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

2018-04-23 Thread 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  wrote:

> On Wed, Apr 11, 2018 at 3:49 PM, Wayne Thayer  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

2018-04-16 Thread Wayne Thayer via dev-security-policy 
On Wed, Apr 11, 2018 at 3:49 PM, Wayne Thayer  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

2018-04-11 Thread 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: Audit requirements for new subCA certificates

2018-04-05 Thread 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

2018-04-05 Thread 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

2018-04-05 Thread 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  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 letter afterwards). It
seems that the BRs require some special

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

2018-04-05 Thread Ryan Sleevi via dev-security-policy 
On Thu, Apr 5, 2018 at 5:20 AM, Dimitris Zacharopoulos via
dev-security-policy  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

2018-04-04 Thread 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