On 14/07/2017 21:04, Ryan Sleevi wrote:
On Fri, Jul 14, 2017 at 2:07 PM, Jakob Bohm via dev-security-policy <
[email protected]> wrote:
That's my point. The current situation is distinct from weak keys, and
we shouldn't sacrifice the weak keys BR to make room for a compromised
keys BR.
But a weak key is always suspected of having suffered a Key Compromise - is
it not?
That is, changing to from "weak keys" to "suspected or known to have
suffered Key Compromise" in 6.1.1.3 would fully include weak keys (which
are already in scope) as well as include those excluded (compromised,
strong). This applies in addition to the requirements already present in
6.1.5/6.1.6 regarding key sizes and strengths (which already counter your
hypothetical), and 4.9.1.1/4.9.1.2 address the situation if a strong key,
post issuance, becomes either weak or compromised.
I would say a key whose strength against attack is significantly below
that of normally accepted keys (say 256 times less work factor with the
best known attack) would be a weak key, even though that might still
require a year or more on the best known hardware at fort Meade.
A suspected key compromise is a higher degree of badness (say > 0.01%
chance that attackers will have the key now or in the next 72 hours).
Heartbleed, Debian weak keys or leaving the private key in a public
place would be suspected or actual key compromise, because attackers may
have already gotten the private key using a known attack and almost
trivial effort, and there is no way to tell.
A 2048 bit RSA key which somehow has only the cryptographic strength
normally associated with a 1536 bit RSA key would be a weak key, but
still unlikely to be cracked within a few weeks of revealing the public
key. And since an actual 1536 bit RSA key would be too weak to allow
issuance under BR 6.1.5, issuing a new certificate issued to such a
"special form" 2048 bit RSA key would be reasonably considered against
6.1.1.3 .
Now we obviously don't know the nature of yet-to-be-published
cryptanalytical attacks, but if a new attack applies to only some keys,
and those keys can be identified from the public keys, similar to how
there is currently a formula for detecting "weak SHA-1" hashes, then CAs
should apply that formula in a pre-issuance test under 6.1.1.3, but
would not require instant revocation of all such keys under 4.9.1.2 #3,
though CA subscribers would be encouraged to voluntarily reissue and
revoke such keys as they are spotted by e.g. Qualsys SSL checks or
database scans by the CA.
P.S.
The classical example of "weak keys" is of cause the special forms of
DES symmetric keys that were known 30 years ago, at a time when cracking
regular full DES keys was still beyond most attackers.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
