Re: In September 29, 2016, WoSign stop issuing free certificate, but I still successfully get it.
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.
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.
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
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
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
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
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