On 24/8/2018 4:10 μμ, Ryan Sleevi wrote:
On Fri, Aug 24, 2018 at 1:42 AM Dimitris Zacharopoulos via
Servercert-wg <servercert...@cabforum.org
<mailto:servercert...@cabforum.org>> wrote:
I'm not sure if this has been discussed before (sorry if I missed
did),
but I would like to bring up the fact that there might be Subscribers
who suffer a Key Compromise (like the ones distributed with their own
software or embedded within customer devices), who would be willing to
leave the compromised Certificate/Key out there until they find a
way to
replace it (that might take more than 24 hours or 5 days). This is a
case where the Subscriber weighs the impact of Availability in the
security properties of the offered service more than Confidentiality.
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.
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).
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.
Dimitris.
[1]:
https://groups.google.com/d/msg/mozilla.dev.security.policy/2RCO0P-gX0g/CYJHeU7eAwAJ
If a Subscriber doesn't want their Certificate revoked because that
might have a significant impact/damage in their service Availability,
isn't that something the ecosystem should respect and allow? Shouldn't
this be treated on a case-by-case basis? I would be in favor of
entering
clauses in the BRs to allow more than 5 days before revocation for
certain such cases, provided that the CA and the affected Subscriber
would have to disclose the case to the CA/B Forum, as Ryan
suggested in
previous discussions. Just disclosing the fact should be enough. It
would just be an additional option for the CAs and the Subscribers
that
would improve today's practices. As Jeremy demonstrated, there are
several real cases today, where CAs try to extend the 24hours
revocation
window in order to balance that Availability risk for the Subscribers
and -I might add- the Relying Parties that want to have access to the
Subscriber's services. I believe there are RPs out there that value
availability more than confidentiality. I'm not one of them, but... :)
Thoughts?
Dimitris.
_______________________________________________
Servercert-wg mailing list
servercert...@cabforum.org <mailto:servercert...@cabforum.org>
http://cabforum.org/mailman/listinfo/servercert-wg
_______________________________________________
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public
