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

[Ryan Sleevi]

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.

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 :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20180904/8eb9b188/attachment-0001.html>