<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 24/8/2018 4:10 μμ, Ryan Sleevi
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CACvaWvYLcSQYB4fy2fs-RZyT3EU73nhGkXZ=q5DP+4H6a=yX4Q@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 Fri, Aug 24, 2018 at 1:42 AM Dimitris
Zacharopoulos via Servercert-wg <<a
href="mailto:servercert-wg@cabforum.org"
moz-do-not-send="true">servercert-wg@cabforum.org</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">I'm not
sure if this has been discussed before (sorry if I missed
did),<br>
but I would like to bring up the fact that there might be
Subscribers<br>
who suffer a Key Compromise (like the ones distributed with
their own<br>
software or embedded within customer devices), who would be
willing to<br>
leave the compromised Certificate/Key out there until they
find a way to<br>
replace it (that might take more than 24 hours or 5 days).
This is a<br>
case where the Subscriber weighs the impact of Availability
in the<br>
security properties of the offered service more than
Confidentiality.<br>
</blockquote>
<div><br>
</div>
<div>I don't agree that the Subscriber's wishes should trump
the Relying Parties. Otherwise, we never would have
deprecated SHA-1 or RSA-1024.</div>
</div>
</div>
</blockquote>
<br>
I agree that for cases where the risk of compromise is high (like
the SHA-1 or RSA-1024 deprecation) and the impact to the ecosystem
equally high, there should be firm requirements that mitigate this
risk. However, cases such as [1] about improper encoding of IP
Addresses as dNSName type in SAN extension, which is properly
validated information but clearly non-conformant to the
requirements, that IMHO seems to have a lower risk to the ecosystem
and impact to the Relying Parties. The impact of the Relying Parties
losing access to these services seems greater if the CA were to
revoke the Certificate within 24 hours (or even after 5 days,
because the Subscriber is not able to update their system sooner
than 5 days).<br>
<br>
The only reason I am following-up on this is because there will
certainly be CAs in the future that will be tempted to violate the
5-day rule if they come across a dilemma like the one SHECA is
facing. The public would benefit from a disclosure requirement for
revocation cases where the revocation time must extended the 5 days
requirement. CAs will have no excuse if they do not revoke
mis-issued certificates within the 5-day rule and not use the
disclosure provision to extend the 5-day rule and share the
particular revocation case with the public. IMO, it is better for
CAs to share pro-actively, rather than getting caught and share the
information anyway, under worse conditions.<br>
<br>
Dimitris.<br>
<br>
<br>
[1]:
<a class="moz-txt-link-freetext" href="https://groups.google.com/d/msg/mozilla.dev.security.policy/2RCO0P-gX0g/CYJHeU7eAwAJ">https://groups.google.com/d/msg/mozilla.dev.security.policy/2RCO0P-gX0g/CYJHeU7eAwAJ</a>
<br>
<br>
<br>
<blockquote type="cite"
cite="mid:CACvaWvYLcSQYB4fy2fs-RZyT3EU73nhGkXZ=q5DP+4H6a=yX4Q@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
If a Subscriber doesn't want their Certificate revoked
because that<br>
might have a significant impact/damage in their service
Availability,<br>
isn't that something the ecosystem should respect and allow?
Shouldn't<br>
this be treated on a case-by-case basis? I would be in favor
of entering<br>
clauses in the BRs to allow more than 5 days before
revocation for<br>
certain such cases, provided that the CA and the affected
Subscriber<br>
would have to disclose the case to the CA/B Forum, as Ryan
suggested in<br>
previous discussions. Just disclosing the fact should be
enough. It<br>
would just be an additional option for the CAs and the
Subscribers that<br>
would improve today's practices. As Jeremy demonstrated,
there are<br>
several real cases today, where CAs try to extend the
24hours revocation<br>
window in order to balance that Availability risk for the
Subscribers<br>
and -I might add- the Relying Parties that want to have
access to the<br>
Subscriber's services. I believe there are RPs out there
that value<br>
availability more than confidentiality. I'm not one of them,
but... :)<br>
<br>
<br>
Thoughts?<br>
Dimitris.<br>
<br>
<br>
_______________________________________________<br>
Servercert-wg mailing list<br>
<a href="mailto:Servercert-wg@cabforum.org" target="_blank"
moz-do-not-send="true">Servercert-wg@cabforum.org</a><br>
<a href="http://cabforum.org/mailman/listinfo/servercert-wg"
rel="noreferrer" target="_blank" moz-do-not-send="true">http://cabforum.org/mailman/listinfo/servercert-wg</a><br>
</blockquote>
</div>
</div>
</blockquote>
<br>
</body>
</html>