Mozilla's Response to Camerfirma's Compliance Issues

[Ben Wilson via dev-security-policy]

Dear All,

We appreciate your comments and participation in the discussion about the
Summary of Camerfirma's Compliance Issues,
https://wiki.mozilla.org/CA:Camerfirma_Issues.

Mozilla has not yet made a decision about Camerfirma's continuation in our
root store. We intend to continue with our public discussion process to
determine whether Camerfirma's root certificates can remain included in
Mozilla's root store, and what actions they need to take.

Camerfirma has responded to the list of issues by providing a Remediation
Plan,
https://drive.google.com/file/d/1DV7cUSWqdOEh3WwKsM5k1U5G4rT9IXog/view?usp=sharing,
with a commitment to align Camerfirma to the highest level of standards of
the Mozilla community.

They asked if there are parts of the Remediation Plan that need
clarification and for suggestions to improve the Remediation Plan.

We will appreciate your constructive feedback on it.

- Do the proposed actions in the Remediation Plan address the underlying
issues?

- If Camerfirma fully executes on this plan, will that be sufficient to
regain trust so that they can remain a CA in Mozilla's root store?

- Do you have additional recommendations for steps that you think
Camerfirma should take?

Thanks,

Ben
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.7.1: MRSP Issue #218: Clarify CRL requirements for End Entity Certificates

[Aaron Gable via dev-security-policy]

I think that an explicit carve-out for time-scoped CRLs is a very good idea.

In the case that this change to the MRSP is adopted, I suspect that LE
would scope CRLs by notAfter quite tightly, with perhaps one CRL per 24 or
even 6 hours of issuance. We would pick a small interval such that we could
guarantee that each CRL would still be a reasonable size even in the face
of a mass revocation event.

Producing CRLs at that rate, it would be very valuable to be able to
gracefully age CRLs out once there is no possibility for a revocation
status update for any certificate in their scope.

Aaron

On Sun, Jan 24, 2021 at 10:22 AM Ben Wilson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> All,
>
> Another suggestion came in for clarification that hasn't been raised on the
> list yet, so I'll try and explain the scenario here.
>
> Normally, a CA must publish and update its CRLs until the end of the CA
> certificate's expiration. However, I think that some CAs partition their
> CRLs based on issuance time, e.g., all certificates issued during January
> 2021. And all of those certificates would expire after the applicable
> validity period.  I think CAs don't continue to regenerate or reissue those
> types of partitioned CRLs which only contain certificates that have
> expired.  So maybe we need to add an express exception that allows CAs to
> omit those obsolete CRLs from the JSON file -- as long as the JSON file
> contains the equivalent of  a "full and complete" CRL.
>
> Thoughts?
>
> Thanks,
> Ben
>
>
> On Wed, Jan 13, 2021 at 8:57 AM Rob Stradling  wrote:
>
> > Hi Ben.
> >
> > > *A CA technically capable of issuing server certificates MUST ensure
> > that
> > > the CCADB field "Full CRL Issued By This CA" contains either the URL
> for
> > > the full and complete CRL or the URL for the JSON file containing all
> > URLs
> > > for CRLs that when combined are the equivalent of the full and complete
> > CRL*
> >
> > As a consumer of this data (crt.sh), I'd much prefer to see "Full CRL
> > Issued By This CA" and "the URL for the JSON file" as 2 separate fields
> in
> > the CCADB.  CAs would then be expected to fill in one field or the other,
> > but not both.  Is that possible?
> >
> > To ensure that these JSON files can be programmatically parsed, I suggest
> > specifying the requirement a bit more strictly.  Something like this:
> >   "...or the URL for a file that contains only a JSON Array, whose
> > elements are URLs of DER encoded CRLs that when combined are the
> equivalent
> > of a full and complete CRL"
> >
> > > I propose that this new CCADB field be populated in all situations
> where
> > the CA is enabled for server certificate issuance.
> >
> > Most Root Certificates are "enabled for server certificate issuance".
> > Obviously CAs shouldn't issue leaf certs directly from roots, but
> > nonetheless the technical capability does exist.  However, currently CAs
> > can't edit Root Certificate records in the CCADB, which makes populating
> > these new field(s) "in all situations" rather hard.
> >
> > Since OneCRL covers revocations of intermediate certs, may I suggest that
> > CAs should only be required to populate these new field(s) in
> intermediate
> > certificate records (and not in root certificate records)?
> >
> > Relatedly, "A CA technically capable of...that the CCADB field" seems
> > wrong.  CCADB "CA Owner" records don't/won't contain the new field(s).
> > Similar language elsewhere in the policy (section 5.3.2) says "All
> > certificates that are capable of being used to..." (rather than "All
> > CAs...").
> >
> > Technically-constrained intermediate certs don't have to be disclosed to
> > CCADB, but "in all situations where the CA is enabled for server
> > certificate issuance" clearly includes technically-constrained
> > intermediates.  How would a CA populate the "Full CRL Issued By This CA"
> > field for a technically-constrained intermediate cert that has
> > (legitimately) not been disclosed to CCADB?
> >
> > --
> > *From:* dev-security-policy <
> dev-security-policy-boun...@lists.mozilla.org>
> > on behalf of Ben Wilson via dev-security-policy <
> > dev-security-policy@lists.mozilla.org>
> > *Sent:* 08 January 2021 01:00
> > *To:* mozilla-dev-security-policy <
> > mozilla-dev-security-pol...@lists.mozilla.org>
> > *Subject:* Policy 2.7.1: MRSP Issue #218: Clarify CRL requirements for
> > End Entity Certificates
> >
> > CAUTION: This email originated from outside of the organization. Do not
> > click links or open attachments unless you recognize the sender and know
> > the content is safe.
> >
> >
> > This is the last issue that I have marked for discussion in relation to
> > version 2.7.1 of the Mozilla Root Store Policy
> > <
> >
> 

Re: Summary of Camerfirma's Compliance Issues

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

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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Summary of Camerfirma's Compliance Issues

[Ryan Sleevi via dev-security-policy]

(Writing in a Google capacity)

I personally want to say thanks to everyone who has contributed to this
discussion, who have reviewed or reported past incidents, and who have
continued to provide valuable feedback on current incidents. When
considering CAs and incidents, we really want to ensure we’re considering
all relevant information, as well as making sure we’ve got a correct
understanding of the details.

After full consideration of the information available, and in order to
protect and safeguard Chrome users, certificates issued by AC Camerfirma SA
will no longer be accepted in Chrome, beginning with Chrome 90.

This will be implemented via our existing mechanisms to respond to CA
incidents, via an integrated blocklist. Beginning with Chrome 90, users
that attempt to navigate to a website that uses a certificate that chains
to one of the roots detailed below will find that it is not considered
secure, with a message indicating that it has been revoked. Users and
enterprise administrators will not be able to bypass or override this
warning.

This change will be integrated into the Chromium open-source project as
part of a default build. Questions about the expected behavior in specific
Chromium-based browsers should be directed to their maintainers.

To ensure sufficient time for testing and for the replacement of affected
certificates by website operators, this change will be incorporated as part
of the regular Chrome release process. Information about timetables and
milestones is available at https://chromiumdash.appspot.com/schedule.

Beginning approximately the week of Thursday, March 11, 2021, website
operators will be able to preview these changes in Chrome 90 Beta. Website
operators will also be able to preview the change sooner, using our Dev and
Canary channels, while the majority of users will not encounter issues
until the release of Chrome 90 to the Stable channel, currently targeting
the week of Tuesday, April 13, 2021.

When responding to CA incidents in the past, there have been a variety of
approaches taken by different browser vendors, determined both by the facts
of the incident and the technical options available to the browsers. Our
particular decision to actively block all certificates, old and new alike,
is based on consideration of the details available, the present technical
implementation, and a desire to have a consistent, predictable,
cross-platform experience for Chrome users and site operators.

For the list of affected root certificates, please see below. Note that we
have included a holistic set of root certificates in order to ensure
consistency across the various platforms Chrome supports, even when they
may not be intended for TLS usage. However, please note that the
restrictions are placed on the associated subjectPublicKeyInfo fields of
these certificates.

Affected Certificates (SHA-256 fingerprint)

   - 04F1BEC36951BC1454A904CE32890C5DA3CDE1356B7900F6E62DFA2041EBAD51
   - 063E4AFAC491DFD332F3089B8542E94617D893D7FE944E10A7937EE29D9693C0
   - 0C258A12A5674AEF25F28BA7DCFAECEEA348E541E6F5CC4EE63B71B361606AC3
   - C1D80CE474A51128B77E794A98AA2D62A0225DA3F419E5C7ED73DFBF660E7109
   - 136335439334A7698016A0D324DE72284E079D7B5220BB8FBD747816EEBEBACA
   - EF3CB417FC8EBF6F97876C9E4ECE39DE1EA5FE649141D1028B7D11C0B2298CED


On Thu, Dec 3, 2020 at 1:01 PM Ben Wilson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

>  All,
>
> We have prepared an issues list as a summary of Camerfirma's compliance
> issues over the past several years. The purpose of the list is to collect
> and document all issues and responses in one place so that an overall
> picture can be seen by the community. The document is on the Mozilla wiki:
> https://wiki.mozilla.org/CA:Camerfirma_Issues.
> 
>
> I will now forward the link above to Camerfirma to provide them with a
> proper opportunity to respond to the issues raised and to ask that they
> respond directly in m.d.s.p. with any comments, corrections, inputs, or
> updates that they may have.
>
> If anyone in this group believes they have an issue appropriate to add to
> the list, please send an email to certifica...@mozilla.org.
>
> Sincerely yours,
> Ben Wilson
> Mozilla Root Program
> ___
> 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