Come codificare un nome utente nel certificato PKIX?

0

Leggevo RFC 5280, Certificato PKIX e profilo CRL, Sezione 4.2.1.6, Nome soggetto alternativo :

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.

Domanda: come si codifica un nome utente come "john" o "jdoe"? Ecco le scelte:

 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 }

E sto facendo una distinzione tra un indirizzo email PKCS # 9 ("[email protected]") e un nome utente ("jdoe").

    
posta jww 08.07.2014 - 21:26
fonte

2 risposte

6

Di fronte a questa domanda, Microsoft ha risposto nel modo in cui sono abituati: con un'estensione specifica di Microsoft. Hanno definito Nome principale utente , che in realtà è una OtherName element, l'UPN identificato da un Microsoft OID (1.3.6.1.4.1.311.20.2.3) e codificato come UTF8String (come succintamente specificato ci ). Il formato della stringa simula quello di un indirizzo email, in quanto consiste in un nome account e un nome di dominio, uniti con un carattere '@'.

È interessante notare che sebbene l'UPN sembri un indirizzo e-mail, non è pensato per essere utilizzato per l'invio di e-mail; e, corrispondentemente, Microsoft ha non usare un elemento rfc822name , perché tale nome trasmette la semantica basata su email (in particolare quando il certificato viene usato con S/MIME ) che l'UPN non dovrebbe incarnare.

Il "modo X.509" per codificare un nome in un certificato, il cui formato non corrisponde alle categorie predefinite, è farlo sulla stessa linea di Microsoft: usa otherName , con un OID di tua proprietà, e definisci la tua sintassi. Ovviamente, tale nome sarà utilizzabile solo dal proprio software ... Sebbene si possa decidere di riutilizzare il formato Microsoft UPN, e quindi (possibilmente) ottenere una certa compatibilità con il software Microsoft (l'obiettivo dell'UPN è di mappare un certificato su un Account di Active Directory).

La cosa veramente importante è determinare quali sistemi software dovranno gestire il tuo "nome utente". È inutile codificare un nome utente in un certificato se i sistemi che devono decodificare quel nome utente non sanno come farlo. Ad esempio, supponiamo che il nome utente debba essere utilizzato da un sito Web alimentato da Apache, il certificato client presentato a livello SSL. La documentazione , in particolare SSLUserName direttiva di configurazione, ci mostra che Apache può essere impostato per utilizzare alcuni campi specifici del certificato come "username", tra l'elenco completo di variabili d'ambiente gestite dal modulo SSL. Se ti trovi in quella situazione, dovrai inserire il tuo "nome utente" in uno di questi campi, non in qualche otherName con una tua sintassi.

Guardando questi campi, direi che la tua migliore scommessa sarebbe "UID". Questo è uno dei componenti di un Distinguished Name, specificato in RFC 4519 sotto OID 0.9.2342.19200300.100.1. 1. È fondamentalmente una stringa in formato libero e mod_ssl di Apache sa come estrarlo e trasformarlo in un nome utente con:

SSLUserName SSL_CLIENT_S_DN_UID

Come parte di un DN, questo andrebbe direttamente nel campo subjectDN , non in un'estensione Nome alt soggetto. (Ciò solleva la questione del perché Microsoft non abbia usato quel campo "UID" per il loro UPN, suppongo che volessero a un certo punto usare il subjectDN completo come percorso in qualche directory LDAP, e quindi non poter aggiungere altro campi a volontà nel DN.)

    
risposta data 09.07.2014 - 14:46
fonte
0

Oltre alla risposta di Thoma, ecco alcune ulteriori informazioni da 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
  ...
    
risposta data 08.08.2014 - 06:12
fonte