Re: Synopsis of Proposed Changes to MRSP v. 2.7.1

[Ben Wilson via dev-security-policy]

Thanks, Ryan
I'll work on incorporating your suggestions into the draft we're working on.
Ben

On Wed, Mar 10, 2021 at 9:10 AM Ryan Sleevi  wrote:

>
>
> On Mon, Mar 8, 2021 at 7:08 PM Ben Wilson via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> #139 resolved - Audits are required even if no longer issuing, until CA
>> certificate is revoked, expired, or removed.
>>
>> See
>>
>> https://github.com/BenWilson-Mozilla/pkipolicy/commit/888dc139d196b02707d228583ac20564ddb27b35
>>
>
> I'm assuming you're OK with this, but just wanting to make sure it's
> explicit:
>
> In the scenario where the CA destroys the private key, they may still have
> outstanding certificates that work in Mozilla products. If Mozilla is
> relying on infrastructure provided by that CA (e.g. OCSP, CRL), the CA no
> longer has an obligation to audit that infrastructure.
>
> I suspect that the idea is that if/when a CA destroys the private key,
> that the expectation is Mozilla will promptly remove/revoke the root, but
> just wanted to call out that there is a gap between the operational life
> cycle of a CA (e.g. providing revocation services) and the private key
> lifecycle.
>
> If this isn't intended, then removing the "or until all copies" should
> resolve this, but of course, open up new discussion.
>
>
>> #221 resolved - Wrong hyperlink for “material change” in MRSP section 8
>>
>> Replace hyperlink with “there is a change in the CA's operations that
>> could
>> significantly affect a CA's ability to comply with the requirements of
>> this
>> Policy.”
>>
>>
>> https://github.com/BenWilson-Mozilla/pkipolicy/commit/fbe04aa64f931940af967ed90ab98aa95789f057
>
>
> Since "significantly" is highly subjective, and can lead the CA to not
> disclosing, what would be the impact of just dropping the word? That is,
> "that could affect a CA's ability to comply". There's still an element of
> subjectivity here, for sure, but it encourages CAs to over-disclose, rather
> than under-disclose, as the current language does.
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Ben Wilson via dev-security-policy]

All,

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.  See
https://wiki.mozilla.org/CA/Application_Process#Process_Overview, (Steps 4
through 9).

The ANF Secure Server Root CA is operated by ANF AC, a Qualified Trust
Services Provider in the European Union and in operation since the late
1990s.

A previous application for other root CAs was filed in 2010.  See
https://bugzilla.mozilla.org/show_bug.cgi?id=555156.  During that process
it was decided that a new root should be submitted.

This current CA inclusion application has been tracked in the CCADB and in
Bugzilla–

https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=0501

https://bugzilla.mozilla.org/show_bug.cgi?id=1585951

This new root CA certificate was signed in 2019, and it is proposed for
inclusion with the websites bit and EV enabled.

Mozilla is considering approving ANF’s request. 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).

*Root Certificate Information:*

ANF Secure Server Root CA

crt.sh -
https://crt.sh/?q=FB8FEC759169B9106B1E511644C618C51304373F6C0643088D8BEFFD1B997599

Download -
http://www.anf.es/es/certificates-download/ANFSecureServerRootCA.cer



*CP/CPS:*

Current CP is Version 3.3.1 / January 8, 2021

https://anf.es/pdf/CP_SSL_Electronic_Headquarters_v3_3_1.pdf

Current CPS is Version 31 /  February 1, 2021

https://anf.es/pdf/Certification_Practices_Statement_v31.pdf

Repository location:

https://www.anf.es/en/repositorio-legal/



*ANF's 2021 BR Self-Assessment* (PDF) is located here:

https://bug1585951.bmoattachments.org/attachment.cgi?id=9208014

*Audits:*

The 2020 ETSI EN 319 411 audit is available here:
https://www.csqa.it/getattachment/Sicurezza-ICT/Documenti/Attestazione-di-Audit-secondo-i-requisiti-ETSI/CSQA-Attestation-ANF-2020_12423_V4_Signed.pdf.aspx?lang=it-IT.


The audit observed that Bug 555156
 included "Misissuance
of SSL OV Test Certificate".

*Incidents: *

The incident reports provided by ANF indicate the misissuance of
certificates under the previous CA hierarchy. See
https://bug555156.bmoattachments.org/attachment.cgi?id=9100493 and
https://bugzilla.mozilla.org/attachment.cgi?id=9098945. However, no
misissuances have been found under the ANF Secure Server Root CA, and the
issuing CA certificates passed technical tests.

Thus, this email begins a three-week public discussion period, which I’m
scheduling to close on or about 31-March-2021.

We encourage you to participate in the review and discussion.

A representative of ANF must promptly respond directly in the discussion
thread to all questions that are posted.

Sincerely yours,

Ben Wilson

Mozilla Root Store Program
___
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

[Tim Hollebeek via dev-security-policy]

I know where this kind of requirement is coming from ... it's a common
requirement in key management systems, but they generally operate in worlds
that are completely different from the Web PKI.  Even there, it often causes
more problems than it solves.  I've spent more of my life dealing with the
fallout from rules like this than I care to admit.

It makes more sense when you have a complex asymmetric or symmetric system
with different strength keys protecting the distribution of symmetric keys
with different strengths, and you want to make sure the keys being
distributed actually have the intended strength, instead of being somewhat
weaker due to potential attacks on weak links in the distribution system.
One of the ways of simplifying that complexity is to enforce various
uniformity requirements on the chains.  This helps prevent accidentally
using an encryption key that was distributed with a weaker key, and thinking
that it has full strength.

It's important to remember that TLS keys are real-time online authentication
keys, generally with relatively short lifetimes (relative to many typical
KMSs!), and the goal is to meet the minimum authentication strength goal at
the time the connection is being built.  Whether one or more keys is a bit
stronger than necessary doesn't hurt anything in the same way that it can
for encryption keys.  And as the two previous people have noted, mixed
chains can be extremely useful in various interoperability and
transition/upgrade scenarios.  So rules like these can actually reduce
cryptoagility by unnecessarily eliminating perfectly viable options, and
reducing cryptoagility is the exact opposite of what we should be trying to
accomplish.

-Tim

> -Original Message-
> From: dev-security-policy 
On
> Behalf Of Ryan Sleevi via dev-security-policy
> Sent: Wednesday, March 10, 2021 11:00 AM
> To: pfuen...@gmail.com 
> Cc: Mozilla 
> Subject: Re: Clarification request: ECC subCAs under RSA Root
> 
> I agree with Corey that this is problematic, and wouldn't even call it a
best
> practice/good practice.
> 
> I appreciate the goal in the abstract - which is to say, don't do more
work than
> necessary (e.g. having an RSA-4096 signed by RSA-2048 is wasting cycles
*if*
> there's no other reason for it), but as Corey points out, there are times
where
> it's both necessary and good to have such chains.
> 
> On Wed, Mar 10, 2021 at 9:46 AM pfuen...--- via dev-security-policy < dev-
> security-pol...@lists.mozilla.org> wrote:
> 
> > > My understanding is that neither the BRs or any Root Program require
> > that that subordinate CA key be weaker or equal in strength to the
> > issuing CA's key.
> > >
> > > Additionally, such a requirement would prohibit cross-signs where a
> > "legacy" root with a smaller key size would certify a new root CA with
> > a stronger key. For that reason, this illustrative control seems
problematic.
> > >
> >
> > Thanks, Corey.
> > I also see it problematic, but I've been seeing other root programs
(i.e.
> > Spanish Government) enforcing this rule, so I'd like to understand if
> > it's a "best practice" or a rule, and, in particular, if it's rule to
> > be respected for TLS-oriented hierarchies.
> > P
> > ___
> > 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



smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Synopsis of Proposed Changes to MRSP v. 2.7.1

[Ryan Sleevi via dev-security-policy]

On Mon, Mar 8, 2021 at 7:08 PM Ben Wilson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> #139 resolved - Audits are required even if no longer issuing, until CA
> certificate is revoked, expired, or removed.
>
> See
>
> https://github.com/BenWilson-Mozilla/pkipolicy/commit/888dc139d196b02707d228583ac20564ddb27b35
>

I'm assuming you're OK with this, but just wanting to make sure it's
explicit:

In the scenario where the CA destroys the private key, they may still have
outstanding certificates that work in Mozilla products. If Mozilla is
relying on infrastructure provided by that CA (e.g. OCSP, CRL), the CA no
longer has an obligation to audit that infrastructure.

I suspect that the idea is that if/when a CA destroys the private key, that
the expectation is Mozilla will promptly remove/revoke the root, but just
wanted to call out that there is a gap between the operational life cycle
of a CA (e.g. providing revocation services) and the private key lifecycle.

If this isn't intended, then removing the "or until all copies" should
resolve this, but of course, open up new discussion.


> #221 resolved - Wrong hyperlink for “material change” in MRSP section 8
>
> Replace hyperlink with “there is a change in the CA's operations that could
> significantly affect a CA's ability to comply with the requirements of this
> Policy.”
>
>
> https://github.com/BenWilson-Mozilla/pkipolicy/commit/fbe04aa64f931940af967ed90ab98aa95789f057


Since "significantly" is highly subjective, and can lead the CA to not
disclosing, what would be the impact of just dropping the word? That is,
"that could affect a CA's ability to comply". There's still an element of
subjectivity here, for sure, but it encourages CAs to over-disclose, rather
than under-disclose, as the current language does.
___
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

[Ryan Sleevi via dev-security-policy]

I agree with Corey that this is problematic, and wouldn't even call it a
best practice/good practice.

I appreciate the goal in the abstract - which is to say, don't do more work
than necessary (e.g. having an RSA-4096 signed by RSA-2048 is wasting
cycles *if* there's no other reason for it), but as Corey points out, there
are times where it's both necessary and good to have such chains.

On Wed, Mar 10, 2021 at 9:46 AM pfuen...--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> > My understanding is that neither the BRs or any Root Program require
> that that subordinate CA key be weaker or equal in strength to the issuing
> CA's key.
> >
> > Additionally, such a requirement would prohibit cross-signs where a
> "legacy" root with a smaller key size would certify a new root CA with a
> stronger key. For that reason, this illustrative control seems problematic.
> >
>
> Thanks, Corey.
> I also see it problematic, but I've been seeing other root programs (i.e.
> Spanish Government) enforcing this rule, so I'd like to understand if it's
> a "best practice" or a rule, and, in particular, if it's rule to be
> respected for TLS-oriented hierarchies.
> P
> ___
> 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: Clarification request: ECC subCAs under RSA Root

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

> My understanding is that neither the BRs or any Root Program require that 
> that subordinate CA key be weaker or equal in strength to the issuing CA's 
> key. 
> 
> Additionally, such a requirement would prohibit cross-signs where a "legacy" 
> root with a smaller key size would certify a new root CA with a stronger key. 
> For that reason, this illustrative control seems problematic. 
> 

Thanks, Corey. 
I also see it problematic, but I've been seeing other root programs (i.e. 
Spanish Government) enforcing this rule, so I'd like to understand if it's a 
"best practice" or a rule, and, in particular, if it's rule to be respected for 
TLS-oriented hierarchies.
P
___
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

[Corey Bonnell via dev-security-policy]

My understanding is that neither the BRs or any Root Program require that that 
subordinate CA key be weaker or equal in strength to the issuing CA's key.

Additionally, such a requirement would prohibit cross-signs where a "legacy" 
root with a smaller key size would certify a new root CA with a stronger key. 
For that reason, this illustrative control seems problematic.

Thanks,
Corey

-Original Message-
From: dev-security-policy  On 
Behalf Of pfuen...--- via dev-security-policy
Sent: Wednesday, March 10, 2021 4:17 AM
To: Mozilla 
Subject: Clarification request: ECC subCAs under RSA Root

Hello all,

I'd have an open question about the possibility (from a compliance standpoint) 
of having an ECC 256 subordinate under an RSA 2048 Root.

If I look at the WebTrust criteria, I can see this:

4.1.3 CA key generation generates keys that:
a) use a key generation algorithm as disclosed within the CA’s CP and/or CPS;
b) have a key length that is appropriate for the algorithm and for the validity 
period of the CA certificate as disclosed in the CA’s CP and/or CPS. The public 
key length to be certified by a CA is less than or equal to that of the CA’s 
private signing key; and
c) take into account requirements on parent and subordinate CA key sizes and 
have a key size in accordance with the CA’s CP and/or CPS.


My reading of this criteria is that it's not possible to have a subordinate 
with a stronger key than the issuer, but this is unclear when mixing algorithms.

In theory, an ECC 256 subordinate has a stronger crypto than an RSA 2048 Root, 
so if I read the above criteria in terms of crypto strength, I get the 
impression that this is nor allowed. But I don't know if this is an appropriate 
interpretation of the rules.

Can anyone help me to see the light?

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


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Clarification request: ECC subCAs under RSA Root

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

Hello all,

I'd have an open question about the possibility (from a compliance standpoint) 
of having an ECC 256 subordinate under an RSA 2048 Root.

If I look at the WebTrust criteria, I can see this:

4.1.3 CA key generation generates keys that:
a) use a key generation algorithm as disclosed within the CA’s CP and/or CPS;
b) have a key length that is appropriate for the algorithm and for the validity 
period of the CA certificate as disclosed in the CA’s CP and/or CPS. The public 
key length to be certified by a CA is less than or equal to that of the CA’s 
private signing key; and
c) take into account requirements on parent and subordinate CA key sizes and 
have a key size in accordance with the CA’s CP and/or CPS.


My reading of this criteria is that it's not possible to have a subordinate 
with a stronger key than the issuer, but this is unclear when mixing algorithms.

In theory, an ECC 256 subordinate has a stronger crypto than an RSA 2048 Root, 
so if I read the above criteria in terms of crypto strength, I get the 
impression that this is nor allowed. But I don't know if this is an appropriate 
interpretation of the rules.

Can anyone help me to see the light?

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