Re: OID repository (was Re: Any Organization Certificatesoutthere?)

["Bob Jueneman" <bjueneman@xxxxxxxxxx>]

The even bigger problem would still be with us, even if we had access to a completely up to date repository of the ASN.1 definition of every OID in the world, including those that were proprietary definitions by various vendors or users.

That problem, of course, is how to incorporate some recognition of all of those OIDs into every program that might ever encounter them.  

Ideally, you would have a global, authoritative repository that would be accessible by both LDAP and HTTP, and any time an application encountered a new OID it would download the ASN.1 and reconfigure itself on the fly to at least display the encoded information properly. Sure it will.

But even if you were able to handle the syntax properly, and therefore be able to display the information correctly, what do you do about the semantics?

Consider all of the encodings for what is loosely referred to as an e-mail name.  Even the syntax is problematic, if I start to match what is encoded in the certificate against something like "President William (Bill) (Slick Willy) (Jefferson) Clinton" <potus@xxxxxxxxxxxxxx>.  I'd be willing to bet a fairly large steak dinner that not one single commonly used S/MIME implementation would correctly handle all of a baroque variations of a legal RFC822 e-mail address and compare it to the contents of a certificate.

But what do we do about the semantics?  Consider a few of the more awkward, such as "locality" "commonName", "serial", or even "country".  Do they refer to the current physical abode of the subject, or to some criteria of citizenship or registration?  And what localities, for example, are considered legitimate?  Do they include trailer parks, military bases, state and national parks, off shore oil rigs, migrant tribes, etc.?  Who knows!

I certainly don't have a solution to this problem, and as people like Steve know, it's something I've fretted over for nearly 10 years.

One thing that I am quite confident of, however.  If the situation is this bad with ASN.1, which at least has an unambiguous if sometimes unknown way of naming constructs, then the problem with XML is going to be ASN.1 squared, as people insist on using a familiar, user friendly nickname that may not even be unambiguously defined with respect to the syntax, much less well-defined semantically.

Bob



>>> Paul Hoffman / IMC <phoffman@xxxxxxx> 11/13/01 01:55PM >>>

At 7:12 PM +0100 11/13/01, Olivier DUBUISSON wrote:
>There is also http://asn1.elibel.tm.fr/oid 
>In the current state it probably has less information than Alvestrand's,
>but we agreed to merge the data (just a matter of time!).
>You may also be interested to know that there's discussion inside ISO and
>ITU-T to provide a "more official" repository that could be derived from
>http://asn1.elibel.tm.fr/oid 

This site, however, isn't useful for IETF work. It has none of the 
official S/MIME sub-arcs described at 
<http://www.imc.org/ietf-smime/sm-oid.asn>, and none of the official 
PKIX sub-arcs described at 
<http://www.imc.org/ietf-pkix/pkix-oid.asn>.

Such a project should probably at least grep through all RFCs and 
I-Ds looking for OIDs and make sure they are all represented in the 
published tree.

--Paul Hoffman, Director
--Internet Mail Consortium