322070 - CRL import fails if CRL is not binary DER

Status: RESOLVED INCOMPLETE

(Core :: Security: PSM, defect)

Description

[Ken Johanson]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6

Some CRLs have extraneous whitespace bytes in their head/tail, due to the way some webservers (response filters) dynamically prepend/append data to their response. Other browsers handle these CRLs gracefully; NSS throws a 'ffffe009' error.

Reproducible: Always

Steps to Reproduce:
1. Load http://certificates.starfieldtech.com/repository/root.crl



Note, I have no affiliation with godaddy.com, except as a customer.

Comment 1

[Nelson Bolyard (seldom reads bugmail)]

The above URL returns to me the following results (including http headers)

HTTP/1.1 200 OK
Date: Mon, 02 Jan 2006 03:40:00 GMT
Server: Apache
Last-Modified: Thu, 08 Dec 2005 15:34:24 GMT
ETag: "83c1f-241-d9a000"
Accept-Ranges: bytes
Content-Length: 577
P3P: CP="IDC DSP COR LAW CUR ADM DEV TAI PSA PSD IVA IVD HIS OUR SAM PUB LEG UNI COM NAV STA"
Connection: close
Content-Type: application/x-pkcs7-crl

-----BEGIN X509 CRL-----
MIIBgTCB6zANBgkqhkiG9w0BAQUFADCBuzEkMCIGA1UEBxMbVmFsaUNlcnQgVmFs
aWRhdGlvbiBOZXR3b3JrMRcwFQYDVQQKEw5WYWxpQ2VydCwgSW5jLjE1MDMGA1UE
CxMsVmFsaUNlcnQgQ2xhc3MgMiBQb2xpY3kgVmFsaWRhdGlvbiBBdXRob3JpdHkx
ITAfBgNVBAMTGGh0dHA6Ly93d3cudmFsaWNlcnQuY29tLzEgMB4GCSqGSIb3DQEJ
ARYRaW5mb0B2YWxpY2VydC5jb20XDTA1MDEyNzE4MDIyN1oXDTA2MDEyNzE4MDIy
N1owDQYJKoZIhvcNAQEFBQADgYEAMnhxebiiZFDVRtJOkLsGDsR2dttw4EdlIw5k
OajHzMfUXdlxkjP3xfeKFYmelK9L4adqMmri5JHrT/0qdX+esve1TkvYF+TgxJyB
smSB+Nri2qhVRzqKlEyLEk3n8HsQfxYfPPeFV19QNxBJlfPdbugFjdRhtp0H1PUM
oVFZSa8=
-----END X509 CRL-----

Maybe our parser isn't expecting base64? 
or maybe somthing other than "X509 CRL" ?

Comment 2

[Nelson Bolyard (seldom reads bugmail)]

Error ffffe008 is actually error -8183 (displayed as unsigned hex, rather
than as signed decimal).  According to the official list of error numbers,
http://www.mozilla.org/projects/security/pki/nss/ref/ssl/sslerr.html
That is error SEC_ERROR_BAD_DER
Security library: improperly formatted DER-encoded message.

That tells me that mozilla tried to decode it as a binary DER-encoded 
message and failed, because it was BASE64 encoded, not binary.
I don't know if this is the responsibility of NSS or PSM.  

Comment 3

[Julien Pierre]

base64 decoding is PSM's responsibility . There is no base64 decoding of CRLs in NSS libraries. The CRL decoder APIs all take DER as input.

I'm not sure what the Content-type of application/x-pkcs7-crl is supposed to be - binary or ASCII, or either way.

Comment 4

[Nelson Bolyard (seldom reads bugmail)]

The inability to accept a base64 encoded CRL seems to be somewhat inconsistent 
with NSS's ability to import certs as either binary DER or base64 encoded.

I don't know of any official standard definition of the data types that 
should be associated with MIME content types, especially with the content
types that start with application/x- .

Kai, if you agree that this is a PSM bug/RFE, please change it into a PSM bug.
Thanks.

Comment 5

[Kai Engert [:KaiE:]]

> The inability to accept a base64 encoded CRL seems to be somewhat inconsistent 
> with NSS's ability to import certs as either binary DER or base64 encoded.

I agree


> I don't know of any official standard definition of the data types that 
> should be associated with MIME content types, especially with the content
> types that start with application/x- .

As these are not fully defined, I think it's fine to try to be smart.


> Kai, if you agree that this is a PSM bug/RFE, please change it into a PSM bug.

I think it could be either a NSS or a PSM RFE bug.
If you don't like the idea to make NSS smarter, despite the inconsistency, it's ok to change this into a PSM RFE bug.


Note for anybody who is going to work on this: nss/cmd/lib/secutil.c, SECU_ReadDERFromFile already contains some logic to do the conversion.

Comment 6

[spt]

(In reply to Nelson Bolyard (seldom reads bugmail) from comment #4)
> The inability to accept a base64 encoded CRL seems to be somewhat
> inconsistent 
> with NSS's ability to import certs as either binary DER or base64 encoded.
> 
> I don't know of any official standard definition of the data types that 
> should be associated with MIME content types, especially with the content
> types that start with application/x- .
> 
> Kai, if you agree that this is a PSM bug/RFE, please change it into a PSM
> bug.
> Thanks.

This is ancient but the mime type should be application/pkix-crl (See RFC 2585).  Sec 4.2 addresses the encoding considerations.

Comment 7

[Kai Engert [:KaiE:]]

reassign bug owner.
mass-update-kaie-20120918

Comment 8

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

The CRL Manager / Revocation Lists feature was removed.