Add basic support for Subject Alternative Name OtherName

[Tudyx]

Add basic support for OtherName in the Subject Alternative Name extension.
OtherName is used by smart card certificates and also, for instance, to identify nodes in a peer-to-peer network.

OtherName is defined like this in the RFC 5280§4.2.1.6:

OtherName ::= SEQUENCE {
        type-id    OBJECT IDENTIFIER,
        value      [0] EXPLICIT ANY DEFINED BY type-id }

Which is really close to AttributeTypeAndValue that we already support (RFC 5280§4.1.2.4)

 AttributeTypeAndValue ::= SEQUENCE {
     type     AttributeType,
     value    AttributeValue }

AttributeType ::= OBJECT IDENTIFIER

AttributeValue ::= ANY -- DEFINED BY AttributeType

So I took the same approach while implementing it.

I don't try to map the OID with a specific ASN.1 object, as users could define their own.

This is the same approach as OpenSSL where users provide the OID, the format and its content.

[est31]

OpenSSL seems to allow general ASN.1 for OtherName while here we restrict ourselves to a bunch of string types. Should we instead just take binary encoded ASN.1 plus a custom specified oid?

[Tudyx]

This is the same tradeoff that is made for DnValue which could also technically be an arbitrary ASN.1 object. As OtherName is used for setup a name, the vast majority of the time user will just want to use a string type, so it makes sense to facilitate that path.
The enum is non-exhaustive so in the future we might add another variant that takes an arbitrary ASN.1. But by doing so we will probably re-expose a dependency into our public API so it should be done carefully.
The current proposition unlocks the vast majority of use cases while being future proof.

I don’t feel strongly about that, and will make the required changes if we think exposing an arbitrary ASN.1 struct is the best solution.

[cpu]

I haven't reviewed the branch yet but in general I think we should address #181 before making the problem worse by introducing more types that carry tagged string types that don't enforce that the content matches the type's limitations.

[Tudyx]

I've rebased on the latest commits to be able to use the new string types (#214).

What I propose in this MR is the same tradeoff that the one we are making for DnValue enum.
For instance, DnValue is used to represent the issuer name which is defined by the following ASN.1 in the RFC 5280:

Name ::= CHOICE { -- only one possibility for now --
     rdnSequence  RDNSequence }

   RDNSequence ::= SEQUENCE OF RelativeDistinguishedName

   RelativeDistinguishedName ::=
     SET SIZE (1..MAX) OF AttributeTypeAndValue

   AttributeTypeAndValue ::= SEQUENCE {
     type     AttributeType,
     value    AttributeValue }

   AttributeType ::= OBJECT IDENTIFIER

   AttributeValue ::= ANY -- DEFINED BY AttributeType

Technically, DnValue is incorrect here because the issuer value can be any ASN.1 type. But has stated by the RFC:

The type of
the component AttributeValue is determined by the AttributeType; in
general it will be a DirectoryString.

The DirectoryString type is defined as a choice of PrintableString,
TeletexString, BMPString, UTF8String, and UniversalString.

Most of the time the issuer value will just be a string, so that makes sense we make variants for that, it will cover most of the user's use cases. DnValue is non-exhaustive, so, if in the future we want to add the possibility to provide an arbitrary ASN.1 type, we can do it without breaking users' code.

That's exactly what I propose for subjectAltName, I also think strings will cover most of the use cases.

For my use cases (p2p), we need an UTF-8 string. For smart cards, this the same thing (extracted from Microsoft doc):

Subject Alternative Name = Other Name: Principal Name= (UPN). For instance:
UPN = [email protected]
The UPN OtherName OID is: "1.3.6.1.4.1.311.20.2.3"
The UPN OtherName value: Must be ASN1-encoded UTF8 string

Note that this OID is also used even for non-Windows OS, see this tutorial from Red Hat.

Note: after reflection I just kept the UTF-8 variant for the OtherNameValue, as I'm not aware of any uses cases for the other ASN.1 strings.

[djc]

This seems reasonable to me.

[cpu]

Just leaving a note that I haven't forgotten about this PR. I will aim to review it this week. Thanks!

[cpu]

Thanks! I had a few comments but nothing that I think will be a blocker.

[cpu]

Thank you :-)