Re: Empty IA5String

[Steven Legg <steven.legg@eb2bcom.com>]

Hallvard,

Hallvard B Furuseth wrote:
> Steven Legg writes:
>
> > Component matching allows any string matching rule to be applied to any
> > string component of any ASN.1 type. There is nothing to prevent those
> > string components having zero length. We might be able to force the
> > IA5 String syntax to have at least one character but we can't do the
> > same for every string component of every ASN.1 type.
>
>
> Can that be explained briefly, or can you suggest some parts of rfc3687
> to read to see what's going on?  I'd rather not read 42 pages of RFC
> just to follow this thread.

Suppose that there is an attribute whose syntax is described by the
following ASN.1 type:

    SEQUENCE {
        description   UTF8String,
        parameters    Parameters
    }

It is possible through component matching to apply the caseIgnoreMatch
matching rule to just the description component of attribute values of this
syntax. The description component has no size constraint so it is permitted
to be zero-length as far as ASN.1 is concerned. That means caseIgnoreMatch
potentially has zero-length strings as input.

> At the moment I'm kind of hoping I've misunderstood you completely -
> currently I'm wondering: (No need to reply to the following if the
> explanation is just that I misunderstand:-)
>
> Why should an empty string be treated as a valid Directory String,
> instead of having the comparison return Undefined or an error?

An empty string is always illegal for a DirectoryString, but X.520 allows
caseIgnoreMatch, etc, to be applied to UTF8String (among other things) and
makes no condition about any size constraints on the UTF8String. One could
legally define an attribute whose syntax is just UTF8String without a size
constraint and use caseIgnoreMatch as its equality matching rule.
Component matching just generalizes that by allowing matching rules to
be applied to component parts of attribute values.

> More generally, if one can pass any string to any matching rule
> regardless of the expected syntax (is that assertion syntax or attribute
> syntax?),

Both. The inputs to matching rules can be an attribute value and an
assertion value, or two attribute values.

> why should e.g. numericStringMatch("xx123", "123") be treated
> as anything sensible, with a defined result?

It shouldn't. numericStringMatch is applied to NumericString values and
"xx123" isn't a legal value of NumericString. However numericStringMatch
is permitted by X.520 as the equality matching for an attribute with an
unconstrained NumericString as the syntax. In principle, numericStringMatch
could be applied to attribute values of zero-length.

> Are IA5 String, Printable String and Numeric String defined in terms of
> an 8-bit encoding (e.g. UTF-8) in ASN.1?

X.680 makes no assumption about the encoding of these character sets.
That is left to the definitions of the encoding rules. For the BER family
and the LDAP-specific encodings they are 8-bit encodings. In PER they could
be 8-bits or less. In GSER they are UTF-8, which amounts to the same thing as
8-bit. For RXER and XER they are any character encoding permitted by XML -
typically UTF-8 or UTF-16. The matching rule descriptions in the syntaxes
draft avoid tying the semantics to any particular character encoding.

> Otherwise, when using
> caseIgnoreIA5Match, numericStringMatch or telephoneNumberMatch to
> compare an attribute component with an 8-bit assertion value, which
> character encoding is that assertion value presumed to use?  (I expect
> the attribute component's syntax provides the component's character
> encoding.)

The assertion value arrives in the character encoding determined by
the protocol operation that carried it.

Regards,
Steven