Re: In September 29, 2016, WoSign stop issuing free certificate, but I still successfully get it.

[Percy]

On Saturday, December 10, 2016 at 8:29:29 PM UTC-8, Richard Wang wrote:
> Our promise is close the free SSL application in our own website: 
> buy.wosign.com.
> 
> And now we closed it in our PKI side.
> 
> 
> Best Regards,
> 
> Richard
> 
> > On 9 Dec 2016, at 04:17, Gervase Markham  wrote:
> > 
> >> 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 timeline by which they expect to have ceased
> > to use the API?
> > 
> >> The
> >> most important thing is this certificate is issued by proper way that
> >> this subscriber finished the domain validation, so this is not a
> >> mis-issuance, not "deceiving".
> > 
> > This is narrowly true, from a Mozilla perspective. Mozilla has not
> > required that WoSign stop issuing certificates. We have just said that
> > we no longer trust them. Of course, I don't know what commitments WoSign
> > has made to other root stores. And indeed, no-one has suggested that
> > this certificate is mis-issued from a domain validation perspective.
> > 
> > There is an issue relating to the difference between WoSign's public
> > statement on their website that they have ceased free SSL issuance, and
> > the reality that they have not. We expect CAs who make public statements
> > about their actions to abide by those statements.
> > 
> > Gerv
Sorry. You just said there is no deadline? Which is it? 

-

Sorry, we don't have deadline. 
And no plan to close it in PKI side, we keep the right to active it at any 
time, and we can issue this free SSL certificate for subscribers at any time if 
customers need it. 

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

Re: In September 29, 2016, WoSign stop issuing free certificate, but I still successfully get it.

[Richard Wang]

Our promise is close the free SSL application in our own website: 
buy.wosign.com.

And now we closed it in our PKI side.


Best Regards,

Richard

> On 9 Dec 2016, at 04:17, Gervase Markham  wrote:
> 
>> 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 timeline by which they expect to have ceased
> to use the API?
> 
>> The
>> most important thing is this certificate is issued by proper way that
>> this subscriber finished the domain validation, so this is not a
>> mis-issuance, not "deceiving".
> 
> This is narrowly true, from a Mozilla perspective. Mozilla has not
> required that WoSign stop issuing certificates. We have just said that
> we no longer trust them. Of course, I don't know what commitments WoSign
> has made to other root stores. And indeed, no-one has suggested that
> this certificate is mis-issued from a domain validation perspective.
> 
> There is an issue relating to the difference between WoSign's public
> statement on their website that they have ceased free SSL issuance, and
> the reality that they have not. We expect CAs who make public statements
> about their actions to abide by those statements.
> 
> Gerv


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

Re: In September 29, 2016, WoSign stop issuing free certificate, but I still successfully get it.

[Richard Wang]

As I said before, you finished the domain validation.
This is DV SSL that no need to do the manual validation.

Best Regards,

Richard

> On 10 Dec 2016, at 09:33, "zbw...@gmail.com"  wrote:
> 
> 在 2016年12月6日星期二 UTC+8上午6:50:04，Percy写道：
>> lslqtz,
>> How did you obtain this certificate from WoSign? Through the public website 
>> or some other means?
> 
> I get this certificate through the dealer's website, but the dealer and 
> WoSign API are not doing the verification, the final manual audit also passed.
> ___
> 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

Re: Policy 2.4 Proposal: Require all OCSP responses to have a nextUpdate field

[Brian Smith]

Gervase Markham  wrote:
> On 08/12/16 12:46, Brian Smith wrote:
>> Are you intending to override the BR laxness for maximum OCSP lifetime
>> for intermedaites, or just match the BR requirements?
>
> The wider context of this section includes an "For end-entity
> certificates:". So the wording as proposed matches the BRs in terms of
> duration.

OK. This means that the policy isn't really sufficient for use with
the OCSP mult-stapling extension. Mutli-stapling only works well when
the OCSP responses for the intermediate CA certificates are treated
like what is proposed for end-entity certificates w.r.t. nextUpdate.

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

Re: Policy 2.4 Proposal: Use language of capability throughout

[Brian Smith]

On Thu, Dec 8, 2016 at 10:46 AM, 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.

I'll quote part of the proposed change here:

> 2. Intermediate certificates which have at least one valid, unrevoked chain up
> to such a CA certificate and which are not technically constrained such
> that they are unable to issue server or email certificates. Such technical
> constraints could consist of either:
> * an Extended Key Usage (EKU) extension which does not contain either of the
>   id-kp-serverAuth and id-kp-emailProtection EKUs; or:
> * name constraints which do not allow SANs of any of the following types:
>   dNSName, iPAddress, SRVName, rfc822Name
>
> 3. End-entity certificates which have at least one valid, unrevoked chain up 
> to
> such a CA certificate through intermediate certificates which are all in
> scope, such end-entity certificates having either:
> * an Extended Key Usage (EKU) extension which contains one or more of the
>   id-kp-serverAuth and id-kp-emailProtection EKUs; or:
> * no EKU extension.

Again, it doesn't make sense to say that the forms of names matter for
name constraints, but don't matter for end-entity certificates. If an
end-entity certificate doesn't contain any names of the forms dNSName,
iPAddress, SRVName, rfc822Name, then it shouldn't be in scope.

Also, the way that the text is worded the above means that an
intermediate certificate that contains anyExtendedKeyUsage in its EKU
would be considered out of scope of Mozilla's policy. However, you
need to have such certificates be in scope so that you can forbid them
from using anyExtendedKeyUsage.

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

Re: Policy 2.4 Proposal: Use language of capability throughout

[Brian Smith]

Gervase Markham  wrote:
> On 08/12/16 13:06, Brian Smith wrote:
>> In particular, I suggest replacing "unable to issue server or email
>> certificates" with "unable to issue *trusted* server or email
>> certificates" or similar.
>
> I think I would prefer not to make that tie, because the obvious
> question is "trusted in which version of Firefox"? I would prefer to
> modify Firefox and the policy to match, but have the ability to skew
> those two updates as necessary, rather than tie the policy to what
> Firefox does directly.

"Unable to issue" means "unable to sign with the private key" which
can only happen if they don't have the private key. But they do have
the private key so they're always able to issue certificates with any
contents they want. Thus "unable to issue" is a not a useful criteria
since no CA meets it and so you need a different criteria.

Cheers,
Brian
-- 
https://briansmith.org/
___
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

[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