Résumé

Ce document spécifie une transformation pour le décryptage des signatures XML permettant aux applications XML Signature de distinguer les structures XML Encryption qui ont été chiffrées avant signature (et ne doivent pas être décryptées) de celles qui l'ont été après signature (et doivent être décryptées) pour valider la signature.

Statut de ce document

Table des matières

1. Introduction
   1. Objectif
   2. Conventions de rédaction
   3. Remerciements
2. La syntaxe de la transformation de décryptage
3. La transformation de décryptage en mode XML
   1. Les règles de traitement
   2. La création d'une transformation (non normatif)
   3. Exemple
   4. Restrictions et limitations
      1. La contrainte des données bien-formées
      2. L'héritage des attributs de l'espace de nommage XML
      3. Les références et les changements structuraux
      4. Les références et le surchiffrement
      5. Les références XPointer à nom non strict
      6. Les interactions avec les autres filtres
      7. L'élément EncryptedKey est hors d'atteinte
4. La transformation de décryptage en mode binaire
   1. Les règles de traitement
   2. Exemple
5. Considérations sur la sécurité
   1. Les signatures opérant sur des données cryptées peuvent révéler des informations
   2. Signez ce que vous voyez
6. Références

1 Introduction

1.1 Objectif

David Solo a remarqué, in [Solo], que les opérations de signature [XML-Signature] et de chiffrement [XML-Encryption] peuvent toutes deux être réalisées sur un document XML n'importe quand et dans n'importe quel ordre, notamment dans les scénarios de flux de production. Par exemple, Alice souhaite commander et payer un livre à Bob en employant le système de paiement ZipPay dans lequel ils ont mutuellement confiance. Bob crée un bon de commande comprenant le titre du livre, son prix et les informations sur son compte. Il veut signer tous ces renseignements, mais il va chiffrer les infos sur son compte ensuite seulement pour ZipPay. Il envoie le tout à Alice qui vérifie le titre du livre et le prix, signe le bon et présente la commande doublement signée accompagnée par ses propres informations de paiement à ZipPay. Pour valider les deux signatures, ZipPay devra savoir que la version cryptée des données d'information cryptées est nécessaire pour valider la signature d'Alice, mais la forme avec les données non cryptées est nécessaire pour valider celle de Bob. (Voir Signez ce que vous voyez (section 5.2) pour plus d'information sur la signature de données cryptées).

Étant donné que les opérations de chiffrement effectuées après une opération de signature sur une partie du contenu déjà signé rendent la signature invérifiable, il est nécessaire de décrypter les parties cryptées après signature, avant que la signature ne soit vérifiée. La transformation de décryptage proposée dans ce document fournit ce mécanisme ; le décryptage des seules parties signées-puis-chiffrées (tout en ignorant celles chiffrées-puis-signées). Le signataire peut introduire cette transformation dans une séquence de transformations (par exemple, avant XML canonique [XML-C14N] ou XPath [XPath]) s'il existe une possibilité pour que quelqu'un chiffre des parties de la signature.

La transformation définie dans ce document est destinée à apporter une solution au problème de l'ordre de décryptage/vérification à l'intérieur des ressources signées. Il n'est pas dans le champ d'application de ce document de traiter des cas dans lesquels on peut déduire l'ordre à partir du contexte. Par exemple, quand un élément ds:DigestValue ou (une partie d')un élément ds:SignedInfo sont chiffrés, l'ordre est évident (sans décryptage, la vérification de signature est impossible) et il n'est pas nécessaire de faire appel à une autre transformation.

1.2 Conventions de rédaction

Dans ce document, les mots-clés DOIT, NE DOIT PAS, DEVRA, NE DEVRA PAS, DEVRAIT, NE DEVRAIT PAS, RECOMMANDÉ, PEUT et OPTIONNEL doivent être interprétés comme décrit dans RFC2119 [Keywords].

Ce document fait usage des espaces de nommage [XML-Encryption] et [XML-Signature], et définit le sien propre avec les préfixes suivants :

xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns:dcrpt="http://www.w3.org/2002/07/decrypt#"

Alors que les implémentations DOIVENT gérer XML et les espaces de nommage XML, l'utilisation de nos préfixes d'espace de nommage XML "xenc", "ds" et "dcrpt" est OPTIONNELLE ; nous employons cette facilité pour la compacité et la lisibilité de l'exposé. En outre, l'entité &xenc; est empruntée à [XML-Encryption] pour fournir des identificateurs abrégés pour les adresses URI définies dans cette spécification. Par exemple, "&xenc;Element" correspond à "http://www.w3.org/2001/04/xmlenc#Element".

1.3 Remerciements

Les membres suivants du groupe de travail sont vivement remerciées pour leur participation à cette spécification :

• Hal Finney, PGP Security
• Amir Herzberg, NewGenPay
• Takeshi Imamura, IBM
• Ari Kermaier, Phaos
• Hiroshi Maruyama, IBM
• Joseph Reagle, W3C
• David Solo, Citigroup

2 La syntaxe de la transformation de décryptage

Cette transformation gère deux modes opératoires. En mode XML, les données sont en XML crypté et le résultat est un ensemble de nœuds. En mode binaire, les données forment une séquence d'octets cryptée et le résultat du décryptage est une séquence d'octets. Dans les deux modes, on peut exclure du traitement les éléments xenc:EncryptedData de l'ensemble de nœuds en entrée en utilisant des éléments dcrpt:Except. L'élément dcrpt:Except est défini plus loin par un schéma XML [XML-Schema] et survient comme sous-élément direct de l'élément ds:Transform.

La valeur de l'attribut URI OBLIGATOIRE de l'élément dcrpt:Except identifie les éléments xenc:EncryptedData en entrée auprès de la transformation. La valeur DOIT être une adresse URI [URI] non vide dans un même document (c'est-à-dire, un caractère dièse #) suivi par une expression XPointer [XPointer] comme profilé par Le modèle de traitement des références [XML-Signature, section 4.3.3.2].

  Définition de schéma :

  <?xml version="1.0" encoding="utf-8"?>
  <!DOCTYPE schema PUBLIC "-//W3C//DTD XMLSchema 200102//EN"
    "http://www.w3.org/2001/XMLSchema.dtd" [
    <!ATTLIST schema
      xmlns:dt CDATA #FIXED "http://www.w3.org/2002/07/decrypt#">
    <!ENTITY % p ''>
    <!ENTITY % s ''>
  ]>

  <schema xmlns="http://www.w3.org/2001/XMLSchema" version="0.1"
          xmlns:dt="http://www.w3.org/2002/07/decrypt#"
          targetNamespace="http://www.w3.org/2002/07/decrypt#"
          elementFormDefault="qualified">

    <element name="Except" type="dt:ExceptType"/>
    <complexType name="ExceptType">
      <attribute name="Id" type="ID" use="optional"/>
      <attribute name="URI" type="anyURI" use="required"/>
    </complexType>
  </schema>

3 La transformation de décryptage en mode XML

Identificateur :

http://www.w3.org/2002/07/decrypt#XML

Ce mode de la transformation requiert un ensemble de nœuds XPath [XPath] comme entrée. Quand un flux d'octets est fourni en entrée, il DOIT être converti en un ensemble de nœuds comme décrit dans Le modèle de traitement des références (section 4.3.3.2) de la spécification de la signature XML [XML-Signature]. La transformation décrypte tous les éléments xenc:EncryptedData, sauf ceux spécifiés par les éléments dcrpt:Except. La sortie de la transformation est un ensemble de nœuds.

3.1 Les règles de traitement

Cette section décrit les règles de traitement de la transformation. Les règles se résument à deux fonctions : les entrées et sorties de la transformation sont celles de la fonction decryptXML(), qui elle-même appelle la fonction decryptNodeSet().

O = decryptXML(N, E)

où N représente un ensemble de nœuds et E l'ensemble des adresses URI d'exceptions que portent les attributs URI des éléments dcrpt:Except. O est un ensemble de nœuds calculé de la manière suivante :

1. Soit Y, un jeu d'ensemble de nœuds de remplacement, égal à decryptNodeSet(N, E) ;
2. Canoniser avec remplacement : convertir N en un flux d'octets B, (qui DOIT être bien-formé (voir la section 3.4.1)), en utilisant la transformation XML canonique [XML-C14N] comme décrit dans Le modèle de traitement des références [XML-Signature, section 4.3.3.2] ; mais au lieu de traiter un éventuel élément xenc:EncryptedData d avec ses descendants, traiter l'ensemble de nœuds de remplacement O_d, provenant de Y. Au cours de cette étape, on DOIT augmenter (voir la section 3.4.2) la canonisation de l'ensemble de nœuds de remplacement comme suit :
   • Une déclaration d'espace de nommage xmlns="" DOIT être émise pour chaque élément apex qui n'a pas de nœud déclarant une valeur pour l'espace de nommage par défaut, comme décrit dans La sérialisation du XML [XML-Encryption, section 4.3.3] ;
   • Si un ensemble de nœuds remplace un élément de N dont l'élément parent n'est pas dans N, alors ses éléments apex DOIVENT hériter des attributs associés à l'espace de nommage XML de l'élément parent, tels que xml:base, xml:lang et xml:space.

   B peut ne pas être dans une forme canonique.

3. Soit O, la sortie de cette fonction, un ensemble de nœuds converti à partir de B comme décrit dans Le modèle de traitement des références [XML-Signature, section 4.3.3.2].
   • Si l'analyse de B échoue, alors l'implémentation DOIT signaler un échec de la transformation.
   • Même s'il n'y a pas d'élément xenc:EncryptedData décrypté, remarquer que N est toujours canonisé et analysé.

Y = decryptNodeSet(N, E)

où N représente un ensemble de nœuds et E l'ensemble des adresses URI des exceptions que portent les attributs URI des éléments dcrpt:Except. Y est un jeu d'ensembles de nœuds, calculé comme suit :

1. Soit D un ensemble de nœuds contenant tous les nœuds d'éléments dans N avec le type xenc:EncryptedData qui ne sont pas identifiés par une quelconque adresse URI d'exception dans E.
   • Lors de la résolution d'une adresse URI d'exception dans le contexte de l'ensemble de nœuds original en entrée, l'implémentation DOIT se comporter comme si le nœud document de l'ensemble de nœuds en entrée était utilisé pour initialiser le contexte d'évaluation XPointer [XPointer], même si ce nœud ne fait pas partie de l'ensemble de nœuds. Au contraire d'une signature XML [XML-Signature], une adress URI d'exception peut être évaluée par rapport à un document différent de celui du nœud racine du document XML contenant l'attribut URI. Si l'entrée est un document différent, alors l'utilisation de la fonction here() est une erreur selon XPointer [XPointer].
   • Lors de la résolution d'une adresse URI d'exception dans le contexte d'un ensemble de nœuds de remplacement, on utilise des noms simples XPointer [XPointer] pour localiser les éléments xenc:EncryptedData avec les attributs Id correspondants. Les implémenteurs PEUVENT essayer de résoudre des pointeurs XPointer complets en ensembles de nœuds de remplacement, en recourant à des techniques appropriées pour tenir compte de l'emplacement de l'ensemble de nœuds de remplacement dans le document en entrée, voir Les références XPointer à nom non strict (section 3.4.5).
   • Si une adress URI d'exception échoue à résoudre des nœuds, alors l'erreur résultante DOIT être ignorée ; cela peut provenir d'une partie cryptée du document en entrée.
2. Soit Y {}, un ensemble vide.
3. Pour chaque élément xenc:EncryptedData d issu de D :
   1. Décrypter d, sans se soucier, le cas échéant, desquels de ses descendants se trouvent dans N, et le traiter en fonction de la valeur de son attribut Type, ce qui résulte dans un ensemble de nœuds O_d.
      • Par exemple, le traitement d'un élément xenc:EncryptedData, avec l'attribut Type dont la valeur est &xenc;Element ou &xenc;Content, est spécifié dans Une implémentation de décryptage (section 4.3.1) de [XML-Encryption], et le résultat est un ensemble de nœuds ;
      • Si l'attribut Type est absent, n'est pas connu du moteur de décryptage ou le résultat de son traitement n'est pas un ensemble de nœuds, alors l'implémentation DOIT signaler un échec de la transformation ;
      • Si le décryptage d'un quelconque élément xenc:EncryptedData échoue, alors l'implémentation DOIT signaler un échec de la transformation.
   2. Remplacer Y par Y ∪ {O_d} ;
   3. Si O_d contient des éléments xenc:EncryptedData qui ne sont pas dans E, remplacer Y par Y ∪ decryptNodeSet(O_d, E). Ceci va décrypter récursivement les données surcryptées dans l'ensemble de nœuds de remplacement.

3.2 La création d'une transformation (non normatif)

Cette spécification ne propose pas de mécanisme pour la création d'un élément ds:Transform dans une séquence de transformation [XML-Signature]. Néanmoins, voici une approche (non normatif) :

1. Appliquer à l'objet-données en cours de signature toutes celles des transformations qui apparaissent avant cette transformation ;
2. Si la transformation juste avant celle-ci donne en sortie un flux d'octets, le convertir en un ensemble de nœuds, comme décrit dans Le modèle de traitement des références [XML-Signature, section 4.3.3.2] ;
3. Pour chacun des nœuds dans l'ensemble de nœuds, si celui-ci est un nœud élément de type xenc:EncryptedData, créer un élément dcrpt:Except qui référence le nœud ;
4. Créer un élément ds:Transform, qui inclut l'identificateur d'algorithme de cette transformation et tous les éléments dcrpt:Except créés lors de l'étape 3.

3.3 Exemple

Supposons qu'une partie ([02-14]) du document XML suivant doit être signée. Remarquer que certaines parties du document ([05,11,12]) sont déjà cryptées, préalablement à la signature. Supposons également que le signataire prévoit que d'autres parties du document seront chiffrées après la signature.

  [01] <Document>
  [02]   <ToBeSigned Id="tbs">
  [03]     <Part number="1">
  [04]       <Data>...</Data>
  [05]       <xenc:EncryptedData Id="#secret-1" .../>
  [06]     </Part>
  [07]     <Part number="2">
  [08]       <Data>...</Data>
  [09]     </Part>
  [10]     <Secrets>
  [11]       <xenc:EncryptedData .../>
  [12]       <xenc:EncryptedData .../>
  [13]     </Secrets>
  [14]   </ToBeSigned>
  [15] </Document>

Pour permettre au destinataire de connaître l'ordre exact du décryptage et de la vérification de signature, le signataire inclut la transformation de décryptage ([a19-a22]) dans la signature. Les éléments dcrpt:Except ([a20,a21]) identifient les parties du document qui sont déjà cryptées.

  [a01] <Document>
  [a02]   <ToBeSigned Id="tbs">
  [a03]     <Part number="1">
  [a04]       <Data>...</Data>
  [a05]       <xenc:EncryptedData Id="#secret-1" .../>
  [a06]     </Part>
  [a07]     <Part number="2">
  [a08]       <Data>...</Data>
  [a09]     </Part>
  [a10]     <Secrets>
  [a11]       <xenc:EncryptedData .../>
  [a12]       <xenc:EncryptedData .../>
  [a13]     </Secrets>
  [a14]   </ToBeSigned>
  [a15]   <dsig:Signature ...>
  [a16]     ...
  [a17]     <dsig:Reference URI="#tbs">
  [a18]       <dsig:Transforms>
  [a19]         <dsig:Transform Algorithm="http://www.w3.org/2002/07/decrypt#XML">
  [a20]           <dcrpt:Except URI="#secret-1"/>
  [a21]           <dcrpt:Except URI="#xpointer(id('tbs')/Secrets/*)"/>
  [a22]         </dsig:Transform>
  [a23]       </dsig:Transforms>
  [a24]       ...
  [a25]     </dsig:Reference>
  [a26]     ...
  [a27]   </dsig:Signature>
  [a28] </Document>

Considérons que ce document sera chiffré ensuite par diverses méthodes, produisant le résultat suivant :

  [b01] <Document>
  [b02]   <ToBeSigned Id="tbs">
  [b03]     <xenc:EncryptedData Id="part-1" Type="&enc;Element" .../>
  [b04]     <xenc:EncryptedData Id="part-2" Type="&enc;Element" .../>
  [b05]     <Secrets>
  [b06]       <xenc:EncryptedData .../>
  [b07]       <xenc:EncryptedData .../>
  [b08]     </Secrets>
  [b09]   </ToBeSigned>
  [b10]   <dsig:Signature ...>
  [b11]     ...
  [b12]     <dsig:Reference URI="#tbs">
  [b13]       <dsig:Transforms>
  [b14]         <dsig:Transform Algorithm="http://www.w3.org/2002/07/decrypt#XML">
  [b15]           <dcrpt:Except URI="#secret-1"/>
  [b16]           <dcrpt:Except URI="#xpointer(id('tbs')/Secrets/*)"/>
  [b17]         </dsig:Transform>
  [b18]       </dsig:Transforms>
  [b19]       ...
  [b20]     </dsig:Reference>
  [b21]     ...
  [b22]   </dsig:Signature>
  [b23] </Document>

L'exécution de la transformation de décryptage se déroulera comme suit :

1. L'entrée de la transformation, noté N, est un ensemble de nœuds contenant l'élément ToBeSigned et ses sous-éléments, sans les commentaires ([b02-b09]). Le paramètre de la transformation, noté E, est un ensemble contenant les deux adresses URI d'exceptions ([b15,b16]) ;
2. La première adresse URI d'exception ne se résoud pas dans ce document ; la seconde se résoud dans les deux sous-éléments de l'élément Secrets ([b06,b07]) ;
3. Par conséquent, D pour N est un ensemble de nœuds constitué des deux éléments xenc:EncryptedData, d_part-1 ([b03]) et d_part-2 ([b04]). Chacun d'eux est décrypté, ce qui aboutit aux deux ensembles de nœuds pour O_part-1 et O_part-2 :

   « errata E01 »

     [c01] <Part number="1">
     [c02]   <Data>...</Data>
     [c03]   <xenc:EncryptedData Id="#secret-1" .../>
     [c04] </Part>

     [d01] <Part number="2">
     [d02]   <xenc:EncryptedData Id="#data-2" Type="&enc;Element" .../>
     [d03] </Part>

4. Après cette étape de décryptage, deux nouveaux éléments xenc:EncryptedData ([c03] et [d02]) auront été révélés. Cependant, le premier correspond à une adresse URI d'exception avec un nom nu et donc n'est pas évalué plus avant ; ainsi, D pour O_part-1 est vide, alors que D pour O_part-2 contient juste d_data-2 de l'élément xenc:EncryptedData ([d02]). Ce qui est décrypté à nouveau et résulte dans l'ensemble de nœuds O_data-2 suivant :

     [e01] <Data>...</Data>

5. Aucun nouvel élément xenc:EncryptedData n'est révélé, donc D pour O_data-2 est vide et le traitement se poursuit vers la canonisation ;
6. L'opération de canonisation-avec-remplacement canonise l'ensemble de nœuds N ; mais, au lieu de tous les éléments xenc:EncryptedData qui ont été décryptés, elle canonise les ensembles de nœuds de remplacement. De la même façon, elle remplace également les éventuels éléments xenc:EncryptedData dans les ensembles de nœuds de remplacement. Et plus, la canonisation de chacun des ensembles de nœuds de remplacement est augmentée de telle sorte qu'un attribut xmlns="" soit émis sur chacun des éléments apex qui n'ont pas de nœud d'espace de nommage déclarant une valeur pour l'espace de nommage par défaut. Les données canonisées résultantes sont les suivantes :

     [f01] <Document>
     [f02]   <ToBeSigned Id="tbs">
     [f03]     <Part xmlns="" number="1">
     [f04]       <Data>...</Data>
     [f05]       <xenc:EncryptedData Id="#secret-1" .../>
     [f06]     </Part>
     [f07]     <Part xmlns="" number="2">
     [f08]       <Data xmlns="">...</Data>
     [f09]     </Part>
     [f10]     <Secrets>
     [f11]       <xenc:EncryptedData .../>
     [f12]       <xenc:EncryptedData .../>
     [f13]     </Secrets>
     [f14]   </ToBeSigned>
     [f15] </Document>

7. Puis ce flux d'octets est analysé et retourné comme sortie de la transformation.

3.4 Restrictions et limitations

3.4.1 La contrainte des données bien-formées

Comme spécifié dans l'étape 2 de la fonction decryptXML(), le flux d'octets résultant d'une canonisation-avec-remplacement DOIT être bien-formé. Généralement, ceci sera caractérisé par un ensemble de nœuds avec racine unique en entrée : on dit que l'ensemble de nœuds a une racine unique si et seulement si tous ses nœuds membres sont soit (1) le premier nœud de l'ensemble de nœud dans l'ordre du document, soit (2) un nœud descendant du premier nœud, soit (3) un nœud attribut ou un nœud espace de nommage d'un autre nœud dans l'ensemble de nœuds. De surcroît, si l'ensemble de nœuds en entrée possède en position supérieure un élément xenc:EncryptedData en cours de décryptage, alors ceci DEVRAIT correspondre à un ensemble de nœuds avec racine unique. Cependant, ce n'est pas nécessairement le cas : après décryptage, plusieurs nœuds de niveau supérieur peuvent être bien-formés s'ils consistent de blancs, de commentaires, d'instructions de traitement et d'un seul élément. Aucun traitement particulier n'est requis pour tester cette condition puisque des données mal-formées provoqueront une erreur d'analyse.

3.4.2 L'héritage des attributs de l'espace de nommage XML

Comme spécifié dans l'étape 2 de la fonction decryptXML(), l'étape de canonisation avec remplacement nécessite un héritage de l'attribut de l'espace de nommage XML. L'une des caractéristiques de l'algorithme XML canonique [XML-C14N], qui est appliqué automatiquement par la transformation de décryptage, c'est que tous les attributs ancestraux issus de l'espace de nommage XML (par exemple, xml:lang) sont hérités par tout élément dont le nœud parent ne se trouve pas dans l'ensemble de nœuds canonisé. L'héritage au cours de l'étape 2 garantit la préservation de ces attributs pendant le décryptage et le remplacement. Prenons, par exemple, le document signé suivant :

  [01] <Document xml:lang="ga">
  [02]   <ToBeSigned Id="tbs">
  [03]     ...
  [04]   </ToBeSigned>
  [05]   <dsig:Signature ...>
  [06]     ...
  [07]     <dsig:Reference URI="#tbs">
  [08]       <dsig:Transforms>
  [09]         <dsig:Transform Algorithm="http://www.w3.org/2001/04/decrypt#XML" />
  [10]       </dsig:Transforms>
  [11]       ...
  [12]     </dsig:Reference>
  [13]     ...
  [14]   </dsig:Signature>
  [15] </Document>

La forme canonique de l'élément ToBeSigned (la cible de la référence #tbs, [02-04]) est la suivante ([a01-a03]) :

  [a01] <ToBeSigned Id="tbs" xml:lang="ga">
  [a02]     ...
  [a03]   </ToBeSigned>

Toutefois, si cet élément signé supérieur est chiffré par la suite en recourant à un algorithme de sérialisation XML qui ne prend pas en compte les attributs hérités de l'espace de nommage XML ([b02-b04]) :

  [b01] <Document xml:lang="ga">
  [b02]   <xenc:EncryptedData Id="tbs" ...>
  [b03]     ...
  [b04]   </xenc:EncryptedData>
  [b05]   <dsig:Signature ...>
  [b06]     ...

Au moment du décryptage, le document qui sera analysé pour former le nœud de remplacement serait le suivant :

  [c01] <dummy><ToBeSigned xmlns="" Id="tbs">
  [c02]     ...
  [c03]   </ToBeSigned></dummy>

Puisque ce fragment ne se trouve plus dans son contexte ancestral original, la forme canonique de l'élément ToBeSigned ([d01-d03]) ne correspondrait plus à celle qui a été signée au départ et l'opération de vérification de signature échouerait.

  [d01] <ToBeSigned Id="tbs">
  [d02]     ...
  [d03]   </ToBeSigned>

Comme montré, cet échec survient souvent quand un élément directement signé a été chiffré. Le remède consiste dans l'augmentation de la canonisation interne de l'étape de canonisation-avec-remplacement de la fonction decryptXML() : les ensembles de nœuds, qui remplacent des éléments dont le nœud parent ne fait pas partie de l'ensemble de nœuds signé à l'origine, sont canonisés avec les attributs issus de l'espace de nommage XML qui aurait été hérité par l'élément non crypté dans son document original.

Bien que ce changement ait lieu pour maintenir la validité des signatures utilisant [XML-C14N], il n'interfère pas avec la validité des signatures utilisant [XML-exc-C14N]. Cette transformation et l'incorporation des attributs issus de l'espace de nommage XML (c'est-à-dire, 'xml:') s'effectuent au cours de la validation et de la génération de la signature. Par conséquent, la forme canonisée exclusivement de l'élément va conserver ces attributs 'xml:' — même si la forme canonisée exclusivement de l'élément ne les aurait pas obtenus sans cette transformation.

3.4.3 Les références et les changements structuraux

La résolution des adresses URI avec un pointeur XPointer complet ou une séquence en sous-élément (qu'elles se trouvent dans des exceptions, des données cryptées ou ailleurs) peut échouer si le chiffrement amène un changement structurel dans une partie du document sur laquelle compte la référence. Par exemple, l'adresse URI #xpointer(/ToBeSigned/*[3]) ne fonctionnera plus si les deux premiers sous-éléments de l'élément ToBeSigned sont chiffrés ensemble. On DEVRAIT être prudent lors de l'emploi de telles références conjointement avec la transformation de décryptage.

3.4.4 Les références et le surchiffrement

Le surchiffrement peut causer des problèmes quand un élément xenc:EncryptedData surcrypté utilise des références dans un même document, ou quand un élément xenc:EncryptedData surcrypté exceptionnel est référencé par l'adresse URI d'un pointeur XPointer à nom non strict. Le surcryptage de données signées dans ces conditions N'EST PAS RECOMMANDÉ : le surchiffrement n'aura pas lieu, ou alors on ne devrait pas employer de telles références.

Comme exemple de surchiffrement sur des références dans un même document pouvant causer des problèmes, prenons le document signé suivant ([02-05]) :

  [01] <Document>
  [02]   <ToBeSigned Id="tbs">
  [03]     <Data>...</Data>
  [04]     ...
  [05]   </ToBeSigned>
  [06]   <dsig:Signature ...>
  [07]     ...
  [08]     <dsig:Reference URI="#tbs">
  [09]       <dsig:Transforms>
  [10]         <dsig:Transform Algorithm="http://www.w3.org/2002/07/decrypt#XML" />
  [11]       </dsig:Transforms>
  [12]       ...
  [13]     </dsig:Reference>
  [14]     ...
  [15]   </dsig:Signature>
  [16]   ...
  [17] </Document>

Si l'élément Data ([03]) est chiffré par la suite, en même temps que des données ailleurs dans le document, le nouvel élément xenc:EncryptedData pourrait utiliser une méthode de rapport dans un même document pour identifier les informations partagées par la gestion des clés ([a06]) :

  [a01] <Document>
  [a02]   <ToBeSigned Id="tbs">
  [a03]     <xenc:EncryptedData ...>
  [a04]       ...
  [a05]       <dsig:KeyInfo ...>
  [a06]         <dsig:RetrievalMethod URI="#key-info" 
                 Type="http://www.w3.org/2001/04/xmlenc#EncryptedKey" .../>
  [a07]       </dsig:KeyInfo>
  [a08]       ...
  [a09]     </xenc:EncryptedData>
  [a10]     ...
  [a11]   </ToBeSigned>
  [a12]   <xenc:EncryptedKey Id="key-info" .../>
  [a13]   <dsig:Signature ...>
  [a14]     ...
  [a15]     <dsig:Reference URI="#tbs">
  [a16]       <dsig:Transforms>
  [a17]         <dsig:Transform 
                 Algorithm="http://www.w3.org/2002/07/decrypt#XML"/>
  [a18]       </dsig:Transforms>
  [a19]       ...
  [a20]     </dsig:Reference>
  [a21]     ...
  [a22]   </dsig:Signature>
  [a23] </Document>

Si ce nouvel élément xenc:EncryptedData est surchiffré par la suite ([b02]), la transformation de décryptage échouera : quand la méthode de rapport interne est effectuée, elle sera résolue dans le contexte d'un nouveau document décrypté qui ne contient pas les informations référencées de gestion de clés.

  [b01] <Document>
  [b02]   <xenc:EncryptedData Id="tbs" .../>
  [b03]   <xenc:EncryptedKey Id="key-info" .../>
  [b04]   <dsig:Signature ...>
  [b05]     ...
  [b06]     <dsig:Reference URI="#tbs">
  [b07]       <dsig:Transforms>
  [b08]         <dsig:Transform Algorithm="http://www.w3.org/2002/07/decrypt#XML" />
  [b09]       </dsig:Transforms>
  [b10]       ...
  [b11]     </dsig:Reference>
  [b12]     ...
  [b13]   </dsig:Signature>
  [b14] </Document>

Lors du décryptage, le document, qui aurait été analysé pour former l'ensemble de nœuds de remplacement, serait :

  [d01] <dummy><ToBeSigned Id="tbs">
  [d02]   <xenc:EncryptedData ...>
  [d03]     ...
  [d04]     <dsig:KeyInfo ...>
  [d05]       <dsig:RetrievalMethod URI="#key-info" 
               Type="http://www.w3.org/2001/04/xmlenc#EncryptedKey"
               .../>
  [d06]     </dsig:KeyInfo>
  [d07]     ...
  [d08]   </xenc:EncryptedData>
  [d09]   ...
  [d10] </ToBeSigned></dummy>

3.4.5 Les références XPointer à nom non strict

Comme exemple où la résolution des pointeurs XPointer à nom non strict peut échouer, prenons le document signé suivant ([02-07]), lequel recourt à un pointeur XPointer complet ([13]) pour identifier les données déjà cryptées quand la signature a été générée ([05]) et qui ne devrait donc pas être traitées par la transformation de décryptage :

  [01] <Document>
  [02]   <ToBeSigned Id="tbs">
  [03]     <Data>...</Data>
  [04]     <Secrets>
  [05]       <xenc:EncryptedData Id="#secret-1" .../>
  [06]     </Secrets>
  [07]   </ToBeSigned>
  [08]   <dsig:Signature ...>
  [09]     ...
  [10]     <dsig:Reference URI="#tbs">
  [11]       <dsig:Transforms>
  [12]         <dsig:Transform Algorithm="http://www.w3.org/2002/07/decrypt#XML">
  [13]           <dcrpt:Except URI="#xpointer(/Document/ToBeSigned/Secrets/*)"/>
  [14]         </dsig:Transform>
  [15]       </dsig:Transforms>
  [16]       ...
  [17]     </dsig:Reference>
  [18]     ...
  [19]   </dsig:Signature>
  [20] </Document>

Si l'élément Secrets est chiffré par la suite, comme montré dans le code suivant ([a04]), c'est-à-dire que l'élément xenc:EncryptedData existant sera surcrypté, alors l'adresse URI d'exception XPointer ne pourra plus se résoudre. En conséquence, la transformation de décryptage essaiera alors de réaliser un surdécryptage de l'élément xenc:EncryptedData interne et le traitement échouera.

  [a01] <Document>
  [a02]   <ToBeSigned Id="tbs">
  [a03]     <Data>...</Data>
  [a04]     <xenc:EncryptedData Id="#secrets" .../>
  [a05]   </ToBeSigned>
  [a06]   <dsig:Signature ...>
  [a07]     ...
  [a08]     <dsig:Reference URI="#tbs">
  [a09]       <dsig:Transforms>
  [a10]         <dsig:Transform Algorithm="http://www.w3.org/2002/07/decrypt#XML">
  [a11]           <dcrpt:Except URI="#xpointer(/Document/ToBeSigned/Secrets/*)"/>
  [a12]         </dsig:Transform>
  [a13]       </dsig:Transforms>
  [a14]       ...
  [a15]     </dsig:Reference>
  [a16]     ...
  [a17]   </dsig:Signature>
  [a18] </Document>

La raison pour laquelle le pointeur XPointer complet ne pourra pas être traité, c'est que le document résultant du décryptage de l'élément xenc:EncryptedData externe aura la forme suivante ([b01-b05]) :

  [b01] <dummy>
  [b02]   <Secrets>
  [b03]     <xenc:EncryptedData Id="#secret-1" .../>
  [b04]   </Secrets>
  [b05] </dummy>

3.4.6 Les interactions avec les autres filtres

Le modèle de traitement des références des signatures XML autorise les transformations à retirer des parties d'un ensemble de nœuds subissant une transformation. On RECOMMANDE que toutes ces transformations interviennent avant la transformation de décryptage. Sinon, les données cryptées qui surviennent dans les parties du document qui doivent être retirées et ne peuvent pas être traitées par le destinataire provoqueront l'échec de la transformation de décryptage.

Par exemple, prenons le document suivant, lequel contient des parties devant être signées en récépissé par diverses personnes. La transformation XPath ancestor-or-self::*[@For="job"] ne sélectionne que le sous-ensemble [02-04]. Si cette transformation XPath intervient après la transformation de décryptage et qu'une autre partie du document contient des données cryptées (par exemple, [07]), que celles-ci soient créées avant ou après la signature, alors la transformation de décryptage peut échouer à les décrypter et le traitement échouera. Si la transformation XPath intervient en premier, alors les données cryptées ne seront pas prises en compte par la transformation de décryptage.

  [01] <Document>
  [02]   <ToBeSigned For="job">
  [03]     ...
  [04]   </ToBeSigned>
  [05]   <ToBeSigned For="bob">
  [06]     ...
  [07]     <xenc:EncryptedData .../>
  [08]   </ToBeSigned>
  [09] </Document>

3.4.7 L'élément EncryptedKey est hors d'atteinte

Cette transformation n'inclut aucun élément xenc:EncryptedKey dans sa portée, indiquant spécifiquement les éléments et leurs exceptions qui devraient être décryptés. Un élément xenc:EncryptedKey, existant comme descendant d'un élément xenc:EncryptedData, pourrait être décrypté et être retiré du document original du fait du traitement de son ancêtre xenc:EncryptedData par la transformation. Cependant, un élément xenc:EncryptedKey solitaire sera traité comme n'importe quelles autres données. Par conséquent, nous RECOMMANDONS que les éléments xenc:EncryptedKey soient toujours les sous-éléments de l'élément ds:KeyInfo d'un élément xenc:EncryptedData, quand ils tombent dans la portée d'une signature.

4 La transformation de décryptage en mode binaire

Identificateur :

http://www.w3.org/2002/07/decrypt#Binary

Ce mode de la transformation requiert un ensemble de nœuds XPath [XPath] en entrée. Si on fournit un flux d'octets en entrée, il DOIT être converti en un ensemble de nœuds, comme décrit dans Le modèle de traitement des références (section 4.3.3.2) de la spécification des signatures XML [XML-Signature]. La transformation décrypte tous les éléments xenc:EncryptedData, sauf ce qui est spécifé par les éléments dcrpt:Except. La sortie de la transformation est un flux d'octets.

4.1 Les règles de traitement

Le mode opératoire binaire est destiné à être utilisé quand on génère une signature sur des données binaires qui doivent être chiffrées avant transmission au destinataire. L'utilisation de ce mode de la transformation permet le calcul d'une signature sur la forme brute des données, plutôt que sur le texte crypté obscur. Ceci permet ensuite le stockage du texte crypté ailleurs, identifié par une référence de chiffrement, sans que la signature ne doive en tenir compte.

Cette section décrit les règles de traitement du mode binaire de cette transformation. Les entrées et sorties de la transformation sont celles de la fonction decryptBinary().

O = decryptBinary(N, E)

où N représente un ensemble de nœuds et E l'ensemble des adresses URI d'exceptions que portent les attributs URI des éléments dcrpt:Except. O est un flux d'octets calculé de la manière suivante :

1. Soit D un ensemble de nœuds contenant tous les nœuds des éléments dans N qui ont le type xenc:EncryptedData et qui ne sont pas identifiés par l'adresse URI d'une quelconque exception dans E.
   • Lors de la résolution de l'adresse URI d'une exception, l'implémentation DOIT se comporter comme si le nœud document de l'ensemble de nœuds en entrée était utilisé pour initialiser le contexte d'évaluation XPointer [XPointer], même si le nœud ne fait pas partie de l'ensemble de nœuds. Au contraire d'une signature XML [XML-Signature], l'adresse URI de l'exception peut être évalué par rapport à un document différent à partir du document de signature. Si l'entrée est un document différent, alors, selon XPointer [XPointer], l'utilisation de la fonction here() est une erreur ;
   • Si l'adresse URI d'une exception échoue à résoudre un quelconque nœud, alors l'erreur résultante DOIT être ignorée ; cela peut provenir de certaines parties du document en entrée qui sont cryptées ;
2. Pour chaque élément xenc:EncryptedData d issu de D, décrypter d, sans tenir compte, le cas échéant, desquels descendants se trouvent dans N et sans considération de son attribut Type, ce qui résulte dans un flux d'octets O_d ;
3. Soit O, la sortie de cette transformation, qui représente la concaténation des flux d'octets O_d, ordonnés selon l'ordre du document de d ;
4. S'il n'y a aucun élément EncryptedData dans D, alors le résultat est un flux d'octets de longueur nulle.

4.2 Exemple

Prenons, par exemple, le document signé suivant :

  <Document>
    <xenc:EncryptedData Id="image" MimeType="image/png" ...>
      ...
      <!-- données d'une image -->
      ...
    </xenc:EncryptedData>
    <dsig:Signature ...>
      ...
      <dsig:Reference URI="#image">
        <dsig:Transforms>
          <dsig:Transform Algorithm="http://www.w3.org/2002/07/decrypt#Binary" />
        </dsig:Transforms>
        ...
      </dsig:Reference>
      ...
    </dsig:Signature>
  </Document>

Une grande partie des données cryptées et de la signature est élidée ; ce qui est impliqué dans le commentaire dans les données cryptées, c'est que le contenu crypté est une image binaire.

L'exécution de la transformation de décryptage se déroulera comme suit :

• L'entrée de la transformation, notée N, est un ensemble de nœuds contenant l'élément EncryptedData et ses sous-éléments, moins les commentaires. Le paramètre de la transformation, noté E, est vide ;
• En résultat, D est un nœud consistant en l'élément EncryptedData, d_image. Ceci est décrypté et résulte en une chaîne d'octets O_image contenant le texte en clair de l'image binaire ;
• Il n'y a pas d'autre donnée à décrypter, de sorte que le résultat de cette transformation est le texte en clair obtenu lors de l'étape précédente. Celui-ci sera utilisé directement comme entrée pour l'algorithme de hachage cryptographique.

5 Considérations sur la sécurité

5.1 Les signatures opérant sur des données cryptées peuvent révéler des informations

Quand on utilise cet algorithme pour faciliter le chiffrement consécutif de données déjà signées, l'empreinte numérique [NdT. digest value] de la ressource signée apparaît toujours en clair dans un élément ds:Reference. Ainsi que l'a remarqué Hal Finney [Finney], une telle signature peut révéler des informations (via l'empreinte numérique) sur des données cryptées, ce qui accroît la vulnérabilité du chiffrement aux attaques par prédiction du texte en clair. Cette question n'est pas traitée par ce document et, le cas échéant, c'est aux applications d'y répondre. Par exemple, comme proposé par Amir Herzberg [Herzberg], on peut introduire un sel [N.d.T. salt] aléatoire dans la ressource à signer pour accroître son entropie.

Une autre approche lorsque l'appelant de la signature est crypté : on peut aussi chiffrer la signature (ou au moins les éléments ds:DigestValue). Comme remarqué par Joseph Reagle [Reagle], cette dernière solution ne fonctionne que si la signature et le chiffrement sont connus par l'une et l'autre parties. Par exemple, la signature peut ne pas être connue parce que détachée. Ou bien, elle peut être déjà cryptée ! Considérons ceci : Alice chiffre l'élément A et la signature opérant sur le parent de A. Bob chiffre l'élément B (frère de A), mais pas la signature puisqu'il n'en a pas connaissance. Alice décrypte ensuite A et sa signature, ce qui peut ouvrir une faille aux attaques consécutives par prédiction du texte en clair de l'élément B crypté.

5.2 Signez ce que vous voyez

Cette spécification sert les scénarios dans lesquels une personne pourrait signer des données cryptées. Puisqu'une signature XML [XML-Signature] ne possède qu'une sémantique simple au travers de laquelle une clé est associée à certaines données — et rien de plus — la signature de données cryptée est un processus légitime. Par exemple, quelqu'un pourrait conduire un service d'estampillage indépendant du contenu, qui signera toutes les données qui lui sont envoyées avec sa clé d'estampillage et la phrase J'ai reçu ceci le $date à $heure.. Cependant, les applications associent souvent, explicitement ou implicitement, une sémantique plus complète (par exemple, autorise, agrée, édite) à une signature. On ne devrait demander à personne d'appliquer une signature et la sémantique qui y est associée à des données que celle-ci n'a pas vues. Tout comme les principes dans Seul ce qui est “vu” devrait être signé et “Voir” ce qui est signé sont important pour comprendre l'apport d'une signature XML, ils sont doublement importants quand une sémantique est associée à cette signature : on NE DOIT PAS inférer qu'une signature sur des données cryptées est aussi une signature sur sa forme en texte clair, ni que la signification de cette signature sur les données cryptées s'applique aussi au texte en clair. Si on souhaite signer la forme en texte clair des données, cryptées après, utiliser la transformation spécifiée dans ce document !

6 Références

Finney

Re: Combiner signature et chiffrement. H. Finney. Liste de diffusion XML Encryption, 2000.

http://lists.w3.org/Archives/Public/xml-encryption/2000Nov/0064

Herzberg

Signer des données cryptées. A. Herzberg. Liste de diffusion XML Encryption, 2001.

http://lists.w3.org/Archives/Public/xml-encryption/2001Mar/0025

Keywords

RFC 2119 : Les mots-clés à utiliser dans les RFC pour indiquer les niveaux d'exigence. S. Bradner. Best Current Practices, 1997.

http://www.ietf.org/rfc/rfc2119.txt

Reagle

Re: Signature et chiffrement. J. Reagle. Liste de diffusion XML Encryption, 2001.

http://lists.w3.org/Archives/Public/xml-encryption/2001Jan/0100

Solo

Combiner signature et chiffrement. D. Solo. Liste de diffusion XML Encryption, 2000.

http://lists.w3.org/Archives/Public/xml-encryption/2000Nov/0058

URI

RFC 2396 : Les identificateurs de ressource uniformes (URI) : syntaxe générique. T. Berners-Lee, R. Fielding et L. Masinter. Standards Track, 1998.

http://www.ietf.org/rfc/rfc2396.txt

XML

Le langage de balisage extensible (XML) 1.0 (Deuxième édition). T. Bray, J. Paoli, C.M. Sperberg-McQueen et E. Maler. W3C Recommendation, 2000.

http://www.w3.org/TR/2000/REC-xml-20001006

XML-C14N

XML canonique, version 1.0. J. Boyer. Recommandation du W3C, 2001.

http://www.w3.org/TR/2001/REC-xml-c14n-20010315

XML-exc-C14N

Canonisation XML exclusive. J. Boyer, D. Eastlake et J. Reagle. Recommandation du W3C, 2002.

http://www.w3.org/TR/2002/REC-xml-exc-c14n-20020718/

XML-Encryption

La syntaxe et le traitement XML Encryption. D. Eastlake et J. Reagle. Recommandation du W3C, 2002.

http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/

XML-Schema

Le schéma XML, 1ere partie : Les structures. H. Thompson, D. Beech, M. Maloney, and N. Mendelsohn. Recommandation du W3C, 2001.

http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/

Le schéma XML, 2eme partie : Les types de données. P. Biron et A. Malhotra. Recommandation du W3C, 2001.

http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/

XML-Signature

La syntaxe et le traitement de la signature XML. D. Eastlake, J. Reagle et D. Solo. Recommandation du W3C, 2002.

http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/

XPath

Le langage de chemin XML (XPath), version 1.0. J. Clark et S. DeRose. Recommandation du W3C, 1999.

http://www.w3.org/TR/1999/REC-xpath-19991116

XPointer

Le langage de pointeur XML (XPointer). S. DeRose, R. Daniel et E. Maler. Recommandation candidate du W3C, 2001.

http://www.w3.org/TR/2001/CR-xptr-20010911/