Re: Synopsis of Proposed Changes to MRSP v. 2.7.1

2021-03-10 Thread 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


Re: Synopsis of Proposed Changes to MRSP v. 2.7.1

2021-03-10 Thread 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


Synopsis of Proposed Changes to MRSP v. 2.7.1

2021-03-08 Thread Ben Wilson via dev-security-policy
All,


Below are the summaries of the proposed resolutions of the issues slated to
be addressed by version 2.7.1 of the Mozilla Root Store Policy.


A full redline of the proposed changes can be seen here by clicking on the
"Files changed" tab:
https://github.com/mozilla/pkipolicy/compare/master...BenWilson-Mozilla:2.7.1


I intend to close public discussion on the proposed changes sometime next
week. That will be followed by finalizing anything that needs to be
addressed, Mozilla internal reviews, and a CA Communication and survey.


Thanks for your contributions.


Sincerely yours,


Ben


--


#130 resolved - updates required to current audit versions

References to updated audit criteria are found here:

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


#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


#147 resolved - 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.

Resolved with hyperlink to:
https://wiki.mozilla.org/CA/EV_Processing_for_CAs#EV_TLS_Capable

#152 resolved - 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.

Resolved with hyperlink to:
https://wiki.mozilla.org/CA/EV_Processing_for_CAs#EV_TLS_Capable

#153 resolved – 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.

Resolved with:

“Full-surveillance period-of-time audits MUST be conducted and updated
audit information provided no less frequently than annually from the time
of CA key pair generation until the CA certificate is no longer trusted by
Mozilla's root store or until all copies of the CA private key have been
completely destroyed, as evidenced by a Qualified Auditor's key destruction
report, whichever occurs sooner. This cradle-to-grave audit requirement
applies equally to subordinate CAs as it does to root CAs. Successive
period-of-time audits MUST be contiguous (no gaps).”

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


#154 closed/removed - Require Management Assertions to list Non-compliance
– Add to MRSP section 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.”

https://github.com/mozilla/pkipolicy/issues/154#issuecomment-793124154

#173 resolved - Strengthen requirement for newly included roots to meet all
past and present requirements – Add language to MRSP section 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.

Section “Before being included, CAs MUST provide evidence that their CA
certificates fully comply with the current Mozilla Root Store Requirements
and Baseline Requirements, and have continually, from the time of CA
private key creation, complied with the then-current Mozilla Root Store
Policy and Baseline Requirements.”

https://github.com/BenWilson-Mozilla/pkipolicy/commit/0d72d9be5acca17ada34cf7e380741e27ee84e55


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

Resolved with:

"Thus, the operator of a CA certificate trusted in Mozilla’s CA Certificate
Program MUST disclose in the CCADB all non-technically constrained CA
certificates they issue that chain up to that CA certificate trusted in
Mozilla’s CA Certificate Program. This applies to all non-technically
constrained CA certificates, including those that are self-signed,
doppelgänger, reissued, or cross-signed."

See
https://github.com/BenWilson-Mozilla/pkipolicy/commit/5a3dd2e9d92ec689e08bf1cfa279121e2bb0478b


#187 resolved - Require disclosure of incidents in Audit Reports –  To MRSP
section 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) …”

Resolved with:

“11. all incidents (as defined in section 2.4) disclosed by the CA,
discovered by the auditor, or reported by a third party, that, at any time
during the audit period, occurred or were open in Bugzilla;”