<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 5:53 μμ, Ryan Sleevi wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CACvaWvZW4DbYLr5F1zPuHiymu3MdCFz1+0uoK4ofe1z0M4MHyQ@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 Mon, Sep 3, 2018 at 1:48 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_-6346194225499355923moz-cite-prefix">On
24/8/2018 4:10 μμ, Ryan Sleevi wrote:<br>
</div>
<blockquote type="cite">
<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"
target="_blank" 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>
</div>
</blockquote>
<div><br>
</div>
<div>I disagree.</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 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>
</div>
</blockquote>
<div><br>
</div>
<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>
<br>
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>
<br>
<br>
Thanks,<br>
Dimitris.<br>
</body>
</html>