Re: Policy 2.7.1: MRSP Issue #153: Cradle-to-Grave Contiguous Audits

[Bruce via dev-security-policy]

On Saturday, March 6, 2021 at 11:17:53 PM UTC-5, bwi...@mozilla.com wrote:
> Thanks, Bruce, for raising the issue of pre-generated, yet unassigned keys. 
> The intent was to cover this scenario. We are aware that CAs might 
> generate 1000s of keys in a partition and then years later assign a few of 
> them as CA keys, others as OCSP responder keys, etc., and some might never 
> be used. Presumably each of the keys would have an identifier and the CA 
> operator would maintain a list of those key identifiers for each partition. 
> The goal is to have an audited chain of custody for the keys, which could 
> also be based on the physical and logical protection of the HSM that is 
> holding them. 
> Key lifecycle documentation would consist of a documented key generation 
> ceremony (where such documentation is reviewed by an auditor). Then, 
> annually an auditor would review storage and access records for the HSM(s) 
> and the list of keys to see which ones had been used for CAs and which ones 
> had not. Then, as keys were destroyed (or if not, when the HSM is zeroized 
> at the end of the HSM's lifecycle), there would be an attestation of key 
> destruction that would be covered by an audit/auditor's statement.
> On Fri, Mar 5, 2021 at 9:46 AM Bruce via dev-security-policy < 
> dev-secur...@lists.mozilla.org> wrote: 
> 

One more question for clarification as I want to make sure we understand how to 
get our practices updated to meet the Mozilla Policy. The requirement states 
"until the CA certificate is no longer trusted by Mozilla's root store." Can we 
confirm that a CA certificate is no longer trusted by the Mozilla root store if 
1) it has expired or 2) it has been revoked and the OneCRL has been updated. Of 
course Mozilla may have other ways to no longer trust a CA certificate.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Public Discussion re: Inclusion of the ANF Secure Server Root CA

[Andrey West Siberia via dev-security-policy]

Hello,
I can't find the test URIs for this root certificate...
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

AW: Re: Policy 2.7.1: MRSP Issue #192: Require information about auditor qualifications in the audit report

[Wanko Clemens via dev-security-policy]

Dear Ben, Dear Kahtleen,

 

we suppose, there are no other changes intendent then apart from what you say 
below? 

If the rest of section 3.2 remains as it is, the specific matter of the ETSI 
auditor qualification would be addressed through the referrer back to BRG 
section 8.2. It would then read like this, which is okay for us: 

 

"3.2 Auditors

In normal circumstances, Mozilla requires that audits MUST be performed by a 
Qualified Auditor, as defined in the Baseline Requirements section 8.2.

A Qualified Auditor MUST have relevant IT Security experience, or have audited 
a number of CAs, and be independent. Each Audit Report MUST be accompanied by 
documentation provided to Mozilla of the audit team qualifications sufficient 
for Mozilla to determine the competence, experience, and independence of the 
auditor."

 

Otherwise a link to the Wiki would be necessary for clear definition of the 
details for the auditor qualification. 

 

Apart from that: is it also intended to change section 3.1.4?

 

All the best 

Clemens

 

-Ursprüngliche Nachricht-
Von: mozilla.dev.security.pol...@googlegroups.com 
 Im Auftrag von Ben Wilson
Gesendet: Dienstag, 9. März 2021 00:31
An: mozilla-dev-security-policy 
Betreff: EXT: Re: Policy 2.7.1: MRSP Issue #192: Require information about 
auditor qualifications in the audit report

 

All,

Kathleen and I discussed the language of this proposal and have modified it for 
MRSP section 3.2 as follows:  "A Qualified Auditor MUST have relevant IT 
Security experience, or have audited a number of CAs, and be independent.

Each Audit Report MUST be accompanied by documentation provided to Mozilla of 
the audit team qualifications sufficient for Mozilla to determine the 
competence, experience, and independence of the auditor."

Ben

 

 

On Thu, Feb 18, 2021 at 11:27 AM Ben Wilson <  
bwil...@mozilla.com> wrote:

 

> All,

> 

> I have edited the proposed resolution of Issue #192 

>  5fa760555c1eabb81bd7914ee>

> as follows:

> 

> Subsection 3 of MRSP Section 3.1.4. would read:

> 

> "The publicly-available documentation relating to each audit MUST 

> contain at least the following clearly-labelled information: ...

> 

> 3. name of the lead auditor and qualifications of the team performing 

> the audit, as required by section 3.2; ..."

> 

> Section 3.2 would read:

> 

> "A Qualified Auditor MUST have relevant IT Security experience, or 

> have audited a number of CAs, and be independent and not conflicted. 

> People have competence, partnerships and corporations do not. Each 

> Audit Report MUST be accompanied by documentation provided to Mozilla 

> of the audit team qualifications 

> <  
> https://wiki.mozilla.org/CA/Audit_Statements#Auditor_Qualifications>

> sufficient for Mozilla to determine the competence, experience, and 

> independence of the Qualified Auditor."

> 

> The wiki page linked above will provide further details on how to 

> submit documentation of the audit team's qualifications (which may be 

> separate from the audit letter itself).

> 

> Ben

> 

> 

>  5fa760555c1eabb81bd7914ee>

> 

> 

> 

> On Mon, Feb 15, 2021 at 6:01 PM Watson Ladd via dev-security-policy < 

>   
> dev-security-policy@lists.mozilla.org> wrote:

> 

>> On Monday, February 15, 2021 at 3:07:12 PM UTC-8, Jeff Ward wrote:

>> > On Monday, February 15, 2021 at 4:11:15 PM UTC-6, Ryan Sleevi wrote:

>> > > Apologies for belaboring the point, but I think we might be 

>> > > talking

>> past

>> > > eachother.

>> > >

>> > > You originally stated “The only place I am aware that lists the 

>> > > audit partner in a comparable world is the signing audit partner 

>> > > on public company audits in the US, which is available on the SEC 

>> > > website.” I

>> gave

>> > > two separate examples of such, and you responded to one (FPKI) by

>> saying

>> > > the report was not public (even when it is made available 

>> > > publicly),

>> and

>> > > the other I didn’t see a response to.

>> > >

>> > > This might feel like nit-picking, but I think this is a rather

>> serious

>> > > point to work through, because I don’t think you’re fully

>> communicating

>> > > what you judge to be a “comparable world”, as it appears you are

>> dismissing

>> > > these examples.

>> > >

>> > > I can think of several possible dimensions you might be thinking 

>> > > are relevant, but rather than assume, I’m hoping you can expand 

>> > > with a

>> few

>> > > simple questions. Some admittedly seem basic, but I don’t want to

>> take

>> > > anything for granted here.

>> > >

>> > > 1) Are you/the WTTF familiar with these audit schemes?

>> > >

>> > > 2) Are you aware of schemes 

Re: Public Discussion re: Inclusion of the ANF Secure Server Root CA

[Ben Wilson via dev-security-policy]

Here you go:

https://testvalidsslev.anf.es
https://testrevokedsslev.anf.es
https://testexpiredsslev.anf.es

On Thu, Mar 11, 2021 at 6:38 AM Andrey West Siberia via dev-security-policy
 wrote:

> Hello,
> I can't find the test URIs for this root certificate...
> ___
> 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: Policy 2.7.1: MRSP Issue #153: Cradle-to-Grave Contiguous Audits

[Ben Wilson via dev-security-policy]

Hi Bruce,
I think the answer is yes. A CA certificate is no longer trusted once it
has expired or been revoked (or added to OneCRL for subCAs) or removed
(roots). But I'm double-checking on the case of certificates with validity
periods that extend past the expiration of the root.
Ben

On Thu, Mar 11, 2021 at 7:28 AM Bruce via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Saturday, March 6, 2021 at 11:17:53 PM UTC-5, bwi...@mozilla.com wrote:
> > Thanks, Bruce, for raising the issue of pre-generated, yet unassigned
> keys.
> > The intent was to cover this scenario. We are aware that CAs might
> > generate 1000s of keys in a partition and then years later assign a few
> of
> > them as CA keys, others as OCSP responder keys, etc., and some might
> never
> > be used. Presumably each of the keys would have an identifier and the CA
> > operator would maintain a list of those key identifiers for each
> partition.
> > The goal is to have an audited chain of custody for the keys, which
> could
> > also be based on the physical and logical protection of the HSM that is
> > holding them.
> > Key lifecycle documentation would consist of a documented key generation
> > ceremony (where such documentation is reviewed by an auditor). Then,
> > annually an auditor would review storage and access records for the
> HSM(s)
> > and the list of keys to see which ones had been used for CAs and which
> ones
> > had not. Then, as keys were destroyed (or if not, when the HSM is
> zeroized
> > at the end of the HSM's lifecycle), there would be an attestation of key
> > destruction that would be covered by an audit/auditor's statement.
> > On Fri, Mar 5, 2021 at 9:46 AM Bruce via dev-security-policy <
> > dev-secur...@lists.mozilla.org> wrote:
> >
>
> One more question for clarification as I want to make sure we understand
> how to get our practices updated to meet the Mozilla Policy. The
> requirement states "until the CA certificate is no longer trusted by
> Mozilla's root store." Can we confirm that a CA certificate is no longer
> trusted by the Mozilla root store if 1) it has expired or 2) it has been
> revoked and the OneCRL has been updated. Of course Mozilla may have other
> ways to no longer trust a CA certificate.
> ___
> 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: Policy 2.7.1: MRSP Issue #153: Cradle-to-Grave Contiguous Audits

[Ben Wilson via dev-security-policy]

Bruce,
The answer would be yes because we check the validity of the root CA
certificate and other CA certificates.
Ben



On Thu, Mar 11, 2021 at 10:33 AM Ben Wilson  wrote:

> Hi Bruce,
> I think the answer is yes. A CA certificate is no longer trusted once it
> has expired or been revoked (or added to OneCRL for subCAs) or removed
> (roots). But I'm double-checking on the case of certificates with validity
> periods that extend past the expiration of the root.
> Ben
>
> On Thu, Mar 11, 2021 at 7:28 AM Bruce via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> On Saturday, March 6, 2021 at 11:17:53 PM UTC-5, bwi...@mozilla.com
>> wrote:
>> > Thanks, Bruce, for raising the issue of pre-generated, yet unassigned
>> keys.
>> > The intent was to cover this scenario. We are aware that CAs might
>> > generate 1000s of keys in a partition and then years later assign a few
>> of
>> > them as CA keys, others as OCSP responder keys, etc., and some might
>> never
>> > be used. Presumably each of the keys would have an identifier and the
>> CA
>> > operator would maintain a list of those key identifiers for each
>> partition.
>> > The goal is to have an audited chain of custody for the keys, which
>> could
>> > also be based on the physical and logical protection of the HSM that is
>> > holding them.
>> > Key lifecycle documentation would consist of a documented key
>> generation
>> > ceremony (where such documentation is reviewed by an auditor). Then,
>> > annually an auditor would review storage and access records for the
>> HSM(s)
>> > and the list of keys to see which ones had been used for CAs and which
>> ones
>> > had not. Then, as keys were destroyed (or if not, when the HSM is
>> zeroized
>> > at the end of the HSM's lifecycle), there would be an attestation of
>> key
>> > destruction that would be covered by an audit/auditor's statement.
>> > On Fri, Mar 5, 2021 at 9:46 AM Bruce via dev-security-policy <
>> > dev-secur...@lists.mozilla.org> wrote:
>> >
>>
>> One more question for clarification as I want to make sure we understand
>> how to get our practices updated to meet the Mozilla Policy. The
>> requirement states "until the CA certificate is no longer trusted by
>> Mozilla's root store." Can we confirm that a CA certificate is no longer
>> trusted by the Mozilla root store if 1) it has expired or 2) it has been
>> revoked and the OneCRL has been updated. Of course Mozilla may have other
>> ways to no longer trust a CA certificate.
>> ___
>> 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: Public Discussion re: Inclusion of the ANF Secure Server Root CA

[Andrew Ayer via dev-security-policy]

On Wed, 10 Mar 2021 13:43:55 -0700
Ben Wilson via dev-security-policy
 wrote:

> This is to announce the beginning of the public discussion phase of
> the Mozilla root CA inclusion process for the ANF Secure Server Root
> CA.

I'd like to draw attention to the first misissuance mentioned
in  and
.
Although this misissuance occurred under ANF's old hierarchy, that
hierarchy is/was trusted by Apple and Microsoft, and ANF was requesting
its inclusion in Mozilla, so the incident is relevant to understanding
how ANF operates a publicly-trusted certificate authority.

In 2019, ANF issued a server certificate

with a DNS name of cdcdcd.  Obviously, they could not have possibly
validated domain control of this hostname, which is a serious failure
considering that domain validation is the most important task a
CA performs.  However, their incident report doesn't mention domain
validation at all.  They blamed the incident on human error by "junior
engineers" and their resolution was to implement a blocklist of words
that indicate a test certificate ("Test", "Testing", "Prueba"), provide
more training for junior engineers, and update their "Disciplinary
Measures and Sanctions document, in order to have this resources
available in case of infringement".  None of these resolutions address
the root failure to perform domain validation.  Had this incident
report been written several years earlier, it may have been excusable,
but by 2019 it was very clear to anyone following mdsp and CA incidents
that "human error" is not acceptable analysis and training is not an
adequate resolution.

Additionally, their incident report shows some pretty concerning
misunderstandings of PKI and the BRs:

1. A belief that the CABF's Test Certificate extension OID is meant for
testing their CA rather than a (now forbidden) domain validation method.

2. A belief that the CABF's Test Certificate extension OID is to be put
in the certificate policy extension rather than used as the ID for a
poison extension.

3. A conflation of the subject serial number and the certificate serial
number, stating that the subject serial number must contain 64 bits of
entropy.

Finally, note that the new hierarchy has issued zero end-entity
certificates known to CT, so the fact that the new hierarchy hasn't
misissued any certificates doesn't speak to the competence of ANF.
On the other hand, the history of misissuance in the old hierarchy,
ANF's misunderstandings of PKI, and the incredibly poor incident report
speak very poorly to ANF's competence and trustworthiness.  There is
no indication that they've corrected the root cause of their failure to
perform domain validation, and no reason to believe that their
compliance problems won't reoccur under their new hierarchy.

When Mozilla trusts a CA, Mozilla is giving an assurance to its users
that they won't be harmed by the CA.  A CA which has lax technical
controls, a poor understanding of PKI, and an inability to learn from
and improve when mistakes are made is at heightened risk of
exploitation by malicious actors that would harm Mozilla users.  I do
not believe Mozilla can give assurance to their users that ANF is safe.
Therefore, this application should be rejected.

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

Re: Clarification request: ECC subCAs under RSA Root

[pfuen...--- via dev-security-policy]

OK. Thanks for your answers.

In summary, my understanding is that we can ignore that illustrative control of 
the Webtrust Criteria and that the community is cool with these subordinations 
of CAs with stronger keys (same or different algorithm).

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