<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<br>
<div class="moz-cite-prefix">On 4/9/2018 8:22 μμ, Ryan Sleevi wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CACvaWvbCifmvKaOkdfXAHYTi+zp62AXueanfevAeyK_OEiHGqQ@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=utf-8">
<div dir="ltr"><br>
<br>
<div class="gmail_quote">
<div dir="ltr">On Tue, Sep 4, 2018 at 1:08 PM Dimitris
Zacharopoulos <<a href="mailto:jimmy@it.auth.gr"
moz-do-not-send="true">jimmy@it.auth.gr</a>> wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"> <br>
<br>
<div class="m_8101259580698175376moz-cite-prefix">On
4/9/2018 5:53 μμ, Ryan Sleevi wrote:</div>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_quote">
<div>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.</div>
<div><br>
</div>
<div>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. </div>
</div>
</div>
</blockquote>
<br>
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".<br>
</div>
</blockquote>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" 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>
<br>
<blockquote type="cite"
cite="mid:CACvaWvbCifmvKaOkdfXAHYTi+zp62AXueanfevAeyK_OEiHGqQ@mail.gmail.com">
<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>
<br>
<blockquote type="cite"
cite="mid:CACvaWvbCifmvKaOkdfXAHYTi+zp62AXueanfevAeyK_OEiHGqQ@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<div><br>
</div>
<div>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.</div>
</div>
</div>
</blockquote>
<br>
Understood. Thanks for the nice discussion.<br>
<br>
Dimitris.<br>
</body>
</html>