From: Michael **UNKNOWN CHARSET** <[EMAIL PROTECTED]>
michael> Currently there is no such central document since everybody is free
michael> to define OIDs after getting a OID arc. Not even a central registry
michael> exists. For registering OIDs it's sufficient that the owner of the
michael> parent OID publishes it and holds at least a table of his defined
michael> OIDs.
I know about there being no central repository. But for example, the
"legal" shortnames for the DN attributes should be available
somewhere. I did find some in RFC2253, and I'm pretty sure there are
more in some X.500 or X.400 document, since they're used there. What
I'd like to know is which ones that we have are actually documented
elsewhere and which ones are invented by Eric Young or other SSLeay/OpenSSL
hackers...
michael> For certificates I'm currently using Peter Gutmann's 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.
michael> The /ATTR= writing should be abandoned anyway since it's not
michael> a proper string representation (no proper escaping of special
michael> chars).
That's true, but that's currently a different issue for me.
michael> IMHO it's up to the application to maintain a OID registry
michael> (eventually with name aliases). Names of attribute types
michael> should only be used when displaying or processing user's
michael> input.
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.
But I guess that the right way would be to make it less humanly
readable and use the hash of the issuer DN, the same way it should be
done according to RFC2560...
--
Richard Levitte \ Spannv�gen 38, II \ [EMAIL PROTECTED]
Chairman@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47
Redakteur@Stacken \ SWEDEN \ or +46-709-50 36 10
Procurator Odiosus Ex Infernis -- [EMAIL PROTECTED]
Member of the OpenSSL development team: http://www.openssl.org/
Software Engineer, Celo Communications: http://www.celocom.com/
Unsolicited commercial email is subject to an archival fee of $400.
See <http://www.stacken.kth.se/~levitte/mail/> for more info.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
