On 02/01/2019 13:44, info--- via dev-security-policy wrote: > El miércoles, 2 de enero de 2019, 12:49:52 (UTC+1), Rob Stradling escribió: >> On 09/10/2018 23:53, Wayne Thayer wrote: >>> On Tue, Oct 9, 2018 at 3:43 AM Rob Stradling wrote:<snip> >>> Wayne, Kathleen: >>> Given the number of times that all the CAs in Mozilla's Root Program >>> have been reminded about Mozilla's requirements for disclosing >>> intermediate certs, I wouldn't blame you if you decided to add these 20 >>> intermediate certs [5] to OneCRL immediately! >>> >>> I think we should give this serious consideration, although it doesn't >>> help with the majority of these that are trusted for email. >> >> Hi Wayne. Did you give this serious consideration? >> >> An Izenpe intermediate cert [1] has been known to crt.sh (see [2]) for >> well over a month, but hasn't yet been disclosed to the CCADB. >> >> >> [1] https://crt.sh/?id=966433897 >> >> [2] https://crt.sh/mozilla-disclosures >> >> -- >> Rob Stradling >> Senior Research & Development Scientist >> Sectigo Limited > > We're reviewing what happened with this subCA, because it's reported to the > CCADB (like all other subCAs). At the moment we've seen that there are two > different entries in the crt.sh with the same serial number, but different > fingerprints: > > https://crt.sh/?id=1477430 -> disclosed > https://crt.sh/?id=966433897 -> not disclosed > > This CA is not new, so there wouldn’t be any problem. But we continue > analyzing what happened.
Thanks Oscar. You're right: 966433897 is a duplicate of 1477430, and so this is *not* a violation of Mozilla's intermediate cert disclosure requirement. The only difference between the two certs is the encoding of the signature parameters in the part of the certificate that is not covered by the CA's signature. Anyone could create any number of "different" certs with malformed signature parameters that share the same CA-produced signature, and for this we can't blame the CA. As it happens though, 966433897 is slightly less malformed than 1477430. It's unfortunate that some CT logs accept, or used to accept, certs with malformed signature parameters (in the part of the cert not covered by the CA's signature). Izenpe did make one related mistake when issuing this cert back in (presumably) 2010 though: the signature parameters in the TBSCertificate are omitted, whereas they should be an ASN.1 NULL (and so https://crt.sh/?id=1477430&opt=cablint reports the error "RSA signatures must have a parameter specified"). -- Rob Stradling Senior Research & Development Scientist Sectigo Limited _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
