[Twisted-Python] Deprecate and remove t.internet.ssl.DistinguishedName ?

[Wim Lewis]

I'm looking at a fix for bug <https://twistedmatrix.com/trac/ticket/9804>
(Cannot load a PEM certificate with Unicode in subject). The underlying
problem is that the DistinguishedName class can't handle non-ascii AVAs.
The fix I've made simply avoids creating DistinguishedName instances when
it isn't necessary, but that leaves the question of what to do with the
class. I think that the best thing to do is to deprecate the class
entirely and replace it with simpler API. 

Reasons I think that the DN class is broken:
  - The values in a certificate are conceptually text-strings, not
    byte strings; they may be in ASCII, UTF8, UTF16, or several
    other encodings. However
    - DN represents these textual values as `bytes` instead of `str`
    - DN can't handle non-ASCII-representable values at all, even if
      the user never tries to access that value
  - It can only handle a subset of the attribute-assertions found in
    a PKIX DN; there's no escape hatch for others (e.g. OID keys or
    whatever)
  - It can't represent the full structure of a DN (specific ordering,
    multiple-value RDNs, AVAs whos values aren't textual, etc.) ---
    these are not common in the PKIX world but they are valid

What I propose as an alternative:
  - Replace APIs that take `DistinguishedName` classes with ones that take
    `Union[OpenSSL.crypto.X509Name, dict]` where the `dict` format is parsed
    with the same convenience semantics as DistinguishedName, except that
    values are `str`
  - Replace APIs that return `DistinguishedName` with ones that return
    OpenSSL.crypto.X509Name, which is already fairly convenient to use
    (e.g. it has attributes for retrieving/setting commonName
    and so on without dealing with the full complexity of X.500 names)
  - Deprecate `DistinguishedName` and the APIs that use it for eventual removal
  - Expose a convenience function for the dict -> X509Name transform

Any objections? Thoughts on how I should go about doing this? Should I
do it as part of this Trac ticket or split it out?

The only downside I can think of is that this exposes the
OpenSSL.crypto.X509Name type as part of Twisted's API. I don't think
this is a huge reduction in flexibility --- Twisted's API already somewhat
assumes that TLS is implemented using OpenSSL, and only users whose needs
are *already* not well met by DistinguishedName will care if that `Union`
type changes in the future.


Wim Lewis / wiml at hhhh.org