Re: Public Discussion of GlobalSign's CA Inclusion Request for R46, E46, R45 and E45 Roots

[Ben Wilson via dev-security-policy]

This is a reminder that I will close discussion on this tomorrow.

On Mon, Jan 11, 2021 at 5:59 PM Ben Wilson  wrote:

> This is to announce the beginning of the public discussion phase of the
> Mozilla root CA inclusion process for GlobalSign.
>
> See https://wiki.mozilla.org/CA/Application_Process#Process_Overview,
> (Steps 4 through 9).
>
> GlobalSign has four (4) new roots to include in the root store.  Two
> roots, one RSA and another ECC, are to support server authentication
> (Bugzilla Bug # 1570724
> ) while two other
> roots are for email authentication, RSA and ECC (Bugzilla Bug # 1637269
> ).
>
> Mozilla is considering approving GlobalSign’s request(s). This email
> begins the 3-week comment period, after which, if no concerns are raised,
> we will close the discussion and the request may proceed to the approval
> phase (Step 10).
>
> *A Summary of Information Gathered and Verified appears here in these two
> CCADB cases:*
>
>
> https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=0469
>
>
> https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=0596
>
> *Root Certificate Information:*
>
> *GlobalSign Root R46 *
>
> crt.sh -
> https://crt.sh/?q=4FA3126D8D3A11D1C4855A4F807CBAD6CF919D3A5A88B03BEA2C6372D93C40C9
>
> Download - https://secure.globalsign.com/cacert/rootr46.crt
>
> *GlobalSign Root E46*
>
> crt.sh -
> https://crt.sh/?q=CBB9C44D84B8043E1050EA31A69F514955D7BFD2E2C6B49301019AD61D9F5058
>
> Download - https://secure.globalsign.com/cacert/roote46.crt
>
> *GlobalSign Secure Mail Root R45 *
>
> crt.sh -
> https://crt.sh/?q=319AF0A7729E6F89269C131EA6A3A16FCD86389FDCAB3C47A4A675C161A3F974
>
> Download - https://secure.globalsign.com/cacert/smimerootr45.crt
>
> *GlobalSign Secure Mail Root E45 *
>
> crt.sh -
> https://crt.sh/?q=5CBF6FB81FD417EA4128CD6F8172A3C9402094F74AB2ED3A06B4405D04F30B19
>
> Download - https://secure.globalsign.com/cacert/smimeroote45.crt
>
>
> *CP/CPS:*
>
> https://www.globalsign.com/en/repository/GlobalSign_CPS_v9.6_final.pdf
>
> The current GlobalSign CPS is version 9.6, published 29-December-2020.
>
> Repository location: https://www.globalsign.com/en/repository
>
> *BR Self-Assessment* (Excel) is located here:
>
> https://bugzilla.mozilla.org/attachment.cgi?id=9082310
>
> *Audits:*  GlobalSign is audited annually in accordance with the WebTrust
> criteria by Ernst & Young, Belgium, which found in June 2020 that
> “throughout the period April 1, 2019 to March 31, 2020, GlobalSign
> management’s assertion, as referred to above, is fairly stated, in all
> material respects, in accordance with the WebTrust Principles and Criteria
> for Certification Authorities - SSL Baseline with Network Security, Version
> 2.3.”  The WebTrust audit noted the following 13 Bugzilla incidents,
> which had been previously reported as of that audit date:
>
> 1 Misissuance of QWAC certificates.
>
> 2 Issue with an OCSP responder status.
>
> 3 Some SSL certificates with US country code and invalid State/Prov have
> been issued.
>
> 4 ICAs in CCADB, without EKU extension are listed in WTCA report but not
> in WTBR report.
>
> 5 OCSP responders found to respond signed by the default CA when passed an
> invalid issuer in request.
>
> 6 Wrong business category on 3 EV SSL certificates.
>
> 7 OCSP Responder returned invalid values for some precertificates.
>
> 8 Customer running an on-premise (technically-constrained) CA that chains
> to a GlobalSign root, issued certificates without AIA extension.
>
> 9 Misissued 4 certificates with invalid CN.
>
> 10 Certificates with Subject Public Key Info lacking the explicit NULL
> parameter.
>
> 11 Untimely revocation of TLS certificate after submission of private key
> compromise.
>
> 12 Unable to revoke 2 noncompliant QWACs within 5 days.
>
> 13 Unable to revoke noncompliant ICA within 7 days
>
>
>
> *Incident Reports / Mis-Issuances *
>
> The following bugs/incidents remain open and are being worked on.
>
> 1667944 
>
> Empty SingleExtension in OCSP responses
> 
>
> 1651447 
>
> Failure to revoke noncompliant ICA within 7 days
> 
>
> 1591005 
>
> ICAs in CCADB, without EKU extension are listed in WTCA report but not in
> WTBR report 
>
> 1649937 
>
> Incorrect OCSP Delegated Responder Certificate
> 
>
> 1668007 
>
> Invalid stateOrProvinceName value
> 
>
> 

Re: Summary of Camerfirma's Compliance Issues

[Matthias van de Meent via dev-security-policy]

On Tue, 26 Jan 2021 at 16:28, Ramiro Muñoz via dev-security-policy
 wrote:
>
> El lunes, 25 de enero de 2021 a las 13:31:18 UTC+1, Matthias van de Meent 
> escribió:
> > On Sun, 24 Jan 2021 at 20:58, Ramiro Muñoz via dev-security-policy
> >  wrote:
> > >
> > > Thanks everyone for your valuable contribution to the discussion. We’ve 
> > > prepared a throughful Remediation Plan that addresses all areas of 
> > > improvement emerged both in this public discussion as well as direct 
> > > contacts with some of the members 
> > > https://drive.google.com/file/d/1DV7cUSWqdOEh3WwKsM5k1U5G4rT9IXog/view?usp=sharing.
> > >  The plan is very ambitious but, we’ve our BoD commitment to align 
> > > Camerfirma to the highest level of standards of the Mozzilla community. 
> > > Please feel free send us any request for clarification or any suggestion 
> > > to improve the attached document.
> > In one of your previous replies on this thread you stated the following:
> >
> > > . We are rethinking the SubCA policy since some of the problems come from 
> > > there. Camerfirma has increase the control imposing our 3 external SubCA 
> > > to use the camerfirma central lint control in the pre-isuance process. 
> > > However, next year we plan to convert external SubCA to Wite label CA, 
> > > that's means to run them inside Camerfirma infrastructure.
> >
> > But in this document it looks like this decision has been reverted:
> >
> > > a. Action Point 10.
> > > Insource the management of all the operational activities of the 
> > > intermediate CAs (June
> > 2021).
> > > How:
> > > - Obligation of the SubCA to use the application of controls defined by 
> > > Camerfirma (obligation to send us evidence that they have implemented 
> > > them).
> > > - SubCA obligation to submit to audits set by Camerfirma and with an 
> > > auditor selected by Camerfirma.
> > > - Insource management of all the operational activities of the 
> > > intermediate CAs in a discretionary manner.
> > >
> > > Resources: Internal resources (Legal).
> >
> > Specifically, the need for SubCAs to submit to audits implies that
> > this SubCA (company) is still in control of the ICA's signing.
> > Additionally, the lack of operational resources required for this
> > change further reinforces this implication.
> >
> > As we've seen a lot of problems also stemming from the implementation
> > of external SubCAs, this seems like a serious deterioration in
> > trustability, as that requires Mozilla to trust Camerfirma to hold the
> > SubCA to the requirements of the relevant root stores, while it has
> > repeatedly shown not to do that.
> >
> > Could you explain why you decided to revert that decision?
> >
> > Regards,
> >
> > Matthias van de Meent
>
> Dear Matthias;
>
> We’ve had the chance to discuss the topic with some of our subCAs and arrived 
> to the proposed solution.
> What we’re proposing is not an immediate insourcing of all SubCAs operational 
> activities but, a right to do so if and when we deem it necessary.
> This means the following:
>
> 1.  SubCAs will be obliged to implement the application controls defined 
> by Camerfirma
> 2.  SubCAs will be obliged to submit to audits set by Camerfirma and with 
> an auditor selected by Camerfirma
> 3.  SubCAs will accept contractually that Camerfirma can at any time 
> decide to gain full control of their operational activities
>
> In such a way we’ll be able,  at any timer, to insource the management of 
> operational activities of our ‘problematic’ intermediate CA.
> While virtuous intermediate CA will be allowed to retain the control of their 
> operational activities as long as they remain virtuous.

Could you share what your definition of 'virtuous' means? This, too,
is critical in determining if the trust in your actions (including
your actions to keep trusting these SubCAs with key, operational and
managemental control of parts of your CA infrastructure) is misplaced
or not. And since your SubCAs have a less than virtuous track record,
this wording seems out-of-place.


> In addition, In our remediation plan we are going to incorporate additional 
> resources and controls that will allow us to carry out this monitoring with 
> all guarantees.
> However, we are open to discuss further tuning of our remediation plan to 
> gain the community confident and  assure the security and compliance with the 
> BRs and Mozilla's policies.
> ___
> 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