1139205 - pk11 should more gracefully handle large serial numbers

Status: RESOLVED WONTFIX

(NSS :: Libraries, defect)

Description

[Dana Keeler (she/her) (use needinfo) [:keeler]]

Attachment: ctnca2.pem

PK11_FindCertByIssuerAndSN and PK11_FindCertByIssuerAndSNOnToken enforce that the given serial numbers be no more than CERT_MAX_SERIAL_NUMBER_BYTES octets, which is currently 20. RFC 5280 says that implementations must be able to handle values up to 20 octets, so while it is compliant to not handle larger values, there are root certificates in use that are currently rejected by this restriction (see attached - try to import it as an authority, view it, and then export it). Also note that if these APIs are avoided, the rest of NSS appears to handle these certificates with no trouble.

Comment 1

[Wan-Teh Chang]

David: I remember we discussed this issue in an NSS conference call and
we decided to not change this restriction.

Comment 2

[Dana Keeler (she/her) (use needinfo) [:keeler]]

OK - sounds like a wontfix, then.

Comment 3

[Kathleen Wilson]

We have run into this problem again, with a different root, so now we've seen two instances of this problem, and it's very tricky to identify that there is a problem, and then to figure out what it is.

First time I noticed because the cert export button didn't work when viewing the cert details in the Cert Manager.
https://bugzilla.mozilla.org/show_bug.cgi?id=999378#c15

This time I noticed because when I was checking to make sure the trust bits were correctly set in the inclusion patch, none of the trust bits were set
https://bugzilla.mozilla.org/show_bug.cgi?id=1175227#c6

It seems bad to me that the failure presents itself in different ways...

Comment 4

[Kathleen Wilson]

Should we consider re-opening this bug?

https://groups.google.com/d/msg/mozilla.dev.security.policy/aTN3lkAt0HM/PC4tRwX5BwAJ
"That 20 byte limit sounds like something in NSS hasn't been updated
past SHA-1 yet!  (I do know that certificate serial numbers are not
really hash values in any verifiable way, but that is the historic
design reason for setting the default minimum supported length for
various PKIX elements to 20 bytes).

Since NSS already supports arbitrary length (or at least a lot longer)
values for cryptographic values (such as RSA moduli), it would make
sense for the NSS team to raise any such arbitrary limits to whatever
(non-)limit is implemented for large numbers used in cryptographic
values."

Comment 5

[Martin Thomson [:mt:]]

A longer serial number is probably wise (256 bytes is insane, but I see no reason to set any shorter a limit).  Of course, this will take a very long time to deploy.

Comment 6

[Ryan Sleevi]

mt: Can you explain what you mean by "probably wise"? As already captured on this bug, RFC 5280 spells out very clear:

Conforming CAs MUST NOT use serialNumber values longer than 20 octets.

Given the considerable effort Mozilla (but not necessarily NSS) has put in ensuring RFC 5280 compliance, particularly through the work on mozilla::pkix, your statement seems at odds with the prevailing sentiment.

We discussed that on the call - how RFC 5280 was clear, and how many clients have chosen not to accept non-conforming implementations for their use cases (e.g. they only care about the Web PKI, and thus RFC 5280), so not only will it take a very long time to deploy, it would require coordination across the industry, as well as a change to the Baseline Requirements.

I still support the WontFix :)

Comment 7

[Martin Thomson [:mt:]]

My bad, I forgot.  Ryan is right.