La liste des erreurs dans la spécification syntaxe et traitement de XML signature

À propos de la spécification syntaxe et traitement de XML signature

La recommandation syntaxe et traitement de XML signature à été produite par le groupe de travail de XML signature composé des membres de l'IETF/du W3C...

Ce document liste les erreurs connues de la spécification XML Signature. Chaque entrée possède les informations suivantes :

• Un unique numéro d'entrée.
• La date à laquelle elle a été ajoutée dans la page de la liste des erreurs.
• L'entrée est soit :
  • une erreur qui affecte la conformité et/ou l'interopérabilité de la syntaxe et du traitement,
  • une erreur rédactionnelle, telle qu'une faute de typographie,
  • un défaut de structure dans le document, tel qu'un identifiant de fragment incorrect,
  • un éclaircissement en ce qui concerne un mauvais état ou une mauvaise interprétation de la spécification,
  • une mise en garde où une expérience subséquente a montré qu'une recommandation de la spécification était incorrecte ou nécessitait des modifications plus importante.
• La version et la section à laquelle se réfère l'erreur.
• Une description du problème et une correction si elle peut s'appliquer.

Merci de reporter les erreurs de ce document à l'éditeur et de mettre en copie : la liste publique w3c-ietf-xmldsig@w3.org (archive).

Syntaxe et traitement de XML signature

E01 2002-01-28 (Rédactionnelle) :

L'encodage des valeurs chaîne de caractères dans un DNAME fourni par la spécification xmldsig n'est pas strictement conforme à la RFC2253 [LDAP-DN] ; il y a des différences en ce qui concerne leur encodage dans les documents XML. Par conséquent :

1. L'élément X509Data de la section 4.4.4 : Les deux premier points de la liste d'items "1" devraient être, "l'encodage du nom distingué DOIT être en conformité avec les règles d'encodage du DNAME à la fin de cette section."
2. Le texte à la fin de la section devrait être, "DNames (X509IssuerSerial, X509SubjectName, et KeyName s'ils sont appropriés) devraient être encodés selon la RFC2253 [LDAP-DN] sauf pour l'encodage des valeurs chaîne de caractères dans un DName :"

E02 2002-01-29 (Mise en garde) :

Dans les algorithmes (section 6) la recommandation du XML canonique est référencée en tant qu'objectif général de l'algorithme de canonisation. Cependant, la spécification de la canonisation XML exclusive est maintenant disponible pour assigner des conditions résultant de scénarii où un sous document change de contexte. "Le XML canonique [XML-C14N] spécifie la sérialisation de XML standard qui, lorsqu'elle s'applique à un sous document, inclut le contexte de niveau supérieur du sous document incluant toutes les déclarations et attributs d'espace de nommage dans l'espace de nommage 'xml:'. Cependant, quelques applications requièrent une méthode qui, au niveau de la pratique, exclut le contexte de niveau supérieur inutilisé d'un sous document canonisé."

E03 2002-01-29 (Mise en garde) :

Le filtrage XPath (section 6.6.3) est spécifié comme un mécanisme de "qui omet précisément les noeuds qui peuvent changer une fois que la signature est apposée, et incluant tous les autres noeuds d'entrée dans la sortie." Il y a des comptes rendus informant que les inplémentations agissent pauvrement -- peut être parce qu'elles s'appuient sur des implémentations XPath sous optimales. Les développeurs ont demandé une transformation XPath qui permet la sélection et l'omission facile de la spécification du sous arbre qui soit efficacement implémentée. Cette proposition est à l'étude (les retours d'information sont les bienvenus) et se fera par une nouvelle spécification de transformation si nécessaire.

E04 2002-03-20 (Èclaircissement)

6.5 Les algorithmes de canonisation font état d'une canonisation avec ou sans commentaires, "les deux algorithmes ci-dessous traitent la normalisation textuelle durant le transcodage [NFC, NFC-Corrigendum]." Bien qu'il est vrai que la sortie de ces algorithmes sera dans NFC, ceci n'est pas dû au fait qu'elles réalisént la normalisation d'elles même, mais parce que "le processeur XML utilisé pour préparer l'entrée du modèle de données XPath est requis (par le modèle de données) pour utiliser la form C de normalisation [NFC, NFC-Corrigendum] lors de la conversion d'un document XML vers un domaine de caractère UCS à partir de n'importe quel encodage qui n'est pas basé sur UCS..." [XML-C14N, 4.2 Aucune normalisation du modèle de caractère].

E05 2002-05-08 (Éclaircissement)

L'attribut Type décrit dans 4.3.3.1 l'attribut URI et 4.4.3 L'élément RetrievalMethod "contient des informations à propos du type de l'objet qui doit être signé." L'objet qui doit être signé est le résultat du modèle de traitement et de référencement, incluant toutes les transformations spécifiées. Il est incorrect d'utiliser l'attribut Type pour décrire l'objet qui est identifié via l'URI de l'élément Reference avant son entrée dans toute transformation.

E06 2002-06-06 (Erreur)

L'exemple de l'attribut d'information Encoding dans la section 4.5 L'élément Object est incorrect, il utilise une chaîne de caractères en 'base64' au lieu d'une URI. Il devrait être écrit, "Par exemple, si une données qui est chiffrée est une image encodée en base64, l'attribut Encoding peut être spécifié comme 'http://www.w3.org/2000/09/xmldsig#base64' et l'attribut MimeType comme 'image/png'."