Richard Levitte - VMS Whacker wrote:
>
> But for example, the
> "legal" shortnames for the DN attributes should be available
> somewhere.
Can you list a limited set of attribute types for certificate DNs? I
can't.
> I did find some in RFC2253, and I'm pretty sure there are
> more in some X.500 or X.400 document,
I do not have access to the X.500 documents. But RFC2256 is a good
start for getting an idea of the X.500 schema. BTW: You won't find
anything there related to e-mail addresses.
> michael> For certificates I'm currently using Peter Gutmann's
> michael> dumpasn1.cfg.
> michael> Would be nice to have support for this file in OpenSSL.
>
> Yup, but then we must resolve the problem of name clashes. If you
> look at the latest incarnation of dumpasn1.cfg (available through the
> IETF PKIX WG page), you'll see that there are two "emailAddress". The
> other one is 0.2.262.1.10.7.28, which is apparently a Telesec
> (some operator) attribute.
Again: The only reference to an attribute type is the OID!
If you want to parse a string representation (preferrably RFC2253)
and you have a name clash the parsing should fail. Simply like that.
This only affects parsing user's input or configuration data.
Internally only OIDs of attribute types should be used.
> The problem is, again, when you try to use the subject DN or the
> issuer DN that is returned from X509_NAME_oneline() with a different
> application where the OID name is represented differently. For
> example, one might want to use that string as name in a LDAP catalogue
> and access the same entries using a different program, written in
> Java.
Again: All programs handling DNs have to handle the complete ASN.1
structure of the X.500 DN or parse an equivalent RFC2253 string
encoding to rebuild the ASN.1 structure. Trivial string comparison
is not an overall solution anyway.
> But I guess that the right way would be to make it less humanly
> readable and use the hash of the issuer DN,
NO! A hash is a significant information loss... ;-)
If you're ever lucky enough to have a corresponding DN structure in
certificates and your directory the certificate-handling LDAP-client
has to handle the complete ASN.1 structure of the DN. I'm currently
in the process of trying that with web2ldap and it drives me nuts...
> the same way it should be done according to RFC2560...
OCSP does almost nothing with the issuerName. The OCSP server of a
CA can reference a cert by serialNumber anyway. IMHO issuerNameHash
is in the OCSP request just for input checking.
In opposite directory servers do a lot with DNs...
Ciao, Michael.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
