413379 - Decide what to do with incorrectly encoded cert in nssckbi

Status: RESOLVED FIXED

(CA Program :: CA Certificate Root Program, task)

Description

[Nelson Bolyard (seldom reads bugmail)]

One of the certs now in nssckbi (Mozilla's read-only cert store, a PKCS#11 
module) is incorrectly encoded.  It has an extension that is not encoded 
as defined in RFC 3280.  A decoder that enforces strict adherence to the 
ASN.1 DER encoding rules, such as NSS's "Quick DER" decoder, will not be
able to decode this extension, or will decode it to have a value different
from the one that the cert's creators undoubtedly intended it to have. 
More details about it are given below.

The question is: what should we do with it?  
- keep it as is until it expires?
- remove it now?
- If the CA issues a replacement cert, should we
  - Replace the incorrectly encoded cert with the replacement?
  - Add the replacement to nssckbi, alongside the incorrectly encoded cert?

The cert in question is an intermediate CA certificate, not a root.
It is one of the certificates that was "grandfathered in" to nssckbi.
Its common name is "VeriSign Time Stamping Authority CA". 

The relevant extension is this:
            Name: Authority Information Access
            Method: PKIX Online Certificate Status Protocol
            Location: [6]: {
                "http://ocsp.verisign.com/ocsp/status"
            }

The location has been encoded as "EXPLICIT" when it should be IMPLICIT.
The context dependent tag [6] is constructed, not primitive, (as signified
by the extra curly braces), and contains the explicit DER encoding of an IA5String.  

NSS is able to verify this certificate if OCSP is not enabled.  When OCSP 
is enabled, NSS reports "The location for the certificate status server 
has invalid format."

I have asked Verisign what they intend to do about this certificate.

Given that NSS contains no code for use of a time stamping service, I 
opine that there is an open question about whether this certificate meets 
Mozilla's published policy rule that an included cert must "provide some service relevant to typical users of our software products". 

Once a decision is made about this cert, if further action is needed, this 
bug can be converted into an NSS bug.

Comment 1

[Gervase Markham [:gerv]]

If this certificate is unused, then removing it seems to be a no-brainer. If we ever add code which might need it, or Verisign ever ships a service which means we need it, we can ask them for a valid certificate at that time.

But this is Frank's call, not mine :-)

Gerv

Comment 2

[Nelson Bolyard (seldom reads bugmail)]

Adding my Verisign contact to this bug.

Comment 3

[Julien Pierre]

My preference would be for this cert to be reencoded correctly, and reissued by Verisign.

Comment 4

[Nelson Bolyard (seldom reads bugmail)]

Frank, This is a policy issue and has no other dependencies.  
How can we move this along?

Comment 5

[Kathleen Wilson]

Tony and Rick, Does the"VeriSign Time Stamping Authority CA" root certificate authority need to continue to be included in NSS? If not, shall I add it to the other set of root removals that I am doing (bug #534274)?

If it does need to continue to be included in NSS, then has this encoding issue been resolved?

Comment 6

[Rick Andrews]

Kathleen,

I have limited information on how and where this intermediate (it's not a root) is used. AFAIK, it's used only in Qualcomm BREW code signing. Do you know if nssckbi is used by any Mozilla products that validates signatures on code (code signing clients)? If the answer is no, then I feel pretty safe in saying that you can remove the cert from the store.

Comment 7

[Rick Andrews]

Can someone confirm that this is the cert in question?

-----BEGIN CERTIFICATE-----
MIIDzTCCAzagAwIBAgIQU2GyYK7bcY6nlLMTM/QHCTANBgkqhkiG9w0BAQUFADCB
wTELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTwwOgYDVQQL
EzNDbGFzcyAzIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5
IC0gRzIxOjA4BgNVBAsTMShjKSAxOTk4IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1
dGhvcml6ZWQgdXNlIG9ubHkxHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdv
cmswHhcNMDAwOTI2MDAwMDAwWhcNMTAwOTI1MjM1OTU5WjCBpTEXMBUGA1UEChMO
VmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx
OzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5j
b20vcnBhIChjKTAwMSwwKgYDVQQDEyNWZXJpU2lnbiBUaW1lIFN0YW1waW5nIEF1
dGhvcml0eSBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA0hmdZ8IAIVli
zrQJIkRpivglWtvtDbc2fk7gu5Q+kCWHwmFHKdm9VLhjzCx9abQzNvQ3B5rB3UBU
/OB4naCTuQk9I1F/RMIUdNsKvsvJMDRAmD7Q1yUQgZS9B0+c1lQn3y6ov8uQjI11
S7zi6ESHzeZBCiVu6PQkAsVSD27smHUCAwEAAaOB3zCB3DAPBgNVHRMECDAGAQH/
AgEAMEUGA1UdIAQ+MDwwOgYMYIZIAYb4RQEHFwEDMCowKAYIKwYBBQUHAgEWHGh0
dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwMQYDVR0fBCowKDAmoCSgIoYgaHR0
cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMy5jcmwwCwYDVR0PBAQDAgEGMEIGCCsG
AQUFBwEBBDYwNDAyBggrBgEFBQcwAaYmFiRodHRwOi8vb2NzcC52ZXJpc2lnbi5j
b20vb2NzcC9zdGF0dXMwDQYJKoZIhvcNAQEFBQADgYEAgnBold+2DcIBcBlK0lRW
HqzyRUyHuPU163hLBanInTsZIS5wNEqi9YngFXVF5yg3ADQnKeg3S/LvRJdrF1Ea
w1adPBqK9kpGRjeM+sv1ZFo4aC4cw+9wzrhGBha/937ntag+RaypJXUie28/sJyU
58dzq6wf7iWbwBbtt8pb8BQ=
-----END CERTIFICATE-----

If so, then I believe it can be removed.

Comment 8

[Kaspar]

(In reply to comment #7)
> Can someone confirm that this is the cert in question?

Yes, I can confirm. For the records, its SHA-1 fingerprint is A6:0F:34:C8:62:6C:81:F6:8B:F7:7D:A9:F6:67:58:8A:90:3F:7D:36.

Comment 9

[Kathleen Wilson]

The"VeriSign Time Stamping Authority CA" root certificate has been removed from NSS as per bug #554330. The change is in Firefox 3.6.7.