Signing the SHA-1 subjectKeyIdentifier

[Matthias van de Meent]

Hi,

RFC 5280 specifies using the SHA-1 hash over the public key bitstream
as one way to generate a subjectKeyIdentifier, but it also allows for
other methods. I've noticed that some CAs (GTS, Sectigo) explicitly
uses SHA-1 to generate public key identifiers for inclusion in the
certificate.

As I'm not too aware of any other methods currently in use (looked at
Google Trust Services, Let's Encrypt, Sectigo), I'll assume that this
is common practise.

That being said, the MRSP explicitly forbids CAs from using SHA-1 in
5.1.3 on data other than [some requirements regarding old server
certificates], although I do note that this section is preceded with
s5.1, which details that these subsections 5.1.[1,2,3] apply to
contexts where the algorithm is encoded as an AlgorithmIdentifier.

Are there reasons w.r.t. security as to why SHA-1 was chosen for SKI,
and why it has not been replaced with a more secure variant (e.g.
SHA-256 or any of the other, newer, signature algorithms in the SHA
family)?

Sorry if this has been discussed before, but I could not find the
relevant discussion on the m.d.s.p. thread, except one a small mention
of SKI in the SHA-1 sunsetting thread.

With regards,

Matthias van de Meent

[Andrew Ayer]

Hi Matthias,

I may chime in later with further thoughts about SKI, but for now I
wanted to quickly address this:

> That being said, the MRSP explicitly forbids CAs from using SHA-1 in
> 5.1.3 on data other than [some requirements regarding old server
> certificates]

5.1.3 explicitly talks about "sign[ing]" SHA-1 hashes, not "using"
SHA-1 or creating SHA-1 hashes. Since the SKI value is not signed,
using SHA-1 for it is not a violation of MRSP section 5.1.3. The
sentence in section 5.1 which says "The following sections detail
encoding and signature algorithm requirements for each of these keys"
further clarifies that 5.1.3 is about signatures, not general use of
SHA-1.

Regards,
Andrew

[Peter Gutmann]

'Matthias van de Meent' via dev-secur...@mozilla.org <dev-secur...@mozilla.org> writes:

>Are there reasons w.r.t. security as to why SHA-1 was chosen for SKI,

Nope, it's just one way to generate a unique per-key value, you can use
anything you want as long as it's unique per key. In particular the odd way
of generating it looks like it was someone's implementation that got written
into the spec.

Peter.

[Kurt Roeckx]

On Mon, May 17, 2021 at 02:51:41PM +0200, 'Matthias van de Meent' via dev-secur...@mozilla.org wrote:
>
> Are there reasons w.r.t. security as to why SHA-1 was chosen for SKI,
> and why it has not been replaced with a more secure variant (e.g.
> SHA-256 or any of the other, newer, signature algorithms in the SHA
> family)?

As I understand it, the SKI is not checked by any application, and
does not provide any security. It's used to look something up,
like you do with a hash table. We want it to be unique, but it
doesn't have to be unique. Multiple certificates with the same
SKI can and do exist.


Kurt

[Ryan Sleevi]

Hi Kurt,

I’m afraid your information may be out of date. Windows totally uses the SKI/AKI, and in recent versions of Windows 10, explicitly limits the number of unique SKI/key pairs you can have (that is, shared SKIs with unique keys), as a way of limiting the number of signatures considered during path building. Windows does this before and independent of the subject/issuer name matching.

Other products, such as Adobe, are notable in going further, in which SKI/AKI fully replaces name chaining in some products.

Are these good ideas? In Microsoft’s case, the right intent is there, even if the execution is surprising. NSS has its own similar weird quirks (like issuer and serialNumber uniqueness, even from separate certificate hierarchies), so I’m certainly not trying to cast aspersions here.

The primary reason PKI designers prefer the SHA-1 approach over the unique approach is that it allows client implementations to synthesize the SKI for issuers in the event the AKI is present in the issued cert, which is a scenario that used to be far more prevalent. The unique approach also has the downside of causing clients to prefer certain paths, which can make mid-stream PKI transitions more difficult (replacing an old issuing intermediate with a new one).

However, as you noted, despite these quirks, most clients will not be security affected, and as Andrew noted, it’s not the same risk that the prohibition in policy is defending against (similar to the reason with OCSP ResponderIDs)