Re: Policy 2.7.1: MRSP Issue #207: Require audit statements to provide information about which CA Locations were audited

[Ben Wilson via dev-security-policy]

The current proposed draft of changes is at
https://github.com/BenWilson-Mozilla/pkipolicy/commit/443b4c5d5155942a216322480f3a6a273ea2

Right now, I'm considering having subsection of MRSP section 3.1.4 say,
"the CA locations that were or were not audited" - with a hyperlink to
https://wiki.mozilla.org/CA/Audit_Statements#Audited_Locations, and then
elaborating there as needed.


On Wed, Jan 13, 2021 at 10:25 AM Ben Wilson  wrote:

> Thanks, Jeff.  These are useful comments, and I will take them into
> consideration in revising our proposal.
>
> On Tue, Jan 12, 2021 at 8:38 AM Jeff Ward via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> On Sunday, January 3, 2021 at 8:38:05 AM UTC-6, Jeff Ward wrote:
>> > On Tuesday, December 15, 2020 at 2:41:10 PM UTC-6, Ben Wilson wrote:
>> > > All,
>> > >
>> > > This email is part of the discussion for the next version of the
>> Mozilla
>> > > Root Store Policy (MSRP), version 2.7.1, to be published during of
>> Q1-2021.
>> > >
>> > > For audit delays, we currently require that audit statements disclose
>> the
>> > > locations that were and were not audited, but that requirement has
>> not been
>> > > incorporated yet into the MRSP. See
>> > > https://wiki.mozilla.org/CA/Audit_Statements#Minimum_Expectations.
>> That
>> > > provision reads as follows:
>> > >
>> > > Disclose each location (at the state/province level) that was
>> included in
>> > > the scope of the audit or should have been included in the scope of
>> the
>> > > audit, whether the inspection was physically carried out in person at
>> each
>> > > location, and which audit criteria were checked (or not checked) at
>> each
>> > > location.
>> > >
>> > > - If the CA has more than one location in the same state/province,
>> then
>> > > use terminology to clarify the number of facilities in that
>> state/province
>> > > and whether or not all of them were audited. For example: "Facility 1
>> in
>> > > Province", "Facility 2 in Province, Facility 3 in Province" *or*
>> > > "Primary Facility in Province", "Secondary Facility in Province",
>> "Tertiary
>> > > Facility in Province".
>> > > - The public audit statement does not need to identify the type of
>> > > Facility.
>> > > - "Facility" includes: data center locations, registration authority
>> > > locations, where IT and business process controls of CA operations
>> are
>> > > performed, facility hosting an active HSM with CA private keys,
>> > > facility or
>> > > bank deposit box storing a deactivated and encrypted copy of a
>> > > private key.
>> > >
>> > > It is proposed by Issue #207
>> > >  that this language
>> > > requiring the disclosure of site locations--audited and unaudited--be
>> made
>> > > clearly part of the MSRP by reference to the language above.
>> > >
>> > > A similar method of incorporating by reference has been taken in
>> section
>> > > 2.4 of the MSRP
>> > > <
>> https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#24-incidents>
>>
>> > > with respect to incident reporting and in section 7.1
>> > > <
>> https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#71-inclusions>
>>
>> > > with requirements for the CA inclusion process.
>> > >
>> > > It is proposed that we add a new subsection 10 to MRSP section 3.1.4
>> > > <
>> https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#314-public-audit-information>
>>
>> > > that would require that audit documentation disclose the facility
>> site
>> > > locations that were, or were not, examined.
>> > >
>> > > One concern that has been raised previously is that the Baseline
>> > > Requirements do not define "facility site location". However, we
>> believe
>> > > that the language above at
>> > > https://wiki.mozilla.org/CA/Audit_Statements#Minimum_Expectations
>> > > accomplishes that. We're open to suggestions for re-wording parts of
>> it to
>> > > make it even better.
>> > >
>> > > Currently, the audit letter template for WebTrust for CAs references
>> the
>> > > site location audited (at the level of specificity that is proposed
>> > > above). Over this past year, due to COVID, some ETSI attestation
>> letters
>> > > have also explained which sites were and were not checked. This
>> approach
>> > > seems to work, and the additional information will be beneficial in
>> the
>> > > future as we evaluate the security and trust of PKI service
>> providers.
>> > >
>> > > So, for the page cited above, we intend to move "Minimum
>> Expectations" out
>> > > from under "Audit Delay" so that it stands separately as a
>> requirement for
>> > > disclosing the facility site location. Then we will also revise MRSP
>> > > section 3.1.4 by inserting a new subsection 10 to require "facility
>> site
>> > > locations that were, or were not, examined" with a hyperlink to the
>> Minimum
>> > > Expectations language cited above.
>> > >
>> > 

Re: Policy 2.7.1: MRSP Issue #207: Require audit statements to provide information about which CA Locations were audited

[Ben Wilson via dev-security-policy]

Thanks, Jeff.  These are useful comments, and I will take them into
consideration in revising our proposal.

On Tue, Jan 12, 2021 at 8:38 AM Jeff Ward via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Sunday, January 3, 2021 at 8:38:05 AM UTC-6, Jeff Ward wrote:
> > On Tuesday, December 15, 2020 at 2:41:10 PM UTC-6, Ben Wilson wrote:
> > > All,
> > >
> > > This email is part of the discussion for the next version of the
> Mozilla
> > > Root Store Policy (MSRP), version 2.7.1, to be published during of
> Q1-2021.
> > >
> > > For audit delays, we currently require that audit statements disclose
> the
> > > locations that were and were not audited, but that requirement has not
> been
> > > incorporated yet into the MRSP. See
> > > https://wiki.mozilla.org/CA/Audit_Statements#Minimum_Expectations.
> That
> > > provision reads as follows:
> > >
> > > Disclose each location (at the state/province level) that was included
> in
> > > the scope of the audit or should have been included in the scope of
> the
> > > audit, whether the inspection was physically carried out in person at
> each
> > > location, and which audit criteria were checked (or not checked) at
> each
> > > location.
> > >
> > > - If the CA has more than one location in the same state/province,
> then
> > > use terminology to clarify the number of facilities in that
> state/province
> > > and whether or not all of them were audited. For example: "Facility 1
> in
> > > Province", "Facility 2 in Province, Facility 3 in Province" *or*
> > > "Primary Facility in Province", "Secondary Facility in Province",
> "Tertiary
> > > Facility in Province".
> > > - The public audit statement does not need to identify the type of
> > > Facility.
> > > - "Facility" includes: data center locations, registration authority
> > > locations, where IT and business process controls of CA operations are
> > > performed, facility hosting an active HSM with CA private keys,
> > > facility or
> > > bank deposit box storing a deactivated and encrypted copy of a
> > > private key.
> > >
> > > It is proposed by Issue #207
> > >  that this language
> > > requiring the disclosure of site locations--audited and unaudited--be
> made
> > > clearly part of the MSRP by reference to the language above.
> > >
> > > A similar method of incorporating by reference has been taken in
> section
> > > 2.4 of the MSRP
> > > <
> https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#24-incidents>
>
> > > with respect to incident reporting and in section 7.1
> > > <
> https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#71-inclusions>
>
> > > with requirements for the CA inclusion process.
> > >
> > > It is proposed that we add a new subsection 10 to MRSP section 3.1.4
> > > <
> https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#314-public-audit-information>
>
> > > that would require that audit documentation disclose the facility site
> > > locations that were, or were not, examined.
> > >
> > > One concern that has been raised previously is that the Baseline
> > > Requirements do not define "facility site location". However, we
> believe
> > > that the language above at
> > > https://wiki.mozilla.org/CA/Audit_Statements#Minimum_Expectations
> > > accomplishes that. We're open to suggestions for re-wording parts of
> it to
> > > make it even better.
> > >
> > > Currently, the audit letter template for WebTrust for CAs references
> the
> > > site location audited (at the level of specificity that is proposed
> > > above). Over this past year, due to COVID, some ETSI attestation
> letters
> > > have also explained which sites were and were not checked. This
> approach
> > > seems to work, and the additional information will be beneficial in
> the
> > > future as we evaluate the security and trust of PKI service providers.
> > >
> > > So, for the page cited above, we intend to move "Minimum Expectations"
> out
> > > from under "Audit Delay" so that it stands separately as a requirement
> for
> > > disclosing the facility site location. Then we will also revise MRSP
> > > section 3.1.4 by inserting a new subsection 10 to require "facility
> site
> > > locations that were, or were not, examined" with a hyperlink to the
> Minimum
> > > Expectations language cited above.
> > >
> > > We look forward to your comments and suggestions.
> > >
> > > Sincerely yours,
> > >
> > > Ben
> > Hi Ben. Happy New Year. I have asked the WebTrust Task Force members to
> provide their comments and Don and I will then provide a more detailed
> response. I wanted to be sure to get each of the major firms' feedback
> before responding.
> >
> > Thank you.
> >
> > Jeff
>
> Ben, Don and I offer the following response, which has been vetted through
> the WebTrust Task Force:
>
> Proposed Requirement
> Disclose each location (at the state/province level) that 

Re: Policy 2.7.1: MRSP Issue #207: Require audit statements to provide information about which CA Locations were audited

[Jeff Ward via dev-security-policy]

On Sunday, January 3, 2021 at 8:38:05 AM UTC-6, Jeff Ward wrote:
> On Tuesday, December 15, 2020 at 2:41:10 PM UTC-6, Ben Wilson wrote: 
> > All, 
> > 
> > This email is part of the discussion for the next version of the Mozilla 
> > Root Store Policy (MSRP), version 2.7.1, to be published during of Q1-2021. 
> > 
> > For audit delays, we currently require that audit statements disclose the 
> > locations that were and were not audited, but that requirement has not been 
> > incorporated yet into the MRSP. See 
> > https://wiki.mozilla.org/CA/Audit_Statements#Minimum_Expectations. That 
> > provision reads as follows: 
> > 
> > Disclose each location (at the state/province level) that was included in 
> > the scope of the audit or should have been included in the scope of the 
> > audit, whether the inspection was physically carried out in person at each 
> > location, and which audit criteria were checked (or not checked) at each 
> > location. 
> > 
> > - If the CA has more than one location in the same state/province, then 
> > use terminology to clarify the number of facilities in that state/province 
> > and whether or not all of them were audited. For example: "Facility 1 in 
> > Province", "Facility 2 in Province, Facility 3 in Province" *or* 
> > "Primary Facility in Province", "Secondary Facility in Province", "Tertiary 
> > Facility in Province". 
> > - The public audit statement does not need to identify the type of 
> > Facility. 
> > - "Facility" includes: data center locations, registration authority 
> > locations, where IT and business process controls of CA operations are 
> > performed, facility hosting an active HSM with CA private keys, 
> > facility or 
> > bank deposit box storing a deactivated and encrypted copy of a 
> > private key. 
> > 
> > It is proposed by Issue #207 
> >  that this language 
> > requiring the disclosure of site locations--audited and unaudited--be made 
> > clearly part of the MSRP by reference to the language above. 
> > 
> > A similar method of incorporating by reference has been taken in section 
> > 2.4 of the MSRP 
> > 
> >  
> > with respect to incident reporting and in section 7.1 
> > 
> >  
> > with requirements for the CA inclusion process. 
> > 
> > It is proposed that we add a new subsection 10 to MRSP section 3.1.4 
> > 
> >  
> > that would require that audit documentation disclose the facility site 
> > locations that were, or were not, examined. 
> > 
> > One concern that has been raised previously is that the Baseline 
> > Requirements do not define "facility site location". However, we believe 
> > that the language above at 
> > https://wiki.mozilla.org/CA/Audit_Statements#Minimum_Expectations 
> > accomplishes that. We're open to suggestions for re-wording parts of it to 
> > make it even better. 
> > 
> > Currently, the audit letter template for WebTrust for CAs references the 
> > site location audited (at the level of specificity that is proposed 
> > above). Over this past year, due to COVID, some ETSI attestation letters 
> > have also explained which sites were and were not checked. This approach 
> > seems to work, and the additional information will be beneficial in the 
> > future as we evaluate the security and trust of PKI service providers. 
> > 
> > So, for the page cited above, we intend to move "Minimum Expectations" out 
> > from under "Audit Delay" so that it stands separately as a requirement for 
> > disclosing the facility site location. Then we will also revise MRSP 
> > section 3.1.4 by inserting a new subsection 10 to require "facility site 
> > locations that were, or were not, examined" with a hyperlink to the Minimum 
> > Expectations language cited above. 
> > 
> > We look forward to your comments and suggestions. 
> > 
> > Sincerely yours, 
> > 
> > Ben
> Hi Ben. Happy New Year. I have asked the WebTrust Task Force members to 
> provide their comments and Don and I will then provide a more detailed 
> response. I wanted to be sure to get each of the major firms' feedback before 
> responding. 
> 
> Thank you. 
> 
> Jeff

Ben, Don and I offer the following response, which has been vetted through the 
WebTrust Task Force:

Proposed Requirement
Disclose each location (at the state/province level) that was included in the 
scope of the audit or should have been included in the scope of the audit, 
whether the inspection was physically carried out in person at each location, 
and which audit criteria were checked (or not checked) at each location.
•   If the CA has more than one location in the same state/province, then 
use terminology to clarify the 

Re: Policy 2.7.1: MRSP Issue #207: Require audit statements to provide information about which CA Locations were audited

[Jeff Ward via dev-security-policy]

On Tuesday, December 15, 2020 at 2:41:10 PM UTC-6, Ben Wilson wrote:
> All, 
> 
> This email is part of the discussion for the next version of the Mozilla 
> Root Store Policy (MSRP), version 2.7.1, to be published during of Q1-2021. 
> 
> For audit delays, we currently require that audit statements disclose the 
> locations that were and were not audited, but that requirement has not been 
> incorporated yet into the MRSP. See 
> https://wiki.mozilla.org/CA/Audit_Statements#Minimum_Expectations. That 
> provision reads as follows: 
> 
> Disclose each location (at the state/province level) that was included in 
> the scope of the audit or should have been included in the scope of the 
> audit, whether the inspection was physically carried out in person at each 
> location, and which audit criteria were checked (or not checked) at each 
> location. 
> 
> - If the CA has more than one location in the same state/province, then 
> use terminology to clarify the number of facilities in that state/province 
> and whether or not all of them were audited. For example: "Facility 1 in 
> Province", "Facility 2 in Province, Facility 3 in Province" *or* 
> "Primary Facility in Province", "Secondary Facility in Province", "Tertiary 
> Facility in Province". 
> - The public audit statement does not need to identify the type of 
> Facility. 
> - "Facility" includes: data center locations, registration authority 
> locations, where IT and business process controls of CA operations are 
> performed, facility hosting an active HSM with CA private keys, 
> facility or 
> bank deposit box storing a deactivated and encrypted copy of a 
> private key. 
> 
> It is proposed by Issue #207 
>  that this language 
> requiring the disclosure of site locations--audited and unaudited--be made 
> clearly part of the MSRP by reference to the language above. 
> 
> A similar method of incorporating by reference has been taken in section 
> 2.4 of the MSRP 
> 
>  
> with respect to incident reporting and in section 7.1 
> 
>  
> with requirements for the CA inclusion process. 
> 
> It is proposed that we add a new subsection 10 to MRSP section 3.1.4 
> 
>  
> that would require that audit documentation disclose the facility site 
> locations that were, or were not, examined. 
> 
> One concern that has been raised previously is that the Baseline 
> Requirements do not define "facility site location". However, we believe 
> that the language above at 
> https://wiki.mozilla.org/CA/Audit_Statements#Minimum_Expectations 
> accomplishes that. We're open to suggestions for re-wording parts of it to 
> make it even better. 
> 
> Currently, the audit letter template for WebTrust for CAs references the 
> site location audited (at the level of specificity that is proposed 
> above). Over this past year, due to COVID, some ETSI attestation letters 
> have also explained which sites were and were not checked. This approach 
> seems to work, and the additional information will be beneficial in the 
> future as we evaluate the security and trust of PKI service providers. 
> 
> So, for the page cited above, we intend to move "Minimum Expectations" out 
> from under "Audit Delay" so that it stands separately as a requirement for 
> disclosing the facility site location. Then we will also revise MRSP 
> section 3.1.4 by inserting a new subsection 10 to require "facility site 
> locations that were, or were not, examined" with a hyperlink to the Minimum 
> Expectations language cited above. 
> 
> We look forward to your comments and suggestions. 
> 
> Sincerely yours, 
> 
> Ben

Hi Ben.  Happy New Year.  I have asked the WebTrust Task Force members to 
provide their comments and Don and I will then provide a more detailed 
response.  I wanted to be sure to get each of the major firms' feedback before 
responding.

Thank you.

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