Résumé

Ce document spécifie les règles de traitement et la syntaxe des signatures digitales XML. Les signatures XML fournissent des services d'intégrité, d'authentification du message et/ou d'authentification du signataire pour tous types de données, que celles-ci se trouvent dans le code XML qui contient la signature ou bien ailleurs.

Statut de ce document

Table des matières

1. Introduction
   1. Les conventions éditoriales
   2. La démarche conceptuelle
   3. Les versions, les espaces de nommage et les identifiants
   4. Remerciements
2. Présentation de la signature et exemples
   1. Un exemple simple (Signature, SignedInfo, Method et Reference)
      1. Compléments sur l'élément Reference
   2. Un exemple approfondi (Object et SignatureProperty)
   3. Un exemple approfondi (Object et Manifest)
3. Les règles de traitement
   1. La génération de la signature
   2. La validation de la signature
4. La syntaxe de la structure principale de la signature [N.d.T. Core Signature Syntax]
   1. L' élément Signature
   2. L'élément SignatureValue
   3. L'élément SignedInfo
      1. L'élément CanonicalizationMethod
      2. L'élément SignatureMethod
      3. L'élément Reference
         1. L'attribut URI
         2. Le modèle de traitement des références
         3. Les références d'URI dans un même document
         4. L'élément Transforms
         5. L'élément DigestMethod
         6. L'élément DigestValue
   4. L'élément KeyInfo
      1. L'élément KeyName
      2. L'élément KeyValue
         1. L'élément DSAKeyValue
         2. L'élément RSAKeyValue
      3. L'élément RetrievalMethod
      4. L'élément X509Data
      5. L'élément PGPData
      6. L'élément SPKIData
      7. L'élément MgmtData
   5. L'élément Object
5. Une syntaxe supplémentaire d'une signature
   1. L'élément Manifest
   2. L'élément SignatureProperties
   3. Les instructions de traitement
   4. Les commentaires dans les éléments Signature
6. Les algorithmes
   1. Les identifiants d'algorithme et les exigences d'implémentation
   2. Les condensés des messages [N.d.T. message digests]
   3. Les codes d'authentification de message
   4. Les algorithmes de signature
   5. Les algorithmes de canonisation
   6. Les algorithmes de transformation
      1. La canonisation
      2. La transformation Base64
      3. Le filtrage XPath
      4. La transformation de signature enveloppée
      5. La transformation XSLT
7. Considérations sur la canonisation XML et sur les contraintes syntaxiques
   1. XML 1.0, les contraintes syntaxiques et la canonisation
   2. Les traitements DOM/SAX et la canonisation
   3. Le contexte de l'espace de nommage et les signatures portables
8. Considérations sur la sécurité
   1. Les transformations
      1. Seul ce qui est signé est sûr
      2. Seul ce qui est « visible » devrait être signé
      3. « Voir » ce qui est signé
   2. La vérification du modèle de sécurité
   3. Les algorithmes, les longueurs de clés, etc.
9. Schéma, DTD, modèle de données et exemples valides
10. Définitions
11. Références
12. Les adresses des auteurs

1.0 Introduction

Ce document spécifie la syntaxe XML et les règles de traitement pour créer et représenter des signatures digitales. Les signatures XML peuvent s'appliquer séur n'importe quel contenu digital objet de données, y compris un code XML. Une signature XML peut s'appliquer sur le contenu d'une ou plusieurs ressources. Les signatures enveloppées ou enveloppantes opèrent sur des données dans le même document XML que la signature ; les signatures detachées opèrent sur des données en dehors de l'élément signature. Plus précisément, cette spécification définit un type d'élément de signature XML et une application de signature XML ; les critères de conformité pour chacun d'eux sont spécifiés respectivement par le biais de définitions de schéma et d'explications écrites. Cette spécification comprend également d'autres types utiles qui identifient des méthodes pour référencer collections de ressources, d'algorithmes et d'instructions pour la gestion des clés.

La signature XML est une méthode qui consiste à associer une clé avec des données référencées (octets) ; elle ne spécifie de manière normative ni de quelle façon les clés sont associées aux personnes ou aux institutions, ni la teneur des données référencées ou signées. Par conséquent, bien que cette spécification soit une composante importante des applications XML sécurisées, elle ne suffit pas à répondre seule aux questions de sécurité/confiance des applications, plus particulièrement en ce qui concerne l'utilisation de XML signé (ou d'autres formats de données) comme plate-forme d'échange et d'accord entre les personnes. Une telle application doit spécifier une clé, un algorithme, des conditions de traitement et de rendu supplémentaires. Pour de plus amples informations, merci consulter les « Considérations sur la sécurité » (section 8).

1.1 Les conventions éditoriales

Par souci de lisibilité, de brièveté et pour des raisons historiques, ce document emploie le terme « signature » pour se référer en général à des valeurs d'authentification digitale de tous types. Évidemment, le terme est également utilisé strictement en référence aux valeurs d'authentification qui sont basées sur des clés publiques et qui fournissent l'authentification du signataire. Lorsque l'on parle spécifiquement de valeurs d'authentification basées sur des codes de clés secrètes symétriques, nous utilisons les termes d'authentificateurs ou codes d'authentification. (Voir « La vérification du modèle de sécurité », section 8.2.)

Cette spécification fournit un schéma XML [XML-schema] et une DTD [XML]. La définition du schéma est normative.

Les mots-clés « DOIT », « NE DOIT PAS », « REQUIS », « DEVRA », « NE DEVRA PAS », « DEVRAIT », « NE DEVRAIT PAS », « RECOMMANDÉ », « PEUT » et « OPTIONNEL » doivent être interprétés dans cette spécification comme décrits dans RFC2119 [KEYWORDS] :

"Ils ne DOIVENT seulement être utilisés qu'aux endroits où ils sont vraiment nécessaires pour une interopération ou pour limiter un comportement potentiellement néfaste (par exemple, la limitation des retransmissions)"

Par conséquent, nous utilisons ces mots-clés en lettres majuscules pour clairement spécifier les exigences sur les fonctions des protocoles et des applications, ainsi que sur le comportement concernant l'interopérabilité et la sécurité des implémentations. Ces mots-clés ne sont pas utilisés (en lettres majuscules) pour décrire la grammaire XML ; les définitions du schéma décrivent clairement de telles conditions et nous souhaitons réserver l'utilisation de ces termes pour les descriptions en langage naturel des protocoles et des fonctionnalités. Par exemple, un attribut XML peut être décrit comme étant « optionnel ». La conformité avec des espaces de nommage dans XML [XML-ns] est définie comme « REQUISE ».

1.2 La démarche conceptuelle

La démarche conceptuelle et les exigences pour cette spécification sont traitées dans le document « Les exigences pour XML Signature » [XML-Signature-RD].

1.3 Les versions, les espaces de nommage et les identifiants

Aucune réserve n'est faite pour un numéro explicite de version dans cette syntaxe. Si une version future est nécessaire, elle utilisera un espace de nommage différent. L'URI de l'espace de nommage XML [XML-ns] qui DOIT être utilisé par les implémentations de cette spécification (datée) est :

   xmlns="http://www.w3.org/2000/09/xmldsig#"

Cet espace de nommage est également utilisé comme préfixe pour les identifiants d'algorithme utilisés par cette spécification. Bien que les applications DOIVENT gérer XML et les espaces de nommage XML, l'utilisation d'entités internes [XML] ou de nos préfixe d'espace de nommage XML "dsig" et conventions pour les défauts ou la portée sont OPTIONNELS ; nous utilisons ces ressources pour fournir des exemples compacts et lisibles.

Cette spécification utilise des identifiants de ressource uniformes [URI] pour identifier les ressources, les algorithmes et la sémantique. L'URI dans la déclaration d'espace de nommage ci-dessus est aussi utilisée comme préfixe pour les URI sous le contrôle de cette spécification. Pour les ressources qui ne sont pas sous le contrôle de cette spécification, nous utilisons les noms de ressource uniformes désignés [URN] ou les localisateurs de ressource uniformes [URL] définis par leur spécification externe normative. Si une spécification externe ne s'est pas attribuée elle-même un identifiant de ressource uniforme, nous allouons un identifiant sous notre propre espace de nommage. Par exemple :

L'élément SignatureProperties est identifié et défini par l'espace de nommage de cette spécification

http://www.w3.org/2000/09/xmldsig#SignatureProperties

La recommandation XSLT est identifiée et définie par un URI externe

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

L'algorithme SHA1 est identifié via l'espace de nommage de cette spécification et via une référence normative

http://www.w3.org/2000/09/xmldsig#sha1

FIPS PUB 180-1. Le standard de hachage sécurisé. Département du Commerce des Etats-Unis/Institut National des standards et des technologies.

Enfin, pour des déclarations d'espaces de nommage concises, nous utilisons de temps en temps des entités XML internes [XML] à l'intérieur des URI. Par exemple :

   <?xml version='1.0'?>
   <!DOCTYPE Signature SYSTEM 
     "xmldsig-core-schema.dtd" [ <!ENTITY dsig
     "http://www.w3.org/2000/09/xmldsig#"> ]>
   <Signature xmlns="&dsig;" Id="MaPremiereSignature">
     <SignedInfo>
     ...

1.4 Remerciements

Les contributions des membres suivants du groupe de travail pour cette spécification sont remerciées avec reconnaissance :

• Mark Bartel, Accelio (auteur)
• John Boyer, PureEdge (auteur)
• Mariano P. Consens, Université de Waterloo
• John Cowan, Reuters Health
• Donald Eastlake 3rd, Motorola  (Président, auteur/éditeur)
• Barb Fox, Microsoft (auteur)
• Christian Geuer-Pollmann, Université Siegen
• Tom Gindin, IBM
• Phillip Hallam-Baker, VeriSign Inc
• Richard Himes, US Courts
• Merlin Hughes, Baltimore
• Gregor Karlinger, IAIK TU Graz
• Brian LaMacchia, Microsoft (auteur)
• Peter Lipp, IAIK TU Graz
• Joseph Reagle, W3C (Président, auteur/éditeur)
• Ed Simon, XMLsec (auteur)
• David Solo, Citigroup (auteur/éditeur)
• Petteri Stenius, Capslock
• Raghavan Srinivas, Sun
• Kent Tamura, IBM
• Winchel Todd Vincent III, GSU
• Carl Wallace, Corsec Security, Inc.
• Greg Whitehead, Signio Inc.

Tout comme les commentaires de dernière minute apportés par les personnes suivantes :

• Dan Connolly, W3C
• Paul Biron, Kaiser Permanente, au nom du GT XML Schema.
• Martin J. Duerst, W3C, et Masahiro Sekiguchi,Fujitsu, au nom du GT/GI pour l'internationalisation.
• Jonathan Marsh, Microsoft, au nom du GT pour le langage de feuilles de style extensibles.

2.0 Présentation de la signature et exemples

Cette section fournit une présentation et des exemples de la syntaxe de la signature digitale XML. Le traitement spécifique est donné dans « Les règles de traitement » (section 3). La syntaxe formelle se trouve dans « La syntaxe de la structure principale de la signature » (section 4) et « La syntaxe supplémentaire d'une signature » (section 5).

Dans cette section, une représentation informelle et des exemples sont utilisés pour décrire la syntaxe de la signature digitale XML. Cette représentation et ces exemples peuvent omettre des attributs, des détails et des caractéristiques potentielles qui seront pleinement exposés plus tard.

Les signatures XML s'appliquent sur un contenu digital arbitraire (objets de données) via une indirection. Les objets de données sont prétraités, la valeur qui en résulte est placée dans un élément (avec d'autres informations), puis cet élément est prétraité et signé cryptographiquement. Les signatures digitales XML sont représentées par l'élément Signature qui a la structure suivante (où le caractère « ? » dénote zéro ou une occurence, « + » une ou plusieurs occurences et « * » zéro ou plusieurs occurences) :

  <Signature ID?> 
     <SignedInfo>
       <CanonicalizationMethod/>
       <SignatureMethod/>
       (<Reference URI? >
         (<Transforms>)?
         <DigestMethod>
         <DigestValue>
       </Reference>)+
     </SignedInfo>
     <SignatureValue> 
    (<KeyInfo>)?
    (<Object ID?>)*
   </Signature>

Les signatures sont reliées aux objets de données via des URI [URI]. Dans un document, les signatures se rapportent aux objets de données locaux via des identifiants de fragment. De telles données locales peuvent être incluses dans une signature enveloppante ou peuvent renfermer une signature enveloppée. Les signatures détachées opèrent sur des ressources réseaux externes ou des objets de données locaux qui résident dans le même document XML en tant qu'éléments voisins ; dans ce cas, la signature n'est ni enveloppante (la signature est parente) ni enveloppée (la signature est enfant). Étant donné que l'élément Signature (et son attribut Id valeur/nom) peut co-exister ou être combiné avec d'autres éléments (et leurs ID) dans un seul document XML, il faut faire attention, lorsque l'on choisit les noms, à ce qu'il n'y ait pas de collisions subséquentes qui violent la contrainte de validité de l'unicité de l'ID [XML].

2.1 Un exemple simple (Signature, SignedInfo, Méthodes et Références)

L'exemple suivant est une signature détachée d'un contenu HTML4 dans une spécification XML.

   [s01] <Signature Id="MyFirstSignature"
 xmlns="http://www.w3.org/2000/09/xmldsig#"> 
   [s02]   <SignedInfo> 
   [s03]   <CanonicalizationMethod
 Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/> 
   [s04]   <SignatureMethod
 Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"/> 
   [s05]   <Reference
 URI="http://www.w3.org/TR/2000/REC-xhtml1-20000126/"> 
   [s06]     <Transforms> 
   [s07]       <Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/> 
   [s08]     </Transforms> 
   [s09]     <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> 
   [s10]     <DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</DigestValue> 
   [s11]   </Reference> 
   [s12] </SignedInfo> 
   [s13]   <SignatureValue>MC0CFFrVLtRlk=...</SignatureValue> 
   [s14]   <KeyInfo> 
   [s15a]    <KeyValue>
   [s15b]      <DSAKeyValue> 
   [s15c]        <P>...</P><Q>...</Q><G>...</G><Y>...</Y> 
   [s15d]      </DSAKeyValue> 
   [s15e]    </KeyValue> 
   [s16]   </KeyInfo> 
   [s17] </Signature>

[s02-12] L'élément requis SignedInfo est véritablement l'information qui sera signée. La validation principale de SignedInfo est consistuée de deux traitements obligatoires : la validation de la signature sur l'élément SignedInfo et la validation du prétraitement de chaque élément Reference dans l'élément SignedInfo. À noter que les algorithmes utilisés pour le calcul de l'élément SignatureValue sont aussi inclus dans les informations signées alors que l'élément SignatureValue se trouve en dehors de l'élément SignedInfo.

[s03] L'élément CanonicalizationMethod donne l'algorithme qui est utilisé pour canoniser l'élément SignedInfo avant qu'il ne soit prétraité en tant que partie de l'opération de signature. À noter que cet exemple, et tous les exemples dans cette spécification, ne sont pas dans une forme canonique.

[s04] L'élément SignatureMethod donne l'algorithme qui est utilisé pour convertir l'élément SignedInfo canonisé en un élément SignatureValue. C'est la combinaison d'un algorithme de prétraitement et d'un algorithme dépendant d'une clé, et éventuellement d'autres algorithmes comme un algorithme de remplissage, par exemple RSA-SHA1. Les noms d'algorithme des algorithmes sont signés pour lutter contre les attaques basées sur la substitution par un algorithme plus faible. Pour promouvoir l'interopérabilité des applications, nous spécifions un ensemble d'algorithmes de signature qui DOIVENT être implémentés, bien que leur utilisation reste à la discrétion du créateur de la signature. Nous spécifions des algorithmes supplémentaires RECOMMANDÉS ou OPTIONNELS pour l'implémentation ; l'architecture permet également d'utiliser des algorithmes arbitraires spécifiés par l'utilisateur.

[s05-11] Chaque élément Reference inclut la méthode de prétraitement et la valeur de prétraitement resultante calculées à partir d'un objet de données. Cet élément peut également inclure les transformations qui ont produit l'entrée pour l'opération de prétraitement. Un objet de données est signé au travers d'un calcul sur sa valeur de prétraitement avec une signature sur celle-ci. La signature sera vérifiée plus tard via une référence et une validation de signature.

[s14-16] L'élément KeyInfo indique la clé qui doit être utilisée pour valider la signature. Les formes d'identification possibles comprennent des certificats, des noms de clé et des algorithmes et renseignements pour l'agrément des clés -- nous n'en définissons que quelques unes. L'élément KeyInfo est optionnel pour deux raisons. Premièrement, le signataire peut souhaiter ne pas révéler les informations de clé à toutes les parties engagées dans le traitement du document. Deuxièmement, l'information peut être connue dans le contexte de l'application et n'a pas besoin d'être représentée explicitement. Puisque l'élément KeyInfo se trouve en dehors de l'élément SignedInfo, quand le signataire souhaite relier les informations de clé avec la signature, un élément Reference peut facilement identifier et inclure l'élément KeyInfo comme partie de la signature.

2.1.1 Compléments sur l'élément Reference

   [s05]   <Reference URI="http://www.w3.org/TR/2000/REC-xhtml1-20000126/"> 
   [s06]     <Transforms> 
   [s07]       <Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/> 
   [s08]     </Transforms> 
   [s09]     <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> 
   [s10]     <DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</DigestValue> 
   [s11]   </Reference>

[s05] L'attribut optionnel URI de l'élément Reference identifie l'objet de données qui doit être signé. Cet attribut peut être omis sur au plus un élément Reference dans un élément Signature. (Cette limitation est imposée pour garantir que les références et les objets puissent correspondre sans ambiguïté.)

[s05-08] Cette identification, au fur et à mesure des transformations, est une description fournie par le signataire sur la façon dont les transformations ont obtenus l'objet de données signé dans sa forme prétraitée (c.-à-d., le contenu prétraité). Le vérificateur peut obtenir le contenu prétraité à partir d'une autre méthode, tant que le prétraitement est vérifié. En particulier, le vérificateur peut obtenir le contenu d'un emplacement différent, tel qu'un emplacement local, de celui spécifié dans l'URI.

[s06-08] L'élément Transforms est une liste optionnelle ordonnée, composée d'étapes de traitement qui étaient appliqués sur le contenu de la ressource avant qu'elle ne soit prétraitée. Les transformations peuvent comprendre des opérations telles que canonisation, encodage/décodage (incluant la compression/décompression), XSLT, XPath, schémas de validation XML ou XInclude. Les transformations XPath permettent au signataire de produire un document XML qui omet des portions du document source. Par conséquent, ces portions exclues peuvent changer sans affecter la validité de la signature. Par exemple, si la ressource en train d'être signée contient la signature en question, une telle transformation doit être utilisée pour exclure la valeur de signature de son propre calcul. Si aucun élément Transforms n'est présent, le contenu de la ressource est prétraité directement. Bien que le groupe de travail ait spécifié des algorithmes de canonisation et de codage obligatoires (et optionnels), des transformations spécifiées par l'utilisateur peuvent être utilisées.

[s09-10] L'élément DigestMethod spécifie l'algorithme qui sera appliqué sur les données après l'application de l'élément Transforms (si spécifié) pour produire l'élément DigestValue. C'est la signature de l'élément DigestValue qui relie le contenu de la ressource à la clé du signataire.

2.2 Un exemple approfondi (Object et SignatureProperty)

Cette spécification ne décrit pas les mécanismes pour faire des déclarations ou des affirmations. Par contre, ce document définit ce que signifie pour un objet d'être signé avec une signature XML (l'integrité, l'authentification du message et/ou l'authentification du signataire). Les applications qui veulent représenter d'autres sémantiques doivent compter sur d'autres technologies, telles que [XML, RDF]. Par exemple, une application pourrait utiliser un attribut foo:assuredby dans son propre balisage pour référencer un élément Signature. Par conséquent, c'est l'application qui doit comprendre et savoir comment faire pour prendre des décisions de confiance en fonction de la validité de la signature et du sens de la syntaxe de assuredby. Nous définissons également le type d'élément SignatureProperties afin d'inclure des assertions à propos de la signature elle-même (par exemple, la sémantique de la signature, la date de la signature ou le numéro de série du matériel utilisé dans les traitements cryptographiques). On peut signer de telles assertions en incluant un élément Reference pour l'élément SignatureProperties dans SignedInfo. Alors qu'une application de signature doit faire très attention à ce qu'elle signe (elle doit comprendre ce qui se trouve dans l'élément SignatureProperty), une application réceptrice n'a aucune obligation de comprendre cette sémantique (bien que son moteur de confiance parent puisse le souhaiter). Tous les contenus concernant la génération d'une signature peuvent se trouver dans un élément SignatureProperty. L'attribut obligatoire Target référence l'élément Signature auquel la propriété s'applique.

Considérons l'exemple précédent avec une référence supplémentaire vers un élément Object local comprenant un élément SignatureProperty. (Une telle signature ne serait pas seulement détachée [p02] mais également enveloppante [p03].)

   [   ]  <Signature Id="MySecondSignature" ...>
   [p01]  <SignedInfo>  
   [   ]   ...  
   [p02]   <Reference URI="http://www.w3.org/TR/xml-stylesheet/">   
   [   ]   ... 
   [p03]   <Reference URI="#AMadeUpTimeStamp"  
   [p04]         Type="http://www.w3.org/2000/09/xmldsig#SignatureProperties">  
   [p05]    <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>    
   [p06]    <DigestValue>k3453rvEPO0vKtMup4NbeVu8nk=</DigestValue>
   [p07]   </Reference>    
   [p08]  </SignedInfo>  
   [p09]  ...  
   [p10]  <Object> 
   [p11]   <SignatureProperties> 
   [p12]     <SignatureProperty Id="AMadeUpTimeStamp" Target="#MySecondSignature"> 
   [p13]        <timestamp xmlns="http://www.ietf.org/rfcXXXX.txt">  
   [p14]          <date>19990908</date>  
   [p15]          <time>14:34:34:34</time>  
   [p16]        </timestamp>  
   [p17]     </SignatureProperty> 
   [p18]   </SignatureProperties> 
   [p19]  </Object>  
   [p20]</Signature>

[p04] L'attribut optionnel Type de l'élément Reference fournit des informations à propos de la ressource identifiée par l'URI. En particulier, il peut indiquer si c'est un élément Object, SignatureProperty ou Manifest. Ceci peut être utilisé par des applications pour lancer un traitement spécial sur certains éléments Reference. Les références vers un élément de données XML, dans un élément Object, DEVRAIENT identifier le véritable élément désigné. Lorsque le contenu d'un élément n'est pas du type XML (il peut s'agir de données codées ou binaires), la référence devrait identifier l'élément Object et l'attribut Type de l'élément Reference, s'il est donné, DEVRAIT désigner l'élément Object. À noter que l'attribut Type est utilisé à titre consultatif, le corps du fonctionnement ne demande aucune action qui s'appuie sur celui-ci ni de vérification de son exactitude.

[p10] L'élément Object est un élément optionnel qui permet d'inclure des objets de données dans un élément de signature ou ailleurs. L'élément Object peut être facultativement typé et/ou codé.

[p11-18] Les propriétés de la signature, telle que la date de la signature, peuvent être facultativement signées en les identifiant à partir d'un élément Reference. (Ces propriétés sont traditionnellement appelées des « attributs » de signature, bien que ce terme n'ait aucune relation avec le terme « attributs » en XML.)

2.3 Un exemple approfondi (Object et Manifest)

L'élément Manifest est fourni pour adjoindre des conditions supplémentaires auxquelles les parties obligatoires de la spécification n'apportent pas de réponses directes. Nous allons voir deux conditions et la façon dont l'élément Manifest les satisfait.

Premièrement, les applications ont fréquemment besoin de signer efficacement de multiples objets de données, même lorsque l'opération de signature en question fait appel à une signature à clé publique coûteuse Cette condition peut être réalisée en incluant plusieurs éléments Reference dans SignedInfo étant donné que l'incorporation de chacun des prétraitements sécurise les données prétraitées. Cependant, certaines applications peuvent refuser d'associer le comportement de validation principale à cette approche parce que cela nécessite que chaque élément Reference dans SignedInfo soit soumis à une validation de référence -- que les éléments DigestValue soient vérifiés. Ces applications peuvent vouloir se réserver la logique de décision de la validation des références. Par exemple, une application pourrait recevoir un élément SignedInfo avec une signature valide qui inclut trois éléments Reference. Si un seul élément Reference échoue à la validation (l'objet de données identifié lors du prétraitement ne produit pas le DigestValue spécifié), la signature échouerait dans la validation principale. Cependant, l'application peut vouloir considérer la signature avec deux éléments Reference valides comme étant valide, ou entreprendre différentes actions en fonction de celle qui échoue. Pour réaliser cela, l'élément SignedInfo référencerait un élément Manifest qui contient un ou plusieurs éléments Reference (ayant la même structure que ceux se trouvant dans l'élément SignedInfo). Ensuite, la validation de référence de l'élément Manifest passe sous le contrôle de l'application.

Deuxièmement, on considère une application où beaucoup de signatures (utilisant différentes clés) sont appliquées sur un grand nombre de documents. Une solution inefficace serait d'avoir une signature séparée (pour chaque clé) qui est appliquée à plusieurs reprises sur un grand élément SignedInfo (avec de nombreux éléments Reference) ; c'est un traitement dispendieux et redondant. Une solution plus efficace serait d'inclure plusieurs références dans un seul élément Manifest qui serait ensuite appelé à partir de plusieurs éléments Signature.

L'exemple ci-dessous inclut un élément Reference qui signe un élément Manifest se trouvant dans un élément Object.

   [   ] ...
   [m01]   <Reference URI="#MyFirstManifest"
   [m02]     Type="http://www.w3.org/2000/09/xmldsig#Manifest">
   [m03]     <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> 
   [m04]     <DigestValue>345x3rvEPO0vKtMup4NbeVu8nk=</DigestValue> 
   [m05]   </Reference>  
   [   ] ...
   [m06] <Object>
   [m07]   <Manifest Id="MyFirstManifest">
   [m08]     <Reference>
   [m09]     ...
   [m10]     </Reference>   
   [m11]     <Reference>
   [m12]     ...
   [m13]     </Reference>
   [m14]   </Manifest>
   [m15] </Object>

3.0 Les règles de traitement

Les sections ci-dessous décrivent les opérations qu'il faut effectuer comme faisant partie de la génération et de la validation d'une signature.

3.1 La génération principale

Ces étapes REQUISES incluent la génération des éléments Reference et de l'élément SignatureValue sur l'élément SignedInfo.

3.1.1 La génération d'une référence

Pour chaque objet de données en cours de signature :

1. Appliquer l'élément Transforms, comme déterminé par l'application, sur l'objet de données ;
2. Calculer la valeur prétraitée sur l'objet de données resultant.
3. Créer un élément Reference, incluant l'identification (optionnelle) de l'objet de données, tout élément (optionnel) de transformation, l'algorithme de prétraitement et l'élément DigestValue. (À noter que ce sont les formes canoniques de ces références qui sont signées en 3.1.2 et validées en 3.2.1 .)

3.1.2 La génération de la signature

1. Créer l'élément SignedInfo avec les éléments SignatureMethod, CanonicalizationMethod et Reference ;
2. Canoniser puis calculer l'élément SignatureValue sur l'élément SignedInfo, en fonction des algorithmes spécifiés dans SignedInfo ;
3. Construire l'élément Signature qui inclut les éléments SignedInfo, le ou les Object (si on le désire, le codage peut être différent de celui utilisé pour la signature), KeyInfo (si requis) et SignatureValue.

   À noter que si l'élément Signature inclut des références provenant d'un même document, la validation [XML] ou [XML-schema] du document peut introduire des changements qui faussent la signature. Par conséquent, les applications devraient faire attention de traiter le document de manière cohérente ou d'éviter l'utilisation de contributions externes (par exemple, les défauts et les entités).

3.2 La validation principale

Les étapes REQUISES de la validation principale incluent (1) la validation de référence, la vérification du condensé contenu dans chaque élément Reference de l'élément SignedInfo et (2) la validation de signature cryptographique de la signature calculée sur l'élément SignedInfo.

À noter qu'il peut y avoir des signatures valides que des applications de signature sont incapables de valider. Les raisons de cela comprennent l'échec dans l'implémentation de parties optionnelles de cette specification, l'incapacité et la réticence dans l'exécution des algorithmes spécifiques, ou l'incapacité et la réticence dans la résolution des URI spécifiés (certaines combinaisons d'URI peuvent causer des effets secondaires indésirables), etc.

La comparaison des valeurs dans les validations de référence et de signature se fait sur la séquence d'octets numérique (par exemple, un entier) ou décodée de la valeur. Des implémentations différentes peuvent produire diverses valeurs codées de condensé et de signature lors du traitement de la même ressource dûs à des variations dans leur codage, tel qu'un espace accidentel. Mais si on utilise une comparaison numérique ou une comparaison d'octet (choisir une méthode) sur les deux valeurs déclarées et calculées, alors ces problèmes disparaissent.

3.2.1 La validation de référence

1. Canoniser l'élément SignedInfo en fonction de l'élément CanonicalizationMethod dans SignedInfo ;
2. Pour chaque élément Reference dans SignedInfo :
   1. Obtenir les données à prétraiter. (Par exemple, l'application de signature peut résoudre l'URI et exécuter l'élément Transforms fourni par le signataire dans l'élément Reference, ou elle peut obtenir le contenu par d'autres moyens tel que dans un cache local.) ;
   2. Prétraiter l' objet de données resultant en utilisant l'élément DigestMethod spécifié dans son élément Reference ;
   3. Comparer la valeur condensée générée avec la valeur de DigestValue dans l'élément Reference de SignedInfo ; s'il y a une quelconque divergence, la validation échoue.

À noter que l'élément SignedInfo est canonisé lors de l'étape 1. L'application doit s'assurer que l'élément CanonicalizationMethod n'a pas d'effets secondaires indésirables, tels que la réécriture des URI, (voir CanonicalizationMethod (section 4.3)) et qu'elle voit ce qui est signé, ce qui est la forme canonique.

3.2.2 La validation de signature

1. Obtenir les informations de clé à partir de l'élément KeyInfo ou d'une source externe ;
2. Obtenir la forme canonique de l'élément SignatureMethod en utilisant l'élément CanonicalizationMethod, puis utiliser le résultat (et les informations de clé de l'élément KeyInfo précédemment obtenues) pour confirmer la valeur de l'élément SignatureValue sur l'élément SignedInfo.

À noter que l'élément KeyInfo (ou une certaine version transformée de celui-ci) peut être signé via un élément Reference. La transformation et la validation de cette référence (3.2.1) est orthogonale par rapport à la validation de l'élément Signature qui utilise l'élément KeyInfo lors de l'analyse.

De plus, l'attribut URI de l'élément SignatureMethod peut avoir été altéré par la canonisation de SignedInfo (par exemple, la transformation d'un URI relatif en URI absolu) et c'est la forme canonique qui DOIT être utilisée. Cependant, la canonisation requise [XML-C14N] de cette spécification ne change pas les URI.

4.0 La syntaxe de la structure principale de la signature

La structure générale d'une signature XML est décrite dans « Présentation de la signature et exemples » (section 2). Cette section fournit la syntaxe détaillée et les caractéristiques principales d'une signature. Les caractéristiques décrites dans cette section doivent être obligatoirement implémentées sauf indications contraires. La syntaxe est définie via des DTD et [XML-Schema] avec le préambule XML, la déclaration et l'entité interne suivants.

   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:ds CDATA #FIXED "http://www.w3.org/2000/09/xmldsig#">
      <!ENTITY dsig 'http://www.w3.org/2000/09/xmldsig#'> 
      <!ENTITY % p ''>
      <!ENTITY % s ''>
     ]>

   <schema xmlns="http://www.w3.org/2001/XMLSchema"
           xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
           targetNamespace="http://www.w3.org/2000/09/xmldsig#"
           version="0.1" elementFormDefault="qualified">

   DTD :

   <!--

   Les déclarations d'entité suivantes permettent un contenu externe/souple
   dans le modèle de contenu de Signature.

   #PCDATA émule schema:string ; combiné avec des types d'élément,
   cela émule schema mixed="true".

   %qqchose.ANY permet à l'utilisateur d'incorporer ses propres types d'élément
   issus d'autres espaces de nommage, par exemple :
     <!ENTITY % KeyValue.ANY '| ecds:ECDSAKeyValue'>
     ...
     <!ELEMENT ecds:ECDSAKeyValue (#PCDATA)  >

   -->

   <!ENTITY % Object.ANY ''>
   <!ENTITY % Method.ANY ''>
   <!ENTITY % Transform.ANY ''>
   <!ENTITY % SignatureProperty.ANY ''>
   <!ENTITY % KeyInfo.ANY ''>
   <!ENTITY % KeyValue.ANY ''>
   <!ENTITY % PGPData.ANY ''>
   <!ENTITY % X509Data.ANY ''>
   <!ENTITY % SPKIData.ANY ''>

4.0.1 Le type simple ds:CryptoBinary

Cette spécification définit le type simple ds:CryptoBinary pour représenter des entiers de longueur arbitraire (par exemple des « grands nombres » [N.d.T. bignum]) en XML comme des chaînes d'octets. La valeur entière est d'abord convertie en une chaîne de bits « gros-boutistes » [N.d.T. big endian]. La chaîne de bits est ensuite completée avec des bits forts de valeur zéro de façon à ce que le nombre total de bits == 0 mod 8 (il y aura donc un nombre entier d'octets). Si la chaîne de bits ne contient que des octets forts de valeur zéro, ils seront supprimés (pour que l'octet d'ordre supérieur soit toujours différent de zéro). Cette chaîne d'octets est ensuite codées en base64 [MIME]. (La conversion d'un entier en une chaîne d'octets est équivalente à IEEE 1363 I2OSP [1363] avec une longueur minimale).

Ce type est utilisé par des valeurs de « grand nombre » telles que RSAKeyValue et DSAKeyValue. Si une valeur peut être de type base64Binary ou ds:CryptoBinary, elles définie en base64Binary. Par exemple, si un algorithme de signature est de type RSA ou DSA, alors l'élément SignatureValue représente un grand nombre et peut être du type ds:CryptoBinary. Cependant, si l'algorithme de signature est HMAC-SHA1, alors l'élément SignatureValue peut avoir des octets forts de valeur zéro qui DOIVENT être préservés. Donc l'élément SignatureValue est généralement défini comme étant de type base64Binary.

   Définition du schéma :

   <simpleType name="CryptoBinary">
     <restriction base="base64Binary">
     </restriction>
   </simpleType>

4.1 L'élément Signature

L'élément Signature est l'élément racine d'une signature XML. Une implémentation DOIT générer des éléments Signature suivant un schéma valide relâché [XML-schema] comme spécifié dans le schéma ci-dessous:

   Définition de schéma :

   <element name="Signature" type="ds:SignatureType"/>
   <complexType name="SignatureType">
     <sequence> 
       <element ref="ds:SignedInfo"/> 
       <element ref="ds:SignatureValue"/> 
       <element ref="ds:KeyInfo" minOccurs="0"/> 
       <element ref="ds:Object" minOccurs="0" maxOccurs="unbounded"/> 
     </sequence>  
     <attribute name="Id" type="ID" use="optional"/>
   </complexType>

   DTD :

   <!ELEMENT Signature (SignedInfo, SignatureValue, KeyInfo?, Object*)  >
   <!ATTLIST Signature  
    xmlns   CDATA   #FIXED 'http://www.w3.org/2000/09/xmldsig#'
    Id      ID  #IMPLIED >

4.2 L'élément SignatureValue

L'élément SignatureValue contient la valeur réelle de la signature digitale ; il est toujours codé en utilisant l'algorithme base64 [MIME]. Bien que nous identifions deux algorithmes SignatureMethod, l'un obligatoire et l'autre optionnel, les algorithmes spécifiés par l'utilisateur peuvent être utilisés de la même façon.

   Définition de schéma :

   <element name="SignatureValue" type="ds:SignatureValueType"/> 
   <complexType name="SignatureValueType">
     <simpleContent>
       <extension base="base64Binary">
         <attribute name="Id" type="ID" use="optional"/>
       </extension>
     </simpleContent>
   </complexType>

   DTD :

   <!ELEMENT SignatureValue (#PCDATA) >
   <!ATTLIST SignatureValue  
             Id  ID      #IMPLIED>

4.3 L'élément SignedInfo

La structure de l'élément SignedInfo inclut l'algorithme de canonisation, un algorithme de signature, et une ou plusieurs références. L'élément SignedInfo peut contenir un attribut optionnel ID qui lui permet d'être référencé par d'autres signatures et objets.

L'élément SignedInfo n'inclut pas de signature ou de propriétés de prétraitement explicites (telque le temps de calcul, le numéro de série du périphérique cryptographique, etc.). Si une application a besoin d'associer des propriétés avec la signature ou le prétraitement, elle peut inclure de telles informations dans un élément SignatureProperties d'un élément Object.

   Définition de schéma :

   <element name="SignedInfo" type="ds:SignedInfoType"/> 
   <complexType name="SignedInfoType">
     <sequence> 
       <element ref="ds:CanonicalizationMethod"/>
       <element ref="ds:SignatureMethod"/> 
       <element ref="ds:Reference" maxOccurs="unbounded"/> 
     </sequence>  
     <attribute name="Id" type="ID" use="optional"/> 
   </complexType>

   DTD :

   <!ELEMENT SignedInfo (CanonicalizationMethod, 
    SignatureMethod,  Reference+)  >
   <!ATTLIST SignedInfo  
    Id   ID      #IMPLIED

4.3.1 L'élément CanonicalizationMethod

L'élément CanonicalizationMethod est un élément requis qui spécifie l'algorithme de canonisation appliqué à l'élément SignedInfo avant de réaliser les calculs de signature. Cet élément utilise la structure générale pour les algorithmes, décrite dans « Les identifiants d'algorithme et les exigences d'implémentation » (section 6.1). Les implémentations DOIVENT gérer les algorithmes de canonisation REQUIS.

Des alternatives aux algorithmes de canonisation REQUIS (section 6.5), tel que le XML canonique avec commentaires (section 6.5.1) ou une canonisation minimale (telle qu'une normalisation CRLF et jeu de caractères), peuvent être explicitement spécifiées mais ne sont PAS REQUISES. Par conséquent, leur utilisation peut ne pas être interopérable avec d'autres applications qui ne gèreraient pas l'algorithme spécifié (voir « Considérations sur la canonisation XML et sur les contraintes syntaxiques », section 7). Des problèmes de sécurité peuvent également apparaître durant le traitement de l'interprétation des entités et des commentaires si des algorithmes de canonisation non XML ne sont pas correctement contraints (voir section 8.2 : « Seul ce qui est « vu » doit être signé »).

La manière dont l'élément SignedInfo est présenté à la méthode de canonisation dépend de cette méthode. Les points suivants s'appliquent aux algorithmes qui traitent le XML comme des nœuds ou des caractères :

• Les implémentations de canonisation basées sur XML DOIVENT recevoir un ensemble de nœuds [XPath], formé au départ à partir du document contenant l'élément SignedInfo et indiquant effectivement l'élément SignedInfo, ses descendants et les nœuds d'attributs et d'espaces de nommage de l'élément SignedInfo et ses descendants.
• Les algorithmes de canonisation basés sur le texte (telle qu'une normalisation CRLF et jeu de caractères) devraient recevoir les octets UTF-8 qui représentent l'élément SignedInfo bien formé, du premier caractère jusqu'au dernier caractère de la représentation XML, inclus. Cela inclut le texte entier des balises de début et de fin de l'élément SignedInfo, ainsi que le balisage et les données textuelles vf. de tous les descendants (c.-à-d., le texte vf.) entre ces balises. L'utilisation de la canonisation de l'élément SignedInfo basée sur le texte n'est PAS RECOMMANDÉE.

Nous recommandons que les applications qui implémentent des canonisations basées sur le texte plutôt que sur XML -- telles que les applications contraintes par des ressources -- génèrent du XML canonisé en sortie séquentielle afin d'atténuer les soucis d'interopérabilité et de sécurité. Par exemple, une telle implémentation DEVRAIT (au moins) générer des instances XML [XML] autonomes.

NOTE : l'application de signature doit faire très attention dans l'acceptation et l'éxecution d'un élément CanonicalizationMethod arbitraire. Par exemple, la méthode de canonisation pourrait réécrire les URI des éléments References en cours de validation. Ou, elle pourrait massivement transformer l'élément SignedInfo de sorte que la validation réussisse toujours (c-à-d, convertir l'élément SignedInfo en une signature triviale avec une clé connue sur des données triviales). Étant donné que l'élément CanonicalizationMethod se trouve à l'intérieur de l'élément SignedInfo, dans la forme canonique résultante, il pourrait s'effacer lui-même de l'élément SignedInfo ou modifier l'élément SignedInfo de sorte qu'une fonction de canonisation différente apparaîtrait avoir été utilisée ! Donc un élément Signature, qui semble identifier les données désirées avec la clé , le DigestMethod et le SignatureMethod désirés, peut être dénué de sens si un élément CanonicalizationMethod capricieux est utilisé.

   Définition de schéma :

   <element name="CanonicalizationMethod" type="ds:CanonicalizationMethodType"/> 
   <complexType name="CanonicalizationMethodType" mixed="true">
     <sequence>
       <any namespace="##any" minOccurs="0" maxOccurs="unbounded"/>
       <!-- (0,unbounded) elements from (1,1) namespace -->
     </sequence>
     <attribute name="Algorithm" type="anyURI" use="required"/> 
   </complexType>

   DTD :

   <!ELEMENT CanonicalizationMethod (#PCDATA %Method.ANY;)* > 
   <!ATTLIST CanonicalizationMethod 
    Algorithm CDATA #REQUIRED >

4.3.2 L'élément SignatureMethod

L'élément SignatureMethod est un élément requis qui spécifie l'algorithme utilisé pour la génération et la validation de la signature. Cet algorithme identifie toutes les fonctions cryptographiques impliquées dans l'opération de signature (par exemple, le hachage, les algorithmes à clé publique, les codes MAC, le remplissage, etc.). Cet élément utilise la structure générale définie ici pour les algorithmes décrits dans la section 6.1 : « Les identifiants d'algorithme et les obligations d'implémentation ». Alors qu'il n'y a qu'un seul identifiant, celui-ci peut spécifier un format contenant plusieurs valeurs de signature distinctes.

   Définition de schéma :

   <element name="SignatureMethod" type="ds:SignatureMethodType"/>
   <complexType name="SignatureMethodType" mixed="true">
     <sequence>
       <element name="HMACOutputLength" minOccurs="0" type="ds:HMACOutputLengthType"/>
       <any namespace="##other" minOccurs="0" maxOccurs="unbounded"/>
       <!-- (0,unbounded) elements from (1,1) external namespace -->
      </sequence>
    <attribute name="Algorithm" type="anyURI" use="required"/> 
   </complexType>

   DTD :

   <!ELEMENT SignatureMethod (#PCDATA|HMACOutputLength %Method.ANY;)* >
   <!ATTLIST SignatureMethod 
    Algorithm CDATA #REQUIRED >

4.3.3 L'élément Reference

L'élément Reference est un élément qui peut apparaître une ou plusieurs fois. Il spécifie un algorithme de prétraitement et une valeur condensées et, facultativement, un identifiant de l'objet en train d'être signé, le type de l'objet et/ou une liste de tranformations à appliquer avant un prétraitement. L'identification (URI) et les transformations décrivent la manière dont le contenu condensé (c.-à-d., la valeur d'entrée pour la méthode de prétraitement) a été créé. L'attribut Type facilite le traitement des données référencées. Par exemple, tandis que la spécification ne requiert pas de conditions particulières sur des données extérieures, une application peut souhaiter signaler que le référent soit un élément Manifest. Un attribut optionnel ID permet à un élément Reference d'être référencé à partir d'une autre localisation.

   Définition de schéma :

   <element name="Reference" type="ds:ReferenceType"/>
   <complexType name="ReferenceType">
     <sequence> 
       <element ref="ds:Transforms" minOccurs="0"/> 
       <element ref="ds:DigestMethod"/> 
       <element ref="ds:DigestValue"/> 
     </sequence>
     <attribute name="Id" type="ID" use="optional"/> 
     <attribute name="URI" type="anyURI" use="optional"/> 
     <attribute name="Type" type="anyURI" use="optional"/> 
   </complexType>

   DTD :

   <!ELEMENT Reference (Transforms?, DigestMethod, DigestValue)  >
   <!ATTLIST Reference  
    Id  ID  #IMPLIED
    URI CDATA   #IMPLIED
    Type    CDATA   #IMPLIED>

4.3.3.1 L'attribut URI

L'attribut URI identifie un objet de données en utilisant une référence d'URI, comme spécifié par RFC2396 [URI]. L'ensemble des caractères admis pour les attributs URI est le même que pour XML, nommément [Unicode]. Cependant, certains caractères Unicode ne sont pas admis dans les références d'URI, comprenant tous les caractères non ASCII et les caractères exclus listés dans RFC2396 [URI, section 2.4]. Cependant, le signe dièse (#), le signe pourcentage (%) et les crochets ([ ]), ré-admis dans RFC 2732 [URI-Literal], sont permis. Les caractères non admis doivent être masqués de la manière suivante :

1. Chaque caractères non admis est converti en [UTF-8] sur un ou plusieurs octets ;
2. Tous les octets correspondant à un caractère non admis sont masqués selon le mécanisme de masquage des URI (c'est à dire, convertis en %HH, où HH est la notation hexadécimale de la valeur de l'octet) ;
3. Le caractère original est remplacé par la séquence de caractères résultante.

Les applications de signature XML DOIVENT être capables d'analyser la syntaxe des URI. Nous RECOMMENDONS qu'elles soient capable de résoudre les URI dans le schéma HTTP. La résolution d'un URI dans le schéma HTTP DOIT être conforme avec les définitions de code de statut de [HTTP] (par exemple, les réorientations 302, 305 et 307 sont suivies pour obtenir le corp-entité d'un code de statut de réponse 200). Les applications doivent également avoir connaissance du fait qu'un paramètre de protocole et une information d'état, (tels que les cookies HTTP, les profils des outils HTML ou les négociations de contenu), peuvent affecter le contenu produit par la résolution d'un URI.

Si une ressource est identifiée par plus d'un URI, le plus spécifique doit être utilisé (par exemple, http://www.w3.org/2000/06/interop-pressrelease.html.en plutôt que http://www.w3.org/2000/06/interop-pressrelease). (Voir « La validation de référence » (section 3.2.1) pour plus d'informations sur le traitement des références.)

Si l'attribut URI est omis entièrement, l'application réceptrice est supposée connaître l'identité de l'objet. Par exemple, un protocole de données simple pourrait omettre cet attribut si l'objet est identifié dans le contexte de l'application. Cet attribut peut être omis dans un élément Reference, au plus , dans tout élément SignedInfo particulier, ou Manifest.

L'attribut optionnel Type contient des informations à propos du type de l'objet à signer. Il est représenté par un URI. Par exemple :

Type="http://www.w3.org/2000/09/xmldsig#Object"
Type="http://www.w3.org/2000/09/xmldsig#Manifest"

L'attribut Type s'applique à l'article qui est pointé, et non pas son contenu. Par exemple, une référence qui identifie un élément Object contenant un élément SignatureProperties est toujours du type #Object. L'attribut type est consultatif. Aucune validation de l'information de type n'est nécessaire dans cette spécification.

« errata 2002-05-08 »

4.3.3.2 Le modèle de traitement des références

Note : XPath est RECOMMANDÉ. Les applications de signature n'ont pas besoin de se conformer à la spécification [XPath] pour être conforme à cette spécification. Cependant, le modèle de données, les définitions (par exemple, les ensembles de nœuds vf.[N.d.T. node-sets]) et la syntaxe XPath sont utilisés dans ce document pour décrire une fonctionnalité pour ceux qui veulent traiter un code XML en tant que code XML (plutôt qu'en octets) faisant partie de la génération de la signature. Pour ceux qui veulent utiliser ces caractéristiques, une implémentation en conformité avec [XPath] est un moyen d'implémenter ces caractéristiques, mais il n'est pas nécessaire de les utiliser. De telles applications pourraient substituer un remplaçant suffisamment fonctionnel à un ensemble de nœuds et implémenter seulement ceux des comportements de l'expression XPath REQUIS par cette spécification. Cependant, par simplicité, nous utiliserons généralement une terminologie XPath sans inclure cette qualification sur chaque point. Les conditions des « ensembles de nœuds XPath » peuvent inclure l'équivalent fonctionnel d'un ensemble de nœuds. Les conditions de traitement XPath peuvent inclure des comportements d'applications qui sont équivalents au comportement XPath correspondant.

Le type de données du résultat de la résolution d'un URI ou de transformations subséquentes est soit un flux d'octets soit un ensemble de nœuds XPath.

Les éléments Transforms spécifiés dans ce document sont définis selon la valeur d'entrée qu'ils requièrent. Voici le comportement par défaut d'une application de signature :

• Si l'objet de données est un flux d'octets et que la transformation suivante nécessite un ensemble de nœuds, l'application de signature DOIT tenter d'analyser les octets produisant l'ensemble de nœuds requis via un traitement [XML] bien formé ;
• Si l'objet de données est un ensemble de nœuds et que la transformation suivante requiert un flux d'octets, l'application de signature DOIT tenter de convertir l'ensemble de nœuds en un flux d'octets en utilisant le XML canonique [XML-C14N].

Les utilisateurs peuvent spécifier des transformations secondaires qui écrasent les valeurs par défaut durant les transitions vers les transformations qui attendent des valeurs d'entrée différentes. Le dernier flux d'octets contient les octets des données [N.d.T. data octets] en cours de sécurisation. L'algorithme de prétraitement spécifié par l'élément DigestMethod est alors appliqué à ces octets de données, l'élément DigestValue contenant la valeur résultante.

À moins que la référence d'URI ne soit une référence « dans un même document » comme définie dans [URI, Section 4.2], le résultat de la résolution de la référence d'URI DOIT être un flux d'octets. En particulier, un document XML identifié par un URI n'est pas analysé par l'application de signature à moins que l'URI ne soit une référence dans un même document ou qu'une transformation qui requiert une analyse XML ne soit appliquée. (Voir l'élément Transforms (section 4.3.3.4).)

Lorsqu'un fragment est précédé par un URI absolu ou relatif dans la référence d'URI, la signification du fragment est définie par le type MIME de la ressource. Même pour des documents XML, la résolution d'un URI (incluant le traitement du fragment) pourrait être fait pour l'application de signature par un serveur proxy. De ce fait, la validation de référence pourrait échouer si le traitement du fragment n'était pas réalisé de manière normale (comme défini dans la section suivante pour les références dans un même document). En conséquence, nous RECOMMANDONS que l'attribut URI n'inclut pas d'identifiant de fragment et qu'un tel traitement soit spécifié comme une transformation XPath supplémentaire.

Lorsqu'un fragment n'est pas précédé d'un URI dans la référence d'URI, les applications de signature XML DOIVENT prendre en charge l'URI nul et le nom nu XPointer. Nous RECOMMANDONS la prise en charge des XPointer< '#xpointer(/)' et '#xpointer(id('ID'))' dans un même document si l'application est destinée à gérer une quelconque canonisation préservant les commentaires. (Sinon l'URI="#foo" supprimera automatiquement les commentaires avant que la canonisation puisse même être invoquée). Toute autre gestion des XPointer est OPTIONNELLE, notamment toute la gestion des noms nus et des autres XPointer dans des ressources externes, puisque les applications >n'ont pas forcément le contrôle sur la façon dont le fragment est généré (ceci menant à des problèmes d'interopérabilité et des échecs de validation).

Les exemples suivants montrent ce que l'attribut URI identifie et la manière dont ceci est résolu :

URI="http://example.com/bar.xml"

Identifie les octets qui représentent la ressource externe 'http://example.com/bar.xml', qui est probablement un document XML à la vue de son extension de fichier.

URI="http://example.com/bar.xml#chapitre1"

Identifie l'élément avec un attribut ID ayant comme valeur 'chapitre1' d'une ressource externe XML 'http://example.com/bar.xml', fourni comme un flux d'octets. Encore une fois, pour l'interopérabilité, l'élément identifié par 'chapitre1' devrait être obtenu en utilisant une transformation XPath plutôt qu'un fragment d'URI (la résolution d'un nom XPointer nu dans des ressources externes n'est pas REQUISE dans cette spécification).

URI=""

Identifie un ensemble de nœuds (moins les nœuds de commentaires) de la ressource XML contenant la signature.

URI="#chapitre1"

Identifie un ensemble de nœuds contenant l'élément dont l'attribut ID a pour valeur 'chapitre1' de la ressource XML contenant la signature. La signature XML (et ses applications) modifient cet ensemble de nœuds pour inclure l'élément et tous ses descendants, y compris les espaces de nommage et les attributs -- mais pas les commentaires.

4.3.3.3 Les références d'URI dans un même document [N.d.T. Same-document URI References]

La résolution d'une référence dans un même document DOIT engendrer un ensemble de nœuds XPath convenable pour être utilisé par le XML canonique [XML-C14N]. Précisément, a résolution d'un URI nul (URI="") DOIT engendrer un ensemble de nœuds qui inclut tous les nœuds, qui ne sont pas des nœuds de commentaires, du document XML contenant l'attribut URI. Dans un fragment d'URI, les caractères se trouvant après le caractère dièse ('#') sont conformes à la syntaxe XPointer [Xptr]. Lors du traitement d'un XPointer, l'application DOIT se comporter comme si le nœud racine du document XML contenant l'attribut URI était utilisé pour initialiser le contexte d'évaluation du XPointer. L'application DOIT se comporter comme si le résultat du traitement du XPointer était un ensemble de nœuds provenant de l'ensemble de localisations résultant comme suit :

1. Mettre à l'écart les nœuds de point ;
2. Remplacer chaque nœud d'intervalle par tous les nœuds XPath ayant un contenu se trouvant pleinement ou partiellement dans l'intervalle ;
3. Remplacer le nœud racine par ses fils (s'il est dans l'ensemble de nœuds) ;
4. Remplacer tout nœud d'élément E par E plus tous les descendants de E (texte, commentaire, instruction de traitement [N.d.T. PI], élément) et tous les nœuds d'espaces de nommage et d'attributs de E et de ses descendants ;
5. Si l'URI n'est pas un XPointer complet, alors supprimer tous les nœuds commentaires.

Les étapes du second au dernier remplacement sont nécessaires car XPointer indique typiquement un sous arbre de l'arbre d'analyse d'un document XML, utilisant uniquement un nœud élément à la racine du sous arbre, alors que le XML canonique traite un ensemble de nœuds comme un ensemble de nœuds dans lequel l'absence de nœuds descendants entraîne l'absence de leur texte représentatif issu de la forme canonique.

La dernière étape est réalisé pour les URI nuls, les noms nus XPointer et les séquences d'enfants XPointer. Cela est nécessaire car lorsque le XML canonique [XML-C14N] valide un ensemble de nœuds, il traite l'ensemble de nœuds comme comme tel : avec ou sans commentaires. Il invoque ses propres expressions XPath (par défaut ou sans commentaires), seulement quand on l'appelle avec un flux d'octets. Ainsi, pour garder le comportement par défaut qui consiste à retirer les commentaires à l'examen d'un ensemble de nœuds, ils sont supprimés durant la dernière étape si l'URI n'est pas un Xpointer complet. Pour garder les commentaires durant la sélection d'un élément par un identifiant ID, il faut utiliser le XPointer complet suivant : URI='#xpointer(id('ID'))'. Pour garder les commentaires durant la sélection d'un document entier, il faut utiliser le XPointer complet suivant : URI='#xpointer(/)'. Cet XPointer contient une expression XPath simple qui inclut le nœud racine, qui de la seconde à la dernière étape est remplacé par tous les nœuds de l'arbre d'analyse (tous les descendants, plus tous les attributs, plus tous nœuds d'espaces de nommage).

4.3.3.4 L'élément Transforms

L'élément optionnel Transforms contient une liste ordonnée d'éléments Transform ; ceux-ci décrivent la manière dont le signataire a obtenu l'objet de données qui a été prétraité. La sortie de chaque élément Transform sert d'entrée pour le prochain élément Transform. L'entrée du premier élément Transform est le résultat de la résolution de l'attribut URI de l'élément Reference. La sortie du dernier élément Transform est l'entrée pour l'algorithme de l'élément DigestMethod. Lorsque les transformations sont appliquées, le signataire ne signe pas le document natif (original) mais le document résultant (transformé). (Voir « Seul ce qui est signé est sûr » (section 8.1).)

Chaque élément Transform est constitué d'un attribut Algorithm et, le cas échéant, de paramètres de contenu appropriés pour l'algorithme donné. La valeur de l'attribut Algorithm spécifie le nom de l'algorithme qui doit être utilisé, et le contenu de l'élément Transform fournit des données supplémentaires qui régissent le traitement en entrée de la transformation par l'algorithme. (Voir « Les identifiants d'algorithmes et les obligations d'implémentation » (section 6).)

Comme décrit dans « Le modèle de traitement des références » (section  4.3.3.2), certaines transformations admettent un ensemble de nœuds XPath comme valeur d'entrée, tandis que d'autres requiert un flux d'octets. Si le format de l'entrée en question concorde avec celui attendu par la transformation, alors la transformation opère sur l'entré inchangée. Si le format requis en entrée par la transformation diffère de celui de l'entrée en question, alors l'entrée doit être convertie.

Certains éléments Transform peuvent requérir un type MIME, un jeu de caractères [N.d.T. charset] (un « jeu de caractères » enregistré par l'IANA), ou d'autres informations explicites de ce genre concernant les données qui sont reçues d'un élément Transform précédent ou de données source, bien qu'aucun algorithme d'élément Transform spécifié dans ce document ne nécessite de telles informations explicites. Ces caractéristiques de données sont fournies en paramètres à l'algorithme de l'élément Transform et devraient être décrites dans la spécification de l'algorithme.

Les exemples de transformations incluent le décodage en base64 [MIME], la canonisation [XML-C14N], le filtrage XPath [XPath] et XSLT [XSLT], mais ne s'y limitent pas. La définition générique de l'élément Transform permet également des algorithmes de transformation pour des applications spécifiques. Par exemple, la transformation pourrait être une routine de décompression donnée par une classe Java apparaissant comme un paramètre codé en base64 vers un algorithme en Java de l'élément Transform. Cependant, les applications devraient limiter l'emploi des transformations pour des applications spécifiques si elles souhaitent que leurs signatures soient vérifiables en dehors de leur domaine d'application. la liste des tranformations standards est définie dans « Les algorithmes de transformation » (section 6.6).

   Définition de schéma :

   <element name="Transforms" type="ds:TransformsType"/>
   <complexType name="TransformsType">
     <sequence>
       <element ref="ds:Transform" maxOccurs="unbounded"/>  
     </sequence>
   </complexType>

   <element name="Transform" type="ds:TransformType"/>
   <complexType name="TransformType" mixed="true">
     <choice minOccurs="0" maxOccurs="unbounded"> 
       <any namespace="##other" processContents="lax"/>
       <!-- (1,1) elements from (0,unbounded) namespaces -->
       <element name="XPath" type="string"/> 
     </choice>
     <attribute name="Algorithm" type="anyURI" use="required"/> 
   </complexType>

   DTD :

   <!ELEMENT Transforms (Transform+)>

   <!ELEMENT Transform (#PCDATA|XPath %Transform.ANY;)* >
   <!ATTLIST Transform 
    Algorithm    CDATA    #REQUIRED >

   <!ELEMENT XPath (#PCDATA) >

4.3.3.5 L'élément DigestMethod

L'élément DigestMethod est un élément requis qui identifie l'algorithme de prétraitement qui doit être appliqué sur l'objet signé. Cet élément utilise ici la structure générale pour les algorithmes spécifiés dans « Les identifiants d'algorithmes et les obligations d'implémentation » (section 6.1).

Si le résultat de la résolution de l'URI et de l'application d'éléments Transforms est un ensemble de nœuds XPath (ou un remplacement fonctionnel suffisant implémenté par l'application), alors il doit être converti comme décrit dans « Le modèle de traitement des références » (section  4.3.3.2). Si le résultat de la résolution de l'URI et de l'application d'éléments Transforms est un flux d'octets, alors aucune conversion ne survient (les commentaires pourraient être présents si le XML canonique avec commentaires était spécifié dans les éléments Transforms). L'algorithme de prétraitement s'applique sur les octets de données du flux d'octets résultant.

   Définition de schéma :

   <element name="DigestMethod" type="ds:DigestMethodType"/>
   <complexType name="DigestMethodType" mixed="true"> 
     <sequence>
       <any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
     </sequence>    
     <attribute name="Algorithm" type="anyURI" use="required"/> 
   </complexType>

   DTD :

   <!ELEMENT DigestMethod (#PCDATA %Method.ANY;)* >
   <!ATTLIST DigestMethod
    Algorithm       CDATA   #REQUIRED >

4.3.3.6 L'élément DigestValue

L'élément DigestValue est un élément qui contient la valeur codée du prétraitement. Le condensé est toujours codé en base64 [MIME].

   Définition de schéma :

   <element name="DigestValue" type="ds:DigestValueType"/>
   <simpleType name="DigestValueType">
     <restriction base="base64Binary"/>
   </simpleType>

   DTD :

   <!ELEMENT DigestValue  (#PCDATA)  >
   <!-- valeur condensée codée en base64 -->

4.4 L'élément KeyInfo

L'élément KeyInfo est un élément facultatif qui permet au(x) destinaire(s) d'obtenir la clé nécessaire à la validation de la signature. L'élément KeyInfo peut contenir des clés, des noms, des certificats et d'autres informations concernant la gestion de clés publiques, telles que des données concernant la diffusion en ligne ou l'agrément des clés. Cette spécification définit quelques types simples, mais les applications peuvent étendre ces types ou les remplacer tous par leur propre sémantique d'information et d'échange de clés en utilisant les espaces de nommages XML. [XML-ns] Cependant, les questions concernant la confiance de telles informations de clés (par exemple, leur authenticité ou leur force) sont hors de portée de cette spécification et sont laissées à l'application.

Si l'élément KeyInfo est omis, le destinataire est sensé pouvoir identifier la clé en fonction du contexte de l'application. Plusieurs instructions dans l'élément KeyInfo font référence à la même clé. Bien que les applications puissent définir et utiliser tout mécanisme de leur choix par l'inclusion d'éléments provenant de différents espaces de nommage, les versions conformes DOIVENT implémenter l'élément KeyValue (section 4.4.2) et DEVRAIENT implémenter l'élément RetrievalMethod (section 4.4.3).

Les spécifications de schéma/DTD de nombreux fils de l'élément KeyInfo (par exemple, PGPData, SPKIData, X509Data) permettent à leur contenu d'être étendu/complété par des éléments provenant d'un autre espace de nommage. Ceci n'est envisageable que si on peut ignorer en toute sécurité ces éléments d'extension tout en affirmant la gestion des types définis dans cette spécification. Sinon, les éléments externes, incluant les structures alternatives de celles définies par cette specification, DOIVENT être des fils de l'élément KeyInfo. Par exemple, si on devait définir un standard XML-PGP complet, alors son élément racine DOIT être un fils de KeyInfo. (Bien sûr, des nouvelles structures provenant d'espaces de nommage externes peuvent incorporer des élément provenant de l'espace de nommage &dsig; via des fonctionnalités du langage de définition des types. Par exemple, elles peuvent créer un DTD qui mélange leurs propres éléments qualifiés et ceux de dsig, ou créer un schéma qui permet, inclut, importe ou dérivent des nouveaux types basés sur les éléments &dsig;.)

La liste suivante résume les types d'éléments KeyInfo auxquels sont alloués un identifiant dans l'espace de nommage &dsig; ; ceux-ci peuvent être utilisés dans l'attribut Type de l'élément RetrievalMethod pour décrire la structure d'un élément KeyInfo distant.

• http://www.w3.org/2000/09/xmldsig#DSAKeyValue
• http://www.w3.org/2000/09/xmldsig#RSAKeyValue
• http://www.w3.org/2000/09/xmldsig#X509Data
• http://www.w3.org/2000/09/xmldsig#PGPData
• http://www.w3.org/2000/09/xmldsig#SPKIData
• http://www.w3.org/2000/09/xmldsig#MgmtData

En plus des types ci-dessus, pour lesquels nous définissons une structures XML, nous spécifions un type supplémentaire pour indiquer un certificat X.509 binaire (ASN.1 DER).

• http://www.w3.org/2000/09/xmldsig#rawX509Certificate

   Définition de schéma :

   <element name="KeyInfo" type="ds:KeyInfoType"/> 
   <complexType name="KeyInfoType" mixed="true">
     <choice maxOccurs="unbounded">     
       <element ref="ds:KeyName"/> 
       <element ref="ds:KeyValue"/> 
       <element ref="ds:RetrievalMethod"/> 
       <element ref="ds:X509Data"/> 
       <element ref="ds:PGPData"/> 
       <element ref="ds:SPKIData"/>
       <element ref="ds:MgmtData"/>
       <any processContents="lax" namespace="##other"/>
       <!-- (1,1) elements from (0,unbounded) namespaces -->
     </choice>
     <attribute name="Id" type="ID" use="optional"/>
   </complexType>

   DTD :

   <!ELEMENT KeyInfo (#PCDATA|KeyName|KeyValue|RetrievalMethod|
               X509Data|PGPData|SPKIData|MgmtData %KeyInfo.ANY;)* >
   <!ATTLIST KeyInfo  
    Id  ID   #IMPLIED >

4.4.1 L'élément KeyName

L'élément KeyName contient une valeur de chaîne de caractères (dans laquelle les espaces sont importants) qui peut être utilisée par le signataire pour communiquer un identifiant de clé au destinataire. Typiquement, KeyName contient un identifiant lié au couple de clés utilisée pour signer le message, mais il peut aussi contenir d'autres informations, liées au protocole, qui identifient indirectement un couple de clés. (Les utilisations courantes de l'élément KeyName comprennent des noms de clés sous forme de chaîne de caractères, un index de clés, un nom distinctif (DN), une adresse mèl, etc.)

   Définition de schéma :

   <element name="KeyName" type="string"/>

   DTD :

   <!ELEMENT KeyName (#PCDATA) >

4.4.2 L'élément KeyValue

L'élément KeyValue contient une clé publique unique qui peut être utile lors la validation de signature. Les formats structurés définissant les clés publiques DSA (REQUISES) et RSA (RECOMMANDÉES) sont définis dans « Les algorithmes de signature » (section 6.4). L'élément KeyValue peut inclure des valeurs de clés publiques, définies ailleurs, représentées par un type PCDATA, ou bien des types d'éléments provenant d'un espace de nommage externe.

   Définition de schéma :

   <element name="KeyValue" type="ds:KeyValueType"/> 
   <complexType name="KeyValueType" mixed="true">
    <choice>
      <element ref="ds:DSAKeyValue"/>
      <element ref="ds:RSAKeyValue"/>
      <any namespace="##other" processContents="lax"/>
    </choice>
   </complexType>

   DTD :

   <!ELEMENT KeyValue (#PCDATA|DSAKeyValue|RSAKeyValue %KeyValue.ANY;)* >

4.4.2.1 L'élément DSAKeyValue

Identifiant

Type="http://www.w3.org/2000/09/xmldsig#DSAKeyValue"
(cet identifiant peut être utilisé dans un élément RetrievalMethod, ou Reference, pour identifier le type du référent.)

Les clés DSA et l'algorithme de signature DSA sont spécifiés dans [DSS]. Les valeurs de clé publique DSA peuvent avoir les champs suivants :

P

un module de nombres premiers respectant les conditions [DSS]

Q

un entier dans l'intervalle 2**159 < Q < 2**160 qui est un diviseur premier de P-1

G

un nombre entier avec certaines propriétés en ce qui concerne P et Q

Y

G**X mod P (où X est la partie de la clé privée et qui n'est pas rendue publique)

J

(P - 1) / Q

seed

un point de départ (graine) de la génération DSA de nombres premiers

pgenCounter

un compteur pour la génération DSA de nombres premiers

Le paramètre J est disponible en inclusion uniquement pour des raisons d'efficacité puisqu'il est calculable à partir de P et Q. Les paramètres seed et pgenCounter sont utilisés dans l'algorithme de génération de nombres premiers DSA spécifié dans [DSS]. Comme tels, ils sont facultatifs mais doivent être soit tous les deux présents, soit tous les deux absents. Cet algorithme de génération de nombres premiers est conçu pour garantir qu'un nombre premier faible ne sera pas utilisé et pour produire une valeur P et une valeur Q. Les paramètres P, Q et G peuvent être publics et communs à tout un groupe d'utilisateurs. Ils pourront être connus à partir du contexte de l'application. Comme tels, ils sont facultatifs, mais P et Q doivent être soit tous les deux présents, soit tous les deux absents. Si les paramètres P, Q, seed et pgenCounter sont tous présents, les implémentations n'ont pas l'obligation de vérifier s'ils sont cohérents et elles sont libres d'utiliser P et Q, ou seed et pgenCounter. Tous les paramètres sont codés en valeur base64 [MIME].

Les entiers de longueur arbitraire (par exemple, des « grands nombres » tels que les modules RSA) sont représentés en XML par des chaînes d'octets, comme défini par le type ds:CryptoBinary.

   Définition de schéma :

   <element name="DSAKeyValue" type="ds:DSAKeyValueType"/> 
   <complexType name="DSAKeyValueType"> 
     <sequence>
       <sequence minOccurs="0">
         <element name="P" type="ds:CryptoBinary"/> 
         <element name="Q" type="ds:CryptoBinary"/>
       </sequence>
       <element name="G" type="ds:CryptoBinary" minOccurs="0"/> 
       <element name="Y" type="ds:CryptoBinary"/> 
       <element name="J" type="ds:CryptoBinary" minOccurs="0"/>
       <sequence minOccurs="0">
         <element name="Seed" type="ds:CryptoBinary"/> 
         <element name="PgenCounter" type="ds:CryptoBinary"/> 
       </sequence>
     </sequence>
   </complexType>

   DTD :

   <!ELEMENT DSAKeyValue ((P, Q)?, G?, Y, J?, (Seed, PgenCounter)?) > 
   <!ELEMENT P (#PCDATA) >
   <!ELEMENT Q (#PCDATA) >
   <!ELEMENT G (#PCDATA) >
   <!ELEMENT Y (#PCDATA) >
   <!ELEMENT J (#PCDATA) >
   <!ELEMENT Seed (#PCDATA) >
   <!ELEMENT PgenCounter (#PCDATA) >

4.4.2.2 l'élément RSAKeyValue

Identifiant

Type="http://www.w3.org/2000/09/xmldsig#RSAKeyValue"
(cet identifiant peut être utilisé dans l'élément RetrievalMethod, ou Reference, pour identifier le type du référent).

Les valeurs de clé RSA ont deux champs : Modulus et Exponent.

   <RSAKeyValue>
     <Modulus>xA7SEU+e0yQH5rm9kbCDN9o3aPIo7HbP7tX6WOocLZAtNfyxSZDU16ksL6W
      jubafOqNEpcwR3RdFsT7bCqnXPBe5ELh5u4VEy19MzxkXRgrMvavzyBpVRgBUwUlV
      5foK5hhmbktQhyNdy/6LpQRhDUDsTvK+g9Ucj47es9AQJ3U=
     </Modulus>
     <Exponent>AQAB</Exponent>
   </RSAKeyValue>

Les entiers de longueur arbitraire (par exemple, des « grands nombres » tels que les modules RSA) sont représentés en XML par des chaînes d'octets, comme défini par le type ds:CryptoBinary.

   Définition de schéma :

   <element name="RSAKeyValue" type="ds:RSAKeyValueType"/>
   <complexType name="RSAKeyValueType">
     <sequence>
       <element name="Modulus" type="ds:CryptoBinary"/> 
       <element name="Exponent" type="ds:CryptoBinary"/>
     </sequence>
   </complexType>

   DTD :

   <!ELEMENT RSAKeyValue (Modulus, Exponent) > 
   <!ELEMENT Modulus (#PCDATA) >
   <!ELEMENT Exponent (#PCDATA) >

4.4.3 L'élément RetrievalMethod

L'élément RetrievalMethod dans l'élément KeyInfo est utilisé pour transmettre une référence vers une instruction de KeyInfo stockée dans un autre endroit. Par exemple, plusieurs signatures dans un document pourraient utiliser une clé vérifiée par une succession de certificats X.509v3, qui apparaît une seule fois dans le document ou bien qui est distante, en dehors du document ; chaque élément KeyInfo de la signature peut référencer cette succession en utilisant un unique élément RetrievalMethod au lieu d'inclure la succession entière avec une séquence d'éléments X509Certificate.

L'élément RetrievalMethod utilise la même syntaxe et le même comportement de résolution que les attributs URI de Reference (section 4.3.3.1) et le même modèle de traitement des références (section 4.3.3.2), sauf qu'il n'y a pas d'éléments fils DigestMethod ou DigestValue et que la présence de l'URI est obligatoire.

« errata 2002-05-08 »

L'attribut Type est un identifiant facultatif pour le type de données qui doit être ramené. Le resultat de la résolution d'un élément Reference de RetrievalMethod, pour tous les types d'éléments KeyInfo définis par cette spécification (section 4.4) avec une structure XML correspondante, est un élément XML ou un document XML dont cet élément est l'élément racine. L'élément rawX509Certificate de l'élément KeyInfo (pour lequel il n'existe pas de structure XML) renvoie un certificat binaire X509.

   Définition de schéma :

   <element name="RetrievalMethod" type="ds:RetrievalMethodType"/> 
   <complexType name="RetrievalMethodType">
     <sequence>
       <element ref="ds:Transforms" minOccurs="0"/> 
     </sequence>  
     <attribute name="URI" type="anyURI"/>
     <attribute name="Type" type="anyURI" use="optional"/>
   </complexType>

   DTD :

   <!ELEMENT RetrievalMethod (Transforms?) >
   <!ATTLIST RetrievalMethod
      URI   CDATA #REQUIRED 
      Type  CDATA #IMPLIED >

4.4.4 L'élément X509Data

Identifiant

Type="http://www.w3.org/2000/09/xmldsig#X509Data "
(cet identifiant peut être utilisé dans un élément RetrievalMethod, ou Reference, pour identifier le type du référent).

Un élément X509Data dans KeyInfo contient un ou plusieurs identifiants de clés ou certificats X509 (ou identifiants de certificats ou une liste de révocation). Le contenu de l'élément X509Data est :

1. Au moins d'un élément, provenant de l'ensemble des types d'éléments suivants ; chacun d'eux pouvant apparaître ensemble ou plus d'une fois, ssi (si et seulement si) chaque instance décrit le même certificat ou est liée au même certificat.
2. • L'élément X509IssuerSerial, qui contient le couple nom/numéro de série distingué d'un émetteur X.509 qui DEVRAIT être en comformité avec la RFC2253 [LDAP-DN] ;
   • L'élément X509SubjectName, qui contient le nom distingué d'un sujet X.509 qui DEVRAIT être en conformité avec la RFC2253 [LDAP-DN] ;
   • L'élément X509SKI, qui contient la valeur pleine codée en base64 (c.-à-d., non-codée-DER) d'une extension SubjectKeyIdentifier X509v3 ;
   • L'élément X509Certificate, qui contient un certificat [X509v3] codé en base64 et ;
   • Des éléments provenant d'un espace de nommage externe qui accompagnent/complètent n'importe lesquels des éléments cités ci-dessus ;
   • L'élément X509CRL, qui contient une liste [X509v3] de certificats de révocation codée en base64 (CRL).

« errata 2002-01-28 »

Tous les éléments X509IssuerSerial, X509SKI et X509SubjectName qui apparaissent DOIVENT se référer à un ou des certificats contenant une clé de validation. Tous ces éléments qui se réfèrent à un certificat individuel particulier DOIVENT être regroupés à l'intérieur d'un unique élément X509Data et, si le certificat auquel ils se réfèrent apparaît, ce certificat DOIT également se trouver dans cet l'élément X509Data.

Tous les éléments X509IssuerSerial, X509SKI et X509SubjectName, qui sont rattachés à la même clé mais à différents certificats, DOIVENT être regroupés dans un unique élément KeyInfo mais PEUVENT apparaître dans plusieurs éléments X509Data.

Tous les certificats apparaissant dans un élément X509Data DOIVENT être rattachés à une clé de validation soit en contenant celle-ci, soit en faisant partie de la chaîne de certification qui aboutit à un certificat contenant la clé de validation.

Les contraintes ci-dessus n'impliquent aucun ordre particulier. Les commentaires dans l'exemple suivant montrent ces contraintes :

   <KeyInfo>
     <X509Data> <!-- deux pointeurs vers le certificat-A -->
       <X509IssuerSerial> 
         <X509IssuerName>CN=TAMURA Kent, OU=TRL, O=IBM, 
           L=Yamato-shi, ST=Kanagawa, C=JP</X509IssuerName>
         <X509SerialNumber>12345678</X509SerialNumber>
       </X509IssuerSerial>
       <X509SKI>31d97bd7</X509SKI> 
     </X509Data>
     <X509Data><!-- un seul pointeur vers le certificat-B -->
       <X509SubjectName>Subject of Certificate B</X509SubjectName>
     </X509Data>
     <X509Data> <!-- succession de certificats -->
       <!--Signer cert, issuer CN=arbolCA,OU=FVT,O=IBM,C=US, serial 4-->
       <X509Certificate>MIICXTCCA..</X509Certificate>
       <!-- Sujet de certification intermédiaire CN=arbolCA,OU=FVT,O=IBM,C=US 
            issuer CN=tootiseCA,OU=FVT,O=Bridgepoint,C=US -->
       <X509Certificate>MIICPzCCA...</X509Certificate>
       <!-- Sujet de certification racine CN=tootiseCA,OU=FVT,O=Bridgepoint,C=US -->
       <X509Certificate>MIICSTCCA...</X509Certificate>
     </X509Data>
   </KeyInfo>

À noter qu'il n'y a pas de réserve directe pour un « panier » de certificats ou de CRLcodé en PKCS#7. Cependant, un ensemble de certificats et de CRL peut être présent dans un élément X509Data et plusieurs éléments X509Data peuvent se trouver dans un élément KeyInfo. Toutes les fois où plusieurs certificats apparaîssent dans un élément X509Data, au moins un certificat doit contenir la clé publique qui vérifie la signature.

De plus, les chaînes de caractères dans les DNames (X509IssuerSerial, X509SubjectName et KeyName si nécessaire) devraient être codées comme suit :

• Considèrer la chaîne de caractères comme contenant des caractères Unicode ;
• Masquer les occurrences des caractères spéciaux suivants en les préfixant d'un caractère "\" :
  • un caractère "#" apparaît au début de la chaîne de caractères ;
  • l'un des caractères ",", "+", """, "\", "<", ">" ou ";"
• Masquer toutes les occurences des caractères de contrôle ASCII (intervalle Unicode \x00 - \x1f) en les remplaçant par un caractère "\" suivi d'un nombre hexadécimal à deux chiffres montrant son nombre Unicode ;
• Masquer tout blanc de queue en remplaçant "\ " par "\20" ;
• Puisque les documents XML sont logiquement constitués de caractères, et non d'octets, la chaîne de caractères Unicode résultante est finalement codée selon l'encodage de caractère utilisé pour produire la représentation physique du document XML.

   Définition de schéma :

   <element name="X509Data" type="ds:X509DataType"/> 
   <complexType name="X509DataType">
     <sequence maxOccurs="unbounded">
       <choice>
         <element name="X509IssuerSerial" type="ds:X509IssuerSerialType"/>
         <element name="X509SKI" type="base64Binary"/>
         <element name="X509SubjectName" type="string"/>
         <element name="X509Certificate" type="base64Binary"/>
         <element name="X509CRL" type="base64Binary"/>
         <any namespace="##other" processContents="lax"/>
       </choice>
     </sequence>
   </complexType>

   <complexType name="X509IssuerSerialType"> 
     <sequence> 
       <element name="X509IssuerName" type="string"/> 
       <element name="X509SerialNumber" type="integer"/> 
     </sequence>
   </complexType>

   DTD :

   <!ELEMENT X509Data ((X509IssuerSerial | X509SKI | X509SubjectName |
                        X509Certificate | X509CRL)+ %X509.ANY;)>
   <!ELEMENT X509IssuerSerial (X509IssuerName, X509SerialNumber) >
   <!ELEMENT X509IssuerName (#PCDATA) >
   <!ELEMENT X509SubjectName (#PCDATA) >
   <!ELEMENT X509SerialNumber (#PCDATA) >
   <!ELEMENT X509SKI (#PCDATA) >
   <!ELEMENT X509Certificate (#PCDATA) >
   <!ELEMENT X509CRL (#PCDATA) >

   <!-- À noter que cette DTD et ce schéma autorisent un élément X509Data vide ;  
   la définition dans « L'élément KeyInfo » (section 4.4) l'empêche et indique 
   qu'au moins un élément de l'espace de nommage de dsig devrait être présent 
   dans les structures PGP, SPKI et X509. Ceci s'exprime aisément pour les autres types de clé, 
   mais pas pour X509Data du fait de sa structure riche. -->

4.4.5 L'élément PGPData

Identifiant

Type="http://www.w3.org/2000/09/xmldsig#PGPData "
(cet identifiant peut être utilisé dans un élément RetrievalMethod, ou Reference, pour identifier le type du référent).

L'élément PGPData dans KeyInfo est utilisé pour donner des informations liées aux couples de clés publiques PGP et aux signatures basées sur de telles clés. La valeur de PGPKeyID est une séquence binaire codée en base64 contenant un identifiant de clé PGP publique, comme défini dans [PGP, section 11.2]. L'élément PGPKeyPacket contient un paquet de clé [N.d.T. Key Material Packet] codé en base64, comme défini dans [PGP, section 11.2]. Ces types d'éléments des fils peuvent être complétés/étendus par ceux des voisins provenant d'un espace de nommage externe à l'intérieur d'un élément PGPData, ou l'élément PGPData peut être remplacé entièrement par une structure XML PGP alternative apparaissant comme fils de l'élément KeyInfo. L'élément PGPData doit contenir un élément PGPKeyID et/ou un élément PGPKeyPacket et 0 ou plusieurs éléments provenant d'un espace de nommage externe.

   Définition de schéma :

   <element name="PGPData" type="ds:PGPDataType"/> 
   <complexType name="PGPDataType"> 
     <choice>
       <sequence>
         <element name="PGPKeyID" type="base64Binary"/> 
         <element name="PGPKeyPacket" type="base64Binary" minOccurs="0"/> 
         <any namespace="##other" processContents="lax" minOccurs="0"
          maxOccurs="unbounded"/>
       </sequence>
       <sequence>
         <element name="PGPKeyPacket" type="base64Binary"/> 
         <any namespace="##other" processContents="lax" minOccurs="0"
          maxOccurs="unbounded"/>
       </sequence>
     </choice>
   </complexType>

   DTD :

 <!ELEMENT PGPData ((PGPKeyID, PGPKeyPacket?) | (PGPKeyPacket) %PGPData.ANY;) >
   <!ELEMENT PGPKeyPacket  (#PCDATA)  >
   <!ELEMENT PGPKeyID  (#PCDATA)  >

4.4.6 L'élément SPKIData

Identifiant

Type="http://www.w3.org/2000/09/xmldsig#SPKIData "
(Cet identifiant peut être utilisé dans un élément RetrievalMethod ou Reference pour identifier le type du référent)

L'élément SPKIData dans KeyInfo est utilisé pour transmettre des informations liées au couples de clés publiques SPKI, aux certificats et autres données SPKI. L'élément SPKISexp est l'expression codée en base64 d'une S-expression SPKI canonique. L'élément SPKIData doit contenir au moins un élément SPKISexp ; SPKISexp peut être complété/étendu par des éléments voisins, provenant d'un espace de nommage externe, dans un élément SPKIData, ou SPKIData peut être entièrement remplacé par une structure XML SPKI alternative apparaissant comme fils de l'élément KeyInfo.

   Définition de schéma :

   <element name="SPKIData" type="ds:SPKIDataType"/> 
   <complexType name="SPKIDataType">
     <sequence maxOccurs="unbounded">
       <element name="SPKISexp" type="base64Binary"/>
       <any namespace="##other" processContents="lax" minOccurs="0"/>
     </sequence>
   </complexType>

   DTD :

 <!ELEMENT SPKIData (SPKISexp %SPKIData.ANY;)  >
   <!ELEMENT SPKISexp  (#PCDATA)  >

4.4.7 L'élément MgmtData

Identifiant

Type="http://www.w3.org/2000/09/xmldsig#MgmtData "
(cet identifiant peut être utilisé dans un élément RetrievalMethod, ou Reference, pour identifier le type du référent).

L'élément MgmtData dans KeyInfo est une valeur de chaîne de caractères utilisée pour transmettre des données concernant la diffusion en ligne ou l'agrément de clés. Par exemple, un échange de clé DH, un chiffrement de clé RSA, etc. L'utilisation de cet élément N'EST PAS RECOMMANDÉE. Il fournit un crochet syntaxique dans lequel placer des données de diffusion en ligne ou d'agrément de clés. Cependant, des éléments fils interopérables supérieurs de l'élément KeyInfo pour la transmission de clés chiffrées ou pour l'agrément de clés sont spécifiés par le groupe de travail du W3C travaillant sur le chiffrement XML [N.d.T. XML Encryption] et ils devraient être utilisés au lieu de l'élément MgmtData.

   Définition de schéma :

   <element name="MgmtData" type="string"/>

   DTD :

   <!ELEMENT MgmtData (#PCDATA)>

4.5 L'élément Object

Identifiant

Type="http://www.w3.org/2000/09/xmldsig#Object"
(cet identifiant peut être utilisé dans un élément Reference pour identifier le type du référent)

L'élément Object est un élément facultatif qui peut apparaître une ou plusieurs fois. Lorsqu'il est présent, cet élément peut contenir tout type de données. Cet élément Object peut inclure un type MIME facultatif, un ID, et des attributs d'encodage.

L'attribut Encoding de l'élément Object peut être utilisé pour fournir un URI qui identifie la méthode qui sera utilisée pour coder l'objet (par exemple, un fichier binaire).

L'attribut MimeType est un attribut facultatif qui décrit les données dans l'élément Object (indépendamment de son encodage). C'est une chaîne de caractères ayant des valeurs définies par [MIME]. Par exemple, si l'élément Object contient un format PNG codé en base64, l'attribut Encoding peut être spécifié comme 'base64' et l'attribut MimeType comme 'image/png'. Cet attribut est à titre purement informatif ; aucune validation des informations de l'attribut MimeType n'est requise par cette spécification. Les applications qui requièrent un type normatif et des informations d'encodage pour la validation de la signature devraient spécifier un élément Transforms avec des types et/ou des encodages résultants bien définis.

« errata 2002-06-06 »

L'attribut Id de l'élément Object est communément référencé à partir d'un élément Reference se trouvant dans un élément SignedInfo, ou dans un élément Manifest. Cet élément est typiquement utilisé pour les signatures enveloppantes où l'objet en train d'être signé doit être inclus dans l'élément de signature. Le prétraitement est calculé à partir de l'ensemble de l'élément Object, y compris les balises de départ et de fin.

À noter que si l'application souhaite exclure les balises <Object> du calcul de prétraitement, l'élément Reference doit identifier l'objet de données effectif (ceci est facile pour des documents XML) ou on doit faire appel à une transformation pour supprimer les balises de l'élément Object (ceci est plus généralement utilisé lorsque l'objet de données n'est pas XML). L'exclusion de ces balises peut être désirée si on veut que la signature reste valide si un objet de données est déplacé de l'intérieur vers l'extérieur de la signature (ou vice versa), ou lorsque le contenu de l'élément Object est l'encodage d'un document binaire original et que l'on désire extraire et décoder de manière à signer la représentation originale bit à bit.

   Définition de schéma :

   <element name="Object" type="ds:ObjectType"/> 
   <complexType name="ObjectType" mixed="true">
     <sequence minOccurs="0" maxOccurs="unbounded">
       <any namespace="##any" processContents="lax"/>
     </sequence>
     <attribute name="Id" type="ID" use="optional"/> 
     <attribute name="MimeType" type="string" use="optional"/>
     <attribute name="Encoding" type="anyURI" use="optional"/> 
   </complexType>

   DTD :

   <!ELEMENT Object (#PCDATA|Signature|SignatureProperties|Manifest %Object.ANY;)* >
   <!ATTLIST Object  
    Id  ID  #IMPLIED 
    MimeType    CDATA   #IMPLIED 
    Encoding    CDATA   #IMPLIED >

5.0 Une syntaxe supplémentaire d'une signature

Cette section décrit l'implémentation optionnelle des éléments Manifest et SignatureProperties et décrit la gestion des instructions de traitement et des commentaires XML. En ce qui concerne les éléments Manifest et SignatureProperties, cette section en spécifie la syntaxe et la faible influence -- cela est laissé à l'application. Ces éléments peuvent être présents à n'importe quel endroit où le modèle de contenu de l'élément parent le permet ; le modèle de contenu de l'élément Signature permet uniquement la présence de ces éléments dans un élément Object.

5.1 L'élément Manifest

Identifiant

Type="http://www.w3.org/2000/09/xmldsig#Manifest"
(cet identifiant peut être utilisédans un élément Reference pour identifier le type du référent).

L'élément Manifest fournit une liste d'éléments Reference. Ce qui diffère d'avec la liste dans un élément SignedInfo c'est que l'application définit lesquels condensés, le cas échéant, sont validés auprès des objets référencés et qui décide quoi faire si l'objet est inaccessible ou si la comparaison avec le condensé échoue. Si un élément Manifest est indiqué à partir d'un élément SignedInfo, le condensé sur l'élément Manifest lui-même sera vérifié par le comportement de validation de signature principal. Les condensés, à l'intérieur d'un élément tel que Manifest, sont vérifiés à la discrétion de l'application. Si un élément Manifest est référencé à partir d'un autre élément Manifest, même le condensé d'ensemble de cet élément Manifest au deuxième niveau de profondeur pourrait ne pas être vérifié.

   Définition de schéma :

   <element name="Manifest" type="ds:ManifestType"/> 
   <complexType name="ManifestType">
     <sequence>
       <element ref="ds:Reference" maxOccurs="unbounded"/> 
     </sequence>  
     <attribute name="Id" type="ID" use="optional"/> 
   </complexType>

   DTD :

   <!ELEMENT Manifest (Reference+)  >
   <!ATTLIST Manifest  
             Id ID  #IMPLIED >

5.2 L'élément SignatureProperties

 

Identifiant

Type="http://www.w3.org/2000/09/xmldsig#SignatureProperties"
(cet identifiant peut être utilisé dans un élément Reference pour identifier le type du référent).

Des items d'information supplémentaires concernant la génération de la/les signature(s) peuvent être placés dans un élément SignatureProperty (c.-à-d., des informations concernant une estampille date/heure ou le numéro de série du matériel cryptographique utilisé pour la génération de la signature).

   Définition de schéma :

   <element name="SignatureProperties" type="ds:SignaturePropertiesType"/> 
   <complexType name="SignaturePropertiesType">
     <sequence>
       <element ref="ds:SignatureProperty" maxOccurs="unbounded"/> 
     </sequence>
     <attribute name="Id" type="ID" use="optional"/> 
   </complexType>

      <element name="SignatureProperty" type="ds:SignaturePropertyType"/> 
      <complexType name="SignaturePropertyType" mixed="true">
        <choice maxOccurs="unbounded">
          <any namespace="##other" processContents="lax"/>
          <!-- (1,1) elements from (1,unbounded) namespaces -->
        </choice>
        <attribute name="Target" type="anyURI" use="required"/> 
        <attribute name="Id" type="ID" use="optional"/> 
      </complexType>

   DTD :

   <!ELEMENT SignatureProperties (SignatureProperty+)  >
   <!ATTLIST SignatureProperties  
             Id ID   #IMPLIED  >

   <!ELEMENT SignatureProperty (#PCDATA %SignatureProperty.ANY;)* >
   <!ATTLIST SignatureProperty  
    Target  CDATA    #REQUIRED
    Id  ID   #IMPLIED  >

5.3 Les instructions de traitement

Aucune instruction de traitement XML (IT) [N.d.T. processing instruction (PI)] n'est utilisée par cette spécification.

À noter que les IT placées dans l'élément SignedInfo par une application seront signées, à moins que l'algorithme de l'élément CanonicalizationMethod ne les écarte. (Ceci est vrai pour tout contenu XML signé.) Tous les éléments CanonicalizationMethod identifiés dans cette spécification gardent les IT. Lorsqu'une IT fait partie d'un contenu qui est signé (par exemple, dans un élément SignedInfo ou dans des document XML référencés), toute modification de l'IT engendrera évidemment un échec de la signature.

5.4 Les commentaires dans les éléments Signature

Les commentaires XML ne sont pas utilisés par cette spécification.

À noter qu'à moins que l'élément CanonicalizationMethod ne supprime les commentaires d'un élément SignedInfo ou d'un quelconque document XML référencé (ce que réalise [XML-C14N]), ceux-ci seront signés. Par conséquent, s'ils sont gardés, une modification des commentaires entraînera un échec de la signature. De la même façon, la signature XML sur toutes données XML sera sensible aux modifications des commentaires, à moins qu'une méthode de canonisation/transformation ignorant les commentaires, comme pour le XML canonique [XML-C14N], ne soit spécifiée.

6.0 Les algorithmes

Cette section identifie les algorithmes utilisés dans la spécification de la signature digitale XML. Les entrées contiennent l'identifiant qui doit être utilisé dans les éléments Signature, une référence vers la spécification officielle et des définitions, quand cela s'applique, pour la représentation des clés et pour les résultats des opérations cryptographiques.

« errata 2002-01-29 »

6.1 Les identifiants d'algorithme et les exigences d'implémentation

Les algorithmes sont identifiés par des URI qui apparaîssent en tant qu'attribut de l'élément qui identifie le rôle de l'algorithme (DigestMethod, Transform, SignatureMethod ou CanonicalizationMethod). Tous les algorithmes utilisés dans cette spécification admettent des paramètres mais, dans de nombreux cas, les paramètres sont implicites. Par exemple, un élément SignatureMethod reçoit implicitement deux paramètres : les informations concernant les clés et le format de sortie de l'élément CanonicalizationMethod. Les paramètres explicites supplémentaires pour un algorithme apparaissent en tant qu'éléments de contenu dans l'élément de rôle de l'algorithme. Ces éléments de paramètres ont un nom d'élément descriptif, lequel est fréquemment spécifique à l'algorithme, et DOIVENT se trouver dans l'espace de nommage de la signature XML ou dans un espace de nommage d'algorithme spécifique.

Cette spécification définit un ensemble d'algorithmes, leurs URI et les exigences pour leurs implémentations. Les exigences sont spécifiées sur l'implémentation, non pas sur les conditions d'utilisation de la signature. En outre, le mécanisme est extensible ; des algorithmes alternatifs peuvent être utilisés par des applications de signature.

Le prétraitement [N.d.T. Digest]

1. L'algorithme SHA1 est requis
   http://www.w3.org/2000/09/xmldsig#sha1

L'encodage [N.d.T. Encoding]

1. L'algorithme base64 est requis
   http://www.w3.org/2000/09/xmldsig#base64

Le code MAC [N.d.T. MAC]

1. L'algorithme HMAC-SHA1 est requis
   http://www.w3.org/2000/09/xmldsig#hmac-sha1

La signature [N.d.T. Signature]

1. L'algorithme DSAwithSHA1 (DSS) est requis
   http://www.w3.org/2000/09/xmldsig#dsa-sha1
2. L'algorithme RSAwithSHA1 est recommandé
   http://www.w3.org/2000/09/xmldsig#rsa-sha1

La canonisation [N.d.T. Canonicalization]

1. La forme canonique XML (sans les commentaires) est requise
   http://www.w3.org/TR/2001/REC-xml-c14n-20010315
2. La forme canonique XML avec commentaires est recommandée
   http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments

La transformation [N.d.T. Transform]

1. La transformation XSLT est facultative
   http://www.w3.org/TR/1999/REC-xslt-19991116 vf.
2. La transformation XPath est recommandée
   http://www.w3.org/TR/1999/REC-xpath-19991116 vf.
3. La transformation de signature enveloppée* est requise
   http://www.w3.org/2000/09/xmldsig#enveloped-signature

* La transformation de signature enveloppée supprime l'élément Signature du calcul de la signature lorsque la signature se trouve dans le contenu qui est en train d'être signé. Ceci PEUT être implémenter via la spécification XPath RECOMMANDÉE, spécifiée dans la section 6.6.4 : « La transformation de signature enveloppée » ; elle DOIT avoir le même effet que celle spécifiée par la transformation XPath.

6.2 Les condensés des messages

Seul un algorithme de prétraitement est défini ici. Cependant, on prévoit qu'un ou plusieurs algorithmes de prétraitement fort supplémentaires soient développés en rapport avec l'effort du standard de chiffrement avancé des États-Unis. L'utilisation de MD5 [MD5] N'EST PAS RECOMMANDÉE en raison du fait que des récentes avancées dans l'analyse cryptographique ont jeté le doute sur sa force.

6.2.1 SHA-1

Identifiant :

http://www.w3.org/2000/09/xmldsig#sha1

L'algorithme SHA-1 [SHA-1] n'admet aucun paramètre explicite. Un exemple d'un élément d'algorithme de prétraitement SHA-1 est :

<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>

un condensé SHA-1 est une chaîne de caractères de 160 bits. Le contenu de l'élément DigestValue doit être l'encodage en base64 de cette chaîne de bits vue comme un flux d'octets de 20 octets. Par exemple, l'élément DigestValue pour le condensé de message :

   A9993E36 4706816A BA3E2571 7850C26C 9CD0D89D

cette valeur provenant de l'annexe A du standard SHA-1 serait :

   <DigestValue>qZk+NkcGgWq6PiVxeFDCbJzQ2J0=</DigestValue>

6.3 Les codes d'authentification de message [N.d.T. Message Authentication Code]

Les algorithmes MAC admettent deux paramètres implicites : leur matériel de gestion de clé déterminé à partir de KeyInfo et le flux d'octets de sortie de l'élément CanonicalizationMethod. Les algorithmes MAC et les algorithmes de signature sont syntaxiquement identiques mais un algorithme MAC fait intervenir une clé secrète partagée.

6.3.1 L'algorithme HMAC

Identifiant :

http://www.w3.org/2000/09/xmldsig#hmac-sha1

L'algorithme HMAC (RFC2104 [HMAC]) utilise la longueur de troncature en bits comme paramètre ; si le paramètre n'est pas spécifié, alors tous les bits de la valeur de hachage seront des bits de sortie. Voici un exemple d'élément SignatureMethod HMAC :

   <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1">
      <HMACOutputLength>128</HMACOutputLength>
   </SignatureMethod>

La valeur de sortie de l'algorithme HMAC est finalement la valeur de sortie (potentiellement tronquée) de l'algorithme de prétraitement choisi. Cette valeur devrait être codée en base64 de la même manière que la valeur de sortie des algorithmes de prétraitement. Exemple : l'élément SignatureValue pour le condensé HMAC-SHA1

   9294727A 3638BB1C 13F48EF8 158BFC9D

cette valeur à partir des vecteurs de test dans [HMAC] devrait être

   <SignatureValue>kpRyejY4uxwT9I74FYv8nQ==</SignatureValue>

   Définition de schéma :

   <simpleType name="HMACOutputLengthType">
     <restriction base="integer"/>
   </simpleType>

   DTD :

   <!ELEMENT HMACOutputLength (#PCDATA)>

6.4 Les algorithmes de signature

Les algorithmes de signature admettent deux paramètres implicites : leur matériel de gestion de clé déterminé à partir de l'élément KeyInfo et le flux d'octets de sortie de l'élément CanonicalizationMethod. Les algorithmes de signature et les codes MAC sont syntaxiquement identiques mais une signature fait intervenir une cryptographie à clé publique.

6.4.1 L'algorithme DSA

Identifiant :

http://www.w3.org/2000/09/xmldsig#dsa-sha1

L'algorithme DSA [DSS] n'admet aucun paramètre explicite. Voici un exemple d'élément SignatureMethod DSA :

   <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"/>

La valeur de sortie d'un algorithme DSA est constituée d'une paire de valeurs entières désignée habituellement par (r, s). La valeur de la signature est constituée de deux flux d'octets concaténés et codés en base64 qui sont le résultat de l'encodage respectif des valeur r et s. La conversion d'un type entier en un flux d'octets doit se faire selon l'opération I2OSP, définie dans la spécification RFC 2437 [PKCS1], avec un paramètre l égal à 20. Par exemple, l'élément SignatureValue pour une signature DSA (r, s) avec des valeurs spécifiées en héxadécimal :

   r = 8BAC1AB6 6410435C B7181F95 B16AB97C 92B341C0 
   s = 41E2345F 1F56DF24 58F426D1 55B4BA2D B6DCD8C8

ces valeurs provenant de l'exemple dans l'annexe 5 du standard DSS devrait être :

   <SignatureValue>
   i6watmQQQ1y3GB+VsWq5fJKzQcBB4jRfH1bfJFj0JtFVtLotttzYyA==</SignatureValue>

6.4.2 L'algorithme PKCS1 (RSA-SHA1)

Identifiant :

http://www.w3.org/2000/09/xmldsig#rsa-sha1

L'expression « algorithme RSA » utilisée dans ce brouillon se réfère à l'algorithme RSASSA-PKCS1-v1_5, décrit dans RFC 2437 [PKCS1]. L'algorithme RSA n'admet aucun paramètre explicite. Voici un exemple d'élément SignatureMethod RSA :

   <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>

Le contenu d'un élément SignatureValue pour une signature RSA est l'encodage en base64 [MIME] d'une chaîne d'octets calculée selon RFC 2437 [PKCS1, section 8.1.1 : La génération de la signature pour le schéma de signature RSASSA-PKCS1-v1_5]. Comme spécifié dans la fonction EMSA-PKCS1-V1_5-ENCODE de RFC 2437 [PKCS1, section 9.2.1], la valeur d'entrée pour la fonction de signature DOIT contenir en ajout initial un identifiant objet d'algorithme pour la fonction de hachage, mais la disponibilité d'un analyseur ASN.1 et la reconnaissance des données d'identifiant d'objet [N.d.T. OID] ne sont pas requis pour vérifier la signature. La représentation PKCS#1 v1.5 apparaît comme suit :

   CRYPT (PAD (ASN.1 (OID, DIGEST (data))))

À noter que le code ASN.1 rempli sera de la forme suivante :

   01 | FF* | 00 | prefix | hash

où "|" représente la concaténation, "01", "FF" et "00" sont des octets fixés de la valeur héxadécimale correspondante, "hash" est le codensé SHA1 des données et "prefix" est le préfixe désignant l'algorithme ASN.1 BER SHA1 requis dans PKCS1 [RFC2437], qui est,

   hex 30 21 30 09 06 05 2B 0E 03 02 1A 05 00 04 14

Ce préfixe est ajouté pour faciliter l'utilisation des librairies cryptographiques standards. L'octet FF DOIT être répété un nombre maximal de fois de sorte que la valeur de la quantité étant CRYPTÉE soit plus courte d'un octet que le module RSA.

La chaîne de caractères en base64 [MIME] résultante est la valeur du nœud texte fils de l'élément SignatureValue, par exemple :

<SignatureValue>
IWijxQjUrcXBYoCei4QxjWo9Kg8D3p9tlWoT4t0/gyTE96639In0FZFY2/rvP+/bMJ01EArmKZsR5VW3rwoPxw=
</SignatureValue>

6.5 Les algorithmes de canonisation [N.d.T. Canonicalization Algorithms]

Quand une opération de canonisation est réalisée sur des octets, les algorithmes de canonisation admettent deux paramètres implicites : le contenu et son jeu de caractères. Le jeu de caractères est obtenu à partir des règles des protocoles de transport et des types de média (par exemple, RFC2376 [XML-MT] définit les types de média pour XML). Cette information est nécessaire pour signer et vérifier correctement les documents et requiert souvent une configuration soignée côté serveur.

Divers algorithmes de canonisation requièrent la conversion en [UTF-8]. Les deux algorithmes ci-dessous comprennent au moins [UTF-8] et [UTF-16] en encodage d'entrée. Nous RECOMMANDONS que les algorithmes spécifiées de manière externe fassent de même. La connaissance d'autres types d'encodage est FACULTATIVE.

Divers algorithmes de canonisation transcodent d'un encodage non Unicode vers Unicode. Les deux algorithmes ci-dessous effectuent une normalisation de texte durant le transcodage [NFC, NFC-Corrigendum]. Nous RECOMMANDONS que les algorithmes de canonisation spécifiés de manières externe fassent de même. (À noter qu'il peut y avoir des ambiguïtés au cours de la conversion des jeux de caractères existants vers Unicode ; pour avoir un exemple, voir la note sur le profil Japonais XML [XML-Japanese].)

« errata 2002-03-30 »

6.5.1 Le XML canonique [N.d.T. Canonical XML]

L'identifiant pour le XML canonique REQUIS (sans commentaires) :

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

L'identifiant pour le XML canonique avec commentaires :

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

Voici un exemple d'élément de canonisation XML :

   <CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>

La spécification normative du XML canonique est [XML-C14N]. L'algorithme est capable d'utiliser en entrée soit un flux d'octets, soit un ensemble de nœuds XPath (ou une solution fonctionnelle alternative suffisante.) L'algorithme produit un flux d'octets en sortie. Le XML canonique est facilement paramètrable (via un URI supplémentaire) pour omettre ou garder les commentaires.

6.6 Les algorithmes de l'élément Transform

Un algorithme de l'élément Transform possède un unique paramètre implicite : un flux d'octets provenant d'un élément Reference ou une valeur de sortie d'un précédent élément Transform.

Les développeurs d'application sont fortement encouragés à gérer toutes celles des transformations listées dans cette section comme étant RECOMMANDÉES, à moins que l'environnement de l'application ne dispose de ressources restreintes qui rendraient une telle gestion peu réaliste. Une conformité avec cette recommandation maximisera l'interopérabilité des applications et des librairies devraient être disponibles pour permettre la gestion de ces transformations dans les applications sans coût de développement prohibitif.

6.6.1 La canonisation [N.d.T. Canonicalization]

Tout algorithme de canonisation qui peut être utilisé par l'élément CanonicalizationMethod (tels que ceux qui se trouvent dans « Les algorithmes de canonisation » (section 6.5)) peut être utilisé dans un élément Transform.

6.6.2 La transformation Base64

Identifiant :

http://www.w3.org/2000/09/xmldsig#base64

La spécification normative pour les transformations de décodage en base64 est [MIME]. L'élément Transform en base64 n'a pas de contenu. L'entrée est décodée par les algorithmes. Cette transformation est utile si une application à besoin de signer les données brutes associées au contenu codé d'un élément.

Cette transformation requiert un flux d'octets en entrée. Si un ensemble de nœuds XPath (ou une solution fonctionnelle alternative suffisante) est donné en entrée, alors il sera converti en flux d'octets par des opérations de traitement logiquement équivalente à 1) l'application d'une transformation Xpath avec l'expression self::text(), puis 2) l'utilisation de la valeur chaîne de caractères de l'ensemble de nœuds. Ainsi, quand un élément XML est identifié par un nom nu XPointer dans l'URI d'un élément Reference et quand son contenu n'est constitué que de données textuelles codées en base64, alors cette transformation supprimera automatiquement les balises de début et de fin de l'élément identifié et tous ses éléments descendants, ainsi que tous les commentaires et instructions de traitement éventuels des descendants. La valeur de sortie de cette transformation est un flux d'octets.

6.6.3 Le filtrage XPath [N.d.T. XPath Filtering]

Identifiant :

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

La spécification normative pour l'évaluation d'une expression XPath se trouve à [XPath]. L'expression XPath qui doit être évaluée apparaît en tant que contenu de caractères d'un élément paramètre de transformation enfant appelé XPath.

La valeur d'entrée requise par cette transformation est un ensemble de nœuds XPath. À noter que si l'entrée en question est un ensemble de nœuds XPath issu de la résolution d'un URI nul ou d'un nom nu XPointer, alors les nœuds de commentaires auront été omis. Si la valeur d'entrée en question est un flux d'octets, alors l'application DEVRA convertir le flux d'octets en un ensemble de nœuds XPath convenable pour être utilisé par le XML canonique avec commentaires. (Une application subséquente de l'algorithme XML canonique REQUIS supprimerait commentaires.) En d'autre termes, l'ensemble de nœuds en entrée devrait être équivalent à celui qui serait créé par le traitement suivant :

1. Initialiser un contexte d'évaluation XPath en réglant le nœud initial comme étant égal au nœud racine du document XML en entrée et fixer la position et la taille du contexte à 1 ;
2. Évaluer l'expression XPath (//. | //@* | //espace de nommage::*).

L'évaluation de cette expression inclut tous les nœuds du document (y compris les commentaires) dans l'ensemble de nœuds représentant le flux d'octets.

La sortie de la transformation est également un ensemble de nœuds XPath. L'expression XPath apparaissant dans le paramètre XPath est évaluée une fois pour chaque nœud dans l'ensemble de nœuds d'entrée. Le résultat est converti en un booléen. Si le booléen est vrai, alors le nœud est inclus dans l'ensemble de nœuds de sortie. Si le booléen est faux, alors le nœud en est omis.

Note : Même si l'ensemble de nœuds en entrée avait vu ses commentaires supprimés, les nœuds de commentaires existent toujours dans l'arbre d'analyse sous-jacent et peuvent séparer les nœuds de texte. Par exemple, le balisage <e>Bonjour <!-- commentaire -->tout le monde !</e> contient deux nœuds de texte. Donc, l'expression self::text()[string()="Bonjour tout le monde !"] échouerait. Si le problème survient dans l'application, il peut être résolu soit en canonisant le document avant la transformation XPath pour supprimer physiquement les commentaires, soit en filtrant le nœud en fonction de la valeur chaîne de caractères de l'élément parent. (Par exemple, en utilisant l'expression self::text()[string(parent::e)="Bonjour tout le monde !"]).

L'objectif principal de cette transformation est de garantir que seuls les changement spécifiquement définis du document en entrée sont permis après que la signature est apposée. Ceci est réalisé en omettant précisement les nœuds qui sont autorisés à changer une fois la signature apposée et en incluant tous les autres nœuds d'entrée dans la sortie. C'est la responsabilité de l'auteur de l'expression XPath d'inclure tous les nœuds dont les changements pourraient affecter l'interprétation de la sortie de la transformation dans le contexte de l'application.

« errata 2002-01-29 »

Un scénario d'importance interviendrait pour un document requérant deux signatures enveloppées. Chaque signature doit s'omettre elle-même de ses propres calculs de prétraitement, mais il est également nécessaire d'exclure le second élément de signature du calcul de prétraitement de la première signature, pour que l'ajout de la seconde signature ne casse pas la première signature.

La transformation XPath établit le contexte d'évaluation suivant, pour chaque nœud de l'ensemble de nœuds d'entrée :

• Un nœud de contexte égal à un nœud de l'ensemble de nœuds d'entrée ;
• Une position de contexte, initialisée à 1 ;
• Une taille de contexte, initialisée à 1 ;
• Une librairie de fonctions égale à l'ensemble des fonctions, défini dans [XPath], plus une fonction appelée here ;
• Un ensemble de variables de corrélation. Aucun moyen pour les initialiser n'est défini. Donc, l'ensemble de variables de corrélation utilisé, lorsque l'expression XPath est évaluée, est vide et utiliser un appel de variable dans l'expression provoque une erreur ;
• L'ensemble des déclarations d'espace de nommage dans la portée de l'expression XPath.

En résultat de l'établissement du nœud de contexte, les expressions XPath apparaissant dans cette transformation seront presque similaires à celles utilisées dans [XSLT], sauf que la taille et la position sont toujours de 1 pour refléter le fait que la transformation visite automatiquement chaque nœud (dans la transformation XSLT, on appelle récursivement la commande apply-templates pour visiter les nœuds de l'arbre d'entrée).

La fonction here() est définie de la manière suivante :

Fonction : ensemble de nœuds here()

La fonction here retourne un ensemble de nœuds contenant le nœud d'attribut, ou d'instruction de traitement, ou l'élément parent du nœud de texte qui porte directement l'expression XPath. Cette expression renvoie une erreur si l'expression XPath englobante n'apparaît pas dans le même document XML par rapport auquel l'expression XPath est évaluée.

Comme exemple, on considère la création d'une signature enveloppée (un élément Signature qui est le descendant d'un élément en cours de signature). Bien que le contenu signé ne devrait pas changer après la signature, les élément dans l'élément Signature changent (par exemple, la valeur prétraitée doit être mise dans un élément DigestValue et l'élément SignatureValue doit être calculé ensuite). Une manière pour empêcher ces changements d'invalider la valeur prétraitée dans l'élément DigestValue est d'ajouter un élément Transform XPath qui omet tous les éléments de l'élément Signature et leurs descendants. Par exemple :

   <Document>
   ...   
   <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
     <SignedInfo>
      ...
       <Reference URI="">
         <Transforms>
           <Transform Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116">
             <XPath xmlns:dsig="&dsig;">
             not(ancestor-or-self::dsig:Signature)
             </XPath>
           </Transform>
         </Transforms>
         <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
         <DigestValue></DigestValue>
       </Reference>
     </SignedInfo>
     <SignatureValue></SignatureValue>
    </Signature>
    ...
   </Document>

Du fait de l'URI nul de l'élément Reference dans cet exemple, l'ensemble de nœuds d'entrée de la transformation XPath contient tous les nœuds dans l'arbre d'analyse entier commençant par le nœud racine (sauf les nœuds de commentaires). Pour chaque nœud dans cet ensemble de nœuds, celui-ci est inclus dans l'ensemble de nœuds de sortie sauf si le nœud, ou l'un de ses éléments de niveau supérieur possède une balise de l'élément Signature qui se trouve dans l'espace de nommage donné par le texte de remplacement pour l'entité &dsig;.

Une solution plus élégante utilise la fonction here pour omettre uniquement l'élément Signature contenant la transformation XPath et, ainsi, permettre aux signatures enveloppées de signer d'autres signatures. Dans l'exemple ci-dessus, on utilise l'élément XPath :

   <XPath xmlns:dsig="&dsig;">
   count(ancestor-or-self::dsig:Signature |
   here()/ancestor::dsig:Signature[1]) >
   count(ancestor-or-self::dsig:Signature)</XPath>

Étant donné que l'opérateur d'égalité XPath convertit les ensembles de nœuds en valeur de chaîne de caractères avant la comparaison, nous devons plutôt utiliser l'opérateur d'union XPath (|). Pour chaque nœud du document, l'expression de prédicat est vraie si et seulement si l'ensemble de nœuds et ses éléments Signature de niveau supérieur n'incluent pas l'élément Signature enveloppé contenant l'expression XPath (l'union ne produit pas un ensemble plus large si l'élément Signature enveloppé est dans l'ensemble de nœuds donné par ancestor-or-self::Signature).

6.6.4 La transformation de signature enveloppée

Identifiant :

http://www.w3.org/2000/09/xmldsig#enveloped-signature

Une transformation T de signature enveloppée supprime l'élément Signature entier, contenant T, du calcul du condensé de l'élément Reference qui contient T. La chaîne de caractères entière utilisée par le processeur XML pour faire concorder l'élément Signature avec la production de l'élément XML est supprimée. La sortie de la transformation est équivalente à celle qui aurait résulté du remplacement de T par une transformation XPath contenant l'élément de paramètre XPath suivant :

   <XPath xmlns:dsig="&dsig;">
   count(ancestor-or-self::dsig:Signature |
   here()/ancestor::dsig:Signature[1]) >
   count(ancestor-or-self::dsig:Signature)</XPath>

Les conditions d'entrée et de sortie de cette transformation sont identiques à celles de la transformation XPath, mais elles ne peuvent s'appliquer que sur un ensemble de nœuds provenant de son document XML parent. À noter qu'il n'est pas nécessaire d'utiliser un opérateur d'évaluation d'expression XPath pour créer cette transformation. Cependant, cette transformation DOIT exactement produire la sortie de la même manière que la transformation XPath paramétrée par l'expression XPath ci-dessus.

6.6.5 La transformation XSLT

Identifiant :

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

La spécification normative pour les transformations XSL se trouve à [XSLT]. La spécification d'un élément de feuille de style avec un espace de nommage qualifié, qui DOIT être l'unique enfant de l'élément Transform, indique que la feuilles de style spécifiée devrait être utilisée. C'est le modèle de traitement XSLT qui détermine si cette spécification instancie, ou non, le traitement en-ligne des déclarations XSLT locales ; l'application ordonnée de multiples feuilles de style peut requérir plusieurs éléments Transforms. Aucune réserve particulière n'est faite pour l'identification d'une feuille de style distante localisée par un URI donné,car cette transmission peut avoir lieu via un élément xsl:include vf. ou un élément xsl:import vf. dans l'élément enfant stylesheet de l'élément Transform.

Cette transformation requiert un flux d'octets en entrée. Si la valeur d'entrée en question est un ensemble de nœuds XPath, alors l'application de la signature devrait tenter de convertir celui-ci en octets (appliquer le XML canonique]), comme décrit dans « Le modèle de traitement des références » (section 4.3.3.2).

La sortie de cette transformation est un flux d'octets. Les règles de traitement pour la feuille de style ou l'élément de transformation XSL sont définies dans la spécification XSLT [XSLT]. Nous RECOMMANDONS que les auteurs de transformations XSLT utilisent une méthode de sortie xml pour XML et HTML. Comme les implémentations XSLT ne produisent pas de sérialisations cohérentes en sortie, nous RECOMMANDONS de surcroît l'insertion d'une transformation après la transformation XSLT pour canoniser la sortie. Ces étapes aideront à garantir l'interopérabilité des signatures résultantes entre les applications qui gèrent les transformation XSLT. À noter que si la sortie est en fait au format HTML, alors le résultat de ces étapes est logiquement équivalent à du [XHTML].

7.0 Considérations sur la canonisation XML et sur les contraintes syntaxiques

Les signatures digitales fonctionnent uniquement si les calculs de vérification sont réalisés sur exactement les même bits que les calculs de signature. Si la représentation de surface des données signées peut changer entre la signature et la vérification, alors une certaine façon de standardiser cet aspect variable doit être utilisée avant la signature et la vérification. Par exemple, même pour un texte ASCII simple, il y a au moins trois séquences de fin de lignes qui sont largement utilisées. S'il est possible pour un texte signé d'être modifié, d'une convention de fin de ligne à une autre, entre le moment de la signature et de la vérification de celle-ci, alors les fins de lignes auront besoin d'être canonisées sous une forme standard avant la signature et la vérification, sinon la signature échouera.

XML est susceptible de changements de la représentation de surface et de traitements qui abandonnent des informations de surface. Pour cette raison, les signature digitales XML ont un dispositif pour indiquer des méthodes de canonisation dans la signature, pour que le vérificateur puisse utiliser la même canonisation que le signataire.

Tout au long de cette spécification, nous faisons une distinction entre la canonisation d'un élément Signature et les autres objets de données XML signés. Il est possible pour un document XML isolé d'être traité comme s'il s'agissait de données binaires, de qu'aucun changement ne puisse survenir. Dans ce cas, le condensé du document ne changera pas et il n'aura pas besoin d'être canonisé s'il est signé et vérifié comme tel. Cependant, le XML qui est lu et traité en utilisant des techniques d'analyse et de traitement XML standards est fréquemment altéré de telle manière que certaines de ses informations de représentation de surface soient perdues ou modifiées. En particulier, ceci se produit dans beaucoup de cas pour l'élément Signature et les éléments SignedInfo qui y sont contenus puisque ceux-ci, comme éventuellement le document XML englobant, seront traités comme du XML.

De la même façon, ces considérations s'appliquent aux éléments Manifest, Object et SignatureProperties, quand ces élément ont été prétraités, que leur élément DigestValue doit être vérifié et qu'ils sont traités comme du XML.

Les types de changements en XML, qui peuvent avoir besoin d'être canonisés, se répartissent en quatre catégories. Il y a ceux liés au [XML] basique, comme décrit dans la section 7.1 ci-dessous. Il y a ceux liés à [DOM], [SAX] ou à des traitements similaires, comme décrit dans la section 7.2 ci-dessous. Troisièmement, il y a la possibilité de convertir un ensemble de caractères codés, telle que la conversion entre UTF-8 et UTF-16, dont tous les processeurs conformes à [XML] sont tenus de gérer toutes deux, qui est décrite dans le paragraphe immédiatement ci-après. Et quatrièmement, il y a les changements liés à la déclaration de l'espace de nommage et au contexte d'attribut de l'espace de nommage XML, comme décrit dans la section 7.3 ci-dessous.

Tout algorithme de canonisation devrait produire une sortie dans un jeu de caractères codé, fixe et spécifique. Tous les algorithmes de canonisation identifiés dans ce document utilisent l'encodage UTF-8 (sans marque d'ordre d'octet (BOM)) et ils ne fournissent pas de normalisation des caractères. Nous RECOMMANDONS que les applications de signature créent le contenu XML (les éléments Signature et leur(s) descendant(s)/contenu) dans la forme de normalisation C [NFC, NFC-Corrigendum] et vérifient que tout XML en cours de consommation soit aussi dans cette forme (si ce n'est pas le cas, la validation des signatures peut de fait échouer). De plus, aucun de ces algorithmes ne fournit une normalisation des types de données. Les applications qui normalisent les types de données dans divers formats (par exemple, (vrai, faux) ou (1,0)) peuvent se trouver incapables de valider leurs signatures réciproques.

7.1 XML 1.0, les contraintes syntaxiques et la canonisation

XML 1.0 [XML] définit une interface où une application conforme lisant un document XML reçoit certaines informations de ce document XML et aucune autre informations. En particulier :

1. les fins de lignes sont normalisées au seul caractère #xA, en écartant les caractères #xD s'ils sont immédiatement suivis par un #xA et en les remplaçant par #xA dans tous les autres cas ;
2. les attributs manquants déclarés pour avoir des valeurs par défaut sont fournis à l'application comme s'ils étaient présents avec leur valeur par défaut ;
3. les références de caractère sont remplacées par les caractères correspondants ;
4. les références d'entité sont remplacées par les entités déclarées correspondantes ;
5. les valeurs des attributs sont normalisées :
   1. en remplaçant les références de caractère et d'entité comme ci-dessus ;
   2. en remplaçant les occurrences de #x9, #xA et #xD par #x20 (espace), sauf pour la séquence #xD#xA qui est remplacée par un unique espace et ;
   3. si l'attribut n'est pas déclaré comme étant type CDATA, on supprime tous les espaces de début et de fin et on remplace toutes les séquences d'espaces intermédiaires par un unique espace.

À noter que les points (2), (4), et (5.3) dépendent de la présence d'un schéma, d'une DTD ou de déclarations similaires. Le type de l'élément Signature est un schéma valide relâché [XML-schema], par conséquent un code XML externe ou même un code XML dans le même document que la signature peut être (uniquement) bien formé ou provenir d'un autre espace de nommage (où le schéma de la signature le permet) ; les points notés peuvent ne pas être présents. Ainsi, une signature avec un tel contenu ne sera vérifiable par d'autres applications de signature que si les contraintes syntaxiques suivantes sont observées lors de la génération d'un quelconque matériel signé incluant l'élément SignedInfo, à savoir :

1. que les attributs ayant des valeurs par défaut soient explicitement présents ;
2. que toutes les références d'entité (sauf "amp", "lt", "gt", "apos", "quot" et les autres entités de caractères non représentables pour l'encodage choisi) soient résolues ;
3. que les blancs des valeurs des attributs soient normalisés.

7.2 Les traitements DOM/SAX et la canonisation

En plus de la canonisation et des contraintes syntaxiques décrites ci-dessus, de nombreuses applications XML utilisent le modèle objet de document [DOM] ou l'API simple pour XML [SAX]. DOM traduit le XML en une structure arborescente de nœuds et suppose que celui-ci sera utilisé sur un document entier avec des traitements subséquents fait sur l'arbre. SAX convertit le XML en une série d'événements tels qu'une balise ouvrante, un contenu, etc. Dans l'un ou l'autre cas, de nombreuses caractéristiques de surface tels que l'ordre des attributs et les espaces non-significatifs entre les balises ouvrantes et fermantes seront perdus. De plus, les déclarations des espaces de nommage sont affectées sur les nœuds auxquelles ils s'appliquent, en perdant les préfixes d'espace de nommage du texte source, et, dans la plupart des cas, en perdant les endroits où les déclarations d'espace de nommage apparaissaient dans l'instance originale.

Si une signature XML doit être produite et vérifiée sur un système utilisant un traitement DOM ou SAX, une méthode canonique est nécessaire pour sérialiser la partie concernée de l'arbre DOM ou la séquence d'événements SAX. Les spécifications de canonisation XML, telle que [XML-C14N], sont basées uniquement sur les informations qui sont gardées par DOM et SAX. Pour qu'une signature XML soit vérifiable par une implémentation utilisant DOM ou SAX, les contraintes syntaxiques XML 1.0 citées dans la section précédente doivent non seulement être suivies mais une canonisation XML DOIT aussi être spécifiée pour que le vérificateur puisse sérialiser de nouveau l'entrée transformée par DOM/SAX dans le même flux d'octets qui a été signé.

7.3 Le contexte de l'espace de nommage et les signatures portables

Dans [XPath] et par conséquent dans le modèle de données XML canonique, un élément possède des nœuds d'espace de nommage qui correspondent aux déclarations dans l'élément et dans ses éléments de niveau supérieur :

« Note : Un élément E possède des nœuds d'espace de nommage qui représentent ses déclarations d'espace de nommage ainsi que toutes celles des éventuelles déclarations d'espace de nommage faites par ses éléments de niveau supérieur qui n'ont pas été annulées dans les déclarations de E, l'espace de nommage par défaut, s'il n'est pas vide, et la déclaration du préfixe xml ». [XML-C14N]

Lorsque qu'on sérialise un élément Signature ou des données XML signées qui sont enfants d'autres éléments employant ces modèles de données, cet élément Signature et ses enfants peuvent contenir des déclarations d'espace de nommage provenant du contexte de leur ancêtre. De plus, les algorithmes de XML canonique et de XML canonique avec commentaires importent tous les attributs d'espace de nommage xml (tel que xml:lang) de l'élément de niveau supérieur le plus proche dans lequel ils sont déclarés sur le nœud premier du XML canonisé, à moins qu'ils ne soient déjà déclarés pour ce nœud. Ceci peut frustrer le signataire dans son intention de créer une signature dans un contexte donné qui reste valide dans un autre. Par exemple, soit une signature enfant de B et petit-enfant de A :

   <A xmlns:n1="&foo;">
     <B xmlns:n2="&bar;">
       <Signature xmlns="&dsig;">   ...
         <Reference URI="#signme"/> ...
       </Signature>
       <C ID="signme" xmlns="&baz;"/>
     </B>
   </A>

Lorsque l'élément B ou bien l'élément C signé sont déplacés dans une enveloppe [SOAP] pour le transport :

   <SOAP:Envelope xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/">
     ...
     <SOAP:Body>
       <B xmlns:n2="&bar;">
         <Signature xmlns="&dsig;">
           ...
         </Signature>
         <C ID="signme" xmlns="&baz;"/>
       </B>
     </SOAP:Body>
   </SOAP:Envelope>

La forme canonique de la signature dans ce contexte contiendra de nouvelles déclarations d'espace de nommage provenant du contexte SOAP:Envelope, invalidant la signature. De plus, la forme canonique n'aura plus les déclarations d'espace de nommage qu'elle aurait initialement tirées du contexte de l'élément A, invalidant également la signature. Pour éviter ces problèmes, l'application peut :

1. Compter sur l'application enveloppante pour distinguer correctement son corps (la signature en charge utile) du contexte (l'enveloppe), avant que la signature ne soit validée, ou ;
2. Utiliser une méthode de canonisation qui « repousse/exclut » plutôt que « qui attire » le contexte d'un ancêtre. [XML-C14N] attire un tel contexte volontairement.

8.0 Considérations sur la sécurité

La spécification de la signature XML offre un mécanisme de signature digitale très souple. Les concepteurs doivent considérer avec soin les modèles de menaces de leurs applications et les facteurs suivants.

8.1 Les transformations

Une exigence de cette spécification est de permettre aux signatures de « s'appliquer sur tout ou partie d'un document XML ». (Voir [XML-Signature-RD, section 3.1.3].) Le mécanisme des éléments Transforms satisfait cette exigence en permettant à quelqu'un de signer des données provenant du traitement du contenu de la ressource identifiée. Par exemple, les applications qui souhaitent signer un formulaire, mais également permettre aux utilisateurs d'entrer des données limitées dans des champs de saisie, sans invalider une signature précédente du formulaire, pourraient utiliser [XPath] pour exclure les portions que l'utilisateur a besoin de modifier. Les éléments Transforms peuvent être arbitrairement spécifiés et peuvent inclure des transformations d'encodage, des instructions de canonisation ou même des transformations XSLT. On émet trois avertissements par rapport à cette fonctionnalité dans les sections suivantes.

À noter que le fonctionnement de la validation principale ne confirme pas que les données signées ont été obtenues en appliquant chaque étape des transformations indiquées. (Alors qu'il vérifie bien que le prétraitement du contenu resultant concorde avec celui spécifié dans la signature.) Par exemple, certaines applications peuvent se satisfaire en vérifiant une signature XML auprès d'une copie en cache de données déjà transformées. D'autres applications pourraient exiger que le contenu vienne d'être résolu et transformé.

8.1.1 Seul ce qui est signé est sûr

Tout d'abord, évidemment, les signatures sur un document transformé ne sécurise aucune information écartée par les transformations : seul ce qui est signé est sûr.

À noter que l'utilisation du XML canonique [XML-C14N] assure que toutes les entités et les espaces de nommage internes soient déployés dans le contenu en train d'être signé. Toutes les entités sont remplacées par leurs définitions et la forme canonique représente explicitement l'espace de nommage dont un élément pourrait hériter. Les applications qui ne canonisent pas le contenu XML (spécialement l'élément SignedInfo) NE DEVRAIENT PAS utiliser d'entités internes et DEVRAIENT représenter l'espace de nommage explicitement dans le contenu devant être signé, puisqu'elles ne peuvent pas compter sur la canonisation pour effectuer ceci à leur place. De plus, les utilisateurs concernés par l'intégrité des définitions de types d'élément, associées à l'instance XML devant être signé, peuvent souhaiter signer ces définitions également (c.-à-d., le schéma, le DTD, la description en langage naturel associée à l'espace de nommage/l'identifiant).

Deuxièmement, une enveloppe contenant des informations signées n'est pas garantie par une signature. Par exemple, lorsqu'une enveloppe cryptée contient une signature, la signature ne protège pas l'authenticité ou l'intégrité des entêtes non signées de l'enveloppe ni sa forme cryptée, elle ne garantit que le texte plein effectivement signé.

8.1.2 Seul ce qui est « visible » devrait être signé

En outre, la signature sécurise toute information éventuelle introduite par la transformation : seul ce qui est « visible » (ce qui est présenté à l'utilisateur de manière visuelle, auditive ou autres) devrait être signé. Si la signature reflète le jugement ou le consentement d'un utilisateur (un mécanisme automatique ou une personne), alors il est normalement nécessaire de sécuriser aussi exactement que pratiquement les informations qui étaient présentées à cet utilisateur. À noter que ceci peut être accompli en signant littéralement ce qui était présenté, telles que les images à l'écran montrées à l'utilisateur. Cependant, ceci peut conduire à une manipulation des données plus complexe par un programme suivant. Au lieu de celà, on peut signer les données, quels que soient les filtres, lesfeuilles de style, le profil client ou les autres informations permettant d'agir sur leur présentation.

8.1.3 "Voir" ce qui est signé

Tout comme un utilisateur ne devrait signer que ce qu'il ou elle « voit », les personnes et mécanismes automatisés, qui entérinent la validité d'un document transformé sur la base d'une signature valide, devraient agir sur des données transformées (incluant la canonisation) et signées, et non pas sur les données pré-transformées originales. Cette recommandation s'applique aux transformations spécifiées dans la signature aussi bien que celles incluses dans le document lui-même. Par exemple, si un document XML comprend une feuillede style incorporée vf. [XSLT], c'est le document transformé qui devrait être présenté à l'utilisateur et signé. Pour être conforme à cette recommandation lorsqu'un document référence une feuille de style externe, le contenu de cette ressource externe devrait également être signé comme via l'élément Reference, sinon le contenu de la ressource externe pourrait changer, ce qui altère le document résultant sans invalider la signature.

Certaines applications pourraient agir sur des données originales ou intermédiaires mais devraient être extrêmement prudentes au sujet des possibles faiblesses introduites alors entre les données originales et les données transformées. C'est une décision de confiance, à propos du caractère et de la signification des transformations, qu'une application doit prendre avec précaution. Considérons un algorithme de canonisation qui normalise la casse des caractères (minuscule vers majuscule) ou la composition des caractères (de 'e et un accent' vers accentué'). Un malveillant pourrait introduire des changement qui sont normalisés et, de ce fait, inconséquents sur validité de la signature mais réels pour un processeur DOM. Par exemple, en changeant la casse d'un caractère, cela pourrait influencer le résultat d'une sélection XPath. Un risque sérieux est introduit si ce changement est normalisé pour la validation de la signature mais le processeur opère sur les données originales et renvoie un résultat différent de celui attendu.

Par conséquent :

• Tous les documents sur lesquels opèrent et que génèrent des applications de signature DOIVENT être dans la forme de normalisation [NFC, NFC-Corrigendum] (sinon des processeurs intermédiaires pourraient involontairement casser la signature) ;
• Les normalisations d'encodage NE DEVRAIENT PAS ÊTRE effectuées en tant que partie d'une transformation de signature ou (autrement dit), si une normalisation intervient, l'application DEVRAIT toujours « voir » (opérer sur) la forme normalisée.

8.2 Vérifier le modèle de sécurité

Cette spécification utilise des signatures à clé publique et des codes d'authentification avec hachage de clé. Ceux-ci ont des modèles de sécurité substantiellement différents. De plus, elle permet l'utilisation d'algorithmes, spécifiés par l'utilisateur, qui peuvent avoir d'autres modèles.

Avec les signatures à clé publique, toutes les parties peuvent détenir la clé publique et vérifier les signatures, alors que seules les parties avec la clé privée peuvent créer des signatures. Le nombre des détenteurs de la clé privée devrait être réduit et il serait même préférable qu'il n'y en ait qu'un. La confiance des vérificateurs dans la clé publique qu'ils utilisent et son lien à l'entité ou aux capacités représentées par la clé privée correspondante reste un problème important, généralement résolu par des certificats ou des systèmes d'autorisation en ligne.

Les codes d'authentification avec hachage de clé, basés sur des clés secrètes, sont typiquement bien plus efficace en termede puissance de calcul requise mais ils ont également pour caractéristique que tous les vérificateurs ont besoin d'être en possesion de la même clé que le signataire. Donc tout vérificateur peut contrefaire une signature.

Cette spécification accepte des algorithmes de signature fournis par des utilisateurs et des indicateurs pour la gestion de clés. De tels algorithmes peuvent avoir divers modèles de sécurité. Par exemple, les méthodes qui font appel à la biométrie dépendent habituellement d'une caractéristique physique de l'utilisateur autorisé qui ne peut pas changer, comme des clés publiques ou secrètes, et peuvent avoir des différences dans leur modèle de sécurité.

8.3 Les algorithmes, les longueurs de clés, les certificats, etc.

La force d'une signature particulière dépend de tous les maillons dans la chaîne de sécurité. Cela inclut la signature et les algorithmes de prétraitement utilisés, la force de la génération de la clé [RANDOM] et la taille de la clé, la sécurité de la clé et des mécanismes d'authentification du certificat et de distribution, la politique de validation de la chaîne de certification, la protection du traitement cryptographique contre les surveillances et les falsifications malveillantes, etc.

Les applications doivent faire très attention lors de l'exécution des divers algorithmes qui peuvent être spécifiés dans une signature XML et lors du traitement de tout « contenu exécutable » qui pourrait être fourni à ces algorithmes en paramètres, telles que des transformations XSLT. Les algorithmes spécifiés dans ce document seront généralement implémentés via une librairie de confiance, mais même ce genre de paramètres pervers pourraient causer des consommations en temps processeur et en mémoire inacceptables. Il faut faire encore plus attention avec les algorithmes définis par les applications.

La sécurité d'un système tout entier dépendra également de la sécurité et de l'intégrité de ses modes opératoires, de son personnel et du respect administratif de ces procédures. Tous les facteurs listés dans cette section sont importants pour la sécurité globale d'un système ; cependant, la plupart d'entre eux sont hors de l'objet de cette spécification.

9.0 Schéma, DTD, modèle de données et exemples valides

Une instance de schéma XML Signature

xmldsig-core-schema.xsd

Une instance de schéma XML valide basée sur le schéma/la DTD de la spécification [XML-Schema] du 20001024.

La DTD de XML Signature

xmldsig-core-schema.dtd

Un modèle de données RDF

xmldsig-datamodel-20000112.gif

Un exemple d'objet XML Signature

signature-example.xml

Un exemple XML fabriqué cryptographique qui inclut un contenu étranger et qui est valide par rapport au schéma, il utilise également un attribut schemaLocation pour faciliter le chargement automatisé du schéma et la validation.

Un exemple de signature XML avec RSA

signature-example-rsa.xml

Un exemple de signature XML avec des valeurs cryptographiques générées par Merlin Hughes et validées par Gregor Karlinger.

Un exemple de signature XML avec DSA.

signature-example-dsa.xml

Un exemple similaire au précédent mais avec DSA.

10.0 Définitions

Authentification, message

La propriété, en fonction d'un code d'authentification/une somme de contrôle, telle que les falsifications des données et de la somme de contrôle, de façon à introduire des modifications tout en préservant apparemment l'intégrité, sont toutes deux toujours détectées. « Une signature devrait identifier ce qui est signé, rendant impossible la falsification ou l'altération des propos signés ou de la signature sans détection. » [Les principes de la signature digitale, ABA].

Authentification, signataire

La propriété telle que l'identité du signataire est bien celle prétendue. « Une signature devrait désigner qui a signé le document, le message ou l'enregistrement, et sa production par une autre personne devrait être difficile sans autorisation ». [Les principes de la signature digitale, ABA] Note : l'authentification du signataire est du ressort de l'application (par exemple, la clé de signature correspond-elle réellement à une identité spécifique) qui est gérée par celle-ci, mais hors de l'objet de cette spécification.

Codes d'authentification (somme de contrôle protégée [N.d.T. Protected Checksum])

Valeur générée à partir de l'application d'une clé partagée sur un message via un algorithme cryptographique tel qu'il possède des propriétés d'authentification de message (et d'intégrité) mais pas d'authentification du signataire. L'équivalent d'une somme de contrôle protégée : « une somme de contrôle calculée pour un objet de données selon des moyens prévenant les attaques actives qui tenteraient de modifier la somme de contrôle pour la faire correspondre aux changements apportés sur l'objet-données ». [SEC]

Intégrité [N.d.T. Integrity]

« La propriété telle que les données n'ont pas été modifiées, détruites ou perdues de manière non autorisée ou accidentelle. » [SEC] Une simple somme de contrôle> peut déterminer l'intégrité à partir de changements fortuits dans les données ; l'authentification du message est similaire mais prévient également une attaque active pour altérer les données, laquelle consiste en l'introduction d'une modification dans la somme de contrôle de manière à la faire concorder avec les changements apportées aux données.

Noyau [N.d.T. Core]

La syntaxe et les traitements définis par cette spécification, dont la validation principale. Nous utilisons ce terme pour distinguer les autres sémantiques de balisage, de traitement et d'applications, de la nôtre.

Objet de données [N.d.T. Data Object] (Contenu/Document)

Les données effectives binaires/octets qui sont traitées (transformées, prétraitées ou signées) par une application -- fréquemment une entité HTTP [HTTP]. À noter que le nom propre Object désigne un élément XML spécifique. Occasionellement, nous nous référons à un objet de données comme au document ou contenu d'une ressource. Le terme contenu de l'élément est utilisé pour décrire les données entre ses balises ouvrantes et fermantes XML.[XML]. Le terme document XML est utilisé pour décrire les objets de données qui sont conformes à la spécification XML. [XML].

Object, l'élément

Un élément de signature XML dans lequel des données arbitraires (non-noyau) peuvent être placées. Un élément Object est simplement un type de données digitales (ou un document) qui peut être signé via un élément Reference.

Ressource

« Une ressource peut être tout ce qui possède une identité. Les exemples courants incluent un document éléctronique, une image, un service (par exemple, “le bulletin météo pour Los Angeles aujourd'hui”) et un ensemble d'autres ressources... La ressource est la relation conceptuelle vers une entité ou un ensemble d'entités, pas nécessairement vers l'entité qui correspond à cet relation, à une instance particulière dans le temps. Par conséquent, une ressource peut rester constante même si son contenu -- l'entité à laquelle elle correspond -- change dans le temps, pourvu que la relation conceptuel ne change pas au cours du traitement. » [URI] Pour éviter une collision du terme entity dans les spécifications d'URI et XML, nous utilisons les termes objet de données, contenu ou document pour se référer aux bits/octets en question sur lesquels une opération a lieu.

Signature

Formellement parlant, c'est une valeur générée à partir de l'application d'une clé privée sur un message via un algorithme cryptographique tel que celui-ci possède des propriétés d'integrité, d'authentification de message et/ou d'authentification du signataire. (Cependant, nous utilisons parfois le terme signature de manière génériquequand celui-ci englobe des valeurs de code d'authentification, mais nous faisons soigneusement la distinction lorsque c'est la propriété d'authentication de signataire qui est concernée par l'exposé.) Une signature peut être (non-exclusivement) décrite comme détachée, enveloppante ou enveloppée.

Signature, application

Une application qui implémente les parties OBLIGATOIRES (REQUISES/DOIVENT)) de cette spécifications ; ces conditions de conformité s'appliquent au fonctionnement de l'application, à la structure du type d'élément Signature et ses fils (incluant SignatureValue), et aux algorithmes spécifiés.

Signature détachée

La signature opère sur un contenu extérieur à l'élément Signature et peut être identifiée via un URI ou une transformation. Par conséquent, la signature est « détachée » du contenu qu'elle signe. Cette définition s'applique généralement à des objets de données distincts, mais elle inclut également l'instance dans laquelle résident l'élément Signature et l'objet de données, dans le même document XML, mais restant des éléments voisins.

Signature enveloppante

La signature opère sur un contenu se trouvant dans l'élément Object de la signature elle-même. L'élément Object (ou son contenu) est identifié via un élément Reference (via un identificateur de fragment d'URI ou une transformation).

Signature enveloppée

La signature opère sur le contenu XML qui contient la signature en tant qu'élément. Le contenu fournit l'élément racine. Evidemment, les signatures enveloppées doivent faire attention à ne pas inclure leur propre valeur dans le calcul de l'élément SignatureValue.

Somme de contrôle [N.d.T. Checksum]

« La valeur qui (a) est calculée par une fonction qui dépend du contenu de l'objet de données et (b) qui est stockée ou transmise en même temps que l'objet, dans le but de détecter des changements intervenus dans les données. » [SEC]

Transformation [N.d.T. Transform]

Le traitement des données à partir de leur source vers leur forme dérivée. Les transformation typiques incluent la canonisation XML, XPath et XSLT.

Validation principale [N.d.T. Validation, Core]

Les conditions du traitement principal de cette spécification nécessitant la validation de signature et la validation de référence de l'élément SignedInfo.

Validation de référence [N.d.T. Validation,Reference]

La valeur hachée du contenu identifié et transformé, spécifiée par l'élément Reference, correspond à celle de son élément DigestValue spécifié.

Validation de signature [N.d.T. Validation, Signature]

L'élément SignatureValue correspond au résultat du traitement de l'élément SignedInfo par les éléments CanonicalizationMethod et SignatureMethod, comme spécifié dans « La validation principale » (section 3.2).

Validation, confiance/application

L'application détermine que la sémantique associée à la signature est valide. Par exemple, une application peut valider l'estampille ou l'intégrité de la clé du signataire -- bien que ce comportement soit étranger au noyau [N.d.T. core] de cette spécification.

11.0 Références

ABA

Les principes de la signature digitale.
http://www.abanet.org/scitech/ec/isc/dsgfree.html

DOM

La spécification du modèle objet de document (DOM). Recommandation du W3C. V. Apparao, S. Byrne, M. Champion, S. Isaacs, I. Jacobs, A. Le Hors, G. Nicol, J. Robie, R. Sutor, C. Wilson, L. Wood. Octobre 1998.
http://www.w3.org/TR/1998/REC-DOM-Level-1-19981001/ vf.

DSS

FIPS PUB 186-2 . Le standard de la signature digitale (DSS). Département du Commerce des ÉUA/Institut National des Standards et des Technologies.
http://csrc.nist.gov/publications/fips/fips186-2/fips186-2.pdf

HMAC

RFC 2104. HMAC : Le hachage de clé pour l'authentification de messages. H. Krawczyk, M. Bellare, R. Canetti. Février 1997.
http://www.ietf.org/rfc/rfc2104.txt

HTTP

RFC 2616. Le protocole de transfert hypertexte -- HTTP/1.1. J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee. Juin 1999.
http://www.ietf.org/rfc/rfc2616.txt

KEYWORDS

RFC 2119. Mots-clés à utiliser dans les RFC pour indiquer les niveaux d'importance. S. Bradner. Mars 1997.
http://www.ietf.org/rfc/rfc2119.txt

LDAP-DN

RFC 2253. Le protocole d'accès aux annuaires allégés (v3) : représentation des chaîne de caractères UTF-8 des noms distingués. M. Wahl, S. Kille, T. Howes. Décembre 1997.
http://www.ietf.org/rfc/rfc2253.txt

MD5

RFC 1321. L'algorithme de prétraitement de message MD5. R. Rivest. Avril 1992.
http://www.ietf.org/rfc/rfc1321.txt

MIME

RFC 2045. Les extensions de message internet multi-objectifs - première partie : format du corps des messages internet. N. Freed & N. Borenstein. Novembre 1996.
http://www.ietf.org/rfc/rfc2045.txt

NFC

TR15, Les formes de normalisation Unicode. M. Davis, M. Dürst. Mise à jour 18 : Novembre 1999. http://www.unicode.org/unicode/reports/tr15/tr15-18.html.

NFC-Corrigendum

Errata de la normalisation. Le consortium Unicode. http://www.unicode.org/unicode/uni2errata/Normalization_Corrigendum.html.

PGP

RFC 2440. Le format de message OpenPGP. J. Callas, L. Donnerhacke, H. Finney, R. Thayer. Novembre 1998.
http://www.ietf.org/rfc/rfc2440.txt

RANDOM

RFC 1750. Recommandations pour l'aléatoire dans la sécurité. D. Eastlake, S. Crocker, J. Schiller. Décembre 1994.
http://www.ietf.org/rfc/rfc1750.txt

RDF

La spécification du schéma du cadre de description des ressources (RDF) version 1.0. Recommandation candidate au W3C. D. Brickley, R.V. Guha. Mars 2000.
http://www.w3.org/TR/2000/CR-rdf-schema-20000327/

La spécification du modèle et de la syntaxe du cadre de description des ressources (RDF). Recommandation du W3C. O. Lassila, R. Swick. Février 1999.
http://www.w3.org/TR/1999/REC-rdf-syntax-19990222/ vf.

1363

IEEE 1363: Les spécifications du standard pour la cryptographie à clés publiques. Août 2000.

PKCS1

RFC 2437. PKCS #1 : Les spécifications du chiffrement RSA version 2.0. B. Kaliski, J. Staddon. Octobre 1998.
http://www.ietf.org/rfc/rfc2437.txt

SAX

SAX : API simple pour XML. D. Megginson, et al. May 1998.
http://www.megginson.com/SAX/index.html

SEC

RFC 2828. Glossaire pour la sécurité sur Internet. R. Shirey. May 2000.
http://www.faqs.org/rfcs/rfc2828.html

SHA-1

FIPS PUB 180-1. Standard du hachage sécurisé. Département du commerce des É.U.A/Institut National des Standards et des Technologies.
http://csrc.nist.gov/publications/fips/fips180-1/fip180-1.txt

SOAP

Protocole d'accès objet simple (SOAP) version 1.1. Note du W3C. D. Box, D. Ehnebuske, G. Kakivaya, A. Layman, N. Mendelsohn, H. Frystyk Nielsen, S. Thatte, D. Winer. Mai 2001.

http://www.w3.org/TR/2000/NOTE-SOAP-20000508/

Unicode

Le consortium Unicode. Le standard Unicode.
http://www.unicode.org/unicode/standard/standard.html

UTF-16

RFC 2781. UTF-16, un encodage ISO 10646. P. Hoffman , F. Yergeau. Février 2000.
http://www.ietf.org/rfc/rfc2781.txt

UTF-8

RFC 2279. UTF-8, un format de transformation ISO 10646. F. Yergeau. Janvier 1998.
http://www.ietf.org/rfc/rfc2279.txt

URI

RFC 2396. Les identifiants de ressources uniformes (URI) : syntaxe générique. T. Berners-Lee, R. Fielding, L. Masinter. Août 1998.
http://www.ietf.org/rfc/rfc2396.txt

URI-Literal

RFC 2732. Le format des adresses littérales IPV6 dans les URL. R. Hinden, B. Carpenter, L. Masinter. Décembre 1999.

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

URL

RFC 1738. Les localisations de ressources uniformes (URL). T. Berners-Lee, L. Masinter, and M. McCahill. Décembre 1994.

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

URN

RFC 2141. La syntaxe URN. R. Moats. Mai 1997.
http://www.ietf.org/rfc/rfc2141.txt

RFC 2611. Les mécanismes de définition d'espace de nommage URN. L. Daigle, D. van Gulik, R. Iannella, P. Falstrom. Juin 1999.
http://www.ietf.org/rfc/rfc2611.txt

X509v3

Recommandation ITU-T X.509 version 3 (1997). « Technologie de l'information - interconnection des systèmes libres- Le modèle d'authentification des annuaires » ISO/IEC 9594-8:1997.

XHTML 1.0

XHTML(tm) 1.0 : Le langage de balisage hypertexte extensible. Recommandation du W3C. S. Pemberton, D. Raggett, et al. Janvier 2000.
http://www.w3.org/TR/2000/REC-xhtml1-20000126/ vf.

XLink

Le langage de lien XML (Xlink). Recommandation du W3C. S. DeRose, E. Maler, D. Orchard. Juin 2001.

http://www.w3.org/TR/2001/REC-xlink-20010627/

XML

Le langage de balisage extensible (XML) 1.0 (seconde édition). Recommandation du W3C. T. Bray, E. Maler, J. Paoli, C. M. Sperberg-McQueen. Octobre 2000.

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

XML-C14N

Le XML canonique [N.d.T. Canonical XML]. Recommandation du W3C. J. Boyer. Mars 2001.

http://www.w3.org/TR/2001/REC-xml-c14n-20010315
http://www.ietf.org/rfc/rfc3076.txt

XML-Japanese

Le profil japonais XML. Note du W3C. M. Murata Avril 2000 http://www.w3.org/TR/2000/NOTE-japanese-xml-20000414/

XML-MT

RFC 2376 . Les types de média XML. E. Whitehead, M. Murata. Juillet 1998.
http://www.ietf.org/rfc/rfc2376.txt

XML-ns

Les espaces de nommage dans XML. Recommandation du W3C. T. Bray, D. Hollander, A. Layman. Janvier 1999.

http://www.w3.org/TR/1999/REC-xml-names-19990114 vf.

XML-schema

XML Schema tome 1 : les structures. Recommandation du W3C. D. Beech, M. Maloney, N. Mendelsohn, H. Thompson. Mai 2001.

http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/ vf.
XML Schema tome 2 : les types de données. Recommandation du W3C. P. Biron, A. Malhotra. Mai 2001.

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

XML-Signature-RD

RFC 2807. Les exigences pour XML Signature. Avant-projet du W3C. J. Reagle, Avril 2000.
http://www.w3.org/TR/1999/WD-xmldsig-requirements-19991014
http://www.ietf.org/rfc/rfc2807.txt

XPath

Le langage de chemin XML (XPath) Version 1.0. Recommandation du W3C. J. Clark, S. DeRose. Octobre 1999.
http://www.w3.org/TR/1999/REC-xpath-19991116 vf.

XPointer

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

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

XSL

Le langage de feuille de style extensible (XSL). Recommandation du W3C. S. Adler, A. Berglund, J. Caruso, S. Deach, T. Graham, P. Grosso, E. Gutentag, A. Milowski, S. Parnell, J. Richman, S. Zilles. Octobre 2001.

http://www.w3.org/TR/2001/REC-xsl-20011015/

XSLT

Les transformations XSL (XSLT) version 1.0. Recommandation du W3C. J. Clark. Novembre 1999.

http://www.w3.org/TR/1999/REC-xslt-19991116.html vf.

12. Les adresses des auteurs

Donald E. Eastlake 3rd
Motorola, 20 Forbes Boulevard
Mansfield, MA 02048 USA
Téléphone : 1-508-261-5434
Mèl : Donald.Eastlake@motorola.com

Joseph M. Reagle Jr., W3C
Massachusetts Institute of Technology
Laboratory for Computer Science
NE43-350, 545 Technology Square
Cambridge, MA 02139
Téléphone : + 1.617.258.7621
Mèl : reagle@w3.org

David Solo
Citigroup
909 Third Ave, 16th Floor
NY, NY 10043 USA
Téléphone : +1-212-559-2900
Mèl : dsolo@alum.mit.edu