-
Notifications
You must be signed in to change notification settings - Fork 171
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
OpenSSL::X509::Name.to_s generates ASCII-8BIT strings and double quotes UTF-8 #26
Comments
I would recommend against all of the suggestions in this proposal. Or rather, I think it's okay to extend the current API with new methods that enable this functionality, but the proposed approach will break many things. The subject (i.e. subject CN) and associated SANs are represented in certificates as IDNA names encoded in punycode. For purposes of certificate verification, verification APIs and things that interact with them need to also work in ASCII-8BIT/BINARY-clean punycode. I say this as the person who fixed RFC-6125 IDNA compliance for this library 1. An API which decodes punycode and provides a UTF-8 representation would be nice, but I would argue it MUST be implemented as an extension to the current API or it will break everything which is already capable of working with IDNA names which expects they're encoded in punycode. I think I can safely say this extends to anything which interoperates with DNS, a.k.a. practically everything that supports IDNA in Ruby today. |
It's a shame I assume that swapping the current behavior to a new method e.g. |
I'd suggest something like |
Sounds acceptable. Following with the idiot use case, I'd have figured that out as soon as I saw the escaping and looked around. Would it make sense to have a dedicated |
@tarcieri, there is no IDNA or punycode involved here, and noone is asking that anything related to that should be done. What we have above is a subject field containing non ASCII characters in UTF8STRING objects. See ASN.1 dump extract:
|
@adamel oh sorry, I misunderstood... I was talking about SAN values. Interpreting the subject name and additional fields as UTF-8 is correct per RFC 4630: |
The existing #to_s does not interact well with distinguished names containing multi-byte UTF-8 characters since the OpenSSL function X509_NAME_print_ex() escapes bytes with MSB set by default. Unfortunately we can't fix it without breaking backwards compatibility. It takes options as a bit field that is directly passed to X509_NAME_print_ex(). Let's add a new method instead. Fixes: ruby#26
#143 adds OpenSSL::X509::Name#to_utf8. |
The existing #to_s does not interact well with distinguished names containing multi-byte UTF-8 characters since the OpenSSL function X509_NAME_print_ex() escapes bytes with MSB set by default. Unfortunately we can't fix it without breaking backwards compatibility. It takes options as a bit field that is directly passed to X509_NAME_print_ex(). Let's add a new method instead. Fixes: ruby#26
Nice. For those stuck with older versions the following can be be used as a workaround:
|
Given a certificate with non-ASCII characters in subject I would expect the subject when converted to a string via
.to_s
would return a UTF-8 (or other appropriately encoded) string.What I get instead is an
ASCII-8BIT
encoding string with the UTF-8 characters double encoded.Digging through the ruby openssl code, I see that if
.to_s
is called with an integer flag, it actually callsX509_NAME_print_ex()
.The docs say I should use
XN_FLAG_ONELINE & ~ASN1_STRFLGS_ESC_MSB
to get UTF-8 (as an example). But I couldn't findASN1_STRFLGS_ESC_MSB
in the ruby OpenSSL library.So I'd say there was two bugs:
.to_s
with no arguments should return a properly encoded string without escaped UTF-8 characters.ASN1_STRFLGS
constants are missing.Here is some ruby code to help show the problem:
The text was updated successfully, but these errors were encountered: