-
Bug
-
Resolution: Fixed
-
P4
-
1.4.0
-
None
-
beta2
-
generic
-
generic
sun.security.x509.X509CRLImpl (and therefore our implementation of CertificateFactory.generateCRL) can't parse a CRL that omits the nextUpdate, revokedCertificates, and crlExtensions fields. Instead, its constructor throws a CRLException with a message of "Parsing error: out of data".
The nextUpdate, revokedCertificates, and crlExtensions fields are OPTIONAL, according to X.509(2000) and X.509(1997). RFC 2459 requires that the nextUpdate field be included in all CRLs, but some CAs comply with X.509 and not the PKIX profile. It's easy to support parsing CRLs that omit these fields and the X509CRLImpl class should do so. Our PKIX CertPathBuilder and CertPathValidator implementations, on the other hand, should ignore such CRLs. Trusting a CRL without a nextUpdate field is dangerous. Such a CRL is effectively immortal.
I have attached a CRL that omits the nextUpdate, revokedCertificates, and crlExtensions fields, a CRL that contains those fields, and code to dump a CRL. The dump code can be used to demostrate the problem and its fix.
The nextUpdate, revokedCertificates, and crlExtensions fields are OPTIONAL, according to X.509(2000) and X.509(1997). RFC 2459 requires that the nextUpdate field be included in all CRLs, but some CAs comply with X.509 and not the PKIX profile. It's easy to support parsing CRLs that omit these fields and the X509CRLImpl class should do so. Our PKIX CertPathBuilder and CertPathValidator implementations, on the other hand, should ignore such CRLs. Trusting a CRL without a nextUpdate field is dangerous. Such a CRL is effectively immortal.
I have attached a CRL that omits the nextUpdate, revokedCertificates, and crlExtensions fields, a CRL that contains those fields, and code to dump a CRL. The dump code can be used to demostrate the problem and its fix.