Protocole léger d'accès à un répertoire (LDAP) : Schéma pour les applications d’utilisateur

Statut de ce mémo

Le présent document spécifie un protocole de normalisation Internet pour la communauté de l'Internet, qui appelle à la discussion et à des suggestions pour son amélioration. Prière de se reporter à l'édition en cours des "Normes de protocole officielles de l'Internet" (STD 1) sur l'état de la normalisation et le statut de ce protocole. La distribution du présent mémo n'est soumise à aucune restriction.

Notice de Copyright

Copyright (C) The Internet Society (2006).

Résumé

Le présent document fait partie intégrante de la spécification technique du protocole léger d’accès à un répertoire (LDAP). Il fait la spécification technique des types d’attribut et de classes d’objets destinés à une utilisation par les clients de répertoires LDAP dans de nombreux services de répertoire, tels que les pages blanches de l’annuaire. Ces objets sont largement utilisés comme base du schéma de nombreux répertoires LDAP. Le présent document ne traite pas des attributs utilisés pour l’administration des serveurs de répertoires, et n’inclut pas d’objets de répertoire définis pour des utilisations spécifiques dans d’autres documents.

Table des matières

1. Introduction ........................................................................................................................................................................................ 2
1.1 Relations avec les autres spécifications .............................................................................................................................. 3
1.2 Conventions ............................................................................................................................................................................. 3
1.3 Questions générales ................................................................................................................................................................ 3
2 Types d’attribut .................................................................................................................................................................................. 3
2.1 'businessCategory' .................................................................................................................................................................. 3
2.2 'c' ................................................................................................................................................................................................. 4
2.3 'cn' .............................................................................................................................................................................................. 4
2.4 'dc' .............................................................................................................................................................................................. 4
2.5 'description' ............................................................................................................................................................................... 4
2.6 'destinationIndicator' ............................................................................................................................................................... 5
2.7 'distinguishedName' ................................................................................................................................................................ 5
2.8 'dnQualifier' ............................................................................................................................................................................... 5
2.9 'enhancedSearchGuide' ........................................................................................................................................................... 6
2.10 'facsimileTelephoneNumber' .................................................................................................................................................. 6
2.11 'generationQualifier' ................................................................................................................................................................. 6
2.12 'givenName' ............................................................................................................................................................................... 6
2.13 'houseIdentifier' ....................................................................................................................................................................... 6
2.14 'initials' ....................................................................................................................................................................................... 7
2.15 'internationalISDNNumber' ..................................................................................................................................................... 7
2.16 'l' .................................................................................................................................................................................................. 7
2.17 'member' ..................................................................................................................................................................................... 7
2.18 'name' ......................................................................................................................................................................................... 7
2.19 'o' ................................................................................................................................................................................................ 8
2.20 'ou' .............................................................................................................................................................................................. 8
2.21 'owner' ........................................................................................................................................................................................ 8
2.22 'physicalDeliveryOfficeName' ................................................................................................................................................ 8
2.23 'postalAddress' ........................................................................................................................................................................ 8
2.24 'postalCode' .............................................................................................................................................................................. 8
2.25 'postOfficeBox' ......................................................................................................................................................................... 9
2.26 'preferredDeliveryMethod' ..................................................................................................................................................... 9
2.27 'registeredAddress' .................................................................................................................................................................. 9
2.28 'roleOccupant' ........................................................................................................................................................................... 9
2.29 'searchGuide' ........................................................................................................................................................................... 10
2.30 'seeAlso' .................................................................................................................................................................................. 10
2.31 'serialNumber' ......................................................................................................................................................................... 10
2.32 'sn' ............................................................................................................................................................................................ 10
2.33 'st' ............................................................................................................................................................................................. 10
2.34 'street' ....................................................................................................................................................................................... 11
2.35 'telephoneNumber' ................................................................................................................................................................. 11
2.36 'teletexTerminalIdentifier' ...................................................................................................................................................... 11
2.37 'telexNumber' ........................................................................................................................................................................... 11
2.38 'title' .......................................................................................................................................................................................... 11
2.39 'uid' ........................................................................................................................................................................................... 12
2.40. 'uniqueMember' ................................................................................................................................................................ 12
2.41 'userPassword' ........................................................................................................................................................................ 12
2.42 'x121Address' .......................................................................................................................................................................... 12
2.43 'x500UniqueIdentifier' ........................................................................................................................................................... 13
3. Classes d’objet ................................................................................................................................................................................. 13
3.1 'applicationProcess' ............................................................................................................................................................... 13
3.2 'country' ................................................................................................................................................................................... 13
3.3 'dcObject' ................................................................................................................................................................................. 13
3.4 'device' ..................................................................................................................................................................................... 14
3.5 'groupOfNames' ...................................................................................................................................................................... 14
3.6 'groupOfUniqueNames' ......................................................................................................................................................... 14
3.7 'locality' .................................................................................................................................................................................... 14
3.8 'organization' ........................................................................................................................................................................... 14
3.9 'organizationalPerson' ........................................................................................................................................................... 15
3.10 'organizationalRole' ................................................................................................................................................................ 15
3.11 'organizationalUnit' ................................................................................................................................................................ 15
3.12 'person' .................................................................................................................................................................................... 15
3.13 'residentialPerson' .................................................................................................................................................................. 16
3.14 'uidObject' ............................................................................................................................................................................... 16
4. Considérations relatives à l’IANA ................................................................................................................................................ 16
5. Considérations sur la sécurité ........................................................................................................................................................ 17
6. Remerciements .................................................................................................................................................................................. 18
7. Références ......................................................................................................................................................................................... 18
7.1 Références normatives .......................................................................................................................................................... 18
7.2 Références informatives ....................................................................................................................................................... 19
Appendice A Changements effectués depuis la RFC 2256 ...................................................................................................... 19

1. Introduction

Le présent document donne une vue générale des types d’attribut et de classes d’objet destinés à être utilisés par les clients de répertoire du protocole léger d’accès à un répertoire (LDAP, Lightweight Directory Access Protocol) pour de nombreux services de répertoire, tels que les pages blanches de l’annuaire. Spécifiés à l’origine dans les documents de X.500 [X.500], ces objets sont largement utilisés comme base du schéma de nombreux répertoires LDAP. Le présent document ne traite pas des attributs utilisés pour l’administration des serveurs de répertoires, et n’inclut pas les objets de répertoire définis pour des utilisations spécifiques dans d’autres documents.

1.1 Relations avec les autres spécifications

Le présent document fait partie intégrante de la spécification technique LDAP [RFC4510], qui rend obsolète dans son intégralité la spécification technique LDAP définie précédemment, la RFC 3377. Pour ce qui concerne la RFC 2256, les sections 6 et 8 de la RFC 2256 sont rendues obsolètes par la [RFC4517]. Les paragraphes 5.1, 5.2, 7.1, et 7.2 de la RFC 2256 sont rendus obsolètes par la [RFC4512]. Le reste de la RFC 2256 est rendu obsolète par le présent document. La spécification technique pour le type d’attribut 'dc' et la classe d’objet 'dcObject' qu’on trouve dans la RFC 2247 est subrogée par les paragraphes 2.4 et 3.3 du présent document. Le reste de la RFC 2247 reste en vigueur.

Le présent document met à jour la RFC 2798 en remplaçant la description informative du type d’attribut 'uid' par la description définitive fournie au paragraphe 2.39 du présent document.

Le présent document met à jour la RFC 2377 en remplaçant la description informative de la classe d’objet 'uidObject' par la description définitive fournie au paragraphe 3.14 du présent document.

Un certain nombre d’éléments de schéma qui étaient inclus dans la révision précédente de la spécification technique LDAP ne sont pas inclus dans la présente révision de LDAP. Les éléments de schéma relatifs à PKI sont maintenant spécifiés dans la [RFC4523]. Sauf s’ils étaient réintroduits dans des spécifications techniques à l’avenir, le reste est à considérer à titre historique.

Les descriptions du présent document DOIVENT être considérées comme définitives pour leur utilisation dans LDAP.

1.2 Conventions

Les mots clé "DOIT", "NE DOIT PAS", "EXIGE", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDÉ", "PEUT", et "FACULTATIF" dans le présent document sont à interpréter comme décrit dans le BCP 14 [RFC2119].

1.3 Questions générales

Le présent document fait références aux Syntaxes définies à la Section 3 de la [RFC4517] et aux règles de correspondance définie à la Section 4 de la [RFC4517].

Les définitions des types d’attribut et de classes d’objet sont écrites en utilisant la forme Backus-Naur augmentée (ABNF) [RFC4234] de AttributeTypeDescription et de ObjectClassDescription données dans la [RFC4512]. Les lignes ont été coupées pour faciliter la lecture. Lorsque de telles valeurs sont transférées comme valeurs d’attribut dans le protocole LDAP, les valeurs ne contiendront pas de rupture de ligne.

2 Types d’attribut

Les types d’attribut contenus dans la présente section détiennent des informations d’utilisateur.

Il n’est pas exigé que les serveurs mettent en oeuvre les types d’attribut 'searchGuide' et 'teletexTerminalIdentifier'. En fait, leur utilisation est fortement déconseillée.

Une mise en œuvre de serveur LDAP DEVRAIT reconnaître le reste des types d’attribut décrits dans cette section.

2.1 'businessCategory'

Le type d’attribut 'businessCategory' décrit les domaines d’activité d’une organisation. Chaque domaine est une valeur de cet attribut multi-valeurs. (Source: X.520 [X.520])

( 2.5.4.15 NAME 'businessCategory'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

1.3.6.1.4.1.1466.115.121.1.15 se réfère à la syntaxe Directory String (chaîne de répertoire) [RFC4517].

Exemples : "banque", "transports", et "agent immobilier".

2.2 'c'

Le type d’attribut 'c' ('countryName' in X.500) contient un code de pays [ISO3166] à deux lettres. (Source : [X.520])

( 2.5.4.6 NAME 'c'SUP nameSYNTAX 1.3.6.1.4.1.1466.115.121.1.11SINGLE-VALUE )

1.3.6.1.4.1.1466.115.121.1.11 se réfère à la syntaxe Country String (chaîne de pays) [RFC4517].

Exemples : "DE", "AU" et "FR".

2.3 'cn'

Le type d’attribut 'cn' ('commonName' in X.500) contient les noms d’un objet. Chaque nom est une valeur de cet attribut multi-valeurs. Si l’objet correspond à une personne, c’est normalement le nom complet de la personne. (Source : [X.520])

( 2.5.4.3 NAME 'cn' SUP name )

Exemples : "Martin K Smith", "Marty Smith" et "printer12".

2.4 'dc'

Le type d’attribut 'dc' ('domainComponent' dans la RFC 1274) est une chaîne qui contient un composant, une étiquette d’un nom de domaine DNS [RFC1034][RFC2181] qui désigne un hôte [RFC1123]. C’est à dire, une valeur de cet attribut est une chaîne de caractères ASCII adhérant à l’ABNF suivant [RFC4234] :

label = (ALPHA / DIGIT) [*61(ALPHA / DIGIT / HYPHEN) (ALPHA / DIGIT)]
ALPHA = %x41-5A / %x61-7A ; "A"-"Z" / "a"-"z"
DIGIT = %x30-39 ; "0"-"9"
HYPHEN = %x2D ; trait d’union ("-")

Le codage de IA5String à utiliser dans LDAP est simplement les caractères de l’étiquette ASCII. La règle de correspondance d’égalité est insensible à la casse, comme dans le DNS d’aujourd’hui. (Source : [RFC2247] et [RFC 1274])

( 0.9.2342.19200300.100.1.25 NAME 'dc'
EQUALITY caseIgnoreIA5Match
SUBSTR caseIgnoreIA5SubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )

1.3.6.1.4.1.1466.115.121.1.26 se réfère à la syntaxe IA5 String [RFC4517].

Exemples : Les valeurs valides incluent "exemple" et "com" mais pas "exemple.com". Ce dernier est invalide car il contient plusieurs composants de domaine.

On notera que le service de répertoire ne garantira pas que les valeurs de cet attribut se conforment aux restrictions sur les étiquettes d’hôte [RFC1123] illustrées par la production de <label> fournie ci-dessus. Il est de la responsabilité du client de répertoire de s’assurer que l’étiquette qu’il mémorise dans cet attribut comporte les restrictions appropriées.

Les applications de répertoire qui prennent en charge les noms de domaines internationaux DOIVENT utiliser la méthode ToASCII [RFC3490] pour produire l’étiquette de composant de domaine. Les considérations particulières exposées à la Section 4 de la [RFC3490] devraient être suivies, en fonction du composant de domaine qui est utilisé pour les besoins de "stored" ou "query".

2.5 'description'

Le type d’attribut 'description' contient des phrases de description lisibles par l’homme sur l’objet. Chaque description est une valeur de cet attribut multi-valeurs. (Source : [X.520])

( 2.5.4.13 NAME 'description'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

1.3.6.1.4.1.1466.115.121.1.15 se réfère à la syntaxe Directory String [RFC4517].

Exemples : "imprimante couleur", "La maintenance est faite chaque lundi, à 13 h.", et "liste de distribution pour tous le personnel technique".

2.6 'destinationIndicator'

Le type d’attribut 'destinationIndicator' contient des chaînes de pays et de ville associées à l’objet (le destinataire) nécessaires pour les fournir au Service de télégrammes public. Les chaînes sont composées conformément aux Recommandations UIT-T F.1 et F.31. Chaque chaîne est une valeur de cet attribut multi-valeurs. (Source : [X.520])

( 2.5.4.27 NAME 'destinationIndicator'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 )

1.3.6.1.4.1.1466.115.121.1.44 se réfère à la syntaxe Printable String (chaîne imprimable) [RFC4517].

Exemples : "AASD" comme indicateur de destination pour Sydney, Australia. "GBLD" comme indicateur de destination pour London, United Kingdom.

On notera que le répertoire ne garantit pas que les valeurs de cet attribut se conforment aux Recommandations UIT-T F.1 et F.31. Il est de la responsabilité de l’application de s’assurer que les indicateurs de destination qu’il mémorise dans cet attribut sont construits de façon appropriée.

2.7 'distinguishedName'

Le type d’attribut 'distinguishedName' n’est pas utilisé comme nom de l’objet lui-même, mais plutôt comme type de base dont peuvent hériter des types d’attributs d’utilisateur avec une syntaxe DN.

Il est peu vraisemblable que des valeurs de ce type lui-même surviennent dans une entrée. Les mises en oeuvre de serveur LDAP qui ne prennent pas en charge les sous-types d’attribut n’ont pas besoin de reconnaître cet attribut dans les demandes. Les mises en oeuvre de client NE DOIVENT PAS supposer que les serveurs LDAP sont capables d’effectuer des sous-types d’attribut. (Source : X.520])

( 2.5.4.49 NAME 'distinguishedName'
EQUALITY distinguishedNameMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )

1.3.6.1.4.1.1466.115.121.1.12 se réfère à la syntaxe DN [RFC4517].

2.8 'dnQualifier'

Le type d’attribut 'dnQualifier' contient des chaînes d’informations destinées à lever des ambiguïtés à ajouter au nom distinctif relatif d’une entrée. Les informations sont destinées à être utilisées lors de la fusion de données provenant de plusieurs sources afin d’empêcher des conflits entre des entrées qui sans cela auraient le même nom. Chaque chaîne est une valeur de cet attribut multi-valeurs. Il est recommandé qu’une valeur de l’attribut 'dnQualifier' soit la même pour toutes les entrées d’une source particulière. (Source : X.520)

( 2.5.4.46 NAME 'dnQualifier'
EQUALITY caseIgnoreMatch
ORDERING caseIgnoreOrderingMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 )

1.3.6.1.4.1.1466.115.121.1.44 se réfère à la syntaxe Printable String [RFC4517].

Exemples : "20050322123345Z" – des horodatages peuvent être utilisés pour les informations de précisions.

"123456A" – des numéros de série peuvent être utilisés pour les informations de précisions.

2.9 'enhancedSearchGuide'

Le type d’attribut 'enhancedSearchGuide' contient des ensembles d’informations à utiliser par les clients de répertoire pour construire les filtres de recherche. Chaque ensemble est une valeur de cet attribut multi-valeurs. (Source : X.520)

( 2.5.4.47 NAME 'enhancedSearchGuide' SYNTAX 1.3.6.1.4.1.1466.115.121.1.21 )

1.3.6.1.4.1.1466.115.121.1.21 se réfère à la syntaxe Enhanced Guide [RFC4517].

Exemples : "person#(sn$APPROX)#wholeSubtree" et "organizationalUnit#(ou$SUBSTR)#oneLevel".

2.10 'facsimileTelephoneNumber'

Le type d’attribut 'facsimileTelephoneNumber' contient les numéros de téléphone (et, facultativement, les paramètres) pour les terminaux de télécopie. Chaque numéro de téléphone est une valeur de cet attribut multi-valeurs. (Source : X.520)

( 2.5.4.23 NAME 'facsimileTelephoneNumber' SYNTAX 1.3.6.1.4.1.1466.115.121.1.22 )

1.3.6.1.4.1.1466.115.121.1.22 se réfère à la syntaxe Facsimile Telephone Number [RFC4517].

Exemples : "+61 3 9896 7801" et "+81 3 347 7418$fineResolution".

2.11 'generationQualifier'

Le type d’attribut 'generationQualifier' contient des chaînes de nom qui sont normalement la partie suffixe dun nom d’une personne. Chaque chaîne est une valeur de cet attribut multi-valeurs. (Source : X.520])

( 2.5.4.44 NAME 'generationQualifier' SUP name )

Exemples : "III", "3rd", et "Jr.".

2.12 'givenName'

Le type d’attribut 'givenName' contient des chaînes de nom qui sont la partie du nom d’une personne qui n’est pas son nom de famille. Chaque chaîne est une valeur de cet attribut multi valeurs. (Source : X.520)

( 2.5.4.42 NAME 'givenName' SUP name )

Exemples : "Andrew", "Charles", et "Joanne".

2.13 'houseIdentifier'

Le type d’attribut 'houseIdentifier' contient des identifiant d’un bâtiment au sein d’une localisation. Chaque identifiant est une valeur de cet attribut multi-valeurs. (Source : X.520)

( 2.5.4.51 NAME 'houseIdentifier'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

1.3.6.1.4.1.1466.115.121.1.15 se réfère à la syntaxe Directory String [RFC4517].

Exemple : "20" pour représenter la maison numéro 20.

2.14 'initials'

Le type d’attribut 'initials' contient des chaînes d’initiales de certains ou de tous les prénoms d’un individu (mais pas de son ou ses noms de famille). Chaque chaîne est une valeur de cet attribut multi valeurs. (Source : X.520])

( 2.5.4.43 NAME 'initials' SUP name )

Exemples : "K. A." et "K".

2.15 'internationalISDNNumber'

Le type d’attribut 'internationalISDNNumber' contient les adresses de réseau numérique à intégration de service (RNIS) telles que définies dans la Recommandation UIT-T E.164. Chaque adresse est une valeur de cet attribut multi valeurs. (Source : X.520])

( 2.5.4.25 NAME 'internationalISDNNumber'
EQUALITY numericStringMatch
SUBSTR numericStringSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 )

1.3.6.1.4.1.1466.115.121.1.36 se réfère à la syntaxe Numeric String [RFC4517].

Exemple : "0198 333 333".

2.16 'l'

Le type d’attribut 'l' ('localityName' in X.500) contient les noms d’une localité ou lieu-dit, comme une ville, département ou autre région géographique. Chaque nom est une valeur de cet attribut multi valeurs. (Source : X.520)

( 2.5.4.7 NAME 'l' SUP name )

Exemples : "Genève", "Paris", et "Edinburgh".

2.17 'member'

Le type d’attribut 'member' contient les noms distinctifs des objets qui sont sur une liste ou dans un groupe. Chaque nom est une valeur de cet attribut multi valeurs. (Source : X.520)

( 2.5.4.31 NAME 'member' SUP distinguishedName )

Exemples : "cn=James Clarke,ou=Finance,o=Widget\, Inc." et "cn=John Xerri,ou=Finance,o=Widget\, Inc." peuvent être deux membres de l’équipe financière (group) de Widget, Inc., auquel cas, ces deux noms distinctifs seraient présent comme valeurs individuelles de l’attribut de membre.

2.18 'name'

Le type d’attribut 'name' est le super type d’attribut dont héritent les types d’attributs d’utilisateur avec la syntaxe de nom. De tels types d’attribut sont normalement utilisés pour les dénominations. Le type d’attribut est multi valeurs.

Il est peu vraisemblable que des valeurs de ce type lui –même surviennent dans une entrée. Les mises en œuvre de serveur LDAP qui ne prennent pas en charge les sous-types d’attribut n’ont pas besoin de reconnaître cet attribut dans les demandes. Les mises en oeuvre de client NE DOIVENT PAS supposer que les serveurs LDAP sont capables d’effectuer le sous-typage des attributs. (Source : X.520)

( 2.5.4.41 NAME 'name'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

1.3.6.1.4.1.1466.115.121.1.15 se réfère à la syntaxe Directory String [RFC4517].

2.19 'o'

Le type d’attribut 'o' ('organizationName' in X.500) contient les noms d’une organisation. Chaque nom est une valeur de cet attribut multi valeurs. (Source : X.520)

( 2.5.4.10 NAME 'o' SUP name )

Exemples : "Widget", "Widget, Inc.", et "Widget, Incorporated.".

2.20 'ou'

Le type d’attribut 'ou' ('organizationalUnitName' in X.500) contient les noms d’une unité organisationnelle. Chaque nom est une valeur de cet attribut multi valeurs. (Source : X.520)

( 2.5.4.11 NAME 'ou' SUP name )

Exemples : "Finance", "Ressources humaines", et "Recherche et développement".

2.21 'owner'

Le type d’attribut 'owner' contient les noms distinctifs des objets qui ont une responsabilité de propriétaire sur l’objet possédé. Chaque nom de propriétaire est une valeur de cet attribut multi valeurs. (Source : X.520)

( 2.5.4.32 NAME 'owner' SUP distinguishedName )

Exemple : L’objet liste d’adresses de messagerie, dont le DN est "cn=Tous Employés, ou=Liste d’adresses de messagerie,o=Widget\, Inc.", est la propriété du Directeur des ressources humaines. Donc, la valeur de l’attribut 'owner' au sein de l’objet liste d’adresses de messagerie serait le DN du (rôle) de directeur :

"cn=Directeur des ressources humaines,ou=employé,o=Widget\, Inc.".

2.22 'physicalDeliveryOfficeName'

Le type d’attribut 'physicalDeliveryOfficeName' contient des noms que le service postal utilise pour identifier un bureau de poste. (Source : X.520)

( 2.5.4.19 NAME 'physicalDeliveryOfficeName'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

1.3.6.1.4.1.1466.115.121.1.15 se réfère à la syntaxe Directory String [RFC4517].

Exemples : "Bremerhaven, Main" et "Bremerhaven, Bonnstrasse".

2.23 'postalAddress'

Le type d’attribut 'postalAddress' contient les adresses utilisées par un service postal pour effectuer des services pour l’objet. Chaque adresse est une valeur de cet attribut multi valeurs. (Source : X.520)

( 2.5.4.16 NAME 'postalAddress'
EQUALITY caseIgnoreListMatch
SUBSTR caseIgnoreListSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )

1.3.6.1.4.1.1466.115.121.1.41 se réfère à la syntaxe Postal Address [RFC4517].

Exemple : "15 Main St.$Ottawa$Canada".

2.24 'postalCode'

Le type d’attribut 'postalCode' contient des codes utilisés par un service postal pour identifier des zones de service postal. Chaque code est une valeur de cet attribut multi valeurs. (Source : X.520)

( 2.5.4.17 NAME 'postalCode'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

1.3.6.1.4.1.1466.115.121.1.15 se réfère à la syntaxe Directory String [RFC4517].

Exemple : "22180", pour identifier Vienna, VA, aux USA.

2.25 'postOfficeBox'

Le type d’attribut 'postOfficeBox' contient des identifiants de boîtes postales qu’utilise un Service Postal lorsqu’un consommateur reçoit son courrier dans une boîte située dans les locaux du Service Postal. Chaque identifiant de boîte postale est une seule valeur de cet attribut multi valeurs. (Source : X.520)

( 2.5.4.18 NAME 'postOfficeBox'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

1.3.6.1.4.1.1466.115.121.1.15 se réfère à la syntaxe Directory String [RFC4517].

Exemple : "Box 45".

2.26 'preferredDeliveryMethod'

Le type d’attribut 'preferredDeliveryMethod' contient l’indication de la méthode préférée de l’objet pour obtenir un message. (Source : X.520)

( 2.5.4.28 NAME 'preferredDeliveryMethod'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.14 SINGLE-VALUE )

1.3.6.1.4.1.1466.115.121.1.14 se réfère à la syntaxe Delivery Method [RFC4517].

Exemple : Si la méthode de livraison mhs-delivery est préférée à la délivrance par téléphone, qui est préférée à toutes les autres méthodes, la valeur serait : "mhs $ telephone".

2.27 'registeredAddress'

Le type d’attribut 'registeredAddress' contient les adresses postales convenables pour la réception des télégrammes ou documents expédiés, lorsque il est nécessaire d’avoir la livraison acceptée par le receveur. Chaque adresse est une valeur de cet attribut multi valeurs. (Source : X.520)

( 2.5.4.26 NAME 'registeredAddress'
SUP postalAddress
SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )

1.3.6.1.4.1.1466.115.121.1.41 se réfère à la syntaxe Postal Address [RFC4517].

Exemple : "Receptionist$Widget, Inc.$15 Main St.$Ottawa$Canada".

2.28 'roleOccupant'

Le type d’attribut 'roleOccupant' contient les noms distinctifs des objets (normalement des personnes) qui assument les responsabilités d’un objet de rôle. Chaque nom distinctif est une valeur de cet attribut multi valeurs. (Source : X.520)

( 2.5.4.33 NAME 'roleOccupant' SUP distinguishedName )

Exemple : L’objet de rôle, "cn=Directeu des ressources humainesr,ou=Position,o=Widget\, Inc.", est assumé par deux personnes dont les noms d’objet sont "cn=Mary Smith,ou=employee,o=Widget\, Inc." et "cn=James Brown,ou=employee,o=Widget\, Inc.". L’attribut 'roleOccupant' contiendra les deux noms distinctifs, car ils sont les acteurs de ce rôle.

2.29 'searchGuide'

Le type d’attribut 'searchGuide' contient des ensembles d’informations utiles aux clients pour construire les filtres de recherche. Il est supplanté par 'enhancedSearchGuide', décrit plus haut au paragraphe 2.9. Chaque ensemble est une valeur de cet attribut multi-valeurs. (Source : X.520)

( 2.5.4.14 NAME 'searchGuide' SYNTAX 1.3.6.1.4.1.1466.115.121.1.25 )

1.3.6.1.4.1.1466.115.121.1.25 se réfère à la syntaxe Guide [RFC4517].

Exemple : "person#sn$EQ".

2.30 'seeAlso'

Le type d’attribut 'seeAlso' contient les noms distinctifs des objets qui se rapportent à l’objet sujet. Chaque nom d’objet en rapport est une valeur de cet attribut multi valeurs. (Source : X.520)

( 2.5.4.34 NAME 'seeAlso' SUP distinguishedName )

Exemple : L’objet personne "cn=James Brown,ou=employé,o=Widget\, Inc." se rapporte aux objets rôle "cn=Capitaine de l’équipe de Football,ou=activités patronnées,o=Widget\, Inc." et "cn=Equipe d’échecs,ou=activités patronnées,o=Widget\, Inc.". Comme les objets rôle se rapportent à l’objet personne, l’attribut 'seeAlso' contiendra le nom distinctif de chaque objet rôle dans des valeurs séparées.

2.31 'serialNumber'

Le type d’attribut 'serialNumber' contient les numéros de série des appareils. Chaque numéro de série est une valeur de cet attribut multi valeurs. (Source : X.520)

( 2.5.4.5 NAME 'serialNumber'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 )

1.3.6.1.4.1.1466.115.121.1.44 se réfère à la syntaxe Printable String [RFC4517].

Exemples : "WI-3005" et "XF551426".

2.32 'sn'

Le type d’attribut 'sn' ('surname' dans X.500) contient des chaînes de nom pour les noms de famille d’une personne. Chaque chaîne est une valeur de cet attribut multi valeurs. (Source : X.520)

( 2.5.4.4 NAME 'sn' SUP name )

Exemple : "Smith".

2.33 'st'

Le type d’attribut 'st' ('stateOrProvinceName' dans X.500) contient les noms complets des états ou provinces. Chaque nom est une valeur de cet attribut multi valeurs. (Source : X.520)

( 2.5.4.8 NAME 'st' SUP name )

Exemple : "California".

2.34 'street'

Le type d’attribut 'street' ('streetAddress' in X.500) contient les informations de site d’après une adresse postale (c’est-à-dire, le nom de la rue, place, avenue, et le numéro de la maison). Chaque rue est une valeur de cet attribut multi valeurs. (Source : X.520)

( 2.5.4.9 NAME 'street'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

1.3.6.1.4.1.1466.115.121.1.15 se réfère à la syntaxe Directory String [RFC4517].

Exemple : "15 Grand rue".

2.35 'telephoneNumber'

Le type d’attribut 'telephoneNumber' contient les numéros de téléphone qui sont conformes à la Recommandation UIT-T E.123 [E.123]. Chaque numéro est une valeur de cet attribut multi valeurs. (Source : X.520)

( 2.5.4.20 NAME 'telephoneNumber'
EQUALITY telephoneNumberMatch
SUBSTR telephoneNumberSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )

1.3.6.1.4.1.1466.115.121.1.50 se réfère à la syntaxe Telephone Number [RFC4517].

Exemple : "+1 234 567 8901".

2.36 'teletexTerminalIdentifier'

Ce type d’attribut ayant été retiré de la Recommandation F.200, il en résulte le retrait de cet attribut. (Source : X.520)

( 2.5.4.22 NAME 'teletexTerminalIdentifier'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.51 )

1.3.6.1.4.1.1466.115.121.1.51 se réfère à la syntaxe Teletex Terminal Identifier [RFC4517].

2.37 'telexNumber'

Le type d’attribut 'telexNumber' contient des ensembles de chaînes qui sont un numéro de télex, un code de pays, et un code de réponse d’un terminal télex. Chaque ensemble est une valeur de cet attribut multi valeurs. (Source : X.520)

( 2.5.4.21 NAME 'telexNumber'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.52 )

1.3.6.1.4.1.1466.115.121.1.52 se réfère à la syntaxe Telex Number [RFC4517].

Exemple : "12345$023$ABCDE".

2.38 'title'

Le type d’attribut 'title' contient le titre d’une personne dans son contexte organisationnel. Chaque titre est une valeur de cet attribut multi-valeurs. (Source : X.520])

( 2.5.4.12 NAME 'title' SUP name )

Exemples : "Vice président", "Ingénieur informatique", et "CEO".

2.39 'uid'

Le type d’attribut 'uid' ('userid' dans la RFC 1274) contient des noms d’amorce de système informatique associés à l’objet. Chaque nom est une valeur de cet attribut multi valeurs. (Source : RFC 2798 et RFC 1274])

( 0.9.2342.19200300.100.1.1 NAME 'uid'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

1.3.6.1.4.1.1466.115.121.1.15 se réfère à la syntaxe Directory String [RFC4517].

Exemples : "s9709015", "admin", et "Administrateur".

2.40. 'uniqueMember'

Le type d’attribut 'uniqueMember' contient les noms distinctifs d’un objet qui est sur une liste ou dans un groupe, et les noms distinctifs relatifs de l’objet incluent une valeur qui fait la différence entre les objets lorsqu’un nom distinctif a été réutilisé. Chaque nom distinctif est une valeur de cet attribut multi valeurs. (Source : X.520)

( 2.5.4.50 NAME 'uniqueMember'
EQUALITY uniqueMemberMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.34 )

1.3.6.1.4.1.1466.115.121.1.34 se réfère à la syntaxe Name et Optional UID [RFC4517].

Exemple : Si "ou=1st Battalion,o=Defense,c=US" est un bataillon qui a été dissout, et qu’on a établi un nouveau bataillon avec le "même" nom, il aurait ajouté une valeur d’identifiant unique, ce qui donnerait "ou=1st Battalion, o=Defense,c=US#'010101'B".

2.41 'userPassword'

Le type d’attribut 'userPassword' contient des chaînes d’octet qui ne sont connues que de l’utilisateur et du système auquel l’utilisateur a accès. Chaque chaîne est une valeur de cet attribut multi valeurs.

L’application DEVRAIT préparer des chaînes textuelles utilisées comme mots de passe en les transcodant en Unicode, en appliquant SASLprep [RFC4013], et en les codant en UTF-8. La détermination du caractère textuel d’un mot de passe est du ressort du client local. (Source : X.509)

( 2.5.4.35 NAME 'userPassword'
EQUALITY octetStringMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )

1.3.6.1.4.1.1466.115.121.1.40 se réfère à la syntaxe Octet String [RFC4517].

Les mots de passe sont mémorisés en utilisant une syntaxe Octet String et ne sont pas chiffrés. Le transfert de mots de passe en clair est fortement déconseillé lorsque le service de transport sous-jacent ne peut pas garantir la confidentialité et peut aboutir à la divulgation du mot de passe à des parties non autorisées.

Un exemple du besoin de plusieurs valeurs dans l’attribut 'userPassword' est un environnement dans lequel chaque mois l’utilisateur est censé utiliser un mot de passe différent généré par un système automatique. Durant les périodes de transition, comme le premier et le dernier jour de la période, il peut être nécessaire de permettre que deux mots de passe soient valides pour les deux périodes consécutives dans le système.

2.42 'x121Address'

Le type d’attribut 'x121Address' contient des adresses de réseau de données telles que définies par la Recommandation UIT-T X.121. Chaque adresse est une valeur de cet attribut multi valeurs. (Source : X.520)

( 2.5.4.24 NAME 'x121Address'
EQUALITY numericStringMatch
SUBSTR numericStringSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 )

1.3.6.1.4.1.1466.115.121.1.36 se réfère à la syntaxe Numeric String [RFC4517].

Exemple : "36111222333444555".

2.43 'x500UniqueIdentifier'

Le type d’attribut 'x500UniqueIdentifier' contient des chaînes binaires qui sont utilisées pour distinguer entre les objets lorsque un nom distinctif a été réutilisé. Chaque chaîne est une valeur de cet attribut multi-valeurs.

Dans X.520, ce type d’attribut est appelé 'uniqueIdentifier'. C’est un type d’attribut différent des deux types d’attribut LDAP 'uid' et 'uniqueIdentifier'. Le type d’attribut 'uniqueIdentifier' est défini dans la [RFC4524]. (Source : X.520)

( 2.5.4.45 NAME 'x500UniqueIdentifier'
EQUALITY bitStringMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 )

1.3.6.1.4.1.1466.115.121.1.6 se réfère à la syntaxe Bit String [RFC4517].

3. Classes d’objet

Les serveurs LDAP DEVRAIENT reconnaître toutes les classes d’objet dont la liste figure ici comme valeurs de l’attribut 'objectClass' (voir la RFC 4512]).

3.1 'applicationProcess'

La définition de classe d’objet 'applicationProcess' est la base d’une entrée qui représente une application qui s’exécute dans un système informatique. (Source : X.521)

( 2.5.6.11 NAME 'applicationProcess'
SUP top
STRUCTURAL
MUST cn
MAY ( seeAlso $ ou $ l $ description ) )

3.2 'country'

La définition de classe d’objet 'country' est la base d’une entrée qui représente un pays. (Source : X.521)

( 2.5.6.2 NAME 'country'
SUP top
STRUCTURAL
MUST c
MAY ( searchGuide $ description ) )

3.3 'dcObject'

La classe d’objet 'dcObject' permet à une entrée de contenir des informations de composant de domaine. Cette classe d’objet est définie comme auxiliaire, parce qu’elle sera utilisée en conjonction avec une classe d’objet structurelle existante. (Source : RFC 2247)

( 1.3.6.1.4.1.1466.344 NAME 'dcObject'
SUP top
AUXILIARY
MUST dc )

3.4 'device'

La classe d’objet 'device' est la base d’une entrée qui représente une application, un ordinateur, ou un élément de réseau. (Source : X.521)

( 2.5.6.14 NAME 'device'
SUP top
STRUCTURAL
MUST cn
MAY ( serialNumber $ seeAlso $ owner $ ou $ o $ l $ description ) )

3.5 'groupOfNames'

La classe d’objet 'groupOfNames' est la base d’une entrée qui représente un ensemble d’objets désignés qui incluent des informations qui se rapportent à l’objet ou à la maintenance de l’ensemble. (Source : X.521)

( 2.5.6.9 NAME 'groupOfNames'
SUP top
STRUCTURAL
MUST ( member $ cn )
MAY ( businessCategory $ seeAlso $ owner $ ou $ o $ description ) )

3.6 'groupOfUniqueNames'

La classe d’objet 'groupOfUniqueNames' est la même que la classe d’objet 'groupOfNames' sauf que les noms d’objet ne sont pas répétés ou réalloués dans le domaine d’application d’un ensemble. (Source : X.521)

( 2.5.6.17 NAME 'groupOfUniqueNames'
SUP top
STRUCTURAL
MUST ( uniqueMember $ cn )
MAY ( businessCategory $ seeAlso $ owner $ ou $ o $ description ) )

3.7 'locality'

La classe d’objet 'locality' est la base d’une entrée qui représente un endroit du monde physique. (Source : X.521)

( 2.5.6.3 NAME 'locality'
SUP top
STRUCTURAL
MAY ( street $ seeAlso $ searchGuide $ st $ l $ description ) )

3.8 'organization'

La classe d’objet 'organization' est la base d’une entrée qui représente un groupe de personnes structuré. (Source: X.521)

( 2.5.6.4 NAME 'organization'
SUP top
STRUCTURAL
MUST o
MAY ( userPassword $ searchGuide $ seeAlso $
businessCategory $ x121Address $ registeredAddress $
destinationIndicator $ preferredDeliveryMethod $
telexNumber $ teletexTerminalIdentifier $
telephoneNumber $ internationalISDNNumber $
facsimileTelephoneNumber $ street $ postOfficeBox $
postalCode $ postalAddress $ physicalDeliveryOfficeName $
st $ l $ description ) )

3.9 'organizationalPerson'

La classe d’objet 'organizationalPerson' est la base d’une entrée qui représente une personne dans sa relation à une organisation. (Source : X.521)

( 2.5.6.7 NAME 'organizationalPerson'
SUP person
STRUCTURAL
MAY ( title $ x121Address $ registeredAddress $
destinationIndicator $ preferredDeliveryMethod $
telexNumber $ teletexTerminalIdentifier $
telephoneNumber $ internationalISDNNumber $
facsimileTelephoneNumber $ street $ postOfficeBox $
postalCode $ postalAddress $ physicalDeliveryOfficeName $
ou $ st $ l ) )

3.10 'organizationalRole'

La classe d’objet 'organizationalRole' est la base d’une entrée qui représente un emploi, une fonction, ou une position dans une organisation. (Source : X.521)

( 2.5.6.8 NAME 'organizationalRole'
SUP top
STRUCTURAL
MUST cn
MAY ( x121Address $ registeredAddress $ destinationIndicator $
preferredDeliveryMethod $ telexNumber $
teletexTerminalIdentifier $ telephoneNumber $
internationalISDNNumber $ facsimileTelephoneNumber $
seeAlso $ roleOccupant $ preferredDeliveryMethod $
street $ postOfficeBox $ postalCode $ postalAddress $
physicalDeliveryOfficeName $ ou $ st $ l $ description ) )

3.11 'organizationalUnit'

La classe d’objet 'organizationalUnit' est la base d’une entrée qui représente une partie d’une organisation. (Source : X.521)

( 2.5.6.5 NAME 'organizationalUnit'
SUP top
STRUCTURAL
MUST ou
MAY ( businessCategory $ description $ destinationIndicator $
facsimileTelephoneNumber $ internationalISDNNumber $ l $
physicalDeliveryOfficeName $ postalAddress $ postalCode $
postOfficeBox $ preferredDeliveryMethod $
registeredAddress $ searchGuide $ seeAlso $ st $ street $
telephoneNumber $ teletexTerminalIdentifier $
telexNumber $ userPassword $ x121Address ) )

3.12 'person'

La classe d’objet 'person' est la base d’une entrée qui représente un être humain. (Source : X.521 [X.521])

( 2.5.6.6 NAME 'person'
SUP top
STRUCTURAL
MUST ( sn $ cn )
MAY ( userPassword $ telephoneNumber $ seeAlso $ description ) )

3.13 'residentialPerson'

La classe d’objet 'residentialPerson' est la base d’une entrée qui inclut la résidence d’une personne dans la représentation de la personne. (Source : X.521)

( 2.5.6.10 NAME 'residentialPerson'
SUP person
STRUCTURAL
MUST l
MAY ( businessCategory $ x121Address $ registeredAddress $
destinationIndicator $ preferredDeliveryMethod $
telexNumber $ teletexTerminalIdentifier $
telephoneNumber $ internationalISDNNumber $
facsimileTelephoneNumber $ preferredDeliveryMethod $
street $ postOfficeBox $ postalCode $ postalAddress $
physicalDeliveryOfficeName $ st $ l ) )

3.14 'uidObject'

La classe d’objet 'uidObject' permet qu’une entrée contienne des informations d’identification de l’utilisateur. Cette classe d’objet est définie comme auxiliaire, parce qu’elle sera utilisée e conjonction avec une classe d’objet structurelle existante. (Source : RFC 2377)

( 1.3.6.1.1.3.1 NAME 'uidObject' SUP top AUXILIARY MUST uid )

4. Considérations relatives à l’IANA

L’Autorité d’allocation des numéros de l’Internet (IANA) a mis à jour le registre des descripteurs LDAP comme indiqué dans le modèle suivant :

Sujet : Demande de mise à jour d’enregistrement de descripteur LDAP
Descripteur (abrégé) : voir les commentaires
Identifiant d’objet : voir les commentaires
Nom et adresse de messagerie de la personne à contacter pour les précisions : Andrew Sciberras <andrew.sciberras@eb2bcom.com>
Usage : (A = type d’attribut, O = classe d’objet) voir le commentaire
Spécification : RFC 4519
Auteur/Contrôleur de modifications : IESG

Commentaires
Dans le registre des descripteurs LDAP, les descripteurs suivants (abrégés) ont été mis à jour en référence à la RFC 4519. Les noms qui doivent être réservés, plutôt qu’alloués à un identifiant d’objet, contiendront une valeur d’identifiant d’objet de RÉSERVÉ.

5. Considérations sur la sécurité

Les attributs des entrées de répertoires servent à fournir des informations descriptives sur les objets réels qu’ils représentent, qui peuvent être des personnes, des organisations, ou des appareils. La plupart des pays ont des lois sur la confidentialité à propos de la publication d’informations sur les personnes.

Le transfert de mots de passe en clair est fortement déconseillé lorsque le service de transport sous-jacent ne peut pas garantir la confidentialité et l’intégrité, car il peut en résulter la divulgation du mot de passe à des personnes non autorisées.

Des valeurs d’attribut multiples pour l’attribut 'userPassword' doivent être utilisées avec une grande attention. En particulier l’établissement/suppression d’un mot de passe par un administrateur si il ne connaît pas le vieux mot de passe de l’utilisateur devient très compliqué ou impossible si des valeurs multiples sont présentes pour différentes applications.

Bien sûr, les applications qui entendent remplacer la ou les valeurs du 'userPassword' par un ou de nouvelles valeurs devraient utiliser modify/replaceValues (ou modify/deleteAttribute+addAttribute). De plus, les mises en œuvre de serveurs sont invitées à fournir des contrôles administratifs qui, s’ils sont activés, restreignent l’attribut 'userPassword' à une seule valeur.

Noter que pour les besoins de l’authentification [RFC4513], l’utilisateur a seulement besoin de prouver qu’il connaît une des valeurs, pas toutes les valeurs.

6. Remerciements

Les définitions sur lesquelles se fonde le présent document ont été développées par les comités pour les télécommunications et les normes internationales.

Le préent document est une mise à jour de la RFC 2256 par Mark Wahl. La RFC 2256 a été produite par le groupe de travail ASID de l’IETF.

La définition de type d’attribut 'dc' et la définition de classe d’objet 'dcObject' du présent document remplace celle de la RFC 2247 par S. Kille, M. Wahl, A. Grimstad, R. Huber, et S. Sataluri.

La définition de type d’attribut 'uid' du présent document remplace la spécification du 'userid' de la RFC 1274 par P. Barker et S. Kille et de l’uid de la RFC 2798 par M. Smith.

La définition de calsse d’objet 'uidObject' du présent document remplace la spécification de 'uidObject' de la RFC 2377 par A. Grimstad, R. Huber, S. Sataluri, et M. Wahl.

Le présent document se fonde sur des contributions du groupe de travail LDAPBIS de l’IETF. L’auteur souhaite remercier S. Legg et K. Zeilenga pour leur contribution significative à cette mise à jour. L’auteur adresse aussi ses remerciements à Kathy Dally, qui a édité les premières versions de ce document.

7. Références

7.1 Références normatives

[E.123] Recommandation UIT-T E.123, 1988 : Notation des numéros de téléphone nationaux et internationaux

[E.164] Recommandation UIT-T E.164, 1997 : Plan de numérotation des télécommunications publiques internationales

[F.1] Recommandation UIT-T F.1, 1992 : Dispositions applicables à l'exploitation du service public international des télégrammes

[F.31] Recommandation UIT-T F.31, 1988 : Système à retransmission de télégrammes

[ISO3166] ISO 3166, "Codes de représentation des noms de pays".

[RFC1034] Mockapetris, P., "Noms de domaines - concepts et facilités", STD 13, RFC 1034, novembre 1987.

[RFC1123] Braden, R., "Exigences pour les hôtes Internet - Application et prise en charge", STD 3, RFC 1123, octobre 1989.

[RFC2119] Bradner, S., "Mots clés à utiliser dans les RFC pour indiquer les niveaux d’exigence", BCP 14, RFC 2119, mars 1997.

[RFC2181] Elz, R. et R. Bush, "Clarifications à la spécification DNS", RFC 2181, juillet 1997.

[RFC3490] Faltstrom, P., Hoffman, P., et A. Costello, "Internationalisation des noms de domaines dans les applications (IDNA)", RFC 3490, mars 2003.

[RFC4013] Zeilenga, K., "SASLprep : Profil Stringprep pur les noms d’utilisateur et les mots de passe", RFC 4013, février 2005.

[RFC4234] Crocker, D. et P. Overell, "BNF augmenté pour les spécifications de syntaxe : ABNF", RFC 4234, octobre 2005.

[RFC4510] Zeilenga, K., Ed., "Protocole léger d’accès à un répertoire (LDAP) : Guide des spécifications techniques", RFC 4510, juin 2006.

[RFC4512] Zeilenga, K., "Protocole léger d’accès à un répertoire (LDAP) : Modèles d’informations de répertoire", RFC 4512, juin 2006.

[RFC4517] Legg, S., Ed., "Protocole léger d’accès à un répertoire (LDAP) : Syntaxes et règles de correspondance", RFC 4517, juin 2006.

[X.121] Recommandation UIT-T X.121, 1996 Plan de numérotage international pour les réseaux publics pour données

[X.509] Recommandation UIT-T X.509, 1993 Technologies de l'information – Interconnexion des systèmes ouverts – L'annuaire: cadre général des certificats de clé publique et d'attribut

[X.520] Recommandation UIT-T X.520, 1993 Technologies de l'information – Interconnexion des systèmes ouverts – L'annuaire: types d'attributs sélectionnés

[X.521] Recommandation UIT-T X.521, 1993 Technologies de l'information – Interconnexion des systèmes ouverts – L'annuaire: classes d'objets sélectionnées

7.2 Références informatives

[RFC1274] Barker, P. et S. Kille, "Schéma X.500 COSINE et Internet", RFC 1274, novembre 1991.

[RFC2247] Kille, S., Wahl, M., Grimstad, A., Huber, R., et S. Sataluri, "Utilisation des domaines dans les noms distinctifs LDAP/X.500", RFC 2247, janvier 1998.

[RFC2377] Grimstad, A., Huber, R., Sataluri, S., et M. Wahl, "Plan de dénominations pour les applications Internet à capacité de répertoire", RFC 2377, septembre 1998.

[RFC2798] Smith, M., "Définition de la classe d’objet LDAP inetOrgPerson", RFC 2798, avril 2000.

[RFC4513] Harrison R., Ed., "Protocole léger d’accès à un répertoire (LDAP) : Méthodes d’authentification et mécanismes de sécurité", RFC 4513, juin 2006.

[RFC4523] Zeilenga, K., "Protocole léger d’accès à un répertoire (LDAP) : Définitions de schéma pour les certificats X.509", RFC 4523, juin 2006.

[RFC4524] Zeilenga, E., Ed., "Schéma LDAP/X.500 pour COSINE", RFC 4524, juin 2006.

[X.500] Recommandation UIT-T X.500 (1993) | ISO/CEI 9594-1:1994, Technologies de l'information – Interconnexion des systèmes ouverts – L'annuaire: aperçu général des concepts, modèles et services

Appendice A Changements effectués depuis la RFC 2256

Le présent appendice fait la liste des changements qui sont survenus de la RFC 2256 à la RFC 4519.

Cet appendice n’est pas une partie normative de la présente spécification, et il n’est fourni que pour des besoins d’information.

1. Remplacement du titre du document.

2. Retrait de la note de l’IESG.

3. La relation avec la RFC 1274 a été éliminée.

4. Ajout d’une section de Considérations de sécurité et d’une section Considérations relatives à l’IANA.

5. Suppression de l’exigence de conformité pour les classes d’objet de sous-schéma en faveur d’une déclaration dans la [RFC4517].

6. Ajout d’explication aux types d’attribut et à chaque classe d’objet.

7. Retrait de la Section 4, Syntaxes, et de la Section 6, Règles de correspondance, (passées à la [RFC4517]).

8. Retrait des types d’attribut en relation avec les certificats :
authorityRevocationList, cACertificate,
certificateRevocationList, crossCertificatePair,
deltaRevocationList, supportedAlgorithms, et userCertificate.

Retrait des classes d'objet en relation avec les certificats :
certificationAuthority, certificationAuthority-V2,
cRLDistributionPoint, strongAuthenticationUser, et
userSecurityInformation

LDAP PKI est maintenant exposé dans la [RFC4523].

9. Retrait des types d’attribut dmdName, knowledgeInformation, presentationAddress, protocolInformation, et supportedApplicationContext et des classes d’objet dmd, applicationEntity, et dSA.

10. Suppression des définitions de type d’attribut aliasedObjectName et objectClass. Suppression des définitions de classe d’objet alias et top. Elles sont incluses dans la [RFC4512].

11. Ajout du type d’attribut 'dc' provenant de la RFC 2247, qui fait une distinction entre les valeurs 'stored' et 'query' lors de la préparation des chaînes IDN.

12. Nombreux changements rédactionnels.

13. Suppression de la limite supérieure après l’oid SYNTAX dans toutes les définitions d’attribut où elle apparaissait.

14. Ajout d’un texte sur Unicode, SASLprep [RFC4013], et UTF-8 pour userPassword.

15. Inclusion des définitions, commentaires et références sur 'dcObject' et 'uidObject'.

16. Remplacement des références de schéma PKI par celle de la RFC 4523.

17. ABNF épelé et référencé à la première utilisation.

18. Retrait du paragraphe 2.4 (Source). Remplacement du tableau source avec des références explicites pour chaque définition.

19. Toutes les références à un type d’attributou classe d’objet sont incluses dans des guillemets simples.

20. La présentation des définitions de type d’attribut a été changée pour en assurer la cohérence tout au long du document :
> En-tête de paragraphe
> Description du type d’attribut
> Description de valeurs multiples
> Informations de source
> Définition
> Exemple
> Commentaires supplémentaires

L’ajout de cette présentation cohérente inclut l’ajout d’exemples à certaines définitions.

21. Fourniture de références à des noms de rempacement pour des types d’attributs avec une référence à l’endroit de leur spécification d’origine.

22. Clarification de la description de 'distinguishedName' et 'name', lorsque ces types d’attribut sont des super types.

23. RNS épelé à sa première utilisation.

24. Insertion d’une référence à la [RFC4517] pour l’OID SYNTAX de la définition de 'teletexTerminalIdentifier'.

25. Ajout de noms supplémentaires aux Considérations relatives à l’IANA. Les noms incluent 'commonName', 'dcObject', 'domainComponent', 'GN', 'localityName', 'organizationName', 'organizationUnitName', 'surname', 'uidObject' et 'userid'.

26. Remplacement de toutes les instances de supercede par supersede.

27. Déplacement de [F.1], [F.31] et [RFC4013] des références informatives à normatives.

28. Changement de la définition de 'c' pour être cohérent avec X.500.

Adresse de l’auteur

Andrew Sciberras
eB2Bcom
Suite 3, Woodhouse Corporate Centre,
935 Station Street,
Box Hill North, Victoria 3129
AUSTRALIA
Téléphone : +61 3 9896 7833
mél : andrew.sciberras@eb2bcom.com

Déclaration de copyright

Copyright (C) The Internet Society (2006).

Le présent document est soumis aux droits, licences et restrictions contenus dans le BCP 78, et à www.rfc-editor.org, et sauf pour ce qui est mentionné ci-après, les auteurs conservent tous leurs droits.

Le présent document et les informations y contenues sont fournies sur une base "EN L’ÉTAT" et LE CONTRIBUTEUR, L’ORGANISATION QU’IL OU ELLE REPRÉSENTE OU QUI LE/LA FINANCE (S’IL EN EST), LA INTERNET SOCIETY ET LA INTERNET ENGINEERING TASK FORCE DÉCLINENT TOUTES GARANTIES, EXPRIMÉES OU IMPLICITES, Y COMPRIS MAIS NON LIMITÉES À TOUTE GARANTIE QUE L’UTILISATION DES INFORMATIONS CI-ENCLOSES NE VIOLENT AUCUN DROIT OU AUCUNE GARANTIE IMPLICITE DE COMMERCIALISATION OU D’APTITUDE À UN OBJET PARTICULIER.

Propriété intellectuelle

L’IETF ne prend pas position sur la validité et la portée de tout droit de propriété intellectuelle ou autres droits qui pourrait être revendiqués au titre de la mise en œuvre ou l’utilisation de la technologie décrite dans le présent document ou sur la mesure dans laquelle toute licence sur de tels droits pourrait être ou n’être pas disponible ; pas plus qu’elle ne prétend avoir accompli aucun effort pour identifier de tels droits. Les informations sur les procédures de l’ISOC au sujet des droits dans les documents de l’ISOC figurent dans les BCP 78 et BCP 79.

Des copies des dépôts d’IPR faites au secrétariat de l’IETF et toutes assurances de disponibilité de licences, ou le résultat de tentatives faites pour obtenir une licence ou permission générale d’utilisation de tels droits de propriété par ceux qui mettent en œuvre ou utilisent la présente spécification peuvent être obtenues sur répertoire en ligne des IPR de l’IETF à http://www.ietf.org/ipr.

L’IETF invite toute partie intéressée à porter son attention sur tous copyrights, licences ou applications de licence, ou autres droits de propriété qui pourraient couvrir les technologies qui peuvent être nécessaires pour mettre en œuvre la présente norme. Prière d’adresser les informations à l’IETF à ietf-ipr@ietf.org.

Remerciement

Le financement de la fonction d’édition des RFC est fourni par la Administrative Support Activity (IASA) de l'IETF.