Re: Guang Dong Certificate Authority (GDCA) root inclusion request
I think these are both good points and my recommendation is that Mozilla deny GDCA's request for inclusion.We should not have to explain something as basic as document versioning and version control. If GDCA can not demonstrate sufficient controls over their documentation, there is no reason for the Internet community to place confidence in any of the other versioning systems that are needed to operate a CA.Question: Are auditors expected to review translations of CP or CPS docs and verify consistency between them?From: Jakob BohmSent: Saturday, October 22, 2016 9:07 AMTo: mozilla-dev-security-pol...@lists.mozilla.orgSubject: Re: Guang Dong Certificate Authority (GDCA) root inclusion requestOn 21/10/2016 10:38, Han Yuwei wrote:>> I think this is a major mistake and a investgation should be conducted for CPS is a critical document about CA. This is not just a translation problem but a version control problem. Sometimes it can be lying.>Let me try to be more specific:When publishing a document called CPS version 4.3 the document withthat number must have the same contents in all languages that have adocument with that name and version number.When making any change, even just correcting a mistyped URL, thedocument becomes a new document version which should have a new andlarger number than the number of the document before the change.Thus when a published document refers to a broken URL on your ownserver, it is often cheaper to repair the server than to publish a newdocument version. Some of the oldest CAs have been proudlypublishing their various important files at multiple URLs correspondingto whatever was mentioned in old CP and CPS documents etc., onlyshutting down those URLs years after the corresponding CA roots wereshut down.There can also be a "draft" document which has no number and whichcontains the changes that will go into the next numbered edition. Sucha "draft" would have no official significance, as it has not beenofficially "published". For a well-planned change, the final "draft"would be translated and checked into the relevant languages (e.g.Chinese with mainland writing system, Chinese with Hong Kong and MacaoSpecial Administrative Regions old writing system, English), beforesimultaneously publishing the matching documents with the same numberon the same day.There are infinitely many version numbers in the universe to choosefrom. There are also computer programs that can generate new versionnumbers every time a draft is changed, but computers cannot decide whena version is good enough in all languages to make an officialpublication, and the computer generated version numbers are oftenimpractical for publication because they count all the small steps thatwere not published.EnjoyJakob-- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.comTransformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10This public discussion message is non-binding and may contain errors.WiseMo - Remote Service Management for PCs, Phones and Embedded___dev-security-policy mailing listdev-security-policy@lists.mozilla.orghttps://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: Draft Email - Non-Disclosed SubCAs
To be clear, this particular email will just be going to the CAs listed here: https://crt.sh/mozilla-disclosures#undisclosedsummary The intention of the email is to remind those CAs that they have an overdue action item, that needs to be completed. It is not the intention of this email to clarify policy around intermediate certificate disclosure. > what to do about intermediate CAs which were created since the last audit. > We should work out what to do about that, at least in the short term, I agree that I should add a section about that to https://wiki.mozilla.org/CA:SalesforceCommunity I don't agree that it needs to be resolved before reminding these particular CAs about their overdue action items. If they fall into that category, then they can respond to my email stating that. > Disclosed, but audit and CP/CPS data incomplete To be handled differently... I plan to add automation to Salesforce that will send email to CAs with intermediate cert data that has incomplete or outdated audit/CP/CPS information in Salesforce. (similar to the automated audit reminder emails that get sent to CAs regarding their included root certs.) > uploading intermediates > to the Common CA Database is an ongoing responsibility, not just a > one-off task. This should be kind of obvious, but at least one person at > the CAB Forum suggested it needed making more clear. Please see https://wiki.mozilla.org/CA:SalesforceCommunity#CA_Community_in_Salesforce and let me know if you still think we need to add a sentence to the wiki page stating that CAs are expected to maintain this data on an ongoing basis. > For CA certificates signed or cross signed after the June deadline, > there is an ongoing requirement to enter them within ? calendar days > (?? hours) after signing them, preferably earlier. > > For all the CA certificates entered in SalesForce, there is an ongoing > requirement to keep the information up to date, e.g. when there are > updates to audit reports, policy documents, ownership etc. Generally > within ?? calendar days (??? hours) after these changes occur. In > particular, changes of ownership should be reported as soon as they are > operational facts, even if the legal process of ownership change has > not yet completed. Perhaps I need to add a section called "CA Responsibilities" to https://wiki.mozilla.org/CA:SalesforceCommunity Here's the current draft of the email that I plan to send to the CAs listed in https://crt.sh/mozilla-disclosures#undisclosedsummary ~~ Subject: ACTION REQUIRED: Non-Disclosed non-technically-constrained Intermediate Certs Dear Certification Authority, You are receiving this email because our records indicate that there are non-technically-constrained intermediate certificates that chain up to your root certificates that are included in Mozilla’s program that have not been entered into the CA Community in Salesforce. The deadline for CAs to disclose their intermediate certificate data in the CA Community in Salesforce was June 2016. Mozilla is going to begin discussions in the mozilla.dev.security.policy forum about action to take for any remaining non-disclosed non-technically-constrained intermediate certificates and the CAs who are responsible for those CA hierarchies. The following was stated in Mozilla’s March 2016 CA Communication (https://wiki.mozilla.org/CA:Communications#March_2016): Beginning with Version 2.1 of Mozilla's CA Certificate Policy, for any certificate which directly or transitively chains to the root certificates you currently have included in Mozilla's CA Certificate Program, which are capable of being used to issue new certificates, and which are not technically constrained as described in Section 9 of Mozilla's CA Certificate Inclusion Policy, you are required to provide public-facing documentation about the certificate verification requirements and annual public attestation of conformance to said requirements. This includes certificates owned by, operated by, or issued by third parties, whether or not those issuing certificates are already part of Mozilla's CA Certificate Program, if they have been cross-signed by a certificate that directly or transitively chains to your root certificate. To facilitate this public disclosure, Mozilla is requiring that these certificates, as well as their CP/CPS and audit statements, be entered into Mozilla's CA Community in Salesforce. This includes the full PEM data of every intermediate certificate that directly or transitively chains to your included root certificates, provided that the root certificate is enabled with the Websites trust bit and the intermediate certificate is not Technically Constrained, as described in Section 9 of Mozilla's CA Certificate Inclusion Policy. This also includes every variation of these certificates, in the event they were reissued, such as to change the contents of extensions or validity dates. Please see
Re: Distrusting New WoSign and StartCom Certificates -- Mozilla Security Blog
Kathleen, This coverage is very encouraging! Among the sites you included, huanqiu, which is a newspaper operated by the central government is notable. So far, no censorship has been observed, contrary to the blanket censorship of the previous CNNIC case. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Distrusting New WoSign and StartCom Certificates -- Mozilla Security Blog
Kathleen, This coverage is very encouraging! Among the sites you included, huanqiu, which is a newspaper operated by the central government is notable. So far, no censorship has been observed, contrary to the blanket censorship of the previous CNNIC case. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Technically Constrained Sub-CAs and the BRs
One thing I forgot to mention: Although I think Viriginia's view of the process is fine, passing the ballot now puts the requirement into a weird status where it may be adopted or not adopted, depending on the CA's interpretation on when changes are adopted. This then becomes an exercise in whether the auditor believes the process is allowed instead of something that is prohibited. The status of the ballot as binding may be unclear from the Forum's perspective but that at least shifts it over to the CA to explain to auditors. The process definitely needs clarification, but I can see the point in Wayne wanting to pass the ballot before the governance/IPR issues are resolved (that plus we never voted to suspend ballots so I think we permit members to continue following the process until there is clarity - we're no worse off than we were before) -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla .org] On Behalf Of Ryan Sleevi Sent: Wednesday, October 26, 2016 11:53 AM To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Technically Constrained Sub-CAs and the BRs On Wednesday, October 26, 2016 at 3:52:23 AM UTC-7, Gervase Markham wrote: > Perhaps it would be worth revisiting the reasons why technically > constrained sub-CAs were excluded from Mozilla policy. As I remember, > this was a privacy requirement - CAs wanted to be able to have some > sub-CAs which were not publicly disclosed, as Mozilla policy was set > to require. The compromise reached was that public disclosure was not > necessary if the sub-CA were name-constrained. Am I correct in this, > or were there other reasons? Are there parts of Mozilla's policy > and/or the BRs that it would be reasonable for such sub-CAs to be exempt from? My understanding was actually that it was two-fold: 1) A small subset of CAs felt that TCSCs should be private. 2) Generally, it was felt that because the most 'harm' you can do with a TCSC is to your own domains, the need for a third-party audit, or for some of the more substantial requirements (e.g. standing up an OCSP and CRL responder, HSM protection, etc) were unnecessary, and more an element of local security policy. I'm actually entirely unsympathetic to the argument in 1, and even RFC 6962 (early drafts) and RFC 6962-bis (current draft) seemed to support this, without objection from CAs, by requiring that a TCSC be disclosed via CT, but that it's leaves would be exempt. Independent of Chrome's view of that (wearing that hat for only this sentence), by allowing leaves under a TCSC to be unlogged seems to support the interpretation of #2. This is also why I support the mandatory disclosure of TCSCs to Mozilla Salesforce, to ensure that the Technical Constraints are properly implemented and conforming in order for the CA to claim its exclusion. The challenge with the interpretation in #2 is that, while the damage may be localized to a specific domain, we know that it can present ecosystem issues, particularly around deprecation. If we fully accept that TCSCs can do no harm to the Web PKI, then arguably, requirements such as using 2048-bit RSA keys are unnecessary in the BRs, because they're also "localized" harm (if for a non-CA cert). Since we have precedent of using the BRs to set ecosystem-wide minimum security requirements (to receive secure UI), such as using unambiguous subjectAltNames, presenting the right EKU, and using reasonably sufficient cryptographic key sizes (RSA-2048, ECC-256), I think the interpretation that nothing below a TCSC can do any harm is a bad interpretation. So then the question becomes - what ARE the things that TCSCs should be exempt from, and to what degree? As it stands in the BRs, they are exempt from only one thing: An independent, third-party audit. All other requirements are in full force, regarding the certificate profile, key protection, and key revocation services. Under Mozilla policy, as interpreted at present, they are exempt from all requirements. This is the core inconsistency - because the Issuing CA has a BR obligation to ensure the TCSC is compliant. While I'm supportive, in general, of you're suggested modification, I do want to highlight the implications that it brings. It means that TCSCs must ensure FIPS 140-2 Level 3 HSMs and key protection, audit logs, etc. In effect, the only benefit a TCSC provides is that it allows you to avoid an independent auditor, but doesn't allow you to avoid any of the substantial obligations in capital to conform to the BRs and the netsec requirements. Alternatively, we could try to suggest that a TCSCs' certificates must conform to the certificate profile, but not other obligations (like separation of duty, offline protection, etc), but then we still have to figure out which elements of that technical profile are relevant - for example, OCSP and CRL services for the TCSC. Or we could go with the current perceived
Re: Technically Constrained Sub-CAs and the BRs
On Wednesday, October 26, 2016 at 3:52:23 AM UTC-7, Gervase Markham wrote: > Perhaps it would be worth revisiting the reasons why technically > constrained sub-CAs were excluded from Mozilla policy. As I remember, > this was a privacy requirement - CAs wanted to be able to have some > sub-CAs which were not publicly disclosed, as Mozilla policy was set to > require. The compromise reached was that public disclosure was not > necessary if the sub-CA were name-constrained. Am I correct in this, or > were there other reasons? Are there parts of Mozilla's policy and/or the > BRs that it would be reasonable for such sub-CAs to be exempt from? My understanding was actually that it was two-fold: 1) A small subset of CAs felt that TCSCs should be private. 2) Generally, it was felt that because the most 'harm' you can do with a TCSC is to your own domains, the need for a third-party audit, or for some of the more substantial requirements (e.g. standing up an OCSP and CRL responder, HSM protection, etc) were unnecessary, and more an element of local security policy. I'm actually entirely unsympathetic to the argument in 1, and even RFC 6962 (early drafts) and RFC 6962-bis (current draft) seemed to support this, without objection from CAs, by requiring that a TCSC be disclosed via CT, but that it's leaves would be exempt. Independent of Chrome's view of that (wearing that hat for only this sentence), by allowing leaves under a TCSC to be unlogged seems to support the interpretation of #2. This is also why I support the mandatory disclosure of TCSCs to Mozilla Salesforce, to ensure that the Technical Constraints are properly implemented and conforming in order for the CA to claim its exclusion. The challenge with the interpretation in #2 is that, while the damage may be localized to a specific domain, we know that it can present ecosystem issues, particularly around deprecation. If we fully accept that TCSCs can do no harm to the Web PKI, then arguably, requirements such as using 2048-bit RSA keys are unnecessary in the BRs, because they're also "localized" harm (if for a non-CA cert). Since we have precedent of using the BRs to set ecosystem-wide minimum security requirements (to receive secure UI), such as using unambiguous subjectAltNames, presenting the right EKU, and using reasonably sufficient cryptographic key sizes (RSA-2048, ECC-256), I think the interpretation that nothing below a TCSC can do any harm is a bad interpretation. So then the question becomes - what ARE the things that TCSCs should be exempt from, and to what degree? As it stands in the BRs, they are exempt from only one thing: An independent, third-party audit. All other requirements are in full force, regarding the certificate profile, key protection, and key revocation services. Under Mozilla policy, as interpreted at present, they are exempt from all requirements. This is the core inconsistency - because the Issuing CA has a BR obligation to ensure the TCSC is compliant. While I'm supportive, in general, of you're suggested modification, I do want to highlight the implications that it brings. It means that TCSCs must ensure FIPS 140-2 Level 3 HSMs and key protection, audit logs, etc. In effect, the only benefit a TCSC provides is that it allows you to avoid an independent auditor, but doesn't allow you to avoid any of the substantial obligations in capital to conform to the BRs and the netsec requirements. Alternatively, we could try to suggest that a TCSCs' certificates must conform to the certificate profile, but not other obligations (like separation of duty, offline protection, etc), but then we still have to figure out which elements of that technical profile are relevant - for example, OCSP and CRL services for the TCSC. Or we could go with the current perceived interpretation - out of sight, out of mind - in which case, that means that any BR-violating sub-CA may be reissued as a TCSC, provided that its only for domains it controls. That, of course, leaves the situation I described as a possibility - largescale, automated TCSC issuance as a way to avoid BR-based deprecations - but we can cross that bridge when it comes up. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Distrusting New WoSign and StartCom Certificates -- Mozilla Security Blog
More links in simplified Chinese: Weibo: http://weibo.com/1663337394/EeutZ447K?type=comment#_rnd1477447436655 Toutiao: http://www.toutiao.com/i6345313124182131201/ Below is some coverage from China, all coverage contained message pull-through from Mozilla's blog post and mentioned WoSign's response: https://linux.cn/article-7898-1.html https://www.sslchina.com/news20161025-mozilla-distrusted-new-wosign-and-startcom-certificates/ http://www.pcpop.com/doc/3/3522/3522780.shtml http://www.solidot.org/story?sid=50116 http://www.cnbeta.com/articles/551603.htm http://digi.163.com/16/1025/13/C47QM5EU001687H3.html http://mobile.163.com/16/1025/13/C47QJPD300118023.html http://tech.huanqiu.com/diginews/2016-10/9598056.html http://www.d1net.com/security/vendor/438705.html http://www.chinaz.com/free/2016/1025/600531.shtml ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Technically Constrained Sub-CAs and the BRs
Reading this makes me wonder. Will it still be possible to have such a thing as a non disclosed sub-CA now that Chrome has announced that they soon will require CT? CU Hans ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Technically Constrained Sub-CAs and the BRs
On Tue, Oct 25, 2016 at 12:12:47PM -0700, Ryan Sleevi wrote: > 8. All certificates that are capable of being used to issue new certificates, > and which directly or transitively chain to a certificate included in > Mozilla’s CA Certificate Program, MUST be operated in accordance with > Mozilla’s CA Certificate Policy and MUST either be technically constrained or > be publicly disclosed and audited. > > This wording implies that technically constrained sub-CAs, from a Mozilla > Policy standpoint, are not required to adhere to the Baseline Requirements. So I think what you're trying to say is that you interprete it as: "MUST either be (technically constrained) or (be publicly disclosed and audited)" While maybe it was meant to say: "MUST either be (technically constrained or be publicly disclosed) and audited" Where audited can either be done by an external auditor, or by the CA that issued the TCSC. But you could also interprete is like we only require an audit report from those that are not technically constrained. To avoid confusing, you could make it a list like: - technically constrained or be publicly disclosed - audited It's also not clear from that sentence that they need to adhere to the BRs, but I guess that comes from the audit requirements. Kurt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Technically Constrained Sub-CAs and the BRs
On 26/10/16 02:30, Ryan Sleevi wrote: > So we certainly know that Mozilla's policies are, in some ways, > designed to minimize the number of errors that users are presented > with, by allowing a gradual fade out of insecure or undesirable > practices. A change in the BRs is, in theory, supposed to be fully > reflected in all valid certificates within 39 months of the effective > date, after which time, application software vendors can remove > support. I certainly agree that this is the goal. And, insofar as the BRs are only meaningful to CAs because root program policy requires it, we need to make sure that Mozilla's application of the BRs is correctly scoped. Perhaps it would be worth revisiting the reasons why technically constrained sub-CAs were excluded from Mozilla policy. As I remember, this was a privacy requirement - CAs wanted to be able to have some sub-CAs which were not publicly disclosed, as Mozilla policy was set to require. The compromise reached was that public disclosure was not necessary if the sub-CA were name-constrained. Am I correct in this, or were there other reasons? Are there parts of Mozilla's policy and/or the BRs that it would be reasonable for such sub-CAs to be exempt from? If privacy was the extent of the issue, would it solve the problem to change bullet 8 of the inclusion policy as follows? 8. All certificates that are capable of being used to issue new certificates, and which directly or transitively chain to a certificate included in Mozilla’s CA Certificate Program, MUST be operated in accordance with Mozilla’s CA Certificate Policy and MUST either be technically constrained or be publicly disclosed and audited. -> 8. All certificates that are capable of being used to issue new certificates, and which directly or transitively chain to a certificate included in Mozilla’s CA Certificate Program, MUST be operated in accordance with Mozilla’s CA Certificate Policy (including being included in audits) and MUST either be technically constrained or be publicly disclosed. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Distrusting New WoSign and StartCom Certificates -- Mozilla Security Blog
On Tuesday, 25 October 2016 4:30:39 PM UTC Percy wrote: > StartCom on the other hand, issued no announcement > (https://startssl.com/News) even under multiple explicit inquires from > multiple users > (https://forum.startcomca.com/viewforum.php?f=16=549011a08d3a081898f1e1 > 542d3ecc10). There is an announcement when you log in which I've attached: "Mozilla decided to distrust all StartCom root certificates as of 21st of October, this situation will have an impact in the upcoming release of Firefox in January. StartCom will provide an interim solution soon and will replace all the issued certificates from that date in case of requested. Meanwhile StartCom is updating all their systems and will generate new root CAs as requested by Mozilla." -N ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Technically Constrained Sub-CAs and the BRs
On Wednesday, 26 October 2016 02:31:07 UTC+1, Ryan Sleevi wrote: > Yes. There is no obligation or expectation, presently communicated, to revoke > extant certificates. Indeed, CAs were adamantly opposed to such a > requirement. So these certificates will still very much be valid. Ah yes, I had muddled this with the obligation to revoke remaining certificates for non-Internet addresses (e.g. example.corp, 10.20.30.40) at the start of this month for which it's on my TODO list to verify the extent of compliance. So this would be a significant risk. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
