Re: Policy 2.4 Proposal: Add CC-0 license to policy

2016-11-30 Thread Gervase Markham 
On 30/11/16 21:58, Kurt Roeckx wrote:
>> This would involve adding a footer:
>>
>> Any copyright in this document is dedicated to the Public Domain.
>>
>> with the link being to http://creativecommons.org/publicdomain/zero/1.0/.
> 
> public domain and CC0 are very similar, but are not the same. I
> suggest you put CC0 there instead of PD.

The link is to CC-0. The reason the text says "dedicated to the Public
Domain" is that this is the goal of CC-0. (Where it's not possible, it
turns into a liberal license, but that's the goal.)

Presumably you are proposing alternative text like:

"This document is licensed under the Creative Commons Zero license."

?

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

Re: Policy 2.4 Proposal:Require open licensing of CPs and CPSes

2016-11-30 Thread Gervase Markham 
On 30/11/16 22:29, Han Yuwei wrote:
> Is there enough time for CAs to change their license?

This is a good question, but I would prefer we discuss them when I
start discussion on this topic. I am not starting discussion on all 17
topics at once in order to give people time to think about the 3 I have
started a discussion on.

So please, hold your point, and make it at the proper time :-)

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

Re: Policy 2.4 Proposal:Require full CP/CPS in English

2016-11-30 Thread Gervase Markham 
On 30/11/16 22:38, Han Yuwei wrote:
> I request to postpone this issue for further discussion for reasons below.
> 
> 1. Is English CP/CPS authoritative or just a plain translation?
> 2. Requesting every changes to be published in English?
> 3. What should we do if there is conflicts between English version and CA's 
> native language due to the culture differences?

These are good questions, but I would prefer we discuss them when I
start discussion on this topic. I am not starting discussion on all 17
topics at once in order to give people time to think about the 3 I have
started a discussion on.

So please, hold your points, and make them at the proper time :-)

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

Re: Discussion about restricting government roots to that country's TLD(s)

2016-11-30 Thread Gervase Markham 
On 30/11/16 23:25, Han Yuwei wrote:
> Github issue:https://github.com/mozilla/pkipolicy/issues/42

That issue is not currently targetted for 2.4. In the message titled
"Mozilla Root Store Policy 2.4: goals and process", I said:

> If you think any of them should be targetted at 2.4, please make the
> case in the thread attached to this message. Remember to explain how
> the change is either "urgent" or "relatively uncontroversial and
> self-contained".

Before we discuss this topic, you need to make that case. Otherwise, I
would ask that we not discuss it right now.

Gerv

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

Re: Policy 2.4 Proposal:Require full CP/CPS in English

2016-11-30 Thread David E. Ross 
On 11/30/2016 3:28 PM, Matt Palmer wrote [in part]:
> On Wed, Nov 30, 2016 at 02:38:44PM -0800, Han Yuwei wrote [also in part]:
>> I request to postpone this issue for further discussion for reasons below.
>>
>> 1. Is English CP/CPS authoritative or just a plain translation?
> 
> I expect it would be authoritative from Mozilla's perspective; that is, any
> deviations from the English document would be considered a failure to adhere
> to published expectations.  That would, I presume, require auditors to
> assert compliance to the English version of the CP/CPS also.

As an alternative, auditors should choose between (a) assert compliance
to the English version and (b) assert that the English version is an
accurate and complete translation of the version in the certification
authority's native language.

-- 
David E. Ross

The Crimea is Putin's Sudetenland.
The Ukraine will be Putin's Czechoslovakia.
See .
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.4 Proposal:Require full CP/CPS in English

2016-11-30 Thread Matt Palmer 
On Wed, Nov 30, 2016 at 02:38:44PM -0800, Han Yuwei wrote:
> I request to postpone this issue for further discussion for reasons below.
> 
> 1. Is English CP/CPS authoritative or just a plain translation?

I expect it would be authoritative from Mozilla's perspective; that is, any
deviations from the English document would be considered a failure to adhere
to published expectations.  That would, I presume, require auditors to
assert compliance to the English version of the CP/CPS also.

> 2. Requesting every changes to be published in English?

That would be reasonable to assume.

> 3. What should we do if there is conflicts between English version and CA's 
> native language due to the culture differences?

The English language version would be authoritative for any interaction
between Mozilla and the CA.

- Matt

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

Discussion about restricting government roots to that country's TLD(s)

2016-11-30 Thread Han Yuwei 
Github issue:https://github.com/mozilla/pkipolicy/issues/42

My opinions:

It's good to restrict government CAs to certain TLDs for reasons below

1. government CA is intented to provide domestic assurance of IDs and services 
for government's websites.

2. If we assume every government is "evil", we can limit its consequences in 
the corresponding ccTLD.

3. Make government CA dedicated for their people.

But there's also questions:

1.Policital Problems
Due to the word "country", there MUST be lots of policital problems. In a word, 
what we should do about ".tw"? (I am Chinese.)

2.Definition about "government CA"
Who can represent the government? NIC could be private (or not? I am not sure).

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

Continue discussion about "Define actions or practices that bar a company from being a trusted CA (#19)"

2016-11-30 Thread Han Yuwei 
In https://github.com/mozilla/pkipolicy/issues/19 Gerv talked about what 
shouldn't CA do but the discussion thread listed didn't continue.

There's my questions:
1. What's the definition about "The same organzition"?
The structure of large companys are very complicated now. With unaccoutable 
transactions of shares It's too hard for normal internet users like me to 
distinguish. And I can't easily know if shareholders' mind affected the 
company's running.

2. What's MITM-style ?
Since lots of CDNs like Cloudflare provide such a "MITI-style" service, there's 
a necessity to clarify it.

3. Is spying system avoidable?
Since major IT companys had involved in PRISM, it's time to face it.

4.Is government CAs acceptable?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Policy 2.4 Proposal:Require full CP/CPS in English

2016-11-30 Thread Han Yuwei 
I request to postpone this issue for further discussion for reasons below.

1. Is English CP/CPS authoritative or just a plain translation?
2. Requesting every changes to be published in English?
3. What should we do if there is conflicts between English version and CA's 
native language due to the culture differences?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Policy 2.4 Proposal:Require open licensing of CPs and CPSes

2016-11-30 Thread Han Yuwei 
Is there enough time for CAs to change their license?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.4 Proposal: Add CC-0 license to policy

2016-11-30 Thread Kurt Roeckx 
On Wed, Nov 30, 2016 at 09:34:11PM +, Gervase Markham wrote:
> CAs may want to copy bits of our policy into their working documents and
> other things; the best way to make that easy is to use CC-0.
> 
> This would involve adding a footer:
> 
> Any copyright in this document is dedicated to the Public Domain.
> 
> with the link being to http://creativecommons.org/publicdomain/zero/1.0/.

public domain and CC0 are very similar, but are not the same. I
suggest you put CC0 there instead of PD.


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

Policy 2.4 Proposal: Add CC-0 license to policy

2016-11-30 Thread Gervase Markham 
CAs may want to copy bits of our policy into their working documents and
other things; the best way to make that easy is to use CC-0.

This would involve adding a footer:

Any copyright in this document is dedicated to the Public Domain.

with the link being to http://creativecommons.org/publicdomain/zero/1.0/.

This is: https://github.com/mozilla/pkipolicy/issues/35

---

This is a proposed update to Mozilla's root store policy for version
2.4. Please keep discussion in this group rather than on Github. Silence
is consent.

Policy 2.3 (current version):
https://github.com/mozilla/pkipolicy/blob/2.3/rootstore/policy.md
Update process:
https://wiki.mozilla.org/CA:CertPolicyUpdates
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Policy 2.4 Proposal: Replace all occurrences of 'CA' with "Certification Authority' when that is the intended meaning

2016-11-30 Thread Gervase Markham 
We need to be clear in our terminology. The policy itself uses "CA" (or
"issuing CA" or "subordinate CA") to refer to the organization and "CA
certificate" to refer to the certificate fairly consistently. The two
exceptions which need fixing are:

Inclusion point 5 ("additional CAs")
Inclusion point 18 ("CA hierarchy") x 2

We should update those to "additional CA certificates" and "CA
certificate hierarchy" respectively. I think that then the policy will
be internally consistent.

This is: https://github.com/mozilla/pkipolicy/issues/40

---

This is a proposed update to Mozilla's root store policy for version
2.4. Please keep discussion in this group rather than on Github. Silence
is consent.

Policy 2.3 (current version):
https://github.com/mozilla/pkipolicy/blob/2.3/rootstore/policy.md
Update process:
https://wiki.mozilla.org/CA:CertPolicyUpdates
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Mozilla Root Store Policy 2.4: goals and process

2016-11-30 Thread Gervase Markham 
Hi all,

The Mozilla root store policy has not been updated since July 2013 - 3.5
years ago. We are now on the verge of shipping version 2.3, which
contains some edits which have been pending for more than a year, agreed
during the last period of policy update activity. That version will be
applicable immediately. The goal of version 2.4 is to do any updates
which are either urgent, or relatively uncontroversial and
self-contained, so we can ship another version soon which deals with
much of the backlog and out-of-dateness. This will hopefully give us the
breathing space to look at the tougher and more widely-scoped issues
over a longer timescale.

Therefore, further to the process outlined here:
https://wiki.mozilla.org/CA:CertPolicyUpdates
I want to kick off some discussions about changes which potentially
might make it into the next version of our root store policy, version
2.4 - i.e. ones which are currently triaged as targetting 2.4. If a
particular update balloons into a complex discussion, we may decide to
postpone it.

Here is policy version 2.3, the base version we will be working from:
https://github.com/mozilla/pkipolicy/blob/2.3/rootstore/policy.md

Policy update proposals are now tracked in Github. Those proposals _not_
currently targetted at 2.4 are here:
https://github.com/mozilla/pkipolicy/issues?utf8=%E2%9C%93=is%3Aissue%20is%3Aopen%20no%3Amilestone

If you think any of them should be targetted at 2.4, please make the
case in the thread attached to this message. Remember to explain how the
change is either "urgent" or "relatively uncontroversial and
self-contained".

I will start new individual message threads for the update proposals
which are currently targetted for 2.4, on a staggered basis. The full
list of those is here:
https://github.com/mozilla/pkipolicy/issues?q=is%3Aopen+is%3Aissue+milestone%3A2.4
There are currently 17 of them. Let's try and keep discussion on the
mailing list, and put the results back in Github, and see how that goes
as a work mode. We will be operating on a "silence is consent" model -
if there is no discussion of or dissent against a change and I think
it's a good idea, it's going in.

Mozilla employee interactions may be reduced a little bit next week as
it's the Mozilla 6-monthly get-together. But hopefully they will pick up
after that, and beyond Christmas.

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

Policy 2.4 Proposal: Make clear that duplicate serial numbers are OK when supporting CT

2016-11-30 Thread Gervase Markham 
At least for RFC 6962 (-bis is a different issue), pre-certs are certs
and so the duplication of (issuer name, serial number) between the
pre-cert and the cert is technically a violation of Mozilla policy; we
reserve the right not to include CAs who issue certs with "duplicate
issuer names and serial numbers".

We should make it clear that this is OK in the CT case. I propose the
following change:

duplicate issuer names and serial numbers;

->

duplicate issuer names and serial numbers (except that a Certificate
Transparency pre-certificate is allowed to match the corresponding
certificate);

This is: https://github.com/mozilla/pkipolicy/issues/41

---

This is a proposed update to Mozilla's root store policy for version
2.4. Please keep discussion in this group rather than on Github. Silence
is consent.

Policy 2.3 (current version):
https://github.com/mozilla/pkipolicy/blob/2.3/rootstore/policy.md
Update process:
https://wiki.mozilla.org/CA:CertPolicyUpdates
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Apple's Further Steps for WoSign

2016-11-30 Thread certificate-authority-prog...@group.apple.com 


Further Steps for WoSign

After further investigation we have concluded that in addition to multiple 
control failures in the operation of the WoSign certificate authority (CA), 
WoSign did not disclose the acquisition of StartCom.

We are taking further actions to protect users in an upcoming security update.  
Apple products will block certificates from WoSign and StartCom root CAs if the 
"Not Before" date is on or after 1 Dec 2016 00:00:00 GMT/UTC.

Regards,

Apple Root Certificate Program

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