Exigences pour les signatures XML    

Statut du présent mémoire
Le présent mémoire fournit des informations pour la communauté de l'Internet. Il ne spécifie aucune sorte de norme de l'Internet. La distribution du présent mémoire n'est soumise à aucune restriction.  

Notice de copyright
Copyright (c) 2000 The Internet Society & W3C (MIT, INRIA, Keio), tous droits réservés.  

Résumé
Le présent document fait la liste des principes de conception, de la portée et des exigences de la spécification des signatures numériques XML. Il comporte des exigences qui se rapportent à la syntaxe, au modèle des données, au format, au traitement cryptographique de la signature, ainsi que des exigences externes et de coordination.  

Table des matières  

1.   Introduction

2.   Principes de conception et portée

3.   Exigences

3.1   Modèle et syntaxe des données de signature

3.2   Format

3.3   Cryptographie et traitement

3.4   Coordination

4.   Considérations pour la sécurité

5.   Références

6.   Remerciements

7.   Adresse de l'auteur

8.   Déclaration de copyright

1.   Introduction

 La Recommandation XML 1.0 [XML] décrit la syntaxe d'une classe d'objets de données appelés documents XML. La mission du présent groupe de travail est de développer une syntaxe XML pour la représentation des signatures de contenu numérique et les procédures de calcul et de vérification de telles signatures. Les signatures assureront la protection de l'intégrite des données, l'authentification, et/ou la non-répudiation.  Le présent document fait la liste des principes de conception, de la portée et des exigences couvrant trois domaines :
(1)   la portée du travail disponible pour le groupe de travail,
(2)   la spécification de la signature XML,
(3)   les applications qui mettent en œuvre la spécification.  Cela inclut les exigences qui se rapportent à la syntaxe de la signature, au modèle des données, au format, au traitement cryptographique, et aux exigences externes et à la coordination. Ces éléments d'exigences sont mentionnés comme "DOIT", les éléments qui sont facultatifs sont mentionnés comme "PEUT", les éléments qui sont facultatifs mais recommandés sont mentionnés comme "DEVRAIT".  

2.   Principes de conception et portée

 1.   La spécification doit décrire comment signer un contenu numérique, et en particulier un contenu XML. La syntaxe XML utilisée pour représenter une signature (sur tout contenu) est décrite comme une signature XML. [Charte]

2.   Les signatures XML sont générées à partir d'un hachage sur la forme canonique d'un manifeste de signature. (Dans le présent document on utilise le terme "manifeste" pour signifier une collection de références aux objets signés. Les spécifications peuvent utiliser les termes "manifeste", "paquetage" ou autres termes différemment du présent document tout en respectant cette exigence.) Le manifeste doit prendre en charge des références aux ressources de la Toile, le hachage du contenu de la ressource (ou de sa forme canonisée), et (facultativement) le type de contenu de la ressource. [Brown, List(Solo)] Les ressources de la Toile sont définies comme tout contenu numérique qui peut être atteint en utilisant la syntaxe de localisateur XLink [XLink]).

3.   La signification d'une signature est simple : La syntaxe de signature XML associe le contenu des ressources dont la liste figure dans un manifeste avec une clé via une forte transformation unidirectionnelle.

1.   La syntaxe de signature XML doit être extensible de façon a pouvoir prendre en charge des capacités arbitraires de sémantique et d'assertion d'application/de confiance – qui puissent aussi être signées. [Charte (Exigences 1 & 4), Liste (Bugbee, Solo)]

2.   Le groupe de travail n'est pas mandaté pour spécifier la sémantique de confiance, mais la syntaxe et les règles de traitement nécessaires pour communiquer la validité de la signature (authenticité, intégrité et non-répudiation). [Charte (exigence 1)] À la discrétion du président et afin de de vérifier l'extensibilité de la syntaxe, le groupe de travail peut produire des propositions de chemin non critique définissant la sémantique commune (par exemple, manifeste, paquetage, horodatages, approbation, etc.) pertinente pour les assertions signées à propos des ressources de la Toile dans une définition de schéma [XML, RDF] ou une définition de type liaison [XLink].  Commentaire : Une définition plus formelle d'une ressource signée figure ci-dessous. La notation est "définition(entrées):contraintes" où définition s'évalue comme vrai pour les entrées données et les contraintes spécifiées. ressource-signée(URI-de-ressource, contenu, clé, signature): (à un moment donné il y avait un message de protocole tel que "GET(URI- de-resource) = contenu") ET (sign-doc(contenu, clé, sig)) sign-doc(contenu, clé, signature): signature est la valeur d'une transformation unidirectionnelle forte sur le contenu et la clé, qui donne l'intégrité/validité du contenu et/ou la non répudiabilité de clé.  

4.   La spécification ne doit pas spécifier les méthodes de confidentialité bien que le groupe de travail puisse faire rapport sur la faisabilité d'un tel travail à l'avenir ou en modifiant le mandat . [Liste (Bugbee)]

5.   La spécification doit seulement exiger la fourniture des informations de clés essentielles pour vérifier la validité de la signature cryptographique. Par exemple, les informations d'identité et de reprise de clé peuvent être intéressantes pour des applications particulières, mais elles ne font pas partie de la classe des informations exigées définies dans cette spécification. [Liste (Reagle)]

6.   La spécification doit définir ou faire référence à au moins une méthode de canonisation et de hachage de syntaxe de signature (c'est-à-dire, des blocs manifeste et signature). [Oslo] La spécification ne doit pas traiter des méthodes de canonisation du contenu de la ressource [Charte], bien qu'elle puisse spécifier des exigences de sécurité sur de telles méthodes. [Oslo] Un tel contenu est normalisé en spécifiant un algorithme de contenu approprié C14N (canonisation) [DOMHASH, XML-C14N]. Il est prévu que les applications normalisent la sémantique spécifique d'application avant de passer les données à une application de signature XML ou spécifiant les transformations nécessaires pour ce processus au sein de la signature. [Charte]

7.   Les applications de signature XML doivent se conformer comme suit aux spécifications :

1.   Espace de nom XML [XML-namespaces] au sein de sa propre syntaxe de signature. Les applications peuvent choisir les algorithmes C14N qui traitent ou non les espaces de noms au sein du contenu XML. Par exemple, certains algorithmes C14N peuvent opter pour le retrait de toutes les déclarations d'espace de noms, d'autres peuvent réécrire les déclarations d'espace de noms pour fournir des déclarations indépendantes du contexte au sein de chaque élément.

2.   XLink [Xlink] au sein de sa propre syntaxe de signature. Pour toute identification de ressource au delà des simples URI (sans identifiant de fragment) ou des fragmentID, les applications doivent utiliser des localiseurs XLink pour faire référence à des ressources signées. Les applications de signature ne doivent pas incorporer ou étendre des références XLink dans un contenu signé, bien que les applications puissent choisir des algorithmes C14N qui fournissent ce dispositif.

3.   Pointeurs XML [XPointer] au sein de leur propre syntaxe de signature. Si les applications font référence/sélectionnent des parties de documents XML, elles doivent utiliser XML-Pointer au sein d'un localiseur XLink. [WS-list(1)] Le groupe de travail peut spécifier des exigences de sécurité qui contraignent le fonctionnement de ces annexes à assurer une génération et un fonctionnement de signature cohérent et sûr. [Oslo]

 8.   Les signatures XML doivent être développées dans le cadre de la philosophie de décentralisation la plus large de la conception de la Toile, des URI, des données de la Toile, de la modularité, de la structure en couches, de l'extensibilité, et des assertions comme déclarations sur les déclarations. [Berners-Lee, WebData] Dans ce contexte, on devrait tirer parti des primitives existantes de fournisseur (et d'infrastructure) cryptographique. [List(Solo)]  

3.   Exigences

3.1   Modèle et syntaxe des données de signature

 1.   Les structures de données des signature XML doivent se fonder sur le modèle de données RDF [RDF] mais pas nécessairement utiliser la syntaxe de sérialisation RDF. [Charte]

2.   Les signatures XML s'appliquent à toute ressource adressable par un localiseur – y compris un contenu non XML. Les référents des signatures sont identifiés par des localiseurs XML (URI ou fragments) au sein du manifeste qui se réfère à des ressources externes ou internes (c'est-à-dire, accessible réseau ou au sein du même document/paquetage XML). [Berners-Lee, Brown, List(Vincent), WS, XFDL]

3.   Les signatures XML doivent être capables de s'appliquer à une partie ou à la totalité d'un document XML. [Charter, Brown] Commentaire : une exigence examinée à ce sujet demande à la spécification de prendre en charge la capacité à indiquer les portions du document qui sont signées via l'exclusion des portions qu'on ne souhaite pas signer. Ce dispositif permet de créer des signatures qui ferment le document [List(Boyer(1)], conservent les informations d'historique, et conservent l'ordre des éléments des régions non continues qui doivent être signées. On envisage de mettre en œuvre cette exigence via (1) un élément spécial <dsig:exclude> , (2) une liste d'exclusion accompagnant le localiseur de ressource, ou (3) la spécification de XML-Fragment ou XPointer -- ou une demande de changement de ces spécifications si la fonctionnalité n'est pas disponible. Voir List(Boyer(1,2)) pour un exposé complémentaire sur cette question.

4.   Plusieurs signatures XML doivent pouvoir exister sur le contenu statique d'une ressource de la Toile selon des clés, des transformations de contenu, et des spécifications d'algoritme (signature, hachage, canonisation, etc.) diverses données. [Charter, Brown]

5.   Les signatures XML sont elles-mêmes des objets de première classe et doivent par conséquent être capables d'être référencées et signées. [Berners-Lee]

6.   La spécification doit permettre l'utilisation de divers codes d'authentification de signature numérique et d'authentification de message, tels que des schémas d'authentification symétriques et asymétriques ainsi que d'agrément dynamique du matériel de clés. [Brown] L'identifiant de ressource ou d'algorithme est un objet de première classe et doit être adressable par un URI. [Berners-Lee]

7.   Les signatures XML doivent être capables de s'appliquer à la version originale d'une ressource incluse/codée. [WS-list (Brown/Himes)]  

3.2   Format

 1.   Une signature XML doit être un élément XML (comme défini par la production 39 de la spécification XML1.0. [XML])

2.   Lorsque des signatures XML sont placées dans un document, l'opération doit préserver (1) l'étiquette d'élément racine du document comme racine et (2) l'arbre de descendance de la racine, aux emplacements permis par le modèle de contenu du document, à l'exception de l'ajout du ou des éléments de signature. Par exemple, une forme XML, lorsqu'elle est signée, devrait rester reconnaissable comme forme XML à son application après sa signature. [WS-summary]

3.   Une signature XML doit fournir un mécanisme qui facilite la production de documents composites -- par addition ou suppression – tout en préservant les caractéristiques de la signature (intégrité, authentification, et non répudiation) des parties consititutives. [Charter, Brown, List(Bugbee)]

4.   Un important usage des signatures XML sera les signatures Web détachées. Cependant, les signatures peuvent être incorporées dans XML ou encapsulées dans XML ou être à contenu codé. [Charte] Le groupe de tavail doit spécifier une méthode simple de paquetage et d'encapsulation si aucune recommandation du W3C n'est disponible.  

3.3   Chiffrement et traitement

 1.   La spécification doit permettre des algorithmes arbitraires de signature cryptographique et d'authentification de message, des schémas d'authentification symétriques et asymétriques, et des méthodes d'accord de clés. [Brown]

2.   La spécification doit préciser au moins un algorithme de mise en œuvre obligatoire de canonisation de signature, de canonisation de contenu, de hachage, et de signature.

3.   Dans le cas d'attributs redondants au sein de la syntaxe de signature XML et de taches cryptographiques pertinentes, les applications de signature XML préfèrent la sémantique de signature XML. Commentaire : une autre possibilité est qu'une erreur soit générée, cependant, c'est une situation différente de celle où un conflit est affiché entre les diverses couches de fonction et d'application.

4.   Le concept et le texte de spécification de la signature ne doivent pas permettre que les développeurs construisent par erreur des mises en œuvre faibles susceptibles de prêter le flanc aux faiblesses courantes de la sécurité (comme les attaques en dégradation ou substitution d'algorithme).  

3.4   Coordination

 1.   La spécification de signature XML devrait satisfaire aux exigences des applications suivantes :

1.   Protocole Internet d'échange ouvert (Internet Open Trading Protocol) v1.0 [IOTP]

2.   Langage de balsiage de services financiers (Financial Services Mark Up Language) v2.0 [Charter]

3.   Au moins une application de forme [XFA, XFDL]  

2.   Pour s'assurer que toutes les exigences du présent document sont traitées de façon adéquate, la spécification de signature XML doit être révisée par un membre désigné des communautés suivantes :

1. Groupe de travail Syntaxe XML : annexes pour la canonisation. [Charter]

2. Groupe de travail Liaison XML : référents de signature. [Charter]

3. Groupe de travail Schéma XML : conception du schéma de signature. [Charter]

4. Groupe de coordination Métadonnées : conception du modèle des données. [Charter]

5. Groupe d'intérêt à l'internationalisation du W3C : [AC Review]

6. Groupe de travail Paquetage XML : contenu signé dans/sur les paquetages.

7. Groupe de travail Fragment XML : signature de portions de contenu XML.  

Commentaire : Les membres du groupe de travail sont très intéressés par la signature et le traitement des fragments et des composants en paquetage. Boyer affirme que [XML-fragment] "n'identifie pas de portions non contiguës d'un document d'une façon telle que les positions relatives des composants connectés soient préservées". Le paquetage est une capacité critique pour les applications de signature XML, mais elle dépend clairement des définitions de confiance/sémantique, des exigences de l'application de paquetage, et même des exigences d'application de style mémoire cache. On ne voit pas clairement comment ce travail sera traité.  

4.   Considérations pour la sécurité

5.   Références

AC Review   Misha Wolf. "The Charter should include the I18N WG in the section on `Coordination with Other Groups'", http://lists.w3.org/Archives/Team/xml-dsig-review/1999May/0007.html  

Berners-Lee   Axioms of Web Architecture: URIs. http://www.w3.org/DesignIssues/Axioms.html Web Architecture from 50,000 feet http://www.w3.org/DesignIssues/Architecture.html  

Brown-XML-DSig   Digital Signatures for XML. Travail en cours. http://www.w3.org/Signature/Drafts/xmldsig-signature-990618.html  

Charter   Charte de signature XML (xmldsig). http://www.w3.org/1999/05/XML-DSig-charter-990521.html  

DOMHASH   H. Maruyama, K. Tamura et N. Uramoto, "Valeurs de résumé pour DOM (DOMHASH)", RFC 2803, avril 2000.  

FSML   FSML 1.5 Reference Specification http://www.echeck.org/library/ref/fsml-v1500a.pdf  

Infoset-Req   XML Information Set Requirements Note. http://www.w3.org/TR/1999/NOTE-xml-infoset-req-19990218.html

IOTP   Burdett, D., "Internet Open Trading Protocol - IOTP Version 1.0", RFC 2801, avril 2000.

IOTP-DSig   Davidson, K. and Y. Kawatsura, "Digital Signatures for the v1.0 Internet Open Trading Protocol (IOTP)", RFC 2802, April 2000.

 Oslo   Minutes of the signature XML WG Sessions at IETF face-to-face meeting in Oslo.

 RDF   RDF Schema http://www.w3.org/TR/1999/PR-rdf-schema-19990303

RDF Model and Syntax http://www.w3.org/TR/1999/REC-rdf-syntax-19990222  Signature WG List http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/  

URI   T. Berners-Lee, R. Fielding et L. Masinter, "Identifiants de ressource uniformes (URI) : Syntaxe générique", RFC 2396, août 1998. http://www.ietf.org/rfc/rfc2396.txt(rendue obsolète par la RFC 3986)  

WS   (list, summary) XML-DSig '99: The W3C Signed XML Workshop http://www.w3.org/DSig/signed-XML99/http://www.w3.org/DSig/signed-XML99/summary.html  

XLink XML   Linking Language http://www.w3.org/1999/07/WD-xlink-19990726  

XML   Extensible Markup Language (XML) Recommendation. http://www.w3.org/TR/1998/REC-xml-19980210  

XML-C14N   XML Canonicalization Requirements. http://www.w3.org/TR/1999/NOTE-xml-canonical-req-19990605  

XFA   XML Forms Architecture (XFA) http://www.w3.org/Submission/1999/05/  XFDL   Extensible Forms Description Language (XFDL) 4.0 http://www.w3.org/Submission/1998/16/  

XML-Fragment   XML-Fragment Interchange http://www.w3.org/1999/06/WD-xml-fragment-19990630.html  

XML-namespaces   Namespaces in XML http://www.w3.org/TR/1999/REC-xml-names-19990114  

XML-schema   XML Schema Part 1: Structures http://www.w3.org/1999/05/06-xmlschema-1/XML Schema Part 2: Datatypes http://www.w3.org/1999/05/06-xmlschema-2/

 XPointer   XML Pointer Language (XPointer) http://www.w3.org/1999/07/WD-xptr-19990709  

WebData   Web Architecture: Describing and Exchanging Data. http://www.w3.org/1999/04/WebData  

6.   Remerciements

7.   Adresse de l'auteur

8.   Déclaration de copyright

Copyright (c) 2002 The Internet Society & W3C (MIT, INRIA, Keio). Tous droits réservés.

Le présent document et les informations y contenues sont fournies sur une base "EN L’ÉTAT" et LE CONTRIBUTEUR, L’ORGANISATION QU’IL OU ELLE REPRÉSENTE OU QUI LE/LA FINANCE (S’IL EN EST), LA INTERNET SOCIETY ET LA INTERNET ENGINEERING TASK FORCE DÉCLINENT TOUTES GARANTIES, EXPRIMÉES OU IMPLICITES, Y COMPRIS MAIS NON LIMITÉES À TOUTE GARANTIE QUE L’UTILISATION DES INFORMATIONS CI-ENCLOSES NE VIOLENT AUCUN DROIT OU AUCUNE GARANTIE IMPLICITE DE COMMERCIALISATION OU D’APTITUDE À UN OBJET PARTICULIER.

Remerciement

Le financement de la fonction d’édition des RFC est actuellement fourni par l’Internet Society.