Le mardi 9 février 2016 16:45:29 UTC+1, Peter Bowen a écrit : > On Tue, Feb 9, 2016 at 6:55 AM, Erwann Abalea <[email protected]> wrote: > > Le lundi 8 février 2016 21:43:19 UTC+1, Kathleen Wilson a écrit : > >> On 2/8/16 12:22 PM, Kathleen Wilson wrote: > >> > >> One topic currently under discussion in Bug #1201423 is regarding root > >> certificates with serial number of 0. The error being returned by > >> http://cert-checker.allizom.org/ is "Serial number must be positive". > >> > >> Arguments raised in the bug: > >> > >> >>> RFC 5280 is not ambiguous as to whether zero is positive or not. > >> >>> https://tools.ietf.org/html/rfc5280#section-4.2.1.10 > >> >>> Note: Non-conforming CAs may issue certificates with serial numbers > >> >>> that are negative or zero. Certificate users SHOULD be prepared to > >> >>> gracefully handle such certificates. > >> >>> So zero is clearly non-conforming. > > > > Objection, votre honneur! > > > > The above excerpt from RFC5280 is only a note. The paragraph saying that a > > serial number must be positive is this one: > > > > ----- > > The serial number MUST be a positive integer assigned by the CA to > > each certificate. It MUST be unique for each certificate issued by a > > given CA (i.e., the issuer name and serial number identify a unique > > certificate). CAs MUST force the serialNumber to be a non-negative > > integer. > > ----- > > > > Please note that in the same paragraph, it is said that the serial number > > must be positive and that the serial number must be non-negative. > > This is ambiguous regarding to 0. > > > > For native english speakers, the number 0 is neither positive nor negative, > > and is therefore a member of the non-negative set of numbers, and also a > > member of the non-positive set of numbers. > > For french native speakers, 0 is both positive and negative (it's even the > > only number that is at the same time positive, negative, and pure > > imaginary). > > > > In my opinion, 0 is a perfectly acceptable serial number, but I'm french, > > whence bizarre. That said, 0 is a poor choice for a serial number, close to > > the cliff. > > Even ignoring my frenchyness, 0 is a non-negative number, therefore is > > allowed by this exact paragraph. > > > >> Is a root certificate with serial number 00 compliant with RFC5280 and > >> the BRs? > > > > X.509 doesn't restrict the serialNumber to anything. > > RFC2459 didn't either. > > RFC3250/5280, a profile of X.509, introduced restrictions on serial > > numbers, with an ambiguity regarding to 0. > > BR doesn't clarify the 0 position. > > > > I read the ambiguity as a yes. > > I think the total of the section taken together makes that authors' > intent clear: > > 4.1.2.2. Serial Number > > The serial number MUST be a positive integer assigned by the CA to > each certificate. It MUST be unique for each certificate issued by a > given CA (i.e., the issuer name and serial number identify a unique > certificate). CAs MUST force the serialNumber to be a non-negative > integer. > > Note: Non-conforming CAs may issue certificates with serial numbers > that are negative or zero. Certificate users SHOULD be prepared to > gracefully handle such certificates.
Digging more into RFC2459 evolution. 2459bis-draft01 changed the serial number from an integer to a positive integer. 2459bis-draft03 added the "non-negative" part, the 20 octets limit, and the conflicting Note. 2459bis later drafts only changed small things (a coma, a may into a MAY, etc). I tried to find discussions about those 2 major changes in the PKIX mailing list. Nothing. Discussing about the author's intent is then difficult. An errata has been proposed in 2012: http://www.rfc-editor.org/errata_search.php?rfc=5280&eid=3200 with no action so far. The ASN.1 definition of the CertificateSerialNumber stayed as an INTEGER with no value constraint; it was already possible in the ASN.1 1988 syntax (X.208) used to write the standard. > Serial numbers must be positive. Negative or zero values are non-conforming. I disagree, but. > However, unlike with negative numbers, there is no chance that an > improper encoding of zero (i.e. too many or too few zero bytes) will > cause the value to change. Therefore, I don't see having a zero > integer as a major issue. I fully appreciate that CAs frequently > participate in multiple root programs and may want to use use the > serial number in authority key identifiers, so having to change the > serial number can be a major problem. > > I would suggest that Mozilla make it clear that zero is not acceptable > for certs with a notBefore after a certain date but accept others as > grandfathered. That may be acceptable. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
