[cabfpub] [Servercert-wg] [EXTERNAL]Re: Ballot SC6 - Revocation Timeline Extension
jimmy at it.auth.gr
Tue Sep 4 10:08:28 MST 2018
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
>> 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
>> 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  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?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Public