March 2016 CA Communication Responses

[Kathleen Wilson]

All,

I have added links to reports of the responses to the March 2016 CA Communication survey:

https://wiki.mozilla.org/CA:Communications#March_2016_Responses

Please keep in mind that the responses are considered preliminary and may be changed until April 22, 2016. And remember that up until about 2010, some CAs were issuing 10 year TLS/SSL certificates, so this may cause some consternation regarding responses to ACTION #1b.

Also, I still need to add the new "ACTION 1a TEXT INPUT" and "ACTION 1b TEXT INPUT" data to the reports.

Thanks,
Kathleen

[Kathleen Wilson]

The reports of the responses to Action 1a and Action 1b have been updated to include the text input too.

Thanks,
Kathleen

[Nick Lamb]

On Wednesday, 13 April 2016 21:39:48 UTC+1, Kathleen Wilson wrote:
> I have added links to reports of the responses to the March 2016 CA Communication survey:
>
> https://wiki.mozilla.org/CA:Communications#March_2016_Responses

Thanks Kathleen,

I have compared the list of responses to the list of included CAs also driven by Salesforce, and there is a considerable discrepancy. First pass of "missing" responses is:

Certicámara S.A.
China Financial Certification Authority (CFCA)
Cybertrust Japan / JCSI
Deutscher Sparkassen Verlag GmbH (S-TRUST, DSV-Gruppe)
Government of France (ANSSI, DCSSI)
Government of Turkey, Kamu Sertifikasyon Merkezi (Kamu SM)
RSA the Security Division of EMC
Start Commercial (StartCom) Ltd.
SwissSign AG
Trend Micro
Visa
Web.com

Probably some of these can be explained away as re-names or acquisitions, I'd appreciate it if Kathleen or the CA owners point out any examples of that above. Perhaps also a few more responses will trickle in late over this weekend.

If in fact no response was received then immediately it doesn't make any sense to continue processing applications to add roots or increase trust for the organisations that haven't responded, purely as an anti-exploitation measure. Longer term it may even make sense to simply remove all trust for roots operated by these CAs, perhaps after a reminder / warning.

[Kathleen Wilson]

On Saturday, April 23, 2016 at 2:53:40 AM UTC-7, Nick Lamb wrote:
> On Wednesday, 13 April 2016 21:39:48 UTC+1, Kathleen Wilson wrote:
> > I have added links to reports of the responses to the March 2016 CA Communication survey:
> >
> > https://wiki.mozilla.org/CA:Communications#March_2016_Responses
>
> Thanks Kathleen,
>
> I have compared the list of responses to the list of included CAs also driven by Salesforce, and there is a considerable discrepancy. First pass of "missing" responses is:

Hi Nick,

I appreciate your efforts in this area.

It will take me some time to reach out to each of these CAs to have them check to see if the email got caught in their SPAM filter, or if their Primary POC has changed or been out of the office, etc. I did receive email from a few of them asking for a bit more time, due to needing to hear back from the rest of their subCAs, or having been out of the office for various reasons (e.g. medical or vacation).

Thanks,
Kathleen

[Mat Caughron]

Hi All:

To make it current, can the Trend Micro entry be turned into a pointer to Entrust Datacard?

On March 22 this year, the acquisition of Trend's certificate authority business unit by Entrust was made public, for reference:
http://www.businesswire.com/news/home/20160322005639/en/Entrust-Datacard-Trend-Micro-Partner-Provide-Comprehensive

Regarding presence in the trust stores, these Entrust roots are still legacy-branded as Affirmtrust.


Mat Caughron
(408) 910-1266

On Wednesday, April 13, 2016 at 1:39:48 PM UTC-7, Kathleen Wilson wrote:

[Kathleen Wilson]

On Monday, April 25, 2016 at 7:29:20 AM UTC-7, Mat Caughron wrote:
> Hi All:
>
> To make it current, can the Trend Micro entry be turned into a pointer to Entrust Datacard?
>
> On March 22 this year, the acquisition of Trend's certificate authority business unit by Entrust was made public, for reference:
> http://www.businesswire.com/news/home/20160322005639/en/Entrust-Datacard-Trend-Micro-Partner-Provide-Comprehensive
>
> Regarding presence in the trust stores, these Entrust roots are still legacy-branded as Affirmtrust.
>

Hi Mat,

I received a similar question from Kirk at Trend Micro. But, I responded to Kirk asking him to reply to the survey with answers regarding Trend Micro's current state. They can just put in a future date for when the CA hierarchy information will be put into Salesforce, so they can figure that out later. But I would still like a Trend Micro response to the survey.

Thanks,
Kathleen

[Kathleen Wilson]

On Monday, April 25, 2016 at 7:28:35 AM UTC-7, Kathleen Wilson wrote:
>
> It will take me some time to reach out to each of these CAs to have them
> check to see if the email got caught in their SPAM filter, or if their
> Primary POC has changed or been out of the office, etc. I did receive email
> from a few of them asking for a bit more time, due to needing to hear back
> from the rest of their subCAs, or having been out of the office for various
> reasons (e.g. medical or vacation).

All of the currently-included CAs have responded to the survey.

https://wiki.mozilla.org/CA:Communications#March_2016_Responses


Thanks,
Kathleen

[Charles Reiss]

On 04/13/16 20:32, Kathleen Wilson wrote:
> All,
>
> I have added links to reports of the responses to the March 2016 CA
> Communication survey:
>
> https://wiki.mozilla.org/CA:Communications#March_2016_Responses

For the responses to Question 1a:

DocuSign (OpenTrust/Keynectis) indicated 2015 Dec 31 but the following
certificate has a notBefore of 10 Feb 2016 and, according to its CRL,
was revoked 11 Feb 2016:
- https://crt.sh/?id=16157906&opt=cablint

Government of France indicated by 2015 Dec 31 but the following
certificate has notBefores of 11 Jan 2016 and 18 April 2016:
- https://crt.sh/?id=12129393&opt=cablint
- https://crt.sh/?id=18777122&opt=cablint

SECOM indicated 2015 Dec 31 but the following certificate as a notBefore
of 7 Jan 2016:
- https://crt.sh/?id=12090324&opt=cablint

T-Systems International GmbH (Deutsche Telekom) indicated 2016 Jan 15
with "revoked: 02/02/2016" in the comment, but the following certificate
has a notBefore of 9 March 2016:
- https://crt.sh/?id=15019496&opt=cablint


For the responses to Question 4:

Government of France indicated "None of the above", but the following
certificates include the id-kp-serverAuth EKU but no dNSName or
iPAddress SAN:
- https://crt.sh/?id=12129393&opt=cablint
- https://crt.sh/?id=18777122&opt=cablint

Government of Hong Kong (SAR) indicated "None of the above", but these
certificates (which chain to Hongkong Post Root CA 1) are lacking SAN
entries and appear to be intended for TLS server usage:
- https://crt.sh/?id=16024471&opt=cablint
- https://crt.sh/?id=12114285&opt=cablint

[Erwann Abalea]

Bonjour,

Le lundi 9 mai 2016 21:40:52 UTC+2, Charles Reiss a écrit :
> On 04/13/16 20:32, Kathleen Wilson wrote:
> > All,
> >
> > I have added links to reports of the responses to the March 2016 CA
> > Communication survey:
> >
> > https://wiki.mozilla.org/CA:Communications#March_2016_Responses
>
> For the responses to Question 1a:
>
> DocuSign (OpenTrust/Keynectis) indicated 2015 Dec 31 but the following
> certificate has a notBefore of 10 Feb 2016 and, according to its CRL,
> was revoked 11 Feb 2016:
> - https://crt.sh/?id=16157906&opt=cablint

There has been exactly 2 TLS server certificates signed with SHA1 after the 31 Dec 2015:
- serial number 1121741263ED77D31273BB5048A39EBCCB02, for *.idnomic.com and *.int.idnomic.com, (organization IDnomic, the new brand name of OpenTrust) generated on 04 Feb 2016, revoked on 11 Feb 2016
- serial number 1121C624EFBEFC18F88FC1987576AA9B7822, for api2.certificat.com and vetting.certificat.com (O=DocuSign France), generated on 10 Feb 2016, revoked on 11 Feb 2016

They were errouneously produced, not for a customer (OpenTrust/IDnomic and DocuSign still share some infrastructure), and once detected the certificates have been revoked, and the SHA1 configuration files have been disabled. New certificates have been generated to replace them, on 11 Feb 2016.

[Charles Reiss]

On 04/13/16 20:32, Kathleen Wilson wrote:

> All,
>
> I have added links to reports of the responses to the March 2016 CA
> Communication survey:
>
> https://wiki.mozilla.org/CA:Communications#March_2016_Responses

For question 1a, TeliaSonera indicated "2015 Oct 20", but the following
SHA-1 server certificate has a notBefore of 17 March 2016 and appears to
chain to TeliaSonera Root v1:
https://censys.io/certificates/ff7f4a0f23205127347018555628b05d11a355ed92e9aa59d5eabda750f0f622

[Rob Stradling]

On 15/05/16 07:39, Charles Reiss wrote:
> On 04/13/16 20:32, Kathleen Wilson wrote:

>> All,
>>
>> I have added links to reports of the responses to the March 2016 CA
>> Communication survey:
>>
>> https://wiki.mozilla.org/CA:Communications#March_2016_Responses
>

> For question 1a, TeliaSonera indicated "2015 Oct 20", but the following
> SHA-1 server certificate has a notBefore of 17 March 2016 and appears to
> chain to TeliaSonera Root v1:
> https://censys.io/certificates/ff7f4a0f23205127347018555628b05d11a355ed92e9aa59d5eabda750f0f622

Hi Charles.

See also https://crt.sh/?id=15647440
(This page failed to display the certificate details until I fixed a bug
just now, which could explain why you quoted the Censys page instead ;-) )

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

[pekka.la...@teliasonera.com]

TeliaSonera (now known as Telia Company) did a human mistake when enrolling this mentioned SHA1 certificate by using manual methods. BR restriction was not properly informed to all Registration Officers. It was enrolled because customer's old server couldn't handle SHA-2.

This certificate was not included to our reply because our SHA1 listing for reply was based only on our normal issuance method. Now we have checked the whole SSL database that this was the only SHA exception.

We will technically prevent this from happening again by disabling the old configurations which are required to issue our SHA1 certificates. We'll also improve our instructions for Registration Officers.

Pekka Lahtiharju
Senior Development Manager
Telia Company CA

[?? ?]

Hello,

> SECOM indicated 2015 Dec 31 but the following certificate as a notBefore of 7 Jan 2016:
> - https://crt.sh/?id=12090324&opt=cablint

We checked again and found the last day issued was January 26, 2016.
Those were already revoked.
It was informed to the customer that the last day to issue SHA-1 certificates was December31, 2015.
However, it seems that the announcement was not enough stop issuing thus we took a measure technically stop issuing SHA-1 SSL certificates.

Best regards,
Hisashi Kamo

> -----Original Message-----
> From: dev-security-policy [mailto:dev-security-policy-bounces+h-kamo=secom...@lists.mozilla.org] On Behalf Of
> Charles Reiss
> Sent: Tuesday, May 10, 2016 4:40 AM
> To: mozilla-dev-s...@lists.mozilla.org
> Subject: Re: March 2016 CA Communication Responses
>
> On 04/13/16 20:32, Kathleen Wilson wrote:

> > All,
> >
> > I have added links to reports of the responses to the March 2016 CA
> > Communication survey:
> >
> > https://wiki.mozilla.org/CA:Communications#March_2016_Responses
>

> For the responses to Question 1a:
>
> DocuSign (OpenTrust/Keynectis) indicated 2015 Dec 31 but the following certificate has a notBefore of 10 Feb 2016 and,
> according to its CRL, was revoked 11 Feb 2016:
> - https://crt.sh/?id=16157906&opt=cablint
>

> Government of France indicated by 2015 Dec 31 but the following certificate has notBefores of 11 Jan 2016 and 18 April
> 2016:
> - https://crt.sh/?id=12129393&opt=cablint
> - https://crt.sh/?id=18777122&opt=cablint
>
> SECOM indicated 2015 Dec 31 but the following certificate as a notBefore of 7 Jan 2016:
> - https://crt.sh/?id=12090324&opt=cablint
>
> T-Systems International GmbH (Deutsche Telekom) indicated 2016 Jan 15 with "revoked: 02/02/2016" in the comment, but
> the following certificate has a notBefore of 9 March 2016:
> - https://crt.sh/?id=15019496&opt=cablint
>
>
> For the responses to Question 4:
>
> Government of France indicated "None of the above", but the following certificates include the id-kp-serverAuth EKU but
> no dNSName or iPAddress SAN:
> - https://crt.sh/?id=12129393&opt=cablint
> - https://crt.sh/?id=18777122&opt=cablint
>
> Government of Hong Kong (SAR) indicated "None of the above", but these certificates (which chain to Hongkong Post Root
> CA 1) are lacking SAN entries and appear to be intended for TLS server usage:
> - https://crt.sh/?id=16024471&opt=cablint
> - https://crt.sh/?id=12114285&opt=cablint
>
>
>
> >

> > Please keep in mind that the responses are considered preliminary and
> > may be changed until April 22, 2016. And remember that up until about
> > 2010, some CAs were issuing 10 year TLS/SSL certificates, so this may
> > cause some consternation regarding responses to ACTION #1b.
> >
> > Also, I still need to add the new "ACTION 1a TEXT INPUT" and "ACTION
> > 1b TEXT INPUT" data to the reports.
> >
> > Thanks, Kathleen
> >
>

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

[Bernd.N...@t-systems.com]

We revoked the affected certificate immediately.

One of our customers issued a S/MIME certificate (SHA-1) to misuse as gateway certificate. That's the reason, why this certificate was identified as incorrect TLS Server certificate (ERROR: SHA-1 not allowed for signing certificates). We specified in our CP/CPS that this practice is not allowed.

We will improve the verification mechanisms to prevent this kind of abuse in the future.


Bernd Nakonzer
T-Systems International GmbH
Trust Center Applications


-----Ursprüngliche Nachricht-----
Von: dev-security-policy [mailto:dev-security-policy-bounces+bernd.nakonzer=t-syst...@lists.mozilla.org] Im Auftrag von Charles Reiss
Gesendet: Montag, 9. Mai 2016 21:40
An: mozilla-dev-s...@lists.mozilla.org
Betreff: Re: March 2016 CA Communication Responses

On 04/13/16 20:32, Kathleen Wilson wrote:

> All,
>
> I have added links to reports of the responses to the March 2016 CA
> Communication survey:
>
> https://wiki.mozilla.org/CA:Communications#March_2016_Responses

For the responses to Question 1a:

DocuSign (OpenTrust/Keynectis) indicated 2015 Dec 31 but the following certificate has a notBefore of 10 Feb 2016 and, according to its CRL, was revoked 11 Feb 2016:
- https://crt.sh/?id=16157906&opt=cablint

Government of France indicated by 2015 Dec 31 but the following certificate has notBefores of 11 Jan 2016 and 18 April 2016:
- https://crt.sh/?id=12129393&opt=cablint
- https://crt.sh/?id=18777122&opt=cablint

SECOM indicated 2015 Dec 31 but the following certificate as a notBefore of 7 Jan 2016:
- https://crt.sh/?id=12090324&opt=cablint

T-Systems International GmbH (Deutsche Telekom) indicated 2016 Jan 15 with "revoked: 02/02/2016" in the comment, but the following certificate has a notBefore of 9 March 2016:
- https://crt.sh/?id=15019496&opt=cablint


For the responses to Question 4:

Government of France indicated "None of the above", but the following certificates include the id-kp-serverAuth EKU but no dNSName or iPAddress SAN:
- https://crt.sh/?id=12129393&opt=cablint
- https://crt.sh/?id=18777122&opt=cablint

Government of Hong Kong (SAR) indicated "None of the above", but these certificates (which chain to Hongkong Post Root CA 1) are lacking SAN entries and appear to be intended for TLS server usage:
- https://crt.sh/?id=16024471&opt=cablint
- https://crt.sh/?id=12114285&opt=cablint



>

> Please keep in mind that the responses are considered preliminary and
> may be changed until April 22, 2016. And remember that up until about
> 2010, some CAs were issuing 10 year TLS/SSL certificates, so this may
> cause some consternation regarding responses to ACTION #1b.
>
> Also, I still need to add the new "ACTION 1a TEXT INPUT" and "ACTION
> 1b TEXT INPUT" data to the reports.
>
> Thanks, Kathleen
>

[Nick Lamb]

On Friday, 3 June 2016 07:53:06 UTC+1, Bernd.N...@t-systems.com wrote:
> We revoked the affected certificate immediately.
>
> One of our customers issued a S/MIME certificate (SHA-1) to misuse as gateway certificate. That's the reason, why this certificate was identified as incorrect TLS Server certificate (ERROR: SHA-1 not allowed for signing certificates). We specified in our CP/CPS that this practice is not allowed.
>
> We will improve the verification mechanisms to prevent this kind of abuse in the future.

Bernd what do you mean here by "misuse as gateway certificate" ? The meaning of this is opaque to me, perhaps from my lack of experience with S/MIME systems. Does this mean only that the customer obtained this certificate from a system intended to issue S/MIME certs, but with the apparent intent to use it on a web server or similar ? Or something more ?

I am also a little worried by the vague phrase "in the future". When a problem like this is identified, where subscribers are able to obtain certificates which T-Systems should never have signed, you can't continue issuing and hope to fix it later.

That might be a language problem, but so far as I can see the only acceptable options here are for T-systems to

1. Ensure this system cannot issue working TLS server certificates NOW
OR
2. Cease issuance from the affected system until the problem is fixed.

In the Symantec thread they discussed technical controls they'd put in place to control this sort of risk, so you might want to discuss how they did it, or talk to other CAs in the S/MIME issuance business for their ideas.

A Mozilla employee might be able to expand on my thought here or correct me if I'm wrong.

Further, once the problem is fixed, it would make sense for T-Systems to perform an internal review of your issuance logs or other records to identify any other instances where this happened, revoke any affected certificates, and reach out to customers who obtained them explaining that this is _prohibited_ but emphasising that the fault in allowing issuance was yours, not theirs.

>From the Mozilla side, this is yet further evidence of the need to stop treating CN as a hostname in certificates, at least new certificates. We're fast approaching the point where more of the certificates with a hostname in the CN but no SAN are going to be mis-issued garbage like this example than are just the result of incompetent issuers not adding a SAN and there's no reason to reward either scenario with a a green lock logo.