Lisez-moi S.V.P. 
W3C

La spécification de la gestion des clés XML (XKMS 2.0)

Version 2.0

Recommandation du W3C du 28 juin 2005

Cette version :
http://www.w3.org/TR/2005/REC-xkms2-20050628/
Dernière version :
http://www.w3.org/TR/xkms2/
Version précédente :
http://www.w3.org/TR/2005/PR-xkms2-20050502/
Rédacteurs :
Phillip Hallam-Baker, Verisign
Shivaram H. Mysore
Contributeurs :
Cf. la section Remerciements.

Veuillez consulter la liste des errata de ce document, laquelle peut contenir des corrections normatives.

Cf. également d'éventuelles traductions.

Copyright ©2005 W3C® (MIT, ERCIM, Keio), tous droits réservés. Les règles de responsabilité, de nom de marque et d'utilisation des documents du W3C s'appliquent.

Résumé

[2] Ce document qui définit les protocoles de distribution et d'enregistrement des clés publiques accompagne les recommandations du XML Signature [XML-SIG] et XML Encryption [XML-Enc] du W3C. La spécification pour la gestion des clés XML (XKMS) se compose de deux parties : la spécification des services d'information de clés XML (X-KISS) et la spécification des services d'enregistrement de clés XML (X-KRSS).

Statut de ce document

Cette section décrit le statut de ce document au moment de sa publication. D'autres documents peuvent venir le remplacer. On peut trouver une liste des publications courantes du W3C et la dernière révision de ce rapport technique dans l'index des rapports techniques du W3C à l'adresse http://www.w3.org/TR/.

Ce document est une recommandation du W3C →vf. Il a été révisé par les membres du W3C et d'autres tiers intéressés, et approuvé par le Directeur. C'est un document stable qui peut être utilisé comme matériel de référence ou cité comme référence normative par un autre document. Le rôle du W3C en produisant la recommandation consiste à attirer l'attention sur la spécification et à en promouvoir un large déploiement. Cela participe à la fonctionnalité et l'interopérabilité du Web.

Ce document a été produit par le groupe de travail XKMS. Seule la version en anglais de cette spécification est normative. Des versions traduites de ce document sont éventuellement disponibles.

Pour tous commentaires sur ce document, rendez-vous sur www-xkms@w3.org, une liste de diffusion avec des archives publiques. Une liste des errata de cette édition est disponible.

Ceci est la première partie de la recommandation du W3C de la spécification de la gestion des clés XML (XKMS version 2.0). Ce document définit les protocoles de distribution et d'enregistrement des clés publiques, à utiliser en conjonction avec les standards proposés XML Signature →vf et XML Encryption →vf. La spécification de la gestion des clés XML (XKMS) définit deux types de service : les services d'information de clés XML (X-KISS) et les services d'enregistrement de clés XML (X-KRSS). La deuxième partie →vf de cette spécification couvre les diverses liaisons de protocoles présentant des caractéristiques de sécurité pour XKMS. Pour connaître les fondements de ce travail, veuillez consulter la déclaration de l'activité XKMS.

Ce document se fonde sur la recommandation proposée de la spécification XKMS version 2.0 du 2 mai 2005. Les commentaires reçus au cours de cette période de révision ont suscité des changements rédactionnels mineurs. Les preuves d'interopérabilité entre au moins deux mises en œuvre de cette spécification sont documentées dans le rapport de mise en œuvre. Les changements effectués sur ce document depuis le stade de recommandation proposée sont répertoriés dans l'Annexe F.

Ce document est produit sous couvert de la politique de brevetabilité courante du 24 janvier 2002 modifiée par la procédure de transition de la politique de brevetabilité du W3C. Le groupe de travail tient à disposition la liste publique des divulgations de brevets relative à ce document ; cette page contient également des instructions pour divulguer un brevet. Toute personne ayant connaissance de l'existence d'un brevet, qu'elle estime contenir une (ou des) revendication(s) essentielle(s) touchant à cette spécification, devrait divulguer cette information, conformément à la section 6 de la politique de brevetabilité du W3C.

Table des matières

1 Introduction

[8] Ce document définit les protocoles de distribution et d'enregistrement de clés publiques à utiliser avec le standard de signature XML Signature [XML-SIG], qui est défini par le World Wide Web Consortium (W3C) et l'Internet Engineering Task Force (IETF), lequel accompagne le standard de chiffrement XML Encryption [XML-ENC]. La spécification pour la gestion des clés XML (XKMS) comprend deux parties : la spécification des services d'information de clés (X-KISS) et la spécification des services d'enregistrement de clés (X-KRSS).

[9] Ces protocoles ne s'appuient sur aucune infrastructure à clé publique particulière (telle que X.509) mais ils sont conçus pour être compatibles avec de telles infrastructures.

[10] Ce document définit les spécifications de services suivantes :

La spécification des services d'information de clés XML :
Un protocole permettant à une application de déléguer à un service le traitement des informations de clés associées à une signature XML, à un chiffrement XML, ou à un autre usage des éléments <ds:KeyInfo> des signatures XML [XML-SIG].
La spécification des services d'enregistrement de clés XML :
Un protocole permettant au détenteur d'un couple de clés d'enregistrer un couple de clés qui pourra ensuite être utilisé en relation avec un service d'information de clés XML ou une infrastructure à clé publique (PKI), telle que [X.509][PKIX].

1.1 Les conventions d'écriture et de conformité

[11] Cette spécification utilise un schéma XML [XML-schema] pour décrire le modèle de contenu.

[12] Les mots-clés DOI(VEN)T, NE DOI(VEN)T PAS, OBLIGATOIRE, DEVRA (DEVRONT), NE DEVRA (DEVRONT) PAS, DEVRAI(EN)T, NE DEVRAI(EN)T PAS, RECOMMANDÉ, PEU(VEN)T et OPTIONNEL dans cette spécification doivent s'interpréter comme décrit dans le document [RFC2119] :

[13] on ne DOIT seulement les employer que lorsqu'ils sont réellement nécessaires pour l'interopérabilité ou pour limiter un comportement potentiellement néfaste (par exemple, en limitant les retransmissions)

[14] Par conséquent, nous emploierons ces mots-clés en lettres capitales pour lever toutes ambiguïtés sur les conditions concernant les caractéristiques des protocoles et applications et le comportement, lesquels influent sur l'interopérabilité et la sécurité des mises en œuvre. Ces mots-clés (en capitales) ne seront pas employés pour décrire la grammaire XML, car les définitions du schéma décrivent sans ambiguïté ces conditions, et nous souhaitons réserver la primauté de ces termes aux descriptions en langue naturelle des protocoles et des caractéristiques. Par exemple, on pourrait décrire un attribut XML comme étant optionnel, et la conformité avec la spécification des espaces de nommage XML [XML-NS] comme étant OBLIGATOIRE.

1.2 La définition des termes

[17] Les termes suivants employés dans ce document ont le sens particulier indiqué ci-dessous :

[18] Service
Une application qui pourvoit des ressources calculatoires ou informationnelles à la demande. Un service peut être fourni par plusieurs serveurs physiques agissant comme une unité.

[20] Client
Une application qui effectue des requêtes auprès d'un service. Le concept de client est relatif à une demande de service : une application peut jouer le rôle de client pour certaines requêtes et de service pour d'autres.

[20a] Sécurité des données utiles"
L'emploi de mécanismes de sécurité de bout en bout, tel que XML DSIG, indépendants du mécanisme de transport (HTTP, TLS, SOAP, etc.).

1.3 Les espaces de nommage et les identificateurs des versions

[21] Il n'est pas prévu de numéro de version explicite dans cette syntaxe. Si une autre version se révélait nécessaire, elle utiliserait alors un espace de nommage différent. Les mises en œuvre de cette spécification (datée) DOIVENT utiliser l'adresse URI d'espace de nommage XML [XML-ns] suivante :

   http://www.w3.org/2002/03/xkms#

[22] Cet espace de nommage sert également de préfixe pour les identificateurs des algorithmes utilisés par cette spécification. Alors que les applications DOIVENT gérer XML et les espaces de nommage XML, les utilisations d'entités internes [XML] ou du préfixe d'espace de nommage xkms et des conventions concernant les valeurs par défaut ou la visibilité sont OPTIONNELLES : nous employons ces facilités techniques pour offrir des exemples compacts et lisibles.

[23] Dans ce document, certains préfixes d'espace de nommage représentent des espaces de nommage dans des fragments du schéma (apparaissant sur un fond jaune) comme ceci :

Préfixe  Spécification Schéma
xsi Schéma XML http://www.w3.org/2001/XMLSchema
ds Signature XML http://www.w3.org/2000/09/xmldsig#
xenc Chiffrement XML http://www.w3.org/2001/04/xmlenc#
ec Canonisation exclusive http://www.w3.org/2001/10/xml-exc-c14n#
xkms XKMS http://www.w3.org/2002/03/xkms#

[24] Pour la clarté, certains exemples de XML ne sont pas des documents complets et les déclarations d'espace de nommage peuvent être absentes des fragments XML.

[25] Dans tous les exemples (apparaissant sur un fond bleu clair) et dans le corps du texte, l'espace de nommage par défaut se rapporte à l'espace de nommage xkms. Cela signifie que les préfixes d'espace de nommage sont omis pour tous les noms d'élément et de type dans l'espace de nommage xkms.

[26] Ces noms d'espace de nommage sont déclarés dans le schéma XKMS de la manière suivante :

<?xml version="1.0"?>
<schema targetNamespace="http://www.w3.org/2002/03/xkms#"
      xmlns:xkms="http://www.w3.org/2002/03/xkms#"
      xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
      xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
      xmlns="http://www.w3.org/2001/XMLSchema"
      elementFormDefault="qualified" attributeFormDefault="unqualified">
   <import namespace="http://www.w3.org/2000/09/xmldsig#"
         schemaLocation="xmldsig-core-schema.xsd"/>
   <import namespace="http://www.w3.org/2001/04/xmlenc#"
         schemaLocation="xenc-schema.xsd"/>
   <annotation>
      <documentation xml:lang="fr">
         Schéma XML de la recommandation proposée XKMS 2.0 candidate 2005
      </documentation>
   </annotation>
   <!-- /Namespace -->
   ...
   <!-- Fin du schéma -->
</schema>

[27] Les adresses de protocole Internet (IP) et les noms du système de noms de domaine (DNS) sont volontairement choisis pour éviter les confusions avec les adresses et noms assignés. Toutes les adresses IP se trouvent dans la plage de réseau réservée et non routable 10.x.x.x. Tous les noms DNS se trouvent dans le domaine réservé example.com.

1.4 Vue d'ensemble d'un service d'information de clés (non normatif)

[28] Le protocole X-KISS permet à un client de déléguer tout ou partie des tâches nécessaires au traitement des éléments <ds:KeyInfo> des signatures XML [XML-SIG] à un service XKMS. Un objectif essentiel de la conception du protocole vise à minimiser la complexité des applications utilisant le standard XML Signature [XML-SIG]. En se posant comme client du service XKMS, l'application est dégagée de la complexité et de la syntaxe de l'infrastructure à clé publique sous-jacente, utilisée pour établir les relations de confiance, et elle peut s'appuyer sur une spécification différente telles que X.509/PKIX, SPKI ou PGP.

[29] Par conception, la spécification XML Signature [XML-SIG] n'impose pas l'utilisation d'une politique de confiance particulière. Le signataire d'un document n'est pas obligé de joindre des informations de clé mais il peut inclure un élément <ds:KeyInfo> qui désigne la clé en question, un nom de clé, un certificat X.509, un identificateur de clé PGP, etc. Autrement, on peut fournir un lien conduisant à l'emplacement où se trouvent les informations complètes de l'élément <ds:KeyInfo>.

[30] Les informations fournies par le signataire peuvent être insuffisantes en elles-mêmes pour effectuer une vérification cryptographique et pour décider de se fier à la clé de signature, ou elles peuvent être dans un format inutilisable pour le client. Par exemple :

[31] Dans le cas d'une opération de chiffrement :

1.5 Vue d'ensemble d'un service d'enregistrement de clés (non normatif)

[32] Le protocole X-KRSS décrit l'enregistrement et la gestion ultérieure des informations de clés publiques. Le client d'un service conforme peut demander au service d'enregistrement de lier ces informations à une clé publique. Les informations liées peuvent comprendre un nom, un identificateur ou les attributs étendus définis par la mise en œuvre.

[33] Le couple de clés auquel les informations sont liées peut être généré à l'avance par le client ou à la demande par le service. Le protocole d'enregistrement peut aussi servir à des opérations de gestion ultérieures, dont la récupération de la clé privée et la réémission, ou la révocation, de la liaison de clé.

[34] Le protocole permet l'authentification du demandeur et, au cas où le client génère le couple de clés, la preuve de possession (POP) de la clé privée. Il fournit un moyen pour communiquer la clé privée au client lorsque celle-ci est générée par le service d'enregistrement.

[35] Ce document définit des moyens afin d'enregistrer des clés RSA et DSA ainsi qu'un cadre pour étendre le protocole afin de gérer d'autres algorithmes de chiffrement, tel que Diffie-Hellman et les variantes de courbes elliptiques.

1.6 La structure de ce document

[36] La suite de ce document décrit la spécification des services d'information de clés XML et la spécification des services d'enregistrement de clés XML.

Section 2 : Les échanges de protocole
On y décrit les caractéristiques du protocole XKMS communes aux services XKMS.
Section 3 : La syntaxe des messages
On y décrit les éléments de syntaxe communs aux messages XKMS.
Section 4 : La description des services d'information de clés
On y décrit le comportement fonctionnel des services X-KISS.
Section 5 : Le jeu de messages des services d'information de clés
On y définit la sémantique des messages du protocole X-KISS.
Section 6 : La description des services d'enregistrement de clés
On y décrit le comportement fonctionnel des services X-KRSS.
Section 7 : Le jeu de messages des services d'enregistrement de clés
On y définit la sémantique des messages du protocole X-KRSS.
Section 8 : Les paramètres spécifiques des algorithmes cryptographiques
On y définit les paramètres et les formats de données spécifiques à l'emploi d'algorithmes de chiffrement particuliers.
Section 9 : La conformité
On y indique les critères de conformité des applications XKMS 2.0 conformes.
Section 10 : Les considérations sur la sécurité
On y décrit les considérations de sécurité concernant la mise en œuvre et le déploiement de la spécification XKMS.

2 Les échanges de protocole

[37] Les échanges de protocole XKMS consistent en une séquence d'un ou bien de deux couples requête-réponse.

[38] Les messages du protocole XKMS partagent un format commun permettant un transport. Une liaison au protocole de message SOAP [SOAP][XMLP] est fournie dans la deuxième partie →vf concernant les liaisons de protocole. On recommande aux développeurs d'applications XKMS de mettre en œuvre une gestion du protocole SOAP par-dessus HTTP pour des raisons d'interopérabilité. Toutefois, le protocole XKMS est indifférent au protocole de transport et il PEUT constituer une surcouche pour un transport SOAP.

[39] Les développeurs PEUVENT mettre en œuvre des liaisons avec d'autres protocoles, à discrétion.

[40] Aucune opération XKMS n'est idempotente, c'est-à-dire que toutes les requêtes XKMS PEUVENT amener un changement d'état.

[41] La deuxième partie →vf de cette spécification décrit les liaisons du protocole de sécurité XKMS.

[42] Le protocole XKMS consiste en couples de requêtes et réponses. La liaison de protocole XKMS permet un cycle requête-réponse supplémentaire, si nécessaire, pour tenir compte des cas tels que les réponses en cours et les requêtes en deux phases en prévention d'une attaque par répétition.

[43] Chaque message de réponse XKMS contient un code d'attribut MajorResult ResultMajor qui détermine si la réponse est finale ou bien si d'autres traitements sont nécessaires. Le protocole est décrit selon le formalisme CSP [CSP] comme suit :

Final = { Success, VersionMismatch, Sender, Receiver }
 
Request -> Result.Final
|
Request -> Result.Pending->PendingNotification->Request->Result.Final
|
Request -> Result.Represent->Request->Result.Final

[44] Les sections suivantes décrivent le protocole des messages et les étapes du traitement des messages observées par les deux parties pour chacun des messages.

2.1 Tous les messages

[45] Les étapes de traitement suivantes sont observées pour tous les messages, qu'il s'agisse d'une requête ou d'une réponse :

Génération
L'attribut Id est affecté d'une valeur unique générée aléatoirement
L'attribut Service est affecté de la valeur de l'adresse URI vers laquelle la requête XKMS est dirigée
Une signature d'authentification est générée (si nécessaire).
Traitement
La valeur de l'attribut Service est vérifiée
La signature d'authentification est vérifiée (si nécessaire).

2.1.1 Exemple

<?xml version="1.0" encoding="utf-8"?>
<MessageAbstractType Id="1noOYHt5Lx7xUuizWZLOMw=="
      Service="http://www.example.org/XKMS"
      xmlns="http://www.w3.org/2002/03/xkms#" />

2.2 Les types de requête

[46] La spécification XKMS définit trois types de requête :

Les requêtes X-KISS
Une requête de localisation (LocateRequest) ou de validation (ValidateRequest), comme l'indique la spécification des services d'information de clés.
Les requêtes X-KRSS
Une requête d'enregistrement (RegisterRequest), de réémission (ReissueRequest), de révocation (RevokeRequest) ou de récupération (RecoverRequest), comme l'indique la spécification des services d'enregistrement de clés.
Les requêtes composées
Une requête composée consiste en un ensemble d'une ou de plusieurs requêtes X-KISS ou X-KRSS.

[47] Le protocole XKMS définit un certain nombre d'options de protocole, comprenant le traitement asynchrone, les requêtes en deux phases et les requêtes composées. Le client indique les options de protocole qu'il reconnaît, relativement à une requête spécifique, au travers de l'élément ResponseMechanism dans la requête.

[48] Le mécanisme par lequel le service indique les options de protocole qu'il accepte n'est pas traité dans ce document. Si le mécanisme en question emploie des identificateurs à base d'adresse URI pour cet usage, il DEVRAIT employer les identificateurs suivants :

Traitement asynchrone
http://www.w3.org/2002/03/xkms#Asynchronous
Protocole de requête à deux phases
http://www.w3.org/2002/03/xkms#Represent
Requêtes et réponses composées
http://www.w3.org/2002/03/xkms#Compound

2.3 Les réponses

[49] Toutes les réponses XKMS contiennent un code de résultat comprenant un composant majeur et un composant mineur. Si un service applique une option de traitement de protocole, le client en est informé par le biais de la valeur du code de l'attribut MajorResult ResultMajor de la réponse.

2.4 Le traitement synchrone et asynchrone

[50] Le protocole XKMS gère deux modes de traitement : un mode synchrone et un mode asynchrone.

[51] Un client PEUT aviser un service qu'il acceptera le traitement asynchrone d'une requête en indiquant une valeur Pending pour l'attribut ResponseMechanism. Un service XKMS recevant une requête contenant un attribut ResponseMechanism avec la valeur Pending PEUT répondre soit de manière synchrone, soit asynchrone. Si le service doit répondre de manière asynchrone, il avise le client de ce fait, que la valeur de réponse sera retournée ultérieurement, au moyen d'un attribut MajorResult ResultMajor avec la valeur de code Pending.

[52] Un service XKMS NE DOIT PAS retourner d'attribut MajorResult ResultMajor avec la valeur Pending, sauf si la requête correspondante contenait un attribut ResponseMechanism avec la valeur Pending. Si un service XKMS reçoit une requête qui ne peut être traitée de manière synchrone et que l'attribut ResponseMechanism n'avait pas la valeur Pending, alors il renverra un attribut MajorResult ResultMajor avec la valeur de code Receiver et un attribut MinoResult ResultMinor avec la valeur de code NotSynchronous.

[53] On PEUT utiliser le traitement asynchrone afin de permettre l'intervention d'un administrateur au cours du traitement de la requête. Par exemple, un administrateur peut être amené à vérifier et approuver toutes les requêtes d'enregistrement X-KRSS avant que celles-ci ne soient traitées.

2.4.1 Le cycle requête-réponse synchrone

[54] Le traitement d'une requête-réponse synchrone se déroule de la manière suivante :

Génération du message de requête par le requérant
Les attributs Nonce et OriginalRequestId sont absents
La valeur Pending de l'attribut ResponseMechanism PEUT être spécifiée mais le service l'ignorera
Traitement du message de requête par le service
Vérifier que la requête satisfait à la politique des autorisations du service
Traiter la requête jusqu'à réalisation
Génération du message de réponse par le service
L'attribut RequestId est affecté de la valeur de l'attribut Id du message de requête
L'attribut Nonce est absent
L'attribut MajorResult ResultMajor reçoit l'une des valeurs du jeu Final
Traitement du message de réponse par le requérant
La valeur de l'attribut RequestId est vérifiée

2.4.2 Exemple

2.4.2.1 Requête

<?xml version="1.0" encoding="utf-8"?>
<LocateRequest Id="I6d995b8d05a9a2ce0573d29e32ab9441"
      Service="http://www.example.org/XKMS"
      xmlns="http://www.w3.org/2002/03/xkms#">
  <QueryKeyBinding />
</LocateRequest>

2.4.2.2 Réponse

<?xml version="1.0" encoding="utf-8"?>
<LocateResult Id="I089b18dc1a520b26e2e6689dd3a5a820"
      Service="http://www.example.org/XKMS"
      ResultMajor="http://www.w3.org/2002/03/xkms#Success"
      RequestId="I6d995b8d05a9a2ce0573d29e32ab9441"
      xmlns="http://www.w3.org/2002/03/xkms#" />

2.5 Le traitement asynchrone

[55] Le traitement asynchrone consiste en une séquence de couples requête-réponse ; une requête initiale qui spécifie les valeurs de requête, zéro (ou plus) requête(s) de statut et une requête en instance, laquelle obtiendra le résultat de l'opération. Le client peut émettre des requêtes de statut afin de sonder le statut d'une opération asynchrone, indépendamment de l'usage du mécanisme de notification annoncé (par le client) dans la requête initiale.

2.5.1 La requête initiale

[56] Le message de la requête initiale est traité de la manière suivante :

Génération du message de la requête initiale par le requérant
Les attributs Nonce et OriginalRequestId sont absents
L'attribut ResponseMechanism DOIT avoir la valeur de code Pending
Traitement du message de la requête initiale par le service
Demander le planning du traitement asynchrone
Génération du message de la réponse initiale par le service
L'attribut RequestId est affecté de la valeur de l'attribut Id du message de la requête initiale
L'attribut Nonce est absent
L'attribut ResultMajor reçoit la valeur de code Pending
Traitement du message de la réponse initiale par le requérant
Enregistrer la requête comme étant en instance de réalisation, sonder le statut du traitement et/ou attendre une notification

2.5.2 La requête de statut

[56a] Le client peut sonder le statut de l'opération asynchrone de la manière suivante :

Génération du message de la requête de statut par le requérant
L'élément pour la requête est StatusRequest
L'attribut OriginalRequestId est affecté de la valeur de l'attribut Id du message de la requête initiale
L'attribut ResponseId est affecté de la valeur de l'attribut Id du message de la réponse initiale
Traitement du message de la requête de statut par le service
Identifier la requête en instance en utilisant les valeurs des attributs OriginalRequestId et ResponseId.
Génération du message de la réponse de statut par le service
L'attribut RequestId est affecté de la valeur de l'attribut Id du message de la requête de statut
L'attribut Nonce est absent
Traitement du message de la réponse de statut par le requérant
Pour les messages non composés, c'est l'attribut ResultMajor qui indiquera le statut de l'opération. Pour les messages composés, ce sont les valeurs des attributs Success, Failure et Pending qui indiqueront en outre le nombre des requêtes internes pour le statut correspondant.

2.5.3 Les requêtes en instance

[57] Le client détermine, au travers d'une notification ou d'un sondage, si l'opération requise a été réalisée et demande alors le transfert des valeurs résultats en émettant un message de requête en instance de la manière suivante :

Génération du message de la requête en instance par le requérant
L'élément pour cette requête est PendingRequest
L'attribut OriginalRequestId est affecté de la valeur de l'attribut Id du message de la requête initiale
L'attribut ResponseId est affecté de la valeur de l'attribut Id du message de la réponse initiale
Traitement du message de la requête en instance par le service
Accorder la requête en instance à une réponse en instance
Génération du message de la réponse en instance par le service
L'attribut RequestId est affecté de la valeur de l'attribut Id du message de la requête en instance
L'attribut Nonce est absent
Traitement du message de la réponse en instance par le requérant
Si l'attribut MajorResult ResultMajor est affecté d'une valeur non finale, considérer celui-ci comme valant Failure

[58] Le client PEUT demander le transfert des valeurs résultats avant la fin du traitement. Auquel cas, le service répond à la requête en instance par un attribut MajorResult ResultMajor avec le code de valeur Pending.

2.5.4 Exemple

2.5.4.1 Requête

<?xml version="1.0" encoding="utf-8"?>
<LocateRequest Id="I6227979ae4073f2b3b145db7a488ce16"
      Service="http://www.example.org/XKMS"
      xmlns="http://www.w3.org/2002/03/xkms#">
  <ResponseMechanism>http://www.w3.org/2002/03/xkms#Pending</ResponseMechanism>
  <PendingNotification Mechanism="urn:ietf:rfc:822" 
      Identifier="mailto:alice@example.org">
  <QueryKeyBinding />
</LocateRequest>

2.5.4.2 Réponse

<?xml version="1.0" encoding="utf-8"?>
<LocateResult Id="I98366e407a2a78dff79687dbdb4d974c"
      Service="http://www.example.org/XKMS" 
      ResultMajor="http://www.w3.org/2002/03/xkms#Pending"
      RequestId="I6227979ae4073f2b3b145db7a488ce16"
      xmlns="http://www.w3.org/2002/03/xkms#" />

2.5.4.3 Notification

Le service XKMS avise le client de la fin du traitement de la requête en utilisant le mécanisme de notification indiqué par l'élément <PendingNotification>.

2.5.4.4 Requête en instance

<?xml version="1.0" encoding="utf-8"?>
<PendingRequest Id="I6045ff8b2eb204edb538be1fa22e340a"
      Service="http://www.example.org/XKMS"
      OriginalRequestId="I6227979ae4073f2b3b145db7a488ce16"
      ResponseId="I98366e407a2a78dff79687dbdb4d974c"
      xmlns="http://www.w3.org/2002/03/xkms#" />

2.5.4.5 Réponse

<?xml version="1.0" encoding="utf-8"?>
<LocateResult Id="I4da52fc78e0391a11257d64926cd184c"
      Service="http://www.example.org/XKMS"
      ResultMajor="http://www.w3.org/2002/03/xkms#Success"
      RequestId="I6045ff8b2eb204edb538be1fa22e340a"
      xmlns="http://www.w3.org/2002/03/xkms#" />

2.6 Le protocole de requête à deux phases

[59] Les requêtes XKMS peuvent emprunter un protocole de requête à deux phases en prévention d'une attaque en déni de service. Le protocole de requête à deux phases permet au service d'effectuer une authentification superficielle de la source d'une requête XKMS ; précisément, le service détermine si le client est capable de lire les messages envoyés à l'adresse source prétendue. Bien que ce mécanisme n'offre qu'une forme d'authentification faible, il empêche les attaques en déni de service en forçant le service à effectuer une forme d'authentification consommatrice de ressource telle que la vérification d'une signature digitale.

[60] Les deux phases du protocole se déroulent de la manière suivante :

[61] Dans la première phase, le requérant présente la requête et le service répond par un attribut MajorResult ResultMajor avec la valeur de code Represent en présentant un ticket.

[62] Dans la seconde phase, le requérant présente à nouveau la requête originale accompagnée du ticket.

[63] Un client PEUT aviser le service qu'il gère le protocole de requête à deux phases en indiquant une valeur de code Represent pour l'attribut ResponseMechanism. Le service XKMS avise le client que l'utilisation du protocole de requête à deux phases est obligatoire en indiquant une valeur de code Represent pour l'attribut MajorResult ResultMajor.

[64] Un service XKMS NE DOIT PAS retourner d'attribut MajorResult ResultMajor avec une valeur de code Represent à moins que la requête correspondante n'ait contenu un attribut ResponseMechanism avec la valeur Represent. Si un service XKMS impose l'utilisation du protocole de requête à deux phases et que la requête correspondante ne contient pas d'attribut ResponseMechanism avec la valeur Represent, alors il renverra un attribut ResultMajor avec la valeur de code Sender et un attribut ResultMinor avec la valeur de code RepresentRequired.

[65] Le protocole de requête à deux phases présente quelques similitudes avec le traitement asynchrone d'une requête. Les deux mécanismes introduisent un cycle de protocole supplémentaire mais ce cycle revêt des objectifs différents. Le but du traitement asynchrone est de permettre l'introduction d'un délai entre la requête initiale et le retour du résultat. En revanche, dans le protocole de requête à deux phases, il n'y a aucun délai entre la première requête et la première réponse, ou entre la première réponse et la seconde requête. Le but du protocole de requête à deux phases est de donner la possibilité au service de se protéger d'une attaque en déni de service en lui permettant de réaliser une authentification superficielle de la source de la requête.

[66] Le service DEVRAIT vérifier que la valeur du ticket, dans la requête de la deuxième phase, a bien été générée récemment et par lui-même. Le service PEUT vérifier que la valeur du ticket n'a pas déjà fait l'objet d'une réponse. La construction effective de la valeur d'un ticket n'est pas traitée dans cette spécification et on peut la choisir selon les impératifs propres d'un site particulier. La section La construction des valeurs des tickets décrit plusieurs techniques, l'une permettant de réduire ou d'éviter l'obligation de conserver un état du serveur pour satisfaire aux conditions d'utilisation du ticket.

2.6.1 Les étapes du traitement

[67] Dans la première phase du protocole à deux phases, les étapes du traitement, spécifiées pour une seule phase, s'enchaînent avec les exceptions suivantes :

Génération du message de requête de la phase 1 par le requérant
L'attribut ResponseMechanism DOIT avoir la valeur de code Represent
Traitement du message de requête de la phase 1 par le service
Le service décide d'imposer un traitement en deux phases
La requête N'EST PAS traitée
Génération du message de réponse de la phase 2 par le service
L'attribut RequestId est affecté de la valeur de l'attribut Id du message de la requête de la phase 1
La valeur du ticket (attribut Nonce) est fixée selon les conditions de protection contre les répétitions du service
L'attribut MajorResult ResultMajor est affecté de la valeur de code Represent
Traitement du message de réponse de la phase 1 par le requérant
Aller à la phase 2

[68] Dans la deuxième phase du protocole à deux phases, les étapes du traitement, spécifiées pour une seule phase, s'enchaînent avec les exceptions suivantes :

Génération du message de requête de la phase 2 par le requérant
L'attribut OriginalRequestId est affecté de la valeur de l'attribut Id du message de la requête de la phase 1
L'attribut Nonce est affecté de la valeur de l'attribut Nonce du message de réponse de la phase 1
Traitement du message de requête de la phase 2 par le service
Vérifier la valeur de l'attribut Nonce
Vérifier que la requête satisfait à la politique d'autorisation du service
Traiter la requête jusqu'à réalisation
Génération du message de réponse de la phase 2 par le service
L'attribut RequestId est affecté de la valeur de l'attribut Id du message de requête de la phase 2
L'attribut Nonce est absent
L'attribut MajorResult ResultMajor est affecté d'une valeur de résultat finale
Traitement du message de réponse de la phase 2 par le requérant
Si l'attribut MajorResult ResultMajor est affecté d'une valeur non finale, considérer celui-ci comme valant Failure

2.6.2 La construction des valeurs des tickets

[69] Les valeurs des tickets peuvent se construire comme le service l'entend. Il peut se révéler utile de construire les tickets de façon à ce que le service puisse déterminer, automatiquement et pratiquement, qu'ils ont été générés par le serveur à un moment précis selon le modèle suivant.

[70] Le ticket est construit à partir de l'heure courante du service, d'un numéro de série unique et d'une clé secrète, connue seulement du service, utilisant un code d'authentification du message (MAC) de la manière suivante (le signe + indique une concaténation) :

[71] ticket = heure + n° de série + M ( heure + n° série , k )

[72] Le service peut restreindre l'intervalle de temps pendant lequel les attaques par répétitions sont probables, en rejetant les valeurs de ticket qui indiquent une valeur de temps inacceptable ou une valeur MAC incorrecte.

[73] Le service peut prévenir les attaques par répétition en effectuant un suivi des numéros de série pour lesquels des réponses ont déjà été données, en utilisant la valeur de construction temporelle du ticket pour restreindre l'intervalle pendant lequel le numéro de série est suivi.

[74] La valeur du ticket peut être cryptée afin d'éviter les fuites d'information telle que la valeur du numéro de série, qui est susceptible d'intéresser un attaquant.

2.6.3 Exemple

2.6.3.1 Requête 1

<?xml version="1.0" encoding="utf-8"?>
<LocateRequest Id="Ia1d6ca7a067fdd545f1a1396d2f26779"
      Service="http://www.example.org/XKMS"
      xmlns="http://www.w3.org/2002/03/xkms#">
  <ResponseMechanism>http://www.w3.org/2002/03/xkms#Represent</ResponseMechanism>
  <QueryKeyBinding />
</LocateRequest>

2.6.3.2 Réponse 1

<?xml version="1.0" encoding="utf-8"?>
<LocateResult Id="Idbc77142059a3a51c9eccd2425d77757"
      Service="http://www.example.org/XKMS"
      Nonce="Rj2BoUZM7PisPX2ytSAAWA==" 
      ResultMajor="http://www.w3.org/2002/03/xkms#Represent"
      RequestId="Ia1d6ca7a067fdd545f1a1396d2f26779"
      xmlns="http://www.w3.org/2002/03/xkms#" />

2.6.3.3 Requête 2

<?xml version="1.0" encoding="utf-8"?>
<LocateRequest Id="I47804adaec32e34afeecdb51f3e0f765"
      Service="http://www.example.org/XKMS"
      Nonce="Rj2BoUZM7PisPX2ytSAAWA=="
      OriginalRequestId="Ia1d6ca7a067fdd545f1a1396d2f26779"
      xmlns="http://www.w3.org/2002/03/xkms#">
  <QueryKeyBinding />
</LocateRequest>

2.6.3.4 Réponse 2

<?xml version="1.0" encoding="utf-8"?>
<LocateResult Id="I3b0111d2232507a56444c1bc85409a94"
      Service="http://www.example.org/XKMS"
      ResultMajor="http://www.w3.org/2002/03/xkms#Success"
      RequestId="I47804adaec32e34afeecdb51f3e0f765"
      xmlns="http://www.w3.org/2002/03/xkms#" />

2.7 Le protocole à deux phases avec traitement asynchrone

[75] Le protocole à deux phases peut se combiner à un traitement asynchrone. Auquel cas, l'opération comprendra trois cycles comme suit :

[76] Le traitement du message a lieu comme décrit précédemment avec les exceptions suivantes.

2.8 Les requêtes et réponses composées

[77] Un service XKMS PEUT mettre en œuvre un traitement des requêtes composées. Une requête composée permet d'effectuer plusieurs requêtes XKMS en même temps. Une requête composée comprend une requête externe et une (ou plusieurs) requête(s) interne(s). Les requêtes internes ne suivent aucun ordre implicite. La sémantique de réunir un ensemble de requêtes en une requête composée est exactement la même que si chaque requête individuelle de l'ensemble avait été faite séparément et simultanément.

[78] La réponse à une requête composée est une réponse composée. Une réponse composée comprend une réponse externe et zéro (ou plus) réponse(s) interne(s). Si la valeur de l'attribut ResultMajor de la réponse externe est Success, alors la réponse composée DEVRAIT contenir un élément de réponse interne correspondant à chaque élément de requête interne de la requête composée. Si la valeur de l'attribut ResultMajor de la réponse externe n'est pas Success, alors la réponse NE DOIT PAS contenir une quelconque réponse interne. Si une réponse composée a un attribut ResultMajor externe de valeur Success mais ne contient pas de réponse correspondant à une requête interne, alors cette requête interne est censée avoir échoué.

[79] Un service XKMS PEUT gérer une utilisation du protocole à deux phases sur la requête externe d'une réponse composée. Le protocole à deux phases NE DEVRAIT PAS être employé sur une réponse interne. Si une requête interne indique un attribut ResponseMechanism avec la valeur Represent, alors celle-ci DEVRAIT être ignorée.

[80] Un service XKMS PEUT gérer l'utilisation d'un traitement asynchrone conjointement à une requête composée. Le traitement asynchrone PEUT opérer sur la requête composée comme un tout, sur les requêtes individuelles internes ou sur toutes.

[81] Si un traitement asynchrone doit avoir lieu sur une requête composée comme un tout, alors la requête externe indique un attribut ResponseMechanism de valeur Pending. Si le service décide de renvoyer une réponse asynchrone, il retourne alors une réponse composée avec un attribut ResultMajor de valeur Pending. Lorsque le service a terminé le traitement, par détermination au travers d'un sondage ou d'une notification, le client émet un message de requête en instance (élément PendingRequest) pour la requête externe à laquelle le service répond par une réponse composée, en retournant soit les réponses internes correspondant aux requêtes internes originales, soit un signal d'erreur.

[82] Si un traitement asynchrone doit avoir lieu sur les requêtes internes individuelles, chaque requête interne pour laquelle une réponse asynchrone est attendue indique un attribut ResponseMechanism de valeur Pending. Si le service décide de renvoyer une réponse asynchrone à une requête interne, il retourne alors une réponse composée avec un attribut ResultMajor externe de valeur Success et un attribut ResultMajor interne de valeur Pending pour les requêtes pour lesquelles une réponse asynchrone doit être émise. Un service PEUT renvoyer des réponses synchrones et asynchrones en une seule réponse composée.

[83] Étant donné que la sémantique d'une requête composée est exactement la même que si chaque requête interne avait été faite séparément, un client PEUT émettre des requêtes en instance séparées afin d'obtenir les résultats des requêtes internes d'une requête composée précédente.

2.8.1 Exemple

2.8.1.1 Requête 1

<?xml version="1.0" encoding="utf-8"?>
<CompoundRequest Id="I264f5da49b1ff367d4e7aef1f7a1df1a"
      Service="http://www.example.org/XKMS"
      xmlns="http://www.w3.org/2002/03/xkms#">
  <LocateRequest Id="I8c26be5f1b4dd228b43fb6eaee285faa"
        Service="http://www.example.org/XKMS">
    <RespondWith>http://www.w3.org/2002/03/xkms#KeyValue</RespondWith>
    <QueryKeyBinding>
      <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
        <X509Data>
          <X509Certificate>
            MIICEDCCAX2gAwIBAgIQimXeUAxYJbJMady9vV1bLjAJBgUrDgMCHQUAMBIxEDA
            OBgNVBAMTB1Rlc3QgQ0EwHhcNMDMwODE1MDcwMDAwWhcNMDUwODE1MDY1OTU5Wj
            ArMSkwJwYDVQQDEyBBbGljZSBBYXJkdmFyayBPPUFsaWNlIENvcnAgQz1VUzCBn
            zANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA0nIsmR+aVW2egl5MIfOKy4HuMKkk
            9AZ/IQuDLVPlhzOfgngjVQCjr8uvmnqtNu8HBupui8LgGthO6U9D0CNT5mbmhIA
            ErRADUMIAFsi7LzBarUvNWTqYNEJmcHsAUZdrdcDrkNnG7SzbuJx+GDNiHKVDQg
            gPBLc1XagW20RMvokCAwEAAaNWMFQwDQYDVR0KBAYwBAMCBkAwQwYDVR0BBDwwO
            oAQAaVOkaVLLKoFmLN37pC8uqEUMBIxEDAOBgNVBAMTB1Rlc3QgQ0GCEC4MndUX
            jPG1TZxVKg+HutAwCQYFKw4DAh0FAAOBgQABU91ka7IlkXCfv4Zh2Ohwgg2yObt
            Y3+6C/BTFGrOEBJDy+DoxJ/NuBF18w3rrrR18xE6jNKYLCQb8zUGk4QOG5Y+HT/
            QTTFvWkiOLXcpTuhnOhXatr42FoYpDkjx2QWK+J5Q2l/Rgjgc/0ZV8U/kD8UuRk
            Xp4AZh7QsiX8AcO0w==
          </X509Certificate>
        </X509Data>
      </KeyInfo>
      <KeyUsage>http://www.w3.org/2002/03/xkms#Signature</KeyUsage>
    </QueryKeyBinding>
  </LocateRequest>
  <LocateRequest Id="If8e63d729384ad35498e7b65b3dc785e"
        Service="http://www.example.org/XKMS">
    <RespondWith>http://www.w3.org/2002/03/xkms#KeyName</RespondWith>
    <RespondWith>http://www.w3.org/2002/03/xkms#KeyValue</RespondWith>
    <RespondWith>http://www.w3.org/2002/03/xkms#X509Cert</RespondWith>
    <RespondWith>http://www.w3.org/2002/03/xkms#X509Chain</RespondWith>
    <RespondWith>http://www.w3.org/2002/03/xkms#PGPWeb</RespondWith>
    <RespondWith>http://www.w3.org/2002/03/xkms#PGP</RespondWith>
    <QueryKeyBinding>
      <KeyUsage>http://www.w3.org/2002/03/xkms#Encryption</KeyUsage>
      <UseKeyWith Application="urn:ietf:rfc:2440"
            Identifier="bob@example.com" />
      <UseKeyWith Application="urn:ietf:rfc:2633"
            Identifier="bob@example.com" />
    </QueryKeyBinding>
  </LocateRequest>
</CompoundRequest>

2.8.1.2 Réponse 1

<?xml version="1.0" encoding="utf-8"?>
<CompoundResult Id="If2d286d4a542bd92989aa606d9f1a5ca"
      Service="http://www.example.org/XKMS"
      ResultMajor="http://www.w3.org/2002/03/xkms#Success"
      RequestId="I264f5da49b1ff367d4e7aef1f7a1df1a"
      xmlns="http://www.w3.org/2002/03/xkms#">
  <LocateResult Id="I69044d458e0bceef5f78c79c32fa9ddf"
        Service="http://www.example.org/XKMS"
        ResultMajor="http://www.w3.org/2002/03/xkms#Success"
        RequestId="I8c26be5f1b4dd228b43fb6eaee285faa">
    <UnverifiedKeyBinding Id="I8f7367375ac134872eab7acf42a8d1bd">
      <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
        <KeyValue>
          <RSAKeyValue>
            <Modulus>
              0nIsmR+aVW2egl5MIfOKy4HuMKkk9AZ/IQuDLVPlhzOfgngjVQCjr8uvmnqtNu8HBupui8LgG
              thO6U9D0CNT5mbmhIAErRADUMIAFsi7LzBarUvNWTqYNEJmcHsAUZdrdcDrkNnG7SzbuJx+GD
              NiHKVDQggPBLc1XagW20RMvok=
            </Modulus>
            <Exponent>AQAB</Exponent>
          </RSAKeyValue>
        </KeyValue>
      </KeyInfo>
      <KeyUsage>http://www.w3.org/2002/03/xkms#Signature</KeyUsage>
      <KeyUsage>http://www.w3.org/2002/03/xkms#Encryption</KeyUsage>
      <KeyUsage>http://www.w3.org/2002/03/xkms#Exchange</KeyUsage>
      <UseKeyWith Application="urn:ietf:rfc:2633"
            Identifier="alice@example.com" />
    </UnverifiedKeyBinding>
  </LocateResult>
  <LocateResult Id="Ic3d02a8b1f63ba694a8fad11a74fb499"
        Service="http://www.example.org/XKMS"
        ResultMajor="http://www.w3.org/2002/03/xkms#Success"
        RequestId="If8e63d729384ad35498e7b65b3dc785e">
    <UnverifiedKeyBinding Id="I42604b6f40f46b74b5c30077100fe8e9">
      <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
        <KeyValue>
          <RSAKeyValue>
            <Modulus>
              3FFtWUsvEajQt2SeSF+RvAxWdPPh5GSlQnp8SDvvqvCwE6PXcRWrIGmV7twNf2T
              UXCxYuztUUClMIy14B0Q+k1ej2nekmYL7+Ic3DDGVFVaYPoxaRY0Y2lV8tOreyn
              WegpFbITXc8V6Y02QfR5O7Pn1/10ElslaF/TF8MQGqYE8=
            </Modulus>
            <Exponent>AQAB</Exponent>
          </RSAKeyValue>
        </KeyValue>
        <X509Data>
          <X509Certificate>
            MIICCTCCAXagAwIBAgIQe0Sk4xr1VolGFFNMkCx07TAJBgUrDgMCHQUAMBIxEDA
            OBgNVBAMTB1Rlc3QgQ0EwHhcNMDMwODE1MDcwMDAwWhcNMDUwODE1MDY1OTU5Wj
            AkMSIwIAYDVQQDExlCb2IgQmFrZXIgTz1Cb2IgQ29ycCBDPVVTMIGfMA0GCSqGS
            Ib3DQEBAQUAA4GNADCBiQKBgQDcUW1ZSy8RqNC3ZJ5IX5G8DFZ08+HkZKVCenxI
            O++q8LATo9dxFasgaZXu3A1/ZNRcLFi7O1RQKUwjLXgHRD6TV6Pad6SZgvv4hzc
            MMZUVVpg+jFpFjRjaVXy06t7KdZ6CkVshNdzxXpjTZB9Hk7s+fX/XQSWyVoX9MX
            wxAapgTwIDAQABo1YwVDANBgNVHQoEBjAEAwIGQDBDBgNVHQEEPDA6gBABpU6Rp
            UssqgWYs3fukLy6oRQwEjEQMA4GA1UEAxMHVGVzdCBDQYIQLgyd1ReM8bVNnFUq
            D4e60DAJBgUrDgMCHQUAA4GBAF4jP1gGDbaq3rg/Vo3JY7EDNTp0HmwLiPMLmdn
            B3WTIGFcjS/jZFzRCbvKPeiPTZ6kRkGgydFOuCo5HMAxIks/LtnKFd/0qYT+AOD
            q/rCrwSx+F+Ro2rf9tPpja9o7gANqxs6Pm7f1QSPZO57bT/6afiVm7NdaCfjgMp
            hb+XNyn
          </X509Certificate>
          <X509Certificate>
            MIIB9zCCAWSgAwIBAgIQLgyd1ReM8bVNnFUqD4e60DAJBgUrDgMCHQUAMBIxEDA
            OBgNVBAMTB1Rlc3QgQ0EwHhcNMDMwODE1MDcwMDAwWhcNMTAwODE1MDcwMDAwWj
            ASMRAwDgYDVQQDEwdUZXN0IENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBg
            QCn23HHp+HtXpiyKVSDtdE3dO0r0oLB/H9sxUEkeXB8oMxwbhdcizWH92zrtm1V
            fVtxkfmwF14ZXoyDZHeZXuCOtAfz/mW6s2gmfD45TfFFVGksDGVRNK5XmKXA5sE
            C51RCvaxzGBdGDlCuVPqX7Cq3IcZpRU1IXbi5YzGwV7j6LwIDAQABo1YwVDANBg
            NVHQoEBjAEAwIHgDBDBgNVHQEEPDA6gBABpU6RpUssqgWYs3fukLy6oRQwEjEQM
            A4GA1UEAxMHVGVzdCBDQYIQLgyd1ReM8bVNnFUqD4e60DAJBgUrDgMCHQUAA4GB
            ABDYD4Fwx2dscu+BgYcZ+GoQQtCJkwJEXytb4zlNl7HLFKbXSw4m0blQquIsfsi
            QgFYAQBXSbu7aeUqqmSGHvILu3BGwVOKjxbHfcM4/MefuTtpOpCN40wy3YwwngD
            tHTaIqm8NwS966PE+W9f8kD70q5FNwf+GF/lX9qGc/x435
          </X509Certificate>
        </X509Data>
      </KeyInfo>
      <KeyUsage>http://www.w3.org/2002/03/xkms#Signature</KeyUsage>
      <KeyUsage>http://www.w3.org/2002/03/xkms#Encryption</KeyUsage>
      <KeyUsage>http://www.w3.org/2002/03/xkms#Exchange</KeyUsage>
      <UseKeyWith Application="urn:ietf:rfc:2633"
            Identifier="bob@example.com" />
    </UnverifiedKeyBinding>
  </LocateResult>
</CompoundResult>

2.9 La sécurité

[84] Les questions de sécurité auxquelles un service XKMS est tenu de répondre dépendent de la couverture particulière du service. Par exemple, un service de localisation XKMS gratuit peut ne pas imposer de contrôles pour l'authentification de la requête afin de prévenir les attaques par répétition des requêtes tandis qu'un service de validation payant pourrait le faire. Le mise en place des mesures pour améliorer la sécurité est traitée dans la deuxième partie →vf qui décrit les renforts de sécurité à apporter aux points suivants :

[85] L'usage des mesures de sécurité est abordé plus loin dans la section Les questions de sécurité .

3 La syntaxe des messages

3.1 La base des messages

3.1.1 Le type MessageAbstractType

[86] Le type abstrait MessageAbstractType est celui à partir duquel tous les types d'élément des messages XKMS sont dérivés. Le type abstrait MessageAbstractType contient l'élément les éléments et les attributs suivants :

<ds:Signature> (optionnel)
Une signature XML [XML-SIG] en mode enveloppé. La portée de la signature recouvre le message de requête entier (c'est-à-dire, l'élément dérivé de MessageAbstractType) et elle est définie en utilisant une référence à l'attribut Id indiqué dans le type abstrait MessageAbstractType.
<MessageExtension> (un nombre quelconque)
Un élément d'extension dérivé du type MessageExtensionAbstractType.
<OpaqueClientData> (optionnel)
Une collection de données, spécifiée par le client, qui est opaque pour le service. Un service XKMS DEVRAIT retourner la valeur de l'élément <OpaqueClientData>, dans une requête, non modifiée dans une réponse avec un code de statut Success.
Id (obligatoire)
Un identificateur unique généré par l'initiateur.
Service (obligatoire)
L'adresse URI du service Web auquel la requête est adressée.
Nonce (optionnel)
Des données chiffrées aléatoires utilisées pour se prémunir d'une attaque par répétition.

[87] Le schéma suivant définit le type abstrait MessageAbstractType :

   <!-- MessageAbstractType -->
   <complexType name="MessageAbstractType" abstract="true">
      <sequence>
         <element ref="ds:Signature" minOccurs="0"/>
         <element ref="xkms:MessageExtension" minOccurs="0"
               maxOccurs="unbounded"/>
         <element ref="xkms:OpaqueClientData" minOccurs="0"/>
      </sequence>
      <attribute name="Id" type="ID" use="required"/>
      <attribute name="Service" type="anyURI" use="required"/>
      <attribute name="Nonce" type="base64Binary" use="optional"/>
   </complexType>
   <!-- /MessageAbstractType -->

3.1.2 L'élément <ds:Signature>

[88] Une signature XML [XML-SIG] en mode enveloppé. La portée de la signature recouvre le message de requête entier (c'est-à-dire, l'élément dérivé de MessageAbstractType) et elle est définie en utilisant une référence à l'attribut Id indiqué dans le type abstrait MessageAbstractType. On NE DOIT PAS utiliser l'identificateur vide "".

[89] La validation des signatures XML DOIT être effectuée indépendamment de tout contexte XML ancestral du message. Cela peut être réalisé :

[90] Pour des raisons d'interopérabilité, les mises en œuvre XKMS DOIVENT gérer la canonisation XML exclusive.

[91] L'élément <ds:Signature> est défini dans la spécification XML Signature [XML-SIG].

3.1.3 L'élément <MessageExtension>

[92] L'élément <MessageExtension> est un élément abstrait du type abstrait MessageExtensionAbstractType. Les mises en œuvre peuvent spécifier des sous-classes du type MessageExtensionAbstractType pour définir des éléments d'extension de message pouvant s'appliquer à n'importe quel message XKMS.

[93] Le schéma suivant définit l'élément MessageExtension :

   <!-- MessageExtension -->
   <element name="MessageExtension" type="xkms:MessageExtensionAbstractType"
         abstract="true"/>
   <complexType name="MessageExtensionAbstractType" abstract="true"/>
   <!-- /MessageExtension -->

3.1.4 L'élément <OpaqueClientData>

[94] L'élément <OpaqueClientData> contient des données, spécifiées par le client, qui sont opaques pour le service. Un service XKMS DEVRAIT retourner la valeur d'un élément <OpaqueClientData> indiqué dans une requête (y compris ses enfants), sans la modifier dans la réponse correspondante.

[95] Un client PEUT utiliser les données opaques d'un client en conjonction avec le traitement d'une requête asynchrone afin d'apparier une réponse au contexte de la requête originale. Les données opaques d'un client PEUVENT aussi être utilisées en conjonction avec un traitement de requête synchrone afin de fournir une information de contexte pour des besoins telle qu'une réconciliation par piste de vérification.

[96] Le schéma suivant définit l'élément OpaqueClientData :

   <!-- OpaqueClientData -->
   <element name="OpaqueClientData" type="xkms:OpaqueClientDataType"/>
   <complexType name="OpaqueClientDataType">
      <sequence maxOccurs="unbounded">
         <element ref="xkms:OpaqueData" minOccurs="0"/>
      </sequence>
   </complexType>
   <element name="OpaqueData" type="base64Binary"/>
   <!-- /OpaqueClientData -->

3.2 Les messages de requête

3.2.1 Le type RequestAbstractType

[97] Le type abstrait RequestAbstractType est celui à partir duquel tous les types d'élément des requêtes XKMS sont dérivés. Le type abstrait RequestAbstractType hérite des éléments et attributs du type abstrait MessageAbstractType et contient, en outre, l'élément les éléments et les attributs suivants :

<ResponseMechanism> (un nombre quelconque)
Indique les mécanismes de protocole étendus que le client gère en rapport avec cette requête.
<RespondWith> (un nombre quelconque)
Indique les types de données que le destinataire demande qu'on lui envoie dans la réponse.
<PendingNotification> (optionnel)
Indique un moyen par lequel le service peut aviser le requérant de la réalisation d'une réponse en instance. Si l'élément <PendingNotification> est présent, on DOIT affecter la valeur Pending à l'attribut <ResponseMechanism>.
OriginalRequestId (optionnel)
Indique la valeur Id de la première requête faite dans un protocole en plusieurs étapes tels que le mécanisme de traitement asynchrone ou le protocole à deux phases.
ResponseLimit (optionnel)
Indique le nombre maximum d'éléments de données que le requérant peut accepter au cas où le schéma spécifierait un nombre illimité d'éléments.

[98] Le schéma suivant définit le type abstrait RequestAbstractType abstract type :

   <!-- RequestAbstractType -->
   <complexType name="RequestAbstractType" abstract="true">
      <complexContent>
         <extension base="xkms:MessageAbstractType">
            <sequence>
               <element ref="xkms:ResponseMechanism" minOccurs="0"
                     maxOccurs="unbounded"/>
               <element ref="xkms:RespondWith" minOccurs="0"
                     maxOccurs="unbounded"/>
               <element ref="xkms:PendingNotification" minOccurs="0"/>
            </sequence>
            <attribute name="OriginalRequestId" type="NCName"
                  use="optional"/>
            <attribute name="ResponseLimit" type="integer" use="optional"/>
         </extension>
      </complexContent>
   </complexType>
   <!-- /RequestAbstractType -->

3.2.2 L'élément <ResponseMechanism>

[99] L'élément <ResponseMechanism> d'une requête spécifie une ou plusieurs chaînes, incluses dans la requête, qui indiquent les mécanismes de protocole étendus que le client reconnaît en relation avec une requête.

[100] Les valeurs de l'élément ResponseMechanism sont spécifiées comme étant de type anyURI ; voici les identificateurs définis :

Nom du type anyURI Description
http://www.w3.org/2002/03/xkms#Pending Le requérant est prêt à accepter une réponse utilisant un traitement asynchrone, c'est-à-dire que le service PEUT retourner un attribut MajorResult ResultMajor avec la valeur de code Pending
http://www.w3.org/2002/03/xkms#Represent Le requérant est prêt à accepter une réponse utilisant le protocole à deux phases, c'est-à-dire que le service PEUT retourner un attribut MajorResult ResultMajor avec la valeur de code Represent
http://www.w3.org/2002/03/xkms#RequestSignatureValue Le requérant est prêt à accepter une réponse qui transporte un élément <RequestSignatureValue>.

[101] Le schéma suivant définit l'élément <ResponseMechanism> :

   <!-- ResponseMechanism -->
   <simpleType name="ResponseMechanismEnum">
      <restriction base="anyURI">
         <enumeration value="http://www.w3.org/2002/03/xkms#Pending"/>
         <enumeration value="http://www.w3.org/2002/03/xkms#Represent"/>
         <enumeration value="http://www.w3.org/2002/03/xkms#RequestSignatureValue"/>
      </restriction>
   </simpleType>
   <simpleType name="ResponseMechanismOpenEnum">
      <union memberTypes="xkms:ResponseMechanismEnum anyURI"/>
   </simpleType>
   <element name="ResponseMechanism" type="xkms:ResponseMechanismOpenEnum"/>
   <!-- /ResponseMechanism -->

3.2.3 L'élément <RespondWith>

[102] L'élément <RespondWith> d'une requête spécifie une ou plusieurs valeurs d'adresse URI qui DEVRAIENT se résoudre en éléments de données soit dans l'élément <ds:KeyInfo>, soit dans une information de clé privée définie dans la section Les paramètres des clés privées plus loin. L'élément <RespondWith> DEVRAIT être inclus dans les requêtes de type LocateRequest, ValidateRequest, RegisterRequest, ReissueRequest, RevokeRequest et RecoverRequest. Les éléments de la signature XML sont décrits ici par commodité : la référence normative est la spécification des signatures numériques XML [XML-SIG].

[103] Le service DEVRAIT retourner tous les éléments de données qui peuvent se résoudre en valeurs d'adresse URI <RespondWith> et qu'il gère. Le service PEUT retourner d'autres éléments de données non demandés. En particulier, il PEUT renvoyer en réponse les éléments de données spécifiés dans la requête.

[104] Les valeurs de l'élément RespondWith sont spécifiées comme étant de type anyURI ; voici les identificateurs définis (tous les noms de la première colonne sont préfixés par l'URIhttp://www.w3.org/2002/03/xkms#) :

Nom de type anyURI Élément <ds:Keyinfo> Description
KeyName <ds:KeyName> Nom de clé
KeyValue <ds:KeyValue> Paramètres de clé publique
X509Cert <ds:X509Data> Certificat X509 v3 qui authentifie la clé spécifiée
X509Chain <ds:X509Data>* Chaîne de certificats X509 v3 qui authentifie la clé spécifiée. Remarquez que les certificats sont retournés dans un ordre quelconque.
X509CRL <ds:X509Data> Liste de révocation de certificats X509 v2
RetrievalMethod <ds:RetrievalMethod> Données sur la méthode de récupération
PGP <ds:PGPData> Données de signature par clé PGP
PGPWeb <ds:PGPData>* Collection de données de signature par clé PGP
SPKI <ds:SPKIData>* Signature par clé SPKI
PrivateKey   Demande de renvoyer la clé privée cryptée dans la réponse. (Utilisé dans le protocole X-KRSS)

[104a] (Dans la table ci-dessus, l'astérisque * signifie un ou plusieurs).

[105] Par exemple, un client dépourvu de capacité de traitement X.509 pourrait effectuer une opération Locate afin d'obtenir les informations concernant les paramètres et le nom de clé publique à partir d'un élément <ds:Keyinfo> qui indique seulement un certificat. Auquel cas, les valeurs de l'élément RespondWith seraient KeyName et KeyValue.

[106] Le schéma suivant définit l'élément <RespondWith> :

   <!-- RespondWith -->
    <simpleType name="RespondWithEnum">
         <restriction base="anyURI">
              <enumeration value="http://www.w3.org/2002/03/xkms#KeyName"/>
              <enumeration value="http://www.w3.org/2002/03/xkms#KeyValue"/>
              <enumeration value="http://www.w3.org/2002/03/xkms#X509Cert"/>
              <enumeration value="http://www.w3.org/2002/03/xkms#X509Chain"/>
              <enumeration value="http://www.w3.org/2002/03/xkms#X509CRL"/>
              <enumeration value="http://www.w3.org/2002/03/xkms#RetrievalMethod"/>
              <enumeration value="http://www.w3.org/2002/03/xkms#PGP"/>
              <enumeration value="http://www.w3.org/2002/03/xkms#PGPWeb"/>
              <enumeration value="http://www.w3.org/2002/03/xkms#SPKI"/>
              <enumeration value="http://www.w3.org/2002/03/xkms#PrivateKey"/>
         </restriction>
    </simpleType>
    <simpleType name="RespondWithOpenEnum">
         <union memberTypes="xkms:RespondWithEnum anyURI"/>
    </simpleType>
   <element name="RespondWith" type="xkms:RespondWithOpenEnum"/>
   <!-- /RespondWith -->

3.2.4 L'élément <PendingNotification>

[107] L'élément <PendingNotification> sert à spécifier un mécanisme par lequel le service peut informer un requérant qu'une requête en instance a été réalisée de manière asynchrone.

[108] L'élément <PendingNotification> contient les attributs suivants :

Mechanism (obligatoire)
Une adresse URI qui spécifie le protocole par lequel la notification PEUT se faire.
Identifier (obligatoire)
Une adresse URI qui spécifie l'adresse à laquelle la notification PEUT se faire.

[109] Les mécanismes suivants sont définis :

Protocole Mécanisme Identificateur Description
SMTP urn:ietf:rfc:822 mailto: Notification par courrier électronique. Le contenu de ce courrier n'est pas défini par cette spécification.
HTTP urn:ietf:rfc:2616 http:// Notification par HTTP. Le contenu de cette requête n'est pas défini par cette spécification.

[110] Le schéma suivant définit l'élément <PendingNotification> et le type PendingNotificationType :

   <!-- PendingNotification -->
   <element name="PendingNotification" type="xkms:PendingNotificationType"/>
   <complexType name="PendingNotificationType">
      <attribute name="Mechanism" type="anyURI" use="required"/>
      <attribute name="Identifier" type="anyURI" use="required"/>
   </complexType>
   <!-- /PendingNotification -->

3.2.5 L'élément <PendingRequest>

[111] L'élément PendingRequest sert à demander le résultat d'une requête présentée antérieurement pour laquelle un attribut MajorResult ResultMajor avec la valeur de code Pending avait été retourné. L'élément PendingRequest hérite de l'élément des éléments et des attributs du type RequestAbstractType et de l'attribut suivant :

ResponseId (obligatoire)
La valeur de l'attribut Id envoyé dans la réponse originale contenant l'attribut MajorResult ResultMajor avec la valeur Pending.

[112] Si la valeur de l'attribut ResponseId est inconnue auprès du service, celui-ci retourne le résultat Sender.UnknownResponseId.

[112a] L'élément RespondWith NE DOIT PAS être présent au sein d'un élément PendingRequest.

[113] Le schéma suivant définit l'élément PendingRequest et le type PendingRequestType :

   <!-- PendingRequest -->
   <element name="PendingRequest" type="xkms:PendingRequestType"/>
   <complexType name="PendingRequestType">
      <complexContent>
         <extension base="xkms:RequestAbstractType">
            <attribute name="ResponseId" type="NCName" use="required"/>
         </extension>
      </complexContent>
   </complexType>
   <!-- /PendingRequest -->

3.3 Les messages de réponse

3.3.1 L'élément <Result>

[114] Le type ResultType est celui à partir duquel tous les types d'élément des réponses XKMS sont dérivés. Le type ResultType hérite de l'élément des éléments et des attributs du type abstrait MessageAbstractType et contient, en outre, les attributs suivants :

<RequestSignatureValue> (optionnel)
La valeur de l'élément ds:SignatureValue de la requête correspondante.
ResultMajor (obligatoire)
Le composant le plus significatif du code de résultat.
ResultMinor (optionnel)
Le composant le moins significatif du code de résultat.
RequestId (optionnel)
L'identificateur Id unique spécifié dans la requête.

[115] Si la valeur de l'attribut l'attribut MajorResult ResultMajor a la valeur Represent, alors l'attribut Nonce DOIT être présent et sa valeur NE DOIT PAS être la chaîne vide.

[116] L'élément <Result> est retourné en réponse à une requête XKMS si, et seulement si, le service ne peut pas retourner d'élément de résultat plus précis qui hérite du type ResultType. Par exemple, si une requête intervient pour connaître le statut d'une requête en instance dont l'identificateur est inconnu du service.

[117] Considération pour la sécurité : Lors de la signature des réponses, il faut s'assurer que le service ne fournisse pas un oracle de signature, c'est-à-dire la signature de messages dont le contenu peut être deviné par un attaquant. Les mises en œuvre DOIVENT s'assurer que les messages de réponse contiennent une quantité suffisante de données imprévisibles tel qu'un attribut Id choisi de manière pseudo-aléatoire. Cf. la section Les questions de sécurité pour plus de renseignements.

[118] Le schéma suivant définit l'élément <Result> et le type ResultType :

<!-- ResultType -->
<element name="Result" type="xkms:ResultType"/>
     <simpleType name="ResultMajorEnum">
          <restriction base="anyURI">
               <enumeration value="http://www.w3.org/2002/03/xkms#Success"/>
               <enumeration value="http://www.w3.org/2002/03/xkms#VersionMismatch"/>
               <enumeration value="http://www.w3.org/2002/03/xkms#Sender"/>
               <enumeration value="http://www.w3.org/2002/03/xkms#Receiver"/>
               <enumeration value="http://www.w3.org/2002/03/xkms#Represent"/>
               <enumeration value="http://www.w3.org/2002/03/xkms#Pending"/>
          </restriction>
     </simpleType>
     <simpleType name="ResultMajorOpenEnum">
          <union memberTypes="xkms:ResultMajorEnum anyURI"/>
     </simpleType>
     <simpleType name="ResultMinorEnum">
          <restriction base="anyURI">
             <enumeration value="http://www.w3.org/2002/03/xkms#NoMatch"/>
             <enumeration value="http://www.w3.org/2002/03/xkms#TooManyResponses"/>
             <enumeration value="http://www.w3.org/2002/03/xkms#Incomplete"/>
             <enumeration value="http://www.w3.org/2002/03/xkms#Failure"/>
             <enumeration value="http://www.w3.org/2002/03/xkms#Refused"/>
             <enumeration value="http://www.w3.org/2002/03/xkms#NoAuthentication"/>
             <enumeration 
                 value="http://www.w3.org/2002/03/xkms#MessageNotSupported"/>
             <enumeration value="http://www.w3.org/2002/03/xkms#UnknownResponseId"/>
             <enumeration value="http://www.w3.org/2002/03/xkms#RepresentRequired"/>
             <enumeration value="http://www.w3.org/2002/03/xkms#NotSynchronous"/>
             <enumeration 
                 value="http://www.w3.org/2002/03/xkms#OptionalElementNotSupported"/>
             <enumeration 
                 value="http://www.w3.org/2002/03/xkms#ProofOfPossessionRequired"/>
             <enumeration 
                 value="http://www.w3.org/2002/03/xkms#TimeInstantNotSupported"/>
             <enumeration 
                 value="http://www.w3.org/2002/03/xkms#TimeInstantOutOfRange"/>
          </restriction>
     </simpleType>
     <simpleType name="ResultMinorOpenEnum">
          <union memberTypes="xkms:ResultMinorEnum anyURI"/>
     </simpleType>
     <complexType name="ResultType">
        <complexContent>
          <extension base="xkms:MessageAbstractType">
             <sequence>
                 <element ref="xkms:RequestSignatureValue" minOccurs="0"/>
             </sequence>
             <attribute name="ResultMajor" type="xkms:ResultMajorOpenEnum" 
                 use="required"/>
             <attribute name="ResultMinor" type="xkms:ResultMinorOpenEnum" 
                 use="optional"/>
             <attribute name="RequestId" type="NCName" use="optional"/>
          </extension>
        </complexContent>
     </complexType>
<!-- /ResultType -->

3.3.1.1 Les codes de résultat

[119] Les codes de résultat se composent d'un code majeur et d'un code mineur. Les codes majeurs et mineurs sont définis comme étant des types anyURI XML. Cette spécification emploie la notation ResultMajor.ResultMinor pour spécifier un code de résultat. Par exemple, le code de résultat Sender.NoMatch indique un code ResultMajor de Sender et un code ResultMinor de NoMatch.

[120] Voici les codes ResultMajor définis (les entrées Nom de type anyURI sont tous à préfixer de http://www.w3.org/2002/03/xkms#) :

Nom de type anyURI Final Description
Success Final L'opération a réussi.
VersionMismatch Final Le service ne gère pas la version du protocole spécifiée dans la requête.
Sender Final Il s'est produit une erreur causée par le message envoyé par l'émetteur.
Receiver Final Il s'est produit une erreur du côté du récepteur.
Represent Non final Le service n'a pas obtempéré à la requête. Pour que la requête soit exécutée, celle-ci DOIT être présentée à nouveau avec le ticket spécifié conformément au protocole à deux phases.
Pending Non final La requête a été acceptée pour traitement et le service retournera le résultat de manière asynchrone.

[121] Les codes ResultMajor Success, VersionMismatch, Sender et Receiver sont finaux, c'est-à-dire que le retour du code marque la fin du protocole. Les codes ResultMajor Represent et Pending sont non finaux et indiquent la nécessité d'un autre traitement pour recevoir le résultat.

[122]Voici les codes ResultMinor définis (les entrées Nom de type anyURI sont tous à préfixer de http://www.w3.org/2002/03/xkms#) :

Nom de type anyURI Codes majeurs possibles Description
NoMatch  - Description générique : Aucune concordance n'a été trouvée pour le prototype de recherche fourni.
Success Le code de résultat Success.NoMatch indique que le service a autorité pour le prototype de recherche spécifié, lequel affirme qu'aucune concordance n'existe.
Receiver Le code de résultat Receiver.NoMatch indique que le service n'a pas autorité pour le prototype de recherche fourni.
TooManyResponses  - Description générique : La requête a produit un nombre de réponses qui excède soit la valeur spécifiée dans la requête pour l'attribut ResponseLimit, soit une autre limite déterminée par le service. Le service PEUT retourner un sous-ensemble des réponses possibles ou bien rien du tout.
Success Le service a retourné une ou plusieurs réponses représentant un sous-ensemble des réponses possibles.
Receiver Le service n'a retourné aucune réponse.
Incomplete Success Une partie seulement de l'information demandée a pu être fournie.
Failure  - Description générique : Le service a tenté de réaliser la requête, mais l'opération a échoué pour une raison non précisée.
Sender La raison de l'échec est attribuée à l'émetteur (par exemple, la requête a échoué à la validation du schéma).
Receiver La raison de l'échec est attribuée au récepteur (par exemple, la recherche dans une base de données a échoué).
Refused  - Description générique : L'opération a été refusée. Le service n'a pas essayé de réaliser la requête.
Sender L'émetteur n'a pas réussi à fournir suffisamment de renseignements pour authentifier ou autoriser la requête (par exemple, un paiement non effectué).
Receiver Le récepteur refuse actuellement certaines requêtes pour des raisons non précisées.
NoAuthentication Sender L'opération a été refusée, car les renseignements nécessaires pour l'authentification étaient incorrects ou manquants.
MessageNotSupported Sender Le récepteur n'a pas la capacité de mettre en œuvre l'opération spécifiée.
UnknownResponseId Sender La valeur de l'attribut ResponseId de la réponse pour laquelle un statut en instance a été demandé est inconnue du service.
RepresentRequired Sender Le répondant impose à l'émetteur qu'il offre l'option de protocole Represent afin traiter la requête.
NotSynchronous Receiver Le récepteur ne gère pas le traitement synchrone pour ce type de requête.
OptionalElementNotSupported Receiver Le récepteur a refusé l'opération, car il ne gère pas la valeur d'élément OPTIONNELLE présente dans la requête.
ProofOfPossessionRequired Sender Le récepteur a refusé l'opération, car il exige de l'émetteur qu'il inclut l'élément ProofOfPossession dans sa requête.
TimeInstantNotSupported Receiver Le récepteur a refusé l'opération, car il ne gère pas l'élément TimeInstant.
TimeInstantOutOfRange Sender Le récepteur a refusé l'opération, car le temps indiqué n'est pas dans le délai de réponse fixé.

3.3.2 L'élément <RequestSignatureValue>

[123] L'élément <RequestSignatureValue> d'une réponse contient la valeur codée en base64 du contenu de l'élément <ds:SignatureValue> dans le bloc <ds:Signature> de la requête correspondante. Si la réponse est signée, cela permettra d'avoir un lien cryptographique entre la requête et la réponse.

[124] Un service DEVRAIT inclure l'élément <RequestSignatureValue> dans une réponse si les conditions suivantes sont satisfaites, sinon il NE DOIT PAS l'inclure :

[125] Si l'élément <RequestSignatureValue> est présent dans une réponse, le requérant DOIT rejeter le message dans le cas où :

[126] L'élément <RequestSignatureValue> est du type ds:SignatureValueType, défini dans la spécification XML Signature [XML-SIG].

   <!-- RequestSignatureValue -->
   <element name="RequestSignatureValue" type="ds:SignatureValueType"/>
   <!-- /RequestSignatureValue -->

3.4 Les requêtes composées

[127] Le mécanisme des requêtes composées autorise l'envoi de plusieurs requêtes dans un seul message de requête et, pour les réponses correspondantes, dans un seul message de réponse. Cela permet une économie considérable des ressources de traitement car on peut utiliser une seule signature du message composé au lieu de plusieurs signatures sur les requêtes ou réponses individuelles. Il n'y a aucune contrainte sur le type de requête susceptible d'apparaître dans une seule requête composée. Une requête composée peut contenir plusieurs instances du même type de requête, un mélange de types différents ou bien un panachage des deux.

3.4.1 L'élément <CompoundRequest>

[128] L'élément <CompoundRequest> sert à émettre plusieurs requêtes en même temps. L'élément <CompoundRequest> hérite de l'élément des éléments et des attributs du type RequestAbstractType ainsi que des éléments suivants, dans n'importe quel ordre :

<LocateRequest> (un nombre quelconque)
Une requête de localisation XKMS Locate
<ValidateRequest> (un nombre quelconque)
Une requête de validation XKMS Validate.
<RegisterRequest> (un nombre quelconque)
Une requête d'enregistrement XKMS Register.
<ReissueRequest> (un nombre quelconque)
Une requête de réémission XKMS Reissue.
<RecoverRequest> (un nombre quelconque)
Une requête de récupération XKMS Recover.
<RevokeRequest> (un nombre quelconque)
Une requête de révocation XKMS Revoke.

[128a] L'élément RespondWith NE DOIT PAS apparaître comme enfant direct d'un élément CompoundRequest. Chaque requête encapsulée dans un élément CompoundRequest peut avoir ou non son propre élément RespondWith enfant.

[129] Le schéma suivant définit l'élément <CompoundRequest> et le type CompoundRequestType :

   <!-- CompoundRequest -->
   <element name="CompoundRequest" type="xkms:CompoundRequestType"/>
   <complexType name="CompoundRequestType">
      <complexContent>
         <extension base="xkms:RequestAbstractType">
            <choice maxOccurs="unbounded">
               <element ref="xkms:LocateRequest"/>
               <element ref="xkms:ValidateRequest"/>
               <element ref="xkms:RegisterRequest"/>
               <element ref="xkms:ReissueRequest"/>
               <element ref="xkms:RecoverRequest"/>
               <element ref="xkms:RevokeRequest"/>
            </choice>
         </extension>
      </complexContent>
   </complexType>
   <!-- /CompoundRequest -->

3.4.2 L'élément <CompoundResult>

[130] L'élément <CompoundResult> sert à répondre à un élément <CompoundRequest>. Si l'attribut MajorResult ResultMajor du résultat composé a la valeur Success, alors il contient plusieurs réponses correspondant aux multiples requêtes spécifiées dans l'élément <CompoundRequest>. L'élément <CompoundResult> hérite de l'élément des éléments et des attributs du type ResultType ainsi que des autres éléments suivants, dans un ordre quelconque :

<LocateResult> (un nombre quelconque)
Le résultat d'une requête en localisation XKMS Locate.
<ValidateResult> (un nombre quelconque)
Le résultat d'une requête en validation XKMS Validate.
<RegisterResult> (un nombre quelconque)
Le résultat d'une requête en enregistrement XKMS Register.
<ReissueResult> (un nombre quelconque)
Le résultat d'une requête en réémission XKMS Reissue.
<RecoverResult> (un nombre quelconque)
Le résultat d'une requête en récupération XKMS Recover.
<RevokeResult> (un nombre quelconque)
Le résultat d'une requête en révocation XKMS Revoke.

[131] Le schéma suivant définit l'élément <CompoundResult> et le CompoundResultType :

   <!-- CompoundResult -->
   <element name="CompoundResult" type="xkms:CompoundResultType"/>
   <complexType name="CompoundResultType">
      <complexContent>
         <extension base="xkms:ResultType">
            <choice minOccurs="0" maxOccurs="unbounded">
               <element ref="xkms:LocateResult"/>
               <element ref="xkms:ValidateResult"/>
               <element ref="xkms:RegisterResult"/>
               <element ref="xkms:ReissueResult"/>
               <element ref="xkms:RecoverResult"/>
               <element ref="xkms:RevokeResult"/>
            </choice>
         </extension>
      </complexContent>
   </complexType>
   <!-- /CompoundResult -->

3.5 Les requêtes de statut

3.5.1 L'élément <StatusRequest>

[132] L'élément StatusRequest sert à demander au service qu'il retourne le statut d'une requête en instance par le biais d'un élément <StatusResult>. L'élément StatusRequest hérite de l'élément des éléments et des attributs du type PendingRequestType. L'élément RespondWith NE DOIT PAS apparaître au sein d'un élément StatusRequest.

[133] Le schéma suivant définit l'élément StatusRequest et le type StatusRequestType :

   <!-- StatusRequest -->
   <element name="StatusRequest" type="xkms:StatusRequestType"/>
   <complexType name="StatusRequestType">
      <complexContent>
         <extension base="xkms:PendingRequestType"/>
      </complexContent>
   </complexType>
   <!-- /StatusRequest -->

3.5.2 L'élément <StatusResult>

[134] L'élément <StatusResult> sert à retourner le statut d'une requête en instance. S'il s'agit d'une requête non composée, le statut est indiqué par le contenu de l'attribut ResultMajor. Pour une requête composée, le statut de chacune des requêtes internes la composant est indiqué par trois attributs optionnels différents, définis ci-dessous.

[134a] Le type StatusResultType hérite de l'élément des éléments et des attributs du type ResultType et il contient, en outre, les attributs suivants pour signaler le statut des requêtes composées :

Success (optionnel)
Pour une requête composée, le nombre des requêtes internes qui ont été réalisées avec un statut Success.
Failure (optionnel)
Pour une requête composée, le nombre des requêtes internes qui ont été réalisées avec un statut autre que Success.
Pending (optionnel)
Pour une requête composée, le nombre des requêtes internes qui sont toujours en instance.

[135] Le schéma suivant définit l'élément StatusResult et le type StatusResultType :

   <!-- StatusResult -->
   <element name="StatusResult" type="xkms:StatusResultType"/>
   <complexType name="StatusResultType">
      <complexContent>
         <extension base="xkms:ResultType">
            <attribute name="Success" type="integer" use="optional"/>
            <attribute name="Failure" type="integer" use="optional"/>
            <attribute name="Pending" type="integer" use="optional"/>
         </extension>
      </complexContent>
   </complexType>
   <!-- /StatusResult -->

4 La description des services d'information de clés

[136] Selon la spécification XML Signature [XML-SIG], un signataire peut, en option, inclure des informations sur sa clé de signature publique (par l'élément<ds:KeyInfo>) dans le bloc signature. Ces informations sur la clé sont prévues pour que le signataire puisse communiquer à un vérificateur des indications sur la clé publique à sélectionner.

[137] Une autre propriété importante de l'élément <ds:KeyInfo> est celle selon laquelle il peut ou non être lié de manière cryptographique à la clé en question. Cela permet la substitution ou le complément de l'élément <ds:KeyInfo> sans invalider la signature numérique.

[138] Par exemple, Alice signe un document et l'envoie à Bob avec un élément <ds:KeyInfo> qui spécifie seulement les données de la clé de signature. À réception du message, Bob récupère les informations supplémentaires nécessaires pour valider la signature et ajoute ces informations à l'élément <ds:KeyInfo> avant de passer le document à Carol (cf. Figure 1 ci-dessous).

[139] Le remplacement de l'élément ds:KeyInfo lors de la transmission d'un document d'un processeur à l'autre.

[140] Figure 1 : Le remplacement de l'élément <ds:KeyInfo> lors de la transmission d'un document d'un processeur à l'autre

4.1 Le service de localisation

[141] Le service de localisation (N.D.T. Locate) X-KISS résoud l'élément <ds:Keyinfo> mais il N'EST PAS OBLIGÉ de se prononcer quant à la validité des liaisons entre les données dans l'élément <ds:Keyinfo>.

[142] Le service XKMS PEUT résoudre l'élément <ds:Keyinfo> en utilisant des données locales ou il PEUT relayer la requête vers d'autres serveurs. Par exemple, le service XKMS pourrait résoudre un élément <ds:RetrievalMethod> (Figure 2) ou se comporter comme une passerelle vers une infrastructure à clé publique (PKI) sous-jacente basée sur une syntaxe non-XML.

[143] Le diagramme montre un échange de protocole entre un client, un service de séquestre et un serveur distant (le serveur A).

[144] Figure 2 : Le service de localisation fournit une résolution de nom

[145] La requête et la réponse PEUVENT toutes deux être signées, ce qui permet d'authentifier l'émetteur comme de protéger l'intégrité des données transmises au moyen d'une signature XML [XML-SIG].

4.1.1 Exemple : Le chiffrement des données

[146] Alice veut envoyer un courrier électronique crypté à Bob mais ne connaît pas sa clé de chiffrement. Alice a la possibilité d'utiliser les formats de courrier sécurisé S/MIME et PGP. Le client d'Alice utilise le système DNS pour localiser le service XKMS offrant un service de localisation pour les clés liées au domaine example.com puis envoie une requête de localisation XKMS au service XKMS découvert pour une clé liée à bob@example.com et le protocole S/MIME ou PGP. L'application vérifie alors que le certificat obtenu remplit ses critères de confiance en effectuant une validation de certificat standard par rapport à un certificat racine éprouvé.

[147] Requête :

<?xml version="1.0" encoding="utf-8"?>
<LocateRequest xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
      xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
      Id="I8fc9f97052a34073312b22a69b3843b6"
      Service="http://www.example.org/XKMS"
      xmlns="http://www.w3.org/2002/03/xkms#">
  <RespondWith>http://www.w3.org/2002/03/xkms#KeyName</RespondWith>
  <RespondWith>http://www.w3.org/2002/03/xkms#KeyValue</RespondWith>
  <RespondWith>http://www.w3.org/2002/03/xkms#X509Cert</RespondWith>
  <RespondWith>http://www.w3.org/2002/03/xkms#X509Chain</RespondWith>
  <RespondWith>http://www.w3.org/2002/03/xkms#PGPWeb</RespondWith>
  <RespondWith>http://www.w3.org/2002/03/xkms#PGP</RespondWith>
  <QueryKeyBinding>
    <KeyUsage>http://www.w3.org/2002/03/xkms#Encryption</KeyUsage>
    <UseKeyWith Application="urn:ietf:rfc:2440"
          Identifier="bob@example.com" />
    <UseKeyWith Application="urn:ietf:rfc:2633"
          Identifier="bob@example.com" />
  </QueryKeyBinding>
</LocateRequest>

[148] Réponse :

<?xml version="1.0" encoding="utf-8"?>
<LocateResult xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
      xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
      Id="I8ce3809ab23500015cc27704b7eb0912"
      Service="http://www.example.org/XKMS"
      ResultMajor="http://www.w3.org/2002/03/xkms#Success"
      RequestId="I8fc9f97052a34073312b22a69b3843b6"
      xmlns="http://www.w3.org/2002/03/xkms#">
  <UnverifiedKeyBinding Id="I809ca03cf85b3cb466859694dbd0627d">
    <ds:KeyInfo>
      <ds:KeyValue>
        <ds:RSAKeyValue>
          <ds:Modulus>
            3FFtWUsvEajQt2SeSF+RvAxWdPPh5GSlQnp8SDvvqvCwE6PXcRWrIGmV7twNf2T
            UXCxYuztUUClMIy14B0Q+k1ej2nekmYL7+Ic3DDGVFVaYPoxaRY0Y2lV8tOreyn
            WegpFbITXc8V6Y02QfR5O7Pn1/10ElslaF/TF8MQGqYE8=
          </ds:Modulus>
          <ds:Exponent>AQAB</ds:Exponent>
        </ds:RSAKeyValue>
      </ds:KeyValue>
      <ds:X509Data>
        <ds:X509Certificate>
          MIICCTCCAXagAwIBAgIQe0Sk4xr1VolGFFNMkCx07TAJBgUrDgMCHQUAMBIxEDA
          OBgNVBAMTB1Rlc3QgQ0EwHhcNMDMwODE1MDcwMDAwWhcNMDUwODE1MDY1OTU5Wj
          AkMSIwIAYDVQQDExlCb2IgQmFrZXIgTz1Cb2IgQ29ycCBDPVVTMIGfMA0GCSqGS
          Ib3DQEBAQUAA4GNADCBiQKBgQDcUW1ZSy8RqNC3ZJ5IX5G8DFZ08+HkZKVCenxI
          O++q8LATo9dxFasgaZXu3A1/ZNRcLFi7O1RQKUwjLXgHRD6TV6Pad6SZgvv4hzc
          MMZUVVpg+jFpFjRjaVXy06t7KdZ6CkVshNdzxXpjTZB9Hk7s+fX/XQSWyVoX9MX
          wxAapgTwIDAQABo1YwVDANBgNVHQoEBjAEAwIGQDBDBgNVHQEEPDA6gBABpU6Rp
          UssqgWYs3fukLy6oRQwEjEQMA4GA1UEAxMHVGVzdCBDQYIQLgyd1ReM8bVNnFUq
          D4e60DAJBgUrDgMCHQUAA4GBAF4jP1gGDbaq3rg/Vo3JY7EDNTp0HmwLiPMLmdn
          B3WTIGFcjS/jZFzRCbvKPeiPTZ6kRkGgydFOuCo5HMAxIks/LtnKFd/0qYT+AOD
          q/rCrwSx+F+Ro2rf9tPpja9o7gANqxs6Pm7f1QSPZO57bT/6afiVm7NdaCfjgMp
          hb+XNyn
        </ds:X509Certificate>
        <ds:X509Certificate>
          MIIB9zCCAWSgAwIBAgIQLgyd1ReM8bVNnFUqD4e60DAJBgUrDgMCHQUAMBIxEDA
          OBgNVBAMTB1Rlc3QgQ0EwHhcNMDMwODE1MDcwMDAwWhcNMTAwODE1MDcwMDAwWj
          ASMRAwDgYDVQQDEwdUZXN0IENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBg
          QCn23HHp+HtXpiyKVSDtdE3dO0r0oLB/H9sxUEkeXB8oMxwbhdcizWH92zrtm1V
          fVtxkfmwF14ZXoyDZHeZXuCOtAfz/mW6s2gmfD45TfFFVGksDGVRNK5XmKXA5sE
          C51RCvaxzGBdGDlCuVPqX7Cq3IcZpRU1IXbi5YzGwV7j6LwIDAQABo1YwVDANBg
          NVHQoEBjAEAwIHgDBDBgNVHQEEPDA6gBABpU6RpUssqgWYs3fukLy6oRQwEjEQM
          A4GA1UEAxMHVGVzdCBDQYIQLgyd1ReM8bVNnFUqD4e60DAJBgUrDgMCHQUAA4GB
          ABDYD4Fwx2dscu+BgYcZ+GoQQtCJkwJEXytb4zlNl7HLFKbXSw4m0blQquIsfsi
          QgFYAQBXSbu7aeUqqmSGHvILu3BGwVOKjxbHfcM4/MefuTtpOpCN40wy3YwwngD
          tHTaIqm8NwS966PE+W9f8kD70q5FNwf+GF/lX9qGc/x435
        </ds:X509Certificate>
      </ds:X509Data>
    </ds:KeyInfo>
    <KeyUsage>http://www.w3.org/2002/03/xkms#Signature</KeyUsage>
    <KeyUsage>http://www.w3.org/2002/03/xkms#Encryption</KeyUsage>
    <KeyUsage>http://www.w3.org/2002/03/xkms#Exchange</KeyUsage>
    <UseKeyWith Application="urn:ietf:rfc:2633"
          Identifier="bob@example.com" />
  </UnverifiedKeyBinding>
</LocateResult>

4.1.2 Exemple : La signature d'un document

[149] Bob reçoit le document signé d'Alice, qui indique le certificat X.509v3 d'Alice mais pas la valeur de la clé. Le client de messagerie de Bob est incapable de traiter les certificats X.509v3 mais il peut obtenir les paramètres de la clé auprès du service XKMS au moyen du service de localisation. Le client de messagerie de Bob envoie l'élément <ds:Keyinfo> au service de localisation en demandant que l'élément <KeyValue> correspondant soit retourné.

[150] Requête :

<?xml version="1.0" encoding="utf-8"?>
<LocateRequest xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
      xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
      Id="I045c66f6c525a9bf3842ecd3466cd422"
      Service="http://www.example.org/XKMS"
      xmlns="http://www.w3.org/2002/03/xkms#">
  <RespondWith>http://www.w3.org/2002/03/xkms#KeyValue</RespondWith>
  <QueryKeyBinding>
    <ds:KeyInfo>
      <ds:X509Data>
        <ds:X509Certificate>
          MIICEDCCAX2gAwIBAgIQimXeUAxYJbJMady9vV1bLjAJBgUrDgMCHQUAMBIxEDA
          OBgNVBAMTB1Rlc3QgQ0EwHhcNMDMwODE1MDcwMDAwWhcNMDUwODE1MDY1OTU5Wj
          ArMSkwJwYDVQQDEyBBbGljZSBBYXJkdmFyayBPPUFsaWNlIENvcnAgQz1VUzCBn
          zANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA0nIsmR+aVW2egl5MIfOKy4HuMKkk
          9AZ/IQuDLVPlhzOfgngjVQCjr8uvmnqtNu8HBupui8LgGthO6U9D0CNT5mbmhIA
          ErRADUMIAFsi7LzBarUvNWTqYNEJmcHsAUZdrdcDrkNnG7SzbuJx+GDNiHKVDQg
          gPBLc1XagW20RMvokCAwEAAaNWMFQwDQYDVR0KBAYwBAMCBkAwQwYDVR0BBDwwO
          oAQAaVOkaVLLKoFmLN37pC8uqEUMBIxEDAOBgNVBAMTB1Rlc3QgQ0GCEC4MndUX
          jPG1TZxVKg+HutAwCQYFKw4DAh0FAAOBgQABU91ka7IlkXCfv4Zh2Ohwgg2yObt
          Y3+6C/BTFGrOEBJDy+DoxJ/NuBF18w3rrrR18xE6jNKYLCQb8zUGk4QOG5Y+HT/
          QTTFvWkiOLXcpTuhnOhXatr42FoYpDkjx2QWK+J5Q2l/Rgjgc/0ZV8U/kD8UuRk
          Xp4AZh7QsiX8AcO0w==
        </ds:X509Certificate>
      </ds:X509Data>
    </ds:KeyInfo>
    <KeyUsage>http://www.w3.org/2002/03/xkms#Signature</KeyUsage>
  </QueryKeyBinding>
</LocateRequest>

[151] Le service de localisation extrait le certificat X.509v3 de l'élément <ds:Keyinfo> et retourne la valeur de la clé. Le service de localisation NE PRÉCISE PAS le statut de révocation NI la crédibilité du certificat.

[152] Réponse :

<?xml version="1.0" encoding="utf-8"?>
<LocateResult xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
      xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
      Id="I04cd4f17d0656413d744f55488369264"
      Service="http://www.example.org/XKMS"
      ResultMajor="http://www.w3.org/2002/03/xkms#Success"
      RequestId="I045c66f6c525a9bf3842ecd3466cd422"
      xmlns="http://www.w3.org/2002/03/xkms#">
  <UnverifiedKeyBinding Id="I012f61e1d7b7b9944fe8d954bcb2d946">
    <ds:KeyInfo>
      <ds:KeyValue>
        <ds:RSAKeyValue>
          <ds:Modulus>
            0nIsmR+aVW2egl5MIfOKy4HuMKkk9AZ/IQuDLVPlhzOfgngjVQCjr8uvmnqtNu8
            HBupui8LgGthO6U9D0CNT5mbmhIAErRADUMIAFsi7LzBarUvNWTqYNEJmcHsAUZ
            drdcDrkNnG7SzbuJx+GDNiHKVDQggPBLc1XagW20RMvok=
          </ds:Modulus>
          <ds:Exponent>AQAB</ds:Exponent>
        </ds:RSAKeyValue>
      </ds:KeyValue>
    </ds:KeyInfo>
    <KeyUsage>http://www.w3.org/2002/03/xkms#Signature</KeyUsage>
    <KeyUsage>http://www.w3.org/2002/03/xkms#Encryption</KeyUsage>
    <KeyUsage>http://www.w3.org/2002/03/xkms#Exchange</KeyUsage>
    <UseKeyWith Application="urn:ietf:rfc:2633"
          Identifier="alice@example.com" />
  </UnverifiedKeyBinding>
</LocateResult>

4.2 Le service de validation

[153] Le service de validation (Validate) X-KISS permet tout ce que le service de localisation peut offrir ; le client peut en plus obtenir l'assurance du statut de la liaison entre la clé publique et d'autres données, par exemple, un nom ou un ensemble d'attributs étendus. En outre, le service établit une représentation selon laquelle le statut de chacun des éléments de données est valide et que tous sont liés à la même clé publique. Le client envoie au service XKMS un prototype contenant tout ou partie des éléments pour lesquels le statut de la liaison de clé est nécessaire. Si les informations dans le prototype sont incomplètes, le service XKMS PEUT obtenir les données supplémentaires requises d'un service d'infrastructure à clé publique (PKI) sous-jacent. Une fois la validité de la liaison de clé déterminée, le service XKMS retourne le résultat de statut au client (Figure 3).

[154] Le diagramme montre un service de séquestre agissant comme une passerelle pour des 'services PKI'

[155] Figure 3 : Le service de validation fournit la validation de la clé

4.2.1 Example : La signature d'un document

[156] Bob a reçu le message d'Alice et son client de messagerie a vérifié la signature sur le document par rapport à la clé publique dans le certificat fourni par Alice. Toutefois, on ne sait pas encore si le certificat est digne de confiance. Pour le déterminer, le client de messagerie de Bob envoie la chaîne de certificat à un service de validation XKMS. Le service signale en retour avoir déterminé avec succès que la liaison de clé est liée à un émetteur de confiance et qu'elle n'a pas été révoquée.

[157] Requête :

<?xml version="1.0" encoding="utf-8"?>
<ValidateRequest xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
      xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
      Id="Ie26380bfeb9d0c5bc526d5213a162d46"
      Service="http://www.example.org/XKMS"
      xmlns="http://www.w3.org/2002/03/xkms#">
  <RespondWith>http://www.w3.org/2002/03/xkms#X509Cert</RespondWith>
  <QueryKeyBinding>
    <ds:KeyInfo>
      <ds:X509Data>
        <ds:X509Certificate>
          MIICEDCCAX2gAwIBAgIQimXeUAxYJbJMady9vV1bLjAJBgUrDgMCHQUAMBIxEDA
          OBgNVBAMTB1Rlc3QgQ0EwHhcNMDMwODE1MDcwMDAwWhcNMDUwODE1MDY1OTU5Wj
          ArMSkwJwYDVQQDEyBBbGljZSBBYXJkdmFyayBPPUFsaWNlIENvcnAgQz1VUzCBn
          zANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA0nIsmR+aVW2egl5MIfOKy4HuMKkk
          9AZ/IQuDLVPlhzOfgngjVQCjr8uvmnqtNu8HBupui8LgGthO6U9D0CNT5mbmhIA
          ErRADUMIAFsi7LzBarUvNWTqYNEJmcHsAUZdrdcDrkNnG7SzbuJx+GDNiHKVDQg
          gPBLc1XagW20RMvokCAwEAAaNWMFQwDQYDVR0KBAYwBAMCBkAwQwYDVR0BBDwwO
          oAQAaVOkaVLLKoFmLN37pC8uqEUMBIxEDAOBgNVBAMTB1Rlc3QgQ0GCEC4MndUX
          jPG1TZxVKg+HutAwCQYFKw4DAh0FAAOBgQABU91ka7IlkXCfv4Zh2Ohwgg2yObt
          Y3+6C/BTFGrOEBJDy+DoxJ/NuBF18w3rrrR18xE6jNKYLCQb8zUGk4QOG5Y+HT/
          QTTFvWkiOLXcpTuhnOhXatr42FoYpDkjx2QWK+J5Q2l/Rgjgc/0ZV8U/kD8UuRk
          Xp4AZh7QsiX8AcO0w==
        </ds:X509Certificate>
        <ds:X509Certificate>
          MIIB9zCCAWSgAwIBAgIQLgyd1ReM8bVNnFUqD4e60DAJBgUrDgMCHQUAMBIxEDA
          OBgNVBAMTB1Rlc3QgQ0EwHhcNMDMwODE1MDcwMDAwWhcNMTAwODE1MDcwMDAwWj
          ASMRAwDgYDVQQDEwdUZXN0IENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBg
          QCn23HHp+HtXpiyKVSDtdE3dO0r0oLB/H9sxUEkeXB8oMxwbhdcizWH92zrtm1V
          fVtxkfmwF14ZXoyDZHeZXuCOtAfz/mW6s2gmfD45TfFFVGksDGVRNK5XmKXA5sE
          C51RCvaxzGBdGDlCuVPqX7Cq3IcZpRU1IXbi5YzGwV7j6LwIDAQABo1YwVDANBg
          NVHQoEBjAEAwIHgDBDBgNVHQEEPDA6gBABpU6RpUssqgWYs3fukLy6oRQwEjEQM
          A4GA1UEAxMHVGVzdCBDQYIQLgyd1ReM8bVNnFUqD4e60DAJBgUrDgMCHQUAA4GB
          ABDYD4Fwx2dscu+BgYcZ+GoQQtCJkwJEXytb4zlNl7HLFKbXSw4m0blQquIsfsi
          QgFYAQBXSbu7aeUqqmSGHvILu3BGwVOKjxbHfcM4/MefuTtpOpCN40wy3YwwngD
          tHTaIqm8NwS966PE+W9f8kD70q5FNwf+GF/lX9qGc/x435
        </ds:X509Certificate>
      </ds:X509Data>
    </ds:KeyInfo>
    <KeyUsage>http://www.w3.org/2002/03/xkms#Signature</KeyUsage>
    <UseKeyWith Application="urn:ietf:rfc:2633"
          Identifier="alice@example.com" />
  </QueryKeyBinding>
</ValidateRequest>

[158] Réponse :

<?xml version="1.0" encoding="utf-8"?>
<ValidateResult xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
      xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
      Id="I34ef61b96f7db2250c229d37a17edfc0"
      Service="http://www.example.org/XKMS"
      ResultMajor="http://www.w3.org/2002/03/xkms#Success"
      RequestId="Ie26380bfeb9d0c5bc526d5213a162d46"
      xmlns="http://www.w3.org/2002/03/xkms#">
  <KeyBinding Id="Icf608e9e8b07468fde1b7ee5449fe831">
    <ds:KeyInfo>
      <ds:X509Data>
        <ds:X509Certificate>
          MIICEDCCAX2gAwIBAgIQimXeUAxYJbJMady9vV1bLjAJBgUrDgMCHQUAMBIxEDA
          OBgNVBAMTB1Rlc3QgQ0EwHhcNMDMwODE1MDcwMDAwWhcNMDUwODE1MDY1OTU5Wj
          ArMSkwJwYDVQQDEyBBbGljZSBBYXJkdmFyayBPPUFsaWNlIENvcnAgQz1VUzCBn
          zANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA0nIsmR+aVW2egl5MIfOKy4HuMKkk
          9AZ/IQuDLVPlhzOfgngjVQCjr8uvmnqtNu8HBupui8LgGthO6U9D0CNT5mbmhIA
          ErRADUMIAFsi7LzBarUvNWTqYNEJmcHsAUZdrdcDrkNnG7SzbuJx+GDNiHKVDQg
          gPBLc1XagW20RMvokCAwEAAaNWMFQwDQYDVR0KBAYwBAMCBkAwQwYDVR0BBDwwO
          oAQAaVOkaVLLKoFmLN37pC8uqEUMBIxEDAOBgNVBAMTB1Rlc3QgQ0GCEC4MndUX
          jPG1TZxVKg+HutAwCQYFKw4DAh0FAAOBgQABU91ka7IlkXCfv4Zh2Ohwgg2yObt
          Y3+6C/BTFGrOEBJDy+DoxJ/NuBF18w3rrrR18xE6jNKYLCQb8zUGk4QOG5Y+HT/
          QTTFvWkiOLXcpTuhnOhXatr42FoYpDkjx2QWK+J5Q2l/Rgjgc/0ZV8U/kD8UuRk
          Xp4AZh7QsiX8AcO0w==
        </ds:X509Certificate>
      </ds:X509Data>
    </ds:KeyInfo>
    <KeyUsage>http://www.w3.org/2002/03/xkms#Signature</KeyUsage>
    <KeyUsage>http://www.w3.org/2002/03/xkms#Encryption</KeyUsage>
    <KeyUsage>http://www.w3.org/2002/03/xkms#Exchange</KeyUsage>
    <UseKeyWith Application="urn:ietf:rfc:2633"
          Identifier="alice@example.com" />
    <Status StatusValue="http://www.w3.org/2002/03/xkms#Valid">
      <ValidReason>http://www.w3.org/2002/03/xkms#Signature</ValidReason>
      <ValidReason>http://www.w3.org/2002/03/xkms#IssuerTrust</ValidReason>
      <ValidReason>http://www.w3.org/2002/03/xkms#RevocationStatus</ValidReason>
      <ValidReason>http://www.w3.org/2002/03/xkms#ValidityInterval</ValidReason>
    </Status>
  </KeyBinding>
</ValidateResult>

4.3 Les modalités d'utilisation de la localisation et de la validation

[159] Les opérations de localisation et de validation servent toutes à obtenir des informations à propos d'une clé publique auprès d'un service XKMS. Les services de localisation et de validation sont tous censés fournir des informations exactes au requérant. Ils se distinguent dans la mesure de savoir quel service atteste de la crédibilité des informations retournées.

[160] Un service de localisation DEVRAIT essayer de fournir uniquement des informations crédibles à sa connaissance sans garantir pour autant qu'elles le seront. Les informations obtenues d'un service de localisation NE DEVRAIENT PAS être considérées comme fiables à moins d'avoir été validées. La validation peut être réalisée en faisant suivre les données vers un service de validation ou en effectuant la vérification nécessaire du chemin de confiance localement.

[161] Un service de validation entreprendra de retourner seulement les informations validées positivement par le service XKMS comme satisfaisantes à des critères de validation spécifiques. Un client PEUT se fier aux informations retournées par le service, sans autre vérification, à condition qu'il puisse déterminer que ces informations sont authentiques et qu'il soit sûr que le service de validation a appliqué les moyens de validation appropriés aux circonstances.

[162] Il n'existe pas de jeu de critères de validation universel applicable en toutes circonstances. Les applications faisant intervenir des transactions financières exigeront vraisemblablement des critères de validation très spécifiques afin de s'assurer que certains aspects contractuels et/ou règlementaires soient respectés. Le service de localisation offre une fonction de recherche de clé, indépendante des critères de validation, que l'application cliente peut utiliser. Le service de validation offre une fonction de recherche et de validation de clé produisant des résultats dont chacun est propre à un seul jeu de critères de validation.

4.3.1 L'intégration du système DNS

[163] Dans beaucoup de cas, les informations de clé demandées par un client sont liées à une certaine forme d'adresse, indiquée par un protocole Internet, dont une partie se compose d'une adresse DNS. Par exemple, un client de messagerie peut demander une clé fiable afin d'envoyer un courrier crypté à bob@example.com. À moins que ne soit connu a priori un service XKMS fournissant des informations de clé concernant les clés liées aux adresses de courrier électronique du domaine example.com, il faudra disposer d'un moyen de localiser le bon service XKMS.

[164] La figure 5 4 montre un exemple d'utilisation d'un enregistrement de service SRV DNS pour rechercher les services XKMS. Le client de messagerie demande une clé pour bob@example com à un service de validation de confiance. Le service de validation interroge alors le système DNS afin de localiser un service XKMS fournissant des informations sur les clés liées aux adresses dans la zone example.com. Le service de validation n'ayant pas de relation de confiance établie avec le service XKMS de example.com, une requête de localisation va donc être faite afin de déterminer si on peut localiser éventuellement des informations de clé liées à bob@example.com. Le service de validation valide alors les informations reçues par ce moyen comme étant adéquates (par exemple, en vérifiant qu'une chaîne de certification puisse être construite à partir d'un certificat racine) et cette réponse est retournée au client de messagerie.

[165] Cf. la légende de la figure

[166] Figure 5 4 : L'utilisation combinée d'un service de localisation et de validation

[167] L'annexe B fournit d'autres renseignements pour l'utilisation de l'enregistrement de service DNS.

5 Le jeu de messages des services d'informations de clés

[168] Le protocole consiste en couples de messages, une aplication envoyant un message de requête à un service XKMS et le service répondant par un autre message.

5.1 La spécification des liaisons de clé

[169] Une liaison de clé atteste d'une association entre des éléments de données en rapport avec une clé publique, laquelle est composée d'éléments <ds:KeyName>, <ds:KeyValue> et <ds:X509Data> contenus dans un élément <ds:KeyInfo>. En outre, le service exerce, pour le client accédant au service et pour ce client seul, une représentation selon laquelle la liaison entre les éléments de données est valide, quelle que soit la politique de confiance offerte par le service à ce client.

[170] La spécification XKMS définit quatre éléments qui indiquent des liaisons de clé, tous étant dérivés du type KeyBindingAbstractType. Ces éléments sont :

UnverifiedKeyBinding
Indique les paramètres d'une instance particulière d'une liaison de clé mais pas le statut.
KeyBinding
Indique les paramètres d'une instance particulière d'une liaison de clé.
QueryKeyBinding
Un modèle employé pour spécifier une ou plusieurs liaisons de clé en utilisant une interrogation par l'exemple.
PrototypeKeyBinding
Un modèle employé pour spécifier les paramètres de la liaison de clé demandée dans une requête d'enregistrement.

[171] Un service XKMS PEUT offrir une interface pour une architecture à clé publique (PKI) telles que PKIX ou PGP. Cette spécification ne définit pas comment les opérations XKMS interagissent avec l'architecture PKI sous-jacente. La liaison de clé XKMS PEUT être liée à un objet de données, tels qu'un certificat ou une signature de clé dans l'architecture PKI sous-jacente, de telle sorte que les opérations XKMS sur la liaison de clé produisent un changement correspondant des structures de données dans l'architecture PKI sous-jacente et vice versa. Si, par exemple, le service XKMS fournit une application vers une architecture PKI sous-jacente PKIX/X.509, l'enregistrement d'une liaison de clé se concrétisera typiquement par l'émission d'un certificat, même si le client ne demande pas le retour du certificat dans le résultat d'enregistrement. Si la liaison de clé est révoquée par la suite, le certificat correspondant dans l'architecture PKI sous-jacente le sera typiquement aussi.

5.1.1 Le type abstrait KeyBindingAbstractType

[172] Le type KeyBindingAbstractType est le type abstrait à partir duquel tous les spécificateurs des éléments de liaison de clé XKMS sont dérivés. Il contient les éléments et attributs suivants :

Id (optionnel)
L'identificateur de la liaison de clé.
<ds:KeyInfo> (optionnel)
Les informations de clé publique auxquelles les informations de liaison de clé sont liées.
<KeyUsage> [0 à 3]
Les usages cryptographiques pour lesquels la clé peut servir.
<UseKeyWith> (un nombre quelconque)
Les applications pour lesquelles la clé peut être utilisée avec l'identificateur de sujet spécifique de l'application du gardien de la clé de cette application.

[173] L'identificateur Id est défini afin de pouvoir signer la liaison de clé en utilisant une signature XML. Les clients NE DOIVENT PAS compter que l'identificateur de la liaison de clé soit unique ou bien stable. Au cas où le service XKMS fournirait une interface vers une architecture PKI sous-jacente, les clients NE DOIVENT PAS compter sur le service pour qu'il choisisse les mêmes identificateurs de liaison de clé ou bien qui revêtent une relation systématique avec les numéros de série, ou d'autres identificateurs, des autorisations correspondantes dans l'architecture PKI sous-jacente.

[174] Le schéma suivant définit le type KeyBindingAbstractType :

   <!-- KeyBindingAbstractType-->
   <complexType name="KeyBindingAbstractType" abstract="true">
      <sequence>
         <element ref="ds:KeyInfo" minOccurs="0"/>
         <element ref="xkms:KeyUsage" minOccurs="0" maxOccurs="3"/>
         <element ref="xkms:UseKeyWith" minOccurs="0"
               maxOccurs="unbounded"/>
      </sequence>
      <attribute name="Id" type="ID" use="optional"/>
   </complexType>
   <!-- /KeyBindingAbstractType-->

5.1.2 L'élément <KeyUsage>

[175] L'élément <KeyUsage> indique un ou plusieurs usages prévus pour la clé. Si aucun élément <KeyUsage> n'est présent, alors tous les usages sont permis. Voici les usages de clé définis :

Encryption
Le couple de clés peut servir pour le chiffrement et le déchiffrement.
Signature
Le couple de clés peut servir pour la signature et la vérification.
Exchange
Le couple de clés peut servir pour l'échange de clés.

[176] Si un élément KeyBinding indique un usage de clé non géré par l'algorithme cryptographique associé à la clé, alors l'élément DOIT être ignoré. Si un élément QueryKeyBinding indique un usage de clé, l'usage de clé ne formera toutefois qu'une partie des critères que le service devrait évaluer.

[177] Par exemple, si un élément KeyBinding indique l'usage de clé Encryption pour une clé DSA (Digital Signature Algorithm), l'application utilisatrice devrait ignorer l'élément d'usage de clé. Inversement, si un client fait une requête qui contient un élément QueryKeyBinding indiquant un usage de clé Encryption, alors le service ne devrait pas retourner une clé DSA.

[178] Le schéma suivant définit l'élément <KeyUsage> :

   <!-- KeyUsage -->
   <simpleType name="KeyUsageEnum">
      <restriction base="anyURI">
         <enumeration value="http://www.w3.org/2002/03/xkms#Encryption"/>
         <enumeration value="http://www.w3.org/2002/03/xkms#Signature"/>
         <enumeration value="http://www.w3.org/2002/03/xkms#Exchange"/>
      </restriction>
   </simpleType>

   <element name="KeyUsage" type="xkms:KeyUsageEnum"/>
   <!-- /KeyUsage -->

5.1.3 L'élément <UseKeyWith>

[179] L'élément <UseKeyWith> indique un identificateur de sujet et un identificateur d'application qui déterminent l'usage de la clé. L'interprétation de l'élément <UseKeyWith> dépend de la structure englobante.

QueryKeyBinding / PrototypeKeyBinding
On demande une liaison de clé qui satisfasse aux critères indiqués. Si le service est incapable de satisfaire exactement aux critères, alors la meilleure estimation est acceptable.
UnverifiedKeyBinding / KeyBinding
La clé peut servir pour l'usage indiqué (si non vérifiée après la validation). Si plusieurs éléments <UseKeyWith> sont spécifiés, alors tous sont applicables solidairement et individuellement.

[180] L'élément <UseKeyWith> contient les attributs suivants :

Application (obligatoire)
Une adresse URI qui spécifie le protocole d'application avec lequel la clé peut être utilisée.
Identifier (obligatoire)
Spécifie le sujet auquel la clé correspond au sein du protocole d'application indiqué.

[181] Remarquez que dans certaines applications, notamment X.509, l'identificateur d'application n'est pas garanti globalement unique. Auquel cas, le service XKMS a la responsabilité de définir des règles afin d'interpréter les identificateurs sans ambiguïté.

[182] Le tableau suivant liste les adresses URI d'application pour les protocoles d'application courants et le format correspondant des identificateurs :

Application Adresse URIde l'application Identificateur Type
XKMS http://www.w3.org/2002/03/xkms# Adresse URL identifiant un rôle SOAP AdresseURI
XKMS/profil http://www.w3.org/2002/03/xkms#profil Adresse URL identifiant un rôle SOAP Adresse URI
S/MIME urn:ietf:rfc:2633 Adresse de courrier SMTP du sujet Spécification d'adresse (addr-spec) RFC822
PGP urn:ietf:rfc:2440 Adresse de courrier SMTP du sujet Spécification d'adresse (addr-spec) RFC822
TLS urn:ietf:rfc:2246 Adresse URI identifiant le sujet du certificat Adresse URI
TLS/HTTPS urn:ietf:rfc:2818 Adresse DNS du serveur HTTP Adresse DNS
TLS/SMTP urn:ietf:rfc:2487 Adresse DNS du serveur de messagerie Adresse DNS
IPSEC urn:ietf:rfc:2401 Adresse IP de la ressource Internet Adresse IP
PKIX urn:ietf:rfc:2459 Nom du sujet de certificat (Certificate Subject Name) Nom distingué X.509 (Distinguished Name)

[183] L'adresse URI de l'application XKMS sert à indiquer une liaison de clé utilisée pour sécuriser un service XKMS. Les services XKMS DEVRAIENT gérer la recherche des profils de sécurité reconnus et des liaisons de clé correspondantes au moyen d'une opération de localisation (Locate) qui spécifie l'adresse URI de l'application XKMS et l'adresse URL du rôle du service. Remarquez que, ainsi que pour toutes les autres opérations de localisation, les autorisations retournées par ce mécanisme DEVRAIENT être considérées comme fiables seulement après avoir été validées et conformément à la politique de confiance du client.

[184] Les identificateurs <UseKeyWith> servent principalement à identifier des protocoles d'application. Les identificateurs d'adresse URI <UseKeyWith> PEUVENT être spécifiés pour représenter une émission de liaison de clé et/ou des politiques d'utilisation, à la place ou en plus d'un protocole d'application. Auquel cas, l'élément <UseKeyWith> indique que la liaison de clé est conforme à la politique spécifiée. Par exemple, les applications gérant les signatures conformes à la spécification XAdES [XAdES] pourraient définir leurs propres valeurs d'application <UseKeyWith>.

[185] Au cas où le client suit un modèle directif, selon lequel les informations de liaison de clé brutes sont obtenues d'un service de localisation puis retransmises à un service de validation, les éléments <UseKeyWith> de l'interrogation devraient, dans les deux cas, indiquer les usages pour lesquels l'application prévoit d'utiliser la clé. Les applications NE DEVRAIENT PAS faire suivre les éléments <UseKeyWith> retournés par un résultat de localisation dans une interrogation de validation à suivre.

[186] Le tableau suivant décrit le format des types d'identificateurs spécifiés :

Type d'identificateur Exemple Description
RFC822 addr-spec bob@example.com Le fragment addr-spec d'une adresse de courrier électronique RFC 822 comme utilisée par le protocole SMTP
Adresse URI https://example.com/ Un identificateur de ressource uniforme (URI)
Adresse DNS example.com Une adresse DNS Internet
Adresse IP 10.23.0.20 Une adresse IPv4 en notation décimale
1080::8:800:200C:417A Une adresse IPv6 dans la notation RFC 2373
X.509 Distinguished Name C="UK" O="CryptoGuys Ltd." CN="Bob" Un nom distingué X.509

[187] Le schéma suivant définit l'élément <UseKeyWith> :

   <!-- UseKeyWith -->
   <element name="UseKeyWith" type="xkms:UseKeyWithType"/>
   <complexType name="UseKeyWithType">
      <attribute name="Application" type="anyURI" use="required"/>
      <attribute name="Identifier" type="string" use="required"/>
   </complexType>
   <!-- /UseKeyWith -->

5.1.4 L'élément <UnverifiedKeyBinding>

[188] L'élément <UnverifiedKeyBinding> est dérivé du type KeyBindingAbstractType. Il décrit une liaison de clé mais n'affirme rien à propos du statut de la liaison de clé.

[189] L'élément <UnverifiedKeyBinding> étend le type KeyBindingAbstractType avec l'élément supplémentaire suivant :

<ValidityInterval> (optionnel)
L'intervalle de temps pour lequel les relations de la liaison de clé doivent être valides.

[190] Le schéma suivant définit l'élément <UnverifiedKeyBinding> et le type UnverifiedKeyBindingType :

   <!-- UnverifiedKeyBinding -->
   <element name="UnverifiedKeyBinding"
         type="xkms:UnverifiedKeyBindingType"/>
   <complexType name="UnverifiedKeyBindingType">
      <complexContent>
         <extension base="xkms:KeyBindingAbstractType">
            <sequence>
               <element ref="xkms:ValidityInterval" minOccurs="0"/>
            </sequence>
         </extension>
      </complexContent>
   </complexType>
   <!-- /UnverifiedKeyBinding -->

5.1.5 L'élément <ValidityInterval>

[191] L'élément <ValidityInterval> spécifie les limites de la validité de la liaison de clé.

NotBefore (optionnel)
La date du début de l'intervalle de validité.
NotOnOrAfter (optionnel)
La date de la fin de l'intervalle de validité.

[192] Toutes les valeurs de type dateTime DOIVENT représenter une date complète.

[193] Les attributs NotBefore et NotOnOrAfter sont optionnels. Si l'attribut NotBefore est omis, alors la liaison de clé est valide pour toute date jusqu'à la date indiquée par l'attribut NotOnOrAfter, celle-ci étant exclue. Si l'attribut NotOnOrAfter est omis, alors la liaison de clé est valide à partir de la date indiquée par l'attribut NotBefore et n'expire pas. Si les deux sont omis, alors la liaison de clé est tout le temps valide.

[194] Conformément à la spécification XML Schema, toutes les instances de temps s'interprètent dans le temps universel coordonné (UTC), sauf si celles-ci indiquent explicitement un fuseau horaire.

[195] Les mises en œuvre NE DOIVENT PAS générer d'instances de temps qui spécifient des fractions de secondes.

[196] Pour les comparaisons, l'intervalle de temps de NotBefore à NotOnOrAfter commence dès le premier instant compatible avec la spécification de l'attribut NotBefore et se terminera au dernier instant compatible avec la spécification de l'attribut NotOnOrAfter

[197] Par exemple, si on spécifie un intervalle de temps de aaaa-mm-jjT12:03:02 à aaaa-mm-jjT12:05:12, les instants 12:03:02.00 et 12:05:11.9999 seront compris dans l'intervalle. L'instant 12:05:12.0000 se trouve hors de l'intervalle.

[198] Le schéma suivant définit l'élément <ValidityInterval> :

   <!-- ValidityInterval -->
   <element name="ValidityInterval" type="xkms:ValidityIntervalType"/>
   <complexType name="ValidityIntervalType">
      <attribute name="NotBefore" type="dateTime" use="optional"/>
      <attribute name="NotOnOrAfter" type="dateTime" use="optional"/>
   </complexType>
   <!-- /ValidityInterval -->

5.1.6 L'élément <KeyBinding>

[199] L'élément <KeyBinding> est dérivé du type UnverifiedKeyBindingType. Il spécifie une instance particulière d'une liaison de clé et de son statut courant tel qu'il apparaît à l'émetteur de la liaison de clé.

[200] L'élément <KeyBinding> étend le type UnverifiedKeyBindingType avec l'élément supplémentaire suivant :

<Status> (obligatoire)
Le statut de l'instance de liaison de clé.

[201] Le schéma suivant définit l'élément <KeyBinding> et le type KeyBindingType :

   <!-- KeyBinding -->
   <element name="KeyBinding" type="xkms:KeyBindingType"/>
   <complexType name="KeyBindingType">
      <complexContent>
         <extension base="xkms:UnverifiedKeyBindingType">
            <sequence>
               <element ref="xkms:Status"/>
            </sequence>
         </extension>
      </complexContent>
   </complexType>
   <!-- /KeyBinding -->

5.1.7 L'élément <Status>

[202] L'élément <Status> indique le statut d'une instance <KeyBinding>.

[203] Le valeur de statut PEUT être complétée par des codes qui indiquent le statut d'aspects spécifiques du statut de la liaison de clé, ces aspects ayant été validés.

[204] L'élément <Status> contient les éléments et attributs suivants :

<ValidReason> (un nombre quelconque)
Un aspect du statut qui a été évalué et trouvé valide.
<IndeterminateReason> (un nombre quelconque)
Un aspect du statut qui n'a pas pu être évalué, ou qui l'a été et a retourné un résultat indéterminé.
<InvalidReason> (un nombre quelconque)]
Un aspect du statut qui a été évalué et trouvé invalide.
StatusValue (obligatoire)
Le statut de la liaison de clé.

[205] Le type énuméré KeyBindingEnum sert à indiquer le statut de la liaison de clé. Les valeurs suivantes sont définies :

Valid
La liaison de clé est définitivement valide.
Indeterminate
Le statut de la liaison de clé ne peut pas être déterminé.
Invalid
La liaison de clé est définitivement invalide.

[206] Si des codes de raison sont indiqués, alors l'attribut StatusValue DOIT être cohérent avec eux comme suit :

[206a] Remarquez que les éléments KeyBinding X-KRSS de révocation (Revoke), de réémission (Reissue) et de récupération (Recover) sont tous du type KeyBindingType, lequel exige la présence d'un élément Status (cf. la section 7). Dans le cas des requêtes Reissue, Revoke et Recover, les serveurs PEUVENT ignorer une valeur de statut Indeterminate pour l'attribut <Status> et les clients PEUVENT fixer une valeur de statut Indeterminate.

[207] Le schéma suivant définit l'élément <Status> et les types StatusType et AssertionType :

   <!-- Status -->
   <element name="Status" type="xkms:StatusType"/>
   <complexType name="StatusType">
      <sequence>
         <element ref="xkms:ValidReason" minOccurs="0"
               maxOccurs="unbounded"/>
         <element ref="xkms:IndeterminateReason" minOccurs="0"
               maxOccurs="unbounded"/>
         <element ref="xkms:InvalidReason" minOccurs="0"
               maxOccurs="unbounded"/>
      </sequence>
     
      <attribute name="StatusValue" type="xkms:KeyBindingEnum" use="required"/>
   </complexType>
   
   <simpleType name="KeyBindingEnum">
      <restriction base="anyURI">
         <enumeration value="http://www.w3.org/2002/03/xkms#Valid"/>
         <enumeration value="http://www.w3.org/2002/03/xkms#Invalid"/>
         <enumeration value="http://www.w3.org/2002/03/xkms#Indeterminate"/>
      </restriction>
   </simpleType>
   <!-- /Status -->

5.1.8 Les éléments <ValidReason>, <InvalidReason> et <IndeterminateReason>

[208] Les éléments <ValidReason>, <InvalidReason> et <IndeterminateReason> servent à spécifier une valeur de type anyURI qui indique la raison du statut d'une clé de liaison particulière.

[209] Les aspects du statut sont définis dans le tableau suivant. Par commodité, on donne les étapes équivalentes du traitement X.509 :

Type anyURI de la raison (à préfixer de http://www.w3.org/2002/03/xkms#) Description Équivalent X.509
Valid Invalid
IssuerTrust L'émetteur des informations sur lesquelles la liaison de clé est basée est considéré comme étant crédible par le service XKMS Le chemin de certification, ancré sur un certificat racine éprouvé, a été construit avec succès Le chemin de certification n'a pas pu être construit sur un certificat racine éprouvé
RevocationStatus Le service XKMS a vérifié formellement le statut de la liaison de clé auprès d'une source autorisée Le statut du certificat est validé en utilisant une liste de révocation de certificats (CRL) ou le protocole OCSP Le statut du certificat est retourné : révoqué ou suspendu.
ValidityInterval L'instant de la requête se trouvait dans l'intervalle de validité de la liaison de clé La chaîne de certification était valide au moment de la requête La requête a eu lieu avant ou après l'intervalle de validité de la chaîne de certification
Signature La signature sur les données signées fournies par le client dans l'élément <Keyinfo> a été vérifiée avec succès. La signature du certificat est vérifiée La vérification de la signature du certificat a échoué

[210] Le schéma suivant définit les éléments <ValidReason>, <InvalidReason> et <IndeterminateReason> :

   <!-- Reason -->
   <simpleType name="ReasonEnum">
       <restriction base="anyURI">
            <enumeration value="http://www.w3.org/2002/03/xkms#IssuerTrust"/>
            <enumeration value="http://www.w3.org/2002/03/xkms#RevocationStatus"/>
            <enumeration value="http://www.w3.org/2002/03/xkms#ValidityInterval"/>
            <enumeration value="http://www.w3.org/2002/03/xkms#Signature"/> 
       </restriction>
    </simpleType>
    <simpleType name="ReasonOpenEnum">
       <union memberTypes="xkms:ReasonEnum anyURI"/>
   </simpleType>
   <element name="ValidReason" type="xkms:ReasonOpenEnum"/>
   <element name="InvalidReason" type="xkms:ReasonOpenEnum"/>
   <element name="IndeterminateReason" type="xkms:ReasonOpenEnum"/>
   <!-- /Reason -->

5.1.9 L'élément <QueryKeyBinding>

[211] L'élément <QueryKeyBinding>, qui est dérivé du type KeyBindingAbstractType, sert à effectuer une recherche dont le résultat consiste en une ou plusieurs liaison de clé concordantes.

[212] Une liaison de clé correspond à l'élément QueryKeyBinding si :

[213] L'élément <QueryKeyBinding> étend le type KeyBindingAbstractType avec les éléments supplémentaires suivants :

<TimeInstant> (optionnel)
L'instant où l'interrogation a lieu. Si aucun instant n'est spécifié, la valeur par défaut est l'instant où la requête a été faite. Un service qui ne gère pas l'élément TimeInstant DOIT retourner un résultat Receiver.TimeInstantNotSupported. En outre, un service gérant l'élément TimeInstant peut se trouver incapable ou refuser de répondre aux requêtes indiquant un instant hors d'un certain intervalle. Auquel cas, le service DOIT retourner un résultat Sender.TimeInstantOutOfRange.

[214] Le schéma suivant définit l'élément <QueryKeyBinding> et le type KeyBindingType :

   <!-- QueryKeyBinding -->
   <element name="QueryKeyBinding" type="xkms:QueryKeyBindingType"/>
   <complexType name="QueryKeyBindingType">
      <complexContent>
         <extension base="xkms:KeyBindingAbstractType">
            <sequence>
               <element ref="xkms:TimeInstant" minOccurs="0"/>
            </sequence>
         </extension>
      </complexContent>
   </complexType>
   <!-- /QueryKeyBinding -->

5.1.10 L'élément <TimeInstant>

[215] L'élément <TimeInstant> spécifie un instant particulier dans le temps pendant lequel une interrogation de liaison de clé est faite. L'élément <TimeInstant> contient l'attribut suivant :

Time (obligatoire)
L'instant auquel l'élément <QueryKeyBinding> se rapporte.

[216] Toutes les valeurs de type dateTime DOIVENT spécifier une date complète.

[217] Le schéma suivant définit l'élément <TimeInstant> :

   <!-- TimeInstant -->
   <element name="TimeInstant" type="xkms:TimeInstantType"/>
   <complexType name="TimeInstantType">
      <attribute name="Time" type="dateTime" use="required"/>
   </complexType>
   <!-- /TimeInstant -->

5.2 Le service de localisation

[218] Le service de localisation accepte en entrée un élément <QueryKeyBinding> qui spécifie une liaison de clé et retourne un ou plusieurs éléments <UnverifiedKeyBinding> qui se rapportent à la même clé publique. Les éléments <UnverifiedKeyBinding> retournés sont spécifiés par l'élément RespondWith dans la requête.

5.2.1 L'élément <LocateRequest> de la requête de localisation

[219] Le message de la requête de localisation contient un élément <LocateRequest> contenant l'élément suivant 

<QueryKeyBinding> (obligatoire)
La liaison de clé à laquelle correspondre dans la réponse.

[220] Le schéma suivant définit l'élément <LocateRequest> :

   <!-- LocateRequest -->
   <element name="LocateRequest" type="xkms:LocateRequestType"/>
   <complexType name="LocateRequestType">
      <complexContent>
         <extension base="xkms:RequestAbstractType">
            <sequence>
               <element ref="xkms:QueryKeyBinding"/>
            </sequence>
         </extension>
      </complexContent>
   </complexType>
   <!-- /LocateRequest -->

5.2.2 L'élément <LocateResult> de la réponse de localisation

[221] Le message de la réponse de localisation contient un élément <LocateResult> pouvant contenir l'élément suivant :

<UnverifiedKeyBinding> (un nombre quelconque)
Une séquence de liaisons de clé <UnverifiedKeyBinding> lesquelles concordent avec la recherche de liaison de clé spécifiée dans la requête correspondante. Si la recherche ne produit aucun résultat, la séquence est vide et le code de résultat NoMatch est retourné. Dans certains cas, une opération de localisation (Locate) PEUT retourner plusieurs résultats concordants.

[222] Le schéma suivant définit l'élément <LocateResult> :

   <!-- LocateResult -->
   <element name="LocateResult" type="xkms:LocateResultType"/>
   <complexType name="LocateResultType">
      <complexContent>
         <extension base="xkms:ResultType">
            <sequence>
               <element ref="xkms:UnverifiedKeyBinding" minOccurs="0"
                     maxOccurs="unbounded"/>
            </sequence>
         </extension>
      </complexContent>
   </complexType>
   <!-- /LocateResult -->

5.3 Le service de validation

[223] Le service de validation (Validate) permet au client de rechercher la liaison entre un élément <ds:Keyinfo> et d'autres données tel qu'un identificateur. Le client fournit un prototype pour la liaison de clé demandée. Le prototype peut spécifier un élément <ds:Keyinfo>, ou un (ou plusieurs) élément(s) <UseKeyWith>, ou les deux. Si la requête en validation réussit, le serveur retourne un ou plusieurs éléments <KeyBinding> qui satisfont aux critères spécifiés dans la requête.

5.3.1 L'élément <ValidateRequest> de la requête de validation

[224] Le message de la requête de validation contient un élément <ValidateRequest> contenant l'élément suivant :

<QueryKeyBinding> (obligatoire)
La liaison de clé à laquelle correspondre dans la réponse.

[225] Le schéma suivant définit l'élément <ValidateRequest> :

   <!-- ValidateRequest -->
   <element name="ValidateRequest" type="xkms:ValidateRequestType"/>
   <complexType name="ValidateRequestType">
      <complexContent>
         <extension base="xkms:RequestAbstractType">
            <sequence>
               <element ref="xkms:QueryKeyBinding"/>
            </sequence>
         </extension>
      </complexContent>
   </complexType>
   <!-- /ValidateRequest -->

5.3.2 L'élément <ValidateResult> de la réponse de validation

[226] Le message de la réponse de validation contient un élément <ValidateResult> pouvant contenir l'élément suivant :

<Keybinding> (un nombre quelconque)
Une séquence de liaisons de clé <KeyBinding> lesquelles concordent avec la recherche de liaison de clé spécifiée dans la requête correspondante. Si la recherche ne produit aucun résultat, la séquence est vide et le code de résultat NoMatch est retourné. Dans certains cas, une opération de validation (Validate) PEUT retourner plusieurs résultats concordants.

[227] Le schéma suivant définit l'élément <ValidateResult> et le type ValidateResultType :

   <!-- ValidateResult -->
   <element name="ValidateResult" type="xkms:ValidateResultType"/>
   <complexType name="ValidateResultType">
      <complexContent>
         <extension base="xkms:ResultType">
            <sequence>
               <element ref="xkms:KeyBinding" minOccurs="0"
                     maxOccurs="unbounded"/>
            </sequence>
         </extension>
      </complexContent>
   </complexType>
   <!-- /ValidateResult -->

6 La description des services d'enregistrement de clés

[228] La spécification des services d'enregistrement de clés XML (X-KRSS) permet de gérer les informations liées à un couple de clés public. La spécification X-KRSS permet les opérations suivantes :

L'enregistrement (Register)
Les informations sont liées à un couple de clés public au moyen d'une liaison de clé.
La réémission (Reissue)
Une liaison de clé enregistrée précédemment est réémise.
La révocation (Revoke)
Une liaison de clé enregistrée précédemment est révoquée.
La récupération (Recover)
La clé privée associée à une liaison de clé est récupérée.

[229] Un service XKMS peut offrir tout ou partie de ces services.

[230] L'opération d'enregistrement (Register) n'est assortie en elle-même d'aucune obligation pour le service d'enregistrement de communiquer cette information à un tiers. Toutefois, pour la plupart des applications, le service d'enregistrement fournira les informations de clé à d'autres services Web, tels que ceux décrit dans la spécification XKMS, ou à une architecture PKI sous-jacente, telle que PKIX.

[231] L'opération d'enregistrement (Register) PEUT intervenir selon un mode où les requêtes du client sont acceptées par un intermédiaire, telle qu'une autorité d'enregistrement locale (LRA), puis transmises à une autorité d'enregistrement centrale (MRA). Ce mode opératoire est entièrement transparent pour le client qui agit comme si l'autorité locale était la seule autorité d'enregistrement concernée. La construction de la preuve de possession (POP) de la clé privée et les informations d'authentification sont totalement séparées de la signature du message d'authentification. Cela permet à la fois une vérification par l'autorité d'enregistrement locale et par toute autre autorité d'enregistrement vers laquelle le message aurait été relayé, même si l'autorité locale remplaçait la signature du message d'authentification.

6.1 L'enregistrement

[232] La requête d'enregistrement (Register) sert à affirmer une association d'informations en relation à un couple de clés public. La génération du couple de clés public PEUT être accomplie par le client ou bien par le service d'enregistrement.

[233] Le message de la requête d'enregistrement contient un prototype de la liaison de clé demandée. Le service d'enregistrement PEUT imposer au client de fournir des informations supplémentaires afin d'authentifier la requête. Si le couple de clés public est généré par le client, le service PEUT imposer au client de fournir une preuve de possession (POP) de la clé privée.

[234] Le prototype de la liaison de clé demandée peut ne contenir que des informations partielles, une clé anonyme ou un nom sans clé. Auquel cas, le client demande au service d'enregistrement de fournir les informations complémentaires nécessaires pour achever la liaison. Toutes les informations contenues dans le prototype de la liaison de clé demandée sont consultatives et le service PEUT les ignorer ou les modifier à sa guise.

[235] À réception d'une requête d'enregistrement, le service vérifie les informations d'authentification et de preuve de possession (le cas échéant). Si le service d'enregistrement accepte la requête, la liaison de clé est enregistrée. Cette liaison de clé PEUT inclure tout ou une partie, voire aucune des informations fournies par le prototype de liaison de clé et elle PEUT inclure d'autres informations.

[236] Le service d'enregistrement PEUT retourner tout ou partie de la liaison de clé enregistrée au client.

[237] Un diagramme montrant les données passées du client au serveur pour l'enregistrement

[238] Figure 5 : L'enregistrement d'une liaison de clé

[239] Le choix de la génération du couple de clés, par le client ou par le service, dépend de l'application et du type de clé. Dans le cas d'une clé destinée à des besoins de signature, il n'est généralement pas souhaitable que chaque partie ait accès à la clé privée, hormis son titulaire. Si l'accès à la clé privée était perdu, une nouvelle clé pourrait être délivrée sans que cela n'affecte la validité des signatures créées avec l'ancienne clé privée. Par conséquent, on préfère habituellement que ces clés soient générées par le client et non par le serveur.

[240] Dans le cas d'une clé privée utilisée exclusivement pour certains types de chiffrement, la perte de l'accès à la clé privée peut se traduire par une perte de l'accès aux données chiffrées au moyen de cette clé. En de telles circonstances, il est généralement souhaitable de pouvoir employer une certaine forme de récupération de clé. Dans ces systèmes, le couple de clé est typiquement généré par le service et livré au client.

[241] Une clé utilisée à la fois pour signature et pour chiffrement peut être générée par le client ou par le serveur, selon que l'on ait besoin d'une faculté de récupération de clé ou pas.

6.1.1 Exemple : L'enregistrement d'un couple de clés généré par le client

[242] Alice demande l'enregistrement d'un couple de clés RSA pour son adresse de courrier Alice@example.com. Auparavant, Alice a reçu du service XKMS le code 024837 avec lequel authentifier sa requête. Alice choisit le mot de passe Help I have revealed my key pour s'authentifier au cas où il lui faudrait révoquer l'enregistrement ultérieurement.

[243] Le message de la requête X-KRSS contient l'élément <RegisterRequest> suivant. Puisque la requête d'enregistrement concerne une clé générée par le client, l'élément Authentication contient à la fois un élément <ProofOfPossession>, lequel démontre que la requête est autorisée par le titulaire de la clé privée, et un élément <KeyBindingAuthentication>, lequel démontre que la requête a été faite par une personne connaissant le code d'authentification 024837.

<?xml version="1.0" encoding="utf-8"?>
<RegisterRequest xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
   xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
   Id="I1494ac4351b7de5c174d455b7000e18f"
   Service="http://www.example.org/XKMS"
   xmlns="http://www.w3.org/2002/03/xkms#">
  <RespondWith>http://www.w3.org/2002/03/xkms#X509Cert</RespondWith>
  <RespondWith>http://www.w3.org/2002/03/xkms#X509Chain</RespondWith>
  <PrototypeKeyBinding Id="I269e655567dbae568591c0a06957529e">
    <ds:KeyInfo>
      <ds:KeyValue>
        <ds:RSAKeyValue>
          <ds:Modulus>
            0nIsmR+aVW2egl5MIfOKy4HuMKkk9AZ/IQuDLVPlhzOfgngjVQCjr8uvmnqtNu8
            HBupui8LgGthO6U9D0CNT5mbmhIAErRADUMIAFsi7LzBarUvNWTqYNEJmcHsAUZ
            drdcDrkNnG7SzbuJx+GDNiHKVDQggPBLc1XagW20RMvok=
          </ds:Modulus>
          <ds:Exponent>AQAB</ds:Exponent>
        </ds:RSAKeyValue>
      </ds:KeyValue>
    </ds:KeyInfo>
    <KeyUsage>http://www.w3.org/2002/03/xkms#Signature</KeyUsage>
    <KeyUsage>http://www.w3.org/2002/03/xkms#Encryption</KeyUsage>
    <KeyUsage>http://www.w3.org/2002/03/xkms#Exchange</KeyUsage>
    <UseKeyWith Application="urn:ietf:rfc:2459"
         Identifier='C="US" O="Alice Corp" CN="Alice Aardvark"' />
    <UseKeyWith Application="urn:ietf:rfc:2633"
         Identifier="alice@example.com" />
    <UseKeyWith Application="http://ca.example.com/cps/20030401/class3"
         Identifier="alice@example.com" />
    <RevocationCodeIdentifier>
      5AEAai06hFJEkuqyDyqNh8k/u3M=
    </RevocationCodeIdentifier>
  </PrototypeKeyBinding>
  <Authentication>
    <KeyBindingAuthentication>
      <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
        <SignedInfo>
          <CanonicalizationMethod 
                  Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
          <SignatureMethod 
                  Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1" />
          <Reference URI="#I269e655567dbae568591c0a06957529e">
            <Transforms>
              <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
            </Transforms>
            <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
            <DigestValue>WCbpkifxJ1zIJ+V6/knZgxRhR34=</DigestValue>
          </Reference>
        </SignedInfo>
        <SignatureValue>iJSKM+98hj5ae+btC2WjwBYP+/k=</SignatureValue>
      </Signature>
    </KeyBindingAuthentication>
  </Authentication>
  <ProofOfPossession>
    <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
      <SignedInfo>
        <CanonicalizationMethod 
                Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
        <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
        <Reference URI="#I269e655567dbae568591c0a06957529e">
          <Transforms>
            <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
          </Transforms>
          <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
          <DigestValue>WCbpkifxJ1zIJ+V6/knZgxRhR34=</DigestValue>
        </Reference>
      </SignedInfo>
      <SignatureValue>
        DcPw742vN120QNrCjCKw0jiCX3pUvbMeRkYjktZkn4nbgo1b7leXU0sJgXM2CY/
        oQugaRsgz18+qUzM0UX+jr1t1wtCMci5fjzVKZB63oZyKZ9+CJLcBCbirsgJAId
        +Pq9w4WiwKDf2AytsdXHlN5V1byQIkpfR1CypvBzQa1b4=
      </SignatureValue>
    </Signature>
  </ProofOfPossession>
</RegisterRequest>

[246] Le service accepte l'enregistrement et retourne la réponse suivante :

<?xml version="1.0" encoding="utf-8"?>
<RegisterResult xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
      xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
      Id="I92ed24772e43843b3d23020ad9ec9754"
      Service="http://www.example.org/XKMS"
      ResultMajor="http://www.w3.org/2002/03/xkms#Success"
      RequestId="I1494ac4351b7de5c174d455b7000e18f"
      xmlns="http://www.w3.org/2002/03/xkms#">
  <KeyBinding Id="Ia26450ebe93f62b3b3ab137fc6a61c36">
    <ds:KeyInfo>
      <ds:X509Data>
        <ds:X509Certificate>
          MIICEDCCAX2gAwIBAgIQimXeUAxYJbJMady9vV1bLjAJBgUrDgMCHQUAMBIxEDA
          OBgNVBAMTB1Rlc3QgQ0EwHhcNMDMwODE1MDcwMDAwWhcNMDUwODE1MDY1OTU5Wj
          ArMSkwJwYDVQQDEyBBbGljZSBBYXJkdmFyayBPPUFsaWNlIENvcnAgQz1VUzCBn
          zANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA0nIsmR+aVW2egl5MIfOKy4HuMKkk
          9AZ/IQuDLVPlhzOfgngjVQCjr8uvmnqtNu8HBupui8LgGthO6U9D0CNT5mbmhIA
          ErRADUMIAFsi7LzBarUvNWTqYNEJmcHsAUZdrdcDrkNnG7SzbuJx+GDNiHKVDQg
          gPBLc1XagW20RMvokCAwEAAaNWMFQwDQYDVR0KBAYwBAMCBkAwQwYDVR0BBDwwO
          oAQAaVOkaVLLKoFmLN37pC8uqEUMBIxEDAOBgNVBAMTB1Rlc3QgQ0GCEC4MndUX
          jPG1TZxVKg+HutAwCQYFKw4DAh0FAAOBgQABU91ka7IlkXCfv4Zh2Ohwgg2yObt
          Y3+6C/BTFGrOEBJDy+DoxJ/NuBF18w3rrrR18xE6jNKYLCQb8zUGk4QOG5Y+HT/
          QTTFvWkiOLXcpTuhnOhXatr42FoYpDkjx2QWK+J5Q2l/Rgjgc/0ZV8U/kD8UuRk
          Xp4AZh7QsiX8AcO0w==
        </ds:X509Certificate>
        <ds:X509Certificate>
          MIIB9zCCAWSgAwIBAgIQLgyd1ReM8bVNnFUqD4e60DAJBgUrDgMCHQUAMBIxEDA
          OBgNVBAMTB1Rlc3QgQ0EwHhcNMDMwODE1MDcwMDAwWhcNMTAwODE1MDcwMDAwWj
          ASMRAwDgYDVQQDEwdUZXN0IENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBg
          QCn23HHp+HtXpiyKVSDtdE3dO0r0oLB/H9sxUEkeXB8oMxwbhdcizWH92zrtm1V
          fVtxkfmwF14ZXoyDZHeZXuCOtAfz/mW6s2gmfD45TfFFVGksDGVRNK5XmKXA5sE
          C51RCvaxzGBdGDlCuVPqX7Cq3IcZpRU1IXbi5YzGwV7j6LwIDAQABo1YwVDANBg
          NVHQoEBjAEAwIHgDBDBgNVHQEEPDA6gBABpU6RpUssqgWYs3fukLy6oRQwEjEQM
          A4GA1UEAxMHVGVzdCBDQYIQLgyd1ReM8bVNnFUqD4e60DAJBgUrDgMCHQUAA4GB
          ABDYD4Fwx2dscu+BgYcZ+GoQQtCJkwJEXytb4zlNl7HLFKbXSw4m0blQquIsfsi
          QgFYAQBXSbu7aeUqqmSGHvILu3BGwVOKjxbHfcM4/MefuTtpOpCN40wy3YwwngD
          tHTaIqm8NwS966PE+W9f8kD70q5FNwf+GF/lX9qGc/x435
        </ds:X509Certificate>
      </ds:X509Data>
    </ds:KeyInfo>
    <KeyUsage>http://www.w3.org/2002/03/xkms#Signature</KeyUsage>
    <KeyUsage>http://www.w3.org/2002/03/xkms#Encryption</KeyUsage>
    <KeyUsage>http://www.w3.org/2002/03/xkms#Exchange</KeyUsage>
    <UseKeyWith Application="urn:ietf:rfc:2459" Identifier='C="US"
          O="Alice Corp" CN="Alice Aardvark"' />
    <UseKeyWith Application="urn:ietf:rfc:2633"
          Identifier="alice@example.com" />
    <UseKeyWith Application="http://ca.example.com/cps/20030401/class3"
          Identifier="alice@example.com" />
    <Status StatusValue="http://www.w3.org/2002/03/xkms#Valid">
      <ValidReason>http://www.w3.org/2002/03/xkms#Signature</ValidReason>
      <ValidReason>http://www.w3.org/2002/03/xkms#IssuerTrust</ValidReason>
      <ValidReason>http://www.w3.org/2002/03/xkms#RevocationStatus</ValidReason>
      <ValidReason>http://www.w3.org/2002/03/xkms#ValidityInterval</ValidReason>
    </Status>
  </KeyBinding>
</RegisterResult>

6.1.2 Exemple : L'enregistrement d'un couple de clés généré par le service

[247] La requête pour l'enregistrement d'un couple de clés générées par un service omet les données de la clé publique et requiert que les données de la clé privée soit retournées avec la réponse.

[248] Bob demande un couple de clés généré par un service après avoir reçu le code d'authentification 3N9CJ-K4JKS-04JWF-0934J-SR09JW-IK4 par le biais d'un certain mécanisme hors-bande. La requête précise seulement les usages de clé Encryption et Exchange dans la mesure où la clé doit être séquestrée en vue d'une possible récupération ultérieure et la politique de sécurité de l'émetteur n'autorise pas le séquestre des clés de signature.

[249] Le serveur génère un couple de clés en réponse à la requête, génère les certificats appropriés et retourne le résultat au client. Ce résultat inclut la valeur de la clé privée cryptée au moyen d'une clé dérivée de la valeur du code d'authentification comme décrit dans la section 8.1 (cf. également l'annexe C.1.3). Le client peut déchiffrer la clé privée en fabriquant la clé de déchiffrement à partir de la valeur du code d'authentification de la même façon que le service.

[250] Afin d'éviter la fuite de la valeur de la clé privée vers des entités non autorisées, il est impératif que le service et le client protège la valeur du code d'authentification d'une divulgation. Le service ne devrait pas réutiliser les valeurs des codes d'authentification et la clé dérivée d'un code d'authentification ne devrait pas servir à chiffrer plus d'une seule communication de clé privée.

[251] La fabrication des données d'authentification et le chiffrement de la clé privée de cet exemple sont décrits dans l'annexe C.

[252] La réponse inclut à la fois les données de la clé publique et la clé privée cryptée :

<?xml version="1.0" encoding="utf-8"?>
<RegisterResult xmlns:ds="http://www.w3.org/2000/09/xmldsig#" 
      xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" 
      Id="I2eb0b29bf38eeecfc5f099c8ca149f98" 
      Service="http://www.example.org/XKMS"
      ResultMajor="http://www.w3.org/2002/03/xkms#Success"
      RequestId="I4e442fc461a83f320d7a3afb4f2454a9" 
      xmlns="http://www.w3.org/2002/03/xkms#">
  <KeyBinding Id="Ia500663f4e4e578447407a38b9049c8b">
    <ds:KeyInfo>
      <ds:X509Data>
        <ds:X509Certificate>
          MIICCTCCAXagAwIBAgIQe0Sk4xr1VolGFFNMkCx07TAJBgUrDgMCHQUAMBIxEDA
          OBgNVBAMTB1Rlc3QgQ0EwHhcNMDMwODE1MDcwMDAwWhcNMDUwODE1MDY1OTU5Wj
          AkMSIwIAYDVQQDExlCb2IgQmFrZXIgTz1Cb2IgQ29ycCBDPVVTMIGfMA0GCSqGS
          Ib3DQEBAQUAA4GNADCBiQKBgQDcUW1ZSy8RqNC3ZJ5IX5G8DFZ08+HkZKVCenxI
          O++q8LATo9dxFasgaZXu3A1/ZNRcLFi7O1RQKUwjLXgHRD6TV6Pad6SZgvv4hzc
          MMZUVVpg+jFpFjRjaVXy06t7KdZ6CkVshNdzxXpjTZB9Hk7s+fX/XQSWyVoX9MX
          wxAapgTwIDAQABo1YwVDANBgNVHQoEBjAEAwIGQDBDBgNVHQEEPDA6gBABpU6Rp
          UssqgWYs3fukLy6oRQwEjEQMA4GA1UEAxMHVGVzdCBDQYIQLgyd1ReM8bVNnFUq
          D4e60DAJBgUrDgMCHQUAA4GBAF4jP1gGDbaq3rg/Vo3JY7EDNTp0HmwLiPMLmdn
          B3WTIGFcjS/jZFzRCbvKPeiPTZ6kRkGgydFOuCo5HMAxIks/LtnKFd/0qYT+AOD
          q/rCrwSx+F+Ro2rf9tPpja9o7gANqxs6Pm7f1QSPZO57bT/6afiVm7NdaCfjgMp
          hb+XNyn
        </ds:X509Certificate>
        <ds:X509Certificate>
          MIIB9zCCAWSgAwIBAgIQLgyd1ReM8bVNnFUqD4e60DAJBgUrDgMCHQUAMBIxEDA
          OBgNVBAMTB1Rlc3QgQ0EwHhcNMDMwODE1MDcwMDAwWhcNMTAwODE1MDcwMDAwWj
          ASMRAwDgYDVQQDEwdUZXN0IENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBg
          QCn23HHp+HtXpiyKVSDtdE3dO0r0oLB/H9sxUEkeXB8oMxwbhdcizWH92zrtm1V
          fVtxkfmwF14ZXoyDZHeZXuCOtAfz/mW6s2gmfD45TfFFVGksDGVRNK5XmKXA5sE
          C51RCvaxzGBdGDlCuVPqX7Cq3IcZpRU1IXbi5YzGwV7j6LwIDAQABo1YwVDANBg
          NVHQoEBjAEAwIHgDBDBgNVHQEEPDA6gBABpU6RpUssqgWYs3fukLy6oRQwEjEQM
          A4GA1UEAxMHVGVzdCBDQYIQLgyd1ReM8bVNnFUqD4e60DAJBgUrDgMCHQUAA4GB
          ABDYD4Fwx2dscu+BgYcZ+GoQQtCJkwJEXytb4zlNl7HLFKbXSw4m0blQquIsfsi
          QgFYAQBXSbu7aeUqqmSGHvILu3BGwVOKjxbHfcM4/MefuTtpOpCN40wy3YwwngD
          tHTaIqm8NwS966PE+W9f8kD70q5FNwf+GF/lX9qGc/x435
        </ds:X509Certificate>
      </ds:X509Data>
    </ds:KeyInfo>
    <KeyUsage>http://www.w3.org/2002/03/xkms#Encryption</KeyUsage>
    <KeyUsage>http://www.w3.org/2002/03/xkms#Exchange</KeyUsage>
    <UseKeyWith Application="urn:ietf:rfc:2459" Identifier='C="UK"
          O="Bob Corp" CN="Bob Baker"' />
    <UseKeyWith Application="urn:ietf:rfc:2633" 
          Identifier="bob@example.com" />
    <Status StatusValue="http://www.w3.org/2002/03/xkms#Valid">
      <ValidReason>http://www.w3.org/2002/03/xkms#Signature</ValidReason>
      <ValidReason>http://www.w3.org/2002/03/xkms#IssuerTrust</ValidReason>
      <ValidReason>http://www.w3.org/2002/03/xkms#RevocationStatus</ValidReason>
      <ValidReason>http://www.w3.org/2002/03/xkms#ValidityInterval</ValidReason>
    </Status>
  </KeyBinding>
  <PrivateKey>
    <xenc:EncryptedData>
      <xenc:EncryptionMethod 
            Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc" />
      <xenc:CipherData>
        <xenc:CipherValue>
          Em6xEIvjjlqqeEVOdf9Fq2E6ycz5OZrUU3jw7fBMhiM8BciSC3qry7GAlvRFp/D
          iD5zZduSaDriD27HGOuWo1fLihgOcw5sw+G9nyhfxKo7IZ2DEss0DD5H3AAZnTW
          reTYwposEBiBcuea4nYwzVWYFsIcplPYsHnXg1cq7MtMfaSu1WA4P/tQLhM1mdO
          V6FHkEHdyL4FBaZbjfmkB1Z++Yb0OlOUTNCQLcNxDkF6lNM75sprB+2FtwG1u9x
          ZnFXwP0Yt5euwCKeBRFm8Sfsf67CTIjKQ0+l9b66l/W1VszBgq2hMgSi8w+qILw
          mFP7p4AhJJNaYlOXHbJAQL6dOe4jtyEkjhEfXXJAO8497Dat9JU5l4Aeb8Mw5BA
          KDBT8RKnQTHqRTQZ8h5FPTapD1Av3KllxrIwRJG155enFrVwlxm6mLD+z4WeAdn
          U5l9gUSaS13E0PlBApi98zDjILihycV1m90SzUNRIuSnw/8tV0ykS3uquDSmNAO
          5YX7UZtieFMyQ2U8XBNRYYftLaN6RfPCejtxXZxIsGtvxyzzL+Yf3bl595J+IOt
          n3M73bBvkdq3ACgOG0SCaETlTE5i60Trw19um+f7gAD4QKXawKw72gyQ70GccML
          Dh4mypfstCbXxCG5nntGAPkCqT/c+t0TdPc7VrtyFLB3ta9z9yiRkeKqvkVZpvb
          lQwykzDd3fgn9ds1liuy8RagrVO6Zczii9b7AQmQ9dekw+QDVkeS53xNTbByau/
          aYAjOjIu4Xb6QNPOrNfHYOLMwGuf19o5nAjZEadZU83QhJq/ofwv3EL7tVMlOpF
          K7n6Apk7cwmS4OtU71cbAVBMcAsh3KbfrHm0TCy67DEZLtdE9ksTekZMpDKXayQ
          uRI0nyKugmwOVvI6oxyMt9JHRiSJRfyYF6yQoyGHGyX8nLX5imG8WNxHBur7j9h
          rt8Nf9XRvXY2N9RRfpoDTexN/KZJIZJhDFsY5gsjs1xy0kZqushvZ+jeElGylXs
          U/CSXwu3fgeM4qTnMKvJvHl9K4KlDtjIyYIRlBt22n238ADjMLFgUWS4+lyoWZ+
          EJPzo0y9CIqb2uUNqp5cSAnb0v7s7gsq6yTqaB9fFSrV0oLH/I65Xoa7XW4mY06
          xgwshdC/HHCaTyP/OEgq5Iv2VZUlWTGp1KuEmfko6MaRB/JqMhjNupi1esYTpre
          JsBexGjBiCpPPieykC8ngC8GEWLRUyWPdDCybiM/CRFdCvgD5n/Js7nkNY0JGLf
          BY0cGnkrxv7e5+5S1Be33yWonJSs8QQ6+y4/V5vPe+5tH8++VFm6dZXtL/oOU0S
          DyHruc0yGmdu9GCibRcaU49rPLWbwSfg/g7mVibah2YBXkDDolW1U6pOpry9fHM
          kEODQrnoIvGZLaOZ8UQ7jnI92WOTySdxylFL2ZvEHadlUKKN2KtW4zs7nhcQ6Tf
          6gjYLNXX9ztkNgCKCZRzI4TXOM2khtPhxTv83rfV0hlx1mtRjlifDdbiWInrCW7
          7IPgMEIkEa1oXoKcYb1pUw+W9xzeTp4hTx16izBqC9aWNSYJrT1AvX/Xa+oY8F4
          p+YGGgOSvn9Cb2h1Va8YTb3ntqWaFSE+0/YyOHYgCIsaeYXV9YFN8A+fw          
        </xenc:CipherValue>
      </xenc:CipherData>
    </xenc:EncryptedData>
  </PrivateKey>
</RegisterResult>

6.2 La réémission

[253] Un service d'enregistrement PEUT autoriser les clients à demander la réémission de liaisons de clé précédemment émises. Une requête de réémission est similaire au premier enregistrement d'une clé.

[254] La raison principale pour laquelle un client ferait une requête de réémission est d'inciter le service d'enregistrement à générer de nouvelles autorisations dans l'architecture PKI sous-jacente, par exemple, des certificats X.509.

6.2.1 Exemple : La réémission

[255] Alice demande la réémission de son couple de clés RSA précédemment émis pour son adresse de courrier électronique.

[256] Le message de la requête X-KRSS contient l'élément <ReissueRequest> suivant :

<?xml version="1.0" encoding="utf-8"?>
<ReissueRequest xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
      xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
      Id="I3a682dfb94cc8e9b3b648026783a8094"
      Service="http://www.example.org/XKMS"
      xmlns="http://www.w3.org/2002/03/xkms#">
  <RespondWith>http://www.w3.org/2002/03/xkms#X509Cert</RespondWith>
  <RespondWith>http://www.w3.org/2002/03/xkms#X509Chain</RespondWith>
  <ReissueKeyBinding Id="I518fc89b03369bccec3d1ee9d985c436">
    <ds:KeyInfo>
      <ds:X509Data>
        <ds:X509Certificate>
          MIICEDCCAX2gAwIBAgIQimXeUAxYJbJMady9vV1bLjAJBgUrDgMCHQUAMBIxEDA
          OBgNVBAMTB1Rlc3QgQ0EwHhcNMDMwODE1MDcwMDAwWhcNMDUwODE1MDY1OTU5Wj
          ArMSkwJwYDVQQDEyBBbGljZSBBYXJkdmFyayBPPUFsaWNlIENvcnAgQz1VUzCBn
          zANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA0nIsmR+aVW2egl5MIfOKy4HuMKkk
          9AZ/IQuDLVPlhzOfgngjVQCjr8uvmnqtNu8HBupui8LgGthO6U9D0CNT5mbmhIA
          ErRADUMIAFsi7LzBarUvNWTqYNEJmcHsAUZdrdcDrkNnG7SzbuJx+GDNiHKVDQg
          gPBLc1XagW20RMvokCAwEAAaNWMFQwDQYDVR0KBAYwBAMCBkAwQwYDVR0BBDwwO
          oAQAaVOkaVLLKoFmLN37pC8uqEUMBIxEDAOBgNVBAMTB1Rlc3QgQ0GCEC4MndUX
          jPG1TZxVKg+HutAwCQYFKw4DAh0FAAOBgQABU91ka7IlkXCfv4Zh2Ohwgg2yObt
          Y3+6C/BTFGrOEBJDy+DoxJ/NuBF18w3rrrR18xE6jNKYLCQb8zUGk4QOG5Y+HT/
          QTTFvWkiOLXcpTuhnOhXatr42FoYpDkjx2QWK+J5Q2l/Rgjgc/0ZV8U/kD8UuRk
          Xp4AZh7QsiX8AcO0w==
        </ds:X509Certificate>
      </ds:X509Data>
    </ds:KeyInfo>
    <Status StatusValue="http://www.w3.org/2002/03/xkms#Valid" />
  </ReissueKeyBinding>
  <Authentication>
    <KeyBindingAuthentication>
      <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
        <SignedInfo>
          <CanonicalizationMethod
                Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
          <SignatureMethod
                Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1" />
          <Reference URI="#I518fc89b03369bccec3d1ee9d985c436">
            <Transforms>
              <Transform
                    Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
                <ec:InclusiveNamespaces PrefixList="ds xenc #default"
                      xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#" />
              </Transform>
            </Transforms>
            <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
            <DigestValue>qnhsUF9RMxxGydG/5KdJjWhtBFE=</DigestValue>
          </Reference>
        </SignedInfo>
        <SignatureValue>+gKw3b0qi9BaIqmN1gIyvj1UxRs=</SignatureValue>
      </Signature>
    </KeyBindingAuthentication>
  </Authentication>
  <ProofOfPossession>
    <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
      <SignedInfo>
        <CanonicalizationMethod
              Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
        <SignatureMethod
              Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
        <Reference URI="#I518fc89b03369bccec3d1ee9d985c436">
          <Transforms>
            <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
              <ec:InclusiveNamespaces PrefixList="ds xenc #default"
                    xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#" />
            </Transform>
          </Transforms>
          <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"
                />
          <DigestValue>qnhsUF9RMxxGydG/5KdJjWhtBFE=</DigestValue>
        </Reference>
      </SignedInfo>
      <SignatureValue>
sP/RWAA7fnv86ZgwOlfxTwN05akxyf65rCw7rwXNkJmx0fxUNFJ+qKDqmIh2KyvFyBut6FredSXj
t3iDIXUKMmjA2/VPGEX8yyd71DbRqf9dXb2FzkvkKrCbYumlavbrChpEwiMUqk2rd5tjkFAZjYRA
tuURoFfmoOYY/M+mNUU=
      </SignatureValue>
    </Signature>
  </ProofOfPossession>
</ReissueRequest>

[257] Le service accepte l'enregistrement et retourne la réponse suivante :

<?xml version="1.0" encoding="utf-8"?>
<ReissueResult xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
      xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
      Id="I4f0f13b32e4f43f0c1b390b5186fa997"
      Service="http://www.example.org/XKMS"
      ResultMajor="http://www.w3.org/2002/03/xkms#Success"
      RequestId="I3a682dfb94cc8e9b3b648026783a8094"
      xmlns="http://www.w3.org/2002/03/xkms#">
  <KeyBinding Id="I9a894fff4149d2351c24241886e3900e">
    <ds:KeyInfo>
      <ds:X509Data>
        <ds:X509Certificate>
          MIICEDCCAX2gAwIBAgIQimXeUAxYJbJMady9vV1bLjAJBgUrDgMCHQUAMBIxEDA
          OBgNVBAMTB1Rlc3QgQ0EwHhcNMDMwODE1MDcwMDAwWhcNMDUwODE1MDY1OTU5Wj
          ArMSkwJwYDVQQDEyBBbGljZSBBYXJkdmFyayBPPUFsaWNlIENvcnAgQz1VUzCBn
          zANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA0nIsmR+aVW2egl5MIfOKy4HuMKkk
          9AZ/IQuDLVPlhzOfgngjVQCjr8uvmnqtNu8HBupui8LgGthO6U9D0CNT5mbmhIA
          ErRADUMIAFsi7LzBarUvNWTqYNEJmcHsAUZdrdcDrkNnG7SzbuJx+GDNiHKVDQg
          gPBLc1XagW20RMvokCAwEAAaNWMFQwDQYDVR0KBAYwBAMCBkAwQwYDVR0BBDwwO
          oAQAaVOkaVLLKoFmLN37pC8uqEUMBIxEDAOBgNVBAMTB1Rlc3QgQ0GCEC4MndUX
          jPG1TZxVKg+HutAwCQYFKw4DAh0FAAOBgQABU91ka7IlkXCfv4Zh2Ohwgg2yObt
          Y3+6C/BTFGrOEBJDy+DoxJ/NuBF18w3rrrR18xE6jNKYLCQb8zUGk4QOG5Y+HT/
          QTTFvWkiOLXcpTuhnOhXatr42FoYpDkjx2QWK+J5Q2l/Rgjgc/0ZV8U/kD8UuRk
          Xp4AZh7QsiX8AcO0w==
        </ds:X509Certificate>
        <ds:X509Certificate>
          MIIB9zCCAWSgAwIBAgIQLgyd1ReM8bVNnFUqD4e60DAJBgUrDgMCHQUAMBIxEDA
          OBgNVBAMTB1Rlc3QgQ0EwHhcNMDMwODE1MDcwMDAwWhcNMTAwODE1MDcwMDAwWj
          ASMRAwDgYDVQQDEwdUZXN0IENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBg
          QCn23HHp+HtXpiyKVSDtdE3dO0r0oLB/H9sxUEkeXB8oMxwbhdcizWH92zrtm1V
          fVtxkfmwF14ZXoyDZHeZXuCOtAfz/mW6s2gmfD45TfFFVGksDGVRNK5XmKXA5sE
          C51RCvaxzGBdGDlCuVPqX7Cq3IcZpRU1IXbi5YzGwV7j6LwIDAQABo1YwVDANBg
          NVHQoEBjAEAwIHgDBDBgNVHQEEPDA6gBABpU6RpUssqgWYs3fukLy6oRQwEjEQM
          A4GA1UEAxMHVGVzdCBDQYIQLgyd1ReM8bVNnFUqD4e60DAJBgUrDgMCHQUAA4GB
          ABDYD4Fwx2dscu+BgYcZ+GoQQtCJkwJEXytb4zlNl7HLFKbXSw4m0blQquIsfsi
          QgFYAQBXSbu7aeUqqmSGHvILu3BGwVOKjxbHfcM4/MefuTtpOpCN40wy3YwwngD
          tHTaIqm8NwS966PE+W9f8kD70q5FNwf+GF/lX9qGc/x435
        </ds:X509Certificate>
      </ds:X509Data>
    </ds:KeyInfo>
    <KeyUsage>http://www.w3.org/2002/03/xkms#Signature</KeyUsage>
    <KeyUsage>http://www.w3.org/2002/03/xkms#Encryption</KeyUsage>
    <KeyUsage>http://www.w3.org/2002/03/xkms#Exchange</KeyUsage>
    <UseKeyWith Application="urn:ietf:rfc:2633"
          Identifier="alice@example.com" />
    <Status StatusValue="http://www.w3.org/2002/03/xkms#Valid">
      <ValidReason>http://www.w3.org/2002/03/xkms#Signature</ValidReason>
      <ValidReason>http://www.w3.org/2002/03/xkms#IssuerTrust</ValidReason>
      <ValidReason>http://www.w3.org/2002/03/xkms#RevocationStatus</ValidReason>
      <ValidReason>http://www.w3.org/2002/03/xkms#ValidityInterval</ValidReason>
    </Status>
  </KeyBinding>
</ReissueResult>

6.3 La révocation

[258] Un service d'enregistrement PEUT autoriser les clients à révoquer des liaisons de clé émises précédemment. Une requête de révocation doit seulement contenir les informations suffisantes pour identifier la liaison de clé à révoquer et l'autorité pour la requête de révocation.

[259] Si une liaision de clé XKMS est liée à un objet de données dans une architecture PKI sous-jacente, alors la révocation de la liaison de clé DEVRAIT se traduire par la révocation de l'objet de données sous-jacent. Par exemple, si la liaison de clé XKMS est liée à un certificat X.509, la révocation de la liaison de clé DEVRAIT révoquer ce certificat.

6.3.1 Exemple : La révocation

[260] Pour une raison quelconque, Alice demande au service d'enregistrement de révoquer la liaison de clé pour sa clé publique. Alice s'authentifie en se servant de la valeur de la phrase d'accès établie lors de l'enregistrement.

[261] Le message de la requête est le suivant :

<?xml version="1.0" encoding="utf-8"?>
<RevokeRequest xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
      xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
      Id="I2aa2c2f37195c9c4364c55f15df68091"
      Service="http://www.example.org/XKMS"
      xmlns="http://www.w3.org/2002/03/xkms#">
  <RevokeKeyBinding Id="Ie91dfbf1c948d5cf142099676968caf1">
    <ds:KeyInfo>
      <ds:X509Data>
        <ds:X509Certificate>
          MIICEDCCAX2gAwIBAgIQimXeUAxYJbJMady9vV1bLjAJBgUrDgMCHQUAMBIxEDA
          OBgNVBAMTB1Rlc3QgQ0EwHhcNMDMwODE1MDcwMDAwWhcNMDUwODE1MDY1OTU5Wj
          ArMSkwJwYDVQQDEyBBbGljZSBBYXJkdmFyayBPPUFsaWNlIENvcnAgQz1VUzCBn
          zANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA0nIsmR+aVW2egl5MIfOKy4HuMKkk
          9AZ/IQuDLVPlhzOfgngjVQCjr8uvmnqtNu8HBupui8LgGthO6U9D0CNT5mbmhIA
          ErRADUMIAFsi7LzBarUvNWTqYNEJmcHsAUZdrdcDrkNnG7SzbuJx+GDNiHKVDQg
          gPBLc1XagW20RMvokCAwEAAaNWMFQwDQYDVR0KBAYwBAMCBkAwQwYDVR0BBDwwO
          oAQAaVOkaVLLKoFmLN37pC8uqEUMBIxEDAOBgNVBAMTB1Rlc3QgQ0GCEC4MndUX
          jPG1TZxVKg+HutAwCQYFKw4DAh0FAAOBgQABU91ka7IlkXCfv4Zh2Ohwgg2yObt
          Y3+6C/BTFGrOEBJDy+DoxJ/NuBF18w3rrrR18xE6jNKYLCQb8zUGk4QOG5Y+HT/
          QTTFvWkiOLXcpTuhnOhXatr42FoYpDkjx2QWK+J5Q2l/Rgjgc/0ZV8U/kD8UuRk
          Xp4AZh7QsiX8AcO0w==
        </ds:X509Certificate>
      </ds:X509Data>
    </ds:KeyInfo>
    <Status StatusValue="http://www.w3.org/2002/03/xkms#Indeterminate" />
  </RevokeKeyBinding>
  <RevocationCode>PHx8li2SUhrJv2e1DyeWbGbD6rs=</RevocationCode>
</RevokeRequest>

[262] Le service répond que la liaison de clé a été révoquée :

<?xml version="1.0" encoding="utf-8"?>
<RevokeResult xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
      xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
      Id="I252433a097631dca9a2775493f39c7d7"
      Service="http://www.example.org/XKMS"
      ResultMajor="http://www.w3.org/2002/03/xkms#Success"
      RequestId="I2aa2c2f37195c9c4364c55f15df68091"
      xmlns="http://www.w3.org/2002/03/xkms#" />

6.4 La récupération d'une clé

[263] Un service d'enregistrement PEUT gérer la récupération des clés. Pour qu'une récupération de clé soit possible, la clé privée à récupérer DOIT avoir été précédemment sequestrée auprès du service de récupération, par exemple, à la faveur de l'enregistrement X-KRSS d'une clé générée par un serveur. Une requête de récupération de clé est similaire à l'enregistrement initial d'une clé, à la différence que, si le service d'enregistrement n'a pas l'enregistrement de la liaison de clé à récupérer, le code de résultat NotFound POURRA être retourné.

[264] Le service de récupération de clé mettra vraisemblablement un certain temps à répondre à la requête de récupération. Les clients gérant la récupération de clé DEVRAIENT aussi gérer le traitement asynchrone.

[265] La politique de sécurité de l'émetteur PEUT considérer le processus de récupération de clé en lui-même comme représentant une compromission effective ou potentielle de la clé récupérée et donc imposer la révocation de toutes les liaisons de clé associées, en particulier si la récupération de la clé a été demandée par un tiers tel que le superviseur du titulaire de la clé.

6.4.1 Exemple : La récupération d'une clé

[266] Bob a oublié la clé privée obtenue dans l'exemple d'enregistrement précédent. Il contacte d'abord l'administrateur du service de récupération de clé en utilisant une procédure d'authentification hors-bande déterminée par une politique du site. L'administrateur de la récupération de clé envoie à Bob (en recourant à une méthode hors-bande) le code d'autorisation de récupération de clé A8YUT VUHHU C9H29 8Y43U H9J3I 23. Dans le cas présent, le code est lu au téléphone et donc il serait gênant de devoir indiquer les espaces entre les blocs de code ou la mise en majuscules.

[267] Les paramètres de la requête pour récupérer la clé sont les suivants :

<?xml version="1.0" encoding="utf-8"?>
<RecoverRequest xmlns:ds="http://www.w3.org/2000/09/xmldsig#" 
      xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" 
      Id="I66f40510c322d281602ce76b9eb04d7d" 
      Service="http://www.example.org/XKMS" 
      xmlns="http://www.w3.org/2002/03/xkms#">
  <RespondWith>http://www.w3.org/2002/03/xkms#PrivateKey</RespondWith>
  <RecoverKeyBinding Id="I29cb8ac8a2ad878f7be44edfe53ea77a">
    <ds:KeyInfo>
      <ds:KeyValue>
        <ds:RSAKeyValue>
          <ds:Modulus>
            3FFtWUsvEajQt2SeSF+RvAxWdPPh5GSlQnp8SDvvqvCwE6PXcRWrIGmV7twNf2T
            UXCxYuztUUClMIy14B0Q+k1ej2nekmYL7+Ic3DDGVFVaYPoxaRY0Y2lV8tOreyn
            WegpFbITXc8V6Y02QfR5O7Pn1/10ElslaF/TF8MQGqYE8=
          </ds:Modulus>
          <ds:Exponent>AQAB</ds:Exponent>
        </ds:RSAKeyValue>
      </ds:KeyValue>
    </ds:KeyInfo>
    <Status StatusValue="http://www.w3.org/2002/03/xkms#Indeterminate" />
  </RecoverKeyBinding>
  <Authentication>
    <KeyBindingAuthentication>
      <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
        <SignedInfo>
          <CanonicalizationMethod 
                Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
          <SignatureMethod 
                Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1" />
          <Reference URI="#I29cb8ac8a2ad878f7be44edfe53ea77a">
            <Transforms>
              <Transform 
                    Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
                <ec:InclusiveNamespaces PrefixList="ds xenc #default" 
                      xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#" />
              </Transform>
            </Transforms>
            <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
            <DigestValue>GfV3xa/OL6EQAoo5sFL/nHQJCeo=</DigestValue>
          </Reference>
        </SignedInfo>
        <SignatureValue>TtHM/i5L6ynzQHh2Xym8wnbjQ+w=</SignatureValue>
      </Signature>
    </KeyBindingAuthentication>
  </Authentication>
</RecoverRequest>

[268] La politique de ce service d'enregistrement particulier est de révoquer une clé privée dès lors qu'une récupération de clé est intervenue. Un service d'enregistrement peut adopter une politique de révocation en cas de récupération pour nombre de raisons, dont le souci que, à la faveur du processus de récupération, la clé puisse être compromise d'une manière ou d'une autre. Le service retourne la liaison de clé révoquée et les paramètres de la clé privée :

<?xml version="1.0" encoding="utf-8"?>
<RecoverResult xmlns:ds="http://www.w3.org/2000/09/xmldsig#" 
      xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" 
      Id="Iacd24dbd4b3c79660f4d26aca7aaaea2" 
      Service="http://www.example.org/XKMS"
      ResultMajor="http://www.w3.org/2002/03/xkms#Success"
      RequestId="I66f40510c322d281602ce76b9eb04d7d" 
      xmlns="http://www.w3.org/2002/03/xkms#">
  <KeyBinding Id="I29cb8ac8a2ad878f7be44edfe53ea77a">
    <ds:KeyInfo>
      <ds:KeyValue>
        <ds:RSAKeyValue>
          <ds:Modulus>
            3FFtWUsvEajQt2SeSF+RvAxWdPPh5GSlQnp8SDvvqvCwE6PXcRWrIGmV7twNf2T
            UXCxYuztUUClMIy14B0Q+k1ej2nekmYL7+Ic3DDGVFVaYPoxaRY0Y2lV8tOreyn
            WegpFbITXc8V6Y02QfR5O7Pn1/10ElslaF/TF8MQGqYE8=
          </ds:Modulus>
          <ds:Exponent>AQAB</ds:Exponent>
        </ds:RSAKeyValue>
      </ds:KeyValue>
    </ds:KeyInfo>
    <Status StatusValue="http://www.w3.org/2002/03/xkms#Invalid">
      <InvalidReason>http://www.w3.org/2002/03/xkms#Signature</InvalidReason>
      <InvalidReason>http://www.w3.org/2002/03/xkms#IssuerTrust</InvalidReason>
      <InvalidReason>http://www.w3.org/2002/03/xkms#RevocationStatus</InvalidReason>
      <InvalidReason>http://www.w3.org/2002/03/xkms#ValidityInterval</InvalidReason>
    </Status>
  </KeyBinding>
  <PrivateKey>
    <xenc:EncryptedData Type="http://www.w3.org/2001/04/xmlenc#Content"
     	                MimeType="text/xml">
      <xenc:EncryptionMethod 
            Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc" />
      <xenc:CipherData>
        <xenc:CipherValue>
          DDSIEvW/tshnuCwCC+jX6y/srzMpt3qCIQ5zXmk/cHN4o/BItHsi9BJF85a3hnN
          C4/aFfPVJ3WgP6vIZNAUaDY2FbAJckWRgWhGku36p7DZTB14vmt5P5C1bXGU5ps
          CDw5Sbm+s/cFkReyfGk6khJTpbgQABPGIZBy2hiZMdSnu0eRgaVUXk9X5oPAhYU
          BjiQRq56ckHgEhkuwa+RiA+ybDNn/Ttjt5Uu5BjCONkOdeE8eJMlu0ykj99Vn7G
          NKUvt86bJsuwu5ZD1vSmVEwUAvHKV09UfVWfcKEINoj30t8Imj9naJ37oVRNPXl
          EKqZY9cxqzHiYEEhu0wxiTMiLbkEyh1DIcLNW78JXpWHRuRTrU5hgNzGEO1pKo7
          1uRT1/lArojeJGCJKAwQJvCDXU9zZSXVLzU/AqUshR3L0AoY8pJ/p+LbmlTh43E
          4TeT0iXNWkLz0mdgWdmwhhZtj8NcP/4auqfpv7+4NAP5OFVOEYJgE1I60F49K9m
          7FbNygiAczfN1YZwjc5lLoIXo75cXduxOZgTWN8ZnFKwrhG1IMhstrauywur6lr
          lyxZ1JXEj2aohE4Msa7HKx1LSzDi3dejtK3ZFRqnJcJ1bQ/liOA1IgonN0wvUaH
          DM9ibo2xUie2DfoSw3kWCDf0bcZEcV33UFNR3w8kOHgpSAwdHJi0pRyHdgfyd8w
          3NzvfCNy9AlrU2MbTdFF7hBxmgFK3fvaX7aEcgdqY17dqkiK75TAwzkVh5WkVjS
          WZGSiN49C8e4bY9zzq33lZwZabd5ts2Dvy3RuKc0hQj2rnCZcowXC+XJ7tVtMG+
          lNu1ykyeYmvR8VI5Ame5h1DFPjoFLAjkt/tUu2uZlqLYoSKvJU4FWNMAXRUge+f
          L3f35lObqwxPJN/LVJgvgGqoMt5hO+/uwgsb3nbR7rTHavPX2kS5LDAtW5xNcfF
          dJz8l+dDjlYBJMN8cgEKnNtHTcnVJ5NiFPsGIFv/3IGUZsiw7M4dff3GN6quv9A
          601e5rqG1ObMT6/7y7T0Z5IBXwiqs4HcdV+kyRfJwX1QpGat3nQsOZ59PTsIt5n
          oKSH0sB5AZmLJa1zgeOILJ574r+F6kD44R32NoLjqu0QL5IqfQ/0lQJuYhn0uEr
          FeZIn/lvjqzgf+rGPtgI5wtZ9Fv3qKrTPJOGM8atkzPkUtyJ8kR+WRhdAdFH9HM
          0PgyrSGjcCGgFIppsN1KJawrvcXokGRzF81cD/3pVaZC/ZIBtvp4DXM2JSLGoa1
          GpLuaIFUP5T/uxFf6MpW2v07bB/jqEZrcsB/ofmvv6RXD/gXrrw99iIiv0k2lyR
          sHDN5/syXglGGeskPvCUOZZ5oXrZruxER/IXKRnlsD+0wJ3JZCSuPy9wYmQk77F
          pynJ5//7w8UA2qWvkZ0B4rKXOgZYp2pCWaZIDknHJoY+VL7J3sQyAp7qlkQxSBj
          bhTEjSYXpHWA+Vj/TiH1ue7/ULlCKfDNvDaWFuEqGT/9H+xUJ5POfTDBhUh+Row
          rwCcfYe71B+pB/tylQEERKNpqqgu3TbNJZk5G8U9p41+PwJ0kw9EZnv+z8UEyFl
          qAZZxj64rTelurPUsiehBFwVwh2fATuMrW9fhGew11npVlF5k+WxE1Cz+          
        </xenc:CipherValue>
      </xenc:CipherData>
    </xenc:EncryptedData>
  </PrivateKey>
</RecoverResult>

[269] Les paramètres de la clé privée déchiffrée sont les suivants :

<?xml version="1.0" encoding="utf-8"?>
<RSAKeyPair xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xmlns:xsd="http://www.w3.org/2001/XMLSchema"
      xmlns="http://www.w3.org/2002/03/xkms#">
  <Modulus>
    3FFtWUsvEajQt2SeSF+RvAxWdPPh5GSlQnp8SDvvqvCwE6PXcRWrIGmV7twNf2TUXCxYuztUU
    ClMIy14B0Q+k1ej2nekmYL7+Ic3DDGVFVaYPoxaRY0Y2lV8tOreynWegpFbITXc8V6Y02QfR5
    O7Pn1/10ElslaF/TF8MQGqYE8=
  </Modulus>
  <Exponent>AQAB</Exponent>
  <P>
    8dnXAObQvcKL0Rr/A+5Ufp1yJgLpH+uohFcJV2kUDCzv5VWKcN+LTq2mciKlnFbAQXKa5dNPO
    x4qi3An/4NSMQ==
  </P>
  <Q>
    6TUX4d9+enb/aLHtck39x7cPQWlKkNFFJAqXaaRScDhjf4d8b009uW/pu3O2BdIJPY8M/QnUR
    lqXGLqGGl26fw==
  </Q>
  <DP>
    LVEcMFcPlf72I+BjGGF4A6GM2gKBnDGUCfglD/Pohb+F0/sLTcsVV1DCd3B2h6zZqWnIDHhjy
    DgG0MnbNM1ugQ==
  </DP>
  <DQ>
    0DWm7PMtaQl1X3P8G2Gmgvjdlfj7qfAtWtBZ/ufG8oplyyab4oOD6FwSwlm82dV8iol9fy2Xa
    HjZDir6L/Ae4Q==
  </DQ>
  <InverseQ>
    sD2Vl/CCVTDbhhLwdfc4IQDBOh8xpBUV7PPM5LFGjiLetlfwaYi7Bp2ol8WF1MX88iCV2E3xO
    PCNfbMhvEB5dA==
  </InverseQ>
  <D>
    REUnMUhO6ZX6NxoCwkJ7El5wXAVGtlNJsnPqFygbeEjlBvD6TZx9TqnpP/8IX7WK6JUFWd9kn
    QJvCWeJjhbjnImSS/3xc+v+m4glnnebZbaghvfunbI++fQaNAFRVT1hLvEGknqC/7zsrUM04o
    gU7hP+XgdFTJ1QYGfGHl5c0IE=
  </D>
</RSAKeyPair>

6.5 L'authentification de la requête

[270] La spécification X-KRSS définit un mécanisme pour authentifier les requêtes, indépendant de tout mécanisme d'authentification fournit par la liaison de sécurité du message. Par nature, le protocole X-KRSS est tenu de gérer les requêtes de tiers qui ont encore à enregistrer leurs autorisations ou dont les autorisations insuffisantes doivent être révoquées.

[271] Un service X-KRSS DEVRAIT s'assurer que toutes les requêtes soient authentiques et autorisées.

[272] Authenticité : Le message de requête provient du tiers spécifié.

[273] Intégrité : Le message de requête n'a pas été modifié.

[274] Possession : Si une clé publique est spécifiée dans une requête d'enregistrement, la preuve que la requête est autorisée par un tiers ayant accès à la clé privée correspondante.

[275] Les services d'enregistrement fixent leur propre politique d'authentification. Cette spécification définit un mécanisme d'authentification qui emploie un secret partagé établi hors-bande entre le client et le service d'enregistrement.

[276] Les services DEVRAIENT exiger des clients qu'ils prouvent la possession du composant clé privée d'une clé asymétrique pour une requête d'enregistrement d'une liaison de clé valide associée à cette clé.

[277] Les services DEVRAIENT accepter une preuve de la possession du composant clé privée d'une clé asymétrique pour effectuer la révocation de n'importe quelle liaison de clé associée à cette clé.

[277a] Les clients et les répondants PEUVENT utiliser un élément dsig:KeyName pour une validation HMAC. Autrement, ils peuvent utiliser d'autres informations d'identité dérivées de la liaison sécurisée, telle que l'adresse IP de l'émetteur.

7 Le jeu de messages des services d'enregistrement de clés

[278] Les opérations du protocole reviennent à l'appel d'une procédure distante qui consiste en un seul message de requête envoyé par le client au service d'enregistrement suivi par un seul message de réponse envoyé par le serveur au client.

[279] Un message de réponse PEUT contenir plusieurs liaisons de clé si l'opération a abouti à la création ou le changement dans le statut de plusieurs liaisons de clé. Par exemple, une opération d'enregistrement pourrait provoquer l'établissement de deux liaisons de clé indépendantes, celles-ci ayant des identificateurs de politique et des intervalles de validité différents, dans deux architectures PKI sous-jacentes indépendantes. La révocation d'une telle liaison de clé pourrait causer celles des autres liaisons de clé associées.

7.1 Les éléments communs

7.1.1 L'élément <PrototypeKeyBinding>

[280] L'élément <PrototypeKeyBinding> est dérivé du type KeyBindingAbstractType. Il sert à spécifier les valeurs des éléments dont un client demande la présence dans la liaison de clé résultant d'une requête d'enregistrement.

[281] Tous les champs d'un élément <PrototypeKeyBinding> sont consultatifs et le service PEUT les ignorer. Par exemple, un client pourrait demander un enregistrement sous l'identificateur de politique http://example.com/politique/haute-securite correspondant à une politique de délivrance avec des garanties élevées, mais la liaison de clé retournée pourrait spécifier à la place l'identificateur de politique http://example.com/politique/securite-minimale correspondant à une politique de délivrance avec des garanties faibles.

[282] L'élément <PrototypeKeyBinding> étend le type KeyBindingAbstractType avec les éléments supplémentaires suivants :

<ValidityInterval> (optionnel)
L'intervalle de temps suggéré pour lequel les relations de la liaison de clé sont valides.
<RevocationCodeIdentifier> (optionnel)
Spécifie une valeur à utiliser pour valider une valeur RevocationCode dans une requête de révocation ultérieure.

[283] Le schéma suivant définit l'élément <PrototypeKeyBinding> et le type PrototypeKeyBindingType :

   <!-- PrototypeKeyBinding -->
   <element name="PrototypeKeyBinding" type="xkms:PrototypeKeyBindingType"/>
   <complexType name="PrototypeKeyBindingType">
      <complexContent>
         <extension base="xkms:KeyBindingAbstractType">
            <sequence>
               <element ref="xkms:ValidityInterval" minOccurs="0"/>
               <element ref="xkms:RevocationCodeIdentifier" minOccurs="0"/>
            </sequence>
         </extension>
      </complexContent>
   </complexType>
   <!-- /PrototypeKeyBinding -->

7.1.2 L'élément <RevocationCodeIdentifier>

[284] L'élément <RevocationCodeIdentifier> contient la valeur de sortie d'un algorithme d'authentification de message (MAC) codée comme une chaîne en base64.

[285] L'algorithme MAC utilisé par défaut est HMAC-SHA1. D'autres algorithmes MAC PEUVENT être utilisés, à condition que le client soit averti que le service accepte de tels algorithmes, par le biais d'un mécanisme hors-bande telle qu'une description de service Web ou un mécanisme de distribution de politiques.

[286] Lors de l'enregistrement initial, la valeur de l'élément <RevocationCodeIdentifier> est obtenue en lançant d'abord le calcul MAC sur la valeur de la phrase d'accès puis en réalisant un second calcul MAC sur le résultat.

[287] Pour prouver la connaissance de la phrase d'accès dans une requête de révocation ultérieure, on effectue le calcul MAC sur la valeur de la phrase d'accès et on obtient la valeur de l'élément <RevocationCode>.

[288] L'emploi du double calcul MAC est un avantage, car il garantit que le service XKMS n'exerce aucune contrainte arbitraire sur la longueur de la phrase d'accès ou sur le jeu de caractères avec lequel elle est codée.

[289] Les détails du calcul de la valeur de sortie MAC sont fournis plus loin dans la section Les paramètres spécifiques des algorithmes cryptographiques.

[290] Le schéma suivant définit l'élément <RevocationCodeIdentifier> et le type RevocationCodeIdentifierType :

   <!-- RevocationCodeIdentifier -->
   <element name="RevocationCodeIdentifier"
         type="xkms:RevocationCodeIdentifierType"/>
   <simpleType name="RevocationCodeIdentifierType">
      <restriction base="base64Binary"/>
   </simpleType>
   <!-- /RevocationCodeIdentifier -->

7.1.3 L'élément <Authentication>

[291] L'élément <Authentication> sert à authentifier l'élément de liaison de clé au sein d'une requête X-KRSS. Cet élément peut être l'un des suivants, selon le type de la requête : <PrototypeKeyBinding>, <ReissueKeyBinding>, <RevokeKeyBinding> ou <RecoverKeyBinding>.

<KeyBindingAuthentication> (optionnel)
Authentification de la liaison de clé par une signature en recourant à une clé établie précédemment.
<NotBoundAuthentication> (optionnel)
Données en clair utilisées pour authentifier la requête X-KRSS laquelle n'est pas liée à la liaison de clé.
 
Les répondants XKMS ne sont pas tenus de reconnaître ces deux éléments optionnels dans un message de requête.

[292] Le schéma suivant définit l'élément <Authentication> :

   <!-- Authentication -->
   <element name="Authentication" type="xkms:AuthenticationType"/>
   <complexType name="AuthenticationType">
      <sequence>
         <element ref="xkms:KeyBindingAuthentication" minOccurs="0"/>
         <element ref="xkms:NotBoundAuthentication" minOccurs="0"/>
      </sequence>
   </complexType>
   <!-- /Authentication -->

7.1.4 L'élément <KeyBindingAuthentication>

[293] L'élément <KeyBindingAuthentication> contient un élément XML Signature [XML-SIG] qui sert à authentifier la requête en recourant à une clé établie précédemment.

<ds:Signature> (obligatoire)
Un élément XML Signature [XML-SIG] contenant une signature qui recouvre les éléments <KeyBinding> ou <PrototypeKeyBinding>.

[294] La signature XML [XML-SIG] est générée en signature détachée et utilise l'attribut Id, spécifié dans le type KeyBindingAbstractType, qui en définit la portée.

[295] Le schéma suivant définit l'élément <KeyBindingAuthentication> :

   <!-- KeyBindingAuthentication -->
   <element name="KeyBindingAuthentication"
         type="xkms:KeyBindingAuthenticationType"/>
   <complexType name="KeyBindingAuthenticationType">
      <sequence>
         <element ref="ds:Signature"/>
      </sequence>
   </complexType>
   <!-- /KeyBindingAuthentication -->

7.1.5 L'élément <NotBoundAuthentication>

[296] L'élément <NotBoundAuthentication> contient des données d'identification en clair (par exemple, un secret partagé à usage limité) qui servent à authentifier la requête.

Protocol (obligatoire)
Une adresse URI indiquant le protocole d'authentification employé.
Value (obligatoire)
Les données d'authentification en clair dans le format base64.

[297] La spécification des adresses URI des protocoles n'est pas abordée par ce document.

[298] Cet élément est fourni pour tenir compte des applications dont le schéma d'authentification prescrit que le serveur doive avoir un accès en clair aux données d'authentification. Les données d'authentification ne sont pas liées de manière sûre à la requête et, donc, on NE DOIT PAS utiliser cet élément sauf pour les occasions où le message ou le protocole de transport fournissent une protection adéquate à la fois de la confidentialité et de l'intégrité..

[299] Le schéma suivant définit l'élément <NotBoundAuthentication> :

   <!-- NotBoundAuthentication -->
   <element name="NotBoundAuthentication"
         type="xkms:NotBoundAuthenticationType"/>
   <complexType name="NotBoundAuthenticationType">
      <attribute name="Protocol" type="anyURI" use="required"/>
      <attribute name="Value" type="base64Binary" use="required"/>
   </complexType>
   <!-- /NotBoundAuthentication -->

7.1.6 L'élément <ProofOfPossession>

[300] L'élément <ProofOfPossession> contient un élément XML Signature [XML-SIG]. La portée de la signature est celle de l'élément <PrototypeKeyBinding> utilisant la clé publique à enregistrer. Le composant clé privée de la clé asymétrique contenue dans l'élément <PrototypeKeyBinding> est utilisé pour générer la signature.

<ds:Signature> (obligatoire)
Un élément XML Signature [XML-SIG] contenant une signature détachée couvrant l'élément <PrototypeKeyBinding>. La clé de signature est celle identifiée par l'élément ds:KeyInfo contenu dans l'élément <PrototypeKeyBinding>.

[301] La signature XML [XML-SIG] est générée en signature détachée et utilise l'attribut Id, spécifié dans le type KeyBindingAbstractType, qui en définit la portée.

[302] Le schéma suivant définit l'élément <ProofOfPossession> :

   <!-- ProofOfPossession -->
   <element name="ProofOfPossession" type="xkms:ProofOfPossessionType"/>
   <complexType name="ProofOfPossessionType">
      <sequence>
         <element ref="ds:Signature"/>
      </sequence>
   </complexType>
   <!-- /ProofOfPossession -->

7.1.7 L'élément <PrivateKey>

[303] L'élément <PrivateKey> contient les paramètres cryptés de la clé privée retournée par le service en réponse à une requête d'enregistrement, quand les clés sont générées par le serveur, ou en réponse à une requête de récupération réussie.

<xenc:EncryptedData> (obligatoire)
Les données cryptées de la clé privée. Cet élément est défini par la spécification XML Encryption [XML-Enc]. L'attribut Type DEVRAIT être présent et, le cas échéant, DOIT contenir la valeur de type "http://www.w3.org/2001/04/xmlenc#Content". L'attribut MimeType DEVRAIT avoir la valeur "text/xml".

[304] Le schéma suivant définit l'élément <PrivateKey> :

   <!-- PrivateKey -->
   <element name="PrivateKey" type="xkms:PrivateKeyType"/>
   <complexType name="PrivateKeyType">
      <sequence>
         <element ref="xenc:EncryptedData"/>
      </sequence>
   </complexType>
   <!-- /PrivateKey -->

7.1.8 L'élément <RevocationCode>

[305] L'élément <RevocationCode> contient la valeur de sortie d'un algorithme MAC codée comme une chaîne base64.

[306] L'algorithme MAC utilisé par défaut est HMAC-SHA1. D'autres algorithmes MAC PEUVENT être utilisés, à condition que le client soit averti que le service accepte de tels algorithmes, par le biais d'un mécanisme hors-bande telle qu'une description de service Web ou un mécanisme de distribution de politiques.

[307] Lors de l'enregistrement initial, la valeur de l'élément <RevocationCodeIdentifier> est obtenue en lançant d'abord le calcul MAC sur la valeur de la phrase d'accès puis en réalisant un second calcul MAC sur le résultat.

[308] Pour prouver la connaissance de la phrase d'accès dans une requête de révocation ultérieure, on effectue le calcul MAC sur la valeur de la phrase d'accès et on obtient la valeur de l'élément <RevocationCode>.

[309] Les détails du calcul de la valeur de sortie MAC sont fournis plus loin dans la section Les paramètres spécifiques des algorithmes cryptographiques.

[310] Le schéma suivant définit l'élément <RevocationCode> et le type RevocationCodeType :

   <!-- RevocationCode -->
   <element name="RevocationCode" type="xkms:RevocationCodeType"/>
   <simpleType name="RevocationCodeType">
      <restriction base="base64Binary"/>
   </simpleType>
   <!-- /RevocationCode -->

7.2 L'enregistrement

7.2.1 L'élément <RegisterRequest> de la requête d'enregistrement

[311] Le message de la requête d'enregistrement contient un élément <RegisterRequest> pouvant contenir les éléments suivants :

<PrototypeKeyBinding> (obligatoire)
Spécifie les éléments que le client demande à enregistrer.
<Authentication> (obligatoire)
Des information qui authentifient la requête..
<ProofOfPossesion> (optionnel)
La preuve de possession (POP) du composant clé privée de la liaison de clé. Un service qui exige la présence d'un élément ProofOfPossession DOIT retourner un résultat Sender.ProofOfPossessionRequired si l'élément ProofOfPossession n'apparaît pas dans la requête.

[312] Le schéma suivant définit l'élément <RegisterRequest> :

   <!-- RegisterRequest -->
   <element name="RegisterRequest" type="xkms:RegisterRequestType"/>
   <complexType name="RegisterRequestType">
      <complexContent>
         <extension base="xkms:RequestAbstractType">
            <sequence>
               <element ref="xkms:PrototypeKeyBinding"/>
               <element ref="xkms:Authentication"/>
               <element ref="xkms:ProofOfPossession" minOccurs="0"/>
            </sequence>
         </extension>
      </complexContent>
   </complexType>
   <!-- /RegisterRequest -->

7.2.2 L'élément <RegisterResult> de la réponse d'enregistrement

[313] Le message de la réponse d'enregistrement contient un élément <RegisterResult> pouvant contenir les éléments suivants :

<KeyBinding> (un nombre quelconque)
Si présent, spécifie la liaison de clé qui a été enregistrée par le service.
<PrivateKey> (optionnel)
Les valeurs des paramètres d'une clé privée qui a été générée par le service d'enregistrement.

[314] Le schéma suivant définit l'élément <RegisterResult> :

   <!-- RegisterResult -->
   <element name="RegisterResult" type="xkms:RegisterResultType"/>
   <complexType name="RegisterResultType">
      <complexContent>
         <extension base="xkms:ResultType">
            <sequence>
               <element ref="xkms:KeyBinding" minOccurs="0"
                     maxOccurs="unbounded"/>
               <element ref="xkms:PrivateKey" minOccurs="0"/>
            </sequence>
         </extension>
      </complexContent>
   </complexType>
   <!-- /RegisterResult -->

7.3 La réémission

7.3.1 L'élément <ReissueRequest> de la requête de réémission

[315] Le message de la requête de réémission contient un élément <ReissueRequest> pouvant contenir les éléments suivants :

<ReissueKeyBinding> (obligatoire)
Identifie la liaison de clé à réémettre.
<Authentication> (obligatoire)
Des informations qui authentifient la requête.
<ProofOfPossesion> (optionnel)
La preuve de possession du composant clé privée de la liaison de clé. Un service qui exige la présence d'un élément ProofOfPossession DOIT retourner un résultat Sender.ProofOfPossessionRequired si l'élément ProofOfPossession n'apparaît pas dans la requête.

[316] Le schéma suivant définit les éléments <ReissueRequest> et <ReissueKeyBinding> :

   <!-- ReissueRequest -->
   <element name="ReissueRequest" type="xkms:ReissueRequestType"/>
   <complexType name="ReissueRequestType">
      <complexContent>
         <extension base="xkms:RequestAbstractType">
            <sequence>
               <element ref="xkms:ReissueKeyBinding"/>
               <element ref="xkms:Authentication"/>
               <element ref="xkms:ProofOfPossession" minOccurs="0"/>
            </sequence>
         </extension>
      </complexContent>
   </complexType>
   <element name="ReissueKeyBinding" type="xkms:KeyBindingType"/>
   <!-- /ReissueRequest -->

7.3.2 L'élément <ReissueResult> de la réponse de réémission

[317] Le message de la réponse de réémission contient un élément <ReissueResult> pouvant contenir l'élément suivant :

<KeyBinding> (un nombre quelconque)
Si présent, spécifie la (ou les) liaison(s) de clé qui a (ont) été réémise(s) par le service.

[318] Le schéma suivant définit l'élément <ReissueResult> :

   <!-- ReissueResult -->
   <element name="ReissueResult" type="xkms:ReissueResultType"/>
   <complexType name="ReissueResultType">
      <complexContent>
         <extension base="xkms:ResultType">
            <sequence>
               <element ref="xkms:KeyBinding" minOccurs="0"
                     maxOccurs="unbounded"/>
            </sequence>
         </extension>
      </complexContent>
   </complexType>
   <!-- /ReissueResult -->

7.4 La révocation

7.4.1 L'élément <RevokeRequest> de la requête de révocation

[319] Le message de la requête de révocation contient l'élément <RevokeRequest> pouvant contenir les éléments suivants :

<RevokeKeyBinding> (obligatoire)
Identifie la liaison de clé à révoquer.
<Authentication> (choix)
Des informations qui authentifient la requête.
<RevocationCode> (choix)
La valeur du code de révocation qui génère la valeur de l'identificateur du code de révocation spécifiée lors de l'enregistrement.

[320] Le schéma suivant définit les éléments <RevokeRequest> et <RevokeKeyBinding> :

   <!-- RevokeRequest -->
   <element name="RevokeRequest" type="xkms:RevokeRequestType"/>
   <complexType name="RevokeRequestType">
      <complexContent>
         <extension base="xkms:RequestAbstractType">
            <sequence>
               <element ref="xkms:RevokeKeyBinding"/>
               <choice>
                  <element ref="xkms:Authentication"/>
                  <element ref="xkms:RevocationCode"/>
               </choice>
            </sequence>
         </extension>
      </complexContent>
   </complexType>
   <element name="RevokeKeyBinding" type="xkms:KeyBindingType"/>
   <!-- /RevokeRequest -->

7.4.2 L'élément <RevokeResult> de la réponse de révocation

[321] Le message de la requête de révocation contient un élément <RevokeResult> pouvant contenir l'élément suivant :

<KeyBinding> (un nombre quelconque)
Si présent, spécifie la liaison de clé qui a été révoquée par le service.

[322] Le schéma suivant définit l'élément <RevokeResult> :

   <!-- RevokeResult -->
   <element name="RevokeResult" type="xkms:RevokeResultType"/>
   <complexType name="RevokeResultType">
      <complexContent>
         <extension base="xkms:ResultType">
            <sequence>
               <element ref="xkms:KeyBinding" minOccurs="0"
                     maxOccurs="unbounded"/>
            </sequence>
         </extension>
      </complexContent>
   </complexType>
   <!-- /RevokeResult -->

7.5 La récupération

7.5.1 L'élément <RecoverRequest> de la requête de récupération

[323] Le message de la requête de récupération contient un élément <RecoverRequest> pouvant contenir les éléments suivants :

<RecoverKeyBinding> (obligatoire)
Identifie la liaison de clé à récupérer.
<Authentication> (obligatoire)
Des information qui authentifient la requête.

[324] Le schéma suivant définit les éléments <RecoverRequest> et <RecoverKeyBinding> :

   <!-- RecoverRequest -->
   <element name="RecoverRequest" type="xkms:RecoverRequestType"/>
   <complexType name="RecoverRequestType">
      <complexContent>
         <extension base="xkms:RequestAbstractType">
            <sequence>
               <element ref="xkms:RecoverKeyBinding"/>
               <element ref="xkms:Authentication"/>
            </sequence>
         </extension>
      </complexContent>
   </complexType>
   <element name="RecoverKeyBinding" type="xkms:KeyBindingType"/>
   <!-- /RecoverRequest -->

7.5.2 L'élément <RecoverResult> de la réponse de récupération

[325] Le message de la réponse de récupération contient un élément <RecoverResult> pouvant contenir les éléments suivants :

<KeyBinding> (un nombre quelconque)
Peut apparaître pour signaler un changement du statut de la liaison de clé en conséquence de la récupération de la clé.
<PrivateKey> (optionnel)
Les valeurs des paramètres de la clé privée récupérée.

[326] Le schéma suivant définit l'élément <RecoverResult> :

   <!-- RecoverResult -->
   <element name="RecoverResult" type="xkms:RecoverResultType"/>
   <complexType name="RecoverResultType">
      <complexContent>
         <extension base="xkms:ResultType">
            <sequence>
               <element ref="xkms:KeyBinding" minOccurs="0"
                     maxOccurs="unbounded"/>
               <element ref="xkms:PrivateKey" minOccurs="0"/>
            </sequence>
         </extension>
      </complexContent>
   </complexType>
   <!-- /RecoverResult -->

8 Les paramètres spécifiques des algorithmes cryptographiques

8.1 L'utilisation de données secrètes partagées à usage limité

[327] Il est souvent nécessaire ou souhaitable d'utiliser un secret partagé d'authentification à usage limité (c'est-à-dire, un numéro d'identification personnel (PIN) ou une phrase d'accès à usage unique) afin d'authentifier les messages des requêtes d'enregistrement. En particulier, on ne peut pas utiliser de clé privée pour l'authentification tant que la clé publique correspondante n'a pas été enregistrée.

[328] En outre, il est souhaitable que les paramètres de la clé privée, générée ou récupérée par le service d'enregistrement, soit retournés cryptés. Il est commode d'utiliser des données symétriques dans ce but.

[329a] Les données de la clé symétrique PEUVENT être des données binaires (comme si elles provenaient d'un dispositif d'authentification) ou apparaître comme une valeur lisible par un humain (numérique, alphabétique ou les deux). Lorsqu'il s'agit de données binaires, aucune transformation n'est nécessaire et les données peuvent être utilisées directement comme entrée de la fonction d'authentification MAC.

[329b] Lorsque les données de la clé symétrique sont lisibles pour un humain, elles peuvent lui être délivrées sous la forme d'une chaîne textuelle qui est susceptible d'être lue via une ligne téléphonique. Elle peut être générée de façon aléatoire, représenter une valeur numérique sous-jacente ou peut être un mot de passe ou une phrase d'accès. Dans tous les cas, il est souvent commode de présenter la valeur à un utilisateur humain sous forme d'une chaîne de caractères dans un jeu de caractères que ce dernier comprend. Pour limiter les probabilités d'erreur humaine dans le traitement des données de la clé symétrique et pour fournir une représentation binaire canonique, la chaîne doit être conforme au profil SASLprep de l'algorithme stringprep [SASLPREP] pour les noms et mots de passe d'utilisateurs.

[329c] L'algorithme de canonisation d'une chaîne textuelle avant sa présentation à la fonction MAC est le suivant :

  1. Convertir la chaîne en entrée vers un codage Unicode.
    Lever les limitations des codes US-ASCII et ISO-LATIN-1 ! Laisser l'utilisateur taper une phrase d'accès dont il peut se souvenir facilement ou qui peut se taper facilement avec la configuration de son clavier.
  2. Vérifier que la chaîne en entrée soit conforme au profil SASLprep de l'algorithme stringprep [SASLPREP] pour les noms et mots de passe d'utilisateurs. Sinon refuser la chaîne.
    Cette opération consiste à filtrer et normaliser les caractères de la chaîne et à vérifier qu'elle ne contient aucun caractère interdit. Notamment, aucune fusion de plusieurs caractères espace ni changement de casse n'ont lieu. Les symboles de ponctuation ne sont pas supprimés non plus. Les caractères de tabulation, lesquels sont des caractères de contrôle, sont de ce fait interdits.
  3. Coder le résultat en UTF-8.
  4. Appliquer les fonctions d'authentification MAC.

[330] Les applications DOIVENT s'assurer que les données secrètes partagées à usage limité sont suffisamment entropiques pour empêcher les attaques par dictionnaire. Pour plus de précisions, cf. l'entrée concernée dans la section traitant des considérations de sécurité.

[331] L'élément de mise à la clé est dérivé de la chaîne partagée en utilisant une fonction d'authentification MAC.

[332] L'algorithme MAC utilisé par défaut est HMAC-SHA1. D'autres algorithmes MAC PEUVENT être utilisés, à condition que le client soit averti que le service accepte de tels algorithmes, par le biais d'un mécanisme hors-bande telle qu'une description de service Web ou un mécanisme de distribution de politiques.

[333] Selon l'usage de la clé symétrique, on recourt à des valeurs de mise à la clé MAC différentes qui sont dérivées de la manière suivante :

Valeur Application
0x1 Authentification
0x2 Codage de l'élément RevocationCodeIdentifier (première passe)
0x3 Codage de l'élément RevocationCodeIdentifier (deuxième passe)
0x4 Chiffrement des données de l'élément PrivateKey

[334] Si la sortie de la fonction MAC produit plus d'éléments de mise à la clé que nécessaire pour une opération cryptographique (c'est-à-dire, chiffrement, authentification MAC), alors on utilisera les bits les moins significatifs.

[335] Si, au contraire, la sortie de la fonction MAC produit moins d'éléments de mise à la clé que nécessaire, alors on obtiendra les éléments de mise à la clé complémentaires de la manière suivante :

[336] bloc0 = MAC (convertie, clé)

[337] blocn+1 = MAC (convertie, clé XOR blocn)

[338] sortie = bloc0 + bloc1 + ... + blocn

[339] Cela consiste à utiliser la première valeur de sortie MAC pour obtenir les bits les moins significatifs de l'élément de mise à la clé. Une deuxième valeur de sortie MAC est alors obtenue en appliquant à nouveau la fonction MAC à la chaîne convertie, cette fois la valeur de mise à la clé MAC étant obtenue par une opération OU exclusif entre la première sortie et la valeur de mise à la clé précédente. Ce processus peut se répéter autant de fois que nécessaire afin de produire une quantité suffisante d'éléments de mise à la clé.

8.2 Les paramètres de la clé privée

[340] L'élément <PrivateKey> peut contenir les paramètres de la clé privée de n'importe quel algorithme cryptographique à clé publique. Les paramètres pour l'algorithme RSA sont spécifiés plus loin.

[341] Cette spécification ne définit aucun paramètre de clé privée pour l'algorithme de signature DSA puisque celui-ci ne gère que des modes de signature et donc son intérêt pour l'application de clés générées par un serveur et la récupération de clé est limité.

8.2.1 L'élément <RSAKeyPair>

[342] L'élément <RSAKeyPair> spécifie les paramètres publics et privés d'un couple de clés RSA. Le contenu de l'élément RSAKeyPair est défini par la spécification [PKCS1]. L'élément <RSAKeyPair> contient les paramètres suivants :

<Modulus> (obligatoire)
Le module.
<Exponent> (obligatoire)
L'exposant public.
<P> (obligatoire)
Le premier facteur (un entier positif).
<Q> (obligatoire)
Le second facteur (un entier positif).
<DP> (obligatoire)
L'exposant CRT du premier facteur (un entier positif).
<DQ> (obligatoire)
L'exposant CRT du second facteur (un entier positif).
<InverseQ> (obligatoire)
Le premier coefficient CRT (un entier positif).
<D> (obligatoire)
L'exposant privé.

[343] Le schéma suivant définit l'élément <RSAKeyPair> :

   <!-- RSAKeyPair -->
   <element name="RSAKeyPair" type="xkms:RSAKeyPairType"/>
   <complexType name="RSAKeyPairType">
      <sequence>
         <element ref="xkms:Modulus"/>
         <element ref="xkms:Exponent"/>
         <element ref="xkms:P"/>
         <element ref="xkms:Q"/>
         <element ref="xkms:DP"/>
         <element ref="xkms:DQ"/>
         <element ref="xkms:InverseQ"/>
         <element ref="xkms:D"/>
      </sequence>
   </complexType>
   <element name="Modulus" type="ds:CryptoBinary"/>
   <element name="Exponent" type="ds:CryptoBinary"/>
   <element name="P" type="ds:CryptoBinary"/>
   <element name="Q" type="ds:CryptoBinary"/>
   <element name="DP" type="ds:CryptoBinary"/>
   <element name="DQ" type="ds:CryptoBinary"/>
   <element name="InverseQ" type="ds:CryptoBinary"/>
   <element name="D" type="ds:CryptoBinary"/>
   <!-- /RSAKeyPair -->

9 La conformité

[344] Cette section décrit les caractéristiques et les opérations qui sont obligatoires ou recommandées pour les applications XKMS afin d'assurer l'interopérabilité des services XKMS.

[345] Pour cela, les règles de conformité concernent plutôt les destinataires des messages que leurs émetteurs, bien que ces derniers NE DEVRAIENT PAS envoyer de messages sans savoir qu'ils seront acceptés par les destinataires.

[346] Le tableau suivant définit les conditions de conformité OBLIGATOIRES, RECOMMANDÉES ou OPTIONNELLES pour les applications XKMS :

[350] Certaines fonctionnalités sont marquées comme OBLIGATOIRES* ou RECOMMANDÉES*. Cela signifie que la condition tient si une autre fonctionnalité est gérée. Par exemple, un service de localisation XKMS n'est pas obligé de gérer la spécification XML Signature. Toutefois, si c'est le cas, alors le service DOIT également gérer la canonisation exclusive.

[351] Une fonctionnalité est indiquée comme RECOMMANDÉE+. Cela signifie que, même si le client peut utiliser cette fonctionnalité à sa guise, il est fortement recommandé que la requête du client l'utilise dans la mesure où un service va vraisemblablement l'exiger pour que la réponse réussisse.

[352] Lorsqu'un service gère une fonctionnalité marquée comme OPTIONNELLE, il lui est recommandé d'annoncer cette fonctionnalité au moyen d'un mécanisme de description de service Web. Par exemple, un service XKMS qui permet de recourir à un autre codage protocole de transport que HTTP DEVRAIT en faire état.

[352a] Lorsque la requête d'un client inclut un élément OPTIONNEL non reconnu par le serveur, celui-ci peut recourir aux codes ResultMajor="Receiver" et ResultMinor="OptionalElementNotSupported". Dans certains cas, en fonction du contexte, le serveur peut recourir aux codes Failure ou MessageNotSupported de l'attribut ResultMinor. Quel que soit le cas, le client devrait vérifier les fonctionnalités reconnues par le serveur, par exemple, en consultant un état WSDL [WSDL] ou un fichier de métadonnées. Le mécanisme de recherche des ressources n'est pas traité par cette spécification.

[353] Les développeurs devraient tenir compte du fait que ces conditions sont susceptibles de changer pour les versions futures de la spécification XKMS. Par exemple, elles rendront vraisemblablement obligatoire la version future courante de la spécification SOAP.

[354a]

Les opérations XKMS
Fonctionnalité Opérations Niveau d'obligation Commentaires
Gestion de l'opération Localisation RECOMMANDÉ Les services DEVRAIENT gérer la récupération de leurs propres autorisations au moyen de l'opération de localisation par l'adresse URI du protocole XKMS.
Toutes Une opération OBLIGATOIRE Un service XKMS conforme DOIT gérer au moins une opération XKMS, c'est-à-dire qu'il DOIT y avoir au moins une entrée possible qui produise un résultat Success.
Composée OPTIONNELLE Cf. la remarque sur la gestion d'une opération de statut.
Statut RECOMMANDÉ* Les services DEVRAIENT gérer les opérations de statut si le traitement asynchrone et les requêtes composées le sont aussi.
Opération de réponse Toutes OBLIGATOIRE Un service XKMS conforme DOIT accepter toute requête XKMS valide qui lui est envoyée et être capable d'y répondre avec un résultat XKMS correctement formaté. Si un service ne gère pas une opération, il DOIT répondre à toutes les requêtes d'une opération particulière par le résultat Sender.MessageNotSupported.

[354b]

Les mécanismes de réponse
Fonctionnalité Opérations Niveau d'obligation Commentaires
Réponse synchrone Toutes OBLIGATOIRE Un service XKMS conforme DOIT être capable de retourner une réponse immédiate à toute requête XKMS.
Réponse asynchrone Enregistrement, réémission, récupération RECOMMANDÉ+ Le traitement de certaines opérations X-KRSS peut nécessiter l'intervention manuelle d'un opérateur en certaines circonstances. C'est pourquoi il est recommandé aux clients qu'ils gèrent le traitement asynchrone de ces opérations sauf si l'on sait que toutes les requêtes seront traitées immédiatement.
Composée RECOMMANDÉ Les services qui gèrent les opérations composées DEVRAIENT gérer les requêtes composées.
Localisation, validation, révocation OPTIONNEL Les services PEUVENT gérer les réponses asynchrones si elles sont gérées pour ces opérations.
En instance, statut INTERDIT Un client PEUT offrir un traitement asynchrone des opérations en instance et de statut ; toutefois, un service NE DOIT PAS retourner de réponse en instance.
Requête à deux phases Toutes RECOMMANDÉ+ Les clients DEVRAIENT gérer le protocole de requête à deux phases. Le surcroît de complexité pour sa mise en œuvre est minime et permet au service de fournir une réponse même en cas d'attaque en déni de service.

[354c]

L'encapsulation des protocoles
Fonctionnalité Opérations Niveau d'obligation Commentaires
Transport HTTP Toutes OBLIGATOIRE Les services DOIVENT gérer le protocole de transport HTTP.
Transport SOAP 1.2 Toutes OBLIGATOIRE Les services DOIVENT gérer l'encapsulation SOAP 1.2.
Transport SOAP 1.1 Toutes RECOMMANDÉ Les services PEUVENT gérer l'encapsulation SOAP 1.1.

[354d]

Les liaisons de sécurité
Fonctionnalité Opérations Niveau d'obligation Commentaires
Aucune liaison de sécurité Localisation OBLIGATOIRE Un service XKMS DOIT être capable de gérer les opérations de localisation sans recourir à des mécanismes d'authentification ou de sécurité de protocole.
(Autres) RECOMMANDÉ  
Liaison d'authentification des données utiles Toutes RECOMMANDÉ Si on utilise une signature XML, alors on DOIT gérer la canonisation exclusive.
Liaison TLS Toutes RECOMMANDÉ  

10 Les questions de sécurité

[355] Les mises en œuvre DEVRAIENT tenir compte des problèmes de sécurité suivants :

10.1 Les attaques par répétition

[356] Les mises en œuvre DEVRAIENT s'assurer que la répétition d'une réponse XKMS précédente est impossible.

[357] Le mécanisme exact pour contrarier les attaques par répétition est laissé à la mesure de la mise en œuvre. Par exemple, on PEUT utiliser, s'il en existe un, le mécanisme générique intégré au protocole d'échange de l'objet.

[358] Un moyen général qu'on peut appliquer pour prévenir une attaque par répétition consiste à placer un jeton dans chaque message afin de prouver au destinataire la fraîcheur du message, par exemple :

10.2 Le déni de service

[359] Les services XKMS DEVRAIENT prendre des mesures afin de prévenir ou atténuer les attaques par déni de service. En particulier, les services XKMS NE DEVRAIENT PAS lancer un nombre illimité d'opérations coûteuses en ressources à moins que la requête ne provienne d'une source authentifiée. Les opérations potentiellement coûteuses en ressources comprennent :

10.3 La politique de récupération

[360] Le choix de la politique de récupération des clés revient à la mise en œuvre.

[361] En fonction de la mise en œuvre et de l'application, l'opération de récupération d'une clé peut entraîner un discrédit inacceptable pour la sécurité du composant clé privée. Cette perte de confiance peut aller jusqu'à la répudiation du document signé ou de la crédibilité dans le cas d'un document crypté.

[362] Les services DEVRAIENT évaluer soigneusement dans quelles mesures une opération de récupération peut compromettre une clé privée et appliquer les contrôles suffisants telle que la révocation, si nécessaire, de la liaison de clé concernée.

10.4 La sécurité d'un secret partagé à usage limité

[363] En cas d'utilisation d'un secret partagé à usage limité, il faut s'assurer que le secret possède une entropie suffisante pour que la probabilité qu'un attaquant le devine soit faible et reste dans des limites tolérables. Il faut être particulièrement vigilant quand on se sert d'un secret partagé à usage limité pour chiffrer une clé privée générée par un service dans la mesure où la clé privée est susceptible d'une attaque par dictionnaire au cours de son transport. Les mises en œuvre ne devraient pas réutiliser les codes de révocation d'une liaison de clé à l'autre (sans égard pour la quantité d'entropie consommée pour les générer). Remarquez qu'une protection forte de la confidentialité des éléments RevocationCodeIdentifier et RevocationCode peut contribuer à réduire ce risque. Les applications DEVRAIENT respecter les valeurs minimales suivantes pour l'entropie du secret partagé :

Enregistrement d'une clé générée par le client
Le secret partagé DEVRAIT contenir un minimum de 32 bits d'entropie dans le cas où le service met en œuvre des mesures pour empêcher la prédiction du secret partagé (des mesures qui PEUVENT inclure une protection forte de la confidentialité des codes de révocation et de leurs identificateurs, qui barre les attaques par dictionnaire et protège des attaquants essayant de reconnaître les collisions délibérées ou accidentelles des codes de révocation) et un minimum de 128 bits sinon.
Enregistrement d'une clé générée par un service
Le secret partagé DEVRAIT avoir un minimum de 128 bits d'entropie.

10.5 La confidentialité des données opaques d'un client

[364] Les clients NE DEVRAIENT PAS envoyer des données confidentielles ou touchant à la vie privée à un service XKMS en tant que données opaques, à moins que celles-ci ne soient cryptées et ne puissent donc pas être divulguées au service.

[365] Comme exemple de données confidentielles : les indexes de programmes internes tels que des pointeurs qui permettraient à un tiers malveillant ayant un accès au service XKMS, ou à son journal d'audit, de lancer une attaque en s'appuyant sur la connaissance de l'état interne du client.

10.6 La sécurité des données d'authentification non liées

[366] Si un service permet d'utiliser une authentification en recourant à l'élément <NotBoundAuthentication>, alors on DOIT exercer des contrôles afin d'assurer la confidentialité des données d'authentification et pour s'assurer que l'élément <NotBoundAuthentication> est lié à la requête.

[367] Cela PEUT revêtir la forme d'un protocole au niveau du message ou au niveau du transport qui protège à la fois le chiffrement et l'intégrité tel que le protocole TLS [RFC-2246].

10.7 L'oracle de signature

[368] Les services XKMS qui fournissent des réponses signées DEVRAIENT s'assurer que le requérant ne puisse pas solliciter une réponse prévue, offrant ainsi un oracle de signature. Un tel oracle de signature pourrait compromettre directement la clé dans un protocole différent ou permettre d'exploiter une faille dans la signature ou l'algorithme de hachage cryptographique employés.

[369] Les messages de réponse devraient inclure au moins autant de données aléatoires que la sortie de l'algorithme de hachage cryptographique utilisé pour créer la signature. Par exemple, un message signé au moyen des algorithmes RSA et SHA-1 devrait contenir au moins 160 bits de données aléatoires.

10.8 La vie privée

[370] Un service XKMS PEUT solliciter des données intéressant la vie privée. Dans certaines circonstances, la manipulation de ces données PEUT être soumise à des règlements gouvernementaux, des politiques d'entreprise ou des obligations contractuelles. Les mises en œuvre DEVRAIENT évaluer si les informations qu'elles collectent sont concernées par ces préoccupations et, le cas échéant, déployer un mécanisme de notification concernant les données privées tel que P3P [P3P].

10.9 La sécurité de la clé privée

[371] Les mises en œuvre DOIVENT s'assurer, quand une clé privée est générée par le service, que les informations utilisées pour crypter les données de la clé privée soient correctement protégées. Notamment, si on utilise une phrase d'accès d'authentification, échangée hors-bande, pour crypter la clé privée, la mise en œuvre DOIT s'assurer que le mécanisme de communication hors-bande protège la confidentialité de la phrase d'accès de manière adéquate.

[372] On recommande pour les mises en œuvre qu'elles recourent à un protocole TLS ou à un mécanisme d'échange de clé intrabande pour protéger la clé privée, au cas où la phrase d'accès d'authentification serait dévoilée.

[372a] Les mises en œuvre permettant un chiffrement des données de la clé privée DOIVENT gérer un mécanisme de secret partagé. L'usage du secret partagé est décrit en détails dans la section 8.1.

10.10 Les vulnérabilités créées par la divulgation de la longueur du message

[373] Dans certaines circonstances, la longueur d'une réponse cryptée PEUT révéler des informations utiles pour un attaquant. Par exemple, un message court peut signifier le refus d'une requête. Les solutions de déploiement DEVRAIENT évaluer si de telles divulgations peuvent entraîner la compromission d'informations confidentielles.

10.11 La vérification de la valeur de signature dans un message SOAP signé

[373a] Les mises en œuvre XKMS DOIVENT vérifier la référence de la valeur de signature dans les données à signer lors de l'utilisation d'un message SOAP signé. Elles DOIVENT également s'assurer que tous les octets dans les messages XKMS, par exemple, dans un élément <LocateRequest> .... </LocateRequest>, soient inclus dans le hachage et dans la valeur de signature résultante du message.

Annexe A : Schémas

A.1 Le schéma XKMS

Le schéma rassemblé est disponible à cette adresse.

Annexe B : Configuration pour la localisation du service (non normatif)

[374] Dans beaucoup de cas, il est souhaitable d'annoncer l'existence d'un service XKMS en recourant à une forme de protocole de recherche. Cette annexe décrit les moyens spécifiques pour annoncer l'existence des services XKMS dans le service de noms de domaine (DNS) Internet.

B.1 Le service de noms de domaine (DNS)

[375] On PEUT annoncer les prestations d'un service XKMS renseignant sur les informations de clé liées à des adresses DNS dans une zone DNS spécifiée au moyen d'un enregistrement de service SRV DNS [RFC 2782]. Un enregistrement SRV contient les champs de données suivants :

[376]_Service._Protocole.Nom Durée de vie Classe SRV Priorité Poids Port Cible
(N.D.T. _Service._Protocol.Name TTL Class SRV Priority Weight Port Target)

Service
Le nom symbolique du service demandé, selon la définition des nombres assignés du standard STD 2 ou bien une définition locale. Un caractère souligné (_) préfixe l'identificateur du service afin d'éviter les collisions avec les étiquettes DNS susceptibles de se produire.
Protocole
Le nom symbolique du protocole demandé, préfixé d'un caractère souligné pour éviter les collisions avec les étiquettes DNS susceptibles de se produire.
Nom
Le domaine auquel cet enregistrement de ressource (RR) se rapporte. L'enregistrement RR SRV est unique dans le fait que le nom (du service) que l'on recherche n'est pas ce nom.
Durée de vie (TTL)
La signification DNS standard [RFC 1035].
Classe
La signification DNS standard [RFC 1035]. Les enregistrements SRV apparaissent dans la classe IN.
Priorité
La priorité de cet hôte cible. Un client DOIT essayer de contacter l'hôte cible joignable dont le numéro de priorité est le plus faible ; les hôtes cibles avec la même priorité DEVRAIENT être testés selon un ordre défini par le champ Poids.
Poids
Un mécanisme de sélection d'un serveur. Ce champ spécifie un poids relatif pour les entrées de même priorité. Les poids plus forts DEVRAIENT avoir une probabilité proportionnelle plus élevée d'être sélectionnés. La plage de numérotation va de 0 à 65535.
Port
Le port sur l'hôte cible de ce service. La plage de numérotation va de 0 à 65535. C'est un entier de 16 bits non signé dans l'ordre des octets du réseau. Il prend souvent la forme définie dans le mémorandum sur les numéros assignés, mais ce n'est pas obligatoire.
Cible
Le nom de domaine de l'hôte cible. Il DOIT y avoir un ou plusieurs enregistrements d'adresse pour ce nom ; le nom NE DOIT PAS être un alias (dans le sens des documents RFC 1034 ou RFC 2181). Les développeurs sont invités instamment, sans y être obligés, à retourner le(s) enregistrement(s) d'adresse(s) dans la section des données supplémentaires. On ne doit pas comprimer le nom de ce champ, tant que les standards ne le permettent pas.

[377] Les services suivants sont définis :

_XKMS_XKISS_SOAP_HTTP
Un service XKMS gérant le protocole X-KISS dans la liaison SOAP et utilisant le protocole HTTP pour le transport de la couche application. La valeur du champ Protocole pour ce service est TCP.
_XKMS_XKRSS_SOAP_HTTP
Un service XKMS gérant le protocole X-KRSS dans la liaison SOAP et utilisant le protocole HTTP pour le transport de la couche application. La valeur du champ Protocole pour ce service est TCP.

[378] La publication d'un enregistrement SRV dans une zone DNS annonçant un service XKMS est une déclaration positive faite par l'opérateur de la zone selon laquelle le service XKMS en question PEUT être interrogé afin d'obtenir des renseignements concernant les informations de clé liées aux adresses de protocole dans cette zone. La publication d'un enregistrement SRV ne constitue pas un quelconque engagement de l'éditeur selon lequel les informations fournies par le service XKMS sont garanties exactes ou crédibles. Les parties concernées DOIVENT donc établir la crédibilité de toutes les informations provenant d'un service XKMS, découvert grâce à un enregistrement SRV, par d'autres moyens, par exemple, en faisant suivre les données à un service de validation XKMS.

B.1.1 Examples

[379] L'enregistrement SRV suivant annonce un service X-KISS XKMS sur le port 80 du serveur border-xkms.example.com :

[380] _XKMS_XKISS_SOAP_HTTP._TCP.example.com - IN 0 1 80 border-xkms.example.com

[381] Cet autre enregistrement SRV annonce trois services X-KISS XKMS : main1, main2 et backup. Les clients devraient diriger leurs requêtes vers main1 et main2, leurs priorités étant égales, et vers le service backup seulement si ni main1 ni main2 ne sont disponibles :

[382]
_XKMS_XKISS_SOAP_HTTP._TCP.example.com - IN 0 50 80 main1.example.com
_XKMS_XKISS_SOAP_HTTP._TCP.example.com - IN 0 50 80 main2.example.com
_XKMS_XKISS_SOAP_HTTP._TCP.example.com - IN 1 1 80 backup.example.com

Annexe C : Exemples d'échanges de protocole (non normatif)

[383] Pour la lisibilité, les exemples dans le texte courant omettent certains détails tels que les signatures d'authentification de message et les informations de liaison SOAP. Cette section présentent les messages en entier pour faciliter les tests d'interopérabilité.

C.1 Le calcul des authentifications

[384] Le calcul des valeurs d'authentification utilisées dans les exemples.

C.1.1 La clé d'authentification d'enregistrement d'Alice

Données d'authentification
024837
Données d'authentification converties
[30][32][34][38][33][37]
Clé = HMAC-SHA1 ( Données d'authentification converties, 0x1 )
[d6][cc][34][cb][83][fa][e2][99] [3a][39][3a][a8][e7][de][9a][06] [c7][fa][2c][92]

C.1.2 La clé d'authentification d'enregistrement de Bob

Données d'authentification
3N9CJ-JK4JK-S04JF-W0934-JSR09-JWIK4
Données d'authentification converties
[33][4e][39][43][4a][2d][4a][4b] [34][4a][4b][2d][53][30][34][4a] [46][2d][57][30][39][33][34][2d] [4a][53][52][30][39][2d][4a][57] [49][4b][34]
Clé = HMAC-SHA1 ( Données d'authentification converties, 0x1 )
[3f][9a][5d][33][62][96][78][87] [eb][ce][55][37][b7][40][13][e8] [cd][40][b0][3f]

C.1.3 Le chiffrement de la clé privée d'enregistrement de Bob

Données d'authentification
3N9CJ-K4JKS-04JWF-0934J-SR09JW-IK4
Données d'authentification converties
[33][4e][39][43][4a][2d][4b][34] [4a][4b][53][2d][30][34][4a][57] [46][2d][30][39][33][34][4a][2d] [53][52][30][39][4a][57][2d][49] [4b][34]
Premier bloc = HMAC-SHA1 ( Données d'authentification converties, 0x4 )
[78][e8][bb][f5][32][d0][1d][ec] [e3][8a][a9][d2][a4][a4][09][db] [ff][1a][26][5c]
Clé = Premier bloc XOR 0x4
[7c][e8][bb][f5][32][d0][1d][ec] [e3][8a][a9][d2][a4][a4][09][db] [ff][1a][26][5c]
Second bloc = HMAC-SHA1 ( Données d'authentification converties, Clé )
[db][ae][1b][95][7a][48][46][b7] [f3][6e][36][ef][0b][44][62][d0] [fe][8a][9a][7b]
Clé secrète finale
[78][e8][bb][f5][32][d0][1d][ec] [e3][8a][a9][d2][a4][a4][09][db] [ff][1a][26][5c][db][ae][1b][95]

[385] La clé secrète est utilisée pour chiffrer la clé privée de Bob de la manière suivante :

Vecteur d'initialisation
[12][6e][b1][10][8b][e3][8e][5a]
Texte en clair
<?xml version="1.0" encoding="utf-8"?>
   <RSAKeyPair xmlns="http://www.w3.org/2002/03/xkms#"> ...
Texte en clair
[3c][3f][78][6d][6c][20][76][65] [72][73][69][6f][6e][3d][22][31] [2e][30][22][20][65][6e][63][6f] [64][69][6e][67][3d][22][75][74] [66][2d][38][22][3f][3e][0a][3c] [52][53][41][4b][65][79][50][61] [69][72][20][78][6d][6c][6e][73] [3d][22][68][74][74][70][3a][2f] [2f][77][77][77][2e][77][33][2e] [6f][72][67][2f][32][30][30][32] [2f][30][33][2f][78][6b][6d][73] ...
[69][72][3e][ba][cb][c1][59][05]
Texte crypté (avec ajout initial du vecteur d'initialisation)

[12][6e][b1][10][8b][e3][8e][5a] [aa][78][45][4e][75][ff][45][ab] [61][3a][c9][cc][f9][39][9a][d4] [53][78][f0][ed][f0][4c][86][23] [3c][05][c8][92][0b][7a][ab][cb] [b1][80][96][f4][45][a7][f0][e2] [0f][9c][d9][76][e4][9a][0e][b8] [83][db][b1][c6][3a][e5][a8][d5] [f2][e2][86][03][9c][c3][9b][30] [f8][6f][67][ca][17][f1][2a][8e] [c8][67][60][c4][b2][cd][03][0f] [91][f7][00][06][67][4d][6a][de] ...
[75][7d][60][53][7c][03][e7][f0]

C.1.4 Le chiffrement de la clé privée de récupération de Bob

Données d'authentification
A8YUT vuhhu c9h29 8y43u h9j3i 23
Données d'authentification converties
[41][38][59][55][54][20][76][75] [68][68][75][20][63][39][68][32] [39][20][38][79][34][33][75][20] [68][39][6a][33][69][20][32][33]
Clé secrète
[21][02][af][d9][e4][7a][88][0b] [57][d8][80][04][4b][9e][ef][11] [77][b8][01][25][85][02][b7][4c]

C.2 Le calcul des phrases d'accès

[386] Le calcul des valeurs des phrases d'accès utilisées dans les exemples.

C.2.1 Le calcul de la phrase d'accès d'Alice

Phrase d'accès
"Help I Have Revealed My Key"
Phrase d'accès convertie
[48][65][6c][70][20][49][20][48] [61][76][65][20][52][65][76][65] [61][6c][65][64][20][4d][79][20] [4b][65][79]
Phrase d'accès 1ère passe = HMAC-SHA1 ( Données d'authentification converties, 0x2 )
[1c][08][57][c9][54][58][c2][6f] [44][32][7e][fd][0e][f0][55][b0] [8c][ad][5c][78]
Phrase d'accès 2ème passe = HMAC-SHA1 ( Phrase d'accès 1ère passe ,0x3 )
[e6][b4][4d][d9][c3][99][88][c9] [5c][88][9c][41][a9][a7][a5][ad] [90][c2][cd][21]
Codage en base 64 de la phrase d'accès
5rRN2cOZiMlciJxBqaelrZDCzSE=

C.2.2 Le calcul de la phrase d'accès de Bob

Phrase d'accès
"Have A Banana"
Phrase d'accès convertie
[48][61][76][65][20][41][20][42] [61][6e][61][6e][61]
Phrase d'accès 1ère passe = HMAC-SHA1 ( Données d'authentification converties, 0x2 )
[2b][62][13][bd][55][9d][c7][99] [f1][4e][d0][24][7c][4c][60][af] [42][0b][b1][76]
Codage en base 64 de la phrase d'accès 1ère étape
K2ITvVWdx5nxTtAkfExgr0ILsXY=
Phrase d'accès 2ème passe = HMAC-SHA1 ( Phrase d'accès 1ère passe, 0x3 )
[5b][57][bf][7b][13][63][65][23] [e9][52][e3][62][2e][35][95][e5] [6b][a0][30][cc]
Codage en base 64 de la phrase d'accès 2ème étape
W1e/exNjZSPpUuNiLjWV5WugMMw=

C.3 Les paramètres des clés privées

[387] Les paramètres des couples de clés RSA des parties sont les suivantes :

C.3.1 Les paramètres de la clé privée d'Alice

<?xml version="1.0" encoding="utf-8"?>
<RSAKeyPair xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
      xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
      xmlns="http://www.w3.org/2002/03/xkms#">
  <Modulus>
    0nIsmR+aVW2egl5MIfOKy4HuMKkk9AZ/IQuDLVPlhzOfgngjVQCjr8uvmnqtNu8HBupui8LgG
    thO6U9D0CNT5mbmhIAErRADUMIAFsi7LzBarUvNWTqYNEJmcHsAUZdrdcDrkNnG7SzbuJx+GD
    NiHKVDQggPBLc1XagW20RMvok=
  </Modulus>
  <Exponent>AQAB</Exponent>
  <P>
    7p05u5P4BO+aXdyD/6n31a4Dk9kC4Tv5fMbE15/ioPii9JwPU2J29qhO1QEqvgNwxv67w4jrC
    025Yz5LXgjziw==
  </P>
  <Q>
    4ceKAtGgSJg8ddRxwz8OESXVOd1tlSHFu7Gqona3VxbrOONLZEbsnYA4dv4nI+pxl8PmUe5CP
    gggGElx30OIuw==
  </Q>
  <DP>
    ve9rEDQVfaBYCRTKAY2DGJT+hgZ881qxGjCCaXz8gdPIqts6m85KEcchkQ3vvvawI8aLIXdwW
    TwSMLxac8y+Rw==
  </DP>
  <DQ>
    jW/x3ggx76gmn+3hAl3a0xUvORukjTrl4snOyg2ylsUNv8prrTrc+WGcfbaDEHXKiTc4bnTiX
    He8m1pPEnz9Bw==
  </DQ>
  <InverseQ>
    yxCo+k0v8n80Qeo2QAGKiwltLF+1ObyZ1TQg4chISWdfLD+j1nIKIs1miELdszjO/szLWMx5k
    A3kOLi6jXsByw==
  </InverseQ>
  <D>
    aeLWu8jh75/zRGdL6T1QFatvfH5uwHXQW4EeZJ00/P0lghEOvgNPWPGkjpaxNtW39GvaaWoJN
    pilw9CFL2HHIVn1OVZyw5BDbotQty3lm66KL7qtrjqlqyPu5ARglGqTZIaRyP8LW6NAbkyxLP
    npADVfHJuEePmooCmHbTValP0=
  </D>
</RSAKeyPair>

C.3.2 Les paramètres de la clé privée de Bob

<?xml version="1.0" encoding="utf-8"?>
<RSAKeyPair xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
      xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
      xmlns="http://www.w3.org/2002/03/xkms#">
  <Modulus>
    3FFtWUsvEajQt2SeSF+RvAxWdPPh5GSlQnp8SDvvqvCwE6PXcRWrIGmV7twNf2TUXCxYuztUU
    ClMIy14B0Q+k1ej2nekmYL7+Ic3DDGVFVaYPoxaRY0Y2lV8tOreynWegpFbITXc8V6Y02QfR5
    O7Pn1/10ElslaF/TF8MQGqYE8=
  </Modulus>
  <Exponent>AQAB</Exponent>
  <P>
    8dnXAObQvcKL0Rr/A+5Ufp1yJgLpH+uohFcJV2kUDCzv5VWKcN+LTq2mciKlnFbAQXKa5dNPO
    x4qi3An/4NSMQ==
  </P>
  <Q>
    6TUX4d9+enb/aLHtck39x7cPQWlKkNFFJAqXaaRScDhjf4d8b009uW/pu3O2BdIJPY8M/QnUR
    lqXGLqGGl26fw==
  </Q>
  <DP>
    LVEcMFcPlf72I+BjGGF4A6GM2gKBnDGUCfglD/Pohb+F0/sLTcsVV1DCd3B2h6zZqWnIDHhjy
    DgG0MnbNM1ugQ==
  </DP>
  <DQ>
    0DWm7PMtaQl1X3P8G2Gmgvjdlfj7qfAtWtBZ/ufG8oplyyab4oOD6FwSwlm82dV8iol9fy2Xa
    HjZDir6L/Ae4Q==
  </DQ>
  <InverseQ>
    sD2Vl/CCVTDbhhLwdfc4IQDBOh8xpBUV7PPM5LFGjiLetlfwaYi7Bp2ol8WF1MX88iCV2E3xO
    PCNfbMhvEB5dA==
  </InverseQ>
  <D>
    REUnMUhO6ZX6NxoCwkJ7El5wXAVGtlNJsnPqFygbeEjlBvD6TZx9TqnpP/8IX7WK6JUFWd9kn
    QJvCWeJjhbjnImSS/3xc+v+m4glnnebZbaghvfunbI++fQaNAFRVT1hLvEGknqC/7zsrUM04o
    gU7hP+XgdFTJ1QYGfGHl5c0IE=
  </D>
</RSAKeyPair>

C.3.3 Les paramètres de la clé privée du service XKMS

<?xml version="1.0" encoding="utf-8"?>
<RSAKeyPair xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
      xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
      xmlns="http://www.w3.org/2002/03/xkms#">
  <Modulus>
    189VeX3+tAcwQPGMtYm8/CEKRfe6DtBFZ11SAREHhMIqf68/dsmbes0q0dnxWQcKfQtVDfp6R
    f0ulk5rZZ3j2vHHK9OFXMfaF+zJdATJ3KkXd5myjNf2clYWqKZp7K8/7Wo/qIiL8EsCT7yihR
    QvkYfYprFbF9GjKJPs4ng+zE8=
  </Modulus>
  <Exponent>AQAB</Exponent>
  <P>
    6+mJu5c75rQ2D0NjjZVgpzwHC2Rqcz+Dqs8E+f6yN2cYH5DTRKk08YGWSJanxwkNHCRSOC8KZ
    spLzmnVUyKavw==
  </P>
  <Q>
    6i+ZxJX3FDz8SwIvFEp+Vzu2C+N3USgOWGghrZuYzxKSoawpmIU0+22IVug1H3w0c7ae+5d35
    8O8APR+7v0CcQ==
  </Q>
  <DP>
    Wizzy/P8HqyF+YGd3THbNzGX07/3fMQrdTAay+CSiODsdKxsRVOUfDg3lNmZmlgYXch4cSdyB
    2aOYYFM3LFeiw==
  </DP>
  <DQ>
    0GAuiHeP9FgXfX6h+YIXTPN6lrV9k576tLtjTCCpJYe3JVgVYvsUG6xopjvUGQHhghy69c7fC
    EBn5smmsGw8YQ==
  </DQ>
  <InverseQ>
    phQH0GiKxdQnq7xj+5z69zLL6cI/53STn/XXZz9A/XRPUJecJxUguJHgbrKAI1aylLBZB0CfS
    +UVkIkoF/nP2g==
  </InverseQ>
  <D>
    ybPx+oRlO1QAqKJa1g2vgaNL28tGrbPBOnPBQlftRArJ998OnPKfi+4YWFyvs3reNbMSwubZw
    3J4SWlv/WDN5Ux2ozdqjl8DShZfhpeRhVIkygg8tDqqbkVmuzQyUbDR5NncMiEPX5errlrCyd
    wsc2OgUDHYXslORPsRFh/Fk6E=
  </D>
</RSAKeyPair>

Annexe D : Références (non normatif)

[388] CSP C. A. R. Hoare, Communicating Sequential Processes, Prentice Hall, 1985, http://www.usingcsp.com/.

[389] P3P L. Cranor, M. Langheinrich, M. Marchiori, M. Presler-Marshall, J. Reagle, La spécification de la plateforme pour les préférences de confidentialité 1.0 (P3P1.0), recommandation du W3C du 16 avril 2002, http://www.w3.org/TR/2002/REC-P3P-20020416/ →vf.

[390] PKIX R. Housley, W. Ford, W. Polk, D. Solo, Internet X.509 Public Key Infrastructure Certificate and CRL Profile, IETF RFC 2459, janvier 1999, http://www.ietf.org/rfc/rfc2459.txt.

[391] PKCS1 B. Kaliski, PKCS #1: RSA Encryption Version 2.0, RSA Laboratories et aussi IETF RFC 2437, octobre 1998. http://www.ietf.org/rfc/rfc2437.txt.

[392] RFC2119 S. Bradner, Key words for use in RFCs to Indicate Requirement Levels, IETF RFC 2119, mars 1997, http://www.ietf.org/rfc/rfc2119.txt.

[393] RFC2459 R. Housley, W. Ford, W. Polk, D. Solo, Internet X.509 Public Key Infrastructure Certificate and CRL Profile, IETF RFC 2459, janvier 1999, http://www.ietf.org/rfc/rfc2459.txt.

[394] RFC2104 H. Krawczyk,, M. Bellare et R. Canetti, HMAC: Keyed Hashing for Message Authentication, IETF RFC 2104, février 1997. http://www.ietf.org/rfc/rfc2104.txt.

[395] RFC2246 T. Dierks, C. Allen., The TLS Protocol Version, 1.0. IETF RFC 2246, janvier 1999. http://www.ietf.org/rfc/rfc2246.txt.

[396] RFC2373 R. Hinden, S. Deering, IP Version 6 Addressing Architecture, IETF RFC 2373, juillet 1998., http://www.ietf.org/rfc/rfc2373.txt.

[397] RFC2782 A. Gulbrandsen, P. Vixie, L. Esibov, A DNS RR for specifying the location of services (DNS SRV), IETF RFC 2782, février 2000, http://www.ietf.org/rfc/rfc2782.txt.

[397b] SASLPREP K. D. Zeilenga, SASLprep: Stringprep profile for user names and passwords, IETF RFC 4013, février 2005, http://www.ietf.org/rfc/rfc4013.txt.

[398] SOAP M. Gudgin, et al., SOAP Version 1.2 Partie 1 : Structure pour l'échange de messages, recommandation du W3C du 24 juin 2003, http://www.w3.org/TR/2003/REC-soap12-part1-20030624/ →vf.

[399] XMLP XML Protocol Working Group, http://www.w3.org/2000/xp/Group/.

[400] WSDL R. Chinnici, M. Gudgin, J.-J. Moreau, J. Schlimmer, S. Weerawarana, Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language, W3C Working Draft, 3 août 2004, dernière version à http://www.w3.org/TR/wsdl20.

[401] X509 recommandation X.509 de l'ITU-T (1997 E) : Information Technology, Open Systems Interconnection - The Directory: Authentication Framework, juin 1997.

[402] XML T. Bray, E. Maler, J. Paoli, C. M. Sperberg-McQueen, Le langage de balisage extensible (XML) 1.0 (2ème édition), recommandation du W3C, octobre 2000, http://www.w3.org/TR/2000/REC-xml-20001006 →vf (1ère édition).

[403] XML-SIG D. Eastlake, J. R., D. Solo, M. Bartel, J. Boyer , B. Fox , E. Simon, La syntaxe et le traitement XML Signature, recommandation du W3C, 12 février 2002, http://www.w3.org/TR/xmldsig-core/ →vf.

[404] XML-SIG-XSD Le schéma XML Signature est disponible à http://www.w3.org/TR/xmldsig-core/xmldsig-core-schema.xsd.

[405] XML-Enc D. Eastlake, J. Reagle, T. Imamura, B. Dillaway, E. Simon, La syntaxe et le traitement XML Encryption, recommandation du W3C, 10 décembre 2002, http://www.w3.org/TR/xmlenc-core/ →vf.

[406] XML-NS T. Bray, D. Hollander, A. Layman, Les espaces de nommage dans XML, recommandation du W3C, janvier 1999, http://www.w3.org/TR/1999/REC-xml-names-19990114 →vf.

[407] XML-Schema1 H. S. Thompson, D. Beech, M. Maloney, N. Mendelsohn, XML Schema Tome 1 : Structures (2ème édition, recommandation du W3C du 28 octobre 2004, http://www.w3.org/TR/xmlschema-1/ →vf (1ère édition).

[408] XML-Schema2 P. V. Biron, A. Malhotra, XML Schema Tome 2 : Types de données (2ème édition), recommandation du W3C du 28 octobre 2004, http://www.w3.org/TR/xmlschema-2/.

[409] XAdES J.C. Cruellas, G. Karlinger, K. Sankar, Les signatures électroniques évoluées XML, note du W3C du 20 février 2003, http://www.w3.org/TR/XAdES/ →vf.

Annexe E : Remerciements (non normatif)

[410] Cette spécification est le fruit des travaux du groupe de travail XML Key Management W3C. Nous sommes reconnaissants envers les membres suivants du groupe de travail de cette spécification pour leurs contributions, conformément aux politiques vis-à-vis des contributeurs et au tableau de service actif du groupe de travail.

[411] Les participants au groupe de travail sont (au moment de la rédaction et par ordre alphabétique) : Guillermo Alvaro Rey (Trinity College Dublin), Stephen Farrell (Trinity College Dublin, Vice-Président), José Kahan (W3C, contact du groupe), Berin Lautenbach (Apache Software Foundation), Tommy Lindberg (Markup Security), Roland Lockhart (Entrust, Inc.), Vamsi Motukuru (Oracle Corp.), Shivaram Mysore (Vice-Président, rédacteur depuis le 13 avril 2004), Rich Salz (DataPower Technology, Inc.), Yunhao Zhang (SQLData Systems).

[412] Les participants précédents étaient (par ordre alphabétique) : Daniel Ash (Identrus), Blair Dillaway (Microsoft), Donald Eastlake 3rd (Motorola), Yassir Elley (Sun Microsystems), Jeremy Epstein (webMethods), Slava Galperin (Sun Microsystems), Phillip Hallam-Baker (VeriSign Inc, rédacteur jusqu'au 13 avril 2004), Loren Hart (VeriSign Inc.), Mack Hicks (Bank of America), Merlin Hughes (Baltimore), Frederick Hirsch (Nokia Mobile Phones), Mike Just (Treasury Board of Canada Secretariat), Brian LaMacchia (Microsoft), Pradeep Lamsal, Joseph Reagle (W3C, ancien contact du groupe), Dave Remy (GeoTrust, Inc.), Peter Rostin (RSA Security Inc.), Ed Simon (XMLsec Inc.)

[413] Les auteurs remercient également David Solo (CitiGroup) et Barbara Fox (Microsoft) pour leur assistance dans la conception de cette spécification et (par ordre alphabétique) le Dr. Paul Boisen (NSA), Alex Deacon, Dan Guinan, Marc Hayes, Jeremy Epstein (webMethods), Andrew Layman (Microsoft) et Mingliang Pei (VeriSign) pour leur contributions.

[414] Les personnes qui ont contribué aux débats sur www-xkms@w3.org sont aussi vivement remerciées.

Annexe F : Changements (non normatif)

Cette annexe documente les changements (autres que ceux d'ordre rédactionnel mineurs) intervenus depuis la recommandation proposée du 2 mai 2005 pour tenir compte des remarques. Chaque entrée se compose de :

Les changements du schéma XKMS intervenus entre la recommandation proposée et la recommandation

Aucun.

Les changements de la spécification XKMS intervenus entre la recommandation proposée et la recommandation

  1. Correction : supprimé une définition de service Web dans la section 1.2 car elle ne servait pas dans le document et n'était pas compatible avec l'usage actuel (337-phb) ;
  2. Correction : l'élément UseKeyWith avec les exemples d'application "urn:ietf:rdf:2459", paragraphes 246 et 252, n'était pas correctement échappé (342-ml) ;
  3. Correction : rendu les paragraphes 102 et 103 plus intelligibles en renforçant la terminologie RFC 2119 terminology, en substituant le terme chaîne par adresse URI et en indiquant quels éléments XKMS contiennent des éléments <RespondWith> (344-ml) ;
  4. Correction : le paragraphe 218 se terminait par Les éléments <UnverifiedKeyBinding> retournés sont spécifiés par l'élément Respond dans la requête mais il faudrait y lire par l'élément RespondWith dans la requête (347-kj).