[Servercert-wg] [cabfpub] Ballot SC6 - Revocation Timeline Extension

[Wayne Thayer]

On Mon, Aug 20, 2018 at 1:43 PM Doug Beattie <doug.beattie at globalsign.com>
wrote:

> Tim,
>
>
>
> I agree that Vulnerability is different from key compromise and the
> actions we take should reflect that and I think we should try to keep 12
> and 13 type events in the 5-day list.
>
>
>
> Is our strategy to have vulnerabilities fall into the 5 day list and
> exploited vulnerabilities fall into the 24 hour list?
>
> *Key Compromise:* A Private Key is said to be compromised if:
>
> 1)      its value has been disclosed to an unauthorized person
>
> 2)      an unauthorized person has had access to the private keys
>
> 3)      a vulnerability has been exploited to disclose private keys
>
> And the remainder of the definition can be removed because those are
> examples of vulnerabilities being exploited ( Debian weak  and poor key
> generation).  If we want a list of possible vulnerabilities or bad
> practices, then we can put in an appendix.
>
>
>
> I think #13 is a special case of #12 (both vulnerabilities), so I still
> recommend removing it.  Is the distribution of a private key in in a
> software package any different than the distribution of a private key in
> any other (insecure) method?
>
>
>
> Here’s what I’d recommend:
>
>
>
> a) Use the new definition I listed above
>
> b) change:
>
> 12. The CA is made aware of a vulnerability that exposes the Subscriber's
> Private Key to compromise; or
>
> to
>
> 12. The CA is made aware of a vulnerability that has been exploited to
> disclose the Subscriber's Private Key; or
>
>
>
> c) Delete #13
>
>
> Thanks for the proposal Doug. I like the direction, but:

* The new definition proposed for #12 makes it equivalent to key
compromise, because to know that a vulnerability has been exploited the CA
is going to prove key compromise. I'd propose:

12. The CA is made aware of a practical technique that exposes the
Subscriber's Private Key to compromise; or

The intent being that disclosing a vulnerability isn't enough to trigger
revocation, but a practical exploit is.

* if we adopt that definition for 12, then I agree that 13 can be removed.

* I think we should keep the language on weak keys in the definition of Key
Compromise. Without it, I can see it being argued that weak keys fall under
12 and thus allow 5 days for revocation, or worse, don't require revocation
at all.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20180820/501599b8/attachment.html>