DRAFT November 2017 CA Communication

[Kathleen Wilson]

All,

I will greatly appreciate your thoughtful and constructive feedback on the DRAFT of Mozilla's next CA Communication, which I am hoping to send in early November.

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

Direct link to the survey:
https://ccadb-public.secure.force.com/mozillacommunications/CACommunicationSurveySample?CACommunicationId=a051J00003mogw7

Thanks,
Kathleen

[Jeremy Rowley]

Some initial thoughts
1. I'm a bit confused by bullet #2 in the survey. Wasn't it already the
Mozilla policy that CAs could only use the blessed 10 methods of validation?
I thought this was communicated in the previous letter?
2. On bullet #3, I'm reading the wording to mean either 1) disclosed and
audited or 2) revoked, not disclosed and either a) revoked or b) audited,
correct? Rewording the language to be "must be either audited and disclosed
or revoked in the Common CA Database" might clarify between the two.
3. On bullet #3, should you specify what audits are required for s/MIME in
the email? There might be confusion between the two audit questions that
interprets s/MIME as requiring a BR audit. This might not be worth
clarifying though as all CAs should understand the purpose of each audit.
4. On action 4, how often will Mozilla require BR Self assessments? Should
you state that Mozilla may require them on a periodic basis going forward?
5. On action 7, I'm unaware of any CT discussions currently ongoing at the
CAB Forum or Mozilla list. Could you provide a link or further intent on
what we're watching for?

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

[Andrew Ayer]

Hi Kathleen,

I suggest being explicit about which CAA errata Mozilla allows.

For CNAME, it's erratum 5065.

For DNAME, it's erratum 5097.

Link to errata: https://www.rfc-editor.org/errata_search.php?rfc=6844

We don't want CAs to think they can follow any errata they like, or to
come up with their own interpretation of what "natural" means :-)

Regards,
Andrew

On Wed, 25 Oct 2017 12:46:40 -0700 (PDT)
Kathleen Wilson via dev-security-policy

[Andrew Ayer]

[Tim Hollebeek]

I don't like erratum 5097. It just deletes the mention of DNAME, which can easily be misinterpreted as not permitting DNAME following for CAA (or even worse, allows DNAME to be handled however you want). Erratum 5097 also has not been approved by IETF (and shouldn't be, for this reason).

The "natural" interpretation of DNAME, which has been discussed on various CA/Browser forum calls and at the Taiwan face to face meeting, is that DNAME must be handled in compliance with RFC 6672, which explains how synthesized CNAMEs work.

My own personal preferred fix for RFC 6844 is to replace "CNAME or DNAME alias record specified at the label X" with "CNAME alias record specified at the label X, or a DNAME alias record *in effect at* the label X (see RFC 6672)"

But anyway, I think everyone agrees what we want: DNAMEs work the way they do everywhere else. There's nothing special about them for CAA.

-Tim

-----Original Message-----
From: dev-security-policy [mailto:dev-security-policy-bounces+thollebeek=trustw...@lists.mozilla.org] On Behalf Of Andrew Ayer via dev-security-policy
Sent: Wednesday, October 25, 2017 5:05 PM
To: Kathleen Wilson <kwi...@mozilla.com>
Cc: Kathleen Wilson via dev-security-policy <dev-secur...@lists.mozilla.org>; mozilla-dev-s...@lists.mozilla.org
Subject: Re: DRAFT November 2017 CA Communication

Hi Kathleen,

I suggest being explicit about which CAA errata Mozilla allows.

For CNAME, it's erratum 5065.

For DNAME, it's erratum 5097.

Link to errata: https://scanmail.trustwave.com/?c=4062&d=rPzw2czQrwDIggzGnHPfXELR5_onUMc5So6YlzbIiQ&s=5&u=https%3a%2f%2fwww%2erfc-editor%2eorg%2ferrata%5fsearch%2ephp%3frfc%3d6844

We don't want CAs to think they can follow any errata they like, or to come up with their own interpretation of what "natural" means :-)

Regards,
Andrew

On Wed, 25 Oct 2017 12:46:40 -0700 (PDT) Kathleen Wilson via dev-security-policy <dev-secur...@lists.mozilla.org> wrote:

> All,
>
> I will greatly appreciate your thoughtful and constructive feedback on
> the DRAFT of Mozilla's next CA Communication, which I am hoping to
> send in early November.
>

> https://scanmail.trustwave.com/?c=4062&d=rPzw2czQrwDIggzGnHPfXELR5_onU
> Mc5St_PkWKbjQ&s=5&u=https%3a%2f%2fwiki%2emozilla%2eorg%2fCA%2fCommunic
> ations%23November%5f2017%5fCA%5fCommunication

>
> Direct link to the survey:

> https://scanmail.trustwave.com/?c=4062&d=rPzw2czQrwDIggzGnHPfXELR5_onU
> Mc5SomUljKdiw&s=5&u=https%3a%2f%2fccadb-public%2esecure%2eforce%2ecom%
> 2fmozillacommunications%2fCACommunicationSurveySample%3fCACommunicatio
> nId%3da051J00003mogw7

>
> Thanks,
> Kathleen
>
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org

> https://scanmail.trustwave.com/?c=4062&d=rPzw2czQrwDIggzGnHPfXELR5_onU
> Mc5StnPlmSVhg&s=5&u=https%3a%2f%2flists%2emozilla%2eorg%2flistinfo%2fd
> ev-security-policy

>
_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org

https://scanmail.trustwave.com/?c=4062&d=rPzw2czQrwDIggzGnHPfXELR5_onUMc5StnPlmSVhg&s=5&u=https%3a%2f%2flists%2emozilla%2eorg%2flistinfo%2fdev-security-policy

[Kathleen Wilson]

On Wednesday, October 25, 2017 at 1:34:03 PM UTC-7, Jeremy Rowley wrote:
> Some initial thoughts
> 1. I'm a bit confused by bullet #2 in the survey. Wasn't it already the
> Mozilla policy that CAs could only use the blessed 10 methods of validation?
> I thought this was communicated in the previous letter?

It was in the April 2017 CA Communication:
https://wiki.mozilla.org/CA/Communications#April_2017

But it was not specifically stated in previous versions of Mozilla's Root Store Policy:
https://github.com/mozilla/pkipolicy/blob/2.4.1/rootstore/policy.md

I updated ACTION 1 to separate the changes into two lists:
- Changes that most likely require CA action
- Changes that are clarification of previously expected practice or policy

Does that help?

> 2. On bullet #3, I'm reading the wording to mean either 1) disclosed and
> audited or 2) revoked, not disclosed and either a) revoked or b) audited,
> correct? Rewording the language to be "must be either audited and disclosed
> or revoked in the Common CA Database" might clarify between the two.

This is referring to the item starting with: "Additional requirements were added for intermediate certificates that are used to sign certificates for S/MIME."

So, this is now the first bullet in Action 1.

Text updated.

> 3. On bullet #3, should you specify what audits are required for s/MIME in
> the email? There might be confusion between the two audit questions that
> interprets s/MIME as requiring a BR audit. This might not be worth
> clarifying though as all CAs should understand the purpose of each audit.

Added sentence: "See Section1.3.2 of Mozilla's Root Store Policy for details about required audits."

with link to:
https://www.mozilla.org/about/governance/policies/security-group/certs/policy#required-audits

> 4. On action 4, how often will Mozilla require BR Self assessments? Should
> you state that Mozilla may require them on a periodic basis going forward?

It is now part of our root inclusion/update process, but otherwise we have not yet decided if this will be a regularly-recurring exercise.

How about if I add a sentence like the following?
"We recommend that you perform a BR Self Self Assessment on a periodic basis to ensure that your CA is aware of and following updates to the BRs."

> 5. On action 7, I'm unaware of any CT discussions currently ongoing at the
> CAB Forum or Mozilla list. Could you provide a link or further intent on
> what we're watching for?

This is currently a place holder.
I would like to say something about CT, but still have to figure it out.

Thanks,
Kathleen

[Kathleen Wilson]

On Wednesday, October 25, 2017 at 2:05:33 PM UTC-7, Andrew Ayer wrote:
> Hi Kathleen,
>
> I suggest being explicit about which CAA errata Mozilla allows.
>
> For CNAME, it's erratum 5065.
>
> For DNAME, it's erratum 5097.
>
> Link to errata: https://www.rfc-editor.org/errata_search.php?rfc=6844
>

I added the link, and added a "TO DO" note regarding specifying the exact errata.

Looking forward to further discussion about which errata should be allowed.

Thanks,
Kathleen

[Gervase Markham]

On 27/10/17 00:23, Kathleen Wilson wrote:
> Looking forward to further discussion about which errata should be allowed.

Those are the correct two errata.

Gerv

[Kathleen Wilson]

It has been suggested that I need to communicate to CAs that there will
be consequences if their audit statements do not meet Mozilla’s
requirements, so how about if I add the following to the November CA
Communication?

~~
As stated in Mozilla’s April 2017 CA Communication[1] and Mozilla’s Root
Store Policy[2, 3] audit statements/letters must meet the following
requirements or Mozilla will reject the audit statements. And CAs
without proper and current audit statements will be put on notice and
potentially removed from Mozilla’s Root Store.

Additionally, audit statements must be provided in English from now on.

As a reminder, here is what Mozilla’s Root Store Policy[2, 3] currently
says:
“Full-surveillance period-of-time audits MUST be conducted and updated
audit information provided no less frequently than annually. Successive
audits MUST be contiguous (no gaps).
....
The publicly-available documentation relating to each audit MUST contain
at least the following clearly-labelled information:
- name of the company being audited;
- name and address of the organization performing the audit;
- Distinguished Name and SHA256 fingerprint of each root and
intermediate certificate that was in scope;
- audit criteria (with version number) that were used to audit each of
the certificates;
- a list of the CA policy documents (with version numbers) referenced
during the audit;
- whether the audit is for a period of time or a point in time;
- the start date and end date of the period, for those that cover a
period of time;
- the point-in-time date, for those that are for a point in time;
- the date the report was issued (which will necessarily be after the
end date or point-in-time date); and
- For ETSI, a statement to indicate if the audit was a full audit, and
which parts of the criteria were applied, e.g. DVCP, OVCP, NCP, NCP+,
LCP, EVCP, EVCP+, QCP-w, Part1 (General Requirements), and/or Part 2
(Requirements for trust service providers).
“

The above listed information MUST be provided by the auditor in each
audit statement or its accompanying letter. If the information is
provided in an accompanying letter, then the pdf file that is submitted
to Mozilla must contain BOTH the audit statement and the letter.

Please indicate your CA’s understanding that each audit statement/letter
provided to Mozilla must be in English and must meet the requirements of
Mozilla’s Root Store Policy, specifically stating the information listed
above. Otherwise Mozilla will reject the audit statement, and put the CA
on notice for being out of compliance, which may result in the CA’s root
certificate(s) being removed from our program.


[1]
https://ccadb-public.secure.force.com/mozillacommunications/CACommResponsesOnlyReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00018,Q00032

[2]
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#audit-parameters

[3]
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#public-audit-information

~~


As always, I will appreciate your thoughtful and constructive feedback
on this suggested addition to the draft of theNovember CA Communication.

Thanks,
Kathleen

[Kathleen Wilson]

All,

I have updated the draft of the November 2017 CA Communication as follows:

- Postponed the response deadline to December 15.

- Removed the CT item (that will be handled separately, later)

- Added an action item (#4) about full period-of-time audits with no
gaps. (resulted in a slight re-ordering of the action items)

- Added action to test the Problem Reporting email (added to ACTION #6)

- Added "Mozilla currently allows Errata ID 5065 and 5097." to the CAA
item (ACTION #7)

- Added an action item regarding the .tg Registry problems (ACTION #8)


Link to November 2017 CA Communication on wiki page:

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

Direct link to the survey:
https://ccadb-public.secure.force.com/mozillacommunications/CACommunicationSurveySample?CACommunicationId=a051J00003mogw7

I will greatly appreciate it if you will review and comment on this
version of the draft of the November 2017 CA Communication.

I am hoping to send it this week.

Thanks,
Kathleen

[Kathleen Wilson]

On 11/13/17 1:52 PM, Kathleen Wilson wrote:
> Link to November 2017 CA Communication on wiki page:
> https://wiki.mozilla.org/CA/Communications#November_2017_CA_Communication
>
> Direct link to the survey:
> https://ccadb-public.secure.force.com/mozillacommunications/CACommunicationSurveySample?CACommunicationId=a051J00003mogw7
>
>
> I will greatly appreciate it if you will review and comment on this
> version of the draft of the November 2017 CA Communication.
>
> I am hoping to send it this week.

Hey Everyone,

I am planning to send this CA Communication in about two hours. I will
send it to the Primary POCs and CC the CA's Email Alias 1 (as indicated
in the CCADB).

I will also post a related announcement in Mozilla's Security Blog
(https://blog.mozilla.org/security/).

Thanks,
Kathleen

[Kathleen Wilson]

The email is being sent now.

I have also posted about it in Mozilla's Security Blog:

https://blog.mozilla.org/security/2017/11/16/november-2017-ca-communication/

Thanks,
Kathleen