966350 - Distrust a pb.com certificate that does not comply with the baseline requirements

Status: RESOLVED FIXED

(NSS :: CA Certificates Code, task, P1)

Description

[Rick Andrews]

User Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; MS-RTC LM 8)

Steps to reproduce:

At the end of 2013, Symantec issued a cert to one of its customers that did not comply with several provisions of the CA/Browser Forum Baseline Requirements. We did this knowingly because if we had not, the customer would have experienced a significant loss of business. In addition, Symantec believed that this certificate posed very little or no risk to browser users. I don't have permission to reveal the name of the customer, but they are a major maker of devices that communicate over the Internet to the company's web server. The certificate is not intended to be used by a browser. We exhausted all other possible technical options before taking this step.

Due to the limitations of their devices, they needed us to reissue a certificate directly off one of our 1024-bit roots, with a 1024-bit key in the end-entity cert, and with a Valid From backdated to 2010. Here are the details you will need if you wish to blacklist this certificate in NSS:
  
Issuer = OU = Equifax Secure Certificate Authority, O = Equifax, C = US
CDP = http://crl.geotrust.com/crls/secureca.crl
AKI = 48 e6 68 f9 2b d2 b2 95 d7 47 d8 23 20 10 4f 33 98 90 9f d4
EKU = serverAuth, clientAuth
Serial Number = ‎15 79 14
SKI = e3 79 a4 fd fb 77 0f bb bb 5d 95 11 7b c0 54 7e 0e 90 1c bb
KU = Digital Signature, Non-Repudiation, Key Encipherment, Data Encipherment (f0)
Thumbprint (SHA-1) = 30 f1 82 ca 1a 5e 4e 4f f3 6e d0 e6 38 18 b8 b9 41 cb 5f 8c

Valid From = ‎Monday, ‎February ‎01, ‎2010 6:54:04 AM
Valid To = ‎Monday, ‎September ‎29, ‎2014 4:00:00 PM

Comment 1

[Kaspar]

(In reply to Rick Andrews from comment #0)
> I don't have permission to reveal the name of the customer, but they
> are a major maker of devices that communicate over the Internet to the
> company's web server.

Oh my, why do CAs believe they can keep such things secret? It didn't work in the Trustwave case (bug 724929 comment 88), and doesn't in this case, either. I'm under no NDA, do not have any insider knowledge, but here we go: it's Pitney Bowes.

Specifically, it's the following certificate for *.pb.com:

-----BEGIN CERTIFICATE-----
MIIDUjCCArugAwIBAgIDFXkUMA0GCSqGSIb3DQEBBQUAME4xCzAJBgNVBAYTAlVT
MRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0
aWZpY2F0ZSBBdXRob3JpdHkwHhcNMTAwMjAxMTQ1NDA0WhcNMTQwOTMwMDAwMDAw
WjBwMQswCQYDVQQGEwJVUzEUMBIGA1UECBMLQ29ubmVjdGljdXQxEDAOBgNVBAcT
B0RhbmJ1cnkxFTATBgNVBAoTDFBpdG5leSBCb3dlczEPMA0GA1UECxMGTWV0ZXJz
MREwDwYDVQQDDAgqLnBiLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA
w6IuzcPeE723idfqifJshU3sa06s/EhL2QRFHkh3VETh2MJpAiHG3F6RALelCnc9
xfp6ankzVFv4FelJzjslt80Ug7DHAcGeETnKId2yEo0eGYHmokRA9XUdUQxJYqmy
U2CgyegSpwjbaWpqHoWRmhypgPamhfHVTOIoRTVMBOsCAwEAAaOCARowggEWMB8G
A1UdIwQYMBaAFEjmaPkr0rKV10fYIyAQTzOYkJ/UMA4GA1UdDwEB/wQEAwIE8DAd
BgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwGwYDVR0RBBQwEoIIKi5wYi5j
b22CBnBiLmNvbTA6BgNVHR8EMzAxMC+gLaArhilodHRwOi8vY3JsLmdlb3RydXN0
LmNvbS9jcmxzL3NlY3VyZWNhLmNybDAdBgNVHQ4EFgQU43mk/ft3D7u7XZURe8BU
fg6QHLswTAYDVR0gBEUwQzBBBgpghkgBhvhFAQc2MDMwMQYIKwYBBQUHAgEWJWh0
dHA6Ly93d3cuZ2VvdHJ1c3QuY29tL3Jlc291cmNlcy9jcHMwDQYJKoZIhvcNAQEF
BQADgYEAVfZxkAkvtlL55G2nrD1N9ec0BcJ9/WOwnK+6Tf9egSl0CBFTxA/5iJ9A
s98Gx8An8qgHXypp49Aru0NeKFLZotcE9tTZvc1ooYTjG6tJQbu2NMEfYEbSSdgL
4T+0dsJIw6/gBIUKNgHdcgbnvyi2lx4E045ua7cQ/spi4E4reOg=
-----END CERTIFICATE-----

which is a replacement for this certificate which has expired on 31 December 2013:

-----BEGIN CERTIFICATE-----
MIIDAjCCAmugAwIBAgIDFN1TMA0GCSqGSIb3DQEBBQUAME4xCzAJBgNVBAYTAlVT
MRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0
aWZpY2F0ZSBBdXRob3JpdHkwHhcNMTAwMjAxMTQ1NDA0WhcNMTMxMjMxMTQ1NDA0
WjBwMQswCQYDVQQGEwJVUzEUMBIGA1UECBMLQ29ubmVjdGljdXQxEDAOBgNVBAcT
B0RhbmJ1cnkxFTATBgNVBAoTDFBpdG5leSBCb3dlczEPMA0GA1UECxMGTWV0ZXJz
MREwDwYDVQQDDAgqLnBiLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA
w6IuzcPeE723idfqifJshU3sa06s/EhL2QRFHkh3VETh2MJpAiHG3F6RALelCnc9
xfp6ankzVFv4FelJzjslt80Ug7DHAcGeETnKId2yEo0eGYHmokRA9XUdUQxJYqmy
U2CgyegSpwjbaWpqHoWRmhypgPamhfHVTOIoRTVMBOsCAwEAAaOByzCByDAfBgNV
HSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf1DAdBgNVHQ4EFgQU43mk/ft3D7u7
XZURe8BUfg6QHLswDgYDVR0PAQH/BAQDAgTwMB0GA1UdJQQWMBQGCCsGAQUFBwMB
BggrBgEFBQcDAjA6BgNVHR8EMzAxMC+gLaArhilodHRwOi8vY3JsLmdlb3RydXN0
LmNvbS9jcmxzL3NlY3VyZWNhLmNybDAbBgNVHREEFDASgggqLnBiLmNvbYIGcGIu
Y29tMA0GCSqGSIb3DQEBBQUAA4GBAAKg+JCZaTxjteSehMWrKorovivKujXy7kSm
Gqv6zF2LRKekSpnN9Tkc9tnOuiKmKDzeKtWKa1V/0ah/RsvwcG9BAND5XVeLYr0d
qSX1akFzv1OhWJVLXWUy/vpxUWr7dIuHZbLLt+jV2Quw7AoU/VBBfVKNNzpsBPY7
M5rbfMhx
-----END CERTIFICATE-----

Other differences besides the serial number and the notAfter field in detail:

- the new cert also has a SAN extension (*.pb.com, pb.com)

- the new cert includes a certificatePolicies extension with the 2.16.840.1.113733.1.7.54 OID, for which the GeoTrust CPS v1.1.13 ([1], November 7, 2013) states: "Symantec has assigned a reserved OID value for asserting conformance with the current version of the CA/Browser Forum Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates. This OID value is reserved for use by any brand of Symantec CA as a means of asserting compliance with these CABF Requirements and as such does not distinguish a particular brand or class of Certificate."

[1] http://www.geotrust.com/resources/cps/pdfs/GeoTrustCPS-Version1.1.13.pdf

Comment 2

[Gervase Markham [:gerv]]

Kaspar: are you saying the new cert asserts a "BR Compliance" OID?

Rick: is that correct? If so, given that the entire point of the new cert involves it not being BR compliant, how did that happen?

Gerv

Comment 3

[Gervase Markham [:gerv]]

Hi Camilo,

Brian assigned the other one of these to you, so I'm assigning this one similarly. Sorry if that's wrong :-)

Gerv

Comment 4

[Camilo Viecco (:cviecco)]

Gerv that is fine. Expected release 3.16

Comment 5

[Camilo Viecco (:cviecco)]

Attachment: patch-bug-966350

Comment 6

[Kai Engert (:KaiE:)]

I propose to use a different comment for the distrust record. We aren't distrusting pb.com in general. For example the comment could say "Distrust wrongly issued pb.com certificate".

Comment 7

[Kai Engert (:KaiE:)]

(In reply to Kaspar Brand from comment #1)
> - the new cert also has a SAN extension (*.pb.com, pb.com)

It seems that isn't a difference, the old one had the same SAN extension, it's just that the order of extensions in the certificate has changed.

Comment 8

[Kai Engert (:KaiE:)]

Comment on attachment 8378340 [details] [diff] [review]
patch-bug-966350

r-, but only because of the comment.

Otherwise the patch is correct. Please create a new patch using a different label (the different should be visible in both the comment and the actual label).

Comment 9

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

(In reply to Kai Engert (:kaie) from comment #6)
> I propose to use a different comment for the distrust record. We aren't
> distrusting pb.com in general. For example the comment could say "Distrust
> wrongly issued pb.com certificate".

Camilo asked me to clarify what to change about the patch. I think he missed Kai's comment that I quoted above. The only thing that needs to be changed about the patch is the comment. Saying "Distrust pb.com" could be read to mean that we're going to distrust all or several pb.com certificates. I don't think "wrongly issued" is the right characterization either though; in the source code, we should avoid making opinionated statements like that unnecessarily. Instead, I suggest "Distrust a pb.com certificate that does not comply with the baseline requirements."

Comment 10

[Kai Engert (:KaiE:)]

(In reply to comment #9)
> I suggest
>   "Distrust a pb.com certificate that does not comply with the baseline requirements."

This comment sounds good to me.

Comment 11

[Kai Engert (:KaiE:)]

Attachment: text dump of certificate to blacklist

This is a text dump of the certificate that Kaspar provided in comment 1, and which appears to match the certificate mentioned by Symantec in the initial comment.

Comment 12

[Camilo Viecco (:cviecco)]

Attachment: patch-bug-966350

Comment 13

[Kai Engert (:KaiE:)]

Comment on attachment 8379075 [details] [diff] [review]
patch-bug-966350

r=kaie

Comment 14

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

http://hg.mozilla.org/projects/nss/rev/352e4b1d4ccd

Comment 15

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

> http://hg.mozilla.org/projects/nss/rev/352e4b1d4ccd

I landed that on the NSS_3_15_5 branch mistakenly. Backed out:
http://hg.mozilla.org/projects/nss/rev/d2b4a1dc67e9

Re-landed on the default branch:
http://hg.mozilla.org/projects/nss/rev/36b7cd279e8d

Comment 16

[Rob Stradling]

Brian,

Please would you remove the unnecessary double-quote at the end of this line...

CKA_LABEL UTF8 "Distrust a pb.com certificate that does not comply with the baseline requirements.""

...and from the corresponding comment?

Thanks.

Comment 17

[Wan-Teh Chang]

Rob: I made the change you suggested:
https://hg.mozilla.org/projects/nss/rev/17ea3e0f798f

Is the change correct?

Comment 18

[Rob Stradling]

(In reply to Wan-Teh Chang from comment #17)
> Rob: I made the change you suggested:
> https://hg.mozilla.org/projects/nss/rev/17ea3e0f798f

Thanks Wan-Teh.

> Is the change correct?

Yes.