Apparence
Uubu.fr

Les systèmes Linux, l’open source, les réseaux, l’interopérabilité, etc.
« Il vaut mieux viser la perfection et la manquer que viser l’imperfection et l’atteindre. » (Bertrand Arthur William RUSSEL)
28 July 2015

htmlpdflatexmanmd

chiffrement sécurité certificats           Public Key Infrastructure


rfc3739

rfc3739

Profile de certificats qualifiés

   Ce document forme un profile de certificat, basé sur la rfc3280, pour les certificat d'identité émis à des personnes naturelles.

   Le profile définis les conventions spécifiques pour les certificats qui sont qualifiés avec un framework définis, les Certificat Qualifiés nommés. Cependant, le profile ne définis aucune exigence légale pour de tels certificats qualifiés.

   Le but de ce document est de définir un profile de certificat qui supporte l'émission de certificat qualifiés indépendamment des exigences légales. Le profile n'est cependant pas limité aux certificats qualifiés et le profile peut simplifier les besoins locaux.

   Cette spécification fait partie d'une famille de standards pour la PKI X.509 de l'Internet. Elle est basées sur X.509 et la rfc3280, qui définissent les formats de certificat sous-jacent nécessaire à l'implémentation complète de ce standard.

Exigences et hypothèses

   Ce terme "Qualified Certificate" est utilisé par la directive européenne pour les signature électroniques (EU-ESDIR) pour référer à un type spécifique de certificats, en conformité avec la législation européenne sur la signature électronique. Cette spécification est prévue pour supporter cette classe de certificats, mais son périmètre n'est pas limité à cette application.

   Dans ce standard, le terme "Qualified Certificate" est utilisé généralement, décrivant un certificat dont le but premier est d'identifier une personne avec un haut niveau d'assurance, où le certificat répond à des exigences de qualification définie par un framework légale applicable, tels que la directive européenne sur la signature électronique. Les mécanismes actuels qui décident si un certificat devrait ou non être considéré comme certificat qualifié au regard de la législation est hors du périmètre de ce standard.

   L'harmonisation dans le champs des certificats d'identité émis aux personnes naturelles, en particulier les certificats qualifiés, est essentiel dans de nombreux aspects qui sont hors du périmètre de la rfc3280. Les aspects les plus important qui affectent le périmètre de cette spécification sont:

- Définition des noms et informations d'identité pour pouvoir identifier le sujet associé d'une manière uniforme
- Définition des informations qui identifient la CA et la juridiction sous laquelle la CA opère en émettant un certificat particulier.
- Définition de l'extension d'utilisation de clé pour les certificats qualifiés
- Définition de la structure d'informations pour le stockage d'informations biométriques.
- Définition d'une méthode standardisée de stocker des états pré-définis d'intérêt pour des certificats qualifiés.
- Exigences pour les extensions critiques

Propriétés

   Ce profile adapte les besoins de profilage pour les certificats qualifiés basés sur les hypothèses que:

- Les certificats qualifiés sont émis par une CA qui qui déclare que le certificat sert le but d'un certificat qualifié
- Le certificat qualifié indique une stratégie de certificat conforme aux engagements, pratiques, et procédures entrepris par la CA.
- Le certificat qualifié est émis à une personne naturelle.
- Le certificat qualifié contient un nom qui peut être soit basé sur le vrai nom du sujet ou un pseudonyme.

Déclaration d'intention

   Ce profile définis les conventions pour déclarer dans un certificat qu'il sert l'objectif d'être un certificat qualifié. Cela permet à la CA de définir explicitement cette intention.

   Ce profile définis 2 méthodes pour inclure cette information:

- Comme information définie par une stratégie de certificat inclue dans l'extension de stratégies de certificat
- Comme déclaration inclue dans l'extension de déclaration de certificats qualifiés.

problématique de stratégie

   Certains aspects de stratégie définissent le contexte dans lequel ce profile est compris et utilisé. Il est cependant en dehors du scope de ce profile de spécifier une stratégie ou les aspects légaux qui vont gouverner les services qui émettent ou utilisent les certificat en accord avec ce profile.

   C'est cependant un hypothèse sous-jacente dans ce profile qu'une CA émettrice responsable va entreprendre de suivre une stratégie de certificat qui est consistante avec ses engagements, pratiques et procédure.

Unicité des noms

   Les noms distincts sont initialement définis dans X.501 comme représentation d'un nom d'annuaire, définis comme une construction qui identifie un objet particulier parmi un ensemble de tous les objets. Le nom distinct doit être unique pour chaque sujet certifié par une CA comme définie par le champ issuer, pour toute la durée de vie d'une CA.

Profile de certificat et d'extensions de certificat

   Cette section définis les conventions de profile de certificat. Le profile est basé sur le profile de certificat de l'Internet (rfc3280), qui lui-même est basé sur le format X.509v3. Pour une implémentation complète de cette section, les implémenteurs doivent consulter les formats et sémantiques définies dans la rfc3280.

Champs de certificat de base

   Cette section fournis des détails au regard du contenu de 2 champs dans le certificat de base. Ces champs sont issuer et subject.

Issuer

   Le champ issuer devrait identifier l'organisation responsable de l'émission du certificat. Le nom devrait être un nom officiellement enregistré de l'organisation.

   Le nom distinct de l'émetteur devrait être spécifié en utilisant le sous-jeu approprié les attributs suivants:

domainComponent
countryName
stateOrProvinceName
organizationName
localityName
serialNumber

   L'attribut domainComponent est définis dans la rfc2247, tous les autres attributs sont définis dans la rfc3280 et X.520.

   Des attributs additionnels peuvent être présent, mais ils ne doivent pas être nécessaires pour identifier l'organisation émettrice.

   Un tiers de confiance peut avoir à consulter les stratégies de certificat associés et/ou la CPS de l'émetteur, pour pouvoir déterminer les sémantiques du nom des champs.

Subject

   Le champs subject d'un certificats conforme avec ce profile devrait contenir un nom distinct du sujet. Le champ subject devrait contenir un sous-jeu des attributs suivants:

domainComponent
countryName
commonName
surname
givenName
pseudonym
serialNumber
title
organizationName
organizationUnitName
stateOrProvinceName
localityName

   Des attributs additionnels peuvent être présent, mais ils ne doivent pas être nécessaires pour distinguer un nom de sujet d'un autre nom de sujet. C'est à dire, les attributs listés ci-dessus sont suffisant pour s'assurer de l'unicité des noms de sujet.

   De ces attributs, le champs sujet devrait inclure au moins un des suivants:

Choix I: commonName
Choix II: givenName
Choix III: pseudonym

   La valeur de l'attribut countryName spécifie un contexte général dans lequel d'autres attributs sont compris. L'attribut country n'indique pas nécessairement le pays de citoyenneté ou de résidence du sujet, ni n'indique le pays d'émission.

   Note: de nombreuses implémentations X.500 nécessitent la présence de countryName dans le DIT. Dans les cas où le nom du sujet, comme spécifié dans le champ subject, spécifie une entrée d'annuaire X.500, l'attribut countryName devrait toujours être présent.

   L'attribut commonName devrait, si présent, contenir un nom du sujet. Cela peut être dans le format de présentation préféré du sujet, ou un format préféré par la CA, ou un autre format. Les pseudonymes, surnoms, et noms ayant une orthographe autre que définie par le nom enregistré peut être utilisé. Pour comprendre la nature du nom présenté dans commonName, les applications conformes peuvent avoir à examiner les valeurs présentes des attributs givenName et surname, ou l'attribut pseudonym.

   Note: de nombreuses implémentations client pré-supposent la présence de la valeur de l'attribut commonName dans le champ subject et utilisent cette valeur pour afficher le nom du sujet sans regarder la présence de givenName, surname, ou pseudonym.

   Les types d'attribut surname et givenName devraient être utilisés dans le champ suject si ni l'attribut commonName ni l'attribut pseudonym n'est présent. Dans les cas où le sujet a seulement givenName, l'attribut surname devrait être omis.

   Le type d'attribut pseudonym devrait, si présent, contenir un pseudonyme du sujet. L'utilisation de l'attribut pseudonym ne doit pas être combiné avec l'utilisation de l'attribut surname et/ou givenName.

   Le type d'attribut serialNumber devrait, si présent, être utilisé pour différencier entre les noms où le champ subject serait sinon identique. Cet attribut n'a pas de sémantique définie au-delà de s'assurer de l'unicité des noms des sujets. Il peut contenir un nombre ou un code assigné par la CA ou un identifiant assigné par un gouvernement ou une autorité civile. C'est de la responsabilité de la CA de s'assurer que le serialNumber est suffisant à résoudre toute collision du nom du sujet.

   Le type d'attribut title devrait, si présent, être utilisé pour stocker une position désignée ou fonction ou sujet dans l'organisation spécifiée par les attributs organisationnelle présent dans le champs subject. L'association entre le titre, le sujet, et l'organisation est au-delà du périmètre de ce document.

   Les types d'attribut organizationName et organizationalUnitName, si présents, sont utilisé pour stocker le nom et les informations essentielles d'une organisation avec lequel le sujet est associé. Le type d'association entre l'organisation et le sujet est au-delà du périmètre de ce document.

   Les types d'attribut stateOrProvinceName et localityName devraient, si présents, être utilisés pour stocker les information géographiques avec lequel le sujet est associé. Si une valeur organizationName est également présente, les valeurs d'attribut stateOrProvinceName et localityName devraient être associés avec l'organisation spécifiée. Le type d'association entre stateOrProvinceName et localityName et soit le subject ou organizationName est au-delà du périmètre de ce document.

   Les implémentations conformes devraient être capable d'interpréter les attributs nommés dans cette section.

Extensions de certificat

   Cette section fournis des détails additionnels sur le contenu des 4 extensions de certificats définis dans la rfc3280: subjectAltName, subjectDirectoryAttributes, certificate policies, et key usage. Cette section définis également 2 extensions additionnelles: informations biométriques et déclaration de certificat qualifié.

Subject Alternative Name

   Si l'extension subjectAltName est présent, et qu'elle contient un directoryName, alors le directoryName doit suivre la convention spécifié dans la section subject plus haut dans ce document.

Subject Directory Attributes

   L'extension subjectDirectoryAttributes peut être présente et peut contenir des attributs additionnels associés avec le sujet, comme complément aux informations présentes dans le champ subject et l'extension subjectAltName.

   Les attributs prévus pour le stockage dans cet extension sont les attributs qui ne font pas partie du nom distinct du sujet, mais qui peuvent être utiles pour d'autres buts (ex: autorisation). Cette extension ne doit pas être marquée critique.

   Les implémentations conformes devraient être capable d'interpréter les attributs suivants:

- dateOfBirth
- placeOfBirth
- gender
- countryOfCitizenship
- countryOfResidence

   D'autres attributs peuvent être inclus en accord avec les définitions locales.

   L'attribut dateOfBirth devrait, si présent, contenir la valeur de la date de naissance du sujet. La manière dans laquelle la date de naissance est associée avec le sujet est hors du périmètre de ce document. La date de naissance est définis au format GeneralizedTime et devrait préciser GMT 12.00.00 (midi) jusqu'à la granularité des secondes, pour empêcher les changements de date accidentels lié aux ajustement de zone. Par exemple, une date de naissance du 27 Septembre 1959 est encodé "19590927120000Z". Une application qui lit un certificat conforme devrait ignorer toute donnée de temps et simplement présenter la date contenue sans ajustement de zone.

   L'attribut placeOfBirth devrait, si présent, contenir la valeur du lieu de naissance du sujet. La manière dans laquelle le lieu de naissance est associé avec le sujet est au-delà du périmètre de ce document.

   L'attribut gender devrait, si présent, contenir la valeur du genre du sujet. Pour une femme la valeur 'F' ou 'f', et pour un homme la valeur 'M' ou 'm', doivent être utilisés. La manière dont le genre est associé avec le sujet est hors du périmètre de ce document.

   L'attribut countryOfCitizenship devrait, si présent, contenir l'identifiant d'au-moins un des pays de citoyenneté du sujet au moment où le certificat a été délivré. Si plus d'un pays est spécifié, chaque pays devrait être spécifié via un attribut countryOfCitizenship séparé. La détermination de la citoyenneté est une question de droit et est hors du périmètre de ce document.

   L'attribut countryOfResidence devrait, si présent, contenir la valeur d'au-moins un pays dans lequel le sujet réside. Si plus d'un pays de résidence est spécifié, chaque pays de résidence devrait être spécifié via un attribut countryOfResidence séparé. La détermination de résidence est une question de droit et est hors du périmètre de ce document.

Stratégies de certificat

   L'extension de stratégie de certificat devrait être présent et devrait contenir l'identifiant d'au-moins une stratégie de certificat qui reflète les pratiques et procédures utilisées par la CA. L'extension de stratégie de certificat peut être marquée comme critique.

   Les informations fournies par l'émetteur statuant le but du certificat, devrait être évident au travers de la stratégie indiquée.

   L'extension de stratégie de certificat doit inclure toutes les informations de stratégie nécessaire pour la validation de chemin de certification. Si les déclarations de stratégie connexes sont incluses dans l'extension QCStatements, alors ces déclarations devraient également être contenues dans les stratégies identifiées.

   Les stratégies de certificat peuvent être combinées avec tout qualifiant définis dans la rfc3280.

Utilisation de clé

   L'extension d'utilisation de clé devrait être présent. Les paramètres d'utilisation de clé devraient être définis en accord avec les définitions de la rfc3280. D'autres exigences sur les paramètres d'utilisation de clé peuvent être définis par stratégie locale et/ou exigences légales. L'extension d'utilisation de clé devrait être marqué critique.

Informations biométriques

   Cette section définis une extension optionnelle pour stocker les informations biométriques. Les informations biométriques sont stockés sous la forme d'un hash d'un modèle biométrique.

   Le but de cette extension est de fournir un moyen pour l'authentification d'information biométrique. Les informations biométriques qui correspondent au hash stocké ne sont pas stockés dans cette extension, mais l'extension peut inclure une URI (sourceDataUri) qui référence un fichier contenant cette information.

   Si inclus, l'URI doit utiliser le schéma http:// ou https://. Vu que les données d'identification en cours de vérification peuvent elles-même être des information sensibles, ceux qui déploient ce mécanisme peuvent également souhaiter considérer l'utilisation des URI qui ne peuvent pas être facilement liés par des tiers aux identités de ceux dont l'information est en cours de récupération.

   L'utilisation de l'option URI assume que le format d'encodage des données du contenu du fichier est déterminé via des moyens au-delà du périmètre de cette spécification, tel que les conventions de nommage de fichier et les méta-données dans le fichier. L'utilisation de cette URI n'implique pas que c'est la seule manière d'accéder à cette information.

   Il est recommandé que les informations biométriques dans cette extension soient limitées aux types d'informations utilisable pour la vérification humaine, par ex., lorsque la décision de savoir si l'information est une représentation précise du sujet est effectuée naturellement par une personne. Cela implique une utilisation où les informations biométriques soient représentée par, par exemple, une image affichée par le tiers de confiance, qui peut être utilisé par le tiers de confiance pour améliorer l'identification du sujet.

Cette extension ne doit pas être marquée critique.
biometricInfo EXTENSION ::= {
    SYNTAX BiometricSyntax
    IDENTIFIED BY id-pe-biometricInfo }
    
id-pe-biometricInfo OBJECT IDENTIFIER ::= {id-pe 2}
    
BiometricSyntax ::= SEQUENCE OF BiometricData
    
BiometricData ::= SEQUENCE {
    typeOfBiometricData TypeOfBiometricData,
    hashAlgorithm AlgorithmIdentifier,
    biometricDataHash OCTET STRING,
    sourceDataUri IA5String OPTIONAL }
    
TypeOfBiometricData ::= CHOICE {
    predefinedBiometricType PredefinedBiometricType,
    biometricDataID OBJECT IDENTIFIER }
    
PredefinedBiometricType ::= INTEGER { picture(0),
    handwritten-signature(1)} (picture|handwritten-signature,...)
    

   L'image de type biométrique prédéfinie, si présent, devrait identifier que l'image source est sous la forme d'une image graphique affichable du sujet. Le hash de l'image graphique devrait être calculée sur tout le fichier image référencé.

   L'handwritten-signature de type biométrique prédéfinis, si présent, devrait identifier que la source de donnée est sous la forme d'une image graphique affichable de la signature manuscrite du sujet. Le hash de l'image graphique devrait être calculé sur tout le fichier image référencé.

Déclaration de certificat qualifié

   Cette section définis une extension optionnelle pour inclure les déclaration de propriétés explicites du certificat.

   Chaque déclaration devrait inclure un identifiant d'objet pour la déclaration et peut également inclure une donnée qualifiante optionnelle contenue dans le paramètre statementInfo.

   Si le paramètre statementInfo est inclus, alors l'identifiant d'objet de la déclaration devrait définir la syntaxe et devrait définir les sémantiques de ce paramètre. Si l'identifiant d'objet ne définis pas les sémantiques, un tiers de confiance peut avoir à consulter une stratégie de certificat ou CPS pour déterminer les sémantiques exactes.

   Cette extension peut être critique ou non. Si l'extension est critique, cela signifie que toutes les déclarations inclues dans l'extension sont considérés comme critique.


qcStatements EXTENSION ::= {
    SYNTAX QCStatements
    IDENTIFIED BY id-pe-qcStatements }
    
-- Note: cette extension en permet pas de mixer les déclarations de certificat qualifiés
-- critique et non-critique. Soit tout est critique, soit tous sont non-critique.
    
id-pe-qcStatements OBJECT IDENTIFIER ::= { id-pe 3 }
    
QCStatements ::= SEQUENCE OF QCStatement
QCStatement ::= SEQUENCE {
    statementId QC-STATEMENT.&Id({SupportedStatements}),
    statementInfo QC-STATEMENT.&Type({SupportedStatements}{@statementId}) OPTIONAL }
    
SupportedStatements QC-STATEMENT ::= { qcStatement-1,...}

   Une déclaration approprié pour cette extension peut être une déclaration par l'émetteur que le certificat est émis comme certificat qualifié en accord avec un système légal particulier.

   D'autres déclarations appropriés pour cette extension peuvent être des déclaration liées aux juridictions légales applicables dans lequel le certificat est émis. Par exemple, on peut inclure une limite de confiance maximale pour le certificat indiquant les restrictions de la responsabilité de la CA.

Déclaration prédéfinies

   La déclaration de certificat (id-qcs-pkixQCSyntax-v1), identifie la conformité avec les exigences définis dans la rfc3039 obsolète. Cet déclaration est fournie pour l'identification des anciens certificats émis en conformité avec la rfc3039. Cette déclaration ne doit pas être inclue dans les certificats émis en accord avec ce profile.

   Ce profile inclus une nouvelle déclaration de certificat qualifié (identifié par l'OID id-qcs-pkixQCSyntax-v2), identifiant la conformité avec les exigences définies dans ce profile. Ce profile de certificat qualifié est référé à la version 2.

Cette déclaration identifie la conformité avec les exigences de la rfc3039. Cette déclaration peut optionnellement contenir des informations de sémantique additionnelles comme spécifié plus bas:
qcStatement-1 QC-STATEMENT ::= { SYNTAX SemanticsInformation IDENTIFIED BY id-qcs-pkixQCSyntax-v1 }

Cette déclaration identifie la conformité avec les exigences définis dans ce profile de certificat qualifié. Cette déclaration peut optionnellement contenir des informations de sémantiques additionnelles comme spécifié plus bas:
qcStatement-2 QC-STATEMENT ::= { SYNTAX SemanticsInformation IDENTIFIED BY id-qcs-pkixQCSyntax-v2 }
    
SemanticsInformation ::= SEQUENCE {
    semanticsIdentifier OBJECT IDENTIFIER OPTIONAL,
    nameRegistrationAuthorities NameRegistrationAuthorities OPTIONAL }
    (WITH COMPONENTS {..., semanticsIdentifier PRESENT}|
    WITH COMPONENTS {..., nameRegistrationAuthorities PRESENT})
    
NameRegistrationAuthorities ::= SEQUENCE SIZE (1..MAX) OF GeneralName

   Le composant SemanticsInformation identifié par id-qcs-pkixQCSyntax-v1 peut contenir un identifiant de sémantique et peut identifier un ou plusieurs nom d'autorité d'enregistrement.

   Le composant semanticsIdentifier, si présent, devrait contenir un OID, définissant les sémantiques pour les attributs et les noms dans les champs de base du certificat et les extensions. L'OID peut définir les sémantiques pour tout, ou pour un sous-groupe de tous les attributs présents et/ou les noms.

   Le composant NameRegistrationAuthorities, si présent, devrait contenir un nom d'une ou plusieurs autorité d'enregistrement, responsable pour l'enregistrement des attributs ou noms associés avec le sujet. L'association entre un nom identifié d'autorité d'enregistrement et les attributs présents peuvent être définis par un OID de sémantique, par une CP ou CPS, ou autre facteurs implicites.

   Si une valeur de type SemanticsInformation est présente dans un QCStatement où le composant statementID est mis à id-qcs-pkig-QCSyntax-v1 ou id-qcs-pkix-QCSyntax-v2, alors au moins un des champs semanticsIdentifier ou nameRegistrationAuthorities doit être présent, comme indiqué. Noter que le composant statementInfo ne doit pas être présent dans une valeur QCStatement même si le composant statementID est mis à id-qcs-pkix-QCSyntax-v1 ou id-qcs-pkix-QCSyntax-v2.

Considérations de sécurité

   La valeur légale d'une signature numérique qui est validée avec un certificat qualifié dépend hautement de la stratégie gouvernant l'utilisation de la clé privée associée. Le propriétaire de la clé privée, et le tiers de confiance, devraient s'assurer que la clé privée est utilisée uniquement avec le consentement du propriétaire légitime de la clé.

   Vu que les clés publiques sont pour une utilisation publique avec des implications légales pour les parties concernées, certaines conditions devraient exister avant qu'une CA émette des certificat comme certificats qualifiés. Les clés privées associées doivent être unique pour le sujet, et doivent être maintenue sous le contrôle exclusif du sujet. C'est à dire, une CA ne devrait pas émettre un certificat qualifié si les moyens d'utiliser une clé privée ne sont pas protégés contre les utilisation non-prévues. Cela implique que la CA ait une certaine connaissance du module cryptographique du sujet.

   La CA doit de plus vérifier que la clé publique contenue dans le certificat représente légitimement le sujet.

   La CA ne devrait pas émettre de certificats CA avec les extensions de mappage de stratégie indiquant l'acceptation d'une autre stratégie de CA sauf si les conditions sont rencontrées.

   En combinant le bit de nonRepudiation dans l'extension d'utilisation de clé avec d'autres bits d'utilisation de clé peut avoir des implication de sécurité en fonction du contexte dans lequel le certificat est utilisé. Les applications validant les signature électronique basés sur de tels certificats devraient déterminer si la combinaison d'utilisation de clé est approprié pour leur utilisation.

   La capacité de comparer 2 certificats qualifiés pour déterminer s'ils représentent la même entité physique est dépendante des sémantiques des noms des sujets. Les sémantiques d'une attribut particulier peut être différent pour différent émetteurs. En comparant les noms sans connaître les sémantiques des noms dans ces certificats particulier peut fournir de faux résultats.

   Cette spécification est un profile de la rfc3280. Les considérations de sécurité de ce document s'appliquent à cette spécification également.