On 02/01/2019 14:10, Rob Stradling via dev-security-policy wrote: > On 02/01/2019 13:44, info--- via dev-security-policy wrote: <snip> >> 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").
To deal with this false positive, I've just deleted crt.sh ID 966433897 and reassigned its log entry records to 1477430. -- 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
