You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAH8yC8m7c3Dg8DEt%3DTT0Hh1icRXOE356aEu6iEUegTwxvNtWRQ%40mail.gmail.com.
I’d also like to add that amongst the linters that are available publicly, only x509lint (https://github.com/kroeckx/x509lint) flags this error. Neither zlint or certlint flag this.
It would probably be useful for Mozilla to add running x509lint alongside zlint and cablint as part of its evaluation process for new root certificate inclusions.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAEmnErfQ64AzUUN-syGL%2B%2BxxZFn-UXs9uD7NaeTEygEMhvc3ow%40mail.gmail.com.
>I’d also like to add that amongst the linters that are available publicly,
>only x509lint (https://github.com/kroeckx/x509lint) flags this error. Neither
>zlint or certlint flag this.
Or run them through dumpasn1, that's been flagging this, and many other
issues, for years...
>I think that's another good check. Automatable too since you return the error
>count as the process return code.
One thing to be aware of if you're using it to check large numbers of certs
automatically rather than just a one-off check of a few certs is that with
enough certs you'll eventually run into FPs because it uses heuristics to dig
into X-stuffed-inside-Y encodings. It's fine for the hole encodings in
extensions since it knows about those, but there are other things where you
can occasionally get FPs.
A small nit about this... The ITU standards says (from X.690, Section 6.2):
For the purposes of this Recommendation | International Standard only,
the bits of an octet are numbered from 8 to 1, where bit 8 is the
"most significant bit", and bit 1 is the "least significant bit"
RFC 5280, Section 126.96.36.199, calls out bits but does not specify where
the msb is located, or where the lsb is located. I think that means
according to X.690, 0000011 would assert digitalSignature (bit 0) and
nonRepudiation (bit 1).
>Therefore the certificates are in violation of RFC5280, Section 188.8.131.52,
>which states that "The signatureValue field contains a digital signature
>computed upon the ASN.1 DER encoded tbsCertificate" (emphasis added).
Technically they are, but I would assume that every implementer on the planet
knows that that's one of the numerous parts of the spec that you need to
ignore if you want things to work:
* There is only one encoding rule and that is memcpy()
* There is only one comparison rule and that is memcmp()
In other words you take what the other side sends you and either memcpy() or
memcmp() it as required without ever trying to do any re-coding or
canonicalisation or whatever, because all that'll ever do is break things.
This is illustrated by the fact that in the five years since those certs were
issued and presumably billions of times they've been used, nothing even
noticed the non-DER encoding apart from a tool specially written to check for
So it's really a minor encoding issue, not a significant problem.