¿Cómo codificar un nombre de usuario en el certificado PKIX?

Ante esta pregunta, Microsoft respondió a la forma en que están acostumbrados: con una extensión específica de Microsoft. Definieron el Nombre principal del usuario , que en realidad es un% elemento OtherName , el UPN se identifica con un OID de Microsoft (1.3.6.1.4.1.311.20.2.3) y se codifica como UTF8String (como se especifica sucintamente there ). El formato de la cadena imita al de una dirección de correo electrónico, ya que consiste en un nombre de cuenta y un nombre de dominio, unidos con un carácter '@'.

Cabe destacar que aunque el UPN parece una dirección de correo electrónico, no está destinado a ser enviado para enviar correos electrónicos; y, en consecuencia, Microsoft no usó no un elemento rfc822name , porque dicho nombre transmite una semántica basada en el correo electrónico (en particular cuando el certificado se usa con S/MIME ) que UPN no debe representar.

La "forma X.509" para codificar un nombre en un certificado, cuyo formato no coincide con las categorías predefinidas, es hacerlo de la misma manera que hizo Microsoft: use otherName , con un OID propio, y define tu propia sintaxis. Por supuesto, tal nombre solo podrá ser utilizado por su propio software ... Aunque puede decidir reutilizar el formato UPN de Microsoft, y así (posiblemente) obtener cierta compatibilidad con el software de Microsoft (el objetivo de la UPN es asignar un certificado a un Cuenta de Active Directory).

Lo realmente importante es determinar qué sistemas de software tendrán que lidiar con su "nombre de usuario". Es inútil codificar un nombre de usuario en un certificado si los sistemas que deben decodificar ese nombre de usuario no saben cómo hacerlo. Por ejemplo, supongamos que el nombre de usuario debe ser utilizado por un sitio web impulsado por Apache; el certificado del cliente se presenta en el nivel SSL. La documentación , en particular la SSLUserName directiva de configuración, nos muestra que Apache puede configurarse para usar algunos campos de certificado específicos como "nombre de usuario", entre la lista exhaustiva de variables de entorno mantenidas por el módulo SSL. Si se encuentra en esa situación, tendrá que poner su "nombre de usuario" en uno de estos campos, no en algunos otherName con una sintaxis propia.

Al mirar estos campos, diría que su mejor apuesta sería "UID". Ese es uno de los componentes de un Nombre Distinguido, especificado en RFC 4519 bajo OID 0.9.2342.19200300.100.1. 1. Básicamente es una cadena de forma libre, y mod_ssl de Apache sabe cómo extraerla y convertirla en un nombre de usuario con:

SSLUserName SSL_CLIENT_S_DN_UID

Como parte de un DN, esto iría directamente al campo subjectDN , no a una extensión de Nombre alternativo del sujeto. (Esto plantea la pregunta de por qué Microsoft no usó ese campo "UID" para su UPN; supongo que querían en algún momento usar el subjectDN completo como ruta en algún directorio LDAP, y por lo tanto no pudieron agregar más campos a voluntad en el DN)

Además de la respuesta de Thoma, aquí hay más información de 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
  ...