On Tuesday, August 8, 2017 at 5:18:21 AM UTC+9, Jakob Bohm wrote: > On 07/08/2017 16:54, Peter Bowen wrote: > > On Mon, Aug 7, 2017 at 12:53 AM, Franck Leroy via dev-security-policy > > <[email protected]> wrote: > >> Hello > >> > >> I checked only one but I think they are all the same. > >> > >> The integer value of the serial number is 20 octets, but when encoded into > >> DER a starting 00 may be necessary to mark the integer as a positive value > >> : > >> > >> 0 1606: SEQUENCE { > >> 4 1070: SEQUENCE { > >> 8 3: [0] { > >> 10 1: INTEGER 2 > >> : } > >> 13 21: INTEGER > >> : 00 A5 45 35 99 1C E2 8B 6D D9 BC 1E 94 48 CC 86 > >> : 7C 6B 59 9E B3 > >> > >> So the serialNumber (integer) value is 20 octets long but lenght can be > >> more depending on the encoding representation. > >> > >> Here is ASCII (common representation when stored into a database: > >> "A54535991CE28B6DD9BC1E9448CC867C6B599EB3" it is 40 octets long, > >> VARCHAR(40) is needed. > > > > The text from 5280 says: > > > > " CAs MUST force the serialNumber to be a non-negative integer, that > > is, the sign bit in the DER encoding of the INTEGER value MUST be > > zero. This can be done by adding a leading (leftmost) `00'H octet if > > necessary. This removes a potential ambiguity in mapping between a > > string of octets and an integer value. > > > > As noted in Section 4.1.2.2, serial numbers can be expected to > > contain long integers. Certificate users MUST be able to handle > > serialNumber values up to 20 octets in length. Conforming CAs MUST > > NOT use serialNumber values longer than 20 octets." > > > > This makes it somewhat whether the `00'H octet is to be included in > > the 20 octet limit or not. While I can see how one might view it > > differently, I think the correct interpretation is to include the > > leading `00'H octet in the count. This is because > > CertificateSerialNumber is defined as being an INTEGER, which means > > "octet" is not applicable. If it was defined as OCTET STRING, similar > > to how KeyIdentifier is defined, then octet could be seen as applying > > to the unencoded value. However, given this is an INTEGER, the only > > way to get octets is to encode and this requires the leading bit to be > > zero for non-negative values. > > > > That being said, I think that it is reasonable to add "DER encoding of > > Serial must be 20 octets or less including any leading 00 octets" to > > the list of ambiguities that CAs must fix by date X, rather than > > something that requires revocation. > > > > (Thinking in a multi-year future perspective): > > Given the age of RFC5280 and the (suspicious) fact that 20 is also the > length of SHA-1 hashes, maybe there should be work in CAB/F and > implementations to actually raise this maximum (and one day perhaps the > minimum) to a larger value, such as 64 plus optional zero. > > Doing so would allow future requirements to increase the minimum serial > entropy to more than 160 bits, should a relevant attack scenario emerge.
This is entirely unnecessary and would present serious stability issues due to backwards compatibility. It may not be appropriate for this thread - discussing specific misissuances - but there is zero benefit from extending the serial number, and obvious serious detriment to the wide variety of applications - including, of course, NSS and CryptoAPI - that specifically expect serial numbers to be less than or equal to 20 bytes, when encoded. I appreciate your multiyear perspective, but given that it provides no articulated value, and of which significant discussion around the limits of other fields, such as commonName, are both relevant and informative, it would merely be change for change sake. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
