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

[Dimitris Zacharopoulos]

On 4/9/2018 5:53 μμ, Ryan Sleevi wrote:
>
>
> On Mon, Sep 3, 2018 at 1:48 PM Dimitris Zacharopoulos 
> <jimmy at it.auth.gr <mailto:jimmy at it.auth.gr>> wrote:
>
>
>
>     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).
>
>
> I disagree.
>
>     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.
>
>
> 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.
>
> 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.

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".

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?


Thanks,
Dimitris.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20180904/a66ab4a0/attachment.html>