tl;dr: Do you use the SKID field of the certificates we issue for some purpose? Would something break if we removed it?
Background: The Subject Key Identifier (SKID) extension contains a short (20-bytes) hash of the public key that appears in the certificate. This extension is the sibling of the Authority Key Identifier (AKID) extension, which similarly contains a hash of the public key of the issuer of the certificate. These two extensions are a critical part of chain building, the process of finding a validation path from the end-entity certificate presented by a website to a root certificate that your browser trusts.
So the Baseline Requirement mandate that the SKID be present in all CA Certificates, so that it can be matched against the AKID in certificates that they issue. But Subscriber Certificates like those we issue to you don't themselves issue other certificates. No one is performing chain-building up to a Subscriber Certificate. So the Baseline Requirements also strongly recommend against including the SKID in Subscriber Certificates.
We have historically included the SKID in all Subscriber Certificates that we issue. With the recommendation to remove it, we are strongly considering doing so. But we don't know who might be using or relying on the SKID for some purpose that we have no visibility into.
If you are aware of anyone who is using the SKID field and would be broken by its removal, please reply here describing the use-case. Thanks!
I previously used it, but migrated to calculating the SPKI hash. The use-case is that we recycled Private Keys across ACME Orders [e.g. all Orders within a given week or day might share a Private Key] and this was a cheap way to determine which Certificates relied on the same Key.
The reason for time-based recycling of Private Keys was to minimize server memory in scalable systems. If you have any Subscribers/Accounts that often re-use the same Private Key across large numbers of Certificates, they might be affected by this.
I looked through OpenSSL source code to find usages of the subject key identifier extension, apart from the obvious path building.
I found two usages not related to path building within OpenSSL code:
The Certificate Management Protocol uses the subjectKeyIdentifier extension to match certificates against a senderKID in the PKI Message Header. Usage is optional.
The SignerInfo type uses either the issuer and serial number for identification, or the subject key identifier.
The KeyAgreeRecipientInfo Type has the same choice between using either issuer + serial number, or the SKID extension.
The KeyTransRecipientInfo type has the same choice again.
I have no detailed knowledge of these protocols to understand how commonly it is used though. Formally both protocols should work fine without the extension, but I don't know how that plays in practice.
Which other public CAs don't set the Subject Key Identifier? If the answer is none (or no popular ones) then personally I'd sit back and let them trailblaze that for you.
There will be a breakage somewhere, it's just the scale that's unknown. Most likely is null references where they previously expected a value, or perhaps worse would be cases that match on blank (so all certs seem to have the same SKID).
I feel like these are the sorts of questions that should have been answered by whatever committee is recommending no longer including the field. I'm not personally aware of software I use, or clients connecting to my servers, being dependent on it, but I don't know why I would know if they were.
No, the larger motivator here is to remove it entirely to be in line with the BRs. The phrasing "NOT RECOMMENDED" means "there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed" (RFC 2119). This thread is part of that process of understanding and weighing. Simply shortening the SKID would not bring us in line with the BRs.
Per a censys search, it appears that only about 0.04% of currently-valid DV certs omit the SKID. But that is still tens of thousands of certificates. Figuring out which CAs are issuing those certs appears to be beyond my censys abilities at the moment, since censys doesn't seem to like to handle queries for empty values.
I modified your query to show the issuers of the 36492 certificates that do not have the SKID extension. For those who don't have an account, here's a screenshot of the issuers:
Yes, it is likely that many CAs offer different issuance profiles. Here are three examples of certs without SKID, taken from the censys results I posted above:
Thank you! I don't know why I couldn't get parsed.extensions.subject_key_id="" to work; I feel like I was trying the exact same thing as your query. Thanks for getting that to work, this data is great.
As far as I can tell, certificates with and without SKID have always existed. I looked through 20 years of generated certs of mine and found most have a SKID, but at least one did not. That one made with openssl generating the key on the fly, like so: openssl req -new -newkey rsa:2048 -subj "/C=US/O=HORK Enterprises/OU=ITS/CN=CAE server" -keyout private/cae.hork.key -out csr/cae.hork.csr
and then signed with my internal (self-signed) CA. The resulting cert does NOT comprise a SKID. That makes sense of course, as the SKID was originally intended to identify private key reuse and a key, generated on-the-fly, is typically not reused. The moral of the story is that valid certs without SKID have always existed and any software scanning for it should have a mechanism to deal with it not being present.
