Re: sanctions short of distrust

[John Nagle]

   It would be useful to try out some of these
ideas in a Firefox add-on.  But it seems that although
Mozilla supports three add-on APIs (XPI, Jetpack, and
a subset of Google Web Extensions), none of them allow
reading the certificate of the current page.

   That's a lack. It prevents writing add-ons to
deal with some of these problems.

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

Re: Sanctions short of distrust

[Matt Palmer]

On Thu, Sep 08, 2016 at 09:44:04AM -0700, Ryan Sleevi wrote:
> On Thursday, September 8, 2016 at 4:09:25 AM UTC-7, Rob Stradling wrote:
> > >  1. Enforce CT only after a certain date, after which WoSign will need
> > > to embed qualified SCTs. This check can be bypassed if the CA
> > > backdates certificates (which is problematic, given the history of
> > > backdating certificates in this particular case.)
> > 
> > AIUI, Chrome doesn't currently consider the difference between the
> > certificate's notBefore date and the corresponding SCTs' timestamps when
> > evaluating whether or not the certificate is "CT qualified".
> > 
> > To guard against backdating, ISTM that future versions of Chrome (and
> > hopefully Firefox too) could require, for certain CAs, that:
> >   1. The certificate MUST be "CT qualified".
> >   and
> >   2. In addition to the standard requirements for being "CT qualified",
> > the SCT timestamps MUST be within N seconds of the certificate's
> > notBefore date.
> 
> Without wanting to derail this thread with discussions of Chrome's CT
> implementations, to the point it's relevant to a Firefox implementation,
> this is something better as part of the monitoring ecosystem (and with a
> CA/B Forum Guideline) than as a client enforcement.

I read Rob's proposal as one specifically for CAs under some sort of
"quintuple secret probation" arrangement, where there has been a history of
shenanigans with notBefore dates.  In that circumstance, as a proactive
enforcement mechanism, it makes a certain degree of sense.  Post-hoc
detection through CT logs is without value for such CAs; the reason they're
on probation is because they've got too many customers to just pull the
root and ship a valid certs whitelist, so if further shenanigans is detected
via CT, what recourse is there available?  Revocation is off the table,
because it's under the CA's control, and we've seen recent examples of
revocation equivocation from CAs.

Therefore, proactive enforcement of standards on a cert-by-cert basis is,
as far as I can tell, about all there is left.  Do you see things
differently?

- Matt

___
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

[Jakob Bohm]

On 07/09/2016 16:01, Thijs Alkemade wrote:

On 07 Sep 2016, at 14:52, Rob Stradling  wrote:


On 06/09/16 19:12, Thijs Alkemade wrote:


Hello,

We obtained 2 certificates from the StartEncrypt API which had SHA-1 signatures 
and which were backdated to December 20, 2015.

After WoSign announced that all certificates issued in 2015 were logged to 
their Certificate Transparency server, I analyzed them to check if any other 
certificates using SHA-1 signatures show signs of being backdated. Using the 
Python tools from Google’s Certificate Transparency repository I downloaded all 
certificates from the log and then queried them from an sqlite database. 
Considering this is the first time I’m working with Certificate Transparency 
logs, it might be better if someone else tries to reproduce my results. I’ve 
generated a table here: 
https://gist.github.com/anonymous/72920ff1b4450d38893dfa1b4863af52 (timestamps 
are in UTC).

I found 1204 certificates with a SHA-1 signature issued after December 1, 2015. 
53 of them included embedded SCT data, so can be dated more accurately.

The most interesting pattern I noticed was from sorting the certificates based 
on the ID they have in WoSign’s Certificate Transparency log. Up to ID 109149 
(https://crt.sh/?q=6d8665951cf6d8743200393a1085e0f6eb226270cc1f1402507d61faae93256a),
 the notBefore values are (approximately) chronologically ordered. Those which 
have embedded SCTs have timestamps which are about 2 hours later than the 
notBefore date.


Hi Thijs.  I agree that this pattern is interesting (and it'd be nice to
see an explanation), but I'm not convinced that it proves everything you
think it proves.


But after that follow 64 certificates which are all dated on December 20, 2015 
(CST, UTC+8), including our two test certificates. Six of these have embedded 
SCT data, but they have a large discrepancy between the notBefore and the 
earliest SCT: 3 have a SCT of December 31 (11 days later) and 1 even has a SCT 
of January 18, 2016, almost a full month after the notBefore. (Unless I 
misunderstand the use of pre-certificates, this by itself already implies the 
certificate was signed using SHA-1 on or after January 18, 2016.)


Yes.  A certificate that has embedded SCTs cannot have been issued any
earlier than any of the timestamps in those embedded SCTs (assuming
those timestamps are accurate, of course).

Of course, "implies...was signed...after" is only demonstrably true when
you have a copy of both the precertificate and the corresponding
certificate.  You can't prove it if you only have a copy of the
precertificate; the signature on a precertificate "indicates the
certificate authority's intent to issue a certificate" [RFC6962 section
3.1], but this doesn't mean the CA is required to issue the certificate.


Hi Rob,

That makes sense, thanks.


Aside from the 3 embedded SCTs on December 31, none of these certificates have 
been logged to a Certificate Transparency server before January 1, 2016.


When a precertificate is logged, there is no need for the corresponding
certificate to be logged.  If the corresponding certificate does get
logged at some point later, so what?
Let's look at one of your examples:
aceeccdbb17b9096251dd11a84041ec75fe7a92e903ffe07c6d6b0a0c980d399
The fact that the certificate (https://crt.sh/?id=12367098) wasn't
logged until late January 2016 is uninteresting, because the
precertificate (https://crt.sh/?id=11751158) was logged on (and has a
notBefore date of) 31st December 2015.

Except for EV, certificates issued by WoSign aren't required (by Chrome)
to be logged.  If a certificate (for which there is no corresponding
precertificate) does get logged at some point long after its issuance
date, so what?
Let's look at one of your examples:
61b6289b1d3786e8f362e4049a4c5e24bb1356c0776fadb3a8a569f99d071a98
I see no evidence to suggest that this certificate was not issued on
30th December 2015, as suggested by its notBefore date.


Both of these are not examples of the certificates which I consider suspicious. 
To be precise, the suspicious certificates have:

- A SHA-1 signature from WoSign.
- A notBefore date on December 20, 2015 (CST).
- An ID in the WoSign Certificate Transparency log ≥ 109153.

In the gist which I posted, this is line 4 up to 65.

The fact that these certificates weren’t logged to public Certificate 
Transparency servers soon after is not suspicious and I did not intend it as 
such. It was only meant to indicate the lack of evidence that could have proven 
their timestamps.

What is suspicious is:

- Twice as many SHA-1 certificates being issued on a specific Sunday in 
December than the daily average that month. (Which also happens to be the date 
on the certificates which I personally got from the StartEncrypt API.)
- The long difference between the notBefore and the embedded SCTs, if any.
- Some of these certificates having an almost identical copy issued using 
SHA-256 on a date in January. 

Re: Amazon Root Inclusion Request

[Kathleen Wilson]

On Thursday, August 25, 2016 at 2:37:43 PM UTC-7, Kathleen Wilson wrote:
> Does anyone else have questions, comments, or concerns about this request?
> If not, then I will proceed with recommending approval.


Thanks again to those of you who participated in this discussion about Amazon 
Trust Services' request to include 4 new Amazon root certs, turn on the Email 
and Websites trust bits, and enable EV treatment for them. This request is also 
to enable EV treatment for the “Starfield Services Root Certificate Authority - 
G2" certificate.

I am now closing this discussion and will recommend approval in the bug.

https://bugzilla.mozilla.org/show_bug.cgi?id=1172401

Any further follow-up on this request should be added directly to the bug.

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

Re: Security concern on various domain validating methods

[Ryan Sleevi]

On Thursday, September 8, 2016 at 9:00:15 AM UTC-7, Stephen Schrauger wrote:
 > It proves you control the web server that runs under the domain. Which is 
 > more or less all that you need to prove, since a TLS certificate is designed 
 > for web security. 
> 
> If you don't control DNS, but you do control the web server, you essentially 
> control the domain as far as web browsing goes, and thus you should be able 
> to acquire a certificate for that domain. Which is probably why it is 
> included in the Baseline Requirements as an acceptable validation method.

Just a slight correction: TLS is not only used for HTTPS. We certainly know 
it's used for other protocols - such as IMAPS and POPS - and we know that a 
given service may be colocated with other services on the same host. At 
present, a TLS certificate doesn't distinguish the intended or authorized 
services (there's a SRVName ballot circulating in the Forum that could resolve 
this), but I think recent events have shown the issues where control of a 
single service might be elevated to presumptive control of the domain, which 
can and, in the case of mail providers, frequently is, inaccurate.

That is, consider the example of StartCom and WoSign including 'base domains' 
within the certificate (both authorized and unauthorized), where a certificate 
for 'mail.example.com' would include a SAN of 'example.com'. Just because I can 
demonstrate operational control of 'mail.example.com' (for example, if 
mail.example.com was actually run by GMail) doesn't imply authorization of 
'example.com'.

This is, perhaps, a convoluted example, but it's meant to highlight why, for 
the methods of control that don't directly rely upon DNS, the intended 
authorization scope in the new validation methods is limited to the FQDN of 
that host (e.g. the cert could only contain mail.example.com), which was 
already a requirement in previous versions, but made more explicit in the 
latest versions. However, control of the web portion of mail.example.com 
doesn't imply control of the email portion, and that's where the SRVName ballot 
fits.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Sanctions short of distrust

[Ryan Sleevi]

On Thursday, September 8, 2016 at 4:09:25 AM UTC-7, Rob Stradling wrote:
> >  1. Enforce CT only after a certain date, after which WoSign will need
> > to embed qualified SCTs. This check can be bypassed if the CA
> > backdates certificates (which is problematic, given the history of
> > backdating certificates in this particular case.)
> 
> AIUI, Chrome doesn't currently consider the difference between the
> certificate's notBefore date and the corresponding SCTs' timestamps when
> evaluating whether or not the certificate is "CT qualified".
> 
> To guard against backdating, ISTM that future versions of Chrome (and
> hopefully Firefox too) could require, for certain CAs, that:
>   1. The certificate MUST be "CT qualified".
>   and
>   2. In addition to the standard requirements for being "CT qualified",
> the SCT timestamps MUST be within N seconds of the certificate's
> notBefore date.

Without wanting to derail this thread with discussions of Chrome's CT 
implementations, to the point it's relevant to a Firefox implementation, this 
is something better as part of the monitoring ecosystem (and with a CA/B Forum 
Guideline) than as a client enforcement. 

For pre-certificates: The earliest (trusted) SCT represents a reasonable 
lower-bound of the issuance date, for purposes of policy. That is, for 
certificates issued with embedded SCTs, any policy controls can be applied on 
the basis of the embedded SCT, if present.

However, for SCTs delivered via OCSP or TLS extensions, there is zero 
relationship between the notBefore and any SCTs. This is because the set of 
SCTs delivered with a certificate - or the logs in which a certificate is 
logged - may change over a certificate's lifetime, as part of the normal 
operation of trusting and distrusting logs.

Consider a hypothetical situation, possible today, in which a certificate is 
logged to two logs (Google Pilot and DigiCert). These are the only logs the 
certificate is logged in, and the cert is logged within a few hours of 
issuance, and SCTs delivered via OCSP. Now, let's imagine that the Pilot log is 
distrusted one year into the cert's 3 year lifetime. In order to comply with 
Chrome's policy (and what Chrome believes is a good guideline for other UAs, at 
least at present), the cert would need to be logged to Google's Aviator or 
Rocketeer logs, which have as-of-yet never seen the certificate. When the CA 
does so, the SCT will be issued at least 1y > the cert's notBefore, and then 
embedded in the OCSP response (such that the new set is Aviator, DigiCert). 
Now, imagine that 2y into the cert's lifetime, DigiCert's log is distrusted, 
and so the cert is then logged to Symantec's log. Now, the SCT set is Aviator, 
Symantec, and the SCTs are respectively 1y and 2y newer than the cer
 t. This is not proof of backdating.

While the above example is, arguably, convoluted, and ignores the ways in which 
a log may and has been distrusted (e.g. 'freezing' a log at a particular 
timestamp, as has been done so far for the operational failures that have 
caused log distrust), it's meant to highlight that the assumption and design of 
CT don't require a relationship between the notBefore and the SCT validity 
period of the date.

Obviously, for pre-certificates, the act of backdating can be trivially 
detected, since it's cryptographically guaranteed that the cert cannot have 
been issued earlier than the latest SCT embedded within it (assuming the log's 
clock is functioning correctly), but this doesn't apply to other SCT delivery 
mechanisms, and this is arguably by design.

Among other reasons, I believe this is why the client complexity is not worth 
it, but that this can and should be addressed through a combination of explicit 
policy actions (within Mozilla policy) and within the Baseline Requirements, 
and there are many ways in which we can further an auditable criteria to ensure 
this, and in a programatically detectable way, without foisting this upon 
clients to enforce.
___
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

[Richard Wang]

Your top 10 or top 5 is not same as my top 10 or top 5.
BTW, 
Dangdang.com is using our certificate: 
https://www.ssllabs.com/ssltest/analyze.html?d=login.dangdang.com

Some is also using our certificate that you don't know.


Regards,

Richard

> On 8 Sep 2016, at 23:59, Ming  wrote:
> 
> 在 2016年9月7日星期三 UTC+8下午6:08:33，Richard Wang写道：
>> Hi Gerv, Kathleen and Richard,
>> 
>> 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.
>> I make my confession that our system and management do have some problems 
>> which lead to the misissuance of some certificates. And I am very sorry that 
>> WoSign don’t notify all browsers after the incident happened and even after 
>> the problem fixed.
>> 
>> I’d like to give my suggestion action for Mozilla as below:
>> 1. Mozilla will trust those SSL certificates only:
>>(1) The certificate notBefore date is before Jan. 1st 2015;
>>(2) The certificate notBefore date is from Jan. 1st 2015 to July 4th 2016 
>> that listed in the Google CT log server;
>>(3) The certificate notBefore date is from July 5th 2016 to Sept xx 2016 
>> that embedded SCT data in the certificate;
>>(4) The certificate notBefore date is from Sept xx 2016 that embedded SCT 
>> data in the certificate and must have the “C=CN” in the certificate subject.
>> 
>> 2. Mozilla can assign a WebTrust auditor to WoSign office to check and 
>> inspect every incident, check every relevant issued certificate, and record 
>> a report with:  what happened, why this happened and what is being done to 
>> prevent this in the future etc., WoSign will pay the audit cost.
>> 
>> I’d like to make some supplements about 1. (4) above, this term means WoSign 
>> will only issue SSL certificates to China subscribers. 
>> WoSign issued about 120K SSL certificates for websites in China including 
>> many central government websites like MIIT and many other local province 
>> government websites, many university websites, many online banking websites, 
>> 6 of the Top 10 ecommerce websites, big supermarket online store like 
>> Walmart, 4 of the Top 5 cloud service in China, and many big companies that 
>> listed in NYSE and Nasdaq, and many subsidiaries of foreign countries big 
>> companies.
> 
> Richard,I check the  top 10 e-commerce websites in China, ONLY suning.com and 
> yhd.com are your subscribers; and ZERO of the top 5 cloud service companies 
> in China use WoSign.
> 
> I have reason to doubt the authenticity of the data you provided. 
> 
> there is the top 10 e-commerce websites in China:
> taobao.com
> jd.com
> tmall.com
> amazon.cn
> vip.com
> meituan.com
> suning.com
> dangdang.com
> jumei.com
> yhd.com
> 
> the top 5 cloud service companies in China:
> aliyun.com
> qcloud.com
> qingcloud.com
> ucloud.cn
> hwclouds.com
> 
> 
>> Those customers like to use WoSign certificate especially our support of 
>> Chinese, local support and customer service. And some of them paid up to 
>> 10-year certificate fee in advance, we need to renew their certificate for 
>> free once it is about to expire at every three years for OV SSL.
>> 
>> I wish Mozilla could accept my suggestion, and I am sure WoSign will do it 
>> better after getting this so big lesson. 
>> Thank you.
>> 
>> 
>> Best Regards,
>> 
>> Richard Wang
>> CEO
>> WoSign CA Limited
>> 
>> 
>> -Original Message-
>> From: dev-security-policy 
>> [mailto:dev-security-policy-bounces+richard=wosign@lists.mozilla.org] On 
>> Behalf Of Richard Wang
>> Sent: Sunday, September 4, 2016 5:49 PM
>> To: Gervase Markham ; 
>> mozilla-dev-security-pol...@lists.mozilla.org
>> Subject: RE: Incidents involving the CA WoSign
>> 
>> Hi all,
>> 
>> We finished the investigation and released the incidents report today: 
>> https://www.wosign.com/report/wosign_incidents_report_09042016.pdf 
>> 
>> This report has 20 pages, please let me if you still have any questions, 
>> thanks.
>> 
>> This report is just for Incident 0-2, we will release a separate report for 
>> another incident X soon.
>> 
>> 
>> Best Regards,
>> 
>> Richard Wang
>> CEO
>> WoSign CA Limited
>> 
>> 
>> -Original Message-
>> From: Gervase Markham [mailto:g...@mozilla.org] 
>> Sent: Wednesday, August 24, 2016 9:08 PM
>> To: mozilla-dev-security-pol...@lists.mozilla.org
>> Cc: Richard Wang 
>> Subject: Incidents involving the CA WoSign
>> 
>> Dear m.d.s.policy,
>> 
>> Several incidents have come to our attention involving the CA "WoSign".
>> Mozilla is considering what action it should take in response to these 
>> incidents. This email sets out our understanding of the situation.
>> 
>> Before we begin, we note that Section 1 of the Mozilla CA Certificate 
>> Enforcement Policy[0] says: "When a serious security concern is noticed, 
>> such as a major root compromise, it should be treated as a 
>> security-sensitive bug, and the Mozilla Policy for 

Re: Second Discussion of LuxTrust Root Inclusion Request

[Kathleen Wilson]

On Thursday, August 4, 2016 at 10:51:58 AM UTC-7, Kathleen Wilson wrote:
> 
> The CA has resolved the questions and concerns raised during the first 
> discussion, and has provided an updated root certificate with corresponding 
> updated documentation and audit statement.
> 
> Please review this request from LuxTrust to include the "LuxTrust Global Root 
> 2" certificate, turn on the Websites trust bit, and enable EV treatment.
> 
> The request is documented in the following bug:
> https://bugzilla.mozilla.org/show_bug.cgi?id=944783
> 
> Summary of Information Gathered and Verified:
> https://bugzilla.mozilla.org/attachment.cgi?id=8777892
> 
> This root signs internally-operated subordinate CAs that issue SSL and code 
> signing certificates.
> 
> Documents are in French and English.
> CA Document Repository: https://repository.luxtrust.lu
> CP: 
> https://www.luxtrust.lu/upload/data/repository/LuxTrust%20Global%20Root%20CA%20-%20Certificate%20Profiles%20v1%2022.pdf
> CPS: 
> https://www.luxtrust.lu/upload/data/repository/LuxTrust_Global_Root%20CA_Certification_Practice_Statements_v1_09.pdf
> SSL CPS:  SSL CPS: 
> https://www.luxtrust.lu/upload/data/repository/LuxTrust%20SSL%20CA%20CPS%20v1.3.pdf
>   
> SSL CPS section 3.2.2: In the particular case of SSL, RAs operating under the 
> LuxTrust SSL CA shall determine whether the domain referenced in the SSL 
> Certificate application is owned and controlled by the subscriber.
> LuxTrust validates that the Subscriber has the right to control the domain 
> names using the following verification procedures:
> [1] Communicating with the technical contact information provided by the 
> Subscriber in the order form.
> [2] Communicating directly with the Domain Name Registrant using the contact 
> information listed in the WHOIS record’s “registrant”, “technical”, or 
> “administrative” field;
> [3] Relying upon a Domain Authorization Document which contains the signature 
> of an authorized representative of the domain holder, a date that is on or 
> after the certificate request and a statement confirming the Subscriber’s 
> control over the domain names in the certificate. LuxTrust also relies on a 
> reliable third-party, the Chamber of Commerce of Luxembourg, to confirm the 
> authenticity of the Domain Authorization Document.
> 
> Root Certificate Download URL:
> https://ca.luxtrust.lu/LTGRCA2.crt
> 
> Test Website: https://ltsslca5.trustme.lu/
> 
> EV Policy OID: 1.3.171.1.1.10.5.2
> 
> CRL:
> http://crl.luxtrust.lu/LTGRCA2.crl
> http://crl.luxtrust.lu/LTSSLCA5.crl
> SSL CPS section 4.9.7: A CRL is issued each 4 hours, at an agreed time.
> 
> OCSP:
> http://ssl.ocsp.luxtrust.lu
> http://ltgroot.ocsp.luxtrust.lu
> 
> Annual audits are performed by LSTI, according to the ETSI TS 102 042 
> criteria.
> Audit Statement: https://bugzilla.mozilla.org/attachment.cgi?id=8777887
> http://www.lsti-certification.fr/images/liste_entreprise/Liste%20PSCe.pdf
> 
> This continues the discussion of the request from LuxTrust to include the 
> "LuxTrust Global Root 2" certificate, turn on the Websites trust bit, and 
> enable EV treatment. At the conclusion of this discussion I will provide a 
> summary of issues noted and action items. If there are outstanding issues, 
> then additional discussion may be needed as follow-up. If there are no 
> outstanding issues, then I will recommend approval of this request in the bug.
> 
> Kathleen

Does anyone have comments, questions, or concerns about this request from 
LuxTrust to include the "LuxTrust Global Root 2" certificate, turn on the 
Websites trust bit, and enable EV treatment?

If not, I will close this discussion and recommend approval in the bug.

Thanks,
Kathleen



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

Re: Compromised certificate that the owner didn't wish to revoke (signed by GeoTrust)

[Jernej Simončič]

On Wed, 7 Sep 2016 03:55:02 -0700 (PDT), Nick Lamb wrote:

> If you DIY, the rate limits obviously aren't a problem, and lots of DIY 
> devices have Let's Encrypt issued certificates today. Home "routers" built 
> out of a Raspberry Pi or a Mini PC are fairly popular with hobbyists. So rate 
> limits (which exist for a perfectly sensible reason) are the only reason you 
> can't buy a device that does this off the shelf.

Wouldn't Let's Encrypt's 3-month certificate validity time also pose a
problem for such devices? I'm pretty sure I've bought routers that sat in
some warehouse far longer than 3 months in the past.

-- 
begin  .sig
< Jernej Simončič ><>◊<>< jernej|s-ng at eternallybored.org >
end
___
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

[Ming]

在 2016年9月7日星期三 UTC+8下午6:08:33，Richard Wang写道：
> Hi Gerv, Kathleen and Richard,
> 
> 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.
> I make my confession that our system and management do have some problems 
> which lead to the misissuance of some certificates. And I am very sorry that 
> WoSign don’t notify all browsers after the incident happened and even after 
> the problem fixed.
> 
> I’d like to give my suggestion action for Mozilla as below:
> 1. Mozilla will trust those SSL certificates only:
> (1) The certificate notBefore date is before Jan. 1st 2015;
> (2) The certificate notBefore date is from Jan. 1st 2015 to July 4th 2016 
> that listed in the Google CT log server;
> (3) The certificate notBefore date is from July 5th 2016 to Sept xx 2016 
> that embedded SCT data in the certificate;
> (4) The certificate notBefore date is from Sept xx 2016 that embedded SCT 
> data in the certificate and must have the “C=CN” in the certificate subject.
> 
> 2. Mozilla can assign a WebTrust auditor to WoSign office to check and 
> inspect every incident, check every relevant issued certificate, and record a 
> report with:  what happened, why this happened and what is being done to 
> prevent this in the future etc., WoSign will pay the audit cost.
> 
> I’d like to make some supplements about 1. (4) above, this term means WoSign 
> will only issue SSL certificates to China subscribers. 
> WoSign issued about 120K SSL certificates for websites in China including 
> many central government websites like MIIT and many other local province 
> government websites, many university websites, many online banking websites, 
> 6 of the Top 10 ecommerce websites, big supermarket online store like 
> Walmart, 4 of the Top 5 cloud service in China, and many big companies that 
> listed in NYSE and Nasdaq, and many subsidiaries of foreign countries big 
> companies. 

Richard,I check the  top 10 e-commerce websites in China, ONLY suning.com and 
yhd.com are your subscribers; and ZERO of the top 5 cloud service companies in 
China use WoSign.

I have reason to doubt the authenticity of the data you provided. 

there is the top 10 e-commerce websites in China:
taobao.com
jd.com
tmall.com
amazon.cn
vip.com
meituan.com
suning.com
dangdang.com
jumei.com
yhd.com

the top 5 cloud service companies in China:
aliyun.com
qcloud.com
qingcloud.com
ucloud.cn
hwclouds.com


> Those customers like to use WoSign certificate especially our support of 
> Chinese, local support and customer service. And some of them paid up to 
> 10-year certificate fee in advance, we need to renew their certificate for 
> free once it is about to expire at every three years for OV SSL.
> 
> I wish Mozilla could accept my suggestion, and I am sure WoSign will do it 
> better after getting this so big lesson. 
> Thank you.
> 
> 
> Best Regards,
> 
> Richard Wang
> CEO
> WoSign CA Limited
> 
> 
> -Original Message-
> From: dev-security-policy 
> [mailto:dev-security-policy-bounces+richard=wosign@lists.mozilla.org] On 
> Behalf Of Richard Wang
> Sent: Sunday, September 4, 2016 5:49 PM
> To: Gervase Markham ; 
> mozilla-dev-security-pol...@lists.mozilla.org
> Subject: RE: Incidents involving the CA WoSign
> 
> Hi all,
> 
> We finished the investigation and released the incidents report today: 
> https://www.wosign.com/report/wosign_incidents_report_09042016.pdf 
> 
> This report has 20 pages, please let me if you still have any questions, 
> thanks.
> 
> This report is just for Incident 0-2, we will release a separate report for 
> another incident X soon.
> 
> 
> Best Regards,
> 
> Richard Wang
> CEO
> WoSign CA Limited
> 
> 
> -Original Message-
> From: Gervase Markham [mailto:g...@mozilla.org] 
> Sent: Wednesday, August 24, 2016 9:08 PM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Cc: Richard Wang 
> Subject: Incidents involving the CA WoSign
> 
> Dear m.d.s.policy,
> 
> Several incidents have come to our attention involving the CA "WoSign".
> Mozilla is considering what action it should take in response to these 
> incidents. This email sets out our understanding of the situation.
> 
> Before we begin, we note that Section 1 of the Mozilla CA Certificate 
> Enforcement Policy[0] says: "When a serious security concern is noticed, such 
> as a major root compromise, it should be treated as a security-sensitive bug, 
> and the Mozilla Policy for Handling Security Bugs should be followed." It is 
> clear to us, and appears to be clear to other CAs based on their actions, 
> that misissuances where domain control checks have failed fall into the 
> category of "serious security concern".
> 
> Incident 0
> --
> 
> On or around April 23rd, 2015, WoSign's certificate issuance system for their 
> free certificates allowed the applicant to choose any port for validation. 
> Once validation had been 

Re: Incidents involving the CA WoSign

[Vincent Lynch]

On Wednesday, September 7, 2016 at 7:00:54 AM UTC-4, Gervase Markham wrote:
> 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

Richard,

When you provide additional details about Issue P, can you specifically comment 
on why two of the certificates were issued for 4 years (48 months)?

Section 6.3.2 of the BRs states "Subscriber Certificates issued after 1 April 
2015 MUST have a Validity Period no greater than 39 months."

That section DID allow for an exception to that 39 month maximum if the CA 
documents that the certificate is being used in a case that satisfies a set of 
5 requirements (too lengthy to provide here). If this was the case, this would 
have been allowable until 30 June 2016 and these certificates' validity period 
would not be a violation. 

Can you comment on if these certificates satisfied the exception? And if so, 
can you provide WoSign's documentation of this?

In my opinion, this is one of the more concerning violations because it may 
show that it is trivially easy for WoSign's issuance software to issue 
certificates that violate the BRs.

(My understanding is that these certificates qualify as a Subscriber 
Certificate, the fact that the subject CN = wosign.net is irrelevant.)

Citation:
https://wiki.mozilla.org/CA:WoSign_Issues#Issue_P:_Use_of_SM2_Algorithm_.28Nov_2015.29
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Security concern on various domain validating methods

[Stephen Schrauger]

Regarding the specific file verification method:

It proves you control the web server that runs under the domain. Which is more 
or less all that you need to prove, since a TLS certificate is designed for web 
security. 

If you don't control DNS, but you do control the web server, you essentially 
control the domain as far as web browsing goes, and thus you should be able to 
acquire a certificate for that domain. Which is probably why it is included in 
the Baseline Requirements as an acceptable validation method.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: (Optional) list of participants

[Gervase Markham]

On 08/09/16 14:21, Rob Stradling wrote:
> Hi Gerv.  mailman adds this footer to each message:

Only on the mailing list version of each message. So I, for example, who
read via NNTP, don't see them. Nevertheless, this is better than
nothing, so I've emailed the list moderators to ask them to make the change.

Gerv


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

Re: (Optional) list of participants

[Rob Stradling]

On 08/09/16 14:13, Gervase Markham wrote:
> On 07/09/16 00:17, Kirk Hall wrote:
>> Great idea, Gerv.  Question: How will we remember how/where to find the 
>> list?  (I never remember.)
> 
> Sorry, I don't have a good solution to that :-) I will try and remember
> to post it occasionally, and whenever a big discussion starts. Others
> may wish to get there before me on this.

Hi Gerv.  mailman adds this footer to each message:

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

A quick Google search suggests that it's possible to edit this message:
https://mail.python.org/pipermail/mailman-users/2003-November/032852.html

If it can be edited, how about you append a line to the footer that says
something like:
"Useful links: https://wiki.mozilla.org/DevSecurityPolicyUsefulLinks;

?

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

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

Re: (Optional) list of participants

[Gervase Markham]

On 07/09/16 00:17, Kirk Hall wrote:
> Great idea, Gerv.  Question: How will we remember how/where to find the list? 
>  (I never remember.)

Sorry, I don't have a good solution to that :-) I will try and remember
to post it occasionally, and whenever a big discussion starts. Others
may wish to get there before me on this.

Gerv

___
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

[Gervase Markham]

On 08/09/16 11:39, Rob Stradling wrote:
> Consider https://crt.sh/?id=30629293, for example.  Are you really
> suggesting that this was issued on 2nd September 2016 but backdated to
> 20th December 2015?

For simplicity, I've removed this section from Issue S. I think the
evidence related there stands alone without any log-number-related
inferences.

Gerv

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

Re: Sanctions short of distrust

[Rob Stradling]

On 02/09/16 21:04, Patrick Figel wrote:

> I believe there are two possible solutions if CT enforcement is what the
> community decides on:
> 
>  1. Enforce CT only after a certain date, after which WoSign will need
> to embed qualified SCTs. This check can be bypassed if the CA
> backdates certificates (which is problematic, given the history of
> backdating certificates in this particular case.)

AIUI, Chrome doesn't currently consider the difference between the
certificate's notBefore date and the corresponding SCTs' timestamps when
evaluating whether or not the certificate is "CT qualified".

To guard against backdating, ISTM that future versions of Chrome (and
hopefully Firefox too) could require, for certain CAs, that:
  1. The certificate MUST be "CT qualified".
  and
  2. In addition to the standard requirements for being "CT qualified",
the SCT timestamps MUST be within N seconds of the certificate's
notBefore date.

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

___
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

[Rob Stradling]

On 07/09/16 17:02, Gervase Markham wrote:
> On 07/09/16 13:52, Rob Stradling wrote:
>> Hi Thijs.  I agree that this pattern is interesting (and it'd be nice to
>> see an explanation), but I'm not convinced that it proves everything you
>> think it proves.
> 
> Hi Rob,
> 
> My digest of Thijs's work (and that of others investigating the same
> issues) is here:
> https://wiki.mozilla.org/CA:WoSign_Issues#Issue_S:_Backdated_SHA-1_Certs_.28January_2016.29
> 
> Is every conclusion I draw justified from the data?

Hi Gerv.  I'd like to discuss this particular conclusion:

  "...up to ID 109149...But after that follow 64 certificates which are
   all dated on December 20, 2015 (CST, UTC+8). This suggests that
   these were logged at the actual time of issuance but that time is
   not reflected in their notBefore date - i.e. they were backdated."

ID 109153 (https://crt.sh/?id=30629275) is the first such certificate,
not 109150.  Also, these 64 certificates were not logged consecutively.
I've just posted details of the relevant range of log entries here:
https://gist.github.com/robstradling/129729531779dab448ca88049c49307c

These log entries were only created 5 or 6 days ago, and the majority
don't have corresponding precertificates.
Consider https://crt.sh/?id=30629293, for example.  Are you really
suggesting that this was issued on 2nd September 2016 but backdated to
20th December 2015?

The entry timestamps up to ID 109221 are all very close together
(several entries per second).  We know that WoSign were at that time
submitting all of the certs they issued in 2015, so this is not surprising.

I think it's unreasonable to assume that WoSign attempted to log the
certs they issued in 2015 in the order in which they were issued.

I look forward to reading WoSign's response to Issue S.

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

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