In <199412312035(_dot_)MAA23310(_at_)netcom3(_dot_)netcom(_dot_)com>,
jefft(_at_)net(_dot_)com said:
Some questions, all relevant to the MIME/PEM discussion (I hope):
1. Is the UniqueIdentifier always an integer? (I have only part of
the definition on line.)
The syntax for UniqueIdentifier is a BIT STRING, which can of course
contain an integer.
2. If I understand you, an integer is the best key selector because
the public key itself is too big as a database index and a hash allows
the possibility of collisions (albeit 1 in 2^32 or 1 in 2^128). Have
I understood this correctly?
This is a reasonable choice. Per the latest draft on certificate
extensions, the key identifier is unique for those certificates belonging
to that subject. This matches the MIME/PEM KEYSEL definition (distinct from
all KEYSELs assigned by whomever assigned this KEYSEL) if you assume the
subject assigns his/her KEYSELs.
3. Does the new X.509 standard or accompanying implementors' agreements
explicitly recommend against using a hash as the unique identifier?
The subject unique identifier is associated with the subject of the
certificate (the DN), not a particular key. It was added to the certificate
to accommodate reuse of DNs over time (e.g., John Smith leaves organization
X, and a new John Smith is hired). There are implementation agreements on
its format, but the base standard suggests using a date/time, OID, etc.
The key identifier is an extension defined in the new work, and would go
in a field of type Extension. Its syntax is an OCTET STRING, and there are
no words on how it might be allocated (although Warwick's suggestion of
simple sequence numbers works just fine).
4. What circumstances can you think of where someone might want to put
a different key selector in a MIME/PEM identifier if they already have
a subjectUniqueID in their X.509 certificate?
None, off the top of my head.
5. I can understand why the issuerUniqueID would be put in the
certificate: I need to get the right public key among the possible
ones the issuer might own in order to verify the certificate. But
what motivated putting the subjectUniqueID in there, since the
SubjectPublicKeyInfo is already included? If it is simply to match
the key to the database index, was it determined that this needs to be
authenticated by a third party issuer?
The subject unique ID is used, among other things, by the Directory
access control mechanism defined in the 1993 standards. In X9F1, we
had talked about using this field for a key ID, but this tends to break
the Directory (if you have one, and if you use access controls).
6. Who chooses the subjectUniqueID, the issuer or the subject? If the
subject gets certified by two different issuers with the same key,
have any protocols been defined saying whether or not the
subjectUniqueID values have to be the same?
Nothing is defined in the base standard regarding this, although there is
a suggestion that a user which is issued certificates by multiple CAs
might require coordination of the unique ID between them. (Note the
unique ID is assigned by the naming authority, not the CA, in the general
X.500 case).
7. In the X.509 context, the two MIME/PEM identifiers to choose from
for Originator-ID and Recipient-ID are:
<id-dname> ::= "DN" "," <keysel> "," <dnamestr> CRLF
and
<id-publickey> ::= "PK" "," <publickey> CRLF (I left out the
optional name here)
Given that you aren't trying to hide the public key, when would you
use the <id-dname> instead of the <id-publickey> ? (A typical
distinguished name is longer than a typical public key, so you
wouldn't use the <id-dname> for lower bandwidth.) Another way of
asking this is: Is the database index functionality, for which you
like the key selector, appropriate for or needed in the Originator-ID
and Recipient-ID fields?
I would certainly use the DN if I have a shared, distributed database
(like an X.500 directory) which holds the keys and other information
associated with a user. In this case, the DN can be used to navigate
to the server holding the user's entry, and the key selector just picks
the right certificate from the entry. In this environment, the public
key is pretty useless for finding the right server. One could imagine
splitting the keys up among servers based on some property of the keys
themselves, e.g. based on the low order bits of the modulus, but of course
then you can't look up other information about the user based on his/her
name. Of course, if I have a single key server, or if I maintain my own
database of known public keys (suitably protected from undetected
modification), the key or a hash of it works just fine. But this doesn't
seem to scale very well.
Regards,
Rich