At 5:18 PM +0100 1/10/09, Ian G wrote: >>That I agree with, although I believe NIST's decisions will be a lot more >>important. (Disclaimer: I sometimes consult for NIST.) > > >Ahhh... no, please! Mozilla needs to do its own analysis. If it can't make >up its own mind about MDs, which are the simplest possible building block in >all of crypto, then what hope is there?
Where did I say Mozilla didn't need to do its own analysis? I said that NIST's will be more important. >>- Mozilla changes its rules for CAs in the trust anchor pile to say that they >>must not issue certificates with RSA-MD5 starting on some date (it could even >>be this year), and to say that sub-CAs cannot have their identities assured >>by RSA-MD5. This is a retroactive change to its acceptance policy in the pile. > > >I would argue that is already covered in the policy, because it has a clause >that says that CAs must follow the technical decisions of Mozilla. I don't >think we want to get into the rabbit hole of documenting all those >technicalities :) That's absurd. You can't hold a CA to doing something that we don't document. >>- CAs in the pile are required to send Mozilla a letter saying that they >>comply with all Mozilla policies, including this one. > >Sorry, what is the point of asking for them to say they will survive any >switch-off? They have actively signed an agreement that says they understand what we are demanding and will abide by it. This is no different than them applying to be in the trust anchor pile. >>- All CAs for which that letter has not been received by the date given in >>the new policy are removed from the pile. > > >Sorry, what's the point of invalidating all the CA's certs, as opposed to just >invalidating the MD5 certs? There is no reason to invalidate an end-entity cert that is signed with MD5. Doing so needlessly punishes end entities and relying parties and gains nothing in security. There *is* a reason to kick out CAs that do not follow Mozilla security and policy guidelines, of course: it's the same reason we would not have let them into the root pile in the first place. >>This puts the responsibility squarely where it belongs: on the CAs and on >>Mozilla's policy enforcement. No technical changes are needed, and it shows >>that Mozilla is willing to bring its policies up to date with modern security >>practice. It is also a test run for Mozilla updating its trust anchor >>policies in the future. > > >Well, maybe, but it also puts more weight on requiring the CAs to do business >level steps such as getting the CEO to sign the letter, getting the auditor to >agree, etc. Yes, that's what they are in the business to do. >This is mostly a technical level thing that can in most cases be sorted out at >a lower layer of communications; For most CAs, the technicians can turn off >MD5 without any need to discuss it because they already have the framework in >place. We could not disagree more. This is a policy issue: is the CA willing to follow Mozilla policies in order to stay in the root pile. Further, even if a "technicians can turn off MD5", you are ignoring all the MD5-based certs that they have already issued for which there is no security threat. >This is what happened at Verisign, they were 1 month (apparently) away from >dropping MD5 entirely, so they just advanced the timetable. No discussion >needed. Please re-read the paper that described the attack. The authors discussed the attack with all of the named CAs. "No discussion needed" is just plain naive. --Paul Hoffman _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
