On 4/9/2018 8:22 μμ, Ryan Sleevi wrote:
On Tue, Sep 4, 2018 at 1:08 PM Dimitris Zacharopoulos
<[email protected] <mailto:[email protected]>> 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.
_______________________________________________
Public mailing list
[email protected]
https://cabforum.org/mailman/listinfo/public
