Does the string type cause aborted works as intended?

[x509-name-testing]

Hi there,

I found that the Botan will return Aborted (core dump) but not verification failed when using Botan::x509_path_validate() if the input certificate chain is not a desired string type/has an encoding error.
For example, if matching CN=aa to CN=<graphicString>aa, the echo would be
"terminate called after throwing an instance of 'Botan::Invalid_Argument'
Unknown string type";
and if the CN=aa match CN=<universalString>aa(0x6161) (malformed), the echo would be
"terminate called after throwing an instance of 'Botan::Decoding_Error'
CERTIFICATE decoding failed with Invalid length for UCS-4 string".
Both of the above two examples will abort with a core dumped.

Question: Does the (crash) behavior work as intended?

Many thanks and looking forward to your reply.

[Jack Lloyd]

I do not understand why you would characterize an (apparently uncaught) exception during certificate parsing as a crash.

Rejecting a GraphicsString CN at parsing time seems entirely appropriate as RFC 5280's DirectoryString and X520CommonName types do not include this string type. Thus the certificate could not possibly be valid.

Likewise outright rejecting at parse time a certificate with an invalid UCS-4 encoding seems appropriate since likewise the certificate cannot possibly be valid.

[x509-name-testing]

Thanks for your reply.

For the GraphicsString CN, I concur with your point. I have previously used CN=<utf8>aa to match CN=<ia5>aa (out of DirectoryString scope), and it was successful. So I used to misunderstand that Botan might not perform strict string-type checking.

And for the UniversalString case, I think I understand your point. Thanks very much. I found some other libraries will reject (return invalid) while Botan will throw an exception (abouted), so I ask the question out of curiosity.

It would indeed be great if everything worked as intended. And many thanks for your reply.