info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
RE: Root Store Policy 2.5: Call For Review and Phase-In Periods
245 views
Skip to first unread message
Doug Beattie
Jun 20, 2017, 10:32:20 AM6/20/17
to Gervase Markham, mozilla-dev-s...@lists.mozilla.org
H Gerv,
I'd like to recommend a phase in of the requirement for technically constrained CAs that issue Secure email certificates.
We have 2 customers that can issue Secure Email certificates that are not technically constrained with name Constraints (the EKU is constrained to Secure Email and ClientAuth).
We'd like to propose:
- All new CAs shall comply with Policy 2.5 on its effective date
- All existing CAs can continue to operate in issuance mode for one year
- All existing CAs may continue to operate in maintenance mode to support revocation services for up to 1 additional year (allow all 1-year certificates to expire), then the CA must be revoked.
One customer operates the CA within their environment and has been doing so for several years. Even though we've been encouraging them to move back to a Name Constrained CA or a hosted service, we've been unable to set firm plans in place without a Root program deadline we can reference. Due to the nature of the company and their acquisitions, they need to keep supporting new domains so name constraints is difficult to keep up with.
The other customer complies the prior words in the Mozilla policy regarding "Business Controls". We have an agreement with them where we issue them Secure Email certificates from our Infrastructure for domains they host and are contractually bound to using those certificates only for the matching mail account. Due to the number of different domains managed and fact they obtain certificates on behalf of the users, it's difficult to enforce validation of the email address. We have plans to add features to this issuance platform that will resolve this, but not in the near term.
Doug
> -----Original Message-----
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+doug.beattie=globals...@lists.mozilla.org] On Behalf Of
> Gervase Markham via dev-security-policy
> Sent: Thursday, June 8, 2017 11:43 AM
> To: mozilla-dev-s...@lists.mozilla.org
> Subject: Root Store Policy 2.5: Call For Review and Phase-In Periods
>
> Hi everyone,
>
> I've made the last change I currently intend to make for version 2.5 of
> Mozilla's Root Store Policy. The last task before shipping it is to assess
> whether any of the changes require a phase-in period, i.e. for some reason,
> they can't be applicable immediately.
>
> CAs and others are requested to comment, with rationale, as to why
> particular changes will need a phase-in period and what period they are
> proposing as appropriate. This is also an opportunity for interested parties to
> do a general final review.
>
> I hope to ship the policy immediately after the CAB Forum meeting in Berlin,
> which is happening from the 20th to the 22nd of June.
>
> You can see the differences between version 2.4.1 and version 2.5 here in
> diff format (click "Files Changed" and then "Load Diff"):
> https://github.com/mozilla/pkipolicy/compare/2.4.1...master
>
> or here in a more rich format:
> https://github.com/mozilla/pkipolicy/compare/2.4.1...master?short_path=b
> 7447c8
> (click "Files Changed" and scroll down).
>
> The CCADB Policy changes are trivial and can be ignored.
>
> Here is my summary of what's changed that's significant (with section
> numbers in brackets), although you should not rely on it to be complete:
>
>
> 1) Certificates with anyEKU have been added to the scope. (1.1)
>
> 2) CAs are required to "follow industry best practice for securing their
> networks, for example by conforming to the CAB Forum Network Security
> Guidelines or a successor document". (2.1)
>
> 3) Accounts which perform "Registration Authority or Delegated Third Party
> functions" are now also required to have multi-factor auth. (2.1)
>
> 4) CAs are required to follow, but not required to contribute to,
> mozilla.dev.security.policy. (2.1)
>
> 5) CAs are required to use only the 10 Blessed Methods for domain
> validation. (2.2) This requirement has already had a deadline set for it in the
> most recent CA Communication; that deadline is 21st July 2017.
>
> 6) WebTrust BR audits must now use version 2.2 or later of the audit criteria.
> (3.1.1)
>
> 7) The ETSI audit criteria requirements have been updated to be accurate.
> (3.1.2.2). ETSI TS 102 042 and TS 101 456 audits will only be accepted for
> audit periods ending in July 2017 or earlier.
>
> 8) There are further requirements on the information that needs to be
> contained in publicly-available audit information. (3.1.3)
>
> 9) Mozilla now requires that auditors be qualified in the scheme they are
> using, unless agreed in writing beforehand. (3.2)
>
> 10) When CAs do their BR-required yearly update of their CPs and CPSes,
> they MUST indicate this by incrementing the version number and adding a
> dated changelog entry. (3.3)
>
> 11) The Mozilla CCADB Policy has been merged into the Root Store Policy,
> but the requirements have not changed. (4.1/4.2)
>
> 12) CA are required at all times to operate in accordance with the applicable
> CP and CPS. (5.2)
>
> 13) The requirements for what constitutes a TCSC for email have been
> reformed to actually make some sense - the cert now has to have meaningful
> technical constraints on rfc822Name. (5.3.1)
>
> 14) New intermediates must be disclosed in the CCADB within a week.
> (5.3.2)
>
> 15) Requirements for revocation are now delegated to the BRs rather than
> being explicitly enumerated. (6)
>
> 16) Section 7.4 ("Transfers") has been replaced by a new section 8 which
> requires CAs to notify of various operational changes. This is a merge-in of
> text equivalent to the existing Root Transfer Policy which was documented
> on our wiki. (8)
>
>
> Gerv
>
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
I'd like to recommend a phase in of the requirement for technically constrained CAs that issue Secure email certificates.
We have 2 customers that can issue Secure Email certificates that are not technically constrained with name Constraints (the EKU is constrained to Secure Email and ClientAuth).
We'd like to propose:
- All new CAs shall comply with Policy 2.5 on its effective date
- All existing CAs can continue to operate in issuance mode for one year
- All existing CAs may continue to operate in maintenance mode to support revocation services for up to 1 additional year (allow all 1-year certificates to expire), then the CA must be revoked.
One customer operates the CA within their environment and has been doing so for several years. Even though we've been encouraging them to move back to a Name Constrained CA or a hosted service, we've been unable to set firm plans in place without a Root program deadline we can reference. Due to the nature of the company and their acquisitions, they need to keep supporting new domains so name constraints is difficult to keep up with.
The other customer complies the prior words in the Mozilla policy regarding "Business Controls". We have an agreement with them where we issue them Secure Email certificates from our Infrastructure for domains they host and are contractually bound to using those certificates only for the matching mail account. Due to the number of different domains managed and fact they obtain certificates on behalf of the users, it's difficult to enforce validation of the email address. We have plans to add features to this issuance platform that will resolve this, but not in the near term.
Doug
> -----Original Message-----
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+doug.beattie=globals...@lists.mozilla.org] On Behalf Of
> Gervase Markham via dev-security-policy
> Sent: Thursday, June 8, 2017 11:43 AM
> To: mozilla-dev-s...@lists.mozilla.org
> Subject: Root Store Policy 2.5: Call For Review and Phase-In Periods
>
> Hi everyone,
>
> I've made the last change I currently intend to make for version 2.5 of
> Mozilla's Root Store Policy. The last task before shipping it is to assess
> whether any of the changes require a phase-in period, i.e. for some reason,
> they can't be applicable immediately.
>
> CAs and others are requested to comment, with rationale, as to why
> particular changes will need a phase-in period and what period they are
> proposing as appropriate. This is also an opportunity for interested parties to
> do a general final review.
>
> I hope to ship the policy immediately after the CAB Forum meeting in Berlin,
> which is happening from the 20th to the 22nd of June.
>
> You can see the differences between version 2.4.1 and version 2.5 here in
> diff format (click "Files Changed" and then "Load Diff"):
> https://github.com/mozilla/pkipolicy/compare/2.4.1...master
>
> or here in a more rich format:
> https://github.com/mozilla/pkipolicy/compare/2.4.1...master?short_path=b
> 7447c8
> (click "Files Changed" and scroll down).
>
> The CCADB Policy changes are trivial and can be ignored.
>
> Here is my summary of what's changed that's significant (with section
> numbers in brackets), although you should not rely on it to be complete:
>
>
> 1) Certificates with anyEKU have been added to the scope. (1.1)
>
> 2) CAs are required to "follow industry best practice for securing their
> networks, for example by conforming to the CAB Forum Network Security
> Guidelines or a successor document". (2.1)
>
> 3) Accounts which perform "Registration Authority or Delegated Third Party
> functions" are now also required to have multi-factor auth. (2.1)
>
> 4) CAs are required to follow, but not required to contribute to,
> mozilla.dev.security.policy. (2.1)
>
> 5) CAs are required to use only the 10 Blessed Methods for domain
> validation. (2.2) This requirement has already had a deadline set for it in the
> most recent CA Communication; that deadline is 21st July 2017.
>
> 6) WebTrust BR audits must now use version 2.2 or later of the audit criteria.
> (3.1.1)
>
> 7) The ETSI audit criteria requirements have been updated to be accurate.
> (3.1.2.2). ETSI TS 102 042 and TS 101 456 audits will only be accepted for
> audit periods ending in July 2017 or earlier.
>
> 8) There are further requirements on the information that needs to be
> contained in publicly-available audit information. (3.1.3)
>
> 9) Mozilla now requires that auditors be qualified in the scheme they are
> using, unless agreed in writing beforehand. (3.2)
>
> 10) When CAs do their BR-required yearly update of their CPs and CPSes,
> they MUST indicate this by incrementing the version number and adding a
> dated changelog entry. (3.3)
>
> 11) The Mozilla CCADB Policy has been merged into the Root Store Policy,
> but the requirements have not changed. (4.1/4.2)
>
> 12) CA are required at all times to operate in accordance with the applicable
> CP and CPS. (5.2)
>
> 13) The requirements for what constitutes a TCSC for email have been
> reformed to actually make some sense - the cert now has to have meaningful
> technical constraints on rfc822Name. (5.3.1)
>
> 14) New intermediates must be disclosed in the CCADB within a week.
> (5.3.2)
>
> 15) Requirements for revocation are now delegated to the BRs rather than
> being explicitly enumerated. (6)
>
> 16) Section 7.4 ("Transfers") has been replaced by a new section 8 which
> requires CAs to notify of various operational changes. This is a merge-in of
> text equivalent to the existing Root Transfer Policy which was documented
> on our wiki. (8)
>
>
> Gerv
>
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
Gervase Markham
Jun 20, 2017, 3:12:57 PM6/20/17
to Doug Beattie
Hi Doug,
On 20/06/17 16:31, Doug Beattie wrote:
> I'd like to recommend a phase in of the requirement for technically constrained CAs that issue Secure email certificates.
For those following along at home, that is this change:
https://github.com/mozilla/pkipolicy/issues/69
https://github.com/mozilla/pkipolicy/commit/f96076a01ef10e5d6a84fa4b042227512925cb7c
> We have 2 customers that can issue Secure Email certificates that are
> not technically constrained with name Constraints (the EKU is
> constrained to Secure Email and ClientAuth).>
for any email address on the planet, and they control their own
intermediate in their own infrastructure?
Do they have audits of any sort?
What are their objections to moving to a hosted service?
> The other customer complies the prior words in the Mozilla policy regarding "Business Controls". We have an agreement with them where we issue them Secure Email certificates from our Infrastructure for domains they host and are contractually bound to using those certificates only for the matching mail account. Due to the number of different domains managed and fact they obtain certificates on behalf of the users, it's difficult to enforce validation of the email address. We have plans to add features to this issuance platform that will resolve this, but not in the near term.
So even though this issuance is from your infrastructure, there are no
restrictions on the domains they can request issuance from?
Gerv
On 20/06/17 16:31, Doug Beattie wrote:
> I'd like to recommend a phase in of the requirement for technically constrained CAs that issue Secure email certificates.
https://github.com/mozilla/pkipolicy/issues/69
https://github.com/mozilla/pkipolicy/commit/f96076a01ef10e5d6a84fa4b042227512925cb7c
> We have 2 customers that can issue Secure Email certificates that are
> not technically constrained with name Constraints (the EKU is
> constrained to Secure Email and ClientAuth).>
> One customer operates the CA within their environment and has been
> doing so for several years. Even though we've been encouraging them to
> move back to a Name Constrained CA or a hosted service,
To be clear: this customer has the ability to issue email certificates
> doing so for several years. Even though we've been encouraging them to
> move back to a Name Constrained CA or a hosted service,
for any email address on the planet, and they control their own
intermediate in their own infrastructure?
Do they have audits of any sort?
What are their objections to moving to a hosted service?
> The other customer complies the prior words in the Mozilla policy regarding "Business Controls". We have an agreement with them where we issue them Secure Email certificates from our Infrastructure for domains they host and are contractually bound to using those certificates only for the matching mail account. Due to the number of different domains managed and fact they obtain certificates on behalf of the users, it's difficult to enforce validation of the email address. We have plans to add features to this issuance platform that will resolve this, but not in the near term.
restrictions on the domains they can request issuance from?
Gerv
Doug Beattie
Jun 21, 2017, 7:13:58 AM6/21/17
to Gervase Markham, mozilla-dev-s...@lists.mozilla.org
> -----Original Message-----
> From: Gervase Markham [mailto:ge...@mozilla.org]
> Sent: Tuesday, June 20, 2017 9:12 PM
> To: Doug Beattie <doug.b...@globalsign.com>; mozilla-dev-security-
> pol...@lists.mozilla.org
> Subject: Re: Root Store Policy 2.5: Call For Review and Phase-In Periods
> > We have 2 customers that can issue Secure Email certificates that are
> > not technically constrained with name Constraints (the EKU is
> > constrained to Secure Email and ClientAuth).> One customer operates
> > the CA within their environment and has been doing so for several
> > years. Even though we've been encouraging them to move back to a Name
> > Constrained CA or a hosted service,
>
> To be clear: this customer has the ability to issue email certificates for any
> email address on the planet, and they control their own intermediate in
> their own infrastructure?
Yes, but see qualifications below.
> email address on the planet, and they control their own intermediate in
> their own infrastructure?
> Do they have audits of any sort?
> What are their objections to moving to a hosted service?
> > The other customer complies the prior words in the Mozilla policy
> regarding "Business Controls". We have an agreement with them where we
> issue them Secure Email certificates from our Infrastructure for domains
> they host and are contractually bound to using those certificates only for the
> matching mail account. Due to the number of different domains managed
> and fact they obtain certificates on behalf of the users, it's difficult to
> enforce validation of the email address. We have plans to add features to
> this issuance platform that will resolve this, but not in the near term.
>
> So even though this issuance is from your infrastructure, there are no
> restrictions on the domains they can request issuance from?
That is correct. Enforcement is via contractual/business controls which is compliant with the current policy, as vague and weak as that is (and you've previously acknowledged). Moving from this level of control to being audited or having name constraints will take more time that just a couple of months.
> restrictions on the domains they can request issuance from?
Two further points:
1) It’s not clear of email applications work with name constrained CAs. Some have reported email applications do not work, however, I have not tested this case.
2) It’s unlikely that a secure email cert which is not compliant with the NC extension would be identified by email applications as non-compliant. Again, this is something I haven't tested either. Maybe some others have first-hand knowledge for how email applications work (or not) with NC CAs?
Both of the customers are large US based companies with contractual obligations to only issue secure email certificates to domains which they own and control so I hope we can come to an agreement on the phased plan.
> Gerv
Gervase Markham
Jun 21, 2017, 10:16:11 AM6/21/17
to mozilla-dev-s...@lists.mozilla.org
On 21/06/17 13:13, Doug Beattie wrote:
>> Do they have audits of any sort?
>
> There had not been any audit requirements for EKU technically
> constrained CAs, so no, there are no audits.
In your view, having an EKU limiting the intermediate to just SSL or to
>> Do they have audits of any sort?
>
> There had not been any audit requirements for EKU technically
> constrained CAs, so no, there are no audits.
just email makes it a technically constrained CA, and therefore not
subject to audit under any root program?
I ask because Microsoft's policy at http://aka.ms/auditreqs says:
"Microsoft requires that every CA submit evidence of a Qualifying Audit
on an annual basis for the CA and any non-limited root within its PKI
chain."
In your view, are these two intermediates, which are constrained only by
having the email and client auth EKUs, "limited" or "non-limited"?
>>> The other customer complies the prior words in the Mozilla policy
>> regarding "Business Controls".
the first customer does not comply with those words?
> That is correct. Enforcement is via contractual/business controls which is compliant with the current policy, as vague and weak as that is (and you've previously acknowledged). Moving from this level of control to being audited or having name constraints will take more time that just a couple of months.
arrangement with the second customer is compliant with our current
policy. For the new policy, they have 3 options: a) get an audit, b) use
a name-constrained intermediate, or c) move to a hosted service which
limits them to an approved set of domains.
Consistent with the principles outlined for Symantec regarding business
continuity, the fact that GlobalSign does not have the capability to
provide c) should not be a factor in us determining how long we should
allow this particular situation to continue.
It's worth noting that if we had discovered this situation for SSL -
that an unconstrained intermediate or uncontrolled power of issuance had
been given to a company with no audit - we would be requiring the
intermediate be revoked today, and probably taking further action as well.
> Two further points:
> 1) It’s not clear of email applications work with name constrained CAs. Some have reported email applications do not work, however, I have not tested this case.
urgency :-)
> Both of the customers are large US based companies with contractual obligations to only issue secure email certificates to domains which they own and control so I hope we can come to an agreement on the phased plan.
correlated to their competence in handling unconstrained (for email)
intermediate CAs correctly. Our default assumption must be that, without
audit, they don't know how to handle it properly.
Gerv
Doug Beattie
Jun 21, 2017, 10:59:39 AM6/21/17
to Gervase Markham, mozilla-dev-s...@lists.mozilla.org
> -----Original Message-----
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+doug.beattie=globals...@lists.mozilla.org] On Behalf Of
> Gervase Markham via dev-security-policy
> Sent: Wednesday, June 21, 2017 4:16 PM
> To: mozilla-dev-s...@lists.mozilla.org
> Subject: Re: Root Store Policy 2.5: Call For Review and Phase-In Periods
> To: mozilla-dev-s...@lists.mozilla.org
> Subject: Re: Root Store Policy 2.5: Call For Review and Phase-In Periods
> In your view, having an EKU limiting the intermediate to just SSL or to just
> email makes it a technically constrained CA, and therefore not subject to
> audit under any root program?
The BRs clearly specify SSL CAs without name constraints are required to follow the BRs and must be audited.
> email makes it a technically constrained CA, and therefore not subject to
> audit under any root program?
> I ask because Microsoft's policy at http://aka.ms/auditreqs says:
>
> "Microsoft requires that every CA submit evidence of a Qualifying Audit on
> an annual basis for the CA and any non-limited root within its PKI chain."
>
> In your view, are these two intermediates, which are constrained only by
> having the email and client auth EKUs, "limited" or "non-limited"?
>
> >>> The other customer complies the prior words in the Mozilla policy
> >> regarding "Business Controls".
>
> By implication, and reading your previous emails, are you saying that the first
> customer does not comply with those words?
The first customer does comply with "business Controls", in our view. We have contracts that specifies what they are allowed to do.
> > That is correct. Enforcement is via contractual/business controls which is
> compliant with the current policy, as vague and weak as that is (and you've
> previously acknowledged). Moving from this level of control to being
> audited or having name constraints will take more time that just a couple of
> months.
>
> Leaving aside the requirements of other root programs, I agree this
> arrangement with the second customer is compliant with our current policy.
> For the new policy, they have 3 options: a) get an audit, b) use a name-
> constrained intermediate, or c) move to a hosted service which limits them
> to an approved set of domains.
Agree, there are options for both of these customers and we're conformable we can make this happen within 12 months with another 12 months to keep the CA live for cert management and then doing a revocation of the CA.
> arrangement with the second customer is compliant with our current policy.
> For the new policy, they have 3 options: a) get an audit, b) use a name-
> constrained intermediate, or c) move to a hosted service which limits them
> to an approved set of domains.
> Consistent with the principles outlined for Symantec regarding business
> continuity, the fact that GlobalSign does not have the capability to provide c)
> should not be a factor in us determining how long we should allow this
> particular situation to continue.
>
> It's worth noting that if we had discovered this situation for SSL - that an
> unconstrained intermediate or uncontrolled power of issuance had been
> given to a company with no audit - we would be requiring the intermediate
> be revoked today, and probably taking further action as well.
> > Two further points:
> > 1) It’s not clear of email applications work with name constrained CAs.
> Some have reported email applications do not work, however, I have not
> tested this case.
>
> That sounds like something you might want to investigate as a matter of
> urgency :-)
Are there any other CAs or mail vendors that have tested name constrained issuing CAs? If using name constrained CAs don’t work with some or all of the mail applications, it seems like we might as well recommend a change to the requirement.
> urgency :-)
Peter Bowen
Jun 21, 2017, 11:02:56 AM6/21/17
to Gervase Markham, mozilla-dev-s...@lists.mozilla.org
On Wed, Jun 21, 2017 at 7:15 AM, Gervase Markham via
dev-security-policy <dev-secur...@lists.mozilla.org> wrote:
> On 21/06/17 13:13, Doug Beattie wrote:
dev-security-policy <dev-secur...@lists.mozilla.org> wrote:
> On 21/06/17 13:13, Doug Beattie wrote:
>>> Do they have audits of any sort?
>>
>> There had not been any audit requirements for EKU technically
>> constrained CAs, so no, there are no audits.
>
>>
>> There had not been any audit requirements for EKU technically
>> constrained CAs, so no, there are no audits.
>
> In your view, having an EKU limiting the intermediate to just SSL or to
> just email makes it a technically constrained CA, and therefore not
> subject to audit under any root program?
>
> just email makes it a technically constrained CA, and therefore not
> subject to audit under any root program?
>
> I ask because Microsoft's policy at http://aka.ms/auditreqs says:
>
> "Microsoft requires that every CA submit evidence of a Qualifying Audit
> on an annual basis for the CA and any non-limited root within its PKI
> chain."
>
> In your view, are these two intermediates, which are constrained only by
> having the email and client auth EKUs, "limited" or "non-limited"?
What is probably not obvious is that there is a very specific
>
> "Microsoft requires that every CA submit evidence of a Qualifying Audit
> on an annual basis for the CA and any non-limited root within its PKI
> chain."
>
> In your view, are these two intermediates, which are constrained only by
> having the email and client auth EKUs, "limited" or "non-limited"?
definition of non-limited with respect to the Microsoft policy. The
definition is unfortunately contained in the contract, which is
confidential, but the definition makes it clear that these CAs are out
of scope for audits.
Thanks,
Peter
Gervase Markham
Jun 22, 2017, 8:50:48 AM6/22/17
to mozilla-dev-s...@lists.mozilla.org
On 21/06/17 16:58, Doug Beattie wrote:
>> It's worth noting that if we had discovered this situation for SSL - that an
>> unconstrained intermediate or uncontrolled power of issuance had been
>> given to a company with no audit - we would be requiring the intermediate
>> be revoked today, and probably taking further action as well.
>
> Agree
After consultation, I have decided to implement this requirement with a
>> It's worth noting that if we had discovered this situation for SSL - that an
>> unconstrained intermediate or uncontrolled power of issuance had been
>> given to a company with no audit - we would be requiring the intermediate
>> be revoked today, and probably taking further action as well.
>
> Agree
phase-in period of six months, for already-existing intermediates. So
before 15th January 2018 (add a bit because of Christmas) these
customers, and any others like them at any other CA, need to have audits
(over at least 30 days of operations), move to a name-constrained
intermediate, or move to a managed service which does domain ownership
validation on each domain added to the system. I expect these two
intermediates to be revoked on or before 15th January 2018.
I realise this is not what you were hoping for, but it's not reasonable
to leave unconstrained intermediates in the hands of those not qualified
to hold them for a further 2 years. I am allowing six months because,
despite the weakness of the previous controls, you were in compliance
with them and so it's not reasonable to ask for a super-quick move.
https://github.com/mozilla/pkipolicy/commit/44ae763f24d6509bb2311d33950108ec5ec87082
(ignore the erroneously-added logfile).
> Are there any other CAs or mail vendors that have tested name constrained issuing CAs? If using name constrained CAs don’t work with some or all of the mail applications, it seems like we might as well recommend a change to the requirement.
Gerv
Doug Beattie
Jul 6, 2017, 11:31:47 AM7/6/17
to Gervase Markham, mozilla-dev-s...@lists.mozilla.org
Gerv,
Moving to a new CA within 6 months is certain reasonable, but having enterprise customers also replace all certificates so the CA can be revoked within 6 months might be a bit short, especially since several of those months are over the holidays. Would you consider an approach were the CAs MUST not issue new certificates after 15 November (4 months) and the CAs SHALL be revoked no later than 15 April (9 months)?
Doug
> -----Original Message-----
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+doug.beattie=globals...@lists.mozilla.org] On Behalf Of
> Gervase Markham via dev-security-policy
> Sent: Thursday, June 22, 2017 8:50 AM
> To: mozilla-dev-s...@lists.mozilla.org
> Subject: Re: Root Store Policy 2.5: Call For Review and Phase-In Periods
>
Moving to a new CA within 6 months is certain reasonable, but having enterprise customers also replace all certificates so the CA can be revoked within 6 months might be a bit short, especially since several of those months are over the holidays. Would you consider an approach were the CAs MUST not issue new certificates after 15 November (4 months) and the CAs SHALL be revoked no later than 15 April (9 months)?
Doug
> -----Original Message-----
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+doug.beattie=globals...@lists.mozilla.org] On Behalf Of
> Gervase Markham via dev-security-policy
> Sent: Thursday, June 22, 2017 8:50 AM
> To: mozilla-dev-s...@lists.mozilla.org
> Subject: Re: Root Store Policy 2.5: Call For Review and Phase-In Periods
>
> On 21/06/17 16:58, Doug Beattie wrote:
> >> It's worth noting that if we had discovered this situation for SSL -
> >> that an unconstrained intermediate or uncontrolled power of issuance
> >> had been given to a company with no audit - we would be requiring the
> >> intermediate be revoked today, and probably taking further action as well.
> >
> > Agree
>
> >> that an unconstrained intermediate or uncontrolled power of issuance
> >> had been given to a company with no audit - we would be requiring the
> >> intermediate be revoked today, and probably taking further action as well.
> >
> > Agree
>
> After consultation, I have decided to implement this requirement with a
> phase-in period of six months, for already-existing intermediates. So before
> 15th January 2018 (add a bit because of Christmas) these customers, and any
> others like them at any other CA, need to have audits (over at least 30 days of
> operations), move to a name-constrained intermediate, or move to a
> managed service which does domain ownership validation on each domain
> added to the system. I expect these two intermediates to be revoked on or
> before 15th January 2018.
>
> I realise this is not what you were hoping for, but it's not reasonable to leave
> unconstrained intermediates in the hands of those not qualified to hold them
> for a further 2 years. I am allowing six months because, despite the weakness
> of the previous controls, you were in compliance with them and so it's not
> reasonable to ask for a super-quick move.
>
> https://github.com/mozilla/pkipolicy/commit/44ae763f24d6509bb2311d339
> 50108ec5ec87082
>
> (ignore the erroneously-added logfile).
>
> phase-in period of six months, for already-existing intermediates. So before
> 15th January 2018 (add a bit because of Christmas) these customers, and any
> others like them at any other CA, need to have audits (over at least 30 days of
> operations), move to a name-constrained intermediate, or move to a
> managed service which does domain ownership validation on each domain
> added to the system. I expect these two intermediates to be revoked on or
> before 15th January 2018.
>
> I realise this is not what you were hoping for, but it's not reasonable to leave
> unconstrained intermediates in the hands of those not qualified to hold them
> for a further 2 years. I am allowing six months because, despite the weakness
> of the previous controls, you were in compliance with them and so it's not
> reasonable to ask for a super-quick move.
>
> https://github.com/mozilla/pkipolicy/commit/44ae763f24d6509bb2311d339
> 50108ec5ec87082
>
> (ignore the erroneously-added logfile).
>
> > Are there any other CAs or mail vendors that have tested name constrained
> issuing CAs? If using name constrained CAs don’t work with some or all of the
> mail applications, it seems like we might as well recommend a change to the
> requirement.
>
> issuing CAs? If using name constrained CAs don’t work with some or all of the
> mail applications, it seems like we might as well recommend a change to the
> requirement.
>
> I am open to hearing further evidence on this point.
>
>
Gervase Markham
Jul 6, 2017, 12:15:01 PM7/6/17
to Doug Beattie
On 06/07/17 16:31, Doug Beattie wrote:
> Moving to a new CA within 6 months is certain reasonable, but having enterprise customers also replace all certificates so the CA can be revoked within 6 months might be a bit short, especially since several of those months are over the holidays. Would you consider an approach were the CAs MUST not issue new certificates after 15 November (4 months) and the CAs SHALL be revoked no later than 15 April (9 months)?
Yeah, OK. A bit late for this feedback :-), but I'll make a fix when I
> Moving to a new CA within 6 months is certain reasonable, but having enterprise customers also replace all certificates so the CA can be revoked within 6 months might be a bit short, especially since several of those months are over the holidays. Would you consider an approach were the CAs MUST not issue new certificates after 15 November (4 months) and the CAs SHALL be revoked no later than 15 April (9 months)?
get back. Can you file a bug, please?
https://github.com/mozilla/pkipolicy/issues
Gerv
0 new messages