Re: Policy 2.6 Proposal: Audit requirements for new subCA certificates

[Wayne Thayer via dev-security-policy]

To close out discussion on this issue, I've updated the change by removing
the requirement to list each subCA certificate in the CPS:
https://github.com/mozilla/pkipolicy/commit/1bdcd53baf2e8b9006a5e13923ce3d66eeff927e

- Wayne


On Mon, Apr 16, 2018 at 4:51 PM, Wayne Thayer <wtha...@mozilla.com> wrote:

> On Wed, Apr 11, 2018 at 3:49 PM, Wayne Thayer <wtha...@mozilla.com> wrote:
>
>> As an alternative to requiring newly-issued subCA Certificates to be
>> listed in the relevant CP/CPS prior to issuing certificates, would it be
>> reasonable for Mozilla to require the Certificate Policies extension in
>> these certificates to contain a URL pointing to the relevant policy
>> document(s)? I believe that most subCA certificates already contain this
>> information.
>>
>> Section 7.1.2.2 of the BRs states that the certificatePolicies:
> policyQualifiers:qualifier:cPSuri for a subCA certificate should contain
> a pointer to the **root** CA's policies. If this is correct, then my
> proposal doesn't solve the problem of requiring disclosure of the policies
> that a new subordinate CA certificate is operating under.
>
> In theory, we could also permit three options - add the new subCA
>> certificate to the relevant CP/CPS, include a Certificate Policies pointer,
>> or publish an attestation, but I'd prefer a single, consistent mechanism
>> that allows a relying party to determine which policies apply.
>>
>> Based on the feedback so far, none of these options is desirable. I
> propose that we only make the change to section 5.3.2 of the Mozilla policy
> that clarifies the audit requirements for new subCA certificates, as
> follows:
>
> If the subordinate CA has a currently valid audit report at the time of
>> creation of the certificate, it MUST appear on the subordinate CA's next
>> periodic audit reports.
>>
>
> - Wayne
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.6 Proposal: Audit requirements for new subCA certificates

[Wayne Thayer via dev-security-policy]

On Wed, Apr 11, 2018 at 3:49 PM, Wayne Thayer <wtha...@mozilla.com> wrote:

> As an alternative to requiring newly-issued subCA Certificates to be
> listed in the relevant CP/CPS prior to issuing certificates, would it be
> reasonable for Mozilla to require the Certificate Policies extension in
> these certificates to contain a URL pointing to the relevant policy
> document(s)? I believe that most subCA certificates already contain this
> information.
>
> Section 7.1.2.2 of the BRs states that the
certificatePolicies:policyQualifiers:qualifier:cPSuri for a subCA
certificate should contain a pointer to the **root** CA's policies. If this
is correct, then my proposal doesn't solve the problem of requiring
disclosure of the policies that a new subordinate CA certificate is
operating under.

In theory, we could also permit three options - add the new subCA
> certificate to the relevant CP/CPS, include a Certificate Policies pointer,
> or publish an attestation, but I'd prefer a single, consistent mechanism
> that allows a relying party to determine which policies apply.
>
> Based on the feedback so far, none of these options is desirable. I
propose that we only make the change to section 5.3.2 of the Mozilla policy
that clarifies the audit requirements for new subCA certificates, as
follows:

If the subordinate CA has a currently valid audit report at the time of
> creation of the certificate, it MUST appear on the subordinate CA's next
> periodic audit reports.
>

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

Re: Policy 2.6 Proposal: Audit requirements for new subCA certificates

[Wayne Thayer via dev-security-policy]

As an alternative to requiring newly-issued subCA Certificates to be listed
in the relevant CP/CPS prior to issuing certificates, would it be
reasonable for Mozilla to require the Certificate Policies extension in
these certificates to contain a URL pointing to the relevant policy
document(s)? I believe that most subCA certificates already contain this
information.

In theory, we could also permit three options - add the new subCA
certificate to the relevant CP/CPS, include a Certificate Policies pointer,
or publish an attestation, but I'd prefer a single, consistent mechanism
that allows a relying party to determine which policies apply.

- Wayne

On Thu, Apr 5, 2018 at 1:12 PM, Ben Wilson <ben.wil...@digicert.com> wrote:

> That is a distinction without a difference.  If I create a subCA, it’s
> because I want to put it into production soon afterwards. This proposal is
> going to add hours per week that DigiCert is going to have to do, on top of
> reporting CAs to the CCADB, and everything else that CAs have to do.  What
> is the security-critical driver behind this?  Where is the
> risk-cost-benefit analysis?
>
>
>
> *From:* Wayne Thayer [mailto:wtha...@mozilla.com]
> *Sent:* Thursday, April 5, 2018 1:56 PM
> *To:* Ben Wilson <ben.wil...@digicert.com>
> *Cc:* Dimitris Zacharopoulos <ji...@it.auth.gr>; r...@sleevi.com;
> mozilla-dev-security-policy <mozilla-dev-security-pol...@lists.mozilla.org
> >
> *Subject:* Re: Policy 2.6 Proposal: Audit requirements for new subCA
> certificates
>
>
>
> On Thu, Apr 5, 2018 at 12:05 PM, Ben Wilson <ben.wil...@digicert.com>
> wrote:
>
> If I create a new sub CA on a weekly basis, will that mean that I have to
> republish my CPS every week?  That makes absolutely no sense.
>
> As proposed, the requirement isn't based on when the subCA certificate is
> created - it requires the subCA to be added to the CP/CPS before being used
> to issue certificates. Refer to the following thread for background on this
> proposal: https://groups.google.com/d/msg/mozilla.dev.security.
> policy/CAaC2a2HMiQ/IKimeW4NBgAJ
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.6 Proposal: Remove obsolete ETSI audit requirements

[Wayne Thayer via dev-security-policy]

I've gone ahead and removed references to ETSI TS 101 456 and TS 102 042
from the 2.6 branch of the policy:
https://github.com/mozilla/pkipolicy/commit/49a07119a1fd5c887d4b506f60e210fad941b26a

- Wayne


On Tue, Mar 27, 2018 at 12:44 PM, Wayne Thayer  wrote:

> There has been a lot of confusion about the transition to the new
> standards, and I believe that this change makes it clearer that Mozilla no
> longer accepts audits based on the older ETSI standards.
>
> On Tue, Mar 27, 2018 at 4:28 AM, Julian Inza via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> European Conformity Assessment Bodies are nowadays issuing Audit
>> Certificates aligned with EN 319 401, EN 319-411-1 and EN 319 411-2
>> standards.
>>
>> There is no need to explicitly deny validity to previous standars,
>> because as Jakob states, they can reflect the chain of audits.
>>
>> In fact, TS 102 042 and TS 101 456 are basically the same standards, but
>> instead of changing only the version number, ETSI opted to renew the full
>> reference code, more in the approach of IETF for RFCs.
>>
>> The Mozilla rule also is aligned with CAB Forum Baseline Requirements for
>> the Issuance and Management of Publicly-Trusted Certificates and Extended
>> Validation SSL Certificate Guidelines, and any change to those documents
>> would need a ballot.
>>
>> This is the kind of confusion that I hope to avoid. Mozilla policy is not
> aligned with the BRs now that Mozilla does not accept TS 102 042 and TS 101
> 456 audits.
>
> Regards,
>>
>> Julian Inza
>>
>>
>>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Policy 2.6 Proposal: Audit requirements for new subCA certificates

[Ben Wilson via dev-security-policy]

That is a distinction without a difference.  If I create a subCA, it’s because 
I want to put it into production soon afterwards. This proposal is going to add 
hours per week that DigiCert is going to have to do, on top of reporting CAs to 
the CCADB, and everything else that CAs have to do.  What is the 
security-critical driver behind this?  Where is the risk-cost-benefit analysis? 
  

 

From: Wayne Thayer [mailto:wtha...@mozilla.com] 
Sent: Thursday, April 5, 2018 1:56 PM
To: Ben Wilson <ben.wil...@digicert.com>
Cc: Dimitris Zacharopoulos <ji...@it.auth.gr>; r...@sleevi.com; 
mozilla-dev-security-policy <mozilla-dev-security-pol...@lists.mozilla.org>
Subject: Re: Policy 2.6 Proposal: Audit requirements for new subCA certificates

 

On Thu, Apr 5, 2018 at 12:05 PM, Ben Wilson <ben.wil...@digicert.com 
<mailto:ben.wil...@digicert.com> > wrote:

If I create a new sub CA on a weekly basis, will that mean that I have to 
republish my CPS every week?  That makes absolutely no sense.

As proposed, the requirement isn't based on when the subCA certificate is 
created - it requires the subCA to be added to the CP/CPS before being used to 
issue certificates. Refer to the following thread for background on this 
proposal: 
https://groups.google.com/d/msg/mozilla.dev.security.policy/CAaC2a2HMiQ/IKimeW4NBgAJ



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: Policy 2.6 Proposal: Audit requirements for new subCA certificates

[Ben Wilson via dev-security-policy]

If I create a new sub CA on a weekly basis, will that mean that I have to 
republish my CPS every week?  That makes absolutely no sense.

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+ben=digicert@lists.mozilla.org] On 
Behalf Of Dimitris Zacharopoulos via dev-security-policy
Sent: Thursday, April 5, 2018 12:56 PM
To: r...@sleevi.com
Cc: mozilla-dev-security-policy 
<mozilla-dev-security-pol...@lists.mozilla.org>; Wayne Thayer 
<wtha...@mozilla.com>
Subject: Re: Policy 2.6 Proposal: Audit requirements for new subCA certificates



On 5/4/2018 9:00 μμ, Ryan Sleevi via dev-security-policy wrote:
> On Thu, Apr 5, 2018 at 5:20 AM, Dimitris Zacharopoulos via 
> dev-security-policy <dev-security-policy@lists.mozilla.org> wrote:
>
>> On 5/4/2018 12:02 πμ, Wayne Thayer via dev-security-policy wrote:
>>
>>> In a recent discussion [1] we decided to clarify the audit 
>>> requirements for new subordinate CA certificates. I’ve  drafted a 
>>> change that requires the new certificate to appear in the next 
>>> periodic audits and in the CP/CPS prior to issuance:
>>>
>>> https://clicktime.symantec.com/a/1/uK18WYwZQOQJdKx7xZlajZuBM8yRGOSgy
>>> j1SoIDpakw=?d=D63GzWzwhoWeyF_kJnBb491EQqEtmVMk515cECZCjkvzPtf4ppGYNv
>>> Y3xQzWed2guj7FppkMjqslzeVCYi9dA46TCVayqu5Tk0o2EDxhFu5cVrwgIwYV6z3Qdy
>>> 4QD_d6ibEP1WuTnxrft1qz_jJTrAoGJKnJvzZI_WgYGagK8hsCodpfgVKRdtZqb9gY-k
>>> TB8J9nzo1Cz2qs2os1GoxF05PH6Gqw6GQZq36x5HPrE3UqPHqcCmYT51fsijJ-RDYREG
>>> k0FuIONxQpg5euehDHMTwSi_uGuf5uGTENRcyA17jb6kKEKLMVVp4CcZqitUybUjyMYX
>>> eVXNvXSEsaCtvNI0riIlcGei3mMVMMhio00v5BPygp0QWx1OEYrsE3lZpMylswo-8Cjt
>>> _Xqg0SNpHK-cPOO0r52NCNO1YxcgDHY9sBQiAVMdb8O4hDZhonN37bP31tHyHFJl8d9c
>>> Isp_BE0uutKBEGOnmgO6cd=https%3A%2F%2Fgithub.com%2Fmozilla%2Fpkipol
>>> icy%2Fcommit%2F09867ef4a0db3b1c
>>> ab162930c0326c84d272ec10
>>>
>>> We also discussed requiring root key generation ceremony (RKGC) 
>>> audit reports, but I have since realized that the BRs (section 
>>> 6.1.1.1) only require these audit reports for new root certificates. 
>>> I’m not convinced that we should begin requiring an auditor’s report 
>>> every time a new subordinate CA certificate is created.
>>>
>>> I would appreciate everyone's comments on this proposed change.
>>>
>>> This is: 
>>> https://clicktime.symantec.com/a/1/H6tO2jUY3sZd2sXgMqg8Ay069QdOne7oi
>>> y4J1W4xQsI=?d=D63GzWzwhoWeyF_kJnBb491EQqEtmVMk515cECZCjkvzPtf4ppGYNv
>>> Y3xQzWed2guj7FppkMjqslzeVCYi9dA46TCVayqu5Tk0o2EDxhFu5cVrwgIwYV6z3Qdy
>>> 4QD_d6ibEP1WuTnxrft1qz_jJTrAoGJKnJvzZI_WgYGagK8hsCodpfgVKRdtZqb9gY-k
>>> TB8J9nzo1Cz2qs2os1GoxF05PH6Gqw6GQZq36x5HPrE3UqPHqcCmYT51fsijJ-RDYREG
>>> k0FuIONxQpg5euehDHMTwSi_uGuf5uGTENRcyA17jb6kKEKLMVVp4CcZqitUybUjyMYX
>>> eVXNvXSEsaCtvNI0riIlcGei3mMVMMhio00v5BPygp0QWx1OEYrsE3lZpMylswo-8Cjt
>>> _Xqg0SNpHK-cPOO0r52NCNO1YxcgDHY9sBQiAVMdb8O4hDZhonN37bP31tHyHFJl8d9c
>>> Isp_BE0uutKBEGOnmgO6cd=https%3A%2F%2Fgithub.com%2Fmozilla%2Fpkipol
>>> icy%2Fissues%2F32
>>>
>>> [1]
>>> https://clicktime.symantec.com/a/1/wkXkHi0pu4wDxDHEw6Kx8SMY_1-Pcpybd
>>> w-Yf2WFJ7M=?d=D63GzWzwhoWeyF_kJnBb491EQqEtmVMk515cECZCjkvzPtf4ppGYNv
>>> Y3xQzWed2guj7FppkMjqslzeVCYi9dA46TCVayqu5Tk0o2EDxhFu5cVrwgIwYV6z3Qdy
>>> 4QD_d6ibEP1WuTnxrft1qz_jJTrAoGJKnJvzZI_WgYGagK8hsCodpfgVKRdtZqb9gY-k
>>> TB8J9nzo1Cz2qs2os1GoxF05PH6Gqw6GQZq36x5HPrE3UqPHqcCmYT51fsijJ-RDYREG
>>> k0FuIONxQpg5euehDHMTwSi_uGuf5uGTENRcyA17jb6kKEKLMVVp4CcZqitUybUjyMYX
>>> eVXNvXSEsaCtvNI0riIlcGei3mMVMMhio00v5BPygp0QWx1OEYrsE3lZpMylswo-8Cjt
>>> _Xqg0SNpHK-cPOO0r52NCNO1YxcgDHY9sBQiAVMdb8O4hDZhonN37bP31tHyHFJl8d9c
>>> Isp_BE0uutKBEGOnmgO6cd=https%3A%2F%2Fgroups.google.com%2Fd%2Fmsg%2
>>> Fmozilla.dev.security.policy%2F
>>> CAaC2a2HMiQ/IKimeW4NBgAJ
>>> ---
>>>
>>> This is a proposed update to Mozilla's root store policy for version 
>>> 2.6. Please keep discussion in this group rather than on GitHub. 
>>> Silence is consent.
>>>
>>> Policy 2.5 (current version):
>>> https://clicktime.symantec.com/a/1/5agl31kcRVdv5wJIFH5-P76QaiWh638Yf
>>> cxtaF8uZWQ=?d=D63GzWzwhoWeyF_kJnBb491EQqEtmVMk515cECZCjkvzPtf4ppGYNv
>>> Y3xQzWed2guj7FppkMjqslzeVCYi9dA46TCVayqu5Tk0o2EDxhFu5cVrwgIwYV6z3Qdy
>>> 4QD_d6ibEP1WuTnxrft1qz_jJTrAoGJKnJvzZI_WgYGagK8hsCodpfgVKRdtZqb9gY-k
>>> TB8J9nzo1Cz2qs2os1GoxF05PH6Gqw6GQZq36x5HPrE3UqPHqcCmYT51fsijJ-RDYREG
>>> k0FuIONxQpg5euehDHMTwSi_uGuf5uGTENRcyA17jb6kKEKLMVVp4CcZqitUybUjyMYX
>>> e

Re: Policy 2.6 Proposal: Audit requirements for new subCA certificates

[Dimitris Zacharopoulos via dev-security-policy]

On 5/4/2018 9:00 μμ, Ryan Sleevi via dev-security-policy wrote:

On Thu, Apr 5, 2018 at 5:20 AM, Dimitris Zacharopoulos via
dev-security-policy <dev-security-policy@lists.mozilla.org> wrote:


On 5/4/2018 12:02 πμ, Wayne Thayer via dev-security-policy wrote:


In a recent discussion [1] we decided to clarify the audit requirements
for
new subordinate CA certificates. I’ve  drafted a change that requires the
new certificate to appear in the next periodic audits and in the CP/CPS
prior to issuance:

https://github.com/mozilla/pkipolicy/commit/09867ef4a0db3b1c
ab162930c0326c84d272ec10

We also discussed requiring root key generation ceremony (RKGC) audit
reports, but I have since realized that the BRs (section 6.1.1.1) only
require these audit reports for new root certificates. I’m not convinced
that we should begin requiring an auditor’s report every time a new
subordinate CA certificate is created.

I would appreciate everyone's comments on this proposed change.

This is: https://github.com/mozilla/pkipolicy/issues/32

[1]
https://groups.google.com/d/msg/mozilla.dev.security.policy/
CAaC2a2HMiQ/IKimeW4NBgAJ
---

This is a proposed update to Mozilla's root store policy for version
2.6. Please keep discussion in this group rather than on GitHub. Silence
is consent.

Policy 2.5 (current version):
https://github.com/mozilla/pkipolicy/blob/2.5/rootstore/policy.md
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy



I will copy the proposed change here for convenience:

"

1. MUST be audited in accordance with Mozilla’s Root Store Policy. If
the subordinate CA has a currently valid audit report at the time of
creation of the certificate, it MUST appear on the subordinate CA's
next periodic audit reports.
2. MUST be publicly disclosed in the CCADB by the CA that has their
certificate included in Mozilla’s root program. The CA with a
certificate included in Mozilla’s root program MUST disclose this
information within a week of certificate creation, and before any
such subordinate CA is allowed to issue certificates. All disclosure
MUST be made freely available and without additional requirements,
including, but not limited to, registration, legal agreements, or
restrictions on redistribution of the certificates in whole or in part.
3. MUST be added to the relevant CP/CPS before issuing certificates.

"

I kind of disagree with 3. The new Subordinate CA Certificate MUST be
added to CCADB (per 2.). It MUST be covered by the audit (per 1.) and show
up in the next report. If a Subordinate CA is operated by the Root
operator, a change in the CP/CPS could probably be just an addition of the
Distinguished Name and a SHA fingerprint. However, CPS changes require
administrative work and several levels of approval which IMHO is not worth
the effort for such an addition. I don't see such a big value for 3.
compared to 1. and 2.


Do you see this as a frequent occurrence such that the overhead of
performing this is greater than the value derived by the community in
having this information?



I will call the specific scenario below "a rollover subCA". I think 
rollover subCAs are issued frequently, several times per year depending 
on the size of the CA and their practices. From 2. the community has 
this information so it seems redundant.



Consider the case where you have a Subordinate CA Certificate that you
need to update because you want to change the hashing algorithm (SHA1 -->
SHA256), or change the key size, or renew. This would lead to a new subCA
Certificate with CN "My Subordinate CA Certificate R2",  "My Subordinate CA
Certificate R3" and so on. The controls would be exactly the same as the
previous subCA Certificate.


Except how does the community know and verify that those controls are the
same? How does the community know and verify if those controls change (e.g.
the subordinate CA is immediately sold to a third-party and/or transferred
to them)



I understand the concern, so why don't we write policy language to 
address this concern rather than making it so broad and cause 
administrative overhead for not so much value compared to the other 
points? What you're describing looks like a rare case. Something along 
the lines of "If a new Subordinate CA Certificate is issued and not 
included in the currently published CP/CPS, it must be maintained by the 
Root CA Operator and must appear in the next audit report" might address 
this concern.



The 3rd requirement might make more sense for externally operated
Subordinate CAs. According to BRs 6.1.1.1, Key Pairs that are generated for
SubCAs not to be used by the Root CA operator or an Affiliate (meaning an
externally operated Subordinate CA), MUST be witnessed by a Qualified
Auditor (or record the ceremony and get an opinion let

Re: Policy 2.6 Proposal: Audit requirements for new subCA certificates

[Ryan Sleevi via dev-security-policy]

On Thu, Apr 5, 2018 at 5:20 AM, Dimitris Zacharopoulos via
dev-security-policy <dev-security-policy@lists.mozilla.org> wrote:

> On 5/4/2018 12:02 πμ, Wayne Thayer via dev-security-policy wrote:
>
>> In a recent discussion [1] we decided to clarify the audit requirements
>> for
>> new subordinate CA certificates. I’ve  drafted a change that requires the
>> new certificate to appear in the next periodic audits and in the CP/CPS
>> prior to issuance:
>>
>> https://github.com/mozilla/pkipolicy/commit/09867ef4a0db3b1c
>> ab162930c0326c84d272ec10
>>
>> We also discussed requiring root key generation ceremony (RKGC) audit
>> reports, but I have since realized that the BRs (section 6.1.1.1) only
>> require these audit reports for new root certificates. I’m not convinced
>> that we should begin requiring an auditor’s report every time a new
>> subordinate CA certificate is created.
>>
>> I would appreciate everyone's comments on this proposed change.
>>
>> This is: https://github.com/mozilla/pkipolicy/issues/32
>>
>> [1]
>> https://groups.google.com/d/msg/mozilla.dev.security.policy/
>> CAaC2a2HMiQ/IKimeW4NBgAJ
>> ---
>>
>> This is a proposed update to Mozilla's root store policy for version
>> 2.6. Please keep discussion in this group rather than on GitHub. Silence
>> is consent.
>>
>> Policy 2.5 (current version):
>> https://github.com/mozilla/pkipolicy/blob/2.5/rootstore/policy.md
>> ___
>> dev-security-policy mailing list
>> dev-security-policy@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-security-policy
>>
>>
> I will copy the proposed change here for convenience:
>
> "
>
> 1. MUST be audited in accordance with Mozilla’s Root Store Policy. If
>the subordinate CA has a currently valid audit report at the time of
>creation of the certificate, it MUST appear on the subordinate CA's
>next periodic audit reports.
> 2. MUST be publicly disclosed in the CCADB by the CA that has their
>certificate included in Mozilla’s root program. The CA with a
>certificate included in Mozilla’s root program MUST disclose this
>information within a week of certificate creation, and before any
>such subordinate CA is allowed to issue certificates. All disclosure
>MUST be made freely available and without additional requirements,
>including, but not limited to, registration, legal agreements, or
>restrictions on redistribution of the certificates in whole or in part.
> 3. MUST be added to the relevant CP/CPS before issuing certificates.
>
> "
>
> I kind of disagree with 3. The new Subordinate CA Certificate MUST be
> added to CCADB (per 2.). It MUST be covered by the audit (per 1.) and show
> up in the next report. If a Subordinate CA is operated by the Root
> operator, a change in the CP/CPS could probably be just an addition of the
> Distinguished Name and a SHA fingerprint. However, CPS changes require
> administrative work and several levels of approval which IMHO is not worth
> the effort for such an addition. I don't see such a big value for 3.
> compared to 1. and 2.
>

Do you see this as a frequent occurrence such that the overhead of
performing this is greater than the value derived by the community in
having this information?


> Consider the case where you have a Subordinate CA Certificate that you
> need to update because you want to change the hashing algorithm (SHA1 -->
> SHA256), or change the key size, or renew. This would lead to a new subCA
> Certificate with CN "My Subordinate CA Certificate R2",  "My Subordinate CA
> Certificate R3" and so on. The controls would be exactly the same as the
> previous subCA Certificate.
>

Except how does the community know and verify that those controls are the
same? How does the community know and verify if those controls change (e.g.
the subordinate CA is immediately sold to a third-party and/or transferred
to them)


> The 3rd requirement might make more sense for externally operated
> Subordinate CAs. According to BRs 6.1.1.1, Key Pairs that are generated for
> SubCAs not to be used by the Root CA operator or an Affiliate (meaning an
> externally operated Subordinate CA), MUST be witnessed by a Qualified
> Auditor (or record the ceremony and get an opinion letter afterwards). It
> seems that the BRs require some special treatment when a SubCA Key Pair is
> generated for an externally operated entity. Is it worth the effort to
> reflect a similar distinction in the Mozilla Policy?
>

That covers the key generation - but if the subCA is first generated for
the CA, and then later transferred to a third-party - which is something
that has happened - it's a loophole in both policies and practices.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Policy 2.6 Proposal: Audit requirements for new subCA certificates

[Wayne Thayer via dev-security-policy]

In a recent discussion [1] we decided to clarify the audit requirements for
new subordinate CA certificates. I’ve  drafted a change that requires the
new certificate to appear in the next periodic audits and in the CP/CPS
prior to issuance:

https://github.com/mozilla/pkipolicy/commit/09867ef4a0db3b1cab162930c0326c84d272ec10

We also discussed requiring root key generation ceremony (RKGC) audit
reports, but I have since realized that the BRs (section 6.1.1.1) only
require these audit reports for new root certificates. I’m not convinced
that we should begin requiring an auditor’s report every time a new
subordinate CA certificate is created.

I would appreciate everyone's comments on this proposed change.

This is: https://github.com/mozilla/pkipolicy/issues/32

[1]
https://groups.google.com/d/msg/mozilla.dev.security.policy/CAaC2a2HMiQ/IKimeW4NBgAJ
---

This is a proposed update to Mozilla's root store policy for version
2.6. Please keep discussion in this group rather than on GitHub. Silence
is consent.

Policy 2.5 (current version):
https://github.com/mozilla/pkipolicy/blob/2.5/rootstore/policy.md
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.6 Proposal: Remove obsolete ETSI audit requirements

[Wayne Thayer via dev-security-policy]

There has been a lot of confusion about the transition to the new
standards, and I believe that this change makes it clearer that Mozilla no
longer accepts audits based on the older ETSI standards.

On Tue, Mar 27, 2018 at 4:28 AM, Julian Inza via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> European Conformity Assessment Bodies are nowadays issuing Audit
> Certificates aligned with EN 319 401, EN 319-411-1 and EN 319 411-2
> standards.
>
> There is no need to explicitly deny validity to previous standars, because
> as Jakob states, they can reflect the chain of audits.
>
> In fact, TS 102 042 and TS 101 456 are basically the same standards, but
> instead of changing only the version number, ETSI opted to renew the full
> reference code, more in the approach of IETF for RFCs.
>
> The Mozilla rule also is aligned with CAB Forum Baseline Requirements for
> the Issuance and Management of Publicly-Trusted Certificates and Extended
> Validation SSL Certificate Guidelines, and any change to those documents
> would need a ballot.
>
> This is the kind of confusion that I hope to avoid. Mozilla policy is not
aligned with the BRs now that Mozilla does not accept TS 102 042 and TS 101
456 audits.

Regards,
>
> Julian Inza
>
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.6 Proposal: Remove obsolete ETSI audit requirements

[Ryan Sleevi via dev-security-policy]

I support this change. Previously accepted audits are covered by previously
accepted policies, so there's no issue since there should be no new audits
going forward using these criteria, much in the same way all new, valid
WebTrust audits are using the new criteria.

On Mon, Mar 26, 2018 at 4:41 PM, Wayne Thayer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Mozilla policy section 3.1.2.2 states:
>
> ETSI TS 102 042 and TS 101 456 audits are only acceptable for audit periods
> > ending in July 2017 or earlier.
> >
>
> Now that we are past this deadline, I propose that we remove all references
> to ETSI TS 102 042 and 101 456 from the policy.
>
> This is: https://github.com/mozilla/pkipolicy/issues/108
>
> ---
>
> This is a proposed update to Mozilla's root store policy for version
> 2.6. Please keep discussion in this group rather than on GitHub. Silence
> is consent.
>
> Policy 2.5 (current version):
> https://github.com/mozilla/pkipolicy/blob/2.5/rootstore/policy.md
> ___
> 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.6 Proposal: Remove obsolete ETSI audit requirements

[Julian Inza via dev-security-policy]

European Conformity Assessment Bodies are nowadays issuing Audit Certificates 
aligned with EN 319 401, EN 319-411-1 and EN 319 411-2 standards.

There is no need to explicitly deny validity to previous standars, because as 
Jakob states, they can reflect the chain of audits.

In fact, TS 102 042 and TS 101 456 are basically the same standards, but 
instead of changing only the version number, ETSI opted to renew the full 
reference code, more in the approach of IETF for RFCs.

The Mozilla rule also is aligned with CAB Forum Baseline Requirements for the 
Issuance and Management of Publicly-Trusted Certificates and Extended 
Validation SSL Certificate Guidelines, and any change to those documents would 
need a ballot.

Regards,

Julian Inza

 El martes, 27 de marzo de 2018, 8:43:31 (UTC+2), Jakob Bohm  escribió:
> On 26/03/2018 22:41, Wayne Thayer wrote:
> > Mozilla policy section 3.1.2.2 states:
> > 
> > ETSI TS 102 042 and TS 101 456 audits are only acceptable for audit periods
> >> ending in July 2017 or earlier.
> >>
> > 
> > Now that we are past this deadline, I propose that we remove all references
> > to ETSI TS 102 042 and 101 456 from the policy.
> > 
> > This is: https://github.com/mozilla/pkipolicy/issues/108
> > 
> > ---
> > 
> > This is a proposed update to Mozilla's root store policy for version
> > 2.6. Please keep discussion in this group rather than on GitHub. Silence
> > is consent.
> > 
> > Policy 2.5 (current version):
> > https://github.com/mozilla/pkipolicy/blob/2.5/rootstore/policy.md
> > 
> 
> Will that make such audits (prior to the deadline) unacceptable as part
> of the unbroken audit chain back to first issuance for new roots?
> 
> Enjoy
> 
> Jakob
> -- 
> Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
> Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
> This public discussion message is non-binding and may contain errors.
> WiseMo - Remote Service Management for PCs, Phones and Embedded

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

Re: Policy 2.6 Proposal: Remove obsolete ETSI audit requirements

[Jakob Bohm via dev-security-policy]

On 26/03/2018 22:41, Wayne Thayer wrote:

Mozilla policy section 3.1.2.2 states:

ETSI TS 102 042 and TS 101 456 audits are only acceptable for audit periods

ending in July 2017 or earlier.



Now that we are past this deadline, I propose that we remove all references
to ETSI TS 102 042 and 101 456 from the policy.

This is: https://github.com/mozilla/pkipolicy/issues/108

---

This is a proposed update to Mozilla's root store policy for version
2.6. Please keep discussion in this group rather than on GitHub. Silence
is consent.

Policy 2.5 (current version):
https://github.com/mozilla/pkipolicy/blob/2.5/rootstore/policy.md



Will that make such audits (prior to the deadline) unacceptable as part
of the unbroken audit chain back to first issuance for new roots?

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Policy 2.6 Proposal: Remove obsolete ETSI audit requirements

[Wayne Thayer via dev-security-policy]

Mozilla policy section 3.1.2.2 states:

ETSI TS 102 042 and TS 101 456 audits are only acceptable for audit periods
> ending in July 2017 or earlier.
>

Now that we are past this deadline, I propose that we remove all references
to ETSI TS 102 042 and 101 456 from the policy.

This is: https://github.com/mozilla/pkipolicy/issues/108

---

This is a proposed update to Mozilla's root store policy for version
2.6. Please keep discussion in this group rather than on GitHub. Silence
is consent.

Policy 2.5 (current version):
https://github.com/mozilla/pkipolicy/blob/2.5/rootstore/policy.md
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Audit requirements

[Varga Viktor]

Dear Erwann,

My answers inline marked with ***

Le jeudi 29 septembre 2016 11:45:39 UTC+2, Varga Viktor a écrit :
> Dear Peter,
> 
> I am deeply in ETSI process, so I can give info some info:
> 
> Formerly the ETSIs are based on
> 
> *102042 for CAs
> *101456 for CAs issuing qualified certificates (refernces frequently 
> the 102042)
> 
> o   BRG and EV is referenced from them for SSL and EV SSL certificate 
> issuance.
> 
> The new version of these : (2016-02) (these are based on the 910/2014/EC 
> regulation, which makes a common EU market.)
> 
> *319411-1 for CAs
> *319412-2 for CAs issuing qualified certificates (refernces 
> frequently the 319411-1)

You meant 319411-2 here. (319412-* are certificate profiles).

*** You have right, it was misstyped.

> o   319401 is referenced from them for technical requirements (technical 
> requirements from 102042 and 101456 were ripped of into this documents)
> 
> o   319412-1 ,-2, -3, -4, -5 referenced from them for certificate profiles
> o   BRG and EV is referenced from them for SSL and EV SSL certificate 
> issuance.

319412-2 and 319412-3 are not used for TLS server certificates, 319412-1 is 
general and introduces some semantic identifiers that could be used in TLS 
server certs, 319412-4 is dedicated to TLS server certificates but is mostly an 
empty shell relying on EVG and BR, 319412-5 adds the QCStatements extension 
(MUST be present for Qualified certs, MAY be present for non Qualified certs).

> For EU CAs the Microsoft forces to move to ETSI audit instead Webtrust.

No.

*** I accept your correction. I correct myself.
I remember I read it somewhere, but can't find my source again.
(Maybe I read it in a work version left on the net.)



> The ETSI audit checks:
> 
> *that the certificate issuance systems and environment are compliant 
> with the technical or requirements. (against 319401)
> *that the certificate profiles meet the requirements (against 319412s)
> *the CP/CPS and the practice of issuance compliant with the 319411-1 
> (and for qualified certificates with 319411-2)
> 
> o   the 319411-1 and 319411-2 defines various Certification policies, and 
> rules for them.
> 
> LCP, NCP, NCP+, DVCP, IVCP, OVCP, EVCP, and also the new qualified ones 
> (qcp-n, qpc-l, qcp-n-qscd, qcp-l-qscd, qcp-w)
> 
> For DVCP, OVCP, IVCP, OVCP they references BRG and EVGL (and also for qcp-w, 
> which looks like a chimera for me :) )
> 
> At the end of audit each issuing subcas are checked against the compliance 
> with issuing policies, profiles, and technical requirements.
> 
> Of-course the ETSI report, or its Annex also includes the whole list of the 
> subordinates too.
> 
> Also the Microsoft doesn't accepts audit report without the subordinate list, 
> so its mandatory nowadays.
> 
> I think what is important to add the 319411-1 and -2 to the actual acceptable 
> audit requirements, because the MS ask for this, and it older version (119411 
> included in the 2.3 proposal)

My view is that 319411-2 may be an acceptable audit requirements, but since 
QCP-w certificates (the chimera) are not easily compared to EV certificates 
(because the "Qualified" attribute is granted by a supervisory body to a TSP 
established on its territory only), it's useless to add 319411-2 as acceptable 
(a CA will necessarily be 319411-1).

***  It's also a possible solution to left the 411-2 out, because 411-1 covers 
also the LCP, NCP, NCP+ signer and ecnryption certificates too, so SMIME usage 
is also covered. What I just want to recommend to add also the new numbers to 
the current Mozilla Policy.

Regards, Viktor Varga
 
___
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: Audit requirements

[Erwann Abalea]

Bonjour,

Le jeudi 29 septembre 2016 11:45:39 UTC+2, Varga Viktor a écrit :
> Dear Peter,
> 
> I am deeply in ETSI process, so I can give info some info:
> 
> Formerly the ETSIs are based on
> 
> *102042 for CAs
> *101456 for CAs issuing qualified certificates (refernces frequently 
> the 102042)
> 
> o   BRG and EV is referenced from them for SSL and EV SSL certificate 
> issuance.
> 
> The new version of these : (2016-02) (these are based on the 910/2014/EC 
> regulation, which makes a common EU market.)
> 
> *319411-1 for CAs
> *319412-2 for CAs issuing qualified certificates (refernces 
> frequently the 319411-1)

You meant 319411-2 here. (319412-* are certificate profiles).

> o   319401 is referenced from them for technical requirements (technical 
> requirements from 102042 and 101456 were ripped of into this documents)
> 
> o   319412-1 ,-2, -3, -4, -5 referenced from them for certificate profiles
> o   BRG and EV is referenced from them for SSL and EV SSL certificate 
> issuance.

319412-2 and 319412-3 are not used for TLS server certificates, 319412-1 is 
general and introduces some semantic identifiers that could be used in TLS 
server certs, 319412-4 is dedicated to TLS server certificates but is mostly an 
empty shell relying on EVG and BR, 319412-5 adds the QCStatements extension 
(MUST be present for Qualified certs, MAY be present for non Qualified certs).

> For EU CAs the Microsoft forces to move to ETSI audit instead Webtrust.

No.

> The ETSI audit checks:
> 
> *that the certificate issuance systems and environment are compliant 
> with the technical or requirements. (against 319401)
> *that the certificate profiles meet the requirements (against 319412s)
> *the CP/CPS and the practice of issuance compliant with the 319411-1 
> (and for qualified certificates with 319411-2)
> 
> o   the 319411-1 and 319411-2 defines various Certification policies, and 
> rules for them.
> 
> LCP, NCP, NCP+, DVCP, IVCP, OVCP, EVCP, and also the new qualified ones 
> (qcp-n, qpc-l, qcp-n-qscd, qcp-l-qscd, qcp-w)
> 
> For DVCP, OVCP, IVCP, OVCP they references BRG and EVGL (and also for qcp-w, 
> which looks like a chimera for me :) )
> 
> At the end of audit each issuing subcas are checked against the compliance 
> with issuing policies, profiles, and technical requirements.
> 
> Of-course the ETSI report, or its Annex also includes the whole list of the 
> subordinates too.
> 
> Also the Microsoft doesn't accepts audit report without the subordinate list, 
> so its mandatory nowadays.
> 
> I think what is important to add the 319411-1 and -2 to the actual acceptable 
> audit requirements, because the MS ask for this, and it older version (119411 
> included in the 2.3 proposal)

My view is that 319411-2 may be an acceptable audit requirements, but since 
QCP-w certificates (the chimera) are not easily compared to EV certificates 
(because the "Qualified" attribute is granted by a supervisory body to a TSP 
established on its territory only), it's useless to add 319411-2 as acceptable 
(a CA will necessarily be 319411-1).
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Audit requirements

[Varga Viktor]

Dear Peter,



I am deeply in ETSI process, so I can give info some info:



Formerly the ETSIs are based on

*102042 for CAs

*101456 for CAs issuing qualified certificates (refernces frequently 
the 102042)

o   BRG and EV is referenced from them for SSL and EV SSL certificate issuance.



The new version of these : (2016-02) (these are based on the 910/2014/EC 
regulation, which makes a common EU market.)

*319411-1 for CAs

*319412-2 for CAs issuing qualified certificates (refernces frequently 
the 319411-1)

o   319401 is referenced from them for technical requirements (technical 
requirements from 102042 and 101456 were ripped of into this documents)

o   319412-1 ,-2, -3, -4, -5 referenced from them for certificate profiles

o   BRG and EV is referenced from them for SSL and EV SSL certificate issuance.



For EU CAs the Microsoft forces to move to ETSI audit instead Webtrust.



The ETSI audit checks:

*that the certificate issuance systems and environment are compliant 
with the technical or requirements. (against 319401)

*that the certificate profiles meet the requirements (against 319412s)

*the CP/CPS and the practice of issuance compliant with the 319411-1 
(and for qualified certificates with 319411-2)

o   the 319411-1 and 319411-2 defines various Certification policies, and rules 
for them.

LCP, NCP, NCP+, DVCP, IVCP, OVCP, EVCP, and also the new qualified ones (qcp-n, 
qpc-l, qcp-n-qscd, qcp-l-qscd, qcp-w)

For DVCP, OVCP, IVCP, OVCP they references BRG and EVGL (and also for qcp-w, 
which looks like a chimera for me :) )



At the end of audit each issuing subcas are checked against the compliance with 
issuing policies, profiles, and technical requirements.

Of-course the ETSI report, or its Annex also includes the whole list of the 
subordinates too.

Also the Microsoft doesn't accepts audit report without the subordinate list, 
so its mandatory nowadays.



I think what is important to add the 319411-1 and -2 to the actual acceptable 
audit requirements, because the MS ask for this, and it older version (119411 
included in the 2.3 proposal)



At october I would like to upload our new audit reports to Salesforce, which 
are made aganst the 319411-s.

üdvözlettel //sincerelly yours,
Viktor Varga
Netlock
chief architect











-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+varga.viktor=netlock...@lists.mozilla.org] 
On Behalf Of Peter Bowen
Sent: Friday, September 23, 2016 12:57 AM
To: mozilla-dev-security-pol...@lists.mozilla.org 
<dev-security-policy@lists.mozilla.org>
Subject: Audit requirements



Kathleen, Gerv, Richard and m.d.s.p,



In reviewing the WebTrust audit documentation submitted by various CA program 
members and organizations wishing to be members, it seems there is possibly 
some confusion on what is required by Mozilla.  I suspect this might also span 
to ETSI audit documentation, but I don't know the ETSI process as well, so will 
leave it to some else to determine if there is confusion there.



The first part of the confusion comes from the scope of the audit.

When engaging an auditor to provide attestion services, it is up to the 
organization to define the scope of the audit.  For audits utilizing the 
WebTrust criteria, the scope could be all parts of the criteria.  According to 
auditors I have spoken with, the report will indicate which portions of the 
criteria were in scope for the audit by including a statement of items in scope 
on the management assertion.

If the assertion does not include an item, or the auditor does not express an 
opinion about the item, then it should be assumed to be out of scope.



I have seen a number of reports that do not include all of the criteria be in 
scope.  Specifically, many reports do not provide an opinion on criteria 7 
("Subordinate CA Certificate Life Cycle

Management") of the Trust Services and Principles and Criteria for 
Certification Authorities.  Given the emphasis on subordinate CAs in the 
Mozilla policy, it would seem that this should be required for any CA which 
does not the zero path length constraint.  The current inclusion policy item 11 
presumably includes this already, but does not specifically state that all 
parts of the listed criteria must be included.



The second item of confusion seems to be which CA certificate subjects must be 
audited.  A number of CAs only include the subjects of CA certificates directly 
included in the Mozilla products and do not include the subjects of subordinate 
CA certificates.  My impression is that there should be a report clearly 
covering each of subject of a unconstrained CA certificate in the heirarchy, as 
described in item 8 of the inclusion policy.  This includes a Baseline 
Requirements report for any unconstrained CA, even if the CA is not intended to 
be used for server authentication ("SSL") certificates.



What is 

Re: Audit requirements

[Myers, Kenneth (10421)]

I think it has also been discussed of the consistency between WebTrust 
auditors. The WebTrust for CA use of criteria and illustrative controls may 
leave to much room for interpretation by an auditor. There is also the 
potential gap between the WebTrust licensed firm and the individual auditors 
which again leaves room that the firm is properly training its auditors in how 
to conduct/understanding of PKI operations.

The US Federal PKI has created its own criteria that relies on a direct 
CP-to-CPS analysis. An FPKI affiliate may use any audit standard as long as it 
includes an addendum that a CP-to-CPS analysis was conducted along with annual 
core requirements. WebTrust has recognized this additional requirement as part 
of their Certification Compliance Matrix.

If anyone is interested, FPKI Compliance Audit Requirements can be found here 
https://www.idmanagement.gov/IDM/s/article_detail?link=fpki-audit-info
NOTICE: Protiviti is a global consulting and internal audit firm composed of 
experts specializing in risk and advisory services. Protiviti is not licensed 
or registered as a public accounting firm and does not issue opinions on 
financial statements or offer attestation services. This electronic mail 
message is intended exclusively for the individual or entity to which it is 
addressed. This message, together with any attachment, may contain confidential 
and privileged information. Any views, opinions or conclusions expressed in 
this message are those of the individual sender and do not necessarily reflect 
the views of Protiviti Inc. or its affiliates. Any unauthorized review, use, 
printing, copying, retention, disclosure or distribution is strictly 
prohibited. If you have received this message in error, please immediately 
advise the sender by reply email message to the sender and delete all copies of 
this message. Thank you.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Audit requirements

[Ben Wilson]

What about subordinate CAs created after the audit letter is published?  If
both WebTrust and ETSI audit schemes assume ongoing audit reporting
responsibilities, I'd assume that  you  wouldn't need a new audit letter
every time you create a subordinate CA, which might be weekly.  The list of
subordinate CAs could be updated annually, I'd think.

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+ben=digicert@lists.mozilla.org] On
Behalf Of Peter Bowen
Sent: Friday, September 23, 2016 9:18 AM
To: Kurt Roeckx <k...@roeckx.be>
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Audit requirements

On Fri, Sep 23, 2016 at 5:29 AM, Kurt Roeckx <k...@roeckx.be> wrote:
> On 2016-09-23 00:57, Peter Bowen wrote:
>>
>> Kathleen, Gerv, Richard and m.d.s.p,
>>
>> In reviewing the WebTrust audit documentation submitted by various CA 
>> program members and organizations wishing to be members, it seems 
>> there is possibly some confusion on what is required by Mozilla.  I 
>> suspect this might also span to ETSI audit documentation, but I don't 
>> know the ETSI process as well, so will leave it to some else to 
>> determine if there is confusion there.
>
>
> So at least 1 thing I miss in those audit reports is which CAs are
covered.
> If you look at the CAs they disclosed, how can we be sure that the 
> audit actually covers that CA? I think the report should cover at 
> least all root and intermediate CAs that are required to be disclosed by
Mozilla.

And many audit reports specify this.  See the following examples from the
Mozilla included CAs report.  I didn't check all -- I'm sure many more have
lists of in scope CAs.

https://cert.webtrust.org/SealFile?seal=2032=pdf (in the first
paragraph lists the CAs)
https://cert.webtrust.org/SealFile?seal=1998=pdf (first paragraph lists
the CA, appendix listing the CA details)
https://www.certsign.ro/certsign_en/files/certSIGN_Webtrust_CA.pdf
(bulleted list of CAs)
https://cert.webtrust.org/SealFile?seal=2092=pdf (first paragraph)
https://cert.webtrust.org/SealFile?seal=1944=pdf (Appendix listing CA
details) https://cert.webtrust.org/SealFile?seal=1568=pdf (Appendix
listing CAs)

So for many reports you don't have to guess which are covered.

Thanks,
Peter
___
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: Audit requirements

[Peter Bowen]

On Fri, Sep 23, 2016 at 5:29 AM, Kurt Roeckx  wrote:
> On 2016-09-23 00:57, Peter Bowen wrote:
>>
>> Kathleen, Gerv, Richard and m.d.s.p,
>>
>> In reviewing the WebTrust audit documentation submitted by various CA
>> program members and organizations wishing to be members, it seems
>> there is possibly some confusion on what is required by Mozilla.  I
>> suspect this might also span to ETSI audit documentation, but I don't
>> know the ETSI process as well, so will leave it to some else to
>> determine if there is confusion there.
>
>
> So at least 1 thing I miss in those audit reports is which CAs are covered.
> If you look at the CAs they disclosed, how can we be sure that the audit
> actually covers that CA? I think the report should cover at least all root
> and intermediate CAs that are required to be disclosed by Mozilla.

And many audit reports specify this.  See the following examples from
the Mozilla included CAs report.  I didn't check all -- I'm sure many
more have lists of in scope CAs.

https://cert.webtrust.org/SealFile?seal=2032=pdf (in the first
paragraph lists the CAs)
https://cert.webtrust.org/SealFile?seal=1998=pdf (first paragraph
lists the CA, appendix listing the CA details)
https://www.certsign.ro/certsign_en/files/certSIGN_Webtrust_CA.pdf
(bulleted list of CAs)
https://cert.webtrust.org/SealFile?seal=2092=pdf (first paragraph)
https://cert.webtrust.org/SealFile?seal=1944=pdf (Appendix
listing CA details)
https://cert.webtrust.org/SealFile?seal=1568=pdf (Appendix listing CAs)

So for many reports you don't have to guess which are covered.

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

Re: Audit requirements

[Jakob Bohm]

On 23/09/2016 14:29, Kurt Roeckx wrote:

On 2016-09-23 00:57, Peter Bowen wrote:

Kathleen, Gerv, Richard and m.d.s.p,

In reviewing the WebTrust audit documentation submitted by various CA
program members and organizations wishing to be members, it seems
there is possibly some confusion on what is required by Mozilla.  I
suspect this might also span to ETSI audit documentation, but I don't
know the ETSI process as well, so will leave it to some else to
determine if there is confusion there.


So at least 1 thing I miss in those audit reports is which CAs are
covered. If you look at the CAs they disclosed, how can we be sure that
the audit actually covers that CA? I think the report should cover at
least all root and intermediate CAs that are required to be disclosed by
Mozilla.



Except those that are covered by separate Audit reports (also
submitted).  Examples would include cross-signed copies of other root
CAs (which already submit audit reports), as well as CAs covered by
submitted audit reports of other parts of the same CA organization (for
example, StartCOM might be cross-signed by WoSign but audited
separately, and the WoSign EV SubCA is audited separately under
stricter rules).

For such certificates it would be enough for the parent CA audit report
to list them and state that separate audit reports should be checked
for those (the auditor of the parent CA audit report may not know the
outcome of the the subCA audit when issuing his report on the parent
CA).  Of cause the audit of the parent CA should still audit the
controls that prevent issuing SubCA certificates that are unlikely to
be compliant, regardless if those controls are "we only sign our own 
in-house SubCAs using a multi-person signing ceremony" or "we sign any
SubCA that pays a fee and passes a full BR audit by Ernst, Young or 
Deloite".



Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Audit requirements

[Peter Bowen]

Kathleen, Gerv, Richard and m.d.s.p,

In reviewing the WebTrust audit documentation submitted by various CA
program members and organizations wishing to be members, it seems
there is possibly some confusion on what is required by Mozilla.  I
suspect this might also span to ETSI audit documentation, but I don't
know the ETSI process as well, so will leave it to some else to
determine if there is confusion there.

The first part of the confusion comes from the scope of the audit.
When engaging an auditor to provide attestion services, it is up to
the organization to define the scope of the audit.  For audits
utilizing the WebTrust criteria, the scope could be all parts of the
criteria.  According to auditors I have spoken with, the report will
indicate which portions of the criteria were in scope for the audit by
including a statement of items in scope on the management assertion.
If the assertion does not include an item, or the auditor does not
express an opinion about the item, then it should be assumed to be out
of scope.

I have seen a number of reports that do not include all of the
criteria be in scope.  Specifically, many reports do not provide an
opinion on criteria 7 ("Subordinate CA Certificate Life Cycle
Management") of the Trust Services and Principles and Criteria for
Certification Authorities.  Given the emphasis on subordinate CAs in
the Mozilla policy, it would seem that this should be required for any
CA which does not the zero path length constraint.  The current
inclusion policy item 11 presumably includes this already, but does
not specifically state that all parts of the listed criteria must be
included.

The second item of confusion seems to be which CA certificate subjects
must be audited.  A number of CAs only include the subjects of CA
certificates directly included in the Mozilla products and do not
include the subjects of subordinate CA certificates.  My impression is
that there should be a report clearly covering each of subject of a
unconstrained CA certificate in the heirarchy, as described in item 8
of the inclusion policy.  This includes a Baseline Requirements report
for any unconstrained CA, even if the CA is not intended to be used
for server authentication ("SSL") certificates.

What is Mozilla's expectation?  Do CAs need to ensure that all
components of the criteria are included in their report and ensure
that all unconstrained subordinates are identified as being covered by
the reports?

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