[Servercert-wg] [cabfpub] [EXTERNAL]Re: Ballot SC6 - Revocation Timeline Extension
Ryan Sleevi
sleevi at google.com
Tue Sep 4 07:53:21 MST 2018
On Mon, Sep 3, 2018 at 1:48 PM Dimitris Zacharopoulos <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> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20180904/27c69f47/attachment.html>
More information about the Servercert-wg
mailing list