Next CA Communication

[Gervase Markham]

The URL for the draft of the next CA Communication is here:
https://mozilla-mozillacaprogram.cs54.force.com/Communications/CACommunicationSurveySample?CACommunicationId=a050S000000G3K2

Note that this is a _draft_ - the form parts will not work, and no CA
should attempt to use this URL or the form to send in any responses.

Please provide feedback in this group on whether the questions and
actions are clear, whether they are appropriate, and whether anything
else should or could be added.

Some of these items are effectively new policy (such as the requirement
to rev CP/CPS version numbers at least yearly); if they survive
unscathed, we will update the policy doc to include them.

We'd like to send out this Communication before the end of this month.

Gerv

[Peter Bowen]

On Fri, Mar 17, 2017 at 8:30 AM, Gervase Markham via
dev-security-policy <dev-secur...@lists.mozilla.org> wrote:
> The URL for the draft of the next CA Communication is here:
> https://mozilla-mozillacaprogram.cs54.force.com/Communications/CACommunicationSurveySample?CACommunicationId=a050S000000G3K2
>
> Note that this is a _draft_ - the form parts will not work, and no CA
> should attempt to use this URL or the form to send in any responses.
>
> Please provide feedback in this group on whether the questions and
> actions are clear, whether they are appropriate, and whether anything
> else should or could be added.
>
> Some of these items are effectively new policy (such as the requirement
> to rev CP/CPS version numbers at least yearly); if they survive
> unscathed, we will update the policy doc to include them.

"+ Friendly name and SHA1 or SHA256 fingerprint of each root
certificate and intermediate certificate covered by the audit scope "

I think you unintentionally have this backwards. Certificates in
scope for audits are those _issued_ by the CA being audited. So if
ExampleCA issues a CA certificate naming ContosoCA as the subject,
then that certificate is in scope for Example CA but not for
ContosoCA.

I would also avoid the term "Friendly name" unless you define it, as
that is the name of Microsoft trust list attribute which does not
necessarily match anything in the certificate; for example one entry
in the Microsoft list is for a CA with1 distinguished name of
"CN=Class 1 Primary CA,O=Certplus,C=FR" and friendly name of "WoSign
1999".

I would replace this with:

+ Distinguished name and SHA-256 hash of the SubjectPublicKeyInfo of
each certificate issuer covered by the audit scope
+ Clear indication of which in-scope certificate issuers are Root CAs

Thanks,
Peter

[Gervase Markham]

On 17/03/17 15:30, Gervase Markham wrote:
> The URL for the draft of the next CA Communication is here:
> https://mozilla-mozillacaprogram.cs54.force.com/Communications/CACommunicationSurveySample?CACommunicationId=a050S000000G3K2

* Action 1 should say that if in future additional specific methods are
defined by the CAB Forum, then they will be permitted also.

* Clarifying: "so the subsections of version 3.2.2.4 that are marked
"Reserved" in version 1.4.2 of the BRs are still BR-compliant" -> "so
the subsections of section 3.2.2.4 in 1.4.1 that are marked "Reserved"
in version 1.4.2 of the BRs are still BR-compliant under 1.4.2".

* Action 1: Kathleen, I believe you said that 1/1/2016 is the earliest
date the widget will do, but the text asks for 1/1/2015 (if you don't
have the Websites trust bit)?

* Action 2: as the two choices are mutually exclusive, I would expect
radio buttons rather than a checkbox.

* Action 3: "in github" -> "on Github".

* Action 5: policy 2.4 has some of these requirements but not all. I've
filed an issue to add any extra ones.
https://github.com/mozilla/pkipolicy/issues/66

* Action 7: some of the BR Compliance bugs relate to CAs which are no
longer trusted, like StartCom. If StartCom does become a trusted CA
again, it will be with new systems which most likely do not have the
same bugs. Should we close the StartCom compliance bugs?

* Action 7: I have updated these bugs to have a convention of putting
the CA name at the start of the bug summary. This allows sorting "by CA"
if you sort by Summary.

* Action 8: Can we provide more structure here, by perhaps putting some
boilerplate text in the answer box or something like that? Or at least
list the sections and actions we expect to have been done?

I would also like to add the following questions/actions:

A) Does your CA have an RA program, whereby non-Affiliates of your
company perform aspects of certificate validation on your behalf under
contract? If so, please tell us about the program, including:

* How many companies are involved
* Which of those companies do their own domain ownership validation
* What measures you have in place to ensure this work is done to an
appropriate standard

If you do not have an RA program, write "Not Applicable".

<Free text box>

B) Your attention is drawn to the cablint and x509lint tools, which you
may wish to incorporate into your certificate issuance pipeline to get
early warning of circumstances when you are issuing certificates which
do not meet the Baseline Requirements (cablint) or X509 standards
(x509lint).

https://github.com/kroeckx/x509lint
XXX What's the URL for cablint?

[ ] I am now aware of these tools

C) CAA

The CAB Forum recently passed ballot 187, which updated the Baseline
Requirements to make CAA (RFC 6844) checking mandatory at time of
certificate issuance in almost all circumstances. Please provide a list
of the domain names which your CA plans to recognise in a CAA record's
issue and issuewild property tags as permitting it to issue. If certain
identifiers only permit under certain circumstances, please explain.

<Free text box>

Mozilla plans to make a central list of these identifiers.

D) Problem Reporting Mechanism

Please explain how your CA meets the following requirement from the BRs
section 4.9.3:

“The CA SHALL provide Subscribers, Relying Parties, Application Software
Suppliers, and other third parties with clear instructions for reporting
suspected Private Key Compromise, Certificate misuse, or other types of
fraud, compromise, misuse, inappropriate conduct, or any other matter
related to Certificates. The CA SHALL publicly disclose the instructions
through a readily accessible online means.”

Please detail both the mechanism and the location(s) where you publicly
disclose it. Mozilla plans to make a central list of these mechanisms.
You are encouraged to make an email address at least one of your
provided options.

<Free text box>

E) SHA-1 and S/MIME

Does your CA issue SHA-1 S/MIME certificates? If so, please explain your
plans for ceasing to do so, and any self-imposed or external deadlines
you are planning to meet. Mozilla plans to make policy in this area in
the future, so please explain any facts or constraints which you think
might be relevant to our considerations.

If none of your roots have the Email trust bit set, write "Not Applicable".

<Free text box>


Gerv

[Peter Bowen]

On Mon, Mar 20, 2017 at 8:36 AM, Gervase Markham via
dev-security-policy <dev-secur...@lists.mozilla.org> wrote:
> On 17/03/17 15:30, Gervase Markham wrote:

>> The URL for the draft of the next CA Communication is here:
>> https://mozilla-mozillacaprogram.cs54.force.com/Communications/CACommunicationSurveySample?CACommunicationId=a050S000000G3K2
>
>

> * Action 5: policy 2.4 has some of these requirements but not all. I've
> filed an issue to add any extra ones.
> https://github.com/mozilla/pkipolicy/issues/66
>
>

> B) Your attention is drawn to the cablint and x509lint tools, which you
> may wish to incorporate into your certificate issuance pipeline to get
> early warning of circumstances when you are issuing certificates which
> do not meet the Baseline Requirements (cablint) or X509 standards
> (x509lint).
>
> https://github.com/kroeckx/x509lint
> XXX What's the URL for cablint?

https://cabforum.org/pipermail/public/2017-March/010144.html

>
> E) SHA-1 and S/MIME
>
> Does your CA issue SHA-1 S/MIME certificates? If so, please explain your
> plans for ceasing to do so, and any self-imposed or external deadlines
> you are planning to meet. Mozilla plans to make policy in this area in
> the future, so please explain any facts or constraints which you think
> might be relevant to our considerations.

Why is this limited to s/mime? It would be highly valuable to
understand if any SHA-1 signatures are being created using keys
trusted to sign server auth certs.

[Jeremy Rowley]

A) Does your CA have an RA program, whereby non-Affiliates of your company
perform aspects of certificate validation on your behalf under contract? If
so, please tell us about the program, including:

* How many companies are involved
* Which of those companies do their own domain ownership validation
* What measures you have in place to ensure this work is done to an
appropriate standard

[JR] This should be limited to SSL certs IMO. With client certs, you're going
to get a lot more RAs that likely function under the standard or legal
framework defining the certificate type.

[Peter Bowen]

What if the question was scoped to "RAs that can do independent
validation of domain control" or some such? e.g. a classic "Enteprise
RA" set up where the CA's in-house RA confirms control of a public
suffix and then allows the Enterprise to internally confirm
certificate requests under the validated domain should not be counted
here.

[Kathleen Wilson]

On Friday, March 17, 2017 at 9:17:07 AM UTC-7, Peter Bowen wrote:
> I would replace this with:
>
> + Distinguished name and SHA-256 hash of the SubjectPublicKeyInfo of
> each certificate issuer covered by the audit scope
> + Clear indication of which in-scope certificate issuers are Root CAs
>

Is this OK?
+ Distinguished name (Certificate Subject Field) and SHA1 or SHA256 fingerprint of each certificate issuer covered by the audit scope

+ Clear indication of which in-scope certificate issuers are Root CAs

We are looking for human-readable information, so want a name and a fingerprint.

Thanks,
Kathleen

[Kathleen Wilson]

On Monday, March 20, 2017 at 9:50:38 AM UTC-7, Gervase Markham wrote:
> On 17/03/17 15:30, Gervase Markham wrote:
> > The URL for the draft of the next CA Communication is here:
> > https://mozilla-mozillacaprogram.cs54.force.com/Communications/CACommunicationSurveySample?CACommunicationId=a050S000000G3K2
>
> * Action 1 should say that if in future additional specific methods are
> defined by the CAB Forum, then they will be permitted also.

added

>
> * Clarifying: "so the subsections of version 3.2.2.4 that are marked
> "Reserved" in version 1.4.2 of the BRs are still BR-compliant" -> "so
> the subsections of section 3.2.2.4 in 1.4.1 that are marked "Reserved"
> in version 1.4.2 of the BRs are still BR-compliant under 1.4.2".

done

>
> * Action 1: Kathleen, I believe you said that 1/1/2016 is the earliest
> date the widget will do, but the text asks for 1/1/2015 (if you don't
> have the Websites trust bit)?

Turns out that the date widget in the survey tool allows for 1/1/2015.

(I had previously tested the date widget within Salesforce records)

>
> * Action 2: as the two choices are mutually exclusive, I would expect
> radio buttons rather than a checkbox.

done

>
> * Action 3: "in github" -> "on Github".

done

>
> * Action 5: policy 2.4 has some of these requirements but not all. I've
> filed an issue to add any extra ones.
> https://github.com/mozilla/pkipolicy/issues/66

Thanks.

>
> * Action 7: some of the BR Compliance bugs relate to CAs which are no
> longer trusted, like StartCom. If StartCom does become a trusted CA
> again, it will be with new systems which most likely do not have the
> same bugs. Should we close the StartCom compliance bugs?

Yes, I think that makes sense.

>
> * Action 7: I have updated these bugs to have a convention of putting
> the CA name at the start of the bug summary. This allows sorting "by CA"
> if you sort by Summary.

Good idea. Added to
https://wiki.mozilla.org/CA_Bug_Triage#CA_Certificate_Issuance_Problems_and_Incidents

I will be updating all of the open CA Incident and BR Compliance bugs to move them into a new component:
mozilla.org :: CA Certificates Mis-Issuance

(Currently these bugs may be found in NSS :: CA Certificates and mozilla.org :: CA Certificates.)

While I'm at it, I'll update the bug summary as you suggested, and I'll update the whiteboard:
[ca-investigation] -- Concern has been raised about certificates that a CA has issued. Investigation and/or discussion in progress.
[ca-incident-response] -- The concern about a CA's certificates has been confirmed, and the CA has follow-up action items
[ca-compliance] -- The concern about a CA's certificates is in regards to failure to comply with Mozilla policy and/or the CA/Browser Forum's Baseline Requirements, and is determined to not be an imminent security concern.

Then I'll update https://wiki.mozilla.org/CA/ca-bugs to use the new whiteboard tags.

>
> * Action 8: Can we provide more structure here, by perhaps putting some
> boilerplate text in the answer box or something like that? Or at least
> list the sections and actions we expect to have been done?

Changed to checkboxes and a follow-up text field. Please review.

>
> I would also like to add the following questions/actions:
>
> A) Does your CA have an RA program, whereby non-Affiliates of your
> company perform aspects of certificate validation on your behalf under
> contract? If so, please tell us about the program, including:
>
> * How many companies are involved
> * Which of those companies do their own domain ownership validation
> * What measures you have in place to ensure this work is done to an
> appropriate standard
>
> If you do not have an RA program, write "Not Applicable".
>
> <Free text box>

added

>
> B) Your attention is drawn to the cablint and x509lint tools, which you
> may wish to incorporate into your certificate issuance pipeline to get
> early warning of circumstances when you are issuing certificates which
> do not meet the Baseline Requirements (cablint) or X509 standards
> (x509lint).
>
> https://github.com/kroeckx/x509lint
> XXX What's the URL for cablint?
>
> [ ] I am now aware of these tools

Added

>
> C) CAA
>
> The CAB Forum recently passed ballot 187, which updated the Baseline
> Requirements to make CAA (RFC 6844) checking mandatory at time of
> certificate issuance in almost all circumstances. Please provide a list
> of the domain names which your CA plans to recognise in a CAA record's
> issue and issuewild property tags as permitting it to issue. If certain
> identifiers only permit under certain circumstances, please explain.
>
> <Free text box>
>
> Mozilla plans to make a central list of these identifiers.

Added, but please carefully review -- not sure I got it correct.

>
> D) Problem Reporting Mechanism
>
> Please explain how your CA meets the following requirement from the BRs
> section 4.9.3:
>
> “The CA SHALL provide Subscribers, Relying Parties, Application Software
> Suppliers, and other third parties with clear instructions for reporting
> suspected Private Key Compromise, Certificate misuse, or other types of
> fraud, compromise, misuse, inappropriate conduct, or any other matter
> related to Certificates. The CA SHALL publicly disclose the instructions
> through a readily accessible online means.”
>
> Please detail both the mechanism and the location(s) where you publicly
> disclose it. Mozilla plans to make a central list of these mechanisms.
> You are encouraged to make an email address at least one of your
> provided options.
>
> <Free text box>

added

>
> E) SHA-1 and S/MIME
>
> Does your CA issue SHA-1 S/MIME certificates? If so, please explain your
> plans for ceasing to do so, and any self-imposed or external deadlines
> you are planning to meet. Mozilla plans to make policy in this area in
> the future, so please explain any facts or constraints which you think
> might be relevant to our considerations.
>
> If none of your roots have the Email trust bit set, write "Not Applicable".
>
> <Free text box>
>

added

Thanks,
Kathleen

[Kathleen Wilson]

On Monday, March 20, 2017 at 10:59:41 AM UTC-7, Peter Bowen wrote:
> On Mon, Mar 20, 2017 at 10:43 AM, Jeremy Rowley via

> > [JR] This should be limited to SSL certs IMO. With client certs, you're going
> > to get a lot more RAs that likely function under the standard or legal
> > framework defining the certificate type.
>
> What if the question was scoped to "RAs that can do independent
> validation of domain control" or some such? e.g. a classic "Enteprise
> RA" set up where the CA's in-house RA confirms control of a public
> suffix and then allows the Enterprise to internally confirm
> certificate requests under the validated domain should not be counted
> here.

updated

See action 9 here:
https://mozilla-mozillacaprogram.cs54.force.com/Communications/CACommunicationSurveySample?CACommunicationId=a050S000000G3K2

[Jeremy Rowley]

I only understand this "independent validation of domain control" because
I'm on the thread. I don't think CAs who aren't actively involved will
understand what it means. DigiCert has an RA. It's DigiCert. We validate
our certificate orders and submit them to the CA for issuance. I think it
should be clarified that this is referencing a) third-party RAs and b) where
the CA relies on the RA to perform the domain validation function required
under the Baseline Requirements.

Something like: "Does your CA have any third-party Registration Authority
(RA)s program that the CA relies on to perform the domain validation
required under Section 3.2.2.4 of the Baseline Requirements."

Jeremy

-----Original Message-----
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digice...@lists.mozilla
.org] On Behalf Of Kathleen Wilson via dev-security-policy
Sent: Monday, March 20, 2017 2:29 PM
To: mozilla-dev-s...@lists.mozilla.org
Subject: Re: Next CA Communication

On Monday, March 20, 2017 at 10:59:41 AM UTC-7, Peter Bowen wrote:

> On Mon, Mar 20, 2017 at 10:43 AM, Jeremy Rowley via

> > [JR] This should be limited to SSL certs IMO. With client certs,
> > you're going to get a lot more RAs that likely function under the
> > standard or legal framework defining the certificate type.
>
> What if the question was scoped to "RAs that can do independent
> validation of domain control" or some such? e.g. a classic "Enteprise
> RA" set up where the CA's in-house RA confirms control of a public
> suffix and then allows the Enterprise to internally confirm
> certificate requests under the validated domain should not be counted
> here.

updated

See action 9 here:
https://mozilla-mozillacaprogram.cs54.force.com/Communications/CACommunicati
onSurveySample?CACommunicationId=a050S000000G3K2

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

[Kathleen Wilson]

On Monday, March 20, 2017 at 1:37:32 PM UTC-7, Jeremy Rowley wrote:
> Something like: "Does your CA have any third-party Registration Authority
> (RA)s program that the CA relies on to perform the domain validation
> required under Section 3.2.2.4 of the Baseline Requirements."

Updated

[Peter Bowen]

On Mon, Mar 20, 2017 at 4:52 PM Rob Stradling <rob.st...@comodo.com>
wrote:

> On 20/03/17 17:07, Peter Bowen via dev-security-policy wrote:
> <snip>

> >> B) Your attention is drawn to the cablint and x509lint tools, which you
> >> may wish to incorporate into your certificate issuance pipeline to get
> >> early warning of circumstances when you are issuing certificates which
> >> do not meet the Baseline Requirements (cablint) or X509 standards
> >> (x509lint).
> >>
> >> https://github.com/kroeckx/x509lint
> >> XXX What's the URL for cablint?
> >

> > https://cabforum.org/pipermail/public/2017-March/010144.html
>
> Hi Peter. I presume you meant...
>
> https://github.com/awslabs/certlin <https://github.com/awslabs/certlint>t



Yes. Not sure how that archive URL got there.

>
> --
> Rob Stradling
> Senior Research & Development Scientist
> COMODO - Creating Trust Online
>

[Gervase Markham]

On 20/03/17 15:33, Kathleen Wilson wrote:
>> * Action 7: some of the BR Compliance bugs relate to CAs which are no
>> longer trusted, like StartCom. If StartCom does become a trusted CA
>> again, it will be with new systems which most likely do not have the
>> same bugs. Should we close the StartCom compliance bugs?
>
> Yes, I think that makes sense.

OK, I've closed the StartCom and ANSSI bugs.

>> * Action 8: Can we provide more structure here, by perhaps putting some
>> boilerplate text in the answer box or something like that? Or at least
>> list the sections and actions we expect to have been done?
>
> Changed to checkboxes and a follow-up text field. Please review.

You've added a box: "All SHA-1 based TLS/SSL certificates chaining up to
our root certificates included in Mozilla’s CA Certificate Program have
either expired or been revoked."

I don't think we _required_ revocation of all publicly-trusted SHA-1
certs, did we?

Also, the two about "all... certificates" might need to be changed to
"Our policy now is that all... certificates".

>> C) CAA

>
> Added, but please carefully review -- not sure I got it correct.

Looks good to me.

Gerv

[Gervase Markham]

On 20/03/17 13:07, Peter Bowen wrote:
>> E) SHA-1 and S/MIME
>>
>> Does your CA issue SHA-1 S/MIME certificates? If so, please explain your
>> plans for ceasing to do so, and any self-imposed or external deadlines
>> you are planning to meet. Mozilla plans to make policy in this area in
>> the future, so please explain any facts or constraints which you think
>> might be relevant to our considerations.
>
> Why is this limited to s/mime? It would be highly valuable to
> understand if any SHA-1 signatures are being created using keys
> trusted to sign server auth certs.

Presumably you mean outside the scope of the BRs?

Gerv

[Gervase Markham]

On 20/03/17 16:29, Kathleen Wilson wrote:
> updated
>
> See action 9 here:
> https://mozilla-mozillacaprogram.cs54.force.com/Communications/CACommunicationSurveySample?CACommunicationId=a050S000000G3K2

You now need to remove the second bullet in this action, as it's
redundant with the reduced scope.

Gerv

[Kathleen Wilson]

On Monday, March 20, 2017 at 2:43:22 PM UTC-7, Gervase Markham wrote:
> On 20/03/17 15:33, Kathleen Wilson wrote:
> >> * Action 7: some of the BR Compliance bugs relate to CAs which are no
> >> longer trusted, like StartCom. If StartCom does become a trusted CA
> >> again, it will be with new systems which most likely do not have the
> >> same bugs. Should we close the StartCom compliance bugs?
> >
> > Yes, I think that makes sense.
>
> OK, I've closed the StartCom and ANSSI bugs.

Thanks!

I also finished updating bugs:
https://wiki.mozilla.org/CA/ca-bugs
https://wiki.mozilla.org/CA_Bug_Triage#CA_Certificate_Issuance_Problems_and_Incidents

>
> >> * Action 8: Can we provide more structure here, by perhaps putting some
> >> boilerplate text in the answer box or something like that? Or at least
> >> list the sections and actions we expect to have been done?
> >
> > Changed to checkboxes and a follow-up text field. Please review.
>
> You've added a box: "All SHA-1 based TLS/SSL certificates chaining up to
> our root certificates included in Mozilla’s CA Certificate Program have
> either expired or been revoked."
>
> I don't think we _required_ revocation of all publicly-trusted SHA-1
> certs, did we?

removed

>
> Also, the two about "all... certificates" might need to be changed to
> "Our policy now is that all... certificates".

Updated

>
> > See action 9 here:
> > https://mozilla-mozillacaprogram.cs54.force.com/Communications/CACommunicationSurveySample?CACommunicationId=a050S000000G3K2
>
> You now need to remove the second bullet in this action, as it's
> redundant with the reduced scope.
>

removed

Thanks,
Kathleen

[Kurt Roeckx]

On 2017-03-17 16:30, Gervase Markham wrote:
> The URL for the draft of the next CA Communication is here:
> https://mozilla-mozillacaprogram.cs54.force.com/Communications/CACommunicationSurveySample?CACommunicationId=a050S000000G3K2

Action 6 says:
However, a point-in-time audit statement only validates CA’s practices
on that date. Therefore, period-of-time audit statements are still
required over that timeframe. Audit periods must be less than a year and
contiguous. There must not be gaps in audit periods.

I'm not sure what it's trying to say.


Kurt

[Jakob Bohm]

Reading this in context seems to simply emphasize, in no uncertain
terms, that getting a point-in-time audit that a problem has been fixed
does not in any way, shape or form replace the need for regular audits
for the period that happens to overlap the date of such a clean-up
point-in-time audit.


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

[Kurt Roeckx]

On 2017-03-21 12:51, Jakob Bohm wrote:
> On 21/03/2017 10:09, Kurt Roeckx wrote:
>> On 2017-03-17 16:30, Gervase Markham wrote:
>>> The URL for the draft of the next CA Communication is here:
>>> https://mozilla-mozillacaprogram.cs54.force.com/Communications/CACommunicationSurveySample?CACommunicationId=a050S000000G3K2
>>>
>>>
>>
>> Action 6 says:
>> However, a point-in-time audit statement only validates CA’s practices
>> on that date. Therefore, period-of-time audit statements are still
>> required over that timeframe. Audit periods must be less than a year and
>> contiguous. There must not be gaps in audit periods.
>>
>> I'm not sure what it's trying to say.
>>
>>
>> Kurt
>>
>
> Reading this in context seems to simply emphasize, in no uncertain
> terms, that getting a point-in-time audit that a problem has been fixed
> does not in any way, shape or form replace the need for regular audits
> for the period that happens to overlap the date of such a clean-up
> point-in-time audit.

I read both of them as "point-in-time", and it didn't make sense to me.


Kurt

[Gervase Markham]

On 17/03/17 11:30, Gervase Markham wrote:
> The URL for the draft of the next CA Communication is here:
> https://mozilla-mozillacaprogram.cs54.force.com/Communications/CACommunicationSurveySample?CACommunicationId=a050S000000G3K2

A few more wording tweaks on the current version:

* Action 1 says: "Date must be before June 1, 2017". That gives CAs 2
months to make a CP/CPS update. Do we normally allow a bit more than
that for non-urgent updates? Say, 3 months?

* "I understand that our CP/CPS documents shall be updated each year" ->
"I understand that our CP/CPS documents should be reviewed and the
version number incremented each year"

* Action 8: "Our current policy is...". In hindsight, this is ambiguous
- it could be Mozilla's policy, and the CA is just affirming they
understand it. Instead say "The current policy of our CA is...".

Gerv

[Gervase Markham]

On 21/03/17 10:16, Gervase Markham wrote:
> On 17/03/17 11:30, Gervase Markham wrote:
>> The URL for the draft of the next CA Communication is here:
>> https://mozilla-mozillacaprogram.cs54.force.com/Communications/CACommunicationSurveySample?CACommunicationId=a050S000000G3K2
>
> A few more wording tweaks on the current version:

In Action 1, we should replace:

"However, if additional methods of domain validation are added to
section 3.2.2.4 of the BRs in the future, they will also be permitted."

with:

"Mozilla expects that all missing methods will be restored to the
Baseline Requirements in the near future. Once that happens, we will
return to the practice of requiring conformance to the latest version of
the BRs."

(The CAB Forum PAG is about to resolve itself; happily, all participants
have agreed to license their patents under a CAB Forum RF license. It's
now just a question of getting a ballot done to add back the missing
methods. Yay :-)

Gerv

[Kathleen Wilson]

On Tuesday, March 21, 2017 at 5:51:29 AM UTC-7, Kurt Roeckx wrote:
> On 2017-03-21 12:51, Jakob Bohm wrote:
> > On 21/03/2017 10:09, Kurt Roeckx wrote:

> >> Action 6 says:


I've updated action #6, but it still might not be clear.

Here's the new draft:
ACTION 6: QUALIFIED AUDIT STATEMENTS

When an auditor finds non-compliance with the audit criteria, the audit statement should clearly indicate the word “qualified”, and clearly identify the controls that failed. The auditor should provide qualified reports for all time periods until the problems have been fixed.

Period-of-time audit statements are required to cover audit periods that are less than one year and are contiguous. In other words, there should never be a time gap between the audit periods indicated in period-of-time audit statements.

Point-in-time audit statements may be used to confirm that all of the problems that the auditor previously identified in a qualified audit statement have been corrected. However, a point-in-time assessment does *not* replace the period-of-time assessment. (Required)

~~

Please let me know if you have suggestions about how to make this more clear.

Thanks,
Kathleen

[Kathleen Wilson]

On Tuesday, March 21, 2017 at 7:17:26 AM UTC-7, Gervase Markham wrote:
> On 17/03/17 11:30, Gervase Markham wrote:
> > The URL for the draft of the next CA Communication is here:
> > https://mozilla-mozillacaprogram.cs54.force.com/Communications/CACommunicationSurveySample?CACommunicationId=a050S000000G3K2
>
> A few more wording tweaks on the current version:
>
> * Action 1 says: "Date must be before June 1, 2017". That gives CAs 2
> months to make a CP/CPS update. Do we normally allow a bit more than
> that for non-urgent updates? Say, 3 months?

Updated to "Date must be before July 21, 2017." (3 months from when survey must be completed)

>
> * "I understand that our CP/CPS documents shall be updated each year" ->
> "I understand that our CP/CPS documents should be reviewed and the
> version number incremented each year"

Action 2 option updated to:
"I understand that our CP/CPS documents must be reviewed annually to ensure continued compliance with the CA/Browser Forum's Baseline Requirements, and that at least the version number should be incremented each year."

>
> * Action 8: "Our current policy is...". In hindsight, this is ambiguous
> - it could be Mozilla's policy, and the CA is just affirming they
> understand it. Instead say "The current policy of our CA is...".

Done.

Thanks,
Kathleen

[Kathleen Wilson]

Glad to hear that.

Second paragraph of Action 1 now says:
~~
Note that version 1.4.2 of the BRs does not contain all 10 of these methods, but it does contain section 3.2.2.4.11, "Other Methods", so the subsections of version 3.2.2.4 that are marked "Reserved" in version 1.4.2 of the BRs are still BR-compliant under version 1.4.2. By Mozilla policy, CAs are not permitted to rely on the "Other Methods" section to use methods of domain validation that are not among the 10 listed in section 3.2.2.4 of version 1.4.1 of the BRs. Mozilla expects that all of the methods for doing domain validation that are missing in version 1.4.2 of the BRs will be restored to a forthcoming version of the BRs, so we will once again be able to accept all of the methods of domain validation listed in the latest version of the BRs.
~~

Thanks,
Kathleen

[Gervase Markham]

On 23/03/17 23:07, Kathleen Wilson wrote:
> Second paragraph of Action 1 now says: ~~ Note that version 1.4.2 of
> the BRs does not contain all 10 of these methods, but it does contain
> section 3.2.2.4.11, "Other Methods", so the subsections of version
> 3.2.2.4 that are marked "Reserved" in version 1.4.2 of the BRs are
> still BR-compliant under version 1.4.2. By Mozilla policy, CAs are
> not permitted to rely on the "Other Methods" section to use methods
> of domain validation that are not among the 10 listed in section
> 3.2.2.4 of version 1.4.1 of the BRs. Mozilla expects that all of the
> methods for doing domain validation that are missing in version 1.4.2
> of the BRs will be restored to a forthcoming version of the BRs, so
> we will once again be able to accept all of the methods of domain
> validation listed in the latest version of the BRs. ~~

That's not quite it, because the first bit is still confusing (my
fault), and the last para suggests we currently don't accept all methods
listed, which we do. Can we try the following?

Note that version 1.4.2 of the BRs does not contain all 10 of these
methods, but it does contain section 3.2.2.4.11, "Other Methods", so the

methods that were removed in version 1.4.2 of the BRs are still
BR-compliant under that version. By Mozilla policy, CAs are not

permitted to rely on the "Other Methods" section to use methods of
domain validation that are not among the 10 listed in section 3.2.2.4 of

version 1.4.1 of the BRs. As the IPR issues relating to these missing
methods have now been resolved, Mozilla expects that they will soon be
restored. Once they are, our policy will once again become that "we
accept all of the methods of domain validation explicitly listed in the

latest version of the BRs".

Gerv

[Kathleen Wilson]

Updated.

Thanks,
Kathleen

[Gervase Markham]

On 17/03/17 15:30, Gervase Markham wrote:
> The URL for the draft of the next CA Communication is here:
> https://mozilla-mozillacaprogram.cs54.force.com/Communications/CACommunicationSurveySample?CACommunicationId=a050S000000G3K2
>

> Note that this is a _draft_ - the form parts will not work, and no CA
> should attempt to use this URL or the form to send in any responses.

Here is another proposed question:

Certificate Validity Periods

Your attention is drawn to CAB Forum ballot 193, which recently passed.
This reduces the maximum permissible lifetime of certificates from 39 to
27 months, as of 1st March 2018. In addition, it reduces the amount of
time validation information can be reused, from 39 to 27 months, as of
31st March 2017. Please be aware of these deadlines so you can adjust
your practices accordingly.

Mozilla is interested in, and the CAB Forum continues to discuss, the
possibility of further reductions in certificate lifetime. We see a
benefit here in reducing the overall turnover time it takes for an
improvement in practices or algorithms to make its way through the
entire WebPKI. Shorter times, carefully managed, also encourage the
ecosystem towards automation, which is beneficial when quick changes
need to be made in response to security incidents. Specifically, Mozilla
is currently considering a reduction to 13 months, effective as of 1st
March 2019 (2 years from now). Alternatively, several CAs have said that
the need for contract renegotiation is a significant issue when reducing
lifetimes, so in order that CAs will only have to do this once rather
than twice, another option would be to require the reduction from 1st
March 2018 (1 year from now), the current reduction date.

Please explain whether you would support such a further reduction dated
to one or both of those dates and, if not, what specifically prevents
you from lending your support to such a move. You may wish to reference
the discussion on the CAB Forum public mailing list to familiarise
yourself with the detailed arguments in favour of certificate lifetime
reduction.


Comments, as always, are welcome.

Gerv

[Ryan Sleevi]

Gerv,

I'm curious whether you would consider 18 months an appropriate target for
a deprecation to 1 year certificates. That is, do you believe a transition
to 1 year certificates requires 24 months or 18 months, or was it chosen
simply for its appeal as a staggered number (1 year -> 2 year certs, 2
years -> 1 year certs)

[Ryan Sleevi]

On Mon, Mar 27, 2017 at 10:18 AM, Ryan Sleevi <ry...@sleevi.com> wrote:

> Gerv,
>
> I'm curious whether you would consider 18 months an appropriate target for
> a deprecation to 1 year certificates. That is, do you believe a transition
> to 1 year certificates requires 24 months or 18 months, or was it chosen
> simply for its appeal as a staggered number (1 year -> 2 year certs, 2
> years -> 1 year certs)
>

I suppose one further consideration - the proposal you outline would forbid
issuance. As we saw with the SHA-1 deprecation, there are a variety of PKI
communities which may rely on long-lived certificates for other purposes,
but otherwise in no way interact with Mozilla applications.

Would it be useful to thus also query whether there would be impact in
Mozilla applications failing to trust such certificates, but otherwise to
continue permitting their issuance. While this carries with it some
compatibility and interoperability risk - due to the issuance continuing
independent of applications - I suspect that if applications could agree
upon a target date to reduce the trust in acceptance, this might be a
sufficient safeguard against the "first mover" problem and allow Mozilla to
obtain its objectives without explicitly prohibiting issuance.

That is a separate, but related, question, but useful to consider if you
will be asking all CAs, some of whom may have reasons due to other PKIs
that would make them concerned about potential impact. However, if
Mozilla's goals and desires would include seeing those PKIs are operated
independently of the Web PKI, then forbidding issuance would be appropriate.

[Gervase Markham]

On 27/03/17 16:18, Ryan Sleevi wrote:
> I'm curious whether you would consider 18 months an appropriate target for
> a deprecation to 1 year certificates. That is, do you believe a transition
> to 1 year certificates requires 24 months or 18 months, or was it chosen
> simply for its appeal as a staggered number (1 year -> 2 year certs, 2
> years -> 1 year certs)

The latter.

It sort of seems like if you were going to do 18 months, why not do 12
months, and have a single contract renegotiation? But I'm open to
further discussion.

Gerv

[Gervase Markham]

On 27/03/17 16:22, Ryan Sleevi wrote:
> Would it be useful to thus also query whether there would be impact in
> Mozilla applications failing to trust such certificates, but otherwise to
> continue permitting their issuance.

That is a good idea. How about:


If you are unable to support a comprehensive reduction in issuance
lifetime, please explain the impact you see of Mozilla (and potentially
other browsers) removing trust from certificates of lifetime > 13 months
in the same sort of timeframe. This would mean browser-facing
certificates would need to have shorter lifetimes, but those
certificates not issued for trust by browsers could have longer lifetimes.

<Free text box>

> That is a separate, but related, question, but useful to consider if you
> will be asking all CAs, some of whom may have reasons due to other PKIs
> that would make them concerned about potential impact. However, if
> Mozilla's goals and desires would include seeing those PKIs are operated
> independently of the Web PKI, then forbidding issuance would be appropriate.

Presumably you mean independently apart from the fact that they happen
to share roots?

Gerv

[Jakob Bohm]

On 27/03/2017 11:10, Gervase Markham wrote:
> On 17/03/17 15:30, Gervase Markham wrote:
>> The URL for the draft of the next CA Communication is here:
>> https://mozilla-mozillacaprogram.cs54.force.com/Communications/CACommunicationSurveySample?CACommunicationId=a050S000000G3K2
>>
>> Note that this is a _draft_ - the form parts will not work, and no CA
>> should attempt to use this URL or the form to send in any responses.
>
> Here is another proposed question:
>
> Certificate Validity Periods
>
> Your attention is drawn to CAB Forum ballot 193, which recently passed.
> This reduces the maximum permissible lifetime of certificates from 39 to
> 27 months, as of 1st March 2018. In addition, it reduces the amount of
> time validation information can be reused, from 39 to 27 months, as of
> 31st March 2017. Please be aware of these deadlines so you can adjust
> your practices accordingly.
>

While this has apparently already passed, the earlier date for
requiring revalidation is going to be a problem for any CA that has
already sold a large number (thousands, millions) of prepaid 3 year
contracts based on the assumption that validation costs would be
incurred by the CA only once during the contract period.

As I have noted elsewhere, at least one major CA (GlobalSign) has a
contract structure and issuance practice which assumes that the
validity of validation information is at least as long as the
certificate validity period. Thus for any 3-year GlobalSign
certificate issued in the past 2 years, GlobalSign would have already
promised the cert holders that the work and costs of doing certificate
validation had been fully completed at the time when payment was
collected.

This is all because the allowed validity of validation information is
being retroactively shortened within that validity period. It would
not have occurred if the shorter validity period of validity
information only applied to validity information gathered after a
deadline that isn't in the extremely near future (If someone orders an
OV cert *today* and pays *todays* price, the validation might not
complete until next week).

At least this needs to be considered when doing the next reduction (if any).

> Mozilla is interested in, and the CAB Forum continues to discuss, the
> possibility of further reductions in certificate lifetime. We see a
> benefit here in reducing the overall turnover time it takes for an
> improvement in practices or algorithms to make its way through the
> entire WebPKI. Shorter times, carefully managed, also encourage the
> ecosystem towards automation, which is beneficial when quick changes
> need to be made in response to security incidents. Specifically, Mozilla
> is currently considering a reduction to 13 months, effective as of 1st
> March 2019 (2 years from now). Alternatively, several CAs have said that
> the need for contract renegotiation is a significant issue when reducing
> lifetimes, so in order that CAs will only have to do this once rather
> than twice, another option would be to require the reduction from 1st
> March 2018 (1 year from now), the current reduction date.
>
> Please explain whether you would support such a further reduction dated
> to one or both of those dates and, if not, what specifically prevents
> you from lending your support to such a move. You may wish to reference
> the discussion on the CAB Forum public mailing list to familiarise
> yourself with the detailed arguments in favour of certificate lifetime
> reduction.
>

Note that it is very common for all the underlying validity information
to be fixed for 2 or more years (for example domain registrations,
company registrations etc.), providing little reason to impose the
inconvenience and cost of short certificate lifespans onto every
ongoing business and every personal website on the planet.

[Ryan Sleevi]

On Tue, Mar 28, 2017 at 8:52 AM, Jakob Bohm via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

>
> While this has apparently already passed, the earlier date for
> requiring revalidation is going to be a problem for any CA that has
> already sold a large number (thousands, millions) of prepaid 3 year
> contracts based on the assumption that validation costs would be
> incurred by the CA only once during the contract period.
>

It's unclear to me the point you're trying to make with this comment, so
I'm hoping you can expand. It sounds like you're just making a position
statement, and not asking Mozilla to change or reconsider anything that was
already considered. Is that a correct understanding?

That is, given that Gerv is asking for feedback, it's unclear whether
you're offering the feedback for change, or just making statements. Given
that you're talking about "future consideration", it sounds like that's
best directed to the CA/Browser Forum, and given that the CAs affected
voted in favour of it, it doesn't sound like they agree with your analysis,
but I could be mistaken.

> Note that it is very common for all the underlying validity information
> to be fixed for 2 or more years (for example domain registrations,
> company registrations etc.), providing little reason to impose the
> inconvenience and cost of short certificate lifespans onto every
> ongoing business and every personal website on the planet.

I think including domain registrations in that would be a stretch that
borderlines inaccurate, and thus while it may impose some degree of
inconvenience over the status quo, it will also significantly improve
security.

While a domain may be registered for a number of years, there's no
guarantee as to the frequency of that information being updated, and
there's no guarantee that the domain holder's contact information won't
change during the operation, thus there is a great benefit for ensuring
it's revalidated.

To the general point that different aspects of different information
require different revalidation periods, I'm on record in the CA/Browser
Forum as agreeing with that sentiment, as my goal with 186 is
post-readoption of the 169/182 methods of validation, the lifetime of reuse
will be appropriately scoped to the method used to validate that
information.

[Jakob Bohm]

On 28/03/2017 15:20, Ryan Sleevi wrote:
> On Tue, Mar 28, 2017 at 8:52 AM, Jakob Bohm via dev-security-policy <
> dev-secur...@lists.mozilla.org> wrote:
>
>>
>> While this has apparently already passed, the earlier date for
>> requiring revalidation is going to be a problem for any CA that has
>> already sold a large number (thousands, millions) of prepaid 3 year
>> contracts based on the assumption that validation costs would be
>> incurred by the CA only once during the contract period.
>>
>
> It's unclear to me the point you're trying to make with this comment, so
> I'm hoping you can expand. It sounds like you're just making a position
> statement, and not asking Mozilla to change or reconsider anything that was
> already considered. Is that a correct understanding?
>
> That is, given that Gerv is asking for feedback, it's unclear whether
> you're offering the feedback for change, or just making statements. Given
> that you're talking about "future consideration", it sounds like that's
> best directed to the CA/Browser Forum, and given that the CAs affected
> voted in favour of it, it doesn't sound like they agree with your analysis,
> but I could be mistaken.
>
>

For this part, I am only making a position statement as it seems the
CAB/F has already voted and passed the rules as stated.

>> Note that it is very common for all the underlying validity information
>> to be fixed for 2 or more years (for example domain registrations,
>> company registrations etc.), providing little reason to impose the
>> inconvenience and cost of short certificate lifespans onto every
>> ongoing business and every personal website on the planet.
>
>
> I think including domain registrations in that would be a stretch that
> borderlines inaccurate, and thus while it may impose some degree of
> inconvenience over the status quo, it will also significantly improve
> security.
>
> While a domain may be registered for a number of years, there's no
> guarantee as to the frequency of that information being updated, and
> there's no guarantee that the domain holder's contact information won't
> change during the operation, thus there is a great benefit for ensuring
> it's revalidated.
>
> To the general point that different aspects of different information
> require different revalidation periods, I'm on record in the CA/Browser
> Forum as agreeing with that sentiment, as my goal with 186 is
> post-readoption of the 169/182 methods of validation, the lifetime of reuse
> will be appropriately scoped to the method used to validate that
> information.
>

In principle any source of information could change just one minute
later. A domain could be sold, a company could declare bankruptcy, a
personal domain owner could die.

For smaller organizations (i.e. not Google), requesting and deploying
new certificates every few years is a real hassle, and often a
non-trivial expense. Forcing the paid, carefully validated
certificates to be repurchased and reinstalled a lot more often imposes
a real burden on real websites and real e-mail accounts.

The previous CAB/F rule of 3 years max seemed to be a useful
compromise, only slightly more difficult than the old 5 year offering
from some CAs, and well within reason as to handling the frequency of
ordinary changes in domain and company ownership/status that occur in
the real world.

The somewhat sudden (to outsiders) tendency to force frequent
certificate replacements for those not using "Let's encrypt" seems
arbitrary, harmful and mostly pointless.

It should also be noted, that many countries have services that a CA
could subscribe to in order to be alerted to changes in validated
information, such as whois changes, company closures, changes of
address etc.

[Ryan Sleevi]

On Tue, Mar 28, 2017 at 10:00 AM, Jakob Bohm via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> In principle any source of information could change just one minute
> later. A domain could be sold, a company could declare bankruptcy, a
> personal domain owner could die.
>

Yup. And we balance the usability tradeoff.

> For smaller organizations (i.e. not Google), requesting and deploying
> new certificates every few years is a real hassle,

And that's a bug and needs to change. Plain and simple, that doesn't work
for security. But perhaps we're getting further off-topic, other than I
think the crux of your objection is that "Replacing certificates is hard",
when the reality is we should be striving to replace certificate every 90
days or less, and work to address the systemic and organizational issues
that prevent this.

> and often a
> non-trivial expense. Forcing the paid, carefully validated
> certificates to be repurchased and reinstalled a lot more often imposes
> a real burden on real websites and real e-mail accounts.
>
> The previous CAB/F rule of 3 years max seemed to be a useful
> compromise, only slightly more difficult than the old 5 year offering
> from some CAs, and well within reason as to handling the frequency of
> ordinary changes in domain and company ownership/status that occur in
> the real world.
>

Unfortunately, that's long been held as undesirably long by browser
members, based on the surveys for several years. Unfortunately, CAs have
not been terribly interested in aligning this.

> The somewhat sudden (to outsiders) tendency to force frequent
> certificate replacements for those not using "Let's encrypt" seems
> arbitrary, harmful and mostly pointless.

Right, I think this philosophical difference - one in which I very much
think is actively harmful to security, even though I think it's a totally
understandable and reasonable position for you to hold - is perhaps the
crux of the objection on validating information. And that's useful to
acknowledge up front, and since we've arguably beat this horse to death,
acknowledge that it's merely a position statement being provided, and the
philosophical differences mean it's unlikely for everyone to be happy.

[Jakob Bohm]

Just because you happen to disagree doesn't make it an invalid point to
make when someone explicitly asks if it would be a good idea to lower
the max to 1 year *before* the "bug" of certificate deployment being
hard has been fixed.

While some parts of the "bug" are about tools and instructions (I have
posted some suggestions to help in that area), there are fundamental
intractable parts:

1. Strong validation *by necessity* must involve interacting with high
ranking humans in ways that are sufficiently non-trivial to avoid
being faked by phishing attacks.

2. Securely generating and deploying private keys for new certificates,
and securely ensuring the right private key is used in a non-ACME
certificate request (of any form), *necessarily* involves non-trivial
security procedures on the part of the certificate holder.

[Kathleen Wilson]

I have moved the draft of the April 2017 CA Communication to production, so the link has changed to:

https://mozillacaprogram.secure.force.com/Communications/CACommunicationSurveySample?CACommunicationId=a05o000003WrzBC

It is also available here:
https://wiki.mozilla.org/CA:Communications#April_2017

Note to CAs: The survey is now visible in the CCADB via the "CA Communications (Page)" tab, but DO NOT TAKE THE SURVEY YET. You will not be able to submit your survey answers until I update the "Expiration Date" to a date in the future. I will do this when the survey is ready to be sent.


Notable changes in this version:

1) Added free text Comments boxes to many of the action items.

2) Added ACTION 14: CERTIFICATE VALIDITY PERIODS IN TLS/SSL CERTS

3) Updated the last two bullet points in ACTION 5...
+ The word "clean" must be included in audit statements for which no problems were noted.
+ For ETSI - the attestation should additionally state that the audit was a full audit, and must indicate which parts of the criteria applied (e.g. DVCP, OVCP, NCP, NCP+, LCP, EVCP, EVCP+, QCP-w, Part1 (General Requirements), Part 2 (Requirements for trust services Providers issuing EU qualified certificates)).

4) Moved the "respond by" date to April 28.


Please let me know asap if you see any problems, typos, etc. in this version.

I would like to send this CA Communication next week.

Thanks,
Kathleen

[Gervase Markham]

On 31/03/17 22:20, Kathleen Wilson wrote:
> Please let me know asap if you see any problems, typos, etc. in this
> version.

Now that policy 2.4.1 has been published, we should update Action 3 to
say the following at the top:

Versions 2.4 and 2.4.1 of Mozilla's CA Certificate Policy have been
published. Differences <a>between 2.4 and 2.3</a> (published Dec 2016),
and <a>between 2.4 and 2.2</a> (published July 2013) may be viewed on
Github. Version 2.4.1 contains exactly the same normative requirements
as version 2.4 but has been completely reorganized. Please review
version 2.4.1 policy and confirm that your CA complies with it.


And then change the "2.4" to "2.4 or 2.4.1" underneath the bullet points.

Other than that, LGTM - ship it :-)

Gerv

[Kathleen Wilson]

On Saturday, April 1, 2017 at 3:59:28 AM UTC-7, Gervase Markham wrote:
> On 31/03/17 22:20, Kathleen Wilson wrote:
> > Please let me know asap if you see any problems, typos, etc. in this
> > version.
>
> Now that policy 2.4.1 has been published, we should update Action 3 to
> say the following at the top:
>
> Versions 2.4 and 2.4.1 of Mozilla's CA Certificate Policy have been
> published. Differences <a>between 2.4 and 2.3</a> (published Dec 2016),
> and <a>between 2.4 and 2.2</a> (published July 2013) may be viewed on
> Github. Version 2.4.1 contains exactly the same normative requirements
> as version 2.4 but has been completely reorganized. Please review
> version 2.4.1 policy and confirm that your CA complies with it.
>
>

https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/
still shows version 2.4. Shall I wait until it shows version 2.4.1 before I send the CA Communication?

Kathleen

[Kathleen Wilson]

On Monday, April 3, 2017 at 10:13:22 AM UTC-7, Kathleen Wilson wrote:
> https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/
> still shows version 2.4.

It's been updated to version 2.4.1.

Thanks,
Kathleen

[Kathleen Wilson]

All,

I'm getting ready to send the April 2017 CA Communication email.

I updated the wiki page to have the survey introduction text, and a (read-only) link to the full survey:
https://wiki.mozilla.org/CA:Communications#April_2017

The survey in the Common CA Database is now open, with an expiration date of May 1.

The text for the mass email is ready (see below). I have it set to be sent to the CA's email alias and CC'd to the Primary Points of Contact for each CA currently included in Mozilla's program.


== Email Text ==
Subject: Mozilla CA Communication: Action requested by April 28, 2017

Message:

Dear Certification Authority,

This email requests a set of actions on your behalf, as a participant in Mozilla's CA Certificate Program, by April 28, 2017.

Please login to the Common CA Database, click on the 'CA Communications (Page)' tab, select the 'April 2017 CA Communication' survey, and submit your initial response by April 28, 2017.

Reference: https://wiki.mozilla.org/CA:CommonCADatabase

A compiled list of CA responses to the survey action items will be automatically and immediately published by the Common CA Database here:
https://wiki.mozilla.org/CA:Communications

In addition to responding to the action items in this survey, we are instituting a program requirement that you follow discussions in the mozilla.dev.security.policy forum, which includes discussions about upcoming changes to Mozilla's CA Certificate Policy, questions and clarification about policy and expectations, root certificate inclusion/change requests, and certificates that are found to be non-compliant with the CA/Browser Forum's Baseline Requirements or other program requirements. You are not required to contribute to those discussions, only to be aware of them. However, we hope you will participate and help shape the future of Mozilla's CA Certificate Program.

Participation in Mozilla's CA Certificate Program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you for your cooperation in this pursuit.

Regards,

Kathleen Wilson
Mozilla CA Program Manager
===

[Kathleen Wilson]

On Monday, April 3, 2017 at 2:21:14 PM UTC-7, Kathleen Wilson wrote:
> All,
>
> I'm getting ready to send the April 2017 CA Communication email.
>
> I updated the wiki page to have the survey introduction text, and a (read-only) link to the full survey:
> https://wiki.mozilla.org/CA:Communications#April_2017
>
> The survey in the Common CA Database is now open, with an expiration date of May 1.
>
> The text for the mass email is ready (see below). I have it set to be sent to the CA's email alias and CC'd to the Primary Points of Contact for each CA currently included in Mozilla's program.
>

The email has been sent, and the survey is open.

Kathleen

[Kathleen Wilson]

On Tuesday, April 4, 2017 at 10:38:28 AM UTC-7, Kathleen Wilson wrote:
>
> The email has been sent, and the survey is open.
>

Published a security blog about it:
https://blog.mozilla.org/security/2017/04/04/mozilla-releases-version-2-4-ca-certificate-policy/

Cheers,
Kathleen

[Doug Beattie]

Kathleen,

Can you explain how policy 2.4 applies to existing CAs with respect to being Technically Constrained?

This is my understanding:
- Under policy 2.3 a CA that is technically constrained with EKU set to only secure email but without name constraints was considered out of scope of the Mozilla Policy.
- Policy 2.4.1 adds a requirement that for the CA to be out of scope of the Mozilla policy the CA needs to have name constraints if the CA is capable of issuing secure email certificates.

Is this accurate? If so, when does this new requirement apply to existing CAs?

Doug


> -----Original Message-----
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+doug.beattie=globals...@lists.mozilla.org] On Behalf Of Kathleen
> Wilson via dev-security-policy
> Sent: Tuesday, April 4, 2017 4:13 PM
> To: mozilla-dev-s...@lists.mozilla.org
> Subject: Re: Next CA Communication

>
> On Tuesday, April 4, 2017 at 10:38:28 AM UTC-7, Kathleen Wilson wrote:
> >
> > The email has been sent, and the survey is open.
> >
>
>

> Published a security blog about it:
> https://blog.mozilla.org/security/2017/04/04/mozilla-releases-version-2-4-ca-
> certificate-policy/
>
> Cheers,
> Kathleen

[Gervase Markham]

Hi Doug,

Kathleen is unavailable this week, so I'll try and answer. (This might
have been better as a new top-level post, though...)

On 11/04/17 21:14, Doug Beattie wrote:
> This is my understanding:
>
> - Under policy 2.3 a CA that is technically
> constrained with EKU set to only secure email but without name
> constraints was considered out of scope of the Mozilla Policy.

Which parts of policy 2.3 lead you to that conclusion?
https://github.com/mozilla/pkipolicy/blob/2.3/rootstore/policy.md

2.3 does not have an explicit scope statement, something we fixed in 2.4.

Policy 2.3, Application section, bullet 9, defines rules for technically
constrained certificates, including a section giving rules for certs
issued by technically constrained email sub-CAs. How do you then see
these as out of scope?

> - Policy 2.4.1 adds a requirement that for the CA to be out of scope of
> the Mozilla policy the CA needs to have name constraints if the CA is
> capable of issuing secure email certificates.

Which parts of policy 2.4.1 lead you to that conclusion?
https://github.com/mozilla/pkipolicy/blob/2.4.1/rootstore/policy.md

Section 1.1.2 of 2.4.1 says that sub-CAs are included in the overall
scope statement. There are two ways to be exempted - not be capable of
issuing email certificates, or be name-constrained. So I assume you are
referring to 1.1.2, bullet 2. But this says that to be exempted, you
need to be not issuing any form of rfc822Name - in other words, it's a
way of turning off email entirely using a different technical mechanism.
This bullet is not met if you have name constraints which restrict you
to particular email domains.

So I would say that an email-only sub-CA which is name-constrained to
certain domains is currently still in scope. And, indeed, section 5.3.1
is the new analogue of the old Application section, bullet 9 mentioned
above, and contains the same language governing certs issued by
technically constrained email-only sub-CAs.

Of course, this is all related to:
https://github.com/mozilla/pkipolicy/issues/36
:-)

Gerv

[Doug Beattie]

> -----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, April 12, 2017 4:45 AM
> To: mozilla-dev-s...@lists.mozilla.org

> > - Under policy 2.3 a CA that is technically constrained with EKU set
> > to only secure email but without name constraints was considered out
> > of scope of the Mozilla Policy.
>

> Which parts of policy 2.3 lead you to that conclusion?
> https://github.com/mozilla/pkipolicy/blob/2.3/rootstore/policy.md

In 3.2 the term Technically Constrained is not defined to be any different than the BRs (or perhaps even less restrictive). In 3.2 this is all I can find regarding CAs that are capable of signing secure email certificates, section 9:
"If the certificate includes the id-kp-emailProtection extended key usage, then all end-entity certificates MUST only include e-mail addresses or mailboxes that the issuing CA has confirmed (via technical and/or business controls) that the subordinate CA is authorized to use."

There is no statement back to scope or corresponding audits. Were secure email capable CAs supposed to be disclosed and audited to Mozilla under 2.3? Section 8 implies that if it's technically constrained then it does not need to be disclosed and audited:
"All certificates that are capable of being used to issue new certificates, and which directly or transitively chain to a certificate included in Mozilla's CA Certificate Program, MUST be operated in accordance with Mozilla's CA Certificate Policy and MUST either be technically constrained or be publicly disclosed and audited." Combine this with the definition, or lack thereof, of TCSC and how it applies to Secure email, I don't see how TCSCs with secure email EKU fall within the scope of the Mozilla Policy 2.3. Can you help clarify?

> 2.3 does not have an explicit scope statement, something we fixed in 2.4.
>
> Policy 2.3, Application section, bullet 9, defines rules for technically constrained
> certificates, including a section giving rules for certs issued by technically
> constrained email sub-CAs. How do you then see these as out of scope?

The definition of Technically Constrained in this policy does not apply to secure email certificates, as far as I can determine. It just says you need an EKU and is must not be anyExtendedKeyUsage. This is actually less restrictive than the BR definition.

> > - Policy 2.4.1 adds a requirement that for the CA to be out of scope
> > of the Mozilla policy the CA needs to have name constraints if the CA
> > is capable of issuing secure email certificates.
>

> Which parts of policy 2.4.1 lead you to that conclusion?
> https://github.com/mozilla/pkipolicy/blob/2.4.1/rootstore/policy.md
>

OK, you're right, the number of negatives in that section got me. So, even when EKU permits just secure email, having name constraints does not exempt a CA from the Mozilla policy. It does for BRs since email is not within scope (and discussed on the link you included in the response). When I saw TCSC references I personally didn't realize that this was different than the BR definition of TCSC (maybe should have called this something different).

Section 3.1.2.1 specifies that any CA capable of issuing secure email certificates must have a "WebTrust for CAs" audit (or corresponding ETSI audit). This is a huge change from 3.2 and I wonder if all CAs understand this. Even the Blog about this version does not highlight this substantial change:
https://blog.mozilla.org/security/2017/04/04/mozilla-releases-version-2-4-ca-certificate-policy/

Obviously there are a lot of technically constrained CAs issued to organizations to run their own CAs for issuing secure email and client auth certificates. In order for them to continue operations they now every organization needs to be publicly reported and audited (a new requirement for 2.4.1 as far as I can tell), is that right?

When did (does) this take effect? Is this for new CAs, existing or both? When would the Audit Period for these CAs need to begin?

This is a side question, but does the Mozilla policy require that these CAs meet the Network Security Requirements?

> Section 1.1.2 of 2.4.1 says that sub-CAs are included in the overall scope
> statement. There are two ways to be exempted - not be capable of issuing email
> certificates, or be name-constrained. So I assume you are referring to 1.1.2,
> bullet 2. But this says that to be exempted, you need to be not issuing any form
> of rfc822Name - in other words, it's a way of turning off email entirely using a
> different technical mechanism.
> This bullet is not met if you have name constraints which restrict you to
> particular email domains.
>
> So I would say that an email-only sub-CA which is name-constrained to certain
> domains is currently still in scope. And, indeed, section 5.3.1 is the new
> analogue of the old Application section, bullet 9 mentioned above, and contains
> the same language governing certs issued by technically constrained email-only
> sub-CAs.

Section 5.3.2 says that all CAs of the type I'm discussing must be in the CCADB. What's the timeline for CAs to upload them?

> Of course, this is all related to:
> https://github.com/mozilla/pkipolicy/issues/36
> :-)
>
> Gerv

[Gervase Markham]

On 13/04/17 14:23, Doug Beattie wrote:
> In 3.2 the term Technically Constrained is not defined to be any
> different than the BRs (or perhaps even less restrictive).

You mean 2.3, right?

I would say Inclusion section, bullet 9 gives the definition of
technically constrained. For email certs, because of the bug described
in issue #69, it basically just says that it has to have the
id-kp-emailProtection EKU. It should say more, but it doesn't. That's
problematic, because just having an EKU isn't really a technical
constraint in the "TCSC" sense.

> In 3.2
> this is all I can find regarding CAs that are capable of signing
> secure email certificates, section 9: "If the certificate includes
> the id-kp-emailProtection extended key usage, then all end-entity
> certificates MUST only include e-mail addresses or mailboxes that the
> issuing CA has confirmed (via technical and/or business controls)
> that the subordinate CA is authorized to use."
>
> There is no statement back to scope or corresponding audits. Were
> secure email capable CAs supposed to be disclosed and audited to
> Mozilla under 2.3?

If they did not include id-kp-serverAuth, I would not have faulted a CA
for not disclosing them if they met the exclusion criteria for email
certs as written.

> and how it applies to Secure email, I don't see how TCSCs with secure
> email EKU fall within the scope of the Mozilla Policy 2.3. Can you
> help clarify?

I think this is basically issue #69.
https://github.com/mozilla/pkipolicy/issues/69

I don't think it was supposed to be the case that intermediates with
id-kp-emailProtection alone were supposed to be considered TCSCs. After
all, certs with id-kp-serverAuth alone are not TCSCs; they need to have
Name Constraints as well. But you are right, that's what the policy says.

> OK, you're right, the number of negatives in that section got me.
> So, even when EKU permits just secure email, having name constraints
> does not exempt a CA from the Mozilla policy. It does for BRs since
> email is not within scope (and discussed on the link you included in
> the response). When I saw TCSC references I personally didn't
> realize that this was different than the BR definition of TCSC (maybe
> should have called this something different).
>
> Section 3.1.2.1 specifies that any CA capable of issuing secure email
> certificates must have a "WebTrust for CAs" audit (or corresponding
> ETSI audit). This is a huge change from 3.2 and I wonder if all CAs
> understand this. Even the Blog about this version does not highlight
> this substantial change:
> https://blog.mozilla.org/security/2017/04/04/mozilla-releases-version-2-4-ca-certificate-policy/

I didn't realise it _was_ a substantial change. Are you saying that you
used to think it was fine for email-only sub-CAs to have no audits at
all? Is this because you considered all such CAs to be TCSCs (by the
Mozilla definition)?

Even if we didn't require it in our policy, I'm very surprised that
no-one else does. Which other root store policies have requirements on
email-only sub-CAs?

> Obviously there are a lot of technically constrained CAs issued to
> organizations to run their own CAs for issuing secure email and
> client auth certificates. In order for them to continue operations
> they now every organization needs to be publicly reported and audited
> (a new requirement for 2.4.1 as far as I can tell), is that right?

This is issue #36 :-)
https://github.com/mozilla/pkipolicy/issues/36

Do the CAs you are thinking of in this category have name constraints,
or not (either actually in the cert, or via business controls)?

> When did (does) this take effect? Is this for new CAs, existing or
> both? When would the Audit Period for these CAs need to begin?
>
> This is a side question, but does the Mozilla policy require that
> these CAs meet the Network Security Requirements?

https://github.com/mozilla/pkipolicy/issues/70 :-) Not at the moment.

> Section 5.3.2 says that all CAs of the type I'm discussing must be in
> the CCADB. What's the timeline for CAs to upload them?

Well, let's figure out what the right thing to do is first. If it turns
out we've created new normative requirements accidentally, the first
thing to do is to decide whether that's what we meant. Only then will we
set some sort of sane implementation timeline.

Gerv

[Ryan Sleevi]

On Thu, Apr 13, 2017 at 10:48 AM, Gervase Markham via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

>
> > Section 3.1.2.1 specifies that any CA capable of issuing secure email
> > certificates must have a "WebTrust for CAs" audit (or corresponding
> > ETSI audit). This is a huge change from 3.2 and I wonder if all CAs
> > understand this. Even the Blog about this version does not highlight
> > this substantial change:
> > https://blog.mozilla.org/security/2017/04/04/mozilla-
> releases-version-2-4-ca-certificate-policy/
>

> I didn't realise it _was_ a substantial change. Are you saying that you
> used to think it was fine for email-only sub-CAs to have no audits at
> all? Is this because you considered all such CAs to be TCSCs (by the
> Mozilla definition)?
>
> Even if we didn't require it in our policy, I'm very surprised that
> no-one else does. Which other root store policies have requirements on
> email-only sub-CAs?
>

https://social.technet.microsoft.com/wiki/contents/articles/31635.microsoft-trusted-root-certificate-program-audit-requirements.aspx
(aka http://aka.ms/auditreqs)

S/MIME trust bit requires either "WebTrust Principles and Criteria for
Certification Authorities - WebTrust for CAs 2.0" or the combination of the
following: "WebTrust Principles and Criteria for Certification Authorities
- WebTrust for CAs 2.0" "ETSI TS 102 042 V2.4.1 or later (LCP, NCP, NCP+
policies) - Electronic Signatures and Infrastructures (ESI); Policy
requirements for certification authorities issuing public key certificates"
and "ETSI TS 101 456 V1.4.3 or later - Electronic Signatures and
Infrastructure (ESI); Policy requirements for certification authorities
issuing qualified certificates"

>
> > Obviously there are a lot of technically constrained CAs issued to
> > organizations to run their own CAs for issuing secure email and
> > client auth certificates. In order for them to continue operations
> > they now every organization needs to be publicly reported and audited
> > (a new requirement for 2.4.1 as far as I can tell), is that right?
>

> This is issue #36 :-)
> https://github.com/mozilla/pkipolicy/issues/36
>
> Do the CAs you are thinking of in this category have name constraints,
> or not (either actually in the cert, or via business controls)?
>

> > When did (does) this take effect? Is this for new CAs, existing or
> > both? When would the Audit Period for these CAs need to begin?
> >
> > This is a side question, but does the Mozilla policy require that
> > these CAs meet the Network Security Requirements?
>

> https://github.com/mozilla/pkipolicy/issues/70 :-) Not at the moment.
>

> > Section 5.3.2 says that all CAs of the type I'm discussing must be in
> > the CCADB. What's the timeline for CAs to upload them?
>

> Well, let's figure out what the right thing to do is first. If it turns
> out we've created new normative requirements accidentally, the first
> thing to do is to decide whether that's what we meant. Only then will we
> set some sort of sane implementation timeline.
>

[douglas...@gmail.com]

On Thursday, April 13, 2017 at 10:49:17 AM UTC-4, Gervase Markham wrote:
> On 13/04/17 14:23, Doug Beattie wrote:
> > In 3.2 the term Technically Constrained is not defined to be any
> > different than the BRs (or perhaps even less restrictive).
>
> You mean 2.3, right?

Yes, 2.3.

> I would say Inclusion section, bullet 9 gives the definition of
> technically constrained. For email certs, because of the bug described
> in issue #69, it basically just says that it has to have the
> id-kp-emailProtection EKU. It should say more, but it doesn't. That's
> problematic, because just having an EKU isn't really a technical
> constraint in the "TCSC" sense.
>
> > In 3.2
> > this is all I can find regarding CAs that are capable of signing
> > secure email certificates, section 9: "If the certificate includes
> > the id-kp-emailProtection extended key usage, then all end-entity
> > certificates MUST only include e-mail addresses or mailboxes that the
> > issuing CA has confirmed (via technical and/or business controls)
> > that the subordinate CA is authorized to use."
> >
> > There is no statement back to scope or corresponding audits. Were
> > secure email capable CAs supposed to be disclosed and audited to
> > Mozilla under 2.3?
>
> If they did not include id-kp-serverAuth, I would not have faulted a CA
> for not disclosing them if they met the exclusion criteria for email
> certs as written.

OK.

> > and how it applies to Secure email, I don't see how TCSCs with secure
> > email EKU fall within the scope of the Mozilla Policy 2.3. Can you
> > help clarify?
>
> I think this is basically issue #69.
> https://github.com/mozilla/pkipolicy/issues/69

OK, I look forward to a conclusion on that. I hope that name constraining a secure email CA (either technically in the CA certificate or via business controls) is sufficient to avoid WebTrust Audits. If Public disclosure helps get us there then that would be acceptable.

> I don't think it was supposed to be the case that intermediates with
> id-kp-emailProtection alone were supposed to be considered TCSCs. After
> all, certs with id-kp-serverAuth alone are not TCSCs; they need to have
> Name Constraints as well. But you are right, that's what the policy says.
>
> > OK, you're right, the number of negatives in that section got me.
> > So, even when EKU permits just secure email, having name constraints
> > does not exempt a CA from the Mozilla policy. It does for BRs since
> > email is not within scope (and discussed on the link you included in
> > the response). When I saw TCSC references I personally didn't
> > realize that this was different than the BR definition of TCSC (maybe
> > should have called this something different).
> >
> > Section 3.1.2.1 specifies that any CA capable of issuing secure email
> > certificates must have a "WebTrust for CAs" audit (or corresponding
> > ETSI audit). This is a huge change from 3.2 and I wonder if all CAs
> > understand this. Even the Blog about this version does not highlight
> > this substantial change:
> > https://blog.mozilla.org/security/2017/04/04/mozilla-releases-version-2-4-ca-certificate-policy/
>
> I didn't realise it _was_ a substantial change. Are you saying that you
> used to think it was fine for email-only sub-CAs to have no audits at
> all? Is this because you considered all such CAs to be TCSCs (by the
> Mozilla definition)?

Yes, we've been working hard to technically constrain all CAs and especially those operated outside of our infrastructure. We've been following the BR definition: Include EKUs in all CAs, and for those that include server auth or secure email, include name constraints.

> Even if we didn't require it in our policy, I'm very surprised that
> no-one else does. Which other root store policies have requirements on
> email-only sub-CAs?

Not that I know of.

> > Obviously there are a lot of technically constrained CAs issued to
> > organizations to run their own CAs for issuing secure email and
> > client auth certificates. In order for them to continue operations
> > they now every organization needs to be publicly reported and audited
> > (a new requirement for 2.4.1 as far as I can tell), is that right?
>
> This is issue #36 :-)
> https://github.com/mozilla/pkipolicy/issues/36
>
> Do the CAs you are thinking of in this category have name constraints,
> or not (either actually in the cert, or via business controls)?

Yes - they are all either name constrained either via the certificate name constraints or via business controls.

> > When did (does) this take effect? Is this for new CAs, existing or
> > both? When would the Audit Period for these CAs need to begin?
> >
> > This is a side question, but does the Mozilla policy require that
> > these CAs meet the Network Security Requirements?
>
> https://github.com/mozilla/pkipolicy/issues/70 :-) Not at the moment.

OK

> > Section 5.3.2 says that all CAs of the type I'm discussing must be in
> > the CCADB. What's the timeline for CAs to upload them?
>
> Well, let's figure out what the right thing to do is first. If it turns
> out we've created new normative requirements accidentally, the first
> thing to do is to decide whether that's what we meant. Only then will we
> set some sort of sane implementation timeline.

Thanks Gerv.

> Gerv

[Peter Bowen]

On Thu, Apr 13, 2017 at 9:33 AM, douglas.beattie--- via
dev-security-policy <dev-secur...@lists.mozilla.org> wrote:
> On Thursday, April 13, 2017 at 10:49:17 AM UTC-4, Gervase Markham wrote:

>> On 13/04/17 14:23, Doug Beattie wrote:
>> > There is no statement back to scope or corresponding audits. Were
>> > secure email capable CAs supposed to be disclosed and audited to
>> > Mozilla under 2.3?
>>
>> If they did not include id-kp-serverAuth, I would not have faulted a CA
>> for not disclosing them if they met the exclusion criteria for email
>> certs as written.
>

> OK.

>
>> > and how it applies to Secure email, I don't see how TCSCs with secure
>> > email EKU fall within the scope of the Mozilla Policy 2.3. Can you
>> > help clarify?
>>
>> I think this is basically issue #69.
>> https://github.com/mozilla/pkipolicy/issues/69
>

> OK, I look forward to a conclusion on that. I hope that name constraining a secure email CA (either technically in the CA certificate or via business controls) is sufficient to avoid WebTrust Audits. If Public disclosure helps get us there then that would be acceptable.

Should the Mozilla policy change to require disclosure of all CA
certificates issued by an unconstrained CA (but not necessarily
require audits, CP/CPS, etc)? This would help identify unintentional
gaps in policy.

Thanks,
Peter

[Rob Stradling]

On 15/04/17 17:05, Peter Bowen via dev-security-policy wrote:
> On Thu, Apr 13, 2017 at 9:33 AM, douglas.beattie--- via
> dev-security-policy <dev-secur...@lists.mozilla.org> wrote:
>> On Thursday, April 13, 2017 at 10:49:17 AM UTC-4, Gervase Markham wrote:

>>> On 13/04/17 14:23, Doug Beattie wrote:
>>>> There is no statement back to scope or corresponding audits. Were
>>>> secure email capable CAs supposed to be disclosed and audited to
>>>> Mozilla under 2.3?
>>>
>>> If they did not include id-kp-serverAuth, I would not have faulted a CA
>>> for not disclosing them if they met the exclusion criteria for email
>>> certs as written.
>>

>> OK.

>>
>>>> and how it applies to Secure email, I don't see how TCSCs with secure
>>>> email EKU fall within the scope of the Mozilla Policy 2.3. Can you
>>>> help clarify?
>>>
>>> I think this is basically issue #69.
>>> https://github.com/mozilla/pkipolicy/issues/69
>>

>> OK, I look forward to a conclusion on that. I hope that name constraining a secure email CA (either technically in the CA certificate or via business controls) is sufficient to avoid WebTrust Audits. If Public disclosure helps get us there then that would be acceptable.
>
> Should the Mozilla policy change to require disclosure of all CA
> certificates issued by an unconstrained CA (but not necessarily
> require audits, CP/CPS, etc)? This would help identify unintentional
> gaps in policy.

+1

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

[Gervase Markham]

On 15/04/17 17:05, Peter Bowen wrote:
> Should the Mozilla policy change to require disclosure of all CA
> certificates issued by an unconstrained CA (but not necessarily
> require audits, CP/CPS, etc)? This would help identify unintentional
> gaps in policy.

https://github.com/mozilla/pkipolicy/issues/73

I think I understand your point but if you could expand a bit in the
bug, that would be most welcome.

Gerv

[Peter Bowen]

(Resending as the attached file was too large)

On Fri, May 5, 2017 at 10:46 AM, Peter Bowen <pzb...@gmail.com> wrote:

> On Thu, Apr 20, 2017 at 3:01 AM, Gervase Markham via
> dev-security-policy <dev-secur...@lists.mozilla.org> wrote:
>> On 15/04/17 17:05, Peter Bowen wrote:

>>> Should the Mozilla policy change to require disclosure of all CA
>>> certificates issued by an unconstrained CA (but not necessarily
>>> require audits, CP/CPS, etc)? This would help identify unintentional
>>> gaps in policy.
>>

>> https://github.com/mozilla/pkipolicy/issues/73
>>
>> I think I understand your point but if you could expand a bit in the
>> bug, that would be most welcome.
>

> Right now the policy does not require disclosure of CA-certificates
> that the CA deems are technically constrained. We have seen numerous
> cases where the CA misunderstood the rules or where the rules had
> unintentional gaps an disclosing the certificate as constrained will
> allow discovery of these problems. For example the current policy
> says "an Extended Key Usage (EKU) extension which does not contain
> either of the id-kp-serverAuth and id-kp-emailProtection EKUs" which
> means a certificate that has EKU extension with only the
> anyExtendedKeyUsage KeyPurposeId fall outside of the scope. This is
> obviously wrong, but would not be discovered today.
>
> The flow chart at https://imagebin.ca/v/3LRcaKW9t2Qt shows my proposal for disclosure; it is a
> revised version from the one I posted to the CA/Browser Forum list and
> depends on the same higher level workflow
> (https://cabforum.org/pipermail/public/attachments/20170430/0e692c4d/attachment-0002.png
> ).
>
> Thanks,
> Peter

[Gervase Markham]

On 05/05/17 18:58, Peter Bowen wrote:
>> Right now the policy does not require disclosure of CA-certificates
>> that the CA deems are technically constrained.

I believe this was made the case for some mix of the following reasons:

a) the CA did not want to reveal every customer it had;
b) this would significantly increase the volume of disclosure required;
c) we didn't think we needed to know about these.

>> We have seen numerous
>> cases where the CA misunderstood the rules or where the rules had
>> unintentional gaps an disclosing the certificate as constrained will
>> allow discovery of these problems. For example the current policy
>> says "an Extended Key Usage (EKU) extension which does not contain
>> either of the id-kp-serverAuth and id-kp-emailProtection EKUs" which
>> means a certificate that has EKU extension with only the
>> anyExtendedKeyUsage KeyPurposeId fall outside of the scope. This is
>> obviously wrong, but would not be discovered today.

Is it obviously wrong? Firefox doesn't respect anyEKU. OTOH, Kathleen
recently told me that she feels that because the Mozilla root store is
used by others, we should continue to keep anyEKU intermediates in
scope. But do you think Mozilla also needs to know about these for
Firefox/Thunderbird purposes? If so, why?

>> The flow chart at https://imagebin.ca/v/3LRcaKW9t2Qt shows my proposal for disclosure; it is a
>> revised version from the one I posted to the CA/Browser Forum list and
>> depends on the same higher level workflow

Apologies that your message got held up.

Looking at that flowchart:

* Does "Log certificate" mean "in CT"?
* The "Subject/Key list" is the list of intermediate certs which need to
be disclosed?
* This diagrem represents your proposal, not the status quo?

Gerv

[Doug Beattie]

Hi Gerv,

I wanted to get the latest Mozilla thoughts on the audit requirements for TCSCs based on the discussion we started last month. I understand the BR requirement if the CA can issue server auth certificates, this was discussed here:
https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/ZMUjQ6xHrDA/ySofsF_PAgAJ

For TCSCs that can issue secure email certs, what are the requirements in the new policy, 2.4? I think they were excluded from audit requirement before, but in the latest Mozilla policy these CAs need to have a WT for CA audit even if they are Name Constrained.

So here my questions:

Was this an intentional change?

Is the same true for TCSCs that can issue server auth certificates (even NC CAs need a webtrust for CA audit)?

Are previously issued TCSCs exempt, if not, when would the audit period for them start?

Do these CAs need to be publicly disclosed?

Related tickets:
https://github.com/mozilla/pkipolicy/issues/36

https://github.com/mozilla/pkipolicy/issues/69

> -----Original Message-----
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+doug.beattie=globals...@lists.mozilla.org] On Behalf Of

> douglas.beattie--- via dev-security-policy
> Sent: Thursday, April 13, 2017 12:33 PM
> To: mozilla-dev-s...@lists.mozilla.org

> Subject: Re: Email sub-CAs
>
> On Thursday, April 13, 2017 at 10:49:17 AM UTC-4, Gervase Markham wrote:

> > On 13/04/17 14:23, Doug Beattie wrote:
> > > In 3.2 the term Technically Constrained is not defined to be any
> > > different than the BRs (or perhaps even less restrictive).
> >
> > You mean 2.3, right?
>

> Yes, 2.3.

>
> > I would say Inclusion section, bullet 9 gives the definition of
> > technically constrained. For email certs, because of the bug described
> > in issue #69, it basically just says that it has to have the
> > id-kp-emailProtection EKU. It should say more, but it doesn't. That's
> > problematic, because just having an EKU isn't really a technical
> > constraint in the "TCSC" sense.
> >
> > > In 3.2
> > > this is all I can find regarding CAs that are capable of signing
> > > secure email certificates, section 9: "If the certificate includes
> > > the id-kp-emailProtection extended key usage, then all end-entity
> > > certificates MUST only include e-mail addresses or mailboxes that
> > > the issuing CA has confirmed (via technical and/or business
> > > controls) that the subordinate CA is authorized to use."
> > >
> > > There is no statement back to scope or corresponding audits. Were
> > > secure email capable CAs supposed to be disclosed and audited to
> > > Mozilla under 2.3?
> >
> > If they did not include id-kp-serverAuth, I would not have faulted a
> > CA for not disclosing them if they met the exclusion criteria for
> > email certs as written.
>

> OK.

>
> > > and how it applies to Secure email, I don't see how TCSCs with
> > > secure email EKU fall within the scope of the Mozilla Policy 2.3.
> > > Can you help clarify?
> >
> > I think this is basically issue #69.
> > https://github.com/mozilla/pkipolicy/issues/69
>

> OK, I look forward to a conclusion on that. I hope that name constraining a
> secure email CA (either technically in the CA certificate or via business
> controls) is sufficient to avoid WebTrust Audits. If Public disclosure helps get
> us there then that would be acceptable.
>

> > I don't think it was supposed to be the case that intermediates with
> > id-kp-emailProtection alone were supposed to be considered TCSCs.
> > After all, certs with id-kp-serverAuth alone are not TCSCs; they need
> > to have Name Constraints as well. But you are right, that's what the policy
> says.
> >
> > > OK, you're right, the number of negatives in that section got me.
> > > So, even when EKU permits just secure email, having name constraints
> > > does not exempt a CA from the Mozilla policy. It does for BRs since
> > > email is not within scope (and discussed on the link you included in
> > > the response). When I saw TCSC references I personally didn't
> > > realize that this was different than the BR definition of TCSC
> > > (maybe should have called this something different).
> > >
> > > Section 3.1.2.1 specifies that any CA capable of issuing secure
> > > email certificates must have a "WebTrust for CAs" audit (or
> > > corresponding ETSI audit). This is a huge change from 3.2 and I
> > > wonder if all CAs understand this. Even the Blog about this version
> > > does not highlight this substantial change:
> > > https://blog.mozilla.org/security/2017/04/04/mozilla-releases-versio
> > > n-2-4-ca-certificate-policy/
> >
> > I didn't realise it _was_ a substantial change. Are you saying that
> > you used to think it was fine for email-only sub-CAs to have no audits
> > at all? Is this because you considered all such CAs to be TCSCs (by
> > the Mozilla definition)?
>

> Yes, we've been working hard to technically constrain all CAs and especially
> those operated outside of our infrastructure. We've been following the BR
> definition: Include EKUs in all CAs, and for those that include server auth or
> secure email, include name constraints.
>

> > Even if we didn't require it in our policy, I'm very surprised that
> > no-one else does. Which other root store policies have requirements on
> > email-only sub-CAs?
>

> Not that I know of.
>

> > > Obviously there are a lot of technically constrained CAs issued to
> > > organizations to run their own CAs for issuing secure email and
> > > client auth certificates. In order for them to continue operations
> > > they now every organization needs to be publicly reported and
> > > audited (a new requirement for 2.4.1 as far as I can tell), is that right?
> >
> > This is issue #36 :-)
> > https://github.com/mozilla/pkipolicy/issues/36
> >
> > Do the CAs you are thinking of in this category have name constraints,
> > or not (either actually in the cert, or via business controls)?
>

> Yes - they are all either name constrained either via the certificate name
> constraints or via business controls.
>

> > > When did (does) this take effect? Is this for new CAs, existing or
> > > both? When would the Audit Period for these CAs need to begin?
> > >
> > > This is a side question, but does the Mozilla policy require that
> > > these CAs meet the Network Security Requirements?
> >
> > https://github.com/mozilla/pkipolicy/issues/70 :-) Not at the moment.
>

> OK

>
> > > Section 5.3.2 says that all CAs of the type I'm discussing must be
> > > in the CCADB. What's the timeline for CAs to upload them?
> >
> > Well, let's figure out what the right thing to do is first. If it
> > turns out we've created new normative requirements accidentally, the
> > first thing to do is to decide whether that's what we meant. Only then
> > will we set some sort of sane implementation timeline.
>

> Thanks Gerv.

[Doug Beattie]

Hi Gerv,

I'm still looking for audit guidance on subordinate CAs that have EKU of Server auth and/or Secure Mail along with name constraints. Do these need to be audited?

I'm looking at this: https://github.com/mozilla/pkipolicy/blob/master/rootstore/policy.md

Section 1.1, item #2 implies yes, that these CAs are in scope of this policy and thus must be audited - correct me if I'm wrong if being in the policy means they need to be audited.

Section 5.3.1 and 5.3.2 imply no audit is needed

Prior versions of the policy (at least 1.3 and before), did not require audits for technically constrained CAs like the ones referenced above. Further, it used to be OK if the "Name Constraints" applied for Secure Mail CAs was done via contractual methods, vs. in the CA certificate at a technical NC. We have one remaining customer with a CA like this and we're not sure on how new policy requirements apply to this existing customer. Your guidance is appreciated.

Doug

> -----Original Message-----
> From: dev-security-policy [mailto:dev-security-policy-

> > -----Original Message-----
> > From: dev-security-policy [mailto:dev-security-policy-
> > bounces+doug.beattie=globals...@lists.mozilla.org] On Behalf Of

> > douglas.beattie--- via dev-security-policy
> > Sent: Thursday, April 13, 2017 12:33 PM
> > To: mozilla-dev-s...@lists.mozilla.org

> > Subject: Re: Email sub-CAs
> >
> > On Thursday, April 13, 2017 at 10:49:17 AM UTC-4, Gervase Markham
> wrote:

> > > On 13/04/17 14:23, Doug Beattie wrote:
> > > > In 3.2 the term Technically Constrained is not defined to be any
> > > > different than the BRs (or perhaps even less restrictive).
> > >
> > > You mean 2.3, right?
> >

> > Yes, 2.3.

> >
> > > I would say Inclusion section, bullet 9 gives the definition of
> > > technically constrained. For email certs, because of the bug
> > > described in issue #69, it basically just says that it has to have
> > > the id-kp-emailProtection EKU. It should say more, but it doesn't.
> > > That's problematic, because just having an EKU isn't really a
> > > technical constraint in the "TCSC" sense.
> > >
> > > > In 3.2
> > > > this is all I can find regarding CAs that are capable of signing
> > > > secure email certificates, section 9: "If the certificate includes
> > > > the id-kp-emailProtection extended key usage, then all end-entity
> > > > certificates MUST only include e-mail addresses or mailboxes that
> > > > the issuing CA has confirmed (via technical and/or business
> > > > controls) that the subordinate CA is authorized to use."
> > > >
> > > > There is no statement back to scope or corresponding audits. Were
> > > > secure email capable CAs supposed to be disclosed and audited to
> > > > Mozilla under 2.3?
> > >
> > > If they did not include id-kp-serverAuth, I would not have faulted a
> > > CA for not disclosing them if they met the exclusion criteria for
> > > email certs as written.
> >

> > OK.

> >
> > > > and how it applies to Secure email, I don't see how TCSCs with
> > > > secure email EKU fall within the scope of the Mozilla Policy 2.3.
> > > > Can you help clarify?
> > >
> > > I think this is basically issue #69.
> > > https://github.com/mozilla/pkipolicy/issues/69
> >

> > OK, I look forward to a conclusion on that. I hope that name
> > constraining a secure email CA (either technically in the CA
> > certificate or via business
> > controls) is sufficient to avoid WebTrust Audits. If Public
> > disclosure helps get us there then that would be acceptable.
> >

> > Yes, we've been working hard to technically constrain all CAs and
> > especially those operated outside of our infrastructure. We've been
> > following the BR
> > definition: Include EKUs in all CAs, and for those that include server
> > auth or secure email, include name constraints.
> >

> > > Even if we didn't require it in our policy, I'm very surprised that
> > > no-one else does. Which other root store policies have requirements
> > > on email-only sub-CAs?
> >

> > Not that I know of.
> >

> > > > Obviously there are a lot of technically constrained CAs issued to
> > > > organizations to run their own CAs for issuing secure email and
> > > > client auth certificates. In order for them to continue
> > > > operations they now every organization needs to be publicly
> > > > reported and audited (a new requirement for 2.4.1 as far as I can tell), is
> that right?
> > >
> > > This is issue #36 :-)
> > > https://github.com/mozilla/pkipolicy/issues/36
> > >
> > > Do the CAs you are thinking of in this category have name
> > > constraints, or not (either actually in the cert, or via business controls)?
> >

> > Yes - they are all either name constrained either via the certificate
> > name constraints or via business controls.
> >

> > > > When did (does) this take effect? Is this for new CAs, existing or
> > > > both? When would the Audit Period for these CAs need to begin?
> > > >
> > > > This is a side question, but does the Mozilla policy require that
> > > > these CAs meet the Network Security Requirements?
> > >
> > > https://github.com/mozilla/pkipolicy/issues/70 :-) Not at the moment.
> >

> > OK

> >
> > > > Section 5.3.2 says that all CAs of the type I'm discussing must be
> > > > in the CCADB. What's the timeline for CAs to upload them?
> > >
> > > Well, let's figure out what the right thing to do is first. If it
> > > turns out we've created new normative requirements accidentally, the
> > > first thing to do is to decide whether that's what we meant. Only
> > > then will we set some sort of sane implementation timeline.
> >

> > Thanks Gerv.

[Gervase Markham]

Hi Doug,

On 18/05/17 12:03, Doug Beattie wrote:
> I'm still looking for audit guidance on subordinate CAs that have EKU
> of Server auth and/or Secure Mail along with name constraints. Do
> these need to be audited?
>
> I'm looking at this:
> https://github.com/mozilla/pkipolicy/blob/master/rootstore/policy.md
>
> Section 1.1, item #2 implies yes, that these CAs are in scope of this
> policy and thus must be audited - correct me if I'm wrong if being in
> the policy means they need to be audited.

Being in scope of the policy means that you need to read the rest of the
policy as applicable. It doesn't necessarily mean they need to be
audited - whether they do or not depends on what the Audit section says
about what needs to be audited. If these certs weren't in the scope of
the policy, then whatever the Audit section said would be irrelevant.

> Section 5.3.1 and 5.3.2 imply no audit is needed

At the moment, if a server-auth intermediate is properly
name-constrained according to the BRs, it's a TCSC and does not require
an audit. As you know, there's a bug in the latest version of the policy
regarding email intermediates, but the intent is that is an email
intermediate is properly rfc822name-constrained, with the constraints
being domain-ownership-validated to be owned by your customer, it also
doesn't require an audit, otherwise it does.

> Prior versions of the policy (at least 1.3 and before), did not
> require audits for technically constrained CAs like the ones
> referenced above. Further, it used to be OK if the "Name
> Constraints" applied for Secure Mail CAs was done via contractual
> methods, vs. in the CA certificate at a technical NC. We have one
> remaining customer with a CA like this and we're not sure on how new
> policy requirements apply to this existing customer. Your guidance
> is appreciated.

Contractual constraints are not considered sufficient under the current
version of the policy.

Gerv