Synopsis of Proposed Changes to MRSP v. 2.7.1

[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;”

Re: Policy 2.7.1: MRSP Issue #218: Clarify CRL requirements for End Entity Certificates

[Ben Wilson via dev-security-policy]

All,
We are going to postpone the resolution of this Issue #218 and the addition
of language to address the "Full CRL" until MRSP version 2.8.
Thanks for your input thus far.
Ben

On Thu, Feb 25, 2021 at 10:59 AM Ben Wilson  wrote:

> As placeholder in the Mozilla Root Store Policy, I'm proposing the
> following sentence for section 6.1 - "A CA MUST ensure that it populates
> the CCADB with the appropriate 'full CRL' in the CCADB revocation
> information field pertaining to certificates issued by the CA
>  for each
> intermediate CA technically capable of issuing server certificates." (The
> hyperlink isn't active yet until we have the CCADB language and
> implementation clarified, per Kathleen's recent email and responses
> thereto.)Here it is on GitHub -
> https://github.com/BenWilson-Mozilla/pkipolicy/commit/26c1ee4ea8be1a07f86253e38fbf0cc043e12d48.
> Caveat - other browsers, such as Apple, will likely have more encompassing
> implementation requirements for when to populate these "full CRL" fields.
>
> On Mon, Jan 25, 2021 at 10:16 AM Aaron Gable 
> wrote:
>
>> I think that an explicit carve-out for time-scoped CRLs is a very good
>> idea.
>>
>> In the case that this change to the MRSP is adopted, I suspect that LE
>> would scope CRLs by notAfter quite tightly, with perhaps one CRL per 24 or
>> even 6 hours of issuance. We would pick a small interval such that we could
>> guarantee that each CRL would still be a reasonable size even in the face
>> of a mass revocation event.
>>
>> Producing CRLs at that rate, it would be very valuable to be able to
>> gracefully age CRLs out once there is no possibility for a revocation
>> status update for any certificate in their scope.
>>
>> Aaron
>>
>> On Sun, Jan 24, 2021 at 10:22 AM Ben Wilson via dev-security-policy <
>> dev-security-policy@lists.mozilla.org> wrote:
>>
>>> All,
>>>
>>> Another suggestion came in for clarification that hasn't been raised on
>>> the
>>> list yet, so I'll try and explain the scenario here.
>>>
>>> Normally, a CA must publish and update its CRLs until the end of the CA
>>> certificate's expiration. However, I think that some CAs partition their
>>> CRLs based on issuance time, e.g., all certificates issued during January
>>> 2021. And all of those certificates would expire after the applicable
>>> validity period.  I think CAs don't continue to regenerate or reissue
>>> those
>>> types of partitioned CRLs which only contain certificates that have
>>> expired.  So maybe we need to add an express exception that allows CAs to
>>> omit those obsolete CRLs from the JSON file -- as long as the JSON file
>>> contains the equivalent of  a "full and complete" CRL.
>>>
>>> Thoughts?
>>>
>>> Thanks,
>>> Ben
>>>
>>>
>>> On Wed, Jan 13, 2021 at 8:57 AM Rob Stradling  wrote:
>>>
>>> > Hi Ben.
>>> >
>>> > > *A CA technically capable of issuing server certificates MUST ensure
>>> > that
>>> > > the CCADB field "Full CRL Issued By This CA" contains either the URL
>>> for
>>> > > the full and complete CRL or the URL for the JSON file containing all
>>> > URLs
>>> > > for CRLs that when combined are the equivalent of the full and
>>> complete
>>> > CRL*
>>> >
>>> > As a consumer of this data (crt.sh), I'd much prefer to see "Full CRL
>>> > Issued By This CA" and "the URL for the JSON file" as 2 separate
>>> fields in
>>> > the CCADB.  CAs would then be expected to fill in one field or the
>>> other,
>>> > but not both.  Is that possible?
>>> >
>>> > To ensure that these JSON files can be programmatically parsed, I
>>> suggest
>>> > specifying the requirement a bit more strictly.  Something like this:
>>> >   "...or the URL for a file that contains only a JSON Array, whose
>>> > elements are URLs of DER encoded CRLs that when combined are the
>>> equivalent
>>> > of a full and complete CRL"
>>> >
>>> > > I propose that this new CCADB field be populated in all situations
>>> where
>>> > the CA is enabled for server certificate issuance.
>>> >
>>> > Most Root Certificates are "enabled for server certificate issuance".
>>> > Obviously CAs shouldn't issue leaf certs directly from roots, but
>>> > nonetheless the technical capability does exist.  However, currently
>>> CAs
>>> > can't edit Root Certificate records in the CCADB, which makes
>>> populating
>>> > these new field(s) "in all situations" rather hard.
>>> >
>>> > Since OneCRL covers revocations of intermediate certs, may I suggest
>>> that
>>> > CAs should only be required to populate these new field(s) in
>>> intermediate
>>> > certificate records (and not in root certificate records)?
>>> >
>>> > Relatedly, "A CA technically capable of...that the CCADB field" seems
>>> > wrong.  CCADB "CA Owner" records don't/won't contain the new field(s).
>>> > Similar language elsewhere in the policy (section 5.3.2) says "All
>>> > certificates that are capable of being used to..." (rather than "All
>>> > CAs...").
>>> >
>>> > 

Re: Policy 2.7.1: MRSP Issue #206: Limit re-use of domain name verification to 398 days

[Ben Wilson via dev-security-policy]

All,

Here is the currently proposed wording for subsection 5.1 of MRSP section
2.1:

" 5.1. for server certificates issued on or after October 1, 2021, verify
each dNSName or IPAddress in a SAN or commonName at an interval of 398 days
or less;"

Ben

On Fri, Feb 26, 2021 at 9:48 AM Ryan Sleevi  wrote:

>
>
> On Thu, Feb 25, 2021 at 7:55 PM Clint Wilson via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> I think it makes sense to separate out the date for domain validation
>> expiration from the issuance of server certificates with previously
>> validated domain names, but agree with Ben that the timeline doesn’t seem
>> to need to be prolonged. What about something like this:
>>
>> 1. Domain name or IP address verifications performed on or after July 1,
>> 2021 may be reused for a maximum of 398 days.
>> 2. Server certificates issued on or after September 1, 2021 must have
>> completed domain name or IP address verification within the preceding 398
>> days.
>>
>> This effectively stretches the “cliff” out across ~6 months (now through
>> the end of August), which seems reasonable.
>>
>
> Yeah, that does sound reasonable.
>
___
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 #192: Require information about auditor qualifications in the audit report

[Ben Wilson via dev-security-policy]

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  wrote:

> All,
>
> I have edited the proposed resolution of Issue #192
> 
> 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
> 
> 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
>
>
> 
>
>
>
> 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 that require disclosing the relevant
>> skills and
>> > > experience of the audit team to the client? (E.g. as done by BSI C5
>> audits
>> > > under ISAE 3000)
>> > >
>> > > 3) Are you aware of such reports naming multiple parties for the use
>> of the
>> > > report (e.g. as done by FPKI audits)
>> > >
>> > > 4) Are you aware of schemes in which a supplier requires a vendor to
>> be
>> > > audited, and ensures that the customer of supplier are able to access
>> such
>> > > audits as part of their reliance upon supplier? (Note, this doesn’t
>> have to
>> > > be limited to ISMS systems)
>> > >
>> > > I’m trying to understand what, given the prevalence of these
>> practices,
>> > > makes these instances *not* a comparable world, since it seems that
>> helps
>> > > move closer to solutions.
>> > Ryan, I hope you are not suggesting I am dodging you points. That would
>> be absurd. Let me use different words as comparable world seems to be
>> tripping you up. You are not providing a general/public distribution
>> example to make your point so it is baseless. You are using a restricted
>> opinion from EY and neither Ryan Sleevi nor Google are listed as the two
>> intended users. The closest I have seen to support your desire to name
>> individual auditors is in public company audit reports, which are housed on
>> the SEC website. To be clear, of your two examples, one is an opinion,
>> which is restricted, and the other represents the guidelines. Perhaps you
>> have seen a public/general distribution report from your second opinion as
>> I do not see it in this thread. I am aware, as mentioned previously, of the
>> Federal PKI program desiring to know more about team 

Re: Policy 2.7.1: MRSP Issue #187: Require disclosure of incidents in Audit Reports

[Ben Wilson via dev-security-policy]

Kathleen and I edited the proposed language (
https://github.com/BenWilson-Mozilla/pkipolicy/commit/a69aa03fb92d1b0c3f74fd560dffefdeed934b45)
to now read:

"The publicly-available documentation relating to each audit MUST contain
at least the following clearly-labelled information:
...
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;"

Additional guidance will be provided here:
https://wiki.mozilla.org/CA/Audit_Statements and/or here:
https://wiki.mozilla.org/CA/Responding_To_An_Incident



On Mon, Feb 15, 2021 at 11:47 AM Jeff Ward via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Friday, February 12, 2021 at 10:27:11 AM UTC-6, Ben Wilson wrote:
> > I'm fine with that suggestion.
> > On Fri, Feb 12, 2021 at 5:06 AM malcol...--- via dev-security-policy <
> > dev-secur...@lists.mozilla.org> wrote:
> >
> > > On Thursday, 11 February 2021 at 21:14:13 UTC, Ben Wilson wrote:
> > > > 11. all incidents (as defined in section 2.4), including those
> reported
> > > in
> > > > Bugzilla, that were:
> > > > * disclosed by the CA or discovered by the auditor, and
> > > > * unresolved at any time during the audit period;
> > > >
> > > > The idea is that all "incidents" must be reported if they were
> > > "unresolved"
> > > > - which would include those that occurred or were open - at any time
> > > during
> > > > the audit period.
> > > >
> > >
> > > Wouldn't it be clearer to non-native English speakers to avoid the
> nuance
> > > associated with "unresolved at any time" needing to imply both those
> that
> > > occurred or those that were still open?
> > >
> > > Why not amend the language to just say:
> > >
> > > 11. all incidents (as defined in section 2.4), including those
> reported in
> > > Bugzilla, that:
> > > * were disclosed by the CA or discovered by the auditor, and
> > > * occurred or were open at any time during the audit period;
> > > ___
> > > dev-security-policy mailing list
> > > dev-secur...@lists.mozilla.org
> > > https://lists.mozilla.org/listinfo/dev-security-policy
> > >
> This wording works from a WebTrust perspective as well.  Thanks!
> ___
> 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]

Also, I neglected to mention it before, but this issue is also related to
Issue #173.  While section 7.1 already states that CAs must provide
evidence of CA compliance from "creation," the Issue #173 proposal is that
section 7.1 be amended to say, "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*."  I don't believe I
received any comments on that language. See
https://groups.google.com/g/mozilla.dev.security.policy/c/DChXLJrMwag/m/uGpEqiEcBgAJ


On Sat, Mar 6, 2021 at 9:17 PM Ben Wilson  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-security-policy@lists.mozilla.org> wrote:
>
>> On Thursday, February 25, 2021 at 2:30:52 PM UTC-5, bwi...@mozilla.com
>> wrote:
>> > I haven't seen any response to my question about whether there is still
>> a
>> > concern over the language "as evidenced by a Qualified Auditor's key
>> > destruction report".
>> > I did add "This cradle-to-grave audit requirement applies equally to
>> > subordinate CAs as it does to root CAs" to address the scenarios that
>> were
>> > raised.
>> > So I am going to assume that this issue is resolved and that we can
>> move
>> > this proposed change forward.
>> > See
>> >
>> https://github.com/BenWilson-Mozilla/pkipolicy/commit/c8bdb949020634b1f8fa31bc060229c600fe6f9d
>>
>> Ben, sorry for the late input.
>>
>> We are onboard with the cradle-to-grave audit as we have experience
>> auditing non-functioning CAs before they go into production and after they
>> have stopped issuing certificates. However, I think there might be an issue
>> in the requirement with the start and stop time of cradle-to-grave.
>>
>> At the beginning, I think that CAs will generate one or many keys, but
>> will not assign them to CAs. The gap period could be days to years. Since
>> the requirement says "from the time of CA key pair generation", do we want
>> an audit of an unassigned key? Or should the audit start once the key has
>> been assigned and the CA certificate has been generated?
>>
>> At the end, subordinate CA certificate(s) may be revoked or may expire.
>> Once the certificate(s) are revoked or expired, is this a reasonable time
>> to stop auditing the CA as trust has been removed? Of course if the
>> certificates are not revoked or expired, then all copies of the keys should
>> be destroyed to stop the audit. However, I think the best practice should
>> be that certificates should be revoked/expired at time of key destruction.
>> ___
>> 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