Skip to content

Bouncy Castle 1.79 cannot process thisUpdate field according to RFC5280 #1986

@onepeople158

Description

@onepeople158

Main content:
The RFC standard for X.509 CRLs restricts the thisUpdate field to only two formats, namely UTCTime (YYMMDDHHMMSSZ) and GeneralizedTime (YYYYMMDDHHMMSSZ) in ASN.1 representation, which are 13 and 15 characters wide, respectively. However, Bouncy Castle 1.79 accepts CRL with a thisUpdate field of length 11 ("0103010100Z").The openssl cannot print the information of this CRL file.

Version of Bouncy Castle used:

(bcprov-jdk18on-1.79.jar:bcpkix-jdk18on-1.79.jar)

Computer system:
Ubuntu

How reproducible:

import java.io.InputStream;
import java.io.FileInputStream;
import org.bouncycastle.asn1.x509.CertificateList;
import org.bouncycastle.cert.X509CRLHolder;

public class CRLParserExample3 {
    public static void main(String[] args) throws Exception{
            InputStream inputStream = new FileInputStream("crl_file.der");

            X509CRLHolder crlHolder = new X509CRLHolder(inputStream);
            
            System.out.println("Issuer: " + crlHolder.getIssuer());
            System.out.println("ThisUpdate: " + crlHolder.getThisUpdate());

        } 
}

Actual results:
The CRL is trusted and printed

Expected results:
The RFC standard for X.509 CRLs limits the thisUpdate field to only two formats: UTCTime (YYMMDDHHMMSSZ) and GeneralizedTime (YYYYMMDDHHMMSSZ) in ASN.1 encoding, which are 13 and 15 characters wide, respectively. Therefore, it should reject a CRL file with a thisUpdate field length of 11 (e.g., "0103010100Z").

test.zip

Metadata

Metadata

Assignees

No one assigned

    Labels

    support requestCommunity assistance requested

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions