On Fri, Jul 14, 2017 at 11:11 AM, Jakob Bohm via dev-security-policy < [email protected]> wrote:
> On 14/07/2017 15:53, Ryan Sleevi wrote: > >> On Fri, Jul 14, 2017 at 1:29 AM, Jakob Bohm via dev-security-policy < >> [email protected]> 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. > Sure, but that's unrelated to the discussion at hand, at least from what you've described. However, if I've misunderstood you, it might help if you rephrase the argument from what was originally being discussed - which is CAs issuing certificates for compromised keys - which are arguably distinct from weak keys (which was the point I was making). It sounds like you're saying "No, they're weak" - but I both acknowledged and refuted that interpretation in my message, so perhaps I simply do not understand the relation of what you're discussing above to the general issue Hanno raised. > 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 . > I'm afraid at this point, I'm completely lost as to the point you're trying to make. But at least 4.9.1.1 #3 requires them to revoke without waiting for a > new report. No, "it depends". And that was the point I was trying to make. > 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). I don't think you can or should ascribe bad faith here; my entire point was to highlight the possible interpretation issues - but to further highlight why the thing you call "patently bad faith" is itself fraught with peril, and thus it's reasonable to argue that it's not bad faith. If this is not desirable, we should strive to make it clearer - but that means acknowledging the edge cases, determining what is appropriate, and providing sufficient guidance so that, in the future, it might be more successfully argued as bad faith. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
