On Tue, Sep 4, 2018 at 11:10 AM Ryan Sleevi via Servercert-wg < [email protected]> wrote:
> > On Tue, Sep 4, 2018 at 1:53 PM Dimitris Zacharopoulos <[email protected]> > wrote: > >> The CA will still get an "unclean" report anyway because of the RFC5280 >>> violation or the mis-issuance per se, we are not debating that. I am only >>> pointing out the requirement to revoke within 24 hours or 5 days. Does this >>> make it clearer? >>> >> >> You are, though, because that's not accurate to suggest the CA is >> guaranteed to get a modified opinion / qualified report. If the BRs endorse >> this, as you propose, then it's no longer a BR violation. >> >> >> That is a very strange interpretation of the BRs, at least for me. IMO, >> if a CA issues a Certificate that has incorrect encoding, it is definitely >> a violation of the BRs under a specific section and that is expected to be >> in the Auditor findings. If the BRs allowed that certificate to remain >> valid until the Subscriber rolled-over and not be revoked in 24 hours or 5 >> days but with disclosing the case (as you had suggested in earlier posts), >> then that would not be an additional violation. Now, we live situations >> where CAs are doing multiple violations; one being the mis-issuance and >> another by not revoking within 24 hours. >> > > We've had this discussion before, though, about creative interpretations > of RFC 5280 being applied. > > >> If the information was, say, inaccurate (the domain ownership was lost >> due to court order), but the CA determined to optimize for availability, >> then the CA isn't in violation of the BRs or RFC 5280 if they decide not to >> revoke. >> >> >> I'm not saying that all cases would be allowed to use this extension. We >> seem to have separated two "classes" of revocation cases; those with >> 24-hour and 5-day window. Perhaps the 5-day window cases might be >> considered for extension, or not even all of them. In any case, I have no >> strong feelings about this, just wanted this discussion to take place so we >> have a mutual understanding of the challenges that need to be balanced. >> > > As noted, I disagree with your assessment about risk (24 vs 5), but also > more fundamentally, the view that providing availability for relying > parties is somehow in the best determination of the CA. > > Consider this recently issued certificate from DigiCert - > https://crt.sh/?id=628153824&opt=cablint,x509lint,zlint > > Here, the certificate contains an invalid RSAPublicKey - the DER-encoding > of the exponent is not minimally encoded, in that it has a leading zero > byte. No doubt, this RSAPublicKey came from the Subscriber/Applicant - that > is, it wasn't generated by DigiCert. I suspect DigiCert probably just took > the value directly from a BER-encoded CSR and transplanted it, versus > re-encoding it. > > One creative interpretation of CAs is to cite RFC 5280, Section 4.1, and > note that "For signature calculation, the data that is to be signed is > encoded using the ASN.1 distinguished encoding rules (DER)", re-echoed in > 4.1.1.3. It should come as no surprise, then, that CAs found not to be > issuing certificates properly formed have been arguing that their > certificates are not mis-issued - merely, they signed something not-DER, so > they're not-certificates (not missued-certificates). Or, alternatively, > they've argued that the presentation format doesn't need to be DER, > provided that the signatureValue is computed over the DER - that is, that > Relying Parties should re-encode the BER to DER and see if the signatures > match. If they don't, it's just "invalid signature" - not "misissued > certificate". When you look at TLS' RFCs, you see it refers to X.509v3, not > RFC 5280's profile of X.509v3, and that's similarly been used for creative > interpretation. > > Similarly, such CAs will cite RFC 3279, which states that the RSA public > key MUST be encoded using the ASN.1 type RSAPublicKey. However, through > creative wording, the description of "The DER encoded RSAPublicKey is the > value of the BIT STRING subjectPublicKey" can be read as non-exclusive - > that is, that it could permit other inclusions. > > So this is a concrete example of where your argument doesn't hold water, > and precisely the danger in trying to come up with this ranked hierarchies > of revocation. > > However, let's further expand this thought experiment, and think about > what the consequences are of having the CA make such a determination > (Availability > Competent and Correct operation). A CA is naturally > incentivized to optimize for Availability - the CA who never revokes their > Subscriber certs is the CA to pick, the same as the CA that always picks > the maximum validity period rather than the minimum. This is something > we've seen time and time again - the worse a CA is, for the ecosystem, the > more popular it becomes relative to its competitors. But equally, a CA that > issues such invalid certificates, but encourages non-revocation, equally > encourages the rest of the ecosystem to do so, such that it becomes the > norm - a de facto standard of incompatibility. > > > This is really the key point to me. I don't see any way to create a "hardship exception" to the 5-day rule that won't be abused given the incentives of both CAs and Subscribers. I would go further and state that we already have something close to this. A number of CAs have decided to accept a (theoretical) audit qualification rather than follow the existing BR revocation rules. My hope is that the extension to a 5-day revocation window will reduce this abuse and that auditors will hold CAs accountable when they choose to violate the BRs. > > If the client does not aggressively police this - at verification time - > then the ecosystem falters, because the existing players accept such certs, > and thus any new Relying Parties must also accept such certs. This isn't > theoretical either - we've seen that because both NSS and CryptoAPI evolved > as BER-and-DER supporting implementations, they were lax in DER enforcement > (both by design and through bugs). This has caused a host of issues - > Mozilla has captured just some of the ones they encountered in > https://wiki.mozilla.org/SecurityEngineering/mozpkix-testing#Things_for_CAs_to_Fix > > But that's not a concern of the CAs - their obligation is to their > Subscriber, not the ecosystem - and as we've seen, have attempted to > creatively language-lawyer out of interoperable compliance. > > So yes, I reject the fundamental premise and goal :) > _______________________________________________ > Servercert-wg mailing list > [email protected] > http://cabforum.org/mailman/listinfo/servercert-wg >
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
