Hi Lev,
I believe that this kind of functionality could be implemented on top of the existing verify-with-callback API `mbedtls_x509_crt_verify_with_cb()`. More precisely, you can enable `MBEDTLS_X509_ALLOW_UNSUPPORTED_CRITICAL_EXTENSION` to ignore unknown extensions initially, and then chekc them yourself in the verification callback by manually traversing `mbedtls_x509_crt::v3_ext`. If you detect an extension you cannot make sense of and which is marked critical, you can modify the verification flags.
Would that work for you, in principle? Note, though, that this would work at the level of verification, not parsing, which might or might not be acceptable.
In this regard you might also be interested in knowing about a significant rewrite of CRT parsing on the `baremetal` branch. The main difference is that the X.509 CRT structure has been stripped down to no longer make use of dynamically allocated memory but instead only provide pointers to the various fields in the certificate. In the case of dynamic-length fields such as the Subject or Issuer names, but also the extension list, inspection shall be done through a newline introduced ASN.1 parsing function
int mbedtls_asn1_traverse_sequence_of( unsigned char **p, const unsigned char *end, uint8_t tag_must_mask, uint8_t tag_must_val, uint8_t tag_may_mask, uint8_t tag_may_val, int (*cb)( void *ctx, int tag, unsigned char* start, size_t len ), void *ctx );
https://github.com/ARMmbed/mbedtls/blob/baremetal/include/mbedtls/asn1.h#L36...
This function traverses an ASN.1 sequence and triggers a callback for each item found. This functionality could be used to perform the extension traversal in the verification callback or directly after parsing.
Which extensions are you interested in, particularly, by the way? If it is a standardized extension, feel free to add support for it under a new compile-time feature flag and file a PR to add it.
Cheers, Hanno ________________________________ From: mbed-tls mbed-tls-bounces@lists.trustedfirmware.org on behalf of Lev Stipakov via mbed-tls mbed-tls@lists.trustedfirmware.org Sent: Friday, April 3, 2020 8:32 AM To: mbed-tls@lists.trustedfirmware.org mbed-tls@lists.trustedfirmware.org Subject: Re: [mbed-tls] Allowing unsupported extensions in X.509 certificates
Hi,
I am not too much into mbedTLS design and not sure if this would make sense, but what about if we introduce an API to let client decide, what to do with unknown extensions?
Let's provide a way for a client to specify a callback
typedef int (*mbedtls_x509_crt_unsupported_extension_cb_t)( const mbedtls_asn1_buf *oid );
which could be an argument to a new method
int mbedtls_x509_crt_parse_with_ext_cb( mbedtls_x509_crt *chain, const unsigned char *buf, size_t buflen,
mbedtls_x509_crt_unsupported_extension_cb_t f_ext_cb );
which is called when parser encounters unsupported extension:
/* * Detect supported extensions */ ret = mbedtls_oid_get_x509_ext_type( &extn_oid, &ext_type ); if( ret != 0 ) { /* No parser found, skip extension */ *p = end_ext_octet;
if( is_critical ) { /* Data is marked as critical: ask client what to do */ if( f_ext_cb != NULL ) { ret = f_ext_cb( &extn_oid ); }
/* Client is OK with unsupported critical extension, continue */ if( ret == 0 ) continue;
return( MBEDTLS_ERR_X509_INVALID_EXTENSIONS + MBEDTLS_ERR_ASN1_UNEXPECTED_TAG ); }
continue; }
This would allow us to deprecate MBEDTLS_X509_ALLOW_UNSUPPORTED_CRITICAL_EXTENSION - those clients which want to allow all extensions could pass a callback which always returns 0.
What do you think?
-- -Lev -- mbed-tls mailing list mbed-tls@lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.