I want key selectors because they serve to identify one key from many owned
by
the same entity either at the same time or over periods of time. In products
supporting key life cycle management, we always have key selectors - they are
essential for purposes such as archive and audit management. Ideally, the
key
selector also accompanies each instance of use of the key, to serve as an
index
to find the right key. In public-key systems it is sometimes possible to
avoid
using such selectors, making use of dates, or the public key value itself, to
find the right key. However, dates are problematical because of overlapping
periods of key usage and because dates are not always reliably known. In
theory, the public-key value is adequate, but in practice this value (or a
hash
thereof) is not a good database index (too big, if uniqueness is to be
assured).
For example, simply assigning monotonically increasing numbers to the
sequence
of keys for one entity, then storing key records sorted by key selector,
gives a
much cleaner and efficient implementation.
We have introduced Key Identifier as a new field in the X.509 v3 certificate
for
this purpose. It seems to me that exactly the same value could be conveyed
in
the key selector of MIME-PEM. That way the right public key can always be
readily found, regardless of whether or not a copy of the key or a
certificate
accompanies the message.
Thank you. These explicit reasons for why you want the key selector
are very useful to me. Here's what I have for the X.509 certificate
definition:
Certificate ::= SIGNED { SEQUENCE {
version [0] Version DEFAULT v1,
serialNumber CertificateSerialNumber,
signature AlgorithmIdentifier,
issuer Name,
validity Validity,
subject Name,
subjectPublicKeyInfo SubjectPublicKeyInfo,
issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL,
-- If present, version must be v2 or v3
subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL,
-- If present, version must be v2 or v3
extensions [3] Extensions OPTIONAL
-- If present, version must be v3 --} }
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.)
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?
3. Does the new X.509 standard or accompanying implementors' agreements
explicitly recommend against using a hash as the unique identifier?
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?
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?
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?
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?
- Jeff