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

[Dimitris Zacharopoulos]

On 4/9/2018 8:22 μμ, Ryan Sleevi wrote:
>
>
> On Tue, Sep 4, 2018 at 1:08 PM Dimitris Zacharopoulos 
> <jimmy at it.auth.gr <mailto:jimmy at it.auth.gr>> wrote:
>
>
>
>     On 4/9/2018 5:53 μμ, Ryan Sleevi wrote:
>>     I do not believe there is any justifiable or defensible reason to
>>     extend the 5 days requirement, nor do I believe the CA should be
>>     expected to have a 'clean' audit should they chose to do so.
>>
>>     CAs facing challenges of their own creation should not be
>>     exploring "How do I keep these certs working", but "How do I make
>>     sure I don't issue violating certs to begin with". Anything less
>>     is gross negligence, and not the system we should be striving to
>>     build.
>
>     Ryan, it's fine we disagree, however allow me to clarify one more
>     thing. I had a very different picture for the CA that got this
>     case. It was not "How do I keep these certs working" but "How do I
>     balance the need for RPs to access a service ("Availability" in
>     terms of C-I-A), which is also a pressing matter for Subscribers,
>     and "the requirement to revoke the certificate in 24 hours or 5 days".
>
>
> I disagree that this is the correct prioritization. A bad CA should 
> not be prioritizing availability - that sort of perverse incentive 
> structure is one that several now-distrusted CAs have argued, 
> precisely because it sets the wrong expectations. We've seen CAs 
> unsuccessfully argue that even though they didn't validate the domain 
> properly, or could not demonstrate that validation, it's still more 
> important to availability.
>
> This is no different than if your website is made inaccessible because 
> your hosting provider failed to pay their power bill. I can understand 
> it's inconvenient to lack availability, but your service provider is 
> the one that failed, and they don't get to steal power in order to 
> optimize your availability.
>
>     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.

> 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.

>
> There is no safe way to do what you ask, nor is it reasonable to do 
> what you ask. For a system built on trust, it requires trust in the 
> competencies of CAs. The reality of SSL/TLS is that the cost for 
> mistakes is externalized on the ecosystem - on to Subscribers, Relying 
> Parties, and Application Providers - while the profits from those 
> mistakes are centralized with the CA. That's a fundamentally 
> imbalanced system, yet the reality we live it, but that doesn't mean 
> we should further seek to exacerbate those imbalances.

Understood. Thanks for the nice discussion.

Dimitris.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20180904/aba3cff7/attachment.html>