Subject: RE: RFC2253 e-mail address

From: "Ramsay, Ron" <[email-masked]>
Date: Thu, 15 Nov 2001 12:42:35 +1100

Ok, Michael.

I looked at the section. 2.4 considers those attributes that are not in "a
published table of attribute types associated with LDAP." Well, there is no
such table, so I believe you can use the name form provided it is well
known. Now, there are about four names for an email address and at least two
object identifiers. If you choose the one from the inetOrgPerson RFC, you
should have little problem. You can then use the normal ascii string value.

For true interoperability, some believe you should only use the name forms
for the attributes in the table in 2.3. This would be the baseline for
interoperability. To encode an ascii string in BER for this case, you might
think that the X.500 version of directory string would be meant, this would
result in the encoding 16 04 41 42 43 44 as the encoding of "ABCD". However,
I think all that LDAP requires is an octet string wrapper, when the encoding
would be 04 04 41 42 43 44. (Inserting email addresses in DNs is rejected by
the purists, possibly for this (and other) reasons - the subject alt name
extension is better used for this as the email address is more appropriately
used in the filter used to search for the entry.)

There are very few attributes that do not have a string representation. I
think they are all certificate and CRL forms. These normally wouldn't occur
in DNs. (But they do have a well-known ASN.1 representation.)

Ron.

-----Original Message-----
From: Michael Ströder [mailto:[email-masked]]
Sent: Thursday, 15 November 2001 11:48
To: Ramsay, Ron
Cc: Anders Rundgren; [email-masked]
Subject: Re: RFC2253 e-mail address

"Ramsay, Ron" wrote:
> 
> Anders Rundgren wrote:
> >
> > Micheal,
> > 2.4:
> >
> >    If the AttributeValue is of a type which does not have a string
> >    representation defined for it, then it is simply encoded as an
> >    octothorpe character ('#' ASCII 35) followed by the hexadecimal
> >    representation of each of the bytes of the BER encoding of the X.500
> >    AttributeValue.  This form SHOULD be used if the AttributeType is of
> >    the dotted-decimal form.
> >
> > Hum,
> > My colluege still think that the last line says something else!
> > i.e. since the e-mail *type* must be represented as dotted decimal
> > its value SHOULD be in hex rather than IA5String.  Or is this bad
writing?
>
> If the attribute is not *recognised*, then it is not possible to decide if
> the value is an RFC 822 address! It is not even possible to decide if the
> value represents an ascii string (though, in this case, inspection would
> show that it is (or perhaps it is base-64 encoded?))
> 
> Therefore, the value is presented in hexadecimal.

Ron, but the attribute value has to be BER-encoded represented in
hex-decimal notation. Which string type is used for the BER-encoding
if your application does not even know the attribute type by OID?

Ciao, Michael.

---

From: Michael Ströder <[email-masked]>
Date: Thu, 15 Nov 2001 02:56:56 +0100

"Ramsay, Ron" wrote:
> would be 04 04 41 42 43 44.

Ron, you raise another issue which BER encoding is used. For me the
conclusion is that RFC 2253 is not sufficient to represent
certificate subject and issuer names in e.g. XML-DSIG.

Ciao, Michael.