On 4/9/2018 5:53 μμ, Ryan Sleevi wrote:
On Mon, Sep 3, 2018 at 1:48 PM Dimitris Zacharopoulos
<[email protected] <mailto:[email protected]>> wrote:
On 24/8/2018 4:10 μμ, Ryan Sleevi wrote:
On Fri, Aug 24, 2018 at 1:42 AM Dimitris Zacharopoulos via
Servercert-wg <[email protected]
<mailto:[email protected]>> 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.
_______________________________________________
Public mailing list
[email protected]
https://cabforum.org/mailman/listinfo/public
