bc-java icon indicating copy to clipboard operation
bc-java copied to clipboard

Bouncy Castle 1.79 cannot process thisUpdate field according to RFC5280

Open onepeople158 opened this issue 11 months ago • 8 comments

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

onepeople158 avatar Feb 05 '25 13:02 onepeople158

@onepeople158 why was this ticket closed? I would like to assign a label but I do not understand whether you rejected your question or whether it was a bug and it was fixed somehow without the PR being linked to this issue?

winfriedgerlach avatar Feb 23 '25 19:02 winfriedgerlach

@onepeople158 why was this ticket closed? I would like to assign a label but I do not understand whether you rejected your question or whether it was a bug and it was fixed somehow without the PR being linked to this issue?

Hello, I accidentally clicked the wrong button earlier, but now I've reopened the report.

onepeople158 avatar Feb 24 '25 01:02 onepeople158

@onepeople158 why was this ticket closed? I would like to assign a label but I do not understand whether you rejected your question or whether it was a bug and it was fixed somehow without the PR being linked to this issue?

Hello Developer, this report has been reopened. Could you please assign a label?

onepeople158 avatar Mar 04 '25 01:03 onepeople158

@onepeople158 sorry, I do not feel confident enough to classify this as "bug"; let's wait for a comment from a developer, I am just the "label janitor" ;-)

winfriedgerlach avatar Mar 04 '25 08:03 winfriedgerlach

I can still parse the time using Bouncy Castle 1.80.

Image

onepeople158 avatar Mar 11 '25 13:03 onepeople158

Hello, developer. It's been over a month since it was opened. Any results?

onepeople158 avatar Mar 24 '25 08:03 onepeople158

We would consider it a bug if we were generating non-compliant times.

We cannot suddenly start enforcing this restriction when parsing, since we don't know the impact on existing users and extant PKIX data (CRLs, but also certificates, OCSP, TSP, etc.).

If it is a concern for you to enforce this, it would probably have to be added subject to a runtime property (or multiple properties for the different high-level types), preserving current behaviour by default.

To move towards enforcing by default would require collection/analysis of real-world data e.g. in the case of certificates, the Certificate Transparency logs.

peterdettman avatar Mar 24 '25 08:03 peterdettman

We would consider it a bug if we were generating non-compliant times.

We cannot suddenly start enforcing this restriction when parsing, since we don't know the impact on existing users and extant PKIX data (CRLs, but also certificates, OCSP, TSP, etc.).

If it is a concern for you to enforce this, it would probably have to be added subject to a runtime property (or multiple properties for the different high-level types), preserving current behaviour by default.

To move towards enforcing by default would require collection/analysis of real-world data e.g. in the case of certificates, the Certificate Transparency logs.

Hello, developer. However, if an incorrect CRL file is accepted, could it also pose a security risk?

onepeople158 avatar Mar 24 '25 09:03 onepeople158