Doug, On Thu, Aug 23, 2018 at 12:26 PM Doug Beattie <[email protected]> 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 <[email protected]> *On Behalf Of *Doug Beattie > via Public > *Sent:* Thursday, August 23, 2018 1:38 PM > *To:* Ryan Sleevi <[email protected]> > *Cc:* [email protected]; CABFPub <[email protected]> > *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 >
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
