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)

19 octobre 2013

Cyrus SASL

Serveur SASL de Cyrus

Composants SASL

Le premier composant de la librairie SASL est la couche Glue. Il s'occupe des tâches de base:

- Charger les plugins
- Gère les propriétés de sécurité nécessaires de l'application pour l'aider dans le choix du mécanisme ou pour limiter les mécanismes disponibles.
- Lister les plugins disponibles au applications
- Choisir le meilleur mécanisme dans une liste pour une authentification particulière
- Router les paquets de données d'authentification entre l'application et le mécanisme choisi
- Fournir des informations sur la négociation SASL aux applications

Il fournis également d'autres services aux plugins et applications tels que l'encodage MIME base 64, génération de nombres aléatoires, etc. Il permet également aux mécanismes et aux applications d'accéder à types spéciaux de plugin. Auxiliary Property "auxprop" qui fournis une interface de base simple et peut retourner des propriétés sur l'utilisateur tel que le mot de passe, répertoire personnel, ou adresse mail. et Username Canonicalization, qui peut fournir des manières de canoniser un nom d'utilisateur ou effectuer d'autres tâches.

Mécanisme PLAIN et mots de passe en texte clair

auxprop Vérifie les mots de passe dans userPassword fournis par une plugin de propriété auxiliaire. Par exemple, SASL est fournis avec sasldb, qui peut être utilisé pour authentifier avec des mots de passe stockés dans /etc/sasldb2.
saslauthd Permet de vérifier des mots de passe en utilisant divers mécanismes.
courrier-IMAP authdaemond Utilisé pour contacter authdaemond pour vérifier les mots de passe.

Mécanismes à secret partagé

Cyrus SALS fournis plusieurs méthodes d'authentification basé sur un secret partagé: CRAM-MD5 et son successeur DIGEST-MD5.

Mécanismes Kerberos

Cyrus SASL fournis 2 mécanismes qui utilisent kerberos: Kerberos_v4 et GSSAPI qui permet d'utiliser kerberos v5.

Mécanismes OTP

Cyrus SASL support le mécanisme OTP, similaire à CRAM-MD5 et DIGEST-MD5. Ces OTP sont stockés dans /etc/sasldb2. SASL support également OPIE.

Auxiliary Properties

SASLv2 introduit le concept de propriétés auxiliaires. C'est la capacité de rechercher des informations liées à l'authentification ou l'authorisation depuis un répertoire durant le processus d'authentification.

Fichier de configuration par défaut

Par défaut, Cyrus SASL lit ses options depuis /usr/lib/sasl2/App.conf (où App est le nom de l'application). Les applications peuvent redéfinir comment la librairie recherche les informations de configuration.

OPTIONS

authdaemond_path (SASL library) Chemin du socket UNIX de authdaemond (défaut: /dev/null)
auto_transition (SASL library) à yes ou noplain et utilisé avec auxprop. Transferts automatiquement les users à d'autres mécanismes quand ils font une authentification plaintext réussie. à noplain, seul les secrets non plaintext sont écris. (défaut: no)
auxprop_plugin (AuxProp Plugin) Nom(s) de(s) plugin(s) auxiliaire à utiliser. (défaut: null)
canon_user_plugin (SASL library) Nom du plugin canon_user à utiliser (défaut: INTERNAL)
keytab (GSSAPI) Emplacement du fichier keytab (défaut: /etc/krb5.keytab)
ldapdb_uri (LDAPDB plugin) liste d'URI ldap
ldapdb_id (LDAPDB plugin) id d'authentification ldap
ldapdb_mech (LDAPDB plugin) mécanisme pour l'authentification
ldapdb_pw (LDAPDB plugin) password
ldapdb_rc (LDAPDB plugin) Fichier à placer dans l'environnement LDAPRC
ldapdb_starttls (LDAPDB plugin) utiliser StartTls (try, demand).
ldapdb_canon_attr (LDAPDB plugin) attribut contenant le nom canonique de l'utilisateur
log_level (SASL library) Niveau de debug (défaut: 1 (SASL_LOG_ERR))
mech_list (SASL library) liste de mécanisme à autoriser (défaut: tous)
ntlm_server (SASL library) Liste des serveurs
ntlm_v2 (SASL library) Envoyer des réponses ntlmv2 au serveur opiekeys (OPIE) Emplacement du fichier opiekeys (défaut: /etc/opiekeys)
otp_mda (OPIE) Algorithme pour l'OTP (md4, md5, sha1) (défaut: md5)
plugin_list (SASL library) Emplacement de la liste des plugins
pwcheck_method (SASL library) liste des mécanismes utilisés pour vérifier les mots de passe, utilisé par sasl_checkpass (auxprop, saslauthd, pwcheck, authdaemond, alwaystrue). (défaut: auxprop)
reauth_timeout (DIGST-MD5) Temps en minutes de cache de l'authentification pour une réauthentification rapide. défaut: 0
saslauthd_path (SASL library) Chemin vers le répertoire saslauthd, incluant le pipe /mux
sasldb_path (sasldb plugin) Chemin du fichier sasldb (défaut: /etc/sasldb2)
sql_engine (SQL plugin) Nom du moteur SQL à utiliser (mysql, pgsql, sqlite, sqlite3). défaut: mysql
sql_hostnames (SQL plugin) liste de serveurs:ports SQL
sql_user (SQL plugin) Utilisateur SQL pour l'authentification
sql_passwd (SQL plugin) Mode de passe pour l'authentification
sql_database (SQL plugin) Nom de la base de données qui contient les propriétés auxiliaires
sql_select (SQL plugin) Déclaration SELECT à utiliser pour récupérer les propriétés
sql_insert (SQL plugin) Déclaration INSERT pour créer des propriétés
sql_update (SQL plugin) Déclaration UPDATE pour mettre à jours des propriétés
sql_usessl (SQL plugin) à yes, créé une connexion sécurisée
srp_mda (SRP) Algorithme à utiliser pour les calculs SRP (md5, sha1, rmd160).
srvtab (kerberos 4) Emplacement du fichier srvtab (défaut: /etc/srvtab)

Notes sur les options auxprop sql

%U username
%p Nom de la propriété à modifier/ajouter
%r Royaume auquel l'utilisateur appartient
%v Valeur de la propriété

Exemples

sql_select: SELECT %p FROM user_table WHERE username = '%u' and realm = '%r'
Va envoyer la requête suivante pour l'utilisateur bovik et le royaume madoka.surf.org.uk:
SELECT userPassword FROM user_table WHERE username = 'bovik' and realm = 'madoka.surf.org.uk';
sql_insert: INSERT INTO user_table (username, realm, %p) VALUES ('%u', '%r', '%v')
Va générer les requêtes suivante pour l'utilisateur bovik dans le royaume madoka.surf.org.uk et le userPassword "wert":
INSERT INTO user_table (username, realm, userPassword) VALUES ('bovik', 'madoka.surf.org.uk', 'wert');

Notes sur les options LDAPDB

s'active en créant /usr/lib/sasl2/slapd.conf avec:
auxprop_plugin: slapd

Exemples

ldapdb_uri: ldap://ldap.example.com
ldapdb_id: root
ldapdb_pw: secret
ldapdb_mech: DIGEST-MD5
ldapdb_canon_attr: uid
root authcid doit avoir des privilèges de proxy authorization pour tous les comptes authorisés à s'authentifier.
ldapdb_uri: ldapi://
ldapdb_mech: EXTERNAL
Cette configuration assume que le serveur LDAP est sur le même serveurs qui utilise SASL. C'est plus rapide et sécure et n'a pas besoin de stocker de user/password. slapd.conf doit mapper ces usernames en DN ldap:
sasl-regexp uidNumber=(.*)\\+gidNumber=(.*),cn=peercred,cn=external,cn=auth ldap:///dc=example,dc=com ??sub ?(&(uidNumber=$1)(gidNumber=$2))
sasl-regexp uid=(.*),cn=external,cn=auth ldap:///dc=example,dc=com ??sub ?(uid=$1)

19 octobre 2013

gsasl

CLI pour libgsasl

OPTIONS

-c, --client Agit comme client
--client-mechanism Mécanismes supportés par le client
-s, --server Agit comme serveur
--server-mechanism Mécanismes supportés par le serveur
--connect=HOSTNAME[:SERVICE] Serveur distant.
-d, --application-data Après l'authentification lis les données de stdin et le lance dans la couche de sécurité du mécanisme puis l'affiche en base64.
--imap Utilise la procédure de login style IMAP
-m, --mechanism=STRING mécanisme à utiliser
--no-client-first Empêche le client d'envoyer les info en premier (client only)
-n, --anonymous-token=STRING Token pour l'authentification anonyme, générallement l'addresse email.(ANONYMOUS only)
-a, --authentication-id=STRING Identité du propriétaire des acréditations
-z, --authorization-id=STRING Identité de demandeur
--disable-cleartext-validate Désactive la validation cleartext, force le serveur à demander le mot de passe
--enable-cram-md5-validate Valide les challenge/réponse CRAM-MD5 intéractivement
--hostname=STRING Nom du serveur avec le service requis
-p, --password=STRING Mot de passe pour l'authentification
--passcode=NUMBER Passcode pour l'authentification (SECURID only)
--quality-of-protection=‹qop-auth | qop-int | qop-conf› Protection du payload. qop-auth: pas de protection, qop-int: protection de l'intégrité, qop-conf: confidentitalité
-r, --realm=STRING Royaume
--service=STRING Nom du service requis
--service-name=STRING Nom du serveur en cas de serveur répliqué (DIGEST-MD5 only)
-x, --maxbuf=NUMBER Taille de buffer max (DIGEST-MD5 only)
--starttls Force l'utilisation de starttls
--no-starttls désactive starttls
--no-cb Ne définis pas de chanel binding
--x509-ca-file=FILE Fichier contenant les certificats des CA
--x509-cert-file=FILE Fichier contenant le certificat du client
--x509-key-file=FILE Fichier contenant la clé privée du client
--priority Chaîne de priorité de chiffrement
-Q, --QUIET, --SILENT mode silencieux
-v, --verbose mode verbeux

01 septembre 2013

rfc4422

Simple Authentication and Security Layer (SASL)

SASL est un framework fournissant des services d'authentification et de sécurité de données dans des protocoles orienté connexion utilisant des mécanismes remplaçable. SASL fournis une interface structurée entre les protocoles et les mécanismes. SASL fournis également un protocole pour sécuriser les échanges. SASL est conçu pour permettre à de nouveaux protocoles de réutiliser les mécanismes existants.

SASL fournis une couche d'abstraction entre les protocoles et les mécanismes. Pour utiliser SASL, chaque protocole fournis une méthode pour identifier le mécanisme à utiliser, une méthode pour échanger les challenges et une méthode pour la communication. Chaque mécanisme SASL définis une série de server-challenge et client-response qui fournissent les services d'authentification et de négociation de sécurisation des données.

Concept d'identité

   SASL nécessite 2 identités:

1) L'identité associé avec les accréditifs ( authentication identity )
2) L'identité qui agis en tant que ( authorization identity )

   Le client fournis ses accréditifs ( qui inclus ou implique un authentication identity) et optionnellement, une chaîne de caractère représentant l'authorization identity. Quand cette chaîne est omis ou vide, le client agis comme identité associé avec les accréditifs.

   Le serveur vérifie les accréditifs du clients et vérifie que l'identité qu'il associe avec les accréditifs du client (authorization idenity) a le droit d'agir comme authorization identity. Si une des vérifications échoue, l'échange SASL échoue.

Échange d'authentification

Chaque échange d'authentification consiste d'un message du client vers le serveur demandant une authentification via un mécanisme particulier, suivi par une ou plusieurs paires de challenges du serveur et de réponse du client, suivis par un message du serveur indiquant la sortie de l'échange d'authentification.

Exemple d'échange

C: Request authentication exchange
S: Initial challenge
C: Initial response
‹additional challenge/response messages›
S: Outcome of authentication exchange

Certains mécanismes spécifient que le client envoie une réponse initiale dans la requête. Plusieurs variantes sont possible.

Nommage des mécanismes

les mécanismes SASL sont nommés par des chaînes de caractère, de 1 à 20 caractère de long, en ASCII noté (ABNF) :
sasl-mech = 1*20mech-char
mech-char = UPPER-ALPHA / DIGIT / HYPHEN / UNDERSCORE

UPPER-ALPHA = %x41-5A ; A-Z (uppercase only)
DIGIT = %x30-39 ; 0-9
HYPHEN = %x2D ; hyphen (-)
UNDERSCORE = %x5F ; underscore (_)

Négociation de mécanisme

La négociation des mécanismes est spécifique au protocole. Généralement, un protocole spécifie que le serveur avertis le client des mécanismes disponibles et supportés. Le client choisira le meilleur protocole de cette liste qu'il supporte.

Demande d'échange d'authentification

L'échange d'authentification est initié par le client en demandant une authentification via le mécanisme qu'il spécifie. Le client envoie une message contenant le nom du mécanisme au serveur. Les particularité du message sont spécifiques au protocole. Noter que le nom du mécanisme n'est pas protégé par le mécanisme.

Challenges and Responses

Les challenges et réponse sont imbriqués dans des messages de protocole. Le mécanisme peut être:

- Authentifier le client auprès du serveur
- authentifier le serveur auprès du client
- Transférer une chaîne authorization identity
- Négocier une couche de sécurité
- Fournir d'autres services.

La négociation de couche de sécurité implique la négociation de services de sécurité à fournir dans la couche et comment ces services sont fournis. Après avoir reçu une requête d'authentification ou une réponse d'un client, le serveur peut fournir un challenge, annuler l'échange, ou indiquer la sortie de l'échange. Après avoir reçu un challenge, un mécanisme client peut fournir une réponse ou annuler l'échange.

Chaîne d'identité d'authorisation

Cette chaîne est une séquence de caractères unicode représentant l'identité qui qui agis en tant que. Si cette chaîne est absente, le demandeur agis en tant qu'identité que le serveur associe avec les accréditifs du client. Une chaîne non vide indique que le client souhaite agir en tant qu'identité représentée par la chaîne.

Annuler l'échange

Un client ou un serveur peut annuler l'échange.

Fin de l'authentification

La conclusion de l'échange, le serveur envoie un message spécifique au protocole, au client indiquant la sortie de l'échange. La sortie est un échec si:

- L'échange d'authentification a échoué pour une quelconque raison
- Les accréditifs du client n'ont pu être vérifiés
- Le serveur ne peut associer une identité avec les accréditifs du client
- L'authorization Identity fournie est mal formaté
- L'identité associé avec les accréditifs du client n'est pas autorisé à agir en tant qu'authorization identity
- La couche sécurité demandée (ou son absence) n'est pas disponible et n'est pas utilisable par le client et/ou le serveur

Le protocole peut inclure des données additionnelles dans le message.

Couches de sécurité

Les mécanismes SASL peuvent offrir une grande variété de services dans les couches de sécurité, incluant l'intégrité des données et la confidentialité des données. Si la couche de sécurité est négociée dans l'échange, la couche n'est installée par le serveur qu'après le message de sortie d'échange.

Authentification multiple

Sans être explicitement permis dans le protocole, seul un échange d'authentification réussis peut se produire dan une sessions. Quand plusieurs authentifications sont permis, en aucun cas il ne peut y avoir plusieurs couche de sécurité simultanés. Si une couche de sécurité est effective, et qu'une seconde négociation sélectionne une autre couche de sécurité, la seconde couche remplace la première.

Protocol requirements

Pour qu'un protocole offre des services SASL, ses spécifications doivent fournir les informations suivantes:

1) un nom de service, à sélectionner du registre de services pour la forme de nom de service basé sur l'hôte GSSAPI.
2) Détail des négociations de mécanisme que le protocole fournis.
3) Définition des messages nécessaires pour l'échange d'authentification
4) Décrire la syntaxe de chaîne d'authorization identity non-vide
5) Détailler les facilité que le protocole fournis qui permettent au client/serveur d'annuler un échange
6) Identifier précisément où les couches de sécurité nouvellement négociée prenent effet.
7) Si le protocole supporte d'autres couche de sécurité tel que TLS, la spécification doit décrire l'ordre dans lequel les couches de sécurité sont appliquées dans les données du protocole
8) indiquer si le protocole supporte l'authentification multiple

Mechanism requirement

Les spécification des mécanisme doivent fournir les informations suivantes:

1) le nom du mécanisme
2) Si le mécanisme est client-first ou server-first.
3) si le serveur doit fournir des données additionnelles en indiquant une sortie réussie
4) Si le mécanisme est capable de transférer l'authorization identity
5) Si le mécanisme offre une couche de sécurité
6) si la technologie cryptographique utilisée supporte l'intégrité des données

19 octobre 2013

saslauthd

Service qui manipule les authentifications plaintext basé sur la librarie Cyrus SASL

OPTIONS

-a authmech Spécifie le mécanime à utiliser
-O option Options spécifiques au mécanisme, incluant l'hôte à contacter
-m path Chemin du socket pour les connexions (défaut : /var/state/saslauthd) sans "/mux"
threads Nombre de threads à traiter (défaut : 5)
-s size Taille de la table de hash en Ko
-t timeout temps d'expiration du cache d'authentification en secondes
-T' Honore les restriction de connection time-of-day
-c' Active le cache des crédentials
-l' Désactive l'utilisation d'un file lock pour contrôller l'accès à accept()
-r' Combine le roaume avec le login.
-d' Mode debug

Mécanismes d'authentification

getpwent Authentifie avec un fichier password local
kerberos4 Authentification kerberos v4
kerberos5 Authentification kerberos v5
pam' Utilise PAM
rimap' Remote IMAP server.
shadow' Utilise le fichier shadow local
sasldb' Authentifie avec la base SASL
ldap' Authentifie avec un serveur LDAP
sia' Authentifie en utilisant SE Linux

15 février 2012

card_eventmgr

Monitorer et gérer les lecteurs de carte

Cet utilitaire est utilisé pour monitorer le statut du lecteur de carte et effectuer des actions en fonction de l’évènement.

Commandes

debug Active le mode debug
daemon Lance en tâche de fond
timeout=‹ms› Temps en ms entre 2 statuts consécutifs (défaut : 1000)
config_file=‹file› Fichier de configuration à utiliser (défaut : /etc/pam_pkcs11/card_eventmgr.conf)

15 février 2012

card_eventmgr.conf

Fichier de configuration pour card_eventmgr

card_eventmgr {
    daemon = false ; # lancer en tâche de fond
    debug = false ; # mode debug
    timeout = 1000 ; #polling time en ms
    # Liste des évènements et actions
    event card_insert { # carte insérée
        on_error = ignore ; # que faire en cas d’erreur (ignore=continuer, return=stopper la séquence, quit=quitter le programme)
        action = "/usr/bin/play /usr/share/sounds/warning.wav",
        "/usr/X11R6/bin/xscreensaver-command -deactivate" ; # action à exécuter
    }
    event card_remove { # carte retirée
        on_error = ignore ;
        action = "/usr/bin/play /usr/share/sounds/error.wav",
        "/usr/X11R6/bin/xscreensaver-command -lock" ;
    }
}

27 mai 2016

cert-to-efi-hash-list

Outils pour convertir des certificats Openssl en lists de révocation de hash de signature EFI

cert-to-efi-hash-list prend un certificat X509 en entrée au format PEM et le convertis en fichier de liste de hash de signature EFI

OPTIONS

-g ‹guid› Utilise le guid spécifie comme propriétaire de la signature. Non spécifié, un guid avec des 0 est utilisé
-s ‹hash› Spécifie l'algorithme SHA‹hash› (256, 384, 512)
-t ‹timestamp› Durée de révocation pour le hash (0=infini)

Exemples

Produire un fichier de hash de signature EFI
cert-to-efi-hash-list PK.crt PK.esl
Pour produire un fichier avec plusieurs signatures:
cat PK1.esl PK2.esl › PK.esl

27 mai 2016

cert-to-efi-sig-list

Outil pour convertir des certificats openssl en listes de signature EFI

cert-to-efi-sig-list prend un certificat X509 en entrée au format PEM et le convertis en fichier de liste de signature EFI contenant seulement ce certificat.

OPTIONS

-g ‹guid› Utilise le guid spécifie comme propriétaire de la signature. Non spécifié, un guid avec des 0 est utilisé

Exemples

Produire un fichier de signature EFI
cert-to-efi-sig-list PK.crt PK.esl
Pour produire un fichier avec plusieurs signatures:
cat PK1.esl PK2.esl › PK.esl

25 mars 2016

cmtab

Informations sur les systèmes de fichier gérés par cryptmount

   /etc/cryptmount/cmtab contient les informations sur les systèmes gérés par cryptmount. Le format est flexible:

TARGET_NAME {
    dev=DEVICE # REQUIRED
    flags=FLAG,FLAG,...
    startsector=STARTSECTOR
    numsectors=NUMSECTORS
    loop=LOOPDEV
    dir=MOUNT_POINT
    fstype=TYPE # REQUIRED
    mountoptions=MOPT,MOPT,...
    fsckoptions=FOPT;FOPT;...
    supath=SUPATH
    bootaction=BOOTACTION
    cipher=CIPHER
    ivoffset=IVOFFSET
    keyformat=KEYMANAGER
    keyfile=KEYFILE # REQUIRED
    keyhash=KEYHASH
    keycipher=KEYCIPHER
    keymaxlen=KEYMAXLEN
    passwdretries=NUMATTEMPTS
}

   Certains champs, tels que dev et fstype sont obligatoires. De nombreux champs ont des valeurs par défaut. Un champ contenant une valeur non-numérique peut contenir une référence à une variable d'environnement:

$(HOME) Répertoire personnel de l'utilisateur
$(UID) UID de l'utilisateur
$(USERNAME) Nom de l'utilisateur
$(GID) GID du groupe primaire de l'utilisateur
$(GROUPNAME) Groupe primaire de l'utilisateur

Définitions de cibles

dev Dpfinis le nom du périphérique ou du fichier.
flags "user", "nouser", "fsck", "nofsck", "mkswap", "nomkswap", "trim", "notrim". Défaut: user,fsck,nomkswap,notrim
startsector Secteur de début du système de fichier dans le périphérique. défaut: 0
numsectors Donne la longueur totale du système de fichier en secteur. Défaut: -1
loop Permet de spécifier un périphérique loopback. Défaut: auto
dir Point de montage
fstype Type de système de fichier
mountoptions Options de montage utilisées par mount
fsckoptions options utilisées par fsck
supath Définis la variable d'environnement PATH en lançant des sous-processus en tant que root. Peut être nécessaire pour fsck et mount. Défaut: /sbin:/bin:/usr/sbin:/usr/bin
bootaction Action lors du démarrage du système (none, mount, swap ou prepare)
cipher Algorithme de chiffrement à utiliser. Défaut: aes-cbc-plain
keyformat schéma de gestion de clé utilisé pour interagir avec le keyfile. (libgcrypt, luks, openssl-compact, builtin, raw). Défaut: builtin
keyfile Nom du fichier contenant la clé à utiliser
ivoffset Offset ajouté au numéro de secteur utilisé pour construire le vecteur d'initialisation de l'algorithme de chiffrement. Défaut: 0
keyhash Algorithme de hashage à utiliser
keycipher Algorithme de chiffrement à utiliser pour sécuriser la clé de déchiffrement
keymaxlen Longueur en octet de la clé de déchiffrement
passwdretries Nombre de tentative du mot de passe

Choix du keymanager

cryptmount supporte différentes manières de protéger l'accès à la clé associée avec chaque système de fichier chiffré. Pour la plupart des utilisateurs, le keymanager builtin fournis a bon niveau de sécurité et une bonne flexibilité. Les keymanager alternatifs offre un grand choix de schéma de hashage de mot de pass et de compatibilité avec d'autres outils de chiffrement.

builtin Ce keymanager utilise un keyfile séparé. Une fonction de dérivation de clé (PBKPF2) utilisant l'algorithme de hashage SHA1, avec chiffrement blowfish-cbc est utilisé pour protéger la clé.
libgcrypt Ce keymanager utilise un keyfile séparé. Une fonction de dérivation de clé (PBKPF2) est utilisé pour protéger la clé, avec un algorithme de hashage et de chiffrement supporté par la version installé de la librairie libgcrypt.
luks Ce keymanager fournis une compatibilité avec le format LUKS. Au lieu d'un fichier séparé, LUKS utilise un en-tête dans le système de fichier lui-même.
openssl/openssl-compat Ce keymanager utiliser un keymanager séparé qui est compatible avec le format utilisé par l'outil de chiffrement opennssl. Une fonction de dérivation de clé (PBKPF2) est utilisé pour protéger la clé, avec un algorithme de hashage et de chiffrement disponible.
password Ce keymanager dérive la clé directement depuis le mot de passe de l'utilisateur
raw Ce keymanager utilise un keyfile séparé où la clé accès est stocké directement et sans chiffrement. Ce keymanager est utile pour gérer les partitions swap chiffrés, où le keyfile peut être choisis avec /dev/random et la clé sera différente à chaque fois quelle est lue.

Sécurité

Parce que cryptmount nécessite d'opérer avec des privilèges setuid, il est très important que son fichier de configuration soit sécurisé. Idéalement, /etc/cryptmount/cmtab devrait être géré seulement par l'administrateur système, et tous les keyfiles devraient lisibles par leur propriétaire. cryptmount effectue des vérifications de sécurité sur /etc/cryptmount/cmtab chaque fois qui est lancé, et va refuser d'opérer sauf si les conditions suivant sont rencontrées:

- cmtab doit être possédé par root
- cmtab doit être un fichier régulier
- cmtab ne doit pas être en écriture globalement
- Le répertoire contenant cmtab doit être possédé par root
- Le répertoire contenant cmtab ne doit pas être en écriture globalement
- Pour chaque cible dans @CM_SYSCONFDIR@/cmtab, tous les chemins doivent être absolus

Exemples

L'exemple suivant de @CM_SYSCONFDIR@/cmtab consiste de 5 cibles, utilisant divers algorithmes de chiffrement et stockent leur système de fichier de différentes manières, incluant une cible représentant une partition swap chiffrée:
_DEFAULTS_ {
    passwdretries=3 # allow 3 password attempts by default
}

basic {
    dev=/home/secretiveuser/crypt.fs
    dir=/home/secretiveuser/crypt # where to mount
    loop=auto # find free loop-device
    fstype=ext3 mountoptions=default
    cipher=aes-cbc-plain # filesystem encryption
    keyfile=/home/secretiveuser/crypt.key
    keyformat=builtin
}

partition {
    dev=/dev/hdb62 # use whole disk partition
    dir=/mnt/crypt62
    fstype=ext3 mountoptions=nosuid,noexec
    cipher=serpent-cbc-plain
    keyfile=@CM_SYSCONFDIR@/crypt_hdb62.key
    keyformat=openssl # use OpenSSL key-encryption
    keyhash=md5 keycipher=bf-cbc # encryption of key file
}

subset {
    dev=/dev/hdb63
    startsector=512 numsectors=16384 # use subset of partition
    dir=/mnt/encrypted\ subset\ of\ hdb
    fstype=reiserfs mountoptions=defaults
    cipher=twofish-cbc-plain # filesystem encryption
    keyfile=@CM_SYSCONFDIR@/crypt_hdb63.key
    keyformat=libgcrypt
    keyhash=md5 keycipher=blowfish-cbc # encryption of key file
}

encswap { # encrypted swap partition
    bootaction=swap
    dev=/dev/disk/by-id/scsi-SATA_ST500_ABCDEFG-part37
    startsector=16896 numsectors=1024 # use subset of partition
    fstype=swap flags=mkswap cipher=twofish-cbc-plain
    keyfile=/dev/random keymaxlen=16 keyformat=raw
}

luks { # partition created by cryptsetup-luks
    dev=/dev/hdb63
    dir=/mnt/luks-partition-$(USERNAME)
    keyformat=luks
    keyfile=/dev/hdb63
    fstype=ext3
}

22 mars 2016

cryptdisks_start

cryptdisks_start, cryptdisks_stop

wrapper de cryptsetup qui parse /etc/crypttab

cryptdisks_start est un wrapper de cryptsetup qui parse /etc/crypttab tout comme /etc/init.d/cryptdisks le fait et démarre le mappage dm-crypt qui correspond au nom spécifié.

cryptdisks_stop est un wrapper de cryptsetup qui parse /etc/crypttab tout comme /etc/init.d/cryptdisks le fait et stop le mappage dm-crypt qui correspond au nom spécifié.

22 mars 2016

cryptmount

Monter/démonter/configurer un système de fichier chiffré

cryptmount permet de monter ou démonter un système de fichier chiffré dans nécessiter de privilèges root, et l'assister root dans la création de nouveau système de fichiers chiffrés. Une fois la configuration initiale du système de fichier par l'administrateur système, l'utilisateur doit seulement fournir le mot de passe de déchiffrement pour que cryptmount configure automatiquement device-mapper et les cibles loopback avant de monter le système

cryptmount a été écris en réponse aux différences entre la nouvelle infrastructure device-mapper de linux 2.6 et l'ancien cryptoloop qui permettait aux utilisateurs standards d'accéder aux systèmes de fichiers directement via mount.

OPTIONS

-a, --all Agit sur toutes les cible disponible, ex: pour monter toutes les cibles
-m, --mount Monte la cible spécifiée. L'utilisateur devra fournir un mot de passe pour débloquer la clé de déchiffrement pour le système de fichier.
-S, --status Indique si la cible est montée ou non
-l, --list Liste toutes les cibles disponible, incluant des informations sur le système de fichier et le point de montage.
-c, --change-password Change le mot de passe qui protège la clé de déchiffrement pour un système de fichier donné.
-g, --generate-key size Génère une clé de déchiffrement opur un nouveau système de fichier, avec la taille spécifiée en octets
-e, --reuse-key existing-target Définis une clé de déchiffrement pour un nouveau système de fichier, en utilisant une clé existante pour un autre système de fichier. Uniquement disponible pour root
-f, --config-fd num Lit la configuration des cible depuis le descripteur de fichier spécifié au lieu du fichier de configuration par défaut. Uniquement disponible pour root
-m, --passwd-fd num Lit les mots de passe depuis le descripteur de fichier spécifié au lieu du terminal. Chaque mot de passe est lu une seule fois.
-p, --prepare Prépare les périphériques device-mapper et loopback nécessaire pour accéder à la cible, mais ne la monte pas. Utilisé par root pour installer un système de fichier sur un périphérique chiffré
-r, --release Relache tous les périphériques device-mapper et loopback associés avec un cible particulière. Uniquement disponible pour root.
-s, --swapon Active le paging et swaping pour la cible. Uniquement disponible pour root.
-x, --swapoff Désactive le paging et swaping pour la cible. Uniquement disponible pour root.
-k, --key-managers Liste tous les formats disponibles pour protéger les clés d'accès au système de fichier
-B, --system-boot Configure toutes les cibles marquées "bootaction". Généralement utilisé pour monter automatiquement les systèmes de fichiers chiffré. Uniquement disponible pour root.
-Q, --system-shutdown Stop toutes les cibles marquées bootaction. L'opposé de -B. Uniquement disponible pour root.
-n, --safetynet Tente de stopper toute cible mounté qui devrait normalement être arrêtée avec --unmount ou --swapoff. Uniquement disponible pour root, et prévu exclusivemeent durant l'extinction du système.

Codes de sortie

1 Option de ligne de commande non-reconnue
2 Nom de cible non-reconnue
3 Erreur en exécutant le programme helper
100 Privilèges insuffisants
101 Erreur de sécurité à l'installation

Exemple d'utilisation

   Pour pouvoir créer un nouveau système de fichier chiffré par cryptmount, utiliser le programme cryptmount-setup qui peut être utilisé par le superuser pour le configurer interactivement.

   Alternativement, une configuration manuelle permet un contrôle avancé. Avant de le faire, il faut s'assurer que le kernel supporte /dev/loop et /dev/mapper (modprobe -a loop dm-crypt).

Ensuite, supposons que l'on souhaite définir un nouveau système de fichier chiffré qui aura comme nom "opaque". Si on a une partition libre, disons /dev/hdb63, on peut donc l'utiliser directement pour stocker le système de fichier chiffré. Alternativement, si l'on souhaite stocker le système de fichier chiffré dans un fichier ordinaire, on doit créer un fichier avec par exemple:
dd if=/dev/zero of=/home/opaque.fs bs=1M count=512
Puis remplacer toutes les occurences de /dev/hdb63 avec /home/opaque.fs.

Premièrement, il faut ajouter une entrée dans /etc/cryptmount/cmtab, qui décris le chiffrement qui sera utilisé pour protéger le système de fichier lui-même et la clé d'accès, comme suit:
opaque {
dev=/dev/hdb63 dir=/home/crypt
fstype=ext2 mountoptions=defaults cipher=twofish
keyfile=/etc/cryptmount/opaque.key
keyformat=builtin
}

   Ici, on utilise l'algorithme twofish pour chiffrer le système de fichier lui-même, avec le gestionnaire de clé embarqué utilisé pour protéger la clé de déchiffrement (dans /etc/cryptmount/opaque.key) qui sera utilisé pour chiffrer le système de fichier lui-même, on peut exécuter, en root:

   Cela va générer une clé 32 octets (256bits), qui est connu pour être supportée par twofish, et la stocke dans une forme chiffrée après avoir demandé le mot de passe.

Si on exécute, en root:
cryptmount --prepare opaque
Le mot de passe sera demandé, qui va permettre à cryptmount de définir une cible device-mapper (/dev/mapper/opaque). On peut désormais utiliser les outils standard pour créer le système de fichier dans /dev/mapper/opaque:
mke2fs /dev/mapper/opaque
après avoir exécuté:
cryptmount --release opaque
mkdir /home/crypt
Le système de fichier chiffré est prêt. Généralement, les utilisateurs peuvent le monter avec:
cryptmount -m opaque
ou
cryptmount opaque
et le démontent avec
cryptmount -u opaque

   cryptmount conserve un enregistrement sur quel utilisateur a monté chaque système de fichier pour pouvoir fournir un mécanisme de blockage pour s'assurer que seul le même utilisateur (ou root) peut le démonter.

Changement de mot de passe

Une fois un système de fichier utilisé, on peut souhaiter changer le mot de passe d'accès, par exemple:
cryptmount --change-password opaque

Système de fichier chiffré avec LUKS

   cryptmount peut être utilisé pour fournir un accès simple à aux systèmes de fichier chiffrés compatibles avec LUKS.

Pour accéder à une partition LUKS existante, une entrée a besoin d'être créé dans /etc/cryptmount/cmtab. Par exemple, si la partition /dev/hdb62 est utilisé pour contenir un système de fichier ext3 LUKS, une entrée sous la forme:
LUKS {
keyformat=luks
dev=/dev/hdb62 keyfile=/dev/hdb62
dir=/home/luks-dir fstype=ext3
}

Que permet de monter via cryptmount sous /home/luks-dir en exécutant:
cryptmount LUKS
cryptmount va également permettre à un utilisateur qui connaît un des mots de passe d'accè de changer leur mot de passe via
cryptmount --change-password LUKS

   cryptmount fournis également un support basic pour créer un nouveau système de fichier chiffré LUKS, qui peut être placé dans des fichiers ordinaires aussi bien que des partitions disque, via --generate-key. Cependant, pour exploiter toutes les fonctionnalité de LUKS, tel qu'ajouter plusieurs mots de passes, il faut utiliser cryptsetup.

   Il est fortement recommandé de ne pas tenter d'utiliser le support LUKS en combinaison avec les fonctionnalités de cryptmount pour stocker plusieurs systèmes de fichiers chiffrés dans une simple partition disque ou un fichier ordinaire. Cela est dû à la supposition dans le design de cryptsetup-luks que la clé LUKS est toujours stockée au début de la partition.

22 mars 2016

cryptmount-setup

Définir un nouveau système de fichier chiffré

cryptmount-setup aide à la configuration initiale du chiffrement d'un système de fichier, pour être géré par cryptmount. Lancé en root, il permet de créer un système de fichier de bas dans un fichier ordinaire. La taille, l'emplacement, le point de montage et le propriétaire du système de fichier peuvent être sélectionnés interactivement.

25 mars 2016

cryptsetup

Gérer les volumes chiffré dm-crypt et LUKS

   cryptsetup est utilisé pour définir les mappages device-mapper gérés par dm-crypt. Cela inclus les volume dm-crypt et LUKS. La différence est que LUKS utilise en en-tête de méta-données et peut ainsi offrir plus de fonctionnalités que dm-crypt. D'un autre côté, l'en-tête est visible et vulnérable.

   De plus, cryptsetup fournis un support limité des volumes historiques loopaes et pour les volumes compatibles TrueCrypt.

   Beaucoup d'informations sur les riques de l'utilisation de stockage chiffré, la gestion des problèmes et sur les aspects de sécurité peuvent être trouvés dans la FAQ Cryptsetup.

Commandes de base

open ‹device› ‹name› --type ‹device_type› Ouvre (créé un mappage avec) le nom. device_type peut être plain, luks, loopaes ou tcrypt.
close ‹name› Supprime la mappage existant et détruit la clé de la mémoire kernel
status ‹name› Reporte le status pour la mappage donné
resize ‹name› Redimentionne un mappage active

Mode Plain

plain dm-crypt chiffre le périphérique secteur par secteur avec un simple, non-salted hash de la passphrase. aucune vérification n'est effectuée, aucune métadonnée n'est utilisée. Il n'y a pas d'opération de formattage. Quand le périphérique brut est mappé, les opérations de périphériques peuvent être utilisée sur le périphérique mappé, incluant la création du système de fichier. Les périphériques de mappage peuvent être créés dans /dev/mapper/‹name›.

Extensions LUKS

Variables d'environnement

CRYPTDISKS_ENABLE à yes, lance les initscripts cryptdisks au démarrage.
CRYPTDISKS_MOUNT Spécifie les points de montage qui sont montés avant d'invoquer cryptdisks. Prend les points de montage configuré dans /etc/fstab comme arguments, séparés par un espace.
CRYPTDISKS_CHECK Spécifie le checkscript par défaut à lancer avec le périphérique cible après avoir invoqué cryptdisks
CRYPTDISKS_PRECHECK Spécifie le checkscript par défaut à lancer avec le périphérique dm-crypt, avant d'invoquer cryptdisks

22 mars 2016

dm-crypt

Chiffrement transparent des périphériques block

la cible crypt de Device-Mapper fournis un chiffrement transparent des périphériques blocks utilisant l'API crypto du kernel

Paramètres

cipher Algorithme de chiffrement et un mode de génération IV optionel (ex: des, aes-cbc-essip:sha256, twofish-ecb). /proc/crypto contient les modes crypto supportés
key Clé utilisée pour le chiffrement. Encodé en hexadécimal.
keycount Mode compatibilité multi-clé. On peut définis keycount clé et les secteurs sont chiffrés en accord avec leur offset (le secteur 0 utilise key0, etc.)
iv_offset L'offset IV est un compteur de secteur qui sont ajoutés au numéro du secteur avant de créer l'IV
device_path Périphérique qui est utilisé comme backend et contient la donnée chiffrée.
offset Secteur de départ dans le périphérique où les données chiffrée commencent
#opt_params Nombre de paramètres optionnels.

Paramètres optionnels

allow_discards Block discard request passé au périphérique crypté. Défaut: ignore ces requêtes
same_cpu_crypt Effectue le chiffrement en utilisant le même cpu que l'IO qui l'a émis.
submit_from_crypt_cpus Désactive l'écriture offload dans un thread séparé après le chiffrement. L'écriture bénéficie à CFQ, mais peut dégrader les performances dans certains cas.

Scripts d'exemple

LUKS (Linux Unified Key Setup) est la manière préférée pour définir le chiffrement de disque avec dm-crypt en utilisant l'utilitaire cryptsetup
[[
#!/bin/sh
# Crée un périphérique crypto avec dmsetup
dmsetup create crypt1 --table "0 `blockdev --getsize $1` crypt aes-cbc-essiv:sha256 babebabebabebabebabebabebabebabe 0 $1 0"
]]

[[
#!/bin/sh
# Crée un périphérique en utilisant cryptsetup et LUKS avec le chiffrement par défaut:
cryptsetup luksFormat $1
cryptsetup luksOpen $1 crypt1
]]

27 mai 2016

efi-readvar

Outil pour afficher les variables sécurisés

Sans arguments, affiche la base de variables et étend le contenu des hash et des certificats x509. Peut être restreint à des variables spécifiques et des signatures spécifiques dans les variables. Noter que les listes de signatures EFI sont numérotées à partir de 0 et peuvent contenir un ou plusieurs entrées également numérotées à partir de 0, donc 0-0 représente la première entrée de la liste de signature 0.

OPTIONS

-v ‹var› Liste seulement le contenu de ‹var›
-s ‹list›[-‹entry›] Liste seulement la liste de signature donnée
-o ‹file› Sort les les listes de signature demandées dans le fichier

Exemples

voir toutes les variables:
efi-readvars
Voir la seconde entrée de la liste de signature 1 pour la variable db:
efi-readvars -v db -s 1-1
Voir toutes les entrées de la liste de signature 0 pour le KEK
efi-readvars -v KEK -s 0

27 mai 2016

efi-updatevar

Outil de mise à jours des variables

OPTIONS

-a Ajoute une valeur à une variable au lieu de la remplacer
Utiliser la liste de signature EFI au lieu de mises à jours signées
-b «binfile› Ajoute le hash du fichier spécifié à la liste de signature
-f ‹file› Ajoute ou remplace le fichier de clé (.esl ou .auth) à ‹var›
-c ‹file› Ajoute ou remplace le certificat x509 à ‹var›
-g ‹guid› guid optionnel pour le certificat x509
-k ‹key› Fichier de clé secrète pour autoriser les mises à jours en User Mode
-d ‹list›[-‹entry›] Supprime la liste de signature spécifiée, ou simplement une entrée dans la liste

Exemples

Supposons vos propres clé PK.auth et noPK.auth, les sortir du système en mode user:
efi-updatevar -f noPK.auth PK
puis les replacer:
efi-updatevar -f PK.auth PK
Ajouter le hash de bin.efi à db en mode setup:
efi-updatevar -b bin.efi db
Ajouter une liste de signature EFI à db en mode setup:
efi-updatevar -a -e append.esl db
Ajouter votre propre clé KEK en mode user:
efi-updatevar -a -c KEK.crt -k PK.key KEK
Ajouter le certificat DB.crt à db en mode user:
efi-updatevar -a -c DB.crt -k KEK.key db
Remplacer l'ancienne clé de plateforme avec une nouvelle:
efi-updatevar -c newPK.crt -k PK.key db
Supprimer la clé privée, basculant du mode user au mode setup:
efi-updatevar -d 0 -k PK.key PK
Et place la clé privée de nouveau (en mode setup):
efi-updatevar -c PK.crt -k PK.key PK

10 janvier 2017

firewall-applet

Applet firewalld

firewalld-applet est un applet graphique pour afficher le status de firewalld. Il ne possède pas d'option.

QSettings

firewall-applet a des paramètres additionnels pour adapter l'apparence. QSettings est utilisé et les stocke dans ~/.config/firewall/applet.conf. Le fichier est automatiquement rechargé s'il est changé. Il y a également un fichier global /etc/firewall/applet.conf, qui contient les valeurs par défaut. les paramètres dans ce fichier sont écrasés par les paramètres dans le fichier utilisateur.

Exemple de fichier applet.conf
[General]
notifications=true
show-inactive=true

notifications active les notifications. Défaut: false
show-inactive Affiche l'applet même si firewalld ne fonctionne pas. Défaut: false
shields-up nom de la zone shields-up si shields-up est activé. Défaut: block
shelds-down Nom de la zone shields-down si shields-up a été désactivé
blink Si permis, l'icône clignote si la connection à filewalld est perdue ou si le mode panic a été activé ou désactivé. Défaut: false
blink-count Nombre de clignotement si blink est activé. Défaut: 5

10 janvier 2017

firewallctl

Client en ligne de commande pour firewalld

Il y a des options qui peuvent être spécifiées plusieurs fois. Le code de sortie est 0 s'il y a au moins un élément qui réussit. les erreurs ALREADY_ENABLED, NOT_ENABLED et ZONE_ALREADY_SET sont traité comme réussis.

Options générales

-v, --verbose mode verbeux
-q, --quiet N'affiche pas de messages de status

Option de status

state Vérifie si le service firewalld est actif

Option de rechargement

reload [ -c | --complete ] Recharge les règle firemall et conserve les informations d'état. La configuration permanente devient la configuration courante. -c recharge complètement le firewall, incluant les modules netfilter.

Option runtime-to-permanent

runtime-to-permanent Sauve la configuration active en tant que configuration permanente.

Options de liste

list zones [ -a | --active | -p | --permanent ] Affiche la liste des zones prédéfinies. -a n'affiche que les zones actives, -p n'affiche que les zones dans l'environnement permanent
list services [ -p | --permanent ] Affiche la liste des services prédéfinis.
list ipsets [ -p | --permanent ] Affiche la liste des ipsets prédéfinis
list helpers [ -p | --permanent ] Affiche la liste des helpers
list icmptypes [ -p | --permanent ] Affiche la liste des types icmp prédéfinis

Options d'informations

info zone ‹zone› [ -p | --permanent ] Affiche des informations sur la zone
info zones [ -a | --active | -p | --permanent ] Affiche des informations sur les zones
info service service [ -p | --permanent ] Affiche des informations sur le service spécifié
info services [ -p | --permanent ] Affiche des informations sur les services
info ipset ipset [ -p | --permanent ] Affiche des informations sur l'ipset spécifié
info ipsets [ -p | --permanent ] Affiche des informations sur les ipsets
info helper helper [ -p | --permanent ] Affiche des informations sur l'helper spécifié
info helpers [ -p | --permanent ] Affiche des informations sur les helper
info icmptype icmptype [ -p | --permanent ] Affiche des informations sur le type icmp spécifié
info icmptypes [ -p | --permanent ] Affiche des informations sur les types icmp

Options de zone

zone zone [ -p | --permanent ] add element.. [ --timeout=timeval ] Ajoute un élément ou de nombreux éléments de même type à une zone avec un timeout optionnel. Si la zone est une chaîne vide, la zone par défaut est utilisée. -p ajoute les éléments dans l'environnement permanent.
zone zone [ -p | --permanent ] remove element ... Supprime un ou plusieurs éléments d'une zone.
zone zone [ -p | --permanent ] query element ... Affiche si le ou les éléments sont activés dans la zone
zone zone [ -p | --permanent ] get { short | description } Affiche une description de la zone
zone zone [ -p | --permanent ] set { short | description } text Définis un description pour une zone
zone zone [ -p | --permanent ] list { interfaces | sources | services | ports | protocols | source-ports | rich-rules | forward-ports | icmp-blocks } Retourne la liste des éléments ajoutés pour la zone
zone zone { -p | --permanent } load-defaults Charge les paramètres de la zone par défaut ou affiche l'erreur NO_DEFAULTS

Éléments de zone

interface ‹interface› Nom d'une interface. Si l'interface est sous le contrôle de NetworkManager, elle doit d'abord être connectée.
source { address[/mask] | MAC | ipset:ipset } Une adresse ou plage d'adresse source ou une adresse MAC ou un ipset.
service ‹service› Nom d'un service
port portid[-portid]/protocol Port, plage de port ou nom de protocole
source-port portid[-portid]/protocol Port source
rich-rule 'rule' Règle en langage rich
masquerade Masquerading IPv4
forward-port port=portid[-portid]:proto=protocol[:toport=portid[-portid]][:toaddr=address[/mask]] Port forward ipv4
icmp-block icmptype block de type ICMP
icmp-block-inversion Inverse les blocks de type icmp

Options de service

service service [ -p | --permanent ] add element... Ajoute un ou plusiuers éléments à un service
service service [ -p | --permanent ] remove element... Supprime un ou plusieurs éléments d'un service
service service [ -p | --permanent ] query element... Affiche si un ou plusieurs éléments sont activés dans le service
service service [ -p | --permanent ] get { short | description } Affiche la description du service
service service [ -p | --permanent ] set { short | description } text Définis la description pour un service
service service [ -p | --permanent ] list { ports | protocols | source-ports | modules | destinations } Retourne la liste des éléments ajoutés pour un service
service service { -p | --permanent } load-defaults Charge les paramètres par défaut du service ou affiche NO_DEFAULTS

Éléments de service

port portid[-portid]/protocol Port ou plage de port / tcp|udp
protocol protocol Protocole supporté par le système
source-port portid[-portid]/protocol Port ou plage de port source / tcp|udp
module module Module netfilter
destination ipv:address[/mask] Adresse de destination. ipv=ipv4 ou ipv6

Options ipset

ipset ipset [ -p | --permanent ] add { entry entry | entries-from-file filename }... Ajoute une ou plusieurs entrées dans l'ipset
ipset ipset [ -p | --permanent ] remove { entry entry | entries-from-file filename | all }... Supprime une ou plusieurs entrées dans l'ipset
ipset ipset [ -p | --permanent ] query { entry entry | entries-from-file filename }... Affiche si la ou les entrées sont dans l'ipset
ipset ipset [ -p | --permanent ] get { short | description } Retourne la description de l'ipset
ipset ipset [ -p | --permanent ] set { short | description } text Définis la description de l'ipset
ipset ipset [ -p | --permanent ] list entries Liste les entrées ajoutées dans l'ipset
ipset ipset { -p | --permanent } load-defaults Charge les paramètres par défaut pour l'ipset ou retourne NO_DEFAULTS

Entrées ipset

ip[/cidr] Ajoute un ip ou une plage d'ip.
ip[/cidr] | fromaddr-toaddr idem en spécifiant les ip source et de destination
mac L'entrée est une adresse MAC

Options helper

helper helper -p | --permanent { add | remove } port portid[-portid]/protocol Ajoute ou supprime le port au helper.
helper helper [ -p | --permanent ] query port portid[-portid]/protocol Affiche si le port est mis dans le helper
helper helper [ -p | --permanent ] get { short | description } Affiche la description du helper
helper helper [ -p | --permanent ] get family Affiche la famille du helper
helper helper [ -p | --permanent ] get module Affiche le module netfilter du helper
helper helper -p | --permanent set { short | description } text Définis la description du helper
helper helper -p | --permanent set family Définis la famille du helper
helper helper -p | --permanent set module Définis le module helper netfilter pour le helper
helper helper [ -p | --permanent ] list ports Retourne la liste des ports ajoutés au helper
helper helper { -p | --permanent } load-defaults Charge les paramètres par défaut du helper ou retourne NO_DEFAULTS

Options icmptype

icmptype icmptype [ -p | --permanent ] { add | remove } destination { ipv4 | ipv6 } Ajoute ou supprime la destination au icmptype.
icmptype icmptype [ -p | --permanent ] query destination { ipv4 | ipv6 } Affiche si la destination est dans le icmptype
icmptype icmptype [ -p | --permanent ] get { short | description } Affiche la description du icmptype
icmptype icmptype [ -p | --permanent ] set { short | description } text Définis la description du icmptype
icmptype icmptype [ -p | --permanent ] list destinations Affiche la liste des destinations ajoutées pour l'icmptype
icmptype icmptype { -p | --permanent } load-defaults Charge le paramètres par défaut du icmptype ou affiche NO_DEFAULTS

Options new

new { -p | --permanent } zone { { -n | --name } name | { -f | --filename} filename [ { -n | --name } name } ] } Ajoute une zone permanente.
new { -p | --permanent } service { { -n | --name } name | { -f | --filename} filename [ { -n | --name } name } ] } Ajoute un service permanent
new { -p | --permanent } ipset { { -n | --name } name { -t | --type } ipsettype [ { -o | --option } option[=value] ] | { -f | --filename} filename [ { -n | --name } name } ] } Ajoute un ipset permanent
new { -p | --permanent } icmptype { { -n | --name } name | { -f | --filename} filename [ { -n | --name } name } ] } Ajoute un icmptype permanent

Options delete

delete { -p | --permanent } zone zone Supprime une zone permanente
delete { -p | --permanent } service service Supprime un service permanent
delete { -p | --permanent } ipset ipset Supprime un ipset permanent
delete { -p | --permanent } icmptype icmptype Supprime un ipset permanent

Options direct

direct [ -p | --permanent ] { add | remove } chain { ipv4 | ipv6 | eb } table chain Ajoute une nouvelle chaîne nommé à la table spécifiée.
direct [ -p | --permanent ] query chain { ipv4 | ipv6 | eb } table chain Affiche si un chaîne existe dans la table spécifiée
direct [ -p | --permanent ] get chains { ipv4 | ipv6 | eb } table Affiche les chaînes ajoutées à la table spécifiée
direct [ -p | --permanent ] get all-chains Récupère toutes les chaînes ajoutées à toutes les tables
direct [ -p | --permanent ] { add | remove } rule { ipv4 | ipv6 | eb } table chain priority args Ajoute ou supprime une règle à la chaîne spécifiée. La priorité est utilisée pour l'ordre des règles (0 étant la première)
direct [ -p | --permanent ] query rule { ipv4 | ipv6 | eb } table chain priority args Affiche si une règle avec la priorité et les arguments existe dans la chaîne dans la table spécifiés. Retourne 0 si vrai, 1 sinon.
direct [ -p | --permanent ] get all-rules Affiche toutes les règles ajoutées à toutes les chaînes d-ans toutes les tables
direct [ -p | --permanent ] get rules { ipv4 | ipv6 | eb } table chain Affiche les règles ajoutées à la chaîne dans la table spécifiées.
direct [ -p | --permanent ] { add | remove } passthrough { ipv4 | ipv6 | eb } args Ajoute une règle passthrough
direct [ -p | --permanent ] query passthrough { ipv4 | ipv6 | eb } args Affiche une règle passthrough
direct [ -p | --permanent ] get all-passthroughs Affiche toutes les règles passthrough
direct [ -p | --permanent ] get passthroughs { ipv4 | ipv6 | eb } Affiche les règles passthrough pour une valeur ipv
direct passthrough { ipv4 | ipv6 | eb } args Passe une commande au firewall args peut être iptables, ip6tables et ebtables.

Options Lockdown Whitelist

Les applications locales ou services sont capable de changer la configuration firewall s'ils tournent en root (par exemple libvirt) ou sont authentifiés via PolKit. Avec cette fonctionnalité, les administrateurs peuvent bloquer la configuration du firewall pour que seuls les applications dans la lockdown whitelist soient capable de changer le firewall.

lockdown-whitelist [ -p | --permanent ] { add | remove } element... Ajoute ou supprime un ou plusieurs éléments à la liste
lockdown-whitelist [ -p | --permanent ] query element... Affiche si le ou les éléments sont membres de la liste
lockdown-whitelist [ -p | --permanent ] list { commands | contexts | uids | users } Affiche la liste des membres de la liste

Options de configuration

config set { default-zone zone | lockdown { on | off } | log-denied value | panic { on | off } } Définis une option de configuration firewalld. Les valeurs possibles sont:

default-zone zone Définis la zone par défaut pour les connexions et les interfaces
lockdown Active/désactive le lockdown. Noter que par défaut firewall-cmd n'est pas dans la liste.
log-denied Si activé, les règles de logging sont ajoutées avant les règles de rejet/suppression dans les chaînes INPUT, FORWARD, et OUTPUT pour les règles par défaut. Les valeurs possibles sont all, unicast, broadcast, multicast, et off. Défaut: off.
panic Active le mode panic. Si activé, tous les paquets entrant et sortant sont supprimés. À activer uniquement en cas de problème sérieux dans le réseau.

config list Liste les options de configuration de firewalld
config get { default-zone | lockdown | log-denied | panic } Afficher les options de configuration de firewalld

Options de paramètrage

settings list Liste les paramètres de firewalld comme BRIDGE, CleanupOnExit, IPSet, IPSetTypes, IPv4, IPv6, IPv6_rpfilter, IndividualCalls et MinimalMark
settings get { BRIDGE | CleanupOnExit | IPSet | IPSetTypes | IPv4 | IPv6 | IPv6_rpfilter | IndividualCalls | MinimalMark } AFficher les paramètres de firewalld:

BRIDGE Affiche si la commutation est disponible
CleanupOnExit Affiche si CleanupOnExit est activé
IPSet Affiche si le support ipset est disponible
IPSetTypes Affiche les types ipsets supportés
IPv4 Affiche si le support IPv4 est disponible
IPv6 Affiche si le support IPv6 est disponible
IPv6_rpfilter Affiche si rpfilter IPv6 est activé
IndividualCalls Retourne les paramètres d'appel individuels
MinimalMark Retourne le paramètre de marque minimum

Codes de sortie

0 succès
11 ALREADY_ENABLED
12 NOT_ENABLED
13 COMMAND_FAILED
14 NO_IPV6_NAT
15 PANIC_MODE
16 ZONE_ALREADY_SET
17 UNKNOWN_INTERFACE
18 ZONE_CONFLICT
19 BUILTIN_CHAIN
20 EBTABLES_NO_REJECT
21 NOT_OVERLOADABLE
22 NO_DEFAULTS
23 BUILTIN_ZONE
24 BUILTIN_SERVICE
25 BUILTIN_ICMPTYPE
26 NAME_CONFLICT
27 NAME_MISMATCH
28 PARSE_ERROR
29 ACCESS_DENIED
30 UNKNOWN_SOURCE
31 RT_TO_PERM_FAILED
32 IPSET_WITH_TIMEOUT
33 BUILTIN_IPSET
34 ALREADY_SET
35 MISSING_IMPORT
36 DBUS_ERROR
37 BUILTIN_HELPER
100 INVALID_ACTION
101 INVALID_SERVICE
102 INVALID_PORT
103 INVALID_PROTOCOL
104 INVALID_INTERFACE
105 INVALID_ADDR
106 INVALID_FORWARD
107 INVALID_ICMPTYPE
108 INVALID_TABLE
109 INVALID_CHAIN
110 INVALID_TARGET
111 INVALID_IPV
112 INVALID_ZONE
113 INVALID_PROPERTY
114 INVALID_VALUE
115 INVALID_OBJECT
116 INVALID_NAME
117 INVALID_FILENAME
118 INVALID_DIRECTORY
119 INVALID_TYPE
120 INVALID_SETTING
121 INVALID_DESTINATION
122 INVALID_RULE
123 INVALID_LIMIT
124 INVALID_FAMILY
125 INVALID_LOG_LEVEL
126 INVALID_AUDIT_TYPE
127 INVALID_MARK
128 INVALID_CONTEXT
129 INVALID_COMMAND
130 INVALID_USER
131 INVALID_UID
132 INVALID_MODULE
133 INVALID_PASSTHROUGH
134 INVALID_MAC
135 INVALID_IPSET
136 INVALID_ENTRY
137 INVALID_OPTION
138 INVALID_HELPER
200 MISSING_TABLE
201 MISSING_CHAIN
202 MISSING_PORT
203 MISSING_PROTOCOL
204 MISSING_ADDR
205 MISSING_NAME
206 MISSING_SETTING
207 MISSING_FAMILY
252 NOT_RUNNING
253 NOT_AUTHORIZED
254 UNKNOWN_ERROR

09 janvier 2017

firewalld

Gestionnaire de firewall dynamique

firewalld fournis une gestion dynamique du firewall. Il supporte IPv4 et IPv6.

OPTIONS

--debug[=level] mode debug, de 1 à 10. le debug est écris dans /var/log/firewalld
--debug-gc Affiche les informations sur les fuites du collecteur. Le collecteur se lance toutes les 10 secondes, et s'il y a des fuites, il les affiche.
--nofork ne fork pas le service
--nopid désactive l'écriture du fichier pid.

Concepts

   firewalld a une interface D-Bus pour la configuration du firewall des services et applications. Il a également un client pour l'utilisateur. Les services ou applications utilisant déjà D-Bus peuvent demander des changements au firewall directement via D-Bus.

   firewalld fournis un suppport pour les zones, des services prédéfinis et les types ICMP et a une séparation des options de configuration permanentes et en temps-réel. La configuration permanente est chargé depuis des fichiers XML dans /usr/lib/firewalld ou /etc/firewalld

   Si NetworkManager n'est pas utilisé et que firewalld est démarré après que le réseau soit déjà définis, les connexions et interfaces créées manuellement ne sont pas liées à la zone spécifiée dans le fichier ifcfg. Les interfaces sont automatiquement géré par la zone par défaut. firewalld est également notifié sur les renommages de périphériques réseaux. Tout cela s'applique également aux interfaces qui ne sont pas contrôlés par NetworkManager si NM_CONTROLED=no est mis.

   On peut ajouter ces interfaces à une zone avec firewall-cmd [--permanent] --zone=zone --add-interface=interface. S'il y a un fichier ifcfg-interface, firewalld tente de changer ZONE=zone dans ce fichier.

   Si firewalld est rechargé, il va restaurer les liaisons d'interface qui étaient en place avant de recharger pour conserver les liaisons d'interfaces stables dans le cas d'interface non contrôlés par NetworkManager. Ce mécanisme n'est pas possible dans le cas du redémarrage de firewalld.

   Il est essentiel de conserver le paramètre ZONE= dans les fichiers ifcfg consistant avec les liaisons dans firewalld dans le cas d'interfaces non controlé par NetworkManager.

Zones

Une zone réseau ou firewall définis le niveau de confiance de l'interface utilisée pour une connexion. Il y a de nombreuses zones prédéfinies fournis par firewalld.

Services

Un service peut être une liste de ports locaux, protocoles, et destination et additionnellement une liste de modules firewall automatiquement chargé si un service est activé. L'utilisation de services prédéfinis simplifient l'activation/désactivation des accès à un service.

Types ICMP

ICMP est utilisé pour échanger les informations et messages d'erreur dans IP. les types ICMP peuvent être utilisé dans firewalld pour limiter l'échange de ces messages.

Configuration temps-réel

La configuration temps-réel est la configuration active et n'est pas permanente. Une fois le service rechargé/redémarré ou après un reboot système, les paramètres temps réel sont perdus s'ils ne sont pas également dans la configuration permanente.

Configuration permanente

Le configuration permanente est stockée dans les fichiers de configuration et est chargé au démarrage du service.

Interface directe

L'interface directe est principalement utilisée par les services ou application pour ajouter des règles firewall spécifiques.

Répertoires

/usr/lib/firewalld Configuration par défaut, types icmp, services et zones.
/etc/firewalld Configuration système ou utilisateur.

Signaux

SIGHUP

06 avril 2017

firewalld.conf

Fichier de configuration de firewalld

firewalld.conf est chargé par firewalld à l'initialisation. Ce fichier contient des options de configuration de base pour firewalld.

OPTIONS

DefaultZone Définis la zone par défaut pour les connection ou les interfaces si la zone n'est pas sélectionnée ou spécifiée par NetworkManager, initscripts, ou les outils en ligne de commande.
MinimalMark Pour certains paramètres de firewall, de nombreuses règles nécessaires dans différentes tables sont capable de gérer des paquets de la bonne manière. Pour celà, ces paquets sont marqués en utilisant le target MARK. Avec cette options, un block de marquage peut être réservé pour une utilisation privée; seules les marques au-delà de cette valeur sont utilisées. La valeur minimalMark par défaut est 100.
CleanupOnExit Si firewalld s'arrête, il nettoie toutes les règles firewall. Définir cette option à no ou false laisse les règles firewall intouchées. Défaut: yes, ou true.
Lockdown Activée, les changements du firewall via l'interface D-Bus sont limisées aux applications listées dans la liste lockdown. Défaut: no ou false
IPv6_rpfilter Activé, un test de filtre de chemin inverse dans un paquet pour IPv6 est effectué. Si une réponse au paquet serait envoyé via la même interface, le paquet match et est accepté, sinon il est supprimé. Pour IPv4, rp_filter est contrôllé via sysctl.
IndividualCalls Désactivé, les appels combinés -restore sont utilisé et pas les appels individuel pour appliquer les changements sur le firewall. L'utilisation d'appels individuels augmente le temps nécessaire pour appliquer les changements et pour démarrer le service, mais est bon pour le debuggage vu que les messages d'erreur sont plus spécifiques.
LogDenied Ajoute les règles de logging avant de rejeter ou supprimer dans les chaînes INPUT, FORWARD, et OUTPUT pour les règles par défaut, ainsi que le rejet et suppression final dans les zones pour le type de paquet l2 configuré. Les valeurs possible sont : all, unicast, broadcast, multicast et off. Défaut: off.

06 avril 2017

firewalld.direct

Fichier de configuration direct

   Ce fichier de configuration donne un accès plus directe au firewall. Il nécessite de connaître les concepts ip(6)tables/ebtables. Un fichier de configuration direct contient des informations sur les chaînes directes permanentes

Exemple de structure de fichier de configuration directe:
‹?xml version="1.0" encoding="utf-8"?›
‹direct›
    [ ‹chain ipv="ipv4|ipv6|eb" table="table" chain="chain"/› ]
    [ ‹rule ipv="ipv4|ipv6|eb" table="table" chain="chain" priority="priority"› args ‹/rule› ]
    [ ‹passthrough ipv="ipv4|ipv6|eb"› args ‹/passthrough› ]
‹/direct›

direct Tag définissant la configuration directe
chain Définis les noms pour les chaînes additionnelles. Optionnel et peut être spécifié plusieurs fois. Une entrée chaîne a exactement 3 attributs:

ipv="ipv4|ipv6|eb" Famille d'IP où la chaîne doit être créée
table="table" Nom de la table où la chaîne doit être créée
chain="chain" Nom de la chaîne, qui sera créée

rule Permet d'ajouter des règles à une chaîne intégrée ou ajoutée. Optionnel et peut être utilisé plusieurs fois. Une règle a exactement 4 attributs:

ipv="ipv4|ipv6|eb" Famille d'IP où la règle doit être ajoutée
table="table" Nom de la table où la règle doit être ajoutée
chain="chain" Nom de la chaîne où la règle doit être ajoutée
priority="priority" Priorité utilisée pour ordonner les règles. 0 signifie d'ajouter la règle en haut de la chaîne

passthrough Permet d'ajouter des règles à une chaîne intégrée ou ajoutée. Optionnel et peut être utilisé plusieurs fois. Une règle a exactement un attribut:

ipv="ipv4|ipv6|eb" Famille d'IP où le passthrough doit être ajouté

Exemples

Blacklister les réseaux 192.168.1.0/24 et 192.168.5.0/24 en loggant et supprimant très tôt dans la table raw:
‹chain ipv="ipv4" table="raw" chain="blacklist"/›
‹rule ipv="ipv4" table="raw" chain="PREROUTING" priority="0"›-s 192.168.1.0/24 -j blacklist‹/rule›
‹rule ipv="ipv4" table="raw" chain="PREROUTING" priority="1"›-s 192.168.5.0/24 -j blacklist‹/rule›
‹rule ipv="ipv4" table="raw" chain="blacklist" priority="0"›-m limit --limit 1/min -j LOG --log-prefix "blacklisted: "‹/rule›
‹rule ipv="ipv4" table="raw" chain="blacklist" priority="1"›-j DROP‹/rule›

28 mars 2017

firewalld.helper

firewalld.zones

Zones firewalld

Une zone réseau définis le niveau de confiance des connexions réseaux. C'est une des nombreuses relations, qui signifie qu'une connexion peut seulement faire partie d'une zone, mais une zone peut être utilisé pour de nombreuses connections réseaux. La zone définis les fonctionnalités firewall qui sont activés dans cette zone:

Services prédéfinis un service est une combinaison de ports et/ou protocols. Optionnellement, des modules netfilter peuvent être ajoutés ainsi que des adresses de destination IPv4 et IPv6
Protocoles et ports Définition de ports tcp ou udp, où les ports peuvent être un simple port ou une plage de ports.
Masquerading Les adresses d'un réseau privé sont mappés et cachés derrière une adresse IP publique.
Forward ports Un forward port est soit mappé au même port dans un autre hôte ou à un autre port dans le même hôte ou un autre port dans un autre hôte.
Règles de langage rich Le langage rich étend les éléments avec des adresses source et destination additionnels, logging, actions et limites pour les logs et actions. Il peut être utilisé pour les hôtes ou listing de réseau blanc ou noir.

zones disponibles

Il y a des zones fournies par firewalld triés en accord avec le niveau avec le niveau de confiance des zones:

drop Tous les paquets sont supprimés, sans réponse. Seul les connexions sortantes sont possibles
block Les connexions réseau entrantes sont rejetées avec un message icmp-host-prohibited pour IPv4 et icmp6-adm-prohibited pour IPv6. Seul les connexions initiées dans ce système sont possibles
public À utiliser dans les zones publiques. Ne pas faire confiance aux autres machines. Seuls les connections entrantes séléctionnées sont acceptés.
external À utiliser dans les réseaux externes avec le masquerading activé. Pas de confiance aux autres machines. Seules les connexions entrantes sélectionnées sont acceptées
dmz Pour les machines dans une zone démilitarisée publiquement accessibles avec accès limité au réseau interne. Seules les connections entrantes sélectionnées sont acceptés
work À utiliser dans les zones de travail. Fait confiance aux autres machines dans les réseaux de la machine. Seules les connexions entrantes sélectionnées sont acceptées
home À utiliser dans les réseaux personnels. Fait confiance aux autres machines du réseau. Seules les connections entrantes sélectionnées sont acceptées
internal À utiliser dans les réseaux interne. Fait confiance aux autres machines dans le réseaux non liés à la machine. Seules les connections entrantes séléctionnées sont acceptées
trusted Toutes les connections réseaux sont acceptées

Zones à utiliser

Un réseau WIFI publique par exemple, ne doit pas être de confiance, une connexion filaire personnelle devrait être de confiance.

Configurer ou ajouter une zone

   Pour configurer ou ajouter une zone, utiliser les interfaces firewalld. Il y a un outils de configuration graphique firewall-config, un outil en ligne de commande firewall-cmd ou l'interface D-Bus. Il est également possible de copier un fichier de zone dans /usr/lib/firewalld/zones dans /etc/firewalld/zones.

   La zone est stockée dans ifcfg de la connexion avec l'option ZONE=. Si l'option est manquante ou vide, la zone par défaut est utilisée.

  Si la connexion est contrôlée par NetworkManager, on peut également utiliser nm-connection-editor pour changer la zone

  Pour l'ajout ou la modifications d'interfaces non contrôlées par NetworkManager, firewalld tente de changer le paramètres ZONE dans le fichier ifcfg, s'il existe.

  Pour les interfaces non contrôlées par NetworkManager, lors de la suppression firewalld ne tente pas de changer la ZONE dans le fichier ifcfg. Cela permet de s'assuser qu'un ifdown ne réinitialise pas les paramètres de zone.

15 février 2012

GPShell

Interpréteur de script pour communiquer avec les cartes à puces compatibles GlobalPlatform

Il utilise le plugin de connection PCSC pour accéder aux cartes à puces. Il peut établir un canal sécurisé avec une carte à puce, charger, instantier, supprimer et lister les applications sur les cartes supportées. Ces applications sont pratiquement toujors des applets JAVA.

Installer GPShell et GlobalPlatform

Ajouter dans /etc/apt/sources.list les entrées:
http://ppa.launchpad.net/k-o-/globalplatform/ubuntu
http://ppa.launchpad.net/k-o-/globalplatform/ubuntu
ou, pour compiler les sources:
aptitude install gcc libpcsclite-dev pkg-config zlib zlib1g-dev libcur14-openssl-dev make
wget http://heanet.dl.sourceforge.net/sourceforge/globalplatform/globalplatform-6.0.0.tar.gz
tar xfvz globalplatform-6.0.0.tar.gz
cd globalplatform-6.0.0
./configure —prefix=/usr
make
make install
cd ..
wget http://heanet.dl.sourceforge.net/sourceforge/globalplatform/gpshell-1.4.4.tar.gz
tar xfvz gpshell-1.4.4.tar.gz
cd gpshell-1.4.4
./configure —prefix=/usr
make
sudo make install
cd ..

Commandes

establish_context Établir le contexte, nécessaire avant d’établir une communication avec la carte.
card_connect -reader Connection à la carte dans le lecteur spécifié par son nom (-reader) ou son numéro (-readerNumber)
select -AID Sélectionner l’instance de l’applet
card_disconnect Déconnecter la carte
release_context Arrêter le contexte
mode_201 Sélectionne le mode OpenPlatform 2.0.1
mode_211 Sélectionne le mode globalPlatform 2.1.1
enable_trace Active le debug APDU
enable_timer Log le temps d’exécution d’une commande
open_sc -keyind x -keyver x -key xyz -mac_key xyz -enc_key xyz -kek_key xyz -security x -scp x -scpimpl x -keyDerivation x (mode_211) -scp et scpimpl ne sont pas nécessaires.
open_sc -keyind x -keyver x -mac_key xyz -enc_key xyz (mode_201)
Install -file appletFile -priv privilege -sdAID sdAID -AID AIDInPkg -pkgAID packageAID -instAID instanceAID -nvCodeLimit x -nvDataLimit x Installer une applet
install_for_load -pkgAID x -sdAID sdAID -nvCodeLimit x
load -file appletFile Charger une applet. A utiliser si la commande install ne fonctionne pas.
get_status -element e0 Liste les applets, packages et domaines de sécurité
get_status -element 20 Liste les packages
get_status -element 40 Liste les applets et les domaines de sécurité
get_status -element 80 Liste me gestionnaire de carte et les domaine fournisseur de sécurité
get_data -identifier identifier Retourne la donnée pour l’identifieur donné
put_sc_key -keyver 0 -newkeyver 2 -mac_key new_MAC_key -enc_key new_ENC_key -kek_key new_KEK_key -cur_kek current_KEK_key Ajouter un nouveau jeu de clé version 2
put_sc_key -keyver 1 -newkeyver 1 -mac_key new_MAC_key -enc_key new_ENC_key -kek_key new_KEK_key -cur_kek current_KEK_key Remplacer le jeu de clé version 1
put_dm_keys -keyver 0 -newkeyver 2 -file public_rsa_key_file -pass password -key new_receipt_generation_key Place les clés de gestion délégués en version 2 (mode_211)
put_dm_keys -keyver 0 -newkeyver 2 -file public_rsa_key_file -pass password -key new_receipt_generation_key -cur_kek current_KEK_key Place les clé de gestion délégués en version 2 (mode_201)
send_apdu -APDU x Envoyer un APDU
send_apdu -sc 0 -APDU x Envoyer un APDU sans canal sécurisé
send_apdu_nostop -APDU x Envoyer un APDU et ne stop pas en cas d’erreur

OPTIONS

-reader readerName Nom du lecteur de carte
-readerNumber x Numéro du lecteur de carte
-protocol x Protocole (0 : T=0 ; 1 : T=1)
-keyind x Index de clé
-keyver Version du jeu de clé
-newkeyver x Nouvelle version du jeu de clé
-key key Valeur de la clé en hexa
-mac_key key Clé MAC en hexa
-enc_key key Valeur de clé ENC en hexa
-kek_key key Valeur de clé KEK en hexa
-security x 0 : aucun, 1:MAC, 3:MAC+ENC
-scp x Protocol du canal sécurisé (1 SCP01, 2 SCP02)
-scpimpl x Implémentation du canal sécurisé (ne devrait pas être sopécifié implicitement)
-pass password Mot de passe pour le déchiffrement de la clé
-sc x mode canal sécurisé (0 off, 1 on)
-keyDerivation (’non’, ’visa2’, ’emvcps11’)
-AID aid ID de l’applet
-sdAID aid AID du domaine sécurisé
-pkgAID aid AID du Package
-instAID aid AID de l’instance
-nvCodeLimit x Limite de taille du code non-volatile
-nvDataLimit x Limite de taille de donnée non-volatile
-vDataLimit x Limite de taille de donnée volatile
-file file Nom du fichier
-instParam param Paramètre d’installation
-priv x Privilège (ex : 0x04 Default Selected)
-element x Type d’élément à indexer en hexa

80 Card Manager / Card Issuer Security Domain only.
40 Applications (and Security Domains only in GP211).
20 Executable Load Files only.
10 Executable Load Files and their Executable Modules only (Only GP211)

-identifier Identifieur pour le tag pour la commande get_data (en hexa, ex : 9F7F)
-APDU apdu APDU à envoyer en hexa (ex : 80CA00CF00)

Variables d'environnement

GLOBALPLATFORM_DEBUG Active le mode debug depuis la librairie GlobalPlatform
GLOBALPLATFORM_LOGFILE Définis le fichier dans lequel écrire les logs

Installer une applet java sur une carte cyberflex 64k

mode_201
enable_trace
establish_context
card_connect
select -AID a000000003000000
open_sc -security 1 -keyind 0 -keyver 0 -mac_key 404142434445464748494a4b4c4d4e4f -enc_key 404142434445464748494a4b4c4d4e4f
delete -AID A0000003230101
delete -AID A00000032301
delete -AID A00000000101
delete -AID A000000001
install_for_load -pkgAID A000000001 -nvCodeLimit 13500 -sdAID A000000003000000
load -file CardEdgeCflex.ijc
install_for_install -instParam 00 -priv 02 -AID A00000000101 -pkgAID A000000001 -instAID A00000000101 -nvDataLimit 12000
card_disconnect
release_context

Ensuite il reste à intialiser le code pin à "00000000":
opensc-tool -s 00:A4:04:00:06:A0:00:00:00:01:01 -s B0:2A:00:00:38:08:4D:75:73:63:6C:65:30:30:04:01:08:30:30:30:30:30:30:30:30:08:30:30:30:30:30:30:30:30:05:02:08:30:30:30:30:30:30:30:30:08:30:30:30:30:30:30:30:30:00:00:17:70:00:02:01
Utiliser la carte avec opensc:
pkcs15-init -EC -p pkcs15+onepin

27 mai 2016

hash-to-efi-sig-list

Créer une entrée de liste de signature de hash depuis un binaire

Produit un fichier de liste de signature EFI contenant le hash SHA256 du binaire EFI

Exemples

Créer un fichier avec le binaire HelloWorld.efi, pour la placer dans les variables db avec UpdateVar
hash-efi-sig-list HelloWorld.efi hash.esl

13 février 2012

ifdhandler

Utilitaire de gestion des modules au format ifdhandler

OPTIONS

-r Index du lecteur de carte à utiliser
-F Tâche de fond
-H spécifie qu’il s’agit d’un lecteur hotplug
-p force le polling device event si les évènement sont supportés
-s Envoie les messages de debug et d’erreur à syslogd
-d mode debug (peut être spécifié plusieurs fois)
-i Affiche la liste des pilotes et protocoles disponibles

13 février 2012

ifdproxy

Utilitaire pour l'accès au lecteur de carte distant

OPTIONS

-d mode debug
-F Ne lance pas en tâche de fond

Commandes

server [-dF] Lance le mode serveur
export [-dF] name device address:port Exporte le lecteur de carte vers une machine distante
list [-dF] address:port Liste les périphériques sur la machine distante, ou tous les périphériques si aucune adresse n’est spécifiée

29 juin 2014

.k5identity

Liste de règles pour sélectionner un principal

   Ce fichier, qui réside dans le home d'un utilisateur, contient une liste de règle pour sélectionner un principal client basé sur le serveur accédé. Ces règles sont utilisée pour choisir un cache d'accréditifs dans la collection de cache quand c'est possible. Chaque ligne a la forme

  principal field=value

  Si le principal serveur rencontre toutes les contrainte de champ, le principal est choisi comme principal client. Les champs suivant sont reconnus:

realm Si le domaine du principal du serveur est connus, il est matché avec cette valeur, qui peut être un pattern en utilisant les wildcard shell.
service Si le serveur principal est un principal basé sur l'hôte, son composant service est matché avec la valeur, qui peut être un pattern en utilisant les wildcard shell.
host Si le principal du serveur est un principal basé sur l'hôte, son nom d'hôte est convertis en minuscule et matché avec la valeur, qui peut être un pattern en utilisant les wildcard shell.

   Si le principal du serveur matche plusieurs lignes dans ce fichier, le principal depuis le premier matche est utilisé. Si aucune ligne ne matche, les accréditifs seront sélectionnés d'une autre manière, tel que le realm heuristic ou le cache primaire courant.

L'exemple suivant sélectionne le principal client alice@KRBTEST.COM si le serveur principal est dans ce domaine, le principal alice/root@EXAMPLE.COM si l'hôte serveur est dans un sous-domaine, et le principal alice/mail@EXAMPLE.COM en accédant au service IMAP sur mail.example.com:
alice@KRBTEST.COM realm=KRBTEST.COM
alice/root@EXAMPLE.COM host=*.servers.example.com
alice/mail@EXAMPLE.COM host=mail.example.com service=imap

29 juin 2014

.k5login

Liste de principaux Kerberos

Ce fichier réside dans le home de l'utilisateur, contenant une liste de principaux Kerberos. tous ceux ayant des tickets valide pour un principal dans ce fichier est autorisé à accéder à l'hôte avec l'UID de l'utilisateur dont ce fichier est dans son home. Une utilisation commune est de placer ce fichier dans le home de root, autorisant les administrateurs système à accéder en root à l'hôte via Kerberos.

Exemples

Supposons que l'utilisateur Alice a un fichier .k5login dans son répertoire home contenant la ligne suivante:
bob@FOOBAR.ORG
Celà permet à bob d'utiliser Kerberos tel que SSH, pour accéder au compte Alice, en utilisant les tickets Kerberos de bob.
Supposons qu'Alice est un administrateur système. Alice et les autres administrateurs auront leurs principaux dans le .k5login de root:
alice@BLEEP.COM
joeadmin/root@BLEEP.COM
Cela permet aux administrateurs de se logger en root avec leur tickets.

27 juin 2014

k5srvutil

Commandes

list Liste les clé dans un keytab
change Utilise le protocole kadmin pour mettre à jours les clés dans la base Kerberos avec des clés générées aléatoirement, et met à jours les clés dans le keytab. Si un numéro de version de clé ne matche pas le numéro de version dans la base, l'opération échoue. Les anciennes clés sont laissées dans le keytab pour que des tickets existant continuent à fonctionner. Si le flag -i est donné, k5srvutil demande confirmation avant de changer chaque clé. -e permet de spécifier les types de chiffrement et de salt.
delold Supprime les anciennes clé du keytab.
delete Supprime les clés dans le keytab, demande confirmation.

k5srvutil utilise kadmin pour éditer le keytab.

OPTIONS

-i Demande confirmation pour chaque opération
-f filename Spécifie le fichier keytab
keysalts Spécifie les types de chiffrement et de salt à utiliser.

20 juin 2014

kadm5.acl

Fichier acl pour kadmind

Kadmind utilise un fichier d'acl pour gérer les droits d'accès à la base Kerberos. Pour les opérations qui affectent les principaux, le fichier d'acl contrôle également quels principaux peuvent opérer sur quels autres principaux. L'emplacement par défaut est LOCALSTATEDIR/krb5kdc/kadm5.acl ou la variable acl_file dans kdc.conf.

Syntaxe

   Les lignes vides ou commençant par # sont ignorées. les lignes contenant une entrée acl a le format suivant:

  principal permissions [target_principal [ restrictions] ]

  Note: l'ordre des lignes est importante. La première entrée correspondante va contrôler l'accès pour un acteur principal sur un principal cible.

principal (Nom de principal complet ou partiel) Spécifie le principal dont les permissions sont définies
permissions Spécifie quels opérations peuvent être effectuées ou non par le principal. C'est une chaîne d'un ou plusieurs caractères ou leur opposé majuscule qui désactive cette permission:

a ajout de principaux ou stratégies
c changer les mots de passe pour les principaux
d suppression de principaux ou stratégies
i demandes de renseignements concernant les principaux et stratégies
l lister les principaux ou stratégies
m modification de principaux ou stratégies
p propagation de la base de principaux
s paramétrage explicite des clés pour un principal
x raccourci pour admcil. Tous les privilèges

target_principal (Optionnel. Nom de principal complet ou partiel) Spécifie le principal sur lequel les permissions s'appliquent. chaque composant du nom peut être wildcarded (*). Peut également inclure des référence au principal, dans lequel *number matche le wilcard correspondant dans principal
restrictions (optionnel) Une chaîne de flags. Les restrictions permises sont:

{+|-}flagname flag est forcé à la valeur indiquée. Les flags permissifs sont les même que les flags + et - pour les commandes add_principal et modify_principal de kadmin.
-clearpolicy La stratégie est forcée à être vide
-policy pol La stratégie est forcée à pol
-{expire, pwexpire, maxlife, maxrenewlife} time (chaîne de temps getdate) la valeur associée est forcée à MIN(time, valeur demandée)

Ces flags agissent comme restriction sur toute opération d'ajout ou de modification qui sont permis dans la ligne d'ACL.

Attention: si le fichier d'acl est modifié, kadmind doit être redémarré pour prendre en compte les modifications.

Exemple

Exemple de fichies kadm5.acl:
*/admin@ATHENA.MIT.EDU    *
joeadmin@ATHENA.MIT.EDU ADMCIL
joeadmin/*@ATHENA.MIT.EDU il    */root@ATHENA.MIT.EDU
*/root@ATHENA.MIT.EDU cil    *1@ATHENA.MIT.EDU
*/*@ATHENA.MIT.EDU i
*/admin@EXAMPLE.COM x    *    -maxlife 9h -postdateable

ligne 1 Tout principal dans le domaine ATHENA.MIT.EDU avec une instance admin a tous les privilèges administratifs
ligne 2 et 3 L'utilisateur joeadmin a toutes les permissions avec son instance admin, joeadmin/admin@ATHENA.MIT.EDU (matche de la ligne 1), il n'a aucune permission avec son instance joeadmin@ATHENA.MIT.EDU (matche de la ligne 2). Ses instances root et autre non admin ont les permissions de lister et demander avec tout principal qui a l'instance root (macthe de la ligne 3).
ligne 4 Tout principal root dans ATHENA.MIT.EDU peut demander, lister ou changer les mots de passe de leur instance nul, mais pas les autres instance null.
ligne 5 Tout principal dans ATHENA.MIT.EDU (sauf joeadmin@ATHENA.MIT.EDU comme mentionné plus haut) a les privilèges demander.
ligne 6 Finallement, tout principal avec une instance admin dans EXAMPLE.COM a toutes les permissions, mais tout principal qu'ils créent ou modifient ne seront par capable d'obtenir de tickets post-datés ou avec une durée de vie supérieur à 9 heures.

25 juin 2014

kadmin

Interface CLI pour l'administration de Kerberos

kadmin et kadmin.local sont des interfaces en ligne de commande pour le système d'administration de Kerberos. Ils fonctionnent de manière similaire à l'exception que kadmin.local communique directement avec le fichier de base de données.

Le client distant kadmin utilise Kerberos pour s'authentifier auprès de kadmind en utilisant le principal de service kadmin/ADMINHOST, où ADMINHOST est le fqdn du serveur d'administration, ou kadmin/admin. Si le cache d'accréditifs contient un ticket pour un de ces principaux, et que l'option -c est spécifié, ce ticket est utilisé pour s'authentifier à kadmind. Sinon les options -p et -k sont utilisés pour spécifier le nom du principal client utilisé pour s'authentifier. Une fois que kadmin a déterminé le nom du principal, il demande un ticket de service au KDC, et l'utilise pour s'authentifier à kadmind.

OPTIONS

-r realms Utilise de domaine spécifié par défaut
-p principal Utilise le principal spécifié pour s'authentifier. Sinon, kadmin va ajouter /admin au nom de principal primaire du ccache par défaut, la valeur de la variable d'environnement USER, ou le username obtenu par getpwuid, dans cet ordre.
-k Utilise un keytab pour déchiffrer la réponse du KDC au lieu de demander un mot de passe. Dans ce cas, le principal par défaut sera host/hostname. S'il n'y a par de keytab spécifié avec l'option -t, le keytab par défaut sera utilisé.
-t keytab Utilise keytab pour déchiffrer la réponse du KDC. Peut seulement être utilisé avec l'option -k
-n Demande un traitement anonyme. 2 types de principaux anonyme sont supportés. Pour l'anonymité complète, configurer PKINIT et utiliser l'option -n avec un principal sous la forme @REALM. Si permis par le KDC, un ticket anonyme sera retourné. Une seconde forme est supportée, et cache l'identité du client mais pas le domaine du client. Pour ce mode, utiliser kinit -n avec un principal normal. Si supporté par le KDC, le principal, mais pas le domaine, sera remplacé par le principal anonymous.
-c credentials_cache Utile de cache d'accréditifs spécifié. Le cache devrait contenir un ticket de service pour kadmin/ADMINHOST ou kadmin/admin. Si non spéifié, kadmin demande un nouveau ticket au KDC et le stocke dans son propre cache temporaire.
-w password Utilise le mot de passe au lieu de le demander
-q query Effectue le requête spécifiée et quitte.
-d dbname Spécifie le nom de la base KDC. Ne s'applique par au module de base LDAP
-s admin_server[:port] Spécifie le serveur d'administration à contacter
-m Avec kadmin.local, demande le mot de passe maître de la base au lieu de chercher un fichier stash
-e “enc:salt...” Définis la liste keysalt à utiliser pour toute nouvelle clé créée.
-O Force l'utilisation de l'ancienne authentification AUTH_GSSAPI
-N Empêche l'utilisation de l'ancienne authentification AUTH_GSSAPI
-x db_args Spécifie les arguments spécifique à la base. les options supportée pour le module de base LDAP sont:

-x host=hostname Spécifie le serveur LDAP à contacter
-x binddn=bind_dn DN de l'objet à utiliser par le serveur d'administration pour le bind ldap.
-x bindpwd=bind_password Mot de passe pour le binddn
-x debug=level Niveau de verbosité pour le client OpenLDAP.

Commandes

En utilisant le client distant, les commandes disponible peuvent être restreins en accord avec les privilèges dans kadm5.acl.

add_principal

Crée le principal spécifié, en demandant 2 fois le mot de passe. Si aucune stratégie de mot de passe n'est spécifiée, la stratégie nommée default est assignée au principal si elle existe. Cependant, créer une stratégie default ne va pas assigner automatiquement ce stratégie aux principaux déjà existant. Cette stratégie peut être supprimée avec l'option -clearpolicy

-expire expdate (chaîne getdate_time) Date d'expiration du principal
-pwexpire pwexpdate (chaîne getdate_time) Date d'expiration du mot de passe
-maxlife maxlife (chaîne getdate_time) Durée de vie de ticket max pour le principal
-maxrenewlife maxrenewlife (chaîne getdate_time) Durée de vie de renouvellement max des tickets
-kvno kvno Numéro de version de clé initial
-policy policy Stratégie de mot de passe utilisé par ce principal.
-clearpolicy Empêche l'assignation automatique d'une stratégie si non spécifiée par -policy
{-|+}allow_postdated Droit d'obtenir des tickets post-datés
{-|+}allow_forwardable Droit d'obtenir des tickets forwardable
{-|+}allow_renewable Droit d'obtenir des tickets renouvelable
{-|+}allow_proxiable Droit d'obtenir des tickets proxiable
{-|+}allow_dup_skey Droit d'effectuer une authentification user-to-user
{-|+}requires_preauth force le principal à ce pré-authentifier
{-|+}requires_hwauth Utiisation d'un hardware pour la pré-authentification
{-|+}ok_as_delegate flag okay as delegate dans les tickets fournis avec ce principal en tant que service.
{-|+}allow_svr Droit de délivrer des tickets de service pour ce principal
{-|+}allow_tgs_req Droit d'obtenir un TGS pour un ticket de service pour ce principal
{-|+}allow_tix Droit d'obtenir un ticket pour ce principal
{-|+}needchange Force le changement de mot de passe à la prochaine authentification
{-|+}password_changing_service Marque ce principal comme principal de service de changement de mot de passe
{-|+}ok_to_auth_as_delegate Droit d'obtenir des tickets forwardable à soi-même depuis des utilisateurs arbitraires
{-|+}no_auth_data_required Droit d'ajouter des données PAC ou AD-SIGNEDPATH
-randkey Définis la clé du principal à une valeur aléatoire
-nokey Crée un principal sans clé
-pw password Définis de mot de passe pour ce principal
-e enc:salt,... Utilise la liste de keysalt pour les clés de ce principal.
-x db_princ_args Options spécifique à la base:

-x dn=dn Spécifie l'objet LDAP qui va contenir le principal Kerberos à créer
-x linkdn=dn Spécifie l'objet LDAP pour lequel le nouveau principal Kerberos va pointer
-x containerdn=container_dn Spécifie le conteneur sous lequel le principal Kerberos est créé
-x tktpolicy=policy Associe une stratégie de ticket au principal Kerberos

Note

Les options containerdn et linkdn ne peuvent pas être spécifiés avec l'option dn. Si ces options ne sont pas spécifiées, les principaux sont créés sous le conteneur principal configurés dans le domaine. Ces options devraient pointer dans les sous-arborescences ou le conteneur principal configurés dans le domaine.

Exemple
kadmin: addprinc jennifer
WARNING: no policy specified for "jennifer@ATHENA.MIT.EDU";
defaulting to no policy.
Enter password for principal jennifer@ATHENA.MIT.EDU:
Re-enter password for principal jennifer@ATHENA.MIT.EDU:
Principal "jennifer@ATHENA.MIT.EDU" created.
kadmin:

modify_principal

Modifie le principal spécifié, en changeant les champs spécifiés. Les options de add_principal s'appliquent également à cette commande, excepté -randkey, -pw et -e. Cette commande nécessite les privilège modify. Alias: modprinc

-unlock Débloque un principal.

rename_principal

Renomme l'ancien principal avec le nouveau principal. Demande configuration sauf si -force est donné. Nécessite les privilèges add et delete. Alias: renprinc

delete_principal

Supprime le principal spécifié de la base. emande configuration sauf si -force est donné. Nécessite les privilèges delete. Alias: delprinc

change_password

Change le mot de passe du principal. Demande un nouveau mot de passe si -randkey ou -pw ne sont pas spécifiés. Nécessite les privilège changepw, ou que le principal qui lance ce programme est le même que le principal à changer. Aliar: cpw

-randkey Définis la clé du principal à une valeur aléatoire
-pw password Définis de mot de passe pour ce principal
-e enc:salt,... Utilise la liste de keysalt pour les clés de ce principal.
-keepold Conserve les clés existantes dans la base.

Exemple
kadmin: cpw systest
Enter password for principal systest@BLEEP.COM:
Re-enter password for principal systest@BLEEP.COM:
Password for systest@BLEEP.COM changed.
kadmin:

purgekeys

Purge les anciennes clé du principal. Si -keepkvno est spécifié, alors seul les clés avec des kvno inférieur sont purgés. Si -all est spécifié, purge toutes les clés. Nécessite le privilège modify

get_principal

Récupère les attributs du principal. L'option -terce affiche les champs en tant que chaîne séparés par des tabulations. Nécessite le privilège inquire, ou que le principal utilisant le programme soit le même que le principal cible. Alias: getprinc

Exemple
kadmin: getprinc tlyu/admin
Principal: tlyu/admin@BLEEP.COM
Expiration date: [never]
Last password change: Mon Aug 12 14:16:47 EDT 1996
Password expiration date: [none]
Maximum ticket life: 0 days 10:00:00
Maximum renewable life: 7 days 00:00:00
Last modified: Mon Aug 12 14:16:47 EDT 1996 (bjaspan/admin@BLEEP.COM)
Last successful authentication: [never]
Last failed authentication: [never]
Failed password attempts: 0
Number of keys: 2
Key: vno 1, DES cbc mode with CRC-32, no salt
Key: vno 1, DES cbc mode with CRC-32, Version 4
Attributes:
Policy: [none]

kadmin: getprinc -terse systest
systest@BLEEP.COM 3 86400 604800 1
785926535 753241234 785900000
tlyu/admin@BLEEP.COM 786100034 0 0
kadmin:

list_principal

Récupère des noms de principal. L'expression est une expression glob qui peut contenir les caractères *, ? et []. Tous les noms de principaux qui matche l'expression sont affichés. Sans expression, liste tous les principauix. Si l'expression ne contient pas un caractère @, ce caractère est ajouté avec le domaine local à l'expression. Nécessite le privilège list. Alias: listprincs, get_principals, get_princs

Exemple
kadmin: listprincs test*
test3@SECURE-TEST.OV.COM
test2@SECURE-TEST.OV.COM
test1@SECURE-TEST.OV.COM
testuser@SECURE-TEST.OV.COM
kadmin:

get_strings

Affiche les attributs chaîne dans le principal. Nécessite le privilège inquire. Alias: getstr

set_strings

Définis un attribut chaîne dans le principal. Les attributs chaîne sont utilisés pour fournir une configuration par principal au KDC et certaine modules du KDC. Nécessite le privilège modify. Alias setstr. Les attributs suivants sont reconnus par le KDC:

session_enctypes Spécifie les types de chiffrement supportés pour les clés session quand le principal est authentifié en tant que serveur.

del_strings

Supprime un attribut chaîne du principal. Nécessite le privilège delete. Alias: delstr

add_policy

Ajoute une stratégie de mot de passe à la base. Nécessite le privilège add. Alias: addpol

-maxlife time (chaîne getdate_time) Définis la durée de vie max d'un mot de passe
-minlife time (chaîne getdate_time) Définis la durée de vie min d'un mot de passe
-minlength length Définis la longueur maximum d'un mot de passe
-minclasses number Définis le nombre minimum de classes de caractères requis dans un mot de passe. Les 5 classes sont: minuscule, majuscule, nombres, ponctuation et espaces blancs.
-history number Définis le nombre de clé à conserver pour un principal. Non supporté avec le module LDAP
-maxfailure maxnumber Définis le nombre d'échec d'authentification avant que le principal soit bloqué. 0 le désactive.
-failurecountinterval failuretime (chaîne getdate_time) Définis le temps permis entre les échecs d'authentification.
-lockoutduration lockouttime (chaîne getdate_time) Définis la durée pour lequel le principal est bloqué. 0 signifie que le compte est bloqué jusqu'à ce qu'un administrateur le débloque.
-allowedkeysalts Spécifie les tuples key/salt supportés pour les clés à long terme en définissant ou en changeant un mot de passe de principal. Les tuples doivent être séparés par une virgule. Pour enlever le tuple de la stratégie, utiliser "-"

Exemple
kadmin: add_policy -maxlife "2 days" -minlength 5 guests
kadmin:

modify_policy

Modifie la stratégié de mot de passe spécifiée. Les options sont les même que pour add_policy. Nécessite le privilège modify. Alias: modpol

delete_policy

Supprime la stratégie de mot de passe spécifiée. Demande confirmation. Échoue si la stratégie est utilisée par un principal. Nécessite le privilège delete. Alias: delpol

Exemple
kadmin: del_policy guests
Are you sure you want to delete the policy "guests"?
(yes/no): yes
kadmin:

get_policy

Affiche les valeurs de la stratégie spécifiées. -terse affiche les champs séparés par des tabulations. Nécessite le privilège inquire. Alias: getpol

Exemple
kadmin: get_policy admin
Policy: admin
Maximum password life: 180 days 00:00:00
Minimum password life: 00:00:00
Minimum password length: 6
Minimum number of password character classes: 2
Number of old keys kept: 5
Reference count: 17

kadmin: get_policy -terse admin
admin 15552000 0 6 2 5 17
kadmin:

list_policies

Liste des stratégie basée sur l'expression. Nécessite le privilège list. Alias: listpols, get_policies, getpols

Exemple
kadmin: listpols
test-pol
dict-only
once-a-min
test-pol-nopw

kadmin: listpols t*
test-pol
test-pol-nopw
kadmin:

ktadd

   Ajoute un principal, ou tous les principaux matchant l'expression de l'option glob, à chaque fichier keytab. Chaque clé de principal est randomisé dans le processus. Nécessite les privilèges inquire et changepw. pour utiliser -glob, nécessite le privilège list.

-k[eytab] keytab Utilise le fichier keytab spécifié
-e enc:salt,... Utilise la liste keysalt spécifiée
-q mode silencieux
-norandkey Ne randomise pas les clé. Ne peut pas être utilisé avec -e.

Exemple
kadmin: ktadd -k /tmp/foo-new-keytab host/foo.mit.edu
Entry for principal host/foo.mit.edu@ATHENA.MIT.EDU with kvno 3,
    encryption type aes256-cts-hmac-sha1-96 added to keytab
    FILE:/tmp/foo-new-keytab
kadmin:

ktremove

Supprime des entrées pour le principal spécifié du keytab. Ne nécessite aucune permission. Si all est spéficié, toutes les entrées pour le principal sont supprimés; si old est spécifié, toutes les entrée sauf le kvno le plus récent sont supprimés. Si kvno est spécifié, supprime les entrées avec ce kvno.

-k[eytab] keytab Utilise le fichier keytab spécifié
-q mode silencieux

Exemple
kadmin: ktremove kadmin/admin all
Entry for principal kadmin/admin with kvno 3 removed from keytab
FILE:/etc/krb5.keytab
kadmin:

lock

Bloque la base. Ne fonctionne qu'avec le module DB2

unlock

Réactive la base après un lock

list_requests

Liste les demandes kadmin disponible. Alias lr, ?

quit

Quitte le programme. Alias exit,q

25 juin 2014

kadmind

   Les noms de sections sont entre crochets, chaque section peut contenir 0 ou plusieurs relations, sous la forme:

  foo = bar

Sections

Le fichier kdc.conf peut contenir les sections suivantes:

[kdcdefaults] Valeurs par défaut pour le fonctionnement du KDC
[realms] Configuration et paramètres de base de données spécifique au domaine
[dbdefaults] Paramètres de base de données par défaut
[dbmodules] Paramètres par base de données
[logging] Contrôle les logs des services Kerberos

[kdcdefaults]

À une exception près, les relations dans cette section spécifient les valeur par défaut pour les variable du domaine à utiliser si la sous-section [realms] ne contient par de relation pour le tag.

host_based_services
kdc_ports
kdc_tcp_ports
no_host_referral
restrict_anonymous_to_tgt
kdc_max_dgram_reply_size Spécifie la taille de packet maximum que peut être envoyé en UDP. Défaut: 4096

[realms]

   Chaque tag dans cette section est le nom d'un domaine Kerberos. La valeur du tag est une sous-section où les relations définissent les paramètres du KDC pour ce domaine. L'exemple suivant montre comment définir un paramètre pour le domaine ATHENA.MIT.EDU:

[realms]
    ATHENA.MIT.EDU = {
        max_renewable_life = 7d 0h 0m 0s
    }

acl_file (chaîne). Emplacement du fichier d'acl que kadmind utilise pour déterminer quels principaux ont un accès privilégié à la base. Défaut: LOCALSTATEDIR/krb5kdc.acl
database_module (chaîne). Indique le nom de la section de configuration sous [dbmodules] pour les paramètres spécifiques à la base utilisé par la librairie. Défaut: le nom du domaine.
database_name (chaîne, déprécié) Spécifie l'emplacement de la base Kerberos pour ce domaine, si DB2 est utilisé et que la section de configuration [dbmodules] ne spécifie par un nom de base. Défaut: LOCASTATEDIR/krb5kdc/principal
default_principal_expiration (chaîne, temps absolu). Spécifie le temps d'expiration par défaut des principaux créés dans ce domaine. Défaut: 0 qui signifie aucune expiration.
default_principal_flags (Chaîne) Spécifie les attributs par défaut des principaux crées dans ce domaine. Le format est une liste de flags séparés par une ",", avec un "+" avant chaque flag à ajouter, et "-" à enlever. Défaut: les flag suivant sont permis postdateable, forwardable, tgt-based, renewable, proxiable, dup-skey, allow-tickets, et service. Les flags possibles sont:

allow-tickets Le KDC va fournir de tickets pour ce principal
dup-skey permet au principal d'obtenir une clé de session pour un autre utilisateur.
forwardable Permet au principal d'obtenir des tickets forwardable
hwauth Le principal doit utiliser un périphérique hardware pour la pré-authentification
no-auth-data-required Empêche les données PAC et AD-SIGNEDPATH d'être ajoutés au ticket de service pour le principal
ok-as-delegate Indique au client que les accréditifs peuvent et devraient être délégués en s'authentifiant auprès du service
ok-to-auth-as-delegate Permet au principal d'utiliser des tickets S4USelf
postdateable Permet au principal d'obtenir des tickets post-datés.
preauth Le principal doit de pré-authentifier auprès du KDC avant de recevoir un ticket. Pour un principal de service, cela signifie que les tickets de service pour ce principal seront uniquement fournis aux clients avec un TGT qui a le bit preauthenticated mis.
proxiable Permet au principal d'obtenir des tickets proxy
pwchange Force le changement de mot de passe pour ce principal
pwservice Marque ce principal comme service de changement de mot de passe. Devrait être utilisé uniquement dans des cas spéciaux, par exemple, si le mot de passe de l'utilisateur a expiré, alors l'utilisateur doit obtient des tickets pour ce principal sans passer par une authentification normal par mot de passe pour pouvoir changer le mot de passe.
renewable Permet au principal d'obtenir des tickets renouvelable.
service Permet au KDC de fournir des tickets de service pour ce principal
tgt-based Permet au principal d'obtenir des tickets basés sur un TGT au lieu de répéter le process d'authentification utilisé pour obtenir ce TGT.

dict_file (chaîne) Emplacement du fichier dictionnaire contenant les chaînes non permises pour un mot de passe.
host_based_services (liste séparée par des espaces ou des virgules) Liste des services qui vont obtenir un traitement des référants basés sur l'hôte même si le principal du serveur n'est pas marqué comme basé sur l'hôte par le client.
iprop_enable (bool) Spécifie si la propagation incrémentale de la base est permise. Défaut: false.
iprop_master_ulogsize (entier) Spécifie le nombre max d'entrées de log à retenir pour la propagation incrémentale. max: 2500, défaut: 1000
iprop_slave_poll (chaîne de temps delta) Spécifie la fréquence des mises à jours les esclaves auprès du maître. Défaut: 2m (minutes)
iprop_port (numéro de port) Spécifie le numéro de port à utiliser pour la propagation incrémentale. Requis dans les configuration des maître et esclaves.
iprop_resync_timeout (chaîne de temps delta). Spécifie le temps d'attente pour une propagation complète. Optionnel et est utilisé par les esclaves uniquement. Défaut: 5m.
iprop_logfile (Nom de fichier) Spécifie où se situe le fichier de log des mises à jours. Par défaut, utilise database_name.ulog
kadmind_port (numéro de port) Port d'écoute du service kadmind. Défaut: 749
key_stash_file (chaîne) Spécifie l'emplacement du fichier stash. Défaut: LOCALSTATEDIR/krb5kdc/.k5.REALM.
kdc_ports (liste séparée par des espaces ou des virgules) Liste de ports d'écoute du serveur Kerberos pour les requêtes UDP. Défaut: 88,750
kdc_tcp_ports (liste séparée par des espaces ou des virgules) Liste de ports d'écoute du serveur Kerberos pour les requêtes TCP (Défaut: 88).
master_key_name (chaîne) Spécifie le nom du principal associé avec la clé maître. Défaut: K/M
master_key_type (Chaîne de type de clé) Spécifie le type de clé maître. Défaut: aes256-cts-hmac-sha1-96.
max_life (chaîne de temps) Spécifie le temps maximum pour lequel un ticket peut être valide dans le domaine. Défaut: 24heures.
max_renewable_life (chaîne de temps) Spécifie le temps maximum durant lequel un ticket valide peut être renouvelé dans ce domaine. Défaut: 0
no_host_referral (liste séparée par des espaces ou des virgules) Liste
des_crc_session_supported (bool) À true, le KDC assume que les principaux de service supportent des-cbc-crc pour les type de clé de session. Défaut: true.
reject_bad_transit (bool) À true, le KDC vérifie la liste des domaines de transit pour les tickets inter-domaines avec le chemin de transit calculé depuis les noms des domaines et la section capaths de son fichier krb5.conf; si le chemin dans le ticket contient un domaine qui n'est pas dans le chemin calculé, le ticket ne sera pas délivré. Si cette valeur est à false, de tels tickets seront toujours émis. si le flag disable-transited-check est mis dans la requête entrante, cette vérification n'est pas effectuée. L'option reject_bad_transit force de telles requête à être toujours rejetées. Défaut: true
restrict_anonymous_to_tgt (bool) À true, le KDC rejète les demandes de tickets pour des principaux anonymes au principaux de service autre que le domaine du TGS. Cette option permet les PKINIT anonymes pour les tickets FAST sans autoriser l'authentification anonyme aux services. Défaut: false.
supported_enctypes (liste de key:salt) Spécifie les combinaisons key/salt par défaut des principaux pour ce domaine. Tout principal créé via kadmin aura des clé de ce type. Défaut: aes256-cts-hmac-sha1-96:normal aes128-cts-hmac-sha1-96:normal des3-cbc-sha1:normal arcfour-hmac-md5:normal.

[dbdefaults]

Cette section spécifie les valeur par défaut pour certains paramètres de base, à utiliser si la sous-section dbmodules ne contient pas de relation pour ce tag.

ldap_kerberos_container_dn
ldap_kdc_dn
ldap_kadmind_dn
ldap_service_password_file
ldap_servers
ldap_conns_per_server

[dbmodules]

   Cette section contient des paramètres utilisés par les bases du KDC et les modules. Chaque tag dans cette section est le nom d'un domaine Kerberos ou un nom de section spécifié par le paramètre database_module du domaine. L'exemple suivant montre comment définir un paramètre de base pour le domaine ATHENA.MIT.EDU:

[dbmodules]
    ATHENA.MIT.EDU = {
        disable_last_success = true
    }

database_name Ce tag spécifique à db2 indique l'emplacement de la base dans le système de fichier. Défaut: LOCALSTATEDIR/krb5kdc/principal
db_library Indique le nom du module de base à charger. peut être db2 ou kldap
disable_last_success À true, supprime les mises à jours KDC du champ "last successful authentication" des entrées de principal nécessitant une pré-authentification. Positionner ce flag peut améliorer les performances. (Les entrées de principal qui ne nécessitent par de pré-authentification ne mettent jamais ce champ)
disable_lockout À true, supprime les champs "last failed authentication" et "failed password attempts" des entrées de principal nécessitant une pré-authentification. peut améliorer les performances.
ldap_conns_per_server Indique le nombre de connexios à maintenir par serveur LDAP
ldap_kadmind_dn Indique le bind DN par défaut pour le service kadmind. Cet objet devrait avoir les droits de lire et écrire dans la base Kerberos dans la base LDAP.
ldap_kdc_dn Indique le bind DN par défaut pour le service krb5kdc. Cet objet devrait avoir les droits de lire dans la base Kerberos dans la base LDAP et d'écrire les données sauf si disable_lockout et disable_last_success sont à true.
ldap_kerberos_container_dn Indique le DN de l'objet conteneur où les objets de domaine sont localisés.
ldap_servers Liste les serveur LDAP à contacter.
ldap_service_password_file Indique le fichier contenant les mots de passe stashed (créés par kdb5_ldap_util stashsrvpw) pour les objets ldap_kadmind_dn et ldap_kdc_dn.
db_module_dir contrôle l'emplacement les modules de base de données. devrait être un chemin absolu. Ce tag pour être spécifié directement dans la section dbmodules.

[logging]

   Cette section indique comment krb5kdc et kadmind effectuent les logs. Les clés dans cette section sont les noms des services, qui peut être un parmi:

admin_server Spécifie comment kadmind effectue les logs
kdc Spécifie comment krb5kdc effectue les logs
default Spécifie comment les 2 services effectuent les logs.

   Les valeurs sont sous la forme suivante:

FILE=filename ou FILE:filename Log les messages dans le fichier spécifié. si la 1ère forme est utilisée, le fichier est écrasé.
STDERR Log les message sur stderr
CONSOLE Log les messages dans la console
DEVICE=‹devicename› Log les messages dans le périphérique spécifié
SYSLOG[:severity[:facility]] Los les messages dans syslog

Dans l'exemple suivant, les messages du KDC vont dans la console et dans syslog. Les messages de kadmind vont dans /var/adm/kadmin.log et dans le périphérique /dev/tty04
[logging]
    kdc = CONSOLE
    kdc = SYSLOG:INFO:DAEMON
    admin_server = FILE:/var/adm/kadmin.log
    admin_server = DEVICE=/dev/tty04

[otp]

   Chaque sous-section de [opt] est le nom du type de token OTP. Les tags dans la sous-section définis la configuration requise pour forwarder une requête OTP au serveur radius. Pour chaque type de token, les tags suivants peuvent être spécifiés:

server Serveur où envoyer les requêtes RADIUS. Peut être un nom d'hôte et un port optionnel, une adresse IP ou un socket UNIX. Défaut LOCALSTATEDIR/krb5kdc/‹name›.socket
secret Indique le fichier qui peut être relatif à LOCALSTATEDIR/krb5kdc contenant le secret utilisé pour chiffré les packets RADIUS. Le secret devrait apparaître sur la première ligne du fichier. Si server indique un socket unix, ce tag est optionnel.
timeout Entier qui spécifie le temps en secondes durant lequel de KDC devrait attendre pour contacter le serveur RADIUS. Ce tag est le temps total entre toutes les tentatives et devrait être inférieur au temps de validité de l'OTP. Défaut: 5 secondes
retries Nombre de re-tentatives auprès du serveur RADIUS. Défaut: 3
strip_realm À true, le principal sans le domaine sera passé au serveur RADIUS, sinon le domaine est inclus. Défaut: true.

Dans l'exemple suivant, les requêtes sont envoyées à un serveur distant via UDP:
[otp]
    MyRemoteTokenType = {
        server = radius.mydomain.com:1812
        secret = SEmfiajf42$
        timeout = 15
        retries = 5
        strip_realm = true
    }

Un token par défaut implicite nommé DEFAULT est définis pour les type de token non spécifiés. Sa configuration est décrite ci-dessous.
[otp]
    DEFAULT = {
        strip_realm = false
    }

Options PKINIT

   Cet valeurs peuvent être spécifiées dans [kdcdefaults] comme valeur par défaut, ou dans une sous-section de [realms]. Noter qu'une valeur spécifique à un domaine remplace, n'ajoute pas, une spécification kdcdefaults. L'ordre de recherche est:

1. sous-section de [realms]:
    [realms]
        EXAMPLE.COM = {
            pkinit_anchors = FILE:/usr/local/example.com.crt
        }

2. Valeur générique dans la section [kdcdefaults]:
    [kdcdefaults]
        pkinit_anchors = DIR:/usr/local/generic_trusted_cas/

pkinit_anchors Spécifie l'emplacement des certificats de confiance racine que le client utilise pour signer les certificats KDC. Peut être spécifié plusieurs fois.
pkinit_dh_min_bits Taille de la clé Diffie-Hellman que le client va tenter d'utiliser. les valeur acceptable sont 1024, 2048 (défaut), et 4096.
pkinit_allow_upn Spécifie que le KDC est prêt à accepter les certificats client avec un SAN UPN. Défaut: false. Sans cette option, le KDC accepte uniquement les certificats avec id-pkinit-san comme définis dans la rfc4556. Il n'y a actuellement aucune option pour désactiver la vérification SAN dans le KDC.
pkinit_eku_checking spécifie quelle valeur d'Extended Key Usage le KDC est prêt à accepter dans les certificats client. Les valeurs reconnues sont:

kpClientAuth C'est la valeur par défaut et spécifie que les certificats client doivent avoir le id-pkinit-KDKdc EKU comme définis dans la rfc4556.
scLogin Les certificats client avec id-ms-sc-logon seront acceptés
none Les certificats client ne seront pas vérifiés pour un EKU acceptable.

pkinit_identity Spécifie l'emplacement des information d'identité X.509 du KDC. Cette option est requise si pkinit est supportée par le KDC
pkinit_kdc_ocsp Spécifie l'emplacement de l'OCSP du KDC
pkinit_mapping_file Spécifie le nom du fichier de mappage d'acl pkinit. Ce fichier map les principaux aux certificats qu'ils utilisent.
pkinit_pool Spécifie l'emplacement des certificats intermédiaires qui peuvent être utilisés par le KDC pour compléter le chaîne. Peut être spécifiée plusieurs fois
pkinit_revoke Spécifie l'emplacement de la CRL. Peut être spécifié plusieurs fois
pkinit_require_crl_checking Spécifie que la vérification de révocation est requise.

Types de chiffrement

des-cbc-crc DES cbc mode avec CRC-32 (weak)
des-cbc-md4 DES cbc mode avec RSA-MD4 (weak)
des-cbc-md5 DES cbc mode avec RSA-MD5 (weak)
des-cbc-raw DES cbc mode raw (weak)
des3-cbc-raw Triple DES cbc mode raw (weak)
des3-cbc-sha1 des3-hmac-sha1 des3-cbc-sha1-kd Triple DES cbc mode avec HMAC/sha1
des-hmac-sha1 DES avec HMAC/sha1 (weak)
aes256-cts-hmac-sha1-96 aes256-cts AES-256 CTS mode avec 96-bit SHA-1 HMAC
aes128-cts-hmac-sha1-96 aes128-cts AES-128 CTS mode avec 96-bit SHA-1 HMAC
arcfour-hmac rc4-hmac arcfour-hmac-md5 RC4 avec HMAC/MD5
arcfour-hmac-exp rc4-hmac-exp arcfour-hmac-md5-exp Exportable RC4 avec HMAC/MD5 (weak)
camellia256-cts-cmac camellia256-cts Camellia-256 CTS mode avec CMAC
camellia128-cts-cmac camellia128-cts Camellia-128 CTS mode avec CMAC
des Fammille DES: des-cbc-crc, des-cbc-md5, and des-cbc-md4 (weak)
des3 Famille triple DES: des3-cbc-sha1
aes Famille AES: aes256-cts-hmac-sha1-96 and aes128-cts-hmac-sha1-96
rc4 Famille RC4: arcfour-hmac
camellia Famille Camellia: camellia256-cts-cmac and camellia128-cts-cmac

La chaîne DEFAULT peut être utilisé pour les type de jeu par défaut pour les variables en question. Les types ou familles peuvent être supprimées de la liste courante en les préfixant avec un "-". Les types ou familles peuvent être préfixés avec un "+" pour la symétrie; il a la même signification que simplement lister le type ou la famille. Par exemple, DEFAULT -des sera le jeu de chiffrement par défaut avec les types DES supprimés, et des3 DEFAULT sera le jeu de chiffrement par défaut avec triple DES supprimé.

Alors que aes128-cts et aes256-cts sont supportés pour toutes les opérations Kerberos, ils ne sont pas supportés par d'anciennes versions de l'implémentation GSS-API.

Listes de keysalt

   Les clés Kerberos pour les utilisateurs sont généralement dérivés des mots de passe. Les commandes et les paramètres de configuration Kerberos qui affectent la génération de clés prennent la liste des paires enctype-salttype, appelés "liste keysalt". Chaque paire keysalt est un nom de type de chiffrement suivi par un nom de salttype, dans le format enc:salt. Par exemple:

  kadmin -e aes256-cts:normal,aes128-cts:normal

  va lancer kadmin pour qu'il génère par défaut des clé dérivés pour les types de chiffrement aes256-cts et aes128-cts, en utilisant un salt normal.

   Pour s'assurer que les gens qui utilisent le même mot de passe n'aient pas la même clé, Kerberos 5 incorpore plus d'informations dans la clé en utilisant un salt. Les types de salt supportés sont les suivant:

normal Défaut pour Kerberos v5
v4 Utilisé uniquement par Kerberos v4 (pas de salt)
norealm Idem au défaut, sans utiliser d'information de domaine.
onlyrealm Utilise seulement les information de domaine comme salt
afs3 AFS version 3, utilisé uniquement pour la compatibilité avec Kerberos v4
special Génère un salt aléatoire.

Exemple

Exemple de fichier de configuration kdc.conf
[kdcdefaults]
    kdc_ports = 88

[realms]
    ATHENA.MIT.EDU = {
        kadmind_port = 749
        max_life = 12h 0m 0s
        max_renewable_life = 7d 0h 0m 0s
        master_key_type = des3-hmac-sha1
        supported_enctypes = des3-hmac-sha1:normal des-cbc-crc:normal des-cbc-crc:v4
        database_module = openldap_ldapconf
    }

[logging]
    kdc = FILE:/usr/local/var/krb5kdc/kdc.log
    admin_server = FILE:/usr/local/var/krb5kdc/kadmin.log

[dbdefaults]
    ldap_kerberos_container_dn = cn=krbcontainer,dc=mit,dc=edu

[dbmodules]
    openldap_ldapconf = {
        db_library = kldap
        disable_last_success = true
        ldap_kdc_dn = "cn=krbadmin,dc=mit,dc=edu"
        ldap_kadmind_dn = "cn=krbadmin,dc=mit,dc=edu"
        ldap_service_password_file = /etc/kerberos/service.keyfile
        ldap_servers = ldaps://kerberos.mit.edu
        ldap_conns_per_server = 5
    }

30 juin 2014

kdestroy

Supprimer les caches d'accréditifs

kdestroy est un utilitaire pour supprimer des tickets d'autorisation Kerberos actifs en supprimant les caches d'accréditifs. Si le cache n'est pas spécifié, le cache par défaut est supprimé.

OPTIONS

-A Supprime tous les caches dans la collection, si une collection de cache est disponible
-q mode silencieux
-c cache_name Supprime le cache spécifié

Notes

Le cache d'accréditifs par défaut peut varier entre les systèmes. Si la variable d'environnement KRB5CCNAME est définie, sa valeur est utilisée comme cache de tickets par défaut.

Il est recommandé de placer la commande kdestroy dans le fichier .logout pour supprimer tous les tickets à la deconnexion.

Variable d'environnement

KRB5CCNAME peut contenir un nom de cache d'autorisations Kerberos5

fichiers

DEFCCNAME Emplacement par défaut pour le cache d'accréditifs Kerberos 5

01 juillet 2014

Kerberos - Formats

Formats et données diverses

Format de temps supportés

   Le format time_duration est utilisé pour exprimé une durée de temp dans les fichiers de configuration Kerberos est les commandes utilisateur. Les formats permis sont:

Format____Exemple____valeure
h:m[:s]___36:00______36 hours
NdNhNmNs__8h30s______8 hours 30 seconds
N_________3600_______1 hour

   Note: l'interval de temps ne devrait pas excéder 2147483647 secondes.

   Le format getdate_time spécifie une date. Les formats permis sont:

Date___________mm/dd/yy______07/27/12
_______________month dd, yyyy_Jul 27, 2012
_______________yyyy-mm-dd____2012-07-27
Absolute time__HH:mm[:ss]pp__08:30 PM
_______________hh:mm[:ss]____20:30
Relative time__N tt__________30 sec
Time zone______Z_____________EST
_______________z_____________-0400

   Le format absolute_time, rarement utilisé peut être noté selon un des formats suivants:

Format__________________Example_______________Value
yyyymmddhhmmss__________20141231235900________One minute before 2015
yyyy.mm.dd.hh.mm.ss_____2014.12.31.23.59.00
yymmddhhmmss____________141231235900
yy.mm.dd.hh.mm.ss_______14.12.31.23.59.00
dd-month-yyyy:hh:mm:ss__31-Dec-2014:23:59:00
hh:mm:ss________________20:00:00______________8 o’clock in the evening

Types de chiffrement

   Kerberos peut utiliser divers algorithmes de chiffrement pour protéger des données. Un type de chiffrement Kerberos est une combinaison spécifique d'un algorithme de chiffrement avec un algorithme d'intégrité pour fournir la confidentialité et l'intégrité des données. Les clients effectuent 2 types de demandes (KDC-REQ) au KDC: AS-REQ et TGS-REQ. Le client utilise l'AS-REQ pour obtenir des tickets initiaux ( appelés TGT ), et utilisent TGS-REQ pour obtenir des tickets de service. Le KDC utilise 3 types de clé différentes en fournissant un ticket au client.

La clé long-terme du service: Le KDC l'utilise pour chiffrer le ticket de service actuel. Le KDC utilise la première clé long-terme dans le kvno le plus récent.
La clé de session: Le KDC choisis aléatoirement cette clé et place une copie dans le ticket et une autre copie dans la partie chiffrée de la réponse.
La clé de chiffrement de réponse: Le KDC l'utilise pour chiffrer la réponse qu'il envoie au client. Pour les réponses AS, c'est une clé long-terme du client. Pour les réponses TGS, c'est soit la clé de session du ticket authentifiant, ou une clé de sous-session.

   Chaque type de demande permet au client d'envoyer une liste de type de chiffrement qu'il accepte. Pour AS-REQ, cette liste affecte la sélection de la clé de session et la clé de chiffrement de la réponse. Pour TGS-REQ, cette liste affecte uniquement la sélection de la clé de session.

   Compatibilité des types de chiffrement:
   des-cbc-crc_____________weak____all_____›=2000
   des-cbc-md5_____________weak____all__ __›=2000
   arcfour-hmac____________ _______›=1.3___›=2000
   aes128-cts-hmac-sha1-96_ _______›=1.3___›=Vista
   camellia128-cts-cmac____ _______›=1.9___none

Variables d'environnement

KRB5_CONFIG Spécifie l'emplacement de krb5.conf
KRB5_KDC_PROFILE Spécifie l'emplacement de kdc.conf
KRB5_KTNAME Fichier keytab par défaut
KRB5_CLIENT_KTNAME Fichier keytab client par défaut
KRB5CCNAME fichier du cache d'accréditifs par défaut, sous la forme type:residual
KRB5RCACHETYPE Type de cache replay par défaut. (défaut: dfl) none pour le désactiver
KRB5RCACHEDIR Répertoire du cache replay par défaut.
KPROP_PORT port kprop à utiliser. Défaut: 754
KRB5_TRACE Fichier pour les logs.

18 juin 2014

Kerberos - Installer les KDC

Introduction à la configuration initiale des KDC

En implémentant Kerberos dans un environnement de production, il est préférable d'avoir plusieurs KDC esclave avec un KDC maître pour s'assurer de la disponibilité continue des service kerberisés. Chaque KDC contient une copie de la base de donnée Kerberos. Le KDC maître contient la copie modifiable de la base, qui est répliquée au esclaves à intervalle régulier. Tous les changements de base sont faites sur le maître. Les esclave fournissent les services TGS, mais pas d'administration de la base, quand le KDC maître n'est pas disponible. Le MIT recommande d'installer tous les KDC pour être en mesure de fonctionner soit en tant que maître ou un esclave. Celà permet de facilement basculer un esclave en maître si nécessaire.

Attention

Le système Kerberos s'appuyent du la disponibilité des informations de temps correcte, assurez vous que le maître et les esclaves ont une horloge synchronisée correctement. Il est préférable d'installer les KDC sur du hardware dédié et sécurisé avec un accès limité.

Installer et configurer le KDC maître

Dans ce document, nous utilisons les noms suivants:
kerberos.mit.edu____-_master KDC
kerberos-1.mit.edu__-_slave KDC
ATHENA.MIT.EDU______-_realm name
.k5.ATHENA.MIT.EDU__-_stash file
admin/admin_________-_admin principal

Éditer les fichiers de configuration du KDC

Modifier les fichiers de configuration, krb5.conf et kdc.conf, pour refléter les informations telles que le mappage domain-realm et les noms des serveurs kerberos. Beaucoup de tags dans la configuration ont des valeurs par défaut qui sont adéquat à la plupart des sites. Les variables KRB5_CONFIG et KRB5_KDC_PROFILE permettent de spécifier les fichiers altérnatifs:

export KRB5_CONFIG=/yourdir/krb5.conf
export KRB5_KDC_PROFILE=/yourdir/kdc.conf

krb5.conf

   Si vous n'utilisez pas les enregistrements DNS TXT, vous devez spécifier le default_realm dans la section [libdefault]. Si vous n'utilisez par les enregistrements DNS SRV, vous devez inclure le tag kdc pour chaque realm dans la section [realms]. Pour communiquer avec le serveur kadmin dans chaque realm, le tag admin_server doit être définis dans la section [realms].

Exemple de fichier krb5.conf
[libdefaults]
    default_realm = ATHENA.MIT.EDU

[realms]
    ATHENA.MIT.EDU = {
        kdc = kerberos.mit.edu
        kdc = kerberos-1.mit.edu
        admin_server = kerberos.mit.edu
    }

kdc.conf

   Ce fichier peut être utilisé pour contrôler les ports d'écoute du KDC en de kadmind, et les paramètres par défaut spécifique au realm, le type de base et son emplacement et le logging.

Exemple de fichier kdc.conf
[kdcdefaults]
    kdc_ports = 88,750

[realms]
    ATHENA.MIT.EDU = {
        kadmind_port = 749
        max_life = 12h 0m 0s
        max_renewable_life = 7d 0h 0m 0s
        master_key_type = aes256-cts
        supported_enctypes = aes256-cts:normal aes128-cts:normal
        # If the default location does not suit your setup,
        # explicitly configure the following values:
        #    database_name = /var/krb5kdc/principal
        #    key_stash_file = /var/krb5kdc/.k5.ATHENA.MIT.EDU
        #    acl_file = /var/krb5kdc/kadm5.acl
    }

[logging]
    # By default, the KDC and kadmind will log output using
    # syslog. You can instead send log output to files like this:
    kdc = FILE:/var/log/krb5kdc.log
    admin_server = FILE:/var/log/kadmin.log
    default = FILE:/var/log/krb5lib.log

   Remplacer ATHENA.MIT.EDU et kerberos.mit.edu avec le nom de votre domaine et serveur Kerberos, respectivement.

  Note: vous devez avoir les droits d'écriture sur les répertoires cibles ( et doivent exister ) utilisés par database_name, key_stash_file, et acl_file.

Créer la base KDC

   Il faut utiliser la commande kdb5_util sur le KDC maître pour créer la base Kerberos et le fichier optionnel stash.

  Note: Si vous choisissez de ne pas installer un fichier stash, le KDC va vous demander la clé maître chaque fois qu'il démarre.

   kdb5_util va vous demander le mot de passe maître pour la base Kerberos. L'exemple suivant montre comment créer une base Kerberos et le fichier stash sur le KDC maître.

shell% kdb5_util create -r ATHENA.MIT.EDU -s

Initializing database '/usr/local/var/krb5kdc/principal' for realm 'ATHENA.MIT.EDU',
master key name 'K/M@ATHENA.MIT.EDU'
You will be prompted for the database Master Password.
It is important that you NOT FORGET this password.
Enter KDC database master key: ‹= Type the master password.
Re-enter KDC database master key to verify: ‹= Type it again.
shell%

   Cela va créer 5 fichiers dans LOCALSTATEDIR/krb5kdc ( ou l'emplacement spécifié dans kdc.conf ):

- 2 fichiers de base de données, principal et principal.ok
- Le fichier de base de données administrative, principal.kadm5
- Le fichier de lock de la base administrative, principal.kadm5.lock
- Le fichier stash, dans cet exemple .k5.ATHENA.MIT.EDU. utiliser l'option -s pour ne pas générer ce fichier.

Ajouter les administrateurs au fichier d'ACL

Ensuite, vous devez créer un fichier d'acl et y placer le principal Kerberos d'au moins un administrateur. Ce fichier est utilisé par kadmind pour contrôler quel principaux peuvent voir et effectuer des modifications privilégiées dans les fichiers de base Kerberos. Le nom du fichier d'acl est déterminé par la variable acl_file dans kdc.conf ( défaut: LOCALSTATEDIR/krb5kdc/kadm5.acl )

Ajouter les administrateurs à la base kerberos

   Vous devez ajouter les principaux administratifs à la base de données Kerberos. Vous devez ajouter au moins un principal pour permettre la communication entre kadmind et kadmin sur le réseaux. Pour cela, utiliser l'utilitaire kadmin.local sur le KDC maître. Il est conçus pour être lancé sur un KDC maître sans utiliser d'authentification Kerberos. Vous devez avoir un accès en lecture/écriture à la base Kerberos.

   Les principaux administratifs que vous créez devraient être ceux ajoutés dans le fichier d'acl.

Dans l'exemple suivant, le principal administratif admin/admin est créé:
shell% kadmin.local

kadmin.local: addprinc admin/admin@ATHENA.MIT.EDU

WARNING: no policy specified for "admin/admin@ATHENA.MIT.EDU";
assigning "default".
Enter password for principal admin/admin@ATHENA.MIT.EDU: ‹= Enter a password.
Re-enter password for principal admin/admin@ATHENA.MIT.EDU: ‹= Type it again.
Principal "admin/admin@ATHENA.MIT.EDU" created.
kadmin.local:

Démarrer le service Kerberos sur le KDC maître

À ce point, vous êtes prêt à démarrer le KDC (krb5kdc) et les services administratifs sur le KDC maître:
shell% krb5kdc
shell% kadmind

Chaque service va se forker en tâche de fond.

Vous pouvez vérifier qu'ils sont lancés correctement en vérifiant les messages de démarrage dans les emplacement le logging spécifiés dans krb5.conf:
shell% tail /var/log/krb5kdc.log
Dec 02 12:35:47 beeblebrox krb5kdc[3187](info): commencing operation
shell% tail /var/log/kadmin.log
Dec 02 12:35:52 beeblebrox kadmind[3189](info): starting

En vérification additionnelle, vérifier si kinit réussit avec les principaux administratifs:
shell% kinit admin/admin@ATHENA.MIT.EDU

Installer les KDC esclave

Maintenant vous être prêt à configurer les KDC esclaves.

Note: en assumant que vous paramètrez le KDC de manière à facilement basculer le maître avec un des esclaves, vous devriez effectuer chaque étape sur de maître sur les esclaves, sauf les ces instructions spécifient le contraire.

Créer les keytabs pour les KDC esclave

   Chaque KDC a besoin d'un clé host dans la base Kerberos. Ces clés sont utilisée pour l'authentification mutuelle lors de la propagation des dump de la base de donnée depuis le maître.

   Sur le KDC maître, se connecter à l'interface administrative et créer le principal de l'hôte pour chaque service host des KDC. Par exemple, si le maître s'appel kerberos.mit.edu, et l'esclave s'appel kerberos-1.mit.edu:

shell% kadmin
kadmin: addprinc -randkey host/kerberos.mit.edu
NOTICE: no policy specified for "host/kerberos.mit.edu@ATHENA.MIT.EDU"; assigning "default"
Principal "host/kerberos.mit.edu@ATHENA.MIT.EDU" created.

kadmin: addprinc -randkey host/kerberos-1.mit.edu
NOTICE: no policy specified for "host/kerberos-1.mit.edu@ATHENA.MIT.EDU"; assigning "default"
Principal "host/kerberos-1.mit.edu@ATHENA.MIT.EDU" created.

   Il n'est pas nécessaire d'avoir le maître dans la base Kerberos, mais peut être nécessaire si vous souhaitez basculer le maître en esclave. Ensuite, extraire chaque clé host pour tous les KDC participants et les stocker dans chaque fichier keytab de l'hôte. Idéalement, vous devriez extraire chaque keytab localement dans son propre KDC. Si cela n'est pas faisable, vous devriez utiliser une session chiffrée pour les envoyer sur le réseau. Pour extraire un keytab sur un serveur esclave:

kadmin: ktadd host/kerberos-1.mit.edu
Entry for principal host/kerberos-1.mit.edu with kvno 2, encryption
    type aes256-cts-hmac-sha1-96 added to keytab FILE:/etc/krb5.keytab.
Entry for principal host/kerberos-1.mit.edu with kvno 2, encryption
    type aes128-cts-hmac-sha1-96 added to keytab FILE:/etc/krb5.keytab.
Entry for principal host/kerberos-1.mit.edu with kvno 2, encryption
    type des3-cbc-sha1 added to keytab FILE:/etc/krb5.keytab.
Entry for principal host/kerberos-1.mit.edu with kvno 2, encryption
    type arcfour-hmac added to keytab FILE:/etc/krb5.keytab.

Configurer les KDC esclave

   La propagation de la base de données copie le contenu de la base du maître, mais ne propage pas les fichiers de configuration, les fichiers stash, ou le fichier d'acl. Les fichiers suivants doivent être copiés à la main pour chaque esclave:

- krb5.conf
- kdc.conf
- kadm5.acl
- master key stash file

   Déplacer les fichiers copiés dans leur répertoires appropriés, exactement comme sur le KDC maître. La base est propagée du maître vers les esclaves via le service kpropd. Vous devez explicitement spécifier les principaux qui sont autorisé à fournir les mises à jours Kerberos sur les esclaves avec une nouvelle base de données. Créer un fichier nommé kpropd.acl dans le répertoire d'état KDC contenant les principaux host pour chaque KDC:

host/kerberos.mit.edu@ATHENA.MIT.EDU
host/kerberos-1.mit.edu@ATHENA.MIT.EDU

   Note: si vous souhaitez que le maître et l'esclave puis être inversés, listez les principaux hôtes depuis tous les KDC participants dans les fichiers kpropd.acl dans tous les KDC. Sinon, vous avez seulement besoin de lister le principal de l'hôte du KDC maître dans kpropd.acl des KDC esclaves.

Ensuite, ajoutez la ligne suivante dans /etc/inetd.conf dans chaque KDC:
krb5_prop 754/tcp # Kerberos slave propagation

   Redémarrez inetd. Alternativement, démarrer kpropd comme service standalone. Cela est nécessaire quand la propagation incrémental est activé.

   Maintenant que le KDC est capable d'accepter la propagation de la base, vous avez besoin de propager la base depuis le maître. Note: Ne pas démarrer le KDC esclave avant d'avoir une copie du maître.

Propager la base à chaque esclave

Premièrement, créer un fichier dump de la base sur le maître:
shell% kdb5_util dump /usr/local/var/krb5kdc/slave_datatrans
Puis, propager manuellement la base à chaque esclave:
shell% kprop -f /usr/local/var/krb5kdc/slave_datatrans kerberos-1.mit.edu
Database propagation to kerberos-1.mit.edu: SUCCEEDED

   Vous aurez besoin d'un script pour dumper et propager la base. voici un exemple de script shell. Rappelez vous que vous avez besoin de remplacer /usr/local/var/krb5kdc avec le nom du répertoire d'état KDC.

#!/bin/sh

kdclist = "kerberos-1.mit.edu kerberos-2.mit.edu"

kdb5_util dump /usr/local/var/krb5kdc/slave_datatrans

for kdc in $kdclist
do
    kprop -f /usr/local/var/krb5kdc/slave_datatrans $kdc
done

Vous avez besoin du définir un cron pour lancer ce script à intervalle régulier. Maintenant que l'esclave a une copie de la base Kerberos, vous pouvez démarrer krb5kdc:
shell% krb5kdc

Erreurs de propagation

kprop: No route to host while connecting to server
Assurez vous que le nom d'hôte de l'esclave est correct et que les firewalls entre le maître et l'esclave autorisent le port 754.
kprop: Connection refused while connecting to server
Si l'esclave tente de lancer kpropd via inetd, assurez vous que inetd est configuré pour accepter les connections krb5_prop. inetd a besoin de relire sa configuration pour qu'un changement soit pris en compte.
kprop: Server rejected authentication (during sendauth exchange) while authenticating to server
assurez vous que:

1. L'heure est synchonisée
2. Le fichier stash du maître a été copié sur l'esclave à l'emplacement attendu
3. L'esclave a un fichier keytab contenant un principal host pour le nom d'hôte de l'esclave.

Ajouter des principaux à la base

Une fois les KDC définis et fonctionnels, vous êtes prêt à utiliser kadmin pour charger les principaux pour vos utilisateurs, hôtes, et autres services dans la base kerberos. Vous pouvez occasionnellement utiliser un des esclaves comme maître. Cela peut se produire si vous mettez à jour le maître, ou si le maître crash.

Basculer de maître et d'esclave

Si le KDC maître fonctionne, effectuez les étapes suivantes sur l'ancien maître:

1. Tuer kadmind
2. Désactiver le job cron qui propage la base
3. Lancer le script de propagation manuellement, pour s'assurer que tous les esclaves ont la dernière copie de la base.

Sur le nouveau maître:

1. Démarrer Kadmind
2. Définir un cron pour propager la base
3. Bascules les CNAME de l'ancien vers le nouveau maître. Si vous ne pouvez pas le faire, vous aurez besoin de changer le fichier krb5.conf sun chaque client dans le domaine kerberos.

01 juillet 2016

keys-ecryptfs

Système de fichier stacké à chiffrement transparent

   ecryptfs est un système de fichier stacké qui chiffre et déchiffre de manière transparente chaque fichier en utilisant une clé de chiffrement de fichier (FEK) générée aléatoirement.

   Chaque FEK est en retour chiffré avec une clé de chiffrement de clé de chiffrement de fichier (FEFEK) soit dans l'espace kernel ou en espace utilisateur avec un service appelé ecryptfsd. Dans le premier cas, l'opération est effectuée directement par le cryptoAPI du kernel en utilisant une clé, la FEFEK, dérivée d'une passphrase de l'utilisateur; dans l'autre cas, la FEK est chifrée par ecryptfsd avec l'aide de librairies externes pour supporter d'autres mécanismes comme les clés publiques, PKCS#11 et TPM.

   La structure de données définie par ecryptfs pour contenir les informations requises pour le déchiffrement FEK est appelé le jeton d'authentification et , actuellement, peut être stocké dans une clé kernel de type 'user', inséré dans la session de l'utilisateur par l'utilitaire userspace mount.ecryptfs fournis avec le paquet ecryptfs-utils

   Le type de clé encrypted a été étendue avec l'introduction du nouveau format ecryptfs pour être utilisé en conjonction avec le système de fichier ecryptfs. Les clé chiffrées au nouveau format stockent un jeton d'authentification dans son payload avec un FEFEK générée aléatoirement par le kernel et protégé par la clé maître.

   Pour éviter les attaques plaintext, le 'datablob' obtenu via les commandes 'keyctl print' ou 'keyctl pipe' ne contiennent pas tout le jeton d'authentification, dont le contenu est connu, mais seulement la FEFEK sous forme chiffrée.

   Le système de fichier ecryptfs peut réellement bénéficier de l'utilisation de clé chiffrées car les clés requises peuvent être générées de manière sécurisée par un administrateur et fournis au boot une fois la clé de confiance fournie pour effectuer le montage dans un environnement contrôlé. Un autre avantage est que la clé n'est pas exposée aux traitements de logiciels malicieux, parce qu'elle est disponible en clair seulement au niveau du kernel.

Utilisation

keyctl add encrypted name "new ecryptfs key-type:master-key-name keylen" ring
keyctl add encrypted name "load hex_blob" ring
keyctl update keyid "update key-type:master-key-name"
name:= '‹ 16 hexadecimal characters ›'
key-type:= 'trusted' | 'user'
keylen:= 64

Exemple d'utilisation de clé chiffrée avec le système de fichier ecryptfs

Créer un clé chiffrée "1000100010001000" de 64bits de long au format ecryptfs et la sauver avec une clé utilisateur précédemment chargée "test":
keyctl add encrypted 1000100010001000 "new ecryptfs user:test 64" @u 19184530
keyctl print 19184530
ecryptfs user:test 64 490045d4bfe48c99f0d465fbbbb79e7500da954178e2de0697
dd85091f5450a0511219e9f7cd70dcd498038181466f78ac8d4c19504fcc72402bfc41c2
f253a41b7507ccaa4b2b03fff19a69d1cc0b16e71746473f023a95488b6edfd86f7fdd40
9d292e4bacded1258880122dd553a661
keyctl pipe 19184530 › ecryptfs.blob
Monter un système de fichier ecryptfs avec la clé chiffrée créée "1000100010001000" dans le répertoire /secret:
mount -i -t ecryptfs -oecryptfs_sig=1000100010001000,ecryptfs_cipher=aes,ecryptfs_key_bytes=32 /secret /secret

30 juin 2014

kinit

Obtenir un TGT initial

OPTIONS

27 juin 2014

kproplog

Affiche le contenu les logs de mise à jours de la base Kerberos

kproplog affiche le contenu des logs de mise à jours du KDC sur la sortie standard. Il peut être utilisé pour garder une trace des mises à jours incrémental de la base principal. Le fichier de log contient les logs maintenus par le processus kadmind sur le serveur maître, et kpropd sur les serveurs esclaves. Quand une mise à jours se produit, elle est loggée dans ce fichier. kproplog nécessite un accès en lecture à ce fichier, il va afficher uniquement les mises à jours pour le KDC sur lequel il est lancé. Sans options, affiche un sommaire des logs. Si invoqué sur le maître, affiche uniquement un sommaire des mises à jours.

OPTIONS

-R Ré-initialise le fichier de log. Force une re-synchronisation complète. Si utilisé sur un esclave, il va tout synchroniser. Sur un maître, tous les esclaves vont demander une synchronisation complète.
-h Affiche un sommaire des logs. Inclus le numéro de version, l'état de la base, le nombre d'updates, le timestamp du premier et dernier update, et le numéro de version de la première et dernière entrée.
-e num Affiche le num dernières entrées dans le log.
-v Affiche les attributs individuels par update. Exemple de sortie générée pour une entrée:

Update Entry
    Update serial # : 4
    Update operation : Add
    Update principal : test@EXAMPLE.COM
    Update size : 424
    Update committed : True
    Update time stamp : Fri Feb 20 23:37:42 2004
    Attributes changed : 6
        Principal
        Key data
        Password last changed
        Modifying principal
        Modification time
        TL data

Variables d'environnement

KRB5_KDC_PROFILE Spécifie l'emplacement de kdc.conf

30 juin 2014

krb5-config

Indique quels flags utiliser pour compiler et lier les programmes avec Kerberos

Krb5-config indique au programmeur d'application quels flags utilisés pour compiler et linker les programmes avec les librairies Kerberos installées.

OPTIONS

--all Affiche la version, vendeur, préfixe, et exec-prefix
--version Affiche le numéro de version de Kerberos
--vendor Affiche le nom du vendeur de l'installation Kerberos
--prefix Affiche le préfixe pour lequel l'installation Kerberos a été construite
--exec-prefix Affiche le préfixe pour les exécutables pour lequel l'installation Kerberos a été construite
--defccname Affiche l'emplacement du cache d'accréditifs par défaut.
--defktname Affiche l'emplacement du keytab par défaut
--defcktname Affiche l'emplacement du keytab client par défaut
--cflags Affiche les flags de compilation utilisés pour construire l'installation Kerberos
--libs [library] Affiche les options du compileur nécessaire pour linkerà la librairie spécifiée. les valeurs permises sont:

krb5 Kerberos 5 applications (default)
gssapi GSSAPI applications with Kerberos 5 bindings
kadm-client Kadmin client
kadm-server Kadmin server
kdb Applications qui accèdent à la base Kerberos

18 juin 2014

krb5.conf

Fichier de configuration Kerberos

Ce fichier contient la configuration Kerberos, incluant l'emplacement des serveurs KDC et admin pour les domaines Kerberos, les valeurs par défaut pour le domaine courant et pour les applications kerberos, et les mappages de nom d'hôte dans les royaumes Kerberos. Normallement, ce fichier est dans /etc mais son emplacement peut être spécifié dans la variable KRB5_CONFIG.

Structure

   Les noms de sections sont entre crochets, chaque section peut contenir 0 ou plusieurs relations, sous la forme:

  foo = bar



ou:
fubar = {
    foo = bar
    baz = quux
}

   Placer un * à la fin d'une ligne indique que c'est la valeur final pour le tag. Cela signifie que ni le reste du fichier de configuration, ni un autre fichier de configuration ne sera vérifié pour une autre valeur pour ce tag.

Par exemple, les lignes suivantes:
foo = bar*
foo = baz
Alors la seconde valeur ne sera jamais lue.

Le fichier krb5.conf peut inclure d'autres fichiers en utilisant une des directives suivantes au début d'une ligne:
include FILENAME
includedir DIRNAME

   FILENAME et DIRNAME doivent être des chemin absolus. Le fichier ou le répertoire nommé doit exister et lisible. Inclure un répertoire inclue tous les fichiers dans le répertoire dont le nom consiste uniquement de caractères alphanumériques, "-" ou "_". Les fichiers de profils sont syntaxiquement indépendants de leurs parent, donc chaque fichier inclus doit commencer avec un en-tête de section. Le fichier krb5.conf peut spécifier que la configuration devrait être obtenue depuis un module chargeable, au lieu du fichier lui-même, en utilisant le directive suivante au début de la ligne avant toute section headers:

  module MODULEPATH:RESIDUAL

  MODULEPATH peut être relatif au chemin de librairies de l'installation de krb5, ou peut être un chemin absolus. RESIDUAL est fournis au module à l'initialisation. Si krb5 utilise une directive module, kdc.conf devrait également l'utiliser.

Sections

krb5.conf peut contenir les sections suivantes:

[libdefaults] Paramètres utilisés par la libraire Kerberos v5
[realms] information et paramètres de contact spécifique au domaine
[domain_realm] Map les noms d'hôte serveur à des domaines Kerberos
[capaths] Chemins d'authentification pour les inter-domaines non-hiérarchiques
[appdefaults] Paramètres utilisés par certaines applications Kerberos
[plugins] Contrôle l'enregistrement des plugins

Additionnellement, krb5.conf peut inclure une des relations décrites dans kdc.conf, mais n'est pas une pratique recommandée.

[libdefaults]

allow_weak_crypto à false (défaut), les type de chiffrements faibles seront exclus des listes default_tgs_enctypes, default_tkt_enctypes, et permitted_enctypes.
ap_req_checksum_type Un entier qui spécifie le type de checksum AP-REQ à utiliser dans l'authentifiant. Doit être non définis pour le checksun approprié pour la clé de chiffrement soit utilisé.
canonicalize A true (défaut: false), la requête du ticket initial va demander la canonicalisation du nom du principal, et que répondre avec des principaux du client différent du principal demandé sera accepté.
ccache_type Détermine le format du cache d'accéditifs créés par kinit ou autre. défaut: 4, qui représente le format le plus courant.
clockskew Définis la quantité maximum permise de décalage d'horloge en seconde que la librairie va tolérer. Défaut: 300.
default_ccache_name Cette relation spécifie le nom du cache d'accréditifs par défaut. Défaut: DEFCCNAME.
default_client_keytab_name Cette relation spécifie le nom du keytab par défaut pour obtenir les accréditifs du client. Défaut: DEFCKTNAME.
default_keytab_name Cette relation spécifie le nom du keytab par défaut à utiliser par les serveurs d'application tels que sshd. Défaut: DEFKTNAME.
default_realm Identifie le domaine Kerberos par défaut pour le client. Si non définis, un domaine doit être spécifié avec tout principar Kerberos en invoquant un programme tel que kinit
default_tgs_enctypes Identifie la liste supportée de type de chiffrement de clé de session que le client devrait demander dans un TGS-REQ, par ordre de préférence. Défaut: aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 des3-cbc-sha1 arcfour-hmac-md5 camellia256-cts-cmac camellia128-cts-cmac des-cbc-crc des-cbc-md5 des-cbc-md4
default_tkt_enctypes Identifie la liste supportée de type de chiffrement de clé de session que le client devrait demander dans un AS-REQ, par ordre de préférence. Défaut: aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 des3-cbc-sha1 arcfour-hmac-md5 camellia256-cts-cmac camellia128-cts-cmac des-cbc-crc des-cbc-md5 des-cbc-md4
dns_canonicalize_hostname Indique si la recherche de noms sera utilisée pour canoniser les noms d'hôte à utiliser dans les nom principal de service. Définis ce flag à false pour améliorer la sécurité en réduisant le dépendance à DNS. Défaut: true.
dns_lookup_kdc Indique si les enregistrements DNS SRV dervaient pour localiser le KDC et d'autre serveurs pour un domaine, s'il ne sont pas listés par krb5.conf. (noter que l'entrée admin_server doit être dans krb5.conf pour pouvoir contacter kadmin, parce que l'implémentation DNS pour kadmin est incomplète).
extra_addresses Permet à un ordinateur d'utiliser plusieurs adresses locales, pour permettre à Kerberos de travailler dans un réseau qui utilise le NAT. Les adresses devraient être listée séparées par une virgule. n'a pas d'effet si noaddresses est à true.
forwardable À true, les tickets initiaux ne seront pas forwardable par défaut, si permis par le KDC. Défaut: false
ignore_acceptor_hostname En acceptant les contextes de sécurité GSSAPI ou krb5 pour les principaux de service basés sur l'hôte, ignore tout nom d'hôte passé par l'application appelante, et permet aux clients d'authentifier tout principal de service dans le keytab correspondant au nom du service et au nom du domaine. peut compromettre la sécurité des environnements d'hôte virtuels. Défaut: false.
k5login_authoritative À true, les principaux doivent listés dans le fichier k5login de l'utilisateur pour avoir un accès login, si un fichier .k5login existe. Si ce flag est à false, un principal peut avoir l'accès login au travers d'autre mécanismes même si un k5login existe mais ne liste pas le principal. Défaut: true.
k5login_directory Si définis, la librairie va rechercher le fichier k5login de l'utilisateur local dans le répertoire spécifié, avec un nom de fichier correspondant au nom de l'utilisateur local. Sinon, recherche un fichier nommé .k5login dans le home de l'utilisateur. Pour des raisons de sécurité, .k5login doit être possédé par l'utilisateur local ou par root.
kdc_req_checksum_type Un entier qui spécifie le type de checksum à utilise pour les demande KDC, pour la compatibilité avec de vieille version de KDC.
noaddresses À true, les demandes pour les tickets initiaux ne seront pas faites avec des jeux de restriction d'adresse, permettant aux tickets d'être utilisés via les NAT. Défaut: true.
permitted_enctypes Identifie tous les types de chiffrement permis pour le chiffrement de clé de session. Défaut: aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 des3-cbc-sha1 arcfour-hmac-md5 camellia256-cts-cmac camellia128-cts-cmac des-cbc-crc des-cbc-md5 des-cbc-md4
plugin_base_dir Répertoire de base où se trouvent les plugins krb5. Défaut: krb5/plugins
preferred_preauth_types Permet de définir le type de pré-authentification préféré du client. Défaut: "17, 16, 15, 14" qui force libkrb5 à utiliser PKINIT si supporté.
proxiable À true, les tickets initiaux seront mandatables, si permis par le KDC. Défaut: false
rdns À true, la recherche de noms inversée sera utilisée en plus de la recherche de nom pour canoniser les nom d'hôte à utiliser dans les noms de principaux de service. Si dns_canonicalize_hostname est à false, ce flag n'a pas d'effet. défaut: true.
realm_try_domains Indique si les composants de domaine des hôte devraient être utilisés pour déterminer de domaine Kerberos de l'hôte. La valeur de cette variable est un entier: -1 signifie ne pas rechercher, 0 tente le domaine de l'hôte, 1 tente le domaine immédiatement parent, etc. Le mécanisme usuel de la librairie pour localiser les domaines Kerberos est utilisé pour déterminer si un domaine est un domaine valide, qui peut impliquer de consulter DNS si dns_lookup_kdc est mis. Défaut: -1
renew_lifetime Définis la durée de vie de renouvellement pour les demandes de tickets initiaux. Défaut: 0
safe_checksum_type Un entier qui spécifie le type de checksum à utiliser pour les demandes KRB-SAFE. Défaut: 8 (RSA MD5 DES). Ce champ est ignoré quand ça valeur est incompatible avec le type de clé de session.
ticket_lifetime Durée de vie par défaut pour les demandes de tickets initiaux. Défaut: 1 jour
udp_preference_limit En envoyant un message au KDC, la librairie tente d'utiliser TCP avant UDP si la taille du message est supérieur à udp_preference_limit.
verify_ap_req_nofail À true, une tentative de vérifier des accréditifs initiaux va échouer si la machine client n'a pas de keytab. Défaut: false

[realms]

Chaque tag dans cette section est le nom d'un domaine Kerberos. La valeur du tag est une sous-section qui définis les propriétés de ce domaine. Pour chaque domaine, les tags suivants peuvent être spécifiés dans la sous-section:

admin_server Identifie l'hôte où le serveur d'administration réside. Typiquement, c'est le serveur maître. Ce tag doit avoir une valeur pour permettre la communication avec le serveur kadmind
auth_to_local Permet de définir un règle générale pour le mappage des noms des principaux aux nom des utilisateurs locaux. Est utilisé s'il n'y a pas de mappage explicite pour le nom principal. Les valeurs possible sont:

RULE:exp Le nom local sera formulé depuis exp. Le format est [n:string](regexp)s/pattern/replacement/g. L'entier n indique combien de composants le principal cible devrait avoir. Si cela matche, alors un chaîne sera formée depuis string, en substituant le domaine du principal pour $0 et le n-ième composant du principal pour $n ( exemple, si le principal était johndoe/admin alors [2:$2$1foo] va résulter dans la chaîne adminjohndoefoo). Si la chaîne matche regexp, alors la substitution de commande s//[g] ne va jamais parcourir la chaîne. le g optionnel matche toutes les occurences.
DEFAULT Le nom du principal sera utilisé tel que le nom d'utilisateur. Si le principal a plus d'un composant ou n'est pas le domaine par défaut, cette règle n'est pas applicable et la conversion va échouer.

Par exemple:
[realms]
    ATHENA.MIT.EDU = {
        auth_to_local = RULE:[2:$1](johndoe)s/^.*$/guest/
        auth_to_local = RULE:[2:$1;$2](^.*;admin$)s/;admin$//
        auth_to_local = RULE:[2:$2](^.*;root)s/^.*$/root/
        auto_to_local = DEFAULT
    }

va résulter en tout principal sans root ou admin comme second composant à traduire avec la règle par défaut. Un principal avec un second composant admin va devenir son premier composant. root sera utilisé comme nom local pour tout principal avec un second composant root. L'exception à ces règles sont tout principal johndoe/* qui sera toujours le nom local guest.

auth_to_local_names Cette sous-section vous permet de définir explicitement des mappages de noms de principaux à des noms locaux. Le tag est le nom mappé, et la valeur est l'utilisateur local
default_domain Ce tag spécifie le domaine utilisé pour étendre les noms d'hôte en traduisant les principaux Kerberos v4 en principaux v5.
kdc Le nom ou l'adresse d'un hôte hébergeant un KDC pour ce domaine. Un numéro de port optionnel peut être inclus. Si le nom ou l'adresse contient des ":", utiliser des crochets pour distinguer le ":" de l'adresse du numéro de port. Pour que la machine puisse communiquer avec le KDC, ce tag doit être donné, ou il doit y avoir des enregistrements DNS SRV.
kpasswd_server Pointe vers le serveur où tous les changements de mot de passe sont effectués. S'il n'y a pas de telles entrées, le port 464 de l'hôte admin_server sera tenté.
master_kdc Identifie le KDC maître. Actuellement, ce tag est utilisé dans un cas: si la tentative d'obtention des accréditifs échoue à cause d'un mot de passe invalide, le client va tenter de contacter le KDC maître, dans le cas où le mot de passe de l'utilisateur vient juste d'être changé.

[domain_realm]

   Cette section fournis une traduction depuis un nom de domaine ou un nom d'hôte en un nom de domaine Kerberos. Le nom du tag peut être un nom d'hôte ou un nom de domaine, où les noms de domaine sont identifiés par un préfixe point (.). La valeur est le nom de domaine Kerberos pour un hôte ou un domaine particulier. Une relation de nom d'hôte fournis implicitement la relation de nom de domaine correspondante, sauf si une relation de nom de domaine explicite est fournie. Le domaine Kerberos peut être identifié soit dans la section realm ou en utilisant les enregistrements DNS SRV. Les noms d'hôte et domaine devraient être en minuscules. Par exemple:

[domain_realm]
    crash.mit.edu = TEST.ATHENA.MIT.EDU
    .dev.mit.edu = TEST.ATHENA.MIT.EDU
    mit.edu = ATHENA.MIT.EDU

   mappe l'hôte crash.mit.edu dans le domaine Kerberos TEST.ATHENA.MIT.EDU. La seconde entrée map tous les hôtes sous le domaine dev.mit.edu dans le domaine Kerberos TEST.ATHENA.MIT.EDU sauf l'hôte dev.mit.edu qui est mappé au domaine ATHENA.MIT.EDU.

   Si aucune traduction ne s'applique au nom d'hôte utilisé pour un principal de service pour une demande de ticket de service, la librairie va tenter d'obtenir un référant au domaine approprié depuis le KDC du domaine du client. Si cela échoue, le domaine de l'hôte est considéré être la portion de domaine du nom d'hôte convertit en majuscules, sauf le paramètre realm_try_domains dans la section libdefaults qui force un domaine parent différent à utiliser.

[capaths]

   Pour pouvoir effectuer une authentification inter-domaine directe ( non hiérarchique ), une configuration est nécessaire pour déterminer les chemins d'authentification entre les domaines.

   Un client va utiliser cette section pour trouver le chemin d'authentification entre son domaines et le domaine du serveur. Le serveur va utiliser cette section pour vérifier le chemin d'authentification utilisé par le client, en vérifiant le champ transited.

   Il y a un tag pour chaque domaine client participant, et chaque tag a des sous-tags pour chaque domaine serveur. La valeur des sous-tags est un domaine intermédiaire qui peuvent participer dans l'authentification inter-domaine. Les sous-tags peuvent être répétés s'il y a plus d'un domaine intermédiaire. Une valeur "." signifie que le 2 domaines partagent les clés directement, et aucun intermédiaire ne devrait être autorisé à participer.

   Seul ces entrées qui sont nécessaire dans le client ou le serveur doivent être présent. Un client a besoin d'un tag pour son domaine local avec des sous-tags pour tous les domaines des serveurs auquel il aura besoin de s'authentifier. Un sereur a besoin d'un tag pour chaque domaine des clients qu'il désert, avec un sous-tag pour chaque domaine serveur.

   Par exemple, ANL.GOV, PNL.GOV et NERSC.GOV veulent utiliser le domaine ES.NET comme domaine intermédiaire. ANL a un sous-domaine TEST.ANL.GOV qui va s'authentifier avec NERSC.GOV mais pas PNL.GOV. La section capaths pour les systèmes ANL.GOV ressembleraient à:

[capaths]
    ANL.GOV = {
        TEST.ANL.GOV = .
        PNL.GOV = ES.NET
        NERSC.GOV = ES.NET
        ES.NET = .
    }
    TEST.ANL.GOV = {
        ANL.GOV = .
    }
    PNL.GOV = {
        ANL.GOV = ES.NET
    }
    NERSC.GOV = {
        ANL.GOV = ES.NET
    }
    ES.NET = {
        ANL.GOV = .
    }

La section capaths du fichier de configuration utilisé dans les systèmes NERSC.GOV ressembleraient à:
    [capaths]
        NERSC.GOV = {
            ANL.GOV = ES.NET
            TEST.ANL.GOV = ES.NET
            TEST.ANL.GOV = ANL.GOV
            PNL.GOV = ES.NET
            ES.NET = .
        }
        ANL.GOV = {
            NERSC.GOV = ES.NET
        }
        PNL.GOV = {
            NERSC.GOV = ES.NET
        }
        ES.NET = {
            NERSC.GOV = .
        }
        TEST.ANL.GOV = {
            NERSC.GOV = ANL.GOV
            NERSC.GOV = ES.NET
        }

   Quand un sous-tag est utilisé plus d'une fois dans un tag, les clients utilisent l'ordre des valeurs pour déterminer le chemin. L'ordre des valeurs n'est pas important pour les serveurs.

[appdefault]

   Chaque tag dans cette section nomme une application Kerberos v5 ou un option qui est utilisé par certaines applications Kerberos v5. La valeur du tag définis le fonctionnement par défaut pour cette application.

par exemple:
[appdefaults]
    telnet = {
        ATHENA.MIT.EDU = {
            option1 = false
        }
    }
    telnet = {
        option1 = true
        option2 = true
    }
    ATHENA.MIT.EDU = {
        option2 = false
    }
    option2 = true

   Les 4 manières présentées de spécifier la valeur d'une option sont affichés dans l'ordre de précédence descendante. Dans cet exemple, si telnet fonctionne dans le domaine EXAMPLE.COM, il devrait, par défaut, avoir option1 et option2 à true. Cependant, un programme telnet dans le domaine ATHENA.MIT.EDU devrait avoir l'option1 à false et option2 à true. Tout autre programme dans ATHENA.MIT.EDU devrait avoir l'option2 à false par défaut. Tout programme fonctionnant dans d'autre domaine devraient avoir option2 à true.

   La liste d'options spécifiable pour chaque application peut être trouvée dans les man des applications.

[plugins]

   Les tags dans cette section peuvent être utilisées pour enregistrer les modules dynamique et pour activer/désactiver les modules. Tous les interface activable n'utilisent pas cette section. Celles qui l'utilise sont documentées ici. Chaque interface pluggable correspond à une sous-section. Toutes les sous-sections supportent les même tags:
   [SECTION]
   [SECTION] name="-" table="paragraphes" imbrication="0"
   Ce tag peut avoir plusieurs valeurs. S'il y a des valeur pour ce tag, alors les modules nommés seront désactivés pour l'interface pluggable.
   Ce tag peut avoir plusieurs valeurs. S'il y a des valeur pour ce tag, alors les modules nommés seront activés pour l'interface pluggable.
   Ce tag peut avoir plusieurs valeurs. Chaque valeur est une chaîne sous la forme modulename:pathname. chaque module est enregistré comme module dynamique pour l'interface pluggable. Si pathname n'est pas un chemin absolus, il est considéré relatif à plugin_base_dir.

   Pour les interfaces pluggable où l'ordre des modules est importante, les modules enregistrés avec un tag module viennent en premier, dans l'ordre qu'il sont enregistrés. Si enable_only est utilisé, alors l'ordre de ces tags remplace l'ordre des modules normal.

  Les sections suivantes sont actuellement supportées dans la section plugins.

interface ccselect

La sous-section ccselect contrôle les modules pour la sélection du cache d'accréditifs dans une collection de cache. En plus des modules dynamique enregistrés, les modules embarqués suivant existent:

k5identity Utilise un fichier .k5identity dans le home de l'utilisateur pour sélectionner un principal
realm Utilise le domaine de service pour deviner un cache approprié depuis la collection.

interface pwqual

Cette sous-section contrôle les modules pour l'interface de qualité de mot de passe, qui est utilisé pour rejeter les mots de passe faibles lors des changements de mot de passe. Les modules embarqués suivant existent pour cette interface:

dict Vérifie avec un fichier dictionnaire du domaine
empty Rejète les mots de passe vide
hesiod Vérifie avec les informations utilisateurs stockés dans Hesiod ( seulement si Kerberos est construit avec le support de Hesiod )
princ Vérifie avec les composant du nom du principal

interface kadm5_hook

Fournis des plugins avec des informations sur la création de principaux, la modification, changement de mot de passe et suppression. Cette interface peut être utilisée pour écrire un plugin pour synchroniser Kerberos MIT avec celui de Microsoft.

interface clpreauth et kdcpreauth

Ces interfaces permettent aux modules de fournir des mécanisme de pré-authentification au client et au KDC. Les modules intégrés suivant existent pour ces interfaces:

pkinit Implémente le mécanisme de pré-authentification pkinit
encrypted_challenge Implémente FAST
encrypted_timestamp Implément le mécanisme de timestamp chiffré

interface hostrealm

Cette section contrôle les modules pour l'interface host-to-realm, qui affecte le mappage locale des noms d'hôte et le choix du domaine par défaut. Les module intégré suivant existent pour cette interface:

profile Consulte la section [domain_realm] du profile pour les mappages host-to-realm autoritatifs, et la variable default_realm pour le domaine par défaut.
dns Recherche les enregistrements DNS pour les mappages et le domaine par défaut. n'opère que si dns_lookup_realm est à true.
domain Applique de l'heuristique pour les mappages host-to-realm. Implémente la variable realm_try_domains, et utilise le domaine parent en majuscule du nom d'hôte si cela ne produit pas de résultat.

interface localauth

Contrôle les modules pour l'interface d'autorisation local, qui affecte la relation entre les principaux Kerberos et les comptes système locaux. Les modules intégrés suivant existent pour cette interface:

default Implémente le type DEFAULT pour les valeurs auth_to_local
rule Implémente le type RULE pour les valeur auth_to_local
names Recherche un mappage auth_to_local_names pour le nom du principal
k5login Autorise un principal à un compte local en accord avec le .k5login du compte
an2ln Autorise un principal à un compte local si le nom du principal se mappe au nom local

Options PKINIT

   Les options suivante sont spécifique à PKINIT. Ces valeur peuvent être spécifiées dans [libdefaults] comme valeurs globales par défaut, ou dans une sous-section spécifique au domaine, ou peuvent être spécifiés comme valeurs spécifique au domaine dans la section [realms]. Les valeurs spécifique au domaine écrase, n'ajoutent pas à une spécification libdefaults par défaut. L'ordre de recherche est:

1. sous-section spécifique au domaine de [libdefaults]
[libdefaults]
    EXAMPLE.COM = {
        pkinit_anchors = FILE:/usr/local/example.com.crt
    }

2. Valeurs spécifique au domaine dans [realms]
[realms]
    OTHERREALM.ORG = {
        pkinit_anchors = FILE:/usr/local/otherrealm.org.crt
    }

3. Valeur générique dans [libdefaults]
[libdefaults]
    pkinit_anchors = DIR:/usr/local/generic_trusted_cas/

Spécifier les informations d'identité PKINIT

FILE:filename[,keyfilename] Cette option est dépendante du contexte.

Dans pkinit_identity ou pkinit_identities, filename spécifie le nom d'un fichier PEM contenat le certificat de l'utilisateur. Si Keyfilename n'est pas spécifié, la clé privée de l'utilisateur est attendue dans filename.

Dans pkinit_anchors ou pkinit_pool, filename est assumé être le nom d'un fichier ca-bundle style OpenSSL.

DIR:dirname Cette option est dépendante du contexte.

Dans pkinit_identity ou pkinit_identities, dirname spécifie un répertoire avec des fichiers .crt et .key.

Dans pkinit_anchors ou pkinit_pool, dirname est assumé être un répertoire CA hashé style OpenSSL où chaque certificat CA est stocké dans un fichier nommé hash-of-ca-cert.#

PKCS12:filename filename est le nom d'un pkcs#12, contenant le certificat de l'utilisateur en la clé privée.
PKCS11:[module_name=]modname[:slotid=slot-id][:token=token-label][:certid=cert-id][:certlabel=cert-label] Tous les mots clé sont optionnels. modname spécifie l'emplacement de la librairie PKCS#11. Si une valeur est rencontrée sans mot clé, il est assumé être le modname. Si aucun nom de module n'est spécifié, le défaut est opensc-pkcs11.so. slotid= et/ou token= peuvent être spécifiés pour forcer l'utilisation d'un lecteur de carte ou un token spécifique. certid= et/ou certlabel peuvent être utilisés pour forcer la sélection d'un certificat particulier sur un périphérique.
ENV:envvar envvar spécifie le nom d'une variable d'environnement qui a été définie à une valeur se conformant à une des valeur précédente. Par exemple, ENV:X509_PROXY où la variable d'environnement X509_PROXY a été définie à FILE:/tmp/my_proxy.pem

options krb5.conf pour PKINIT

pkinit_anchors Spécifie l'emplacement des certificats de confiance racine que le client utilise pour signer les certificats KDC. Peut être spécifié plusieurs fois.
pkinit_cert_match Spécifie les règles de correspondance que le certificat client doit matcher avant d'être utilisé pour l'authentification PKINIT. Peut être spécifié plusieurs fois. Tous les certificats sont vérifiés avec chaque règle jusqu'à ce qu'un certificat matche. La comparaison de chaîne Issuer et Subject sont des représentations chaîne rfc2253 des valeurs Issuer DN et Subject DN du certificat. La syntaxe de la règle est [relation-operator]component-rule ... où:

relations-operator peut être soit && signifiant toutes les composantes des règles doivent matcher, ou || signifiant que seul un composant de règle doit matcher. Défaut: &&
component-rule Peut être un des suivant. Noter qu'il n'y a pas de ponctuation ou d'espace blanc entre les composantes de règle:

‹SUBJECT› regular-expression
‹ISSUER› regular-expression
‹SAN› regular-expression
‹EKU› extended-key-usage-list
‹KU› key-usage-list

extended-key-usage-list est une liste de valeurs Extended Key Usage. Toutes les valeurs dans la liste doivent être présents dans le certificat. Les valeurs sont:

pkinit
msScLogin
clientAuth
emailProtection

key-usage-list est une liste de valeurs requises Key Usages. Toutes les valeurs dans la liste doivent être présentes dans le certificat. Les valeurs sont:

digitalSignature
keyEncipherment

exemple:
pkinit_cert_match = ||‹SUBJECT›.*DoE.*‹SAN›.*@EXAMPLE.COM
pkinit_cert_match = &&‹EKU›msScLogin,clientAuth‹ISSUER›.*DoE.*
pkinit_cert_match = ‹EKU›msScLogin,clientAuth‹KU›digitalSignature

pkinit_eku_checking spécifie quelle valeur d'Extended Key Usage le certificat KDC présenté au client doit contenir. (Noter que si le certification du KDC a le pkinit SubjectAlternativeName encodé comme nom Kerberos TGS, la vérification EKU n'est pas nécessaire vu que la CA fournie a certifié cela comme certificat KDC). Les valeurs reconnues sont:

kpKDC C'est la valeur par défaut et spécifie que le KDC doit avoir le id-pkinit-KDKdc EKU comme définis dans la rfc4556.
kpServerAuth Un certificat KDC avec le id-kp-serverAuth EKU tel qu'utilisé par Microsoft sera accepté
none Le certificat du KDC ne sera pas vérifié pour savoir s'il a un EKU acceptable.

pkinit_dh_min_bits Taille de la clé Diffie-Hellman que le client va tenter d'utiliser. les valeur acceptable sont 1024, 2048 (défaut), et 4096.
pkinit_identities Spécifie les emplacements à utiliser pour trouver les information d'identité X.509 du client. Peut être spécifié plusieurs fois. Ces valeur ne sont pas utilisées si l'utilisateur spécifie X509_user_identity sur la ligne de commande.
pkinit_kdc_hostname La présence de cette option indique que le client est prêt à accepter un certificat KDC avec un dNSName SAN au lieu de nécessiter de id-pkinit-san comme définis dans la rfc4556. peut être spécifié plusieurs fois.
pkinit_longhorn À true, on parle au KDC Longhorn
pkinit_pool Spécifie l'emplacement des certificats intermédiaires qui peuvent être utilisés par le client pour compléter la validation de la chaîne. Peut être spécifié plusieurs fois.
pkinit_require_crl_checking Vérifie les informations de révocation.
pkinit_revoke Spécifie l'emplacement de la CRL à utiliser pour vérifier les informations de révocations.
pkinit_win2k Spécifie si le domaine cible est supporte l'ancienne version, pré-rfc, de Kerberos
pkinit_win2k_require_binding À true, le KDC cible attendu est patché pour retourner une réponse avec un checksum. Défaut: false

Expansion de paramètres

De nombreuses variables, telles que default_keytab_name, permettent d'étendre les paramètres:

%{TEMP} Répertoire temporaire
%{uid} User ID réel ou Windows SID
%{euid} User ID effectif ou Windows SID
%{USERID} Idem à %{uid}
%{null} Chaîne vide
%{LIBDIR} Répertoire d'installation des librairies
%{BINDIR} Répertoire d'installation des binaires
%{SBINDIR} Répertoire d'installation des binaires administratifs
%{username} nom de l'utilisateur unix ou user ID effectif
%{APPDATA} (Windows) Roaming application data for current user
%{COMMON_APPDATA} (Windows) Application data for all users
%{LOCAL_APPDATA} (Windows) Local application data for current user
%{SYSTEM} (Windows) Windows system folder
%{WINDOWS} (Windows) Windows folder
%{USERCONFIG} (Windows) Per-user MIT krb5 config file directory
%{COMMONCONFIG} (Windows) Common MIT krb5 config file directory

Exemple de fichier krb5.conf

[libdefaults]
    default_realm = ATHENA.MIT.EDU
    default_tkt_enctypes = des3-hmac-sha1 des-cbc-crc
    default_tgs_enctypes = des3-hmac-sha1 des-cbc-crc
    dns_lookup_kdc = true
    dns_lookup_realm = false

[realms]
    ATHENA.MIT.EDU = {
        kdc = kerberos.mit.edu
        kdc = kerberos-1.mit.edu
        kdc = kerberos-2.mit.edu:750
        admin_server = kerberos.mit.edu
        master_kdc = kerberos.mit.edu
        default_domain = mit.edu
    }
    EXAMPLE.COM = {
        kdc = kerberos.example.com
        kdc = kerberos-1.example.com
        admin_server = kerberos.example.com
    }

[domain_realm]
    .mit.edu = ATHENA.MIT.EDU
    mit.edu = ATHENA.MIT.EDU

[capaths]
    ATHENA.MIT.EDU = {
         EXAMPLE.COM = .
    }
    EXAMPLE.COM = {
         ATHENA.MIT.EDU = .
    }

26 juin 2014

krb5kdc

Service d'authentification Kerberos et centre de distribution des clés

OPTIONS

-r realm Spécifie le domaine Kerberos
-d dbname Spécifie le nom sous lequel la base principale peut être trouvée. Ne s'applique pas aux base LDAP
-k keytype Spécifie le type de clé de la clé maître.
-M mkeyname Spécifie le nom du principal pour la clé maître dans la base.
-m Spécifie que le mot de passe maître de la base devrait être lu depuis le clavier au lieu d'un fichier sur disque.
-n Spécifie que le KDC ne se place pas en tâche de fond.
-P pid_file PID du service
-p portnum Numéros de port UDP d'écoute. Liste séparé par "," Défaut 88,750
-w numworkers Fork le nombre de processus spécifié pour écouter et traiter en parallèle. Le processus parent agit comme superviseur et relai les signaux SIGHUP.

Note: Sur les OS qui supportent pktinfo, utiliser les sous-processus empêche de KDC d'écouter les paquets UDP sur les interfaces créés après que le KDC ait démarré.

-x nconns=number_of_connections Spécifie le nombre de connexion à maintenir par serveur LDAP
-x host=ldapuri Spécifie le serveur LDAP à contacter
-x binddn=binddn Spécifie le DN de l'objet à utiliser par le serveur d'administration
-x bindpwd=bind_password Mot de passe du binddn
-x debug=level Définis le niveau de verbosité de la librairie cliente OpenLDAP
-T offset Spécifie un offset de temps, en secondes, pendant lequel le KDC va opérer.

Exemples

Le KDC peut désservir jusqu'à 32 domaines. Les domaines sont listés sur la ligne de commande, les options par domaine peuvent être spécifiés avant chaque domaine:

krb5kdc -p 2001 -r REALM1 -p 2002 -r REALM2 -r REALM3

Variables d'environnement

KRB5_CONFIG Spécifie l'emplacement de krb5.conf
KRB5_KDC_PROFILE Spécifie l'emplacement de kdc.conf

30 juin 2014

ksu

Version kerberisé de su

ksu est une version Kerberisé du programme su qui a 2 objectifs: sécuriser les changements d'ID d'utilisateur réel et effctifs, et de pouvoir créer de nouveaux contextes de sécurité.

Authentification

ksu opère en 2 phases: l'authentification et l'autorisation. Résoudre le nom du principal de la cible est la première étape de l'authentification. L'utilisateur peut soit spécifier sont nom de principal avec -n, ou un nom de principal par défaut sera assigné en utilisant l'heuristique. Le nom de l'utilisateur cible doit être le premier argument du ksu; si non spécifié, root est le défaut. Si . est spécifié, l'utilisateur cible sera l'utilisateur source, Si l'utilisateur source est root ou l'utilisateur cible est l'utilisateur source, aucune authentification est aucune autorisation ne sera effectuée. Sinon, ksu recherche un ticket Kerberos approprié dans le cache de la source.

Ce ticket peut être soit pour un serveur final, ou un TGT pour le domaine du principal cible. Si le ticket pour le serveur final est déjà dans le cache, il est déchiffré et vérifié. S'il n'est pas dans le cache mais que le TGT l'est, le TGT est utilisé pour obtenir le ticket. Si aucun de cet tickets n'est présent, et ksu est compilé avec GET_TGT_VIA_PASSWD, l'utilisateur devra entrer son mot de passe qui sera ensuite utilisé pour obtenir un TGT. Si l'utilisateur est loggé à distance et n'a pas de canal sécure, le mot de passe peut être exposé. Si ni le ticket ni GET_TGT_VIA_PASSWD ne sont présent, l'authentification échoue.

Autorisation

Cette section décris l'autorisation de l'utilisateur source quand ksu est appelé sans l'option -e.Une fois l'authentification réussie, ksu vérifie que le principal cible est autorisé pou accéder au compte cible. Dans le home de l'utilisateur cible, ksu tente d'accéder à .k5login et .k5users Pour vérifier les autorisations.

Si le nom du principal cible est trouvé dans le .k5login, l'utilisateur source, est autorisé à accéder au compte cible. Sinon, ksu recherche le fichier .k5users. Si le nom de principal cible est trouvé sans commandes ou suivi uniquement par *, l'utilisateur source est autorisé. Si les 2 fichiers ne sont trouvés mais qu'aucune entrée appropriée pour le principal cible n'existe, l'accès est refusé. Si les 2 fichiers n'existent pas le principal aura accès au compte en accord avec la règle de mappage aname-›lname. Sinon l'autorisation échoue.

Exécution du shell cible

Une fois l'autorisation réussie, ksu se comporte comme su. L'environnement n'est pas modifié sauf USER, HOME, et SHELL. Si l'utilisateur cible n'est pas root, USER est l'utilisateur cible. Sinon USER reste inchangé. La variable d'environnement KRB5CCNAME est définie au nom du cache de la cible. L'ID utilisateur réel et effectif sont changés à l'utilisateur cible. Une fois le shell terminé, ksu supprime le cache cible, sauf si -k.

Créer un nouveau contexte de sécurité

ksu peut être utilisé pour créer un nouveau contexte de sécurité pour le programme cible ( soit le shell, soit la commande spécifiée avec -e). Le programme cible hérite d'un jeu d'accréditifs de l'utilisateur source. Par défaut, ce jeu inclue tous les accréditifs dans le cache source, plus tout type d'accréditifs obtenus durant l'authentification. L'utilisateur source est capable de limiter les accréditifs dans le jeu avec les options -z ou -Z. -z restreins la copie des tickets du cache source dans le cache cible aux seuls tickets où le client == le nom principal cible. -Z fournis à l'utilisateur cible un cache neuf, sans accréditifs. Noter que pour des raisons de sécurité, quand l'utilisateur source est root et l'utilisateur cible non-root, -z est le mode par défaut.

Note: durant l'authentification, seul les tickets qui pourraient être obtenus sans fournir de mot de passe sont cachés dans le cache source.

OPTIONS

-n target_principal_name Spécifie un nom de principal cible. non spécifié, un nom de principal par défaut est assigné via les cas suivant:

Cas 1: l'utilisateur source est non-root Si l'utilisateur cible est l'utilisateur source, le nom de principal par défaut est définis au principal par défaut du cache source. Si le cache n'existe pas, le nom de principal par défaut est target_user@local_realm. Si les utilisateurs source et cible sont différent et que .k5users et .k5login n'existent pas, le nom de principal est target_user_login_name@local_realm. Sinon, en commençant avec le premier principal listé ci-dessous, ksu vérifie si le principal est autorisé à accéder au compte cible et s'il y a un ticket pour ce principal dans le cache source.

a. Principal par défaut du cache source
b. target_user@local_realm
c. source_user@local_realm

Cas 2: l'utilisateur source est root Si l'utilisateur cible est non-root, le nom de principal par défaut est target_user@local_realm. Sinon, si le cache source existe, le nom est un principal par défaut du cache source. Si le cache source n'existe pas, le nom est root\@local_realm.

-c source_cache_name Spécifie le nom du cache source. Non spécifié, utilise KRB5CCNAME, ou définis à krb5cc_‹target uid›.(gen_sym()).
-k Ne supprime pas le cache cible à la sortie du shell ou de la commande.
-d mode debug
-z Restreins la copie de tickets du cache source dans le cache cible aux seuls tickets où client==le nom du principal cible.
-Z Ne copie aucun tickets du cache source dans le cache cible.
-q mode silencieux
-l lifetime (chaîne time_duration) Spécifie la durée de vie pour les tickets demandés. défaut 12 heures.
-r time (chaîne time_duration) spécifie l'option renewable à demander pour les tickets.
-p Spécifie que l'option proxiable devrait être demandé pour le ticket
-f Spécifie que l'option forwardable devrait être demandé pour le ticket
-e command [args ...] Exécute la commande spécifiée au lieu d'exécuter le shell cible.

Le fichier .k5users a le format suivant: Une seul entrée par ligne qui peut être suivie par une liste de commandes que le principal est autorisé à exécuter. Un nom de principal suivi par un * signifie que l'utilisateur est autorisé à exécuter une commande. Ainsi, l'exemple suivant:

jqpublic@USC.EDU ls mail /local/kerberos/klist
jqpublic/secure@USC.EDU *
jqpublic/admin@USC.EDU

La première ligne autorise à exécuter ls, mail et klist. La deuxième ligne autorise à exécuter toute commande, et la troisième autorise uniquement à exécuter le shell cible, tout comme la deuxième ligne, mais pas la première.

-a args Spécifie les arguments à passer au shell cible. cette option peut être utilisé pour simuler l'option -e avec: -a -c[command [arguments]].

Instructions d'installation

ksu peut être compilé avec les flags suivant:

GET_TGT_VIA_PASSWD Si aucun ticket approprié n'est trouvé dans le cache source, demande à l'utilisateur son mot de passe.
PRINC_LOOK_AHEAD Durant la résolution du nom de principal par défaut, permet à ksu de trouver les noms des principaux dans le fichier .k5users.
CMD_PATH Spécifie une liste de répertoires contenant les programmes que les utilisateur sont autorisés à exécuter (via le fichier .k5users)
HAVE_GETUSERSHELL Si l'utilisateur source est non-root, ksu insiste pour que le shell de l'utilisateur invoqué soit un shell légal.

ksu devrait être possédé par root et avoir le set user bit mis.

30 juin 2014

kswitch

Spécifier le cache primaire dans une collection

OPTIONS

-c cachename Spécifie le cache d'accréditifs à rendre primaire
-p principal Recherche un cache contenant des accréditifs pour le principal, dans la collection.

Variable d'environnement

KRB5CCNAME peut contenir un nom de cache d'autorisations Kerberos5

fichiers

DEFCCNAME Emplacement par défaut pour le cache d'accréditifs Kerberos 5

27 juin 2014

ktutil

Utilitaire de gestion de fichiers keytab

Commandes

list Affiche la keylist courante. Alias: l
read_kt keytab Lit le keytab Kerberos v5 dans la keylist courante. Alias: rkt
read_st srvtab Lis le srvtab Kerberos v4 dans la keylist courante. Alias: rst
write_kt keytab Écrit la keylist courant dans le keytab. Alias: wkt
write_st srvtab Écrit la keylist courant dans le srvtab. Alias: wst
clear_list Efface le keylist courante. Alias: clear
delete_entry supprime l'entrée dans le numéro de slot de la keylist courante. Alias: delent
add_entry {-key|-password} -p principal -k kvno -e enctype Ajoute un principal dans la keylist en utilisant une clé ou un mot de passe. Alias: addent
list_requests Affiche une liste des commande disponibles. Alias: lr,?
quit quitte. Alias: exit,q

Exemples

ktutil: add_entry -password -p alice@BLEEP.COM -k 1 -e
aes128-cts-hmac-sha1-96
Password for alice@BLEEP.COM:
ktutil: add_entry -password -p alice@BLEEP.COM -k 1 -e
aes256-cts-hmac-sha1-96
Password for alice@BLEEP.COM:
ktutil: write_kt keytab
ktutil:

30 juin 2014

kvno

Acquière un ticket de service pour les principaux spécifiés et affiche les numéros de version de clé pour chaque.

OPTIONS

-c ccache Spécifie le nom du cache d'accréditifs à utiliser
-e etype Spécifie le enctype à demander pour la clé de session de tous les services nommés.
-q Mode silencieux en cas de réussite.
-P Spécifie que les arguments service1 service2 ... sont interprétés comme noms d'hôte, et les principaux de service sont à construire depuis ces nom et le nom de service sname. Les noms d'hôte de service seront canonisés en accord avec les règles pour construire les principaux de service.
-U for_user Spécifie que S4U2Self est utilisé pour obtenir un ticket pour for_user. Si la délégation de contraintes n'est pas requise, le nom de service doit matcher le cache d'accréditifs du principal du client.

Variable d'environnement

KRB5CCNAME peut contenir un nom de cache d'autorisations Kerberos5

fichiers

DEFCCNAME Emplacement par défaut pour le cache d'accréditifs Kerberos 5

28 mars 2016

kxc

Client d'échange de clé

kxc est le client pour kxd. Il prend une clé et un certificat client, le certificat du serveur et une URL (ex: kxd://server/host1/key1), et affiche sur stdout la clé retournée. Il y a un script pour ouvrir des périphérique cryptsetup automatiquement: kxc-cryptsetup.

OPTIONS

--client_key=‹file› Fichier contenant la clé privée du client
--client_cert=‹file› Certificat du client
--server_cert=‹file› Certificats du serveur

28 mars 2016

kxc-cryptsetup

wrapper cryptsetup pour kxc

kxc-cryptsetup est un wrapper pour invoquer kxc tout en prenant les options des fichiers dans /etc/kxc/. Il peut être utilisé comme script de clé cryptsetup, pour automatiquement obtenir les clé pour ouvrir des périphériques kxc.

28 mars 2016

kxd

Service d'échange de clé

kxd est un service d'échange de clé, qui dessert des clé sur https. Il peut être utilisé pour obtenir des clé à distance au lieu d'utiliser un stockage local. Son utilisation principale est d'obtenir des clé pour ouvrir des périphériques dm-crypt automatiquement, sans avoir à stocker les clé sur la machine locale. Sa configuration est stockée dans /etc/kxd/data, dans lequel il y a un répertoire pas clé (ex: /etc/kxd, data, host1/key1/), chacun contenant les fichiers suivants:

key Contient la clé à donner au client
allowed_clients Contient un ou plusieurs certificats PEM clients autorisés à demander la clé
allowed_hosts Contient un ou plusieurs noms d'hôte (un par ligne)
email_to Un ou plusieurs email de destination pour les notifications (un par ligne)

OPTIONS

--key=‹file› clé privée à utiliser. Défaut: /etc/kxd/key.pem
--cert=‹file› Certificat à utiliser. Défaut: /etc/kxd/cert.pem
--data_dir=‹directory› Répertoire des données. Défaut: /etc/kxd/data
email_from=‹email-address› Adresse email de l'émetteur pour l'envoie des emails
--ip_addr=‹ip-address› Adresse IP d'écoute. Défaut: 0.0.0.0
--logfile=‹file› Fichier de log. '-' pour stdout. Défaut: utilise syslog
--port=‹port› Port d'écoute. Défaut: 19840
--smtp_addr=‹host:port› Addresse du serveur smtp

22 mars 2016

luksformat

Créé et format un périphérique LUKS

luksformat est un wrapper autour de cryptsetup et mkfs qui fournis une interface simple pour créer un périphérique chiffré qui suis le standard LUKS et pour placer un système de fichier dans le périphérique chiffré. Le système de fichier par défaut est vfat vu qu'il est plus commun sur les périphérique amovibles.

syntaxe:
luksformat [-t fstype] device [mkfs_options]

22 mars 2016

module-signing

Signature des modules kernel

Présentation

La facilité de signature de module kernel signe cryptographiquement les modules durant l'installation et vérifie la signature au chargement des modules. Cela augmente la sécurité de kernel en interdisant le chargement des modules non-signés ou les modules signés avec une clé invalide. La signature de module augmente la sécurité en rendant le chargement de code malicieux plus dur dans le kernel. La vérification de la signature est fait par le kernel donc il n'est pas nécessaire d'avoir de clé de confiance dans l'espace utilisateur.

Cette facilité utilise les certificats X.509 pour encoder les clé publiques. Les signature ne sont pas encodées par un type standard. La facilité supporte actuellement seulement RSA. Les algorithmes de hashage qui peuvent être utilisée sont SHA-1, SHA-224, SHA-256, SHA-384, et SHA-512.

Configuration

La facilité de signature de module est activée par la section "Enable Loadable Module Support" de la configuration du kernel et en activant CONFIG_MODULE_SIG. Il y a quelques options disponibles:

Require modules to be validly signed CONFIG_MODULE_SIG_FORCE - spécifie le comportement du kernel lorsque la signature d'un module ne peut pas être vérifiée. off, autorise les module non-signés ou non valides, restrictive impose une signature valide.
Automatically sign all modules CONFIG_MODULE_SIG_ALL - Signe les modules automatiquement durant la phase modules_install. À off, les modules doivent être signés manuellement avec scripts/sign-file
Which hash algorithm should modules be signed with? Présente un choix d'algorithmes de hashage pour signer les modules
File name or PKCS#11 URI of module signing key CONFIG_MODULE_SIG_KEY - Définir cette option à une valeur différente que le défaut "certs/signing_key.pem" désactive l'autogénération des clés de signatures. Cette chaîne devrait identifier un fichier contenant une clé privée et son certificat correspondant au format PEM, ou - sur les système où OpenSSL ENGINE pkcs11 est fonctionnel
Additional X.509 keys for default system keyring CONFIG_SYSTEM_TRUSTED_KEYS - Définis un fichier PEM contenant des certificats additionnels qui seront inclus dans le système par défaut.

Générer les clés

Une paire de clé cryptographique est requise pour générer et vérifier les signatures. Une clé privée est utilisée pour générer une signature et la clé publique correspondante est utilisée pour la vérifier. La clé privée est seulement nécessaire durant le build, et peut être supprimée ensuite. La clé publique est embarquée dans le kernel.

Dans des conditions normales, CONFIG_MODULE_SIG_KEY est inchangé de son défaut, le build génère automatiquement une nouvelle clé en utilisant openssl s'il n'existe pas de fichier certs/signing_key.pem. certs/x509.genkey est également généré et contient les paramètres openssl.

Par défaut la section req_distinguished_name contient:
[ req_distinguished_name ]
#O = Unspecified company
CN = Build time autogenerated kernel key
#emailAddress = unspecified.user@unspecified.company

La taille de clé est également définie avec:
[ req ]
default_bits = 4096

Il est également possible de générer manuellement les fichiers avec le fichier x509.genkey:
openssl req -new -nodes -utf8 -sha256 -days 36500 -batch -x509 -config x509.genkey -outform PEM -out kernel_key.pem -keyout kernel_key.pem

Clés publiques dans le kernel

   Le kernel contient un jeu de clé publiques qui peuvent être vues par root (cat /proc/keys).

   Au delà la clé publique générée spécifiquement pour la signature de module, des certificats additionnels peuvent être fournis au format PEM référencés par l'option kernel CONFIG_SYSTEM_TRUSTED_KEYS.

   De plus, le code peut prendre des clés publiques depuis un stockage hardware et les ajouter (ex: depuis une base de clé UEFI)

Finalement, il est possible d'ajouter des clé publiques en faisant:
keyctl padd asymmetric "" [.system_keyring-ID] ‹[key-file]›

   Noter cependant que le kernel ne permet que d'ajouter des clés dans .system_keyring s'ils sont signés par une clé déjà présente dans le .system_keyring au moment où elle est ajoutée.

Signer des modules manuellement

Pour signer manuellement un module, utiliser le script sign-file. Ce script nécessite 4 arguments: l'algorithme de hashage, le nom de la clé privée ou une URI PKCS#11, la clé publique et le module à signer.

exemple:
scripts/sign-file sha512 kernel-signkey.priv kernel-signkey.x509 module.ko

L'algorithme de hashage utilisé ne doit pas correspondre à celui configuré, mais l'algorithme utilisé doit être compilé dans le kernel ou un module chargeable. Si la clé privée nécessite une passphrase ou PIN, il peut être fournis dans la variable d'environnement $KBUILD_SIGN_PIN

Modules signés et stripping

Un module signé a une signature numérique simplement ajouté à la fin. La chaîne '~ Module signature appended~ .' à la fin diu fichier du module confirme qu'une signature est présente mais ne confirme pas que la signature est valide.

Les modules signés sont embarqué comme signature hors du conteneur ELF. Donc, ils ne peuvent plus être stripped une fois la signature calculée. Noter que tout le module est le payload signé, incluant les informations de debug présents au moment de la signature.

Charger des modules signés

Les modules sont chargés avec insmod, modprobe, init_module() ou finit_module(), exactement comme pour les modules non-signés et aucun traitement n'est fait dans l'espace utilisateur. La vérification de la signature est entièrement faite dans le kernel

Signatures non-valides et modules non-signé

Si CONFIG_MODULE_SIG_FORCE est activé ou enforcemodulesig=1 est fournis au kernel, le kernel va seulement charger les modules signés et valides pour lequel il possède une clé publique. Un module pour lequel le kernel a une clé, mais qui prouve qu'une signature ne correspond pas ne sera pas chargé. Tout module dont la signature n'est pas lisible sera rejeté.

Administrer/protéger la clé privée

Vu que la clé privée est utilisée pour signer les modules, les virus et malware peuvent l'utiliser pour signer des modules et compromettre l'OS. La clé privée doit être soit détruite, soit placée dans une emplacement sûre et non possédé dans le nœud root du kernel.

15 juin 2017

/etc/moduli

moduli Diffie-Hellman

   Le fichier /etc/moduli contient les nombre premier et générateurs pour sshd lors de l'échange de clé Diffie-Hellman.

   Un nouveau moduli peut être généré par ssh-keygen en utilisant un processus à 2 étapes. Un pass initial de génération candidat, utilisant ssh-keygen -G, calcule les nombres qui sont utiles. Puis une passe test, utilisant ssh-keygen -T, fournis au haut niveau d'assurance que les nombres sont premiers et sont sûre pour les opérations DH. Le format moduli est utilisé comme sortie depuis chaque passe.

   Le fichier consiste d'enregistrement, un par modulo, contenant 7 champs:

timestamp La date du traitement du modulus
type Spécifie la structure interne (0=inconnu, non testé, 2=safe prime, 4=Sophie Germain)
tests Indisque le type de tests de primalité (0x00=non testé,0x01=nombre composite, pas premier, 0x02=Sleve of Eratosthenes, 0x04=Probabilistic Miller-Rabin primality tests)
trials Nombre de primalité effectués dans le modulus
size Taille du prime en bits
generator Le générateur recommandé à utiliser avec ce modulus (en hexa)
modulus Le modulus lui-même en hexadécimal

10 mai 2016

openca - ocspd

service OCSP

openca-ocspd est un répondeur OCSP conforme à la rfc2560. Il peut être utilisé pour vérifier le status d'un certificat en utilisant les clients OCSP.

OPTIONS

-d Détache le processus principal du processus appelant
-p n Spécifie le port d'écoute. Défaut: 2560
-b address Spécifie l'adresse IP d'écoute. Défaut:_*
-c file Fichier de configuration. Défaut: /usr/local/etc/ocspd.conf
-md digest Spécifie le hash à utiliser pour générer les réponses. Défaut: sha1
-k passwd Spécifie le mot de passe utilisé pour charger la clé privée
-i passin Source du mot de passe de la clé
-engine id Spécifie un engine
-r chroot_dir chroot l'application dans le répertoire spécifié
-v Affiche des détails sur les opération effectuées

10 mai 2016

openca - ocspd.conf

Fichier de configuration pour openca-ocspd

Le fichier de configuration est divisé en sections, et est conforme à la syntaxe spécifiée dans openssl-config.

Exemple

[ ocspd ]
default_ocspd = OCSPD_default

[ OCSPD_default ]

dir = /usr/local/etc/ocspd
db = $dir/index.txt
md = sha1

ca_certificate = $dir/certs/cacert.pem
ocspd_certificate = $dir/certs/ocspd_cert.pem
ocspd_key = $dir/private/ocspd_key.pem
pidfile = $dir/ocspd.pid

user = ocspd
group = daemon
bind = *
port = 2560
max_childs_num = 5
max_req_size = 8192

request = ocsp_req
response = ocsp_response

dbms = dbms_ldap # Example using the LDAP for CRL retrivial

#dbms = dbms_file # Example using file for CRL

engine = HSM # ENGINE section

####################################################################
[ ocsp_req ]
default_keyfile = key.pem

####################################################################
[ ocsp_response ]
dir = /usr/local/etc/ocspd
ocsp_add_response_certs = $dir/certs/chain_certs.pem
ocsp_add_response_keyid = yes
next_update_days = 0
next_update_mins = 5

####################################################################
[ dbms_ldap ]

# It is possible to use an URI to identify a CRL and/or the CA certificate, the general format is:
# [protocol]://[user[:pwd]@]server[:port]/[path]
#
# where:
# protocol - specifies the protocol to be used, supported are
# file, ldap, http
# user - is the user for auth (meaningful only if ldap or
# http is used)
# pwd - password used for auth (meaningful only if ldap
# or http is used)
# port - port to connect to (meaningful only if ldap or
# http is used)
# path - complete path to the object (meaningful only if
# http is used)
#
# You can have the CRLs/CA certificates on a simple file
# crl_url = file:///usr/local/etc/ocspd/crl.pem
#
# You can retrieve the CRLs/CA certificates from a web server
# crl_urt = http://server/ca/cacert.der
#
# You can store the CRL into an LDAP server, simply
# store it in certificateRevocationList;binary attribute
#
# There are different way, all legal, to specify the CRL
# URL address:
# crl_url = ldap://user:pwd@ldap.server.org:389
# crl_url = ldap://ldap.server.org:389
crl_url = ldap://localhost

# The CRL entry DN is the DN to look for when retrieving the
# date from the LDAP server. Put here the complete DN (usually
# the DN of the CA's certificate).
crl_entry_dn = "email=email@address, cn=Certification Auth, \
o=Organization, c=IT"

####################################################################
[ dbms_file ]

# You can have the CRL on a simple file in PEM format
crl_url = file:///usr/local/etc/ocspd/crl.pem

[ HSM ]
# Hardware accelerators support via the ENGINE interface
engine_id = MyAccelerator
0.engine_pre = login:1:10:11:myPassword
# 0.engine_post = logout:1:10:11

default_ocspd Dans cette section du fichier de configuration sont placés les options utilisées par le répondeur, certains sont disponibles en utilisant les options de la ligne de commande.
db Spécifie la db où tout est concervé. Actuellement, le seul format fichier supporté est celui de openssl.
md Spécifie le hash à utiliser. Défaut: sha1
ca_certificate Chemin vers de certificat de la CA
ocspd_certificate Chemin vers le certificat utilisé par le répondeur
ocspd_key Chemin de la clé privée du certificat utilisé par le répondeur
pidfile fichier du pid du processus
user UID du processus
group GID du processus
bind Adresse d'écoute
port Port d'écoute
threads_num Nombre de threads qui devraient être créés au démarrage. plus le nombre est élevé, plus il peut gérer les fort trafics.
chroot_dir chroot d'application dans le répertoire spécifié
max_req_size Taille maximum de requête reçue. Au delà la requête est détruite. Généralement les requêtes font environ 200/300 octets
request section non utilisé actuellement
response section Ici sont conservés les options pour la construction des réponses
dbms Options pour la crl
ocsp_add_response_certs Chemin d'un fichier contentant les certificats à ajouter à la réponse (généralement toute la chaîne de certification).
ocsp_add_response_keyid Spécifie si l'id de clé est ajouté dans la réponse
next_update_days Nombre de jours jusqu'à la prochaine mise à jours.
next_update_mins idem pour la partie minutes. La réponse est valide pour days+mins
ca_url URI où le certificat de la CA est localisée. (file:// http:// ou ldap://)
crl_url URI où la crl est localisée (file:// http:// ou ldap://)
crl_entry_dn avec ldap, spécifie le dn où rechercher l'attribut certificateRevocationList
engine_id Spécifie l'id de l'engine
engine_pre, engine_post Paramètres d'initialisation du périphérique

13 février 2012

OpenCT

Pilotes pour cartes à puce

Openct implémente des pilotes pour de nombreux lecteurs de carte. Ils sont fournis au format ifdhandler requis pour pcsc-lite. OpenCT a également un mécanisme primitif pour exporter les lecteurs de carte sur des machines distantes via tcp/ip.

Présentation générale

OpenSC

Librairie PKCS#11

OpenSC est une librairie PKCS #11 ainsi qu'une API pour l'utiliser. Sur la carte, OpenSC implémente PKCS #15

13 février 2012

opensc-explorer

Utilitaire intéractif pour accéder aux cartes à puce

OPTIONS

--reader, -r Utilise le numéro de lecteur de carte donné
--card-driver, -c Utilise le pilote de carte donné
--verbose, -v mode verbeux

Commandes

ls Liste tous les fichiers dans le DF courant
cd file-id Changer de DF spécifié par sont file-id
info [file-id] Affiche les attributs d’un fichier spécifié par son file-id
create file-id size Crée un nouveau EF en spécifiant sont file-id et sa taille
delete file-id Supprime le EF ou DF spécifié par son file-id
verify key-typekey-id [key] Présente un PIN ou une clé à la carte. le key-type peut être CHV, KEY ou PRO, le key-id est la clé ou le PIN et les clé est la clé ou le PIN à vérifié en hexa.
change CHVid [old-pin] new-pin Changer un pin
put file-id [input] Copie un fichier local sur la carte
get file-id [output] Copie un EF dans un fichier local
mkdir file-id size Créer un DF
pksign Créer un signature de clé publique. (actuellement non implémenté)
pkdecrypt Décrypte un clé publique. (actuellement non implémenté)
erase Efface la carte
quit Quitter le programme.

13 février 2012

opensc-tool

Utilitaire générique pour cartes à puce

OPTIONS

--atr, -a Affiche l’Answer To Reset de la carte, au format hexa
--serial Afficher le numéro de série de la carte (ICCSN) en hexa
--send-apdu, -s Envoie un APDU arbitraire à la carte au format AA:BB:CC:DD:EE:FF...
--list-files, -f Liste tous les fichiers stockés sur la carte
--list-readers, -l Liste tous les lecteurs configurés
--list-drivers, -D Liste tous les pilotes de carte installés
--list-rdrivers, -R Liste tous les pilotes de lecteur installés
--reader, -r Numéro du lecteur --card-driver, -c
Utilise le lecteur de carte donné --verbose, -v
Mode verbeux

13 février 2012

opensc.conf

Fichier de configuration pour OpenSC

app default {
    debug = 0 ; # niveau de debug
    debug_file = "/var/log/opensc-debug.log" ; # Fichier où ecrire les informations de debug (défaut : stdout)
    error_file = "/var/log/opensc-errors.log" ; # Fichier où ecrire les information d’erreur (défaut : stderr)
    profile_dir = PKGDATADIR ; # Répertoire de profil pour pkcs15-init (défaut : /usr/share/opensc)
    reader_drivers = pcsc, openct, ctapi ; # pilotes à charger au démarrage. ’internal’ va charger tous les pilote liés statiquement (défaut)
}

    {
        reader_driver ctapi { # configuration pour le pilote ctapi
            module /usr/local/towitoko/lib/libtowitoko.so {
                ports = 0 ; # port CT-API 0..3 (COM1..4) 4 (printer) 5 (modem) 6..7 (LPT1..2)
            }
        }

        reader_driver pcsc { # configuration pour le pilote pcsc
            max_send_size = 252 ; # Taille max des données envoyée et reçues. Vérifier avec lsusb -vv pour dwMaxIFSD
            max_recv_size = 252 ;
            connect_exclusive = false ; # connecter le lecteur en mode exclusif (défaut : false)
            connect_reset = true ; # réinitialiser la carte après déconnection (défaut : true)
            transaction_reset = false ; # réinitialise la carte après charque transaction (défaut : false)
            enable_pinpad = false ; # active pinpad si détecté (défaut : false)
        }

        reader_driver openct {
            readers = 5 ; Lecteurs virtuels à allouer (défaut : 5)
        }

        card_drivers = customcos, internal ; # pilotes à charger au démarrage. ’internal’ charge tous les pilotes liés dynamiquement (défaut et doit toujours être la dernière entrée)
        card_driver customcos {
            module = /usr/lib/opensc/drivers/card_customcos.so ; # emplacement du pilote
        }

        force_card_driver = autodetect ; # si spécifié, force OpenSC à utiliser ce pilote.(défaut : autodetect)
        # noms des pilotes internes supportés : etoken, flex, cyberflex, gpk, miocos, mcrd, setcos, starcos, tcos, openpgp, jcop, oberthur, belpic, emv, piv
        card_atr 3b:f0:0d:ca:fe { # nouvelle entrée pour le pilote flex. Format générique : card_atr ‹hex encoded ATR (case-sensitive !)›
            atrmask = "ff:ff:ff:ff:ff" ; # masque AND pour l’ATR de la carte pour la l’identification de la référence ATR.
            driver = "flex" ; # pilote à utiliser
            name = "My CryptoFlex card" ; { nom de la carte
                type = "2002" ; # type de carte (valeur entière)
                flags = "keygen", "rng", "0x80000000" ; # flags au format hexa (ou chaine pour certains : keygen = capacités de génération de clé embarqué, rng = source de nombre aléatoire embarqué) pour personnaliser les capacités de la carte.
                pkcs15emu = "custom" ; # Couche d’amulation PKCS #15, force le pilote d’émulation pour les cartes spécifiques
                force_protocol = "t0" ; # Force le protocole à utiliser (t0, t1 ou raw)
            }
            card_atr 3B:7D:96:00:00:80:31:80:65:B0:83:11:00:AC:83:00:90:00 { # les cartes PIV on besoin d’un entrée comme ceci
                name = "PIV-II" ;
                driver = "piv" ;
            }
            card_atr 3b:6e:00:ff:45:73:74:45:49:44:20:76:65:72:20:31:2e:30 { # les cartes Estonian ID et le pilote Micardo fonctionne ensemble avec T=0. Seul l’ATR ’cold’ devrait être spécifié
                force_protocol = t0 ;
            }
            card_atr 3b:fe:94:00:ff:80:b1:fa:45:1f:03:45:73:74:45:49:44:20:76:65:72:20:31:2e:30:43 {
                force_protocol = t0 ;
            }
            card_atr 3b:fe:94:00:ff:80:b1:fa:45:1f:03:45:73:74:45:49:44:20:76:65:72:20:31:2e:30:43 { # Les cartes D-Trust sont aussi basées sur micardo et T=0
                force_protocol = t0 ;
            }
            card_atr 3b:ff:94:00:ff:80:b1:fe:45:1f:03:00:68:d2:76:00:00:28:ff:05:1e:31:80:00:90:00:23 {
                force_protocol = t0 ;
            }
            card_atr 3b:ff:11:00:ff:80:b1:fe:45:1f:03:00:68:d2:76:00:00:28:ff:05:1e:31:80:00:90:00:a6 {
                force_protocol = t0 ;
            }
            framework pkcs15 { # block spécifique au framework PKCS #15
                use_caching = false ; # spécifie d’utiliser les fichier en cache dans le home de l’utilisateur en apprenant la carte (pkcs15-tool -L) (ne doit pas être utilisé en root) (défaut : false)
                enable_pkcs15_emulation = yes ; # Active l’émulation pkcs15 (défaut : yes)
                try_emulation_first = yes ; # tente d’abord l’émulation pkcs15 avant le traitement normal pkcs15 (défaut : no)
                enable_builtin_emulation = yes ; # Active l’émulation intégrée
                builtin_emulators = esteid, openpgp, tcos, starcert, infocamere, postecert, actalis, atrust-acos, gemsafe, tccardos, PIV-II ; # liste des émulateurs pkcs15 intégrés à tester
                emulate custom { # Paramètre pour un émulateur pkcs15 chargé depuis une librairie externe
                    module = /usr/lib/opensc/drivers/p15emu_custom.so ; # emplacement de la librairie
                }
            }
        }

        app opensc-pkcs11 { # paramètres pour le module PKCS11 OpenSC
        pkcs11 {
            num_slots = 4 ; # Nombre de slot maximum par carte à puce
            hide_empty_tokens = yes ; # Cache les slots vides
            lock_login = true ; # opensc tente de locker la carte une fois authentifiée via C_Login. (défaut : false)
            cache_pins = true # normalement le module pkcs11 ne met pas en cache le pin présenté via C_Login, mais certaines carte ne fonctionne pas correctement avec opensc (défaut : true)
            soft_keygen_allowed = true ; # Force la génération de pair de clé embarqué (défaut : true)
            }
        }

08 mai 2016

OpenSSL - config

Fichers de configuration de la librairie CONF

   La librairie CONF openssl peut être utilisée pour lire les fichiers de configuration. Elle est utilisée pour le fichier de configuration maître openssl.cnf et dans d'autres endroits comme dans les fichiers SPKAC et les fichiers d'extensions de certificat pour l'utilitaire x509. Les application openssl peuvent également utiliser la librairie CONF pour leur propre utilisation.

   Un fichier de configuration est divisé en nombre de sections. Chaque section commence avec une ligne [ section_name ] et se termine quand une nouvelle section commence.

   La première section d'un fichier de configuration est spécial et est réferré à la section par défaut qui est généralement non nommée. Quand un nom est recherché il est d'abord recherché dans une section nommée, puis dans la section par défaut.

   L'environnement est mappé en une section appelée ENV. Chaque section consiste d'un nombre de paire nom=valeur.

   La valeur peut être étendue en utilisant la forme $var ou ${var}, qui substitue la valeur de la variable dans la section courante. Il est également possible de substituer une valeur d'une autre section en utilisant la syntaxe $section::name ou ${section::name}. En utilisant la forme $ENV::name les variables d'environnement peuvent être substituées. Il est également possible d'assigner des valeurs aux variables d'environnement en utilisant le nom ENV::name, cela fonctionne si le programme recherche des variables d'environnement en utilisant la librairie CONF au lieu d'appeler getenv() directement.

Configuration de la librairie openssl

   Les application peuvent configurer automatiquement certains aspects d'openssl en utilisant le fichier de configuration maître, ou optionnellement un fichier de configuration alternatif. L'utilitaire openssl inclus cette fonctionnalité; toute sous-commande utilise le fichier de configuration maître sauf si une option est utilisée dans la sous commande pour utiliser un fichier de configuration alternatif.

   Pour activer la configuration de librairie la section par défaut doit contenir la ligne appropriée qui pointe vers la section de configuration principale. Le nom par défaut est openssl_conf qui est utilisé par l'utilitaire openssl. D'autres applications peuvent utiliser un nom alternatif

La section de configuration devrait consister en un jeu de nom=valeur qui contient des informations spécifique au module. Le nom représente le nom du module de configuration et la valeur est spécifique au module. Par exemple:
openssl_conf = openssl_init

[openssl_init]
oid_section = new_oids
engines = engine_section

[new_oids]
... new oids here ...

[engine_section]
... engine stuff here ...

Module de configuration d'objet ASN1

Ce module a le nom oid_section. La valeur est le nom de la section contenant les paires de valeur d'OID. Bien que certains utilitaires openssl ont leur propre section d'objet ASN1, toutes ne l'ont pas. En utilisant le module de configuration d'objet ASN1 tout l'utilitaire openssl peut voir les nouveaux objets. Par exemple:
[new_oids]
some_new_oid = 1.2.3.4
some_other_oid = 1.2.3.5

Il est également possible de définir la valeur avec un nom long, suivi par une virgule et l'OID:
shortName = some object long name, 1.2.3.4

Module de configuration engine

   Le module de configuration ENGINE a le nom des engines. La valeur pointe vers une section contenant les informations de configuration du moteur.

Chaque section spécifique est utilisée pour définir les algorithmes par défaut, le chargement dynamique, d'initialisation et les contrôles envoyés. par exemple:
[engine_section]
# Configure ENGINE named "foo"
foo = foo_section
# Configure ENGINE named "bar"
bar = bar_section

[foo_section]
... foo ENGINE specific commands ...

[bar_section]
... "bar" ENGINE specific commands ...

La commande engine_id est utilisée pour donner le nom du moteur. par exemple:
[engine_section]
# This would normally handle an ENGINE named "foo"
foo = foo_section

[foo_section]
# Override default name and use "myfoo" instead.
engine_id = myfoo

   La commande dynamic_path charge et ajoute un engine. C'est équivalent au contrôle SO_PATH avec la partie argument suivie par LIST_ADD avec la valeur 2 et LOAD à l'engine dynamic.

   La commande init détermine l'initialisation de l'engine. À 0 l'engine n'est pas initialisé. La commande default_algorithms définis les algorithmes par défaut qu'un engin fournis en utilisant les fonctions ENGINE_set_default_string().

Si le nom match aucune des commande ci-dessus, il sont considérés comme des commandes ctrl qui sont envoyés à l'engine. La valeur de la commande est l'argument de la commande ctrl. Si la v+aleur est une chaîne vide aucune valeur n'est envoyée à la commande. par exemple:
[engine_section]
# Configure ENGINE named "foo"
foo = foo_section

[foo_section]
# Load engine from DSO
dynamic_path = /some/path/fooengine.so
# A foo specific ctrl.
some_ctrl = some_value
# Another ctrl that doesn't take a value.
other_ctrl = EMPTY
# Supply all default algorithms
default_algorithms = ALL

Module de configuration EVP

Ce module a le nom alg_section qui pointe vers une section contenant les commandes algorithme. Actuellement la seule commande algorithme supportée est fips_mode dont la valeur devrait être un booléen. par exemple:
alg_section = evp_settings

[evp_settings]
fips_mode = on

Module de configuration ssl

Ce module a le nom ssl_conf qui pointe vers une section contenant les configurations ssl. Chaque ligne dans la section contient le nom de la configuration et la section. Chaque section consiste de paires commande-valeur pour SSL_CONF. Chaque paire sera passée à SSL_CTX ou la structure SSL en cas d'appel SSL_CTX_config() ou SSL_config() avec le nom de configuration approprié. Noter que tout caractère avant le point initial dans la section est ignoré donc la même commande peut être utilisée plusieurs fois:
ssl_conf = ssl_sect

[ssl_sect]
server = server_section

[server_section]
RSA.Certificate = server-rsa.pem
ECDSA.Certificate = server-ecdsa.pem
Ciphers = ALL:!RC4

Notes

Si un fichier de configuration tente d'étendre une variable qui n'existe pas alors une erreur est flaggée et le fichier n'est pas chargé. Cela peut se produire si une variable d'environnement n'existe pas.

Cela peut fonctionner en incluant une section par défaut pour fournir une valeur par défaut: si la recherche d'environnement échoue, la valeur par défaut sera utilisée. Pour que cela fonctionne correctement la valeur par défaut doit être définie très tôt dans le fichier de configuration.

Si la même variable existe dans la même section, seule la dernière est prise en compte. Sous certaines circonstances comme avec les DN le même champ peut être présent plusieurs fois:
1.OU = "My first OU"
2.OU = "My Second OU"

Exemples

Exemple de fichier de configuratio utilisant des fonctionnalités décrite plus haut:
HOME=/temp
RANDFILE= ${ENV::HOME}/.rnd
configdir=$ENV::HOME/config

[ section_one ]
# We are now in section one.
# Quotes permit leading and trailing whitespace
any = " any variable name "

other = A string that can \
cover several lines \
by including \\ characters

message = Hello World\n

[ section_two ]
greeting = $section_one::message

L'exemple suivant montre come étendre les variables d'environnement. Supposont que l'on veut une variable tmpfile référrant à un fichier temporaire. Le répertoire où il est placé peut être déterminé par la variable d'environnement TEMP ou TMP, mais elle peut ne pas être définie. En incluant les noms des variables d'environnement sans que celle-ci n'existe créé une erreur en chargeant le fichier de configuration. En utilisant la section par défaut pour les 2 valeurs:
# si TMP n'existe pas
TMP=/tmp
# Si TMP existe
TEMP=$ENV::TMP
tmpfile=${ENV::TEMP}/tmp.filename

Exemple pour entrer en mode fips:
openssl_conf = openssl_conf_section

[openssl_conf_section]
alg_section = evp_sect

[evp_sect]
fips_mode = yes

Configuration plus complexe:
openssl_conf = openssl_conf_section

[openssl_conf_section]
alg_section = evp_sect
oid_section = new_oids

[evp_sect]
fips_mode = no

[new_oids]
# New OID, just short name
newoid1 = 1.2.3.4.1
# New OID shortname and long name
newoid2 = New OID 2 long name, 1.2.3.4.2

   Les exemples ci-dessus peuvent être utilisées avec toute application utilisant la librairie si openssl_conf est modifié pour correspondre au nom de l'application.

Par exemple, si le second fichie d'exemple ci-dessus est sauvé dans example.cnf, la ligne de commande:
OPENSSL_CONF=example.cnf openssl asn1parse -genstr OID:1.2.3.4.1
va afficher
0:d=0 hl=2 l= 4 prim: OBJECT :newoid1

BUGS

Il n'y a actuellement aucun moyen d'utiliser des caractères en utilisant la notation octal \nnn. Les chaînes sont toutes terminer par un caractère null, donc les nulls ne peuvent pas faire partie de la valeur. Les fichiers sont chargés en une seule passe. Cela signifie qu'une expansion de variable ne fonctionne que si les variables sont référencées très tôt dans le fichier.

08 mai 2016

OpenSSL - engine

Trouver et charger les engines

La commande engine est utilisée pour voir le status et les capacités des engines spécifiés. Les engines peuvent être spécifiés avant ou après tous les autres flags de la ligne de commande.

OPTIONS

-v -vv -vvv -vvvv -v liste les commandes de contrôle temps-réel, -vv ajoute une description pour chaque commande, -vvv ajoute les flags d'entrée, et -vvvv ajoute les flags d'entrée internes
-c Liste les capacités de chaque engine
-t Teste si chaque engine spécifié est disponible, et affiche la réponse
-tt Affiche une erreur pour un engine non-disponible
-pre command=item -post command Configuration en ligne de commande des engines. -pre est donné à l'engine avec qu'il soit chargé et -post est donné une fois chargé.

Exemple

Pour lister toutes les commandes disponibles d'un engine dynamique
openssl engine -t -tt -vvvv dynamic
Pour lister les capacités de l'engine rsax
openssl engine -c

19 février 2012

OpenSSL - asn1parse

Parser les structures ASN.1, ou extraire les données ASN.1

OPTIONS

-inform DER|PEM Format d’entrée (DER : binaire, PEM : base64)
-in filename Fichier d’entrée
-out filename Fichier de sortie où placer les données DER.
-noout Ne sort pas la version parsée du fichier en entrée
-offset number Commence à parser à l’offset spécifié
-length number Nombre d’octets à parser
-i Indenter la sortie en accord avec le "depth" des structures
-oid filename Un fichier contenant un OID additionnel.
-stdparse offset Parse le contenu des octets de l’objet ASN.1 en commençant à l’offset spécifié. Peut être spécifié plusieurs fois.
-genstr string, -genconf file Génère des données encodée basé sur la chaîne ou le fichier spécifié en utilisant le format ASN1_generate_nconf

SORTIE

La sortie contient des lignes de ce type:
0:d=0 hl=4 l= 681 prim : SEQUENCE
.....
229:d=3 hl=3 l= 141 prim : BIT STRING
373:d=2 hl=3 l= 162 cons : cont [ 3 ]
376:d=3 hl=3 l= 159 cons : SEQUENCE
379:d=4 hl=2 l= 29 cons : SEQUENCE
381:d=5 hl=2 l= 3 prim : OBJECT

Chaque ligne commence avec un offset décimal. d=xx spécifie la profondeur courante. hl=XX donne la longueur d’en-tête du type courant. l=XX donne la longueur du contenu.

Exemples

parser un fichier
openssl asn1parse -in file.pem
parser un fichier DER
openssl asn1parse -inform DER -in file.der
générer un UTF8String simple
openssl asn1parse -genstr ’UTF8:Hello World’
Générer un UTF8String, ne pas parser la sortie
openssl asn1parse -genstr ’UTF8:Hello World’ -noout -out utf8.der
génerer en utilisant un fichier de configuration
openssl asn1parse -genconf asn1.cnf -noout -out asn1.der
exemple de fichier de configuration
asn1=SEQUENCE:seq_sect
[seq_sect]
field1=BOOL:TRUE
field2=EXP:0, UTF8some random string

26 février 2012

OpenSSL - ca

Application CA minimaliste. Peut être utilisé pour signer des requêtes de certificats et générer des CRL. Maintient également une base des certificats délivrés et leur status.

Options CA

-config filename Spécifie le fichier de configuration à utiliser
-name section Spécifie la section du fichier de configuration à utiliser
-in filename Fichier source contenant une requête de certificat à signer
-ss_cert filename un certificat auto-signé à signer par la CA
-spkac filename Un fichier contenant une clé publique signée Netscape, un challenge et des valeurs de champs assitionnels à signer par la CA.
-infiles Si présent doit être la dernière option. Tous les arguments qui suivent sont traités comme des noms de fichier contenant des requêtes.
-out filename Fichier de sortie. (défaut : stdout)
-outdir directory Répertoire où placer les certificats de sortie. Le certificat sera nommé avec un numéro hexa et l’extension pem.
-cert Fichier du certificat CA
-keyfile filename La clé privée à utiliser pour signer la requête
-key password Le mot de passe à utiliser pour chiffrer la clé privée
-selfsign indique que les certificats délivrés doivent être signés avec la clé qui a servit à signer la requête (spécifié avec -keyfile). Les requêtes signées avec un certificat différent sont ignorés. si spkac, ss_cert ou gencrl sont spécifiés, cette option est ignorée.
-passin arg La source du mot de passe.
-verbose mode verbeux
-notext N’affiche pas la forme texte dans le fichier de sortie
-startdate date Permet de définir la date de début au format YYMMDDHHMMSSZ (structure ASN1 UTCTime)
-enddate date Permet de définir la date d’expiration au format YYMMDDHHMMSSZ (structure ASN1 UTCTime)
-days arg Le nombre de jours pendant lesquels certifier ce certificat
-md alg Le message digest à utiliser (md5 sha1 et mdc2)
-policy arg Spécifie la stratégie CA à utiliser. C’est une section dans le fichier de configuration
-msie_hack Permet un fonctionnemnt avec les très vieux contrôle d’enrollement de certificat IE ’certenr3’.
-preserveDN Normalement l’ordre du DN est le même que l’ordre des champs dans la section de stratégie. Avec cette option, l’ordre est le même que dans la requête
-noemailDN Le DN d’un certificat peut contenir le champ email s’il est présent dans le DN de la requête ; cependantil est préférable d’avoir l’email dans l’extnsion altName. Avec cette option, le champs email est supprimé du sujet du certificat et définis dans les extensions si présent.
-batch Dans ce mode tous les certificats sont certifiés automatiquement sans poser de questions.
-extensions section La section du fichier de configuration contenant les extensions à ajouter quand un certificat est délivré. Sans extention, un V1 est créé, si une extension est présente, même vide, un v3 est créé.
-extfile file Un fichier de configuration additionnel contenant les extensions à ajouter.
-engine id Spécifie le type de moteur. peut être définis à default pour tous les algorithmes disponibles
-subj arg Remplace le sujet dans la reque^te. doitêtre au format /type0=value0/type1=value1/type2=...
-utf8 Les valeurs dns les champs sont interprétés comme chaînes UTF-8 (par défaut en ASCII)
-multivalue-rdn l’argument -subj est interprété comme RDN multivalué. ex : /DC=org/DC=OpenSSL/DC=users/UID=123456+CN=John Doe (sans cette option : 123456+CN=John Doe)

Options CRL

-gencrl Génère une CRL basé sur les informations dans le fichier d’index
-crldays num Nombre de jours avant la prochaine CRL. valeur placée dans le champ nextUpdate de la CRL.
-crlhours num Nombre d’heure avant la prochaine CRL.
-revoke filename Un nom de fichier contenant un certificat à révoquer.
-crl_reason reason Raison dela révocation. Peut être (unspecified, keyCompromise, CACompromise, affiliationChanged, superseded, cessationOfOperation, certificateHold ou removeFromCRL). Définis une raison de révocation va créer une CRL v2.
-crl_hold instruction Définis la raison de révocation à certificateHold et l’instruction doit etre un OID (pet être à holdInstructioNone (=obsolete), holdInstructionCallIssuer ou HoldInstructionReject)
-crl_compromise time Définis la raison de révocation keyCompromise et le temps au format YYYYMMDDHHMMSSZ.
-crl_CA_compromise time Idem pour CACompromise
-crlexts section Section dans le fichier de configuration contenant les extensions CRL à inclure. Sans extension, une CRL v1 st générée.

Options du fichier de configuration

La section par défaut doit être nommée dans l’option default_ca de la section ca (ou de la section par défaut).

oid_file Spécifie le fichier contenant des oid additionnels, un par ligne.
oid_section Spécifie la section dans le fichier de configuration contenant les oid additionnels.
new_certs_dir Idem à -outdir
certificate idem à -cert
private_key idem à -keyfile
RANDFILE un fichier utilisé pour lire et écrire des informations de nombre aléatoire.
default_startdate idem à -startdate
default_enddate idem à -enddate
default_crl_hours idem à -crlhours
default_crl_days idem à -crldays
default_md idem à -md
database le fichier de données à utiliser
unique_subject à yes, les certificats doivent avoir un sujet unique
serial Fichier texte contenant le prochain numéro de CRL en hexa à utiliser.
x509_extensions idem à -extensions
crl_extensions idem à -crlexts
preserve idem à -preserveDN
email_in_dn idem à -noemailDN
msie_hack idem à -msie_hack
policy idem à -policy
name_opt, cert_opt Permettent au format utilisé d’afficher les détails du certificat lorsqu’il est demandé à l’utilisateur de confirmer la signature.
copy_extensions Détermine comment les extensions dans la requête sont manipulés. non spécifié ou à none, lesextensions sont ignorés. à copy, les extensions non encore présentes sont copiées dans le certificat. a copyall, toutes les extensions sont copiées en supprimant celles déjà présentes

Exemples

Signer une requête de certificat:
openssl ca -in req.pem -out newcert.pem
signer une requête e certificat, en utilisant les extensions de CA:
openssl ca -in req.pem -extensions v3_ca -out newcert.pem
Générer une CRL:
openssl ca -gencrl -out crl.pem
signer plusieurs requêtes:
openssl ca -infiles req1.pem req2.pem req3.pem
Certifier un SPKAC Netscape:
openssl ca -spkac spkac.txt
exemple de fichier SPKAC (tronquée pour plus de clarté):
SPKAC=MIG0MGAwXDANBgkqhkiG9w0BAQEFAANLADBIAkEAn7PDhCeV/xIxUg8V70YRxK2A5
CN=Steve Test
emailAddress=steve@openssl.org
0.OU=OpenSSL Group
1.OU=Another Group

Exemple de section ca dans la configuration

[ ca ]
default_ca = CA_default # Section ca par défaut

[ CA_default ]
dir = ./demoCA # Répertoire de base
database = $dir/index.txt # fichier d’index
new_certs_dir = $dir/newcerts # Répertoire pour les nouveaux certificats délivrés

certificate = $dir/cacert.pem # Certificat racine
serial = $dir/serial # fichier serial
private_key = $dir/private/cakey.pem# Clé privée de la ca
RANDFILE = $dir/private/.rand # Fichier de nombres aléatoire

default_days = 365 # Durée de validité du certificat
default_crl_days= 30 # Durée de la CRL
default_md = md5 # md à utiliser

policy = policy_any # Stratégie par défaut
email_in_dn = no # Ne pas ajouter le mail dans le DN

name_opt = ca_default # Option d’affichage du nom du sujet
cert_opt = ca_default # Option d’affichage du certificat
copy_extensions = none # Ne pas copier les extensions depuis la requête

[ policy_any ]
countryName = supplied
stateOrProvinceName = optional
organizationName = optional
organizationalUnitName = optional
commonName = supplied
emailAddress = optional

Variables d'environnement

OPENSSL_CONF Réflète l’emplacement du fichier de configuration maître (idem à -config)

27 février 2012

OpenSSL - ciphers

Convertis les listes de chiffrement en liste de préférence ordonnées. Peut être utilisé comme outil de test pour déterminer la liste de chiffrement.

OPTIONS

-v mode verbeux
-V idem à -v mais inclus les codes des suites de chiffrements en hexa.
-ssl3 Uniquement les chiffrements SSL v3
-ssl2 Uniquement les chiffrements SSL v2
-tls1 Uniquement les chiffrements TLS v1
cipherlist Une liste de chiffrement à convertir en une liste de préférence de chiffrement.

Format de liste de chiffrement

Une liste consiste en une ou plusieurs chaîne de chiffrement séparés par des ':'. Une liste peut être une suite de chiffrements simple comme RC4-SHA. Elle peut représenter un certain algorithme. Par exemple SHA1 représente toutes les suites utilisant cet algorithme, et SSLv3 représente tous les algorithmes SSLv3.

Les listes de suite de chiffrement peuvent être combinées en une simple chaîne en utilisant le '+' (est un ET logique), un '!' pour les chiffrements à supprimer de la liste, un '-' pour ceux à supprimer, mais qui peuvent être rajoutés ultérieurement. En plus, la chaine de chiffrement @STRENGTH peut être utilisée pour trier la liste de chiffrement courante dans l'ordre de longueur de clé de chiffrement.

Chaînes de chiffrement

Liste des chaînes de chiffrement permises et leur signification:

DEFAULT Liste de chiffrement par défaut. Déterminé à la compilation. (pour openssl v1.0.0 est normalement à ALL:!aNULL:!eNULL). Doit être la première chaîne de chiffrement spécifiée.
COMPLEMENTOFDEFAULT Les chiffrement inclus dans ALL, mais non actifs par défaut.
ALL Toutes les suites de chiffrement sauf eNULL
COMPLEMENTOFALL Les suites de chiffrement non activés par ALL, actuellement eNULL.
HIGH Suites de chiffrements élevés. Actuellement, signifie toutes les longueurs de clé supérieurs à 128 bits, et certains chiffrements avec clé 128 bits.
MEDIUM Suites de chiffrements moyens. Actuellement, signifie toutes les longueurs de clé à 128 bits.
LOW Suites de chiffrements faibles. Actuellement, signifie toutes les longueurs de clé supérieurs à 56 ou 64 bits mais exclus les suites de chiffrement d’export
EXP, EXPORT Algorithmes de chiffrement d’export, incluant les clés à 56 et 64 bits.
EXPORT40 Algorithmes de chiffrement d’export de 40 bits
EXPORT56 Algorithmes de chiffrement d’export de 56 bits
eNULL, NULL Chiffrement qui n’offrent pas de cryptage.
aNULL Suites de chiffrement n’offrant pas d’authentification. Actuellement, les algorithmes DH anonymes. Vulnérables aux attaques MITM.
kRSA, RSA Suites de chiffrement utilisant les échanges de clé RSA
kEDH Suites de chiffrement utilisant les agréments de clé DH éphémères
kDHr, kDHd Suites de chiffrement utilisant les agréments de clé DH et les certificats DH signés par CA avec des clé RSA et DSS, respectivement.
aRSA Suites de chiffrement utilisant l’authentification RSA.
aDSS, DSS Suites de chiffrement utilisant l’authentification DSS
aDH Suites de chiffrement utilisant effectivement l’authentification DH.
kFZA, aFZA, eFZA, FZA Suites de chiffrement utilisant l’échange de clé, l’authentification et/ou le chiffrement FORTEZZA
TLSv1, SSLv3, SSLv2 Suites de chiffrement utilisant respectivement TLS v1, SSL v3 et SSL v2.
DH Suites de chiffrement utilisant DH, incluant DH anonyme.
ADH Suites de chiffrement utilisant DH anonyme.
AES Suites de chiffrement utilisant AES
CAMELLIA Suites de chiffrement utilisant Camellia
3DES Suites de chiffrement utilisant 3DES
DES Suites de chiffrement utilisant DES
RC4 Suites de chiffrement utilisant RC4
RC2 Suites de chiffrement utilisant RC2
IDEA Suites de chiffrement utilisant IDEA
SEED Suites de chiffrement utilisant SEED
MD5 Suites de chiffrement utilisant MD5
SHA1, SHA Suites de chiffrement utilisant SHA1
aGOST Suites de chiffrement utilisant GOST R 34.10 (soit 2001 soit 94) pour l’authentification
aGOST01 Suites de chiffrement utilisant l’authentification GOST R 34.10-2001
aGOST94 Suites de chiffrement utilisant L’authentification GOST R 34.10-94
kGOST Suites de chiffrement utilisant l’échange de clé VKO 34.10 (RFC 4357)
GOST94 Suites de chiffrement utilisant HMAC basé sur GOST R 34.10-94
GOST89MAC Suites de chiffrement utilisant GOST 28147-89 MAC

Noms des suites de chiffrement

Les listes suivantes donnent les noms des suites de chiffrement SSL ou TLS et leur équivalent OpenSSL.

Suites de chiffrement SSL v3.0

SSL_RSA_WITH_NULL_MD5 NULL-MD5
SSL_RSA_WITH_NULL_SHA NULL-SHA
SSL_RSA_EXPORT_WITH_RC4_40_MD5 EXP-RC4-MD5
SSL_RSA_WITH_RC4_128_MD5 RC4-MD5
SSL_RSA_WITH_RC4_128_SHA RC4-SHA
SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5 EXP-RC2-CBC-MD5
SSL_RSA_WITH_IDEA_CBC_SHA IDEA-CBC-SHA
SSL_RSA_EXPORT_WITH_DES40_CBC_SHA EXP-DES-CBC-SHA
SSL_RSA_WITH_DES_CBC_SHA DES-CBC-SHA
SSL_RSA_WITH_3DES_EDE_CBC_SHA DES-CBC3-SHA

SSL_DH_DSS_EXPORT_WITH_DES40_CBC_SHA Not implemented.
SSL_DH_DSS_WITH_DES_CBC_SHA Not implemented.
SSL_DH_DSS_WITH_3DES_EDE_CBC_SHA Not implemented.
SSL_DH_RSA_EXPORT_WITH_DES40_CBC_SHA Not implemented.
SSL_DH_RSA_WITH_DES_CBC_SHA Not implemented.
SSL_DH_RSA_WITH_3DES_EDE_CBC_SHA Not implemented.
SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA EXP-EDH-DSS-DES-CBC-SHA
SSL_DHE_DSS_WITH_DES_CBC_SHA EDH-DSS-CBC-SHA
SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA EDH-DSS-DES-CBC3-SHA
SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA EXP-EDH-RSA-DES-CBC-SHA
SSL_DHE_RSA_WITH_DES_CBC_SHA EDH-RSA-DES-CBC-SHA
SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA EDH-RSA-DES-CBC3-SHA

SSL_DH_anon_EXPORT_WITH_RC4_40_MD5 EXP-ADH-RC4-MD5
SSL_DH_anon_WITH_RC4_128_MD5 ADH-RC4-MD5
SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA EXP-ADH-DES-CBC-SHA
SSL_DH_anon_WITH_DES_CBC_SHA ADH-DES-CBC-SHA
SSL_DH_anon_WITH_3DES_EDE_CBC_SHA ADH-DES-CBC3-SHA

SSL_FORTEZZA_KEA_WITH_NULL_SHA Not implemented.
SSL_FORTEZZA_KEA_WITH_FORTEZZA_CBC_SHA Not implemented.
SSL_FORTEZZA_KEA_WITH_RC4_128_SHA Not implemented.

Suites de chiffrement TLS v1.0

TLS_RSA_WITH_NULL_MD5 NULL-MD5
TLS_RSA_WITH_NULL_SHA NULL-SHA
TLS_RSA_EXPORT_WITH_RC4_40_MD5 EXP-RC4-MD5
TLS_RSA_WITH_RC4_128_MD5 RC4-MD5
TLS_RSA_WITH_RC4_128_SHA RC4-SHA
TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 EXP-RC2-CBC-MD5
TLS_RSA_WITH_IDEA_CBC_SHA IDEA-CBC-SHA
TLS_RSA_EXPORT_WITH_DES40_CBC_SHA EXP-DES-CBC-SHA
TLS_RSA_WITH_DES_CBC_SHA DES-CBC-SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA DES-CBC3-SHA

TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA Not implemented.
TLS_DH_DSS_WITH_DES_CBC_SHA Not implemented.
TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA Not implemented.
TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA Not implemented.
TLS_DH_RSA_WITH_DES_CBC_SHA Not implemented.
TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA Not implemented.
TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA EXP-EDH-DSS-DES-CBC-SHA
TLS_DHE_DSS_WITH_DES_CBC_SHA EDH-DSS-CBC-SHA
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA EDH-DSS-DES-CBC3-SHA
TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA EXP-EDH-RSA-DES-CBC-SHA
TLS_DHE_RSA_WITH_DES_CBC_SHA EDH-RSA-DES-CBC-SHA
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA EDH-RSA-DES-CBC3-SHA

TLS_DH_anon_EXPORT_WITH_RC4_40_MD5 EXP-ADH-RC4-MD5
TLS_DH_anon_WITH_RC4_128_MD5 ADH-RC4-MD5
TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA EXP-ADH-DES-CBC-SHA
TLS_DH_anon_WITH_DES_CBC_SHA ADH-DES-CBC-SHA
TLS_DH_anon_WITH_3DES_EDE_CBC_SHA ADH-DES-CBC3-SHA

Suites de chiffrement AES de la rfc3268, étendant TLS v1.0

TLS_RSA_WITH_AES_128_CBC_SHA AES128-SHA
TLS_RSA_WITH_AES_256_CBC_SHA AES256-SHA

TLS_DH_DSS_WITH_AES_128_CBC_SHA Not implemented.
TLS_DH_DSS_WITH_AES_256_CBC_SHA Not implemented.
TLS_DH_RSA_WITH_AES_128_CBC_SHA Not implemented.
TLS_DH_RSA_WITH_AES_256_CBC_SHA Not implemented.

TLS_DHE_DSS_WITH_AES_128_CBC_SHA DHE-DSS-AES128-SHA
TLS_DHE_DSS_WITH_AES_256_CBC_SHA DHE-DSS-AES256-SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA DHE-RSA-AES128-SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA DHE-RSA-AES256-SHA

TLS_DH_anon_WITH_AES_128_CBC_SHA ADH-AES128-SHA
TLS_DH_anon_WITH_AES_256_CBC_SHA ADH-AES256-SHA

Suites de chiffrement Camellia de la rfc4132, étendant TLS v1.0

TLS_RSA_WITH_CAMELLIA_128_CBC_SHA CAMELLIA128-SHA
TLS_RSA_WITH_CAMELLIA_256_CBC_SHA CAMELLIA256-SHA

TLS_DH_DSS_WITH_CAMELLIA_128_CBC_SHA Not implemented.
TLS_DH_DSS_WITH_CAMELLIA_256_CBC_SHA Not implemented.
TLS_DH_RSA_WITH_CAMELLIA_128_CBC_SHA Not implemented.
TLS_DH_RSA_WITH_CAMELLIA_256_CBC_SHA Not implemented.

TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA DHE-DSS-CAMELLIA128-SHA
TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA DHE-DSS-CAMELLIA256-SHA
TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA DHE-RSA-CAMELLIA128-SHA
TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA DHE-RSA-CAMELLIA256-SHA

TLS_DH_anon_WITH_CAMELLIA_128_CBC_SHA ADH-CAMELLIA128-SHA
TLS_DH_anon_WITH_CAMELLIA_256_CBC_SHA ADH-CAMELLIA256-SHA

Suites de chiffrement SEED de la rfc4162, étendant TLS v1.0

TLS_RSA_WITH_SEED_CBC_SHA SEED-SHA

TLS_DH_DSS_WITH_SEED_CBC_SHA Not implemented.
TLS_DH_RSA_WITH_SEED_CBC_SHA Not implemented.

TLS_DHE_DSS_WITH_SEED_CBC_SHA DHE-DSS-SEED-SHA
TLS_DHE_RSA_WITH_SEED_CBC_SHA DHE-RSA-SEED-SHA

TLS_DH_anon_WITH_SEED_CBC_SHA ADH-SEED-SHA

Suites de chiffrement GOST du draft-chudov-cryptopro-cptls, étendant TLS v1.0

Note: Ces chiffrements nécessitent un moteur qui inclut les algorithmes cryptographique GOST tel que le moteur ccgost, inclus dans OpenSSL.
TLS_GOSTR341094_WITH_28147_CNT_IMIT GOST94-GOST89-GOST89
TLS_GOSTR341001_WITH_28147_CNT_IMIT GOST2001-GOST89-GOST89
TLS_GOSTR341094_WITH_NULL_GOSTR3411 GOST94-NULL-GOST94
TLS_GOSTR341001_WITH_NULL_GOSTR3411 GOST2001-NULL-GOST94

Exports additionnels 1024 et autres suites de chiffrement

Note: Ces chiffrements peuvent aussi être utilisé dans SSL v3
TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA EXP1024-DES-CBC-SHA
TLS_RSA_EXPORT1024_WITH_RC4_56_SHA EXP1024-RC4-SHA
TLS_DHE_DSS_EXPORT1024_WITH_DES_CBC_SHA EXP1024-DHE-DSS-DES-CBC-SHA
TLS_DHE_DSS_EXPORT1024_WITH_RC4_56_SHA EXP1024-DHE-DSS-RC4-SHA
TLS_DHE_DSS_WITH_RC4_128_SHA DHE-DSS-RC4-SHA

Suites de chiffrement SSL v2.0

SSL_CK_RC4_128_WITH_MD5 RC4-MD5
SSL_CK_RC4_128_EXPORT40_WITH_MD5 EXP-RC4-MD5
SSL_CK_RC2_128_CBC_WITH_MD5 RC2-MD5
SSL_CK_RC2_128_CBC_EXPORT40_WITH_MD5 EXP-RC2-MD5
SSL_CK_IDEA_128_CBC_WITH_MD5 IDEA-CBC-MD5
SSL_CK_DES_64_CBC_WITH_MD5 DES-CBC-MD5
SSL_CK_DES_192_EDE3_CBC_WITH_MD5 DES-CBC3-MD5

Exemples

Lister tous les chiffrements OpenSSL incluant les chiffrements NULL:
openssl ciphers -v ’ALL:eNULL’
Inclure tous les chiffrements excepté NULL et DH anonyme, et trier par force:
openssl ciphers -v ’ALL : !ADH :@STRENGTH’
Inclure seulement les chiffrements 3DES puis placer RSA en dernier:
openssl ciphers -v ’3DES :+RSA’
Inclure tous les chiffrements RC4 mais laisser ceux sans authentification:
openssl ciphers -v ’RC4 : !COMPLEMENTOFDEFAULT’
Inclure tous les chiffrements avec authentification RSA mais laisser les chiffrements sans cryptage:
openssl ciphers -v ’RSA : !COMPLEMENTOFALL’

28 février 2012

OpenSSL - cms

Utilitaire CMS (Cryptographic Message Syntax)

OPTIONS

-encrypt Chiffre un mail avec le certificat donné. Le fichier d’entrée est le message à chiffrer. Le fichier de sortie est le mail chiffré au format MIME. Le type de CMS actuel est EnvelopedData.
-decrypt Déchiffre un mail en utilisant le certificat et la clé privée spécifiée. Le fichier d’entrée est un mail au format MIME. le fichier de sortie est le mail déchiffré.
-sign Signe un mail en utilisant le certificat et la clé privée spécifiée. Le fichier d’entrée est le message à signer, le fichier de sortie est le message signé au format MIME.
-verify Vérifie le mail signé. L’entrée est le mail signé, le fichier de sortie et la sortie est la donnée signée.
-cmsout Prend un message en entrée et écrit une structure CMS encodée PEM
-resign Re-signe un message: prend un message existant et un ou plusieurs nouveaux signataires.
-data_create Créé un type CMS Data
-data_out Type une donnée et sort le contenu
-digest_create Crée un type CMS DigestedData
-digestVerify Vérifie un CMS DigestedData et sort le contenu
-compress Créé un CMS CompressedData. OpenSSL doit être compilé avec zlib pour que cette option fonctionne.
-uncompress Décompresse un CMS CompressedData.
-EncryptedData_encrypt Chiffre le contenu en utilisant une clé symétrique et un algorithme CMS EncryptedData et sort le contenu.
-sign_receipt Génère et sort un reçu signé pour le message spécifié. Le message d’entrée doit contenir une requête de reçu signée.
-verify_receipt receipt Vérifie un reçu signé dans le fichier spécifié. Le message d’entrée doit contenir une requête de reçu.
-in filename Fichier d’entrée
-inform SMIME|PEM|DER Format du fichier d’entrée, à utiliser avec -receipt_verify
-out filename Fichier de sortie
-outform SMIME|PEM|DER Spécifie le format du fichier de sortie (défaut SMIME)
-stream -indef -stream et indef sont équivalent et permettent le streaming I/O pour les opérations d’encodage. Cela permet un traitement en une passe de donnée sans nécessiter de maintenir tout le contenu en mémoire.
-noindef Désactive le streaming I/O.
-content filename spécifie un fichier contenant le contenu détaché. Seulement utile avec -verify et si la structure CMS utilise une signature détachée du contenu.
-text Ajoute des en-têtes text/plain au message fournis.
-noout Ne sort par la structure CMS parsée. Utile avec -print
-print pour -cmsout, affiche tous les champs de la structure CMS.
-CAfile file Un fichier contenant les certificats trustés. Utile avec -verify
-CApath dir Un répertoire contenant les certificats CA. Utile avec -verify
-md digest Algorithme digest à utiliser pour signer ou re-signer.
-[ciphers] L’algorithme de chiffrement à utiliser. Voir enc pour la liste des chiffrements supportés. (Défaut : 3DES)
-nointern En vérifiant un message, les certificats inclus dans le message sont utilisé pour vérifier la signature. Avec cette option, seul les certificats spécifiés avec -certfile sont utilisés.
-no_signer_cert_verify Ne vérifie pas le certificat du message signé.
-nocerts En signant un message, le certificat du signataire est inclus. Cette option l’empêche.
-noattr Normalement quand un message est signé, des attributs sont inclus dont la date de signature et les algorithmes symétriques supportés. Cette option ne les inclus pas.
-nosmimecap Exclus la liste des algorithmes supportés pour les attributs signés. D’autres options telles que la date de signature et le type de contenu sont inclus.
-binary Normalement, le message d’entrée est convertit au format canonique qui utilise CR et LF comme fin de ligne comme requis par la spécification S/MIME. Avec cette option, aucune conversion n’est faite.
-nodetach En signant un message en utilisant une signature opaque la forme est plus résistante aux translations par les relais, mais ne peut pas être lus par les agents qui ne supportent pas S/MIME. Sans cette option, la signature en texte clair est utilisée.
-certfile file Permet de spécifier des certificats additionnels, qui seront inclus dans le message. Ces certificats devraient être au format PEM.
-certsout file Tout certificat contenus dans le message sont écris dans le fichier spécifié
-signer file Un certificat de signature. Peut-être spécifiée plusieurs fois.
-recip file Le certificat pour le déchiffrement d’un message. Ce certificat doit matcher un des destinataires du message.
-keyid Utilise le subject key identifier pour identifier les certificats au lieu du nom et du numéro de série. Le certificat doit inclure une extension subject key identifier.
-receipt_request_all -receipt_request_first Pour que l’option -sign inclue une requête de reçu. Indique que les requêtes devraient être fournies par tous les destinataires ou le premier tiers des destinataires.
-receipt_request_to_emailaddress Ajoute une adresse mail où les reçus signés devraient être envoyés. Doit être fournis si un reçu signé est demandé.
-receipt_request_print Pour -verify, affiche le contenu des demandes de reçus signés.
-secretkey key Spécifie la clé symétrique à utiliser. La clé doit être fournie en hexa.
-secretkeyid id L’identifiant de clé pour la clé symétrique fournies pour le type KEKRecipentInfo.
-econtent_type type Définis le type de contenu encapsulé. Peut-être un OID soit en texte soit sous forme numérique.
-inkey file La clé privée à utiliser pour signer ou déchiffrer.
-passin arg Le mot de passe pour la clé privée.
-rand file(s) Un ou plusieurs fichiers contenant des données aléatoires utilisée pour le générateur de nombre aléatoires, ou un socket EGD.
cert.pem... Un ou plusieurs certificats de destinataire de message à utiliser pour chiffrer un message
-to, -from -subject Les en-têtes du mail.
-purpose, -ignore_critical, -issuer_checks, -crl_check, -crl_check_all, -policy_check, -extended_crl, -x509_strict, -policy -check_ss_sig Diverse options de validation de la chaîne de certificat. Voir verify.

Codes de sortie

0 succès de l’opération
1 Erreur en parsant les options
2 Un des fichiers d’entrée ne peut pas être lu
3 Une erreur s’est produite en créant le fichier CMS ou en lisnt le message MIME
4 Erreur durant la vérification ou le déchiffrement du message
5 Le message a été vérifié correctement mais une erreur s’est produite en écrivant les certificats des signeurs.

Compatibilité avec le format PKCS #7

l’utilitaire smime peut seulement traiter l’ancien format pkcs #7. L’utilitaire cms supporte le format CMS.

L’utilisation de -keyid avec -sign ou -encrypt
L’option -outform PEM
L’option -compress
L’option -secretkey avec -encrypt
-EncryptedData_create et -data_create ne peuvent être traitée par les commandes smime.

Exemples

Créer un message signé en texte clair:
openssl cms -sign -in message.txt -text -out mail.msg -signer mycert.pem
Créer un message signé opaque:
openssl cms -sign -in message.txt -text -out mail.msg -nodetach -signer mycert.pem
Créer un message signé, incluant des certificats additionnels et lire la clé privée depuis un autre fichier:
openssl cms -sign -in in.txt -text -out mail.msg -signer mycert.pem -inkey mykey.pem -certfile mycerts.pem
Créer un message signé avec 2 signataires, utiliser un identifier de clé:
openssl cms -sign -in message.txt -text -out mail.msg -signer mycert.pem -signer othercert.pem -keyid
Envoyer un message signé sous Unix directement à sendmail, incluant les en-têtes:
openssl cms -sign -in in.txt -text -signer mycert.pem -from steve@openssl.org -to someone@somewhere -subject "Signed message" | sendmail someone@somewhere
Vérifier un message et extraire le certificat du signataire en cas de réussite:
openssl cms -verify -in mail.msg -signer user.pem -out signedtext.txt
Envoyer un mail chiffré avec 3DES:
openssl cms -encrypt -in in.txt -from steve@openssl.org -to someone@somewhere -subject "Encrypted message" -des3 user.pem -out mail.msg
Signer et chiffrer un mail:
openssl cms -sign -in ml.txt -signer my.pem -text | openssl cms -encrypt -out mail.msg -from steve@openssl.org -to someone@somewhere -subject "Signed and Encrypted message" -des3 user.pem
Déchiffrer un mail:
openssl cms -decrypt -in mail.msg -recip mycert.pem -inkey key.pem
La sortie de la Netscape est une structure PKCS #7 avec le format de signature détachée. Pour vérifier la signature, mettre la structure codé en base 64 entre:
-----BEGIN PKCS7-----
-----END PKCS7-----
Et utiliser la commande:
openssl cms -verify -inform PEM -in signature.pem -content content.txt
Alternativement vous pouvez décoder la signature et utiliser:
openssl cms -verify -inform DER -in signature.der -content content.txt
Créer et chiffrer un message en utilisant Camellia 128 bits:
openssl cms -encrypt -in plain.txt -camellia128 -out mail.msg cert.pem
Ajouter un signataire à un message existant:
openssl cms -resign -in mail.msg -signer newsign.pem -out mail2.msg

28 février 2012

OpenSSL - crl

Utilitaire de traitement des fichiers CRL

OPTIONS

-infor DER|PEM Format du fichier d’entrée.
-outform DER|PEM Spécifie le format de la sortie
-in filename Spécifier le fichier d’entrée
-out filename Spécifier le fichier de sortie
-text Affiche la CRL au format texte
-noout Ne sort pas la version encodée de la CRL
-hash Sort un hash de nom de l’émetteur. Peut être utilisé pour rechercher les CRL dans un répertoire par émetteur
-issuer Affiche le nom de l’émetteur
-lastupdate affiche le champ lastUpdate
-nextupdate Affiche le champ nextUpdate
-CAfile file Vérifie l signature d’un CRL avec le certificat spécifié
-CApath dir Vérifie la signature d’une CRL en recherchant le certificat dabs DIR. Ce répertoire doit être un répertoire de certificat standard: un hash du nom du sujet est lié à chaque certificat (x509 -hash)

Notes

Le format PEM utilise les en-tête et pieds de page suivante:
-----BEGIN X509 CRL-----
-----END X509 CRL-----

Exemples

Convertir une CRL PEM en DER
openssl crl -in crl.pem -outform DER -out crl.der
Afficher un certificat DER en texte clair
openssl crl -in crl.der -text noout

28 février 2012

-inform DER|PEM Format du fichier d'entrée
-outform DER|PEM Format du fichier de sortie
-in filename Fichier d'entrée
-out filename Fichier de sortie
-dsaparam Si spécifié, les paramètres DSA sont lus ou créé au lieu de paramètres DH; ils sont convertis au format DH. Sinon, les premiers 'fort' seront utilisé pour la génération de paramètres DH.
-check Vérifie si les paramètres sont valides
-2, -5 Générateur à utiliser. Si présent, le fichier d'entrée est ignoré et les paramètres sont générés. Défaut: 2
-rand file(s) Fichiers contenant des données aléatoires utilisée pour le générateur de nombre aléatoire, ou un socket EGD.
numbits Spécifie le nombre de bit à utiliser. Doit être la dernière option. Défaut: 2048
-noout Inhibe la sortie de la version encodée des paramètres
-text Affiche les paramètres DH au format lisible
-C Convertis les paramètres en code C. Les paramètres peuvent ainsi être chargés en appelant get_dhNNNN()
-engine id dhparam va tenter d'obtenir une référence fonctionnelle du moteur spécifié.

Notes

Le programme dhparam combine les fonctionnalités des programmes dh et gendh dans les versions précédentes de OpenSSL. Les programmes dh et gendh sont retenus pour d'autres utilisations dans le future.

Les paramètres DH au format PEM utilisent les en-tête et pied de page suivant:
-----BEGIN DH PARAMETERS-----
-----END DH PARAMETERS-----

Openssl supporte actuellement l'ancien PKCS#3 DH, pas le nouveau X9.42 DH.

01 mars 2012

la forme PEM de la clé privée contient:
-----BEGIN EC PRIVATE KEY-----
-----END EC PRIVATE KEY-----

Exemples

Chiffrer une clé privée avec 3DES:
openssl ec -in key.pem -des3 -out keyout.pem
Convertir une clé privée PEM en DER:
openssl ec -in key.pem -outform DER -out keyout.der
Afficher les composants d'une clé privée sur stdout:
openssl ec -in key.pem -text -noout
Afficher la partie publique d'une clé privée:
openssl ec -in key.pem -pubout -out pubkey.pem
Changer les paramètres d'encodage à explicit:
openssl ec -in key.pem -param_enc explicit -out keyout.pem
Changer la conversion de point à compressed:
openssl ec -in key.pem -conv_form compressed -out keyout.pem

12 mai 2015

OpenSSL - ecparam

Manipulation et génération de paramètre EC

OPTIONS

-inform DER|NET|PEM Format du fichier d’entrée.
-outform DER|NET|PEM Format du fichier de sortie
-in filename Fichier d’entrée
-out filename fichier de sortie où écrire les paramètres
-text Affiche des infos sur les clés privée et publique
-noout n’affiche pas la version encodée des paramètres
-C Convertis les paramètres EC en code C.
-check Valide les paramètres de courbe elliptique
-name arg Utilise les paramètres EC avec le nom court spécifié.
-list_curves Affiche la liste de tous les paramètres EC implémentés.
-conv_form Spécifie comment les points sur la courbe elliptique sont convertis en chaîne d'octets ( compressed, uncompressed ou hybrid ).
-param_enc arg Spécifie comment les paramètres de courbe elliptique sont encodés. named_curve ou explicit
-no_seed Inhibe que le 'seed' pour la génération de paramètre soit inclus dans la structure ECParameters
-genkey Génère une clé privée EC en utilisant les paramètres spécifiés
-rand file Un ou plusieurs fichiers contenant des données aléatoires.
-engine id ecparam va tenter d’obtenir une référence fonctionnelle de ce moteur.

Notes

la forme PEM des paramètres EC utilisent la forme:
-----BEGIN EC PARAMETERS-----
-----END EC PARAMETERS-----

Exemples

Créer des paramètres EC avec le groupe 'prime192v1':
openssl ecparam -out ec_param.pem -name prime192v1
Créer des paramètres EC avec les paramètres explicites:
openssl ecparam -out ec_param.pem -name prime192v1 -param_enc explicit
Valider les paramètres EC donnés:
openssl ecparam -in ec_param.pem -check
Créer des paramètres EC et une clé privée:
openssl ecparam -out ec_key.pem -name prime192v1 -genkey
Changer l'encodage des points à compressed:
openssl ecparam -in ec_in.pem -out ec_out.pem -conv_form compressed
Afficher les paramètres EC:
openssl ecparam -in ec_param.pem -noout -text

06 mars 2012

OpenSSL - enc

Routines de chiffrements symétriques

Permet de chiffrer ou déchiffrer des données en utilisant divers block ou flux de chiffrement en utilisant des clés basé sur mot de passe ou fournis explicitement. L’encodage/décodage en base 64 peut également être effectué en plus du chiffrement/déchiffrement.

OPTIONS

-in filename Fichier d’entrée
-out filename Fichier de sortie
-pass arg Source du mot de passe
-salt Utilise un Salt dans les routines de dérivation de clé pendant le chiffrement (défaut). Généré aléatoirement avec l’option -S
-nosalt N’utilise pas de Salt. Ne doit être utilisé que pour des tests un pour compatibilité avec des anciennes versions d’OpenSSL.
-S salt Le Salt à utiliser au format hexa
-e Chiffre la donnée en entrée (défaut)
-d Déchiffre la donnée en entrée
-a Traite les données en base 64.
-base64 Idem à -a
-A si -a, le traitement base64 se fait sur une ligne
-k password Le mot de passe à dériver de la clé. Pour la compatibilité avec d’anciennes versions d’OpenSSL. Remplacé par -pass
-kfile filename Le mot de passe à dériver de la clé depuis ce fichier. Pour la compatibilité avec d’anciennes versions d’OpenSSL. Remplacé par -pass
-K key La clé à utiliser en hexa. IV doit être spécifié avec -iv. Si la clé et le mot de passe sont spécifiés, IV est généré depuis le mot de passe.
-iv IV L’IV à utiliser en hexa
-p Afficher la clé et l’IV utilisé
-P Idem à -p mais quitte immédiatement
-bufsize number Définis la taille du tampon pour les E/S
-nopad Désactive le padding de block standard
-debug Débug les BIO utilisé pour les E/S
-z Compresse ou décompresse en texte clair en utilisant zlib avant le chiffrement ou après le déchiffrement.
-none Utilise le chiffrement NULL

Notes

Les moteurs qui fournissent de nouveaux algorithmes de chiffrement (tel que ccgost qui fournis l’algorithme gost89) devraient être configurés dans le fichier de configuration. Les moteurs spécifiés sur la ligne de commande peuvent seulement être utilisé avec des implémentations de chiffrement assisté par hardware supportés par OpenSSL core.

Chiffrements supportés

Noter que certains chiffrements peuvent être désactivés à la compilation.
base64 Base 64

bf-cbc Blowfish in CBC mode
bf Alias for bf-cbc
bf-cfb Blowfish in CFB mode
bf-ecb Blowfish in ECB mode
bf-ofb Blowfish in OFB mode

cast-cbc CAST in CBC mode
cast Alias for cast-cbc
cast5-cbc CAST5 in CBC mode
cast5-cfb CAST5 in CFB mode
cast5-ecb CAST5 in ECB mode
cast5-ofb CAST5 in OFB mode

des-cbc DES in CBC mode
des Alias for des-cbc
des-cfb DES in CBC mode
des-ofb DES in OFB mode
des-ecb DES in ECB mode

des-ede-cbc Two key triple DES EDE in CBC mode
des-ede Two key triple DES EDE in ECB mode
des-ede-cfb Two key triple DES EDE in CFB mode
des-ede-ofb Two key triple DES EDE in OFB mode

des-ede3-cbc Three key triple DES EDE in CBC mode
des-ede3 Three key triple DES EDE in ECB mode
des3 Alias for des-ede3-cbc
des-ede3-cfb Three key triple DES EDE CFB mode
des-ede3-ofb Three key triple DES EDE in OFB mode

desx DESX algorithm.

gost89 GOST 28147-89 in CFB mode (provided by ccgost engine)
gost89-cnt `GOST 28147-89 in CNT mode (provided by ccgost engine)

idea-cbc IDEA algorithm in CBC mode
idea same as idea-cbc
idea-cfb IDEA in CFB mode
idea-ecb IDEA in ECB mode
idea-ofb IDEA in OFB mode

rc2-cbc 128 bit RC2 in CBC mode
rc2 Alias for rc2-cbc
rc2-cfb 128 bit RC2 in CFB mode
rc2-ecb 128 bit RC2 in ECB mode
rc2-ofb 128 bit RC2 in OFB mode
rc2-64-cbc 64 bit RC2 in CBC mode
rc2-40-cbc 40 bit RC2 in CBC mode

rc4 128 bit RC4
rc4-64 64 bit RC4
rc4-40 40 bit RC4

rc5-cbc RC5 cipher in CBC mode
rc5 Alias for rc5-cbc
rc5-cfb RC5 cipher in CFB mode
rc5-ecb RC5 cipher in ECB mode
rc5-ofb RC5 cipher in OFB mode

aes-[128|192|256]-cbc 128/192/256 bit AES in CBC mode
aes-[128|192|256] Alias for aes-[128|192|256]-cbc
aes-[128|192|256]-cfb 128/192/256 bit AES in 128 bit CFB mode
aes-[128|192|256]-cfb1 128/192/256 bit AES in 1 bit CFB mode
aes-[128|192|256]-cfb8 128/192/256 bit AES in 8 bit CFB mode
aes-[128|192|256]-ecb 128/192/256 bit AES in ECB mode
aes-[128|192|256]-ofb 128/192/256 bit AES in OFB mode

Exemples

Encoder un fichier binaire en base 64
openssl base64 -in file.bin -out file.b64
Décoder le même fichier
openssl base64 -f -in file.b64 -out file.bin
Chiffrer un fichier avec 3DES en mode CBC
openssl des3 -salt -in file.txt -out file.des3
Déchiffrer un fichier en fournissant le mot de passe
openssl des3 -d -salt -in file.des3 -out file.txt -k mypassword
Chiffrer un fichier puis l’encoder en base 64 avec blowfish en mode CBC
openssl bf -a -salt -in file.txt -out file.bf
Décode un fichier base 64 et le déchiffrer
openssl bf -d -salt -a -in file.bf -out file.txt
Déchiffre des données en utilisant une clé RC4 40 Bits
openssl rc4-40 -in file.rc4 -out file.txt -K 0102030405

06 mars 2012

OpenSSL - ErrStr

Utilitaire pour afficher la description d'un code d'erreur

Exemple

le code d’erreur suivant:
27594:error:2006D080:lib(32):func(109):reason(128):bss_file.c:107:
avec openssl errstr 2006D080 produit:
error:2006D080:BIO routines:BIO_new_file:no such file

07 mars 2012

OpenSSL - gendsa

Génère des clés privées DSA à partir de fichiers de paramètres DSA

OPTIONS

-des|-des3|-idea Algorithme à utiliser pour chiffrer la clé privée.
-rand file(s) Fichiers utilisés pour le génération de nombre aléatoire
-engine id gendsa va tenter d’obtenir un référence fonctionnelle pour le moteur spécifié.

09 mars 2012

OpenSSL - genpkey

Génération de clé privée

OPTIONS

-out filename Nom du fichier de sortie
-outform PEM|DER Format du fichier de sortie
-pass arg Source du mot de passe du fichier de sortie
-cipher Algorithme à utiliser pour chiffrer la clé privée.
-engine id genpkey va tenter d’obtenir une référence fonctionnelle pour le moteur spécifié.
-algorithm alg Algorithme de clé publique à utiliser tel que RSA, DSA ou DH. Doit précéder -pkeyopt
-pkeyopt opt:value Définis une option pour l’algorithme de clé publique.
-genparam Génère un jeu de paramètres au lieu d’une clé privée. Doit précéder -algorithm, -paramfile ou -pkeyopt
-paramfile filename Fichier contenant les paramètres à utiliser pour générer la clé privée. Doit précéder -pkeyopt.
-text Affiche une représentation texte des clés publique et privée et des paramètres.

Options de génération de clé

Les options prises en charge par chaque algorithme et même chaque mise en œuvre d’un algorithme peut varier.

Options de génération de clé RSA

rsa_keygen_bits:numbits Nombre de bits dans la clé générée. (défaut : 1024)
rsa_keygen_pubexp:value Valeur d’exposant publique RSA, en décimal ou hexa (défaut : 65537)

Options de génération de clé DSA

dsa_paramgen_bits:numbits Nombre de bits dans les paramètres générés (défaut 1024)

Options de génération de paramètres DH

dh_paramgen_prime_len:numbits Nombre de bits dans le paramètre p
dh_paramgen_generator:value valeur à utiliser pour le générateur g
dh_rfc5114:num Applique les paramètres RFC5114. num peut être (1 : groupe de 1024 avec sous-groupe 160bits, 2 : groupe de 2048 avec sous-groupe 224bits ,3 : groupe de 2048 avec sous-groupe 256bits).

Options de génération de paramètres EC

ec_paramgen_curve:curve La courbe EC à utiliser

Options de paramètres et de génération de clé GOST2001

paramset:name Spécifie le paramètre GOST R 34.10-2001 en accord avec la RFC 4357. Les paramètres suivants sont supportés

paramset OID Usage
A 1.2.643.2.2.35.1 Signature
B 1.2.643.2.2.35.2 Signature
C 1.2.643.2.2.35.3 Signature
XA 1.2.643.2.2.36.0 Key exchange
XB 1.2.643.2.2.36.1 Key exchange
test 1.2.643.2.2.35.0 Test purposes

Exemples

Générer une clé privée RSA en utilisant les paramètres par défaut:
openssl genpkey -algorithm RSA -out key.pem
Chiffrer une clé privée en utilisant AES128 et la passphrase 'hello':
openssl genpkey -algorithm RSA -out key.pem -aes-128-cbc -pass pass:hello
Générer une clé RSA 2048bits et un exposant publique 3:
openssl genpkey -algorithm RSA -out key.pem -pkeyopt rsa_keygen_bits:2048 -pkeyopt rsa_keygen_pubexp:3
Générer des paramètres DSA 1024bits:
openssl genpkey -genparam -algorithm DSA -out dsap.pem -pkeyopt dsa_paramgen_bits:1024
Générer une clé DSA depuis des paramètres:
openssl genpkey -paramfile dsap.pem -out dsakey.pem
Générer des paramètres DH 1024bits:
openssl genpkey -genparam -algorithm DH -out dhp.pem -pkeyopt dh_paramgen_prime_len:1024
sortir des paramètres DH RFC5114 type 2:
openssl genpkey -genparam -algorithm DH -out dhp.pem -pkeyopt dh_rfc5114:2
Générer une clé DH depuis des paramètres:
openssl genpkey -paramfile dhp.pem -out dhkey.pem

Le format chiffré des fichiers PKCS#8 encodés PEM utilisent les en-tête et fin suivant:
-----BEGIN ENCRYPTED PRIVATE KEY-----
-----END ENCRYPTED PRIVATE KEY-----

La version non-chiffrée:
-----BEGIN PRIVATE KEY-----
-----END PRIVATE KEY-----

   Les clé privées chiffrées en utilisant PKCS#5 v2.0 et un compteur d'itération élevé sont plus sécurisés que ceux chiffrés en utilisant les formats compatible SSLeay traditionnels. Le chiffrement par défaut est seulement de 56bits parce que c'est le chiffrement le plus courant dans les implémentations supportant PKCS#8.

   Certains logiciels peuvent utiliser des algorithmes de chiffrement basé sur mot de passe PKCS#12 avec des clés privées au format PKCS#8: ils sont gérés automatiquement mais il n'y a pas d'option pour les produire.

   Il est possible d'écrire des clé privée encodées DER au format PKCS#8 parce que les détails de chiffrement sont inclus au niveau ASN1 alors que le format traditionnel les inclus au niveau PEM.

Algorithmes PKCS#5 v1.5 et PKCS#12

Divers algorithmes peuvent être utilisés avec l'option -v1, incluant PKCS#5 v1.5 et PKCS#12:

PBE-MD2-DES PBE-MD5-DES Ces algorithmes sont inclus dans la spécification PKCS#5 v1.5. Ils offrent une protection 56-bits vu qu'ils utilisent DES
PBE-SHA1-RC2-64 PBE-MD2-RC2-64 PBE-MD5-RC2-64 PBE-SHA1-DES Ces algorithmes ne sont pas mentionnés dans la spécification PKCS#5 v1.5 mais utilisent le même algorithme de dérivation de clé et sont supportés par certains logiciels. Ils sont mentionnés dans PKCS#5 v2.0. Ils utilisent soit rs2 64bits, ou DES 56bits
PBE-SHA1-RC4-128 PBE-SHA1-RC4-40 PBE-SHA1-3DES PBE-SHA1-2DES PBE-SHA1-RC2-128 PBE-SHA1-RC2-40 Ces algorithems utilisent l'algorithme de chiffrement de mot de passe PKCS#12 et utilisent 3DES ou rc2 128bits.

Exemples

Convertir une forme privée traditionnelle en PKCS#5 v2.0 avec 3DES
openssl pkcs8 -in key.pem -topk8 -v2 des3 -out enckey.pem
Convertir un forme privée traditionnelle en PKCS#5 v2.0 avec AES 256 en mode CBC et hmacWithSHA256 PRF
openssl pkcs8 -in key.pem -topk8 -v2 aes-256-cbc -v2prf hmacWithSHA256 -out enckey.pem
Convertir une clé privée en PKCS#8 utilisant PKCS#5 1.5 (DES)
openssl pkcs8 -in key.pem -topk8 -out enckey.pem
Convertir un clé privée en PKCS#8 en utilisant un algorithme compatible PKCS#5 1.5 (DES)
openssl pkcs8 -in key.pem -topk8 -out enckey.pem -v1 PBE-SHA1-3DES
Lire une clé privée PKCS#8 DER non-chiffré
openssl pkcs8 -inform DER -nocrypt -in key.der -out key.pem
Convertir une clé privée depuis un format PKCS#8 dans un format traditionnel
openssl pkcs8 -in pk8.pem -out key.pem
Convertir une clé privée au format PKCS#8, la chiffrer avec AES-256 et un million d'itération
openssl pkcs8 -in raw.pem -topk8 -v2 aes-256-cbc -iter 1000000 -out pk8.pem

Standards

Le format des clé privée DSA PKCS#8 (et d'autres) ne sont pas bien documentés: c'est caché dans PKCS#11 v2.01, section 11.9. Openssl se conforme à ce standard.

18 mars 2012

OpenSSL - pkey

Outil de traitement de clé privée ou publique

OPTIONS

-inform DER|PEM Format du fichier d’entrée
-outform DER|PEM Spécifie le format de sortie
-in filename Fichier à lire
-out filename Fichier à écrire
-passin arg source du mot de passe du fichier d’entrée
-passout password source du mot de passe du fichier de sortie.
-cipher Chiffre la clé privée avec le chiffrement spécifié
-text Affiche les composant de clé privée ou publique en texte clair en plus de la version encodée.
-text_pub Affiche uniquement la composante clé publique.
-noout Ne sort pas la version encodée de la clé
-pubin Par défaut, la clé privée est lue depuis le fichier d’entrée, cette option lit une clé publique à la place
-pubout Par défaut une clé privée est écrite en sortie. Cette option sort une clé publique.
-engine id pkey va tenter d’obtenir une référence fonctionnelle de ce moteur.

Exemples

Enlever un passphrase d’une clé RSA:
openssl pkey -in key.pem -out keyout.pem
Chiffrer une clé publique avec 3DES:
openssl pkey -in key.pem -des3 -out keyout.pem
Convertir une clé privée PEM en DER:
openssl pkey -in key.pem -outform DER -out keyout.der
Afficher les composants de clé privée:
openssl pkey -in key.pem -text -noout
Afficher les composants publics d’une clé privée:
openssl pkey -in key.pem -text_pub -noout
Sortie la partie publique d’une clé privée:
openssl pkey -in key.pem -pubout -out pubkey.pem

18 mars 2012

OpenSSL - pkeyparam

Outil de traitement de paramètres d'algorithme de clé publique

OPTIONS

-in filename Fichier à lire au format PEM
-out filename Fichier à écrire au format PEM
-text Affiche les paramètres en clair en plus de la version encodée
-noout Ne sort pas la version encodée des paramètres
-engine id pkeyparam va tenter d’obtenir une référence fonctionnelle de ce moteur.

Exemples

Afficher la version des paramètres:
openssl pkeyparam -in param.pem -text

31 mars 2012

OpenSSL - pkeyutl

Utilitaire de manipulation de clé publique

OPTIONS

-in filename Spécifie le nom du fichier d’entrée
-out filename Spécifie le fichier de sortie
-inkey file fichier clé d’entrée, par défaut devrait être une clé privée.
-keyform PEM|DER Format de clé PEM, DER ou ENGINE
-passin arg Source du mot de passe de la clé en entrée
-peerkey file Fichier de clé pair, utilisé par les opérations de dérivation de clé
-peerform PEM|DER Format du fichier de clé pair PEM, DER ou ENGINE
-engine id pkeyutil va tenter d’obtenir une référence fonctionnelle de ce moteur.
-pubin Le fichier d’entrée est une clé publique
-certin L’entrée est un certificat contenant une clé publique
-rev Renverse l’ordre du tampon d’entrée. Utile pour certains libraires comme CryptoAPI qui présente l’entrée au format little endian
-sign Signe les données d’entrée et sort le résultat signé, requière une clé privée.
-verify Vérifie les données en entrée avec le fichier de signature et indique si l’opération à réussie ou non
-verifyrecover Vérifie les données entrée et sort les données récupérées
-encrypt Chiffre les données en entrée en utilisant un clé publique
-decrypt Déchiffre les données en entrée en utilisant une clé privée
-derive Dérive une clé partagée en utilisant une clé paire
-hexdump Dump en hexa les données sorties
-asn1parse asn1parse les données en sortie. Utilisé avec -verifyrecover

Notes

Les opérations et options dépendent de l’algorithme de clé et de son implémentation. Tous les algorithmes supportent l’option digest:alg qui spécifie le digest à utiliser pour les opérations de signature et vérification.

RSA

RSA supporte les opérations de chiffrement, déchiffrement, signature et vérification.

-rsa_padding_mode:mode Définis le padding RSA. (pkcs1, sslv23, none oaep, x931 et pss). oeap supporte uniquement le chiffrement et déchiffrement. pss support uniquement la signature et la vérification. rsa_pss_saltlen:len pour le mode pss, spécifie la longueur du salt. (Valeurs spéciales : -1 - le salt est à la longueur du digest, -2 - valeur maximum permise).

DSA

DSA support les opérations de signature et de vérification uniquement.

DH

DH supporte uniquement les opérations de dérivation

EC

EC supporte les opérations de signature, de vérification et de dérivation. La signature et vérification utilise ECDSA et la dérivation ECDH.

Exemples

Signer des données en utilisant une clé privée:
openssl pkeyutl -sign -in file -inkey key.pem -out sig
Récupérer des données signées:
openssl pkeyutl -verifyrecover -in sig -inkey key.pem
Vérifier la signature:
openssl pkeyutl -verify -in file -sigfile sig -inkey key.pem
Signer les données en utilisant un message digest:
openssl pkeyutl -sign -in file -inkey key.pem -out sig -pkeyopt digest:sha256
Dériver une clé secrète partagée:
openssl pkeyutl -derive -inkey key.pem -peerkey pubkey.pem -out secret

19 février 2012

OpenSSL - présentation

Utilitaire cryptographique

OpenSSL est un utilitaire cryptographique implémentant SSL v2/v3 et TLS v1 et les standards cryptographiques liés. Il permet de:

- Crée des paramètres de clé RSA, DH et DSA
- Créer des certificats X.509, CSR et CRL
- Calculer les digests de messages
- Crypter et décrypter avec chiffrement
- Tests client/serveur SSL/TLS
- Manipuler les mails signé ou chiffré S/MIME

Sommaire des commandes

list-standard-commands Affiche la liste des commandes standards
list-message-digest-commands Affiche la liste des commandes Digest standard
list-cipher-commands Affiche la liste des commandes de chiffrement standard
list-public-key-algorithms Liste les algorithmes de clé publique supportés.
no-‹commande› test si une commande est disponible. (Sort 0 si la commande existe, 1 sinon)

Commandes standards

asn1parse Parse une séquence ASN.1
ca Gestion de CA
ciphers Détermine le Cipher Suite Description
cms Utilitaire CMS
crl Gestion de CRL
crl2pkcs7 Conversion de CRL vers pkcs7
dgst Calcul de Message Digest
dh Gestion des paramètre Diffie Hellman
dhparam Génération et gestion des paramètres Diffie Hellman
dsa Gestion des données DSA
dsaparam Génération des paramètres DSA
ec Traitement de clé EC
ecparam Génération et manipulation de paramètres EC
enc Encodage avec Chiffrement
engine Information et manipulation du moteur
errstr Conversion des numéro d’erreur en message d’erreur
gendh Génération des paramètres Diffie Hellman
gendsa Génération des paramètres DSA
genrsa Génération des paramètres RSA
genpkey Génération des clés privée ou paramètres
nseq Créer ou examiner une séquence de certificat Netscape
ocsp Utilitaire pour le protocole Online Certificate Status
passwd Génération de hash de mot de passe
pkcs12 Gestion des données PKCS #12
pkcs7 Gestion des données PKCS #7
pkey Gestion de clé publique et privée
pkeyparam Gestion des paramètres d’algorithme de clé publique
pkeyutl Utilitaire pour les opérations cryptographique de clé publique
rand Génère des octets pseudo-aléatoire
req Gestion des CSR
rsa Gestion des données RSA
rsautil Utilitaire RSA pour signer, vérifier, chiffrer et déchiffrer
s_client Implémente un client générique SSL/TLS pour établir une connexion transparente à un serveur distant.
s_server Implémente un serveur SSL/TLS qui accepte les connections depuis des clients distant.
s_time Timer de connexion SSL
sess_id Gestion de données de session SSL
smime Traitement des mail S/MIME
speed Mesure de vitesse des algorithmes
spkac Utilitaire de génération et d’affichage SPKAC
ts Outil client/serveur d’autorité TimeStamping
verify Vérification de certificats X.509
version Information de version d’openssl
x509 Gestion des données des certificats x509

Commandes Digest Standards

md2 digest md2
md5 Digest md5
mdc2 digest mdc2
rmd160 digestion RMD-160
sha digest sha
sha1 digest sha-1
sha224 digest sha-224
sha256 digest sha-256
sha384 digest sha-384
sha512 digest sha-512

Commandes d’encodage et de chiffrement

base64 Encodage en base64
bf bf-cbc bf-cfb bf-ecb bf-ofb Chiffrement blowfish
cast cast-cbc Chiffrement CAST
cast5-cbc cast5-cfb cast5-ecb cast5-ofb Chiffrement CAST5
des des-cbc des-cfb des-ecb des-ede des-ebe-cbc des-ebe-cfb des-ebe-ofb des-ofb Chiffrement DES
des3 desx des-ede3 des-ede3-cdc des-ede3-cfb des-ede3-ofb Chiffrement TRIPLE-DES
idea idea-cbc idea-cfb idea-ecb idea-ofb Chiffrement IDEA
rc2 rc2-cbc rc2-ecb rc2-ofb Chiffrement RC2
rc4 Chiffrement rc4
rc5 rc5-cbc rc5-cfb rc5-ecb rc5-ofb Chiffrement rc5

Arguments de pass-phrase

pass:password Le mot de passe actuel est password.
env:var Obtenir le mot de pass depuis la variable d’environnement var
file:pathname La première ligne du fichier est le mot de passe. Si ce même fichier est spécifié à -passin et -passout, la première ligne est pour l’entrée la ligne suivante est pour la sortie
fd:number Lit le mot de passe depuis le descripteur de fichier spécifié
stdin Lit le mot de passe depuis l’entrée standard

31 mars 2012

OpenSSL - rand

Générateur pseudo-aléatoire

OPTIONS

-out file Spécifie le fichier à écrire
-rand file(s) Utilise le(s) fichier(s) pour le moteur de nombre aléatoire.
-base64 Effectue un encodage en base 64 sur la sortie
-hex Affiche la sortie en hexa.

31 mars 2012

OpenSSL - req

Utilitaire pour créer et traiter des requêtes pkcs#10

OPTIONS

-inform PEM|DER Format du fichier d’entrée
-outform PEM|DER Format du fichier de sortie
-in filename Fichier d’entrée
-passin arg source du mot de passe du fichier d’entrée
-out filename Fichier de sortie
-passout arg Source du mot de passe pour le fichier de sortie
-text Affiche la requête en clair
-subject Affiche le sujet de la requête
-pubkey Affiche la clé publique
-noout N’affiche pas la version encodée de la requête
-modulus Affiche le modulo de la clé publique contenue dans la requête
-verify Vérifie la signature de la requête
-new Génère une nouvelle requête de certificat.
-subj arg Remplace le champ sujet dans la requête d’entrée doit être au format /type0=value0/type1=value1/typeN=valueN...
-rand file(s) Fichier(s) contenant les données aléatoire pour le générateur de nombre aléatoire.
-newkey arg Crée une nouvelle requête de certificat et une nouvelle clé privée. arg peut être sous la forme rsa:nbits où nbits est la longueur de la clé RSA. Tous les autres algorithmes supportent la forme alg:file où file est un fichier de paramètre. param:file utilise le fichier de paramètre ou le certificat spécifié par file. L’algorithme est déterminé par les paramètres.
-pkeyopt opt:value Définie une options d’algorithme. (Voir genpkey)
-key filename Spécifie le fichier contenant la clé privée à lire. Accepte le format PKCS#8.
-keyform PEM-DER Le format du fichier de clé privée.
-keyout filename Nom du fichier où écrire la clé privée.
-nodes Si cette option est spécifiée, la clé privée créée n’est pas chiffrée
-[digest] Spécifie le message digest à utiliser pour signer la requête.
-multivalue-rdn Permet d’interpréter -subj au format RDN multi-valué (exemple : /DC=org/DC=OpenSSL/DC=users/UID=123456+CN=John Doe, sinon le format sera : 123456+CN=John Doe)
-x509 Sort un certificat auto-signé au lieu d’une requête de certificat.
-days -n avec -x509, spécifie la durée de validité du certificat (défaut : 30jours)
-set_serial n Définis le numéro de série du certificat auto-signé. Peut-être en décimal ou en hexa.
-extensions section
-reqexts section Spécifient les sections alternatives à inclure dans la requête.
-utf8 interprète les valeurs de champs au format UTF8
-nameopt option détermine comment le sujet et l’issuer sont affichés (voir x509)
-repopt Personnalise le format de sortie avec -text. l’argument peut être une simple options ou plusieurs, séparés par des ’,’ (voir x509)
-asn1-kludge Par défaut, req sort les requêtes de certificat ne contenant pas d’attributs dans le format PKCS#10 correct. Cependant, certaines CA acceptent uniquement les requêtes ne contenant pas d’attributs dans une forme invalide : cette options produit ce format invalide (les attributs dans une requête PKCS#10 sont définis comme un set d’attribut SET OF. Ils ne sont pas optionnels donc si aucun attribut n’est présent, il devrait être encodé comme un SET OF vide, une forme invalide ne contient pas ce SET OF vide)
-no-asn1-kludge Inverse l’effet de -asn1-kludge
-newhdr Ajoute le mot NEW dans l’en-tête et pied de page PEM.
-batch Mode non-interactif
-verbose Affiche les détails sur l’opération courante
-engine id req va tenter d’obtenir une référence fonctionnelle du moteur spécifié
-keygen_engine id Spécifie un moteur qui devrait être utilisé pour les opérations de génération de clé.

Format du fichier de configuration

input_password output_password Les mots de passe pour les fichier de clé privée d’entrée et de sortie (remplace passin et passout)
default_keyfile Taille en bits de la clé (défaut 512, remplace -newkey)
oid_file Spécifie un fichier contenant des OID additionnels. Chaque ligne consiste de l’oid suivi d’un espace blanc, suivi du nom cours, suivi par un blanc et suivi par un nom long.
oid_section Spécifie la section dans le fichier de configuration contenant les oid supplémentaires
RANDFILE Spécifie un nom de fichier contenant les données aléatoires à utiliser par le moteur de génération de nombres pseudo-aléatoires
encrypt_key à no, la clé privée n’est pas chiffrée. (Remplace -nodes)
default_md Spécifie l’algorithme digest à utiliser. (md5, sha1 ou mdc2, défaut : md5)
string_mask Masque l’utilisation de certaines chaines dans certains champs. default utilise PrintableStrings, T61Strings et BMPStrings.
pkix utilise PrintableStrings et BMPStrings. utf8only utilise UTF8Strings. nombstr utilise PrintableStrings et T61Strings.
req_extensions Spécifie la section du fichier de configuration contenant la liste des extensions à ajouter à une requête (remplace -reqexts)
x509_extensions Spécifie la section du fichier de configuration contenant un liste des extensions à ajouter au certificat généré avec -x509 (remplace -extensions)
prompt à no désactive la demande des champs du certificat et prend les valeurs dans le fichier de configuration
utf8 à yes les valeurs de champs sont interprétés en utf8 (ASCII par défaut)
attributes Spécifie la section contenant les attributs de requête. Identique à distinguished_name. Actuellement ignoré par OpenSSL.
distinguished_name Spécifie la section contenant les champs dn à demander pour générer un certificat ou une requête.

Format des sections Distinguished Name et Attribute

Il y’a 2 formats pour ces sections. Si l’option prompt est à no, ces sections consistent de noms de champs et de valeur. Par exemple:
CN=My Name
OU=My Organization
emailAddress=someone@somewhere.org

Si prompt est absent ou à yes, ces sections contiennent la liste des champs à demander:
fieldName="prompt"
fieldName_default="default field value"
fieldName_min= 2
fieldName_max= 4

fieldname est le nom d’un champs, par exemple commonName ou CN. "prompt" est utilisé pour demander à l’utilisateur d’entrer les informations du champ. Si l’utilisateur n’entre rien, ce champ est omis.
- Si une valeur par défaut est définie, elle sera utilisée si l’utilisateur n’entre rien. L’utilisateur peut outrepasser cette valeur par défaut en entrant le caractère '.'
- Les limites min et max peuvent être utilisé pour limiter les valeurs de champs. Par exemple, countryName peut seulement avoir 2 caractères et doivent être correspondre à un PrintableString
- Certains champs comme organizationName peuvent être utilisé plus d’une fois dans un DN. Un second organizationName peut être entré en l’appelant 1.organizationName
- Les noms de champs permis sont des noms cours ou long d’object identifier. Incluant : commonName, countryName, localityName, organizationName, organizationUnitName, stateOrProvinceName. emailAddress, name, surname, givenName, dnQualifier.
- Des object identifier additionnels peuvent être définis avec les options oid_file et oid_section dans le fichier de configuration. Ces champs additionnels seront traités comme si c’était un DirectoryString

Exemples

Examiner et vérifier une requête de certificat:
openssl req -in req.pem -text -verify -noout
Créer une clé privée et générer une requête de certificat:
openssl genrsa -out key.pem 1024
openssl req -new -key key.pem -out req.pem
Idem en utilisant uniquement req:
openssl req -newkey rsa:1024 -keyout key.pem -out req.pem
Générer un certificat root auto-signé:
openssl req -x509 -newkey rsa:1024 -keyout key.pem -out req.pem
Exemple de fichier pointé par l’option oid_file:
1.2.3.4 shortName A longer Name
1.2.3.6 otherName Other longer Name
Exemple d’une section pointée par oid_section:
testoid1=1.2.3.5
testoid2=$testoid1.6

Exemple de fichier de configuration demandant les valeurs de champs

[ req ]
default_bits = 1024
default_keyfile = privkey.pem
distinguished_name = req_distinguished_name
attributes = req_attributes
x509_extensions = v3_ca

dirstring_type = nobmp

[ req_distinguished_name ]
countryName = Country Name (2 letter code)
countryName_default = AU
countryName_min = 2
countryName_max = 2

localityName = Locality Name (eg, city)

organizationalUnitName = Organizational Unit Name (eg, section)

commonName = Common Name (eg, YOUR name)
commonName_max = 64

emailAddress = Email Address
emailAddress_max = 40

[ req_attributes ]
challengePassword = A challenge password
challengePassword_min = 4
challengePassword_max = 20

[ v3_ca ]

subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid:always,issuer:always
basicConstraints = CA:true

Exemple de configuration contenant toutes les valeurs de champs

RANDFILE = $ENV ::HOME/.rnd

[ req ]
default_bits = 1024
default_keyfile = keyfile.pem
distinguished_name = req_distinguished_name
attributes = req_attributes
prompt = no
output_password = mypass

[ req_distinguished_name ]
C = GB
ST = Test State or Province
L = Test Locality
O = Organization Name
OU = Organizational Unit Name
CN = Common Name
emailAddress = test@email.address

[ req_attributes ]
challengePassword = A challenge password

Notes

Le format PEM inclus:
-----BEGIN CERTIFICATE REQUEST-----
-----END CERTIFICATE REQUEST-----

Certains logiciels comme Netscape certificate server nécessitent:
-----BEGIN NEW CERTIFICATE REQUEST-----
-----END NEW CERTIFICATE REQUEST-----

Variables d'environnement

OPENSSL_CONF peut être utilisé comme emplacement de fichier de configuration alternatif.

09 avril 2012

OpenSSL - rsa

Traitement des clés rsa

OPTIONS

-inform DER|NET|PEM Format du fichier d’entrée.
-outform DER|NET|PEM Format du fichier de sortie
-in filename Fichier d’entrée
-passin arg source du mot de passe du fichier d’entrée
-out filename Fichier de sortie où écrire la clé
-passout password source du mot de passe du fichier de sortie
-sgckey Utilisé pour l’algorithme modifié NET utilisé avec certaines versions de Microsoft IIS et les clé SGC.
-des|-des3|-idea Algorithme utilisé pour chiffrer la clé privée.
-text Affiche des infos sur les clés privée et publique
-noout N’affiche pas la version encodée de la clé
-modulus Affiche la valeur du modulo de la clé
-check Vérifie la consistance de la clé privée RSA
-pubin Lit une clé publique en entrée plutôt qu’une clé privée
-pubout Sort une clé publique plutôt qu’une clé privée
-engine id rsa va tenter d’obtenir une référence fonctionnelle de ce moteur.

Notes

la forme PEM de la clé privée contient:
-----BEGIN RSA PRIVATE KEY-----
-----END RSA PRIVATE KEY-----

la forme PEM de la clé publique contient:
-----BEGIN PUBLIC KEY-----
-----END PUBLIC KEY-----

Exemples

OpenSSL - speed

-accept port Port TCP d’écoute (défaut : 4433)
-context id ID de Context SSL. Peut être une valeur chaîne.
-cert certname Certificat à utiliser.
-certform PEM|DER Format du certificat
-key keyfile Clé privée à utiliser
-keyform PEM|DER Format de la clé privée
-pass arg Source du mot de passe de la clé privée
-dcert filename, -dkey keyname Certificat et clé privée additionnel
-dcertform format, -dkeyform format, -dpass arg Le format du certificat et de la clé privée supplémentaire, et la source du mot de passe.
-nocert Ne pas utiliser de certificat. Restreint la suite de chiffrements à anonymous DH.
-dhparam filename Fichier de paramètres DH à utiliser
-no_dhe Ne charge aucun paramètre DH et désactive les suites de chiffrement ephemeral DH.
-no_tmp_rsa Pour les suites utilisant une clé RSA temporaire, désactive la génération d’une telle clé.
-verify depth, -Verify depth Spécifie la longueur max de la chaîne de certificat client et force le serveur à demander le certificat du client. -verifie, le client n’a pas à fournir de certificat, -Verify l’oblige.
-crl_check, -crl_check_all Vérifie la CRL. Les crl sont ajoutés au fichier de certificat.
-CApath directory Répertoire contenant les certificats de la CA au ’hash format’
-CAfile file Un fichier contenant les certificats de confiance
-state Affiche l’état de session SSL
-debug Affiche des informations de débogage incluant un dump hexa de tout le trafic
-msg Affiche tous les messages de protocoles avec dump hexa
-nbio_test Tests IO non bloquant
-nbio Active l’I/O non bloquant
-crlf Traduit un line feed depuis le terminal en CR+LF
-quiet Inhibe l’affichage de session et des informations de certificat
-psk_hint hint Utilise l’identité PSK en utilisant la suite de chiffrement PSK.
-psk key Utilise la clé PSK spécifié. La clé est donnée en hexa sans 0x, exemple : 1a2b3c4d
-ssl2, -ssl3, -tls1, -no_ssl2, -no_ssl3, -no_tls1 Désactive l’utilisation de certains protocoles SSL ou TLS. Par défaut, le handshake utilise une méthode qui devrait être compatible avec tous les serveurs et permet d’utiliser SSLv3, SSLv2 ou TLS.
-bugs Il y’a de nombreux bugs connus dans les implémentations SSL et TLS. Cette option autorise diverses solutions.
-hack Active une solution de contournement pour certaines anciennes versions de Netscape SSL.
-cipher cipherlist Permet de modifier la liste des chiffrements utilisés par le serveur.
-tlsextdebug Affiche un dump hexa des extensions TLS reçue
-no_ticket Désactive le support de ticket de session RFC4507bis
-www Envoie un message de statut au client quand il se connecte. Inclus beaucoup d’informations sur les chiffrements utilisé et divers paramètres de session, la sortie est au format HTML.
-WWW Emule un serveur web simple. Les pages chargées sont relatives au répertoire courant. (Ex : https://myhost/page.html charge ./page.html)
-HTTP idem, mais les pages chargée contiennent une réponse HTTP complète et correcte.
-engine id s_server va tenter d’obtenir une référence fonctionnelle du moteur spécifié.
-id_prefix arg Génère un ID de session SSL/TLS préfixé par arg.
-rand file(s) Le(s) fichier(s) contenant les données aléatoire utilisé par le générateur de nombre aléatoire.

Commandes connectées

Si une connexion est établie avec un client SSL et ni -www ni -WWW n’est utilisé, les données du client sont affichées et l’appuie sur une touche sera envoyé au client:

q Termine la connexion SSL courante, mais accepte les nouvelles connections
Q Termine la connexion SSL courante et quitte.
r Renégocie la session SSL
R Renégocie la session SSL et demande un certificat client
P Envoie un texte en clair à la connexion TCP : devrait forcer le client à se déconnecter dû à une violation de protocole.
S Affiche les informations de statut du cache de session

Notes

s_server peut être utilisé pour débugger les clients SSL. Pour accepter les connections depuis un navigateur web:
openssl s_server -accept 443 -www
Beaucoup de navigateurs ne supportent que les suites de chiffrement RSA. Les paramètres de session peuvent être imprimés avec sess_id.

03 juin 2012

OpenSSL - s_time

Programme de test de performance SSL/TLS

OPTIONS

-connect host:port Spécifie l’hôte:port distant
-www page Spécifie la page à GET. Sans cette options, s_time effectue simplement un handshake pour établir la connexion SSL, mais ne transfère pas de données payload.
-cert certname Certificat à utiliser (PEM)
-key keyfile Clé privée à utiliser
-verify depth Active la vérification du certificat du serveur et spécifie la longueur max de la chaine de certificat du serveur
-CApath directory Répertoire à utiliser pour la vérification du certificat du serveur. doit être un ’hash format’
-CAfile file Fichier contenant les certificats à truster
-new Effectue un test de temps en utilisant un nouvel ID de session pour chaque connexion.
-reuse Effectue un test de temps en utilisant le même ID de session.
-nbio Active l’I/O non bloquant
-ssl2, -ssl3 Désactive l’utilisation de certains protocoles SSL. Par défaut, le handshake utilise une méthode qui devrait être compatible avec tous les serveurs et permet d’utiliser SSLv3, SSLv2 ou TLS.
-bugs Il y’a de nombreux bugs connus dans les implémentations SSL et TLS. Cette option autorise diverses solutions.
-cipher cipherlist Permet d’envoyer la liste des chiffrements à modifier. Le serveur détermine quelle suite est utilisée et devrait prendre la première supportée dans la liste.
-time length Spécifie le temps en second que s_time devrait mettre pour établir les connections et optionnellement transférer les données payload du serveur.

Notes

s_time peut être utilisé pour mesurer les performances d’une connexion SSL. Pour se connecter à un serveur SSL HTTP et obtenir la page par défaut:
openssl s_time -connect servername:443 -www / -CApath yourdir -CAfile yourfile.pem -cipher commoncipher [-ssl3]

14 avril 2013

OpenSSL - ts

Outil de Time Stamping Authority (TSA) client/serveur

ts est un outil de base TSA client/serveur comme spécifié dans la RFC3161. Un TSA peut être une partie d’une PKI et son rôle est de fournir une preuve à long terme de l’existence d’un horodatage avant une date particulière. Brève description du protocole:

1. Le client TSA calcule un hash 'one-way' pour un fichier de données et l’envoie au TSA.
2. Le TSA attache la date et l’heure courante au hash reçu, signe le tout et renvoie ce token au client.
3. Le client TSA reçoit le token et vérifie la signature. Il vérifie également si le token contient le même hash qu’il avait envoyé au TSA.

Génération de requête et Time Stamp

-query Permet de générer une requête avec les options suivantes:

-rand file:file... Fichier contenant les données pour le générateur pseudo-aléatoire, plusieurs fichiers peuvent être utilisés
-config configfile Fichier de configuration à utiliser. Seul la section OID est utilisée (remplace la variable OPENSSL_CONF)
-data file_to_hash Fichier de donnée pour lequel la requête doit être crée.
-digest digest_bytes Permet de spécifier l’empreinte du message sans le fichier de donnée, au format hexadécimal
-md2|-md4|-md5|-sha|-sha1|-mdc2|-ripemd160|... Message digest à appliquer au fichier de données
-policy object_id Stratégie que le client s’attend à ce que le TSA utilise pour créer le time stamp. Sous forme OID numérique ou nom IOD.
-no_nonce Aucun nonce n’est utilisé, sinon un nombre pseudo-aléatoire 64 bits est inclus dans la requête. nonce est recommandé.
-cert Le TSA doit inclure son certificat de signature dans la réponse
-in request.tsq Spécifie une précédente requête time stamp en DER à afficher en sortie
-out request.tsq Nom du fichier de sortie pour écrire la requête.
-text Affiche la sortie compréhensible au lieu du DER.

Génération d'une réponse Time Stamp

-reply Créer une réponse time stamp, incluant le status de la réponse et le token lui-même, avec les options suivantes:

-config configfile Fichier de configuration à utiliser. (remplace la variableOPENSSL_CONF)
-section tsa_section Nom de la section contenant les paramètres pour la génération de la réponse
-queryfile request.tsq Nom du fichier contenant la requête timestamp encodée en DER
-passin password_src Source du mot de passe pour la clé provée du TSA
-signer tsa_cert.pem Certificat du signataire du TSA au format PEM. Doit avoir eactement un extension d’utilisation de clé ’timeStamping’ et doit être critique
-inkey private.pem clé privée du signataire du TSA au format PEM
-chain certs_file.pem Certification au format PEM à inclure dans la répnose en plus du certificat u signataire
-policy object_id Stratégie par défaut à utiliser pour la réponse à moins que le client en demande une. (nom ou OID)
-in response.tsr Spécifie une réponse timestamp créé précédemment ou un tocken timestamp au format DER qui sera écrit dns le fichier de sortie. Ne requière pas de requête. Permet d’examiner le contenu d’une réponse
-token_in avec -in, indique que l’entrée est un otken timestamp DER (ContentInfo) au lieu d’une réponse (TimeStampResp)
-out response.tsr Fichier de sortie
-token_out La sortie est un timestamp token (ContentInfo) au lieu d’une réponse (TimeStampResp)
-text Sort au format human-readable au lieu d’un DER
-engine id ts va tenter d’obtenir une référence fonctionnelle du moteur spécifié.

Vérification de réponse Time Stamp

-verify permet de vérifier une réponse ou un jeton, il accèpte les options suivante:

-data file_to_hash La réponse ou le token doit être vérifié avec. Ce fihcier est hashé avec le message digest spécifié dans le token.
-digest digest_bytes La réponse ou le token doit être vérifié avec le message digest
-queryfile request.tsq La requête originale en DER
-in response.tsr La réponse qui doit être vérifiée au format DER
-token_in avec -in, indique que l’entrée est un token DER (ContentInfo) au lie d’une réponse (TimeStampResp)
-CApath trusted_cert_path Répertoire contenant Les certificats de CA du client
-CAfile trusted_certs.pem Le nom du fichier contenant un jeu de certificats PEM de ca
-untrusted cert_file.pem Définis des certificats non-trustés PEM qui peuvent être nécessaire pour créer une chaîne de certificat

OPTIONS

-inform DER|PEM|NET Format du fichier x509 en entrée
-outform DER|PEM|NET Format du fichier en sortie
-in filename Fichier en entrée
-out filename Fichier de sortie
-md2|-md5|-sha1|-mdc2 Message digest à utiliser
-engine id x509 va tenter d’obtenir une référence fonctionnelle du moteur spécifié.

Options d'affichage

-text Affiche le certificat au format texte.
-certopt option Personnalise la sortie utilisée avec -text liste d’options à afficher. Peut être spécifié plusieurs fois
-noout N’affiche pas la version encodée de la requête
-pubkey Affiche le block SubjectPublicKeyInfo du certificat au format PEM
-modulus Affiche la valeur du modulo de la clé publique contenue dans le certificat
-serial Affiche le numéro de série du certificat
-subject_hash Affiche le hash du nom du certificat
-issuer_hash Affiche le hash de l’issuer du certificat
-hash idem à -subject_hash
-subject_hash_old Affiche le hash du nom du certificat en utilisant l’ancien algorithme pré v1
-issuer_hash_old Affiche le hash de l’issuer du certificat en utilisant l’ancien algorithme pré v1
-subject Affiche le sujet
-issuer Affiche le fournisseur
-nameopt option Détermine comment le sujet et l’issuer sont affichés (voir options de nom)
-email Affiche les adresses email
-ocsp_uri Affiche les adresses de répondeur OCSP
-startdate Affiche la date de début de validité du certificat
-enddate Affiche la date de fin de validité du certificat
-dates Affiche la date de début et d’expiration du certificat
-fingerprint Affiche le digest de la version encodé DER du certificat
-C Affiche le certificat sous la forme d’un source C

Paramètres de confiance

-trustout Sort un certifcat de confiance.
-setalias arg Définis l’alias du certificat
-alias Affiche l’alias du certificat, s’il existe
-clrtrust Efface toutes les utilisations de confiance et permises du certificat
-clrreject Efface toutes les utilisations rejetée ou interdites du certificat
-addtrust arg Ajoute une utilisation de certifiaction de confiance. (clientAuth, serverAuth, emailProtection)
-addreject arg Ajoute une utilisation interdite. Accèpte lesmême valeurs que -addtrust
-purpose Effectue des tests sur les extensions du certificat et affiche le résultat (voir les extensions de certificat)

Options de signature

-signkey filename Signe le fichier en entrée avec la clé privée spécifiée. Si l’entrée est une requête de certificat, génère un certificat auto-signé
-clrext Supprime des extensions d’un certificat
-keyform PEM|DER Format de la clé privée
-days arg Spécifie le nombre de jours pour créer une validité pour le certificat
-x509toreq Convertit un certificat en une requête
-req L’entrée est une requete au lieu d’un certificat
-set_serial n Numéro de série à utiliser en décimal ou hexa
-CA filename Certificat de la CA à utiliser pour signer le certificat
-CAkey filename Clé privée de la CA
-CAserial filename Définis le fichier de numéro de série à utiliser
-CAcreateserial Créé le fichier de numéro de série s’il n’existe pas
-extfile filename Fichier contenant les extensions à utiliser
-extensions section Section où se trouvent les extensions à ajouter

Options de nommage

compat Utiliser l’ancien formats, équivalent à ne spécifier aucune option de nommage
RFC2253 Affiche les noms compatibles avec la rfc2253 equivalent à spécifier: esc_2253, esc_ctrl, esc_msb, utf8, dump_nostr, dump_unknown, dump_der, sep_comma_plus, dn_rev et sname
oneline Format oneline, plus lisible que rfc2253. equivalent à spécifier: esc_2253, esc_ctrl, esc_msb, utf8, dump_nostr, dump_der, use_quote, sep_comma_plus_space, space_eq et sname
multiline Format multiligne. équivalent à spécifier: esc_ctrl, esc_msb, sep_multiline, space_eq, lname et align.
esc_2253 Échappe les caractères spéciaux (,+"‹› ;#) requis par la rfc2253
esc_ctrl Échappe les caractères de contrôle d’échappement
esc_msb Echappe les caractères avec le MSB mis, c’est à dire les valeurs ASCII › 127
use_quote Échappe certains caractères en les plaçant entre "" au lieu de \
utf8 Convertit toutes les chaînes en UTF8
no_type Ne tente pas d’interpréter les caractères multi-octets
show_type Affiche le type de chaîne caractère ASN1
dump_der Dump en encodé DER les champs qui doivent être dumpé en hexa
dump_nostr Dump les types de chaînes non caractères
dump_all Dump tous les champs
dump_unknown Dump les champs dont l’OID n’est pas reconnus par openssl
sep_comma_plus
sep_comma_plus_space
sep_semi_plus_space
sep_multiline Déterminent les séparateurs de champs
dn_rev Renverse les champs d’un DN
nofname
sname
lname
oid Altère la manière dont le nom des champs est affiché
align Aligne les valeurs de champs
space_eq Met des espace autour du caractère ’=’

Options de texte

compatible Utiliser l’ancien formats, équivalent à ne spécifier aucune option de sortie
no_header N’affiche pas les en-têtes
no_version N’affiche pas le numéro de version
no_serial N’affiche pas le numéro de série
no_signame N’affiche pas l’algorithme de signature utilisé
no_validity N’affiche pas la validité
no_subject N’affiche pas le sujet
no_issuer N’affiche pas l’issuer
no_pubkey N’affiche pas la clé publique
no_sigdump Ne dump par la signature du certificat
no_aux N’affiche pas les informations de trust du certificat
no_extensions N’affiche pas les extensions X509v3
ext_default Tente d’afficher les extensions de certificat non supportés
ext_error Affiche une erreur pour les extensions de certificat non supportés
ext_parse Parse en ASN1 les extensions non supportés
ext_dump Dumps en hexa les extensions non supportés
ca_default Valeur utilisé par l’utilitaire ca. equivalent à o_issuer, no_pubkey, no_header, no_version, no_sigdump et no_signame

Exemples

Afficher le contenu d’un certificat:
openssl x509 -in cert.pem -noout -text
Afficher le numérode série d’un certificat:
openssl x509 -in cert.pem -noout -serial
Affiche le sujet d’un certificat:
openssl x509 -in cert.pem -noout -subject
Afficher le sujet du certificat sous la forme RFC2253:
openssl x509 -in cert.pem -noout -subject -nameopt RFC2253
Afficher le sujet du certificat en une ligne et en utf8:
openssl x509 -in cert.pem -noout -subject -nameopt oneline,-esc_msb
Affiche l’empreinte MD5 du certificat:
openssl x509 -in cert.pem -noout -fingerprint
Affiche l’empreinte SHA1 du certificat:
openssl x509 -sha1 -in cert.pem -noout -fingerprint
Convertir un certificat PEM en DER:
openssl x509 -in cert.pem -inform PEM -out cert.der -outform DER
Convertit un certificat en requête:
openssl x509 -x509toreq -in cert.pem -out req.pem -signkey key.pem
Convertit une requête en un certificat auto-signé utilisant des extensions:
openssl x509 -req -in careq.pem -extfile openssl.cnf -extensions v3_ca -signkey key.pem -out cacert.pem
Signer une requête en utilisant le certificat d’un CA et en ajoutant des extensions utilisateur:
openssl x509 -req -in req.pem -extfile openssl.cnf -extensions v3_usr -CA cacert.pem -CAkey key.pem -CAcreateserial
Définis un certificat à truster pour un client SSL et changer son alias en "Steve’s Class 1 CA":
openssl x509 -in cert.pem -addtrust clientAuth -setalias "Steve’s Class 1 CA" -out trust.pem

Notes

Le format PEM utilise les élements suivants:
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----

ou:
-----BEGIN X509 CERTIFICATE-----
-----END X509 CERTIFICATE-----

Les certificats trustés auronts les lignes:
-----BEGIN TRUSTED CERTIFICATE-----
-----END TRUSTED CERTIFICATE-----

Extensions de certificat

l’option -purpose vérifie les extensions de certificat et détermine l’utilisation du certificat.

basicContraints (Bool)Cette extension est utilisé pour déterminer si le certificat peut être utilisé comme CA.
keyUsage Cette extension contient des restrictions sur l’utilisation du certificat. Un certificat CA doit avoir le but keyCertSign mis si cette extension est présente.

Description de chaque tests

SSL Client L’extension d’utilisation de clé doit être absent ou inclure l’OID web client authentication. keyUsage doit être absent ou avoir le bit digitalSignature mis.
SSL Client CA L’extension d’utilisation de clé doit être absent ou inclure l’OID web client authentication.
SSL Server L’extension d’utilisation de clé doit être absent ou inclure l’OID web server authentication et/ou un OID SGC. keyUsage doit être absent ou avoir le bit digitalSignature et/ou keyEncipherment mis.
SSL Server CA L’extension d’utilisation de clé doit être absent ou inclure l’OID web server authentication et/ou un OID SGC.
Netscape SSL Server Pour que les clients Netscape se connectent à un serveur SSL il doitavoir le bit keyEncipherment mis si keyUsage est présent
Common S/MIME Client Tests L’extension d’utilisation de clé doit être absent ou inclure l’OID email protection.
S/MIME Signing idem, et test le bit digitalSignature sur keyUsage est présent
S/MIME Encryption idem et test le bit keyEncipherment sur keyUsage est présent
S/MIME CA L’extension d’utilisation de clé doit être absent ou inclure l’OID email protection.
CRL Signing KeyUsage doit être absent ou avoir le bit CRL Signing mis.
CRL Signing CA Test normal CA, excepté que l’extention basicContraints ne doit pas être présent

15 avril 2013

OpenSSL - x509v3_config

Format de configuration des extensions de certificat X509 v3

   Le format est le suivant:

  extension_name=[critical,] extension_options

  Si critical est présent, l’extension est critique. Il y’a 4 types d’extension: chaînes, multi-valué, raw, et arbitraire.

exemple chaîne:
nsComment="This is a Comment"
exemple multi-valué:
basicConstraints=critical,CA:true,pathlen:1
variante d’un multivalué:
basicConstraints=critical,@bs_section
[bs_section]
CA=true
pathlen=1

Extensions standard

Contraintes de base Extension multi-valué qui indique si un certificat est un certificat de CA

basicConstraints=CA:TRUE
basicConstraints=CA:FALSE
basicConstraints=critical,CA:TRUE, pathlen:0

Un certificat de CA doit avoir basicContraints à TRUE et optionnellement un pathlen qui indique le nombre maximum de CA qui peut apparaitre sous celle-ci dans une chaîne. A 0, peut seulement signer des certificats finaux.

Utilisation de clé Extension multi-valué consistant d’une liste de noms d’utilisation de clé permis Les noms supportés sont : digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment, keyAgreement, keyCertSign, cRLSign, encipherOnly et decipherOnly.

exemple:
keyUsage=digitalSignature, nonRepudiation
keyUsage=critical, keyCertSign

Utilisation de clé étendue Consiste en une liste d’utilisation indiquant l’utilisation de la clé publique. Peut être un nom court, ou un OID:

Value Meaning
----- -------
serverAuth SSL/TLS Web Server Authentication.
clientAuth SSL/TLS Web Client Authentication.
codeSigning Code signing.
emailProtection E-mail Protection (S/MIME).
timeStamping Trusted Timestamping
msCodeInd Microsoft Individual Code Signing (authenticode)
msCodeCom Microsoft Commercial Code Signing (authenticode)
msCTLSign Microsoft Trust List Signing
msSGC Microsoft Server Gated Crypto
msEFS Microsoft Encrypted File System
nsSGC Netscape Server Gated Crypto

exemple:
extendedKeyUsage=critical,codeSigning,1.2.3.4
extendedKeyUsage=nsSGC,msSGC

Identifiant de clé du sujet Extention de type chaîne qui prend 2 valeurs : hash qui suit la rfc3280 ou une chaîne hexa donnant la valeur de l’extension à inclure

exemple:
subjectKeyIdentifier=hash

Identifiant de clé d’autorité Permet 2 options, keyid et issuer et peuvent prendre optionnellement la valeur always

   Avec keyid, tente de copier le subject key identifier depuis le certificat parent. Avec always, une erreur est retourné si l’option échoue.

  avec issuer, copie l’issuer et le numéro de série de l’issuer

exemple:
authorityKeyIdentifier=keyid,issuer

Subject Alternative Name L’extention subjectAltName permet d’inclure divers valeurs : email, URI, DNS, RID (ID:Object Identitifer), IP, dirName (un DN) et otherName.

email contient une options spécial ’copy’ qui inclus automatiquement les emails contenus dans le sujet dans l’extension
dirName devrait pointer vers une section contenant un DN à utiliser.
otherName peut inclure des données arbitraires associées avec un OID

exemple:
subjectAltName=email:copy,email:my@other.address,URI :http://my.url.here/
subjectAltName=IP:192.168.7.1
subjectAltName=IP:13::17
subjectAltName=email:my@other.address,RID:1.2.3.4
subjectAltName=otherName:1.2.3.4;UTF8:some other identifier

subjectAltName=dirName:dir_sect

[dir_sect]
C=UK
O=My Organization
OU=My Unit
CN=My Name

Issuer Alternative Name Supporte toutes les options litéral de subjectAltName. Il ne supporte pas l’option mail:copy. Il supporte issuer:copy qui copie tous les subjectAltName du certificat de l’issuer

exemple:
issuerAltName = issuer:copy

Authority Info Access Extension d’accès aux informations de l’authorité donne des détails sur la mannière d’accéder à certaines informations lié à la CA. la syntaxe est accessOID;location, où location a la même syntaxe qu’un subjectAltName (excepté email:copy) accessOID peut être un OID valide mais seul certaines valeurs ont une signification, par exemple OCSP et calssuers

exemple:
authorityInfoAccess = OCSP;URI:http://ocsp.my.host/
authorityInfoAccess = caIssuers;URI:http://my.ca/ca.html

Point de distribution de CRL Extension multi-valuée qui peut être un nom:valeur utilisant la même forme qu’un subjectAltName

   Dans le cas d’une simple option, la section indiquée contient les valeurs pour chaque champs. dans cette section:

  Si le nom est fullname la valeur devrait contenir le nom complet du point de distribution dans le même format que subjectAltName.

  Si le nom est relativename, la valeur devrait contenir un nom de section dont le contenu représente un DN

  Le nom CRLIssuer devrait contenir une valeur pour ce champ au format subjectAltName

  Si le nom est reasons, la valeur devrait consister en un champ contenant les raisons: keyCompromise, CACompromise, affiliationChanged, superseded, cessationOfOperation, certificateHold, privilegeWithdrawn, AACompromise.

exemple:
crlDistributionPoints=URI:http://myhost.com/myca.crl
crlDistributionPoints=URI:http://my.com/my.crl,URI:http://oth...
crlDistributionPoints=crldistpoint1_section

[crldistpoint1_section]
fullname=URI:http://myhost.com/myca.crl
CRLissuer=dirName:issuer_sect
reasons=keyCompromise, CACompromise

[issuer_sect]
C=UK
O=Organisation
CN=Some Name

Issuing Distribution Point Devrait seulement apparaître dans les CRL. Extension multi-valuée dont la syntaxe est similaire à la section pointé par l’extension de point de distribution de CRL avec quelques différences

   Les noms reasons et CRLIssuer ne sont pas reconnus

  Le nom onlysomereasons est accepté. La valeur est au même format que le champ reasons des crlDistributionPoints. Les noms onlyuser, onlyCA, onlyAA et indirectCRL sont aussi acceptés et sont des booléen.

exemple:
issuingDistributionPoint=critical, @idp_section
[idp_section]
fullname=URI:http://myhost.com/myca.crl
indirectCRL=TRUE
onlysomereasons=keyCompromise,CACompromise
[issuer_sect]
C=UK
O=Organisation
CN=Some Name

Certificate Policies Extension raw

Si on suit la recommandation PKIX, en utilisant des OID:
certificatePolicies= 1.2.4.5, 1.1.3.4

   Si on inclus des qualifiers, les OID de stratégie et les qualifieurs doivent être spécifiés dans une section séparée (sous la forme @section) La section référée doit inclure l’OID de stratégie en utilisant policyIdentifier. les qualifiers cPSuri peuvent être inclus avec cette syntaxe:

CPS.nnn=value

les qualifiers userNotice peuvent être définis avec:
userNotice.nnn=@notice

   Cette section peut inclure explicitText, organization et noticeNumbers.

exemple:
certificatePolicies=ia5org,1.2.3.4,1.5.6.7.8,@polsect
[polsect]
policyIdentifier = 1.3.5.8
CPS.1="http://my.host.name/";
CPS.2="http://my.your.name/";
userNotice.1=@notice
[notice]
explicitText="Explicit Text Here"
organization="Organisation Name"
noticeNumbers=1,2,3,4

   Si userNotice est utilisé avec IE5, il faut l’option ia5org avant pour modifier l’encodage. Cette options modifie le type de champs organization dans la rfc2459, il peut seulement être de type DisplayText. Dans la rfc3280 IA5String est aussi permis.

Policy Constraints Extension multivaluée consistant de nom requireExplicitPolicy ou inhibitPolicyMapping et une valeur entière non négative Au moins un composant doit être présent.

exemple:
policyConstraints = requireExplicitPolicy:3

Inhibit Any Policy Extension chaîne consistant de valeurs non négatives

exemple:
inhibitAnyPolicy = 2

Name Constraints Extension multi-valuée. Le nom devrait commencer avec le mot permitted ou excluded, suivi par un ';' le reste suivi la syntaxe subjectAltName excepté email:copy et IP

exemple:
nameConstraints=permitted;IP:192.168.0.0/255.255.0.0
nameConstraints=permitted;email:.somedomain.com
nameConstraints=excluded;email:.com
issuingDistributionPoint = idp_section

OCSP No Check Extension chaîne, mais sa valeur est ignored

exemple:
noCheck = ignored

Extensions arbitraires

Si une extension n’est pas supportée par OpenSSL, elle doit être encodé en utilisant le format arbitraire. Il est possible d’utiliser ce format pour les extensions connues.

Il y’a 2 manières d’écrire des extensions de type arbitraire:

Utiliser le mot ASN1 suivi de l’extension en utilisant la même syntaxe que ASN1_generate_nconf(3):
1.2.3.4=critical,ASN1:UTF8String:Some random data
1.2.3.4=ASN1:SEQUENCE:seq_sect
[seq_sect]
field1 = UTF8:field1
field2 = UTF8:field2

Utiliser le mot DER pour inclure les donnée brutes:
1.2.3.4=critical,DER:01:02:03:04
1.2.3.4=DER:01020304

La valeur après DER est un dump DER d’une extension. Une extension peut être placée dans cette forme pour remplacer le mode par défaut :
basicConstraints=critical,DER:00:01:02:03

Notes

Si une extension est multi-valué et un champs doit contenir un ',', la forme longue doit être utilisée sinon le séparateur sera mal interprété:
subjectAltName=URI:ldap://somehost.com/CN=foo,OU=bar

va produire une erreur, mais ceci est valide:
subjectAltName=@subject_alt_section
[subject_alt_section]
subjectAltName=URI:ldap://somehost.com/CN=foo,OU=bar

Due à la librairie conf, le même nom de champ ne peut se trouver qu’une seul fois. Celà signifie que:
subjectAltName=@alt_section
[alt_section]
email=steve@here
email=steve@there

Va seulement reconnaître la dernière valeur, alors que ceci reconnaîtra toutes les valeurs:
[alt_section]
email.1=steve@here
email.2=steve@there

Ajouter cette ligne dans /etc/pam.d/login pour définir une message au login
auth optional pam_issue.so issue=/etc/issue

06 octobre 2010

pam_keyinit

Affiche le fichier keyinit

pam_keyinit s'assure que le process invoque une session keyring autre que la session keyring par défaut de l'utilisateur. Il vérifie si la session keyring du processus est le défaut de l'utilisateur, et si c'est le cas, crée une nouvelle session keyring anonyme. Ce module est utilié principalement pour les processus de login. Ce module ne devrait pas être invoqué par des programmes comme su. Le package keyutils est utilisé pour manipuler les clés plus directement.

OPTIONS

debug Affiche des informations de debuggage
force force le session keyring du processus invoquant pour être remplacé inconditionnellement
revoke Force le session keyring du processus invoquant pour être révoqué quand ce processus quitte si le session keyring pour ce processus

Valeurs retournées

ne fournit que le type de module session. Retourne PAM_SUCCESS, pam_ATH_ERR, PAM_BUF_ERR, PAM_IGNORE, PAM_SERVICE_ERR, PAM_SESSION_ERR et PAM_USER_UNKNOWN

Exemples

Ajouter cette ligne dans les entrées logins pour commencer chaque session login avec sa propre session keyring
session required pam_keyinit.so

02 juillet 2014

pam_krb5

Module d'authentification Kerberos

OPTIONS

ccache=‹pattern› Utilise le pattern pour créer le cache d'accréditifs. doit être sous la forme ‹type›:‹residual›. %u est remplacé avec l'id de l'utilisateur. %p est remplacé avec le PID courant. Si pattern se termine avec la chaîne XXXXXX, une chaîne aléatoire est utilisée. (auth et session)
ccache_dir=‹directory› Stocke les caches utilisateur dans le répertoire spécifié au lieu de /tmp (auth et session)
debug mode debug
forwardable Obtient des tickets forwardable (auth)
ignore_k5login Ne regarde jamais dans le fichier .k5login dans le home de l'utilisateur (auth et account)
ignore_root Ne fait rien si l'utilisateur est root.
minimum_uid=‹uid› ID minimum pour authoriser l'authentification
no_ccache ne créé pas de cache de ticket après l'authentification (auth). non définissable dans krb5.conf
realm=‹realm› Obtient des accréditifs dans le domaine spécifié au lieu de celui par défaut. non définissable dans krb5.conf
renew_lifetime=‹lifetime› Obtient des tickets renouvelable (auth)
retain_after_close Ne détruit pas le cache de ticket temporaire lorsque pam_end() ou pam_close_session() sont appelés. (auth et session)
search_k5login Utilise .k5login de l'utilisateur pour l'authentification.
try_first_pass Utilise le mot de passe d'un module précédent au lieu d'en demander un. En cas d'échec, demande un mot de passe.
use_authtok Utilise le mot de passe d'un module précédent au lieu d'en demander un. Ne demande jamais de mot de passe.
use_first_pass Utilise le mot de passe d'un module précédent au lieu d'en demander un. En cas d'échec, si aucun module n'a de mot de passe, en demande un, si un mot de passe est trouvé et ne fonctionne pas, échoue sans en demander un.

Variables d'environnement

KRB5CCNAME Définis par pam_setcred(). Fichier du cache d'accréditifs par défaut, sous la forme type:residual
PAM_KRB5CCNAME Définis par pam_authenticate() pour pointer vers le cache de ticket temporaire utilisé pour l'authentification.

Fichiers

/tmp/krb5cc_UID_RANDOM Nom du cache d'accréditifs par défaut.
/tmp/krb5cc_pam_RANDOM no du cache d'accréditifs utilisé pour le cache temporaire crée par pam_authenticate(). il est supprimé à la fin de la session pam ou quand pam_setcred() est appelé.
~/.k5login Fichier contenant les principaux Kerberos autorisés à accéder à ce compte.

Exemples

Exemple de configuration PAM:
auth sufficient pam_krb5.so ignore_root
session optional pam_krb5.so ignore_root
account required pam_krb5.so ignore_root
password optional pam_krb5.so ignore_root

Exemple de configuration krb5.conf
[appdefaults]
forwardable = true
    pam = {
        minimum_uid = 100
        EXAMPLE.COM = {
            ignore_k5login = true
        }
    }

06 octobre 2010

pam_lastlog

Affiche une ligne d'information sur la dernière connexion de l'utilisateur

Le module maintient le fichier /var/log/lastlog.

OPTIONS

debug Affiche des informations de debuggage
silent N'informe par 'utilisateur sur le précédent login, met simplement à jours /var/log/lastlog
never Si /var/log/lastlog est vide, indique à l'utilisateur qu'il n'a jamais été loggé
nodate N'affiche pas la date du dernier login
noterm N'affiche pas le nom du terminal
nohost N'indique pas depuis quel hôte le dernier login a eu lieu
nowtmp Ne met pas à jour l'entrée wtmp
noupdate Ne met aucun fichier à jour
showfailed Affiche le nombre de logins échoués et la date de la dernier tentative échouée depuis btmp

Valeurs retournées

PAM_SUCCESS tout est ok
PAM_SERVICE_ERR Erreur interne
PAM_USER_UNKNOWN utilisateur inconnu

Exemples

Ajouter cette ligne dans /etc/pam.d/login pour afficher le dernier login d'un utilisateur
session required pam_lastlog.so wtmp

13 novembre 2010

pam_ldap

Authentification via un serveur ldap

   pam_ldap fournit l'authentification, l'autorisation et le changement de mot de passe depuis un serveur ldap. Il inclus le support sécurisé, authentification sasl, les politiques de mot de passe renforcés pas le serveur, les autorisations de login basés sur les hôtes et groupes.

  Quand il autorise ou authentifie un utilisateur, pam_ldap map le nom de login de l'utilisateur à un DN en cherchant dans l'annuaire. Cela doit être possible en utilisant l'identité du système local, spécifié dans ldap.conf (cette étape initial ne supporte que l'authentification simple pour le moment).

  Pour authentifier ou autoriser un utilisateur, pam_ldap tente de se lier au serveur en utilisant le DN de l'utilisateur. pam_ldap est généralement configuré dans ldap.conf, mais certaines options peuvent être configurées dans le fichier de configuration PAM, pour permettre une granularité par service.

   Les options du fichier de configuration consistent d'un mot clé suivi par un espace et des arguments. Il est possible de configurer certains aspects de pam_ldap par service dans les fichiers de configuration de pam

OPTIONS

config=‹path› Spécifie le fichier de configuration à utiliser au lieu de ldap.conf. Il n'est pas possible d'utiliser plusieurs instances de configuration.
use_first_pass Spécifie que pam_ldap devrait toujours utiliser le premier mot de passe fournis dans la pile d'authentification
try_first_pass Spécifie que pam_ldap devrait d'abord essayer le premier mot de passe fournis dans la pile d'authentification, puis de demander à l"utilisateur le mot de passe LDAP si l'authentification échoue.
ignore_unknown_user Spécifie que pam_ldap devrait retourner PAM_IGNORE pour les utilisateurs non présents dans l'annuaire.
ignore_authinfo_unavail Spécifie que pam_ldap devrait retourner PAM_IGNORE s'il ne peut contacter le serveur LDAP
no_warn Spécifie que les messages d'alerte ne devraient pas être propagés dans l'application PAM
use_authok Identique à use_first_pass pour le changement de mot de passe uniquement

06 octobre 2010

PAM_BUF_ERR erreur tampon mémoire
PAM_SERVICE_ERR argument malformé
PAM_SUCCESS succès
PAM_USER_UNKNOWN utilisateur inconnu

Exemples

Ajouter cette ligne dans /etc/pam.d/login pour indiquer que l'utilisateur a de nouveau mails quand il se log sur le système
session optional pam_mail.so standard

06 octobre 2010

pam_mkhomedir

Créer un répertoire home

ce module crée un répertoire home utilisateur s'il n'existe pas quand la session commence. Cela permet aux utilisateurs d'être présent dans la base central (tel que NIS, kerberos ou LDAP) sans utiliser un système de fichier distribué ou en pré-créant un grand nombre de répertoires. Le répertoire squelette (généralement /etc/skel/) est utilisé pour copier les fichiers par défaut et définir également un umask pour l'utilisateur.

OPTIONS

silent N'affiche pas d'information
skel=/path/to/skel/directory Spécifie le répertoire squelette
umask Spécifie le masque de création de fichiers

Valeurs retournées

PAM_BUF_ERR Erreur de tampon mémoire
PAM_CRED_INSUFFICIENT insufficient credentials to access authentification data
PAM_PERM_DENIED Pas assez de permission pour créer le nouveau répertoire ou lire le dossier squelette
PAM_USER_UNKNOWN utilisateur inconnu
PAM_SUCCESS variables d'environnement définis

Exemples

un exemple du fichier /etc/pam.d/login
auth requisite pam_securetty.so
auth sufficient pam_ldap.so
auth required pam_unix.so
auth required pam_nologin.so
account sufficient pam_ldap.so
account required pam_unix.so
password required pam_unix.so
session required pam_mkhomedir.so skel=/etc/skel/ umask=0022
session required pam_unix.so
session optional pam_lastlog.so
session optional pam_mail.so standard

06 octobre 2010

pam_motd

Afficher le fichier motd

pam_motd permet d'afficher le contenu d'un fichier motd une fois loggé avec succès. par défaut /etc/motd. La taille du message est limitée à 64Ko. Ne fournit que le type de module session.

Valeurs retournées

PAM_IGNORE c'est la seule valeur retournée par ce module

Exemples

pam_permit

Permet de toujours autoriser l'accès

Dans le cas d'une authentification, le nom d'utilisateur est nobody si l'application n'est fournis pas un. Ce module est dangereux.

Exemples

Ajouter cette ligne dans les entrées other pour désactiver la gestion des comptes, mais continue de permettre aux utilisateurs de se logger
account required pam_permit.so

12 février 2012

pam_pkcs11

Module PAM d'authentification via une librairie PKCS #11

Module PAM pour faire de l'authentification au moyen d'un certificat X509 au travers d'une librairie PKCS #11. Pour la vérification des certificats utilisateurs, le certificat de l'autorité stocké localement et la CRL en ligne ou locale sont utilisés. Les modules PKCS #11 doivent remplir les prérequis de RSA Asymmetric Client Signing Profil. Pour permettre au propriétaire d'un certificat de se connecter, pam_pkcs11 utilise des modules appelés des mappers, qui effectuent des mappages cert-to-login.

Configurer le package

1. créer le répertoire de base /etc/pam_pkcs11/
2. Copier ${base}/etc/pam_pkcs11.conf.example dans /etc/pam_pkcs11/ et le renommer en /etc/pam_pkcs11/pam-pkcs11.conf
3. créer /etc/pam_pkcs11/crls/ et /etc/pam_pkcs11/cacerts/. Le répertoire tools/ fournis un outil pkcs11_make_hask_link qui peut être utilisé pour créer les fichiers de hash pour chaque fichier certificat et crl valide.
4. Choisir un ou plusieurs mappers à installer, les configurer.
5. Éditer et configurer /etc/pam.d/xxx
6. Utiliser pkcs11_inspect et pklogin_finder pour voir si vous pouvez lire le certificat et effectuer un mappage correct
7. tester un login.

Configurer pam_pkcs11

la configuration de pam-pkcs11 se fait en 2 étapes:
1. configurer pam-pkcs11
2. Configurer les options PAM.

Vous devez connaître

- quel module PKCS #11 vous allez utiliser, et son fichier
- quels mappers vous voulez et comment le créer et l'éditer
- Les fichiers de l'authorité de certification et le fichier de révocation
- Une liste d'utilisateurs autorisés à se connecter, et leur certificats correspondant.

Spécifier la CRL et la CA

pam-pkcs11 a besoin d'une liste d'authorité de certification reconnue pour valider l'utilisateur. Celà s'applique également à la CRL :

1. Créer les répertoire ca_dir et crl_dir en accord avec le fichier de configuration
2. Copier les certificats de la CA au format DER ou PEM
3. Créer un hash link vers les certificats CA, fournis avec pkcs11_make_hash_link. Noter que openSSL doit être installé :
cd /etc/pam_pkcs11/cacerts
/usr/bin/pkcs11_make_hash_link
4. Répéter la procédure pour la CRL
5. Sélectionner la stratégie de vérification de certificat (cert_policy)

NOTE : Du à des limitations de librairie OpenSSL, les certificats de la CA doivent résider dans le système de fichier local.

Un fichier de map a la syntaxe suivante:
Certificate1 data -› login1
Certificate2 data -› login2
Certificate3 data -› login3
Ce fichier est parsé du début àla fin et la première occurence qui match est retournée.

Configuration PAM

Configurer les fichiers pam.d

auth sufficient pam_pkcs11.so ...

OPTIONS

debug mode debug
err_display_time Secondes à attendre après un message d'erreur pour lire le message
config_file Spécifier le fichier de configuration (défaut : /etc/pam_pkcs11/pam_pkcs11.conf)
nullok Autorise les mots de passe vide
use_first_pass Ne demande pas le mot de passe à l'utilisateur, mais le prend depuis le PAM_items.
try_first_pass Ne demande pas le mot de passe à l'utilisateur à moins que PAM_(OLD)AUTHOK ne soit pas mis.
use_authok Comme try_first_pass mais échoue si le nouveau PAM_AUTHOK n'a pas été précédemment mis.
pkcs11_module=‹file› Nom de fichier du module PKCS11 (défaut : /etc/pam_pkcs11/pkcs11_module.so)
slot_num=‹nb› Numéro de slot à utiliser (défaut = 0 = utiliser le premier slot disponible)
ca_dir=‹path› Répertoire contenant les certificats CA (défault : /etc/pam_pkcs11/cacerts/)
crl_dir=‹path› Répertoire contenant la CRL (défault : /etc/pam_pkcs11/crls/)
cert_policy=none, ca, signature, crl_online, crl_offline, crl_auto Spécifier la stratégie de vérification par défaut.

Utiliser la fonction d'auto-détection de LOGIN

Depuis pam-pkcs11-0.4.2 pam-pkcs11 peut déduire le username depuis le certificat utilisateur sans utiliser le login prompt.

Quand pam_get_user() retourne null ou une chaîne vide, pam-pkcs11 va alors utiliser la fonction ’find’ du mapper au lieu du match normal. Si le finder retourne un succès, le username est définit avec pam_set_item(PAM_USER) et PAM_AUTH_OK est retourné.

Il y’a 2 manières d’utiliser cette fonctionnalité :
a. Patcher gdm et login pour détecter la présence d’un carte et retourner null comme nom d’utilisateur
b. Utiliser une version non patchée et entrée un espace pour login et entrée pour gdm.

12 février 2012

pam_pkcs11.conf

fichier de configuration pour pam_pkcs11

   Le fichier de configuration utilise la librairie scconf. Les paramètres et données sont groupées dans des blocks. ils peuvent être imbriqués.

Un fichier de configuration pam_pkcs11 ressemble à:
pam-pkcs11
    global options
    [...]
    use_pkcs11_module = pkcs11 module to be used
    pkcs11_module module1 {
        module1 specific options
    }
    pkcs11_module module2 {
        module2 specific options
    }
    [...]
    use_mappers = mapper1, mapper2,... ;
    mapper mapper1 {
        mapper1 specific options
    }
    mapper mapper2 {
        mapper2 specific options
    }
    [...]
    mapper mapperN {
        mapperN specific options
    }
}

Exemple de fichier pam_pkcs11.conf
pam_pkcs11 {
    nullok = true ; # Allow empty passwords
debug = true ; # Enable debugging support.
    use_first_pass = false ; # Do not prompt for the passwords but take them from the PAM_ items instead
    try_first_pass = false ; # Do not prompt for the passwords unless PAM_(OLD)AUTHTOK is unset.
    use_authtok = false ; # Like try_first_pass, but fail if the new PAM_AUTHTOK has not been previously set (intended for stacking password modules only).
    use_pkcs11_module = opensc ; # Filename of the PKCS #11 module. The default value is "default"

pkcs11_module opensc {
    module = /usr/lib/opensc-pkcs11.so ;
    description = "OpenSC PKCS#11 module" ;
    slot_description = "none" ; # spécifier le slot à utiliser. préférer cette option à slot_num.
    # slot_num = 0 ; # spécifier soit slot_description, soit slot_num.
    ca_dir = /etc/pam_pkcs11/cacerts ; # répertoire contenant les certificats de l’autorité au format pem ou asn1 oui des liens hash.
    crl_dir = /etc/pam_pkcs11/crls ; # répertoire contenant la CRL offline
    support_threads = false ; # certaines librairies supportent le multi-thread
    cert_policy = ca,signature ; # définis la vérification de certificat
    # none aucune vérification
    # ca vérfication de la CA
    # crl_online télécharge la CRL
    # crl_offline utilise la crl offline
    # crl_auto tente d’abord la online, puis la offline
    # signature vérifie la signature
    token_type = "Smart card" ; # spécifie le type de token. sera utilisé dans le message de prompt.
    pkcs11_module etoken { # Aladdin eTokenPRO 32
        module = /usr/local/lib/libetpkcs11.so
        description = "Aladdin eTokenPRO-32" ;

        slot_num = 0 ;
        support_threads = true ;
        ca_dir = /etc/pam_pkcs11/cacerts ;
        crl_dir = /etc/pam_pkcs11/crls ;
        cert_policy = ca,signature ;
    }
    pkcs11_module nss { # NSS (Network Security Service) config
        nss_dir = /etc/ssl/nssdb ;
        crl_policy = none ;
    }
    pkcs11_module default { # Default pkcs11 module
        module = @libdir@/pam_pkcs11/pkcs11_module.so ;
        description = "Default pkcs#11 module" ;
        slot_num = 0 ;
        support_threads = false ;
        ca_dir = /etc/pam_pkcs11/cacerts ;
        crl_dir = /etc/pam_pkcs11/crls ;
        cert_policy = none ;
    }
    use_mappers = digest, cn, pwent, uid, mail, subject, null ;    # spécifie les mappers à utiliser:
        # subject    Sujet du certificat
        # pwent     CN ou gecos
        # ldap        mapper LDAP
        # opensc    Cherche le certificat dans ${HOME}/.eid/authorized_certificates
        # openssh    Cherche la clé public du certificat dans ${HOME}/.ssh/authorized_keys
        # mail        compare le champs email du certificat
        # ms        Utilise l’UPN
        # krb        Compare avec le Kerberos Principal Name
        # cn        Compare le CN
        # uid        Compare l’UID
        # digest    Certificat Digest
        # generic    Contenu définis par l’utilisateur
        # null        blind access/deny mapper
    mapper_search_path = @libdir@/pam_pkcs11 ;    # chemin des module mapper.
    mapper subject {                # Mapper le sujet du certificat pour le login, fournis dans un fichier sous la forme "Subject -› login"
        debug = false ;
        #module = @libdir@/pam_pkcs11/subject_mapper.so ;
        module = internal ;
        ignorecase = false ;
        mapfile = file :///etc/pam_pkcs11/subject_mapping ;
    }
    mapper pwent {                # map le CN à getpwent()
        debug = false ;
        ignorecase = false ;
        module = internal ;
        #module = @libdir@/pam_pkcs11/pwent_mapper.so ;
    }
    mapper ldap {                # mapper d’annuaire
        debug = false ;
        module = @libdir@/pam_pkcs11/ldap_mapper.so ;
        ldaphost = "" ;                 # fqdn du serveur ldap (utilise l’URI ldap pour en spécifier plusieurs)
        ldapport = ;                 # port du serveur ldap s’il n’est pas donné dans l’URI
        URI = "" ;                # list d’URI utilisés dans l’ordre
        scope = 2 ;                 # scope de recherche : 0 (base), 1 (one), 2 (sub)
        binddn = "cn=pam,o=example,c=com" ;     # DN du bind. doit avoir un accès en lecture
        passwd = "" ;                 # password du binddn
        base = "ou=People,o=example,c=com" ;    # base de recherche
        attribute = "userCertificate" ;        # attribut qui contient le certificat
        filter = "(&(objectClass=posixAccount)(uid=%s))" # Filtre de recherche pour les entrées utilisateurs ( doit seulement laisser passer l’entrée pour le login utilisateur )
        ssl = tls                # off (désactiver), tls (activer tls), on|ssl (activer ssl)
        tls_randfile =                 # chemin de la source entropie
        tls_cacertfile = /etc/ssl/cacert.pem    # Chemin vers le certification pour l’authentification du pair
        tls_cacertdir =                # Répertoire contenant les certificats X509 pour l’authentification du pair
        tls_checkpeer = 0            # 0 ou 1. spécifie de vérifier le certificat.
        tls_ciphers =                 # Chiffrement à utiliser
        tls_cert = ...                # Chemin du fichier contenant le certificat local pour l’authentification TLS client
        tls_key = ...                # Chemin du fichier contenant la clé privée pour l’authentification TLS client
    }
    mapper opensc {                 # recherche les certificats depuis $HOME/.eid/autorized_certificates qui match l’utilisateur
        debug = false ;
        module = @libdir@/pam_pkcs11/opensc_mapper.so ;
    }
    mapper openssh {                # Cherche les clés publique dans $HOME/.ssh/authorized_keys qui match l’utilisateur
        debug = false ;
        module = @libdir@/pam_pkcs11/openssh_mapper.so ;
    }
    mapper mail {                # Compare le champ email du certificat
        debug = false ;
        module = internal ;
        # module = @libdir@/pam_pkcs11/mail_mapper.so ;
        mapfile = file :///etc/pam_pkcs11/mail_mapping ;    # Déclarer un fichier de map, ’empty’ ou vide pour ne pas utiliser de fichier de map
        ignorecase = true ;            # ignorer la casse
        ignoredomain = false ;            # Vérifie le domaine mx. en utilisant un fichier de map, cette option est ignorée.
    }
    mapper ms {                    # utilise l’UPN (login@AD_domain)
        debug = false ;
        module = internal ;
        # module = @libdir@/pam_pkcs11/ms_mapper.so ;
        ignorecase = false ;
        ignoredomain = false ;
        domain = "domain.com" ;
    }
    mapper krb {                # Compare avec le principal kerberos
        debug = false ;
        module = internal ;
        # module = @libdir@/pam_pkcs11/krb_mapper.so ;
        ignorecase = false ;
        mapfile = "none" ;
    }
    mapper cn {                    # le CN est le login
        debug = false ;
        module = internal ;
        # module = @libdir@/pam_pkcs11/cn_mapper.so ;
        ignorecase = true ;
        # mapfile = file :///etc/pam_pkcs11/cn_map ;
        mapfile = "none" ;
    }
    mapper uid {                # l’uid (s’il existe) est le login
        debug = false ;
        module = internal ;
        # module = @libdir@/pam_pkcs11/uid_mapper.so ;
        ignorecase = false ;
        mapfile = "none" ;
    }
    mapper digest {                # Evalue le digest du certificat et le map dans un fichier
        debug = false ;
        module = internal ;
        # module = @libdir@/pam_pkcs11/digest_mapper.so ;
        algorithm = "sha1" ;             # Algorithme utilisé pour évaluer le digest ("null","md2","md4","md5","sha","sha1","dss","dss1","ripemd160")
        mapfile = file :///etc/pam_pkcs11/digest_mapping ;
        # mapfile = "none" ;
    }
    mapper generic {                # mapper de contenu générique
        debug = true ;
        #module = @libdir@/pam_pkcs11/generic_mapper.so ;
        module = internal ;
        ignorecase = false ;            # ignirer la casse
        cert_item = cn ;             # ( "cn" , "subject" , "kpn" , "email" , "upn" ou "uid" )
        mapfile = file :///etc/pam_pkcs11/generic_mapping ;
        use_getpwent = false ;            # utiliser petpwent() pour mapper le login
    }
    mapper null {                # Pas de mappage. Quand un utilisateur match à NULL ou nobody
        debug = false ;
        # module = @libdir@/pam_pkcs11/null_mapper.so ;
        module = internal ;
        default_match = false ;            # match toujours (true) ou échoue toujours (false)
        default_user = nobody ;            # en cas de match, retourner cet utilisateur
    }
}

06 octobre 2010

PAM_AUTH_ERR Ne peut pas récupérer ou définir de contexte valide
PAM_SUCCESS le contexte de sécurité a été définis
PAM_USER_UNKNOWN Utilisateur inconnus

Exemples

auth required pam_unix.so
session required pam_permit.so
session optional pam_selinux.so

06 octobre 2010

pam_shells

Vérifie les shells de login valides

pam_shells autorise l'accès au système si le shell utilisateur est listé dans /etc/shells. Il vérifie également si /etc/shells est un fichier texte et n'est pas writable. Ne fournis que les type de module auth et account.

Valeurs retournées

PAM_AUTH_ERR l'accès a été refusé
PAM_SUCCESS l'accès est autorisé
PAM_SERVICE_ERR le module n'est pas capable d'obtenir le nom de l'utilisateur

Exemples

auth required pam_shells.so

06 octobre 2010

pam_succeed_if

Test les caractéristiques des comptes

pam_succeed_if est conçu pour réussir ou non l'authentification en se basant sur les caractéristiques du compte de l'utilisateur. Une utilisation est de sélectionner si d'autres modules sont chargés en fonction de ce test.

OPTIONS

debug syslog les informations de debuggage
use_uid Évalue les conditions en utilisant le compte utilisateur de l'application au lieu de l'utilisateur qui s'authentifie
quiet mode silencieux
quiet_fail ne log pas les echecs
quiet_success ne log pas les réussites
audit syslog les utilisateurs inconnus

Conditions

Les conditions sont composés de 3 mots un champs, un test et une valeur de test.

field ‹ number
field ‹= number
field eq number
field ›= number
field › number
field ne number
field = string
field != string
field = glob
field in item:item :...
user ingroup group
user notingroup group
user innetgr netgroup
user notinnetgr group

Exemples

Pour émuler de principe de pam_wheel, excepté qu'il ne revient pas au group 0
auth required pam_succeed_if.so quiet user ingroup wheel
charge seulement les autres modules si l'UID est › 500
type [ default=1 success=ignore ] pam_succeed_if.so quiet uid › 500
type required othermodule.so arguments

07 octobre 2010

pam_tally2

Module compteur de login

   Ce module maintient un compteur de tentative d'accès, peut ré-initialiser ce compteur en cas de succès et peut refuser l'accès si trop de tentatives échouent.

  pam_tally2 est composé de 2 parties: pam_tally2.so et pam_tally2. Ce dernier est une application optionnelle qui peut être utilisé pour interroger et manipuler le fichier compteur. Il peut afficher le compteur de l'utilisateur, définir les compteurs individuels ou reset tous les compteurs Définir des compteurs élevés peut être utile pour bloquer les utilisateurs sans changer leur mot de passe. Par exemple, il peut être utile effacer tous les compteurs à minuit depuis un cron.

  Normalement, les tentatives échouées au compte root ne bloque pas ce compte, pour prévenir les DOS. Fournit les types de module auth et account.

Options globales

PAM_AUTH_ERR Authentification échouée
PAM_AUTHOK_RECOVERY_ERR Les informations d'authentification ne peut être récupérées
PAM_BUF_ERR Erreur de tampon mémoire
PAM_CONV_ERR Erreur de conversation
PAM_SERVICE_ERR Erreur dans le module
PAM_SUCCESS succès
PAM_USER_UNKNOWN Utilisateur inconnus

Exemples

auth sufficient pam_userdb.so icase db=/etc/dbtest.db

/var/lib/pcscd/reader.conf: Fichier de configuration des lecteurs
/var/run/pcscd/pcscd.pid: process id
/usr/lib/pcsc/drivers: Répertoire des pilotes usb.

OPTIONS

-a, --apdu log les APDU et SW en utilisant la méthode de debug
-c, --config Spécifie le fichier alternatif à /var/lib/pcscd/reader.conf
-f, --foreground Ne lance pas en tâche de fond et envoie les mesage sur stderr au lieu de syslog
-d, --debug Niveau de debug
--info Utilise le niveau de log info (mode par défaut)
--error Utilise le niveau de log error
--critical Utilise le niveau de log critical
-H, --hotplug Demande à pcscd de rescanner les bus USB et relire /var/lib/pcscd/reader.conf pour détecter les lecteurs non-USB.

13 février 2012

pcsc_scan

Scanner les lecteurs de carte

Scan les lecteurs de carte à interval régulier. Il demande à pcscd la liste des lecteurs disponible. Quand une carte est insérée, il affiche diverses informations:

Date et heure, nom du lecteur, état de la carte et évènements, ATR de la carte à l’insertion et analyse si la commande ATR_analysis est disponible

OPTIONS

-n N’effectue pas d’analyse ATR.

24 décembre 2016

pkaction

Obtenir des détails sur les actions enregistrées

pkaction est utilisé pour obtenir des informations sur les actions PolicyKit.

OPTIONS

--action-id Affiche seulement l'action spécifiée
--verbose Affiche des détails

24 décembre 2016

pkcheck

Vérifier si un processus est autorisé

pkcheck est utilisé pour vérifier si un processus, est autorisé à effectuer une action.

OPTIONS

--process processus pour lequel enregistrer l'agent d'authentification
--system-bus-name Nom du sujet pour lequel enregistrer l'agent d'authentification
--detail key value Peut être spécifié plusieurs fois pour passer des détails sur l'action
--allow-user-interaction Attend pour l'authentification
--list-temp Liste toutes les autorisations temporaires pour la session courante
--revoke-temp Révoque toutes les autorisations temporaires pour la session courante.
--action-id Spécifie l'action à vérifier
--process [pid|pid,pid-start-time|pid,pid-start-time,uid] Spécifie le processus à vérifier
--enable-internal-agent Si aucun agent d'authentification n'est disponible, enregistre son agent d'authentification textuel

Valeurs de retour

   si le processu spécifié est autorisé, pkcheck quitte avec une valeur de retour de 0. Si l'autorisation résultante contient des détails, ils sont affiché sur stdout.

   Si le processus spécifié n'est pas autorisé, pkcheck quitte avec une valeur de 1 et un message de diagnostique est affiché sur stdout.

   Si le processus spécifié n'est pas autorisé parce l'agent d'authentification a été fermé par l'utilisateur, pkcheck quitte avec une valeur 3 et un message de diagnostique affiché sur stderr. Des détails sont affichés sur stdout

   Si une erreur se produit pour l'autorisation, pkcheck quitte avec une valeur de retour de 127 et un message de diagnostique est affiché sur stderr.

   Si une ou plusieurs options passées sont malformées, pkcheck quitte avec une valeur de 126. Si stdin est un tty, ce man est également affiché.

05 mars 2012

PKCS#1

RSA Cryptography Standard

RSA (Rivest Shamir Adleman) est un algorithme asymétrique.

Génération des clés

Pour calculer une paire de clé privée/publique RSA, l’algorithme s’appuie sur 2 nombres premiers, p et q. Une fois ces 2 nombres déterminés, on obtient 2 nombres:
n = p x q
z = ( p - 1 ) x ( q - 1 )
On calcul ensuite l’indicatrice d’Euler e de z (inférieur à z), qui doit nécessairement être premier avec z:
d = e-1 mod((p - 1)(q - 1))

le couple (n,e) est la clé publique, le couple (n,d) est la clé privée. Une fois e, d et n caclulés, il faut détruire p, q, et z pour des raisons évidentes de sécurité. La clé privée est généralement chiffrée avec un algorithme symmetrique pour la conserver de façon sûre.

Chiffrement et déchiffrement

Pour chiffrer un nombre, il faut le mettre à la puissance de e. Le reste modulo n représente le nombre chiffré:
c = t^e mod n
pour déchiffrer, on utilise la même opération, mais à la puissance d:
t = c^d mod n
exemple simple utilisant de petits nombres:
pour chiffrer le texte suivant: "Hello World", on choisis p = 37 et q = 43.
on déduit :
n = 37 x 43 = 1591
z = 36 x 42 = 1512
on choisit e = 19, premier avec 1512. L’inverse de 19 modulo 1512 est d = 955.
pour chiffrer chaque caractère:
Hello World = 72 101 108 108 111 32 87 111 114 108 100

H___e___l___l___o___ ___W___o___r___l___d
72__101_108_108_111_32__87__111_114_108_100

on caclule chaque caractère avec:
7219 [1591] = 335 ; 10119 [1591] = 1174 ; etc…

72____101____108____108____111___32____87____111___114___108____100
335___1174___1329___1329___703___930___431___703___632___1329___396

On déchiffre avec:
335955 [1591] = 72 ; 1174955 [1591] = 101 ; etc…

Notes

Plusieurs techniques permettent de déchiffrer ou déduire la clé privée:

pkcs11_setup

Affiche tous les certificats

OPTIONS

debug mode debug
list_module liste les modules disponible et configurés dans /etc/pam_pkcs11/pam_pkcs11.conf
use_module Affiche le module utilisé par pam_pkcs11 ou le définis
ins_action[=commande] Affiche les commande exécutées quand la carte est insérée ou définis les commandes
rm_action[=commande] Affiche les commande exécutées quand la carte est retirée ou définis les commandes

15 février 2012

pkcs15-crypt

Effectuer des opérations crypto en utilisant des cartes pkcs #15

OPTIONS

--sign, -s Signer numériquement une donnée lue depuis un fichier. Le contenu du fichier est le résultat d’une opération de hash md5. Il attend une donnée binaire. Si aucun fichier de sortie n’est spécifié, affiche sur stdout
--pkcs1 pkcs15-crypt attend en entrée des données à la longueur correcte. Cette option force pkcs15-crypt à convertir à la bonne longueur en utilisant pkcs1
--sha-1 Le fichier d’entrée est le résultat d’une opération de hash SHA1 au lieu de md5. (Doit être en représentation binaire)
--decipher, -c Déchiffre le contenu du fichier. le résultat est écrit sur stdout si aucun fichier de sortie n’est spécifié
--key, -k Spécifie l’id de la clé à utiliser
--reader, -r Sélectionne le nième lecteur de carte
--input, -i Spécifie le fichier à utiliser en entrée
--output, -o Spécifie le fichier à utiliser en sortie
--raw, -R Sort les données brut 8bits
--pin, -p Spécifie le PIN si une opération le nécessite
--verbose, -v mode verbeux

15 février 2012

pkcs15-init

Utilitaire de personnalisation de carte à puce

Il permet de créer des structures PKCS #15 sur les cartes à puce, créer des PIN et ajouter des clés et des certificats. Les détails de la structure est contrôlée par des profils.

Utilisation du PIN

Une carte OpenSC peut avoir un security officer PIN, et 0 ou plusieurs PIN utilisateurs. Généralement, un PIN est une séquence de chiffres, mais certaines cartes acceptent des caractères ascii. Le SO-PIN est spécial, il est utilisé pour protéger les métadonnées sur la carte, tel que la structure PKCS #15 elle-même. Le SO-PIN est optionnel. Pour chaque PIN, vous pouvez spécifier un PUK.

Modes opératoires

Initialisation

Première étape de la personnalisation de la carte, et va créer les fichiers de bases sur la carte. Pour créer une structure PKCS #15 (le PIN, le PUK et le SO-PIN sont demandés):
pkcs15-init --create-pkcs15
Si la carte le supporte, vous pouvez également l’effacer avant avec --erase

Installation du PIN de l'utilisateur

Avant d’installer des objets, vous avez besoin d’au moins un PIN pour protéger ces objets (demande le PIN et le PUK):
pkcs15-init --store-pin --id " nn
Où nn est un ID PKCS #15 en notation hexadécimal. Les valeurs communes sont 01, 02, etc.

Génération de clé

Pour générer une nouvelle clé et la stocker:
pkcs15-init --generate-key " keyspec " --auth-id " nn
Où keyspec décrit l’algorithme et la longueur de la clé à créer, tel que rsa/512. Actuellement seul RSA est supporté. nn est l’ID d’un PIN utilisateur
Cela va stocker la portion privée et publique de la clé. Par défaut, tente d’utiliser la fonctionnalité embarquée de la carte.

Télécharger la clé privée

Vous pouvez utiliser une clé par un autre moyen et la charger dans la carte. Doit être au format PEM, DER, et les certificats pkcs12 et pfx :
pkcs15-init --store-private-key key.pem --id 45 --auth-id 01
L’option --id sert pour définir 2 templates de clé. l’id 45 sert pour l’authentification et l’id 46 pour la non-répudiation.

Télécharger la clé publique

--store-public-key stocke la clé publique. Utiliser --format pour spécifier le format du fichier (PEM par défaut)

Télécharger un certificat

--store-certificat stocke le certificat. Le fichier est supposé être un fichier x.509 au format DER

Télécharger les fichiers pkcs#12

pkcs15-init --store-private-key key.p12 --format pkcs12 --auth-id 01

OPTIONS

--profil, -p Charge le profile général spécifié. Des options peuvent être spécifiées pour ce module en ajoutant un + entre chaque option. ex : pkcs15+onepin
--card-profile, -c Charge l’option de profile de carte spécifié.
--create-pkcs15, -C Crée un structure PKCS #15 sur la carte
--erase-card, -E Efface la carte avant de créer la structure PKCS #15
--generate-key, -G Dit à la carte de générer une nouvelle clé et de la stocker sur la carte, avec l’algorithme/longueur spécifiée
--store-private-key, -S Télécharge la clé privée sur la carte. Crée également un objet clé publique
--store-public-key, -P Télécharge la clé publique sur le certificat
--store-certificate, -X Stocke le certificat sur la carte
--so-pin, --so-puk, --pin, --puk Permet de spécifier les valeurs pour les opérations qui le nécessite
--passphrase Permet de spécifier la passphrase pour débloquer la clé privée
--verbose, -v mode verbeux
--options-file Lit les options additionnelles depuis le fichier spécifié. Ce fichier est supposé contenir une option longue par ligne. (Peut être spécifié plusieurs fois). ex:

pin frank
puk zappa

15 février 2012

pkcs15-tool

Utilitaire pour manipuler les structures de données PKCS #15

OPTIONS

--learn-card, -L Met en cache les données du token PKCS #15. Les opérations suivantes sont effectuées sur les données en cache si possible.
--read-certificate, -r Lit le certificat avec l’id spécifié
--list-certificates, -c Liste tous les certificats présent
--list-pins Liste tous les PIN
--change-pin Change un PIN
--unblock-pin, -u Débloque un PIN en utilisant le PUK
--list-keys, -k Listes les clés privées
--list-public-keys Liste toutes les clés publiques
--read-public-key Lit la clé publique avec l’id spécifié
--read-ssh-key Lit la clé publique avec l’id spécifié, affiche dans un format compatible pour $HOME/.ssh/authorized_keys
--output, -o Fichier de sortie
--no-cache Désactive la mise en cache des données
--pin-id, -a Spécifie le PIN à utiliser pour l’opération. Utile avec -change-pin
--reader Utilise le lecteur spécifié par son numéro
--verbose, -v mode verbeux

07 mars 2012

PKCS#3

Diffie-Hellman Key-Agreement Standard

L’échange de clé Diffie-Hellman est une méthode par laquelle 2 personnes peuvent se mettre d’accord sur un nombre qu’ils peuvent utiliser pour chiffrer des données.

Exemple

1. 2 utilisateurs A et B choisisent un nombre premier p et une base g: p=23, et g=3
2. L’utilisateur A choisi un nombre secret a=6
3. L’utilisateur A envoie la valeur A = g^a [mod p] = 3⁶ [23] = 16
4. L’utilisateur B choisit un nombre secret b=15
5. L’utilisateur B envoie la valeur B = g^b [mod p] = 3¹⁵ [23] = 12
6. L’utilisateur A calcule la clé secrète K : (g^b [mod p])^a [mod p] = 12⁶ [23] = 9
7. L’utilisateur B calcule la clé secrète K : (g^a [mod p])^b [mod p] = 16¹⁵ [23] = 9

Il est nécessaire d’utiliser des nombres suffisamment grand pour éviter une attaque par recherche exhaustive.

Diffie-Hellman est vulnérable aux attaques MITM. Pour parer à cette attaque, on peut signer les échanges avec une paire de clés asymétriques.

24 décembre 2016

pkexec

Exécuter une commande sous un autre utilisateur

pkexec permet à un utilisateur autorisé d'exécuter le programmes spécifié sous un autre utilisateur. Si l'utilisateur n'est pas spécifié, utilise root.

Valeur de retour

une fois terminé, la valeur de retour est la valeur de retour du programme. Si le processus appelant n'est pas autorisé ou qu'une autorisation ne peut pas être obtenue ou qu'une erreur s'est produite, pkexec quitte avec une valeur de retour de 127. Si l'autorisation ne peut être obtenue, pkexec quitte avec la valeur 126.

l'agent d'authentification

pkexec, comme tout autre application PolicyKit, utilise l'agent d'authentification enregistré pour le procéssus appelant. Cependant, si aucun agent d'authentification n'est disponible, pkexec enregistre son propre agent d'authentification. Ce comportement peut être désactivé avec --disable-internal-agent.

Notes de sécurité

Exécuter un programme sous un autre utilisateur est une opération privilégiée. Par défaut l'autorisation requise nécéssite une authentification administrative. De plus, le dialogue d'authentification présenté à l'utilisateur affiche le chemin complet du programme à exécuter dont l'utilisateur est au courant de se qu'il va se passer.

+----------------------------------------------------------+
|_____________________Authenticate_____________________[X]_|
+----------------------------------------------------------+
|__________________________________________________________|
|__[Icon]__Authentication_is_needed_to_run_`/bin/bash'_____|
|__________as_the_super_user_______________________________|
|__________________________________________________________|
|__________An_application_is_attempting_to_perform_an______|
|__________action_that_requires_privileges._Authentication_|
|__________as_the_super_user_is_required_to_perform_this___|
|__________action._________________________________________|
|__________________________________________________________|
|__________Password_for_root:_[_________________________]__|
|__________________________________________________________|
|_[V]_Details:_____________________________________________|
|__Command:_/bin/bash______________________________________|
|__Run_As:__Super_User_(root)______________________________|
|__Action:__org.freedesktop.policykit.exec_________________|
|__Vendor:__The_PolicyKit_Project__________________________|
|__________________________________________________________|
|__________________________________[Cancel]_[Authenticate]_|
+----------------------------------------------------------+

L'environnement dans lequel le programme tourne, est définis à un environnement minimal et sûr pour éviter d'injecter du code via LD_LIBRARY_PATH ou des mécanismes similaires. De plus, la variable d'environnement PKEXEC_UID est définie avec l'UID invoquant pkexec. En résultat, pkexec n'autorise pas de lancer des application X11 sous un autre utilisateur vu que $DISPLAY et $XAUTHORITY ne sont pas définis. Il y a 2 variables retenus si org.freedesktop.policykit.exec.allow_gui dans une action est définis à une valeur non-nul. C'est découragé, et utilisé uniquement pour compatibilité.

Autorisations requises

Par défaut, org.freedesktop.policykit.exec est requis sauf si un fichier de définition d'action est présent pour le programme en question. pour exiger une autre autorisation, cela peut être spécifié en utilisant l'annotation org.freedesktop.policykit.exec.path dans une action.

Exemple

Pour spécifier un type d'autorisation nécessaire pour exécuter le programme /usr/bin/pk-example-frobnicate sous un autre utilisateur, écrire simplement une définition d'action:
‹?xml version="1.0" encoding="UTF-8"?›
‹!DOCTYPE policyconfig PUBLIC
    "-//freedesktop//DTD PolicyKit Policy Configuration 1.0//EN"
    "http://www.freedesktop.org/standards/PolicyKit/1/policyconfig.dtd"›
‹policyconfig›

    ‹vendor›Examples for the PolicyKit Project‹/vendor›
    ‹vendor_url›http://hal.freedesktop.org/docs/PolicyKit/‹/vendor_url›

    ‹action id="org.freedesktop.policykit.example.pkexec.run-frobnicate"›
        ‹description›Run the PolicyKit example program Frobnicate‹/description›
        ‹description xml:lang="da"›Kør PolicyKit eksemplet Frobnicate‹/description›
        ‹message›Authentication is required to run the PolicyKit example program Frobnicate (user=$(user), program=$(program), command_line=$(command_line))‹/message›
        ‹message xml:lang="da"›Autorisering er påkrævet for at afvikle PolicyKit eksemplet Frobnicate (user=$(user), program=$(program), command_line=$(command_line))‹/message›
        ‹icon_name›audio-x-generic‹/icon_name›
        ‹defaults›
            ‹allow_any›no‹/allow_any›
            ‹allow_inactive›no‹/allow_inactive›
            ‹allow_active›auth_self_keep‹/allow_active›
        ‹/defaults›
        ‹annotate key="org.freedesktop.policykit.exec.path"›/usr/bin/pk-example-frobnicate‹/annotate›
    ‹/action›

‹/policyconfig›

   placer ce fichier dans /usr/share/polkit-1/actions avec un nom qui ait du sens, par exemple l'espace de nom de l'action. Noter que pkexec ne valide pas les arguments passés au programme. Dans un cas normal (où l'authentification administration est requise à chaque fois que pkexec est utilisé), ce n'est pas un problème vu que si l'administrateur est un administrateur il peut simplement lancer pkexec bash pour devenir root.

   Cependant, si une action est utilisée pour laquelle l'utilisateur peut retenir l'authorisation ( ou si l'utilisateur est implicitement autorisé), tel qu'avec pk-example-frobnicate ci-dessus, cela peut être un problème de sécurité. Donc, les programmes pour lesquels l'autorisation requise par défaut est changé, ne devraient jamais implicitement faire confiance à l'entrée utilisateur.

15 février 2012

pklogin-finder

Trouver des maps Cert-to-login

Utilisé pour trouver les maps Cert-to-login, en dehors de l’environnement PAM. Peut être utilisé pour créer et tester les maps. Il utilise la même structure de configuration que le module pam-pkcs11. Il lit le certificat et tente tous les mappers spécifiés pour trouver l’utilisateur.

OPTIONS

[no]debug mode debug
config_file=‹file› Fichier de configuration (défaut : /etc/pam_pkcs11/pam_pkcs11.conf)

24 décembre 2016

pkttyagent

Helper d'authentification textuel

pkttyagent est utilisé pour démarrer un agent d'authentification textuel pour le sujet spécifié par --process ou --system-bus-name. Si aucun n'est spécifié, utilise le processus parent.

Pour être notifié quand l'agent d'authentification a été enregistré, écouter soit D-Bus ou utiliser --notify-fd pour passer le numéro d'un descripteur de fichier au programme. Ce fd sera fermé quand l'agent d'authentification est enregistré.

Valeur de retour

   Si l'agent d'authentification ne peut pas être enregistré, pkttyagent quitte avec un code de sortie de 127. Des messages de diagnostique sont affichés sur stderr.

   Si une ou plusieurs options sont malformées, pkttyagent quitte avec le code 126. Si stdin est un tty, ce man est également affiché.

   Si l'agent d'authentification a été enregistré avec succès, pkttyagent continue de fonctionner, interagissant avec l'utilisateur si nécessaire. Quand ses services ne sont plus nécessaires, le processus s'arrête.

Notes

Vu que les PID peuvent être recyclés, l'appelant devrait toujours utiliser pid,pid-start-time en utilisant l'option --process. La valeur de pid-start-time peut être déterminé en consultant par exemple proc. Si seul pid est passé à l'option --process, pkttyagent recherche l'heure de début de lui-même.

OPTIONS

--process { pid | pid,pid-start-time} processus pour lequel enregistrer l'agent d'authentification
--system-bus-name busname Nom du sujet pour lequel enregistrer l'agent d'authentification
--notify-fd fd Permet de passer un descripteur de fichier pour connaître quand l'agent d'authentification est enregistré
--fallback Empêche l'agent d'authentification textuel de remplacer un agent d'authentification existant.

24 décembre 2016

polkit

framework d'autorisation

policyKit fournis une API d'autorisation conçue pour être utilisée par des programmes privilégiés (mécanismes) offrant un service à des programmes non privilégiés (clients) sous la forme d'un mécanisme IPC tel que D-Bus ou pipes Unix. Dans ce scénario, le mécanisme traite généralement le client n'étant pas de confiance. Pour toute requête d'un client, le mécanisme doit déterminer si la requête est autorisée ou si elle devrait refuser le service au client. En utilisant l'API PolicyKit, un mécanisme peut décharger cette décision à un tier de confiant: l'autorité PolicyKit.

En plus d'agir comme autorité, PolicyKit permet aux utilisateurs d'obtenir une autorisation temporairement en authentifiant soit un utilisateur administratif ou le propriétaire de la session auquel appartient l'utilisateur. C'est utile pour les scénarios où un mécanisme doit vérifier que l'opérateur du système est réellement l'utilisateur ou réellement un utilisateur administratif.

Architecture système

   L'architecture système de PolicyKit est composé de l'autorité (implémenté comme un service dans D-Bus) et un agent d'authentification par session utilisateur (fournis et démarré par la session utilisateur). Additionnellement, PolicyKit support des points d'extensions - spécifiquement, les vendeurs et/ou sites peuvent écrire des extensions pour contrôler complètement la stratégie d'autorisation. Dans un diagramme block, l'architecture ressemble à ceci:

    +-------------------+
_|___Authentication__|
_|_______Agent_______|
_+-------------------+
_|_libpolkit-agent-1_|
_+-------------------+
________^__________________________________+--------+
________|__________________________________|_Client_|
________+--------------+___________________+--------+
_______________________|________________________^
_______________________|________________________|
User_Session___________|________________________|
=======================|========================|=============
System_Context_________|________________________|
_______________________|________________________|
_______________________|____________________+---+
_______________________V____________________|
_____________________/------------\_________|
_____________________|_System_Bus_|_________|
_____________________\------------/_________|
_______________________^________^___________V
_______________________|________|______+---------------------+
________+--------------+________|______|______Mechanism______|
________|_______________________|______+---------------------+
________V_______________________+----›_|_libpolkit-gobject-1_|
+------------------+___________________+---------------------+
|_org.freedesktop._|
|____PolicyKit1____|
+------------------+
|___Backends_and___|
|____Extensions____|
+------------------+

   libpolkit-gobject-1 enveloppe l'API D-Bus PolicyKit utilisant GObject. Cependant, un mécanisme peut également utiliser l'API D-Bus ou la commande pkcheck pour vérifier les autorisations.

   La librairie libpolkit-agent-1 fournis une abstraction du système d'authentification natif, par exemple pam et également des facilités d'enregistrement et de communication avec le service D-Bus PolicyKit.

   Les extensions PolicyKit et les backends d'autorité sont implémentés en utilisant libpolkit-backend-1

Agents d'authentification

Un agent d'authentification est utilisé pour que l'utilisateur d'une session prouve qu'il est l'utilisateur ou un utilisateur administratif. Pour s'intégrer avec le reste de la session utilisateur, les agents d'authentification sont censés être fournis par la session utilisateur que l'utilisateur utilise. Par exemple, un agent d'authentification peut ressembler à:

+----------------------------------------------------------+
|_____________________Authenticate_____________________[X]_|
+----------------------------------------------------------+
|__________________________________________________________|
|__[Icon]__L'authentification_est_requise_pour_lancer______|
|__________des_tests_ATA_SMART_____________________________|
|__________________________________________________________|
|_________Une_application_tente_d'effectuer_une_action_____|
|_________qui_nécessite_des_privilèges._L'authentification_|
|_________super_utilisateur_est_requis_pour_effectuer______|
|_________cette_action.____________________________________|
|__________________________________________________________|
|__________Password_for_root:_[_________________________]__|
|__________________________________________________________|
|_[V]_Details:_____________________________________________|
|__Drive:__ATA_INTEL_SSDSA2MH08_(045C)_____________________|
|__Device:_/dev/sda________________________________________|
|__Action:_org.fd.devicekit.disks.drive-ata-smart-selftest_|
|__Vendor:_The_DeviceKit_Project___________________________|
|__________________________________________________________|
|__________________________________[Cancel]_[Authenticate]_|
+----------------------------------------------------------+

Si le système est configuré sans un compte root il peut vous autoriser à sélectionner un utilisateur administratif:
+----------------------------------------------------------+
|_____________________Authenticate_____________________[X]_|
+----------------------------------------------------------+
|__________________________________________________________|
|__[Icon]__Authentication_is_required_to_run_ATA_SMART_____|
|__________self_tests______________________________________|
|__________________________________________________________|
|__________An_application_is_attempting_to_perform_an______|
|__________action_that_requires_privileges._Authentication_|
|__________as_one_of_the_users_below_is_required_to________|
|__________perform_this_action.____________________________|
|__________________________________________________________|
|__________[[Face]_Patrick_Bateman_(bateman)_________[V]]__|
|__________________________________________________________|
|__________Password_for_bateman:_[______________________]__|
|__________________________________________________________|
|_[V]_Details:_____________________________________________|
|__Drive:__ATA_INTEL_SSDSA2MH08_(045C)_____________________|
|__Device:_/dev/sda________________________________________|
|__Action:_org.fd.devicekit.disks.drive-ata-smart-selftest_|
|__Vendor:_The_DeviceKit_Project___________________________|
|__________________________________________________________|
|__________________________________[Cancel]_[Authenticate]_|
+----------------------------------------------------------+

Les applications qui tournent pas sous un environnement de bureau peuvent ne pas avoir d'agent d'authentification associé avec lui. De telles applications peuvent utiliser le type PolkitAgentTextListener ou pkttyagent pour que l'utilisateur puisse s'authentifier en utilisant une interface textuelle.

Déclarer des actions

   Un mécanisme doit déclarer un jeu d'actions pour utiliser PolicyKit. Les actions correspondent aux opérations que les clients peuvent demander et sont définis dans des fichiers XML que le mécanisme install dans /usr/share/polkit-1/actions.

Les action PolicyKit sont en namespace et peuvent seulement contenir les caractères "[a-z][0-9].-". Chaque fichier XML peut contenir plus d'une action mais toutes les actions doivent être dans le même espace de nom et le fichier doit être nommé après l'espace de nom et doit avoir l'extension .policy. Le fichier XML doit avoir la déclaration doctype suivante:
‹?xml version="1.0" encoding="UTF-8"?›
‹!DOCTYPE policyconfig PUBLIC "-//freedesktop//DTD PolicyKit Policy Configuration 1.0//EN"
"http://www.freedesktop.org/standards/PolicyKit/1.0/policyconfig.dtd"›

   L'élément policyconfig doit être présent exactement une fois. Les éléments qui peuvent être utilisés dans policyconfig incluent:

vendor Le nom du projet ou vendeur qui fournis les action dans le document XML.
vendor_url Une URL du projet ou vendeur qui fournis les action dans le document XML.
icon_name Un icône représentant le projet ou vendeur qui fournis les actions.
action Déclare une action. Le nom de l'action est spécifiée en utilisant l'attribut id et peuvent seulement contenir les caractères "[a-z][0-9].-"

   Les éléments qui peuvent être inclus dans les actions sont:

description Une description de l'action
message Le message affiché à l'utilisateur quand les accréditifs sont demandés.
defaults Cet élément est utilisé pour spécifier des autorisation implicites au client

Les éléments qui peuvent être utilisés dans defaults incluents:

allow_any Autorisation implicite qui s'applique à tout client.
allow_inactive Autorisation implicite qui s'applique aux clients dans les sessions inactives dans les consoles locales.
allow_active Autorisation implicite qui s'applique aux clients dans les sessions actives dans les consoles locales.

   Chaque élément allow_any, allow_inactive, et allow_active peuvent contenir les éléments suivants:

no non autorisé
yes autorisé
auth_self Authentification par le propriétaire de la session d'où vient le client requise
auth_admin Authentification par un utiliateur administratif est requis
auth_self_keep Comme auth_self mais l'autorisation est conservé pour une période brève.
auth_admin_keep Comme auth_admin mais l'autorisation est conservée pour une brève période.

annotate Utilisé pour annoter une action avec une paire de clé/valeur. La clé est spécifiée en utilisant l'attribut clé et la valeur est spécifiée en utilisant la valeur attribut. Cet élément peut apparaître 0 ou plusieurs fois.
vendor Utilisé pour remplacer le vendeur sur une base par action
vendor_url Utilisé pour remplacer l'URL vendeur sur une base par action
icon_name Utilisé pour remplacer le nom de l'icône sur une base par action

   Les éléments localization, description et message peuvent exister 0 ou plusieurs fois avec différents attributs xml:lang

   Pour lister les actions installées, utiliser la commande pkaction

Annotations connues

org.freedesktop.policykit.exec.path est utilisé par le programme pkexec fournis par PolicyKit.
org.freedesktop.policykit.imply (sa valeur est une chaîne contenant une liste séparée par un espace d'identifiants d'action). peut être utilisé pour définir des actions méta. La manière dont elles fonctionnent et que si un sujet est autorisé pour une action spécifiée, il est également autorisé pour toutes les autres action de l'annotation. Une utilisation typique est en définissant un shell avec un simple bouton lock qui devrait débloquer plusieurs actions pour des mécanismes distincts.
org.freedesktop.policykit.owner peut être utilisé pour définir un jeu d'utilisateurs qui peuvent demander si un client est autorisé à effectuer cette action. Si cette annotation n'est pas spécifiée, seul root peut vérifier si un client tournant sous un utilisateur différent est autorisé pour une action. La valeur de cette annotation est une chaîne contenant une liste séparée par des espaces d'entrées PolkitIdentity. par exemple "unix-user:42 unix-user:colord". Une utilisation typique est pour les processus qui tournent sous un utilisateur système au lieu de root.

24 décembre 2016

polkitd

Service PolicyKit

polkitd fournis le service D-Bus org.freedesktop.PolicyKit1 dans le bus de message système. Les utilisateurs ou administrateurs ne devraient jamais avoir besoin de démarrer ce service vu qu'il est démarré par dbus-daemon quand une application appèlent le service.

13 février 2012

reader.conf

reader.conf, reader.conf.d

Fichiers de configuration pour les pilotes des lecteurs pcscd

Syntaxe

Chaque entrée doit être définie par 4 champs:

FRIENDLYNAME Texte arbitraire pour identifier le lecteur. Affiché par la commande pcsc_scan
DEVICENAME (ifdhandler ›= 3.0). Utilisé pour identifier le port physique sur lequel le lecteur est connecté
LIBPATH Nom du fichier du pilote
CHANNELD (ifdhandler ‹ 3.0). Remplacé par DEVICENAME

Exemples

Gemplus lecteur GemPCTwin avec communication série:
FRIENDLYNAME "GemPCTwin serial"
DEVICENAME /dev/ttyS0
LIBPATH /usr/lib/pcsc/drivers/serial/libccidtwin.so.0.4.1
CHANNELID 1

28 mars 2016

restricted-ssh-commands

Restreindre les utilisateurs SSH à un jeu prédéfinis de commandes

restricted-ssh-commands est conçu pour être appelé par SSH pour restreindre un utilisateur à lancer uniquement certaines commandes. Une liste d'expressions régulière permises peuvent être configurés dans /etc/restricted-ssh-commands. La commande demandé doit correspondre à au moins une expression régulière. Sinon elle sera rejetée.

Le paramètre optionnel est le nom du fichier de configuration sous /etc/restricted-ssh-commands à utiliser. Si omis, le nom de l'utilisateur sera utilisé.

Créer un fichier de configuration dans /etc/restricted-ssh-commands/$config et ajouter la ligne suivant dans ~/.ssh/authorized_keys pour l'utiliser:
command="/usr/lib/restricted-ssh-commands",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa [...]

Codes de sortie

124 Le fichier de configuration contient au moins une expression régulière, mais la commande demandée ne matche pas
125 Pas de fichier de configuration ou ne contient pas d'expressions régulière

Exemple

Supposons un dépôt de package Debian sur un hôte en utilisant reprepro pour uploader les paquets. La configuration de package est dans /srv/reprepro, et le fichier de configuration est /etc/restricted-ssh-commands/reprepro contenant les expressions régulières suivante:
^scp -p( -d)? -t( --)? /srv/reprepro/incoming(/[^ /]*)?$
^chmod 0644 /srv/reprepro/incoming/[^ /]*$
^reprepro ( -V)? -b /srv/reprepro processincoming foobar$

10 novembre 2014

rfc2315

Syntaxe des messages cryptographiques

Définitions

Pour ce document, les définitions suivantes s'appliquent:

AlgorithmIdentifier un type qui identifie un algorithme et ses paramètres associés. Ce type est définis dans X.509.
ASN.1 Abstract Syntax Notation One, définis dans X.208
Attribute un type qui contient un type d'attribut et une ou plusieurs valeurs d'attribut. Ce type est définis dans X.501.
BER Basic Encoding Rules, comme définis dans X.209
Certificat un type qui lie un dn d'une entité à une clé publique avec une signature numérique. Ce type est définis dans X.509. Ce type contient également le dn du fournisseur du certificat, un numéro de série, l'algorithme de signature, et une période de validité.
CertificateSerialNumber un type qui identifie de manière unique un certificat avec ceux signés par un fournisseur de certificat particulier. Ce type est définis dans X.509.
CertificateRevocationList un type qui contient des informations sur les certificats dont la validité a été prématurément révoquée par le fournisseur.
DER Distinguished Encoding Rules for ASN.1, comme définis dans X.509
DES Data Encryption Standard, comme définis dans FIPS PUB 46-1
desCBC L'identifiant d'objet pour DES en mode cipher-block chaining
ExtendedCertificate Un type qui consiste d'un certificat X.509 et un jeu d'attributs, signés collectivement par le fournisseur du certificat. Définis dans PKCS#6
MD2 RSA Data Security, incluant l'algorithme MD2. rfc1319
md2 L'identifiant d'objet pour MD2
MD5 RSA Data Security, incluant l'algorithme MD5. rfc1321
md5 L'identifiant d'objet pour MD5
Name Un type qui identifie de manière unique des objets dans un annuaire X.500. Ce type est définis dans X.501. Dans un certificat X.509, le type identifie de fournisseur du certificat et l'entité dont la clé publique est certifiée.
PEM Internet Privacy-Enhanced, comme définis dans rfc1421-1424
RSA Le crypto-système à clé publique RSA
rsaEncryption L'identifiant d'objet pour le chiffrement RSA

Vue générale

   La syntaxe est suffisamment généraliste pour supporter de nombreux types de contenus. Ce document en définis 6: donnée, donnée signée, donnée enveloppée, donnée enveloppée et signée, donnée hashée et donnée chiffrée. D'autres types peuvent être ajoutés dans le future. L'utilisation des types de contenu définis en dehors de ce document est possible, mais est sujet à agrément bilatéral entre les parties échangeant du contenu.

   Ce document exporte un type, ContentInfo, et divers identifiants d'objets.

   Il y a 2 classes de type de contenu: base et amélioré. Les types de contenu dans la classe de base contient seulement les donnée, sans amélioration cryptographique. Présentement, un type de contenu est dans cette classe, le type de contenu donnée. Les types de contenus dans la classe améliorée contiennent le contenu d'un certain type (possiblement chiffré), et d'autre améliorations cryptographique. Par exemple, le contenu donnée enveloppée peut contenir du contenu de données signée, qui peut contenir du contenu donnée. Les 4 type de contenu non données remplissent la classe améliorée. Les types de contenu dans la classe améliorée emploient ainsi l'encapsulation, donnent naissance au termes de contenu extérieur ( celui contenant les améliorations) et de contenu intérieur ( celui qui est amélioré ).

   Le document est conçu de manière à ce que les types de contenus améliorés puissent être préparés dans une simple classe en utilisant un encodage BER de longueur indéfinie. L'opération à une seule passe est spécialement utile si le contenu est stockée sur des cassettes, ou est pipé depuis un autre processus. Un des inconvénients de l'opération simple-passe est qu'il est difficile de sortir un encodé DER en une simple passe, vu que la longueur de divers composants peuvent ne pas être connus à l'avance. Vu que l'encodage DER est requis par les type de contenu donnée signée, donnée signé et enveloppée, donnée hashée, une passe supplémentaire peut être nécessaire quand un type de contenu autre que donnée est le contenu interne de l'un de ces types de contenu.

Types utiles

Les sections suivantes définissent les types qui sont utiles dans au moins 2 endroits dans le document.

CertificateRevocationLists

Le type CertificateRevocationList donne un jeu de listes de révocation de certificat. Il est conçus pour que le jeu d'informations soit suffisant pour déterminer si les certificats avec lequel le jeu est associé est "hot listed" mais il peut y avoir plusieurs listes de révocation que nécessaire, ou moins que nécessaire.

CertificateRevocationLists ::= SET OF CertificateRevocationList

ContentEncryptionAlgorithmIdentifier

Le type ContentEncryptionAlgorithmIdentifier identifie un algorithme de chiffrement de contenu tel que DES. Un algorithme de chiffrement de contenu supporte les opérations de chiffrement et de déchiffrement. L'opération de chiffrement map une chaîne d'octets ( le message ) en une autre chaîne d'octet ( le texte chiffré ) sous le contrôle de la clé de chiffrement de contenu. L'opération de déchiffrement est l'inverse.

ContentEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier

DigestAlgorithmIdentifier

Le type DigestAlgorithmIdentifier identifie un algorithme de hashage, ex. MD2 et MD5. Un algorithme de hashage mappe une chaîne d'octets ( le message ) en une autre chaîne d'octets ( le hash ).

DigestAlgorithmIdentifier ::= AlgorithmIdentifier

DigestEncryptionAlgorithmIdentifier

Le type DigestEncryptionAlgorithmIdentifier identifie un algorithme de chiffrement de hash avec lequel un hash peut être chiffré. Par exemple, rsaEncryption. Un algorithme de chiffrement de hash supporte les opérations de chiffrement et de déchiffrement. L'opération de chiffrement mappe une chaîne d'octets ( le hash ) a une autre chaîne d'octets ( le hash chiffré ) sous le contrôle d'une clé de chiffrement de hash. L'opération de déchiffrement est l'inverse.

DigestEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier

ExtendedCertificateOrCertificate

Le type ExtendedCertificateOrCertificate donne soit un certificat étendu PKCS#6 ou un certificat X.509. Ce type suit la syntaxe recommandée dans PKCS#6:
ExtendedCertificateOrCertificate ::= CHOICE {
certificate Certificate, -- X.509
extendedCertificate [0] IMPLICIT ExtendedCertificate }

ExtendedCertificatesAndCertificates

le type ExtendedCertificatesAndCertificates donne un jeu de certificats étendus et de certificats X.509. Il est conçus pour que le jeu soit suffisant pour contenir des chaînes depuis un "root" ou "top-level certification authority" vers tous les signataires avec lequel le jeu est associé, mais il peut y avoir plus de certificats que nécessaire, ou moins.

ExtendedCertificatesAndCertificates ::= SET OF ExtendedCertificateOrCertificate

IssuerAndSerialNumber

Le type IssuerAndSerialNumber identifie un certificat ( et donc une entité et une clé publique ) par le nom distinct du fournisseur du certificat et un numéro de série spécifique au fournisseur.
IssuerAndSerialNumber ::= SEQUENCE {
issuer Name,
serialNumber CertificateSerialNumber }

KeyEncryptionAlgorithmIdentifier

Le type KeyEncryptionAlgorithmIdentifier identifie un algorithme de chiffrement de clé avec lequel une clé de chiffrement de contenu peut être chiffrée. Ex: rsaEncryption.

KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier

Version

Le type Version donne un numéro de version de syntaxe, pour compatibilité avec de future révisions de ce document.

Syntaxe générale

La syntaxe générale pour le contenu échangé entre les entités en accord avec ce document associe un type de contenu avec le contenu. La syntaxe devrait avoir le ContentInfo en ASN.1:
ContentInfo ::= SEQUENCE {
    contentType ContentType,
    content
    [0] EXPLICIT ANY DEFINED BY contentType OPTIONAL }

ContentType ::= OBJECT IDENTIFIER

contentType Indique le type de contenu. C'est un OID, qui signifie que c'est un chaîne unique assignée par l'autorité qui définis le type de contenu.
content Est le contenu. Ce champ est optionnel, et si non présent, sa valeur attendu doit être fournie par d'autres moyens.

Notes

1. Les méthodes ci-dessous assument que le type de contenu peut être déterminé uniquement par le contentType, donc le type définis avec l'oid ne devrait par être un type CHOICE.
2. Quand une valeur ContentInfo est le contenu interne d'un contenu donnée signée, donnée signée et enveloppée, ou donnée hashée, un algorithme message-digest est appliqué aux octets du contenu encodé DER du champ content. Quand une valeur ContentInfo est le contenu interne d'un contenu donnée enveloppée ou donnée signée et enveloppée, un algorithme de chiffrement de contenu est appliqué aux octets d'un encodé BER à longueur définie du champ.
3. L'omission optionnelle du champ content rend possible la construction de signatures externes, par exemple, sans modification ou réplication du contenu avec lequel la signature s'applique. Dans le cas de signatures externe, le contenu à signer sera omis de la valeur ContentInfo encapsulée interne inclus dans le type de contenu donnée signée.

Type de contenu donnée

Le type de contenu de donnée est conçus pour référer à des chaînes arbitraires d'octets, tel que des fichiers texte ASCII. L'interprétation est laissée à l'application, de telles chaînes n'ont pas besoin d'une structure interne.

Data ::= OCTET STRING

Type de contenu donnée signée

   Le type de contenu donnée signée consiste du contenu d'un type et du hash du contenu pour 0 ou plusieurs signataires. Le hash chiffré pour un signataire est une signature numérique sur le contenu pour ce signataire. Tout type de contenu peut être signé par plusieurs signataires en parallèle. De plus, la syntaxe a un cas dégénéré dans lequel il n'y a pas de signataires sur le contenu. Le cas dégénéré fournis un moyen de diffuser des certificat et des listes de révocation de certificat.

   Il est prévu que l'application typique du type de contenu donnée signée représente la signature numérique d'un signataire sur le contenu du type de contenu donnée. Une autre application typique est de diffuser des certificat et des listes de révocation de certificat.

  Le processus par lequel la donnée signée est construite se fait par les étapes suivantes:

1. Pour chaque signataire, un message digest est calculé sur le contenu avec un algorithme de hashage spécifique au signataire. ( Si 2 signataires emploient le même algorithme, le hash doit alors être calculé pour seulement un d'entre eux). Si le signataire authentifie une information autre que le contenu, le hash du contenu et l'autre information sont hashé avec l'algorithme de hashage du signataire, et le résultat devient le hash.
2. Pour chaque signataire, le hash et d'autres informations associées sont chiffrées avec la clé privé du signataire.
3. Pour chaque signataire, le hash chiffré et d'autres informations spécifiques au signataire sont collectés dans une valeur SignerInfo. Les certificats et les listes de révocation de certificat pour chaque signataire, et ceux ne correspondant pas à un signataire, sont collectés dans cette étape.
4. Les algorithme de hashage pour tous les signataires et les valeur SignerInfo pour tous les signataires sont collectés ensemble avec le contenu dans une valeur SignedData.

   Un destinataire vérifie les signatures en déchiffrant le hash chiffré pour chaque signataire avec la clé publique du signataire, puis compare le hash récupéré avec un hash calculé indépendamment. La clé publique du signataire est soit contenue dans un certificat inclus dans l'information du signataire, soit est référencée par un nom de fournisseur et un numéro de série spécifique au fournisseur qui identifie de manière unique le certificat pour la clé publique.

   Cette section est divisée en 5 parties. La première décrit le type SignedData, la seconde décrit le type SignerInfo, la troisième et quatrième décrivent le hashage, et la dernière section est un sommaire de la compatibilité avec PEM.

type SignedData

Le type de contenu donnée signée devrait avec le type ASN.1:
SignedData ::= SEQUENCE {
    version Version,
    digestAlgorithms DigestAlgorithmIdentifiers,
    contentInfo ContentInfo,
    certificates
        [0] IMPLICIT ExtendedCertificatesAndCertificates OPTIONAL,
    crls
        [1] IMPLICIT CertificateRevocationLists OPTIONAL,
    signerInfos SignerInfos }

DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier

SignerInfos ::= SET OF SignerInfo

version Est le numéro de version de syntaxe. Devrait être à 1 pour cette version du document.
digestAlgorithms Est une collection d'identifiant d'algorithme de hashage. Il peut y avoir plusieurs élément dans la collection, incluant 0. Chaque élément identifie l'algorithme de hashage ( et ses paramètres associés ) sous lequel le contenu est hashé pour un signataire. La collection est conçue pour lister les algorithmes de hashage employés par tous les signataires, dans n'importe quel ordre, pour faciliter la vérification la vérification de signature en une passe.
contentInfo Est le contenu qui est signé. Il peut avoir n'importe quel type de contenu défini.
certificates Est le jeu de certificat étendu PKCS#6 et de certificats X.509. Il est prévu que le jeu soit suffisant pour contenir des chaînes depuis un root reconnus pour tous les signataires dans le champ signerInfos. Il peut y avoir plus de certificats que nécessaire, et il peut y avoir les certificats suffisants pour contenir les chaînes depuis 2 ou plusieurs autorité racine indépendants. Il peut également y avoir moins de certificats que nécessaire, s'il est prévu que la vérification des signatures aient un moyen alternatif.
clrs Est un jou de liste de révocation de certificats. Il est prévus que le jeu contienne des informations suffisantes pou déterminer si les certificats dans le champ certificates sont listés ou non, mais une telle correspondance n'est pas nécessaire. Il peut y avoir plus d'un liste de révocation que nécessaire, et il peut y en avoir moins que nécessaire.
signerInfos Est une collection d'information par signataire. Il peut y avoir plusieurs élément dans la collection, ou aucun.

notes

Le padding peut être supprimé de manière non-ambigu vu que toute l'entrée est remplie et qu'aucune chaîne de padding n'est un suffixe d'un autre. Cette méthode est définie si et seulement si k ‹ 256; les méthodes pour k supérieur sont un problème.

Processus de chiffrement de clé

L'entrée du processus de chiffrement de clé - la valeur fournie à l'algorithme de chiffrement de clé du destinataire - est simplement la valeur de la clé de chiffrement de contenu.

Type de contenu donnée signée et enveloppée

   Cette section définis le type de contenu donnée signée et enveloppée. Pour faire court, le principal de cette section sont exprimée en terme des 2 sections précédentes.

   Le type de contenu donnée signée et enveloppée consiste d'un contenu chiffré de n'importe quel type, des clés de chiffrement de contenu chiffré pour un ou plusieurs destinataires, et du hash doublement chiffrés pour un ou plusieurs signataires. Le double chiffrement consiste d'un chiffrement avec la clé privée du signataire suivi par un chiffrement avec la clé de chiffrement de contenu.

   La combinaison du contenu chiffré et de la clé de chiffrement de contenu chiffré pour un destinataire est une enveloppe numérique pour ce destinataire. Le hash chiffré récupéré pour un signataire est une signature numérique sur le contenu récupéré pour ce signataire. Tout tupe de contenu peut être enveloppé pour des destinataire et signé par des signataire en parallèle.

   Il est prévu que l'application typique d'un type de contenu donnée enveloppée et signée est de représenter la signature numérique d'un signataire et une ou plusieurs enveloppe numérique d'un ou plusieurs destinataires dans le contenu du type de contenu donnée. Le processus pour signer et envelopper est construit selon les étapes suivantes:

1. Une clé de chiffrement pour un algorithme de chiffrement de contenu particulier est généré aléatoirement.
2. Pour chaque destinataire, la clé de chiffrement de contenu est chiffrée avec la clé publique du destinataire
3. Pour chaque destinataire, la clé de chiffrement de contenu chiffrée et d'autres informations spécifiques au destinataire sont collectés dans une valeur RecipientInfo.
4. Pour chaque signataire, un hash est calculé sur le contenu avec un algorithme de hash spécifique au signataire. ( si 2 signataires emploient le même algorithme de hash, le hash doit être calculé une seule fois ).
5. Pour chaque signataire, le hash est les informations associées sont chiffrées avec la clé privée du signataire, et le résultat est chiffré avec la clé de chiffrement de contenu. ( le deuxième chiffrement peut nécessiter que le résultat du premier chiffrement soit padded à un multiple d'un taille de block)
6. Pour chaque signataire, le hash et les informations spécifique doublement chiffrés sont collecté dans une valeur SignerInfo.
7. Le contenu est chiffré avec la clé de chiffrement de contenu.
8. Les algorithmes de hash pour tous les signataires, les valeurs SignerInfo pour tous les signataires et les valeurs RecipientInfo pour tous les destinataires sont collecté ensemble avec le contenu chiffré dans une valeur SignedAndEnvelopedData.

   Un destinataire ouvre les enveloppes et vérifie les signature en 2 étapes. D'abord, celle contenant les clé de chiffrement de contenu est déchiffrée avec la clé privée du destinataire, et le contenu chiffré est déchiffré avec la clé de chiffrement de contenu récupéré. Ensuite, le hash doublement chiffré pour chaque signataire est déchiffré avec la clé de chiffrement de contenu récupérée, le résultat est déchiffré avec la clé publique du signataire et le hash récupéré est comparé avec un hash calculé indépendemment.

   Cette section est divisée en 3 parties. La première décris le type SignedAndEnvelopedData et la deuxième décris le processus de chiffrement. Les autres types et processus sont les même que dans les sections précédente. La troisième partie est un sommaire de compatibilité avec PEM.

   Note: Le type de contenu donnée signée et enveloppée fournis un amélioration cryptographique similaire à celui résultant d'un combinaison séquentielle des type de contenu donnée signée et donnée enveloppée. Cependant, vu que le type de contenu donnée signée et enveloppée n'a pas d'attributs authentifié ou non-authentifié, ni ne fournis d'enveloppe pour les information de signataire autre que la signature, la combinaison séquentielle est généralement préférable au contenu SignedAndEnvelopedData. Excepté quand la compatibilité avec le type de processus ENCRYPTED dans PEM est recherché.

Type SignedAndEnvelopedData

Le type de contenu donnée signée et enveloppée devrait avoir le type ASN.1:
SignedAndEnvelopedData ::= SEQUENCE {
    version Version,
    recipientInfos RecipientInfos,
    digestAlgorithms DigestAlgorithmIdentifiers,
    encryptedContentInfo EncryptedContentInfo,
    certificates
        [0] IMPLICIT ExtendedCertificatesAndCertificates
            OPTIONAL,
    crls
        [1] IMPLICIT CertificateRevocationLists OPTIONAL,
    signerInfos SignerInfos }

version Est le numéro de version de syntaxe. Il devrait être 0 pour cette version du document
recipientInfos Est une collection d'information par destinataires. Il doit y avoir au moins un élément dans la collection
digestAlgorithms Est une collection d'identifiants d'algorithme de hashage.
encryptedContentInfo Est le contenu chiffré. Il peut avoir tout type de contenu
certificates Est un jeu de certificats PKCS#6 et de certificats X.509
crls Est un jeu de listes de révocation de certificat
signerInfos Est une collection d'information par signataire. Il doit y avoir au moins un élément dans la collection.

Notes

1. Le fait que les champs recipientInfos et digestAlgorithms soient avant les champs contentInfo et signerInfos rend possible de traiter un valeur SignedAndEnvelopedData en une passe.
2. La différence entre les version 0 et 1 de SignedAndEnvelopedData est que le champ crls est permis dans la version 1, mais pas dans la version 0.

Processus de chiffrement de hash

L'entrée du processus de chiffrement est la même que pour processus de chiffrement de hash, mais le processus lui-même est différent. Spécifiquement, le processus à 2 étapes. D'abord, l'entrée est fournie à l'algorithme de chiffrement de hash du signataire. Ensuite, le résultat est chiffré avec la clé de chiffrement de contenu. Il n'y a pas d'encodage DER entre les 2 étapes; la valeur de sortie de la première étape est entrée directement dans la seconde étape. Ce processus est compatible avec le processus ENCRYPTED dans PEM.

Note: Le but de la seconde étape est d'empêcher un adversaire de récupérer le hash du contenu. Sinon, un adversaire sera capable de déterminer qui d'une liste de contenus candidats est le contenu actuel en comparant leur hash.

Compatibilité avec PEM

La compatibilité avec le type de processus ENCRYPTED de PEM se produit quand le type de contenu de la valeur ContentInfo à signer et envelopper est une donnée, l'algorithme de hash est md2 ou md5, l'algorithme de chiffrement est DES en mode CBC, l'algorithme de chiffrement de hash est rsaEncryption, et l'algorithme de chiffrement de clé est rsaEncryption. Sous toutes ces conditions, le hash doublement chiffré et la clé de chiffrement de contenu chiffré matchent celui produit dans PEM parce que les raisons données plus haut sont similaires aussi bien que les suivantes:

1. La valeur d'entrée de l'algorithme de chiffrement de contenu dans PEM est la même que dans ce document. DES en mode CBC est le même que desCBC.
2. La valeur d'entrée de l'algorithme de chiffrement de clé dans PEM est la même que dans ce document. RSA dans PEM est le même que rsaEncryption.
3. Le processus de double chiffrement appliqué au hash dans ce document et dans PEM sont les même

Les autres parties du type de contenu donnée signée et enveloppée ( certificates, CRLs, algorithm identifiers, etc. ) sont facilement transposables depuis et vers leur composant PEM.

Type de contenu donnée hashé

   Le type de contenu donnée hashée consiste du contenu de n'importe quel type et un hash du contenu. Il est prévu que l'application typique du type de contenu donnée hashée est d'ajouter l'intégrité du contenu d'entrée au type de contenu donnée enveloppée. Le processus par lequel une donnée hashée est construite est constituée des étapes suivantes:

1. Un hash est calculé sur le contenu avec un algorithme de hashage
2. L'algorithme de hashage est le hash sont collecté ensemble avec le contenu dans une valeur DigestedData.

   Un destinataire vérifie le hash en comparant ce hash avec un hash calculé indépendamment.

Le type de contenu donnée hashée devrait avoir le type ASN.1:
DigestedData ::= SEQUENCE {
    version Version,
    digestAlgorithm DigestAlgorithmIdentifier,
    contentInfo ContentInfo,
    digest Digest }

Digest ::= OCTET STRING

version Est le numéro de version de syntaxe. Il devrait être 0 pour cette version du document
digestAlgorithm Identifie l'algorithme de hashage et ses paramètres associés avec lequel le contenu est hashé.
contentInfo Est le contenu qui est hashé
digest Est le résulta du processus de hashage

   Note: Le fait que le champ digestAlgorithm vient avant le champ contentInfo est le champ digest vient aprés rend possible le traitement d'une valeur DigestedData en une seule passe.

Type de contenu donnée chiffrée

   Le type de contenu donnée chiffrée consiste d'un contenu chiffré de n'importe quel type. À la différence du type de contenu donnée enveloppée, le type de contenu donnée chiffrée n'a ni destinataire ni clé de chiffrement de contenu. Les clé sont supposés être gérées par d'autres moyens.

   Il est prévu que l'application typique du type de contenu donnée chiffrée est de chiffrer le contenu du type de contenu donnée pour stochage local, où la clé de chiffrement peut être un mot de passe.

Le type de contenu donnée chiffrée devrait avoir le type ASN.1:
EncryptedData ::= SEQUENCE {
    version Version,
    encryptedContentInfo EncryptedContentInfo }

version Est le numéro de version de syntaxe. Il devrait être 0 pour cette version du document
encryptedContentInfo contient les information sur le contenu chiffré

Object Identifiers

   Ce document définis 7 identifiant d'objet: pkcs-7, data, signedData, envelopedData, signedAndEnvelopedData, digestedData, et encryptedData.

L'identifiant d'objet pkcs-7 identifie ce document
pkcs-7 OBJECT IDENTIFIER ::=
    { iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1) 7 }

Les OID data, signedData, envelopedData, signedAndEnvelopedData, digestedData, et encryptedData, identifient, respectivement, les type de contenu donnée, donnée signée, donnée enveloppée, donnée signée et enveloppée, donnée hashée et donnée chiffrée.
data OBJECT IDENTIFIER ::= { pkcs-7 1 }
    signedData OBJECT IDENTIFIER ::= { pkcs-7 2 }
    envelopedData OBJECT IDENTIFIER ::= { pkcs-7 3 }
    signedAndEnvelopedData OBJECT IDENTIFIER ::= { pkcs-7 4 }
    digestedData OBJECT IDENTIFIER ::= { pkcs-7 5 }
    encryptedData OBJECT IDENTIFIER ::= { pkcs-7 6 }

   Ces OID sont prévus pour être utilisé dans le champ contentType d'une valeur de type ContentInfo.

07 juillet 2016

rfc3161

rfc3161, rfc5816

PKIX Time-Stamp Protocol

   Un service d'horodatage supporte la preuve qu'une donnée existait à une date donnée. Un TSA peut être opéré par un Tiers de confiance (TTP - Trusted Third Party), bien que d'autres modèles opérationels peuvent être appropriés, par ex, une organisation peut exiger un TSA pour de l'horodatage interne.

   Les services de non-répudiation exigent la capacité d'établir l'existence d'une donnée avant une date spécifiée. Ce protocole peut être utilisé comme bloque de construction de tels services.

   Pour associer une donnée avec un point dans le temps, une autorité d'horodatage (TSA) peut être utilisé. Ce tiers de confiance fournis une preuve d'existence pour cette donnée particulière à une point dans le temps.

   Le rôle du TSA est de dater une donnée pour établir l'évidence indiquant qu'une donnée existait avant une date particulière. Cela peut être utilisé, par exemple, pour vérifier qu'une signature numérique a été appliquée à un message avant que le certificat correspondant n'ait été révoqué, permettant à une clé publique révoquée d'être utilisé pour vérifier la signature créé avant la date de révocation. C'est une opération PKI importante. Le TSA peut également être utilisé pour indiquer la date d'émission quand une deadline est critique, ou pour indiquer la date de transaction pour les entrées dans un log.

Le TSA

Le TSA est un TTP qui créé des jetons d'horodatage pour indiquer qu'une donnée a existé à un point dans le temps particulier. Pour le reste du document, une "requête valide" signifie une requête que peut être décodée correctement.

Pre-requis du TSA

Le TSA doit:

- Utiliser une source de temps fiable pour chaque jeton d'horodatage
- Inclure une date fiable pour chaque jeton d'horodatage
- Inclure un entier unique pour chaque jeton d'horodatage généré
- produire un jeton d'horodatage une fois reçu une requête valide, si possible
- Inclure dans chaque jeton d'horodatage un identifiant pour indiquer de manière unique la stratégie de sécurité sous laquelle le jeton a été créé.
- horodater seulement une représentation hashée des données
- examiner l'OID d'une fonction de hash résistante aux collisions et vérifier que la longueur du hash est consistante avec l'algorithme
- Ne pas example l'empreinte à horodater de toute autre manière
- Ne pas inclure d'identification de l'identité demandeur dans les jetons d'horodatage
- Signer chaque jeton d'horodatage en utilisant une clé générée exclusivement dans ce but et avoir cette propriété de clé indiquée dans le certificat correspondant.
- Inclure les informations additionnelles dans le jeton d'horodatage, si demandé en utilisant le champs extensions, seulement pour les extensions qui sont supportés par le TSA. Si ce n'est pas possible, le TSA doit répondre avec un message d'erreur.

Transactions TSA

   Comme premier message de ce mécanisme, l'entité demande un jeton d'horodatage via une requête (qui est ou inclus un TimeStampReq) au TSA. Comme second message, le TSA répond en envoyant une réponse (qui est ou inclus un TimeStampResp) à l'entité.

   Une fois reçu la réponse ( qui est ou inclus un TimeStampResp qui contient normalement un TimeStampToken (TST) ), l'entité doit vérifier le status retourné dans la réponse et en l'absence d'erreur il doit vérifier les divers champs contenus dans le TimeStampToken et la validité de la signature numérique du TimeStampToken. En particulier, il doit vérifier que l'horodatage correspond à ce qui était demandé. Le demandeur doit vérifier que le TimeStampToken contient l'identifiant de certificat correcte du TSA, l'empreinte des données correcte, et l'OID de l'algorithme de hashage correcte. Il doit ensuite vérifier le délai de la réponse en vérifiant soit la date incluse dans la réponse avec une source de temp locale fiable de référence, si disponible, ou la valeur du nonce (un grand nombre aléatoire avec une grande probabilité qu'il a été généré par le client seulement une seule fois) inclus dans la réponse avec la valeur inclus dans la demande. Si une de ces vérification échoue, le TimeStampToken doit être rejeté.

   Ensuite, le certificat du TSA peut avoir été révoqué, le status du certificat doivrait être vérifié pour s'assurer que le certificat est valide.

   Ensuite, l'application cliente devrait vérifie le champ policy pour déterminer si la stratégie sous laquelle le jeton a été émis est acceptable pour l'application.

Identification du TSA

   Le TSA doit signer chaque message avec une clé réservée spécifiquement dans ce but. Un TSA peut avoir des clé privées distincts, par ex, pour gérer différentes stratégie, différents algorithmes, différentes tailles de clé ou pour augmenter les performances. Le certificat correspondant doit contenir seulement une instance du champ d'utilisation de clé avec KeyPurposeIP ayant la valeur: id-kp-timeStamping. Cette extension doit être critique.

L'identifiant d'objet suivant identifie le KeyPurposeIP ayant la valeur id-kp-timeStamping
id-kp-timeStamping OBJECT IDENTIFIER ::= {iso(1)
        identified-organization(3) dod(6)
        internet(1) security(5) mechanisms(5) pkix(7)
        kp (3) timestamping (8)}

Format des requêtes

Une requête time-stamping est comme suit:
TimeStampReq ::= SEQUENCE {
    version INTEGER { v1(1) },
    messageImprint MessageImprint,
        --Un OID d'algorithme de hash et la valeur du hash des donnée à horodater
    reqPolicy TSAPolicyId OPTIONAL,
    nonce INTEGER OPTIONAL,
    certReq BOOLEAN DEFAULT FALSE,
    extensions [0] IMPLICIT Extensions OPTIONAL }

   Le champ version (actuellement v1) décris la version de la demande d'horodatage.

Le champ messageImprint devrait contenir le hash des données à horodater. Le hash est représenté comme chaîne d'octets. Sa longueur doit correspondre à la longueur de la valeur du hash pour cet algorithme. (20 octets pour SHA1, 16 pour MD5).
MessageImprint ::= SEQUENCE {
    hashAlgorithm AlgorithmIdentifier,
    hashedMessage OCTET STRING }

   L'algorithme de hashage indiqué dans le champ hashAlgoritm devrait être un algorithme de hashage connu. Cela signifie qu'il doit être one-way et résistant aux collisions. Le TSA devrait vérifier si l'algorithme de hashage donné est connu pour être suffisant. Si le TSA ne reconnait pas l'algorithme de hashe ou sait qu'il est faible, le TSA devrait refuser de fournir le jeton d'horodatage en retournant un pkiStatusInfo de 'bad_alg'.

   Le champ reqPolicy, si inclus, indique la stratégie TSA sous laquelle le TimeStampTocke devrait être fournis. TSAPolicyId est définis comme suit: TSAPolicyId ::= OBJECT IDENTIFIER

   Le nonce, si inclus, permet au client de vérifier la date de la réponse quand aucune horloge locale n'est disponible. Le nonce est un grand nombre aléatoire avec une forte probabilité que le client l'a généré seulement une seule fois. Dans ce cas la même valeur nonce doit être incluse dans la réponse, sinon la réponse doit être rejetée.

   Si le champ certReq est présent et à true, le certificat du TSA qui est référencé par l'identifiant ESSCertID dans un attribut SigningCertificate ou ESSCertIDv2 dans la réponse doit être fournie par le TSA dans le champ certificates de la structure SignedData dans cette réponse. Ce champ peut également contenir d'autres certificats.

   Si le champ certReq est manquant ou s'est est présent est à false, le champ certificates ne doit pas être présent dans la réponse.

   Le champ extensions est un manière générique d'ajouter des informations additionnelles aux requêtes dans le future. Les extensions sont définies dans la rfc2459. Si une extension, qu'elle soit marquée critique ou non, est utilisée par un demandeur mais non reconnue par le TSA, le serveur ne doit pas émettre de jeton et doit retourner une erreur (unacceptedExtension)

   La requête d'horodatage ne doit pas identifier le demandeur, vu que cette information n'est pas validée par le TSA. Dans les situations où le TSA exige l'identité du demandeur, une identification/authentification alternative doit être mise en place.

Format de réponse

Une réponse d'horodatage est comme suit:
TimeStampResp ::= SEQUENCE {
    status PKIStatusInfo,
    timeStampToken TimeStampToken OPTIONAL }

Le status est basé sur la définition des status dans la rfc2510 comme suit:
PKIStatusInfo ::= SEQUENCE {
    status PKIStatus,
    statusString PKIFreeText OPTIONAL,
    failInfo PKIFailureInfo OPTIONAL }

Quand le status contient la valeur 0 ou 1, un TimeStampToken doit être présent. Quand le status contient une autre valeur, un TimeStampToken ne doit pas être présent. Une des valeurs suivantes doit être contenus dans le status:
PKIStatus ::= INTEGER {
    granted (0),
    grantedWithMods (1),
    rejection (2),
    waiting (3),
    revocationWarning (4), // indique une révocation imminente
    revocationNotification (5) // indique une révocation

   Les serveurs conformes ne doivent pas produire d'autres valeur. Les clients conforme doivent générer une erreur si des valeurs qu'il ne comprend pas sont présents.

Quand le TimeStampToken n'est pas présent, failInfo indique la raison du rejet de le requête et peut être une des valeurs suivantes:
PKIFailureInfo ::= BIT STRING {
    badAlg (0), -- identifiant d'algorithme non supporté ou inconnu
    badRequest (2), -- transaction non permise ou non supportée
    badDataFormat (5), -- Mauvais format de données transmises
    timeNotAvailable (14), -- Source de temps du TSA non disponible
    unacceptedPolicy (15), -- La stratégie TSA demandée n'est pas supportée par le TSA
    unacceptedExtension (16), -- extension non supportée par le TSA
    addInfoNotAvailable (17), -- Les informations additionnelles demandées ne sont pas comprises ou non disponible
    systemFailure (25) -- La requête ne peut pas être gérée à cause d'une erreur système
}

   Ce sont les seules valeurs de PKIFailureInfo qui doivent être supportées.

   Les serveurs conformes ne doivent pas produire d'autres valeurs. Les clients conformes doivent générer une erreur si des valeurs qu'il ne comprend pas sont présents.

   Le champ statusString de PKIStatusInfo peut être utilisé pour inclure un texte de raison.

Un TimeStampToken est comme suit. Il est définis comme ContentInfo et doit encapsuler un type de contenu de données signée.
TimeStampToken ::= ContentInfo
    -- contentType is id-signedData ([CMS])
    -- content is SignedData ([CMS])

   Les champs de type EncapsulatedContentInfo de la construction SignedData ont la signification suivante:

eContentType est un identifiant d'objet qui spécifie uniquement le type de contenu. Pour un jeton d'horodatage il est définis comme suit:
id-ct-TSTInfo OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) ct(1) 4}

   eContent est le contenu, un chaîne d'octet, un TSTInfo encodé DER.

Le jeton d'horodatage ne doit pas contenir de signature autre que la signature du TSA. L'identifiant de certificat (ESSCertID ou ESSCertIDv2) du certificat TSA doit être inclus comme attribut signerInfo dans l'attribut SigningCertificate.
TSTInfo ::= SEQUENCE {
    version INTEGER { v1(1) },
    policy TSAPolicyId,
    messageImprint MessageImprint,
        -- doit avoir la même valeur que le champ similaire dans TimeStampReq
    serialNumber INTEGER,
    genTime GeneralizedTime,
    accuracy Accuracy OPTIONAL,
    ordering BOOLEAN DEFAULT FALSE,
    nonce INTEGER OPTIONAL,
        -- Doit être présent si le champ similaire est présent dans TimeStampReq, et doit avoir la même valeur
    tsa [0] GeneralName OPTIONAL,
    extensions [1] IMPLICIT Extensions OPTIONAL }

   Le champ version (v1) décris la version du jeton d'horodatage. Les serveurs conformes doivent être capable de fournir des jetons version 1.

   Parmis les champs optionnels, seul nonce doit être supporté. Les demandeurs conforme doivent être capable de reconnaitre les jeton d'horodatage version 1 avec tous les champs optionnels présents, mais ne sont pas obligés de comprendre les sémantiques des extensions. si présent.

   Le champ policy doit indiquer la stratégie TSA sous laquelle la réponse a été produite. Si un champ similaire est présent dans TimeStampReq, il doit avoir la même valeur, sinon une erreur unacceptedPolicy doit être retournée. Cett stratégie peut inclure les types d'information suivantes (bien que cette liste n'est certainement pas exhaustive):

- Les condition sous lesquels le jeton peut être uilisé
- La disponibilité de log de jeton d'horodatage, pour permettre une vérification ultérieur de l'authenticité du jeton.

   Le messageImprint doit avoir la même valeur que le champ similaire dans le TimeStampReq, indiquant que la taille de la valeur du hash matche la taille attendue de l'algorithme de hashage identifié dans hashAlgorithm.

   Le champ serialNumber est un entier assigné par le TSA pour chaque TimeStampTocken. Il doit être unique pour chaque TimeStampToken émis par un TSA donné.

   genTime est la date à laquelle le jeton a été créé par le TSA. Il est exprimé en temp UTC pour réduire la confusion avec le timezone local. UTC est une échelle de temp, basée sur le secon (SI), comme définis et recommandé par le CCIR, et maintenu par le Bureau International des Poids et Mesures (BIPM). Un synonime est le temp "Zulu" qui est utilisé par l'aviation civile et représentée par la lettre Z.

accuracy représent la déviation de temp autour du temps UTC contenus dans GeneralizedTime.
Accuracy ::= SEQUENCE {
    seconds INTEGER OPTIONAL,
    millis [0] INTEGER (1..999) OPTIONAL,
    micros [1] INTEGER (1..999) OPTIONAL }

   Si un des éléments est manquant, la valeur est considéré comme 0. En ajoutant la valeur accuracy dans le GeneralizedTime, une limite supérieur du temp auquel le jeton d'horodatage a été créé par la TSA peut être obteni. De la même manière, en soustrayant l'accuracy au GeneralizedTime, une limite inférieur du temp auquel le jeton a été créé par le TSA peut être obtenu.

   Si le champ ordering est manquant, ou s'il est présent et mis à false, le champ genTime indique seulement le temp auquel le jeton a été créé par le TSA. Dans un tel cas, l'ordre des jetons d'horodatage émis par le même TSA ou différents TSA est seulement possible quand la différence entre le genTime du premier jeton et le genTime du second jeton est supérieur à la somme des accuracy du genTime pour chaque jeton.

   Si le champ ordering est présent et à true, tout jeton du même TSA peut toujours être ordonné basé sur le champ genTime, sans regarder l'accuracy GenTime.

   Le champ nonce doit être présent s'il est présent dans le TimeStampReq. Dans ce cas, il doit être recopié dans la structure TimeStampReq.

   Le but du champ tsa est de donner une indication pour identifier le nom du TSA. Si présent, il doit correspondre à un des nom de sujet inclus dans le certificat qui est utilisé pour vérifier le jeton. Cependant, l'identification de l'entité qui a signé la réponse se produit toujours via l'utilisation de l'identifiant de certificat (ESSCertID) dans l'attribut SigningCertificate ou ESSCertIDv2 dans l'attribut SigningCertificateV2 qui fait partie du signerInfo.

   Les extensions sont une manière générique d'ajouter des informations additionnelles dans le future.

Transports

Il n'y a pas de mécanisme de transport obligatoire pour les messages TSA dans ce document. Les mécanismes décris ci-dessous sont optionnels, d'autres mécanisme pouvant être définis dans le future.

E-mail

Cette section spécifie un moyen de transporter des messages encodés ASN.1 pour l'échange de protocole via les mails. 2 objets MIME sont spécifiés comme suit:
Content-Type: application/timestamp-query
Content-Transfer-Encoding: base64
‹‹the ASN.1 DER-encoded Time-Stamp message, base64-encoded››

Content-Type: application/timestamp-reply
Content-Transfer-Encoding: base64
‹‹the ASN.1 DER-encoded Time-Stamp message, base64-encoded››

Ces objets MIME peuvent être respectivement envoyés et reçus en utilisant les moteurs de traitement MIME qui fournissent un simple transport par mail des messages d'horodatage.

Pour les types MIME application/timestamp-query et application/timestamp-reply, les implémentations devraient inclure les paramètres optionnels "name" et "filename". Inclure un nom de fichier aide à préserver le type d'information quand les requêtes et réponses d'horodatage sont sauvées en tant que fichier. Quand ces paramètres sont inclus, un nom de fihier avec l'extension approprié devrait être sélectionné:
______MIME Type_____________________File Extension
application/timestamp-query____________.TSQ
application/timestamp-reply____________.TSR

Fichier

Un fichier contenant un message timestamp doit contenir seulement l'encodé DER d'un message TSA. De tels fichiers peuvent être utilisé pour transporter les messages timestamp en utiisant ftp par exemple.

Une requête timestamp devrait être contenue dans un fichier avec l'extension .tsq, et une réponse devrait être contenue dans un fichier avec l'extension .tsr

Socket

   Le protocole suivant basé sur TCP est utilisé pour transporter les messages TSA. Ce protocole est utilisable pour les cas où une entité initie une transaction et peut demander un résultat. Le protocole assume qu'un processus d'écoute dans un TSA peut accepter les messages TSA sur un port définis (318).

   Généralement un initiateur lie ce port et envoie le message TSA initiale. Le répondeur répond avec un message TSA et/ou avec un numéro de référence à utiliser ultérieurement pour demander la réponse.

   L'initiateur d'une transaction envoie un "direct TCP-based TSA message" au destinataire. Le destinataire répond avec un message similaire. Un "direct TCP-based TSA message" consiste de: length (32-bits), flag (8-bits), value (defined below)

Le champ longueur contient le nombre d'octets du reste du message. Toutse les valeurs 32bits dans ce protocole sont spécifiés pour être dans l'ordre d'octet réseaux
Message name flag value
tsaMsg '00'H DER-encoded TSA message -- message TSA
pollRep '01'H polling reference (32 bits),
                    time-to-check-back (32 bits)
                    -- Réponse quand aucun message TSA n'est prête. Utilise la valeur polling reference (et la valeur de date estimée) pour la demande ultérieur.
pollReq '02'H polling reference (32 bits)
                    -- demande d'une réponse TSA pour le message initial
negPollRep '03'H '00'H
                     pas d'autre réponses ultérieur (ex: transaction complète)
partialMsgRep '04'H next polling reference (32 bits),
                    time-to-check-back (32 bits),
                    DER-encoded TSA message
                    -- réponse partielle du message initial plus une nouvelle référence d'attente à utilise pour obtenir la prochaine partie de la réponse
finalMsgRep '05'H DER-encoded TSA message
                    -- réponse finale du message initial
errorMsgRep '06'H human readable error message
                    -- produit quand une erreur est détectée

   La séquence des messages qui se produit est:

a) L'entité envoie tsaMsg et reçoit un pollRep, negPollRep, partialMsgRep, ou finalMsgRep dans la réponse.
b) L'entité envoie un message pollReq et reçois negPollRep, partialMsgRep, finalMsgRep, ou errorMsgRep dans la réponse

HTTP

2 objets MIME sont spécifiés comme suit:
Content-Type: application/timestamp-query

    ‹‹the ASN.1 DER-encoded Time-Stamp Request message››

Content-Type: application/timestamp-reply

    ‹‹the ASN.1 DER-encoded Time-Stamp Response message››

   Ces 2 objets MIME peuvent être envoyés et reçus en utilisant un moteur de traitement HTTP sur des liens WWW et fournis un transport simple via navigateur internet. Une fois un requête valide reçue, le serveur doit répondre avec soit une réponse valide avec le type application/timestamp-response, ou avec une erreur HTTP.

Considérations de sécurité

   Tout le document est concerné par les considérations de sécurité. En concevant un service TSA, les considérations suivantes ont été identifiées comme ayant un impacte sur la validité ou la confiance dans le jeton d'horodatage.

   1. Quand un TSA ne doit plus être utilisé, mais la clé privée TSA n'a pas été compromise, le certificat de l'autorité doit être révoqué. Quand l'extension reasonCode relatif au certificat révoqué du TSA est présent dans les extensions d'entrée de CRL, il doit être mis soit à unspecified, affiliationChanged, superseded ou cessationOfOperation. Dans ce cas, les jetons signés avec la clé correspondante seront considérés comme invalides, mais les jetons générés avant la date de révocation resteront valides. Quand l'extension reasonCode n'est pas présent dans la CRL, tous les jetons qui ont été signés avec la clé correspondante doivent être considérés comme invalides. Pour cette raison, il est recommandé d'utiliser l'extension reasonCode.

   2. Quand la clé privée TSA a été compromise, le certificat correspondant doit être révoqué. Dans ce cas, l'extension reasonCode peut être présent et dans ce cas doit être à keyCompromise. Tout jeton signé par le TSA utilisant cette clé privée ne peuvent plus être validés. Pour cette raison, il est impératif que la clé privée du TSA soit conservé en lieu sûr et contrôlé pour minimiser la possibilité d'être compromise. Dans le cas où la clé privée est compromise, un audit de tous les jetons générés par le TSA peut fournir un moyen de discriminer les jetons. 2 jetons d'horodatage de 2 TSA différents est une autre manière d'adresser ce problème.

   3. La clé de signature TSA doit être suffisamment longue pour une durée de vie confortable. Même si c'est le cas, la clé a une durée de vie définie. Donc, tout jeton signé par le TSA devrait être horodatées de nouveau (si des copies authentique des anciennes CRL sont disponibles) ou notarisé (s'il elle ne le sont pas) à une date ultérieur pour renouveler la confiance qui existe dans la signature du TSA. Les jetons d'horodatage peuvent également être conservés avec un "Evidence Recording Authority" pour maintenir ce trust.

   4. Une application client utilisant seulement un nonce et sans horloge locale devrait être concerné par la quantité de temp qu'il est prêt à attendre la réponse. Une attaque MITM peut introduire un délai. Donc, un TimeStampResp qui prend trop de temp devrait être considéré comme suspect. Vu que chaque méthode de transport spécifié dans ce document a différentes caractéristiques de délai, la durée considérée acceptable dépend du transport utilisé, ainsi que les facteurs environnementaux.

   5. Si différentes entités obtiennent des jetons d'horodatage sur le même objet en utilisant le même algorithme de hashage, ou une simple entité obtient plusieurs jetons sur le même objet, les jetons générés incluent le même message; en résultat, un observateur avec accès à ces jetons peut en déduire que l'horodatage réfère aux même données.

   6. Le replays délibérés ou par inadvertance pour les demandes incorporant le même algorithme de hashage et de valeur peut se produire. Les replays par inadvertance se produisent quand plus d'une copie de la même requête est envoyée au TSA à cause de problèmes réseau. Les replays délibérés se produisent via MITM. Pour détecter ces situations, de nombreuses techniques peuvent être utilisé. Utiliser un nonce permet toujours de détecter les replay, et est recommandé. Il est également possible d'utiliser une horloge local, et une fenêtre de temps durant laquelle le demandeur mémorise tous les hash envoyés . En reçevant une réponse, le demandeur s'assure que l'heure de la réponse est dans la fenêtre et qu'il y a une seule occurence de la valeur de hash dans cette fenêtre de temps.

APPENDIX A - attributs Time-stamp utilisant CMS

   Une des utilisations majeur de l'horodatage est d'horodater une signature pour prouver qu'une signature numérique a été créée avant une date donnée. Le certificat correspondant est révoqué, cela permet à un vérificateur de savoir si la signature a été créé avant ou après la date de révocation.

   Un endroit sensible où stocker un timestamp est dans une structure CMS comme un attribut non-signé. Cette appendice définis un attribut Signature Time-stamp qui peut être utilisé pour horodater une signature numérique.

Les identifiant d'objets suivants identifient cet attribut:
id-aa-timeStampToken OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) aa(2) 14 }

La valeur de cet attribut a le type ASN.1 SignatureTimeStampToken:
SignatureTimeStampToken ::= TimeStampToken

   La valeur du champ messageImprint dans TimeStampToken doit être un hash de la aleur du champ signature dans SignerInfo pour le signedData à horodater.

APPENDIX 1 - Placer une signature à un point dans le temps

   On présent un exemple d'une utilisation possible de ce service d'horodatage généraliste. Il place une signature à un point dans le temps, depuis lequel les informations de status du certificat appropri(ex, CRL) doit être vérifié. Cette application est prévue pour être utilisée en conjonction avec des preuves générées en utilisant un mécanisme de signature numérique.

   Les signature peuvent seulement être vérifiées en accord avec une stratégie de non-répudiation. Cette stratégie peut être implicite ou explicite (ex, indiquée dans la preuve fournie par le signataire). La stratégie de non-répudiation peut spécifier, entre-autre, la période permise par un signataire pour déclarer la compromission d'un clé de signature utilisée pour la génération des signatures numérique. Donc une signature ne peut pas garantir d'être valide jusqu'à la fin de cette période.

   Pour vérifier une signature numérique, la technique basique suivante peut être utilisée:

A) Les informations d'horodatage doivent être obtenus juste après la production de la signature

1) La signature est présentée au TSA. Le TSA retourne un TimeStampToken (TST).
2) Le demandeur du service doit vérifier que le TimeStampToken est correct.

B) La validité de la signature numérique peut ainsi être vérifiée de la manière suivante:

1) Le jeton d'horodatage lui-même doit être vérifié et qu'il s'applique à la signature du signataire
2) La date indiquée par le TSA dans le TimeStampToken doit être retrouvée.
3) Le certificat utilisé par le signataire doit être identifié et récupéré
4) La date indiquée par le TSA doit être dans la période de validité du certificat du signataire
5) Les informations de révocation sur ce certificat, à la date de l'opération d'horodatage, doit être récupéré
6) Si le certificat est révoqué, la date de révocation doit être ultérieur à la date indiquée par le TSA.

   Si toutes ces conditions sont réussies, la signature numérique doit être déclarée comme valide.

APPENDIX C - Module ASN.1 utilisant la syntaxe 1988

PKIXTSP {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-tsp(13)}

DEFINITIONS IMPLICIT TAGS ::=

BEGIN

-- EXPORTS ALL --

IMPORTS
Extensions, AlgorithmIdentifier FROM PKIX1Explicit88 {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit-88(1)}

GeneralName FROM PKIX1Implicit88 {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-implicit-88(2)}

ContentInfo FROM CryptographicMessageSyntax {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) cms(1)}

PKIFreeText FROM PKIXCMP {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-cmp(9)} ;

-- Locally defined OIDs --

-- eContentType for a time-stamp token

id-ct-TSTInfo OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) ct(1) 4}

-- 2.4.1

TimeStampReq ::= SEQUENCE {
    version INTEGER { v1(1) },
    messageImprint MessageImprint,
        --a hash algorithm OID and the hash value of the data to be time-stamped
    reqPolicy TSAPolicyId OPTIONAL,
    nonce INTEGER OPTIONAL,
    certReq BOOLEAN DEFAULT FALSE,
    extensions [0] IMPLICIT Extensions OPTIONAL }

MessageImprint ::= SEQUENCE {
    hashAlgorithm AlgorithmIdentifier,
    hashedMessage OCTET STRING }

TSAPolicyId ::= OBJECT IDENTIFIER

-- 2.4.2

TimeStampResp ::= SEQUENCE {
    status PKIStatusInfo,
    timeStampToken TimeStampToken OPTIONAL }

PKIStatusInfo ::= SEQUENCE {
    status PKIStatus,
    statusString PKIFreeText OPTIONAL,
    failInfo PKIFailureInfo OPTIONAL }

PKIStatus ::= INTEGER {
    granted (0),
        -- when the PKIStatus contains the value zero a TimeStampToken, as requested, is present.
    grantedWithMods (1),
        -- when the PKIStatus contains the value one a TimeStampToken, with modifications, is present.
    rejection (2),
    waiting (3),
    revocationWarning (4),
        -- this message contains a warning that a revocation is imminent
        revocationNotification (5)
-- notification that a revocation has occurred }

PKIFailureInfo ::= BIT STRING {
    badAlg (0),
    badRequest (2),
    badDataFormat (5),
    timeNotAvailable (14),
    unacceptedPolicy (15),
    unacceptedExtension (16),
    addInfoNotAvailable (17)
    systemFailure (25)

TimeStampToken ::= ContentInfo

TSTInfo ::= SEQUENCE {
    version INTEGER { v1(1) },
    policy TSAPolicyId,
    messageImprint MessageImprint,
        -- MUST have the same value as the similar field in TimeStampReq
    serialNumber INTEGER,
        -- Time-Stamping users MUST be ready to accommodate integers up to 160 bits.
    genTime GeneralizedTime,
    accuracy Accuracy OPTIONAL,
    ordering BOOLEAN DEFAULT FALSE,
    nonce INTEGER OPTIONAL,
        -- MUST be present if the similar field was present in TimeStampReq. In that case it MUST have the same value.
    tsa [0] GeneralName OPTIONAL,
    extensions [1] IMPLICIT Extensions OPTIONAL }

Accuracy ::= SEQUENCE {
    seconds INTEGER OPTIONAL,
    millis [0] INTEGER (1..999) OPTIONAL,
    micros [1] INTEGER (1..999) OPTIONAL }

END

01 décembre 2014

rfc3370

Algorithmes de Syntaxe de message cryptographique

Introduction

CMS est utilisé pour signer, hasher, authentifier, ou chiffrer numériquement des messages. Ce document décris l'utilisation des algorithmes utilisés communément avec CMS. Les implémentations de CMS peuvent supporter ces algorithmes; et peuvent également supporter d'autres algorithmes. Cependant, si une implémentation choisis de supporter un des algorithmes décris dans ce document, l'implémentation doit le faire comme décris dans ce document.

Les valeurs CMS sont générées en utilisant ASN.1, encodé BER. Les identifiants d'algorithmes ( qui incluent les identifiants d'objets ASN.1) identifient les algorithmes de cryptographiques, et certains algorithmes nécessitent des paramètres additionnels. Quand nécessaire, les paramètres sont spécifiés avec une structure ASN.1. L'identifiant d'algorithme pour chaque algorithme est spécifié, et que nécessaire, la structure de paramètres est spécifiée. Les champs dans le CMS employé par chaque algorithme sont identifié.

Changements depuis la rfc 2630

Ce document obsolète la section 12 de la rfc 2630. La séparation des spécification du protocole et des algorithmes permet à chacun d'être mis à jours sans impacter d'autre. Cependant, les conventions pour utiliser des algorithmes additionnels avec CMS sont spécifiés dans des documents séparés.

Algorithmes de hashage

Cette section spécifie les conventions employées par les implémentations CMS qui supportent SHA-1 ou MD5. Les identifiants d'algorithmes de hashage sont localisés dans le champ digestAlgorithms du SignedData, le champ digestAlgorithm du SignerInfo, le champ digestAlgorithm du DigestedData, et le champ digestAlgorithm du AuthenticatedData.

Les valeurs de hash sont placés dans le champ DigestedData et l'attribut authentifié messages-digest.

SHA-1

L'algorithme de hashage SHA-1 est définis dans FIPS pub 180-1. L'identifiant d'algorithme pour SHA-1 est:
sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) oiw(14) secsig(3) algorithm(2) 26 }

Il y a 2 encodages possible pour le champ de paramètres AlgorithmIdentifier. Les 2 alternatives surviennent du fait que quand la syntaxe 1988 pour AlgorithmIdentifier a été traduite en syntaxe 1997, l'optionnel associé avec les paramètres AlgortihmIdentifier ont été perdus. Plus tard, cet optionnel a été récupérée, mais jusque là beaucoup de gens pensaient que les paramètres de l'algorithme étaient obligatoires. À cause de cela certaines implémentations encodent les paramètres en éléments NUL et d'autres les omettent entièrement. L'encodage correct est d'omettre le champ parameters; cependant, les implémentations doivent également gérer les champ parameters qui contiennent un NULL.

Le champ parameters de AlgorithmIdentifier est optionnel. Si présent, le champ parameters doit contenir un NULL. Les implémentations doivent accepter un AlgorithmIdentifiers SHA-1 sans paramètres. Les implémentations doivent accepter AlgorithmIdentifiers SHA-1 avec un AlgorithmIdentifiers avec un parameters NULL. Les implémentations devraient générer des AlgorithmIdentifiers SHA-1 sans parameters.

MD5

L'algorithme de hashage MD5 est définis dans la rfc1321. L'identifiant d'algorithme pou MD5 est:
md5 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) digestAlgorithm(2) 5 }

Le champ parameters de AlgorithmIdentifier doit être présent, et doit contenir NULL. Les implémentations peuvent accepter le AlgorithmIdentifiers MD5 avec parameters absent ou à NULL.

Algorithmes de signature

Cette section spécifie les conventions employées par les implémentation CMS qui supportent DSA ou RSA. Les identifiants d'algorithme de signature sont localisés dans le champ signatureAlgorithm du SignerInfo du SignedData. Également, les identifiants d'algorithme de signature sont localisés dans le champ signatureAlgorithm du SignerInfo des attributs countersignatures. Les valeurs de signature sont localisées dans le champ signature du SignerInfo du SignedData. Également, les valeurs de signature dans le champ signature des attributs countersignature.

DSA

L'algorithme de signature DSA est définis dans FIPS Pub 186. DSA doit être utilisé avec l'algorithme SHA-1. L'identifiant d'algorithme DSA sujetà à clé publique dans les certificats est:
id-dsa OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) x9-57 (10040) x9cm(4) 1 }

   La validation de signature DSA nécessite 3 paramètres, communément appelés p, q et g. Quand l'identifiant d'algorithme id-dsa est utilisé, le champ parameters de AlgorithmIdentifier est optionnel. Si présent, ce champ doit contenir les 2 valeurs de paramètre DSA encodés en utilisant le type Dss-Parms. Si absent, le sujet de la clé publique DSA utilise les même paramètres DSA que le fournisseur de certificat:

Dss-Parms ::= SEQUENCE {
    p INTEGER,
    q INTEGER,
    g INTEGER }

Quand l'identifiant d'algorithme id-dsa est utilisé, la clé publique DSA, communément appelée Y, doit être encodée en integer. La sortie de cet encodage est placé dans la clé publique du sujet du certificat:
Dss-Pub-Key ::= INTEGER -- Y

L'identifiant de l'algorithme DSA avec signature SHA-1 est:
id-dsa-with-sha1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) x9-57 (10040) x9cm(4) 3 }

Quand l'identifiant de l'algorithme id-dsa-with-sha1 est utilisé, le champ de paramètres AlgorithmIdentifier doit être absent. En signant, l'algorithme DSA génère 2 valeurs, communément appelés r et s. Pour transférer ces 2 valeurs en tant que signature, il doivent être encodés en utilisant le type Dss-Sig-Value:
Dss-Sig-Value ::= SEQUENCE {
    r INTEGER,
    s INTEGER }

RSA

L'algorithme de signature RSA est définis dans la rfc2437, et spécifie l'utilisation de l'algorithme de signature RSA avec les algorithmes de hashage SHA-1 et MD5. L'identifiant d'algorithme pour les sujets de clé publique RSA dans les certificats est:
rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 }

Quand l'identifiant d'algorithme rsaEncryption est utilisé, le champ parameters de AlgorithmIdentifier doit contenir NULL. Quand l'identifiant d'algorithme rsaEncryption est utilisé, la clé publique RSA, qui est composée d'un modulo et d'un exposant publique, doit être encodé en utilisant le type RSAPublicKey. La sortie de cet encodage est placé dans la clé publique du sujet du certificat.
RSAPublicKey ::= SEQUENCE {
    modulus INTEGER, -- n
    publicExponent INTEGER } -- e

   Les implémentations CMS qui incluent l'algorithme de signature RSA doivent implémenter l'algorithme de hashage SHA-1. De telles implémentations devraient également supporter l'agorithme MD5.

   L'identifiant d'algorithme rsaEncryption est utilisé pour identifier les valeurs de signature RSA sans regarder l'algorithme de hashage utilisé. Les implémentations CMS qui incluent l'algorithme de signature RSA doivent supporter l'identifiant d'algorithme de valeur de signature rsaEncryption, et les implémentations CMS peuvent supporter les identifiant d'algorithme de valeur de signature RSA et l'algorithme de hashage.

L'identifiant d'algorithme pour RSA avec signature SHA-1 est:
sha1WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 5 }

L'identifiant d'algorithme pour RSA avec signature MD5 est:
md5WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 4 }

   Quand les identifiants d'algorithme de signature rsaEncryption, sha1WithRSAEncryption, ou md5WithRSAEncryption sont utilisés, le champ parameters de AlgorithmIdentifier doit être NULL.

   En signant, l'algorithme RSA génère une seule valeur, et cette valeur est utilisée directement comme valeur de signature.

Algorithmes de gestion de clé

   CMS accueille les techniques de gestion de clé suivant: key agreement, key transport, previously distributed symmetric key-encryption keys, et passwords.

   Cette section spécifie les conventions employées par les implémentations CMS qui supportent l'agrément de clé en utilisant X9.42 Ephemeral-Static Diffie-Hellman (X9.42 E-S D-H) et X9.42 Static-Static Diffie-Hellman (X9.42 S-S D-H).

   Quand un algorithme d'agrément de clé est utilisé, un algorithme de chiffrement de clé est également nécessaire. Donc, quand l'agrément de clé est supporté, un algorithme de chiffrement de clé doit être fournis pour chaque algorithme de chiffrement de contenu. Les algorithmes d'enveloppement de clé pour Triple-DES et RC2 sont décris dans la rfc3217.

   Pour l'agrément de clé des clés de chiffrement de clé RC2, 128bits doivent être générés en entrée du processus d'expansion de clé utilisé pour calculé la clé effective RC2.

   Les identifiants d'algorithme d'agrément de clé sont localisé dans les champs EnvelopedData RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm et AuthenticatedData RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm.

   Les identifiants d'algorithme d'envelopement de clé sont localisés dans parameters de KeyWrapAlgorithm dans les champs EnvelopedData RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm et AuthenticatedData RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm.

   Les clés de chiffrement de contenu enveloppés sont localisés dans le champ EnvelopedData RecipientInfos KeyAgreeRecipientInfo RecipientEncryptedKeys encryptedKey. Les clés message-authentication enveloppés sont localisés dans le champ AuthenticatedData RecipientInfos KeyAgreeRecipientInfo RecipientEncryptedKeys encryptedKey.

X9.42 Ephemeral-Static Diffie-Hellman

L'agrément de clé Ephemeral-Static Diffie-Hellman est définis dans la rfc 2631. En utilisant Ephemeral-Static Diffie-Hellman, le champ EnvelopedData RecipientInfos KeyAgreeRecipientInfo est utilisé comme suit:

- la version doit être 3
- originator doit être l'alternative originatorKey. le champ algorithm de originatorKey doit contenir l'identifiant d'objet dh-public-number avec parameters absent. le champ publicKey de originatorKey doit contenir la clé publique éphémère de l'émetteur. l'identifiant d'objet dh-public-number est:

dh-public-number OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) ansi-x942(10046) number-type(2) 1 }

- ukm peut être présent ou absent. Les implémentations CMS doivent supporter l'absence de ukm, et devraient supporter la présence d'ukm. Quand présent, ukm est utilisé pour s'assurer qu'une clé de chiffrement de clé est générée quand la clé privée éphémère doit être utilisée plus d'une fois.
- keyEncryptionAlgorithm doit être l'identifiant d'algorithme id-alg-ESDH. Le champ de paramètre d'identifiant d'algorithme pour id-alg-ESDH est KeyWrapAlgorithm, et ce paramètre doit être présent. KeyWrapAlgorithm dénote l'algorithme de chiffrement symétrique utilisé pour chiffrer la clé de chiffrement de contenu ave la clé de chiffrement générée en utilisa l'algorithme d'agrément de clé X9.42 Ephemeral-Static Diffie-Hellman. Triple-DES et RC2 sont décris dans la rfc3217. la syntaxe de l'identifiant d'algorithme id-alg-ESDH et ses paramètres est:

id-alg-ESDH OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 5 }

KeyWrapAlgorithm ::= AlgorithmIdentifier

- recipientEncryptedKeys contient un identifiant et un clé chiffrée pour chaque destinataire. Le KeyAgreeRecipientIdentifier de RecipientEncryptedKey doit contenir soit le issuerAndSerialNumber identifiant le certificat du destinataire, soit RecipientKeyIdentifier contenant d'identifiant de clé du sujet du certificat du destinataire. Dans les 2 cas, le certificat du destinataire contient la clé publique statique du destinataire. EncryptedKey de RecipientEncryptedKey doit contenir la clé de chiffrement de contenu chiffrée avec la clé de chiffrement de clé X9.42 Ephemeral-Static Diffie-Hellman générée en utilisant l'algorithme spécifié par le KeyWrapAlgorithm.

X9.42 Static-Static Diffie-Hellman

L'agrément de clé Static-Static Diffie-Hellman est définis dans la rfc 2631. En utilisant Static-Static Diffie-Hellman, les champs EnvelopedData RecipientInfos KeyAgreeRecipientInfo et AuthenticatedData RecipientInfos KeyAgreeRecipientInfo sont utilisé comme suit:

- la version doit être 3
- originator doit être sost issuerAndSerialNumber soit subjectKeyIdentifier. Dans les 2 cas, le certificat de l'auteur contient la clé publique statique de l'émetteur. La rfc 3279 spécifie la syntaxe et les valeurs des paramètres AlgorithmIdentifier qui sont inclus dans le certificat de l'auteur. Le champ d'information de clé publique du certificat de l'auteur doit contenir l'identifiant d'objet dh-public-number:

dh-public-number OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) ansi-x942(10046) number-type(2) 1 }

dh-public-number OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) ansi-x942(10046) number-type(2) 1 }

- ukm doit être présent. ukm s'assure qu'une clé de chiffrement de clé différente est générée pour chaque message entre les même émetteur et destinataire.
- keyEncryptionAlgorithm doit être d'identifiant d'algorithme id-alg-SSDH. Le champ parameter de d'identifiant d'algorithme pour id-alg-SSDH est KeyWrapAlgorithm, et ce paramètre doit être présent. KeyWrapAlgorithm dénote l'algorithme de chiffrement symétrique utilisé pour chiffrer la clé de chiffrement de contenu avec la clé de chiffrement de clé générée en utilisant l'algorithme d'agrément de clé X9.42 Static-Static Diffie-Hellman. Triple-DES et RC2 sont décris dans la rfc 3217. L'identifiant d'algorithme id-alg-SSDH et ses paramètres est:

id-alg-SSDH OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 10 }

KeyWrapAlgorithm ::= AlgorithmIdentifier

- recipientEncryptedKeys contient un identifiant et une clé chiffrée pour chaque destinataire. KeyAgreeRecipientIdentifier de RecipientEncryptedKey doit contenir soit le issuerAndSerialNumber identifiant le certificat du destinataire, soit le RecipientKeyIdentifier contenant l'identifiant de clé du sujet du certificat du destinataire. Dans les 2 cas, le certificat du destinataire contient la clé publique statique du destinataire. EncryptedKey de RecipientEncryptedKey doit contenir la clé de chiffrement de contenu chiffrée avec la clé de chiffrement de clé X9.42 Static-Static Diffie-Hellman générée en utilisant l'algorithme spécifiée par KeyWrapAlgorithm.

Algorithmes de transport de clé

Cette section spécifie les conventions employés par les implémentations CMS qui supportent le transport de clé en utilisant RSA. Les identifiant d'algorithme de transport de clé sont localisé dans le champ EnvelopedData RecipientInfos KeyTransRecipientInfo keyEncryptionAlgorithm. Les clé de chiffrement de contenu chiffrés par transport de clé sont localisés dans le champ EnvelopedData RecipientInfos KeyTransRecipientInfo encryptedKey.

RSA

L'algorithme de transport de clé RSA est le shéma de chiffrement RSA définis dans la rfc 2313, le type de block est 02, où le message à chiffrer est la clé de chiffrement de contenu. L'identifiant d'algorithme pour RSA est:
rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 }

   Le champ parameters de AlgorithmIdentifier doit être présent, et le champ parameters doit contenir NULL. En utilisant une clé de chiffrement de contenu Triple-DES, les implémentations CMS doivent ajuster les bits de parité pour chaque clé DES comprises dans la clé Triple-DES avant le chiffrement RSA.

   L'utilisation du chiffrement RSA, comme définis dans la rfc 2313, pour fournir la confidentialité a une vulnérabilité conue. La vulnérabilité est plus dans l'utilisation dans les application intéractives que dans les environnement de stockages. Dans informations et contre-mesure sont discutés dans la section considération de sécurité de ce document et la rfc3218.

   Noter que le même schéma de chiffrement RSA est également définis dans la rfc 2437, qui est appelé RSAES-PKCS1-v1.5.

Algorithmes de clé de chiffrement de clé symétriques

   Cette section spécifie les conventions employés par les implémentations CMS qui supportent la gestion de clé de chiffrement de clé en utilisant Triple-DES ou RC2. Quand RC2 est supporté, des clé RC2 128 bits doivent être utilisé, et doivent être utilisées avec le paramètre RC2ParameterVersion à 58. Une implémentation CMS peut supporter un key-encryption et content-encryptionalgorithms mixés. Par exemple, une clé de chiffrement de contenu 40-bits RC2 peut être enveloppé avec une clé de chiffrement de clé Triple-DES 168-bits ou avec une clé de chiffrement de clé 128-bits RC2.

   Les identifiants d'algorithme d'enveloppement sont localisé dans les champs EnvelopedData RecipientInfos KEKRecipientInfo keyEncryptionAlgorithm et AuthenticatedData RecipientInfos KEKRecipientInfo keyEncryptionAlgorithm.

   Les clé de chiffrement de contenus enveloppés sont localisés dans le champ EnvelopedData RecipientInfos KEKRecipientInfo. Les clé d'authentification de message enveloppés sont localisés dans le champ AuthenticatedData RecipientInfos KEKRecipientInfo encryptedKey.

   La sortie d'un algorithme d'agrément de clé est une clé de chiffrement de clé, et cette clé de chiffrement de clé est utilisée pour chiffrer la clé de chiffrement de contenu. Pour suppporter l'agrément de clé, les identifiants d'algorithme d'enveloppement sont localisés dans le KeyWrapAlgorithm parameter des champs EnvelopedData RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm et AuthenticatedData RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm. Cependant, seuls les algorithmes d'agrément de clé qui fournissent des clés d'authentification doivent être utilisé avec AuthenticatedData. Les clés de chiffrement de contenu enveloppés sont localisés dans le champ EnvelopedData RecipientInfos KeyAgreeRecipientInfo RecipientEncryptedKeys encryptedKey, les clé d'authentification de message enveloppés sont localisés dans le champ AuthenticatedData RecipientInfos KeyAgreeRecipientInfo RecipientEncryptedKeys encryptedKey.

Triple-DES Key Wrap

Une implémentation CMS peut supporter des algorithmes de chiffrement de clé et de chiffrement de contenu mixés. Par exemple, une clé de chiffrement de contenu 128-bits RC2 peut être enveloppé avec une clé de chiffrement de clé 168-bits Triple-DES.

Le chiffrement Triple-DES a l'identifiant d'algorithme :
id-alg-CMS3DESwrap OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 6 }

Le champ parameter de AlgorithmIdentifier doit être NULL. L'algorithme d'envelope de clé utilisé pour chiffrer une clé de chiffrement de contenu Triple-DES avec une clé de chiffrement de clé Triple-DES est spécifiée dans la rfc3217.

RC2 Key Wrap

   Une implémentation CMS peut supporter des algorithmes de chiffrement de clé et de chiffrement de contenu mixés. Par exemple, une clé de chiffrement de contenu 128-bits RC2 peut être enveloppé dans une clé de chiffrement de clé Triple-DES 168-bits. Similairement, une clé de chiffrement de contenu RC2 40-bits peut être enveloppé dans une clé de chiffrement de clé RC2 128-bits.

Le chiffrement de clé RC2 a l'identifiant d'algorithme:
id-alg-CMSRC2wrap OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 7 }

Le champ parameter de AlgorithmIdentifier doit être RC2wrapParameter:
RC2wrapParameter ::= RC2ParameterVersion
RC2ParameterVersion ::= INTEGER

   Les bits de clé effectifs RC2 ( la taille de clé ) supérieurs à 32 et inférieurs à 256 sont encodés dans le RC2ParameterVersion. Pour les tailles 40, 64, et 128, les valeurs RC2ParameterVersion sont 160, 120, et 58, respectivement. Ces valeurs ne sont pas simplement la longueur de clé RC2. Noter que la valeur 160 doit être encodé en 2 octets (00 A0), parce que l'octet A0 seul représente un nombre négatif.

   Les clé RC2 128-bits doivent être utilisés comme clé de chiffrement de clé, et doivent être utilisé avec le paramètre RC2ParameterVersion à 58.

   L'algorithme d'enveloppe de clé utilisé pour chiffrer une clé de chiffrement de contenu RC2 avec une clé de chiffrement de clé RC2 est spécifiée dans la rfc 3217.

Algorithmes de dérivation de clé

   Cette section spécifie les conventions employées par les implémentations CMS qui supportent la gestion de clé basé sur mot de passe en utilisant PBKDF2. Les algorithmes de dérivation de clé sont utilisés pour convertir un mot de passe en une clé de chiffrement de clé comme partie de la technique de gestion de clé basée sur mot de passe.

   Les identifiants d'algorithme de dérivation de clé sont localisés dans les champs EnvelopedData RecipientInfos PasswordRecipientInfo keyDerivationAlgorithm et AuthenticatedData RecipientInfos PasswordRecipientInfo keyDerivationAlgorithm. La clé de chiffrement de clé qui est dérivée du mot de passe est utilisée pour chiffrer la clé de chiffrement de contenu.

   Les clé de chiffrement de contenu chiffrés avec une clé de chiffrement de clé dérivé de mot de passe sont localisés dans le champ EnvelopedData RecipientInfos PasswordRecipientInfo encryptedKey. Les clés d'authentification de message chiffrés avec de clés de chiffrement de clé dérivés de mot de passe sont localisés dans le champ AuthenticatedData RecipientInfos PasswordRecipientInfo encryptedKey.

L'algorithme de dérivation de clé PBKDF2 est spécifié dans la rfc 2898. keyDerivationAlgorithmIdentifier identifie l'algorithme de dérivation de clé, et ses paramètres associés utilisés pour dériver la clé de chiffrement de clé du mot de passe fournis. L'identifiant d'algorithme pour l'algorithme de dérivation de clé PBKDF2 est:
id-PBKDF2 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-5(5) 12 }

Le champ parameter de AlgorithmIdentifier doit être PBKDF2-params:
PBKDF2-params ::= SEQUENCE {
    salt CHOICE {
        specified OCTET STRING,
        otherSource AlgorithmIdentifier },
    iterationCount INTEGER (1..MAX),
    keyLength INTEGER (1..MAX) OPTIONAL,
    prf AlgorithmIdentifier
        DEFAULT { algorithm hMAC-SHA1, parameters NULL } }

   Dans le PBKDF2-params, le salt doit utiliser la chaîne d'octet spécifiée.

Algorithmes de chiffrement de contenu

Cette section spécifie les conventions employées par les implémentation CMS qui supportent le chiffrement de contenu en utilisant Triple-DES 3 clés en mode CBC, Triple 2-clés en mode CBC, ou RC2 en mode CBC.

Les identifiants d'algorithme de chiffrement de contenu sont localisés dans les champs EnvelopedData EncryptedContentInfo contentEncryptionAlgorithm et EncryptedData EncryptedContentInfo contentEncryptionAlgorithm. Les algorithme de chiffrement de contenu sont utilisé pour chiffrer le contenu localisé dans le champ EnvelopedData EncryptedContentInfo encryptedContent et le champ EncryptedData EncryptedContentInfo encryptedContent.

Triple-DES CBC

L'algorithme Triple-DES est composé de 3 opération DES séquentielles: chiffrer, déchiffrer, et chiffrer. Triple-DES 3-clés utilise une clé différente pour chaque opération DES. Triple-DES 2-clés utilise une clé pour les opérations de chiffrement et une clé différente pour l'opération de déchiffrement. Les même identifiant d'algorithme sont utilisé pour les 2.

L'identifiant d'algorithme pour Triple-DES en mode CBC est:
des-ede3-cbc OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) encryptionAlgorithm(3) 7 }

Le champ parameters de AlgorithmIdentifier doit être présent, et le champ doit contenir un CBCParameter:
CBCParameter ::= IV
IV ::= OCTET STRING -- exactement 8 octets

RC2 CBC

L'algorithme RC2 est décris dans la rfc2268. L'identifiant d'algorithme pour RC2 en mode CBC est:
rc2-cbc OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) encryptionAlgorithm(3) 2 }

Le champ parameters de AlgorithmIdentifier doit être présent et doit contenir un RC2CBCParameter:
RC2CBCParameter ::= SEQUENCE {
    rc2ParameterVersion INTEGER,
    iv OCTET STRING } -- exactement 8 octets

   Les bits de clé effectifs RC2 (la taille de clé) supérieurs à 32 et inférieurs à 256 sont encodés dans le RC2ParameterVersion. Pour les tailles 40, 64, et 128, les valeurs RC2ParameterVersion sont 160, 120, et 58, respectivement. Ces valeurs ne sont pas simplement la longueur de clé RC2. Noter que la valeur 160 doit être encodé en 2 octets (00 A0), parce que l'octet A0 seul représente un nombre négatif.

Algorithms de code d'authentification de message

Cette section spécifie les conventions employées par les implémentations CMS qui supportent HMAC avec SHA-1. Les identifiant d'algorithme MAC sont localisés dans le champ macAlgorithm de AuthenticatedData. es valeurs MAC sont localisées dans le champ mac de AuthenticatedData.

HMAC avec SHA-1

L'algorithme HMAC avc SHA-1 est décris dans la rfc 2104. L'identifiant d'algorithme pour HMAC avec SHA-1 est:
hMAC-SHA1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) 8 1 2 }

Il y a 2 encodages possibles pour le champ parameters de AlgorithmIdentifier pour HMAC avec SHA-1. Les 2 alternatives surviennent du fait que quand la syntaxe 1988 pour AlgorithmIdentifier a été traduite en syntaxe 1997, l'optionnel associé avec les paramètres AlgortihmIdentifier ont été perdus. Plus tard, cet optionnel a été récupérée, mais jusque là beaucoup de gens pensaient que les paramètres de l'algorithme étaient obligatoires. À cause de cela certaines implémentations encodent les paramètres en éléments NUL et d'autres les omettent entièrement.

Le champ parameters de AlgorithmIdentifier est optionnel. Si présent, le champ parameters doit contenir NULL. Les implémentations doivent accepter HMAC avec SHA-1 avec parameters absent, et doivent accepter HMAC avec SHA-1 avec paramaters à NULL. Les implémentations devraient générer des AlgorithmIdentifiers HMAC avec SHA-1 avec parameters absent.

Module ASN.1

CryptographicMessageSyntaxAlgorithms
    { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) cmsalg-2001(16) }

DEFINITIONS IMPLICIT TAGS ::=
BEGIN
    -- EXPORTS All
    -- Les types et valeurs définis dans ce module sont exporté pour l'utilisation dans d'autres modules ASN.1.
    -- D'autres applications peuvent les utiliser.

IMPORTS
    -- Imports de la rfc 3280, Appendix A.1
        AlgorithmIdentifier
            FROM PKIX1Explicit88 { iso(1)
                identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) mod(0) pkix1-explicit(18) } ;

    -- Algorithm Identifiers

    sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) oiw(14) secsig(3) algorithm(2) 26 }

    md5 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) digestAlgorithm(2) 5 }

    id-dsa OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) x9-57(10040) x9cm(4) 1 }

    id-dsa-with-sha1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) x9-57(10040) x9cm(4) 3 }

    rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 }

    md5WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 4 }

    sha1WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 5 }

    dh-public-number OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) ansi-x942(10046) number-type(2) 1 }

    id-alg-ESDH OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 5 }

    id-alg-SSDH OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 10 }

    id-alg-CMS3DESwrap OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 6 }

    id-alg-CMSRC2wrap OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 7 }

    des-ede3-cbc OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) encryptionAlgorithm(3) 7 }

    rc2-cbc OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) encryptionAlgorithm(3) 2 }

    hMAC-SHA1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) 8 1 2 }

    id-PBKDF2 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-5(5) 12 }

    -- Public Key Types

    Dss-Pub-Key ::= INTEGER -- Y

    RSAPublicKey ::= SEQUENCE {
        modulus INTEGER, -- n
        publicExponent INTEGER } -- e

    DHPublicKey ::= INTEGER -- y = g^x mod p

    -- Signature Value Types

    Dss-Sig-Value ::= SEQUENCE {
        r INTEGER,
        s INTEGER }

    -- Algorithm Identifier Parameter Types

    Dss-Parms ::= SEQUENCE {
        p INTEGER,
        q INTEGER,
        g INTEGER }

    DHDomainParameters ::= SEQUENCE {
        p INTEGER, -- odd prime, p=jq +1
        g INTEGER, -- generator, g
        q INTEGER, -- factor of p-1
        j INTEGER OPTIONAL, -- subgroup factor
        validationParms ValidationParms OPTIONAL }

    ValidationParms ::= SEQUENCE {
        seed BIT STRING,
        pgenCounter INTEGER }

    KeyWrapAlgorithm ::= AlgorithmIdentifier

    RC2wrapParameter ::= RC2ParameterVersion

    RC2ParameterVersion ::= INTEGER

    CBCParameter ::= IV

    IV ::= OCTET STRING -- exactly 8 octets

    RC2CBCParameter ::= SEQUENCE {
        rc2ParameterVersion INTEGER,
        iv OCTET STRING } -- exactly 8 octets

    PBKDF2-params ::= SEQUENCE {
        salt CHOICE {
            specified OCTET STRING,
            otherSource AlgorithmIdentifier },
        iterationCount INTEGER (1..MAX),
        keyLength INTEGER (1..MAX) OPTIONAL,
        prf AlgorithmIdentifier
            DEFAULT { algorithm hMAC-SHA1, parameters NULL } }

END -- of CryptographicMessageSyntaxAlgorithms

Considérations de sécurité

   La technique de gestion de clé employée pour distribuer les clé d'authentification de message doit elle-même fournir l'authentification, sinon le contenu est délivré avec l'intégrité depuis une source inconnue. Ni RSA, ni Ephemeral-Static Diffie-Hellman ne fournissent l'authentification de l'origine des données nécessaires. Static-Static Diffie-Hellman fournis l'authentification de l'origine des données nécessaire quand l'auteur et les clés publiques des destinataires sont liés aux entités appropriés dans les certificats X.509.

   Quand plus de 2 parties partagent la même clé d'authentification de message, l'authentification de l'origine des donnée n'est pas fournie. Toutes les parties qui connaissent la clé d'authentification de message peuvent calculer un MAC valide, donc le contenu pourrait venir de n'importe lequel de ces parties.

   Les implémentations doivent générer des clé de chiffrement de contenu, de clé d'authentification de message, des vecteurs d'initialisation, des valeurs one-time aléatoirement, et du padding. Également, la génération de paires de clé publique/privées assure des nombres aléatoires. L'utilisation inadéquate de générateurs de nombre pseudo-aléatoires pour générer des valeurs peut engendrer des problèmes de sécurité. Un attaquant peut trouver qu'il est plus facile de reproduite l'environnement PRNG qui de produire les clé, en cherchant le plus petit jeu de possibilités résultants, au lieu de brute forcer tout l'espace de clé. La génération de nombre aléatoires de qualité est difficile. Les rfc1750 offre un guide important dans ce but, et l'appendice 3 de FIPS Pub 186 fournis une technique PRNG de qualité.

   En utilisant les algorithmes d'agrément de clé ou des clé de chiffrement de clé symétrique précédemment distribués, une clé de chiffrement de clé est utilisée pour chiffrer la clé de chiffrement de contenu. Si les algorithmes de chiffrement de clé et de chiffrement de contenu sont différents, la sécurité effective est déterminée par le plus faible des 2. Les implémenteurs doivent s'assurer que les algorithmes de chiffrement de clé sont aussi fort sinon plus que les algorithmes de chiffrement de contenu.

   La rfc 3217 spécifie des algorithmes d'enveloppe de clé utilisés pour chiffrer une clé de chiffrement de contenu Triple-DES avec une clé de chiffrement de clé Triple-DES ou pour chiffrer un clé de chiffrement de contenu RC2 avec une clé de chiffrement de clé RC2. Les algorithmes d'enveloppe de clé utilisent le mode CBC, et ont été revus pour l'utilisation avec Triple-DES et RC2. Ils n'ont pas été revus pour l'utilisation avec d'autres modes cryptographiques ou d'autres algorithmes de chiffrement. Cependant, si une implémentation CMS souhaite supporter d'autres chiffrements, les algorithmes d'enveloppe de clé additionnels doivent être définis pour supporter ces chiffrements additionnels.

   Les implémenteurs devraient vérifier si les algorithmes cryptographiques deviennent faible dans le temps. De nouvelles techniques de cryptanalyse sont développées et les performances de calcul s'améliorent, Le facteur temps pour casser un algorithme cryptographique sera réduit. Cependant, les implémentations d'algorithmes crytographiques devraient être modulaires permettant aux nouveaux algorithmes d'être facilement insérés.

   Les utilisateurs de CMS, particulièrement ceux employant le CMS pour le support d'applications intéractives, devraient savoir que RSA, comme spécifié dans la rfc 2313, est vulnérable à des attaques de texte chiffré choisis lorsqu'il est appliqué à des fins de chiffrement. L'exploitation de cette vulnérabilité identifiée, révélant le résultat d'un déchiffrement RSA particulier, nécessite l'accès à un oracle qui répondra à un grand nombre de textes chiffrés (basé sur les résultats disponibles actuellement), qui sont construits adaptivement en réponse à une réponse reçue précédemment fournissant des informations sur la réussite ou l'échec des opération de déchiffrement tentés. En résultat, l'attaque apparaît significativement moins faisable dans les environnements S/MIME store-and-forward que pour les protocoles intéractif.

   Une version mises à jours de PKCS#1 a été publiée, la version 2.0, qui préserve le support pour le format de padding de chiffrement, et définis une nouvelle alternative. Pour résoudre la vulnérabilité, la version 2.0 spécifie et recommande l'utilisation de OAEP quand RSA est utilisé pour fournir la confidentialité. Voir la rfc 3218 pour plus d'informations sur la vulnérabilité de PKCS#1 version 1.5.

24 juillet 2015

rfc3647

Framework de stratégie de certificat et de pratiques de certification

Introduction

   En général, un certificat à clé publique lie une clé publique maintenue par une entité (telle qu'une personne, une organisation, compte, périphérique, ou site) à un jeu d'informations qui identifient l'entité associée avec l'utilisation de la clé privée correspondante. Dans beaucoup de cas impliquant des certificats d'identité, cette entité est connue comme le "subject" ou "subscriber" du certificat. 2 exceptions cependant, incluant les périphérique (dans lequel le souscripteur est généralement l'organisation contrôlant le périphérique) et les certificats anonymes (dans lequel l'identité de l'individu ou de l'organisation n'est pas disponible depuis le certificat lui-même). D'autres types de certificats lient les clés publiques aux attributs d'une entité autre que l'identité de l'entité, tel qu'un rôle, un titre, ou des informations de solvabilité.

   Un certificat est utilisé par un utilisateur de certificat ou un tiers de confiance qui a besoin d'utiliser, et compte sur la précision de, le lien entre la clé publique du sujet distribué via ce certificat et l'identité et/ou d'autres attributs du sujet contenu dans ce certificat. Un tiers de confiance est fréquemment une entité qui vérifie la signature numérique du sujet du certificat où la signature numérique est associée avec un mail, document électronique, ou autre donnée. D'autres exemples de tiers de confiance peut inclure un émetteur de mail chiffré à un souscripteur, un utilisateur d'un navigateur web vérifiant un certificat serveur durant une session SSL, et une entité opérant un serveur qui contrôle l'accès aux informations online en utilisant des certificats client comme mécanisme de contrôle d'accès. En résumé, un tiers de confiance est une entité qui utilise une clé publique dans un certificat (pour vérification de signature et/ou chiffrement). Le degré auquel le tiers de confiance peut faire confiance à la liaison embarquée dans un certificat dépend de nombreux facteurs. Ces facteurs peuvent inclure les pratiques suivies par l'autorité de certification en authentifiant le sujet; la stratégie de la CA, les procédures, et les contrôles de sécurité. Le scope de la responsabilité du souscripteur (par exemple, en protégeant la clé privée); et les responsabilités statué et les termes et conditions de responsabilité de la CA.

   Un certificat X.509 version 3 peut contenir un champ déclarant qu'une ou plusieurs stratégies de certificat spécifiques s'appliquent à ce certificat. En accord avec X.509, une stratégie de certificat (CP) est "un jeu de règles nommés qui indiquent l'applicabilité d'un certificat à une communauté particulière et/ou classe d'applications avec des pré-requis de sécurité communs". Un CP peut être utilisé par un tiers de confiance pour aider à décider si un certificat est suffisamment digne de confiance et par ailleurs approprié pour une application particulière. Le concept CP est un prolongement du concept de déclaration de stratégie développé pour Internet Privacy Enhanced Mail.

   Une description plus détaillée des pratiques suivies par une CA en émettant et gérant des certificats peut être contenu dans une déclaration de pratique de certification (CPS) publié par ou référencé par la CA. En accord avec American Bar Association Information Security Committee's Digital Signature Guidelines (DSG) et l'Information Security Committee's PKI Assessment Guidelines (PAG), "un CPS est une déclaration des utilisations qu'une autorité de certification emploie pour émettre des certificats". En général, les CPS décrivent également des pratiques liées à tous les services de cycle de vie des certificats (ex: émission, gestion, révocation, renouvellement, etc), et les CPS fournissent des détails concernant d'autres question d'affaires, juridiques et techniques. Les termes contenus dans un CP ou CPS peuvent ou non être obligatoire pour les participants d'une PKI comme un contrat. Un CP ou CPS peut lui-même prétendre être un contrat. Plus communément, cependant, un agrément peut incorporer un CP ou CPS par référence et ainsi tenter de lier les parties de l'agrément à partie ou tous ses termes. Par exemple, certaines PKI peuvent utiliser un CP ou ( plus communément ) un CPS qui est incorporé par référence dans l'agrément entre un souscripteur et une CA ou RA (appelé un agrément de souscripteur) ou l'agrément entre un tiers de confiance et une CA (appelé un agrément de tiers de confiance ou RPA). Dans d'autres cas, cependant, un CP ou CPS n'a pas de signification contractuelle du tout. Une PKI peut définir ces CP ou CPS comme étant strictement informationels ou des documents d'information.

But

Le but de ce document est double. D'abord, le document explique les concepts d'un CP ou d'un CPS, décris les différences entre ces 2 concepts, et décris leur relation au souscripteur et agréments de tiers de confiance. Ensuite, ce document présente un framework pour assister les rédacteurs et utilisateurs de stratégie de certificat ou CPS en définissant et comprenant ces documents. En particulier, le framework identifie les éléments qui peuvent être nécessaire à considérer en formulant un CP ou CPS. Le but n'est pas de définir de stratégie de certificat particulière ou CPS.

Périmètre

   Le périmètre de ce document est limité à la discussion des éléments qui peuvent être couverts dans un CP (comme définis dans X.509) ou CPS (comme définis dans DSG et PAG). En particulier, ce document décris les types d'information qui devraient être considérés pour les inclure dans un CP ou CPS. Bien que le framework présenté généralement assume l'utilisation de certificat X.509v3 pour fournir l'assurance d'identité, il n'est pas prévus qu'il soit restreint à l'utilisation de ce format de certificat. À la place, il est prévus que ce framework soit adaptable à d'autres formats de certificat et certificats fournissant des assurance autre que l'identité qui peuvent entrer en utilisation.

   Le scope ne s'étend pas à la définition des stratégies de certificat (tels que les stratégies de sécurité des organisation, stratégie de sécurité des systèmes, ou stratégie de labelisation des données). De plus, ce document ne définis pas de CP ou CPS spécifiue. En outre, en présentant un framework, ce document devrait être vu et utilisé comme un outil flexible présentant des éléments qui devraient être considérés comme un intérêt particulier pour les CP ou CPS, et pas comme une formue rigide pour produire des CP ou CPS.

   Ce document assume que le lecteur est familiarisé avec les concepts généraux de signature numérique, certificat, et infrastructure à clé publique, comme utilisé dans X.509, le DSG et le PAG.

Définitions

Ce document utilise les termes suivant:

Activation Data Les valeurs, autre que les clés, qui sont requis pour opérer des modules cryptographiques et qui nécessitent d'être protégés.
Authentification Le processus qui établis que les individus, organisation, ou autre sont qui ils prétendent être. Dans le contexte d'une PKI, l'authentification peut être le processus d'établissement qu'un individu ou organisation applique pour accéder à quelque chose sous un certain nom est, en fait, l'individu ou l'organisation propre. Cela correspond au deuxième processus impliqué dans l'identification.
CA-certificate Un certificat pour une clé publique de CA émise par une autre CA
Certificate Policy Un jeu nommé de règles qui indiquent l'applicabilité d'un certificat à une communauté particulière et/ou class d'applications avec des besoins de sécurités communs. Par exemple, un CP particulier peut indiquer l'applicabilité d'un type de certificat pour l'authentification des parties engagés dans des transaction b2b pour le commerce de biens ou de services dans une plage de prix donné.
Certification path Une séquence ordonnée de certificats qui, ensemble avec la clé publique de l'objet initial dans le chemin, peuvent être traités avec la clé publique de l'objet initial dans le chemin, peut être traité pour obtenir l'objet final est dans le chemin.
Certification Practice Statement Une déclaration des pratiques qu'une autorité de certification emploie en émettant, gérant, révoquant, et renouvelant les certificats.
CPS Summary (ou CPS Abstract) Un sous-jeu des dispositions d'une CPS complète qui est rendue publique par une CA.
Identification Les processus établissant l'identité d'un individu ou d'une organisation, par ex, pour montrer qu'un individu ou une organisation est un individu ou une organisation spécifique. Dans le contexte d'une PKI, l'identification réfère à 2 processus:

1. Établir qu'un nom donné d'un individu ou d'une organisation correspond à une identité du monde réel d'un individu ou d'une organisation
2. Établir qu'un individu ou une organisation s'applique pour un accès à quelque chose sous ce nom est, en fait, l'individu ou l'organisation nommée. Une identification d'une personne peut être un demandeur de certificat, un demandeur pour un emploie dans un poste de confiance participant à une PKI, ou une personne cherchant accès au réseaux ou à une application, telle qu'un administrateur CA cherchant l'accès aux systèmes CA.

Issuing certification authority Dans le contexte d'un certificat particulier, la CA émettrice est la CA qui a émise le certificat.
Participant Un individu ou une organisation qui joue un rôle dans une PKI donnée comme un souscripteur, un tiers de confiance, CA, RA, etc.
PKI Disclosure Statement Un instrument qui complète une CP ou une CPS en divulguant des informations essentielles sur les stratégies et pratiques d'une CA/PKI. Un PDS est un véhicule pour divulguer et souligner les informations normalement couvertes en détail par les documents CP et/ou CPS associés. En conséquence, un PDS n'est pas prévu pour remplace une CP ou CPS.
Policy qualifier Information dépendante de la stratégie qui peut accompagner un identifiant de CP dans un certificat X.509. De telles informations peuvent inclure un pointeur vers une URL d'une CPS applicable ou d'un agrément de tiers de confiance. Il peut également inclure du texte qui contient les termes d'utilisation du certificat ou des informations légales.
Registration authority (RA) Une entité qui est responsable pour une ou plusieurs fonctions: l'identification et l'authentification des demandeurs de certificat, l'approbation ou le rejet des applications de certificat, initier les révocations de certificat ou leur suspension sous certaines circonstances, traiter les demandes de renouvellement ou changement de clé. Les RA, cependant, ne signent ou n'émettent pas de certificat.
Relying party Un destinataire d'un certificat qui agit en se fondant sur ce certificat et/ou toutes signature vérifiées en utilisant ce certificat. Dans ce document, les termes "certificate user" et "relying party" sont utilisé de la même manière.
Relying party agreement (RPA) Un agrément entre une autorité de certification et un tiers de confiance qui établis typiquement les droits et responsabilité entre ces parties en regardant la vérification des signatures ou d'autres utilisation des certificats.
Set of provisions Une collection de déclarations de stratégies et/ou de pratique, couvrant un éventails de sujets standards, à utiliser dans l'expression d'un CP ou CPS utilisant l'approche décrite dans ce framework.
Subject certification authority (subject CA) Dans le contexte d'un certificat CA particulier, le subjet CA est la CA dont la clé publique est certifiée dans le certificat
Subscriber Un Sujet d'un certificat qui a été émis.
Subscriber Agreement Un agrément entre une CA et un souscripteur qui établis les droits et responsabilités des parties en regardant l'émission et la gestion des certificats.
Validation Le processus d'identification des demandeurs de certificat. la validation est un sous-jeu de l'identification et réfère à l'identification dans le contexte d'établissement de l'identité des demandeurs de certificat.

Concepts

Cette section explique les concepts des CP et CPS, et décris leur relation avec d'autres documents PKI, tels que les agréments de souscripteur et de tiers de confiance. D'autres concepts liés sont également décris. Certains supports couverts dans cette section et dans d'autres sections sont spécifiques aux extensions de stratégie de certificat comme définis dans X.509v3. Excepté pour ces sections, ce framework est prévu pour être adaptable à d'autres formats de certificat qui peuvent être utilisés.

Certificate Policy

   Quand une autorité de certification émet un certificat, elle fournis une déclaration à l'utilisateur du certificat qu'une clé publique particulière est liée à l'identité et/ou d'autres attributs d'une entité particulière. La mesure par laquelle le tiers de confiance devrait se conformer sur cette déclaration, cependant, doit être évalué par le tiers de confiance ou d'entité qui contrôle ou coordonne la manière dont les tiers de confiance ou les applications de confiance utilisent les certificats. Différents certificats sont émis suivant différentes pratiques et procédures, et peuvent être utilisable pour différentes applications et/ou buts.

   Le standard X.509 définis une CP comme un jeu nommé de règles qui indique l'applicabilité d'un certificat à une communauté et/ou classe d'application particulier avec les pré-requis de sécurité communs. Un certificat X.509v3 peut identifier une CP applicable spécifique, qui peut être utilisé par un tiers de confiance pour décider de faire confiance ou non à un certificat, la clé publique associée ou les signatures numériques vérifiées en utilisant la clé publique pour un but particulier.

   Il y a typiquement 2 catégories de CP. D'abord, certaines CP indiquent l'applicabilité d'un certificat à une communauté particulière. Ces CP présentent les pré-requis pour l'utilisation de certificat et les pré-requis des membres d'une communauté. Par exemple, une CP peut se concentrer sur les besoins d'une communauté géographique, tel que les pré-requis de stratégie ETSI pour les CA émettant des certificats qualifiés. Également, une CP de ce type peut se focaliser sur les besoins d'une communauté de marché spécifique telle que les services financiers.

   La seconde catégorie de CP indique l'applicabilité d'un certificat à une classe d'applications avec des pré-requis de sécurité communs. Ces CP identifient un jeu d'applications ou d'utilisations pour les certificats et indique que ces applications ou utilisations nécessitent un certain niveau de sécurité. Ils sont ainsi exposés aux exigences PKI qui sont appropriés pour cet applications ou utilisation. Une CP dans cette catégorie créé souvent des jeux de pré-requis appropriés pour un certain niveau d'assurance fournis par les certificats, relatifs aux certificats émis conformément aux CP liés. Ces niveaux d'assurance peuvent correspondre à des classes ou des types de certificat.

   Par exemple, le Government of Canada PKI Policy Management Authority (GOC PMA) a établis 8 stratégies de certificat dans un seul document, 4 stratégies pour les certificats utilisé pour les signatures et 4 certificat pour les certificats utilisé pour le chiffrement. Pour chacune de ces applications, le document établis 4 niveaux d'assurances: rudimentaire, basique, moyen et élevé. Le GOC PMA décris certains types d'utilisation de signature numérique et de confidentialité, chacun avec un certain jeu de pré-requis de sécurité, et groupé en 8 catégories. Le GOC PMA établis ainsi les pré-requis PKI pour chacune de ces catégories, en créant 8 types de certificats, chacun fournissant des niveaux d'assurance rudimentaire, basique, moyen et élevé. La progression du niveau d'assurance rudimentaire à élevé correspond à l'augmentation du niveau de sécurité et d'assurance requis.

   Une CP est représentée dans un certificat par un numéro unique appelé un OID. Cet OID, ou au moins un "arc", peut être enregistré. Un "arc" est le début d'une séquence numérique d'un OID et est assigné à une organisation particulière. Le processus d'enregistrement suit les procédures spécifiées dans les standards ISO/IETC et ITU. Le partie qui enregistre l'OID ou l'arc peut également publier le texte d'un CP, pour être examiné par les tiers de confiance. Tout certificat va explicitement déclarer une seule CP ou, possiblement, être émis en accord avec un petit nombre de stratégies différentes. De telles déclaration apparaissent dans l'extension de stratégie de certificat des certificats X.509v3. Quand une CA place plusieurs CP dans une extension de stratégie de certificat d'un certificat, la CA affirme que le certificat est approprié pour utilisation en accord avec une des CP listées.

   Les CP constituent également une base pour un audit, accréditation, ou autre évaluation d'une CA. Chaque CA peut être évaluée avec une ou plusieurs stratégie de certificat ou CPS qui sont reconnus comme implémentés. Quand une CA émet un certificat CA pour une autre CA, le CA émettrice doit évaluer le jeu de stratégie de certificats pour lequel il trust le sujet. Le jeu évalué est ainsi indiqué par la CA émettrice dans le certificat CA. Le traitement logique du chemin de certification X.509 emploie ces indication CP dans son modèle de validation.

Exemples de stratégie de certification

   Dans un but d'exemple, supposons que l'International Air Transport Association ( IATA ) s'engage à définir certaines stratégies de certificat pour l'utilisation dans l'industrie du transport aérien, dans une PKI opérée par IATA en combinaison avec les PKI opérés par les transports aériens individuels. 2 CP peuvent être définis - l'IATA General-Purpose CP, et l'IATA Commercial-Grade CP.

   L'IATA General-Purpose CP pourrais être utilisé par l'industrie pour protéger les informations de routine (ex: mails) et pour authentifier les connexions depuis les navigateurs web vers les services d'informations générales. Les paires de clé sont générées, stockées, et gérées en utilisant des systèmes à base de logiciel et à faible coût, tels que les navigateurs commerciaux. Sous cette stratégie, un certificat peut être automatiquement émis à tous les employés dans l'annuaire de l'IATA ou un membre qui a envoyé une demande de certificat signée par le biais d'un administrateur réseaux dans son organisation.

   L'IATA Commercial-Grade CP pourrait être utilisé pour protéger les transactions financières ou lier les échanges contractuels entre les entreprises. Sous cette stratégie, l'IATA pourrait imposer que les paires de clé certifiées soient générées et stockées dans des jetons hardwares cryptographiques approuvés. Les certificat et jetons pourraient être fournis aux employés avec une autorité de validation. Les individus autorisés peuvent ainsi être obligés d'être présents dans le bureaux de sécurité de l'organisation, montrer un badge d'identification valide, et signer un agrément de souscripteur qui leur impose de protéger le jeton et de l'utiliser seulement pour les buts autorisés.

Champs de certificat X.509

Les extensions X.509 suivant sont utilisés pour supporter les CP:

- Extension de stratégies de certificat
- Extension de mappage de stratégie
- Extension de contrainte de stratégie

Extension de stratégie de certificat

   Un champ de stratégies de certificat liste les CP que l'autorité de certification déclare comme applicable. En utilisant l'exemple de l'IATA General-Purpose et Commercial-Grade définis plus haut, les certificats émis pour les employés normaux vont contenir l'identifiant d'objet pour la stratégie à but générale. Les certificats émis pour les employés avec autorité de validation vont contenir les identifiants d'objets pour les 2 stratégies. L'ajout des 2 stratégies dans les certificats signifie qu'ils sont appropriés pour les 2 stratégies. Ces stratégies de certificat peuvent également être optionnellement transmettre les valeurs de qualifiants pour chaque stratégie identifié.

   En traitant un chemin de certification, un CP qui est acceptable pour l'application doit être présent dans tous les certificats dans le chemin, par ex., dans les certificats CA et les certificat EE.

   Si le champ de stratégies de certificats est marqué critique, il sert le même but que décris plus haut mais a un rôle additionnel. Spécifiquement, il indique que l'utilisation du certificat est restreint à une des stratégies identifiées, par ex, l'autorité de certification déclare que le certificat doit seulement être utilisé en accord avec les dispositions d'au moins une CP listée. Ce champ est prévu pour protéger l'autorité de certification contre les réclamations pour des dommages causés par un tiers de confiance qui a utilisé le certificat dans un but inapproprié ou d'une manière inapproprié, comme stipulé dans la CP applicable.

   Par exemple, l'Internal Revenue Service peut émettre des certificat pour les contribuables dans le but de protéger les déclarations fiscales. L'Internal Revenue Service peut comprendre et accommoder les risques lié à l'émission de mauvais certificat, par ex, à un imposteur. Supposons, cependant, que quelqu'un à utilisé un certificat comme base pour le chiffrement de secrets commerciaux à plusieurs millions de dollars, qui tombent ensuite dans de mauvaises mains suite à une attaque par cryptanalytique par un attaquant qui est capable de déchiffrer le message. L'Internal Revenue Service peut vouloir se défendre lui-même contre les réclamations de dégâts dans de telles circonstances en pointant la criticité de l'extension des stratégies de certificat pour montrer la mauvaise utilisation du certificat par le souscripteur et le tiers de confiance. L'extension de stratégies de certificat marquée critique est prévue pour limiter les risques de la CA dans de telles situations.

Extension de mappage de stratégie

L'extension de mappage de stratégie peut seulement être utilisé dans les certificats CA. Ce champ permet à une autorité de certification d'indiquer que certaines stratégies dans son propre domaine peuvent être considérés équivalents à d'autres stratégies dans le domaine du sujet de l'autorité de certification.

Par exemple, supposons que pour faciliter l'interopérabilité, l'ACE Corporation établis un agrément avec ABC Corporation pour cross-certifier les clés publiques de chaque autorité de certification pour sécuriser mutuellement leur échanges respectifs. De plus, supposons que les 2 entreprises ont des stratégies de protection de transaction financières pré-existantes appelées ace-e-commerce et abc-e-commerce, respectivement. On peut voir que générer simplement les cross-certificats entre les 2 domaines ne fournis pas l'interopérabilité, vu que les 2 applications d'entreprises sont configurées avec, en les certificats des employés sont renseignés avec, leur stratégies de certificat respectifs. Une possibilité est de reconfigurés toutes les applications financières pour imposer une des 2 stratégies et de ré-émettre tous les certificats avec les 2 stratégies apparaissant dans l'extension de stratégies de certificat. Une autre solution, qui peut être plus simple à administrer, utilise le champ de mappage de stratégie. Si ce champ est inclus dans un cross-certificat pour l'autorité de certification d'ABC Corporation émis par l'autorité de certification de ACE Corporation, il peut fournir une déclaration que la stratégie de protection des transactions financières de ABC (ex: abc-e-commerce) peut être considéré équivalent à celle de ACE Corporation (ex: ace-e-commerce). Avec une telle déclaration inclue dans le cross-certificat émis à ABC, les applications tiers dans le domaine ACE nécessitent la présence de l'identifiant d'objet pour que la CP ace-e-commerce soit également acceptée, traitée, et validée une fois les certificats émis dans le domaine ABC contenant l'identifiant d'objet pour la CP abc-e-commerce.

Extension de contraintes de stratégie

L'extension de contraintes de stratégie supporte 2 fonctionnalités optionnelles. La première est la capacité pour une autorité de certification de nécessiter que les indications de CP explicites soient présents dans tous les certificats suivant dans la chaîne de certification. Les certificats au début d'un chemin de certification peuvent être considérés par un tiers de confiance comme partie d'un domaine de confiance, par ex, les autorités de certification sont validés pour tous les buts donc aucune CP n'est nécessaire dans l'extension de stratégies de certificat. De tels certificats n'ont pas besoin d'indications explicites de CP. Quand une autorité de certification dans le domaine, cependant, certifie en dehors du domaine, il peut activer les pré-requis d'un CP qui doit apparaître dans les certificats suivants dans le chemin de certification.

L'autre fonctionnalité optionnelle dans le champ de contraintes de stratégie est la capacité pour une autorité de certification de désactiver le mappage de stratégie pour les autorités de certification suivant dans la chaîne de certification. Il peut être prudent de désactiver le mappage de stratégies en certifiant en dehors du domaine. Cela peut aider à contrôler les risques dus à des trusts de transitions.

Qualifiants de stratégie

   Le champ d'extension de stratégies de certificat comporte une disposition pour le transport, avec chaque identifiant de CP, d'informations se stratégie dans le champ qualifier. Le standard X.509 ne mandate pas le but lequel ce champ est utilisé, ni ne décris la syntaxe pour ce champ. Les types de qualifiants de stratégie peuvent être enregistrés par une organisation.

   Les types de qualifiants de stratégie suivant sont définis dans la rfc3280:

a) Le CPS Pointer contient un pointer vers une CPS, sommaire de CPS, RPA, ou PDS publié par la CA. Le pointeur est sous la forme d'une URI.
b) Le User Notice contient une chaîne texte qui est affiché au souscripteur et les tiers de confiance avant l'utilisation du certificat. Le texte peut être un IA5String ou BMPString. Une CA peut invoquer une procédure qui nécessite que la prise de connaissance par le tiers de confiance des termes applicables et des conditions d'utilisation.

   Les qualifiants de stratégie peuvent être utilisé pour supporter la définition de CP génériques ou paramétrisés. En fournissant la CP de base, les types de qualifiants de stratégie peuvent être définis pour transmettre, sur une base par-certificat, des détails de stratégie spécifiques additionnels qui complète la définition générique.

Déclaration de pratique de certification

   Le terme certification practice statement (CPS) est définis par le DSG et PAG en tant que "déclaration de pratique qu'un autorité de certification emploie pour émettre des certificats". Comme statué plus haut, une CPS établis les pratiques concernant le cycle de vie des services en plus de l'émission, tel que la gestion de certificat (incluant la publication et l'archivage), la révocation, et le renouvellement. Dans le DSG, le ABA étend cette définition avec les commentaires suivants:

   "Une déclaration de pratique de certification peut prendre la forme d'une déclaration par l'autorité de certification des détails de son système fiable et les pratiques qu'elle emploie dans ses opérations et dans le support d'émission d'un certificat." Cette forme de CPS est le type le plus commun, et peut varier en longueur et en niveau de détail.

   Certaines PKI peuvent ne pas avoir besoin de créer de déclaration détaillée et approfondie des pratiques. Par exemple, la CA peut elle-même être le tiers de confiance et sera toujours conscient de la nature et de la fiabilité de ses services. Dans d'autres cas, une PKI peut fournir des certificats fournissant seulement un très bas niveau d'assurance où les applications à sécuriser peuvent causer seulement des risques marginaux s'il sont compromis. Dans ces cas, une organisation établissant une PKI peut seulement vouloir écrire ou avec des CA utilisant un agrément de souscripteur, agrément de tiers de confiance, en fonction du rôle des différents participants de PKI. Dans de telles PKI, cet agrément peut servir comme seule déclaration de pratique utilisé par une ou plusieurs CA dans cette PKI. En conséquence, cet agrément peut également être considéré une CPS et peut être intitulé ou sous-titré comme tel.

   Également, vu qu'une CPS détaillée peut contenir des détails sensible de son système, une CA peut choisir de ne pas publier l'entièreté du CPS. Elle peut choisir de ne publier qu'une CPS sommaire ( ou CPS abstrait ). La CPS sommaire contient seulement les dispositions de la CPS que la CA considère être pertinents pour les participants dans la PKI (tel que les responsabilités des tiers ou les étapes du cycle de vie du certificat). Une CPS sommaire, cependant, ne contient pas les disposition sensibles de la CPS complète qui peut fournir à un attaquant les informations utiles sur les opérations de la CA. Tout au long de ce document, l'utilisation de CPS inclus la CPS détaillée et la CPS sommaire.

   Les CPS ne constituent pas automatiquement des contrats et ne lie pas automatiquement les participants de la PKI comme un contrat le ferai. Lorsqu'un document sert de double objectif d'agrément de souscripteur ou tiers de confiance et CPS, le document est prévu pour être un contrat et constitue un contrat liant dans la mesure où un agrément de souscripteur ou de tiers de confiance serait considéré comme tel. La plupart des CPS, cependant, ne sont pas à double usage. Ainsi, dans beaucoup de cas, les termes de la CPS ont un effet lié comme termes de contrat seulement si un document séparé créé une relation contractuelle entre les parties et que ce document incorpore une partie ou toute la CPS en référence. De plus, si une PKI particulière emploie une CPS sommaire, la CPS sommaire peut être incorporé dans un agrément de souscripteur ou de tiers de confiance applicable.

   Dans le future, un tribunal ou une loi statutaire ou réglementaire applicable peut déclarer qu'un certificat lui-même est un document qui est capable de créer une relation contractuelle, pour étendre ses mécanismes conçus pour être incorporé par référence ( tel que l'extension de stratégies de certificat et ses qualifiants ) indique que les termes d'utilisation apparaissent dans certains documents. Pendant ce temps, cependant, certains agréments de souscripteurs et tiers de confiance peuvent incorporer une CPS par référence et ainsi prendre ses dispositions sur les parties de tels accords.

Relation entre CP et CPS

   Les CP et CPS adressent le même jeu de sujets qui sont d'interêt pour un tiers de confiance en terme de degré à et le but pour lequel un certificat à clé publique devrait être trusté. Leur principales différences sont dans le focus de leurs disposition. Un jeu CP énonce les pré-requis et les standards imposés par la PKI en respect de divers sujets. En d'autres termes, le but du CP est d'établir ce que les participants doivent faire. Une CPS, en contraste, status comment une CA et d'autres participants dans un domaine donné implémentent les procédures et contrôles pour répondre aux pré-requis statués dans la CP. En d'autres termes, le but de la CPS est de déclarer comment les participants effectuent leur fonction et implémentent les contrôles.

   Une autre différence relate le périmètre de couverture des 2 types de document. Vu qu'une CP est une déclaration des pré-requis, il est préférable pour communiquer un guide d'exploitation minimum qui doivent être rencontrés par les PKI intéropérantes. Donc, une CP s'applique généralement à plusieurs CA, plusieurs organisations, ou plusieurs domaines. En contraste, une CPS d'applique seulement à une simple CA ou une simple organisation.

   Un CA avec une seule CPS peut supporter plusieurs CP ( utilisés pour différentes applications et/ou différentes communautés tiers de confiance ). Également, plusieurs CA, avec des CPS différentes, peuvent supporter la même CP.

   Par exemple, le gouvernement fédéral peut définir une CP globale au gouvernement pour gérer les informations de ressources humaines confidentielles. La CP sera une déclaration générale des pré-requis pour les participants dans la PKI du gouvernement, et une indication des types d'applications pour lesquelles elle est prévue. Chaque département ou agence souhaitant opérer une autorité de certification dans cet PKI peut nécessiter l'écriture de sa propre CPS pour supporter cette CP en expliquant comment elle gère les pré-requis de la CP. Dans le même temps, un CPS de département ou agence peut supporter d'autres stratégies de certificat.

   Une autre différence entre une CP et une CPS concerne le niveau de détail des dispositions. Bien que le niveau de détail peut varier dans les CPS, une CPS va généralement être plus détaillée qu'un CP. Une CPS fournis une description détaillée des procédures et contrôles en places pour se conformer aux requis de la CP, alors que la CP est plus générale.

   Les principales différences entre CP et CPS peuvent être résumés comme suit:

a) Une PKI utilise une CP pour établir les requis qui statuent sur ce que les participants doivent faire. Une simple CA ou organisation peut utiliser une CPS pour divulguer comment elle se conforme aux requis d'une CP ou comment elle implémente ses pratiques et contrôles.
b) Une CP facilite l'interopérabilité entre cross-certification, certification unilatérale, ou d'autres moyens. De plus, elle est prévue pour couvrir plusieurs CA. En contraste, une CPS est une déclaration d'une seul CA ou organisation. Son but n'est pas de simplifier l'interopération.
c) Une CPS est généralement plus détaillée qu'une CP et spécifie comment la CA se conforme aux requis spécifiés dans une ou plusieurs CP sous lesquelles elle émet des certificats.

   En plus de populer l'extension de stratégies de certification avec l'OID de la CP applicable, une autorité de certification peut inclure, dans les certificats quelle émet, une référence à ses CPS.

Relation entre CP, CPS et d'autres documents

   CP et CPS jouent un rôle centrale en documentant les pré-requis et pratiques d'une PKI. Cependant, ce ne sont pas les seuls documents. Par exemple, les agréments de souscripteur et les agréments de tiers de confiance jouent un rôle critique en allouant les responsabilités des souscripteur et tiers de confiance liés à l'utilisation de certificats et des paires de clé. Ils établissent les termes et conditions sous lesquelles les certificats sont émis, gérés, et utilisés. Le terme agrément de souscripteur est définis par le PAG comme: "un agrément entre une CA et un souscripteur qui établis les droits et obligation des parties au regard de l'émission et la gestion des certificats". Le PAG définis un agrément de tiers de confiance comme: "un agrément entre une autorité de certification et un tiers de confiance qui établis typiquement les droits et obligations entre ces parties au regard de la vérification des signatures numériques ou d'autres utilisations de certificats".

   Comme mentionné précédemment, un agrément de souscripteur, un agrément de tiers de confiance, ou un agrément qui combine les 2 peut également service de CPS. Dans d'autres PKI, cependant, un agrément de souscripteur ou de tiers de confiance peut incorporer certains ou tous les termes d'une CP ou CPS par référence. D'autre PKI encore peuvent distiller depuis une CP et/ou CPS les termes qui sont applicables au souscripteur et place de tels termes dans un agrément de souscripteur auto-contenu, sans incorporer de CP ou CPS par référence. Elles peuvent utiliser la même méthode pour distiller les termes de tiers de confiance depuis une CP et/out CPS et placer de tels termes dans un agrément de tiers de confiance. Créer de tels agrément auto-contenus a l'avantage de créer des documents qui sont plus faciles à lire par les consommateurs. Dans certains cas, les souscripteur et les tiers de confiance peuvent être considérés comme des consommateurs sous une loi applicable, qui sont sujets aux lois civiles des pays, incorporer une CP ou une CPS par référence peut ne pas être efficace pour lier les consommateurs aux termes dans une CP ou CPS incorporé.

   Les CP et CPS peuvent être incorporés par référence dans d'autres documents, incluant:

- Agréments d'interopérabilité ( incluant les agréments entre les CA pour la cross-certification, la certification unilatérale, ou d'autres formes d'interopération ).
- Agréments de vendeur ( sous lequels un vendeur de PKI accepte de se conformer aux normes énoncées dans une CP ou CPS ).
- Un PDS

   Un PDS a une fonction similaire à une CPS sommaire. C'est un document relativement court contenant seulement un sous-jeu de détails critiques sur une PKI ou CA. Il peut différer d'une CPS sommaire, cependant, dans son but qui est d'agir comme sommaire d'information sur la nature globale de la PKI, en contraste à une forme condensée d'une CPS.

   De plus, son but est de distiller les informations sur la PKI, en opposé à la protection d'information sensible de sécurité contenu dans une CPS non-publiée, bien qu'un PDS pourrait servir également cette fonction.

   Tout comme un rédacteur pourrait souhaiter référer à une CP ou CPS ou l'incorporer par référence dans un agrément ou PDS, une CP ou CPS peut référer à d'autres documents lors de l'établissement des requis ou en définissant les déclarations. Par exemple, une CP pour définir les requis pour le contenu de certificat en se référant à un document externe énonçant un profile de certificat standard. Référencer des documents externes permet à une CP ou CPS d'imposer des requis détaillés ou des déclarations détaillées sans avoir à ré-écrire les dispositions longue depuis d'autres documents dans la CP ou CPS. De plus, référencer un document dans une CP ou CPS est une autre manière utile de diviser les dispositions entre les informations publique et les informations confidentielles sensibles ( en plus de ou comme alternative à une CPS sommaire ). Par exemple, une PKI peut souhaiter publier une CP ou CPS, mais maintenir les paramètres de construction du site pour une CA comme information confidentielle. Dans ce cas, la CP ou CPS pourrait référencer un manuel externe ou un document contenant ces paramètres détaillés.

   Les documents qu'une PKI peut souhaiter faire référence dans une CP ou CPS incluent:

- Une stratégie de sécurité
- Manuels de formation, opérationnel, installation, et utilisateurs ( qui peuvent contenir des requis opérationnels )
- Plans de gestion de clés
- Guides de ressources humaine et manuels d'embauche ( qui peuvent décrire certains aspects de pratiques de sécurité personnel )
- Stratégie d'email ( qui peut discuter des responsabilités des souscripteurs et tiers de confiance, aussi bien que les implications de gestion de clé, si applicable )

Jeu de disposition

   Un jeu de dispositions est une collection de pratiques et/ou déclarations de stratégies, couvrant un éventail de sujets à utiliser dans l'expression d'une CP ou CPS employant l'approche décrite dans ce framework.

   Une CP peut être exprimée comme un seul jeu de dispositions

   Une CPS peut être exprimée comme un seul jeu de dispositions avec chaque composant adressant les requis d'une ou plusieurs stratégie de certificat, ou, alternativement, comme une collection organisée de jeux de dispositions. Par exemple, une CPS pourrait être exprimées comme un combinaison des éléments suivants:

a) Une liste de stratégies de certificats supportés par la CPS;
b) Pour chaque CP dans (a), un jeu de dispositions qui contiennent les déclarations répondant à cette CP en ajoutant les détails non stipulés dans la stratégie ou expressément laissée à la discrétion de la CA (dans ses CPS); de telles déclarations servent à statuer comment cette CPS particulière implémente les requis d'une CP particulière, ou
c) Un jeu de dispositions qui contiennent des déclarations de pratique de certification dans la CA, sans regarder la CP.

   Les déclarations fournies dans (b) et (c) peuvent augmenter ou affiner les stipulations de la CP applicable, mais ne doit généralement pas être en conflit avec une des stipulations d'une telle CP. Dans certains cas, cependant, une autorité de stratégie peut permettre des exceptions aux pré-requis dans une CP, parce que certains contrôles de compensation de la CA sont décris dans sa CPS, qui permet à la CA de fournir des assurances qui sont équivalents aux assurances fournies par les CA qui sont complètement conformes avec la CP.

   Ce framework dessine le contenu d'un jeu de dispositions, en terme de 9 composants principaux, comme suit:

1. Introduction
2. Publication et dépôt
3. Identification et Authentification
4. Pré-requis opérationnels du cycle de vie de certificat
5. Installation, gestion, et contrôles opérationnels
6. Contrôles de sécurité techniques
7. Profiles de certificat, CRL, et OCSP
8. Audit de conformité
9. Autres affaires et questions juridiques

   Les PKI peuvent utiliser ce simple framework de 9 composant primaires pour écrire une CP ou CPS simple. De plus, une CA peut utiliser ce framework pour écrire des agréments de souscripteur et/ou de tiers de confiance. Si une CA utilise ce framework pour construire un agrément, il peut utiliser le paragraphe 1 comme introduction, peut exposer les responsabilités des parties dans le paragraphe 2-8, et peut utiliser le paragraphe 9 pour couvrir les problèmes légaux et commerciaux décris plus en détail plus bas. L'ordre des sujets dans ce simple framework et les questions juridiques et de business est le même que l'ordre des sujets dans un logiciel typique ou d'autres agréments technologiques. Cependant, une PKI peut établir un jeu de documents centraux ( avec une CP, CPS, agrément de souscripteur et de tiers de confiance ) ayant tous la même structure et ordre des sujets, facilitant ainsi les comparaisons et les mappages entre ces documents et entre les documents correspondant d'autres PKI.

   Ce simple framework peut également être utile pour les agrément autre que les agréments de souscripteur et de tiers de confiance. Par exemple, une CA souhaitant externaliser certains services à une RA ou une autorité de fabrication de certificat ( certificate manufacturing authority (CMA) ) peuvent trouver utile d'utiliser ce framework comme checklist pour écrire un agrément d'autorité d'enregistrement ou d'externalisation. Similairement, 2 CA peuvent souhaiter utiliser ce framework pour définir une cross-certification, certification unilatérale, ou d'autre agréments d'interopérabilité.

   Les composants primaires du framework peuvent rencontrer les besoins des rédacteurs de CP, CPS et agréments cours. Cependant, ce framework est extensible, et sa couverture de 9 composants est suffisamment flexible pour s'adapter aux besoins des rédacteurs de CP et CPS. Spécifiquement, les composants apparaissant ci-dessus peuvent comprendre plusieurs éléments. La section suivante fournis une description plus détaillée du contenu des composants et leur sous-composants. Les rédacteurs de CP et CPS sont autorisés à ajouter des niveaux additionnels de sous-composants sous les sous-composant pour correspondre à leurs besoins.

Contenu du jeu de dispositions

   Cette section étends le contenu du framework de dispositions. Les sujets identifiés dans cette section sont, en conséquence, des sujets candidats pour être inclus dans une CP ou CPS détaillée.

   bien que de nombreux sujets sont identifiés, il n'est pas nécessaire pour une CP ou une CPS d'inclure une déclaration concrète pour chaque sujet. À la place, une CP ou CPS particulière peut indiquer "aucune stipulation" pour un composant, sous-composant, ou élément sur lequel la CP ou CPS n'impose aucun requis ou ne divulgue rien. En ce sens, la liste des sujets peut être considéré comme une checklist de sujets pour aider à la rédaction d'une CP ou CPS.

   Il est recommandé que chaque composant et sous-composant soit inclus dans une CP ou CPS, même s'il n'y a aucune stipulation; cela indique au lecteur qu'une décision consciente a été faite d'inclure ou exclure une disposition concernant ce sujet. Ce style de rédaction protège contre les oublis par inadvertance d'un sujet, tout en facilitant la comparaison de différentes stratégies de certificat ou CPS.

   Dans une CP, il est possible de laisser certains composants, sous-composants et/ou élément non-spécifiés, et pour stipuler que les informations requises seront indiquées dans un qualifiant de stratégie, ou le document vers lequel le qualifiant de stratégie pointe. Le jeu de dispositions devrait référencer ou définir les types de qualifiant de stratégie requis et devrait spécifier les valeurs par défaut applicables.

1. Introductions

Ce composant identifie et introduit le jeu de dispositions, et indique les types d'entité et applications pour lesquels le document écris.

1.1 Vue générale

Ce sous-composant fournis une introduction générale au document. Ce sous-composant peut également être utilisé pour fournir un synopsis de la PKI pour laquelle la CP ou CPS s'applique. Par exemple, il peut définir différents niveaux d'assurance fournis par les certificats dans une PKI particulière, une représentation diagrammatique de la PKI être utile ici.

1.2 Nom du document et identification

Ce sous-composant fournis des noms applicable ou d'autres identifiants incluant les identifiants d'objets ASN.1, pour le document. Un exemple d'un tel nom de document serait "US Federal Government Policy for Secure E-mail".

1.3 Participants de la PKI

Ce sous-composant décris l'identité ou les types d'entités qui ont un rôle de participant dans une PKI:

Autorités de certification, Par ex, les entités qui émettent des certificat. Une CA est la CA émettrice respectant le certificat CA qui lui a été donné. Les CA peuvent être organisés hiérarchiquement dans laquelle une CA d'organisation émet des certificats à des CA opérés par des organisations subordonnées, comme une branche, une division, ou un département dans une plus grande organisation.
autorités d'enregistrement, par ex, les entités qui établissent les procédures d'enrôlement pour les candidats de certificats finaux, l'identification et l'authentification pour les candidats de certificats, et l'initialisation des demandes de révocation pour les certificats, et les approuver le renouvellement ou le changement de clé des certificats. Les organisations subordonnées dans une grande organisation peuvent agir comme RA pour la CA servant toute l'organisation, mais les RA peuvent également être externe à la CA.
souscripteurs des exemples de souscripteurs qui reçoivent des certificats d'une CA incluent les employés d'une organisation avec sa propre CA, les clients de banque ou de courtage, organisations hébergeant des sites de e-commerce, etc.
Tiers de confiance. Des examples de tiers de confiance incluent les employés d'une organisation ayant sa propre CA qui reçoit des emails signés par d'autres employs, les clients d'un site e-commerce, les organisations participant à un échange business-to-business, etc.
Autres participants, tels que les autorités de fabrique de certificat, les fournisseurs de services de dépôt, et d'autres entités fournissant des service liés à la PKI.

1.4 Utilisation de certificat

Ce sous-composant contient:

- Une liste ou les types d'applications pour lesquels les certificats émis sont utilisable, tels que les mails éléctroniques, les transactions de vente, contrats, ou ordre de voyage, et/ou
- Une liste ou les types d'applications pour lesquels l'utilisation des certificats est interdite.

Dans le cas d'une CP ou CPS décrivant différents niveaux d'assurance ce sous-composant peut décrire les application ou les types d'applications qui sont appropriés ou inappropriés pour les différents niveaux d'assurance.

1.5 Administration de stratégie

Ce sous-composant inclus le nom et l'adresse de l'organisation qui est responsable pour la rédaction, l'enregistrement, la maintenance, et la mise à jours de cette CP ou CPS. Il inclus également le nom, l'adresse email, numéro de téléphone, et numéro de fax d'une personne à contacter. Au lieu de nommer un personne, le document peut nommer un titre ou un rôle, un email alias, et d'autres informations généralisées. Dans certains cas, l'organisation peut statuer qui sa personne de contact, seule ou avec d'autre, est disponible pour répondre aux questions sur ce document.

De plus, quand une autorité de stratégie formelle ou informelle est responsable pour déterminer si une CA devrait être autorisée à opérer dans ou intéropérer avec une PKI, il peut être souhaitable d'approuver la CPS d'une CA comme étant utilisable pour l'a CP de l'autorité de stratégie. Si c'est le cas, ce sous-composant peut inclure le nom ou titre, adresse email, numéro de téléphone, fax, et autres informations généralisées de l'entité en charge de prendre de telles décisions. Finalement, dans ce cas, le sous-composant peut également inclure les procédures par lesquels cette détermination est faite.

1.6 Définitions et acronymes

Ce sous-composant contient une liste de définitions pour les termes définis utilisés dans ce document, aussi bien qu'une liste d'acronymes dans le document leur signification.

2 Responsablités de publication et de dépôt

Ce composant contient les dispositions applicable avec:

- Une identification de l'entité ou les entités qui opèrent les dépôts dans la PKI, tels qu'une CA, CMA, ou fournisseur de service de dépôt indépendant
- La responsabilité d'un participant de PKI pour publier les informations de pratiques, certificat, et le statuts courant de tels certificats, qui peuvent inclurent les responsabilités de rendre la CP ou CPS disponible au publique en utilisant divers mécanismes en identifiant les composants, sous-composants, et élément de tels documents qui existent mais ne sont pas publiquement disponible, par exemple, les contrôles de sécurité, les procédures de dédouanement, ou information secrètes.
- Quand les informations doivent être publiés et la fréquence de publication, et
- le contrôle d'accès sur les objets publiés incluant les CP, CPS, certificats, statuts de certificats, et CRL.

3 Identifiation et authentification

Ce composant décris les procédures utilisées pour authentifier l'identité et/ou les autres attributs d'un utilisateur demandant un certificat à une CA ou une RA avant de recevoir le certificat. En plus, le composant énonce les procédures pour authentifier l'identité et les critères d'accèptation des demandes des entités cherchant à devenir un CA, RA, ou d'autres entités opérant dans ou intéropérant avec la PKI. Il décris également comment les parties demande un renouvellement de clé ou une révocation sont authentifiés. Ce composant adresse également les pratiques de nommage, incluant la reconnaissance des droits de marque dans certains noms.

3.1 Nommage

Ce sous-composant inclus les éléments suivants pour le nommage et l'identification des souscripteurs:

- Les types et noms assignés au sujet, tel que les DN X.500, noms rfc822, et noms X.400.
- Si les noms doivent avoir un sens ou non
- Si les souscripteurs peuvent être anonymes ou des pseudonymes, et s'ils le peuvent, quels noms leur sont assignés ou peuvent être utilisé par les souscripteurs anonymes.
- Les règles pour interpréter divers formes de nom, tels que le standard X.500 et rfc822.
- Si les nom doivent être uniques, et
- La reconnaissance, l'authentification, et le rôle des marques.

3.2 Validation initiale de l'identité

Ce sous-composant contient les éléments suivant pour les procédures d'identification et d'authentification pour l'enregistrement initial de chaque type de sujet (CA, RA, souscripteur, ou autre participant):

- Si et comment le sujet doit prouver la possession d'une clé privée associée à la clé privée en cours d'enregistrement, par exemple, une signature numérique dans le message de demande de certificat.
- Les requis d'identification et d'authentification pour l'entité organisationnelle du souscripteur ou du participant (CA, RA, souscripteur, ou autre participant), par exemple, en consultant la base d'un service qui identifie les organisations ou en inspectant les statuts de l'organisation.
- Les requis d'identification et d'authentification pour un souscripteur ou une personne agissant pour le compte d'une organisation ou d'un participant (CA, RA, dans le cas de certificats émis aux organisation ou périphériques contrôles par une organisation, souscripteur, ou autre participant), incluant:

- Le type de documentation et/ou le nombre de référence d'identification requis.
- Comment une CA ou RA authentifie l'identité de l'organisation ou individu basé sur la documentation ou les accréditifs fournies
- Si l'individu doit se présenter personnellement à la CA ou RA authentifiante.
- Comment un individu tel qu'une personne de l'organisation est authentifiée, tels que par référence à des documents d'autorisation signés ou un badge d'identification d'entreprise.

- La liste des informations de souscripteur qui n'est pas vérifiée durant l'enregistrement initial
- La validation de l'autorité implique de déterminer si une personne a des droits spécifiques ou des permissions incluant la permission d'agir pour le compte d'une organisation pour obtenir un certificat; et
- Dans le cas des applications par une CA souhaitant opérer dans, ou interopérer avec, une PKI, ce sous-composant contient le critère par lequel un PKI, CA, ou autorité de stratégie détermine si la CA est prévue pour de telles opérations ou intéropérations. Une telle intéropération peut inclure la cross-certification, certification unilatérale, ou d'autres formes d'intéropérations.

3.3 Identification et authentification pour les demande de renouvellement de clé

Ce sous-composant adresse les éléments suivant pour les procédures d'identification et d'authentification pour le renouvellement de clé pour chaque type de sujet (CA, RA, souscripteur, ou autres participants).

- les requis d'identification et d'authentification pour les routines de renouvellement de clé, tel qu'une demande de renouvellement de clé qui contient la nouvelle clé et est signée en utilisant la clé actuellement valide, et
- Les requis d'identification et authentification pour le renouvellement de clé après la révocation de certificat. Un exemple est l'utilisation du même processus que pour la validation initiale

3.4 Identification et authentification pour les demandes de révocation

Ce sous-composant décris les procédures d'identification et d'authentification pour une demande de révocation pour chaque type de sujet (RA, CA, souscripteur, et autres participants).

4 Requis opérationnel du cycle de vie des certificats

Ce composant est utilisé pour spécifier les requis imposés en émettant des CA, sujets de CA, RA, souscripteurs, ou autres participants en respect avec le cycle de vie d'un certificat.

Dans chaque cous-composant, des considérations séparées peuvent être nécessaire à donner au sujet d'une CA, RA, souscripteurs, et autres participants

4.1 Demande de certificat

Ce sous-composant est utilisé pour adresser les requis suivant au regard de la demande de certificat:

- Qui peut émettre une demande de certificat, tel qu'un sujet de certificat ou la RA; et
- Le processus l'enrôlement utilisé par les sujets pour émettre des demandes de certificat et les responsabilités en connexion avec ce processus. Un exemple de ce processus est quand le sujet génère la paire de clé et envoie une demande à la RA. La RA valide et signe le demande et l'envoi à la CA. Une CA ou RA peut avoir la responsabilité d'établir le processus d'enrôlement pour pouvoir recevoir la demande. De même, les demandeurs de certificat peuvent avoir la responsabilité de fournir des informations précises sur leurs demandes de certificat.

4.2 Traitement des demandes de certificat

Ce sous-composant est utilisé pour décrire la procédure pour traiter les demandes de certificat. Par exemple, La CA et RA émettrice peut effectuer des procédures d'identification et d'authentification pour valider la demande de certificat. En suivant ces étapes, la CA ou RA va soit approuver soit rejeter la demande, éventuellement basé sur certains critères. Finalement, ce sous-composant définis la durée limite qu'une CA et/ou RA doit agir et traiter la demande.

4.3 Émission de certificat

Ce sous-composant est utilisé pour décrire les éléments suivant lié à l'émission de certificat:

- Les actions effectuées par la CA durant l'émission du certificat, par exemple une procédure par laquelle la CA valide la signature de la RA et l'autorité RA et génère un certificat; et
- Les mécanismes de notification, s'il y'en a, utilisé par la CA pour notifier le souscripteur de l'émission du certificat; par exemple, la procédure par laquelle la CA envoie par e-mail le certificat au souscripteur ou la RA ou les informations permettant au souscripteur de télécharger le certificat depuis un site web.

4.4 Acceptation de certificat

Ce sous-composant adresse les éléments suivant:

- La conduite d'un candidat qui sera considéré pour constituer l'acceptation du certificat. Une telle conduite peut inclure des étapes d'affirmation pour indiquer l'acceptation, les actions impliquant l'acceptation, ou un rejet du certificat ou de son contenu. Par exemple, l'acceptation peut être considéré si la CA n'a pas reçu de notification du souscripteur dans une certaine période de temps; un souscripteur peut envoyer un message signé acceptant le certificat; ou un souscripteur peut envoyer un message signé rejetant le certificat qui inclus la raison du rejet et identifie les champs dans le certificat qui sont incorrect ou incomplets.
- La publication du certificat par la CA. Par exemple, la CA peut poster le certificat dans un annuaire LDAP ou X.500.
- La notification de l'émission du certificat par la CA à d'autres entités. Par exemple, la CA peut envoyer le certificat à la RA.

4.5 Utilisation du certificat et de la paire de clé

Ce sous-composant est utilisé pour décrire les responsabilités liées à l'utilisation des clés et des certificats, incluant:

- La responsabilité du souscripteur lié à l'utilisation de la clé privée et du certificat du souscripteur. Par exemple, on peut imposer au souscripteur d'utiliser un clé privée et un certificat uniquement pour les applications appropriées comme indiquée dans la CP et en consistance avec le contenu du certificat (ex: le champ keyUsage). L'utilisation d'une clé privée et d'un certificat sont sujet aux termes de l'agrément du souscripteur, l'utilisation de la clé privée est permise seulement après que le souscripteur a accepté le certificat correspondant, ou le souscripteur doit arrêter l'utilisation de la clé privée après l'expiration ou la révocation du certificat.
- Les responsabilités des tiers de confiance liés à l'utilisation d'une clé publique de souscripteur et du certificat. Par exemple, un tiers de confiance peut être obligé de valider les certificats seulement pour les applications appropriées comme indiqué dans la CP et en consistance avec le contenu du certificat (ex: le champ keyUsage), exécuter avec succès les opération de clé publique comme condition de validation d'un certificat, assumer la responsabilité de vérifier le statut d'un certificat en utilisant un des mécanismes requis ou permis définis dans la CP/CPS, et le consentement des termes de l'agrément du tiers de confiance comme condition de validation de certificat.

4.6 Renouvellement de certificat

Ce sous-composant est utilisé pour décrire les éléments suivants liés au renouvellement de certificat. Le renouvellement de certificat signifie l'émission d'un nouveau certificat au souscripteur sans changer le souscripteur ou d'autres clé publiques du participant ou informations dans le certificat:

- Les circonstances sous lesquelles le renouvellement du certificat prend place, tel que lorsque le certificat a expiré, mais la stratégie permet de réutiliser la même paire de clé.
- Qui peut faire des demandes de renouvellement de certificat, par exemple, le souscripteur, la RA, ou la CA peut automatiquement renouveler un certificat EE.
- Les procédures de CA ou RA pour traiter les demandes de renouvellement pour émettre le nouveau certificat, par exemple, l'utilisation d'un jeton, tels qu'un mot de passe, pour ré-authentifier le souscripteur, ou les procédures qui sont les même qui l'émission d'un certificat initial.
- La notification d'un nouveau certificat au souscripteur
- La conduite constituant l'acceptation du certificat
- La publication du certificat par la CA
- La notification de l'émission du certificat par la CA à d'autres entités.

4.7 Renouvellement le clé

Ce sous-composant est utilisé pour décrire les éléments suivants liés à un souscripteur ou un autre participant générant une nouvelle paire de clé et application pour l'émission d'un nouveau certificat qui certifie la nouvelle clé publique:

- Les circonstances sous lesquelles le renouvellement de clé de certificat peut ou doit être fait, tels qu'après la révocation d'un certificat pour une raison de compromission de clé ou après qu'un certificat a expiré et que la période d'utilisation de la paire de clé a également expiré.
- Qui peut demander le renouvellement le clé de certificat, par exemple, le souscripteur
- Les procédures CA ou RA pour traiter les demandes de renouvellement de clé pour émettre le nouveau certificat, tel que les procédures qui sont les même que pour l'émission de certificat initial.
- La notification du nouveau certificat au souscripteur
- La conduite constituant l'acceptation du certificat
- La publication du certificat par la CA
- La notification de l'émission du certificat par la CA à d'autres entités.

4.8 Modification de certificat

Ce sous-composant est utilisé pour décrire les éléments suivant liés à l'émission d'un nouveau certificat du à des changement d'informations dans le certificat autre qui la clé publique:

- Les circonstances sous lesquelles la modification de certificat peut se faire, tels qu'un changement de nom, changement de rôle, réorganisation résultant en un changement dans le DN.
- Qui peut effectuer des demandes de modification de certificat, par exemple, les souscripteurs, personnel des ressources humaines, ou la RA.
- Les procédures CA ou RA pour traiter les demandes de modification pour émettre le nouveau certificat, tel que les procédures qui sont les même que pour l'émission initiale.
- Notification du nouveau certificat au souscripteur
- La conduite constituant l'acceptation du certificat
- La publication du certificat par la CA
- La notification de l'émission du certificat par la CA à d'autres entités.

4.9 Révocation et suspension de certificat

Ce sous-composant adresse les points suivants:

- Les circonstances sous lesquelles un certificat peut être suspendu et les circonstances sous lesquelles il doit être révoqué, par exemple, dans le cas ou un souscripteur termine sont contrat, perd son jeton cryptographique, ou suspecte la compromission de la clé privé
- Qui peut demander la révocation du certificat du participant, par exemple, le souscripteur, RA ou CA dans le cas d'un certificat EE.
- Les procédures utilisées pour les demandes de révocation de certificat, tels qu'un message signé numériquement de la RA, du souscripteur, ou un appel téléphonique de la RA.
- La période de grâce disponible au souscripteur, dans laquelle le souscripteur doit créer une demande de révocation.
- Le temps dans lequel la CA doit traiter la demande de révocation
- Les mécanismes, s'il y en a, que le tiers de confiance peuvent utiliser ou doivent utiliser pour vérifier le statut des certificats qui souhaitent valider.
- Si un mécanisme de CRL est utilisé, la fréquence d'émission
- Si un mécanisme de CRL est utilisé, le délai maximum entre la génération de la CRL et sa publication (en d'autres termes, le temps maximum de traitement)
- La disponibilité d'un mécanisme de vérification on-line, par exemple, OCSP.
- Les pre-requis des tiers de confiance pour effectuer des vérification de statut/révocation on-line
- D'autres formes d'annonce de révocation disponible
- Toutes variations des stipulations précédentes pour lesquelles la suspension ou la révocation est le résultat d'une compromission de clé privée
- Les circonstances sous lesquelles un certificat peut être suspendu
- Qui peut demander la suspension d'un certificat, par exemple, le souscripteur, le personnel des ressources humaines, un superviseur du souscripteur, ou la RA dans le cas d'un certificat utilisateur.
- Les procédures pour demander la suspension du certificat, tel qu'un message signé numériquement du souscripteur ou d'un RA, un appel téléphonique de la RA
- La durée de suspension

4.10 Services de statut de certificat

Ce sous-composant adresse les services de vérification de statut de certificat disponible aux tiers de confiance, incluant:

- Les caractéristiques opérationnelles des services de vérification de statut de certificat
- La disponibilité de tels services, et toutes stratégies applicables sur l'indisponibilité
- Toutes fonctionnalités optionnelles de tels services.

4.11 Fin de souscription

Ce sous-composant adresse les procédures utilisée pour les souscripteurs pour terminer la souscription des services CA, incluant:

- La révocation des certificat à la fin de la souscription ( qui peut différer, en fonction de si la fin de souscription est dûe à l'expiration du certificat ou la fin du service ).

4.12 dépôt et récupération de clé

Ce sous-composant contient les éléments pour identifier les stratégies et pratiques liées au dépôt, et/ou récupération des clés privées quand des services de dépôt de clés privée sont disponibles.

- Identification du document contenant les stratégies et pratiques de dépôt de clé et de récupération ou une liste de telles stratégies et pratiques
- Identification du document contenant les stratégies et pratiques d'encapsulation des clés de session ou une liste de telles stratégie et pratiques.

5. Gestion, opérationnel, et contrôles physiques

   Ce composant décris les contrôles de sécurité non-techniques (c'est à dire, les contrôles physiques, procédurales et personnelles) utilisées par la CA émettrice pour effectuer de manière sécurisée les fonctions de génération de clé, authentification du sujet, assurances de certificat, révocation de certificat, audit, et archivage.

   Ce composant peut également être utilisé pour définir des contrôles de sécurité non-techniques sur les dépôt, tels que les sujets CA, RA, souscripteurs, et autres participants. Les contrôles de sécurité non-techniques pour les CA, RA, souscripteurs, et autres participants peuvent être les mêmes, similaires, ou très différents.

   Ces contrôles de sécurité non-techniques sont critique pour valider les certificat vu qu'un manque de sécurité peut compromettre les opérations CA résultantes par exemple, en la création de certificats ou CRL avec des informations erronées ou la compromission de la clé privée de la CA.

   Dans chaque sous-composant, des considérations séparées vont, en général, être donnés à chaque type d'entité.

5.1 Contrôles de sécurité physiques

Dans ce sous-composant, les contrôles physiques sur les installation abritant les systèmes de l'entité sont décris:

- La construction et l'emplacement du site, tel que la pré-requis de construction pour des zones à haute sécurité et l'utilisation de salles fermées, cages, coffre-fort, et armoires.
- L'accès physique, par ex, les mécanismes de contrôles d'accès d'une zone à une autre ou l'accès à des zones de haute sécurité, tels que les opérations CA localisées dans une salle information sécurisée et supervisée par des gardiens ou des alarmes de sécurité.
- Puissance et climatisation
- Exposition à l'eau
- Prévention et protection contre le feu
- Stockage, par exemple, la nécessité d'un stockage de sauvegarde dans un emplacement séparé qui est sécurisé physiquement et protégé du feu et de l'eau.
- L'élimination des déchets
- sauvegarde hors-site

5.2 Contrôles procédurales

   Dans ce sous-composant, les pré-requis opur reconnaître les rôles de confiance sont décris, avec les responsabilités de chaque rôle. Des exemples de rôles de confiance incluent les administrateurs systèmes, les responsables de la sécurité, et les auditeurs système.

   Pour chaque tâche identifié, le nombre d'individus requis pour effectuer la tâche devrait être statué pour chaque rôle. L'identification et l'authentification requis pour chaque rôle peut également être définis.

   Ce composant inclus également la séparation des privilèges en termes de rôles qui ne peuvent pas être effectués par les même individus.

5.3 Contrôles de sécurité personnel

Ce sous-composant adresse les éléments suivant:

- Qualifications, expérience, et habilitations que le personnel doit avoir comme condition pour jouer ces rôles de confiance ou d'autres rôles importants. Par exemple les accréditifs, expérience professionnelle, et habilitations gouvernementales que les candidats à ces positions doivent avoir.
- La vérification des antécédents et des procédures d'habilitations qui sont requis dans le cadre de l'embauche de personnel remplissant des rôles de confiance ou d'autres rôles importants; de tels rôles peuvent nécessiter une vérification de leur casier judiciaire, références, et habilitations additionnelles qu'un participant engage après une décision d'embauche d'une personne particulière.
- Formations requises et procédures de formations pour chaque rôle qui suivent l'embauche.
- Toute période de renouvellement et les procédures de renouvellement pour chaque rôle après l'achèvement de la formation initiale.
- La fréquence et la séquence de la rotation des postes sur divers rôles
- Les sanctions contre le personnel pour les actions non autorisées, l'utilisation d'autorité non autorisée, l'utilisation non autorisé des systèmes dans le but d'imposer la responsabilité sur un participant.
- Les contrôles du personnel qui sont des indépendant aux lieu d'employés de l'entité, par exemple:

- Exigences de cautionnement sur le personnel sous contrat
- Les exigences contractuelles, y compris l'indemnisation des dommages dûs à des actions du personnel en contrat
- L'audit et la supervision du personnel en contrat
- D'autres contrôles sur le personnel en contrat

- La documentation à fournir au personnel durant la formation initiale, le renouvellement, ou autre.

5.4 Procédures d'audit de connexion

Ce sous-composant est utilisé pour décrire les évènements de connexion et les systèmes d'audit, implémentés dans le but de maintenir un environnement sécurisé.

- Les types d'évènements enregistrés, tels que les opérations sur le cycle de vie des certificats, tentatives d'accès au système, et requêtes faites au système.
- Fréquence à laquelle les logs d'audits sont traités ou archivés, par exemple, chaque semaine, suivant un évènement anormal ou d'alerte, ou quand le log d'audit est plein.
- Période pour laquelle les données d'audit sont conservées
- Protection des logs d'audit:

- Qui peut voir les logs d'audit, par exemple, les administrateurs d'audit
- La protection contre la modification des logs d'audit, par exemple une exigence qu'aucune modification ou suppression les enregistrements d'audit ou que seul l'administrateur d'audit peut supprimer un fichier d'audit comme partie de la rotation du fichier d'audit
- Protection contre la suppression des logs d'audit.

- Procédures de sauvegarde des log d'audits
- Si le système de d'accumulation des logs d'audits est interne ou externe à l'entité
- Si le sujet qui à causé un évènement d'audit est notifié de l'action d'audit
- L'évaluation des vulnérabilité, par exemple, où les données d'audit sont lancées via un outils qui identifie les tentatives potentielles pour casser le système de sécurité

5.5 Archivage des données d'enregistrement

Ce sous-composant est utilisé pour décrire les stratégies d'archivage des enregistrements:

- Les types d'enregistrement qui sont archivés, par exemple, toutes les données d'audit, les information d'application de certificat, et la documentation supportant les applications de certificat.
- La période de rétention pour une archive
- La protection d'une archive

- Qui peut voir l'archive, par exemple, seulement l'administrateur d'audit
- La protection contre la suppression de l'archive
- La protection contre la détérioration du support sur lequel l'archive est stockée, tel que la migration des donnée périodiquement sur un nouveau support.
- La protection contre l'obsolescence du matériel, systèmes d'exploitation et autres logiciels.

- Les procédure de sauvegarde des archives
- Les pré-requis pour l'horodatage des enregistrements
- Si le système de collecte d'archive est interne ou externe
- Les procédures pour obtenir et vérifier les informations d'archive, tels que le besoin de maintenir 2 copies de l'archive sous le contrôle de 2 personnes, et que les 2 copies soient comparées pour s'assurer que les informations sont valides.

5.6 Renouvellement des clés

Ce sous-composant décris les procédures pour fournir une nouvelle clé aux utilisateurs de la CA après un renouvellement de clé par la CA. Ces procédures peuvent être les même que les procédures pour fournir la clé courante. Également, la nouvelle clé peut être certifiée dans un certificat signé en utilisant l'ancienne clé.

5.7 Récupération après sinistre ou compromission

Ce sous-composant décris les pré-requis liées à la notification et les procédures de récupérations dans le cas d'une compromission ou d'un sinistre. Chaque point suivant doit être adressé séparément

- L'identification ou la liste des incidents et compromissions applicable et les procédure de gestion et de reporting.
- Les procédures de récupération utilisée si les ressources informatiques, logiciels et/ou données sont corrompues ou suspectée comme tel. Ces procédures décrivent comment un environnement sécurisé est ré-établis, quels certificats sont révoqués, si la clé de l'entité est révoquée, comme la nouvelle clé publique est fournie aux utilisateurs, et comment les sujets sont re-certifiés.
- Les procédures de récupération utilisées si la clé de l'entité est compromise. Ces procédures décrivent comment un environnement est ré-établis, comme la nouvelle clé de l'entité publique est fournie aux utilisateurs, et comment les sujets sont re-certifiés.
- Les capacités de l'entité pour s'assurer de la continuité du business après un sinistre naturel ou autre. De telles capacités peuvent inclure la disponibilité d'un site distant sur lequel les opérations peuvent être récupérées. Il peut également inclure les procédures pour sécuriser ses facilités durant la période de temps suivant un désastre naturel ou autre et avant un rétablissement d'un environnement sécurisé, soit sur le site original, soit sur un site distant. Par exemple, les procédures pour protéger contre le vol de matériel sensible sur un site endommagé par un séisme.

5.8 Cessation de CA ou RA

Ce sous-composant décris les requis liées aux procédures pour la notification de cessation et la cessation d'une CA ou RA, incluant l'identité du gardien des documents d'archive de la CA ou RA.

6. Contrôles de sécurité technique

   Ce composant est utilisé pour définir les mesures techniques prises par la CA émettrice pour protéger ses clés cryptographique et données d'activation (par ex, PIN, mot de passe, ou clé partagées gérées manuellement). Ce composant peut également être utilisé pour imposer des contraintes sur les dépôts, sujets CA, souscripteur, et autres participants pour protéger leur clés privées, données d'activation pour leur clé privées, et paramètres de sécurité critique. La gestion de clé sécurisé est critique pour s'assurer que tous les secrets et clés privées et données d'activation sont protégées et utilisés seulement par le personnel autorisé.

   Ce composant décris également d'autres contrôles de sécurité technique utilisées par la CA émettrice pour effectuer les fonctions sécurisées de génération de clé, d'authentification de l'utilisateur, d'enregistrement de certificat, de révocation de certificat, d'audit, et d'archivage. Les contrôle techniques incluent les contrôle de sécurité du cycle de vie ( incluant la sécurité de l'environnement de développement logiciel, la méthodologie de développement logiciel) et les contrôles de sécurité opérationnel.

   Ce composant peut également être utilisé pour définir d'autres contrôles de sécurité technique sur les dépôts, sujets CA, RA, souscripteurs, et autres participants.

6.1 Génération et installation de paire de clé

La génération et l'installation de paire de clé doit être considéré pour la CA émettrice, les dépôts, sujets de CA, RA, et souscripteurs. Pour chacun de ces types d'entité, les questions suivantes peuvent potentiellement être répondues:

1. Qui génère l'entité publique, la paire de clé? Cela peut être le souscripteur, la RA, ou la CA. Également, comment est effectuée la génération de la clé? Est-ce que la génération de clé est faite par un hardware ou un software?
2. Comment est fournie la clé privée à l'entité de manière sécurisée? Par exemple, une situation où l'entité l'a généré et donc l'a déjà, qui manipule physiquement la clé privée, envoie un jeton contenant la clé privée de manière sécurisée ou en la délivrant dans une session SSL.
3. Comment la clé publique de l'entité est fournie de manière sécurisée à l'autorité de certification? Certaines possibilités sont dans une session SSL ou dans un message signé par la RA.
4. Dans le cas de la CA, comment la clé publique de la CA est fournie aux tiers de confiance de manière sécurisée.
5. Quels sont les tailles de clé?
6. Qui génère les paramètres de la clé publique, et est-ce que la qualité des paramètres sont vérifiés durant la génération?
7. Dans quel but la clé peut être utilisée, ou quel usage de clé est interdite? Pour les certificats X.509v3, ces but devraient être mappés dans les flags d'utilisation de clé.

6.2 Contrôles de Protection de clé privé et de module cryptographique

Les pré-requis pour la protection de la clé privée et des modules cryptographiques doivent être considérés pour la CA emettrice, les dépôts, les sujets de CA, RA, et souscripteurs. Pour chacun de ces types ou entités, les questions suivantes doivent être répondue:

1. Quels standards, s'il y en a, sont requis pour le module cryptographique utilisé pour générer les clé? Un module cryptographique peut être composé de hardware, software, firmware, ou une combinaison. Par exemple, est-ce que les clé certifiées par l'infrastructure doivent être générés en utilisant des modules conformes FIPS 140-1? Si c'est le cas, quel est le niveau FIPS 140-1 du module? Y'a t'il une autre ingénierie ou d'autres contrôles liés au module cryptographique, tel que l'identification des limites du module cryptographique, l'entrée/sortie, les rôles et services, l'état de la machine, la sécurité physique, la sécurité logiciel, la sécurité du système d'exploitation, la conformité des algorithmes, la compatibilité éléctro-magnétique, et les selfs tests.
2. Est-ce que la clé privée est sous contrôle de n de m personnes. Si c'est le cas, fournir n et m (2 contrôleurs est un cas spécial où n=m=2)
3. Est-ce que la clé privée est entiercée? si c'est le cas, qui est l'agent d'entièrcement, sous quelle forme est la clé entiercée (texte clair, chiffré, splitté), et quels sont les contrôles de sécurités dans le système d'entièrcement?
4. Est-ce que la clé privée est sauvegardée? Si c'est le cas, qui est l'agent de sauvegarde, sous quelle forme est la clé sauvegardée, et quels sont les contrôles de sécurité dans le système de sauvegarde?
5. Est-ce que la clé privée est archivée? Si c'est le cas, qui est l'agent d'archivage, sous quelle forme est archivée la clé, et quels sont les contrôles de sécurité dans le système d'archivage?
6. Sous quelles circonstances, s'il y en a, la clé privée peut être transférée dans ou depuis un module cryptographique? Qui est autorisé à effectuer une telle opération de transfert? Sous quelle forme est la clé privée durant le transfert?
7. Comment est stocké la clé privée dans le module?
8. Qui peut activer (utiliser) la clé privée? Quelles actions doivent être effectués pour activer la clé privée (ex: login, mise en route, fournir un PIN, insérer la clé/jeton, automatique, etc.)? Une fois la clé activée, est-ce que la clé est active pour une période indéfinie, active pour une seule fois, ou pour une période définie?
9. Qui peut désactiver la clé privée et comment? des exemples des méthodes de désactivation de clés privée incluent la déconnexion, suppression de la clé/jeton, désactivation automatique, et date d'expiration.
10. Qui peut détruire la clé privée et comment? Par exemple, la remise symbolique, la destruction symbolique, et écraser la clé.
11. Fournir les capacité du module cryptographique dans les zones suivantes: identification des limites du module cryptographique, entrée/sortie, rôles et services, état de la machine, sécurité physique, sécurité logiciel, sécurité du système d'exploitation, conformité des algorithmes, compatibilité éléctromagnétique, et selfs tests. Les capacités peuvent être exprimés via une référence de conformité avec un standard tel que FIPS 140-1 et le niveau associé.

6.3 Autres aspects de la gestion de paire de clés

D'autres aspects de gestion de clé doivent être considérés pour la CA émettrice, les dépôts, les sujets CA, RA, souscripteurs, et d'autres participants. Pour chacun de ces types d'entité, les questions suivante ont potentiellement besoins d'être répondues:

1. Est-ce que la clé publique est archivée? Si c'est le cas, qui est l'agent d'archivage et quels sont les contrôles de sécurité sur le système d'archivage? Également, quel logiciel et hardware doit être conservé comme partie de l'archive pour permettre d'utiliser la clé publique dans le temps? Note: ce sous-composant n'est pas limité aux requis aux pré-requis ou à la description de l'utilisation des signatures numériques avec les données d'archive, mais peut adresser les contrôles d'intégrité autre que les signatures numériques quand une archive nécessite une protection contre l'altération. Les signatures numériques ne fournissent pas de protection contre l'altération ou de protection de l'intégrité des données; Elles vérifient simplement l'intégrité des données. De plus, la période d'archivage peut être supérieur à une signature numérique appliquée à la donnée archivée.
2. Quel est la période opérationnelle des certificats émis au souscripteur. Quelles périodes d'utilisation, ou durée de vie, pour les paires de clé du souscripteur?

6.4 Données d'activation

Les données d'activation réfèrent aux valeurs de données autre que les clé privées qui sont nécessaire pour opérer les clés privées ou les modules cryptographique contenant les clés privées, tels qu'un PIN, passphrases, ou portions d'une clé privée utilisées dans un schéma de splitting de clé. La protection des données d'activation empêchent l'utilisation non autorisée de la clé privée, et les besoins potentiels à considérer pour la CA émettrice, les sujets CA, RA, et les souscripteurs. Une telle considération nécessite potentiellement d'adresser tout le cycle de vie des données d'activation depuis la génération jusqu'à l'archivage et la destruction. Pour chaque types d'entité (CA émettrice, sujets CA, RA, souscripteur, et autres participants), toutes les questions listées en 6.1 à 6.3 peuvent potentiellement être répondus en respect des données d'activation au lieu du respect des clés.

6.5 Contrôles de sécurité informatique

Ce sous-composant est utilisé pour décrire les contrôles de sécurité informatique tels que: l'utilisation de concept de base de calcul de confiance, le contrôle d'accès discrétionnaire, le contrôle d'accès obligatoire, la réutilisation d'object, l'audit, d'identification et l'authentification, les chemin de confiance, les tests de sécurité, et les tests de pénétration. L'assurance de produit peut également être adressé.

Un taux de sécurité informatique pour les systèmes informatiques peut être requis. Le taux peut être basé, par exemple, sur le Trusted System Evaluation Criteria (TCSEC), Canadian Trusted Products Evaluation Criteria, European Information Technology Security Evaluation Criteria (ITSEC), ou le Common Criteria for Information Technology Security Evaluation, ISO/IEC 15408:1999. Ce sous-composant peut également adresser les requis pour l'analyse de l'évaluation de produit, tests, profilage, certification de produit, et/ou accréditation de produit lié à l'activité entreprise.

6.6 Contrôles de sécurité du cycle de vie

   Ce sous-composant adresse les contrôles de développement système et les contrôles de gestion de la sécurité.

   Les contrôles de développement système incluent la sécurité de l'environnement de développement, la sécurité du personnel de développement, la sécurité de la gestion de configuration durant la maintenance produit, les pratique d'ingénierie logiciel, la méthodologie de développement logiciel, la modularité, couches, l'utilisation de concepts à sécurité intégrée et implémentation technique et sécurité des facilités de développement.

   Les contrôles de gestion de sécurité incluent l'exécution d'outils et de procédures pour s'assurer que les systèmes opérationnels et réseaux adhèrent à la sécurité configurée. Ces outils et procédures incluent la vérification de l'intégrité du logiciel de sécurité, firmware, et hardware pour s'assurer de leur opérations correct.

   Ce sous-composant peut également adresser le cycle de vie de la sécurité basé par exempel, sur Trusted Software Development Methodology (TSDM) niveau IV et V, independent life-cycle security controls audit, et Software Engineering Institute's Capability Maturity Model (SEI-CMM).

6.7 Contrôles de sécurité réseaux

Ce sous-composant adresse les contrôles liés à la sécurité des réseaux, incluant les firewalls.

6.8 Horodatage

Ce sous-composant adresse les requis ou pratiques liées à l'utilisation d'horodatage de diverses données. Il peut également discuter de si l'application de l'horodatage doit utiliser une source de temps fiable.

7. Profils de certificat et de CRL

Ce composant est utilisé pour spécifier le format de certificat et, si des CRL et/ou OCSP sont utilisés, le format de CRL et/ou OCSP. Cela inclus les informations dans les profils, versions, et extensions utilisées.

7.1 Profil de certificat

Ce sous-composant adresse les sujets suivant, potentiellement par référence à une définition de profil séparé, tel que celui définis dans la rfc 3280.

- Les versions supportées
- Les extensions de certificat utilisées et leur criticité
- Les identifiant d'objet d'algorithmes cryptographiques
- Les formes de nom utilisé pour la CA, RA, et les noms des souscripteurs
- Les contraintes de nom utilisés et les formes de nom utilisé dans les contraintes de nom
- Les OID de CP applicable
- L'utilisation de l'extension de contrainte de stratégie
- La syntaxe et sémantiques des qualifiants de stratégie
- Les sémantiques de traitement pour l'extension critique CP

7.2 Profile de CRL

Ce sous-composant adresse les sujets suivant, potentiellement par référence à une définition de profil séparé, tel que celui définis dans la rfc 3280.

- Les numéro de version supportés
- Les extensions d'entrée de CRL utilisées et leur criticité

7.3 Profile OCSP

Ce sous-composant adresse les sujets suivant, potentiellement par référence à une définition de profil séparé, tel que celui définis dans la rfc 2560.

- La version d'OCSP qui est utilisé comme base pour établir un système OCSP
- Les extensions OCSP utilisés et leur criticité

8 Audit et autres évaluations de conformité

Ce composant adresse les sujets suivants:

- La liste des sujets couverts par l'évaluation et/ou la méthodologie d'évaluation utilisée pour effectuer l'évaluation; par exemple WebTrust pour les CA et SAS 70.
- La fréquence de l'audit de conformité ou autres évaluations pour chaque entité qui doit être évalué conformément à une CP ou CPS, ou les circonstances qui vont déclencher une évaluation; par exemple un audit annuel, évaluation pré-opérationnelle comme condition d'autorisation pour une entité d'être opérationnelle, ou des investigations suivant une possible compromission de la sécurité.
- L'identité et/ou les qualifications du personnel effectuant l'audit ou autre évaluation.
- La relation entre l'évaluateur et l'entité qui est évaluée, incluant le degré d'indépendance de l'évaluateur.
- Les actions prises en résultat de déficience trouvé durant l'évaluation; par exemple, une suspension temporaire des opérations jusqu'à ce que la déficience soit corrigée, la révocation de certificats émis par l'entité évaluée, le changement de personnel, les investigations spéciales ou des évaluation de conformité plus fréquentes, et les demandes pour les dommages contre l'entité évaluée.
- Qui est habilité à voir les résultat d'une évaluation (ex, les entités évaluées, d'autres participant, tout le monde), qui leur fournis, et comment ils sont communiqués.

9 Autre questions juridiques et sur l'entreprise

   Ce sous-composant couvre les questions juridiques et liées à l'entreprise. Les sections 9.1 et 9.2 discutent des questions d'entreprise de redevances à percevoir pour divers services et les responsabilités financières des participants pour maintenir les ressources pour les opérations en cours et pour le payements des jugements ou règlement en réponse aux allégations formulées contre eux. Les sections restantes sont plus généralement concernés par les sujets légaux.

   À partir de la section 9.3, l'ordre des sujets est le même que l'ordre des sujets dans un agrément de licence logiciel ou autre agrément technologique. En conséquence, ce framework n'est pas seulement pour les CP et CPS, mais également associé aux agréments liés à la PKI, spécialement les agréments de souscripteur et de tiers de confiance. Cet ordre est prévu pour aider les avocats examinant les CP, CPS et autres documents qui adhèrent à ce cadre.

   En respect à de nombreux sous-composant légaux dans ce composant, une rédacteur de CP ou CPS peut choisir d'inclure dans le document les termes et conditions qui s'appliquent directement aux souscripteurs ou tiers de confiance. Par exemple, une CP ou CPS peut énoncer les limitations de responsabilité applicables aux souscripteurs et tiers de confiance. L'inclusion des termes et conditions est plus approprié dans les cas où la CP ou CPS est elle-même un contrat ou partie d'un contrat.

   Dans d'autres cas, cependant, la CP ou CPS n'est pas un contrat ou partie d'un contrat; à la place, elle est configurée pour que ses termes et conditions soient appliquées aux parties par des documents séparés, qui peuvent inclure des agréments associés, tels qu'un agrément de souscripteur ou tiers de confiance. Dans ce cas, un rédacteur de CP peut écrire une CP de façon à exiger que certaines conditions juridiques apparaissent (ou n'apparaissent pas) dans de tels agréments. Par exemple, une CP pour inclure un sous-composant statuant qu'un certain terme de limitation de responsabilité apparaisse dans les agréments de souscripteur et de tiers de confiance. Un autre exemple est une CP qui contient un sous-composant interdisant l'utilisation d'un agrément de souscripteur ou de tiers de confiance contenant une limitation de la responsabilité de la CA incompatible avec les disposition de la CP. Un rédacteur de CPS peut utiliser des sous-composants légaux pour divulguer que certains termes et conditions apparaissent dans des agréments de souscripteur, de tiers de confiance, ou d'autres, associé, utilisé par la CA. Une CPS peut expliquer, par exemple, que la CA écris qu'elle utilise un agrément de souscripteur ou de tiers de confiance associé qui applique une disposition particulière pour limiter la responsabilité.

9.1 Honoraires

Ce sous-composant contient les dispositions applicables liés aux frais des CA, dépôts, ou RA, tels que:

- frais d'émission ou de renouvellement de certificat
- frais d'accès au certificat
- frais d'accès aux informations de status ou de révocation
- frais pour d'autres services tels que ceux fournissant l'accès aux CP ou CPS
- Stratégies de remboursement

9.2 Responsabilité financière

Ce sous-composant contient les pré-requis ou les informations relatives aux ressources disponible aux CA, RA, et autres participants fournissant des services de certification pour supporter l'exécution de leurs responsabilité opérationnels, et pour rester solvable et payer les dommages dans le cas où ils sont tenus de payer un jugement ou un règlement dans le cadre d'une réclamation résultant de ces opérations. De telles dispositions incluent:

- Une déclaration que le participant maintient un certain montant de couverture d'assurance pour ses engagements envers les autres participants.
- Une déclaration que le participant a accès à d'autres ressources pour supporter les opérations et payer les dommages pour la responsabilité potentielle, qui peut être formulée en termes d'un niveau minimum d'actifs nécessaires pour opérer et couvrir les imprévus qui pourraient survenir au sein d'une PKI, par exemple, les actifs sur le bilan d'une organisation, un cautionnement, une lettre de crédit, et un droit en vertu d'un accord pour une indemnité sous certaines circonstances.
- Une déclaration qu'un participant a un programme qui offre une assurance de première partie ou la protection de garantie à d'autres participants dans le cadre de leur utilisation de la PKI.

9.3 Confidentialité des informations de l'entreprise

Ce sous-composant contient les dispositions liées au traitement des information confidentielles de l'entreprise que les participants peuvent communiquer aux autres, tels que les business plan, informations de vente, secrets bancaires, et autres informations reçues d'un tiers de confiance sous un agrément de non-divulgation. spécifiquement, ce sous-composant adresse:

- Le périmètre de ce qui est considéré comme information confidentielle.
- Les types d'informations qui sont considérés hors périmètre des informations confidentielles
- Les responsabilités des participants qui reçoivent des informations confidentielles pour éviter une compromission, et éviter des les utiliser ou les divulguer à des tiers.

9.4 Confidentialité des renseignements personnels

Ce sous-composant est lié à la protection que les participants, particulièrement les CA, RA, et dépôts, peut nécessiter pour permettre d'identifier les informations privées personnelles des candidats de certificat, souscripteurs, et autres participants. Spécifiquement, ce sous-composant adresse les éléments suivant:

- La désignation et divulgation du plan de protection des renseignements personnels applicables qui s'appliquent aux activités des participants, si requis par la stratégie ou la loi applicable.
- Les informations qui sont considérés ou non privée dans la PKI
- Toute responsabilité des participants qui reçoivent des informations privée pour les sécuriser, et éviter leur utilisation ou divulgation à des tiers.
- Tout prérequis pour avis, ou le consentement des individus concernant l'utilisation ou la divulgation d'informations privées.
- Toutes circonstances sous lesquelles un participants a droit ou est tenus de divulguer des informations privées en vertu judiciaire, traitement administratif dans un processus privée ou gouvernemental, ou tout traitement légal.

9.5 Droits de propriété intellectuelle

Ce sou-composant adresse les droits de propriété intellectuelle, tels que les droits d'auteur, brevets, marques, ou secrets commerciaux, que certains participants peuvent avoir ou réclamer dans une CP, CPS, certificats, noms, et clés, ou font l'objet d'une licence ou de participant.

9.6 Représentations et garanties

Ce sous-composant peut inclure des représentations et garanties de divers entités qui sont faites en vertu de la CP ou CPS. Par exemple, une CPS qui sert de contrat peut contenir une garantie de la CA que les informations contenus dans le certificat sont précis. Alternativement, une CPS peut contenir une garantie moins étendue où les informations dans le certificat sont vrai au mieux de la connaissance de la CA après avoir effectué certaines procédures d'authentification de l'identité. Ce sous-composant peut également inclure des prérequis que les représentations et garanties apparaissent dans certains agréments. Par exemple, une CP peut contenir un prérequis qui toutes les CA utilisent un agrément de souscripteur, et qu'un agrément de souscripteur doit contenir une garantie par la CA que les informations dans le certificat est précis. Les participants qui peuvent faire les représentation et garanties incluent les CA, RA, souscripteurs, tiers de confiance, et autres participants.

9.7 exclusions de garanties

Ce sous-composant peut inclure des exclusions de garanties expresses qui pourraient être réputé exister dans un accord, et les exclusions de garanties implicites qui pourraient être imposées par la loi applicable, tels que les garanties de qualité marchande ou d'adéquation pour un but particulier. La CP ou CPS peut directement imposer de tels exclusions, ou la CP ou CPS peut maintenir une obligation que les exclusions apparaissent dans les agrément associés.

9.8 Limitations de responsabilité

Ce sous-composant peut inclure des limitations de responsabilité dans une CP ou CPS ou des limitations qui apparaissent ou doivent apparaître dans un agrément associés avec la CP ou CPS. Ces limitations peuvent rentrer dans un des deux catégories: les limitations sur les éléments de dommages récupérables et les limitations sur la quantité de dommage récupérable, également connus sous le terme plafonnement de responsabilité. Souvent, les contrats contiennent des clauses empêchant la récupération d'éléments de dommage tels qu'un dommage accessoire et indirect, et les dommage punitifs. Fréquemment, les contrats contiennent des clauses qui limitent la possible récupération d'une partie ou l'autre à un certain montant ou à un montant correspondant à un indice de référence, tels que le montant qu'un vendeur a été payé en vertu du contrat.

9.9 Indémité

Ce sous-composant inclus les dispositions par lesquelles un partie utilise envers un second partie pour les pertes ou dommages encourus par le second partie, résultant généralement de la conduite de la première partie. Ils peuvent apparaîtrent dans une CP, CPS, ou agrément. Par exemple, une CP peut nécessiter que les agréments de souscripteur contiennent un terme sous lequel un souscripteur est responsable de l'indemnisation de la CA pour les pertes que la CA soutient découlant de fausses déclarations d'un souscripteur dans la demande de certificat en vertu de laquelle la CA a émis au souscripteur un certificat inexact. Similairement, une CPS peut dire qu'une CA utilise un agrément de tiers de confiance, sous lequel les tiers de confiance sont responsable de l'indemnisation d'une CA en cas de perte que la CA soutient à cause de l'utilisation d'un certificat sans vérifier les informations de révocation de statut ou l'utilisation d'un certificat dans un but que la CA n'a pas permis.

9.10 Durée et résiliation

Ce sous-composant peut inclure la durée dans laquelle une CP ou CPS demeure en vigueur et les circonstances sous lesquelles le document, portions du document, ou son applicabilité à un participant particulier peut être terminé. En plus ou alternativement, la CP ou CPS peut inclure les exigences que certaines clause de durée et de résiliation apparaissent dans un agrément. En particulier, de tels termes incluent:

- La durée d'un document ou agrément, c'est à dire, quand le document devient effectif et quand il expire s'il n'est pas résilié plus tôt
- Les dispositions de résiliation statuant sur les circonstances sous lesquelles le document, certaines portions, ou son application à un participant particulier cesse d'être en effet.
- Les conséquences de résiliation du document. Par exemple, certaines dispositions d'un agrément peuvent survivre à la résiliation et rester en vigueur. Des exemples incluent la connaissance des droits de propriété intellectuelle et les dispositions de confidentialité. Également, la résiliation peut impliquer une responsabilité des parties de retourner les informations confidentielles au partie qui l'a divulgué.

9.11 Remarques individuels et communications avec les participants

Ce sous-composant discute de la manière par laquelle un participant peut ou doit communiquer avec un autre participant sur une base 1 à 1 pour qu'une telle communication soit légalement effective. Par exemple, une RA peut souhaiter informer la CA qu'elle souhaite terminer sont agrément avec la CA. Ce sous-composant est différent des fonctions de publication et de dépôt, parce contrairement aux communications individuelles décrites dans ce sous-composant, la publication et l'envoi dans un dépôt servent à communiquer à une large audience. Ce sous-composant peut établir des mécanismes pour communiquer et indiquer les informations de contact à utiliser pour router de telles communications, tel que les email signés numériquement à une adresse spécifique, suivie par un email signé d'accusé de réception.

9.12 Modifications

Si sera occasionnellement nécessaire d'amender une CP ou CPS. Certains de ces changements ne vont pas réduire matériellement l'assurance qu'une CP ou son implémentation fournis, et sera jugé par l'administrateur de stratégie sur l'effet insignifiant de l'acceptabilité des certificats. De tels changement dans une CP ou CPS ne nécessitent pas de changement dans l'OID de CP ou le pointeur CPS. D'une autre manière, certains changements dans une spécification va changer matériellement l'acceptabilité des certificats pour des buts spécifiques, et ces changement peuvent nécessiter des changements correspondant à l'OID de la CP ou le pointeur CPS. Ce sous-composant peut également contenir les informations suivantes:

- Les procédures par lesquelles la CP ou CPS et/ou les autres documents doivent, peuvent être, ou sont amendés. Dans le cas des amendements de CP ou CPS, les procédures de changement peuvent inclure un mécanisme de notification pour fournir des avis de modifications proposées aux parties concernées, tels que les souscripteurs ou tiers de confiance, une période de commentaire, un mécanisme par lequel les commentaires sont reçus, revus, et incorporés dans le document, et un mécanisme par lequel les amendements deviennent effectifs.
- Les circonstances sous lesquelles les amendements de CP ou CPS nécessitent un changement d'OID ou pointeur de CPS.

9.13 Procédures de règlement de différends

Ce sous-composant discute des procédures utilisée pour résoudre les différents découlant des CP, CPS et/ou agréments. Des exemples de telles procédures incluent l'exigence qu'un différent soit résolu dans un certain forum ou par des mécanismes de résolutions de différents alternatifs.

9.14 Lois gouvernementales

Ce sous-composant énonce une déclaration que la loi d'une certaine juridiction régit l'interprétation et l'application de la CP ou CPS ou agréments.

9.15 Conformité avec les lois applicables

Ce composant a trait aux conditions énoncées que les participants se conforment avec les lois applicables, par exemple, les lois liées au hardware et software cryptographique que peuvent être sujet aux lois de contrôle d'export d'une juridiction donnée. La CP ou CPS pourrait prétendre imposer de telles exigences ou peuvent exiger que ces dispositions figurent dans d'autres agréments.

9.16 Dispositions diverses

Ce sous-composnat contient diverses dispositions, parfois appelé "dispositions passe-partout" dans les contrats. Les clauses couvertes dans ce sous-composant peuvent apparaître dans une CP, CPS, ou agréments et inclus:

- Une clause d'agrément entière, qui identifie typiquement le document ou les documents comprenant l'intégralité de l'agrément entrée les parties et status que ces agrément remplacent tous les accords antérieurs et actuels écris ou compris oralement relatifs à la même question.
- Une clause de cession, qui peut agir pour limiter la capacité d'un partie dans un agrément, l'attribution de ses droits en vertu de l'accord à un autre partie (comme le droit de recevoir un flux de paiement dans le future) ou de limiter la capacité d'un partie à déléguer ses obligations en vertu de l'accord.
- Une clause de divisibilité, qui énonce les intentions des parties dans le cas où une cour ou un autre tribunal détermine qu'une clause dans un agrément est, pour certaines raisons, invalides ou non-applicables, et dont le but est fréquemment d'empêcher l'inapplicabilité d'une clause causant l'ensemble de l'agrément inapplicable.
- Une clause d'application, qui peut indiquer qu'un partie gagnant dans un litige découlant d'un accord a droit à des honoraires d'avocats dans le cadre de sa récupération, ou peut statuer que le renoncement d'un partie d'une rupture de contrat d'un partie ne constitue par un renoncement permanent, ou un renoncement future ou autres violation de contrat.
- Un clause de force majeur, communément utilisée pour excuser la performance d'un ou plusieurs partie à un accord en raison d'un événement hors du contrôle raisonnable de ou des parties affectées. En règle générale, la durée de l'exécution dispensée est proportionnelle à la durée du retard causé par l'événement. La clause peut également prévoir la résiliation de l'accord dans les circonstances et conditions spécifiées. Les événements considérés pour constituer une force majeur peut inclure ce que l'on appelle les "actes de dieu", les guerres, terrorisme, grèves, catastrophes naturelles, défaillances de fournisseurs ou vendeurs, ou défaillances de l'internet ou autre infrastructure. Les clauses de force majeur doivent être rédigées de manière à être compatibles avec d'autres parties du framework et des agrément de niveau de service applicable. Par exemple, les responsabilités et les capacités de continuation d'activité et de reprise sur incident peut placer des événements sous le contrôle raisonnable des parties, telles qu'une obligation de maintenir une alimentation électrique de secours.

9.17 Autres Dispositions

Ce sous-composant est "fourre-tout" où des responsabilités additionnelles et termes peuvent être imposés aux participants de la PKI qui ne rentre par nécessairement dans une autre catégorie de ce framework. Les rédacteurs de CP et CPS peut placer toute disposition dans ce sous-composant qui n'est pas couvert par un autre sous-composant.

Considérations de sécurité

   En accord avec X.509, une stratégie de certificat est un jeu nommé de règles qui indiquent l'applicabilité d'un certificat à une communauté particulière et/ou classe d'applications avec des exigences de sécurité particulières. Une CP peut être utilisée par un tiers de confiance pour aider à décider si un certificat, et sa liaison, sont suffisamment dignes de confiance et appropriés à une application particulière.

   Le dégré auquel un tier de confiance peut avoir confiance à la liaison embarquée dans un certificat dépend de nombreux facteurs. Ces facteurs peuvent inclure les pratiques suivies par l'autorité de certification en authentifiant le sujet; la stratégie d'opération de la CA, les procédures, et les contrôles de sécurité techniques, incluant de scope des responsabilités des souscripteurs (par exemple, en protégeant la clé privée), et les responsabilités statué et les termes de responsabilités de la CA (par exemple, les garanties, déclarations de garanties, et les limitations de responsabilité).

   Ce document fournis un framework pour adresser les aspects techniques, procédurales, personnelles, et physiques des autorités de certification, d'enregistrement, les dépôts, souscripteurs, et modules cryptographiques de confiance, pour s'assurer que la génération de certificats, la publication, le renouvellement, changement de clé, utilisation, et révocation est faite de manière sécurisée.

Plan d'un jeu de dispositions

Cette section contient un plan recommandé pour un jeu de dispositions prévues pour servir de checklist ou de template standard à utiliser par les rédacteurs de CP ou CPS. Un tel plan facilite:

- La comparaison entre 2 stratégies de certificats durant la cross-certification ou d'autres formes d'interopérations.
- La comparaison d'une CPS avec une CP pour s'assurer que la CPS implémente fidèlement la stratégie
- La comparaison entrée 2 CPS.

Afin de se conformer à cette rfc, les rédacteurs d'une CP ou CPS conformes sont fortement encouragés à adhérer à ce plan. Bien que l'utilisation d'un plan alternatif est découragé, il peut être accepté si une justification est fournie pour la déviation et une table de mappage est fournie pour discerner clairement où chaque éléments décris dans ce plan est fournis.

1. INTRODUCTION
1.1 Overview
1.2 Document name and identification
1.3 PKI participants
1.3.1 Certification authorities
1.3.2 Registration authorities
1.3.3 Subscribers
1.3.4 Relying parties
1.3.5 Other participants
1.4 Certificate usage
1.4.1. Appropriate certificate uses
1.4.2 Prohibited certificate uses
1.5 Policy administration
1.5.1 Organization administering the document
1.5.2 Contact person
1.5.3 Person determining CPS suitability for the policy
1.5.4 CPS approval procedures
1.6 Definitions and acronyms
2. PUBLICATION AND REPOSITORY RESPONSIBILITIES
2.1 Repositories
2.2 Publication of certification information
2.3 Time or frequency of publication
2.4 Access controls on repositories
3. IDENTIFICATION AND AUTHENTICATION (11)
3.1 Naming
3.1.1 Types of names
3.1.2 Need for names to be meaningful
3.1.3 Anonymity or pseudonymity of subscribers
3.1.4 Rules for interpreting various name forms
3.1.5 Uniqueness of names
3.1.6 Recognition, authentication, and role of trademarks
3.2 Initial identity validation
3.2.1 Method to prove possession of private key
3.2.2 Authentication of organization identity
3.2.3 Authentication of individual identity
3.2.4 Non-verified subscriber information
3.2.5 Validation of authority
3.2.6 Criteria for interoperation
3.3 Identification and authentication for re-key requests
3.3.1 Identification and authentication for routine re-key
3.3.2 Identification and authentication for re-key after revocation
3.4 Identification and authentication for revocation request
4. CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS (11)
4.1 Certificate Application
4.1.1 Who can submit a certificate application
4.1.2 Enrollment process and responsibilities
4.2 Certificate application processing
4.2.1 Performing identification and authentication functions
4.2.2 Approval or rejection of certificate applications
4.2.3 Time to process certificate applications
4.3 Certificate issuance
4.3.1 CA actions during certificate issuance
4.3.2 Notification to subscriber by the CA of issuance of certificate
4.4 Certificate acceptance
4.4.1 Conduct constituting certificate acceptance
4.4.2 Publication of the certificate by the CA
4.4.3 Notification of certificate issuance by the CA to other entities
4.5 Key pair and certificate usage
4.5.1 Subscriber private key and certificate usage
4.5.2 Relying party public key and certificate usage
4.6 Certificate renewal
4.6.1 Circumstance for certificate renewal
4.6.2 Who may request renewal
4.6.3 Processing certificate renewal requests
4.6.4 Notification of new certificate issuance to subscriber
4.6.5 Conduct constituting acceptance of a renewal certificate
4.6.6 Publication of the renewal certificate by the CA
4.6.7 Notification of certificate issuance by the CA to other entities
4.7 Certificate re-key
4.7.1 Circumstance for certificate re-key
4.7.2 Who may request certification of a new public key
4.7.3 Processing certificate re-keying requests
4.7.4 Notification of new certificate issuance to subscriber
4.7.5 Conduct constituting acceptance of a re-keyed certificate
4.7.6 Publication of the re-keyed certificate by the CA
4.7.7 Notification of certificate issuance by the CA to other entities
4.8 Certificate modification
4.8.1 Circumstance for certificate modification
4.8.2 Who may request certificate modification
4.8.3 Processing certificate modification requests
4.8.4 Notification of new certificate issuance to subscriber
4.8.5 Conduct constituting acceptance of modified certificate
4.8.6 Publication of the modified certificate by the CA
4.8.7 Notification of certificate issuance by the CA to other entities
4.9 Certificate revocation and suspension
4.9.1 Circumstances for revocation
4.9.2 Who can request revocation
4.9.3 Procedure for revocation request
4.9.4 Revocation request grace period
4.9.5 Time within which CA must process the revocation request
4.9.6 Revocation checking requirement for relying parties
4.9.7 CRL issuance frequency (if applicable)
4.9.8 Maximum latency for CRLs (if applicable)
4.9.9 On-line revocation/status checking availability
4.9.10 On-line revocation checking requirements
4.9.11 Other forms of revocation advertisements available
4.9.12 Special requirements re key compromise
4.9.13 Circumstances for suspension
4.9.14 Who can request suspension
4.9.15 Procedure for suspension request
4.9.16 Limits on suspension period
4.10 Certificate status services
4.10.1 Operational characteristics
4.10.2 Service availability
4.10.3 Optional features
4.11 End of subscription
4.12 Key escrow and recovery
4.12.1 Key escrow and recovery policy and practices
4.12.2 Session key encapsulation and recovery policy and practices
5. FACILITY, MANAGEMENT, AND OPERATIONAL CONTROLS (11)
5.1 Physical controls
5.1.1 Site location and construction
5.1.2 Physical access
5.1.3 Power and air conditioning
5.1.4 Water exposures
5.1.5 Fire prevention and protection
5.1.6 Media storage
5.1.7 Waste disposal
5.1.8 Off-site backup
5.2 Procedural controls
5.2.1 Trusted roles
5.2.2 Number of persons required per task
5.2.3 Identification and authentication for each role
5.2.4 Roles requiring separation of duties
5.3 Personnel controls
5.3.1 Qualifications, experience, and clearance requirements
5.3.2 Background check procedures
5.3.3 Training requirements
5.3.4 Retraining frequency and requirements
5.3.5 Job rotation frequency and sequence
5.3.6 Sanctions for unauthorized actions
5.3.7 Independent contractor requirements
5.3.8 Documentation supplied to personnel
5.4 Audit logging procedures
5.4.1 Types of events recorded
5.4.2 Frequency of processing log
5.4.3 Retention period for audit log
5.4.4 Protection of audit log
5.4.5 Audit log backup procedures
5.4.6 Audit collection system (internal vs. external)
5.4.7 Notification to event-causing subject
5.4.8 Vulnerability assessments
5.5 Records archival
5.5.1 Types of records archived
5.5.2 Retention period for archive
5.5.3 Protection of archive
5.5.4 Archive backup procedures
5.5.5 Requirements for time-stamping of records
5.5.6 Archive collection system (internal or external)
5.5.7 Procedures to obtain and verify archive information
5.6 Key changeover
5.7 Compromise and disaster recovery
5.7.1 Incident and compromise handling procedures
5.7.2 Computing resources, software, and/or data are corrupted
5.7.3 Entity private key compromise procedures
5.7.4 Business continuity capabilities after a disaster
5.8 CA or RA termination
6. TECHNICAL SECURITY CONTROLS (11)
6.1 Key pair generation and installation
6.1.1 Key pair generation
6.1.2 Private key delivery to subscriber
6.1.3 Public key delivery to certificate issuer
6.1.4 CA public key delivery to relying parties
6.1.5 Key sizes
6.1.6 Public key parameters generation and quality checking
6.1.7 Key usage purposes (as per X.509 v3 key usage field)
6.2 Private Key Protection and Cryptographic Module Engineering Controls
6.2.1 Cryptographic module standards and controls
6.2.2 Private key (n out of m) multi-person control
6.2.3 Private key escrow
6.2.4 Private key backup
6.2.5 Private key archival
6.2.6 Private key transfer into or from a cryptographic module
6.2.7 Private key storage on cryptographic module
6.2.8 Method of activating private key
6.2.9 Method of deactivating private key
6.2.10 Method of destroying private key
6.2.11 Cryptographic Module Rating
6.3 Other aspects of key pair management
6.3.1 Public key archival
6.3.2 Certificate operational periods and key pair usage periods
6.4 Activation data
6.4.1 Activation data generation and installation
6.4.2 Activation data protection
6.4.3 Other aspects of activation data
6.5 Computer security controls
6.5.1 Specific computer security technical requirements
6.5.2 Computer security rating
6.6 Life cycle technical controls
6.6.1 System development controls
6.6.2 Security management controls
6.6.3 Life cycle security controls
6.7 Network security controls
6.8 Time-stamping
7. CERTIFICATE, CRL, AND OCSP PROFILES
7.1 Certificate profile
7.1.1 Version number(s)
7.1.2 Certificate extensions
7.1.3 Algorithm object identifiers
7.1.4 Name forms
7.1.5 Name constraints
7.1.6 Certificate policy object identifier
7.1.7 Usage of Policy Constraints extension
7.1.8 Policy qualifiers syntax and semantics
7.1.9 Processing semantics for the critical Certificate Policies extension
7.2 CRL profile
7.2.1 Version number(s)
7.2.2 CRL and CRL entry extensions
7.3 OCSP profile
7.3.1 Version number(s)
7.3.2 OCSP extensions
8. COMPLIANCE AUDIT AND OTHER ASSESSMENTS
8.1 Frequency or circumstances of assessment
8.2 Identity/qualifications of assessor
8.3 Assessor's relationship to assessed entity
8.4 Topics covered by assessment
8.5 Actions taken as a result of deficiency
8.6 Communication of results
9. OTHER BUSINESS AND LEGAL MATTERS
9.1 Fees
9.1.1 Certificate issuance or renewal fees
9.1.2 Certificate access fees
9.1.3 Revocation or status information access fees
9.1.4 Fees for other services
9.1.5 Refund policy
9.2 Financial responsibility
9.2.1 Insurance coverage
9.2.2 Other assets
9.2.3 Insurance or warranty coverage for end-entities
9.3 Confidentiality of business information
9.3.1 Scope of confidential information
9.3.2 Information not within the scope of confidential information
9.3.3 Responsibility to protect confidential information
9.4 Privacy of personal information
9.4.1 Privacy plan
9.4.2 Information treated as private
9.4.3 Information not deemed private
9.4.4 Responsibility to protect private information
9.4.5 Notice and consent to use private information
9.4.6 Disclosure pursuant to judicial or administrative process
9.4.7 Other information disclosure circumstances
9.5 Intellectual property rights
9.6 Representations and warranties
9.6.1 CA representations and warranties
9.6.2 RA representations and warranties
9.6.3 Subscriber representations and warranties
9.6.4 Relying party representations and warranties
9.6.5 Representations and warranties of other participants
9.7 Disclaimers of warranties
9.8 Limitations of liability
9.9 Indemnities
9.10 Term and termination
9.10.1 Term
9.10.2 Termination
9.10.3 Effect of termination and survival
9.11 Individual notices and communications with participants
9.12 Amendments
9.12.1 Procedure for amendment
9.12.2 Notification mechanism and period
9.12.3 Circumstances under which OID must be changed
9.13 Dispute resolution provisions
9.14 Governing law
9.15 Compliance with applicable law
9.16 Miscellaneous provisions
9.16.1 Entire agreement
9.16.2 Assignment
9.16.3 Severability
9.16.4 Enforcement (attorneys' fees and waiver of rights)
9.16.5 Force Majeure
9.17 Other provisions

28 juillet 2015

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.

21 juin 2016

rfc4033

Introduction à la sécurité DNS et aux pré-requis

Les DNS Security Extensions (DNSSEC) sont une collection de nouveaux enregistrements et modifications de protocole qui ajoutent un authentification de l'origine des données et l'intégrité des données à DNS.

Définition des termes DNSSEC important

Authentication Chain Une séquence alternée de RRsets de clé publique DNS (DNSKEY) et de RRset de Delegation Signer (DS) forment une chaîne de donnée signée, et chaque lien dans la chaîne étant garant de la suivante. Un RR DNSKEY est utilisé pour vérifier la signature couvrant un RR DS et permet au RR DS d'être authentifié. Le RR DS contient un hash d'un autre RR DNSKEY et ce nouveau RR DNSKEY en retour authentifie un autre RRset DNSKEY et , en retour, certains RR DNSKEY dans ce jeu peuvent être utilisés pour authentifiier un autre RR DS, et ainsi de suite jusqu'à ce que la fin de la chaîne se termine avec un RR DNSKEY dont la clé privée correspondante signe la donnée DNS souhaitée. Par exemple, le RRset DNSKEY root peut être utilisé pour authentifier le RRset DS pour "example.". Le RRset DS "example." contient un hash qui matche une DNSKEY "example.", et la clé privée correspondante à ce DNSKEY signe le RRset DNSKEY "example." Les RRset DNSKEY signe les données enregistré tel que "www.example." et les RR DS pour les délégation comme "subzone.example."
Authentication key Une clé publique qu'un résolveur a vérifié et peut ainsi l'utiliser pour authentifier les données. Un résolveur peut obtenir les clés d'authentification de 3 manières. D'abord, le résolveur est généralement configuré pour connaître au moins une clé publique; cette donnée configurée est généralement soit la clé publique elle-même ou un hash de la clé publique tel que trouvé dans le RR DS. Ensuite, le résolveur peut utiliser une clé publique authentifiée pour vérifier un RR DS et le RR DNSKEY pour lequel le RR DS réfère. Enfin, le résolveur peut être capable de déterminer qu'une nouvelle clé publique a été signée par la clé privée correspondante à une autre clé publique que le résolveur a vérifié. Noter que le résolveur doit toujours être guidé par la stratégie locale quand il décide d'authentifier une nouvelle clé publique même si la stratégie locale est simplement pour authentifier une nouvelle clé publique pour laquelle le résolveur est capable de vérifier la signature.
Authoritative RRset Dans le contexte d'une zone particulière, un RRset est authoritatif si et seulement si le nom propriétaire du RRset est dans le sous-jeu de l'espace de nom qui est au niveau ou sous le zone apex et au niveau ou sous la séparation de la zone de ses enfant, s'il y en a. Tous les RRsets dans la zone apex sont authoritatifs, excepté pour certains RRsets à ce nom de domaine qui, si présent, appartient au parent de cette zone. Ces RRset peuvent inclure un RRset DS, le RRset NSEC référençant ce RRset DS (le NSEC parental), et les RR RRSIG associés avec ces RRset, tous étant authoritatif dans la zone parente. Similairement, si cette zone contient des points de délégation, seul le RRset NSEC parent, les RRsets DS, et tou RR RRSIG associés avec ces RRsets sont autoritatifs pour cette zone
Delegation Point Terme utilisé pour décrire le nom côté parent d'une coupure de zone. C'est à dire, le point de délégation pour "foo.example" serait le nœud foo.example dans la zone "example" (opposé à l'apex de zone de la zone foo.example").
Island of Security Termet utilisé pour décrire une zone signée et déléguée qui n'a pas de chaîne d'authentification de son parent déléguant. C'est à dire qu'il n'y a pas de RR DS contenant un hash d'un RR DNSKEY pour l'île dans la zone du parent déléguant. Une île de sécurité est désservie par des serveurs de nom sécurisés et peut fournir des chaînes d'authentification à toute zone enfant déléguée. Les réponses d'une île de sécurité ou ses descendants peut seulement être authentifié si ses clés d'authentification peuvent être authentifiés par un moyen de confiance en dehors du protocole DNS
Key Signing Key Une clé d'authentification qui correspond à une clé privée utilisée pour signer une ou plusieurs autres clé d'authentification pour une zone donnée. Typiquement, la clé privée correspondant à une KSK va signer une clé de signature de zone, qui en retour a une clé privée correspondante qui va signer les données de la zone. La stratégie locale peut nécessiter que la clé de signature de zone soit changée fréquemment, alors que la KSK peut avoir une période de validité plus longue pour fournir un point d'entrée sécurisé plus stable dans la zone. Désigner une clé d'authentification comme KSK est purement un problème opérationnel: La validation DNSSEC ne distingue pas les KSK et les autres clé d'authentification DNSSEC, et il est possible d'utiliser une seul clé pour signer les clé et signer la zone.
Non-Validation Security-Aware Stub Resolver Un résolveur sécurisé qui valide un ou plusieurs serveurs de noms récursifs sécurisés pour effectuer plus de tâches discutés dans ce document. En particulier, un tel résolveur est une entité qui envoie des requêtes DNS, reçois les réponses DNS, et est capable d'établir un canal sécurisé approprié vers un serveur récursif sécurisé qui fournir ces services à la demande.
Non-Validating Sub Resolver Un terme plus simple pour Non-Validation Security-Aware Stub Resolver
Security-Aware Name Server Une entité agissant dans le rôle d'un serveur de noms qui comprend les extensions de sécurité DNS définis dans ce document. En particulier, un serveur de nom sécurisé est une entité qui reçois des requêtes DNS, envoie des réponses DNS, supporte l'extension EDNS0 et le bit D0, et supporte les types RR et bits d'en-tête de messages définis dans ce document.
Security-Aware Recursive Name Server Une entité qui agit comme serveur de nom sécurisé et résolveur sécurisé.
Security-Aware Resolver Une entité agissant dans le rôle d'un résolveur qui comprend les extensions de sécurité DNS pour fournir des services additionnels. Ces résolveurs peuvent être soit validateurs soit non-validateurs, dépendant si le résolveur vérifie les signatures DNSSEC par lui-même ou fait confiance à un serveur de nom sécurisé pour le faire.
Security-Oblivious ‹anything} tout ce qui n'est pas sécurisé
Signed Zone Une zone dont les RRset sont signés et qui contiennent des enregistrements DNSKEY, RRSIG, NSEC et optionnellement DS
Trust Anchor Un RR DNSKEY configuré ou un hash RR DS d'un RR DNSKEY. Un résolveur sécurisé validant utilise cette clé publique ou le hash comme point de départ pour construire la chaîne d'authentification d'une réponse DNS. En général, un résolveur validateur obtient les valeurs initiales de ses ancres de confiance via un moyen sécurisé en dehors du protocole DNS. La présence d'une ancre de confiance implique également que le résolveur s'attende à ce que la zone vers laquelle l'ancre de confiance soit signée.
Unsigned Zone Une zone qui n'est pas signée
Validating Security-Aware Stub Resolver Un résolveur sécurisé qui envoie des requêtes en mode récursif mais qui valide la signature par lui-même au lieu de simplement faire confiance à un serveur de nom sécurisé.
Validating Stub Resolver Un terme plus simple pour Validating Security-Aware Stub Resolver
Zone Apex Terme utilisé pour décrire le nom d'une coupure de zone côté client
Zone Signing Key Une clé d'authentification qui correspond à une clé privée utilisée pour signer une zone. Typiquement, une ZSK fait partie du même RRset DNSKEY que la KSK dont la clé privée correspondante signe ce RRset DNSKEY, mais la ZSK est utilisée dans un but différent et peut être différente de la KSK en autre, sur sa durée de vie.

Services fournis par la sécurité DNS

Les extensions de sécurité DNS fournissent l'authentification de l'origine des données et l'intégrité des données, incluant les mécanismes pour authentifier le refus de l'existance de données DNS.

Ces mécanismes nécessitent de changer le protocole DNS. DNSSEC ajoute 4 nouveaux types d'enregistement de ressource: Resource Record Signature (RRSIG), DNS Publik Key (DNSKEY), Delegation Signer (DS), et Next Secure (NSEC). Il ajoute également 2 nouveaux bits d'en-tête: Checking Disables (CD) et Authenticated Data (AD). Pour supporter des tailles de messages DNS plus grands, DNSSEC exige le support EDNS0. Finallement, DNSSEC nécessite le support pour le bit d'en-tête DNSSEC OK (DO) pour qu'un résolveur sécurisé puissent indiquer dans ses requêtes qu'il souhaite reçevoir les RR DNSSEC dans les réponses.

Authentification de l'origine des données et intégrité des données

   DNSSEC fournis l'authentification en associant des signature numérique générées cryptographiquement avec les RRset DNS. Ces signatures numérique sont stockées dans un nouvel enregistrement de ressource, l'enregistrement RRSIG. Généralement, il y a une seule clé privée qui signe les données d'une zone, mais plusieurs clés sont possibles. Par exemple, il peut y avoire des clés pour chaque algorithme de signature. Si un résolveur sécurisé apprend un clé publique de zone, il peut authentifier les données signées de cette zone. Un concept DNSSEC important est que la clé qui signe les données d'une zone est associée avec la zone elle-même et pas avec les serveurs de nom ayant autorité sur la zone. (Les clé publique pour les mécanismes d'authentification de transaction DNS peuvent également apparaître dans les zone, mais DNSSEC lui-même est concerné par la sécurité des données DNS, par la sécurité des canaux de transaction DNS. Les clés associées avec la sécurité des transaction peuvent être stockés dans des types RR différents)

   Un résolveur sécurisé peut apprendre une clé publique d'une zone soit en ayant une ancre de confiance configuré dans le résolveur ou par résolution normale DNS, auquel cas les clé publiques sont stockées dans un nouveau type d'enregistrement de ressource, le RR DNSKEY. Noter que les clés privées utilisée pour signer les donées de la zone doivent être conservé de manière sécurisés et devraient être stockés hors-line. Pour découvrir un clé publique de manière sûre via la résolution DNS, la clé cible elle-même doit être signée par une clé d'authentification configurée ou une autre clé qui a été authentifiée précédemment. Les résolveurs sécurisés authentifient les information de zone en formant une chaîne d'auhentification depuis une nouvelle clé publique apprise vers une clé publique authentifiée connue, qui en retour a été soit configurée dans le résolveur ou doit avoir été apprise et vérifiée précédemment. Donc, le résolveur doit être configuré avec au moins un trust anchor.

   Si l'ancre de confiance configurée est une clé de signature de zone, elle authentifie la zone associée; si la clé configurée est une clé de signature de clé, elle authentifie une clé de signature de zone. Si l'ancre de confiance configuré est le hash d'une clé au lieu de la clé elle-même, le résolveur peut obtenir la clé via une requête DNS. Pour aider les résoleurs à établir cette chaîne d'authentification, les serveurs de noms tentent d'envoyer les signatures nécessaire à authentifier les clé publique de la zone dans le message de réponse DNS avec la clé publique elle-même.

   Le type RR Delegation Signer (DS) simplifie certaines tâches administratives en signant les délégation entre les limites administratives. Le RRset DS réside au point de délégation dans une zone parent et indique les clé publique correspondante aux clé privées utilisée pour signer les RRset DNSKEY dans l'apex de zone enfant déléguée. L'administrateur de la zone enfant, en retour, utilise les clés privée correspondantes à une ou plusieurs des clé publique dans ce RRset DNSKEY pour signer les données de la zone enfant. La chaîne d'authentification est donc DNSKEY-›[DS›DNSKEY]*-›RRset, où '*' dénote 0 ou plusieurs sous-chaînes DS-›DNSKEY. DNSSEC permet des chaînes d'authentification plus complexes, tels que des couches additionnelles de RR DNSKEY signant d'autres RR DNSKEY dans une zone.

   Un résolveur sécurisé construit normalement cette chaîne d'authentification depuis la racine de la hiérarchie DNS jusqu'aux zones basés sur une connaissance configurée de la clé publique pour root. La stratégie locale, cependant, peut également permettre au résolveur d'utilisen une ou plusieurs clé publique configurées (ou hash de ces clé) autre que la clé publique root, peuvent ne pas fournir de connaissance configuré de la clé publique root, ou peuvent empêcher le résolveur d'utiliser des clé publique particulières pour des raisons arbitraires, même si ces clés publique sont signées correctement et vérifiables. DNSSEC fournis des mécanismes par lesquels un résolveur peut déterminer si la signature d'un RRset est valide. Dans l'analyse finale, cependant, authentifier les clé DNS et les donnée est sujet à la stratégie locale, qui peut étendre ou même remplacer les extensions de protocole définis dans ce document.

Authentifier les noms et la non-existence de type

Le mécanisme de sécurisé décris ci-dessus ne fournis qu'une manière de signer des RRset exsistant dans une zone. Le problème des réponses négatives avec le même niveau d'intégrité et d'authentification exige l'utilisation d'un nouveau type d'enregistrement de ressource, NSEC. NSEC permet à un résolveur d'authentifier une réponse négative depuis soit le nom, ou la non-existance du type avec les même mécanisme utilisés pour authentifier les autres réponses DNS. L'utilisation des enregistrements NSEC nécessite une représentation canonique et d'ordre pour les noms de domaine dans les zones. Les chaînes d'enregistrement NSEC décrivent explicitement les gaps, ou espace vides, entre les noms de domaine dans une zone et la liste des types de RRset présent aux noms existant. Chaque enregistrement NSEC est signé et authentifié en utilisant les mécanismes décris plus haut.

Services non-fournis par la sécurité DNS

   DNS a été conçus à l'origine avec la supposition que DNS retourne la même réponse à une requête donnée sans regarder qui a émis la requête, et que toutes les données dans DNS est donc visible. DNSSEC n'est pas conçus pour fournir la confidentialité, les listes de contrôle d'accès, ou d'autres moyens de différencier les questionneurs.

   DNSSEC ne fournis pas de protection contre les attack DOS. Les résolveurs et les serveurs de nom sécurisé sont vulnérables à uen classe d'attaque DOS additionnel basé sur les opérations cryptographiques.

   Les extensions de sécurité DNS fournissent l'authentification de l'origine des données DNS. Les mécanismes définis plus haut ne sont pas conçus pour protéger es opérations telles que les transferts de zone et les mises à jours dynamiques. Les schéma d'authentification de message décris dans les rfc2845 et rfc3007 adressent les opérations de sécurité pour ces transactions.

Périmètre du document et problème Last Hop

   La spécification dans ce jeu de document définis le comportement pour les signataires de zone et les serveurs de nom sécurisés et les résolveurs qui valident les entités peuvent déterminer de manière non-ambigües l'état des données. Un résolveur validateur peut déterminer les 4 états suivants:

Secure Le résolveur validant a une ancre de confiance, a une chaîne de confiance, et est capable de vérifier toutes les signatures dans la réponse.
Insecure Le résolveur validant a une ancre de confiance, une chaîne de confiance, et, à certains points de délégation, la preuve signées de la non-existance d'un enregistrement DS. Celà indique que les branches sous-jacents dans l'arborescence sont probablement non-sécurisés. Un résolveur peut avoir une stratégie local pour marquer les parties de l'espace de domaine comme insécure.
Bogus Le résolveur validant a une ancre de confiance et une délégation sécurisée indique que les données subsidiaires sont signées, mais la réponse échoue la validation: signatures manquantes, signatures expirées, signatures avec des algorithmes non-supportés, données manquantes, etc.
Indeterminés Il n'y a pas d'ancre de confiance qui indique qu'une portion spécifique de l'arborescence est sécurisé. C'est le mode d'opération par défaut.

   Cette spécification définis seulement comment les serveurs de nom sécurisés peuvent signaler aux résolveurs non-validateurs que les données trouvés sont à l'état bogus (en utilisant RCODE=2 "Server Failure")

   Il y a un mécanisme pour les serveurs de nom sécurisés pour signaler aux résolveurs sécurisé que les données sont sécurisés (en utilisant le bit AD)

   Cette spécification ne définis pas de format pour communiquer la raison des réponses bogus ou insecure.

   Une méthode pour signaler les codes d'erreur avancés et les stratégies entre un résolveur sécurisé et les serveurs de noms récursifs est un sujet pour un travail future, tout comme l'interface entre un résolveur sécurisé et les applications qui l'utilisent. Noter, cependant, que le manque de spécification d'une telle communication n'empêche pas de déployer des zones signées ou le déploiement de serveurs de noms récursifs sécurisés qui empêchent la propagation de données bogus aux applications.

Considérations du résolveur

   Un résolveur sécurisé doit être capable d'effectuer des fonctions cryptographiques nécessaires à la vérification de signatures numérique en utilisant au moins les algorithmes obligatoire. Ces résolveurs doivent être capable de former une chaîne d'authentification depuis une nouvelle zone apprise vers une clé authentifiée, tel que décris plus haut. Ce processus peut nécessiter des requêtes additionnelles aux zones intermédiaires pour obtenir les enregistrements DNSKEY, DS, et RRSIG. Un résolveur devrait être configuré avec au moins une ancre de confiance comme point de départ depuis lequel il tente d'établir les chaînes d'authentification.

   Si un résolveur est séparé des serveurs de nom autoritatifs par un serveur de nom récursif ou par un périphérique intermédiaire qui agit comme proxy pour DNS, et si le serveur de nom récursif ou le périphérique intermédiaire n'est pas sécurisé, le résolveur n'est pas capable d'opérer dans un mode sécurisé. Par exemple, si les paquets d'un résolveur sont routés via un NAT qui inclus un proxy DNS qui n'est pas sécurisé, le résolveur peut avoir des difficultés ou l'impossibilité d'obtenir ou valider la données DNS signée.

   Si un résolveur sécurisé doit faire confiance à une zone non-signée ou un serveur de nom qui n'est pas sécurisé, le résolveur n'est pas capable de valider les réponses DNS et à besoin d'une stragégie locale pour accepter les réponses non-vérifiées

   Un résolveur sécurisé doit prendre en compte la période de validité en déterminant le TTL des données en cache, pour éviter que les données signées en cache soient au-delà de la période de validité de la signature. Cependant, il devrait être permis que l'horloge du résolveur soit fausse. Donc, un résolveur qui fait partie d'un serveur de nom récursif doit faire attention aux bit CD. Cela permet d'éviter le blocage des signatures valide via d'autres résolveurs qui sont clients de ce serveur de nom récursif.

Considérations du résolveur cache

   Bien que non strictement requis par le protocole, beaucoups de requêtes DNS ont pour origine les résolveurs cache. Ces résolveurs, par définition, sont des résolveurs minimals qui utilisent les requête récursives pour décharger le travaille de la résolution DNS à un serveur de nom récursif. L'architecture DNSSEC doit prendre en compte les résolveurs cache, mais les fonctionnalités de sécurité dans le résolveur cache diffèrent de ceux nécessaires dans un résolveur itératif sécuris.

   Même un résolveur cache non sécurisé peut bénéficier de DNSSEC si les serveurs de noms récursifs qu'il utilise sont sécurisés, mais pour que le résolveur cache puisse s'appuyer sur les services DNSSEC, le résolveur doit faire confiance à serveurs de nom récursifs en question et aux canaux de communication entre lui et ces serveurs de nom. Le premier de ces problème est un problème de stratégie locale: un résolveur non-sécurisé n'a pas le choix mais se place lui-même à la merci des serveurs de noms récursifs qu'il utilise, vu qu'il ne valide pas DNSSEC. Le second problème nécessite un mécanisme de canal sécurisé; l'utilisation des mécanismes d'authentification de transaction sécurisé comme SIG(0) ou TSIG est suffisant, et est approprié avec IPsec. Les implémentations peuvent avoir d'autres choix disponible, tels que des mécanisme de communication interprocess spécifiques à l'OS. La confidentialité n'est pas nécessaire pour ce canal, mais l'intégrité des données et l'authentification des messages le sont.

   Un résolveur sécurisé fait confiance aux serveurs de noms sécurisé et ses canaux de communication et peut choisir d'examiner le bit AD dans l'en-tête des messages qu'il reçoit. Le résolveur peut utiliser ce flag pour voir si le serveur de nom récursif est capable de valider les signatures pour toutes les données dans les sections d'autorité et de réponse

   Il y a une étape de plus qu'un résolveur sécurisé peut effectuer, s'il n'est pas capable d'établir une relation de confiance avec les serveurs de nom récursifs qu'il utilise: il peut effectuer sa propre validation de signature en définissant le bit CD dans ses requêtes. Un résolveur est capable de traiter les signatures DNSSEC comme relation de confiance entre les administrateurs de zone et le résolveur lui-même.

Considérations de zone

Il y a de nombreuses différences entre des zones signées et non-signées. Une zone signée contient des enregistrements liées à la sécurité additionnels (RRSIG, DNSKEY, DS, et NSEC). Les enregistrements RRSIG et NSEC peuvent être générées par un procéssus de signature avec de servir la zone. Les enregistrements RRSIG qui accompagnent les données de zone ont une date de création et d'expiration définis qui établissent une période de validité pour les signatures et les données de zone que les signatures couvrent.

Valeurs TTL vs Période de validité RRSIG

Il est important de noter la distinction entre la valeur TTL des RRset et la période de validité de signature spécifiée par le RR RRSIG couvrant ce RRset. DNSSEC ne change par la définition ou la fonction de la valeur TTL, qui est prévue pour maintenir la cohérence de la base dans les caches. Un résolveur cache purge les RRest de ses caches à la fin de la période spécifiée par les champs TTL et ces RRsets, sans regarder si le résolveur est sécurisé.

Les champs de création et d'expiration dans le RR RRSIG, spécifient la période durant laquelle la signature peut être utilisée pour valider les RRset couvert. Les signatures associées avec les données de zone signées sont seulement valides pour la période de temps spécifiés par ces champs dans les RR RRSIG en question. Les valeurs TTL ne peuvent pas étendre la période de validit des RRset signés dans le cache du résolveur, mais le résolveur peut utiliser le temps restant avant l'expiration du la période de validité de la signature d'un RRset comme limite supérieur pour le TTL du RRset signé et ses RR RRSIG associés dans le cache.

Problème de dépendance temporelle pour les zones

L'information dans une zone signée a une dépendance temporelle qui n'existe pas dans le protocole DNS original. Une zone signée nécessite une maintenance régulière pour s'assurer que chaque RRset dans la zone a un RR RRSIG valide. La période de validité de signature d'un RR RRSIG est un interval durant lequel la signature pour un RRset signé particulier peut être considéré comme valide, et les signatures des différents RRset dans une zone peuvent expirer à des moments différents. Resigner un ou plusieurs RRset dans une zone va changer un ou plusieurs RR RRSIG, qui en retour nécessite d'incrémenter le numéro de série SOA de la zone pour indiquer qu'une zone a changé et resigner le RRset SOA lui-même. Donc, resigner un RRset dans une zone peut également déclencher des messages DNS NOTIFY et des opération de transfert de zone.

Considérations de serveur de nom

   Un serveur de nom sécurisé devrait inclure les enregistrements DNSSEC appropriés (RRSIG, DNSKEY, DS, et NSEC) dans toutes les réponses aux requêtes des résolveurs qui ont signalé leur volonté de recevoir de tels enregistrement via l'utilisation du bit DO dans l'en-tête EDNS, sujet aux limitations de taille de message. À cause de l'ajout de ces RR DNSSEC pouvant facilement tronquer le message UDP et retourner en TCP, un serveur de nom sécurisé doit également supporter le mécanisme UPD "sender's UDP payload".

   Si possible, la partie privée de chaque paire de clé DNSSEC devrait être conservée hors-ligne, mais ce n'est pas possible pour une zone pour laquelle les mises à jours dynamiques sont permis. Dans le cas des mises à jours dynamiques, le serveur maître primaire pour la zone doit resigner la zone quand elle est mise à jours, dont la clé privée correspondant à la ZSK doit être online. C'est une exemple de situation dans laquelle la capacité de séparer le RRset DNSKEY de la zone en ZSK et KSK peut être utile, vu que la KSK peut rester offline et peut avoir une durée de vie plus longue que les ZSK.

   Par lui-même, DNSSEC n'est pas suffisant pour protéger l'intégrité d'une zone durant les opérations de transfert de zone, vu que même une zone signée contient des données non-signées, non-authoritatives si la zone a des enfants. Donc, les opérations de maintenance de zone nécessitent des mécanismes additionnels (tels que TSIG, SIG(0) ou IPsec)

Famille de document de sécurité DNS

   Le jeu de document DNSSEC peut être partitionné en plusieurs groupes sous les documents du protocole DNS de base. Les jeu de document de protocole DNSSEC réfère à 3 documents qui forment le cœur des extensions de sécurité DNS:

1. Introduction et exigents pour la sécurité DNS (ce document)
2. Enregistrements de ressource pour les extensions de sécurité DNS (rfc4034)
3. Modification de protocole pour les extensions de sécurité DNS (rfc4035)

   Le jeu de document de spécification d'algorithme de signature numérique réfère au groupe de documents qui décrivent comme les algorithmes de signature numérique devraient être implémentés dans DNSSEC. Voir la rfc4034 pour la liste des algorithmes définis.

   Le jeu de documents de protocole d'authentification de transaction réfère au groupe de documents qui gérènt l'authentification des messages DNS, incluant l'établissement et la vérification des clé secrètes.

   Je jeu de document d'utilisation des nouvelles sécurités réfère aux documents qui visent à utiliser les extensions de sécurité DNS proposés pour d'autres but de sécurité. DNSSEC ne fournis pas de sécurité directe pour ces nouvelles utilisations mais peuvent être utilisé pour les supporter. Les documents qui rentre dans cette catégorie incluent l'utilisation de DNS dans le stockage et la distribution de certificats

27 juin 2016

rfc4034

Enregistrements de ressource pour les extensions de sécurité DNS

   Les extensions de sécurité DNS introduisent 4 nouveaux type d'enregistrement de ressource DNS: DNS Public Key (DNSKEY), Resource Record Signature (RRSIG), Next Secure (NSEC), et Delegation Signer (DS). Ce document définis le but de chacun de ces RR, le format RDATA de ces RR, et leur format de présentation (ASCII).

   DNSSEC utilise la cryptographie à clé publique pour signer et authentifier les jeus d'enregistrement de ressources (RRsets). Les clé publiques sont stockées dans les RR DNSKEY et sont utilisé dans le processus d'authentification DNSSEC.: Une zone signe son RRset authoritatif en utilisant une clé privée et stocke la clé publique correspondante dans un RR DNSKEY. Un résolveur peut ainsi utiliser la clé publique pour valider les signature couvrant les RRset dans la zone, et donc les authentifier.

   Le RR DNSKEY n'est pas prévu comme un enregistrement pour stocker des clé publiques arbitraires et ne doit pas être utilisé pour stocker des certificats ou des clé publiques non liées à l'infrastructure DNS.

   La valeur Type pour le RR DNSKEY est 48, le RR DNSKEY est indépendant de la class et n'a pas de requis de TTL spécial.

Format DNSKEY RDATA

Le RDATA pour un RR DNSKEY consiste d'un champ de Flags à 2 octets, un champ Protocole 1 octet, en champ Algorithme 1 octet, et le champ de clé publique:
_____________________1_1_1_1_1_1_1_1_1_1_2_2_2_2_2_2_2_2_2_2_3_3____
____0_1_2_3_4_5_6_7_8_9_0_1_2_3_4_5_6_7_8_9_0_1_2_3_4_5_6_7_8_9_0_1_
___+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
___|______________Flags____________|____Protocol___|___Algorithm___|
___+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
___/_______________________________________________________________/
___/____________________________Public_Key_________________________/
___/_______________________________________________________________/
___+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Champ Flags

Le bit 8 est le flag de clé de zone. Si le bit 7 est mis, l'enregistrement DNSKEY maintient une clé de zone DNS, et le nom propriétaire du RR DNSKEY doit être le nom d'une zone. S'il est non-mis, l'enregistrement DNSKEY maintien un autre type de clé publique DNS et ne doit pas être utilisé pour vérifier les RRSIG qui couvrent les RRsets.

Le bit 15 est le flag de point d'entrée sécurisé, décris dans la rfc3757. Mis, l'enregistrement DNSKEY maintient une clé utilisée comme point d'entrée. Ce flag est seulement prévu pour être un départ de signature de zone, ou pour débugger les logiciel; les validateurs ne doivent pas altérer leur comportement durant le processus de validation de signature en se basant sur ce bit. Il signifie également qu'un RR DNSKEY avec le bit SEP mis à également besoin du flag Zone Key mis pour être capablede générer des signature légalement. Un RR DNSKEY avec SEP mis et le bit 7 non mis ne doivent pas être utilisés pour vérifier les RRSIG qui couvrent les RRsets.

Champ Protocol

Le champ Protocol doit avoir la valeur 3, et le RR DNSKEY doit être traité comme invalide durant la vérification de la signature si une autre valeur est trouvée.

Champ Algorithm

Identifie l'algorithme cryptographique à clé publique et détermine le format du champ de clé publique.

Champ Public Key

Maintien la clé publique. Le format dépend de l'algorithme de la clé stockée et est décrit dans un document séparé.

Notes sur le design de DNSKEY RDATA

Bient que le chaps Protocol a toujours la valeur 3, il est retenu pour compatibilité avec les premières versions de l'enregistrement KEY

Format de présentation des RR DNSKEY

Le format de présentatin de la portion RDATA est comme suit:

- Le champ Flag doit être représenté comme entier décimal non-signé. Avec les flags actuellement définis, les valeurs possibles sont: 0, 256 et 257.
- Le champ protocol doit être représenté comme entier décimal non-signé avec une valeur de 3
- Le champ algorithm doit être resprésenté comme entier décimal non-signé, ou comme mnémonique d'algortihme.
- La clé publique doit être représentée en base64.

Exemple de RR DNSKEY

Le RR DNSKEY suivant stocke un clé de zone DNS pour example.com.
example.com. 86400 IN DNSKEY 256 3 5 (_AQPSKmynfzW4kyBv015MUG2DeIQ3
_______________________________________Cbl+BBZH4b/0PY1kxkmvHjcZc8no
_______________________________________kfzj31GajIQKY+5CptLr3buXA10h
_______________________________________WqTkF7H6RfoRqXQeogmMHfpftf6z
_______________________________________Mv1LyBUgia7za6ZEzOJBOztyvhjL
_______________________________________742iU/TpPSEDhm2SNKLijfUppn1U
_______________________________________aNvv4w==__)

Les 4 premiers champs spécifient le nom propriétaire, le TTL, la Classe , et le type de RR (DNSKEY). Une valeur 256 indique que le bit de clé de zone est mis. La valeur 3 est la valeur de protocole. La valeur 5 indique l'algorithme à clé publique (RSA/SHA1). Le reste est la clé publique encodé en base64

L'enregistrement de ressource RRSIG

   DNSSEC utilise la cryptographie à clé publique pour signer et authentifier les RRset. Les signatures numériques sont stockées dans les RRSIG et sont utilisé dans le processus d'authentification DNSSEC décris dans la rfc4035. Un validateur peut utiliser ces RRSIG pour authentifier les RRest de la zone. Le RR RRSIG doit seulement être utilisé pour valider les signatures numérique utilisés pour sécuriser les opérations DNS.

   Un enregistrement RRSIG contient la signature pour un RRset avec un nom, classe et type. Le RR RRSIG spécifie un interval de validité pour la signature et utilise Algorithm, nom du signataire, et le Key Tag pour identifier le RR DNSKEY contenant la clé publique qu'un validateur peut utiliser pour vérifier la signature.

   Parce que tout RRset authoritatif dans une zone doit être protégé par une signature numérique, les RR RRSIG doivent être présents pour les noms contenant un RR CNAME. C'est un changement de la spécification DNS (rfc1034), qui status que si un CNAME est présent pour un nom, il est seulement du type permis pour ce nom. Un RRSIG et NSEC doivent exister pour le même nom qu'un enregistrement de ressource CNAME dans une zone signée.

   La valeur de Type pour le RR RRSIG est 46. Le RR RRSIG est indépendant de la classe. Un RR RRSIG doit avoir la même classe que le RRset qu'il couvre. La valeur TTL d'un RRSIG doit correspondre au TTL du RRset qu'il couvre. C'est une exception des règles de la rfc2181 pour les valeurs TTL des RR individuels dans un RRset: les RR RRSIG individuels avec le même nom propriétaire ont différentes valeur TTL si le RRset qu'ils couvrent ont différentes valeurs TTL.

Format RRSIG RDATA

Le RDATA pour un RR RRSIG consiste d'un champ Type à 2 octets, un champ Algorithm à 1 octet, un champ Labels 1 octet, un champ TTL 4 octets, un champ Signature Expiration 4 octets, un champ Signature Inception 4 octets, en tag Key 2 octets, le champ du nom du signataire et le champ Signature.
_-_-_-_-_-_-_-_-_-_-_1_1_1_1_1_1_1_1_1_1_2_2_2_2_2_2_2_2_2_2_3_3_
_0_1_2_3_4_5_6_7_8_9_0_1_2_3_4_5_6_7_8_9_0_1_2_3_4_5_6_7_8_9_0_1_
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|________Type_Covered___________|__Algorithm____|_____Labels____|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|_________________________Original_TTL__________________________|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|______________________Signature_Expiration_____________________|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|______________________Signature_Inception______________________|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|____________Key_Tag____________|_______________________________/
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+_________Signer's_Name_________/
/_______________________________________________________________/
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/_______________________________________________________________/
/____________________________Signature__________________________/
/_______________________________________________________________/
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Champ Type Covered

Ce champ identifie le type du RRset couvert pas cet enregistrement RRSIG

Champ Algorithm Number

Ce champ identifie l'algorithme cryptographique utilisé pour créer la signature.

Champ Labels

   Spécifie le nombre de labels dans le nom propriétaire du RR RRSIG. La signification de ce champs est qu'un validateur l'utilise pour déterminer si la réponse a été synthétisée depuis un wildcard. Si c'est le cas, il peut être utilisé pour déterminer quel nom propriétaire a été utilisé pour générer la signature.

   Pour valider une signature, le validateur a besoin du nom propriétaire original qui a été utilisé pour créer la signature. Si ce nom contient un label wildcard, le nom propriétaire peut avoir été étendu par le serveur durant le processus de réponse, auquel cas le validateur doit reconstruire le nom original pour pouvoir valider la signature. La rfc4035 décris comment utiliser le champ Labels pour reconstruire le nom propriétaire original.

   La valeur du champ Label ne doit pas compter le label null (root) qui termine le nom propriétaire ni le label wildcard. La valeur du champ Labels doit être inférieur ou égal au nombre de labels dans le nom propriétaire RRSIG. Par exemple, "www.example.com." a une valeur de champ Labels de 3, et "*.example.com." a une valeur de 2. Root ('.') a une valeur de 0.

   Bien que le label wildcard n'est pas inclus dans le compteur stocké dans le champ Labels du RR RRSIG, le label wildcard fait partie du nom propriétaire du RRset quant la signature est générée ou vérifiée.

Champ TTL Original

Spécifie le TTL du RRset couvert tel qu'il apparaît dans le zone authoritative.

Ce champ est nécessaire parce que le cache du résolveur décrémente la valeur TTL d'un RRset en cache. Pour valider une signature, un validateur nécessite le TTL original. la rfc4035 décris comment utiliser ce champ pour reconstruire le TTL original.

Champs Signature Expiration et Inception

Ces champ spécifie la période de validité pour la signature. L'enregistrement RRSIG ne doit pas être utilisé pour authentifier avant la date de début, et ne doit pas être utilisée pour l'authentification après la date d'expiration.

Ce champsspécifie une date et heure sous la forme d'un nombre non-signé 32bits en secondes depuis le 1 Janvier 1970 00:00:00 UTC. L'interval le plus long qui peut être exprimé par ce format est approximativement de 136ans. Un RR RRSIG peut avoir un champ Expiration qui est numérique plus petit que le champ Inception si la valeur du champ du champ d'expiration est proche du maximum 32bits ou si la signature a une durée de vie longue.

Champ Key Tag

Contient la valeur de tag de clé du RR DNSKEY qui valide cette signature.

Champs Signer's Name

Ce champ identifie le nom propriétaire du RR DNSKEY qu'un validateur est supposé utiliser pour valider cette signature. Ce champ doit contenir le nom de la zone du RRset couvert. Un émetteur ne doit pas utiliser la compression de nom DNS dans ce champ en transmettant un RR RRSIG

Champ Signature

Le champ signature contient la signature cryptographique qui couvre le RDATA RRSIG (excluant le champ signature) et le RRset spécifié par le nom du RRSIG, la classe RRSIG, et le type RRSIG. Le format de ce champ dépend de l'algorithme utilisé.

Calcul de Signature

Une signature couvre le RDATA RRSIG et couvre les données RRset spécifiées par le nom propriétaire RRSIG, la classe et le type couvert RRSIG. Le RRset est sous la forme canonique et est signé comme suit:
signature = sign(RRSIG_RDATA | RR(1) | RR(2)... )

ou '|' dénote une concaténation. RRSIG_RDATA est le format des champs RDATA RRSIG avec le champ Signer's Name sous forme canonique et le champ Signature est exclus.
RR(i) = owner | type | class | TTL | RDATA length | RDATA

owner est le nom propriétaire pleinement qualifié du RRset sous la forme canonique. Chaque RR doit avoir le même nom propriétaire et la même classe que le RR RRSIG. Chaque RR dans le Rset doit avoir le type RR listé dans le champ Type Covered du RR RRSIG. Tous nom DNS dans le champ RDATA de chaque RR doit être sous la forme canonique, et le RRset doit être trié dans l'ordre canonique.

Format de présentation RR RRSIG

Le format de présentation de la portion RDATA est comme suit:

- Le champ Type Covered est représenté comme un mnémonique du type RR. Quand le mnémonique n'est pas connus, la représentation du TYPE rfc3597 doit être utilisé.
- Le champ Algorithm doit être représenté soit comme entier décimal non-signé ou comme mnémonique.
- Le champ Labels doit être représenté comme entier décimal non-signé
- Le champ Original TTL doit être représenté comme entier décimal non-signé
- Les champs Signature Expiration Time et Inception Time doivent être représenté soit comme entier décimal non-signé indiquant les secondes depuis le 1 Janvier 1970 00:00:00 UTC, ou sous la forme YYYMMDDHHmmSS en UTC.

Noter qu'il est toujours possible de faire la distinction entre les 2 format parce que le format YYYYMMDDHHmmSS fait toujours exactement 14 chiffres, alors que la représentation décimale 32bits ne peut jamais dépasser 10 chiffres.

- Le champ Key Tag doit être représenté comme entier décimal non-signé
- Le champ Signer's Name doit être représenté en nom de domaine
- Le champ Signature est représenté en Base64.

Exemple de RR RRSIG

Le RR RRSIG suivant stocke la signature pour un RRset A de host.example.com:
host.example.com. 86400 IN RRSIG A 5 3 86400 20030322173103 (
_______________________________20030220173103 2642 example.com.
_______________________________oJB1W6WNGv+ldvQ3WDG0MQkg5IEhjRip8WTr
_______________________________PYGv07h108dUKGMeDPKijVCHX3DDKdfb+v6o
_______________________________B9wfuh3DTJXUAfI/M0zmO/zz8bW0Rznl8O3t
_______________________________GNazPwQKkRN20XPXV6nwwfoXmJQbsLNrLfkG
_______________________________J5D6fwFm8nN+6pBzeDQfsS3Ap3o= )

Les 4 premiers champs spécifient le nom propriétaire, le TTL, la classe, et le type RR (RRSIG). Le A represente le type couvert. La valeur 5 identifie l'algorithme (RSA/SHA1), la valeur 3 est le nombre de labels dans le nom propriétaire original. 86400 est le TTL d'origine pour le RRset A couvert. 20030322173103 et 20030220173103 sont les date de début et de fin de validité de la signature. 2642 est le Key Tag, et example.com. est le nom du signataire.

Noter la combinaison du nom, classe et type couvert du RR indiquent que ce RRSIG couvret le RRset A host.example.com. La valeur Labels indique qu'il n'y a pas d'expansion wildcard. Algorithm, Signer's Name et Key Tag indiquent que cette signature peut être authentifiée en utilisant un RR DNSKEY dans la zone example.com dont l'algorithme est 4 et dont le tag de clé est 2642

Enregistrement de ressource NSEC

   Le RR NSEC liste 2 choses séparée: le prochain nom propriétaire qui contient les données autoritatives ou un point de délégation RRset NS, et le jeu de type RR présents au nom propriétaire du RR NSEC (rfc3845). Le jeu complet de RR NSEC dans une zone indique quels RRset autoritatif existe dans une zone et forme également une chaîne de noms propriétaires authoritatifs dans la zone. Cette information est utilisée pour fournir un déni d'existance authentifié pour les données DNS, comme décris dans la rfc4035.

   Parce que tout nom autoritatif dans une zone doit faire partie d'une chaîne NSEC, les RR NSEC doivent être présents pour les noms contenant un RR CNAME. C'est un changement par rapport à la spécification DNS (rfc1034), qui status que si un CNAME est présent pour un nom, il est seulement du type permis pour ce nom. Un RRSIG et NSEC doivent exister pour le même nom comme le fait un RR CNAME dans une zone non-signée.

   La valeur du type pour un RR NSEC est 47. Le RR NSEC est indépendant de la classe et devrait avoir le même TTL que le champ SOA minimum TTL.

Format NSEC RDATA

Le RDATA d'un RR NSEC est comme suit:
_-_-_-_-_-_-_-_-_-_-_1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/______________________Next_Domain_Name_________________________/
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/_______________________Type_Bit_Maps___________________________/
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Champ Next Domain Name

Ce champ contient le nom propriétaire qui a les données autoritatives ou contient un RRset NS de point de délégation. La valeur de ce champ dans le dernier enregistrement NSEC dans la zone est le nom de l'apex de zone (le nom propriétaire du RR SOA de la zone). Cela indique que le nom propriétaire du RR NSEC est le dernier nom dans l'ordre canonique de la zone.

Un émetteur ne doit pas utiliser la compression de noms DNS dans ce champ en le transettant. Les noms propriétaires des RRset pour lesquel la zone donnée n'est pas autoritative (comme les enregistrements glue) ne doivent pas être listés dans ce champ sauf si au moins un RRset autoritatif existe avec le même nom propriétaire.

Champ Type Bit Maps

Identifie les types du RRset qui existe au niveau du nom propriétaire du RR NSEC. L'espace du type RR est splitté en 256 blocks, chacun représentant les 8bits LSB de l'espace du type RR 16-bits. Chaque block qui a au moins un type RR actif est encodé en utilisant un simple octet de numéro de fenêtre ( de 0 à 255), un simple octet de longueur (de 1 à 32) indiquant le nombre d'octets utilisés pour le bitmap de block, et jusqu'à 32 octets (256bits) de bitmaps. Les blocks sont présent dans le RDATA du RR NSEC en augmentant l'ordre numérique:
Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )+

   où "|" dénote la concaténation

   Chaque bitmap encode les 8bits LSB des types RR dans le block, dans l'ordre de bit réseau. Le premier bit est le bit 0. Pour le block de fenêtre 0, le bit 1 correspond au type RR 1 (A), le bit 2 correspond au RR type 2 (NS), etc. pour le block de fenêtre 1, le bit 1 correspond au RR type 257, et le bit 2 correspond au RR type 258. Si un bit est mis, il indique qu'un RRset de ce type est présent pour le nom propriétaire NSEC.

   Les bits représentant les pseudo-type doivent être effacés, vu qu'ils n'apparaîssent pas dans la zone de données. Si rencontré, ils doivent être ignorés

   Les blocks sans type ne doivent pas être inclus. Les 0 restant dans le bitmap doivent être omis. La longueur de chaque bitmap de block est déterminé par le code de type avec la valeur numérirque la plus grande.

   Le bitmap pour le RR NSEC au point de délégation nécessite une attension spéciale. Les bits correspondant au RRset NS de délégation et les type RR pour lequels la zone parent a une donnée autoritative doivent être mis; les bits correspondants à tout RRset non-NS pour lequel le parent n'est pas autoritatif doivent être effacés.

   Une zone ne doit pas inclure le RR NSEC pour un domaine qui ne maintient que des enregistrements glue.

Ajout des noms wildcard dans RDATA NSEC

Il un nom wildcard apparaît dans une zone, le label wildcard est traité comme symbole littéral et est traité de la même manière que pour tout nom propriétaire.

Format de présentation RR NSEC

Le format de présentation de la portion RDATA est comme suit:

- Le champ Next Domain Name est représenté comme un nom de domaine
- Le champs Type Bit Map est resprésenté comme une séquence de mnémoniques de type RR.

Exemple de RR NSEC

L'exemple suivant identifie les RRset associés avec alfa.example.com. et identifie le nom autoritatif suivant après alfa.example.com.
alfa.example.com. 86400 IN NSEC host.example.com. ( A MX RRSIG NSEC TYPE1234 )

   Les 4 premiers champs identifient le nom, TTL, class et type RR (NSEC). host.example.com. est le nom autoritatif suivant après alfa.example.com dans l'ordre canonique. Les mnémoniques A, MX, RRSIG, NSEC et TYPE1234 indiquent qu'il y a des RRsets correspondants associés avec le nom alfa.example.com.

  La section RDATA du RR NSEC serait encodé:

0x04 'h' 'o' 's' 't'
0x07 'e' 'x' 'a' 'm' 'p' 'l' 'e'
0x03 'c' 'o' 'm' 0x00
0x00 0x06 0x40 0x01 0x00 0x00 0x00 0x03
0x04 0x1b 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x20

   Assumant que le validateur peut authentifier cet enregistrement NSEC, il peut être utilisé pour prouver que beta.example.com n'existe pas, ou pour prouver qu'il n'y a pas d'enregistrement AAAA associé avec alfa.example.com.

Enregistrement de ressource DS

   Le RR DS réfère à un RR DNSKEY et est utilisé dans le processus d'authentification DNSKEY. Un RR DS réfèrre à un RR DNSKEY en stockant le tag de clé, le numéro d'algorithme, et un hash du RR DNSKEY. Noter que bien que le hash soit suffisant pour identifier le clé publique, stocker le tag de clé et l'algorithme aide à le processus d'identification plus efficacement. En authentifiant l'enregistrement DS, un résolveur peut authentifier le RR DNSKEY pour lequel le RR DS pointe.

   Le RR DS et son RR DNSKEY correspondant ont le même nom propriétaire, mais ils sont stockés à différents emplacements. Le RR DS apparaît seulement côté parental d'une délégation, et est autoritatif dans la zone parent. Par exemple, le DS RR pour example.com est stocké dans la zone com. Le RR DNSKEY est stocké dans la zone example.com. Cela simplifie la gestion de zone DNS et la signature de zone en introduisant une traitement de réponse spécial pour le RR DS.

   Le type pour le RR DS est 43, et est indépendant de la classe. Le RR DS n'a pas de prérequis de TTL spécial.

Format DS RDATA

Le RDATA pour un RR DS consiste d'un champ 2 octets Key Tag, un champ algorithme 1 octet Algorithm un champ 1 octet Digest Type, et un champ Digest
_____________________1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|___________Key_Tag_____________|__Algorithm____|__Digest_Type__|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/_______________________________________________________________/
/____________________________Digest_____________________________/
/_______________________________________________________________/
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Champ Key Tag

Le champ Key Tag liste le tag de clé du RR DNSKEY réferré par l'enregistrement DS. Le Key Tag utilisé par le RR DS est identique au Key Tag utilisé pas les RR RRSIG.

Champ Algorithm

Le champ algorithme liste le numéro d'algorithme du RR DNSKEY correspondant à cet enregistrement DS.

Champ Digest Type

Le RR DS réfèrre à un RR DNSKEY en inclant un hash de ce RR DNSKEY. Ce champ identifie l'algorithme utilisé pour construire le hash.

Champ Digest

Contient le hash du RR DNSKEY. Le hash est calculé en concaténant la forme canonique du nom propriétaire pleinement qualifié du RR DNSKEY uavec le RDATA DNSKEY et applique ainsi l'algorithme de hashage:
digest = digest_algorithm( DNSKEY owner name | DNSKEY RDATA);

"|" dénote la concaténation.
DNSKEY RDATA = Flags | Protocol | Algorithm | Public Key.

La taille du hash peut varier en fonction de l'algorithme et de la taille du RR DNSKEY.

Traitement des RR DS en validant les réponses

Les RR DS lient la chaîne d'authentification entre les zones, donc le RR DS nécessite une attention particulière dans le traitement. Le RR DNSKEY réferré dans le RR DS doit être une clé de zone DNSSEC. Les flags du RR DNSKEY doivent avoir le bit 7 mis. Si les flags DNSKEY n'indiquent pas une clé de zone DNSSEC, le RR DS (et le RR DNSKEY correspondant) ne doivent pas être utilisés pour le processus de validation.

Format de présentation du RR DS

Le champ key tag doit être représenté comme entier décimal non-signé. Le champ algorithm doit être réprésenté comme entier décimal non-signé ou mnémonique d'algorithme. Le champ Digest Type doit être réprésenté comme entier décimal non-signé. Le champ Digest doit être reprsenté comme une séquence de chiffres hexadécimaux sensible à la casse.

Exemple de RR DS

L'exemple suivant montre un RR DNSKEY et son RR DS correspondant:
dskey.example.com. 86400 IN DNSKEY 256 3 5 ( AQOeiiR0GOMYkDshW
__________________________________________fwJr1AYtsmx3TGkJaNXV
__________________________________________2pHm822aJ5iI9BMzNXxe
__________________________________________DRD99WYwYqUSdjMmmAph
__________________________________________egXd/M5+X7OrzKBaMbCV
__________________________________________Uh6DhweJBjEVv5f2wwjM
__________________________________________nOf+EPbtG9DMBmADjFDc
__________________________________________ljwvFw==
__________________________________________) ; key id = 60485

dskey.example.com. 86400 IN DS 60485 5 1 ( 2BB183AF5F22588179A
___________________________________________98631FAD1A292118 )

Le 4 premiers champs spécifient le nom, TTL, classe et type RR (DS). La valeur 60485 est le tag de clé pour dskey.example.com. Les RR DNSKEY, et la valeur 5 dénotent l'algorithme utilisé par ce RR DNSKEY. La valeur 1 est l'algorithme utilisé pour construire le hash, et le reste est le hash.

Forme canonique et ordre d'enregistrement de ressource

Cette section définis une forme canonique pour les enregistrements de ressource, un ordre canonique des noms DNS, et un ordre canonique d'enrgistrements de ressource dans un RRset. Un ordre de nom canonique est requis pour construire la chaîne de nom NSEC. Une forme RR canonique est l'ordre dans un RRset sont requis pour construire et vérifier les RR RRSIG.

Ordre de noms DNS canonique

Pour la sécurité DNS, les noms propriétaires sont ordonnés en traitant les labels individuels comme chaînes d'octets non-signés justifiés à gauche. L'absence d'un trie d'octet avant un octet zéro, et les lettre US-ASCII majuscule sont traités comme s'ils étaient en minuscule.

Pour calculer l'ordre canonique d'un jeu de noms DNS, on commence par trier les noms en accord avec leur labels les plus signifiant. Pour les noms dans lequel le label le plus signifiant est identique, on continue à trier en accord avec le label suivant, et ainsi de suite.

Par exemple, les noms suivants sont triés par ordre de nom DNS canoniques. Le lable le plus signifiant est "example". À ce niveau, "example" est en premier, suivis par les noms se terminant dans "a.example", puis par les noms se terminant par "z.example". Les noms dans chaque niveau sont traités de la même manière:
example
a.example
yljkjljk.a.example
Z.a.example
zABC.a.EXAMPLE
z.example
\001.z.example
*.z.example
\200.z.example

Forme RR canonique

Pour la sécurité DNS, la forme canonique d'un RR est le format des RR où:

1. Tout nom de domaine dans le RR est étendu et pleinement qualifié)
2. Toute lettre US-ASCII majuscule dans le nom propriétaire du RR sont remplacés par les lettres minuscules.
3. Si le type du RR est NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR, HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX, SRV, DNAME, A6, RRSIG, ou NSEC, toutes les lettres US-ASCII majuscule dans les noms DNS contenur dans le RDATA sont remplacés par des minuscules.
4. Si le nom propriétaire du RR est un nom wildard, le nom propriétaire est dans sa forme non-étendue originale, inclunat le label '*'
5. Le TTL du RR est mis à sa valeur d'origine telle qu'elle apparaît dans la zone autoritative d'origine ou le champ Original TTL du RR RRSIG.

Ordre RR canonique dans un RRset

Pour la sécurité DNS, les RR avec le même nom propriétaire, class et type sont triés en traitant la portion RDATA de la forme canonique de chaque RR comme séquence d'octet non-signé justifié à gauche dans laquelle l'absence d'un octet trie avant un octet zéro.

La rfc2181 spécifie qu'un RRset n'est pas autorisé à contenir des enregistrements dupliqués (plusieurs RR avec le même nom propriétaire, class, type, et RDATA). Cependant, si une implémentation détecte des RR dupliqués en plaçant le RRset dans une forme canonique, il doit traite comme une erreur de protocole. Si l'implémentation choisis de gérer cette erreur de protocole dans l'esprit du principe de robustesse, il doit supprimer les RR dupliqués pour calculer la forme canonique du RRset.

Considérations de sécurité

L'enregistrement DS pointe vers un RR DNSKEY en utilisant un hash cryptographique, le type d'algorithme de clé, et un tag de clé. L'enregistrement DS est prévu pour identifier un RR DNSKEY existant, mais il est théoriquement possible pour un attaquant de générer un DNSKEY qui corresponde à ces champs. La probabilité de construire un DNSKEY qui correspond dépend de l'algorithme de hasha utilisé. Actuellement, seul SHA-1 est définis.

Le tag de clé est utilisé pour sélectionner le RR DNSKEY efficacement, mais il n'identifie pas de manière unique un simple RR DNSKEY. Il est possible que 2 RR DNSKEY distincts aient le même nom propriétaire, le même type d'algorithme, et le même tag de clé. Une implémentation qui utiliser seulement le tag de clé pour sélectionner un RR DNSKEY peut sélectionner la mauvaise clé dans certaines circonstances.

Algorithme et types de hashage

Les extensions de sécurité DNS sont conçus pour être indépendants des algorithmes cryptographique. Les enregistrements de ressource DNSKEY, RRSIG, et DS utilisent tous un numéro d'algorithme DNSSEC pour identifier l'algorithme utilisé par le RR. le RR DS spécifie également un numéro d'algorithme de hashage.
Value_Algorithm_[Mnemonic]__Signing__References___Status
__-----_--------------------_---------_----------__---------
____0___reserved
____1___RSA/MD5_[RSAMD5]_________n______[RFC2537]__NOT_RECOMMENDED
____2___Diffie-Hellman_[DH]______n______[RFC2539]___-
____3___DSA/SHA-1_[DSA]__________y______[RFC2536]__OPTIONAL
____4___Elliptic_Curve_[ECC]______________TBA_______-
____5___RSA/SHA-1_[RSASHA1]______y______[RFC3110]__MANDATORY
__252___Indirect_[INDIRECT]______n__________________-
__253___Private_[PRIVATEDNS]_____y______see_below__OPTIONAL
__254___Private_[PRIVATEOID]_____y______see_below__OPTIONAL
__255___reserved

Le numéro d'algorithme 253 est réservé pour une utilisation privée et n'est jamais assigné à un algorithme spécifique. La zone de clé publique dans le RR DNSKEY et la zone de signature dans le RR RRSIG commence avec un nom de domaine encodé, qui ne doit pas être compressé. Le nom de domaine indique l'algorithme utilisé, et le reste de la zone de clé publique est déterminé par cet algorithme.

L'algorithme 254 est réservé pour une utilisation privée et n'est jamais assigné à un algorithme spécifique. La zone de clé publique dans le RR DNSKEY et la zone de signature dans le RR RRSIG commencent avec un octet de longueur non-signé suivi par un OID encodé BER du cette longueur. L'OID indique l'algorithme de clé privée utilisé.

Types de hash DNSSEC

Un champ Digest Type dans un RR DS identifie l'algorithme de hasha utilisé par le RR. La table suivante liste les types actuellement définis:
0 Réservé
1 SHA-1
2-255 non-assigné

Calcule du tag de clé

   Le champ key tag dans les RR RRSIG et DS fournissent un mécanisme pour sélectionner une clé publique efficacement. Dans la plupars des cas, une combinaison de nom propriétaire, algorithme, et tag de clé peut efficacement identifier un enregistrement DNSKEY. Il est essentiel de noter que le Key Tag n'est pas unique.

   Le tag de clé est le même pour tous les types d'algorithmes DNSKEY excpté l'algorithme 1. L'algorithme de tag de clé est la somme du format du RDATA DNSKEY séparé en 2 groupes d'octets. D'abord, le RDATA est traité comme séries de groupes de 2 octets. Ces groupes sont ainsi ajoutés ensemble, en ignorant les bits de retenu.

L'implémentation de référence ANSI C suivante calcule la valeur d'un Key Tag. Cette implémentation de référence s'applique à tous les algorithmes excepté l'algorithme 1. Le code est écrit pour la clarté, non l'efficacité:
/*
    On assure que l'entier fait au moins 16 bits
    Le premier octet du tag de clé sont les 8 bits MSB de la valeur retournée
    Le second octet du tag de clé sont les 8 bits LSB de la valeur retournée
*/
unsigned int
keytag (
    unsigned char key[], /*the RDATA part of the DNSKEY RR*/
    unsigned int keysize /*the RDLENGTH*/
)
{
    unsigned long ac; /*assumed to be 32 bits or larger*/
    int i; /*loop index*/

    for ( ac = 0, i = 0; i ‹ keysize; ++i )
        ac += (i & 1) ? key[i] : key[i] ‹‹ 8;
    ac += (ac ›› 16) & 0xFFFF;
    return ac & 0xFFFF;
}

Algorithme 1 pour le tag de clé

Le type de clé pour l'algorithme 1 (RSA/MD5) est définis différemment du tag de clé pour tous les autres algorithmes, pour des raisons historiques. Pour un RR DNSKEY avec l'algorithme 1, le tag de clé est les 16bits les plus signifiant des 24bits les moins signifiants dans le modulo de la clé publique. Noter que l'algorithme 1 n'est pas recommandé.

11 juillet 2016

rfc4035

Modifications de protocole pour les extensions de sécurité DNS

Les DNS Security Extensions (DNSSEC) sont une collection de nouveaux enregistrements et modifications de protocole qui ajoutent un authentification de l'origine des données et l'intégrité des données à DNS. Ce document définis les modifications du protocole DNSSEC.

Signature de zone

   DNSSEC introdui le concept de zones signées. Une zone signée inclus une clé publique DNS (DNSKEY), un enregistrement de ressource de signature (RRSIG), Next Secure (NSEC), et optionnellement une délégation de signataire (DS). Une zone qui n'inclue pas ces enregistrements n'est pas une zone signée.

   DNSSEC nécessite un changement dans la définition de l'enrgistrement de ressource CNAME, pour permettre aux RR RRSIG et NSEC d'apparaître avec le même nom propriétaire que le fait un RR CNAME.

   DNSSEC spécifie le placement de 2 nouveaux type RR, RSEC et DS, qui peuvent être placés au niveau du parent (au point de délégation). C'est une exception à l'interdiction générale de placer des données dans la zone parent.

Inclure les RR DNSKEY dans une zone

Pour signer une zone, l'administrateur de zone génère une ou plusieurs paires de clés publique/privée et les utilise pour signer les RRset authoritatif dans la zone. Pour chaque clé privée utilisée pour créer les RR RRSIG dans une zone, la zone doit inclure un RR DNSKEY de zone contenant la clé publique correspondante. Une clé de zone RR DNSKEY doit avoir le bit de clé de zone du champ de flags RDATA mis. Les clés publiques associées avec d'autres opérations DNS peuvent être stockées dans des RR DNSKEY et ne sont pas marquées comme clé de zone et ne doivent pas être utilisées pour vérifier les RRSIG.

Si l'administrateur de zone prévois une zone signé pour être utilisable pour autre chose de la sécurité, l'apex de zone doit contenir au moins un RR DNSKEY pour agir comme point d'entrée sécurisé dans la zone. Ce point d'entrée sécurisé peut ainsi être utilisé comme cible d'une délégation sécurisé via un RR DS correspondant dans la zone parent.

Inclure les RR RRSIG dans une zone

   Pour chaque RRset autoritatif dans une zone signée, il doit y avoir au moins un enregistrement RRSIG qui rencontre les exigences suivantes:

- Le nom propriétaire RRSIG est égal au nom propriétaire du RRset
- La classe RRSIG est la même que la classe du RRset
- Le champ Type Covered du RRSIG est égal au type du RRset
- Le champ Original TTL du RRSIG est égal au TTL du RRset
- Le champ Labels du RRSIG est égal au nombre de labels dans le nom propriétaire du RRset, sant compter le label root et le label le plus à gauche si c'est un wildcard
- Le champ Signer's Name du RRSIG est égale au nom de la zone contenant le RRset
- Les champs Algorithm, Signer's Name, et Key Tag identifient une clé de zone DNSKEY dans l'apex de la zone.

   Le processus pour construire le RR RRSIG pour un RRset donné est décris dans la rfc4034. Un RRset peut avoir plusieurs RR RRSIG associé avec lui. Un RR RRSIG lui-même ne doit pas être signé, vu que signer un RR RRSIG n'ajoute pas de valeur et créé une boucle infinie dans le processus de signature.

   Le RRset NS qui apparaît dans l'apex de la zone doit être signé, mais les RRset NS qui apparaîssent aux points de délégation ne doivent pas être signés. Les RRset Glue associés avec les délégation ne doivent pas être signés.

   Il doit y avoir un RRSIG pour chaque RRset utilisant au moins une DNSKEY de chaque algorithm dans le RRset DNSKEY de l'apex de la zone. Le RRset DNSKEY apex lui-même doit être signé par chaque algorithme apparaissant dans le RRset DS localisé dans le parent déléguant.

Inclure les RR NSEC dans une zone

   Chaque nom propriétaire dans la zone qui a une donnée autoritative ou un RRset NS point de délégation doit avoir un RR NSEC. Le format des RR NSEC et le processus pour le construire et donnée dans la rfc4034.

   La valeur TTL pour un RR NSEC devrait être la même que le TTL minimum de la zone.

   Un enregistrement NSEC (et son RRset RRSIG associé) ne doit pas être le seul RRset à un nom propriétaire particulier. C'est à dir, le processus de signature ne doit pas créer les RR NSEC ou RRSIG pour les nœuds de nom propriétaire qui n'est pas le nom propriétaire d'un RRset avant que la zone ne soit signée. La principale raison pour cela est un désire pour la consistance de l'espace de nom entre les versions signées et non signées de la même zone et un désire de réduire les risques de réponses inconsistantes dans les serveurs récursifs non sécurisés.

   Le bitmap de tout RR NSEC dans une zone signée doit indiquer la présence de l'enregistrement NSEC lui-même et les enregistrement RRSIG correspondants.

   La différence entre le jeu de noms propriétaire qui nécessite les enregistrements RRSIG et le jeu de noms propriétaire qui nécessitent les enregistrements NSEC est subtile et mérite d'être souligné. Les enregistrement RRSIG sont présent aux noms propriétaires de tous les RRset autoritatifs. Les enregistrements NSEC sont présents aux noms propriétaire et également aux noms propriétaires des délégations de la zone signée vers ses enfants. Ni NSEC ni RRSIG ne sont présents (dans la zone parente) aux noms propriétaire des RRset d'adresse glue. Noter, cependant, que cette distinction est généralement visible seulement durant le processus de signature de zone, vu que les RRset NSEC sont des données autoritatives et sont donc signées. Donc, tout nom propriétaire qui a un RRset NSEC aura des RR RRSIG également dans la zone signée.

   Le bitmap pour le RR NSEC au point de délégation nécessite une attention spéciale. Les bits correspondants au RRset NS délégation et tout RRset pour lequel la zone parent an une donnée autoritative doit être mis; les bits correspondants à un RRset non-NS pour lequel le parent n'est pas autoritatif doivent être effacés.

Inclure les RR DS dans une zone

   Le RR DS établis les chaînes d'authentification entre les zones DNS. Un RRset DS devrait être présent à un point de délégation quand la zone enfant est signée. Le RRset DS peut contenir plusieurs enregistrement, chacun référençant une clé publique dans la zone enfant utilisée pour vérifier le RRSIG dans cette zone. Tous les RRset DS dans une zone doivent être signés, et les RRset DS ne doivent pas apparaître dans l'apex de la zone.

   Un RR DS doit pointer vers un RR DNSKEY qui est présent dans le RRset DNSKEY de l'apex de l'enfant, et ce RRset doit être signé par la clé privée correspondante. Les RR DS qui échoue à ces conditios ne sont pas utilies pour la validation, mais parce que le RR DS et son RR DNSKEY sont dans des zones correspondantes, un erreur temporaire peut se produire.

   Le TTL d'un RRset DS matche le TTL du RRset NS déléguant (la zone contenant le RRset DS).

   La construction d'un RR DS nécessite la connaissance du RR DNSKEY correspondant dans la zone enfant, ce qui implique la communication entre les zones parent et enfant. Cette communication est un moyen opérationnel non couver par ce document.

Changement des RR CNAME

Si un RRset CNAME est présent au nom d'une zone signée, les RRset RRSIG et NESC sont requis à ce nom. Un RRset KEY à ce nom pour les mises à jours dynamique sécurisé est également fournis (rfc3007). D'autre types ne doivent pas être présent à ce nom.

C'est une modification de la définition du CNAME original de la rfc1034. La définition original du RR CNAME ne permet pas à d'autres type de cohexister avec un enregistrement CNAME, mais une zone signée exige les RR RRSIG et NSEC pour tout nom autoritatif. Pour résoudre ce conflit, cette spécification modifie la définition du RR CNAME pour lui permettre de cohexister vace les RR NSEC et RRSIG.

Type RR DNSSEC apparaissant aux coupures de zone

DNSSEC a introduit 2 nouveaux types de RR qui sont inhabituels par le fait qu'ils peuvent apparaître du côté du parent. Au niveau du point de délégation, les RR NSEC sont requit au nom propriétaire. Un RR DS peut également être présent si la zone à déléguer est signée et cherche à avoir une chaîne d'authentification dans la zone parent. C'est une exception de la spécification DNS original, qui status que seul les RRset NS peuvent apparaître dans le point de délégation du parent.

Cette spécification met à jours la spécification DNS pour permettre aux types RR NSEC et DS côté parent. Ces RRset sont autoritatif pour le parent quand ils apparaissent dans le point de délégation de la zone parent.

Service

   Cette section décris le comportement des entités qui incluent les fonctions des serveurs de nom sécurisés. Dans beaucoup de cas de telles fonctions font partie d'un serveur de nom récursif sécurisé, mais un serveur de nom autoritatif sécurisé possède certaines de ces exigences.

   Un serveur de nom sécurisé doit supporter EDNS0 (rfc2671), une taille de message d'au moins 1220 octets, et devrait supporter une taille de message de 4000 octets. Vu que les paquets IPv6 peuvent seulement être fragmentés par l'hôte source, un serveur de nom sécurisé devrait prendre en considération les étapes pour s'assurer que les datagrammes UDP qu'il transmet sur IPv6 sont fragmentés, si nécessaire, au MTU IPv6 minimum.

   Un serveur de nom sécurisé qui reçois une requête DNS qui n'inclus pas l'option EDNS pseudo-RR ou sans le bit DO doit traite les RR RRSIG, DNSKEY et NSEC comme si c'était un RRset sans traitement additionnel. Parce que le type RR DS a la propriété particulière de n'exister que dans la zone parente, les RR DS exigent toujours un traitement spécial.

   Les serveurs de nom sécurisés qui reçoivent des requêtes explicite pour les types RR de sécurité qui matchent le contenu de plus d'une zone qu'il déssert (par exemple, les RR NSEC, et RRSIG avant et après un point de délégation œu le sereur est autoritatif pour les 2 zones) devraient de comporter comme consistant. Tant que la réponse est toujours consistante pour chaque requête au serveur de nom, le serveur peut retourner au choix:

- Les RRsets au dessus de la délégation
- Les RRsets au dessous de la délégation
- Les 2
- Une section réponse vide
- Une autre réponse
- Une erreur

   DNSSEC alloue 2 nouveaux bits dans l'en-tête de message DNS: CD (Checking Disabled) et AD (Authentic Data). Le bit CD est contrôlé par les résolveurs. Un serveur de nom sécurisé doit copier le bit CD de la requête dans la réponse correspondante. Le bit AD est contrôlé par les serveurs de noms, et un serveur de nom sécurisé doit ignorer le bit AD dans les requêtes.

   Un serveur de nom sécurisé qui synthétise les RR CNAME depuis les RR DNAME (rfc2672) ne devrait pas générer de signatures pour les RR CNAME synthétisés.

Serveur de nom autoritatif

   Une fois une requête reçue qui a le bit DO de l'option EDNS(0) pseudo-RR, un serveur de nom autoritatif sécurisé pour une zone signée doit inclure les RR RRSIG, NSEC et DS, en accord avec les règles suivantes:

- Les RR RRSIG qui peuvent être utilisés pour authentifier une réponse doivent être inclus dans la réponse
- Les RR NSEC qui peuvent être utilisé pour fournir un refus d'existance authentifié doivent être inclus dans la réponse
- Soit un RRset DS ou un RR NSEC prouvant qu'aucun RR DS n'existe doit être inclus dans les référrants

   Ces règles s'appliquent seulement aux réponses où les sémantiques véhiculent des informations sur la présence ou l'absence d'enregistrement de ressource. C'est à dire, Ces règles ne sont pas prévues pour pour exclure les réponses tels que RCODE 4 (Not Implemented) ou RCODE 5 (Refused).

   DNSSEC ne change pas le protocole de transfert de zone.

Inclure les RR RRSIG dans une réponse

En répondant à une requête qui a le bit DO mis, un serveur de nom devrait tenter d'envoyer les RR RRSIG qu'un résolveur peut utiliser pour authentifier les RRset dans la réponse. Un serveur de nom devrait tenter de conserver le RRset et ses RRSIG ensemble dans une réponse. L'ajout des RR RRSIG dans une réponse est sujet aux règles suivantes:

- En plaçant un RRset signé dans une section Answer, le serveur de nom doit également placer ses RR RRSEG dans la section Answer. Les RR RRISG ont une priorité supérieur pour l'inclusion que tout autre RRset qui peuvent être inclus. Si l'espace ne permet pas d'inclure ces RR RRSIG, le serveur de nom doit mettre le bit TC.
- En plaçant un RRset signé dans la section Authority, le serveur de nom doit également placer ses RR RRSIG dans la section Authority. Les RR RRSIG ont une priorité supérieur pour l'inclusion que tout autre RRset qui peuvent être inclus. Si l'espace ne permet pas d'inclure ces RR RRSIG, le serveur de nom doit mettre le bit TC.
- En plaçant un RRset signé dans la section Additional, le serveur de nom doit également placer ses RR RRSIG dans la section Additional. Si l'espace ne permet pas d'inclure le RRset et ses RR RRSIG associés, le serveur de nom peut retenir le RRset et enlever les RR RRSIG. Si cela se produit, le serveur de nom ne doit pas définir le bit TC.

Inclure les RR DNSKEY dans une réponse

En répondant à une requête qui a le bit DO mis et que demande les RR SOA et NS à l'apex d'une zone signée, un serveur de nom autoritatif pour cette zone peut retourner le RRset DNSKEY de l'apex dans la section Additional. Dans cette situation, le RRset DNSKEY et les RR RRSIG associés ont une priorité inférieur que d'autres informations à placer dans la section additionnelle. Le server de nom ne devrait pas inclure le RRset DNSKEY sauf s'il y a suffisamment de place dans la réponse pour le RRset DNSKEY et les RR RRSIG associés. S'il n'y a pas assez de place, le server de nom doit les omettre et ne doit pas inclure le bit TC uniquement pour ces RR.

Inclure les RR NSEC dans une réponse

En répondant à une requête qui a le bit DO mis, un serveur de nom autoritatif pour une zone signée doit inclure les RR NSEC dans chacun de ces cas:

No Data: La zone contient des RRset qui matche exactement ‹SNAME, SCLASS› mais ne contient pas de RRset qui match exactement ‹SNAME, SCLASS, STYPE›.
Name Error: La zone ne contient pas de RRset qui match ‹SNAME, SCLASS›, soit exactement, soit via l'expansion wildcard
Wildcard Answer: La zone ne contient pas le RRset qui match exactement ‹SNAME, SCLASS› mais contient un RRset qui match ‹SNAME, SCLASS, STYPE› via l'expansion wildcard
Wildcard No Data: La zone ne contient pas de RRset qui match exactement ‹SNAME, SCLASS› et contient un ou plusieurs RRset que match ‹SNAME, SCLASS› via l'expansion wildcard, mais ne contient pas de RRset qui match ‹SNAME, SCLASS, STYPE› via l'expansion wildcard.

Dans chacun de ces cas, le serveur de nom inclus les RR NSEC dans la réponse pour prouver qu'un match exact pour ‹SNAME, SCLASS, STYPE› n'était pas présent dans la zone et que la réponse que le serveur retourne les données dans la zone est correct.

Inclure les RR NSEC: No Data Response

Si la zone contient des RRset matchant ‹SNAME, SCLASS› mais ne contient pas de RRset matchant ‹SNAME, SCLASS, STYPE›, le serveur de nom doit inclure le RR NSEC pour ‹SNAME, SCLASS›, puis le serveur de nom doit inclure le RR NSEC pour ‹SNAME, SCLASS› avec les RR RRSIG associés dans la section Authority de la réponse. Si l'espace ne permet pas d'inclure le RR NSEC ou les RR RRSIG associés, le serveur de nom doit mettre le bit TC.

Vu que le nom recherché existe, l'expansion wildcard ne s'applique par à cette requête, et un simple RR NSEC suffit à prouver que le type RR demandé n'existe pas.

Inclure les RR NSEC: Name Error Response

   Si la zone ne contient pas de RRset matchant ‹SNAME, SCLASS› soit exactement soit via l'expansion wildcard, le serveur doit incluse les RR NSEC suivants dans la section Authority, avec les RR RRSIG associés:

- Un RR NSEC prouvant qu'il n'y a pas de match exace pour ‹SNAME, SCLASS›
- Un RR NSEC prouvant que la zone ne contient pas de RRset qui match ‹SNAME, SCLASS› via l'expansion wildcard

   Dans certains cas, un simple RR NSEC peut prouver ces 2 points. Si c'est le cas, le serveur devrait seulement inclure le RR NSEC et les RR RRSIG une seule fois dans la section Authority

   Si l'espace ne le permet pas, le serveur doit mettre le bit TC.

   Les noms propriétaires de ces RR NSEC et RRSIG ne sont pas sujet à l'expansion wildcard quand ces RR sont inclus dans la section Authority de la réponse.

   Noter que cette forme de réponse inclus les cas dans lesquels SNAME correspond à un nom non-terminal vide dans la zone (un nom qui n'est pas le nom propriétaire pour un RRset mais qui est le nom parent d'un ou plusieurs RRset).

Inclure les RR NSEC: Wildcard Answer Response

Si la zone ne contient pas de RRset qui matche exactement ‹SNAME, SCLASS› mais contient un RRset qui matche ‹SNAME, SCLASS, STYPE› via l'expansion wildcard, le serveur de nom doit inclure la réponse étendue et les RR RRSIG étendus correspondants dans la section Answer et doit inclure dans la section Authority un RR NSEC et les RR RRSIG associés prouvant que la zone ne contient pas de match à ‹SNAME, SCLASS›. Si l'espace ne permet pas d'inclure les RR NSEC et RRSIG, le serveur doit mettre le bit TC.

Inclure les RR NSEC: Wildcard No Data Response

Ce cas est une combinaison des précédents cas. La zone ne contient pas de match exacte pour ‹SNAME, SCLASS›, et bien que la zen contient des RRset qui match ‹SNAME, SCLASS› via l'expansion wildcard, aucun RRset ne match STYPE. Le serveur de nom doit inclure les RR NSEC suivants dans la section Authority, avec les RR RRSIG associés:

- Un RR NSEC prouvant qu'il n'y a pas de RRset correspondant à STYPE au nom propriétaire wildcard qui match ‹SNAME, SCLASS›
- Un RR NSEC prouvant qu'il n'y a pas de RRset dans la zone qui aurait matché pour ‹SNAME, SCLASS›

Dans certains cas, un simple RR NSEC peut prouver les 2. Les noms propriétaire de ces RR NSEC et RRSIG ne sont pas sujet à l'expansion wildcard quand ces RR sont inclus dans la section Authority de la réponse. Si l'espace ne permet pas d'inclure les RR NSEC et RRSIG, le serveur de nom doit mettre le bit TC.

Trouver les bon RR NSEC

   Comme expliqué plus haut, il y a de nombreuses situations dans lesquelles un serveur de nom doit localiser un RR NSEC qui prouve qu'aucun RRset correspondant à un SNAME n'existe. Localiste un tel RR NSEC dans une zone autoritative est relativement simple, du moins dans le concept. La suite assume que le serveur de nom est autoritatif pour la zone. L'algorithme ci-dessous est écrit pour clareté, non pour l'efficacité.

   Pour trouver les NSEC qui prouve qu'aucun RRset ne match le nom N dans la zone Z, constuire une séquence, S, consistant des noms propriétaire de tout RRset dans Z, trié dans l'ordre canonique, sans noms dupliqué. Trouver le nom M qui aurait précédé immédiatement N dans S si un RRset avec le nom N existait. M est le nom propriétaire du RR NSEC qui prouve qu'aucun RRset n'existe avec le nom N.

   L'algorithme pour trouver le RR NSEC qui prouve qu'un nom donné n'est pas couvert par un wildcard applicable est similaire mais nécessite une étape supplémentaire. Plus précisemment, l'algorithme pour trouver le NSEC prouvant qu'aucun RRsec n'existe avec le nom wildcard applicable est précisemment le même que l'algorithme pour trouver le RR NSEC qui prouve que les RRset avec un nom propriétaire n'existe pas. La partie manquante est une méthode pour déterminer le nom du wildcard applicable non-existant. En pratique, c'est facile, parce que le serveur de nom autoritatif à déjà vérifié la présence de ce nom wildcard dans l'étape (1)(c) de l'algorithme de recherche décrit dans la rfc1034.

Inclure les RR DS dans une réponse

   En répondant à une requête qui a le bit DO mis, un serveur de nom autoritatif retournant un référant inclus les données DNSSEC avec le RRset NS.

   Si un RRset DS est présent au point de délégation, le serveur de nom doit retourner le RR DS et ses RR RRSIG associés dans la section Authority avec le RRset NS.

   Si aucun RRset DS n'est présent au point de délégation, le serveur de nom doit retourner le RR NSEC qui prouve que le RRset DS n'est pas présent et les RR RRSIG associés du RR NSEC avec les RRset NS. Le serveur de nom doit placer le RRset NS avant les RRset NSEC et les RR RRSIG associés.

   En incluant ces RR DS, NSEC, et RRSIG, la taille de message augmente et peut causer l'omission de tous les RR glue. Si l'espace ne permet pas d'inclure les RRset DS ou NSEC et RRSIG, le serveur de nom doit mettre le bit TC.

Répondre aux requêtes pour les RR DS

   Le type RR DS n'est pas courant par le fait qu'il apparaît seulement dans la zone parente. Par exemple, le RRset DS pour la délégation de "foo.example" est stockée dans la zone "example". Cela nécessite un traitement spéciale pour les serveurs de nom et les résolveurs, vu que le serveur de nom pour la zone enfant est autoritative pour le nom à la coupure de zone par les règles DNS normales mais la zone enfant ne contient pas le RRset DS.

   Un résolveur sécurisé envoie des requêtes à la zone parent en recherchant un RR DS au point de délégation. Cependant, des règles spéciales sont nécessaires pour éviter la confusion des résolveurs non sécurisés qui peuvent traiter une telle requête (par exemple, dans une configuration réseau qui force un résolveur sécurisé à canaliser ses requêtes via un serveur de nom récursif non sécurisé). Le reste de cette section décris comment un serveur de nom sécurisé traite les requêtes DS pour éviter ce problème.

   Le besoin pour un traitement spécial par un serveur de nom sécurisé survient seulement quand toutes les conditions suivantes sont rencontrées:

- Le serveur de nom a reçu une requête pour le RRset DS à la coupure de zone
- Le serveur de nom est autoritaire pour la zone enfant
- Le serveur de nom n'est pas autoritatif pour la zone parent
- Le serveur de nom n'offre pas de récursion

   Dans tous les autres cas, le serveur de nom a soit une manière d'obtenir le RRset DS soit ne s'attend pas à avoir le RRset DS même si les règles de traitement pré-DNSSEC, donc le serveur de nom peut retourner soit le RRset DS ou une erreur en accord avec les règles de traitement normal.

   Si toutes les conditions ci-dessus sont rencontrées, cependant, le serveur de nom est autoritatif pour SNAME mais ne peut pas fournir le RRset demandé. Dans ce cas, le serveur de nom doit retourner une réponse "no data" montrant que le RRset DS n'existe pas dans l'apex de la zone enfant.

Répondre aux requêtes pour le type AXFR ou IXFR

   DNSSEC ne change par le processus de transfert de zone. Une zone signée contient les RR RRSIG, DNSKEY, NSEC, et DS, mais ces enregistrement n'ont pas de signification spéciale dans les opérations de transfert de zone.

   Un serveur de nom autoritatif n'est pas tenu de vérifier qu'une zene est proprement signée avent d'envoyer ou d'accepter un transfert de zone. Cependant, un serveur de nom autoritatif peut choisir de rejeter tout le transfert de zone si la zone ne répond pas à toutes les exigences décrites dans la section Signature de zone. L'objectif principal d'un transfert de zone est de s'assurer que tous les serveurs de nom autoritatifs ont une copie identique de la zone. Un serveur de nom autoritatif qui choisis d'effectuer sa propre validation de zone ne doit pas rejeter sélectivement certains RR et en accepter d'autres.

   Les RRset DS apparaîssent seulement coté parent d'une coupure de zone et sont des données autoritatives dans la zone parent. Comme avec tout autre RRset autoritatif, le RRset DS doit être inclus dans le transfert de zone dans lequel le RRset est une donnée autoritative. Dans la cas du RRset DS, c'est la zone parent.

   Les RR NSEC apparaissent dans les zones parent et enfant à la coupure de zone et sont autoritatifs dans ces 2 zones. Les RR NSEC à la coupure de zone parent et enfant ne sont jamais identique, vu que le RR NSEC dans l'apex de la zone enfant indiquent toujours la présence du RR SOA de la zone enfant alors que le RR NSEC du parent ne l'indique pas. Comme avec tout autre RR autoritatif, les RR NSEC doivent être inclus dans les transferts de zone dans lequels ils sont des données autoritatives. Le RR NSEC parent doit être inclus dans le transfert de zone de la zone parent, et le NSEC de l'apex de la zone enfant doit être inclus dans le transfert de la zone enfant.

   Les RR RRSIG apparaissent dans les zones parent et enfant à la coupure de zone et sont autoritatifs dans la zone contenant contenant le RRset autoritatif pour lequel le RR RRSIG fournis la signature. C'est à dire, le RR RRSIG pour un RRset DS ou un RR NSEC parent à la coupure de zone sera autoritatif dans la zone parent, et le RRSIG pour un RRset dans l'apex de la zone enfant sera autoritatif dans la zone enfant. Les RR RRSIG parent et enfant à la coupure de jone ne sont jamais identique. Comme d'autres RR autoritatif, les RR RRSIG doivent être inclus dans le transfert de zone dans lequel ils sont des données autoritatives.

bits AD et CD dans une réponse autoritative

   Les bits CD et AD sont conçus pour être utilisés dans une communication entre des résolveurs sécurisés et des serveurs de nom récursifs sécurisés. Ces bits ne sont pas significatif pour le traitement par les serveurs de nom autoritatifs.

   Un serveur de nom sécurisé ne valide pas la signature pour une donnée autoritative durant le traitement de la requête, même quand le bit CD est effacé. Un serveur de nom sécurisé devrait effacer le bits CD en créant une réponse autoritative.

   Un serveur de nom sécurisé ne doit pas mettre le bit AD dans une réponse à moins que le serveur considère que tous les RRset dans les section Answer et Authority de la réponse sont authentiques. La stratégie locale d'un serveur de nom sécurisé peut considérer les données d'une zone autoritative comme authentique sans autre validation. Cependant, le serveur de nom ne doit pas le faire à moins qu'il n'obtienne la zone autoritative via un moyen sécurisé (tel qu'un mécanisme de transfert de zone sécurisé) et ne doit pas le faire sauf si ce comportement a été configuré explicitement.

   Un serveur de nom sécurisé qui supporte la récursion doit suivre les règles suivantes pour les bits CD et AD donnés ci-dessous en générant un réponse qui implique des données obtenus via la récursion.

Servers de nom récursifs

Comme indiqué dans la rfc4033, un serveur de nom récursif sécurisé est une entité qui agit dans les rôles de serveur de nom sécurisé et de résolveur sécurisé. Cette section utilise les termes "partie serveur de nom" et "partie résolveur" pour référrer au code dans un serveur de nom qui implémente ces 2 rôles.

La partie résolveur suis les règles usuelles pour le caching et le caching négatif qui s'applique à tout résolveur sécurisé

Le bit DO

La partie résolveur doit mettre le bit DO en envoyant les requêtes, sans regarder l'état du bit DO dans la requête initiale reçue par la partie serveur de nom. Si le bit DO dans une requête initiale n'est pas mise, la partie serveur de nom doit enlever tous RR DNSSEC authentifiant de la réponse mais ne doit pas enlever les type RR DNSSEC que la requête initiale a demandé explicitement.

Le bit CD

   Le bit CD existe pour permettre à un résolveur sécurisé de désactiver la validation de la signature dans le traitement du serveur de nom d'une requête particulière.

   La partie serveur de nom doit copier le paramètre du bit CD de la requête à la réponse correspondante.

   La partie serveur de nom doit passer l'état du bit CD à la partie résolveur avec le reste de la requête initiale, pour que la partie résolveur sache s'il est nécessaire de vérifier la réponse qu'il retourne à la partie serveur de nom. Si le bit CD est mis, il indique que le résolveur d'origine souhaite effectuer une authentification via sa stratégie locale. Donc, la partie résolveur n'a pas besoin d'effectuer d'authentification dans les RRset dans la réponse. Quand le bit CD est mis, le serveur de nom récursif devrait, si possible, retourner la donnée demandée au resolveur d'origine, même si la stratégie locale du serveur aurait rejeté les enregistrements en question. C'est à dire, en définissant le bit CD, le résolveur d'origine a indiqué qu'il prend la responsabilité pour effectuer sa propre authentification, et le serveur de nom n'interfers pas.

   Si la partie résolveur implémente un cache BAD et la partie serveur de nom reçois une requête qui matche une entrée dans ce cache, La réponse de la partie serveur dépend de l'état du bit CD dans la requête originale. Si le bit CD estmis, la partie serveur de nom devrait retourner la données depuis le cache; si le bit CD n'est pas mis, la partie serveur de nom doit retourner le RCODE 2 (server failure)

   L'intention de cette règle est de fournir les données brute aux clients capable d'effectuer eux-même la vérification de la signature tout en protégeant le client qui dépent de cette vérification.

Le bit AD

La partie serveur de nom ne doit pas mettre le bit AD dans une réponse à moins que le serveur considère tous les RRset dans les section Answer et Authority de la réponse comme étant authentiques. La partie serveur de nom devrait mettre le bit AD si et seulement si la partie résolveur considère tous les RRset dans les serveur Answer et Authority comme étant authentiques. La partie résolveur doit suivre la procédure décrite dans la section "Authentifier les réponses DNS" pour déterminer si les RR en question sont authentiques. Cependant, pour compatibilité, un serveur de nom récursif peut mettre le bit AD quand une réponse incluse des RR CNAME non signés si ces RR CNAME démontrent avoir été synthétisés depuis un RR DNAME authentique qui est également inclus dans la réponse en accord avec les règles de synthèse de la rfc2672.

Résolution

Cette section décrit le comportement des entités qui incluent des fonctions de résolution sécurisé. Dans la plupart des cas de telles fonctions font partie d'un serveur de nom récursif sécurisé, mais un résolveur sécurisé a de nombreuses exigences similaires. Les fonctions spécifique aux serveurs de nom récursif sécurisés sont décrits dans la section précédente.

Support EDNS

Un résolveur sécurisé doit inclure un OPT pseudo-RR EDNS avec le bit DO mis en envoyant les requêtes

Un résolveur sécurisé doit supporter une taille de message d'au moins 1220 octets, devrait supporter une taille de message de 4000 octets, et doit utiliser le champ sender,' UDP payload size dans le pseudo-RR pour annoncer la taile de message qu'il est prêt à accepter. Un couche IP du résolveur sécurisé doit gérer les paquets UDP fragmentés correctement sans regarder si ces fragments sont reçus via IPv4 ou IPv6.

Support de vérification de signature

   Un résolveur sécurisé doit supporter les mécanismes de vérification de signature et devrait les appliquer à chaque réponse reçue, excepté quand:

- Le résolveur sécurisé fait partie d'un serveur de nom récursif, et la réponse est le résultat d'une récursion à la demande d'une requête reçue avec le bit CD mis;
- La réponse est le résultat d'une requête générée directement via une interface d'application qui a instruit le résolveur de ne pas effectuer de validation pour cette requête;
- La validation pour cette requête a été désactivée par stratégie locale.

   Le support d'un résolveur sécurisé pour la vérification de signature doit inclure le support pour la vérification des noms propriétaires wildcard.

   Les résolveurs sécurisés peuvent requêter les RR de sécurité manquant en tentant d'effectuer une validation; les implémentations qui choisissent de le faire doit être prêt à recevoir une réponse qui n'est pas suffisante pour valider la réponse originale. Par exemple, une mise à jours de zone peut avoir changé ou supprimé l'information désirée entre les requêtes original et les requêtes suivantes.

   En tentant de récupérer les RR NSEC manquant qui résident dans le parent, un résolveur en mode itératif doit requêter les serveurs de nom pour la zone parent, pas la zone enfant.

   En tentant de récupérer un DS manquant, un résolveur en mode itératif doit requêter les serveurs de nom pour la zone parent. Comme vu plus haut, les serveurs de nom doivent appliquer des traitements spéciaux pour gérer le RR DS, et dans certaines situations le résolveur peut également nécessiter d'appliquer les règles spéciales pour localiser les serveurs de nom pour la zone parent si le résolveur n'a pas le RRset NS du parent. Pour localiser le RRset NS parent, le résolveur peut commencer avec le nom de délégation, enlever le label le plus à gauche, et requêter un RRset NS par ce nom. Si aucun RRset NS n'est présent à ce nom, le résolveur enlève le label le plus à gauche et retente la requête pour ce nom, en répétant le processus jusqu'à ce qu'il trouve le RRset NS ou n'ai plus de label.

Déterminer le status de sécurité des données

Un résolveur doit être capable de déterminer s'il doit s'attendre à un RRset particulier signé. Plus précisemment, un résolveur sécurisé doit être capable de faire la distinction entre 4 cas:

Sécure: Un RRset pour lequel le résolveur est capable de construire une chaîne de RR DNSKEY et DS signés depuis une ancre de confiance au RRset. Dans ce cas, le RRset devrait être signé et est sujet à validation de signature.
Insecure: Un RRset pour lequel le résolveur sait qu'il n'a pas de chaîne de RR DNSKEY et DS signé. Cela se produit quand le RRset cible est dans une zone non signée. Dans ce cas le résolveur ne peut pas vérifier la signature.
Bogus: Un RRset pour lequel le résolveur estime qu'il est en mesure d'établir une chaîne de confiance, mais n'est pas capable de le faire, soit en raison de signature qu'il ne parvient par à valider, soit à cause de données manquantes que les RR DNSSEC indiquent qu'elles devraient être présentes. Ce cas peut indiquer une attaque ou une erreur de configuration.
Indeterminate: Un RRset pour lequel le résolveur n'est pas capable de déterminer si le RRset est signé, vu que le résolveur n'est pas capable d'obtenir les RR DNSSEC nécessaire. Cela peut se produire quand le résolveur sécurisé n'est pas capable de contacter les serveurs de nom pour les zones concernées.

Ancres de confiance configurés

Un résolveur sécurisé doit être capable d'être configuré avec au moin une clé publique ou ur RR DS et devrait être capable d'être configuré avec plusieurs clé ou RR DS. Vu qu'un résolveur sécurisé n'est pas capable de valider les signatures sans ancre de confiance, le résolveur devrait avoir un mécanisme robuste pour obtenir de telles clé quand il démarre; par exemple un stockage non-volatile (disque dur) ou une configuration réseau local de confiance. Noter que les ancres de confiance couvrent également les clé qui sont mis à jours de manière sécurisé, qui peut être un support physique, un protocole d'échange de clé, ou d'autres moyens tiers.

Cacher les réponses

   Un résolveur sécurisé devrait mettre en cache chaque réponse comme simple entrée atomique contenant toute la réponse, incluant le RRset nomé et tout RR DNSSEC associé. Le résolveur devrait supprimer l'entrée quand un des RR qu'il contient expire. Dans beaucoup de cas le l'index de cache approprié pour l'entrée atomique est le triplet ‹QNAME, QTYPE, QCLASS›, mais pour les cas décris dans la section "inclure les RR NSEC: Name Error Response", l'index sera ‹QNAME, QCLASS›.

   La raison de ces recommandations est que, entre la requête initiale et l'expiration des données du cache, les données autoritatives peuvent avoir changé. Il y a 2 situation pour lesquel c'est important:

1. En utilisant l'enregistrement RRSIG, il est possible de déduire qu'une réponse a été synthétisée depuis un wildcard. Un serveur de nom récursif pourrait stocker cette donnée wildcard et l'utiliser pour générer des réponses positives aux requêtes autre que le nom pour lequel la réponse originale a été reçue.
2. Les RR NSEC reçues pour prouver la non-existance d'un nom pourrait être réutilisée par un résolveur pour prouver la non-existence d'un nom dans la plage de noms.

   En théorie, un résolveur pourrait utiliser les wildcard ou les RR NSEC pour générer des réponses positives et négatives (respectivement) jusqu'à ce que le TTL ou les signatures dans les enregistrement n'expirent. Cependant, il semble prudent pour les résolveurs d'éviter de bloquer les nouvelles données autoritatives ou de synthétiser de nouvelles donnés par eux même. Les résolveurs qui suivent cette recommandation auront une vue plus consistante de l'espace de nom.

Gérer les bits CD et AD

   Un résolveur sécurisé peut mettre le bit CD d'une requête pour indiquer que le résolveur prend la résponsabilité d'effectuer toute authentification que sa stratégie locale exige sur les RRsets dans la réponse.

   Un résolveur doit effacer le bit AD en créant une requête pour se protéger contre les serveurs de nom buggés qui copient bêtement les en-têtes qu'ils ne comprennent pas de la requête dans la résponse.

   Un résolveur doit ignorer la signification des bits CD et AD dans une réponse sauf si la réponse a été obtenue en utilisant un canal sécurisé ou le résolveur a été configuré spécifiquement pour le faire.

Cache des données BAD

   Bien que de nombreuses erreurs de validation sont transitoires, certaines sont persistantes, tel que les erreurs administratives. Vu que redemander n'aide pas dans ces cas, les résolveurs validateurs peuvent générer un quantité significative de trafique DNS non-nécessaire en mettant en cache les signatures invalides, avec quelques réstrictions.

   Conceptuellement, cacher de telles données est similaire aux caching négatif (rfc2308), excepté qu'au lieu de cacher une réponse invalide, le résolveur cache le fait qu'une réponse particulière à échoué la validation. Ce document réfèrre au cache de telles données au cache BAD.

   Les résolveurs qui implémentent un cache BAD doit effectuer certaines étapes pour éviter que le cache soit utilisé comme amplificateur d'attaque DOS, particulièrement:

- Vu que les RRset qui échouent la validation n'ont pas de TTL de confiance, l'implémentation doit leur assigner un TTL. Ce TTL devrait être petit, pour mitiger l'effet de cache de résultat d'une attaque.
- Pour éviter de cacher des erreurs de validation aléatoires (qui peuvent être le résultat d'une attaque), les résolveurs devraient suivre les requêtes qui résultent en erreurs de validation de devraient seulement répondre depuuis le cache BAD après que le nombre de fois que les réponse aux requêtes pour ce ‹QNAME, QTYPE, TCLASS› particulier a échoué la validation a excédé un valeur seuil.

   Les résolveurs ne doivent pas retourner les RRset depuis le cache BAD sauf si le résolveur n'a pas à valider les signature des RRset en question.

CNAME synthétisés

Un résolveur sécurisé validateur doit traiter la signature d'un RR DNAME signé valide comme couvrant égaleent les RR CNAME non-signés qui pourraient avoir été synthétisés depuis le RR DNAME, tel que décris dans la rfc2672, au moins dans la mesure de ne pas rejeter une réponse parce qu'elle contient seulement de tels RR CNAME.

Résolveurs stub

Un résolveur stub sécurisé doit supporter les types de RR DNSSEC, au moins pour éviter de mal gérer les réponses simplement parce qu'elles contiennent des RR DNSSEC.

Gérer les bit DO

Un résolveur stub sécurisé non-validateur peut inclure les RR DNSSEC retournés par un serveur de nom récursif sécurisé comme partie des données que le stub resolver envoie à l'application, mais ce n'est pas obligatoire. Un stub resolver qui le fait doit mettre le bit DO pour recevoir les RR DNSSEC depuis le serveur de nom récursif.

Un stub resolver sécurisé validateur doit mettre le bit DO, parce que sinon il ne reçoit pas les RR DNSSEC qu'il a besoin pour la validation de la signature.

Gérer le bit CD

Un stub resolver sécurisé non-validateur ne devrait pas mettre le bit CD en envoyant les requêtes sauf s'il est demandé par l'application, vu que par définition, un stub resolver non-validateur dépend du serveur de nom récursif sécurisé qui effectue la validation pour lui.

Un résolveur stub sécurisé validateur devrait mettre le bit CD, parce que sinon le serveur de nom récursif va répondre à la requête en utilisant la stratégie locale du serveur de nom, qui peut empêcher le stub resolver de reçevoir des données qui seraient acceptables pour la stratégie local du stub resolver.

Gérer le bit AD

Un stub resolver sécurisé non-validateur peut choisir d'examiner le bit AD dans les réponses qu'il reçoit pout déterminer si le serveur de nom récursif sécurisé qui envoie la réponse prétend avoir cryptographiquement vérifié les données dans les section Answer et Authority de la réponse. Noter, cependant, que les réponse reçues par un stub resolver sécurisé dépend de la stratégie locale du serveur de nom sécurisé. Un stub resolver ne doit pas placer de confiace dans la prétendue validation de signature effectuée, exceptée quand le stub resolver sécurisé a obtenu les données en question depuis un serveur de nom récursif sécurisé de confiance via un canal sécurisé.

Un résolveur stub validateur ne doit pas examiner le bit AD dans les messages de réponse, vu que par définition, le stub resolver effectue sa propre validation de signature.

Authentifier les réponses DNS

   Pour utiliser les RR DNSSEC pour d'authentification, un résolveur doit connaître au moins un RR DNSKEY ou DS authentifié. Le processus pour obtenir et authentifier cet ancre de confiance initial est fait via un mécanisme externe. Le reste de cette section assume que le résolveur a obtenu le jeu initial d'ancres de confiance.

   Un RR DNSKEY initial peut être utilisé pour authentifier un RRset DNSKEY dans l'apex de la zone. Pour authentifier un RRset DNSKEY apex en utilisant une clé initiale, le résolveur doit:

1. Vérifier que le RR DNSKEY initial apparaît dans le RRset DNSKEY apex, et que le RR DNSKEY a le Zone Key Flag mis.
2. Vérifier qu'il y a un RR RRSIG qui couvre le RRset DNSKEY apex, et que la combinaison du RR RRSIG et du RR DNSKEY authentifient le RRset DNSKEY. Le processus pour utiliser un RR RRSIG pour authentifier un RRset est décris plus bas.

   Une fois que le résolveur a authentifié le RRset DNSKEY apex en utilisant un RR DNSKEY initial, les délégation depuis cette zone peuvent être authentifiés en utilisant les RR DS. Celà permet à un résolveur de démarrer depuis une clé initiale et d'utiliser les RRset DS pour traiter récursivement l'arborescence DNS, en obtenant les autres RRset DNSKEY apex. Si le résolveur était configuré avec un RR DNSKEY root, et si chaque délégation a un RR DS associé avec lui, le résolveur peut obtenir et valider tout RRset DNSKEY apex. Le processus d'utilisation les RR DS pour authentifier les référrants est décris plus bas.

   Quand un résolveur indique le support pour DNSSEC (en définissant le bit DO), un serveur de nom sécurisé devrait tenter de fournir les RRset DNSSEC nécessaires dans une réponse. Cependant, un résolveur sécurisé peut reçevoir une réponse dans laquelle il manque des RR DNSSEC. Un résolveur devrait attendre les informations d'authentification des zones signées. Un résolveur devrait croire qu'une zone est signée si le résolveur a été configuré avec des informations de clé publique pour la zone, ou si le parent de la zone est signée, et contient un RRset DS.

Considérations spéciales pour les îlots de sécurité

Les îlots de sécurité sont les zones signées pour lequelles il n'est pas possible de construire une chaîne d'authentification vers la zone depuis son parent. Valider les signature dans un îlot de sécurité nécessite que le validateur ait un moyen d'obtenir une clé de zone authentifiée initiale pour l'îlot. Si un validateur ne peut pas obtenir une telle clé, il devrait opérer comme si les zones étaient non-signées.

Tous les processus normaux pour valider les réponse s'appliquent aux îlots de sécurité. La seul différence entre une validation normale et la validation d'une un îlot de sécurité et la manière dont le validateur obtient une ancre de confiance pour la chaîne d'authentification.

Authentifier les référrants

   Une fois le RRset DNSKEY apex pour une zone parent signée est authentifiée, les RRset DS peuvent être utilisés pour authentifier la délégation pour une zone enfant signée. Un RR DS identifie un RR DNSKEY dans le RRset DNSKEY apex de la zone enfant. Un RR DS identifie un RR DNSKEY dans le RRset DNSKEY dans l'apex de la zone enfant. L'utilisation d'un algorithme de hashage fort s'assure qu'il est impossible pour un attaquant de générer un RR DNSKEY qui matche le hash. Donc, authentifier le hash permet au résolveur d'authentifier le RR DNSKEY. Le résolveur peut ainsi utiliser ce RR DNSKEY pour authentifier tout le RRset DNSKEY apex enfant.

   En donnant un RR DS pour une délégatio, le RRset DNSKEY apex de la zone enfant peut être authentifié si:

- Le RR DS a été authentifié en utilisant un RR DNSKEY dans le RRset DNSKEY apex du parent.
- Algorithm et Key Tag dans le RR DS match les champs Algorithm et Key Tag d'un RR DNSKEY dans le RRset DNSKEY apex de la zone enfant, et, quand le nom propriétaire du RR DNSKEY et RDATA sont hashés en utilisant l' algorithme de hashage spécifié dans le champ Digest Type dans le RR DS, les valeurs de hash correspondent.
- Le RR DNSKEY correspondant dans la zone enfant a le bit Zone Flag mis, la clé privée correspondante a signé le RRset DNSKEY apex de la zone, et le RR RRSIG résultant authentifie le RRset DNSKEY apex de la zone enfant.

   Si le référant de la zone parent ne contient pas un RRset DS, la réponse devrait inclure un RRset NSEC signé prouvant qu'il n'y a pas de RRset DS pour le nom délégué. Un résolveur sécurisé doit requêter les serveurs de nom pour la zone parent à la recherche du RRset DS si le réferrant n'inclus ni un RRset DS ni un RRset NSEC prouvant que le RRset DS n'existe pas.

   Si le validateur authentifie un RRset NSEC qui prouve qu'aucun RRset DS n'est présent pour cette zone, il n'y a pas de chemin d'authentification entre le parent et l'enfant. Si la résolveur a un DNSKEY initial ou un RR DS qui appartient à la zone enfant ou pour une délégation sous la zone enfant, le RR initial peut être utilisé pour ré-établir un chemin d'authentification. Si un tel RR n'existe pas, le validateur ne peut pas authentifier les RRset.

   Si le validateur ne support aucun algorithme listé dans le RRset DS authentifié, le résolveur n'a pas de chemin d'authentification. Le résolveur devrait traiter ce cas comme si un RRset NSEC authentifié prouvait qu'il n'y a pas de DS RRset.

   Note que, pour une délégation signée, il y a 2 RR NSEC associés avec le nom délégué. Un RR NSEC réside dans la zone parent et peut être utilisé pour prouver si un RRset DS existe pour le nom délégué. Le second réside dans la zone enfant et identifie quels RRset sont présent à l'apex de la zone.

   Si le résolveur ne supporte aucun algorithme listé dans un RRset DS, le résolveur n'est pas capable de vérifier le chemin d'authentification pour la zone enfant. Dans ce cas, le résolveur devrait traiter la zone enfant comme si elle était non-signée.

Authentifier un RRset avec un RR RRSIG

Un validateur peut utiliser un RR RRSIG et le RR DNSKEY correspondant pour tenter d'authentifier les RRset. Le validateur vérifie d'abord le RR RRSIG pour vérifier qu'il couvre le RRset, a un interval de temps valide, et identifier un RR DNSKEY valide. Le validateur construit ensuite la forme canonique de la donnée signée en ajoutant le RDATA RRSIG (sans le champ Signature) avec la forme canonique du RRset couvert. Finalement, le validateur utilise la clé publique et la signature pour authentifier la donnée signée.

Vérifier la validité RR RRSIG

   Un résolveur sécurisé peut utiliser un RR RRSIG pour authentifier un RRset si toutes les conditions suivantes sont maintenues:

- Le RR RRSIG et le RRset doivent avoir le même nom propriétaire et la même classe
- Le champ Signer's Name du RR RRSIG doit être le nom de la zone qui contient le RRset
- Le champ Type Covered du RR RRSIG doit être égal au type du RRset.
- Le nombre de labels dans le nom propriétaire du RRset doit être supérieur ou égal à la valeur dans le champ Label du RR RRSIG
- La notion du validateur du temps courant doit être inférieur ou égal au temps listé dans le champ Expiration du RR RRSIG
- La notion du validateur du temps courant doit être supérieur ou égal au temps listé dans le champ Inception du RR RRSIG.
- Les champs Signer's Name, Algorithm, et Key Tag du RR RRSIG doivent correspondre au nom propriétaire, algorithm et key tag d'un RR DNSKEY dans le RRset DNSKEY de l'apex de zone.
- Le RR DNSKEY correspondant doit être présent dans le RRset DNSKEY de l'apex de zone, et doit avoir le bit Zone Flag mis.

   Il est possible que plus d'un RR DNSKEY corresponde aux conditions ci-dessus. Dans ce cas, le validateur ne peut pas prédéterminer lequel utiliser pour authentifier la signature, et doit tenter chaque RR DNSKEY jusqu'à ce que la signature soit validée.

   Noter que ce procéssus d'authentification est seulement significatif si le validateur authentifie le RR DNSKEY avant de l'utiliser pour valider les signatures. Le RR DNSKEY correspondant est considéré authentique si:

- Le RRset DNSKEY apex contenant le RR DNSKEY est considéré comme authentique, ou
- Le RRset couvert par le RR RRSIG est le RRset DNSKEY apex lui-même, et le RR DNSKEY match soit un RR DS authentifié de la zone parent ou matche une ancre de confiance.

Reconstruire les données signées

Une fois le RR RRSIG validé, le validateur doit reconstruire la donnée signée original. Cette donnée inclus le RDATA RRSIG (sans le champ signature) et la forme canonique du RRset. En plus d'être ordonné, la forme canonique peut également différer du RRset reçu à cause de la compression de nom DNS, des TTLs décrémentés, ou de l'expansion wildcard. La validateur devrait utiliser le reconstruction suivante:
signed_data = RRSIG_RDATA | RR(1) | RR(2)...

où "|" dénote un concaténation.
RR(i) = name | type | class | OrigTTL | RDATA length | RDATA

name est calculé en accord avec la fonction plus bas
class est la classe du RRset
type est le type du RRset et de tous les RR dans la classe
OrigTTL est la valeur du champ Original TTL du RRSIG
- Tous les noms dans le champ RDATA sont sous la forme canonique
- Le jeu de RR(i) est trié par ordre canonique

Pour calculer le nom:
let rrsig_labels = La valeur du champ Labels RRSIG

let fqdn = nom de domaine pleinement qualifié sous la forme canonique

let fqdn_labels = compteur de label dans le fqdn

if rrsig_labels = fqdn_labels, name = fqdn

if rrsig_labels ‹ fqdn_labels, name = "*." | Les labels rrsig_label les plus à droite du fqdn

if rrsig_labels › fqdn_labels
    le RR RRSIG ne passe pas nécessairement la validation et ne doit pas être utilisé pour authentifier ce RRset.

   Les RRset NSEC au point de délégation nécessitent un traitement spécial. Il y a 2 RRset NSEC distinct associé avec un nom signé délégué. Un RRset NSEC réside dans la zone parent, et spécifique quels RRset snt présent dans la zone parent. L'autre réside dans la zone enfant et identifie quels RRset sont présent à l'apex dans la zone enfant. En reconstruisant le RRset NSEC original puor la délégation depuis la zone parent, le RR NSEC ne doit pas être combiné avec les RR NSEC de la zone enfant. En reconstruisant le RRset NSEC original pour l'apex de la zone enfant, les RR NSEC ne doivent pas être combinés avec les RR NSEC de la zone parent.

   Noter que les 2 RRset NSEC au point de délégation ont un RR RRSIG correspondant avec un nom propriétaire correspondant au nom délégué, et chacun de ces RR RRSIG est une donnée autoritative associée avec la zone qui contient le RRset NSEC.

Vérifier la signature

   Une fois que le résolveur a validé le RR RRSIG et reconstruit les données signées originales, le validateur peut tenter d'utiliser la signature cryptographique pour authentifier les données signées, et donc finalement, authentifier le RRset.

   Le champ Algorithm dans le RR RRSIG identifie l'algoritme cryptographique utilisé pour générer la signature. La signature elle-même est contenue dans le champ Signature du RDATA RRSIG, et la clé publique utilisée pour vérifier la signature est contenue dans le champ Public Key du ou des RR DNSKEY correspondants

   Si le champ Labels du RR RRSIG n'est pas égal au nombre de labels dans le nom propriétaire pleinement qualifié du RRset, le RRest est soit invalide, ou le résultat d'une expansion wildcard. Le résolveur doit vérifier que l'expansion wildcard a été appliqué correctement avant de considérer le RRset comme authentique.

   Si d'autre RR RRSIG couvrent également ce RRset, la stratégie de sécurité locale du résolveur détermine s'il doit tester les RR RRSIG et comment gérer les conflits si les RR RRSIG donnent différents résultats.

   Si le résolveur accèpte le RRset, le validateur doit mettre le TTL du RR RRSIG et chaque RR dans le RRset authentifié à une valeur pas supérieur au minimum de:

- Le TTl du RRset reçu dans la réponse
- Le TTL du RR RRSIG reçu dans la réponse
- La valeur dans le champ Original TTL du RR RRSIG, et
- La différence du temps d'expiration de la signature du RR RRSIG et la date courante.

Authentifier un RRset wilcard étendu positif

Si le nombre de labels dans le nom propriétaire du RRset est supérieur au champ Labels du RR RRSIG couvrant, le RRset et sont RR RRSIG ont été créés en résultat d'une expansion wildcard. Une fois que le validateur a vérifié la signature, il doit vérifier la non-existance d'un match exacte pour la requête.

Noter que la réponse reçue par le résolveur devrait inclure tous les RR NSEC nécessaire pour authentifier la réponse.

Authentifier la non-existance

   Un résolveur peut utiliser les RR NSEC authentifiés pour prouver qu'un RRset n'est pas présent dans une zone signée. Les serveurs de nom sécurisés devraient automatiquement inclure les RR NSEC nécessaires pour les zones signées dans leur réponses aux résolveurs sécurisés.

   La non existance est déterminée par les règles suivantes:

- Si le RR demandé match le nom propriétaire d'un RR NSEC authentifié, le bit du type RR NSEC liste tous les types de RR présents au nom propriétaire, et un résolveur peut prouver que le type RR demandé n'existe pas en vérifiant le type RR dans le bit map. Si le nombre de labels dans un nom propriétaire du RR NSEC est égal au champ Labels du RR RRSIG couvrant, l'existence du RR NSEC prouve que l'expansion wildcard n'a pas été utilisé pour matcher la requête.
- Si le nom RR demandé apparaît après le nom propriétaire du RR NSEC authentifié et avant le nom listé dans le champ Next Domain du RR NSEC en accord avec l'ordre DNS canonique définis dans la rfc4034, alors aucun RRset avec le nom demandé n'existe dans la zone. Cependant, il est possible qu'un wildcard ait été utilisé pour correspondre au nom propriétaire et type du RR demandé, donc prouver que le RRset demandé n'existe pas nécessite également qu'aucun RRset wildcard possible n'existe qui pourrait être utilisé pour générer une résponse positive.

   De plus, les résolveurs sécurisés doivent authentifier les RRset NSEC qui incluent la preuve de non-existence. Pour prouver la non-existence d'un RRset, le résolveur doit être capable de vérifier les RRset demandés qui n'existent pas et dont aucun RRset wildcard n'existe. Prouver cela peut nécessiter plus d'un RRset NSEC de la zone. Si le jeu complet de RRset NSEC n'est pas présent dans une réponse (par ex, dû à un message tronqué), le résolveur sécurisé doit renvoyer la demande pour pouvoir tenter d'obtenir la collection de RR NSEC nécessaire pour vérifier la non-existence de RRset demandé. Comme avec toutes les opération DNS, cependant, le résolveur doit délimiter le travail qu'il place dans la réponse d'une requête particulière.

   Vu que le RR NSEC validé prouve la non-existence de lui-même et de ses RR RRSIG correspondants, un validateur doit ignorer les paramètres des bits NSEC et RRSIG dans un RR NSEC.

Comportement des résolveurs si les signatures échouent

Si aucun des RRSIG ne peut être validé, la résponse devrait être considérée BAD. Si la validation a été faite pour desservir une requête récursive, le serveur de nom doit retourner RCODE 2 au client. Cependant, il doit retourner la réponse complète si et seulement si la requête originale avait le bit CD mis.

07 juillet 2014

rfc4120

Le protocole Kerberos v5

Le protocole Kerberos

   Kerberos fournit un moyen de vérifier les identités des principaux sur un réseau non-sûr. Ceci est fait sans s'appuyer sur la confiance des assertions par le système hôte, sans confiance basé sur les adresses de l'hôte, sans nécessiter de sécurité physique des hôtes sur le réseau, et en assumant qui les paquets sur le réseau peuvent être lus, modifiés et insérés. Kerberos effectue une authentification dans ces conditions en tant que service d'authentification tiers en utilisant la cryptographie conventionnelle. Les extensions Kerberos peuvent permettre l'utilisation de chiffrements à clé publique durant certaines phases de l'authentification.

   Le processus d'authentification de base de Kerberos se déroule comme suit: Un client envoie une demande au serveur d'authentification (AS) pour les accréditations pour un serveur donné. l'AS répond avec ces accréditations, chiffrés avec la clé du client. les accréditations consistent d'un ticket pour le serveur et une clé de chiffrement temporaire (souvent appelé un clé de session). Le client transmet le ticket ( qui contient l'identité du client et une copie de la clé de session, le tout chiffré avec la clé du serveur) au serveur. La clé de session (maintenant partagée par le client et le serveur) est utilisé pour authentifier le client et peut optionnellement être utilisé pour authentifier le serveur. Il peut être utilisé également pour chiffrer d'autres communications entre les 2 parties ou pour échanger une clé de sous-session séparée à utiliser pour chiffrer d'autres communications.

   L'implémentation du protocole de base consiste d'un ou plusieurs serveurs d'authentification fonctionnant sur un hôte sécurisé. Les serveurs d'authentification maintiennent une base de données de principaux et leur clés secrète. Pour ajouter l'authentification à ses transactions, une application réseaux ajoute des appels à la librairie Kerberos directement ou via GSS-API. Ces appels résultent en la transmission des messages nécessaires pour accomplir l'authentification.

   Le protocole de base consiste de nombreux sous-protocoles ( ou échanges ). Il y a 2 méthodes de base pour lequel un client peut demander des accréditations. Dans la première approche, le client envoie une requête en texte clair pour le serveur désiré au serveur AS. La réponse est envoyée chiffrée avec la clé secrète du client. Généralement cette requête est pour un TGT (Ticket-Granting Ticket), qui peut être utilisé ultérieurement avec le TGS (Ticket-Granting Server). Dans la seconde méthode, le client envoie une requête au TGS. Le client utilise de TGT pour s'authentifier lui-même auprès du TGS de la même manière que s'il avait contacté un serveur d'application qui nécessitait une authentification Kerberos. La réponse est chiffrée dans la clé de session du TGT. Bien que la spécification du protocole décrive l'AS et le TGT comme des serveurs séparés, en pratique il sont souvent implémentés comme points d'entrée différents du protocole dans seul serveur Kerberos.

   Une fois obtenues, les accréditations peuvent être utilisés pour vérifier l'identité des principaux dans une transaction, pour s'assurer de l'intégrité des messages échangés entre eux, ou pour préserver la confidentialité des messages. L'application est libre de choisir qu'elle protection est nécessaire.

   Pour vérifier les identités des principaux dans une transaction, le client transmet le ticket au serveur d'application. Parce que le ticket est envoyé en clair (de partie sont chiffrés, mais ce chiffrement ne déjoue pas la répétition) et peut être intercepté et réutilisé par un attaquant, des informations additionnelles sont envoyées pour prouver que le message a bien pour origine le principal à qui le ticket a été fourni. Cette information ( appelée l'authentifiant) est chiffrée dans la clé de session et inclus un horodatage. l'horodatage prouve que le message a été récemment envoyés et n'est pas rejouée. Chiffrer l'authentifiant dans la clé de session prouve qu'il a été généré par un partie possédant la clé de session. Vu que personne excepté le principal et le serveur ne connaît la clé de session ( qui n'est jamais envoyée sur le réseau en clair ), cela garantis l'identité du client.

   L'intégrité des messages échangés entre les principaux peut également être garantis en utilisant la clé de session ( passée dans le ticket et contenus dans les accréditations ). Cette approche fournis la détection contre les attaques à répétition et les attaques par modification de flux. C'est accomplis en générant et en transmettant un checksum à l'épreuve des collisions du message du client, entrée avec la clé de session. La confidentialité et l'intégrité des messages échangés entre les principaux peuvent êrte sécurisé en chiffrant le données en utilisant la clé de session contenus dans le ticket ou la clé de sous-session trouvée dans l'authentifiant.

   les échanges d'authentification mentionnés plus haut nécessitent un accès lecture seule à la base de données Kerberos. Parfois, cependant, les entrées dans la base de données doit être modifiée, par exemple pour ajouter des principaux ou changer la clé d'un principal. Pour cela on utilise un protocole entre un client et un serveur Kerberos tiers, le serveur d'administration Kerberos (KADM). Il y a aussi un protocole pour maintenir plusieurs copies de la base Kerberos. Aucun de ces protocoles n'est décris dans ce document.

Fonctionnement inter-domaine

   Le protocole Kerberos est conçus pour opérer au delà des limites organisationnelle. Un client dans une organisation peut être authentifié pour un serveur dans une autre organisation. Chaque organisation souhaitant utiliser un serveur Kerberos établis son propre "domaine" (realm). Le nom de ce domaine dans lequel un client est enregistré fait partie du nom du client et peut être utilisé par le service final pour décider d'honorer ou non une requête.

   En établissant des clé inter-domaine, les administrateurs de 2 domaines peuvent permettre à un client authentifié dans le domaine local de prouver son identité aux serveurs dans les autres domaines. Les échanges de clé inter-domaines ( une clé séparée peut être utilisé pour chaque direction ) enregistrent le service d'allocation de ticket de chaque domaine comme un principale dans l'autre domaine. Un client est ainsi capable d'obtenir un TGT pour le service d'allocation de ticket du royaume distant depuis le domaine local. Quand ce TGT est utilisé, le service d'allocation de ticket distant utilise la clé inter-domaine ( qui généralement diffère de sa propre clé TGS normale ) pour déchiffrer le TGT; ainsi il est certain que le ticket a été fournis par le TGS du client. Les tickets fournis par le service d'allocation de ticket distant va indiquer au service final que le client a été authentifié depuis un autre domaine.

   Sans opération inter-domaine et avec les permissions appropriées, le client peut l'enregistrement d'un principal nommé séparément dans en royaume distant et engager un échange normal avec ce domaine. Cependant, même pour un petit nombre de clients, cela devient lourd à gérer, et méthodes plus automatiques sont nécessaires.

   Un domaine est dit communiquer avec un autre si les 2 domaines partagent un clé inter-domaine, ou si le domaine local partage une clé inter-domaine avec un domaine intermédiaire qui communique avec le domaine distant. Un chemin d'authentification est la séquence de domaines intermédiaire qui servent de transit d'un domaine à un autre.

   Les domaines peuvent être organisés hiérarchiquement. Chaque domaine partage une clé avec son parent et une clé différente avec chaque enfant. Si une clé inter-domaine n'est pas directement partagée par 2 domaines, l'organisation hiérarchique permet de construire facilement un chemin d'authentification. Si une organisation hiérarchique n'est pas utilisée, il peut être nécessaire de consulter une base de données pour construire un chemin d'authentification entre les domaines.

   Bien que les domaines sont typiquement hiérarchiques, les domaines intermédiaire peuvent être bypassés pour effectuer une authentification inter-domain au travers d'un chemin alternatif. Il est important pour le service final de connaître les domaines traversés. Pour simplifier cette décision, un champ dans chaque ticket contient les noms des domaines qui ont servis dans l'authentification du client.

   Le serveur d'application est responsable au final d'accepter ou non l'authentification et devrait vérifier le champ de transit. Le serveur d'application peut choisir de s'appuyer sur le KDC pour la vérification de ce champ. Le KDC du serveur d'application va mettre le flag TRANSITED-POLICY-CHECKED dans ce cas. Les KDC des domaines intermédiaire peuvent également vérifier ce champ vu qu'ils fournissent des TGT pour d'autre domaines, mais ils sont encouragés à ne pas le faire. Un client peut demander que les KDC ne vérifient pas ce champ en mettant le flag DISABLE-TRANSITED-CHECK. Les KDC devraient honorer ce flag.

Choisir un principal avec lequel communiquer

   Le protocole Kerberos fournis un moyen de vérifier que l'entité avec laquelle il communique est la même que celle enregistrée avec le KDC en utilisant l'identité revendiquée (le principal). Il est nécessaire de déterminer que cette identité correspond à l'entité avec laquelle on tente de communiquer.

   Quand des données appropriées ont été échangées en avance, l'application peut effectuer cette détermination syntaxiquement basé sur la spécification du protocole de l'application, les informations fournies par l'utilisateur, et les fichiers de configuration. Par exemple, le nom principal du serveur (incluant le domaine) pour un serveur telnet peut être dérivé du nom d'hôte spécifié par l'utilisateur (depuis la ligne de commande), le préfixe "host/" spécifié dans la spécification du protocole de l'application, et un mappage à un domaine Kerberos dérivé syntaxiquement depuis la partie domaine du nom d'hôte et des informations spécifiées depuis la base de domaines Kerberos locale.

   On peut également s'appuyer sur les tiers de confiance qui font cette détermination, mais seulement quand les données obtenues depuis un tiers sont convenablement protégées en intégrité lorsqu'elles résident sur le serveur du tiers de confiance et lors de leur transmission. Par exemple, on ne devrait pas pas se fier à un enregistrement DNS non protégé pour

   Les implémentations de Kerberos et les protocoles basés sur Kerberos ne doivent pas utiliser de requêtes DNS non sécurisés pour canoniser les composants du nom d'hôte des noms de principal de service. Dans un environnement sans service de nom sécurisé, les auteurs d'application peuvent ajouter un nom de domaine configuré statiquement pour les noms d'hôtes non qualifiés avant de passer ce nom aux mécanismes de sécurité. Les facilités de service de nom sécurisés, si disponible, peuvent être trustés pour la canonisation de nom d'hôte, mais une telle canonisation par le client ne devrait pas être requise par les implémentations du KDC.

Authorisation

   En tant que service d'authentification, Kerberos fournis un moyen de vérifier l'identité des principaux sur un réseau. L'authentification est généralement la première étape dans le processus d'autorisation, déterminant si un client peut utiliser un service, à quels objets le client à accès, et le type d'accès permis pour chacun. Kerberos ne fournis pas par lui-même d'autorisation. La possession d'un ticket client pour un service fournis uniquement l'authentification de ce client pour ce service, et en l'absence de procédure d'autorisation, une application ne devrait pas lui autoriser l'utilisation de ce service.

   Des méthodes d'autorisation séparés peuvent être implémentés comme fonctions de contrôle d'accès spécifique à l'application et peut utiliser des fichiers sur le serveur d'application, sur des accréditations d'autorisation fournis séparément tels que ceux fournis dans les proxys. Ces accréditations peuvent être embarqués dans une donnée d'authentification du ticket lorsqu'il est encapsulé par l'élément de données d'autorisation produit par le KDC.

   Les applications ne devraient pas accepter la délivrance d'un ticket de service par le serveur Kerberos (même par un serveur Kerberos modifié) comme accordant l'autorisation d'utiliser le service, car de telles applications peuvent devenir vulnérables au détournement de cette vérification d'autorisation dans un environnement où sont fournies d'autres options pour l'authentification d'application, ou si elles interopèrent avec d'autres KDC.

Étendre Kerberos sans rupture d'intéropérabilité

   Avec la base d'implémentation de Kerberos déployée grandissante, étendre Kerberos devient de plus en plus important. Malheureusement, certaines extensions du protocole existant créent des problèmes d'intéropérabilité à cause de l'incertitude au regard du traitement de certaines options d'extentions par certaines implémentations.

   Kerberos fournis un mécanisme général pour l'extensibilité du protocole. Certains messages du protocole contiennent des trous typés -- des sous-messages qui contiennent une chaîne d'octet et un entier qui définis comment interpréter cette chaîne d'octet. Les types entier sont enregistrés centralement, mais ils peuvent être utilisés par les vendeurs d'extension et pour les extensions standardisés.

   Dans ce document, le mot extension réfère à une extension en définissant un nouveau type à insérer dans un trou typé existant dans un message du protocole. Il ne réfère pas à l'extension en ajoutant de nouveaux champs ASN.1, sauf mention.

Envoyer des messages extensibles

If faut s'assurer que les anciennes implémentations peuvent comprendre les messages envoyés, même si elles ne comprennent pas une extension utilisée. À moins que l'emeteur sache qu'une extension est supportée, l'extension ne peut pas changer les sémantiques du coeur du message ou des extensions définies précédemment.

Par exemple, une extension incluant des information de clé nécessaire à déchiffrer la partie chiffrée d'un KDC-REP pourrait seulement être utilisé dans les situations où le receveur est connus pour supporter l'extension. Donc en définissant de tels extensions il est important de fournir une manière pour le receveur de notifier à l'envoyeur la prise en charge de l'extension. Par exemple dans le cas d'une extension qui change la clé de réponse de KDC-REP, le client pourrait indiquer la prise en charge de l'extension en incluant un élément padata dans la séquence AS-REQ. Le KDC ne devrait utiliser l'extension que si cet élément padata est présent dans le AS-REQ. Même si la politique exige l'utilisation de l'extension, il est préférable de retourner une erreur en indiquant que l'extension est exigée que d'utiliser l'extension alors que le receveur peut ne pas la prendre en charge.

Hypothèse sur l'environnement

Kerberos impose quelques hypothèses sur l'environnement dans lequel il peut fonctionner de façon appropriées, qui sont les suivantes:

- Les attaques DOS ne sont pas résolues avec Kerberos. Il y a des endroits dans le protocoles où un intrus peut empêcher une application de participer aux étapes d'authentification appropriées.
- Les principaux doivent garder secrètes leurs clés secrète. Si un intrus s'empare d'une manière un d'une autre de la clé d'un principal, il sera capable de se faire passer pour ce principal ou de se déguiser en n'importe quel serveur du principal légitime.
- Les attaques en devinant le mot de passe ne sont pas résolues par Kerberos. Si un utilisateur choisit un mot de passe faible, il est possible à un agresseur de monter avec succès une attaque de dictionnaire.
- Chaque hôte sur le réseaux doit avoir une horloge synchronisée à l'heure des autres hôtes. Cette synchronisation est utilisée pour réduire les besoins d'enregistrement des serveurs d'application lorsqu'ils refont effectivement la détection. Si les horloges sont synchronisées sur le réseaux, le protocole doit lui-même être synchronisé. Le degré d'approximation normal est de l'ordre de 5 minutes
- Les identifiants de principal ne sont pas recyclés à court terme. Un contrôle de mode d'accès normal utilise des ACL pour accorder les permissions à des principaux particuliers. Si une entrée d'acl périmée subsiste pour un principal supprimé et si l'identifiant du principal est réutilisé, le nouveau principal va hériter des droits spécifiés dans l'entrée d'acl périmée. On supprime ce problème en ne réutilisant pas les identifiants de principal.

Glossaire

Authentification Vérifier l'identité revendiquée par un principal
En-tête d'authentification Enregistrement qui contient un ticket et un authentifiant à présenter à un serveur au titre du processus d'authentification.
Chemin d'authentification Séquence de domaines intermédiaires traversés dans le processus d'authentification lors de la communication d'un domaine à l'autre.
Authentifiant Enregistrement contenant des informations dont on peut montrer qu'elles ont été générées récemment en utilisant la clé de session connue seulement du client et du serveur.
Autorisation Processus pour déterminer si un client a la permission d'utiliser un service, à quels objets le client a la permission d'accès et le type d'accès permis pour chacun.
Capacité Jeton qui accorde au porteur la permission d'accéder à un objet ou service. Dans Kerberos, ce peut être un ticket dont l'utilisation est restreinte par le contenu du champ de données d'autorisation, mais qui ne donne pas d'adresse réseau, avec la clé de session nécessaire pour utiliser le ticket.
Texte chiffré Résultat d'une fonction de chiffrement. Le chiffrement transforme le texte clair en texte chiffré
Client Processus qui utilise un service réseau au nom d'un utilisateur. Noter que dans certains cas, un serveur peut être lui-même un client de quelque autre serveur (par exemple, un serveur d'impression peut être un client d'un serveur de fichiers)
Accréditifs Un ticket plus la clé de session secrète nécessaire pour utiliser ce ticket avec succès dans un échange d'authentification
Type de chiffrement (etype) Associé à des données chiffrées; un type de chiffrement identifie l'algorithme utilisé pour chiffrer les données et est utilisé pour choisir l'algorithme approprié pour déchiffrer les données. Les étiquettes de type de chiffrement sont communiquées dans d'autres messages pour énumérer les algorithmes qui sont souhaités, pris en charge, préférés, ou permis en utilisation pour le chiffrement des données entre les parties. Cette préférence est combinée aux informations et politiques locales pour choisir l'algorithme à utiliser.
KDC (Key Distribution Center) Centre de distribution de clés. Service réseau qui fournit les tickets et les clés de sessions temporaires ; ou instance de ce service ou l'hôte sur lequel il fonctionne. Le KDC sert à la fois le ticket initial et les demandes de ticket d'allocation de ticket. La portion de ticket initial est parfois appelée serveur (ou service) d'authentification. La portion de ticket d'allocation de ticket est parfois appelée serveur (ou service) d'allocation de ticket.
Kerberos Nom donné au service d'authentification du Projet Athéna, protocole utilisé par ce service, ou code utilisé pour mettre en œuvre le service d'authentification. Le nom vient de celui du chien à trois têtes qui garde l'Hadès
Numéro de version de clé (kvno,Key Version Number) Étiquette associée aux données chiffrées qui identifie quelle clé a été utilisée pour le chiffrement lorsque une clé à longue durée associée à un principal change au fil du temps. Il est utilisé durant la transition vers une nouvelle clé de sorte que la partie qui déchiffre un message puisse dire si les données ont été chiffrées avec la vieille ou la nouvelle clé
Texte en clair Entrée dans une fonction de chiffrement ou sortie d'une fonction de chiffrement. Le déchiffrement transforme le texte chiffré en texte clair.
Principal Entité client ou serveur nommée qui participe à une communication réseau, avec un nom qui est considéré comme canonique.
Identifiant de principal Nom canonique utilisé pour identifier de façon univoque chaque différent principal.
Sceau Pour chiffrer un enregistrement contenant plusieurs champs de telle sorte que les champs ne puissent pas être remplacés individuellement sans connaissance de la clé de chiffrement ou sans laisser de traces d'altération.
Clé secrète Clé de chiffrement partagée par un principal et le KDC, distribuée en dehors des limites du système, avec une durée de vie longue. Dans le cas du principal d'un utilisateur humain, la clé secrète peut être déduite d'un mot de passe.
Serveur Principal particulier qui fournit une ressource aux clients réseau. Le serveur est parfois appelé serveur d'application.
Service Ressource fournie aux clients réseau; souvent fournie par plus d'un serveur (par exemple, un service de fichier distant)
Clé de session Clé de chiffrement temporaire utilisée entre deux principaux, avec une durée de vie limitée à la durée d'une seule "session" de connexion. Dans le système Kerberos, une clé de session est générée par le KDC. La clé de session est distincte de la sous-clé de session, décrite ci-après
Sous-clé de session Clé de chiffrement temporaire utilisée entre deux principaux, choisie et échangée par les principaux en utilisant la clé de session, et avec une durée de vie limitée à la durée d'une seule association. La sous-clé de session est aussi appelée sous-clé.
Ticket Enregistrement qui aide un client à s'authentifier auprès d'un serveur; il contient l'identité du client, une clé de session, un horodatage, et d'autres informations, toutes scellées en utilisant la clé secrète du serveur. Il ne sert qu'à authentifier un client lorsqu'il est présenté avec un authentifiant frais.

Utilisation et demandes de flags de ticket

Chaque ticket Kerberos contient un ensemble de flags utilisés pour indiquer les attributs de ce ticket. La plupart des flags peuvent être demandés par un client lorsque le ticket est obtenu; certains sont automatiquement activés et désactivés en fonction des besoins du serveur. À l'exception du flag INVALID, les clients doivent ignorer les flags qu'ils ne reconnaissent pas. Les KDC doivent ignorer les options KDC qui ne sont pas reconnus. Certaines mises en œuvre de la rfc1510 sont connues pour rejeter les options KDC si la demande a été rejetée alors qu'elle avait été envoyée avec des options ajoutées depuis la rfc1510. Comme les nouveaux KDC ignorent les options inconnues, les clients doivent confirmer que le ticket retourné satisfait leur besoins.

Noter qu'il n'est en général pas possible de déterminer si une option n'a pas été satisfaite parce qu'elle n'a pas été comprise ou si elle a été rejetée à cause de la configuration ou de la politique. Lors de l'ajout d'une nouvelle option au protocole Kerberos, les concepteurs devraient examiner si la distinction est importante pour leur option. Si elle l'est, il faut fournir un mécanisme pour que le KDC retourne une indication comme quoi l'option a été comprise mais rejetée, dans la spécification de l'option. Souvent dans de tels cas, le mécanisme doit être suffisamment tolérant pour permettre qu'une erreur soit retournée.

Ticket initial, pré-authentification, et matériel authentifié

Le flag INITIAL indique qu'un ticket a été produit en utilisant le protocole d'AS, plutôt que produit sur la base d'un TGT. Les serveurs d'application qui veulent demander la preuve de la connaissance de la clé secrète d'un client (par exemple, un programme à changement de mot de passe) peut insister pour que ce flag soit établi dans tous les tickets qu'il accepte, et peut donc être assuré que la clé du client a été récemment présentée au serveur d'authentification.

Les flags PRE-AUTHENT (pré-authentifié) et HW-AUTHENT (matériel-authentifié) donnent des informations supplémentaires sur l'authentification initiale, que le ticket en cours ait été produit directement (dans ce cas le flag INITIAL est établi) ou qu'il soit produit sur la base d'un TGT (le flag INITIAL n'est pas mis, mais PRE-AUTHENT et HW-AUTHENT sont ramenés du TGT).

Tickets invalides

Le flag INVALID indique qu'un ticket est invalide. Les serveur d'application doivent rejeter les tickets qui ont ce fjag. Un ticket postdaté sera toujours produit sous cette forme. Les tickets invalides doivent être validés par le KDC avant utilisation, en étant présentés au KDC dans une demande TGS avec l'option VALIDATE spécifié. Le KDC ne validera le ticket qu'après l'heure de début soit passée. La validation est exigée de sorte que les tickets postdatés qui ont été volés avant leur heure de début puissent être rendus invalides de façon permanente (grâce à un mécanisme de liste noire)

Tickets renouvelables

   Les applications peuvent désirer détenir des tickets qui soient valides pour de longues durées. Cependant, cela peut exposer leurs accréditifs à des menaces de vol. Utiliser simplement des tickets à courte durée de vie et en obtenir périodiquement de nouveaux exige que le client ait un accès à long terme à sa clé secrète, ce qui présente un risque encore plus grand. Les tickets renouvelables peuvent être utilisés pour atténuer les conséquences d'un vol. Les tickets renouvelables ont 2 heures d'expiration: la première est quand l'instance actuelle du ticket expire, et la seconde est la valeur permissible la plus tardive pour une heure d'expiration individuelle. Un client d'application doit périodiquement présenter au KDC un ticket renouvelable, avec l'option RENEW dans la demande.

   Le KDC va produire un nouveau ticket avec une nouvelle clé de session et une nouvelle heure d'expiration. Tous les autres champs du ticket sont laissés inchangés par le processus de renouvellement. Lorsque arrive l'heure d'expiration la plus tardive permissible, le ticket est expiré de façon permanente. À chaque renouvellement, le KDC peut consulter une liste noire pour déterminer si le ticket a été noté volé depuis son dernier renouvellement.

   Le flag RENEWABLE dans un ticket n'est normalement interprété que par le service d'allocation de tickets. Il peut habituellement être ignoré par les serveurs d'application. Cependant, certains serveurs d'application particulièrement soigneux peuvent interdire les tickets renouvelables.

   Si un ticket renouvelable n'est pas renouvelé à son heure d'expiration, le KDC ne renouvellera pas le ticket. Le flag RENEWABLE est rétabli par défaut, mais un client peut demander qu'il soit établi en mettant l'option RENEWABLE dans le message KRB_AS_REQ. S'il est établi, le champ renew-till dans le ticket contient l'heure après laquelle le ticket ne peut plus être renouvelé.

Tickets postdatés

   Les applications peuvent parfois avoir besoin d'obtenir des tickets à utiliser beaucoup plus tard; par exemple, un système de soumission par lots aura besoin de tickets valides au moment où le lot est à traiter. Cependant, il est dangereux de détenir des tickets valides dans une file d'attente. Les tickets postdatés fournissent le moyen d'obtenir ces tickets du KDC au moment de la soumission de la tâche, mais de les laisser dormants jusqu'à ce qu'ils soient activés et validés par une demande ultérieure du KDC. Si un vol de ticket devait être rapporté dans l'intervalle, le KDC refuserait de valider le ticket.

   Le flag MAY-POSTDATE dans un ticket n'est normalement interprété que par le service d'allocation de tickets. Il peut être ignoré par les serveurs d'application. Ce flag doit être établi dans un TGT afin de produire un ticket postdaté sur la base du ticket présenté. Il est rétabli par défaut; un client peut le demander en établissant l'option ALLOW-POSTDATE dans le KRB_AS_REQ. Ce flag ne permet pas à un client d'obtenir un TGT postdaté; les TGT postdatés ne peuvent être obtenus qu'en demandant le postdatage dans le KRB_AS_REQ. La durée de vie d'un ticket postdaté sera la durée de vie restante du TGT au moment de la demande. Sauf si l'option RENEWABLE est aussi établie, auquel cas elle peut être la durée de vie complète du TGT. Le KDC peut limiter la durée d'un ticket postdaté.

   Le flag POSTDATED indique qu'un ticket a été postdaté. Le serveur d'application peut vérifier le champ authtime dans le ticket pour voir quand est survenue l'authentification originale. Certains services peuvent choisir de rejeter ces tickets, ou ne les accepter que dans une certaine période après l'authentification originale. Lorsque le KDC produit un ticket POSTDATED, il sera aussi marqué INVALID, de sorte que le client d'application doit présenter le ticket au KDC pour validation avant utilisation.

Tickets mandatables et mandataires

   Il peut être nécessaire qu'un principal permette à un service d'effectuer une opération en son nom. Le service doit être capable de prendre l'identité du client, mais seulement pour un objet particulier. Un principal peut permettre à un service de faire cela en lui accordant un mandat (proxy).

   Le processus de délivrance d'un mandat en utilisant les flags proxy et proxiable est utilisé pour fournir des accéditifs à utiliser avec des services spécifiques. Bien que ce soit conceptuellement aussi un mandat, les utilisateurs qui souhaitent déléguer leur identité dans une forme utilisable à tous propos doivent utiliser le mécanisme de transmission de ticket décrit au paragraphes suivant pour transmettre un TGT.

   Le flag PROXIABLE dans un ticket n'est normalement interprété que par le service d'allocation de tickets. Il peut être ignoré par les serveurs d'application. Lorsqu'il est établi, ce flag dit au TGS qu'il est d'accord pour produire un nouveau ticket (mais pas un TGT) avec une adresse réseau différente fondée sur ce ticket. Ce flag est établi s'il est demandé par le client à l'authentification initiale. Par défaut, le client demandera qu'il soit établi lorsqu'il demande un TGT, et gu'il soit rétabli lorsqu'il demande tout autre ticket.

   Ce flag permet à un client de passer au serveur proxy d'effectuer une demande distante en son nom (par exemple, un client de service d'impression peut donner mandat au serveur d'impression d'accéder aux fichiers du client sur un serveur de fichiers particulier afin de satisfaire à une demande d'impression).

   Afin de compliquer l'utilisation des accréditifs volés, les tickets Kerberos sont souvent valides pour les seules adresses réseau spécifiquement incluses dans le ticket, mais il est permis, comme option de politique de permettre des demandes et de produire des tickets sans aucune adresse réseau spécifiée. Lorsqu'il accorde un mandat, le client doit spécifier la nouvelle adresse réseau à partir de laquelle le mandat sera utilisé ou indiquer que le mandat est produit pour être utilisé sur toute adresse.

   Le flag PROXY est établi dans un ticket par le TGS lorsqu'il produit un ticket proxy. Les serveurs d'application peuvent vérifier ce flag; et optionnellement peuvent demander une authentification supplémentaire de la part de l'agent qui présente de mandat afin de fournir une trace d'audit.

Tickets transmissibles

   La transmission d'authentification est une instance de mandat dans laquelle le service qui est accordé est l'utilisation complète de l'identité du client. Exemple: Un usager qui s'enregistre sur un système distant et veut l'authentification pour travailler à partir de ce système comme si l'enregistrement était local.

   Le flag FORWARDABLE dans un ticket n'est normalement interprété que par le service d'allocation de tickets. Il peut être ignoré par les serveurs d'application. Le flag FORWARDABLE a une interprétation similaire à PROXIABLE, sauf que les TGT peuvent aussi être produits avec des adresses réseau différentes. Ce flag est ré-initialisé par défaut, mais les utilisateurs peuvent demander qu'il soit établi en mettant l'option FORWARDABLE dans la demande d'AS lorsqu'ils demandent le TGT initial.

   Le flag FORWARDED est mis par le TGS lorsqu'un client présente un ticket avec le flag FORWARDABLE mis et demande un ticket transmis en spécifiant l'option KDC FORWARDED et en fournissant un ensemble d'adresses pour le nouveau ticket. Il est aussi établi dans tous les tickets produits sur la base de tickets ayant le flag FORWARDED mis. Les serveurs d'application peuvent choisir de traiter les tickets FORWARDED différemment.

   Si les tickets sans adresse sont transmis d'un système à un autre, les clients devraient continuer d'utiliser cette option pour obtenir un nouveau TGT afin d'avoir des clés de session différentes sur les différents systèmes.

Vérification des stratégies traversées

   Dans Kerberos, le serveur d'application est responsable en dernier ressort de l'acceptation ou du rejet de l'authentification, et il devrait vérifier que seuls des KDC de confiance sont impliqués dans l'authentification d'un principal. Les champs de transit dans le ticket identifient quels domaines ( et donc quels KDC ) ont été impliqués dans le processus d'authentification, et un serveur d'application devrait normalement vérifier ce champ. Si l'un d'eux n'est pas de confiance pour authentifier le principal de client indiqué (probablement déterminé par une politique fondée sur le domaine), la tentative d'authentification doit être rejetée. La présence de ?DC de confiance dans cette liste ne donne aucune garantie; un KDC compromis peut avoir fabriqué la liste.

   Bien que le serveur d'extrémité décide en dernier ressort si l'authentification est valide, le KDC pour le domaine du serveur l'extrémité peut appliquer une politique spécifique du domaine pour la validation du champ de transit et l'acceptation des accréditifs pour l'authentification de traversée de domaine. Lorsque le KDC applique de telles vérifications et accepte une telle authentification de traversée de domaine, il va établir le flag TRANSITED-POLICY-CHECKED dans les tickets de service qu'il produit sur la base du TGT de traversée de domaine. Un client peut demander que les KDC ne vérifient pars le champ en mettant le flag DISABLE-TRANSITED-CHECK. Les KDC devraient respecter ce flag.

   Les serveurs d'application doivent soit faire eux-mêmes les vérifications de domaine traversé soit rejeter les tickets de traversée de domaine sans que TRANSITED-POLICY-CHECKED sois mis.

OK-as-Delegate

Pour certaines applications, un client peut avoir besoin de déléguer son autorité à un serveur pour agir en son nom en contactant d'autres services. Cela exige que le client transmette les accréditifs à un serveur intermédiaire. La capacité pour un client à obtenir un ticket de service pour un serveur n'apporte pas d'information au client sur la question de savoir si le serveur devrait être considéré comme de confiance pour accepter des accréditifs délégués. Le flag OK-AS-DELEGATE donne à un KDC un moyen pour communiquer une politique de domaine local à un client sur le sujet de savoir si un serveur intermédiaire est de confiance pour accepter de tels accréditifs.

La copie des flags de ticket dans la partie chiffrée de la réponse du KDC peut avoir le flag OK-AS-DELEGATE établi pour indiquer au client que le serveur spécifié dans le ticket a été déterminé par la politique du domaine comme étant un récepteur convenable de délégation. Un client peut utiliser la présence de ce flag pour l'aider à décider de déléguer des accréditifs (en accordant soit un mandat soit un TGT retransmis) à ce serveur. Il est acceptable d'ignorer la valeur de ce flag. Lorsqu'il établit ce flag, un administrateur devrait considérer la sécurité et le placement du serveur sur lequel va fonctionner le service, ainsi que si le service exige l'utilisation d'accréditifs délégués.

Autres options de KDC

Il y a 3 options supplémentaires qui peuvent être établies dans une demandes de KDC du client

Renewable-OK

L'option REMEWABLE-OK indisque que le client acceptera un ticket renouvelable si un ticket avec la durée de vie demandée ne peut pas être autrement fourni. Si un ticket avec la durée de vie demandée ne peut pas être fourni, le KDC peut alors produire un ticket renouvelable avec un renew-till égal à la fin de durée de vie demandée. La valeur du champ renew-till peut encore être ajustée par des limites déterminées par le site ou des limites imposées par le principal ou serveur individuel.

ENC-TKT-IN-SKEY

Dans sa forme de base, le protocole Kerberos prend en charge l'authentification dans un montage client-serveur et ne convient pas bien pour l'authentification dans un environnement d'homologue à homologue parce que la clé à long terme de l'usager ne reste pas sur la station de travail après la connexion initiale. L'authentification de tels homologues peut être prise en charge par Kerberos dans sa variante d'usager à usager. L'option ENC-TKT-IN-SKEY prend en charge l'authentification d'usager à usager en permettant que le KDC produise un ticket de service chiffré en utilisant la clé de session provenant d'un autre TGT produite pour un autre usager. L'option ENC-TKT-IN-SKEY n'est honorée que par le TGT. Elle indique que le ticket à produire pour le serveur est à chiffrer dans la clé de session à partir du second TGT supplémentaire fourni avec la demande.

Authentification hardware sans mot de passe

L'option OPT-HARDWARE-AUTH indique que le client souhaite utiliser une forme d'authentification de matériel à la place de ou en plus du mot de passe du client ou autre clé de chiffrement à longue durée de vie. OPT-HARDWARE-AUTH n'est honoré que par l'AS. S'il est pris en charge et admis par la politique, le KDC va retourner un code d'erreur de KDC_ERR_PREAUTH_REQUIRED et inclure les METHOD-DATA exigées pour effectuer une telle authentification.

Échange de messages

Les paragraphes qui suivent décrivent les interactions entre les clients et serveurs réseau et les messages impliqués dans ces échanges.

Échange service d'authentification

   L'échange de service d'authentification ( AS ) entre le client et le serveur d'authentification Kerberos est initialisé par un client qui souhaite obtenir des accréditifs d'authentification pour un serveur donné mais ne détient pas actuellement d'accréditifs. Dans la forme de base, la clé secrète du client est utilisée pour le chiffrement et le déchiffrement. Cet échange est normalement utilisé à l'initialisation d'une session de connexion pour obtenir des accréditifs pour un serveur d'allocation de tickets ( TGS ). qui seront utilisés ultérieurement pour obtenir des accréditifs pour d'autres serveurs sans avoir besoin d'utiliser la clé secrète du client. Cet échange est aussi utilisé pour demander des accréditifs pour des services qui ne doivent pas passer par le TGS ( le service de changement de mot de passe refuse les demandes si le demanteur ne peut pas démontrer qu'il a connaissance du vieux mot de passe ).

   Cet échange ne fournit par lui-même aucune assurance de l'identité de l'usager. Pour authentifier un usager qui s'inscrit sur un système local, les accréditifs obtenus dans l'échange d'AS peuvent d'abord être utilisés dans un échange TGS pour obtenir des accréditifs pour un serveur local; ces accréditifs doivent ensuite être vérifiés par un serveur local à travers l'achèvement réussi de l'échange client/serveur.

   L'échange AS consiste en 2 messages: KRB_AS_REQ et KRB_AS_REP ou KRB_ERROR.

   Dans la demande, le client envoie (en clair) sa propre identité et l'identité du serveur pour lequel il demande les accréditifs, d'autres informations sur les accréditifs qu'il demande, et un nom temporaire généré de façon aléatoire qui peut être utilisé pour détecter des répétitions et pour associer les réponses aux demandes correspondantes. Ce nom temporaire doit être généré de façon aléatoire par le client et mémorisé pour vérification par rapport au nom aléatoire dans la réponse attendue. La réponse, KRB_AS_REP, contient un ticket que le client présentera au serveur, et une clé de session qui sera partagée par le client et le serveur. La clé de session et les informations supplémentaire sont chiffrées avec la clé secrète du client. La partie ciffrée du message KRB_AS_REP contient aussi le nom temporaire qui doit correspondre au nom temporaire provenant du message KRB_AS_REQ.

   Sans pré-authentification, l'AS ne sait pas si le client est réellement le principal nommé dans la demande. Il envoie simplement une réponse sans savoir s'il sont les mêmes et sans s'en soucier. Ceci est acceptable puisque personne sauf le principal dont l'identité a été donnée dans la demande se sera capable d'utiliser la réponse. Ses information critiques sont chiffrées avec la clé du principal. Cependant, un attaquant peut envoyer un message KRB_AS_REQ pour obtenir du texte en clair connu afin d'attaquer la clé du principal. Et particulièrement si la clé se fonde sur un mot de passe, cela peut créer un danger pour la sécurité. Ainsi, la demande initiale prend en charge un champ facultatif qui peut être utilisé pour passer des informations supplémentaires nécessaire pour l'échange initial. Ce champ devrait être utilisé pour la pré-authentification.

   Diverses erreurs peuvent survenir; elles sont indiquées par une réponse d'erreur KRB_ERROR à la place de la réponse KRB_AS_REP. Le message d'erreur n'est pas chiffré. Ce message contient des informations qui peuvent être utilisées pour l'associer au message auquel il répond. Le contenu du message KRB_ERROR n'est pas protégé en intégrité, donc le client ne peut pas détecter les répétitions, contrefaçons, ou modifications. Une solution à ce problème sera donnée dans une prochaine version du protocole.

Génération du message KRB_AS_REQ

Le client peut spécifier un certain nombre d'options dans la demande initiale. Parmi ces options figure la question de savoir si la pré-authentification est à effectuer; si le ticket demandé est renouvelable, mandatable, ou transmissible; s'il devrait être postdaté ou permettre de postdatage de tickets déduits; et si un ticket renouvelable sera accepté à la place d'un ticket non renouvelable si la date d'expiration du ticket demandé ne peut pas être satisfaite par un ticket non renouvelable.

Réception du message KRB_AS_REQ

Si tout va bien, le traitement du message KRB_AS_REP résultera en la création d'un ticket que le client présentera au serveur.

Parce que Kerberos peut fonctionner sur des transports non fiables comme UDP, le KDC doit être prêt à retransmettre des réponses dans le cas où elles sont perdues. Si un KDC reçoit une demande identique à l'une de celles qu'il a récemment traitées avec succès, le KDC doit répondre par un message KRB_AS_REP plutôt qu'une erreur de répétition. Afin de réduire la quantité de texte chiffré à disposition d'un attaquant potentiel, les KDC peuvent envoyer la même réponse que générée lors du premier traitement de la demande. Les KDC doivent obéir à ce comportement de répétition même si le transport réel utilisé est fiable.

Génération du message KRB_AS_REP

   Le serveur d'authentification cherche dans sa base de données les principaux de client et de serveur nommés dans le message KRB_AS_REQ, et en extrait les clés respectives. Si le principal client demandé nommé dans la demande est inconnu parce qu'il n'existe pas dans la base de données de principaux du KDC, un message d'erreur est retourné avec un KDC_ERR_C_PRINCIPAL_UNKNOWN.

   S'il lui est demandé de faire ainsi, le serveur pré-authentifie la demande, et si la vérification de pré-authentification échoue, un message d'erreur avec le code KDC_ERR_PREAUTH_FAILES. Si la pré-authentification est exigée, mais n'était pas présente dans la demande, un message d'erreur avec le code KDC_ERR_PREAUTH_REQUIRED est retourné, et un objet METHOD-DATA sera mémorisé dans le champ e-data du message KRB-ERROR pour spécifier quels mécanismes de pré-authentification sont acceptables. Cela inclure habituellement les éléments PA-ETYPE-INFO et/ou PA-ETYPE-INFO2. Si le serveur ne peut pas s'accommoder d'un des types de chiffrement demandé par le client, un message d'erreur avec le code KDC_ERR_ETYPE_NOSUPP est retourné.

   Autrement, le KDC génère une clé de session "aléatoire", ce qui signifie, entre autres choses, qu'il devrait être impossible de deviner la prochaine clé de session sur la base de la connaissance des clés de session passées. Bien que cela puisse être réalisé avec un générateur de nombres pseudo-aléatoires s'il se fonde sur les principes cryptographiques, il est plus souhaitable d'utiliser un générateur de nombres vraiment aléatoires, comme un de ceux fondés sur la mesure de phénomènes physiques aléatoires.

   En réponse à une demande d'AS, s'il y a plusieurs clés de chiffrement inscrites pour un client dans la base de données Kerberos, le champ etype de la demande d'AS est utilisé par le KDC pour choisir la méthode de chiffrement à utiliser pour protéger la partie chiffrée du message KRB_AS_REP qui est envoyé au client. S'il y a plus d'un type de chiffrement fort dans la liste etype, le KDC devrait utiliser le premier etype fort valide pour lequel une clé de chiffrement est disponible.

   Lorsque la clé de l'utilisateur est générée à partir d'un mot de passe ou d'une passphrase, la fonction string-to-key pour le type de clé de chiffrement particulier est utilisé, comme spécifié dans la rfc 3961. La valeur de salt et les paramètres supplémentaires pour la fonction string-to-key ont des valeurs par défaut qui peuvent être remplacés par les données de pré-authentification (n (PA-PW-SALT, PA-AFS3-SALT, PA-ETYPE-INFO, PA-ETYPE-INFO2, etc.). Comme le KDC est supposé mémoriser une copie seulement de la clé résultant, ces valeurs ne devraient pas être changées pour des clés fondées dus des mots de passe excepté lorsqu'on change la clé du principal.

   Lorsque le serveur d'AS va inclure les données de pré-authentification dans un KDC-ERROR ou dans un AS-REP, il doit utiliser PA-ETYPE-INFO2 et non PA-ETYPE-INFO, si le champ etype de la AS-REQ du client comporte au moins un type de chiffrement "plus récent". Autrement (lorsque le champ etype de l'AS-REQ ne comporte aucun type de chiffrement plus récent), il doit envoyer les deux PA-ETYPE-INFO2 et PA-ETYPE-INFO (tous 2 avec une entrée pour chaque enctype). Un enctype "plus récent" est tout enctype spécifié officiellement en premier concurrement ou ultérieurement à la publication de la présent rfc. Les enctypes DES, 3DES, ou RC4 et tous ceux définis dans la RFC1510 ne sont pas des enctypes "plus récents"

   Il n'est pas possible de générer une clé utilisateur de façon fiable selon une passphrase donnée sans contacter le KDC, car on ne pourra pas savoir si des valeurs de salt ou de paramètres de remplacement sont nécessaires.

   Le kDC va essayer d'allouer le type de la clé de session aléatoire d'après la liste des méthodes dans le champ etype. Le KDC va sélectionner le type approprié en utilisant la liste des méthodes fournie et les informations tirées de la base de données Kerberos qui indique les méthodes de chiffrement acceptables pour le serveur d'application. Le KDC ne produira pas de tickets avec un type faible de chiffrement de clé de session.

   Si l'heure de début demandée est absente, indique une heure passée, ou est dans une fenêtre acceptable pour le KDC et si l'option POSTDATE n'a pas été spécifié, l'heure de début du ticket est réglée à l'heure en cours du serveur d'authentification. S'il indique une heure future au delà de la fenêtre acceptable, mais si l'option POSTDATED n'a pas été spécifiée, l'erreur KDC_ERR_CANNOT_PORTDATE est retournée. Autrement, l'heure de début demandée est vérifiée par rapport à la politique du domaine local, et si l'heure de début du ticket est acceptable, il est réglé comme demandé, et le flag INVALID est mis dans le nouveau ticket.

   L'heure d'expiration du ticket sera réglée au plus tôt de l'heure de fin demandée et de l'heure déterminée par la politique locale, éventuellement en utilisant des facteurs spécifiques du domaine ou du principal. Par exemple, l'heure d'expiration peut être réglée au plus tôt de ce qui suit:

- L'heure d'expiration demandée dans le message KRB_AS_REQs
- L'heure de début du ticket plus la durée de vie maximum admissible associée au principal d'après la base de données du serveur d'authentification.
- L'heure de début du ticket plus la durée de vie maximum admissible associée au principal
- L'heure de début du ticket plus la durée de vie maximum réglée par la stratégie du domaine local

   Si l'heure d'expiration demandée moins l'heure de début est inférieur à la durée de vie minimum déterminée par un site, un message d'erreur avec le code KDC_ERR_NEVER_VALID est retourné. Si l'heure d'expiration demandée pour le ticket excède ce qui a été déterminé ci-dessus, et si l'option RENEWABLE-OK était demandé, le flag RENEWABLE est alors mis dans le nouveau ticket, et le champ renew-till peut être réglé au plus tôt de:

- Sa valeur demandée
- L'heure de début du ticket plus le minimum des deux durées de vie maximum associées aux entrées de base de données des principaux
- L'heure de début plus la durée de vie renouvelable maximum réglée par la politique du domaine local

   Le champ des flags du nouveau ticket aura les options suivantes établies s'ils ont été demandés et si la politique du domaine local le permet: FORWARDABLE, MAY-POSTDATE, POSTDATED, PROXIABLE, RENEWABLE.. Si le nouveau ticket est postdaté, son flag INVALID est également mis.

   Si tout ce qui précède réussit, le serveur va chiffrer la partie de ciphertext du ticket en utilisant la clé de chiffrement extraite de l'enregistrement du principal du serveur dans la base de données Kerberos en utilisant le type de chiffrement associé à la clé du principal du serveur (ce choix n'est pas affecté par le etype dans la requête). Il forge alors un message KDC_AS_REP, en copiant les adresses de la demande dans le caddr de la réponse, en plaçant toutes les données de pré-authentification demandées dans le padata de la réponse, et en chiffrant la partie ciphertext dans la clé du client en utilisant une méthode de chiffrement acceptable demandée dans le champ etype de la demande, ou dans une clé spécifiée par le mécanisme de pré-authentification utilisé.

Génération du message KDC_ERROR

Plusieurs erreurs peuvent survenir, et le serveur d'authentification répond en envoyant un message d'erreur, KDC_ERROR, au client, avec les champs code d'erreur et e-text réglés aux valeurs appropriées.

Réception du message KRB_AS_REP

   Si le type du message de réponse est KDC_AS_REP, le client vérifie alors que les champs cname et crealm de la portion de texte en clair de la réponse correspondent à ce qui était demandé. Si un champ padata est présent, il peut être utilisé pour déduire la clé secrète appropriée pour déchiffrer le message. Le client déchiffre la partie chiffrée de la réponse en utilisant sa clé secrète et vérifie que le nom temporaire dans la partie chiffrée correspond au nom occasionnel qu'il a fourni dans sa demande (pour détecter des répétitions). Il vérifie aussi que sname et srealm de la réponse correspondent à ceux de la demande (ou des valeurs attendues), et que le champ d'adresse d'hôte est correcte. Il mémorise alors le ticket, la clé de sessions, les heures de début et d'expiration, et les autres informations pour un usage ultérieur. Le champ last-req (et le champ déconseillé key-expiration) tirés de la partie chiffrée de la réponse peuvent être vérifiés pour notifier à l'utilisateur une expiration de clé imminente. Ceci permet au programme client de suggérer un remède, comme un changement de mot de passe.

   À la validation du message KRB_AS_REP (en comparant le nom temporaire avec celui envoyé), le client sait que l'heure courante du KDC est celle lue dans le champ authtime de la partie chiffrée de la réponse. Le client peut optionnellement utiliser cette valeur pour synchroniser l'horloge dans les messages suivant en enregistrant avec le ticket la différence entre la valeur de authtime et l'horloge locale. Cet offset peut ainsi être utilisé par le même utilisateur pour ajuster le temps lu de l'horloge système lors de la génération des messages.

   Cette technique doit être utilisée en ajustant le biais d'horloge au lieu de changer directement l'horloge système, parce que la réponse du KDC n'est authentifiée qu'auprès de l'utilisateur dans la clé secrète a été utilisée, mais pas auprès du système ou de la workstation.

   Le déchiffrement correcte du message KRB_AS_REP n'est pas suffisant à l'hôte peut vérifier l'identité de l'utilisateur qui se connecte sur la workstation. L'utilisateur et un attaquant pourraient coopérer pour générer un message de format KRB_AS_REP qui se déchiffre correctement mais ne serait pas du KDC approprié. Si l'hôte souhaite vérifier l'identité de l'utilisateur, il doit exiger que l'utilisateur présente des accréditifs d'application qui puissent être vérifiés en utilisant une clé secrète que l'hôte aura mémorisé en toute sécurité. Si ces accréditifs peuvent être vérifiés, l'identité de l'usager peut alors être assurée.

Réception du message KRB_ERROR

Si le type de message de réponse est KRB_ERROR, le client l'interprète alors comme une erreur et effectue toute tâche spécifique de l'application qui est nécessaire pour récupérer.

Échange d'authentification client/serveur

L'échange d'authentification client/serveur (CS) est utilisé par les applications réseau pour authentifier le client auprès du serveur et vice versa. Le client doit déjà avoir acquis des accréditifs pour le serveur en utilisant l'échange AS ou TGS.

Message KRB_AP_REQ

KRB_AP_REQ contient des informations d'authentification qui devraient faire partie du premier message dans une transaction authentifiée. Il contient un ticket, un authentifiant, et quelques informations de comptabilité supplémentaire. Le ticket est insuffisant par lui-même pour authentifier un client, car les tickets passent à travers le réseau. L'authentifiant est utilisé pour empêcher la répétition invalide de tickets en prouvant au serveur que le client connaît la clé de session du ticket et est donc fondé à utiliser le ticket. Le message KRB_AP_REQ est par ailleurs appelé un "en-tête d'authentification".

Génération d'un message KRB_AP_REQ

Lorsqu'un client souhaite initier l'authentification auprès d'un serveur, il obtient (soit avec un cache d'arréditifs, l'échange d'AS, ou l'échange TGS) un ticket et une clé de session pour le service désiré. Le client peut réutiliser tous les tickets qu'il détient jusqu'à leur expiration. Pour utiliser un ticket, le client construit un nouvel authentifiant à partir de l'heure du système et de son nom, et facultativement à partir d'une somme de contrôle spécifique de l'application, un numéro de séquence initial à utiliser dans les messages KRB_SAFE ou KRB_PRIV, et/ou une sous-clé de session à utiliser dans les négociations pour une clé de session unique pour cette session particulière. Les authentifiants ne doivent pas être réutilisés et devraient être rejetés s'ils sont répétés sur un serveur. Noter que cela peut rendre les applications fondées sur des transports non fiables difficiles à coder correctement. Si le transport peut délivrer des messages dupliqués, un nouvel authentifiant doit être généré pour chaque essai, ou le serveur d'application doit faire correspondre demandes et réponses et répéter la première répétition en réponse à un duplicata détecté.

Si un numéro de séquence doit être inclus, il devrait être choisi de façon aléatoire de sorte que même après l'échange de nombreux messages il n'y ait aucune probabilité de collision avec un autre numéro de séquence utilisé. Le client peut indiquer une exigence d'authentification mutuelle ou l'utilisation d'un ticket fondé sur une clé de session en mettant le ou les flags appropriés dans le champ ap-options du message. L'authentifiant est chiffré dans la clé de session et combiné avec le ticket pour former le message KRB_AP_REQ, qui est alors envoyé au serveur d'extrémité avec toutes information supplémentaires spécifiques de l'application.

Réception du message KRB_AP_REQ

   L'authentification se fonde sur l'heure courante du serveur, sur l'authentifiant, et sur le ticket. Plusieurs erreurs sont possibles. Si une erreur survient, on attend du serveur qu'il réponde un message KRB_ERROR au client. Ce message peut être encapsulé dans le protocole d'application si sa forme brute n'est pas acceptable pour le protocole.

   L'algorithme de vérification des informations d'authentification est le suivant. Si le type de message n'est pas KRB_AP_REQ, le serveur retourne l'erreur KRB_AP_ERR_MSG_TYPE. Si la version de clé est indiquée par le ticket dans KRB_AP_REQ n'est pas une de celles que le serveur peut utiliser (par exemple, elle indique une vieille clé, et le serveur ne possède plus de copie de la vieille clé), l'erreur KRB_AP_ERR_BADKEYVER est retournée. Si le flag USE-SESSION-KEY est mis dans le champ ap-options, il indique au serveur l'utilisation de l'authentification d'utilisateur à utilisateur. et le chiffrement du ticket avec la clé de session provenant du TGT du serveur plutôt qu'avec la clé secrète du serveur.

   Le champ srealm dans la portion non chiffrée du ticket dans KRB_AP_REQ est utilisé pour spécifier quelle clé secrète devrait utiliser le serveur pour déchiffrer le ticket, parce qu'il est possible au serveur d'être enregistré dans plusieurs domaines, avec des clés différentes dans chacun. Le code d'erreur KRB_AP_ERR_NOKEY est retourné si le serveur n'a pas la clé appropriée pour déchiffrer le ticket.

   Le ticket est déchiffré en utilisant la version de la clé du serveur spécifiée par le ticket. Si la routine de déchiffrement détecte une modification du ticket (chaque système de chiffrement doit fournir des sauvegardes pour détecter le texte chiffré modifié), l'erreur KRB_AP_ERR_BAD_INTEGRITY est retournée (il y a de bonnes chances que différentes clés aient été utilisées pour chiffrer et pour déchiffrer).

   L'authentifiant est déchiffré en utilisant la clé de session extraite du ticket déchiffré. Si le déchiffrement montre qu'il a été modifié, l'erreur KRB_AP_ERR_BAD_INTEGRITY est retournée. Le nom et le domaine du client tirés du ticket sont comparés aux champs correspondants dans l'authentifiant. S'ils ne correspondent pas, l'erreur KRB_AP_ERR_BADMATCH est retournée; ceci est normalement causé par une erreur client ou une tentative d'attaque. Les adresses dans le ticket sont alors examinées à la recherche d'une adresse correspondant à l'adresse mentionnée par le système d'exploitation du client. Si aucune correspondance n'est trouvée, ou si le serveur insiste sur les adresses du ticket mais qu'aucune n'est présente dans le ticket, l'erreur KRB_AP_ERR_BADADDR est retournée. Si l'heure locale du serveur et l'heure du client dans l'authentifiant diffèrent au delà de l'admissible, l'erreur KRB_AP_ERR_SKEW est retournée.

   À moins que le serveur d'application ne fournisse ses propres moyens pour se protéger contre la répétition (par exemple, une séquence challenge-réponse initiée par le serveur après l'authentification, ou l'utilisation d'une sous-clé de chiffrement générée par le serveur), le serveur doit utiliser un cache pour mémoriser tout authentifiant présenté dans la plage de temps admissible. Une analyse soigneuse du protocole et de la mise en œuvre de l'application est recommandée avant d'éliminer ce cache. Le cache mémorise au moins les champ de nom du serveur, de nom du client, et d'heures tirés des authentifiants vus le plus récemment, et si une correspondance est trouvée, l'erreur KRB_AP_ERR_REPEAT est retournée. Noter qu'ici, le rejet est restreint aux authentifiants provenant du même principal vers le même serveur. Les autres principaux de clients qui communiquent avec le même principal du serveur ne devraient pas voir leurs authentifiants rejetés si les champ heure et microseconde se trouvent correspondre à d'autres authentifiants du client.

   Si un serveur perd la trace des authentifiants présentés pendant l'horaire admissible, il doit rejeter toutes les demandes jusqu'à la fin de la plage de temps, lui donnant l'assurance que tout authentifiant perdu ou répété se retrouvera hors plage.

   Note de mise en œuvre: Si un client génère plusieurs demandes au KDC avec le même horodatage, y compris le champ timestamp, toutes les demandes reçues sauf la première seront rejetées comme répétitions. Cela peut arriver, par exemple, si la résolution de l'horloge du client est trop grossière. Les mises en œuvre client devraient s'assurer que les horodatages ne sont pas réutilisés, éventuellement en incrémentant le champ timestamp dans l'horodatage lorsque l'horloge retourne la même heure pour plusieurs demandes.

   Si plusieurs serveur ( par exemple, différents services sur une machine, ou un seul service mis en œuvre sur plusieurs machines ) partagent un principal de service ( pratique non recommandée en général ), ils doivent partager ce cache, ou bien le protocole d'application doit être conçu de façon à en éliminer le besoin. Noter que ceci s'applique à tous les services. Si un protocole d'application n'a pas de protection contre la répétition, un authentifiant utilisé avec un tel service pourrait être répété ultérieurement dans un service différent avec le même principal de service mais sans protection contre la répétition.

   Si un numéro de séquence est fourni dans l'authentifiant, le serveur le sauvegarde pour utilisation ultérieure en traitant les messages KRB_SAFE et/ou KRB_PRIV. Si une sous-clé est présente, le serveur la sauvegarde pour plus tard ou l'utilise pour aider à générer son propre choix d'une sous-clé à retourner dans un message KRB_AP_REP.

   Le serveur calcule l'âge du ticket: heure locale du serveur moins l'heure de début dans le ticket. Si l'heure de début est plus tardive que l'heure en cours de plus que la plage horaire admissible, ou si le flag INVALID est mis, l'erreur KRB_AP_ERR_TKT_NYV est retournée. Autrement, si l'heure en cours est plus tardive que l'heure de fin de plus que la plage admissible, l'erreur KRB_AP_ERR_TKT_EXPIRED est retournée.

   Si toutes ces vérification ont réussi sans erreur, le serveur est assuré que le client possède les accréditifs du principal nommé dans le ticket, et donc, que le client a été authentifié auprès du serveur.

   Réussir ces vérifications ne fournit que l'authentification du principal désigné; cela n'implique pas l'autorisation d'utiliser le service désigné. Les applications doivent gérer l'autorisation sur la base du nom authentifié de l'utilisateur. de l'opération demandée, des informations de commande d'accès locales telles que celles contenues dans un fichier .k5login ou .k5users, et éventuellement d'un service d'autorisation distribué distinct.

Génération d'un message KRB_AP_REP

Normalement, la demande l'un client va inclure à la fois les informations d'authentification et sa demande initiale dans le même message, et le serveur n'a pas besoin de répondre explicitement au KRB_AP_REQ. Cependant, si l'authentification mutuelle (authentifiant non seulement le client auprès du serveur, mais aussi le serveur auprès du client) est effectuée, le message KRB_AP_REQ aura MUTUAL-REQUIRED établi dans son champ ap-options, et un message KRB_AP_REP est exigé en réponse. Comme avec le message d'erreur, ce message peut être encapsulé dans le protocole d'application si sa forme "brute" n'est pas acceptable pour le protocole d'application. Les champs horodatage et microseconde utilisés dans la réponse doivent être les champs horodatage et microseconde du client (tels que fournis par l'authentifiant). Si un numéro de séquence doit être inclus, il devrait être choisi de façon aléatoire comme décrit ci-dessus pour l'authentifiant. Une sous-clé peut être incluse si le serveur désire négocier une sous-clé différente. Le message KRB_AP_REP est chiffré dans la clé de session extraite du ticket.

Réception du message KRB_AP_REP

Si un message KRB_AP_REP est retourné, le client utilise la clé de session provenant des accréditifs obtenus pour que le serveur déchiffre le message et vérifie que les champs horodatage et microseconde correspondent à ceux de l'authentifiant qu'il a envoyé au serveur. S'ils correspondent, le client est alors assuré que le serveur est authentique. Le numéro de séquence est la sous-clé ( si présente ) sont conservés pour utilisation ultérieure ( noter que pour chiffrer le message KRB_AP_REP, la sous-clé de session n'est pas utilisée, même si elle est présent dans l'authentification ).

Utilisation de la clé de chiffrement

   Après que l'échange KRB_AP_REQ/KRB_AP_REP est terminé, le client et le serveur partagent une clé de chiffrement qui peut être utilisée par l'application. Dans certains cas, l'utilisation de cette clé de session sera implicite dans le protocole; dans d'autres, la méthode d'utilisation doit être choisie entre plusieurs possibilités. L'application peut choisir la clé de chiffrement réelle à utiliser pour KRB_PRIV, KRB_SAFE, ou d'autres utilisation spécifiques de l'application fondées sur la clé de session à partir du ticket et des sous-clés dans le message KRB_AP_REP et l'authentifiant. Les mises en œuvre du protocole peuvent fournir des routines pour choisir les sous-clés sur la base des clés de session et de nombres aléatoires et générer une clé négociée à retourner dans le message KRB_AP_REP.

   Pour atténuer l'effet des défaillances de la génération de nombres aléatoire chez le client, il est vivement recommandé que toute clé déduite par une application pour utilisation ultérieure incluent la pleine entropie de clé déduite de la clé de session générée par le KDC portée dans le ticket. On laisse les négociations de protocole sur la façon d'utiliser la clé (par exemple, pour choisir un type de chiffrement ou de somme de contrôle) au programmeur de l'application. Le protocole Kerberos n'impose pas de contrainte sur les options de mise en œuvre, mais un exemple de la façon dont cela peut être fait figure ci-après.

   Une façon qu'une application peut choisir pour négocier une clé à utiliser pour la protection ultérieure d'intégrité et de confidentialité est que le client propose une clé dans le champ sous-clé à l'authentifiant. Le serveur peut alors choisir une clé en utilisant la clé proposée par le client en entrée, retournant la nouvelle sous-clé dans le champ sous-clé de la réponse de l'application. Cette clé eut alors être utilisée pour la suite de la communication.

   Avec les échanges d'authentification aussi bien unilatérale que mutuelle, les homologues devraient veiller à ne pas s'envoyer l'un l'autre d'informations sensibles sans garanties appropriées. En particulier, les applications qui exigent la confidentialité ou l'intégrité devraient utiliser la réponse KRB_AP_REP du serveur au client pour que le client et le serveur s'assurent tous deux de l'identité de leur homologue. Si un protocole d'application exige la confidentialité de ses messages, il peut utiliser le message KRB_PRIV. Le message KRB_SAFE peut être utilisé pour s'assurer de l'intégrité.

Échange TGS

L'échange TGS entre un client et le TGS est initié par un client lorsqu'il cherche à obtenir des accréditifs d'authentification pour un serveur donné (qui peut être enregistré dans un domaine distant), lorsqu'il cherche à renouveler ou valider un ticket existant, ou lorsqu'il cherche à obtenir un ticket mandataire. Dans le premier cas, le client doit déjà avoir acquis un ticket pour le TGS auprès de l'AS ( Le TGT est généralement obtenu quand un client quand un client s'authentifie sur le système ). Le format pour l'échange TGS est presque identique à l'échange AS. La différence principale est que le chiffrement et le déchiffrement dans l'échange TGS n'est pas effectuée dans le clé du client. À la place, le clé de session du TGT ou du ticket renouvelable, ou de la clé de sous-session d'un authentifiant est utilisé. Comme c'est le cas pour tous les serveur d'application, les tickets expirés ne sont pas acceptés par le TGS, donc une fois une TGT ou un renouvelable expiré, le client doit utiliser un échange séparé pour obtenir des tickets valides.

L'échange TGS consiste de 2 messages: une requête ( KRB_TGS_REQ ), et une réponse ( KRB_TGS_REP ou KRB_ERROR ). Le message KRB_TGS_REQ inclus les informations authentifiant le client plus une requête pour des accréditifs. Les information d'authentification consistent de l'en-tête d'authentification ( KRB_AP REQ ), qui inclus le ticket TGT, renouvelable ou invalide du client précédemment obtenus. Dans les cas de TGT et de proxy, la requête peut inclure un ou plusieurs éléments: une liste d'adresses réseaux, une collection de données d'autorisation typées, ou des tickets supplémentaires. La réponse TGS ( KRB_TGS_REP ) contient es accréditifs demandés, chiffrés dans la clé de session provenant du TGT ou le ticket renouvelable, ou, si elle est présente, dans la sous-clé de session provenant de l'authentifiant. Le message KRB_ERROR n'est pas chiffré. Le message KRB_TGS_REP contient des informations qui peuvent être utilisées pour détecter les répétitions, et pour l'associer au message auquel il répond.

Génération du message KRB_TGS_REQ

   Avant d'envoyer une demande au TGS, le client doit déterminer dans quel domaine il pense qu'est enregistré le serveur d'application. Cela peut se faire de diverses façons. Il peut être connu à l'avance, peut être mémorisé dans un serveur de noms, ou peut être obtenu d'un fichier de configuration. Si le client connaît le nom et le domaine du principal du service et s'il ne possède pas encore un TGT pour le domaine approprié, il doit alors en obtenir un. Il essaye d'abord en demandant un TGT pour le domaine de destination à un serveur Kerberos pour lequel le client possède un TGT ( en utilisant de façon récurrent le message KRB_TGS_REQ ). Le serveur Kerberos peut retourner un TGT pour le domaine désiré, auquel cas le traitement peut se poursuivre. Autrement, le serveur Kerberos peut retourner un TGT pour un domaine qui est plus proche du domaine désiré. Noter que dans ces cas, la mauvaise configuration du serveur Kerberos peut causer les boucles dans le chemin d'authentification résultant. ce que le client devrait veiller à détecter et éviter.

   Si le serveur Kerberos retourne un TGT pour un domaine plus proche que le domaine désiré, le client peut utiliser la configuration de la politique locale pour vérifier que le chemin d'authentification utilisé est acceptable. Autrement, un client peut choisir son propre chemin d'authentification, plutôt que de s'appuyer sur le serveur Kerberos pour en choisir un. Dans les 2 cas, toute information de politique ou de configuration utilisée pour choisir ou valider des chemins d'authentification, par le serveur Kerberos ou par le client, doit être obtenue d'une source de confiance.

   Lorsqu'un client obtient un TGT qui est plus proche du domaine de destination, il peut mettre en cache ce ticket et le réutiliser dans des échange KRB_TGS futures avec les services dans le domaine plus proche. Cependant, si le client devait obtenir un TGT pour le domaine plus proche en commençant au KDC initial plutôt qu'au titre de l'obtention d'un autre ticket, un chemin plus court vers le domaine plus proche pourrait être utilisé. Ce chemin plus court peut être désirable parce que moins de KDC intermédiaires connaîtraient la clé de session du ticket impliqué. Pour cette raison, les clients devraient évaluer s'ils ont confiance dans les domaines de transit pour obtenir le ticket plus proche lorsqu'ils prennent la décision d'utiliser le ticket à l'avenir.

   Une fois que le client a obtenu un TGT pour le domaine approprié, il détermine quels serveur Kerberos servent ce domaine et contacte l'un d'entre eux. Leur liste peut être obtenue par un fichier de configuration ou un service réseau, ou elle peut être générée à partir du nom du domaine. Tant que les clés secrètes échangées par domaine sont gardées secrètes, seul de DOS résulte de l'utilisation d'un faux serveur Kerberos.

   Comme dans l'échange d'AS, le client peut spécifier un certain nombre d'options dans le message KRB_TGS_REQ. Une de ces options est l'options ENC-TKT-IN-SKEY utilisée pour l'authentification d'utilisateur à utilisateur. Lors de la génération du message KRB_TGS_REQ, cette option indique que le client inclut un TGT obtenu du serveur d'application dans le champ de tickets supplémentaires de la demande et que le KDC devrait chiffrer le ticket pour le serveur d'application en utilisant la clé de session provenant de ce ticket supplémentaire, au lieu d'une clé de serveur provenant de la base de données du principal.

   Le client prépare le message KRB_TGS_REQ, qui fournit un en-tête d'authentification comme élément du champ padata, et incluant les même champs qu'utilisés dans le message KRB_AS_REQ avec plusieurs champs facultatifs: le champ enc-authorization-data pour l'usage du serveur d'application et les tickets supplémentaires requis par certaines options.

   Pour préparer l'en-tête d'authentification, le client peut choisir une sous-clé de session avec laquelle sera chiffrée la réponse du serveur Kerberos. Si le client choisit une sous-clé de session, il faut veiller à s'assurer du caractère aléatoire de la sous-clé de session choisie.

   Si la sous-clé de session n'est pas spécifiée, la clé de session provenant du TGT sera utilisée. Si enc-authorization-data est présent, il doit être chiffré dans la sous-clé de session, si elle est présente, à partir de la portion d'authentifiant de l'en-tête d'authentification, ou, si elle n'est pas présente, en utilisant la clé de session provenant du TGT.

   Une fois préparé, le message est envoyé au serveur Kerberos pour le domaine de destination.

Réception du message KRB_TGS_REQ

   Le message KRB_TGS_REQ est traité de manière similaire au message KRB_AS_REQ mais il y a de nombreuses vérification supplémentaires à effectuer. D'abord, le serveur Kerberos doit déterminer pour quel serveur est le ticket d'accompagnement, et il doit choisir la clé appropriée pour le déchiffrer. Pour un message KRB_TGS_REQ normal, ce sera pour le TGS, et la clé du TGS sera utilisée. Si le TGT a été produit par un autre domaine, les clés inter-domaines appropriées doivent être utilisées. Si (a) le ticket d'accompagnement n'est pas un TGT pour le domaine courant, mais est pour un serveur d'application dans le domaine courant, (b) les options RENEW, VALIDATE ou PROXY sont spécifiées dans la demande, et (c) le serveur pour lequel un ticket est demandé est le serveur désigné dans le ticket d'accompagnement, pus le KDC va déchiffrer le ticket dans l'en-tête d'authentification en utilisant la clé du serveur pour lequel elle a été produite. Si aucun ticket ne peut être trouvé dans le champ padata, l'erreur KDC_ERR_PADATA_TYPE_NOSUPP est retournée.

   Une fois que le ticket d'accompagnement a été déchiffré, la somme de contrôle fournie par l'utilisateur dans l'authentifiant doit être vérifiée par rapport au contenu de la demande, et le message doit être rejeté si les sommes de contrôle ne correspondent pas ( avec un code d'erreur KRB_AP_ERR_MODIFIED ) ou si la somme de contrôle n'est pas à l'épreuve des collisions ( avec un code d'erreur KRB_AP_ERR_INAPP_CKSUM ). Si le type de somme de contrôle n'est pas accepté, l'erreur KDC_ERR_SUMTYPE_NOSUPP est retournées.

   Si un des déchiffrements indique un échec de vérification d'intégrité, l'erreur KRB_AP_ERR_BAD_INTEGRITY est retournée. Le KDC doit envoyer un message KRB_TGS_REP valide s'il reçoit un message KRB_TGS_REQ identique à celui qu'il a traité récemment. Cependant, si l'authentifiant est une répétition, mais que le reste de la demande n'est pas identique, de KDC devrait alors retourner KRB_AP_ERR_REPEAT.

Génération du message KRB_TGS_REP

   Le message KRB_TGS_REP partage son format avec KRP_AS_REP, mais avec son champ de typee réglé à KRB_TGS_REP.

   La réponse va comporter un ticket pour le serveur demandé ou pour un serveur d'allocation de ticket d'un KDC intermédiaire à contacter pour obtenir le ticket demandé. La base de données Kerberos est interrogée pour restituer l'enregistrement pour le serveur approprié ( y compris la clé avec laquelle le ticket sera chiffré ). Si la demande est pour un TGT d'un domaine distant, et s'il n'y a pas de partage de clé avec le domaine demandé, le serveur Kerberos va alors choisir le domaine le plus proche du domaine demandé avec lequel il partage une clé et utiliser ce domaine à la place. C'est le seul cas où la réponse pour le KDC sera pour un serveur différent de celui demandé par le client.

   Par défaut, le champ d'adresse, le nom et le domaine du client, la liste des domaines de transit, l'heure de l'authentification initiale, l'heure d'expiration, et les données d'autorisation du ticket nouvellement produit seront copiées du TGT ou du ticket renouvelable. Si les champs de transit ont besoins d'être mis à jour, mais que le type de transit n'est par accepté, l'erreur KDC_ERR_TRTYPE_NOSUPP est retournée.

   Si la demande spécifie une heure de fin, l'heure de fin du nouveau ticket est réglée au minimum de (a) cette demande, (b) de l'heure de fin provenant du TGT, et (c) de l'heure de début du TGT plus le minimum de la durée de vie maximum pour le serveur 'application et la durée de vie maximum pour le domaine local ( la durée de vie maximum pour le principal demandeur a déjà été appliquée lors de la production du ticket ). Si le nouveau ticket doit être un renouvellement, l'heure de fin ci-dessus est alors remplacée par le minimum de (a) la valeur du champ renew_till du ticket et (b) l'heure de début pour le nouveau ticket plus la durée de vie (heure de fin - heure de début ) du vieux ticket.

   Si l'option FORWARDED a été demandée, le ticket résultant contiendra alors les adresses spécifiées par le client. Cette option ne sera honorée que si le flag FORWARDABLE est mis dans le TGT. L'option PROXY est similaire; le ticket résultant contiendra les adresses spécifiées par le client. Elle ne sera honorée que si le flag PROXIABLE est établi dans le TGT. L'option PROXY ne sera pas honorée sur les demandes de TGT supplémentaires.

   Si l'heure de début demandée est absente, indique une heure passée, ou est dans la plage horaire admissible pour le KDC et si l'option POSTDATE n'est pas spécifiée, l'heure de début du ticket est réglée à l'heure en cours de l'AS. Si elle indique une heure dans le futur au delà de la plage horaire admissible, mais l'option POSTDATE n'est pas spécifiée ou si le flag MAY-POSTDATE n'est pas mis dans le TGT, l'erreur KDC_ERR_CANNOT_POSTDATE est alors retournée. Sinon, si le TGT a le flag MAY-POSTDATE mis, le ticket résultant sera postdaté, et l'heure de début demandée sera vérifiée par rapport à la politique du domaine local. Si elle est acceptable, l'heure de début du ticket sera réglée comme demandé, et le flag INVALID sera mis. Le ticket postdaté doit être validé avant utilisation en le présentant au KDC après l'heure de début a été atteinte. Cependant, en aucun cas l'heure de début, de fin, ou de fin de renew-till d'un ticket postdaté nouvellement produit ne peut être étendue au delà de l'heure de renew-till du TGT.

   Si l'option ENC-TGT-IN-SKEY a été spécifiée et si un ticket supplémentaire a été inclus dans la demande, il indique que le client utilise l'authentification d'utilisateur à utilisateur pour prouver son identité à un serveur qui n'a pas d'accès à une clé persistante. Lors de la génération du message KRB_TGS_REP, cette option dans le message KRB_TGS_REQ dit au KDC de déchiffrer le ticket supplémentaire en utilisant la clé pour le serveur auquel le ticket supplémentaire a été produit et de vérifier qu'il est un TGT. Si le nom du serveur demandé manque dans la demande, le nom du client dans le ticket supplémentaire sera utilisé. Autrement, le nom du serveur demandé sera comparé au nom du client dans le ticket supplémentaire. Si c'est différent, la demande sera rejetée. Si la demande réussit, la clé de session provenant du ticket supplémentaire sera utilisée pour chiffrer le nouveau ticket produit au lieu d'utiliser la clé du serveur pour lequel le nouveau ticket sera utilisé.

   si (a) le nom du serveur dans le ticket qui est présenté au KDC au titre de l'en-tête d'authentification n'est pas celui du TGS lui-même, (b) le serveur est enregistré dans le domaine de ce KDC, et (c) l'option RENEW est demandé, donc le KDC va vérifier que le flag RENEWABLE est mis dans le ticket, que le flag INVALID n'est pas mis, et que le temp renew-till est dans le future. Si l'option VALIDATE est requis, le KDC va vérifier que le starttime a passé et que le flag INVALID est mis. Si l'option PROXY est demandé, le KDC va vérifier que le flag PROXIABLE est mis dans le ticket. Si le test réussis et que le ticket passe toutes les vérifications décris dans la prochaine section, le KDC va fournir le nouveau ticket approprié.

   La parie ciphertext de la réponse dans le message KRB_TGS_REP est chiffrée dans la clé de sous-session de l'authentifiant, si présent, ou dans la clé de session du TGT. Elle n'est pas chiffré en utilisant la clé secrète du client. De plus, les champs de date d'expiration de la clé du client et de numéro de version de clé sont laissés de côté car ces valeurs sont stockées avec les enregistrements de la base de données du client, et il n'y a pas besoin de cet enregistrement pour satisfaire une demande sur la base d'un TGT.

Recherche de tickets révoqués

Chaque fois qu'une demande est faite au TGS, le ou les tickets présentés sont confrontés à une liste rouge de tickets annulés. Celle liste peut être mise en œuvre en mémorisant une gamme d'horodatages de production de tickets suspects; si un ticket présenté a un authtime dans cette gamme, il sera rejeté. De cette façon, un TGT volé ou un ticket renouvelable ne peut pas être utilisé pour obtenir des tickets supplémentaires une fois que le vol a été rapporté au KDC pour le domaine dans lequel réside le serveur. Tout ticket normal obtenu avant qu'il ait été rapporté volé sera toujours valide ( parce que les tickets n'exigent pas l'interaction avec le KDC ), mais seulement jusqu'à son heure d'expiration normale. Si les TGT ont été produites pour une authentification inter-domaine, l'utilisation du TGT inter-domaine se sera pas affectée sauf si la liste rouge est transmise aux KDC pour les domaines pour lesquels de tels tickets inter-domaine avaient été produits.

Codage du champ de transit

   Si l'identité du serveur dans le TGT qui est présenté au KDC au titre de l'en-tête d'authentification est celle du service d'allocation de tickets, mais si le TGT a été produit à partir d'un autre domaine, le KDC va chercher la clé inter-domaines partagée avec ce domaine et utiliser cette clé pour déchiffrer le ticket. Se le ticket est valide, le KDC va alors honorer la demande, sous réserve des contraintes soulignées ci-dessus au paragraphe qui décrit l'échange d'AS. La partie domaine de l'identité du client sera tirée du TGT. Le nom de domaine qu'a produit le TGT, si ce n'est par le domaine du principal client, sera ajouté au champ de transit du ticket à produire. Ceci est accomplis en lisant le champ de transit d'après de TGT ( qui est traité comme un ensemble non ordonné de noms de domaines ), en ajoutant le nouveau domaine à l'ensemble, et en construisant et écrivant sa forme ( abrégée ) codée (ce qui peut impliquer un réarrangement du codage existant ).

   Noter que le service d'allocation de tickets n'ajoute pas le nom de son propre domaine. Au lieu de cela, sa responsabilité est d'ajouter le nom du domaine précédent. Cela empêche un serveur Kerberos malveillant d'inscrire intentionnellement son propre nom ( il pourrais cependant omettre les noms d'autres domaines ).

   Ni les noms du domaine local ni ceux du domaine du principal ne sont à inclure dans le champ de transit. Ils apparaissent ailleurs dans le ticket et tous deux sont connus pour prendre part à l'authentification du principal. Parce que les points d'extrémité ne sont pas inclus, aussi bien l'authentification inter-domaine local que celle à un seul bond résulte en un champ de transit qui est vide.

   Comme à ce champ est ajouté le nom de chaque domaine de transit, il peut éventuellement être très long. Pour diminuer la longueur de ce champ, son contenu est codé. Les codages initialement acceptés sont optimisés sur le cas normal de communication inter-domaine: un arrangement hiérarchique de domaines utilisant les noms de domaine de style domaine ou X.500. Ce codage ( appelé DOMAIN-X500-COMPRESS ) est décris ci-dessous.

   Les noms de domaine dans le champ de transit sont séparés par une ",", les caractères ",", "\", les "." de fin, et les espaces d'en-tête sont des caractères spéciaux, et s'ils font partie d'un nom de domaine, ils doivent être entre guillemets dans le champ de transit en les faisant précéder d'un "\"

   Un nom de domaine se terminant par un "." est interprété comme étant ajouté au domaine précédent. Par exemple, ou peut coder la traversée de EDU, MIT.EDU, ATHENA.MIT.EDU, , WASHINGTON.EDU, et CS.WASHINGTON.EDU par:

  "EDU,MIT.,ATHENA.,WASHINGTON.EDU,CS."

  Noter que si ATHENA.MIT.EDU, ou CS.WASHINGTON.EDU étaient des points d'extrémité, ils ne seraient pas inclus dans ce champ, et on aurait:

  "EDU,MIT.,WASHINGTON.EDU"

   Un nom de domaine commençant par un "/" est interprété comme ayant été ajouté au domaine précédent. Pour les besoins de l'ajout, le domaine précédant le premier domaine de la liste est considéré comme le domaine nul (""). Si un nom de domaine commençant par un "/" doit être autonome, il devrait alors être précédé d'un espace (" "). Par exemple, on pour coder la traversée de /COM/HP/APOLLO,/COM/HP,/COM, et /COM/DEC par:

  "/COM,/HP,/APOLLO, /COM/DEC"

  Comme dans l'exemple ci-dessus, si /COM/HP/APOLLO et /COM/DEC étaient des points d'extrémité, ils ne seraient pas inclus dans ce champ:

  "/COM,/HP"

   Un sous-champ nul précédant ou suivant une "," indique que tous les domaines entre le domaine précédent et le prochain domaine ont été traversés. Pour les besoins de l'interprétation des sous-champs nuls, le domaine du client est considéré comme précédant ceux du champ de transit, et le domaine du serveur est considéré les suivre. Et donc, "," signifie que tous les domaines le long du chemin entre le client et le serveur ont été traversées. ",EDU, /COM," signifie que tous les domaines depuis le domaine du client jusqu'à EDU ( dans une hiérarchie de type domaine ) ont été traversés, et que tous depuis /COM jusqu'au domaine du serveur dans un style X.500 ont aussi été traversés. Cela pourrait survenir si le domaine EDU dans une hiérarchie partage une clé inter-domaine directement avec le domaine /COM dans une autre hiérarchie.

Réception du message KRB_TGS_REP

Lorsque le message KRB_TGS_REP est reçu par le client, il est traité de la même manière que le traitement KRB_AS_REP décrit ci-dessus. La principale différence est que la partie chiffrée de la réponse doit être déchiffrée en utilisant la sous-clé de session provenant de l'authentifiant, s'il a été spécifié dans la demande, ou la clé de session provenant du TGT, plutôt que la clé secrète du client. Le nom du serveur retourné dans la réponse est le vrai nom du principal du service.

L'échange KRB_SAFE

Le message KRB_SAFE peut être utilisé par des clients qui exigent la capacité à détecter les modifications des messages qu'ils échangent. Ceci est réalisé en incluant une somme de contrôle à l'épreuve des collisions des données utilisateur et de quelques informations de contrôle. La somme de contrôle est assortie avec une clé de chiffrement ( normalement la dernière clé négociée via des sous-clés, ou la clé de session si aucune négociation n'est survenue.

Génération d'un message KRB_SAFE

   Lorsqu'une application souhaite envoyer un message KRB_SAFE, elle collecte ses données et les informations de contrôle appropriées et calcule une somme de contrôle sur l'ensemble. L'algorithme de somme de contrôle devrait être la somme de contrôle assortie mandatée pour être mise en œuvre ainsi que le système de chiffrement utilisé pour la clé de session ou de sous-session. La somme de contrôle est générée en utilisant la sous-clé de session, si elle est présente, ou la clé de session. Certaines mise en œuvre utilisent un algorithme de somme de contrôle différent pour les messages KRB_SAFE mais il n'est pas toujours possible de faire ainsi de façon interopérable.

   Les informations de contrôle pour le missage KDB_SAFE comportent à la fois un horodatage et un numéro de séquence. Le concepteur d'une application utilisant le message KRB_SAFE doit choisir au moins un des 2 mécanismes. Ce choix devrait se fonder sur les besoins du protocole d'application.

   Les numéros de séquence sont utiles lorsque tous les messages envoyés sont reçus par l'homologue. L'état de connexion est actuellement exigé pour l'entretien de la clé de session, aussi la maintenance du prochain numéro de séquence ne devrait pas présenter de problème supplémentaire.

   Si le protocole d'application est prévu pour tolérer des pertes de messages sans qu'ils soient renvoyés, l'utilisation de l'horodatage est le mécanisme de détection de répétition approprié. L'utilisation des horodatages est aussi le mécanisme approprié pour les protocoles de diffusion groupée dans lesquels tous les homologues partagent une sous-clé de session commune, mais certains messages seront envoyés à un sous-ensemble d'un homologue.

   Après le calcul de la somme de contrôle, le client transmet les informations et la somme de contrôle au receveur.

Réception du message KRB_SAFE

   Lorsqu'une application reçoit un message KRB_SAFE, elle le vérifie comme suit. Si une erreur survient, un code d'erreur est retourné.

   On vérifie d'abord que les champs version et type du protocole du message correspondent respectivement à la version en cours et à KRB_SAFE. Une discordance génère une erreur KRB_AP_ERR_BADVERSION ou KRB_AP_ERR_MSG_TYPE. L'application vérifie que la somme de contrôle utilisée est une somme de contrôle à l'épreuve des collisions qui utilise des clés compatibles avec la clé de session ou clé de sous-session selon le cas approprié ( ou la clé d'application déduite des clés de session ou de sous-session ). Si ce n'est pas le cas, une erreur KRB_AP_ERR_INAPP_CKSUM est générée. D'adresse de l'expéditeur doit être incluse dans les informations de contrôle; le receveur vérifie que le rapport du système d'exploitation de l'adresse de l'expéditeur correspond à l'adresse de l'expéditeur dans le message, et ( si une adresse de réception est spécifiée ou si le receveur exige une adresse ) qu'une des adresses du receveur apparaît comme adresse de réception dans le message. Pour travailler avec la traduction d'adresse réseau, les expéditeurs peuvent utiliser le type d'adresse directionnel pour l'adresse d'expéditeur et ne pas inclure d'adresse de receveur. Un échec de correspondance pour l'un de ces cas génère une erreur KRB_AP_ERR_BADADDR. Puis les champs timestamp et usec et/ou de numéro de séquence sont vérifiés. Si timestamp et usec sont attendus et absents, ou s'ils sont présents mais ne sont pas ceux en cours, l'erreur KRB_AP_ERR_SKEW est générée. Il n'est pas exigé que les timestamp soient strictement ordonnées; il est seulement exigé qu'ils soient dans la plage permise. Si les champs nom du serveur, ainsi que nom du client, heure, et microsecondes de l'authentifiant correspondent à de tels tuples récemment vus (envoyés ou reçus), l'erreur KRB_AP_ERR_REPEAT est générée. Si un numéro de séquence incorrect est inclus, ou si un numéro de séquence est attendu mais n'est pas présent, l'erreur KRB_AP_ERR_BADORDER est générée. Si ni un timestamp ni usec ni un numéro de séquence ne sont présents, une erreur KRB_AP_ERR_MODIFIED est générée. Finalement, la somme de contrôle est calculée sur les informations de données te de contrôle, et si elle ne correspond pas à la somme d contrôle reçue, une erreur KRB_AP_ERR_MODIFIED est générée.

   Si toutes les vérification réussissent, l'application est sûr que le message a été généré par son homologue et n'a pas été modifié dans le transit.

   Les mises en œuvre devraient accepter tout algorithme de checksum qui a à la fois la sécurité adéquate et des clés compatibles avec la clé de session ou de sous-session. Les chechsums non keyed ou qui ne sont pas à l'épreuve des collisions ne conviennent pas pour cette utilisation.

L'échange KRB_PRIV

Le message KRB_PRIV peut être utilisé par les clients qui exigent la confidentialité et la capacité à détecter les modifications des messages échangés. Il réalise cela en chiffrant les messages et en ajoutant des informations de contrôle.

Génération du message KRB_PRIV

Lorsqu'une application souhaite envoyer un message KRB_PRIV, elle collecte ses données et les informations de contrôle appropriées et les chiffre avec une clé de chiffrement ( habituellement la dernière clé négociée via des sous-clés, ou la clé de session si aucune négociation n'est survenue ). Au titre des informations de contrôle, le client doit choisir d'utiliser soit un timestamp soit un numéro de séquence (ou les 2). Après le chiffrement des données d'utilisateur et des informations de contrôle, le client transmet le texte chiffré et certaines des informations "d'enveloppe" au receveur.

Réception du message KRB_PRIV

   Lorsqu'une application reçoit un messagse KRB_PRIV, elle le vérifie comme suit. Si une erreur survient, un code d'erreur est rapporté.

   Il est d'abord vérifié que les champs de version et type du protocole du message correspondent respectivement à la version en cours et au KRB_PRIV. Une discordance génère une erreur KRB_AP_ERR_BADVERSION ou KRB_AP_ERR_MSG_TYPE. L'application déchiffre ensuite le texte chiffré et traite le texte clair qui en résulte. Si le déchiffrement montre que les données ont été modifiées, une erreur KRB_AP_ERR_BAD_INTEGRITY est générée.

   L'adresse de l'éxpéditeur doit être incluse dans les informations de contrôle; le receveur vérifie que le rapport du système d'exploitation de l'adresse de l'expéditeur correspond à l'adresse de l'expéditeur dans le message. Si une adresse de receveur est spécifiée ou si le receveur exige une adresse, une des adresse du receveur doit également apparaître comme adresse de receveur dans le message. Lorsqu'une adresse d'expéditeur ou de receveur peut ne par correspondre à l'adresse du message à cause d'une traduction d'adresse réseau, une application peut être écrite pour utiliser les adresses du type d'adresse directionnel à la place de l'adresse réseau réelle.

   Après cela intervient la vérification des champs timestamp et usec et/ou de numéro de séquence. Si le timestamp et usec sont attendus et ne sont pas présents, ou s'ils sont présents mais ne sont pas ceux en cours, l'erreur KRB_AP_ERR_SKEW est générée. Si les champs de nom du serveurs, ainsi que le nom du client, l'heure, et microseconde provenant de l'authentifiant correspondent à tout tuple de ces valeurs vu récemment, l'erreur KRB_AP_ERR_REPEAT est générée. Si un numéro de séquence incorrect est inclus, ou si un numéro de séquence est attendu mais n'est pas présent, l'erreur KRB_AP_ERR_BADORDER est générée. Si ni un timestamp, ni usec ni un numéro de séquence n'est présent, une erreur KRB_AP_ERR_MODIFIED est générée.

   Si toutes les vérifications réussissent, l'application peut supposer que le message a été généré par son homologue et a été transmis en toute sécurité.

L'échange KRB_CRED

Le message KRB_CRED peut être utilisé par les clients qui exigent la capacité à envoyer des accréditifs Kerberos d'un hôte à l'autre. Ceci est réalisé par l'envoi des tickets avec les données chiffrées qui contiennent les clés de session et les autres informations associées à ces tickets.

Génération d'un message KRB_CRED

   Lorsqu'une application souhaite envoyer un message KRB_CRED, elle obtient d'abord ( en utilisant l'échange KRB_TGS ) des accréditifs à envoyer à l'hôte distant. Elle construit ensuite un message KRB_CRED en utilisant le ou les tickets ainsi obtenus, plaçant la clé de session qu'il est nécessaire d'utiliser pour chaque ticket dans le champ clé de la séquence KrbCredInfo correspondante dans la partie chiffrée du message KRB_CRED.

   Les autres information associées à chaque ticket et obtenues durant l'échange KRB_TGS sont aussi placées dans la séquence KrbCredInfo correspondante dans la partie chiffrée du message KRB_CRÉD. L'heure courante et, s'ils sont spécifiquement exigés par l'application, les champs nonce, s-address, et r-address sont placés dans la partie chiffrée du message KRB_CRED, qui est alors chiffré avec la clé de chiffrement précédemment échangée dans le KRB_AP ( habituellement la dernière clé négociée via des sous-clés, ou la clé de session si aucune négociation n'est intervenue ).

   Note de mise en œuvre: lors de la construction d'un message KRB_CRED pour l'inclure dans un jeton de contexte initial GSS-API, la mise en œuvre MIT de Kerberos ne chiffrera pas le message KRB_CRED si la clé de session est DES ou triple DES. Pour l'intéropérabilité avec MIT, la mise en œuvre Microsoft ne chiffrera pas le KRB_CRED dans un jeton GSS-API si elle utilise une clé de session DES. MIT Kerberos peut recevoir et décoder des jetons KRB_CRED chiffrés ou non dans l'échange GSS-API. La mise en œuvre Heimdal de Kerberos peut aussi accepter des messages KRB_CRED chiffrés ou non. Comme le message KRB_CRED dans un jeton GSS-API est chiffré dans l'authentifiant, le comportement du MIT ne présente pas de problème de sécurité, bien qu'il soit en violation de la spécification Kerberos.

Réception d'un message KRB_CRED

   Lorsqu'une application reçoit un message KRB_CRED, elle le vérifie. Si une erreur survient, un code d'erreur est rapporté pour être utilisé par l'application Le message est vérifié en s'assurant que les champs de version et type de protocole correspondent respectivement à la version en cours et à KRB_CRED. Une discordance génère une erreur KRB_AP_ERR_BADVERSION ou KRB_AP_ERR_MSG_TYPE. L'application déchiffre alors le texte chiffré et traite le texte clair résultant. Si le déchiffrement montre que les données ont été modifiées, une erreur KRB_AP_ERR_BAD_INTEGRITY est générée.

   Si elle est présente ou exigé, le receveur peut vérifier que le rapport du système d'exploitation sur l'adresse de l'expéditeur correspond à l'adresse de l'expéditeur dans le message, et qu'une des adresse de réception apparaît comme adresse de réception dans le message. La vérification d'adresse ne fournit aucune sécurité supplémentaire, car l'adresse, si elle est présente, a déjà été vérifiée dans le message KRB_AP_REQ et il n'y a aucun intérêt pour un agresseur à retourner un message KRB_CRED à celui qui l'a généré. Et donc, le receveur peut ignorer l'adresse même si elle est présente afin de mieux travailler dans des environnement de traducteur d'adresses réseau (NAT). L'échec de correspondance pour l'un de ces cas génère une erreur KRB_AP_ERR_BADADDR. Les receveurs peuvent sauter la vérification d'adresse, car le message KRB_CRED ne peut généralement pas être reflété à celui qui l'a généré. Les champs timestamp et usec ( et nonce, s'il est exigé) sont vérifiés ensuite. Si timestamp et usec ne sont pas présents, ou s'ils sont présents mais ne sont pas celui en cours, l'erreur KRB_AP_ERR_SKEW est générée.

   Si toutes les vérifications ont réussi, l'application mémorise chacun des nouveaux tickets dans sa mémoire cache d'accréditifs avec la clé de session et les autres informations dans la séquence KrbCredInfo correspondante de la partie chiffrée du message KRB_CRED.

Échanges d'authentification user to user

   L'authentification d'utilisateur à utilisateur fournit une méthode pour effectuer l'authentification lorsque le vérificateur n'a pas accès à un service de clé à long terme. Ce peut être le cas lorsqu'on utilise un serveur (par ex: un serveur Windows) comme utilisateur sur une workstation. Dans un tel cas, le serveur peut avoir accès au TGT obtenu lorsque l'utilisateur se connecte sur la workstation, mais comme le serveur fonctionne comme un utilisateur non privilégié, il peut ne pas avoir accès aux clés du système. Des situations similaires peuvent survenir en faisant fonctionnes des applications paire-à-paire.

   Pour traiter ce problème, le protocole Kerberos permet au client de demander que le ticket produit par le KDC soit chiffré en utilisant une clé de session provenant d'un TGT produit par la partie qui va vérifier l'authentification. Ce TGT doit être obtenu du vérificateur au moyen d'un échange extérieur au protocole Kerberos, habituellement au titre du protocole d'application. Noter que parce que le TGT est chiffré avec la clé secrète du KDC, il ne peut pas être utilisé pour l'authentification sans la possession de la clé secrète correspondante. De plus, parce que le vérificateur ne révèle pas la clé secrète correspondante, fournir le TGT du vérificateur ne permet pas de se faire passe pour le vérificateur.

   Le premier message est une négociation spécifique de l'application entre le client et le serveur, à la fin de laquelle tous deux ont déterminé qu'ils vont utiliser l'authentification d'utilisateur à utilisateur, et le client a obtenu le TGT du serveur.

   Ensuite, le client inclut le TGT du serveur comme ticket supplémentaire dans sa demande KRB_TGS_REQ au KDC et spécifie l'option ENC-TKT-IN-SKEY dans sa demande.

   S'il est validé, le ticket d'application retourné au client va être chiffré en utilisant la cé de session provenant du ticket supplémentaire et le client va le noter lorsqu'il utilise ou mémorise le ticket d'application.

   Lorsqu'il contacte le serveur en utilisant un ticket obtenu pour l'authentification l'utilisateur à utilisateur, le client doit spécifier le flag USE-SESSION-KEY dans le champ ap-options. Cela dit au serveur d'application d'utiliser la clé de session associée à son TGT pour déchiffrer le ticket de serveur fourni dans la demande d'application.

Spécifications de chiffrement et de checksum

   Les protocoles Kerberos décrits dans le présent document sont conçus pour le chiffrement de messages de tailles arbitraires, en utilisant le chiffrement de flux ou de blocs. Le chiffrement est utilisé pour prouver les identités des entités du réseau qui participent à l'échange de messages. Le KDC pour chaque domaine est de confiance pour tous les principaux enregistrés dans ce domaine pour mémoriser une clé secrète. La preuve de la connaissance de cette clé secrète est utilisée pour vérifier l'authenticité d'un principal.

   Le KDC utilise la clé secrète du principal ( dans l'échange d'AS ) ou une clé de session partagée ( dans l'échange de TGS ) pour chiffrer les réponses aux demandes de ticket; la capacité à obtenir la clé secrète ou la clé de session implique la connaissance des clés appropriées et l'identité du KDC. La capacité d'un principal à déchiffrer la réponse du KDC et à présenter un ticket et un authentifiant correctement formé ( généré avec la clé de session provenant de la réponse du KDC ) à un service vérifie l'identité du principal; de même, la capacité du service à extraire la clé de session du ticket et à prouver ainsi sa connaissance du secret dans une réponse vérifie d'identité du service.

   L'opération string-to-key fournie par la rfc3961 est utilisée pour produire une clé à long terme pour un principal ( généralement pour un utilisateur ). La chaîne salt par défaut, si fournis via les données de pré-authentification, est l'enchaînement des composants de domaine et de nom du principal, dans l'ordre, et sans séparateur. Sauf indication contraire, on utilise l'ensemble des paramètres opaque de string-to-key par défaut comme définis dans la rfc3961.

   Les données chiffrées, et les checksums sont transmis en utilisant les objets de données EncryptedData, EncryptionKey, et Checksum. Les opérations de chiffrement, déchiffrement, et de checksums décrites dans le présent document utilisent les opérations correspondantes de chiffrement, déchiffrement, et get_mic décrites dans la rfc3961, avec la génération implicite de clé spécifique utilisant les valeurs de KeyUsage spécifiées dans la description de chaque objet EncryptedDate ou Checksum pour faire varier la clé pour chaque opération. Noter que dans certains cas, la valeur à utiliser dépend de la méthode de choix de la clé ou du contexte du message.

   Les utilisations de clé sont des entiers non signés 32-bits, le 0 n'est pas permis. Les valeurs d'utilisation de clé de 512 à 1023 sont réservés pour des utilisation internes à une mise en œuvre de Kerberos. ( par exemple, alimenter un générateur de nombre pseudo-aléatoire avec une valeur produite en chiffrant quelque chose avec une clé de session et une valeur d'utilisation de clé non utilisée pour un autre objet. ) Les valeurs d'utilisation de clé de 1024 à 2047 sont réservés à l'usage des applications; les applications devraient utiliser des valeurs paires pour le chiffrement et des valeurs impaires pour les checksums dans cette gamme.

   Il peut exister d'autres documents qui définissent les protocoles dans les termes des types de chiffrement ou de checksums de la rfc1510. Ces documents ne connaissent rien sur les utilisations de clé. Afin que ces spécifications continuent d'avoir un sens en attendant leur mise à jour, si aucune valeur d'utilisation de clé n'est spécifié, les utilisation de clé 1024 et 1025 doivent être utilisés pour déduire les clés pour le chiffrement et les checksums, respectivement. ( ceci ne s'applique pas aux protocoles qui ont leur propre chiffrement indépendemment du présent cadre, en utilisant directement la clé qui résulte de l'échange d'authentification de Kerberos. ) De nouveaux protocoles définis en termes de types de chiffrement et de checksum Kerberos devraient utiliser leurs propres valeurs d'utilisation de clé.

   Sauf indication contraire, aucun chaînage d'état de chiffrement n'est fait d'une opération de chiffrement à un autre.

   Note de mise en œuvre: Bien que ce ne soit pas recommandé, certains protocoles d'application vont continuer d'utiliser directement les données de clé, même si c'est seulement dans les spécifications de protocole qui existent actuellement. Une mise en œuvre destinée à prendre en charge les applications Kerberos générales peuvent donc avoir besoin de rendre disponibles les données de clé, ainsi que les attributs et opérations décrits dans la rfc3961. Une des raisons les plus courantes pour effectuer directement le chiffrement est le contrôle direct sur la négociation et le choix d'un algorithme de chiffrement suffisamment fort ( dans le contexte d'une application de données ). Bien que Kerberos ne fournisse pas directement de facilité de négociation des types de chiffrement entre le client et le serveur d'application, il y a des approches qui utilisent Kerberos pour faciliter cette négociation. Par exemple, un client peut ne demander que des types de clé de session suffisamment fort au KDC et espérer que tout type retourné par le KDC sera compris et pris en charge par le serveur d'application.

Spécifications de message

   Le protocole Kerberos est défini ici en termes de notation ASN.1, qui fournit une syntaxe de spécification à la fois de la disposition abstraite des messages du protocole et de leurs codages. Les mises en œuvre qui n'utilisent pas un compilateur ASN.1 existant ou une bibliothèque de soutien devraient avoir une bonne compréhension de la spécification ASN.1 réelle afin de s'assurer d'un comportement correcte de la mise en œuvre.

   Noter qu'en plusieurs endroits, ds changements des types abstraits ont été faits par rapport à la rfc1510. Ceci en partie pour répondre à des hypothèses largement répandues faites par diverses mises en œuvre, qui résultent dans certains cas de violations non intentionnelles de la norme ASN.1. Elles sont clairement mentionnées lorsqu'elles surviennent. Les différences entre les types abstraits de la rfc1510 et les types abstraits dans le présent document peuvent causer l'émission de codages incompatibles quand on utilise certaines règles de codage, par exemple, les règles de codage compact ( PER, Packed Encoding Rules ). Cette incompatibilité théorique ne devrait pas être pertinente pour Kerberos, car Kerberos spécifie explicitement l'utilisation des règles de codage en méta-langage distinctif (DER, Distinguished Encoding Rules). Ce peu être un problème pour les protocoles qui cherchent à utiliser les types de Kerberos avec d'autres règles de codage. ( Cette pratique n'est pas recommandée ) À très peu d'exceptions près ( en particulier d'utilisation du BIT STRING ), les codages résultant de l'utilisation de DER restent identiques entre les types définis dans la rfc1510 et les types définis dans le présent document.

Les définitions de type de la présente section supposent une définition de module ASN.1 de la forme suivante:
KerberosV5Spec2 {
    iso(1) identified-organisation(3) dod(6) internet(1)
    security(5) kerberosV5(2) modules(4) krb5spec2(2)
} DEFINITIONS EXPLICIT TAGS ::= BEGIN
    -- reste de la définition ici
END

   Ceci spécifie que le contexte d'étiquetage du module devra être explicite et non automatique. Noter que dans certaines autres publications ( comme la rfc1510 et la rfc1964 ), la portion "dod" de d'identifiant d'objet est spécifiée par erreur comme ayant la valeur de "5". Dans le cas de la rfc1964, l'utilisation de la valeur d'OID correcte résulterait en un changement du protocole du câble; elle reste donc inchangée pour l'instant.

   Noter qu'ailleurs dans le document, la nomenclature de divers types de message est incohérente, mais elle suit largement les conventions du langage C, y compris l'utilisation du caractère souligné (_) et de l'écriture en majuscules de noms destinés à être des constantes numériques. Aussi, à certains endroits, les identifiants ( particulièrement ceux qui se réfèrent à des constantes ) sont écrits en majuscules afin de les distinguer du texte explicatif environnant.

   La notation ASN.1 ne permet pas de souligner dans les identifiants, aussi dans les définitions ASN.1 réelles, les soulignés sont remplacés par le traits d'union (-). De plus, les noms de membre de la structure et les valeur définies en ASN.1 doivent commencer par une lettre minuscule, alors que les noms du types doivent commencer par une majuscule.

Notes de compatibilité ASN.1

Pour les besoins de la compatibilité, les mises en œuvre devraient tenir compte des notes spécifiques suivantes concernant l'utilisation de l'ASN.1 dans Kerberos. Ces notes ne décrivent pas les variantes standard de l'ASN.1. L'objet de ces notes est plutôt de décrire quelques bizarreries historiques et non la conformité de diverses mises en œuvre, ainsi que des ambiguïtés historiques, qui, bien qu'elles soient de l'ASN.1 valide, peuvent amener une certaine confusion dans la mise en œuvre.

Règles de codage distinct ASN.1

Les codage des messages du protocole Kerberos doit obéir aux règles de codage en DER de l'ASN.1 telles que décrites dans X690. Certaines mises en œuvre ( qui sont principalement celles dérivées de DCE 1.1 et antérieures ) sont connues pour utiliser les règles de codage de base ( BER ) les plus générales; en particulier, cet mises en œuvre envoient des codages de longueur indéfinie. Les mises en œuvre peuvent accepter de tels codages dans l'intérêt de la rétro compatibles, bien qu'on doive prévenir les mises en œuvre que le décodage du BER le plus général est plein de périls.

Champs d'entier facultatifs

Certaines mises en œuvre de distinguent par en interne entre une valeur d'entier facultative omise et une valeur transmise de zéro. Les endroits du protocole où ceci est pertinent sont divers champs de micro-secondes, de noms occasionnels, et de numéro de séquence. Les mises en œuvre devraient traiter les valeurs d'entier facultatives omises comme ayant été transmises avec une valeur de zéro, si c'est ce qu'attend l'application.

Types SEQUENCE OF vides

Il y a des endroits du protocole où un message contient un type de SEQUENCE OF qui est un membre facultatif. Il peut en résulter un codage contenant une SEQUENCE OF vide. Le protocole Kerberos ne fait pas de distinction sémantique entre un type de SEQUENCE OF facultatif absent et un type de SEQUENCE OF facultatif présent mais vide. Les mises en œuvre ne devraient pas envoyer de codages de SEQUENCE OF vides marqués OPTIONAL, mais devraient les accepter comme équivalents à un type OPTIONAL vide. Dans la syntaxe ASN.1 qui décrit les messages Kerberos, les instances de ces types de SEQUENCE OF facultatifs problématiques sont indiquées avec un commentaire.

Tag Numbers non reconnus

De futures révisions du présent protocole pourraient comporter de nouveaux types de message avec des numéros d'étiquette de classe APPLICATION différents. De telles révisions devraient protéger les mises en œuvre plus anciennes en envoyant seulement les types de messages que les parties comprennent; par exemple, au moyen d'un flag mis par le receveur dans une demande précédente. Dans l'intérêt de la robustesse du traitement d'erreurs, les mises en œuvre devraient accepter de traiter de toutes façons un message reçu avec une étiquette non reconnue, et retourner le cas échéant un message d'erreur.

En particulier, les KDC devraient retourner KRB_AP_ERR_MSG_TYPE si le tag incorrecte est envoyé sur TCP. Les KDC ne devraient pas répondre aux messages reçus avec un tag inconnus sur UDP afin d'éviter les attaques DOS. Pour les applications non KDC, la mise en œuvre de Kerberos indique normalement une erreur à l'application qui prend les mesures appropriées sur la base du protocole d'application.

Tag Number supérieurs à 30

Une mise en œuvre simple de décodeur ASN.1 DER peut rencontrer des problèmes avec les numéros d'étiquette ASN.1 supérieures à 30, du fait que de tels numéros sont codés en utilisant plus d'un octet. Les révisions futures du présent protocole pourraient utiliser les numéros supérieurs à 30, et les mises en œuvre devraient être préparées à retourner une erreur, le cas échéant, lorsqu'elles ne reconnaissent pas l'étiquette.

Types Kerberos de base

Ce paragraphe définit un certain nombre de types de base qui sont éventuellement utilisés dans plusieurs messages du protocole Kerberos

KerberosString

   La spécification d'origine du protocole Kerberos dans la rfc1510 utilise GeneralString à de nombreux endroits pour les données de chaîne human-readable. Les mise en œuvre historiques de Kerberos ne peuvent pas utiliser toute la puissance de GeneralString. Ce type ASN.1 exige l'utilisation de séquences d'échappement de désignation et d'invocation comme spécifié dans la norme ISO-2022/ECMA-35 pour commuter les ensembles de caractères, et l'ensemble de caractères par défaut qui est conçus désigné sous le nom de G0 est la version de référence internationale ( IRV ) - US ASCII de ISO-646/ECMA-6.

   La nomes ISO-2022/ECMA-35 définit 4 éléments de code d'ensemble de caractèrse (G0 à G3) et 2 éléments de code de fonction de contrôle (C0 à C1). DER interdit la désignation des ensembles de caractères autres que les ensembles G0 et C0. Malheureusement, cela semble avoir l'effet collatéral d'interdire l'utilisation de l'ensemble de caractères ISO Latin (ISO-8859) ou de tout autre ensemble de caractères qui utilise un jeu de 96 caractères, comme ISO-2022/ECMA-35 interdit de les désigner comme l'élément de code G0.

   En pratique, de nombreuses mises en œuvre traitent GeneralStrings comme chaînes 8 bits par défaut quel que soit le jeu de caractères, sans considération de l'utilisation correcte des séquences d'échappement. Le jeu de caractères par défaut est souvent déterminé par la localisation du systèmes d'exploitation de l'utilisateur habituel. Au moins une mise en œuvre majeure place des caractères Unicode codés en UTF-8 dans GeneralString. Cette incapacité à s'en tenir aux spécifications de GeneralString a pour conséquence des problèmes d'interopérabilité lorsque des codages de caractères incompatibles sont utilisés par des client, services et KDC Kerberos.

   Cette situation malheureuse est le résultat d'une documentation défectueuse des restrictions du type ASN.1 de GeneralString dans les spécifications Kerberos précédentes. Le nouveau (post-RFC 1510) type KerberosString, défini ci-dessous est une GeneralString qui a pour contrainte de ne contenir que des caractères en IA5String.

  KerberosString := GeneralString (IA5String)

   En général, les caractères de contrôle US-ASCII ne devraient pas être utilisés dans KerberosString. Les caractères de contrôle ne devraient pas être utilisés dans des noms de principal ou des noms de domaine

   Pour la compatibilité, les implémentations peuvent choisir d'accepter les valeurs de GeneralString qui contiennent des caractères autres que ceux permis par IA5String, mais elles devraient être conscientes que les codes de désignation de jeu de caractères seront vraisemblablement absents, et que le codage devrait probablement presque de toutes façons être traité comme spécifique de la localisation. Les implémentations peuvent aussi choisir d'émettre des valeurs de GeneralString qui sont au-delà ce celles permises par IA5String, mais elles devraient être conscientes que faire cela est extraordinairement risqué du point de vue de l'interopérabilité.

   Certaines mises en œuvre existantes utilisent GeneralString pour coder des caractères spécifiques de la localisation sans échappement. C'est une violation de la norme ASN.1. La plupart de ces mises en œuvre codent l'US-ASCII dans la moitié gauche, aussi tant que la mise en œuvre ne transmet que de l'US-ASCII, la norme ASN.1 n'est pas violée à cet égard. Lorsque ces mises en œuvre codent les caractères sans échappement spécifiques de la localisation avec le bit de plus fort poids établi, cela viole la norme ASN.1

   D'autres mises en œuvre sont connues pour utiliser GeneralString avec un codage UTF-8. Cela aussi est une violation de la norme ASN.1, car UTF-8 est un codage différent, et pas un jeu "G" à 94 ou 96 caractères tel que défini par la norme ISO 2022. On pense que ces mises en œuvre n'utilisent même pas la séquence d'échappement de ISO 2022 pour changer le codage des caractères. Même si les mises en œuvre devaient annoncer le changement de codage en utilisant la séquence d'échappement, la norme ASN.1 interdit l'utilisation de toute séquence d'échappement autre que celles utilisées pour désigner/invoquer les ensembles "G" ou "C" permis par GeneralString.

   De futures révisions de ce protocole permettront presque certainement une représentation plus interopérable des noms de principaux, probablement en y incluant UTF8String. Noter qu'appliquer une nouvelle contrainte à un type qui n'en avait pas auparavant constitue la création d'un nouveau type ASN.1. Dans ce cas particulier, le changement n'aboutit pas à un changement de codage en DER.

Domaine et PrincipalName

Realm ::= KerberosString
PrincipalName ::= SEQUENCE {
    name-type [0] Int32,
    name-string [1] SEQUENCE OF KerberosString
}

   Les noms de domaine Kerberos sont codés comme KerberosStrings. Les domaines se doivent pas contenir de caractère avec le code 0 (US-ASCII NULL). La plupart des domaines vont normalement comporter plusieurs composants séparés par des points, dans le style des noms de domaine Internet, ou séparés par des "/", dans le style des noms X.500. Un PrincipalName est une séquences typée de composants comportant les sous champs suivants:

name-type Ce champ spécifie le type de nom qui suit. Ce champ devrait être traité comme conseil.
name-string Ce champ code une séquence de composants qui forment un nom, chaque composant étant codé comme un KerberosString. Pris ensemble, un PrincipalName et un domaine forment un identifiant de principal.

KerberosTime

KerberosTime ::= GeneralizedTime – sans fraction de seconde

Les horodatages utilisés dans Kerberos sont codés comme GeneralizedTime. Une valeur KerberosTime ne doit pas inclure de portions fractionnée de seconde. Comme exigé par les DER, elle ne doit pas non plus inclure de séparateur, et elle doit spécifier la zone de temps UTC (Z). Exemple: le seul format valide pour l'heure UTC 6 minutes, 27 secondes aprés 21h le 6 novembre 1985 est 19851106210627Z.

Contraintes sur les types entiers

   Certains membres de type entier devraient être contraints à des valeur représentables en 32-bits, pour la compatibilité avec des limites raisonnables d'implémentation.

Int32 ::= INTEGER (-2147483648..2147483647)
    -- valeurs signées représentables en 32 bits
UInt32 ::= INTEGER (0..4294967295)
    -- valeurs de 32 bits non signées
Microseconds ::= INTEGER (0..999999)
    -- microsecondes

   Bien qu'il en résulte des changements des types abstraits de la version de la rfc1510, le codage DER ne devrait pas être altéré. Les anciennes implémentations étaient normalement limitées à des valeurs d'entier 32-bits, et les numéros alloués devraient entrer dans l'espace des valeurs entières représentables en 32-bits afin de promouvoir l'intéropérabilité. Plusieurs champs d'entiers dans les messages sont contraints à des valeurs fixes.

pvno comme TGT-VNO ou AUTHENTICATOR-VNO, ce champ récurant vaut toujours 5.
msg-type Ce champ est habituellement identique au tagNumber d'application du type de message qui le contient

HostAddress et HostAddresses

HostAddress ::= SEQUENCE {
    addr-type [0] Int32,
    address [1] OCTET STRING
}

   Note:HostAddress est toujours utilisé comme champ OPTIONAL et ne devrait pas être vide. Le codage d'adresse d'hôte comporte 2 champs:

addr-type Ce champ spécifie le type d'adresse suivant.
address Code une seule adresse du type addr-type.

AuthorizationData

AuthorizationData est toujours utilisé comme champ OPTIONAL et ne devrait pas être vide.
AuthorizationData
::= SEQUENCE OF SEQUENCE {
    ad-type [0] Int32,
    ad-data [1] OCTET STRING
}

ad-data Contient des données d'authorisation à interpréter conformément à la valeur du chanp ad-type correspondant
ad-type Spécifie le format du sous-champ ad-data.

   Chaque séquence de type et données est perçue comme un élément d'autorisation. Les éléments peuvent être spécifiques à l'application; cependant, il y a un jeu commun d'éléments récursifs qui devraient être compris par toutes les implémentations. Ces éléments contiennent d'autres éléments embarqués, et l'interprétation de l'élément encapsulé détermine lequel des éléments embarqués doit être interprétés, et ceux qui peuvent être ignorés.

   Ces éléments de données d'autorisation communs sont définis récursivement, signifiant que ad-data pour ces types va lui-même contenir une donnée de séquence d'autorisation. dont l'interprétation est affectée par l'élément encapsulant. En fonction de la signification de l'élément encapsulant, les éléments encapsulés peuvent être ignorés, pourraient être interprétés produit directement par le KDC, ou pourraient être stockés dans une partie plaintext séparé du ticket. Les types d'éléments encapsulant sont spécifiés comme partie de la spécification Kerberos parce que comportement fondé sur ces valeurs devrait être compris te toutes les implémentations, alors que d'autre éléments n'ont besoin d'être compris que par les applications qu'ils affectent.

   Les éléments de données d'autorisation sont considérés comme critiques s'ils sont présents dans un ticket ou un authentifiant. Si un type d'élément de données d'autorisation inconnu est reçu par un serveur dans un AP-REQ ou dans un ticket contenu dans un AP-REP, alors, sauf s'il est encapsulé dans un élément de données d'autorisation commun qui amende la criticité des éléments qu'il contient, l'authentification doit échouer. Les données d'autorisation sont destinées à restreindre l'utilisation d'un ticket. Si le service ne peut pas déterminer si la restriction s'applique à ce service, il peut en résulter une faiblesse de la sécurité de l'utilisation de ce ticket pour ce service. Les éléments d'autorisation qui sont facultatifs peuvent être inclus dans un élément AD-IF-RELEVANT.

Contenu des ad-data__________________ad-type
Codage DER de AD-IF-RELEVANT_________1
Codage DER de AD-KDCIssued___________4
Codage DER de AD-AND-OR______________5
Codage DER de AD-MANDATORY-FOR-KDC___8

IF-RELEVANT

   AD-IF-RELEVANT ::= AuthorizationData

  Les éléments encapsulés au sein de l'élément if-relevant sont destinés seulement à être interprétés par les serveurs d'application qui comprennent le ad-type particulier de l'élément incorporé. Les serveurs d'application qui ne comprennent pas le type d'un élément incorporé au sein de l'élément if-relevant peuvent ignorer l'élément non interprétable. Cet élément aide à l'interopérabilité des implémentations qui peuvent avoir des extensions locales pour l'autorisation.

  Le ad-type pour AD-IF-RELEVANT est (1)

KDCIssued

AD-KDCIssued ::= SEQUENCE {
    ad-checksum [0] Checksum,
    i-realm [1] Realm OPTIONAL,
    i-sname [2] PrincipalName OPTIONAL,
    elements [3] AuthorizationData
}

ad-checksum ckecksum cryptographique calculés sur le codage DER de AuthorizationData dans le champ "elements", keyed avec la clé de session. Son checksumtype est le type de checksum obligatoire pour le type de chiffrement de la clé de sessio, et sa valeur d'utilisation de clé est 19.
i-realm, i-sname Le nom du principal qui émet, s'il est différent de celui du KDC. Ce champ devrait être utilisé lorsque le KDC peut vérifier l'authenticité des éléments signés par le principal qui émet, et permet au KDC de notifier au serveur d'application la validité de ces éléments.
elements Séquence d'éléments de données d'autorisation produite par le KDC.

   Le champ ad-data produit par le KDC est destiné à fournir un moyen pour que les accréditifs de principal Kerberos incorporent en leur sein les attributs de privilège et autres mécanismes d'autorisation positive, amplifiant les privilèges du principal au-delà de ce qui peut être fait en utilisant des accréditifs sans un tel élément a-data.

   Les moyens ci-dessus ne peuvent être fournis sans cet élément à cause de la définition du champ authorization-data qui permet d'ajouter des éléments à volonté par le porteur d'un TGT au moment où il demande les tickets de service, et des éléments peuvent aussi être ajoutés à un ticket délégué par inclusion dans l'authentifiant.

   Pour les éléments produits par le KDC, ceci est empêché parce que les éléments sont signés par le KDC en incluant un checksum chiffrée en utilisant la clé du serveur (la même que celle utilisée pour chiffrer le ticket ou une clé dérivée de cette clé). Les éléments encapsulés avec l'élément produit par le KDC doivent être ignorés par le serveur d'application si cette signature n'est pas présente. De plus, les éléments encapsulés au sein de cet élément à partir d'un TGT peuvent être interprétés par le KDC, et utilisés comme base, conformément à la politique, pour inclure des éléments nouvellement signés au sein de tickets dérivés, mais ils ne seront par copiés directement sur un ticket dérivé. S'ils sont copiés directement sur un ticket dérivé par un KDC qui n'est pas au courant de cet élément, la signature ne sera pas correcte pour les éléments de ticket d'application, et le champ sera ignoré par le serveur d'application.

   Cet élément et les éléments qu'il encapsule peuvent être ignorés en toute sécurité par les applications, serveur d'application, et KDC qui n'implémentent pas cet élément.

AND-OR

AD-AND-OR ::= SEQUENCE {
    condition-count [0] Int32,
    elements [1] AuthorizationData
}

   Lorsque des éléments AD restrictifs sont encapsulés au sein de l'élément and-or, l'élément and-or est considéré comme satisfait si et seulement si au foins le nombre d'éléments encapsulés spécifié dans condition-count est satisfait. Donc, cet élément peut être utilisé pour mettre en œuvre une opération "ou" en réglant le champ condition-count à 1, et il peut spécifier une opération "et" en réglant le compte de condition au nombre d'éléments incorporés. Les serveurs d'application qui ne mettent pas en œuvre cet élément doivent rejeter les tickets qui contiennent des éléments de données d'autorisation de ce type. Le ad-type pour AD-AND-OR est (5)

MANDATORY-FOR-KDC

AD-MANDATORY-FOR-KDC ::= AuthorizationData

Les éléments AD encapsulés au sein de l'élément mandatory-for-kdc sont à interpréter par le KDC. Les KDC qui ne comprennent pas le type d'un élément incorporé au sein de l'élément mandatory-for-kdc doivent rejeter la demande. Le ad-type pour AD-MANDATORY-FOR-KDC est (8)

PA-DATA

   Historiquement, les PA-DATA étaient connues comme des données de pré-authentification, ce qui signifie qu'elles étaient utilisée pour augmenter l'authentification initiale auprès du KDC. Depuis cette époque, elles ont aussi été utilisées comme trou typé avec lequel on étend les échanges de protocoles avec le KDC.

PA-DATA ::= SEQUENCE {
    -- NOTE : la première étiquette est [1], et non [0]
    padata-type [1] Int32,
    padata-value [2] OCTET STRING -- peut être codée AP-REQ
}

padata-type Indique la façon d'interpréter l'élément padata-value. Les valeurs négatives de padata-type sont réservées pour des utilisations non-enregistrées; les valeurs non négatives sont utilisée pour une interprétation répertoriée du type d'élément.
padata-value Contient habituellement le codage DER d'un autre type; le champ padata-type identifie quel type est codé ici.

type de padata__Nom_______________Contenu de la valeur padata
1_______________pa-tgs-req________Codage en DER de AP-REQ
2_______________pa-enc-horodatage_Codage en DER de PA-ENC-TIMESTAMP
3_______________pa-pw-salt________sel (non codé en ASN.1)
11______________pa-etype-info_____Codage en DER de ETYPE-INFO
19______________pa-etype-info2____Codage en DER de ETYPE-INFO2

   Ce champ peut aussi contenir des informations nécessaires à certaines extensions au protocole Kerberos. Par exemple, il peut être utilisé pour vérifier l'identité d'un client avant qu'aucune réponse ne soit retournée.

   Le champ padata peut aussi contenir les informations nécessaires pour aider le KDC ou le client à choisir la clé nécessaire pour générer ou déchiffrer la réponse. Cette forme de padata est utile pour la prise en charge de l'utilisation de certaines cartes avec Kerberos.

PA-TGS-REQ

Dans le cas de demandes de tickets supplémentaire KRB_TGS_REQ, padata-value contient une AP-REQ coddée. La somme de contrôle dans l'authentifiant ( qui doit être à l'épreuve des collisions ) est à calculer sur le codage de KDC-REQ-BODY.

Pré-authentification à timestamp chiffré

   Il y a des types de pré-authentification qui peuvent être utilisés pour pré-authentifier un client au moyen d'un timestamp chiffré.

PA-ENC-TIMESTAMP ::= EncryptedData -- PA-ENC-TS-ENC

PA-ENC-TS-ENC ::= SEQUENCE {
    patimestamp [0] KerberosTime -- client's time --,
    pausec [1] Microseconds OPTIONAL
}

   patimestamp contient l'heure du client, et pausec contient les microsecondes, qui peuvent être omises si un client ne va pas générer plus d'une demande par seconde. Le texte chiffré ( padata-value ) comporte le codage de PA-ENC-TS-ENC, chiffré en utilisant la clé secrète du client et une valeur d'utilisation de clé de 1.

PA-PW-SALT

padata-value pour ce type de pré-authentification contient de salt pour le string-to-key à utiliser par le client pour obtenir la clé pour déchiffrer la partie chiffrée d'un message AS-REP. Malheureusement, pour des raisons historiques, l'ensemble de caractères à utiliser n'est pas spécifié et probablement spécifique à la localisation.

Dans l'exemple trivial, une chaîne de salt de longueur 0 est très courant pour les domaines qui ont converti leur bases de données de principal depuis une version 4. Un KDC ne devrait par envoyer PA-PW-SALT lorsqu'il produit un message KRB-ERROR qui demande une pré-authentification supplémentaire. Note d'implémentation: Certaines implémentations de KDC produisent un PA-PW-SALT erroné lorsqu'elle envoient un message KRB-ERROR qui demande une pré-authentification supplémentaire. Donc, les clients devraient ignorer un PA-PW-SALT accompagnant un KDC-ERROR qui demande une pré-authentification supplémentaire. Un KDC ne doit pas envoyer PA-PW-SALT lorsque le AS-REQ du client comporte au moins un etype "newer".

PA-ETYPE-INFO

   Le type de pré-authentification ETYPE-INFO est envoyé par le KDC dans un KRB-ERROR indiquant l'exigence d'une pré-authentification supplémentaire. Il est habituellement utilisé pour notifier à un client quelle clé utiliser pour le chiffrement d'un timestamp chiffré pour les besoins de l'envoi d'une valeur PA-ENC-TIMESTAMP de pré-authentification. Il peut aussi être envoyé dans un AS-REP pour fournir des informations au client sur le salt de clé à utiliser pour le string-to-key que le client doit utiliser pour obtenir la clé de déchiffrement de la partie chiffrée du AS-REP.

ETYPE-INFO-ENTRY ::= SEQUENCE {
    etype [0] Int32,
    salt [1] OCTET STRING OPTIONAL
}
ETYPE-INFO ::= SEQUENCE OF ETYPE-INFO-ENTRY

   Le salt, comme celui de PA-PW-SALT, est aussi complètement non spécifié par rapport au jeu de caractères et est probablement spécifique à la localisation. Si ETYPE-INFO est envoyé dans un AS-REP, il doit être exactement un ETYPE-INFO-ENTRY, et son etype doit correspondre à celui du enc-part dans AS-REP. Un KDC ne doit pas envoyer PA-ETYPE-INFO lorsque le AS-REQ du client comporte un moins un etype "newer".

PA-ETYPE-INFO2

   Le type de pré-authentification ETYPE-INFO2 est envoyé par le KDC dans un KRB-ERROR indiquant l'exigence d'une pré-authentification supplémentaire. Il est habituellement utilisé pour notifier à un client quelle clé utiliser pour le chiffrement d'un timestamp chiffré pour les besoins de l'envoi d'une valeur PA-ENC-TIMESTAMP de pré-authentification. Il peut aussi être envoyé dans un AS-REP pour fournir des informations au client sur le salt de clé à utiliser pour le string-to-key que le client doit utiliser pour obtenir la clé de déchiffrement de la partie chiffrée du AS-REP

ETYPE-INFO2-ENTRY ::= SEQUENCE {
    etype [0] Int32,
    salt [1] KerberosString OPTIONAL,
    s2kparams [2] OCTET STRING OPTIONAL
}
ETYPE-INFO2 ::= SEQUENCE SIZE (1..MAX) OF ETYPE-INFO2-ENTRY

   Le type de salt est un KerberosString, mais les installations existantes peuvent avoir des caractères spécifiques de la localisation mémorisés dans le chaînes de salt, et les développeurs peuvent choisir de les traiter. L'interprétation de s2kparams est spécifiée dans la description du cryptosystem associé au etype. Chaque cryptosystem a une interprétation par défaut de s2kparams qui restera si cet élément est omis dans le codage de ETYPE-INFO2-ENTRY.

   Si ETYPE-INFO2 est envoyé dans un AS-REP, il doit être exactement un ETYPE-INFO2-ENTRY, et son etype doit correspondre à celui du enc-part dans le AS-REP. L'ordre préféré des données de pré-authentification conseillé qui affecte le choix de clé du client est: ETYPE-INFO2, suivi par ETYPE-INFO, suivi par PW-SALT. Un KDC ne doit pas envoyer de ETYPE-INFO ou PW-SALT lorsque AS-REQ comporte au moins un etype "newer".

KerberosFlags

KerberosFlags ::= BIT STRING (SIZE (32..MAX))
    -- nombre minimum de bits qui doivent être envoyés, mais pas moins de 32

   Note de compatibilité: les paragraphes suivants décrivent un changement par rapport à la description de la rfc1510 des chaînes binaires qui résulteraient en une incompatibilité dans le cas d'une mise en œuvre strictement conforme au DER de l'ASN.1 et à la RFC1510.

   Les chaînes binaires ASN.1 ont plusieurs utilisations. L'utilisation la plus simple d'une chaîne est de contenir un vecteur de bits, sans signification particulière attachée aux bits individuels. Ce vecteur de bits n'est pas nécessairement un multiple de 8 bits de longueur. L'utilisation par Kerberos d'une chaîne binaire comme vecteur booléen compact dans lequel chaque élément a une signification distincte pose quelques problèmes. La notation naturelle pour un vecteur booléen compact est la notation ASN.1 "NamedBit", et les DER exigent que les codages d'une chaîne binaire qui utilise la notation "NamedBit" excluent tous bits à zéro en queue. Il est facile de négliger cette troncature, tout particulièrement dans les implémentations de langage C qui choisissent naturellement de mémoriser les vecteur booléens comme des entiers de 32bits.

   Par exemple, si la notation de KDCOptions devait inclure la notation "NamedBit", comme dans la rfc1510, et si la valeur KDCOptions à coder avait seulement le bit "transmissible" (bit numéro 1) mis, le codage DER doit n'inclure que 2 bits: le premier est à 0 et est réservé, et le bit de valeur 1 pour transmissible.

   La plupart des implémentations de Kerberos envoient inconditionnellement 32 bits sur le réseau lors du codage de chaînes binaires utilisée comme vecteurs booléens. Ce comportement viole la syntaxe ASN.1 utilisée pour les valeurs de flag dans la rfc1510, mais cela survient si fréquemment que la description du protocole en est modifiée pour s'en accommoder.

   Par conséquent, le présent document retire la notation "NamedBit" pour les bits individuels, les relèguant en commentaires. La contrainte de taille sur le type KerberosFlags exige qu'au moins 32 bits soient codés à tout moment, bien qu'une implémentation laxiste puisse choisir d'accepter moins de 32bits et de traiter les bits manquants comme mis à 0.

   Actuellement, aucune utilisation de KerberosFlags ne spécifie plus de 32bits de flags, bien que de futures révisions du présent document puissent le faire. Lorsque plus de 32 bits sont à transmettre dans une valeur de KerberosFlags, les futures révisions du présent document spécifieront spécifieront vraisemblablement que le plus petit nombre de bits nécessaires pour coder le bit de valeur un de plus haut rang devrait être envoyé. Ceci est assez similaire au codage en DER d'une chaîne binaire qui est déclarée avec la notation "NamedBit".

Type liés au cryptosystem

   De nombreux messages de protocole Kerberos contiennent un EncryptedData comme conteneur pour des données chiffrées de façon arbitraire, qui sont souvent le codage chiffré d'un autre type de données. Les champs au sein de EncryptedData assistent le receveur dans le choix d'une clé pour le déchiffrer

EncryptedData ::= SEQUENCE {
    etype [0] Int32 -- EncryptionType --,
    kvno [1] UInt32 OPTIONAL,
    cipher [2] OCTET STRING – texte chiffré
}

etype Ce champ spécifie l'algorithme de chiffrement utilisé pour chiffrer le texte
kvno Ce champ contient le numéro de version de clé utilisée pour chiffrer les données. n'est présent que dans les messages chiffrés avec des clés à longue durée.
cipher Contient le texte chiffré.

   Le type EncryptionKey est le moyen par lequel les clés cryptographiques utilisée pour le chiffrement sont transférées.

EncryptionKey ::= SEQUENCE {
    keytype [0] Int32 -- actually encryption type --,
    keyvalue [1] OCTET STRING
}

keytype Spécifie le type de chiffrement de la clé de chiffrement qui suit dans le champ keyvalue.
keyvalue Contient la clé elle-même, codée comme une chaîne d'octet.

   Les messages qui contiennent des données de texte en clair à authentifier le feront habituellement en utilisant un membre du type Checksum. La plupart des instances de Checksums utilisent un hachage chiffré, bien que des exceptions existent.

Checksum ::= SEQUENCE {
    cksumtype [0] Int32,
    checksum [1] OCTET STRING
}

cksumtype Indique l'algorithme utilisé pour générer la somme de contrôle qui l'accompagne
checksum Contient la somme de contrôle elle-même.

Tickets

   Ce paragraphe décrit les paramètres de format et de chiffrement pour les tickets et les authentifiants. Lorsqu'un ticket ou un authentifiant est inclus dans un message de protocole, il est traité comme un objet opaque. Un ticket est un enregistrement qui aide un client à s'authentifier auprès d'un service. Un ticket contient les informations suivantes:

Ticket ::= [APPLICATION 1] SEQUENCE {
    tkt-vno [0] INTEGER (5),
    realm____[1] Realm,
    sname____[2] PrincipalName,
    enc-part_[3] EncryptedData -- EncTicketPart
}
-- Partie chiffrée du ticket
EncTicketPart ::= [APPLICATION 3] SEQUENCE {
    flags______________[0] TicketFlags,
    key________________[1] EncryptionKey,
    crealm_____________[2] Realm,
    cname______________[3] PrincipalName,
    transited__________[4] TransitedEncoding,
    authtime___________[5] KerberosTime,
    starttime__________[6] KerberosTime OPTIONAL,
    endtime____________[7] KerberosTime,
    renew-till_________[8] KerberosTime OPTIONAL,
    caddr______________[9] HostAddresses OPTIONAL,
    authorization-data_[10] AuthorizationData OPTIONAL
}
-- champs traversés codés
TransitedEncoding ::= SEQUENCE {
tr-type__[0] Int32 -- doit être enregistré --,
contents_[1] OCTET STRING
}
TicketFlags ::= KerberosFlags
    -- reserved(0),
    -- forwardable(1),
    -- forwarded(2),
    -- proxiable(3),
    -- proxy(4),
    -- may-postdate(5),
    -- postdated(6),
    -- invalid(7),
    -- renewable(8),
    -- initial(9),
    -- pre-authent(10),
    -- hw-authent(11),
-- les flags suivants sont nouveaux depuis la RFC 1510
    -- transited-policy-checked(12),
    -- ok-as-delegate(13)

tkt-vno Spécifie le numéro de version pour le format de ticket. Ce document décrit la version 5
realm Spécifie le domaine qui a produit un ticket. Sert à identifier la partie de domaine de l'identifiant de principal du serveur. Comme un serveur Kerberos ne peut produire de tickets que pour des serveurs au sein de son domaine, les deux seront toujours identiques.
sname Spécifie tous les composants de la partie nom de l'identité du serveur, incluant les parties qui identifient une instance spécifique d'un service.
enc-part Contient le codage chiffré de la séquence EncTicketPart. Il est chiffré avec la clé partagée par Kerberos et le serveur d'extrémité (la clé secrète du serveur), en utilisant une clé de valeur d'utilisation de 2.
flags Indique lesquelles des diverses options ont été utilisées ou demandées lorsque le ticket a été produit. La signification des flags est la suivante:

0 (Réserved)
1 (forwardable) Le flag FORWARDABLE n'est normalement interprété que par le TGS, et peut être ignoré par les serveurs d'extrémité. Lorsqu'il est mis, ce flag dit au TGS qu'il est ok pour produire un nouveau TGT avec une adresse réseau différente fondée sur le ticket présenté.
2 (forwarded) Lorsque mis, ce flag indique que le ticket a été transmis ou a été produit sur la base d'une authentification impliquant un TGT transmis.
3 (proxiable) Normalement interprété que par le TGS et est identique que FORWARDABLE, excepté qu'il dit au TGS que seuls des non-TGT peuvent être produits avec des adresses réseau différentes.
4 (proxy) Indique que ce ticket a été mandaté
5 (may-postdate) Normalement interprété que par le TGS et indique qu'un ticket post-daté peut être produit sur la base de ce TGT.
6 (postdated) Indique que ce ticket est post-daté
7 (invalid) Indique que ce ticket est invalide, et qu'il doit être validé par le KDC avant utilisation.
8 (renewable) Normalement interprété que par le TGS et peut être utilisé pour obtenir un ticket de remplacement qui expire à une date ultérieur.
9 (initial) Indique que ce ticket a été produit en utilisant le protocole d'AS, et non pas produit sur la base d'un TGT.
10 (pre-authent) Indique que durant l'authentification initiale, le client a été authentifié par le KDC avant la production d'un ticket.
11 (hw-authent) Indique que le protocole utilisé pour l'authentification initiale exige l'utilisation d'un matériel.
12 (transited-policy-checked) Indique que le KDC pour le domaine a vérifié le champ de transit par rapport à une politique définie par le domaine en matière de certificateurs de confiance. Si ce flag est à 0, le serveur d'application doit alors vérifier le champ de transit lui-même, et s'il est incapable de le faire, il doit rejeter l'authentification. Si le flag est à 1, le serveur d'application peut alors s'affranchir de la vérification.
13 (ok-as-delegate) Indique que le serveur ( et non le client ) spécifié dans le ticket a été déterminé par la politique du domaine comme étant un receveur de délégation convenable. Un client peut utiliser la présence de ce flag pour l'aider à décider de déléguer des accréditifs à ce serveur.
14-31 (reserved) Réservé

key Ce champ existe dans le ticket et la réponse du KDC et il est utilisé pour passer la clé de session Kerberos au serveur d'application et au client.
crealm Ce champ contient le nom du domaine dans lequel le client est enregistré et dans lequel l'authentification initiale a eu lieu.
cname Ce champ contient la partie nom de l'identifiant de principal du client.
transited Ce champ donne la liste des noms des domaines Kerberos qui ont pris part à l'authentification de l'utilisateur à qui ce ticket a été produit. Il ne spécifie par l'ordre dans lequel les domaines ont été traversés. Quand les noms des CA sont à incorporer dans le champ de transit ( comme spécifié pour certaines extensions au protocole ), les noms X.500 des CA devraient être transposé en éléments dans ce champ en utilisant la transposition définis dans la rfc2253.
authtime Ce champ indique l'heure de l'authentification initiale du principal désigné. C'est l'heure de production du ticket original sur lequel est fondé ce ticket.
starttime Ce champ dans le ticket spécifie l'heure après laquelle le ticket sera valide. Avec le champ endtime, ce champ spécifié la durée de vie du ticket. S'il est absent, le champ authtime devrait alors être utilisé à la place pour déterminer la durée de vie du ticket.
endtime Ce champ contient l'heure après laquelle le ticket ne sera plus honoré.
renew-till Ce champ n'est présent que dans les ticket qui on le flag RENEWABLE mis. Indique l'heure de fin maximum qui peut être incluse dans un renouvellement. Il peut aussi être vu comme l'heure d'expiration absolue pour le ticket, y compris pour les renouvellements.
caddr Ce champ dans un ticket contient zéro (s'il est omis) ou plusieurs adresses d'hôte. Ce sont les adresses à partir desquelles le ticket peut être utilisé. S'il n'y a pas d'adresse, le ticket peut être utilisé à partir de toute localisation. La décision du KDC de produire, ou par le serveur d'extrémité d'accepter des tickets sans adresse est une décision de politique qui est laissée à Kerberos et aux administrateurs de service d'extrémité; ils peuvent refuser de produire ou d'accepter de tels tickets. À cause du large développement de la traduction des adresses réseau, il est recommandé que les politiques permettent la production et l'acceptation de tels tickets.

   Les adresse réseau sont incluses dans le ticket pour rendre plus difficile à un agresseur d'utiliser des accréditifs volés. Comme la clé de session n'est pas envoyée sur le réseau en clair, les accréditifs ne peuvent pas être volés simplement en écoutant le réseau; un agresseur doit gagner l'accès à une clé de session ( peut-être à travers des failles de la sécurité du système d'exploitation ou une session non surveillée d'un utilisateur négligeant) pour utiliser des tickets volés.

   Noter que l'adresse réseau à partir de laquelle une connexion est reçue ne peut pas être déterminée de façon fiable. Même si elle pouvant l'être, un agresseur qui a compromis la workstation du client pourrait utiliser les accréditifs à partir de là Inclure les adresses réseau ne fait que rendre plus difficile, mais pas impossible, à un agresseur de sortir avec des accréditifs volés et de les utiliser ensuite à partir d'un localisation sûre.

authorization-data Ce champ est utilisé pour passer les données d'autorisation du principal au nom duquel un ticket a été produit au service d'application. Si aucune données d'autorisation n'est incluse, ce champ sera laissé de côté. L'expérience nous montre que le nom de ce champ prête à confusion, et un meilleur nom serait "restrictions".

   Ce champ contient des restrictions à toute autorité obtenue sur la base d'une authentification utilisant le ticket. Il est possible à tout principal en possession d'accréditifs d'ajouter des entrées au champ de données d'autorisation car ces entrées prolongent les restrictions qui peuvent être faites avec le ticket. De telles additions peuvent être faites en spécifiant les entrées supplémentaires lorsqu'un nouveau ticket est obtenu durant l'échange TGS, ou elle peuvent être ajoutées durant une délégation chaînée utilisant le champ de données d'autorisation de l'authentifiant.

   Les données dans ce champ peuvent être spécifiques du service d'extrémité; le champ contiendra les noms des objets spécifiques du service, et les droits de ces objets. Bien que Kerberos ne soit pas concerné par le format du contenu des sous-champs, il en porte les information de type (ad-type).

   En utilisant le champ authorization-data, un principal est capable de produire un mandat valide pour un objet spécifique. Par exemple, un client souhaitant imprimer un fichier peut obtenir qu'un mandat de serveur de fichiers soit passé au serveur d'impression. En spécifiant le nom du fichier dans le champ authorization-data, le serveur de fichiers sait que le serveur d'impression peut seulement utiliser les droits du client lorsqu.il accède au fichier particulier à imprimer.

   On peut construire un service séparé qui fournit l'autorisation ou la certification d'appartenance à un groupe en utilisant le champ authorization-data. Dans ce cas, l'entité qui accorde l'autorisation (et non l'entité autorisée) peut obtenir un ticket en son nom propre (par exemple, le ticket est produit au nom d'un serveur privilégié), et cette entité ajoute des restrictions à sa propre autorité et délègue au client l'autorité restreinte à travers un mandataire. Le client présenterait alors cet accréditif d'autorisation au serveur d'application séparément de l'échange d'authentification. Autrement, de tels accréditifs d'autorisation peuvent être incorporés dans le ticket qui authentifie l'entité autorisée, lorsque l'autorisation est authentifiée séparément en utilisant l'élément de données d'autorisation produit par le KDC.

   De même, si on spécifie le champ authorization-data d'un mandataire et qu'on laisse en blanc les adresses d'hôte, le ticket et la clé de session qui résultent peuvent être traités comme une capacité. Le champ authorization-data est facultatif et n'a pas à être inclus dans un ticket.

Spécification pour les échanges AS et TGS

Ce paragraphe spécifie le format des messages utilisés dans l'échange entre le client et le serveur Kerberos.

Définition de KRB_KDC REQ

   Le message KRB_KDC_REQ n'a pas de numéro d'étiquette d'application par lui-même. Il est incorporé dans KRB_AS_REQ ou KRB_TGS_REQ, qui ont chacune une étiquette d'application, selon que la demande est celle d'un ticket initial ou d'un ticket supplémentaire. Dans les 2 cas, le message est envoyé du client au KDC pour demander des accréditifs pour un service.

Les champs de message sont les suivants:
AS-REQ ::= [APPLICATION 10] KDC-REQ
TGS-REQ := [APPLICATION 12] KDC-REQ

KDC-REQ ::= SEQUENCE { -- NOTE: la première étiquette est [1], pas [0]
    pvno    [1] INTEGER (5) ,
    msg-type    [2] INTEGER (10 -- AS -- | 12 -- TGS --),
    padata    [3] SEQUENCE OF PA-DATA OPTIONAL -- NOTE : non vide --,
    req-body    [4] KDC-REQ-BODY
}

KDC-REQ-BODY ::= SEQUENCE {
    kdc-options    [0] KDCOptions,
    cname    [1] PrincipalName OPTIONAL -- Ne sert que dans AS-REQ --,
    realm    [2] Realm -- Domaine du serveur et aussi du client dans AS-REQ --,
    sname    [3] PrincipalName OPTIONAL, from [4] KerberosTime OPTIONAL,
    till    [5] KerberosTime,
    rtime    [6] KerberosTime OPTIONAL,
    nonce    [7] UInt32,
    etype    [8] SEQUENCE OF Int32 -- Type de chiffrement dans l'ordre de préférence --,
    addresses    [9] HostAddresses OPTIONAL,
    enc-authorization-data    [10] EncryptedData OPTIONAL -- AuthorizationData --,
    additional-tickets    [11] SEQUENCE OF Ticket OPTIONAL -- NOTE : non vide
}

KDCOptions ::= KerberosFlags
        -- reserved(0),
        -- forwardable(1),
        -- forwarded(2),
        -- proxiable(3),
        -- proxy(4),
        -- allow-postdate(5),
        -- postdated(6),
        -- unused7(7),
        -- renewable(8),
        -- unused9(9),
        -- unused10(10),
        -- opt-hardware-auth(11),
        -- unused12(12),
        -- unused13(13),
        -- 15 est réservé pour la canonisation
        -- unused15(15),
        -- 26 n'était pas utilisé dans la rfc 1510
        -- disable-transited-check(26),--
        -- renewable-ok(27),
        -- enc-tkt-in-skey(28),
        -- renew(30),
        -- validate(31)

pvno Inclus dans chaque message de protocole, et spécifie le numéro du protocole. Doit être à 5
msg-type Indique le type d'un message. Il sera presque toujours le même que l'identifiant d'application associé à un message. Il est inclus pour rendre l'identifiant plus facilement accessible à l'application. Pour le message KDC-REQ, ce type sera KRB_AS_REQ ou KRB_TGS_REQ.
padata Contient les données de pré-authentification. Les demandes de tickets supplémentaires ( KRB_TGS_REQ ) doivent contenir un padata de PA-TGS-REQ. Ce champ contient une séquence d'informations d'authentification qui peuvent être nécessaire avant que les accréditifs puissent être produits ou déchiffrés.
req-body Paramètre fictif qui délimite l'extension des champs restants. Si une somme de contrôle est à calculer dur la demande, elle est calculée sur un codage de la séquence KDC-REQ-BODY qui est dans le champ req-body.
kdc-options Ce champ apparaît dans les demandes KRB_AS_REQ et KRB_TGS_REQ et indique les flags que le client veut mettre sur les tickets ainsi que les autres informations qui vont modifier le comportement du KDC. Lorsque c'est approprié, le nom d'une option peut être le même que celui du flag qui est mis par cette option. Bien que dans la plupart des cas le bit dans le champ options soit le même que celui du champ flags, cela n'est pas garanti, aussi il n'est pas acceptable de simplement copier le champ options dans le champ flags. Diverses vérifications doivent être faites avant qu'une option ne soit honorée.

   Le cahmp kdc_options est un champ binaire, où les options choisies sont indiquées par le bit mis, et les option non choisies et les champs réservés ne sont pas mis. La signification des options est la suivante:

0 (Réserved)
1 (FORWARDABLE) Indique que le tickest est fournis avec le flag forwardable mis. Ne peut seulement être mis dans la demande initiale, ou dans une sous-demande si le TGT sur lequel il est basé est également forwardable.
2 (FORWARDED) Seulement spécifié dans une demande au TGS et sera honoré si le TGT dans la demande a le bit FORWARDABLE mis.
3 (PROXIABLE) Indique que le tickest est fournis avec le flag proxiable mis. Ne peut seulement être mis dans la demande initiale, ou dans une sous-demande si le TGT sur lequel il est basé est également proxiable.
4 (PROXY) Indique que c'est une demande pour un proxy et sera honoré si le TGT dans la demande a le bit PROXIABLE mis.
5 (ALLOW-POSTDATE) Indique que le ticket à fournir doit avoir MAY-POSTDATE mis. Ne peut seulement être mis dans la demande initiale, ou dans une sous-demande si le TGT sur lequel il est basé est également MAY-POSTDATE.
6 (POSTDATED) Indique que c'est une demande pour un ticket post-daté. Sera honoré si le TGT sur lequel il est basé a son MAY-POSTDATE mis. Le ticket résultant aura également le flag INVALID mis.
7 (RESERVED)
8 (RENEWABLE) Indique que le ticket à fournir doit avoir son flag RENEWABLE mis. Peut seulement être mis dans la demande initiale, ou dans une sous-demande si le TGT sur lequel il est basé est également renewable
9 (RESERVED)
10 (RESERVED)
11 (RESERVED)
12-25 (RESERVED)
26 (DISABLE-TRANSITED-CHECK) Indique au KDC de ne pas vérifier le champ transited
27 (RENEWABLE-OK) Indique qu'un ticket renouvelable sera acceptable si un ticket avec la durée de vie requise ne peut autrement être fourni, auquel cas un ticket renouvelable peut être produit avec un renew-till égal à l'heure de fin demandée.
28 (ENC-TKT-IN-SKEY) N'est utilisée que par le TGS. indique que le ticket pour le serveur d'extrémité est à chiffrer avec la clé de session provenant du TGT supplémentaire fourni.
29 (RESERVED)
30 (RENEW) N'est utilisé que par le TGS. Indique que la demande est pour un renouvellement. Le ticket fournis est chiffré dans la clé secrète pour le serveur sur lequel il est valide. Ne sera honoré que si le ticket à renouveler a son flag RENEWABLE mis et si renew-till n'est pas passé.
31 (VALIDATE) N'est utilisé que par le TGS. Indique que la demande est pour un ticket post-daté à valider.

cname et sname Ces champs sont les mêmes que ceux décrits pour le ticket plus haut. Le sname ne peut être absent que lorsque l'option ENC-TGT-IN-SKEY est spécifié. Si le sname est absent, le nom du serveur est tiré du nom du client dans le ticket passé comme ticket supplémentaire.
enc-authorization-data Si présent (et ne peut l'être que sous la forme de TGS_REQ), est un codage des authorizations désirées chiffré avec la sous-clé de session si elle est présent dans l'authentifiant, ou avec la clé de session dans le TGT (l'authentifiant et le TGT viennent tous deux du champ padata dans le KRB_TGS_REQ). La valeur d'utilisation de clé utilisée pour le chiffrement est 5 si une sous-clé de session est utilisée, ou 4 si la clé de session est utilisée.
realm Spécifie la partie domaine de l'identifiant de principal du serveur. Dans l'échange AS, c'est aussi la partie domaine de l'identifiant de principal du client.
from Ce champ est inclus dans les demandes de ticket KRB_AS_REQ et KRB_TGS_REQ lorsque le ticket demandé est à post-dater. Il spécifie l'heure de début de validité pour le ticket demandé. Si omis, le KDC devrait uiliser l'heure en cours.
till Contient la date d'expiration demandée par le client dans une demande de ticket. Il n'est pas facultatif, mais si l'heure de fin demandée est "19700101000000Z", le ticket aura l'heure maximum permise par le KDC.
rtime Ce champ est l'heure de renew-till envoyée au KDC dans une demande de ticket. facultatif.
nonce Fait partie de la demande et de la réponse du KDC. Il est destiné à contenir un nombre aléatoire généré par le client. Si le même nombre est inclus dans la réponse chiffrée provenant du KDC, cela montre à l'évidence que la réponse est fraîche et n'a pas été répétée par un attaquant. Les noms occasionnels ne doivent jamais être réutilisés.
etype Ce champ spécfie l'algorithme de chiffrement désiré à utiliser dans la réponse.
addresses Ce champ est inclus dans la demande de ticket, et il est facultativement inclus dans les demandes de tickets supplémentaire provenant du serveur d'allocation de tickets. Il spécifie les adresse à partir desquelles le ticket demandé doit être valide. Normalement, il inclut les adresse de l'hôte du client. Si un proxy est demandé, ce champ contiendra d'autres adresse. Ce champ est généralement copié par le KDC dans le champ cappr du ticket résultant.
additional-tickets Des tickets supplémentaire peuvent être facultativement inclus dans une demande au TGS. Si l'option ENC-TGT-IN-SKEY a été spécifiée, la clé de session provenant du ticket supplémentaire sera alors utilisée à la place de la clé du serveur pour chiffrer le nouveau ticket. Lorsque l'option ENC-TKT-IN SKEY est utilisée pour l'authentification d'utilisateur à utilisateur, ce ticket supplémentaire peut être un TGT produit par le domaine local ou un TGT inter-domaine produit pour le domaine du KDC en cours par un KDC distant. Si plus d'une option exigeant des tickets supplémentaire a été spécifiée, les tickets supplémentaire sont alors utilisés dans l'ordre spécifié par l'ordre des bits des options bits.

Définition de KRB_KDC_REP

   Le format de message KRB KDC_REP est utilisé pour la réponse du KDC à une demande initiale ( AS ) ou à une demande ultérieure ( TGS ). Il n'y a pas de type de message pour KRB_KDC_REP. Le type sera KRB_AS_REP ou KRB_TGS_REP. La clé utilisée pour chiffrer la partie de texte chifrée de la réponse dépend du type de message. Pour KRB_AS_REP, le texte est chiffré avec la clé secrète du client, et le numéro de version de clé du client est inclus dans le numéro de version de clé pour les données chiffrées. Pour KRB_TGS_REP, et texte est chiffré avec la clé de session provenant du TGT utilisé dans la demande. Dans ce cas, aucun numéro de version ne sera présent dans la séquence EncryptedData.

Les champs de message sont les suivants:
AS-REP ::= [APPLICATION 11] KDC-REP
TGS-REP ::= [APPLICATION 13] KDC-REP
KDC-REP ::= SEQUENCE {
    pvno    [0] INTEGER (5),
    msg-type    [1] INTEGER (11 -- AS -- | 13 -- TGS --),
    padata    [2] SEQUENCE OF PA-DATA OPTIONAL -- NOTE : non vide --,
    crealm    [3] Realm,
    cname    [4] PrincipalName,
    ticket    [5] Ticket,
    enc-part    [6] EncryptedData -- EncASRepPart ou EncTGSRepPart, selon le cas
}
EncASRepPart ::= [APPLICATION 25] EncKDCRepPart
EncTGSRepPar ::= [APPLICATION 26] EncKDCRepPart
EncKDCRepPart ::= SEQUENCE {
    key    [0] EncryptionKey,
    last-req    [1] LastReq,
    nonce    [2] UInt32,
    key-expiration    [3] KerberosTime OPTIONAL,
    flags    [4] TicketFlags,
    authtime    [5] KerberosTime,
    starttime    [6] KerberosTime OPTIONAL,
    endtime    [7] KerberosTime,
    renew-till    [8] KerberosTime OPTIONAL,
    srealm    [9] Realm,
    sname    [10] PrincipalName,
    caddr    [11] HostAddresses OPTIONAL
}
LastReq ::= SEQUENCE OF SEQUENCE {
    lr-type    [0] Int32,
    lr-value    [1] KerberosTime
}

pvno et msg-type Décrits dans KRB_KDC_REQ. msg-type est KRB_AS_REP ou KRB_TGS_REP
padata Décrits dans KRB_KDC_REQ. Une utilisation possible est de coder une chaîne salt à utiliser avec un algorithme de string-to-key. C'est utile pour faciliter les transitions si un nom de domaine doit changer; dans un tel cas, toutes les entrées déduites de mot de passe existantes dans la base de données Kerberos auraient un flag marquant qu'elles ont besoin d'une chaîne salt spécial jusqu'au prochain changement de mot de passe.
crealm, cname, srealm, et sname Décrits dans KRB_KDC_REQ.
ticket C'est le ticket nouvellement produit
enc-part Ce champ est un fourre-tout pour le texte chiffré et les informations qui s'y rapportent, qui forme la partie chiffrée d'un message. La description de la partie chiffrée du message suit chaque apparition de ce champ.

   La valeur d'utilisation de clé pour le chiffrement de ce champ est 3 dans un message AS-REP, en utilisant la clé à long-terme du client ou une autre clé choisie via des mécanismes de pré-authentification. Dans un message TGS-REP, la valeur d'utilisation de clé est 8 si la clé de session TGS est utilisée, ou 9 si une sous-clé d'authentifiant TGS est utilisée.

key Ce champ est le même que celui décrit au paragraphe ticket
last-req Ce champ est retourné par le KDC et spécifie l'heure de la dernière demande d'un principal. Selon les informations disponibles, ce peut être la dernière fois qu'une demande de TGT a été faite, ou la dernière fois qu'une demande fondée sur un TGT a réussi. I peut aussi couvrir tous les serveurs d'un domaine, ou juste un serveur particulier. Certaines implémentations peuvent afficher ces informations à l'utilisateur pour aider à découvrir des utilisations non autorisées d'une identité. C'est d'un esprit similaire à l'affichage de la dernière connexion affichée à la connexion dans les systèmes en tamps partagé.
lr-typeCe champ indique comment interpréter le champ lr-value suivant. Les valeurs négatives indiquent que ces informations n'appartiennent qu'au serveur qui répond. Les valeurs non négatives appartiennent à tous les serveurs pour le domaine. Les valeurs possibles sont:

0 Aucune information n'est portée par le sous-champ lr-value.
1 le sous-champ lr-value est l'heure de la dernière demande initiale pour un TGT.
2 Le sous-champ lr-value est l'heure de la dernière demande initiale.
3 Le sous-champ lr-value est l'heure de la production du plus récent TGT utilisé
4 Le sous-champ lr-value est l'heure de la demande du dernier renouvellement
5 Le sous champ lr-value est l'heure de la dernière demande (de tout type).
6 Le sous-champ lr-value est l'heure de l'arrivée à expiration du mot de passe.
7 Le sous-champ lr-value est l'heure de l'arrivée à expiration du compte.

lr-value Ce champ contient l'heure de la dernière demande. L'heure doit être interprété conformément au contenu du sous-champ lr-type qui l'accompagne.
nonce Décrits dans KRB_KDC_REQ.
key-expiration Ce champ fait partie de la réponse du KDC et spécifie l'heure à laquelle la clé secrète du client va arriver à expiration. L'expiration peut être le résultat du vieillissement d'un mot de passe ou de l'expiration d'un compte. S'il est présent, il devrait être réglé au plus tôt de l'expiration de la clé de l'utilisateur et de l'expiration du compte. L'utilisation de ce champ est déconseillé, et le champ last-req devrait être utilisé à la place pour porter ces informations. Ce champ sera normalement laissé en dehors de la réponse TGS car la réponse à une demande de TGS est chiffrée avec une clé de session et aucune information client n'a à être restituée de la base de données du KDC. Il appartient au client d'application ( généralement le programme de connexion) de prendre les mesures appropriées si l'heure d'expiration est imminente.
flags, authtime, starttime, endtime, renew-till et caddr Ces champs sont des duplications de ceux qui figurent dans la portion chiffré du ticket joint, et ils sont fournis pour que le client puisse vérifier qu'ils correspondent à la demande prévue et afin d'aider à une mise en mémoire cache appropriée du ticket. Si le message est du type KRB_TGS_REP, le champ caddr ne sera rempli que si la demande était pour un proxy ou un ticket transmis, ou si l'utilisateur substitue un sous-ensemble des adresses venant du TGT. Si les adresses demandées par le client ne sont pas présentes ou pas utilisées, les adresses contenues dans le ticket devront alors être les mêmes que celles incluses dans le TGT.

Spécifications de message client-serveur

Ce paragraphe spécifie le format des messages utilisée pour l'authentification du client auprès du serveur d'application.

Définition de KRB_AP_REQ

   Le message KRB_AP_REQ contient le numéro de version du protocole Kerberos, le type de message KRB_AP_REQ, un champ d'options pour indiquer toutes les options utilisée, et le ticket et l'authentifiant eux-mêmes. Le message KRB_AP_REQ est souvent désigné comme un en-tête d'authentification.

AP-REQ ::= [APPLICATION 14] SEQUENCE {
    pvno    [0] INTEGER (5),
    msg-type    [1] INTEGER (14),
    ap-options    [2] APOptions,
    ticket    [3] Ticket,
    authenticator    [4] EncryptedData -- Authentifiant
}
APOptions ::= KerberosFlags
    -- reserved(0),
    -- use-session-key(1),
    -- mutual-required(2)

pvno et msg-type Décrits dans KRB_KDC_REQ. msg-type estKRB_AP_REQ
ap-options Ce champ apparaît dans la demande d'application KRB_AP_REQ et affecte la façon dont la demande est traitée. C'est un champ binaire, où les options choisies sont indiquées par le bis mis, et les options non choisies à 0. La signification des options est la suivante:

(reserved) 1
(use-session-key) Indique que le ticket que présente le client à un serveur est chiffré avec la clé de session venant du TGT du serveur. Quand cette option n'est pas spécifiée, le ticket est chiffré avec la clé secrète du serveur. 2
(mutual-required) Dit au serveur que le serveur exige l'authentification mutuele, et qu'il doit répondre par un message KRB_AP_REP. 3-31
(reserved)

ticket Ce champ est un ticket authentifiant le client auprès du serveur
authenticator Contient l'authentifiant chiffré, qui inclut le choix d'une sous-clé par le client.

   L'authentifiant chiffré est inclus dans le AP-REQ; il certifie à un serveur que l'envoyeur a une connaissance récente de la clé de chiffrement du ticket d'accompagnement, pour aider le serveur à détecter les répétitions. Il aide aussi au choix d'une vraie clé de session à utiliser dans cette session. Le codage DER de ce qui suit est chiffré avec la clé de session du ticket, avec une valeur d'utilisation de clé de 11 dans les échanges d'application normaux, ou 7 lorsque utilisée comme champ PA-TGS-REQ PA-DATA d'un échange TGS-REQ.

-- Authentifiant non chiffré
Authenticator ::= [APPLICATION 2] SEQUENCE {
    authenticator-vno    [0] INTEGER (5),
    crealm    [1] Realm,
    cname    [2] PrincipalName,
    cksum    [3] Checksum OPTIONAL,
    cusec    [4] Microseconds,
    ctime    [5] KerberosTime,
    subkey    [6] EncryptionKey OPTIONAL,
    seq-number    [7] UInt32 OPTIONAL,
    authorization-data    [8] AuthorizationData OPTIONAL
}

authenticator-vno Spécifie le numéro de version du format de l'authentifiant. Vaut 5
crealm et cname Décrit dans le paragraphe ticket
cksum Contient un checksum des données d'application qui accompagnent le KRB_AP_REQ. calculée en utilisant une valeur d'utilisation de clé de 10 dans les échanges d'application normaux, ou 6 lorsqu'utilisé dans le champ TGS-REQ PA-TGS-REQ AP-DATA
cusec Ce champ contient la partie microsecondes du timestamp du client. sa valeur va de 0 à 999999.
ctime Ce champ contient l'heure en cours sur l'hôte du client
subkey Ce champ contient le choix du client d'une clé de chiffrement à utiliser pour protéger cette session d'application spécifique. Sauf si une application spécifie autre chose, si ce champ est laissé de côté, la clé de session venant du ticket sera utilisée.
seq-number Ce champ optionnel comporte le numéro de séquence initial à utiliser par KRB_PRIV ou KRB_SAFE lorsque les numéros de séquence sont utilisés pour détecter les répétitions.

   Il peut aussi être utilisé par des messages spécifiques de l'application. Lorsqu'il est inclus dans l'authentifiant, ce champ spécifie le numéro de séquence initiale pour les messages du client au serveur. Lorsqu'il est inclus dans le message KRB_PRIV ou KRB_SAFE, il est incrémenté de un après l'envoi de chaque message. Les numéros de séquence sont dans la gamme de 0 à 2^32 -1 puis reviennent à 0.

   Pour que les numéros de séquence prennent adéquatement en charge la détection des répétitions, ils devraient être non-répétitifs, même à travers les frontières de connexion. Le numéro de séquence initiale devrait être aléatoire et uniformément distribué à travers l'espace complet des numéros de séquence possibles, de sorte qu'il ne puisse pas être deviné par un agresseur et de sorte que lui et les numéros de séquence successifs ne répètent pas d'autres séquences. Au cas où plus de 2^32 messages devraient être générés dans une série de message KRB_PRIV ou KRB_SAFE, un changement de clé devrait être effectué avant que les numéros de séquence soient réutilisés avec la même clé de chiffrement.

authorization-data Ce champ est décrit au paragraphe ticket. il est optionnel et n'apparaît que lorsque des restrictions supplémentaires sont à mettre à l'utilisation d'un ticket, au-delà de celles portées par le ticket lui-même.

Définition de KRB_AP_REP

   Le message KRB_AP_REP contient le numéro de version du protocole Kerberos, le type de message, en un timestamp chiffré. Le message est envoyé en réponse à une demande d'application ( KRB_AP_REQ ) pour laquelle l'option d'authentification mutuelle a été choisie dans le champ ap-options.

AP-REP ::= [APPLICATION 15] SEQUENCE {
    vno     [0] INTEGER (5),
    sg-type    [1] INTEGER (15),
    nc-part    [2] EncryptedData -- EncAPRepPart
}
EncAPRepPart ::= [APPLICATION 27] SEQUENCE {
    time    [0] KerberosTime,
    usec    [1] Microseconds,
    ubkey    [2] EncryptionKey OPTIONAL,
    eq-number    [3] UInt32 OPTIONAL
}

nc-part La partie codée EncAPRepPart est chiffrée avec la clé de session partagée du ticket. Le champ de sous-clé facultatif peut être utilisé dans une négociation arrangée par l'application pour choisir une clé de session par association.
pvno et msg-type Décrits dans KRB_KDC_REQ. msg-type estKRB_AP_REP
enc-part Décrits dans KRB_KDC_REQ. Est calculé avec une valeur d'utilisation de clé de 12
ctime Heure courant sur l'hôte du client
cusec partie micro-seconde du timestamp
subkey Contient une clé de chiffrement à utiliser pour protéger cette session d'application spécifique.
seq-number Décrit au paragraphe ticket

Spécification du message KRB_SAFE

   Ce paragraphe spécifie le format d'un message qui peut être utilisé par l'un ou l'autre côté ( client ou serveur ) d'une application pour envoyer un message inaltérable à son homologue. Il suppose qu'une clé de session ait été échangée précédemment. Le message KRB_SAFE contient des données d'utilisateur avec une somme de contrôle à l'épreuve des collisions chiffrée avec la dernière clé de chiffrement négociée via des sous-clés, ou avec la clé de session si aucune négociation n'est intervenue.

Les champs de message sont les suivants:
KRB-SAFE ::= [APPLICATION 20] SEQUENCE {
    pvno    [0] INTEGER (5),
    msg-type    [1] INTEGER (20),
    safe-body    [2] KRB-SAFE-BODY,
    cksum    [3] Checksum
}
KRB-SAFE-BODY ::= SEQUENCE {
    user-data    [0] OCTET STRING,
    timestamp    [1] KerberosTime OPTIONAL,
    usec    [2] Microseconds OPTIONAL,
    seq-number    [3] UInt32 OPTIONAL,
    s-address    [4] HostAddress,
    r-address    [5] HostAddress OPTIONAL
}

pvno et msg-type Décrits dans KRB_KDC_REQ. msg-type est KRB_SAFE
safe-body Ce champ est un fourre tout pour le corps du message KRB_SAFE
cksum Ce champ contient le checksum des données d'application, calculée avec une valeur d'utilisation de clé de 15. La somme de contrôle est calculée sur le codage de la séquence KRB-SAFE. D'abord, le cksum est mis à un type zéro, valeur de longueur zéro, et la somme de contrôle est calculée sur le codage de la séquence KRB-SAFE. Puis la somme de contrôle est réglée au résultat de ce calcul. Finalement, la séquence KRB-SAFE est codée à nouveau.
user-data Ce champ fait partie des messages KRB_SAFE et KRB_PRIV, et contient les données spécifiques de l'application qui sont passées de l'envoyeur au receveur.
timestamp Ce champ fait partie des messages KRB_SAFE et KRB_PRIV. Heure courante le l'émetteur.
usec partie micro-seconde du timestamp
seq-number Ce champ est décrit au paragraphe ticket
s-address Spécifie l'adresse utilisée par l'eméteur du message
r-address Spécifie l'adresse utilisée par le receveur du message. Il peut être omis pour certaines utilisations ( comme les protocoles de diffusion ), mais le receveur peut arbitrairement rejeter de tels messages. Ce champ, avec s-address, peut être utilisé pour aider à détecter des messages qui on été incorrectement ou malicieusement délivrés à un mauvais receveur.

Spécification du message KRB_PRIV

   Ce paragraphe spécifie le format d'un message qui peut être utilisé par un client et un serveur d'application pour envoyer en toute sécurité et confidentialité un message à son homologue. Il suppose qu'une clé de session ait précédemment été échangée (par exemple, en utilisant les message KRB_AP_REQ/KRB_AP_REP. Le message KRB_PRIV contient des données d'utilisateur chiffrées avec la clé de session.

Les champs de messages sont les suivant:
KRB-PRIV ::= [APPLICATION 21] SEQUENCE {
    pvno    [0] INTEGER (5),
    msg-type [1] INTEGER (21), -- NOTE : Il n'y a pas d'étiquette [2]
    enc-part    [3] EncryptedData -- EncKrbPrivPart
}
EncKrbPrivPart ::= [APPLICATION 28] SEQUENCE {
    user-data    [0] OCTET STRING,
    horodatage    [1] KerberosTime OPTIONAL,
    usec    [2] Microseconds OPTIONAL,
    seq-number    [3] UInt32 OPTIONAL,
    s-address    [4] HostAddress -- adresse de l'envoyeur
    r-address    [5] HostAddress OPTIONAL -- adresse du receveur
}

pvno et msg-type Décrits dans KRB_KDC_REQ. msg-type est KRB_PRIV
enc-part Ce champ détient un codage de la séquence EncKrbPrivPart chiffrée avec le clé de session, avec une valeur d'utilisation de clé de 13. Ce codage chiffré est utilisé pour le champ enc-part du message KRB-PRIV
user-data, horodatage, usec, s-address, et r-address Décrits dans KRB_SAFE
seq-number Décrits dans la section ticket

Spécification du message KRB_CRED

   Ce paragraphe spécifie le format d'un message qui peut être utilisé pour envoyer des accréditifs Kerberos d'un principal à un autre. Il est présenté ici pour encourager l'utilisation d'un mécanisme commun par les applications lors de la transmission des tickets ou la fourniture de mandataires aux serveurs subordonnées. Il suppose qu'une clé de session a déjà été échangée, peut-être en utilisant les message KRB_AP_REQ/KRB_AP_REP. Le message KRB_CRED contient une séquence de tickets à envoyer et les informations nécessaires pour utiliser les tickets, comportant la clé de session de chacun. Les informations nécessaires pour utiliser les tickets sont chiffrées avec une clé de chiffrement échangée précédemment ou transférée à l'aide du message KRB_CRED.

Les champs de message sont les suivants:
KRB-CRED ::= [APPLICATION 22] SEQUENCE {
    pvno    [0] INTEGER (5),
    msg-type    [1] INTEGER (22),
    tickets    [2] SEQUENCE OF Ticket,
    enc-part    [3] EncryptedData -- EncKrbCredPart
}
EncKrbCredPart ::= [APPLICATION 29] SEQUENCE {
    ticket-info    [0] SEQUENCE OF KrbCredInfo,
    nonce    [1] UInt32 OPTIONAL,
    timestamp    [2] KerberosTime OPTIONAL,
    usec    [3] Microseconds OPTIONAL,
    s-address    [4] HostAddress OPTIONAL,
    r-address    [5] HostAddress OPTIONAL
}
KrbCredInfo ::= SEQUENCE {
    key    [0] EncryptionKey,
    prealm    [1] Realm OPTIONAL,
    pname    [2] PrincipalName OPTIONAL,
    flags    [3] TicketFlags OPTIONAL,
    authtime    [4] KerberosTime OPTIONAL,
    starttime    [5] KerberosTime OPTIONAL,
    endtime    [6] KerberosTime OPTIONAL,
    renew-till    [7] KerberosTime OPTIONAL,
    srealm    [8] Realm OPTIONAL,
    sname    [9] PrincipalName OPTIONAL,
    caddr    [10] HostAddresses OPTIONAL
}

pvno et msg-type Décrits dans KRB_KDC_REQ. msg-type est KRB_PRIV
tickets Ce sont les tickets obtenus du KDC pour utilisation spécifique par le receveur. Les tickets successifs sont appariés avec la séquence KrbCredInfo correspondante de enc-part du message KRB-CRED
enc-part Ce champ étient un codage de la séquence EncKrbCredPart chiffrée avec la clé de session partagée par l'envoyeur et le receveur prévu, avec une valeur d'utilisation de 14. Ce codage chiffré est utilisé pour le champ enc-part du message KRB-CRED.
nonce Si elle en a la capacité, une application peut exiger l'inclusion d'un nom occasionnel généré par le receveur du message.Si la même valeur est incluse comme nom occasionnel danse le message, cela donne la preuve que le message est frais et n'a pas été répété par un agresseur.
timestamp et usec Ces champs spécifient l'heure à laquelle le message KRB-CRED a été généré. L'heure est utilisée pour fournir l'assurance que le message est frais.
s-address et r-address Décrit dans KRB_SAFE
key Ce champ existe dans le ticket correspondant passé par le message KRB-CRED et est utilisé pour passer la clé de session de l'envoyeur au destinataire prévu.
prealm et pname facultatifs. Nom et domaine de l'entité de principal délégué.
lags, authtime, starttime, endtime, renew-till, srealm, sname, et caddr facultatifs. Ces champs contiennent les valeurs des champs correspondants dans le ticket trouvé dans le champ ticket. Les descriptions des champs sont identiques aux descriptions dans le messages KDC-REP.

Spécification du message KRB_ERROR

   Ce paragraphes spécifie le format du message KRB_ERROR. Les champs inclus dans le message sont destinés à retourner autant d'informations que possible sur l'erreur. On ne s'attend pas à ce que toutes les informations exigées par les champs soient disponibles pour tous.les types d'erreur. Si les informations appropriées ne sont pas disponibles lors de la composition du message, le champ correspondant sera laissé de côté pour ce message. Noter que comme le message KRB_ERROR n'est pas protégé en intégrité, il est assez possible à un attaquant de le synthétiser ou le modifier. En particulier, cela signifie que le client ne devrait pas utiliser ces champs dans ce message pour des besoins critiques pour la sécurité, comme le réglage d'une horloge système ou la génération d'un authentifiant frais. Le message peut cependant être utile pour informer un utilisateur des raisons d'un échec.

Les champs de message sont les suivants:
KRB-ERROR ::= [APPLICATION 30] SEQUENCE {
    pvno    [0] INTEGER (5),
    msg-type    [1] INTEGER (30),
    ctime    [2] KerberosTime OPTIONAL,
    cusec    [3] Microseconds OPTIONAL,
    stime    [4] KerberosTime,
    susec    [5] Microseconds,
    error-code    [6] Int32,
    crealm    [7] Realm OPTIONAL,
    cname    [8] PrincipalName OPTIONAL,
    realm    [9] Realm -- domaine du service --,
    sname    [10] PrincipalName -- domaine du service --,
    e-text    [11] KerberosString OPTIONAL,
    e-data    [12] OCTET STRING OPTIONAL
}

pvno et msg-type Décrits dans KRB_KDC_REQ. msg-type est KRB_ERROR
ctime et cusec Ces champs sont décris dans KRB_AP REP.Si les valeurs de ces champs sont connues de l'entité qui génère l'erreur, ils devraient être remplis dans la KRB-ERROR. Se les valeurs ne sont pas disponibles, ces champs peuvent être omis.
stime Ce champ contient l'heure en cours au serveur. Il est du type KerberosTime.
susec Ce champ contient la partie microseconde du timestamp.
error-code Ce champ contient le code d'erreur retourné par Kerberos ou le serveur.
crealm et cname Ces champs sont décrit au paragraphe ticket. Lorsque l'entité qui génère l'erreur connaît ces valeur, elle devraient être remplies dans le KRB-ERROR. Si les valeurs ne sont pas connues, les champs crealm et cname devraient être omis.
realm et sname Ces champs sont décrits dans le paragraphe ticket
e-text Ce champ contient du texte supplémentaire pour aider à expliquer le code d'erreur associé à l'échec de demande.
e-data Ce champ contient des données supplémentaires sur l'erreur à utiliser par l'application. Si le codes d'erreur est KDC_ERR_PREAUTH_REQUIRED, le champ e-data contiendra alors un odage de la séquence des champs padata, chacun correspondant à une méthode acceptable de pré-authentification et contenant facultativement des données pour la méthode: METHOD-DATA ::= SEQUENCE OF PA-DATA

   Pour les codes d'erreur définis dans le présent document autres que KDC_ERR_PREAUTH_REQUIRED, le format et le contenu du champ e-data sont définis par l'implémentation. De même, pour les codes d'erreur futurs, le format et le contenu du champ e-data sera défini par l'implémentation sauf spécification contraire. Qu'ils soient définis par l'implémentation ou dans un document futur, le champ e-data peut prendre la forme de TYPED-DATA:

TYPED-DATA ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE {
    data-type    [0] Int32,
    data-value    [1] OCTET STRING OPTIONAL
}

Noms de domaine

   Bien que les noms de domaine soient codés comme des GeneralStrings et que techniquement un domaine puisse choisir le nom qu'il veut, l'intéropérabilité à travers les frontières de domaine exige un accord sur la façon dont les noms de domaine sont alloués et les informations qu'ils comportent.

   Pour mettre en application ces conventions, chaque domaine doit se conformer aux conventions elles-mêmes, et il doit exiger que tout domaine avec lequel il partage des clés inter-domaine se conforme aussi aux conventions et qu'il exige la même chose de ses voisins.

   Les noms de domaine Kerberos sont sensibles à la casse. Les noms de domaine qui ne diffèrent que par la casse des caractères ne sont pas équivalents. Il y a actuellement 3 styles de noms de domaine: domaine, X500, et autre:

domain: ATHENA.MIT.EDU
X500: C=US/O=OSF
autre: NAMETYPE:rest/of.name=without-restrictions

   Les noms de style domaine doivent ressembler à des noms de domaine: Ils comportent des composants séparés par des points et ils ne contiennent ni ":" ni "/". Bien que les noms de domaine eux-mêmes ne soient pas sensibles à la casse, afin que les domaines correspondent, la casse doit aussi correspondre. Lors de l'établissement d'un nouveau nom de domaine fondé sur un nom de domaine internet, il est recommandé par convention que les caractères soient convertis en majuscules.

   Les noms X.500 contiennent le signe égal et ne peuvent pas contenir ":" avant le signe égal. Les noms de domaine pour les noms X.500 doivent être des représentations de chaîne des noms avec des composants séparés par des barres obliques. Les barres obliques en tête et en queue ne seront pas incluses. Noter que la barre oblique de séparation est cohérente avec les implémentations de Kerberos fondées sur la rfc1510, mais elle est différente du séparateur recommandé dans la rfc2253.

   Les noms qui entrent dans la catégorie autre doivent commencer par un préfixe ne contenant pas de signe égal ou point, et le préfixe doit être suivi par ":" et le reste du nom. Tous les préfixes attendent ceux qui commencent à être utilisés. Actuellement, aucun n'est alloué.

   La catégorie réservée comporte des chaînes qui n'entrent pas dans les 3 premières catégories. Tous les noms de cette catégorie sont réservés. Il est peut vraisemblable que des noms soient alloués dans cette catégorie sauf s'il y a de très forts arguments pour ne pas utiliser la catégorie autre.

   Ces règles garantissent qu'il n'y aura pas de conflit entre les divers styles de nom. Les contraintes supplémentaires suivantes s'appliquent à l'allocation de noms de domaine dans les catégories domaine et X.500: le nom d'un domaine pour les formats domaine ou X.500 doit être utilisé par l'organisation propriétaire d'un nom de domaine Internet ou d'un nom X.500, ou, dans le cas où un tel nom n'est pas enregistré, l'autorité pour utiliser un nom de domaine peut être dérivé de l'autorité du domaine parent. Par exemple, s'il n'y a pas de nom de domaine pour E40.MIT.EDU, l'administrateur du domaine MIT.EDU peut alors autoriser la création d'un domaine de ce nom.

   Ceci est acceptable parce que l'organisation à laquelle le parent est alloué est vraisemblablement aussi l'organisation autorisée à allouer des noms à ses enfants dans les systèmes de nom X.500 et domaine. Si le parent alloue un nom de domaine sans l'enregistrer aussi dans la hiérarchie de nom de domaine ou X.500, il est de la responsabilité du parent de s'assurer qu'à l'avenir il n'existe pas un nom identique au nom de domaine de l'enfant sauf s'il est alloué à la même entité comme nom de domaine.

Noms de principal

   Comme c'est le cas pour les noms de domaine, des conventions sont nécessaires pour s'assurer que tous sont d'accord sur les information impliquées par un nom de principal. Le champ name-type qui fait partie du nom de principal indique le type d'informations impliquées par le nom. Le name-type devrait être traité que comme un conseil pour interpréter la signification d'un nom. Il n'y a pas de sens à lui rechercher une équivalence. Les noms de principal qui ne diffèrent que par le name-type identifient le même principal. Le type de nom ne crée pas une partition de l'espace de nom. En ignorant le type de nom, 2 noms ne peuvent être les mêmes. Les types de nom suivants sont définis:

NT-UNKNOWN (0) Type de nom inconnu
NT-PRINCIPAL (1) Seulement le nom du principal comme dans DCE, ou pour les utilisateurs
NT-SRV-INST (2) Service et autre instance unique (krbtgt)
NT-SRV-HST (3) Service avec nom d'hôte comme instance (telnet, rcommands)
NT-SRV-XHST (4) Service avec hôte comme composants restants
NT-UID (5) ID unique
NT-X500-PRINCIPAL (6) Nom distinctif codé en X.509 [RFC2253]
NT-SMTP-NAME (7) Nom en forme de nom de messagerie électronique SMTP (par exemple,user@example.com)
NT-ENTERPRISE (10) Nom d'entreprise - peut être transposé en nom de principal

   Lorsqu'un nom n'implique pas d'informations autres que son unicité à un moment particulier, le type de nom PRINCIPAL devrait être utilisé pour les utilisateurs, et il peut aussi être utilisé pour un serveur unique. Si le nom est un ID unique généré par la machine qu'il est garanti n'être jamais ré-alloué, le type de nom d'UID devrait alors être utilisé.

   Si le premier composant d'un nom identifie un service et si des composants restants identifient une instance du service d'un manière spécifiée par le serveur, le type de nom de SRV-INST devrait alors être utilisé. Un exemple de ce type de nom est le TGS dont le nom a un premier composant de krbtgt et un second composant identifiant le domaine pour lequel le ticket est valide.

   Si le premier composant d'un nom identifie un service et qu'il y a un seul composant suivant le nom de service qui identifie l'instance comme l'hôte sur lequel fonctionne le serveur, le type de nom SRV-HST devrait être utilisé. Ce type est normalement utilisé pour les services Internet tels que telnet et les commandes R de Berkeley. Si les composants séparés du nom de l'hôte apparaissent comme des composants successifs qui suivent le nom du service, le type de nom SRV-XHST devrait être utilisé. Ce type peut être utilisé pour identifier les serveurs sur des hôtes qui ont des noms X.500, et où "/" pourrait être ambiguë.

   Un type de nom NT-X500-PRINCIPAL devrait être utilisé lorsqu'un nom provenant d'un certificat X.509 est traduit en un nom Kerberos. Le codage du nom X.509 comme un principal de Kerberos doit être conforme aux règles de codage spécifiées dans la rfc2253.

   Un type de nom de SMTP permet à un nom d'être d'un forme qui ressemble à un nom de messagerie électronique SMTP. Ce nom, comportant un @ et un nom de domaine, est utilisé comme premier composant du nom de principal.

   Un type de nom de UNKNOWN devrait être utilisé lorsque la forme du nom n'est pas connue. Lors d'une comparaison des nom, un type de nom UNKNOWN correspondra aux principaux authentifiés avec des noms de tout type. Un principal authentifié avec un type de nom de UNKNOWN ne correspondra cependant qu'à d'autres noms de type UNKNOWN.

   Les noms de tout type avec un composant initial de krbtgt sont réservés pour le TGS.

Nom des principaux de serveur

L'identifiant de principal pour un serveur sur un hôte sera généralement composé de 2 parties: Le domaine du KDC avec lequel le serveur est enregistré, et un nom à 2 composants NT-SRV-HST, si le nom d'hôte est un nom de domaine Internet, ou un nom multi-composants de type NT-SRV-XHST, si le nom de l'hôte est d'une forme qui permet "/" comme séparateurs. Le premier composant du nom à deux ou plusieurs composants va identifier le service, et les derniers composants vont identifier l'hôte. Lorsque le nom de l'hôte n'est pas sensible à la casse, le nom de l'hôte doit être en minuscule. Si c'est spécifié par le protocole d'application pour des services tels que telnet et les commandes R de Berkeley qui fonctionnent avec des privilèges de système, le premier composant peut être la chaîne host au lieu d'un identifiant spécifique du service.

Types d'adresse d'hôte

   Toutes les valeurs négatives pour le type d'adresse d'hôte sont réservées à une utilisation locale. Toutes les valeurs non négatives sont réservées aux champs et interprétations de type officiellement alloués.

Adresses Internet (IPv4) Les adresses Internet sont des quantités de 32bits codées dans l'ordre MSB. Une adresse IPv4 de bouclage ne devrait pas apparaître dans un PDU Kerberos. Le type des adresses IPv4 est (2)
Adresses Internet (IPv6) Les adresses IPv6 sont des guantités de 128bits codées danfs l'ordre MSB. Le type des adresses IPv6 est (24). Les adresses suivantes ne doivent pas apparaître dans un PDU Kerberos: l'adresse non spécifiée, la loopback, les adresses de lien locaux.

   Ces restrictions s'appliquent à l'inclusion dans les champs d'adresse des PDU, mais pas aux champs d'adresse des paquets qui pourraient porter ces PDU. La restriction est nécessaire parce que l'utilisation d'une adresse d'une portée non mondial pourrait permettre l'acceptation d'un message envoyé à partir d'un nœud qui pourrait avoir la même adresse, mais qui ne serait par l'hôte prévu. Si le type d'adresse local doit être utilisé pour une communication, la restriction d'adresse dans les tickets ne doit pas être utilisée. Les adresses IPv6 transposées en IPv4 doivent être représentées comme adresses de type 2.

Adresses DECnet de Phase IV Les adresses DECnet de Phase IV sont des adresses de 16 bits, codées dans l'ordre LSB. Le type des adresses DECnet de Phase IV est (12).
Adresses Netbios Les adresses Netbios sont des adresses de 16 octets normalement composées de caractères alphanumériques de 1 à 15 et complétées avec le caractère US-ASCII SPC (code 32). Le 16ème octet DOIT être le caractère US-ASCII NUL (code 0). Le type des adresses Netbios est (20)

Adresses directionnelles Inclure l'adresse de l'émetteur dans les messages KRB_SAFE et KRB_PRIV n'est pas souhaitable dans de nombreux environnements parce que les adresses peuvent être changées dans le transport par des traducteurs d'adresse réseau. Cependant, si ces adresses sont retirées les messages peuvent être soumis à une attaque par réflexion dans laquelle un message est répliqué en retour à son origine. Le type d'adresse directionnelle donne le moyen d'éviter les attaques des adresses dans le transport et en réflexion. Les adresses directionnelles sont codées comme des entiers non signés de 4 octets dans l'ordre des octets du réseau. Si le message est généré par la pratie qui envoie le message KRB_AP_REQ original, une adresse de 0 devrait être utilisé. Les applications qui impliquent plusieurs parties peuvent spécifier l'utilisation des autres adresses.

   Les adresses directionnelles doivent être utilisées uniquement pour le champ d'adresse d'envoyeur dans les messages KRB_SAFE ou KRB_PRIV. Elles no doivent pas être utilisées comme adresse de ticket ou dans un message KRB_AP_REQ. Ce type d'adresse devrait être utilisé seulement dans des situations où la partie qui envoie sait que la partie qui reçoit prend en charge le type d'adresse. Cela signifie généralement que les adresses directionnelles ne peuvent être utilisée que quand le protocoles d'application exige leur prise en charge. Les adresses directionnelles dont du type (3)

Échange de messages KDC: transports IP

Kerberos définis 2 mécanismes de transport IP pour communiquer entre clients et serveurs: UDP/IP et TCP/IP.

UDP/IP

   Les KDC qui prennent en charge les transport IP doivent accepter les demandes UDP et devraient les écouter sur le port 88. Des accès de remplacement peuvent être utilisés quand plusieurs KDC fonctionnent sur plusieurs domaines sur le même hôte.

   Les clients Kerberos qui prennent en charge les transports IP devraient prendre en charge l'envoi des demandes UDP. Les client devraient utiliser la découverte de KDC pour identifier l'adresse et le port IP auquel ils veulent envoyer leur demande.

   Lorsqu'il contacte un KDC pour un KRB_KDC_REQ en utilisant UDP, le client doit envoyer un UDP ne contenant qu'un codage de la demande au KDC. Le KDC répondra avec un datagramme contenant seulement un encodage de la réponse (soi un KRB_ERROR, soit un KRB_KDC_REP) à l'adresse IP de l'envoyeur. La réponse à une demande faite au moyen d'un transport UDP/IP doit aussi utiliser le transport UDP. Si la réponse ne peut être traitée en utilisant UDP (par exemple, parce qu'elle est trop grande), le KDC doit retourner KRB_ERR_RESPONSE_TOO_BIG, forçant le client à réessayer la demande en utilisant le transport TCP.

TCP/IP

   Les KDC qui prennent en charge les transports IP doivent accepter les demandes TCP et devraient les écouter sur le port 88. Les clients doivent prendre en charge l'envoi des demandes TCP, mais peuvent choisir d'essayer une demande en utilisant initialement le transport UDP. Les clients devraient utiliser la découverte de KDC pour identifier l'adresse et le port IP auquel ils enverront leur demande.

   Lorsque le message KRB_KDC_REQ est envoyé au KDC sur un flux TCP, la réponse doit être retournées au client sur le même flux TCP qui était établis pour le demandes. Le KDC peut fermer le flux TCP après avoir envoyé une réponse, mais peut laisser le flux ouvert pendant une durées raisonnable s'il attend une suite. Il faut veiller, dans la gestion des connexions TCP avec le KDC, à empêcher les attaques DOS fondées sur le nombre de connexions TCP ouvertes.

   Le client doit être prêt à voir le flux fermé par le KDC à tout moment après la réception d'une réponse. Une clôture de flux ne devrait pas être traitée comme une erreur fatale. Plutôt, si plusieurs échanges sont exigés (par exemple, par certaines formes de pré-authentification), le client peut avoir besoin d'établir une nouvelle connexion quand il est prêt à envoyer les messages suivants. Un client peut clore le flux après réception d'une réponse, et devrait clore le flux s'il ne prévoit pas d'envoyer de messages de suite.

   Un client peut envoyer plusieurs demandes avant de recevoir des réponses, bien qu'il doive être prêt à traiter la fermeture de la connexion après la première réponse.

   Chaque demande (KRB_KDC_REQ) et réponse (KRB_KDC_REP ou KRB_ERROR) envoyée sur le flux TCP est précédée par la longueur de la demande en 4 octets dans l'ordre des octets du réseau. Le MSB de la longueur est réservé à une expansion future et doit actuellement être mis à zéro. Si un KDC qui ne comprend pas comment interpréter un MSB mis dans le codage de longueur, reçoit une demande avec le MSB mis, il doit retourner un message KRB-ERROR avec l'erreur KRB_ERR_FIELD_TOOLONG et doit clore le flux TCP.

Découverte de KDC sur les réseaux IP

Les implémentations de client Kerberos doivent fournir un moyen pour que le client détermine la localisation des KDC. Traditionnellement, les implémentations Kerberos mémorisent de telles informations de configuration dans un fichier sur chaque machine cliente. L'expérience a montré que cette méthode de mémorisation des informations de configuration pose des problèmes d'informations périmées et d'évaluation, tout particulièrement lors de l'utilisation de l'authentification inter-domaine.

DNS

Dans Kerberos, les noms de domaine sont sensibles à la casse. Bien qu'il soit fortement recommandé que tous les noms de domaine soient en majuscule, cette recommandation n'a pas été adoptée par tous les sites. Certains sites utilisent des noms tout en minuscules et d'autres utilisent une casse mélangée. DNS, d'un autre côté, est insensible à la casse pour les interrogations.

Spécification de localisation de KDC avec DNS SRV

   Les informations de localisation de KDC sont à mémoriser en utilisant les DNS RR SRV . Le format de ce RR est le suivant:

  _Service._Proto.Realm TTL Class SRV Priority Weight Port Target

  Le proto peut être udp ou tcp. Si ces enregistrements de SRV doivent être utilisé, les enregistrements upd et tcp doivent tous 2 être spécifiés pour tous les développements de KDC. Le Realm est de domaine Kerberos auquel cet enregistrement correspond. Le domaine doit être un nom de domaine de style domaine. TTL, Class, SRV, Priority, Weight et Target ont la signification standar définis dans la rfc2782.

   Conformément à cette rfc, le numéro de port utilisé pour les enregistrement de SRV "_udp" et "_tcp" devraient être la valeur allouée à "kerberos" par l'IANA: 88, sauf si le KDC est configuré pour écouter sur un autre accès TCP.

Découverte de KDC pour les Realms name stype domaine

Ce sont des enregistrement DNS pour un domaine Kerberos EXAMPLE.COM. Il y a 2 serveurs Kerberos kdc1.example.com et kdc2.example.con. Les requêtes devraient d'abord être dirigées sur kdc1.example.com conformément à la priorité spécifée. Les pondérations ne sont pas utilisées dans cet échantillons d'enregistrements.

_kerberos._udp.EXAMPLE.COM. IN SRV 0 0 88 kdc1.example.com.
_kerberos._udp.EXAMPLE.COM. IN SRV 1 0 88 kdc2.example.com.
_kerberos._tcp.EXAMPLE.COM. IN SRV 0 0 88 kdc1.example.com.
_kerberos._tcp.EXAMPLE.COM. IN SRV 1 0 88 kdc2.example.com.

Nom du TGS

L'identifiant de principal du TGS doit être composé de 3 parties: le domaine du KDC qui produit les tickets TGS, et un nom en 2 parties du type NT-SRV-INST, dont la première partie est "krbtgt" et la seconde partie est le nom du domaine qui va accepter le TGT. Par exemple, un TGT produit par le domaine ATHENA.MIT.EDU utilisé pour des tickets du KDC ATHENA.MIT.EDU a un identifiant de principal de "ATHENA.MIT.EDU" (domaine), ("krbtgt", "ATHENA.MIT.EDU") (nom). Un TGT produit par le domaine ATHENA.MIT.EDU utilisé pour obtenir des tickets du domaine MIT.EDU a l'identifiant de principal "ATHENA.MIT.EDU" (domaine), ("krbtgt", "MIT.EDU") (nom).

OID pour Kerberosv5

Cet OID peut être utilisé pour identifier les messages de protocoles Kerberos encapsulés dans d'autres protocoles:
id-krb5 OBJECT IDENTIFIER ::= {
iso(1) identified-organisation(3) dod(6) internet(1) security(5) kerberosV5(2)
}

Constantes du protocole et valeurs associées

Les tableaux qui suivent font la liste des constantes utilisées dans le protocole et définissent leur signification. Dans la partie "spécification" sont spécifiés les gammes qui limitent les valeurs des constantes pour lesquelles les valeurs sont définies ici.

Valeurs d'utilisation de clé

La spécification du chiffrement et de checksum exige en entrée un numéro d'utilisation de clé, pour altérer la clé de chiffrement utilisée dans tout message spécifique afin de rendre plus difficiles certains types d'attaques.

1. timestamp padata AS-REQ PA-ENC-TIMESTAMP, chiffré avec la clé de client
2. Tickets AS-REP et TGS-REP (inclut la clé de session TGS ou la clé de session d'application), chiffrés avec la clé de service
3. Partie chiffrée de AS-REP (inclut la clé de session TGS ou la clé de session d'application), chiffrée avec la clé de client
4. Données d'autorisation TGS-REQ KDC-REQ-BODY, chiffrées avec la clé de session TGS
5. Données d'autorisation TGS-REQ KDC-REQ-BODY, chiffrées avec la sous-clé d'authentifiant TGS
6. Somme de contrôle d'authentifiant AP-REQ de padata TGS-REQ PA-TGS-REQ, frappée avec la clé de session TGS
7. Authentifiant AP-REQ de padata TGS-REQ PA-TGS-REQ (inclut la sous-clé d'authentifiant de TGS), chiffré avec la clé de session TGS
8. Partie chiffrée de TGS-REP (inclut la clé de session d'application), chiffrée avec la clé de session TGS
9. Partie chiffrée de TGS-REP (inclut la clé de session d'application), chiffrée avec la sous-clé d'authentifiant de TGS
10. Somme de contrôle d'authentifiant AP-REQ, frappée avec la clé de session d'application
11. Authentifiant AP-REQ (inclut la sous-clé d'authentifiant d'application), chiffré avec la clé de session d'application
12. Partie chiffrée de AP-REP (inclut la sous-clé de session d'application), chiffré avec la clé de session d'application
13. Partie chiffrée de KRB-PRIV, chiffrée avec une clé choisie par l'application
14. Partie chiffrée de KRB-CRED, chiffrée avec une clé choisie par l'application
15. Somme de contrôle KRB-SAFE, frappé avec une clé choisie par l'application
16-18. Réservés à une utilisation future dans Kerberos et les protocoles qui s'y rapportent.
19. Somme de contrôle AD-KDC-ISSUED (ad-checksum)
20-21. Réservés à une utilisation future dans Kerberos et les protocoles qui s'y rapportent.
22-25. Réservés à une utilisation future dans les mécanismes GSS-API de Kerberos Version 5 [RFC4121].
26-511. Réservés à une utilisation future dans Kerberos et les protocoles qui s'y rapportent.
512-1023. Réservés à des utilisations internes à une mise en œuvre Kerberos.
1024. Chiffrement à usage d'application dans les protocoles qui ne spécifient pas de valeurs d'usage de clés.
1025. Sommes de contrôle à usage d'application dans les protocoles qui ne spécifient pas de valeurs d'usage de clés
1026-2047. Réservé à l'usage d'application.

Types de données de pré-authentification

Padata et type de données (Padata-type) Commentaire
PA-TGS-REQ (1)
PA-ENC-TIMESTAMP (2)
PA-PW-SALT (3)
[reserved] (4)
PA-ENC-UNIX-TIME (5) déconseillé
PA-SANDIA-SECUREID (6)
PA-SESAME (7)
PA-OSF-DCE (8)
PA-CYBERSAFE-SECUREID (9)
PA-AFS3-SALT (10)
PA-ETYPE-INFO (11)
PA-SAM-CHALLENGE (12) sam/otp
PA-SAM-RESPONSE (13) sam/otp
PA-PK-AS-REQ_OLD (14) pkinit
PA-PK-AS-REP_OLD (15) pkinit
PA-PK-AS-REQ (16) pkinit
PA-PK-AS-REP (17) pkinit
PA-ETYPE-INFO2 (19) remplace pa-etype-info
PA-USE-SPECIFIED-KVNO (20)
PA-SAM-REDIRECT (21) sam/otp
PA-GET-FROM-TYPED-DATA (22) incorporé dans typed-data
TD-PADATA (22) incorpore padata
PA-SAM-ETYPE-INFO (23) sam/otp
PA-ALT-PRINC (24) crawdad@fnal.gov
PA-SAM-CHALLENGE2 (30) kenh@pobox.com
PA-SAM-RESPONSE2 (31) kenh@pobox.com
PA-EXTRA-TGT (41) Réservé extra TGT
TD-PKINIT-CMS-CERTIFICATES (101) CertificateSet du CMS
TD-KRB-PRINCIPAL (102) PrincipalName
TD-KRB-REALM (103) Domaine
TD-TRUSTED-CERTIFIERS (104 de PKINIT
TD-CERTIFICATE-INDEX (105) de PKINIT
TD-APP-DEFINED-ERROR (106) spécifique de l'application
TD-REQ-NONCE (107) ENTIER
TD-REQ-SEQ (108) ENTIER
PA-PAC-REQUEST (128) jbrezak@exchange.microsoft.com

Types d'adresse

IPv4 2
Directionnelle 3
ChaosNet 5
XNS 6
ISO 7
DECNET Phase IV 12
AppleTalk DDP 16
NetBios 20
IPv6 24

Types de données d'autorisation

Types de données d'autorisation Valeur de Ad-type
AD-IF-RELEVANT 1
AD-INTENDED-FOR-SERVER 2
AD-INTENDED-FOR-APPLICATION-CLASS 3
AD-KDC-ISSUED 4
AD-AND-OR 5
AD-MANDATORY-TICKET-EXTENSIONS 6
AD-IN-TICKET-EXTENSIONS 7
AD-MANDATORY-FOR-KDC 8
Valeurs réservées 9-63
OSF-DCE 64
SESAME 65
AD-OSF-DCE-PKI-CERTID 66 (hemsath@us.ibm.com)
AD-WIN2K-PAC 128 (jbrezak@exchange.microsoft.com)
AD-ETYPE-NEGOTIATION 129 (lzhu@windows.microsoft.com)

Types de codages de transit

Type de codage traversé Valeur de Tr-type
DOMAIN-X500-COMPRESS 1
Valeurs réservées Toutes les autres

Numéro de version du protocole

pvno (5) Numéro de version en cours du protocole Kerberos

Types de message Kerberos

KRB_AS_REQ (10) Demande d'authentification initiale
KRB_AS_REP (11) Réponse à demande KRB_AS_REQ
KRB_TGS_REQ (12) Demande d'authentification fondée sur un TGT
KRB_TGS_REP (13) Réponse à demande KRB_TGS_REQ
KRB_AP_REQ (14) Demande d'application au serveur
KRB_AP_REP (15) Réponse à KRB_AP_REQ_MUTUAL
KRB_RESERVED16 (16) Réservé à une demande krb_tgt_request d'usager à usager
KRB_RESERVED17 (17) Réservé à une réponse krb_tgt_reply d'usager à usager
KRB_SAFE (20) Message d'application sûr (avec somme de contrôle)
KRB_PRIV (21) Message d'application privé (chiffré)
KRB_CRED (22) Message privé (chiffré) pour transmission d'accréditifs
KRB_ERROR (30) Réponse d'erreur

Types de noms

KRB_NT_UNKNOWN (0) Type de nom inconnu
KRB_NT_PRINCIPAL (1) Juste le nom du principal comme dans DCE, ou pour utilisateurs
KRB_NT_SRV_INST (2) Service et autre instance unique (krbtgt)
KRB_NT_SRV_HST (3) Service avec nom d'hôte comme instance (telnet, rcommands)
KRB_NT_SRV_XHST (4) Service avec hôte comme composants restants
KRB_NT_UID (5) ID unique
KRB_NT_X500_PRINCIPAL (6) Nom distinctif X.509 codé [RFC2253]
KRB_NT_SMTP_NAME (7) Nom en forme de nom de messagerie électronique SMTP (par exemple, user@example.com)
KRB_NT_ENTERPRISE (10) Nom d'entreprise; peut être transposé en nom de principal

Codes d'erreur

KDC_ERR_NONE (0) Pas d'erreur
KDC_ERR_NAME_EXP (1) L'entrée du client dans la base de données a expiré
KDC_ERR_SERVICE_EXP (2) L'entrée du serveur dans la base de données a expiré
KDC_ERR_BAD_PVNO (3) Numéro de version du protocole demandé non accepté
KDC_ERR_C_OLD_MAST_KVNO (4) La clé du client est chiffrée avec la vieille clé maîtresse
KDC_ERR_S_OLD_MAST_KVNO (5) La clé du serveur est chiffrée avec la vieille clé maîtresse
KDC_ERR_C_PRINCIPAL_UNKNOWN (6) Client non trouvé dans la base de données Kerberos
KDC_ERR_S_PRINCIPAL_UNKNOWN (7) Serveur non trouvé dans la base de données Kerberos
KDC_ERR_PRINCIPAL_NOT_UNIQUE (8) Plusieurs entrées du principal dans la de données
KDC_ERR_NULL_KEY (9) Le client ou le serveur a une clé nulle
KDC_ERR_CANNOT_POSTDATE (10) Ticket non éligible au postdatage
KDC_ERR_NEVER_VALID (11) Heure de début demandée postérieure à l'heure de fin
KDC_ERR_POLICY (12) La politique du KDC rejette la demande
KDC_ERR_BADOPTION (13) Le KDC ne peut pas traiter l'option demandée
KDC_ERR_ETYPE_NOSUPP (14) Le KDC ne prend pas en charge le type de chiffrement
KDC_ERR_SUMTYPE_NOSUPP (15) Le KDC n'accepte pas le type de somme de contrôle
KDC_ERR_PADATA_TYPE_NOSUPP (16) Le KDC ne prend pas en charge le type de padata
KDC_ERR_TRTYPE_NOSUPP (17) Le KDC ne prend pas en charge le type transité
KDC_ERR_CLIENT_REVOKED (18) Les accréditifs du client ont été révoqués
KDC_ERR_SERVICE_REVOKED (19) Les accréditifs du serveur ont été révoqués
KDC_ERR_TGT_REVOKED (20) Le TGT a été révoqué
KDC_ERR_CLIENT_NOTYET (21) Client pas encore valide ; réessayer plus tard
KDC_ERR_SERVICE_NOTYET (22) Serveur pas encore valide ; réessayer plus tard
KDC_ERR_KEY_EXPIRED (23) Mot de passe expiré ; changer le mot de passe pour recommencer
KDC_ERR_PREAUTH_FAILED (24) Informations de pré-authentification invalides
KDC_ERR_PREAUTH_REQUIRED (25) Pré-authentification supplémentaire exigée
KDC_ERR_SERVER_NOMATCH (26) Le serveur demandé et le ticket ne correspondent pas
KDC_ERR_DOIIVENT_USE_USER2USER (27) Principal de serveur valide seulement d'usager à usager
KDC_ERR_PATH_NOT_ACCEPTED (28) La politique du KDC rejette le chemin de transit
KDC_ERR_SVC_UNAVAILABLE (29) Un service n'est pas disponible
KRB_AP_ERR_BAD_INTEGRITY (31) Échec de vérification d'intégrité sur le champ déchiffré
KRB_AP_ERR_TKT_EXPIRED (32) Ticket expiré
KRB_AP_ERR_TKT_NYV (33) Ticket pas encore valide
KRB_AP_ERR_REPEAT (34) La demande est une répétition
KRB_AP_ERR_NOT_US (35) Le ticket n'est pas pour nous
KRB_AP_ERR_BADMATCH (36) Ticket et authentifiant ne correspondent pas
KRB_AP_ERR_SKEW (37) Biais d'horloge trop grand
KRB_AP_ERR_BADADDR (38) Adresse réseau incorrecte
KRB_AP_ERR_BADVERSION (39) Discordance de version de protocole
KRB_AP_ERR_MSG_TYPE (40) Type de message invalide
KRB_AP_ERR_MODIFIED (41) Flux de message modifié
KRB_AP_ERR_BADORDER (42) Message pas à son ordre
KRB_AP_ERR_BADKEYVER (44) Version de clé spécifiée non disponible
KRB_AP_ERR_NOKEY (45) Clé de service non disponible
KRB_AP_ERR_MUT_FAIL (46) Échec d'authentification mutuelle
KRB_AP_ERR_BADDIRECTION (47) Direction de message incorrecte
KRB_AP_ERR_METHOD (48) Autre méthode d'authentification exigée
KRB_AP_ERR_BADSEQ (49) Numéro de séquence incorrect dans le message
KRB_AP_ERR_INAPP_CKSUM (50) Type de somme de contrôle inapproprié dans le message
KRB_AP_PATH_NOT_ACCEPTED (51) La politique rejette le chemin de transit
KRB_ERR_RESPONSE_TOO_BIG (52) Réponse trop grosse pour UDP ; ressayer avec TCP
KRB_ERR_GENERIC (60) Erreur générique (description dans e-text)
KRB_ERR_FIELD_TOOLONG (61) Le champ est trop long pour cette mise en œuvre
KDC_ERROR_CLIENT_NOT_TRUSTED (62) Réservé pour PKINIT
KDC_ERROR_KDC_NOT_TRUSTED (63) Réservé pour PKINIT
KDC_ERROR_INVALID_SIG (64) Réservé pour PKINIT
KDC_ERR_KEY_TOO_WEAK (65) Réservé pour PKINIT
KDC_ERR_CERTIFICATE_MISMATCH (66) Réservé pour PKINIT
KRB_AP_ERR_NO_TGT (67) Pas de TGT disponible pour valider USER-TO-USER
KDC_ERR_WRONG_REALM (68) Réservé pour utilisation future
KRB_AP_ERR_USER_TO_USER_REQUIRED (69) Le ticket doit être pour USER-TO-USER
KDC_ERR_CANT_VERIFY_CERTIFICATE (70) Réservé pour PKINIT
KDC_ERR_INVALID_CERTIFICATE (71) Réservé pour PKINIT
KDC_ERR_REVOKED_CERTIFICATE (72) Réservé pour PKINIT
KDC_ERR_REVOCATION_STATUS_UNKNOWN (73) Réservé pour PKINIT
KDC_ERR_REVOCATION_STATUS_UNAVAILABLE (74) Réservé pour PKINIT
KDC_ERR_CLIENT_NAME_MISMATCH (75) Réservé pour PKINIT
KDC_ERR_KDC_NAME_MISMATCH (76) Réservé pour PKINIT

Exigences d'intéropérabilité

La version 5 du protocole Kerberos accepte une myriade d'options. Parmi celles-ci, plusieurs types de chiffrement et de sommes de contrôle; des schéma de codage de remplacement pour le champ de transit; des mécanismes facultatifs pour la pré-authentification; le traitement de tickets sans adresse; des options pour l'authentification mutuelle; l'authentification d'utilisateur à utilisateur; la prise en change de proxy; le format des noms de domaines; le traitement des données d'autorisation; et la transmission, le post-datage, et le renouvellement de tickets.

Afin d'assurer l'intéropérabilité des domaines, il est nécessaire de définir une configuration minimale qui doit être prise en charge par toutes les mises en œuvre. Cette configuration minimale est sujette à changement ultérieurs.

Spécification 2

   Ce paragraphe définit la seconde spécification des options. Les implémentations qui sont configurées de cette façon peuvent être considérées comme prenant en charge la spécification 2 de Kerberos v5 (5.2).

Transport Le transport TCP/IP et UDP/IP doivent être pris en charge par les clients et KDC qui revendiquent la conformité à
la spécification 2. Méthodes de chiffrement et de somme de contrôle
Les mécanismes de chiffrement et de somme de contrôle suivants doivent être pris en charge:
Chiffrement: AES256-CTS-HMAC-SHA1-96 [RFC3962]
Somme de contrôle: HMAC-SHA1-96-AES256 [RFC3962]

   Les mises en œuvre devraient aussi accepter d'autres mécanismes, mais les mécanismes supplémentaires ne peuvent être utilisés qu'en communicant avec des principaux connus pour les accepter aussi. Les mécanismes suivants provenant de la [RFC3961] et de la [RFC3962] devraient être pris en charge:

Chiffrement: AES128-CTS-HMAC-SHA1-96, DES-CBC-MD5, DES3-CBC-SHA1-KD
Somme de contrôle: DES-MD5, HMAC-SHA1-DES3-KD, HMAC-SHA1-96-AES128

   Les implémentations peuvent aussi accepter d'autres mécanismes, mais les mécanismes supplémentaires ne peuvent être utilisés qu'en communication avec des principaux connus pour les accepter aussi.

Noms de domaine Toutes les mises en œuvre doivent comprendre la hiérarchie des domaines à la fois dans le domaine Internet et dans le style X.500. Lorsque est demandé un TGT pour un domaine inconnu, le KDC doit être capable de déterminer les noms des domaines intermédiaires entre le domaine du KDC et le domaine demandé.
Codage de champ de transit DOMAIN-X500-COMPRESS doit être pris en charge. D'autres codages peuvent être acceptés, mais ils ne peuvent être utilisés lorsque ce codage est accepté par tous les domaines intermédiaires.
Méthodes de pré-authentification La méthode TGS-REQ doit être prise en charge. Elle n'est pas utilisée sur la demande initiale. La méthode PA-ENC-TIMESTAMP doit être acceptée par les clients, mais savoir si elle est activée par défaut peut être déterminé domaine par domaine. Si la méthode n'est pas utilisée dans la demande initiale et si l'erreur KDC_ERR_PREAUTH_REQUIRED est retournée, spécifiant PA-ENC-TIMESTAMP comme méthode acceptable, le client devrait ressayer la demande initiale en utilisant la méthode de pré-authentification PA-ENC-TIMESTAMP. Les serveurs n'ont pas besoin de prendre en charge la méthode PA-ENC-TIMESTAMP, mais si elle n'est pas acceptée, le serveur devrait ignorer la présence de la pré-authentification PA-ENC-TIMESTAMP dans une demande.
La méthode ETYPE-INFO2 doit être acceptée; cette méthode est utilisée pour communiquer l’ensemble des types de chiffrement acceptés, et les paramètres correspondants de salt et de string-to-key. La méthode ETYPE-INFO devrait être acceptée pour l’interopérabilité avec les mises en œuvre les plus anciennes.
Authentification mutuelle L’authentification mutuelle (via le message KRB_AP_REP) doit être acceptée.
Adresses et flags de ticket Tous les KDC doivent passer les tickets qui ne portent pas d’adresse (c’est-à-dire que si un TGT ne contient pas d’adresse, le KDC retournera des tickets dérivés). Les mises en œuvre devraient par défaut demander des tickets sans adresse, car cela augmente de façon significative l’interopérabilité avec la traduction d’adresse réseau. Dans certains cas, les domaines ou les serveurs d’application peuvent exiger que les tickets aient une adresse.

   Les mises en œuvre devraient accepter le type d’adresse directionnelle pour les messages KRB_SAFE et KRB_PRIV et devraient inclure des adresses directionnelles dans ces messages quand d’autres types d’adresse ne sont pas disponibles. Les tickets mandataires et transmis doivent être acceptés. Les domaines et serveurs d’application individuels peuvent y régler leur propre politique lorsque de tels tickets seront acceptés. Toutes les implémentations doivent reconnaître les tickets renouvelables et postdatés, mais ils n’ont pas besoin de les mettre réellement en œuvre. Si ces options ne sont pas prises en charge, l’heure de début et l’heure de fin dans le ticket devront spécifier l’entière durée de vie utile d’un ticket. Lorsque un ticket postdaté est décodé par un serveur, toutes les mises en œuvre devront rendre visible la présence du flag postdaté pour le serveur appelant

Authentification d’usager à usager La prise en charge de l’authentification d’usager à usager (via l’option ENC-TKT-IN-SKEY KDC) doit être fournie par les mises en œuvre, mais les domaines individuels peuvent décider au titre de leur politique de rejeter de telles demandes principal par principal ou domaine par domaine.
Données d’autorisation Les mises en œuvre doivent passer tous les sous-champs de données d’autorisation des TGT à tout ticket dérivé sauf si ils sont amenés à supprimer un sous-champ au titre de la définition de ce type de sous-champ enregistré. (Il n’est jamais incorrect de passer sur un sous-champ, et actuellement, aucun type de sous-champ enregistré ne spécifie la suppression au KDC.)
Les mises en œuvre doivent rendre disponible le contenu de tout sous-champ de données d’autorisation au serveur lorsque le ticket est utilisé. Les mises en œuvre ne sont pas obligées de permettre aux clients de spécifier le contenu des champs de données d’autorisation.
Gammes de constantes Toutes les constantes du protocole sont contraintes à des valeurs de 32 bits (signés) sauf contraintes supplémentaires provenant de la définition du protocole. Cette limite est donnée pour permettre aux mises en œuvre de faire des hypothèses sur les valeurs maximales qui seront reçues pour ces constantes. Les mises en œuvre recevant des valeurs hors de ces gammes peuvent rejeter la demande, mais elles doivent se récupérer proprement.

Valeurs de KDC recommandées

Durée de vie minimum 5 minutes
Durée de vie maximum renouvelable 1 semaine
Durée de vie maximum de ticket 1 jour
Biais d’horloge admissible 5 minutes
Adresses vides Admis
proxiable, etc. Admis

17 juin 2015

rfc4210

Protocole de gestion de certificat des infrastructures à clé publique X.509

Introduction

Ce document décris le protocole de gestion de certificat (CMP) des infrastructures à clé publique X.509. Les messages de protocole sont définis pour la création et la gestion des certificats. Le terme X.509 dans ce document réfère à un certificat X.509v3.

Définition des entités de PKI

Les entités impliqués dans la gestion de PKI incluent l'entité finale et l'autorité de certification. Une autorité d'enregistrement peut également être utilisé.

Sujet et entités finales

   Le terme "subject" est utilisé ici pour référer à l'entité pour lequel le certificat est fournis, typiquement nommé dans le sujet ou le champ subjectAltName d'un certificat. Quand on souhaite distinguer les outils et/ou logiciels utilisés par le sujet (ex: un module de gestion de certificat local), on utilise le terme "subject equipment". En général, le terme "end entity" (EE), au lieu de "subject" est préféré pour éviter les confusions avec le nom du champ. Il est important de noter que les entités finales n'incluent pas seulement des utilisateurs humains d'applications, mais également les applications elles-mêmes. Ce facteur influence les protocoles que les opérations de gestion de PKI utilisent; par exemple, une application est plus susceptibles de savoir exactement quelles extensions de certificat sont nécessaires que ne le sont les utilisateurs humains.

   Les entités de gestion de PKI sont également des entités finales dans le sens qu'ils sont parfois nommés dans le sujet ou le subjectAltName d'un certificat ou un cross-certificate. Quand approprié, le terme "end entity" sera utilisé pour référer aux entités finales qui ne sont pas des entités de gestion de PKI.

   Toute entité finale nécessite un accès local sécurisé à certaines informations -- au minimum, son propre nom et clé privée, le nom d'une CA qui est directement trusté, et la clé publique de cette CA ( ou une empreinte de la clé publique où une version d'un certificat auto-fournis est disponible quelque part). Les implémentations peuvent utiliser un stockage local sécurisé pour plus que ce minimum. La forme de stockage varie également -- de simples fichier à des jetons cryptographiques inviolables. L'information stockée dans un tel stockage local est référé ici à l'environnement de sécurité personnel (PSE). Bien que les formats PSE sont au-delà du scope de ce document, un format générique d'échange pour les PSE est définis ici: un message réponse de certification peut être utilisé.

Autorité de certification

   L'autorité de certification peut ou non être un vrai tier de confiance du point de vue de l'entité finale. Très souvent, la CA appartient à la même organisation que les entités finales qu'elle supporte.

   De même, on utilise le terme CA pour référer à l'entité nommée dans le champ issuer d'un certificat. Quand il est nécessaire de distinguer les outils software ou hardware utilisé par la CA, on utilise le terme d'équipement CA. L'équipement CA inclus souvent un composant offline et un composant online, avec la clé privée de la CA uniquement disponible au composant offline.

   On utilise le terme "root CA" pour indiquer une CA qui est directement trusté par une entité finale; c'est à dire, acquérir de manière sécurité la valeur d'une clé publique d'une CA root nécessite certaines étapes out-of-band. Ce terme n'implique pas qu'une CA root soit nécessairement tout en haut d'une hiérarchie, simplement que la CA en question est trustée directement.

   Une CA subordonnée est une CA qui n'est pas une CA root pour l'entité finale. Souvent, une CA subordonnée ne sera une CA root pour aucune entité, mais ce n'est pas mandatoire.

   En plus des entités finales et des CA, de nombreux environnements font appel à un autorité d'enregistrement (RA) séparé de l'autorité de certification. Les fonctions du RA varie d'un cas à un autre mais peut inclure une authentification personnelle, la distribution de jetons, reporter la révocation, assignement de nom, génération de clé, archivage de paires de clé, etc.

   Ce document considère le RA comme composant optionnel: quand il n'est pas présent, la CA est supposé gérer les fonctions du RA, donc les protocoles de gestion de PKI sont les même du point de vue de l'entité finale. De même, on distingue le RA et les outils utilisés (les équipements RA).

   Noter qu'un RA est lui-même une entité finale. On assume que tous les RA sont en fait des entités finales certifiés et que les RA ont des clés privées qui sont utilisable pour la signature. La manière dont un équipement CA identifie des entités finales comme RA est un problème d'implémentation (par ex: Ce document ne spécifie pas d'opération de certification RA spécial). On ne mandate pas que le RA est certifié par la CA avec laquelle il inter-agit (donc un RA peut travailler avec plus d'une CA alors qu'il a été certifié une seule fois).

   Dans certaines circonstances, les entités finales vont communiquer directement avec une CA même quand un RA est présent. Par exemple, pour un enregistrement initial et/ou une certification, le sujet peut utiliser sont RA, mais communiquer directement avec le CA pour rafraîchir son certificat.

Pré-requis de gestion de PKI

Les protocoles donnés ici nécessitent les pré-requis suivant pour la gestion de PKI:

1. La gestion de la PKI doit se conformer aux standards ISO/IEC 9594-8/ITU-T X.509
2. Il doit être possible de mettre à jour régulièrement une paire de clé sans affecter une autre paire de clé.
3. L'utilisation de la confidentialité dans les protocoles de gestion de PKI doit être conservé à un minimum pour pouvoir simplifier l'acceptation dans les environnements où une forte confidentialité peut causer des problèmes réguliers.
4. Les protocoles de gestion de PKI doivent permettre d'utiliser différents algorithmes cryptographiques ( incluant RSA, DSA, MD5 et SHA-1). Cela signifie qu'une CA, RA, ou entité finale donné, en principe, utilise les algorithmes qui lui conviennent pour ses propres paires de clés.
5. Les protocoles de gestion de PKI ne doivent pas pré-inclure la génération de paires de clé par l'entité finale concernée, par un RA, ou par une CA. La génération de clé peut également se produire n'importe où, mais dans le but de la gestion de PKI la clé est d'abord présente dans une entité finale, RA, ou CA.
6. Les protocoles de gestion de PKI doivent supporter la publication de certificats par l'entité finale concernée, par une RA, ou par une CA. Différences implémentations et différents environnements peuvent choisir n'importe quel approche ci-dessus.
7. Les protocoles de gestion de PKI doivent supporter la production de listes de révocation de certificat en permettant aux entités finales certifiées de créer des requêtes pour la révocation des certificats. Cela doit être fait de telle manière qu'une attaque DOS, qui est possible, ne soit pas simple.
8. Les protocoles de gestion de PKI doivent être utilisables sur une variété de mécanismes de transport, incluant les mails, http, TCP/IP et ftp.
9. L'autorité finale pour la création des certificats incombe à la CA. Aucune RA ou équipement d'entité finale ne peut supposer qu'un certificat fournis par une CA contienne ce qui a été demandé; Une CA peut altérer les valeurs de champs de certificat ou peut en ajouter, supprimer, ou modifier les extensions en accord à ses stratégies. En d'autres terme, toutes les entités PKI (entités finales, CA et CA) doivent être capable de manipuler les réponses aux requêtes pour les certificats dans lequel le certificat émis est différent de la demande. Noter qu'une stratégie peut dicter qu'une CA ne publie pas ou ne distribue pas le certificat tant que l'entité qui a fait la demande n'a pas accepté le certificat créé (généralement par un message certConf).
10. Une grâce, un changement planifié d'une paire de clé de CA non-compromise doit être supporté (noter que si la clé CA est compromise, la ré-initialisation doit être effectuée pour toutes les entités dans le domaine de la CA). Une entité finale dont le PSE contient la nouvelle clé publique CA doit également être capable de vérifier les certificats vérifiables en utilisant l'ancienne clé publique. Les entités finales qui trust directement l'ancienne paire de clé CA doivent également être capable de vérifier les certificat signés en utilisant la nouvelle clé privée de la CA.
11. Les fonctions d'un RA peut, dans certaines implémentations ou environnements, être géré par la CA elle-même. Les protocoles doivent être conçus pour que les entités finales utilisent le même protocole sans regarder si la communication est avec une CA ou une RA. Naturellement, l'entité finale doit utiliser la bonne clé public RA ou CA pour protéger la communication.
12. Pour une EE demandant un certificat contenant un valeur de clé publique donnée, celle-ci doit être prête à démontrer la possession de la clé privée correspondant.

Opérations de gestion de PKI

Le diagramme suivant affiche la relation entre les entités définies plus haut en terme d'opération de gestion de PKI. Les lettres dans le diagramme indiquent les protocoles dans le sens qu'un jeu définis de message de gestion de PKI peut être envoyé.
+---+_____cert._publish________+------------+______j
_____|___|__‹---------------------__|_End_Entity_|_‹-------
_____|_C_|_____________g____________+------------+______"out-of-band"
_____|_e_|____________________________|_^________________loading
_____|_r_|____________________________|_|______initial
_____|_t_|__________________________a_|_|_b_____registration/
_____|___|____________________________|_|_______certification
_____|_/_|____________________________|_|______key_pair_recovery
_____|___|____________________________|_|______key_pair_update
_____|_C_|____________________________|_|______certificate_update
_____|_R_|__PKI_"USERS"_______________V_|______revocation_request
_____|_L_|_-------------------+-+-----+-+------+-+-------------------
_____|___|__PKI_MANAGEMENT____|_^______________|_^
_____|___|____ENTITIES______a_|_|_b__________a_|_|_b
_____|_R_|____________________V_|______________|_|
_____|_e_|_____________g___+------+____d_______|_|
_____|_p_|___‹------------_|_RA___|_‹-----+____|_|
_____|_o_|______cert.______|______|_----+_|____|_|
_____|_s_|_______publish___+------+___c_|_|____|_|
_____|_i_|______________________________|_|____|_|
_____|_t_|______________________________V_|____V_|
_____|_o_|__________g_________________+------------+___i
_____|_r_|___‹------------------------|_____CA_____|-------›
_____|_y_|__________h_________________+------------+__"out-of-band"
_____|___|______cert._publish______________|_^_________publication
_____|___|______CRL_publish________________|_|
_____+---+_________________________________|_|____cross-certification
_________________________________________e_|_|_f__cross-certificate
___________________________________________|_|_______update
___________________________________________|_|
___________________________________________V_|
_________________________________________+------+
_________________________________________|_CA-2_|
_________________________________________+------+

1. Établissement de CA: en établissant une nouvelle CA, certaines étapes sont requises ( par ex. la production de crl initiales, l'export de la clé publique de la CA).
2. Initialisation de l'entité finale: inclus l'import d'une clé publique CA racine et la demande d'information sur les options supportées par une entité de gestion de PKI.
3. Certification: Diverses opérations résultent de la création de nouveaux certificats:

1. Enregistrement/certification initiale: C'est le processus par lequel une entité finale se fait connaître auprès d'une CA ou RA, avant que la CA ne fournisse un certificat pour l'entité finale. Le résultat final de ce processus ( Quand il est réussit ) est qu'une CA fournis un certificat pour une clé publique d'une entité finale, et retourne ce certificat à l'entité finale et/ou poste ce certificat dans un répertoire publique. Ce processus peut, et est typiquement, être fait de plusieurs étapes, incluant une initialisation de l'équipement de l'entité finale. Par exemple, l'équipement de l'entité finale doit être initialisé de manière sécurisé avec la clé publique d'une CA, pour être utilisé dans la validation de chemins de certification.
2. Mise à jour des paires de clé: Toute paire de clé doit être mis à jours régulièrement ( par ex: remplacé par une nouvelle paire de clé), et un nouveau certificat doit être fournis.
3. Mise à jour de certificat: Vu que les certificats expirent, ils doivent être rafraîchis si rien n'a été changé dans l'environnement.
4. Mise à jours de paire de clé de CA: Comme pour les entités finales, les paires de clé CA doivent être mis à jours régulièrement; cependant, différents mécanismes sont requis.
5. Demande de cross-certification: Une CA demande de fournir un cross-certificat pour une autre CA. Pour ce standard, les termes suivants sont définis. Un cross-certificat est un certificat dans lequel le sujet de la CA et le fournisseur de la CA sont distincts et subjectPublicKeyInfo contient une clé de vérification (par ex: le certificat a été fournis pour la signature de la paire de clé du sujet de la CA.). Quand il est nécessaire de distinguer plus finement, les termes suivants peuvent être utilisé: un cross-certificat est appelé un certification inter-domaine si le sujet et le fournisseur appartiennent à des domaines administratifs différents.

1. Note 1. La définition ci-dessus de cross-certificat s'aligne avec le term définis CA-certificate dans X.509. Noter que ce terme ne doit pas être confondu avec le type d'attribut cACertificate X.500, qui n'est pas lié.
2. Note 2. Dans de nombreux environnements, le terme cross-certificate, sera compris comme synonyme de cross-certificate inter-domaine.
3. Note 3. L'émission de cross certificat peut être, mais pas nécessairement, mutuel; c'est à dir, 2 CA peuvent fournir des cross certificats entre eux.

6. Mise à jours de cross-certificats: Similairement à une mise à jours de certificat.

4. Opérations de découverte de certificat/CRL: Certaines opérations de gestion de PKI résultent dans la publication de certificats ou de CRL:

1. Publication de certificat: Après avoir produit un certificat, un moyen de publication est nécessaire. Ce moyen définis dans PKIX peut impliquer les messages spécifiés plus bas, ou d'autres moyen (ldap par exemple).
2. Publication de CRL: Comme pour une publication de certificat.

5. Opérations de récupération: Certaines opérations de gestion de PKI sont utilisée quand une entité finale a perdu son PSE:

1. Récupération de paire de clé: Comme option, Les clé clients utilisateurs ( par exemple la clé privée de l'utilisateur utilisé pour le déchiffrement) peut être sauvegardé par une CA, une RA, ou un système de sauvegarde de clé associé avec une CA ou une RA. Si une entité a besoin de récupérer sa clé, un protocole d'échange peut être nécessaire pour supporter une telle récupération.

6. Opérations de révocation: Certaines opérations de PKI résultent en la création d'une nouvelle entrée de CRL et/ou une nouvelle CRL.

1. Demande de révocation: Une personne autorisée avertis une CA d'une situation anormale nécessitant la révocation de certificat

7. Opérations PSE: Bien que la définition des opérations PSE soient en dehors du périmètre de ce document, on doit définir une PKIMessage ( CertRepMessage ) qui peut former la base de telles opérations.

Noter que les protocoles on-line ne sont par la seule manière d'implémenter les opérations ci-dessus. Pour toutes les opérations, il y à des méthodes offline qui accomplissent le même résultat, et cette spécification ne mandate pas l'utilisation de protocoles on-line. Par exemple, quand des tokens hardware sont utilisé, de nombreuses opération peuvent être accomplies comme partie de la livraison de jetons physique.

Hypothèses et restrictions

Initialisation de l'entité finale

La première étape pour une entité finale en dialoguant avec les entités de gestion de PKI est de demander les informations sur les fonctions de la PKI supportés et pour acquérir de manière sécurisé une copie des clé publiques de CA root.

Enregistrement/certification Initiale

   Il y a de nombreux schéma qui peuvent être utilisé pour accomplir un enregistrement et une certification des entités finales. Aucune méthode n'est adaptée pour toutes les situations à cause de la plage de stratégie qu'une CA peut implémenter et la variation dans les types d'entité finales qui peuvent se produire.

   Cependant, on peut classer les schémas d'enregistrement/certification qui sont supportés par cette spécification. Noter que le terme d'initial est crucial: on gère les situations où l'entité finale en question n'a jamais eu de contact avec la PKI. Quand l'entité finale possède déjà des clés certifiés, certaines simplification/alternatives sont possibles.

   En ayant classé les schémas qui sont supportés par cette spécification on peut ainsi spécifier certains comme obligatoire et d'autres comme optionnels. Le but est que les schéma obligatoires couvrent suffisamment de cas qui se produisent en utilisation réelle, alors que les schémas optionnels se produisent moins fréquemment. De cette manière, on accomplis une balance entre la flexibilité et la simplicité d'implémentation.

Critères utilisés

Initialisation de l'enregistrement/certification

En terme de messages PKI qui sont produits, on peut regarder l'initialisation des échange d'enregistrement/certification initials comme se produisant chaque fois que le premier message de PKI lié à l'entité finale est produite. Noter que l'initialisation dans le monde réel de cette procédure peut se produire n'importe où.

Authentification du message originel de l'entité finale

   Les messages on-line produits par l'entité finale qui nécessitent un certificat peuvent être authentifiés ou non. Les prérequis ici sont pour authentifier l'origine de tous messages de l'entité finale vers la PKI (CA/RA).

   Dans cette spécification, une telle authentification est accomplie par la PKI ( CA/RA ) qui fournis à l'entité finale une valeur secrète ( clé d'authentification initiale ) et une valeur de référence ( utilisée pour identifier la valeur secrète ) via d'autres moyens. La clé d'authentification initiale peut ainsi être utilisée pour protéger les messages PKI important.

   Donc, on peut classer le schéma d'enregistrement/certification initial en fonction de si l'entité finale est on-line ou non -› les messages PKI sont authentifiés on non.

   Note 1: on ne discute pas des messages d'authentification de la PKI -› entité finale ici, vu que c'est toujours requis. Dans tous les cas, il peut être simplement une fois que la clé publique de la CA root a été installée dans l'équipement de l'entité finale ou peut être basée sur la clé d'authentification initiale.

   Note 2: Une procédure d'enregistrement/certification initiale peut être sécurisé via d'autres moyens alternatifs.

Emplacement de la génération de clé

Dans cette spécification, la génération de clé est vu comme se produisant quand la clé publique ou privée se produit dans un PKIMessage. Noter que cela ne pré-inclus pas un service de génération de clé centralisée; la paire de clé actuelle peut avoir été générée n'importe où et envoyé à l'entité finale, RA, ou CA en utilisant un protocole de requête/réponse de génération de clé. Il y a donc 3 possibilités pour l'emplacement de la génération de clé: l'entité finale, une RA ou une CA.

Confirmation du succès de la certification

Après la création d'un certificat initial pour une entité finale, Une assurance supplémentaire peut être obtenu en retournant une confirmation du succès de l'opération à l'entité finale, contenant le certificat. Cela donne 2 possibilités: confirmé ou non.

Schéma mandatoire

Le critère ci-dessus permet un grand nombre de schéma d'enregistrement/certification initial. Cette spécification mandate qu'un équipement CA, RA, EE conformes doit supporter le schéma "Schéma authentifié de base", et peut supporter d'autres schémas additionnels.

Schéma centralisé

En terme de classification, ce schéma est, d'une certaine manière, le plus simple possible, où:

- L'initialisation se produit sur la CA certifiante
- Aucune authentification on-line n'est requis
- La génération de clé se produit sur la CA authentifiante
- Aucun message de confirmation n'est requis

En terme de flux de message, ce schéma signifie que le seul message requis est envoyé de la CA à l'entité finale. Le message doit contenir tout le PSE pour l'entité finale. Certains moyens externes doivent être fournis pour permettre à l'entité final d'authentifier le message reçu et pour décrypter et décrypter les valeurs.

Schéma authentifié de base

En terme de classification, ce schéma est où:

- Une initialisation se produit au niveau de l'entité finale
- un message d'authentification est requis
- La génération de clé se produit sur l'entité finale
- Un message de confirmation est requis

En terme de flux de message, ce schéma est comme suit: La génération de la clé, la création de la demande de certification et la protection de la clé d'authentification initiale (IAK) se produisent sur l'entité finale. L'autorité vérifie la requête, la traite et créé la réponse. L'entité final manipule cette réponse et créé la confirmation. L'autorité vérifie la confirmation et créé une réponse.

Preuve de possession de la clé privée

   Pour empêcher certaines attaques et pour permettre à une CA/RA de vérifier proprement la validité du lien entre une entité finale et une paire de clé, les opérations de gestion de PKI spécifiés ici permettent à une entité finale de prouver qu'il possède la clé privée correspondant à la clé publique pour laquelle un certificat est demandée. Une CA/RA est libre de choisir comment forcer le POP dans ses échanges de certification. Cependant, il est nécessaire qu'un CA/RA force le POP par n'importe quel moyen parce qu'il y a de nombreux protocoles opérationnels non-PKIX utilisés qui ne vérifient pas la liaison entre l'entité finale et la clé privée.

   POP est accomplis de différente manières en fonction du type de clé pour laquelle un certificat est demandé. Si une clé peut être utilisée différents but, une méthode appropriée peut être utilisée. Par exemple, une clé qui peut être utilisée pour signer, aussi bien que d'autres but, ne devraient pas être envoyés à la CA/RA pour prouver la possession).

   Cette spécification permet explicitement les cas où une entité finale fournis la preuve significative à une RA et que cette RA atteste à la CA que la preuve requise a été reçue et validée. Par exemple, une entité finale souhaite avoir une clé de signature certifiée, pourrait envoyer la signature appropriée à la RA, qui peut simplement notifier à la CA que l'entité finale a fournis la preuve requise. Bien sûr, une telle situation peut être interdite par stratégie ( ex: les CA peuvent être les seules entités permises à vérifier le POP durant la certification).

Clés de signature

Pour les clés de signature, l'entité finale peut signer une valeur pour prouver la possession de la clé privée.

Clés de chiffrement

   Pour les clés de chiffrement, l'entité finale peut fournir la clé privée à la CA/RA, ou peut être requise pour déchiffrer une valeur pour prouver sa possession de la clé privée. En déchiffrant une valeur qui peut être accomplie soit directement, soit indirectement.

   La méthode directe sert à une RA/CA pour fournir un challenge aléatoire pour lequel une réponse immédiate par l'EE est requise.

   La méthode indirect sert à fournir un certificat qui est chiffré afin que l'EE puisse démontrer sa capacité à déchiffrer le message.

   Cette spécification encourage l'utilisation de la méthode indirecte parce qu'elle ne nécessite pas de messages supplémentaires à envoyer.

Clés d'agrément de clé

Pour les clés d'agrément de clé, l'entité finale et l'entité de gestion de PKI doit établir un clé secrète partagée pour pouvoir prouver que l'entité finale possède la clé privée.

Noter que cela nécessite de n'imposer aucune restriction sur les clés qui peuvent être certifiés par une CA donnée. En particulier, pour les clés Diffie-Hellman, l'entité finale peut librement choisir ses paramètres à condition que la CA puisse générer une paire de clé avec les paramètres appropriés si nécessaire.

Mise à jour de clé de la CA root

   Cette discussion s'applique uniquement aux CA qui sont directement trustés par certaines entités finales. Les CA auto-signés devraient être considérés comme des CA directement trustés. Reconnaître si une CA non auto-signé est supposé être directement trusté par certaines entités finales est une question de stratégie de CA et est hors du scope de ce document.

   La base de la procédure décrite ici est que la CA protège sa nouvelle clé publique en utilisant sa précédente clé privée et vice-versa. Donc, quand une CA met à jour sa paire de clé elle doit générer 2 valeurs d'attribut cACertificate supplémentaires si les certificats sont disponibles en utilisant un annuaire X.500 (pour un total de 4: OldWithOld, OldWithNew, NewWithOld, et NewWithNew).

   Quand une CA change sa paire de clé, ces entités qui ont acquis l'ancienne clé publique de la CA via des moyens tiers sont les plus affectés. Ce sont ces entités finales qui auront besoin d'accéder à la nouvelle clé publique CA protégée avec l'ancienne clé privée CA. Cependant, ils vont seulement avoir besoin de cela pour une période limitée (jusqu'à ce qu'ils aient acquis la nouvelle clé publique). Ce sera facile à accomplir quand les certificats des entités finales expirent.

   La structure de données utilisé pour protéger la nouvelle et l'ancienne clé publique CA est un certificat standard ( qui peut également contenir des extensions). Il n'y a pas de nouvelle structures de données requises.

   Note 1. Ce schéma n'utilise aucune extension X.509 v3 vu qu'il doit être capable fonctionner avec les certificats version 1. La présente de l'extension KeyIdentifier serait cependant plus efficace.

   Note 2. Bien que le schéma pourrait être généralisé pour couvrir des cas où les CA mettent à jours leur paire de clé plus d'une fois durant la période de validité du certificat d'une de ses entités finales, cette généralisation semble d'une valeur douteuse. Ne pas avoir cette généralisation signifie simplement que la période de validité des certificats émis avec l'ancienne paire de clé CA ne peut pas excéder la fin de la période de validité OldWithNew.

   Note 3. Ce schéma s'assure que les entités finales vont acquérir la nouvelle clé publique CA, à la dernière par expiration du dernier certificat qu'ils possèdent qui a été signé avec l'ancienne clé privée de la CA. Les opération de certificat et/ou de mise à jours de clé se produisant à d'autre moments ne nécessitent pas nécessairement cela.

Actions de l'opérateur CA

   Pour changer la clé de la CA, l'opérateur CA effectue:

1. Générer une nouvelle paire de clés
2. Créer un certificat contenant l'ancienne clé publique signée avec la nouvelle clé privée
3. Créer un certificat contenant la nouvelle clé publique signée avec l'ancienne clé privée
4. Créer un certificat contenant la nouvele clé publique CA signée avec la nouvelle clé privée
5. Publier ces nouveaux certificats via le dépôt et/ou d'autres moyens
6. Exporter la nouvelle clé publique CA pour que les entités finales puissent l'acquérir en utilisant un mécanisme externe (si nécessaire).

   L'ancienne clé privée CA n'est ainsi plus requise. Cependant, l'ancienne clé publique CA va continuer à être utilisée pour un certain temps. L'ancienne clé publique CA n'est plus requise ( autre que pour la non-répudiation ) quand toutes les entités finale de cette CA on acquis la nouvelle clé publique CA.

   Le certificat "old with new" doit avoir une période de validité commençant à la date de génération de l'ancienne paire de clé et se terminant à la date d'expiration de l'ancienne lé publique.

   Le certificat "new with old" doit avoir une période de validité commençant à la date de génération de la nouvelle paire de clé et se terminant à la date à laquelle toutes les entités finales de cette CA vont posséder la nouvelle clé publique.

   Le certificat 'new with new' doit avoir une période de validité commençant à la date de génération de la nouvelle paire de clé et se terminant à ou avant la date à laquelle la CA va mettre de nouveau à jour sa paire de clé.

Vérifier les certificats

En vérifiant une signature, le vérificateur vérifie le certificat contenant la clé publique du signataire. Cependant, une fois qu'une CA est autorisée à mettre à jours ses clés il y a de nouvelles possibilités:

- Pour les cas impaires, le signataire des certificats est protégé avec la nouvelle clé publique, dans les cas paires, ce certificat est protégé avec l'ancienne clé publique.
- 2 types de dépôts: le dépôt contient la nouvelle et l'ancienne clé publique ou le dépôt ne contient que l'ancienne clé ( dû à un délay )
- 2 cas de possession de la clé: le PSE contient la nouvelle clé, ou le PSE contient l'ancienne clé.

Cas 1: le dépôt et le PSE contiennent la nouvelle clé: c'est le cas standard où le vérificateur peut directement vérifier le certificat sans utiliser le dépôt.
Cas 2: le dépôt et le PSE contiennent la nouvelle clé: Le vérificateur doit accéder au dépôt pour obtenir la valeur de l'ancienne clé publique
Cas 3: le dépôt a la nouvelle clé, mais pas le PSE. Dans ce cas, le vérifier doit accéder au dépôt pour obtenir la valeur de la nouvelle clé publique.
Cas 4: le dépôt a la nouvelle clé, mais pas le PSE. Le vérificateur peut directement vérifier le certificat sans utiliser le dépôt
Cas 5: Le PSE a la nouvelle clé, mais pas le dépôt. Bien que l'opération CA n'a pas mis à jours le dépôt, le certificat peut être directement validé (identique au cas 1)
Cas 6: Le PSE a la nouvelle clé, mais pas le dépôt. Le vérificateur pense qu'il s'agit d'un situation cas 2 et va accéder au dépôt, cependant, la vérification va échouer.
Cas 7: le dépôt et le PSE contiennent l'ancienne clé: Dans ce cas l'opérateur CA n'a pas mis à jours le dépôt et la vérification va échouer
Cas 8: le dépôt et le PSE contiennent l'ancienne clé: Bien que l'opérateur CA n'a pas mis à jours le dépôt, le vérificateur peut vérifier le certificat directement, (identique au cas 4)

Vérification dans les cas 1,4,5,8

Dans ces cas, le vérificateur n'a pas de copie locale de la clé publique qui peut être utilisée pour vérifier le certificat directement. C'est la même situation où aucune clé n'a été changée. Noter que le cas 8 peut se produire entre le moment où l'opérateur CA a généré la nouvelle paire de clé et le moment où l'opérateur CA stock les attributs mis à jours dans le dépôt. Le cas 5 peut seulement se produire si l'opérateur CA a émis les certificats du signataire et du vérificateur durant cet écart ( L'opérateur CA devrait éviter cela).

Vérification dans le cas 2

Dans le cas 2, le vérificateur doit avoir accès à l'ancienne clé publique de la CA. Le vérificateur fait ceci:

1. Recherche l'attribut caCertificate dans le dépôt et prend le certificat OldWithNew (déterminé sur la période de validité; noter que les champs subject et issuer doivent correspondre).
2. Vérifie que c'est correcte en utilisant la nouvelle clé CA ( que le vérificateur a localement ).
3. Si correct, vérifie le certificat du signataire en utilisant l'ancienne clé CA.

Le cas 2 se produit quand l'opérateur CA a émis le certificat du signataire, puis changé la clé, puis émis le certificat du vérificateur; donc c'est un bon cas typique.

Vérification dans le cas 3

Dans le cas 3, le vérificateur doit avoir accès à la nouvelle clé publique de la CA. Le vérificateur fait ceci:

1. Recherche l'attribut CACertificate dans le dépôt et prend le certificat NewWithOld (déterminé sur la période de validité; le subject et issuer doivent matcher.
2. Vérifie que c'est correct en utilisant l'ancienne clé
3. Si correct, vérifie le certificat du signataire en utilisant la nouvelle clé CA.

Le cas 3 se produit quand l'opérateur CA a émis le certificat du signataire, puis changé la clé, et ainsi émis le certificat du signataire; donc c'est également un cas typique.

Érreur de vérification dans le cas 6

Dans ce cas, la CA a émis le PSE du vérificateur, qui contient la nouvelle clé, sans mettre à jours les attributs du dépôt. Cela signifie que le vérificateur n'a aucun moyen d'obtenir une version trustée de l'ancienne clé de la CA et donc la vérification échoue. Cette erreur est une faute de l'opérateur CA.

Érreur de vérification dans le cas 7

Dans ce cas, la CA a émis le certificat du signataire protégé avec la nouvelle clé sans mettre à jours les attributs du dépôt. Cela signifie que le vérificateur n'a aucun moyen d'obtenir une version trustée de l'ancienne clé de la CA et donc la vérification échoue. Cette erreur est une faute de l'opérateur CA.

Révocation - Changement de la clé CA

Comme vu plus haut, la vérification d'un certificat devient de plus en plus complexe une fois que la CA est autorisée à changer sa clé. C'est également vrai pour les vérifications de révocation vu que la CA peut avoir signé la CRL en utilisant une clé privée plus récente que celle dans le PSE de l'utilisateur.

L'analyse des alternatives est la même que pour la vérification du certificat.

Structures de données

Cette section contient des descriptions des structures de données requise pour les messages de gestion de PKI. La section suivante décris les contraintes sur leur valeurs et la séquence des évènements pour chaque opération de gestion de PKI.

Message PKI

Tous les messages utilisés dans cette spécification pour les buts de gestion de PKI utilisent la structure suivante:
PKIMessage ::= SEQUENCE {
    header PKIHeader,
    body PKIBody,
    protection [0] PKIProtection OPTIONAL,
    extraCerts [1] SEQUENCE SIZE (1..MAX) OF CMPCertificate OPTIONAL
}
PKIMessages ::= SEQUENCE SIZE (1..MAX) OF PKIMessage

PKIHeader contient les informations qui sont communes aux messages PKI
PKIBody contient des informations spécifiques au message
PKIProtection si utilisé, contient les bits qui protègent le message de PKI.
extraCerts peut contenir des certificats qui peuvent être utiles. Par exemple, cela peut être utilisé par une CA ou RA pour présente une entité finale avec les certificats qui sont nécessaires pour vérifier son propre nouveau certificat. (Si, par exemple, la CA qui a émis le certificat EE n'est pas une CA root pour l'EE). Noter que ce champ ne contient pas nécessairement un chemin de certification; le destinataire peut avoir à trier, sélectionner, ou traiter les certificats supplémentaires pour pouvoir les utiliser.

En-tête de message de PKI

   Tous les messages de PKI nécessitent certaines informations d'en-tête pour l'adressage et l'identification de la transaction. Certaines de ces informations vont également être présentes dans une enveloppe spécifique au transport. Cependant, si le message PKI est protégé, alors cette information est également protégée.

La structure de données suivante est utilisée pour contenir cette information:
PKIHeader ::= SEQUENCE {
    pvno INTEGER { cmp1999(1), cmp2000(2) },
    sender GeneralName,
    recipient GeneralName,
    messageTime [0] GeneralizedTime OPTIONAL,
    protectionAlg [1] AlgorithmIdentifier OPTIONAL,
    senderKID [2] KeyIdentifier OPTIONAL,
    recipKID [3] KeyIdentifier OPTIONAL,
    transactionID [4] OCTET STRING OPTIONAL,
    senderNonce [5] OCTET STRING OPTIONAL,
    recipNonce [6] OCTET STRING OPTIONAL,
    freeText [7] PKIFreeText OPTIONAL,
    generalInfo [8] SEQUENCE SIZE (1..MAX) OF InfoTypeAndValue OPTIONAL
}
PKIFreeText ::= SEQUENCE SIZE (1..MAX) OF UTF8String

pvno est fixé à 2 pour cette version de ce document
sender contient le nom de l'émetteur du PKIMessage. Ce nom ( en conjonction avec senderKID, si fournis) devrait être suffisant pour indiquer la clé à utiliser pour vérifier la protection dans le message. Si rien sur l'émetteur n'est connus sur l'entité (ex: dans l'initialisation, un message req, où l'entité finale peut ne pas connaître son propre DN, e-mail, IP, etc), alors ce champ doit contenir une valeur NULL; c'est à dire une séquence de rdn de longueur 0. Dans un tel cas, le champ senderKID doit contenir un identifiant (par ex: un numéro de référence) qui indique au destinataire les information de clé secrète partagée appropriée pour vérifier le message.
recipient Contient le nom du destinataire du PKIMessage. Ce nom ( en conjonction avec recipKID, si fournis ) devrait être utilisable pour vérifier la protection du message.
protectionAlg Spécifie l'algorithme utilisé pour protéger le message. Si aucun bits de protection n'est fournis ( PKIProtection est optionnel ), ce champ doit être omis; si les bits de protection sont fournis, ce champ doit être fournis.
senderKID, recipKID Sont utilisables pour indiquer quelles clés ont été utilisées pour protéger le message. (RecipKID va normalement être requis seulement quand le message est protégé avec des clés DH ). Ces champs doivent être utilisés si nécessaire pour identifier de manière unique une clé et devraient être omis sinon.
transactionID est utilisé pour permettre au destinataire du message de le corréler avec une transaction sortante. C'est nécessaire pour toutes les transactions qui consistent d'une simple paire demande/réponse. Pour ces transactions demande/réponse, les règles sont comme suit. Un client peut populer le champ transactionID de la requête. Si un serveur reçois une telle requête qui a le champ transactionID mis, alors il doit mettre le champ transactionID de la réponse à la même valeur. Si un serveur reçois une telle requête avec un champ transactionID manquant, alors il peut mettre le champ transactionID de la réponse.

   Pour les transaction qui consistent de plus qu'une simple paire demande/réponse, les règles sont comme suit. Les client devraient générer une transactionID pour la première demande. Si un serveur reçoit une telle demande avec le champs transactionID mis, alors il doit mettre le champ transactionID de la réponse à la même valeur. Si un serveur reçois une telle demande sans le champs transactionID, il doit populer ce champs dans la réponse avec un ID généré par le serveur. Les requêtes et réponses suivantes doivent toutes mettre le champs transactionID avec la valeur établie. Dans tous les cas où un transactionID est utilisé, un client ne doit pas avoir plus d'une transaction avec le même transactionID en cours vers un serveur donné. Les serveur sont libre d'imposer ou non l'unicité du transactionID, tant qu'ils sont capable d'associer correctement les messages avec la transaction correspondante.

   Typiquement, cela signifie qu'un serveur va nécessiter que le couple client/transactionID soit unique, ou même le transactionID seul, s'il ne peut pas distinguer les clients basé sur les information au niveau du transport. Un serveur recevant le premier message d'un transaction ( qui nécessite plus d'une paire demande/réponse ) qui contient un transactionID qui ne permet pas de répondre aux contraintes ci-dessus ( généralement parce que le transactionID est déjà utilisé ) doit envoyer un ErrorMsgContent avec un PKIFailureInfo de transactionIdInUse. Il est recommandé que les client utilisent un transactionID avec une donnée pseudo-aléatoire 128-bits pour commencer la transaction pour réduire la probabilité d'avoir un transactionID utilisé par le serveur.

senderNonce, recipNonce protègent le PKIMessage avec les attaques replay. senderNonce est généralement une donnée pseudo-aléatoire 128-bits générée par l'émetteur, et recipNonce est copié de senderNonce du précédent message dans la transaction.
messageTime Contient l'horodatage du moment où l'émetteur a créé le message. Peut être utile pour permettre aux entités finales de corriger/vérifier l'heure local.
freeText Peut être utilisé pour envoyer des données additionnelles au destinataire. Le premier langage utilisé dans cette séquence indique la langue désirée pour les réponses.
generalInfo Peut être utilisé pour envoyer des données additionnelles traitable par la machine au destinataire. Les extentions generalInfo suivantes sont définies et peuvent être supportées:

ImplicitConfirm

C'est utilisé par l'EE pour informer la CA qu'elle ne souhaite pas envoyer une confirmation de certificat pour les certificats émis.
implicitConfirm OBJECT IDENTIFIER ::= {id-it 13}
ImplicitConfirmValue ::= NULL

Si la CA autorise la demande, elle doit placer la même extension dans le PKIHeader de la réponse. Si l'EE ne trouve pas l'extension dans la réponse, elle doit envoyer la confirmation du certificat.

ConfirmWaitTime

C'est utilisé par la CA pour informer l'EE du temps d'attente prévu pour la confirmation de certificat avant de révoque le certificat et supprimer la transaction.
confirmWaitTime OBJECT IDENTIFIER ::= {id-it 14}
ConfirmWaitTimeValue ::= GeneralizedTime

Corps du message PKI

PKIBody ::= CHOICE {
    ir [0] CertReqMessages, --Initialization Req
    ip [1] CertRepMessage, --Initialization Resp
    cr [2] CertReqMessages, --Certification Req
    cp [3] CertRepMessage, --Certification Resp
    p10cr [4] CertificationRequest, --PKCS #10 Cert. Req.
    popdecc [5] POPODecKeyChallContent --pop Challenge
    popdecr [6] POPODecKeyRespContent, --pop Response
    kur [7] CertReqMessages, --Key Update Request
    kup [8] CertRepMessage, --Key Update Response
    krr [9] CertReqMessages, --Key Recovery Req
    krp [10] KeyRecRepContent, --Key Recovery Resp
    rr [11] RevReqContent, --Revocation Request
    rp [12] RevRepContent, --Revocation Response
    ccr [13] CertReqMessages, --Cross-Cert. Request
    ccp [14] CertRepMessage, --Cross-Cert. Resp
    ckuann [15] CAKeyUpdAnnContent, --CA Key Update Ann.
    cann [16] CertAnnContent, --Certificate Ann.
    rann [17] RevAnnContent, --Revocation Ann.
    crlann [18] CRLAnnContent, --CRL Announcement
    pkiconf [19] PKIConfirmContent, --Confirmation
    nested [20] NestedMessageContent, --Nested Message
    genm [21] GenMsgContent, --General Message
    genp [22] GenRepContent, --General Response
    error [23] ErrorMsgContent, --Error Message
    certConf [24] CertConfirmContent, --Certificate confirm
    pollReq [25] PollReqContent, --Polling request
    pollRep [26] PollRepContent --Polling response
}

   Les types spécifiques sont décris plus bas.

Protection de message PKI

   Certains message PKI vont être protéger pour l'intégrité. ( Noter que si un algorithme asymétrique est utilisé pour protéger un message et que le composant publique a déjà été certifié, l'origine du message peut également être authentifié ).

Quand la protection est appliquée, la structure suivante est utilisée:
PKIProtection ::= BIT STRING

L'entrée pour le calcul de PKIProtection est un encodé DER de la structure de données suivante:
ProtectedPart ::= SEQUENCE {
    header PKIHeader,
    body PKIBody
}

   Il peut y avoir des cas dans lesquels la chaîne de bit PKIProtection n'est délibérément pas utilisée pour protéger un message parce que d'autre protection externes sont appliqués à la place. Un tel choix est explicitement permit dans cette spécification. Des exemples de telles protections externes incluent les encapsulations PKCS#7 et Security Multiparts ( rfc1847 ) du PKIMessage ( ou simplement le PKIBody ), si les informations PKIHeader sont gérés de manière sécurisés dans le mécanisme externe. Il est noté, cependant, que de nombreux mécanismes externes nécessitent que l'entité finale possède déjà un certificat et/ou un DN unique, et/ou d'autres informations liées à l'infrastructure.

   Donc, ils peuvent être non appropriés pour un enregistrement initial, récupération de clé, ou tout autre processus avec des caractéristiques de 'boot-strapping'. Pour ces cas il peut être nécessaire que le paramètre PKIProtection soit utilisé. Dans le future, si et quand les mécanismes externes sont modifiés pour ces scénarios, l'utilisation de PKIProtection peut devenir rare ou non-existant.

   En fonction des circonstance, les bits PKIProtection peuvent contenir un MAC ou une signature. Seul les cas suivants peut se produire.

Information de secret partagé

Dans ce cas, l'émetteur et le destinataire partages une information secrète (établie via un moyen externe ou depuis une opération de gestion PKI précédente). PKIProtection va maintenir une valeur MAC et protectionAlg sera:
id-PasswordBasedMac OBJECT IDENTIFIER ::= {1 2 840 113533 7 66 13}
PBMParameter ::= SEQUENCE {
    salt OCTET STRING,
    owf AlgorithmIdentifier,
    iterationCount INTEGER,
    mac AlgorithmIdentifier
}

   Dans protectionAlg ci-dessus, la valeur salt est ajoutée à l'entrée du secret partagé. Le OWF est ainsi appliqué iterationCount fois, où le secret salé est l'entrée de la première itération et, pour chaque itération successive, l'entrée est la sortie de l'itération précédente. La sortie de l'itération finale ( appelée BASEKEY avec une taille H) est ce qui est utilisé pour former la clé symétrique. Si l'algorithme MAC nécessite une clé K-Bits et K ‹= H, alors les bits K les plus signifiant de BASEKEY sont utilisés. Si K › H, alors tout BASEKEY est utilisé pour les bits H les plus signifiant de la clé, OWF('1' || BASEKEY) est utilisé pour les bits H les plus signifiant suivants de la clé, OWF('2' || BASEKEY) est utilisé pour les bits H les plus signifiant suivants de la clé et ainsi de suite, jusqu'à ce que tous les bits K aient été dérivés.

   Note: il est recommandé que les champs de PBMParameter restent constants via les messages d'une simple transaction (ex: ir/ip/certConf/pkiConf) pour pouvoir réduire la charge associé avec le calcul de PasswordBasedMac.

Paires de clé DH

Où l'émetteur et le destinataire possèdent des certificats Diffie-Hellman avec des paramètres DH compatibles, pour pouvoir protéger le message l'entité finale doit générer une clé symétrique basée sur la clé privée DH et la clé publique DH du destinataire de message PKI. PKIProtection contient une valeur MAC protégé avec cette clé symétrique dérivée et protectionAlg sera:
id-DHBasedMac OBJECT IDENTIFIER ::= {1 2 840 113533 7 66 30}
DHBMParameter ::= SEQUENCE {
    owf AlgorithmIdentifier, -- AlgId for a One-Way Function (SHA-1 recommended)
    mac AlgorithmIdentifier -- the MAC AlgId (e.g., DES-MAC, Triple-DES-MAC [PKCS11],
}

   Dans le protectionAlg ci-dessus, OWF est appliqué au résultat du calcul DH. La sortie OWF (appelée BASEKEY, avec une taille H) est ce qui est utilisé pour former la clé symétrique. Si l'algorithme MAC nécessite une clé K-bit et K ‹= H, les bits K les plus signifiant de BASEKEY sont utilisé. Si K › H, tout BASEKEY est utilisé pour les bits H les plus signifiants suivants, OWF('1' || BASEKEY) est utilisé pour les bits H les plus signifiant suivant, OWF('2' || BASEKEY) est utilisé pour les bits H les plus signifiant suivant, et ainsi de suite, jusqu'à ce que les bits K aient été dérivés.

Signature

Dans ce cas, l'émetteur possède une paire de clé de signature et signe simplement le message PKI. PKIProtection va contenir la valeur de signature et protectionAlg sera un AlgorithmIdentifier pour une signature numérique.

Protection Multiple

Dans les cas ou une entité finale envoie un message PKI protégé à une RA, la RA peut transférer ce message à une CA, attachant sa propre protection ( qui peut être un MAC ou une signature, en fonction des informations et des certificats partagés entre la RA et la CA ). C'est accomplis en imbriquant tout le message envoyé par l'entité finale dans un nouveau message PKI. La structure utilisée est:
NestedMessageContent ::= PKIMessages

L'utilisation des PKIMessages, une sequence de PKIMessage, laisse la RA automatiser les requêtes de nombreux EE dans un simple nouveau message. Par simplicité, tous les messages dans le batch doivent être de même type (ex: ir). Si la RA souhaite modifier les messages d'une certaine manière (ex: ajouter des valeur de champ particulier ou de nouvelles extensions), elle peut créer sont propre PKIBody. Le PKIMessage originel de l'EE peut être inclus dans le champ generalInfo de PKIHeader. l'infoType utilisé dans cette situation est {id-it 15} et infoValue est PKIMessages (le contenu doit être dans le même ordre que les demandes dans PKIBody).

Structures de données communes

Avant de spécifier les types spécifique qui peuvent être placés dans un PKIBody, on définis certaines structures qui sont utilisées dans plus d'un cas.

Contenu des certificats demandés

Divers messages de gestion de PKI nécessitent que l'initiateur du message indique certains des champs qui doivent être présent dans un certificat. La structure CertTemplate permet à une entité finale ou une RA de spécifier ce qu'elle souhaite dans le certificat. CertTemplate est identique à une certificat, mais avec tous les champs optionnels.

Noter que même si l'initiateur spécifie complètement le contenus d'un certificat, une CA est libre de modifier les champs dans le certificat qu'elle émet. Si le certificat modifié n'est pas acceptable pour le demandeur, le demandeur doit renvoyer un message certConf qui soit n'inclus pas ce certificat, ou inclus ce certificat ( via un CertHash ) avec un statut "rejected".

Valeurs chiffrées

   Quand des valeurs chiffrées ( restreintes, dans cette spécification, à des clés privées ou des certificats ) sont envoyés dans les messages PKI, la structure de données EncryptedValue est utilisée.

   L'utilisation de cette structure nécessite que le créateur et de destinataire soient capable de chiffrer et déchiffrer, respectivement. Typiquement, cela signifie que l'émetteur et de destinataire aient, ou soient capable de générer une clé secrète partagée.

   Si le destinataire du PKIMessage possède déjà une clé privée utilisable pour le déchiffrement, alors le champ encSymmKey peut contenir une clé de session chiffrée en utilisant la clé publique du destinataire.

Codes de status et information d'erreur pour les messages PKI

Tous les messages de réponse incluent une information de status. Les valeurs suivantes sont définies.
PKIStatus ::= INTEGER {
    accepted (0),
    grantedWithMods (1),
    rejection (2),
    waiting (3),
    revocationWarning (4),
    revocationNotification (5),
    keyUpdateWarning (6)
}

Les répondeurs peuvent utiliser la syntaxe suivante pour fournir certaines informations sur les cas d'erreur
PKIFailureInfo ::= BIT STRING {
    badAlg (0),
    badMessageCheck (1),
    badRequest (2),
    badTime (3),
    badCertId (4),
    badDataFormat (5),
    wrongAuthority (6),
    incorrectData (7),
    missingTimeStamp (8),
    badPOP (9),
    certRevoked (10),
    certConfirmed (11),
    wrongIntegrity (12),
    badRecipientNonce (13),
    timeNotAvailable (14),
    unacceptedPolicy (15),
    unacceptedExtension (16),
    addInfoNotAvailable (17),
    badSenderNonce (18),
    badCertTemplate (19),
    signerNotTrusted (20),
    transactionIdInUse (21),
    unsupportedVersion (22),
    notAuthorized (23),
    systemUnavail (24),
    systemFailure (25),
    duplicateCertReq (26)
}

PKIStatusInfo ::= SEQUENCE {
    status PKIStatus,
    statusString PKIFreeText OPTIONAL,
    failInfo PKIFailureInfo OPTIONAL
}

Identification de certificat

Pour pouvoir identifier des certificats particuliers, la structure de données CertId est utilisée.

Clé publique CA out-of-band

   Chaque CA root doit être capable de publier sa clé publique courante via des moyens externes. Bien que de tels mécanismes soient au-delà du scope de ce document, on définis des structures de données qui peuvent supporter de tels mécanismes.

Il y a généralement 2 méthodes disponibles: soit la CA publie directement son certificat auto-signé, ou cette information est disponible via l'annuaire ( ou équivalent ) et la CA publie un hash de cette valeur pour permettre la vérification de son intégrité avec utilisation.
OOBCert ::= Certificate

   Les champs dans ce certificat sont restreints comme suit:

- Le certificat doit être auto-signé (par ex: la signature doit être vérifiable en utilisant le champ subjectPublicKeyInfo.
- Les champs subject et issuer doivent être identiques
- Si le champ subject est NULL, alors les extensions subjectAltNames et issuerAltNames doivent être présents et avoir la même valeur
- Les valeur de toutes les autres extensions doivent être correct pour un certificat auto-signé.

OOBCertHash ::= SEQUENCE {
    hashAlg [0] AlgorithmIdentifier OPTIONAL,
    certId [1] CertId OPTIONAL,
    hashVal BIT STRING
}

   L'intension de la valeur de hash est que celui qui a reçu de manière sécurisée cette valeur peut vérifier un certificat auto-signé pour cette CA.

Options d'archive

Les demandeurs peuvent indiquer qu'ils souhaitent que la PKI archive une valeur de clé privée en utilisant la structure PKIArchiveOptions.

Information de publication

Les demandeurs peuvent indiquer qu'ils souhaitent que la PKI publient un certificat en utilisant la structure PKIPublicationInfo

Structures POP

Si la demande de certification concerne la signature d'une paire de clé, alors la preuve de possession de la clé privée est démontrée via l'utilisation de la structure POPOSigningKey.
POPOSigningKeyInput ::= SEQUENCE {
    authInfo CHOICE {
        sender [0] GeneralName,
        publicKeyMAC PKMACValue
    },
    publicKey SubjectPublicKeyInfo
}

   D'une autre manière, si la demande de certification est pour une paire de clé de chiffrement, alors la preuve de possession de la clé de privée peut être démontrée d'une des 3 manières suivante:

Méthode indirecte

La CA ne retourne pas un certificat, mais un certificat chiffré ( le certificat chiffré avec une clé symétrique générée aléatoirement, et la clé symétrique est chiffrée avec la clé publique pour laquelle la demande de certificat est faite). L'entité finale prouve sa connaissance de la clé privée à la CA en fournissant le CertHash correct pour ce certificat dans le message certConf. Cela démontre le POP parce que l'EE peut seulement calculer le CertHash correct s'il est capable de récupérer le certificat, et il peut seulement récupérer le certificat s'il est capable déchiffrer la clé symétrique en utilisant sa propre clé privée. Pour que cela fonctionne, la CA ne doit pas publier le certificat tant que le message certConf n'est pas arrivé ( où certHash est utilisé pour démontrer POP).

Protocole Challenge-Response

   L'entité finale s'engage dans un protocole challenge-response ( en utilisant les messages POPODecKeyChall et POPODecKeyResp ) entre CertReqMessages et CertRepMessage -- c'est la méthode directe décrite plus haut. ( Cette méthode est généralement utilisée dans un environnement dans lequel une RA vérifie le POP et créé la demande de certification à la CA. Dans un tel scénario, la CA trust la RA pour avoir validé le POP correctement avant que la RA demande un certificat pour l'entité finale ). Le protocole complet ressemble comme suit:

EE____________RA____________CA
________----_req_----›
________‹---_chall_---
________----_resp_---›
______________________----_req'_---›
______________________‹---_rep_-----
______________________----_conf_---›
______________________‹---_ack_-----
________‹---_rep_-----
________----_conf_---›
________‹---_ack_-----

Ce protocole est plus long qu'un échange triple donné dans le choix 2 ci-dessus, mais permet à une RA d'être impliqué et a la propriété que le certificat n'est pas créé tant que le POS n'est pas complété. Dans certains environnements, un ordre différent peut être requis, tel que ceci ( peut être déterminé par stratégie):
EE____________RA____________CA
----_req_----›
‹---_chall_---
----_resp_---›
______________----_req'_---›
______________‹---_rep_-----
‹---_rep_-----
----_conf_---›
______________----_conf_---›
______________‹---_ack_-----
‹---_ack_-----

   Si la demande de certificat est pour une paire de clé d'agrément de clé (KAK), alors le POP peut être utilisé dans un échange triple décris plus haut pour encoder les paires de clé, avec les changement suivant: (1) le texte entre parenthèses 2) est remplacé avec "ex: le certificat chiffré avec la clé symétrique dérivé de la clé privée KAK de la CA et la clé publique pour laquelle la demande de certification est faite". (2) le premier texte entre parenthèses du champ challenge est remplacé avec "(PreferredSymmAlg et une clé symétrique dérivé de la clé privée KAK de la CA et la clé publique pour laquelle la demande de certificat est faite)". Alternativement, le POP peut utiliser la structure POPOSigningKey comme 4ème alternative pour démontrer le POP si la CA a déjà un certificat DH qui est connu de l'EE.

Les messages challenge-response pour POP d'une clé privée de chiffrement sont spécifié comme suit. Noter que cet échange est associé avec le message de demande de certification précédent by le transactionID utilisé dans le PKIHeader et par la protection appliquée au PKIMessage.
POPODecKeyChallContent ::= SEQUENCE OF Challenge
Challenge ::= SEQUENCE {
    owf AlgorithmIdentifier OPTIONAL,
    witness OCTET STRING,
    challenge OCTET STRING
}

Noter que la taille de Rand doit être approprié pour le chiffrement sous la clé publique de demandeur. Cet entier n'est généralement pas plus long que 64bits, laissant 100 octets pour le champ sender quand le modulo est 1024 bits. Si, dans certains environnements, les noms sont trop long, alors tout ce qui peut rentrer doit être utilisé ( tant que cela inclus au moins un nom commun, et tant que le destinataire est capable de comprendre l'abréviation).
POPODecKeyRespContent ::= SEQUENCE OF INTEGER

Sommaire des options POP

Le texte dans cette section fournis de nombreuses options en respect des techniques POP. En utilisant SK pour Signing Key, EK pour Encryption Key, et KAK pour Key Agreement Key, les techniques peut être listés comme suit:

RAVerified
SKPOP
EKPOPThisMessage
KAKPOPThisMessage
KAKPOPThisMessageDHMAC
EKPOPEncryptedCert
KAKPOPEncryptedCert
EKPOPChallengeResp
KAKPOPChallengeResp

En donnant ce tableau d'options, il est naturel de demander comment une entité finale peut connaître ce qui est supporté par la CA/RA. Les guides suivants devraient clarifier cette situation.

RAVerified Ce n'est pas une décision de l'EE; le RA l'utilise si et seulement si a vérifié le POP avant de transmettre la requête à la CA, donc il n'est pas possible pour l'EE de choisir cette technique.
SKPOP Si l'EE an une paire de clé de signature, c'est la seule méthode POP spécifiée pour l'utilisation dans la requête pour un certificat correspondant.
EKPOPThisMessage, KAKPOPThisMessage Donner on non sa clé privée à la CA/RA est une décision EE. Si l'EE décide de révéler sa clé, alors ce sont les seules méthodes POP disponible dans cette spécification pour l'accomplir.
KAKPOPThisMessageDHMAC L'EE peut seulement utiliser cette méthode si (1) la CA a un certificat DH disponible dans ce but, et (2) l'EE a déjà une copie de ce certificat. Si ces 2 conditions sont remplies, cette technique est clairement supportée et peut être utilisé par l'EE, si désiré.
EKPOPEncryptedCert, KAKPOPEncryptedCert, EKPOPChallengeResp, KAKPOPChallengeResp L'EE choisis une des technique dans le message de demande, en fonction des préférences et du type de clés. L'EE ne fait pas de POP à ce moment là; il indique simplement quelle méthode il souhaite utilisé. Cependant, si la CA/RA répond avec une erreur badPOP, l'EE peut redemander en utilisant une autre méthode. Noter cependant que cette spécification encourage l'utilisation de EncryptedCert et, en outre, dit que le challenge-response devrait être utilisé quand une RA est impliquée et fait la vérification POP. Ainsi, l'EE devrait être capable de prendre une décision intelligente concernant la méthode POP à choisir dans la demande.

Initialisation de la demande

Un message d'initialisation de demande contient comme PKIBody la structure CertReqMessages, qui spécifie les certificats demandés. Typiquement, SubjectPublicKeyInfo, KeyId, et Validity sont les champs qui doivent être fournis pour chaque demande de certificat. Ce message est prévu pour être utilisé par les entité qui s'initialise pour la première fois dans la PKI.

Initialisation de la réponse

Un message d'initialisation de réponse contient comme PKIBody la structure CertRepMessage, qui a pour chaque attribut demandé un champ PKIStatusInfo, un sujet, et possiblement une clé privée (normalement chiffrée avec une clé de session, qui est elle-même chiffrée avec le protocolEncrKey). Noter que si la protection du message est de type secret partagé, tout certificat transporté dans le champ caPubs peut être directement validé comme certificat CA root par l'initiateur.

Demande de certification

Un message de demande de certification contient comme PKIBody une structure CertReqMessages, qui spécifie les certificats demandés. Ce message est prévu pour être utilisé pour les entité PKI existantes qui souhaitent obtenir des certificats additionnels. Alternativement, PKIBody peut être un CertificationRequest. Cette structure peut être requise pour les demande de certificat pour les paires de clé de signature quand l'intéropérabilité avec les anciens systèmes est désirée, mais son utilisation est fortement découragée.

Réponse de certification

Un message de réponse de certification contient comme PKIBody une structure CertRepMessage, qui a la valeur de status pour chaque certificat demandé, et optionnellement une clé publique de CA, des informations d'erreur, un sujet, et une clé privée chiffrée.
CertRepMessage ::= SEQUENCE {
    caPubs [1] SEQUENCE SIZE (1..MAX) OF Certificate OPTIONAL,
    response SEQUENCE OF CertResponse
}

CertResponse ::= SEQUENCE {
    certReqId INTEGER,
    status PKIStatusInfo,
    certifiedKeyPair CertifiedKeyPair OPTIONAL,
    rspInfo OCTET STRING OPTIONAL
         analogue à id-regInfo-utf8Pairs définis pour regInfo dans CertReqMsg
}

CertifiedKeyPair ::= SEQUENCE {
    certOrEncCert CertOrEncCert,
    privateKey [0] EncryptedValue OPTIONAL,
    publicationInfo [1] PKIPublicationInfo OPTIONAL
}

CertOrEncCert ::= CHOICE {
    certificate [0] Certificate,
    encryptedCert [1] EncryptedValue
}

   Seul un champ failInfo (dans PKIStatusInfo) et certificate (dans CertifiedKeyPair) peuvent être présents dans chaque CertResponse (en fonction du statut). Pour certaines valeurs de statut (ex: waiting), aucun des champs optionnels ne sont présents.

   En donnant un EncryptedCert et la clé de déchiffrement, le certificat peut êtr obtenu. Le but de cela est de permettre à une CA de retourner la valeur d'un certificat, mais avec la contrainte que seule le destinataire prévu peut obtenir le certificat. Le bénéfice de cette approche est qu'un CA peut répondre avec un certificat même en l'absence de preuve que le demandeur est l'entité finale qui peut utiliser la clé privée ( noter que la preuve n'est pas obtenue jusqu'à ce que le message certConf soit reçu par la CA). Donc, la CA n'aura pas à révoquer ce certificat dans le cas où quelque-chose ne va pas avec le POP.

Contenu des demandes de mise à jour de clé

Pour les demandes de mise à jour de clé la syntaxe CertReqMessages est utilisée. Typiquement, SubjectPublicKeyInfo, KeyId, et Validity sont les champs fournis pour chaque clé à mettre à jours. Ce message est prévu pour être utilisé pour demanders des mises à jours de certificat existant non-révoqués et non-expirés. Une mise à jours est un remplacement de certificat contenant soit une nouvelle clé publique ou la clé publique courante.

Contenu des réponses de mise à jour de clé

Pour les réponses de mise à jour de clé, la syntaxe CertRepMessage est utilisée. La réponse est identique à la réponse d'initialisation.

Contenu de demande de récupération de clé

Pour les demandes de récupération de clé la syntaxe utilisée est identique à CertReqMessages des demandes d'initialisation. Typiquement, SubjectPublicKeyInfo et KeyId sont les champs qui peuvent être utilisé pour fournir une clé publique de signature pour laquelle un certificat est requis. Noter que si un historique de clé est requis, le demandeur doit fournir un contrôle de clé de chiffrement de protocole dans la demande.

Contenu de réponse de récupération de clé

Pour les réponses de récupération de clé, la syntaxe suivante est utilisée. Pour certaines valeurs de statut (ex: waiting), aucun champ optionnel n'est présent.
KeyRecRepContent ::= SEQUENCE {
    status PKIStatusInfo,
    newSigCert [0] Certificate OPTIONAL,
    caCerts [1] SEQUENCE SIZE (1..MAX) OF Certificate OPTIONAL,
keyPairHist [2] SEQUENCE SIZE (1..MAX) OF CertifiedKeyPair OPTIONAL
}

Contenu de demande de révocation

Pour une demande de révocation d'un ou plusieurs certificats, la structure de données suivante est utilisée. Le nom du demandeur est présent dans la structure PKIHeader
RevReqContent ::= SEQUENCE OF RevDetails
RevDetails ::= SEQUENCE {
certDetails CertTemplate,
crlEntryDetails Extensions OPTIONAL
}

Contenu de réponse de révocation

La réponse de révocation est envoyée au demandeur de la révocation:
RevRepContent ::= SEQUENCE {
    status SEQUENCE SIZE (1..MAX) OF PKIStatusInfo,
    revCerts [0] SEQUENCE SIZE (1..MAX) OF CertId OPTIONAL,
    crls [1] SEQUENCE SIZE (1..MAX) OF CertificateList OPTIONAL
}

Contenu de demande de cross-certification

Les demandes de cross-certification utilisent la même syntaxe (CertReqMessages) que pour les demandes de certification normales, avec comme restriction que la paire de clé doit avoir été générée par la CA demandeur et que la clé privée ne doit pas être envoyée. Cet requête peut également être utilisé par les CA subordonnées pour obtenir leur certificats signés par la CA parent.

Contenu de réponse de cross-certification

Les réponse de cross-certification utilisent la même syntaxe (CertRepMessage) que pour les réponse de certification normales, avec comme restriction qu'aucune clé privée de chiffrement ne peut être envoyée.

Contenu d'annonce de mise à jour de clé CA

Quand une CA met à jours sa propre paire de clé, la structure de données suivante peut être utilisé pour annoncer cet évènement:
CAKeyUpdAnnContent ::= SEQUENCE {
    oldWithNew Certificate,
    newWithOld Certificate,
    newWithNew Certificate
}

Annonce de certificat

Cette structure peut être utilisé pour annoncer l'existence de certificat. Noter que ce message est prévu pour être utilisé pour les cas (s'il y'en a) où il n'y a pas de méthode pré-existante pour la publication de certificats; il n'est pas prévu pour être utilisé où, par exemple, X.500 est la méthode pour la publication de certificats
CertAnnContent ::= Certificate

Annonce de révocation

Quand une CA a été révoquée, ou est en train de révoquer un certificat particulier, elle peut émettre une annonce de cet évènement:
RevAnnContent ::= SEQUENCE {
    status PKIStatus,
    certId CertId,
    willBeRevokedAt GeneralizedTime,
    badSinceDate GeneralizedTime,
    crlDetails Extensions OPTIONAL
}

   Une CA peut utiliser une telle annonce pour alerter ou notifier un sujet que son certificat est révoqué. C'est généralement utilisé quand la demande de révocation en vient pas du sujet concerné. Le champ willBeRevokedAt contient la date à laquelle une nouvelle entrée sera ajoutée aux CRLs concernées.

Contenu de confirmation PKI

Cette structure est utilisée dans le protocole d'échange comme PKIMessage final. Son contenu est le même dans tous les cas -- actullement il n'y a aucun contenu vu que PKIHeader gère toutes les informations requises.
PKIConfirmContent ::= NULL

L'utilisation de ce message pour la confirmation de certificat n'est pas recommandée. certConf devrait être utilisé à la place. Une fois reçu un PKIConfirm pour une réponse de certificat, le destinataire peut le traiter comme un certConf avec tous les certificats acceptés.

Contenu de confirmation de certificat

Cette structure est utilisée par le client pour envoyer une confirmation à la CA/RA pour accepter ou rejeter le certificat.
CertConfirmContent ::= SEQUENCE OF CertStatus
CertStatus ::= SEQUENCE {
    certHash OCTET STRING,
    certReqId INTEGER,
    statusInfo PKIStatusInfo OPTIONAL
}

   Pour un CertStatus particulier, l'omission du champ statusInfo indique l'acceptation du certificat spécifié. Alternativement, des détails de statut explicite peuvent être fournis dans le champ statusInfo.

   Dans CertConfirmContent, l'omission d'une structure CertStatus correspond à un certificat fournis dans la réponse précédente indiquant le rejet du certificat. Donc, un CertConfirmContent vide peut être utilisé pour indiquer le rejet de tous les certificats émis.

Contenu du message général PKI

InfoTypeAndValue ::= SEQUENCE {
infoType OBJECT IDENTIFIER,
infoValue ANY DEFINED BY infoType OPTIONAL
} -- où {id-it} = {id-pkix 4} = {1 3 6 1 5 5 7 4}
GenMsgContent ::= SEQUENCE OF InfoTypeAndValue

Certificat de chiffrement de protocole CA

Peut être utilisé par l'EE pour obtenir un certificat depuis la CA à utiliser pour protéger les informations sensibles durant le protocole:
GenMsg: {id-it 1}, ‹ absent ›
GenRep: {id-it 1}, Certificate | ‹ absent ›

Les EE doivent s'assurer que le certificat correct est utilisé pour ce but.

Types de paire de clé de signature

Peut être utilisé par l'EE pour obtenir la liste des algorithmes de signature dont les valeur de clé publique peuvent être certifiés par la CA. Noter que dans le but de cet échange, rsaEncryption et rsaWithSHA1, par exemple, sont considérés équivalents.
GenMsg: {id-it 2}, ‹ absent ›
GenRep: {id-it 2}, SEQUENCE SIZE (1..MAX) OF AlgorithmIdentifier

Types de paire de clé d'agrément de clé/chiffrement

Peut être utilisé par le client pour obtenir la liste des algorithmes d'agrément de clé/chiffrement dont les valeurs de clé publique peut être certifiés par la CA.
GenMsg: {id-it 3}, ‹ absent ›
GenRep: {id-it 3}, SEQUENCE SIZE (1..MAX) OF AlgorithmIdentifier

Algorithme symétrique préféré

Peut être utilisé par le client pour obtenir l'algorithme de chiffrement préféré de la CA pour les informations confidentielles qui nécessitent d'échanger entre l'EE et la CA.
GenMsg: {id-it 4}, ‹ absent ›
GenRep: {id-it 4}, AlgorithmIdentifier

Paire de clé CA mise à jour

Peut être utilisé par la CA pour annoncer une mise à jour de clé de CA
GenMsg: {id-it 5}, CAKeyUpdAnnContent

CRL

Peut être utilisé par le client pour obtenir une copie de la dernière CRL.
GenMsg: {id-it 6}, ‹ absent ›
GenRep: {id-it 6}, CertificateList

Identifiant d'objet non supporté

C'est utilisé par le serveur pour retourner une liste d'identifiants d'objets qu'il ne reconnaît ou supporte.
GenRep: {id-it 7}, SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER

Paramètres de paire de clé

Peut être utilisé par l'EE pour demander les paramètres de domaine à utiliser pour générer la paire de clé pour certains algorithmes à clé publique. Peut être utilisé, par exemple, pour demander P, Q et G appropriés pour générer la clé DH/DSA, ou pour demander un jeu de courbe elliptique.
GenMsg: {id-it 10}, OBJECT IDENTIFIER -- (Algorithm object-id)
GenRep: {id-it 11}, AlgorithmIdentifier | ‹ absent ›

Un infoValue absent dans GenRep indique que l'algorithme spécifié dans GenMsg n'est pas supporté. Les EE doivent s'assurer que les paramètres sont acceptable et que le message GenRep est authentifié.

passphrase de révocation

Peut être utilisé par l'EE pour envoyer un passphrase à une CA/RA pour authentifier un demande de révocation.
GenMsg: {id-it 12}, EncryptedValue
GenRep: {id-it 12}, ‹ absent ›

Tags de langue supportés

Peut être utilisé pour déterminer le tag de langue approprié à utiliser dans les messages suivants. L'émeteur envoie sa liste de langages supportés ( par ordre de préférence ); le destinataire retourne celui qu'il souhaite utiliser. Si aucun des tags proposés ne sont supportés, une erreur doit être retournée.
GenMsg: {id-it 16}, SEQUENCE SIZE (1..MAX) OF UTF8String
GenRep: {id-it 16}, SEQUENCE SIZE (1) OF UTF8String

Contenu de réponse PKI Général

GenRepContent ::= SEQUENCE OF InfoTypeAndValue

Cette structure de données peut être utilisée par l'EE, CA ou RA pour transporter des informations d'erreur
ErrorMsgContent ::= SEQUENCE {
    pKIStatusInfo PKIStatusInfo,
    errorCode INTEGER OPTIONAL,
    errorDetails PKIFreeText OPTIONAL
}

   Ce message peut être généré à tout moment durant une transaction PKI. Si le client envoie cette requête, le serveur doit répondre avec une réponse PKIConfirm, ou un autre ErrorMsg si une partie de l'en-tête n'est pas valide. Chaque partie doit traiter ce message comme la fin de la transaction (si une transaction est en cours).

   Si la protection est souhaitée dans le message, le client doit le protéger en utilisant la même technique que le message de début de la transaction. La CA doit toujours le signer avec une clé de signature.

Demande et réponse d'interrogation

Cette paire de message est prévue pour manipuler les scénario dans lequel le client a besoin d'interroger le serveur pour déterminer le statut d'une transaction ir, cr, ou kur en cours. (par exemple quand le PKIStatus "waiting" a été reçu).
PollReqContent ::= SEQUENCE OF SEQUENCE {
    certReqId INTEGER }

PollRepContent ::= SEQUENCE OF SEQUENCE {
    certReqId INTEGER,
    checkAfter INTEGER, -- time in seconds
    reason PKIFreeText OPTIONAL }

   Les clauses suivantes décrivent quand les messages d'interrogation sont utilisés, et comment ils sont utilisés. Il est assumé que plusieurs messages certConf peuvent être envoyés durant les transactions. Il y'en aura un envoyé en réponse à chaque ip, cp, kup qui contient un CertStatus pour un certificat émis.

1. En réponse à un message ip, cp, ou kup, un EE va envoyer un certConf pour tous les certificats émis et, suivant le ack, un pollReq pour tous les certificats en attente.
2. En réponse à un message à un pollReq, une CA/RA va retourner un ip, cp, kup si un ou plusieurs certificats sont prêts; sinon, elle retourne un pollRep
3. Si l'EE reçois un pollRep, il attend au moins checkAfter avant d'envoyer un autre pollReq
4. Si nu ip, cd, ou kup est reçu en réponse à un pollReq, alors il sera traité de la même manière que la réponse initiale.

_______________________________START
_________________________________|
_________________________________v
______________________________Send_ir
_________________________________|_ip
_________________________________v
____________________________Check_status
____________________________of_returned_‹------------------------+
_______________________________certs_____________________________|
_________________________________|_______________________________|
_______+------------------------›|‹------------------+___________|
_______|_________________________|___________________|___________|
_______|________(issued)_________v_______(waiting)___|___________|
_____Add_to_‹-----------_Check_CertResponse_------›_Add_to_______|
____conf_list___________for_each_certificate______pending_list___|
_________________________________/_______________________________|
________________________________/________________________________|
___________________(conf_list)_/_____(empty_conf_list)___________|
______________________________/_____________________ip___________|
_____________________________/_________________+----------------+
______(empty_pending_list)__/__________________|____pRep
________END_‹----_Send_certConf_________Send_pReq------------›Wait
_________________________|_________________^___^_______________|
_________________________|_________________|___|_______________|
_________________________+-----------------+___+---------------+
____________________________(pending_list)

Dans l'échange suivant, l'EE s'enregistre pour 2 certificats en une seule demande:
Step__End_Entity_______________________PKI
____1___Format_ir
____2____________________-›_ir______-›
____3____________________________________Handle_ir
____4____________________________________Manual_intervention_is
_________________________________________required_for_both_certs.
____5____________________‹-_ip______‹-
____6___Process_ip
____7___Format_pReq
____8____________________-›_pReq_____-›
____9____________________________________Check_status_of_cert_requests
____10___________________________________Certificates_not_ready
____11___________________________________Format_pRep
____12___________________‹-_pRep_____‹-
____13__Wait
____14__Format_pReq
____15___________________-›_pReq_____-›
____16___________________________________Check_status_of_cert_requests
____17___________________________________One_certificate_is_ready
____18___________________________________Format_ip
____19___________________‹-_ip_______‹-
____20__Handle_ip
____21__Format_certConf
____22___________________-›_certConf_-›
____23___________________________________Handle_certConf
____24___________________________________Format_ack
____25___________________‹-_pkiConf___‹-
____26__Format_pReq
____27___________________-›_pReq_____-›
____28___________________________________Check_status_of_certificate
____29___________________________________Certificate_is_ready
____30___________________________________Format_ip
____31___________________‹-_ip_______‹-
____31__Handle_ip
____32__Format_certConf
____33___________________-›_certConf_-›
____34___________________________________Handle_certConf
____35___________________________________Format_ack
____36___________________‹-_pkiConf__‹-

Fonctions de gestion de PKI obligatoire

Cette section décris les fonctions qui sont obligatoires dans le sens que toutes les implémentations EE, CA et RA doivent être capable de fournir les fonctionnalités décrites.

Initialisation de la CA root

Une CA root nouvellement créée doit produire un certificat auto-émis, qui est une structure Certificate avec le profile définis pour le certificat "newWithNew" émis par la mise à jours de la clé CA.

Pour que le certificat de la CA soit utile aux entités finales qui ne l'obtiennent pas par des moyens tiers, la CA doit également produire une empreinte pour son certificat. La structure de données utilisée pour gérer l'empreinte est OOBCertHash.

Mise à jours de la clé CA

Les clés CA ( comme toutes les autres clés) on une durée de vie finie et doivent être mis à jours périodiquement. Les certificats NewWithNew, NewWithOld, et OldWithNew peuvent être émis par la CA pour aider les EE existantes qui possèdent l'ancien certificat auto-signé (OldWithOld) à passer de manière sécurisée au nouveau certificat (NewWithNew), et pour aider les nouvelles entités qui ont NewWithNew à obtenir OldWithOld pour la vérification de donné existante.

Initialisation de CA subordonnée

Du point de vue des protocoles de gestion de PKI, l'initialisation d'une CA subordonnée est la même que l'initialisation d'un entité finale. La seule différence est que la CA subordonnée doit également produire une liste de révocation initiale.

Production de CRL

Avant d'émettre des certificats, une CA nouvellement établie ( qui émet des crls ) doit produire des versions vides de chaque CRL qui sont périodiquement produites.

Demande d'information PKI

   Quand une entité PKI (CA, RA, ou EE) souhaite acquérir des informations sur le status courant d'une CA, elle peut lui envoyer une demande pour de telles informations.

   La CA doit répondre à le demande en fournissant toutes les informations demandées. Si certaines informations ne peuvent pas être fournies, une erreur doit être retournée.

   Si des PKIMessages sont utilisés pour demander et fournir cette information, alors la requête doit être le message GenMsg, la réponse doit être le message GenRep, et l'erreur doit être le message Error. Ce messages sont protégés en utilisant un MAC basé sur une information de secret partagé, ou en utilisant un autre moyen authentifié (si l'EE a un certificat existant).

Cross Certification

Le demandeur CA est la CA qui va devenir le sujet du cross-certificat; le répondeur CA va devenir l'émetteur du cross-certificat. Le demandeur CA doit être "up and running" avant d'initialiser l'opération de cross-certification.

Schéma demande-réponse une voie

   Le schéma de cross-certification est essentiellement une opération one-way; c'est à dir, quand réussit, cette opération résulte en la création d'un nouveau cross-certificat. Si le pré-requis est que ce cross-certificat soit créé dans les 2 direction, alors chaque CA, en retour, doit initialiser une opération de cross-certification ( ou utiliser un autre schéma ).

   Ce schéma est prévu quand les 2 CA en question peuvent déjà se vérifier mutuellement leur signature. Description détaillée:

   La cross certification est initiée à une CA connue comme répondeur. L'administrateur CA pour le répondeur identifie la CA qu'il veut cross certifier et l'équipement du répondeur génère un code d'autorisation. L'administrateur du répondeur passe ce code d'autorisation à la CA demandeuse via un moyen externe à l'administrateur de la CA demandeuse, qui utilise ce code pour initier l'échange on-line.

   Le code d'autorisation est utilisé pour l'authentification et l'intégrité. C'est fait en générant une clé symétrique basée sur le code d'autorisation et en utilisant la clé symétrique pour générer des MAC pour tous les messages échangés. ( Une authentification peut alternativement être faite en utilisant les signature au lieu des MAC, si les CA sont capable de récupérer et valider les clés publiques requise.)

   La CA demandeuse initie l'échange en générant un demande de cross-certification ( ccr ) avec un nouveau nombre aléatoire. La CA demandeuse envoie le message ccr au répondeur. Les champs dans ce message sont protégés des modification avec un MAC basé sur le code d'autorisation.

   À la réception du message ccr, le répondeur valide le message et le MAC, sauvegarde le nombre aléatoire du demandeur, et génère son propre nombre aléatoire. Il génère ainsi un nouveau certificat qui contient la clé publique de la CA demandeuse et est signée avec la clé privée du répondeur. Le répondeur répond avec un message ccp. Les champs dans ce message sont protégés des modification avec un MAC basé sur le code d'autorisation.

   À la réception du message ccp, la CA demandeuse valide le message et le MAC. la CA demandeuse répond avec le message certConf. Les champs dans ce message sont protégés des modifications avec un MAC basé sur le code d'autorisation. La CA demandeuse peut écrire le certificat dans le dépôt comme aide pour la construction de future chemins de certificats.

   Une fois le message certConf reçu, le répondeur valide le message et le MAC, et envoi un accusé en utilisant le message PKIConfirm. Il peut également publier le certificat.

Notes

1. Le message ccr doit contenir une demande de certification complète: c'est à dire, tous les champs exceptés le numéro de série doivent être spécifiés par la CA demandeuse.
2. Le message ccp devrait contenir le certificat de vérification du répondeur; si présent, la CA demandeuse doit vérifier ce certificat.

Une version plus simple et non-interactive de la cross-certification peut également être envisagé, dans lequel la CA émettrice obtient la clé publique de la CA depuis un dépôt, la vérifie via un mécanisme externe, et créé et publie le cross-certificat sans le concours explicite de la CA.

Initialisation de l'entité finale

Comme avec les CA, les entités finales doivent être initialisées. L'initialisation des entités finales nécessite au moins 2 étapes:

- Acquisition des informations de la PKI
- Vérification tiers d'une clé publique de CA root

Acquisition d'information PKI

Les informations requises sont:

- La clé publique de la CA racine courante
- (Si la CA certifiante n'est pas la CA racine) le chemin de certification depuis la CA racine jusqu'à la CA certifiante, avec les listes de révocation appropriés.
- Les algorithmes et paramètres d'algorithme que la CA certifiante supporte pour chaque utilisation.

Des informations additionnelles peuvent être requises ( ex: extensions supportées ou informations de stratégie de CA) pour pouvoir produire une demande de certification qui sera réussie. Cependant, par simplicité, on n'oblige par l'EE d'obtenir ces information via les messages PKI. Le résultat final est simplement que certaines demandes de certification peuvent échouer (ex: si l'EE veut générer sa propre clé de chiffrement, mais que la CA ne le permet pas).

Vérification Out-of-Band de la clé CA racine

Une EE doit posséder de manière sécurisée la clé publique de sa CA racine. Une méthode consiste à fournir à l'EE une empreinte du certificat de la CA via un moyen externe sécurisé. L'EE peut ainsi utiliser le certificat de la CA.

Demande de certificat

Une EE initialisée peut demander un certificat additionnel à tout moment. Cette demande sera faite en utilisant le message de demande de certification (cr). Si l'EE possède déjà une paire de clé de signature ( avec un certificat de vérification correspondant ), alors ce message cr sera protégé par la signature numérique de l'entité. La CA retourne le nouveau certificat dans un CertRepMessage.

Mise à jour de clé

Quand une paire de clé va expirer, l'entité finale peut demander une mise à jour de clé; c'est à dire, qu'elle peut demander à la CA d'émettre un nouveau certificat pour une nouvelle paire de clé (ou, dans certaines circonstances, un nouveau certificat pour la même paire de clé (. La demande est faite en utilisant un message de demande de mise à jour de clé (kur). Si l'EE possède déjà une paire de clé de signature ( avec le certificats de vérification correspondant ), alors ce message sera typiquement protégé par la signature numérique de l'entité. La CA retourne le nouveau certificat ( si la demande est réussie) dans une réponse de mise à jour de clé (kup), qui est syntaxiquement identique à un CertRepMessage.

Négociation de version

   Cette section définis la négociation de version utilisée pour supporter d'anciens protocoles entre client et serveurs.

   Si un client connaît les versions de protocoles supportés par le serveur (ex: depuis un précédent échange PKIMessage ou via un moyen externe ), il doit envoyer un PKIMessage avec la version la plus haute supportée par lui et le serveur. Si un client ne connaît pas les versions supportées par le serveur, il doit envoyer un PKIMessage en utilisant la version la plus élevée qu'il supporte.

   Si un serveur reçoit un message avec une version qu'il supporte, alors la version du message de réponse doit être la même que la version reçue. Si un serveur reçoit un message avec une version plus élevée ou moins élevée qu'il ne supporte, il doit envoyer en ErrorMsg avec le bit unsupportedVersion ( dans le champ failureInfo de pKIStatusInfo ). Si la version reçue est supérieur à la versions supportée, la version dans le message d'erreur doit être la plus haute version que le serveur supporte; si la version reçue est inférieur à la version la plus basse supportée par le serveur alors la version dans le message d'erreur doit être la version la plus basse que le serveur supporte.

   Si un client reçoit un ErrorMsgContent avec le bit unsupportedVersion et une version qu'il supporte, il peut retenter la requête avec cette version.

Support des implémentation rfc2510

La rfc2510 ne spécifie pas le comportement des implémentation recevant des versions qu'il ne comprend pas vu qu'il ne comprend qu'une seule version. Avec l'introduction de cette révision, le comportement suivant sur le versionning est recommandé.

Clients parlant aux serveurs rfc2510

Si, après avoir envoyé un message cmp2000, un client reçois un ErrorMsgContent avec une version de cmp1999, alors il doit annuler la transaction. Il peut ensuite retenter la transaction en utilisant des message cmp1999.

Si un client reçois un PKIMessage non-erreur avec une version de cmp1999, il peut décider de continuer la transaction en utilisant les sémantiques rfc2510. S'il choisis de ne pas le faire et que la transaction n'est pas terminée, il doit annuler la transaction et envoyer un ErrorMsgContent avec une version de cmp1999.

Serveurs reçevant des PKIMessage cmp1999

Si un serveur reçoit un message cmp1999, il peut revenir à un comportement rfc2510 et répondre avec des messages cmp1999. S'il choisi de ne pas le faire, il doit envoyer un ErrorMsgContent.

Considérations de sécurité

POP avec une clé de déchiffrement

Dans les protocoles spécifiés avant, quand une entité finale doit prouver la possession d'un clé de déchiffrement, il est effectivement challengé pour déchiffrer quelque-chose (son propre certificat). Ce schéma (et beaucoup d'autres) peut être vulnérable à une attaque si le propriétaire de la clé de déchiffrement en question peut être dupé en déchiffrant un challenge arbitraire et en retournant le texte en clair à un attaquant. Bien que dans cette spécification, d'autres problèmes de sécurité sont requis pour que cette attaque réussise, il est concevable que des services futures pourraient être vulnérable à de telles attaques. Pour cette raison, on réitère la règle générale que les implémentations devraient suivre sur le déchiffrement arbitraire et la révélation du texte récupéré.

POP en exposant la clé privée

Noter également qu'exposer une clé priée à la CA/RA comme technique POP peut exposer à des risques de sécurité. Les implémenteurs doivent faire preuve de prudence en sélectionnant et utilisant ce mécanisme POP particulier.

Appendice A. Raisons de la présence des RA

Les raisons qui justifient la présence d'un RA peut être séparés en ceux, d'un part, qui sont dûs à des facteurs techniques, et ceux qui d'autre part sont de nature organisationnelles. Les raisons techniques sont les suivante:

- Si des jetons hardwares sont utilisé, toutes les entités finales n'ont pas l'équipement nécessaire à les initialiser; l'équipement RA peut inclure les fonctionnalités nécessaires.
- Certaines entités finales peuvent ne pas avoir la capacité de publier les certificats; de même, la RA peut être utilisé pour cela.
- La RA sera capable d'émettre des demandes de révocation signées à la demande des entités finales associées avec elle, alors que l'entité final peut ne pas être en mesure de le faire ( Si la paire de clé est complètement perdue ).

Certaines raisons organisationnelles qui demandent la présente d'une RA sont:

- Il peut y avoir une raison de coût de concentrer les fonctionnalités dans un équipement RA plutôt que de fournir ces fonctionnalités à tous les EE.
- Établir des RA dans une organisation peut réduire le nombre de CA requises, ce qui est parfois désirable
- Pour beaucoup d'applications, Il y aura déjà en place une structure administrative pour que les candidats pour le rôle de RA soit facile à trouver.

Appendice B. Utilisation de passphrase de révocation

   Une demande de révocation doit incorporer des mécanismes de sécurité prévu, incluant une authentification propre, pour réduire la probabilité d'attaques DOS réussies. Une signature numérique dans la requête peut fournir l'authentification requise, mais il y a des circonstances sous lesquelles un mécanisme alternatif peut être souhaité (par ex: quand une clé privée n'est plus accessible et que l'entité souhaite demander une révocation avant de re-certifier une autre paire).

   Pour de telles circonstances, un PasswordBasedMac dans la demande est également obligatoire pour supporter cette spécification si les demandes de révocations sont également supportées et si les informations de secret partagé peuvent être établis entre le demandeur et le répondeur avant le besoin de révocation.

   Un mécanisme qui est utilisé dans certains environnement est la passphrase de révocation, dans lequel une valeur d'entropy suffisante ( ex: une passphrase relativement plus longue qu'un mot de passe court) est partagé entre (seulement) l'entité et la CA/RA à un certain moment avant la révocation; cette valeur est ensuite utilisé pour authentifier la demande de révocation.

   Dans cette spécification, la technique suivante pour établir une information à secret partagé est optionnelle. Son utilisation précise dans les messages CMP sont comme suit.

   L'OID et la valeur spécifié dans la section "passphrase de révocation" peuvent être envoyé dans un message GenMsg à tout moment, ou peut être envoyé dans le champ generalInfo du PKIHeader d'un PKIMessage a tout moment. ( En particulier, EncryptedValue peut être envoyé dans l'en-tête du message CertConf qui confirme l'acceptation des certificats requis dans une demande d'initialisation ou une demande de certification.). Cela transmet une passphrase de révocation choisie par l'entité ( ex: les octets déchiffrés du champ encValue) à la CA/RA; en outre, le transfert est accomplis avec les caractéristiques de confidentialité appropriés ( parce que la passphrase est chiffrée avec le protocolEncryptionKey de la CA/RA).

   Si une CA/RA reçois la passphrase de révocation dans un GenMsg, elle doit construire et envoyer un message GenRep qui inclus l'OID ( avec une valeur absente) spécifiée dans la section "passphrase de révocation". Si la CA/RA reçois la passphrase de révocation dans le champ generalInfo d'un PKIHeader d'un PKIMessage, elle doit inclure l'OID ( avec une valeur absente) dans le champ generalInfo du PKIHeader du PKIMessage de réponse correspondant. Si la CA/RA n'arrive pas à retourner le message de réponse approprié, elle doit envoyer un message d'erreur avec un status de rejet et optionnellement, un jeu de raison failInfo.

   Le champ valueHint de EncryptedValue peut contenir un identifiant de clé (choisi par l'entité finale, avec la passphrase elle-même) pour assister à la récupéraion de la passphrase correcte (ex, quand la demande de révocation est construite par l'entité et reçue par la CA/RA).

   Le messages de demande de révocation est protégé par un PasswordBasedMac, avec la passphrase de révocation comme clé. Si approprié, le champ senderKID dans le PKIHeader peut contenir la valeur précédemment transmise dans valueHint.

   En utilisant la technique spécifiée ci-dessus, la passphrase de révocation peut être initialement établie et mise à jour à tout moment sans nécessiter de messages supplémentaires ou d'échange externes. Par exemple, le message de demande de révocation lui-même (protégé et authentifié via un MAC qui utilise la passphrase de révocation comme clé) peut contenir, dans le PKIHeader, une nouvelle passphrase de révocation à utiliser pour authentifier de futures demandes de révocation pour tout autre certificat de l'entité. Dans certains environnements cela peut être préférable aux mécanismes qui révèlent la passphrase dans le message de demande de révocation, vu que cela peut permettre une attaque DOS dans laquelle la passphrase révélée est utilisée par un tier non-autorisé pour authentifier les demandes de révocation pour les autres certificat de l'entité. Cependant, parce que la passphrase n'est pas révélée dans la requête, il n'y a pas de pré-requis pour que la passphrase soit toujours mise à jours quand la demande de révocation est faite ( c'est à dire, la même passphrase peut être utilisée par une entité pour authentifier les demandes de révocation pour différents certificats à différents moments).

   De plus, la technique ci-dessus peut fournir une protection cryptographique forte sur tout le message de demande de révocation même quand une signature numérique n'est pas utilisée. Les techniques qui font de l'authentification de la demande de révocation en révélant simplement la passphrase de révocation ne fournissent pas de protection cryptographique sur les champs du message (donc une demande de révocation d'un certificat peut être modifié par un tier non autorisé pour révoquer un autre certificat pour cette entité).

Appendice C - Clarification du conportement des messages de demande

Dans le cas des mises à jours de la rfc4211, qui apporte des problème d'interprétation ou d'intéropérabilité, la rfc4211 devrait être le document normatif. Les définitions suivante viennent de la rfc4211. Elles sont inclues ici pour codifier les clarifications de comportement; sinon toutes les syntaxes et sémantiques sont identiques à la rfc4211.
CertRequest ::= SEQUENCE {
    certReqId INTEGER,
    certTemplate CertTemplate,
    controls Controls OPTIONAL }

-- Si certTemplate est une séquence vide, alors les contrôles peuvent contenir le contrôle
-- id-regCtrl-altCertTemplate, spécifiant un template pour un certificat autre qu'un
-- certificat à clé-publique x509v3. Inversement, si certTemplate n'est pas vide (au moins
-- un champ est présent), alors les contrôles ne doivent pas contenir id-regCtrl-altCertTemplate.
-- Le nouveau contrôle est définis comme suit:

id-regCtrl-altCertTemplate OBJECT IDENTIFIER ::= {id-regCtrl 7}
AltCertTemplate ::= AttributeTypeAndValue

POPOSigningKey ::= SEQUENCE {
    poposkInput [0] POPOSigningKeyInput OPTIONAL,
    algorithmIdentifier AlgorithmIdentifier,
    signature BIT STRING }

-- La signature (en utilisant AlgorithmIdentifier) est dans la valeur encodée DER de poposkInput.
-- Note: si CertReqMsg certReq certTemplate ( ou le contrôle altCertTemplate) contient les valeurs
-- subject et publicKey, alors poposkInput doit être omis et la signature doit être calculée dans
-- la valeur encodée DER de CertReqMsg certReq ( ou la valeur encodée DER de AltCertTemplate).
-- Si certTemplate/altCertTemplate ne contient ni le sujet ni la clé publique, poposkInput doit
-- être présent et doit être signé.

POPOPrivKey ::= CHOICE {
    thisMessage [0] BIT STRING,

-- Le type de "thisMessage" est donné en chaîne de bit dans la rfc4211; mais devrait être un
-- "EncryptedValue", en accord avec cette spécification.

    subsequentMessage [1] SubsequentMessage,
    dhMAC [2] BIT STRING }

Appendice D. profils de messages de gestion

Cet appendice contient les profils détaillés pour ces PKIMessages qui doivent être supportés par les implémentations conformes. Les profils pour les PKIMessages utilisés dans les opérations de gestion PKI suivant sont fournis:

- Enregistrement/certification initiale
- Schéma authentifié de base
- Demande de certificat
- Mise à jour de clé

Règles générales pour l'interprétation de ces profils

1. Où les champs OPTIONAL ou DEFAULT ne sont pas mentionnés dans les profiles, ils doivent être absent du message. Les champs obligatoire ne sont pas mentionnés s'il ont une valeur évidente. (ex dans la version de cette spécification, pvno est toujours 2).
2. Où les structures se trouvent dans plus d'un message, elles sont profilés séparément comme appropriées.
3. Les algorithmIdentifier des structures PKIMessage sont profilés séparément.
4. Un DN X.500 spécial est appelé le "NULL-DN"; cela signifie un DN contenant une séquence RelativeDistinguishedNames de longueur 0 (son encodé DER est alors '3000'H).
5 Où un GeneralName est requis pour un champ, mais qu'aucune valeur prévue n'est disponible (ex: une entité produit une demande avant de connaître son nom), alors le GeneralName doit être un NULL-DN. Cette valeur spéciale peut être appelée NULL-GeneralName.
6. Où un profil omit de spécifier la valeur pour un GeneralName, la valeur NULL-GeneralName doit être présente dans le champs PKIMessage concerné.
7. Où toute ambiguïté peut se produire à cause du nommage des champs, le profile les nomme en utilisant une notation "point" (ex: certTemplate.subject signifie le champ subject dans un champ appelé certTemplate).
8. Où une séquence de types fait partie d'un message, une notation en tableau basé sur des 0 est utilisée pour décrire les champs dans la séquence (ex: crm[0].certReq.certTemplate.subject réfère à un sous-champ du premier CertReqMsh contenu dans un message de demande).
9. Tous les échanges de message PKI décris plus bas dans cet appendice nécessitent qu'un message certConf soit envoyé par l'entité qui initie et un PKIConfirm par l'entité qui répond. Le PKIConfirm n'est pas inclus dans certains profiles donnés vu que sont contenu est NULL et son header peut être utilisé pour le protectionAlg.

Utilisation des algorithmes

   La table suivante contient les définitions de l'utilisation d'algorithme dans les protocoles de gestion PKI. Les colonnes dans la table sont:

Name: Un identifiant utilisé pour les profiles de message
Use: Une description d'ou et pourquoi l'algorithme est utilisé
Mandatory: Un AlgorithmIdentifier qui doit être supporté par les implémentations conformes.
others: Alternatives à AlgorithmIdentifier.

Name_________Use________________________________________________Mandatory__________________Others
MSG_SIG_ALG__Protection des messages en utilisant une signature_DSA/SHA-1__________________RSA/MD5,ECDSA,...
MSG_MAC_ALG__Protection des messages en utilisant MAC___________PasswordBasedMac___________HMAC, X9.9,...
SYM_PENC_ALG_Chiffrement symétrique de la clé privée de l'EE____3-DES (3-key-EDE,CBC mode)_AES,RC5,CAST-128,...
PROT_ENC_ALG_Chiffrement asymétrique de la clé privée___________D-H________________________RSA,ECDH,...
PROT_SYM_ALG_Chiffrement symétrique des bits de la clé privée___3-DES (3-key-EDE,CBC mode)_AES,RC5,CAST-128,...

AlgorithmIdentifier mandatoire et spécifications:
DSA/SHA-1:
    AlgId: {1 2 840 10040 4 3};

Digital Signature Standard [FIPS-186]
    Public Modulus size: 1024 bits.

PasswordBasedMac:
    AlgId: {1 2 840 113533 7 66 13}, avec SHA-1 {1 3 14 3 2 26} et HMAC-SHA1 {1 3 6 1 5 5 8 1 2};

Secure Hash Standard [FIPS-180] and [RFC2104]
    HMAC key size: 160 bits (i.e., "K" = "H" in Section 5.1.3.1, "Shared secret information")

3-DES:
    AlgId: {1 2 840 113549 3 7}; (used in RSA's BSAFE and in S/MIME).

D-H:
    AlgId: {1 2 840 10046 2 1};

[ANSI-X9.42]
    Public Modulus Size: 1024 bits.
    DomainParameters ::= SEQUENCE {
        p INTEGER, -- odd prime, p=jq +1
        g INTEGER, -- generator, g^q = 1 mod p
        q INTEGER, -- prime factor of p-1
        j INTEGER OPTIONAL, -- cofactor, j›=2
        validationParms ValidationParms OPTIONAL
    }
    ValidationParms ::= SEQUENCE {
        seed BIT STRING, -- seed for prime generation
        pGenCounter INTEGER -- parameter verification
    }

Profile POP

Les champs POP utilisé (dans le champ signature du champ pop de la structure ProofOfPossession) en prouvant la possession d'une clé privée de signature qui correspond à une clé publique de vérification pour laquelle un certificat a été demandé.
Field_______________Value_________Comment
algorithmIdentifier_MSG_SIG_ALG___Seul la protection de la signature est permise pour cette preuve
signature___________present_______bits calculés en utilisant MSG_SIG_ALG

La preuve de possession d'une clé privée de déchiffrement qui correspond à une clé public de chiffrement pour laquelle un certificat a été demandé n'utilise pas ce profile; le champ CertHash du message certConf est utilisé à la place.

Toutes les CA/RA ne font pas de POP dans le protocole de demande de certification ( comment POP est faite peut être un problème de stratégie explicite pour une CA). Cependant, cette spécification mandate que les entités CA/RA doivent faire une POP comme partie du processus de certification. Toutes les entités finales doivent être préparée à fournir une POP.

Enregistrement/certification initial - schéma authentifié de base

   Une entité finale ( non initialisée ) demande un (premier) certificat à une CA. Quand la CA répond avec une message contenant un certificat, l'EE répond avec une confirmation de certificat. La CA envoie en PKIConfirm en retour, terminant la transaction. Tous les message sont authentifiés.

   Ce schéma permet à l'EE de demander une certification d'une clé publique générée localement (typiquement une clé de signature). L'EE peut également choisir de demander la génération et la certification centralisée d'une autre paire de clé (typiquement une paire de clé de chiffrement). La certification peut seulement être demandée pour en clé publique générée localement.

   L'EE doit supporter le POP d'une clé privée, associée avec la clé publique générée localement.

  Préconditions:

1. L'EE peut authentifier la signature de la CA via un moyen externe
2. L'EE et la CA partage une clé MAC symétrique

Flux de messages:
Step#_End_entity___________________________PKI
______1___format_ir
______2______________________-›___ir______-›
______3________________________________________handle_ir
______4________________________________________format_ip
______5______________________‹-___ip______‹-
______6___handle_ip
______7___format_certConf
______8______________________-›___certConf_-›
______9________________________________________handle_certConf
_____10________________________________________format_PKIConf
_____11______________________‹-___PKIConf__‹-
_____12___handle_PKIConf

   Pour ce profile, on mandate que l'EE doit inclure tous CertReqMsg dans un simple PKIMessage, et que le PKI (CA) doit produire une seul réponse PKIMessage qui contient la réponse complète (ex: incluant la seconde paire de clé optionnelle, s'il elle a été demandée et si la génération de la clé centralisée est supportée). Par simplicité, on mandate également que ce message doit être le final (ex: pas d'utilisation du status "waiting").

   L'EE a une interaction out-of-band avec la CA/RA. Cette transaction établis le secret partagé, le referenceNumber et optionnellement le dn utilisé pour sender et subject dans le template du certificat. Il est recommandé que le secret partagé ait au moins 12 caractères de long.

Demande de certificat

Une EE (initialisé) demande un certificat depuis une CA. Quand la CA répond avec un message contenant un certifica, l'EE répond avec une confirmation de certificat. La CA répond avec un PKIConfirm, pour terminer la transaction. Tous les messages sont authentifiés. Le profile pour cet échange est identique à celui donné précédemment excepté:

- Le nom de l'émetteur devrait être présent
- protectionAlg de MSG_SIG_ALG doit être supporté ( MSG_MAC_ALG peut l'être également) dans le demande, la réponse, certConfirm et les PKIMessages.
- senderKID et recipKID sont seulement présents si requis pour la vérification du message
- body est cr ou cp
- body peut contenir une ou 2 structures CertReqMsg, mais CertReqMsg peut être utilisé pour demander une certification d'une clé publique générée localement ou une clé publique générée centralement.
- Les bits de protection sont calculés en accord avec le champ protectionAlg

Demande de mise à jour de clé

Une entité finale ( initialisée ) demande un certificat à une CA ( pour mettre à jours la paire de clé et/ou le certificat correspondant qu'il possède déjà ). Quand la CA répond avec un message contenant un certificat, l'EE répond avec une confirmation de certificat. La CA répond avec un PKIConfirm, pour terminer la transaction. Tous les messages sont authentifiés. Le profile pour cet échange est identique à celui donné précédemment excepté:

- Le nom de l'émetteur devrait être présent
- protectionAlg de MSG_SIG_ALG doit être supporté ( MSG_MAC_ALG peut l'être également) dans le demande, la réponse, certConfirm et les PKIMessages.
- senderKID et recipKID sont seulement présents si requis pour la vérification du message
- body est kur ou kup
- body peut contenir une ou 2 structures CertReqMsg, mais CertReqMsg peut être utilisé pour demander une certification d'une clé publique générée localement ou une clé publique générée centralement.
- Les bits de protection sont calculés en accord avec le champ protectionAlg
- regCtrl OldCertId devrait être utilisé

Appendice E: Profile de message de gestion PKI

Cet appendice contient les profile pour les PKIMessages qui peuvent être supportés par les implémentations. Les profiles pour les PKIMessages utilisé dans les opération de gestion PKI suivant sont fournis:

- Mise à jours de clé CA racine
- Demande/réponse d'informations
- Demande/réponse de cross-certification
- Initialisation in-band en utilisant en certificat d'identité externe.

Certificats auto-signés

Le profile sur la manière dont un certificat peut être auto-signé. Ces structures sont utilisées pour les distributions de clés publiques de CA. Cela peut se produire d'une des 3 manières.
Type________Fonction
newWithNew__Une vrai certificat auto-signé; la clé publique contenue doit être utilisable pour vérifier la signature
oldWithNew__La précédente clé CA Root signée avec la nouvelle clé privée.
newWithOld__La nouvelle clé publique CA root signée avec la précédente clé privée.

De tels certificats doivent contenir les valeurs sensibles pour tous les champs. Par exemple, quand présent, subjectAltName doit être identique à issuerAltName, et, quand présent, keyIdentifier doit contenir les valeurs appropriées, etc.

Mise à jours de clé Root

Une CA racine met à jour sa paire de clé. Elle produit ainsi un message d'annonce de mise à jours de clé CA qui peut être disponible (via certains mécanismes de transport) aux EE concernées. Un message de confirmation n'est pas requis pour les EE.

Demande/réponse d'information PKI

L'entité finale envoie un message général à la PKI demandant des détails qui sont requis pour d'autres opérations de gestion PKI. La RA/CA répond avec une réponse générale. Si une RA génère la réponse, alors il va simplement transférer le message équivalent qui a été précédemment reçus de la CA, en ajoutant possiblement les certificats dans les champs extraCerts du PKIMessage. Un message de confirmation n'est pas requis pour les EE.

Demande/réponse de cross-certification

   La création d'un simple cross-certificat (ex: pas 2 en même temps). La CA demandeuse peut choisir qui est responsable pour la publication du cross-certificat créé par la CA répondante via l'utilisation du contrôle PKIPublicationInfo.

  Préconditions:

1. La CA répondante peut vérifier l'origine de la demande avant de traiter la demande.
2. La CA demandeuse peut authentifier l'authenticité de l'origine de la réponse avant de traiter la réponse.

   L'utilisation de confirmation de certification et la confirmation du serveur correspondant est déterminé par le champ generalInfo dans le PKIHeader. Le profile suivant ne mandate pas le supporte pour ces confirmations.

Initialisation in-band via certificat externe

Une EE ( non-initialisée ) souhaite s'initialiser dans la PKI avec une CA, CA-1. Elle utilise, pour l'authentification, un certificat d'identité pré-existant émis par une autre CA (externe), CA-X. Une relation de confiance doit déjà avoir été établis entre CA-1 et CA-X pour que CA-1 puisse valider le certificat de l'EE signé par CA-X. De plus, certains mécanismes doivent déjà avoir été établis dans le PSE de l'EE qui lui permet d'authentifier et vérifier les PKIMessage signés par CA-1.

L'EE envoie une demande d'initialisation pour démarrer la transaction. Quand CA-1 répond avec un message contenant le nouveau certificat, l'EE répond avec une confirmation de certificat. CA-1 répond avec un PKIConfirm pour terminer la transaction. Tous les messages sont signés ( les messages EE sont signés en utilisant la clé privée qui correspond à la clé publique dans son certificat d'identité externe, les messages CA-1 sont signés en utilisant la clé privée qui correspond à la clé publique dans un certificat qui peut être chaîné à une ancre de confiance dans le PSE de l'EE). Le profile pour cet échange est identique à celui donné précédemment excepté:

- L'EE et CA-1 ne partagent pas de clé MAC symétrique
- Le nom de l'émetteur dans ir doit être présent
- protectionAlg de MSG_SIG_ALG doit être utilisé dans tous les messages
- le certificat d'identité externe doit être géré dans le champ extraCerts de ir
- senderKID et recipKID ne sont pas utilisés.
- body est ir ou ip
- Les bits de protections sont calculés en accord avec le champ protectionAlg

21 juillet 2014

rfc4556

PKINIT

   Ce document décrit des extensions au protocole Kerberos. Ces extensions fournissent une méthode pour intégrer le clé de chiffrement publique dans l'échange d'authentification initiale, en utilisant les clé asymétrique pour les algorithmes de chiffrement et/ou de signature dans les champs de donnée de pré-authentification.

   La pierre angulaire de Kerberos 5 sont le ticket et l'authenticator. Un ticket encapsule une clé symétrique ( la clé de session ) dans un enveloppe ( un message publique ) à destination d'un service spécifique. Le contenu de ce ticket est chiffré avec une clé secrète partagée entre le principale de service et le KDC. La partie chiffrée du ticket contient le nom du principal du client, et d'autre éléments. Un authenticator est un enregistrement qui est généré en utilisant la clé de session du ticket associé. La clé de session est connue du client qui demande le ticket. Le contenu de l'authenticator est chiffré avec cette clé de session et contient un timestamp et le nom du principal du client.

   Le protocole Kerberos 5 consiste des échanges de messages suivant, entre le client et le KDC, et le client et les services d'application:

- L'échange d'AS, où le client obtient un ticket initial, les TGT.
- L'échange TGT, où le client utilise sont TGT pour s'authentifier et demander des tickets de service.
- L'échange AP, où le client faite des demandes avec des messages consistant d'un ticket de service et d'un authenticator qui certifie que le client possède la clé de session du ticket. Le serveur peut optionnellement y répondre. Ces échange négocient généralement des clé de session symétriques.

Généralement, l'AS et le TGS sont intégrés dans un seul périphérique, appelé le KDC.
___________________+- - - - - - - +
________+- - - - -›|__KDC_________|
AS-REQ_/___+- - - -|______________|
______/___/________+- - - - - - - +
_____/___/__________^___________|
____/____|AS-REP___/____________|
___|_____|________/_TGS-REQ_____+_TGS-REP
___|_____|_______/_____________/
___|_____|______/_____________/
___|_____|_____/___+- - - - -+
___|_____|____/___/
___|_____|___/___/
___|_____|__/___/
___|_____v_/___v
__++- - -+- - - - +_____________+- - - - - - - - -+
__|__Client_______+- - - - - - ›|__Application____|
__|_______________|____AP-REQ___|__Server_________|
__|_______________|‹- - - - - - |_________________|
__+- - - - - - - -+____AP-REP___+- - - - - - - - -+

   Dans l'échange AS, la réponse du KDC contient la clé de session du ticket, avec d'autres éléments, qui est chiffré en utilisant une clé partagée entre le client et le KDC. La clé de réponse AS est généralement dérivée du mot de passe du client. Cependant, pour les personnes physiques, la force du protocole Kerberos est sujette à la force du mot de passe.

   L'utilisation d'une clé asymétrique sous la forme d'un certificat X.509 permet de faciliter l'authentification de l'origine des données et la préservation du secret. Un PKI fournis une gestion et des mécanismes de distribution des clés qui peuvent être utilisé pour établir une authentification et une communication sûre.

   L'avantage du TGT Kerberos est que le client expose sa clé à long-terme secrète seulement une fois. Le TGT est ses clé de session associés peuvent être utilisées pour d'autres demandes de ticket. Cela permet à toutes les autres authentification d'être indépendant de la méthode d'authentification initiale. En plus, l'utilisation de clé symétrique après l'authentification initial est préférable pour des raisons de performance.

Extensions

Cette section décris les extensions pour supporter le chiffrement à clé publique dans la requête initiale pour un ticket. Brièvement, cet document définis les extensions suivantes:

- Le client indique l'utilisation d'une authentification à clé publique en incluant un pré-authentifiant spécial dans la demande initiale. Ce pré-authentifiant contient la clé publique du client et une signature.
- Le KDC teste la demande du client avec sa stratégie d'authentification et les autorités de certification de confiance.
- Si le demande passe les tests de vérification, le KDC répond normalement, mais la réponse est chiffrée en utilisant soit:

- Un clé générée avec l'échange DH avec le client, signé avec la clé de signature du KDC; ou
- Un clé de chiffrement symétrique, signée avec la clé de signature du KDC est chiffrée en utilisant la clé publique du client.

- Le client valide la signature du KDC, obtient la clé de chiffrement, déchiffre la réponse, et traite la suite normalement.

Algorithmes requis

Toutes les implémentations PKINIT doivent supporter les algorithmes suivant:

- l'enctype de la réponse AS: aes128-cts-hmac-sha1-96 and aes256-cts-hmac-sha1-96
- L'algorithme de signature: sha-1WithRSAEncryption
- La méthode de livraison de la clé de la réponse AS: La méthode DH.

En plus, les implémentations de cette spécification doivent être capable de traiter l'extension EKU et le id-pkinit-san otherName de l'extention SAN dans les certificat X.509.

Algorithmes recommandés

Toutes les implémentations PKINIT devraient supporter les algorithmes suivant:

- La méthode de livraison de la clé de la réponse AS: voir la section Utiliser le chiffrement à clé publique

Pour les implémentations qui supporte le chiffrement à clé publique pour les méthodes de livraison de clé, Les algorithmes suivant doivent être supportés:

- Les algorithmes de transport de clé identifiés dans le champ keyEncryptionAlgorithm du type KeyTransRecipientInfo pour le chiffrement de clé temporaire dans le champ encryptedKey avec un clé publique: rsaEncryption.
- Les algorithmes de chiffrement de contenu identifiés dans le champ contentEncryptionAlgorithm du type EncryptedContentInfo pour le chiffrement de la clé de réponse AS avec la clé temporaire contenue dans le champ encryptedKey du type KeyTransRecipientInfo: des-ede3-cbc

Messages définis et types de chiffrement

PKINIT utilise les types de pré-auhentification suivants:
PA_PK_AS_REQ 16
PA_PK_AS_REP 17
PKINIT utilisé les types de données d'autorisation suivants:
AD_INITIAL_VERIFIED_CAS 9
PKINIT introduit les nouveaux codes d'erreurs suivants:
KDC_ERR_CLIENT_NOT_TRUSTED 62
KDC_ERR_INVALID_SIG 64
KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED 65
KDC_ERR_CANT_VERIFY_CERTIFICATE 70
KDC_ERR_INVALID_CERTIFICATE 71
KDC_ERR_REVOKED_CERTIFICATE 72
KDC_ERR_REVOCATION_STATUS_UNKNOWN 73
KDC_ERR_CLIENT_NAME_MISMATCH 75
KDC_ERR_INCONSISTENT_KEY_PURPOSE 77
KDC_ERR_DIGEST_IN_CERT_NOT_ACCEPTED 78
KDC_ERR_PA_CHECKSUM_MUST_BE_INCLUDED 79
KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED 80
KDC_ERR_PUBLIC_KEY_ENCRYPTION_NOT_SUPPORTED 81
PKINIT utilise les type de données suivant pour les erreurs:
TD_TRUSTED_CERTIFIERS 104
TD_INVALID_CERTIFICATES 105
TD_DH_PARAMETERS 109

Type de chiffrement Kerberos pour CMS Algorithm Identifiers

   PKINIT définis les numéros de type de chiffrement Kerberos, qui peut être utilisé dans le champ etype du message AS-REQ pour indiquer au KDC l'acceptation du client les algorithmes correspondant ( incluant les algorithmes de transport de clé algorithmes de chiffrement de contenu, et algorithmes de signature ). Les type de chiffrement dans le champ etype sont dans l'ordre décroissant de préférence du client. La présent de chacun de ces types de chiffrement dans le champ etype est équivalent à la présence du l'OID l'algorithme correspondant la le champ supportedCMSTypes, et l'ordre de préférence dans le champ supportedCMSTypes a précédence sur l'ordre de préférence dans le champ etype.

Kerberos Encryption Type Name____Num____Corresponding Algorithm OID
=============================____===____===============================
id-dsa-with-sha1-CmsOID__________ 9_____id-dsa-with-sha1 [RFC3370]
md5WithRSAEncryption-CmsOID______10_____md5WithRSAEncryption [RFC3370]
sha-1WithRSAEncryption-CmsOID____11_____sha-1WithRSAEncryption [RFC3370]
rc2-cbc-EnvOID___________________12_____rc2-cbc [RFC3370]
rsaEncryption-EnvOID_____________13_____rsaEncryption [RFC3447][RFC3370]
id-RSAES-OAEP-EnvOID_____________14_____id-RSAES-OAEP [RFC3447][RFC3560]
des-ede3-cbc-EnvOID______________15_____des-ede3-cbc [RFC3370]

   Les numéros de type de chiffrement ci-dessus sont seulement utilisé pour indiquer le support des algorithmes correspondant dans PKINIT; ils ne correspondant pas aux types de chiffrement Kerberos actuels et ne doivent pas être utilisé dans le champ etype. L'assignation des numéros de type de chiffrement Kerberos pour indiquer le support pour les algorithmes CMS est déprécié, et les nouveaux numéros ne devraient pas être assignés dans ce but. À la place, le champ supportedCMSTypes devrait être utilisé pour identifier les algorithmes supportés par le client et l'ordre de préférence du client.

   Pour une intéropérabilité maximiale, cependant, les clients PKINIT désirant indiquer au KDC le support pour un ou plusieur algorithmes listés ci-dessus devraient inclure les numéros dans le champ etype de l'AS-REQ.

Syntaxe et utilisation de la pré-authentification PKINIT

Cette section définie la syntaxe et l'utilisation des champs de pré-authentification utilisés par PKINIT.

Génération d'une demande client

   La demande d'authentification initilale ( AS-REQ ) est envoyée avec un élément de pré-authentification, dont le padata-type est PA PK_AS_REQ et dont padata-value contient le DER du type PA-PK-AS-REQ.

PA-PK-AS-REQ ::= SEQUENCE {
    signedAuthPack    [0] IMPLICIT OCTET STRING
    trustedCertifiers [1] SEQUENCE OF ExternalPrincipalIdentifier OPTIONAL
    kdcPkId [2] IMPLICIT OCTET STRING OPTIONAL
    ...
}
DHNonce ::= OCTET STRING
ExternalPrincipalIdentifier ::= SEQUENCE {
    subjectName [0] IMPLICIT OCTET STRING OPTIONAL
    issuerAndSerialNumber [1] IMPLICIT OCTET STRING OPTIONAL
    subjectKeyIdentifier [2] IMPLICIT OCTET STRING OPTIONAL
    ...
}
AuthPack ::= SEQUENCE {
    pkAuthenticator [0] PKAuthenticator,
    clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL
    supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier OPTIONAL
    clientDHNonce [3] DHNonce OPTIONAL
    ...
}
PKAuthenticator ::= SEQUENCE {
    cusec [0] INTEGER (0..999999)
    ctime [1] KerberosTime
    nonce [2] INTEGER (0..4294967295)
    paChecksum [3] OCTET STRING OPTIONAL
    ...
}

signedAuthPack Contient un CMS type ContentInfo. Le champ contentType est id-signedData (1.2.840.113549.1.7.2), et le champ tontent est un SignedData. le Champ eContentType pour le type SignedData est id-pkinit-authData (1.3.6.1.5.2.3.1), et le champ eContent contient le DER du type AuthPack
trustedCertifiers Liste de CA, trusté par le client qui peuvent être utilisés pour certifier le KDC.
kdcPkId Contient un CMS type SignerIdentifier. Identifie, si présent, une clé publique d'un KDC particulier que le client a déjà.
subjectName Conient un nom de type PKIX. Identifie le sujet du certificat par le nom distinct du sujet.
issuerAndSerialNumber Contient un type CMS IssuerAndSerialNumber. Identifie un certificat du sujet.
subjectKeyIdentifier Identifie la clé publique du sujet par une ID de clé.
clientPublicValue Spécifie les paramètres de domaine DH et la valeur de clé publique du client.
supportedCMSTypes Liste d'algorithmes CMS qui identifie les algorithmes de transport de clé ou de signature supportés par le client, par ordre de préférence.
clientDHNonce Présent seulement si le client indique qu'il souhaite ré-utiliser les clés DH ou autoriser le KDC à le faire.
paChecksum Contient le checksum SHA1.

eContentType ce champ pour le type SignedData est id-pkinit-authData: { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) pkinit(3) authData(1) }
eContent Ce champ pour le type SignedData contient le DER du type AuthPack
signerInfos Ce champ pour le type SignedData contient un simple signerInfo, qui contient la signature du type AuthPack.
AuthPack Cette structure contient un PKAuthenticator, les informations de clé publique client, les type de chiffrement CMS supportés et un DHNonce.

pkAuthenticator certifie au KDC que le client a une connaissance récente de la clé de signature qui authentifie le client.
clientPublicValue spécifie les paramètre de domaine DH et la valeur de clé publique du client. La valeur de clé publique SH est encodée en BIT STRING.
clientPublicValue est présent seulement si le client désire utilisé DH.
supportedCMSTypes spécifie la liste des ID d'algorithmes CMS qui sont supportés par le client et peut être utilisé pour identifier un algorithme de signature ou un algorithme de transport de clé dans le champ keyEncryptionAlgorithm de type KeyTransRecipientInfo, ou un algorithme de chiffrement de contenu dans le champ contentEncryptionAlgorithm de type EncryptedContentInfo.
clientDHNonce est décrit plus bas

ctime dans la structure PKAuthenticator contient l'heure courante dans l'hôte du client, et le champ cusec est la partie micro-secondes. Ils sont utilisé ensemble pour spécifier un timestamp suffisamment précis. le champ nonce est choisi au hasard. le champ paChechsum doit être présent et contient un checksum SHA1. Pour faciliter les migrations futures de l'utilisation de SHA1, le champ paChecksum est optionnel: quand la demande est étendue à la négociation d'algorithmes de hash, le nouveau client qui souhaite ne pas utiliser SHA1 va envoyer la demande sans ce champ. Le KDC ce conformant à cette spécification doivent retourner KRB-ERROR avec le code KDC_ERR_PA_CHECKSUM_MUST_BE_INCLUDED. Cela permet à un nouveau client de retenter avec SHA1 si permis par la stratégie locale.
certificates de type SignedData, contient les certificats utilisés pour la construction du chemin de certification, pour que le KDC puisse vérifier la signature sur le type AuthPack. Cet certificats devraient être suffisants pour construire au moins chemin de certification depuis le certificat client. Le client doit être capable d'inclure un tel jeu de certificats s'il est configuré pour le faire. Le champ certificates ne doit pas contenir de certificat CA root.
clientPublicValue La valeur public Diffie-Hellman est inclues si le client veut utiliser la méthode DH. Les paramètres de domaine DH pour la clé public du client sont spécifiés dans le champ algorithm du type SubjectPublicKeyInfo, et la valeur de clé publique DH du client est mapppé à un ubjectPublicKey. En utilisant la méthode d'agrément de clé DH, les implémentations doivent supporter Oakley 1024-bits Modular Exponential (MODP) group 2 et OakleOakley 2048-bits Modular Exponential (MODP) group 14 et devraient supporter OakleOakley 4096-bits Modular Exponential (MODP) group 16.

   La structure ExternalPrincipalIdentifier est utilisée dans ce document pour identifier la clé publique du sujet. Cette structure est construite comme suit:

subjectName Contient un nom de type PKIX encodé en accord avec la rfc3280. Ce champ identifie le sujet du certificat par un nom de sujet distinct. Ce champ est requis quand il y a un distinguished subject name présent dans le certificat utilisé.
issuerAndSerialNumber Contient un type CMS encodé. Ce champ identifie un certificat du sujet. Il est requis pour TD-INVALID-CERTIFICATES et TD-TRUSTED-CERTIFIERS
subjectKeyIdentifier Identifie la clé publique du sujet par une key identifier. Quand un certificat X.509 est référencé, cette Key Identifier matche la valeur d'extention subjectKeyIdentifier. Quand d'autres fomats de certificat sont référencés, les documents qui spécifient le format de certificat et leur utilisation avec le CMS doivent inclurent les détails du match de key identifier au champ de certificat approprié.

   Le champ trustedCertifiers du type PA-PK-AS-REQ contient une liste de CA, trustés par le client, qui peut être utilisé pour certifier le KDC. Chaque ExternalPrincipalIdentifier identifie une CA ou un certificat CA. Le champ kdcPkId du type PA-PK-AS-REQ contient un type CMS SignerIdentifier encodé. Ce champ identifie, si présent, une clé publique d'un KDC particulier que le client possède.

Réception de la demande client

   Une fois reçu la demande du client, le KDC la valide. Le KDC vérifie la signature du client dans le champ signedAuthPack. Si, pendant la validation du certificat du client, le KDC ne peut pas construire un chemin de validation, il retourne un KRB-ERROR avec le code KDC_ERR_CANT_VERIFY_CERTIFICATE. Le e-data qui l'accompagne est un TYPED-DATA qui contient un élément dont data-type est TD_TRUSTED_CERTIFIERS, et contient le DER du type TD-TRUSTED-CERTIFIERS:

TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF
    ExternalPrincipalIdentifier
    -- Identifies une liste de CA trustés par le KDC.
    -- Chaque ExternalPrincipalIdentifier identifies une CA
    -- ou un certificat CA

   Une fois ce message d'erreur reçu, le client devrait retenter seulement s'il a un jeu de certificats différent qui forment un chemin de certification acceptable pour le KDC.

   Si, pendant le traitement du chemin de certification, de KDC détermine qu'une signature dans le champ signedAuthPack est invalide, il retourne KRB-ERROR avec le code KDC_ERR_INVALID_CERTIFICATE. Le e-data qui l'accompagne est un TYPED-DATA qui contient un élément dont data-type est TD_INVALID_CERTIFICATES, et contient le DER du type TD-INVALID-CERTIFICATES:

TD-INVALID-CERTIFICATES ::= SEQUENCE OF
    ExternalPrincipalIdentifier
    -- Chaque ExternalPrincipalIdentifier identifie un
    -- Certificat (envoyé par le client) avec une signature invalide

   Si plus d'une signature est invalide, le KDC peut inclure un IssuerAndSerialNumber par signature invalide dans le TD-INVALID-CERTIFICATES. Le certificat X.509 du client est validé en accord avec la rfc3280.

   En fonction de la stratégie locale, le KDC peut également vérifier si un certificat X.509 dans le chemin de certification a été révoqué. Si c'est le cas, le KDC doit retourner un message d'erreur avec le code KDC_ERR_REVOKED_CERTIFICATE. Si le KDC tente de déterminer le statut de révocation mais n'est pas en mesure de le faire, il devrait retourner un message d'erreur avec le code KDC_ERR_REVOCATION_STATUS_UNKNOWN. Le ou les certificats affectés sont identifiés comme pour le code d'erreur KDC_ERR_INVALID_CERTIFICATE.

   Noter que les données d'erreur TD_INVALID_CERTIFICATES est uniquement utilisé pour identifier les certificats invalides envoyés par le client dans le demande.

   La clé publique du client est ainsi utilisée pour vérifier la signature. Si la vérification de la signature échoue, le KDC doit retourner un message d'erreur avec le code KDC_ERR_INVALID_SIG. Il n'y a pas de e-data pour ce message d'erreur.

   En plus de la validation de la signature du client, le KDC doit également vérifier que la clé publique du client utilisée pour vérifier la signature est liée au principal du client comme suit:

1. Si le KDC a sa propre liaison entre la clé publique du client ou le certificat du client et le nom du principal du client, il utilise cette liaison.
2. Sinon, si le certificat X.509 du client contient un SAN avec un KRB5PrincipalName dans le champ otherName de type GeneralName, il lie le certificat du client à ce nom.

Le type de champ otherName est AnotherName. Le champ type-id du type AnotherName est id-pkinit-san:
id-pkinit-san OBJECT IDENTIFIER ::=
    { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
    x509SanAN (2) }

Et le champ valeur du type AnotherName est un KRB5PrincipalName:
KRB5PrincipalName ::= SEQUENCE {
    realm [0] Realm,
    principalName [1] PrincipalName
    }

   Si le nom du client dans le AS-REQ ne matche pas un nom lié par le KDC, ou s'il n'y a aucune liaison trouvée par le KDC, le KDC doit retourner un message d'erreur avec le code KDC_ERR_CLIENT_NAME_MISMATCH. Il n'y a pas de e-data pour ce type d'erreur.

   Même si le chemin de certification est validée et que le certificat est mappé au nom principal du client, le KDC peut décider de ne pas accepter le certificat du client, en fonction de la stratégie locale.

Le KDC peut imposer la présence du EKU KeyPurposeId id-pkinit-KDClientAuth dans le champ extensions du certificat du client:
id-pkinit-KPClientAuth OBJECT IDENTIFIER ::=
    { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
    pkinit(3) keyPurposeClientAuth(4) }
    -- PKINIT client authentication.
    -- Key usage bits that MUST be consistent:
    -- digitalSignature.

   Le bit d'utilisation de clé digitalSignature doit être présent quand le but du certificat du client est restreins avec le id-pkinit-KDClientAuth.

   Si ce EKU KeyPusposeId est requis mais n'est pas présent, ou si le certificat du client est restreins à ne pas l'utiliser pour PKINIT, le KDC doit retourner un message d'erreur avec le code KDC_ERR_INCONSISTENT_KEY_PURPOSE. Il n'y a pas de e-data pour cette erreur. Les KDC implémentant ce requis devraient également accepter le EKU KeyPurposeId id-ms-kp-sc-logon (1.3.6.1.4.1.311.20.2.2), vu que de nombreux certificats déployés pour PKINIT ont ce EKU.

   En conséquence de la stratégie locale, le KDC peut décider de rejeter les demandes sur la base de l'absence ou la présence d'autres EKU spécifiques.

   Si l'algorithme digest utilisé pour générer la signature CA pour la clé publique dans un certificat de la demande n'est pas acceptable, le KDC doit retourner un KRB-ERROR avec le code KDC_ERR_DIGEST_IN_CERT_NOT_ACCEPTED. Le e-data doit être un TYPED-DATA encodé, bien que rien n'est définis.

   Si la clé publique du client n'est pas acceptée pour des raisons autre que ceux spécifiés, le KDC retourne un message KRB-ERROR avec le code KDC_ERR_CLIENT_NOT_TRUSTED. Il n'y a pas de e-data dans ce message.

   Le KDC doit vérifier le timestamp pour s'assurer que la demande n'est pas rejouée, et que la plage de temps est dans la limite acceptable. Si la vérification échoue, le KDC doit retourner un code d'erreur KRB_AP_ERR_REPEAT ou KRB_AP_ERR_SKEW, respectivement.

   Si clientPublicValue est remplis, indiquant que le client désire utiliser la méthode d'agrément de clé DH, le KDC devrait vérifier si les paramètres satisfont sa stratégie. Si ce n'est pas le cas, il doit retourner un message d'erreur avec le code KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED. Le e-data qui l'accompagne est un TYPED-DATA qui contient un élément dont le data-type est TD-DH--PARAMETERS:

TD-DH-PARAMETERS ::= SEQUENCE OF AlgorithmIdentifier
    -- Chaque AlgorithmIdentifier spécifie un jeu de
    -- paramètres de domaine Diifie-Hellman. Cette liste
    -- est dans l'ordre de préférence décroissante.

   La structure AlgorithmIdentifier est définie dans la rfc3280 et est renseigné en accord avec la rfc3279. Si le client inclus un champ kdcPkId dans le PA-PK-AS-REQ et que le KDC ne possède pas la clé correspondante, le KDC doit ignorer le kdcPkId comme si le client ne l'avait pas inclus.

   Si l'algorithme digest utilisé par le id-pkinit-authData n'est pas acceptable par le KDC, le KDC doit retourner un KRB-ERROR avec le code KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED. Le e-data qui l'accompagne doit être encodé en TYPED-DATA, bien que rien n'est définis.

Génération de la réponse KDC

   Si le paChechsum dans la demande n'est pas présente, le KDC se conformant a cette spécification doivent retourner un KRB-ERROR avec le code KDC_ERR_PA_CHECKSUM_MUST_BE_INCLUDED. Le e-data qui l'accompagne doit être encodé dans un TYPED-DATA.

   En assumant que la demande du client a été validée, le KDC procède comme dans la rfc4120, excepté ce qui suit.

Le KDC doit mettre le flag initial et inclure un élément de donnée d'autorisation de ad-type AD_INITIAL_VERIFIED_CAS dans le ticket fournis. Le champ ad-data contient le DER du type AD-INITIAL-VERIFIED-CAS:
AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF ExternalPrincipalIdentifier
    -- Identifie le chemin de certification avec lequel le certificat
    -- client a été validé. Chaque ExternalPrincipalIdentifier
    -- identifie une CA ou un certificat CA

   Noter que la syntaxe pour les données d'autorisation AD-INITIAL-VERIFIED-CAS ne permet pas d'encoder des SEQUENCES vides. De tels séquences vides peuvent uniquement être utilisée si le KDC garantis lui-même le certificat du client.

   l'AS enveloppe toute donnée AD-INITIAL-VERIFIED-CAS dans des conteneur AD-IF-RELEVANT si la liste des CA satisfait la stratégie locale de l'AS. De plus, tout TGS doit copier de telles données d'autorisation depuis les tickets utilisé dans un PA-TGS-REQ du TGS-REQ dans le ticket résultant. Si la liste des CA satisfait la stratégie de domaine du KDC, le TGS peut envelopper les données dans le AD-IF-RELEVANT; sinon, il peut sortir les données d'autorisation du conteneur AD-IF-RELEVANT.

   Les serveurs d'application qui comprennent ce type de données d'autorisation devraient appliquer la stratégie locale pour déterminer si un ticket donné comportant un tel type non contenu dans un conteneur AD-IF-RELEVANT est acceptable. ( Cela correspond au serveur AP qui vérifie le champ transited quand le flag TRANSITED-POLICY-CHECKED n'est pas mis). Si un tel type de donnée est contenu dans un conteneur AD-IF-RELEVANT, les serveurs AP peuvent appliquer la stratégie locale pour déterminer si les données d'autorisation sont acceptables.

Un élément de donnée de pré-authentification, dont padata-type est PA_PK_AS_REP et dont padata-value contient le DER du type PA-PK-AS-REP, est inclus dans le AS-REP.
PA-PK-AS-REP ::= CHOICE {
    dhInfo [0] DHRepInfo,
    -- Sélectionné quand l'échange de clé DH est utilisé
    encKeyPack [1] IMPLICIT OCTET STRING,
    -- Sélectionné quand le chiffrement par clé publique est utilisé
    -- Contient un type CMS ContentInfo encodé
    -- le champ contentType de type ContentInfo est id-envelopedData (1.2.840.113549.1.7.3)
    -- Le champ content est un EnvelopedData
    -- le champ contentType pour le type EnvelopedData est id-signedData (1.2.840.113549.1.7.2)
    -- le champ eContentType pour le type SignedData est id-pkinit-rkeyData (1.3.6.1.5.2.3.3)
    -- et le champ eContent contient le DER du type ReplyKeyPack
}
KDCDHKeyInfo ::= SEQUENCE {
    subjectPublicKey [0] BIT STRING,
    -- La clé publique DH du KDC
    -- la clé publique DH est encodée en BIT STRING
    nonce [1] INTEGER (0..4294967295),
    -- Contient le nonce dans le champ pkAuthenticator dans le demande si les clés DH ne sont pas réutilisées. 0 sinon.
    dhKeyExpiration [2] KerberosTime OPTIONAL,
    -- Temp d'expiration pour la paire de clé du KDC, présent si est seulement si les clé DH sont réutilisées
    -- Si présent, la clé publique DH du KDC ne doit pas être utilisé passé cette expiration
    -- Si ce champ est omis, le champ serverDHNonce doit également être utilisé.
}

   Le contenu de AS-REP est inchangé sinon. Le KDC chiffre la réponse normalement, mais pas avec la clé long-terme du client. À la place, il le chiffre avec soit une clé partagée dérivée d'un échange DH, ou une clé de chiffrement générée. Le contenu de PA-PK-AS-REP indique quelle méthode de livraison de clé est utilisé.

   Si le client ne souhaite pas utiliser la méthode DH ( le champ clientPublicValue n'est pas présent dans la demande ) et que le KDC ne supporte pas la méthode de livraison de clé de chiffrement à clé publique, le KDC doit retourner un message d'erreur avec le code KDC_ERR_PUBLIC_KEY_ENCRYPTION_NOT_SUPPORTED. Il n'y a pas de e-data accompagnant ce message d'erreur.

   En plus, la durée de vie du ticket retourné par le KDC ne doit pas excéder celle de la paire de clé du client.

Utiliser l'échange de clé Diffie-Hellman

   Dans ce cas, le PA-PK-AS-REP contient une structure SHRepInfo. La structure ContentInfo pour le champ shSignedData est remplis comme suis:

1. Le champ contentType du type ContentInfo est id-signedData, et le champ content est un SignedData
2. Le champ eContentType pour le type SignedData est l'OID pour id-pkinit-DHKeyData: { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) pkinit(3) DHKeyData(2) }.
3. Le champ eContent pour le type SignedData contient le DER du type KDCDHKeyInfo.
4. La structure KDCDHKeyInfo contient la clé publique du KDC, un nonce, et optionnellement l'expiration de la clé DH du KDC qui est réutilisée. Le champ subjectPublicKey du type KDCDHKeyInfo identifie la clé publique DH du KDC. Ce clé est encodée en BIT STRING. Le champ nonce contient le nonce dans le champ pkAuthenticator dans le demande si les clés DH ne sont pas réutilisées. La valeur de ce champ nonce est 0 si les clés DH sont réutilisées. Le champ dhKeyExpiration est prisent si et seulement si les clé DH sont réutilisées. Si le champ dhKeyExpiration est présent, la clé publique DH du KDC dans cette structure KDCDHKeyInfo ne doit pas être utilisée passé ce temps. Si ce champ est omis, le champ serverDHNonce doit également être omis.
5. Le champ signerInfo du type SignedData contient un simple signerInfo, qui contient la signature pour le type KDCDHKeyInfo.
6. Le champ certificat du type SignedData contient les certificats prévus pour faciliter la construction du chemin de certification, pour que le client puisse vérifier la signature du KDC pour le type KDCDHKeyInfo. Les informations contenus dans le trustedCertifiers dans la demande devraient être utilisés par le KDC pour l'aider dans sa sélection d'une chaîne de certificats approprié à retourner au client. Ce champ peut être vide si la clé publique du KDC spécifiée par le champ kdcPkId dans le PA-PK-AS-REQ a été utilisé pour signer. Le KDC doit être capable d'inclure un tel jeu de certificat s'il est configuré pour le faire. Ce champ ne doit pas contenir de certificat CA root.
7. Si le client inclus le champ clientDHNonce, le KDC peut choisir de réutiliser ses clés DH, et doit inclure un temps d'expiration. Quand le serveur réutilise les clé DH, il doit inclure un serverDHNonce au moins aussi long que la longueur des clé pour le système de chiffrement symétrique utilisé pour chiffrer la réponse AS. Noter qu'inclure le serverDHNonce change la manière dont le client et le serveur calculent le clé à utiliser pour chiffrer la réponse. Le KDC ne dervait pas réutiliser les clé DH sauf si clientDHNonce est présent dans la demande.

   La réponse AS est dérivée comme suit:

1. Le KDC et le client calculent la clé partagée comme suit: Quand MODP Diffie-Hellman est utilisé, les DHSharedSecret être la valeur de clé secrète. DHSharedSecret est la valeur ZZ, et est remplis avec des 0 pour la taille en octets soit la même que le modulo, et représente une chaîne d'octet dans l'ordre big-endian.
2. Laisse K être la source de génération de clé de la réponse AS.
3. Définie la fonction octetstring2key() comme suis:

octetstring2key(x) == random-to-key(K-truncate(
    SHA1(0x00 | x) |
    SHA1(0x01 | x) |
    SHA1(0x02 | x) |
    ...
    ))

   où x est une chaîne d'octets, | est l'opérateur de concaténation, 0x00, etc. sont représentés comme octet simple, random-to-key() est une opération qui génère une clé de protocole depuis un bitstring de longueur K; et K-truncate tronque son entrée au premiers K bits.

4. Quand les clé DH sont réutilisées, laisse n_c être le clientDHNonce et n_k être le serverDHNonce, sinon ils sont vides.
5. La clé de réponse AS est: k = octetstring2key(DHSharedSecret | n_c | n_k)

Utiliser le chiffrement à clé publique

   Dans ce cas, le PA-PK-AS-REP contient le champ encKeyPack où la clé de réponse AS est chiffrée. La structure ContentInfo pour le champ encKeyPack est construit comme suit:

1. Le champ contentType du type ContentInfo est id-envelopedData, et le champ content est un EnvelopedData
2. Le champ contentType pour le type EnvelopedData est id-signedData: { iso (1) member-body (2) us (840) rsadsi (113549) pkcs (1) pkcs7 (7) signedData (2) }
3. Le champ eContentType pour le type SignedData ( quand déchiffré depuis le champ EncryptedContent pour le type EnvelopedData) est id-pkinit-rkeyData: { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) pkinit(3) rkeyData(3) }.
4. Le champ eContent pour le type SignedData contient le DER du type ReplyKeyPack
5. Le champ signerInfos du type SignedData contient un simple signerInfo, qui contient la signature pour le type ReplyKeyPack.
6. Le champ certificates pour le type SignedData contient les certificats pour construire le chemin de certification, pour que le client puisse vérifier la signature du KDC pou le type ReplyKeyPack. Les informations contenues dans le trustedCertifiers dans la demande devraient être utilisés par le KDC comme guide dans sa sélection d'une chaîne de certification appropriée. Ce champ peut être vide si la clé publique du KDC spécifiée par le champ kdcPkId dans le PA-PK-AS-REQ a été utilisé pour signer. Sinon, pour la validation du chemin, ces certificats devraient être suffisant pour construire au moins un chemin de certification depuis le certificat du KDC. Le KDC doit être capable d'inclure un tel jeu s'il est configuré pour le faire. Ce champ ne doit pas contenir de certificat CA root.
7. Le champ recipientInfos du type EnvelopedData est un jeu qui doit contenir exactement un membre du type KeyTransRecipientInfo. Le encryptedKey de ce membre contient la clé temporaire qui est chiffrée en utilisant la clé publique du client.
8. Les champs unprotectedAttrs ou originatorInfos du type EnvelopedData peut être présent.

   S'il y a un champ supportedCMSTypes dans le AuthPack, le KDC doit vérifier s'il supporte un des types listés. S'il supporte plus d'un type, le KDC devrait utilisé le premiers qui listé. S'il n'en supporte aucun, le KDC doit retourner un message d'erreur avec le code KDC_ERR_ETYPE_NOSUPP.

   Le KDC calcule le checksum du AS-REQ dans la demande du client. Ce checksum est effectué sur le type AS-REQ, et la clé de protocole de l'opération checksum est le replyKey, et le numéro d'utilisation de clé est 6. Si le enctype de replyKey est "newer", l'opération checksum est l'opération checksum requise de ce enctype:

ReplyKeyPack ::= SEQUENCE {
    replyKey [0] EncryptionKey,
    -- contient la clé de session utilisé pour chiffrer le
    -- champ enc-part dans le AS-REP. par ex: la clé de réponse AS
    asChecksum [1] Checksum,
    -- Contient le checksum du AS-REQ correspondant au AS-REP
    -- Le checksum est effectué sur le type AS-REQ.
    ...
    }

   Les implémentations de cette méthode de livraison de clé de chiffrement RSA devraient supporter les clé RSA d'au moins 2048-bits.

Réception de la réponse du KDC

   Une fois la réponse du KDC reçus, le client procède comme suit. Si le PA-PK-AS-REP contient le champ dhSignedData, le client dérive le clé de réponse AS en utilisant la même procédure utilisée par le KDC. Sinon, le message contient le champ encKeyPack, et le client déchiffre de extrait la clé temporaire dans le champ encryptedKey du membre KeyTransRecipientInfo et l'utilise comme clé de réponse AS. Si la méthode de chiffrement à clé publique est utilisé, le client doit vérifier le asChecksum dans le ReplyKeyPack.

   Dans tous les cas, le client doit vérifier la signature dans le SignedData. En plus, sauf si le client peut vérifier que la clé publique utilisée pour vérifier la signature du KDC est liée au KDC du domaine cible, le certificat du KDC doit contenir un SAN ayant un AnotherName dont type-id est id-pkinit-san et dont la valeur est un KRB5PrincipalName qui correspond au nom du TGS du domaine cible.

À moins que le client connaisse par d'autres moyens que le certificat du KDC est prévu pour un KDC, le client doit imposer que le certificat du KDC contienne le EKU KeyPurposeId id-pkinit-KPKdc:
id-pkinit-KPKdc OBJECT IDENTIFIER ::=
    { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) pkinit(3) keyPurposeKdc(5) }

   Le bit d'utilisation de clé digitalSignature doit être mis quand le but du certificat du KDC est restreins avec le EKU id-pkinit-KPKdc. Si le certificat du KDC contient le nom du TGS encodé en SAN id-pkinit-san, ce certificat est certifié par la CA qui l'a délivré, et donc l'EKU id-pkinit-KPKdc n'est pas requis. Si toutes les vérifications applicables sont satisfaites, le client déchiffre le champ enc-part du KDC-REP dans le AS-REP, utilisant la clé de réponse AS, puis procède normalement.

Prérequis d'intéropérabilité

Le client doit être capable d'envoyer un jer de certificats suffisant pour permettre au KDC de construire un chemin de certification pour le certificat du client, si le jeu correct de certificat est fournis via la configuration ou la stratégie. Si le client envoie tous les certificats X.509 dans un chemin de certification en une chaîne acceptable pour le KDC, et si le KDC ne peut par vérifier la clé publique du client, le KDC doit être capable de traiter la validation pour le certificat du client basé sur les certificats dans le demande.

Indication du support PKINIT

   Si la pré-authentification est requise mais n'est pas présente dans la requête, un message d'erreur avec le code KDC_ERR_PREAUTH_FAILED est retourné, et un objet METHOD-DATA sera présent dans le champ e-data du message KRB-ERROR pour spécifier quels mécanismes de pré-authentification sont acceptables. Le KDC peut ainsi indiquer le support de PKINIT en incluant un élément vide dont le padata-type est PA_PK_AS_REQ dans l'objet METHOD-DATA.

   Sinon s'il est requis par la stratégie local du KDC que le client doive être pré-authentifié en utilisant le mécanisme de pré-authentification spécifié dans ce document, mais qu'aucune pré-authentification PKINIT n'est présent dans la requête, une message d'erreur avec le code d'erreur KDC_ERR_PREAUTH_FAILED devrait être retourné.

   Le KDC doit laisser le champ padata-value de l'élément PA_PK_AS_REQ dans le METHOD-DATA du KRB-ERROR vide, et les clients doivent l'ignorer. De futures extensions de ce protocole peuvent spécifier d'autres données à envoyer au lieu d'un OCTET STRING vide.

18 août 2015

rfc5019

Profile OCSP pour les environnements à haut volume

   OCSP spécifie un mécanisme utilisé pour déterminer le statut des certificats numériques, au lieu d'utiliser les CRL. Depuis sa définition en 1999, il a été déployé dans de nombreux environnements et prouvé son utilité.

   À ce jour, de nombreux déploiements on été utilisé pour s'assurer les informations de statut de certificats de manière sécurisé et en temps pour les transactions électroniques ou hautement sensibles, tels que les environnements financiers. Un tel environnement exige un répondeur OCSP en temps réel. De plus, ces déploiements ont opérés dans des environnements où l'utilisation de la bande passante n'est pas un problème, et fonctionnement sur des systèmes client et serveur où la charge de traitement n'est pas une contrainte.

   Vu que l'utilisation d'une PKI continue de grandir et d'aller dans divers environnements, on n'a donc besoin d'un mécanisme de statut de certificat efficace. Bien qu'OCSP a été définis et déployé dans de nombreuses petites et moyennes PKI qui opèrent sur des systèmes puissants et sur des réseaux câblés, il y a une limite sur l'agrandissement des déploiements. Les environnements mobiles, où la bande passante peut être une des principales contraintes, il exige une attention particulière de l'utilisation d'OCSP pour minimiser l'utilisation de la bande passante et la complexité de traitement côté client.

   Les PKI continuent d'être déployés dans des environnements où des millions voir des centaines de millions de certificats ont été émis. Dans beaucoup de ces environnements, un aussi grand nombre d'utilisateurs on besoins de s'assurer que le certificat qu'ils souhaitent utiliser n'a pas été révoqué. Il est important que OCSP soit utilisé de manière à s'assurer que la charge des répondeurs OCSP et que l'infrastructure réseaux soient utilisés au minimum.

   Ce document adresse les problèmes d'évolution inhérents en utilisant OCSP dans des environnements PKI décrits ci-dessus en définissant un profile de message et en clarifiant le comportement du client et du répondeur OCSP qui va permettre de:

1) pré-produire et distribuer des réponse OCSP
2) Réduire la taille de message OCSP pour réduire la bande passante
3) Le caching des messages de réponse dans le réseaux et dans le client

   Il est prévu que les exigences définies dans ce profile soit adopté par les clients et les répondeurs OCSP opérant dans des environnements PKI à très grand volume ou les environnements PKI qui exigent une solution légère pour minimiser la bande passante de le traitement côté client. Vu que OCSP n'a pas de moyen de signaler les capacités du répondeur dans le protocole, les clients doivent différencier les réponses OCSP produites par les répondeurs conforme avec ce profile et ceux qui n'ont pas besoin de s'appuyer sur des mécanismes externe pour déterminer quand une réponse opère en accord avec ce profile et, quand les exigences de ce profile s'appliquent. Dans le cas où des mécanismes tiers ne sont pas disponible entre un client OCSP 2560 et un répondeur qui opère dans un mode décrit dans cette spécification.

Profile de demande OCSP

Structure OCSPRequest

   OCSPRequest conforme a ce profile doit inclure seulement une Request dans la structure OCSPRequest.RequestList

   Les clients ne doivent pas utiliser SHA1 comme algorithme de hash pour les valeurs CertID.issuerNameHash et CertID.issuerKeyHash.

   Les clients ne doivent pas inclure la structure singleRequestExtensions

   Les clients ne devraient pas inclure la structure requestExtensions. Si une structure requestExtensions est inclue, ce profile recommande qu'il ne contienne seulement que l'extension nonce (id-pkix-ocsp-nonce).

OCSPRequests signées

Les clients ne doivent pas envoyer d'OCSPRequests signés. Les répondeurs peuvent ignorer la signature dans les requêtes OCSPRequests.

Si OCSPRequest est signé, le client devrait spécifier son nom dans le champ OCSPRequest.requestorName, sinon, les clients ne devraient pas inclure le champ requestorName dans OCSPRequest. Les serveurs OCSP doivent être préparés à recevoir des requêtes OCSP non-signés qui contiennent le champ requestorName, mais doivent réaliser que la valeur fournie n'est pas authentifiée.

Profile de réponse OCSP

Structure OCSPResponse

   Les répondeurs doivent générer un BasicOCSPResponse comme identifié par l'OID BasicOCSPResponse. Les OCSPResponses conformes à ce profile devraient inclure seulement un SingleResponse dans la structure ResponseData.responses, mais peuvent inclure des éléments SingleResponse additionnels si nécessaire pour améliorer les performances de pré-génération de réponse ou l'efficacité des caches.

   Le répondeur ne devrait pas inclure responseExtensions. Comme spécifié dans OCSP, les clients doivent ignorer les responsesExtensions non-critiques dans la réponse.

   Dans le cas où un répondeur n'a pas la possibilité de répondre à une demande OCSP contenant une option non supportée par le serveur, il devrait retourner la réponse la plus complète qu'il peut. Par exemple, dans le cas où un répondeur ne supporte que les réponses pré-produites et n'a pas la possibilité de répondre à une demande OCSP contenant a nonce, il devrait retourner une réponse qui n'inclut pas un nonce.

   Les clients devraient tenter de traiter une réponse même si la réponse n'inclue pas un nonce.

   Les répondeurs qui n'ont pas la capacité de répondre aux requêtes OCSP qui contiennent une option non-supportée telle que nonce peuvent renvoyer la requête à un répondeur OCSP qui en a la capacité.

   Le répondeur peut inclure la structure d'extensions singleResponse.singleResponse.

OCSPResponses signés

   Les clients doivent valider la signature de l'OCSPResponse retourné. Si la réponse est signée par un délégué de l'autorité de certification émettrice, un certificat de répondeur valide doit être référencé dans la structure BasicOCSPResponse.certs.

   Il est recommandé que le certificat du répondeur OCSP contienne l'extension id-pkix-ocsp-nocheck, comme définis dans OCSP, pour indiquer au client qu'il ne doit pas vérifier le statut du certificat. De plus, il est recommandé que ni une extension authorityInfoAccess ni une extension cRLDistributionPoints ne soit inclus dans le certificat du répondeur OCSP. En accord avec ça, le certificat de signature du répondeur devrait être relativement de courte durée et renouvelé régulièrement.

   Les clients doivent être capable d'identifier les certificats de répondeur OCSP en utilisant les chois ResponseData.ResponderID byName et byKey. Les répondeur devraient utiliser byKey pour réduire ensuite la taille de la réponse dans les scénarios où la réduction de la bander passante est un problème.

Valeurs OCSPResponseStatus

Tant que l'infrastructure OCSP a des enregistrements autoritatifs pour un certificat particulier, un OCSPResponseStatus "Success" sera retourné. Quand l'accès aux enregistrements autoritatifs pour un certificat particulier n'est pas disponible, le répondeur doit retourner un OCSPResponseStatus "unautorized". Ce profile étend la rfc2560 de "unauthorized" comme suit:

La réponse "unauthorized" est retournée dans le cas où le client n'est pas autorisé à faire cette demande à ce serveur ou quand le serveur n'est pas capable de répondre de manière autoritative.

Par exemple, les répondeurs OCSP qui n'ont pas accès aux enregistrements autoritatifs pour un certificat, tel que ceux qui génèrent et distribuent les réponses OCSP à l'avance et donc n'ont pas la capacité de répondre correctement avec une réponse "success" ni "unknown", vont répondre avec un OCSPResponseStatus "unauthorized". Également, pour s'assurer que la base d'information de révocation ne grandis pas indéfiniment dans le temps, le répondeur peut supprimer les enregistrements des certificats expirés. Les demandes des clients pour les certificat dont l'enregistrement a été supprimé vont résulter dans un OCSPResponseStatus "unauthorized".

thisUpdate, nextUpdate, et producedAt

   En pré-produisant les messages OCSPResponse, le répondeur doit définir les temps thisUpdate, nextUpdate et producedAt comme suit:

thisUpdate La date à laquelle le statut indiqué est connu comme étant correcte
nextUpdate La date à laquelle ou avant laquelle de nouvelles informations seront disponibles sur le statut des certificats. Les répondeur doivent toujours inclure cette valeur pour aider dans le caching des réponses.
producedAt La date à laquelle la réponse OCSP a été signée

   Note: Dans de nombreux cas la valeur de thisUpdate et producedAt seront les même.

   Pour ce profile, les valeurs GeneralizedTime encodé ASN.1 pour thisUpdate, nextUpdate et producedAt doivent être exprimés en GMT et doivent inclure les secondes, même quand le nombre de secondes est 0. Les valeurs GeneralizedTime ne doivent pas inclure les fractions de secondes.

Comportement du client

Découverte du répondeur OCSP

Les clients doivent supporter l'extension authorityInfoAccess comme définis dans PKIX et doivent reconnaître la méthode d'accès id-ad-ocsp. Cela permet d'informer les clients sur la manière de contacter le service OCSP.

Dans le cas où un client vérifie le statut d'un certificat qui contient une extension authorityInformationAccess pointant vers un répondeur OCSP et une extension cRLDistributionPoints pointant vers une CRL, le client devrait tenter de contacter le répondeur OCSP en premier. Les clients peuvent tenter de récupérer la CRL si aucune OCSPResponse n'est reçu du répondeur.

Envoyer une demande OCSP

Pour éviter le trafic réseaux inutile, les applications doivent vérifier la signature d'une donnée signée avant de demander à un client OCSP de vérifier le statut des certificats utilisé pour vérifier la donnée. Si la signature est invalide ou l'application n'est pas capable de la vérifier, une vérification OCSP ne doit pas être tentée.

Similairement, une application doit valider la signature dans les certificats dans une chaîne, avant de demander à un client OCSP de vérifier le statut d'un certificat. Si la signature du certificat est invalide ou que l'application n'est pas capable de le vérifier, une vérification OCSP ne doit pas être faite. Les clients ne devraient pas faire de demande de statut des certificats expirés.

S'assure qu'un OCSPResponse est récent

   Pour s'assurer qu'un client n'accepte pas de réponse expirée qui indique un statut 'good' il y a une réponse plus récente qui spécifie un statut 'revoked', un client doit s'assurer que les réponses qu'ils reçoivent sont récentes.

   En général, 2 mécanismes sont disponibles aux clients pour s'assurer qu'une réponse est récente. La première utilise nonces, et la seconde est basée sur la date. Pour que les mécanismes basés sur les dates fonctionnent, les clients et les répondeurs doivent avoir accès à une source de temps précise.

   Parce que ce profile spécifie que les clients ne devraient pas inclure une structure requestExtensions dans OCSPRequests, les clients doivent être capable de déterminer que OCSPResponse est récent basé sur une source de temps précise. Les clients qui optent pour inclure un nonce dans le demande ne doivent pas rejeter une OCSPResponse correspondante seulement sur la base de la non-existance du nonce attendu, mais doivent valider l'OCSPResponse basé sur le temps.

   Les clients qui n'incluent pas un nonce dans la requête doivent ignorer tout nonce qui peut être présent dans la réponse.

   Les clients doivent vérifier l'existence du champ nextUpdate et doivent s'assurer de la date courante, exprimée en temps GMT, qui doit être entre le thisUpdate et le nextUpdate. Si le champ nextUpdate est absent, le client doit rejeter la réponse.

   Si le champs nextUpdate est présent, le client doit s'assurer qu'il n'est pas antérieur la date courante. Si la date courante dans le client est ultérieur au temps spécifié dans le champ nextUpdate, le client doit rejeter la réponse. Les clients peuvent autoriser la configuration d'une petite période de tolérance pour accepter des réponses après nextUpdate pour gérer les différences mineurs d'horloge relative aux répondeurs et aux caches. Cette période de tolérance devrait être choisis sur la précision de la technologie de synchronisation de temps disponible dans l'environnement de l'application appelante. Par exemple, les paires internet avec connexion à faibles latences s'attendent à une synchronisation du temps NTP avec une précision élevée; les environnements à haute latence ou quand un NTP n'est pas disponible peuvent avoir besoin d'une tolérance plus élevée.

Profile de transport

Le répondeur OCSP doit supporter les requêtes et réponses sur HTTP. En envoyant les requêtes qui sont inférieur ou égal à 255 octets au total (après encodage) incluant le schéma et les délimiteurs (http://), le nom du serveur et la structure OCSPRequest encodé en base 64, les clients doivent utiliser la méthode GET (pour permettre le caching de réponse OCSP). Les requêtes OCSP supérieurs à 255 octets devraient être envoyés en utilisant la méthode POST. Dans tous les cas, les clients doivent suivre les descriptions définis dans la norme OCSP en construisant leurs messages.

En construisant un message GET, les clients OCSP doivent encoder en base 64 la structure OCSPRequest et l'ajouter à l'URI spécifiée dans l'extension authorityInfoAccess. Les clients ne doivent pas inclure les caractères CR ou LF dans la chaîne encodée base 64. Les clients doivent encoder l'url proprement, par exemple:
http://ocsp.example.com/MEowSDBGMEQwQjAKBggqhkiG9w0CBQQQ7sp6GTKpL2dAdeGaW267owQQqInESWQD0mGeBArSgv%2FBWQIQLJx%2Fg9xF8oySYzol80Mbpg%3D%3D

En réponse aux OCSPRequests formatés proprement qui sont capable d'être mis en cache (par exemple, les réponses qui contiennent une valeur nextUpdate), le répondeur va inclure la valeur binaire de l'encodé DER de l'OCSPResponse précédé par l'en-tête HTTP suivant:
content-type: application/ocsp-response
content-length: ‹OCSP response length›
last-modified: ‹producedAt [HTTP] date›
ETag: "‹strong validator›"
expires: ‹nextUpdate [HTTP] date›
cache-control: max-age=‹n›, public, no-transform, must-revalidate
date: ‹current [HTTP] date›

Recommandations de mise en cache

La capacité de mise en cache des réponses OCSP via le réseaux est un facteur important dans les déploiements à haut volume. Cette section discute de comportement de la mise en cache des clients OCSP et des proxy HTTP et les étapes qui devraient être faites pour minimiser le nombre de fois que les clients OCSP utilisent le réseaux. De plus, le concept de réponses OCSP incluses dans les échanges de protocole ( stapling ou piggybacking), tel que définis dans TLS, sont également discutés.

Mise en cache par le client

Pour minimiser l'utilisation de la bande passante, les clients doivent mettre en cache localement les réponses OCSP autoritatives (ex: une réponse avec une signature qui a été validée avec succès et qui indique un OCSPResponseStatus 'successful').

Beaucoup de clients OCSP vont envoyer des OCSPRequests à ou près du temps nextUpdate (quand une réponse mise en cache expire). Pour éviter des pointes importantes dans la charge des répondeurs qui peuvent se produire quand de nombreux clients rafraîchissent les réponses en cache pour un certificat populaire, les répondeurs peuvent indiquer quand le client devrait chercher une réponse OCSP mise à jours en utilisant la directive cache-control:max-age. Pour s'assurer que les clients reçoivent une réponse mises à jours, les répondeurs OCSP doivent rafraîchir la réponse OCSP avant le temps max-age.

Proxy HTTP

   Le répondeur devrait définir l'en-tête HTTP dans la réponse OCSP de manière à permettre une utilisation intelligente des serveurs proxy intermédiaire. Voir la norme HTTP pour la définition de ces en-têtes et le format correcte.

HTTP Header___Description
date La date et l'heure à laquelle le serveur OCSP a généré la réponse HTTP.
last-modified Cette valeur spécifie la date et l'heure à laquelle le répondeur OCSP à modifié la réponse. Cette date sera la même que thisUpdate dans la requête elle-même.
expires Spécifie la durée de à laquelle la réponse est considérée comme récente. Cette date est la même que nextUpdate dans la réponse OCSP.
ETag Une chaîne qui identifie une version particulière de la donnée associée. Ce profile recommande que la valeur ETag soit une représentation hexa ASCII du hash SHA1 de la structure OCSPResponse
cache-control Contient des directives de mise en cache:

* max-age=‹n› où n est la valeur de temps ultérieur à thisUpdate mais inférieur à nextUpdate.
* public rend la réponse non cachable
* no-transform Spécifie qu'une proxy cache ne peut pas changer le type, longueur, ou encodage du contenu de l'objet.
* must-revalidate empêche les caches de retourner des réponses périmées intentionnellement

   Les répondeurs OCSP ne doivent pas inclure d'en-tête "Pragma: no-cache", "Cache-Control: no-cache", ou "Cache-Control: no-store" dans les réponses OCSP autoritatives. Les répondeurs OCSP devraient inclure un ou plusieurs de ces en-têtes dans les réponses non-autoritatives.

Par exemple, supposons une réponse OCSP ayant les horodatages suivant:
thisUpdate = May 1, 2005 01:00:00 GMT
nextUpdate = May 3, 2005 01:00:00 GMT
productedAt = May 1, 2005 01:00:00 GMT

Et que les clients demandent la réponse le 2 may 2005 01:00:00 GMT. Dans ce scénario, la réponse HTTP peut ressembler à ceci:
content-type: application/ocsp-response
content-length: 1000
date: Fri, 02 May 2005 01:00:00 GMT
last-modified: Thu, 01 May 2005 01:00:00 GMT
ETag: "c66c0341abd7b9346321d5470fd0ec7cc4dae713"
expires: Sat, 03 May 2005 01:00:00 GMT
cache-control: max-age=86000,public,no-transform,must-revalidate
‹...›

   Les clients OCSP ne doivent pas inclure d'en-tête no-cache dans les demandes, sauf si le client rencontre une réponse expirée qui peut être le résultat d'une donnée périmée d'un proxy cache. Dans cette situation, les clients devraient renvoyer le demande en spécifiant que les proxy devraient être bypassés en incluant un en-tête HTP approprié dans la demande (ex. Pragma: no-cache ou Cache-Control: no-cache).

Mise en cache des serveurs

   Dans certains scénarios, il est avantageux d'inclure les information de réponse OCSP dans le protocole utilisé entre le client et le serveur. En incluant les réponses OCSP de cette manière a quelques effet désirable.

   D'abord, il permet la mise en cache des réponses OCSP dans le serveur diminuant ainsi le nombre de requêtes au répondeur.

   Ensuite, il permet la validation de certificat dans le cas où le client n'est pas connecté à un réseaux et donc élimine le besoin pour les clients d'établir une nouvelle session HTTP avec le répondeur.

   Il réduit le nombre d'aller-retours que le client a besoin pour compléter un handshake

   Enfin, il simplifie l'implémentation OCSP côté client en permettant une situation où le client n'a seulement besoin de la capacité de parser et reconnaître les réponses OCSP.

   Cette fonctionnalité a été spécifiée comme extension du protocole TLS, mais peut être appliqué à tout protocole client-serveur.

   Ce profile recommande que les clients et les serveurs TLS implémentent le mécanisme d'extension de demande de statut de certificat pour TLS.

   D'autres informations sur les problèmes de mise en cache peuvent être obtenus depuis la rfc3143.

Considérations de sécurité

Les considérations suivantes s'appliquent en plus des considérations de sécurité spécifié dans la norme OCSP.

Attaques Replay

   Puisque l'utilisation de nonce dans ce profile est optionnel, il y a possibilité qu'une réponse OCSP périmée puisse être rejouée, causant le client à accepter une réponse 'good' quand en fait il a été révoké. Pour réduire cette attaque, les clients doivent avoir accès à une source de temps précise et s'assurer que les réponses OCSP qu'ils reçoivent sont suffisamment récentes.

   Les clients qui n'ont pas de source de temps précise sont vulnérables. Par exemple, un client avec une horloge suffisamment rapide peut rejeter une réponse OCSP récente et accepter une réponses valide qui est expirée pour des certificat qui sont en fait révoqués.

   De future versions du protocole OCSP peuvent fournir une manière pour le client de savoir si le serveur supporte nonce ou non. Si un client peut déterminer que le serveur supporte nonce, il doit rejeter une réponse qui ne contient pas le nonce attendu. Sinon, les client qui optent pour inclure un nonce dans la demande ne devraient pas rejeter l'OCSPResponse correspondant uniquement sur la base de la non-existance du nonce, mais doivent également valider OCSPResponse sur la base du temps.

Attaques Man-In-The-Middle

Pour réduire les risques associés avec ce type d'attaque, le client doit valider correctement la signature de la réponse. L'utilisation de réponses signées dans OCSP sert à authentifier l'identité du répondeur OCSP et de vérifier qu'il est autorisé à signer les réponses de la CA.

Attaques pas usurpation d'identité

L'utilisation de réponses signées dans le serveur OCSP sert à authentifier l'identité du répondeur OCSP. Comme détaillé dans OCSP, les clients doivent valider correctement la signature de la réponse OCSP et la signature du certificat du signataire OCSP pour s'assurer que le répondeur est autorisé.

Attaques pas deni de service

Les répondeurs OCSP devraient prendre des mesures pour empêcher ou réduire les attaques par déni de service. Vu que ce profile spécifie l'utilisation de OCSPRequests non-signés, l'accès au répondeur peut être donné implicitement par toute personne qui souhaite envoyer une demande à un répondeur, et ainsi la capacité de monter des attaques par déni de service via des demandes en rafales. Par exemple, un répondeur peut limiter le taux de demande entrante pour une adresse IP particulière si un comportement douteux est détecté.

Modification des en-têtes HTTP

Les valeurs incluses dans les en-têtes HTTP ne sont pas protégées cryptographiquement; elles peuvent être manipulées par un attaquant. Les clients devraient utiliser ces valeurs pour la mise en cache seulement après s'assurer que les valeurs sont présentes dans le OCSPResponse signé. Les clients ne devraient pas valider les réponses au-delà de la date nextUpdate.

Authentification et autorisation des demandes

La suggestion d'utiliser des demandes non-signée dans cet environnement supprime une option qui permet au répondeur de déterminer l'authenticité de la requête entrante. Donc, l'accès au répondeur peut être implicitement donné à toute personne qui peut envoyer une demande à un répondeur. Les environnement où l'autorisation explicite pour accéder au répondeur OCSP est nécessaire peuvent utiliser d'autres mécanismes pour authentifier les demandeurs, ou restreindre le service.

26 novembre 2014

rfc5208

Syntaxe et conteneur pour les informations de clé privée

Définitions

Les informations de clé privée incluent une clé privée pour un algorithme à clé publique spécifié, et un jeu d'attributs. La syntaxe de message cryptographique, dénifis dans la rfc5652, peut être utilisé pour signer numériquement, hasher, authentifier ou chiffrer le type de contenu de clé asymétrique.

La liste suivante sont les mises à jours de la rfc5208:

- PrivateKeyInfo a été changé en OneAsymmetricKey. Cela reflète l'ajout du champ publicKey pour permettre aux 2 parties de la clé asymétrique d'être transportés séparément.
- Définition du type de contenu CMS asymmetric Key Package
- Suppression de la redondance IMPLICIT des attributs
- Ajout de publicKey à OneAsymmetricKey et mise à jour du numéro de version
- Ajout du support des attributs PKCS #9
- Ajout d'une discussion sur la compatibilité avec d'autres formats de clé privée
- Ajout des pré-requis pour le jeu de règle d'encodage
- Changement des imports depuis PKCS #5
- Remplacement de ALGORITHM-IDENTIFIER avec ALGORITHM depuis la rfc 5912
- Enregistrement du type de média application/pkcs8 et de l'extension de fichier .p8

Asymmetric Key Package CMS Content Type

   Le type de contenu CMS paquet de clé asymétrique est utilisé pour transférer une ou plusieurs clé asymétrique d'un partie à un autre. Un paquet de clé asymétrique peut être encapsulé dans un ou plusieurs types de contenu CMS de protection. Les anciennes versions de cette spécification de spécifiaient pas de jeu de règle d'encodage particulier, mais les générateurs devraient utiliser DER et les destinataires doivent supporter BER, qui inclus également DER.

Ce type de contenu a la syntaxe suivante:
ct-asymmetric-key-package CONTENT-TYPE ::=
    { AsymmetricKeyPackage IDENTIFIED BY id-ct-KP-aKeyPackage }

id-ct-KP-aKeyPackage OBJECT IDENTIFIER ::=
    { joint-iso-itu-t(2) country(16) us(840) organization(1)
        gov(101) dod(2) infosec(1) formats(2)
        key-package-content-types(78) 5
    }

AsymmetricKeyPackage ::= SEQUENCE SIZE (1..MAX) OF OneAsymmetricKey

OneAsymmetricKey ::= SEQUENCE {
    version Version,
    privateKeyAlgorithm PrivateKeyAlgorithmIdentifier,
    privateKey PrivateKey,
    attributes [0] Attributes OPTIONAL,
    ...,
    [[2: publicKey [1] PublicKey OPTIONAL ]],
    ...
}

PrivateKeyInfo ::= OneAsymmetricKey

    -- PrivateKeyInfo est utilisé par [P12]. Si un élément taggé en version 2 est utilisé,
    -- La version doit être v2, sinon la version devrait être 1. Quand v1 est utilisé,
    -- PrivateKeyInfo est le même que dans la [RFC5208].

Version ::= INTEGER { v1(0), v2(1) } (v1, ..., v2)

PrivateKeyAlgorithmIdentifier ::= AlgorithmIdentifier
    { PUBLIC-KEY,
        { PrivateKeyAlgorithms } }

PrivateKey ::= OCTET STRING
    -- Le contenu varie en fonction du type de clé. L'identifiant d'algorithme dicte le format de la clé

PublicKey ::= BIT STRING
    -- Le contenu varie en fonction du type de clé. L'identifiant d'algorithme dicte le format de la clé

Attributes ::= SET OF Attribute { { OneAsymmetricKeyAttributes } }

   AsymmetricKeyPackage contient un ou plusieurs élément OneAsymmetricKey.

   La syntaxe de OneAsymmetricKey accueille un numéro de version, une indication de l'algorithme asymétrique à utiliser avec la clé privée, une clé privée, des attributs optionnels ( par ex. userCertificate de X.520 ), et une clé publique optionnelle. En général, doit la clé publique, soit le certificat est présent. Dans de très rare cas les 2 sont présents, vu qu'ils incluent chacun une copie de la clé publique. OneAsymmetricKey renomme la syntaxe PrivateKeyInfo définie dans la rfc5208. Le nouveau nom reflète mieux la capacité de s'occuper des composant clé publique et privée. La compatibilité avec PrivateKeyInfo est préservée via le numéro de version. Les champs dans OneAsymmetricKey sont utilisé comme suit:

version Identifie la version de OneAsymmetricKey. Si publicKey est présent, la version est v2 sinon v1.
privateKeyAlgorithm Identifie l'algorithme de clé privée et optionnellement les paramètres associés avec la paire de clé asymétrique. L'algorithme est identifiée par un OID et le format des paramètres dépend de cet OID, mais le jeu d'objets privateKeyAlgorithms restreins les OID permis. La valeur placée dans PrivateKeyAlgorithmIdentifier est la valeur d'un algorithme utilisé avec la clé privée.
privateKey Est une chaîne d'octets qui contiennent la valeur de la clé privée. L'interprétation du contenu est définis dans l'enregistrement de l'algorithme de clé privée. Par exemple, une clé DSA est un entier, une clé RSA est représentée en RSAPrivateKey comme définis dans la rfc3447, et une clé ECC est représentée comme ECPrivateKey comme définie dans la rfc5915.
attributes est optionnel et contient les informations correspondantes à la clé publique (par ex: les certificats). Les champs attributes utilise la classe ATTRIBUTE qui est restreins par le jeu d'objet OneAsymmetricKeyAttributes. Les attributs de la rfc2985 peuvent être supportés.
publicKey est optionnel. Si présent, il contient la clé publique encodée en chaîne de bits. L structure dans cette chaîne dépend de privateKeyAlgorithm. Par exemple, une clé DSA est un entier. Noter que les clé publiques RSA sont inclues dans RSAPrivateKey, comme dans rfc 3447, et les clé publiques ECC sont inclues dans ECPrivateKey, comme dans rfc 5915.

Informations de clé privée chiffrée

Cette section donne la syntaxe pour les informations de clé privée chiffrée qui sont utilisées par [P12]:
EncryptedPrivateKeyInfo ::= SEQUENCE {
    encryptionAlgorithm EncryptionAlgorithmIdentifier,
    encryptedData EncryptedData }

EncryptionAlgorithmIdentifier ::= AlgorithmIdentifier
    { CONTENT-ENCRYPTION,
        { KeyEncryptionAlgorithms } }

EncryptedData ::= OCTET STRING

encryptionAlgorithm Identifie l'algorithme sous lequel les informations de clé privée sont chiffrées.
encryptedData Est le résulta du chiffrement des informations de clé privée.

   Le processus de chiffrement est constitué des étapes suivantes:

1. Les informations de clé privée sont encodées. Les générateurs devraient utiliser DER et les destinataires doivent supporter BER, qui inclus également DER
2. Le résultat de la première étape est chiffré avec la clé secrète pour donner une chaîne d'octets, le résultat du processus de chiffrement.

Protection de AsymmetricKeyPackage

Les types de contenu de protection CMS peuvent être utilisés pour fournir une sécurité à AsymmetricKeyPackage:

SignedData Peut être utilisé pour appliquer une signature numérique à AsymmetricKeyPackage
EncryptedData Peut être utilisé pour chiffrer AsymmetricKeyPackage avec un chiffrement symétrique, où l'émetteur et le destinataire partagent déjà la clé de chiffrement nécessaire.
EnvelopedData Peut être utilisé pour chiffrer AsymmetricKeyPackage avec un chiffrement symétrique, où l'émetteur et le destinataire ne partagent pas la clé de chiffrement nécessaire.
AuthenticatedData Peut être utilisé pour protéger AsymmetricKeyPackage avec MAC, où les informations de gestion de clé sont manipulées d'une manière similaire à EnvelopedData.
AuthEnvelopedData Peut être utilisé pour protéger AsymmetricKeyPackage avec des algorithmes qui supportent de chiffrement authentifié, où les informations de gestion de clé sont manipulées d'une manière similaire à EnvelopedData.

Considérations d'autres format de clé privée

Ce document définis la syntaxe et les sémantiques pour un type de contenu qui échange des clé privées asymétriques. Il y a 2 autres formats qui ont été utilisés pour le transport de clé privée asymétiques:

Personal Information Exchange Est une syntaxe transfert pour les informations d'identité personnelle, incluant les clés privées, certificats, divers autres secrets, et des extensions. OneAsymmetricKey, PrivateKeyInfo, et EncryptedPrivateKeyInfo peuvent être inclus dans un message p12. Les informations de clé privée, OneAsymmetricKey et PrivateKeyInfo, sont inclus dans le KeyBag BAG-TYPE P12. EncryptedPrivateKeyInfo est inclu dans le pkcs8ShroudedKeyBag BAG-TYPE P12. Dans les implémentations courantes, les extensions pfx et p12 peuvent être utilisées.
Microsoft's private-key l'extension pvk est utilisé pour des stockages locaux. pvk et p12 ne sont pas interchangeables.

Pour extraire les information de clé privée du AsymmetricKeyPackage les couches d'encapsulations doivent être enlevées. Au minimum, la couche ContentInfo doit être enlevée. Si le AsymmetricKeyPackage est encapsulée dans une donnée signée, puis les couches SignedData et EncapsulatedContentInfo doivent également être supprimées. C'est la même chose pour EnvelopedData, EncryptedData, et AuthenticatedData. Une fois toutes les couches supprimées, il y a autant de jeux d'information de clé privée qu'il y a de structure OneAsymmetricKey. OneAsymmetricKey et PrivateKeyInfo ont la même structure, donc peuvent être sauvées en tant que fichier p8 ou copiés dans un BAG-TYPE KeyBag p12. Supprimer les couches de sécurité encapsulantes va invalider toute signature et peut exposer la clé.

Les fichiers p8 sont parfois encodés PEM, et dans ce cas utilisent l'extension pem. L'encodage PEM est soit l'encodage Base64 ou de type EncryptedPrivateKeyInfo encodé DER inclus entre:
-----BEGIN ENCRYPTED PRIVATE KEY-----
-----END ENCRYPTED PRIVATE KEY-----

ou l'encodage Base64 du PrivateKeyInfo encodé DER entre:
-----BEGIN PRIVATE KEY-----
-----END PRIVATE KEY-----

Media application/pkcs8

Type name: application
Subtype name: pkcs8
Required parameters: None
Optional parameters: None
Encoding considerations: binary
Security considerations: Carries a cryptographic private key
Interoperability considerations: The PKCS #8 object inside this media type MUST be DER-encoded PrivateKeyInfo.
Published specification: RFC 5958
Applications which use this media type: Any MIME-compliant transport that processes asymmetric keys.
Additional information: Magic number(s): None
File extension(s): .p8
Macintosh File Type Code(s): Person & email address to contact for further information: Sean Turner ‹turners@ieca.com›
Restrictions on usage: none

06 mars 2015

rfc5280

rfc5280, rfc6818

Profile de certification et de liste de révocation de certificat d'infrastructure à clé publique X.509

Introduction

   Cette spécification fait partie d'une famille de standards pour les infrastructures à clé publique X.509 pour l'Internet.

   Cette spécification profile le format et les sémantiques des certificats et des listes de révocation de certificat pour les PKI Internet. Les procédures sont décrites pour traiter les chemins de certification dans l'environnement Internet. Finalement, les modules ASN.1 sont fournis dans l'appendice pour toutes les structures de données définies ou référencées.

La section "Exigences et hypothèses" décris les pré-requis de PKI Internet et les hypothèses qui affectent le périmètre de ce document.
La section "Aperçu de l'approche" Présentent un modèle d'architecture qui décrivent ses relations aux précédant standards IETF et ISO/IEC/ITU-T. En particulier, la relation de ce document avec les spécification PEM IETF et les document ISO/IEC/ITU-T X.509 sont décris.
La section "Profile de certificat et d'extensions de certificat" profile les certificats X.509 version 3.
La section "Profile de CRL et d'extensions de CRL" profile les CRL X.509 v2.
La section "Validation de chemin de certification" inclus les procédures de validation de chemin de certification. Ces procédures sont basée sur la définition ISO/IEC/ITU-T.

   Les procédures pour l'identification et l'encodage des clés publiques et des signatures numérique sont définis dans la rfc3279, la rfc 4055, et la rfc4491. Les implémentations de cette spécification ne sont pas obligés d'utiliser un algorithme crypto-graphique particulier. Cependant, les implémentations conformes qui utilisent les algorithmes identifiés dans la rfc3279,la rfc 4055, et la rfc 4491 doivent identifier en encoder la clé publique et les signatures numérique comme décris dans ces spécifications.

   Finalement, 2 appendices sont fournis pour aider les implémenteurs.

  Cette spécification obsolète la rfc 3280. Les différences sont résumées ici:

- Support amélioré pour les noms internationalisés, avec des règles pour l'encodage et la comparaison de noms de domaines internationalisés, Identifiant de ressources internationalisés (IRI), et de noms distinct. Ces règles sont alignés avec les règles de comparaison établies dans les rfc courantes, incluant la rfc3490, rfc3987 et la rfc 4518.
- Les section "Issuer" et "Subject" incorporent les conditions pour l'utilisation continue de schémas d'encodage de texte existant qui ont été spécifiés dans la rfc4630. Là où c'est utilisé par les PKI établies, la transition vers UTF8String pourrait poser des problème DOS basés sur les erreurs de chaînage de nom ou des traitement incorrecte de contraintes de nom.
- La section qui spécifie l'extension de certificat privateKeyUsagePeriod de la rfc 3280, mais déprécie son utilisant, a été supprimée. L'utilisation de cette extension standards ISO n'est plus dépréciée ni recommandée pour l'utilisation dans les PKI de l'Internet.
- La section Policy Mappings recommande de marquer l'extension de contraintes de stratégie comme critique. La rfc 3280 nécessitait que l'extension de mappage de stratégie soit marquée non critique.
- La section Policy Constraints nécessite que l'extension de contraintes de stratégie soit critique. la rfc 3280 permettait cette extension d'être critique ou non.
- L'extension de CRL AIA, comme spécifié dans la rfc 4325, a été ajoutée.
- Les sections extensions de CRL et extensions d'entrée de crl clarifient les règles pour manipuler les extensions de CRL et d'entrée de CRL non-reconnues, respectivement.
- La section qui spécifie l'extension d'entrée de CRL holdInstructionCode dans la rfc 3280 a été supprimée.
- L'algorithme de validation de chemin ne suit plus la criticité des extensions de stratégie de certificat dans une chaîne de certificats. Dans la rfc 3280, cette information était retourné à un tier de confiance.
- La section de considérations de sécurité adresse les risques de dépendances circulaires se produisant lors de l'utilisation de schémas https ou similaire dans les points de distribution de CRL, AIA, ou extension d'accès aux informations du sujet.
- La section de considérations de sécurité adresse les risques associés aves l'ambiguïté des noms
- La section de considérations de sécurité référence les rfc 4210 pour les procédures pour signaler les changements dans les opération de CA.

Pré-requis et hypothèses

   Le but de cette spécification est de développer un profil pour faciliter l'utilisation des certificats X.509 dans les applications Internet pour les communautés qui souhaitent utiliser la technologie X.509. De telles applications peuvent inclure WWW, les messageries électroniques, l'authentification utilisateur, et IPSec. Afin de soulager certains obstacles à l'utilisation des certificat X.509, cet document définis un profile pour promouvoir le développement de systèmes de gestion de certificat, le développement d'outils applicatifs, et d'interopérabilité déterminé par stratégie.

   Un utilisateur de certificat devrait revoir la stratégie de certificat générée par l'autorité de certification avant de faire confiance aux services d'authentification et de non-répudiation associés avec la clé publique dans un certificat particulier. À cette fin, ce standards ne prescrit pas de règles juridiques contraignantes ou de droits.

   Vu que les outils d'autorisation supplémentaires et de gestions d'attributs émergent, tels que les certificats d'attributs, il peut être approprié de limiter les attributs authentifiés qui sont inclus dans un certificat. Ces autres outils de gestion peuvent fournir des méthodes plus appropriés de transport de nombreux attributs authentifiés.

Communication et topologie

Les utilisateurs de certificat vont opérer dans une grande variété d'environnements en respect de leur topologie de communication, spécialement les utilisateurs de messagerie électronique. Ce profile supporte les utilisateurs à faible bande passante, connectivité IP temps-réel, ou connexion à haute disponibilité. En plus, le profile permet la présence de firewall ou autre communication filtrée.

Ce profil n'assume pas le déploiement d'un système d'annuaire X.500 ou LDAP. Le profile n'interdit pas leur utilisation; cependant, tout moyen de distribuer des certificats et CRL peut être utilisé.

Critère d'acceptabilité

Le but d'une PKI est de répondre aux besoins de fonctions déterministes, d'identification automatisée, d'authentification, de contrôle d'accès, et d'autorisation. Le support pour cet services détermine les attributs contenus dans le certificat aussi bien que les information de contrôle auxiliaire dans le certificat tel que les données de stratégie et contraintes de chemin de certification.

Attentes des utilisateurs

Les utilisateurs de PKI Internet sont des gens et des processus qui utilisent des clients logiciel et sont les sujets nommés dans les certificats. Ces utilisations incluent les lecteurs et rédacteurs de messages électroniques, les clients pour les navigateurs web, les serveurs web, et le gestionnaire de clé pour IPSec dans un routeur. Ce profile reconnaît les limitations des plate-formes que les utilisateurs utilisent et les limitations de la sophistication et de l'attention des utilisateurs eux-même. Cela se manifeste dans la responsabilité minimale de la configuration utilisateur (ex: les clé de CA de confiance, les règles), les contraintes d'utilisation des plate-formes explicites dans le certificat, les contraintes de chemin de certification qui protège l'utilisateur les actions malicieuses, et les applications qui automatise sensiblement les fonction de validation.

Attentes des administrateurs

Comme avec les attentes des utilisateurs, le profile PKI de l'Internet est structuré pour supporter les individus qui opèrent généralement les CA. Fournir aux administrateurs des choix illimités augmente les chances qu'une erreur subtile d'administrateur de CA résulte en un large compromission. En outre, des choix illimités compliquent grandement le logiciel qui traite et valide les certificats crées par la CA.

Présentation de l'approche

Ceci est une vue simplifiée du modèle architecturel assumé par les infrastructures à clé publique utilisant les spécification X.509 ( PKIX ). Les composants dans ce modèle sont:

end entity L'utilisateur de certificats PKI et/ou le système utilisateur final qui est le sujet d'un certificat.
CA Autorité de certification
RA Autorité d'enregistrement, ex. un système opérationnel pour lequel une CA délègue certaines fonctions de gestion.
CRL issuer Un système qui génère et signe les CRL
repository Un système ou une collection de systèmes distribués qui stockent les certificats et les CRL et sert de moyen de distribution aux end entity

Les CA sont responsables de l'indication du statut de révocation des certificats qu'elles fournissent. Les informations de statut de révocation peuvent être fournis en utilisant OCSP, CRL, ou d'autres mécanismes. En général, quand les informations de statut de révocation sont fournis en utilisant les CRL, la CA est également le CRL issuer. Cependant, une CA peut déléguer cette responsabilité à une entité différente.

Noter qu'un Attribute Authority ( AA ) peut également choisir de déléguer la publication des CRL à un CRL issuer.
___+---+
___|_C_|_______________________+------------+
___|_e_|_‹--------------------›|_End_entity_|
___|_r_|_______Operational_____+------------+
___|_t_|_______transactions__________^
___|_i_|______and_management_________|__Management
___|_f_|_______transactions__________|__transactions________PKI
___|_i_|_____________________________|_____________________users
___|_c_|_____________________________v
___|_a_|_=======================__+--+------------+__==============
___|_t_|__________________________^_______________^
___|_e_|__________________________|_______________|_________PKI
___|___|__________________________v_______________|______management
___|_&_|_______________________+------+___________|_______entities
___|___|_‹---------------------|__RA__|‹----+_____|
___|_C_|__Publish_certificate__+------+_____|_____|
___|_R_|____________________________________|_____|
___|_L_|____________________________________|_____|
___|___|____________________________________v_____v
___|_R_|________________________________+------------+
___|_e_|_‹------------------------------|_____CA_____|
___|_p_|___Publish_certificate__________+------------+
___|_o_|___Publish_CRL_____________________^______^
___|_s_|___________________________________|______|__Management
___|_i_|________________+------------+_____|______|__transactions
___|_t_|_‹--------------|_CRL_Issuer_|‹----+______|
___|_o_|___Publish_CRL__+------------+____________v
___|_r_|______________________________________+------+
___|_y_|______________________________________|__CA__|
___+---+______________________________________+------+

Certificat X.509 Version 3

   Les utilisateurs d'une clé publique nécessitent la confidentialité de la clé privée associée qui est possédée par le bon sujet ( personne ou système ) avec laquelle un mécanisme de chiffrement ou de signature numérique sera utilisé. Cette confidentialité est obtenue via l'utilisation de certificats à clé publique, qui sont des structures de donnée qui lie des valeurs de clés publique à des sujets. La liaison est affirmée en ayant un CA de confiance qui signe numériquement chaque certificat. La CA peut baser cette affirmation sur les moyens techniques (ex: preuve de possession via un protocole de challenge/réponse), la présentation de la clé privée, ou sur une affirmation par le sujet. Un certificat a une durée de vie limitée, qui est indiquée dans son contenu signé. Parce que la signature du certificat et la du validité peuvent être vérifiés indépendamment par un client, les certificats peuvent être distribués via des communication et des systèmes serveurs non-sûres, et peuvent être mis en cache dans des stockages dans des systèmes non-sûres.

   l'ITU-T X.509 ou l'ISO/IEC 9594-8, qui a été publié en 1988 comme partie des recommandations des annuaires X.500, définis un format de certificat standard. Le format de certificat dans le standard 1988 est appelé le format version 1 (v1). Quand X.500 a été révisé en 1993, 2 champs ont été ajoutés, résultant en un format version 2 (v2).

   Les rfc PEM, publiés en 1993, incluent les spécifications pour une infrastructure à clé publique basés sur X.509 v1 (rfc 1422). L'expérience a montré que les déploiement rfc 1422 faits avec les formats v1 et v2 étaient défaillant dans de nombreux aspects. Plus important, de nombreux champs étaient nécessaires pour gérer les information que le concept et l'implémentation de PEM a démontré la nécessité. En réponse, l'ISO/IEC, l'ITU-T, et ANSI X9 on développés le format de certificat version 3 (v3). Il étend le format v2 en ajoutant les champs d'extension additionnels. Les types de champ d'extension particulier peuvent être spécifiés dans des standards ou peuvent être définis et enregistrés par une organisation ou une communauté. En Juin 1996, la standardisation du format de base v3 a été complété.

   L'ISO/IEC, l'ITU-T, et ANSI X9 ont également développés des extensions standard développés pour l'utilisation dans le champs d'extensions v3. Ces extensions peuvent transmettre des données telles des informations d'identification de sujet additionnels, des information d'attribut de clé, informations de stratégie, et de contraintes de chemin de certification.

   Cependant, les extensions standard e l'ISO/IEC, l'ITU-T, et de l'ANSI X9 étaient très générales dans leur utilisation. Pour développer des implémentations intéropérable des système X.509 v3 pour l'Internet, il est nécessaire de spécifier un profile pour utiliser les extensions X.509 v3 adaptés pour l'Internet. C'est un des objectifs de ce document pour spécifier un profile pour WWW, les messages électroniques, et les application IPSec. Les environnements avec les pré-requis additionnels peuvent construire par-dessus ce profil pour le remplacer.

Chemins de certification et confiance

   Un utilisateur d'un service de sécurité nécessitant la connaissance d'une clé publique, a besoin généralement d'obtenir et de valider un certificat contenant la clé publique requise. Si l'utilisateur de clé publique ne possède pas une copie fiable de la clé publique de la CA qui a signé le certificat, le nom de la CA et les information liées (tel que la période de validité, ou les contraintes de nom), alors il peut nécessiter un certificat additionnel pour obtenir la clé publique. En général, une chaîne de plusieurs certificats peuvent être nécessaires, comprenant un certificat du propriétaire de la clé publique ( l'entité finale) signée par une CA, et 0 ou plusieurs certificats de CA signés par d'autres CA. De telles chaînes, appelées chemin de certification, sont requis parce qu'un utilisateur de clé publique est seulement initialisé avec un nombre limité de clé publique de CA.

   Les CA peuvent être configurées de différentes manières pour que les utilisateurs de clé publique soient capable de trouver les chemins de certification. Pour PEM, la rfc 1422 définis une structure hiérarchique rigide de CA. Il y a 3 types d'autorité de certification PEM:

(a) Internet Policy Registration Authority (IPRA): cette autorité, qui opère sous les auspices de l'Internet Society, agit comme le niveau racine de la hiérarchie de certification PEM, au niveau 1. Il fournis des certificats uniquement pour le niveau suivant d'autorités, les PCA. Tous les chemins de certification commencent avec l'IPRA.
(b) Policy Certification Authorities (PCAs): les PCA sont au niveau 2 de la hiérarchie, chaque PCA est certifié par l'IPRA. Un PCA devrait établir et publier un état de sa stratégie, avec respect de certifier des utilisateurs ou des autorités de certification subordonnés. Des PCA distincts ont pour objectifs de satisfaire différents besoins utilisateurs. Par exemple, un PCA peut supporter les besoins de messages électroniques des organisations commerciales, et un autre PCA peut avoir une stratégie plus stricte conçue pour satisfaire les besoins légaux des signatures numériques.
(c) Les autorités de certification (CA): les CA sont au niveau 3 de la hiérarchie et peuvent également être à des niveaux inférieurs. Ceux de niveau 3 sont certifiés par les PCA. Les CA représentent, par exemple, des organisations particulières, les unités organisationelles particulières, ou des zones géographiques particulières.

   La rfc 1422 a en outre une règle de subordination de nom, qui nécessite qu'une CA peut seulement fournir des certificats pour des entités dont les noms sont subordonnés au nom de la CA elle-même, le trust associé avec un chemin de certification PEM est impliqueé par le nom du PCA. La règle de subordination de nom s'assure que les CA sous le PCA sont contraint sensiblement au jeu d'entité subordonnés qu'ils peuvent certifier. Les systèmes d'utilisateurs de certificat sont capable de vérifier mécaniquement que la règle de subordination de nom a été suivie.

   La rfc 1422 utilise le format de certificat X.509 v1. Les limitations de cette version impose de nombreuses restrictions structurelles pour associer clairement les information de stratégie ou restreindre l'utilité des certificats. Ces restrictions incluent:

(a) Un hiérarchie "top-down", avec tous les chemins de certifications commençant depuis IPRA
(b) Une règle de subordination de nom qui restreints les noms des sujets des CA
(c) L'utilisation du concept PCA, qui nécessite la connaissance de tous les PCA individuells pour construire la logique de vérification de la chaîne de certification.

   Avec X.509 v3, la plupart des pré-requis adressés par la rfc1422 peuvent être adressés en utilisant les extensions de certificats, sans avoir à restreindre les structures CA utilisées. En particulier, les extensions de certificat liées aux stratégies de certificat évitent les besoins de PCA et les extensions de contraintes évitent les besoins de règle de subordination de nom. En résultat, ce document supporte une architecture plus flexible, incluant:

(a) Les chemins de certification commencent avec une clé publique d'une CA dans le domaine de l'utilisateur, ou avec la clé publique de la racine d'une hiérarchie. Commencer avec la clé publique d'une CA dans le domaine de l'utilisateur a certains avantages. Dans certains environnements, le domaine local est le plus sûr.
(b) Les contraintes de nom peuvent être imposés via l'inclusion explicite d'une extension de contrainte de noms dans un certificat, mais n'est pas requis.
(c) Les extensions de stratégie et les mappages de stratégie remplacent le concept de PCA, qui permet un plus haut degré d'automatisation. L'application peut determiner si le chemin de certification est acceptable basé sur le contenu du certificat au lieu d'un connaissance à priori des PCA. Cela permet d'automatiser le traitement des chemins de certification.

   X.509 v3 inclus également une extension qui identifie le sujet d'un certificat comme étant une CA ou une entité finale, réduisant la dépendance sur les informations out-of-band démandé dans PEM.

   Cette spécification couvre 2 classes de certificats: les certificats CA et les certificats d'entité finale. Les certificats CA peuvent être divisés en 3 classes: cross-certificats, certificats auto-fournis et certificat auto-signés.

Les Cross-certificats sont des certificats CA dans lequel le fournisseur et les sujets sont des entités différentes. Les Cross-certificats décrivent une relation de confiance entre les 2 CA.
Les certificats auto-fournis sont des certificat CA dans lequel le fournisseur et le sujet sont la même entité. Les certificats auto-fournis sont générés pour supporter les changements dans la stratégie ou les opérations.
Les certificats auto-signés sont des certificat auto-fournis où la signature numérique peut être vérifiée par la clé publique lié dans le certificat. Les certificats auto-signés sont utilisé pour transporter une clé publique à utiliser au début des chemins de certification.

   Les certificats d'entité finale sont fournis aux sujets qui ne sont pas autorisés à fournir de certificats.

Révocation

   Quand un certificat est fournis, il est prévu pour être utilisé pour toute sa période de validité. Cependant, diverses circonstances peuvent causer un certificat à devenir invalide avant l'expiration de la période de validité. De telles circonstances incluent le changement de nom, changement d'association entre le sujet et la CA (ex: un employé termine sont emploie avec une organisation ), et la compromission de la clé privée associée. Dans de telles circonstances, la CA doit révoquer le certificat.

   X.509 définis une méthode de révocation de certificat. Cette méthode implique que chaque CA fournis périodiquement une structure de données appelée une liste de statut de révocation. Une CRL est une liste horodatée identifiant les certification révoqués. qui est signée par une CA ou un fournisseur de CA et est librement accessible dans de dépôt publique. Chaque certificat révoqué est identifié dans une CRL par son numéro de série. Quand un système utilisant les certificats utilise un certificat ( par exemple pour vérifier la signature numérique d'un utilisateur ), ce système ne vérifie pas seulement la signature et la validité du certificat mais récupère également une CRL utilisable et récente et vérifie que le numéro de série n'est pas dans cette CRL

   La signification de "utilisable et récente" peut varier avec la stratégie locale, mais signifie généralement la plus récente CRL fournis. Une nouvelle CRL est fournie sur une base régulière. Une entrée est ajoutée à la CRL comme partie de la prochaine mise à jours suivant la notification de la révocation. Une entrée ne doit pas être supprimée de la CRL jusqu'à ce qu'elle apparaisse dans une dans une CRL régulière fournie au-delà de la période de validité du certificat.

   Un avantage de cette méthode de révocation est que les CRL peuvent être distribués exactement de la même manière que les certificats eux-mêmes, via des serveurs et des communications non-sûres.

   Une limitation de la méthode de révocation CRL, utilisant des communications et des serveurs non sûrs, et que la granularité de temps de révocation est limitée à la période d'émission de la CRL. Par exemple, si une révocation est reportée maintenant, cette révocation ne sera pas notifiée tant qu'une nouvelle CRL n'est pas générée.

   Comme avec le format de certificat X.509 v3, pour pouvoir faciliter l'interopérabilité des implémentation, le format de CRL v2 X.509 doit être profilé pour l'utilisation sur l'Internet. C'est un des objectifs de ce document. Cependant, ce profile ne nécessite pas l'émission des CRL. Les formats de message et les protocoles supportant les notification de révocation on-line sont définis dans d'autres spécifications PKIX. Les méthodes on-line de notification de révocation peuvent être applicables dans certains environnements comme une alternative à la CRL X.509. La vérification de révocation On-line peut significativement réduire la latence entre une révocation et la distribution de l'information. Une fois que la CA acceptes une révocation comme authentique et valide, toute requête au service on-line va refléter correctement l'information de révocation.

   Cependant, ces méthodes imposent de nouveaux pré-requis de sécurité: le validateur de certificat a besoin de faire confiance au service de validation on-line, alors que le dépôt n'a pas besoin de l'être.

Protocoles opérationnels

Les protocoles opérationnels sont requis pour délivrer les certificats et les CRL ( ou les informations de statut ) aux système client qui utilisent les certificats. Des dispositions sont nécessaires pour divers moyens de délivrer des certificats et les CRL, incluant les procédures de distribution basées sur LDAP, HTTP, FTP, et X.500. Les protocoles opérationnels supportant ces fonctions sont définies dans d'autres spécification PKIX. Ces spécifications peuvent inclurent les définition de formats de message et des procédures pour supporter tous les environnements opérationnel, incluant les définitions et les référence aux types de contenu MIME appropriés.

Protocoles de gestion

   Les protocoles de gestion sont requis pour supporter les interactions on-line entre les utilisateurs de PKI et les entités de gestion. Par exemple, un protocole de gestion peut être utilisé entre une CA et un système client avec lequel une paire de clé est associée, ou entre 2 CA qui se cross-certifient entre-eux. Le jeu de fonctions qui nécessite potentiellement d'être supportés par les protocoles de gestion incluent:

(a) Enregistrement: c'est la procédure par laquelle un utilisateur se fait connaître à la CA ( directement, ou via un RA ), avec que la CA ne lui fournisse un ou plusieurs certificats.
(b) Initialisation: Avant qu'un système client puisse opérer de manière sécurisé, il est nécessaire d'installer les clés qui ont la relation appropriée avec les clés stockées ailleurs dans l'infrastructure. Par exemple, le client a besoin d'être initialisée de manière sécurisée avec la clé publique et d'autres informations des CA de confiance, pour être utilisées dans les validation de chemins de certification. De plus, un client a généralement besoin d'être initialisé avec ses propres paires de clés.
(c) Certification: C'est le processus dans lequel une CA fournie un certificat pour une clé publique de l'utilisateur, et retourne ce certificat au système client de l'utilisateur et/ou poste ce certificat dans un dépôt.
(d) Récupération de paire de clé: En option, les clés du client (ex: la clé privée de l'utilisateur ) peut être sauvegardée par une CA ou un système de sauvegarde de clé. Si un utilisateur a besoin de récupérer ces clés ( par exemple lors de la perte du mot de passe ou la perte de la clé ), un protocole d'échange on-line peut être nécessaire pour de telles récupérations.
(e) Mise à jours de paires de clé: toutes les paires de clé ont besoin d'être mises à jours régulièrement, par ex. remplacées avec une nouvelle paire de clé, et de nouveaux certificats fournis.
(f) Demandes de révocation: Une personne autorisée avertit une CA d'une situation anormale nécessitant la révocation d'un certificat.
(g) cross-certification: 2 CA échangent des informations utilisées pour établir une certification croisée. Un cross-certificat est un certificat fournis par une CA à une autre qui contient une clé de signature CA utilisée pour fournir des certificats.

   Noter que les protocoles on-line ne sont pas la seul manière d'implémenter les fonction ci-dessus. Pour toutes les fonctions, il y a des méthodes off-line pour accomplir de même résultat, et cette spécification ne mandate pas l'utilisation des protocoles on-line. Par exemple, quand des jetons hardware sont utilisés, beaucoup de fonctions peuvent être faites comme partie de la livraison du jeton physique. De plus, certaines fonctions ci-dessus peuvent être combinées dans un seul protocole d'échange. En particulier, les fonctions d'enregistrement, d'initialisation et de certification peuvent être combinés en un seul protocole d'échange.

   Les séries PKIX des spécifications définissent un jeu de formats de messages standard pour supporter les fonction ci-dessus. Les protocoles pour transporter ces messages dans différents environnement (ex: email, transfert de fichier, et www ) sont décris dans ces spécifications.

Profile de certificat et d'extensions de certificat

Cette section présente un profile pour les certificats à clé publique qui favorisent l'interopérabilité et une PKI ré-utilisable. Cette section est basée sur le format de certificat X.509 v3 et les extensions de certificats standards définis dans X.509. Les document ISO/IEC et ITU-T utilisent la version 1997 de ASN.1; alors que ce document utilise la syntaxe ASN.1 1988, le certificat et les extensions standard encodés sont équivalents. Cette section définis également des extensions privées nécessaires pour supporter une PKI pour la communauté Internet.

Les certificats peuvent être utilisés dans une grande variété d'applications et d'environnements couvrant un large spectre d'interopérabilité et de pré-requis opérationnel et d'assurance. Le but de ce document est d'établir une base commune pour des applications générique nécessitant une grande interopérabilité et des besoins spéciaux limités. En particulier, l'accent sera mis sur le support de l'utilisation des certificats X.509 v3 pour les messages électronique, IPSec, et les applications web.

Champs de certificat de base

La syntaxe de base des certificats X.509 v3 est comme suit. Pour le calcule de la signature, les données à signer sont encodés en utilisant DER. L'encodage DER ASN.1 est un système d'encodage de tag, longueur, et valeur pour chaque élément.
Certificate ::= SEQUENCE {
    tbsCertificate TBSCertificate,
    signatureAlgorithm AlgorithmIdentifier,
    signatureValue BIT STRING }

TBSCertificate ::= SEQUENCE {
    version [0] EXPLICIT Version DEFAULT v1,
    serialNumber CertificateSerialNumber,
    signature AlgorithmIdentifier,
    issuer Name,
    validity Validity,
    subject Name,
    subjectPublicKeyInfo SubjectPublicKeyInfo,
    issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL,
        -- Si présent, version doit être v2 ou v3.
    subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL,
        -- Si présent, version doit être v2 ou v3
    extensions [3] EXPLICIT Extensions OPTIONAL
        -- Si présent, version doit être v2 ou v3
}

    Version ::= INTEGER { v1(0), v2(1), v3(2) }

CertificateSerialNumber ::= INTEGER

Validity ::= SEQUENCE {
    notBefore Time,
    notAfter Time }

Time ::= CHOICE {
    utcTime UTCTime,
    generalTime GeneralizedTime }

UniqueIdentifier ::= BIT STRING

SubjectPublicKeyInfo ::= SEQUENCE {
    algorithm AlgorithmIdentifier,
    subjectPublicKey BIT STRING }

Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension

Extension ::= SEQUENCE {
    extnID OBJECT IDENTIFIER,
    critical BOOLEAN DEFAULT FALSE,
    extnValue OCTET STRING
         -- contient l'encodé DER d'une valeur ASN.1 correspondant au type d'extension identifié par extnID
}

Champs de certificat

   Certificate est une séquence de 3 champs requis. Les champs sont décris en détail dans les section suivantes.

tbsCertificate Le champ contient les noms du sujet et du fournisseur, une clé publique associée avec le sujet, une période de validité, et d'autres informations associées. Les champs sont décris plus bas. tbsCertificate inclue généralement des extensions, qui sont décris plus bas également.
signatureAlgorithm Le champ signatureAlgorithm contient l'identifiant pour l'algorithme cryptographique utilisé par la CA pour signer ce certificat. les rfc 3279, rfc 4055, et rfc 4491 listent les algorithmes de signature supportés, mais d'autres algorithmes peuvent être également supportés.

Un identifiant d'algorithme est définis par la structure ASN.1 suivante:
AlgorithmIdentifier ::= SEQUENCE {
    algorithm OBJECT IDENTIFIER,
    parameters ANY DEFINED BY algorithm OPTIONAL }

   L'identifiant d'algorithme est utilisé pour identifier un algorithme cryptographique. L'identifiant d'objet identifie l'algorithme (tel que DSA avec SHA-1). Le contenu des paramètres optionnels varient en fonction de l'algorithme identifié. Ce champ doit contenir le même identifiant d'algorithme que le champ signature dans la séquence tbsCertificate.

signatureValue Le champ signatureValue contient une signature numérique calculée sur l'encodé DER ASN.1 de tbsCertificate, qui est utilisé en entrée de l'algorithme de la fonction de signature. Cette valeur de signature est encodée en chaîne de bits et inclus dans le champ signature. Les détails de ce processus sont spécifiés pour chaque algorithme listés dans les rfc3279, rfc4055, et rfc4491.

   En générant cette signature, une CA certifie la validité de l'information dans le champ tbsCertificate. En particulier, la CA certifie la liaison entre la clé publique et le sujet du certificat.

TBSCertificate

La séquence TBSCertificate contient les informations associées avec le sujet du certificat et la CA qui l'a fournie. Tous TBSCertificate contient les noms du sujet et du fournisseur, une clé publique associée avec le sujet, une période de validité, un numéro de version, et un numéro de série; certains peuvent optionnellement contenir des champs d'identifiant unique. Le reste de cette section décris la syntaxe et les sémantiques de ces champs. Un TBSCertificate inclus généralement des extensions. Les extensions pour les PKI de l'Internet sont décris plus bas.

Version

Ce champ décris la version du certificat encodé. Quand les extensions sont utilisée, comme prévu dans ce profile, la version doit être 3 (valeur 2). Si aucune extension n'est présente, mais qu'un UniqueIdentifier est présent, la version devrait être 2 (valeur 1); cependant, la version peut être 3. Si seul les champs de base sont présents, la version devrait être 1 ( la valeur est omise du certificat); cependant, la version peut être 2 ou 3.

Les implémentations devraient être préparés à accepter n'importe quel numéro de version. Au minimum, les implémentations conformes doivent reconnaître la version 3. La génération de certificats version 2 n'est pas prévue pour les implémentations de ce profile.

Serial Number

   Le numéro de série doit être un entier positif assigné par la CA pour chaque certificat. Il doit être unique pour chaque certificat fournis par une CA donnée (ex: le nom du fournisseur et le numéro de série identifie un certificat de manière unique ). Les CA doivent forcer le serialNumber à être un entier non-négatif.

   Les numéros de série peuvent être prévus pour contenir des entiers long. Les utilisateurs de certificat doivent être capable de manipules des valeurs jusqu'à 20 octets. Les CA conformes ne doivent pas utiliser de valeur serialNumber supérieur à 20 octets.

   Note: les CA non-conforme peuvent fournir des certificats avec des numéro de série négatifs ou 0. Les utilisateurs de certificat devraient être préparés à manipuler de tels certificats.

Signature

Ce champ contient l'identifiant d'algorithme pour l'algorithme utilisé par la CA pour signer le certificat. Ce champ doit contenir le même identifiant d'algorithme que le champ signatureAlgorithm dans la séquence Certificate. Le contenu du champ optionnel parameters varie en fonction de l'algorithme.

Issuer

Le champ issuer identifie l'entité qui a signé et fournis le certificat. Le champ issuer doit contenir un dn non-vide. Le champ issuer est définis comme nom de type X.501. Le nom est définis par les structures ASN.1 suivantes:
Name ::= CHOICE { -- un seul possible --
    rdnSequence RDNSequence }

RDNSequence ::= SEQUENCE OF RelativeDistinguishedName

RelativeDistinguishedName ::=
    SET SIZE (1..MAX) OF AttributeTypeAndValue

AttributeTypeAndValue ::= SEQUENCE {
    type AttributeType,
    value AttributeValue }

AttributeType ::= OBJECT IDENTIFIER

AttributeValue ::= ANY -- DEFINED BY AttributeType

DirectoryString ::= CHOICE {
    teletexString TeletexString (SIZE (1..MAX)),
    printableString PrintableString (SIZE (1..MAX)),
    universalString UniversalString (SIZE (1..MAX)),
    utf8String UTF8String (SIZE (1..MAX)),
    bmpString BMPString (SIZE (1..MAX)) }

   Le nom décris un nom hiérarchique composé d'attributs, tel que le nom du pays, et les valeurs correspondantes, tel que US. Le type du composant AttributeValue est déterminé par le AttributeType; en général il sera un DirectoryString.

   Le type DirectoryString est définis comme choix de PrintableString, TeletexString, BMPString, UTF8String, et UniversalString. Les CA conformes à ce profile doivent utiliser l'encodage de DirectoryString soit PrintableString soit UTF8String, avec 2 exceptions. Quand les CA on précédemment fournis des certificats avec les champs issuer avec attributs encodés en utilisant TeletexString, BMPString, ou UniversalString, alors la CA peut continuer à utiliser ces encodages de DirectoryString pour préserver la compatibilité en arrière. Également, les nouvelles CA qui sont ajoutée à un domaine où des CA existantes fournissent des certificat avec les champs issuer avec des attribut utilisant TeletexString, BMPString, ou UniversalString peuvent encoder les attributs qu'ils partagent avec les CA existantes en utilisant les même encodages que les CA existantes.

   Comme mentionné plus haut, les dn sont composés d'attributs. Cette spécification ne restreint pas le jeu de type d'attribut qui peuvent apparaître dans le nom. Cependant, les implémentations conformes doivent être préparées à recevoir des certificats avec des noms de fournisseur contenant le jeu de type d'attributs définis ci-dessous. Cette spécification recommande le support pour des type d'attributs additionnels.

   Les jeux standard d'attributs ont été définis dans X.520. Les Implémentations de cette spécification doit être préparée à recevoir les types d'attribut standard suivant dans le noms de fournisseur et du sujet:

- country
- organization
- organizational unit
- distinguished name qualifier
- state or province name
- common name (ex: "Susan Housley")
- serial number

   En plus, les implémentations de cette spécification devraient être préparés à recevoir le type d'attributs standard suivant dans les noms de fournisseur et de sujet:

- locality
- title
- surname
- given name
- initials
- pseudonym
- generation qualifier (ex: "Jr.", "3rd", ou "IV")

   La syntaxe et les identifiant d'objets associés pour ces types d'attribut sont fournis dans les modules ASN.1 dans l'appendice A. En plus, les implémentations de cette spécification doivent être préparées à recevoir l'attribut domainComponent, comme définis dans la rfc4519. Le DNS founis un système de label de ressource hiérarchique. Cet attribut fournis un mécanisme pour les organisations qui souhaitent utiliser les DN en parallèle à leurs noms DNS. Ce n'est pas un remplacement pour le composant dNSName des extensions de nom alternative. Les implémentations ne sont pas obligés de convertir de tels noms en noms DNS. La syntaxe et OID associé pour cet type d'attribut sont fournis dans les modules ASN.1 dans l'appendice 1. Les règles pour l'encodage des noms de domaines internationalisés à utiliser avec le type d'attribut domainComponent sont spécifiés plus bas.

   Les utilisateurs de certificat doivent être préparés à traiter les champs issuer et subject pour effectuer un chaînage de nom pour la validation de chemin de certification. Le chaînage de noms est effectué en faisant correspondre le dn issuer dans un certificat avec le sujet dans un certificat CA. Les règles pour comparer les dn sont spécifiés plus loin dans ce document. Si les noms dans les champ issuer et subject dans un certificat correspond aux règles spécifiés plus bas, le certificat est auto-signé.

Validity

   La période de validité de certificat est un intervalle de temps durant lequel la CA garantie qu'elle va maintenir les informations sur le statut du certificat. Le champ est représenté comme séquence de 2 dates: la date à laquelle la période de validité commence (notBefore) et la date à laquelle la période de validité se termine (notAfter). Ces 2 dates peuvent être encodés en UTCTime ou GeneralizedTime.

   Les CA conformes à ce profile doivent toujours encoder les dates de validité de certificat jusqu'à l'année 2049 en UTCTime; les de date en 2050 ou ultérieur en GeneralizedTime. Les applications conformes doivent être capable de traiter les dates de validité qui sont encodés en UTCTime ou en GeneralizedTime.

   La période de validité pour un certificat est la période de temps depuis notBefore jusqu'à notAfter, inclus.

   Dans certaines situations, les périphériques donnent des certificats pour lesquels aucune date d'expiration correcte ne peut être assignée. Par exemple, un périphérique pourrait fournir un certificat qui lie son modèle et un numéro de série à sa clé publique; un tel certificat est prévu pour être utilisé pour toute la durée de vie du périphérique.

   Pour indiquer qu'un certificat n'a pas de date d'expiration, notAfter devrait être assigné à la valeur GeneralizedTime 99991231235959Z.

   Quand le fournisseur n'est pas capable de maintenir les informations de statut jusqu'à la date notAfter (incluant le cas où notAfter vaut 99991231235959Z), le fournisseur doit s'assurer qu'aucun chemin de certification valide n'existe pour le certificat après que la maintenance du statut d'information soit terminée. Cela peut être fait par l'expiration ou la révocation de tous les certificats CA contenant la clé publique utilisée pour vérifier la signature dans le certificat et d'arrêter d'utiliser la clé publique utilisée pour vérifier la signature dans le certificat.

UTCTime

Le type de temps universelle UTCTime, est un type ASN.1 standard prévu pour représenter les dates et le temps. UTCTime spécifie l'année via 2 chiffres et le temps est spécifié avec une précision d'une minute ou une seconde. UTCTime inclus soit Z (pour Zulu, ou Greenwich Mean Time) ou un temps différentiel.

Pour ce profile, les valeurs UTCTime doivent être exprimées en GMT ( Zulu ) et doivent inclurent les secondes ( YYMMDDHHMMSSZ ), même que le nombre de secondes est 0. Les systèmes conforme doivent interpréter le champ année comme suit:

- Si YY est supérieur ou égale à 50, l'année devrait être interprété comme 19YY.
- Si YY est inférieur à 50, l'année dervait être interprété comme 20YY.

GeneralizedTime

Le type de temps généralisé, GeneralizedTime, est un type ASN.1 standard pour des représentation à précision variable du temps. Optionnellement, le champ GeneralizedTime peut inclure une représentation du temps différentiel entre GMT et la local.

Pour ce profile, les valeurs GeneralizedTime doivent être exprimées en GMT (Zulu) et doivent inclure les secondes (YYYYMMDDHHMMSSZ), même si le nombre de secondes est 0. Les valeurs GeneralizedTime ne doivent pas inclure les fractions de secondes.

Subject

   Le champ subject identifie l'entité associée avec la clé publique stockée dans le champ de clé publique. Le nom du sujet peut être placé dans le champ subject et/ou dans l'extension SubjectAltName. Si le sujet est une CA (ex: l'extension de contraintes de base et présent et la valeur de cA est TRUE), alors le champ subject doit être renseigné avec un dn non-vide corrspondant au contenu du champs issuer dans tous les certificats émis par la CA. Si le sujet est un fournisseur de CRL (ex: l'extension utilisation de clé est présent et la valeur de cRLSign est TRUE), alors le champ subject doit être populé avec un dn non-vide correspondant au contenu du champ issuer dans toutes les CRL émise par le fournisseur de CRL. Si les informations de nommage du sujet sont présent seulement dans l'extension subjectAltName ( ex: une clé liée seulement à une adresses email ou une URI), alors le sujet doit être une séquence vide et l'extension subjectAltName doit être critique.

   Quand il est non-vide, le champ subject doit contenir un dn X.500. Le dn doit être unique pour chaque entité sujet certifié par une CA comme définie dans le champ issuer. Une CA peut fournir plus d'un certificat avec le même dn à la même entité sujet.

   Le champ subject est définis comme nom de type X.501. Les pré-requis d'implémentation pour ce champ sont ceux définis pour le champ issuer. Les implémentations de cette spécification doivent être préparés à recevoir des noms de sujet contenant les types d'attributs requis pour le champ issuer. Les implémentations de cette spécification devraient être préparés à recevoir des noms de sujet contenant les types d'attributs recommandés pour le champ issuer. La syntaxe et les identifiant d'objet associés pour ces types d'attributs sont fournis dans les modules ASN.1 en appendice 1.

   Les implémentations de cette spécification peuvent utiliser les règles de comparaison pour traiter les types d'attributs non-familier (ex: pour le chaînage de noms) dont les valeurs d'attributs utilisent une des options d'encodage de DirectoryString. Les comparaisons binaires devraient être utilisées quand les type d'attribut non-familiers incluent des valeurs d'attribut avec des options d'encodage autre que ceux trouvés dans DirectoryString. Cela permet aux implémentations de traiter les certificats avec des attributs non-familier dans le sujet.

   En encodant des valeurs d'attribut de type DirectoryString, les CA conformes doivent utiliser PrintableString ou UTF8String, avec les exceptions suivant:

(a) Quand le sujet du certificat est une CA, le champ subject doit être encodé de la même manière que s'il est encodé dans le champ issuer dans tous les certificat qu'elle fournis. Donc, si la CA encode les attributs dans les champs issuer des certificat qu'elle fournis en utilisant TeletexString, BMPString, ou UniversalString, alors le champ subject des certificats fournis par cette CA doit utiliser le même encodage.
(b) Quand le sujet du certificat est un fournisseur de CRL, le champ subject doit être encodé de la même manière qu'il est encodé dans le champ issuer dans toutes les CRL fournies par le fournisseur de CRL.
(c) TeletexString, BMPString, et UniversalString sont inclus pour la compatibilité en arrière, et ne devraient pas être utilisés pour les certificats pour les nouveaux sujets. Cependant, ces types peuvent être utilisés dans les certificats où le nom a été précédemment établit, incluant les cas dans lequel un nouveau certificat est fournis à un nouveau sujet où les attributs à encoder ont été précédemment établis dans les certificats fournis à d'autres sujets. Les certificats utilisateur devraient être préparés à recevoir les certificats avec ces types.

   Les implémentations anciennes existent où une adresse de messagerie électronique est embarquée dans le sujet comme emailAddress (rfc2985). La valeur d'attribut pour emailAddress est de type IA5String pour permettre l'inclusion du caractère '@' qui ne fait pas partie du jeu de caractère PrintableString. Les valeurs de l'attribut emailAddress sont sont pas sensibles à la casse.

   Les implémentations conformes générant de nouveaux certificat avec des adresse email doivent utiliser le rfc822Name dans l'extension de nom alternative du sujet pour décrire de telles identités. L'inclusion simultanée de l'attribut emailAddress dans le sujet pour supporter les anciennes implémentations est dépréciée, mais permise.

Subject Public Key Info

Ce champ est utilisé pour gérer la clé publique et identifier l'algorithme avec lequel la clé est utilisée (ex: RSA, DSA, ou DH). L'algorithme est identifié en utilisant la structure AlgorithmIdentifier. Les identifiant d'objet pour les algorithmes supportés et les méthodes pour l'encodage de la clé publique (clé publique et paramètres) sont spécifiés dans les rfc3279, rfc4055, et rfc4491.

Unique Identifiers

Ces champs doivent seulement apparaître si la version est 2 ou 3. Les identifiant uniques du sujet et du fournisseur sont présent dans le certificat pour gérer la possibilité de réutiliser les noms du sujet et/ou fournisseur dans le temps. Ce profile recommande que les noms ne soient pas réutilisés pour différentes entités et que les certificats Internet n'utilisent pas les identifiant uniques. Les CA conformes à ce profile ne doivent pas générer de certificats avec des identifiants uniques. Les applications conformes à ce profile doivent être capable de lire les certificats qui incluent des identifiants uniques, mais il n'y a pas de pré-requis de traitement associés avec les identifiant uniques.

Extensions

Ce champ doit seulement apparaître si la version est 3. Si présent, ce champ est une séquence d'une ou plusieurs extensions de certificat.

Extensions de certificat

   Les extension définies pour les certificats X.509 v3 fournissent une méthode pour associer des attributs additionnels avec les utilisateurs ou les clés publiques et pour gérer les relations entre les CA. Le format de certificat X.509 v3 permet également aux communautés de définir des extensions privées pour gérer l'unicité des informations de ces communautés. Chaque extension dans un certificat peut être soit critique soit non-critique. Un système utilisant les certificats doit rejeter le certificat s'il rencontre une extension critique qu'il ne reconnaît pas ou une extension critique qui contient des informations qu'il ne peut pas traiter. Une extension non-critique peut être ignorée si elle n'est pas reconnue, mais doit être traitée si elle est reconnue. Les section suivantes présentent les extensions recommandées utilisée avec les certificats Internet et les emplacements standards pour les informations.

   Les communautés peuvent choisir d'utiliser des extensions additionnels, cependant, la prudence doit être de mise en adoptant des extension critiques dans les certificats qui peuvent empêcher leur utilisation dans un contexte général.

   Chaque extension inclus un OID et une structure ASN.1. Quand une extension apparaît dans un certificat, l'OID apparaît comme champ extnID et l'a structure encodée DER ASN.1 est la valeur de la chaîne d'octets extnValue. Un certificat ne doit pas inclure plus d'une instance d'une extension particulière. Par exemple, un certificat peut contenir seulement une extension d'identifiant de clé d'autorité. Une extension inclus le booléen critical, avec une valeur par défaut à FALSE. Le texte pour chaque extension spécifie les valeurs acceptable pour le champ critical pour les CA conformes à ce profile.

   Les CA conformes doivent supporter les identifiant de clé, les contraintes de base, l'utilisation de clé, et les stratégie de certificat. Si les CA fournissent des certificats avec une séquence vide pour le champ sujet, la CA doit supporter l'extension de noms alternatifs du sujet. Le support pour les extensions restantes est optionnel. Les CA conformes peuvent supporter les extension qui ne sont pas identifiés dans cette spécification; les fournisseurs de certificats sont prévenus que marquer de telles extensions comme critique peut inhiber l'interopérabilité.

   Au minimum, les applications conformes à ce profile doivent reconnaître les extensions suivantes: utilisation de clé, stratégie de certificat, contraintes de base, contraintes de nom, contraintes de stratégie, utilisation de clé étendue, et inhibit anyPolicy. En plus, les applications conformes à ce profile devraient reconnaître les extensions d'identifiant de clé du sujet et de l'autorité, et les mappages de stratégie.

Extensions standard

Cette section identifie les extensions de certificat standard définis dans X.509 pour l'utilisation dans les PKI de l'Internet. Chaque extension est associée avec un OID définis dans X.509. Ces OID sont membres de id-ce arc, qui est définis:
id-ce OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) ds(5) 29 }

Authority Key Identifier

   L'extension d'identifiant de clé de l'autorité fournis un moyen d'identifier la clé publique correspondant à la clé privée utilisée pour signer un certificat. Cette extension est utilisée où un fournisseur a plusieurs clé de signature (soit dû à plusieurs paires de clé concurrentes, soit à cause d'un changement de clé). L'identification peut être basée sur l'identifiant de clé ( le subject key identifier dans le certificat du fournisseur ) ou le nom du fournisseur et un numéro de série.

   Le champ keyIdentifier de l'extension authorityKeyIdentifier doit être inclus dans tous les certificats générés par les CA conformes pour faciliter la construction de chemin de certification. Il y a une exception: là où une CA distribue sa clé publique sous la forme d'un certificat auto-signé, l'identifiant de clé d'autorité peut être omise. La signature d'un certificat auto-signé est générée avec la clé privée associée avec la clé publique du sujet du certificat. Dans ce cas, le sujet et les identifiants de clé d'autorité seraient identiques, mais seul l'identifiant de clé du sujet est nécessaire pour construire le chemin de validation.

   La valeur du champ keyIdentifier devrait être dérivé de la clé publique utilisée pour vérifier la signature du certificat ou une méthode qui génère des valeurs uniques. 2 méthodes communes pour générer des identifiant de clé depuis une clé publique sont décris dans la section suivante. Là où un identifiant de clé n'a pas été précédemment établis, cette spécification recommande l'utilisation d'une de ces méthodes pour générer les keyIdentifiers ou l'utilisation de méthodes similaires qui utilisent un algorithme de hashage différent. Là où un identifiant de clé a été précédemment établis, la CA devrait utiliser l'identifiant établis précédemment.

Ce profile recommande le support pour la méthode d'identifiant de clé par tous les utilisateurs de certificat. Les CA conformes doivent marquer cette extension comme non-critique.
id-ce-authorityKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 35 }

AuthorityKeyIdentifier ::= SEQUENCE {
    keyIdentifier [0] KeyIdentifier OPTIONAL,
    authorityCertIssuer [1] GeneralNames OPTIONAL,
    authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL }

KeyIdentifier ::= OCTET STRING

Subject Key Identifier

   L'extension d'identifiant de clé du sujet fournis un moyen d'identifier les certificats qui contiennent une clé publique particulière.

   Pour simplifier la construction de chemin de certification, cette extension doit apparaître dans tous certificats CA conformes, c'est à dire, tous les certificats incluant l'extension de contraintes de base où la valeur de cA est TRUE. Dans les certificats de CA conformes, la valeur de l'identifiant de clé du sujet doit être la valeur placée dans le champ d'identifiant de clé de l'extension de clé d'autorité des certificats fournis par le sujet de ce certificat. Les applications ne sont pas obligées de vérifier que les identifiants de clé correspondent en validant le chemin de certification.

   Pour les certificats de CA, les identifiants de clé du sujet devraient être dérivés de la clé publique ou une méthode qui génère des valeurs uniques. 2 méthodes communes pour générer des identifiant de clé depuis la clé publique sont:

(1) keyIdentifier est composé d'un hash SHA-1 160-bits de la valeur de la chaîne de bits subjectPublicKey (excluant le tag, longueur et le nombre de bits non-utilisé).
(2) keyIdentifier est composé d'un champ de type 4-bits avec la valeur 0100, suivis par au moins 60bits de hash SHA-1 de la valeur de la chaîne de bits subjectPublicKey (excluant le tag, longueur et le nombre de bits non-utilisé).

   D'autres méthodes pour générer des nombres uniques sont également acceptables.

   Pour un certificat d'entité finale, l'extension d'identifiant de clé du sujet fournis un moyen d'identifier les certificats contenant la clé publique particulière utilisée dans une application. Quand une entité finale a obtenu plusieurs certificats, spécialement depuis plusieurs CA, l'identifiant de clé du sujet fournis un moyen de rapidement identifier le jeu de certificats contenant une clé publique particulière. Pour assister les applications à identifier le bon certificat, cette extension devrait être incluse dans tous les certificats d'entité finale.

   Pour les certificats d'entité finale, les identifiants de clé du sujet devraient être dérivés de la clé publique. 2 méthodes communes pour générer des identifiants de clé depuis la clé publique sont identifiés ci-dessus.

   Quand un identifiant de clé n'a pas été établis précédemment, cette spécification recommande l'utilisation d'une de ces méthodes pour générer les keyIdentifiers ou utiliser une méthodes similaire qui utilise un algorithme de hash différent. Quand un identifiant de clé a été précédemment établis, la CA devrait utilise cet identifiant.

Les CA conformes doivent marquer cette extension comme non-critique.
id-ce-subjectKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 14 }

SubjectKeyIdentifier ::= KeyIdentifier

Key Usage

   L'extension d'utilisation de clé définis le but (ex: le chiffrement, la signature, signature de certificat) de la clé contenue dans le certificat. La restriction d'utilisation peut être employée quand une clé qui pourrait être utilisée pour plus d'une opération doit être restreindre. Par exemple, quand une clé RSA devrait être utilisée seulement pour vérifier les signatures sur des objets autre que des certificats à clé publique et les CRL, les bits digitalSignature et/ou nonRepudiation devraient être mis. De même, quand une clé RSA devrait être utilisée seulement pour la gestion de clé, le bit keyEncipherment devrait être mis.

   Les CA conformes doivent inclure cette extension dans les certificats qui contiennent des clés publiques qui sont utilisée pour valider les signatures numériques dans d'autre certificats à clé publique ou des CRL. Quand il est présent, les CA conformes devraient marquer cette extension comme critique.

id-ce-keyUsage OBJECT IDENTIFIER ::= { id-ce 15 }

KeyUsage ::= BIT STRING {
    digitalSignature (0),
    nonRepudiation (1), -- Les éditions récentes de X.509 ont renommé ce bis en contentCommitment
    keyEncipherment (2),
    dataEncipherment (3),
    keyAgreement (4),
    keyCertSign (5),
    cRLSign (6),
    encipherOnly (7),
    decipherOnly (8) }

digitalSignature est mis quand la clé publique du sujet est utilisée pour vérifier les signatures numériques, autre que les signature des certificats et des CRL, telles que celles utilisées dans les services d'authentification d'entité, services d'authentification de l'origine des données, et/ou services d'intégrité.
nonRepudiation est mis quand la clé publique du sujet est utilisée pour vérifier les signatures numérique, autre que les signatures des certificats et des CRL, utilisé pour fournir un service de non-répudiation qui protège contre l'entité signataire niant à tord certaines actions. Dans le cas de conflits ultérieurs, un tiers de confiance peut déterminer l'authenticité des données signées.
keyEncipherment est mis quand la clé publique du sujet est utilisée pour chiffrer des clés secrètes ou privée, par exemple, pour le transport de clé. Par exemple, ce bit devrait être mis quand une clé publique RSA est utilisée pour chiffrer une clé de déchiffrement de contenu symétrique ou une clé privée asymétrique.
dataEncipherment est mis quand la clé publique du sujet est utilisée pour chiffrer directement les donnée brutes de l'utilisateur sans l'utilisation de clé symétrique intermédiaire. Noter que l'utilisation de ce bit est extrêmement peu commun; la plupart des applications utilisent le transport de clé pour l'agrément de clé pour établir une clé symétrique.
keyAgreement est mis quand la clé publique est utilisée pour la gestion de clé. Par exemple, quand une clé Diffie-Hellman est utilisée pour la gestion de clé, alors ce bit est mis.
keyCertSign Est mis quand la clé publique est utilisée pour vérifier les signatures des certificats à clé publique. Si keyCertSign est mis, alors le bit cA dans l'extension de contrainte de base doit également être mis.
cRLSign est mis quand la clé publique est utilisée pour vérifier les signatures dans les listes de révocation de certificat.
encipherOnly la signification de ce bit est indéfinis en l'absence du bit keyAgreement. Quand ces 2 bits sont mis, la clé publique du sujet peut être utilisée seulement pour chiffrer les données en effectuant un agrément de clé.
decipherOnly la signification de ce bit est indéfinis en l'absence du bit keyAgreement. Quand ces 2 bits sont mis, la clé publique du sujet peut être utilisée seulement pour déchiffrer les données en effectuant un agrément de clé.

   Si l'extension keyUsage est présent, alors la clé publique du sujet ne doit pas être utilisée pour vérifier les signatures dans le certificats ou les CRL à moins que les bits correspondants ne soient mis. Si la clé publique du sujet est seulement utilisée pour vérifier les signatures dans les certificats et/ou les CRL, alors les bits digitalSignature et nonRepudiation ne devraient pas être mis. Cependant, digitalSignature et/ou nonRepudiation peuvent être mis en plus de keyCertSign et/ou cRLSign si la clé publique du sujet est utilisée pour vérifier les signatures dans les certificats et/ou les CRL et également dans d'autres objets.

   Combiner le bit nonRepudiation dans l'extension de certificat keyUsage avec d'autres bits d'utilisation de clé peut avoir des implications de sécurité en fonction du contexte dans lequel le certificat est utilisé. D'autres distinction entre digitalSignature et nonRepudiation peuvent être fournis dans des stratégies de certificat spécifiques.

   Ce profil ne restreins pas les combinaisons de bits qui peuvent être mis dans une extension keyUsage. Cependant, des valeurs appropriées pour keyUsage pour des algorithmes particuliers sont spécifiés dans les rfc3279, rfc4055, et rfc4491. Quand l'extension keyUsage apparaît dans un certificat, au moins un bit doit être mis.

Certificate Policies

   L'extension de stratégie de certificat contient une séquence d'un ou plusieurs termes d'informations de stratégie, chacun consistant d'un identifiant d'objet et d'un qualifiant optionnel. Les qualifiants optionnel, qui peuvent être présents, ne sont pas prévus pour changer la définition de la stratégie. Un OID de stratégie de certificat ne doit pas apparaître plus d'une fois dans une extension de stratégie de certificat.

   Dans un certificat d'entité finale, ces informations de stratégie indique la stratégie sous laquelle le certificat a été émis et le but pour lequel le certificat peut être utilisé. Dans un certificat CA, ces stratégies limitent le jeu de stratégie pour les chemins de certification qui incluent ce certificat. Quand une CA ne souhaite pas limiter le jeu de stratégies pour les chemins de certification qui incluent ce certificat, elle peut indiquer une stratégie spéciale anyPolicy, qui a la valeur { 2 5 29 32 0 }.

   Les applications avec des besoins de stratégie spécifiques sont censés avoir une liste de ces stratégies qu'elles vont accepter et pour comparer les OID de stratégie dans le certificat à cette liste. Si cette extension est critique, le logiciel de validation de chemin doit être capable d'interpréter cette extension (incluant le qualifiant optionnel), ou doivent rejeter le certificat.

   Pour promouvoir l'interopérabilité, ce profile recommande que les termes d'informations de stratégie consistent de seulement un OID. Quand un OID seul n'est pas suffisant, ce profile recommande fortement que l'utilisation des qualifiants soient limités à ceux identifiés dans cette section. Quand les qualifiants sont utilisé avec le stratégie spéciale anyPolicy, ils doivent être limités aux qualifiants identifés dans cette section. Seul ces qualifiants retournés en résultat de la validation de chemin sont considérés.

   Cette spécification définis 2 types de qualifiants de stratégie à utiliser avec les concepteurs de stratégie de certificat. Les types de qualifiants sont le CPS Pointer et User Notice.

   Le CPS Pointer contient un pointer vers un Certification Practice Statement ( CPS ) publié par la CA. Le pointeur est sous la forme d'un URI. Les pré-requis de traitement pour ce qualifiant sont définis localement. Aucune action n'est mandatée par cette spécification sans regarder la criticité de cette extension.

   User notice est prévu pour afficher un tier de confiance quand un certificat est utilisé. Seuls les consignes utilisateurs retournés en résultat de la validation de chemin sont prévus pour l'affichage à l'utilisateur. Si une consigne est dupliqué, seul une copie est affichée. Pour empêcher une telle duplication, ce qualifiant devrait seulement être présent dans les certificats d'entité finaux et les certificats de CA fournis à d'autres organisations.

   La consigne utilisateur a 2 champs optionnels: noticeRef et explicitText. Les CA conformes ne devraient pas utiliser l'option noticeRef.

   Le champ noticeRef, si utilisé, nomme une organisation et identifie, par un nombre, une déclaration textuelle particulière préparée par cette organisation. Par exemple, il peut identifier l'organisation "CertsRUs" et un numéro de consigne 1. Dans une implémentation typique, l'application aura un fichier de consigne contenant le jeu de textes dans un fichier et l'affichera. Les messages peuvent être multi-langue.

   Le champ explicitText inclus la déclaration textuel directement dans le certificat. Ce champ est une chaîne avec un maximum de 200 caractères. Les CA conformes devraient utiliser l'encodage UTF8String, mais peuvent utiliser IA5String. Les CA conformes ne doivent pas encoder explicitText en VisibleString ou BMPString. La chaîne explicitText ne devrait pas inclure de caractères de contrôle. Encodé en UTF8String, toutes les séquences de caractère devraient être normalisés en accord avec Unicode Normalization form C (NFC).

   Si les 2 options sont inclues dans un qualifiant et si l'application peut localiser le texte indiqué par noticeRef, alors ce texte devrait être affiché; sinon, la chaîne explicitText devrait être affichée.

   Note: bien que explicitText a une taille maximum de 200 caractères, certaines CA non-conformes dépassent cette limite. Cependant, les utilisateurs de certificat devrait gérer ce champ avec plus de 200 caractères.

id-ce-certificatePolicies OBJECT IDENTIFIER ::= { id-ce 32 }

    anyPolicy OBJECT IDENTIFIER ::= { id-ce-certificatePolicies 0 }

    certificatePolicies ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation

    PolicyInformation ::= SEQUENCE {
        policyIdentifier CertPolicyId,
        policyQualifiers SEQUENCE SIZE (1..MAX) OF
         PolicyQualifierInfo OPTIONAL }

    CertPolicyId ::= OBJECT IDENTIFIER

    PolicyQualifierInfo ::= SEQUENCE {
        policyQualifierId PolicyQualifierId,
        qualifier ANY DEFINED BY policyQualifierId }

    -- policyQualifierIds for Internet policy qualifiers

    id-qt OBJECT IDENTIFIER ::= { id-pkix 2 }
    id-qt-cps OBJECT IDENTIFIER ::= { id-qt 1 }
    id-qt-unotice OBJECT IDENTIFIER ::= { id-qt 2 }

    PolicyQualifierId ::= OBJECT IDENTIFIER ( id-qt-cps | id-qt-unotice )

    Qualifier ::= CHOICE {
        cPSuri CPSuri,
        userNotice UserNotice }

    CPSuri ::= IA5String

    UserNotice ::= SEQUENCE {
        noticeRef NoticeReference OPTIONAL,
        explicitText DisplayText OPTIONAL }

    NoticeReference ::= SEQUENCE {
        organization DisplayText,
        noticeNumbers SEQUENCE OF INTEGER }

    DisplayText ::= CHOICE {
        ia5String IA5String (SIZE (1..200)),
        visibleString VisibleString (SIZE (1..200)),
        bmpString BMPString (SIZE (1..200)),
        utf8String UTF8String (SIZE (1..200)) }

Policy Mappings

   Cette extension est utilisée dans les certificats CA. Elle liste une ou plusieurs paires d'OID; chacune incluant un issuerDomainPolicy et un subjectDomainPolicy. Le jumelage indique que la CA émettrice considère son issuerDomainPolicy équivalent au subjectDomainPolicy de la CA.

   Les utilisateurs de la CA émettrice peuvent accepter un issuerDomainPolicy pour certaines applications. Le mappage de stratégie définie la liste des stratégies associées avec le sujet CA qui peuvent être acceptés comme comparable à issuerDomainPolicy.

   Chaque issuerDomainPolicy nommé dans l'extension de mappage de stratégies devrait également être mis dans une extension de stratégie de certificat dans le même certificat. Les stratégies ne doivent pas être mappés soit pour ou depuis la valeur spéciale anyPolicy.

   En général, les stratégies de certificat qui apparaissent dans le champ issuerDomainPolicy de l'extension de mappage de stratégie ne sont pas considérées comme stratégie acceptable pour l'inclusion dans le certificats sous-jacents dans le chemin de certification. Dans certaines circonstances, une CA peut souhaiter mapper une stratégie (p1) à une autre (p2), mais veut que le issuerDomainPolicy (p1) soit considéré comme acceptable pour l'ajout dans les certificat sous-jacents. Cela peut se produire, par exemple, si la CA est dans le processus de transition d'e l'utilisation de la stratégie p1 vers l'utilisation de la stratégie p2 et a des certificats valides qui ont été émis sous chaque stratégie. Une CA peut indiquer cela en incluant 2 mappage de stratégie dans les certificats CA qu'elle fournis. Chaque mappage de stratégie aura un issuerDomainPolicy de p1; un mappage de stratégie aura subjectDomainPolicy de p1 et l'autre aura le subjectDomainPolicy de p2.

Cette extension peut être supportée par les CA et/ou les applications. Les CA conformes devraient marquer cette extension comme critique.
id-ce-policyMappings OBJECT IDENTIFIER ::= { id-ce 33 }

PolicyMappings ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE {
    issuerDomainPolicy CertPolicyId,
    subjectDomainPolicy CertPolicyId }

Subject Alternative Name

   L'extension subject alternative name permet aux identités d'être liées au sujet du certificat. Ces identités peuvent être inclues en plus ou à la place e l'identité dans le champ subject du certificat. Les options définies incluent une adresse de messagerie électronique, un nom DNS, une adresse IP, et une URI. D'autres options existent, incluant les définitions complètement locales. Plusieurs formes de nom, et plusieurs instances de chaque forme de nom peuvent être inclus. Quand de telles identités sont liées dans un certificat, l'extension subject alternative name (ou issuer alternative name) doit être utilisée; cependant, un nom DNS peut également être représenté dans le champ subject en utilisant l'attribut domainComponent. Noter que quand de tels noms sont représentés dans le champ subject, les implémentation ne sont pas obligées de les convertir en noms DNS.

   Puisque le nom alternatif du sujet est considéré comme lié définitivement à la clé publique, toutes les parties doivent être vérifiés par la CA.

   De plus, si la seul identité du sujet inclue dans le certificat est une forme de nom alternative, alors le nom distinct du sujet doit être vide, et l'extension subjectAltName doit être présent. Si le champ subject contient une séquence vide, alors la CA émettrice doit inclure une extension subjectAltName marquée comme critique. En incluant l'extension subjectAltName dans un certificat qui a un sujet non-vide, les CA conformes devraient marque l'extension subjectAltName comme non-critique.

   Quand l'extension subjectAltName contient une adresse email, cette adresse doit être stockée dans le rfc822Name. Le format d'un rfc822Name est un Mailbox comme définis dans la rfc 2821. Une Mailbox a la forme "local-part@Domain". Noter qu'une Mailbox n'a pas de phrase (cet un nom commun) avant lui, et n'est pas entouré de "‹" et "›". Les règles d'encodage des adresses email qui incluent des noms de domaines internationalisés sont spécifiés plus bas.

   Quand l'extension subjectAltName contient une iPAdress, l'adresse doit être stockée dans la chaîne d'octets dans "network byte order", comme spécifié dans la rfc791. Le LSB de chaque octet est le LSB de l'octet correspondant dans l'adresse réseau. Pour les IPv4, comme spécifié dans la rfc791, la chaîne d'octets doit contenir exactement 4 octets. Pour la version IPv6, comme spécifié dans la rfc2460, la chaîne d'octets doit contenir exactement 16 octets.

   Quand l'extension subjectAltName contient un nom de domaine, le nom de domaine doit être stocké dans le dNSName ( un IA5String ). Le nom doit être en "preferred name syntax", comme spécifié dans la rfc1034 et modifié dans la rfc1123. Noter que bien que les lettres majuscules et minuscules sont permises dans les noms de domaines, la casse n'est pas prise en compte. En plus, alors que la chaîne " " est un nom de domaine légal, les extensions subjectAltName avec un dNSName de " " ne doivent pas être utilisé. Finalement, l'utilisation de la représentation DNS pour les adresses mail ne doivent pas être utilisées, de telles identités sont encodées en rfc822Name. Les règles pour l'encodage des noms de domaine internationalisés sont spécifiés plus bas.

   Quand l'extension subjectAltName contient une URI, le nom doit être stocké dans un uniformResourceIdentifier (un IA5String). Le nom ne doit pas être une URI relative, et doit suivre la syntaxe URI et les règles d'encodage spécifiés dans la rfc3986. Le nom doit inclure à la fois un schéma (ex: http ou ftp) et une partie spécifique au schéma. Les URI qui incluent une autorité doivent inclure un nom pleinement qualifié ou une adresse IP comme hôte. Les règles pour l'encodage des Internationalized Resource Identifiers (IRI) sont spécifiées plus bas.

   Comme spécifié dans la rfc3986, le schema n'est pas sensible à la casse ( ex: http est équivalent à HTTP ). La partie hôte, si présent, est également insensible à la casse, mais les autres composant de la partie spécifique au schéma peut être sensible à la casse. Les règles pour comparer les URI sont spécifiées plus bas.

   Quand l'extension subjectAltName contient un DN dans le directoryName, les règles d'encodage sont les mêmes qui ceux spécifiés pour le champ issuer. Le DN doit être unique pour chaque entité sujet certifiée par une CA comme définie par le champ issuer. Une CA peut émettre plus d'un certificat vec le même DN au même sujet.

   Le subjectAltName peut gérer des types de noms additionnel via l'utilisation du champ otherName. Le format et les sémantiques de nom sont indiqués via l'identifiant d'objet dans le champ type-id. Le nom lui-même est acheminé comme valeur de champ dans otherName. Par exemple un OID de nom principal Kerberos peut être encodé comme séquence du Realm et du PrincipalName.

   Les noms alternatifs du sujet peuvent être contraints de la même manière que les noms distinct du sujet en utilisant une extension de contrainte de nom.

   Si l'extension subjectAltName est présent, la séquence doit contenir au moins une entrée. À la différence du champ subject, les CA conformes ne doivent pas fournir de certificats avec un subjectAltName contenant des champs GeneralName vides. Par exemple, un rfc822Name est représenté en IA5String. Alors qu'une chaîne vide est un IA5String valide, un tel rfc822Name n'est pas permis par ce profile. Le comportement des client qui rencontrent un tel certificat en traitant un chemin de certification n'est pas définis par ce profile.

   Finalement, les sémantiques des noms alternatifs du sujet qui incluent des caractères wilcards ne sont pas adressés par cette spécification. Les applications avec des requis spécifiques peuvent utiliser de tels noms, mais elles doivent définir les sémantiques.

id-ce-subjectAltName OBJECT IDENTIFIER ::= { id-ce 17 }

SubjectAltName ::= GeneralNames

GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName

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 }

OtherName ::= SEQUENCE {
    type-id OBJECT IDENTIFIER,
    value [0] EXPLICIT ANY DEFINED BY type-id }

EDIPartyName ::= SEQUENCE {
    nameAssigner [0] DirectoryString OPTIONAL,
    partyName [1] DirectoryString }

Issuer Alternative Name

Comme pour la section précédente, cette extension est utilisée pour associer des identité de style Internet avec des fournisseurs de certificats. Le nom alternatif du fournisseur doit être encodé comme dans la section précédente. Les noms alternatifs du fournisseur ne sont pas traités comme partie de l'algorithme de validation de chemin de certification. ( ils ne sont pas utilisé dans le chaînage et les contraintes de noms ne sont pas forcées ). Quand présent, les CA conformes devraient marquer cette extension non-critique.
id-ce-issuerAltName OBJECT IDENTIFIER ::= { id-ce 18 }

IssuerAltName ::= GeneralNames

Subject Directory Attributes

L'extension d'attributs d'annuaires du sujet est utilisée pour transmettre des attributs d'identification (ex: nationalité) du sujet. L'extension est définie comme une séquence d'un ou plusieurs attributs. Les CA conformes doivent marquer cette extension comme non-critique.
id-ce-subjectDirectoryAttributes OBJECT IDENTIFIER ::= { id-ce 9 }

SubjectDirectoryAttributes ::= SEQUENCE SIZE (1..MAX) OF Attribute

Basic Constraints

   L'extension de contraintes de base identifie si le sujet du certificat est une CA et la profondeur maximale des chemins de certification valides qui incluent ce certificat.

   Le booléen cA indique si la clé publique certifiée peut être utilisée pour vérifier le signatures de certificat. Si le booléen cA n'est pas présent, alors le bit keyCertSign de l'extension d'utilisation de clé ne doit pas être présent. Si l'extension de contraintes de base n'est pas présent dans un certificat v3, ou l'extension est présent mais le booléen cA n'est pas mis, alors la clé publique certifiée ne doit pas être utilisée pour vérifier les signatures de certificat.

   Le champ pathLenConstraint a une signification seulement si cA est mis et l'extension d'utilisation de clé, si présent, à le bit keyCertSign mis. Dans ce cas, il donne le nombre maximum de certificats intermédiaires non auto-fournis qui peuvent suivre ce certificat dans le chemin de certification. ( Note: le dernier certificat dans le chemin de certification n'est pas un certificat intermédiaire, et n'est pas inclus dans cette limite. Généralement, le dernier certificat est un certificat d'entité finale, mais peut être un certificat de CA). Un pathLenConstraint de 0 indique qu'aucun certificat de CA intermédiaire non auto-fournis ne peut suivre dans un chemin de certification valide. Quand il apparaît, le champ pathLenConstraint doit être supérieur ou égal à 0. Quand pathLenConstraint n'apparaît pas, aucune limite n'est imposée.

   Les CA conformes doivent inclure cette extension dans tous les certificats CA qui contiennent une clé publique utilisée pour valider les signatures numérique dans les certificat et doivent marquer cette extension comme critique. Cette extension peut apparaître comme critique ou non dans les certificats CA qui contiennent des clés publiques utilisée exclusivement pour d'autres but que la validation des signatures numérique dans les certificats. De tels certificats de CA incluent ceux qui contiennent des clé publique utilisées exclusivement pour valider les signatures numérique dans les CRL et ceux qui contiennent des clés publique de gestion de clé utilisées avec les protocoles d'inscription de certificat.

Les CA ne doivent pas inclure le champ pathLenConstraint sauf si le booléen cA est mis et que l'extension d'utilisation ed clé a le bit keyCertSign mis.
id-ce-basicConstraints OBJECT IDENTIFIER ::= { id-ce 19 }

BasicConstraints ::= SEQUENCE {
    cA BOOLEAN DEFAULT FALSE,
    pathLenConstraint INTEGER (0..MAX) OPTIONAL }

Name Constraints

   L'extension de contrainte de noms, qui doit être utilisé seulement dans un certificat de CA, indique un espace de noms dans lequel tous les noms de sujet dans les certificats sous-jacent dans un chemin de certification doivent être localisés. Les restrictions d'appliquent aux dn du sujet et aux noms alternatifs du sujet. Les restrictions s'appliquent seulement quand la forme de nom spécifié est présente. Si aucun nom du type n'est dans le certificat, le certificat est acceptable.

   Les contraintes de nom ne sont pas appliquées aux certificats auto-fournis ( à moins que le certificat est un certificat final dans le chemin ). ( Cela peut empêcher les CA qui utilisent les contraintes de noms d'employer des certificats auto-fournis pour implémenter du remplacement de clé).

   Les restrictions sont définies en termes de subtrees de noms permis ou exclus. Tout nom correspondant à une restriction dans le champ excludedSubtrees est invalide sans regarder les informations apparaîssant dans permittedSubtrees. les CA conformes doivent marquer cette extension comme critique et ne devraient pas imposer de contraintes de nom sur les formes de noms x400Address, ediPartyName, ou registeredID. Les CA conformes ne doivent pas fournir de certificats où les contraintes de nom est une séquence vide, le champ permittedSubtrees ou excludedSubtrees doit être présent.

   Les applications conformes à ce profile doivent être capable de traiter les contraintes de noms qui sont imposées dans le forme de nom directoryName et devraient être capable de traiter les contraintes de nom qui sont imposées dans les formes de nom rfc822Name, uniformResourceIdentifier, dNSName, et iPAddress. Si une extension de contraintes de nom qui est marqué critique impose des contraintes sur une forme de nom particulier, et une instance de cette forme de nom apparaît dans le champ subject ou dans l'extension subjectAltName. d'un certificat sous-jacent, alors l'application doit traiter la contrainte ou rejeter le certificat.

   Dans ce profile, les champs minimum et maximum ne sont pas utilisé pour les formes de nom, donc, le minimum doit être 0, et maximum doit être absent. Cependant, si une application rencontre une extension de contraintes de noms critique qui spécifie d'autres valeurs pour minimum et maximum pour une forme de nom qui apparaît dans un certificat sous-jacent, l'application doit traiter ces champs ou rejeter le certificat.

   Pour les URI, la contrainte s'applique à la partie hôte du nom. La contrainte doit être spécifiée en fqdn et peut spécifier un hôte ou un domaine. Quand la contrainte commance avec un point, elle peut être étendue avec un ou plusieurs labels. Par exemple, ".example.com" est satisfait par host.example.com, et my.host.example.com. Cependant, la contrainte .example.con n'est pas satisfait par example.com. Quand la contrainte ne commence pas avec un point, elle spécifie un hôte. Si une contrainte est appliquée à une forme de nom URI et qu'un certificat sous-jacent inclue une extension subjectAltName avec une URI qui n'inclue pas un composant d'autorité avec un nom d'hôte spécifié en fqdn, alors l'application doit rejeter le certificat.

   Une contrainte de nom pour les adresses email de l'Internet peut spécifier une boîte mail particulière, toutes les adresses dans un hôte particulier, ou toutes les boîtes mail dans un domaine. Pour indiquer une boîte mail particulière, la contrainte est l'adresse mail complète. Pour indiquer toutes les adresses mail dans un hôte particulier, la contrainte est spécifiée comme nom d'hôte. Pour spécifier toutes les adresse mail dans un domaine, la contrainte est spécifiée avec un point, comme avec une URI ( .example.com indique toutes les adresse mail du domaine example.com, mail pas les adresses internet de l'hôte example.com ).

   Les restrictions des noms DNS sont exprimées en host.example.com. Tous nom DNS qui peut être construit en ajoutant simplement 0 ou plusieurs labels à la partie gauche du nom satisfont la contrainte de nom. Par exemple, www.host.example.com satisfait la contrainte mais pas host1.example.com.

   Les anciennes implémentations existent où une adresse mail est embarquée dans le sujet dans une attribut de type emailAddress. Quand les contraintes sont imposée sur la forme de nom rfc822Name, mais que le certificat n'inclut pas une extension subjecAltName, la contrainte rfc822Name doit être appliquée à l'attribut de type emailAdress dans le sujet. La syntaxe ASN.1 pour emailAddress et l'OID correspondant sont fournis en appendix A.

   Les restrictions de la forme directoryName doivent être appliqués au champ subject dans le certificat ( quand le certificat inclus un champ de sujet non-vide ). et à tous noms de type directoryName dans l'extension subjectAltName. Les restrictions de la form x400Address doivent être appliquées à tous les noms de type x400Address dans l'extension subjectAltName.

   La syntaxe de iPAddress doit être comme décris précédemment avec les ajouts suivant spécifiquement pour les contraintes de noms. Pour les adresses IPv4, le champ IPv4 de GeneralName doit contenir 8 cotets, encodés dans le style rfc4632 (CIDR) opur représenter une plage d'adresses. Pour les adresses IPv6, le champ iPAddress doit contenir 32 octets encodés similairement. Par exemple, une contrainte de nom un sous-réseaux de classe C 192.0.2.0 est représenté pas les octets C0 00 02 00 FF FF FF 00, représentant la notation CIDR 192.0.2.0/24.

   Des règles additionnelles pour l'encodage et le traitement des contraintes de noms sont spécifiées plus bas. La syntaxe et les sémantiques pour les contraintes de noms pour otherName, ediPartyName, et registeredID ne sont pas définies par cette spécification. Cependant, la syntaxe et les sémantiques pour les contraintes de nom pour d'autres formes de nom peuvent être spécifiés dans d'autres documents.

id-ce-nameConstraints OBJECT IDENTIFIER ::= { id-ce 30 }

NameConstraints ::= SEQUENCE {
    permittedSubtrees [0] GeneralSubtrees OPTIONAL,
    excludedSubtrees [1] GeneralSubtrees OPTIONAL }

    GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree

GeneralSubtree ::= SEQUENCE {
    base GeneralName,
    minimum [0] BaseDistance DEFAULT 0,
    maximum [1] BaseDistance OPTIONAL }

BaseDistance ::= INTEGER (0..MAX)

Policy Constraints

   L'extension de contrainte de stratégie peut être utilisée dans les certificats fournis aux CA. Cette extension contraint la validation de chemin de 2 manières. Elle peut être utilisée pour interdire le mappage de stratégie ou nécessiter que chaque certificat dans le chemin contienne un identifiant de stratégie acceptable.

   Si le champ inhibitPolicyMapping est présent, la valeur indique le nombre de certificats additionnels qui peuvent apparaître dans le chemin avant que le mappage de stratégie ne soit plus permis. Par exemple, une valeur indique que le mappage de stratégie peut être traitée dans les certificats fournis par le sujet de ce certificat, mais pas dans les certificats additionnels dans le chemin.

   Si le champ requireExplicitPolicy est présent, sa valeur indique le nombre de certificats additionnels qui peuvent apparaître dans le chemin avant qu'une stratégie explicite soit requise pour tous le chemin. Quand une stratégie explicite est requise, il est nécessaire pour tous les certificats dans le chemin de contenir un identifiant de stratégie acceptable dans l'extension de stratégie de certificat. Un identifiant de stratégie acceptable est l'identifiant d'une stratégie requise par l'utilisateur du chemin de certification ou l'identifiant d'une stratégie qui a été déclarée équivalente via le mappage de stratégie.

   Les applications conformes doivent être capable de traiter le champ requireExplicitPolicy et devraient être capable de traiter le champ inhibitPolicyMapping. Les application qui supportent le champ inhibitPolicyMapping doivent également implémenter le support pour l'extension policyMappings. Si l'extension policyConstraints est marquée critique et que le champ inhibitPolicyMapping est présent, les applications qui n'implémentent pas le support pour inhibitPolicyMapping doivent rejeter le certificat.

   Les CA conformes ne doivent pas fournir de certificats où la contrainte de stratégie est une séquence vide. inhibitPolicyMapping ou requireExplicitPolicy doit être présent. Le comportement des clients qui rencontrent un champ de contrainte de stratégie vide n'est pas adressé dans ce document.

Les CA conformes doivent marquer cette extension critique.
id-ce-policyConstraints OBJECT IDENTIFIER ::= { id-ce 36 }

PolicyConstraints ::= SEQUENCE {
    requireExplicitPolicy [0] SkipCerts OPTIONAL,
    inhibitPolicyMapping [1] SkipCerts OPTIONAL }

SkipCerts ::= INTEGER (0..MAX)

Extended Key Usage

Cette extension indique un ou plusieurs buts pour lequel la clé publique certifiées peut être utilisée, en plus ou à la place de l'extension d'utilisation de clé. En général, cette extension apparaît seulement dans les certificats d'entité finales. Cette extension est définie:
id-ce-extKeyUsage OBJECT IDENTIFIER ::= { id-ce 37 }

ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId

KeyPurposeId ::= OBJECT IDENTIFIER

   Les identifiants d'objet utilisés pour identifier le but de clé doivent être assignés en accord avec les recommandations de l'IANA ou l'ITU-T X.660. Cette extension peut être critique ou non.

   Si l'extension est présente, alors le certificat doit seulement être utilisé pour un des buts indiqué. Si plusieurs buts sont indiqués l'application n'a pas besoin de reconnaître tous les buts indiqués, tant que le but prévus est présent. Les applications utilisant les certificats peuvent nécessiter que l'extension d'utilisation de clé soit présente et qu'un but particulier soit indiqué pour que le certificat soit accepté par l'application.

   Si une CA inclus les utilisations de clé pour satisfaire de telles applications, mais ne souhaite pas restreindre les utilisations de clé, la CA peut inclure le KeyPurposeId spécicial anyExtendedKeyUsage en plus des buts particuliers requis par les applications. Les CA conformes ne devraient pas maquer cette extension critique si anyExtendedKeyUsage est présent. Les applications qui nécessitent la présence d'un but particulier peuvent rejeter les certificats qui incluent anyExtendedKeyUsage mais par l'OID particulier attendus pour l'application.

   Si un certificat contient à la fois l'extension d'utilisation de clé et une extension d'utilisation de clé étendue, les 2 extensions doivent être traitées indépendamment et le certificat doit seulement être utilisé pour un but consistant avec les 2 extensions. S'il n'y a pas de but consistant avec les 2 extensions, alors le certificat ne doit pas être utilisé.

Les buts d'utilisation de clé suivants sont définis:
anyExtendedKeyUsage OBJECT IDENTIFIER ::= { id-ce-extKeyUsage 0 }

id-kp OBJECT IDENTIFIER ::= { id-pkix 3 }

id-kp-serverAuth OBJECT IDENTIFIER ::= { id-kp 1 }
    -- Authentification serveur www TLS
    -- Utilisations de clé qui peuvent être consistant: digitalSignature, keyEncipherment ou keyAgreement

id-kp-clientAuth OBJECT IDENTIFIER ::= { id-kp 2 }
    -- Authentification client www TLS
    -- Utilisations de clé qui peuvent être consistant: digitalSignature, et/ou keyAgreement
    TLS WWW client authentication

id-kp-codeSigning OBJECT IDENTIFIER ::= { id-kp 3 }
    -- Signature de codes exécutables téléchargeables
    -- Utilisations de clé qui peuvent être consistant: digitalSignature

id-kp-emailProtection OBJECT IDENTIFIER ::= { id-kp 4 }
    -- Protection d'email
    -- Utilisations de clé qui peuvent être consistant: digitalSignature, nonRepudiation, et/ou (keyEncipherment ou keyAgreement)

id-kp-timeStamping OBJECT IDENTIFIER ::= { id-kp 8 }
    -- Lier le hash d'un objet à une date
    -- Utilisations de clé qui peuvent être consistant: digitalSignature et/ou nonRepudiation

id-kp-OCSPSigning OBJECT IDENTIFIER ::= { id-kp 9 }
    -- Signature de réponses OCSP
    - Utilisations de clé qui peuvent être consistant: digitalSignature et/ou nonRepudiation

CRL Distribution Points

   L'extension de point de distribution de CRL identifie comment les informations de CRL sont obtenus. L'extension devrait être non-critique, mais ce profile recommande le support pour cette extension par les CA et les application.

   L'extension cRLDistributionPoints est une séquence de DistributionPoint. Un DistributionPoint consiste de 3 champs, chacun d'entre-eux est optionnels: distributionPoint, reasons, et cRLIssuer. Bien que chacun de ces champs est optionnel, un DistributionPoint ne doit pas consister du seul champ reasons; distributionPoint ou cRLIssuer doit être présent. Si le fournisseur de certificat n'est pas le fournisseur de CRL, alors le champ cRLIssuer doit être présent et contient le nom du fournisseur de CRL. Si le fournisseur de certificat est également le fournisseur de CRL, les CA conformes doivent omettre le champ cRLIssuer et doivent inclure le champ distributionPoint.

   Quand le champ distributionPoint est présent, il contient soit une séquence de noms ou une simple valeur, nameRelativeToCRLIssuer. Si le DistributionPointName contient plusieurs valeurs, chaque nom décris un mécanisme différent pour obtenir la même CRL. Par exemple, la même CRL pourrait être disponible via LDAP et HTTP.

   Si le champ distributionPoint contient un directoryName, l'entrée pour ce directoryName contient la CRL courante pour les raisons associées et la CRL est fournie par le cRLIssuer associé. La CRL peut être stockée dans soit certificateRevocationList ou authorityRevocationList. La CRL est obtenus par l'application en fonction de la configuration locale du serveur d'annuaire. Le protocole que l'application utilise pour accéder à l'annuaire et un choix local.

   Si DistributionPointName contient un nom général de type URI, les sémantiques suivante doivent être assumées: l'URI est un pointer vers la CRL courante pour les raisons associées et sera fournis par le cRLIssuer associé. Quand les schémas d'URI HTTP ou FTP sont utilisés, l'URI doit pointer vers une CRL simple encodé DER comme spécifié dans la rfc2585. Les implémentations de serveur HTTP accèdés via l'URI devraient spécifier le type de media application/pkix-crl dans le champ d'en-tête content-type de la réponse.

   Quand le schéma d'URI LDAP est utilisé, l'URI doit inclure un champ dn contenant le nom distinct de l'entrée maintenant la CRL, doit inclure un simple attrdesc qui contient une description d'attribut appropriée pour l'attribut qui maintient la CRL (rfc4523), et devrait inclur un hôte (ex: ‹ldap://ldap.example.com/cn=example%20CA,dc=example,dc=com?certificateRevocationList;binary›). Omettre l'hôte (ex: ‹ldap:///cn=CA,dc=example,dc=com?authorityRevocationList;binary›) implique de s'appuyer sur la connaissance du client du serveur approprié. Quand présent, DistributionPointName devrait inclure au moins une URI LDAP ou HTTP.

   Si DistributionPointName contient un simple valeur nameRelativeToCRLIssuer, la valeur fournis un fragment de nom distinct. Le fragment est ajouté au nom distinct X.500 du fournisseur de CRL pour obtenir le nom du point de distribution. Si le champ cRLIssuer dans le DistributionPoint est présent, alors le fragment est ajouté au nom distinct qu'il contient, sinon le fragment est ajouté au nom distinct du fournisseur de certificat. Les CA conformes ne devraient pas utiliser nameRelativeToCRLIssuer pour spécifier les noms des points de distributions. Le DistributionPointName ne doit pas utiliser un nameRelativeToCRLIssuer relatif quand cRLIssuer contient plus d'un nom distinct.

   Si DistributionPoint omet le champ reasons, la CRL doit inclure des informations de révocation pour toutes les raisons. Ce profile recommande d'éviter la segmentation de CRL par code de raison. Quand une CA conforme inclus une extension cRLDistributionPoints dans un certificat, elle doit inclure au moins un DistributionPoint qui pointe vers une CRL qui couvre le certificat pour toutes les raisons.

   cRLIssuer identifie l'entité qui signe et fournis la CRL. Si présent, cRLIssuer doit seulement contenir le nom distinct du champ issuer de la CRL pointé par le DistributionPoint. L'encodage du nom dans le champ cRLIssuer doit être exactement le même que l'encodage dans le champ issuer de la CRL. Si le champ cRLIssuer est inclus et le dn dans ce champ ne correspond par à une entrée X.500 ou LDAP où la CRL est localisée, alors les CA conformes doivent inclure le champ distributionPoint.

id-ce-cRLDistributionPoints OBJECT IDENTIFIER ::= { id-ce 31 }

CRLDistributionPoints ::= SEQUENCE SIZE (1..MAX) OF DistributionPoint

DistributionPoint ::= SEQUENCE {
    distributionPoint [0] DistributionPointName OPTIONAL,
    reasons [1] ReasonFlags OPTIONAL,
    cRLIssuer [2] GeneralNames OPTIONAL }

DistributionPointName ::= CHOICE {
    fullName [0] GeneralNames,
    nameRelativeToCRLIssuer [1] RelativeDistinguishedName }

ReasonFlags ::= BIT STRING {
    unused (0),
    keyCompromise (1),
    cACompromise (2),
    affiliationChanged (3),
    superseded (4),
    cessationOfOperation (5),
    certificateHold (6),
    privilegeWithdrawn (7),
    aACompromise (8) }

Inhibit anyPolicy

   L'extension inhibit anyPolicy peut être utilisée dans les certificats fournis aux CA. Elle indique que l'OID spéciale anyPolicy { 2 5 29 32 0 }, n'est pas considérée comme une correspondance explicite pour les autres stratégies de certificat excepté quand elle apparaît dans un certificat CA auto-fournis intermédiaire. La valeur indique le nombre de certificats non auto-fournis additionnels qui peuvent apparaître dans le chemin avant que anyPolicy ne soit plus permis. Par exemple, une valeur de 1 indique que anyPolicy peut être traitée dans les certificats fournis par le sujet de ce certificat, mais pas dans les certificats additionnels dans le chemin.

Les CA conformes doivent marquer cette extension critique
id-ce-inhibitAnyPolicy OBJECT IDENTIFIER ::= { id-ce 54 }

InhibitAnyPolicy ::= SkipCerts

SkipCerts ::= INTEGER (0..MAX)

Freshest CRL

l'extension freshest CRL identifie comment les informations de CRL delta sont obtenus. Cette extension doit être marquée non critique. La même syntaxe est utilisée pour cette extension et l'extension cRLDistributionPoints. Les même conventions d'appliquent aux 2 extensions
id-ce-freshestCRL OBJECT IDENTIFIER ::= { id-ce 46 }

FreshestCRL ::= CRLDistributionPoints

Extensions Internet privées

Cette section définis 2 extensions à utiliser dans les infrastructures à clé publique de l'Internet. Ces extensions peuvent être utilisées pour diriger les applications vers des informations en ligne sur le fournisseur ou le sujet. Chaque extension contient une séquence de méthodes d'accès et d'emplacements d'accès. La méthode d'accès est un identifiant d'objet qui indique le type d'informations qui sont disponibles. L'emplacement d'accès est un GeneralName qui spécifie implicitement l'emplacement et le format des informations et la méthode pour obtenir ces informations.

Les identifiants d'objet sont définis pour les extensions privées. Les identifiants d'objet associés avec les extensions privées sont définies sous l'arc id-pe dans l'arc id-pkix. Toutes extensions futures définies pour la PKI Internet seront définis également sous cet arc id-pe.
id-pkix OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) }

id-pe OBJECT IDENTIFIER ::= { id-pkix 1 }

Authority Information Access

   L'extension d'accès aux informations d'autorité indique comment accéder aux informations et services pour le fournisseur du certificat dans lequel l'extension apparaît. Les informations et services peuvent inclure des services de validation en ligne et les données de stratégie de CA. ( L'emplacement des CRL n'est pas spécifié dans cette extension). Cette extension peut être inclus dans les certificat d'entité finale ou de CA. Les CA conformes doivent marquer cette extension non-critique.

id-pe-authorityInfoAccess OBJECT IDENTIFIER ::= { id-pe 1 }

AuthorityInfoAccessSyntax ::=
    SEQUENCE SIZE (1..MAX) OF AccessDescription

AccessDescription ::= SEQUENCE {
    accessMethod OBJECT IDENTIFIER,
    accessLocation GeneralName }

id-ad OBJECT IDENTIFIER ::= { id-pkix 48 }

id-ad-caIssuers OBJECT IDENTIFIER ::= { id-ad 2 }

id-ad-ocsp OBJECT IDENTIFIER ::= { id-ad 1 }

   Chaque entrée dans la séquence AuthorityInfoAccessSyntax décris le format et l'emplacement d'informations additionnelles fournies par le fournisseur du certificat dans lequel cette extension apparaît. Le type et le format des informations sont spécifiées par le champ accessMethod; le champ accessLocation spécifie l'emplacement des informations. Le mécanisme de récupération peut être déduit par accessMethod ou spécifié par accessLocation.

   Ce profile définis 2 OID d'accessMethod: id-ad-caIssuers et id-ad-ocsp.

   Dans un certificat à clé publique, l'OID id-ad-caIssuers est utilisé quand les informations additionnelles listent les certificats qui ont été fournis à la CA qui a fournis le certificat contenant cette extension. La description de fournisseurs CA référencés est destiné à aider les utilisateurs de certificat dans la sélection d'un chemin de certification qui se termine au point validé par le certificat utilisateur.

   Quand id-ad-caIssuers apparaît comme accessMethod, le champ accessLocation décris le serveur de description référencé et le protocole d'accès pour obtenir la description référencée. Le champ accessLocation est définis en GeneralName, qui peut prendre de nombreuses formes.

   Quand accessLocation est un directoryName, l'information est obtenu par l'application en fonction du serveur d'annuaire configuré localement. L'entrée pour le directoryName contient les certificats CA dans les attributs crossCertificatePair et/ou cACertificat comme spécifié dans la rf4523. Le protocole que les applications utilisent pour accéder à l'annuaire est une décision locale.

   Quand l'information est disponible via LDAP, accessLocation devrait être un uniformResourceIdentifier. L'URI LDAP doit inclure un champ dn contenant le dn de l'entrée maintenant les certificats, doit inclure un champ attribute qui maintient la liste des descriptions d'attributs appropriés pour les attributs qui maintiennent les certificats encodés DER ou les paire le cross-certificats, et devraient inclure un hôte ( ex ‹ldap://ldap.example.com/cn=CA,dc=example,dc=com?cACertificate;binary,crossCertificatePair;binary›). Omettre l'hôte (ex: ‹ldap:///cn=exampleCA,dc=example,dc=com?cACertificate;binary›) implique que le client connaisse le serveur approprié à contacter.

   Quand les informations sont disponibles via HTTP ou FTP, accessLocation doit être un uniformResourceIdentifier et l'URI doit pointer sur soit un simple certificat encodé DER comme spécifié dans la rfc2585, ou une collection de certificats dans message CMS "certs-only" encodé DER ou BER, comme spécifié dans la rfc2797.

   Les applications conformes qui supportent HTTP ou FTP pour accéder aux certificats doivent être capable d'accepter les certificats encodés DER individuels et devraient être capable d'accepter les message CMS "certs-only".

   Les implémentations serveur HTTP accédés via l'URI devraient spécifier le type de média application/pkix-cert (rfc2585) dans l'en-tête content-type de la réponse pour un simple certificat encodé DER et devrait spécifier le type de média application/pkcs7-mime (rfc2797) dans le champ d'en-tête content-type de la réponse pour les messages CMS "certs-only". Pour FTP, le nom d'un fichier qui contient un simple certificat encodé DER devrait avoir le suffix ".cer" (rfc2585), et le nom d'un fichier qui contient un message CMS "certs-only" devrait avoir l'extension ".p7c" (rfc2797). Les clients peuvent utiliser le type de média ou l'extension de fichier, mais ne devraient pas dépendre uniquement de la présence du type de média ou de l'extension de fichier correcte dans la réponse du serveur.

   Les sémantiques pour d'autres formes de noms d'accessLocation id-ad-caIssuers ne sont pas définis.

   Une extension authorityInfoAccess peut inclure plusieurs instances de l'accessMethod id-ad-caIssuers. Les différentes instances peut spécifier différentes méthodes d'accès à la même information ou peut pointer vers différentes informations. Quant l'accessMethod id-ad-caIssuers est utilisé, au moins une instance devrait spécifier un accessLocation qui est une URI HTTP ou LDAP.

   L'OID id-ad-ocsp est utilisé quand les informations de révocation pour le certificat contenant cette extension est disponible en utilisant OCSP (rfc2560). Quand id-ad-ocsp apparaît comme accessMethod, le champ accessLocation est l'emplacement du répondeur OCSP, en utilisant les conventions spécifiées dans la rfc2560.

   Des descripteurs d'accès additionnels peuvent être définis dans d'autres spécification PKIX.

Subject Information Access

   L'extension d'accès aux informations du sujet indique comment accéder aux informations et services pour le sujet du certificat dans lequel l'extension apparaît. Quand le sujet est une CA, les informations et services peuvent inclure des services de validation de certificat et une donnée de stratégie CA. Quand le sujet est une entité finale, les informations décrivent le type de services offerts et comment y accéder. Dans ce cas, le contenu de cette extension est définis dans les spécifications du protocole pour les services supportés. Cette extension peut être inclue dans des certificats CA ou d'entité finale. Les CA conformes doivent marquer cette extension non-critique.

id-pe-subjectInfoAccess OBJECT IDENTIFIER ::= { id-pe 11 }

SubjectInfoAccessSyntax ::=
    SEQUENCE SIZE (1..MAX) OF AccessDescription

AccessDescription ::= SEQUENCE {
    accessMethod OBJECT IDENTIFIER,
    accessLocation GeneralName }

   Chaque entrée dans la séquence SubjectInfoAccessSyntax décris le format et l'emplacement des informations additionnelles fournies par le sujet du certificat dans lequel cette extension apparaît. Le type et le format de l'information sont spécifiés par le champ accessMethod; le champ accessLocation spécifie l'emplacement de l'information. Le mécanisme de récupération peut être implicite via accessMethod ou accessLocation.

   Ce profile définis une méthode d'accès à utiliser quand le sujet est une CA et une méthode d'acces utilisée quand le sujet est une entité finale. Des méthodes d'accès additionnels peuvent être définis dans de futures spécification de protocole pour d'autres services.

   L'OID id-ad-caRepository est utilisé quand le sujet est une CA qui publie les certificat quelle fournis dans un annuaire. Le champ accessLocation est définis en GeneralName, qui peut prendre de nombreuses formes.

   Quand accessLocation est un directoryName, l'information est obtenue par l'application depuis le serveur d'annuaire configuré localement. Quand l'extension est utilisée pour pointer vers des certificats CA, l'entrée pour le directoryName contient les certificats CA dans les attributs crossCertificatePair et/ou cACertificat comme spécifiés dans la rfc4523. Le protocole que l'application utilise pour accéder à l'annuaire est un choix local.

   Quand les informations sont disponible via LDAP, accessLocation devrait être un uniformResourceIdentifier. L'URI ldap doit inclure un champ dn contenant le dn de l'entrée maintenant les certificats, doit inclure un champ attribute qui liste les descriptions d'attributs appropriés pour les attributs qui maintiennent les certificats encodés DER ou les paires de cross-certificats, et devraient inclure un hôte. ( ex: ‹ldap://ldap.example.com/cn=CA,dc=example,dc=com?cACertificate;binary,crossCertificatePair;binary› ). Omettre l'hôte implique que le client connaît le serveur approprié à contacter.

   Quand l'information est disponible via HTTP ou FTP, accessLocation doit être un uniformResourceIdentifier et l'URI doit pointer soit vers un simple certificat encodé DER ou une collection de certificats dans un message CMS "certs-only" encodés DER ou BER.

   Les applications conformes qui supportent HTTP ou FTP pour accéder aux certificats doivent être capable d'accepter les certificat encodés DER individuels et devraient être capable d'accepter les message CMS "certs-only".

   Les implémentations de serveur HTTP accédés via l'URI devraient spécifier le type de média application/pkix-cert (rfc2585) dans l'en-tête content-type de la réponse pour un simple certificat encodé DER et devrait spécifier le type de média application/pkcs7-mime (rfc2797) dans le champ d'en-tête content-type de la réponse pour les messages CMS "certs-only". Pour FTP, le nom d'un fichier qui contient un simple certificat encodé DER devrait avoir le suffix ".cer" (rfc2585), et le nom d'un fichier qui contient un message CMS "certs-only" devrait avoir l'extension ".p7c" (rfc2797). Les clients peuvent utiliser le type de média ou l'extension de fichier, mais ne devraient pas dépendre uniquement de la présence du type de média ou de l'extension de fichier correcte dans la réponse du serveur.

   Les sémantiques pour d'autres formes de nom accessLocation id-ad-caRepository ne sont pas définies.

   Une extension subjectInfoAccess peut inclure plusieurs instances de accessMethod id-ad-caRepository. Les instances différentes peuvent spécifier des méthodes différentes pour accéder à la même information ou peuvent pointer vers différentes informations. Quand accessMethod id-ad-caRepository est utilisé, au moins une instance devrait spécifier un accessLocation qui est une URI HTTP ou LDAP.

   L'OID id-ad-timeStamping est utilisé quand le sujet offre des services de timestamping utilisant le TSP (rfc3161). Quand les services de timestamping sont disponibles via HTTP ou FTP, accessLocation doit être un uniformResourceIdentifier. Quand les services de timestamping sont disponibles via les messages électroniques, accessLocation doit être un rfc822Name. Quand les services de timestamping sont disponibles en utilisant TCP/IP, les formes de noms dNSName ou iPAddress peuvent être utilisés. Les sémantiques d'autres formes de nom de accessLocation (quand accessMethod est id-ad-timeStamping) ne sont pas définis par cette spécification.

Des descripteurs d'accès additionnels peuvent être définis dans d'autres spécifications PKIX.
id-ad OBJECT IDENTIFIER ::= { id-pkix 48 }

id-ad-caRepository OBJECT IDENTIFIER ::= { id-ad 5 }

id-ad-timeStamping OBJECT IDENTIFIER ::= { id-ad 3 }

Profile de CRL et d'extensions de CRL

   Comme discuté plus haut, un des but de ce profile de CRL X.509 v2 est de favoriser la création d'une ICP Internet interopérable et réutilisable. Pour cela, des lignes directrices pour l'utilisation des extensions sont spécifiée, et certaines hypothèses sont faites sur la nature des informations inclues dans la CRL.

   Les CRL peuvent être utilisée dans un grande variété d'applications et d'environnement couvrant un large spectre de pré-requis opérationnels et d'assurance. Ce profile établis une ligne de base commune pour les applications génériques nécessitant une grande interopérabilité. Ce profile définis un jeu d'informations qui peuvent être prévus dans toutes les CRL. Également, le profile définis des emplacements communs dans la CRL pour les attributs fréquemment utilisés et les représentations communes pour ces attributs.

   Les fournisseurs de CRL fournissent les CRL. Le fournisseur de CRL est soit la CA ou une entité qui a été autorisée par la CA pour fournir les CRL. Les CA publient les CRL pour fournir des informations de statut sur les certificats qu'elles émettent. Cependant, une CA peut déléguer cette responsabilité à une autre autorité de confiance.

   Chaque CRL a un périmètre particulier. Le scope de CRL est le jeu de certificats qui peuvent apparaître dans une CRL donnée. Par exemple, le scope pourrait être "tous les certificats émis par la CA X", "Tous les certificats de CA fournis par la CA X", "tous les certificats émis par la CA X qui ont été révoqués pour une raison de compromission de clé et de CA compromise", ou un jeu de certificats basés sur des informations locales arbitraire, tels que "tous les certificats fournis aux employés NIST localisé à Boulder.

   Une CRL complète liste tous les certificat non-expirés, dans son scope, qui ont été révoqués pour une des raisons de révocation couverts par le scope de la CRL. Une CRL pleine et complète liste tous les certificats non-expirés fournis par une CA qui a été révoqué pour une raison. (Noter que vu que les CA et les fournisseurs de CRL sont identifiés par nom, le scope d'une CRL n'est pas affectée par la clé utilisée pour signer la CRL ou les clés utilisées pour signer les certificats).

   Si le scope de la CRL inclus un ou plusieurs certificats fournis par une entité autre que le fournisseur de CRL, alors c'est une CRL indirecte. Le scope d'une CRL indirect peut être limitée aux certificats fournis par une simple CA ou peut inclure les certificats fournis par plusieurs CA. Si le fournisseur de la CRL indirecte est une CA, alors le scope de la CRL indirecte peut également inclure les certificats inclus par le fournisseur de cette CRL.

   Le fournisseur de CRL peut également générer des CRL delta. Une CRL delta liste seulement les certificats, dans son scope, dont le statut de révocation a changé depuis l'émission de la dernière CRL de complète référencée. Le scope d'une CRL delta doit être la même que a CRL de base qu'elle référence.

   Ce profile définis une extension de CRL Internet privée mais ne définis pas d'extensions d'entrée de CRL privée.

   Les environnements avec de besoins spéciaux ou additionnels peuvent se baser sur ce profile ou le remplacer.

   Les CA conformes ne sont pas obligés de fournir des CRL si d'autre mécanismes de statut de révocation ou de certificat sont fournis. Quand les CRL sont fournis, les CRL doivent être des CRL v2, doivent inclure la date à laquelle la prochaine CRL sera fournie dans le champ nextUpdate, doivent inclure l'extension de numéro de CRL, et doivent inclure l'extension d'identifiant de clé d'autorité. Les applications conformes qui supportent les CRL doivent traiter les CRL v1 et v2 qui fournissent des informations de révocation pour tous les certificats fournis par une CA. Les applications conformes ne sont pas obligés de supporter le traitement des CRL delta, des CRL indirect, ou des CRL avec un scope autre que tous les certificats fournis par une CA.

Champs de CRL

La syntaxe de CRL X.509 v2 est la suivante. Pour le calcule de signature, la donnée qui est signée est encodée ASN.1 DER. Un encodage ASN.1 DER est un système d'encodage ayant un tag, une longueur, et une valeur pour chaque élément.
CertificateList ::= SEQUENCE {
    tbsCertList TBSCertList,
    signatureAlgorithm AlgorithmIdentifier,
    signatureValue BIT STRING }

TBSCertList ::= SEQUENCE {
    version Version OPTIONAL, -- si présent, doit être v2
    signature AlgorithmIdentifier,
    issuer Name,
    thisUpdate Time,
    nextUpdate Time OPTIONAL,
    revokedCertificates SEQUENCE OF SEQUENCE {
        userCertificate CertificateSerialNumber,
        revocationDate Time,
        crlEntryExtensions Extensions OPTIONAL -- si présent, doit être v2
    } OPTIONAL,
    crlExtensions [0] EXPLICIT Extensions OPTIONAL -- si présent, doit être v2
}

-- Version, Time, CertificateSerialNumber, et les Extensions
-- sont tous définis dans la section "champs de certificat de base"
-- AlgorithmIdentifier est décris dans la section signatureAlgorithm

Champs CertificateList

CertificateList est une séquence de 3 champs requis. Les champs sont décris en détail ci-dessous.

tbsCertList

Le premier champ dans la séquence est le tbsCertList. Ce champ est lui-même une séquence contenant le nom du fournisseur, une date d'émission, une date d'émission de la prochaine liste, la liste optionnelle des certificats révoqués, et les extensions de CRL optionnels. Quand il n'y a pas de certificats révoqués, la liste des certificats révoqués est absent. Quand un ou plusieurs certificats sont révoqués, chaque entrée dans la liste de certificat révoqués est définie par une séquence de numéro de série de certificat utilisateur, d'une date de révocation, et des extensions d'entrée de CRL optionnels.

signatureAlgorithm

Le champ signatureAlgorithme contient l'identifiant pour l'algorithme utilisé par le fournisseur de CRL pour signer le CertificateList. Le champ est de type AlgorithmIdentifier, mais d'autres algorithmes de signatures peuvent être supportés. Ce champ doit contenir le même identifiant d'algorithme que le champ signature dans la séquence tbsCertList.

signatureValue

   Le champ signatureValue contient une signature numérique calculée sur le tbsCertList encodé DER ASN.1, qui est utilisé en entrée de la fonction de signature. Cette valeur de signature est encodée en chaîne de bits et inclus dans le champ signatureValue de la CRL. Les détails de ce processus sont spécifiés pour chacun des algorithmes supportés dans les rfc3279, rfc4055, et rfc 4491.

   Les CA qui sont également fournisseurs de CRL peuvent utiliser une seul clé privée pour signer numériquement les certificats et les CRL, ou peuvent utiliser des clé privées séparées. Quand des clés privées séparés sont utilisées, chaque clé publique associée avec les clés ces clés privée sont placées dans un certificat séparé, une avec le bit keyCertSign mis dans l'extension d'utilisation de clé, et une avec le bit cRLSign mis dans l'extension d'utilisation de clé. Quand des clés privée séparés sont utilisés, les certificats émis par la CA contiennent un seul identifiant de clé d'autorité, et les CRL correspondantes contiennent un identifiant de clé d'autorité différent.

   L'utilisation de certificats CA séparés pour la validation des signature de certificat et de CRL peut offrir de caractéristiques de sécurité améliorés; cependant, cela impose une charge dans les applications, et peut limiter l'interopérabilité. De nombreuses application construisent un chemin de certification, puis le valide. La vérification de CRL nécessite un chemin de certification séparé pour la validation de la signature de la CRL. Les applications qui vérifient la CRL doivent supporter la validation de chemin de certification quand les certificats et les CRL sont signés numériquement avec la même clé privée, et devraient supporter la validation de chemin de certification quand les certificats et les CRL sont signés numériquement avec des clé différentes.

Certificate List To Be Signed

La liste de certificat signée, ou TBSCertList, est une séquence de champs requis et optionnels. Les champs requis identifient le fournisseur de la CRL, l'algorithme utilisé pour signer la CRL, et la date d'émission de la CRL.

Les champs optionnels incluent la date à laquel le fournisseur de CRL va émettre la prochaine CRL, les listes de certificats révoqués, et les extensions de CRL. La liste de certificats révoqués est optionnel pour supporter le cas où une CA n'a pas de certificats révoqué. Ce profile nécessite que les fournisseurs de CRL conformes incluent le champ nextUpdate et les extensions de CRL d'identifiant de clé d'autorité et de numéro.

Version

Ce champ optionnel décris la version de la CRL encodée. Quand les extensions sont utilisées, comme requis par ce profile, ce champ doit être présent et doit spécifier la version 2 (valeur 1).

Signature

Ce champ contient l'identifiant d'algorithme pour l'algorithme utilisé pour signier la CRL. la rfc3279, rfc4055, et rfc 4491 listent les OID pour les algorithmes de signature les plus populaires utilisés dans les PKI de l'Internet.

Issuer Name

Le nom du fournisseur identifie l'entité qui a signé et fournis la CRL. L'identité du fournisseur est placé dans le champ issuer. Les formes de noms Alternatives peuvent également apparaître dans l'extension issuerAltName. Le champ issuer doit contenir un DN X.500 non-vide. Le champ issuer est définis comme nom de type X.501, et doit suivre les rêgles d'encodage pour le champs du nom du fournisseur dans le certificat.

This Update

Ce champ indiques la date d'émission de cette CRL. thisUpdate peut être encodé en UTCTime ou GeneralizedTime. Les fournisseurs de CRL conformes à ce profile doivent encoder thisUpdate en UTCTime pour les dates avant 2050. Les fournisseurs de CRL conformes à ce profile doivent encoder thisUpdate en GeneralizedTime pour des dates après 2049. Les application conformes doivent être capable de traiter les dates qui sont encodé en UTCTime ou GeneralizedTime.

Quand encodé en UTCTime, thisUpdate doit être spécifié et interprété comme définis plus haut dans ce document (voir section UTCTime). Quand encodé en GeneralizedTime, thisUpdate doit être spécifié et interprété comme définis plus haut dans ce document (voir section GeneralizedTime).

Next Update

   Ce champ indique la date à laquelle la prochaine CRL sera fournie. La prochaine CRL pourrait être fournie avant cette date, mais ne sera pas fournis après cette date. Les fournisseurs de CRL devraient fournir les CRL avec un temps nextUpdate égale à ou supérieurs à tous les CRL précédentes. nextUpdate peut être encodé en UTCTime ou GeneralizedTime.

   Les fournisseurs de CRL conformes doivent inclure le champ nextUpdate dans toutes les CRL. Noter que la syntaxe ASN.1 de TBSCertList décris ce champ comme optionnel, qui est consistant avec la structure ASN.1 définis dans X.509. Le comportement des clients traitant les CRL qui omettent nextUpdate n'est pas définis par ce profile.

   Les fournisseurs de CRL conformes à ce profile doivent encoder nextUpdate en UTCTime pour les dates avant 2050 et en GeneralizedTime pour les dates après 2049. Les application conformes doivent être capable de traiter les dates encodés en UTCTime ou GeneralizedTime.

   Quand encodé en UTCTime, nextUpdate doit être spécifié et interprété comme définis plus haut dans ce document (voir section UTCTime). Quand encodé en GeneralizedTime, nextUpdate doit être spécifié et interprété comme définis plus haut dans ce document (voir section GeneralizedTime).

Revoked Certificates

Quand il n'y a pas de certificats révoqués, la liste des certificats révoqué doit être absent. Sinon, les certificats révoqués sont listés par leur numéro de série. Les certificats révoqués par la CA sont identifiés de manière unique par ce numéro de série. La date à laquelle la révocation se produit est spécifiée. La date pour revocationDate doit être exprimée comme décris dans la section thisUpdate. Des informations additionnelles peuvent être fournis dans les extensions d'entrée de CRL.

Extensions

Ce champ peut seulement apparaître si la version est 2. Si présent, ce champ est une séquence d'une ou plusieurs extensions de CRL.

Extensions de CRL

Les extensions définis par ANSI X9, ISO/IEC, et l'ITU-T pour les CRL X.509 v2 fournissent des méthodes pour associer des attributs additionnels avec les CRL. Le format de CRL X.509 v2 permet également des extensions privées. Chaque extension dans une CRL peut être conçue comme critique ou non. Si une CRL contient une extension critique que l'application en peut pas traiter, alors l'application ne doit pas utiliser cette CRL pour déterminer le statut des certificats. Cependant, les applications peuvent ignorer les extensions non-critiques non reconnus. Les sections suivantes présentent ces extensions utilisées avec les CRL de l'internet. Les communautés peuvent choisir d'inclure des extensions dans les CRL qui ne sont pas définies dans cette spécification. Cependant, une attention particulière doit être faite pour l'adoptions d'extensions critiques dans les CRL qui pourraient être utilisées dans un contexte général.

Les fournisseurs de CRL conformes doivent inclure les extensions d'identifiant de clé d'autorité et de numéro de CRL dans toutes les CRL émises.

Authority Key Identifier

L'extension d'identifiant de clé d'autorité fournis un moyen d'identifier la clé publique correspondante à la clé privée utilisée pour signer une CRL. L'identification peut être basée sur l'identifiant de clé (l'identifiant de clé du sujet dans le certificat du signataire de la CRL) ou le nom et le numéro de série du fournisseur. Cette extension est spécialement utile où un fournisseur a plus d'une clé de signature, soit dû à plusieurs paires de clé concurrentes, ou dû à un changement.

Les fournisseurs de CRL conformes doivent utiliser la méthode d'identifiant de clé, et doivent inclure cette extension dans toutes les CRL émise. La syntaxe pour cette extension de CRL est définie dans la section Authority Key Identifier.

Issuer Alternative Name

L'extension de nom alternatif de fournisseur permet d'associer des identités alternatives avec le fournisseur de CRL. Les options définies incluent une adresse de messagerie électronique (rfc822Name), un nom DNS, une adresse IP, et une URI. Plusieurs instances d'une forme de nom et plusieurs formes de noms peuvent être inclus. Quand de telles identités sont utilisées, l'extension de nom alternatif de fournisseur doit être utilisé; cependant, un nom DNS peut être représenté dans le champ issuer en utilisant l'attribut domainComponent décris dans la section Issuer.

Les fournisseurs de CRL conformes devraient marquer l'extension issuerAltName comme non-critique. L'OID et la syntaxe pour cette extension de CRL sont définis dans la section Issuer Alternative Name précédente.

CRL Number

   Le numéro de CRL est une extension de CRL non-critique qui transmet un numéro de séquence croissant monotone pour un scope de CRL et un fournisseur de CRL donné. Cette extension permet aux utilisateurs de facilement déterminer quand une CRL particulière remplace une autre CRL. Les numéros de CRL supportent également l'identification de CRL complètes et de CRL delta complémentaires. Les fournisseurs de CRL conformes à ce profile doivent inclure cette extension dans toutes les CRL et doivent marquer cette extension non-critique.

   Si un fournisseur de CRL génère des CRL delta en plus de CRL complètes pour un scope donné, les CRL complète et delta doivent partager une séquence de numéro. Si une CRL delta et une CRL couvrant le même scope sont émis en même temps, elles doivent avoir le même numéro de CRL et fournir la même information de révocation. C'est à dire, la combinaison de la CRL delta et une CRL complète acceptable doivent fournir la même information de révocation que la CRL complète.

   Si un fournisseur de CRL génère 2 CRL ( 2 CRL complètes, 2 CRL delta, ou une CRL complète et une CRL delta) pour le même scope à des moments différents, les 2 CRL ne doivent pas avoir le même numéro de CRL, c'est à dire, si le champ thisUpdate dans les 2 CRL ne sont pas identiques, les numéros de CRL doivent être différents.

En considération, les numéro de CRL peuvent être de long entiers. Les vérificateurs de CRL doivent être capable de gérer des valeur CRLNumber jusqu'à 20 octets. Les fournisseurs de CRL conformes ne doivent pas utiliser de valeurs CRLNumber plus long que 20 octets.
id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 }

CRLNumber ::= INTEGER (0..MAX)

Delta CRL Indicator

   L'indicateur de CRL delta est une extension de CRL critique qui identifie qu'une CRL est une CRL delta. Les CRL delta contiennent des mises à jours d'information de révocation précédemment distribuée. L'utilisation de CRL delta peut significativement réduire la charge réseaux et le temps de traitement dans certains environnements. Les CRL delta sont généralement plus petites que les CRL qu'elles mettent à jours, donc les applications qui obtiennent les CRL delta consomment moins de bande passante que les applications qui obtiennent les CRL complètes correspondantes. Les applications qui stockent les informations de révocation dans un format autre que la structure CRL peuvent ajouter les nouvelles information de révocation dans la base locale sans retraiter les informations.

   L'extension d'indication de CRL delta contient une valeur simple de type BaseCRLNumber. Le numéro de CRL identifie la CRL, complète pour un scope donné, qui a été utilisé comme point de départ dans la génération de cette CRL delta. Un fournisseur de CRL conforme doit publier la CRL de base référencée ou une CRL complète. La CRL delta contient toutes les mises à jours de statut de révocation pour ce même scope. La combinaison d'une CRL delta et de la CRL de base référencée est équivalente à une CRL complète, pour le périmètre applicable, au moment de la publication de la CRL delta.

   Quand un fournisseur de CRL conforme génère une CRL delta, la CRL delta doit inclure une extension d'indication de CRL delta.

   Quand une CRL delta est émise, elle doit couvrir le même jeu de raisons et le même jeu de certificats qui sont couverts par la CRL de base qu'elle référence. C'est à dire que le scope de la CRL delta doit être le même que le scope de la CRL complète référencée comme base. La CRL de base référencée et la CRL delta doivent omettre l'extension de point de distribution d'émission ou doivent contenir des extensions de point de distribution d'émission identique. De plus, le fournisseur de CRL doit utiliser la même clé privée pour signer la CRL delta et toute CRL complète qui peut être utilisée pour les mises à jours.

   Une application qui supporte les CRL delta peuvent construire une CRL qui est complète pour un scope donné en combinant une CRL delta pour ce scope avec soit une CRL émise qui est complète pour ce scope ou une CRL construite localement, qui est complète pour ce scope.

   Quand une CRL delta est combinée avec une CRL complète ou une CRL construite localement, la CRL construite localement résultante a le numéro de CRL spécifié dans l'extension de numéro de CRL trouvé dans la CRL delta utilisée dans sa construction. En plus, le CRL construite localement résultante a les temps thisUpdate et nextUpdate spécifiés dans les champs correspondant de la CRL delta utilisés dans sa construction. En plus, la CRL construite localement hérite du point de distribution d'émission de la CRL delta.

   Une CRL complète et une CRL delta peuvent être combinés si les 4 conditions suivantes sont satisfaites:

(a) La CRL complète et la CRL delta ont le même fournisseur
(b) La CRL complète et la CRL delta ont le même périmètre. Les 2 CRL ont le même périmètre si une des conditions suivantes est satisfaite:

(1) L'extension issuingDistributionPoint est omis de la CRL complète et de la CRL delta
(2) L'extension issuingDistributionPoint est présente dans la CRL complète et la CRL delta est sont identiques.

(c) Le numéro de CRL de la CRL complète est égale ou supérieur au BaseCRLNumber spécifié dans la CRL delta. C'est à dire que la CRL complète contient (au minimum) toutes les informations de révocation maintenus par la CRL de base référencée.
(d) Le numéro de CRL de la CRL complète est inférieur au numéro de CRL de la CRL delta. C'est à dire, la CRL delta suit la CRL complète dans la séquence de numérotation.

   Les fournisseurs de CRL doivent s'assurer que la combinaison d'une CRL delta et toute CRL complète appropriée réflète précisément le statut de révocation. Le fournisseur e CRL doit inclure une entrée dans la CRL delta pour chaque certificat dans le scope de la CRL delta dont le status a changé depuis la génération de la CRL de base référencée:

(a) Si le certificat est révoqué pour une raison inclue dans le scope de la CRL, liste le certificat révoqué.
(b) Si le certificat est valide et a été listé dans la CRL de base référencée ou toute CRL suivantes avec un code de raison certificatHold est inclus dans le scope de la CRL, liste le certificat avec le code de raison removeFromCRL.
(c) Si le certificat est révoqué pour une raison hors du scope de la CRL, mais que le certificat a été listé dans la CRL de base référencée ou toute CRL suivante avec un code de raison inclus dans le scope de cette CRL, liste le certificat comme révoqué mais omet le code de raison.
(d) Si le certificat est révoqué pour une raison hors du scope de la CRL est que le certificat n'est ni listé dans la CRL de référence ni dans les CRL suivantes avec un code un code de raison inclus dans le scope de cette CRL, ne pas lister le certificat dans cette CRL.

   Le statut d'un certificat est considéré comme ayant changé s'il est révoqué (pour n'importe quelle raison, incluant certificateHold), s'il est libéré de l'attente, ou si sa raison de révocation change.

   Il est approprié de lister un certificat avec un code de raison removeFromCRL dans une CRL delta même si le certificat n'était pas en attente dans la CRL de base référencée. Si le certificat a été placé en attente dans une CRL émise après la base mais avant cette CRL delta puis relachée, il doit être listé dans le CRL delta avec une raison de révocation removeFromCRL.

   Un fournisseur de CRL peut optionnellement lister un certificat dans une CRL delta avec le code de raison removeFromCRL si le temps notAfter spécifié dans le certificat précède le temps thisUpdate spécifié dans la CRL delta et que le certificat était listé dans la CRL de base référencée. ou dans toute CRL émise après la base mais avant cette CRL delta.

   Si une révocation de certificat apparaît dans une CRL delta, il est possible pour que la période de validité du certificat expire avant la prochaine CRL complète pour le même scope. Dans ce cas, La notification de révocation doit être inclue dans toutes les CRL delta suivantes jusqu'à ce que la notification de révocation soit inclue dans au moins une CRL complète émise pour ce scope.

   Une application qui supporte les CRL delta doit être capable de construire une CRL complète courante en combinant une CRL complète et la CRL delta la plus récente. Une application qui supporte les CRL delta peut également être capable de construire une CRL complète courante en combinant une CRL complète construite localement et la CRL delta courante. Une CRL delta est considérée courante si le date courante est entre les temps contenus dans thisUpdate et nextUpdtae. Sous certaines circonstances, le fournisseur de CRL peut publier une ou plusieurs CRL avant le temps indiqué par le champ nextUpdate. Si plus d'une CRL delta courante est rencontré pour un scope donné, l'application devrait être considérée celle ayant la valeur thisUpdate la plus récente comme courante.

id-ce-deltaCRLIndicator OBJECT IDENTIFIER ::= { id-ce 27 }

BaseCRLNumber ::= CRLNumber

Issuing Distribution Point

   Le point de distribution d'émission est une extension de CRL critique qui identifie le point de distribution de CRL et le scope pour une CRL particulière, et indique si la CRL couvre la révocation des certificat d'entités finaux uniquement, des certificats CA uniquement, ou un jeu limité de codes de raisons. Bien que cette extension soit critique, les implémentations conformes ne sont pas obligés de supporter cette extension. Cependant, les implémentations qui ne supportent pas cette extension doivent soit traiter le statut des certificats non listés dans cette CRL comme inconnu ou localiser une autre CRL qui ne contient pas d'extensions critique non-reconnues.

   La CRL est signée en utilisant la clé privée du fournisseur. Les points de distribution de CRL n'ont pas leur propre paires de clé. Si la CRL est stockée dans un annuaire X.500, elle est stockée dans l'entrée d'annuaire correspondant au point de distribution e CRL, qui peut être différent de l'entrée d'annuaire du fournisseur de CRL.

   Les codes de raison associées avec un point de distribution doivent être spécifiés dans onlySomeReasons. Si onlySomeReasons n'apparaît pas, le point de distribution doit contenir les révocation pour tous les codes de raison. Les CA peuvent utiliser les points de distribution de CRL pour partitionner la CRL sur la base de révocation de routine et de compromission. Dans ce cas, les révocations avec le code de raison keyCompromise, cACompromise, et aACompromise apparaissent dans un point de distribution, et les révocations avec d'autres codes de raison apparaissent dans un autre point de distribution.

   Si une CRL inclus une extension issuingDistributionPoint avec onlySomeReasons présent, alors tout certificat dans le scope de la CRL qui est révoqué doit être assigné à un code de raison autre qui unspecified. La raison de révocation assignées est utilisée pour déterminer dans quelle CRL lister le certificat révoqué, cependant, il n'est pas requis d'inclure l'extension d'entrée de CRL reasonCode dans l'entrée de CRL correspondant.

   La syntaxe et les sémantiques pour le champ distributionPoint sont les même que pour le champ distributionPoint dans l'extension cRLDistributionPoints. Si le champ distributionPoint est présent, alors il doit inclure au moins un des noms du distributionPoint correspondant de l'extension cRLDistributionPoints de tout certificat qui est dans le scope de cette CRL. L'encodage identique doit être utilisé dans les champs distributionPoint du certificat et de la CRL.

   Si le champ distributionPoint est absent, le CRL doit contenir des entrées pour tous les certificats révoqués non-expirés fournis par le fournisseur de CRL, dans le scope de la CRL.

   Si le scope de la CRL inclus uniquement les certificats émis par le fournisseur de CRL, alors le booléen indirectCRL doit être FALSE. Sinon, si le scope de la CRL inclus des certificats fournis par une ou plusieurs autres autorités, indirectCRL doit être à TRUE. L'autorité responsable pour chaque entrée est indiquée par le fournisseur de certificat de l'extension d'entrée de CRL.

   Si le scope de la CRL inclus uniquement des certificats à clé publique d'entité final, alors onlyContainsUserCerts doit être à TRUE. Si le scope de la CRL inclus seulement des certificats CA, alors onlyContainsCACerts doit être à TRUE. Si onlyContainsUserCerts ou onlyContainsCACerts est à TRUE, alors le scope de la CRL ne doit pas inclure de certificats version 1 ou version 2. Les fournisseurs de CRL conformes doivent définir le booléen onlyContainsAttributeCerts à FALSE.

   Les fournisseurs de CRL conformes ne doivent pas émettre de CRL où l'encodage DER de l'extension de point de distribution du fournisseur est une séquence vide. C'est à dire que si onlyContainsUserCerts, onlyContainsCACerts, indirectCRL, et onlyContainsAttributeCerts sont à FALSE, alors soit le champ distributionPoint soit le champ onlySomeReasons doit être présent.

id-ce-issuingDistributionPoint OBJECT IDENTIFIER ::= { id-ce 28 }

IssuingDistributionPoint ::= SEQUENCE {
    distributionPoint [0] DistributionPointName OPTIONAL,
    onlyContainsUserCerts [1] BOOLEAN DEFAULT FALSE,
    onlyContainsCACerts [2] BOOLEAN DEFAULT FALSE,
    onlySomeReasons [3] ReasonFlags OPTIONAL,
    indirectCRL [4] BOOLEAN DEFAULT FALSE,
    onlyContainsAttributeCerts [5] BOOLEAN DEFAULT FALSE }

     -- au moins un parmis onlyContainsUserCerts, onlyContainsCACerts, et onlyContainsAttributeCerts doit être à TRUE.

Freshest CRL

   L'extension freshest CRL identifie comment les informations de CRL delta pour cette CRL complète est obtenue. Les fournisseurs conformes doivent marquer cette extension non-critique. Cette extension ne doit pas apparaître dans les CRL delta.

   La même syntaxe est utilisée pour cette extension que dans l'extension de certificat cRLDistributionPoints. Cependant, seul le champ de point de distribution est significatif dans ce contexte. Les champs raison et cRLIssuer doivent être omis de cette extension de CRL.

Chaque nom de point de distribution fournis l'emplacement auquel une CRL delta pour cette CRL complète peut être trouvée. Le scope de ces CRL delta doit être le même que le scope de la CRL complète. Le contenu de cette extension de CRL est seulement utilisé pour localiser les CRL delta; le contenu n'est pas utilisé pour valider la CRL ou les CRL delta.
id-ce-freshestCRL OBJECT IDENTIFIER ::= { id-ce 46 }

    FreshestCRL ::= CRLDistributionPoints

Authority Information Access

   Cette section définis l'utilisation de l'extension d'accès aux informations d'autorité dans une CRL. La syntaxe et les sémantiques définis pour l'extension de certificat du même nom sont également utilisé pour l'extension de CRL. Cette extension de CRL doit être marquée non-critique.

   Quand présent dans une CRL, cette extension doit inclure au moins un AccessDescription spécifiant l'id-ad-caIssuers comme accessMethod. L'OID id-ad-caIssuers est utilisé quand l'information disponible liste les certificats qui peuvent être utilisés pour vérifier la signature dans la CRL (par exemple, les certificats qui ont un nom de sujet qui correspond à la clé privée utilisé pour signer la CRL). Les types de méthode d'accès autre que id-ad-caIssuers ne doivent pas être inclus. Au moins une instance de AccessDescription devrait spécifier un URI accessLocation HTTP ou LDAP.

   Quand l'information est disponible via HTTP ou FTP, accessLocation doit être un uniformResourceIdentifier et l'URI doit pointer vers soit un simple certificat encodé DER soit une collection de certificats dans une message CMS "certs-only" encodé en DER ou BER.

   Les applications conformes qui supportent HTTP ou FTP pour accéder aux certificats doivent être capable d'accepter les certificats individuels encodés DER et devraient être capable d'accepter les messages CMS "certs-only".

   Les implémentations de serveurs HTTP accédés via l'URI devraient spécifier le type de média application/pkix-cert dans le champ dans le champ d'en-tête content-type de la réponse pour un simple certificat encodé DER et devraient spécifier le type de média application/pkcs7-mime dans le champ d'en-tête content-type de la réponse pour les message CMS "certs-only". Pour FTP, le nom d'un fichier qui contient un simple certificat encodé DER devrait avoir un suffix ".cer" et le nom d'un fichier qui contient un message CMS "certs-only" devrait avoir le suffix ".p7c". Les client peuvent utiliser le type de média ou l'extension de fichier comme indicateur de contenu, mais ne devraient pas s'en contenter.

   Quand accessLocation est un directoryName, l'information est obtenu par l'application via le serveur configuré localement. Quand une clé publique de CA est utilisée pour valider les signatures dans les certificats et CRL, le certificat de CA désiré est stocké dans les attributs crossCertificatePair et/ou cACertificate. quand différentes clé publique sont utilisées pour valider les signatures dans les certificats et les CRL, le certificat désiré est stocké dans l'attribut userCertificate. Donc, les implémentations qui supportent la forme directoryName de accessLocation doivent être préparés à trouver le certificat nécessaire dans n'importe lequel de ces attributs. Le protocole qu'une application utilise pour accéder à l'annuaire est un choix local.

   Quand les informations sont disponibles via LDAP, accessLocation devrait être un uniformResourceIdentifier. L'URI LDAP doit inclure un champ dn contenant de nom distinct de l'entrée maintenant les certificats, doit inclure un champ attributes qui liste les descriptions d'attributs appropriés pour les attributs qui maintiennent les certificats encodés DER ou les paires de cross-certificats, et devrait inclure un hôte (ex: ‹ldap://ldap.example.com/cn=CA,dc=example,dc=com?cACertificate;binary,crossCertificatePair;binary›). Omettre l'hôte (ex: ‹ldap:///cn=exampleCA,dc=example,dc=com?cACertificate;binary›) implique que le client connaisse le serveur approprié à contacter.

CRL Entry Extensions

Les extensions d'entrée de CRL définis par l'ISO/IEC, ITU-T, et ANSI X9 pour les CRL X.509 v2 fournissent des méthodes pour associer des attributs additionnels avec des entrées de CRL. Le format de CRL X.509 v2 permet également aux communautés de définir des extensions d'entrée de CRL privées pour gérer les informations spécifiques de ces communautés. Chaque extension dans une entrée de CRL peut être désignée comme critique ou non. Si une CRL contient une extension d'entrée de CRL critique qui l'application ne peut pas traiter, alors l'application ne doit pas utiliser cette CRL pour déterminer le statut des certificats. Cependant, les applications peuvent ignorer les extensions d'entrées de CRL non-critique non reconnus.

Le support pour les extensions d'entrée de CRL définis dans cette spécification est optionnel pour les fournisseurs de CRL et les applications conformes. Cependant, les fournisseurs de CRL devraient inclure des codes de raison et des dates d'invalidité quand cette information est disponible.

Reason Code

   Le reasonCode est une extension d'entrée de CR non-critique qui identifie la raison pour la révocation du certificat. Les fournisseurs de CRL sont fortement encouragés à inclure des codes de raison significatifs dans les entrées de CRL. Cependant, l'extension d'entrée de CRL de code de raison devrait être absent au lieu d'utiliser la valeur reasonCode unspecified.

   La valeur de reasonCode removeFromCRL peut seulement apparaître dans les CRL delta, et indique qu'un certificat à été supprimé de la CRL soit parce qu'il a expiré, soit parce qu'il n'est plus en attente. Toutes les autres raisons peuvent apparaître dans les CRL et indique que le certificat spécifié devrait être considéré révoqué.

id-ce-cRLReasons OBJECT IDENTIFIER ::= { id-ce 21 }

    -- reasonCode ::= { CRLReason }

CRLReason ::= ENUMERATED {
    unspecified (0),
    keyCompromise (1),
    cACompromise (2),
    affiliationChanged (3),
    superseded (4),
    cessationOfOperation (5),
    certificateHold (6),
    -- La valeur 7 n'est pas utilisée
    removeFromCRL (8),
    privilegeWithdrawn (9),
    aACompromise (10) }

Invalidity Date

La date d'invalidité est une extension d'entrée de CRL non-critique qui fournis la date à laquelle on sait, ou on suspecte qui la clé privée a été compromise ou que le certificat est devenu invalide. Cette date peut être antérieur à la date de révocation dans l'entrée de CRL, qui est la date à laquelle la CA a procédé à la révocation. Quand une révocation est postées d'abord par un fournisseur de CRL dans une CRL, la date d'invalidité peut précéder la date d'émission des premières CRL, mais la date de révocation ne devrait pas précéder la date d'émission des premières CRL. Quand cette information est disponible, les fournisseurs de CRL sont fortement encouragés à la partager avec les utilisateurs de CRL.

Les valeurs GeneralizedTime inclus dans ce champ doit être exprimés en GMT, et doivent être spécifiés et interprétés comme définis dans la section "GeneralizedTime".
id-ce-invalidityDate OBJECT IDENTIFIER ::= { id-ce 24 }

InvalidityDate ::= GeneralizedTime

Certificate Issuer

   Cette extension d'entrée de CRL identifie le fournisseur de certificat associé avec une entrée dans une CRL indirecte, c'est à dire, une CRL qui a l'indicateur indirectCRL mis dans sont extension de point de distribution d'émission. Quand présent, l'extension d'entrée de CRL de fournisseur de certificat inclus un ou plusieurs noms du champ issuer et/ou de l'extension de noms alternatif du sujet du certificat qui correspond à l'entrée de la CRL. Si cette extension n'est pas présente dans la première entrée dans une CRL indirecte, le fournisseur de certificat par défaut est le fournisseur de CRL. Dans les entrées suivantes, si cette extension n'est pas présente, le fournisseur de certificat pour l'entrée est la même que pour l'entrée précédente. Ce champ est définis comme suit:

id-ce-certificateIssuer OBJECT IDENTIFIER ::= { id-ce 29 }

CertificateIssuer ::= GeneralNames

   Les fournisseurs de CRL conformes doivent inclure dans cette extension le dn du champ issuer du certificat qui correspond à cette entrée de CRL. L'encodage du DN doit être identique à l'encodage utilisé dans le certificat.

   Les fournisseurs de CRL doivent marquer cette extension critique vu que l'implémentation qui ignore cette extension ne peut pas correctement attribuer les entrées de CRL aux certificats. Cette spécification recommande que les implémentations reconnaissent cette extension.

Validation de chemin de certification

   Les procédures de validation de chemin de certification pour les PKI de l'Internet sont basés sur l'algorithme fournis dans X.509. Le traitement des chemins de certification vérifie la liaison entrée le nom distinct du sujet et/ou le nom alternatif du sujet et la clé publique du sujet. La liaison est limitée par les contraintes qui sont spécifiées dans les certificats qui comprennent le chemin et les entrées qui sont spécifiés par les tiers de confiance. Les extensions de contraintes de base et de contraintes de stratégie permettent à la logique de traitement de chemin de certification d'automatiser le processus de prise de décision.

   Cette section décris un algorithme pour valider les chemins de certification. Les implémentations conformes de cette spécification ne sont pas obligés d'implémenter cet algorithme, mais doivent fournir une fonctionnalité équivalente au fonctionnement résultant de cette procédure. Tout algorithme peut être utilisé par une implémentation particulière tant qu'elle dérive le résultat correcte.

   Dans la section suivante, le texte décris la validation basique de chemin . Les chemins valides commencent avec des certificats fournis par une entité de confiance. L'algorithme nécessite la clé publique de la CA, le nom de la CA, et toutes les contraintes sur le jeu de chemins qui peuvent être validés en utilisant cette clé.

   La sélection d'une entité de confiance est une décision de stratégie locale: il peut être le CA supérieur dans une PKI hiérarchique, la CA qui a fournis le certificat du vérificateur, ou toute autre CA dans le réseau PKI. La procédure de validation de chemin est la même quelque soit l'entité de confiance. En plus, différentes applications peuvent faire confiance à plusieurs entités, ou peuvent accepter des chemins qui commencent avec un jeu d'entité de confiance.

Validation de chemin basique

   Ce texte décris un algorithme pour le traitement de chemin X.509. Une implémentation conforme doit inclure une procédure de traitement de chemin X.509 qui est fonctionnellement équivalente à la sortie de cet algorithme. Cependant, le support pour certains extensions de certificat traités dans cet algorithme sont optionnels pour les implémentations conformes. Les clients qui ne supportent pas ces extensions peuvent omettre les étapes correspondantes dans l'algorithme de validation de chemin.

   Par exemple, les clients ne sont pas obligés de supporter l'extension de mappage de stratégie. Les clients qui ne supportent pas cette extension peuvent omettre les étapes de validation de chemin où le traitement du policy mappings sont traités. Noter que les clients doivent rejeter le certificat s'il contient une extension critique non-supportée.

   Bien que les profiles de certificat et de CRL spécifiés dans ce document spécifient des valeurs pour les champs et les extensions de certificat et de CRL considérés appropriés pour les PKI de l'Internet, l'algorithme présenté dans cette section n'est pas limité à accepter les certificats et CRL qui se conforment à cet profiles. Cependant, l'algorithme inclus uniquement les vérifications de chemint de certification valide en accord avec X.509 et n'inclus pas les vérifications de conformité des certificats et CRL avec ce profile. Bien que l'algorithme pourrait être étendu pour inclure des vérifications de conformité avec les profiles de ce document, ce profile recommande de ne pas inclure de telles vérification.

   L'algorithme présenté dans cette section valide le certificat en respectant l'horodatage courant. Un application conforme peut également supporter la validation en respectant un point dans le passé. Noter que les mécanismes ne sont pas disponible pour valider un certificat en dehors de sa période de validité.

   L'entité de confiance est une entrée de l'algorithme. Il n'y a pas d'obligation que la même entité de confiance soit utilisée pour valider tous les chemins de certification. Plusieurs entités de confiance peuvent être utilisés pour valider différents chemins.

   Le but premier de la validation de chemin est de vérifier le lien entre un nom distinct du sujet ou un nom alternatif du sujet et la clé publique du sujet, tel que représenté dans le certificat cible, basé sur la clé publique de l'entité de confiance. Dans la plupart des cas, le certificat cible sera un certificat d'entité finale, mais le certificat cible peut être un certificat de CA tant que la clé publique du sujet est utilisée dans un but autre que vérifier la signature dans certificat à clé publique. Vérifier le lien entre le nom et la clé publique nécessite d'obtenir une séquence de certificats qui supportent ce lien. La procédure effectuée pour obtenir cette séquence de certificat est hors du scope de cette spécification.

   Dans ce but, le processus de validation de chemin vérifie, entre autre, qu'un chemin de certification éventuel ( une séquence de n certificats ) satisfait les conditions suivantes:

(a) Pour tout x dans { 1, ..., n-1 }, le sujet des certificats x est le fournisseur du certificat x+1
(b) le certificat 1 est fournis par l'entité de confiance
(c) Le certificat n est le certificat à valider
(d) Pour tout x dans { 1, ..., n }, le certificat était valide à l'époque en question

   Un certificat ne doit pas apparaître plus d'une fois dans une chemin de certification éventuel.

   Quand l'entité de confiance est fournis sous la forme d'un certificat auto-signé, ce certificat n'est pas inclus comme partie du chemin de validation éventuel. Les informations sur l'entité de confiance est fournis en entrée de l'algorithme de validation de chemin de certification.

   Un chemin de validation de certification particulier ne peut pas, cependant, être approprié pour toutes les applications. Une application peut augmenter cet algorithme pour limiter le jeu de stratégie de certificat qui sont valides pour ce chemin, basé sur l'extension de stratégies de certificat, l'extension de mappage de stratégie, l'extension de contraintes de stratégie, et inhiber l'extension anyPolicy. Pour accomplir cela, l'algorithme de validation de chemin construit une arborescence de stratégie valide. Si le jeu de stratégies de certificat qui sont valides pour ce chemin n'est pas vide, alors le résultat sera une arborescence de stratégie valide de profondeur n, sinon le résultat sera une arborescence de stratégie valide null.

   Un certificat est auto-fournis si le même DN apparaît dans les champs sujets et fournisseur. En général, le fournisseur et le sujet des certificat qui constituent un chemin sont différents pour chaque certificat. Cependant, une CA peut fournir un certificat à elle-même pour supporter le changement de clé ou de stratégies de certificat. Ces certificats auto-fournis ne sont pas comptés dans l'évaluation de la longueur de chemin ou les contraintes de nom.

   Cette section présente l'algorithme en 4 étapes de base: initialisation, traitement de certificats de base, préparation pour le certificat suivant, et la conclusion. Les étapes 1 et 4 sont effectuées exactement 1 seule fois, l'étape 2 est effectuée pour tous les certificats dans le chemin, et l'étape 3 est effectuée pour tous les certificats dans le chemin excepté le certificat final. La figure suivante fournis une vue générale de cet algorithme:

___________________________+- - - -+
___________________________|_START_|
___________________________+- - - -+
_______________________________|
_______________________________V
_______________________+- - - - - - - - +
_______________________|_Initialization_|
_______________________+- - - - - - - - +
_______________________________|
_______________________________+‹- - - - - - - - - - +
_______________________________|_____________________|
_______________________________V_____________________|
_______________________+- - - - - - - - +____________|
_______________________|__Process_Cert__|____________|
_______________________+- - - - - - - - +____________|
_______________________________|_____________________|
_______________________________V_____________________|
_______________________+================+____________|
_______________________|__IF_Last_Cert__|____________|
_______________________|____in_Path_____|____________|
_______________________+================+____________|
_________________________|____________|______________|
____________________THEN_|____________|_ELSE_________|
_________________________V____________V______________|
______________+- - - - - - - - +_+- - - - - - - - +__|
______________|____Wrap_up_____|_|__Prepare_for___|__|
______________+- - - - - - - - +_|___Next_Cert____|__|
______________________|__________+- - - - - - - - +__|
______________________V_______________|______________|
__________________+- - - -+___________+- - - - - - - +
__________________|_STOP__|
__________________+- - - -+

Entrées

Cet algorithme assume que les 9 entrées suivantes sont fournis au traitement de chemin:

(a) Une chemin de certification éventuel de longueur n
(b) La date et heure courante
(c) user-initial-policy-set, nommant les stratégies qui sont acceptables pour l'utilisateur de certificat. Le user-initial-policy-set contient la valeur spéciale any-policy si l'utilisateur n'est pas concerné par les stratégies de certificat.
(d) Informations de l'entité de confiance qui incluent:

(1) Le nom du fournisseur de confiance
(2) L'algorithme de clé publique de confiance
(3) La clé publique de confiance
(4) Optionnellement, les paramètres de clé publique associés à la clé publique.

Les informations de l'entité de confiance peuvent être fournis à la procédure de traitement de chemin sous la forme d'un certificat auto-signé. Quand les information de l'entité de confiance sont fournies sous la fourme d'un certificat, le nom dans le champ subject est utilisé comme nom de fournisseur de confiance et le contenu du champ subjectPublicKeyInfo est utilisé comme source de l'algorithme de clé publique de confiance et la de clé publique de confiance. Les informations d'entité de confiance sont de confiance parce qu'elles ont été délivrées à la procédure de traitement de chemin par une procédure digne de confiance. Si l'algorithme de clé publique de confiance nécessite des paramètres, alors les paramètres sont fournis avec la clé publique de confiance.

(e) initial-policy-mapping-inhibit, qui indique si le mappage de stratégie est permis dans le chemin de certification.
(f) initial-explicit-policy, qui indique si le chemin doit être valide pour au moins une des stratégie de certificat dans le user-initial-policy-set.
(g) initial-any-policy-inhibit, qui indique si l'OID anyPolicy devrait être traité s'il est inclus dans un certificat
(h) initial-permitted-subtrees, qui indique pour chaque type de nom un jeu de sous-arborescences dans lequel tous les noms du sujet dans tous les certificats dans le chemin de certification doivent aller. Cette entrée doit inclure un jeu pour chaque type de nom. Pour chaque type de nom, le jeu peut consister d'une simple sous-arborescence qui inclus tous les noms de ce type de nom ou une ou plusieurs sous-arborescence qui chacune spécifie un sous-jeu de noms de ce type de nom, ou le jeu peut être vide. Si le jeu pour un type de nom est vide, alors le chemin de certification sera considéré invalide dans tous les certificats dans le chemin de certification qui inclus un nom de ce type de nom.
(i) initial-excluded-subtrees, qui indique pour chaque type de nom un jeu de sous-arborescence dans lequel aucun nom du sujet dans les certificats du chemin de certification ne peut aller. Cette entrée inclus un jeu pour chaque type de nom. Pour chaque type de nom, le jeu peut être vide ou peut consister d'une ou plusieurs sous-arborescences qui spécifient chacun un sous-jeu des noms de ce type de nom. Si le jeu pour un type de nom est vide, aucun nom de ce type de nom n'est exclus.

Initialization

   Cette phase d'initialisation établis 11 variables d'état basés sur les 9 entrées:

(a) valid_policy_tree: Une arborescence de stratégies de certificats avec leurs qualifiants optionnels; chaque branche de l'arborescence représente une stratégie valide à ce stade de la validation du chemin de certification. Si des stratégie valides existent à ce stade dans la validation du chemin de certification, la profondeur de l'arbre est égal au nombre de certificats dans la chaîne qui a été traitée. Si des stratégies valides n'existent pas à ce stade, l'arbre est null. Une fois l'arbre mis à NULL, le traitement de stratégie s'arrête.

(1) valid_policy est un simple OID de stratégie représentant une stratégie valide pour le chemin de longueur x.
(2) qualifier_set est un jeu de qualifiants de stratégie associés avec la stratégie valide dans le certificat x.
(3) expected_policy_set contient un ou plusieurs OID de stratégie qui satisferait cette stratégie dans le certificat x+1.

   La valeur initiale de valid_policy_tree est un nœud simple avec pour valid_policy anyPolicy, un qualifier_set vide, et un expected_policy_set avec la seule valeur anyPolicy. Ce nœud a une profondeur de 0.

La figure suivante est une représentation graphique de l'état initial de valid_policy_tree. Les figures additionnelles vont utiliser ce format pour décrire les changement dans le valid_policy_tree durant le traitement du chemin.
______________+- - - - - - - - +
______________|___anyPolicy____|___‹- - _valid_policy
______________+- - - - - - - - +
______________|_______{}_______|___‹- - _qualifier_set
______________+- - - - - - - - +
______________|__{anyPolicy}___|___‹- - _expected_policy_set
______________+- - - - - - - - +

(b) permitted_subtrees: un jeu de noms racine pour chaque type de nom définissant un jeu de sous-arborescence dans lequel tous les noms du sujet dans les certificats suivant dans le chemin de certificat doivent tomber. Cette variable inclus un jeu pour chaque type de nom, et la valeur initiale est initial-permitted-subtrees.
(c) excluded_subtrees: un jeu de noms racines pour chaque type de nom définissant un jeu de sous-arborescence dans lequel aucun nom du sujet dans les certificats suivant dans le chemin de certification ne peut tomber. Cette valiable inclus un jeu pour chaque type de nom, et la valeur initiale est initial-excluded-subtrees.
(d) explicit_policy: Un entier qui indique si un valid_policy_tree non-null est requis. L'entier indique le nombre de certificats non auto-fournis à traiter avant que ce requis soit imposé. Une fois définis, cette variable peut être décrémentée, mais ne peut pas être incrémentée. C'est à dire, si un certificat dans le chemin requière un valid_policy_tree non-null, un certificat ultérieur ne peut pas supprimer ce requis. Si initial-explicit-policy est mis, alors la valeur initiale est 0, sinon la valeur initiale est n+1.
(e) inhibit_anyPolicy: un entier qui indique si l'identifiant de stratégie anyPolicy est considéré comme un match. L'entier indique le nombre de certificats non auto-fournis à traiter avant que l'OID anyPolicy, si indiqué dans un certificat autre qu'un certificat intermédiaire auto-fournis, est ignoré. Une fois mis, cette variable peut être décrémentée, mais ne peut pas être incrémentée. C'est à dire, si un certificat dans le chemin inhibe le traitement de anyPolicy, un certificat ultérieur ne peut pas le permettre. Si initial-any-policy-inhibit est mis, alors la valeur initial est 0, sinon la valeur initial est n+1.
(f) policy_mapping: un entier qui indique si le mappage de stratégie est permis. L'entier indique le nombre de certificat non auto-fournis à traiter avant que le mappage de stratégie soit inhibé. Une fois mis, cette variable peut être décrémentée, mais ne peut pas être incrémenté. C'est à dire,, si un certificat dans le chemin spécifie que le mappage de stratégie n'est pa permis, il ne peut pas écrasé par un certificat ultérieur. Si initial-policy-mapping-inhibit est mis, la valeur initiale est 0, sinon la valeur est n+1.
(h) working_public_key: La clé publique utilisée pour vérifier la signature d'un certificat. working_public_key est initialiée depuis la clé publique de confiance fournis dans les informations de l'entité de confiance.
(i) working_public_key_parameters: Les paramètres associés avec la clé publique courante qui peut être requise pour vérifier une signature ( en fonction de l'algorithme). working_public_key_parameters est initialisée avec les paramètres de clé publique de confiance fournis dans les informations de l'entité de confiance.
(j) working_issuer_name: Le dn du fournisseur prévu dans le prochain certificat dans la chaîne. working_issuer_name est initialisé avec le dn du founisseur fournis la les informations de l'entité de confiance.
(k) max_path_length: Cet entier est initialisé à n, est décrémenté pour chaque certificat non auto-fournis dans le chemin, et peut être réduit à la valeur dans le champ de contrainte de longueur de chemin dans l'extension de contraintes de base d'un certificat de CA.

   Une fois ces étapes d'initialisation complétées, effectue les étapes de traitement de certificat de base.

Traitement de certificat de base

Les actions de traitement de chemin de base à effectuer pour le certificat i ( pour tout i dans [1..n] ) sont les suivantes:

(a) Vérifie les informations de certificat de base. Le certificat doit satisfaire chacun des points suivants:

(1) La signature dans le certificat peut être vérifié en utilisant working_public_key_algorithm, working_public_key, et working_public_key_parameters.
(2) La période de validité du certificat inclus l'heure courante
(3) Actuellement, le certificat n'est pas révoqué. Cela peut être déterminé en obtenant le CRL appropriée, par information de statut, ou par des mécanismes tiers.
(4) Le nom du fournisseur de certificat est le working_issuer_name.

(b) Si le certificat i est auto-fournis et n'est pas le certificat final dans le chemin, saute cette étape pour le certificat i. Sinon, vérifie que le nom du sujet est dans un des permitted_subtrees pour les noms distincts X.500, et vérifie que chaque noms alternatifs dans l'extension subjectAltName (critique ou non-critique) est dans un des permitted_subtrees pour ce type de nom.
(c) Si le certificat i est auto-fournis et n'est pas le certificat final dans le chemin, saute cette étape pour le certificat i. Sinon, vérifie que le nom du sujet n'est pas dans le excluded_subtrees pour les noms distincts X.500, et vérifie que chaque noms alternatifs n'est pas dans un des excluded_subtrees pour ce type de nom.
(d) Si l'extension de stratégies de certificats est présent dans le certificat et le valid_policy_tree n'est pas null, traite les information de stratégie en effectuant les étapes suivantes dans l'ordre:

(1) Pour chaque stratégie P non égal à anyPolicy dans l'extension de stratégie de certificat, P-OID dénote l'OID pour la stratégie P et P-Q dénote le jeu de qualifiant pour la stratégie P. Effectue les étapes suivantes dans l'ordre:

(i) Pour chaque nœud de profondeur i-1 dans le valid_policy_tree où P-OID est dans le expected_policy_set, crée un nœud enfant comme suit: définis valid_policy à P-OID, définis qualifier_set à P-Q, et définis expected_policy_set à {P-OID}.

Par exemple, considérons un valid_policy_tree avec un nœud de profondeur i-1 où expected_policy_set est {Gold, White}. Les stratégies de certificat Gold et Silver apparaissent dans l'extension de stratégie de certificat du certificat i. La stratégie Gold est matchée, mais la stratégie Silver ne l'est pas. Cette règle va générer un nœud enfant de profondeur i pour la stratégie Gold:
_____________________________+- - - - - - - - -+
_____________________________|_______Red_______|
_____________________________+- - - - - - - - -+
_____________________________|_______{}________|
_____________________________+- - - - - - - - -+___node_of_depth_i-1
_____________________________|__{Gold,_White}__|
_____________________________+- - - - - - - - -+
______________________________________|
______________________________________|
______________________________________|
______________________________________V
_____________________________+- - - - - - - - -+
_____________________________|______Gold_______|
_____________________________+- - - - - - - - -+
_____________________________|_______{}________|
_____________________________+- - - - - - - - -+___node_of_depth_i
_____________________________|_____{Gold}______|
_____________________________+- - - - - - - - -+

(ii) S'il n'y avait pas de correspondance dans l'étape (i) et valid_policy_tree incluais un nœud de profondeur i-1 avec valid_policy anyPolicy, génère un nœud enfant avec les valeurs suivantes: définis valid_policy à P-OID, définis qualifier_set à P-Q, et définis expected_policy_set à {P-OID}.

Par exemple, considérons un valid_policy_tree avec un nœud de profondeur i-1 où valid_policy est anyPolicy. Les stratégie de certificat Gold et Silver apparaîssent dans l'extension de stratégies de certificat du certificat i. La stratégie Gold n'a pas de qualifiant, mais la stratégie Silver a le qualifiant Q-Silver. Si Gold et Silver ne correspondent pas dans (i), cette règle va générer 2 nœuds enfants de profondeur i, une pour chaque stratégie:
__________________________________+- - - - - - - - -+
___________________________________|____anyPolicy____|
___________________________________+- - - - - - - - -+
___________________________________|_______{}________|
___________________________________+- - - - - - - - -+_node_of_depth_i-1
___________________________________|___{anyPolicy}___|
___________________________________+- - - - - - - - -+
______________________________________/___________\
_____________________________________/_____________\
____________________________________/_______________\
___________________________________/_________________\
_____________________+- - - - - - - - -+__________+- - - - - - - - -+
_____________________|______Gold_______|__________|_____Silver______|
_____________________+- - - - - - - - -+__________+- - - - - - - - -+
_____________________|_______{}________|__________|___{Q-Silver}____|
_____________________+- - - - - - - - -+_nodes_of_+- - - - - - - - -+
_____________________|_____{Gold}______|_depth_i__|____{Silver}_____|
_____________________+- - - - - - - - -+__________+- - - - - - - - -+

(2) Si l'extension de stratégies de certificat inclus la stratégie anyPolicy avec le qualifiant AP-Q et soit (a) inhibit_anyPolicy est plus grand que 0 ou (b) i‹n et le certificat est auto-fournis, alors: Pour chaque nœud dans valid_policy_tree de profondeur i-1, pour chaque valeur dans expected_policy_set (inclant anyPolicy) qui n'apparaît pas dans un nœud enfant, crée un nœud enfant avec les valeurs suivantes: définis valid_policy à la valeur de expected_policy_set dans le nœud parent, définis qualifier_set à AP-Q, et définis expected_policy_set à la valeur dans valid_policy de ce nœud.

Par exemple, considérons un valid_policy_tree avec un nœud de profondeur i-1 où expected_policy_set est {Gold, Silver}. anyPolicy apparaît dans l'extension de stratégie de certificat i sans qualifiant de stratégie, mais Gold et Silver n'apparaît pas. Cette règle va générer 2 nœuds enfant de profondeur i, une pour chaque stratégie:
_______________________________+- - - - - - - - -+
_______________________________|______Red________|
_______________________________+- - - - - - - - -+
_______________________________|_______{}________|
_______________________________+- - - - - - - - -+_node_of_depth_i-1
_______________________________|__{Gold,_Silver}_|
_______________________________+- - - - - - - - -+
__________________________________/___________\
_________________________________/_____________\
________________________________/_______________\
_______________________________/_________________\
_________________+- - - - - - - - -+__________+- - - - - - - - -+
_________________|______Gold_______|__________|_____Silver______|
_________________+- - - - - - - - -+__________+- - - - - - - - -+
_________________|_______{}________|__________|_______{}________|
_________________+- - - - - - - - -+_nodes_of_+- - - - - - - - -+
_________________|_____{Gold}______|_depth_i__|____{Silver}_____|
_________________+- - - - - - - - -+__________+- - - - - - - - -+

(3) S'il y a un nœud dans valid_policy_tree de profondeur i-1 ou moins sans nœud enfant, supprime ce nœud. Répète cette étape jusqu'à ce qu'il n'y ait plus de nœud de profondeur i-1 ou moins dans enfant. Par exemple, on considère valid_policy_tree ci-dessous. Les 2 nœuds à la profondeur i-1 qui sont marqués avec un 'X' n'ont pas d'enfant, et sont supprimés. Appliquer cette règle à l'arbre résultant va cause le nœud à la profondeur i-2 qui est marqué avec un 'Y' d'être supprimé. Dans l'arbre résultant, il n'y a pas de nœuds de profondeur i-1 ou moins dans enfant, et cette étape est complète.

(e) Si l'extension de stratégies de certificat n'est pas présent, définis valid_policy_tree à NULL.
(f) Vérifie que soit explicit_policy est supérieur à 0 soit valid_policy_tree n'est pas égal à NULL

Si une des étapes (a), (b), (c), ou (f) échoue, la procédure se termine, retournant une erreur indiquant un raison appropriée.

Si i n'est pas égal à n, continue en effectuant le étapes préparatoires listées dans la section suivante. Si i est égal à f, effectue les étapes listés dans la section d'après.
_________________________________+- - - - - -+
_________________________________|___________|_node_of_depth_i-3
_________________________________+- - - - - -+
_________________________________/_____|_____\
________________________________/______|______\
_______________________________/_______|_______\
___________________+- - - - - -+_+- - - - - -+_+- - - - - -+
___________________|___________|_|___________|_|_____Y_____|_nodes_of
___________________+- - - - - -+_+- - - - - -+_+- - - - - -+_depth_i-2
___________________/___\_______________|_____________|
__________________/_____\______________|_____________|
_________________/_______\_____________|_____________|
______+- - - - - -+_+- - - - - -+_+- - - - - -+_+- - - - - -+_nodes_of
______|___________|_|_____X_____|_|___________|_|____X______|__depth
______+- - - - - -+_+- - - - - -+_+- - - - - -+_+- - - - - -+___i-1
____________|______________________/____|____\
____________|_____________________/_____|_____\
____________|____________________/______|______\
______+- - - - - -+_+- - - - - -+_+- - - - - -+_+- - - - - -+_nodes_of
______|___________|_|___________|_|___________|_|___________|__depth
______+- - - - - -+_+- - - - - -+_+- - - - - -+_+- - - - - -+___i

Préparation pour le certificat i+1

   Pour préparer le traitement du certificat i+1, effectuer les étapes suivantes pour le certificat i:

(a) Si une extension de mappage de stratégie est présente, vérifie que la valeur spéciale anyPolicy n'apparaît pas comme un issuerDomainPolicy ou un subjectDomainPolicy.
(b) Si une extension de mappage de stratégie est présente, pour chaque issuerDomainPolicy ID-P dans l'extension de mappage de stratégie:

(1) Si la variable policy_mapping est supérieur à 0, pour chaque nœud dans valid_policy_tree de profondeur i où ID-P est le valid_policy, définis expected_policy_set au jeu de valeurs subjectDomainPolicy qui sont spécifiées comme équivalent à ID-P par l'extension de mappage de stratégie.
Si aucun nœud de profondeurs i dans valid_policy_tree n'a un valid_policy à anyPolicy, génère un nœud enfant du nœud de profondeur i-1 qui a un valid_policy de anyPolicy comme suit:

(i) Définis valid_policy à ID-P
(ii) Définis qualifier_set au jeu de qualifiant de stratégie anyPolicy dans l'extension de stratégie de certificat du certificat i
(iii) Définis expected_policy_set au jeu de valeurs subjectDomainPolicy qui sont spécifiés comme équivalent à ID-P par l'extension de mappage de stratégie.

(2) Si policy_mapping est égal à 0:

(i) Supprime chaque nœud de profondeur i dans valid_policy_tree où ID-P est le valid_policy
(ii) S'il y a un nœud dans valid_policy_tree de profondeur i-1 ou moins sans nœud enfant, supprime ce nœud. Répète cette étape jusqu'à ce qu'il n'y ait plus de nœuds de profondeur i-1 ou moins sans enfant.

(c) Assigne le nom du sujet du certificat au working_issuer_name
(d) Assigne le subjectPublicKey du certificat au working_public_key
(e) Si le champ subjectPublicKeyInfo du certificat contient un champ algorithme avec des paramètres non-null, assigne les paramètres à la variable working_public_key_parameters. Si le champ subjectPublicKeyInfo du certificat contient un champ algorithme avec des paramètres null ou les paramètres sont omis, compare l'algorithme subjectPublicKey au working_public_key_algorithm. Si l'algorithme subjectPublicKey du certificat et le working_public_key_algorithm sont différent, définis working_public_key_parameters à null.
(f) Assigne l'algorithme de subjectPublicKey du certificat à la variable working_public_key_algorithm
(g) Si une extension de contrainte de noms est inclue dans le certificat, modifie permitted_subtrees et excluded_subtrees comme suit:

(1) Si permittedSubtrees est présent dans le certificat, définis la variable d'état permitted_subtrees à l'intersection de sa précédente valeur et de la valeur indiquée dans le champ de l'extension. Si permittedSubtrees n'inclus pas un type de nom particulier, la variable d'état permitted_subtrees est inchangée pour ce type de nom. Par exemple, l'intersection de example.com et foo.example.com est foo.example.com. Et l'intersection de example.com est example.net est un jeu vide.
(2) Si excludedSubtrees est présent dans le certificat, définis la variable d'état excluded_subtrees à l'union de sa valeur précédente valeur et la valeur indiquée dans le champ de l'extension. si excludedSubtrees n'inclus par un type de nom particulier, la variable d'état excluded_subtrees n'est pas changée pour ce type de nom. Par exemple, l'union de l'espace de nom example.con et foo.example.com est example.com. Et l'union de example.com et example.net est les 2 espaces de nom.

(h) Si le certificat i n'est pas auto-fournis:

(1) Si explicit_policy n'est pas 0, décrémente de 1
(2) Si policy_mapping n'est pas 0, décrémente de 1
(3) Si inhibit_anyPolicy n'est pas 0, décrémente de 1

(i) Si une extension de containte de stratégie est inclue dans le certificat, modifie les variables d'état explicit_policy et policy_mapping comme suit:

(1) Si requireExplicitPolicy est présent et est inférieur à explicit_policy, définis explicit_policy à la valeur de requireExplicitPolicy
(2) Si inhibitPolicyMapping est présent et est inférieur à policy_mapping, définis policy_mapping à la valeur de inhibitPolicyMapping

(j) Si l'extension inhibitAnyPolicy est inclus dans le certificat et est inférieur à inhibit_anyPolicy, définis inhibit_anyPolicy à la valeur de inhibitAnyPolicy
(k) Si le certificat i est un certificat v3, vérifie que l'extension basicConstraints est présent et que cA est mis à TRUE. ( Si le certificat i est un v1 ou v2, l'application doit vérifier que le certificat i est un certification CA via un moyen externe ou rejeter le certificat. Les implémentations conformes peuvent choisir de rejeter tous les certificat intermédiaire v1 et v2)
(l) Si le certificat n'est pas auto-fournis, vérifie que max_path_length est supérieur à 0 et le décrémente de 1
(m) Si pathLenConstraint est présent dans le certifiat et est inférieur à max_path_length, définis max_path_length à la valeur de pathLenConstraint
(n) Si une extension d'utilisation de clé est présente, vérifie que le bit keyCertSign est mis.
(o) Reconnaît et traite toute autre extension critique présent dans le certificat. Traite tout autre extension non critique présente dans le certificat qui a sont importance dans le traitement du chemin.

   Si les vérification (a), (k), (l), (n), ou (o) échouent, la procédure se termine, retournant une indication d'erreur et une raison appropriée.

  si (a), (k), (l), (n), et (o) sont complétées avec succès, incrémente i et effectue le traitement de certificat de base spécifié dans la section précédente.

Procédure Wrap-Up

Pour compléter le traitement du certificat cible, effectue les étapes suivantes pour le certificat n:

(a) Si explicit_policy n'est pas 0, décrément explicit_policy de 1
(b) Si une extension de contrainte de stratégie est inclue dans le certificat et requireExplicitPolicy est présent et a une valeur de 0, définis la variable d'état explicit_policy à 0.
(c) Assigne le certificat subjectPublicKey à working_public_key
(d) Si le champ subjectPublicKeyInfo du certificat contient un champ algorithme avec un paramètre non-null, assigne les paramètres à la variable working_public_key_parameters.
Si le champ subjectPublicKeyInfo du certificat contient un champ algorithm avec des paramètre null ou des paramètre omis, compare l'algorithme subjectPublicKey avec working_public_key_algorithm. S'ils sont différents, définis working_public_key_algorithm à nul.
(e) Assigne l'algorithme subjectPublicKey à la variable working_public_key_algorithm.
(f) Reconnaît et traite toute autre extension critique présente dans le certificat n. Traite tout autre extension non critique présente qui a sont importance dans le traitement du chemin.
(g) Calcule l'intersection de valid_policy_tree et user-initial-policy-set, comme suit:

(i) si valid_policy_tree est null, l'intersection est null.
(ii) Si valid_policy_tree n'est pas null et que user-initial-policy-set est any-policy, l'intersection est tout le valid_policy_tree
(iii) Si valid_policy_tree n'est pas null et que user-initial-policy-set est any-policy, calcule l'intersection de valid_policy_tree et de user-initial-policy-set comme suit:

1. Détermine le jeu de nœuds de stratégies dont les nœuds parent ont un valid_policy à anyPolicy. C'est le valid_policy_node_set.
2. Si valid_policy d'un nœud dans valid_policy_node_set n'est pas dans le user-initial-policy-set et n'est pas anyPolicy, supprime ce nœud et tous ses enfants.
3. Si valid_policy_tree inclus un nœuds de profondeur n avec valid_policy anyPolicy et user-initial-policy-set n'est pas any-policy, effectue les étapes suivantes:

a. Définis P-Q au qualifier_set dans le nœud de profondeur n avec valid_policy anyPolicy
b. Pour chaque P-OID dans user-initial-policy-set qui n'est pas le valid_policy d'un nœud dans valid_policy_node_set, crée un nœud enfant dont le parent est le nœud de profondeur n-1 avec valid_policy anyPolicy. Définis les valeurs dans le nœud enfant comme suit: définis valid_policy à P-OID, définis le qualifier_set à P-Q, et définis le jeu expected_policy à {P-OID}.
c. Supprime le nœud de profondeur n avec le valid_policy anyPolicy.

4. S'il y a un nœud dans valid_policy_tree de profondeur n-1 ou moins sans nœud enfant, supprime ce nœud. Répète cette étape jusqu'à ce qu'il n'y ai plus de nœud de profondeur n-1 ou moins sans enfant.

Si (1) la valeur de explicit_policy est supérieur à 0 ou (2) valid_policy_tree n'est pas null, le traitement du chemin a réussit.

Sorties

Si le traitement du chemin réussit, la procédure se termine, retournant une indication de succès avec la valeur finale de valid_policy_tree, working_public_key, working_public_key_algorithm, et working_public_key_parameters.

Utiliser l'algorithme de validation de chemin

   L'algorithme de validation de chemin décris le processus de validation d'un simple chemin de certification. Bien que chaque chemin de certification commence avec une ancre de confiance, il n'y a pas de pré-requis pour tous les chemins de certification validés par un système particulier qui partage une seul ancre de confiance. La sélection d'une ou plusieurs CA de confiance comme ancre de confiance est une décision locale. Un système peut fournir une de ses CA de confiance comme ancre de confiance pour un chemin particulier. L'entrée dans l'algorithme de validation de chemin peut être différent pour chaque chemin. Les entrées utilisées pour traiter un chemin peuvent refléter des pré-requis spécifique à une application ou les limitations dans la confiance accordée à une ancre de confiance particulière. Par exemple, une CA de confiance peut seulement être approuvée pour une stratégie de certificat particulier. Cette restriction peut être exprimée via les entrées de la procédure de validation de chemin.

   Une implémentation peut augmenter l'algorithme présenté plus haut pour limiter le jeu de chemins de certification valide qui commencent avec une ancre de confiance particulière. Par exemple, une implémentation peut modifier l'algorithme pour appliquer une contrainte le longueur de chemin pour une ancre de confiance spécifique durant la phase d'initialisation, ou l'application peut nécessite la présence d'une forme de nom alternative particulière dans le certificat cible, ou l'application peut imposer des pré-requis dans les extensions spécifiques à l'application. L'algorithme de validation de chemin présenté dans ce document définis les conditions minimum pour qu'un chemin soit considéré valide.

   Quand une CA distribut des certificat auto-signés pour spécifier des informations d'ancre de confiance, les extensions de certificat peuvent être utilisé pour spécifier les entrées recommandées à la validation de chemin. Par exemple, une extension de contrainte de stratégie pourrait être inclus dans le certificat auto-signé pour indiquer que le chemin commençant avec cet ancre de confiance devrait être validé seulement pour les stratégies spécifiées. Similairement, une extension de contrainte de nom pourrait être inclus pour indiquer que les chemins commençant avec cet ancre de confiance devraient être validés seulement pour les espaces de nom spécifiés. L'algorithme de validation de chemin présenté dans ce document n'assume pas que les informations de l'ancre de confiance est fournie dans des certificats auto-signés et ne spécifie pas les règles de traitement pour les informations additionnelles inclus dans de tels certificats.

   Cependant, la rfc 5914 définis de nombreux formats pour représenter des informations d'ancre de confiance, incluant des certificats auto-signés, et la rfc 5937 fournis un exemple sur comment de telles informations peuvent être utilisées pour initialiser les entrées de validation de chemin. Les implémentations sont libre d'utiliser les informations additionnelles qui sont inclus dans la représentation de l'ancre de confiance, ou des les ignorer.

Validation de CRL

   Cette section décris les étapes nécessaires pour déterminer is un certificat est révoqué quand les CRL sont le mécanisme de révocation utilisé par le fournisseur de certificat. Les implémentations conformes qui supportent les CRL ne sont pas obligés d'implémenter cet algorithme, mais elles doivent être fonctionnellement équivalente à cette procédure. Tout algorithme peut être utilisé par une implémentation tant qu'elle dérive un résultat correcte.

   Cet algorithme assume que toutes les CRL nécessaire sont disponible dans un cache local. De plus, si le temps nextUpdate d'une CRL a passé, l'algorithme assume un mécanisme pour chercher une CRL courante et la placer dans le cache de CRL local.

   Cet algorithme définis un jeu d'entrées, un jeu de variables d'états, et des étapes de traitement qui sont effectués pour chaque certificat dans le chemin. La sortie de l'algorithme est le statut de révocation du certificat.

Entrées de révocation

Pour supporter le traitement de la révocation, l'algorithme nécessite 2 entrées:

(a) certificate: l'algorithme nécessite le numéro de série du certificat et le nom du fournisseur pour déterminer si un certificat est dans une CRL particulière. L'extension basicConstraints est utilisé pour déterminer si le certificat fournis est associé avec un CA ou une entité finale. Si présent, l'algorithme utilise les extensions cRLDistributionPoints et freshestCRL pour déterminer de statut de révocation.
(b) use-delta: ce booléen détermine si des CRL delta sont appliquées aux CRL.

Variables d'état d'initialisation et de révocation

Pour supporter le traitement des CRL, l'algorithme nécessite les variable d'état suivants:

(a) reasons_mask: Cette variable contient le jeu de raisons de révocation supportés par les CRL et les CRL délta. Les membres légaux de ce jeu sont les valeurs de raison possible moins ceux non-spécifiés: La valeur spéciale all-reasons est utilisée pour dénoter le jeu de tous les membres légaux. Cette variable est initialisée à un jeu vide.
(b) cert_status: cette variable contient le statut du certificat. Cette variable peut être assignée à une des valeurs suivantes: unspecified, keyCompromise, cACompromise, affiliationChanged, superseded, cessationOfOperation, certificateHold, removeFromCRL, privilegeWithdrawn, aACompromise, la valeur spéciale UNREVOKED, ou la valeur spéciale UNDETERMINED. Cette variable est initialisée à UNREVOKED.
(c) interim_reasons_mask: contient le jeu de raisons de révocation supportés par le CRL ou la CRL delta actuellement traitée.

Note: Dans certains environnements, il n'est pas nécessaire de vérifier tous les codes de raison. Par exemple, certains environnement sont seulement concernés par cACompromise et keyCompromise pour les certificats CA. Cet algorithme vérifie tous les codes de raison. Un traitement et des variables d'état additionnel peuvent être nécessaires pour limiter la vérification d'un sous-jeu de codes de raison.

Traitement de CRL

   Cet algorithme commence par supposer que le certificat n'est pas révoqué. L'algorithme vérifie une ou plusieurs CRL jusqu'à ce que soit le statut du certificat est déterminé être révoqué soit que suffisamment de CRL ont été vérifiée pour couvrir tous les codes de raison.

   Pour chaque point de distribution dans l'extension de points de distribution de CRL du certificat, pour chaque CRL correspondant dans le cache de CRL local, tant que ((reasons_mask n'est pas all-reasons) et (cert_status est UNREVOKED)), effectue les étapes suivantes:

(a) Met à jour le cache de CRL local en obtenant une CRL complète, une CRL delta, ou les 2:

(1) Si la date courante est après la valeur du champ nextUpdate de la CRL, effectue une des étapes suivantes:

(i) Si use-deltas et mis et que soit le certificat ou la CRL contient l'extension freshest CRL, obtient une CRL delta avec la valeur nextUpdate qui est après la date courante et peut être utilisée pour mettre à jours la CRL en cache local.
(ii) Met à jour le cache de CRL local avec une CR complète courante, vérifie que la date courante est avant le champ nextUpdate dans la nouvelle CRL. Si use-deltas est mis et soit le certificat soit la CRL contient l'extension freshest CRL, obtient la CRL delta courante qui peut être utilisée pour mettre à jours la nouvelle CRL complète en cache.

(2) Si la date courante est avant la valeur du champ nextUpdate, use-deltas est mis, et soit le certificat ou la CRL contient l'extension freshest CRL, puis obtient la CRL delta courante qui peut être utilisée pour mettre à jour la CRL complète en cache.

(b) Vérifie le fournisseur et le scope de la CRL complète comme suit:

(1) Si le point de distribution (DP) inclus cRLIssuer, alors vérifie que le champ issuer dans la CRL complète correspond au cRLIssuer dans le DP et que la CRL complète contient une extension de point de distribution de fournisseur avec le booléen indirectCRL inséré. Sinon, vérifie que le fournisseur de CRL correspond au fournisseur de certificat.
(2) Si la CRL complète inclus une extension de point de distribution de fournisseur (IDP), vérifie les étapes suivante:

(i) Si le nom du point de distribution est présent dans l'extension de CRL IDP et que le champ de distribution est présent dans le DP, alors vérifie qu'un des noms dans le IDP correspond à un des noms dans le DP. Si le point de distribution est présent dans l'extension de CRL IDP et que le champ distribution est omis du DP, vérifie qu'un des noms dans le IDP correspond à un des noms dans le champ cRLIssuer du DP.
(ii) Si le booléen onlyContainsUserCerts est mis dans l'extension de CRL IDP, vérifie que le certificat n'inclus pas l'extension de contrainte de base avec le booléen cA mis.
(iii) Si le booléen onlyContainsCACerts est mis dans l'extension de CRL IDP, vérifie que le certificat inclus l'extension de contraintes de base avec le booléen cA mis.
(iv) Vérifie que le booléen onlyContainsAttributeCerts n'est pas mis.

(c) Si use-deltas est mis, vérifie le fournisseur et le scope de la CRL delta comme suit:

(1) Vérifie que le fournisseur de CRL delta correspond au fournisseur de CRL complète.
(2) Si la CRL complète inclus une extension de CRL IDP, vérifie que la CRL delta contient une extension de CRL IDP correspondant à l'extension de CRL IDP. Si la CRL complète omet une extension de CRL IDP, vérifie que la CRL delta omet également une extension de CRL IDP.
(3) Vérifie que l'extension d'identifiant de clé d'autorité de CRL delta correspond à l'extension d'identifiant de clé d'autorité de la CRL complète.

(d) Calcule interim_reasons_mask pour cette CRL comme suit:

(1) Si l'extension de CRL IDP est présent et inclu onlySomeReasons et que DP inclus des raisons, définis interim_reasons_mask à l'intersection des raisons dans le DP et onlySomeReasons dans l'extension de CRL IDP.
(2) Si l'extension de CRL IDP inclus onlySomeReasons mais que DP omet les raisons, alors définis interim_reasons_mask à la valeur de onlySomeReasons dans l'extension de CRL IDP.
(3) Si l'extension de CRL IDP n'est pas présente ou omet onlySomeReasons mais que DP inclus des raisons, définis interim_reasons_mask à la valeur de reasons DP.
(4) Si l'extension de CRL IDP n'est pas présente ou omet onlySomeReasons et que DP omet les raisons, définis onlySomeReasons à la valeur spéciale all-reasons.

(e) Vérifie que interim_reasons_mask inclus une ou plusieurs raisons qui ne sont pas inclus dans le reasons_mask.
(f) Obtient et valide le chemin de certification pour le fournisseur de CRL complète. L'ancre de confiance pour le chemin de certification doit être la même que l'ancre de confiance utilisée pour valider le certificat cible. Si une extension d'utilisation de clé est présente dans le certificat du fournisseur de CRL, vérifie que le bit cRLSign est mis.
(g) Valide la signature dans le CRL complète en utilisant la clé publique validée dans l'étape (f).
(h) Si use-delta est mis, valide la signature dans la CRL delta en utilisant la clé publique validée dans l'étape (f)
(i) Si use-deltas et mis, alors recherche le certificat dans la CRL delta. Si une entrée est trouvée qui correspond au fournisseur de certificat et numéro de série, met la variable cert_status à la raison indiquée comme suit:

(1) Si l'extension d'entrée de CRL de code de raison est présent, définis la variable cert_status à la valeur de l'extension d'entrée de CRL de code de raison.
(2) Si l'extension d'entrée de CRL de code de raison n'est pas présent, définis va variable cert_status à la valeur unspecified.

(j) Si (cert_status est UNREVOKED), alors cherche le certificat dans la CRL complète. Si une entrée est trouvée qui correspond au fournisseur et numéro de série du certificat, définis la variable cert_status à la raison indiquée comme décris dans l'étape (i).
(k) Si (cert_status est removeFromCRL), définis cert_status à UNREVOKED.
(l) Définis la variable d'état reasons_mask à l'union de ses précédentes valeurs et de la valeur de la variable d'état interim_reasons_mask.

   Si ((reason_mask est all-reasons) OU (cert_status n'est pas UNREVOKED)), le status de révocation a été determiné, donc retourne cert_status.

   Si le status de révocation n'a pas été déterminé, répète le processus avec toutes les CRL disponible non spécifiées dans un point de distribution, mais fournis par le fournisseur e certificat. Pour le traitement de telles CRL, assume un DP avec champs reasons et cRLIssuer omis et un nom de point de distribution du fournisseur de certifiat. C'est à dire la séquence de noms dans fullName est générée depuis le champ issuer du certificat aussi bien que l'extension issuerAltName du certificat. Après traitement de telles CRL, si le status de révocation n'a pas été déterminé, retourne cert_status à UNDETERMINED.

Traitement des règles pour les noms internationalisés

Les noms internationalisés peuvent être rencontrés dans de nombreux champs et extensions de certificat et de CRL, incluant des noms distinct, noms de domaine internationalisés, adresses de messagerie électronique, et IRI. Le stockage, comparaison, et présentation de tels noms nécessite un attention particulière. Certains caractères peuvent être encodés de plusieurs manières. Les même nom peuvent être représentés dans plusieurs encodage. Cette section établis les pré-requis de conformité pour le stockage ou la comparaison de chacune de ces formes de nom.

Noms internationalisés dans les noms distinct

   Les attribut de nommage standard tels les noms communs, employent le type DirectoryString, qui supporte les noms internationalisés via une variété d'encodage de langues. Les implémentation conformes doivent supporter UTF8String et PrintableString. La rfc3280 requière seulement une comparaison binaire des valeurs d'attributs encodés en UTF8String, cependant, cette spécification requière une manipulation plus compréhensible. Les implémentations peuvent rencontrer des certificats et des CRL avec des noms encodés en utilisant TeletexString, BMPString, ou UniversalString, mais leur support est optionnel.

   Les implémentations conformes doivent utiliser le profile LDAP StringPrep (rfc4518) comme base pour la comparaison des attributs de noms distinct encodés avec PrintableString ou UTF8String. Les implémentations conforme doivent supporter la comparaison de noms en utilisant caseIgnoreMatch. Le support pour les types d'attributs qui utilisent d'autres règles de correspondance d'égalité est optionnel.

   Avant de comparer les noms en utilisant la règle de correspondance caseIgnoreMatch, les implémentation doivent effectuer l'algorithme de conformité en 6 étapes décrit dans la rfc4518 pour chaque attribut de type DirectoryString, avec les clarifications suivantes:

- Dans l'étape 2, le mapparge devrait inclure de cas spécifié dans la rfc3454 Appendix B.2.
- Dans l'étape 6, La suppression des caractères insignifiant, effectue la compression des espaces blanc comme spécifié dans la section Insignificant Space Handling de la rfc 4518.

   En effectuant l'algorithme de préparation de chaîne, les attributs doivent être traités comme valeurs stockées.

   2 attributs de nommage correspondent si les types d'attributs sont les même et les valeurs des attributs sont un exact match après traitement avec l'algorithme de préparation de chaîne. 2 noms distincts relatifs RDN1 et RDN2 correspondent s'ils ont le même nombre d'attributs de nommage pour chaque attribut de nommage dans RDN1, il y a un attribut de nommage correspondant dans RDN2, et les RDN apparaissent dans le même ordre. Un DN1 est dans le subtree définis dans DN2 si DN1 contient au moins autant de RDN que DN2, et DN1 et DN2 correspondent quand les DNS restants dans DN1 sont ignorés.

Noms de domaine internationalisés dans GeneralName

   Les noms de domaine internationalisés (IDN) peuvent être inclus dans les certificats et les CRL dans les extensions subjectAltName et issuerAltName, les extensions de contraintes de nom, extensions d'accès aux informations d'autorité, extensions d'accès aux informations du sujet, extensions de point de distribution de CRL, et les extensions de point de distribution de fournisseur. Chacune de ces extensions utilise le type GeneralName; Un choix dans GeneralName est le champ dNSName, qui est définis comme type IA5String.

   IA5String est limité au jeu de caractères ASCII. Pour adapter les noms de domaine internationalisés dans la structure courante, les implémentations conformes doivent convertir les noms de domaine internationalisés au format ASCII Compatible Encoding (ACE) comme spécifié dans la rfc 3490 avant de stocker le champ dNSName. Spécifiquement, les implémentations conformes doivent effectuer les opérations de conversion spécifiés dans la rfc 3490, avec les clarifications suivantes:

- Dans l'étape 1, le nom de domaine devrait être considéré comme chaîne stockée, c'est à dire que le flag AllowUnassigned n'est pas mis.
- Dans l'étape 3, définis le flag appelé "UseSTD3ASCIIRules"
- Dans l'étape 4, traite chaque label avec l'opération "ToASCII"
- Dans l'étape 5, change tous les séparateurs de label à U+002E.

   En comparant les noms DNS pour l'égalité, les implémentations conforme doivent effectuer une correspondance sensible à la casse exacte sur tout le nom DNS. En évaluant les contraintes de nom, les implémentations conformes doivent effectuer une correspondance sensible à la casse exacte sur une base label par label. Comme spécifié dans la section "name constraints", tous nom DNS que peut être construit en ajoutant des labels à gauche du nom de domaine donné comme contrainte est considéré être dans le subtree indiqué.

   Les implémentations devraient convertir les IDN en Unicode avant affichage. Spécifiquement, les application conformes devraient effectuer l'opération de conversion spécifiée dans la rfc3490, avec les clarifications suivante:

- Dans l'étape 1, le nom de domaine devrait être considéré comme chaîne stockée, c'est à dire que le flag AllowUnassigned n'est pas mis.
- Dans l'étape 3, définis le flag appelé "UseSTD3ASCIIRules"
- Dans l'étape 4, traite chaque label avec l'opération "ToUnicode"
- Saute l'étape 5.

   Note: les implémentations doivent autoriser l'augmentation de l'espace requis pour les IDN. Un label IDN ACE va commencer avec les 4 caractères additionnels "xn--" et peut nécessiter jusqu'à 5 caractères ASCII pour spécifier un simple caractère internationalisé.

Noms de domaine internationalisés dans les noms distincts

Les noms de domaine peuvent également être représentés en noms distinct, en utilisant des composantes domaine dans le champ subject, issuer, l'extension subjectAltName, ou issuerAltName. Comme avec dNSName dans le type GeneralName, la valeur de cet attribut est définis comme IA5String. Chaque attribut domainComponent représente un simple lable. Pour représenter un label depuis un IDN en nom distinct, l'implémentation doit effectuer la conversion de label "ToASCII" spécifié dans la rfc3490. Le label devrait être considéré comme chaîne stockée, c'est à dire que le flag AllowUnassigned n'est pas mis.

Les implémentations conformes devraient convertir les labels ACE en Unicode avant affichage. Spécifiquement, les implémentations conformes devraient effectuer l'opération de conversion "ToUnicode" spécifiée dans la rfc3490, sur chaque label ACE avant affichage.

Identifiants de ressources internationalisés

   Les IRI sont le complément internationalisé des URI. Les IRI sont des séquences de caractères Unicode, alors que les URI sont des séquences de caractères ASCII. La rfc3987 définis un mappage des IRI en URI. Bien que les IRI ne sont pas encodés directement dans les champs et extensions de certificat et CRL, leur version mappé URI peuvent êrte inclus dans les certificats et CRL. Les URI peuvent apparaître dans les extensions subjecAltName, issuerAltName, contraintes de noms, accès aux informations de l'autorité, accès aux informations du sujet, point de distribution de fournisseur et de CRL. Chacune de ces extensions utilisent le type GeneralName, les URI sont encodés dans le champ uniformResourceIdentifier dans GeneralName, qui est défini en type IA5String.

   Pour représenter les IRI dans la structure courante, les implémentations courantes doivent mapper les IRI en URI comme spécifiés dans la rfc 3987, avec les clarifiations suivantes:

- Dans l'étape 1, génère une séquence de caractère UCS du format IRI original normalisant en accord au NFC comme spécifié dans la variante b
- Effectue l'étape 2 en utilisant la sortie de l'étape 1.

   Les implémentations ne doivent pas convertir le composant ireg-name avant d'effectuer l'étape 2.

   Avant que les URI puissent être comparés, les implémentations conformes doivent effectuer une combinaison des techniques de normalisation basé sur la syntaxe et sur le schéma décris dans la rfc3987. Spécifiquement, les implémentations conformes doivent préparer les URI pour les comparaisons comme suit:

Étape 1 Quand les IRI permettent l'utilisation d'IDN, ces noms doivent être convertis en ACE comme spécifié plus haut
Étape 2 Le schéma et l'hôte sont normalisés en minuscule comme spécifié dans la rfc3987
Étape 3 Effectue une normalisation percent-encoding, comme spécifié dans la rfc3987
Étape 4 Effectue une normalisation de segment de chemin, comme spécifié dans la rfc3987
Étape 5 Si reconnus, L'implémentation doit effectuer une normalisation basée sur le schéma, comme spécifié dans la rfc3987

   Les implémentations conformes doivent reconnaître et effectuer une normalisation basée sur les schéma pour les schéma suivant: ldap, http, https, et ftp. Si le schéma n'est pas reconnu, l'étape 5 est omise.

   En comparant les URI pour l'équivalence, les implémentations conformes devraient effectuer une correspondance d'égalité sensible à la casse.. Les implémentations devraient convertir les URI en Unicode avant affichaqe.

Adresses de messagerie électronique internationalisées

   Les adresses de messagerie électronique peuvent être inclus dans les certificats et les CRL dans les extension subjecAltName et issuerAltName, contraintes de noms, accès aux information d'autorité et du sujet, et point de distribution du fournisseur et de CRL. chacune de ces extensions utilise la construction GeneralName; GeneralName inclus rfc822Name, qui est définis comme type IA5String. Pour spécifier des adresses email avec des noms de domaine internationalisés en utilisant la structure courante, les implémentations conforme doivent convertir les adresses en représentation ASCII.

   Quand la partie hôte (le domaine de la boîte mail) contient un nom internationalisé, le nom de domaine doit être convertis depuis un IDN en ACE. 2 adresses email correspondent si:

1) La partie locale du chaque nom est un exact match, et
2) la partie hôte de chaque nom correspond en utilisant une comparaison ASCII insensible à la casse.

   Les implémentations devraient convertir la partie hôte des adresses email internationalisés spécifiés dans ces extension en Unicode avant affichage. Spécifiquement, les implémentations conformes devraient effectuer la conversion de la partie hôte de la boîte mail comme décris dans la section des IDN dans GeneralName.

Considérations de sécurité

   Vu que les certificats et les CRL sont signés numériquement, aucun service d'intégrité additionnel n'est nécessaire, ni de conserver les certificats ou les CRL secrets, et les accès non-restreins et anonymes aux certificats et CRL n'a pas d'implication de sécurité.

   Cependant, des facteurs de sécurité en dehors du scope de cette spécification affectent l'assurance fournie par les certificats utilisateurs. Cette section met en avant les problèmes de sécurité hautement critique à considérer par les implémenteurs, administrateurs et les utilisateurs.

   L'utilisation d'une simple paire de clé pour la signature et d'autres buts est fortement découragée. L'utilisation de paires de clé séparés pour la signature et la gestion de clé fournis de nombreux bénéfices aux utilisateurs. Les ramifications associées avec la pertes ou la divulgation d'une clé de signature sont différents de la perte ou la divulgation d'une clé de gestion de clé. Utiliser des paires de clé différente permet une réponse balancée et différente. Similairement, différentes périodes de validité ou longueur de clé pour chaque paire de clé peuvent être approprié dans certains environnements. Malheureusement, certaines applications utilisent une simple paire de clé pour la signature et la gestion de clé.

   La protection des clés privées conférée aux clés privées est un facteur critique. À petite échelle, les utilisateurs qui ne protègent pas leurs clés privée va permettre à un attaquant de les usurper ou déchiffrer leurs informations personnelles. À plus grande échelle, la clé privée de signature d'une CA compromise peut avoir un effet catastrophique. Si un attaquant obtient une clé privée, il peut émettre de faux certificats et CRL. L'existance de faux certificats et CRL va détruire la confidence dans le système. Si un tel compromis est détecté, tous les certificats émis par la CA compromise doivent être révoqués, bloquant les services entre ses utilisateurs et les utilisateurs d'autres CA. Reconstruire après un tel compromis sera problématique, donc les CA doivent implémenter une combinaison de mécanismes fort et de procédures de gestion appropriés (ex: séparation des privilèges) pour éviter un incident.

   La perte d'une clé de signature privée de CA peut également être problématique. La CA ne sera pas capable de produire de CRL ou d'effectuer des remplacements de clé. Les CA devraient maintenir une sauvegarde sûre pour les clés de signature. La sécurité des procédures de sauvegarde de clé est un facteur critique pour éviter la compromission de clé.

   La disponibilité des informations de révocation affecte le degré d'assurance qui est placé dans un certificat. Bien que les certificats expirent naturellement, des évènements peuvent se produire durant sa durée de vie qui supprime la liaison entre le sujet et sa clé publique. Si l'information de révocation n'est pas disponible, l'assurance avec la liaison est clairement réduite. Les parties de confiance peuvent ne pas être capable de traiter toutes les extensions critiques qui peuvent apparaître dans une CRL. Les CA devraient faire très attention créant des informations de révocation uniquement disponibles via des extensions critiques, particulièrement si le support pour ces extensions n'est pas mandaté par ce profile.

   Par exemple, si les informations de révocation sont fournis en utilisant une combinaison de CRL delta et le CRL complètes, et que la CRL delta est fournie plus fréquemment que les CRL complètes, les parties de confiance qui ne peuvent pas manipuler les extensions critiques liées au traitement de la CRL delta ne seront pas capable d'obtenir les informations de révocations les plus récentes. Alternativement, il une CRL complète est fournis au même moment qu'une CRL delta, Les informations de révocation seront disponibles à toutes les parties. Similairement, les implémentations du mécanisme de validation de chemin de certification qui omettent la vérification de révocation fournissent moint d'assurance qui celles qui le supporte.

   L'algorithme de validation de chemin de certification dépend de la connaissance des clé publiques ( et autres informations ) sur une ou plusieurs CA de confiance. La décision de la confiance en un CA est une décision importante vu qu'elle détermine la confiance accordée à un certificat. La distribution authentifiée de clés publique de CA (généralement sous la forme de certificat auto-signé) est un processus à part critique qui est en dehors de cette spécification.

   En plus, quand une clé est compromise ou qu'une CA en peut plus être de confiance, l'utilisateur doit modifier les informations fournies à la routine de validation de chemin. Sélectionner trop de CA de confiance rend cette maintenance difficile.

   La qualité des implémentations qui traitent les certificats affectent également le degré d'assurance fournis. L'algorithme de validation de chemin s'assure de l'intégrité des informations de CA de confiance, et spécialement l'intégrité des clés publiques associées avec ces CA. En substituant les clés publiques pour lequel un attaquant a la clé privée lui permet de faire accepter de faux certificats à un utilisateur.

   La liaison entre une clé et le sujet du certificat ne peut pas être plus fort que l'implémentation du module cryptographique et des algorithmes utilisés pour générer la signature. Des longueurs de clé courtes ou des algorithmes de hashage faible limitent l'utilité des certificats. Les CA sont encouragés à noter les progrès en cryptologie afin d'employer des techniques cryptographiques fortes. De plus, les CA devraient refuser de fournir des certificats à de CA ou des entités finales qui génèrent des signatures faibles.

   Une application inconsistante de règle de comparaison de nom peut résulter dans l'acceptation de chemins de certification invalides ou le rejet de chemins valides. Les séries de spécification X.500 définissent des règles pour comparer les noms distincts qui nécessitent la comparaison de chaînes sans regarder là casse, le jeu de caractère, espaces blancs multi-caractères, ou espaces blancs en début ou fin. Cette spécification relaxe ces requis, nécessitant le support d'une comparaison binaire au minimum.

   Les CA doivent encoder les noms distinct dans le champ sujet d'un certificat CA identiquement au nom distinct dans le champ issuer dans les certificats fournies par cette CA. Si les CA utilisent des encodages différents, les implémentations peuvent échouer à reconnaître les chaînes de nom pour les chemins qui incluent ce certificat. En conséquence, les chemins valides pourraient être rejetés.

   En plus, les contraintes de nom pour les noms distincts doivent être identiques à l'encodage utilisé dans le champ subjet ou l'extension subjectAltName. Sinon, les contraintes de noms définis comme excludedSubtrees ne matcheront pas et les chemins invalides seront acceptés et les contraintes de noms exprimés comme permittedSubtrees ne vont pas matcher et les chemins valides seront rejeter. Pour éviter d'accepter les chemins invalides, les CA devraient définir les contraintes de noms pour les noms distincts comme permittedSubtrees si possibles.

   En général, utiliser l'extension nameConstraints pour contraindre une forme de nom n'offre pas de protection contre l'utilisation d'autre formes de nom.

   Bien que X.509 mandate que les noms soient non ambigus, il y a un risque que 2 autorités non liées fournissent des certificats et/ou des CRL sous le même nom de fournisseur. Un moyen de réduire ces problèmes et les problèmes de sécurité liés aux collisions de nom de fournisseur, les noms de CA et de fournisseurs de CRL devraient être formé d'une manière qui réduit la probabilité des collisions de noms. Les implémenteurs devraient prendre en compte l'existence possible de multiples CA et fournisseurs de CRL avec le même nom. Au minimum, les implémentations validant les CRL doivent s'assurer que le chemin de certification d'un certificat et du chemin de certification du fournisseur de CRL utilisés pour valider ce certificat se terminent à l'ancre de confiance.

   Bien que la partie locale d'une adresse de messagerie électronique est sensible à la casse, les valeurs de l'attribut emailAddress sont insensibles à la casse. Il y un risque que 2 adresses emails différentes soient traitées comme des adresse identiques. Les implémenteurs ne devraient pas inclure une adresses email dans l'attribut emailAddress si le serveur de messagerie traite la partie locale des adresses email comme sensible à la casse.

   Les implémenteurs devraient s'assurer des risques liés si les points de distribution de CRL ou les extensions d'accès aux informations d'autorité de certificats ou de CRL corrompus contiennent les liens vers du code malicieux. Les implémenteurs devraient toujours prendre les étapes consistant à valider les données extraites afin de s'assurer que les données sont correctement formées.

   Quand les certificats incluent une extension cRLDistributionPoints avec une URI https ou un schéma similaire, des dépendances circulaires peuvent être introduits. Le tier de confiance est forcé d'effectuer une validation de chemin additionnel pour obtenir la CRL requise pour compléter la validation de chemin initiale. Des conditions similaires peuvent égalemente être créés avec une URI https dans les extensions authorityInfoAccess ou subjectInfoAccess.

   Les CA ne devraient pas inclure d'URI qui spécifient https, ldaps, ou des schémas similaires dans les extensions. Les CA qui incluent une de ces extension doivent s'assurer que le certificat du serveur peut être validé dans utiliser d'informations pointé par l'URI. Les tiers de confiance qui choisissent de valider le certificat du serveur en obtenant les informations pointés par une URI https dans les extensions cRLDistributionPoints, authorityInfoAccess, ou subjectInfoAccess doivent être préparés pour cette possibilité.

   Les certificats auto-fournis fournissent des CA avec un mécanisme automatisé pour indiques les changements dans les opération de la CA. En particulier, les certificat auto-signés peuvent être utilisés pour implémenter un changement de paire de clé non-compromis à un autre. Les procédures détaillée pour la mise à jours de clé de CA sont spécifiés dans la rfc4210, où la CA protège sa nouvelle clé publique en utilisant sa précédente clé privée et vice versa en utilisa 2 certificats auto-fournis. Les implémentations client conformes vont traiter le certificat auto-signé et déterminer si les certificats fournis sous la nouvelle clé peut être trusté. Les certificats auto-fournis peuvent être utilisé pour supporter d'autres changements dans les opérations de CA, tel que l'ajout de stratégies, en utilisant des procédures similaires.

   Certaines anciennes implémentations supportent les noms encodés en ISO 8859-1 (Latin1String) mais les tag en TeletexString. TeletexString encode un jeu de caractère plus grand que ISO 8859-1, mais il encode certains caractères différemment. Les règles de comparaison spécifiée plus haut assument que les TeletexStrings sont encodés comme décris dans le standard ASN.1. En comparant les noms encodés en Latin1String, de faux positifs et négatifs sont possibles.

   Quand des chaînes sont mappées depuis des représentations interne vers de représentation visuelle, 2 chaînes différentes peuvent parfois avoir la même représentation visuelle. Cela peut se produire pour plusieurs raisons, incluant l'utilisation de glyphes similaires et l'utilisation de caractères composés. Les fournisseurs de certificats et les tiers de confiance doivent gérer cette situation.

27 novembre 2014

rfc5652

Syntaxe de message cryptographique

Définitions

   Ce document décris la syntaxe de message cryptographique (CMS). Cette syntaxe est utilisée pour signer, hasher, authentifier ou chiffrer numériquement du contenu de message arbitraire.

   Le CMS décris une syntaxe d'encapsulation pour la protection des données. Il supporte les signatures et chiffrement numérique. La syntaxe permet plusieurs encapsulations; un enveloppe d'encapsulation peut être imbriquée dans une autre. Également, une partie peut signer une donnée précédemment encapsulée. Il peut également des attributs arbitraires, telle que la date de signature.

   Le CMS peut supporter divers architectures pour la gestion de clé basé sur les certificats, tes que celui définis par le groupe de travail PKIX.

   Les valeurs CMS sont générées en utilisant ASN.1, utilisant l'encodage BER. Les valeurs sont typiquement représentées comme chaîne d'octets. Bien que de nombreux systèmes sont capable de transmettre des chaînes d'octet arbitraires de manière sûre, il est bien connu que les systèmes de messagerie électronique ne le sont pas. Ce document n'adresse pas les mécanismes pour encoder les chaînes d'octets pour une transmission sûre dans de tels environnements.

Évolution de CMS

Le CMS est dérivé de PKCS#7 version 1.5, qui est documenté dans la rfc 2315. PKCS#7 a été publié à l'origine comme note technique des laboratoires RSA en novembre 1993. IETF a depuis repris la responsabilité pour le développement et la maintenance du CMS. Aujourd'hui, de nombreux protocoles IETF utilisent CMS. Cette section décris les changement que l'IETF a fait de CMS dans chaque version publiée.

Changements depuis PKCS#7 version 1.5

la rfc 2630 [CMS1] était la première version de CMS. Quand cela est possible, la compatibilité avec PKCS#7 a été préservée; cependant, des changements fait pour accueillir le transfert de l'attribut certificat version 1 et pour supporter la gestion de clé indépendamment de l'algorithme. PKCS#7 version 1.5 incluait le support seulement pour le transport des clé. la rfc 2630 ajoute le support pour l'accord de clé et les techniques de chiffrement de clé symétrique distribués précédemment.

Changements depuis la rfc 2630

   La rfc 3369 [CMS2] remplace la rfc 2630 et la rfc 3211. La gestion de clé basé sur des mots de passe est inclue dans la spécification CMS et un mécanisme d'extension pour supporter de nouveau schémas de gestion de clé dans avoir à changer le CMS est spécifié. La compatibilité avec la rfc 2630 et la rfc3211 est préservée. Cependant, le transfert d'attribut de certificat version 2 est ajouté, et l'utilisation des attributs de certificat version 1 est déprécié.

   Les signatures S/MIME v2, qui sont basées sur PKCS#7 v1.5, sont compatibles avec les signature S/MIME v3 et v3.1. Cependant, il y a quelques problème subtiles de compatibilité avec les signatures basées sur PKCS#7 v1.5.

   Les algorithmes de chiffrement spécifiques ne sont pas discutés dans ce document, mais ont été discutés dans la rfc 2630. La discussion des algorithmes de chiffrement on été placés dans les document séparés.

Changements depuis la rfc 3369

La rfc 3852 [CMS3] remplace la rfc 3369. Comme discuté dans la précédente section, la rfc 3369 a introduit un mécanisme d'extension pour supporter de nouveaux schémas de gestion de clé. La rfc 3852 introduit un mécanisme d'extension similaire pour supporter des formats de certificats additionnels et les formats d'information de status de révocation.

Changement depuis la rfc 3852

Ce document remplace la rfc 3852. La raison principale pour la publication de ce document est de faire progresser le CMS avec la maturité des standards. Ce document inclus la clarification qui était originellement publiée dans la rfc 4853 concernant la manipulation correcte du type de contenu SignedData quand plus d'une signature numérique est présente.

Numéros de version

Chacune des structures de donnée majeur inclus un numéro de version comme premier élément de la structure. Les numéros de version. Les numéro de version sont prévus pour éviter les erreurs de décodage ASN.1. Certaines implémentations ne vérifient pas le numéro de version avant de tenter un décodage, et si une erreur est rencontrée, le numéro de version est vérifié. C'est une approche raisonnable.

La plupart des numéros de version initiales ont été assignés dans PKCS#7 v1.5. D'autre ont été assignés quand la structure a été créée initialement. Quand une structure est mise à jours, un numéro de version supérieur est assigné. Cependant, pour s'assurer d'une interopérabilité maximale, le numéro de version supérieur est uniquement utilisé quand une nouvelle syntaxe est employée.

Vue générale

   Le CMS est suffisamment généraliste pour supporter de nombreux types de contenu différents. Ce document définis une protection de contenu, ContentInfo. ContentInfo encapsule un type de contenu identifié simple, et le type identifié peut fournir d'autres encapsulations. Ce document définis 6 types de contenu: donnée, donnée signée, donnée enveloppée, donnée hashée, donnée chiffrée et donnée authentifiée. Des types de contenu additionnels peuvent être définis en dehors de ce document.

   Une implémentation qui se conforme à cette spécification doit implémenter le contenu de protection, ContentInfo, et doit implémenter les types de contenu donnée, donnée hashé donnée chiffrée, et donnée authentifiée. Les autres type de contenu peuvent être implémentés.

   Comme philosophie de design générale, chaque type de contenu permet un traitement en une seule passe en utilisant l'encodage BER à longueur indéfinie. L'opération single-pass est spécifiquement utile si le contenu est grand, stocké sur cassettes, ou pipé depuis un autre processus. Une opération simple passe a un inconvénient important: il est difficile d'effectuer des opérations d'encodage en utilisant DER dans une simple passe vu que les longueurs des divers composants peuvent ne pas être connus à l'avance. Cependant, les attributs signés dans le type de contenu donnée signée et les attributs authentifiés dans le type de contenu donnée authentifiée doivent être transmis sous la forme DER pour s'assurer que le destinataire puisse vérifier un contenu qui contiendrait un ou plusieurs attributs non-reconnus. Les attributs signés et les attributs authentifiés sont les seuls types de donnée utilisées dans le CMS qui nécessitent un encodage DER.

Syntaxe générale

Les identifiants d'objet suivants identifient le type d'information de contenu:
id-ct-contentInfo OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) ct(1) 6 }

Le CMS associe un identifiant de type de contenu avec un contenu. La syntaxe doit avoir le type ASN.1 ContentInfo:
ContentInfo ::= SEQUENCE {
    contentType ContentType,
    content [0] EXPLICIT ANY DEFINED BY contentType }

    ContentType ::= OBJECT IDENTIFIER

contentType Indique le type de contenu associé. C'est un identifiant d'objet; c'est une chaîne unique d'entiers assignés par une autorité qui définie le type de contenu.
content Est le contenu associé. Le type de contenu peut être déterminé de manière unique par le contentType. Les types de contenus pour donnée, donnée signée, donnée enveloppée, donnée hashée, donnée chiffrée et donnée chiffrée sont définies dans ce document. Si d'autres types de contenu sont définis dans d'autres documents, le type ASN.1 définis ne devrait pas être un type CHOICE.

Type de contenu donnée

L'identifiant d'objet suivant identifie le type de contenu donnée:
id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs7(7) 1 }

Le type de contenu donnée est prévu pour référer à des chaînes d'octets arbitraires, tels que des fichiers texte ASCII; l'interprétation est laissée à l'application. De telles chaînes n'ont pas besoin de structure interne ( bien qu'ils peuvent avoir leur propre définition ASN.1 ou d'autre structure ). S/MIME utilis id-data pour identifier le contenu encodé MIME. L'utilisation de cet identifiant de contenu est spécifié dans la rfc 2311 pour S/MIME v2, rfc 2633 pour S/MIME v3, et rfc 3851 pour S/MIME v3.1. Le type de contenu donnée est généralement encapsulée dans un type de contenu donnée signée, donnée enveloppée, donnée hashée, donnée chiffrée, ou donnée authentifiée.

Type de contenu donnée signée

   Le type de contenu donnée signée consiste d'un contenu de n'importe quel type et 0 ou plusieurs valeurs de signatures. Plusieurs signataires en parallèle peuvent signer un type de contenu.

   L'application typique du type de contenu donnée signée représente la signature numérique d'un signataire sur le contenu d'un type de contenu donnée. Une autre application typique est la diffusion de certificats et le listes de révocation de certificats. Le processus par lequel une donnée signée est construite est composé des étapes suivantes:

1. Pour chaque signataires, un hash est calculé sur le contenu avec un algorithme de hash spécifique au signataire. Si le signataire signe une information autre que le contenu, le hash du contenu et les autres informations sont hashées avec l'algorithme de hashage du signataire, et le résultat devient le hash.
2. Pour chaque signataire, le hash est signé numériquement en utilisant la clé privée du signataire.
3. Pour chaque signataire, la valeur de signature et d'autres informations spécifiques au signataire sont collectées dans une valeur SignerInfo. Les certificats et CRL pour chaque signataire, et ceux ne correspondant pas à un signataire, sont collectées dans cette étape.
4. Les algorithmes de hash et les valeurs SignerInfo pour tous les signataires sont collectés ensemble avec le contenu dans une valeur SignedData.

   Un destinataire calcule de manière indépendante le hash. Ce hash est la clé publique du signataire sont utilisés pour vérifier la valeur de la signature. La clé publique du signataire est référencée d'un des 2 manières. Elle peut être référencée par un dn de fournisseur avec un numéro de série de fournisseur pour identifier de manière unique le certificat qui contient la clé publique. Alternativement, elle peut être référencéé par un identifiant de clé du sujet, qui reçoit les clé publiques certifiés et non-certifiés. Bien qui ce ne soit pas requis, le certificat du signataire peut être inclu dans le champ des certificates du SignedData.

   Quand plus d'une signature est présente, la réussite de la validation d'une signature associée avec un signataire donné est généralement traitée comme une signature réussie dans le signataire. Cependant, il y a certaines application où d'autres règles sont nécessaires. Une application qui emploie une règle autre qu'une signature valide pour chaque signataire doit spécifier ces règles. Également, là où une simple correspondance de l'identifiant du signataire n'est pas suffisant pour déterminer si les signatures ont été générées par le même signataire, l'application doit décrire comment déterminer quelles signatures ont été générées par le même signataire. Le support de différentes communautés des bénéficiaires est la principale raison qui les signataires choisissent d'inclure plus d'une signature.

   Par exemple, le type de contenu donnée signée peut inclure des signatures générées avec l'algorithme de signature RSA et avec l'algorithme de signature à courbe elliptique (ECDSA). Celà permet aux destinataires de vérifier la signature associée avec un algorithme ou l'autre.

   Cette section est divisée en 6 parties. La première décris le type SignedData, la seconde décris EncapsulatedContentInfo, la troisième décris les information par signataire SignerInfo, la quatrième, cinquième et sixième décrivent le calcule du hash, génération de signature, et processus de vérification de signature.

Type SignedData

L'identifiant d'objet suivant identifie le type de contenu donnée signée:
id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 }

Le type de contenu donnée signée devrait avoir le type ASN.1:
SignedData ::= SEQUENCE {
    version CMSVersion,
    digestAlgorithms DigestAlgorithmIdentifiers,
    encapContentInfo EncapsulatedContentInfo,
    certificates [0] IMPLICIT CertificateSet OPTIONAL,
    crls [1] IMPLICIT RevocationInfoChoices OPTIONAL,
    signerInfos SignerInfos }

    DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier

    SignerInfos ::= SET OF SignerInfo

version Est le numéro de version de syntaxe. La valeur appropriée dépend des certificats, eContentType et SignerInfo. a version doit être assignée comme suit:

IF ((certificates is present) AND
    (any certificates with a type of other are present)) OR
    ((crls is present) AND
    (any crls with a type of other are present))
THEN version MUST be 5
ELSE
    IF (certificates is present) AND
        (any version 2 attribute certificates are present)
    THEN version MUST be 4
    ELSE
        IF ((certificates is present) AND
            (any version 1 attribute certificates are present)) OR
            (any SignerInfo structures are version 3) OR
            (encapContentInfo eContentType is other than id-data)
        THEN version MUST be 3
        ELSE version MUST be 1

digestAlgorithm Est une collection d'identifiant d'algorithme de hash. Il peut y avoir plusieurs éléments dans la collection, incluant 0. Chaque élément identifie l'algorithme de hash, avec leur paramètres associés, utilisés par un ou plusieurs signataires. La collection est prévue pour lister les algorithmes de hash employées par tous les signataires, dans n'importe quel ordre, pour faciliter la vérification de signature en une passe. Les implémentations peuvent échouer la validation des signatures qui utilisent un algorithme qui n'est pas inclus dans ce set.
encapContentInfo Est le contenu signé, consistant d'un identifiant de type de contenu et le contenu lui-même.
certificates Est une collection de certificats. Il est prévu que ce jeu de certificat soit suffisant pour contenir les chemins de certification depuis un root reconnus vers tous les signataires dans le champ signerInfos. Il peut y avoir plus de certificats qui nécessaire, et il peut y avoir suffisamment de certificats pour contenir les chemins de certification depuis 2 ou plusieurs autorités de certification racine indépendante. Il peut y avoir moins de certificats qui nécessaire, s'il est prévu que les destinataires ont un moyen alternatif pour les obtenir. Le certificat du signataire peut être inclus. L'utilisation de la version 1 de l'attribut certificates est fortement découragée.
crls Est une collection d'information de status de révocation. Il est prévu qui la collection contienne les information suffisantes pour déterminer si les certificats dans le champ certificates sont valides, mais une telle correspondance n'est pas nécessaire. Les CRL sont la principale source d'information de status de révocation. Il peut y avoir plus de CRL que nécessaire, et il peut y avoir moins de crl qui nécessaire.
signerInfos Est une collection d'information par signataire. Il peut y avoir plusieurs éléments dans la collection, incluant 0. Quand la collection représente plus d'une signature, la réussite de la validation d'une signature d'un signataire donné doit être traitée comme une signature réussie par le signataire. Cependant, il y a certaines applications où d'autres règles sont nécessaire. Vu que chaque signataire peut employer une technique de signature différente, et de futures spécifications peut mettre à jours la syntaxe, toutes les implémentations doivent manipuler les versions non-implémentées de SignerInfo. De plus, toutes les implémentations doivent manipuler les algorithmes de signature non-implémentées quand elles sont rencontrées.

Type EncapsulatedContentInfo

Le contenu est représenté dans le type EncapsulatedContentInfo:
EncapsulatedContentInfo ::= SEQUENCE {
    eContentType ContentType,
    eContent [0] EXPLICIT OCTET STRING OPTIONAL }

    ContentType ::= OBJECT IDENTIFIER

eContentType Est un identifiant d'objet.
eContent Est le contenu lui-même, il n'a pas besoin d'être encodé DER.

   L'omission optionnelle de eContent avec le champ EncapsulatedContentInfo rend possible la contruction de signatures externes. Dans le cas de signatures externes, le contenu à signer est absent de la valeur EncapsulatedContentInfo inclus dans le type de contenu donnée signée. Si la valeur eContent dans EncapsulatedContentInfo est absent, signatureValue est calculée et le eContentType est assignée comme si la valeur eContent était présente.

   Dans le cas dégénéré où il n'y a pas de signataires, la valeur EncapsulatedContentInfo à signer est sans importance. Dans ce cas, le type de contenu avec la valeur EncapsulatedContentInfo à signer doit être id-data, et le champ content de la valeur EncapsulatedContentInfo doit être omise.

Compatibilité avec PKCS#7

   Cette section contient un mot d'alerte pour les implémenteurs qui souhaites supporter les type de contenu SignedData CMS et PKCS#7. CMS et PKCS#7 identifient le type de contenu encapsulé avec un identifiant d'objet, mais le type ASN.1 du contenu lui-même est variable dans le type de contenu SignedData PKCS#7.

PKCS#7 définis le contenu:
content [0] EXPLICIT ANY DEFINED BY contentType OPTIONAL
Le CMS définis eContent:
eContent [0] EXPLICIT OCTET STRING OPTIONAL

   La définition de CMS est plus facile à utiliser dans la plupart des applications, et est compatible avec S/MIME v2 et v3. les messages signés S/MIME utilisant CMS et PKCS#7 sont compatibles parce que les format de message signés identique sont spécifiés dans les rfc 2311, 2633 et 3851. S/MIME v2 encapsule le contenu MIME dans un type Data ( un OCTET STRING ) dans le contenu contentInfo de SignedData, et S/MIME v2 le porte dans le eContent encapContentInfo SignedData. Cependant, dans S/MIME v2, v3 et v3.1, le contenu MIME est placé dans un OCTET STRING et le hash est calculé sur les portions identiques de contenu.

   Il y a des incompatibilités entre les type SignedData de CMS et PKCS#7 qui le contenu encapsulé n'est pas formaté en utilisant le type Data. Par exemple, qui un reçu signé rfc3634 est encapsulé dans le type SignedData CMS, le Receipt SEQUENCE est encodé dans le SignedData encapContentInfo eContent OCTET STRING et le hash est calculé en utilisant tous l'encodage Receipt SEQUENCE ( incluant le tag, longueur et octets de valeurs). Cependant, si un reçu signé rfc2634 est encapsulé dans le type SignedData PKCS#7, alors le Receipt SEQUENCE est encodé DER dans le contenu SignedData contentInfo (une SEQUENCE, par un OCTET STRING). Cependant, le hash est calculé en utilisant seulement les octets de valeur de l'encodage de Receipt SEQUENCE.

   La stratégie suivante peut être utilisée pour la compatibilité avec PKCS#7 en traitant les type de contenu SignedData. Si l'implémentation n'est pas capable de décoder l'ASN.1 du type SignedData en utilisant la syntaxe CMS SignedData encapContentInfo eContent OCTET STRING, alors l'implémentation peut tenter de décoder le type SignedData en utilisant une syntaxe de contenu PKCS#7 SignedData contentInfo et calculer le hash.

   La stratégie suivante peut être utilisé pour la compatibilité avec PKCS#7 en créant un type de contenu SignedData dans lequel le contenu encapsulé n'est pas formaté en utilisant le type Data. Les implémentations peuvent examiner la valeur de eContentType, et ainsi ajuster l'encodage DER attendu de eContent basé sur la valeur de l'identifiant d'objet. Par exemple pour supporter MSAC, les informations suivantes peuvent être inclus:

    eContentType Object Identifier is set to { 1 3 6 1 4 1 311 2 1 4 }

    eContent contains DER-encoded Authenticode signing information

Type SignerInfo

Les information par signataire sont représentés dans le type SignerInfo:
SignerInfo ::= SEQUENCE {
    version CMSVersion,
    sid SignerIdentifier,
    digestAlgorithm DigestAlgorithmIdentifier,
    signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL,
    signatureAlgorithm SignatureAlgorithmIdentifier,
    signature SignatureValue,
    unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL }

SignerIdentifier ::= CHOICE {
    issuerAndSerialNumber IssuerAndSerialNumber,
    subjectKeyIdentifier [0] SubjectKeyIdentifier }

SignedAttributes ::= SET SIZE (1..MAX) OF Attribute

UnsignedAttributes ::= SET SIZE (1..MAX) OF Attribute

Attribute ::= SEQUENCE {
    attrType OBJECT IDENTIFIER,
    attrValues SET OF AttributeValue }

AttributeValue ::= ANY

SignatureValue ::= OCTET STRING

version Est le numéro de version de syntaxe. Si SignerIdentifier est le choix issuerAndSerialNumber, la version doit être 1. Si SignerIdentifier est sibjectKeyIdentifier, la version doit être 3.
sid Spécifie le certificat du signataire ( et donc sa clé publique). La clé publique du signataire est nécessaire au destinataire pour vérifier la signature.

   SignerIdentifier fournis 2 alternatives pour spécifier la clé publique du signataire. L'alternative issuerAndSerialNumber identifie le certificat du signataire par le dn du fournisseur et le numéro de série du certificat; le subjectKeyIdentifier identifie le certificat du signataire par un identifiant de clé. Quand un certificat X.509 est référencé, l'identifiant de clé matche la valeur de l'extention subjectKeyIdentifier. Quand d'autres formats de certificats sont référencés, les documents qui spécifient le format de certificat et leur utilisation avec le CMS doivent inclure les détails sur le matching d'identifiant de clé du champ certificat approprié. Les implémentations doivent supporter la réception des formes issuerAndSerialNumber et subjectKeyIdentifier.

   En générant un SignerIdentifier les implémentations peuvent supporter une des formes ( soit issuerAndSerialNumber soit subjectKeyIdentifier) et toujours l'utiliser, ou les implémentations peuvent arbitrairement mixer les 2 formes. Cependant, subjectKeyIdentifier doit être utilisé pour référer à une clé publique contenue dans un certificat non-X.509.

digestAlgorithm Identifie l'algorithme de hash, et ses paramètres associés, utilisés par le signataire. Le hash est calculé sur soit le contenu à signer soit le contenu et les attributs signés en utilisant le processus décris plus bas. l'algorithme de hash devrait être listé dans le champ digestAlgorithms du SignerData associé. Les implémentations peuvent échouer si ce n'est pas le cas.
signedAttrs Est une collection d'attributs qui sont signés. Le champ est optionnel, mais il doit être présent si le type de contenu de la valeur EncapsulatedContentInfo à signer n'est pas id-data. SignedAttributes doit être encodé DER, même si le reste de la structure set encodée BER. Les types d'attributs utiles, tels qu'une date de signature, sont définis plus loin dans ce document. Si le champ est présent, il doit contenir, au minimum, les 2 attributs suivants:

content-type ayant comme valeur le type de contenu de la valeur EncapsulatedContentInfo à signer. Cependant, cet attribut ne doit pas être utilisé comme partie d'un attribut contersignatures non-signé
message-digest ayant comme valeur le hash du contenu.

signatureAlgorithm identifie l'algorithme de signature, et ses paramètres associés, utilisé par le signataire pour générer la signature numérique.
signature Est le résultat de la génération de la signature, en utilisant le hash et la clé privée du signataire.
unsignedAttrs Est une collection d'attributs qui ne sont pas signés. Ce champ est optionnel.

   Les champs de type SignedAttributes et UnsignedAttributes ont la signification suivante:

attrType Indique le type d'attribut, c'est un identifiant d'objet.
attrValues Est un jeu de valeurs pour cet attribut.

Processus de calcul du hash

   Le processus de calcul du hash calcule un hash sur soit le contenu à signer, soit le contenu et les attributs signés. Dans tous les cas, l'entrée initiale du processus est la valeur du contenu encapsulé à signer. Spécifiquement, l'entrée initiale est la chaîne d'octets eContent de encapContentInfo auquel le processus de signature est appliqué. Seul les octets comprenant la valeur de la chaîne d'octets eContent sont entrés dans l'algorithme de hashage, et non le tag ou les octets de longueur.

   Le résultat du processus de calcul du hash dépend de la présence ou non du champ signedAttrs. Quand le champ est absent, le résultat est simplement le hash du contenu. Quand le champ est présent, cependant, le résultat est le hash de l'encodage DER complet de la valeur SignedAttrs contenu dans le champ signedAttrs. Vu que la valeur SignedAttrs, quand présent, doit contenir les attributs de type de contenu et de hash, ces valeurs sont indirectement incluses dans le résultat. L'attribut content-type ne doit pas être inclus dans un attribut non signé countersignature. Un encodage séparé du champ signedAttrs est effectué pour le calcul du hash. Le IMPLICIT [0] tag dans signedAttrs n'est pas utilisé pour l'encodage DER, et EXPLICIT SET OF tag est utilisé, et doit donc être inclus dans le calcul du hash avec les octets de longueur et de contenu de la valeur SignedAttributes.

   Quand le champ signedAttrs est absent, seul les octets compris dans la valeur de la chaîne d'octets eContent de encapContentInfo du SignedData sont entrés dans le calcul du hash. Cela a l'avantage que la longueur du contenu à signer n'a pas besoin d'être connus à l'avance.

   Bien que le les octets de tag et de longueur de la chaîne d'octets eContent de encapContentInfo ne sont pas inclus dans le calcul du hash, ils sont protégés par d'autres moyens. Les octets de longueur sont protégés par la nature de l'algorithme.

Processus de génération de signature

L'entrée du processus de génération de signature inclus le résultat du processus de calcul du hash et la clé privée du signataire. Les détails de la génération de la signature dépend de l'algorithme de signature employé. L'identifiant d'objet, avec ses paramètres, qui spécifient l'algorithme de signature employé par le signataire sont placés dans le champ signatureAlgoritm. La valeur de la signature générée par le signataire doit être encodé en chaîne d'octets et placés dans le champ signature.

Processus de vérification de signature

   L'entrée du processus de vérification de signature inclus le résultat du processus de calcul du hash et la clé publique du signataire. Le destinataire peut obtenir la bonne clé publique pour le signataire par tous moyens, mais la méthode préférée est depuis un certificat obtenu depuis le champ certificates de SignedData. La sélection et la validation de la clé publique du signataire peut être basée sur la validation du chemin de certification aussi bien que d'autres contextes externes, mais c'est au-delà du scope de ce document. Les détails de la vérification de la signature dépendent de l'algorithme de signature employé.

   Le destinataire ne doit pas s'appuyer sur les valeurs de hash calculés par l'auteur. Si le signerInfo de SignedData inclus un SignedAttributes, alors le hash doit être calculé comme décris plus haut. Pour que la signature soit valide, la valeur du hash calculée par le destinataire doit être la même que la valeur de l'attribut messageDigest inclus dans le signedAttributes du signerInfo du SignedData.

   Si signerInfo du SignedData inclus signedAttributes, alors la valeur de l'attribut content-type doit matcher la valeur eContentType de encapContentInfo du signedData.

Type de contenu Enveloped-data

   Le type de contenu donnée enveloppée consiste d'un contenu chiffré et de clé de chiffrement de contenu chiffrés pour un ou plusieurs destinataires. La combinaison du contenu chiffré et un clé de chiffrement de contenu chiffré pour un destinataire est une enveloppe numérique pour ce destinataire. Tout type de contenu peut être enveloppé pour un nombre arbitraire de destinataires utilisant tout type de technique de gestion de clé supportés pour chaque destinataire.

   L'application typique du type de contenu donnée enveloppée représente une ou plusieurs enveloppes numérique de destinataires sur le contenu des type de de contenu donnée et donnée signée. Enveloped-data est construit par les étapes suivantes:

1. Une clé de chiffrement pour un algorithme de chiffrement de contenu est généré aléatoirement.
2. La clé de chiffrement de contenu est chiffrée pour chaque destinataire. Les détails de ce chiffrement dépend de l'algorithme de gestion de clé utilisé, mais 4 techniques générales sont supportées:

transport de clé La clé de chiffrement de contenu est chiffrée dans la clé publique clé publique du destinataire.
agrément de clé La clé publique du destinataire est la clé privée de l'émetteur sont utilisé pour générer une clé symétrique, puis la clé de chiffrement de contenu est chiffré dans la clé symétrique.
Clé de chiffrement symétrique La clé de chiffrement de contenu est chiffré dans un clé de chiffrement de clé symétrique distribuée précédemment.
mot de passes La clé de chiffrement de contenu est chiffrée dans une clé de chiffrement de contenu qui est dérivée d'un mot de passe ou autre valeur de secret partagée.

3. Pour chaque destinataire, la clé de chiffrement de contenu chiffré et d'autres informations spécifiques au destinataire sont collectés dans une valeur RecipientInfo.
4. Le contenu est chiffré avec la clé de chiffrement de contenu. Le chiffrement de contenu peut nécessiter qui le contenu soit padded à un multiple d'une taille de block.
5. Les valeurs RecipientInfo pour tous les destinataires sont collectés ensemble avec le contenu chiffré pour former une valeur enveloppée.

   Un destinataire ouvre l'enveloppe numérique en déchiffrant celle qui contient les clé de chiffrement de contenu chiffrés puis déchiffre le contenu chiffré avec la clé de chiffrement de contenu récupéré.

   Cette section est divisée en 4 parties. La première partie décris le type EnvelopedData, la seconde partie décris le type d'information par destinataire RecipientInfo, et les troisième et quatrième partie décrivent le chiffrement de contenu et les processus de chiffrement de clé.

Type EnvelopedData

L'identifiant d'objet suivant identifie le type de contenu enveloped-data suivant:
id-envelopedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs7(7) 3 }

Le type donnée enveloppée devrait avoir le type ASN.1 suivant:
EnvelopedData ::= SEQUENCE {
    version CMSVersion,
    originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL,
    recipientInfos RecipientInfos,
    encryptedContentInfo EncryptedContentInfo,
    unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL }

OriginatorInfo ::= SEQUENCE {
    certs [0] IMPLICIT CertificateSet OPTIONAL,
    crls [1] IMPLICIT RevocationInfoChoices OPTIONAL }

RecipientInfos ::= SET SIZE (1..MAX) OF RecipientInfo

EncryptedContentInfo ::= SEQUENCE {
    contentType ContentType,
    contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier,
    encryptedContent [0] IMPLICIT EncryptedContent OPTIONAL }

EncryptedContent ::= OCTET STRING

UnprotectedAttributes ::= SET SIZE (1..MAX) OF Attribute

version Est le numéro de version de la syntaxe. La valeur appropriée dépend de originatorInfo, RecipientInfo, et unprotectedAttrs. La version doit être assignée comme suit:

IF (originatorInfo is present) AND
    ((any certificates with a type of other are present) OR
    (any crls with a type of other are present))
THEN version is 4
ELSE
    IF ((originatorInfo is present) AND
        (any version 2 attribute certificates are present)) OR
        (any RecipientInfo structures include pwri) OR
        (any RecipientInfo structures include ori)
    THEN version is 3
    ELSE
        IF (originatorInfo is absent) AND
            (unprotectedAttrs is absent) AND
            (all RecipientInfo structures are version 0)
        THEN version is 0
        ELSE version is 2

originatorInfo Fournis optionnellement des informations sur l'auteur. Il est présent seulement s'il est requis par l'algorithme de gestion des clés. Il peut contenir des certificats et des crls:

certs est une collection de certificats. certs peut contenir les certificats d'expéditeur associés avec de nombreux algorithmes de gestion de clés. certs peut également contenir des certificats d'attribut associés avec l'expéditeur. Les certificats contenus dans certs sont prévus pour être suffisants pour tous les destinataires pour construire des chemin de validation depuis un root reconnu. Cependant, certs peut contenir plus de certificats que nécessaire, et il peut y avoir les certificats nécessaire pour créer les chemins de validation de 2 ou plusieurs autorité de certification racine. Alternativement, il est prévu que les destinataires aient un moyen alternatif pour obtenir les certificats nécessaires.
crls est une collection de CRL. Il est prévu que ce jeu contienne les informations suffisantes pour déterminer si les certificats dans le champ certs sont valides ou non. Il peut y avoir plus de CRL que nécessaire, et il peut y avoir moins de crl que nécessaire.

recipientInfos est une collection d'information par destinataire, il doit y avoir au moins un élément dans la collection.
encryptedContentInfo Est l'information de contenu chiffré
unprotectedAttrs est une collection d'attributs qui ne sont pas chiffrés. Le champ est optionnel.
EncryptedContentInfo Les champs ont la signification suivante:

contentType Indique le type de contenu
contentEncryptionAlgorithm identifie l'algorithme de chiffrement de contenu, et ses paramètres associés, utilisés pour chiffrer le contenu. Le même algorithme de chiffrement de contenu et la clé de chiffrement de contenu sont utilisé pour tous les destinataires.

Type RecipientInfo

   Les informations par destinataire sont représentés dans le type RecipientInfo. RecipientInfo a un format différent pour chacune des techniques de gestion de clés supportés. Tout type de technique de gestion de clé peut être utilisé pour chaque destinataire de même contenu chiffré. Dans tous les cas, la clé de chiffrement de contenu chiffrée est transféréeà un ou plusieurs destinataires.

   Vu que toutes les implémentations ne vont pas supporter tous les algorithmes de gestion de clés possibles, toutes les implémentations doivent gérer les algorithmes non-implémentés quand ils sont rencontrés. Par exemple, si un destinataire reçoit une clé de chiffrement de contenu chiffrée avec leur clé publique RSA en utilisant RSA-OAEP et que l'implémentation ne supporte que RSA PKCS#1 v1.5, alors l'échec doit être implémentée.

   Les implémentations doit supporter le transport de clé, l'agrément de clé, et les clé de chiffrement de clé symétriques distribués précédemment, comme représentés par ktri, kari, et kekri, respectivement. Les implémentations peuvent supporter la gestion de clé basé sur mot de passe comme représenté par pwri. Les implémentations peuvent supporter d'autres technique de gestion de clé comme représenté par ori. Vu que chaque destinataire peut employer une technique de gestion de clé différente et que les spécifications futures peuvent définir des technique supplémentaires, toutes les implémentation doit manipuler les alternatives non-implémentées, les versions non-implémentées et les ori inconnues.

RecipientInfo ::= CHOICE {
    ktri KeyTransRecipientInfo,
    kari [1] KeyAgreeRecipientInfo,
    kekri [2] KEKRecipientInfo,
    pwri [3] PasswordRecipientinfo,
    ori [4] OtherRecipientInfo }

    EncryptedKey ::= OCTET STRING

Type KeyTransRecipientInfo

Les informations par destinataire utilisant le transport de clé sont représentés dans le type KeyTransRecipientInfo. Chaque instance de KeyTransRecipientInfo transfert la clé de chiffrement de contenu à un destinataire.
KeyTransRecipientInfo ::= SEQUENCE {
    version CMSVersion, -- always set to 0 or 2
    rid RecipientIdentifier,
    keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
    encryptedKey EncryptedKey }

RecipientIdentifier ::= CHOICE {
    issuerAndSerialNumber IssuerAndSerialNumber,
    subjectKeyIdentifier [0] SubjectKeyIdentifier }

version Est le numéro de version de la syntaxe. Si RecipientIdentifier est issuerAndSerialNumber, la version doit être 0. Si c'est subjectKeyIdentifier, la version doit être 2.
rid Spécifie le certificat ou la clé du destinataire qui a été utilisé par l'émetteur pour protéger la clé de chiffrement de contenu. RecipientIdentifier fournis 2 alternatives pour spécifier le certificat du destinataire, et donc la clé publique du destinataire. Le certificat du destinataire doit contenir une clé publique de transport de clé. Donc, un certification X.509v3 d'un destinataire qui contient un extension d'utilisation de clé doit avoir le bin keyEncipherment. L'alternative issuerAndSerialNumber identifie le certificat du destinataire par le dn du fournisseur et le numéro de série du certificat; le sibjectKeyIdentifier identifie le certificat du destinataire par un identifiant de clé.

Quand un certificat X.509 est référencé, l'identifiant de clé matche la valeur de l'extension subjectKeyIdentifier X.509. Quand d'autres formats de certificat sont référencés, les documents qui spécifient le format du certificat et son utilisation avec le CMS doit inclure les détails sur la correspondance le l'identifiant de clé. Pour le traitement du destinataire, les implémentations doivent supporter ces alternatives pour spécifier le certificat du destinataire. Pour l'émetteur, les implémentations doivent supporter au moins un de ces alternatives.

keyEncryptionAlgorithm Identifie l'algorithme de chiffrement de clé et ses paramètres associés, utilisés pour chiffrer la clé de chiffrement de contenu pour le destinataire.
encryptedKey est le résultat du chiffrement de la clé de chiffrement de contenu pour le destinataire.

Type KeyAgreeRecipientInfo

Les informations de destinataire utilisant l'accord de clé est représenté dans le type KeyAgreeRecipientInfo. Chaque instance de KeyAgreeRecipientInfo va transférer la clé de chiffrement de contenu à un ou plusieurs destinataires qui utilisent le même algorithme d'accord de clé et les paramètres de domaine pour cet algorithme.
KeyAgreeRecipientInfo ::= SEQUENCE {
    version CMSVersion, -- always set to 3
    originator [0] EXPLICIT OriginatorIdentifierOrKey,
    ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL,
    keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
    recipientEncryptedKeys RecipientEncryptedKeys }

OriginatorIdentifierOrKey ::= CHOICE {
    issuerAndSerialNumber IssuerAndSerialNumber,
    subjectKeyIdentifier [0] SubjectKeyIdentifier,
    originatorKey [1] OriginatorPublicKey }

OriginatorPublicKey ::= SEQUENCE {
    algorithm AlgorithmIdentifier,
    publicKey BIT STRING }

RecipientEncryptedKeys ::= SEQUENCE OF RecipientEncryptedKey

RecipientEncryptedKey ::= SEQUENCE {
    rid KeyAgreeRecipientIdentifier,
    encryptedKey EncryptedKey }

KeyAgreeRecipientIdentifier ::= CHOICE {
    issuerAndSerialNumber IssuerAndSerialNumber,
    rKeyId [0] IMPLICIT RecipientKeyIdentifier }

RecipientKeyIdentifier ::= SEQUENCE {
    subjectKeyIdentifier SubjectKeyIdentifier,
    date GeneralizedTime OPTIONAL,
    other OtherKeyAttribute OPTIONAL }

SubjectKeyIdentifier ::= OCTET STRING

version Est le numéro de version de la syntaxe. Doit toujours être 3.
originator Est un choix avec 3 alternatives spécifiant la clé publique de l'accord de clé de l'émetteur. L'émetteur utilise la clé privée correspondant et la clé publique du destinataire pour générer une clé paire. La clé de chiffrement de contenu est chiffrée dans la clé paire. L'alternative issuerAndSerialNumber identifie le certificat de l'émetteur, et donc sa clé publique, par dn de fournisseur et numéro de série. l'alternative subjectKeyIdentifier identifie le certificat de l'émetteur par identifiant de clé.

Quand un certificat X.509 est référencé, l'identifiant de clé matche la valeur de l'extension X.509 subjectKeyIdentifier. Quand d'autres format de certificat sont référencés, les documents qui spécifient le format de certificat et son utilisation avec le CMS doit inclure les détails sur le matche d'identifiant de clé. L'alternative originatorKey inclus l'identifiant d'algorithme et la clé publique d'accord de clé de l'émetteur. Cette alternative permet à l'auteur l' anonymité vu que la clé publique n'est pas certifiée. Les implémentations doivent suppporter les 3 alternatives pour spécifier la clé publique de l'émetteur.

ukm est optionnel. Avec certains algorithmes d'accord de clé, l'émetteur fournis un User Keying Material (UKM) pour s'assurer qu'une clé différente est générée chaque fois que les même 2 parties génèrent une clé paire. Les implémentations doivent accepter une séquence KeyAgreeRecipientInfo qui inclus un champ ukm. Les implémentations qui ne supportent par les algorithmes d'accord de clé qui utilisent UKM doivent manipuler correctement la présence des UKM.
keyEncryptionAlgorithm Identifie l'algorithme de chiffrement de clé et ses paramètres associés, utilisé pour chiffrer la clé de chiffrement de contenu avec la clé de chiffrement de clé.
recipientEncryptedKeys Inclus un identifiant de destinataire et une clé chiffrée pour un ou plusieurs destinataires. le KeyAgreeRecipientIdentifier est un choix avec 2 alternatives spécifiant le certificat du destinataire, et donc sa clé publique, qui a été utilisée par l'émetteur pour générer un clé de chiffrement de clé paire. Le certificat du destinataire doit contenir une clé publique d'accord de clé. Donc, un certificat X.509 v3 d'un destinataire qui contient une utilisation de clé étendue doit avoir le bit keyAgreement. La clé de chiffrement de contenu est chiffrée dans la clé de chiffrement de clé paire. L'alternative issuerAndSerialNumber identifie le certificat du destinataire par dn du fournisseur et numéro de série. encryptedKey est le résultat du chiffrement de la clé de chiffrement de contenu dans la clé de chiffrement de clé paire générée en utilisa l'algorithme d'accord de clé. Les implémentations doivent supporter ces alternatives en spécifiant le certificat du destinataire.
subjectKeyIdentifier Identifie le certificat du destinataire par identifiant de clé.
date est optionnel. Quand présent, la date spécifie celle du précédent UKM distribué précédemment qui a été utilisé par l'émetteur.
other est optionnel. Quand présent, ce champ contient des informations additionnels utilisé par le destinataire pour localiser l'UKM utilisé par l'émetteur.

Type KEKRecipientInfo

Les informations de déstinataire utilisant les clés symétriques précédemment distribuées sont représentés dans le type KEKRecipientInfo. Chaque instance de KEKRecipientInfo va transférer la clé de chiffrement de contenu à un ou plusieurs destinataires qui ont la clé de chiffrement de clé distribuée précédemment.
KEKRecipientInfo ::= SEQUENCE {
    version CMSVersion, -- always set to 4
    kekid KEKIdentifier,
    keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
    encryptedKey EncryptedKey }

KEKIdentifier ::= SEQUENCE {
    keyIdentifier OCTET STRING,
    date GeneralizedTime OPTIONAL,
    other OtherKeyAttribute OPTIONAL }

version est le numéro de version de la syntaxe. Doit être 4.
kekid spécifie un clé de chiffrement de clé symétrique qui a été distribué précédemment à l'émetteur en un ou plusieurs destinataires.
keyEncryptionAlgorithm Identifie l'algorithme de chiffrement de clé et ses paramètres associés, utilisé pour chiffrer la clé de chiffrement de contenu avec la clé de chiffrement de clé.
encryptedKey est le résultat du chiffrement de la clé de chiffrement de contenu dans la clé de chiffrement de clé.
keyIdentifier identifie la clé de chiffrement de clé qui a été précédemment distribuée à l'émetteur et un ou plusieurs destinataires.
date optionnel. Quand présent, la date spécifie un clé de chiffrement de clé simple depuis un jeu qui a été distribué précédemment.
other optionnel. Quand présent, ce champ contient des informations optionnelles utilisées par le destinataire pour déterminer la clé de chiffrement de clé utilisée par l'émetteur.

Type PasswordRecipientinfo

Les information de destinataire utilisant un mot de passe ou une valeur secrète partagée est représentée dans le type PasswordRecipientinfo. Chaque instance de PasswordRecipientinfo va transférer la clé de chiffrement de contenu à un ou plusieurs destinataires qui possède un mot de passe ou une valeur secrète partagée. Le type PasswordRecipientinfo est définie dans la rfc3211:
PasswordRecipientInfo ::= SEQUENCE {
    version CMSVersion, -- Always set to 0
    keyDerivationAlgorithm [0] KeyDerivationAlgorithmIdentifier
     OPTIONAL,
    keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
    encryptedKey EncryptedKey }

version est le numéro de version de la syntaxe. Doit être 0.
keyDerivationAlgorithm identifie l'algorithme de dérivation de clé et ses paramètres associés, utilisé pour dériver la clé de chiffrement de clé du mot de passe ou de la valeur secrète partagée. Si ce champ est absent, la clé de chiffrement de clé est fournie depuis une source externe, par example, un jeton cryptographique physique tel qu'une carte à puce.
encryptedKey est le résultat du chiffrement de la clé de chiffrement de contenu avec la clé de chiffrement de clé.

Type OtherRecipientinfo

Les information de destinataire pour les techniques de gestion de clé additionnels sont représentés dans le type OtherRecipientInfo. Le type OtherRecipientInfo permet aux technique de gestion de clé au delà des type précédemment définis d'être spécifiés dans de futures documents. Un identifiant d'objet identifie de manière unique de telles techniques de gestion de clé.
OtherRecipientInfo ::= SEQUENCE {
oriType OBJECT IDENTIFIER,
oriValue ANY DEFINED BY oriType }

oriType identifie la technique de gestion de clé
oriValue contient les éléments de données du protocole nécessaire pour un destinataire utilisant la technique de gestion de clé identifiée.

Processus de chiffrement de contenu

La clé de chiffrement de contenu pour l'algorithme de chiffrement de contenu désiré est généré aléatoirement. La donnée à protéger est padded comme décris plus bas, puis cette donnée est chiffrée en utilisant la clé de chiffrement de contenu. L'opération de chiffrement mappe une chaîne d'octets arbitraire (la donnée) en une autre chaîne d'octets (le texte chiffré) sous le contrôle d'une clé de chiffrement de contenu. La donnée chiffrée est inclue dans encryptedContent de encryptedContentInfo du EnvelopedData.

Certains algorithmes de chiffrement de contenu assument que la longueur d'entrée est un multiple de k octets, où k est supérieur à 1. Pour de tels algorithmes, l'entrée devrait être complétée à la fin avec des octets k-(lth mod k) ayant pour valeur (k-lth mod k), où lth est la longueur de l'entrée. En d'autres termes, l'entrée est complétées à la fin avec une des chaînes suivantes:
__________01 -- if lth mod k = k-1
_______02 02 -- if lth mod k = k-2
__________.
__________.
__________.
k k ... k k -- if lth mod k = 0

Le padding peut être supprimé de manière non ambigu vu que toute l'entrée est paddée, incluant les valeurs d'entrée qui sont déjà un multiple de la taille de block, et aucune chaîne de padding n'est un suffix d'un autre. Cette méthode de padding est définie si et seulement si k est inférieur à 256.

Processus de chiffrement de clé

L'entrée du processus de chiffrement de clé -- la valeur fournie à l'algorithme de chiffrement de clé du destinataire -- est simplement la valeur de la clé de chiffrement de contenu.

N'importe quelle technique de gestion de clé mentionnées dans ce document peuvent être utilisées pour chaque destinataire de même contenu chiffré.

Type de contenu Digested-Data

   Le type de contenu donnée hashée consiste d'un contenu de n'importe quel type et un hash du contenu. Typiquement, le type de contenu donnée hashée est utilisé pour fournir une intégrité de contenu, et le résultat devient généralement un entrée au type de contenu donnée enveloppée. Les étapes suivantes construisent une donnée hashée:

1. Un hash est calculé sur le contenu avec un algorithme de hashage.
2. L'algorithme de hashage et le hash sont collectés ensemble avec le contenu dans une valeur DigestedData.

   Un destinataire vérifie le hash en comparant le hash à un hash calculé indépendamment.

L'identifiant d'objet suivant identifie le type de contenu digested-data:
id-digestedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs7(7) 5 }

Le type de contenu digested-data devrait avoir le type ASN.1:
DigestedData ::= SEQUENCE {
    version CMSVersion,
    digestAlgorithm DigestAlgorithmIdentifier,
    encapContentInfo EncapsulatedContentInfo,
    digest Digest }

Digest ::= OCTET STRING

version est le numéro de version de la syntaxe. Si le type de contenu incapsulé est id-data, la valeur doit être 0, 2 sinon.
digestAlgorithm identifie l'algorithme de hashage et ses paramètres associés.
encapContentInfo est le contenu qui est hashé
digest est le résultat du processus de hashage.

   L'ordre des champs rend possible le traitement d'un valeur DigestedData en une seule passe.

Type de contenu Encrypted-data

   Le type de contenu donnée chiffrée consiste d'un contenu de n'importe quel type, chiffré. À la différence du type de contenu donnée enveloppée, le type de contenu donnée chiffrée n'a ni destinataire, ni clé de chiffrement de contenu. Les clé doivent être gérées par un autre moyen.

   L'application typique du type de contenu chiffré est de chiffré le contenu du type de contenu donnée pour un stockage local, où la clé de chiffrement est dérivée d'un mot de passe.

L'identifiant d'objet suivant identifie le type de contenu encrypted-data:
id-encryptedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs7(7) 6 }

Le type de contenu encrypted-data devrait avoir le type ASN.1:
EncryptedData ::= SEQUENCE {
    version CMSVersion,
    encryptedContentInfo EncryptedContentInfo,
    unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL }

version est le numéro de version de la syntaxe. si unprotectedAttrs est présent, la version doit être 2, 0 sinon.
encryptedContentInfo est le contenu chiffré
unprotectedAttrs est une collection d'attributs qui ne sont pas chiffrés. Ce champ est optionnel.

Type de contenu Authenticated-data

Le type de contenu donnée authentifiée consiste d'un contenu de n'importe quel type, un MAC, et de clés d'authentification chiffrés pour un ou plusieurs destinataires. La combinaison du MAC et d'une clé d'authentification chiffrée pour un destinataire est nécessaire pour que ce destinataire puisse vérifier l'intégrité du contenu. Tout type de contenu peut être protégé pour l'intégrité pour plusieurs destinataires.

Le processus par lequel un donnée authentifiée est construite est faite des étapes suivantes:

1. Une clé d'authentification de message pour un algorithme d'authentification de message particulier est généré aléatoirement.
2. La clé d'authentification de message est chiffrée pour chaque destinataire. Les détails de ce chiffrement dépend de l'algorithme de gestion de clé utilisé.
3. Pour chaque destinataire, la clé d'authentification de message chiffrée et les autres information spécifiques au destinataire sont collectés dans une valeur RecipientInfo.
4. Un utilisant la clé d'authentification de message, l'auteur calcul une valeur MAC sur le contenu. Si l'auteur authentifie une information en plus du contenu, un hash est calculé sur le contenu, le hash du contenu est les autres informations sont authentifiées en utilisant la clé d'authentification de message, et le résultat devient la valeur MAC.

Type AuthenticatedData

L'identifiant d'objet suivant identifie le type de contenu authenticated-data:
id-ct-authData OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) ct(1) 2 }

Le type de contenu authenticated-data devrait avoir le type ASN.1:
AuthenticatedData ::= SEQUENCE {
    version CMSVersion,
    originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL,
    recipientInfos RecipientInfos,
    macAlgorithm MessageAuthenticationCodeAlgorithm,
    digestAlgorithm [1] DigestAlgorithmIdentifier OPTIONAL,
    encapContentInfo EncapsulatedContentInfo,
    authAttrs [2] IMPLICIT AuthAttributes OPTIONAL,
    mac MessageAuthenticationCode,
    unauthAttrs [3] IMPLICIT UnauthAttributes OPTIONAL }

AuthAttributes ::= SET SIZE (1..MAX) OF Attribute

UnauthAttributes ::= SET SIZE (1..MAX) OF Attribute

MessageAuthenticationCode ::= OCTET STRING

version est le numéro de version de la syntaxe. La version doit êtré assignée comme suit:

IF (originatorInfo is present) AND
    ((any certificates with a type of other are present) OR
    (any crls with a type of other are present))
THEN version is 3
ELSE
    IF ((originatorInfo is present) AND
        (any version 2 attribute certificates are present))
    THEN version is 1
    ELSE version is 0

originatorInfo fournis optionnellement des informations sur l'auteur. Il est présent seulement s'il est requis par l'algorithme de gestion de clé. Il peut contenir des certificats, des attributs de certificat, et des CRLs.
recipientInfos Est une collection d'information par destinataire. Il doit y avoir au moins un élément dans la collection.
macAlgorithm est un identifiant d'algorithme MAC. Il identifie l'algorithme MAC et ses paramètres associés, utilisé par l'auteur.
digestAlgorithm identifie l'algorithme de hashage et ses paramètres associés, utilisé pour calculer un hash sur le contenu encapsulé si des attributs authentifiés sont présents. Si ce champ est présent, authAttrs doit l'être également.
authAttrs est une collection d'attributs authentifiés. La structure AuthAttributes doit être encodé DER, même si le reste du la structure est encodée BER. Si cet attribut est présent, il doit contenir au minimum ces 2 attributs:

content-type ayant comme valeur le type de contenu de la valeur EncapsulatedContentInfo qui est authentifée.
message-digest ayant comme valeur le hash du contenu.

mac est le message authentication code
unauthAttrs est une collection d'attributs non authentifiés. Ce champ est optionnel.

Génération du MAC

   Le processus de calcul du MAC calcule un code d'authentification de message sur soit le contenu à authentifier soit un hash du contenu à authentifier avec les attributs authentifié de l'auteur.

   Si le champ authAttrs est absent, l'entrée du processus de calcul MAC est la valeur de la chaîne d'octets de eContent dans encapContentInfo. Seul les octets comprenant la valeur de eContent sont entrées dans l'algorithme MAC; le tag et les octets de longueur sont omis. Cela a l'avantage que la longueur du contenu à authentifier n'a pas besoin d'être connu à l'avance.

   Si le champ authAttrs est présent, les attributs content-type et message-digest doivent être inclus, et l'entrée dans le processus de calcul du mac est l'encodé DER de authAttrs. Un encodage séparé du champ authAttrs est effectué pour un calcul de hash. Le tag implicite dans le champ authAttrs n'est pas utilisé pour l'encodage DER, un jeu explicite de tag est utilisé à la place. ce qui signifie que l'encodé DER du jeu de tag, au lieu du tag implicite, doit être inclus dans le calcul du hash avec les octets de longueur et de contenu de la valeur authAttrs.

   Le processus de calcule du hash calcul un hash sur le contenu à authentifier. L'entrée initiale du processus de calcul du hash est la valeur du contenu encapsulé à authentifier. Spécifiquement, l'entrée est la chaîne d'octets de eContent de encapContentInfo pour lequel le processus d'authentification est appliqué. Seul les octets comprenant la valeur de la chaîne d'octets eContent de encapContentInfo sont entrés dans l'algorithme de hashage, pas le tag ni les octets de longueur. Cela a l'avantage que la longueur du contenu n'a pas besoin d'être connu à l'avance. Bien que le tag et les octets de longueur ne sont pas inclus dans le calcul du hash, il sont protégés par d'autres moyens. Les octets de longueur sont protégés par la nature de l'algorithme de hashage.

   L'entrée du processus de calcul MAC inclus la donnée d'entrée MAC définie précédemment, et une clé d'authentification transportée dans une structure recipientInfo. Les détails du calcul MAC dépend de l'algorithme utilisé. L'identifiant d'objet et ses paramètres, qui spécifie l'algorithme employé par l'auteur est placé dans le champ macAlgorithm. La valeur MAC générée par l'auteur est encodé en chaîne d'octet dans le champ mac.

Vérification du MAC

   L'entrée du processus de vérification du MAC inclus les donnée d'entrée ( déterminées sur la présence ou non du champ authAttrs), et la clé d'authentification dans recipientInfo. Les détails du processus de vérification du MAC dépend de l'algorithme MAC employé.

   Le destinataire ne doit pas se fier aux valeurs MAC et hash de l'auteur. Pour que l'authentification réussisse, la valeur MAC calculée par le destinataire doit être la même que la valeur du champ mac. Similairement, pour que l'authentification réussisse quand le champ authAttrs est présent, le hash du contenu calculé par le destinataire doit être le même que le hash inclus dans l'attribut message-digest.

   Si AuthenticatedData inclus authAttrs, la valeur de l'attribut content-type doit matcher la valeur eContentType de encapContentInfo de AuthenticatedData.

Types utiles

Cette section est divisée en 2 parties. La première définis les identifiants d'algorithme, et la seconde définie d'autres type utiles.

DigestAlgorithmIdentifier

Le type DigestAlgorithmIdentifier identifie un algorithme de hashage. (ex: SHA-1, MD2, et MD5). Un algorithme de hashage mappe un chaîne d'octets ( le contenu ) en une autre chaîne d'octets ( le hash ).

DigestAlgorithmIdentifier ::= AlgorithmIdentifier

SignatureAlgorithmIdentifier

Le type SignatureAlgorithmIdentifier identifie un algorithme de signature, et peut également identifier un algorithme de hashage. (ex: RSA, DSA, DSA avec SHA-1, ECDSA, et ECDSA avec SHA-256). Un algorithme de signature supporte les opérations de génération et de vérification de signature. L'opération de génération de signature utilise le hash et la clé privée du signataire pour générer une valeur signature. L'opération de vérification de signature utilise le hash et la clé publique du signataire pour déterminer si la signature est valide.

SignatureAlgorithmIdentifier ::= AlgorithmIdentifier

KeyEncryptionAlgorithmIdentifier

Le type KeyEncryptionAlgorithmIdentifier identifie un algorithme de chiffrement de clé pour chiffrement une clé de chiffrement de contenu. L'opération de chiffrement mappe une chaîne d'octets ( la clé ) en une autre chaîne d'octets ( la clé chiffrée ) sous le contrôle de la clé de chiffrement. L'opération de déchiffrement est l'inverse de l'opération de chiffrement. Les détails du chiffrement et du déchiffrement dépendent de l'algorithme de gestion de clé utilisé.

KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier

ContentEncryptionAlgorithmIdentifier

Le type ContentEncryptionAlgorithmIdentifier identifie un algorithme de chiffrement de contenu. (ex: Triple-DES et RC2). Un algorithme de chiffrement de contenu supporte les opérations de chiffrement et de déchiffrement. L'opération de chiffrement mappe une chaîne d'octets ( le texte en clair ) en une autre chaîne d'octets ( le texte chiffré ) sous le contrôle de la clé de chiffrement de contenu. L'opération de déchiffrement est l'inverse de l'opération de chiffrement.

ContentEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier

MessageAuthenticationCodeAlgorithm

KeyDerivationAlgorithmIdentifier

Le type KeyDerivationAlgorithmIdentifier est spécifié dans la rfc 3211. Les algorithmes de dérivation de clé convertissent un mot de passe ou une valeur de clé secrète en une clé de chiffrement de clé.

KeyDerivationAlgorithmIdentifier ::= AlgorithmIdentifier

RevocationInfoChoices

   Le type RevocationInfoChoices donne un jeu d'informations de statut de révocation alternatif. Il est prévu que le jeu contienne les informations suffisantes pour déterminer si les certificats et les attributs de certificat avec lequel le jeu est associé sont révoqués. Cependant, il peut y avoir plus d'informations de statut de révocation que nécessaire. Les listes de révocation de certificats X.509 sont la principale source d'informations de statut de révocation, mais tout autre format d'information de révocation peut être supporté. L'alternative OtherRevocationInfoFormat est fournis pour supporter tout autre format de révocation sans modification du CMS.

   CertificateList peut contenir un CRL, une ARL, un Delta CRL, ou un attribut CRL. Toutes ces listes partagent une syntaxe commune. Le type CertificateList donne une CRL. les CRL sont spécifiés dans X.509, et sont prévus pour être utilisés sur l'Internet.

La définition de CertificateList est prise de X.509:
RevocationInfoChoices ::= SET OF RevocationInfoChoice

RevocationInfoChoice ::= CHOICE {
    crl CertificateList,
    other [1] IMPLICIT OtherRevocationInfoFormat }

OtherRevocationInfoFormat ::= SEQUENCE {
    otherRevInfoFormat OBJECT IDENTIFIER,
    otherRevInfo ANY DEFINED BY otherRevInfoFormat }

CertificateChoices

Le type CertificateChoices donne soit un certificat étendus PKCS#6, un ACv1, ACv2, ou tout autre format. L'alternative OtherCertificateFormat est fournis pour supporter tout autre format de certificat sans modification du CMS.
CertificateChoices ::= CHOICE {
    certificate Certificate,
    extendedCertificate [0] IMPLICIT ExtendedCertificate, -- Obsolete
    v1AttrCert [1] IMPLICIT AttributeCertificateV1, -- Obsolete
    v2AttrCert [2] IMPLICIT AttributeCertificateV2,
    other [3] IMPLICIT OtherCertificateFormat }

OtherCertificateFormat ::= SEQUENCE {
    otherCertFormat OBJECT IDENTIFIER,
    otherCert ANY DEFINED BY otherCertFormat }

CertificateSet

   Le type CertificateSet fournis un jeu de certificats. Il est prévu que le jeu soit suffisant pour contenir des chemins de certification depuis une autorité racine vers tour les certificats de l'émetteur avec lequel le jeu est associé. Cependant, il peut y avoir plus de certificats que nécessaire, ou moins que nécessaire.

   La signification précise d'un chemin de certification est hors du scope de ce document. Certaines applications peuvent imposer des limites maximales sur la longueur d'un chemin de certification; d'autre peuvent forcer certaines relations entre les sujets et les fournisseurs de certificats dans un chemin de certification.

  CertificateSet ::= SET OF CertificateChoices

IssuerAndSerialNumber

   Le type IssuerAndSerialNumber identifie un certificat, et donc une entité et une clé publique, par le nom distinct du fournisseur du certificat et un numéro de série de certificat spécifique au fournisseur.

La définition de Name vient de X.501-88 et de CertificateSerialNumber vient de X.509-97:
IssuerAndSerialNumber ::= SEQUENCE {
    issuer Name,
    serialNumber CertificateSerialNumber }

CertificateSerialNumber ::= INTEGER

CMSVersion

Le type CMSVersion donne un numéro de version de syntaxe, pour la compatibilité avec de futures révisions de cette spécification.

CMSVersion ::= INTEGER { v0(0), v1(1), v2(2), v3(3), v4(4), v5(5) }

UserKeyingMaterial

Le type UserKeyingMaterial donne une syntaxe pour UKM. Certains agréments de clé nécessitent UKM pour s'assurer qu'une clé différente est générée à chaque fois que les même 2 parties génèrent une clé pairée. L'émetteur fournis un UKM à utiliser avec un algorithme d'agrément de clé spécifique.

UserKeyingMaterial ::= OCTET STRING

OtherKeyAttribute

Le type OtherKeyAttribute donne une syntaxe pour inclure d'autres attributs de clé qui permettent au destinataire de sélectionner la clé utilisé par l'émetteur. L'identifiant d'objet d'attribut doit être enregistré avec la syntaxe de l'attribut lui-même. L'utilisatino de cette structure devrait être évité vu qu'il peut entraver l'intéropérabilité
OtherKeyAttribute ::= SEQUENCE {
keyAttrId OBJECT IDENTIFIER,
keyAttr ANY DEFINED BY keyAttrId OPTIONAL }

Attributs utiles

Cette section définis les attributs qui peuvent être utilisés avec signed-data, enveloped-data, encrypted-data, ou authenticated-data. La syntaxe de l'attribut est compatible avec X.501. Certains des attributs définis dans cette section ont été définis à l'origine dans PKCS#9; d'autres ont été définis dans une précédente version de cette spécification. Les attributs ne sont pas listés dans un ordre particulier.

D'autres attributs sont définis ailleurs, notamment dans S/MIME v3.1 et dans ESS, qui inclus également des recommandations sur le placement de ces attributs.

Content Type

   Le type d'attribut content-type spécifie le type de contenu de ContentInfo dans une donnée signée ou une donnée authentifié. L'attribut content-type doit être présent quand des attributs signés sont présents dans une donnée signée ou que des attributs authentifiés sont présents dans une donnée authentifiée. La valeur de l'attribut content-type doit matcher la valeur eContentType de encapContentInfo dans la donnée signée ou la donnée authentifiée.

   L'attribut content-type doit être un attribut signé ou un attribut authentifié; il ne doit pas être un attribut non-signé, non-authentifié, ou non-protégé.

L'identifiant d'objet suivant identifie l'attribut content-type:
id-contentType OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3 }

Les valeurs d'attribut content-type ont le type ASN.1:
ContentType ::= OBJECT IDENTIFIER

   Même si la syntaxe est définie comme un jeu d'AttributeValue, un attribut content-type doit avoir un simple valeur d'attribut. 0 ou plusieurs instances de AttributeValue ne sont pas permis.

   Les syntaxe SignedAttributes et AuthAttributes sont chacun définis comme un jeu d'attributs. SignedAttributes dans un signerInfo ne doit pas inclure plusieurs instances de l'attribut content-type. Similairement, AuthAttributes dans un AuthenticatedData ne doit pas inclure plusieurs instances de l'attribut content-type.

Message Digest

   Le type d'attribut message-digest spécifie la hash de la chaîne d'octet eContent de encapContentInfo à signer dans une donnée signée, ou à authentifier dans une donnée authentifiée. pour une donnée signée, le hash est calculé en utilisant l'algorithme de hashage du signataire. Pour une donnée authentifiée, le hash est calculé en utilisant l'algorithme de hashage de l'auteur.

   Dans une donnée signée, le type d'attribut signé message-digest doit être présent quand il y a des attributs signés. dans une donnée authentifiée, le type d'attribut authentifié message-digest doit être présent quand il à des attribut authentifiés.

   L'attribut message-digest doit être un attribut signé ou un attribut authentifié; il ne doit pas être un attribut non-signé, non-authentifié, ou non-protégé.

L'indentifiant d'objet suivant identifie l'attribut message-digest:
id-messageDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 4 }

Les valeurs d'attribut message-digest ont le type ASN.1:
MessageDigest ::= OCTET STRING

   Un attribut message-digest doit avoir une valeur d'attribut simple, même si la syntaxe est définie comme un jeu d'AttributValue. Il ne doit pas y avoir 0 ou plusieurs instances de AttributeValue.

   La syntaxe SignedAttributes et AuthAttributes sont chacun définis comme jeu d'attributs. SignedAttributes dans un signerInfo doit inclure seulement une instance de l'attribut message-digest. Similairement, AuthAttributes dans un AuthenticatedData doit inclure seulement une instance de l'attribut message-digest.

Signing Time

   Le type d'attribut signing-time spécifie la date à laquelle le signataire a effectué la signature. Le type d'attribut signing-time est prévu pour être utilisé dans une donnée signée. Il doit être un attribut signé, ou un attribut authentifié.

L'identifiant d'objet suivant identifie l'attribut signing-time:
id-signingTime OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 5 }

Les valeurs de l'attribut signing-time ont le type ASN.1:
SigningTime ::= Time

Time ::= CHOICE {
    utcTime UTCTime,
    generalizedTime GeneralizedTime }

   Note: la définition de Time matche celui spécifié dans la version 1997 de X.509. Les dates entre le 1 janvier 1950 et le 31 décembre 2049 (inclus) doit être encodé en UTCTime. Toutes dates en dehors de cette plage doivent être encodés en GeneralizedTime.

   Les valeurs UTCTime doivent être exprimés en Coordinated Universal Time ( GMT ) et doivent inclure les secondes ( YYMMDDHHMMSSZ), même où le nombre de secondes est 0. Minuit doit être représenté "YYMMDD000000Z". L'information du siècle est implicit, et le siècle doit être interprété comme suit:

- où YY est supérieur ou égal à 50, l'année doit être interprétée en 19YY
- où YY est inférieur ou égal à 50, l'année doit être interprétée en 20YY.

   Les valeurs GeneratizedTime doivent être exprimées en GMT et doivent inclure les secondes ( YYYYMMDDHHMMSSZ ), même quand le nombre de seconde est 0. Les valeurs GeneralizedTime ne doivent pas inclure des fractions de secondes.

   Un attribut signing-time doit avoir une valeur d'attribut simple, même si la syntaxe est définie comme jeu d'AttributeValue. Il ne doit pas y avoir 0 ou plusieurs instances d'AttributeValue.

   La syntaxe SignedAttributes et la syntaxe AuthAttributes sont chacun définis comme jeu d'attributs. SignedAttributes dans un signerInfo ne doit pas inclure plusieurs instances de l'attribut signing-time. Similairement, AuthAttributes dans un AuthenticatedData ne doit pas inclure plusieurs instances de l'attribut signing-time.

   Aucun prérequis n'est imposé concernant l'exactitude de la date de signature, et l'acceptation d'une date de signature est laissée à la discretion du destinataire. Il est prévu, cependant, que certains signataires, tels que les serveurs time-stamp, vont l'approuver implicitement.

Countersignature

   Le type d'attribut Countersignature spécifie une ou plusieurs signatures sur les octets de contenu de la chaîne d'octets signature dans une valeur signerInfo d'une donnée signée. C'est à dire que le hash est calculé sur les octets comprenant la valeur de la chaîne d'octets, sans inclure le tag ni les octets de longueur. Donc, le type d'attribut countersignature contre-signe ( signe en série) une autre signature.

   L'attribut countersignature doit être un attribut non signé, il ne doit pas être un attribut signé, un attribut authentifié, un attribut non-authentifié, ou un attribut non-protégé.

L'identifiant d'objet suivant identifie l'attribut countersignature:
id-countersignature OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 6 }

Les valeurs d'attribut countersignature ont le type ASN.1:
Countersignature ::= SignerInfo

   Les valeurs countersignature ont la même signification que les valeurs SignerInfo pour les signatures ordinaires, excepté:

1. le champ signedAttributes ne doit pas contenir un attribut content-type, il n'y a pas de type de contenu pour les contre-signatures
2. Le champ signedAttributes doit contenir un attribut message-digest s'il contient d'autres attributs
3. L'entrée du processus de hashage sont les octets de contenu de l'encodé DER du champ signatureValue de la valeur SignerInfo avec lequel l'attribut est associé.

   Un attribut countersignature peut avoir plusieurs valeurs d'attribut. La syntaxe est définie comme jeu d'AttributeValue, et il doit y avoir au moins une valeur présente.

   La syntaxe UnsignedAttributes est définie comme un jeu d'attributs. UnsignedAttributes dans un SignerInfo peut inclure plusieurs instances de l'attribut countersignature.

   Un countersignature, vu qu'il a le type SignerInfo, peut lui-même contenir un attribut countersignature. Donc, il est possible de construire arbitrairement une longue série de contre-signatures.

Modules ASN.1

Cette section contient le module ASN.1 pour le CMS, et la section suivante contient le module ASN.1 pour l'attribut certificat version 1.

Module ASN.1 CMS

CryptographicMessageSyntax2004
    { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2004(24) }

DEFINITIONS IMPLICIT TAGS ::=
BEGIN

-- EXPORTS All
-- Les types et valeurs définies dans ce module sont exportés pour l'utilisation dans
-- d'autres modules ASN.1. D'autres applications peuvent les utiliser pour leur propre usage.

IMPORTS

    -- Imports de la RFC 5280, Appendix A.1
        AlgorithmIdentifier, Certificate, CertificateList,
        CertificateSerialNumber, Name
            FROM PKIX1Explicit88
                { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) mod(0) pkix1-explicit(18) }

    -- Imports de la RFC 3281, Appendix B
        AttributeCertificate
            FROM PKIXAttributeCertificate
                { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) mod(0) attribute-cert(12) }

    -- Imports de l'Appendix B de ce document
        AttributeCertificateV1
            FROM AttributeCertificateVersion1
                { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) v1AttrCert(15) } ;

-- Cryptographic Message Syntax

ContentInfo ::= SEQUENCE {
    contentType ContentType,
    content [0] EXPLICIT ANY DEFINED BY contentType }

ContentType ::= OBJECT IDENTIFIER

SignedData ::= SEQUENCE {
    version CMSVersion,
    digestAlgorithms DigestAlgorithmIdentifiers,
    encapContentInfo EncapsulatedContentInfo,
    certificates [0] IMPLICIT CertificateSet OPTIONAL,
    crls [1] IMPLICIT RevocationInfoChoices OPTIONAL,
    signerInfos SignerInfos }

DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier

SignerInfos ::= SET OF SignerInfo

EncapsulatedContentInfo ::= SEQUENCE {
    eContentType ContentType,
    eContent [0] EXPLICIT OCTET STRING OPTIONAL }

SignerInfo ::= SEQUENCE {
    version CMSVersion,
    sid SignerIdentifier,
    digestAlgorithm DigestAlgorithmIdentifier,
    signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL,
    signatureAlgorithm SignatureAlgorithmIdentifier,
    signature SignatureValue,
    unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL }

SignerIdentifier ::= CHOICE {
    issuerAndSerialNumber IssuerAndSerialNumber,
    subjectKeyIdentifier [0] SubjectKeyIdentifier }

SignedAttributes ::= SET SIZE (1..MAX) OF Attribute

UnsignedAttributes ::= SET SIZE (1..MAX) OF Attribute

Attribute ::= SEQUENCE {
    attrType OBJECT IDENTIFIER,
    attrValues SET OF AttributeValue }

AttributeValue ::= ANY

SignatureValue ::= OCTET STRING

EnvelopedData ::= SEQUENCE {
    version CMSVersion,
    originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL,
    recipientInfos RecipientInfos,
    encryptedContentInfo EncryptedContentInfo,
    unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL }

OriginatorInfo ::= SEQUENCE {
    certs [0] IMPLICIT CertificateSet OPTIONAL,
    crls [1] IMPLICIT RevocationInfoChoices OPTIONAL }

RecipientInfos ::= SET SIZE (1..MAX) OF RecipientInfo

EncryptedContentInfo ::= SEQUENCE {
    contentType ContentType,
    contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier,
    encryptedContent [0] IMPLICIT EncryptedContent OPTIONAL }

EncryptedContent ::= OCTET STRING

UnprotectedAttributes ::= SET SIZE (1..MAX) OF Attribute

RecipientInfo ::= CHOICE {
    ktri KeyTransRecipientInfo,
    kari [1] KeyAgreeRecipientInfo,
    kekri [2] KEKRecipientInfo,
    pwri [3] PasswordRecipientInfo,
    ori [4] OtherRecipientInfo }

EncryptedKey ::= OCTET STRING

KeyTransRecipientInfo ::= SEQUENCE {
    version CMSVersion, -- always set to 0 or 2
    rid RecipientIdentifier,
    keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
    encryptedKey EncryptedKey }

RecipientIdentifier ::= CHOICE {
    issuerAndSerialNumber IssuerAndSerialNumber,
    subjectKeyIdentifier [0] SubjectKeyIdentifier }

KeyAgreeRecipientInfo ::= SEQUENCE {
    version CMSVersion, -- always set to 3
    originator [0] EXPLICIT OriginatorIdentifierOrKey,
    ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL,
    keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
    recipientEncryptedKeys RecipientEncryptedKeys }

OriginatorIdentifierOrKey ::= CHOICE {
    issuerAndSerialNumber IssuerAndSerialNumber,
    subjectKeyIdentifier [0] SubjectKeyIdentifier,
    originatorKey [1] OriginatorPublicKey }

OriginatorPublicKey ::= SEQUENCE {
    algorithm AlgorithmIdentifier,
    publicKey BIT STRING }

RecipientEncryptedKeys ::= SEQUENCE OF RecipientEncryptedKey

RecipientEncryptedKey ::= SEQUENCE {
    rid KeyAgreeRecipientIdentifier,
    encryptedKey EncryptedKey }

KeyAgreeRecipientIdentifier ::= CHOICE {
    issuerAndSerialNumber IssuerAndSerialNumber,
    rKeyId [0] IMPLICIT RecipientKeyIdentifier }

RecipientKeyIdentifier ::= SEQUENCE {
    subjectKeyIdentifier SubjectKeyIdentifier,
    date GeneralizedTime OPTIONAL,
    other OtherKeyAttribute OPTIONAL }

SubjectKeyIdentifier ::= OCTET STRING

KEKRecipientInfo ::= SEQUENCE {
    version CMSVersion, -- always set to 4
    kekid KEKIdentifier,
    keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
    encryptedKey EncryptedKey }

KEKIdentifier ::= SEQUENCE {
    keyIdentifier OCTET STRING,
    date GeneralizedTime OPTIONAL,
    other OtherKeyAttribute OPTIONAL }

PasswordRecipientInfo ::= SEQUENCE {
    version CMSVersion, -- always set to 0
    keyDerivationAlgorithm [0] KeyDerivationAlgorithmIdentifier OPTIONAL,
    keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
    encryptedKey EncryptedKey }

OtherRecipientInfo ::= SEQUENCE {
    oriType OBJECT IDENTIFIER,
    oriValue ANY DEFINED BY oriType }

DigestedData ::= SEQUENCE {
    version CMSVersion,
    digestAlgorithm DigestAlgorithmIdentifier,
    encapContentInfo EncapsulatedContentInfo,
    digest Digest }

Digest ::= OCTET STRING

EncryptedData ::= SEQUENCE {
    version CMSVersion,
    encryptedContentInfo EncryptedContentInfo,
    unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL }

AuthenticatedData ::= SEQUENCE {
    version CMSVersion,
    originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL,
    recipientInfos RecipientInfos,
    macAlgorithm MessageAuthenticationCodeAlgorithm,
    digestAlgorithm [1] DigestAlgorithmIdentifier OPTIONAL,
    encapContentInfo EncapsulatedContentInfo,
    authAttrs [2] IMPLICIT AuthAttributes OPTIONAL,
    mac MessageAuthenticationCode,
    unauthAttrs [3] IMPLICIT UnauthAttributes OPTIONAL }

AuthAttributes ::= SET SIZE (1..MAX) OF Attribute

UnauthAttributes ::= SET SIZE (1..MAX) OF Attribute

MessageAuthenticationCode ::= OCTET STRING

DigestAlgorithmIdentifier ::= AlgorithmIdentifier

SignatureAlgorithmIdentifier ::= AlgorithmIdentifier

KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier

ContentEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier

MessageAuthenticationCodeAlgorithm ::= AlgorithmIdentifier

KeyDerivationAlgorithmIdentifier ::= AlgorithmIdentifier

RevocationInfoChoices ::= SET OF RevocationInfoChoice

RevocationInfoChoice ::= CHOICE {
    crl CertificateList,
    other [1] IMPLICIT OtherRevocationInfoFormat }

OtherRevocationInfoFormat ::= SEQUENCE {
    otherRevInfoFormat OBJECT IDENTIFIER,
    otherRevInfo ANY DEFINED BY otherRevInfoFormat }

CertificateChoices ::= CHOICE {
    certificate Certificate,
    extendedCertificate [0] IMPLICIT ExtendedCertificate, -- Obsolete
    v1AttrCert [1] IMPLICIT AttributeCertificateV1, -- Obsolete
    v2AttrCert [2] IMPLICIT AttributeCertificateV2,
    other [3] IMPLICIT OtherCertificateFormat }

AttributeCertificateV2 ::= AttributeCertificate

OtherCertificateFormat ::= SEQUENCE {
    otherCertFormat OBJECT IDENTIFIER,
    otherCert ANY DEFINED BY otherCertFormat }

CertificateSet ::= SET OF CertificateChoices

IssuerAndSerialNumber ::= SEQUENCE {
    issuer Name,
    serialNumber CertificateSerialNumber }

CMSVersion ::= INTEGER { v0(0), v1(1), v2(2), v3(3), v4(4), v5(5) }

UserKeyingMaterial ::= OCTET STRING

OtherKeyAttribute ::= SEQUENCE {
    keyAttrId OBJECT IDENTIFIER,
    keyAttr ANY DEFINED BY keyAttrId OPTIONAL }

-- Content Type Object Identifiers

id-ct-contentInfo OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) ct(1) 6 }

id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs7(7) 1 }

id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 }

id-envelopedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs7(7) 3 }

id-digestedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs7(7) 5 }

id-encryptedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs7(7) 6 }

id-ct-authData OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) ct(1) 2 }

-- The CMS Attributes

MessageDigest ::= OCTET STRING

SigningTime ::= Time

Time ::= CHOICE {
    utcTime UTCTime,
    generalTime GeneralizedTime }

Countersignature ::= SignerInfo

-- Attribute Object Identifiers

id-contentType OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3 }

id-messageDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 4 }

id-signingTime OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 5 }

id-countersignature OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 6 }

-- Obsolete Extended Certificate syntax from PKCS #6

ExtendedCertificateOrCertificate ::= CHOICE {
    certificate Certificate,
    extendedCertificate [0] IMPLICIT ExtendedCertificate }

ExtendedCertificate ::= SEQUENCE {
    extendedCertificateInfo ExtendedCertificateInfo,
    signatureAlgorithm SignatureAlgorithmIdentifier,
    signature Signature }

ExtendedCertificateInfo ::= SEQUENCE {
    version CMSVersion,
    certificate Certificate,
    attributes UnauthAttributes }

Signature ::= BIT STRING

END -- of CryptographicMessageSyntax2004

Module ASN.1 Certificat d'attribut version 1

AttributeCertificateVersion1
    { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) v1AttrCert(15) }

DEFINITIONS EXPLICIT TAGS ::=
BEGIN

-- EXPORTS All

IMPORTS

    -- Imports from RFC 5280 [PROFILE], Appendix A.1
        AlgorithmIdentifier, Attribute, CertificateSerialNumber,
        Extensions, UniqueIdentifier
            FROM PKIX1Explicit88
                { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) mod(0) pkix1-explicit(18) }

    -- Imports from RFC 5280 [PROFILE], Appendix A.2
        GeneralNames
            FROM PKIX1Implicit88
                { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) mod(0) pkix1-implicit(19) }

    -- Imports from RFC 3281 [ACPROFILE], Appendix B
        AttCertValidityPeriod, IssuerSerial
            FROM PKIXAttributeCertificate
                { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) mod(0) attribute-cert(12) } ;

    -- Définition extraite de X.509-1997, mais des noms de type différents sont utilisés pour éviter les collisions

AttributeCertificateV1 ::= SEQUENCE {
    acInfo AttributeCertificateInfoV1,
    signatureAlgorithm AlgorithmIdentifier,
    signature BIT STRING }

AttributeCertificateInfoV1 ::= SEQUENCE {
    version AttCertVersionV1 DEFAULT v1,
    subject CHOICE {
        baseCertificateID [0] IssuerSerial,
            -- associé avec un certificat à clé publique
        subjectName [1] GeneralNames },
            -- associé avec un nom
    issuer GeneralNames,
    signature AlgorithmIdentifier,
    serialNumber CertificateSerialNumber,
    attCertValidityPeriod AttCertValidityPeriod,
    attributes SEQUENCE OF Attribute,
    issuerUniqueID UniqueIdentifier OPTIONAL,
    extensions Extensions OPTIONAL }

AttCertVersionV1 ::= INTEGER { v1(0) }

END -- of AttributeCertificateVersion1

21 décembre 2014

rfc5755

Profil de certificat d'attribut Internet pour l'autorisation

Introduction

   Les certificats à clé publique X.509 (PKCs) lien une identité et une clé publique. Un certificat d'attribut (AC) est une structure similaire à PKC; la principale différence est que AC ne contient pas de clé publique. Un AC peut contenir des attributs qui spécifie l'appartenance à un groupe, un rôle, habilitation, ou d'autres informations d'autorisation associés avec le titulaire de l'AC.

   La syntaxe pour AC est définie dans Recommendation X.509, rendant le terme "X.509 Certificate' ambigus.

   Certaines personnes confondent constamment PKCs et ACs. Un analogie peut rendre la distinction plus claire. An PKC peut être considéré comme un passeport: il identifie le titulaire, tend à durer longtemps, et ne devrait pas être trivial à obtenir. Un AC est plus comme un visa d'entrée: il est typiquement utilisé par une autorité différente et ne dure pas très longtemps.

   Les informations d'autorisation peuvent être placés dans une extension PKC ou placé dans un certificat d'attribut séparé. Le placement des informations d'autorisation dans les PKCs est généralement indésirable pour 2 raisons. D'abord, les informations d'autorisation n'ont pas la même durée de vie que la liaison de l'identité et de la clé publique. Ensuite, le fournisseur PKC n'a généralement pas autorité pour les informations d'autorisation.

   Pour ces raisons, il est souvent meilleur de séparer les informations d'autorisation des PKC. Les informations d'autorisation doivent également être liées a une identité. Un AC fournis cette liaison; c'est simplement une identité signé ou certifiée numériquement et un jeu d'attributs.

   Un AC peut être utilisé avec divers services de sécurité, incluant le contrôle d'accès, authentification de l'origine des données, et la non-répudiation.

   les PKCs peuvent fournir une identité à des fonctions de contrôle d'accès. Cependant, dans de nombreux contextes, l'identité n'est pas le critère qui est utilisé pour les décisions de contrôle d'accès, mais plutôt le rôle ou l'appartenance à un groupe. De tels schémas de contrôles d'accès sont appelé RBAC.

   En créant des décisions de contrôle d'accès basé sur un AC, une fonction de décision de contrôle d'accès peut nécessiter de s'assurer que le titulaire de l'AC approprié est l'entité qui a demandé l'accès. Une manière de lier la demande ou l'identité et l'AC peut être accomplie par l'inclusion d'une référence à un PKC dans l'AC et l'utilisation de la clé privée correspondante au PKC pour l'authentification dans la demande d'accès.

   Les AC peuvent également être utilisés dans le contexte de service d'authentification de l'origine des données et de non-répudiation. Dans ces contextes, les attributs contenus dans l'AC fournis des informations additionnels sur l'identité du signataire. Cet information peut être utilisée pour s'assurer que l'identité est autorisée à signer la donnée. Ce genre de vérification dépend soit du contexte dans lequel la donnée est échangée soit sur la donnée qui a été signée numériquement.

Délégation de chemin d'AC

   Le standard X.509 définis l'autorisation comme le "transport de privilège d'une entité qui détient ce privilège, à une autre identité.". Un AC est un mécanisme d'autorisation.

   Une séquence ordonnée d'AC pourrait être utilisée pour vérifier l'authenticité des privilège du déclarant. De cette manière, les chaînes et chemins d'AC pourraient être employés pour déléguer l'autorisation.

   Vu que l'administration est le traitement associé avec de telles chaînes AC est complexe et que l'utilisation des AC dans l'Internet aujourd'hui est limitée, il est recommandé que les implémentations de cette spécification n'utilisent pas les chaînes d'AC. D'autres futures spécifications peuvent adresser l'utilisation de chaînes d'AC. Cette spécification s'occupe de cas simples, où une autorité gère tous les AC pour un jeu d'attributs particuliers. Cependant, cette simplification n'exclus par l'utilisation de plusieurs autorités différentes, chacune d'entre elles gérant un jeu d'attributs différents. Par exemple, l'appartenance à un groupe peut être inclus dans un AC fournis par une autorité, et les habilitations de sécurité peuvent être inclus dans un autre AC par une autre autorité.

   Cela signifie que les implémentations conformes doivent seulement être capable de traiter un simple AC à la fois. Le traitement de plus d'un AC, un après l'autre, peut être nécessaire. Noter cependant, que la validation d'un AC peut nécessiter une validation d'une chaîne de PKCs.

Distribution de certificat d'attributs

   Comme discuté plus haut, les AC fournissent un mécanisme pour fournir de manière sécurisé des informations d'autorisation pour, par exemple, des fonctions de décision de contrôle. Cependant, il y a un nombre de chemins de communication possible pour les AC.

   Dans certains environnements, il est possible pour un client de "pousser" un AC à un serveur. Cela signifie qu'il n'y a pas de nouvelle connexion entre le client et le serveur. Ce la signifie également qu'aucune charge de recherche n'est imposée sur les serveurs, ce qui améliore les performances et le vérificateur d'AC est seulement présenté avec ce que l'on a besoin de connaître. Le modèle "push" est préférable spécialement dans les cas inter-domaines où les droits des client devraient être assignés dans le domaine du client.

   Dans d'autres cas, il est préférable pour un client de simplement s'authentifier auprès du serveur et de lui demander ( "pull" ) l'AC du client depuis un fournisseur d'AC. Un bénéfice majeur est du modèle "pull" est qu'il peut être implémenté sans changements sur le client ou dans le protocole. Le modèle "pull" est préférable spécialement pour les cas inter-domaines où les droits du client devraient être assignés dans le domaine du serveur.

   Il y a un certain nombre d'échanges possibles impliquant 3 entités: Le client, le serveur, et le fournisseur d'AC. En plus, un service d'annuaire ou d'autres annuaire pour la récupération d'AC peuvent être supportés.

La Figure 1 montre un vue abstraite des échanges qui peuvent se produire. Ce profile ne spécifie pas de protocole pour ces échanges:
______+--------------+__________________________________________
______|______________|________Server_Acquisition________________
______|__AC_issuer___+‹---------------------------+_____________
______|______________|____________________________|_____________
______+--+-----------+____________________________|_____________
_________^________________________________________|_____________
_________|_Client_________________________________|_____________
_________|_Acquisition____________________________|_____________
_________v________________________________________v_____________
______+--+-----------+_________________________+--+------------+
______|______________|_______AC_"push"_________|_______________|
______|___Client_____+‹------------------------|____Server_____|
______|______________|_(part_of_app._protocol)_|_______________|
______+--+-----------+_________________________+--+------------+
_________^________________________________________^_____________
_________|_Client_________________________________|_Server______
_________|_Lookup________+--------------+_________|_Lookup______
_________|_______________|______________|_________|_____________
_________+--------------›+__Repository__+‹--------+_____________
_________________________|______________|_______________________
_________________________+--------------+_______________________
_
____________________________Figure_1:_AC_Exchanges______________

Terminologie

Par simplicité, on utilise les termes client et serveur dans cette spécification. Cela n'est pas prévu pour indiquer que les AC sont seulement utilisé dans des environnements client/serveur. Par exemple, les AC peuvent être utilisé dans un contexte S/MIME v3.2, où le MUA serait à la fois client et serveur dans le sens des termes utilisés ici.

AA Attribute Autority, l'entité qui fournis l'AC, synonyme dans cette spécification avec "fournisseur de CA"
AC Attribute Certificate
AC user Une entité qui parse ou traite un AC
AC verifier Une entité qui vérifie la validité d'un AC et utilise le résultat
AC issuer L'entité qui signe l'AC: synonyme de AA
Client L'entité qui demande l'action pour laquelle les vérifications d'autorisation doivent êtes faites
Proyxing Dans cette spécification, le proxying est utilisé pour signifier la situation où un serveur d'application agit comme application cliente à la demande de l'utilisateur.
PKC Public Key Certificates - utilise les certificats de type ASN.1 définis dans X.509 et profilé dans la rfc5280.
Server L'entité qui nécessite qu'une vérification d'autorisation soit faite.

Pré-requis

Ce profile AC à les pré-requis suivants:

1. Support pour les AC à durée de vie courte et longue. Une période de validité courte typique peut se mesurer en heures, en mois pour les PKC. Les périodes de validité courtes permettent aux AC d'être utiles sans mécanisme de révocation.
2. Les fournisseurs d'AC devraient être capable de définir leur propres types d'attributs à utiliser dans les domaines fermés.
3. Certains types d'attributs standard, qui peuvent être contenus dans les AC devraient être définis. Par exemple "access identity", "group", "role", "clearance", "audit identity", et "charging identity".
4. Les type d'attributs standard devraient être définis d'une manière qui permette à un AC verifier de distinguer l'utilisation de mêmes attributs dans des domaines différents. Par exemple, "Administrators group" comme définis par "Baltimore" et "Administrators group" définis par "SPYRUS" devraient être facilement distincts.
5. Il devrait être possible de cibler un AC à un ou un petit nombre de serveurs. Cela signifie qu'un serveur non-ciblé sera rejeté par les décisions d'autorisation d'AC.
6. Les AC devaient être définis pour qu'il puissent être soit "pushed" par le client au serveur, ou "pulled" par le serveur depuis un dépôt ou un service réseaux, incluant un fournisseur d'AC online.

Profile de certificat d'attribut

   Les AC peuvent être utilisés dans un large éventail d'applications et d'environnements, couvrant un large spectre de besoins opérationnels et d'assurances. Le but de ce document est d'établir une base commune pour des applications génériques nécessitant une grande interopérabilité et des besoins spéciaux limités. En particulier, l'accent sera mis sur le support de l'utilisation de certificats d'attributs pour les messages électroniques, IPsec, et les applications www.

   Cette section présente un profile pour les AC qui va favoriser l'interopérabilité. Cette section définis également certaines extensions pour la communauté internet.

  Alors que les documents ISO/IEC/ITU utilisent la version 1993 (ou ultérieur) de ASN.1, ce document utilise la syntaxe ASN.1 1988, comme pour les PKCs.

Définition de certificat d'attribut X.509

X.509 contient la définition d'un AC donné ci-dessous. Tous les types qui ne sont pas définis dans ce document peuvent être trouvés dans la rfc 5280.
AttributeCertificate ::= SEQUENCE {
    acinfo AttributeCertificateInfo,
    signatureAlgorithm AlgorithmIdentifier,
    signatureValue BIT STRING
}

AttributeCertificateInfo ::= SEQUENCE {
    version AttCertVersion, -- version is v2
    holder Holder,
    issuer AttCertIssuer,
    signature AlgorithmIdentifier,
    serialNumber CertificateSerialNumber,
    attrCertValidityPeriod AttCertValidityPeriod,
    attributes SEQUENCE OF Attribute,
    issuerUniqueID UniqueIdentifier OPTIONAL,
    extensions Extensions OPTIONAL
}

AttCertVersion ::= INTEGER { v2(1) }

Holder ::= SEQUENCE {
    baseCertificateID [0] IssuerSerial OPTIONAL,
        -- le issuer et serial number du titulaire du certificat à clé publique
    entityName [1] GeneralNames OPTIONAL,
        -- le nom du demandeur ou du rôle
    objectDigestInfo [2] ObjectDigestInfo OPTIONAL
        -- Utilisé pour authentifier directement le titulaire, par exemple, un exécutable.
}

ObjectDigestInfo ::= SEQUENCE {
    digestedObjectType ENUMERATED {
        publicKey (0),
        publicKeyCert (1),
        otherObjectTypes (2) },
    -- otherObjectTypes ne doit pas être utilisé dans ce profile
    otherObjectTypeID OBJECT IDENTIFIER OPTIONAL,
    digestAlgorithm AlgorithmIdentifier,
    objectDigest BIT STRING
}

AttCertIssuer ::= CHOICE {
    v1Form GeneralNames, -- ne doit pas être utilisé dans ce profile
    v2Form [0] V2Form -- v2 only
}

V2Form ::= SEQUENCE {
    issuerName GeneralNames OPTIONAL,
    baseCertificateID [0] IssuerSerial OPTIONAL,
    objectDigestInfo [1] ObjectDigestInfo OPTIONAL
        -- issuerName doit être présent dans ce profile
        -- baseCertificateID et objectDigestInfo ne doivent pas être présents dans ce profile
}

IssuerSerial ::= SEQUENCE {
    issuer GeneralNames,
    serial CertificateSerialNumber,
    issuerUID UniqueIdentifier OPTIONAL
}

AttCertValidityPeriod ::= SEQUENCE {
    notBeforeTime GeneralizedTime,
    notAfterTime GeneralizedTime
}

Bien que la syntaxe d'attribut soit définis dans la rfc 5280, on répète la définition ici par commodité:
Attribute ::= SEQUENCE {
    type AttributeType,
    values SET OF AttributeValue
        -- Au moins une valeur est requise
}

AttributeType ::= OBJECT IDENTIFIER

AttributeValue ::= ANY DEFINED BY AttributeType

   Les implémenteurs devraient noter que l'encodage DER des valeurs de jeu nécessitent d'ordonner l'encodage des valeurs. Bien que cette question se pose avec les dn, et doit être géré avec l'implémentation rfc 5280, il est plus important dans ce contexte, vu que les valeurs multiples sont plus courantes dans les AC.

Profile des champs standards

   GeneralName offre une grande flexibilité. Pour parvenir à l'interopérabilité, en dépit de cette souplesse, ce profile impose des contraintes à l'utilisation de GeneralName.

   Les implémentations doivent être capable de supporter dNSName, directoryName, uniformResourceIdentifier, et iPAddress. C'est compatible avec les pre-requis de GeneralName dans la rfc 5280. Les implémentations doivraient également supporter SRVName, et ne doivent pas utiliser x400Address, ediPartyName et registeredID.

   Les implémentations peuvent utiliser otherName pour transmettre les formes de nom définis dans les standards Internet. Par exemple, le format kerberos des noms peut être encodé dans otherName, en utilisant l'OID du nom principal kerberos v5 et une séquence de domaine et du PrincipalName.

Version

Le champ version doit avoir la valeur v2. Le champ version est présent dans l'encodage DER.

Note: cette version n'est pas compatible avec les précédentes définition des certificats d'attribut du standard X.509-1997, mais est compatible avec la définition v2 X.509-2000.

Holder

   Le champ Holder est une séquence permettant 2 syntaxes optionnelles différentes: baseCertificateID, entityName, et objectDigestInfo. Où seul une option est présente, la signification du champ Holder est claire.

   Cependant, quand plus d'une option est utilisée, il y a une confusion possible, laquelle est normative, laquelle est une allusion, etc. Vu que la position correcte n'est pas claire dans X.509-2000, cette spécification recommande que seule une de ces options soit utilisée dans un AC donné.

   Pour tout environnement où l'AC est passée dans un message authentifié ou une session et où l'authentification est basée sur l'utilisation d'un PKC X.509, le champ Holder devrait être le baseCertificateID.

   Avec l'option baseCertificateID, le serialNumber et issuer du PKC du titulaire doit être identique au champ Holder de l'AC. Le fournisseur PKC doit avoir un dn non vide qui doit être présent comme simple valeure de la construction holder.baseCertificateID.issuer dans le champ directoryName. Le champ holder.baseCertificateID.issuerUID de l'AC doit seulement être utilisé si le PKC du titulaire contient un champ issuerUniqueID. Si le champs holder.baseCertificateID.issuerUID de l'AC et le champ issuerUniqueID du PKC sont présents, la même valeur doit être présente dans ces 2 champs. Donc, baseCertificateID est seulement utilisable avec les profiles PKC qui mandatent que le champ issuer du PKC contient une valeur dn non-vide.

   Note: un dn vide est un dn où la séquence de dn relatifs à une longueur de 0. Dans un encodage DER, il a la valeur '3000'H.

   Si le champ Holder utilise l'option entityName et que l'authentification sous-jacent est basée sur un PKC, entityName doit être le même que le champ subject du PKC ou une des valeurs de subjectAltName du PKC ( si présent ). Noter que la rfc 5280 mandate que l'extension subjectAltName soit présente si le sujet du PKC est un dn vide.

   Dans tous les cas où le champ Holder utilise l'option entityName, seul un nom devrait être présent.

   Les implémentations se conformant à ce profile ne sont pas obligés de supporter l'utilisation du champ objectDigest.

   Tout protocole se conformant à ce profile devrait spécifier quel option de titulaire de l'AC doit être utilisé et comment cela s'intègre avec les schémas d'authentification supportés définis dans ce protocole.

Issuer

Les AC se conformant à ce profile doivent utiliser le choix v2Form, qui doit contenir un et un seul GeneralName dans le issuerName, qui doit contenir un dn non-vide dans le champ directoryName. Cela signifie que tous les fournisseurs d'AC doivent avoir des noms distincts non-vide. Les AC se conformant à ce profile doivent omettre les champs baseCertificateID et objectDigestInfo.

Une des raisons d'utiliser v2Form contenant seulement un issuerName et que cela le fournisseur n'a pas à connaître quel PKC l'AC verifier va utiliser. Utiliser le champ baseCertificateID pour référencer le fournisseur d'AC signifie que l'AC verifier doit faire confiance au PKC que le fournisseur d'AC choisis pour lui à la création de l'AC.

Signature

Contient l'identifiant d'algorithme utilisé pour valider la signature AC. Doit être un des algorithmes de signature définis dans les rfc3279, rfc4055, rfc5480, et rfc5756, ou définis dans une mise à jour approuvée par l'ietf de ces rfc. Les implémentations conformes doivent honorer toutes les déclarations MUST/SHOULD/MAY des algorithmes de signature.

SerialNumber

   Pour tout AC conforme, la paire issuer/serialNumber doit former une combinaison unique, même si les AC ont une durée de vie très courte. Les fournisseurs d'AC doivent s'assure que le serialNumber est un nombre positif, qui est, le bit de signe dans l'encodage DER de la valeur integer doit être 0. Cela peut être fait en ajoutant un '00'H gauche si nécessaire. Cela supprime une ambiguïté dans le mappage entre une chaîne d'octets et une valeur entière.

   En donnant un timing et une unicité requise, les numéros de série peuvent contenir des entiers longs. Les utilisateurs d'AC doivent être capable de manipuler les valeurs de serialNumber supérieurs à 4 octets. Les AC conformes ne doivent pas contenir de valeurs serialNumber supérieurs à 20 octets.

   Il n'y a pas de pré-requis pour que le numéro de série utilisé par un fournisseur d'AC suive un ordre particulier. En particulier, ils nécessitent de ne pas être incrémentés monotoniquement avec le temp. Chaque fournisseur d'AC doit s'assurer que chaque AC qu'il fournis contient un numéro de série unique.

Période de validité

   Le champ attrCertValidityPeriod spécifie la période pour laquelle le fournisseur d'AC certifie que le lien entre le titulaire et les champs d'attributs sont valides.

   Le type GeneralizedTime est un type ASN.1 standard pour représenter le temps. Ce champ peut optionnellement inclure une représentation du temps différentiel entre la zone de temps local et GMT.

   Pour ce profile, les valeurs GeneralizedTime doivent être exprimés en UTC et doivent inclure les secondes (ex: YYYYMMDDHHMMSSZ), même quand le nombre de seconde est 0. Les valeurs GeneralizedTime ne doivent pas inclure les fractions de secondes.

   Les utilisateurs d'AC doivent être capable de manipuler un AC que, au moment du traitement, a des parties de sa période de validité ou toute sa période de validité dans le passé ou dans le future. C'est valide pour certaines applications, tels que les backups.

Attributes

   Le champ attributes donne des informations sur le titulaire de l'AC. Quand l'AC est utilisé pour l'autorisation, il contient souvent un jeu de privilèges.

   Le champ attributes contient une séquence d'attributs. chaque attribut contient le type de l'attribut et un jeu de valeurs. Pour un AC donné, chaque identifiant d'object AttributeType dans la séquence doit être unique, mais peut être multi-valué.

   Les utilisateurs d'AC doivent être capable de manipuler plusieurs valeurs pour tous les types d'attributs. Un AC doit contenir au moins un attribut, c'est à dire une séquence d'Attributes de longueur non-zéro.

Issuer Unique Identifier

Ce champ ne doit pas être utilisé à moins qu'il est également utilisé dans le PKC du fournisseur d'AC, auquel cas il doit être utilisé. Noter que la rfc5280 indique que ce champ ne devrait pas être utilisé par les autorités de certification conformes, mais ces applications devraient être capable de gérer les PKCs contenant ce champ.

Extensions

   Le champ extensions donne généralement des informations sur l'AC, en opposé aux informations sur le titulaire de l'AC.

   Un AC qui n'a pas d'extensions est conforme avec ce profile. Cependant les sections suivantes définissent des extensions qui peuvent être utilisé avec ce profile, et indique s'ils sont à marquer critiques. Si une autre extension critique est utilisé, l'AC n'est pas conforme à ce profile. Cependant, si une autre extension non-critique est utilisée, l'AC est conforme à ce profile.

   Les extensions définie pour les AC fournissent des méthodes pour associer les attributs additionnels avec les titulaires. Ce profile permet aux communautés de définir des extensions privées pour les informations unique à ces communautés. Chaque extension dans un AC peut être désigné comme critique ou non-critique. Un system utilisant les AC doit rejeter un AC s'il rencontre une extension critique qu'il ne reconnaît pas; cependant, une extension non-critique peut être ignorée s'il ne la reconnaît pas.

Audit Identity

   Dans certaines circonstances, il est requis ( par ex: protection des données ) que chemins d'audit ne contiennent pas d'enregistrement qui identifie directement les individus. Cette circonstance peut rendre le champ Holder inutilisable dans les chemins d'audit.

   Pour permettre de tels cas, un AC peut contenir une extension d'identité d'audit. Idéalement, il devrait être impossible de dériver l'identité du titulaire depuis la valeur de l'identité d'audit sans la coopération du fournisseur d'AC.

   La valeur de l'identité d'audit, avec le issuer/serial, devrait être utilisé dans un but d'audit/logging. Si la valeur de l'identité d'audit est bien choisis, un serveur/administrateur de service peut utiliser les traces d'audit pour tracer le comportement du titulaire de l'AC sans être capable d'identifier ce titulaire.

   Le serveur/administrateur de service en combinaison avec le fournisseur d'AC doit être capable d'identifier le titulaire de l'AC dans les cas où des problèmes sont détectés. Cela signifie que le fournisseur d'AC doit être capable de déterminer l'identité actuelle du titulaire de l'AC depuis l'identité d'audit.

   Bien évidemment, l'audit pourrait être basée sur la paire issuer/serial; cependant, cette méthode ne permet pas de tracer le même titulaire avec plusieurs AC. Donc, une identité d'audit n'est utile que si elle dure plus longtemps que la durée de vie typique d'un AC. L'audit pourrait également être basée sur le issuer/serial du PKC du titulaire de l'AC; cependant, cela permet souvent au serveur/administrateur de service d'identifier le titulaire de l'AC.

   Un AC verifier peut sinon utiliser holder ou d'autres valeur identifiant pour un but d'audit, cette extension doit être critique quand elle est utilisée.

   Les protocoles qui utilisent les AC vont souvent exposer l'identité du titulaire. Dans de tels cas, une identité d'audit opaque n'utilise pas d'AC anonyme; il s'assure simplement que les traces d'audit ne contiennent pas d'information d'identification.

La valeur d'une identité d'audit doit être plus longue que 0 octet. La valeur d'une identité d'audit ne doit pas être plus longue que 20 octets.
name id-pe-ac-auditIdentity
OID { id-pe 4 }
syntax OCTET STRING
criticality MUST be TRUE

AC Targeting

   Pour cibler un AC, l'extension d'information de cible, importé depuis X.509-2000, peut être utilisé pour spécifier un nombre de serveurs/services. Le but est que l'AC devrait seulement être utilisable sur les serveurs/services spécifiés. Un AC verifier ( honnête ) qui n'est pas parmi les serveurs/services nommés doit rejeter l'AC.

   Si cette extension n'est pas présente, l'AC n'est pas ciblée et peut être accepté par n'importe quel serveur. Dans ce profile, les informations de cible consiste simplement d'une liste de cibles nommés, ou de groupes.

La syntaxe suivante est utilisée pour représenter les informations de cible:
Targets ::= SEQUENCE OF Target

Target ::= CHOICE {
    targetName [0] GeneralName,
    targetGroup [1] GeneralName,
    targetCert [2] TargetCert
}

TargetCert ::= SEQUENCE {
    targetCertificate IssuerSerial,
    targetName GeneralName OPTIONAL,
    certDigestInfo ObjectDigestInfo OPTIONAL
}

   Le choix targetCert dans la structure Target est seulement présente pour permettre de futures compatibilités avec X.509-2000 et ne doit pas être utilisé.

   Les vérifications de cible réussissent si le serveur courant ( le destinataire ) est un des champs targetName dans la séquence Targets, ou si le serveur courant est un membre d'un des champs targetGroup dans la sequence Targets. Dans ce cas, le serveur courant est dit "correspondre" à l'extension de ciblage.

   La manière de déterminer si la cible est dans un targetGroup n'est pas déterminés ici. Il est assumé que la cible donnée connaît les noms des targetGroups pour lequel il appartient ou peut déterminer ses membres. Par exemple, le targetGroup spécifie un domaine DNS, et l'AC verifier connaît le domaine DNS auquel il appartient. Pour un autre exemple, targetGroup spécifie "PRINTERS" et l'AC verifier sait s'il est ou non une imprimante ou un serveur d'impression.

   Note: X.509-2000 définis la syntaxe d'extension comme une séquence de target. Les implémentations de fournisseur d'AC conformes doivent seulement produire un élément Targets. Les utilisateurs d'AC doivent être capable d'accepter une sequence de Targets. Si plus d'un élément Targets est trouvé dans l'AC, l'extension doit être traitée comme si tous les éléments Target avaient été trouvés dans un élément Targets.

name id-ce-targetInformation
OID { id-ce 55 }
syntax SEQUENCE OF Targets
criticality MUST be TRUE

Authority Key Identifier

L'extension authorityKeyIdentifier, comme profilé dans la rfc 5280, peut être utilisée pour assister l'AC verifier dans la vérification de la signature de l'AC. La description de la rfc 5280 devrait être lue comme si CA signifiait AC issuer. Comme avec les PKC, cette extension devrait être incluse dans les AC.

Note: Un AC, où le champ issuer utilisant le choix baseCertificateID, ne nécessite pas l'extension authorityKeyIdentifier, vu qu'il est explicitement lié à la clé dans le certificat référé. Cependant, l'AC doit utiliser la v2Form avec le choix issuerName, cette duplication ne se produit pas.
name id-ce-authorityKeyIdentifier
OID { id-ce 35 }
syntax AuthorityKeyIdentifier
criticality MUST be FALSE

Authority Information Access

l'extension authorityInfoAccess, comme définis dans la rfc 5280, peut être utilisée pour assister l'AC verifier dans la vérification de statut de révocation de l'AC. Le support pour id-ad-caIssuers accessMethod est optionnel par ce profile vu que les chaînes d'AC ne sont pas attendus.

L'accessMethod suivante est utilisée pour indiquer que la vérification de statut de révocation est fournie pour cet AC, en utilisant OCSP:
id-ad-ocsp OBJECT IDENTIFIER ::= { id-ad 1 }

accessLocation doit contenir une URI, et l'URI doit contenir une URL HTTP qui spécifie l'emplacement d'un répondeur OCSP. Le fournisseur d'AC doit, bien sûr, maintenir un répondeur OCSP à cet emplacement.
name id-ce-authorityInfoAccess
OID { id-pe 1 }
syntax AuthorityInfoAccessSyntax
criticality MUST be FALSE

CRL Distribution Points

l'extension crlDistributionPoints, comme définis dans la rfc 5280, peut être utilisée pour assister l'AC verifier dans la vérification du statut de révocation de l'AC.

Si l'extension crlDistributionPoints est présent, un seul point de distribution doit être présent. l'extension crlDistributionPoints doit utiliser l'option DistributionPointName, qui doit contenir un nom complet, qui doit contenir une forme nom simple. Ce nom doit contenir soit un nom distinct soit une URI. L'URI doit être soit une URL HTTP soit une URL LDAP.
name id-ce-cRLDistributionPoints
OID { id-ce 31 }
syntax CRLDistributionPoints
criticality MUST be FALSE

No Revocation Available

L'extension noRevAvail, définis dans X.509-2000, permet à un fournisseur d'AC d'indiquer qu'aucune information de révocation n'est disponible pour cet AC.

Cette extension doit être non-critique. Un AC vérifier qui ne comprend par cette extension doit être capable de trouver une liste de révocation du fournisseur d'AC, mais la liste de révocation n'inclura jamais l'AC.
name id-ce-noRevAvail
OID { id-ce 56 }
syntax NULL (i.e., '0500'H is the DER encoding)
criticality MUST be FALSE

Types d'attributs

   Certains attributs définis ci-dessous utilisent le type IetfAttrSyntax, également définis ci-dessous. Les raisons d'utiliser ce type sont:

1. Il permet une séparation entre le fournisseur d'AC et l'autorité de stratégie d'attributs. C'est utile pour les situations où une seule autorité de stratégie (par exemple une organisation) alloue des valeurs d'attributs, mais où plusieurs fournisseurs d'AC sont déployés pour les raisons de performances, ou autre.
2. Les syntaxes permises pour les valeurs sont restreintes à des chaînes d'octets, identifiant d'objet, et UTF8String, qui réduit significativement la complexité associée avec les syntaxes plus générales. Tous les attributs multi-valués utilisant cette syntaxe sont restreints pour que chaque valeur utilise le même choix de syntaxe de valeur. Par exemple, le fournisseur d'AC ne doit pas utiliser une valeur avec un oid et une autre valeur avec une chaîne.

IetfAttrSyntax ::= SEQUENCE {
    policyAuthority [0] GeneralNames OPTIONAL,
    values SEQUENCE OF CHOICE {
        octets OCTET STRING,
        oid OBJECT IDENTIFIER,
        string UTF8String
    }
}

   Dans la description ci-dessous, chaque type d'attribut est soit marqué "Multiple Allowed" ou "One Attribute value only; multiple values within the IetfAttrSyntax". Cela réfère au jeu d'AttributeValues; le AttributeType ne se produit qu'une seul fois.

Service Authentication Information

   L'attribut SvceAuthInfo identifie le titulaire de l'AC au serveur/service par un nom, et l'attribut peut inclure des information optionnelles d'authentification spécifiques au service. Typiquement, il contient une paire nom/mot de passe.

   Cet attribut fournis des informations qui peuvent être présentés par l'AC verifier pour être interprété et authentifié par une application séparée dans le système cible. Noter que c'est une utilisation différente de ce qui est prévu pour l'attribut accessIdentity.

Ce type d'attribut est typiquement chiffré quand le champ authInfo contient des information sensibles, tel qu'un mot de passe.
name id-aca-authenticationInfo
OID { id-aca 1 }
syntax SvceAuthInfo
values Multiple allowed

SvceAuthInfo ::= SEQUENCE {
    service GeneralName,
    ident GeneralName,
    authInfo OCTET STRING OPTIONAL
}

Access Identity

L'attribut accessIdentity identifie le fournisseur d'AC au serveur/service. Pour cet attribut le champ authInfo ne doit pas être présent.

Cet attribut est prévu pour fournir des informations sur le titulaire d'AC, qui peut être utilisé par l'AC verifier ( ou un grand système dans lequel l'AC verifier est un composant ) pour autoriser les actions du titulaire dans le système de l'AC verifier. Noter que c'est une utilisation différente que l'attribut svceAuthInfo.
name id-aca-accessIdentity
OID { id-aca 2 }
syntax SvceAuthInfo
values Multiple allowed

Charging Identity

L'attribute chargingIdentity identifie le titulaire de l'AC dans un but de charge. En général, l'identité de charge sera différent des autres identités du titulaire. Par exemple, la compagnie du titulaire peut être chargé pour un service.
name id-aca-chargingIdentity
OID { id-aca 3 }
syntax IetfAttrSyntax
values One Attribute value only; multiple values within the IetfAttrSyntax

Group

L'attribut group gère les informations d'appartenance du titulaire à des groupes.
name id-aca-group
OID { id-aca 4 }
syntax IetfAttrSyntax
values One Attribute value only; multiple values within the IetfAttrSyntax

Role

L'attribut role, spécifié dans X.509-2000, gère les informations sur l'allocation de rôle du titulaire de l'AC. La syntaxe utilisée pour cet attribut est:
RoleSyntax ::= SEQUENCE {
    roleAuthority [0] GeneralNames OPTIONAL,
    roleName [1] GeneralName
}

   Le champ roleAuthority peut être utilisé pour spécifier l'autorité de délivrance de certificat de spécification de rôle. Il n'y a pas de pré-requis pour qu'un certificat de spécification de rôle existe nécessairement pour le roleAuthority. Cela diffère de X.500-2000, où le champ roleAuthority est assumé au nom du fournisseur du certificat de spécification de rôle. Par exemple, pour distinguer le rôle administrateur comme définis par Baltimore de ce qui est définis par SPYRUS, on pourrait placer la valeur "urn:administrator" dans le champ roleName et la valeur "Baltimore" ou "SPYRUS" dans le champ roleAuthority.

Le champ roleName doit être présent, et roleName doit utiliser le choix uniformResourceIdentifier de GeneralName:
name id-at-role
OID { id-at 72 }
syntax RoleSyntax
values Multiple allowed

Clearance

   L'attribut clearance, spécifié dans X.501-1993, gère les informations de clairance ( associé avec les labels de sécurité ).

   Le champ policyId est utilisé pour identifier la stratégie de sécurité pour lequel la clairance est liée. policyId indique les sémantiques des champs classList et securityCategories.

   Cette spécification inclus le champ classList exactement comme spécifié dans X.501-1993. Des valeurs additionnelles de classification de sécurité, et leur position dans la hiérarchie de classification, peuvent être définis par une stratégie de sécurité au niveau local ou par accord bilatéral. La hiérarchie de classification de sécurité de base est, dans l'ordre ascendant: unmarked, unclassified, restricted, confidential, secret, et top-secret.

   Une organisation peut développer ses propres stratégies de sécurité qui définissent les valeurs de classification de sécurité et leur signification. Cependant, les positions 0 à 5 de la chaîne de bits sont réservés pour la hiérarchie de classification de sécurité de base.

   Si présent, le champ securityCategory fournis d'autres information d'autorisation. La stratégie de sécurité identifié par le champ policyId indique les syntaxes qui sont permises dans le jeu securityCategories. Un identifiant d'objet identifie chaque syntaxe permise. Quand une de ces syntaxe est présente dans le jeu securityCategories, l'identifiant d'objet associé avec cette syntaxe est réalisé dans le champ securityCategory.type.

L'identifiant d'objet pour l'attribut clearance de la rfc3281 est:
id-at-clearance OBJECT IDENTIFIER ::= {
    joint-iso-ccitt(2) ds(5) module(1) selected-attribute-types(5)
    clearance (55) }

La syntaxe a été corrigée depuis la rfc3281, pour restaurer la conformité avec X.509-1997:
Clearance ::= SEQUENCE {
    policyId OBJECT IDENTIFIER,
    classList ClassList DEFAULT {unclassified},
    securityCategories SET OF SecurityCategory OPTIONAL
}

L'identifiant d'objet pour l'attribut clearance de X.509-1997 est:
id-at-clearance OBJECT IDENTIFIER ::= {
    joint-iso-ccitt(2) ds(5) attributeType(4) clearance (55) }

La syntaxe associée est la suivante:
Clearance ::= SEQUENCE {
    policyId OBJECT IDENTIFIER,
    classList ClassList DEFAULT {unclassified},
    securityCategories SET OF SecurityCategory OPTIONAL
}

Les implémentations doivent supporter l'attribut clearance comme définis dans X.501-1997. Les implémentations devraient supporter le décodage de la syntaxe clearance de la rfc3281. Les implémentations ne doivent pas générer d'attribut clearance comme définis dans la rfc3281.
ClassList ::= BIT STRING {
    unmarked (0),
    unclassified (1),
    restricted (2),
    confidential (3),
    secret (4),
    topSecret (5)
}

SecurityCategory ::= SEQUENCE {
    type [0] OBJECT IDENTIFIER,
    value [1] EXPLICIT ANY DEFINED BY type
}
name { id-at-clearance }
OID { joint-iso-ccitt(2) ds(5) attribute-type (4) clearance (55) }
syntax Clearance -- imported from [X.501-1997]
values Multiple allowed

Profile du PKC du AC Issuer

Le PKC du fournisseur doit être conforme à la rfc5280, et l'extension keyUsage dans le PKC ne doit pas explicitement indiquer que la clé publique du fournisseur d'AC ne peut pas être utilisée pour valider une signature numérique. Pour éviter toute confusion dans les numéros de série et les révocations, un fournisseur d'AC ne doit pas être en même temps un PKC Issuer. Donc le PKC du fournisseur d'AC ne doit pas avoir une extension basicConstraints avec cA à TRUE.

Validation de certificat d'attribut

   Cette section décrit un jeu de règles de base que tout AC valide doit satisfaire. Certaines vérifications additionnelles sont également décrites, que l'AC verifier peut choisir d'implémenter. Pour être valide, un AC doit satisfaire tous les points suivant:

1. Là où le titulaire utilise un PKC pour s'authentifier auprès de l'AC verifier, le PKC du titulaire de l'AC doit être trouvé, et tout le chemin de certification de ce PKC doit être vérifié en accord avec la rfc5280. Comme mentionné dans la section Considération de Sécurité, si un autre schémas de sécurité est utilisé, les AC verifier doivent être très attentifs au mappage des identités.
2. La signature de l'AC doit être cryptographiquement correcte, et tout le chemin de certification du PKC du fournisseur d'AC doit être vérifié en accord avec la rfc5280.
3. Le PKC du fournisseur d'AC doit également être conforme au profile spécifié dans la section précédente.
4. Le fournisseur d'AC doit être directement considéré comme un fournisseur d'AC.
5. Le temps pour lequel l'AC est évalué doit être dans la validité de l'AC. Si l'évaluation est égal à soit notBeforeTime soit notAfterTime, la vérification réussit. Noter que dans certaines applications, l'évaluation du temps peut ne pas être la même que l'heure courante.
6. La vérification de l'AC targeting doit passe comme spécifié dans la section AC Targeting.
7. Si l'AC contient une extension critique non-supportée, l'AC doit être rejetée.

   Le support pour une extension dans ce contexte signifie:

1. L'AC verifier doit être capable de lire la valeur de l'extension
2. Là où la valeur de l'extension implique de rejeter l'AC, l'AC verifier doit rejeter l'AC.

   Vérifications additionnelles:

1. L'AC peut être rejetée sur la base d'une configuration de l'AC verifier. Par exemple, un AC verifier peut être configuré pour rejeter les AC qui contiennent ou qui n'ont pas certains attributs.
2. Si l'AC verifier fournis une interface qui permet aux applications de requêter le contenu de l'AC, alors l'AC verifier peut filtrer les atributs de l'AC en fonction de sa configuration. Par exemple, un AC verifier pourrait être configuré pour ne pas retourner certains attributs pour certains serveurs.

Révocation

   Dans de nombreux environnements, la période de validité d'un AC est inférieure au temps requis pour fournir et distribuer les informations de révocation. Les AC à durée de vie courte ne nécessitent pas de support de révocation. Cependant, les AC à durée de vie longue et les environnements où les AC permettent les transaction à forte valeur, le support de la révocation peut être requise.

   2 schémas de révocation sont définis, et le fournisseur d'AC devrait élire celui qui est le plus adapté à l'environnement dans lequel l'AC sera employé.

Schéma "Never revoke": Les AC peuvent être marqués pour que les parties comprennent qu'aucune information de statut de révocation ne sera rendu disponible. L'extension NoRevAvail doit être présent dans l'AC pour indiquer l'utilisation de ce schéma. Si cette extension n'est pas présente, le fournisseur d'AC statut qu'une vérification du statut de révocation est suppportée, et certaines méthodes de révocation doivent être fournis pour permettre aux AC verifiers d'établir le statut de révocation de l'AC.
Schéma "Pointer in AC": Les AC peuvent "pointer" sur la source d'information de statut de révocation, en utilisant soit l'extension authorityInfoAccess ou l'extension crlDistributionPoints dans l'AC.

   Pour les utilisateurs d'AC, le schéma "never revoke" doit être supporté, et le "pointer in AC" devrait être supporté. Si seul le premier est supporté, tous les AC qui ne contiennent pas l'extension noRevAvail doivent être rejetés.

   Un AC ne doit pas contenir à la fois l'extension noRevAvail et un "pointer in AC".

  Un AC verifier peut utiliser toute information de statut de révocation de l'AC.

Fonctionnalités optionnelles

Cette section spécifie les fonctionnalités qui peuvent être implémentées. La conformité avec ce profile n'impose pas de supporter ces fonctionnalités; cependant, si ces fonctionnalités sont supportées, elles doivent le faire tel que décris ici.

Chiffrement d'attribut

   Les attributs d'AC peuvent nécessiter d'être chiffrés si l'AC est transporté dans le protocole d'application en clair ou contient des informations sensibles ( par ex: username/password ).

   Quand un jeu d'attributs doit être chiffré dans un AC, le CMS EnvelopedData est utilisé pour transporter le texte chiffré et les informations par destinataire associés.

   Ce type de chiffrement d'attribut est ciblé. Avant que l'AC soit signé, les attributs sont chiffrés pour un jeu de destinataires prédéterminés.

Dans l'EnvelopedData, encapsulatedContentInfo identifie le type de contenu transporté dans le texte chiffré. Dans ce cas, le champ contentType de encapsulatedContentInfo doit contenir id-ct-attrCertEncAttrs, qui a la valeur suivante:
attrCertEncAttrs OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) id-smime(16) id-ct(1) 14 }

   Le texte chiffré est inclus dans l'AC comme valeur d'un attribut encAttrs. Seul un attribut encAttrs peut être présent dans un AC; cependant, l'attribut encAttrs peut être multi-valué, et chacune de ses valeurs contient un EnvelopedData indépendant.

   Chaque valeur peut contenir un jeu d'attributs ( chaque pouvant être multi-valué ) chiffré pour un jeu de déstinataires prédéterminés.

Le texte en clair qui est chiffré a le type:
ACClearAttrs ::= SEQUENCE {
    acIssuer GeneralName,
    acSerial INTEGER,
    attrs SEQUENCE OF Attribute
}

   L'encodé DER de la structure ACClearAttrs est utilisée comme champ encryptedContent de EnvelopedData. L'encodé DER doit être embarqué dans une chaîne d'octets.

   Les champs acIssuer et acSerial sont présents pour empêcher le vol du texte chiffré. Quand un AC verifier a déchiffré un attribut chiffré avec succès, il doit ensuite vérifier que les champs acIssuer et acSerial contiennent les même valeur. Cela empêche un fournisseur d'AC malicieux de copier le texte chiffré d'un autre AC.

   La procédure pour un fournisseur d'accès pour chiffrer des attributs est illustré par les étapes suivantes ( tout autre procédure qui donne le même résultat peut être utilisé ):

1. Identifier les jeux d'attributs qui doivent être chiffrés pour chaque jeu de destinataires.
2. Pour chaque jeu d'attribut qui doit être chiffré:

2.1. Créer une structure EnvelopedData pour les données pour ce jeu de destinataires
2.2. Encoder ContentInfo contenant le EnvelopedData comme valeur de l'attribut encAttrs
2.3. S'Assurer que les attributs en texte clair ne sont pas présents dans l'AC à signer

3. Ajouter encAtrs ( avec ses multiples valeurs ) à l'AC.

   Noter qu'il peut y avoir plus d'un attribut de même type ( le même identifiant d'objet ) après de déchiffrement. C'est à dire, un AC peut contenir le même type d'attribut à la fois en clair et chiffré ( et de nombreuses fois si différents destinataires sont associés avec plus d'un EnvelopedData ). Par exemple, un AC pourrait contenir un attribut clearance en texte claire indiquant que le titulaire est autorisé à SECRET, et , en plus, un attribut clearance chiffré dont la valeur est une clairance supérieure qui ne doit pas être connus par tout le monde. Une approche peut choisir de fusionner les valeurs d'attributs après déchiffrement pour rétablir la contrainte "once only".

name id-aca-encAttrs
OID { id-aca 6}
syntax ContentInfo
values Multiple Allowed

   Si un AC contient des attributs apparemment chiffrés pour l'AC verifier, un échec du processus de déchiffrement doit impliquer le rejet de l'AC.

Proxying

   Quand un serveur agit comme un client pour un autre serveur de la part du titulaire, le serveur peut nécessiter proxyfier un AC. Un tel proxy peut être fait sous le contrôle du fournisseur d'AC, pour que tous les AC ne soient pas proxyfiables et qu'un AC proxyfié puisse l'être de façon ciblée. Le support pour les chaînes de proxy ( avec plus d'un serveur intermédiaire ) peut également être requis. Noter que cela n'implique pas une chaîne d'AC.

   Pour ce pré-requis, on définis une autre extension, ProxyInfo, similaire à l'extension targeting.

   Quand cette extension est présente, l'AC verifier doit vérifier que l'entité depuis lequel l'AC a été reçus était autorisé à l'envoyer et que l'AC est autorisé à être utilisé par l'AC verifier.

   Les informations de proxying est une liste dans laquelle chaque élément est une liste d'informations de ciblage. Si le verifieur et l'émetteur de l'AC sont nommés dans la même liste de proxy, l'AC peut alors être accepté ( la règle exacte est donnée plus bas ).

   L'effet est que le titulaire de l'AC peut envoyer l'AC à une cible valide qui peut ainsi seulement proxyfier aux cibles qui sont dans une des même listes que lui.

La structure de donnée suivante est utilisée pour représenter les information de targeting/proxying:
ProxyInfo ::= SEQUENCE OF Targets

   Les Targets sont expliqués dans la section AC Targeting. Comme dans le cas du targeting, le choix targetCert ne doit pas être utilisé.

   Une vérification de proxy réussie si une des conditions suivantes est rencontrée:

1. L'identité de l'émetteur, comme établit par le service d'authentification sous-jacent, correspond au champ Holder de l'AC, et le serveur courant correspond à un nom dans les jeux proxy.
2. L'identité de l'émetteur, comme établit par le service d'authentification sous-jacent, correspond à un des jeux proxy ( appelons le jeu A ), et le serveur courant est un des champs targetName dans le jeu A, ou le serveur courant est un membre d'un des champs targetGroup dans le jeu A.

   Quand un AC est proxyfié plus d'une fois, un nombre de cibles seront sur le chemin du client original, qui est normalement, mais pas toujours, le titulaire de l'AC. Dans de tels cas, la prévention du vol d'AC nécessite que l'AC verifier vérifie toujours que toutes les cibles dans le chemin sont dans le jeu proxy. Il est de la responsabilité du protocole utilisant d'AC de s'assurer qu'une liste de cibles de confiance dans le chemin soit disponible à l'AC verifier.

name id-pe-ac-proxying
OID { id-pe 10 }
syntax ProxyInfo
criticality MUST be TRU

Utilisation de ObjectDigestInfo

   Dans certains environnements, il peut être requis que l'AC ne soit pas lié soit à une identité ( via entityName ) ou à un PKC ( via baseCertificateID ). Le choix objectDigestInfo dans le champ Holder permet de le gérer.

   Si le titulaire est identifié avec le champ objectDigestInfo, alors le champ version de l'AC doit contenir v2 ( l'entier 1 ).

   L'idée est de lier l'AC à un objet en plaçant un hash de cet objet dans le champ Holder de l'AC. Par exemple, cela permet la production d'AC qui sont liés aux clés publiques au lieu de leur noms. Cela permet également la production d'AC qui contiennent des privilèges associés avec un objet exécutable telle qu'une classe java au travers d'une clé publique ou un PKC. Les AC conformes ne doivent pas utiliser de valeur otherObjectTypes pour le digestedObjectType.

   Pour lier un AC à une clé publique, le hash doit être calculé sur la présentation de cette clé publique, qui pourrait être présente dans un PKC, spécifiquement, l'entrée pour l'algorithme de hash doit être l'encodé DER d'une représentation SubjectPublicKeyInfo de la clé.

   Note: cela inclus l'AlgorithmIdentifier aussi bien que la chaîne de bit. Les règles donnée dans les algorithmes PKIX ( rfc3279, rfc4055, rfc5480, et rfc5756 ) pour encoder les clés doivent être suivies. Dans ce cas, le digestedObjectType doit être publicKey et le champ otherObjectTypeID ne doit pas être présent.

   Noter que si la valeur de la clé publique utilisé en entrée de la fonction de hashage a été extraite d'un PKC, il est possible que le SubjectPublicKeyInfo de ce PKC ne soit pas la valeur qui devrait être hashé. Cela peut se produire si les Dss-parms de DSA sont hérités comme décris dans la section 2.3.2 de la rfc3279. L'entrée correcte pour le hashage dans ce contexte inclus la valeur des paramètres hérités du PKC de la CA, et donc peut différer du SubjectPublicKeyInfo présent dans le PKC.

   Les implémentations qui supportent cette fonctionnalité doivent être capable de gérer les représentations de clé publique pour les algorithmes spécifiés dans la section 2.3 de la rfc3279.

   Pour lier un AC à un PKC via un hash, le hash doit être calculé sur l'encodé DER de tout le PKC, incluant la valeur de signature. Dans ce cas, digestedObjectType doit être publicKeyCert et otherObjectTypeID ne doit pas être présent.

Contrôles AA

Durant la validation d'AC, un partie de confiance doit répondre à la question: est-ce que ce fournisseur d'AC est valide pour fournir des ACs avec cet attribut? L'extension AAControls est prévu pour être utilisé dans les CA et les fournisseurs d'AC
id-pe-aaControls OBJECT IDENTIFIER ::= { id-pe 6 }

AAControls ::= SEQUENCE {
    pathLenConstraint INTEGER (0..MAX) OPTIONAL,
    permittedAttrs [0] AttrSpec OPTIONAL,
    excludedAttrs [1] AttrSpec OPTIONAL,
    permitUnSpecified BOOLEAN DEFAULT TRUE
}

AttrSpec::= SEQUENCE OF OBJECT IDENTIFIER

   L'extension AAControls est utilisé comme suit:

PathLenConstraint si présent,, est interprété comme dans la rfc5280. Il restreint la distance permise entre le AA CA ( une CA directement validé pour inclure les AAControls dans ses PKCs), et le fournisseur d'AC.
permittedAttrs spécifie une liste de types d'attributs que tout fournisseur d'AC sous ce AA CA est autorisé à inclure dans les AC. Si ce champ n'est pas présent, cela signifie qu'aucun type d'attribut n'est explicitement permis.
excludedAttrs spécifie une liste de types d'attributs qu'aucun fournisseur d'AC sous ce AA CA n'est autorisé à inclure dans les AC. Si ce champ n'est pas présent, cela signifie qu'aucun type d'attribut n'est explicitement interdis.
permitUnSpecified spécifie comment manipuler les types d'attributs qui ne sont pas présents dans les champs permittedAttrs ou excludedAttrs. TRUE ( par défaut ) signifie qu'un type d'attribut non-spécifié est autorisé dans les AC, et FALSE, qu'il ne l'est pas.
- Quand AAControls est utilisé, les vérifications additionnelles suivantes sur la chaîne de PKC d'AA doit tous réussir pour que l'AC soit valide:

1. Certaines CA dans le chemin de certification de l'AC doivent être directement trustés pour fournir des PKCs qui précède le fournisseur d'AC dans le chemin de certification; appelons cette CA le "AA CA".
2. Tous les PKC dans le chemin depuis le AA CA, incluant le PKC du fournisseur d'AC, doivent contenir l'extension AAControls; cependant, le PKC du AA CA n'a pas besoin de contenir cette extension.
3. Seul les attributs dans l'AC qui sont permis, en accord avec toutes les valeurs d'extension AAControls dans tous les PKC depuis le AA CA jusqu'au fournisseur d'AC, peuvent être utilisé pour les décisions d'autorisation; tous les autres attributs doivent être ignorés. Cette vérification doit être appliquée à la liste des attributs suivant le déchiffrement d'attributs, et le type id-aca-encAtrs doit être également vérifié.

name id-pe-aaControls
OID { id-pe 6 }
syntax AAControls
criticality MAY be TRUE

Considérations de sécurité

   La protection offerte pour les clés privées est un facteur critique pour maintenir la sécurité. Si les fournisseurs d'AC ne parviennent pas à protéger leur clé privée, un attaquant pour les utiliser, potentiellement pour générer de faux AC ou statut de révocation. Si le système est compromis, tous les AC fournis par le fournisseur d'AC doivent être révoqués. La reconstruction sera problématique, donc les fournisseurs d'AC doivent implémenter une combinaison de techniques fortes ( ex: modules cryptographique inviolable ) et de procédures de gestion appropriés ( ex: séparation des fonctions ) pour éviter un tel incident.

   La perte d'une clé privée d'un fournisseur d'AC peut également être problématique. Le fournisseur d'AC ne sera plus capable de produire de status de révocation ou de renouvellement d'AC. Les fournisseur d'AC doivent maintenir une sauvegarde sécurisée de leur clé de signatue. La sécurité des procédures de sauvegarde de clé est un facteur critique.

   La disponibilité et la "fraîcheur" du status de révocation va affecter le degré d'assurance qui serai placé dans un AC long terme. Bien que les AC long-terme expirent naturellement, des évènements peuvent se produire durant sa durée de vie. Si le status de révocation est non-timé ou non-disponible, l'assurance associée avec le lien entre le titulaire de l'AC et les attributs est clairement réduit.

   La liaison entrée un titulaire d'AC et les attributs ne peut pas être plus forte que l'implémentation cryptographique et les algorithmes utilisé pour générer la signature. Des clé courtes ou des algorithmes faibles limitent l'utilité d'un AC.

   Les applications qui sont inconsistant lors de la comparaison des noms peut engendrer l'acceptation de cibles ou proxy invalides, ou le rejet de certains valides. Les séries X.500 de spécifications définissent des règles pour comparer les noms distincts. Ces règles nécessitent la comparaison de chaînes sans regarder la casse, le jeu de caractères, les espace blancs multi-caractères, ou les espaces blanc de début et de fin. Cette spécification relaxe ces pré-requis, nécessitant une comparaison binaire au minimum.

   Les fournisseurs d'AC doivent encoder le nom distinct dans le champ holder.entityName de l'AC identiquement au nom distinct dans le PKC du titulaire. Si des encodages différents sont utilisé, les implémentations de cette spécifiaciton peuvent échouer dans la reconnaissance de l'AC et du PKC appartenant à la même entité.

   Si un certificat d'attribut est lié au PKC du titulaire un utilisant le composant baseCertificateID du champ Holder et la PKI utilisée inclue un faux CA avec le même nom de fournisseur spécifié dans le composant baseCertificateID, ce faux CA pourrait fournir un PKC à un paire malicieux, en utilisant le même nom de fournisseur et numéro de série que le PKC du titulaire. Ainsi, le paire malicieux pourrait utiliser ce PKC en conjonction avec l'AC. Ce scénario devrait être évité en gérant et en configurant proprement la PKI pour qu'il ne puisse pas y avoir 2 CA avec le même nom.

   Une autre alternative est de lier les AC aux PKC en utilisant le type publicKeyCert dans le champ ObjectDigestInfo. Les AC verifier doivent établir ( en utilisant d'autres moyens ) que les collisions potentiels ne peuvent pas se produire, par exemple, le Certificate Practice Statements (CPSs) des CA impliqués peuvent préciser qu'une collision de nom ne puisse se produire.

   Les implémenteurs doivent s'assurer qu'en suivant la validation d'un AC, seuls les attributs dont le fournisseur est autorisé à fournir sont utilisés dans les décisions d'autorisation. Les autres attributs, qui peuvent être présents doivent être ignorés. L'extension PKC AAControls est optionnel, et les informations de configuration peuvent être une alternative. Cela devient très important si un AC verifier trust plus d'un fournisseur d'AC.

   Il est souvent requis de mapper l'authentification fournie par un protocole de sécurité particulier ( ex: TLS, S/MIME ) et l'identité du titulaire de l'AC. Si l'authentification utilise les PKC, alors le mapping est simple. Cependant, il est envisagé que les AC sont également utilisés dans des environnement où le titulaire peut être authentifié en utilisant d'autres moyens. Les implémenteurs devraient prendre en charge le mapping d'identité d'authentification qui ne proviennent pas de certificats à clé publique.

Appendix A - Object Identifiers

   Cet appendix liste les nouveaux identifiant d'objet qui sont définis dans cette spécification. Certains sont requis uniquement pour le support de fonctionnalités optionnels et ne sont pas obligatoire pour se conformer à ce profile.

Les OID suivant sont importés depuis les rfc de profile PKIX:
id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) }
id-mod OBJECT IDENTIFIER ::= { id-pkix 0 }
id-pe OBJECT IDENTIFIER ::= { id-pkix 1 }
id-ad OBJECT IDENTIFIER ::= { id-pkix 48 }
id-at OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) ds(5) 4 }
id-ce OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) ds(5) 29 }

Le nouvel OID de mode ASN.1 suivant est définis:
id-mod-attribute-cert OBJECT IDENTIFIER ::= { id-mod 12 }

Les OID d'extension d'AC suivant sont définis:
id-pe-ac-auditIdentity OBJECT IDENTIFIER ::= { id-pe 4 }
id-pe-ac-proxying OBJECT IDENTIFIER ::= { id-pe 10 }
id-ce-targetInformation OBJECT IDENTIFIER ::= { id-ce 55 }

Les OID d'extension PKC suivants sont définis:
id-pe-aaControls OBJECT IDENTIFIER ::= { id-pe 6 }

Les OID d'attributs suivant sont définis:
id-aca OBJECT IDENTIFIER ::= { id-pkix 10 }
id-aca-authenticationInfo OBJECT IDENTIFIER ::= { id-aca 1 }
id-aca-accessIdentity OBJECT IDENTIFIER ::= { id-aca 2 }
id-aca-chargingIdentity OBJECT IDENTIFIER ::= { id-aca 3 }
id-aca-group OBJECT IDENTIFIER ::= { id-aca 4 }
id-aca-encAttrs OBJECT IDENTIFIER ::= { id-aca 6 }
id-at-role OBJECT IDENTIFIER ::= { id-at 72 }
id-at-clearance OBJECT IDENTIFIER ::= {
    joint-iso-ccitt(2) ds(5) attributeType(4) clearance (55) }
id-at-clearance OBJECT IDENTIFIER ::= {
    joint-iso-ccitt(2) ds(5) module(1) selected-attribute-types(5) clearance (55) }

Appendix B - Module ASN.1

Cet appendix décrit les objects utilisé par les composant de PKI conformes dans une syntaxe ASN.1-like, un hybrid des syntaxe 1988 et 1993 d'ASN.1.
PKIXAttributeCertificate-2008 { iso(1) identified-organization(3)
    dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
    id-mod-attribute-cert-v2(61) }

DEFINITIONS IMPLICIT TAGS ::=

BEGIN

-- EXPORTS ALL --

IMPORTS

-- Les OID des modules IMPORTés peuvent changer si les rfc de profile PKIX changent les extensions de certificat PKIX.

Attribute, AlgorithmIdentifier, CertificateSerialNumber,
Extensions, UniqueIdentifier, id-pkix, id-pe, id-kp, id-ad, id-at
    FROM PKIX1Explicit88
        { iso(1) identified-organization(3) dod(6) internet(1)
            security(5) mechanisms(5) pkix(7) id-mod(0)
            id-pkix1-explicit-88(18) }

GeneralName, GeneralNames, id-ce, AuthorityKeyIdentifier,
    AuthorityInfoAccessSyntax, CRLDistributionPoint
        FROM PKIX1Implicit88
        { iso(1) identified-organization(3) dod(6) internet(1)
            security(5) mechanisms(5) pkix(7) id-mod(0)
            id-pkix1-implicit-88(19) }

ContentInfo
    FROM CryptographicMessageSyntax2004
        { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
            smime(16) modules(0) cms-2004(24) }

;

id-pe-ac-auditIdentity OBJECT IDENTIFIER ::= { id-pe 4 }

id-pe-aaControls OBJECT IDENTIFIER ::= { id-pe 6 }

id-pe-ac-proxying OBJECT IDENTIFIER ::= { id-pe 10 }

id-ce-targetInformation OBJECT IDENTIFIER ::= { id-ce 55 }

id-aca OBJECT IDENTIFIER ::= { id-pkix 10 }

id-aca-authenticationInfo OBJECT IDENTIFIER ::= { id-aca 1 }

id-aca-accessIdentity OBJECT IDENTIFIER ::= { id-aca 2 }

id-aca-chargingIdentity OBJECT IDENTIFIER ::= { id-aca 3 }

id-aca-group OBJECT IDENTIFIER ::= { id-aca 4 }

-- { id-aca 5 } is reserved

id-aca-encAttrs OBJECT IDENTIFIER ::= { id-aca 6 }

id-at-role OBJECT IDENTIFIER ::= { id-at 72}

id-at-clearance OBJECT IDENTIFIER ::= {
    joint-iso-ccitt(2) ds(5) attributeType(4) clearance (55) }

-- Décommenter la déclaration suivante et commenter la ligne au dessus pour utiliser
-- l'attribut id-at-clearance comme définis dans la rfc3281.

-- id-at-clearance OBJECT IDENTIFIER ::= {
-- joint-iso-ccitt(2) ds(5) module(1) selected-attribute-types(5)
-- clearance (55) }

-- Uncomment this if using a 1988 level ASN.1 compiler

-- UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING

AttributeCertificate ::= SEQUENCE {
    acinfo AttributeCertificateInfo,
    signatureAlgorithm AlgorithmIdentifier,
    signatureValue BIT STRING
}

AttributeCertificateInfo ::= SEQUENCE {
    version AttCertVersion, -- version is v2
    holder Holder,
    issuer AttCertIssuer,
    signature AlgorithmIdentifier,
    serialNumber CertificateSerialNumber,
    attrCertValidityPeriod AttCertValidityPeriod,
    attributes SEQUENCE OF Attribute,
    issuerUniqueID UniqueIdentifier OPTIONAL,
    extensions Extensions OPTIONAL
}

AttCertVersion ::= INTEGER { v2(1) }

Holder ::= SEQUENCE {
    baseCertificateID [0] IssuerSerial OPTIONAL,
        -- the issuer and serial number of
        -- the holder's Public Key Certificate
    entityName [1] GeneralNames OPTIONAL,
        -- the name of the claimant or role
    objectDigestInfo [2] ObjectDigestInfo OPTIONAL
        -- used to directly authenticate the
        -- holder, for example, an executable
}

ObjectDigestInfo ::= SEQUENCE {
    digestedObjectType ENUMERATED {
        publicKey (0),
        publicKeyCert (1),
        otherObjectTypes (2) },
    -- otherObjectTypes MUST NOT
    -- MUST NOT be used in this profile
    otherObjectTypeID OBJECT IDENTIFIER OPTIONAL,
    digestAlgorithm AlgorithmIdentifier,
    objectDigest BIT STRING
}

AttCertIssuer ::= CHOICE {
    v1Form GeneralNames, -- MUST NOT be used in this profile
    v2Form [0] V2Form -- v2 only
}

V2Form ::= SEQUENCE {
    issuerName GeneralNames OPTIONAL,
    baseCertificateID [0] IssuerSerial OPTIONAL,
    objectDigestInfo [1] ObjectDigestInfo OPTIONAL
        -- issuerName MUST be present in this profile
        -- baseCertificateID and objectDigestInfo MUST
        -- NOT be present in this profile
}

IssuerSerial ::= SEQUENCE {
    issuer GeneralNames,
    serial CertificateSerialNumber,
    issuerUID UniqueIdentifier OPTIONAL
}

AttCertValidityPeriod ::= SEQUENCE {
    notBeforeTime GeneralizedTime,
    notAfterTime GeneralizedTime
}

Targets ::= SEQUENCE OF Target

Target ::= CHOICE {
    targetName [0] GeneralName,
    targetGroup [1] GeneralName,
    targetCert [2] TargetCert
}

TargetCert ::= SEQUENCE {
    targetCertificate IssuerSerial,
    targetName GeneralName OPTIONAL,
    certDigestInfo ObjectDigestInfo OPTIONAL
}

IetfAttrSyntax ::= SEQUENCE {
    policyAuthority [0] GeneralNames OPTIONAL,
    values SEQUENCE OF CHOICE {
        octets OCTET STRING,
        oid OBJECT IDENTIFIER,
        string UTF8String
    }
}

SvceAuthInfo ::= SEQUENCE {
    service GeneralName,
    ident GeneralName,
    authInfo OCTET STRING OPTIONAL
}

RoleSyntax ::= SEQUENCE {
    roleAuthority [0] GeneralNames OPTIONAL,
    roleName [1] GeneralName
}

Clearance ::= SEQUENCE {
    policyId OBJECT IDENTIFIER,
    classList ClassList DEFAULT {unclassified},
    securityCategories SET OF SecurityCategory OPTIONAL
}

-- Uncomment the following lines to support deprecated clearance
-- syntax and comment out previous Clearance.

-- Clearance ::= SEQUENCE {
-- policyId [0] OBJECT IDENTIFIER,
-- classList [1] ClassList DEFAULT {unclassified},
-- securityCategories [2] SET OF SecurityCategory OPTIONAL
-- }

ClassList ::= BIT STRING {
    unmarked (0),
    unclassified (1),
    restricted (2),
    confidential (3),
    secret (4),
    topSecret (5)
}

SecurityCategory ::= SEQUENCE {
    type [0] OBJECT IDENTIFIER,
    value [1] EXPLICIT ANY DEFINED BY type
}

-- Note that in [RFC3281] the syntax for SecurityCategory was
-- as follows:
--
-- SecurityCategory ::= SEQUENCE {
-- type [0] IMPLICIT OBJECT IDENTIFIER,
-- value [1] ANY DEFINED BY type
-- }
--
-- The removal of the IMPLICIT from the type line and the
-- addition of the EXPLICIT to the value line result in
-- no changes to the encoding.

AAControls ::= SEQUENCE {
    pathLenConstraint INTEGER (0..MAX) OPTIONAL,
    permittedAttrs [0] AttrSpec OPTIONAL,
    excludedAttrs [1] AttrSpec OPTIONAL,
    permitUnSpecified BOOLEAN DEFAULT TRUE
}

AttrSpec ::= SEQUENCE OF OBJECT IDENTIFIER

ACClearAttrs ::= SEQUENCE {
    acIssuer GeneralName,
    acSerial INTEGER,
    attrs SEQUENCE OF Attribute
}

ProxyInfo ::= SEQUENCE OF Targets

END

05 août 2015

rfc5914

Format d'ancre de confiance

Ce document décris une structure pour représenter les informations d'ancre de confiance. Une ancre de confiance est une entité autoritative représentée par une clé publique et des données associées. La clé publique est utilisée pour vérifier les signatures numériques, et les données associées sont utilisée pour contraindre les types d'information ou actions pour lesquelles l'ancre de confiance a autorité. Les structures définies dans ce document sont prévus pour satisfaire les exigences liées au format définis dans les exigencse de gestion d'ancre de confiance.

Les ancres de confiance sons largement utilisées pour vérifier les signatures numériques et valider les chemins de certification. Ils sont requis pour valider les chemins de certification. Bien que largement utilisés, il n'y a pas de format standard pour représenter les informations d'ancre de confiance. ce document décris la structure TrustAnchorInfo. Cette structure est prévue pour satisfaire les exigences liées au format exprimées dans les exigences de gestion d'ancre de confiance ( rfc6024 ) et est exprimée en utilisant ASN.1. Il peut fournir une alternative plus compact aux certificats X.509 pour échanger les informations d'ancre de confiance et fournir un moyen d'associer des contraintes additionnelles ou alternatives avec les certificats sans casser la signature dans le certificat.

Syntaxe d'information d'ancre de confiance

Cette section décris la structure TrustAnchorInfo:
TrustAnchorInfo ::= SEQUENCE {
    version TrustAnchorInfoVersion DEFAULT v1,
    pubKey SubjectPublicKeyInfo,
    keyId KeyIdentifier,
    taTitle TrustAnchorTitle OPTIONAL,
    certPath CertPathControls OPTIONAL,
    exts [1] EXPLICIT Extensions OPTIONAL,
    taTitleLangTag [2] UTF8String OPTIONAL }

TrustAnchorInfoVersion ::= INTEGER { v1(1) }

Version

La version identifie la version de TrustAnchorInfo. De futures mises à jours de ce document peuvent inclure des changements dans cette structure, auquel cas le numéro de version devrait être incrémenté. Cependant, la valeur par défaut, v1, ne peut pas être changée.

Clé publique

pubKey identifie la clé publique et l'algorithme associé avec l'ancre de confiance en utilisant la structure SubjectPublicKeyInfo (rfc5280). La structure SubjectPublicKeyInfo contient l'identifiant d'algorithme suivi par la clé publique elle-même. Le champ algorithm est un AlgorithmIdentifier, qui contient un identifiant d'objet et des paramètres optionnels. L'identifiant d'objet nomme l'algorithme de clé publique et indique la syntaxe des paramètres, si présent, aussi bien que le format de la clé publique. La clé publique est encodée en chaîne de bits.

Titre de l'ancre de confiance

TrustAnchorTitle ::= UTF8String (SIZE (1..64))

taTitle est optionnel. Si présent, il fournis un nom compréhensible pour l'ancre de confiance. Le texte est encodé en UTF-8. Le champ taTitleLangTag identifie la langue utilisée pour exprimer le taTitle. Quand taTitleLangTag est absent, l'englais ("en") est utilisé. La valeur de taTitleLangTag devrait être un tag de langue comme décris dans la rfc5646.

Contrôles de chemin de certification

CertPathControls ::= SEQUENCE {
    taName Name,
    certificate [0] Certificate OPTIONAL,
    policySet [1] CertificatePolicies OPTIONAL,
    policyFlags [2] CertPolicyFlags OPTIONAL,
    nameConstr [3] NameConstraints OPTIONAL,
    pathLenConstraint[4] INTEGER (0..MAX) OPTIONAL}

   certPath est optionnel. Si présent, il fournis les contrôles nécessaires pour initialiser une implémentation d'algorithme de validation de certification X.509. Si absent, l'ancre de confiance ne peut pas être utilisée pour valider la signature dans un certificat X.509.

   taName fournis le nom distinct X.500 associé avec l'ancre de confiance, et ce nom distinct est utilisé pour construire et valider un chemin de certification X.509. Le nom ne doit pas être une séquence vide.

   certificate fournis un certificat X.509 optionnel, qui peut être utilisé dans certains environnements pour représenter l'ancre de confiance dans le développement et la validation du chemin de certification. Si le certificat est présent, le nom du sujet dans le certificat doit correspondre exactement le nom distinct X.500 fournis dans le champ taName, la clé publique doit correspondre exactement à la clé publique dans le champ pubKey, et l'extension subjectKeyIdentifier, si présent, doit correspondre exactement l'identifiant de clé dans le champ keyId. La description complète de la syntaxe et les sémantiques du certificat sont fournis dans la rfc5280. Les contraintes définies dans les champs policySet, policyFlags, nameConstr, pathLenConstraint, et exts dans TrustAnchorInfo remplacent les valeurs contenues dans un certificat ou fournissent des valeurs pour les extensions non présente dans le certificat. Les valeurs définies dans ces champs TrustAnchorInfo sont toujours forcés. Les extensions inclues dans un certificat sont forcés seulement s'il n'y a pas de valeur correspondante dans le TrustAnchorInfo. La correspondance entre les extensions dans le certificat et les champs TrustAnchorInfo sont définis comme suit:

- une extension de certificat id-ce-certificatePolicies correspond au champ CertPathControls.policySet
- une extension de certificat id-ce-policyConstraints correspond au champ CertPolicyFlags.inhibitPolicyMapping et CertPolicyFlags.requireExplicitPolicy
- Une extension de certificat id-ce-inhibitAnyPolicy correspond au champ CertPolicyFlags.inhibitAnyPolicy
- Une extension de certificat id-ce-nameConstraints correspond au champ CertPathControls.nameConstr
- Le champ pathLenConstraint d'une extension de certificat id-ce-basicConstraints correspond au champ CertPathControls.pathLenConstraint ( La présence d'une structure CertPathControls correspond à une valeur TRUE dans le champ cA de l'extension BasicConstraints )
- Toute autre extension de certificat correspond au même type d'extension dans le champ TrustAnchorInfo.exts

CertificatePolicies ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation

PolicyInformation ::= SEQUENCE {
    policyIdentifier CertPolicyId,
    policyQualifiers SEQUENCE SIZE (1..MAX) OF PolicyQualifierInfo OPTIONAL }

CertPolicyId ::= OBJECT IDENTIFIER

   policySet est optionnel. Si présent, il contient une séquence d'identifiant de stratégie de certificat fournis en entrée de l'algorithme de validation de chemin de certification. Si absent, la valeur spéciale any-policy est fournie comme entrée de l'algorithme de validation de chemin de certification. La description complète de la syntaxe et des sémantiques de CertificatePolicies sont fournis dans la rfc5280, incluant la syntaxe PolicyInformation. Dans ce contexte, la structure optionnelle policyQualifiers ne doit pas être inclue.

CertPolicyFlags ::= BIT STRING {
    inhibitPolicyMapping (0),
    requireExplicitPolicy (1),
    inhibitAnyPolicy (2) }

   policyFlags est optionnel. Si présent, 3 valeurs booléennes pour l'entrée dans l'algorithme de validation de chemin de certification sont fournis dans un BIT STRING. Si absent, l'entrée de l'algorithme de validation de chemin de certification est { FALSE, FALSE, FALSE }, qui représente le paramètre le plus libéral de ces flags. Ces 3 bits sont utilisés comme suit:

- inhibitPolicyMapping indique si le mappage de stratégie est autorisé dans le chemin de certification. Quand mis à TRUE, le mappage de stratégie n'est pas permis. Cette valeur représente la valeur d'entrée initial-policy-mapping-inhibit dans l'algorithme de validation de chemin de certification décris dans la rfc5280.
- requireExplicitPolicy indique si le chemin de certification doit être valide pour au moins une des stratégies de certificat dans le policySet. À TRUE, tous les certificats dans le chemin de certification doivent contenir un identifiant de stratégie acceptable dans l'extension de stratégie de certificat. Cette valeur représente la valeur d'entrée initial-explicit-policy dans l'algorithme de validation de chemin de certification décris dans la rfc5280. Un identifiant de stratégie acceptable est un membre du policySet ou l'identifiant d'une stratégie qui est déclarée équivalente via le mappage de stratégie. Ce bit doit être à FALSE si policySet est absent.
- inhibitAnyPolicy indique si l'identifiant de stratégie anyPolicy, avec la valeur { 2 5 29 32 0 }, est considéré un match explicite pour d'autres stratégies de certificat. Cette valeur représente la valeur d'entrée initial-any-policy-inhibit dans l'algorithme de validation de chemin de certification décris dans la rfc5280.

NameConstraints ::= SEQUENCE {
    permittedSubtrees [0] GeneralSubtrees OPTIONAL,
    excludedSubtrees [1] GeneralSubtrees OPTIONAL }

GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree

GeneralSubtree ::= SEQUENCE {
    base GeneralName,
    minimum [0] BaseDistance DEFAULT 0,
    maximum [1] BaseDistance OPTIONAL }

BaseDistance ::= INTEGER (0..MAX)

   nameConstr est optionnel. Il a la même syntaxe et sématiques que l'extension de certificat de contrainte de noms, qui inclue une liste de noms permis et une liste de noms exclus. La définition de GeneralName peut être trouvée dans la rfc5280. Quand il est présent, les contraintes sont fournies sur les noms (incluant les noms alternatifs) qui doivent apparaître dans le certificats X.509 sous-jacents dans un chemin de certification. Ce champ est utilisé pour définir les valeurs d'entrée initial-permitted-subtrees et d'initial-excluded-subtrees dans l'algorithme de validation de chemin de certification décris dans la rfc5280. Quand ce champ est absent, la variable initial-permitted-subtrees n'est pas limitée et la variable initial-excluded-subtrees est vide.

   Le champ pathLenConstraint donne le nombre maximum de certificats intermédiaire non-auto-émis qui peuvent suivre ce certificat dans un chemin de certification valide. ( Note: le dernier certificat dans le chemin de certification n'est pas un certificat intermédiaire et n'est pas inclus dans cette limite. Généralement, le dernier certificat est en certificat EE, mais il peut être un certificat CA). Un pathLenConstraint de 0 indique qu'aucun certificat d'autorité de certification intermédiaire non-auto-émis ne peut suivre dans le chemin de certification. Quand il apparaît, le champ pathLenConstraint doit être supérieur ou égal àl 0. Quand il n'apparaît pas, aucune limite n'est imposée.

   Quand l'ancre de confiance est utilisée pour valider un chemin de certification, CertPathControls fournis les limitations dans le chemins de certification qui seront validés avec succès. Une application qui valide un chemin de certification ne devrait pas ignorer ces limitations, mais l'application peut imposer des limitations additionnelles pour s'assurer que le chemin de certification validé est approprié pour le contexte applicatif prévu. Comme entrée de l'algorithme de validation de chemin de certification, une application peut:

- Fournir un sous-jeu de stratégies de certification fournies dans le policySet
- Fournir une valeur TRUE, si approprié, pour les flags dans le policyFlags
- Fournir un sous-jeu de noms permis fournis dans nameConstr
- Fournir des noms exclus additionnels à ceux fournis dans le nameConstr
- Fournir une valeur plus petite pour pathLenConstraint

Extensions

exts est optionnel. Si présent, il peut être utilisé pour associer des informations additionnelles avec l'ancre de confiance en utilisant la structure Extensions standard. Les extensions qui sont prévus pour être largement utilisé ont été inclus dans la structure CertPathControls pour éviter une surchage associée avec l'utilisation de la structure Extensions. Pour éviter la duplication avec le champ CertPathControls, les types d'extensions suivants ne doivent pas apparaître dans le champ exts et sont ignorés s'il n'apparaissent: id-ce-certificatePolicies, id-ce-policyConstraints, id-ce-inhibitAnyPolicy, et id-ce-nameConstraints.

Liste d'ancre de confiance

   TrustAnchorInfo permet la représentation d'une simple ancre de confiance. Dans de nombreux cas, il est préférable de représenter une collection d'ancre de confiance. La structure TrustAnchorList est définie dans ce but. TrustAnchorList est définis comme une séquence d'un ou plusieurs objects TrustAnchorChoice. TrustAnchorChoice fournis 3 options pour représenter une ancre de confiance. L'option certificat permet d'utiliser un certificat sans contraintes additionnelles. L'option tbsCert permet d'associer des contraintes en supprimant un signature dans un certificat et en changeant le champ extensions. L'option taInfo permet d'utiliser une structure TrustAnchorInfo définis dans ce document.

TrustAnchorList ::= SEQUENCE SIZE (1..MAX) OF TrustAnchorChoice

TrustAnchorChoice ::= CHOICE {
    certificate Certificate,
    tbsCert [1] EXPLICIT TBSCertificate,
    taInfo [2] EXPLICIT TrustAnchorInfo }

trust-anchor-list PKCS7-CONTENT-TYPE ::= { TrustAnchorList IDENTIFIED BY id-ct-trustAnchorList }

   La structure TrustAnchorList peut être protégée en utilisant la structure SignedData définis dans CMS. L'identifiant d'objet id-ct-trustAnchorList a été définis pour représenter le payloads TrustAnchorList avec les structure CMS.

Considérations de sécurité

   La compromission d'une clé privée d'ancre de confiance permet à des tiers non-autorisés d'usurper l'ancre de confiance, avec des conséquences potentiellement sévères. Quand des contraintes basés sur TA sont forcés, une personne non-autorisée ayant la clé privée sera limité par les contrôles de chemin de certification associés avec l'ancre de confiance, comme exprimé dans les champs certPath et exts. Par exemple, les contraintes de nom dans l'ancre de confiance vont déterminer l'espace de nom qui sera accepté dans le certificats qui sont validés en utilisant l'ancre de confiance compromise. Le recours à une clé publique d'un ancre de confiance inapproprié ou incorrect a des conséquences potentiellement sévères.

   La compromission d'une clé privée de CA a le même type de problème que la compromission de clé privée d'une ancre de confiance. Une entité non autorisée possédant la clé privée de la CA sera limité par les contrôles de chemin de certification associés avec l'ancre de confiance, comme exprimé dans le champ certPath ou comme extension.

   L'utilisation d'un certificat indépendant de la structure TrustAnchorinfo qui l'enveloppe doit être géré avec prudence pour éviter de violer les contraintes exprimées dans le TrustAnchorInfo. En enveloppant un certificat dans une structure TrustAnchorinfo, les valeurs inclues dans le certificat devraient être évalués pour s'assurer qu'il n'y a pas de confusion ou de conflit avec les valeurs dans la structure TrustAnchorinfo.

05 août 2015

rfc5937

Utilisation des contraintes d'ancre de confiance durant le traitement de chemin de certification

   Ce document décris comment utiliser les informations utilisée avec une clé publique d'ancre de confiance lors de la validation de chemin de certification. Cette information peut être utilisée pour contraindre l'utilisation d'une ancre de confiance. Typiquement, les contraintes sont utilisées pour limiter les stratégies de certificat et les noms qui peuvent apparaître dans les chemins de certification validés en utilisant une ancre de confiance.

   Les ancres de confiance sons largement utilisés pour vérifier les signatures numérique et la validation de chemin de certification (rfc5280). Il sont requis pour la validation de chemin de certification. La spécification du format de l'ancre de confiance (rfc5914) définis un moyen pour limiter le périmètre dans lequel une ancre de confiance peut être utilisée. La rfc5280 décris comment valider un chemin de certification. L'algorithme exige de traiter le nom et la clé depuis une ancre de confiance. L?utilisation d'autres informations, incluant le renforcement de contraintes, est permis mais non requis, et le traitement des règles ne sont pas spécifiés.

   Ce document définis un mécanisme pour identifier les contraintes qui devraient être forcés et les règles de traitement supplémentaires. Les règles supplémentaires spécifient une entrée additionnels et étendent les procédures d'initialisation dans l'algorithme de validation de chemin (rfc5280), les étapes de traitement post-initialisation ne sont pas affectés.

Identifier le contraintes d'ancre de confiance

   TAF supporte 3 formats pour représenter les informations d'ancre de confiance: TrustAnchorInfor, Certificate, et TBSCertificate. Dans les 3 cas, les contraintes d'ancre de confiance peut être représentée comme extensions. Dans la structure TrustAnchorInfor, les stratégies de certificat, contraintes de stratégie, les contraintes de noms, inhibitAnyPolicy, et les contraintes de bases n'apparaîssent pas comme extensions et apparaîssent dans le champ CertPathControls.

   Les extensions peuvent être marquées critique ou non. Quand les contraintes d'ancre de confiance sont forcées, les clients doivent rejeter les chemins de certification contenant une ancre de confiance avec des extensions critique non-reconnues. Quand les contraintes d'ancre de confiance ne sont pas forcées, les clients peuvent accepter les chemins de certification contenant une ancre de confiance avec les extensions critique non-reconnues. Les informations apparaissant dans le champ CertPathControls d'un objet TrustAnchorInfo doit être traité, pour s'assurer que les contraintes indiquées par ce champ sont forcés dans tous les cas.

   Pour certains types de contrainte d'ancre de confiance, il y a un manque de concordance entre les paramètres pour l'algoritme de validation de chemin de certification et l'extension qui contient la contrainte. L'algorithme de validation de chemin de certification définis essentiellement l'initial-any-policy-inhibit, initial-policy-mapping-inhibit et initial-explicit-policy comme valeurs booléennes. les extensions inhibitAnyPolicy et policyConstraints qui correspondent à ces entrées sont exprimées en valeurs entières. Dans les étapes décrites ci-dessous, la présence de l'extension inhibitAnyPolicy résulte dans la valeur initial-any-policy-inhibit à TRUE. Si une extension policyConstraints est présente et contient un champ requireExplicitPolicy, la valeur initial-explicit-policy est à TRUE. Si une extension policyConstraints est présente et contient un champ inhibitPolicyMapping, la valeur initial-policy-mapping-inhibit est à TRUE.

Utiliser les contraintes durant le traitement de chemin de certification

Cet algorithme assume que les 9 entrées définies dans la rfc5280 sont fournis au traitement de chemin, plus une variable additionnelle:

enforceTrustAnchorConstraints Indique si les contraintes de l'ancre de confiance devraient être forcés

Les implémentations conformes ne sont pas obligés de supporter ce paramètre. Si une implémentation ne supporte pas le paramètre de ce flag, il doit valider tous les chemins de certification en utilisant une valeur de TRUE pour enforceTrustAnchorConstraints.

Initialisation

Si enforceTrustAnchorConstraints vaut false, aucune étape additionnelle n'est requise. Si enforceTrustAnchorConstraints vaut true, les étapes additionnelles suivante doivent être effectuées. Ces étapes (ou équivalentes) doivent être effectuées avant les étapes d'initialisation décrites dans la rfc5280.

- Si aucun nom distinct du sujet n'est associé avec l'ancre de confiance, la validation de chemin échoue. Le nom peut apparaître dans le champ subject d'un certification ou une structure TBSCertificate ou dans le champ taName de CertPathControls dans une structure TrustAnchorInfo.
- Si les contraintes de nom sont associées avec l'ancre de confiance, définis la variable initial-permitted-subtrees égale à l'intersection des permitted subtrees de l'ancre de confiance et de l'uinitial-permited-subtrees fournis par l'utilisateur. Si une de ces 2 entrées n'est pas fournie, la variable initial-permited-subtrees est définis à la valeur qui est disponible. Si aucun n'est fournis, la variable est définie à un jeu infinis.
- Si les contraintes de nom sont associées avec l'ancre de confiance, définis la variable initial-excluded-subtrees égal à l'union des excluded subtrees de l'ancre de confiance et de l'initial-excluded-subtrees fournis par l'utilisateur. Si une de ces 2 entrées n'est pas fournis, la variable est mis à la valeur qui est disponible. Si aucune n'est fournis, la variable est définie à un jeu vide.
- Si les stratégies de certificat sont associées avec l'ancre de confiance, définis la variable user-initial-policy-set égal à l'intersection des stratégies de certificat associés avec l'ancre de confiance et le user-initial-policy-set fournis par l'utilisateur. Si une de ces 2 entrées n'est pas fournie, la variable est définie à la valeur qui est disponible. Si aucune de ces valeurs n'est fournie, définis la variable à any-policy.
- Si une valeur inhibitAnyPolicy à TRUE est associée avec l'ancre de confiance (soit dans un CertPathControls, soit dans une extension inhibitAnyPolicy) et que la valeur initial-any-policy-inhibit vaut false, définis la valeur initial-any-policy-inhibit à true.
- Si une valeur de stratégie explicite requise est associée avec l'ancre de confiance (soit dans un CertPathControls, soit dans une extension policyConstraints) et que la valeur initial-explicite-policy vaut false, définis la valeur initial-explicit-policy à true.
- Si une valeur de mappage d'inhibition de stratégie est associée avec l'ancre de confiance (soit dans un CertPathControls, soit dans une extension PolicyConstraints) et que la valeur initial-policy-mapping-inhibit vaut false, définis la valeur initial-policy-mapping-inhibit à true.
- Si une extension de contrainte de base est associée avec l'ancre de confiance et contient une valeur pathLenConstraint, défins la variable d'état max_path_length égal à la valeur pathLenConstraint de l'extension de contrainte de base.

Traitement de certificat de base

Ce document n'exige pas d'augmentation d'étapes de traitement de certificat de base. Cepenadnt, certains types de contraintes d'ancre de confiance peuvent avoir définis des étapes additionnelles, par exemple, des contraintes de contenu CMS ou des contraintes de dédouanement de l'autorité.

Préparation pour le certificat i+1

Ce document ne nécessite aucune augmentation des étapes pour préparer le traitement du certificat i+1. Cependant, certains types de contraintes d'ancre de confiance peuvent avoir définies des étapes additionnelles, par exemple, des contraintes de contenu CMS ou des contraintes de dédouanement de l'autorité.

Procédure wrap-up

Ce document ne nécessite pas d'augmentation d'étapes de procédure d'enveloppement. Cependant, certains types de contraintes d'ancre de confiance peuvent avoir définies des étapes additionnelles, par exemple, des contraintes de contenu CMS ou des contraintes de dédouanement de l'autorité.

Relations à la rfc5280

   Le traitement décris ci-dessous peut être incorporé dans une implémentation rfc5280 ou être implémenté comme pré-traitement aux entrées rfc5280 et post-traitement des sorties rfc5280.

   Pour les contraintes de nom et les contraintes liées aux stratégies, le pré-traitement peut être utilisé, fournissant à l'implémentation rfc5280 la configuration des valeurs d'entrée user-initial-policy-set, initial-policy-mapping-inhibit, initial-explicit-policy, initial-any-policy-inhibit, initial-permitted-subtrees, et initial-excluded-subtrees. La rfc5280 ne définis pas d'entrée pour les contraintes de longueur de chemin, donc les contraintes de bases ne peuvent pas être implémentées en utilisant un pré-traitement. Il peut être implémenté comme post-traitement.

   Certains types de contraintes d'ancre de confiance peuvent imposer des exigences additionnelles à l'implémentation rfc5280 pour supporter le pré-traitement et le post-traitement pour forcer les contraintes des ancres de confiance.

Considérations de sécurité

   Les implémentations qui ne forcent par les contraintes d'ancre de confiance peuvent accepter certains chemins de certification rejetés par les implémentations qui imposent les contraintes d'ancre de confiance. Par exemple, une application qui ne force pas une contrainte de stratégie de certificat inclus dans une ancre de confiance peut accepter les certificats émis sous une stratégie de certificat qui fournis un niveau d'assurance plus faible que le niveau requis.

   Les informations d'ancre de confiance doivent être stockées de manière sécurisée. Les changements d'information d'ancre de confiance peut impliquer l'acceptation de certificat qui devraient être rejetés. Par exemple, si une définition d'ancre de confiance est altérée pour supprimer une contrainte de noms, les applications peuvent accepter les certificats contenant les noms qui n'auraient été validés que dans des certificats validés par une ancre de confiance différente. Similairement, l'ajout d'ancres de confiance inapproprié à un dépôt d'ancre de confiance peut résulter en une validation de certificats via une ancre de confiance différente et avec des contraintes différente.

   La rfc5914 et rfc5934 fournissent des considérations de sécurité additionnelles au regard de la préparation, le stockage, et l'utilisation d'ancres de confiance. La rfc5280 fournis des considérations de sécurité additionnelles au regard de l'utilisation des contraintes de nom.

05 août 2015

rfc6024

Exigences de gestion d'ancre de confiance

   Une ancre de confiance représente une entité autoritative via une clé publique et des données associées. La clé publique est utilisée pour vérifier les signatures numériques, et les données associées sont utilisée pour contraindre les types d'informations pour lesquelles l'ancre de confiance a autorité. Un tiers de confiance utilise les ancres de confiance pour déterminer si un objet signé numériquement est valide en vérifiant une signature numérique en utilisant la clé publique de l'ancre de confiance, et en forçant les contraintes exprimées dans les données associées pour l'ancre de confiance. Ce document décris certains problèmes associées avec le manque de mécanisme de gestion d'ancre de confiance et définis les exigences pour les formats de données et les protocoles conçus pour adresser ces problèmes.

   Les signatures numériques sont utilisées dans de nombreuses applications. Pour que les signatures numériques fournissent l'intégrité et d'authentification, la clé publique utilisée pour vérifier la signature numérique doit être "trustée", par exemple, accepté par un tiers de confiance comme utilisation appropriée dans le contexte donné. Une clé publique utilisée pour vérifier une signature doit être configurée comme une ancre de confiance ou contenue dans un certificat qui peut être vérifiée par une chemin de certification se terminant à l'ancre de confiance. Une ancre de confiance est une clé publique et ses données associées utilisée par un tiers de confiance pour valider une signature sur un objet signé où l'objet est soit:

- Un certificat à clé publique qui commence un chemin de certification terminé par un certificat de signature ou un certificat de chiffrement.
- Un objet, autre qu'un certificat à clé publique ou liste de révocation de certificat, qui ne peut pas être validé via l'utilisation d'un chemin de certification.

   Les ancres de confiance ont seulement une signification locale, par exemple, chaque tiers de confiance (RP) est configuré avec un jeu d'ancres de confiance, soit par le RP ou par l'entité qui gère les TA dans le contexte dans lequel le RP opère. Les données associées définissent le périmètre d'une ancre de confiance en imposant des contraintes sur les signatures qui peuvent être vérifiés en utilisant l'ancre de confiance. Par exemple, si une ancre de confiance est utilisée pour vérifier les signatures dans le certificats X.509, ces contrainte peuvent inclure une combinaison d'espace de noms, de stratégie de certificat, ou de types d'application/utilisation.

   Une utilisation des signatures numérique est la vérification des signatures dans les packages de firmware chargés dans les modules hardware, tels que les modules cryptographiques, boitiers de cables, routeurs, etc. Vu que de tels périphériques sont souvent gérés à distance, les périphériques doivent être capable d'authentifier la source d'interaction de gestion et peuvent utiliser les ancres de confiance pour effectuer cette interaction. Cependant, les ancres de confiance nécessitent également une gestion. D'autres applications nécessitant une gestion d'ancre de confiance incluent les navigateurs web ( qui utilisent les ancres de confiance en authentifiant les serveurs web) et les clients mail ( qui utilisent les ancres de confiance en validant les email signés et en authentifiant les bénéficiaires des mails chiffrés ).

   Toutes les applications qui valident les signatures numériques valide les moyens de gérer un ou plusieurs jeux d'ancre de confiance. Chaque jeu d'ancre de confiance est référé dans ce document à un magasin d'ancres de confiance. Souvent, la manière de gérer les magasins d'ancre de confiance est spécifique à l'application et compte sur des moyens tiers pour établir et maintenir la fiabilité. Une application peut utiliser plusieurs magasins d'ancre de confiance, et un magasin d'ancre de confiance peut être utilisé par plusieurs applications. Chaque magasin d'ancre de confiance est gérée par au moins un gestionnaire TA; un gestionnaire TA peut gérer plusieurs magasins TA.

   Les exigences statuées dans ce document ont été préparés avant la publication des rfc5914 et rfc5934. Le document n'a pas été publié à ce moment pour permettre des changement dans les exigences durant le développement des spécification technique associées. Les exigences décrites ci-dessous sont celles qui ont été considérées durant le développement des rfrc5914 et rfc5934.

   Cette section fournis une introduction et définis la terminologie de base. La section suivante décris les problèmes avec les méthodes de gestion d'ancre de confiance actuelles. Les sections suivantes décrivent les exigences et considérations de sécurité pour une solution de gestion d'ancre de confiance.

Terminologie

Les termes suivants sont définis pour pouvoir fournir un vocabulaire pour les exigences décrites pour la gestion des ancres de confiance.

Trust Anchor Une ancre de confiance représente une entité autoritative via une clé publique et ses données associées. La clé publique est utilisée pour vérifier les signatures numériques, et les données associées sont utilisées pour contraindre les types d'information pour lesquels l'ancre de confiance est autoritative. Un tiers de confiance utilise les ancres de confiance pour déterminer si un objet signé numériquement est valide en vérifiant une signature numérique utilisant la clé publique de l'ancre de confiance, et en forçant les contraintes exprimées dans les données associées pour l'ancre de confiance.
Trust Anchor Manager Un gestionnaire d'ancre de confiance est une entité responsable de la gestion du contenu d'un magasin d'ancre de confiance. Tout au long de ce document, chaque gestionnaire d'ancre de confiance est assumé être représenté comme, ou délégué par une ancre de confiance distincte.
Trust Anchor Store Un magasin d'ancre de confiance est un jeu d'une ou plusieurs ancres de confiance stockés dans un périphérique. Un magasin d'ancre de confiance peut être géré par un ou plusieurs gestionnaire d'ancre de confiance. Un périphérique peut avoir plus d'un magasin d'ancre de confiance, chaque pouvant être utilisé par une ou plusieurs applications.

Énoncé des problèmes

   Les ancres de confiance sont utilisées pour supporter de nombreux scénarios d'application. Beaucoup de navigateurs internet et le clients mail utilisent les ancres de confiance lors de l'authentification de sessions TLS, en vérifiant les mails signés, et en générant des mails chiffrés en validant un chemin de certification avec le certificat du serveur, le certificat de l'émetteur d'un mail, ou le certificat du destinataire d'un mail. De nombreuses distributions de logiciels sont signées numériquement pour permettre l'authentification des sources du logiciel avant l'installation. Les ancres de confiance qui supportent ces application sont typiquement installés comme partie de l'OS ou application, installés durant un système de gestion de configuration de l'entreprise, ou installé directement par un OU ou une utilisateur.

   Les ancres de confiance sont généralement stockés dans des magasins d'ancre de confiance spécifique à l'application ou spécifique à l'OS. Souvent, une simple machine peut avoir de nombreux magasins d'ancre de confiance qui ne peuvent pas être synchronisés. Examiner le contenu d'un magasin d'ancre de confiance particulier implique généralement l'utilisation d'un outil propriétaire qui interagi avec un type particulier de magasin.

   La présence d'une ancre de confiance dans un magasin particulier véhicule souvent l'autorisation implicite de valider les signatures pour tous les contextes pour lequel le magasin est accédé. Par exemple, la clé publique d'une autorité d'horodatage peut être installée dans un magasin pour valider les signatures dans les horodatages. Cependant, si le magasin contenant ce TA est utilisé par plusieurs applications qui servent différents bit, la même clé pourrait être utilisée de manière inappropriée pour valider d'autres types d'objets tels que les certificats ou les réponses OCSP. Avant la publication de la rfc5914, il n'y avait pas de mécanisme standard pour limiter le périmètre d'une ancre de confiance. Une pratique commune pour adresser ce problème est de placer différents TA dans différents magasins et de limiter le jeu d'application qui accèdent à un magasin TA donné.

   La relation de confiance entre les PKI sont négociées par des autorité de stratégie. Les négociations exigent fréquemment un temps significatif pour s'assurer que toutes exigences des parties participantes sont satisfaites. Ces exigences sont exprimées, dans une certaine mesure, dans les certificats à clé publique via les contraintes de stratégie, les contraintes de noms, etc. Pour pouvoir forcer ces exigences, les magasins d'ancre de confiance doivent être gérés en accord avec les intensions d'autorité de stratégie. Sinon, les contraintes définies dans un cross-certificat pourrait être contournées en reconnaissant le sujet du cross-certificat comme ancre de confiance, qui permettrait d'implémenter des traitement de chemin qui évitent le cross-certificat.

   Les ancres de confiance sont souvent représentés comme des certificats autos-signés, qui ne fournissent généralement aucun moyen d'établir la validité de l'information contenu dans le certificat. La confiance dans l'intégrité d'une ancre de confiance est généralement établie via un moyen externe, souvent en vérifiant l'empreinte du certificat auto-signé avec une source autoritative. Les Opérations de routine d'ancre de confiance nécessitent généralement de telles vérifications externe, si la livraison de la clé d'une ancre de confiance est supportée par CMP. Idéalement, seul le jeu initial d'ancres de confiance qui sont installés dans un magasin de confiance particulier nécessitent une vérification tiers proportionnée avec les exigences de sécurité des applications en utilisant le magasin.

   Malgré d'utilisation répandue des ancres de confiance, il n'y a ni standard pour la découverte du jeu d'ancres de confiance installés dans un magasin particulier ni de moyen standard de gérer ces ancres de confiance. Le reste de ce document décris les exigences pour une solution à ce problème avec certaines considérations de sécurité.

Exigences

Cette section décris les exigences pour un protocole de gestion d'ancre de confiance. Les exigences sont fournies pour le contenu d'une ancre aussi bien que les opération de gestion des magasins.

Indépendance de transport

Une solution générale pour la gestion des ancres de confiance doit être indépendant du transport pour pouvoir s'appliquer à divers environnements de communication. Il doit fonctionner dans des environnements orientés session et store-and-forward aussi bien que dans les modèles push and pull. Pour répondre à tous ces modèles de manière uniforme, l'intégrité sans connexion et l'authentification de l'origine des données pour les transaction TA doivent être fournis au niveau applicatif. La confidentialité peut être fournie pour de telles transactions.

Raisonnement

Tous les périphériques qui utilisent les ancres de confiance ne sont pas disponible pour des opérations de gestion online; certains périphériques peut nécessiter une interaction manuelle pour la gestion des ancres de confiance. L'authentification de l'origine des données et l'intégrité sont requis pour s'assurer que la transaction n'a pas été modifiée en route. Seul l'intégrité sans connexion est requise, pour compatibilité avec les contextes store-and-forward.

pré-requis fonctionnels

   Au minimum, un protocole utilisé pour la gestion d'ancre de confiance doit permettre à un gestionnaire d'ancre de confiance d'effectuer les opérations suivantes:

- Déterminer quels ancres de confiance sont installées dans un magasin particulier
- Ajouter une ou plusieurs ancres de confiance à un magasin
- Supprimer une ou plusieurs ancres de confiance d'un magasin
- Remplacer tout un magasin

   Un protocole le gestion d'ancre de confiance doit fournir un support pour ces opérations basiques; cependant, toutes les implémentations ne supportent pas chaque options. Par exemple, certaines implémentations peuvent supporter seulement le remplacement des magasins.

   Ces exigences décrivent les opérations requises pour gérer le contenu d'un magasin d'ancre de confiance. Une opération d'édition a été omise pour des raisons de simplicité, avec des suppressions consécutives et opérations d'ajouts utilisés dans ce but. Une simple opération d'ajout ou suppression peut agir sur plus d'une ancre de confiance pour éviter les aller-retours inutiles et sont fournis pour éviter le besoins de toujours remplacer tout un magasin. Le remplacement d'un magasin peut être utile comme une opération alternative aux opérations d'ajouts et suppression.

Gestion des cibles

   Une protocole pour la gestion TA doit permettre à une transaction TA d'être dirigée vers:

- Tous les magasins TA dont le manager est responsable
- Une liste énumérée d'un ou plusieurs groupes nommés de magasins
- un magasin d'ancre de confiance individuel

   Les connexions entre les PKI peuvent être accomplies en utilisant différents moyens. La cross-certification unilatérale ou bilatérale peut être effectuée, ou une communauté peut simplement élire pour accepter explicitement une ancre de confiance depuis une autre communauté. Généralement, ces décisions se font dans l'entreprise. Dans certains scénarios, il peut être utile d'établir ces connexions pour une petite communauté dans une entreprise. Les mécanismes des grandes entreprises, tel que les cross-certificats sont mal adaptés à cet effet vu que la révocation du certificat affecte l'ensemble de l'entreprise.

   Un protocole de gestion d'ancre de confiance peut adresser ce problème en supportant l'installation limitée des ancres de confiance (ex, l'installation des TA dans des sous-jeux de communauté d'utilisateurs de l'entreprise), et en supportant l'expression des contraintes dans l'utilisation des ancres de confiance par des tiers de confiance. L'installation limitée nécessite la capacité d'identifier les membre de la communauté qui sont destinés à s'appuyer sur une ancre de confiance particulière, et la capacité de vérifier et reporter le contenu des magasins. Les contraintes d'ancre de confiance peuvent être utilisés pour représenter les limitations qui peuvent être exprimées dans un cross-certificat, et l'installation limitée assure que la reconnaissance de l'ancre de confiance ne comprend par nécessairement toute une entreprise.

   Les configuration d'ancre de confiance peuvent être uniforme dans une entreprise, ou peuvent être unique à une simple application ou un petit jeu d'applications. De nombreux périphériques et certaines application utilisent plusieurs magasins. En fournissant un moyen d'adresser un magasin spécifique ou une collection de magasins, un protocole de gestion d'ancre de confiance peut permettre une gestion efficace de tous les magasins sous le contrôle d'un gestionnaire d'ancre de confiance.

Délégation de l'autorité du gestionnaire TA

   Un protocole de gestion d'ancre de confiance doit permettre un transfert sécurité du contrôle d'un magasin d'ancre de confiance d'une manager à un autre. Il devrait également permettre la délégation pour les opérations spécifiques sans nécessiter de délégation de toutes les capacités de gestion d'ancres de confiance.

   Le renouvellement de clé du gestionnaire d'ancre de confiance est un type de transfert qui doit être supporté. Dans ce cas, la nouvelle clé sera assignée aux mèmes privilèges que l'ancienne clé.

   La création des ancres de confiance pour des buts spécifiques, tels que la signature de firmware, est un autre exemple de délégation. Par exemple, un gestionnaire d'ancre de confiance peut déléguer seulement d'autorité de signer des firmware à une entité, mais interdit d'autres délégations de ce privilège, ou le gestionnaire d'ancre de confiance peut autorisé la délégation à d'autres autorités de signature de firmwares délégués à d'autres entités.

Support rfc 5280

Un protocole de gestion d'ancre de confiance doit permettre la gestion des ancres de confiance qui seront utilisé pour valider les chemins de certification et les CRL en accord avec les rfc5280 et rfc5055. Un format d'ancre de confiance doit permettre la représentation de contraintes qui influencent la validation de chemin de certification ou l'établissement de périmètre d'utilisation de la clé publique de l'ancre de confiance. Des exemples de telles contraintes sont les contraintes de noms, les stratégies de certificat, et l'utilisation de clé.

La validation de chemin de certification est une des applications d'ancre de confiance les plus communes. Les règles pour utiliser les ancres de confiance pour la validation de chemin sont établis dans la rfc5280. La rfc5055 décris l'utilisation des ancres de confiance pour la validation de chemin déléguée. Les ancres de confiance utilisée pour valider les chemins de certification sont responsable de la livraison, possiblement via une délégation, des informations de statut de révocation des certificats qu'il émet; c'est souvent accomplis en signant une CRL.

Autres supports

Un protocole de gestion d'ancre de confiance doit permettre la gestion des ancres de confiance qui peuvent être utilisé pour d'autres buts que la validation de chemin de certification, incluant les ancres de confiance qui ne peuvent pas être utilisé pour la validation de chemin de certification. Il devrait être possible d'autoriser une ancre de confiance à déléguer l'autorité (à d'autres TA ou propriétaires de certificat) et d'empêcher une ancre de confiance d'être délégué.

Les ancres de confiance sont utilisées pour valider une variété d'objets signés, pas seulement les certificats à clé publique et les CRL. Par exemple, une ancre de confiance peut être utilisée pour vérifier les packages de firmware (rfc5108), les réponses OCSP (rfrc2560), les réponses SCVP (rfc5055), ou les horodatages (rfc3161). Les TA qui sont autorisées pour l'utilisation de certains de ces types d'opérations ne peuvent pas être autorisés pour vérifier les certificats à clé publique ou les CRL. Donc, il est important d'être capable d'imposer des contraintes sur la manière dont un TA donné est employé.

Format d'ancre de confiance

Au minimum, un protocole de gestion d'ancre de confiance doit supporter la gestion des ancres de confiances représentés comme certificats auto-signés et les ancres de confiance représentés comme un nom distinct, informations de clé publique, et, optionnellement, les données associées. La définition d'une ancre de confiance doit inclure une clé publique, un algorithme de clé publique, et, si nécessaire, les paramètres de la clé publique. Quand la clé publique est utilisée pour valider les chemins de certification ou les CRL, un nom distinct doit également être inclus (rfc5280). Un format d'ancre de confiance doit permettre la spécification d'un identifiant de clé publique pour permettre à d'autres applications d'ancre de confiance, par exemple, la vérification des données signées en utilisant la structure SignedData (CMS - rfc5652). Un format d'ancre de confiance devrait également permettre la représentation des contraintes qui peuvent être appliquées pour restreindre l'utilisation d'une ancre de confiance.

Avant la publication de la rfc5914, il n'y avait pas de format d'ancres de confiance. Les certificats X.509 auto-signés sont généralement utilisés, mais la rfc5280 ne mandate par la représentation d'ancre de confiance particulier. Elle exige seulement que les information de clé publique de l'ancre de confiance et le nom distinct soit disponible durant la validation du chemin de certification. CMS est largement utilisé pour protéger divers types de contenu en utilisant les signatures numériques, incluant le contenu qui peut être vérifié directement en utilisant une ancre de confiance, tels que les packages de firmware. Les contraintes peuvent inclure une périodes de validité, des contraintes sur la validation de chemin de certification, etc.

Authentification

   Une entité reçevant une donnée de gestion d'ancre de confiance doit être capable d'authentifier l'identité du partie en fournissant les informations et doit être capable de confirmer que le partie est autorisé à fournir ces informations.

   Un gestionnaire d'ancre de confiance doit être capable d'authentifier quel magasin d'ancre correspond à un listing du contenu du magasin et être capable de confirmer que le contenu du listing n'a pas été altéré.

   L'authentification de l'origine des données et l'intégrité sont requis pour supporter les opération de gestion à distance, même quand les transaction de gestion des TA sont effectuées via des communications store-and-forward.

Réduire la dépendance des mécanimes tiers

En effectuant des opérations d'ajout, un protocole de gestion d'ancre de confiance devrait permettre de vérifier automatiquement l'intégrité des TA par un tiers de confiance sans s'appuyer sur des mécanismes tiers.

Traditionnellement, une ancre de confiance est distribuée via un mécanisme tiers avec vérification manuelle de l'intégrité avant l'installation. L'installation est généralement effectuée par quelqu'un avec suffisamment de privilèges administratifs dans le système recevant l'ancre de confiance. La fiabilité des mécanismes de confiance tiers est un problème avec les approches de gestion des ancre de confiance actuelles, et la réduction du besoin de mécanismes tiers est une motivation principale pour le développement de mécanismes de gestion d'ancre de confiance. Idéalement, les mécanismes tiers sont requis seulement durant l'initialisation du magasin.

Détection des répétitions

Un protocole de gestion d'ancre de confiance doit permettre aux participants engagés dans l'échange du protocole de gestion de détecter les attaques replay. Un mécanisme de détection de replay qui n'introduit pas d'exigence pour une source sûre de temps doit être disponible. Les mécanismes qui ne nécessitent pas de source sûre de temps peuvent être disponibles.

La détection de replay des transactions de gestion d'ancre de confiance est requise pour supporter les opérations de gestion distantes. Le replay d'anciennes transaction pourraient résulter en la réintroduction d'ancres de confiance compromises. Certains périphériques qui utilisent les ancres de confiance n'ont pas accès à une source de temps sûre, donc un mécanisme de détection de replay qui nécessite une source de temps sûre est insuffisant.

Compromission ou récupération après sinistre

Un protocole de gestion d'ancre de confiance doit permettre la récupération lors de la compromission ou la perte de la clé privée d'une ancre de confiance, incluant la clé privée autorisée à service de gestion d'ancre de confiance, sans nécessiter la ré-initialisation du magasin.

La compromission ou la perte d'une clé privée correspondant à une ancre de confiance peut avoir des conséquences négatives significatives. Actuellement, dans certains cas, la ré-initialisation de tous les magasin affectés est requise pour récupérer lors d'une perte ou d'une compromission d'une clé d'ancre de confiance. À cause du coût associés avec la ré-initialisation, un protocole de gestion d'ancre de confiance devrait supporter les options de récupération qui ne nécessitent pas de ré-initialisation du magasin.

Considérations de sécurité

   La clé publique utilisé pour authentifier une transaction de gestion TA peut avoir été placée dans le client comme résultat d'une première transaction de gestion TA ou durant une configuration initiale. Dans de nombreux scénarios, au moins une clé publique autorisé pour la gestion d'ancre de confiance doit être placée dans chaque magasin d'ancre de confiance. Cette clé publique peut être transporté et vérifiée en utilisant des moyens tiers. Dans tous les scénarios, sans regarder le mécanisme d'authentification, au moins un gestionnaire d'ancre de confiance doit être établis pour chaque magasin d'ancre de confiance durant la configuration initiale du magasin.

   La compromission d'une clé privée d'une ancre de confiance peut résulter en de nombreux problèmes de sécurité, incluant l'émission de sécurité compromis ou des ancres de confiance volé.

   L'utilisation de contraintes basées sur l'ancre de confiance nécessite une grande attention en définissant les ancres de confiance. Des erreurs de la part d'un gestionnaire pourrait résulter des déni de service ou des conséquences de sécurité sérieuses. Par exemple, si une contrainte de nom pour une ancre de confiance qui sert de racine d'une PKI inclus une faute de frappe, il en résulte un déni de service pour les propriétaires de certificats. Si un gestionnaire d'ancre de confiance délègue par inadvertance tous ses privilège et les délégations suppriment le gestionnaire d'ancre de confiance des magasins d'ancre de confiance sous son contrôle, la récupération peut nécessiter la ré-initialisation de tous les magasins d'ancre de confiance affectés.

   La rfc5280 nécessite que la validation de chemin de certificat soit initialisée avec un nom du sujet TA et une clé publique, mais n'exige pas le traitement d'autres information, tels quel les contraintes de nom. L'inclusion de contraintes dans les ancres de confiance est optionnelle. Quand des contraintes sont explicitement incluse par un gestionnaire d'ancre de confiance en utilisant un protocole de gestion d'ancre de confiance, on s'attend à ce que l'algorithme de validation de chemin de certification utilise ces contraintes. Les propriétaires d'application doivent confirmer l'implémentation de traitement de chemin supportant le traitement des contraintes basées sur TA, si requis.

   De nombreuses considération de sécurité de la rfc5280 sont également applicable à la gestion des ancres de confiance.

14 août 2015

rfc6960

Online Certificate Status Protocol - OCSP

   Ce document spécifie un protocole utile pour déterminer le statut courant d'un certificat numérique sans nécessiter de CRL. Des mécanismes additionnels adressant les exigences opérationnelles PKIX sont spécifiés dans des documents séparés.

   À la place de, ou en supplément de, vérifier avec une CRL périodique, il peut être nécessaire d'obtenir des informations rapide du status de révocation des certificats. Le protocole de statut de certificat en ligne (OCSP) permet aux applications de déterminer l'état d'un certificat identifié. OCSP peut être utilisé pour satisfaire certaines exigences opérationnelles en fournissant des informations de révocation plus récente qu'il est possible avec les CRL et peut également être utilisé pour obtenir des informations de statut additionnels. Un client OCSP émet une demande de statut à un répondeur OCSP et suspend l'acceptation des certificats en question jusqu'à ce que le répondeur fournir une réponse.

   Ce protocole spécifie les données qui doivent être échangées entre une application vérifiant le statut d'un ou plusieurs certificat le serveur fournissant le statut correspondant.

Requête

   Une demande OCSP contient les données suivantes:

- Une version de protocole
- Une demande de service
- Un identifiant du certificat cible
- Des extensions optionnelles, qui peuvent être traitées par le répondeur OCSP

   Une fois le demande reçue, un répondeur OCSP détermine si:

1. Le message est bien formé
2. Le répondeur est configuré pour fournir le service demandé
3. La demande contient les informations nécessaire.

   Si une de ces conditions n'est pas rencontrée, le répondeur OCSP produit un message d'erreur; sinon, il retourne une réponse définitive.

Réponse

   Les réponses OCSP peuvent être de différents types. Une réponse OCSP consiste d'un type de réponse et les octets de la réponse. Il y a un type de base de réponse OCSP qui doit être supporté par tous les serveur et clients OCSP. Le reste de cette section concerne seulement ce type de réponse de base.

   Tous les messages de réponse définitives doivent être signés numériquement. La clé utilisée pour signer la réponse doit appartenir à un parmi:

- La CA qui a émis le certificat en question
- Un répondeur trusté dont la clé publique est validé par le demandeur
- Un Répondeur désigné par la CA (Répondeur autorisé) qui maintient un certificat spécialement marqué émis directement par la CA, indiquant que le répondeur peut émettre des réponses OCSP pour cette CA.

   Un message de réponse définitive est composée de:

- La version de la syntaxe de la réponse
- L'identifiant du répondeur
- L'horodatage de la génération de la réponse
- Les réponses pour chaque certificat dans la demande
- Des extensions optionnelles
- L'OID de l'algorithme de signature
- La signature calculée par un hash de la réponse

   La réponse pour chaque certificat dans la demande consiste de:

- L'identifiant de certificat cible
- La valeur du statut du certificat
- L'interval de validité de la réponse
- Des extensions optionnelles.

   Cette spécification définis les indicateurs de la réponse définitive à utiliser dans la valeur de statut de certificat:

- good
- revoked
- unknown

   L'état "good" indique une réponse positive. Au minimum, cette réponse positive indique qu'aucun certificat avec le numéro de série demandé dans son interval de validité n'est révoqué. Cet état ne signifie pas nécessairement que le certificat a été émis ou que l'heure à laquelle la réponse a été produite est dans un intervalle de validité du certificat. Les extensions de réponse peuvent être utilisés pour transporter des informations additionnelles sur l'affirmation faite par le répondeur au regard du statut du certificat, tels que la déclaration positive sur l'émission, la validité, etc.

   L'état 'revoked' indique que le certificat a été révoqué, soit temporairement (certificateHold) soit de manière permanente. Cet état peut également être retourné si la CA associée n'a pas d'enregistrement de certificat émis avec le numéro de série du certificat dans la demande, en utilisant la clé courante ou précédente (référé à un certificat 'non-émis' dans ce document).

   L'état 'unknown' indique que le répondeur ne connaît pas le certificat demandé, généralement parce que le demandeur indique un émetteur non connus qui ne sert par ce répondeur.

   NOTE: Le statut 'revoked' indique qu'un certificat avec le numéro de série demandé devrait être rejeté, alors que le statut 'unknown' indique que le statut ne peut pas être déterminé par ce répondeur, permettant ainsi au client de décider s'il veut tenter une autre source d'information de statut (tel qu'une CRL). Cela rend la réponse 'revoked' prévue pour les certificats non-émis où l'intention du répondeur est de forcer le client à rejeter le certificat au lieu de tenter une autre source. Le statut 'revoked' est optionnel pour les certificats non-émis pour pouvoir maintenir la compatibilité avec les déploiements rfc2560. Par exemple, le répondeur peut ne pas avoir connaissance si un numéro de série demandé a été assigné à un certificat émis, ou le répondeur peut fournir des réponses pré-produites en accord avec la rfc5019 et, pour cette raison, il n'est pas capable de fournir une réponse signée pour tous les numéro de série non-émis.

   Quand un répondeur envoie une réponse 'revoked' à une demande de statut pour un certificat non-émis, le répondeur doit inclure l'extension de réponse de définition révoqué étendue dans la réponse, indiquant que le répondeur OCSP supporte la définition étendue de l'état 'revoked' pour couvrir également les certificats non-émis. En plus, le SingleResponse lié à ce certificat non-émis:

- Doit spécifique la raison de révocation certificateHold
- Doit spécifier le revocationTime au 1 Janvier 1970
- Ne doit pas inclure une extension de référence de CRL ou une extension d'entrée de CRL.

Exceptions

   En cas d'erreurs, le répondeur OCSP peut retourner un message d'erreur. Ces messages ne sont pas signés. Les erreurs peuvent être d'un des types suivant:

- malformedRequest
- internalError
- tryLater
- sigRequired
- unauthorized

   Un serveur produit la réponse 'malformedRequest' si la requête reçue n'est pas conforme à la syntaxe OCSP.

   La réponse 'internalError' indique que le répondeur OCSP a atteins un état inconsistant. La demande devrait être retentée potentiellement avec un autre répondeur.

   Dans le cas ou le répondeur OCSP est opérationnel mais incapable de retourner un status pour le certificat demandé, la réponse 'tryLater' peut être utilisée pour indiquer que le service existe mais est temporairement en incapacité de répondre.

   La réponse 'sigRequired' est retournée dans le cas où le serveur exige que le client signe la demande pour pouvoir construire la réponse.

   La réponse 'unauthorized' est retournée dans les cas où le client n'est pas autorisé à faire cette demande à ce serveur ou le serveur n'est pas capable de répondre autoritativement.

Sémantiques thisUpdate, nextUpdate, et produceAt

Les réponses définies dans ce document peuvent contenir 4 dates -- thisUpdate, nextUpdate, producedAt, et revocationTime. La sémantique de ces champs est:

thisUpdate La date la plus récente à laquelle le statut est connu du répondeur pour être correct.
nextUpdate La date à laquelle ou avant laquelle de nouvelles informations seront disponibles
producedAt La date à laquelle le répondeur a signé cette réponse
revocationTime La date à laquelle le certificat a été révoqué.

Pré-production de réponse

Les répondeurs OCSP peuvent pré-produire des réponses signées spécifiant le statut des certificats à une date spécifiée. La date à laquelle le statut est connu pour être correct doit être refléter dans le champ thisUpdate de la réponse. La date à ou avant laquelle la nouvelle information sera disponible est reflété dans le champ nextUpdate, alors que la date à laquelle la réponse a été produite apparaît dans le champ producedAt de la réponse.

Délégation de l'autorité de signature OCSP

La clé qui signe les informations de statut de certificat n'a pas besoin d'être la même que celle qui a signé le certificat. Un émetteur de certificat peut explicitement déléguer l'autorité de signature OCSP en émettant un certificat contenant une valeur unique pour l'extension d'utilisation de clé étendue dans le certificat du signataire OCSP. Ce certificat doit être émis directement au répondeur par la CA.

Clé CA compromise

Si un répondeur OCSP sait qu'une clé privé de CA particulière a été compromise, il peut retourner l'état 'revoked' pour tous les certificats émis par cette CA.

Contenu du certificat

   Pour transporter aux clients OCSP un point d'accès aux informations, les CA doivent fournir la capacité d'inclure l'extension d'information d'accès de l'autorité dans les certificats qui peuvent être vérifiés en utilisant OCSP. Alternativement, l'accessLocation pour le fournisseur OCSP peut être configuré localement dans le client OCSP.

   Les CA qui supportent un service OCSP, soit maintenus localement ou fournis par un répondeur autorisé, doivent fournir un URI accessLocation et l'OID id-ad-ocsp pour l'accessMethod dans la séquence AccessDescription.

   La valeur du champ accessLocation dans le certificat du sujet définis le transport (ex: HTTP) utilisé pour accéder au répondeur OCSP et peut contenir d'autres informations dépendantes du transport (ex: une URL).

Exigence pour l'acceptation de réponse signée

Avant d'accepter une réponse signée pour un certificat particulier comme valid, les clients OCSP doivent confirmer que:

1. Le certificat identifié dans la réponse reçue correspond au certificat qui a été identifié dans la demande correspondant
2 La signature dans la réponse est valide
3. L'identité du signataire correspond au destinataire prévu de la demande
4. Le signataire est actuellement autorisé à fournir une réponse pour le certificat en question
5. La date à laquelle le statut a été indiqué est correct est suffisamment récente
6. Si disponible, la date à laquelle ou avant laquelle de nouvelles informations seront disponible est supérieurs à la date courante.

Détails du protocole

La syntaxe ASN.1 importe les termes définis dans la rfrc5280. Pour le calcul de la signature, la donnée à signer est encodée en utilisant DER. Le tagging explicite ASN.1 est utilisé comme défaut sauf si le contraire est mentionné. Les termes importés d'ailleurs sont Extensions, CertificateSerialNumber, SubjectPublicKeyInfo, Name, AlgorithmIdentifier, et CRLReasons.

Syntaxe de la demande

   Cette section spécifie la spécification ASN.1 pour une demande de confirmation. Le formatage actuel du message peut varier, en fonction du mécanisme de transport utilisé (HTTP, SMTP, LDAP, etc).

La structure ASN.1 correspondant à OCSPRequest est:
OCSPRequest ::= SEQUENCE {
    tbsRequest TBSRequest,
    optionalSignature [0] EXPLICIT Signature OPTIONAL }

TBSRequest ::= SEQUENCE {
    version [0] EXPLICIT Version DEFAULT v1,
    requestorName [1] EXPLICIT GeneralName OPTIONAL,
    requestList SEQUENCE OF Request,
    requestExtensions [2] EXPLICIT Extensions OPTIONAL }
    Signature ::= SEQUENCE {
    signatureAlgorithm AlgorithmIdentifier,
    signature BIT STRING,
    certs [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL}

Version ::= INTEGER { v1(0) }

Request ::= SEQUENCE {
    reqCert CertID,
    singleRequestExtensions [0] EXPLICIT Extensions OPTIONAL }

CertID ::= SEQUENCE {
     AlgorithmIdentifier,
    issuerNameHash OCTET STRING, -- Hash of issuer's DN
    issuerKeyHash OCTET STRING, -- Hash of issuer's public key
    serialNumber CertificateSerialNumber }

- tbsRequest est la demande OCSP optionnellement signée
- optionalSignature contient l'identifiant d'algorithme et ses paramètres associés dans signatureAlgorithm; la valeur de la signature dans signature; et optionnellement les certificat que le serveur a besoin pour vérifier la signature.
- version indique la version du protocole, qui est v1 (0) pour ce document.
- requestorName est optionnel est indique le nom du demandeur OCSP
- requestList contient une ou plusieurs demande de statut de certificat.
- requestExtensions est optionnel et inclus des extensions applicable aux demandes trouvées dans reqCert.
- reqCert contient l'identifiant d'un certificat cible
- singleRequestExtensions est optionnel et inclus des extensions applicable à cette demande de statut de certificat.
- hashAlgorithm est l'algorithme de hashage utilisé pour générer les valeurs issuerNameHash et issuerKeyHash.
- serialNumber est le numéro de série du certificat pour lequel le statut est demandé

Notes sur les demandes OCSP

   La principale raison d'utiliser la hash de la clé publique de la CA en plus du hash de nom de la CA pour identifier l'émetteur est qu'il est possible qui 2 CA choisissent d'utiliser le même nom. 2 CA ne vont jamais, cependant, avoir la même clé publique sauf si les CA on choisis d'utiliser la même clé explicitement, ou si une des clés de CA est compromise.

   Le support pour une extension spécifique est optionnel. Le flag de criticité ne devrait pas être utilisé. Les extensions non-reconnus doivent être ignorés, sauf si la criticité est définie.

   Le demandeur peut choisir de signer la demande OCSP. Dans ce cas, la signature est calculée sur la structure tbsRequest. Si la demande est signée, le demandeur doit spécifier son nom dans le champ requestorName. Également, pour les demandes signées, le demandeur peut inclure les certificats qui aident le répondeur OCSP à vérifier la signature de demandeur dans le champ certs de Signature.

Syntaxe de la réponse

   Cette section spécifie la spécification ASN.1 pour une réponse de confirmation. Le formatage actuel du message peut varier, en fonction du mécanisme de transport.

Une réponse OCSP consiste au minimum d'un champ responseStatus indiquand le traitement du statut de la demande. Si la valeur de responseStatus est une des conditions d'erreur, le champ responseBytes n'est pas mis.
OCSPResponse ::= SEQUENCE {
    responseStatus OCSPResponseStatus,
    responseBytes [0] EXPLICIT ResponseBytes OPTIONAL }

OCSPResponseStatus ::= ENUMERATED {
    successful (0), -- Response has valid confirmations
    malformedRequest (1), -- Illegal confirmation request
    internalError (2), -- Internal error in issuer
    tryLater (3), -- Try again later
            -- (4) is not used
    sigRequired (5), -- Must sign the request
    unauthorized (6) -- Request unauthorized
}

La valeur pour responseBytes consiste d'un identifiant d'objet et d'une syntaxe response identifiée par cet OID encodé comme chaîne d'octets.
ResponseBytes ::= SEQUENCE {
    responseType OBJECT IDENTIFIER,
    response OCTET STRING }

Pour un répondeur OCSP basique, responseType sera id-pkix-ocsp-basic
id-pkix-ocsp OBJECT IDENTIFIER ::= { id-ad-ocsp }
id-pkix-ocsp-basic OBJECT IDENTIFIER ::= { id-pkix-ocsp 1 }

   Les répondeurs OCSP doivent être capable de produire des réponses de type id-pkix-ocsp-basic. Les clients OCSP doivent être capable de recevoir et traiter les réponse de type id-pkix-ocsp-basic.

La valeur pour la réponse doit être un encodé DER de BasicOCSPResponse
BasicOCSPResponse ::= SEQUENCE {
    tbsResponseData ResponseData,
    signatureAlgorithm AlgorithmIdentifier,
    signature BIT STRING,
    certs [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL }

La valeur pour la signature doit être calcurée sur le hash de l'encodé DER de ResponseData. Le répondeur peut inclure des certificats dans le champs certs pour aider le client OCSP à vérifier le signature du répondeur. Si aucun certificat n'est inclus, alors certs devrait être absent.
ResponseData ::= SEQUENCE {
    version [0] EXPLICIT Version DEFAULT v1,
    responderID ResponderID,
    producedAt GeneralizedTime,
    responses SEQUENCE OF SingleResponse,
    responseExtensions [1] EXPLICIT Extensions OPTIONAL }

    ResponderID ::= CHOICE {
    byName [1] Name,
    byKey [2] KeyHash }

KeyHash ::= OCTET STRING -- SHA-1 hash of responder's public key (excluding the tag and length fields)

SingleResponse ::= SEQUENCE {
    certID CertID,
    certStatus CertStatus,
    thisUpdate GeneralizedTime,
    nextUpdate [0] EXPLICIT GeneralizedTime OPTIONAL,
    singleExtensions [1] EXPLICIT Extensions OPTIONAL }

CertStatus ::= CHOICE {
    good [0] IMPLICIT NULL,
    revoked [1] IMPLICIT RevokedInfo,
    unknown [2] IMPLICIT UnknownInfo }

RevokedInfo ::= SEQUENCE {
    revocationTime GeneralizedTime,
    revocationReason [0] EXPLICIT CRLReason OPTIONAL }

UnknownInfo ::= NULL

Notes sur les réponses OCSP

   Les réponses peuvent contenir 4 dates -- thisUpdate, nextupdate, producedAt, et revocationTime. Les sémantiques de ces champs sont définis plus haut. Le format pour GeneralizedTime est définis dans la rfc5280.

   Les champs thisUpdate et nextUpdate définissent un intervalle de validité recommandé. Cet intervalle corresponds à l'interval {thisUpdate, nextUpdate} dans les CRL. Les réponses dont la valeur nextUpdate est avant l'heure système local devraient être considérés comme non sûr. Les réponses dont thisUpdate est ultérieur à la date système local devraient être considérés comme non-sûr.

   Si nextUpdate n'est pas mis, le répondeur indique que de nouvelles informations sont disponible tout le temps.

Répondeurs autorisés

   La clé qui signe les informations de statut d'un certificat n'a pas besoin d'être la même clé que celle qui a signé le certificat. Il est nécessaire, cependant, de s'assurer que l'entité qui signe ces informations est autorisée à le faire. Ainsi, un émetteur de certificat doit faire une des opérations suivantes:

- Signer les réponses OCSP lui-même
- Désigner explicitement cette autorité à une autre entité.

   La délégation de signature OCSP doit être désignée en incluant id-kp-OCSPSigning dans l'extension d'utilisation de clé étendue inclue dans le certificat du répondeur OCSP. Ce certificat doit être émis directement par la CA qui est identifiée dans la requête.

   La CA devrait utiliser la même clé pour émettre un certificat de délégation que celle utilisée pour signer le certificat à vérifier. Les systèmes s'appuyant sur les réponses OCSP doivent reconnaître un certificat de délégation comme étant émis par la CA qui a émis le certificat en question seulement si le certificat de délégation et le certificat à vérifier ont été signés par la même clé.

Note: Pour des raisons de compatibilité avec la rfc2560, il n'est pas interdit d'émettre un certificat pour un répondeur autorisé en utilisant une clé différente que la clé utilisée pour émettre le certificat à vérifier. Cependant, une telle pratique est fortement découragée, vu que les clients ne sont pas obligés de reconnaître un répondeur avec un tel certificat comme répondeur autorisé.
id-kp-OCSPSigning OBJECT IDENTIFIER ::= {id-kp 9}

   Les systèmes ou applications qui reposent sur les réponses OCSP doivent être capable de détecter et forcer l'utilisation de la valeur id-kp-OCSPSigning comme décris plus haut. Ils peuvent fournir un moyen de configurer localement une ou plusieurs autorités de signature OCSP et d-e spécifier un jeu de CA pour lesquelles chaque autorité de signature est validée. Ils doivent rejeter la réponse si le certificat exige de valider la signature dans la réponse qui ne rencontre pas un des critères suivants:

1. Correspond à une configuration locale de l'autorité de signature OCSP pour le certificat en question
2. Est le certificat de la CA qui a émis le certificat en question
3. Inclus une valeur id-kp-OCSPSigning dans l'extension d'utilisation de clé étendue et est émis par la CA qui a émis le certificat en question comme statué plus haut.

   D'autre critères d'acceptation ou de rejet peuvent d'appliquer à la réponse ou au certificat utilisé pour valider la signature dans la réponse.

Vérification de révocation d'un répondeur autorisé

Vu qu'un répondeur OCSP autorisé fournis des informations de statut pour une ou plusieurs CA, les clients OCSP doivent savoir comment vérifier que le certificat d'un répondeur autorisé n'a pas été révoqué. Les CA peuvent choisir de répondre à ce problème d'une des 3 manières suivantes:

- Une CA peut spécifier qu'un client OCSP peut truster un répondeur pour la durée de vie du certificat du répondeur. La CA le fait en incluant l'extension id-pkix-ocsp-nocheck. Cette extension devrait être non-critique. La valeur de l'extension doit être null. Les CA émettant un tel certificat doivent réaliser qu'une clé de répondeur compromise est aussi sérieux que la compromission de la clé de la CA. utilisée pour signer les CRL, au moins pour la période de validité de ce certificat. Les CA peuvent choisir d'émettre ce type de certificat avec une durée de vie très courte et le renouveler fréquemment.
- Une CA peut spécifier comment le certificat du répondeur est vérifié pour la révocation. Cela peut être fait en utilisant les points de distribution de CRL si la vérification devrait être faite en utilisant les CRL, ou en utilisant les accès d'information de l'autorité si la vérification devrait être faite d'une autre manière.
- Une CA peut choisir de ne pas spécifier de méthode de vérification de révocation pour le certificat du répondeur, auquel cas il sera du ressort de la stratégie de sécurité locale du client OCSP de décider si ce certificat devrait être vérifié pour la révocation ou non.

Réponse de base

   Le type de réponse de base contient:

- La version de la syntaxe de réponse, qui doit être v1 (0) pour ce document
- Soit le nom du répondeur ou un hash de la clé publique du répondeur dans ResponderID.
- La date à laquelle la réponse a été générée.
- Les réponses pour chaque certificats dans une requête
- Des extensions optionnelles
- Une signature calculée via un hash de la réponse
- L'OID de l'algorithme de signature.

   Le but de l'information ResponderID est de permettre aux clients de trouver le certificat utilisé pour signer une réponse OCSP signée. Cependant, l'information doit correspondre au certificat qui a été utilisé pour signer la réponse. Le répondeur peut inclure des certificats dans le champ certs de BasicOCSPResponse qui aide le client OCSP à vérifier la signature du répondeur.

- Un identifiant du certificat pour lequel les informations de statut de révocation sont fournies
- Le statut de révocation du certificat (good, revoked, ou unknown); si révoqué, il indique la date à laquelle le certificat a été révoqué et, optionnellement, la raison de la révocation.
- L'intervalle de validité de la réponse
- Des extensions optionnelles.

   La réponse doit inclure un SingleResponse pour chaque certificat dans la demande. La réponse ne devrait pas inclure d'élément SingleResponse additionnels, mais, par exemple, les répondeurs OCSP qui pré-génèrent les réponses peuvent inclure des éléments SingleResponse additionnels si nécessaire pour améliorer les performances de pré-génération des réponses ou l'efficacité des cache.

Algorithmes cryptographiques obligatoires et optionnels

Les clients qui requièrent les services OCSP doivent être capable de traiter les réponses signées en utilisant RSA avec SHA-256 (OID sh256WithRSAEntryption - rfc4055). Les clients devraient être également capable de traiter les réponses signées en utilisant RSA avec SHA-1 et DSA avec SHA-1. Les client peuvent supporter d'autres algorithmes.

Extensions

Cette section définis des extensions standards, basées sur le modèle d'extension employé dans le certificats X.509v3. Le support pour toutes les extensions est optionnel pour les clients et les répondeurs. Pour chaque extension, la définition indique sa syntaxe, le traitement effectué par le répondeur, et les extensions qui sont incluses dans la réponse correspondante.

Nonce

Le nonce lie cryptographiquement une demande et une réponse pour empêcher les attaques replay. Le nonce est inclus comme une des requestExtensions dans les demandes, et est inclus dans les réponses comme une des responseExtensions. Dans la demande et la réponse, nonce sera identifié par l'identifiant d'objets id-pkix-ocsp-nonce, alors que extnValue est la valeur de nonce.
id-pkix-ocsp OBJECT IDENTIFIER ::= { id-ad-ocsp }
id-pkix-ocsp-nonce OBJECT IDENTIFIER ::= { id-pkix-ocsp 2 }

Nonce ::= OCTET STRING

CRL References

Il peut être désirable pour un répondeur OCSP d'indiquer la CRL dans laquelle un certificat revoqué ou onHold est trouvé. Cela peut être utile quand OCSP est utilisé entre des dépôts, et également comme mécanisme d'audit. La CRL peut être spécifiée par une URL, un numéro de CRL, ou une date de création de la crl. Ces extensions sont spécifiés comme singleExtensions. L'identifiant pour cette extension est ip-pkix-ocsp-crl, et la valeur est CrlID.
id-pkix-ocsp-crl OBJECT IDENTIFIER ::= { id-pkix-ocsp 3 }

CrlID ::= SEQUENCE {
    crlUrl [0] EXPLICIT IA5String OPTIONAL,
    crlNum [1] EXPLICIT INTEGER OPTIONAL,
    crlTime [2] EXPLICIT GeneralizedTime OPTIONAL }

   Pour le choix crlUrl, l'IA5String va spécifier l'URL à laquelle la CRL est disponible. Pour crlNum, l'INTEGER spécifique la valeur de l'extension crlNumber. Pour crlTime, le GeneralizedTime indique la date à laquelle la crl a été émise.

Type de réponse acceptable

Un client OCSP peut souhaiter spéifier le type de réponse qu'il comprend. Pour cela, il devrait utiliser une extension avec l'OID id-pkix-ocsp-response et la valeur AcceptableResponses. Cette extensio est inclue comme une des requestExtensions dans les demandes. Les OID inclus dans AcceptableResponses sont les OID des types de réponse que ce client peut accepter.
id-pkix-ocsp-response OBJECT IDENTIFIER ::= { id-pkix-ocsp 4 }

AcceptableResponses ::= SEQUENCE OF OBJECT IDENTIFIER

Comme noté plus haut, les répondeurs OCSP doivent être capable de répondre avec les réponses de type ip-pkix-ocsp-basic. Les clients OCSP doivent être capable de reçevoir et de traiter ce type de réponse également.

Archive Cutoff

   Un répondeur OCSP peut choisir de retenir les informations de révocation au-delà de l'expiration du certificat. La date obtenue en soustrayant cet intervalle de rétention de producedAt dans une réponse est définie comme la date "archive cutoff" du certificat.

   Les applications qui utilisent OCSP utilisent la date d'archive cutoff pour contribuer à une preuve qu'une signature numérique était ( ou n'était pas ) fiable à la date à laquelle elle a été produite même si sa signature a expiré depuis longtemps.

Les serveurs OCSP qui fournissent le support pour un tel historique devraient inclure l'extension Archive cutoff dans les réponses. Si inclus, cette valeur devrait être fournie comme extension singleExtensions idenitifié par id-pkix-ocsp-archive-cutoff et de syntaxe GeneralizedTime.
id-pkix-ocsp-archive-cutoff OBJECT IDENTIFIER ::= {id-pkix-ocsp 6}

ArchiveCutoff ::= GeneralizedTime

   Pour illustrer, si un serveur opère avec une stratégie de rétention de 7 ans et le statut a été produit au temp t1, alors la valeur ArchiveCutoff dans la réponse sera ( t1 -7 ans ).

Extensions d'entrée CRL

Toutes les extensions spécifiées comme extensions d'entrée de CRL sont également supportés comme singleExtensions.

Service Locator

Un serveur OCSP peut être opéré dans un mode par lequel le serveur reçoit une demande et la route vers le serveur OCSP qui est connu pour avoir autorité pour le certificat identifié. L'extension de demande serviceLocator est définie dans ce but. Cette extension est inclue comme singleRequestExtensions dans le demandes
id-pkix-ocsp-service-locator OBJECT IDENTIFIER ::= {id-pkix-ocsp 7}

ServiceLocator ::= SEQUENCE {
    issuer Name,
    locator AuthorityInfoAccessSyntax OPTIONAL }

   Les valeurs pour ces champs sont obtenus depuis leur champs correspondants dans le certificat du sujet.

Algorithmes de signature préférés

   Vu que les algorithmes autre que ceux qui sont mandatoire sont permis, et vu qu'un client n'a pas de mécanisme pour indiquer ses préférences d'algorithme, il y a toujours un risque qu'un serveur choisisse un algorithme non obligatoire pour générer une réponse que le client ne supporte pas.

   Bien qu'un répondeur OCSP peut appliquer des règles pour la sélection d'algorithme, par exemple, en utilisant l'algorithme de signature employé par la CA pour signer les CRL et certificats, de telles règles peut échouer dans des situations communes:

- L'algorithme utilisé pour signer les CRL et les certificats ne peuvent pas être consistent avec la paire de clé utilisée par le répondeur OCSP pour signer les réponses.
- Une demande pour un certificat inconnu ne fournis pas de base pour qu'un répondeur sélectionne parmis plusieurs algorithmes.

   Le dernier critère ne peut pas être résolu via les information disponible en utilisant le protocole rfc2560 sans modifier le protocole.

   De plus, un répondeur OCSP peut souhaiter employer des algorithmes de signature différents de celui utilisé par la CA pour signer les certificats et les CRL pour 2 raisons:

- Le répondeur peut employer un algorithme qui est moins gourmand en calcul que pour la signature des certificats.
- Une implémentation peut souhaiter se prémunir de la possibilité d'un algorithme de signature compromis en employant 2 algorithmes de signature séparés.

   Cette section décrit une extension qui permet à un client d'indiquer le jeu d'argorithmes de signature préféré, et les règles pour la sélection de l'algorithme de signature qui maximise la probabilité de succès dans le cas où aucun algorithme préféré n'est spécifié.

Syntaxe d'extension

Un client peut déclarer un jeu d'algorithmes préféré dans une demande en incluant une extension d'algorithme de signature préféré dans requestExtensions de OCSPRequest:
id-pkix-ocsp-pref-sig-algs OBJECT IDENTIFIER ::= { id-pkix-ocsp 8 }

PreferredSignatureAlgorithms ::= SEQUENCE OF PreferredSignatureAlgorithm

PreferredSignatureAlgorithm ::= SEQUENCE {
    sigIdentifier AlgorithmIdentifier,
    pubKeyAlgIdentifier SMIMECapability OPTIONAL
}

   La syntaxe de AlgorithmIdentifier est définis dans la rfc5280. La syntaxe de SMIMECapability est définie dans la rfc5751.

   sigIdentifier spécifie l'algorithme de signature que le client préfère, par exemple, algorithm=ecdsa-with-sha256. Les paramètres sont absent pour la plupart des algorithmes de signatures communs.

   pubKeyAlgIdentifier spécifie l'identifiat d'algorithme de clé publique que le client préfère dans le certificat du serveur utilisé pour valider la réponse OCSP, par exemple, algorithm=id-ecPublicKey et parameters=secp256r1.

   pubKeyAlgIdentifier est optionnel et fournis un moyen de spécifier les paramètres nécessaires pour distinguer entre les différents usages d'un algorithme particulier, par exemple, il peut être utilisé par le client pour spécifier que courbe il supporte pour un algorithme à courbe elliptique.

   Le client doit supporter chacun des algorithmes de signature préférés spécifiés, et le client doit spécifier les algorithmes dans l'ordre de préférence.

Sélection de l'algorithme de signature

La rfc2560 ne spécifie pas de mécanisme pour décider de l'algorithme de signature à utiliser dans une réponse OCSP. Cela ne fournis pas de niveau suffisant de certitude quant à l'algorithme choisi pour faciliter l'interopérabilité.

Réponse dynamique

Un répondeur peut maximiser le potentiel pour assurer l'interopérabilité en sélectionnant un algorithme de signature supporté en utilisant l'ordre de préférence suivant. tant que l'algorithme sélectionné rencontre toutes les exigences de sécurité du répondeur OCSP, où le premier mécanisme sélectionné à la plus haute précédence:

1. Sélectionne un algorithme spécifié comme algorithme de signature préféré dans le demande du client
2. Sélectionne l'algorithme de signature utilisé pour signer une liste de révocation de certificat émis par l'émetteur du certificat en fournissant les informations de statut pour le certificat spécifié par CertID
3. Sélectionne l'algorithme de signature utilisé pour signer le OCSPRequest
4. Sélectionne un algorithme de signature qui a été déclaré comme algorithme de signature par défaut pour le service de signature en utilisant un mécanisme externe.
5. Sélectionne un algorithme obligatoire ou recommandé spécifié pour la version d'OCSP utilisé.

Un répondeur devrait toujours appliquer le mécanisme de sélection ayant le plus faible numéro qui résulte dans la sélection d'un algorithme connu et supporté qui répond aux critères du répondeur pour la force de l'algorithme cryptographique.

Réponse statique

Dans un but d'efficacité, un répondeur OCSP est autorisé à générer des réponses statiques à l'avance. Le cas ne permet pas au répondeur d'utiliser la demande du client durant la génération de la réponse; cependant, le répondeur devrait utiliser les données de la demande du client durant la sélection de la réponse pré-générée à retourner. Les répondeurs peuvent utiliser les demandes historiques du client comme partie de la décision de l'algorithme à utiliser pour signer les réponses pré-générées.

Définition de révocation étendue

   Cette extension indique que le répondeur supporte la définition étendue du statut "révoqué" pour inclure également les certificats non-émis. Un des buts premier est de permettre des audits pour déterminer le type d'opération du répondeur. Les clients n'ont pas à regarder cette extension pour déterminer le statut des certificats dans la réponse.

   Cette extension doit être incluse dans la réponse OCSP quand cette réponse contient un statut "révoqué" pour un certificat non-émis. Cette extension peut être présente dans d'autres réponses pour signaler que le répondeur implémente la définition révoqué étendue. Quand inclus, cette extension doit être placée dans responseExtensions, et ne doit pas apparaître dans singleExtensions.

Cette extension est identifiée par l'identifiant d'objet id-pkix-ocsp-extended-revoke
id-pkix-ocsp-extended-revoke OBJECT IDENTIFIER ::= {id-pkix-ocsp 9}

   La valeur de l'extension doit être null. Cette extension ne doit pas être marquée critique.

Considérations de sécurité

   Pour que ce service soit effectif, les systèmes utilisant les certificat doivent se connecter au fournisseur de service de statut du certificat. Dans le cas où une telle connexion ne peut être obtenue, ces systèmes peuvent implémenter le traitement de CRL.

   Une vulnérabilité à un DOS est évident. La production d'une signature cryptographique affecte significativement le temps de cycle de génération de signature. Les erreurs de réponses non-signées ouvrent le protocole à une autre attaque DOS, où l'attaquant envoie des réponses non-signées.

   L'utilisation de réponses pré-calculées permet de rejouer des attaques dans lequel une ancienne bonne réponse est rejouée avant sa date d'expiration mais après que le certificat ait été révoqué. Les déploiements d'OCSP devraient évaluer le bénéfice des réponses pré-calculées avec la probabilité d'une attaque replay et le coùt associé avec son exécution.

   Les requêtes ne contiennent pas le répondeurs auquels ils sont redirigés. Cela permet à un attaquant pour rejouer une demande à d'autres répondeurs OCSP

   La dépendance à l'égard de la mise en cache HTTP dans certains scénarios peut résulter en des résultats inattendus si les serveurs intermédiaires sont incorrectement configurés ou ont des fautes de gestion de cache. Les implémenteurs doivent s'assurer que les mécanismes de cache HTTP sont pris en compte en déployant OCSP sur HTTP.

   En répondant avec un état 'revoked' à un certificat qui n'a jamais été émis peut permettre à une personne d'obtenir une réponse de révocation pour une certificat qui n'a jamais été émis, mais qui sera bientôt émis, si le numéro de certificat du certificat qui sera émis peut être prédis ou deviné par le demandeur. Une telle prédiction est facile pour une CA qui émet des certificats en utilisant l'assignement de numéro de série séquentiel. Ce risque est géré dans la spécification en exigant des implémentations conformes à l'utilisation du code de raison certificateHold, qui évite de révoquer des numéros de série. Pour les CA qui supportent les réponses "revoked" pour les certificats non-émis, une manière d'éviter ce problème est d'assigner des numéros de série aléatoirement avec une forte entropy.

Algorithmes de signature préféré

Le mécanisme utilisé pour choisir l'algorithme de signature de réponse doit être considéré comme suffisamment sécure contre les attaques pas cryptanalyse pour l'application prévue.

Dans beaucoup d'applications, l'algorithme de signature au moins aussi sécurisé que l'algorithme utilisé pour signer le certificat original est suffisant. Cependant, ce critère ne peut pas être retenu dans des applications d'archivage à long terme, dans lequel le statut d'un certificat est demandé pour date dans le passé, longtemps après que l'algorithme de signature a cessé d'être considéré comme sûr.

Utilisation d'algorithmes non sécure

   Il n'est pas toujours possible pour un répondeur de générer une réponse que le client s'attend à comprendre et qui correspond aux standards contemporains pour la sécurité cryptographique. Dans de tels cas, un opération de répondeur OCSP doit jouer entre le risque d'employer une solution de sécurité compromise et le coùt d'une mise à jours, incluant le risque que l'alternative choisis par les utilisateurs finaux offre moins de sécurité ou aucune sécurité.

   Dans les applications d'archivage, il est possible qu'un répondeur OCSP ait une demande de répondre de la validité d'un certificat dans le passé. Un tel certificat peut employer une méthode de signature qui n'est plus considéré comme sécurisée. Dans de telles circonstances, le répondeur ne doit pas générer une signature en utilisant un mécanisme de signature qui n'est pas considérée comme suffisamment sûre.

   Un client doit accepter un algorithme de signature dans une réponse qui est spécifiée comme un algorithme de signature préféré dans la demande. Un client ne doit pas spécifier d'algorithme de signature préféré qu'il ne supporte pas ou ne considère pas comme suffisamment sûre.

Attaques MITM

Le mécanisme pour supporter l'indication client des algorithmes de signature préférés n'est pas protégé contre les attaques par dégradation MITM. Cette contrainte n'est pas considéré comme un problème de sécurité significatif, vu que le répondeur OCSP ne doit pas signer les réponses en utilisant des algorithmes faibles même si demandé par le client. En plus, le client peut rejeter les réponses qui ne rencontrent pas ses critères.

Attaques DOS

Les mécanismes d'algorithme définis dans ce document introduit une surface d'attaque légèrement meilleur pour les attaques DOS où la demande client est altérée pour exiger des algorithmes qui ne sont pas supportés par le serveur. Les considérations DOS discutées dans la rfc4732 sont pris en compte pour ce document.

Appendice A. OCSP sur HTTP

Cette section décrit le formattage qui sera fait à la demande et la réponse pour supporter HTTP.

Demande

   Les demandes OCSP basées sur HTTP peut utiliser soit la méthode GET soit POST pour envoyer leurs demandes. Pour permettre le caching HTTP, des petites demandes (qui après encodage font moins de 255 octets) peut être envoyés en utilisant la méthode GET. Si le caching HTTP n'est pas important ou si la demande est supérieur à 255 octets, la demande devrait être envoyé via POST. Où la confidentialité est une exigence, les transactions OCSP en utilisant HTTP peut être protégés en utilisant SSL/TLS ou d'autre protocoles.

Une demande OCSP en utilisant la méthode GET est construite comme suit:
GET {url}/{url-encoding of base-64 encoding of the DER encoding of the OCSPRequest}

   Où {url} peut être dérivé de la valeur de l'extension d'information d'accès à l'autorité dans le certificat à vérifier, ou d'autres configurations locales du client OCSP.

   Une demande OCSP en utilisant la méthode POST est construite comme suit: le header Content-Type a la valeur "application/ocsp-request", alors que le body du message est une valeur binaire de l'encodage DER du OCSPRequest.

Réponse

Une réponse OCSP basé sur HTTP est composée des en-tête HTTP appropriés, suivis par la valeur binaire de l'encodé DER du OCSPResponse. Le header Content-Type a la valeur "application/ocsp-response". Le header Content-Length devrait spécifier la longueur de la réponse. D'autres en-tête HTTP peut être présents et peuvent être ignorés s'ils ne sont pas compris par le demandeur.

09 mai 2016

rfc7299

OID pour le groupe de travail PKIX

Quand le groupe de travail PKIX a démarré, un arc OID a été alloué par l'IANA. Ce document décris les identifiants assignés dans cet arc, et établis les stratégies d'allocation pour tout assignement dans cet arc. l'arc OID pkix est :
id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) }

Arcs OID subordonnés

25 arcs OID subordonnés ont été utilisé, de 0 à 23 et 48. De plus, il y a 7 arcs subordonnée. Ils ont été assignés comme suit:

Identifiants de module id-mod OBJECT IDENTIFIER ::= { id-pkix 0 }
Extensions de certificat PKIX id-pe OBJECT IDENTIFIER ::= { id-pkix 1 }
Type de qualifiant de stratégie id-qt OBJECT IDENTIFIER ::= { id-pkix 2 }
Identifiant de clé étendue id-kp OBJECT IDENTIFIER ::= { id-pkix 3 }
Type d'information CMP id-it OBJECT IDENTIFIER ::= { id-pkix 4 }
Enregistrement CRMF id-pkip OBJECT IDENTIFIER ::= { id-pkix 5 }
Contrôles d'enregistrement CRMF id-regCtrl OBJECT IDENTIFIER ::= { id-pkix 5 1 }
Informations d'enregistrement CRMF id-regInfo OBJECT IDENTIFIER ::= { id-pkix 5 2 }
Algorithmes id-alg OBJECT IDENTIFIER ::= { id-pkix 6 }
Contrôles CMC id-cmc OBJECT IDENTIFIER ::= { id-pkix 7 }
Requêtes et réponses CMC GLA id-cmc-glaRR OBJECT IDENTIFIER ::= { id-pkix 7 99 }
Autres formes de nom id-on OBJECT IDENTIFIER ::= { id-pkix 8 }
Attribut personnel id-pda OBJECT IDENTIFIER ::= { id-pkix 9 }
Attribut de certificat d'attributs id-aca OBJECT IDENTIFIER ::= { id-pkix 10 }
Déclarations de certificat qualifié id-qcs OBJECT IDENTIFIER ::= { id-pkix 11 }
Types de contenu CMC id-cct OBJECT IDENTIFIER ::= { id-pkix 12 }
OID pour test uniquement id-TEST OBJECT IDENTIFIER ::= { id-pkix 13 }
Stratégies de certificat id-cp OBJECT IDENTIFIER ::= { id-pkix 14 }
Type d'erreur CMC id-cet OBJECT IDENTIFIER ::= { id-pkix 15 }
Types d'information de révocation id-ri OBJECT IDENTIFIER ::= { id-pkix 16 }
Types de retour SCVP id-swb OBJECT IDENTIFIER ::= { id-pkix 18 }
Stratégies de validation SCVP id-svp OBJECT IDENTIFIER ::= { id-pkix 19 }
Erreurs de stratégie de validation de nom SCVP id-nvae OBJECT IDENTIFIER ::= { id-pkix 19 2 }
Erreurs de stratégie de validation de base SCVP id-bvae OBJECT IDENTIFIER ::= { id-pkix 19 3 }
Erreurs de stratégie de validation de nom distinct SCVP id-dnvae OBJECT IDENTIFIER ::= { id-pkix 19 4 }
Autres identifiants logotype id-logo OBJECT IDENTIFIER ::= { id-pkix 20 }
Langages de stratégie de certificat proxy id-ppl OBJECT IDENTIFIER ::= { id-pkix 21 }
Rêgles de correspondance id-mr OBJECT IDENTIFIER ::= { id-pkix 22 }
Sémantiques d'identifiant de clé du sujet id-skis OBJECT IDENTIFIER ::= { id-pkix 23 }
Descripteurs d'accès id-ad OBJECT IDENTIFIER ::= { id-pkix 48 }
OCSP id-pkix-ocsp OBJECT IDENTIFIER ::= { id-pkix 48 1 }

L'IANA a mis à jours une table d'enregistrement et créé 33 tables additionnelles. Les mises à jours dans les nouvelles tables sont faites en accord avec la spécification définie dans la rfc5226.

1.3.6.1.5.5.7

Decimal Description References
------- ------------------------------------ ----------
0_______Module identifiers_____________________[RFC7299]
1_______PKIX certificate extensions____________[RFC7299]
2_______Policy qualifier types_________________[RFC7299]
3_______Extended key purpose identifiers_______[RFC7299]
4_______CMP information types__________________[RFC7299]
5_______CRMF registration______________________[RFC7299]
6_______Algorithms_____________________________[RFC7299]
7_______CMC controls___________________________[RFC7299]
8_______Other name forms_______________________[RFC7299]
9_______Personal data attribute________________[RFC7299]
10______Attribute certificate attributes_______[RFC7299]
11______Qualified certificate statements_______[RFC7299]
12______CMC content types______________________[RFC7299]
13______OIDs for TESTING ONLY__________________[RFC7299]
14______Certificate policies___________________[RFC7299]
15______CMC error types________________________[RFC7299]
16______Revocation information types___________[RFC7299]
17______SCVP check type________________________[RFC7299]
18______SCVP want back types___________________[RFC7299]
19______SCVP validation policies_______________[RFC7299]
20______Other logotype identifiers_____________[RFC7299]
21______Proxy certificate policy languages_____[RFC7299]
22______Matching rules_________________________[RFC7299]
23______Subject key identifier semantics_______[RFC7299]
48______Access descriptors_____________________[RFC7299]

1.3.6.1.5.5.7.0

Decimal Description References
------- ------------------------------- ---------------------
1________id-pkix1-explicit-88_____________[RFC2459]
2________id-pkix1-implicit-88_____________[RFC2459]
3________id-pkix1-explicit-93_____________[RFC2459]
4________id-pkix1-implicit-93_____________[RFC2459]
5________id-mod-crmf______________________[RFC2511]
6________id-mod-cmc_______________________[RFC2797]
7________id-mod-kea-profile-88____________[RFC2528]
8________id-mod-kea-profile-93____________[RFC2528]
9________id-mod-cmp_______________________[RFC2510]
10_______id-mod-qualified-cert-88_________[RFC3039]
11_______id-mod-qualified-cert-93_________[RFC3039]
12_______id-mod-attribute-cert____________[RFC3281]
13_______id-mod-tsp_______________________[RFC3161]
14_______id-mod-ocsp______________________[RFC3029]
15_______id-mod-dvcs______________________[RFC3029]
16_______id-mod-cmp2000___________________[RFC4210]
17_______id-mod-pkix1-algorithms__________[RFC3279]
18_______id-mod-pkix1-explicit____________[RFC3280]
19_______id-mod-pkix1-implicit____________[RFC3280]
20_______id-mod-user-group________________Reserved and Obsolete
21_______id-mod-scvp______________________[RFC5055]
22_______id-mod-logotype__________________[RFC3709]
23_______id-mod-cmc2002___________________[RFC5272]
24_______id-mod-wlan-extns________________[RFC3770]
25_______id-mod-proxy-cert-extns__________[RFC3820]
26_______id-mod-ac-policies_______________[RFC4476]
27_______id-mod-warranty-extn_____________[RFC4059]
28_______id-mod-perm-id-88________________[RFC4043]
29_______id-mod-perm-id-93________________[RFC4043]
30_______id-mod-ip-addr-and-as-ident______[RFC3779]
31_______id-mod-qualified-cert____________[RFC3739]
32_______id-mod-crmf2003__________________Reserved and Obsolete
33_______id-mod-pkix1-rsa-pkalgs__________[RFC4055]
34_______id-mod-cert-bundle_______________[RFC4306]
35_______id-mod-qualified-cert-97_________[RFC3739]
36_______id-mod-crmf2005__________________[RFC4210]
37_______id-mod-wlan-extns2005____________[RFC4334]
38_______id-mod-sim2005___________________[RFC4683]
39_______id-mod-dns-srv-name-88___________[RFC4985]
40_______id-mod-dns-srv-name-93___________[RFC4985]
41_______id-mod-cmsContentConstr-88_______[RFC6010]
42_______id-mod-cmsContentConstr-93_______[RFC6010]
43_______id-mod-pkixCommon________________Reserved and Obsolete
44_______id-mod-pkixOtherCerts____________[RFC5697]
45_______id-mod-pkix1-algorithms2008______[RFC5480]
46_______id-mod-clearanceConstraints______[RFC5913]
47_______id-mod-attribute-cert-02_________[RFC5912]
48_______id-mod-ocsp-02___________________[RFC5912]
49_______id-mod-v1AttrCert-02_____________[RFC5912]
50_______id-mod-cmp2000-02________________[RFC5912]
51_______id-mod-pkix1-explicit-02_________[RFC5912]
52_______id-mod-scvp-02___________________[RFC5912]
53_______id-mod-cmc2002-02________________[RFC5912]
54_______id-mod-pkix1-rsa-pkalgs-02_______[RFC5912]
55_______id-mod-crmf2005-02_______________[RFC5912]
56_______id-mod-pkix1-algorithms2008-02___[RFC5912]
57_______id-mod-pkixCommon-02_____________[RFC5912]
58_______id-mod-algorithmInformation-02___[RFC5912]
59_______id-mod-pkix1-implicit-02_________[RFC5912]
60_______id-mod-pkix1-x400address-02______[RFC5912]
61_______id-mod-attribute-cert-v2_________[RFC5755]
62_______id-mod-sip-domain-extns2007______[RFC5924]
63_______id-mod-cms-otherRIs-2009-88______[RFC5940]
64_______id-mod-cms-otherRIs-2009-93______[RFC5940]
65_______id-mod-ecprivatekey______________[RFC5915]
66_______id-mod-ocsp-agility-2009-93______[RFC6277]
67_______id-mod-ocsp-agility-2009-88______[RFC6277]
68_______id-mod-logotype-certimage________[RFC6170]
69_______id-mod-pkcs10-2009_______________[RFC5912]
70_______id-mod-dns-resource-record_______[Abley]
71_______id-mod-send-cert-extns___________[RFC6494]
72_______id-mod-ip-addr-and-as-ident-2____[RFC6268]
73_______id-mod-wlan-extns-2______________[RFC6268]
74_______id-mod-hmac______________________[RFC6268]
75_______id-mod-enrollMsgSyntax-2011-88___[RFC6402] [Err3860]
76_______id-mod-enrollMsgSyntax-2011-08___[RFC6402]
77_______id-mod-pubKeySMIMECaps-88________[RFC6664]
78_______id-mod-pubKeySMIMECaps-08________[RFC6664]
79_______id-mod-dhSign-2012-88____________[RFC6955]
80_______id-mod-dhSign-2012-08____________[RFC6955]
81_______id-mod-ocsp-2013-88______________[RFC6960]
82_______id-mod-ocsp-2013-08______________[RFC6960]
83_______id-mod-TEST-certPolicies_________[RFC7229]
84_______id-mod-bgpsec-eku________________[BGPSEC]

1.3.6.1.5.5.7.1

Decimal Description References
------- ------------------------------ ---------------------
_______1________id-pe-authorityInfoAccess_______[RFC2459]
_______2________id-pe-biometricInfo_____________[RFC3039]
_______3________id-pe-qcStatements______________[RFC3039]
_______4________id-pe-ac-auditIdentity__________[RFC3281]
_______5________id-pe-ac-targeting______________Reserved and Obsolete
_______6________id-pe-aaControls________________[RFC3281]
_______7________id-pe-ipAddrBlocks______________[RFC3779]
_______8________id-pe-autonomousSysIds__________[RFC3779]
_______9________id-pe-sbgp-routerIdentifier_____Reserved and Obsolete
_______10_______id-pe-ac-proxying_______________[RFC3281]
_______11_______id-pe-subjectInfoAccess_________[RFC3280]
_______12_______id-pe-logotype__________________[RFC3709]
_______13_______id-pe-wlanSSID__________________[RFC4334]
_______14_______id-pe-proxyCertInfo_____________[RFC3820]
_______15_______id-pe-acPolicies________________[RFC4476]
_______16_______id-pe-warranty__________________[RFC4059]
_______17_______id-pe-sim_______________________Reserved and Obsolete
_______18_______id-pe-cmsContentConstraints_____[RFC6010]
_______19_______id-pe-otherCerts________________[RFC5697]
_______20_______id-pe-wrappedApexContinKey______[RFC5934]
_______21_______id-pe-clearanceConstraints______[RFC5913]
_______22_______id-pe-skiSemantics______________Reserved and Obsolete
_______23_______id-pe-nsa_______________________[RFC7169]

1.3.6.1.5.5.7.2

Decimal Description References
------- ------------------------------ ---------------------
1________id-qt-cps_______________________[RFC2459]
2________id-qt-unotice___________________[RFC2459]
3________id-qt-textNotice________________Reserved and Obsolete
4________id-qt-acps______________________[RFC4476]
5________id-qt-acunotice_________________[RFC4476]

1.3.6.1.5.5.7.3

Decimal Description References
------- ------------------------------ ---------------------
1________id-kp-serverAuth________________[RFC2459]
2________id-kp-clientAuth________________[RFC2459]
3________id-kp-codeSigning_______________[RFC2459]
4________id-kp-emailProtection___________[RFC2459]
5________id-kp-ipsecEndSystem____________Reserved and Obsolete
6________id-kp-ipsecTunnel_______________Reserved and Obsolete
7________id-kp-ipsecUser_________________Reserved and Obsolete
8________id-kp-timeStamping______________[RFC2459]
9________id-kp-OCSPSigning_______________[RFC2560]
10_______id-kp-dvcs______________________[RFC3029]
11_______id-kp-sbgpCertAAServerAuth______Reserved and Obsolete
12_______id-kp-scvp-responder____________Reserved and Obsolete
13_______id-kp-eapOverPPP________________[RFC4334]
14_______id-kp-eapOverLAN________________[RFC4334]
15_______id-kp-scvpServer________________[RFC5055]
16_______id-kp-scvpClient________________[RFC5055]
17_______id-kp-ipsecIKE__________________[RFC4945]
18_______id-kp-capwapAC__________________[RFC5415]
19_______id-kp-capwapWTP_________________[RFC5415]
20_______id-kp-sipDomain_________________[RFC5924]
21_______id-kp-secureShellClient_________[RFC6187]
22_______id-kp-secureShellServer_________[RFC6187]
23_______id-kp-sendRouter________________[RFC6494]
24_______id-kp-sendProxiedRouter_________[RFC6494]
25_______id-kp-sendOwner_________________[RFC6494]
26_______id-kp-sendProxiedOwner__________[RFC6494]
27_______id-kp-cmcCA_____________________[RFC6402]
28_______id-kp-cmcRA_____________________[RFC6402]
29_______id-kp-cmcArchive________________[RFC6402]
30_______id-kp-bgpsec-router_____________[BGPSEC]

1.3.6.1.5.5.7.4

Decimal Description References
------- ------------------------------ ---------------------
1________id-it-caProtEncCert_____________[RFC2510]
2________id-it-signKeyPairTypes__________[RFC2510]
3________id-it-encKeyPairTypes___________[RFC2510]
4________id-it-preferredSymmAlg__________[RFC2510]
5________id-it-caKeyUpdateInfo___________[RFC2510]
6________id-it-currentCRL________________[RFC2510]
7________id-it-unsupportedOIDs___________[RFC4210]
8________id-it-subscriptionRequest_______Reserved and Obsolete
9________id-it-subscriptionResponse______Reserved and Obsolete
10_______id-it-keyPairParamReq___________[RFC4210]
11_______id-it-keyPairParamRep___________[RFC4210]
12_______id-it-revPassphrase_____________[RFC4210]
13_______id-it-implicitConfirm___________[RFC4210]
14_______id-it-confirmWaitTime___________[RFC4210]
15_______id-it-origPKIMessage____________[RFC4210]
16_______id-it-suppLangTags______________[RFC4210]

1.3.6.1.5.5.7.5

Decimal Description References
------- ------------------------------ ---------------------
1________id-regCtrl______________________[RFC2511]
2________id-regInfo______________________[RFC2511]
3________id-regEPEPSI____________________[RFC4683]

1.3.6.1.5.5.7.5.1

Decimal Description References
------- ------------------------------ ---------------------
1________id-regCtrl-regToken_____________[RFC2511]
2________id-regCtrl-authenticator________[RFC2511]
3________id-regCtrl-pkiPublicationInfo___[RFC2511]
4________id-regCtrl-pkiArchiveOptions____[RFC2511]
5________id-regCtrl-oldCertID____________[RFC2511]
6________id-regCtrl-protocolEncrKey______[RFC2511]
7________id-regCtrl-altCertTemplate______[RFC4210]
8________id-regCtrl-wtlsTemplate_________Reserved and Obsolete
9________id-regCtrl-regTokenUTF8_________Reserved and Obsolete
10_______id-regCtrl-authenticatorUTF8____Reserved and Obsolete

1.3.6.1.5.5.7.5.2

Decimal Description References
------- ------------------------------ ---------------------
1________id-regInfo-utf8Pairs____________[RFC2511]
2________id-regInfo-certReq______________[RFC2511]

1.3.6.1.5.5.7.6

Decimal Description References
------- ------------------------------ ---------------------
1________id-alg-des40________________________________Reserved and Obsolete
2________id-alg-noSignature__________________________[RFC2797]
3________id-alg-dh-sig-hmac-sha1_____________________[RFC2875]
4________id-alg-dhPop-sha1___________________________[RFC2875]
5________id-alg-dhPop-sha224_________________________[RFC6955]
6________id-alg-dhPop-sha256_________________________[RFC6955]
7________id-alg-dhPop-sha384_________________________[RFC6955]
8________id-alg-dhPop-sha512_________________________[RFC6955]
15_______id-alg-dhPop-static-sha224-hmac-sha224______[RFC6955]
16_______id-alg-dhPop-static-sha256-hmac-sha256______[RFC6955]
17_______id-alg-dhPop-static-sha384-hmac-sha384______[RFC6955]
18_______id-alg-dhPop-static-sha512-hmac-sha512______[RFC6955]
25_______id-alg-ecdhPop-static-sha224-hmac-sha224____[RFC6955]
26_______id-alg-ecdhPop-static-sha256-hmac-sha256____[RFC6955]
27_______id-alg-ecdhPop-static-sha384-hmac-sha384____[RFC6955]
28_______id-alg-ecdhPop-static-sha512-hmac-sha512____[RFC6955]

Note: id-alg-dhPop-sha1 est également appelé id-alg-dh-pop.
Note: id-alg-dh-sig-hmac-sha1 est également appelé id-alg-dhPop-static-sha1-hmac-sha1 et id-dhPop-static-hmac-sha1.

1.3.6.1.5.5.7.7

Decimal Description References
------- ------------------------------ ---------------------
1________id-cmc-statusInfo_______________[RFC2797]
2________id-cmc-identification___________[RFC2797]
3________id-cmc-identityProof____________[RFC2797]
4________id-cmc-dataReturn_______________[RFC2797]
5________id-cmc-transactionId____________[RFC2797]
6________id-cmc-senderNonce______________[RFC2797]
7________id-cmc-recipientNonce___________[RFC2797]
8________id-cmc-addExtensions____________[RFC2797]
9________id-cmc-encryptedPOP_____________[RFC2797]
10_______id-cmc-decryptedPOP_____________[RFC2797]
11_______id-cmc-lraPOPWitness____________[RFC2797]
15_______id-cmc-getCert__________________[RFC2797]
16_______id-cmc-getCRL___________________[RFC2797]
17_______id-cmc-revokeRequest____________[RFC2797]
18_______id-cmc-regInfo__________________[RFC2797]
19_______id-cmc-responseInfo_____________[RFC2797]
21_______id-cmc-queryPending_____________[RFC2797]
22_______id-cmc-popLinkRandom____________[RFC2797]
23_______id-cmc-popLinkWitness___________[RFC2797]
24_______id-cmc-confirmCertAcceptance____[RFC2797]
25_______id-cmc-statusInfoV2_____________[RFC5272]
26_______id-cmc-trustedAnchors___________[RFC5272]
27_______id-cmc-authData_________________[RFC5272]
28_______id-cmc-batchRequests____________[RFC5272]
29_______id-cmc-batchResponses___________[RFC5272]
30_______id-cmc-publishCert______________[RFC5272]
31_______id-cmc-modCertTemplate__________[RFC5272]
32_______id-cmc-controlProcessed_________[RFC5272]
33_______id-cmc-popLinkWitnessV2_________[RFC5272]
34_______id-cmc-identityProofV2__________[RFC5272]
35_______id-cmc-raIdentityWitness________[RFC6402]
36_______id-cmc-changeSubjectName________[RFC6402]
37_______id-cmc-responseBody_____________[RFC6402]
99_______id-cmc-glaRR____________________[RFC5275]

Note: id-cmc-statusInfo est également appelé id-cmc-cMCStatusInfo.

1.3.6.1.5.5.7.7.99

Decimal Description References
------- ------------------------------ ---------------------
1________id-cmc-gla-skdAlgRequest________[RFC5275]
2________id-cmc-gla-skdAlgResponse_______[RFC5275]

1.3.6.1.5.5.7.8

Decimal Description References
------- ------------------------------ ---------------------
1________id-on-personalData______________Reserved and Obsolete
2________id-on-userGroup_________________Reserved and Obsolete
3________id-on-permanentIdentifier_______[RFC4043]
4________id-on-hardwareModuleName________[RFC4108]
5________id-on-xmppAddr__________________[RFC3920]
6________id-on-SIM_______________________[RFC4683]
7________id-on-dnsSRV____________________[RFC4985]

1.3.6.1.5.5.7.9

Decimal Description References
------- ------------------------------ ---------------------
1________id-pda-dateOfBirth______________[RFC3039]
2________id-pda-placeOfBirth_____________[RFC3039]
3________id-pda-gender___________________[RFC3039]
4________id-pda-countryOfCitizenship_____[RFC3039]
5________id-pda-countryOfResidence_______[RFC3039]

1.3.6.1.5.5.7.10

Decimal Description References
------- ------------------------------ ---------------------
1________id-aca-authenticationInfo_______[RFC3281]
2________id-aca-accessIdentity___________[RFC3281]
3________id-aca-chargingIdentity_________[RFC3281]
4________id-aca-group____________________[RFC3281]
5________id-aca-role_____________________Reserved and Obsolete
6________id-aca-encAttrs_________________[RFC3281]
7________id-aca-wlanSSID_________________[RFC4334]

1.3.6.1.5.5.7.11

Decimal Description References
------- ------------------------------ ---------------------
1________id-qcs-pkixQCSyntax-v1__________[RFC3039]
2________id-qcs-pkixQCSyntax-v2__________[RFC3739]

1.3.6.1.5.5.7.12

Decimal Description References
------- ------------------------------ ---------------------
1________id-cct-crs______________________Reserved and Obsolete
2________id-cct-PKIData__________________[RFC2797]
3________id-cct-PKIResponse______________[RFC2797]

1.3.6.1.5.5.7.13

Decimal Description References
------- ------------------------------ ---------------------
1________id-TEST-certPolicyOne___________[RFC7229]
2________id-TEST-certPolicyTwo___________[RFC7229]
3________id-TEST-certPolicyThree_________[RFC7229]
4________id-TEST-certPolicyFour__________[RFC7229]
5________id-TEST-certPolicyFive__________[RFC7229]
6________id-TEST-certPolicySix___________[RFC7229]
7________id-TEST-certPolicySeven_________[RFC7229]
8________id-TEST-certPolicyEight_________[RFC7229]

1.3.6.1.5.5.7.14

Decimal Description References
------- ------------------------------ ---------------------
1________id-cp-sbgpCertificatePolicy_____Reserved and Obsolete
2________id-cp-ipAddr-asNumber___________[RFC6484]

1.3.6.1.5.5.7.15

Decimal Description References
------- ------------------------------ ---------------------
1________id-cet-skdFailInfo______________[RFC5275]

1.3.6.1.5.5.7.16

Decimal Description References
------- ------------------------------ ---------------------
1________id-ri-crl_______________________[RFC5940]
2________id-ri-ocsp-response_____________[RFC5940]
3________id-ri-delta-crl_________________[RFC5940]
4________id-ri-scvp______________________[RFC5940]

1.3.6.1.5.5.7.17

Decimal Description References
------- ------------------------------------------------------ ---------------------
1________id-stc-build-pkc-path___________________________________[RFC5055]
2________id-stc-build-valid-pkc-path_____________________________[RFC5055]
3________id-stc-build-status-checked-pkc-path____________________[RFC5055]
4________id-stc-build-aa-path____________________________________[RFC5055]
5________id-stc-build-valid-aa-path______________________________[RFC5055]
6________id-stc-build-status-checked-aa-path_____________________[RFC5055]
7________id-stc-status-check-ac-and-build-status-checked-aa-path_[RFC5055]

1.3.6.1.5.5.7.18

Decimal Description References
------- ------------------------------ ---------------------
1________id-swb-pkc-best-cert-path_______[RFC5055]
2________id-swb-pkc-revocation-info______[RFC5055]
3________id-swb-pkc-cert-status__________Reserved and Obsolete
4________id-swb-pkc-public-key-info______[RFC5055]
5________id-swb-aa-cert-path_____________[RFC5055]
6________id-swb-aa-revocation-info_______[RFC5055]
7________id-swb-ac-revocation-info_______[RFC5055]
8________id-swb-ac-cert-status___________Reserved and Obsolete
9________id-swb-relayed-responses________[RFC5055]
10_______id-swb-pkc-cert_________________[RFC5055]
11_______id-swb-ac-cert__________________[RFC5055]
12_______id-swb-pkc-all-cert-paths_______[RFC5055]
13_______id-swb-pkc-ee-revocation-info___[RFC5055]
14_______id-swb-pkc-CAs-revocation-info__[RFC5055]
15_______id-swb-partial-cert-path________[RFC5276]
16_______id-swb-ers-pkc-cert_____________[RFC5276]
17_______id-swb-ers-best-cert-path_______[RFC5276]
18_______id-swb-ers-partial-cert-path____[RFC5276]
19_______id-swb-ers-revocation-info______[RFC5276]
20_______id-swb-ers-all__________________[RFC5276]

1.3.6.1.5.5.7.19

Decimal Description References
------- ------------------------------ ----------
1________id-svp-defaultValPolicy_________[RFC5055]
2________id-svp-nameValAlg_______________[RFC5055]
3________id-svp-basicValAlg______________[RFC5055]
4________id-svp-dnValAlg_________________[RFC5055]

1.3.6.1.5.5.7.19.2

Decimal Description References
------- ------------------------------ ----------
1________id-nvae-name-mismatch___________[RFC5055]
2________id-nvae-no-name_________________[RFC5055]
3________id-nvae-unknown-alg_____________[RFC5055]
4________id-nvae-bad-name________________[RFC5055]
5________id-nvae-bad-name-type___________[RFC5055]
6________id-nvae-mixed-names_____________[RFC5055]

1.3.6.1.5.5.7.19.3

Decimal Description References
------- ------------------------------ ---------------------
1________id-bvae-expired_________________[RFC5055]
2________id-bvae-not-yet-valid___________[RFC5055]
3________id-bvae-wrongTrustAnchor________[RFC5055]
4________id-bvae-noValidCertPath_________[RFC5055]
5________id-bvae-revoked_________________[RFC5055]
9________id-bvae-invalidKeyPurpose_______[RFC5055]
10_______id-bvae-invalidKeyUsage_________[RFC5055]
11_______id-bvae-invalidCertPolicy_______[RFC5055]
12_______id-bvae-invalidName_____________Reserved and Obsolete
13_______id-bvae-invalidEntity___________Reserved and Obsolete
14_______id-bvae-invalidPathDepth________Reserved and Obsolete

1.3.6.1.5.5.7.20

Decimal Description Reference
------- ------------------------------ ---------
1________id-logo-loyalty_________________[RFC3709]
2________id-logo-background______________[RFC3709]
3________id-logo-certImage_______________[RFC6170]

1.3.6.1.5.5.7.21

Decimal Description Reference
------- ------------------------------ ---------
0________id-ppl-anyLanguage______________[RFC3820]
1________id-ppl-inheritAll_______________[RFC3820]
2________id-ppl-independent______________[RFC3820]

1.3.6.1.5.5.7.22

Decimal Description References
------- ------------------------------ ---------------------
1________id-mr-pkix-alphanum-ids_________Reserved and Obsolete

1.3.6.1.5.5.7.23

Pour une association ATR - type de carte:
ATR sous la forme d'une expression régulière
[tab] Texte descriptif
[tab] Texte descriptif
[tab] Texte descriptif
ligne vide

27 juin 2014

sserver

Serveur de démonstration

   sserver et sclient sont de simples progammes client/serveur de démonstration. Quand sclient se connecte à sserver, il effectue une authentification Kerberos, et le serveur retourne le principal Kerberos qui a été utilisé. Le nom de service utilisé par sserver et sclient est sample. sserver nécessite que l'entrée sample/hostname.domain.name@REALM.NAME dans le keytab. Ce keytab est généré en utilisant le programme kadmin. L'option -S permet d'utiliser un keytab différent de celui par défaut.

   Vu que sample n'a normalement pas de port définis dans /etc/services, il faut généralement ajouter:

  sample 13135/tcp

  En utilisant sclient, il faut d'abord avoir une entrée dans la base Kerberos, en utilisant kadmin, et obtenir des tickets Kerbeors avec kinit.

Exemple de réponse en utilisant sclient:
sendauth succeeded, reply is:
reply len 32, contents:
You are nlgilman@JIMI.MIT.EDU

15 juin 2017

ssh

programme de connexion distante

OPTIONS

-4 Force l'utilisation d'IPv4 uniquement
-6 Force l'utilisation d'IPv6 uniquement
-A Autorise le forwarding de l'agent d'authentification. Peut être spécifié par hôte dans un fichier de configuration.
-a Désactive le forwarding de l'agent d'authentification
-b bind_address Utilise l'adresse locale spécifiée pour la connexion
-C Demande la compression des données. Utile pour les connexions lentes, mais ralentit le traffic dans les réseaux rapide
-c cipher_spec Liste de chiffrements dans l'ordre de préférence pour le chiffrement de la session
-D [bind_address:]port Spécifie un port forwarding locale dynamique. Cela fonctionne en allouant un socker d'écoute sur le port côté local, optionnellement lié à l'adresse spécifiée. Quand une conexion est faite sur ce port, la connexion est envoyés au canal sécurisé, et le protocole d'application est ainsi utilisé pour déterminer où se connection depuis la machine distante. Actuellement les protocoles SOCKS4 et SOCKS5 sont supportés, et ssh agit comme un serveur SOCKS.
-E log_file Ajoute les logs débug à log_file au lieu de l'erreur standard
-e escape_char Définis le caractère d'échappement pour les sessions avec un pty (défaut: ~). Ce caractère est seulement reconnu au début d'une ligne. Ce caractère suivi par un '.' ferme la connexion. Suivi par control-Z suspend la connexion, et suivi par lui-même envoie le caractère échappé une fois.
-F configfile Spécifie un fichier de configuration par utilisateur alternatif. Défaut: ~/.ssh/config
-f ssh se place en tâche de fond juste avant l'exécution
-G Affiche sa configuration après avoir évalué Host et Match, puis quitte
-g Autorise les hôte distants à se connecter aux ports forwardés. Si utilisé dans une connexion multiplexée, cette option doit être spécifiée dans le processus maître
-I pkcs11 Spécifie la librairie PKCS#11 utilisé pour communiquer avec un jeton pkcs#11
-i identity_file Fichier contenant la clé privée. Défaut: ~/.ssh/id_dsa, ~/.ssh-id_ecdsa, ~/.ssh/id_ed25519, et ~/.ssh/id_rsa.
-J [user@]host[:port] Se connecte à l'hôte spécifié en créant d'abord un saut vers cet hôte, et en établissant un forwarding TCP vers la destination. Plusieurs sauts peuvent être spécifiés séparés par des ','
-K Active l'authentification GSSAPI et le forwarding GSSAPI
-k Désactive le forwarding GSSAPI
-L [bind_address:]port:host:hostport
-L [bind_address:]port:remote_socket
-L local_socket:host:hostport
-L local_socket:remote_socket Spécifie que les connexion au port TCP ou socket unix donné dans l'hôte locla doivent être forwardés à l'hôte:port, ou socket unix donné
-l login_name Spécifie l'utilisation de connexion sur la machine distante.
-M Place le client ssh en mode master pour le partage de connexion. Peut être spécifié plusieurs fois pour ajouter une confirmation avant que les connexions esclaves soient acceptée
-m mac_spec Liste d'algorithmes MAC, dans l'ordre de préférence.
-N Ne pas exécuter une commande à distance. Utile pour un simple port forwarding
-n Redirige stdin depuis /dev/null. Doit être utilisé quand ssh tourne en tâche de fond.
-O ctl_cmd Contrôle une connexion active multiplexant un processus maître. ctl_md est interprété et passé au processus maître. (check, forwald, cancel, exit, stop)
-o option Spécifie une option tel que trouvé dans le fichier de configuration
-p port Port de connexion sur l'hôte distant
-Q query_option Affiche les algorithmes supportés pour sshv2. (cipher, cipher-auth, mac, kex, key, key-cert, key-plain, protocol-version)
-q mode silencieux
-R [bind_address:]port:host:hostport
-R [bind_address:]port:local_socket
-R remote_socket:host:hostport
-R remote_socket:local_socket Spécifie que les connexions au port TCP ou socket unix donné dans l'hôte distant doivent être forwardés à l'hôte:port ou socket unix donné, localement. Cela foncionne en alouant un socket pour écouter soit un port TCP ou un socket unix dans l'hôte distant. Quand une connexion est fait, elle est forwardée dans un canal sécurité, et une connexion est faite à l'hôte:port ou au socket, depuis la machine locale.
-S ctl_path Spécifie l'emplacement d'un socket de contrôle pour le partage de connexion, ou 'none' pour désactiver le partage de connexion
-s Peut être utilisé pour demander l'invocation d'un sous-système dans le système distant. Les sous-système facilitent l'utilisation de SSH comme transport sécurisé pour d'autres application.
-T Désactive l'allocation d'un pseudo-terminal
-t Force l'allocation d'un pseudo-terminal.
-v mode verbeux
-W host:port Demande que l'entrée et la sortie standard dans le client soient forwardés à l'hôte:port via un canal sécurisé. Implique -N, -T, ExitOnForwardFailure et ClearAllForwarding
-w local_tun[:remote_tun] Demande un forwarding avec le tunnel spécifié entre le client et le serveur
-X Active le forwarding X11.
-x Désactive le forwarding X11
-Y Active le forwarding X11 trusté, qui ne sont pas sujets aux extensions de contrôle X11 SECURITY
-y Envoie des informations en utilisant syslog, au lie de stderr

Authentification

   Les méthodes disponibles pour l'authentification sont: authentification basée sur GSSAPI, authentification basé sur l'hôte, authentification à clé publique, authentification par challenge-response, et authentification par mot de passe.

   L'authentification basé sur l'hôte fonctionne comme suit: si la machine sur laquelle l'utilisateur se log est listé dans /etc/hosts.equiv ou /etc/shosts.equiv dans la machine distante, et que les noms d'utilisateur sont les même des 2 côté, ou si les fichiers ~/.rhosts ou ~.shosts existent dans le répertoire personnel de l'utilisation dans la machine distante et contient une ligne contenant le nom de la machine cliente et le nom de l'utilisation dans cette machine, l'utilisateur est autorisé. Additionnellement, le serveur doit être capable de vérifie la clé hôte du client. Cette méthode d'authentification est peut sécurisé à cause de l'IP spoofing, DNS spoofing, et routing spoofing.

   L'authentification à clé publique fonctionne comme suit: Le schéma est basé sur la cryptographie à clé publique, en utilisant les cryptosystems où le chiffrement et le déchiffrement sont fait en utilisant des clés séparées, et il est impossible de dériver la clé de déchiffrement depuis la clé de chiffrement. L'idée et que chaque utilisateur créé une paire de clé publique/privée pour l'authentification. Le serveur connaît la clé publique, et seul l'utilisateur connaît la clé privée. ssh supporte les algorithmes DSA, ECDSA, Ed25519 et RSA.

   Le fichier ~/.ssh/authorized_keys liste les clés publiques qui sont permisses pour le logging. Quand l'utilisateur se log, ssh indique au serveur quel paire de clé utiliser pour l'authentification. Le client prouve qu'il a accès à la clé privéue et le sereur vérifie que la clé correspondante est autorisée à accéder au compte

   L'utilisateur créé sa paire de clé avec ssh-keygen, stocke la clé privée dans ~/.ssh/id_dsa, /.ssh/id_ecdsa, ~/.ssh/id_ed25519, ou ~/.ssh/id_rsa. et stocke la clé publique dans ~/.ssh/id_dsa.pub, ~/.ssh/id_ecdsa.pub, ~/.ssh/id_ed25519.pub, ou ~/.ssh/id_rsa.pub. L'utilisateur doit ensuite copier la clé publique dans ~/.ssh/authosized_keys dans le répertoire distant dans la machine distante. Ce fichier correspond au fichier rhosts conventionnel, et a une clé par ligne. Après ça, l'utilisateur peut se connecter sans donner de mot de passe

   Une variation de l'authentification à clé publique est disponible sous la forme d'une authentification par certificat. Au lieu de définir des clés publique/privées, des certificats signés sont utilisé. La manière la plus simple d'utilisation cette méthode d'authentification est avec un agent d'authentification, comme ssh-agent et optionnellement a directive AddKeysToAgent.

   L'authentification par challenge-réponse fonctionne comme suit: Le serveur envoie un challenge arbitraire, et demande une réponse. Des examples d'authentification par challenge-réponse incluent l'authentification BSD et PAM.

   Finallement, si d'autres méthodes d'authentification échouent, ssh demande un mot de passe. Le mot de passe est envoyé à l'hôte distant pour vérification; cependant, vu que toutes les communications sont chiffrées, le mot de passe ne peut pas être vu par quelqu'un qui écoute le réseau.

   ssh maintient et vérifie automatiquement une base d'identification pour tous les hôte qu'il à vu. Les clés d'hôte sont stockés dans ~/.ssh/known_hosts. De plus, /etc/ssh/ssh_known_hosts est automatiquement vérifié pour les hôtes connus. Tout nouvel hôte est automatiquement ajouté au fichier de l'utilisateur. Si l'identification d'un hôte change, ssh alerte et désactive l'authentification par mot de passe. L'option StrictHostKeyChecking peut être utilisée pour contrôler les login sur les machine dont la clé hôte n'est pas connue ou a changé.

   Quand l'identité d'un utilisateur a été acceptée par le serveur, le serveur exécute soit la commande donnée dans une session non-interactive ou, si aucune commande n'est spécifiée, donne un shell. Toute communication avec la commande distante ou le shell sont automatiquement chiffrés

   Si un pseudo-terminal a été alloué l'utilisateur peut utiliser les caractèse d'échappement ci-dessous

   Si aucun pseudo-terminal n'a été alloué, la session est transparent et peut être utilisée pour transférer des données binaire. Dans la plupart des systèmes, définis le caractère d'échappement à none va créer une session transparente même si un tty est utilisé

   La session se termine quand la commande ou le shell se termine et que toutes les connexions TCP et X11 ont été fermées.

Caractères d'échappement

Quand un pseudo-terminal est demandé, ssh supporte certaines fonctions utilisées via un caractère d'échappement:

~. Déconnexion
~^Z mise en tâche de fond
~# Lister les connexions forwardées
~& mise en tâche de fond à la déconnexion en attendant que la connexion forwardée/session X11 se termine
~? Affiche la liste des caractères d'échappement
~ B Envoie un BREAK au système distant
~ C Ouvre une ligne de commande. Actuellement, ajoute le port forwarding en utilisant les options -L, -R, et -D. Permet également d'annuel un port forwarding existant avec -KL[bind_address:]port, -KR[bind_address:]port et -KD[bind_address:]port. !command permet à l'utilisateur d'exécuter une commande locale si PermitLocalCommand est autorisée
~ R rekeying de la connexion
~ V Diminue la verbosité
~ v Augmente la verbosité

TCP forwarding

   Le forwarding des connexions TCP via un canal sécurisé peut être spécifié soit sur la ligne de commande ou dans un fichier de configuration. Une application possible est une connexion sécurisé pour un serveur de messagerie.

   Dans l'exemple ci-dessous, on cherche à chiffrer les communications entre un client IRC et un serveur, même si le serveur IRC ne supporte pas directement le chiffrement des communication. Cela foncion comme suit: l'utilisateur se connecte à l'hôte distant en utilisant ssh, en spécifiant un port à utiliser pour forwarder les connexions au serveur distant. Après ça, il est possible de démarrer le service qui est chiffré dans la machine client, en se connectant au même port local, et ssh chiffre et forward la connexion.

L'exemple suivante tunnelise une session IRC depuis la machine cliente 127.0.0.1 sur le serveur distant server.example.com:
ssh -f -L 1234:localhost:6667 server.example.com sleep 10
irc -c '#users' -p 1234 pinky 127.0.0.1

   Cela tunnélise une connexion au serveur IRC server.example.com, en joignant le canal #users, avec le pseudo pinky sur le port 1234. Le port n'est pas important du moment qu'il est supérieur à 1023, et qu'il n'est pas en conflit avec un port déjà utilisé. La connexion est redirigée au port 6667 sur le serveur distant.

   L'option -f met ssh en tâche de fond et la comande distant sleep 10 est spécifiée pour permettre de démarrer le service tunnélisé.

X11 Forwarding

   Si la variable ForwardX11 est à yes, et que l'utilisateur utilis X11 (la variable DISPLAY doit être définie), la connexion à l'affichage X11 est automatiquement forwardée dans le canal chiffré, et la connexion au vrai serveur X est faite depuis la machine locale.

   La valeur DISPLAY définie pas ssh va pointer vers le serveur, mais avec un numéro d'affichage supérieur à 0. C'est normal parce que ssh créé un serveur X proxy sur la machine serveur pour forwarder les connexions.

   ssh définis également autematiquement Xauthority sur le serveur. Il génère un cookie d'autorisation aléatoire, le stocke dans Xauthority et vérifie que toutes les connexions forwardée connaissent ce cookie et le remplace par le vrai cookie quand la connexion est ouverte. Le vrai cookie d'authentification n'est jamais envoyé au serveur.

   Si la variable ForwardAgent est à yes, et que l'utilisateur utilise un agent d'authentification, la connexion à l'agent est automatiquement forwardée au serveur.

Vérifier les clés hôte

En se connectant à un serveur pour la première fois, une empreinte de la clé publique est présentée à l'utilisateur (sauf si StrictHostKeyChecking a été désactivé). Les empreintes peuvent être déterminés par ssh-keygen:
ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key

   Si l'empreinte est déjà connue, elle est matchée et la clé peut être acceptée ou rejetée. Si seul les empreintes MD5 sont disponibles, ssh-keygen -E peut être utilisé pour adapter l'algorithme de l'empreinte.

   Vu qu'il est difficile de comparer des clé hôte en regardant simplement les empreintes, il y a également un support pour comparer les clé hôte visuellement, en utilisant un moyen aléatoire. Avec VisualHostKey à yes, un petit graphique ASCII est affiché à chaque login au serveur. En apprenant le motif qu'un serveur connu produit, un utilisateur peut facilement voir qu'une clé a changé quand un motif complètement différent est affiché. Ces motifs pouvant être ambigûes, un motif qui semble être similaire ne donne qu'une bonne probabilité que la clé hôte soit la même, sans garantie.

Pour obtenir une liste des empreintes avec leur motif aléatoire:
ssh-keygen -lv -f ~/.ssh/known_hosts

   Si l'empreinte est inconnue, une méthode alternative de vérification est disponible: les empeintes SSH vérifiés par DNS. Un enregistrement de ressource (RR), SSHFP, est ajouté à un fichier de zone et le client est capable de matche l'empreinte avec la clé présentée.

Dans cet exemple, un client se connecte au serveur, host.example.com. Le RR SSHFP doit être présent dans le fichier de zone:
ssh-keygen -r host.example.com
Les lignes affichées sont ajoutées dans la zone. Pour vérifier que la zone réponde à la demande d'empreinte:
dig -t SSHFP host.example.com
Finalement le client se connecte
ssh -o "VerifyHostKeyDNS ask" host.example.com
Voir l'option VerifyHostKeyDNS

VPN basés sur SSH

ssh support les tunnels VPN en utilisant les périphériques tun, permetant à 2 réseaux d'être joint de manière sécurisé. L'option PermitTunnel contrôle si le serveur le supporte et quel niveau.

L'exemple suivant connecte un réseaux client 10.0.50.0/24 avec un réseau distant 10.0.99.0/24 en utilisant une connection point-à-point de 10.1.1.1 vers 10.1.1.2, le serveur ssh dans la gateway vers le réseau distant 192.168.1.15, l'autorise. Dans le client:
ssh -f -w 0:1 192.168.1.15 true
ifconfig tun0 10.1.1.1 10.1.1.2 netmask 255.255.255.252
route add 10.0.99.0/24 10.1.1.2
Dans le serveur:
ifconfig tun1 10.1.1.2 10.1.1.1 netmask 255.255.255.252
route add 10.0.50.0/24 10.1.1.1
L'accès client peut être personnalisé plus finement via /root/.ssh/authorized_keys et l'option serveur PermitRootLogin. L'entrée suivante permet les connexions dans tun1 par l'utilisateur jane, et dans tun2 par john, si PermitRootLogin est à forced-commands-only:
tunnel="1",command="sh /etc/netstart tun1" ssh-rsa ... jane
tunnel="2",command="sh /etc/netstart tun2" ssh-rsa ... john

Variables d'environnement

ssh définis les variables d'environnement suivants:

DISPLAY Emplacement du serveur X11, automatiquement définis par ssh
HOME Répertoire personnel de l'utilisateur
LOGNAME Nom de l'utilisateur
MAIL Emplacement de la boite mail de l'utilisateur
PATH PATH par défaut, tel que spécifié à la compilation de ssh
SSH_ASKPASS Si définis, exécute le programme spécifié et ouvre une fenêtre X11 pour lire la passphrase
SSH_AUTH_SOCK Identifie le chemin d'un socket UNIX utilisé pour communiquer avec l'agent
SSH_CONNECTION Identifie le client et le serveur de la connexion. Contient 4 valeurs: IP, port client, IP, port serveur.
SSH_ORIGINAL_COMMAND Contient la ligne de commande originale si une commande forcée est exécutée.
SSH_TTY Définis le nom du tty associé avec le shell ou la commande courante
TZ Affecte le timezone utilisé
USER nom de l'utilisateur

Additionnellement, ssh lit ~/.ssh/environment, voir PermitUserEnvironment

Fichiers

~/.rhosts Utilisé pour l'authentification basé sur l'hôte
~/.shosts idem .rhosts, mais sans login permit avec rlogin/rsh
~/.ssh/ Répertoire de configuration par défaut pour le utilisateurs
~/.ssh/authorized_keys Liste des clés publiques qui peuvent être utilisé pour se connecter avec cet utilisateur.
~/.ssh/config Fichier de configuration de l'utilisateur
~/.ssh/environment Contient des définitions additionnels pour les variables d'environnement
~/.ssh/id_dsa
~/.ssh/id_ecdsa
~/.ssh/id_ed25519
~/.ssh/id_rsa Clé publique pour l'authentification.
~/.ssh/known_hosts Contient une liste de clés hôte pour tous les hôtes sur lesquels l'utilisateur s'est connecté
~/.ssh/rc Exécuté par ssh quand l'utilisateur se logs, juste avant de lancer le shell ou la commande
/etc/hosts.equiv Fichier pour l'authentification basé sur l'hôte. doit être writable par root uniquement
/etc/shosts.equiv idem sans autoriser rlogin/rsh
/etc/ssh/ssh_config Fichier de configuration global.
/etc/ssh/ssh_host_key
/etc/ssh/ssh_host_dsa_key
/etc/ssh/ssh_host_ecdsa_key
/etc/ssh/ssh_host_ed25519_key
/etc/ssh/ssh_host_rsa_key Contient la clé privée de l'hôte
/etc/ssh/ssh_known_hosts Liste globale de clés hôtes connus. Ce fichier devrait être préparé par l'administrateur système
/etc/ssh/sshrc Exécuté par ssh quand l'utilisateur se log, juste avant de lancer le shell ou la commande.

Code de sortie

ssh quitte avec le statut de sortie de la commande distante, ou avec 255 si une erreur s'est produite.

15 juin 2017

-A Pour chaque types de clé (rsa,-sa,ecdsa et ed25519) pour laquelle les clés hôte n'existent pas, génère les clés hôte avec le fichiers spécifié, une passphrase vide, la taille par défaut, et le commentaire par défaut.
-a rounds En sauvant une clé privée au nouveau format, spécifie le nombre de KDF (fonction de dérivation de clé) utilisé.
-B Affiche le digest de la clé privée spécifiée
-b bits Taille de la clé à créer
-C comment Fournis un nouveau commentaire
-D pkcs11 Charge les clés publique fournis par la librairie pkcs#11. Utilisé avec -s, indique qu'une clé CA réside dans le jeton PKCS#11.
-E md5|sha256 Spécifie l'algorithme de hashage en affichant les empreintes de clé
-e Lit une clé privée ou publique OpenSSH et l'affiche sur stdout dans un des formats de l'option -m
-F hostname Recherche le nom d'hôte spécifié dans un fichier known_hosts.
-f filename Spécifie le nom du fichier de clé
-G output_file Génère des premiers candidats pour DH-GEX.
-g Utilise le format DNS pour afficher les enregistrements de ressource d'empreinte en utilisant -r
-H Hash le fichier known_hosts. Remplace les hostnames et adresses avec les représentations hashés.
-h En signant une clé, créé un certificat hôte au lieu d'un certificat utilisateur.
-l certificate_identity Spécifie l'identité de clé en signant une clé publique.
-i Cette option lit une clé privée ou publique non-chiffrée au format spécifié par -m et l'affiche au format compatible OpenSSH sur stdout.
-J num_lines Quitte après n ligne pendant l'exécution du screening des candidats DH en utilisant l'option -T.
-j start_line Défarre le screening à la ligne spécifiée
-K checkpt Écris la dernière ligne traitée dans le fichier spécifié en effectuant le screening de candidat DH.
-k Génère un fichier KRL
-L Affiche le contenu d'un ou plusieurs certificats
-l Affiche l'empreinte du fichier de clé publique spécifié.
-M memory Quantité de mémoire à utiliser (en Mo) en générant le moduli candidat pour DH-GEX
-m RFC4716|PKCS8|PEM Format de clé pour -i et -e
-N new_passphrase Fournis une nouvelle passphrase
-n principals Spécifie un ou plusieurs principaux à inclure dans un certificat en signant une clé.
-O option Spécifie une option de certificat, en signant une clé. Peut être spécifié plusieurs fois. Les options valides sont:

clear Efface toutes les permissions permises
critical:name[=contents]
Extension:name[=contents] Inclus une option ou une extension arbitraire
force-command=command Force l'exécution de la commande au lieu d'un shell ou de la commande spécifié par l'utilisateur quand le certificat est utilisé pour l'authentification
no-agent-forwarding Désactive le forwarding ssh-agent
no-port-forwarding Désactive le forwarding de port
no-pty Désactive l'allocation pty
no-user-rc Désactive l'exécution -e ~/.ssh/rc
no-x11-forwarding Désactive le forwarding X11
permit-agent-forwarding Autorise le forwarding ssh-agent
permit-port-forwarding Autorise le port forwarding
permit-pty Autorise l'allocation pty
permit-user-rc Autorise l'exécution de ~/.ssh/rc
permit-x11-forwarding Autorise le forwarding X11
source-address=address_list Restreint les adresses sources depuis lequel le certificat est considéré valide.

-o Sauve la clé privée en utilisant le nouveau format au lieu de PEM
-P passphrase Fournis l'ancienne passphrase
-p Demande de changer la passphrase de la clé privée au lieu de créer une nouvelle clé
-Q Teste si les clé ont été révoqués
-q mode silencieux
-R hostname Supprime toutes les clé appartenant à hostname dans known_hosts
-r hostname Affiche le RR SSHFP pour la clé publique spécifiée
-S start Spécifie le point de départ en hexa en générant un moduli candidat pour DH-GEX
-s ca_key Signe un clé publique en utilisant la clé CA spécifiée
-T output_file Teste les premiers candidats à l'échange DH
-t dsa|ecdsa|ed25519|rsa Spécifie le type de clé à créer
-u Met à jours une KRL
-V validity_interval Spécifie un interval de validité en signant un certificat.
-v mode verbeux
-W generator Spécifie le générateur souhaité en testant le moduli pour DH-GEX
-y Lit une clé privée au format OpenSSH et affiche une clé publique sur stdout
-z serial_number Spécifie un numéro de série à embarquer dans le certificat.

Génération de moduli

ssh-keygen peut être utilisé pour générer des groupes pour le protocole de groupe d'échange Diffie-Hellman (DH-GEX). Générer ces groupes se fait en 2 étapes: Les premiers candidats sont générés en utilisant un processus rapide mais consommateur de mémoire. La génération des premiers sont effectués en utilisant -G:
ssh-keygen -G moduli-2048.candidates -b 2048
Par défaut, la recherche des premiers commence au point aléatoire dans la plage de longueur souhaitée, mais peut être changé avec -S. Une fois un jeu de candidats généré, ils doivent être screené, avec l'option -T. Dans ce mode, ssh-keygen lit les candidats depuis l'entrée standard, ou depuis un fichier avec -f, par exemple:
ssh-keygen -T moduli-2048 -f moduli-2048.candidates
Par défaut, chaque candidat est sujet à 100 test de primalité. Cela peut être changé avec -a. La valeur de générateur DH est choisie automatiquement pour le premier en considération. -W permet de choisir un générateur spécifique. Les valeur de générateur sont 2, 3 et 5.

Les groupes DH screenés peuvent être installés dans /etc/moduli. Il est important que ce fichier contienne le moduli d'une plage de longueur de bit et que les partis d'une connections partage un moduli commun.

Certificats

ssh-keygen suppporte la signature de clé pour produire des certificats qui peuvent être utilisés pour l'authentification utilisateur et hôte. Les certificats consistent d'une clé publique, des informations d'identité, 0 ou plusieurs principaux et un jeu d'options qui sont signés par une clé d'autorité de certification. Les clients ou serveurs peuvent ainsi truster seulement la clé CA et vérifier la signature des certificats. Noter que les certificats OpenSSH sont différents et plus simple que les certificats X.509.

sh-keygen support 2 types de certificats: utilisateur et hôte. Les certificats utilisateur authentifient les utilisateurs auprès des serveurs, et les certificats hôte authentifient les serveurs auprès des utilisateurs. Pour générer un certificat utilisateur:
ssh-keygen -s /path/to/ca.key -I key_id /path/to/user_key.pub
Le certificat résultant sera placé dans /path/to/user_key-cert.pub. Un certificat hôte nécessite l'option -h:
ssh-keygen -s /path/to/ca_key -I key_id -h /path/to/host_key.pub
Il est possible de signer en utilisant une clé CA stockée dans un jeton PKCS#11 en fournissant la librairie avec -D
ssh-keygen -s ca_key.pub -D libpkcs11.so -I key_id user_key.pub
Dans tous les cas, key_id est un identifiant de clé qui est loggé par le serveur quand le certifica est utilisé pour l'authentification. Les certificats peuvent être limités pour être valide pour un jeu de principaux. Par défaut, les certificats générés sont valides pour tous les utilisateurs et tous les hôte. Pour générer un certificat pour un jeu spécifié de principaux:
ssh-keygen -s ca_key -I key_id -n user1,user2 user_key.pub
ssh-keygen -s ca_key -I key_id -h -n host.domain host_key.pub

Des limitation aditionneles sur la validité et l'utilisation des certificats utilisateur peuvent être spécifiés. L'option -V permet de spécifier les dates de validité.

KRL

   ssh-key est capable de gérer des listes de révocation de clé. Ces fichiers binaire spécifient des clés ou certificats qui sont révoqués en utilisant un format compacte.

   Les KRL peuvent être générés en utilisant le flag -k. Cette option lit un ou plusieurs fichiers depuis la ligne de commande et génère une nouveau KRL. Les fichiers peuvent contenir une spécification KRL, ou des clé publique, listées une par ligne. Les clés publique sont révoquées en listant leur hash ou leur contenu dans la KRL et les certificats révoqués par numéro de série ou ID de clé.

   Révoquer les clé en utilisant une spécification KRL offre un contrôle explicite sur les types d'enregistrements utilisés pour révoquer les clé et peut être utilisé pour révoquer directement les certificats par numéro de série ou ID de clé sans avoir le certificat original complet. Une spécification KRL consiste de lignes contenant une des directives suivantes:

serial: serial_number[-serial_number] Révoque un certificat avec le numéro de série spécifié
id: key_id Révoque un certificat avec l'ID de clé spécifié
key: public_key Révoque la clé spécifiée
sha1: public_key Révoque la clé spécifiée par son hash sha1

   Les KRL peuvent être mises à jours avec -u. Qunad cette option est spécifiée, les clés listées via la ligne de commande sont fusionnées dans la KRL. Il est également possible de tester si un clé particulière est révoquée avec -Q.

15 juin 2017

ssh-keyscan

rassembler les clé publiques ssh

ssh-keyscan permet de rassembler les clé hôtes. Il a été conçu pour aider à construire et vérifier les fichiers ssh_known_hosts.

OPTIONS

-4 Force l'utilisation d'adresses IPv4 uniquement
-6 Force l'utilisation d'adresses IPv6 uniquement
-c Demande les certificats depuis les hôtes cible au-lieu des clés
-f file List les hôtes ou les paires "addrlist namelist" depuis le fichier spécifié, un par ligne
-H Hash tous les noms d'hôtes et les adresses dans la sortie.
-p port Port de connexion à l'hôte distant
-T timeout timeout pour les tentatives de connexion
-t dsa|ecdsa|ed25519|rsa Type de clé à récupérer dans les hôtes scannés
-v mode verbeux

Sécurité

Si un fichier ssh_known_hosts est construit avec ssh-keyscan sans vérifier les clés, les utilisateurs seront vulnérables aux attaques MITM. D'une autre manière, si le modèle de sécurité permet un tel risque, ssh-keyscan peut aider à detecter les fichiers de clé altérés ou les attaques MITM qui ont commencés après que le fichiers ssh_known_hosts ait été créé

Fichiers

Format d'entrée
1.2.3.4,1.2.4.4 name.my.domain,name,n.my.domain,n,1.2.3.4,1.2.4.4
Format de sortie pour RSA, DSA, ECSDA et Ed25519:
host-or-namelist keytype base64-encoded-key
où keytype est “ecdsa-sha2-nistp256”, “ecdsa-sha2-nistp384”, “ecdsa-sha2-nistp521”, “ssh-ed25519”, “ssh-dss” ou “ssh-rsa”

Exemples

Affiche la clé hôte rsa pour la machine "hostname":
ssh-keyscan hostname
Trouver tous les hôte depuis le fichier ssh_hosts qui ont une clé différente:
ssh-keyscan -t rsa,dsa,ecdsa,ed25519 -f ssh_hosts | sort -u - ssh_known_hosts | diff ssh_known_hosts -

15 juin 2017

ssh-keysign

Helper pour l'authentification basées sur l'hôte

ssh-keysign est utilisé par ssh pour accéder aux clés d'hôte local et génère la signature numérique requise durant l'authentification basées sur l'hôte. ssh-keysign est désactivé par défaut et peut seulement être activé dans la configuration client globale avec EnableSSHKeysign yes. ssh-keysign est invoqué par ssh.

15 juin 2017

sshd

Service ssh

OPTIONS

-4 Force l'utilisation d'adresses IPv4 uniquement
-6 Force l'utilisation d'adresses IPv6 uniquement
-C con_spec Spécifie les paramètres de connexion à utiliser pour le mode test étendu -T. Si fournis, toute directive Match dans la configuration qui s'applique à l'utilisateur, hôte, et adresse spécifié sont définis avant d'écrire la configuration sur stdout.
-c host_certificate_file Spécifie le chemin du certificat. Il doit matcher un fichier de clé hôte spécifié par -h ou HostKey
-d Ne lance pas en tâche de fond
-d mode debug
-E log_file Ajoute les logs de debuggage à ce fichier au lieu des logs système
-e Écrit les logs de debuggage sur stderr au lieu des logs système
-f config_file Spécifie le nom d'un fichier de configuration. Défaut: /etc/ssh/sshd_config.
-g login_grace_time Délai de grâce pour que les clients puissent s'authentifier. Défaut: 120 secondes. 0 = aucune limite.
-h host_key_file Fichier depuis lequel la clé hôte est lue. Doit être donné si sshd ne tourne pas en root. Défaut: /etc/ssh/ssh_host_dsa_key, /etc/ssh/ssh_host_ecdsa_key, /etc/ssh/ssh_host_ed25519_key et /etc/ssh/ssh_host_rsa_key.
-i Spécifie que sshd est lancé depuis inetd
-o option Peut être utilisé pour donner des options au format utilisé dans le fichier de configuration
-p port Port d'écoute. Défaut: 22. Plusieurs ports sont permis. Si spécifié, la directive Port est ignorée. Les ports spécifié en utilisant ListenAddress remplace les ports de la ligne de commande
-q Mode silencieux. N'envoie rien aux logs système
-T Mode test étendu. Vérifie la validité du fichier de configuration, affiche la configuration effective sur stdout puis quitte.
-t Mode test. Vérifie la validité du fichier de configuration et les clés.
-u len Spécifie la taile du champs dans la structure utmp qui maintient le nom d'hôte distant. Si le nom d'hôte résolu est supérieur à len, la valeur décimale est utilisé à la place. Cela permet aux hôtes avec un nom d'hôte très long d'être identifiés de manière unique.

Authentification

   sshd support le protocole ssh v2 uniquement. Chaque hôte a une clé spécifique, utilisée pour identifier l'hôte. Quand un client se connecte, le service répond avec sa clé hôte publique. Le client compare la clé avec sa base pour vérifier qu'elle n'a pas changé. Un agrément de clé Diffie-Hellman est utilisé pour générer une clé de session partagée. Le reste de la session est chiffrée en utilisant un chiffrement symétrique, actuellement AES-128, Blowfish, 2DES, CAST128, Arcfour, AES-192, ou AES-256. Le client sélectionne l'alogrithme à utiliser parmis ceux offerts par le serveur. Additionnellement, l'intégrité de session est fournie via un code MAC (hmac-md5, hmac-sha1, umac-64, umac-128, hmac-sha2-256 ou hmac-sha2-512).

   Finalement, le serveur et le client entrent dans un dialogue d'authentification. Le client tente de s'authentifier lui-même en utilisant une authentification basé sur l'hôte, authentification à clé publique, authentification par challenge-réponse, ou authentification par mot de passe. Si le client réussi à s'authentifier, il entre en préparation d'ouverture de session. À ce moment le client peut demander des éléments tel qu'un pseudo-tty, des connexions de forwarding X11, connexions forwarding TCP, ou forwarder la connexion de l'agent d'authentification via le canal sécurisé.

   Après cela, le client demande soit un shell, ou l'exécution d'une commande. Les partis entrent en mode session. Dans ce mode, un des partis peut envoyer des données, donc les données sont envoyer depuis/vers le shell ou la conmmande dans le serveur, et le terminal côté client. Quand le programme utilisateur se termine et que toutes les connexions sont fermées, le serveur envoie un status de sortie au client, et les 2 parties se terminent.

Processus de connexion

Quand un utilisateur se connecte, sshd effectue les étapes suivantes:

1. si le login est dans un tth, et qu'aucune commande n'a été spécifiée, affiche la date de dernière connection et /etc/motd
2. Si le login est dans un tth, enregistre l'horodatage de connexion
3. Véfirie /etc/nologin; s'il existe, affiche son contenu et quitte (sauf root)
4. Change pour s'exécuter avec des privilèges utilisateurs normaux
5. Définis un environnement basique
6. Lit ~/.ssh/environment, s'il existe, et les utilisateurs sont autorisés à changer leur environnement.
7. Change le répertoire personnel de l'utilisateur
8. Si ~/.ssh/rc existe, et que l'option PermitUserRC est définis, le lance, sinon si /etc/ssh/sshrc exist, le lance, sinon lance xauth.
9. Lance le shell ou la commande de d'utilisateur. Toutes les commandes sont lancées sous le shell de login de l'utilisateur.

sshrc

   Si le fichier ~/.ssh/rc existe, sh le lance après avoir lu les fichiers d'environnement, mais avant de lancer la commande ou le shell de l'utilisateur. Il ne doit pas produire de sortie sur stdout; stderr doit être utilisé à la place. Si le forwarding X11 est utilisé, il reçoit la paire "proto cookie" dans son entrée standard. Le script doit appeler xauth parce que sshd ne lance pas xauth automatiquement pour ajouter les cookies X11.

   Le but premier de ce fichier est de lancer des routines d'initialisation qui peuvent être nécessaires avant que le répertoire personnel de l'utilisateur devienne accessible. AFS est un exemple particulier d'un tel environnement.

Ce fichier contient probablement du code d'initialisation suivi par quelquechose de similaire à:
if read proto cookie && [ -n "$DISPLAY" ]; then
    if [ `echo $DISPLAY | cut -c1-10` = 'localhost:' ]; then
        # X11UseLocalhost=yes
        echo add unix:`echo $DISPLAY | cut -c11-` $proto $cookie
    else
        # X11UseLocalhost=no
        echo add $DISPLAY $proto $cookie
    fi | xauth -q -
fi

   Si ce fichier n'existe pas, /etc/ssh/sshrc est lancé, et s'il n'existe pas, xauth est utilisé pour ajouter le cookie.

Fichier authorized_keys

   AuthorizedKeysFile spécifie les fichiers contenant les clé publique pour l'authentification. Si cette option n'est pas spécifiée, le défaut est ~/.ssh/autorized_keys et ~/.ssh/authorized_keys2. Chaque ligne du fichier contient une clé. Les clé publiques consistent des champs suivants: options, keytype, base64-encoded key, comment. Le champ option est optionnel. Le keytype est “ecdsa-sha2-nistp256”, “ecdsa-sha2-nistp384”, “ecdsa-sha2-nistp521”, “ssh-ed25519”, “ssh-dss” ou “ssh-rsa”.

   Noter que chaque ligne peut faire des centaines d'octets de longs, jusqu'à une limite de 8Ko, ce qui permet des clé DSA jusqu'à 8Ko, et des clé RSA jusqu'à 16Ko.

   sshd force une clé RSA minimal de 768 bits. Les options, si présentes, sont séparés par ','. Aucun espace n'est permis, excepté entre guillemets double. Les options suivantes sont supportés:

agent-forwarding Autorise le forwarding de l'agent d'authentification précédemment désactivé par l'option restrict
cert-autority Spécifie que la clé est une autorité de certification qui sert à valider les certificats utilisateurs
command="command" Cmmande exécutée quand cette clé est utilisée. Peut être utile pour restreindre une clé a effectuer une opération spécifique.
environment="NAME=value" Définie une variable d'environnement
from="pattern-list" Spécifie que le nom canonique de l'hôte distant ou son IP doivent être présents dans cette liste.
no-agent-forwarding Interdit le forwarding de l'agent d'authentification
no-port-forwarding Interdit le forwarding TCP
no-pty Empêche l'allocation tty
no-user-rc Désactive l'exécution de ~/.ssh/rc
no-X11-forwarding Interdit le forwarding X11
permitopen="host:port" Limite le forwarding de port de ssh -L, à l'hôte:port spécifié.
port-forwarding Active le forwarding précédemment désactivé par l'option restrict
principals="principals" Liste de principaux pour l'authentification
pty Autorise l'allocation tty précédemment désactivé par l'option restrict
restrict Active toutes les restrictions, forwarding, pty, ~/.ssh/rc.
tunnel="n" Force un périphérique tun dans le serveur
user-rc Autorise l'exécution de ~/.ssh/rc précédemment désactivé par l'option restrict
X11-forwarding Autorise le forwarding X11 précédemment désactivé par l'option restrict

Fichier ssh_known_hosts

   Les fichier /etc/ssh/ssh_known_hosts et ~/.ssh/known_hosts contiennent les clés publiques pour tous les hôtes connus. Le fichier global devrait être préparé par l'administrateur, et le fichier par utilisateur est maintenu automatiquement. Chaque ligne dans ces fichier contient les champs suivants: marquer, nom d'hôte, type de clé, clé encodé en base64, commentaire. Les champs sont séparés par des espaces.

   Le marqueur est optionnel, mais s'il est présent il doit être sous la forme '@cert-authority' pour indiquer que la ligne contient un certificat d'autorité, ou '@revoked' pour indiquer que la clé contenu dans la ligne est révoquée.

   Les noms d'hôte sont une liste de motifs séparé par ','; chaque pattern est matché avec le nom canonique de l'hôte (en authentifiant un client) ou avec le nom du l'utilisateur (en authentifiant un serveur). A pattern peut inclure '*', '?', et '!' pour la négation.

   Alternativement, les noms d'hôte peuvent être stockés de manière hashé pour cacher les noms d'hôte ou les adresse.

   Le type de clé et la clé encodé en base64 sont pris directement depuis la clé hôte; ils peuvent être obtenus, par exemple, depuis /etc/ssh/ssh_host_rsa_key.pub.

   Il est permis, mais non recommandé, d'avoir plusieurs lignes ou différentes clés hôte pour le même nom. Cela se produit quand des formes courte de noms d'hôte pour différents domaines sont placés dans le fichier. Il est possible que les fichiers contenant des informations en conflit acceptent l'authentification si l'information valide peut être trouvée dans le fichier.

Exemple de fichier ssh_known_hosts:
# Comments allowed at start of line
closenet,...,192.0.2.53 1024 37 159...93 closenet.example.net
cvs.example.net,192.0.2.10 ssh-rsa AAAA1234.....=
# A hashed hostname
|1|JfKTdBh7rNbXkVAQCRp4OQoPfmI=|USECr3SWf1JUPsms5AqfD5QfxkM= ssh-rsa
AAAA1234.....=
# A revoked key
@revoked addentry articles autoadd autofind autoprod createalpha createbeta createdb createprod findentry fullpowa generator.php genhtml genman genmd gentex html insert man md pdf regen setfor setfor2 sql temp temp-new-pc tex threads ToDo ssh-rsa AAAAB5W...
# A CA key, accepted for any host in *.mydomain.com or *.mydomain.org
@cert-authority *.mydomain.org,*.mydomain.com ssh-rsa AAAAB5W...

Fichiers

~/hushlogin Supprime l'affichage de la date de dernière connexion et /etc/motd
~/.rhosts Utilisé pour l'authentification basé sur l'hôte
~/.shosts idem .rhosts, mais sans login permit avec rlogin/rsh
~/.ssh/ Répertoire de configuration par défaut pour le utilisateurs
~/.ssh/authorized_keys Liste des clés publiques qui peuvent être utilisé pour se connecter avec cet utilisateur.
~/.ssh/environment Ce fichier est lu dans l'environnement au login
~/.ssh/known_hosts Contient une liste de clés hôte pour tous les hôtes sur lesquels l'utilisateur s'est connecté
~/.ssh/rc Exécuté par ssh quand l'utilisateur se logs, juste avant de lancer le shell ou la commande
/etc/hosts.equiv Fichier pour l'authentification basé sur l'hôte. doit être writable par root uniquement
/etc/shosts.equiv idem sans autoriser rlogin/rsh
/etc/moduli Contient les groupes Diffie-Hellman utilisé pour l'échange de clé DH.
/etc/motd Message Of The Day
/etc/nologin Si ce fichier existe, sshd refuse la connexion excepté pour root
/etc/ssh/ssh_host_dsa_key
/etc/ssh/ssh_host_ecdsa_key
/etc/ssh/ssh_host_ed25519_key
/etc/ssh/ssh_host_rsa_key Contient la clé privée de l'hôte
/etc/ssh/ssh_host_dsa_key.pub
/etc/ssh/ssh_host_ecdsa_key.pub
/etc/ssh/ssh_host_ed25519_key.pub
/etc/ssh/ssh_host_rsa_key.pub Contient la partie publique de la clé de l'hôte
/etc/ssh/ssh_known_hosts Fichier système listant les clé hôte connues
/etc/ssh/sshd_config Fichier de configuration pour sshd
/etc/ssh/sshrc Similaire à ~/.ssh/rc
/var/empty Répertoire chroot utilisé par sshd durant la séparation de privilège dans la phase de préauthentification. Ce répertoire ne devrait pas contenir de fichiers et doit être possédé par root.
/var/run/sshd.pid fichier pid du processus sshd.

15 juin 2017

sshd_config

Fichier de configuration pour sshd

AcceptEnv Spécifie quelles variables d'environnement envoyées par le client sont copiées dans l'environnement de la session. Voir SendEnv dans ssh_config
AddressFamily any|inet|inet6 Spécifie quelles familles d'adresse sont utilisés par sshd
AllowAgentForwarding yes|no Spécifie si le forwarding ssh-agent est permis. Noter que le désactiver n'améliore pas la sécurité sauf si les utilisateur se voient refuser un accès shell, vu qu'ils peuvent installer leur propre forwarders.
AllowGroups Liste de pattern de nom de groupe autorisé à se connecter
AllowStreamLocalForwardings yes|all|no|local|remote Spécifie si le forwarding StreamLocal (socket Unix) est permis
AllowTcpForwarding yes|all|no|local|remote Spécifie si le forwarding TCP est permis
AlowUsers Liste de noms d'utilisateurs autorisés à se connecter
AuthenticationMethods Spécifie les méthodes d'authentification qui doit être complétée pour autoriser l'accès à un utilisateur. 'any' indique toutes les méthodes.
AuthorizedKeysCommand Spécifie un programme à utiliser pour rechercher les clés publique de l'utilisateur. Le programme doit être possédé par root, pas en écriture pour le groupe et les autres. Le programme doit sortir 0 ou plusieurs ligne au format authorized_keys.
AuthorizedKeysCommandUser Spécifie l'utilisateur sous lequel AuthorizedKeysCommand est lancé.
AuthorizedKeysFile Spécifie le fichier qui contient les clés publique utilisées pour l'authentification utilisateur.
AuthorizedPrincipalsCommand Spécifie un programe à utiliser pour générer une liste de principaux.
AuthorizedPrincipalsCommandUser Spécifie l'utilisateur sous lequel la commande AuthorizedPrincipalsCommand est lancée
AuthorizedPrincipalsFile Spécifie un fichier qui liste les noms principaux qui sont acceptés pour l'authentification par certificat.
Banner Le contenu de ce fichier est affiché à l'utilisateur avant l'authentification.
ChallengeResponseAuthentication yes|no Spécifie si l'authentification par challenge/réponse est authorisée
ChrootDirectory Spécifie le chemin d'un répertoire pour chroot après l'authentification.
Ciphers Liste des chiffrements permis.
ClientAliveCountMax Définis le nombre de messages alive client qui peuvent être envoyés sans reçevoir de réponse du client. Si ce seuil est atteint, le client est déconnecté.
ClientAliveInterval timeout en secondes après lequel si aucune données n'a été reçue du client, sshd envoie un message alive. 0 = désactivé
Compression yes|no Spécifie si la compression est autorisé une fois l'authentification réussie.
DenyGroups Liste de groupes autorisés à se connecter
DenyUsers Liste d'utilisateurs non autorisés à se connecter
DisableForwarding Désactive toutes les fonctionnalités de forwarding
FingerprintHash md5|sha1256 Spécifie l'algorithme de hashage utilisé pour les empreintes de clé le login
ForceCommand Force l'exécution de la commande spécifié, ignorant toute commande fournie par le client et ~/.ssh/rc.
GatewayPorts yes|no|clientspecified Spécifie si les hôte distant sont autorisés à se connecter aux port forwardés pour le client.
GSSAPIAuthentication yes|no Spécifie si l'authentification basée sur GSSAPI est permis
GSSAPICleanupCredentials yes|no Spécifie si le cache d'accréditifs utilisateurs est automatiquement détruit à la déconnexion
GSSAPIStrictAcceptorCheck yes|no Détermine si l'acceptation de l'identité GSSAPI est stricte.
HostbasedAcceptedKeyTypes Spcifie les types de clé acceptés pour l'authentification basé sur l'hôte.
HostbasedAuthentication yes|no Spécifie si l'authentification rhosts ou /etc/hosts.equiv avec la clé publique cliente est permise
HostbasedUsesNameFromPacketOnly Spéifie si le serveur tente d'effectuer une recherche inversée en matchant les noms dans ~/.shosts, ~/.rhosts et /etc/hosts.equiv.
HostCertificate Spécifie un fichier contenant un certificat hôte publique.
HostKey Spécifie un fichier contenant une clé privée hôte.
HostKeyAgent Identifie le socket Unix utilisé pour communiquer avec un agent que a accès aux clés privées
HostKeyAlgorithms Spécifie les algorithmes de clé hôte que le serveur offre.
IgnoreRhosts yes|no Spécifie que les fichiers .rhosts, et .shosts ne sont pas utilisé dans HostbasedAuthentication
IgnoreUserKnownHosts yes|no Spécifie si sshd doit ignorer le fichier ~/.ssh/known_hosts de l'utilisateur durant HostbasedAuthentication.
IPQoS Spécifie le type de service IPv4 ou la classe DSCP pour les connexions. aff11, af12, af13, af21, af22, af23, af31, af32, af33, af41, af42, af43, cs0, cs1, cs2, cs3, cs4, cs5, cs6, cs7, ef, lowdelay, throughput, reliability, ou une valeur numérique.
KbdInteractiveAuthentication yes|no Utilise l'authentification interactive au clavier.
KerberosAuthentication yes|no Spécifie si le mot de passe fournis par l'utilisateur pour PasswordAuthentication est validé auprès du KDC.
KerberosGetAFTToken yes|no Si AFS est actif et l'utilisateur a un TGT, tente d'acquérir un jeton AFS avant d'accéder au répertoire home.
KerberosOrLocalPasswd yes|no Si l'authentification kerberos échoue, le mot de passe est validé avec un mécanisme local.
KerberosTicketCleanup yes|no Spécifie si le cache de ticket de l'utilisateur est automatiquement détruit à la déconnexion.
KeyAlgorithms Spécifie les algorithmes d'échange de clé permis.
ListenAddress Spécifie les adresses locales d'écoute
LoginGraceTime Délay au delà duquel le serveur déconnecte si l'utilisateur n'a pas réussi la connexion. 0 = pas de limite.
LogLevel Niveau de verbosité des logs. QUIET, FATAL, ERROR, INFO, VERBOSE, DEBUG, DEBUG1, DEBUG2, DEBUG3.
MACs Spécifie les algorithmes MAC dans l'ordre de préférence
Match Introdui un block conditionnel. Si tous les critères sont satisfaut, les mots clés suivant remplacent la section globale. Les critèrse sont User, Group, Host, LocalAddress, LocalPort, et Address. Les mots clés suivants sont permis après un match: AcceptEnv, AllowAgentForwarding, AllowGroups, AllowStreamLocalForwarding, AllowTcpForwarding, AllowUsers, AuthenticationMethods, AuthorizedKeysCommand, AuthorizedKeysCommandUser, AuthorizedKeysFile, AuthorizedPrincipalsCommand, AuthorizedPrincipalsCommandUser, AuthorizedPrincipalsFile, Banner, ChrootDirectory, ClientAliveCountMax, ClientAliveInterval, DenyGroups, DenyUsers, ForceCommand, GatewayPorts, GSSAPIAuthentication, HostbasedAcceptedKeyTypes, HostbasedAuthentication, HostbasedUsesNameFromPacketOnly, IPQoS, KbdInteractiveAuthentication, KerberosAuthentication, LogLevel, MaxAuthTries, MaxSessions, PasswordAuthentication, PermitEmptyPasswords, PermitOpen, PermitRootLogin, PermitTTY, PermitTunnel, PermitUserRC, PubkeyAcceptedKeyTypes, PubkeyAuthentication, RekeyLimit, RevokedKeys, StreamLocalBindMask, StreamLocalBindUnlink, TrustedUserCAKeys, X11DisplayOffset, X11Forwarding et X11UseLocalHost.
MaxAuthTries Spécifie le nombre maximum de tentatives d'authentification permise par connexion. Une fois ce nombre atteint, des erreurs additionnels sont loggés.
MaxSessions Nombre de shell, login, ou de sessions sous-système (ex sftp) par connexion réseaux Plusieurs sessions peuvent être établies par les clients qui supportent le multiplexage de connexion. 1 = désactive le multiplexage, 0 = empêche toute session.
MaxStartups Nombre de connexions non-authentifiée concurrentes permises. Alternativement, un format "start:rate:full" va refuser les tentatives de connexion avec un aux de rate/100, s'il y a start connections non-authentifiées concurrentes. La probabilité augmente de manière linéaire et toutes les tentatives de connexion sont refusés si le nombre de connexions non-authentifiées atteint 'full' (Défaut: 10:30:100)
PasswordAuthentication yes|no Spécifie si l'authentification par mot de passe est permise
PermitEmptyPasswords yes|no Quand l'authentification par mot de passe est permis, spécifie si le serveur autorise le login aux comptes sans mot de passe.
PermitOpen [hostname|IP]:port [...] Spécifie les destinations pour lesquels le port forwarding TCP est permis. 'any' supprime toute restriction.
PermitRootLogin yes|prohibit-password|without-password|forced-commands-only|no prohibit-password ou without-password, l'authentification par mot de passe et au clavier sont désactivés. À forced-commands-only, la connexion root avec clé publique est autorisées mais seulement si l'option command a été spécifiée.
PermitTTH yes|no Spécifie si l'allocation pty est permise
PermitTunnel yes|point-to-point|ethernet|no Spécifie si le forwarding de périphérique tun est permis
PermitUserEnvironment yes|no Spécifie si ~/.ssh/environment dans dans le fichier ~/.ssh/authorized_keys sont traités par sshd.
PermitUserRC yes|no Spécifie si le fichier ~/.ssh/rc est exécuté
PidFile Fichier pid du service, on 'none' pour désactiver l'écriture de ce fichier
Port Spécifie le numéro de port d'écoute de sshd. Défaut: 22. Peut être spécifié plusieurs fois
PrintLastLog yes|no Spécifi si sshd affiche la date de dernière connexion de l'utilisateur
PrintMotd yes|no Spécifie si sshd doit afficher /etc/motd quand l'utilisateur se log.
PubkeyAcceptedKeyTypes Spécifie les types de clé acceptés pour l'authentification à clé publique
PubkeyAuthentication Spécifie si l'authentification par clé publique est permise
RekeyLimit Quantité maximum d-e données transmises avant que la clé de session soit renégociée, optionnellement avec un suffix 'K', 'M', ou 'G'.
RevokedKeys Spécifie le fichier de clés révoquées
StreamLocalBindMask umask de création de fichier utilisé en créant le socket unix. Défaut: 0177.
StreamLocalBindUnlink yes|no Spécifie si un fichier socket unix existant doit être supprimé avant d'en créer un nouveau.
StrictModes yes|no Vérifie les permissions et propriétaire des fichiers utilisateur et répertoire home avant d'accepter la connexion
Subsystem Configure un sous-système externe (ex: sftp)
SyslogFacility DAEMON, USER, AUTH, LOCAL0, LOCAL1, LOCAL2, LOCAL3, LOCAL4, LOCAL5, LOCAL6, LOCAL7
TCPKeepAlive yes|no Spécifie si le système envoie des messages TCP keepalive.
TrustedUserCAKeys Spécifie un fichier contenant les clé publiques d'autorité de certification utilisés pour signer les certificats utilisateurs
UseDNS yes|no Recherche les noms d'hôte distants via DNS.
VersionAddendum Spécifie un texte additionnel à ajouter au protocole Banner envoyé par le serveur.
X11DisplayOffset Spécifie le premier affichage disponible pour le forwarding X11.
X11Forwarding yes|no Autorise le forwarding X11
X11UseLocalHost yes|no Spécifie si sshd lie le forwarding X11 à l'adresse de boucle locale ou l'adresse wildcard.
XAuthLocation Chemin complet du programme xauth

Formats de temps

Jetons

Les arguments de certains mots clé peuvent utilise des jetons, étendus comme suit:

%% le caractère %
%F l'enpreinte de la clé CA
%f l'empreinte de la clé ou du certificat
%h Répertoire personnel de l'utilisateur
%I ID de clé dans le certificat
%K Clé CA base64
%k clé ou certificat base64 pour l'authentification
%s Numéro de série du certificat
%T Type de clé CA
%t Type de clé ou certifiat
%u Nom de l'utilisateur

Les mots clés qui accèptent les jetons sont:

AuthorizedKeysCommand %%, %f, %h, %k, %t, %u
AuthorizedKeysFile %%, %h, %u.
AuthorizedPrincipalsCommand %%, %F, %f, %h, %i, %K, %k, %s, %T, %t, %u.
AuthorizedPrincipalsFile %%, %h, %u.
ChrootDirectory %%, %h, %u.

15 juin 2017

ssh_config

Fichier de configuration pour ssh

ssh obtient sa configuration depuis les sources suivantes, dans l'ordre:

1. Options de ligne de commande
2. fichier de configuration utilisateur
3. Fichier de configuration du système

Pour chaque paramètre, la première valeur obtenue est utilisée. Les fichiers de configuration contiennent des sections séparés par des spécifications Host, qui ne s'appliquent qu'aux hôte qui matchent un des patterns donnés dans la spécification.

OPTIONS

Host Restreint les déclarations suivantes aux hôtes qui matchent le motif donné. '*' peut être utilisé comme section par défaut. '!' peut être utilisé pour inverser le match.
Match Restreint les déclarations suivantes seulement quand les conditions spécifiées sont satisfaites:

canonical matche seulement quand le fichier de configuration est reparcouru après la canonisation du nom d'hôte (voir l'option CanonicalizeHostname).
exec Exécute la commande spécifié dans le shell de l'utilisateur. Si la commande retourne un code de sortie 0, la condition est vrai
host Les critères sont matchés avec le nom d'hôte de la cible, après substitution par les options Hostname ou CanonicalizeHostname
originalhost Matche avec le nom d'hôte tel que spécifié sur la ligne de comande.
user Matche le nom d'utilisateur cible dans l'hôte distante
localuser Matche e nom de l'utilisateur local qui lance ssh
all Match tout

AddKeysToAgent yes|ask|confirm|no Spécifie si le clés devraient être automatiquement ajoutés à un ssh-agent en cours de fonctionnement. Si cette option est à yes, et qu'une clé est chargée depuis un fichier, la clé et sa passphrase sont ajoutés à l'agent avec la durée de vie par défaut, comme avec ssh-add. Si cette option est à ask, ssh demande confirmation en utilisant le programme SSH_ASKPASS. à confirm, chaque utilisation de la clé doit être confirmée. à no, aucune clé n'est ajoutée
AddressFamily any|inet|inet6 Spécifie quelle famille d'adresse utiliser pour la connexion
BatchMode yes|no à yes, la demande de mot de passe est désactivée
BindAddress Utilise l'adresse spécifié dans la machine locale comme adresse sources de la connexion. Ne fonctionne pas si UsePrivilegedPort est à yes
CanonicalDomains Activé, spécifie la liste de suffixes de domaines dans lequel rechercher l'hôte de destination
CanonicalizeFallbackLocal yes|no à yes, tente de rechercher le nom d'hôte non qualifié en utilisant les règles de recherche du résolveur. à no, ssh échoue immédiatement si CanonicalizeHostname est activé et que la cible n'est pas trouvé dans les domaines spécifiés par CanonicalDomains
CanonicalizeHostname yes|no Effectue une canonicalisation de nom d'hôte. à no, laisse le résolver rechercher les noms d'hôte, à yes, pour les connexion qui n'utilisent pas ProxyCommand, ssh tente de canoniser le nom d'hôte.
CanonicalizeMaxDots Nombre de points maximum dans le nom d'hôte avant de désactiver la canonicalisation.
CertificateFile Spécifie le certificat de l'utilisateur
ChallengeResponseAuthentication yes|no Active l'authentification challenge-response
CheckHostIP yes|no à yes, effectue une vérification additionnelle de l'adresse IP dans le fichier known_hosts. Permet de détecter si une clé hôte a changé dû à un DNS spoofing
Ciphers Spécifie les chiffrements permet, dans l'ordre de préférence (ssh -Q cipher pour obtenir une liste de chiffrements disponibles)
ClearAllForwardings yes|no Spécifie que tous les ports forwarding local, distant et dynamique spécifiés sont effacés. Utile pour scp et sftp qui les définissent automatiquement.
Compression yes|no Utilise la compression
ConnectionAttempts Nombre de tentatives (1 par secondes) avant de quitter. Défaut: 1
ConnectTimeout Spécifie le timeout en secondes utilisé pour se connecter au serveur ssh, au lieu d'utiliser le timeout TCP du système. Cette valeur est utilisé quand la cible est indisponible, pas quand elle refuse la connexion
ControlMaster yes|no|ask|autoask Active le partage de plusieurs sessions dans une seule connexion réseaux. à yes, ssh écoute les connexions dans un socket de contrôle ControlPath
ControlPath Spécifie le socket contrôle utilisé pour le partage de connexion
ControlPersist yes|no Spécifie que la connexion master de rester en tâche de fond pour de future connexions client, après que la connexion cliente initiale a été fermée
DynamicForward [bind_address:]port Spécifie qu'un port TCP dans la machine locale est forwardée dans le canal sécurisé, et le protocole d'application est ainsi utilisé pour déterminer où se connecter depuis la machine distante
EnableSSHKeySign yes|no à yes, active l'utilisation de ssh-keysign durant HostbaseddAuthentication
EscapeChar Définis le caractère d'échappement (défaut: ~)
ExitOnForwardFailure yes|no Indique si ssh termine la connexion s'il ne peut pas définir les ports forwardings dynamique, local, tunnel, et distant
FingerprintHash md5|sha256 Spécifie l'algorithme de hashage utilisé pour afficher les empreintes de clé
ForwardAgent yes|no Spécifie si la connexion à l'agent d'authentification est forwardée à la machine distante.
ForwardX11 yes|no Spécifie si les connexions X11 sont automatiquement redirigés dans la canal sécurisé.
ForwardX11Timeout timeout pour le forwarding X11 utilisant le format de temps. Les connexions après ce délai sont refusés
ForwardX11Trusted yes|no à yes, les clients X11 distants ont un accès complet à l'affichage X11 original. à no, les clients sont considérés comme non-sûres et bloqués pour éviter le vol ou la falsification des données des clients X11 de confiance.
GatewayPorts yes|no Spécifie si les hôtes distant sont autorisés à se connecter aux ports forwardés locaux. par défaut, ces ports sont liés à l'adresse de bouclage. Cela empêche d'autres hôtes de se connecter aux ports forwardés. Cette option peut être utilisée pour spécifier que ssh lie le port forwarding à l'adresse wildcard.
GlobalKnownHostsFile Spécifie un ou plusieurs fichiers à utiliser pour la base de clé hôte globale, séparé par ' '. Défaut: /etc/ssh/ssh_known_hosts, /etc/ssh/ssh_known_hosts2
GSSAPIAuthentication yes|no Spécifie si l'authentification basée sur GSSAPI est permise
GSSAPIDelegateCredentials yes|no Forward les accréditifs au serveur
HashKnownHosts yes|no Indique que ssh doit hasher les noms d'hôte et les adresses quand elles sont ajoutées à ~/.ssh/known_hosts.
HostbasedAuthentication yes|no Spécifie si l'authentification à clé publique basée sur l'hôte est permise
HostbasedKeyTypes Spécifie la liste des types de clé qui sont utilisé pour l'authentification basé sur l'hôte.
HostKeyAlgorithms Spécifie les algorithmes de clé hôte à utiliser par le client, dans l'ordre de préférence.
HostKeyAlias Spécifie un alias qui doit être utilisé à la place du vrai nom d'hôte en recherchant ou en sauvegardant la clé hôte dans les fichiers de base de clé hôte.
HostName Spécifie le nom d'hôte réel de connexion. Défaut: le nom spécifié sur la ligne de commande
IdentitiesOnly yes|no Spécifie que ssh devrait seulement utiliser l'identité d'authentification et les fichiers de certificat explicitement configurés dans ssh_config ou passés sur la ligne de commande, même si ssh-agent ou un PKCS11Provider offfre plus d'identitiés.
IdentityAgent Spécifie le socket unix utilisé pour communiquer avec l'agent d'authentification
IdentityFile Spécifie un fichier depuis lequel l'identité d'authentification DSA, ECDSA, Ed25519, ou RSA de l'utilisation est lu. Défaut: ~/.ssh/id_dsa, ~/.ssh/id_ecdsa, ~/.ssh/id_ed25519, ~/.sdsh/id_rsa.
IgnoreUnknown Spécifie une liste de motifs d'options inconnue à ignorer s'ils sont rencontrés dans la configuration
Include Inclus les fichiers de configuration spécifiés. Plusieurs fichiers peuvent être spécifié et peuvent contenir un wildcard
IPQoS Spécifie le type de service IPv4 ou la classe DSCP pour les connexions. aff11, af12, af13, af21, af22, af23, af31, af32, af33, af41, af42, af43, cs0, cs1, cs2, cs3, cs4, cs5, cs6, cs7, ef, lowdelay, throughput, reliability, ou une valeur numérique.
KbdInteractiveAuthentication yes|no Utilise l'authentification interactive au clavier.
KbdInteractiveDevices Spécifie la liste des méthodes à utiliser dans l'authentification interactive.
KexAlgorithms Spécifie les algorithmes d'échange de clé permis
LocalCommand Spécifie une commande à exécuter dans la machine locale après s'être connecté au serveur.
LocalForward [bind_address:]port Spécifie qu'un port TCP dans la machine local est forwardé via le canal sécurisé vers l'hôte:port distant. Seul root peut forwarder des ports privilégiés Par défaut, le port local est lié en accord avec GatewayPorts, si bind_address n'est pas spécifié
LogLevel Niveau de verbosité des logs. QUIET, FATAL, ERROR, INFO, VERBOSE, DEBUG, DEBUG1, DEBUG2, DEBUG3.
MACs Spécifie les algorithmes MAC dans l'ordre de préférence
NoHostAuthenticationForLocalhost yes|no Peut être utilisé si le répertoire hôte est partagé. Dans ce cas localhost réfère à une machine différente dans chaque machine et l'utilisateur a des alerts sur les clés d'hôte changés. Cette option désactive l'authentification pour localhost.
NumberOfPasswordPrompts Spécifie le nombre de demande de mot de passe maximume. Défaut: 3
PasswordAuthentication yes|no Indique si l'authentification par mot de passe est permise.
PermitLocalCommand yes|no Autorise l'exécution de commande locale via l'option LocalCommand
PKCS11Provider Spécifie le fournisseur PKCS#11 à utiliser.
Port Spécifie le port de connexion. Défaut: 22
PreferredAuthentications Spécifie l'ordre des méthodes d'authentification
ProxyCommand Spécifie la commande à utiliser pour se connecter au serveur. La chaîne s'étend à la fin de la ligne et est exécuté en utiisant exec
ProxyJump Spécifie un ou plusieurs sauts proxy. Plusieurs proxy peuvent être spécifié, et sont visités séquentiellement. Noter que cette option est en concurrence avec ProxyCommand, c'est le premier spécifié qui est utilisé
ProxyUseFdpass yes|no Spécifie que ProxyCommand passe un descripteur de fichier connecté à ssh au lieu de continuer à exécuter et passe des données.
PubkeyAcceptedKeyTypes Spécifie les types de clé utilisés pour l'authentification à clé publique
PubkeyAuthentication yes|no Indique si l'authentification à clé publique est permise
RekeyLimit Spécifie la quantité maximum de données qui peuvent être transmis avant que la clé de session soit renégociée, optionnellement suivant par un délay. La taille peut être préfixé(K, M, G), le délay utilise le format de temps.
RemoteCommand Spécifie une commande à exécuter dans la machine distante une foi connecté au serveur. La chaîne s'étend à la fin de la ligne, et est exécuté avec le shell de l'utilisateur.
RemoteForward [bind_address:]port Spécifie qu'un port TCP dans la machine distante est forwardée dans le canal sécurisé à l'hôte:port dans la machine locale.
RequestTTY yes|auto|force|no Demande un pseudo-tty pour la session.
RevokedHostKeys Spécifie le clés publiques révoquées. Les clés listées dans ce fichier seront refusés pour l'authentification de l'hôte. Ce fichier peut être un fichier texte listant une clé publique par ligne, ou comme une liste de révocation de clé OpenSSH, tel que généré pa ssh-keygen.
SendEnv Spécifie quelles variables de l'environnement local sont envoyés au serveur. Le serveur doit également le supporter et doit les accepter Noter que TERM est toujours envoyé. Voir AcceptEnv dans sshd_config
ServerAliveCountMax Définis le nombre de message alive serveur qui peuvent être envoyés sans que ssh ne reçoive de réponse du serveur, terminant la session. Il est important de noter que ces messages sont différents de TCPKeepAlive, qui est spoofable. Défaut: 3
ServerAliveInterval Intervalle en secondes sans avoir reçu de données avant d'envoyer une requête au serveur. Défaut: 0 (désactivé)
StreamLocalBindMask umask utilisé en créant le socket unix. Utilisé uniquement pour le port forwarding vers un socket unix. Défaut: 0177
StreamLocalBindUnlink yes|no Spécifie si le socket unix est supprimé avant d'en créer un nouveaux.
StrictHostKeyChecking yes|ask|no à yes, ssh n'ajoute jamais automatiquement les clés hôte dans ~/.ssh/known_hosts, et refuse de se connecter si la clé hôte a changé.
SyslogFacility DAEMON, USER, AUTH, LOCAL0, LOCAL1, LOCAL2, LOCAL3, LOCAL4, LOCAL5, LOCAL6, LOCAL7
TCPKeepAlive yes|no Spécifie si le système envoie des tcp keepalive.
Tunnel yes|point-to-point|ethernet|no Demande un périphérique tun entre le client et le serveur.
TunnelDevice local_tun[:remote_tun] Spécifie le périphérique tun à ouvrir. Les périphériques peuvent être spécifiés par ID ou le mot clé any qui utiliser le premier périphérique disponible
UpdateHostKeys yes|no|ask Spécifie si ssh accepte les notification de clé hôtes additionnels du serveur une fois l'authentification réussie et le ajoute à UserKnownHostsFile.
UsePrivilegedPort yes|no Spécifie l'utilisation d'un port privilégié pour les connexions sortantes. ssh doit être setuid root
User Spécifie l'utilisateur pour la connexion
UserKnownHostsFile Spécifie un ou plusieurs fichiers à utiliser pour la base de clé d'hôte utilisateur. Défaut: "~/.ssh/known_hosts ~/.ssh/known_hosts2"
VerifyHostKeyDNS yes|no|ask Indique si la clé distante est vérifié en utilisant DNS et les enregistrement SSHFP.
VisualHostKey yes|no À yes, une réprésentation ASCII de l'empreinte de la clé distante est affichée au login pour les clés hôte inconnues.
XAuthLocation Chemin du programme xauth. Défaut: /usr/X11R6/bin/xauth

Motifs

   Un pattern consiste de 0 ou plusieurs caractères non-blanc '*' ou '?'. Par exemple, pour spécifier un jeu de déclarations pour un hôte dans le domaine .co.uk:

  Host *.co.uk

  Pour matcher un hôte dans le réseau 192.168.0.[0-9]:

  Host 192.168.0.?

  Un pattern-list est une liste de patterns. les patterns peuvent être inversé avec '!'. Par exemple, pour autoriser une clé excepté depuis le pool dialup, l'entrée suivante dans authorized_keys:

  from="!*.dialup.example.com,*.example.com"

Jetons

Les arguments de certains mots clé peuvent utilise des jetons, étendus comme suit:

%% le caractère %
%C Raccourcis pour %I%h%p%r
%d home de l'utilisateur
%h Nom de l'hôte distant
%I UID local
%L Nom de l'hôte local
%I FQDN de l'hôte local
%n Nom de l'hôte distant, tel que donné sur la ligne de commande
%p Le port distant
%r Nom de l'utilisateur distant
%u Nom de l'utilisateur local

Les mots clés qui accèptent les jetons sont:

jetons permis

Match exec %%, %h, %L, %l, %n, %p, %r, %u.
CertificateFile %%, %d, %h, %l, %r, %u.
ControlPath %%, %C, %h, %i, %L, %l, %n, %p, %r, %u.
HostName %%, %h.
IdentityAgent
IdentityFile %%, %d, %h, %l, %r, %u.
LocalCommand %%, %C, %d, %h, %l, %n, %p, %r, %u.
ProxyCommand %%, %h, %p, %r.
RemoteCommand %%, %C, %d, %h, %l, %n, %p, %r, %u.

fichiers

~/.ssh/config Fichier de configuration de l'utilisateur. Ce fichier doit avoir les permissions suivantes: rw pour l'utilisateur, aucun pour les autres.
/etc/ssh/ssh_config Fichier de configuration système.

13 février 2012

update-reader.conf

Outil pour générer reader.conf

Outil pour regénérer /etc/reader.conf. Il tente de générer le fichier de configuration depuis les fichiers inclus dans /etc/reader.conf.d/. l’ancienne version est backupée dans /etc/reader.conf.old

OPTIONS

force Si le /etc/reader.conf ne contient pas de tag spécial sur la première ligne, il annule la régénération. Ce paramètre le force à continuer.

24 mars 2016

veritysetup

Gère les volumes dm-verity

veritysetup est utilisé pour configurer les mappages device-mapper dm-verity. Les cibles verity fournissent une vérification d'intégrité transparente des périphériques block utilisant l'API crypto kernel. Les périphériques dm-verity sont toujours lecture-seule.

Opérations

format ‹data_device› ‹hash_device› Calcule et stocke Les données de vérification de hash de manière permanente pour le périphérique. La zone de hash peut être localisée sur le même périphérique après que les données soient spécifiées par l'option --hash-offset. Il est nécessaire de fournir la chaîne de hash root pour la vérification du périphérique ou l'activation. Le hash root doit être trusté. Les argument hash et data peuvent être un périphérique block ou un fichier image. Si le périphérique de hash n'existe pas il sera créé
create ‹name› ‹data_device› ‹hash_device› ‹root_hash› Créé un mappage du nom sur le périphérique donné en utilisant le hash pour la vérification par le kernel. root_hash est une chaîne hexadécimale.
verify ‹data_device› ‹hash_device› ‹root_hash› Vérifie a donnée dans le périphérique en utilisant les blocks de hash stocké dans hash_device. Cette commande effectue une vérification dans l'espace utilisateur, aucun périphérique kernel n'est créé.
remove ‹name› Supprime le mappage existant spécifié
status ‹name Affiche le status pour la mappage verity actif spécifié
dump ‹hash_device› Repporte les paramètres du périphérique verity depuis le superblock stocké sur disque

OPTIONS

-v, --verbose mode verbeux
--debug Mode debug
--no-superblock Créé ou utilise dm-verify sans superblock sur disque permanent
--format=number Spécifie le type de hash (actuellement: 1)
--data-block-size=bytes Utilise la taille de block spécifiée pour le périphérique de donnée.
--hash-block-size=bytes Utilise la taille de block spécifiée pour le périphérique de hash
--data-blocks=blocks Taille du périphérique de donnée utilisée pour la vérification. Non spécifié, tout le périphérique est utilisé
--hash-offset=bytes Offset de la zone de hash dans le périphérique de hash. La valeur doit être alignée à l'offset du secteur disque
--salt=hex string Salt à utiliser pour le formattage ou la vérification. Format est une chaîne hexadécimale
--uuid=UUID Utilise l'UUID fournis pour la commande format au lieu d'en générer un nouveau

Codes de retour

0 L'opération s'est déroulé avec succès
1 Mauvais paramètres
2 N'a pas les permissions
3 Out of memory
4 Mauvais périphérique spécifié
5 Le périphérique existe déjà