OpenSSL::X509::Name.to_s generates ASCII-8BIT strings and double quotes UTF-8

[ruby]

OpenSSL::X509::Name.to_s generates ASCII-8BIT strings and double quotes UTF-8

[tarcieri]

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.

[docwhat]

It's a shame .to_s is already being used because it is the expected by idiots (read: me) to "just work" with non-ascii characters.

I assume that swapping the current behavior to a new method e.g. .print_name would break things even if the major number is bumped?

[tarcieri]

I'd suggest something like #to_utf8

[docwhat]

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 .to_something for the use case you had above. In case anyone else like me comes along again and you aren't around to stop them?

[adamel]

@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:

   34:d=3  hl=2 l=  63 cons:    SET               
   36:d=4  hl=2 l=  61 cons:     SEQUENCE          
   38:d=5  hl=2 l=   3 prim:      OBJECT            :commonName
   43:d=5  hl=2 l=  54 prim:      UTF8STRING        :TÜRKTRUST Elektronik Sertifika Hizmet Sağlayıcısı
   99:d=3  hl=2 l=  11 cons:    SET               
  101:d=4  hl=2 l=   9 cons:     SEQUENCE          
  103:d=5  hl=2 l=   3 prim:      OBJECT            :countryName
  108:d=5  hl=2 l=   2 prim:      PRINTABLESTRING   :TR
  112:d=3  hl=2 l=  15 cons:    SET               
  114:d=4  hl=2 l=  13 cons:     SEQUENCE          
  116:d=5  hl=2 l=   3 prim:      OBJECT            :localityName
  121:d=5  hl=2 l=   6 prim:      UTF8STRING        :Ankara
  129:d=3  hl=2 l=  94 cons:    SET               
  131:d=4  hl=2 l=  92 cons:     SEQUENCE          
  133:d=5  hl=2 l=   3 prim:      OBJECT            :organizationName
  138:d=5  hl=2 l=  85 prim:      UTF8STRING        :TÜRKTRUST Bilgi İletişim ve Bilişim Güvenliği Hizmetleri A.Ş. (c) Aralık 2007```

When a field contains non-ASCII ruby *should* return it as correct UTF-8.

As for IDNA/punycode encoded strings those would be plain ASCII in the certificate, and I fully agree that the openssl lib should absolutely not try to decode those in any way.

[tarcieri]

@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:

https://tools.ietf.org/html/rfc4630#section-3

[rhenium]

#143 adds OpenSSL::X509::Name#to_utf8.

[adamel]

Nice. For those stuck with older versions the following can be be used as a workaround:

ASN1_STRFLGS_ESC_MSB = 4

def name2utf8 name
  begin
    s = name.to_s(OpenSSL::X509::Name::ONELINE & ~(ASN1_STRFLGS_ESC_MSB))
  rescue
    s = name.to_s
  end
  return s
end