On 02/17/2012 06:28 AM, Chris Palmer wrote: > On 15 févr. 2012, at 13:37, Ondrej Mikle wrote: > >> For example, I've run into a dead-end when reporting yet-unknown >> certs with weak 512-bit keys with the right KU and EKU extensions for code >> signing to a CA > > A bit off-topic, but that's never stopped me before: We are working on > folding tests for basic sanity into Chrome (for example, we now reject < > 1024-bit RSA or DSA keys at run-time, and we reject weak signing algorithms). > Enforcing as many of the EV guidelines at run-time is also on our list. > > Other key- and certificate-using software should also incorporate what checks > are feasible and reasonable too. > > That doesn't really solve the problem of telling the owners of the weak > key/cert, but it does help users avoid the weaknesses at run-time. (And > that's a good way to suddenly start hearing from the people who issued the > 512-bit key...)
Great. IIRC Mozilla will do the switch in June/July (and some sort of cert-pinning is already built into the update mechanism). Now just to get Microsoft and Oracle onboard, since they use code-signing in Windows/Java respectively (maybe they already did the switch or announced a plan, but I haven't seen it yet.) Weak keys pop up all over the place, fortunately we already got many registrars to go through with rollover of weak < 1024-bit DNSSEC keys. (Strangely enough, I haven't seen yet a single debian-weak-key among the DNSSEC keys.) Ondrej
