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

[Wayne Thayer]

Doug,

On Thu, Aug 23, 2018 at 12:26 PM Doug Beattie <doug.beattie at globalsign.com>
wrote:

> Wayne and Ryan,
>
>
>
> I received some good out-of-band suggestions so I’m passing those along.
>
>
>
> Generally - though not always (e.g. zero days) - attacks are seen as
> 'possible', then 'feasible' before they become 'demonstrable'; there's
> nothing stopping CAs (at their own discretion) from requiring reissuance of
> customer certs based on a possible/feasible attacks - long before the risk
> of the attack becoming demonstrable.
>
>
>
> CAs adopting this methodology may stay ahead of the game (as much as one
> can) by proactively reissuing certs for keys that 'may'
> (possibly/feasibly/reasonably) be at risk of an attack‎. This provides
> better security to customers, the ecosystem, and has the large potential to
> drastically reduce the number of certs that need to be revoked and reissued
> within 5 days if this methodology becomes proven or economically feasible.
> Regardless of how CAs handle these in the possible/feasible/reasonable
> categories, drawing the line at demonstrated/proven seems like a reasonable
> statement for triggering the 5 day revocation rule.
>
>
>
>
If this is to be a 5-day requirement, then I think it needs to move out of
the definition of Key Compromise as you originally suggested. Key
Compromise is inextricably linked to the 24-hour revocation window. Are
there concerns with allowing 5-days to revoke vulnerable certificates?
>

> How about something like this:
>
>
>
> **Key Compromise**: A Private Key is said to be compromised if: a) its
> value has been disclosed to an unauthorized person, b) an unauthorized
> person has had access to the private key, or c) there exists a demonstrated
> or proven method to obtain the Private Key.
>
>
>
>
This is awfully close to the new #11: The CA is made aware of a practical
technique that exposes the Subscriber's Private Key to compromise.

I would still like to have the example of Debian weak keys somewhere, but
it could be under #11 if we agree that 5-days for revocation is acceptable.
I'm also okay with tweaking the language to "demonstrated or proven method"
if you prefer, resulting in:

11. The CA is made aware of a demonstrated or proven method that exposes
the Subscriber's Private Key to compromise, methods have been developed
that can easily calculate it based on the Public Key (such as a Debian weak
key, see http://wiki.debian.org/SSLkeys), or if there is clear evidence
that the specific method used to generate the Private Key was flawed.

- Wayne

Doug
>
>
>
> *From:* Public <public-bounces at cabforum.org> *On Behalf Of *Doug Beattie
> via Public
> *Sent:* Thursday, August 23, 2018 1:38 PM
> *To:* Ryan Sleevi <sleevi at google.com>
> *Cc:* servercert-wg at cabforum.org; CABFPub <public at cabforum.org>
> *Subject:* Re: [cabfpub] [Servercert-wg] [EXTERNAL]Re: Ballot SC6 -
> Revocation Timeline Extension
>
>
>
> Exactly, let’s try to improve the language.
>
>
>
> If anyone has some better idea for how to replace this with the intended
> purpose, let’s hear it!
>
> “A Private Key is also considered compromised if methods have been
> developed that can easily calculate it based on the Public Key (such as a
> Debian weak key, see http://wiki.debian.org/SSLkeys) or if there is clear
> evidence that the specific method used to generate the Private Key was
> flawed.”
>
>
>
> Maybe:
>
> “a vulnerability has been exploited to disclose private keys”
>
>
>
> “there exist documented methods that can be used to easily extract and
> release Private Keys”  (we may need to define easily in terms of some
> measure of difficulty)
>
>
>
>
>
> Doug
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20180823/ccc23d85/attachment.html>