Lisez-moi S.V.P. 
W3C

Les liaisons de 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-bindings-20050628/
Dernière version :
http://www.w3.org/TR/xkms2-bindings/
Version précédente :
http://www.w3.org/TR/2005/PR-xkms2-bindings-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.


Résumé

[2] Ce document spécifie les liaisons de protocoles présentant des caractéristiques de sécurité pour la spécification de la gestion des clés XML (XKMS)→vf.

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 consite à 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 deuxième partie de la recommandation du W3C de la spécification de la gestion des clés XML (XKMS version 2.0). Ce document couvre différentes liaisons de protocoles présentant des caractéristiques de sécurité pour la spécification XKMS. La première partie→vf de cette spécification couvre les protocoles et services 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 des liaisons 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 C.

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

1.1 Les conventions d'écriture et de conformité

[8] Cette spécification utilise des schémas XML [XML-schema] pour décrire le modèle de contenu.

[9] 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 les employer que s'ils sont réellement nécessaires pour l'interopérabilité ou pour limiter un comportement potentiellement néfaste (par exemple, en limitant les retransmissions)

[11] 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

[14] Ce document fait un usage identique des termes définis dans la section 1.2→vf de la première partie de cette spécification.

1.3 La structure du document

[15] La suite du 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 règles de sécurité
On y décrit les règles de sécurité pour le protocole XKMS.
Section 3 : Le protocole de sécurité des données utiles
On y décrit les propriétés de sécurité gérées par les caractéristiques de sécurité des données utiles XKMS.
Section 3 : La liaison avec SOAP
On y décrit le transport des messages XKMS en utilisant le protocole de messagerie SOAP
Section 4 : Les liaisons de sécurité
On y décrit les caractéristiques de la sécurité des données utiles XKMS en fonction de protocoles de sécurité spécifiques.
Section 5 : Les considérations de 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.

2 Les règles de sécurité

[16] Un renforcement de la sécurité PEUT être nécessaire pour contrôler les risques suivants :

[17] Les renforcements de sécurité nécessaires varient selon l'application. Dans le cas de prestations gratuites ou non mesurées, le service n'exigera pas forcément l'authentification de la requête. Le serveur qui impose une requête authentifiée devra déterminer si celle-ci correspond à la réponse spécifiée.

2.1 La confidentialité

[18] La confidentialité du message protège les messages de protocole contre une divulgation à des tiers. La confidentialité PEUT être une obligation pour un service XKMS. Les infrastructures DEVRAIENT être évaluées afin de déterminer dans quelles mesures le contenu des messages XKMS peut révéler des informations sensibles. Il PEUT exister une obligation de confidentialité, même si le service n'offre que des informations provenant de sources publiques, si le contenu d'une requête est susceptible de dévoiler des informations à propos du client.

[19] L'emploi d'une protection de la confidentialité du transport ou des données utiles N'EST PAS un substitut au chiffrement des clés privées spécifié dans les services d'enregistrement ou de récupération XKRSS. Un service qui permet l'enregistrement de clés générées par un serveur ou la récupération de clés DOIT mettre en œuvre une procédure de chiffrement XML fort.

[20] Un service XKMS DEVRAIT offrir une confidentialité par chiffrement.

[21] Cette spécification ne précise pas les moyens par lesquels le client détermine la crédibilité de la clé de chiffrement du service. Quelques mécanismes possibles :

[22] Un service XKMS PEUT déterminer la crédibilité d'une clé de chiffrement par référence à un autre service XKMS, à condition que la chaîne des références se fonde sur un mécanisme qui établisse une relation de confiance directe entre le client et le service.

2.2 L'authentification de la requête

[23] Une authentification du message de requête PEUT être exigée. Un service XKMS PEUT imposer une authentification des requêtes aux infrastructures dans lesquelles le service XKMS s'adresse à un public spécifique, par exemple, dans le cas de prestations payantes. Un service XKMS PEUT imposer une authentification des requêtes dans les contextes offrant différents niveaux de prestation selon l'identité du requérant.

[24] En outre, le protocole d'enregistrement XKRSS PEUT imposer au requérant diverses formes d'authentification afin qu'il confirme ses autorisations et la possession du composant clé privée du (ou des) couple(s) de clés en cours d'enregistrement.

[25] Un service XKMS DEVRAIT gérer l'authentification des messages de requête.

2.3 L'authentification de la réponse

[26] Une authentification du message de réponse PEUT être exigée. L'authentification des messages de réponse est obligatoire pour les infrastructures de validation. Un service de localisation qui ne fournit que des données authentiques, tels que des certificats X.509 ou PGP, n'est pas tenu à l'authentification des messages de réponse.

[27] Remarquez qu'on distingue l'authentification des messages de réponse de la protection contre la répétition des réponses.

[28] Un service XKMS DEVRAIT gérer l'authentification des requêtes messages de réponse.

2.4 L'authentification persistante

[29] Dans certaines circonstances, les requêtes ou les réponses, ou toutes deux, PEUVENT nécessiter une authentification persistante. À savoir, un message envoyé par A et authentifié par B peut être transmis et soumis à une authentification auprès de C. Certaines applications peuvent, en outre, imposer d'autres mesures afin de s'assurer que les messages satisfassent à certains standards légaux pour éviter leur répudiation.

[30] Un service XKMS PEUT mettre en œuvre une authentification persistante en recourant à une signature numérique sur le message.

2.5 La corrélation des messages (répétition de la réponse et substitution de la requête)

[31] Un service XKMS DOIT offrir un moyen permettant d'assurer correctement la corrélation des messages. À savoir, le requérant doit être assuré que la réponse retournée a bien été faite en réponse à la requête voulue envoyée au service et non à une modification de cette requête (attaque par substitution de requête) ou en réponse à une requête antérieure (attaque par répétition de réponse) .

[32] Afin de prévenir les attaques par répétition de la réponse et celles par substitution du message de requête, le requérant DEVRAIT s'assurer que la réponse corresponde à la requête. Pour que la vérification de correspondance soit possible, il est nécessaire d'authentifier la réponse. Dans la liaison avec le protocole TLS, la correspondance entre la requête et la réponse est établie par la couche de transport. Pour les mécanismes de sécurité placés au niveau de la couche du message, tel que le protocole de sécurité des données utiles, le mécanisme nécessaire dépendra de l'authentification ou non de la requête, comme suit :

La requête est authentifiée
Si la requête et la réponse sont authentifiées, leur correspondance peut être déterminée en vérifiant la valeur de l'attribut RequestId dans la réponse.
La requête est authentifiée par une empreinte numérique
Si la requête originale a été authentifiée au moyen d'une signature XML, avec une empreinte numérique comme algorithme de signature, le service peut toujours déterminer une relation forte entre la réponse et la requête originale en recourant à l'élément <RequestSignatureValue>.

2.6 La répétition de la requête

[33] Un service XKMS PEUT imposer une protection contre les attaques par répétition de la requête. Si aucune comptabilité ou autre audit ne sont employés pour suivre les requêtes effectuées, alors il n'est pas nécessaire de recourir à une telle protection contre ce type d'attaque.

[34] Un service XKMS PEUT offrir une protection contre les attaques par répétition.

2.7 Le déni de service

[35] Un service XKMS PEUT imposer une protection contre les attaques par déni de service en recourant aux capacités d'un protocole. Ces mesures ne sont pas obligatoires lorsque le service XKMS est protégé contre les attaques par déni de service par d'autres moyens, par exemple, si le service fonctionne sur un réseau isolé et étroitement contrôlé et qu'il ne fournit aucune prestation en dehors de ce réseau.

[36] Les attaques par déni de service qui proviennent d'une seule source ou d'un seul ensemble de sources peuvent être neutralisées en appliquant des contrôles de vélocité. Au cas où la source du déni de service serait déguisée, on peut recourir à des techniques d'authentification légères, tel que le protocole à deux phases décrit plus loin, pour détecter les requêtes provenant d'adresses falsifiées.

[37] Un service XKMS DEVRAIT gérer une protection contre les attaques par déni de service.

2.8 Le récapitulatif des règles de sécurité

[38] Le tableau suivant récapitule les règles de sécurité auxquelles une infrastructure de service XKMS peut être soumise :

Point de sécurité Condition Commentaires
Confidentialité Quelques unes Les informations fournies par un service XKMS peuvent être confidentielles ; le fait qu'un tiers demande des informations particulières à un service XKMS peut permettre la déduction d'informations confidentielles. Toutefois, nombreuses sont les applications XKMS qui ne nécessitent aucune confidentialité.
Authentification de la requête Quelques unes Un service ne doit authentifier une requête pour des informations que si celles-ci sont confidentielles ou s'il faut payer d'une manière ou d'une autre pour utiliser le service.
Authentification de la réponse La plupart Un service XKMS qui n'offre que des prestations de localisation pour des informations de clé authentiques, tels que des certificats numériques, n'a pas besoin d'authentification.
Authentification persistante Quelques unes Bien que certaines applications XKMS soient formellement tenues de gérer la non-répudiation, la faculté de répudier les requêtes et les réponses est acceptable dans beaucoup d'applications.
Correspondance des messages Toutes Le mécanisme de correspondance de l'attribut RequestId n'est utilisable que si le mécanisme d'authentification des requêtes est fiable. Sinon on devrait utiliser le mécanisme d'empreinte numérique.
Répétition de la requête Quelques unes Les attaques par répétition de la requête ne constituent vraisemblablement un problème que si chaque requête est payante ou s'il s'agit d'un type d'attaque par déni de service.
Déni de service La plupart Toute prestation disponible sur un réseau public est susceptible d'une attaque par déni de service. Le risque d'une telle attaque est considéré généralement comme faible sur les réseaux fermés tels que les réseaux d'entreprises internes.

[39] Lorsque les règles de sécurité du protocole XKRSS diffèrent de celles du protocole XKISS, elles sont directement traitées par le protocole XKRSS plutôt que de compter sur la liaison de sécurité du message.

[40] Par exemple, les fonctions d'enregistrement XKRSS sont conçues pour permettre des modes d'utilisation dans lesquels la requête d'enregistrement d'un client, après son acceptation par une autorité d'enregistrement locale, est transmise à une autorité d'enregistrement centrale. Dans ce mode, il est essentiel que la preuve de possession de la clé en cours d'enregistrement puisse être contrôlée par l'autorité locale comme par l'autorité centrale, même si l'authentification de la requête envoyée à l'autorité centrale est probablement le fait de l'autorité locale au nom du requérant original. La distribution des clés privées obéit à des considérations similaires.

Point de sécurité Condition Commentaires
Confidentialité des clés privées Si usage d'un couple de clés généré par un serveur Si un service d'enregistrement permet l'enregistrement d'un couple de clés généré par un serveur ou la récupération de clés, alors un chiffrement fort de la clé privée DOIT être mis en œuvre.
Authentification d'une requête d'enregistrement Quelques unes Les services d'enregistrements XKMS DEVRAIENT gérer l'authentification des requêtes d'enregistrement pour l'enregistrement initial d'une liaison de clé. Les requêtes secondaires d'enregistrement pour des autorisations délivrées précédemment (c'est-à-dire, une liaison de clé signée ou un certificat numérique) PEUVENT être admises sans authentification.
Preuve de possession lors d'un enregistrement Quelques unes Les services d'enregistrement XKMS DEVRAIENT gérer la vérification de la preuve de possession lors de l'enregistrement initial de clés générées par le client.
Authentification par code de révocation Quelques unes Le code de révocation XKMS est authentique.

3 La liaison avec SOAP

[41] Cette section décrit un mécanisme permettant la transmission des messages XKMS, définis dans la première partie de cette spécification, au moyen du protocole de messagerie SOAP. Les développeurs XKMS devraient mettre en œuvre le protocole de messagerie SOAP pour l'interopérabilité. Le cas échéant, ils DOIVENT employer la liaison décrite ici. Les liaisons pour les deux protocoles SOAP 1.2 [SOAP1.2-1][SOAP1.2-2] et SOAP 1.1 [SOAP] ont été définies.

[42] Les mises en œuvres XKMS 2.0 DOIVENT gérer l'utilisation de SOAP 1.2. Pour une compatibilité à court terme avec les outils et infrastructures existants, elles PEUVENT utiliser SOAP 1.1.

3.1 La liaison du message SOAP XKMS

3.1.1 La liaison avec SOAP 1.2

[43] Les développeurs XKMS devront utiliser la messagerie de style requête-réponse des documents SOAP avec les messages XKMS, définis dans la première partie de la spécification, lesquels sont transportés comme contenu littéral de l'élément Body. Cela équivaut à associer le contenu de l'élément Body à un attribut SOAP 1.2 env:encodingStyle→vf de valeur "http://www.w3.org/2003/05/soap-envelope/encoding/none".

[44] La liaison XKMS devra suivre le modèle de transmission de messages par requête-réponse SOAP, défini dans la spécification [SOAP1.2-2], et le traitement des messages devra être conforme à ce modèle. Les messages SOAP 1.2 transportant un contenu XKMS devront employer le codage de caractères UTF-8 afin d'assurer une interopérabilité.

[45] Les messages SOAP 1.2 transportant un contenu XKMS devront être conformes à la structure suivante :

[46] Le message de requête XKMS :

<?xml version='1.0' encoding="utf-8"?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"> 
  <env:Body>
     L'élément de message de requête XKMS
  </env:Body>
</env:Envelope>

[47] Le message de réponse XKMS :

<?xml version='1.0' encoding="utf-8"?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"> 
  <env:Body>
     L'élément de message de réponse XKMS
  </env:Body>
</env:Envelope>

[48] Il n'est pas nécessaire d'utiliser des en-têtes SOAP dans la liaison de message SOAP et XKMS. On peut utiliser des en-têtes avec les messages SOAP transportant un contenu XKMS pour fournir des prestations supplémentaires concernant, par exemple, la sécurité des échanges ou le routage. L'utilisation de ces en-têtes n'est pas définie par cette spécification. Toutefois, si on les utilise, elles ne doivent pas altérer le style de codage du message ni le modèle de traitement SOAP spécifiés ici.

[49] Voici un exemple de messages LocateRequest et LocateResponse transportés par messages SOAP 1.2 :

[50] Le message LocateRequest :

<?xml version="1.0" encoding="utf-8"?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
  <env:Body>
    <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>
  </env:Body>
</env:Envelope>

[51] Le message LocateResponse :

<?xml version="1.0" encoding="utf-8"?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
  <env:Body>
    <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>
  </env:Body>
</env:Envelope>

[52] Les messages SOAP 1.2 transportant d'autres types de messages XKMS s'inspireront évidemment de la structure de cet exemple.

3.1.2 La liaison avec SOAP 1.1

[53] Les développeurs XKMS qui utilisent une messagerie SOAP 1.1 devront recourir à une transmission de type requête-réponse et feront transporter les messages XKMS comme contenu littéral de l'élément SOAP Body. On ne devra pas suivre le modèle de codage décrit dans la section 5 de la spécification SOAP 1.1. Les messages SOAP 1.1 transportant un contenu XKMS devront utiliser le codage de caractères UTF-8 afin d'assurer une interopérabilité.

[54] La structure des messages SOAP 1.1 XKMS devra se conformer au modèle suivant :

[55] Le message de requête XKMS :

<?xml version='1.0' encoding="utf-8"?>
<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> 
  <env:Body>
     L'élément de message de requête XKMS
  </env:Body>
</env:Envelope>

[56] Le message de réponse XKMS :

<?xml version='1.0' encoding="utf-8"?>
<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> 
  <env:Body>
     L'élément de message de réponse XKMS
  </env:Body>
</env:Envelope>

[57] Comme pour SOAP 1.2, il n'est pas nécessaire d'utiliser des en-têtes SOAP avec la liaison SOAP 1.1. On peut en utiliser avec les messages SOAP transportant un contenu XKMS pour fournir des prestations supplémentaires concernant, par exemple, la sécurité des échanges ou le routage, à condition qu'elles n'influent pas sur le style de codage du message ni sur le modèle de traitement SOAP spécifiés ici.

[58] Les messages SOAP 1.1 transportant un contenu XKMS sont identiques à ceux fondés sur SOAP 1.2 à l'exception de l'espace de nommage des éléments Envelope et Body. Ainsi, les exemples donnés dans la section 3.1.1 seraient conformes si on remplaçait l'espace de nommage SOAP 1.2 par celui de SOAP 1.1 (http://schemas.xmlsoap.org/soap/envelope/).

3.2 Les inclusions d'espaces de nommage

[59] Lorsqu'on utilise la liaison SOAP XKMS, les messages XKMS se construisent selon la définition de la première partie de cette spécification, y compris l'ensemble des déclarations d'espaces de nommage nécessaires. L'élément du message au niveau supérieur est alors inséré comme sous-élément de l'élément SOAP Body. La promotion des déclarations de l'espace de nommage XKMS au niveau de l'élément SOAP parent Body (ou du parent Envelope de celui-ci) n'est pas nécessaire mais elle est possible, à la discrétion du développeur. Cette promotion de l'espace de nommage n'est généralement pas souhaitable lorsque le message XKMS contient une signature numérique, car elle peut nuire à une vérification ultérieure.

[60] Les messages XKMS à incorporer dans des documents SOAP DEVRAIENT être signés en recourant à l'algorithme de canonisation XML exclusive [XML-EXC-C14N].

3.3 Le calcul des éléments XML Signature dans les messages XKMS

[61] L'utilisation de la liaison SOAP XKMS ne gêne pas le traitement des éléments <KeyBindingAuthentication> et <ProofOfPossession>, décrits par la spécification XML Signature. Leur calcul a lieu comme indiqué, respectivement, dans les sections 7.1.4→vf et 7.1.6→vf de la première partie de la spécification XKMS, et le traitement de validation de la signature comme indiqué dans la section 3.1.2 L'élément <ds:Signature>→vf. C'est-à-dire, les nœuds et espaces de nommage définis par SOAP n'interviennent pas dans le calcul de la signature.

3.4 L'utilisation des erreurs SOAP

[62] Le service XKMS utilisera les erreurs SOAP pour signaler les erreurs qui empêchent le traitement du message de requête XKMS reçu. Les clients XKMS ne devraient jamais envoyer de message d'erreur SOAP à un service XKMS.

3.4.1 Les erreurs SOAP 1.2

[63] On définit les messages d'erreur SOAP suivants à utiliser avec la liaison SOAP 1.2 XKMS. Conformément à la spécification SOAP 1.2, ces messages d'erreur contiendront les éléments d'information Code et Reason obligatoires. L'inclusion d'autres éléments est à la discrétion du développeur.

[64] En réponse à un message de requête XKMS, s'il est incapable de le traiter, le récepteur devra répondre par l'une des erreurs SOAP suivantes. S'il peut le traiter, alors la réponse devrait se conformer à la description d'un message de réponse XKMS valide (cf. la première partie de la spécification).

  1. Une erreur avec une valeur de "env:VersionMismatch" pour l'élément Code sera retournée lorsque le service XKMS trouve un élément d'information invalide au lieu de l'élément d'information Envelope attendu, ou que l'espace de nommage, le nom local ou les deux ne correspondaient pas à l'élément d'information obligatoire Envelope. L'élément Reason devra avoir la valeur "Unsupported SOAP version" ;
  2. Une erreur avec une valeur de "env:MustUnderstand" pour l'élément Code sera retournée si un sous-élément d'information de l'élément d'information SOAP Header n'était pas compris ou bien pas interprété par le nœud fautif alors que l'élément Header contenait un attribut SOAP mustUnderstand ayant la valeur "1". L'élément Reason devra avoir la valeur "Unable to process [nom de l'élément d'en-tête]", où l'expression entre crochets désigne l'élément d'information d'en-tête à l'origine de l'erreur ;
  3. Une erreur avec une valeur de "env:Receiver" pour l'élément Code sera générée lorsque le récepteur ne peut pas manipuler le message pour des raisons temporaires, par exemple, un épuisement de la mémoire disponible. L'élément Reason devra avoir la valeur "Service temporarily unable" ;
  4. Une erreur avec une valeur de "env:Sender" pour l'élément Code et une valeur de "xkms:MessageNotSupported" pour l'élément Subcode sera générée lorsque le récepteur ne gère pas le type du message de requête. L'élément Reason devra avoir la valeur "[type du message XKMS] not supported", où l'expression entre crochets désigne le nom de l'élément d'information correspondant au message de requête XKMS reçu ;
  5. Une erreur avec une valeur de "env:Sender" pour l'élément Code et une valeur de "xkms:BadMessage" pour l'élément Subcode sera générée lorsque le récepteur ne peut pas interpréter le message XKMS reçu. L'élément Reason devra avoir la valeur "[type du message XKMS] invalid", où l'expression entre crochets désigne le nom de l'élément d'information correspondant au message de requête XKMS reçu.

[65] Voici un exemple de message d'erreur SOAP 1.2 qui aurait été retourné si le message de requête XKMS reçu n'était pas géré par le service :

<?xml version="1.0" ?>

<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
 <env:Body>
  <env:Fault>
    <env:Code>
      <env:Value>env:Sender</env:Value>
      <env:Subcode>
        <env:Value>xkms:MessageNotSupported</env:Value>
      </env:Subcode>
    </env:Code>
    <env:Reason>LocateRequest message not supported</env:Reason>
   </env:Fault>
 </env:Body>
</env:Envelope>

3.4.2 Les erreurs SOAP 1.1

[66] On définit les messages d'erreur SOAP suivants à utiliser avec la liaison SOAP 1.1 XKMS. Conformément à la spécification SOAP 1.1, ces messages d'erreur devront contenir les éléments faultcode et faultstring. L'inclusion d'autres éléments est à la discrétion du développeur.

[67] En réponse à un message de requête XKMS, s'il est incapable de le traiter, le récepteur devra répondre par l'une des erreurs SOAP suivantes. S'il peut le traiter, alors la réponse devrait se conformer à la description d'un message de réponse XKMS valide (cf. la première partie de la spécification).

  1. Une erreur avec une valeur de "env:VersionMismatch" pour l'élément faultcode devra être retournée lorsque le service XKMS ne trouve pas l'élément Envelope attendu, ou l'espace de nommage, le nom local, ou les deux, ne correspondaient pas à l'élément obligatoire Envelope. L'élément faultstring devra avoir la valeur "Unsupported SOAP version" ;
  2. Une erreur avec une valeur de "env:MustUnderstand" pour l'élément faultcode devra être retournée si un sous-élément immédiat de l'élément SOAP Header n'était pas compris ou pas respecté par le nœud fautif alors que l'en-tête contenait un attribut SOAP mustUnderstand ayant la valeur "1". L'élément faultstring devra avoir la valeur "Unable to process [nom de l'élément d'en-tête]", où l'expression entre crochets désigne le premier élément d'information d'en-tête à l'origine de l'erreur ;
  3. Une erreur avec une valeur de "env:Server" pour l'élément faultcode devra être retournée lorsque le service ne peut pas manipuler le message pour des raisons temporaires , par exemple, un épuisement de la mémoire disponible. L'élément faultstring devra avoir la valeur "Service temporarily unable" ;
  4. Une erreur avec une valeur de "env:Client" pour l'élément faultcode sera retournée lorsque le récepteur ne gère pas le type du message de requête. L'élément faultstring devra avoir la valeur "[type du message XKMS] not supported", où l'expression entre crochets désigne le nom de l'élément d'information correspondant au message de requête XKMS reçu ;
  5. Une erreur avec une valeur de "env:Client" pour l'élément faultcode devra être retournée lorsque le récepteur ne peut pas analyser le message XKMS reçu. L'élément faultstring devra avoir la valeur "[type du message XKMS] invalid", où l'expression entre crochets désigne le nom de l'élément d'information correspondant au message de requête XKMS reçu.

[68] Voici un exemple de message d'erreur SOAP 1.1 qui aurait été retourné si le message de requête XKMS reçu n'était pas géré par le service :

<?xml version="1.0" ?>
<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
 <env:Body>
  <env:Fault>
    <env:faultcode>env:Client</env:faultcode>
    <env:faultstring>LocateRequest message not supported</env:faultstring>
   </env:Fault>
 </env:Body>
</env:Envelope>

3.5 La liaison SOAP sur HTTP

[69] Lorsque la mise en œuvre concerne la liaison SOAP 1.2 XKMS, les messages SOAP devraient être envoyés en utilisant la méthode HTTP POST, conformément aux recommandations de la section 6.4.2 de la spécification [SOAP1.2-2]. Le traitement sera celui décrit dans la section 7 La liaison SOAP sur HTTP de cette spécification.

[70] Lorsque la mise en œuvre concerne la liaison SOAP 1.1 XKMS, les messages SOAP devraient être envoyés en utilisant la méthode HTTP POST, conformément à la section 6.1 de la spécification [SOAP].

4 Les liaisons de sécurité

[71] Cette spécification décrit les deux principales liaisons de sécurité, chacune d'elles spécifiant deux (ou plus) profils de mise en œuvre.

Caractéristique Sécurité des données utiles Sécurité de la couche de transaction transport (TLS)
Dépendances Authentification définie par la spécification XKMS ; le client n'a pas besoin de mettre en place un dispositif complet. Mécanisme d'authentification défini par le protocole TLS que les clients doivent mettre en œuvre.
Utilisation de XML Signature Emploi d'une signature XML en mode enveloppé qui demande un traitement légèrement plus complexe. Pas nécessaire
Gestion du routage La spécification ne décrit qu'une authentification bilatérale : le routage des messages avec sauts multiples et les transactions entre tiers multiples ne sont pas gérés Aucune
Gestion de la confidentialité Aucune, bien que les applications puissent recourir au protocole TLS pour établir un canal sécurisé. Gérée
Non-répudiation Gérée Nécessite une sécurité des données utiles supplémentaire
Authentification d'un tiers non déclaré Gérée Nécessite une sécurité des données utiles supplémentaire
Authentification du client Gérée Gérée au travers d'un certificat d'authentification du client ou au travers de la sécurité des données utiles

4.1 La liaison d'authentification des données utiles

[71a]

Les modes d'authentification du client :
Aucun mécanisme n'est utilisé pour authentifier le client
Le client est authentifié par un recours à la sécurité des données utiles

[71b] Dans le tableau suivant, l'intitulé Requête/Signature signifie que l'élément d'une requête XKMS inclut un élément <dsig:Signature> en mode enveloppé. Cette signature est calculée en utilisant une méthode de signature numérique. Dans le tableau du paragraphe [72], l'intitulé Requête/MAC Request.Signature avec authentification MAC revêt le même sens, à ceci près que la signature se calcule en recourant à un code d'authentification du message (MAC).

Point de sécurité Mode d'authentification du client Gestion Commentaires
Mécanisme d'authentification du client Aucun mécanisme d'authentification n'est utilisé. Aucune  
Authentification utilisant la sécurité des données utiles Données utiles Requête/Signature
Mécanisme d'authentification du service Sans objet Données utiles Réponse/Signature
Correspondance requête/réponse Authentification utilisant la sécurité des données utiles Données utiles Message/RequestId
Protection contre attaque par répétition Tous Données utiles Message/Nonce dans le protocole à deux phases
Protection contre attaque par déni de service Tous Données utiles Requête/RespondWith="Represent"
Non-répudiation Tous Données utiles Message/Signature avec signature numérique

[72] Les caractéristiques suivantes de la sécurité des données utiles sont employées :

(élément XKMS).(nom d'attribut) Niveau d'obligation
MessageAbstractType.Service Obligatoire
MessageAbstractType.Signature Obligatoire dans un profil où le client est authentifié par un recours à la sécurité des données utiles, pour les messages de requête comme pour ceux de réponse.
ResultType.RequestId Obligatoire
PendingRequestType.ResponseId Obligatoire
MessageAbstractType.Nonce Optionnel : peut servir en protection contre une attaque par déni de service.
MessageAbstractType.RespondWith="Represent" Optionnel : peut servir en protection contre une attaque par déni de service.
Request.Signature avec authentification MAC Obligatoire dans un profil où aucun mécanisme n'est utilisé pour authentifier le client, optionnel dans un profil où l'authentification du client est assurée par la sécurité des données utiles.

4.2 La liaison Secure Socket Layer/Transaction Transport Layer Security (SSL/TLS)

[73] Lorsqu'on doit recourir au protocole TLS dans XKMS, les serveurs XKMS DOIVENT gérer la sécurité par la couche de transport authentifiée par le serveur. Remarquez que le client XKMS devra seulement gérer une sécurité TLS anonyme, car sinon cela voudrait dire que tous les clients XKMS auraient à stocker des certificats racines pour utiliser la sécurité TLS.
Tous les clients et serveurs XKMS qui gèrent le protocole TLS DOIVENT gérer l'ensemble de chiffrement TLS_RSA_WITH_3DES-EDE_CBC_SHA.
D'autres ensembles de chiffrement PEUVENT être gérés, toutefois la gestion des ensembles de chiffrement faibles conçus pour satisfaire aux règlements à l'exportation (qualité export) N'EST PAS RECOMMANDÉE.

[74] La liaison SSL/TLS offre trois modes d'authentification du client :

Les modes d'authentification du client SSL/TLS :
Aucun mécanisme n'est utilisé pour authentifier le client.
L'authentification du client basée sur un certificat TLS.
L'authentification du client basée sur la sécurité des données utiles.

[74a]

Point de sécurité Mode d'authentification du client Gestion Commentaires
Mécanisme d'authentification du client. Aucun mécanisme d'authentification n'est utilisé. Aucune  
Authentification du client basée sur un certificat TLS. TLS Authentification du client basée sur un certificat.
Authentification utilisant la sécurité des données utiles. Données utiles Requête/Signature
Mécanisme d'authentification du service Sans objet TLS  
Correspondance requête/réponse Tous TLS Message/RequestId
Protection contre attaque par répétition. Tous TLS Message/Nonce dans le protocole à deux phases.
Protection contre attaque par déni de service Tous Aucune Le protocole TLS n'offre aucune parade spécifique contre les attaques par déni de service.
Non-répudiation Tous Données utiles Message/Signature avec signature numérique (si nécessaire)

[75] Les caractéristiques suivantes de la sécurité des données sont employées :

(élément XKMS).(nom d'attribut) Niveau d'obligation
MessageAbstractType.Service Obligatoire mais pas dépendant
MessageAbstractType.Signature Optionnel : peut servir à mettre en œuvre la non-répudiation, pour les messages de requête comme pour ceux de réponse.
ResultType.RequestId Obligatoire mais pas dépendant
PendingRequestType.ResponseId Obligatoire mais pas dépendant
MessageAbstractType.Nonce Superflu
MessageAbstractType.RespondWith="Represent" Superflu

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

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

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

[78] RFC2693 C. Ellison et. al., Simple Public Key Infrastructure Certificate Theory, IETF RFC 2693, septembre 1999, http://www.ietf.org/rfc/rfc2693.txt 

[79] RFC3280 R. Housley et. al., Public Key Infrastructure (X.509) (PKIX) Certificate and Certificate Revocation List (CRL) Profile, IETF RFC 3280, avril 2002, http://www.ietf.org/rfc/rfc3280.txt 

[80] SOAP D. Box, D Ehnebuske, G. Kakivaya, A. Layman, N. Mendelsohn, H. Frystyk Nielsen, S Thatte, D. Winer, Simple Object Access Protocol (SOAP) 1.1, Note du W3C, 8 mai 2000, http://www.w3.org/TR/2000/NOTE-SOAP-20000508/

[81] SOAP1.2-1 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

[82] SOAP1.2-2 M. Gudgin, et al., SOAP Version 1.2 Partie 2 : Ajouts, recommandation du W3C du 24 juin 2003, http://www.w3.org/TR/2003/REC-soap12-part2-20030624/→vf

[85] XML-SIG D. Eastlake, J. R., D. Solo, M. Bartel, J. Boyer , B. Fox , E. Simon, Syntaxe et traitement des signatures XML, recommandation du W3C, http://www.w3.org/TR/xmldsig-core/→vf

[86] XML-SIG-XSD Schéma de XML Signature disponible à http://www.w3.org/TR/xmldsig-core/xmldsig-core-schema.xsd

[86a] XML-EXC-C14N J. Boyer, D. E. Eastlake, J. Reagle, La canonisation XML exclusive, recommandation du W3C du 8 juillet 2002, http://www.w3.org/TR/2002/REC-xml-exc-c14n-20020718/→vf

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

[88] 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

[89] 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)

[90] 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/

Annexe B : Remerciements (non normatif)

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

[92] 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).

[93] 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.).

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

Annexe C : 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 dans la spécification des liaisons XKMS intervenus entre le statut de recommandation proposée et celui de recommandation

  1. Changement : Le texte du paragraphe [60] était ambigu quant à la façon d'éviter les collisions des préfixes d'espaces de nommage lors de l'incorporation des messages XKMS dans les documents SOAP. Il a été modifié afin de préciser que les messages XKMS DEVRAIENT être signés en utilisant une canonisation exclusive, ce qui était déjà suggéré par les paragraphes [89] et [90] de la première partie de la spécification XKMS (345-ml) ;
  2. Correction : Les paragraphes [46], [47], [55] et [56] de la deuxième partie indiquaient incorrectement que l'élément SOAP Body résidait dans l'élément SOAP Header (338-tl-1) ;
  3. Correction : La fin du paragraphe [47] comportait un point-virgule en double (338-tl-2) ;
  4. Correction : Éclairci le paragraphe [43] pour dire que les messages XKMS sont transportés dans les messages SOAP 1.2 comme contenu littéral de l'élément Body. Supprimé la justification selon laquelle le codage n'était pas sélectionné parce qu'il était devenu inutile (339-ml) ;
  5. Correction : Éclairci le paragraphe [53] pour dire que les messages XKMS sont transportés dans les messages SOAP 1.2 comme contenu littéral de l'élément Body (348-ml).