Re: Requirements for CNNIC re-application
On 6/17/15 12:05 PM, Kathleen Wilson wrote: Therefore, the result of this discussion is as follows: == CNNIC may re-apply for full inclusion following the normal process, after they have completed the following additional steps. 1. Provide a list of changes CNNIC has implemented to ensure that there are no future violations of Mozilla Policy and the Baseline Requirements. 2. Improve CNNIC’s process for authorizing intermediate CAs, and fully document this improved process in the CP/CPS. 3. Include in this year's WebTrust audit an explicit confirmation by the auditor that these changes have been implemented and enforced. 4. Provide auditor attestation that a full performance audit has been performed confirming BR compliance according to https://wiki.mozilla.org/CA:BaselineRequirements 5. April 1, 2016 is the earliest date at which CNNIC may apply for full inclusion. If approved, we will remove the restriction currently in place on their SSL certificates issued after Apr 1 2015. If denied, we will remove the CNNIC root certificates from NSS. == Please reply if you see any errors in this. Otherwise, I will close this discussion and communicate this to CNNIC. Thanks again to all of you who participated in this discussion. I have recorded the above action items in https://bugzilla.mozilla.org/show_bug.cgi?id=1177209 I am now closing this discussion, and will communicate the above information to CNNIC. Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Requirements for CNNIC re-application
On 5/22/15 2:15 PM, Kathleen Wilson wrote: On 4/7/15 5:31 PM, Richard Barnes wrote: As noted in our earlier conclusion with regard to CNNIC's status [1], the CNNIC roots are currently in a partially disabled state, in which certificates chaining to these roots are only to be accepted if they were issued before 1 Apr 2015. CNNIC may reapply for full inclusion following the normal process, along with any additional steps that this community decides to require of them. The purpose of this thread is to discuss what additional steps, if any, we should require. CNNIC has already provided Mozilla with a list of certificates issued before 1 Apr 2015. We are working on publishing this list. CNNIC has also informed Mozilla that they plan to take the following steps: snip [1] https://groups.google.com/d/msg/mozilla.dev.security.policy/czwlDNbwHXM/qPcyC_DWlSwJ [2] http://googleonlinesecurity.blogspot.com/2015/03/maintaining-digital-certificate-security.html [3] http://tools.ietf.org/html/rfc6962 Here is my interpretation of the result of this discussion, and what I should communicate to CNNIC... CNNIC may re-apply for full inclusion following the normal process, after they have completed the following additional steps. 1. Provide a list of changes CNNIC has implemented to ensure that there are no future violations of Mozilla Policy and the Baseline Requirements. 2. Improve CNNIC’s process for authorizing intermediate CAs, and fully document this improved process in the CP/CPS. 3. Include in this year's WebTrust audit an explicit confirmation by the auditor that these changes have been implemented and enforced. 4. Provide auditor attestation that a full performance audit has been performed confirming BR compliance according to https://wiki.mozilla.org/CA:BaselineRequirements 5. April 1, 2016 is the earliest date at which CNNIC may apply for full inclusion, so SSL certificates issued after Apr 1 2015 for new domains will be recognized. Please reply if I've missed anything that needs to be added to this list. Thanks, Kathleen Thanks to all of you for your input on this. To summarize... Re-write item #5, to: April 1, 2016 is the earliest date at which CNNIC may apply for full inclusion. If approved, we will remove the restriction currently in place on their SSL certificates issued after Apr 1 2015. If denied, we will remove the CNNIC root certificates from NSS. CT -- Continued discussion about whether Mozilla should require CNNIC to implement CT. I've decided that I will not require this of CNNIC before they may re-apply. While I am completely in favor of transparency, there are still questions about the implementation details that are being discussed elsewhere. New root cert -- Gerv's argument on June 11 against requiring CNNIC to re-apply with a new root cert resonated with me. So I am not going to add this requirement. Therefore, the result of this discussion is as follows: == CNNIC may re-apply for full inclusion following the normal process, after they have completed the following additional steps. 1. Provide a list of changes CNNIC has implemented to ensure that there are no future violations of Mozilla Policy and the Baseline Requirements. 2. Improve CNNIC’s process for authorizing intermediate CAs, and fully document this improved process in the CP/CPS. 3. Include in this year's WebTrust audit an explicit confirmation by the auditor that these changes have been implemented and enforced. 4. Provide auditor attestation that a full performance audit has been performed confirming BR compliance according to https://wiki.mozilla.org/CA:BaselineRequirements 5. April 1, 2016 is the earliest date at which CNNIC may apply for full inclusion. If approved, we will remove the restriction currently in place on their SSL certificates issued after Apr 1 2015. If denied, we will remove the CNNIC root certificates from NSS. == Please reply if you see any errors in this. Otherwise, I will close this discussion and communicate this to CNNIC. Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Requirements for CNNIC re-application
On 30/05/15 20:20, Brian Smith wrote: By the way, what is Firefox's market share in China and other places that commonly use CNNIC-issued certificates? My understanding is that it is close to 0%. That's why it was relatively easy to remove them in the first place. It also means that there's no need to rush to add them back, AFAICT. I don't know, but I don't think we should let Firefox market share numbers or our perception of a CA's area of operations affect what we decide about roots in the program (which is used by more apps than Firefox). Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Requirements for CNNIC re-application
On 28/05/15 23:07, Richard Barnes wrote: I agree that if CNNIC is to reapply, it should be with a new root. It creates a clean break between the past and the future. It clarifies that the new audits that are required apply to the new thing, and that the old thing is dead. It's marginally easier to implement. Note my post up-thread; in saying this, are you aware of the significantly greater level of sanction that this request imposes as a side-effect? Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Requirements for CNNIC re-application
On 28/05/15 00:32, Peter Kurrasch wrote: I think this is the crux of the problem: how do we want to treat all the existing certs which chain to this root? That's not the only problem. Requiring CNNIC to apply with a new root would also require them to go through the inclusion process again in every other browser, and then wait until their new root had sufficient ubiquity for it to be worth issuing certificates from it. We have imposed a 1-year delay on their application for re-inclusion. Requiring that they do so with a new root would, I guess, add another 3-5 years before they could issue certificates again. If we think that we have appropriately calibrated the sanctions against CNNIC as we stand now, then it's worth noting that adding this requirement would seriously jack them up. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Requirements for CNNIC re-application
On Tue, May 26, 2015 at 5:50 AM, Gervase Markham g...@mozilla.org wrote: On 24/05/15 06:19, percyal...@gmail.com wrote: This is Percy from GreatFire.org. We have long advocated for the revoking of CNNIC. https://www.google.com/webhp?sourceid=chrome-instantion=1espv=2ie=UTF-8#q=site%3Agreatfire.org%20cnnic If CNNIC were to re-included, CT MUST be implemented. At the moment, Mozilla does not have an official position of support for CT - we are watching with interest :-) Therefore, it's not really appropriate for Mozilla to mandate CT-related things as conditions of reinclusion for CNNIC. We should be careful we don't don't turn that into Mozilla doesn't implement CT, so Mozilla has to allow CNNIC back in without requiring CT, even if it would be clearly less safe to do so. A better interpretation would be Mozilla can't let CNNIC back in until it implements CT or similar, because doing so would be clearly less safe. By the way, what is Firefox's market share in China and other places that commonly use CNNIC-issued certificates? My understanding is that it is close to 0%. That's why it was relatively easy to remove them in the first place. It also means that there's no need to rush to add them back, AFAICT. Cheers, Brian ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Requirements for CNNIC re-application
On Wed, May 27, 2015 at 4:32 PM, Peter Kurrasch fhw...@gmail.com wrote: I see this question (new root cert/private key or continue with the existing one) as being less about security and more about what got us here in the first place. From Ryan's reply: 1) Certificates that violate policy (such as the one that lead to CNNIC's quasi-removal) may have been issued that, if CNNIC were accepted, would become recognized as valid. I think this is the crux of the problem: how do we want to treat all the existing certs which chain to this root? If we let the existing root stand it seems like we're saying to CNNIC, Go ahead and do these audits and then once you've been accepted back in the program we'll just pretend that this whole thing never happened. There are probably good reasons to do just that (convenience to cert holders, expediency in reinstating CNNIC's root) but then I have to rethink what started this whole mess: the loss of trust/confidence in the management of this CA. Since losing that trust, why would (should?) we allow any of those certs to be valid once more? How do we know which ones are safe to trust? To my mind, if the question being asked is how do we reestablish trust in CNNIC then I think the answer is new private key, new root cert, new audits, and new certs issued to existing cert holders. If it's a different question being asked, we'll probably have a different answer. I think Peter is on the right track here. I agree that if CNNIC is to reapply, it should be with a new root. It creates a clean break between the past and the future. It clarifies that the new audits that are required apply to the new thing, and that the old thing is dead. It's marginally easier to implement. This does have the consequence that certificates issued under the old root after the April 1 cut-off will never be valid (unless they're re-issued under the new root). (I understand that there are a few of these that have been issued.) I'm OK with that consequence. --Richard Original Message From: Gervase Markham Sent: Wednesday, May 27, 2015 4:41 AM On 26/05/15 22:26, Kathleen Wilson wrote: But this raises the question of whether their re-application can be for the same (currently-included) root certificates, or if it has to be for a new root certificate. In other words, should we consider taking the stance that we will require a new root certificate for their re-application? (i.e. the restrictions would remain in place for the currently-included roots.) I see no security advantage in requiring new roots. Doing so would be an inconvenience (one might say punishment) to CNNIC, and someone might want to argue for it on those grounds, but I can't see how requiring new roots changes any security evaluation, because there has been no suggestion that their roots are either a) technically unsound, or b) compromised. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Requirements for CNNIC re-application
On Tue, May 26, 2015 10:56 pm, Matt Palmer wrote: On Tue, May 26, 2015 at 02:26:33PM -0700, Kathleen Wilson wrote: But this raises the question of whether their re-application can be for the same (currently-included) root certificates, or if it has to be for a new root certificate. In other words, should we consider taking the stance that we will require a new root certificate for their re-application? (i.e. the restrictions would remain in place for the currently-included roots.) I think it would be best if CNNIC did not re-use the same roots when applying for reinclusion. I think it best that we settle this particular matter quickly, since it has the greatest impact on CNNIC's ability to adapt to any program requirements for re-inclusion. This, among every other requirement, has the greatest impact to timing, implementation (e.g. must be ceremonialized key construction), and evaluation. For what it's worth, I have a hard time seeing the benefits to requiring a new root, especially as it's played out for other inclusions, and in practice how it's played out for non-BR compliance (of which there are still a variety of CAs that are either non-compliant or have qualifications on their compliance). Naturally, the concern is the ambiguity for the period of time between removal and re-inclusion. However, that's a time that can be audited (no different than a point-in-time readiness assessment plus a covering period of time ex-post audit, arguably). Now, perhaps we don't trust the audits - after all, there were deficiencies in technical controls that lead to an event that was, from an auditor's perspective, undiscoverable, and it was only through sheer luck that it happened to be noticed. But that's a problem inherent to and endemic in audits, and doesn't disappear when you replace with a new root (... which will have a PITRA before application, and a period of time after application). While I realize Gerv responded earlier that Mozilla does not have an official position of support for CT, it is worth noting that this ambiguity (both during new inclusions and, potentially, for re-inclusions) is something that CT can solve quite well. This is because it offers a way to disclose the existing certs issued in the interim, if any (establishing reasonable evidence of good faith), and, if technically enforced (e.g. via a policy of trusted logs), provide strong assurances that there are no misissued certificates that might be trusted between the point of removal and the point of reinclusion (and all points in the future) To circle back on the new root, and to explain why I don't think it makes sense, the arguments would be: 1) Certificates that violate policy (such as the one that lead to CNNIC's quasi-removal) may have been issued that, if CNNIC were accepted, would become recognized as valid. 2) Auditors may not discover such certificates in the interim audit periods. #2 is true regardless of new or existing root. #1 can be mitigated through a variety of means (CT would reveal the policy violation, a date enforcement of a notBefore check could offer a soft policy check, I'm sure other options exist) that don't necessarily require creating a new root. Anyways, it would help to spell out the problems you think would be solved by a new root, even if not exhaustively, so that the arguments can be evaluated. Given the impact to CNNIC, we (the Mozilla-trusting community) need to have that conversation sooner than later, so I appreciate Kathleen pushing it forward. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Requirements for CNNIC re-application
On 26/05/15 22:26, Kathleen Wilson wrote: But this raises the question of whether their re-application can be for the same (currently-included) root certificates, or if it has to be for a new root certificate. In other words, should we consider taking the stance that we will require a new root certificate for their re-application? (i.e. the restrictions would remain in place for the currently-included roots.) I see no security advantage in requiring new roots. Doing so would be an inconvenience (one might say punishment) to CNNIC, and someone might want to argue for it on those grounds, but I can't see how requiring new roots changes any security evaluation, because there has been no suggestion that their roots are either a) technically unsound, or b) compromised. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Requirements for CNNIC re-application
Gerv, I saw the previous thread on name constrain on possibly all gov CAs.But I have to point out that state hackers routinely uses legit software vendors to sign malware. Stating that I'm not an CA expert, CT sounds much more effective and less subjective than constrain government CAs HTTPSeverywhere has a certificate observatory which can be adapted to this purpose. I would think the number of problematic sites (e.g switching between CNNIC and Verisign) is quite small. Those incidents can be examined manually, for example, emailing the domain owner to check legitimacy. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Requirements for CNNIC re-application
On Tue, May 26, 2015 at 02:26:33PM -0700, Kathleen Wilson wrote: But this raises the question of whether their re-application can be for the same (currently-included) root certificates, or if it has to be for a new root certificate. In other words, should we consider taking the stance that we will require a new root certificate for their re-application? (i.e. the restrictions would remain in place for the currently-included roots.) I think it would be best if CNNIC did not re-use the same roots when applying for reinclusion. - Matt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Requirements for CNNIC re-application
On 5/22/15 4:24 PM, Ryan Sleevi wrote: Nothing is said in the current policy for the population of existing certs - whether or not they comply either to the BRs or to the CA's existing policies. This is somewhat obliquely discussed at https://wiki.mozilla.org/CA:BaselineRequirements#A_CA.27s_First_BR_Audit when discussing a CA's first application, which is conceptually quite similar to a CA that was bounced and then reapplies. The last paragraph of that section is probably most relevant to future discussions of reapplication - determining how to handle this. So this does not get overlooked... https://wiki.mozilla.org/CA:BaselineRequirements#A_CA.27s_First_BR_Audit In the situation where a root certificate is in production and has issued certificates to customers before the CA knew about the BRs, an untold number of the previously issued certificates might not conform to the BRs. This could be serious, depending on which BRs the CA did not previously comply with, the number of BRs the CA did not previously comply with, and the quantity of such certificates issued. Depending on the situation, the CA may be asked to create a new root certificate for inclusion. Therefore, the CA and/or auditor shall provide a list of the BRs that the previously issued certificates did not comply with. Granted, CNNIC did know about the BRs (and were audited according to the BRs) before their mis-issuance. But this raises the question of whether their re-application can be for the same (currently-included) root certificates, or if it has to be for a new root certificate. In other words, should we consider taking the stance that we will require a new root certificate for their re-application? (i.e. the restrictions would remain in place for the currently-included roots.) Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Requirements for CNNIC re-application
Hi Percy, On 24/05/15 06:19, percyal...@gmail.com wrote: This is Percy from GreatFire.org. We have long advocated for the revoking of CNNIC. https://www.google.com/webhp?sourceid=chrome-instantion=1espv=2ie=UTF-8#q=site%3Agreatfire.org%20cnnic If CNNIC were to re-included, CT MUST be implemented. At the moment, Mozilla does not have an official position of support for CT - we are watching with interest :-) Therefore, it's not really appropriate for Mozilla to mandate CT-related things as conditions of reinclusion for CNNIC. Google, of course, does not have to follow Mozilla's trust decisions and they may impose their own conditions for re-inclusion in Chrome. Name constrains to .cn is strongly recommended. We are having a discussion about the general principle of name-constraining government CAs at the moment. Please read the introductory message carefully, and then you are welcome to participate. Is it possible to include additional CA checks for CNNIC? For example, if a website is signed by both verisign and CNNIC in a short period, it will be flagged for manual renew. I'm not sure exactly how that would work. Who would do this check, and when, and what would they do if they found something they thought was problematic? Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Requirements for CNNIC re-application
On Fri, May 22, 2015 at 7:24 PM, Ryan Sleevi ryan-mozdevsecpol...@sleevi.com wrote: On Fri, May 22, 2015 3:11 pm, Eric Mill wrote: On Fri, May 22, 2015 at 5:15 PM, Kathleen Wilson kwil...@mozilla.com wrote: On 4/7/15 5:31 PM, Richard Barnes wrote: 5. April 1, 2016 is the earliest date at which CNNIC may apply for full inclusion, so SSL certificates issued after Apr 1 2015 for new domains will be recognized. Do you mean will *not* be recognized? Fair question. Either answer could work, although will not be recognized would be more work and more inconsistent, historically. Well, I think I just misunderstood the phrasing? I thought that Kathleen was pointing out that since they won't be able to make it back into the trust store until at least mid-2016, their certs they issue since their inclusion won't be recognized for the near future, so I thought it was a typo. Using your message as context, I now read Kathleen's original statement as: 5. April 1, 2016 is the earliest date at which CNNIC may apply for full inclusion, so [that maybe eventually their] SSL certificates issued after Apr 1 2015 for new domains will be recognized [retroactively once they are accepted]. Which makes more sense. -- Eric ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Requirements for CNNIC re-application
Sent from my iPhone. Please excuse brevity. On May 23, 2015, at 02:22, Eric Mill e...@konklone.com wrote: On Fri, May 22, 2015 at 7:24 PM, Ryan Sleevi ryan-mozdevsecpol...@sleevi.com wrote: On Fri, May 22, 2015 3:11 pm, Eric Mill wrote: On Fri, May 22, 2015 at 5:15 PM, Kathleen Wilson kwil...@mozilla.com wrote: On 4/7/15 5:31 PM, Richard Barnes wrote: 5. April 1, 2016 is the earliest date at which CNNIC may apply for full inclusion, so SSL certificates issued after Apr 1 2015 for new domains will be recognized. Do you mean will *not* be recognized? Fair question. Either answer could work, although will not be recognized would be more work and more inconsistent, historically. Well, I think I just misunderstood the phrasing? I thought that Kathleen was pointing out that since they won't be able to make it back into the trust store until at least mid-2016, their certs they issue since their inclusion won't be recognized for the near future, so I thought it was a typo. Using your message as context, I now read Kathleen's original statement as: 5. April 1, 2016 is the earliest date at which CNNIC may apply for full inclusion, so [that maybe eventually their] SSL certificates issued after Apr 1 2015 for new domains will be recognized [retroactively once they are accepted]. Which makes more sense. That matches my thinking. That is: -- Before their re-application request is decided one way or another, their certs are processed under the current rules. Simply reapplying does not trigger any change. -- If the re-application request is denied, then they will be fully removed, and even certs currently accepted will be rejected. -- If they are accepted, then we will have to decide what to do about the corpus of certs issued in the interim. But that seems like a topic for the re-application thread, not this thread about prerequisites. For purposes of this thread, I think we just need to strike the text that has everyone confused, leaving us with: 5. April 1, 2016 is the earliest date at which CNNIC may apply for full inclusion -- Eric ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Requirements for CNNIC re-application
On Fri, May 22, 2015 at 5:15 PM, Kathleen Wilson kwil...@mozilla.com wrote: On 4/7/15 5:31 PM, Richard Barnes wrote: 5. April 1, 2016 is the earliest date at which CNNIC may apply for full inclusion, so SSL certificates issued after Apr 1 2015 for new domains will be recognized. Do you mean will *not* be recognized? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Requirements for CNNIC re-application
On 4/7/15 5:31 PM, Richard Barnes wrote: As noted in our earlier conclusion with regard to CNNIC's status [1], the CNNIC roots are currently in a partially disabled state, in which certificates chaining to these roots are only to be accepted if they were issued before 1 Apr 2015. CNNIC may reapply for full inclusion following the normal process, along with any additional steps that this community decides to require of them. The purpose of this thread is to discuss what additional steps, if any, we should require. CNNIC has already provided Mozilla with a list of certificates issued before 1 Apr 2015. We are working on publishing this list. CNNIC has also informed Mozilla that they plan to take the following steps: snip [1] https://groups.google.com/d/msg/mozilla.dev.security.policy/czwlDNbwHXM/qPcyC_DWlSwJ [2] http://googleonlinesecurity.blogspot.com/2015/03/maintaining-digital-certificate-security.html [3] http://tools.ietf.org/html/rfc6962 Here is my interpretation of the result of this discussion, and what I should communicate to CNNIC... CNNIC may re-apply for full inclusion following the normal process, after they have completed the following additional steps. 1. Provide a list of changes CNNIC has implemented to ensure that there are no future violations of Mozilla Policy and the Baseline Requirements. 2. Improve CNNIC’s process for authorizing intermediate CAs, and fully document this improved process in the CP/CPS. 3. Include in this year's WebTrust audit an explicit confirmation by the auditor that these changes have been implemented and enforced. 4. Provide auditor attestation that a full performance audit has been performed confirming BR compliance according to https://wiki.mozilla.org/CA:BaselineRequirements 5. April 1, 2016 is the earliest date at which CNNIC may apply for full inclusion, so SSL certificates issued after Apr 1 2015 for new domains will be recognized. Please reply if I've missed anything that needs to be added to this list. Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Requirements for CNNIC re-application
CT is an accountability control, not an access control We need both Sent from my difference engine On Apr 14, 2015, at 18:05, Matt Palmer mpal...@hezmatt.org wrote: On Tue, Apr 14, 2015 at 01:38:55PM +0200, Kurt Roeckx wrote: On 2015-04-14 01:15, Peter Kurrasch wrote: Let's use an example. Suppose CNNIC issues a cert for whitehouse[dot]gov and let's further suppose that CNNIC includes this cert in the CT data since they have agreed to do that. What happens next? What I've been wondering about is whether we need a mechanism where the CT log should approve the transition from one issuer to an other. NO. A CT log is a *log*, not a gatekeeper. - Matt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Requirements for CNNIC re-application
On Tue, Apr 14, 2015 at 8:09 AM, Kurt Roeckx k...@roeckx.be wrote: On 2015-04-14 13:54, Rob Stradling wrote: On 14/04/15 12:38, Kurt Roeckx wrote: On 2015-04-14 01:15, Peter Kurrasch wrote: Let's use an example. Suppose CNNIC issues a cert for whitehouse[dot]gov and let's further suppose that CNNIC includes this cert in the CT data since they have agreed to do that. What happens next? What I've been wondering about is whether we need a mechanism where the CT log should approve the transition from one issuer to an other. Kurt, isn't CAA (RFC6844) the tool for this job? I don't see everybody publishing that. Or do you want to make it a requirement that everybody publishes such a record? I think that it is from today that CAs are required to state whether they do CAA or not in their CPS. Anyone who does not implement CAA and then miss-issues just one cert that should have been caught is going to look exceptionally stupid. CAA tells CAs what they should not do CT tells everyone whether or not they did it. Those are the accountability controls. In addition, HSTS and HPKP provide access controls which are currently being distributed through the HTTP and pre-loaded lists and I have a proposal for publishing the exact same info through the DNS as CAA attributes. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Requirements for CNNIC re-application
On 14/04/15 12:38, Kurt Roeckx wrote: On 2015-04-14 01:15, Peter Kurrasch wrote: Let's use an example. Suppose CNNIC issues a cert for whitehouse[dot]gov and let's further suppose that CNNIC includes this cert in the CT data since they have agreed to do that. What happens next? What I've been wondering about is whether we need a mechanism where the CT log should approve the transition from one issuer to an other. Kurt, isn't CAA (RFC6844) the tool for this job? I image something like: Issuer A: issue subject Issuer B: Intend to issue subject Issuer A: Allow migration to Issuer B of subject Issuer B: issue subject If we want go to with something like that, we probably need to think about how this would work with multiple SANs and not migrating all of them and things like that. (This is probably more a discussion for the CT list, feel free to bring it up there.) Kurt -- Rob Stradling Senior Research Development Scientist COMODO - Creating Trust Online ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Requirements for CNNIC re-application
On 2015-04-14 13:54, Rob Stradling wrote: On 14/04/15 12:38, Kurt Roeckx wrote: On 2015-04-14 01:15, Peter Kurrasch wrote: Let's use an example. Suppose CNNIC issues a cert for whitehouse[dot]gov and let's further suppose that CNNIC includes this cert in the CT data since they have agreed to do that. What happens next? What I've been wondering about is whether we need a mechanism where the CT log should approve the transition from one issuer to an other. Kurt, isn't CAA (RFC6844) the tool for this job? I don't see everybody publishing that. Or do you want to make it a requirement that everybody publishes such a record? Kurt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
CAA (was Re: Requirements for CNNIC re-application)
On 14/04/15 13:09, Kurt Roeckx wrote: On 2015-04-14 13:54, Rob Stradling wrote: On 14/04/15 12:38, Kurt Roeckx wrote: On 2015-04-14 01:15, Peter Kurrasch wrote: Let's use an example. Suppose CNNIC issues a cert for whitehouse[dot]gov and let's further suppose that CNNIC includes this cert in the CT data since they have agreed to do that. What happens next? What I've been wondering about is whether we need a mechanism where the CT log should approve the transition from one issuer to an other. Kurt, isn't CAA (RFC6844) the tool for this job? I don't see everybody publishing that. Or do you want to make it a requirement that everybody publishes such a record? I don't think domain owners should be required to publish CAA records. BTW, effective tomorrow, the CABForum BRs require that... A CA’s CPS must state whether it reviews CAA Records, and if so, its policy or practice on processing CAA records for Fully Qualified Domain Names. I'd like to eventually see a requirement that all CAs MUST process CAA records. One step at a time though. Kurt -- Rob Stradling Senior Research Development Scientist COMODO - Creating Trust Online ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Requirements for CNNIC re-application
On Tue, Apr 14, 2015 at 01:38:55PM +0200, Kurt Roeckx wrote: On 2015-04-14 01:15, Peter Kurrasch wrote: Let's use an example. Suppose CNNIC issues a cert for whitehouse[dot]gov and let's further suppose that CNNIC includes this cert in the CT data since they have agreed to do that. What happens next? What I've been wondering about is whether we need a mechanism where the CT log should approve the transition from one issuer to an other. NO. A CT log is a *log*, not a gatekeeper. - Matt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Requirements for CNNIC re-application
On 14/04/15 00:15, Peter Kurrasch wrote: Let's use an example. Suppose CNNIC issues a cert for whitehouse[dot]gov presumably without permission ;-)... and let's further suppose that CNNIC includes this cert in the CT data since they have agreed to do that. What happens next? If no-one is watching, nothing. But it seems to me to be extremely unlikely that no-one will be watching, both from the whitehouse.gov looking for misissuances direction, and from the I want to keep an eye on CNNIC direction. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Requirements for CNNIC re-application
On 14/04/15 01:19, Matt Palmer wrote: I'm not a fan of browser-imposed name constraints on CAs, at a philosophical level. An important principle of the Mozilla root program, IMO, is that it works for the public good (insofar as the public is represented by users of Mozilla products). A name constraint on a CA says we're going to protect *most* of the Internet from a CA's bad behaviour, but the people who visit sites under these prefixes... they're on their own. It depends on why you impose the constraint. You could, for example, think that it's a point of principle that CAs directly controlled by governments can only issue for their own part of the DNS, and not that of other countries. This says nothing about whether or not you think the government CA in question is more or less likely to misissue. (Of course, directly controlled... yes, yes, I know :-|.) Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Requirements for CNNIC re-application
On 11/04/15 01:05, Brian Smith wrote: If a US-based CA were in a similar situation, would we consider name constraining them to *.com, *.org, *.net, *.us? If it were a US government CA, we could certainly constrain to .gov and .mil. No, because that's not much of a constraint. For people within China and others, a name constraint of *.cn isn't much different than that. I think such a constraint gives most of the people on this list a false sense of resolution, because we *.cn websites aren't relevant to the our security, so constraining CNNIC to *.cn is basically equivalent to keeping them out of the program. But, there are many millions of people for whom the security of *.cn websites does matter, and name constraints don't help them. What would, if you postulate a hostile DNS registry and a hostile government? Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Requirements for CNNIC re-application
On Mon, Apr 13, 2015 at 06:15:52PM -0500, Peter Kurrasch wrote: Let's use an example. Suppose CNNIC issues a cert for whitehouse[dot]gov and let's further suppose that CNNIC includes this cert in the CT data since they have agreed to do that. What happens next? Where I'm going with this is that I'm trying to figure out if agreeing to support CT is a hollow promise. It seems like it might deter bad behavior on the part of a cert issuer but it's effectiveness in that regard is limited if nobody is checking the CT logs. (By way of comparison, consider the deterrence impact of using name constraints.) Yes, if nobody is watching the CT logs, there is no *direct* benefit from the single act of publishing all issued certificates. That said, the simple fact that someone *could* be watching what is going on will tend to affect the behaviour of a CA, as it does on any activity involving humans. There is also the benefit that, since the logs are public in perpetuity (or a reasonable approximation thereof), past bad behaviour can be detected by reviewing the historical log data, rather than having to notice it at the time (which is the primary limitation in SSL census data, as useful as that is). Apart from this CT question, it seems to me that requiring name constraints on future submissions from CNNIC is reasonable. I don't see how they have a compelling interest to issue certs beyond Chinese domains in any sense that we would find agreeable. I'm not a fan of browser-imposed name constraints on CAs, at a philosophical level. An important principle of the Mozilla root program, IMO, is that it works for the public good (insofar as the public is represented by users of Mozilla products). A name constraint on a CA says we're going to protect *most* of the Internet from a CA's bad behaviour, but the people who visit sites under these prefixes... they're on their own. To my mind, if a CA isn't trustworthy enough to be trusted to issue certificates for every site on the Internet, they shouldn't be trusted to issue certificates for *any* site on the Internet. In the case of the proposed name constraints for CNNIC, it leaves an especially bad taste in my mouth, as it could easily be interpreted as those Chinese people deserve what they get. - Matt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Requirements for CNNIC re-application
Let's use an example. Suppose CNNIC issues a cert for whitehouse[dot]gov and let's further suppose that CNNIC includes this cert in the CT data since they have agreed to do that. What happens next? Where I'm going with this is that I'm trying to figure out if agreeing to support CT is a hollow promise. It seems like it might deter bad behavior on the part of a cert issuer but it's effectiveness in that regard is limited if nobody is checking the CT logs. (By way of comparison, consider the deterrence impact of using name constraints.) Apart from this CT question, it seems to me that requiring name constraints on future submissions from CNNIC is reasonable. I don't see how they have a compelling interest to issue certs beyond Chinese domains in any sense that we would find agreeable. Original Message From: Gervase Markham Sent: Monday, April 13, 2015 2:15 PM To: Brian Smith; Richard Barnes; mozilla-dev-security-pol...@lists.mozilla.org Cc: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Requirements for CNNIC re-application On 11/04/15 01:05, Brian Smith wrote: If a US-based CA were in a similar situation, would we consider name constraining them to *.com, *.org, *.net, *.us? If it were a US government CA, we could certainly constrain to .gov and ..mil. No, because that's not much of a constraint. For people within China and others, a name constraint of *.cn isn't much different than that. I think such a constraint gives most of the people on this list a false sense of resolution, because we *.cn websites aren't relevant to the our security, so constraining CNNIC to *.cn is basically equivalent to keeping them out of the program. But, there are many millions of people for whom the security of *.cn websites does matter, and name constraints don't help them. What would, if you postulate a hostile DNS registry and a hostile government? Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Requirements for CNNIC re-application
On Mon, Apr 13, 2015 at 8:19 PM, Matt Palmer mpal...@hezmatt.org wrote: To my mind, if a CA isn't trustworthy enough to be trusted to issue certificates for every site on the Internet, they shouldn't be trusted to issue certificates for *any* site on the Internet. In the case of the proposed name constraints for CNNIC, it leaves an especially bad taste in my mouth, as it could easily be interpreted as those Chinese people deserve what they get. While I liked (and still like) Richard Barnes' original name constraint proposal, part of the thing that made it sensical to me is that it's not about *imposing* restrictions outside of a CA's intended model, but about *describing* them. You can argue that a government CA which might want some extra freedom to publish outside of its government-owned TLDs could be respectfully disagreed with, but for a CA like CNNIC that is ostensibly not a government CA and may want the ability to issue to anyone in the world who wishes to pay them -- you're going to make a value judgment on whether they should be able to do that? I agree with Matt that if you just don't trust them, then don't trust them -- why would the Chinese population deserve an untrustworthy CA? -- Eric - Matt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy -- konklone.com | @konklone https://twitter.com/konklone ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Requirements for CNNIC re-application
Richard Barnes rbar...@mozilla.com wrote: My argument is that if we think that CNNIC is likely to cause such mis-issuance to occur because it runs the registry for those TLDs, then there should be additional controls in place so that control over those registries won't result in misissuance. Constraining what a registry can do for names over which it is authoritative is exactly what things like pinning and CT are for. So maybe what you're actually saying is that there should be a requirement for CT as a check on CNNIC's ability to issue even for names for which they are authoritative? Yes. If a US-based CA were in a similar situation, would we consider name constraining them to *.com, *.org, *.net, *.us? No, because that's not much of a constraint. For people within China and others, a name constraint of *.cn isn't much different than that. I think such a constraint gives most of the people on this list a false sense of resolution, because we *.cn websites aren't relevant to the our security, so constraining CNNIC to *.cn is basically equivalent to keeping them out of the program. But, there are many millions of people for whom the security of *.cn websites does matter, and name constraints don't help them. Also, given how things seem to go in China, it seems reasonable to expect some authorities in China to react to removal or limiting CNNIC by blocking Let's Encrypt from operating correctly for *.cn and/or for servers operating in China. Consequently, I'm doubting that building a wall is ultimately what's best in the long term. The advantage of the CT-based approach is that it avoids being such a wall. Cheers, Brian ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Requirements for CNNIC re-application
On Tue, April 7, 2015 5:31 pm, Richard Barnes wrote: E. Require a certain amount of time to pass before CNNIC's re-inclusion request will be considered. I think this remains to be determined in relation to how Mozilla implements their stated policy of a date-based check - e.g. whether this is implemented in Firefox or NSS. Right now, every CA that wishes to apply for inclusion goes in a queue, and there are separate queues for new CAs versus Already included CAs (see https://wiki.mozilla.org/CA:Schedule ). Would CNNIC's presence in the NSS root store give it an advantage over other CAs applying either for inclusion or an updated status? Further, even after CAs are approved for inclusion, they're not directly included in to a Mozilla product until one of the quarterly updates / when there is a sufficient number of new roots. However, if implementing restrictions are done within Firefox, it might give CNNIC an advantage over other participants, in that CNNIC's restrictions can be lifted before other CAs (that were ahead in the queue and approval) are included. Another aspect to consider is Mozilla's inclusion policy with respect to BR audits. That is, https://wiki.mozilla.org/CA:BaselineRequirements#A_CA.27s_First_BR_Audit It would seem like scenario 4 applies 4. Any CA who has received a qualified BR audit opinion (i.e. failing criteria) for its regular period of time audit and then conducts remediation may want a point in time audit to demonstrate their remediation efforts However, given the surrounding context, it would seem that, at the least, a full performance audit showing BR compliance over at least 60 days applies. This means CNNIC will produce new certificates, but they will not be trusted in clients. Alternatively, if CNNIC's disclosure of certificates reveals more BR violations, it might be argued that an untold number of the previously issued certificates may not conform to the BRs, which may require that the CA create a new root, per that same section. It would seem though that there is at least a lower bound of 60 days before the audit begins (for a period of time audit) before CNNIC can be considered for inclusion. If Mozilla opts not to set a minimum time, would it incentivize a quick audit that doesn't address the underlying issues noted by Mozilla? Would Mozilla accept a Point in Time Readiness Assessment for remediation of the issues? Would CNNIC be required, the same as other CAs doign PITRAs, to also perform a PoT assessment within 90 days of inclusion covering at least 60 days of issuance? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
