Re: On the capability of the RFC2253 "CN=Sam"encoding form for identifying a Certificate.

Juan Carlos Cruellas wrote:
> 
> Dear all,
> 
> As I mentioned in a previous email, both RFC2253 in section 7.2 (Use of
> Distinghished Names in Security Applications. RFC4514 changes the
> section to 5.2) warns on the fact that the reversibility between string
> representation as in the subject of this mail and the DER or BER
> encoding is not guaranteed. This section mentions as an example the fact
> that this form loses the type of ASN.1 pre-defined string that the
> Attribute has. Additionally as RFC2253 does not seem clearly stating
> what are the short names for attributes that applications should know,
> it might be the case that some application recieves an attribute short
> name that does not recognize, which would make it unfeasible to locate
> the referenced certificate.
> 
> One way of circumventing this could be to clearly state a repertoire of
> attribute short names that all applications must know and then strongly
> recommend to use the form "dotted oid of the attribute = hex
> representation of the BER/DER encoding of the value" for the rest of not
> so well-known or even privately defined attributes.
> 
> First of all, do you think that this is an issue? and second if so, does
> this approach sound reasonable?

Yes, it is an issue. I think if applications are concerned with
interoperability, they should only use the keywords defined in RFC 2253:
CN, L, ST, O, OU, C, STREET, DC, UID and use the OID form for any other
attributes. They should also consider using the hexadecimal enconding
for attribute values other than PrintableString or UTF8String. But I'm
not sure if we can add requirements, (even if they are recommendations)
like this at this stage.

--Sean

Received on Monday, 11 June 2007 13:00:16 UTC