W3C | XML Signature et XML Encryption
Ce document est une traduction du document informel Refactoring XML Signature and XML Encryption du W3C, daté du 30 octobre 2002. Cette version traduite peut contenir des erreurs absentes de l'original, introduites par la traduction elle-même. La version originelle en anglais, se trouve à l'adresse http://www.w3.org/2002/10/xsec-refactoring.html.
Ce document décrit de possibles thèmes et directions concernant un futur travail sur XML Signature (XDSIG) et XML Encryption (XENC) - ensemble (XSE) - en capturant des questions habituelles et leurs (quelquesfois incomplètes) réponses. Ce n'est pas censé être une introduction, guide, ou FAQ au sujet de ces spécifications ; il s'agit plutôt d'une discussion assez technique sur l'architecture XML et ses à cotés.
C'est un brouillon personnel, sans tenue formelle, sollicitant discussion et commentaires. Je suis sûr qu'il y a des erreurs et des confusions que les lecteurs sont encourgés à noter et à envoyer à l'auteur. (NdT : il en va de même de la traduction ! ).
Nous espérons que toutes les spécifications rassemblées sous les activités XSE seront terminées en décembre 2002. Ces spécifications sont fermement enracinées sur les recommandations XML 1.0, les espaces de noms 1.0, et XPath 1.0. Vu la maturation des spécifications XML Infoset 1.0 et XML Schéma 1.0 il serait maintenant souhaitable pour les technologies XSE d'être mieux intégrées à ces nouvelles spécifications. Ce document enregistre les questions, réponses, et directions pour un futur travail au sujet de cette migration.
Non. XDSIG utilise le modèle de données XPath 1.0 pour représenter une instance XML. Ce modèle est utilisé par XDSIG Transform Processing pour sélectionner et transférer des instances XML et/ou des fragments entre transformations. Par exemple, un noeud élément XPath peut être selectionné, transformé, puis sérialisé. Bien que les modèles de données XPath 1.0 et XML Infoset 1.0 soient similaires, il y a des différences cruciales. Tant que le "XDSIG Transform Processing" dépendra à la fois du modèle de donnée XPath et du traitement des noeuds (c'est à dire sa selection) il serait mieux pour de futures versions d'utiliser une version de XPath basée sur Infoset. XPath 2.0 est basée sur Infoset, mais réclame en plus une prise en compte des types de schéma XML, pour représenter des collections de documents et des valeurs complexes. Ces fonctions acceptent les exigences de XML Query 1.0 et XSLT 2.0 et pourraient être intéressantes pour des applications XSE, mais non nécessaires et couteuses pour d'autres.
Oui. La plupart des applications Infoset sont encore des applications XML 1.0 : elles sont capables de sérialiser et d'analyser un infoset. Par conséquent, une appliquation qui traite d'un document XML comme des éléments d'informations, a juste besoin de définir une correspondance entre son modèle et le modèle XPath 1.0, ou simplement de sérialiser puis de permettre à l'application XML Signature d'analyser l'instance dans un ensemble de noeud XPath. Durant cette traduction ou serialisation/analyse des informations peuvent être perdues (selon les différences évoquées plus haut) ce qui pourrait, ou non, avoir des conséquences sur l'application.
Partiellement, et une fois serialisés. Les algorithmes de chiffrement
nécessitent des octets (ou des bits) en entrée. XENC donne un modèle pour
chiffrer différents types d'information via son mécanisme de Type, et
fournit actuellement deux identificateurs spécifiques et règles de traitement
pour les "elements" et "contenu d'élément" XML 1.0. Il s'agit, bien sûr, de
sérialisation XML 1.0 de parties d'un "Item d'élément d'information" et de
ses "enfants". Toutefois, comme il est décrit dans le paragraphe XENC 4.3.3
Serializing XML et montré dans le mail de Ross Thompson pour le Schema
WG cela peut ouvrir des problèmes tels que la perte d'information infoset
concernant le lien entre les préfixes d'espace de nom et son URI.
D'autres types et leurs traitements peuvent être définis. Par exemple, une spécification peut fournir un identificateur pour toute une représentation sérialisée d'un élément infoset, un extrait python d'un noeud DOM, ou d'une donnée compressée. Ces spécifications pourraient aussi avoir à définir le chiffrement, le déchiffrement, et à reformuler des traitements : comment un objet (ie : un élément infoset) pourrait être effacé, chiffré, déchiffré, et réinséré dans un autre infoset et quels "combines" pourraient être faites (ex un ajustement XInclude d'un IDREF dans le nouvel infoset résultant).
Exigence potentielle : Pour travailler dans ce contexte applicatif Infoset où des éléments infoset complets sont crypté on EXIGE une serialisation des éléments Infoset qui soit non ambiguë et non destructive.
Oui, avec quelques faiblesses. XML Schema 1.0 fait deux choses. Premièrement il valide un instance par rapport à un schéma, cela ne concerne pas XDSIG. Deuxièmement, il peut aussi modifier l' infoset résultant de l'analyse et de la validation de l'instance. Par exemple, "les schémas peuvent aussi fournir pour la spécification d'information additionnelle sur le document, telles que la normalisation et les attributs et les valeurs par défaut". Ces changements sont typiquement reflétés dans le "infoset augmenté" comme "[schema normalized value]". Dans une projection naïve sur le modèle de données XPath, ces changements ne seraient pas relevés. Une projection plus attentive ou sérialisation/retraitement serait plus susceptible de retenir cette information. A première vue, les transformations XDSIG permettent un traitement prudent de cette voie comme il est montré dans le "UDDI Schema Centric Canonicalization". Toutefois, pour que XDSIG adopte et supporte les schemas avec les infoset comme modèle de donnée propre (et traitements et transformations), il devrait être modifié pour se raccorder au schémas XPath 2.0 et ses spécifications associées.
Comme il est dit dans le cahier des charges XENC, XENC n'a pas à maintenir la validité:
- ...
- Validité instance {WS}
- Les instances chiffrées doivent être bien formées mais n'ont pas besoin d'être validées au regard de leur définition originale (ie les applications qui chiffrent la structure des éléments sont supposées masquer cette structure).
- Les auteurs d'instances qui veulent valider des instances chiffrées doivent faire ce qui suit :
- Ecrire le schema original pour valider les instances résultantes en tenant compte des changements dans sa structure et l'insertion des types d'éléments des espaces de noms d'XML Encryption.
- Fournir un schéma après chiffrement pour valider les instances chiffrées.
- Fournir des informations pour restaurer le document dans son état original selon le contexte applicatif (ex entêtes) {Liste : Reagle}
...
Ross Thompson rappelle pour le Schema WG quelques une de ces options et donne plusieurs exemples sur la façon dont un schema peut être écrit pour les remplir.
Non. Les spécifications XSEC dépendent de l'ensemble {XML, NS, XPath} 1.0 de ces spécifications. Pour que XSEC soit adapté, en dehors de mettre à jour les référence normatives, il faudra faire quelques mineurs, mais substantiels, changements dans les spécifications et leurs concrétisations. En outre les relations entre l'ensemble de spécifications {XML Infoset 1.0, XML Schéma, XPath 2.0} et {XML 1.1, NS 1.1} n'est pas clair.