Subject: RE: PI: 10: Split Identity++

From: "Manger, James H" <[email-masked]>
Date: Fri, 23 Jul 2004 11:29:49 +1000

URL vs OID:
URLs as identifiers are fantastic: just by reading the URL you can often learn a lot, type it into a browser and (quite often) you can get a detailed explanation.  An OID is less human-friendly, but type it into google (instead of the address bar) and (quite often) you can get a detailed explanation just as easily.  The pervasiveness of OIDs in certs, there small size, structure and stability make them a good enough choice for identifying PI types.

	> O=http://registry.us.gov
A solution that enforces extra structure on DNs (eg inserting the assigner in the DN) does not sound like it will be too successful.  From your DN, it would be reasonable to guess that John Smith works for the registry department of the US government... but that is probably not what you meant.

The type, assigner and permanence of a value can be considered meta-data for that value.  It is not unreasonable (nor uncommon) to have the meta-data "half" somewhere else.

	> CN=John Smith, serialNumber=6756565, O=http://registry.us.gov, C=US
Even for your DN you still envisage a PI extension -- presumably to flag the O & SN attributes as a {PI-assigner, PI-value} pair.  Those flags are required to properly interpret the DN as a PI.  Hence, you will still have part of the identity somewhere else -- perhaps only a quarter, not a half ;-)

X.501 actually provides a mechanism to describe some meta-data about an attribute: the attribute type OID, its associated ATTRIBUTE object class value and the meta-data for its supertypes.  X.501 defines a limited variety of meta-data for an attribute, such as how to match & sort values and whether or not a value is unique for an entry.  The PI issue could be solved by extending this meta-data, defining some new generic types with well-defined permanence properties (eg employeeId, companyId), arranging them in a type hierarchy, subtyping specific PIs from those types, ensuring directories publish their schema and getting PKI products to consult that schema.  I see the PI certificate extension as a short cut to that sort of solution by representing a small part of the schema directly in a certificate in a specialised manner.

>  -----Original Message-----
> From: 	Anders Rundgren [mailto:[email-masked]] 
> Sent:	Friday, 23 July 2004 5:59 AM
> To:	[email-masked]
> Subject:	PI: 10: Split Identity++
> 
> Although I triggered the (un)deprecation of serialNumber as PI value objects, I am still not completely satisfied with the result.
> 
> Consider the following PI-enabled citizen certificate:
> 
>     CN=John Smith, serialNumber=6756565, C=US
>     PI-assigner: 2.4.4.282.2
> 
> I believe this would make more sense:
> 
>     CN=John Smith, serialNumber=6756565, O=http://registry.us.gov, C=US
> 
> Apart from pure esthetics, an advantage of putting the assigner in the DN as well, is that the DN becomes a TRUE SUPERSET of PI.  Using URIs, DNs in PI-augmented certificates also become TRUE globally unique identifiers (GUIDs).
> 
> Having one "half" of the identity in the DN and the other half somewhere else, is IMHO not a very "clean" solution.   No other PKI name constructs are designed that way AFAIK.
> 
> P.S. I did not bother with describing the PI extension in the second case as I would like to begin with the important stuff first D.S.

---

From: Olivier Dubuisson <[email-masked]>
Date: Fri, 23 Jul 2004 10:27:32 +0200

> URLs as identifiers are fantastic: just by reading the URL you can often learn a lot, type it into a browser and (quite often) you can get a detailed explanation.  An OID is less human-friendly, bu…

Some information that may be of interest to your group:
- RFC 3061 (http://zvon.org/tmRFC/RFC3061/Output/) defines a URN for OIDs.
- There is a repository of 65,000+ OIDs at http://oid.elibel.tm.fr
- This repository offers a kind of OID resolution system by catenating 
your OID (in ASN.1 or dotted notation, see 
http://asn1.elibel.tm.fr/oid/faq.htm#6) after the URL 
http://oid.elibel.tm.fr/ (e.g., http://oid.elibel.tm.fr/1.3.6.1 )
- This repository is planned to get a more official status by moving to 
the ITU website (hopefully by the end of this year).
- It is planned to develop a web service for OID resolution (probably 
not before mid-2005).
-- 
Olivier DUBUISSON (ITU-T ASN.1 Project leader)
France Telecom
Recherche & Developpement / Research & Development Division
DR&D/MAPS/AMS - 22307 Lannion Cedex - France
t: +33 2 96 05 38 50 - f: +33 2 96 05 39 45 - http://asn1.elibel.tm.fr/