[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.
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.
[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
.
[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.
[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 utilesOn 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.
[16] Un renforcement de la sécurité PEUT être nécessaire pour
contrôler les risques suivants :
- La confidentialité
- L'authentification de la requête
- L'authentification de la réponse
- L'authentification persistante
- La répétition de la réponse
- La substitution de la requête
- La répétition de la requête
- Le déni de service
[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.
[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 :
- Une clé racine incorporée dans l'application cliente ;
- Une clé de signature obtenue par d'autres mécanismes de récupération tels que PKIX
[RFC3280] ou SPKI [RFC2693].
[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.
[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.
[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.
[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.
[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>.
[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.
[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.
[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. |
[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.
[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.
[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/).
[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].
[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.
[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.
[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).
- 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" ;
- 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 ;
- 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" ;
- 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 ;
- 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>
[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).
- 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" ;
- 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 ;
- 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" ;
- 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 ;
- 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>
[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].
[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 |
[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. |
[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 |
[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/
[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.
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 :
- un numéro de changement ;
- une brève description et, le cas échéant, ce qui a été fait ;
- un lien vers le message ayant initié le changement (si celui-ci est public).
- 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) ;
- 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) ;
- Correction : La fin du paragraphe [47] comportait un point-virgule en double
(338-tl-2) ;
- 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) ;
- 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).
