Kyle Hamilton wrote, On 2008-11-15 17:49: > What are the problems with overspecified Authority Key ID fields? > (i.e., both key ID and issuer's name/serialnumber)? I'm noticing that > it's part of the Certificate Policy v1.2 (paragraph 4, in the > 'incorrect extensions' bullet point), but I still haven't been able to > figure it out.
RFC 5280 (current IETF PKIX RFC) says: The authority key identifier extension provides a means of identifying the public key corresponding to the private key used to sign a certificate. This extension is used where an issuer has multiple signing keys (either due to multiple concurrent key pairs or due to changeover). The identification MAY be based on either the key identifier (the subject key identifier in the issuer's certificate) or the issuer name and serial number. Let's say a CA has multiple public keys, and different CA certs with the same subject name but different public keys. Let's say that you're trying to validate a certificate (the "certificate under test") that was issued by that CA and signed with one of the private keys corresponding to one of those public keys. That cert under test is only verifiable with one of that CA's public keys, and it's important that you pick the right public key with which to verify the signature on the cert under test. If all those CA certs have the same name, how do you know which one has the right public key? The RFC provides two ways, both of which use an extension in the certificate under test named the authority key ID (AKID) extension. The AKID may contain a "Key Identifier", or an issuer name and serial number (pair), or both. The AKID extension in the Cert under test says "Find a CA cert that matches these criteria and use it". The two ways of using the AKID extension are: a) match the "Key Identifier" in the cert-under-test's AKID extension to the Key Identifier in the Subject Key ID (SKID) extension of one of the CA's certs and use the matching CA cert, or b) specify the issuer name and the serial number of one CA cert in the AKID extension of the cert under test, and use the CA cert with that issuer name and serial number. (Note: the issuer name in the AKID in the cert under test is NOT the name of the issuer of the cert under test. It is the name of the issuer who issued the cert for the CA that issued the cert under test. It is the issuer's issuer's name.) This latter method was intended (I believe) for use with CA certs that were older than the RFC, and lacked SKID extensions, such as X.509 v1 certs that are (or were) still in use when the AKID was defined. There seems to be no reason on earth to specify the CA cert's issuer name and serial number if the CA cert has an SKID extension. In that case, the keyID in the subordinate cert's AKID is sufficient. But lots of certs contain both anyway. I think the people who issue those certs aren't sure what the parts of that extension are for, and feel like they're doing an incomplete job if they don't specify both. Also, nearly all "tutorial" web pages that exist for OpenSSL show the use of both, so most OpenSSL users figure that's what they should do. The problems arise when the cert under test has an AKID that specifies the issuer name and serial number present in the issuing CA's cert, and that CA cert expires or is superseded by another cert with the same public key (perhaps from a different issuer). That AKID won't let the cert under test be verified with a CA cert with a different issuer name or serial number. Note that when the AKID specifies an issuer name and serial number, it doesn't mean "use the cert with this issuer name and serial number UNLESS ITS EXPIRED or REVOKED". In many cases, for many certs whose AKIDs have both keyID and issuer name and serial number, having specified the issuer's issuer name and serial number never actually helps with the verification of that cert, and only hurts by later preventing a transition to a new replacement CA cert. In those cases, the inclusion of the specification for issuer name and serial number is an overspecification that hinders rather than helps. Although the RFC doesn't say so, there have been books and documents on the subject published by various authors which claim that the issuer name and serial number in the AKID, if present, are only an indicator of preference. They state that the AKID's issuer name and serial number are to be ignored if you (the relying party testing the cert under test) cannot find any CA cert with that issuer name and serial number. However, if you do/can find the cert with that issuer name and serial number, then you must use that one. So say certain authors. That statement by those authors doesn't really solve the problems caused by overspecification. As long as the relying party has the CA cert specified by issuer name and serial number in the AKID, he is obligated to rely on that cert. Because of the problem of misconfigured servers that send out incomplete cert chains, most relying party software today saves copies of CA certs that have been found to be valid, so that they may later be found and used to "fill in" for missing CA certs from misconfigured servers. Once the relying party gets a good CA cert, he remembers it for a long time, and is able to use it to match on AKIDs in certs issued by that CA, even after replacement certs for that CA cert have been issued. > Is there something in PKIX or X.509 that explains what AKID must > contain, and/or why? RFC 5280 says: The keyIdentifier field of the authorityKeyIdentifier extension MUST be included in all certificates generated by conforming CAs to facilitate certification path construction. There is one exception; where a CA distributes its public key in the form of a "self-signed" certificate, the authority key identifier MAY be omitted. The RFC is silent about the use of the authorityCertIssuer and authorityCertSerialNumber fields of the authorityKeyIdentifier extension. Although it would be non-conformant with the RFC, I think perhaps NSS should ignore the AKID's issuer name and serial number fields, either a) when the Key ID is also present in the AKID, or b) at all times. That would seem to solve most problems with overspecified AKIDs. It could conceivably cause problems in cases where the CA really knew what it was doing, and properly and intentionally used the issuer name and serial number fields in the AKID of the certs it issued. But I suspect those cases are very rare, or perhaps totally non-existent. I suspect that ignoring the AKID's issuer name and serial number would fix more problems than it would create, by far. But for now, NSS is following the RFC's specification. _______________________________________________ dev-tech-crypto mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-crypto
