On Tuesday, June 21, 2022 at 6:38:27 PM UTC-7 [email protected] wrote: > > 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 4.2.1.3, 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). >
A good observation, but I think irrelevant in this case. The quoted paragraph from X.690 Section 6.2 says "the bits *of an octet* are numbered..." (emphasis added). The value in question here is of type BIT STRING, which doesn't care about octet boundaries, so once we've assembled the bits of that bit string and need to interpret it, that paragraph no longer applies. Additionally, if this observation were correct, every certificate parser I'm aware of would have to change how they interpret this field. As a additional note, I did some further exploration into the certs in question, just for my own edification. In particular, I performed the following operations <https://go.dev/play/p/RpxC8H7qY5s>: 1) Extract the raw bytes of the tbsCert 2) Compute the appropriate (SHA256 or SHA384) hash over those bytes 3) Verify that the public key in the cert validates the signature in the cert over that hash In both cases, the signature validates. This means that the signature in the certificate was originally computed over the same bytes as we currently see in the certificate. From the earlier investigation, we know that the keyUsage extension bytes are actually BER encoded, not DER encoded. Therefore the certificates are in violation of RFC5280, Section 4.1.1.3 <https://datatracker.ietf.org/doc/html/rfc5280#section-4.1.1.3>, which states that "The signatureValue field contains a digital signature computed upon the ASN.1 *DER encoded* tbsCertificate" (emphasis added). Of course, it may be that it doesn't matter. Because these are self-signed roots, they're essentially just wrappers around a public key -- most certificate validation routines will not end up checking the self-signature on these certs because they're inherently trusted. I just thought it was interesting to dig into this and learn more myself. Aaron -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/4141c8ce-5f51-45c9-9963-217fe04ae1d5n%40mozilla.org.
