<div dir="ltr">On Tue, Sep 4, 2018 at 11:10 AM Ryan Sleevi via Servercert-wg <<a href="mailto:servercert-wg@cabforum.org">servercert-wg@cabforum.org</a>> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><br><div class="gmail_quote"><div dir="ltr">On Tue, Sep 4, 2018 at 1:53 PM Dimitris Zacharopoulos <<a href="mailto:jimmy@it.auth.gr" target="_blank">jimmy@it.auth.gr</a>> wrote: </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF"><blockquote type="cite"><div dir="ltr"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF"> 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?<br>
</div>
</blockquote>
<div><br>
</div>
<div>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. </div>
</div>
</div>
</blockquote>
<br>
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.<br></div></blockquote><div><br></div><div>We've had this discussion before, though, about creative interpretations of RFC 5280 being applied.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF">
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_quote">
<div>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.</div>
</div>
</div>
</blockquote>
<br>
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.<br></div></blockquote><div><br></div><div>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.</div><div><br></div><div>Consider this recently issued certificate from DigiCert - <a href="https://crt.sh/?id=628153824&opt=cablint,x509lint,zlint" target="_blank">https://crt.sh/?id=628153824&opt=cablint,x509lint,zlint</a></div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div></div></div></div></div></blockquote><div>></div><div>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.<br></div><div>><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div></div><div>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 <a href="https://wiki.mozilla.org/SecurityEngineering/mozpkix-testing#Things_for_CAs_to_Fix" target="_blank">https://wiki.mozilla.org/SecurityEngineering/mozpkix-testing#Things_for_CAs_to_Fix</a></div><div><br></div><div>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.</div><div><br></div><div>So yes, I reject the fundamental premise and goal :)</div></div></div></div></div>
_______________________________________________<br>
Servercert-wg mailing list<br>
<a href="mailto:Servercert-wg@cabforum.org" target="_blank">Servercert-wg@cabforum.org</a><br>
<a href="http://cabforum.org/mailman/listinfo/servercert-wg" rel="noreferrer" target="_blank">http://cabforum.org/mailman/listinfo/servercert-wg</a><br>
</blockquote></div></div>