On Wed, Apr 12, 2023 at 02:31:30AM -0400, Viktor Dukhovni <openssl-users@xxxxxxxxxxxx> wrote: > On Wed, Apr 12, 2023 at 03:20:51PM +1000, raf via openssl-users wrote: > > > Thanks. I thought that might be the case, but I didn't > > know what kind of encoding was appropriate for openssl > > usage. There are different encodings for different > > purposes. My interest in Unicode domain names relates > > to DNS usage where IDNA2008/UTC#46 is useful. But this > > makes sense since it's an email address. > > > > It would be great if openssl performed the necessary > > encoding, especially when it has been instructed (with > > the -utf8 option) to interperet input as UTF-8 (but the > > locale should probably be enough of an indication), and > > to also perform the corresponding decoding on output. I > > think that requiring users to perform the correct > > encoding is asking too much. But maybe expecting > > openssl to include code for encoding and decoding email > > addresses is asking too much. > > > > I have a shell script that will need to decode > > international email addresses in S/MIME certificates, > > and then encode the domain as IDNA2008/UTC#46. > > [ Doing X.509 validation in shell scripts sounds particularly unwise, > Python, or a programming language less prone to code injection > attacks or other serialisation/deserialisation issues would be > a better choice, or even some robust C++ code on top of the OpenSSL > API. ] I don't think I'm (consciously) validating anything. I just need to extract the email address for the purpose of creating SMIMEA DNS records. My script just checks that "openssl x509 -inform pem -in smimecert.pem -noout -purpose" outputs "S/MIME encryption : Yes", and then it scans the output of "openssl x509 -inform pem -in smimecert.pem -noout -text" looking for "emailAddress = ", and then it uses the subsequent email address. And the important stuff above is done in perl, not shell. :-) > This isn't a question of *encoding*, rather addresses with UTF-8 > localparts, or a U-label domain, are stored in a different subtype of > the SAN discriminated union. That's good. > You need to specify a SAN "otherName" of type smtpUtf8Name, rather than > an rfc822Name. With OpenSSL 3.0, you can use "id-on-SmtpUTF8Mailbox" > instead of the numeric OID: > > [extensions] > subjectAltName = @sans > > [sans] > otherName.1 = 1.3.6.1.5.5.7.8.9;FORMAT:UTF8,UTF8String:потребитель@домен.example > > Full support for this in certificate verification requires OpenSSL 3.0. Thanks. Sadly, I don't understand the config file format enough to know how to incorporate this into my existing config file (copied from a howto for S/MIME). which includes "subjectAltName = email:copy". If I just add the above, I get a new error when decrypting the private key. I think I need to finally read my old OpenSSL book, and get/read the new one for 3.0. Then, I might be able to benefit from your suggestion. :-) In the meantime, I might just wait until a user reports that my script isn't working for S/MIME with non-ASCII email addresses (if that ever happens). If they can show me the output of the openssl x509 ... -noout -text command for their certificate, that should be enough for me to fix my script. > -- > Viktor. cheers, raf
