0

I was reading through RFC 5280, PKIX Certificate and CRL Profile, Section 4.2.1.6, Subject Alternative Name:

The subject alternative name extension allows identities to be bound to the subject of the certificate. These identities may be included in addition to or in place of the identity in the subject field of the certificate. Defined options include an Internet electronic mail address, a DNS name, an IP address, and a Uniform Resource Identifier (URI). Other options exist, including completely local definitions.

Question: how does one encode a username like "john" or "jdoe"? Here are the choices:

 GeneralName ::= CHOICE {
    otherName                       [0]     OtherName,
    rfc822Name                      [1]     IA5String,
    dNSName                         [2]     IA5String,
    x400Address                     [3]     ORAddress,
    directoryName                   [4]     Name,
    ediPartyName                    [5]     EDIPartyName,
    uniformResourceIdentifier       [6]     IA5String,
    iPAddress                       [7]     OCTET STRING,
    registeredID                    [8]     OBJECT IDENTIFIER }

And I'm making a distinction between a PKCS #9 emailAddress ("jdoe@example.com") and a username ("jdoe").

6

Faced with this question, Microsoft answered the way they are accustomed to: with a Microsoft-specific extension. They defined the User Principal Name, which is actually an OtherName element, the UPN being identified by a Microsoft OID (1.3.6.1.4.1.311.20.2.3) and encoded as an UTF8String (as succinctly specified there). The format of the string mimics that of an email address, in that it consists in an account name and a domain name, joined together with an '@' character.

It is noteworthy that though the UPN looks like an email address, it is not meant to be used for sending emails; and, correspondingly, Microsoft did not use a rfc822name element, because such a name conveys email-based semantics (in particular when the certificate is used with S/MIME) that UPN are not supposed to embody.


The "X.509 way" to encode a name in a certificate, whose format does not match the predefined categories, is to do it along the same lines Microsoft did: use otherName, with an OID of your own, and define your own syntax. Of course, such a name will be usable only by your own software... Although you may decide to reuse the Microsoft UPN format, and thus (possibly) gain some compatibility with Microsoft software (the UPN's goal is to map a certificate onto an Active Directory account).

The really important thing is to determine which software systems will have to deal with your "username". It is useless to encode a username in a certificate if the systems which must decode that username don't know how to do it. For instance, suppose that the username must be used by an Apache-powered Web site, the client certificate being presented at the SSL level. The documentation, in particular the SSLUserName configuration directive, shows us that Apache may be set to use some specific certificate fields as "username", among the exhaustive list of environment variables maintained by the SSL module. If you are in that situation, then you will have to put your "username" in one of these fields, not in some otherName with a syntax of your own.

From looking at these fields, I'd say that your best bet would be "UID". That's one of the components of a Distinguished Name, specified in RFC 4519 under OID 0.9.2342.19200300.100.1.1. It is basically a free-form string, and Apache's mod_ssl knows how to extract it and turn it into a username with:

SSLUserName SSL_CLIENT_S_DN_UID

As a part of a DN, this would go in the subjectDN field directly, not into a Subject Alt Name extension. (This raises the question of why Microsoft did not use that "UID" field for their UPN; my guess is that they wanted at some point to use the complete subjectDN as a path in some LDAP directory, and thus could not add extra fields at will in the DN.)

  • Good find on RFC 4519. I just came across it and re-visited the question to add it as an answer. (And I did not realize you had answered it already. Sorry about that). – user29925 Aug 8 '14 at 4:10
0

In addition to Thoma's answer, here's some more info from RFC 4514:

3.  Parsing a String Back to a Distinguished Name

  ...

      String  X.500 AttributeType
      ------  --------------------------------------------
      CN      commonName (2.5.4.3)
      L       localityName (2.5.4.7)
      ST      stateOrProvinceName (2.5.4.8)
      O       organizationName (2.5.4.10)
      OU      organizationalUnitName (2.5.4.11)
      C       countryName (2.5.4.6)
      STREET  streetAddress (2.5.4.9)
      DC      domainComponent (0.9.2342.19200300.100.1.25)
      UID     userId (0.9.2342.19200300.100.1.1)

   These attribute types are described in [RFC4519].

   Implementations MAY recognize other DN string representations.
   However, as there is no requirement that alternative DN string
   representations be recognized (and, if so, how), implementations
   SHOULD only generate DN strings in accordance with Section 2 of this
   document.

4.  Examples

   This notation is designed to be convenient for common forms of name.
   This section gives a few examples of distinguished names written
   using this notation.  First is a name containing three relative
   distinguished names (RDNs):

      UID=jsmith,DC=example,DC=net
  ...

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy