The IdentifierType field may contain either:
a) an Object Identifier (i.e. an OID), or
b) a permanent URI using IA5String.
Characteristically, when an OID is used, the prefix of the OID identifies the Assigner Authority, and a suffix is used to identify the type of permanent identifier being identified. Essentially the same thing is true of URI's.
This last sentence is the most concrete thing the document has to say about the use of URIs as identifiers (here, identifiers of IdentifierType). You wrote:
So, is the question how the authorities are named? Two alternatives are supported: OIDs and URIs. OIDs have a registration process, and it is working pretty well. I have less exposure to URIs, but I know that the XML community is using them. I have not heard about any disasters, so I assume that it is working.Issues:
Leslie:
Let's back up to the motivation for this document. As I said, I really do not want to be seen as the advocate for this document. I was one of the loudest critics in the PKIX working group while this document was being developed. However, I do think that this aspect of the document is satisfactory.
This problem has been around for a long time. The initial solution resulted in X.509v2, which added the optional unique identifier to the certificate. This identifier did not include an authority, it just had a value. As a result, it did not really solve the problem, and no one makes use of this optional feature. This document represents the next generation.
The original driver for the development of this standard was European, where national identity cards are common practice. In fact, many of countries are issuing smart cards that contain X.509 certificates (as well as the associated private key). The inclusion of these national identifiers is important to this community.
In this situation, the authority is a particular country. I have little concern that a national infrastructure will assign the same identifier to more than one person inappropriately.
Another place where a Permanent Identifier can be used is in a company. Consider the employee number. Again, I have no concern that a company will assign the same identifier to more than one person. It would make a huge mess in the human resource database.
Some people think that a Certification Authority (CA) might do this as a service to relying parties. For example, Verisign could include a unique identifier in each certificate subject. I am not sure what customer base is demanding this service, but it seems to be a very straightforward thing to implement. In this case, the CA is authoritative for the name space.
So, is the question how the authorities are named? Two alternatives are supported: OIDs and URIs. OIDs have a registration process, and it is working pretty well. I have less exposure to URIs, but I know that the XML community is using them. I have not heard about any disasters, so I assume that it is working.
One must trust a CA to bind a public key to an identity. This is a core concept to certificates. This is just defining another form of identity that could be bound to a public key. The CA must develop procedures that ensure the robust verification of the identity before issuing the certificate. Again, this is not new. It is a burden that we already impose on the CA.
Russ
At 10:02 PM 4/16/2003 -0400, Leslie Daigle wrote:
Sure there is a syntax. But in my experience of dealing with identifiers, saying "there will be a part that identifies the authority and some other unique string" is insufficient as semantics. Leslie. Russ Housley wrote:Leslie:
I do not want to be viewed as strongly defending this document, but there is a type field. It is quite clear from the ASN.1:
PermanentIdentifier ::= SEQUENCE {
identifierValue IdentifierValue,
identifierType IdentifierType OPTIONAL,
matchingRule [0] IMPLICIT OBJECT IDENTIFIER OPTIONAL
}
IdentifierType ::= CHOICE {
registeredOID OBJECT IDENTIFIER,
uri IA5String
}
The text tells what an absent identifierType means as well....
Russ
At 07:39 PM 4/16/2003 -0400, Leslie Daigle wrote:
Steven M. Bellovin wrote:Precisely -- any sort of name, permanent or not, is useless outside of the administrative context. That's why I think this is such a bad idea, especially as specified here. Why, for example, does it need to have the CA's name in the PI field, when you always have to carry the CA name elsewhere in the certificate?
Hmmm. I did not think the document said that. The Assignment Authority is supposed to be represented in the Identifier Type: " The IdentifierType field, when present, identifies both the Assigner Authority and the type of that field." But the Assigner Authority doesn't have to be the CA. The document is not clear enough about how you go about creating IdentifierType's -- I think that goes to Ted's points. There are some underlying assumptions (aka hand waving) that need to be reviewed. OTOH, if there is no "IdentifierType" field, then the AA is assumed to be the CA, and it is essentially local to that CA. But that's not the same as repeating the CA identifier.Beyond that, the comparison rules for UTF8 strings look wrong -- I'm glad there's a matching rule specified, but from the little I understand about such things there will be a lot of complaints about the lack of more CJK-friendly matching rules.Actually, they should not -- because URIs, as currently defined, are strictly a subset of 0-127 ascii. If you want anything else, you have to encode it (e.g., hex encoding).
OK -- but in that case, why does the document say that the identifier can be a UTV8 string?
Probably 'cause most people don't realize that URIs are ascii character strings :-) I.e., I only pointed out the matching rules should work; that may be by accident. So, I think there are some engineering issues, but I think we've understood the proposal differently, and perhaps buffing off some of the engineering burrs would yield something rational. Leslie. -- ------------------------------------------------------------------- "Reality: Yours to discover." -- ThinkingCat Leslie Daigle leslie@thinkingcat.com --------------------------------------------------------------------- ------------------------------------------------------------------- "Reality: Yours to discover." -- ThinkingCat Leslie Daigle leslie@thinkingcat.com -------------------------------------------------------------------
--
-------------------------------------------------------------------
"Reality:
Yours to discover."
-- ThinkingCat
Leslie Daigle
leslie@thinkingcat.com
-------------------------------------------------------------------