Re: Does Heartbleed count for the purposes of BR 4.9.1.1 point 11? ("proven or demonstrated method")

[Han Yuwei via dev-security-policy]

在 2019年5月27日星期一 UTC+8上午10:05:25，Matt Palmer写道：
> On Sun, May 26, 2019 at 06:57:08PM -0700, Han Yuwei via dev-security-policy 
> wrote:
> > If malloc() is correctly implemented, private keys are secure from 
> > Heartbleed. So
> > I think it doesn't meet the criteria.
> 
> Just to make sure I'm understanding you correctly, you're saying that being
> vulnerable to Heartbleed doesn't *necessarily* expose private keys, it
> requires an additional criteria (malloc being "incorrectly implemented"),
> thus it doesn't fit the definition of a "proven method that exposes the
> Subscriber's Private Key to compromise"?
> 
> > CAs can't revoke a certificate without noticing subscriber in advance.
> 
> Can you point me to where that requirement comes from?  Some CAs don't
> necessarily have *any* notification method for their subscribers (Let's
> Encrypt immediately comes to mind); does that mean they're immune from
> revocation requirements?  Is there any requirement around how quickly CAs
> are required to notify subscribers, and does that time come out of the 24
> hour / 5 day budget, or is it some additional time period?
> 
> > But if any bugs found in future which can retrieve private keys from TLS 
> > endpoints, 
> > you can just use automated tools to scan them and get private keys to 
> > request a
> > revoke. I thought this is the best practice to this BR.
> 
> OK, so that's one vote for "just scan the Internet and drop private keys on
> CAs for revocation within 24 hours".
> 
> - Matt

1. Yes, it doesn't fit ( for what I thought)
2. I missed some words. please add "without proven fact that the certificate is 
not secure"

I thought what Matt says is not about charge, it is about potential policy to 
further mass private key compromising. I don't think this have anything to do 
with StartCom.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Does Heartbleed count for the purposes of BR 4.9.11 point 11? ("proven or demonstrated method")

[Han Yuwei via dev-security-policy]

If malloc() is correctly implemented, private keys are secure from Heartbleed. 
So
I think it doesn't meet the criteria. CAs can't revoke a certificate without 
noticing 
subscriber in advance.
But if any bugs found in future which can retrieve private keys from TLS 
endpoints, 
you can just use automated tools to scan them and get private keys to request a
revoke. I thought this is the best practice to this BR.
在 2019年5月27日星期一 UTC+8上午9:34:31，Matt Palmer写道：
> Hi everyone,
> 
> In pondering ways of getting yet more keys for pwnedkeys.com, my mind turned
> to everyone's favourite bug, Heartbleed.  Whilst hitting all the vulnerable
> servers and pulling their keys is eminently possible (see, as just one
> example, https://github.com/robertdavidgraham/heartleech), I recalled that
> CAs are responsible for revoking certificates within 5 days (with a "SHOULD"
> of 24 hours) when:
> 
> > The CA is made aware of a demonstrated or proven method that exposes the
> > Subscriber's Private Key to compromise, methods have been developed that
> > can easily calculate it based on the Public Key (such as a Debian weak
> > key, see http://wiki.debian.org/SSLkeys), or if there is clear evidence
> > that the specific method used to generate the Private Key was flawed
> 
> (Taken from BRs v1.6.3, because that's what I happened to have handy)
> 
> That sounds an *awful* lot like Heartbleed: "a [...] proven method that
> exposes the Subscriber's Private Key to compromise".
> 
> Several questions arise from this, which I'd like to get the opinion of the
> members of this illustrious debating society:
> 
> 1. Do others agree that Heartbleed appears to meet the criteria of this
>paragraph in the BRs?
> 
> 2. Assuming "yes" to the above question, is it (still) reasonable to require
>CAs to revoke certificates within 5 days if notified that a certificate
>they issued is being served from an endpoint vulnerable to Heartbleed?
> 
> 3. Assuming "yes" to the above questions, should I stand up a tool to watch
>certificates coming out of CT logs, identify endpoints serving those
>certificates, test them for Heartbleed, and report these facts to CAs for
>appropriate handling?
> 
> Of course, if it's deemed that Heartbleed *isn't* "a proven method etc etc",
> the keys could just be pulled directly, which I'm led to believe typically
> takes a lot less than four days (and which would trigger the
> 24-hour-required revocation), but it seems to me "politer" to everyone to
> use the less intrusive option.
> 
> Additional comments surrounding this issue, not pertaining specifically to
> the above three questions, would also be gladly received.
> 
> - Matt

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

Re: CAA record checking issue

[Han Yuwei via dev-security-policy]

This raised a question:
 How can CA prove they have done CAA checks or not at the time of issue? 

在 2019年5月10日星期五 UTC+8上午10:05:36，Jeremy Rowley写道：
> FYI, we posted this today:
> 
>  
> 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1550645
> 
>  
> 
> Basically we discovered an issue with our CAA record checking system. If the
> system timed out, we would treat the failure as a DNS failure instead of an
> internal failure. Per the BRs Section 3.2.2:
> 
> "CAs are permitted to treat a record lookup failure as permission to issue
> if: 
> 
> . the failure is outside the CA's infrastructure; 
> 
> . the lookup has been retried at least once; and 
> 
> . the domain's zone does not have a DNSSEC validation chain to the ICANN
> root"
> 
>  
> 
> The failure was not outside our infrastructure so issuance was improper. 
> 
>  
> 
> We checked all the applicable CAA records and found 16 where the CAA record
> would not permit us to issue if we were issuing a new cert today. What we
> are proposing is to revoke these certificates and reissue them (if they pass
> all the proper checks). The rest would pass if we issued today so we were
> going to leave these where they are while disclosing them to the Mozilla
> community. 
> 
>  
> 
> Other suggestions are welcome. 
> 
>  
> 
> The issue was put into the code back when CAA record checking became
> mandatory (Sept 2017).  We generally have a peer review of our code so that
> at least one other developer has looked at the system before release. In
> this case, neither PM nor a second reviewer was involved in the development.
> We've since implemented more stringent development processes, including
> ensuring a PM reviews and brings questions about projects to the compliance
> team. 
> 
>  
> 
> Anyway, let me know what questions, comments, etc you have.
> 
>  
> 
> Thanks!
> 
> Jeremy

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

Re: Reported Digicert key compromise but not revoked

[Han Yuwei via dev-security-policy]

Thanks for that. So now I should send another email to rev...@digicert.com or 
just wait for revocation? And who should I contact if this address doesn't work?
在 2019年5月10日星期五 UTC+8上午8:26:09，Jeremy Rowley写道：
> No argument from me there. We generally act on them no matter what.
> Typically any email sent to supp...@digicert.com requesting revocation is
> forwarded to rev...@digicert.com. That's the standard procedure. This one
> was missed unfortunately.
> 
> -Original Message-
> From: dev-security-policy  On
> Behalf Of Daniel Marschall via dev-security-policy
> Sent: Thursday, May 9, 2019 4:16 PM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: RE: Reported Digicert key compromise but not revoked
> 
> I personally do think that it matters to this forum. A CA - no matter what
> kind of certificates it issues - must take revocation requests seriously and
> act immediately, even if the email is sent to the wrong address. If an
> employee at the help desk is unable to forward revocation requests, or needs
> several weeks to reply, then there is something not correct with the CA, no
> matter if the revocation request is related to a web certificate or code
> signing certificate. That's my opinion on this case.
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy

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

Reported Digicert key compromise but not revoked

[Han Yuwei via dev-security-policy]

Hi m.d.s.p
I have reported a key compromise incident to digicert by contacting 
support(at)digicert.com at Apr.13, 2019 and get replied at same day. But it 
seems like this certificate is still valid.
This certificate is a code signing certificate and known for signing malware. 
So I am here to report this to Digicert. If private key is needed I will attach 
it.

Certificate Info.
CN:Beijing Founder Apabi Technology Limited
SN: 06B7AA2C37C0876CCB0378D895D71041
SHA1: 8564928AA4FBC4BBECF65B402503B2BE3DC60D4D
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Found something I can't understand in these cerificates.

[Han Yuwei via dev-security-policy]

https://crt.sh/?id=7040227
https://crt.sh/?id=30328289

I am confused for those reasons.

1. the CN of two cerificates are same. So it is not necessary to issue two 
certificates in just 2 minutes.
2. second one used SHA1, though is consistent with BR, but first one used 
SHA256.
3. first one has 39 month period of validity which is very rare.
4. Since they are issued so close they should be logged at CT same time but 
second one are too late.

So is there some common parctice I don't know or another mistake made by Wosign?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Find a 5-year certificate

[Han Yuwei via dev-security-policy]

I have found this:
https://crt.sh/?id=6885329

I don't know whether Mozilla had allowed the certificate valid more than 39 
months, so I am here to verify it.

I have searched on Github but found nothing.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Policy 2.5 Proposal: Indicate direction of travel with respect to permitted domain validation methods

[Han Yuwei via dev-security-policy]

A question:How would a domain holder express denial for certain certificate 
requests?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Symantec: Draft Proposal

[Han Yuwei via dev-security-policy]

So Mozilla think Symantec's issues are on t serious enough to lose trust 
entirely?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: wosign and letsencrypt.cn / letsencrypt.com.cn

[Han Yuwei]

在 2016年12月20日星期二 UTC+8下午8:21:33，Tom写道：
> According to The Uniform Domain-Name Dispute-Resolution Policy, 
> letsencrypt.cn seem use in bad faith.
> 
> On December 20, 2016 2:45:47 PM GMT+08:00, "谭晓生" <tanxiaosh...@360.cn> wrote:
> >It is ICP license you talked about, you can find some information here:
> >https://support.cloudflare.com/hc/en-us/articles/209714777-ICP-FAQ
> >
> >It is almost impossible to register a .cn or .com.cn domain in China
> >for a foreign company which do not have a legal entity in China,
> >legally.
> >The websites will be blocked for access by the ISP/Telco if the
> >websites were hosted in China but do not have valid ICP licenses or
> >even the IPs have not been registered to the government. if it is not
> >that hard before, but it has more and more regulatory polices.
> 
> Yep. As far as I known, it must use the service of one of Chinese hosting 
> providers. Therefore, .cn domain name must point to Chinese IP adress.
> 
> On December 19, 2016 3:54:43 PM GMT+08:00, Han Yuwei <hanyuwe...@gmail.com> 
> wrote:
> >Since letsencrypt.org is very famous, I think the best way is to
> >redirect letsencrypt.com.cn and letsencrypt.cn to letsencrypt.org
> 
> And, It is disallowed redirecting to the website which haven't ICP license.
> 
> tanxiaosh...@360.cn wrote:
> >For Letsencrypt, if you want to own the .cn or .com.cn domain legally,
> >think of to set a legal entity in China.
> 
> I don't think it's a good idea. It may will take much time and money for 
> organization. And I think that Chinese government is not friendly to foreign 
> companies/organizations.

.cn can use CNAME redirect and don't required to point to a Chinese IP address. 
ICP is for *host* not for domain.

I think this is out of m.d.s.p's scope. Maybe we can leave this to Letsencrypt 
and Wosign.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: wosign and letsencrypt.cn / letsencrypt.com.cn

[Han Yuwei]

在 2016年12月19日星期一 UTC+8下午12:36:10，jo...@letsencrypt.org写道：
> We had some trouble figuring out how to purchase a Chinese domain name before 
> we launched, so we didn't purchase it then. We've never talked to wosign 
> about this before, and we haven't seen the domain used for anything confusing 
> so far. This is our first interaction about it and we're happy to hear that 
> Richard would like to help us out by transferring the domains.
> 
> Thanks Richard, I'll be in touch.
> 
> On Sunday, December 18, 2016 at 7:45:16 PM UTC-6, Richard Wang wrote:
> > I wish everyone can talk about this case friendly and equally.
> > 
> > It is very common that everyone can register any domain based on the first 
> > come and first service rule.
> > 
> > We know Let's Encrypt is released after the public announcement, but two 
> > day later, its .cn domain is still not registered, I think maybe it is 
> > caused by the strict registration rule in China, so I registered it for 
> > protection that not registered by Cornbug.
> > 
> > We don’t use those domains for any WoSign's services that we provide 
> > similar service: https://pki.click/index_En.htm (SSL Wizard, StartEncrypt)
> > 
> > Now, if Mozilla or Let’s Encrypt contact me officially and request to 
> > transfer the two domains to them, no any problem, we can transfer to them 
> > for FREE!
> > 
> > But please notice that this arrangement is for friendship, not for others 
> > ..
> > 
> > 
> > Best Regards,
> > 
> > Richard

Register a domain in China is much more different from International common 
partice. For further advice I suggest LE should contact with their lawyer.

Since letsencrypt.org is very famous, I think the best way is to redirect 
letsencrypt.com.cn and letsencrypt.cn to letsencrypt.org
___
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.

[Han Yuwei]

在 2016年12月10日星期六 UTC+8上午9:34:50，zbw...@gmail.com写道：
> 在 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.

not doing verification? Could you say more about that?
And how do you know there is a manual audit about this?
___
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

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

[Han Yuwei]

在 2016年12月9日星期五 UTC+8上午4:19:31，Gervase Markham写道：
> 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

Before the incident of Wosign, lots of cloud service in China is using Wosign's 
API to issue SSL cerificates for their consumers. And in this practicular 
domain I think someone intended to issue a certificate from Wosign's Free 
Certificate G2 via somewhere and they succeeded. Because I saw other valid 
certificate on this domain.

P.S. seems like Wosign updated their system for there is embedded SCT in this 
cert.
___
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.

[Han Yuwei]

在 2016年12月5日星期一 UTC+8下午9:06:13，lslqtz写道：
> Certificate:
> -BEGIN CERTIFICATE-
> MIIFwTCCBKmgAwIBAgIQH6W3+xfuFD8074LcZJFjLjANBgkqhkiG9w0BAQsFADBP
> MQswCQYDVQQGEwJDTjEaMBgGA1UEChMRV29TaWduIENBIExpbWl0ZWQxJDAiBgNV
> BAMMG0NBIOayg+mAmuWFjei0uVNTTOivgeS5piBHMjAeFw0xNjEyMDUwNTU4NDJa
> Fw0xNzEyMDUwNTU4NDJaMCQxCzAJBgNVBAYTAkNOMRUwEwYDVQQDDAxsb2xpd2lr
> aS5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDtdPYBYZsX15zm
> Pb3GAcWYgLRZjTk/o/MfE1erTLUY8laPQLo1wYwoTWbTN1z6C0WRDcs23eoXZaJ9
> PA1HUAnWCmoNOMDI1AfKcOPcPn4jbi/3U/CvYGPdbqXn7uuD0By6bi3JSsHNvmEZ
> NxKDeLuKLEJVeKzTUh99cRJc5Bsl/+zGnBFmv9nsgJnW17s3rhCyzPyUm5UvNlNn
> 8Oj+zk5ls29ZyaeSIc+wwHFKp2gqz2J+a4OIf5qhNPZSTxBhls2eaqSDln7Y0WBD
> y19R8OX6y4VgGupZMAfzbX1a1tApaUpDNHwLQs3zdSEhBoS0HfF6X1lkKjnR5C9k
> uGKxExiTAgMBAAGjggLCMIICvjAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYI
> KwYBBQUHAwIGCCsGAQUFBwMBMAkGA1UdEwQCMAAwHQYDVR0OBBYEFBLGE9J1gMQ9
> ySkbZRU9/6mr3Gv2MB8GA1UdIwQYMBaAFDDadIbzKJBWntcxMcK9Wc2TEjkdMH8G
> CCsGAQUFBwEBBHMwcTA1BggrBgEFBQcwAYYpaHR0cDovL29jc3AyLndvc2lnbi5j
> bi9jYTJnMi9zZXJ2ZXIxL2ZyZWUwOAYIKwYBBQUHMAKGLGh0dHA6Ly9haWEyLndv
> c2lnbi5jbi9jYTJnMi5zZXJ2ZXIxLmZyZWUuY2VyMD4GA1UdHwQ3MDUwM6AxoC+G
> LWh0dHA6Ly9jcmxzMi53b3NpZ24uY24vY2EyZzItc2VydmVyMS1mcmVlLmNybDAp
> BgNVHREEIjAgggxsb2xpd2lraS5vcmeCEHd3dy5sb2xpd2lraS5vcmcwTwYDVR0g
> BEgwRjAIBgZngQwBAgEwOgYLKwYBBAGCm1EBAQIwKzApBggrBgEFBQcCARYdaHR0
> cDovL3d3dy53b3NpZ24uY29tL3BvbGljeS8wggEDBgorBgEEAdZ5AgQCBIH0BIHx
> AO8AdgBBstwuieY85K8bp7spv2jG3ub58cwEfjDf+uOzuiWSYwAAAVjNpMAvAAAE
> AwBHMEUCIQCd5EZg2DiAaKXZoPtB/X6vuC+HBMSgpAnwA4/3q/kEVQIgCazYAFhk
> pL44t4Om6JqCFEi90qQqNzeO0rzIzJ11pisAdQCkuQmQtBhYFIe7E6LMZ3AKPDWY
> BPkb37jjd80OyA3cEVjNpMNmAAAEAwBGMEQCIDefIVxN6HxTm9zX72Mb9TbM
> jxdwKWzLg7qf8juX54/eAiAmqrlF0qlXuqYmQ+UnjHlT+8pODGw9m78jtCJiE+ct
> xTANBgkqhkiG9w0BAQsFAAOCAQEAAetL1ygxl83AAgRsCw3wwzRiXgSDAn8U6cVa
> LjmrQOnksi8PfepBvMiP8lJMsNVeOcXMTiSdIjyqeOR2eK1dzmdcuGTZvU/qVPv+
> WY8VHzb9+4dB0QLPMCXH6ZI0V3x368fSsA6RzTuQETt28BkF7wo2UL524R5la9Rv
> vKlg7h09tuFlvdVy+YgY3jM4zTMejnW6w1kG2GlhJMIOewJK6X1kKMmdORmRx9rK
> yYEA6puiv9pbYmxCo9YBw4Zgvq6wpfSEtB/bxwU+flGpBwqIX9plk8iDDZGiDKRy
> f3s0fVrB7/8+0DxIv/vs/ug43TjCNIpCW03I+ijiwsR12XCk8w==
> -END CERTIFICATE-

Could you tell us how do you get it?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Han Yuwei]

在 2016年12月1日星期四 UTC+8下午3:14:14，Gervase Markham写道：
> On 30/11/16 23:08, Han Yuwei wrote:
> > In https://github.com/mozilla/pkipolicy/issues/19 Gerv talked about
> > what shouldn't CA do but the discussion thread listed didn't
> > continue.
> 
> 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

Ok. Could you tell me when we can discuss it? After 2.4 release?
___
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)

[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)"

[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

[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

[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: Guang Dong Certificate Authority (GDCA) root inclusion request

[Han Yuwei]

在 2016年11月16日星期三 UTC+8下午3:59:12，wangs...@gmail.com写道：
> 在 2016年11月16日星期三 UTC+8上午1:11:05，Han Yuwei写道：
> > 在 2016年11月15日星期二 UTC+8下午7:03:07，wangs...@gmail.com写道：
> > > 在 2016年11月15日星期二 UTC+8上午8:51:25，Kathleen Wilson写道：
> > > > On Friday, October 28, 2016 at 7:29:56 AM UTC-7, wangs...@gmail.com 
> > > > wrote:
> > > > > We have uploaded the lastest translantion of CP/CPS.
> > > > > CP: https://bugzilla.mozilla.org/attachment.cgi?id=8805543
> > > > > CPS: https://bug1128392.bmoattachments.org/attachment.cgi?id=8805545
> > > > > EV CP: https://bugzilla.mozilla.org/attachment.cgi?id=8805546
> > > > > EV CPS: 
> > > > > https://bug1128392.bmoattachments.org/attachment.cgi?id=8805547
> > > > > 
> > > > > Because of our English level, there maybe some mistakes. If you have 
> > > > > any questions, please contact us.
> > > > 
> > > > 
> > > > Thanks to all of you who have reviewed and commented on this request 
> > > > from Guangdong Certificate Authority (GDCA) is to include the "GDCA 
> > > > TrustAUTH R5 ROOT" certificate, turn on the Websites trust bit, and 
> > > > enabled EV treatment. 
> > > > 
> > > > There were some recommendations to deny this request due to the 
> > > > versioning problems between the English documents and the original 
> > > > documents. 
> > > > 
> > > > Do you all still feel that is the proper answer to this root inclusion 
> > > > request?
> > > > 
> > > > Or should we proceed with reviewing these new English translations of 
> > > > the documents, and make our decision based on the new versions?
> > > > 
> > > > Thanks,
> > > > Kathleen
> > > 
> > > Because we misunderstand that we only need to provide the related 
> > > chapters of CP/CPS in English, and non-related sections are not required. 
> > > We are terribly sorry that we misinterpreted your requirement and upload 
> > > an inconsistent CP/CPS in English. Someone inferred that we don’t utilize 
> > > a version control for CP/CPS. In fact, we do have a strict control for 
> > > master version CP/CPS (see section 1.5 in CP/CPS).
> > > We understand that it is our responsibility to provide accurate English 
> > > versions and ensure consistency and synchronicity between Chinese and 
> > > English versions. Hence, we have decided to strictly implement version 
> > > controlling of English version CP/CPS according to section 1.5 in CP/CPS. 
> > > The auditor is reviewing our complete CP/CPS in English and the new 
> > > version will be published as soon as possible.
> > > We will keep open mind to process any further issues.
> > 
> > Ok, this is what I want to see. Maybe next time you could be more specific 
> > about the problems and not just like "translation problem". If you can't 
> > describe your opinion exactly in English you can use Chinese and let others 
> > translate. But it's best for you to hire a professional translator.
> > Since CPS is very critical, I hope you understand what I said before. I 
> > don't want another Wosign incident happen again.
> 
> Thanks for proposing many good questions, which push us to utilize version 
> controls for English CP/CPS. We are looking forward to your further comments 
> and suggestions. 
> We plan to attend the CA/B Forum meetings in February next year, If it is 
> lucky to meet you there, we are looking forward to have your consultation and 
> suggestions.

So are you going to conduct a complete investgation about this? I am still 
waiting for it.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Guang Dong Certificate Authority (GDCA) root inclusion request

[Han Yuwei]

在 2016年11月15日星期二 UTC+8下午7:03:07，wangs...@gmail.com写道：
> 在 2016年11月15日星期二 UTC+8上午8:51:25，Kathleen Wilson写道：
> > On Friday, October 28, 2016 at 7:29:56 AM UTC-7, wangs...@gmail.com wrote:
> > > We have uploaded the lastest translantion of CP/CPS.
> > > CP: https://bugzilla.mozilla.org/attachment.cgi?id=8805543
> > > CPS: https://bug1128392.bmoattachments.org/attachment.cgi?id=8805545
> > > EV CP: https://bugzilla.mozilla.org/attachment.cgi?id=8805546
> > > EV CPS: https://bug1128392.bmoattachments.org/attachment.cgi?id=8805547
> > > 
> > > Because of our English level, there maybe some mistakes. If you have any 
> > > questions, please contact us.
> > 
> > 
> > Thanks to all of you who have reviewed and commented on this request from 
> > Guangdong Certificate Authority (GDCA) is to include the "GDCA TrustAUTH R5 
> > ROOT" certificate, turn on the Websites trust bit, and enabled EV 
> > treatment. 
> > 
> > There were some recommendations to deny this request due to the versioning 
> > problems between the English documents and the original documents. 
> > 
> > Do you all still feel that is the proper answer to this root inclusion 
> > request?
> > 
> > Or should we proceed with reviewing these new English translations of the 
> > documents, and make our decision based on the new versions?
> > 
> > Thanks,
> > Kathleen
> 
> Because we misunderstand that we only need to provide the related chapters of 
> CP/CPS in English, and non-related sections are not required. We are terribly 
> sorry that we misinterpreted your requirement and upload an inconsistent 
> CP/CPS in English. Someone inferred that we don’t utilize a version control 
> for CP/CPS. In fact, we do have a strict control for master version CP/CPS 
> (see section 1.5 in CP/CPS).
> We understand that it is our responsibility to provide accurate English 
> versions and ensure consistency and synchronicity between Chinese and English 
> versions. Hence, we have decided to strictly implement version controlling of 
> English version CP/CPS according to section 1.5 in CP/CPS. The auditor is 
> reviewing our complete CP/CPS in English and the new version will be 
> published as soon as possible.
> We will keep open mind to process any further issues.

Ok, this is what I want to see. Maybe next time you could be more specific 
about the problems and not just like "translation problem". If you can't 
describe your opinion exactly in English you can use Chinese and let others 
translate. But it's best for you to hire a professional translator.
Since CPS is very critical, I hope you understand what I said before. I don't 
want another Wosign incident happen again.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Guang Dong Certificate Authority (GDCA) root inclusion request

[Han Yuwei]

在 2016年11月15日星期二 UTC+8上午8:51:25，Kathleen Wilson写道：
> On Friday, October 28, 2016 at 7:29:56 AM UTC-7, wangs...@gmail.com wrote:
> > We have uploaded the lastest translantion of CP/CPS.
> > CP: https://bugzilla.mozilla.org/attachment.cgi?id=8805543
> > CPS: https://bug1128392.bmoattachments.org/attachment.cgi?id=8805545
> > EV CP: https://bugzilla.mozilla.org/attachment.cgi?id=8805546
> > EV CPS: https://bug1128392.bmoattachments.org/attachment.cgi?id=8805547
> > 
> > Because of our English level, there maybe some mistakes. If you have any 
> > questions, please contact us.
> 
> 
> Thanks to all of you who have reviewed and commented on this request from 
> Guangdong Certificate Authority (GDCA) is to include the "GDCA TrustAUTH R5 
> ROOT" certificate, turn on the Websites trust bit, and enabled EV treatment. 
> 
> There were some recommendations to deny this request due to the versioning 
> problems between the English documents and the original documents. 
> 
> Do you all still feel that is the proper answer to this root inclusion 
> request?
> 
> Or should we proceed with reviewing these new English translations of the 
> documents, and make our decision based on the new versions?
> 
> Thanks,
> Kathleen

If GDCA insists on translation problem, I can't trust it.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Mozilla CT Policy

[Han Yuwei]

在 2016年11月4日星期五 UTC+8下午8:20:11，Gervase Markham写道：
> CT is coming to Firefox. As part of that, Mozilla needs to have a set of
> CT policies surrounding how that will work. Like our root inclusion
> program, we intend to run our CT log inclusion program in an open and
> transparent fashion, such that the Internet community can see how it
> works and how decisions are made. (It is quite possible that, like our
> root program, other entities without the resources to run their own
> programs might adopt our decisions.)
> 
> This policy will need to consider at least the following questions. The
> point of this posting is to gather more _questions_, not to work out the
> answers. In other words, I am trying to work out the scope of the
> policy, not what the policy will be.
> 
> So, please add comments with additional _questions_ you think the policy
> will need to address. What the answers should be is (for now) off-topic.
> 
> Questions I have so far:
> 
> * How do we decide which logs to trust?
> 
>   * Do we have requirements for uptime?
>   * Do we have requirements for certs accepted?
>   * Do we have requirements for the MMD?
> 
> * How do we decide when to un-trust a log? What reasons are valid
> reasons for doing so?
> 
> * Do we want to put monitoring in place to ensure our log quality or
> uptime requirements are met?
> 
> * Are there any CT-related services Mozilla should consider running or
> supporting, for the good of the ecosystem?
> 
> * Do we want to require a certain number of SCTs for certificates of
> particular validity periods?
> 
> * Do we want the Google/non-Google diversity requirement? Or any other
> diversity reqirement?
> 
> * Which certs, if any, should we require CT for, and when?
> 
> * Do we want to allow some CAs to opt into CT before those dates?
> 
> * Do we want to require some CAs to do CT before those dates?
> 
> Gerv

1. What will happen if CT validation failed? Can we add a security excpetion 
about this?

2. Is SLA required for Mozilla chosen CT operator?

3. If CT is required, can we request a CT embedded certificate from CAs because 
some webserver don't support TLS extension.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Update on transition of the Verizon roots and issuance of SHA1 certificates

[Han Yuwei]

在 2016年11月4日星期五 UTC+8上午3:52:23，Jeremy Rowley写道：
> Resent without a signature
> 
> 
> 
> Hi everyone,
> 
> 
> 
> This email is intended to gather public and browser feedback on how we are 
> handling the transitioning Verizon's customers to DigiCert and share with 
> everyone the plan for when all non-DigiCert hosted sub CAs will be fully 
> compliant with the BRs and network security guidelines. Primarily, this 
> letter addresses when all issuing CAs previously held by Verizon will be 
> covered by an unqualified audit and how we are responding to the sub CAs that 
> issued SHA1 certificates. We are looking forward to the browser and public 
> feedback on how to handle the non-compliant cross-signs and insight on how 
> the public views our transition progress and planned completion dates.
> 
> 
> 
> Background
> 
> Prior to presenting the plan for remediation, I thought I'd share a bit about 
> our progress with migrating Verizon customers.  About a year ago in July, 
> DigiCert closed an agreement with Verizon where DigiCert took ownership of 
> three publicly-trusted Verizon root certificates. These certificates are the 
> Verizon Global Root CA, the Baltimore CyberTrust Root CA, and the Verizon 
> Root CA. There were many reasons the acquisition made sense, including 
> acquisition of a root that had cross-signed DigiCert for many years. The 
> ubiquity of the Verizon roots is wide-spread, which meant a lot of CAs like 
> to cross-sign with them. Another significant reason for the acquisition was 
> an attempt to improve the CA industry. After watching the issuance of 
> wildcard EV certs, non-compliant subordinate CAs, and certs with poor 
> profiles, we made a conscious decision to purchase these roots with the 
> intention of migrating them to more complaint system. We felt that helping 
> these CAs get to the point of regular audits and best practices would raise 
> the quality of the entire industry.
> 
> 
> 
> Prior to the acquisition, we were made aware of several potential 
> non-compliances by Verizon's customers. We worked closely with Verizon to 
> clean up many of the Sub CAs, including revoking CAs that would never be 
> compliant with the requirements and attempting to technically constrain 
> others.  Sub CAs were revoked because they either didn't have an audit, were 
> unresponsive to communication, or couldn't control their issuance. Verizon 
> was a great partner and took a very proactive approach in removing CAs that 
> were not actively working towards compliance. Unfortunately, the age of the 
> roots and large number of cross-signs led to a lot of missing paperwork and 
> certain issues in identifying which CAs were covered by audits. Prior to 
> closing we believed there were approximately five technically constrained sub 
> CAs and around 20 unconstrained sub CAs. Turns out there were actually more 
> than 200, each with various levels of compliance. Most of these Sub CAs 
> operated under the Baltimore Cybertrust root, which was created in 2000.
> 
> 
> 
> To their credit, Verizon revoked 48 of the issuing CAs prior to DigiCert's 
> acquisition of the roots. Unfortunately, this left around 150 for our small 
> team to work through. Although the endeavor was daunting, Ben Wilson and 
> others worked to gather audit reports, email customers about compliance 
> dates, monitor certificates issued, and revoke non-compliant customers. 
> Verizon was very good at assisting us in these efforts. This information is 
> now recorded in the Mozilla database and continuously updated as the 
> information changes.
> 
> 
> 
> Transition Process
> 
> After our operational acquisition of the roots (which occurred the last part 
> of September, 2015), we identified 15 expired issuing CAs, 70 revoked sub 
> CAs, 131 audited sub CAs, and 36 where the status was unknown. Since then, 
> we've revoked 25 issuing CAs and assisted others with technical constraints, 
> exodus from the Omniroot cross-signing program, or obtaining audits. Of the 
> existing sub CAs, about half remain operational and are either audited or 
> technically constrained. The other half are either winding down or have been 
> revoked. All revoked certificates were disclosed to Mozilla via Salesforce 
> and should be part of OneCRL.
> 
> 
> 
> Issuing CAs
> 
> There are only a handful of non-audited sub CAs remaining (see 
> https://crt.sh/mozilla-disclosures#disclosureincomplete). We have a plan for 
> each of them that we'd like to share with you. We welcome both browser and 
> public feedback. This is, of course, simply a proposal on how to finish the 
> transition and provide transparency into where we are at. We are certainly 
> willing to modify the plan as needed to further online security and meet the 
> requirements of the root store operators.
> 
> 
> 
> The seven companies listed below are responsible for the remaining unaudited 
> sub CAs:
> 
> 
> 
> 1.   ABB has three unaudited issuing CAs. ABB didn't 

Re: Cerificate Concern about Cloudflare's DNS

[Han Yuwei]

在 2016年9月10日星期六 UTC+8下午8:37:40，Han Yuwei写道：
> I am using Cloudflare's DNS service and I found that Cloudflare has issued a 
> certficate to their server including my domain. But I didn't use any SSL 
> service of theirs. Is that ok to Mozilla's policy?
> 
> Issued certificate:https://crt.sh/?id=31206531
> My domain is BUPT.MOE

Thanks for your time.

My question remains that,
1. If I request Comodo to revoke the certificate, how is it likely to be 
approved?

2. If Cloudflare use this certificate to perform MITM, how can others know 
about it?

3. Is this concerned by Mozilla? If it isn't, I wouldn't post anything about it 
anymore.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Something About CFCA (China Financial Certification Authority)

[Han Yuwei]

在 2016年10月31日星期一 UTC+8下午6:19:44，jonath...@gmail.com写道：
> 在 2016年10月31日星期一 UTC+8上午11:28:04，Han Yuwei写道：
> > 在 2016年10月31日星期一 UTC+8上午9:35:04，jonath...@gmail.com写道：
> > > Please see 6.1.7 which describes these content.
> > 
> > In version 3.2 I see that "证书最长期限（年）" (maxium validity period) about 
> > "SSL服务器证书" (SSL Server Certficates) is 5.
> > 
> > And I don't see any other informations about SM2 usage
> 
>  We feel that there is no  need to discuss those root that NOT included in 
> Mozilla and  other public trusted root store. sm2 is not valid for BR right 
> now，so we didn't apply our sm2 root for inclusion. It is as simple as that. 
> hence， we do not plan to explain further about our NOT included root.

Ok, thanks for your time.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: help

[Han Yuwei]

在 2016年10月31日星期一 UTC+8下午11:29:27，chun.yi...@cn.pwc.com写道：
> Help.  My previous email account (cheungchun...@gmail.com) Is blocked.  I 
> want to subscribe to the mailgroup using my company account 
> (chun.yin.che...@cn.pwc.com).
> 
> Regards
> 
> CY
> 
> > 在 2016年10月28日，下午11:28，Chun Yin Cheung  写道：
> > 
> > help
> > 
> > Regards
> > 
> > CY
> 
> _
> The information transmitted is intended only for the person or entity to 
> which it is addressed 
> and may contain confidential and/or privileged material.  Any review, 
> retransmission, dissemination 
> or other use of, or taking of any action in reliance upon, this information 
> by persons or entities other 
> than the intended recipient is prohibited. If you received this in error, 
> please contact the sender and 
> delete the material from any computer. Any views or opinions expressed in 
> this email are solely 
> those of the author and do not necessarily represent those of PwC.

Maybe you used S/MIME ?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: WoSign: updated report and discussion

[Han Yuwei]

在 2016年11月1日星期二 UTC+8下午6:43:53，Gervase Markham写道：
> On 31/10/16 18:25, Percy wrote:
> > According to http://se.360.cn/event/gmzb.html, the browser needs to send a
> > http header Accept-Protocal: SM-SSL. 
> 
> That seems like an odd mechanism, because SSL connection establishment
> happens before HTTP header transmission. Does this header mean "Next
> time you contact me, use SM2"?
> 
> Gerv

Yes. And it may be decided by a USB-key.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: WoSign: updated report and discussion

[Han Yuwei]

在 2016年10月31日星期一 UTC+8下午11:50:46，Gervase Markham写道：
> On 30/10/16 19:47, Han Yuwei wrote:
> > SM2 is widely used in Chinese government websites. There is a openssl
> > branch (https://github.com/guanzhi/GmSSL) who implemented
> > SM2/SM3/SM4. And I don't see any other depolyment in HTTPS.
> 
> Right, but my question remains: can you find a site with a WoSign SM2
> certificate, which chains up to a root Mozilla trusts?
> 
> Gerv

I am sorry that I can't provide such a certificate for I am not involved in 
these systems. And I am not likely think there could be a SM2 certificate 
because major broswers don't implemented SM2/SM3/SM4 so the server would only 
send RSA/ECC certificates.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Something About CFCA (China Financial Certification Authority)

[Han Yuwei]

在 2016年10月31日星期一 UTC+8上午9:35:04，jonath...@gmail.com写道：
> Please see 6.1.7 which describes these content.

In version 3.2 I see that "证书最长期限（年）" (maxium validity period) about "SSL服务器证书" 
(SSL Server Certficates) is 5.

And I don't see any other informations about SM2 usage
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Something About CFCA (China Financial Certification Authority)

[Han Yuwei]

在 2016年10月30日星期日 UTC+8下午10:26:57，jonath...@gmail.com写道：
> 1，It’s not true. CFCA's RSA root that included in Mozilla is not able to 
> issue sm2 certificate with sm3 hash. CFCA do have sm2 root that issue sm2 
> certificate but that root is not included in Mozilla or any other root store 
> such as Apple, Microsoft or Google. And our CPS never indicate that our RSA 
> root is able to issue sm2 certificate. It is impossible.
> 2，The signing key and encrypting key issue is a standard relate to 
> Chinese double certificate, which is different from ssl, codesigning and 
> email certificate. CFCA's root that included in Mozilla, Google and Apple is 
> never able to issue this kind of certificate. 
> 3，CFCA OV certificate have a longest valid period of 3 years. EV 
> certificate have a longest valid of 2 years. There is no root of CFCA that 
> included in Mozilla, Google and Apple can issue 5 year long certificate. 
> Please note that the sub root that use to be able to issue 5 year long 
> certificate is the GT root, which is a sha1 root that we already turned off. 
> This root issue 0 certificate after 2016 Jan 1, and this root is never 
> included in Mozilla, Apple and Google.

So why I didn't see these statements in the CPS or in the website?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: StartCom & Qihoo Incidents

[Han Yuwei]

在 2016年10月30日星期日 UTC+8下午8:40:37，谭晓生写道：
> Nothing compelled by the gov to trust the self-issued certificates.
> 
> It is because some very large website like 12306.cn(the only one online entry 
> to buy rail way tickets in China) and some government websites, they still 
> using self-issued certificates, even we tried to offer free trusted 
> certificates to them, they rejected.
> If a local browser try to block the access to these websites, user will force 
> the browser to trust the self-issued certificates and complain, for the 
> behavior training to end users, it is also an issue, user will used to trust 
> the certificates which have a warning message by browsers, even there is a 
> MITM attack, they still could not identify it.
> 
> That’s the dilemma we have:
> Block the access to self-issued certificates, user will ignore and force 
> trust the certificated, bad behavior training, user might change to 
> competitor’s product.
> Do not block the access, there are possibility to do the MITM attack, the 
> community complains.
> 
> We already worked on a solution for a while and will release a report soon, 
> hopefully to find a tradeoff between user experience and security.
> 
> Thanks，
> Xiaosheng Tan
> 
> 
> 发件人: Percy 
> 日期: 2016年10月30日 星期日 下午4:01
> 至: 晓生 谭 
> 抄送: "mozilla-dev-security-pol...@lists.mozilla.org" 
> 
> 主题: Re: StartCom & Qihoo Incidents
> 
> As we observed the large scale MITM against iCloud, Outlook, Google and 
> Github carried out on the backbone router with self-signed certs, and that 
> the browsers are explicitly loads self-signed certs, I think it's clear that 
> browsers in China are compelled by the gov to enable insecure cryptography by 
> default.
> 
> Percy 
> Alpha(PGP)
> 
> 
> On Sat, Oct 29, 2016 at 11:36 PM, 谭晓生 
> > wrote:
> Is there anybody thought about why it happens in China? Why the local browser 
> did not block the self-issued certificates?
> 
> Thanks，
> Xiaosheng Tan
> 
> 
> 
> 在 2016/10/30 
> 下午1:17，“Percy”> 写入:
> 
> On Saturday, October 29, 2016 at 5:54:10 PM UTC-7, Matt Palmer wrote:
> > On Sat, Oct 29, 2016 at 02:59:07PM -0700, Percy wrote:
> > > Perhaps not. However, Qihoo 360's behavior calls the trustworthiness 
> of the
> > > entire company into question. And such trust, in my view, should be
> > > evaluated when WoSign/StartCom submit their re-inclusion requests in 
> the
> > > future.
> >
> > You can make that argument when WoSign/StartCom's reinclusion 
> discussions
> > take place on this list.  Now is not the appropriate time for that.
> >
> > - Matt
> WoSign/StartCom's re-inclusion request might be a year from now. In the 
> meanwhile, those 400 million users will be exposed to MITM. That's why I'm 
> bringing it up now, rather than one year later.
> ___
> dev-security-policy mailing list
> 
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy

I think that you can maintain a list to preload self-signed certificates, 
something like HSTS preload. For me the 12306's certficate has a securtiy 
exception for a long time and it still works.

And there's any other government sites using self-signed certs? Who?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Something About CFCA (China Financial Certification Authority)

[Han Yuwei]

According to their CPS (Chinese version 3.2 Jul.2016),

1. All CAs can issue SM2 certificates and uses SM3 Hash.

2. There is a "signing key" generated by subscriber and "encryption key" 
generated by CFCA which transmitted to subscriber.

3. For SSL certificate, the longest vaild duration is 5 years, which is much 
more than 39 months.

Are those conflicting with Mozilla's policy?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Guang Dong Certificate Authority (GDCA) root inclusion request

[Han Yuwei]

在 2016年10月30日星期日 UTC+8上午5:30:23，Peter Bowen写道：
> > On Oct 29, 2016, at 2:23 PM, Han Yuwei <hanyuwe...@gmail.com> wrote:
> > 
> > 在 2016年10月28日星期五 UTC+8下午9:23:01，wangs...@gmail.com写道：
> >> We are not intended to cover-up anything since we had disclosed every 
> >> change to the Chinese version CP/CPS at once after the auditor reviewed.
> >> The “ROOTCA(SM2)” CA in $1.1.3 of CPS ver4.3 is equivalent to the “SM2 
> >> ROOT Certificate” CA in $1.1.3 of CPS ver4.1. The “Guangdong Certificate 
> >> Authority(SM2) ” CA in $1.1.3 of CPS ver4.3 is equivalent to the “SM2 CA 
> >> Certificate” CA in $1.1.3 of CPS ver4.1. We change these names in diagram 
> >> in this revision in order to show the actual CN of these certificates. 
> >> Furthermore, we only issue SM2 subscriber certificates from the subCA of 
> >> “ROOTCA(SM2)” CA.
> > 
> > Is SM2 acceptable in publicy-trusted CAs? I don't think so.
> > 
> > Maybe Gerv could explain more about this. And I am wondering what can CA do 
> > if government requirement conflicts with Mozilla's policy?
> 
> It is acceptable to have a single CPS that covers CAs that are included the 
> Mozilla list of trust anchors and CAs that are not trusted by Mozilla.  The 
> CPS should make clear which portions apply to which CA when there are 
> portions that do not apply to all CAs.
> 
> In this case, I would expect that the ROOTCA(SM2) CA is not proposed for 
> inclusion in Mozilla.  As long as the CPS does not allow issuance of SM2 
> signed certificates or certificates with SM2 subject public keys from the CAs 
> proposed for inclusion in Mozilla, I do not seen an issue.
> 
> Thanks,
> Peter

I don't see anything about this in Chinese CPS or Bugzilla. Could someone point 
out or GDCA explain about this?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Guang Dong Certificate Authority (GDCA) root inclusion request

[Han Yuwei]

在 2016年10月28日星期五 UTC+8上午6:43:30，Han Yuwei写道：
> 在 2016年10月27日星期四 UTC+8下午6:22:03，wangs...@gmail.com写道：
> > 在 2016年10月27日星期四 UTC+8上午8:09:06，Peter Kurrasch写道：
> > > I think these are both good points and my recommendation is that Mozilla 
> > > deny GDCA's request for inclusion.
> > > 
> > > 
> > > We should not have to explain something as basic as document versioning 
> > > and version control. If GDCA can not demonstrate sufficient controls over 
> > > their documentation, there is no reason for the Internet community to 
> > > place confidence in any of the other versioning systems that are needed 
> > > to operate a CA.
> > > 
> > > 
> > > Question: Are auditors expected to review translations of CP or CPS docs 
> > > and verify consistency between them?
> > > 
> > >   
> > >
> > > 
> > >   
> > >   
> > >
> > >   
> > >   
> > >   
> > >   
> > > From: Jakob Bohm
> > > Sent: Saturday, October 22, 2016 9:07 AM
> > > To: mozilla-dev-s...@lists.mozilla.org
> > > Subject: Re: Guang Dong Certificate Authority (GDCA) root inclusion 
> > > request
> > > 
> > > 
> > > On 21/10/2016 10:38, Han Yuwei wrote:
> > > >
> > > > I think this is a major mistake and a investgation should be conducted 
> > > > for CPS is a critical document about CA. This is not just a translation 
> > > > problem but a version control problem. Sometimes it can be lying.
> > > >
> > > 
> > > Let me try to be more specific:
> > > 
> > > When publishing a document called CPS version 4.3 the document with
> > > that number must have the same contents in all languages that have a
> > > document with that name and version number.
> > > 
> > > When making any change, even just correcting a mistyped URL, the
> > > document becomes a new document version which should have a new and
> > > larger number than the number of the document before the change.
> > > Thus when a published document refers to a broken URL on your own
> > > server, it is often cheaper to repair the server than to publish a new
> > > document version.  Some of the oldest CAs have been proudly
> > > publishing their various important files at multiple URLs corresponding
> > > to whatever was mentioned in old CP and CPS documents etc., only
> > > shutting down those URLs years after the corresponding CA roots were
> > > shut down.
> > > 
> > > There can also be a "draft" document which has no number and which
> > > contains the changes that will go into the next numbered edition.  Such
> > > a "draft" would have no official significance, as it has not been
> > > officially "published".  For a well-planned change, the final "draft"
> > > would be translated and checked into the relevant languages (e.g.
> > > Chinese with mainland writing system, Chinese with Hong Kong and Macao
> > > Special Administrative Regions old writing system, English), before
> > > simultaneously publishing the matching documents with the same number
> > > on the same day.
> > > 
> > > There are infinitely many version numbers in the universe to choose
> > > from.  There are also computer programs that can generate new version
> > > numbers every time a draft is changed, but computers cannot decide when
> > > a version is good enough in all languages to make an official
> > > publication, and the computer generated version numbers are often
> > > impractical for publication because they count all the small steps that
> > > were not published.
> > > 
> > > 
> > > 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.
&

Re: Guang Dong Certificate Authority (GDCA) root inclusion request

[Han Yuwei]

在 2016年10月28日星期五 UTC+8下午9:23:01，wangs...@gmail.com写道：
> We are not intended to cover-up anything since we had disclosed every change 
> to the Chinese version CP/CPS at once after the auditor reviewed.
> The “ROOTCA(SM2)” CA in $1.1.3 of CPS ver4.3 is equivalent to the “SM2 ROOT 
> Certificate” CA in $1.1.3 of CPS ver4.1. The “Guangdong Certificate 
> Authority(SM2) ” CA in $1.1.3 of CPS ver4.3 is equivalent to the “SM2 CA 
> Certificate” CA in $1.1.3 of CPS ver4.1. We change these names in diagram in 
> this revision in order to show the actual CN of these certificates. 
> Furthermore, we only issue SM2 subscriber certificates from the subCA of 
> “ROOTCA(SM2)” CA.

Is SM2 acceptable in publicy-trusted CAs? I don't think so.

Maybe Gerv could explain more about this. And I am wondering what can CA do if 
government requirement conflicts with Mozilla's policy?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Guang Dong Certificate Authority (GDCA) root inclusion request

[Han Yuwei]

在 2016年10月27日星期四 UTC+8下午6:22:03，wangs...@gmail.com写道：
> 在 2016年10月27日星期四 UTC+8上午8:09:06，Peter Kurrasch写道：
> > I think these are both good points and my recommendation is that Mozilla 
> > deny GDCA's request for inclusion.
> > 
> > 
> > We should not have to explain something as basic as document versioning and 
> > version control. If GDCA can not demonstrate sufficient controls over their 
> > documentation, there is no reason for the Internet community to place 
> > confidence in any of the other versioning systems that are needed to 
> > operate a CA.
> > 
> > 
> > Question: Are auditors expected to review translations of CP or CPS docs 
> > and verify consistency between them?
> > 
> > 
> >  
> > 
> > 
> > 
> >
> > 
> > 
> >   
> >   
> > From: Jakob Bohm
> > Sent: Saturday, October 22, 2016 9:07 AM
> > To: mozilla-dev-s...@lists.mozilla.org
> > Subject: Re: Guang Dong Certificate Authority (GDCA) root inclusion request
> > 
> > 
> > On 21/10/2016 10:38, Han Yuwei wrote:
> > >
> > > I think this is a major mistake and a investgation should be conducted 
> > > for CPS is a critical document about CA. This is not just a translation 
> > > problem but a version control problem. Sometimes it can be lying.
> > >
> > 
> > Let me try to be more specific:
> > 
> > When publishing a document called CPS version 4.3 the document with
> > that number must have the same contents in all languages that have a
> > document with that name and version number.
> > 
> > When making any change, even just correcting a mistyped URL, the
> > document becomes a new document version which should have a new and
> > larger number than the number of the document before the change.
> > Thus when a published document refers to a broken URL on your own
> > server, it is often cheaper to repair the server than to publish a new
> > document version.  Some of the oldest CAs have been proudly
> > publishing their various important files at multiple URLs corresponding
> > to whatever was mentioned in old CP and CPS documents etc., only
> > shutting down those URLs years after the corresponding CA roots were
> > shut down.
> > 
> > There can also be a "draft" document which has no number and which
> > contains the changes that will go into the next numbered edition.  Such
> > a "draft" would have no official significance, as it has not been
> > officially "published".  For a well-planned change, the final "draft"
> > would be translated and checked into the relevant languages (e.g.
> > Chinese with mainland writing system, Chinese with Hong Kong and Macao
> > Special Administrative Regions old writing system, English), before
> > simultaneously publishing the matching documents with the same number
> > on the same day.
> > 
> > There are infinitely many version numbers in the universe to choose
> > from.  There are also computer programs that can generate new version
> > numbers every time a draft is changed, but computers cannot decide when
> > a version is good enough in all languages to make an official
> > publication, and the computer generated version numbers are often
> > impractical for publication because they count all the small steps that
> > were not published.
> > 
> > 
> > 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-secur...@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-security-policy
> 
> We’d like to explain a few points.
> 
> 1. We have already implemented version control on Chinese version CP/CPS, the 
> revision and release of CP/CPS are reviewed and approve

Re: Guang Dong Certificate Authority (GDCA) root inclusion request

[Han Yuwei]

在 2016年10月28日星期五 UTC+8上午2:12:32，Percy写道：
> On Thursday, October 27, 2016 at 3:22:03 AM UTC-7, wangs...@gmail.com wrote:
> > 在 2016年10月27日星期四 UTC+8上午8:09:06，Peter Kurrasch写道：
> > > I think these are both good points and my recommendation is that Mozilla 
> > > deny GDCA's request for inclusion.
> > > 
> > > 
> > > We should not have to explain something as basic as document versioning 
> > > and version control. If GDCA can not demonstrate sufficient controls over 
> > > their documentation, there is no reason for the Internet community to 
> > > place confidence in any of the other versioning systems that are needed 
> > > to operate a CA.
> > > 
> > > 
> > > Question: Are auditors expected to review translations of CP or CPS docs 
> > > and verify consistency between them?
> > > 
> > >   
> > >
> > > 
> > >   
> > >   
> > >
> > >   
> > >   
> > >   
> > >   
> > > From: Jakob Bohm
> > > Sent: Saturday, October 22, 2016 9:07 AM
> > > To: mozilla-dev-s...@lists.mozilla.org
> > > Subject: Re: Guang Dong Certificate Authority (GDCA) root inclusion 
> > > request
> > > 
> > > 
> > > On 21/10/2016 10:38, Han Yuwei wrote:
> > > >
> > > > I think this is a major mistake and a investgation should be conducted 
> > > > for CPS is a critical document about CA. This is not just a translation 
> > > > problem but a version control problem. Sometimes it can be lying.
> > > >
> > > 
> > > Let me try to be more specific:
> > > 
> > > When publishing a document called CPS version 4.3 the document with
> > > that number must have the same contents in all languages that have a
> > > document with that name and version number.
> > > 
> > > When making any change, even just correcting a mistyped URL, the
> > > document becomes a new document version which should have a new and
> > > larger number than the number of the document before the change.
> > > Thus when a published document refers to a broken URL on your own
> > > server, it is often cheaper to repair the server than to publish a new
> > > document version.  Some of the oldest CAs have been proudly
> > > publishing their various important files at multiple URLs corresponding
> > > to whatever was mentioned in old CP and CPS documents etc., only
> > > shutting down those URLs years after the corresponding CA roots were
> > > shut down.
> > > 
> > > There can also be a "draft" document which has no number and which
> > > contains the changes that will go into the next numbered edition.  Such
> > > a "draft" would have no official significance, as it has not been
> > > officially "published".  For a well-planned change, the final "draft"
> > > would be translated and checked into the relevant languages (e.g.
> > > Chinese with mainland writing system, Chinese with Hong Kong and Macao
> > > Special Administrative Regions old writing system, English), before
> > > simultaneously publishing the matching documents with the same number
> > > on the same day.
> > > 
> > > There are infinitely many version numbers in the universe to choose
> > > from.  There are also computer programs that can generate new version
> > > numbers every time a draft is changed, but computers cannot decide when
> > > a version is good enough in all languages to make an official
> > > publication, and the computer generated version numbers are often
> > > impractical for publication because they count all the small steps that
> > > were not published.
> > > 
> > > 
> > > 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 a

Re: Announcement: Chrome requiring Certificate Transparency in 2017

[Han Yuwei]

在 2016年10月25日星期二 UTC+8下午11:39:31，Nick Lamb写道：
> On Tuesday, 25 October 2016 15:45:26 UTC+1, Han Yuwei  wrote:
> > Is there any timetable for enforcing CAs to support embedded CT or OCSP CT?
> 
> Well, the effect of Google's policy is that if you're a subscriber looking to 
> obtain certificates a year from now you have three options
> 
> 1. Don't care about Chrome (though of course this policy may spread to other 
> browsers). That option might be attractive if your certificates are from the 
> Web PKI but aren't usually examined by browsers. For example in a mail 
> server, or in some financial applications. Otherwise it looks like a bad 
> choice.
> 
> 2. Arrange to implement the TLS SCT extension from your servers and obtain 
> SCTs for yourself to pass on to browsers. This does not require any new 
> effort from the CA. This would meet Chrome's requirement entirely and is very 
> flexible, but can mean significant disruption or even the need for new 
> software development. Most customers again will see this as an undesirable 
> choice.
> 
> 3. Choose a CA that can deliver SCTs with your certificates or maybe via OCSP 
> and in the latter case ensure your server software is compatible with that.
> 
> I expect option (3) to be overwhelmingly popular, so that Google need do 
> little or nothing in the way of "enforcing" this support. Indeed all the big 
> public CAs either already have, or are known to be developing this capability.
> 
> 
> Obviously Google needs to communicate this clearly to subscribers, and to a 
> lesser extent to Chrome users. I think a simple announcement ought to be 
> enough at this stage for CAs themselves, if you're operating a public CA in 
> 2016 and don't know what Certificate Transparency is you're in the wrong 
> business. But for the other two groups effective communication is important 
> over the next 12-24 months. In the ideal world the CAs would take on some of 
> the burden of informing their subscribers, but I think the SHA-1 experience 
> shows that's not always a very reliable path.

First, I care about CT and I desperately want CT depolyment. I have tried to 
implement TLS SCT extension to my nginx but failed and I dont't why. Because I 
deployed OCSP stapling successfully so I want a embedded CT (best for everyone) 
or a OCSP response CT. So I am willing that CA could do more because they have 
much more resources than us.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Announcement: Chrome requiring Certificate Transparency in 2017

[Han Yuwei]

在 2016年10月25日星期二 UTC+8上午8:45:26，Ryan Sleevi写道：
> [Note: This is cross-posted. The best venue for follow-up questions is the 
> public mailing list at ct-pol...@chromium.org or the post at 
> https://groups.google.com/a/chromium.org/d/msg/ct-policy/78N3SMcqUGw/ykIwHXuqAQAJ
>  ]
> [Note: Posting wearing my Chrome hat. None of this reflects Mozilla policy, 
> but is useful for the Mozilla community to be aware of]
> 
> This past week at the 39th meeting of the CA/Browser Forum, the Chrome team 
> announced plans that publicly trusted website certificates issued in October 
> 2017 or later will be expected to comply with Chrome’s Certificate 
> Transparency policy in order to be trusted by Chrome. 
> 
> The Chrome Team believes that the Certificate Transparency ecosystem has 
> advanced sufficiently that October 2017 is an achievable and realistic goal 
> for this requirement.
> 
> This is a significant step forward in the online trust ecosystem. The 
> investments made by CAs adopting CT, and Chrome requiring it in some cases, 
> have already paid tremendous dividends in providing a more secure and 
> trustworthy Internet. The use of Certificate Transparency has profoundly 
> altered how browsers, site owners, and relying parties are able to detect and 
> respond to misissuance, and importantly, gives new tools to mitigate the 
> damage caused when a CA no longer complies with community expectations and 
> browser programs.
> 
> While the benefits of CT are clear, we recognize that some CAs, browsers, or 
> site operators may have use cases they feel are not fully addressed by 
> Certificate Transparency, and so may have concerns over the October 2017 
> date. We encourage anyone who feels this way to bring their concerns to the 
> IETF’s Public Notary Transparency WG (TRANS) so that these use cases can be 
> discussed and cataloged. The information for this WG, and the documents it 
> works on, is available at https://datatracker.ietf.org/wg/trans/charter/.
> 
> Although the date is a year away, we encourage any participants that wish to 
> have their use cases addressed to bring them forward as soon as possible 
> during the next three months. This will ensure that the IETF, the CA/Browser 
> Forum, and the broader community at large have ample time to discuss the 
> challenges that may be faced, and find appropriate solutions for them. Such 
> solutions may be though technical changes via the IETF or via policy means 
> such as through the CA/Browser Forum or individual browsers’ root program 
> requirements.
> 
> We will continue outreach to CAs in trust stores used by Chrome to ensure 
> that they are prepared and that there is minimal user disruption.
> 
> To further support these investments in Certificate Transparency, the Chrome 
> team will be discussing a proposed new HTTP header at next month’s IETF 
> meeting that would allow sites to opt-in to having CT requirements enforced 
> in advance of this deadline.
> 
> Similarly, we welcome and encourage all CAs to voluntarily request that 
> browsers enforce CT logging of their new certificates before this deadline. 
> Doing so enhances CT's ability to protect users, detect misissuance, and in 
> the unfortunate event that misissuance does occur, to confirm the scope of 
> misissuance. This may allow browsers to take more targeted steps to remediate 
> the problem than otherwise possible, thus minimizing any negative impact to 
> their users.

Is there any timetable for enforcing CAs to support embedded CT or OCSP CT?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Remediation Plan for WoSign and StartCom

[Han Yuwei]

在 2016年10月21日星期五 UTC+8下午6:48:21，marc@gmail.com写道：
> Am Freitag, 21. Oktober 2016 03:59:08 UTC+2 schrieb Percy:
> > Kathleen,
> > As most users affected by this decision are Chinese, will you be able to 
> > make the blog post available in Chinese on the security blog as well? You 
> > can ask the Chinese firefox community or me to translate. 
> Hi,
> 
> only the distrust of Wosign affects mostly chinese Users.
> 
> The distrust of StartCom affects individuals, non profit organizations and 
> small companies worldwirde. StartCom was the only CA where these people and 
> groups could get ov,dv,s/mime and code signing certificates for a reasonable 
> price. Of course the incidents needed clarification and ofcourse actions are 
> to be taken to prevent such behaviour in future. But Gerv stated that the 
> main reasons for the harsh punishment are the lies and deceptions. The 
> responsible person is no longer in charge, StartCom has to pay a lot of money 
> to make the changes required by Mozilla. This is OK and fine from the view of 
> a customer / user.
> 
> But with distrusting StartCom roots Mozilla isn't increasing security for 
> their users and the web, Mozilla will decreasing the security.
> 
> A lot of people which have secured their services and code will lose this 
> possibility. From the view of a user not really understandable.
> 
> 
> Just the opinion of a user who is securing services, websites and his mails 
> with certificates but is not capable of paying hundreds of Euros / Dollars 
> for achieving this goal every year.
> 
> Greetings
> 
> Marc

I am also a StartCom's SSL & S/MIME certificate user. The only problem for me 
is that I must re-config nginx. S/MIME have a lot of alternatives for free. 
Code Signing may only works on Windows but Microsoft seems like don't care 
about this because CNNIC is still trusted.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Guang Dong Certificate Authority (GDCA) root inclusion request

[Han Yuwei]

在 2016年10月21日星期五 UTC+8下午12:15:07，wangs...@gmail.com写道：
> 在 2016年10月21日星期五 UTC+8上午12:15:00，Han Yuwei写道：
> > 在 2016年10月20日星期四 UTC+8上午5:27:42，Andrew R. Whalley写道：
> > > Hello,
> > > 
> > > Thank you for the links.  I note, however, that there's at least one
> > > difference between the native language version and the English 
> > > translation:
> > > 
> > > http://www.gdca.com.cn/cps/cps version 4.3 has a section 4.2.4 covering
> > > CAA.
> > > https://bug1128392.bmoattachments.org/attachment.cgi?id=8795091 version 
> > > 4.3
> > > in English has no such section.
> > > 
> > > The fact there's a discrepancy is rather worrying.  Could you please check
> > > and let me know if there are any other substantive differences between the
> > > Chinese and English versions?
> > > 
> > > Cheers,
> > > 
> > > Andrew
> > > 
> > > On Mon, Sep 26, 2016 at 7:17 PM, <wangsn1...@gmail.com> wrote:
> > > 
> > > > 在 2016年9月27日星期二 UTC+8上午4:15:00，Andrew R. Whalley写道：
> > > > > Hello,
> > > > >
> > > > > I have completed a read through of the English translations of the CP
> > > > > (v1.2) and CPS (v4.1). Before I post my comments I wanted to see if 
> > > > > there
> > > > > were any more recent translations?  It looks like the local language
> > > > > versions are 1.4 and 4.3 respectively.
> > > > >
> > > > > Many thanks,
> > > > >
> > > > > Andrew
> > > > >
> > > > > On Wed, Aug 3, 2016 at 2:45 PM, Kathleen Wilson <kwil...@mozilla.com>
> > > > wrote:
> > > > >
> > > > > > This request from Guangdong Certificate Authority (GDCA) is to 
> > > > > > include
> > > > the
> > > > > > "GDCA TrustAUTH R5 ROOT" certificate, turn on the Websites trust 
> > > > > > bit,
> > > > and
> > > > > > enabled EV treatment.
> > > > > >
> > > > > > GDCA is a nationally recognized CA that operates under China’s
> > > > Electronic
> > > > > > Signature Law. GDCA’s customers are business corporations 
> > > > > > registered in
> > > > > > mainland China, government agencies of China, individuals or 
> > > > > > mainland
> > > > China
> > > > > > citizens, servers of business corporations which have been 
> > > > > > registered
> > > > in
> > > > > > mainland China, and software developers.
> > > > > >
> > > > > > The request is documented in the following bug:
> > > > > > https://bugzilla.mozilla.org/show_bug.cgi?id=1128392
> > > > > >
> > > > > > And in the pending certificates list:
> > > > > > https://wiki.mozilla.org/CA:PendingCAs
> > > > > >
> > > > > > Summary of Information Gathered and Verified:
> > > > > > https://bugzilla.mozilla.org/attachment.cgi?id=8749437
> > > > > >
> > > > > > Noteworthy points:
> > > > > >
> > > > > > * Root Certificate Download URL:
> > > > > > https://bugzilla.mozilla.org/attachment.cgi?id=8748933
> > > > > > https://www.gdca.com.cn/cert/GDCA_TrustAUTH_R5_ROOT.der
> > > > > >
> > > > > > * The primary documents are provided in Chinese.
> > > > > >
> > > > > > CA Document Repository: https://www.gdca.com.cn/
> > > > > > customer_service/knowledge_universe/cp_cps/
> > > > > > http://www.gdca.com.cn/cp/cp
> > > > > > http://www.gdca.com.cn/cps/cps
> > > > > > http://www.gdca.com.cn/cp/ev-cp
> > > > > > http://www.gdca.com.cn/cps/ev-cps
> > > > > >
> > > > > > Translations into English:
> > > > > > CP: https://bugzilla.mozilla.org/attachment.cgi?id=8650346
> > > > > > CPS: https://bugzilla.mozilla.org/attachment.cgi?id=8688749
> > > > > >
> > > > > > * CA Hierarchy: This root certificate has internally-operated
> > > > subordinate
> > > > > > CAs
> > > > > > - GDCA TrustAUTH R4 SSL CA (issues 2048-bit SSL certs)
> > > > > > - GDCA TrustAUTH R4 Generic CA 

Re: Guang Dong Certificate Authority (GDCA) root inclusion request

[Han Yuwei]

在 2016年10月20日星期四 UTC+8上午5:27:42，Andrew R. Whalley写道：
> Hello,
> 
> Thank you for the links.  I note, however, that there's at least one
> difference between the native language version and the English translation:
> 
> http://www.gdca.com.cn/cps/cps version 4.3 has a section 4.2.4 covering
> CAA.
> https://bug1128392.bmoattachments.org/attachment.cgi?id=8795091 version 4.3
> in English has no such section.
> 
> The fact there's a discrepancy is rather worrying.  Could you please check
> and let me know if there are any other substantive differences between the
> Chinese and English versions?
> 
> Cheers,
> 
> Andrew
> 
> On Mon, Sep 26, 2016 at 7:17 PM,  wrote:
> 
> > 在 2016年9月27日星期二 UTC+8上午4:15:00，Andrew R. Whalley写道：
> > > Hello,
> > >
> > > I have completed a read through of the English translations of the CP
> > > (v1.2) and CPS (v4.1). Before I post my comments I wanted to see if there
> > > were any more recent translations?  It looks like the local language
> > > versions are 1.4 and 4.3 respectively.
> > >
> > > Many thanks,
> > >
> > > Andrew
> > >
> > > On Wed, Aug 3, 2016 at 2:45 PM, Kathleen Wilson 
> > wrote:
> > >
> > > > This request from Guangdong Certificate Authority (GDCA) is to include
> > the
> > > > "GDCA TrustAUTH R5 ROOT" certificate, turn on the Websites trust bit,
> > and
> > > > enabled EV treatment.
> > > >
> > > > GDCA is a nationally recognized CA that operates under China’s
> > Electronic
> > > > Signature Law. GDCA’s customers are business corporations registered in
> > > > mainland China, government agencies of China, individuals or mainland
> > China
> > > > citizens, servers of business corporations which have been registered
> > in
> > > > mainland China, and software developers.
> > > >
> > > > The request is documented in the following bug:
> > > > https://bugzilla.mozilla.org/show_bug.cgi?id=1128392
> > > >
> > > > And in the pending certificates list:
> > > > https://wiki.mozilla.org/CA:PendingCAs
> > > >
> > > > Summary of Information Gathered and Verified:
> > > > https://bugzilla.mozilla.org/attachment.cgi?id=8749437
> > > >
> > > > Noteworthy points:
> > > >
> > > > * Root Certificate Download URL:
> > > > https://bugzilla.mozilla.org/attachment.cgi?id=8748933
> > > > https://www.gdca.com.cn/cert/GDCA_TrustAUTH_R5_ROOT.der
> > > >
> > > > * The primary documents are provided in Chinese.
> > > >
> > > > CA Document Repository: https://www.gdca.com.cn/
> > > > customer_service/knowledge_universe/cp_cps/
> > > > http://www.gdca.com.cn/cp/cp
> > > > http://www.gdca.com.cn/cps/cps
> > > > http://www.gdca.com.cn/cp/ev-cp
> > > > http://www.gdca.com.cn/cps/ev-cps
> > > >
> > > > Translations into English:
> > > > CP: https://bugzilla.mozilla.org/attachment.cgi?id=8650346
> > > > CPS: https://bugzilla.mozilla.org/attachment.cgi?id=8688749
> > > >
> > > > * CA Hierarchy: This root certificate has internally-operated
> > subordinate
> > > > CAs
> > > > - GDCA TrustAUTH R4 SSL CA (issues 2048-bit SSL certs)
> > > > - GDCA TrustAUTH R4 Generic CA (issues 2048-bit individual certs)
> > > > - GDCA TrustAUTH R4 CodeSigning CA (issues 2048-bit CodeSigning certs)
> > > > - GDCA TrustAUTH R4 Extended Validation SSL CA (issues 2048-bit EV SSL
> > > > certs)
> > > > - GDCA TrustAUTH R4 Extended Validation Code Signing CA (issues
> > 2048-bit
> > > > EV CodeSigning certs)
> > > >
> > > > * This request is to turn on the Websites trust bit.
> > > >
> > > > CPS section 3.2.5: For domain verification, GDCA needs to check the
> > > > written materials which can be used to prove the ownership of
> > corresponding
> > > > domain provided by applicant. Meanwhile, GDCA should ensure the
> > ownership
> > > > of domain from corresponding registrant or other authoritative
> > third-party
> > > > databases. During the verification, GDCA needs to perform the following
> > > > procedures:
> > > > 1. GDCA should confirm that the domain's owner is certificate applicant
> > > > based on the information queried from corresponding domain registrant
> > or
> > > > authoritative third-party database and provided by applicant.
> > > > 2. GDCA should confirm that the significant information (such as
> > document
> > > > information of applicant) in application materials are consistent with
> > the
> > > > reply of domain's owner by sending email or making phone call based on
> > the
> > > > contact information (such as email, registrar, administrator's email
> > > > published at this domain's website, etc.) queried from corresponding
> > domain
> > > > registrant or authoritative third-party database.
> > > > If necessary, GDCA also need to take other review measures to confirm
> > the
> > > > ownership of the domain name. Applicant can't refuse to the request for
> > > > providing appropriate assistance.
> > > >
> > > >
> > > > * EV Policy OID: 1.2.156.112559.1.1.6.1
> > > >
> > > > * Test Website: https://ev-ssl-test-1.95105813.cn/
> > > >
> > > > * CRL URLs:

Re: Remediation Plan for WoSign and StartCom

[Han Yuwei]

在 2016年10月19日星期三 UTC+8上午6:42:18，Ryan Hurst写道：
> All,
> 
> I do not understand the desire to require StartCom / WoSign to not utilize 
> their own logs as part of the associated quorum policy. 
> 
> Certificate Transparency's idempotency is for not dependent on the practices 
> of the operator. By requiring the use of a third-party log (in this case 
> Google's) and requiring that the logs are public,  CT "works" as expected.
> 
> There appears to be an argument being made that this restriction comes from 
> the fact that Firefox does not yet have CT support, I would argue that this 
> is not material. My justification for this argument is that today, Firefox 
> depends on SafeBrowsing, this is a Google-provided service and Firefox uses 
> it to protect users from malicious sites.
> 
> This is not significantly different from the way Chrome (and others) rely on 
> the wonderful Mozilla Trusted Root Program.
> 
> Based on this it seems reasonable to allow them to use the same logs they use 
> for EV.
> 
> Ryan

Could you explain what "idempotency" means? Because I am not a native English 
speaker and I can't lookup a good meaning about this word.

For the StartCom/Wosign's log, I think maybe Mozilla's logic is that they are 
not trustworthy when ther are appling CAs, so their CT logs can't be 
trusted.But I don't think that's right because there's a Google log also 
monitoring this.What I am interested in is why some CT log operator rejected 
the including request from StartCom. Performance is not persuading reason.

For the CT support, is there any plan to implement it into effect in Firefox? 
And if implemented, what would happen if server's certificate don't have enough 
SCTs?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Remediation Plan for WoSign and StartCom

[Han Yuwei]

在 2016年10月18日星期二 UTC+8下午10:38:07，Inigo Barreira写道：
> Hi all,
> 
> 
> I´ve been reading some emails that need clarification form both sides.
> 
> Firstly I´d like to remind, if I´m not wrong, that Kathleen proposed an 
> action plan for distrusting StartCom, which has been taken as the final 
> decission, but with a small option to regain the trust for StartCom in 
> Mozilla if we can make her recover the confidance in StartCom.
> 
> Two weeks ago, there was a meeting between StartCom and Mozilla that 
> everybody was aware and on friday of that week, StartCom published the 
> outcome of that meeting, having this last week to set specific dates and 
> tasks for making it real. The surprise came when Kathleen droped the 
> email with the sanctions plan. In any case, StartCom published on 
> friday, at 10:30 CET, a remediation plan (it was already done by 
> thursday that week, but it´s difficult to coordinate with so many hours 
> of difference) on StartCom´s website. Surprisingly, there hasn´t been 
> any comment, in this mailing list, to that message (I even had to ask 
> Gerv if I posted correctly) in which there is more detailed information 
> on the next steps to be done.
> 
> Here´s the link again: 
> https://www.startssl.com/report/StartCom_Remediation_Plan_14102016.pdf
> 
> So, regarding the situation of StartCom I think that some people has 
> lost what happened and it´s considering Wosign and Startcom the same.
> 
> Let´s focus on the 3 issues for which StartCom has been proposed to a 
> sanction (hopefully we can change that), and these are:
> 
> 1.- Bad coding of a new solution called startencrypt, which basically 
> was barely used and not affected StartCom
> 
> 2.- Issues with serial numbers, not able to generate serial numbers 
> starting with zero and the reuse of some. Those were bugs fixed on time 
> and were because of a software and hardware upgrading as explained 
> before, due to the acquisiton of Wosign because the PKI was cloned. This 
> is also indicated in the plan
> 
> 3.- Backdating 2 certs for Tyro. I think this is the issue that has made 
> Mozilla to include Startcom in the equation and fine it. But as also 
> explained this is not a security issue (same as other SHA1 certs 
> legitimacy issued on time) but a bad practice
> 
> In any case, this mailing list is called mozilla.dev._security_.policy, 
> and for these 3 issues, imho there´s no security problem. We can talk 
> about how things have been done, there´s been some cheating, hidden 
> info, bad practices, etc. That´s totally true but as Mozilla always 
> remembers about their users base, these have not been affected by any 
> security problem. Recently some emails remembered the comodogate, the 
> diginotar, etc. back in 2011, and those were different because the 
> attacker had control over the issuance process and some certificates 
> were issued without knowledge and/or consent of the CA, and this is not 
> what has happened to StartCom in which all the cryptographic material 
> was under control of the companies (including wosign)
> 
> Of course, there has been bad decissions, bad practices and procedures, 
> etc. but if you see the plan, there you can find all the actions that 
> are taking place to avoid this situation again.
> 
> In any case, taking as examples the recent issues affecting Comodo and 
> Globalsign (I´m just mention these because have been published at the 
> same time) it makes me feel with a strange feeling. Comodo issue was an 
> unintentionally or unauthorized issuance of a certificate for a ".sb", 
> can´t remember now, (could be compared to the 2 backdated certificates) 
> and globalsign revoked an intermediate certificate and later un-revoked 
> it (I don´t know if this is allowed in the RC 6960, but in ETSI once a 
> certificate is revoked, you can´t reisntate it status). Again, those are 
> examples and the only concern for me, it´s that the bar in the case of 
> StartCom is not the same in the case of others, again, taking into 
> account what has mentioned above and the control over the keys has not 
> been lost. The price for StartCom is too high.
> 
> For some specific questions that are around this issue, for example, 
> those related to communicate the end users, I have to say that:
> 
> - Mozilla runs a root program on a voluntary basis. So any CA may join, 
> stay or leave on its own discretion. If the CA decides to join, then it 
> shall follow the root program requirements
> 
> - Every CA must have its own procedures and practices for doing its 
> business, independently if decides to join a specific root program or not
> 
> - Mozilla and other root programs can impose its rules to the CAs that 
> voluntary decide to adhere to the programs but can´t have any decission 
> on what a CA decides or not related to its business. Of course comments, 
> suggestions, etc. are welcome in the comunity
> 
> - StartCom has made publicly this report in which they explain what are 
> going to 

Re: StartCom remediation plan

[Han Yuwei]

在 2016年10月14日星期五 UTC+8下午11:23:10，Gervase Markham写道：
> Hi Xiaosheng,
> 
> On 14/10/16 16:06, 谭晓生 wrote:
> > We’ll rewrite all the code with different programing language or buy
> > 3rd party components (for example: PKI), Wosign team using .Net, but
> > my team never use .Net, they are good at C/C++ and PHP, Python.
> 
> It would be great to be clear about what the plan in each case - whether
> it's a "audit, check and review" of the existing codebase, or whether
> it's a rewrite, or whether it's a 3rd party implementation.
> 
> The deadlines in the document are:
> 
> Website:  Dec 31st 2016
> CMS:  Dec 31st 2016
> PKI:  Dec 1st 2016 (replace with StartCom version)
>   Feb 2017 (implement 3rd party)
> OCSP/CRL: Dec 1st 2016
> 
> There are only six weeks between now and Dec 1st 2016. There is no way
> your team, no matter how big or skilled it is, can safely and securely
> write a new OCSP/CRL system in six weeks, and then finish a website and
> a CMS four weeks after that. Even if Python is awesome ;-)
> 
> Gerv

There's no any open-source solution? Maybe Mozilla could build one?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Remediation Plan for WoSign and StartCom

[Han Yuwei]

在 2016年10月14日星期五 UTC+8上午12:50:02，Kathleen Wilson写道：
> All,
> 
> Thanks again to all of you who have put in so much time and effort to 
> determine what happened with WoSign and StartCom and discuss what to do about 
> it.
> 
> Based on the information that I have seen regarding WoSign, I believe that 
> WoSign intentionally bent the rules in order to continue issuing SHA-1 SSL 
> certs, when they knew full well that was no longer allowed. I also believe 
> that the deception continued even after Mozilla directly asked WoSign about 
> this. WoSign has lost my confidence in their ability and intention to follow 
> Mozilla's policies. Therefore, I think we should respond similarly to WoSign 
> as we did to CNNIC [1][2]. Unfortunately, the number of certificates and the 
> timescales involved are such that we prefer not to create a list of the 
> domains for which previously-issued certs that chain up to the Affected Roots 
> may continue to be trusted, so our approach will be a little different, as 
> Gerv previously described[3].
> 
> Within this message, the term “Affected Roots” applies to the following 7 
> root certificates.
> 
> 1) Subject: CN=CA 沃通根证书, OU=null, O=WoSign CA Limited, C=CN
> Certificate Serial Number: 50706bcdd813fc1b4e3b3372d211488d
> SHA-1 Fingerprint   
> 16:32:47:8D:89:F9:21:3A:92:00:85:63:F5:A4:A7:D3:12:40:8A:D6
> SHA-256 Fingerprint   
> D6:F0:34:BD:94:AA:23:3F:02:97:EC:A4:24:5B:28:39:73:E4:47:AA:59:0F:31:0C:77:F4:8F:DF:83:11:22:54
> 
> 2) Subject: CN=Certification Authority of WoSign, OU=null, O=WoSign CA 
> Limited, C=CN
> Certificate Serial Number: 5e68d61171946350560068f33ec9c591
> SHA-1 Fingerprint   
> B9:42:94:BF:91:EA:8F:B6:4B:E6:10:97:C7:FB:00:13:59:B6:76:CB
> SHA-256 Fingerprint   
> 4B:22:D5:A6:AE:C9:9F:3C:DB:79:AA:5E:C0:68:38:47:9C:D5:EC:BA:71:64:F7:F2:2D:C1:D6:5F:63:D8:57:08
> 
> 3) Subject: CN=Certification Authority of WoSign G2, OU=null, O=WoSign CA 
> Limited, C=CN
> Certificate Serial Number: 6b25da8a889d7cbc0f05b3b17a614544
> SHA-1 Fingerprint   
> FB:ED:DC:90:65:B7:27:20:37:BC:55:0C:9C:56:DE:BB:F2:78:94:E1
> SHA-256 Fingerprint   
> D4:87:A5:6F:83:B0:74:82:E8:5E:96:33:94:C1:EC:C2:C9:E5:1D:09:03:EE:94:6B:02:C3:01:58:1E:D9:9E:16
> 
> 4) Subject: CN=CA WoSign ECC Root, OU=null, O=WoSign CA Limited, C=CN
> Certificate Serial Number: 684a5870806bf08f02faf6dee8b09090
> SHA-1 Fingerprint   
> D2:7A:D2:BE:ED:94:C0:A1:3C:C7:25:21:EA:5D:71:BE:81:19:F3:2B
> SHA-256 Fingerprint   
> 8B:45:DA:1C:06:F7:91:EB:0C:AB:F2:6B:E5:88:F5:FB:23:16:5C:2E:61:4B:F8:85:56:2D:0D:CE:50:B2:9B:02
> 
> 5) Subject: CN=StartCom Certification Authority, OU=Secure Digital 
> Certificate Signing, O=StartCom Ltd., C=IL
> Certificate Serial Number: 01
> SHA-1 Fingerprint   
> 3E:2B:F7:F2:03:1B:96:F3:8C:E6:C4:D8:A8:5D:3E:2D:58:47:6A:0F
> SHA-256 Fingerprint   
> C7:66:A9:BE:F2:D4:07:1C:86:3A:31:AA:49:20:E8:13:B2:D1:98:60:8C:B7:B7:CF:E2:11:43:B8:36:DF:09:EA
> 
> 6) Subject: CN=StartCom Certification Authority, OU=Secure Digital 
> Certificate Signing, O=StartCom Ltd., C=IL
> Certificate Serial Number: 2d
> SHA-1 Fingerprint   
> A3:F1:33:3F:E2:42:BF:CF:C5:D1:4E:8F:39:42:98:40:68:10:D1:A0
> SHA-256 Fingerprint   
> E1:78:90:EE:09:A3:FB:F4:F4:8B:9C:41:4A:17:D6:37:B7:A5:06:47:E9:BC:75:23:22:72:7F:CC:17:42:A9:11
> 
> 7) Subject: CN=StartCom Certification Authority G2, OU=null, O=StartCom Ltd., 
> C=IL
> Certificate Serial Number: 3b
> SHA-1 Fingerprint   
> 31:F1:FD:68:22:63:20:EE:C6:3B:3F:9D:EA:4A:3E:53:7C:7C:39:17
> SHA-256 Fingerprint   
> C7:BA:65:67:DE:93:A7:98:AE:1F:AA:79:1E:71:2D:37:8F:AE:1F:93:C4:39:7F:EA:44:1B:B7:CB:E6:FD:59:95
> 
> I intend to move forward as follows, unless further information or input 
> causes me to rethink this plan. Therefore, I will continue to appreciate your 
> input, and this discussion is still open.
> 
> Mozilla will perform the following 4 actions. I have filed Bugzilla Bug 
> #1309707 to track the engineering work for this. Please keep discussion here 
> in mozilla.dev.security.policy, and not in the bug.
> 
> 1) Distrust certificates chaining up to Affected Roots with a notBefore date 
> after October 21, 2016. If additional back-dating is discovered (by any 
> means) to circumvent this control, then Mozilla will immediately and 
> permanently revoke trust in the Affected Roots.
> -- This change will go into the Firefox 51 release train [4]. 
> -- The code will use the subject key id (hash of public key) to identify the 
> Affected Roots, so that the control will also apply to cross-certs of the 
> Affected Roots.
> 2) Add the previously identified backdated SHA-1 certs chaining up to the 
> Affected Roots to OneCRL.
> 3) No longer accept audits carried out by Ernst & Young Hong Kong.
> 4) Remove the Affected Roots from NSS after the SSL certificates issued 
> before October 1, 2016, have expired or have been replaced.
> 
> WoSign may apply for inclusion of new (replacement) root certificates 
> following Mozilla's normal root inclusion/change process (minus waiting 

Re: List Content Policy

[Han Yuwei]

在 2016年10月13日星期四 UTC+8下午11:58:54，Gervase Markham写道：
> A note on accepted content for this list:
> 
> Concrete information which may be important for security policy
> decisions Mozilla has to make is welcome. Wild and unsubstantiated
> accusations are not, nor are comments which attack a person or company
> based on their nationality. I have already rejected one message of this
> type and will reject further ones as necessary.
> 
> Gerv

What handl...@gmail.com said at "StartCom & Qihoo incidents" in Chinese is also 
a offended content. Sent time is 2016OCT13 15:10 UTC
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: WoSign: updated report and discussion

[Han Yuwei]

在 2016年10月13日星期四 UTC+8下午9:09:11，uri...@gmail.com写道：
> >WoSign will resell other trusted CA's SSL certificate to our customers to 
> >provide best product and best service to our customers. 
> 
> Is the plan to resell StartCom certificates?
> 
> On Thursday, October 13, 2016 at 4:18:54 AM UTC-4, Richard Wang wrote:
> > Percy,
> > 
> > I think your English is too bad! And the English translation from Chinese 
> > is very bad.
> > The report said: "Richard Wang will be relieved of his duties as CEO of 
> > WoSign", it is "will be". Now I am the Acting CEO of WoSign till the new 
> > CEO arrives. Anybody that is interesting in this hot position of the CEO of 
> > WoSign can send your Resume to me.
> > 
> > WoSign will resell other trusted CA's SSL certificate to our customers to 
> > provide best product and best service to our customers.
> > 
> > Again, your English translation from Chinese is very bad, I copy the 
> > Chinese sentence here that I wish somebody can translate it correctly.
> > 沃通(WoSign)能取得今天的成绩，除了需要感谢公司创始人/CEO王高华先生带领全体员工一起努力拼搏和全力奉献以外，更应该感谢多年来广大用户对沃通(WoSign)品牌的厚爱，我们对这样的信任倍感珍惜，将不负使命克服各种困难为广大用户提供更好的产品和更优质的服务。
> >  
> > 
> > Best Regards,
> > 
> > Richard Wang
> > 
> > 
> > -Original Message-
> > From: dev-security-policy 
> > [mailto:dev-security-policy-bounces+richard=wosign@lists.mozilla.org] 
> > On Behalf Of Percy
> > Sent: Thursday, October 13, 2016 8:25 AM
> > To: mozilla-dev-security-pol...@lists.mozilla.org
> > Subject: Re: WoSign: updated report and discussion
> > 
> > WoSign has so far announced nothing about those incidents or immediate 
> > distrust (Apple and Mozilla) to its end users. On the contrary, WoSign had 
> > a press release dated Oct 8th 
> > (https://www.wosign.com/news/netcraft-ssl-oct.htm) titled "WoSign SSL certs 
> > reaches almost 50% market share in China". In the press release, it stated 
> > that "WoSign's achievement today is due to company founder and CEO Richard 
> > Wang leads all staff to be dedicated". WoSign is depicted as this positive, 
> > strong growing company. Nothing about its distrust in the immediate future 
> > is mentioned. 
> > 
> > In Oct 7th, in the incident report in English, WoSign admitted multiple 
> > intentional mistakes and deceptions  
> > (https://www.google.com/url?q=https%3A%2F%2Fwww.wosign.com%2Freport%2FWoSign_Incident_Report_Update_07102016.pdf=D=1=AFQjCNGRzAxwYrEEiA_SN5gfcsftSst0nA)
> >  and that the CEO Richard Wang to be relieved of its duties. 
> > 
> > I'm calling WoSign out on this two-faced behavior towards Chinese end users 
> > and foreign security researchers.
> > ___
> > dev-security-policy mailing list
> > dev-security-policy@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-security-policy

Wosign's initial business is reselling other's certificates.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: StartCom & Qihoo Incidents

[Han Yuwei]

在 2016年10月13日星期四 UTC+8下午2:01:19，yliv...@gmail.com写道：
> Would this be enough? 
> http://www.cac.gov.cn/2016-09/19/c_1119583763.htm
> 
> On Thursday, October 13, 2016 at 10:58:34 AM UTC+8, 谭晓生 wrote:
> > Yuwei, 
> > I don’t know who you are, but I can tell you and the community, Qihoo 360 
> > never been involved in * Fire Wall project, if you did some 
> > investigation to the message that accused Qihoo 360 joined the project 
> > “Search Engine Content Security Management System”, you should know the 
> > project had been done on Feb 2005, before Qihoo 360 was founded on Aug 
> > 2005, and the project is neither part of the * fire wall project nor a 
> > project done by Qihoo 360, actually it is part of the efforts to help 
> > Yahoo’s search engine could work in China, I was the tech head of 
> > Yahoo!China ‘s tech team, director of engineering and soon the CTO of 
> > Yahoo!China, I know what happened at that time.
> >  
> > Thanks，
> > Xiaosheng Tan
> > 
> > 
> > 
> > 在 2016/10/13 上午5:22，“dev-security-policy 代表 Han 
> > Yuwei”<dev-security-policy-bounces+tanxiaosheng=360...@lists.mozilla.org 代表 
> > hanyuwe...@gmail.com> 写入:
> > 
> > 在 2016年10月13日星期四 UTC+8上午3:12:08，Ryan Sleevi写道：
> > > As Gerv suggested this was the official call for incidents with 
> > respect to StartCom, it seems appropriate to start a new thread.
> > > 
> > > It would seem that, in evaluating the relationship with WoSign and 
> > Qihoo, we naturally reach three possible conclusions:
> > > 1) StartCom is treated as an independent entity
> > > 2) StartCom is treated as a subsidiary of Qihoo
> > > 3) StartCom is treated as a subsidiary of WoSign
> > > 
> > > We know there are serious incidents with WoSign that, collectively, 
> > encourage the community to distrust future certificates. However, there 
> > hasn't been a similar investigation into the trustworthiness of StartCom as 
> > an independent entity or as an entity operated by Qihoo. It would seem that 
> > germane to the discussion is how trustworthy the claims are - from either 
> > StartCom or Qihoo - and how that affects trust.
> > > 
> > > Incidents with StartCom:
> > > A) Duplicate Serials. 
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1029884
> > > We know that StartCom had issues issuing duplicate serials, in 
> > violation of RFC 5280. We know that they did not prioritize resolution, and 
> > when attempting resolution, did so incompletely, as the issue still 
> > resurfaced.
> > > 
> > > C) Improper OCSP responder. 
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1006479 / 
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1151270
> > > We know that StartCom continues to have issue with their OCSP 
> > responder after they issue certificates. Presumably, this is a CDN 
> > distribution delay, but we can't be sure, especially considering Incident A 
> > was with the underlying systems. As a consequence of this, users with 
> > StartCom certificates are disproportionately disadvantaged from enabling 
> > OCSP stapling, which many browser programs support (and is perhaps the only 
> > viable path towards a complete revocation solution).
> > > 
> > > E) Heartbleed. https://bugzilla.mozilla.org/show_bug.cgi?id=994033 / 
> > https://bugzilla.mozilla.org/show_bug.cgi?id=994478
> > > We know StartCom had a notoriously poor response to HeartBleed. Eddy 
> > first dismissed the significance, and then when proven wrong, still 
> > continued to charge $25 USD for revocation. Ostensibly, this is a violation 
> > of the Baseline Requirements, in that CAs are required to revoke 
> > certificates suspected of Key Compromise. However, despite the BRs 
> > effective date of 2012, Mozilla was not aggressively imposing compliance 
> > then (... or now, to be fair).
> > > 
> > > G) StartCom BR violations - IV 
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1266942
> > > StartCom was materially violating its CP/CPS and the Baseline 
> > Requirements with respect to certain types of validation. No explanation 
> > for the root cause provided.
> > > 
> > > I) StartCom BR violations (2) - Key Sizes 
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1015767
> > > StartCom was issuing certificates less than 2048 bits.
> > > 
> > > K) StartCom impersonating mozilla.com. 
> > https://bugzilla.mozilla.org/show_bug.c

Re: StartCom & Qihoo Incidents

[Han Yuwei]

在 2016年10月13日星期四 UTC+8上午10:58:34，谭晓生写道：
> Yuwei, 
> I don’t know who you are, but I can tell you and the community, Qihoo 360 
> never been involved in * Fire Wall project, if you did some investigation 
> to the message that accused Qihoo 360 joined the project “Search Engine 
> Content Security Management System”, you should know the project had been 
> done on Feb 2005, before Qihoo 360 was founded on Aug 2005, and the project 
> is neither part of the * fire wall project nor a project done by Qihoo 
> 360, actually it is part of the efforts to help Yahoo’s search engine could 
> work in China, I was the tech head of Yahoo!China ‘s tech team, director of 
> engineering and soon the CTO of Yahoo!China, I know what happened at that 
> time.
>  
> Thanks，
> Xiaosheng Tan
> 
> 
> 
> 在 2016/10/13 上午5:22，“dev-security-policy 代表 Han 
> Yuwei”<dev-security-policy-bounces+tanxiaosheng=360...@lists.mozilla.org 代表 
> hanyuwe...@gmail.com> 写入:
> 
> 在 2016年10月13日星期四 UTC+8上午3:12:08，Ryan Sleevi写道：
> > As Gerv suggested this was the official call for incidents with respect 
> to StartCom, it seems appropriate to start a new thread.
> > 
> > It would seem that, in evaluating the relationship with WoSign and 
> Qihoo, we naturally reach three possible conclusions:
> > 1) StartCom is treated as an independent entity
> > 2) StartCom is treated as a subsidiary of Qihoo
> > 3) StartCom is treated as a subsidiary of WoSign
> > 
> > We know there are serious incidents with WoSign that, collectively, 
> encourage the community to distrust future certificates. However, there 
> hasn't been a similar investigation into the trustworthiness of StartCom as 
> an independent entity or as an entity operated by Qihoo. It would seem that 
> germane to the discussion is how trustworthy the claims are - from either 
> StartCom or Qihoo - and how that affects trust.
> > 
> > Incidents with StartCom:
> > A) Duplicate Serials. 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1029884
> > We know that StartCom had issues issuing duplicate serials, in 
> violation of RFC 5280. We know that they did not prioritize resolution, and 
> when attempting resolution, did so incompletely, as the issue still 
> resurfaced.
> > 
> > C) Improper OCSP responder. 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1006479 / 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1151270
> > We know that StartCom continues to have issue with their OCSP responder 
> after they issue certificates. Presumably, this is a CDN distribution delay, 
> but we can't be sure, especially considering Incident A was with the 
> underlying systems. As a consequence of this, users with StartCom 
> certificates are disproportionately disadvantaged from enabling OCSP 
> stapling, which many browser programs support (and is perhaps the only viable 
> path towards a complete revocation solution).
> > 
> > E) Heartbleed. https://bugzilla.mozilla.org/show_bug.cgi?id=994033 / 
> https://bugzilla.mozilla.org/show_bug.cgi?id=994478
> > We know StartCom had a notoriously poor response to HeartBleed. Eddy 
> first dismissed the significance, and then when proven wrong, still continued 
> to charge $25 USD for revocation. Ostensibly, this is a violation of the 
> Baseline Requirements, in that CAs are required to revoke certificates 
> suspected of Key Compromise. However, despite the BRs effective date of 2012, 
> Mozilla was not aggressively imposing compliance then (... or now, to be 
> fair).
> > 
> > G) StartCom BR violations - IV 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1266942
> > StartCom was materially violating its CP/CPS and the Baseline 
> Requirements with respect to certain types of validation. No explanation for 
> the root cause provided.
> > 
> > I) StartCom BR violations (2) - Key Sizes 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1015767
> > StartCom was issuing certificates less than 2048 bits.
> > 
> > K) StartCom impersonating mozilla.com. 
> https://bugzilla.mozilla.org/show_bug.cgi?id=471702
> > StartCom's (former) CEO Eddy Nigg obtained a key and certificate for 
> www.mozilla.com and placed it on an Internet-facing server.
> > 
> > M) StartCom BR violations (3) - Key exponents 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1212655
> > StartCom was not enforcing the BRs with respect to RSA public exponents.
> > 
> > O) StartCom BR violations (4) - Curve violations 
> https://bug98304.bugzilla.mozilla.org/show_bug.cgi?id=1269183
> > StartCom was not enforci

Re: StartCom & Qihoo Incidents

[Han Yuwei]

在 2016年10月13日星期四 UTC+8上午3:12:08，Ryan Sleevi写道：
> As Gerv suggested this was the official call for incidents with respect to 
> StartCom, it seems appropriate to start a new thread.
> 
> It would seem that, in evaluating the relationship with WoSign and Qihoo, we 
> naturally reach three possible conclusions:
> 1) StartCom is treated as an independent entity
> 2) StartCom is treated as a subsidiary of Qihoo
> 3) StartCom is treated as a subsidiary of WoSign
> 
> We know there are serious incidents with WoSign that, collectively, encourage 
> the community to distrust future certificates. However, there hasn't been a 
> similar investigation into the trustworthiness of StartCom as an independent 
> entity or as an entity operated by Qihoo. It would seem that germane to the 
> discussion is how trustworthy the claims are - from either StartCom or Qihoo 
> - and how that affects trust.
> 
> Incidents with StartCom:
> A) Duplicate Serials. https://bugzilla.mozilla.org/show_bug.cgi?id=1029884
> We know that StartCom had issues issuing duplicate serials, in violation of 
> RFC 5280. We know that they did not prioritize resolution, and when 
> attempting resolution, did so incompletely, as the issue still resurfaced.
> 
> C) Improper OCSP responder. 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1006479 / 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1151270
> We know that StartCom continues to have issue with their OCSP responder after 
> they issue certificates. Presumably, this is a CDN distribution delay, but we 
> can't be sure, especially considering Incident A was with the underlying 
> systems. As a consequence of this, users with StartCom certificates are 
> disproportionately disadvantaged from enabling OCSP stapling, which many 
> browser programs support (and is perhaps the only viable path towards a 
> complete revocation solution).
> 
> E) Heartbleed. https://bugzilla.mozilla.org/show_bug.cgi?id=994033 / 
> https://bugzilla.mozilla.org/show_bug.cgi?id=994478
> We know StartCom had a notoriously poor response to HeartBleed. Eddy first 
> dismissed the significance, and then when proven wrong, still continued to 
> charge $25 USD for revocation. Ostensibly, this is a violation of the 
> Baseline Requirements, in that CAs are required to revoke certificates 
> suspected of Key Compromise. However, despite the BRs effective date of 2012, 
> Mozilla was not aggressively imposing compliance then (... or now, to be 
> fair).
> 
> G) StartCom BR violations - IV 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1266942
> StartCom was materially violating its CP/CPS and the Baseline Requirements 
> with respect to certain types of validation. No explanation for the root 
> cause provided.
> 
> I) StartCom BR violations (2) - Key Sizes 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1015767
> StartCom was issuing certificates less than 2048 bits.
> 
> K) StartCom impersonating mozilla.com. 
> https://bugzilla.mozilla.org/show_bug.cgi?id=471702
> StartCom's (former) CEO Eddy Nigg obtained a key and certificate for 
> www.mozilla.com and placed it on an Internet-facing server.
> 
> M) StartCom BR violations (3) - Key exponents 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1212655
> StartCom was not enforcing the BRs with respect to RSA public exponents.
> 
> O) StartCom BR violations (4) - Curve violations 
> https://bug98304.bugzilla.mozilla.org/show_bug.cgi?id=1269183
> StartCom was not enforcing the BRs with respect to EC curve algorithms.
> 
> 
> 
> In addition to discussion of StartCom issues, it seems relevant to future 
> trust to evaluate issues with Qihoo. Many in the Mozilla community may not 
> have direct interactions with Qihoo, but they have obtained some notoriety in 
> security circles.
> 
> Q.A) Qihoo masking their browser as a critical Windows security update to IE 
> users.
> http://wmos.info/archives/7717 / 
> http://www.theregister.co.uk/2013/02/01/qihoo_government_warning_fraud/
> Qihoo displayed a misleading security update for Windows users that instead 
> installed their browser.
> 
> Q.C) Qihoo browser actively enables insecure cryptography.
> https://docs.google.com/document/d/1b7lenmn5XO06QohaJzVffnJxjXjY1rD70wg34gfuxRo/edit
> Qihoo's browser is notably insecure with respect to SSL/TLS, with some of the 
> insecure changes requiring active modification to the low-level source 
> libraries that Chromium (of which they're based on) uses.
> 
> Q.E) Qihoo apps removed from app stores due to malware
> https://www.techinasia.com/qihoo-committing-fraud-google-making-huge-mistake 
> / https://www.techinasia.com/qihoo-apps-banned-apple-app-store
> Qihoo Apps have repeatedly been banned from Apple's App Store due to issues
> 
> Q.G) Qihoo "security" apps repeatedly found as unfair competition
> https://www.techinasia.com/qihoo-360-loses-chinas-courts-ordered-pay-sogou-82-million-unfair-competition
> 
> 
> 
> I hope the above show that the odds are if the original StartCom systems are 
> 

Re: WoSign and StartCom

[Han Yuwei]

在 2016年9月26日星期一 UTC+8下午10:21:13，Gervase Markham写道：
> Today, Mozilla is publishing an additional document containing further
> research into the back-dating of SHA-1 certificates, in violation of the
> CAB Forum Baseline Requirements, to avoid browser blocks. It also
> contains some conclusions we have drawn from the recent investigations,
> and a proposal for discussion regarding the action that Mozilla's root
> program should take in response.
> 
> Because this document is extensive and contains embedded images, links
> and formatting, I have published it on Google Docs instead of as an
> email message here:
> 
> https://docs.google.com/document/d/1C6BlmbeQfn4a9zydVi2UvjBGv6szuSB4sMYUcVrR8vQ/edit
> 
> However, this forum is the appropriate place for discussing it. Please
> feel free to cut and paste any parts you wish to quote and comment on.
> 
> Gerv

About the auditor Ernst & Young (Hong Kong), I don't understand how did it(?) 
involved this. Can someone explain that?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: WoSign: updated report and discussion

[Han Yuwei]

在 2016年10月7日星期五 UTC+8下午7:13:42，Gervase Markham写道：
> As noted by Richard Wang, WoSign have just published an updated Incident
> Report:
> https://www.wosign.com/report/WoSign_Incident_Report_Update_07102016.pdf
> 
> I think we are now in a position to discuss whether the plan proposed here:
> https://docs.google.com/document/d/1C6BlmbeQfn4a9zydVi2UvjBGv6szuSB4sMYUcVrR8vQ/edit#
> is still appropriate for WoSign.
> 
> Because it contains repeated or lightly-updated information about all of
> the issues on the issues list, the updated Incident Report rather
> "buries the lede" (hides the important news). Therefore I felt it might
> be worth highlighting some of the things within it:
> 
> * WoSign admits that it has issued 64 back-dated SHA-1 certificates. The
> cause was a mixture of intentional issuance using a created pathway, and
> bugs which triggered that pathway by mistake.
> 
> * This includes admitting the misissuance of the certificates for
> tyro.com by StartCom, which were the subject of Mozilla's most recent
> investigation; this issuance was approved by Richard Wang.
> 
> * WoSign agrees it should have been more forthcoming about its purchase
> of StartCom, and announced it earlier.
> 
> * WoSign and StartCom are to be legally separated, with the corporate
> structure changed such that Qihoo 360 owns them both individually,
> rather than WoSign owning StartCom.
> 
> * There will be personnel changes:
> 
>   - StartCom’s chairman will be Xiaosheng Tan (Chief Security Officer
> of Qihoo 360).
>   - StartCom’s CEO will be Inigo Barreira (formerly GM of StartCom
> Europe).
>   - Richard Wang will be relieved of his duties as CEO of WoSign and
> other responsibilities. It is not decided who will replace him.
> 
> * StartCom will soon provide a plan on how they will separate their
> operations and technology from that of WoSign.
> 
> * In the light of these changes, Qihoo 360 request that WoSign and
> StartCom be considered separately.
> 
> 
> Mozilla is minded to agree that it is reasonable to at least consider
> the two companies separately, although that does not preclude the
> possibility that we might decide to take the same action for both of
> them. Accordingly, Mozilla continues to await the full remediation plan
> from StartCom so as to have a full picture. However, I think we can work
> towards a conclusion for WoSign now.
> 
> Gerv

According to the previous discussion, I think that maybe a community-driven 
program of CA's issue system could be established. Code is open and everyone 
can audit it. But what's more important is to build the culture of reporting 
issue like civil aviation and civil nuclear system.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: WoSign and StartCom: next steps

[Han Yuwei]

在 2016年9月29日星期四 UTC+8下午11:41:12，Gervase Markham写道：
> Hi everyone,
> 
> Following the publication of the recent investigative report,
> representatives of Qihoo 360 and StartCom have requested a face-to-face
> meeting with Mozilla. We have accepted, and that meeting will take place
> next Tuesday in London.
> 
> After that, we expect to see a public response and proposal for
> remediation from them, which will be discussed here before Mozilla makes
> a final decision on the action we will take.
> 
> Gerv

Could you disclosure what would you talk about or would be determined on the 
meeting? And would there be a video or transcript about your meeting?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: WoSign and StartCom

[Han Yuwei]

在 2016年9月27日星期二 UTC+8下午11:21:26，Hector Martin "marcan"写道：
> On 2016-09-27 23:21, Han Yuwei wrote:
> > 在 2016年9月27日星期二 UTC+8下午8:33:28，Gervase Markham写道：
> >> On 27/09/16 13:13, adroidm...@gmail.com wrote:
> >>> We must use Windows XP becuase some programs can only run on XP. We
> >>> have no money to get new programs and new Windows. Do you give $$$￥￥￥
> >>> to me??? You don't right? So please understand why we use XP.
> >>
> >> Windows XP SP3 supports SHA-256. And of course, you always have the
> >> option of Linux, which is a free modern operating system.
> >>
> >> Gerv
> > 
> > There are a lot of software whose company is already down running at 
> > factoies, critical public infrastructures even hospital. We can't take the 
> > risk to upgrade the operating system. But I am not supporting continous 
> > using of SHA1 certificates. Maybe you can understand this. :)
> 
> *Not* upgrading the operating system is a security risk. If you need to
> interact with certificates, your computer is networked. If your computer
> is networked, you absolutely cannot afford *not* to keep it up to date
> and using a supported operating system. Anything else is asking to get
> compromised, and then certificates are going to be the least of your
> worries.
> 
> The "install it once and don't touch it" mentality stops working the
> moment there's an Ethernet port with a cable connected to it. I would
> hope networked equipment at critical public infrastructure like a
> hospital is using a supported, updated operating system and software.
> 
> -- 
> Hector Martin "marcan" (mar...@marcan.st)
> Public Key: https://mrcn.st/pub

Yes, I totally agree with you.But some software can't work under newer system. 
Maybe we can find a solution towards this.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: WoSign and StartCom

[Han Yuwei]

在 2016年9月27日星期二 UTC+8下午8:33:28，Gervase Markham写道：
> On 27/09/16 13:13, adroidm...@gmail.com wrote:
> > We must use Windows XP becuase some programs can only run on XP. We
> > have no money to get new programs and new Windows. Do you give $$$￥￥￥
> > to me??? You don't right? So please understand why we use XP.
> 
> Windows XP SP3 supports SHA-256. And of course, you always have the
> option of Linux, which is a free modern operating system.
> 
> Gerv

There are a lot of software whose company is already down running at factoies, 
critical public infrastructures even hospital. We can't take the risk to 
upgrade the operating system. But I am not supporting continous using of SHA1 
certificates. Maybe you can understand this. :)
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: WoSign and StartCom

[Han Yuwei]

在 2016年9月26日星期一 UTC+8下午10:21:13，Gervase Markham写道：
> Today, Mozilla is publishing an additional document containing further
> research into the back-dating of SHA-1 certificates, in violation of the
> CAB Forum Baseline Requirements, to avoid browser blocks. It also
> contains some conclusions we have drawn from the recent investigations,
> and a proposal for discussion regarding the action that Mozilla's root
> program should take in response.
> 
> Because this document is extensive and contains embedded images, links
> and formatting, I have published it on Google Docs instead of as an
> email message here:
> 
> https://docs.google.com/document/d/1C6BlmbeQfn4a9zydVi2UvjBGv6szuSB4sMYUcVrR8vQ/edit
> 
> However, this forum is the appropriate place for discussing it. Please
> feel free to cut and paste any parts you wish to quote and comment on.
> 
> Gerv

Seems like we are not able to get a free 1-year certificate. I am very 
disappointed about that.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Maybe Mozilla can work with Chinese CAs to urge Chinese government to open up its internet a bit more?

[Han Yuwei]

在 2016年9月20日星期二 UTC+8上午12:54:48，nfji...@gmail.com写道：
> As you might have already known, most of Google services are blocked within 
> China, including this very forum.
> 
> I'm not sure how a fair and just assessment of a CA, that primarily serves 
> the Chinese market, can be had without any participation from any of its 
> users.
> 
> Having equal right for the Chinese citizen to participate in the discussion 
> of this technical matter not only benefits Mozilla, as more evidence of the 
> technical strength of a CA can be presented, but also gives credibility and 
> value to a Chinese CA, since a right process can be had by giving its users a 
> way to audit its behavior.
> 
> Without a participation from the Chinese citizens, this supposedly free 
> discussion group seems more like a privileged club, where only those who are 
> either outside of China or have a VPN can join.
> 
> I look forward for Mozilla and CA organizations to work to build a better 
> internet for everyone, by urging the Chinese government to stop censoring the 
> internet, starting from this forum.

You can join discussions by mailing-list
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Incidents involving the CA WoSign

[Han Yuwei]

在 2016年9月16日星期五 UTC+8下午6:07:56，Richard Wang写道：
> Hi Gerv,
> 
> This is the final report: 
> https://www.wosign.com/report/WoSign_Incident_Final_Report_09162016.pdf 
> 
> Please let me if you have any questions about the report, thanks.
> 
> 
> Best Regards,
> 
> Richard Wang
> CEO
> WoSign CA Limited
> 
> 
> -Original Message-
> From: Gervase Markham  
> Sent: Wednesday, September 7, 2016 7:00 PM
> To: Richard Wang; mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: Incidents involving the CA WoSign
> 
> Hi Richard,
> 
> On 07/09/16 11:06, Richard Wang wrote:
> > This discuss has been lasting two weeks, I think it is time to end it, 
> > it doesn’t worth to waste everybody’s precious time.
> 
> Unfortunately, I think we may be only beginning.
> 
> I have prepared a list of the issues we are tracking with WoSign's 
> certificate issuance process and business:
> 
> https://wiki.mozilla.org/CA:WoSign_Issues 
> 
> Please can you provide a response to issues F, P, S and T at your earliest 
> convenience?
> 
> In addition, if you have further things to say about issues D, H, J, L, N or 
> V we would be happy to hear them.
> 
> Thank you for your suggestions, but once Mozilla has a full understanding of 
> what has gone on we will be in a better position to decide what next actions 
> are appropriate.
> 
> With best wishes,
> 
> Gerv

About mis-issued alicdn.com and github.com, is the whitelist a acceptable 
solution? I thought it is a serve problem that possible hijacks on CA's 
validation host to the server. Lots of vulnerablity could be used by hackers 
such as DNS poisoning and TCP hijacks. This time the alicdn noticed this 
problem because it is a big company. If this happened to a relatively small 
company can we notice this in time? I am very doubt about that. Anything we can 
do to prevent this from happening?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Cerificate Concern about Cloudflare's DNS

[Han Yuwei]

在 2016年9月13日星期二 UTC+8上午8:07:31，Matt Palmer写道：
> On Mon, Sep 12, 2016 at 08:57:29PM +0100, Rob Stradling wrote:
> > On 12/09/16 18:57, Jakob Bohm wrote:
> > > On 11/09/2016 07:49, Peter Bowen wrote:
> > >> On Sat, Sep 10, 2016 at 10:40 PM, Han Yuwei <hanyuwe...@gmail.com> wrote:
> > >>> So when I delegated the DNS service to Cloudflare, Cloudflare have
> > >>> the privilege to issue the certificate by default? Can I understand
> > >>> like that?
> > >>
> > >> I would guess that they have a clause in their terms of service or
> > >> customer agreement that says they can update records in the DNS zone
> > >> and/or calls out that the subscriber consents to them getting a
> > >> certificate for any domain name hosted on CloudFlare DNS.
> > > 
> > > This seems another reason for the web to not trust cloudflare as a
> > > trustworthy domain proxy handler.
> > > 
> > > Just because their (paid, presumably) job gives them the technical
> > > ability to requests certificates without the consent of the domain
> > > owner, this does not given them any legitimate right to do so.
> > 
> > Hi Jakob.  Do you find any fault with Comodo for issuing this cert
> > (https://crt.sh/?id=31206531) ?
> > 
> > We validated domain control, but we did not attempt to establish "the
> > consent of the domain owner"(s) directly.  As others have pointed out,
> > this is compliant with the CABForum BRs.
> 
> Are you able, by any chance, to reveal whether the domain control was
> validated by HTTP request, DNS change, or "other" (please specify )? 
> At present, it looks like every domain listed in that certificate *other*
> than the domain at issue (bupt.moe) resolves to Cloudflare IP space, so my
> working theory is that the domain was previously pointed to a Cloudflare
> proxy, and has since been moved elsewhere.
> 
> However, it would be nice, for my peace of mind at least, to know how
> control was validated in this instance, if that's something you're able to
> share (I understand you reasonably might not be able, and if so, no
> problem).
> 
> If Cloudflare *was*, in fact, obtaining certificates on behalf of all its
> DNS-using (only) customers on the "off chance" that they might want to use
> their proxy services in the future, that would be extremely creepy and
> unpleasant, but so far I don't think there's enough evidence to be able to
> say such a thing is happening at present.  It seems far more likely that
> bupt.moe was a Cloudflare proxy customer (if only for a *very* brief time),
> the certificate was issued for that purpose, and now the domain has been
> pointed elsewhere, and the name is just hanging around in a cert which will
> expire in six months or so.
> 
> - Matt

I am the owner of BUPT.MOE and I just use DNS service.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: WoSign’s Ownership of StartCom

[Han Yuwei]

在 2016年9月9日星期五 UTC+8下午5:49:07，Gervase Markham写道：
> Dear m.d.s.policy,
> 
> We have been actively investigating reports that WoSign and StartCom may
> have failed to comply with our policy on change of control notification.
> Below is a summary representing the best of our knowledge and belief,
> based on our findings and investigation to date.
> 
> The operations of the CA known as StartCom have historically been owned
> and controlled by an Israeli company, number 513747303, called "סטארט
> קומארשל בע”מ", or in English "Start Commercial Ltd". This company will
> be referred to in this document as "StartCom IL". It has normally been
> represented in public and the CAB Forum by its COO/CTO, Eddy Nigg.
> 
> On August 5th, 2015 a new company, "StartCom CA Ltd", was created in
> Hong Kong.[0] This company will be referred to in this document as
> "StartCom HK".
> 
> On August 21st, 2015 a new company, also called "StartCom CA Ltd", was
> created in the UK.[1] This company will be referred to in this document
> as "StartCom UK".
> 
> 100% of the shares of “StartCom CA Ltd” in the UK are listed as being
> owned by "StartCom CA Ltd".[2] This seems circular, but our
> understanding is it actually refers to StartCom HK, which has the same
> name. StartCom UK is documented as having two directors. One is Gaohua
> (Richard) Wang, who will be known to you all as he represents WoSign in
> this forum and at the CAB Forum. The other, appointed last month, is
> Iñigo Barreira, formerly of the CA Izenpe and now of StartCom.
> 
> StartCom HK's 100% ownership appears to give it total control over
> StartCom UK, including the ability to hire and fire directors at will,
> due to a special clause (#73) in the company formation documents.[3]
> 
> StartCom HK's Company Registration Number (CRN) is 2271553, which can be
> looked up at the Cyber Search Centre of the Integrated Companies
> Registry Information System[4] in Hong Kong. There is a requirement for
> registration and a small payment, but the relevant documents have been
> provided by Mozilla. These documents show that:
> 
> * StartCom HK’s documents list only one director, Gaohua (Richard) Wang.[5]
> 
> * StartCom HK’s documents appear to show it is 100% owned (10,000
> shares) by “WoSign CA Limited”.[6]
> 
> We understand that on or around the 1st of November 2015, ownership of
> all of the shares in StartCom IL was transferred from 15 different
> shareholders (including the majority shareholder, named Revital Nigg) to
> the recently-formed StartCom UK.[7] At around the same time, Gaohua
> (Richard) Wang became the sole director of StartCom IL.[8] Details of
> these changes can be looked up at the appropriate Israeli governmental
> department. They require a payment, but are public records, and the
> relevant documents have been provided by Mozilla.
> 
> So to summarise our understanding: as of today, StartCom IL (sole
> director: Richard Wang) is 100% owned by StartCom UK (two directors:
> Richard Wang and Iñigo Barreira), which is 100% owned by StartCom HK
> (sole director: Richard Wang), which is 100% owned by the CA WoSign
> (CEO: Richard Wang).
> 
> It is important to note that there is nothing confidential about any of
> the above and none of what is described is illegal. Company ownership
> information in these jurisdictions is public information. CAs have been
> bought and sold in the past. However, the following aspects of the
> situation are problematic:
> 
> A) Mozilla's CA policy has a requirement that:
> 
> "We require that all CAs whose certificates are distributed with our
> software products notify us... when the ownership control of the CA’s
> certificate(s) changes, or when ownership control of the CA’s operations
> changes."[9]
> 
> It seems clear to us from the above account that, if our understanding
> is correct, this transaction fits this requirement - ownership control
> of the CA's operations has changed, and StartCom is now wholly owned and
> controlled by WoSign. However, the change in ownership was not reported
> to Mozilla.
> 
> B) When questioned, representatives of StartCom and WoSign have
> specifically denied that anything had happened which needed to be
> reported to Mozilla, even when this particular clause of the policy was
> drawn to their attention.
> 
> On 23rd February 2016, Richard Wang wrote: “no ‘Change in legal
> ownership’ in StartCom.”[10]
> 
> On 24th February 2016, Richard Wang wrote: “[StartCom UK] is one of the
> shareholder of [StartCom IL].”[10]
> 
> On 27th February 2016, Eddy Nigg characterised the relationship as
> follows: “StartCom owns its own roots obviously, operates as usual in
> Israel. ... We have a long-standing business relationship and
> cooperation with WoSign which keeps growing.”[10]
> 
> On 2nd September 2016, Richard Wang wrote: “Please don't bind WoSign
> incident problem with StartCom, it is two independent company that one
> registered in China and one located in Israel.”[11]
> 
> C) Though 

Re: Cerificate Concern about Cloudflare's DNS

[Han Yuwei]

在 2016年9月10日星期六 UTC+8下午10:44:05，Erwann Abalea写道：
> Bonjour,
> 
> Le samedi 10 septembre 2016 14:37:40 UTC+2, Han Yuwei a écrit :
> > I am using Cloudflare's DNS service and I found that Cloudflare has issued 
> > a certficate to their server including my domain. But I didn't use any SSL 
> > service of theirs. Is that ok to Mozilla's policy?
> > 
> > Issued certificate:https://crt.sh/?id=31206531
> > My domain is BUPT.MOE
> 
> Technically speaking, Cloudflare did not issue a certificate, they requested 
> one and have it been issued by a CA.
> 
> I won't say wether it's ok for Mozilla or not, but it's at least authorized 
> by the CABForum Baseline Requirements.
> 
> Cloudflare was the Applicant (it's now the Subscriber), Comodo is the CA, you 
> are the Domain Name Registrant, your Registrar appears to be Hosting Concept 
> (Openprovider), the requested FQDN is bupt.moe.
> 
> The Applicant requested a certificate for the FQDN to the CA, the CA has 
> several methods declared in its CPS to verify that the Applicant is 
> authorized by the Domain Name Registrant to control the FQDN.
> 
> Of all these methods, some of them won't work here without your knowledge 
> (phone-call, sending you an email as listed in the Whois, sending an email to 
> admin/administrator/webmaster/hostmaster/postmaster@yourdomain).
> One of the remaining methods may have been possible only if Cloudflare 
> redirected the DNS record of your FQDN to one of their servers just for the 
> verification to pass ("Having the Applicant demonstrate practical control 
> over the FQDN by making an agreed‐upon change to information found on an 
> online Web page identified by a uniform resource identifier containing the 
> FQDN"), which could be considered problematic.
> In my opinion, the most plausible verification method in this case is the 
> last one: "Having the Applicant demonstrate practical control over the FQDN 
> by making an agreed-upon change to information found in the DNS containing 
> the FQDN"; for example asking the Applicant to add a CA-chosen random value 
> in a TXT record of the FQDN.
> 
> Since you delegated your DNS server to Cloudflare, you implicitly allowed 
> them to perform this certificate request on your behalf.
> 
> 
> Ironically, since you're not the Subscriber, you cannot request for the 
> revocation of this certificate, at least not directly to the CA. If you want 
> this certificate to be revoked, you need to ask Cloudflare.

Thanks for your time.

So when I delegated the DNS service to Cloudflare, Cloudflare have the 
priviliage to issue the certficate by default? Can I understand like that?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Cerificate Concern about Cloudflare's DNS

[Han Yuwei]

I am using Cloudflare's DNS service and I found that Cloudflare has issued a 
certficate to their server including my domain. But I didn't use any SSL 
service of theirs. Is that ok to Mozilla's policy?

Issued certificate:https://crt.sh/?id=31206531
My domain is BUPT.MOE
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Security concern on various domain validating methods

[Han Yuwei]

I raise this question because of the Wosign's incident about high port 
validating. Many CA use email validating such as send a email to 
webmas...@foo.bar, or put a specific file into the root of website.
What I think is that this cannot validate *domain* is yours.  It just verified 
you have the mail server or you control the host. The best way to prove you own 
a domain is to change the DNS records of the domain.
So I suggest to change domain validating method to verify DNS records. Is that 
feel better?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy