Closed mschulz-at-hilscher closed 11 months ago
When parsing valid CSRs with or without extensions marked as critical, the certificate parsing shall succeed
I don't think that's quite true.
If an extension is critical, and we don't understand it, we shouldn't blindly accept it.
(As otherwise we're pretty much signing random data given to us. The standard says
Conforming CAs MUST support key identifiers (Sections 4.2.1.1 and 4.2.1.2), basic constraints (Section 4.2.1.9), key usage (Section 4.2.1.3), and certificate policies (Section 4.2.1.4) extensions. If the CA issues certificates with an empty sequence for the subject field, the CA MUST support the subject alternative name extension (Section 4.2.1.6).
and this implies that CAs shouldn’t sign things they don’t understand - otherwise CA support for extensions wouldn’t be needed at all, they would just sign whatever they get.)
When parsing valid CSRs with or without extensions marked as critical, the certificate parsing shall succeed
I don't think that's quite true.
If an extension is critical, and we don't understand it, we shouldn't blindly accept it
The alternative would be to implement a mechanism similar to the mbedtls_x509_crt_parse_der_with_ext_cb functions that call a callback function to handle unknown extensions.
However, in the current implementation, no critical extensions are supported at all during CSR parsing. Not even the ones that could be understood by the library. That is a blocker for our applications where we have requirements for marking extensions as critical.
There are even situations where marking extensions as critical are mandatory according to the RFC: "If subject naming information is present only in the subjectAltName extension (e.g., a key bound only to an email address or URI), then the subject name MUST be an empty sequence and the subjectAltName extension MUST be critical."
When parsing valid CSRs with or without extensions marked as critical, the certificate parsing shall succeed
I don't think that's quite true.
If an extension is critical, and we don't understand it, we shouldn't blindly accept it.
(As otherwise we're pretty much signing random data given to us. The standard says
Conforming CAs MUST support key identifiers (Sections 4.2.1.1 and 4.2.1.2), basic constraints (Section 4.2.1.9), key usage (Section 4.2.1.3), and certificate policies (Section 4.2.1.4) extensions. If the CA issues certificates with an empty sequence for the subject field, the CA MUST support the subject alternative name extension (Section 4.2.1.6).
and this implies that CAs shouldn’t sign things they don’t understand - otherwise CA support for extensions wouldn’t be needed at all, they would just sign whatever they get.)
The updated code in #8378 now reports an error in case an unknown critical extension is part of a CSR.
Summary
When using mbedtls_x509_csr_parse_der to parse CSRs that contain extensions that are marked as critical ("Each extension in a certificate is designated as either critical or non-critical.", Section 4.2, RFC5280) with an optional boolean field, the certificate parsing fails with error -0x2562 (MBEDTLS_ERR_X509_INVALID_EXTENSIONS | MBEDTLS_ERR_ASN1_UNEXPECTED_TAG) as the implementation of x509_csr_parse_extensions always expects an octet string to follow the extension ID, ignoring an optionally added boolean indicating criticality of the field.
System information
Mbed TLS version (number or commit id): 3.5.0 Operating system and version: Linux but does not really matter Configuration (if not default, please attach
mbedtls_config.h
): default Compiler and options (if you used a pre-built binary, please indicate how you obtained it): see under "Steps to reproduce" Additional environment information:Expected behavior
When parsing valid CRS with or without extensions marked as critical, the certificate parsing shall succeed.
Actual behavior
Certificate parsing returns -0x2562 (MBEDTLS_ERR_X509_INVALID_EXTENSIONS | MBEDTLS_ERR_ASN1_UNEXPECTED_TAG)
Steps to reproduce
Example CSRs: Without extension marked as critical: 308201203081c802010030413119301706035504030c1053656c66207369676e65642074657374310b300906035504061302444531173015060355040a0c0e41757468437274444220546573743059301306072a8648ce3d020106082a8648ce3d03010703420004e1917dd36f166032917928b272e088f6aa4326eb3690eb0650d37bf97b1abfadff8304026c89564fc1e253c47edc209606de986135807ff2ab5db9135dfd7314a025302306092a864886f70d01090e311630143012060b2b0601040183890c8622020403010101300a06082a8648ce3d040302034700304402205cb201bddb922dd2987facbef22371534ef1b20243008ecae314317b3dae478d02207cd2228b117e4cc5420660eede97eb3f7e1e9541c4f26250585156e0fad6faa5
With extension marked as critical: 308201233081cb02010030413119301706035504030c1053656c66207369676e65642074657374310b300906035504061302444531173015060355040a0c0e41757468437274444220546573743059301306072a8648ce3d020106082a8648ce3d03010703420004c11ebb9951848a436ca2c8a73382f24bbb6c28a92e401d4889b0c361f377b92a8b0497ff2f5a5f6057ae85f704ab1850bef075914f68ed3aeb15a1ff1ebc0dc6a028302606092a864886f70d01090e311930173015060b2b0601040183890c8622020101ff0403010101300a06082a8648ce3d040302034700304402200c4108fd098525993d3fd5b113f0a1ead8750852baf55a2f8e670a22cabc0ba1022034db93a0fcb993912adcf2ea8cb4b66389af30e264d43c0daea03255e45d2ccc
Test programe to be placed as csr_critical_ext.c under programs/x509:
Command to build:
Execution and output:
Additional information
The following patch fixes the problem:
Execution and output: