Re: SHA256 for OCSP response issuer hashing

[Jakob Bohm]

On 16/12/2016 00:36, Roland Shoemaker wrote:

Let's Encrypt is currently considering moving away from using SHA1 as
the issuer subject/public key hashing function in OCSP responses and
using SHA256 instead. Given a little investigation this seems like a
safe move to make but we wanted to check with the community to see if
anyone was aware of legacy (or contemporary) software issues that may
cause us any trouble.



I believe it would cause a problem with legacy systems that don't
understand SHA-256 signatures at all, noting that such systems will
only ever trust SHA-1 (and older) certificates, thus SHA-1 signing can
be limited to cases where the CA chain leading to the certificate
issuer has no SHA-256 signatures and the certificate being checked is
not a known SHA-256 certificate (generating the dynamic rejection
response for a never issued certificate would choose the hash based on
the hash algorithm in the involved intermediary CA certs).

I wonder if Let's Encrypt ever issued SHA-1 certificates, and if any of
those are non-expired.  Worst case, I guess there might be only a few
such certificates, all of them Intermediary CA certs (given that LE
only issues TLS, CA and OCSP-signing certificates, and the former have
3 month lifetime).


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-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: CA Public Key Material

[Richard Wang]

You are right, you have done the test same as my test, this don't mean you own 
our intermediate CA root key.

For CSR, yes, our system doesn't validate the CSR self-signature. We think it 
is better to validate it, so we will update our system to validate it soon.

For this test certificate revocation time, yes, it is same as the issuance time.
Our PKI system can let the Revocation Office to choose the revocation time: (1) 
same as the issuance time; (2) the current time. Option (1) is designed for 
invaliding the malware signing code signing certificate instantly if the 
malware signed with timestamp. If we revoke the malware signing code signing 
certificate using Option (2) (the current time), then the signed malware with 
timestamp is still valid even the certificate is revoked. Sure, we can use 
Option (1) to revoke SSL certificate like my test certificate to let nobody 
have the chance to use this test certificate.

Thank you.

Best Regards,

Richard

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+richard=wosign@lists.mozilla.org] On
Behalf Of Andrew Ayer
Sent: Friday, December 16, 2016 12:33 AM
To: Tavis Ormandy 
Cc: dev-security-policy@lists.mozilla.org
Subject: Re: CA Public Key Material

On Wed, 14 Dec 2016 18:46:31 -0800
Tavis Ormandy  wrote:

> Hello, while working on an unrelated problem, I happened to notice
> that this  leaf certificate for
> DNS:test.wgh.cn and DNS: test.ydn.cn has the same RSA public key as
> this trusted root  (and a few others).
>
> test.wgh.cn no longer resolves, but wgh.cn is the personal blog of a
> WoSign employee.

Do you know if test.wgh.cn ever resolved?

> Is it possible key material was accidentally used in a web server and
> removed from a HSM? Maybe there's another explanation, but if there
> was an accident, I assume the root would need to be revoked.

I was just able to obtain the below certificate
(https://crt.sh/?sha256=9d28d7861ef9a0750f7bb95ee9c765d2610fab41fdd7f2142986
d2e8f2a0c7da)
from StartCom for this public key.  StartCom evidently does not validate the
CSR self-signature, and I suspect WoSign didn't either, since they shared so
much code and infrastructure.  (StartCom appears to still share
infrastructure - the validation email for this certificate originated from a
Chinese IP address.)  Validating the CSR self-signature is not required by
the BRs or Mozilla policy.

This is probably more likely than the CA private key being used for a server
cert, although this is WoSign, so who knows?

Regards,
Andrew


___
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

SHA256 for OCSP response issuer hashing

[Roland Shoemaker]

Let's Encrypt is currently considering moving away from using SHA1 as
the issuer subject/public key hashing function in OCSP responses and
using SHA256 instead. Given a little investigation this seems like a
safe move to make but we wanted to check with the community to see if
anyone was aware of legacy (or contemporary) software issues that may
cause us any trouble.

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

Re: Taiwan GRCA Root Renewal Request

[Brian Smith]

Kathleen Wilson  wrote:
> How about the following?

That sounds right to me.

It is important to fix the DoS issue with the path building when there
are many choices for the same subject. SKI/AKI matching only fixes the
DoS issue for benign cases, not malicious cases. Therefore some way of
limiting the resource usage without relying on AKI/SKI matching is
needed.

I'm not sure how to incorporate the possibility of the issue being
fixed into your text.

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

Re: Taiwan GRCA Root Renewal Request

[Kathleen Wilson]

In regards to updating 
https://wiki.mozilla.org/CA:How_to_apply#Root_certificates_with_the_same_subject_and_different_keys
 ?

How about the following? 
~~
The standards allow for two CA certificates to have the same subject names but 
different subject public keys. Please try to avoid this, because it often leads 
to confusion and compatibility issues. When verifying an end-entity certificate 
chaining up to a root certificate with the same subject name as another root 
certificate, if Firefox is aware of the existence of both root certificates, it 
will try all possible orderings of (subject, issuer) pairs until it finds the 
right one. If there are many certificates all with the same subject and issuer 
names, the number of orderings grows exponentially, so it can take a long time 
to evaluate the certificate chains. Therefore, it is better to avoid these 
kinds of situations.

Note that for root certificates, Firefox ignores the authority key identifier 
and subject key identifier extensions.
~~

RE:
> There could be something trying to enforce that root certificates sharing the 
> same distinguished name MUST be owned by the same entity (well, the private 
> key, and all the accompanying things). That should also be true for 
> subordinate CAs (wrt cross-signing), but this has to be enforced by issuing 
> CAs.

Maybe that should be part of the BRs?

Thanks,
Kathleen


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

Re: CA Public Key Material

[Andrew Ayer]

On Wed, 14 Dec 2016 18:46:31 -0800
Tavis Ormandy  wrote:

> Hello, while working on an unrelated problem, I happened to notice
> that this  leaf certificate for
> DNS:test.wgh.cn and DNS: test.ydn.cn has the same RSA public key as
> this trusted root  (and a few others).
> 
> test.wgh.cn no longer resolves, but wgh.cn is the personal blog of a
> WoSign employee.

Do you know if test.wgh.cn ever resolved?

> Is it possible key material was accidentally used in a web server and
> removed from a HSM? Maybe there's another explanation, but if there
> was an accident, I assume the root would need to be revoked.

I was just able to obtain the below certificate
(https://crt.sh/?sha256=9d28d7861ef9a0750f7bb95ee9c765d2610fab41fdd7f2142986d2e8f2a0c7da)
from StartCom for this public key.  StartCom evidently does not
validate the CSR self-signature, and I suspect WoSign didn't either,
since they shared so much code and infrastructure.  (StartCom appears
to still share infrastructure - the validation email for this
certificate originated from a Chinese IP address.)  Validating the CSR
self-signature is not required by the BRs or Mozilla policy.

This is probably more likely than the CA private key being used for a server
cert, although this is WoSign, so who knows?

Regards,
Andrew


-BEGIN CERTIFICATE-
MIIG5jCCBc6gAwIBAgIQIGpPzMoGW7C7rmmIqZ9kQzANBgkqhkiG9w0BAQsFADB4
MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UECxMg
U3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxJjAkBgNVBAMTHVN0YXJ0
Q29tIENsYXNzIDEgRFYgU2VydmVyIENBMB4XDTE2MTIxNTE1MDk1OFoXDTE5MTIx
NTE1MDk1OFowKTELMAkGA1UEBhMCVVMxGjAYBgNVBAMMEXdvZS5jbG91ZHBvcmsu
Y29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxTTDNgZURH21N1vn
WHEpbRdNCkWDtwFCNE8WI9+JIHKlloQtKBfClyjH2ELy6OCy5wiF3wOEEDfflhFI
RVebGw1wUuw6201gpgYzdZAYioMs6egpZeNk+C8d1kWW6VMXRnvccOW+KZTDC6ej
aSnv+ETjptpoVNjlieewuvImzh/WF7RPmvk+nccqFA143MISvA9npWj/WUdSNhqX
+VkwUM/q7tsvXnWR6mHkUZeJkXEqhU1gfPI8isM5zdLB8WEQ6tuW/uXswHD6quW4
OS7n12cFMJ0ZfAt9qJ3tFLiGTJzaCFlxdf6K9vT9+OUW2Bv+ePNDDPXKITbX3cXJ
IMIBnwIDAQABo4IDuTCCA7UwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsG
AQUFBwMCBggrBgEFBQcDATAJBgNVHRMEAjAAMB0GA1UdDgQWBBRHiQGiQRdFHa3K
azO1h7FawsrcoDAfBgNVHSMEGDAWgBTXkU4BxLC/+Mhnk0Sc5zP6rZMMrzBvBggr
BgEFBQcBAQRjMGEwJAYIKwYBBQUHMAh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNv
bTA5BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2Nh
LnNlcnZlcjEuY3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRz
c2wuY29tL3NjYS1zZXJ2ZXIxLmNybDAcBgNVHREEFTATghF3b2UuY2xvdWRwb3Jr
LmNvbTAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wUQYDVR0g
BEowSDAIBgZngQwBAgEwPAYLKwYBBAGBtTcBAgUwLTArBggrBgEFBQcCARYfaHR0
cHM6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTCCAfYGCisGAQQB1nkCBAIEggHm
BIIB4gHgAHcANLtq1sPfnAPuqKSZ/3iRSGydXlysktAfe/0bzhnbSO8AAAFZAyfn
LwAABAMASDBGAiEAizl+ig1kxjDMvajjTETY4vZAClhCU8s8Vwg7RmP09TcCIQD8
93dQS2qtmHFvN+NczhmCpc9Z1BUQ4KzvZ3pSzqmb3gB2AO5Lvbd1zmC64UJpH6vh
nmajD35fsHLYgwDEe4l6qP3LAAABWQMn73kAAAQDAEcwRQIhANqqZfMY4/vYgzvs
tLNdod0VDvlX9h1ODY2o1pvIdligAiAzBYPkftUXDewZrk9Gy8GVl7tARutil7gx
QRuXvIc1FgB2AKS5CZC0GFgUh7sTosxncAo8NZgE+RvfuON3zQ7IDdwQAAABWQMn
69QDAEcwRQIhAKcvpQBHAQDeuPYBbMdrm8CN7Lr/1IWADMxTePAj7F7VAiAD
ZSI6dWiW5urbb1kJ9Yt4Zmk14KVh79r+3xDaeKNZkQB1AEGy3C6J5jzkrxunuym/
aMbe5vnxzAR+MN/647O6JZJjAAABWQMn1kcAAAQDAEYwRAIgKPwcdwjwuJG42GCL
4jJgx31aIrSEz1Mud5a6fwf2a/MCIGRwKTEAoUXV26Q7zgmpoGQsTnlxzUGEdntv
XFz2wpqjMA0GCSqGSIb3DQEBCwUAA4IBAQDMIEYvBw98C3t29ds5prOqaox59PC+
izVi2Ih3PttGtI+NhpnBPQKPoJoUTlshHW4dGo+F8tQScEW1DqjUtmP3vAIfsR5/
hghT+NTBc7rgvG/5xLd/KWZ27zjiZFbZKCL25s6BJLARZnWDoS45cXWMoVc7oZrW
AsYsNld1NiScjUvHzbwqTZvFqx3C+Q4jrXsRgavT6oNpz3frBJROcXADiNoSpuTS
n75BDqk2w3aUZXgrUOCpKGjU/7SELJ6J7U7kXvBJvnGd2d3UpCFZznnDzVs6mO0V
BuP/ZTikYP9KkyhJ17uXJHPeQPyPwGTi3FhrO5dpj7/pey73OJuO7Tp6
-END CERTIFICATE-
-BEGIN CERTIFICATE-
MIIF5TCCA82gAwIBAgIQal3D5TtOT9B7aR6l/OxkazANBgkqhkiG9w0BAQsFADB9
MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi
U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3Rh
cnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTUxMjE2MDEwMDA1WhcN
MzAxMjE2MDEwMDA1WjB4MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g
THRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkx
JjAkBgNVBAMTHVN0YXJ0Q29tIENsYXNzIDEgRFYgU2VydmVyIENBMIIBIjANBgkq
hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2uz0qohni7BLYmaWv8lEaObCK0ygM86s
eeN2w9FW4HWvQbQKRYDvy43kFuMmFD4RHkHn1Mk7sijXkJ/F8NH+5Tjbins7tFIC
ZXd+Qe2ODCMcWbOLoYB54sM514tsZk6m3M4lZi3gmT7ISFiNdKpf/C3dZwasWea+
dbLpwQWZEcM6oCXmW/6L3kwQAhC0GhJm2rBVrYEDvZq1EK3Bv+g5gAW8DVfusUai
oyW0wfQdnKtOLv1M4rtezrKtE8T5tjyeKvFqMX93+LYVlT8Vs+sD12s3ncldqEDL
U89IiBjg6FsbLfM2Ket/3RbfvggfQMPQshipdhrZL8q10jibTlViGQIDAQABo4IB
ZDCCAWAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEF
BQcDATASBgNVHRMBAf8ECDAGAQH/AgEAMDIGA1UdHwQrMCkwJ6AloCOGIWh0dHA6
Ly9jcmwuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDBmBggrBgEFBQcBAQRaMFgwJAYI
KwYBBQUHMAh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTAwBggrBgEFBQcwAoYk

Re: CA Public Key Material

[Rob Stradling]

On 15/12/16 02:46, Tavis Ormandy wrote:

Hello, while working on an unrelated problem, I happened to notice that this
 leaf certificate for DNS:test.wgh.cn and DNS:
test.ydn.cn has the same RSA public key as this trusted root
 (and a few others).

test.wgh.cn no longer resolves, but wgh.cn is the personal blog of a WoSign
employee.

Is it possible key material was accidentally used in a web server and
removed from a HSM? Maybe there's another explanation, but if there was an
accident, I assume the root would need to be revoked.

I'm having trouble finding any observatory/census logs from this time
period to check, can anyone help?


Hi Tavis.

There are lots of links here: https://scans.io/

I took a brief look at https://scans.io/study/sonar.ssl and did not find 
the SHA-1 hash of the test.wgh.cn cert (https://crt.sh/?id=30316154) in 
either of the two logs dated soonest after that cert's notBefore date:

https://scans.io/data/rapid7/sonar.ssl/20150209/20150209_hosts.gz
https://scans.io/data/rapid7/sonar.ssl/20150216/20150216_hosts.gz

That cert has been revoked, but the (presumably backdated) revocation 
date in the CRL matches the cert's notBefore date:

Serial Number: 6E58BF31CFAD4AB20071C26EA9662DA5
Revocation Date: Feb  4 06:47:22 2015 GMT

BTW, https://crt.sh/?id=9329287 (360 EV Server CA G2) is an intermediate 
certificate, not a trusted root.


--
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: CA Public Key Material

[Tom]

On December 15, 2016 10:46:31 AM GMT+08:00, Tavis Ormandy  
wrote:
>test.wgh.cn no longer resolves, but wgh.cn is the personal blog of a
>WoSign employee.
Uh... It is blog of Wosign CEO Wang Gaohua(aka Richard Wang).
>Is it possible key material was accidentally used in a web server and
>removed from a HSM? Maybe there's another explanation, but if there was
>an
>accident, I assume the root would need to be revoked.
Maybe he can explain.
cc rich...@wosign.com


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

Re: Audit Archiving in CCADB

[Nick Lamb]

Thanks once again for this work Kathleen,

On Wednesday, 14 December 2016 23:12:51 UTC, Kathleen Wilson  wrote:
> 1) Salesforce (in cloud) is using the default Java root store, which is 
> smaller than Mozilla's root store. This accounts for the 
> "sun.security.validator.ValidatorException: PKIX path building failed:" 
> errors.
> We're not yet sure how to tell the Java program in the Salesforce cloud to 
> use a different root store, so please point me in the right direction

I believe the Java system property javax.net.ssl.trustStore (please verify 
spelling before using) points to a Java Keystore format list of trusted CA 
certificates which will be used for default SSL connections.

I am responsible for some code that manipulates this programatically for our 
non-public HTTPS-based APIs but the hint above should be enough for a Mozilla 
person or Salesforce expert to get it working without the bureaucracy of 
releasing that code.
___
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.

[Percy]

On Wednesday, December 14, 2016 at 8:29:24 PM UTC-8, zbw...@gmail.com wrote:
> 在 2016年12月15日星期四 UTC+8上午9:53:29，Percy写道：
> > lslqtz,
> > Could you host a subdomain say wosign.loliwiki.org with this cert? So we 
> > can test the blocking is functioning correctly.
> 
> I was pulled into the black list.

What do you mean? Are you the original poster?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy