Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Does the string type cause aborted works as intended? #4044

Open
x509-name-testing opened this issue May 7, 2024 · 2 comments
Open

Does the string type cause aborted works as intended? #4044

x509-name-testing opened this issue May 7, 2024 · 2 comments

Comments

@x509-name-testing
Copy link

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.

@randombit
Copy link
Owner

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
Copy link
Author

x509-name-testing commented May 7, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants