On Tuesday, August 16, 2016 at 11:53:24 AM UTC-7, Kathleen Wilson wrote: > Our understanding: "The real problem here is that the issuing > certificate is using sha-1 with predictable serial numbers. ... If a > chosen-prefix attack on sha-1 were discovered... an attacker could use > this CA to obtain a certificate for a domain that isn't theirs."
I think this is a very important part of the consideration, as it suggests a lack of awareness or concern about the security implications about their practices. In particular, https://bugzilla.mozilla.org/show_bug.cgi?id=1267332#c5 If we ignore the CA/Browser Forum's Ballot 164 (Serial Number Entropy), which has an effective day of 30-Sep-2016, and look at the previous versions, we see the following: "CAs SHOULD generate non‐sequential Certificate serial numbers that exhibit at least 20 bits of entropy." Similarly, Mozilla's policy ( https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/maintenance/ ) states: "all new end-entity certificates must contain at least 20 bits of unpredictable random data (preferably in the serial number)." As pointed out on the bug, that's seriously questionable as to whether this CA has implemented this protection. Had they done so, there's at least some work factor an attacker would have to do to predict such serials. To the claim that this wasn't intended to be used on a server, I can confirm that https://gps.autotoll-gps.com.hk is serving this certificate. Practically speaking, what steps could be taken? 1) Do nothing. Despite communications such as https://mozillacaprogram.secure.force.com/Communications/CACommRespWithTextAndTotalsReport?CommunicationId=a05o000000iHdtx&QuestionId=Q00010&QuestionIdForText=Q00011 , simply accept that some CAs are continuing grossly insecure practices. Because the BRs have not explicitly stated the scope (anything directly or transitively capable of TLS issuance, as measured by the EKUs, for example), accept that it's OK for CAs to continue practices that put Firefox/Mozilla users at risk, and address this either in the CA/Browser Forum or the CA Policy 2.3 2) Disable SHA-1 certificates if they directly or transitively chain to this CA, in advance of the January deadline. This assumes the worst (a collision attack) and moves to protect users, but makes no statement about whether what the CA did is correct or not. 3) Disable trust in these specific certificates. As far as I know, OneCRL only supports revocation by SPKI or by Issuer+SerialNumber - it doesn't support revocation by Issuer-and-Hash (is this correct?). I'm not sure if the NSS blacklist version supports blacklisting by hash (but I believe it does?) 4) Disable trust in the older intermediates. It's clear that this CA has a had a large and longstanding issue with compliance to the BRs. While their new CA (CA 1 - 15) appears to be issuing certs that have no cablint issues, older CAs such as this are rife with issues. It may be that the appropriate response to protect users - especially if this CA continues to issue certificates from it - is to wholesale blacklist it via OneCRL. 5) Disable trust in the CA. The justification for this would be arguing that the CA failed its obligations with respect to Item #9 in https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/maintenance/ , in that the combination of SHA-1 issuance from a publicly trusted, non-constrained intermediate, and the use of seemingly predictable certificates with insufficient entropy, represents a real risk of collision attacks, and the CA has materially failed to follow current best practices, such as adding sufficient entropy to the serial number (as reflected in the CA/Browser Forum's Ballot 164). It's worth noting that both Symantec and WoSign have recently misissued SHA-1 certificates as well, where in all three cases (two separate incidents for Symantec recently, one for WoSign), these certificates WERE intended for TLS servers. However, each case also included entropy within the serial - although Symantec also reused serials. I'm curious if there's other options, and I'm curious what the arguments against #4 or #5 would be. Given that CAs provide such a critical function in the ecosystem, and these mistakes have far reaching implications, who would be interested in arguing in favor of keeping this CA/these intermediates trusted? _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
