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.

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] :

[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 :

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 :

[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 :

• La clé peut être désignée par un nom seul ;
• La politique de confiance locale du client peut demander d'autres informations pour agréer la clé ;
• La clé peut être codée dans un certificat X.509 que le client ne peut pas analyser.

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

• Le client peut ne pas connaître la clé publique du destinataire.

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 :

[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.

• En traitement synchrone, le service répond à une requête de telle manière que, ses obligations étant remplies, il ne répondra plus à la requête en question : il retourne l'un des codes de réponse du jeu Final défini au paragraphe [43].
• En traitement asynchrone, le service ne satisfait pas la requête immédiatement et envoie une notification selon laquelle la requête n'a pas encore été réalisée et que d'autres réponses suivront : il retourne un code de réponse intermédiaire, autre que l'un de ceux trouvés dans le jeu Final.

[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 :

[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) :

[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 :

• Requête initiale / phase 1
• Requête initiale / phase 2
• Réponse en instance

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

• L'attribut OriginalRequestId est affecté de la valeur de l'attribut Id du message de la requête initiale de la phase 1 dans les deux requêtes suivantes.
• L'attribut Nonce est affecté de la valeur de l'attribut Nonce du message de la réponse de la phase 1 dans les deux requêtes 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 :

• La confidentialité
• L'authentification des requêtes
• L'authentification des réponses
• L'authentification intermédiaire
• La répétition des réponses
• La substitution des requêtes
• La répétition des requêtes
• Le déni de service

[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 :

[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é :

• En isolant le message XKMS de toute enveloppe (par exemple, SOAP) avant la validation, ou ;
• En spécifiant un algorithme de canonisation, telle que la canonisation XML exclusive, dans un élément <SignedInfo>:<CanonicalizationMethod>, afin d'exclure tout contexte XML ancestral pendant la validation du message.

[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 :

[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 :

[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#) :

[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 :

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

[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 :

[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 :

[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#) :

[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#) :