What are the problems with overspecified AKID?
Kyle Hamilton
(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.
Is there something in PKIX or X.509 that explains what AKID must
contain, and/or why?
Thanks!
-Kyle H
Nelson B Bolyard
> 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.
Kyle Hamilton
I've been able to put together to this point. Though I'm not quite
sure I completely understand...
If AKID contains an actual key ID (as opposed to the certificate ID
tuple of issuer:serial), it allows for that key to be used to build
the certification path regardless of its certificate validity times
(since it's referencing a key as the trust anchor).
If AKID contains an issuer:serial tuple, it enforces that the
certificate being evaluated has a validity period that is within the
issuer's validity period?
The latter could be useful in the case where you have a trust anchor
(TA) which signs sub-CAs with rolling validity periods. However, in
that case (if I'm understanding correctly) the AKID in the end
certificate (TA signs CA signs EE) would be the name of TA, plus the
serial number of TA's issued certificate to CA?
Or am I seriously missing something?
(One reason for this might be as a way to limit the damage of a forged
certificate, forged via hash-collision... if you can reduce the
potential validity period based on the validity period of the CA, then
that's a part of the certificate that has constraints and thus is more
difficult to alter to create a valid collision...)
-Kyle H
> _______________________________________________
> dev-tech-crypto mailing list
> dev-tec...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto
>
Nelson B Bolyard
> Thanks for the explanation, Nelson -- it's a lot more information than
> I've been able to put together to this point. Though I'm not quite
> sure I completely understand...
>
> If AKID contains an actual key ID (as opposed to the certificate ID
> tuple of issuer:serial), it allows for that key to be used to build
> the certification path regardless of its certificate validity times
> (since it's referencing a key as the trust anchor).
When validating a cert chain, there is always some date/time for which
it is being evaluated. Let's call that the "target validity time".
RFC 5280 says it is "the current date/time". Whatever it is, the target
validity time MUST be within the validity period of every certificate in
the chain for the chain to be valid. That's true with or without AKIDs.
AKIDs don't change that rule.
Now, imagine an intermediate CA that gets a new cert issued to it by a
Trust Anchor every N months. Over time, numerous certs will be issued
to/for that CA's public key. They all have the same subject name, public
key and key ID, and they may have the same issuer name (same TA) or they
may conceivably come from a different TA, but they definitely have different
serial numbers and different validity periods.
Let's say that that intermediate CA issues subordinate certs with AKIDs
that specify ONLY the key ID and not the issuer:serial. Then sometime
later, the CA's own cert expires and is replaced with a new CA cert.
It has the same Subject name, public key and key ID. It may have the same
issuer name as before, or it may have a different issuer name, but it will
definitely have a new serial number and new validity dates. Since the
AKIDs in the subordinate certs issued by that CA all have AKIDs that
specify only the Key ID, then the CA's new replacement cert can be used to
validate the subordinate certs even after the original CA cert has
expired.
But now, let's change that story and say that the intermediate CA issued
subordinates certs that specified key ID *AND* issuer:serial. That means
that that subordinate cert can only be verified while the cert with that
issuer:serial is within its validity period. A new replacement CA cert
will not be acceptable for validating those subordinates certs because it
has a different serial number, and perhaps a different issuer name.
Now, this is not merely theoretical. In the last year or two, numerous
companies that run intermediate CAs have evolved and have also begun to
run their own root CAs (Trust anchors) and have applied to have those
trust anchors added to NSS. Those intermediate CAs formerly got their
CA certs issued by some third party TA, but now they are getting new CA
certs from their own corporate TA. So there is a new intermediate CA
cert with a new issuer name and a new serial number, but the same subject
name, the same public key and the same key ID. Soon that intermediate CA's
old CA cert will expire, and the new cert from the new TA is intended to
act as a replacement for it. But if that intermediate CA has issued
subordinate certs with the old cert's issuer name and serial number,
the new CA cert will not be an acceptable substitute/replacement for
the old CA cert when validating that subordinate cert's chain.
> If AKID contains an issuer:serial tuple, it enforces that the
> certificate being evaluated has a validity period that is within the
> issuer's validity period?
It requires that the "target validity time" for any cert validation
be within that issuer cert's validity period.
> The latter could be useful in the case where you have a trust anchor
> (TA) which signs sub-CAs with rolling validity periods. However, in
> that case (if I'm understanding correctly) the AKID in the end
> certificate (TA signs CA signs EE) would be the name of TA, plus the
> serial number of TA's issued certificate to CA?
Yes, in that case, if the CA had issued an EE cert with an AKID with
issuer:serial, that issuer would be the name of that TA, and the serial
would be the serial of that CA's cert.
> (One reason for this might be as a way to limit the damage of a forged
> certificate, forged via hash-collision... if you can reduce the
> potential validity period based on the validity period of the CA, then
> that's a part of the certificate that has constraints and thus is more
> difficult to alter to create a valid collision...)
It occurred to me that it might be useful to specify just the issuer name
but not the serial number in an AKID. This might be useful in a bridge
CA world where an intermediate CA has multiple certs from different TAs,
all with overlapping time periods, all with the same subject name, public
key and key ID. It might be useful to be able to say, in an AKID,
"only validate this cert IF your cert path includes this one of the many
issuers of certs for this bridge". For example, given a bridge CA with
certs from two TAs (call them "Army" and "Navy"), it might be useful for
that bridge to be able to issue certs that can only be validated by those
who trust the Navy TA, and not by those who trust only the Army TA.
However, the RFC explicitly disallows that use. It says:
-- authorityCertIssuer and authorityCertSerialNumber MUST both
-- be present or both be absent
Jean-Marc Desperrier
> [...]
> 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
> 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.
What the RFC 5280 does say is that :
4.2.1.2. Subject Key Identifier
[...] Applications are not required to verify that key identifiers
match when performing certification path validation.
So, rejecting a potential AC cert only because the SKI/AKI do not match
is not part of the path validation algorithm of the RFC.
Now, the application can consider that it applies the RFC (&4.2.1.1) by
getting a set of potential issuers, filtering them according to the AKI,
and stopping there if the set is empty after the filtering.
Ignoring the extension when that happens is just a sensible and
compatible way to make the application more robust.
> Although it would be non-conformant with the RFC, I think perhaps NSS
> should ignore the AKID's issuer name and serial number fields
It's not non-conformant, the RFC does allow to choose to ignore them.