Re: TunRootCA2 root inclusion request
On Friday, March 9, 2018 at 10:30:18 PM UTC+1, Ryan Sleevi wrote: > On Tue, Feb 27, 2018 at 4:17 PM, Wayne Thayer via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > This request has been in public discussion for more than 6 months, so I > > would like to make a decision soon. If you have comments or concerns with > > this request, please post them here by 6-March 2018. > > > Wayne, > > Thanks for encouraging this discussion and making sure it reaches a timely > conclusion. > > To assist in the review, I've tried to summarize the issues to date: > Incident 1: > - 2016-01-04: As part of the initial Information Gathering, Kathleen Wilson > noted incomplete reply to the list of Mozilla Problematic Practices > regarding DNS names appearing within the subjectAltName. In response, on > 2016-01-20, TunRootCA 2 replies - > https://bugzilla.mozilla.org/show_bug.cgi?id=1233645#c5 - stating that they > only use the subjectAlternativeName. > - 2017-02-28: TunRootCA2 violates this requirement - > https://crt.sh/?id=99182607 > - 2017-03-03: TunRootCA2 revokes this certificate - > https://groups.google.com/d/msg/mozilla.dev.security.policy/wCZsVq7AtUY/4erfw5lwCQAJ > - 2017-07-19: Charles Reiss raises this issue - > https://groups.google.com/d/msg/mozilla.dev.security.policy/wCZsVq7AtUY/rHhr0-NjBgAJ > > Incident 2: > - 2016-01-04: TunRootCA2 states their validation practices > - 2016-03-11: TunRootCA2 violates those - https://crt.sh/?id=15126121 > - 2016-03-21: TunRootCA2 revokes that certificate - > https://groups.google.com/d/msg/mozilla.dev.security.policy/wCZsVq7AtUY/4erfw5lwCQAJ > - 2017-07-19: Charles Reiss raises this issue - > https://groups.google.com/d/msg/mozilla.dev.security.policy/wCZsVq7AtUY/rHhr0-NjBgAJ > > Incident 3: > - 2012-07-01: Baseline Requirements effective date, with restrictions on > reserved IPs and internal server names. > - 2015-10-23: TunRootCA2 issues a certificate with a reserved IP address > with a validity period later than 2015-11-1. > - 2016-12-14: TunRootCA2 replaces the certificate > - 2017-07-19: Charles Reiss raises this issue - > https://groups.google.com/d/msg/mozilla.dev.security.policy/wCZsVq7AtUY/rHhr0-NjBgAJ > > Incident 4: > - 2012-07-01: Baseline Requirements effective date, with restrictions on > reserved IPs and internal server names. > - 2017-01-09: TunRootCA2 issues a certificate for an internal server name > - 2017-07-19: Charles Reiss raises this issue - > https://groups.google.com/d/msg/mozilla.dev.security.policy/wCZsVq7AtUY/rHhr0-NjBgAJ > - 2017-07-28: TunRootCA2 revokes this certificate > > During the discussion of these incidents, TunRootCA2 disclosed that RAs > handled domain name validation, and they used another CA's tools to check > the validity of CSRs. RAs were then empowered to issue the domain > information directly to cause issuance. This suggests a strong lack of > technical controls and understanding by RAs. In response, TunRootCA2 > indicated they were deploying a new PKI platform. > We do use another CA's tool to check the validity of CSR. As we do use the cr.sh tool developed also by another CA to check pre-certificate before issuance. So why is using a tool for checking CSR is problematic whereas using the crt.sh is approved ? The point here is to use an efficient tool to perform certificate checks regardless of the CA that owns it. Besides, given that the Tunisian government does not have a Mozilla trusted CA, we are forced to buy SSL certificates for Tunisian e-commerce websites from the CA who owns the CSR check tool that we use. In order to have a consistent RA process, we use the CSR check tool to by from that trusted CA and also to check our own certificates > On 2018-02-27, TunRootCA2 claims they no longer use DTPs for domain > validation, as per > https://groups.google.com/d/msg/mozilla.dev.security.policy/wCZsVq7AtUY/PCZek1DyAgAJ > > > Incident 5: > - 2017-10-23: TunRootCA2 misissues again - > https://crt.sh/?id=242366304=cablint > - 2018-02-22: Wayne Thayer raises this issue - > https://groups.google.com/d/msg/mozilla.dev.security.policy/wCZsVq7AtUY/gxLNUDyaBgAJ > - 2018-02-27: TunRootCA2 revokes the certificate - > https://groups.google.com/d/msg/mozilla.dev.security.policy/wCZsVq7AtUY/PCZek1DyAgAJ > > Incident 6: > - 2018-02-22: Wayne Thayer completes initial review - > https://groups.google.com/d/msg/mozilla.dev.security.policy/wCZsVq7AtUY/gxLNUDyaBgAJ > - 2018-02-23: TunRootCA2 misissues again - > https://crt.sh/?id=346579818=cablint > - 2018-02-28: TunRootCA2 revokes the certificate > > > Like Jonathan, I am concerned about the technical controls instituted. From > this thread, it does not give the impression of a technically competent > organization. While the requirements for more detailed. While a number of > these incidents predate the normalized Mozilla Incident Report template ( > https://groups.google.com/d/msg/mozilla.dev.security.policy/Y392OBvDvr8/Pf4VCG_-BQAJ > ), it
Re: TunRootCA2 root inclusion request
In addition to the issues Ryan has listed, during the root inclusion process multiple issues with their OCSP responder and CRL endpoints were observed and fixed only after the flaws were documented in the bug ( https://bugzilla.mozilla.org/show_bug.cgi?id=1233645). I believe any CA seeking inclusion should be capable of doing the sorts of checks the Mozilla community performs long prior to seeking root inclusion. Failures like this inspire no confidence in the technical acumen of the administrators and I do not believe this root inclusion request should be accepted. -Paul ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: TunRootCA2 root inclusion request
On Tue, Feb 27, 2018 at 4:17 PM, Wayne Thayer via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > This request has been in public discussion for more than 6 months, so I > would like to make a decision soon. If you have comments or concerns with > this request, please post them here by 6-March 2018. Wayne, Thanks for encouraging this discussion and making sure it reaches a timely conclusion. To assist in the review, I've tried to summarize the issues to date: Incident 1: - 2016-01-04: As part of the initial Information Gathering, Kathleen Wilson noted incomplete reply to the list of Mozilla Problematic Practices regarding DNS names appearing within the subjectAltName. In response, on 2016-01-20, TunRootCA 2 replies - https://bugzilla.mozilla.org/show_bug.cgi?id=1233645#c5 - stating that they only use the subjectAlternativeName. - 2017-02-28: TunRootCA2 violates this requirement - https://crt.sh/?id=99182607 - 2017-03-03: TunRootCA2 revokes this certificate - https://groups.google.com/d/msg/mozilla.dev.security.policy/wCZsVq7AtUY/4erfw5lwCQAJ - 2017-07-19: Charles Reiss raises this issue - https://groups.google.com/d/msg/mozilla.dev.security.policy/wCZsVq7AtUY/rHhr0-NjBgAJ Incident 2: - 2016-01-04: TunRootCA2 states their validation practices - 2016-03-11: TunRootCA2 violates those - https://crt.sh/?id=15126121 - 2016-03-21: TunRootCA2 revokes that certificate - https://groups.google.com/d/msg/mozilla.dev.security.policy/wCZsVq7AtUY/4erfw5lwCQAJ - 2017-07-19: Charles Reiss raises this issue - https://groups.google.com/d/msg/mozilla.dev.security.policy/wCZsVq7AtUY/rHhr0-NjBgAJ Incident 3: - 2012-07-01: Baseline Requirements effective date, with restrictions on reserved IPs and internal server names. - 2015-10-23: TunRootCA2 issues a certificate with a reserved IP address with a validity period later than 2015-11-1. - 2016-12-14: TunRootCA2 replaces the certificate - 2017-07-19: Charles Reiss raises this issue - https://groups.google.com/d/msg/mozilla.dev.security.policy/wCZsVq7AtUY/rHhr0-NjBgAJ Incident 4: - 2012-07-01: Baseline Requirements effective date, with restrictions on reserved IPs and internal server names. - 2017-01-09: TunRootCA2 issues a certificate for an internal server name - 2017-07-19: Charles Reiss raises this issue - https://groups.google.com/d/msg/mozilla.dev.security.policy/wCZsVq7AtUY/rHhr0-NjBgAJ - 2017-07-28: TunRootCA2 revokes this certificate During the discussion of these incidents, TunRootCA2 disclosed that RAs handled domain name validation, and they used another CA's tools to check the validity of CSRs. RAs were then empowered to issue the domain information directly to cause issuance. This suggests a strong lack of technical controls and understanding by RAs. In response, TunRootCA2 indicated they were deploying a new PKI platform. On 2018-02-27, TunRootCA2 claims they no longer use DTPs for domain validation, as per https://groups.google.com/d/msg/mozilla.dev.security.policy/wCZsVq7AtUY/PCZek1DyAgAJ Incident 5: - 2017-10-23: TunRootCA2 misissues again - https://crt.sh/?id=242366304=cablint - 2018-02-22: Wayne Thayer raises this issue - https://groups.google.com/d/msg/mozilla.dev.security.policy/wCZsVq7AtUY/gxLNUDyaBgAJ - 2018-02-27: TunRootCA2 revokes the certificate - https://groups.google.com/d/msg/mozilla.dev.security.policy/wCZsVq7AtUY/PCZek1DyAgAJ Incident 6: - 2018-02-22: Wayne Thayer completes initial review - https://groups.google.com/d/msg/mozilla.dev.security.policy/wCZsVq7AtUY/gxLNUDyaBgAJ - 2018-02-23: TunRootCA2 misissues again - https://crt.sh/?id=346579818=cablint - 2018-02-28: TunRootCA2 revokes the certificate Like Jonathan, I am concerned about the technical controls instituted. From this thread, it does not give the impression of a technically competent organization. While the requirements for more detailed. While a number of these incidents predate the normalized Mozilla Incident Report template ( https://groups.google.com/d/msg/mozilla.dev.security.policy/Y392OBvDvr8/Pf4VCG_-BQAJ ), it was designed precisely to address these issues, and the more recent replies do not provide particular reassurance that these incidents have been fully understood. The failures Wayne raised, particularly around documentation, are troubling. Equally troubling is that in the course of audits, these issues were not disclosed - or, if they were, the revocation of the certificate in response to these incidents was not disclosed to the broader community. Yet, at the same time, there are still-trusted CAs that have demonstrated similar issues - although perhaps not to the same degree of becoming a problematic pattern or an insufficient response - and they still remain trusted. A recommendation to instill trust in such a new CA, one that has demonstrated problematic patterns already, suggests that CAs may continue to display such patterns without risk of distrust - which would overall be harmful. Yet, if the recommendation is not to trust,
Re: AC Camerfirma Chambers of Commerce and Global Chambersign 2016 Root Inclusion Request
On Tue, Mar 6, 2018 at 4:45 AM, ramirommunoz--- via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > 1 * The inclusion request references a much older CPS [3] that doesn't > list the 2016 versions of these roots or comply with current policies. I > only reviewed the newer CPS [5], but this CPS (section 1.2.1) doesn't cover > the older roots that are currently included. I believe this is a compliance > issue with the currently included AC Camerfirma roots. > > RMM -> EIDAS regulation has been an important milestone that took us to > consider to setup a new hierarchy (2016) and writing a new CPS apart from > the other hierarchies and CPS, even more when our final target is to > distribute certificates only from the 2016 hierarchy. > This request to incorporate the new 2016 roots affects only to eIDAS CPS > (1.2.1). However, the CPS –no eIDAS (3.2.7) are still valid for the > hierarchies (2003 and 2008). > > Roots from the older hierarchies are currently included in the Mozilla CA program, but the CPS that applies to these roots does not comply with Mozilla policy (it hasn't been revised since 2015) - is that correct? If so, how and when do you intend to correct the problem? - Wayne ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: AC Camerfirma Chambers of Commerce and Global Chambersign 2016 Root Inclusion Request
On Tuesday, March 6, 2018 at 3:45:47 AM UTC-8, ramiro...@gmail.com wrote: > Hi Wyne > here our answers to the ==Bad== issues we are working on the ==Meh== ones. > > 1 * The inclusion request references a much older CPS [3] that doesn't list > the 2016 versions of these roots or comply with current policies. I only > reviewed the newer CPS [5], but this CPS (section 1.2.1) doesn't cover the > older roots that are currently included. I believe this is a compliance issue > with the currently included AC Camerfirma roots. > > RMM -> EIDAS regulation has been an important milestone that took us to > consider to setup a new hierarchy (2016) and writing a new CPS apart from the > other hierarchies and CPS, even more when our final target is to distribute > certificates only from the 2016 hierarchy. > This request to incorporate the new 2016 roots affects only to eIDAS CPS > (1.2.1). However, the CPS –no eIDAS (3.2.7) are still valid for the > hierarchies (2003 and 2008). > > 2 * I am unable to locate a BR audit for the GCSR2016, but the websites trust > bit has been requested. I first thought that this root was not intended for > serverAuth, but section 1.2.1.4 of the CPS indicates that there is an “AC > CAMERFIRMA GLOBAL FOR WEBSITES” subordinate CA that chains to this root. Both > roots are covered by the latest EV audit. > > RMM -> AC CAMERFIRMA GLOBAL FOR WEBSITES was audited for BR in the same way > that was audited for EV. The absence of AC CAMERFIRMA GLOBAL FOR WEBSITES > from the scope section of the attestation letter have been produced by a > mistake, since this CA is detailed in Pag.32 of the same document. EV > attestation letter follow the same model than BR. An auditor's note can be > requested, if it is need it. > > 3 * Last year, Camerfirma signed a contract with StartCom as a delegated RA. > While I don’t believe the StartCom distrust plan [2] specifically forbade > this, it was found that Camerfirma was not performing domain validation on > the OV certificates [4] as required by the BRs. > > RMM -> Relationship with STARCOM as a delegated RA has been finalized since > STARCOM stopped issuing certificates. > STARCOM RA operator’s certificates are revoked from January 2018. > Last certificate issued by STARCOM as a delegated RA was on December 2017. > > 4 * The BR section 2.2 requirement that “The CA SHALL publicly give effect to > these Requirements and represent that it will adhere to the latest published > version” is not clearly stated in the CPS. Also, the final paragraph of > section 1.2 implies that the CPS takes precedence over BR requirements. > > RMM -> This issue is already clarified in our CPS last version that will be > publish next March. > > 5 * CPS section 3.1.8.2.2 displays a misunderstanding of BR section 3.2.2.8 > when it states that ‘This last procedure will not be necessary if the > certificate issuance uses “Certificate Transparency” as indicated in the > CABFORUM BRs. CA-Browser Forum BR 1.4.4.’ The BRs only exempt CAA checking > prior to issuing the actual certificate because checking is required prior to > issuing the corresponding pre-certificate. > > RMM -> This issue is already clarified in our CPS last version that will be > publish next March. I was due to a misunderstanding of the BR. The procedure > was corrected in November 2017. > > 6 * Camerfirma’s CAA domains are not documented in the CPS as required by BR > section 2.2. > > RMM -> This issue is already included in our CPS last version that will be > publish next March. AC Camerfirma use "camerfirma.com" as a CAA issuer record. > > 7 * Camerfirma’s BR Self Assessment states that they use BR methods 2 and 4 > for domain validation, but the methods are not clearly documented in the CPS > as required by Mozilla policy section 2.2(3). > > RMM -> This issue is already documented in our CPS last version that will be > publish next March. In short, we use an email with a random value to domain > contact that have to be sending back to the CA to prove domain control. BR > 1.5.4 (3.2.2.4.2). > > 8 * There are a few published, misissued, and currently unrevoked > certificates in the CCR2016 hierarchy: > https://crt.sh/?caid=50473=cablint,zlint,x509lint=2011-01-01 > > RMM -> Those few (four) misissued certificates are revoked from the very > moment we were aware of that. We are opening a bug to explain this issue. > > Keep on working on ==Meh== ones > Best regards > Ramiro Several times you mention in your response: > This issue is already clarified in our CPS last version that will be publish > next March. Why wait an entire year to publish a new version of the CPS? The Certificate Practices Statement should be an accurate description of the certificate authority's current or near future operational practices, so you should be publishing new versions as necessary to reflect changes in operations.
Re: ccadb.org
The ccadb.org site is now https. Please let me know if you run into any problems with the ccadb.org site. Thanks for your patience. Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Process of including ca root in mozilla
Every year the ca root will gave the official annual audit to mozilla who prove the respect of norms. this audits made from a recognized auditors ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Process of including ca root in mozilla
Every year the ca root will gave the official annual audit to mozilla who prove the respect of norms. this audits made from a recognized auditors ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Process of including ca root in mozilla
the risk still exists. for example a root ca included in mozilla and generates nonconforming certificates. what to do??? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Process of including ca root in mozilla
Is a good idea to limited the ca root at first at code country or the TLD of this country like .tr for turkey or .fr for France In second step this ca root put the new request for they other domain or code and this request take a profond and enforced check like 2 years of period. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
