Re: Symantec: Next Steps
On 24/03/2017 21:03, Jakob Bohm wrote: On 24/03/2017 19:08, Ryan Sleevi wrote: On Fri, Mar 24, 2017 at 1:30 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: Examples discussed in the past year in this group include the Taiwan GRCA roots and several of the SubCAs hosted by Verizon prior to the DigiCert transition. Apologies for not remembering, but I don't recall the relationship of either of those discussions to what you described. However, it's very easy I'm wrong. Could you link to the threads (ideally, the messages) you believe that captures this description, so that I can better understand? For Taiwan GRCA (Government Root CA) apparently operated by Chungwa Telecom, this seems most obvious from: Message-ID:Date: Sat, 3 Dec 2016 00:34:12 -0800 (PST) From: lcchen.ci...@gmail.com Subject: Re: Taiwan GRCA Root Renewal Request For the Verizon rooted tree of multiple CAs, some hosted by Verizon, some not, look at the long report that is: Message-ID: Date: Thu, 3 Nov 2016 18:28:10 + From: Jeremy Rowley Subject: Update on transition of the Verizon roots and issuance of SHA1 certificates Peter is correct, we discussed something slightly different, so apologies for misunderstanding what you were proposing versus what we discussed. It sounds like what you're describing is what we discussed (white-label), except the person signing the management assertion is also acting as a Delegated Third Party for validation. However, because they're the ones signing the assertion, they're the ones in scope for the audit presented to root stores - correct? On this second point, there really should be two signed management assertions and two public audit reports: One for the "CA Operator", who needs to comply with every bit of the BR, security and root program policy requirements. The "CA Operator" must have a CP/CPS for the CA which is verbatim identical to the one provided by the "CA Owner" and part of the audited CA Operation. In practice, this would often be a "master" assertion and audit for all the CAs hosted by that "CA Operator". One for the "CA Owner", who needs to have a compliant CP/CPS, outsource to a compliant "CA Operator", meet "Delegated Third Party" audit requirements for any self-performed functions and provide a management assertion and other evidence that they don't interfere with the compliance of the "CA Operator" for their CA(s). Both parties would have audit reports etc. submitted to the root programs. Such a double auditing process would solve most of the problems commonly caused (according to others) by auditors only dealing with one of the two parties and the other one falling through the cracks. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec: Next Steps
On 24/03/2017 19:08, Ryan Sleevi wrote: On Fri, Mar 24, 2017 at 1:30 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: Examples discussed in the past year in this group include the Taiwan GRCA roots and several of the SubCAs hosted by Verizon prior to the DigiCert transition. Apologies for not remembering, but I don't recall the relationship of either of those discussions to what you described. However, it's very easy I'm wrong. > Could you link to the threads (ideally, the messages) you believe that > captures this description, so that I can better understand? > For Taiwan GRCA (Government Root CA) apparently operated by Chungwa Telecom, this seems most obvious from: Message-ID:Date: Sat, 3 Dec 2016 00:34:12 -0800 (PST) From: lcchen.ci...@gmail.com Subject: Re: Taiwan GRCA Root Renewal Request For the Verizon rooted tree of multiple CAs, some hosted by Verizon, some not, look at the long report that is: Message-ID: Date: Thu, 3 Nov 2016 18:28:10 + From: Jeremy Rowley Subject: Update on transition of the Verizon roots and issuance of SHA1 certificates Peter is correct, we discussed something slightly different, so apologies for misunderstanding what you were proposing versus what we discussed. It sounds like what you're describing is what we discussed (white-label), except the person signing the management assertion is also acting as a Delegated Third Party for validation. However, because they're the ones signing the assertion, they're the ones in scope for the audit presented to root stores - correct? Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec: Next Steps
On Fri, Mar 24, 2017 at 1:30 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Examples discussed in the past year in this group include the Taiwan > GRCA roots and several of the SubCAs hosted by Verizon prior to the > DigiCert transition. Apologies for not remembering, but I don't recall the relationship of either of those discussions to what you described. However, it's very easy I'm wrong. Could you link to the threads (ideally, the messages) you believe that captures this description, so that I can better understand? Peter is correct, we discussed something slightly different, so apologies for misunderstanding what you were proposing versus what we discussed. It sounds like what you're describing is what we discussed (white-label), except the person signing the management assertion is also acting as a Delegated Third Party for validation. However, because they're the ones signing the assertion, they're the ones in scope for the audit presented to root stores - correct? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec: Next Steps
On 24/03/2017 17:12, Peter Bowen wrote: On Fri, Mar 24, 2017 at 9:06 AM, Ryan Sleevi via dev-security-policywrote: (Wearing an individual hat) On Fri, Mar 24, 2017 at 10:35 AM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: One common scenario that a new wording should allow is a "fully outsourced CA", where all the technical activities, including CA private key storage, CRL/OCSP distribution, ensuring policy compliance and domain/IP validation are outsourced to a single entity which is fully audited as a CA operator, while the entity nominally responsible for the CA acts more like an RA or reseller. Can you highlight why you believe this is a common scenario? During that same conversation, only one party was identified that meets such a definition, and CAs otherwise did not highlight any of their customers or awareness of others. To be fair, we didn't discuss this scenario. The scenario raised was that CompanyX outsources _all_ CA activities to CompanyY except for approving CPS changes, writing the management assertion, and marketing the certificates. What I believe Jakob is describing is one step less, where CompanyY does some of the validation steps. Examples discussed in the past year in this group include the Taiwan GRCA roots and several of the SubCAs hosted by Verizon prior to the DigiCert transition. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec: Next Steps
On Fri, Mar 24, 2017 at 9:06 AM, Ryan Sleevi via dev-security-policywrote: > (Wearing an individual hat) > > On Fri, Mar 24, 2017 at 10:35 AM, Jakob Bohm via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: >> >> One common scenario that a new wording should allow is a "fully >> outsourced CA", where all the technical activities, including CA >> private key storage, CRL/OCSP distribution, ensuring policy compliance >> and domain/IP validation are outsourced to a single entity which is >> fully audited as a CA operator, while the entity nominally responsible >> for the CA acts more like an RA or reseller. >> > > Can you highlight why you believe this is a common scenario? During that > same conversation, only one party was identified that meets such a > definition, and CAs otherwise did not highlight any of their customers or > awareness of others. To be fair, we didn't discuss this scenario. The scenario raised was that CompanyX outsources _all_ CA activities to CompanyY except for approving CPS changes, writing the management assertion, and marketing the certificates. What I believe Jakob is describing is one step less, where CompanyY does some of the validation steps. Thanks, Peter ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec: Next Steps
(Wearing an individual hat) On Fri, Mar 24, 2017 at 10:35 AM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > One common scenario that a new wording should allow is a "fully > outsourced CA", where all the technical activities, including CA > private key storage, CRL/OCSP distribution, ensuring policy compliance > and domain/IP validation are outsourced to a single entity which is > fully audited as a CA operator, while the entity nominally responsible > for the CA acts more like an RA or reseller. > Can you highlight why you believe this is a common scenario? During that same conversation, only one party was identified that meets such a definition, and CAs otherwise did not highlight any of their customers or awareness of others. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec: Next Steps
On 24/03/2017 10:56, Gervase Markham wrote: On 07/03/17 11:37, Gervase Markham wrote: Here are some proposals for policy change. Please do comment on these or suggest others. I can report that at the CAB Forum face-to-face in Raleigh, NC, USA this week, there was broad consensus to draw up a ballot which prevents CAs from (to summarise broadly) outsourcing BR 3.2.2.4 and 3.2.2.5 - domain name and IP address ownership - validation to third parties, and that this restriction would be enacted at the level of the BRs, not the level of Mozilla policy. So I will be working with interested parties from the Forum to draft some wording that achieves that, as there are various cases to consider to make sure we don't forbid certain common and secure activities by accident. One common scenario that a new wording should allow is a "fully outsourced CA", where all the technical activities, including CA private key storage, CRL/OCSP distribution, ensuring policy compliance and domain/IP validation are outsourced to a single entity which is fully audited as a CA operator, while the entity nominally responsible for the CA acts more like an RA or reseller. That "CA operator" might be an actual related CA in good standing, or might be a professional company created solely for doing this job for other CAs (such as the private companies that run some government CAs around the world). For the "fully outsourced CA" scenario, the things that a normal CA cannot outsource to a third party would in this case not be allowed to be "insourced" from the "CA operator" to the nominally responsible organization. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec: Next Steps
On 07/03/17 11:37, Gervase Markham wrote: > Here are some proposals for policy change. Please do comment on these or > suggest others. I can report that at the CAB Forum face-to-face in Raleigh, NC, USA this week, there was broad consensus to draw up a ballot which prevents CAs from (to summarise broadly) outsourcing BR 3.2.2.4 and 3.2.2.5 - domain name and IP address ownership - validation to third parties, and that this restriction would be enacted at the level of the BRs, not the level of Mozilla policy. So I will be working with interested parties from the Forum to draft some wording that achieves that, as there are various cases to consider to make sure we don't forbid certain common and secure activities by accident. This would be stronger than and therefore supercede: > Policy Proposal 1: require all CAs to arrange it so that certs validated > by an RA are issued from one or more intermediates dedicated solely to > that RA, with such intermediates clearly labelled with the name of the > RA in the Subject. Other forms of validation will continue to be outsourceable. Mozilla does not recognise OV certificates, but when it comes to EV, we do need to make sure that any outsourcing is properly audited and those audit findings are properly communicated. How we do this remains an open and difficult question; however, domain/IP ownership validation is so core to a CA's activity that it seems wise to remove it from the scope of this wider problem by banning outsourcing it outright. I will take up the topic of possible action against Symantec in the other thread. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec: Next Steps
On 16/03/17 13:15, Ryan Sleevi wrote: > Or, put differently, it sounds as if you suggest the only obligation a CA > has to ensure their DTP auditors are qualified for the task at hand is if, > and only if, Mozilla requests those audits. In the absence of that request, > the CA is allowed to make their own individual determination. Further, it > seems that you are suggesting that if a CA makes that determination, and > it's incorrect, that's not a failure upon the CAs part, because they made > 'a decision', and the relevant portions of Mozilla policy only apply to the > 'next' audit. I am saying that, however, undesirable, our current policy could be interpreted this way, which is why I want to change it. You don't have to convince me that this situation is undesirable :-) Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Symantec: Next Steps
We have DTP and RA roles slated as part of the validation WG discussion, but only as they relate to validation. -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla .org] On Behalf Of Ryan Sleevi via dev-security-policy Sent: Thursday, March 16, 2017 7:16 AM To: Gervase Markham <g...@mozilla.org> Cc: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Symantec: Next Steps On Thu, Mar 16, 2017 at 6:01 AM, Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 09/03/17 13:32, Ryan Sleevi wrote: > > (Wearing Google hat only for this statement) Have you considered > > having this discussion in the CA/Browser Forum? > Google > > had planned to discuss this very topic at our upcoming F2F about how > > to address this, and would be very interested in collaborating with > > Mozilla > on > > this. I mentioned this recently to Kathleen at the WebTrust TF > > meetings, but apologies for not mentioning to you as well. > > This sounds like a good idea. Do we want to get this added in an open > slot? There may still be time. > Unconference future discussion. If CAs aren't interested in it, and it doesn't get discussed, then that seems like a suitable signal to discuss in the browser policies, doesn't it? > > I don't understand why you > > believe it's relevant the act of "Mozilla requiring disclosure of > > the audits". Can you help me understand where, in the policy, that's > required? > > I'm not sure where your text in quotes comes from, and nor can I work > out the referent of "it", so I don't understand this question. > The quoted text was attempting to summarize the following paragraph from you: """No, because in the case of a sub-CA, we require audits. And when we receive them, if they were done by unqualified parties, the CA would need to flag that, and we would make a judgement about that party's suitability at the time. The issue here arises that, because of the way things are set up, these RA's audits were not submitted to Mozilla, and so Symantec didn't have to resolve the Schrodinger's Cat of (qualified|not qualified and need us to make a judgement).""" The question here is that it seems you have hinged the acceptability/unacceptability of the auditor on the basis of whether or not it was required to be disclosed. Or, put differently, it sounds as if you suggest the only obligation a CA has to ensure their DTP auditors are qualified for the task at hand is if, and only if, Mozilla requests those audits. In the absence of that request, the CA is allowed to make their own individual determination. Further, it seems that you are suggesting that if a CA makes that determination, and it's incorrect, that's not a failure upon the CAs part, because they made 'a decision', and the relevant portions of Mozilla policy only apply to the 'next' audit. In effect, it makes the question of 'qualified' auditor one which can never look retrospectively to prevent issues or instill a duty of care, and it only applies forward thinking, to the 'next' audits. Or, put differently, it sounds as if you're suggesting that Symantec, having made a determination of qualified without input from Mozilla, has sufficiently abided by Mozilla's policy. I'm not sure that's a consistent read with the goals or policy stated. Rather, by making that determination without input from Mozilla, Symantec has instead taken on full liability for that audit. If, as in this case, evidence appears that suggests the auditor is not qualified, then the root issue rests with Symantec for not ensuring that the auditor was qualified. Similarly, all other CAs who are accepting audits from third-parties (whether DTPs or sub-CAs), and which are not ensuring those meet the definition of qualified, similarly accept risk of violation. That risk can be mitigated - for example, showing that the auditor is appropriately licensed at the time they conducted the audit, rejecting audits that are clearly problematic - but it's a risk born through exercising the capability to delegate. Put one last way (since this is such a thorny issue), I read your reply in the above quoted text to say "Mozilla requires that the CA make a decision. But it doesn't have to be a right one, and it doesn't have to use the same data we would." I'm trying to push back on that, which is every CA has an obligation to make the Right Decision - they have the tools at their disposal to do so, but uncertainty or perceived risk can and should only be mitigated by public consultation before - not after. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy smime.p7s
Re: Symantec: Next Steps
On Thu, Mar 16, 2017 at 6:01 AM, Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 09/03/17 13:32, Ryan Sleevi wrote: > > (Wearing Google hat only for this statement) > > Have you considered having this discussion in the CA/Browser Forum? > Google > > had planned to discuss this very topic at our upcoming F2F about how to > > address this, and would be very interested in collaborating with Mozilla > on > > this. I mentioned this recently to Kathleen at the WebTrust TF meetings, > > but apologies for not mentioning to you as well. > > This sounds like a good idea. Do we want to get this added in an open > slot? There may still be time. > Unconference future discussion. If CAs aren't interested in it, and it doesn't get discussed, then that seems like a suitable signal to discuss in the browser policies, doesn't it? > > I don't understand why you > > believe it's relevant the act of "Mozilla requiring disclosure of the > > audits". Can you help me understand where, in the policy, that's > required? > > I'm not sure where your text in quotes comes from, and nor can I work > out the referent of "it", so I don't understand this question. > The quoted text was attempting to summarize the following paragraph from you: """No, because in the case of a sub-CA, we require audits. And when we receive them, if they were done by unqualified parties, the CA would need to flag that, and we would make a judgement about that party's suitability at the time. The issue here arises that, because of the way things are set up, these RA's audits were not submitted to Mozilla, and so Symantec didn't have to resolve the Schrodinger's Cat of (qualified|not qualified and need us to make a judgement).""" The question here is that it seems you have hinged the acceptability/unacceptability of the auditor on the basis of whether or not it was required to be disclosed. Or, put differently, it sounds as if you suggest the only obligation a CA has to ensure their DTP auditors are qualified for the task at hand is if, and only if, Mozilla requests those audits. In the absence of that request, the CA is allowed to make their own individual determination. Further, it seems that you are suggesting that if a CA makes that determination, and it's incorrect, that's not a failure upon the CAs part, because they made 'a decision', and the relevant portions of Mozilla policy only apply to the 'next' audit. In effect, it makes the question of 'qualified' auditor one which can never look retrospectively to prevent issues or instill a duty of care, and it only applies forward thinking, to the 'next' audits. Or, put differently, it sounds as if you're suggesting that Symantec, having made a determination of qualified without input from Mozilla, has sufficiently abided by Mozilla's policy. I'm not sure that's a consistent read with the goals or policy stated. Rather, by making that determination without input from Mozilla, Symantec has instead taken on full liability for that audit. If, as in this case, evidence appears that suggests the auditor is not qualified, then the root issue rests with Symantec for not ensuring that the auditor was qualified. Similarly, all other CAs who are accepting audits from third-parties (whether DTPs or sub-CAs), and which are not ensuring those meet the definition of qualified, similarly accept risk of violation. That risk can be mitigated - for example, showing that the auditor is appropriately licensed at the time they conducted the audit, rejecting audits that are clearly problematic - but it's a risk born through exercising the capability to delegate. Put one last way (since this is such a thorny issue), I read your reply in the above quoted text to say "Mozilla requires that the CA make a decision. But it doesn't have to be a right one, and it doesn't have to use the same data we would." I'm trying to push back on that, which is every CA has an obligation to make the Right Decision - they have the tools at their disposal to do so, but uncertainty or perceived risk can and should only be mitigated by public consultation before - not after. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec: Next Steps
On 08/03/17 15:06, Peter Bowen wrote: > By eliminating the DTP option, you will massively raise costs for CAs > that rely upon local translators and information gatherers. I think a > much better proposal would be to require the CA perform the RA > activity contemplated by BR 3.2.2.4 and 3.2.2.5 and restrict DTPs to > Subject Identity Information validation. Let's call that "Policy Proposal 5" :-) I think that if we did this, it might still make sense to enact Policy Proposal 1. I believe that would have the side effect of making sure we get all the audits. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec: Next Steps
On 09/03/17 13:32, Ryan Sleevi wrote: > (Wearing Google hat only for this statement) > Have you considered having this discussion in the CA/Browser Forum? Google > had planned to discuss this very topic at our upcoming F2F about how to > address this, and would be very interested in collaborating with Mozilla on > this. I mentioned this recently to Kathleen at the WebTrust TF meetings, > but apologies for not mentioning to you as well. This sounds like a good idea. Do we want to get this added in an open slot? There may still be time. > I'm not sure that we can or should so easily dismiss this with a suggestion > that we're dancing on the head of a pin here. That's not quite what I'm saying; I'm saying that my position could be seen as that (making very fine distinctions), and it possibly is. > I don't understand why you > believe it's relevant the act of "Mozilla requiring disclosure of the > audits". Can you help me understand where, in the policy, that's required? I'm not sure where your text in quotes comes from, and nor can I work out the referent of "it", so I don't understand this question. > I agree that removing the conflicting definition of qualified auditor is > likely a suitable outcome, and a much welcome improvement, but I do think > we owe it to the community to provide a greater degree of clarity then > currently provided by this thread about the expectations related to such > audits, both to the qualifications and the independence aspects. Surely requiring the auditor to be qualified in all cases will provide that clarity? I've filed https://github.com/mozilla/pkipolicy/issues/63 . Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Symantec: Next Steps
Cut: > An unwatched RA and a sub-CA are effectively equivalent in power. A > watched RA and a sub-CA might not be, if the CA is exercising > effective control and limits on their issuance. There is a distinction > in the BRs between an RA and a sub-CA, with the RA having less onerous > requirements. One could say that the very existence of that > distinction implies that CAs have a duty to carefully watch their RAs. The equivalency of power is not true most of the time. The term RA/DTP covers a lot of different roles. For example, four commonly used roles are: 1) An entity that does the translation of documents for the CA as defined in the EV Guidelines 2) An entity that gathers the validation documents and submits them to the CA for review in the validation process 3) An entity that identifies the subject identity information for a certificate (for example, in some schools the department may provide the identity proofing of a student that is getting a certificate) 4) An entity that provides verification of the entire certificate contents. Although #3 and #4 should perhaps be audited, by applying a broad requirement you end up capturing a lot more delegated entities than intended. The broad and diverse role of DTPs in the ecosystem is why the audit requirements in Section 8.4 were written to only require audits over those that provide domain validation. Whatever policy is decided, I'm hoping we can exclude translators and entities that are merely gathering documentation. Jeremy -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla .org] On Behalf Of Ryan Sleevi via dev-security-policy Sent: Thursday, March 9, 2017 6:32 AM To: Gervase Markham <g...@mozilla.org> Cc: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Symantec: Next Steps On Thu, Mar 9, 2017 at 6:48 AM, Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > That seems to make sense to me. Given that the BRs have the concept of > a DTP, how can we best align the two in practice? Does requiring every > RA to have its own subCA do that? > (Wearing Google hat only for this statement) Have you considered having this discussion in the CA/Browser Forum? Google had planned to discuss this very topic at our upcoming F2F about how to address this, and would be very interested in collaborating with Mozilla on this. I mentioned this recently to Kathleen at the WebTrust TF meetings, but apologies for not mentioning to you as well. > > I recognize that Item 2 "replaces" the criteria for Section 8.2, but > such a > > replacement is neither reflected within the audit report produced > > (when complying with the BRs) with respect to the issuing CA's > > oversight of the DTP - that is, you might reasonably expect a > > qualification, but for > Mozilla > > to ignore said qualification, consistent with Item 2 of "Audit > > Requirements". > > Can an audit be qualified (in the audit sense) by virtue of the person > _doing_ the audit not being formally qualified (in the other sense!) > to use those criteria? I would expect audit qualifications to relate > to the audit subject, not the auditor. > (Back to non-Google hat) You've misunderstood. An auditor performing an audit is not going to "self-qualify" because they aren't licensed. HOWEVER, an Auditor examining the Principles/Criteria of an Issuing CA is going to examine the controls of that CA relative to the operation of DTPs and sub-CAs, and those Principles/Criteria are based on the Baseline Requirements. If the "sub" auditor is not properly licensed - despite that "sub" auditor meeting the definition of Mozilla's "replacement" 8.2, then the issuing CA should reasonably be expected to receive a qualification that their controls are insufficient for the criteria of the Baseline Requirements (which does not have the replacement 8.2) Does that make more sense? In the Sub-CA case, this is "Principle 2: SSL Service Integrity", Criteria 8.2, and for DTPs, Criteria 8.4 > >> Yes, I would expect externally-operated sub CAs to have the correct > >> audits from a Mozilla-qualified auditor. > > > > Just to be clear: Given the definitions above, you believe it's > acceptable > > for sub-CAs to be issued to parties on the basis of the CA's > > judgement as to whether there is "sufficient public information > > available to determine that the party is competent to judge the CA's > > conformance to the stated criteria", and that so long as they do so, > > it does not represent any form of violation of Mozilla Policy, even > > if the CA makes an error in that judgement? > > No, because in the case of a sub-CA, we req
Re: Symantec: Next Steps
On Thu, Mar 9, 2017 at 1:34 PM, Steve Medin via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > In the case of CrossCert, where we have evidence of failure to properly > document their work, we are NOT relying on their previous work and have > begun fully revalidating all active certificates. In the cases of the other > 3 RAs, our focus is reviewing all of the work previously done to verify > that it can, in fact, be relied upon and/or determine where full > revalidation, without relying on the prior work of the RA, is warranted, if > at all. > Steve, While I appreciate your reply, I think it highlights precisely the concern about whether or not Symantec is qualified and/or should be trusted to make this determination, given that Symantec is in possession of documented evidence from one of their other RA partners about a failure to properly document their work and to ensure the authenticity of what was documented. Given your reply above, I think it's reasonable for readers to conclude that Symantec's Compliance Team, despite having been alerted to these issues on February 8, and having been aware of them for far longer, has decided that they are not significant. I'm not sure how such a conclusion is consistent with the information provided, and eagerly await any explanation Symantec may offer. Further, you have acknowledged that at least one auditor lacked sufficient skill and licensing to perform the audit. It is also clear that one or more of these RA partners was not audited with respect to "WebTrust Principles and Criteria for Certification Authorities - SSL Baseline with Network Security", and as such, lacks effective demonstration of adherence to the security-relevant Principles and Criteria contained therein, only having produced audits to the effect of "WebTrust Principles and Criteria for Certification Authorities". As demonstrated by the historical audits, the issues presented issues span multiple years, so even remediation plans that may have been effected for one or more of these delegated third parties, such plans do not retroactively 'correct' any misissuance or bad data logged in such systems. Finally, I am uncertain how any of Symantec's proposal is consistent with its CP/CPS, which incorporates the Baseline Requirements. In particular, Symantec has now had six weeks, and still has failed to abide by the terms of Section 4.9.1.1 regarding these 30,000 certificates. Regardless of the next steps Symantec may take, I think it's reasonable to suggest that these are all extremely important for members of the community to carefully contemplate, and all of them rest specifically with actions and statements made by Symantec since this investigation began, rather than the RA partners. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Symantec: Next Steps
In the case of CrossCert, where we have evidence of failure to properly document their work, we are NOT relying on their previous work and have begun fully revalidating all active certificates. In the cases of the other 3 RAs, our focus is reviewing all of the work previously done to verify that it can, in fact, be relied upon and/or determine where full revalidation, without relying on the prior work of the RA, is warranted, if at all. > -Original Message- > From: dev-security-policy [mailto:dev-security-policy- > bounces+steve_medin=symantec@lists.mozilla.org] On Behalf Of Ryan > Sleevi via dev-security-policy > Sent: Wednesday, March 08, 2017 11:37 AM > To: Gervase Markham <g...@mozilla.org> > Cc: Ryan Sleevi <r...@sleevi.com>; mozilla-dev-security- > pol...@lists.mozilla.org > Subject: Re: Symantec: Next Steps > > > I highlight this, because at least one of these DTPs failed to maintain > sufficient audit logs, and Symantec has stated it plans to continue using this > information - information improperly secured, improperly maintained, and > with improper access controls - for the issuance of certificates. > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec: Next Steps
On Thu, Mar 9, 2017 at 6:48 AM, Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > That seems to make sense to me. Given that the BRs have the concept of a > DTP, how can we best align the two in practice? Does requiring every RA > to have its own subCA do that? > (Wearing Google hat only for this statement) Have you considered having this discussion in the CA/Browser Forum? Google had planned to discuss this very topic at our upcoming F2F about how to address this, and would be very interested in collaborating with Mozilla on this. I mentioned this recently to Kathleen at the WebTrust TF meetings, but apologies for not mentioning to you as well. > > I recognize that Item 2 "replaces" the criteria for Section 8.2, but > such a > > replacement is neither reflected within the audit report produced (when > > complying with the BRs) with respect to the issuing CA's oversight of the > > DTP - that is, you might reasonably expect a qualification, but for > Mozilla > > to ignore said qualification, consistent with Item 2 of "Audit > > Requirements". > > Can an audit be qualified (in the audit sense) by virtue of the person > _doing_ the audit not being formally qualified (in the other sense!) to > use those criteria? I would expect audit qualifications to relate to the > audit subject, not the auditor. > (Back to non-Google hat) You've misunderstood. An auditor performing an audit is not going to "self-qualify" because they aren't licensed. HOWEVER, an Auditor examining the Principles/Criteria of an Issuing CA is going to examine the controls of that CA relative to the operation of DTPs and sub-CAs, and those Principles/Criteria are based on the Baseline Requirements. If the "sub" auditor is not properly licensed - despite that "sub" auditor meeting the definition of Mozilla's "replacement" 8.2, then the issuing CA should reasonably be expected to receive a qualification that their controls are insufficient for the criteria of the Baseline Requirements (which does not have the replacement 8.2) Does that make more sense? In the Sub-CA case, this is "Principle 2: SSL Service Integrity", Criteria 8.2, and for DTPs, Criteria 8.4 > >> Yes, I would expect externally-operated sub CAs to have the correct > >> audits from a Mozilla-qualified auditor. > > > > Just to be clear: Given the definitions above, you believe it's > acceptable > > for sub-CAs to be issued to parties on the basis of the CA's judgement as > > to whether there is "sufficient public information available to determine > > that the party is competent to judge the CA's conformance to the stated > > criteria", and that so long as they do so, it does not represent any form > > of violation of Mozilla Policy, even if the CA makes an error in that > > judgement? > > No, because in the case of a sub-CA, we require audits. And when we > receive them, if they were done by unqualified parties, the CA would > need to flag that, and we would make a judgement about that party's > suitability at the time. The issue here arises that, because of the way > things are set up, these RA's audits were not submitted to Mozilla, and > so Symantec didn't have to resolve the Schrodinger's Cat of > (qualified|not qualified and need us to make a judgement). > > Having danced enough angels for sufficiently long on the head of this > pin, though, it's clear we should fix this. I propose we switch our > auditor requirements to requiring qualified auditors, and saying that > exceptions can be applied for in writing to Mozilla in advance of the > audit starting, in which case Mozilla will make its own determination as > to the suitability of the suggested party or parties. This would involve > removing bullets 3-6 in the Audit section of 2.4, and rewording bullet 2 > to say something like the above. > I'm not sure that we can or should so easily dismiss this with a suggestion that we're dancing on the head of a pin here. I don't understand why you believe it's relevant the act of "Mozilla requiring disclosure of the audits". Can you help me understand where, in the policy, that's required? I highlight this because the question of "qualified or not qualified", for RAs (which are not disclosed), is one where the CA accepts a liability of the decision if they do not seek Mozilla's guidance. For the question of appropriately WebTrust licensed, this has an objective basis for which compliance with Mozilla can be demonstrated at the time the audit was accepted. However, if entering in the to the "CA's discretion" side of the availability of the public information, any CA that fails to obtain Mozilla's opinion a priori bears the liability and responsibility if they stuff that judgement up. I agree that removing the conflicting definition of qualified auditor is likely a suitable outcome, and a much welcome improvement, but I do think we owe it to the community to provide a greater degree of clarity then currently provided by this thread
Re: Symantec: Next Steps
On 08/03/17 16:36, Ryan Sleevi wrote: > That is precisely the goal. We could define a set of process and procedures > specific to DTPs, which is effectively duplicitive with the handling of > subordinate CAs, or we could strive to align the two both conceptually and > materially, since, as you note below, there's a number of similarities in > the risk profile. > > The concern with the approach of both DTPs and subCAs is that it's very > easy for nuanced and subtle distinctions to be introduced, and as such, it > seems better to avoid that when possible by aligning on the majority-common > portion. That seems to make sense to me. Given that the BRs have the concept of a DTP, how can we best align the two in practice? Does requiring every RA to have its own subCA do that? > Note: It does not appear you've updated > https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ > - do you plan to? https://bugzilla.mozilla.org/show_bug.cgi?id=1343200 . It is a bit sad that a content push to our website requires the work to be scheduled in a sprint, but I digress. The fix is now on their master branch; I don't know how often they push to production. Looking at https://github.com/mozilla/bedrock/commits/prod , it may be as infrequently as once a week :-(( > I'm surprised by that reading, because Item 3 of that section states > > By "competent party" we mean a person or other entity who is authorized to > perform audits according to the stated criteria (e.g., by the organization > responsible for the criteria or by a relevant government agency) or for > whom there is sufficient public information available to determine that the > party is competent to judge the CA’s conformance to the stated criteria. > > In the absence of a proper license, such parties are not "authorized to > perform audits according to the stated criteria", so the only question is > whether "there is sufficient public information available to determine that > the party is competent to judge the CA's conformance to the stated > criteria". Yep, with you so far. > I recognize that Item 2 "replaces" the criteria for Section 8.2, but such a > replacement is neither reflected within the audit report produced (when > complying with the BRs) with respect to the issuing CA's oversight of the > DTP - that is, you might reasonably expect a qualification, but for Mozilla > to ignore said qualification, consistent with Item 2 of "Audit > Requirements". Can an audit be qualified (in the audit sense) by virtue of the person _doing_ the audit not being formally qualified (in the other sense!) to use those criteria? I would expect audit qualifications to relate to the audit subject, not the auditor. > "The burden is on the CA to prove that it has met the above >> requirements. However the CA may request a preliminary determination >> from us regarding the acceptability of the criteria and/or the competent >> independent party or parties by which it proposes to meet the >> requirements of this policy." >> >> I think a reasonable person might interpret this to mean that they >> needed to pick auditors who fulfilled the requirements in our policy, >> but don't need to _prove_ it unless asked. And they are not obliged to >> seek our determination. And I think that if we did ask Symantec to prove >> that the various bits of E met the criteria in the policy at the time, >> I think they could probably do that. > > I find this an interesting and surprising interpretation, because I long > believed the intent and letter of Mozilla policy is that Mozilla required > such determination in the cases of accepting subordinate material, and the > burden of proof rests with them when presenting such material to Mozilla > during inclusion. It would, you are right. But these audits were not submitted to us (until recently) because they did not have to be, and so the question did not arise. >> Yes, I would expect externally-operated sub CAs to have the correct >> audits from a Mozilla-qualified auditor. > > Just to be clear: Given the definitions above, you believe it's acceptable > for sub-CAs to be issued to parties on the basis of the CA's judgement as > to whether there is "sufficient public information available to determine > that the party is competent to judge the CA's conformance to the stated > criteria", and that so long as they do so, it does not represent any form > of violation of Mozilla Policy, even if the CA makes an error in that > judgement? No, because in the case of a sub-CA, we require audits. And when we receive them, if they were done by unqualified parties, the CA would need to flag that, and we would make a judgement about that party's suitability at the time. The issue here arises that, because of the way things are set up, these RA's audits were not submitted to Mozilla, and so Symantec didn't have to resolve the Schrodinger's Cat of (qualified|not qualified and need us to make a judgement). Having danced enough
Re: Symantec: Next Steps
On Wed, Mar 8, 2017 at 10:30 AM, Gervase Markhamwrote: > On 07/03/17 20:37, Ryan Sleevi wrote: > > To make it simpler, wouldn't be a Policy Proposal be to prohibit > Delegated > > Third Parties from participating in the issuance process? This would be > > effectively the same, in as much as the only capability to allow a > > third-party to participate in issuance is to operate a subordinate CA. > > Is this the same as banning the concept of DTPs? > > I note, reading the BRs, that there's no process for root programs to > get any access to, or validate, the audit documentation for DTPs. That > doesn't sound great. Making them sub-CAs would solve that? > That is precisely the goal. We could define a set of process and procedures specific to DTPs, which is effectively duplicitive with the handling of subordinate CAs, or we could strive to align the two both conceptually and materially, since, as you note below, there's a number of similarities in the risk profile. The concern with the approach of both DTPs and subCAs is that it's very easy for nuanced and subtle distinctions to be introduced, and as such, it seems better to avoid that when possible by aligning on the majority-common portion. > > Similarly, do you believe Symantec had an obligation to ensure the proper > > licensing status of auditors, prior to accepting such audits? > > No. This may surprise you but, for better or worse, the Mozilla > requirements override those of the BRs (see the Audit section of policy > 2.4) Note: It does not appear you've updated https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ - do you plan to? https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/ still links to it, as does https://wiki.mozilla.org/CA:Overview - so I suspect there's still a substantial bit of cleanup work to do here ;) (Plus the bugs introduced in 2.4 that were missed until the 2.4.1 discussion, such as the scope, which isn't present in 2.3) > and those do not require official licensing of auditors. > Historically, this was because we wanted to leave room for CACert. What > they actually say is that they give definitions of a "competent party" > and "independent party", and then say: > I'm surprised by that reading, because Item 3 of that section states By "competent party" we mean a person or other entity who is authorized to perform audits according to the stated criteria (e.g., by the organization responsible for the criteria or by a relevant government agency) or for whom there is sufficient public information available to determine that the party is competent to judge the CA’s conformance to the stated criteria. In the absence of a proper license, such parties are not "authorized to perform audits according to the stated criteria", so the only question is whether "there is sufficient public information available to determine that the party is competent to judge the CA's conformance to the stated criteria". I recognize that Item 2 "replaces" the criteria for Section 8.2, but such a replacement is neither reflected within the audit report produced (when complying with the BRs) with respect to the issuing CA's oversight of the DTP - that is, you might reasonably expect a qualification, but for Mozilla to ignore said qualification, consistent with Item 2 of "Audit Requirements". "The burden is on the CA to prove that it has met the above > requirements. However the CA may request a preliminary determination > from us regarding the acceptability of the criteria and/or the competent > independent party or parties by which it proposes to meet the > requirements of this policy." > > I think a reasonable person might interpret this to mean that they > needed to pick auditors who fulfilled the requirements in our policy, > but don't need to _prove_ it unless asked. And they are not obliged to > seek our determination. And I think that if we did ask Symantec to prove > that the various bits of E met the criteria in the policy at the time, > I think they could probably do that. > I find this an interesting and surprising interpretation, because I long believed the intent and letter of Mozilla policy is that Mozilla required such determination in the cases of accepting subordinate material, and the burden of proof rests with them when presenting such material to Mozilla during inclusion. > Yes, I would expect externally-operated sub CAs to have the correct > audits from a Mozilla-qualified auditor. > Just to be clear: Given the definitions above, you believe it's acceptable for sub-CAs to be issued to parties on the basis of the CA's judgement as to whether there is "sufficient public information available to determine that the party is competent to judge the CA's conformance to the stated criteria", and that so long as they do so, it does not represent any form of violation of Mozilla Policy, even if the CA makes an error in that judgement? I can understand
Re: Symantec: Next Steps
On 07/03/17 20:37, Ryan Sleevi wrote: > To make it simpler, wouldn't be a Policy Proposal be to prohibit Delegated > Third Parties from participating in the issuance process? This would be > effectively the same, in as much as the only capability to allow a > third-party to participate in issuance is to operate a subordinate CA. Is this the same as banning the concept of DTPs? I note, reading the BRs, that there's no process for root programs to get any access to, or validate, the audit documentation for DTPs. That doesn't sound great. Making them sub-CAs would solve that? > have you examined the most recent set of audits? I have glanced over them, but not studied them in depth. > Do you, in your capacity > as CA Certificate policy peer, believe the audits were correct for their > capability and role? Note that several of them were "WebTrust for CAs" - > not "WebTrust for CAs - SSL BR and Network Security". Do you believe that > complies with letter of the Baseline Requirements? That would be a question I would leave to Kathleen, who is the team expert here. > Similarly, do you believe Symantec had an obligation to ensure the proper > licensing status of auditors, prior to accepting such audits? No. This may surprise you but, for better or worse, the Mozilla requirements override those of the BRs (see the Audit section of policy 2.4) and those do not require official licensing of auditors. Historically, this was because we wanted to leave room for CACert. What they actually say is that they give definitions of a "competent party" and "independent party", and then say: "The burden is on the CA to prove that it has met the above requirements. However the CA may request a preliminary determination from us regarding the acceptability of the criteria and/or the competent independent party or parties by which it proposes to meet the requirements of this policy." I think a reasonable person might interpret this to mean that they needed to pick auditors who fulfilled the requirements in our policy, but don't need to _prove_ it unless asked. And they are not obliged to seek our determination. And I think that if we did ask Symantec to prove that the various bits of E met the criteria in the policy at the time, I think they could probably do that. Other root programs may differ, of course. One could argue that, with CACert and its creative approach to cheaper auditing not really on the horizon any more, we should drop our custom definitions and just ask for a licensed auditor. > I think these may represent important questions for Mozilla to determine, > in order to evaluate the fullness of the claim you have summarized, and I > think would equally apply if we were discussing externally-operated > subordinate CAs, correct? Yes, I would expect externally-operated sub CAs to have the correct audits from a Mozilla-qualified auditor. > Considering the capability afforded to these RAs - full certificate > issuance through independent domain validation - I'm curious whether you > believe this materially represents a practical distinction from the > issuance of an unconstrained subordinate CA, and how responsible the > issuing CA is for overseeing those operations. If they didn't have control of the private key of their issuing intermediate(s) (as it seems they did not), then I do think this is a practical distinction from them being an unconstrained subordinate CA, in that they would e.g. not be audited for things like key management. In terms of the power they have, it's close - and, if the overseeing CA is not watching, basically identical. And there's the rub. As there is a distinction, then the CA should have been watching. If the CA were permitted not to watch, there would or should be no distinction in the BRs. And there is. Make sense? Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec: Next Steps
On Wed, Mar 8, 2017 at 6:50 AM, Ryan Sleeviwrote: > > On Wed, Mar 8, 2017 at 9:23 AM, Peter Bowen wrote: > >> > Does this make it clearer the point I was trying to make, which is that >> > they're functionally equivalent - due to the fact that both DTPs and >> > sub-CAs >> > have the issue of multi-party audit scopes? >> >> I agree that you suggest an approach that is probably functionally >> equivalent, but what you describe is not how WebTrust audits work. > > > Peter, does my recent clarification help align this? I think we are in > violent agreement with respect to sub-CAs that you don't get to "pick and > choose" the principles and criteria, but for the specific case of DTPs and > their capabilities, was trying to describe how it could fit within the 'site > visit' examination, due to the inability to rely on / use third-party audits > as evidence for the basis of opinion forming. By eliminating the DTP option, you will massively raise costs for CAs that rely upon local translators and information gatherers. I think a much better proposal would be to require the CA perform the RA activity contemplated by BR 3.2.2.4 and 3.2.2.5 and restrict DTPs to Subject Identity Information validation. Thanks, Peter ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec: Next Steps
On 07/03/17 23:26, Nick Lamb wrote: > I am concerned that the specificity of Policy Proposals 1 & 2 risks > fighting the last war by focusing so much on the RA role. I guess that's possible; however, it's clear to me that we need policy improvements in this area. If you know where the next war will be, do let us know :-) Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec: Next Steps
On Wed, Mar 8, 2017 at 9:23 AM, Peter Bowen via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > This is why I'm suggesting, from an audit scope, they're functionally > > equivalent approach, except one avoids the whole complexity of > identifying > > where or not a DTP is something different-than a sub-CA, since the > _intent_ > > is true in both, which is that 100% of the capabilities related to > issuance > > are appropriately audited - either by the DTP/sub-CA or by the issuing > > CA/managed CA provided > > > > Does this make it clearer the point I was trying to make, which is that > > they're functionally equivalent - due to the fact that both DTPs and > sub-CAs > > have the issue of multi-party audit scopes? > > I agree that you suggest an approach that is probably functionally > equivalent, but what you describe is not how WebTrust audits work. > Peter, does my recent clarification help align this? I think we are in violent agreement with respect to sub-CAs that you don't get to "pick and choose" the principles and criteria, but for the specific case of DTPs and their capabilities, was trying to describe how it could fit within the 'site visit' examination, due to the inability to rely on / use third-party audits as evidence for the basis of opinion forming. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec: Next Steps
On Wed, Mar 8, 2017 at 8:46 AM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Yes, I agree they should be functionally equivalent, in the sense that > all aspects of the operation and issuance are validated, and that one > entity is ultimately responsible for the actions of the others. > > The distinction I am making is that the entity named as ultimately > responsible ("the CA") needs an audit report that covers all the > requirements with some requirements possibly audited in the form of > auditing the presence of valid audit report from the other entities > involved. > Except that, from discussions with a number of WebTrust auditors, there is an issue accepting such evidence. So the scenario you describe further is not what actually happens in practice - and this is part of the motivation for the Policy suggestion I provided, so that theory and practice can align. For example, an auditor will not necessarily examine the audits of other parties - this is true whether the other party is, for example, a datacenter operator (which relates to physical security principles), a "Cloud HSM" provider (which relates to key security principles), or what we've identified as a Delegated Third Party. If the function is not at all performed by the CA, then as Peter has noted, the auditor will not report on it - and as a consequence, be unable to produce a seal. If the function is _partially_ performed by the CA, then the auditor will report to the extent that function is provided by the CA. So the disconnect here is your assertion that auditors are examining these reports - whether they be sub-CA or DTPs. The extent of the reporting an auditor performs during such an engagement is to report on the controls relative to the principles - e.g. does the CA have a documented process to review such audits, does the auditor have an opinion that such controls provide sufficient evidence to the criteria and principles, and were they, to the extent for the period in question, performed as such. So we end up in a situation where such audits are not required to be disclosed (at present), such audits may not conform to the expected standards (and the audits Symantec has provided amply demonstrate this), and for which the auditor of the 'issuing CA' may provide a clean opinion, because their opinion was scoped to the specific activities of those provided by Symantec Corporation (notably, in its omission, excluding that of delegated third parties). This does not seem a desirable outcome, particularly because it conflicts with Mozilla's many improvements towards transparency. Each of the Policy proposals Gerv has mentioned ends up in this scenario of insufficiently controlling for and disclosing the concerns related to issuance. So now we circle back to the provision of delegated third party services by reforming it such that it's treated as an externally operated sub-CA. As Peter has noted, the extent of such audits would need to include the full activities of that sub-CA in some form - you don't get to carve that up. In practice, I'm suggesting that the "Issuing CA", during their annual audit cycle, would have all the relevant controls and policies examined for that sub-CA as part of the audit engagement and scope, and would perform some form of 'site visit' to examine the set of controls and procedures relative to the function they provide. This is, I assert, functionally similar to the site audits a number of auditors already perform with respect to third-party datacenter operations (fairly common) or more complex cases such as managed key material (rare, but done). It has the benefit, however, of aligning the practice of what an audit opinion covers (e.g. there's no carve-out for the DTP operations), when the audit is disclosed (publicly), and the technical capability for distinctive issuance. I further suggest that anything less is to undermine the goal and intent of Mozilla policy, which is quite reasonable - know who can issue certs and what their policies are. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec: Next Steps
On Wed, Mar 8, 2017 at 5:08 AM, Ryan Sleeviwrote: > > > On Wed, Mar 8, 2017 at 12:57 AM, Peter Bowen via dev-security-policy > wrote: >> >> If the DTP is only performing the functions that Jakob lists, then >> they only need an auditor's opinion covering those functions. In fact >> there is no way for an auditor to audit functions that don't exist. >> For example, consider the WebTrust for CA criteria called "Subordinate >> CA Certificate Life Cycle Management". If the only CA in scope for >> the audit does not issue Subordinate CA Certificates, then that >> criteria is not applicable. Depending on the auditor, it might be >> that the CA needs to write in some policy (public or private) "the CA >> does not issue Subordinate CA Certificates." >> >> Many auditors vary how much they charge for their work based on the >> expected effort required to compete the work. I believe Jakob's point >> is that an audit where all the criteria are just "we do not do X" is >> very quick -- for example a DTP that does not have a HSM and does not >> digitally sign things is going to be a much cheaper audit than one >> that does have a HSM and signs things under multi-person control. > > > So I agree with this - namely, that a DTP audit does not include the > Principles and/or Criteria relevant for the operational aspects they don't > control, because the auditor neither forms an opinion about the third-party > operation. I think a good example, to continue with yours, if the issuing CA > handles the HSM, and is already audited as such, then the auditor will not > opine on another auditors work. > > So the scope of a DTP audit will be limited to the functions provided by the > DTP. > > But the same is true for an externally operated sub-CA, for which the > majority of services are provided for by the "issuing" CA, and the DTP > performs the validation functions for this sub-CA. Ah, but it is not true. I had a very enlightening discussion with representatives from the WebTrust Task Force at the CA/Browser Forum meeting in Redmond. CAs must be evaluated on all the WebTrust criteria that are not marked optional in order to get a WebTrust seal and the same auditor must do the whole audit. So, sub-CA Foo contracts with Bar to host the HSM for the sub-CA and handle the issuing functions (and probably the revocation functions) and if Bar is also a CA, Bar gets audited twice. One time by Bar's auditor at Bar's cost and then again by Foo's auditor at Foo's cost. Note that WebTrust for CA criteria 6 says: "The Certification Authority maintains effective controls to provide reasonable assurance that Subscriber information was properly authenticated (for the registration activities performed by ABC-CA)." Given this criteria, the auditor does not have to inspect each RA themselves. Also note that the only optional criteria are: 2.1 Certificate Policy Management (if applicable) 2.3 CP and CPS Consistency (if applicable) 4.8 CA Key Escrow (if applicable) 5.1 CA-Provided Subscriber Key Generation Services (if supported) 5.2 CA-Provided Subscriber Key Storage and Recovery Services (if supported) 5.3 Integrated Circuit Card (ICC) Life Cycle Management (if supported) 6.2 Certificate Renewal (if supported) 6.7 Certificate Suspension (if supported) The CA Key Lifecycle controls, including storage and usage, are not optional, so each sub-CA must be audited on them. > This is why I'm suggesting, from an audit scope, they're functionally > equivalent approach, except one avoids the whole complexity of identifying > where or not a DTP is something different-than a sub-CA, since the _intent_ > is true in both, which is that 100% of the capabilities related to issuance > are appropriately audited - either by the DTP/sub-CA or by the issuing > CA/managed CA provided > > Does this make it clearer the point I was trying to make, which is that > they're functionally equivalent - due to the fact that both DTPs and sub-CAs > have the issue of multi-party audit scopes? I agree that you suggest an approach that is probably functionally equivalent, but what you describe is not how WebTrust audits work. Thanks, Peter ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec: Next Steps
On 08/03/2017 14:18, Ryan Sleevi wrote: On Wed, Mar 8, 2017 at 1:36 AM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: I am simply going by the wording in Gervs posting not stating what you stated. I presume that if Gerv wanted to complete eliminate the DTP concept for Mozilla trusted CAs, then that's what he would have written. Jakob, This is a frustrating excerise, and I hope you can appreciate. You are again ascribing an intent, one of which you explicitly stated, to Gerv, without evidence or support. When challenged on this, you acknowledge support for this conclusion isn't present - but now you're trying to again suggest the presumption/wording. Can we at least agree - for the sake of productive discussion - that there's no explicit statement that removing DTPs is off the table, so that we can discuss the substance of that, and you can acknowledge that there's no provided evidence to support your claim that removing DTPs was not intended? Can you imagine the possibility that Gerv just simply didn't word it as such? Having not fully studied the exact wording of the BRs, I operate under the assumption that the longer phrasing "... an audit report, issued under the auditing standards that underlie the accepted audit schemes found in Section 8.1 ..." as quoted from section 8.4 in earlier discussion of the Symantec case was intentionally so phrased to indicate that the audit of a DTP would not be the same as a full WebTrust CA audit, but would only cover those aspects of those criteria which would be applicable to the performance of the particular DTP role. If that quote is indeed from the relevant part of the BRs, then I would posit that if the BR authors had wanted all kinds of DTPs to be subject to a full WebTrust audit, they would not have used this more complex phrase. The BR authors are terribly flawed (I'm one of them, or at least maintainers), and the wording complexity and confusion is more often confusing than intentional. I hope you consider my reply to Peter on this topic, in which I try to highlight how the point upon which you're stuck on 'full audit', is a practical matter that, when applied, is indistinguishable from an DTP audit. I think you can readily agree that the 'intent' is that the fullness of capabilities relative to causing issuance are desired to be audited. Namely, whether we're talking a DTP audit or a CA audit, the intent is that all CA functions outlined in the Baseilne Requirements can have Principles and/or Criteria attached to / derived from them, and that every party who performs some role within it is audited according to that role. If you can agree to that - which is, I think, the point you're trying to make with DTP audits - then what we have is a scenario where some functions are performed by Company A, some functions are performed by Company B. Whether it's a DTP performing 3.2 validation (Company B) or an entity performing 3.2 validation for an externally operated sub-CA (Company B), I think we're in violent agreement that we want to ensure that Company B is audited according to its role. Before I introduce any more complexity - can you agree to that as the goal? Then everything else is just semantics that we can hammer out. Yes, I agree they should be functionally equivalent, in the sense that all aspects of the operation and issuance are validated, and that one entity is ultimately responsible for the actions of the others. The distinction I am making is that the entity named as ultimately responsible ("the CA") needs an audit report that covers all the requirements with some requirements possibly audited in the form of auditing the presence of valid audit report from the other entities involved. The entities ("DTPs") that are not "the CA" need audit reports covering only that which is delegated by "the CA" (and for which an audit report is thus needed as documentation that "the CA" must provide to auditors and root programs). In other words where the audit report for "the CA" would contain statements such as "managing HSM safety: Performed by delegated entity X, as confirmed by audit report Y", the audit report for the others entities ("DTPs") can simply condider their non-jobs as explicitly out of scope for the audit. It is part of the duty for the auditors of "the CA" and the relying parties/root programs looking at paperwork presented by "the CA" to check that all the tasks outsourced by "the CA" are covered as "in scope" by audit reports for the "DTPs" that those tasks are outsourced to. It is this distinction between auditors who only check that which is requested and auditors who checks that all mandatory aspect are audited by someone, somewhere which I believe would result in a difference in cost and effort. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is
Re: Symantec: Next Steps
On Wed, Mar 8, 2017 at 1:29 AM, Santhan Raj via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > Ryan, > > Section 8.4 (cited below), as worded today, does not mandate a DTP to go > through an audit. Rather, it requires the CA to perform additional > out-of-band checks or perform the domain/IPAddress validation (3.2.2.4 & > 3.2.2.5) by itself, when the DTP is not audited as per 8.4 (btw BR > incorrectly refers to section 8.1 for audit schemes). > > It allows (or doesn't prohibit) the DTP to perform other validation checks > in 3.2.2 (while the CA performs 3.2.2.4/5) without going through an > WebTrust/ETSI audit, and a CA may choose to perform an internal audit of > the DTP's process vs forcing them through a WebTrust/ETSI audit. > > There are other checks the CA must perform, but as far as I can tell there > isn't any requirement that states a "DTP MUST go through an audit" in the > BRs. > > "If a Delegated Third Party is not currently audited in accordance with > Section 8 and is not an Enterprise RA, then prior to certificate issuance > the CA SHALL ensure that the domain control validation process required > under Section 3.2.2.4 or IP address verification under 3.2.2.5 has been > properly performed by the Delegated Third Party by either (1) using an > out-of-band mechanism involving at least one human who is acting either on > behalf of the CA or on behalf of the Delegated Third Party to confirm the > authenticity of the certificate request or the information supporting the > certificate request or (2) performing the domain control validation process > itself. I think we may read this different, Santhan. Either the issuing CA must themselves verify the information present in the request - in which case, the DTP acts as an information aggregator, effectively, and the CA is performing the verification function - or if the DTPs validation of the information is to be trusted, then they MUST undergo an audit. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec: Next Steps
On Wed, Mar 8, 2017 at 12:57 AM, Peter Bowen via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > If the DTP is only performing the functions that Jakob lists, then > they only need an auditor's opinion covering those functions. In fact > there is no way for an auditor to audit functions that don't exist. > For example, consider the WebTrust for CA criteria called "Subordinate > CA Certificate Life Cycle Management". If the only CA in scope for > the audit does not issue Subordinate CA Certificates, then that > criteria is not applicable. Depending on the auditor, it might be > that the CA needs to write in some policy (public or private) "the CA > does not issue Subordinate CA Certificates." > > Many auditors vary how much they charge for their work based on the > expected effort required to compete the work. I believe Jakob's point > is that an audit where all the criteria are just "we do not do X" is > very quick -- for example a DTP that does not have a HSM and does not > digitally sign things is going to be a much cheaper audit than one > that does have a HSM and signs things under multi-person control. So I agree with this - namely, that a DTP audit does not include the Principles and/or Criteria relevant for the operational aspects they don't control, because the auditor neither forms an opinion about the third-party operation. I think a good example, to continue with yours, if the issuing CA handles the HSM, and is already audited as such, then the auditor will not opine on another auditors work. So the scope of a DTP audit will be limited to the functions provided by the DTP. But the same is true for an externally operated sub-CA, for which the majority of services are provided for by the "issuing" CA, and the DTP performs the validation functions for this sub-CA. This is why I'm suggesting, from an audit scope, they're functionally equivalent approach, except one avoids the whole complexity of identifying where or not a DTP is something different-than a sub-CA, since the _intent_ is true in both, which is that 100% of the capabilities related to issuance are appropriately audited - either by the DTP/sub-CA or by the issuing CA/managed CA provided Does this make it clearer the point I was trying to make, which is that they're functionally equivalent - due to the fact that both DTPs and sub-CAs have the issue of multi-party audit scopes? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec: Next Steps
On 08/03/2017 06:27, Ryan Sleevi wrote: On Tue, Mar 7, 2017 at 11:23 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: I saw nothing in Gervs posting suggesting that banning all kinds of RA/DTP relationships was the intended effect. But would you also acknowledge that your originally stated "The point is NOT to prohibit RAs" is similarly not provided? I highlight this, because I want to make sure you're not prematurely dismissing policy suggestions because you disagree. I am simply going by the wording in Gervs posting not stating what you stated. I presume that if Gerv wanted to complete eliminate the DTP concept for Mozilla trusted CAs, then that's what he would have written. As to the rest of your message, you describe what have historically been called RAs/DTPs. You have not, however, answered my question - which is what impact, if any, do you believe would happen if Mozilla considers the policy I suggested: That is, to require that anything which 'historically' was considered an RA be treated as an externally operated sub-CA. For the kind of RA that is a combined reseller/control everything related to issuing (the Symantec case), there would be no significant change in burden for the RA. For the kind of RA that only does specific relevant parts of validation (a "traditional" RA), the suggested policy as written would "simply" require the CA to set up and maintain one (set of) subCAs for each of their RAs, while your rephrasing as a ban on RA/DTP relationships would impose the full cost of a formal WebTrust (etc.) audit on RAs that only perform a specific limited function that could be audited much cheaper, provided the CA systems were set up to have little dependency on certificate specific activities and security at the RAs. This misunderstands Policy 1 then, and is perhaps the substance of our unintentional disagreement. if a CA sets up and maintains one (set of) sub CAs for each RA, then each of those subCAs would need to be audited. This is no different than the existing requirements, within the Baseline Requirements, that each DTP be audited. I would highlight Section 8 of the Baseline Requirements for you, and ask that you clarify where, under the existing policies (e.g. ignoring any policy proposal) you believe there is any provision for allowing a DTP to be "audited much cheaper". If you believe such a thing is possible (I would argue incorrectly so, but hear me out), then what we're effectively saying is that a set of Principles and Criteria are not examined by the audit, because the operation and majority of the controls are managed by the "Issuing CA" - at least, within the world today of CA/RA relationships. If we believe such a thing is accepted (and again, not supported by the Baseline Requirements, and to the extent of my interactions with various auditor/practitioners, I do not believe currently supported by WebTrust), then I hope you can also see that we can use that self-same logic to conclude that a DTP operating as a externally operated sub-CA - but one in which the "Issuing CA" handles the operation and majority of controls for - is effectively the same thing. Do you agree with that logic? Can you clarify where and why you disagree with the analysis above? Having not fully studied the exact wording of the BRs, I operate under the assumption that the longer phrasing "... an audit report, issued under the auditing standards that underlie the accepted audit schemes found in Section 8.1 ..." as quoted from section 8.4 in earlier discussion of the Symantec case was intentionally so phrased to indicate that the audit of a DTP would not be the same as a full WebTrust CA audit, but would only cover those aspects of those criteria which would be applicable to the performance of the particular DTP role. If that quote is indeed from the relevant part of the BRs, then I would posit that if the BR authors had wanted all kinds of DTPs to be subject to a full WebTrust audit, they would not have used this more complex phrase. For example, an RA whose sole involvement is to receive a daily list of company name/idno/address/authorized signatory for pending applications, go down to the state hall of records and report back which ones match/do not match official company records (to support EV certification for that state) would only need auditing of that activity and the security of the system used to exchange that list and report with the CAs central validation team. Please provide a citation to the Baseline Requirements or Mozilla policy to support this statement. I would suggest Section 8.4 provides counter-evidence to this claim, and as such, because the argument rests on this claim, needs to be addressed before we might make further progress. I refer to the earlier quote ostensibly from section 8.4 itself. Worse, I chose the precise term of "Delegated Third Party" to avoid confusion with the explicitly-called out
Re: Symantec: Next Steps
On Tue, Mar 7, 2017 at 9:27 PM, Ryan Sleevi via dev-security-policywrote: > On Tue, Mar 7, 2017 at 11:23 PM, Jakob Bohm via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: ]> >> For example, an RA whose sole involvement is to receive a daily list of >> company name/idno/address/authorized signatory for pending >> applications, go down to the state hall of records and report back >> which ones match/do not match official company records (to support EV >> certification for that state) would only need auditing of that activity >> and the security of the system used to exchange that list and report >> with the CAs central validation team. > > > Please provide a citation to the Baseline Requirements or Mozilla policy to > support this statement. I would suggest Section 8.4 provides > counter-evidence to this claim, and as such, because the argument rests on > this claim, needs to be addressed before we might make further progress. Section 8.4 says: " If the CA is not using one of the above procedures and the Delegated Third Party is not an Enterprise RA, then the CA SHALL obtain an audit report, issued under the auditing standards that underlie the accepted audit schemes found in Section 8.1, that provides an opinion whether the Delegated Third Party’s performance complies with either the Delegated Third Party’s practice statement or the CA’s Certificate Policy and/or Certification Practice Statement." If the DTP is only performing the functions that Jakob lists, then they only need an auditor's opinion covering those functions. In fact there is no way for an auditor to audit functions that don't exist. For example, consider the WebTrust for CA criteria called "Subordinate CA Certificate Life Cycle Management". If the only CA in scope for the audit does not issue Subordinate CA Certificates, then that criteria is not applicable. Depending on the auditor, it might be that the CA needs to write in some policy (public or private) "the CA does not issue Subordinate CA Certificates." Many auditors vary how much they charge for their work based on the expected effort required to compete the work. I believe Jakob's point is that an audit where all the criteria are just "we do not do X" is very quick -- for example a DTP that does not have a HSM and does not digitally sign things is going to be a much cheaper audit than one that does have a HSM and signs things under multi-person control. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec: Next Steps
On Tue, Mar 7, 2017 at 11:23 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > I saw nothing in Gervs posting suggesting that banning all kinds of > RA/DTP relationships was the intended effect. But would you also acknowledge that your originally stated "The point is NOT to prohibit RAs" is similarly not provided? I highlight this, because I want to make sure you're not prematurely dismissing policy suggestions because you disagree. > As to the rest of your message, you describe what have historically been >> called RAs/DTPs. You have not, however, answered my question - which is >> what impact, if any, do you believe would happen if Mozilla considers the >> policy I suggested: That is, to require that anything which 'historically' >> was considered an RA be treated as an externally operated sub-CA. >> > > For the kind of RA that is a combined reseller/control everything > related to issuing (the Symantec case), there would be no significant > change in burden for the RA. > > For the kind of RA that only does specific relevant parts of validation > (a "traditional" RA), the suggested policy as written would "simply" > require the CA to set up and maintain one (set of) subCAs for each of > their RAs, while your rephrasing as a ban on RA/DTP relationships would > impose the full cost of a formal WebTrust (etc.) audit on RAs that only > perform a specific limited function that could be audited much cheaper, > provided the CA systems were set up to have little dependency on > certificate specific activities and security at the RAs. > This misunderstands Policy 1 then, and is perhaps the substance of our unintentional disagreement. if a CA sets up and maintains one (set of) sub CAs for each RA, then each of those subCAs would need to be audited. This is no different than the existing requirements, within the Baseline Requirements, that each DTP be audited. I would highlight Section 8 of the Baseline Requirements for you, and ask that you clarify where, under the existing policies (e.g. ignoring any policy proposal) you believe there is any provision for allowing a DTP to be "audited much cheaper". If you believe such a thing is possible (I would argue incorrectly so, but hear me out), then what we're effectively saying is that a set of Principles and Criteria are not examined by the audit, because the operation and majority of the controls are managed by the "Issuing CA" - at least, within the world today of CA/RA relationships. If we believe such a thing is accepted (and again, not supported by the Baseline Requirements, and to the extent of my interactions with various auditor/practitioners, I do not believe currently supported by WebTrust), then I hope you can also see that we can use that self-same logic to conclude that a DTP operating as a externally operated sub-CA - but one in which the "Issuing CA" handles the operation and majority of controls for - is effectively the same thing. Do you agree with that logic? Can you clarify where and why you disagree with the analysis above? > For example, an RA whose sole involvement is to receive a daily list of > company name/idno/address/authorized signatory for pending > applications, go down to the state hall of records and report back > which ones match/do not match official company records (to support EV > certification for that state) would only need auditing of that activity > and the security of the system used to exchange that list and report > with the CAs central validation team. Please provide a citation to the Baseline Requirements or Mozilla policy to support this statement. I would suggest Section 8.4 provides counter-evidence to this claim, and as such, because the argument rests on this claim, needs to be addressed before we might make further progress. > They should not need to pay a > local WebTrust auditor to certify that the many activities done > centrally at the CA (in a different country altogether) meet any > particular requirements, as that should be in scope only for the actual > auditing of the central CA (which should include auditing of the > presence and compliance of the RA audit reports). > > For the "Enterprise customer" "DTP" case, I think subjecting each > Enterprise that has a "cheaply issue certs for subnames" account to any > kind of special audit would be as mindbogglingly onerous as requiring > every shop that accepts credit cards via a 3rd party such as Google to > go through and comply with full PCI certification for systems that > never see credit card numbers, only the shopping cart. For this case, the only thing that needs auditing is that the CA itself > has properly validated that the Enterprise customer has the full > authority to decide and state which of the acceptable subnames are who > they say they are (as per DNS zone delegations for DNSnames, per mail > domain ownership as per e-mail names etc.). In other words the only > thing the Enterprise customer
Re: Symantec: Next Steps
On 08/03/2017 04:21, Ryan Sleevi wrote: On Tue, Mar 7, 2017 at 8:08 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: I contradicted you in saying that RAs (or DTP as you now want to call them) were not supposed to be banned by the policy change. DTPs are the terms from the Baseline Requirements. All responsibilities and expectations are associated with that term. As to the statement "were not supposed to be banned by the policy change", I don't believe Gerv stated that, so it would be useful to understand why you've stated that. These were a variety of policy proposals - all of which are meant to change and/or clarify requirements - so I don't think we can state that simply removing the concept is off the table. I saw nothing in Gervs posting suggesting that banning all kinds of RA/DTP relationships was the intended effect. As to the rest of your message, you describe what have historically been called RAs/DTPs. You have not, however, answered my question - which is what impact, if any, do you believe would happen if Mozilla considers the policy I suggested: That is, to require that anything which 'historically' was considered an RA be treated as an externally operated sub-CA. For the kind of RA that is a combined reseller/control everything related to issuing (the Symantec case), there would be no significant change in burden for the RA. For the kind of RA that only does specific relevant parts of validation (a "traditional" RA), the suggested policy as written would "simply" require the CA to set up and maintain one (set of) subCAs for each of their RAs, while your rephrasing as a ban on RA/DTP relationships would impose the full cost of a formal WebTrust (etc.) audit on RAs that only perform a specific limited function that could be audited much cheaper, provided the CA systems were set up to have little dependency on certificate specific activities and security at the RAs. For example, an RA whose sole involvement is to receive a daily list of company name/idno/address/authorized signatory for pending applications, go down to the state hall of records and report back which ones match/do not match official company records (to support EV certification for that state) would only need auditing of that activity and the security of the system used to exchange that list and report with the CAs central validation team. They should not need to pay a local WebTrust auditor to certify that the many activities done centrally at the CA (in a different country altogether) meet any particular requirements, as that should be in scope only for the actual auditing of the central CA (which should include auditing of the presence and compliance of the RA audit reports). For the "Enterprise customer" "DTP" case, I think subjecting each Enterprise that has a "cheaply issue certs for subnames" account to any kind of special audit would be as mindbogglingly onerous as requiring every shop that accepts credit cards via a 3rd party such as Google to go through and comply with full PCI certification for systems that never see credit card numbers, only the shopping cart. For this case, the only thing that needs auditing is that the CA itself has properly validated that the Enterprise customer has the full authority to decide and state which of the acceptable subnames are who they say they are (as per DNS zone delegations for DNSnames, per mail domain ownership as per e-mail names etc.). In other words the only thing the Enterprise customer is delegated to validate is those things for which the Enterprise customer is the ultimate authority anyway. I assert that there remains functional equivalence in role and capabilities, but greater clarity as to expectations and audits. It would be useful if, for example, you could highlight how such a policy would create any form of new burden or requirement beyond the desired attributes - technical capability to revoke and greater assurance of compliance through public disclosure. Set aside the terminology question - and just focus on the practical impact, if any. Again, I assert, there is no negative impact, and any impact is the desired degree of clarification for which Delegated Third Parties are already nominally expected to be. As a practical matter regarding audits, there's no supporting evidence for the claim that RAs/Delegated Third Parties are allowed to be subject to less audit requirements than CAs. I'd be curious if you could provide any evidence in the Baseline Requirements or Mozilla Inclusion Policy to support this claim, since it would seem to me this is the crux of your objection. In short, I'm hoping you can help me understand * Why you believe it was not intended to 'eliminate' (though the functional role remains) Delegated Third Parties * Why you believe that Delegated Third Parties are subject to any less audit requirement than Externally-Operated Subordinate CAs You've stated what you believe, but I
Re: Symantec: Next Steps
On Tue, Mar 7, 2017 at 8:08 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > I contradicted you in saying that RAs (or DTP as you now want to call > them) were not supposed to be banned by the policy change. > DTPs are the terms from the Baseline Requirements. All responsibilities and expectations are associated with that term. As to the statement "were not supposed to be banned by the policy change", I don't believe Gerv stated that, so it would be useful to understand why you've stated that. These were a variety of policy proposals - all of which are meant to change and/or clarify requirements - so I don't think we can state that simply removing the concept is off the table. As to the rest of your message, you describe what have historically been called RAs/DTPs. You have not, however, answered my question - which is what impact, if any, do you believe would happen if Mozilla considers the policy I suggested: That is, to require that anything which 'historically' was considered an RA be treated as an externally operated sub-CA. I assert that there remains functional equivalence in role and capabilities, but greater clarity as to expectations and audits. It would be useful if, for example, you could highlight how such a policy would create any form of new burden or requirement beyond the desired attributes - technical capability to revoke and greater assurance of compliance through public disclosure. Set aside the terminology question - and just focus on the practical impact, if any. Again, I assert, there is no negative impact, and any impact is the desired degree of clarification for which Delegated Third Parties are already nominally expected to be. As a practical matter regarding audits, there's no supporting evidence for the claim that RAs/Delegated Third Parties are allowed to be subject to less audit requirements than CAs. I'd be curious if you could provide any evidence in the Baseline Requirements or Mozilla Inclusion Policy to support this claim, since it would seem to me this is the crux of your objection. In short, I'm hoping you can help me understand * Why you believe it was not intended to 'eliminate' (though the functional role remains) Delegated Third Parties * Why you believe that Delegated Third Parties are subject to any less audit requirement than Externally-Operated Subordinate CAs You've stated what you believe, but I cannot find evidence to support either claim. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec: Next Steps
On 08/03/2017 01:40, Ryan Sleevi wrote: On Tue, Mar 7, 2017 at 6:26 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: On 07/03/2017 21:37, Ryan Sleevi wrote: To make it simpler, wouldn't be a Policy Proposal be to prohibit Delegated Third Parties from participating in the issuance process? This would be effectively the same, in as much as the only capability to allow a third-party to participate in issuance is to operate a subordinate CA. I think it's procedurally identical to Policy Proposal 1, but it clarifies more explicitly that RAs are forbidden, and that all participants in the issuance ecosystem have a specific set of obligations. The point is NOT to prohibit RAs (which are a good thing if done right), but to allow revocation of certificates validated by a rogue RA. The setup under policy 1 would be that the actual CA holds the key and issuance systems in its own right and under its own security audits, while the RA only deals with the actual verification steps (such as checking that Foo Inc is actually incorporated in country X with official address on Bar Avenue 123 in Baz City according to official records in the local language). Policy 1 is also intended for the reseller-RA combination seen in the Symantec case, where the reseller-RA does other steps that could/should be done by the CA directly (such as domain validation and suspicious case double checking). Policy 1 may still be a problem for the truly local RA scenario where a large number of similar RAs handle in-person verification steps for a small geographic area (such as schemes where each city hall handles checking photo ID of applicants as part of validation at better than EV level). Jakob, You basically restated what I said, except still kept the term "RA". Note that my proposal would not have eliminated the conceptual role you're describing - this is still facilitated - but it's explicitly called out as an externally operated subordinate CA, with all the attendant responsibility and audit criteria. The fact that one or more pieces of infrastructure is offered by the issuing CA is nothing new, in practice, and so the ecosystem already deals with (or fails to deal with) this case. So perhaps it's useful if you can explain why "Delegated Third Party" (since RA is overloaded to include the pre-validated domain case of an Enteprise RA, as well as to cover the case where an RA does not perform domain validation) is a useful concept to support, versus simply treating it as the well-understood role of externally-operated subordinate CA? I contradicted you in saying that RAs (or DTP as you now want to call them) were not supposed to be banned by the policy change. The point of a general-purpose RA (such as the ones that failed in the Symantec case) is that they are supposed to explicitly perform fewer functions and be subject to corresponding reduced requirements (especially if properly setup from the CA end), and are to be audited accordingly (without duplicated pseudo audit statements about the nature of the CA hosted infrastructure). Another type of true RA in the traditional sense is an office that performs specific limited parts of the validation, with the main CA doing the rest. For example the RA would check things that cannot be checked from wherever the CA is located (in person identification, access to local official records in local language etc.), while the CA would do all the checks that don't depend on local knowledge, such as domain checks, BR enforcement etc. These would be subject to even less audit requirements compared to a subCA, since they perform an even more limited subset of CA functions. A type of Delegated Third Party that isn't an RA in the traditional sense (but may fall under some RA definitions) would be a pre-validated Enterprise authorized to request certificates for entities that are fully nested under its validated name spaces (domains, distinguished names), with the CA reusing (under the 39 month rule) validations of those name spaces as being under full control of the enterprise. Those enterprises could in fact be considered as being mere subscribers rather than delegated third parties. Except for the proposed new special policy (which serves only to provide a centralized way for Mozilla to revoke all certificates issued through a specific RA, and only in cases where the CA is somehow unwilling to revoke those certificates itself while Mozilla is unwilling to revoke the CA trust), there is nothing that should conflate the DTP and CA roles. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org
Re: Symantec: Next Steps
On Tue, Mar 7, 2017 at 6:26 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 07/03/2017 21:37, Ryan Sleevi wrote: >> >> To make it simpler, wouldn't be a Policy Proposal be to prohibit Delegated >> Third Parties from participating in the issuance process? This would be >> effectively the same, in as much as the only capability to allow a >> third-party to participate in issuance is to operate a subordinate CA. >> >> I think it's procedurally identical to Policy Proposal 1, but it clarifies >> more explicitly that RAs are forbidden, and that all participants in the >> issuance ecosystem have a specific set of obligations. >> >> > The point is NOT to prohibit RAs (which are a good thing if done > right), but to allow revocation of certificates validated by a rogue RA. > > The setup under policy 1 would be that the actual CA holds the key and > issuance systems in its own right and under its own security audits, > while the RA only deals with the actual verification steps (such as > checking that Foo Inc is actually incorporated in country X with > official address on Bar Avenue 123 in Baz City according to official > records in the local language). > > Policy 1 is also intended for the reseller-RA combination seen in the > Symantec case, where the reseller-RA does other steps that could/should > be done by the CA directly (such as domain validation and suspicious > case double checking). > > Policy 1 may still be a problem for the truly local RA scenario where a > large number of similar RAs handle in-person verification steps for a > small geographic area (such as schemes where each city hall handles > checking photo ID of applicants as part of validation at better > than EV level). > Jakob, You basically restated what I said, except still kept the term "RA". Note that my proposal would not have eliminated the conceptual role you're describing - this is still facilitated - but it's explicitly called out as an externally operated subordinate CA, with all the attendant responsibility and audit criteria. The fact that one or more pieces of infrastructure is offered by the issuing CA is nothing new, in practice, and so the ecosystem already deals with (or fails to deal with) this case. So perhaps it's useful if you can explain why "Delegated Third Party" (since RA is overloaded to include the pre-validated domain case of an Enteprise RA, as well as to cover the case where an RA does not perform domain validation) is a useful concept to support, versus simply treating it as the well-understood role of externally-operated subordinate CA? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec: Next Steps
On 07/03/2017 21:37, Ryan Sleevi wrote: On Tue, Mar 7, 2017 at 6:37 AM, Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: Policy Proposal 1: require all CAs to arrange it so that certs validated by an RA are issued from one or more intermediates dedicated solely to that RA, with such intermediates clearly labelled with the name of the RA in the Subject. If we enact Policy Proposal 1, that allows RAs to be cut off, and also provides a natural point for the CP/CPS and audits of the RA to be monitored in the CCADB, because they would be attached by the CA to the issuing intermediate for that RA. Symantec's oversight of their RAs was clearly inadequate; various forms of misissuance were not detected. To make it simpler, wouldn't be a Policy Proposal be to prohibit Delegated Third Parties from participating in the issuance process? This would be effectively the same, in as much as the only capability to allow a third-party to participate in issuance is to operate a subordinate CA. I think it's procedurally identical to Policy Proposal 1, but it clarifies more explicitly that RAs are forbidden, and that all participants in the issuance ecosystem have a specific set of obligations. The point is NOT to prohibit RAs (which are a good thing if done right), but to allow revocation of certificates validated by a rogue RA. The setup under policy 1 would be that the actual CA holds the key and issuance systems in its own right and under its own security audits, while the RA only deals with the actual verification steps (such as checking that Foo Inc is actually incorporated in country X with official address on Bar Avenue 123 in Baz City according to official records in the local language). Policy 1 is also intended for the reseller-RA combination seen in the Symantec case, where the reseller-RA does other steps that could/should be done by the CA directly (such as domain validation and suspicious case double checking). Policy 1 may still be a problem for the truly local RA scenario where a large number of similar RAs handle in-person verification steps for a small geographic area (such as schemes where each city hall handles checking photo ID of applicants as part of validation at better than EV level). Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec: Next Steps
On Tue, Mar 7, 2017 at 6:37 AM, Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Policy Proposal 1: require all CAs to arrange it so that certs validated > by an RA are issued from one or more intermediates dedicated solely to > that RA, with such intermediates clearly labelled with the name of the > RA in the Subject. > > If we enact Policy Proposal 1, that allows RAs to be cut off, and also > provides a natural point for the CP/CPS and audits of the RA to be > monitored in the CCADB, because they would be attached by the CA to the > issuing intermediate for that RA. > > Symantec's oversight of their RAs was clearly inadequate; various forms > of misissuance were not detected. > > To make it simpler, wouldn't be a Policy Proposal be to prohibit Delegated Third Parties from participating in the issuance process? This would be effectively the same, in as much as the only capability to allow a third-party to participate in issuance is to operate a subordinate CA. I think it's procedurally identical to Policy Proposal 1, but it clarifies more explicitly that RAs are forbidden, and that all participants in the issuance ecosystem have a specific set of obligations. > > > Failures > > > As noted by module peer Ryan Sleevi, this is not the first time Symantec > has had difficulties with misissued "test" certificates. It is > disappointing that investigations related to the last incident did not > turn up the problems which have now been discovered. Various forms of > investigation and remediation were not, apparently, applied to > Symantec's RA network in the same way they were supposedly applied at > Symantec. > > It seems to me that Symantec's claim is of lack of knowledge - that they > contracted and trained CrossCert to do the right things, and the > auditors said that they were, and they had no evidence that they were > not, and so they assumed everything was fine. The question is whether > that lack of knowledge amounts to negligence. > > Comments on this topic, with careful justification, are invited. > > [The alleged audit failures, as opposed to alleged failures by Symantec, > will be discussed in a separate process.] > Gerv, have you examined the most recent set of audits? Do you, in your capacity as CA Certificate policy peer, believe the audits were correct for their capability and role? Note that several of them were "WebTrust for CAs" - not "WebTrust for CAs - SSL BR and Network Security". Do you believe that complies with letter of the Baseline Requirements? Similarly, do you believe Symantec had an obligation to ensure the proper licensing status of auditors, prior to accepting such audits? I think these may represent important questions for Mozilla to determine, in order to evaluate the fullness of the claim you have summarized, and I think would equally apply if we were discussing externally-operated subordinate CAs, correct? Considering the capability afforded to these RAs - full certificate issuance through independent domain validation - I'm curious whether you believe this materially represents a practical distinction from the issuance of an unconstrained subordinate CA, and how responsible the issuing CA is for overseeing those operations. How would Mozilla respond if in every case of "RA", it was replaced with "Sub-CA"? That seems to be the guiding principle here, since they're functionally indistinguishable in this case, except the RA brought with it even greater risk, and lacked sufficient audit controls or technical mitigations to prevent unauthorized access or ensure adequate logging. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy