2016-10-03 3 views
3

Je travaille avec du code hérité, qui implémente un analyseur X.509 très basique. Le code est assez ancien et je ne peux pas le distribuer.X.509 Ensemble d'attributs standard order

Ce code lit l'ensemble d'attributs standard de l'émetteur et du sujet de manière séquentielle et dans un ordre spécifique. A titre d'exemple de base:

C=XX, O=MyOrganization, OU=MyOrganizationalUnit, 
CN=myCommonName 

Il lirait le pays, l'organisation, puis l'unité d'organisation et enfin le nom commun.

J'ai lu la norme (https://tools.ietf.org/html/rfc5280#section-4.1.2.4), (voir les sections 4.1.2.4 et 4.1.2.6) et ce code hérité fonctionne en quelque sorte avec la plupart des certificats.

La question est de savoir si cet ensemble d'attributs doit suivre un ordre spécifique et où il est dit ou le contraire.

Répondre

2

La raison de cet ordre spécifique est que Noms distinctifs (DNs) ont été définis dans la série de normes X.500. X.500 concerne les services de répertoire. Les serveurs d'annuaire X.500 ont été remplacés pour la plupart par des serveurs LDAP, mais X.509, la partie de la série qui définit les certificats, a survécu à d'autres fins.

Dans une arborescence de répertoires, le nœud le plus général se trouve en haut (dans votre exemple pays), puis se rétrécit à chaque niveau de l'arborescence. Une personne est généralement une feuille dans cet arbre:

    C=US 
        | 
    O=Example1 ----- O=Example2 
      |    | 
    OU=OU1-----OU=OU2  ... 
    |   | 
    CN=XYZ  ... 

AFAIK X.500 comprend des règles qui définissent quel attribut type peut suivre un certain type d'attribut dans l'arbre, mais malheureusement, les documents ne sont pas librement disponibles.

L'ordre des noms distinctifs relatifs (RDN) dans le sujet ou émetteur DN d'un certificat sur un ASN.1 niveau reflète l'ordre dans l'arbre (ie haut en bas):

SEQUENCE { 
     SET { 
      SEQUENCE { 
       OBJECT IDENTIFIER=CountryName (2.5.4.6) 
       PRINTABLE STRING='US' 
      } 
     } 
     SET { 
      SEQUENCE { 
       OBJECT IDENTIFIER=OrganizationName (2.5.4.10) 
       PRINTABLE STRING='GeoTrust Inc.' 
      } 
     } 
     SET { 
      SEQUENCE { 
       OBJECT IDENTIFIER=CommonName (2.5.4.3) 
       PRINTABLE STRING='GeoTrust Global CA' 
      } 
     } 
    } 

Toutefois, pour les deux normes d'une DN représentation de chaîne : OpenSSL montre les attributs par défaut car ils sont stockés dans le certificat, alors que RFC 2253/4514 inverse l'ordre:

... la sortie consiste en les codages de chaîne de chaque nom distinctif relatif dans la séquence RDNSequence (conformément à la section 2.2), en commençant par le dernier élément de la séquence et en déplaçant vers l'arrière en direction de la première.

CN=GeoTrust Global CA,O=GeoTrust Inc.,C=US 

Notez également qu'il ya des certificats « dans la nature » qui ont plusieurs unités d'organisation dans leurs DNs ou moins communs types d'attributs de RFC 4519 comme SERIALNUMBER ou UID. J'ai également vu quelques certificats, où les RDN ont été codés dans le mauvais ordre.

+1

Pour être plus précis, l'ordre des attributs RDN dans le sujet du certificat n'a pas d'importance. Il existe une convention, mais elle n'est pas strictement appliquée, car même si le champ sujet utilise le format de nom X.500, il n'appartient à aucun arbre X.500. – Crypt32

+0

@CryptoGuy Je pense que c'est important quand ils sont codés en DER car j'ai trouvé la citation suivante dans diverses sources: "Les éléments d'un ensemble sont codés en ordre trié, basé sur leur valeur de balise" (corrigez-moi si je Je me trompe). Cependant, à la fois votre commentaire et la réponse, m'ont aidé à comprendre pourquoi ce code hérité laid fonctionnait du tout. Merci pour ça! – FranMowinckel

+0

'SET' est une séquence non ordonnée. Cela signifie que les types imbriqués (attributs RDN) peuvent apparaître dans n'importe quel ordre. C'est juste une convention pour les commander dans un ordre particulier. – Crypt32