Re: Audit Reminder Email Summary

[Kathleen Wilson via dev-security-policy]

 Forwarded Message 
Subject: Summary of December 2020 Audit Reminder Emails
Date: Tue, 15 Dec 2020 20:00:28 + (GMT)

Mozilla: Audit Reminder
CA Owner: DigiCert
Root Certificates:
   Symantec Class 2 Public Primary Certification Authority - G6
   Symantec Class 1 Public Primary Certification Authority - G6
   VeriSign Universal Root Certification Authority
   Baltimore CyberTrust Root
   Cybertrust Global Root
   DigiCert Assured ID Root CA
   DigiCert Assured ID Root G2
   GeoTrust Primary Certification Authority - G2
   DigiCert Trusted Root G4
   DigiCert Assured ID Root G3
   VeriSign Class 1 Public Primary Certification Authority - G3
   VeriSign Class 2 Public Primary Certification Authority - G3
Standard Audit: 
https://bug1458024.bmoattachments.org/attachment.cgi?id=9123453

Standard Audit Period End Date: 2019-10-31
Standard Audit: 
https://bug1458024.bmoattachments.org/attachment.cgi?id=9123443

Standard Audit Period End Date: 2019-10-31
Standard Audit: 
https://bug1458024.bmoattachments.org/attachment.cgi?id=9123448

Standard Audit Period End Date: 2019-10-31
BR Audit:
BR Audit Period End Date:
BR Audit: https://bug1458024.bmoattachments.org/attachment.cgi?id=9123452
BR Audit Period End Date: 2019-10-31
BR Audit: https://bug1458024.bmoattachments.org/attachment.cgi?id=9123442
BR Audit Period End Date: 2019-10-31
BR Audit: https://bug1458024.bmoattachments.org/attachment.cgi?id=9123447
BR Audit Period End Date: 2019-10-31
EV Audit:
EV Audit Period End Date:
EV Audit: https://bug1458024.bmoattachments.org/attachment.cgi?id=9123454
EV Audit Period End Date: 2019-10-31
EV Audit: https://bug1458024.bmoattachments.org/attachment.cgi?id=9123445
EV Audit Period End Date: 2019-10-31
CA Comments: null



Mozilla: Audit Reminder
CA Owner: D-TRUST
Root Certificates:
   D-TRUST Root CA 3 2013**
   D-TRUST Root Class 3 CA 2 2009**
   D-TRUST Root Class 3 CA 2 EV 2009**

** Audit Case in the Common CA Database is under review for this root 
certificate.


Standard Audit: 
https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/de/AA2019120301_D-TRUST_Root_CA3_V1.0_s.pdf

Standard Audit Period End Date: 2019-10-07
Standard Audit: 
https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/de/AA2019120302_D-TRUST_Root_Class_3_CA_2_2009_V1.0_s.pdf

Standard Audit Period End Date: 2019-10-07
Standard Audit: 
https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/de/AA2019120303_D-TRUST_Root_Class3_CA2_EV_V1.0_s.pdf

Standard Audit Period End Date: 2019-10-07
BR Audit:
BR Audit Period End Date:
BR Audit: 
https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/de/AA2019120302_D-TRUST_Root_Class_3_CA_2_2009_V1.0_s.pdf

BR Audit Period End Date: 2019-10-07
BR Audit: 
https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/de/AA2019120303_D-TRUST_Root_Class3_CA2_EV_V1.0_s.pdf

BR Audit Period End Date: 2019-10-07
EV Audit: 
https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/de/AA2019120303_D-TRUST_Root_Class3_CA2_EV_V1.0_s.pdf

EV Audit Period End Date: 2019-10-07
CA Comments: null



Mozilla: Audit Reminder
CA Owner: SwissSign AG
Root Certificates:
   SwissSign Gold CA - G2**
   SwissSign Platinum CA - G2**
   SwissSign Silver CA - G2**

** Audit Case in the Common CA Database is under review for this root 
certificate.


Standard Audit: 
https://it-tuv.com/wp-content/uploads/2019/12/AA2019121902_Audit_Attestation_TA_CERT__SwissSign_Gold_G2.pdf

Standard Audit Period End Date: 2019-10-02
Standard Audit: 
https://it-tuv.com/wp-content/uploads/2020/01/AA2019121901_Audit_Attestation_TA_CERT__SwissSign_Platinum_G2.pdf

Standard Audit Period End Date: 2019-09-27
Standard Audit: 
https://it-tuv.com/wp-content/uploads/2020/01/AA2019121903_Audit_Attestation_TA_CERT__SwissSign_Silver_G2.pdf

Standard Audit Period End Date: 2019-09-27
BR Audit: 
https://it-tuv.com/wp-content/uploads/2019/12/AA2019121902_Audit_Attestation_TA_CERT__SwissSign_Gold_G2.pdf

BR Audit Period End Date: 2019-10-02
BR Audit:
BR Audit Period End Date:
BR Audit: 
https://it-tuv.com/wp-content/uploads/2020/01/AA2019121903_Audit_Attestation_TA_CERT__SwissSign_Silver_G2.pdf

BR Audit Period End Date: 2019-09-27
EV Audit: 
https://it-tuv.com/wp-content/uploads/2019/12/AA2019121902_Audit_Attestation_TA_CERT__SwissSign_Gold_G2.pdf

EV Audit Period End Date: 2019-10-02
CA Comments: null



Mozilla: Audit Reminder
CA Owner: Buypass
Root Certificates:
   Buypass Class 2 Root CA
   Buypass Class 3 Root CA
Standard Audit: 
https://www.buypass.com/the-company/certification/_/attachment/download/413dca90-da68-483e-80e4-3978e33a8e98:76247c1b8cacd26f80531a2929c2a739db2b5159/ETS%20018.pdf

Standard Audit Period End Date: 2019-10-31
BR Audit: 
https://www.buypass.com/the-company/certification/_/attachment/download/413dca90-da68-483e-80e4-3978e33a8e98:76247c1b8cacd26f80531a2929c2a739db2b5159/ETS%20018.pdf

BR Audit Period End Date: 2019-10-31
EV Audit: 

Policy 2.7.1: MRSP Issue #207: Require audit statements to provide information about which CA Locations were audited

[Ben Wilson via dev-security-policy]

All,

This email is part of the discussion for the next version of the Mozilla
Root Store Policy (MSRP), version 2.7.1, to be published during of Q1-2021.

For audit delays, we currently require that audit statements disclose the
locations that were and were not audited, but that requirement has not been
incorporated yet into the MRSP. See
https://wiki.mozilla.org/CA/Audit_Statements#Minimum_Expectations. That
provision reads as follows:

Disclose each location (at the state/province level) that was included in
the scope of the audit or should have been included in the scope of the
audit, whether the inspection was physically carried out in person at each
location, and which audit criteria were checked (or not checked) at each
location.

   - If the CA has more than one location in the same state/province, then
   use terminology to clarify the number of facilities in that state/province
   and whether or not all of them were audited. For example: "Facility 1 in
   Province", "Facility 2 in Province, Facility 3 in Province" *or*
   "Primary Facility in Province", "Secondary Facility in Province", "Tertiary
   Facility in Province".
  - The public audit statement does not need to identify the type of
  Facility.
  - "Facility" includes: data center locations, registration authority
  locations, where IT and business process controls of CA operations are
  performed, facility hosting an active HSM with CA private keys,
facility or
  bank deposit box storing a deactivated and encrypted copy of a
private key.

It is proposed by Issue #207
 that this language
requiring the disclosure of site locations--audited and unaudited--be made
clearly part of the MSRP by reference to the language above.

A similar method of incorporating by reference has been taken in section
2.4 of the MSRP

with respect to incident reporting and in section 7.1

with requirements for the CA inclusion process.

It is proposed that we add a new subsection 10 to MRSP section 3.1.4

that would require that audit documentation disclose the facility site
locations that were, or were not, examined.

One concern that has been raised previously is that the Baseline
Requirements do not define "facility site location". However, we believe
that the language above at
https://wiki.mozilla.org/CA/Audit_Statements#Minimum_Expectations
accomplishes that. We're open to suggestions for re-wording parts of it to
make it even better.

Currently, the audit letter template for WebTrust for CAs references the
site location audited (at the level of specificity that is proposed
above).  Over this past year, due to COVID, some ETSI attestation letters
have also explained which sites were and were not checked. This approach
seems to work, and the additional information will be beneficial in the
future as we evaluate the security and trust of PKI service providers.

So, for the page cited above, we intend to move "Minimum Expectations" out
from under "Audit Delay" so that it stands separately as a requirement for
disclosing the facility site location. Then we will also revise MRSP
section 3.1.4 by inserting a new subsection 10 to require "facility site
locations that were, or were not, examined" with a hyperlink to the Minimum
Expectations language cited above.

We look forward to your comments and suggestions.

Sincerely yours,

Ben
___
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

[Ramiro Muñoz via dev-security-policy]

I really sorry for the Delay Burton.

Obviously we do not intend to send inaccurate answers. Maybe I was not using 
the right wording may be I should use “precise” instead ? sorry for my English 
language limitation. Your complain about my email prove that some 
misunderstanding problem could have happen also in our bugs reports. We want to 
be sure that the answers are fully understand to give to the community the 
complete information to evaluate them. As you can imagine in the situation we 
are, it’s critical for us. That’s the reason.

Thanks
Ramiro


De: Burton 
Enviado el: martes, 15 de diciembre de 2020 19:39
Para: Ramiro Muñoz 
CC: r...@sleevi.com; mozilla-dev-security-policy 
; Ben Wilson 

Asunto: Re: Summary of Camerfirma's Compliance Issues

It doesn't look great to the community when a CA that is under investigation 
for serious compliance issues asks for more time to provide detailed answers.

Also you said 'accurate answers' ? Were the answers you were going to post 
today inaccurate in some way?

Burton

On Tue, Dec 15, 2020 at 6:13 PM Ramiro Muñoz via dev-security-policy 
mailto:dev-security-policy@lists.mozilla.org>>
 wrote:
Hi Ryan

Thanks. We will take into account your observations.
As I said we planed to send the formal answer today but the team has asked me 
for more time in order to give a more accurate answer. We plan to postpone to 
this Friday.

KR
Ramiro


De: Ryan Sleevi mailto:r...@sleevi.com>>
Enviado el: lunes, 14 de diciembre de 2020 22:41
Para: Ramiro Muñoz mailto:rami...@camerfirma.com>>
CC: r...@sleevi.com; Ben Wilson 
mailto:bwil...@mozilla.com>>; mozilla-dev-security-policy 
mailto:mozilla-dev-security-pol...@lists.mozilla.org>>
Asunto: Re: Summary of Camerfirma's Compliance Issues

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 

Re: Summary of Camerfirma's Compliance Issues

[Burton via dev-security-policy]

It doesn't look great to the community when a CA that is under
investigation for serious compliance issues asks for more time to provide
detailed answers.

Also you said 'accurate answers' ? Were the answers you were going to post
today inaccurate in some way?

Burton

On Tue, Dec 15, 2020 at 6:13 PM Ramiro Muñoz via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Hi Ryan
>
> Thanks. We will take into account your observations.
> As I said we planed to send the formal answer today but the team has asked
> me for more time in order to give a more accurate answer. We plan to
> postpone to this Friday.
>
> KR
> Ramiro
>
>
> De: Ryan Sleevi 
> Enviado el: lunes, 14 de diciembre de 2020 22:41
> Para: Ramiro Muñoz 
> CC: r...@sleevi.com; Ben Wilson ;
> mozilla-dev-security-policy  >
> Asunto: Re: Summary of Camerfirma's Compliance Issues
>
> 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
>
___
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

[Ramiro Muñoz via dev-security-policy]

Hi Ryan

Thanks. We will take into account your observations.
As I said we planed to send the formal answer today but the team has asked me 
for more time in order to give a more accurate answer. We plan to postpone to 
this Friday.

KR
Ramiro


De: Ryan Sleevi 
Enviado el: lunes, 14 de diciembre de 2020 22:41
Para: Ramiro Muñoz 
CC: r...@sleevi.com; Ben Wilson ; 
mozilla-dev-security-policy 
Asunto: Re: Summary of Camerfirma's Compliance Issues

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