crypto/x509/pkix: Handle emailAddress OID

[cjpatton]

Adds support for the emailAddress OID.

[Lekensteyn]

This limitation exists in upstream Go too. Earlier reports:

• crypto/x509: CommonName truncated at slash golang/go#15256 wanted to extract the emailAddress name. Right now they have to parse certificate.Subject.Names and search for the emailAddress OID.
• crypto/x509/pkix: reorder Name.String to reduce visual noise [freeze exception] golang/go#39924 also shows a case where they expected emailAddress to be human-readable. Closed since unknown attributes are now appended to the end.

Could you come up with any tests for this if it is important? If possible, you could also submit a proposal upstream.

Edit: RFC 5280 (https://tools.ietf.org/html/rfc5280#page-116) defines:

-- Legacy attributes
pkcs-9 OBJECT IDENTIFIER ::=
       { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 9 }
id-emailAddress      AttributeType ::= { pkcs-9 1 }
EmailAddress ::=     IA5String (SIZE (1..ub-emailaddress-length))

and also in https://tools.ietf.org/html/rfc5280#section-4.1.2.6

   Conforming implementations generating new certificates with
   electronic mail addresses MUST use the rfc822Name in the subject
   alternative name extension (Section 4.2.1.6) to describe such
   identities.  Simultaneous inclusion of the emailAddress attribute in
   the subject distinguished name to support legacy implementations is
   deprecated but permitted.

I think more work is needed if this field is intended to be fully supported for validation purposes. Is it possible to modify the user instead of stdlib?

[cjpatton]

Thanks, @Lekensteyn, for providing some context for this change.

Could you come up with any tests for this if it is important? If possible, you could also submit a proposal upstream.

Given (1) this feature is deprecated by RFC5280 and (2) it has been proposed and rejected before, I don't think we should try to upstream this change.

I think more work is needed if this field is intended to be fully supported for validation purposes.

Can you be more specific about what changes are needed? Is it just that you want to see some tests, or are you concerned about the side-effects for users of crypto/x509/pkix?

Is it possible to modify the user instead of stdlib?

This is certainly possible, but it would take some doing. To be clear, the goal is to replicate a feature of boringSSL that we need for our server: https://boringssl.googlesource.com/boringssl/+/refs/heads/master/include/openssl/nid.h#303

[Lekensteyn]

Can you be more specific about what changes are needed? Is it just that you want to see some tests, or are you concerned about the side-effects for users of crypto/x509/pkix?

Both, I was originally concerned about side-effects, but on a quick look there shouldn't be any except those that are strict about the String() output. Some tests would be nice to demonstrate the exact issue that you are trying to solve with this patch.

[Lekensteyn]

One comment about the chosen value in the tests, LGTM otherwise.