Eddy, Frank, See the comments of T-Systems (WP as an Acronym of my Name Wolfgang Pietrus) in the text below.
On Jul 20, 1:37 am, Eddy Nigg <[EMAIL PROTECTED]> wrote: > I started to review this inclusion request by reading parts of the > German version of the CP and CPS, which I understand is the only legal > document. The English version seems to be a draft only and perhaps not > legally binding. > > 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. Instead we are referred > to "contractual obligations" without defining what those obligations > are. Those obligations are not clearly defined anywhere as far as I > could see. This is a problem which has been pointed out here previously > and athttp://wiki.mozilla.org/CA:Problematic_Practices 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). We didn't see any sense about that, since we have made the experience that every enterprise (our customers) is doing the job of building and running a PKI a little bit different. We have to evaluate those circumstances for every request just like the Webtrust auditors. E&Y will perform ra-audits on a yearly basis. If they don't accept our subCAs, we will loose the certfication and can and should be removed from the Root store. Until then we think to be be compliant to this standard. If Mozilla wants to define its own criteria for subCAs, we are ready to modify our CP, CPS and in common our modus of operandi to comply to them. > > 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. > > I couldn't find any clear regulation in respect of the issuing and > maintaining of subordinated CAs which are themselves subordinated to the > T-Systems root. > > Validation of email addresses and domain names aren't clearly defined > (or I might have simply missed the relevant sections). 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. Instead CP/CPS of > the subordinated CAs are governing and regulating those aspects > according to > commenthttps://bugzilla.mozilla.org/show_bug.cgi?id=378882#c52and domain > ownership is commented with: > > "Checking for the ownership of the domain is part of the legal process > to come to a contract with those customers (It`s no big deal to examine > the ownership of the domain via the responsible NIC)" > > The "legal processes" are nowhere defined as far as I could find in the > CP/CPS nor are alternative minimum requirements concerning validations > clearly published. WP: see our previous comments... 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. 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. > > My input is by no means conclusive and perhaps Kathleen or a > representative of T-Systems can point me to the relevant sections of > their CP/CPS. I reserve the right to raise additional questions during > the comments period should I find anything which should be cleared > before continuing. > 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. Best Regards Wolfgang Pietrus T-Systems Enterprise Services GmbH [EMAIL PROTECTED] > -- > 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
