[EMAIL PROTECTED]: > Eddy, Frank, > > See the comments of T-Systems (WP as an Acronym of my Name Wolfgang > Pietrus) in the text below.
Hallo Wolfgang, Vielen Dank fuer Ihre Antwort :-) >> >> Nevertheless I read mostly the English version which is easier to >> understand. Similar to Kathleen's comment >> athttps://bugzilla.mozilla.org/show_bug.cgi?id=378882#c46I had difficulty >> to come to positive conclusion concerning their handling of sub >> ordination CAs and about the validation methods this CA requires. Some >> has been answered in the bug, however the CP/CPS is not clear at all in >> that respect and basically the concerns raised by Kathleen haven't been >> addressed. >> >> Subordinate CAs may be external to T-Systems and as I understand not >> part and covered by the audit performed by E&Y. > > WP: Yes, subordinate CAs may be external to T-Systems. Nevertheless > they are part of the audit in that way, that the auditor did prove our > process to register and issue subordinate CAs. Still this is common > business among trustcenter service providers. Can you point me to the relevant sections at the CP/CPS which describes the obligations of those CAs concerning issuing of intermediate CA certificates, their obligations concerning issuing of end user certificates and the relevant validation requirements of all the CA certificates under your root? It might be common business practice to issue intermediate CA certificates, but it's also common practice to define the requirements and obligations of those CAs and how they are governed, including the auditing of those CAs which operate under a certain root. For more information see also http://wiki.mozilla.org/CA:Problematic_Practices#Allowing_external_entities_to_operate_unconstrained_subordinate_CAs BTW, intermediate CA certificates are many times issued, operated, regulated and governed by the very same CA and all CA certificates are effectively controlled by the relevant CP/CPS and same public key infrastructure. > WP: It is true, that the CP does not maintain a detailed list of > obligations for external SubCAs (besides the obligation that they must > comply to all rules within the CP). OK, this is a very important statement! As you confirm, the external CAs must adhere to your CP, but the CP doesn't define those requirements and obligations. This is the actual issue I'm touching here. The CP is a legally binding document which is public and which the auditor has to confirm (amongst other things). As a relying third party (which includes Mozilla and all its users), this is the document we have to rely on. >> Apparently subordinated CAs maintain their own sets of subordinated CA >> certificates - despite the illustrations and descriptions and comments >> telling us otherwise, or the term of root CAs is interpreted differently >> in the CPS and are actually subordinated CAs. Anyway, that's what I >> found out after visiting the suggested URL in comment 52 of bug >> 378882:https://www.pki.dfn.de/ > > WP: It is true: Those images and the text don't show explicitly the > possibilities of an hierarchical CA structure. Nevertheless the > certificate profile in chapter 7.1.1.2 shows PathLenConstraint = 5, > which should make this clear. OK, this shows that the chain can be extended for up to five subordinated CAs. How are those regulated and governed? Can an external CA issue another subordinated CA certificate to another external entity? What are the obligations of those CAs? How will they validate domains, emails and identities? How will E&Y audit them? Please note that the audit requirement of the Mozilla CA policy doesn't fall only on the CA root, but on all issuing CAs within the same root. > WP: The CP mentions the requirement, that all data that are part of a > certificate have to be validated by a RA and that those date have to > enable a unique identification. How this can be accomplished, should > be defined be the CPS of the Subordinated CAs that issue user > certifates or other entity certificates. If someone comes up with a > method for evaluating certificate requests, that applies to most of > the enterprises of at least Germany and can be considered feasible, we > will be glad to define this method as mandatory. Until then we prefer > to discuss this issue with our customers directly and evaluate their > methods. I think that we also would like to know about it. I would like to know if the validation procedures conform to the Mozilla CA policy and I'd like to know where in your CP and practice statements I can understand what those requirements are. > > I haven't seen any CP/CPS of sub CAs which regulates >> those aspects nor were they examined by Mozilla so far. Nor could I find >> how IP address handled, which domain names are acceptable or anything >> with relevance in that respect (hostnames, wild cards, IP addresses, >> FQDN etc). > > WP: We consider those issues not to be part of the Root CP or CPS. In > our opinion the Root defines the policies, but not the methods for the > SubCAs. This is acceptable, however in that case I think we must evaluate those CA policies of the issuing CA. CAs through root proxies are very problematic and circumvent directly and effectively the audit requirements of the Mozilla CA policy. Additionally, the point I raised above are very important aspects of the Mozilla CA policy! > > The same applies for email address verification. Neither have >> I found how identities and organizations are validated, which might be >> relevant for code signing certificates. > > WP: Not only for code signing. Still: How the evaluation of data > within certificate requests is being performed in detail should be > part of a CPS of the issuing CA, but not of the Root. > If I would want to check the trustlevel of a certificate I would read > the CPS of the issuing CA first, and then evaluate the chain up to the > Root. Yes, and in this case I suggest that the issuing CAs should apply for inclusion at Mozilla directly! As it has been the case with other CA requests in the past, where the root CA has limited functions and/or requirements on part of the CA which are actually the functioning CAs and are effectively a CA and different entity in their own right and where their CA and public key infrastructure (including physical) has NOT been audited, I tend to recommend to Frank to refrain from including T-Systems CA root certificate until either the issues raised have been addressed and/or the issuing CAs themselves requested inclusion and have been evaluated accordingly. > > WP: We think, that a CP of a Root should not be to specific in > defining methods, how policies should be implemented. > Nevertheless: If this discussion leads (Frank) to the conclusion, that > we should make an update on our CP, we will do that. > -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Blog: https://blog.startcom.org _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
