I believe that this is not only exactly what he is saying, but also exactly what must be done.
Once a "potentially problematic practice" is shown to have moved from "potential" to "actual", it is a problematic practice. Once that happens, it must be addressed. CAs fall into a class of security called "operational security". This means, among other things, that their operations -- inputs, black-box certification procedure, and outputs -- are subject to continual attack. Once a viable attack has been exhibited, mitigations against attack must be revisited with that attack in mind -- and if they are insufficient, new mitigations must be applied retroactively. (If an attack currently takes 8+ months to pull off, that just means that in less than 2 years it's going to take on the order of 4 months, in less than 2 years after that it's going to take on the order of 2 months, and in less than 2 years after that it's going to take on the order of 1 month -- assuming that there's no change in the understanding of the underlying mathematics. This is in keeping with the corollary to Moore's Law, that processing power doubles every 18 months, which lately seems to be maintained even in the face of heat problems inherent with doubling the number of transistors on a die.) Yes, this does mean that new requirements could require operational changes in some/all roots, or risk de-acceptance. If a CA's operations are not secure (due to input, processing, or output), how can anyone put any trust in them? -Kyle H On Mon, Jan 12, 2009 at 5:07 AM, Rob Stradling <rob.stradl...@comodo.com> wrote: > Eddy, I agree that the Potentially Problematic Practices wiki page is a useful > resource during the "information gathering period" that happens *before* a > Root Certificate is ever accepted by Mozilla. > > But (reading back a few messages in this thread), the context of this > discussion is Paul's proposal of a "retroactive change to its (Mozilla's) > acceptance policy in the pile" in order to curtail the use of MD5 by CAs who > have *already* been accepted by Mozilla. > > Are you saying that Mozilla could change the Potentially Problematic Practices > wiki page, and then use "non-compliance" to anything on that page as grounds > for pulling a previously approved Root Certificate from the trust pile? > > On Monday 12 January 2009 11:26:03 Eddy Nigg wrote: >> On 01/12/2009 01:08 PM, Rob Stradling: >> > Eddy, I apologize if I'm misinterpreting your response to Paul's last >> > comment, but I think you are suggesting that Mozilla could "hold a CA to >> > doing something" that is 'currently in the 'problematic practices'" wiki >> > page, purely because that wiki page is a document that is (you allege) >> > "presented to every CA for a while already". >> > >> > If that is what you are saying, I disagree with you. The wiki page >> > clearly says (capitalization mine)... >> > - "POTENTIALLY problematic CA practices". >> > - "we do NOT NECESSARILY consider them security risks". >> > - "Some of these practices MAY be addressed in future versions of the >> > policy". >> > >> > If Mozilla want to "hold a CA to doing something", then IMHO the first >> > step towards achieving this has to be to update the Mozilla CA >> > Certificate Policy to explicitly cover that "something". >> >> I absolutely agree with you and in my opinion this is what should be >> done - at least for some of those practices. However as I understand, >> not everything is every time clear so cut to make it a policy, hence >> there are problematic practices which are reviewed on a case-to-case >> basis for every CA individually. Confronting the CA with this page early >> on during the information gathering period makes the CA aware of >> potential problems during the process. This is what happened for a while >> now. I think that not every bit and byte must be listed in the policy, >> but by-laws may exists to assist the intend of the policy. >> >> Instead I think the policy should mention that such by-laws may exists - >> as matter of fact section 4 deals with it more or less. > > -- > Rob Stradling > Senior Research & Development Scientist > Comodo - Creating Trust Online > Office Tel: +44.(0)1274.730505 > Fax Europe: +44.(0)1274.730909 > www.comodo.com > > Comodo CA Limited, Registered in England No. 04058690 > Registered Office: > 3rd Floor, 26 Office Village, Exchange Quay, > Trafford Road, Salford, Manchester M5 3EQ > > This e-mail and any files transmitted with it are confidential and intended > solely for the use of the individual or entity to whom they are addressed. > If you have received this email in error please notify the sender by replying > to the e-mail containing this attachment. Replies to this email may be > monitored by Comodo for operational or business reasons. Whilst every > endeavour is taken to ensure that e-mails are free from viruses, no liability > can be accepted and the recipient is requested to use their own virus checking > software. > _______________________________________________ > dev-tech-crypto mailing list > dev-tech-crypto@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-tech-crypto > _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
