What damage could be done if a malicious certificate had an identical "Subject Key Identifier"?

Question

I'm looking at the the Subject Key Identifier attribute of a CA certificate and am trying to understand the role it plays in validation and infer how validating client software could get it wrong.

• What is the role of the Subject Key Identifier in validating a CA or End certificate?
  Any knowledge of how it's implemented popular software packages would be helpful

• What is the worst that an attacker could do if they could generate a public key that also contained the same hash?

As I read RFC3280 I see that the Subject Key Identifier (SKI) is like the glue that is used to build and verify the PKI chain. The SKI also appears to be a more secure version than the certificate serial number and name that was also used to bind two certs together.

With regard to client validation of the certificate hash, do clients simply do a "pattern match" of the SKI, or is the chain SKI actually computed as described below:

For CA certificates, subject key identifiers SHOULD be derived from
the public key or a method that generates unique values. Two common
methods for generating key identifiers from the public key are:

  (1) The keyIdentifier is composed of the 160-bit SHA-1 hash of the
  value of the BIT STRING subjectPublicKey (excluding the tag,
  length, and number of unused bits).

  (2) The keyIdentifier is composed of a four bit type field with
  the value 0100 followed by the least significant 60 bits of the
  SHA-1 hash of the value of the BIT STRING subjectPublicKey
  (excluding the tag, length, and number of unused bit string bits).

One example risk I'm trying to mitigate is a malformed CA certificate with a public key that doesn't hash to a correct SKI (done by manual ASN.1 editing and resigning the cert from the attacker's root)

Answer 1

The Subject Key Identifier does not play a role in validation, at least not in the algorithm which makes up section 6 of RFC 5280. It is meant to be an help for path building, the activity which takes place before validation: this is when the entity who wants to validate a certificate assembles potential certificate chains that will then be processed through the section 6 algorithm. Section 4.2.1.2 describes this extension, and includes this text:

To facilitate certification path construction, this extension MUST appear in all conforming CA certificates, that is, all certificates including the basic constraints extension (Section 4.2.1.9) where the value of cA is TRUE. In conforming CA certificates, the value of the subject key identifier MUST be the value placed in the key identifier field of the authority key identifier extension (Section 4.2.1.1) of certificates issued by the subject of this certificate. Applications are not required to verify that key identifiers match when performing certification path validation.

These "MUST" are obligations on the CA: to conform to the profile which RFC 5280 describes, CA must take care to match the Authority Key Identifier of the certificates it issues to its own Subject Key Identifier. Take note of the last sentence: this match is not part of what validation must verify.

It is recommended by the RFC to compute the key identifier through hashing, because it will minimize collisions, thus guarantee maximum efficiency of this extension for path building. However, hashing is not mandatory. CA can choose the identifier in any way as they see fit; and verifiers certainly do not recompute identifiers. This is pure byte-to-byte equality test. Also, I know as a fact that Microsoft's implementation of path validation is ready to build and try to validate paths where key identifiers do not match.

The worst that a rogue CA could do by reusing key identifiers is to make path building more difficult; this might trigger a kind of denial of service for verifiers who do path building through key identifiers and are too lazy to try otherwise. In practice, verifiers tend to build paths by matching the subject and issuer DN, not the key identifiers, so the practical impact should be close to nil.

Answer 2

Rouge Key Identifiers would hinder unambiguous path finding.

In the worst case several potential paths have to be checked for validity. But would you have a certificate with a rouge identifier in your trust store anyway? If you don’t trust it, no need to check that path. And if you do trust it, then that path would not validate.