On 2/12/2008 7:37 PM, Eddy Nigg (StartCom Ltd.) wrote: > Below my suggestions concerning a policy update or guidelines for CAs > which issue or have already external sub-ordinated CAs. This could be > also an extension to the Mozilla policy. Here is my initial take: > > Plain CAs: > > - Obligations and requirements of intermediate CAs shall be clearly > defined and described in the policy and practice statements of the CA root. > - The root CA must enforce compliance of said policies by intermediate CAs. > - The root CA must guaranty adherence to the minimum requirements of the > Mozilla CA policy by all issuing CAs in the PKI of the root. > - CAs which are operated by a government agency - or on behalf of a > government or local authority, who's sole purpose is the bootstrapping > of licensed CAs according to the respective local legislation shall not > apply for inclusion, instead the individual CAs in question shall make a > request for inclusion directly if they wish to do so. > - CAs which don't issue end-user certificates shall not apply for > inclusion, instead the intermediate CAs shall make a request for > inclusion directly if they wish to do so. > > EV CAs: > > - If the intermediate CAs are not audited (answer pending) according to > the EV guidelines I would suggest to find ways to guaranty adherence of > the EV guidelines. Possibly marking of the intermediate CAs as EV > instead of the roots. The purpose of this would be to make sure that > there won't be any "runaway" CAs which are chained to such an extend > that control over such sub ordinated CAs by the CA root would be highly > questionable or even impossible. > - Should auditing of intermediate CA certificates be required (and > included in the audit reports), no further addition has to be made to > the current policy, since this is already covered by the latest additions. > > > > I would also like to see an addition concerning physical (security) and > operational requirements to accepted industry standards (Yes, I know, > that sounds somewhat undefined). I have intentionally left out a > reference to name constraints for sub CAs. Feel free to add something in > that respect (I guess after confirming the current status of NSS etc...).
In the existing policy, I see only brief mention of removing a previously approved root certificate (the phrase "to discontinue including a particular CA certificate in our products" in the first sentence of Section 4). I think we need to expand upon that issue. Examples (plus "and other reasons") should be given for why an approved certificate loses its approval. The administrative process for removing a certificate should be described. For example, will a Bugzilla report be issued? How long a review should be tolerated between proposing the removal and the approval? To protect uses who still have versions of Mozilla products (and related products) with a removed certificate, the policy should provide for listing such certificates along with the reason for their removal. Both a permanent list on the Web and notices at both <news://news.mozilla.org:119/mozilla.announce> and <news://news.mozilla.org:119/mozilla.dev.tech.crypto> should be used. Perhaps the policy should authorize a press release. -- David E. Ross <http://www.rossde.com/> Go to Mozdev at <http://www.mozdev.org/> for quick access to extensions for Firefox, Thunderbird, SeaMonkey, and other Mozilla-related applications. You can access Mozdev much more quickly than you can Mozilla Add-Ons. _______________________________________________ dev-tech-crypto mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-crypto
