DRAFT January 2018 CA Communication

[Wayne Thayer via dev-security-policy]

I want to directly notify all CAs in the Mozilla program of the recently
exposed issues with domain validation methods and of some upcoming
deadlines. A draft is available below and at
https://wiki.mozilla.org/CA/Communications#January_2018_CA_Communication

I would appreciate your prompt and constructive feedback on this message -
I'd like to get it sent out this week.

Thanks,

Wayne

=======================

Dear Certification Authority,

Because 2018 has already generated some important news for Certification
Authorities, we are sending this message to ensure that every CA in the
Mozilla program is aware of the following current events and impending
deadlines:

1. On 9-January, the CA “Let’s Encrypt” disclosed a vulnerability in the
ACME domain validation method known as TLS-SNI-01, which is an
implementation of the more general method described in BR 3.2.2.4.10. [1] A
subsequent vulnerability was disclosed on 11-January affecting the
validation method described in BR 3.2.2.4.9. [2] Mozilla expects all CAs to
be monitoring discussion in the mozilla.dev.security.policy forum and for
any CA that employs either of these methods to disclose that fact on the
list. From now on, Mozilla expects that CAs will not use these methods
unless they have implemented and disclosed a mitigation for the
vulnerabilities that have been discovered.

2. On 19-December, significant concerns were raised about the reliability
of the domain validation methods specified in BR 3.2.2.4.1 and 3.2.2.4.5.
[3] Since then, discussions on the CA/Browser Forum Public list have
resulted in a proposed ballot to prohibit the use of these methods after
1-August 2018. [4] If your CA uses either of these methods, please evaluate
your implementation for vulnerabilities and be prepared to discontinue
their use prior to the deadline if ballot 218 succeeds.

3. Sections 5.3.1 and 5.3.2 of Mozilla Root Store Policy version 2.5 [5]
require CAs to publicly disclose (via CCADB [6]) all subordinate CA
certificates including those used to issue email S/MIME certificates by
15-January unless they are technically constrained to a whitelist of
domains. We have since changed the compliance deadline to 15-April 2018.
Certificate monitors have detected over 200 certificates that currently do
not comply with this new policy. [7] Please ensure that your CA is in
compliance before 15-April 2018.

4. In our November 2017 CA Communication [8], Mozilla asked all CAs with
roots enabled for websites (SSL) to complete a BR self-assessment [9] by
31-January and send it to Kathleen. If you have not yet done so, please
complete this work. If you requested an extension, your deadline is
15-April 2018.

5. If you are one of the CAs that indicated in your response to the
November 2017 CA Communication that you need more time to update your CPS
to comply with version 2.5 of the Mozilla Root Store Policy, please
complete the updates no later than 15-April 2018. Mozilla feels that four
months is more than long enough to make a CPS change.

6. On 17-March 2017, in ballot 193, the CA/Browser Forum set a deadline of
1-March 2018 after which newly-issued SSL certificates must not have a
validity period greater than 825 days, and the re-use of validation
information must be limited to 825 days. As with all other baseline
requirements, Mozilla expects all CAs in the program to comply.

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,
Wayne Thayer
Mozilla CA Program Manager

[1]
https://groups.google.com/d/msg/mozilla.dev.security.policy/RHsIInIjJA0/LKrNi35aAQAJ
[2]
https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/PiOiGCyuxCU
[3] https://cabforum.org/pipermail/public/2017-December/012630.html
[4] https://cabforum.org/pipermail/public/2018-January/012819.html
[5]
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/
[6] http://ccadb.org/cas/intermediates
[7]
https://groups.google.com/d/msg/mozilla.dev.security.policy/sKhPTsIYNqs/Q-_ZKmDVAQAJ
[8]
https://wiki.mozilla.org/CA/Communications#November_2017_CA_Communication
[9] https://wiki.mozilla.org/CA/BR_Self-Assessment

[Tim Hollebeek via dev-security-policy]

Wayne,

You might want to highlight that method 1 sub-method 3 would survive even if
ballot 218 passes, as a new method 12 with some changes and improvements
that CAs who use sub-method 3 should pay close attention to.

With regards to TLS-SNI-01, I believe TLS-SNI-02 is also affected by the same
issue and should be mentioned as well.

-Tim

[Jonathan Rudenberg via dev-security-policy]

Post by Wayne Thayer via dev-security-policy
2. On 19-December, significant concerns were raised about the reliability
of the domain validation methods specified in BR 3.2.2.4.1 and 3.2.2.4.5.
[3] Since then, discussions on the CA/Browser Forum Public list have
resulted in a proposed ballot to prohibit the use of these methods after
1-August 2018. [4] If your CA uses either of these methods, please evaluate
your implementation for vulnerabilities and be prepared to discontinue
their use prior to the deadline if ballot 218 succeeds.

Is there a reason to make this deprecation conditional on the ballot? Given what we know about how the vulnerable methods are used in the wild, they have the same level of brokenness as TLS-SNI-01/02 and it’s not clear how evaluating for vulnerabilities would fix anything. August is a long time from now, and even that date would be conditional on the ballot.

I strongly believe that requiring CAs to disclose their use of these methods immediately, and setting a date not more than a couple months from now where these methods and previous validations using them must not be used would be the correct choice to protect Mozilla’s users.

Jonathan

[Wayne Thayer via dev-security-policy]

Post by Wayne Thayer via dev-security-policy

On Jan 24, 2018, at 15:20, Wayne Thayer via dev-security-policy <
2. On 19-December, significant concerns were raised about the reliability
of the domain validation methods specified in BR 3.2.2.4.1 and 3.2.2.4.5.
[3] Since then, discussions on the CA/Browser Forum Public list have
resulted in a proposed ballot to prohibit the use of these methods after
1-August 2018. [4] If your CA uses either of these methods, please

evaluate

your implementation for vulnerabilities and be prepared to discontinue
their use prior to the deadline if ballot 218 succeeds.

Is there a reason to make this deprecation conditional on the ballot?
Given what we know about how the vulnerable methods are used in the wild,
they have the same level of brokenness as TLS-SNI-01/02 and it’s not clear
how evaluating for vulnerabilities would fix anything.

This is a matter of timing. When possible, we should give the CA/Browser
Forum time to act before Mozilla does so unilaterally. Also, changing our
own policy is a process that would need to happen before we send this
communication. I have already suggested the Mozilla policy change [1].

August is a long time from now, and even that date would be conditional on

Post by Wayne Thayer via dev-security-policy
the ballot.

We could still choose to set that date in our own policy if the ballot were
to fail. The reasoning behind that date has been discussed on the
CA/Browser Forum lists. I would summarize the argument as (1) a number of
smaller CAs rely solely on 3.2.2.4.1 and (2) those that have commented
agreed that 6 months was enough time to migrate away from it.

Post by Wayne Thayer via dev-security-policy
I strongly believe that requiring CAs to disclose their use of these
methods immediately, and setting a date not more than a couple months from
now where these methods and previous validations using them must not be
used would be the correct choice to protect Mozilla’s users.
Jonathan

[1] https://github.com/mozilla/pkipolicy/issues/116

[Jonathan Rudenberg via dev-security-policy]

Post by Wayne Thayer via dev-security-policy
We could still choose to set that date in our own policy if the ballot were
to fail. The reasoning behind that date has been discussed on the
CA/Browser Forum lists. I would summarize the argument as (1) a number of
smaller CAs rely solely on 3.2.2.4.1 and (2) those that have commented
agreed that 6 months was enough time to migrate away from it.

While these CAs might want six months, it’s not clear that a good argument has been made for this. Let’s Encrypt stopped validating using the TLS-SNI-01 method under two hours after learning that there was a *potential* security vulnerability in the validation method. Why should we expect any less from other CAs? We should err on the side of protecting users, not CAs using insecure validation methods that don’t even stand up to a small amount of adversarial scrutiny.

[Ryan Sleevi via dev-security-policy]

On Wed, Jan 24, 2018 at 5:05 PM, Wayne Thayer via dev-security-policy <

Post by Wayne Thayer via dev-security-policy

Post by Jonathan Rudenberg via dev-security-policy
Is there a reason to make this deprecation conditional on the ballot?
Given what we know about how the vulnerable methods are used in the wild,
they have the same level of brokenness as TLS-SNI-01/02 and it’s not

clear

Post by Jonathan Rudenberg via dev-security-policy
how evaluating for vulnerabilities would fix anything.

This is a matter of timing. When possible, we should give the CA/Browser
Forum time to act before Mozilla does so unilaterally. Also, changing our
own policy is a process that would need to happen before we send this
communication. I have already suggested the Mozilla policy change [1].

Why is this?

Mozilla unilaterally acted with the 10 Blessed Methods in order to mitigate
security risks, after the Forum kept postponing.
Google and Microsoft (and later Mozilla) unilaterally acted with the
deprecation of SHA-1.

The CA/Browser Forum consensus process does not produce results aligned
with the Mozilla Foundation Manifesto, per-se, as it reflects a consensus
process where 2/3 of CAs have agreed to do something. This naturally
creates a situation of regulatory capture unaligned with the interests of
or security of Mozilla users.

There's two parts to the question at play here:
1) Does Mozilla believe the ballot is likely to pass the Forum, given a
number of CA's stated opposition?
2) Does Mozilla believe August is an appropriate time to cease the
practice, given the risks?
- Similarly, is Mozilla comfortable with accepting certificates using
methods with disclosed vulnerabilities between now and that time, and that
CAs sufficiently understand said vulnerabilities and have devised (but
seemingly not yet disclosed) appropriate mitigations or controls?

Post by Wayne Thayer via dev-security-policy
We could still choose to set that date in our own policy if the ballot were
to fail. The reasoning behind that date has been discussed on the
CA/Browser Forum lists.

Are you talking the public list, or some other list, such as the Validation
WG list? As a co-endorser of the Ballot, in its current form of August, it
was presented that unless we agreed to endorse at August, it was not worth
putting forward. One reason privately put forward as to why August was
because "other user agents" would vote against it unless it was August. Is
Mozilla such a User Agent?

I'm not yet aware of conversation that speaks to the volume of its usage
(those questions have gone unanswered) or to the challenges in migrating to
an alternative method (such as .2 or .3), which are still remarkably
flexible and, indeed, mitigations for the risk of .1 inevitably come back
to being .2 or .3 methods.

Post by Wayne Thayer via dev-security-policy
I would summarize the argument as (1) a number of
smaller CAs rely solely on 3.2.2.4.1 and (2) those that have commented
agreed that 6 months was enough time to migrate away from it.

I've not seen any CA publicly state that 6 months was sufficient time. Was
this on the Validation list?

[Wayne Thayer via dev-security-policy]

Post by Ryan Sleevi via dev-security-policy
On Wed, Jan 24, 2018 at 5:05 PM, Wayne Thayer via dev-security-policy <

Post by Wayne Thayer via dev-security-policy

Post by Jonathan Rudenberg via dev-security-policy
Is there a reason to make this deprecation conditional on the ballot?
Given what we know about how the vulnerable methods are used in the

wild,

Post by Jonathan Rudenberg via dev-security-policy
they have the same level of brokenness as TLS-SNI-01/02 and it’s not

clear

Post by Jonathan Rudenberg via dev-security-policy
how evaluating for vulnerabilities would fix anything.

This is a matter of timing. When possible, we should give the CA/Browser
Forum time to act before Mozilla does so unilaterally. Also, changing our
own policy is a process that would need to happen before we send this
communication. I have already suggested the Mozilla policy change [1].

Why is this?
Mozilla unilaterally acted with the 10 Blessed Methods in order to
mitigate security risks, after the Forum kept postponing.

Yes, *after the Forum kept postponing*.

Google and Microsoft (and later Mozilla) unilaterally acted with the

Post by Ryan Sleevi via dev-security-policy
deprecation of SHA-1.

My recollection is that Microsoft acted after first raising the issue with
the Forum and getting nowhere. So I believe that both of your examples
support my statement.

Post by Ryan Sleevi via dev-security-policy
The CA/Browser Forum consensus process does not produce results aligned
with the Mozilla Foundation Manifesto, per-se, as it reflects a consensus
process where 2/3 of CAs have agreed to do something. This naturally
creates a situation of regulatory capture unaligned with the interests of
or security of Mozilla users.
1) Does Mozilla believe the ballot is likely to pass the Forum, given a
number of CA's stated opposition?

I can't answer that, but it does appear logical that the ballot is less
likely to succeed with a March deadline.

Post by Ryan Sleevi via dev-security-policy
2) Does Mozilla believe August is an appropriate time to cease the
practice, given the risks?

I don't know if there is consensus on this, but it is now clear to me that
at least some members of our community believe that August is not
appropriate.

- Similarly, is Mozilla comfortable with accepting certificates using

Post by Ryan Sleevi via dev-security-policy
methods with disclosed vulnerabilities between now and that time, and that
CAs sufficiently understand said vulnerabilities and have devised (but
seemingly not yet disclosed) appropriate mitigations or controls?

Based on the feedback we've seen on this list, I'm going to say no, this is
a risk we're not comfortable with.

Post by Ryan Sleevi via dev-security-policy
We could still choose to set that date in our own policy if the ballot were

Post by Wayne Thayer via dev-security-policy
to fail. The reasoning behind that date has been discussed on the
CA/Browser Forum lists.

Are you talking the public list, or some other list, such as the
Validation WG list? As a co-endorser of the Ballot, in its current form of
August, it was presented that unless we agreed to endorse at August, it was
not worth putting forward. One reason privately put forward as to why
August was because "other user agents" would vote against it unless it was
August. Is Mozilla such a User Agent?
I expressed my concerns about a Mar 1 deadline on a Validation WG call and

then reiterated them on the Public list: https://cabforum.org/
pipermail/public/2018-January/012713.html I don't think that message
suggests Mozilla would vote against an earlier deadline, and I can't say if
Mozilla would or not. Conversely, your endorsement of the ballot certainly
made me think that Google supported the August deadline.

Post by Ryan Sleevi via dev-security-policy
I'm not yet aware of conversation that speaks to the volume of its usage
(those questions have gone unanswered) or to the challenges in migrating to
an alternative method (such as .2 or .3), which are still remarkably
flexible and, indeed, mitigations for the risk of .1 inevitably come back
to being .2 or .3 methods.

Post by Wayne Thayer via dev-security-policy
I would summarize the argument as (1) a number of
smaller CAs rely solely on 3.2.2.4.1 and (2) those that have commented
agreed that 6 months was enough time to migrate away from it.

I've not seen any CA publicly state that 6 months was sufficient time. Was
this on the Validation list?

Yes - https://cabforum.org/pipermail/validation/2018-January/000703.html

[Wayne Thayer via dev-security-policy]

Tim - I will add a reference to TLS-SNI-02 as you suggested. I think an
explanation of the new method 12 is too much detail for this message, and
it can be found in the ballot that I've referenced.

In order to move ahead with this communication to CAs while our timeline
for the deprecation of BR 3.2.2.4 methods 1 and 5 is still being discussed,
I'd like to propose modifying item #2 as follows:

2. On 19-December, significant concerns were raised about the reliability
of the domain validation methods specified in BR 3.2.2.4.1 and 3.2.2.4.5.
[3] Since then, discussions on the CA/Browser Forum Public list have
resulted in a proposed ballot to prohibit the use of these methods after
1-August 2018. [4] Rather than accept the risk of continued use of these
methods, Mozilla may decide to set an earlier deadline such as 1-March
2018. If your CA uses either of these methods, please evaluate your
implementation for vulnerabilities, follow the discussion closely, and be
prepared to quickly discontinue your use of these methods of domain
validation.

Please comment on this change.

Thanks,

Wayne

Post by Wayne Thayer via dev-security-policy

Post by Ryan Sleevi via dev-security-policy
On Wed, Jan 24, 2018 at 5:05 PM, Wayne Thayer via dev-security-policy <

Post by Wayne Thayer via dev-security-policy

Post by Jonathan Rudenberg via dev-security-policy
Is there a reason to make this deprecation conditional on the ballot?
Given what we know about how the vulnerable methods are used in the

wild,

Post by Jonathan Rudenberg via dev-security-policy
they have the same level of brokenness as TLS-SNI-01/02 and it’s not

clear

Post by Jonathan Rudenberg via dev-security-policy
how evaluating for vulnerabilities would fix anything.

This is a matter of timing. When possible, we should give the CA/Browser
Forum time to act before Mozilla does so unilaterally. Also, changing our
own policy is a process that would need to happen before we send this
communication. I have already suggested the Mozilla policy change [1].

Why is this?
Mozilla unilaterally acted with the 10 Blessed Methods in order to
mitigate security risks, after the Forum kept postponing.

Yes, *after the Forum kept postponing*.
Google and Microsoft (and later Mozilla) unilaterally acted with the

Post by Ryan Sleevi via dev-security-policy
deprecation of SHA-1.

My recollection is that Microsoft acted after first raising the issue with
the Forum and getting nowhere. So I believe that both of your examples
support my statement.

Post by Ryan Sleevi via dev-security-policy
The CA/Browser Forum consensus process does not produce results aligned
with the Mozilla Foundation Manifesto, per-se, as it reflects a consensus
process where 2/3 of CAs have agreed to do something. This naturally
creates a situation of regulatory capture unaligned with the interests of
or security of Mozilla users.
1) Does Mozilla believe the ballot is likely to pass the Forum, given a
number of CA's stated opposition?

I can't answer that, but it does appear logical that the ballot is less
likely to succeed with a March deadline.

Post by Ryan Sleevi via dev-security-policy
2) Does Mozilla believe August is an appropriate time to cease the
practice, given the risks?

I don't know if there is consensus on this, but it is now clear to me that
at least some members of our community believe that August is not
appropriate.
- Similarly, is Mozilla comfortable with accepting certificates using

Post by Ryan Sleevi via dev-security-policy
methods with disclosed vulnerabilities between now and that time, and that
CAs sufficiently understand said vulnerabilities and have devised (but
seemingly not yet disclosed) appropriate mitigations or controls?

Based on the feedback we've seen on this list, I'm going to say no, this
is a risk we're not comfortable with.

Post by Ryan Sleevi via dev-security-policy
We could still choose to set that date in our own policy if the ballot

Post by Wayne Thayer via dev-security-policy
were
to fail. The reasoning behind that date has been discussed on the
CA/Browser Forum lists.

Are you talking the public list, or some other list, such as the
Validation WG list? As a co-endorser of the Ballot, in its current form of
August, it was presented that unless we agreed to endorse at August, it was
not worth putting forward. One reason privately put forward as to why
August was because "other user agents" would vote against it unless it was
August. Is Mozilla such a User Agent?
I expressed my concerns about a Mar 1 deadline on a Validation WG call

https://cabforum.org/pipermail/public/2018-January/012713.html I don't
think that message suggests Mozilla would vote against an earlier deadline,
and I can't say if Mozilla would or not. Conversely, your endorsement of
the ballot certainly made me think that Google supported the August
deadline.

Post by Ryan Sleevi via dev-security-policy
I'm not yet aware of conversation that speaks to the volume of its usage
(those questions have gone unanswered) or to the challenges in migrating to
an alternative method (such as .2 or .3), which are still remarkably
flexible and, indeed, mitigations for the risk of .1 inevitably come back
to being .2 or .3 methods.

Post by Wayne Thayer via dev-security-policy
I would summarize the argument as (1) a number of
smaller CAs rely solely on 3.2.2.4.1 and (2) those that have commented
agreed that 6 months was enough time to migrate away from it.

I've not seen any CA publicly state that 6 months was sufficient time.
Was this on the Validation list?

Yes - https://cabforum.org/pipermail/validation/2018-January/000703.html

[Jonathan Rudenberg via dev-security-policy]

Post by Wayne Thayer via dev-security-policy
Tim - I will add a reference to TLS-SNI-02 as you suggested. I think an
explanation of the new method 12 is too much detail for this message, and
it can be found in the ballot that I've referenced.
In order to move ahead with this communication to CAs while our timeline
for the deprecation of BR 3.2.2.4 methods 1 and 5 is still being discussed,
2. On 19-December, significant concerns were raised about the reliability
of the domain validation methods specified in BR 3.2.2.4.1 and 3.2.2.4.5.
[3] Since then, discussions on the CA/Browser Forum Public list have
resulted in a proposed ballot to prohibit the use of these methods after
1-August 2018. [4] Rather than accept the risk of continued use of these
methods, Mozilla may decide to set an earlier deadline such as 1-March
2018. If your CA uses either of these methods, please evaluate your
implementation for vulnerabilities, follow the discussion closely, and be
prepared to quickly discontinue your use of these methods of domain
validation.
Please comment on this change.

This is a great improvement. I think we should also ask that any CAs using these methods immediate disclose that they are and the procedures they are using, as well as the date they expect to complete a review of their implementation, and then provide the review when it is complete.

[Wayne Thayer via dev-security-policy]

Post by Jonathan Rudenberg via dev-security-policy
This is a great improvement. I think we should also ask that any CAs using
these methods immediate disclose that they are and the procedures they are
using, as well as the date they expect to complete a review of their
implementation, and then provide the review when it is complete.

The scope of this issue is much different from the method .9 and .10
vulnerabilities - lot of CAs use methods .1 and .5. Asking them all to
answer these questions seems likely to just yield a bunch of "we reviewed
our implementation and it is perfect" emails. What do you hope to learn
from this disclosure that hasn't already been discussed? What do others
think?

If we want to hold CAs accountable for this disclosure, we'll need to turn
this communication into a survey and give CAs a certain amount of time to
respond, so we won't have answers for weeks.

- Wayne

[Jonathan Rudenberg via dev-security-policy]

Post by Wayne Thayer via dev-security-policy

Post by Jonathan Rudenberg via dev-security-policy
This is a great improvement. I think we should also ask that any CAs using
these methods immediate disclose that they are and the procedures they are
using, as well as the date they expect to complete a review of their
implementation, and then provide the review when it is complete.

The scope of this issue is much different from the method .9 and .10
vulnerabilities - lot of CAs use methods .1 and .5. Asking them all to
answer these questions seems likely to just yield a bunch of "we reviewed
our implementation and it is perfect" emails. What do you hope to learn
from this disclosure that hasn't already been discussed? What do others
think?
If we want to hold CAs accountable for this disclosure, we'll need to turn
this communication into a survey and give CAs a certain amount of time to
respond, so we won't have answers for weeks.

My goal with this line of questioning is to require some engagement with this item, so that CAs can’t claim they were surprised or unaware of the upcoming deprecation. While it obviously should not be necessary, in the past CAs have claimed all manner of excuses for complying with requirements that were announced and discussed with a lot more lead time than this one might be.

I’d be equally fine with sanctioning CAs that pull this stunt in the future, but we don’t have good levers or procedures for doing this yet.

Jonathan

[Ryan Sleevi via dev-security-policy]

On Thu, Jan 25, 2018 at 11:48 AM, Jonathan Rudenberg <

Post by Jonathan Rudenberg via dev-security-policy
This is a great improvement. I think we should also ask that any CAs
using these methods immediate disclose that they are and the procedures
they are using, as well as the date they expect to complete a review of
their implementation, and then provide the review when it is complete.

The scope of this issue is much different from the method .9 and .10
vulnerabilities - lot of CAs use methods .1 and .5. Asking them all to
answer these questions seems likely to just yield a bunch of "we reviewed
our implementation and it is perfect" emails. What do you hope to learn
from this disclosure that hasn't already been discussed? What do others
think?
If we want to hold CAs accountable for this disclosure, we'll need to turn
this communication into a survey and give CAs a certain amount of time to
respond, so we won't have answers for weeks.

I'm curious why the "for weeks" disclosure.

Mozilla has required since April 2017 that CAs disclose the method of
validation they use - https://wiki.mozilla.org/CA/Communications#April_2017
(Specifically, Action #1), which MUST be completed before July 21, 2017.

Jonathan's proposal to require the CAs "immediately disclose that they are"
is thus consistent with the CA simply reading its CP/CPS. Further, "the
procedures that they are using" is also a matter of existing CP/CPS
documentation and/or supporting documents - making them explicitly public.

So this merely leaves the question of "The date they expect to complete a
review of their implementation, and then provide the review when it is
complete".

When faced with potential Security Vulnerabilities, Mozilla has required
prompt disclosure - see, for example,
https://wiki.mozilla.org/CA/Communications#November_2017_CA_Communication
and https://wiki.mozilla.org/CA/Communications#September_2011

The question, then, is how long it should take CAs to:
- Receive a communication from Mozilla
- Read their CP/CPS and issuance practices
- Reply to two questions:
- Are you using these methods?
- When will you expect to have your review?

Given that both GlobalSign and Let's Encrypt were able to identify within
days, it seems like the upper-bound for a response - and a completed review
- should be suitable within a week, at the absolute most. Any CA who cannot
respond and review that quickly raises questions about their ability to be
trusted

[Peter Bowen via dev-security-policy]

On Thu, Jan 25, 2018 at 1:02 PM, Ryan Sleevi via dev-security-policy

Post by Ryan Sleevi via dev-security-policy

On Thu, Jan 25, 2018 at 11:48 AM, Jonathan Rudenberg <

Post by Jonathan Rudenberg via dev-security-policy
This is a great improvement. I think we should also ask that any CAs
using these methods immediate disclose that they are and the procedures
they are using, as well as the date they expect to complete a review of
their implementation, and then provide the review when it is complete.

The scope of this issue is much different from the method .9 and .10
vulnerabilities - lot of CAs use methods .1 and .5. Asking them all to
answer these questions seems likely to just yield a bunch of "we reviewed
our implementation and it is perfect" emails. What do you hope to learn
from this disclosure that hasn't already been discussed? What do others
think?
If we want to hold CAs accountable for this disclosure, we'll need to turn
this communication into a survey and give CAs a certain amount of time to
respond, so we won't have answers for weeks.

I'm curious why the "for weeks" disclosure.
Mozilla has required since April 2017 that CAs disclose the method of
validation they use - https://wiki.mozilla.org/CA/Communications#April_2017
(Specifically, Action #1), which MUST be completed before July 21, 2017.
Jonathan's proposal to require the CAs "immediately disclose that they are"
is thus consistent with the CA simply reading its CP/CPS. Further, "the
procedures that they are using" is also a matter of existing CP/CPS
documentation and/or supporting documents - making them explicitly public.
So this merely leaves the question of "The date they expect to complete a
review of their implementation, and then provide the review when it is
complete".

What incentive is there for a CA to ever answer with anything other than:

a) that they may use any method allowed by Mozilla, and

b) they have reviewed their implementation and believe that it
complies with Mozilla's requirements?

Given the Mozilla CA policy says "the CA must ensure that the
applicant has registered the domain(s) referenced in the certificate
or has been authorized by the domain registrant to act on their
behalf", is the implication here that showing technical control of the
domain is not adequate and that CAs have to confirm with the
registrant for every issuance. As I read it, the policy does not call
for validating technical control over the domain and does not allow a
simple technical control validation to suffice.

I think Mozilla should update the policy to make sure the policy
language accurately reflects Mozilla's intent, then ask CAs to double
check that they comply with the policy.

Thanks,
Peter

[Ryan Sleevi via dev-security-policy]

On Thu, Jan 25, 2018 at 4:20 PM, Peter Bowen via dev-security-policy <

Post by Peter Bowen via dev-security-policy
On Thu, Jan 25, 2018 at 1:02 PM, Ryan Sleevi via dev-security-policy

Post by Ryan Sleevi via dev-security-policy

On Thu, Jan 25, 2018 at 11:48 AM, Jonathan Rudenberg <

Post by Jonathan Rudenberg via dev-security-policy
This is a great improvement. I think we should also ask that any CAs
using these methods immediate disclose that they are and the procedures
they are using, as well as the date they expect to complete a review of
their implementation, and then provide the review when it is complete.

The scope of this issue is much different from the method .9 and .10
vulnerabilities - lot of CAs use methods .1 and .5. Asking them all to
answer these questions seems likely to just yield a bunch of "we

reviewed

Post by Ryan Sleevi via dev-security-policy

our implementation and it is perfect" emails. What do you hope to learn
from this disclosure that hasn't already been discussed? What do others
think?
If we want to hold CAs accountable for this disclosure, we'll need to

turn

Post by Ryan Sleevi via dev-security-policy

this communication into a survey and give CAs a certain amount of time

to

Post by Ryan Sleevi via dev-security-policy

respond, so we won't have answers for weeks.

I'm curious why the "for weeks" disclosure.
Mozilla has required since April 2017 that CAs disclose the method of
validation they use - https://wiki.mozilla.org/CA/

Communications#April_2017

Post by Ryan Sleevi via dev-security-policy
(Specifically, Action #1), which MUST be completed before July 21, 2017.
Jonathan's proposal to require the CAs "immediately disclose that they

are"

Post by Ryan Sleevi via dev-security-policy
is thus consistent with the CA simply reading its CP/CPS. Further, "the
procedures that they are using" is also a matter of existing CP/CPS
documentation and/or supporting documents - making them explicitly

public.

Post by Ryan Sleevi via dev-security-policy
So this merely leaves the question of "The date they expect to complete a
review of their implementation, and then provide the review when it is
complete".

a) that they may use any method allowed by Mozilla, and
b) they have reviewed their implementation and believe that it
complies with Mozilla's requirements?

I'm not sure I follow - there's two different things at play here.

Combining Wayne's text with Jonathan's proposal, the question is to require
CAs disclose whether they're specifically using 3.2.2.4.1 and 3.2.2.4.5. If
they are, additional work is asked of them. If they aren't, their work is
done.

Thus the incentive for the CA is to be precise about what methods they are
using, because if they aren't using those methods, then there's no work for
them to do.

The Baseline Requirements already require - using a specific proposal from
Mozilla - that CAs "SHALL maintain a record of which domain validation
method, including relevant BR version number, they used to validate every
domain."

So every CA already has the information available as to
- What methods they COULD use to validate
- What methods they DO use to validate

And the request is that they simply aggregate and provide that information
as part of a normal disclosure process, for information that should be
readily available, in order to inform policy and the potential risks of
changing policy, both per-CA and per the ecosystem.

A more concrete question may be:
- Does your CP/CPS permit you to use 3.2.2.4.1?
- Does your CP/CPS permit you to use 3.2.2.4.5?
- If you answered yes to either of the previous two questions:
- In the past 6 months, how many certificates did you issue?
- In the past 6 months, how many certificates did you issue that
contained a domain validated using 3.2.2.4.1
- In the past 6 months, how many new domain validations using 3.2.2.4.1
were performed
- In the past 6 months, how many unique domains reused a previously
completed 3.2.2.4.1 validation
- In the past 6 months, how many certificates did you issue that
contained a domain validated using 3.2.2.4.5
- In the past 6 months, how many new domain validations using 3.2.2.4.5
were performed
- In the past 6 months, how many unique domains reused a previously
completed 3.2.2.4.5 validation

The first two questions involve reviewing the CP/CPS. The CA should be
qualified to so. The remaining questions 'should' be simple queries on
their issuance database. A CA that has not maintained accessible records of
such issuance - for example, putting them in a locked filing cabinet, in
the basement, beneath the leopard - is a CA not equipped to effectively
respond to security risks.

[Wayne Thayer via dev-security-policy]

Based on the feedback we've received, but sticking with the original intent
of this communication, I have converted it into a survey. You can find a
draft at:

https://wiki.mozilla.org/CA/Communications#January_2018_CA_Communication

I would appreciate your comments on this. I have set the deadline for
responses to 9-Feb, making the assumption that we can send this out on
Monday.

Thanks,

Wayne

[Jakob Bohm via dev-security-policy]

Post by Wayne Thayer via dev-security-policy
Based on the feedback we've received, but sticking with the original intent
of this communication, I have converted it into a survey. You can find a
https://wiki.mozilla.org/CA/Communications#January_2018_CA_Communication
I would appreciate your comments on this. I have set the deadline for
responses to 9-Feb, making the assumption that we can send this out on
Monday.

I think a number of the questions/actions need additional options:

For ACTION 1:

(These 3 are between the 1st and second current option).

Add Option: Our CPS permits these methods, but we have already stopped
exercising that permission, and any certificates so issued are no
longer valid (expired or revoked).

Add Option: We previously used these methods, but have already suspended
doing so, We have reviewed our past implementation for vulnerabilities
and have reported our findings below.

Add option: We previously used these methods, but have already suspended
doing so, We will review our past implementation for vulnerabilities
and report our findings on the mozilla.dev.security.policy list by the
date specified in the comments section below.


For ACTION 2:

Add option: Our CPS permits these methods, but we only use them in a way
that already complies with the proposed method 12 in CAB/F ballot 218.

Plus the 3 extra options from ACTION 1

For ACTION 4:

Split the second item into:

Option: We intend to deliver our BR Self Assessment prior to 31-january
2018

Option: We previously requested an extension and intend to deliver our
BR Self Assessment prior to 15-April 2018.

For ACTION 5:

Split the or clause into two options (formatting error)

For ACTION 6:

Split into 3 options

Option: We have never issued SSL certificates with a validity period
greater than 825 days, and will not do so in the future.

Option: We will stop issueing SSL certificates with a validity period
greater than 825 days on or before 1-March 2018

Option: We will stop issueing SSL certificates with a validity period
greater than 825 days on or before 1-March 2018. Some certificates
issued before 1-March 2018 have a not-before date after 28-Feb 2018
and more than 825 days before their not-after date. (But not-after is
still less than the previously permitted maximum time after the date
of issuance).

(That 3rd option would apply, at least, to GlobalSign according to
another thread).



Enjoy

Jakob

[Wayne Thayer via dev-security-policy]

Thanks Jakob. I updated the draft as described below.

On Fri, Jan 26, 2018 at 10:42 AM, Jakob Bohm via dev-security-policy <

Post by Jakob Bohm via dev-security-policy
(These 3 are between the 1st and second current option).
Add Option: Our CPS permits these methods, but we have already stopped
exercising that permission, and any certificates so issued are no
longer valid (expired or revoked).
Add Option: We previously used these methods, but have already suspended
doing so, We have reviewed our past implementation for vulnerabilities
and have reported our findings below.
Add option: We previously used these methods, but have already suspended
doing so, We will review our past implementation for vulnerabilities
and report our findings on the mozilla.dev.security.policy list by the
date specified in the comments section below.
I don't think many CAs are using these methods, so I simplified your

suggestion by changing option 3 to "Other (please describe below)"

Post by Jakob Bohm via dev-security-policy
Add option: Our CPS permits these methods, but we only use them in a way
that already complies with the proposed method 12 in CAB/F ballot 218.
Added.

Plus the 3 extra options from ACTION 1

Post by Jakob Bohm via dev-security-policy
I again tried to simplify your suggestion by changing the existing choices

to cover these cases.

Post by Jakob Bohm via dev-security-policy
Option: We intend to deliver our BR Self Assessment prior to 31-january
2018
Option: We previously requested an extension and intend to deliver our
BR Self Assessment prior to 15-April 2018.
Done.
Split the or clause into two options (formatting error)
Fixed.
Split into 3 options
Option: We have never issued SSL certificates with a validity period
greater than 825 days, and will not do so in the future.
Option: We will stop issueing SSL certificates with a validity period
greater than 825 days on or before 1-March 2018
Option: We will stop issueing SSL certificates with a validity period
greater than 825 days on or before 1-March 2018. Some certificates
issued before 1-March 2018 have a not-before date after 28-Feb 2018
and more than 825 days before their not-after date. (But not-after is
still less than the previously permitted maximum time after the date
of issuance).
(That 3rd option would apply, at least, to GlobalSign according to
another thread).
I rejected this change because it was determined that GlobalSign didn't

break any rules or find a loophole that bypasses the new 825-day
requirement, and the intent of this action is not to discover which CAs
have been issuing 3-year certs.

Post by Jakob Bohm via dev-security-policy
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct [phone]
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
_______________________________________________
dev-security-policy mailing list
https://lists.mozilla.org/listinfo/dev-security-policy

[Wayne Thayer via dev-security-policy]

You can find a link to the final version of the survey at
https://wiki.mozilla.org/CA/Communications#January_2018_CA_Communication

We're planning to send this out to all CAs in the Mozilla program later
today. The deadline for responses has been set to 9-February.

Thanks to everyone who contributed to this effort.

- Wayne

[Wayne Thayer via dev-security-policy]

The email has been sent, and we've published a blog post:

https://blog.mozilla.org/security/2018/01/29/january-2018-ca-communication/

Post by Wayne Thayer via dev-security-policy
You can find a link to the final version of the survey at
https://wiki.mozilla.org/CA/Communications#January_2018_CA_Communication
We're planning to send this out to all CAs in the Mozilla program later
today. The deadline for responses has been set to 9-February.
Thanks to everyone who contributed to this effort.
- Wayne

[Wayne Thayer via dev-security-policy]

Friday was the deadline for responding to this survey. Responses are now
published at
https://wiki.mozilla.org/CA/Communications#January_2018_Responses

I would like to thank everyone who took the time to respond, and especially
those who provided detailed answers to Action 2 regarding methods 1 and 5.

The following CAs have not responded:

- Government of Spain, Fábrica Nacional de Moneda y Timbre (FNMT)
- GoDaddy
- Disig, a.s.
- Certinomis / Docapost
- Cybertrust Japan / JCSI
- Deutscher Sparkassen Verlag GmbH (S-TRUST, DSV-Gruppe)
- TurkTrust
- Web.com
- E-Tugra

I will allow a grace period of a few days and then will open incident bugs
for those CAs that still haven't responded.

- Wayne

On Mon, Jan 29, 2018 at 5:14 PM, Wayne Thayer via dev-security-policy <

Post by Wayne Thayer via dev-security-policy
https://blog.mozilla.org/security/2018/01/29/january-2018-ca
-communication/

Post by Wayne Thayer via dev-security-policy
You can find a link to the final version of the survey at
https://wiki.mozilla.org/CA/Communications#January_2018_CA_Communication
We're planning to send this out to all CAs in the Mozilla program later
today. The deadline for responses has been set to 9-February.
Thanks to everyone who contributed to this effort.
- Wayne

[Wayne Thayer via dev-security-policy]

I've opened bugs for the following CAs that still haven't responded:

- GoDaddy
- Certinomis / Docapost
- Deutscher Sparkassen Verlag GmbH (S-TRUST, DSV-Gruppe)
- TurkTrust
- E-Tugra

You can find these bugs on the Incident Dashboard:
https://wiki.mozilla.org/CA/Incident_Dashboard

- Wayne

Post by Wayne Thayer via dev-security-policy
Friday was the deadline for responding to this survey. Responses are now
published at https://wiki.mozilla.org/CA/Communications#January_2018_
Responses
I would like to thank everyone who took the time to respond, and
especially those who provided detailed answers to Action 2 regarding
methods 1 and 5.
- Government of Spain, Fábrica Nacional de Moneda y Timbre (FNMT)
- GoDaddy
- Disig, a.s.
- Certinomis / Docapost
- Cybertrust Japan / JCSI
- Deutscher Sparkassen Verlag GmbH (S-TRUST, DSV-Gruppe)
- TurkTrust
- Web.com
- E-Tugra
I will allow a grace period of a few days and then will open incident bugs
for those CAs that still haven't responded.
- Wayne

[Gervase Markham via dev-security-policy]

Post by Jonathan Rudenberg via dev-security-policy
While these CAs might want six months, it’s not clear that a good
argument has been made for this. Let’s Encrypt stopped validating
using the TLS-SNI-01 method under two hours after learning that there
was a *potential* security vulnerability in the validation method.
Why should we expect any less from other CAs? We should err on the
side of protecting users, not CAs using insecure validation methods
that don’t even stand up to a small amount of adversarial scrutiny.

Six months may or many not be the right timeline, but I don't think it's
fair to compare removing an option in an automated process (which was,
in fact, subsequently restored for existing customers within a few days)
with retraining all your validation specialists to use a different
manual process. Such work cannot be done in 2 hours.

Gerv

[Ryan Sleevi via dev-security-policy]

On Fri, Jan 26, 2018 at 5:24 AM Gervase Markham via dev-security-policy <

Post by Gervase Markham via dev-security-policy

Post by Jonathan Rudenberg via dev-security-policy
While these CAs might want six months, it’s not clear that a good
argument has been made for this. Let’s Encrypt stopped validating
using the TLS-SNI-01 method under two hours after learning that there
was a *potential* security vulnerability in the validation method.
Why should we expect any less from other CAs? We should err on the
side of protecting users, not CAs using insecure validation methods
that don’t even stand up to a small amount of adversarial scrutiny.

Six months may or many not be the right timeline, but I don't think it's
fair to compare removing an option in an automated process (which was,
in fact, subsequently restored for existing customers within a few days)
with retraining all your validation specialists to use a different
manual process. Such work cannot be done in 2 hours.

As you noted in the CA/Browser Forum, and other CAs have, the only real
change from a .1 to a .2/.3 is that the CA calls the domain contact from
WHOIS, rather than a phone number they got from a “reliable source”
(3.2.5). We should be careful not to accept the unsubstantiated and
questionable narrative of CAs view of difficulty.

If anything, automation is harder to replace because you have an ecosystem
to uplift - new protocols and new upgrades - whereas as you note, even a
radical change in issuance practice can be accomplished via simple training
of a limited number of validation specialists. The economies of scale of
that transition highly favor rapid transition from manual validation
methods.