Re: DRAFT November 2017 CA Communication

[Kathleen Wilson via dev-security-policy]

On 11/16/17 10:04 AM, Kathleen Wilson wrote:

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=a051J3mogw7 



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




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

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

Re: DRAFT November 2017 CA Communication

[Kathleen Wilson via dev-security-policy]

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=a051J3mogw7 



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


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

Re: DRAFT November 2017 CA Communication

[Kathleen Wilson via dev-security-policy]

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=a051J3mogw7

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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DRAFT November 2017 CA Communication

[Kathleen Wilson via dev-security-policy]

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=a05o03WrzBC=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


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

Re: DRAFT November 2017 CA Communication

[Gervase Markham via dev-security-policy]

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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DRAFT November 2017 CA Communication

[Kathleen Wilson via dev-security-policy]

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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: DRAFT November 2017 CA Communication

[Tim Hollebeek via dev-security-policy]

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=trustwave@lists.mozilla.org] 
On Behalf Of Andrew Ayer via dev-security-policy
Sent: Wednesday, October 25, 2017 5:05 PM
To: Kathleen Wilson <kwil...@mozilla.com>
Cc: Kathleen Wilson via dev-security-policy 
<dev-security-policy@lists.mozilla.org>; 
mozilla-dev-security-pol...@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=rPzw2czQrwDIggzGnHPfXELR5_onUMc5So6YlzbIiQ=5=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-security-policy@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=rPzw2czQrwDIggzGnHPfXELR5_onU
> Mc5St_PkWKbjQ=5=https%3a%2f%2fwiki%2emozilla%2eorg%2fCA%2fCommunic
> ations%23November%5f2017%5fCA%5fCommunication
> 
> Direct link to the survey:
> https://scanmail.trustwave.com/?c=4062=rPzw2czQrwDIggzGnHPfXELR5_onU
> Mc5SomUljKdiw=5=https%3a%2f%2fccadb-public%2esecure%2eforce%2ecom%
> 2fmozillacommunications%2fCACommunicationSurveySample%3fCACommunicatio
> nId%3da051J3mogw7
> 
> Thanks,
> Kathleen
> 
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://scanmail.trustwave.com/?c=4062=rPzw2czQrwDIggzGnHPfXELR5_onU
> Mc5StnPlmSVhg=5=https%3a%2f%2flists%2emozilla%2eorg%2flistinfo%2fd
> ev-security-policy
> 
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://scanmail.trustwave.com/?c=4062=rPzw2czQrwDIggzGnHPfXELR5_onUMc5StnPlmSVhg=5=https%3a%2f%2flists%2emozilla%2eorg%2flistinfo%2fdev-security-policy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DRAFT November 2017 CA Communication

[Andrew Ayer via dev-security-policy]

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
 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://wiki.mozilla.org/CA/Communications#November_2017_CA_Communication
> 
> Direct link to the survey:
> https://ccadb-public.secure.force.com/mozillacommunications/CACommunicationSurveySample?CACommunicationId=a051J3mogw7
> 
> Thanks,
> Kathleen
> 
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
> 
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: DRAFT November 2017 CA Communication

[Jeremy Rowley via dev-security-policy]

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? 

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla
.org] On Behalf Of Kathleen Wilson via dev-security-policy
Sent: Wednesday, October 25, 2017 1:47 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: DRAFT November 2017 CA Communication

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/CACommunicationS
urveySample?CACommunicationId=a051J3mogw7

Thanks,
Kathleen

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


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy