2H2020 Symantec Root Updates

[Kathleen Wilson via dev-security-policy]

All,

Continuing with the distrust of the old Symantec root certificates, 10 
root certificates were removed via bug 1670769 from NSS 3.60 and Firefox 
85.


1. GeoTrust Global CA
2. GeoTrust Primary Certification Authority
3. GeoTrust Primary Certification Authority - G3
4. thawte Primary Root CA
5. thawte Primary Root CA - G3
6. VeriSign Class 3 Public Primary Certification Authority - G4
7. VeriSign Class 3 Public Primary Certification Authority - G5
8. thawte Primary Root CA - G2
9. GeoTrust Universal CA
10. GeoTrust Universal CA 2

I also added this information to
https://wiki.mozilla.org/CA/Additional_Trust_Changes#Symantec

Thanks,
Kathleen
___
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]

Thanks Ramiro for the update.

I do want to make sure we're on the same page. Responding point-by-point to
the issues would probably be the least productive path forward. If there
are specific disagreements with the facts as presented, which were taken
from the Bugzilla reports, it would be good to highlight that. However, I
believe the intent is that the Bugzilla report is the source of truth, so
if there are details that were *not* on the incident reports, I would say
that's more concerning than it is reassuring.

I'm a bit concerned to see your latest reply still highlight the "increased
the PKI team", since that's been a sort of repeated refrain (e.g. Issue T,
Issue BB, Issue PP). I don't disagree that it's important to ensure that
there are adequate resources devoted to compliance _and_ development, but I
think it's also important to make sure that the solution is not to throw
more people at the problem.

While the integrity of the CA is perhaps not as obviously cut and dry, as
was the case with WoSign/StartCom, I do believe it's reasonable to ask
whether or not the CA has the skills, expertise, and understanding of the
systemic issues to effectively manage things going forward, especially when
we have seen the regular repetition of issues. This suggests more systemic
fixes are needed, but also suggests that there are more systemic flaws in
how things are operated, designed, and administered that do call into
question the trustworthiness of the current infrastructure.

If Camerfirma were approaching with a new CA/new certificate hierarchy, it
would be reasonable to ask why, given all of these incidents, Camerfirma
should be included, since it puts a lot of risk onto the community.
Regaining trust and reputation, once lost, is incredibly difficult, and
requires going above and beyond. I hope that, in your formal response, you
provide a holistic picture of how Camerfirma has changed its operations,
implementation, infrastructure, management process, policies, and quite
frankly, the use cases/subscribers that it targets with these certificates,
so that the community can make an informed decision about risk.

Similarly, in thinking about what this would be for a "new" PKI, and how
difficult it would be, given the current evidence, to see that as good for
users, it's also worth asking what should happen with the current PKI.
Should we continue to assume that the implementation of the EV guidelines
is correct, even though we have ample evidence of basic RFC 5280 and BR
violations? Should we consider sunsetting (e.g. with a notBefore
restriction) trust? Would it be reasonable to remove trust altogether?

For example, Camerfirma currently has four roots ([1], [2], [3], [4]). [1]
appears to have issued less than 3,500 still valid certificates, [2] / [3]
are only trusted for e-mail, and [4] seems to be a super-CA of sorts (with
sub-CAs operated by Intesa Sanpaolo, Infocert, Multicert, and Govern
d'Andorra). For the sub-CAs that aren't constrained/revoked, it seems
Intesa Sanpaolo has only issued ~2200 certificates, Infocert ~650, and
Multicert ~3000.

Is that accurate? I totally could have made a mistake here, since this was
just manually inspecting every sub-CA from Camerfirma and I totally could
have clicked wrong, but that suggests that there is... very little
practical risk here to removal, compared to the rather significant risk of
having a CA that has established a pattern of compliance and supervision
issues.

[1] https://crt.sh/?caid=869
[2] https://crt.sh/?caid=140
[3] https://crt.sh/?caid=8453
[4] https://crt.sh/?caid=1114
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: FNMT: Public Discussion of Root Inclusion Request

[Ben Wilson via dev-security-policy]

On November 17, 2020, the public discussion period [Step 4 of the Mozilla
Root Store CA Application Process
] began on FNMT’s
inclusion request.

*Summary of Discussion and Completion of Action Items [Steps 5-8]:*

On November 18, 2020, FNMT clarified that it is audited to both ETSI EN 319
411-2 and ETSI 319 411-1.

Also, on that day, a comment was received with the following observations:

(1) certificate profiles could not be located for review - as indicated
subsequently in the thread, FNMT provided links to the certificate profiles
for end entity certificates;

(2) cross-references to a document called the “DGPC” were difficult to
follow - an overall comment was that FNMT’s Certification Practices
Statement (CPS) was confusing with its numerous cross-references to its
DGPC (CPS for its Root CA). FNMT republished its CPS with these
cross-references removed and replaced them with applicable text.  There
were also references to the "DPPP" (FNMT’s CPS), which were replaced by
“CPS”;

(3) there were numerous observations about the CPS (e.g. it lacked a
commitment to communicate back to third parties within 24 hours of
receiving a Certificate Problem Report, etc.) - see
https://groups.google.com/g/mozilla.dev.security.policy/c/T5bYrPznCXQ/m/Rv4ddGh6BQAJ,
and the subsequent response from FNMT, and my similar summary of these
issues in this thread; and

(4) a final suggestion was “[to] have them compare [the CPS] side-by-side
with the BR, and have it at least document their commitment to each of the
baseline requirements explicitly in their CPS”.  FNMT responded, “We have
updated a new BRs Self-Assessment document with CPS v1.6:
https://bug1559342.bmoattachments.org/attachment.cgi?id=9189942”.  I
believe that the BR self-assessment serves this purpose.

This is notice that I am closing public discussion [Step 9] and that it is
Mozilla’s intent to approve FNMT's request for inclusion [Step 10].

This begins a 7-day “last call” period for any final objections.

Thanks,

Ben

On Wed, Dec 9, 2020 at 12:09 PM Ben Wilson  wrote:

> Just a reminder - today, the public discussion period will close and then
> I'll be preparing a summary of the discussion.  In addition to reviewing
> FNMT's response of 27-November, I also reviewed the CPS v. 1.6 and make the
> following observations:
> Matthias van de Meent wrote:
>
> I'm having trouble finding the end entity certificate profiles in this CPS.
> According to the CPS s7.1.2, they are supposed to be available at
> http://www.cert.fnmt.es/dpcs/, but that redirects me to a repository [0]
> of which the only english-language document [1] does not contain any end
> entity certificate profiles, but only the root and ICA profiles in
> attachments. Similarly, I cannot find the CPS you linked in their
> repository.
>
> I was able to review the end entity certificate profiles at
> https://www.sede.fnmt.gob.es/documents/10445900/10575386/Perfiles_certificados_servidores_seguros_tipo1.pdf
> and
> https://www.sede.fnmt.gob.es/documents/10445900/10575386/Perfiles_certificados_servidores_seguros_tipo2.pdf
>
> I noticed that the CPS defers a great amount of sections (section 5, 6.2,
> 6.4, 8.2 - 8.7 and large parts of section 9) to the DGPC, which probably
> is [1] but that is never explicitly confirmed in the CPS - there is no
> explicit link to any repository in section 1.6.1 where the acronym is
> defined, nor are there any other indications that this DGPC is located in
> the repository under the link of [0]. This is confusing, and detrimental
> to the readability of the document.
>
> I noticed that the acronym "DPPP" has been replaced with "CPS" and that
> language from the "DGPC" has been copied into the CPS.
>
> CPS s4.9.2 and s1.5.2 both mention that third parties may send certificate
> problem reports, and select parties may send revocation requests, which
> is great; but I cannot find a commitment to communicating a preliminary
> report within 24 hours to the reporter as stipulated by BR 4.9.5.
>
> CPS section 4.9.5 now states that "Within 24 hours after receiving a CPR,
> the CA will investigate the facts and circumstances related to the CPR and
> provide a preliminary report to both the Subscriber and the entity who
> filed the CPR."
>
> CPS / DGPC s5.2.2 includes by reference an internal policy, which may or
> may not comply with the "at least dual control for CA private key 
> backup/storage/recovery"
> requirement of BR 5.2.2.
>
> CPS section 5.2.2 now states, "The FNMTs Private Key are backed up,
> stored, and recovered only by personnel in trusted roles using, at least,
> dual control in a physically secured environment."
>
> CPS / DGPC s5.3.1 only guarantee the "experience and knowledge", not the
> "trustworthiness and identity" of the operators.
>
> CPS section 5.3.1 now states, "These requirements are guaranteed by the
> corresponding criteria in the personnel selection processes, verifying the
> identity and trustworthi