Jeff:
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.)
I need to clear up one point first. The issuerUniqueId and subjectUniqueId
fields are not key identifiers. These fields were introduced in the v2
certificate to distinguish reused DNs as required to support X.500 access
control. I strongly recommend against using these certificate fields for any
other purpose (e.g., in PEM) because of the inevitability of a clash with their
use by a DSA which uses them in support of access control.
The key identifier fields I referred to are in extension fields. (These are
defined in the Proposed Draft Amendment to X.509 which is about to be issued.
I
have not yet posted this document as the editing group is still reviewing it,
but I shall be able to post it by January 15.) The relevant extensions to our
current discussion are:
12.2.2.1 Authority key identifier field
This field enables distinct keys used by the same certification authority to be
differentiated (e.g., as key updating occurs). The key may be identified by an
explicit key identifier, by identification of a certificate for the key
(giving
certificate issuer and certificate serial number), or both. The following
ASN.1
type defines this field:
authorityKeyIdentifier EXTENSION ::= {
SYNTAX AuthorityKeyId
IDENTIFIED BY { id-ce 1 } }
AuthorityKeyId ::= SEQUENCE {
keyIdentifier [0] KeyIdentifier OPTIONAL,
certIssuer [1] Name OPTIONAL,
certSerialNumber [2] CertificateSerialNumber OPTIONAL
-- certIssuer and certSerialNumber constitute a logical pair,
-- and if either is present both must be present. Either this
-- pair or the keyIdentifier field shall be present. If all
-- three fields are present, then the certificate issuer
-- shall ensure they are consistent -- }
KeyIdentifier ::= OCTET STRING
12.2.2.3 Primary-key attributes field
This field provides for optional additional information about the primary
public
key being certified. It can include a key identifier, an indication of the
intended use of that key, and/or an indication of the period of use of the
corresponding private key. The following ASN.1 type defines this field:
primaryKeyAttributes EXTENSION ::= {
SYNTAX KeyAttributes
IDENTIFIED BY { id-ce 3 } }
KeyAttributes ::= SEQUENCE {
keyIdentifier KeyIdentifier OPTIONAL,
keyUsage KeyUsage OPTIONAL,
privateKeyUsagePeriod Validity OPTIONAL }
KeyUsage ::= ....(irrelevent to the current discussion)...
So, the bottom line is that key identifiers are octet strings and that both
issuer and subject key identifiers may optionally be included.
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?
Yes, these are important points.
3. Does the new X.509 standard or accompanying implementors' agreements
explicitly recommend against using a hash as the unique identifier?
No. Assignment of key identifier values is entirely up to the key-pair owner
and its CA, and the standard does not restrict how the octet string may be set
up, provided different keys for the same subject DN have different identifiers.
Provided you are satisified that collisions are a non-issue, then it would be
perfectly reasonable to use the public key hash as a key id. My main point is
that there may be good reasons for using different id assignment schemes and I
do not believe there is any need for any of these specifications to restrict
the
scheme used.
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?
I can't think of any off-hand.
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?
One of the most important uses is in certificate chain construction which, with
key life cycles, is not always a trivial process. What one does is get the
right chain by matching up an issuer DN/key-id pair in one certificate with a
subject DN/key-id pair in the next. It can also be useful in the end-user
certificate, depending upon the application protocol in use. If I have just
your signature, your DN, and your key-id, I use the latter value (and subject
key-id fields) to pick the right certificate from the several certificates with
your DN which the Directory gives me.
For the scenarios I can think of off-hand, I do not think it is important that
the subject key-id be certified by a third party. However, key-ids may some
day
have a role in non-repudiation, so this might become a requirement.
6. Who chooses the subjectUniqueID, the issuer or the subject?
This is not specified; the value needs to be agreed by both at certification
time.
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?
No, nothing has been specified. I think there may be value in using the same
key id in both certificates, but I cannot see a good reason (but various
pitfalls) for mandating it.
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 have thought that when using MIME/PEM in conjunction with an
X.509-based
infrastructure (e.g., our product) we would always use <id-dname> - the
combination of DN and keysel would be used to obtain the right certificate from
the Directory or a certificate cache. Assuming widespread adoption of the new
X.509 subjectAltName extension, we would likely migrate to <id-email> from
there.
Warwick