Bouncy Castle 1.79 cannot process thisUpdate field according to RFC5280
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").
@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?
@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 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 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" ;-)
I can still parse the time using Bouncy Castle 1.80.
Hello, developer. It's been over a month since it was opened. Any results?
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.
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?