Re: CAs and external entities (resellers, outsourcing)
On Dec 31 2008, 12:27 am, Frank Hecker hec...@mozillafoundation.org wrote: Eddy Nigg wrote: I edited the Problematic Practices page and added https://wiki.mozilla.org/CA:Problematic_Practices#Delegation_of_Domai... It might need some improvement. Frank, can you review? This will affect obviously only future inclusion requests and is not a resolution to the current issue and other CAs which might be affected. I'm not totally happy with that language, but I'm supposed to be on vacation with my family and don't have time to rewrite it right now. I will say however that as a general matter I think it is good CA practice to have standard procedures and associated IT systems for verifying domain ownership/control and email account ownership/control, and to have resellers either use the CA's own systems or use CA-approved equivalents. (For example, reseller A might use the CA's own instances of such systems, while reseller B might run the same software but on its own systems.) One reason I say this is good CA practice as opposed to a mandatory requirement, is because of cases like enterprise PKIs where the enterprises might act as RAs and do verification based on their own internal systems (e.g., HR databases). Frank -- Frank Hecker hec...@mozillafoundation.org Frank, The Comodo topic has once again sparked a fierce discussion about the validity of certificates, how appropriate levels of security and trust should look like and what to do to establish them. Since we expect this discussion to have some impact on the evaluation of requests for Root integration (the current schedule appears not to be valid anymore) we wonder whether you can tell us something about your plans to work on that topic and what does that mean for all pending requests for integration?! Kind regards Wolfgang Pietrus ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: CAs and external entities (resellers, outsourcing)
On 01/12/2009 11:27 AM, wolfgang.piet...@t-systems.com: Frank, The Comodo topic has once again sparked a fierce discussion about the validity of certificates, how appropriate levels of security and trust should look like and what to do to establish them. Since we expect this discussion to have some impact on the evaluation of requests for Root integration (the current schedule appears not to be valid anymore) we wonder whether you can tell us something about your plans to work on that topic and what does that mean for all pending requests for integration?! Wolfgang, does your CA rely on RAs? It was my understanding IIRC that it is not the case. If the issues raised previously were addressed by you and the bug updated accordingly, than I don't think there should be any delay in continuing the schedule including the inclusion request of your CA. Frank, is there any reason why no inclusions (and relevant comments periods) aren't processed according to schedule? Is there any resolution pending which prevents us from doing so? -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: start...@startcom.org Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: CAs and external entities (resellers, outsourcing)
On Jan 12, 10:45 am, Eddy Nigg eddy_n...@startcom.org wrote: On 01/12/2009 11:27 AM, wolfgang.piet...@t-systems.com: Frank, The Comodo topic has once again sparked a fierce discussion about the validity of certificates, how appropriate levels of security and trust should look like and what to do to establish them. Since we expect this discussion to have some impact on the evaluation of requests for Root integration (the current schedule appears not to be valid anymore) we wonder whether you can tell us something about your plans to work on that topic and what does that mean for all pending requests for integration?! Wolfgang, does your CA rely on RAs? It was my understanding IIRC that it is not the case. If the issues raised previously were addressed by you and the bug updated accordingly, than I don't think there should be any delay in continuing the schedule including the inclusion request of your CA. Eddy, no we don't rely on external RAs (for services under the root we made our request for). Still we see that this discussion potentially will result in some work to change policies. If this is so, will requests be processed anyway during that time? Frank, is there any reason why no inclusions (and relevant comments periods) aren't processed according to schedule? Is there any resolution pending which prevents us from doing so? -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: start...@startcom.org Blog: https://blog.startcom.org Regards Wolfgang Pietrus ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: CAs and external entities (resellers, outsourcing)
On 31.12.2008 19:57, Frank Hecker wrote: Kyle Hamilton wrote: Ummm... has an enterprise PKI ever been included in Mozilla? Sorry, I wasn't being clear here. I'm not referring to enterprises that have their own root CAs. I was referring to schemes where enterprises work through CAs like VeriSign to issue certificates to their own employees, servers, etc. IIRC in a number of these schemes the CA is responsible for actually issuing the certificates but the validation is done by the enterprise. (For example, the CA might provide a web-based interface by which authorized representatives of the enterprise can submit previously-validated CSRs to the CA, and get back certificates in return.) In these cases the enterprises are essentially acting as RAs. I think this scenario is different, assuming it's implemented properly: The company would only be able to approve web server certs for their domain, i.e. it's like a wildcard cert. More importantly, they'd verify S/MIME email certs, but again only within their domain. I would consider this to be secure. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: CAs and external entities (resellers, outsourcing)
On 01/02/2009 06:55 PM, ro...@comodo.com: That thread has a lot going on and I don't propose to try to address it all. However, I will address your reading of our CPS in an attempt to bring some degree of clarity. If I correctly understood your referenced post, you asserted that: 1) Comodo outsources validation to its (non RA) resellers. 2) That the outsourcing of validation to anyone is in direct conflict with section 4.2.7 of the PositiveSSL CPS. Hi Robin, Thanks for your reply. In order to understand this a bit better, let me challenge and ask you some more questions. #1 is incorrect. You refer to section 1.10.2 of the main CPS as evidence for your assertion, but that section specifically refers to our main RA class of partners, which we denominate Web Host Resellers. OK, therefore Web Host Resellers are actually RAs. In the section 1.10.2 it says clearly: The Web Host Reseller Partner is obliged to conduct validation in accordance with the validation guidelines and agrees via an online process (checking the “I have sufficiently validated this application” checkbox when applying for a Certificate) that sufficient validation has taken place prior to issuing a certificate. So what you are saying is, that Web Host Resellers are actually RAs according to the CPS and are conducting the validations. How are those validations usually done - as per below? Which training do they receive usually? How do you select those RAs? Which subscriber agreement must be presented by the RA to the subscriber? Section 4.2 deals with application validation and in particular 4.2.2 explicitly mentions again (as also in the PositiveSSL CPS): Reviewing domain name ownership records publicly available through Internet approved global domain registrars and using generic e-mails which ordinarily are only available to person(s) controlling the domain name administration, for example, webmaster@ . . ., postmaster@ . . ., admin@; or Requesting documentation that verifies control of the domain. However it's not Comodo which performs those validations you say, but the RA (Web Host Reseller). Why isn't Comodo doing it through the same web interfaces available to the resellers? How exactly are documentation verified for control validation? How are you retaining evidence about the performed validations? How did the auditor review those validations? Sections 1.10, 2.2, 2.8, 3.9.3, 4.13.1, 5.15, 5.18, and 5.26 of the main CPS also further serve to define the interaction of RAs in the processing of certificate applications. What are the penalties in case an RA doesn't upheld the CPS and as per section 5.18? And a last question, where exactly are resellers handled in your CP/CPS? Thanks so far... -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: start...@startcom.org Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: CAs and external entities (resellers, outsourcing)
Kyle Hamilton wrote: Ummm... has an enterprise PKI ever been included in Mozilla? Sorry, I wasn't being clear here. I'm not referring to enterprises that have their own root CAs. I was referring to schemes where enterprises work through CAs like VeriSign to issue certificates to their own employees, servers, etc. IIRC in a number of these schemes the CA is responsible for actually issuing the certificates but the validation is done by the enterprise. (For example, the CA might provide a web-based interface by which authorized representatives of the enterprise can submit previously-validated CSRs to the CA, and get back certificates in return.) In these cases the enterprises are essentially acting as RAs. Frank -- Frank Hecker hec...@mozillafoundation.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: CAs and external entities (resellers, outsourcing)
On 12/31/2008 08:57 PM, Frank Hecker: employees, servers, etc. IIRC in a number of these schemes the CA is responsible for actually issuing the certificates but the validation is done by the enterprise. (For example, the CA might provide a web-based interface by which authorized representatives of the enterprise can submit previously-validated CSRs to the CA, and get back certificates in return.) In these cases the enterprises are essentially acting as RAs. And on the same token, the CA could perform the validation of the domain through said web interface. I'd see exception for whole IP blocks and batch submissions, whereas the IP block ownership and details of the batch submission have been validated by the CA manually beforehand. The enterprise scenario doesn't present a situation which would justify exemption of domain validation requirement. As per proposal it still would be possible though with appropriate attestation about the RAs capabilities and controls in place. -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: start...@startcom.org Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: CAs and external entities (resellers, outsourcing)
On 12/31/2008 12:30 PM, Rob Stradling: Yes, Reseller and RA are 2 distinct roles. However, in some cases, a single entity may choose (and be approved) to perform both of these roles. I fully agree that the Reseller role should not perform any validation procedures at all. Robin, could you provide some clarifications and your opinion concerning the post I made titled Facts about Comodo Resellers and RAs in particular in relation to the CP and CP statements here: http://groups.google.com/group/mozilla.dev.tech.crypto/msg/416aa6f5b5610ccf -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: start...@startcom.org Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: CAs and external entities (resellers, outsourcing)
Ian G wrote: Which language suggests they have to do verification *themselves* ? The fact that the policy talks about a CA, and I didn't see talk about external entities. BTW, it would be quite problematic to insist that the CAs do this job themselves. CAs are not generally experts on the issues raised. Traditionally, CAs outsource the processess within verification to a range of different organisations: government registries, commercial credit agencies, credit card companies, passport offices, birth registries, etc. That is, to insist they do it themselves would mean that they would have to develop skills that might be better handled elsewhere, and might in the end reduce to moving the deckchairs around. Yes, it seems reasonable that a CA relies on external sources of information like the ones you mention. If the CA has obtained information from registry offices like the above, the CA should be able to conclude verified on their own. It's a first hand decision. In my understanding, what we have experienced here was a second hand decision. Some external entity claimed to have done verification. The CA relied on that and treated it as sufficient. That's the bug. In my opinion, if a CA wants to delegate the decision about correctness of verification to an external party, they must verify the business practices of that external party, requiring the same sense of duty. And my proposal is, as part of this test, the external party should go through the same kind of audit that Mozilla requires for CAs. As I see verification as the core intention of the CA principle, I would have assumed above requirement is obvious to everyone, at least to CAs themselves. However, to turn it into a criteria or policy point, you would need to much more clearly refine your point, *and* you should clearly relate it to how this will improve security. I suggest this is much tougher than it sounds. I'm not talking about improving security. I want to ensure we forbid lowering of verification quality through the backdoor. My point is, we must find a way to ensure the purpose of the CA audit can not become void. We should forbid the practice to delegate the core of verification to external entities with unknown sense of duty. Kai smime.p7s Description: S/MIME Cryptographic Signature ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: CAs and external entities (resellers, outsourcing)
On 12/30/2008 03:24 PM, Kai Engert: As I see verification as the core intention of the CA principle, I would have assumed above requirement is obvious to everyone, at least to CAs themselves. One of Comodo's CPS (the one responsible for PositiveSSL) claims: To validate PositiveSSL and PositiveSSL Wildcard Secure Server Certificates, *Comodo* checks that the Subscriber has control. and the use of generic e-mails which ordinarily are only available to person(s) controlling the domain name administration, for example, webmaster@ . . ., postmaster@ . . ., admin@; However the general CPS says something else. See other thread Facts about Comodo Resellers and RAs. Nevertheless I believe that most CAs indeed take domain validation seriously. CAs must provide confirmation concerning that during inclusion requests. Comodo has not disclosed what I found now. As such there is no backdoor. -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: start...@startcom.org Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: CAs and external entities (resellers, outsourcing)
Eddy Nigg wrote: On 12/28/2008 01:13 PM, Kai Engert: The current Mozilla CA Certificate Policy says: 6. We require that all CAs whose certificates are distributed with our software products: ... provide attestation of their conformance to the stated verification requirements ... Kai, just to counter Ian's reply: The objective of the Mozilla CA policy is to provide sound, reliable and in this context reasonable security for its users. This is anchored clearly in the Mozilla Manifesto as a principal and further described and defined in the Mozilla CA Policy what PKI and CAs concerns. The Mozilla CA Policy is clear in its requirements, *intend* and what it is meant to achieve. All the rest is just throwing sand into ones eyes. In this respect section 7 of said policy clearly states what the requirements are. CAs may find different ways to achieve and conform to those requirements, however it should not lead to a compromise of those requirements. Personally I wouldn't outsource domain control validation but incorporate it into the general process of certificate issuance. In case it is delegated, the third party must provide attestation of their conformance. I think this is what you were proposing... Yes smime.p7s Description: S/MIME Cryptographic Signature ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: CAs and external entities (resellers, outsourcing)
On 12/30/2008 08:39 PM, Kai Engert: Eddy Nigg wrote: On 12/28/2008 01:13 PM, Kai Engert: The current Mozilla CA Certificate Policy says: 6. We require that all CAs whose certificates are distributed with our software products: ... provide attestation of their conformance to the stated verification requirements ... Kai, just to counter Ian's reply: The objective of the Mozilla CA policy is to provide sound, reliable and in this context reasonable security for its users. This is anchored clearly in the Mozilla Manifesto as a principal and further described and defined in the Mozilla CA Policy what PKI and CAs concerns. The Mozilla CA Policy is clear in its requirements, *intend* and what it is meant to achieve. All the rest is just throwing sand into ones eyes. In this respect section 7 of said policy clearly states what the requirements are. CAs may find different ways to achieve and conform to those requirements, however it should not lead to a compromise of those requirements. Personally I wouldn't outsource domain control validation but incorporate it into the general process of certificate issuance. In case it is delegated, the third party must provide attestation of their conformance. I think this is what you were proposing... I edited the Problematic Practices page and added https://wiki.mozilla.org/CA:Problematic_Practices#Delegation_of_Domain_.2F_Email_validation_by_third_parties It might need some improvement. Frank, can you review? This will affect obviously only future inclusion requests and is not a resolution to the current issue and other CAs which might be affected. -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: start...@startcom.org Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: CAs and external entities (resellers, outsourcing)
On 30/12/08 20:41, Eddy Nigg wrote: I edited the Problematic Practices page and added https://wiki.mozilla.org/CA:Problematic_Practices#Delegation_of_Domain_.2F_Email_validation_by_third_parties My comment: it is written like a requirement, using MUST. This is confusing, and it bypasses the process for change of policy. iang It might need some improvement. Frank, can you review? This will affect obviously only future inclusion requests and is not a resolution to the current issue and other CAs which might be affected. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: CAs and external entities (resellers, outsourcing)
On 12/30/2008 10:46 PM, Ian G: On 30/12/08 20:41, Eddy Nigg wrote: I edited the Problematic Practices page and added https://wiki.mozilla.org/CA:Problematic_Practices#Delegation_of_Domain_.2F_Email_validation_by_third_parties My comment: it is written like a requirement, using MUST. This is confusing, and it bypasses the process for change of policy. MUST was intentional. It's not policy, but anything in the problematic practices may be policy one day :-) -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: start...@startcom.org Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: CAs and external entities (resellers, outsourcing)
Eddy Nigg wrote: I edited the Problematic Practices page and added https://wiki.mozilla.org/CA:Problematic_Practices#Delegation_of_Domain_.2F_Email_validation_by_third_parties It might need some improvement. Frank, can you review? This will affect obviously only future inclusion requests and is not a resolution to the current issue and other CAs which might be affected. I'm not totally happy with that language, but I'm supposed to be on vacation with my family and don't have time to rewrite it right now. I will say however that as a general matter I think it is good CA practice to have standard procedures and associated IT systems for verifying domain ownership/control and email account ownership/control, and to have resellers either use the CA's own systems or use CA-approved equivalents. (For example, reseller A might use the CA's own instances of such systems, while reseller B might run the same software but on its own systems.) One reason I say this is good CA practice as opposed to a mandatory requirement, is because of cases like enterprise PKIs where the enterprises might act as RAs and do verification based on their own internal systems (e.g., HR databases). Frank -- Frank Hecker hec...@mozillafoundation.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: CAs and external entities (resellers, outsourcing)
On 12/31/2008 01:27 AM, Frank Hecker: One reason I say this is good CA practice as opposed to a mandatory requirement, is because of cases like enterprise PKIs where the enterprises might act as RAs and do verification based on their own internal systems (e.g., HR databases). I think this is what we want to avoid actually, don't we? Or perhaps we could leave it as is, since the Mozilla CA Policy is actually clear in relation to validations. Incidentally I had previously a problem with Microsoft's policy to disallowing certain enterprise scenarios, hereby it might make some sense. But even then, the proposal would actually call for an attestation, whereas the attestation itself hasn't been defined yet. I think this is what also Kay proposed. Now, we must not forget what an RA is, what a reseller is and what an enterprise scenario is. RAs are interesting for the verification and validation of identity documents in person for example. Or organizations for that matter. Since RAs always have to interact with the CA at some point, I believe incorporating domain/email validation is more than easy. Even in enterprise settings is that possible. Resellers should not perform any validation procedures at all. They should sell certificates and not be involved with any of the technical sides of he procedures. Reseller != RA. As such, I believe that it would be good to improve the Mozilla CA Policy and work towards better definitions and requirements. Even if the validation aspect is clearly defined and *required*, we might exclude certain practices outright. There are of course other points I'd like to have improved. -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: start...@startcom.org Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: CAs and external entities (resellers, outsourcing)
On 28.12.2008 12:13, Kai Engert wrote: From my perspective, it's a CA's job to ensure competent verification of certificate requests. The auditing required for CAs is supposed to prove it. The verification task is the most important task. All people and processes involved should be part of the assuring audit. The current Mozilla CA Certificate Policy says: 6. We require that all CAs whose certificates are distributed with our software products: ... provide attestation of their conformance to the stated verification requirements ... In my opinion, it means, a CA must do this job themselves. ... In my personal opinion, a CA violates the Mozilla CA Certificate Policy if they delegate the verification job to an external entity not owning attestation of their conformance to the stated verification requirements. Agreed. What *is* a CA? I thought it was a company that verifies that a certain entity is what it claims to be, it verifies identity. (Even that definition is much smaller than secure, which normal users assume, based on our own marketing of SSL = secure). The Certificate is merely the technical means to transmit the statement of verification. For that to work reliably, the CA also has to assure technical security of their systems. Based on that definition, which I think most people - even here and on sec-group - assumed to be true, the CA has to do all verifications itself. I think the Mozilla policy also implies that, by requiring the audits. I'd like to see the audit, because I cannot imagine that 7000 resellers were audited, and if any audit approved them all, it audit was useless and should be removed from our policy. Some people seem to now - by allowing Re define a CA as just a company that holds the private bits to a root cert that we distribute. That, IMHO, is a useless definition. In any case, Comodo has obviously failed to assure its processes. Frank Hecker asked what is needed to regain trust. It is the assurance of their processes, that this cannot happen again. For me, that means that Comodo does all verification *themselves*, and of course also the key signing. It is not possible to outsource that task, because it's where the trust relies. It's fine with me that they have resellers. However, they are just sellers, not do the verifications. As sales people/companies go, if you allow the real world comparison, they can recruit customers and collect money, but they do not do the core business, and they are not particularly trusted either. And, FWIW, I do not consider the fact that somebody paid via a certain credit card to be a sufficient verification, for the sake of SSL certs, that he really is that person. Nor when he can receive an email to webmas...@. (That might have been the verification process of Certstar: spam webmaster@ email addresses (as reed said in the bug), and if they react to that, obviously they must have read the webmaster@ email and therefore control the domain, which means the verification is already done. Yes, I'm cynical.) Please also read my following post about PositiveSSL specifically. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: CAs and external entities (resellers, outsourcing)
Kai Engert wrote: From my perspective, it's a CA's job to ensure competent verification of certificate requests. The auditing required for CAs is supposed to prove it. snip In my opinion, it means, a CA must do this job themselves. My quick personal perspective on this (and I'll apologize in advance to those of you for whom this is old news): It is long-standing practice in the CA industry to outsource certain verification-related tasks to third-party Registration Authorities. See for example the definition of an RA in an old IETF PKIX document: http://tools.ietf.org/html/draft-ietf-pkix-roadmap-09 Registration Authority (RA) - An optional entity given responsibility for performing some of the administrative tasks necessary in the registration of subjects, such as: confirming the subject's identity; **validating that the subject is entitled to have the values requested in a PKC [public key certificate]**; and verifying that the subject has possession of the private key associated with the public key requested for a PKC. [emphasis added] So IMO there is nothing inherently unusual or illegitimate in the fact that Comodo or other CAs have resellers acting as RAs and doing validation of domain control/ownership. However such RAs are acting as agents of the CA, and the CA has ultimate responsibility for ensuring that the RAs act to uphold the claims made in the CA's published CPS. As for attestation, in a typical WebTrust for CAs audit the management of the CA asserts that the CA is operating in accordance with the CPS, including whatever claims are made in the CPS vis-a-vis subscriber verification. For example, for Comodo these assertions are in the following document: http://www.comodo.com/repository/non_ev_management_assertions.pdf including the assertion that (during the period of the audit) Comodo maintained effective controls to provide reasonable assurance that ... subscriber information was properly authenticated, albeit with a disclaimer that There are inherent limitations in any controls, including the possibility of human error and the circumvention or overriding of controls. Accordingly, even effective controls can provide only reasonable assurance (Incidentally, this is fairly standard language for a WebTrust for CAs audit. All the WebTrust management assertions that I've read look like this.) The WebTrust for CAs auditors then examine and test these assertions in various ways, and make their own attestation. For example in the case of Comodo they stated in the relevant WebTrust for CAs report https://cert.webtrust.org/ViewSeal?id=798 that In our opinion for the period 1st April 2008 through to 31st July 2008, the Company’s Directors’ assertion, as set forth in the first paragraph, is fairly stated in all material respects, based on the AICPA/CICA WebTrust for Certification Authorities Criteria, although there's also a disclaimer: Because of inherent limitations in controls, errors or fraud may occur and not be detected (and also things may change in future). (Again, this is all pretty standard for a WebTrust for CAs audit report.) So, in theory at least a WebTrust for CAs audit is supposed to confirm management's assertions that verification of subscriber information is being done properly, including any verifications done by third-party RAs acting on behalf of the CA. In practice such confirmation is not necessarily based on doing detailed investigation of each and every RA; it might instead be based on examination of the overall controls put in place to regulate RAs, combined with any internal audits that CA managers might have done for RAs. In this respect I suspect that what Comodo has been and is doing is similar to what other CAs with RAs do. The policy currently does not appear to handle the scenario where a CA delegates the verification job to an external entity. So it's unclear whether it's forbidden or allowed if the external entity has received equivalent attestation of their conformance. When we created the policy I was well aware of the existence of RAs and of the possibility that CAs might outsource functions like domain validtion to RAs. Whether or not this is clear from the policy (and I guess it's not, since you and others are asking about this), my intention was certainly that the activities of RAs were considered to be encompassed within the overall activities of CAs, and that the policy's requirement for CAs to validate domains left open the possibility that this might be done by RAs acting as agents of CAs. So, to repeat, I don't think the key issue here is whether CAs should or should not be allowed to delegate domain validation to RAs. The question (e.g., as in the case of Comodo and Certstar) is rather whether particular RAs are doing this properly, and if it's not done properly, whether the failures on the part of RAs represent isolated incidents or whether they indicate a
Re: CAs and external entities (resellers, outsourcing)
On 12/29/2008 08:04 PM, Frank Hecker: When we created the policy I was well aware of the existence of RAs and of the possibility that CAs might outsource functions like domain validtion to RAs. Whether or not this is clear from the policy (and I guess it's not, since you and others are asking about this), my intention was certainly that the activities of RAs were considered to be encompassed within the overall activities of CAs, and that the policy's requirement for CAs to validate domains left open the possibility that this might be done by RAs acting as agents of CAs. Incidentally we've not long ago agreed that we'll have to look at the various RAs scenarios more closely in the future. There is a similarity between externally controlled sub CAs, RAs and apparently also Resellers, where resellers actually act as RAs (according to Comodo's CPS). As in the case of various other issues listed in the Problematic Practices pages [1], RAs will have to be defined more clearly as well. Something which was supposed to be obvious apparently isn't. As such, there are many common practices in this industry which are not up to today's requirements and/or the race to the bottom require clear regulation, something which previously maybe wasn't required. My insistence on detecting, declaring and defining them previously always had the goal to prevent possible damage and with it make PKI and digital certificates irrelevant for the Internet. Therefore, common practice by CAs never must be the criteria for sound and responsible requirements. So, to repeat, I don't think the key issue here is whether CAs should or should not be allowed to delegate domain validation to RAs. The question (e.g., as in the case of Comodo and Certstar) is rather whether particular RAs are doing this properly, and if it's not done properly, whether the failures on the part of RAs represent isolated incidents or whether they indicate a systemic failure of the CA to properly oversee its RAs. It's the inconvenience to have to confirm an email ping or other automated control verification by the subscriber which leads some CAs to circumvent it with agreement by checkbox validation. This results in an undue risk (being it just by human error and not intend or negligence) and unfair competition as well. I'd never outsource domain name validation to such identities like RAs and Resellers, not even for intermediate CAs. RAs may perform identity or organization validation sometimes more efficient than the CA due to local proximity, however technical requirements such as domain or email have no justification to be outsourced. Otherwise also physical and local controls and requirements will have to be added to the RA infrastructure, which makes it even more complicated. [1] http://wiki.mozilla.org/CA:Problematic_Practices -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: start...@startcom.org Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: CAs and external entities (resellers, outsourcing)
On 29/12/08 23:37, Kyle Hamilton wrote: This comment is likely going to be viewed as being in poor taste... It is rather on point. It is also likely to be viewed as poor taste :) Wasn't it a lack of regulation that managed to put the US and the rest of the world into this economic semi-meltdown that we're in? Wasn't it untrustworthy auditing (from Arthur Anderson) that led to the implementation of Sarbanes-Oxley and such? Enron was an early harbinger of over-dependence on simplistic signalling, and a consequent careful manipulation of that signalling by the players. Which lead to the failure of Arthur Anderson as a conspirator in that manipulation (are we properly following our document destruction policy?). Which then led to a call by the ignorant and the insiders, both, for increased regulation. Hello Sarbanes-Oxley. You will never find auditors willing to resist more complicated requirements for auditing, and you will not find the public resisting more calls for more checks. However, Sarbanes-Oxley (and about 6 others) added more complexity and further obscured signals, when the problem was already too much complexity and too little value in signals and too little effort by relying parties. (I dissemble here, for brevity.) According to my (very brief) checking, not one auditor signalled even one failure in the current meltdown. Yet, all of the failures were basic, finance-101 mistakes, easily described. Go figure... So, whatever. The USA is about to enter an enhanced, increased burden of regulation, in a time where we have just basically proved that the last round of regulation obscured the basic problems, and did nothing but increase the costs (basically, double, and the IPO market moved to London). It is *extremely helpful* to watch the world of regulated finance, when considering the world of CAs. The structure is basically the same, the only difference is that when we make a mistake, nobody notices; when they make a mistake, a million pensions are wiped out. iang ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: CAs and external entities (resellers, outsourcing)
On 29.12.2008 19:04, Frank Hecker wrote: So, in theory at least a WebTrust for CAs audit is supposed to confirm management's assertions that verification of subscriber information is being done properly, including any verifications done by third-party RAs acting on behalf of the CA. In practice such confirmation is not necessarily based on doing detailed investigation of each and every RA; it might instead be based on examination of the overall controls put in place to regulate RAs So, who actually controls that verifications are done at all? I mean, paper is nice, I can claim and write all I want, and not actually do it, but I thought the point of the audit was to *check* and control and ensure that the processes are *actually* carried out as specified. What else is an audit for? To get the CEO's signature that he claims to do what he wrote, or what? We don't need an audit for that, a scan of his signature would do. Verifications are the core of a CA's business, and the audit is there to control the CA's *actual* operations by an *independent* party, because it's exactly not sufficient to just trust the CA to do things properly, or to trust the CA that it trusts its RA, without ever actually checking it. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: CAs and external entities (resellers, outsourcing)
On 12/30/2008 04:04 AM, Ben Bucksch: So, who actually controls that verifications are done at all? I mean, paper is nice, I can claim and write all I want, and not actually do it, but I thought the point of the audit was to *check* and control and ensure that the processes are *actually* carried out as specified. What else is an audit for? To get the CEO's signature that he claims to do what he wrote, or what? We don't need an audit for that, a scan of his signature would do. Verifications are the core of a CA's business, and the audit is there to control the CA's *actual* operations by an *independent* party, because it's exactly not sufficient to just trust the CA to do things properly, or to trust the CA that it trusts its RA, without ever actually checking it. Apparently the auditors found a binding agreement sufficient enough for resellers to perform those validations. This, in addition to random checks and samples performed by the CA. The audit mostly confirms what the CP/CPS claims. This is most likely not what the Mozilla CA Policy envisioned and requires. As a matter of fact, we could have known about it and considered it insufficient during Comodo's review last spring. Unfortunately even if it came up in some form, it drowned by the other concerns which were on the table. We could re-read those discussions in order to find out. -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: start...@startcom.org Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: CAs and external entities (resellers, outsourcing)
On 12/30/2008 04:23 AM, Eddy Nigg: This is most likely not what the Mozilla CA Policy envisioned and requires. As a matter of fact, we could have known about it and considered it insufficient during Comodo's review last spring. Unfortunately even if it came up in some form, it drowned by the other concerns which were on the table. We could re-read those discussions in order to find out. Isn't this interesting? http://groups.google.com/group/mozilla.dev.tech.crypto/msg/fdbb981d7dcd678f -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: start...@startcom.org Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
CAs and external entities (resellers, outsourcing)
After having read the posts related to the unbelievable event, I understand the event involved an approved CA and an external entity they work with. From my perspective, it's a CA's job to ensure competent verification of certificate requests. The auditing required for CAs is supposed to prove it. The verification task is the most important task. All people and processes involved should be part of the assuring audit. The current Mozilla CA Certificate Policy says: 6. We require that all CAs whose certificates are distributed with our software products: ... provide attestation of their conformance to the stated verification requirements ... In my opinion, it means, a CA must do this job themselves. The policy currently does not appear to handle the scenario where a CA delegates the verification job to an external entity. So it's unclear whether it's forbidden or allowed if the external entity has received equivalent attestation of their conformance. In my personal opinion, a CA violates the Mozilla CA Certificate Policy if they delegate the verification job to an external entity not owning attestation of their conformance to the stated verification requirements. If we'd like to be strict, we could remove CAs from our approved list if they have shown to be non-conforming in the above way. In any case, the CA policy should get clarified about involving external entities in the verification and issueing process. All existing CAs should be required to make a statement about their current business practices with regards to external entities. After a grace period all CAs must either stop using external entities, or get conformance attestation for all involved entities. Kai smime.p7s Description: S/MIME Cryptographic Signature ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: CAs and external entities (resellers, outsourcing)
Hi Kai, long reply, I appreciate the grounding in actual policies and practices! This allows us to explore what we really can and cannot do. (I've cut two of your comments out to other posts where they might be generally intersting for the wider audience.) On 28/12/08 12:13, Kai Engert wrote: After having read the posts related to the unbelievable event, I understand the event involved an approved CA and an external entity they work with. Seems about right. From my perspective, it's a CA's job to ensure competent verification of certificate requests. The auditing required for CAs is supposed to prove it. [see other post] The verification task is the most important task. All people and processes involved should be part of the assuring audit. The current Mozilla CA Certificate Policy says: 6. We require that all CAs whose certificates are distributed with our software products: ... provide attestation of their conformance to the stated verification requirements ... OK! And, we can reasonably suggest that pt 7 covers verification, as per the above. In my opinion, it means, a CA must do this job themselves. No, to me, it means the CA must provide attestation of conformance by an independent party. That means they must show how they meet the things that Mozilla lists in pt 7. Which language suggests they have to do verification *themselves* ? BTW, it would be quite problematic to insist that the CAs do this job themselves. CAs are not generally experts on the issues raised. Traditionally, CAs outsource the processess within verification to a range of different organisations: government registries, commercial credit agencies, credit card companies, passport offices, birth registries, etc. That is, to insist they do it themselves would mean that they would have to develop skills that might be better handled elsewhere, and might in the end reduce to moving the deckchairs around. The policy currently does not appear to handle the scenario where a CA delegates the verification job to an external entity. So it's unclear whether it's forbidden or allowed if the external entity has received equivalent attestation of their conformance. I conclude it is allowed. However, whichever way it is done, the policy still insists that conformance to pt 7 is required. So, following that policy, a reasonable investigation to pursue in the current case is what that form of the attestation was, and how precise it was, etc. In my personal opinion, a CA violates the Mozilla CA Certificate Policy if they delegate the verification job to an external entity not owning attestation of their conformance to the stated verification requirements. I'm not sure I parse that, but I think you mean: If the CA delegates, and does not own the conformance requirement, then they have violated the policy. If so, ok. I see the following simplification: If the CA does not own the conformance to verification requirement, then they have violated the policy. If we'd like to be strict, we could remove CAs from our approved list if they have shown to be non-conforming in the above way. [see other post] In any case, the CA policy should get clarified about involving external entities in the verification and issueing process. There are normal business and PKI assumptions in operation here: The CA will involve external entities for as many things as possible. The CA will document the external entities. The CA will take responsibility for the result. (The CA will express its liability and warranty in its RPA.) It may be that you want to surface and state these assumptions. However, to turn it into a criteria or policy point, you would need to much more clearly refine your point, *and* you should clearly relate it to how this will improve security. I suggest this is much tougher than it sounds. E.g., Which external entities are OK? Why? How are they checked? Is it ok to accept an audit? Which audit? Where is the line drawn? Is a passport an outsourcing? If not, is a credit card? Is a website? Why consider external entities when we don't describe documents? If we care to regulate external entities, shouldn't we also regulate use of credit cards, which are known to be poor identity documents? Is one check enough? Two? Correlated? Serial or parallel? And add a thousand other questions. It gets complex! It is for this reason of complexity that we normally apply a reasonableness test. It is reasonable to use external entities, and as long as it is stated in the CPS, then it is up to each party to decide whether they accept that for their individual circumstances. (Those parties include: the CA, auditor(s), vendors, downstream vendors, relying parties, and ultimately end-users.) All existing CAs should be required to make a statement about their current business practices with regards to external
Re: CAs and external entities (resellers, outsourcing)
On 12/28/2008 01:13 PM, Kai Engert: The current Mozilla CA Certificate Policy says: 6. We require that all CAs whose certificates are distributed with our software products: ... provide attestation of their conformance to the stated verification requirements ... Kai, just to counter Ian's reply: The objective of the Mozilla CA policy is to provide sound, reliable and in this context reasonable security for its users. This is anchored clearly in the Mozilla Manifesto as a principal and further described and defined in the Mozilla CA Policy what PKI and CAs concerns. The Mozilla CA Policy is clear in its requirements, *intend* and what it is meant to achieve. All the rest is just throwing sand into ones eyes. In this respect section 7 of said policy clearly states what the requirements are. CAs may find different ways to achieve and conform to those requirements, however it should not lead to a compromise of those requirements. Personally I wouldn't outsource domain control validation but incorporate it into the general process of certificate issuance. In case it is delegated, the third party must provide attestation of their conformance. I think this is what you were proposing... -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: start...@startcom.org Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
