WoSign and StartCom

[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

[yuhong...@hotmail.com]

"However, we don’t feel that Mozilla’s users in China have lower requirements for CA trustworthiness than Mozilla’s users elsewhere."
To be honest, I do hope that there are not many XP SP2 users in China anymore.

[Andrew Ayer]

> This fixing of the notAfter date in this style of certificate may
> have been a sensible move to avoid accidentally issuing SHA-1
> certificates whose validity extends into 2017, which would also be a
> BR violation.

This contradicts the "Issue D" section at
https://wiki.mozilla.org/CA:WoSign_Issues which says that this
issue was not a BR violation.

> Many of the rest of the Macau certificates, which do not have an
> embedded SCT to show when they were issued, have "matching"
> SHA-256 versions issued at some point in 2016, with everything the
> same except the issuing intermediate certificate, the hash algorithm
> and the notBefore/notAfter dates. This hints at the possibility that
> the two certificates were actually issued at the same time, and the
> date in the SHA-256 version is the correct issue date for both. If
> this is true, it shows misissuance continued until at least June 2016
> (*.zlbaba.com SHA-1, SHA-256).

The two *.zlbaba.com certificates (https://crt.sh/?id=30773543 and
https://crt.sh/?id=31103218) do not appear to be matching to me:
their public keys and serial numbers are different.

> Should StartCom/WoSign be permitted to re-apply using the same roots,
> or would they need new roots?

New roots. Considering the extent to which StartCom/WoSign have
mismanaged things, there could be further misissued certificates
chaining to their roots that we don't know about. The only way to
protect the ecosystem from such certificates is to require new roots -
roots that have only ever operated under the new audits that will be
required by Mozilla.

Regards,
Andrew

[Gervase Markham]

On 26/09/16 18:10, Andrew Ayer wrote:
> This contradicts the "Issue D" section at
> https://wiki.mozilla.org/CA:WoSign_Issues which says that this
> issue was not a BR violation.

You are quite right, thank you - fixed :-)

> The two *.zlbaba.com certificates (https://crt.sh/?id=30773543 and
> https://crt.sh/?id=31103218) do not appear to be matching to me:
> their public keys and serial numbers are different.

The serial numbers of all the pairs are different (which is good;
issuing two certs with the same serial number is an RFC violation, see
Issues H and P). I've not done an analysis of whether the public keys
match for some of the pairs; feel free to do one if you like. If you
think two different public keys casts doubt on the idea that these two
certs were issued at the same time, feel free to think that. However,
the document does not stand or fall on whether or not these are
co-issued pairs or not; that is merely a conjecture to try and establish
how long the misissuance happened for, as we have no other reliable dates.

Gerv

[Andrew Ayer]

On Mon, 26 Sep 2016 18:54:09 +0100
Gervase Markham <ge...@mozilla.org> wrote:

> > The two *.zlbaba.com certificates (https://crt.sh/?id=30773543 and
> > https://crt.sh/?id=31103218) do not appear to be matching to me:
> > their public keys and serial numbers are different.
>

> The serial numbers of all the pairs are different (which is good;
> issuing two certs with the same serial number is an RFC violation, see
> Issues H and P). I've not done an analysis of whether the public keys
> match for some of the pairs; feel free to do one if you like. If you
> think two different public keys casts doubt on the idea that these two
> certs were issued at the same time, feel free to think that. However,
> the document does not stand or fall on whether or not these are
> co-issued pairs or not; that is merely a conjecture to try and
> establish how long the misissuance happened for, as we have no other
> reliable dates.

Fair enough. You should revise the following wording which says
that the serial numbers and public keys are the same:

> Many of the rest of the Macau certificates, which do not have an
> embedded SCT to show when they were issued, have “matching” SHA-256
> versions issued at some point in 2016, with everything the same
> except the issuing intermediate certificate, the hash algorithm and
> the notBefore/notAfter dates

It seems that the only similarity between matching certificates is the
subject+SANs. (Plus EKU, AIA, CP, etc. but those are the same in all
WoSign certificates.)

Regards,
Andrew

[Gervase Markham]

On 26/09/16 19:13, Andrew Ayer wrote:
> Fair enough. You should revise the following wording which says
> that the serial numbers and public keys are the same:

Updated again.

Gerv

[Han Yuwei]

在 2016年9月26日星期一 UTC+8下午10:21:13，Gervase Markham写道：

Seems like we are not able to get a free 1-year certificate. I am very disappointed about that.

[Gervase Markham]

On 26/09/16 15:20, Gervase Markham wrote:
> 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.

Participants may be interested in this blog post from Tyro:
https://tyro.com/blog/merchant-security-is-tyros-priority/

Gerv

[Gervase Markham]

On 27/09/16 06:53, Percy wrote:
> you elaborate a bit on concrete ways of discovering such backdating?

Now Percy, you can't expect us to give away all our secrets ;-P

Gerv

[adroi...@gmail.com]

在 2016年9月26日星期一 UTC+8下午10:57:33，yuhong...@hotmail.com写道：

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.

[Stephen Schrauger]

> > Should StartCom/WoSign be permitted to re-apply using the same roots,
> > or would they need new roots?
>
> New roots. Considering the extent to which StartCom/WoSign have
> mismanaged things, there could be further misissued certificates
> chaining to their roots that we don't know about. The only way to
> protect the ecosystem from such certificates is to require new roots -
> roots that have only ever operated under the new audits that will be
> required by Mozilla.
>
> Regards,
> Andrew

I agree that they should need new roots. But on top of the points Andrew makes, it would also require StartCom and WoSign to get cross-signed if they wish to continue supporting older devices that lack their new roots.

They would have to regain the trust of another root CA who would be willing to cross-sign their new roots. Or else StartCom and WoSign would have to accept that new certificates created under their new root may not work on older devices, since older computers and embedded devices aren't always able to update their root stores.

Assuming they want new certificates to work on older devices, I imagine the need to be cross-signed would create another point of trust, since another CA willing to cross-sign would do their own audit and have added requirements.

[adroi...@gmail.com]

在 2016年9月26日星期一 UTC+8下午10:57:33，yuhong...@hotmail.com写道：

[Gervase Markham]

On 27/09/16 13:13, adroi...@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

[Han Yuwei]

在 2016年9月27日星期二 UTC+8下午8:33:28，Gervase Markham写道：

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. :)

[Hector Martin "marcan"]

On 2016-09-27 23:21, Han Yuwei wrote:
> 在 2016年9月27日星期二 UTC+8下午8:33:28，Gervase Markham写道：

> 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

[Han Yuwei]

Yes, I totally agree with you.But some software can't work under newer system. Maybe we can find a solution towards this.

[Erwann Abalea]

Bonsoir,

There are 2 solutions for this problem:

1/ a temporary one, where the certificate subscriber can demonstrate that it its relying parties can't accept SHA2 today but will be upgraded before the end of 2016. The procedure to get a SHA1 certificate is a public review with extended checks, it takes about 2 weeks to get the approval if nothing risky is found. It's the "SHA1 Exceptions process" described in the extensive report written by Gerv. WoSign and StartCom have chosen to not follow it, and to hide their actions.

2/ a permanent one, where it's really not possible to upgrade the relying parties' systems to accept SHA2, or the subscriber is not willing to do the effort. The SHA1 certificate is issued by a non public CA, and this non public CA is explicitly imported as trusted in the necessary relying parties' systems.

There is no other alternative.

[Peter Gutmann]

Percy <percy...@gmail.com> writes:

>On Tuesday, September 27, 2016 at 2:15:38 AM UTC-7, Gervase Markham wrote:
>> Participants may be interested in this blog post from Tyro:
>> https://tyro.com/blog/merchant-security-is-tyros-priority/
>

>So this is almost proof that WoSign/StartCom has been intentionally back-
>dating certificates to avoid blocks on SHA-1 issuance in browsers.

Did anyone keep a copy of that post? Looks like they took it down pretty
quickly, possibly in response to the above.

Peter.

[Shengjing Zhu]

One question,
Since WoSign and StartCom have certification which is cross signed by Certum CA(https://wiki.mozilla.org/CA:WoSign_Issues#Cross_Signing), does that mean browser will still trust any certification signed by "Certification Authority of WoSign G2" if the website owner sends a certification chain indicates this cross signed certification?

Is there any way to distrust intermediate certification by its common name?

[Adam Caudill]

> On Sep 28, 2016, at 3:16 AM, Peter Gutmann <pgu...@cs.auckland.ac.nz> wrote:
>
> Did anyone keep a copy of that post? Looks like they took it down pretty
> quickly, possibly in response to the above.

Thankfully it was still in Bing’s cache (thanks to Ryan Hurst for reminding me to check there); here’s an Archive.org copy of Bing’s cached copy:

https://web.archive.org/web/20160928082744/http://cc.bingj.com/cache.aspx?q=url%3ahttps%3a%2f%2ftyro.com%2fblog%2fmerchant-security-is-tyros-priority%2f&d=3142275970384&mkt=en-US&setlang=en-US&w=CXAExr3p_O5p0vSMb-OFFm7Vt8ZUhoMF

--
Adam Caudill
ad...@adamcaudill.com
http://adamcaudill.com/

[Nick Lamb]

On Tuesday, 27 September 2016 10:15:38 UTC+1, Gervase Markham wrote:
> https://tyro.com/blog/merchant-security-is-tyros-priority/

This site reproduces what I guess is an email from Tyro (can't find similar text on their website) that suggests very strongly they weren't prepared for SHA-1 deprecation at all and hadn't previously even notified their customers of the necessary upgrades.

http://www.newsagencyblog.com.au/2016/06/02/if-you-are-running-windows-xp/

If May was really the first time they realised they had a problem that's pretty damning.

[Gervase Markham]

On 28/09/16 12:23, Nick Lamb wrote:
> This site reproduces what I guess is an email from Tyro (can't find
> similar text on their website) that suggests very strongly they
> weren't prepared for SHA-1 deprecation at all and hadn't previously
> even notified their customers of the necessary upgrades.
>
> http://www.newsagencyblog.com.au/2016/06/02/if-you-are-running-windows-xp/

Very interesting. Thank you :-)

Gerv

[Rob Stradling]

On 28/09/16 12:23, Nick Lamb wrote:

> On Tuesday, 27 September 2016 10:15:38 UTC+1, Gervase Markham wrote:
>> https://tyro.com/blog/merchant-security-is-tyros-priority/
>

> This site reproduces what I guess is an email from Tyro (can't find similar text on their website) that suggests very strongly they weren't prepared for SHA-1 deprecation at all and hadn't previously even notified their customers of the necessary upgrades.
>
> http://www.newsagencyblog.com.au/2016/06/02/if-you-are-running-windows-xp/
>

> If May was really the first time they realised they had a problem that's pretty damning.

Presumably this...

"The certificate that we use to secure our integration system expires
on the 6th of June, 2016 and the new certificate cannot be accepted
by POSs that run on Windows XP Service pack 2 or earlier."

...is referring to https://crt.sh/?id=1455926 and
https://crt.sh/?id=20031959. If so, that would seem to imply that
https://crt.sh/?id=21427475 had not been issued when that article was
posted.

(The alternative, and I would suggest unlikely, explanation is that Tyro
did possess https://crt.sh/?id=21427475 when that article was posted,
but for some reason they'd already made the decision to not use it).

BTW, I found a couple of other references:

http://www.possolutions.com.au/blog/windows-xp-sp2-expires

http://www.possolutions.com.au/blog/if-you-are-running-windows-xp-or-server-2003

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

[Nick Lamb]

On Wednesday, 28 September 2016 18:33:07 UTC+1, Percy wrote:
> I'm assuming WoSign/StartCom pressured Tyro to remove the blog post. WoSign/StartCom has previously publicly threatened legal actions over the secret purchase.

I would say it's just as likely that Tyro's executives decided that the blog post doesn't match up with the current story they want to start telling.

Tomorrow's CA/B agenda, the new Symantec-issued wildcard for Tyro, and other factors suggest that Tyro now intends to pursue the SHA-1 exception process. On the whole there's no overwhelming reason they shouldn't be able to qualify for that process, but it may be a lot easier if they can manage to come up with one coherent story for how they got here which avoids contradicting the known facts or their own previous assertions, such as those in the blog post.

[Dean Coclin]

FYI-Tyro is not the company referenced on the CA/B Forum agenda.

Dean Coclin

CA/B Forum Chair 

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

[Peter Kurrasch]

I think we're well past the point where a "do-over" can be considered a reasonable remedy. The problem is not simply one in which certs were issued improperly nor is it simply one in which ‎there were mistakes in the CA infrastructure. Such problems, I think, could fall under a category where starting over with new roots, new audits, etc. would seem acceptable. 

Rather, what we have here is basically a rogue operator that has threatened the trust and integrity of the global PKI system. Their conduct‎ has undermined efforts to establish and maintain security on the Internet (e.g. backdating SHA-1 certs). Their conduct has flaunted rules and regulations for reasons that are still to this day not fully understood (e.g. ownership and problems with the auditng). Their conduct has caused undue consternation to web site owners (e.g. github) due to cert mis-issuance. Their conduct has put their own customers in a difficult position as they must now consider obtaining new certs for their websites.

Starting over with new roots won't remedy these problems.

  Original Message  
From: Stephen Schrauger
Sent: Tuesday, September 27, 2016 7:32 AM
To: mozilla-dev-s...@lists.mozilla.org
Subject: Re: WoSign and StartCom

[Jakob Bohm]

Note that in my daily work, I am aware of at least one system where
neither option is particularly viable, due to the platform vendor
locking down the system and then abandoning the signing services that
would usually authorize CA certificate imports. This leaves the system
in question with a "set in stone" list of trusted (SHA-1) CAs.

Thus to cater to those systems (especially when the actual devices are
3rd party owned), the only practical solution would be for one of the
relevant old SHA-1 root CA certs to issue (via intermediaries etc.) new
SHA-1 certs until the hardware dies. On a trust policy/BR level, the
key detail here is that the issuing root cert is a SHA-1 cert itself
and would thus be distrusted by SHA-1-distrusting systems anyway.


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

[Gervase Markham]

On 30/09/16 07:50, Jakob Bohm wrote:
> SHA-1 certs until the hardware dies. On a trust policy/BR level, the
> key detail here is that the issuing root cert is a SHA-1 cert itself
> and would thus be distrusted by SHA-1-distrusting systems anyway.

That's not so; I believe most (all?) systems don't check the signatures
on their own embedded root certificates, because they are implicitly
trusted. There are many roots in the Mozilla program with SHA-1
signatures; see the Signature Hash Algorithm column in:
https://mozillacaprogram.secure.force.com/CA/IncludedCACertificateReport

In fact, there are two with MD5 signatures, although as it happens they
are only trusted for email.

Gerv

[Jakob Bohm]

Well, at least the intermediaries involved would be SHA-1 and be
checked against the SHA-1-distrust policy?

[Stefan Paletta]

Hi everyone!

Thank you, Gervase et al., for your excellent work. It is encouraging to see this done so conscientiously and professionally when the circumstances require so. While not claiming any particular significance for my opinion, I do fully agree with the conclusions and the proposed action.

I have one question about the proposal: what is the rationale and justification for the one-year minimum distrust? While this seems quite reasonable at first glance, my thinking is this: clearly, the proposed extensive audit must be deemed sufficient to allow for re-qualification a year from now (because otherwise you would not be proposing it). Then why would such an extensive audit not be sufficient when executed right now? In other words: what does the addition of simply waiting for a year change about admissibility to the Mozilla roots?

One possible rationale might of course be to deliver a form of punishment, if only to discourage any future misconduct by other CAs. On the one hand, that would be a delicate thing to do, on the other hand it could be seen as a necessary strategic move to protect the functioning of the trust program (think Game Theory).

Thanks
–Stefan

[Erwann Abalea]

Bonjour,

Le samedi 1 octobre 2016 11:02:21 UTC+2, Stefan Paletta a écrit :
[...]

> I have one question about the proposal: what is the rationale and justification for the one-year minimum distrust? While this seems quite reasonable at first glance, my thinking is this: clearly, the proposed extensive audit must be deemed sufficient to allow for re-qualification a year from now (because otherwise you would not be proposing it). Then why would such an extensive audit not be sufficient when executed right now? In other words: what does the addition of simply waiting for a year change about admissibility to the Mozilla roots?

The auditor doesn't predict the future. The auditor can only audit what was made in the past.
I consider the Mozilla investigation to be an audit, and the findings are really bad. Another extensive audit performed right now can't possibly give a different result.

[Gervase Markham]

On 30/09/16 13:40, Jakob Bohm wrote:
> Well, at least the intermediaries involved would be SHA-1 and be
> checked against the SHA-1-distrust policy?

Yes. But issuing SHA-1 from a currently-publicly-trusted root is a BR
violation, whether clients enforce distrust or not. One solution often
adopted for old clients is to issue from a root which is no longer
currently-publicly-trusted.

Gerv

[Gervase Markham]

Hi Stefan,

On 01/10/16 00:35, Stefan Paletta wrote:
> I have one question about the proposal: what is the rationale and
> justification for the one-year minimum distrust?

The determination of the action to take in any particular case takes
account of precedent (e.g. CNNIC) and our understanding of
proportionality, and what would be best in order to see a proper
remediation. This time period is part of the proposal (and note that it
is still a proposal) was chosen because I currently believe that WoSign
would need to make significant technical changes (and perhaps other
sorts of changes) in order to pass a full security audit from a code
auditor. If the time period before the possibility of re-enablement was
too short, there might be a temptation to rush this process, which would
be in nobody's interest.

Gerv

[Ángel González]

On 2016-09-26 at 20:15 -0700, Stephen Schrauger wrote:
>
> I agree that they should need new roots. But on top of the points Andrew makes, it would also require StartCom and WoSign to get cross-signed if they wish to continue supporting older devices that lack their new roots.
>
> They would have to regain the trust of another root CA who would be willing to cross-sign their new roots. Or else StartCom and WoSign would have to accept that new certificates created under their new root may not work on older devices, since older computers and embedded devices aren't always able to update their root stores.
>
> Assuming they want new certificates to work on older devices, I imagine the need to be cross-signed would create another point of trust, since another CA willing to cross-sign would do their own audit and have added requirements.

Not really. Their old roots could sign their new roots, which would be
enough to make them work on the older devices where it worked.
The cost of untrusting the old roots is probably similar to that of
adding new roots, so that the effort of chaining to a different CA is
not worthwhile.

[Gervase Markham]

On 04/10/16 01:00, Ángel González wrote:
> Not really. Their old roots could sign their new roots, which would
> be enough to make them work on the older devices where it worked. The
> cost of untrusting the old roots is probably similar to that of
> adding new roots, so that the effort of chaining to a different CA
> is not worthwhile.

This is true as long as there is no gap between when you dis-trust the
old roots and when you add the new ones to your store. But that's
unlikely because dis-trusts normally happen fairly quickly, spinning up
new roots takes time, and you may want it to be done under a reformed
regime rather than under the old one.

Gerv

[Anand Kumria]

Hi,

Thanks for the extensive document and information, it has been a throughly interesting read.

On Tuesday, 27 September 2016 00:21:13 UTC+10, Gervase Markham wrote:
>
> 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.

Thoughts:

> no longer accept audits carried out by Ernst & Young (Hong Kong).

I think that punishing the auditor here but geographically constraining it is the wrong message to send.

Why not simply distrust all audits carried out by Ernst & Young?

Either someone at Ernst & Young HQ (london) signed-off of this kind deception (if it was known), or they signed-off on an audit when it was improperly conducted, or they signed-off on an audit when the sub-ordinate company was unable to obtain all the infomration required.

Or, worse, they have no control at all over their sub-ordinate company.

> How much lead time does the ecosystem need before we take this action?

I think that this should be a standard security update

> Should StartCom/WoSign be permitted to re-apply using the same roots, or
> would they need new roots?

They should be required to use new roots.

I think another set of sanctions you (Mozilla) could also apply are:

- anyone issuing certificates for .cn, .hk or .mo domain *MUST* submit those certificate to the CT server set (with similar constraints as you require for WoSign/StartCom)

- constrain certificates issued to .cn, .hk, .mo domains to be valid for (at most) 2 years.

The rationale for those additional suggestions is that this might preclude any organisation from being pressured into issuing certificates with fraudulent information within them and, even if that were to occur - and not be detected for a while - you have also constrained the maximum exposure window.

Regards,
Anand

[Gervase Markham]

On 05/10/16 05:18, Anand Kumria wrote:
> I think that punishing the auditor here but geographically
> constraining it is the wrong message to send.
>
> Why not simply distrust all audits carried out by Ernst & Young?

As I understand it, global branded auditors are, in fact, made up of a
number of local firms. We think that this is the correct scope for this
ban at the present time. However, if future problems arise with E&Y
audits done by other countries' E&Y teams, that might be the time to
consider a ban of wider scope.

> - anyone issuing certificates for .cn, .hk or .mo domain *MUST*
> submit those certificate to the CT server set (with similar
> constraints as you require for WoSign/StartCom)
>
> - constrain certificates issued to .cn, .hk, .mo domains to be valid
> for (at most) 2 years.
>
> The rationale for those additional suggestions is that this might
> preclude any organisation from being pressured into issuing
> certificates with fraudulent information within them and, even if
> that were to occur - and not be detected for a while - you have also
> constrained the maximum exposure window.

"The maximum exposure is 2 years" is not much of a constraint.
Additionally, although you don't say who you are talking about, there is
not necessarily an overlap between the sort of certs such pressure may
relate to, and the TLDs you mention. Many important sites use .com, for
example. And the risk of a compelled certificate creation attack is
nothing to do with the issues at WoSign.

Gerv

[jul...@gmail.com]

On Tuesday, September 27, 2016 at 7:31:30 AM UTC+2, Han Yuwei wrote:
> 在 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.

You do realize there's a really good CA called LetsEncrypt? Which easily lets you automate renewal, and is proven VERY trustworthy thus far. I already moved away from startcom just because letsencrypt is way easier to maintain..
https://letsencrypt.org/docs/client-options/

[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?

[Nick Lamb]

On Friday, 7 October 2016 21:11:01 UTC+1, Han Yuwei wrote:
> About the auditor Ernst & Young (Hong Kong), I don't understand how did it(?) involved this. Can someone explain that?

Management of a public CA are oblige to state periodically that they understand and obey various rules for operating a public CA. But how can we trust they do so? The management hire an independent _auditor_ usually from a professional services company like EY to verify that the statements from management are true. The auditor should undertake reasonable steps to satisfy themselves of the veracity of these statements, e.g. if the management says the CA is in a second floor steel and concrete building in Manhattan, the auditor can visit and see whether it seems to instead be a wooden barn in New Jersey. If the management says all issuances are authorised by two employees working together, the auditor can watch this being done one day and see if in fact only one employee does all the work.

Mozilla believes that WoSign mis-behaved in ways that a competent auditor should have detected. This leaves open two possibilities, neither good for the local EY

1. They were not competent, their examination of the facts at WoSign fell short of what they should have done, it did not find the misbehaviour at WoSign because it was not sufficiently thorough.

OR
2. They were dishonest, they knew or suspected that WoSign had misbehaved but chose to conceal this fact from readers of the audit report.

In either case, this auditor cannot be trusted with other audit work, as it may do exactly the same thing again, which makes the audit pointless. Competent, honest auditors must be used for all audits.