On 14/07/2017 15:53, Ryan Sleevi wrote:
On Fri, Jul 14, 2017 at 1:29 AM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
But that doesn't clearly include keys that are weak for other reasons,
such as a 512 bit RSA key with an exponent of 4 (as an extreme example).
Yes. Because that's clearly not necessary - because it's already covered by
4.9.1.1 #3 and 6.1.5/6.1.6. So I don't think this serves as a valid
criticism to the proposed update.
That's why I called it an "extreme example". Point was that the current
wording requires CAs to reject public keys that fail any reasonable test
for weakness not just the explicit cases listed in the BRs (such as too
short RSA keys or small composite public exponents).
For example if it is published that the RSA requirements in 6.1.6 are
insufficient (for example that moduli with more than 80% 1-bits are
weak), then the current wording of 6.1.1.3 would require CAs to
instigate such a test without waiting for a BR update.
Maybe it would be better stylistically to add this to one of the other
BR clauses.
Considering that the goal is to make it clearer, I'm not sure this
suggestion furthers that goal.
It could be in a new clause 6.1.1.3.1 (not applicable to SubCAs) or a
new clause 6.1.1.4 (applicable to all public keys, not just subscribers)
or a new clause 6.1.6.1 (ditto), or it could be added as an additional
textual paragraph in 6.1.1.3 or 6.1.6 .
Anyway, I think this is covered by BR 4.9.1.1 #3, although it might not
be obvious to the CA that they should have set up checks for this, since
most key compromise reports come from the subscriber, who would be a lot
less likely to make this mistake after revoking the key themselves,
except when the revocation was mistaken (this happens, and in that case,
reusing the key is not a big problem).
I'm afraid you may have misunderstood the point. Certainly, 4.9.1.1 #3
covers revocation. However, my suggestion was about preventing issuance,
which is why I was talking about 6.1.1.3. That is, unquestionably, if a CA
revokes a certificate for key compromise, then issues a new one for that
same key, they're obligated under 4.9.1.1 #3 to revoke within 24 hours. My
point was responding to Hanno's suggestion of preventing them from issuing
the second certificate at all.
But at least 4.9.1.1 #3 requires them to revoke without waiting for a
new report. And it would be obviously and patently bad faith to revoke
the same key every 24 hours and claim all is well (once or twice may be
an understandable oversight, since this is not such a common scenario,
but after that they should start automating the rejection/revocation).
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
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
