AW: MRSP Issue #147 - Require EV audits for certificates capable of issuing EV certificates

[Wiedenhorst, Matthias via dev-security-policy]

Hi Ben, Hi all,

sorry for the late reply. Thanks to your summary yesterday, I re-checked all 
the open issues and stumbled upon one question with regard to this issue that 
didn't came to my mind earlier.

I am not sure if I am understanding correctly the desired outcome of this 
change. Forgive me if I am overlooking something to obvious at the moment.
Main parts of the EV requirements and hence of an EV audit are about the 
issuance and certificate profile of end-entity certificates.

Let's say we have an EV-enabled Root CA "A" and a Sub-CA "B", which is only 
used to issue DV certificates, but which is not properly constrained and hence 
would be EV capable.

Now, if I would perform an EV audit on Sub-CA "B", then of course all issued 
end entity certificate would fail to meet the EV requirements on end-entity 
certificates (obviously, because they are DV certificates...). As a result, 
such Sub-CA would be non-conformant with regard to EV requirements and not pass 
the audit.
So is the intent to not allow such Sub-CA's, because they can't pass the 
necessary audit?

Or is the intent only, that the Sub-CA certificate for "B" must meet all EV 
requirements on Sub-CA certificates?

Or did you have a scenario in mind, where a Sub-CA "C" has been used to issue 
EV certificates, is than (temporarily) taken out of service and sometime later 
activated again. Now someone could (bot of course shoulndn't) argue that "C" 
has not been issuing EV certs and hence no EV audits were necessary for that 
period.

Best regards
Matthias


> -Ursprüngliche Nachricht-
> Von: dev-security-policy  Im
> Auftrag von Ben Wilson via dev-security-policy
> Gesendet: Dienstag, 6. Oktober 2020 22:38
> An: mozilla-dev-security-policy 
> 
> Betreff: MRSP Issue #147 - Require EV audits for certificates capable of 
> issuing
> EV certificates
>
>  #147  - Require EV audits 
> for
> certificates capable of issuing EV certificates – Clarify that EV audits are 
> required
> for all intermediate certificates that are technically capable of issuing EV
> certificates, even when not currently issuing EV certificates.
>
> This issue is presented for resolution in the next version of the Mozilla 
> Root Store
> Policy.
>
> Suggested language is presented here:
> https://github.com/BenWilson-
> Mozilla/pkipolicy/commit/a83eca6d7d8bf2a3b30529775cb55b0c8a5f982b
>
>
> The proposal is to replace "if issuing EV certificates" with "if capable of 
> issuing
> EV certificates" in two places -- for WebTrust and ETSI audits.
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy

__
Sitz der Gesellschaft/Headquarter: TÜV Informationstechnik GmbH * 
Langemarckstr. 20 * 45141 Essen, Germany
Registergericht/Register Court: Amtsgericht/Local Court Essen * HRB 11687 * 
USt.-IdNr./VAT No.: DE 176132277 * Steuer-Nr./Tax No.: 111/57062251
Geschäftsführung/Management Board: Dirk Kretzschmar


TÜV NORD GROUP
Expertise for your Success


Please visit our website: www.tuv-nord.com
Besuchen Sie unseren Internetauftritt: www.tuev-nord.de
___
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 #186: Requirement to Disclose Self-signed Certificates

[Ben Wilson via dev-security-policy]

Here is an attempt to address the comments received thus far. In Github,
here is a markup:

https://github.com/BenWilson-Mozilla/pkipolicy/commit/ee19ee89c6101c3a6943956b91574826e34c4932

This sentence would be deleted: "These requirements include all
cross-certificates which chain to a certificate that is included in
Mozilla’s CA Certificate Program."

And the following would be added:

"A certificate is deemed to directly or transitively chain to a CA
certificate included in Mozilla’s CA Certificate Program if:

(1)   the certificate’s Issuer Distinguished Name matches (according to the
name-matching algorithm specified in RFC 5280, section 7.1) the Subject
Distinguished Name in a CA certificate or intermediate certificate that is
in scope according to section 1.1 of this Policy, and

(2)   the certificate is signed with a Private Key whose corresponding
Public Key is encoded in the SubjectPublicKeyInfo of that CA certificate or
intermediate certificate.
Thus, these requirements also apply to so-called reissued/doppelganger CA
certificates (roots and intermediates) and to cross-certificates."

I think it is important not to lose sight of the main reason for this
proposed change-- there has been confusion about whether re-issued root CA
certificates need to be disclosed in the CCADB.

I look forward to your additional comments and suggestions.

Thank you,

Ben


On Mon, Nov 2, 2020 at 11:14 AM Corey Bonnell via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> As an alternate proposal, I suggest replacing the third paragraph of
> section 5.3, which currently reads:
>
> "These requirements include all cross-certificates which chain to a
> certificate that is included in Mozilla’s CA Certificate Program."
>
> with:
>
> "A certificate is considered to directly or transitively chain to a
> certificate included in Mozilla’s CA Certificate Program if there is a CA
> or Intermediate certificate in scope (as defined in section 1.1 of this
> Policy) where both of the following is true:
> 1)  The certificate’s Issuer Distinguished Name matches (according to
> the name-matching algorithm specified in RFC 5280, section 7.1) the Subject
> Distinguished Name of the certificate in scope, and
> 2)  The certificate is signed with a Private Key whose corresponding
> Public Key is encoded in the SubjectPublicKeyInfo of the certificate in
> scope."
>
> This proposal better defines the meaning of chaining to certificates
> included in the Mozilla CA program and covers the various scenarios that
> have caused issues historically concerning cross-certificates and
> self-signed certificates.
>
> Thanks,
> Corey
>
> On Wednesday, October 28, 2020 at 8:25:50 PM UTC-4, Ben Wilson wrote:
> > Issue #186 in Github 
> > deals with the disclosure of CA certificates that directly or
> transitively
> > chain up to an already-trusted, Mozilla-included root. A common scenario
> > for the situation discussed in Issue #186 is when a CA creates a second
> (or
> > third or fourth) root certificate with the same key pair as the root
> that
> > is already in the Mozilla Root Store. This problem exists at the
> > intermediate-CA-certificate level, too, where a self-signed
> > intermediate/subordinate CA certificate is created and not reported.
> >
> > Public disclosure of such certificates is already required by section
> 5.3
> > of the MRSP, which reads, "All certificates that are capable of being
> used
> > to issue new certificates, and which directly or transitively chain to a
> > certificate included in Mozilla’s CA Certificate Program, MUST be
> operated
> > in accordance with this policy and MUST either be technically
> constrained
> > or be publicly disclosed and audited."
> >
> > There have been several instances where a CA operator has not disclosed
> a
> > CA certificate under the erroneous belief that because it is self-signed
> it
> > cannot be trusted in a certificate chain beneath the already-trusted,
> > Mozilla-included CA. This erroneous assumption is further discussed in
> Issue
> > #186 .
> >
> > The third paragraph of MRSP section 5.3 currently reads, " These
> > requirements include all cross-certificates which chain to a certificate
> > that is included in Mozilla’s CA Certificate Program."
> >
> > I recommend that we change that paragraph to read as follows:
> >
> > "These requirements include all cross-certificates *and self-signed
> > certificates (e.g. "Issuer" DN is equivalent to "Subject" DN and public
> key
> > is signed by the private key) that* chain to a CA certificate that is
> > included in Mozilla’s CA Certificate Program*, and CAs must disclose
> such
> > CA certificates in the CCADB*.
> >
> > I welcome your recommendations on how we can make this language even
> more
> > clear.
> >
> > Thanks,
> >
> > Ben
> ___
> dev-security-policy mailing 

Re: Policy 2.7.1: Process Overview

[Ben Wilson via dev-security-policy]

I believe that this is where we are so far.  I have not received any
comments on issues 139, 147, 154, 173, or 205.
I have not sent an email out yet for issues 206, 207, 211 or 218.

*Issue*

*When Announced; Status*

#139  - Audits are
required even if no longer issuing - Clarify that audits are required until
the CA certificate is revoked, expired, or removed. Related to Issue #153.

10/6/2020; no comments yet

#147  - Require EV audits
for certificates capable of issuing EV certificates – Clarify that EV
audits are required for all intermediate certificates that are technically
capable of issuing EV certificates, even when not currently issuing EV
certificates.

10/6/2020; no comments yet

#152  - Add EV Audit
exception for Policy Constraints – leaf certificates do not receive EV
treatment unless signed by an intermediate CA with EV OID or anyPolicy OID,
therefore they can be excluded from EV audits.

10/15/2020; comments

#153  – Cradle-to-Grave
Contiguous Audits – Specify the audits that are required from Root key
generation ceremony until expiration or removal from Mozilla’s root store.
Related to Issue #139.

10/15/2020; comments

#154  - Require Management
Assertions to list Non-compliance – Add to MRSP 2.4 “If being audited to
the WebTrust criteria, the Management Assertion letter MUST include all
known incidents that occurred or were still open/unresolved at any time
during the audit period.”

10/22/2020; no comments yet

#173  - Strengthen
requirement for newly included roots to meet all past and present
requirements – Add language to MRSP 7.1 so that it is clear that before
being included CAs must comply and have complied with past and present
Mozilla Root Store Policy and Baseline Requirements.

10/28/2020; no comments yet

#186  - Clarify MRSP 5.3
Requirement to Disclose Self-signed Certificates – Clarify that self-signed
certificates with the same key pair as an existing root meets MRSP 5.3’s
definition of an intermediate certificate that must be disclosed in the
CCADB.

10/28/2020; comments

#187  - Require disclosure
of incidents in Audit Reports –  To MRSP 3.1.4 “The publicly-available
documentation relating to each audit MUST contain at least the following
clearly-labelled information: “ add “11. all incidents (as defined in
section 2.4) that occurred or were still open/unresolved at any time during
the audit period, or a statement that the auditor is unaware of any;”

10/22/2020; comments

#192  - Require
information about auditor qualifications in the audit report – Require
audit statements to be accompanied by documentation of the auditor’s
qualifications demonstrating the auditor’s competence and experience.

11/3/2020; comments

#205  - Require CAs to
publish accepted methods for proving key compromise – Require CAs to
disclose their acceptable methods for proving key compromise in section
4.9.12 of their CPS.

11/5/2020; no comments yet

#206  - Limit re-use of
domain name verification to 395 days – Amend item 5 in MRSP 2.1 with “and
verify ownership/control of each dNSName and iPAddress in the certificate's
subjectAltName at intervals of 398 days or less;”

Not sent to m.d.s.p. list yet

#207  - Require audit
statements to provide information about which CA Locations were and were
not audited, and the extent to which they were (or were not) audited

Not sent to m.d.s.p. list yet

#211  - Align OCSP
requirements in Mozilla's policy with the section 4.9.10 of the Baseline
Requirements

Not sent to m.d.s.p. list yet

#218  Clarify CRL
requirements for End Entity Certificates – For CRLite, Mozilla would like
to ensure that it has full lists of revoked certificates. If the CA uses
partial CRLs, then require CAs to provide the URL location of their full
and complete CRL in the CCADB.

Not sent to m.d.s.p. list yet

On Mon, Nov 9, 2020 at 2:14 PM Ben Wilson  wrote:

> Re-posting this email to start it with its own subject line and to start a
> new thread:
>
> There have been questions about the process being followed and the comment
> period.  Here is where it now stands.
>
> I intend to introduce the remaining discussion topics over the next three
> weeks. I did not announce an end to the discussion period on purpose, so
> that we can have as full of a discussion as possible. Also, in the next
> three weeks, I