> 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
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
Gervase Markham wrote:
> Just to help me be clear: the request is for the inclusion of a root
> with the same DN as a previous root, which will still be included after
> the addition? Or the problem with duplicate DNs occurs further down the
> hierarchy?
Some people claimed some software may be u
Gervase Markham wrote:
> We want to change the policy to make it clear that whether a cert is
> covered by our policy or not is dependent on whether it is technically
> capable of issuing server certs, not whether it is intended by the CA
> for issuing server certs.
NIT: The issue isn't whether i
Gervase Markham wrote:
> Add a requirement that every OCSP response must have a nextUpdate field.
> This is required to ensure that OCSP stapling works reliably with all
> (at least most) server and client products.
>
> Proposal: update the second bullet in point 3 of the Maintenance section
> so
Gervase Markham wrote:
> On 05/12/16 12:43, Brian Smith wrote:
>> However, I do think that if a CA certificate is name constrained to not
>> allow any dNSName or iPAddress names, and/or it EKU that doesn't contain
>> id-kp-serverAuth, then it shouldn't be in scope of the proposal. Either
>> condit
On 05/12/16 12:43, Brian Smith wrote:
> However, I do think that if a CA certificate is name constrained to not
> allow any dNSName or iPAddress names, and/or it EKU that doesn't contain
> id-kp-serverAuth, then it shouldn't be in scope of the proposal. Either
> condition is sufficient.
Can we get
Gervase Markham wrote:
> On 07/12/16 12:44, Brian Smith wrote:
>> Notice in the BRs that the KeyUsage extension (not to be confused with the
>> ExtendedKeyUsage extension we're talking about here) is optional. Why is it
>> OK to be optional? Because the default implementation allows all usages,
>>
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.
>
> Proposa
Gervase Markham wrote:
> On 05/12/16 12:43, Brian Smith wrote:
>> Let's consider the cases:
>>
>> A root CA: It is in scope if it has the SSL trust bit.
>>
>> An intermediate CA: It is in scope unless all the trusted certificates
>> issued for it have an EKU that excludes id-kp-serverAuth.
>
> No;
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 addi
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
Add a requirement that every OCSP response must have a nextUpdate field.
This is required to ensure that OCSP stapling works reliably with all
(at least most) server and client products.
Proposal: update the second bullet in point 3 of the Maintenance section
so that the last sentence reads:
OCSP
On 07/12/16 12:44, Brian Smith wrote:
> Notice in the BRs that the KeyUsage extension (not to be confused with the
> ExtendedKeyUsage extension we're talking about here) is optional. Why is it
> OK to be optional? Because the default implementation allows all usages,
> including in particular the u
We want to change the policy to make it clear that whether a cert is
covered by our policy or not is dependent on whether it is technically
capable of issuing server certs, not whether it is intended by the CA
for issuing server certs.
Until we change Firefox to require id-kp-serverAuth, the polic
On 05/12/16 21:10, Wen-Cheng Wang wrote:
> I mean BR Audit is specifically for CAs that provide SSL
> certificates. Therefore, it is not possible to conduct on those
> subordinate CAs that do not provide SSL certificates,
AIUI, that's not actually true. As we found out recently when discussing
an
On 05/12/16 13:41, Richard Wang wrote:
> We checked our system, this order is from one of the reseller. We
> have many resellers that used the API, we noticed all resellers to
> close the free SSL, but they need some time to update the system.
More than two months?
Has this reseller given a time
On 30/11/16 11:33, Gervase Markham wrote:
> 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
Result: resolved as proposed.
On 30/11/16 11:31, Gervase Markham wrote:
> We should make it clear that this is OK in the CT case. I propose the
> following change:
Result: resolved as specified.
Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://
On 30/11/16 11:34, 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.
>
On 05/12/16 12:43, Brian Smith wrote:
> Let's consider the cases:
>
> A root CA: It is in scope if it has the SSL trust bit.
>
> An intermediate CA: It is in scope unless all the trusted certificates
> issued for it have an EKU that excludes id-kp-serverAuth.
No; it's in scope unless it has cons
21 matches
Mail list logo
