[Servercert-wg] [cabfpub] [EXTERNAL]Re: Ballot SC6 - Revocation Timeline Extension

[Wayne Thayer]

On Tue, Sep 4, 2018 at 11:10 AM Ryan Sleevi via Servercert-wg <
servercert-wg at cabforum.org> wrote:

>
> On Tue, Sep 4, 2018 at 1:53 PM Dimitris Zacharopoulos <jimmy at it.auth.gr>
> 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
> Servercert-wg at cabforum.org
> http://cabforum.org/mailman/listinfo/servercert-wg
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20180904/b03fa837/attachment.html>