[Servercert-wg] [cabfpub] [EXTERNAL]Re: Ballot SC6 - Revocation Timeline Extension

[Dimitris Zacharopoulos]

On 24/8/2018 4:10 μμ, Ryan Sleevi wrote:
>
>
> On Fri, Aug 24, 2018 at 1:42 AM Dimitris Zacharopoulos via 
> Servercert-wg <servercert-wg at cabforum.org 
> <mailto:servercert-wg at 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-wg at cabforum.org <mailto:Servercert-wg at cabforum.org>
>     http://cabforum.org/mailman/listinfo/servercert-wg
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20180903/48faafa6/attachment.html>