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

2016-12-21 Thread Eric Mill
It's not a big deal. The important part is that there's flexibility for
entities in novel legal situations to meet the intent of the policy, which
this does.

On Wed, Dec 21, 2016 at 12:38 AM, Jakob Bohm  wrote:

> On 16/12/2016 16:10, Gervase Markham wrote:
>
>> On 14/12/16 23:13, Eric Mill wrote:
>>
>>> Sure, that works. Is the "in writing" part necessary? You might say
>>> instead
>>> "publicly accepted by Mozilla.", which would imply text on m.d.s.p or
>>> bugzilla that would necessarily be in writing, while also ensuring better
>>> visibility.
>>>
>>
>> I'm not sure what you are getting at; m.d.s.p is "in writing", as is "in
>> Bugzilla". I say "in writing" because I want to make sure some CA
>> doesn't come back with "you said it was OK when we chatted at CAB
>> Forum", or "you implied it was OK by accepting this other license over
>> here which is almost the same".
>>
>>
> I guess he meant that an "in writing" acceptance in an obscure or
> non-public forum (such as IRC or private e-mail) should not count,
> since it is not auditable which such acceptances exist.
>
> But it seems most objections have been ignored and the draconian rule
> instated.
>
>
> Enjoy
>
> Jakob
> --
> Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
> Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
> This public discussion message is non-binding and may contain errors.
> WiseMo - Remote Service Management for PCs, Phones and Embedded
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>



-- 
konklone.com | @konklone 
___
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-12-21 Thread Gervase Markham
On 21/12/16 05:38, Jakob Bohm wrote:
>> I'm not sure what you are getting at; m.d.s.p is "in writing", as is "in
>> Bugzilla". I say "in writing" because I want to make sure some CA
>> doesn't come back with "you said it was OK when we chatted at CAB
>> Forum", or "you implied it was OK by accepting this other license over
>> here which is almost the same".
> 
> I guess he meant that an "in writing" acceptance in an obscure or
> non-public forum (such as IRC or private e-mail) should not count,
> since it is not auditable which such acceptances exist.

It doesn't need to be auditable; CAs are not audited against Mozilla's
policy requirements. And Mozilla knows what license use permissions it
has given out. Regardless, we would expect to publish any such
exceptions granted in the application bug or some other obvious place.

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-12-20 Thread Jakob Bohm

On 16/12/2016 16:10, Gervase Markham wrote:

On 14/12/16 23:13, Eric Mill wrote:

Sure, that works. Is the "in writing" part necessary? You might say instead
"publicly accepted by Mozilla.", which would imply text on m.d.s.p or
bugzilla that would necessarily be in writing, while also ensuring better
visibility.


I'm not sure what you are getting at; m.d.s.p is "in writing", as is "in
Bugzilla". I say "in writing" because I want to make sure some CA
doesn't come back with "you said it was OK when we chatted at CAB
Forum", or "you implied it was OK by accepting this other license over
here which is almost the same".



I guess he meant that an "in writing" acceptance in an obscure or
non-public forum (such as IRC or private e-mail) should not count,
since it is not auditable which such acceptances exist.

But it seems most objections have been ignored and the draconian rule
instated.


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
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-12-16 Thread Gervase Markham
On 14/12/16 23:13, Eric Mill wrote:
> Sure, that works. Is the "in writing" part necessary? You might say instead
> "publicly accepted by Mozilla.", which would imply text on m.d.s.p or
> bugzilla that would necessarily be in writing, while also ensuring better
> visibility.

I'm not sure what you are getting at; m.d.s.p is "in writing", as is "in
Bugzilla". I say "in writing" because I want to make sure some CA
doesn't come back with "you said it was OK when we chatted at CAB
Forum", or "you implied it was OK by accepting this other license over
here which is almost the same".

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-12-16 Thread Gervase Markham
On 08/12/16 20:48, Gervase Markham wrote:
> Require CAs to publish their CPs and CPSes under one of the following
> Creative Commons licenses: CC-BY, CC-BY-SA or CC-BY-ND.
> 
> This is so that there is no legal impediment to their proper storage,
> scrutiny etc. by relying parties.
> 
> Proposal: add an additional paragraph to point 17 of the Inclusion
> policy, as follows:
> 
> CPs and CPSes must be made available to Mozilla under one of the
> following Creative Commons licenses: Attribution (CC-BY),
> Attribution-ShareAlike (CC-BY-SA) or Attribution-NoDerivs (CC-BY-ND). If
> none of these licenses is indicated, the fact of application is
> considered as permission from the CA to allow Mozilla and the public to
> deal with these documents, and any later versions for root certificates
> which are included in Mozilla's trust store, under CC-BY-ND.
> 
> (We would add links to the relevant license terms where each is mentioned.)

Resolution: resolved as specced, with the addition of a CC-0 option,
version information, and a clause about equivalent licensing terms.

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-12-14 Thread Gervase Markham
On 12/12/16 05:35, Eric Mill wrote:
> It's possible there are other edge cases out there that make blanket CC0 or
> CC-BY nor practical. I think adding some catch-all text that allows for a
> solution ensuring no copyright-based restrictions of any kind would allow
> for the bit of flexibility those cases need.

"Or other equally permissive licensing terms accepted by Mozilla in
writing"?

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-12-11 Thread Eric Mill
An edge case: works of the US government, whether documents or code, are
not copyrightable in the US, and so they can't be licensed or dedicated to
the public domain in the US. There is some discussion of this here:
https://theunitedstates.io/licensing/ (Note: I'm an author of that, in an
old work capacity.)

One approach I've seen US government groups take (and have taken in my
current work capacity) is to acknowledge that the contents are not
copyrightable in the US, while using CC0 for an international context:

https://github.com/18F/open-source-policy/blob/master/LICENSE.md

It's possible there are other edge cases out there that make blanket CC0 or
CC-BY nor practical. I think adding some catch-all text that allows for a
solution ensuring no copyright-based restrictions of any kind would allow
for the bit of flexibility those cases need.

On Fri, Dec 9, 2016 at 8:38 PM, Gervase Markham  wrote:

> On 08/12/16 15:33, Jonathan Rudenberg wrote:
> > I think this is reasonable. Does it make sense to add CC0 to the list
> > as well? This would provide an even more permissive license option
> > than CC-BY.
>
> Yes, that makes sense.
>
> Gerv
>
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>



-- 
konklone.com | @konklone 
___
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-12-11 Thread Gervase Markham
On 08/12/16 11:41, Jakob Bohm wrote:
> This could easily conflict with other legal obligations, such as
> requirements to license said documents under a specific other license.

I don't think so; nothing prevents a CA providing multiple potential
sets of license terms for a document.

> It would be more realistic

and longer and more complicated and more prone to error...

> It is in particular noted that these things are a lot less than what
> any of the regular CC licenses permit.  For example, Mozilla has no
> reason to require that other CA operators be permitted to reuse the
> documents as their own, even though such other CA operators are
> encouraged to participate in the permitted activities, such as publicly
> talking about the practices of their competitor.

Well, if they want to become a CA without any ability to change their CP
and CPS, and with every other page of it branded with the brand of
competitor... That seems somewhat unlikely. The default license Mozilla
is planning to assume in absence of anything else is an ND license,
which means No Derivatives. So it seems unlikely to me that some CA
would go into operation with another CA's unmodified documents. And if
they did, they'd be BR-noncompliant within a year, as the BRs require a
yearly update to those documents.

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-12-10 Thread Nick Lamb
On Thursday, 8 December 2016 21:42:29 UTC, Jakob Bohm  wrote:
> This could easily conflict with other legal obligations, such as
> requirements to license said documents under a specific other license.
> 
> It would be more realistic to add wording which simply requires the
> specific things that Mozilla, Relying parties, Subscribers and other
> interested parties (such as the participants in this group) should be
> allowed to do with those documents

I am sympathetic to this argument, on the other hand, it would seem 
extraordinary to me if a would-be public Certificate Authority is unwilling to 
accept Gerv's last "considered as permission" outcome. If a CA is obliged to, 
for example, add some particular government license, or a license chosen by 
another trust store then sure, they can't instead choose a CC license. But that 
also gives them no reason to be hostile to the idea of Mozilla treating their 
application as permission to handle it under CC-BY-ND.

A reason to like Gerv's approach is that we're content CC-BY-ND does what we 
actually want. An explicit list of requirements is subject to lawyer weaselling 
e.g. maybe we say Mozilla's users must be able to quote the CPS to pass comment 
on it, and some lawyer somewhere decides they can meet that requirement by 
demanding any users submit their proposed comment on paper to the lawyers and 
wait up 60 working days for permission which "shall not unreasonably be 
withheld"... thereby meeting the letter of the rules but destroying the spirit.
___
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-12-09 Thread Gervase Markham
On 08/12/16 15:33, Jonathan Rudenberg wrote:
> I think this is reasonable. Does it make sense to add CC0 to the list
> as well? This would provide an even more permissive license option
> than CC-BY.

Yes, that makes sense.

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-12-09 Thread Jakob Bohm

On 09/12/2016 00:48, David E. Ross wrote:

On 12/8/2016 1:41 PM, Jakob Bohm wrote [in part]:

It is in particular noted that these things are a lot less than what
any of the regular CC licenses permit.  For example, Mozilla has no
reason to require that other CA operators be permitted to reuse the
documents as their own, even though such other CA operators are
encouraged to participate in the permitted activities, such as publicly
talking about the practices of their competitor.


The Attribution-NoDerivs (CC-BY-ND) license cited by Markham does what
you request: limit the use of the subject documents to distribution
without alteration.  Thus, a certification authority's CP covered by
CC-BY-ND could not be reused by another certification authority because
such reuse would involve changing the name of the certification
authority within the CP.



Use by another CA does not *necessarily* require rewording of the
documents, someone brash enough to do that might have not qualms about
leaving the original CAs name in the legal document and just explaining
it away outside the document.

Also such reuse by a competing CA was just one of two *examples* I gave
of why a CA might not want to use a specific license of Mozilla's
choosing.

The other /example/ I gave was that they might be under legal
obligation (e.g. to governments, digital signature laws etc.) do use a
different license that happens to be sufficiently permissive (it could
even be more permissive than CC-BY-ND, just with different legal
details).

For example, a CP or CPS document might incorporate text from (or even
being) an official digital signature standard or digital signature law,
subject to whichever license applies to other standards/laws issued by
the same body.  Thus the copyright in the CP/CPS might partially belong
to e.g. ETSI or the government of country XX.

Hence why I suggested providing a list of actual requirements, similar
to how other open projects deal with requirements for 3rd party
licenses.  For example, standards organizations typically requires Free
(as in beer) licensing or standardized technology (some even accept
RAND licensing).

I also don't think Mozilla requires all libraries linked into official
Firefox downloads to be under a Mozilla license (GPL/MPL/etc.), as long
as they don't interfere with the Mozilla licensing.

As a third example, the text of the GPL license applied to Mozilla
source code is itself not under the GPL or any CC license, but under
specific terms found in the preamble of the GPL text.


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
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-12-09 Thread Han Yuwei
在 2016年12月9日星期五 UTC+8上午5:42:29,Jakob Bohm写道:
> On 08/12/2016 21:48, Gervase Markham wrote:
> > Require CAs to publish their CPs and CPSes under one of the following
> > Creative Commons licenses: CC-BY, CC-BY-SA or CC-BY-ND.
> >
> > This is so that there is no legal impediment to their proper storage,
> > scrutiny etc. by relying parties.
> >
> > Proposal: add an additional paragraph to point 17 of the Inclusion
> > policy, as follows:
> >
> > CPs and CPSes must be made available to Mozilla under one of the
> > following Creative Commons licenses: Attribution (CC-BY),
> > Attribution-ShareAlike (CC-BY-SA) or Attribution-NoDerivs (CC-BY-ND). If
> > none of these licenses is indicated, the fact of application is
> > considered as permission from the CA to allow Mozilla and the public to
> > deal with these documents, and any later versions for root certificates
> > which are included in Mozilla's trust store, under CC-BY-ND.
> >
> > (We would add links to the relevant license terms where each is mentioned.)
> >
> 
> This could easily conflict with other legal obligations, such as
> requirements to license said documents under a specific other license.
> 
> It would be more realistic to add wording which simply requires the
> specific things that Mozilla, Relying parties, Subscribers and other
> interested parties (such as the participants in this group) should be
> allowed to do with those documents, for example:
> 
>   - Publicly and privately read the documents.
>   - Publicly and privately Comment on and discuss the documents and
>their meaning, including quoting from the documents in such
>discussions.
>   - Storing, disseminating etc. discussion messages, regardless if they
>contain such quotations or not.
>   - Store complete unaltered copies for later reference, even after a
>document is no longer applicable, and make such unaltered copies
>available as documentation as to what those documents contained at
>relevant times in the past.
>   - Create non-binding "printouts" in formats such as paper, onscreen
>display, copies in formats suitable for such use (including plain
>text etc.).
>   - Apply technical precautions to ensure the permitted copies do not
>change content or meaning.  (For example, if the original document is
>provided as a HTML5 file, embedded script, CSS etc. might cause it to
>change depending on when, where and by whom it is being read, many
>other file formats have similar risks).
>   - Act and make decisions in reliance on those documents to the extend
>Mozilla had not received prior notification of changes to document
>content or validity.
> 
> It is in particular noted that these things are a lot less than what
> any of the regular CC licenses permit.  For example, Mozilla has no
> reason to require that other CA operators be permitted to reuse the
> documents as their own, even though such other CA operators are
> encouraged to participate in the permitted activities, such as publicly
> talking about the practices of their competitor.
> 
> 
> Enjoy
> 
> Jakob
> -- 
> Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
> Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
> This public discussion message is non-binding and may contain errors.
> WiseMo - Remote Service Management for PCs, Phones and Embedded

I agree with you.

So anyone can explain why we require the specific license on CP/CPS?
___
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-12-08 Thread Jonathan Rudenberg

> On Dec 8, 2016, at 12:48, Gervase Markham  wrote:
> 
> Require CAs to publish their CPs and CPSes under one of the following
> Creative Commons licenses: CC-BY, CC-BY-SA or CC-BY-ND.

I think this is reasonable. Does it make sense to add CC0 to the list as well? 
This would provide an even more permissive license option than CC-BY.

Jonathan

___
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-12-08 Thread David E. Ross
On 12/8/2016 12:48 PM, Gervase Markham wrote:
> Require CAs to publish their CPs and CPSes under one of the following
> Creative Commons licenses: CC-BY, CC-BY-SA or CC-BY-ND.
> 
> This is so that there is no legal impediment to their proper storage,
> scrutiny etc. by relying parties.
> 
> Proposal: add an additional paragraph to point 17 of the Inclusion
> policy, as follows:
> 
> CPs and CPSes must be made available to Mozilla under one of the
> following Creative Commons licenses: Attribution (CC-BY),
> Attribution-ShareAlike (CC-BY-SA) or Attribution-NoDerivs (CC-BY-ND). If
> none of these licenses is indicated, the fact of application is
> considered as permission from the CA to allow Mozilla and the public to
> deal with these documents, and any later versions for root certificates
> which are included in Mozilla's trust store, under CC-BY-ND.
> 
> (We would add links to the relevant license terms where each is mentioned.)
> 
> This is: https://github.com/mozilla/pkipolicy/issues/12
> 
> ---
> 
> 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
> 

Great idea.  If the public is to trust the certificates of certification
authorities, the public should be able to access, view, and even copy
those authorities' CPs and CPSs.

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