Source: http://www.yoyodesign.org/doc/w3c/xades/
Timestamp: 2017-09-26 00:23:41+00:00
Document Index: 30756993

Matched Legal Cases: ['art-1', 'art-2', 'art-1', 'art-2', 'art-2', 'art-2', 'art-1', 'art-2']

XMLAdvanced Electronic Signatures (XAdES)
Adresse de la traduction : <http://www.yoyodesign.org/doc/w3c/xades/>
Date de traduction : 28 février 2003
Dernière mise à jour : 7 septembre 2005
Note du W3C du 20 février 2003
http://www.w3.org/TR/2003/NOTE-XAdES-20030220/
Juan Carlos Cruellas, UPC<cruellas@ac.upc.es>
Gregor Karlinger, IAIK<gregor.kerlinger@iaik.at>
Denis Pinkas, Bull<Denis.Pinkas@bull.net>
John Ross, Security and Standards<ross@secstan.com>
Krishna Sankar, Cisco<ksankar@cisco.com>
Copyright © 2003 ETSI, tous droits réservés.
Cette note (XAdES) prolonge la spécification de la syntaxe et du traitement XML Signature de IETF/W3C [XMLDSIG] dans le domaine de la non-répudiation, en définissant des formats XML pour les signatures électroniques évoluées qui restent valides pendant de grandes périodes et sont conformes à la Directive 1999/93/EC du Parlement Européen et du Conseil du 13 décembre 1999 sur le cadre communautaire des signatures électroniques [EU-DIR-ESIG] (désigné également par la Directive ou la Directive Européenne dans la suite du présent document) et qui incorporent des informations supplémentaires utiles dans les situations d'utilisations courantes. Cela comprend la preuve de leur validité, même si le signataire ou le tiers vérifiant essayent ensuite de nier (répudier) la validité de la signature.
Une signature électronique évoluée en accord avec le présent document peut par conséquent être utilisée pour arbitrage en cas de litige entre le signataire et le vérificateur, litige qui peut survenir plus tard, éventuellement des années après.
Cette note ajoute six autres formes à [XMLDSIG]] :
la signature électronique évoluée XML (XAdES) qui offre une authentification et une protection d'intégrité minimales et qui satisfait aux obligations légales pour les signatures électroniques évoluées, comme défini dans la Directive Européenne [EU-DIR-ESIG]. Toutefois, elle ne permet pas sa propre non-répudiation. Cette forme ajoute les éléments suivants à [XMLDSIG] :
SignatureProductionPlace?
SignerRole?
DataObjectFormat*
CommitmentTypeIndication*
AllDataObjectsTimeStamp*
IndividualDataObjectsTimeStamp*
CounterSignature*
la signature électronique évoluée XML avec date [NdT. Time-Stamp] (XAdES-T) qui inclut une date en protection d'une répudiation. Cette forme ajoute les éléments suivants à la forme XAdES à l'intérieur de l'élément considéré :
dans l'élément UnsignedSignatureProperties :
la signature électronique évoluée XML avec données de validation complètes (XAdES-C) qui inclut les références à l'ensemble des données intervenant dans la validation de la signature électronique (c'est-à-dire, les références aux chemins de certification et aux informations sur le statut de révocation qui leur sont associées). Cette forme trouve son utilité dans les situations où ces informations sont archivées par une source externe, comme un tiers de confiance [NdT. trusted service provider]. Cette forme ajoute les éléments suivants à la forme XAdES-T à l'intérieur de l'élément considéré :
la signature électronique évoluée XML avec données de validation étendues (XAdES-X) qui inclut une date sur les références aux données de validation ou bien sur l'élément ds:Signature et les données de validation en question. Cette date contre le risque selon lequel toute clé employée dans la chaîne de certification ou dans les informations de statut de révocation pourrait être compromise. Comme cela a été dit, cette forme est mise en œuvre de deux façons. La première ajoute l'élément suivant à la forme XAdES-C :
La seconde ajoute l'élément suivant à la forme XAdES-C :
la signature électronique évoluée XML avec données de validation étendues incorporées pour le long terme (XAdES-X-L) qui inclut les données de validation, lorsque ces données de validation ne sont pas stockées ailleurs pour le long terme. Cette forme ajoute les éléments suivants à la forme XAdES-X :
la signature électronique évoluée XML avec données de validation pour l'archivage (XAdES-A) qui inclut des dates supplémentaires pour l'archivage des signatures afin de les protéger au cas où les données cryptographiques devenaient vulnérables. Cette forme ajoute les éléments suivants à la forme XAdES-X-L :
Cette note articule également les rôles suivants et leurs responsabilités en ce qui concerne la validité de la signature :
Signataire [NdT. Signer] : l'entité qui crée la signature électronique. Lorsque le signataire signe numériquement des objets-données à l'aide du format prescrit, cela représente un engagement de la part de cette entité sur les objets-données signés.
Vérificateur [NdT. Verifier] : l'entité qui vérifie la signature électronique. Il peut s'agir d'une seule ou bien de plusieurs entités.
Tiers de confiance [NdT. Trusted Service Providers] : une ou plusieurs entités qui participent à l'établissement de la relation de confiance entre le signataire et le vérificateur. Les tiers de confiance comprennent les autorités de certification, les autorités d'enregistrement, les autorités d'entreposage (par exemple, un annuaire), les autorités de datation, les émetteurs des politiques de signature et les autorités d'attribution.
Arbitre [NdT. Arbitrator] : une entité qui intervient dans les litiges entre un signataire et un vérificateur.
Ce document est une soumission au World Wide Web Consortium présentée à l'activité du W3C sur XML Signature. Pour la liste complète de toutes les soumissions reçues, veuillez consulter Les soumissions reçues par le W3C .
Ce document est une note proposée par le W3C seulement pour un débat. La publication de cette note par le W3C ne signifie pas l'approbation du W3C ou de l'équipe concernée du W3C, ou de tous les membres du W3C. Le W3C n'exerce aucun contrôle de rédaction sur la préparation de cette note. Ce document est un travail en cours qui peut être mis à jour, remplacé ou rendu obsolète par d'autres documents à tout instant.
La note XAdES se fonde sur le contenu de la spécification technique TS 101 903 de l'ETSI : Les signatures électroniques évoluées XML (XAdES) [ESI-XAdES]. Elle a été produite par la section STF 178 des membres de l'ETSI et résulte de débats entre l'ETSI, l'ESI et les membres de l'équipe du W3C.
L'ETSI détient le copyright des documents qu'il publie. L'ETSI ne détient pas les droits de propriété intellectuelle, en tant que tels, sur les technologies décrites dans les documents. Les membres de l'ETSI peuvent détenir certains droits sur ces technologies. Néanmoins, aucun droit de propriété intellectuelle essentiel concernant les signatures électroniques n'a été signalé à l'ETSI.
On peut trouver la liste des documents techniques courants du W3C dans la page des rapports techniques.
1.3 Les conventions d'écriture
2 Les structures de données des signatures électroniques évoluées XML
2.1 Les contenus
2.1.1 Le contenu de la forme XAdES
2.1.2 Le contenu de la forme XAdES-T
2.1.3 Le contenu de la forme XAdES-C
2.2 Les formes étendues des données de validation
2.3 Les données de validation des archives
3 L'espace de nommage XML pour le présent document
4 Aperçu de la syntaxe
4.1 Les critères techniques
4.2 L'élément QualifyingProperties
4.2.1 L'élément SignedProperties
4.2.2 L'élément UnsignedProperties
4.2.3 L'élément SignedSignatureProperties
4.2.4 L'élément SignedDataObjectProperties
4.2.5 L'élément UnsignedSignatureProperties
4.2.6 L'élément UnsignedDataObjectProperties
4.3 L'incorporation des propriétés de qualification dans une signature XML
4.3.1 L'élément SigningProperties
4.3.2 L'élément QualifyingPropertiesReference
5 La syntaxe des propriétés de qualification
5.1 La syntaxe auxilliaire
5.1.1 Le type de données AnyType
5.1.2 Le type de données ObjectIdentifierType
5.1.3 Le type de données EncapsulatedPKIDataType
5.1.4 Le type de données TimeStampType
5.2 La syntaxe de la forme XAdES
5.2.1 L'élément SigningTime
5.2.2 L'élément SigningCertificate
5.2.3 L'élément SignaturePolicyIdentifier
5.2.3.1 Les qualificatifs des politiques de signature
5.2.4 L'élément CounterSignature
5.2.5 L'élément DataObjectFormat
5.2.6 L'élément CommitmentTypeIndication
5.2.7 L'élément SignatureProductionPlace
5.2.8 L'élément SignerRole
5.2.9 L'élément AllDataObjectsTimeStamp
5.2.10 L'élément IndividualDataObjectsTimeStamp
5.3 La syntaxe de la forme XAdES-T
5.3.1 L'élément SignatureTimeStamp
5.4 La syntaxe de la forme XAdES-C
5.4.1 L'élément CompleteCertificateRefs
5.4.2 L'élément CompleteRevocationRefs
5.5 La syntaxe de la forme XAdES-X
5.5.1 L'élément SigAndRefsTimeStamp
5.5.2 L'élément RefsOnlyTimeStamp
5.6 La syntaxe de la forme XAdES-X-L
5.6.1 L'élément CertificateValues
5.6.2 L'élément RevocationValues
5.7 La syntaxe de la forme XAdES-A
5.7.1 L'élément ArchiveTimeStamp
8 Annexe A : Les définitions du schéma
9 Annexe B : DTD
10 Annexe C : L'incorporation des propriétés de qualification
11 Coordonnées des auteurs
Le commerce électronique apparaît comme le nouveau moyen émergent pour mener des affaires entre les sociétés, que ce soit sur des réseaux locaux, étendus ou globaux. La confiance est essentielle pour la réalisation de ces affaires et pour le succès et le développement continu du commerce électronique. Il est donc important que les sociétés commerçant de cette façon puissent disposer de moyens de contrôle et de mécanismes de sécurité convenables pour protéger leurs transactions et établir des relations de confiance avec leurs partenaires commerciaux. Dans cette optique, la signature électronique représente un composant important de la sécurité pouvant servir à protéger les informations et à donner foi au commerce électronique.
La Directive Européenne [EU-DIR-ESIG] définit les signatures électroniques comme des données sous forme électronique, qui sont liées ou associées logiquement à d'autres données électroniques et qui servent de méthode d'authentification .
Le présent document est destiné à couvrir les signatures électroniques pour divers types de transactions, y compris les transactions commerciales (par exemple, les applications de demande d'approvisionnement, de contrat ou de facturation). On peut donc utiliser le présent document pour toutes transactions, entre un individu et une société, entre deux sociétés, entre un individu et un corps gouvernemental, etc.
Une signature électronique, produite conformément au présent document, fournit une indication qui peut être traitée afin d'obtenir l'assurance qu'un certain engagement a été pris explicitement, sous couvert d'une politique de signature, à un instant donné, par un signataire identifiable, par exemple, par un nom ou un pseudonyme, ou éventuellement un rôle. La politique de signature spécifie les conditions techniques et procédurales pour la création et la validation de la signature dans le but de satisfaire des besoins particuliers. Un contexte légal/contractuel donné peut reconnaître une politique de signature particulière comme satisfaisant à ses conditions. Par exemple, une politique de signature particulière peut être reconnue par une cour de justice comme satisfaisant aux exigences de la Directive Européeenne pour le commerce électronique.
La norme TS 101 733 ETSI [ESI] définit les formats des signatures électroniques évoluées qui restent valides pour de longues périodes, qui sont conformes à la Directive Européenne [EU-DIR-ESIG] et qui incorporent des informations utiles supplémentaires pour les situations d'utilisations courantes (comme l'indication de l'engagement obtenu par la production de la signature). Elle emploie actuellement la notation de syntaxe (ASN.1) et elle repose sur la structure définie dans le document RFC 2630 [CMS] (dans le présent document, les signatures qui obéissent à ce document RFC seront désignées comme étant des signatures [CMS]).
La norme TS 101 733 [ESI] :
définit les nouveaux types ASN.1 capables de contenir les informations pour la qualification des signatures [CMS] afin que celles-ci puissent satisfaire aux conditions ci-dessus ;
spécifie comment ces qualifications doivent être incorporées aux signatures [CMS].
Le groupe de travail IETF/W3C XML Signature a développé, à ce jour, une syntaxe pour les signatures XML : La syntaxe et le traitement XML Signature [XMLDSIG]. Cette syntaxe fournit les caractéristiques minimales permettant de signer numériquement et simultanément plusieurs objets-données. Elle fournit également les moyens essentiels permettant d'incorporer tous types d'informations de qualification nécessaires.
Le présent document définit les formats des signatures électroniques évoluées XML qui restent valides sur de longues périodes, sont conformes à la Directive Européenne [EU-DIR-ESIG] et incorporent des informations utiles supplémentaires dans les situations d'usages courants :
en proposant les définitions de schéma XML [XML-schema-part-1] [XML-schema-part-2] des nouveaux types XML capables de contenir les informations nécessaires pour remplir les conditions de validité à long terme et celles imposées par les situations d'usages courants et par la Directive Européenne [EU-DIR-ESIG] ;
en spécifiant les mécanismes permettant d'ajouter les informations de qualification mentionnées précédemment.
Le présent document spécifie deux types principaux de propriétés : les propriétés signées et celles qui ne le sont pas. Les premières sont des objets-données supplémentaires qui sont également protégés par la signature produite par le signataire sur l'élément ds:SignedInfo, ce qui implique que le signataire dispose de ces objets-données, calcule une empreinte pour chacun d'eux et génère l'élément ds:Reference correspondant. Les propriétés non signées sont des objets-données ajoutés par le signataire, par le vérificateur ou par des tiers après la production de la signature. Ces objets-donnés ne sont pas protégés par la signature dans l'élément ds:Signature (celui calculé par le signataire) ; toutefois, ils peuvent être en réalité signés par des tiers (les dates, les contre-signatures, les certificats et les réponses CRL sont également des objets-données signés).
Les expressions suivantes sont employées dans ce document, leur signification particulière étant indiquée dessous :
Dans la suite de ce document, on utilisera les expressions informations de qualification , propriétés ou propriétés de qualification pour désigner les informations ajoutées à la signature [XMLDSIG] afin d'obtenir une signature électronique évoluée XML telle que décrite par ce document.
Dans ce document, les mots-clés DOI(VEN)T , NE DOI(VEN)T PAS , REQUIS , DEVRA , NE DEVRA PAS , DEVRAIT , NE DEVRAIT PAS , RECOMMANDÉ , PEUT et OPTIONNEL dans la spécification doivent s'interpréter comme décrit dans le document RFC2119 [Keywords] :
Le présent document définit diverses formes de signatures électroniques, chacune d'elles remplissant les conditions indiquées dans les sections correspondantes.
La section courante présente les trois premières formes : la signature électronique évoluée XML (XAdES), la signature électronique évoluée XML avec date (XAdES-T) et la signature électronique évoluée XML avec données de validation complètes (XAdES-C). La section 2.2 Les formes étendues des données de validation introduit les formes étendues de la signature XAdES (XAdES-X et XAdES-X-L) qui satisfont à des conditions supplémentaires. Enfin, la section 2.3 Les données de validation des archives présente le format pour l'archivage des signatures de manière à les protéger quand les données cryptographiques deviendront vulnérables (XAdES-A).
Les trois premières formes sont les suivantes :
La signature électronique évoluée XML (XAdES). Son format est celui définit dans [XMLDSIG] auquel s'ajoutent des propriétés signées (SigningTime, SigningCertificate, SignaturePolicyIdentifier, SignatureProductionPlace, SignerRole, AllDataObjectsTimeStamp, IndividualDataObjectsTimeStamp, DataObjectFormat et CommitmentTypeIndication) et non signée (CounterSignature)
La signature électronique évoluée XML avec date (XAdES-T), qui ajoute une date à XAdES, pour un premier pas vers la validité à long terme. On devrait créer cette forme, ou un enregistrement chronologique, à un moment proche de celui où la signature XAdES est produite, en prévention d'une répudiation.
La signature électronique évoluée XML avec données de validation complètes (XAdES-C), qui ajoute, à la forme XAdES-T, les références à l'ensemble des données constituant la validité de la signature électronique (c'est-à-dire, les références restantes aux chemins de certification et les informations sur le statut de révocation qui leur sont associées). Remarquez que cet ensemble ne contient pas les données réelles du chemin de certification et des informations de révocation associées, lesquelles sont beaucoup plus volumineuses.
La signature XAdES satisfait aux obligations légales pour les signatures électroniques évoluées, telles que définies dans la Directive Européenne [EU-DIR-ESIG] pour les signatures électroniques. Elle offre une authentification et une protection de l'intégrité minimales et elle peut être créée sans accès à des services en-ligne (datation). Cependant, sans ajout d'une date ou d'un enregistrement chronologique protégés, la signature électronique ne prévient pas du risque que le signataire puisse nier ensuite avoir créé la signature électronique (c'est-à-dire, elle ne permet pas sa propre non-répudiation).
La date XAdES-T devrait être créée à un instant proche de celui de la création de la signature XAdES, pour offrir une protection contre la répudiation. Toutes les données nécessaires pour réaliser la validation ne seront peut-être pas disponibles à cet instant précis, mais toutes les informations qui le seraient peuvent être utilisées pour effectuer certaines vérifications initiales. Par exemple, seulement une partie des informations de révocation ne sera disponible pour une vérification à ce moment-là.
Le vérificateur doit obligatoirement gérer la signature XAdES-C dès qu'une vérification doit avoir lieu ensuite.
Le signataire devra fournir au moins une signature de la forme XAdES, cependant il peut, dans certains cas, fournir la forme XAdES-T et, en dernier recours, la forme XAdES-C. Si le signataire ne fournit pas la forme XAdES-T, le vérificateur devra soit créer la forme XAdES-T dès la première réception de la signature électronique, soit conserver un enregistrement protégé de l'heure courante accompagnant la forme XAdES. L'une ou l'autre approche fournit une preuve indépendante de l'existence de la signature à l'instant de sa première vérification, laquelle devrait être proche de sa date de création, et protège ainsi contre une répudiation ultérieure de l'existence de la signature. Si le signataire ne fournit pas la forme XAdES-C, le vérificateur devra créer la forme XAdES-C dès que l'ensemble complet des données de révocation et autres validations sera disponible. En général, la forme XAdES-C ne sera pas créée au même moment que la forme XAdES, car la capture d'éventuelles informations de révocation demandera forcément un certain délai. Également, si un certificat se présente et qu'il est suspendu temporairement, il sera nécessaire d'attendre jusqu'à la fin de la période de suspension.
Le signataire ne devrait créer la forme XAdES-C que dans les situations où il est prêt à patienter suffisamment, après la création de la forme XAdES, avant de distribuer la forme XAdES-C. Cela présente toutefois l'avantage que le vérificateur puisse recevoir l'ensemble complet des données constituant la validité de la signature XAdES.
La figure 1 présente une signature électronique évoluée XML.
Figure 1. Illustration d'une signature XAdES
On montre ci-dessous la structure de la signature XAdES construite par incorporation directe des informations de qualification dans les nouveaux éléments XML ajoutés à [XMLDSIG] (cf. la section 4.3 L'incorporation des propriétés de qualification dans une signature XML pour plus de détails). Dans l'exemple, un caractère ? indique zéro ou une occurrence, un + une ou plusieurs occurrences et un * zéro ou plus occurences.
Le schéma XML, dans la section 5 La syntaxe des propriétés de qualification définit le préfixe ds pour tous les éléments XML qui le sont déjà dans [XMLDSIG] et déclare comme espace de nommage par défaut celui défini pour le présent document. C'est pourquoi, dans les exemples de cette section, les éléments déjà définis dans [XMLDSIG] apparaissent avec le préfixe ds , alors que les nouveaux éléments XML, qui le sont dans ce document, apparaissent sans préfixe.
<ds:Signature ID?>- - - - - - - - -+- - - - -+
<ds:SignedInfo>                  |         |
<ds:CanonicalizationMethod/>   |         |
<ds:SignatureMethod/>          |         |
(<ds:Reference URI? >          |         |
(<ds:Transforms>)?           |         |
<ds:DigestMethod>            |         |
<ds:DigestValue>             |         |
</ds:Reference>)+              |         |
</ds:SignedInfo>                 |         |
<ds:SignatureValue>              |         |
(<ds:KeyInfo>)?- - - - - - - - - +         |
<ds:Object>                                |
<QualifyingProperties>                   |
<SignedProperties>                     |
<SignedSignatureProperties>          |
</SignedSignatureProperties>         |
<SignedDataObjectProperties>         |
</SignedDataObjectProperties>        |
</SignedProperties>                    |
<UnsignedProperties>                   |
<UnsignedSignatureProperties>        |
</UnsignedSignatureProperties>       |
</UnsignedProperties>                  |
</QualifyingProperties>                  |
</ds:Object>                               |
</ds:Signature>- - - - - - - - - - - - - - - +
Les lecteurs doivent tenir compte du fait que les formes XAdES se construisent à partir de la spécification [XMLDSIG] en ajoutant les nouveaux éléments XML, qui contiennent les informations de qualification, dans l'élément [XMLDSIG] ds:Object selon les règles définies par le présent document. Cet élément ds:Object se comporte comme un réceptacle pour l'ensemble entier des propriétés de qualification, définies dans le présent document, regroupées de manière commode.
On PEUT ajouter d'autres éléments [XMLDSIG] ds:Object avec des contenus différents dans la structure illustrée ci-dessus afin satisfaire à des exigences différentes de celles exprimées dans le présent document. Ceci s'applique également aux autres exemples concernant les structures des formes XAdES illustrées dans cette section.
On donnera des explications détaillées sur les objectifs de chaque propriété tout au long de la section 5 La syntaxe des propriétés de qualification .
La figure 2 montre une signature électronique évoluée XML (XAdES) avec les données supplémentaires qui constituent les formes XAdES-T et XAdES-C.
Figure 2. Illustration de signatures XAdES, XAdES-T et XAdES-C
La structure d'une signature XAdES-T est la suivante :
XMLDISG
<ds:Signature ID?>- - - - - - - - +- - - - +- - - +
<ds:SignedInfo>                 |        |      |
<ds:CanonicalizationMethod/>  |        |      |
<ds:SignatureMethod/>         |        |      |
(<ds:Reference URI? >         |        |      |
(<ds:Transforms>)?          |        |      |
<ds:DigestMethod>           |        |      |
<ds:DigestValue>            |        |      |
</ds:Reference>)+             |        |      |
</ds:SignedInfo>                |        |      |
<ds:SignatureValue>             |        |      |
(<ds:KeyInfo>)? - - - - - - - - +        |      |
<ds:Object>                              |      |
<QualifyingProperties>                 |      |
<SignedProperties>                   |      |
<SignedSignatureProperties>        |      |
(SigningTime)                    |      |
(SigningCertificate)             |      |
(SignaturePolicyIdentifier)      |      |
(SignatureProductionPlace)?      |      |
(SignerRole)?                    |      |
</SignedSignatureProperties>       |      |
<SignedDataObjectProperties>       |      |
(DataObjectFormat)*              |      |
(CommitmentTypeIndication)*      |      |
(AllDataObjectsTimeStamp)*       |      |
(IndividualDataObjectsTimeStamp)*|      |
</SignedDataObjectProperties>      |      |
</SignedProperties>                  |      |
<UnSignedProperties>                 |      |
<UnsignedSignatureProperties>      |      |
(CounterSignature)*- - - - - - - +      |
(SignatureTimeStamp)+                   |
</UnsignedSignatureProperties>- - -+      |
</UnsignedProperties>                |      |
</QualifyingProperties>                |      |
</ds:Object>                             |      |
</ds:Signature>- - - - - - - - - - - - - - +- - - +
XAdES      |
La structure d'une signature XAdES-C est la suivante :
<ds:Signature ID?>- - - - - - - - +- - - - - - +-+-+
<ds:SignedInfo>                 |            | | |
<ds:CanonicalizationMethod/>  |            | | |
<ds:SignatureMethod/>         |            | | |
(<ds:Reference URI? >          |            | | |
(<ds:Transforms>)?          |            | | |
<ds:DigestMethod>           |            | | |
<ds:DigestValue>            |            | | |
</ds:Reference>)+             |            | | |
</ds:SignedInfo>                |            | | |
<ds:SignatureValue>             |            | | |
(<ds:KeyInfo>)? - - - - - - - - +            | | |
<ds:Object>                                  | | |
<QualifyingProperties>                     | | |
<SignedProperties>                       | | |
<SignedSignatureProperties>            | | |
(SigningTime)                          | | |
(SigningCertificate)                   | | |
(SignaturePolicyIdentifier)            | | |
(SignatureProductionPlace)?            | | |
(SignerRole)?                          | | |
</SignedSignatureProperties>             | | |
<SignedDataObjectProperties>             | | |
(DataObjectFormat)*                    | | |
(CommitmentTypeIndication)*            | | |
(AllDataObjectsTimeStamp)*             | | |
(IndividualDataObjectsTimeStamp)*      | | |
</SignedDataObjectProperties>            | | |
</SignedProperties>                      | | |
<UnsignedProperties>                     | | |
</UnsignedSignatureProperties>         | | |
(CounterSignature)*- - - - - - - - - + | |
(SignatureTimeStamp)+- - - - - - - - - + |
(CompleteCertificateRefs)                |
(CompleteRevocationRefs)                 |
</UnsignedSignatureProperties>- - - -  +-+ |
</UnsignedProperties>                   | | |
</QualifyingProperties>                    | | |
</ds:Object>                                 | | |
</ds:Signature>- - -  - - - - - - - - - - - - -+-+-+
XadES | |
XAdES-T |
Comme dit auparavant, une signature XAdES se construira à partir de [XMLDSIG] par incorporation d'un élément ds:Object qui se comportera comme le récipient pour l'ensemble entier des propriétés de qualification. Certaines d'entre elles seront signées (informations de qualification signées regroupées dans un nouvel élément SignedProperties — cf. la section 4.2.1 L'élément SignedProperties ) et d'autres ne le seront pas (informations de qualification non signées regroupées dans l'élément UnsignedProperties — cf. la section 4.2.2 L'élément UnsignedProperties ).
Dans la signature XAdES, la signature DEVRA s'appliquer à la manière habituelle de [XMLDSIG] sur le ou les objets-données à signer et sur le jeu entier des propriétés signées (élément SignedProperties). Les informations obligatoires dans l'élément SignedProperties sont :
une référence non équivoque au certificat du signataire, par exemple, le certificat lui-même ou bien une référence vers celui-ci accompagnée d'une empreinte numérique [NdT. hash value] du certificat. Ceci est particulièrement important quand le signataire détient un certain nombre de certificats différents contenant la même clé publique, pour éviter une réclamation du vérificateur au prétexte que la signature implique un autre certificat et une sémantique différente. Cela revêt également une importance, quand le signataire détient des certificats différents contenant des clés publiques différentes, lorsqu'il s'agit de fournir au vérificateur les données correctes pour la vérification de la signature. Finalement, c'est important encore lorsque la clé d'émission de l'autorité de certification fournissant le certificat était compromise (section 5.2.2 L'élément SigningCertificate ) ;
un moyen non équivoque permettant l'identification de la politique de signature selon laquelle la signature électronique a été produite (section 5.2.3 L'élément SignaturePolicyIdentifier ). Cela garantit que le vérificateur pourra utiliser la même politique de signature lors de la procédure de vérification. Une politique de signature est nécessaire pour éclairer le rôle et les engagements précis que le signataire a l'intention d'assumer vis-à-vis des objets-données signés, et pour éviter une réclamation du vérificateur au prétexte qu'une politique de signature différente était impliquée par le signataire ;
la date de signature, précisant l'heure à laquelle le signataire déclare avoir effectué l'opération de signature (section 5.2.1 L'élément SigningTime ).
En outre, la signature peut aussi couvrir d'autres propriétés signées contenant les informations suivantes :
Le ou les formats de ou des objets-données, identifiant le format d'un objet-données signé (quand les signatures électroniques ne sont pas échangées dans un contexte restrictif), afin de permettre au vérificateur leur présentation ou leur utilisation (texte, son ou vidéo) de la manière exacte voulue par le signataire (section 5.2.5 L'élément DataObjectFormat ) ;
Le(s) type(s) d'engagement pris par le signataire au travers de la signature d'un ou plusieurs objets-données signés dans le contexte de la politique de signature choisie (quand un engagement explicite est utilisé) ; ceci sera demandé quand une politique de signature spécifie plus d'un type d'engagement, chacun d'eux pouvant avoir des interprétations légales différentes sur la destination de la signature, par exemple, preuve d'origine, preuve de réception, preuve de création, etc. (section 5.2.6 L'élément CommitmentTypeIndication ) ;
Le rôle déclaré, ou certifié, assumé par le signataire dans la création de la signature (section 5.2.8 L'élément SignerRole ) ;
L'endroit où le signataire prétend avoir produit la signature (section 5.2.7 L'élément SignatureProductionPlace ).
Le signataire ou le vérificateur peuvent construire une signature XAdES-T en ajoutant à la signature XAdES existante un élément XML (comme sous-élément de UnsignedProperties) (section 5.1.3 Le type de données EncapsulatedPKIDataType ) qui encapsule une date sur la valeur de la signature numérique [XMLDSIG], générée par une autorité de datation comme preuve que la signature électronique est antérieure (section 5.3.1 L'élément SignatureTimeStamp ).
Le signataire ou le vérificateur d'une signature électronique peut créer la forme XAdES-C en incorporant, à la forme XAdES-T, les références vers l'ensemble complet des données constituant sa validité (chemin de certification, listes de révocation de certificats, les réponses OCSP [OCSP], etc.). Le signataire ou le vérificateur créeront cette forme en incorporant ces références à la forme XAdES-T, dans un élément XML dont la définition est donnée dans le présent document (sections 5.4.1 L'élément CompleteCertificateRefs et 5.4.2 L'élément CompleteRevocationRefs ). Cet élément s'ajoute comme sous-élément de UnsignedProperties.
La totalité des données de validation (XAdES-C), décrites ci-dessus, peut être étendue pour former une signature avec données de validation étendues (XAdES-X) pour satisfaire aux exigences supplémentaires suivantes :
Premièrement, lorsqu'il existe un risque que l'une des clés employées dans la chaîne de certification ou dans les informations de révocation de statut puisse être compromise. Le cas diffère pour un algorithme craqué et sera abordé plus tard dans la forme archivée d'une signature électronique. Il est nécessaire de dater en outre toutes les références de chemin de certification et celles de révocation de statut, qui sont contenues dans la signature XAdES-C (cf. section 5.5.2 L'élément RefsOnlyTimeStamp ). Sinon, on peut appliquer la date à la signature numérique (élément ds:Signature), à la (ou aux) date(s) présente(s) dans la forme XAdES-T et aux références mentionnées ci-dessus (cf. section 5.5.1 L'élément SigAndRefsTimeStamp ).
Deuxièmement, lorsque les données de chemin de certification et celles de statut de révocation ne sont pas stockées ailleurs pour le long terme, il est nécessaire alors de les ajouter à la signature (XAdES-X-L).
Figure 3. Illustration de signatures XAdES-X et XAdES-X-L
Remarquez qu'il est possible d'omettre la date sur les références de chemin de certification et les références de statut de révocation tout en ajoutant les données de chemin de certification et les données de statut de révocation.
Les données de validation XAdES-X sont créées en ajoutant, à une signature XAdES-C générée antérieurement, une date sur les références vers l'ensemble complet des données constituant sa validité ou sur la séquence formée par l'élément ds:SignatureValue, la (ou les) date(s) présente(s) dans la forme XAdES-T et les références mentionnées ci-dessus. Encore une fois, cette nouvelle forme sera obtenue en ajoutant un élément XML qui encapsule commodément cette date (cf. les sections 5.5.1 L'élément SigAndRefsTimeStamp et 5.5.2 L'élément RefsOnlyTimeStamp ). Cet élément s'ajoutera comme sous-élément de UnsignedProperties.
La signature XAdES-X-L sera produite en incorporant les informations de chemin de certification et de révocation (les réponses CRL ou OCSP) commodément encapsulées par des éléments XML (cf. les sections 5.6.1 L'élément CertificateValues et 5.6.2 L'élément RevocationValues ). Ces éléments s'ajouteront comme sous-éléments de UnsignedProperties.
La structure d'une signature XAdES-X est la suivante :
<ds:Signature ID?>- - - - - - - - +- - - - - - +-+-+-+
<ds:SignedInfo>                 |            | | | |
<ds:CanonicalizationMethod/>  |            | | | |
<ds:SignatureMethod/>         |            | | | |
(<ds:Reference URI? >         |            | | | |
(<ds:Transforms>)?          |            | | | |
<ds:DigestMethod>           |            | | | |
<ds:DigestValue>            |            | | | |
</ds:Reference>)+             |            | | | |
</ds:SignedInfo>                |            | | | |
<ds:SignatureValue>             |            | | | |
(<ds:KeyInfo>)? - - - - - - - - +            | | | |
<ds:Object>                                  | | | |
<QualifyingProperties>                     | | | |
<SignedProperties>                       | | | |
<SignedSignatureProperties>            | | | |
(SigningTime)                        | | | |
(SigningCertificate)                 | | | |
(SignaturePolicyIdentifier)          | | | |
(SignatureProductionPlace)?          | | | |
(SignerRole)?                        | | | |
</SignedSignatureProperties>           | | | |
<SignedDataObjectProperties>           | | | |
(DataObjectFormat)*                  | | | |
(CommitmentTypeIndication)*          | | | |
(AllDataObjectsTimeStamp)*           | | | |
(IndividualDataObjectsTimeStamp)*    | | | |
</SignedDataObjectPropertiesSigned>    | | | |
</SignedProperties>                      | | | |
<UnsignedProperties>                     | | | |
</UnsignedSignatureProperties>         | | | |
(CounterSignature)*- - - - - - - - - + | | |
(SignatureTimeStamp)+- - - - - - - -   + | |
(CompleteCertificateRefs)                | |
(CompleteRevocationRefs)- - - - - - - - -+ |
((SigAndRefsTimeStamp)* |                  |
(RefsOnlyTimeStamp)*)                      |
</UnsignedSignatureProperties>- - - - -+-+-+ |
</UnsignedProperties>                    | | | |
</QualifyingProperties>                    | | | |
</ds:Object>                                 | | | |
</ds:Signature>- - - - - - - - - - - - - - - - +-+-+-+
XAdES | | |
XAdES-T | |
XAdES-C |
La structure d'une signature XAdES-X-L est montrée ci-dessous.
<ds:Signature ID?>- - - - - - - - +- - - - - +-+-+-+-+
<ds:SignedInfo>                 |          | | | | |
<ds:CanonicalizationMethod/>  |          | | | | |
<ds:SignatureMethod/>         |          | | | | |
(<ds:Reference URI? >         |          | | | | |
(<ds:Transforms>)?          |          | | | | |
<ds:DigestMethod>           |          | | | | |
<ds:DigestValue>            |          | | | | |
</ds:Reference>)+             |          | | | | |
</ds:SignedInfo>                |          | | | | |
<ds:SignatureValue>             |          | | | | |
(<ds:KeyInfo>)?  - - - - - - - -+          | | | | |
<ds:Object>                                | | | | |
<QualifyingProperties>                   | | | | |
<SignedProperties>                     | | | | |
<SignedSignatureProperties>          | | | | |
(SigningTime)                      | | | | |
(SigningCertificate)               | | | | |
(SignaturePolicyIdentifier)        | | | | |
(SignatureProductionPlace)?        | | | | |
(SignerRole)?                      | | | | |
</SignedSignatureProperties>         | | | | |
<SignedDataObjectProperties>         | | | | |
(DataObjectFormat)*                | | | | |
(CommitmentTypeIndication)*        | | | | |
(AllDataObjectsTimeStamp)*         | | | | |
(IndividualDataObjectsTimeStamp)*  | | | | |
</SignedDataObjectPropertiesSigned>  | | | | |
</SignedProperties>                    | | | | |
<UnsignedProperties>                   | | | | |
</UnsignedSignatureProperties>       | | | | |
(CounterSignature)*- - - - - - - - + | | | |
(SignatureTimeStamp)+- - - - - - - - + | | |
(CompleteCertificateRefs)              | | |
(CompleteRevocationRefs)- - - - - - - -+ | |
((SigAndRefsTimeStamp)*  |               | |
(RefsOnlyTimeStamp)*)- - - - - - - - - - + |
(CertificatesValues)                       |
(RevocationValues)                         |
</UnsignedSignatureProperties>- - - -+-+-+-+ |
</UnsignedProperties>                  | | | | |
</QualifyingProperties>                  | | | | |
</ds:Object>                               | | | | |
</ds:Signature>- - - - - - - - - - - - - - - +-+-+-+-+
XAdES | | | |
XAdES-T | | |
XAdES-C | |
XAdES-X |
La signature XAdES-X-L devrait être datée avant que les algorithmes, les clés et les autres données cryptographiques employés au moment où la signature XAdES-C a été construite ne se révèlent faibles et que les fonctions cryptographiques ne deviennent vulnérables. Cette datation devrait, si possible, faire appel à des algorithmes plus forts (ou des longueurs de clé plus grandes) que ceux des dates originales. On appelle ces données et dates supplémentaires les données de validation des archives (XAdES-A). L'opération de datation peut se réitérer à chaque fois que la protection de la datation antérieure d'une signature XAdES-A s'affaiblira. (Une signature XAdES-A peut donc comporter plusieurs dates imbriquées).
La gestion de la forme XAdES-A est optionnelle.
La figure 4 montre un exemple de signature électronique évoluée XML (XAdES), avec les données de validation supplémentaires pour les formes XAdES-C et XAdES-X-L datées, formant la signature XAdES-A.
Figure 4. Illustration d'une signature XAdES-A
La structure d'une signature XAdES-A est la suivante :
<ds:Signature ID?>- - - - - - - - +- - - - - +-+-+-+-+-+
<ds:SignedInfo>                 |          | | | | | |
<ds:CanonicalizationMethod/>  |          | | | | | |
<ds:SignatureMethod/>         |          | | | | | |
(<ds:Reference (URI=)? >      |          | | | | | |
(<ds:Transforms>)?          |          | | | | | |
<ds:DigestMethod>           |          | | | | | |
<ds:DigestValue>            |          | | | | | |
</ds:Reference>)+             |          | | | | | |
</ds:SignedInfo>                |          | | | | | |
<ds:SignatureValue>             |          | | | | | |
(<ds:KeyInfo>)? - - - - - - - - +          | | | | | |
<ds:Object>                                | | | | | |
<QualifyingProperties>                   | | | | | |
<SignedProperties>                     | | | | | |
<SignedSignatureProperties>          | | | | | |
(SigningTime)                      | | | | | |
(SigningCertificate)               | | | | | |
(SignaturePolicyIdentifier)        | | | | | |
(SignatureProductionPlace)?        | | | | | |
(SignerRole)?                      | | | | | |
</SignedSignatureProperties>         | | | | | |
<SignedDataObjectProperties>         | | | | | |
(DataObjectFormat)*                | | | | | |
(CommitmentTypeIndication)*        | | | | | |
(AllDataObjectsTimeStamp)*         | | | | | |
(IndividualDataObjectsTimeStamp)*  | | | | | |
</SignedDataObjectPropertiesSigned>  | | | | | |
</SignedProperties>                    | | | | | |
<UnsignedProperties>                   | | | | | |
</UnsignedSignatureProperties>       | | | | | |
(CounterSignature)*- - - - - - - - + | | | | |
(SignatureTimeStamp)+- - - - - - - - + | | | |
(CompleteCertificateRefs)              | | | |
(CompleteRevocationRefs)- - - - - - - -+ | | |
((SigAndRefsTimeStamp)*  |               | | |
(RefsOnlyTimeStamp)*)- - - - - - - - - - + | |
(CertificatesValues)                       | |
(RevocationValues)- - - - - - - - - - - - -+ |
(ArchiveTimeStamp)+                          |
</UnsignedSignatureProperties>- - - -+-+-+-+-+ |
</UnsignedProperties>                  | | | | | |
</QualifyingProperties>                  | | | | | |
</ds:Object>                               | | | | | |
</ds:Signature>- - - - - - - - - - - - - - - +-+-+-+-+-+
XAdES | | | | |
XAdES-T | | | |
XAdES-C | | |
XAdES-X | |
XAdES-X-L |
Cette forme sera produite en ajoutant, à la signature XAdES-X-L, des éléments XML contenant des dates commodément encapsulées. Les dates seront calculées sur les données à l'intérieur de la structure antérieure : XAdES-X-L pour la première, puis XAdES-X-L plus d'autres dates pour les suivantes (cf. section 5.7.1 L'élément ArchiveTimeStamp ). Ces éléments s'ajouteront comme sous-éléments de UnsignedProperties.
L'adresse URI de l'espace de nommage XML que les mises en œuvres de ce document doivent utiliser est la suivante :
http://uri.etsi.org/01903/v1.1.1#
Les déclarations d'espaces de nommage suivantes s'appliquent aux définitions de schéma XML pour le présent document :
xmlns="http://uri.etsi.org/01903/v1.1.1#"
targetNamespace="http://uri.etsi.org/01903/v1.1.1#"
Cette section introduit la syntaxe concernant l'ajout d'informations de qualification à une signature XML.
La section 4.1 Les critères techniques liste un ensemble de critères techniques qui ont été pris en compte pour cette proposition de syntaxe.
La section 4.2 L'élément QualifyingProperties spécifie un élément XML qui se comporte comme un conteneur pour les informations de qualification. En outre, elle décrit le rapport entre la signature XML et cet élément conteneur.
La section 4.3 L'incorporation des propriétés de qualification dans une signature XML montre deux façons d'incorporer ces informations de qualification dans une signature [XMLDSIG].
Les considérations suivantes ont été prises en compte pour la spécification de la syntaxe des informations de qualification sur les signatures XML :
Le présent document spécifie comment ajouter des informations de qualification à une signature XML, de sorte que celle-ci satisfasse à la fois aux exigences d'une signature électronique évoluée, selon la Directive Européenne [EU-DIR-ESIG], et qu'elle reste valide sur une grande période de temps. La norme TS 101 733 [ESI] identifie toutes les informations nécessaires qu'il faut ajouter pour satisfaire à ces conditions. En outre, elle définit les structures de données adéquates pour ces propriétés de qualification, en utilisant la notation ASN.1 convenant aux signatures électroniques [CMS]. Le but du présent document est de spécifier les propriétés de qualification XML similaires qui transportent ces informations de qualification et qui amendent la spécification [XMLDSIG].
Les nouvelles propriétés de qualification XML ne devraient pas être le résultat d'un processus se bornant à une traduction de ASN.1 vers XML. Cela impliquerait de négliger les différences syntaxiques entre les signatures [CMS] et [XMLDSIG], tels que le nombre des signataires possibles et les multiples objets-données signés couverts par une seule signature, tout comme d'ignorer les fonctionnalités puissantes de l'environnement XML, telle que la liaison des informations au moyen d'identificateurs de ressources uniformes [URI].
Le langage XML Schema [XML-schema-part-1] [XML-schema-part-2] a été choisi comme langage normatif pour la définition des nouvelles structures XML dans ce document plutôt que le vocabulaire de la définition de type de document (DTD) défini dans XML 1.0 [XML], car le premier reconnaît les espaces de nommage, permet de réutiliser les structures existantes et permet de définir plus strictement les contenus autorisés. Toutefois, on fournit une définition DTD des nouvelles structures XML dans une annexe informative du présent document.
Les structures XML définies dans des normes XML apparentées, telles que dans les spécifications XML Schema [XML-schema-part-2] et la syntaxe et le traitement XML Signature [XMLDSIG], ont été réutilisées quand cela était nécessaire.
L'élément QualifyingProperties se comporte comme un conteneur pour toutes les informations de qualification à ajouter à une signature XML. Cet élément a la structure suivante :
<xsd:element name="QualifyingProperties" type="QualifyingPropertiesType"/>
<xsd:complexType name="QualifyingPropertiesType">
<xsd:element name="SignedProperties" type="SignedPropertiesType"
<xsd:element name="UnsignedProperties" type="UnsignedPropertiesType"
<xsd:attribute name="Target" type="xsd:anyURI" use="required"/>
Les propriétés de qualification se répartissent en propriétés cryptographiquement liées à (c'est-à-dire, signées par) la signature XML (SignedProperties ) et en celles qui ne sont pas cryptographiquement liées à la signature XML (UnsignedProperties).
L'élément SignedProperties doit être couvert par un élément Reference de la signature XML. Pour être conforme au présent document, l'élément SignedProperties DOIT exister.
L'attribut obligatoire Target se rapporte à la signature XML à laquelle les propriétés de qualification sont associées.
L'attribut optionnel Id peut servir à établir une référence à un élément conteneur QualifyingProperties.
L'élément SignedProperties contient un certain nombre de propriétés qui sont collectivement signées par la signature [XMLDSIG].
Pour être conforme au présent document, l'élément SignedSignatureProperties DOIT apparaître.
La définition de schéma de l'élément SignedProperties est la suivante :
<xsd:element name="SignedProperties" type="SignedPropertiesType" />
<xsd:complexType name="SignedPropertiesType">
<xsd:element name="SignedSignatureProperties"
type="SignedSignaturePropertiesType"/>
<xsd:element name="SignedDataObjectProperties"
type="SignedDataObjectPropertiesType" minOccurs="0"/>
L'élément SignedProperties DOIT contenir des propriétés qui qualifient la signature [XMLDSIG] en question ou bien le signataire. Elles sont incluses en contenu de l'élément SignedSignatureProperties.
L'élément SignedProperties PEUT aussi contenir des propriétés qui qualifient certains des objets-donnés signés. Ces propriétés apparaissent en contenu de l'élément SignedDataObjectProperties.
L'attribut optionnel Id peut servir à établir une référence à l'élément SignedProperties.
L'élément UnsignedProperties contient un certain nombre de propriétés qui ne sont pas signées par la signature [XMLDSIG].
<xsd:element name="UnsignedProperties" type="UnsignedPropertiesType" />
<xsd:complexType name="UnsignedPropertiesType">
<xsd:element name="UnsignedSignatureProperties"
type="UnsignedSignaturePropertiesType" minOccurs="0"/>
<xsd:element name="UnsignedDataObjectProperties"
type="UnsignedDataObjectPropertiesType" minOccurs="0"/>
L'élément UnsignedProperties PEUT contenir des propriétés qui qualifient la signature XML en question ou bien le signataire. Elles sont incluses en contenu de l'élément UnsignedSignatureProperties.
L'élément UnsignedProperties PEUT aussi contenir des propriétés qui qualifient certains des objets-données signés. Ces propriétés apparaissent en contenu de l'élément UnsignedDataObjectProperties.
L'attribut optionnel Id peut servir à établir une référence à l'élément UnsignedProperties.
Cet élément contient des propriétés qui qualifient la signature XML spécifiée par l'attribut Target de l'élément conteneur QualifyingProperties.
<xsd:element name="SignedSignatureProperties"   type="SignedSignaturePropertiesType" />
<xsd:complexType name="SignedSignaturePropertiesType">
<xsd:element name="SigningTime" type="xsd:dateTime"/>
<xsd:element name="SigningCertificate" type="CertIDListType"/>
<xsd:element name="SignaturePolicyIdentifer"
type="SignaturePolicyIdentifierType"/>
<xsd:element name="SignatureProductionPlace" type="SignatureProductionPlaceType"
<xsd:element name="SignerRole" type="SignerRoleType" minOccurs="0"/>
La propriété de qualification SigningTime est décrite en détails dans la section 5.2.1 L'élément SigningTime , la propriété SigningCertificate dans la section 5.2.2 L'élément SigningCertificate , SignaturePolicyIdentifier dans la section 5.2.3 L'élément SignaturePolicyIdentifier , SignatureProductionPlace dans la section 5.2.7 L'élément SignatureProductionPlace element et SignerRole dans la section 5.2.8 L'élément SignerRole .
Cet élément contient des propriétés qui qualifient certains des objets-données signés.
<xsd:element name="SignedDataObjectProperties"   type="SignedDataObjectPropertiesType"/>
<xsd:complexType name="SignedDataObjectPropertiesType">
<xsd:element name="DataObjectFormat" type="DataObjectFormatType"
<xsd:element name="CommitmentTypeIndication"
type="CommitmentTypeIndicationType" minOccurs="0"
<xsd:element name="AllDataObjectsTimeStamp" type="TimeStampType"
<xsd:element name="IndividualDataObjectsTimeStamp" type="TimeStampType"
La propriété de qualification AllDataObjectsTimeStamp est décrite en détails dans la section 5.2.9 L'élément AllDataObjectsTimeStamp , la propriété IndividualDataObjectsTimeStamp dans la section 5.2.10 L'élément IndividualDataObjectsTimeStamp , DataObjectFormat dans la section 5.2.5 L'élément DataObjectFormat et CommitmentTypeIndication dans la section 5.2.6 L'élément CommitmentTypeIndication .
Toutes ces propriétés qualifient l'objet-données signé après que toutes les transformations obligatoires ont été effectuées.
Cet élément contient des propriétés qui qualifient la signature XML spécifiée par l'attribut Target de l'élément conteneur QualifyingProperties. Le contenu de cet élément n'est pas couvert par la signature XML.
<xsd:element name="UnsignedSignatureProperties"   type="UnsignedSignaturePropertiesType"/>
<xsd:complexType name="UnsignedSignaturePropertiesType">
<xsd:element name="CounterSignature" type="CounterSignatureType"
<xsd:element name="SignatureTimeStamp" type="TimeStampType"
<xsd:element name="CompleteCertificateRefs"
type="CompleteCertificateRefsType" minOccurs="0"/>
<xsd:element name="CompleteRevocationRefs"
type="CompleteRevocationRefsType" minOccurs="0"/>
<xsd:element name="SigAndRefsTimeStamp" type="TimeStampType"
<xsd:element name="RefsOnlyTimeStamp" type="TimeStampType"
<xsd:element name="CertificateValues" type="CertificateValuesType"
<xsd:element name="RevocationValues" type="RevocationValuesType"
<xsd:element name="ArchiveTimeStamp" type="TimeStampType"
La propriété de qualification CounterSignature est décrite en détails dans la section 5.2.4 L'élément CounterSignature , la propriété SignatureTimeStamp dans la section 5.3.1 L'élément SignatureTimeStamp , CompleteCertificateRefs dans la section 5.4.1 L'élément CompleteCertificateRefs , CompleteRevocationRefs dans la section 5.4.2 L'élément CompleteRevocationRefs , SigAndRefsTimeStamp dans la section 5.5.1 L'élément SigAndRefsTimeStamp , RefsOnlyTimeStamp dans la section 5.5.2 L'élément RefsOnlyTimeStamp , CertificateValues dans la section 5.6.1 L'élément CertificateValues , RevocationValues dans la section 5.6.2 L'élément RevocationValues et ArchiveTimeStamp dans la section 5.7.1 L'élément ArchiveTimeStamp .
Cet élément contient des propriétés qui qualifient certains des objets-données signées. La signature générée par le signataire ne couvre pas le contenu de cet élément.
<xsd:element name="UnsignedDataObjectProperties" type="UnsignedDataObjectPropertiesType" />
<xsd:complexType name="UnsignedDataObjectPropertiesType">
<xsd:element name="UnsignedDataObjectProperty" type="AnyType"
La norme TS 101 733 [ESI] ne définit aucun usage pour une quelconque propriété non signée qualifiant l'objet-données signé. Le présent document incorpore pourtant un tel élément par souci d'exhaustivité et pour tenir compte de besoins potentiels futurs pour inclure ces types de propriétés. La définition de schéma laisse ouverte la définition des contenus de ce type. Le type AnyType est défini dans la section 5.1.1 Le type de données AnyType .
Le présent document fait appel à l'élément auxilliaire ds:Object de la spécification [XMLDSIG]. On DOIT l'utiliser pour incorporer les propriétésf de qualification dans la signature [XMLDSIG]. En principe, deux moyens différents sont proposés pour cette incorporation :
l'incorporation directe, qui signifie que l'élément QualifyingProperties est placé comme sous-élément de l'élément ds:Object ;
l'incorporation indirecte, qui signifie qu'un élément QualifyingPropertiesReference est placé comme sous-élément de l'élément ds:Object. Cet élément contient des informations sur un élément QualifyingProperties qui est stocké à un endroit différent de celui de la signature (cf. la section 4.3.2 L'élément QualifyingPropertiesReference ).
Cependant, les restrictions suivantes s'appliquent concernant l'utilisation des éléments ds:Object, QualifyingProperties et QualifyingPropertiesReference :
toutes les instances des éléments QualifyingProperties et QualifyingPropertiesReference DOIVENT apparaître dans un seul élément ds:Object ;
une seule instance au plus de l'élément QualifyingProperties peut apparaître dans cet unique élément ds:Object ;
toutes les propriétés signées doivent apparaître dans un seul élément QualifyingProperties. Cet élément peut soit être un sous-élément de l'élément ds:Object (incorporation directe), soit être appelé par un élément QualifyingPropertiesReference. Voir la section 4.3.1 L'élément SigningProperties pour des informations sur la façon de signer les propriétés ;
zéro instance (ou plus) de l'élément QualifyingPropertiesReference peut apparaître dans un seul élément ds:Object.
Ce document ne définit pas les mécanismes nécessaires pour garantir le stockage correct des éléments QualifyingProperties distribués (c'est-à-dire que les propriétés sont stockées par l'entité chargée de le faire et que celles-ci ne doivent pas être indétectables si elles sont modifiées).
Comme dit auparavant, toutes les propriétés à protéger par la signature doivent être rassemblées dans une seule instance de l'élément QualifyingProperties. En réalité, ces propriétés sont les sous-éléments du sous-élément SignedProperties de cet élément.
Pour protéger les propriétés avec la signature, on doit ajouter un élément ds:Reference à la signature [XMLDSIG]. Cet élément ds:Reference DOIT être composé de telle sorte qu'il utilise l'élément SignedProperties, mentionné ci-dessus, comme entrée [NdT. input] du calcul de l'empreinte numérique [NdT. digest] qui lui correspond.
En outre, le présent document IMPOSE d'utiliser l'attribut Type de cet élément ds:Reference en question, dont la valeur est :
http://uri.etsi.org/01903/v1.1.1#SignedProperties
Cette valeur indique que les données utilisées pour le calcul de l'empreinte numérique représentent un élément SignedProperties, ce qui aide l'application de vérification à détecter les propriétés signées d'une signature conforme au présent document.
Si l'élément QualifyingProperties contenant l'élément SignedProperties est stocké à un endroit différent de celui de la signature (incorporation indirecte), le résultat du traitement de l'adresse URI et des transformations dans cet élément ds:Reference doit être le même que le résultat du traitement de l'adresse URI et des transformations dans l'élément QualifyingPropertiesReference, qui pointe vers l'élément QualifyingProperties mentionné précédemment.
Cet élément contient des informations sur un élément QualifyingProperties qui est stoké à un endroit différent de celui de la signature, par exemple, dans un autre document XML.
<xsd:element name="QualifyingPropertiesReference"   type="QualifyingPropertiesReferenceType"/>
<xsd:complexType name="QualifyingPropertiesReferenceType">
L'attribut obligatoire URI fournit un identificateur pour la localisation de l'élément QualifyingProperties. Ceci pourrait être, par exemple, une adresse URL vers un site Web où récupérer des informations ou bien un nom auquel les applications participantes peuvent recourir pour identifier un élément QualifyingProperties particulier.
L'élément optionnel ds:Transforms peut servir à spécifier une chaîne de transformations à appliquer aux données référencées par l'attribut URI afin d'obtenir la représentation effective de l'élément QualifyingProperties. Le modèle de traitement pour la chaîne de transformations est défini dans la section 4.3.3.2 Le modèle de traitement des références de la spécification [XMLDSIG].
L'attribut optionnel Id peut servir à établir une référence à l'élément QualifyingPropertiesReference.
La section 5.1 La syntaxe auxilliaire réunit un ensemble de structures auxilliaires qui seront nécessaires par la suite, tandis que chacune des sections restantes correspond à une propriété de qualification particulière.
La section 5.2 La syntaxe de la forme XAdES décrit en détails les propriétés de qualification qui peuvent apparaître dans les formes de signature électronique XAdES, comme décrit dans la section 4 Aperçu de la syntaxe .
La section 5.3 La syntaxe de la forme XAdES-T décrit en détails les propriétés de qualification qui peuvent apparaître dans les formes de signature électronique XAdES-T, comme décrit dans la section 4 Aperçu de la syntaxe .
La section 5.4 La syntaxe de la forme XAdES-C décrit en détails les propriétés de qualification, appliquées aux données de validation, qui peuvent apparaître dans la forme XAdES-C.
La section 5.5 La syntaxe de la forme XAdES-X décrit en détails les propriétés de qualification, appliquées aux différentes dates, qui peuvent apparaître dans la forme XAdES-X.
La section 5.6 La syntaxe de la forme XAdES-X-L décrit en détails les propriétés de qualification, appliquées aux données de validation, qui peuvent apparaître dans la forme XAdES-X-L.
Enfin, la section 5.7 La syntaxe de la forme XAdES-A décrit en détails les propriétés de qualification, appliquées aux différentes dates, qui peuvent apparaître dans la forme XAdES-A.
Les trois structures XML auxilliaires suivantes servent à plusieurs reprises pour les autres sections.
Le type de données de schéma AnyType suit un modèle de contenu qui autorise une séquence d'éléments XML arbitraires, de longueur illimitée. En outre, un élément de ce type de données peut porter un nombre illimité d'attributs arbitraires. On l'utilise dans le reste de cette section toutes les fois où le contenu d'un élément XML est laissé libre.
Le type de données ObjectIdentifierType peut servir à identifier un objet-données particulier.
Il permet la spécification de l'identificateur unique et permanent d'un objet. En outre, on peut y trouver une description textuelle de la nature de l'objet-données et un certain nombre de références vers des documents avec d'autres informations sur la nature de l'objet-données.
<xsd:element name="Identifier" type="xsd:anyURI"/>
<xsd:element name="DocumentationReferences"
type="DocumentationReferencesType" minOccurs="0"/>
L'élément Identifier contient un identificateur permanent. Une fois assigné, l'identificateur ne peut plus l'être à nouveau. Il gère à la fois le mécanisme utilisé pour identifier les objets en ASN.1 et celui qui est habituellement utilisé pour identifier les objets dans un environnement XML :
En ASN.1, on utilise un identificateur d'objet (OID) pour identifier un objet. Pour coder un identificateur OID en utilisant le type ObjectIdentifierType, l'élément Identifier DOIT contenir l'identificateur OID sous la forme d'un nom de ressource uniforme (URN) [URN-OID], selon la façon définie par le document RFC3061. On PEUT donner une représentation textuelle qui permet aux humains de mieux comprendre la destination de l'identificateur OID en recourant à l'élément Description. Le présent document ne suggère aucun format particulier pour une telle représentation textuelle ;
Dans un environnement XML, les objets sont typiquement identifiés au moyen d'adresses URI [URI]. Pour coder une telle adresse URI en se servant du type ObjectIdentifierType, on DOIT utiliser l'élément Identifier.
Remarquez que, puisqu'une telle adresse URI repésente un identificateur PERMANENT, on devrait la choisir soigneusement. Par exemple, si un domaine cesse d'exister, cela invalidera également tous les identificateurs spécifiés sous ce domaine, puisque le domaine est susceptible d'être réassigné à un propriétaire différent, ce qui pourrait alors changer la signification des identificateurs. .
S'il existe un identificateur OID et une adresse URI identifiant le même objet, ce document encourage l'emploi de l'identificateur OID, comme cela est expliqué dans la première puce ci-dessus.
L'élément optionnel Description contient un texte informel qui décrit l'identificateur de l'objet.
L'élément optionnel DocumentationReferences se compose d'un nombre arbitraire de références pointant vers une documentation supplémentaire concernant l'identificateur de l'objet.
Le type de données EncapsulatedPKIDataType sert à incorporer un morceau de données de l'infrastructure à clé publique (PKI) dans une structure XML, alors que les données PKI sont codées à l'aide d'un mécanisme de codage ASN.1. Les exemples de telles données PKI, largement employées à l'heure actuelle, comprennent les certificats et les listes de révocation X509, les réponses OCSP, les certificats d'attribution et les dates.
<xsd:complexType name="EncapsulatedPKIDataType">
Le contenu de ce type de données est le morceau de données PKI, codé en base64 comme défini dans la spécification [XMLDSIG]. L'attribut optionnel ID peut servir à établir une référence vers un élément ayant ce type de données.
Les dates seront utilisées avec les signatures numériques évoluées XML dans un certain nombre de situations :
Une signature électronique évoluée XML avec date (XAdES-T) comprend une date sur la signature électronique évoluée XML (XAdES) pour protéger d'une répudiation en cas de compromission de la clé ;
Deux mécanismes sont fournis pour la protection contre la malveillance en cas de compromission de la clé d'une autorité de certification, en obtenant la forme XAdES-X :
une date seulement sur toutes les références aux informations de certifation et de révocation d'une signature électronique évoluée XML avec données de validation complètes (XAdES-C) ;
une date calculée sur la valeur de signature, la date de la signature et les références aux informations de certification et de révocation présentes dans la signature électronique évoluée XML avec données de validation complètes (XAdES-C).
Pour établir une validité à long terme à une signature XML, on peut apposer une date sur une signature électronique évoluée XML avec données de validation étendues (XAdES-X-L) pour obtenir une forme XAdES-A. Dans ce cas, la date est appelée date d'archive . On peut rajouter d'autres dates à cette forme XAdES-A au fur et à mesure.
En outre, on peut rajouter à la signature XAdES des dates, en tant que propriétés signées, prouvant que tout ou partie des données-objets à signer ont été créés avant une certaine date.
On obtient une date en envoyant la valeur de l'empreinte numérique des données en question à l'autorité de datation (TSA). La date retournée représente des données signées constituées de la valeur de l'empreinte numérique, l'identité de l'autorité de datation et l'heure de datation. Ceci prouve que les données en question existaient avant l'heure de datation.
Les dates spécifiées dans le présent document seront générées sur des parties sélectionnées de l'élément de signature XAdES.
Voici la définition de schéma du type de données utilisé pour toutes les dates mentionnées ci-dessus :
Chaque élément HashDataInfo contient un attribut uri appelant un objet-données et un élément ds:Transforms indiquant les transformations à effectuer sur cet objet-données, comme décrit dans la spécification [XMLDSIG].
La séquence des éléments HashDataInfo sera utilisée pour produire l'entrée du calcul de l'empreinte numérique, dont le résultat sera inclus dans la requête de datation à envoyer à l'autorité de datation.
L'entrée effective pour le calcul de l'empreinte numérique est déterminée de la manière suivante : chaque objet-données appelé dans la séquence des éléments HashDataInfo est transformé selon les indications de l'élément Transforms correspondant ; une fois que tous les objets-données référencés ont été transformés, les octets résultants sont concaténés dans l'ordre d'appel des objets-données.
La date générée par l'autorité de datation peut être soit un objet-données ASN.1 (comme défini dans [TSP], utiliser EncapsulatedTimeStamp), soit codée en XML (utiliser XMLTimeStamp). Comme il n'existe actuellement aucune norme pour les dates XML, nous fournissons un paramètre fictif [NdT. placeholder] pour une utilisation future.
Cette section décrit en détails les propriétés de qualification qui peuvent apparaître dans les formes de signature électronique évoluée XAdES et XAdES-T, comme décrit dans la section 4 Aperçu de la syntaxe .
La propriété SigningTime spécifie le moment auquel le signataire prétend avoir réalisé le processus de signature.
La recommandation XML Schema [XML-schema-part-2] définit un type XML xsd:dateTime qui autorise l'inclusion de l'information requise. C'est le type retenu pour l'élément SigningTime.
C'est une propriété signée qui qualifie la signature entière.
Une signature électronique XML alignée sur le présent document DOIT contenir exactement un élément SigningTime.
La définition de schéma de cet élément est la suivante :
Comme déclaré en introduction, une signature électronique produite conformément au présent document emporte l'assurance qu'un certain engagement a été pris explicitement, sous couvert d'une politique de signature, à un instant donné, par un signataire identifiable, par exemple, par un nom ou un pseudonyme, ou éventuellement un rôle .
Dans beaucoup de situations réelles, les utilisateurs auront la possibilité d'obtenir de différentes autorités de certification, ou parfois de la même, des certificats différents contenant la même clé publique pour des noms différents. L'avantage principal c'est que l'utilisateur peut utiliser la même clé privée pour des buts différents. L'usage multiple de la clé privée présente un avantage lorsqu'on se sert d'une carte à puce pour la protéger, car la capacité de stockage d'une carte à puce est toujours limitée. Quand plusieurs autorités de certification sont impliquées, chaque certificat différent peut contenir une identité différente, par exemple, comme celle d'une pièce d'identité nationale ou celle d'un employé d'une société. Ainsi, lorsqu'une clé privée sert à plusieurs usages, le certificat est nécessaire pour éclairer le contexte dans lequel cette clé privée a été employée pour la génération de la signature. Quand il existe des possibilités d'usages multiples des clés privées, le signataire doit obligatoirement indiquer au vérificateur quel certificat précis utiliser.
Beaucoup de systèmes actuels ajoutent simplement le certificat après les données signées et sont donc vulnérables à diverses attaques par substitution. Un exemple d'attaque par substitution serait celui d'une mauvaise autorité de certification qui émettrait un certificat à l'un en se servant de la clé publique d'un autre. Si le certificat du signataire était simplement ajouté en bout de la signature et, de ce fait, non protégé par la signature, n'importe qui pourrait substituer un certificat par un autre et le message apparaîtrait signé par quelqu'un d'autre.
Pour contrer ce type d'attaque, l'identificateur du certificat doit être protégé par la signature numérique du signataire.
La propriété SigningCertificate est conçue pour prévenir la substitution simple du certificat. Cette propriété contient les références des certificats et les empreintes numériques calculées sur ceux-ci.
Le certificat utilisé pour vérifier la signature sera identifié dans la séquence ; la politique de signature peut exiger la présence d'autres certificats, ce qui peut inclure tous les certificats de confiance.
C'est une propriété signée qui qualifie la signature.
Une signature électronique XML alignée sur le présent document DOIT contenir un seul élément SigningCertificate exactement.
<xsd:complexType name="CertIDListType">
<xsd:element name="Cert" type="CertIDType" maxOccurs="unbounded"/>
<xsd:complexType name="CertIDType">
<xsd:element name="CertDigest" type="DigestAlgAndValueType"/>
<xsd:element name="IssuerSerial" type="ds:X509IssuerSerialType"/>
<xsd:complexType name="DigestAlgAndValueType">
<xsd:element name="DigestMethod" type="ds:DigestMethodType"/>
<xsd:element name="DigestValue" type="ds:DigestValueType"/>
L'élément SigningCertificate contient la séquence mentionnée ci-dessus des identificateurs de certificat et des empreintes numériques calculées sur les certificats (cf. les éléments Cert).
L'élément IssuerSerial contient l'identificateur de l'un des certificats référencés dans la séquence. Si l'élément ds:X509IssuerSerial doit apparaître dans la signature pour indiquer le même certificat, alors sa valeur DOIT être cohérente avec l'élément IssuerSerial correspondant.
Si l'utilisateur utilise un certificat d'attribution pour associer un rôle à la signature électronique, ce certificat DOIT être présent dans la propriété SignerRole.
L'élément CertDigest contient l'empreinte numérique de l'un des certificats référencés dans la séquence. Il contient deux éléments : DigestMethod, qui indique l'algorithme de hachage cryptographique [NdT. digest algorithm], et DigestValue, qui contient la valeur de l'empreinte numérique.
Une politique de signature constitue un ensemble de règles pour la création et la validation d'une signature électronique, selon lequel on peut déterminer que la signature est valide. Un contexte légal/contractuel donné peut reconnaître une politique de signature particulière comme satisfaisant à ses exigences.
La politique de signature doit être disponible sous une forme lisible par un humain, de sorte qu'on puisse évaluer sa conformité vis-à-vis des règles du contexte légal ou contractuel dans lequel elle est appliquée.
Pour faciliter le traitement automatique de la signature électronique, les parties de la politique de signature qui spécifient les règles électroniques de création et de validation des signatures électroniques doivent également se présenter sous une forme reconnaissable par un ordinateur.
Si aucune politique de signature n'est identifiée, alors la signature sera considérée comme générée/vérifiée sans les contraintes d'une politique, et elle peut donc n'avoir aucune signification légale ou contractuelle particulières pour une politique de signature.
Comme cela a été dit précédemment, toute signature électronique qui prétend s'aligner sur le présent document doit offrir un moyen permettant d'identifier la signature sans ambiguïté. Le présent document définit deux possibilités :
La signature électronique peut contenir l'identificateur explicite et non équivoque d'une politique de signature accompagné d'une empreinte numérique de cette politique de signature, de sorte que l'on puisse vérifier que la politique sélectionnée par le signataire est bien celle utilisée par le vérificateur. Une politique de signature explicite possède une référence unique globale qui est liée de cette manière à une signature électronique par le signataire comme partie intégrante du calcul de la signature. Dans ce cas, pour une politique de signature explicite donnée, il y aura une forme définitive avec une valeur codée binaire unique. Enfin, une politique de signature, identifiée de cette manière, peut être qualifiée par des informations supplémentaires.
Sinon, la signature électronique peut éviter d'inclure l'identificateur et l'empreinte numérique, mentionnés précédemment. Cela sera possible quand la politique de signature peut se déduire sans ambiguïté de la sémantique du type du ou des objets-données qui sont signés et de certaines autres informations, par exemple, des règlements nationaux ou des accords contractuels privés, stipulant l'utilisation d'une politique de signature donnée pour ce type de contenu de données. Auxquels cas, la signature contiendra un élément vide spécifique indiquant qu'on utilise cette manière implicite d'identifier la politique de signature plutôt que l'identificateur et l'empreinte numérique.
L'identificateur de politique de signature est une propriété signée qui qualifie la signature.
Une signature électronique XML alignée sur le présent document DOIT contenir exactement un seul élément SignaturePolicyIdentifier.
La définition de schéma de ce type est la suivante :
<xsd:element name="SignaturePolicyIdentifier" type="SignaturePolicyIdentifierType"/>
<xsd:element name="SignaturePolicyImplied"/>
<xsd:element name="SigPolicyHash" type="DigestAlgAndValueType"/>
<xsd:element name="SigPolicyQualifiers"
type="SigPolicyQualifiersListType" minOccurs="0"/>
<xsd:complexType name="SigPolicyQualifiersListType">
<xsd:element name="SigPolicyQualifier" type="AnyType"
L'élément SignaturePolicyId apparaîtra lorsqu'on identifie la politique de signature par la première méthode. L'élément SigPolicyId contient un identificateur qui détermine de manière unique une version spécifique de la politique de signature. L'élément SigPolicyHash contient l'identificateur de l'algorithme de hachage cryptographique et l'empreinte numérique de la politique de signature. L'élément SigPolicyQualifier peut contenir d'autres informations qui qualifient l'identificateur de politique de signature. L'élément optionnel ds:Transforms peut contenir les transformations opérées sur le document de la politique de signature avant le calcul de son empreinte numérique. Le modèle de traitement de ces transformations est décrit dans la spécification [XMLDSIG].
Sinon, l'élément SignaturePolicyImplied apparaîtra lorsqu'on emploie la seconde méthode. Cet élément vide indique que le ou les objets-données en cours de signature ainsi que d'autres données externes impliquent une certaine politique de signature.
5.2.3. Les qualificatifs des politiques de signature
Deux qualificatifs pour la politique de signature ont été identifiés jusqu'ici :
une adresse URL, où on peut obtenir une copie de la politique de signature (SP) ;
un avis destiné à l'utilisateur qui s'affichera quand la signature sera vérifiée.
La définition de schéma de ces deux éléments est la suivante :
<xsd:element name="SPURI" type="xsd:anyURI"/>
<xsd:element name="SPUserNotice" type="SPUserNoticeType"/>
<xsd:complexType name="SPUserNoticeType">
<xsd:element name="NoticeRef" type="NoticeReferenceType" minOccurs="0"/>
<xsd:element name="ExplicitText" type="xsd:string" minOccurs="0"/>
<xsd:complexType name="NoticeReferenceType">
<xsd:element name="Organization" type="xsd:string"/>
<xsd:element name="NoticeNumbers" type="IntegerListType"/>
<xsd:complexType name="IntegerListType">
<xsd:element name="int" type="xsd:integer" minOccurs="0"
L'élément SPUserNotice est prévu pour s'afficher dès que la signature est validée. L'élément ExplicitText contient le texte de l'avis à afficher. D'autres avis sont susceptibles de provenir de l'organisme émetteur de la politique de signature. L'élément NoticeRef nomme un organisme et identifie par numéro (élément NoticeNumbers) un ensemble de déclarations textuelles préparé par cet organisme, de sorte que l'application puisse obtenir les avis explicites à partir d'un fichier des avis.
Certaines signatures électroniques peuvent n'être valides que si elles portent plus d'une signature. C'est généralement le cas pour la signature d'un contrat entre deux parties. La chronologie des signatures peut ou non revêtir une importance, c'est-à-dire que l'une devrait ou non être appliquée avant l'autre.
Il est nécessaire que plusieurs formes de signatures multiples et de contre-signatures soient gérées, celles-ci se rangeant dans deux catégories de base :
les signatures indépendantes ;
les signatures incorporées.
Les signatures indépendantes sont des signatures parallèles, pour lesquelles la chronologie des signatures n'est pas important. C'est pourquoi une signature indépendante n'apparaîtra pas comme propriété CounterSignature d'une autre signature indépendante.
Les signatures incorporées sont apposées l'une après l'autre : on les utilise quand l'ordre d'application des signatures est important. Les signatures incorporées multiples sont gérées à l'aide de la propriété non signée CounterSignature. Chaque contre-signature est portée par un seul élément CounterSignature, ajouté à l'élément Signature sur lequel l'élément CounterSignature est appliqué.
Dans une signature qualifiée, le contenu de l'élément CounterSignature est constitué d'une ou plusieurs signatures (c'est-à-dire, des éléments ds:Signature) de l'élément SignatureValue, dans la signature qualifiée.
Un élément CounterSignature peut lui-même être qualifié par une propriété CounterSignature. Il est donc possible de construire des séries de contre-signatures de longueur arbitraire.
C'est une propriété non signée qui qualifie la signature.
La figure suivante montre une signature contre-signée :
Figure 5. Utilisation de l'élément CounterSignature
Lors de la présentation de données signées à un utilisateur humain, il peut être important qu'il n'y ait aucune ambiguïté tout comme pour celle faite à la partie utilisatrice [NdT relying party]. Pour que la représentation adéquate (texte, son ou vidéo) soit sélectionnée par la partie utilisatrice, le signataire peut donner une indication du contenu. Si le système de la partie utilisatrice n'emploie pas le format indiqué pour lui présenter l'objet-données, la signature électronique peut être invalidée. La politique de signature, par exemple, peut avoir défini un tel comportement.
L'élément DataObjectFormat fournit des informations décrivant le format de l'objet-données signé. Cet élément DOIT être présent au cas où il est obligatoire de présenter l'objet-données signé à l'utilisateur humain pour vérification. C'est une propriété signée qui qualifie un seul objet-données signé spécifique. Par conséquent, une signature électronique XML alignée sur le présent document PEUT contenir plus d'un élément DataObjectFormat, chacun d'eux qualifiant un seul objet-données signé.
<xsd:element name="ObjectIdentifier" type="ObjectIdentifierType"
<xsd:element name="Encoding" type="xsd:anyURI" minOccurs="0"/>
<xsd:attribute name="ObjectReference" type="xsd:anyURI"
Cet élément peut transmettre :
une information textuelle se rapportant à ou aux objets-données signés dans l'élément Description ;
un identificateur indiquant le type de ou des objet-données signés dans l'élément ObjectIdentifier ;
une indication du type MIME de ou des objets-données signés dans l'élément MimeType ;
une indication du format de codage de ou des objets-données signés dans l'élément Encoding.
Il doit y avoir au moins un élément Description, ou ObjectIdentifier, ou MimeType dans la propriété.
Selon ce qui a été dit en introduction, une signature électronique produite conformément au présent document emporte l'assurance qu'un certain engagement a été pris explicitement, sous couvert d'une politique de signature, à un instant donné, par un signataire identifiable, par exemple, par un nom ou par un pseudonyme, ou éventuellement un rôle .
On peut indiquer le type d'engagement dans la signature électronique :
soit explicitement en utilisant une indication de type d'engagement dans la signature électronique ;
soit implicitement ou explicitement à partir de la sémantique de l'objet-données signé.
Si le type d'engagement indiqué est explicite au moyen d'une indication de type d'engagement dans la signature électronique, l'acceptation d'une signature vérifiée implique celle de la sémantique de ce type d'engagement. La sémantique des indications des types d'engagement devra être spécifiée comme partie de la politique de signature ou bien elle peut être enregistrée pour une utilisation générique à travers plusieurs politiques.
Si la signature inclut une indication de type d'engagement autre que l'une de celles reconnues sous la politique de signature, la signature sera traitée comme étant invalide.
La manière d'indiquer la sémantique de l'objet-données signé n'est pas définie dans le présent document.
Le type d'engagement peut être :
défini comme partie de la politique de signature, auquel cas le type d'engagement obéit à une sémantique précise définie par la politique de signature ;
un type enregistré, auquel cas le type d'engagement obéit à la sémantique précise définie par l'enregistrement, selon les règles de l'autorité d'enregistrement. Cette autorité peut être une organisation commerciale ou une autorisation légale.
La définition d'un type d'enregistrement comprend :
l'identificateur d'objet de l'engagement ;
une séquence de qualificatifs.
Les qualificatifs peuvent fournir plus d'informations sur l'engagement, par exemple, sur le contexte contractuel, légal ou spécifique à une application.
Si la signature électronique ne contient pas de type d'engagement reconnu, alors la sémantique de la signature électronique dépend des objets-données qui sont signés et du contexte dans lequel sert la signature.
C'est une propriété signée qui qualifie le ou les objets-données signés. Par conséquent, une signature électronique XML alignée sur le présent document PEUT contenir plus d'un élément CommitmentTypeIndication.
<xsd:element name="AllSignedDataObjects"/>
<xsd:complexType name="CommitmentTypeQualifiersListType">
<xsd:element name="CommitmentTypeQualifier"
type="AnyType" minOccurs="0" maxOccurs="unbounded"/>
L'élément CommitmentTypeId identifie de manière univoque le type d'engagement pris par le signataire. Un certain nombre d'engagements ont déjà été identifiés dans la norme TS 101 733 [ESI] (et, par conséquent, il leur a été assigné un identificateur d'objet (OID), à savoir :
la preuve d'origine [NdT. proof of origin], indiquant que le signataire reconnaît avoir créé, approuvé et envoyé l'objet-donnée signé ;
la preuve de réception [NdT. proof of receipt], indiquant que le signataire reconnaît avoir reçu le contenu de l'objet-donné signé ;
la preuve de livraison [NdT. proof of delivery], indiquant que le tiers de confiance, qui fournit cette indication, a livré un objet-donnée signé à un dépôt local [NdT. local store] auquel le destinataire de l'objet-donnée signé peut accéder;
la preuve de transmission [NdT. proof of sender], indiquant que l'entité fournissant cette indication a transmis l'objet-donnée signé (mais ne l'a pas forcément créé) ;
la preuve d'homologation [NdT. proof of approval], indiquant que le signataire a approuvé le contenu de l'objet-donnée signé ;
la preuve de création [NdT. proof of creation], indiquant que le signataire a créé l'objet-donnée signé (mais ne l'a pas forcément approuvé, ni envoyé).
Un seul élément ObjectReference se rapporte a un seul élément ds:Reference de l'élément ds:SignedInfo, correspondant à un seul objet-donnée qualifié par cette propriété. Si certains objets-données signés, mais pas tous, partagent le même engagement, un seul élément ObjectReference DOIT apparaître pour chacun d'eux. Par contre, si tous les objets-données signés partagent le même engagement, l'élément vide AllSignedDataObjects DOIT être présent.
L'élément CommitmentTypeQualifiers fournit un moyen permettant d'inclure des informations de qualification supplémentaires sur les engagements pris par le signataire.
Dans certaines transactions, il peut être nécessaire d'indiquer l'endroit où le signataire prétendait se trouver au moment de la création de la signature. On peut inclure une nouvelle propriété fournissant cette information dans la signature.
Cette propriété spécifie l'adresse d'une localisation géographique particulière (par exemple, une ville) associée au signataire.
C'est une propriété signée qui qualifie le signataire.
Une signature électronique XML alignée sur le présent document PEUT contenir un élément SignatureProductionPlace au plus.
<xsd:element name="SignatureProductionPlace" type="SignatureProductionPlaceType"/>
Le nom du signataire est important, mais la position du signataire dans une société ou une organisation peut l'être plus encore. Certains contrats ne peuvent être valides que s'ils sont signés par un utilisateur ayant un rôle particulier, par exemple, un Directeur des ventes. Dans de nombreux cas, l'identité du Directeur des ventes n'a pas tant d'importance que ça, par contre, la certitude que le signataire soit habilité à être le Directeur des ventes par sa société est fondamentale.
Le présent document définit deux façons de produire cette fonctionnalité :
en employant un nom de rôle proclamé ;
en employant un certificat d'attribution contenant un rôle certifié.
À la différence des certificats de clé publique qui lient un identificateur à la clé publique, les certificats d'attribution lient l'identificateur d'un certificat à certains attributs de son propriétaire dont le rôle. L'autorité d'attribution sera la plupart du temps sous le contrôle d'une organisation ou d'une société, les mieux placées pour savoir quels attributs sont appropriés à tel individu. L'autorité d'attribution peut employer ou diriger vers des certificats de clé publique émis par n'importe quelle autorité de certification, pourvu que cette autorité de certification soit digne de confiance. La période de validité des certificats d'attribution peut varier. Elle peut être très courte, par exemple, un jour. Quoique cette approche puisse imposer d'obtenir un nouveau certificat d'attribution chaque jour et valide pour ce jour uniquement, cela peut présenter des avantages car il n'est parfois plus nécessaire de révoquer de tels certificats. Lors de la signature, le signataire devra préciser quel certificat d'attribution celui-ci a sélectionné.
Une signature électronique XML alignée sur le présent document PEUT contenir un élément SignerRole au plus.
<xsd:element name="SignerRole" type="SignerRoleType"/>
<xsd:complexType name="SignerRoleType">
<xsd:element name="ClaimedRoles" type="ClaimedRolesListType"
<xsd:element name="CertifiedRoles" type="CertifiedRolesListType"
<xsd:complexType name="ClaimedRolesListType">
<xsd:element name="ClaimedRole" type="AnyType" maxOccurs="unbounded"/>
<xsd:complexType name="CertifiedRolesListType">
<xsd:element name="CertifiedRole" type="EncapsulatedPKIDataType"
Cette propriété contient une séquence de rôles que le signataire peut endosser (élément SignerRole). Au moins l'un des deux éléments ClaimedRoles ou CertifiedRoles doit être présent.
L'élément ClaimedRoles contient une séquence de rôles proclamés par le signataire mais non certifiés. On peut définir des types de contenu supplémentaires, selon le domaine d'application, pour faire partie de cet élément. Les espaces de nommage donnés aux schémas XML correspondants permettront de les identifier sans ambiguïté au cas où ces rôles utilisent XML.
L'élément CertifiedRoles contient un ou plusieurs certificats d'attribution enveloppés pour le signataire.
L'élément AllDataObjectsTimeStamp contient les éléments ds:Reference datés dans un élément ds:SignedInfo, lequel référence tout ce que le signataire veut signer, sauf l'élément SignedProperties.
L'application doit composer le ou les éléments HashDataInfo, de telle sorte que les données, référencées par les éléments HashDataInfo dans leur ensemble produisent la séquence d'éléments ds:Reference décrite ci-dessus.
L'élément AllDataObjectsTimeStamp est une propriété signée.
Plusieurs instances de cette propriété, issues de diverses autorités de datation, peuvent apparaître dans la même signature XAdES.
<xsd:element name="AllDataObjectsTimeStamp" type="TimeStampType"/>
L'élément IndividualDataObjectsTimeStamp contient la date calculée avant la production de la signature sur une séquence formée de certains éléments ds:Reference dans l'élément ds:SignedInfo. Remarquez que cette séquence ne peut pas contenir d'élément ds:Reference calculé sur l'élément SignedProperties.
L'application doit composer le ou les éléments HashDataInfo, de telle sorte que les données, référencées par les éléments HashDataInfo dans leur ensemble produisent la séquence d'éléments ds:Reference mentionnée précédemment.
L'élément IndividualDataObjectsTimeStamp est une propriété signée qui qualifie le ou les objets-données signés.
Plusieurs instances de cette propriété peuvent apparaître dans la même signature XAdES.
<xsd:element name="IndividualDataObjectsTimeStamp" type="TimeStampType"/>
Cette section décrit en détails les dates qui peuvent apparaître dans la forme XAdES-T.
Une propriété importante des signatures de longue durée c'est que la validité d'une signature, qui a été validée une fois, devra perdurer des mois ou des années après.
Un signataire, un vérificateur ou les deux peuvent être tenus de fournir, à la demande, la preuve que la signature numérique a été créée ou vérifiée pendant les périodes de validité de tous les certificats qui constituent le chemin de certification. Auquel cas, le signataire, le vérificateur ou les deux seront également tenus d'apporter la preuve qu'aucun des certificats des utilisateurs et des autorités de certification utilisés n'a été révoqué lors de la création ou de la vérification de la signature.
Il ne serait vraiment pas admissible de considérer une signature comme étant invalide parce que les clés ou les certificats auront été compromis par la suite. Il est donc nécessaire de pouvoir démontrer que la clé de la signature était valide au moment de la création de la signature pour fournir la preuve sur le long terme de la validité d'une signature.
La datation par une autorité de datation peut apporter cette preuve. On obtient une date en envoyant l'empreinte numérique des données en question à l'autorité de datation. La date qui est retournée est un objet-données signé contenant l'empreinte numérique, l'identité de l'autorité de datation et l'heure de datation. C'est la preuve que les données en question existaient avant l'heure de datation.
La datation d'une signature électronique (XAdES), avant la révocation de la clé privée du signataire et avant l'expiration du certificat, apporte la preuve que la signature a été créée alors que le certificat était valide et avant que la signature n'ait été révoquée.
Si un destinataire veut disposer d'une signature électronique valide, il devra s'assurer avoir obtenu une date valide pour celle-ci, avant que cette clé (et toutes les clés impliquées dans la validation) ne soit révoquée. Plus tôt sera l'obtention de la date après le moment de la signature, mieux ce sera.
Il est important de remarquer que les signatures peuvent être générées hors connexion et être datées plus tard par n'importe qui, par exemple, par le signataire ou tout destinataire concernés par la valeur de la signature. La date peut donc être fournie par le signataire en même temps que l'objet-données signé, ou bien être fournie par le destinataire à la suite de la réception de l'objet-donnée signé.
La politique de validation de la signature peut spécifier un laps de temps maximal autorisé entre l'heure indiquée par l'élément SigningTime et celle indiquée par l'élément SignatureTimeStamp. Si ce délai est dépassé, alors la signature électronique sera considérée comme invalide.
L'élément SignatureTimeStamp encapsule la date par-dessus l'élément ds:SignatureValue.
L'élément SignatureTimeStamp est une propriété non signée qualifiant la signature. La forme XAdES-T PEUT contenir plusieurs éléments SignatureTimeSamp obtenus de différentes autorités de datation.
<xsd:element name="SignatureTimeStamp" type="TimeStampType"/>
L'élément SignatureTimeStamp contient un seul élément HashDataInfo qui se rapporte à l'élément ds:SignatureValue de la signature [XMLDSIG]. C'est-à-dire, l'entrée pour le calcul de l'empreinte numérique de la date est l'élément XML ds:SignatureValue.
Cette section décrit en détail les propriétés de qualification supplémentaires, appliquées aux données de validation, qui peuvent apparaître dans la forme XAdES-C.
Quand on traite des signatures électroniques à long terme, toutes les données mises en œuvre dans la vérification (à savoir, le chemin de certification et les informations de révocation) de telles signatures doivent être stockées et convenablement datées, comme indiqué dans la section 4 Aperçu de la syntaxe , pour des raisons d'arbitrage.
Dans certains environnements, il peut être commode d'ajouter ces données à la signature électronique (comme propriétés non signées) en construisant une forme XAdES-A.
À l'inverse, d'autres systèmes peuvent trouver commode, pour des raisons d'arbitrage, de les archiver ailleurs. Pour cela, chaque signature électronique doit incorporer les références à toutes ces données dans la forme XAdES-C. Ce format se construit, à partir de la forme XAdES-T, en incorporant les données supplémentaires nécessaires pour la validation :
la séquence des références vers l'ensemble complet des certificats, issus des autorités de certification, qui ont été utilisés pour valider la signature électronique jusqu'au certificat du signataire (celui-ci exclus) ;
un ensemble complet des références aux données de révocation qui ont été utilisées dans la validation des certificats du signataire et ceux des autorités de certification.
Cette section définit l'élément XML destiné à porter les références aux certificats, mentionnées précédemment : l'élément CompleteCertificateRefs.
Une signature électronique XML alignée sur le présent document PEUT contenir un élément CompleteCertificateRefs au plus.
<xsd:element name="CompleteCertificateRefs" type="CompleteCertificateRefsType"/>
<xsd:complexType name="CompleteCertificateRefsType">
<xsd:element name="CertRefs" type="CertIDListType" />
L'élément CertRefs contient une séquence d'éléments Cert, déjà définis dans la section 5.2.2 L'élément SigningCertificate , qui incorporent l'empreinte numérique de chaque certificat et, en option, l'identificateur de l'émetteur et du numéro de série.
Comme cela a été dit dans la section précédente, les signatures XAdES-C ajoutent à la forme XAdES-T l'ensemble complet des références aux données de révocation qui ont été utilisées dans la validation des certificats du signataire et ceux des autorités de certification. Ces références permettent de récupérer les données de révocation effectives archivées ailleurs, en cas de litiges, et ainsi de montrer que le vérificateur s'est empressé de prendre connaissance des informations de révocation disponibles.
À l'heure actuelle, la plupart des systèmes gèrent deux types principaux de données de révocation, à savoir les listes de révocation de certificats (CRL) et les réponses des serveurs de statut des certificats en ligne, qui sont obtenues au travers de protocoles conçus dans ces buts, comme le protocole OCSP [OCSP].
Cette section définit l'élément CompleteRevocationRefs qui va transporter l'ensemble complet des informations de révocation utilisées pour la vérification des signatures électroniques.
Une signature électronique XML alignée sur le présent document PEUT contenir un élément CompleteRevocationRefs au plus.
type="CompleteRevocationRefsType"/>
<xsd:complexType name="CompleteRevocationRefsType">
<xsd:element name="CRLRefs" type="CRLRefsType" minOccurs="0"/>
<xsd:element name="OCSPRefs" type="OCSPRefsType" minOccurs="0"/>
<xsd:element name="OtherRefs" type="OtherCertStatusRefsType" minOccurs="0"/>
<xsd:complexType name="CRLRefsType">
<xsd:element name="CRLRef" type="CRLRefType" maxOccurs="unbounded"/>
<xsd:complexType name="CRLRefType">
<xsd:element name="DigestAlgAndValue" type="DigestAlgAndValueType"/>
<xsd:element name="CRLIdentifier" type="CRLIdentifierType" minOccurs="0"/>
<xsd:complexType name="CRLIdentifierType">
<xsd:element name="IssueTime" type="xsd:dateTime" />
<xsd:element name="Number" type="xsd:integer"  minOccurs="0"/>
<xsd:complexType name="OCSPRefsType">
<xsd:element name="OCSPRef" type="OCSPRefType" maxOccurs="unbounded"/>
<xsd:complexType name="OCSPRefType">
<xsd:element name="OCSPIdentifier" type="OCSPIdentifierType"/>
<xsd:element name="DigestAlgAndValue" type="DigestAlgAndValueType"
<xsd:complexType name="OCSPIdentifierType">
<xsd:element name="ResponderID" type="xsd:string"/>
<xsd:element name="ProducedAt" type="xsd:dateTime"/>
<xsd:complexType name="OtherCertStatusRefsType">
<xsd:element name="OtherRef" type="AnyType" maxOccurs="unbounded"/>
L'élément CompleteRevocationRefs peut contenir :
des séquences de références aux listes de révocation de certificats (cf. les éléments CRLRefs) ;
des séquences de références aux réponses OCSP (cf. les éléments OCSPRefs) ;
d'autres références à des formes alternatives de données de révocation (élément OtherRefs).
Chaque élément dans une séquence CRLRefs (élément CrlRef) identifie une liste de révocation de certificats. Cette identification s'effectue au moyen :
de l'empreinte numérique de la liste de révocation de certificats entière codée dans la forme DER de ASN.1 (élément DigestAlgAndValue) ;
d'un ensemble de données (élément CRLIdentifier), comprenant l'émetteur (élément Issuer), l'heure à laquelle la liste de révocation de certificats a été publiée (élément IssueTime) et, en option, le numéro de la liste de révocation de certificats (élément Number). On peut écarter l'élément Identifier quand la liste de révocation de certificats peut être inférée à partir d'autres informations. Son attribut URI pouvait servir à indiquer où la liste de révocation de certificats identifiée était archivée.
Chaque élément dans une séquence OCSPRefs (élément OcspRef) identifie une seule réponse OCSP. Cette identification s'effectue au moyen :
d'un ensemble de données (élément OCSPIdentifier), comprenant le nom du serveur qui a produit la réponse référencée (élément ResponderID) et l'indication de temps dans le champ "ProducedAt" de la réponse référencée (élément ProducedAt). L'attribut optionnel URI peut servir à indiquer où la réponse OCSP identifiée est archivée ;
de l'empreinte numérique calculée sur la réponse OCSP codée dans la forme DER (élément DigestAlgAndValue), puisqu'il peut être nécessaire de différencier deux réponses OCSP, issues du même serveur, ayant leur champ "ProducedAt" dans une même seconde.
On peut inclure des formes alternatives de données de validation dans cette propriété en recourant à l'élément OtherRefs, une séquence dont les membres (des éléments OtherRef) peuvent contenir tous types d'informations.
Cette section décrit en détails les dates qui peuvent apparaître dans la forme XAdES-X.
Les signatures électroniques étendues par datation sont nécessaires quand il y a obligation de se prémunir contre l'éventualité d'une compromission d'une clé de l'autorité de certification dans la chaîne de certification. Un vérificateur peut être tenu de fournir, à la demande, la preuve que le chemin de certification et les informations de révocation, utilisés au moment de la signature, étaient valides, même dans le cas où l'une des clés d'émission ou l'une des clés du répondeur OCSP [OCSP] était compromise par la suite.
Le document courant définit deux façons d'utiliser les dates en protection d'une telle compromission :
dater la séquence formée par la signature numérique (élément ds:Signature), la (ou les) date(s) présente(s) dans la forme XAdES-T, les références du chemin de certification et les références de statut de révocation, quand on utilise une réponse OCSP pour obtenir le statut du certificat du signataire ;
dater seulement les références des chemins de certification et des informations de révocation, quand on utilise une liste de révocation de certificats pour obtenir le statut du certificat du signataire.
Le signataire, le vérificateur ou les deux peuvent obtenir la date.
Quand on se sert d'une réponse OCSP, il est nécessaire de dater cette réponse en particulier, au cas où la clé du répondeur était compromise. Puisque les informations contenues dans la réponse OCSP sont propres à l'utilisateur et spécifiques à un moment, chaque signature reçue nécessite une date individuelle. Au lieu d'apposer la date seulement sur les références des chemins de certification et sur les références des informations de révocation, y compris la réponse OCSP, la date est apposée sur la signature numérique (élément ds:Signature), la (ou les) date(s) présente(s) dans la forme XAdES-T, les références des chemins de certificiation et les références des statuts de révocation. Pour la même dépense cryptographique, cette approche fournit un mécanisme d'intégrité sur la forme XAdES-C. Toute modification peut être immédiatement détectée. Il faudrait remarquer qu'il existe et qu'on peut employer d'autres moyens pour protéger/détecter l'intégrité de la forme XAdES-C.
La forme obtenue par concaténation des dates successives de ce type est une forme XAdES-X (signature électronique évoluée XML avec données de validation étendues).
L'élément SigAndRefsTimeStamp est une propriété non signée qui qualifie la signature. Une forme XAdES-X PEUT contenir plusieurs éléments SigAndRefsTimeStamp, obtenus de diverses autorités de datation.
<xsd:element name="SigAndRefsTimeStamp" type="TimeStampType"/>
L'élément SigAndRefsTimeStamp contient les éléments HashDataInfo suivants :
un qui se rapporte à l'élément ds:SignatureValue de la signature [XMLDSIG] qualifiée ;
un pour chaque élément SignatureTimeStamp présent dans la forme XAdES-T ;
un qui se rapporte à l'élément CompleteCertificateRefs ;
un qui se rapporte à l'élément CompleteRevocationRefs.
C'est-à-dire, l'entrée pour le calcul de l'empreinte numérique de la date est la séquence des éléments XML suivants :
(ds:SignatureValue, SignatureTimeStamp+, CompleteCertificateRefs, CompleteRevocationRefs).
La datation de chaque signature électronique avec données de validation complètes, comme défini ci-dessus, peut être inefficace, notamment lorsqu'on se sert du même ensemble de certificats d'autorités de certification CA et d'informations de listes de révocation de certificats CRL pour valider de nombreuses signatures.
La datation des certificats CA empêchera tout attaquant d'émettre de faux certificats CA susceptibles de revendiquer une existence avant que la clé de l'autorité de certification ne soit compromise. N'importe quel faux certificat CA révèlera que le certificat aura été créé après que la clé de l'autorité de certification a été compromise. De même, la datation des listes de révocation CRL des autorités de certification empêchera tout attaquant d'émettre de fausses listes de révocation CRL susceptibles de revendiquer une existence avant que la clé de l'autorité de certification ne soit compromise.
La datation des certificats et des listes de révocation de certificats souvent utilisés peut se faire de manière centralisée, par exemple, au sein d'une société ou par un tiers. Cette méthode réduit la quantité de données que le vérificateur doit dater ; par exemple, l'opération peut se limiter à juste une date par jour (c'est-à-dire, quand tous les signataires font appel à la même autorité de certification et quand la liste de révocation de certificats s'applique pour le jour entier). Les informations qui nécessitent une datation ne sont pas les certificats et les listes de révocation de certificats réels mais les références précises de ces mêmes certificats et listes de révocation.
L'empreinte numérique envoyée à l'autorité de datation sera calculée sur la concaténation des éléments CompleteCertificateRefs et CompleteRevocationRefs.
L'élément RefsOnlyTimeStamp est une propriété non signée qualifiant la signature. Une forme XAdES-X PEUT contenir plusieurs éléments RefsOnlyTimeStamp, obtenus de diverses autorités de datation.
<xsd:element name="RefsOnlyTimeStamp" type="TimeStampType"/>
L'élément SigAndRefsTimeStamp contient deux éléments HashDataInfo :
le premier se rapporte à l'élément CompleteCertificateRefs ;
le second se rapporte à l'élément CompleteRevocationRefs.
C'est-à-dire, l'entrée pour le calcul de l'empreinte numérique de la date est une séquence des éléments XML suivants :
(CompleteCertificateRefs,CompleteRevocationRefs)
Cette section décrit en détails les propriétés de qualification supplémentaires, appliquées aux données de validation, qui peuvent apparaître dans la forme XAdES-X-L.
Le vérificateur devra prouver que le chemin de certification était valide, au moment de la validation de la signature, jusqu'à un seuil de confiance, conformément aux contraintes de nommage et des contraintes de la politique de certification issues de la politique de validation des signatures . C'est le terme utilisé pour fixer l'ensemble des règles dévolues spécifiquement au processus de validation dans la politique de signature. Il sera nécessaire de capturer tous les certificats du chemin de certification, en commençant par ceux du signataire et en finissant par ceux du chemin de certification de l'un des certificats racines [NdT. trusted root] de la politique de validation des signatures .
Quand il s'agit de signatures électroniques de longue durée, toutes les données utilisées dans la vérification (y compris le chemin de certification) doivent être convenablement archivées. L'archivage de tout le matériel accompagnant la signature électronique donne lieu à la forme XAdES-X-L.
En principes, l'élément CertificateValues contient l'ensemble complet des certificats qui ont été employés pour valider la signature électronique, y compris le certificat du signataire. Néanmoins, il n'est pas nécessaire d'inclure l'un de ces certificats dans cette propriété si ce certificat est déjà présent dans l'élément ds:KeyInfo de la signature.
En fait, le certificat du signataire (référencé dans l'élément obligatoire SigningCertificate) ainsi que tous les certificats référencés dans l'élément CompleteCertificateRefs doivent être présents soit dans l'élément ds:KeyInfo de la signature, soit dans l'élément CertificateValues.
L'élément CertificateValues est une propriété non signée qui qualifie la signature XML.
Une signature électronique XML alignée sur le présent document PEUT contenir un élément CertificateValues au plus.
<xsd:element name="CertificateValues" type="CertificateValuesType"/>
<xsd:complexType name="CertificateValuesType">
<xsd:element name="EncapsulatedX509Certificate"
<xsd:element name="OtherCertificate" type="AnyType"/>
L'élément EncapsulatedX509Certificate peut contenir le codage en base64 d'un certificat X.509 codé dans la forme DER. L'élément OtherCertificate est un paramètre fictif pour de nouveaux formats de certificats.
Quand il s'agit de signatures électroniques de longue durée, toutes les données de révocation utilisées dans la vérification de telles signatures doivent être stockées et convenablement datées, comme cela a été dit dans la section 4 Aperçu de la syntaxe , pour des raisons d'arbitrage.
À l'heure actuelle, la plupart des systèmes gèrent deux types principaux de données de révocation, à savoir les listes de révocation de certificats et les réponses des serveurs de statuts de certificat en ligne, données qui sont obtenues via des protocoles conçus pour ces usages, comme le protocole [OCSP].
Quand il utilise des listes de révocation de certificats pour obtenir des informations de révocation, le vérificateur devra s'assurer, à la première vérification, qu'il obtienne les informations de révocation de certificat appropriées auprès de l'autorité de certification du signataire. Cette opération devrait intervenir dès que possible afin de réduire au minimum l'intervalle entre l'instant de la génération de la signature et celui de sa vérification. Cela implique de vérifier que le numéro de série du certificat du signataire ne soit pas inclus dans la liste de révocation de certificats. Le signataire, le vérificateur ou n'importe quel tiers peuvent chacun obtenir cette liste de révocation de certificats. Si elle est obtenue par le signataire, alors elle devra être transmise au vérificateur. Le vérificateur doit également consulter les autres listes de révocation de certificats des certificats de l'autorité de certification. Il peut être commode d'archiver ces listes de révocation de certificats dans une forme XAdES-A pour faciliter les vérifications ou arbitrages ultérieurs.
Quand il utilise le protocole [OCSP] pour obtenir des informations de révocation, le vérificateur devra s'assurer, à la première vérification, qu'il obtienne une réponse OCSP contenant le statut "valid". Cette opération devrait intervenir dès que possible après la génération de la signature. Le signataire, le vérificateur ou n'importe quel tiers peuvent obtenir cette réponse OCSP. Étant donné que les réponses OCSP sont transitoires, donc non archivées par les tiers de confiance, y compris les autorités de certification, il est du ressort de chaque vérificateur de s'assurer que celles-ci soient stockées dans un endroit sûr. Le moyen le plus simple consiste à les stocker en accompagnement des signatures électroniques dans leur forme XAdES-X-L.
L'élément RevocationValues sert à porter les valeurs des informations de révocation qui doivent être jointes à la signature XML, dans le cas d'une signature électronique évoluée XML avec données de validation étendues (XAdES-X-L).
Une signature électronique XML alignée sur le présent document PEUT contenir un élément RevocationValues au plus.
<xsd:element name="RevocationValues" type="RevocationValuesType"/>
<xsd:complexType name="RevocationValuesType">
<xsd:element name="CRLValues" type="CRLValuesType" minOccurs="0"/>
<xsd:element name="OCSPValues" type="OCSPValuesType" minOccurs="0"/>
<xsd:element name="OtherValues" type="OtherCertStatusValuesType" minOccurs="0"/>
<xsd:attribute name="Id" type="xsd:ID"  use="optional"/>
Les informations de révocation peuvent comprendre les listes de révocation de certificats (CRLValues) ou les réponses d'un serveur de statuts de certificats en ligne (OCSPValues). En outre, un paramètre fictif pour d'autres informations de révocation (OtherValues) est fourni pour une utilisation future.
<xsd:complexType name="CRLValuesType">
<xsd:element name="EncapsulatedCRLValue" type="EncapsulatedPKIDataType"
Les listes de révocation de certificats (CRLValues) consistent en une séquence formée d'au moins une liste de révocation de certificats. Chaque élément EncapsulatedCRLValue contiendra le codage en base64 d'une liste de révocation de certificats codée dans la forme DER.
<xsd:complexType name="OCSPValuesType">
<xsd:element name="EncapsulatedOCSPValue"
type="EncapsulatedPKIDataType" maxOccurs="unbounded"/>
Les réponses OCSP (OCSPValues) consistent en une séquence formée d'au moins une réponse OCSP. L'élément EncapsulatedOCSPValue contient le codage en base64 d'une réponse OCSP codée dans la forme DER.
<xsd:complexType name="OtherCertStatusValuesType">
<xsd:element name="OtherValue" type="AnyType" maxOccurs="unbounded"/>
L'élément OtherValues offre un paramètre fictif pour d'autres informations de révocation qui pourront être utilisées dans le futur. L'élément ObjectIdentifier sert à spécifier le type des informations de révocation contenues par l'élément Value qui suit.
Cette section décrit en détails les dates qui peuvent apparaître dans la forme XAdES-A.
Les progrès du calcul augmentent les probabilités du craquage des algorithmes et donc de la compromission des clés. Il est donc impératif de protéger les signatures électroniques contre cette éventualité.
Au cours du temps, des faiblesses peuvent apparaître dans les algorithmes cryptographiques utilisés pour créer les signatures électroniques (par exemple, en raison du temps disponible suffisant pour une cryptanalyse ou en raison d'avancées dans les techniques de cryptanalyse). Avant que ces faiblesses deviennent critiques, le vérificateur devraient prendre de nouvelles mesures afin de préserver la validité de la signature électronique. On peut employer plusieurs techniques dans ce but selon la nature de la faille cryptographique. Pour simplifier cette tâche, on emploie dans le présent document une seule technique, appelée les données de validation des archives (la forme XAdES-A) qui recouvre tous les cas.
Les données de validation des archives sont constituées des données de validation complètes et de la totalité des certificats et données de révocation, datés ensemble en même temps que la signature électronique. Les données de validation des archives sont nécessaires si la fonction de hachage cryptographique et les algorithmes cryptographiques, qui ont été utilisés pour créer la signature, ne sont plus sûrs. En outre, si la sécurité de la fonction de hachage cryptographique utilisée par l'autorité de datation n'est plus garantie, les dates incorporées de la signature électronique archivée deviennent alors nécessaires.
Les probabilités que les clés des tiers de confiance (TSP) soient compromises devraient être significativement inférieures à celles des clés des utilisateurs, car les tiers de confiance sont censés employer des moyens cryptographiques plus forts et une protection des clés renforcée. On peut supposer que des nouveaux algorithmes (ou d'anciens avec des longueurs de clé plus grandes) seront utilisés. Dans ce cas, une séquence de dates prémunira des falsifications. Chaque date devra avoir été apposée soit avant la compromission de la clé de signature, soit avant le craquage des algorithmes utilisés par l'autorité de datation. Les autorités de datation devraient avoir des clés longues (par exemple, au moment de la rédaction de ce document, une clé de 2048 bits pour l'algorithme de signature RSA) et/ou un algorithme bon ou différent.
Les dates incorporées protègeront également le vérificateur contre la compromission de clé ou le craquage de l'algorithme pour les signatures électroniques anciennes.
L'opération devra être effectuée et répétée avant que les algorithmes cryptographiques utilisés pour la génération de la date précédente ne soient plus sûrs. Les données de validation des archives peuvent donc porter plusieurs dates imbriquées.
L'empreinte numérique envoyée à l'autorité de datation (messageImprint) sera calculée sur la forme XAdES-X-L de la signature électronique et des objets-données signés, c'est-à-dire sur la séquence formée selon les explications suivantes.
L'élément ArchiveTimeStamp est une propriété non signée qui qualifie la signature. Une forme XAdES-A PEUT contenir plusieurs éléments ArchiveTimeStamp.
<xsd:element name="ArchiveTimeStamp" type="TimeStampType"/>
L'élément ArchiveTimeStamp XAdES contient la séquence d'éléments HashDataInfo suivante :
un élément HashDataInfo pour chaque objet-données signé par la signature [XMLDSIG]. Le résultat de l'application des transformation spécifiées par chaque élément HashDataInfo doit être exactement le même que le flux d'octets qui a été utilisé à l'origine pour le calcul de la valeur de l'empreinte numérique de l'élément ds:Reference correspondant ;
un élément HashDataInfo pour l'élément ds:SignedInfo. Le résultat de l'application des transformations spécifiées dans cet élément HashDataInfo doit être exactement le même que le flux d'octets qui a été utilisé à l'origine pour le calcul de la valeur de signature de la signature [XMLDSIG] ;
un élément HashDataInfo pour l'élément SignedSignatureProperties ;
un élément HashDataInfo pour l'élément SignedDataObjectProperties ;
un élément HashDataInfo pour l'élément ds:SignatureValue ;
un élément HashDataInfo pour chaque propriété SignatureTimeStamp ;
un élément HashDataInfo pour la propriété CompleteCertificateRefs ;
un élément HashDataInfo pour la propriété CompleteRevocationRefs ;
un élément HashDataInfo pour la propriété CertificatesValues (ajouter cette propriété avant si elle n'est pas déjà présente) ;
un élément HashDataInfo pour la propriété RevocationValues (ajouter cette propriété avant si elle n'est pas déjà présente) ;
un élément HashDataInfo pour chaque propriété SigAndRefsTimeStamp (si présente) ;
un élément HashDataInfo pour chaque propriété RefsOnlyTimeStamp (si présente) ;
un élément HashDataInfo pour chaque éventuelle propriété ArchiveTimeStamp précédente (si présente).
Certificat d'attributs [NdT. Attribute Certificate]
Un jeu d'attributs de l'utilisateur avec d'autres informations, rendu infalsifiables par la signature numérique créée à l'aide de la clé privée de l'autorité de certification qui a émis le certificat (définition tirée de [X509v3]).
Objet-données (contenu/document) [NdT. Data Object (Content/Document)]
Voir la définition à http://www.w3.org/TR/xmldsig-core/#def-DataObject
Voir la définition à http://www.w3.org/TR/xmldsig-core/#def-Signature
RFC 2630 : Cryptographic Message Syntax. R. Housley, juin 1999. http://www.ietf.org/rfc/rfc2630.txt
ETSI TS 101 733 : Electronic Signature Formats. http://www.etsi.org
ESI-XAdES
ETSI TS 101 903 : XML Advanced Electronic Signatures (XAdES). http://uri.etsi.org/01903/v1.1.1#
ES-SMIME
RFC 2634 : Enhanced Security Services for S/MIME. P. Hoffman, juin 1999. http://www.ietf.org/rfc/rfc2634.txt
EU-DIR-ESIG
RFC 2119 : Key words for use in RFCs to Indicate Requirement Levels. S. Bradner, mars 1997. http://www.ietf.org/rfc/rfc2119.txt
RFC 2560 : X.509 Internet Public Key Infrastructure Online Certificate Status Protocolol - OCSP. M. Myers, R. Ankney, A. Malpani, S. Galperin, C. Adams, juin 1999. http://www.ietf.org/rfc/rfc2560.txt
RFC 3161 : Internet X.509 Public Key Infrastructure Time Stamp Protocol (TSP). P. Cain, D. Pinkas, R. Zuccherato, août 2001. http://www.ietf.org/rfc/rfc3161.txt
TSPProf
ETSI TS 101 861: Time stamping profile. http://www.etsi.org
RFC 2396 : Uniform Resource Identifiers (URI) : Generic Syntax. T. Berners-Lee, R. Fielding, U.C. Irvine, L. Masinter, août 1998. http://www.ietf.org/rfc/rfc2396.txt
RFC 2141 : URN Syntax. R. Moats, mai 1997. http://www.ietf.org/rfc/rfc2141.txt
URN-NM
RFC 2611 : URN Namespace Definition Mechanisms. L. Daigle, D. van Gulik, R. Iannella, P. Falstrom, juin 1999. http://www.ietf.org/rfc/rfc2611.txt
RFC 3061 : A URN Namespace of Object Identifiers. M. Mealling, février 2001. http://www.ietf.org/rfc/rfc3061.txt
Le langage de balisage extensible (XML) 1.0 (2ème é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
La syntaxe et le traitement XML Signature. Recommandation du W3C. Donald Eastlake, Joseph Reagle, David Solo, février 2002. http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/
XML-schema-part-1
XML Schema - Tome 1 : Structures. Recommandation du W3C. D. Beech, M. Maloney, N. Mendelsohn, H. Thompson, mai 2001. http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/
XML-schema-part-2
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/
X509Prof
RFC 2459 : Internet X.509 Public Key Infrastructure Certificate and CRL Profile. R. Housley, W. Polk, D. Solo, janvier 1999. http://www.ietf.org/rfc/rfc2459.txt
<xsd:schema targetNamespace="http://uri.etsi.org/01903/v1.1.1#"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#" elementFormDefault="qualified">
<!-- Début des définitions des types auxilliaires :
AnyType, ObjectIdentifierType, EncapsulatedPKIDataType et TimestampType -->
<!-- Début AnyType -->
<xsd:element name="Any" type="AnyType"/><xsd:complexType name="AnyType" mixed="true">
<!-- Fin AnyType -->
<!-- Début ObjectIdentifierType-->
<xsd:sequence><
xsd:element name="Identifier" type="IdentifierType"/>
<xsd:element name="DocumentationReferences" type="DocumentationReferencesType"
<!-- Fin ObjectIdentifierType -->
<!-- Début EncapsulatedPKIDataType -->
<xsd:element name="EncapsulatedPKIData" type="EncapsulatedPKIDataType"/>
<!-- Fin EncapsulatedPKIDataType -->
<!-- Début TimeStampType -->
<xsd:element name="TimeStamp" type="TimeStampType"/>
<xsd:element name="HashDataInfo" type="HashDataInfoType" maxOccurs="unbounded"/>
<!-- Fin TimeStampType -->
<!-- Fin des définitions des types auxilliaires -->
<!-- Début des types conteneurs -->
<!-- Début QualifyingProperties -->
<xsd:element name="SignedProperties" type="SignedPropertiesType" minOccurs="0"/>
<xsd:element name="UnsignedProperties" type="UnsignedPropertiesType" minOccurs="0"/>
<!-- Fin QualifyingProperties -->
<!-- Début SignedProperties -->
<xsd:element name="SignedProperties" type="SignedPropertiesType"/>
<xsd:element name="SignedSignatureProperties" type="SignedSignaturePropertiesType"/>
<xsd:element name="SignedDataObjectProperties" type="SignedDataObjectPropertiesType"
<!-- Fin SignedProperties -->
<!-- Début UnsignedProperties -->
<xsd:element name="UnsignedSignatureProperties" type="UnsignedSignaturePropertiesType"
<xsd:element name="UnsignedDataObjectProperties" type="UnsignedDataObjectPropertiesType"
<!-- Fin UnsignedProperties -->
<!-- Début SignedSignatureProperties -->
<xsd:element name="SignedSignatureProperties" type="SignedSignaturePropertiesType" />
<!-- Fin SignedSignatureProperties -->
<!-- Début SignedDataObjectProperties -->
<xsd:element name="SignedDataObjectProperties" type="SignedDataObjectPropertiesType"/>
<xsd:element name="DataObjectFormat" type="DataObjectFormatType" minOccurs="0"
<xsd:element name="CommitmentTypeIndication" type="CommitmentTypeIndicationType"
<xsd:element name="AllDataObjectsTimeStamp" type="TimeStampType" minOccurs="0"
<xsd:element name="IndividualDataObjectsTimeStamp" type="TimeStampType" minOccurs="0"
<!-- Fin SignedDataObjectProperties -->
<!-- Début UnsignedSignatureProperties -->
<xsd:element name="CounterSignature" type="CounterSignatureType" minOccurs="0"
<xsd:element name="SignatureTimeStamp"type="TimeStampType" minOccurs="0"
<xsd:element name="CompleteCertificateRefs" type="CompleteCertificateRefsType"
<xsd:element name="CompleteRevocationRefs" type="CompleteRevocationRefsType"
<xsd:element name="SigAndRefsTimeStamp" type="TimeStampType" minOccurs="0"
<xsd:element name="RefsOnlyTimeStamp" type="TimeStampType" minOccurs="0"
<xsd:element name="CertificateValues" type="CertificateValuesType" minOccurs="0"/>
<xsd:element name="RevocationValues" type="RevocationValuesType" minOccurs="0"/>
<xsd:element name="ArchiveTimeStamp" type="TimeStampType" minOccurs="0"
<!-- Fin UnsignedSignatureProperties -->
<!-- Début UnsignedDataObjectProperties -->
<xsd:element name="UnsignedDataObjectProperty" type="AnyType" minOccurs="0"
<!-- Fin UnsignedDataObjectProperties -->
<!-- Début QualifyingPropertiesReference -->
<xsd:element name="QualifyingPropertiesReference" type="QualifyingPropertiesReferenceType"/>
<!-- Fin QualifyingPropertiesReference -->
<!-- Fin des types conteneurs -->
<!-- Début élément SigningTime -->
<!-- Fin élément SigningTime -->
<!-- Début élément SigningCertificate -->
<!-- Fin élément SigningCertificate -->
<!-- Début élément SignaturePolicyIdentifier -->
<xsd:element name="SigPolicyQualifiers" type="SigPolicyQualifiersListType" minOccurs="0"/>
<xsd:element name="SigPolicyQualifier" type="AnyType" maxOccurs="unbounded"/>
<xsd:element name="int" type="xsd:integer" minOccurs="0" maxOccurs="unbounded"/>
<!-- Fin élément SignaturePolicyIdentifier -->
<!-- Début élément CounterSignature -->
<xsd:element name="CounterSignature" type="CounterSignatureType"/>
<!-- Fin élément CounterSignature -->
<!-- Début élément DataObjectFormat -->
<xsd:attribute name="ObjectReference" type="xsd:anyURI" use="required"/>
<!-- Fin élément DataObjectFormat -->
<!-- Début élément CommitmentTypeIndication -->
<xsd:element name="ObjectReference" type="xsd:anyURI" minOccurs="0"
<xsd:element name="CommitmentTypeQualifiers" type="CommitmentTypeQualifiersListType"
<xsd:element name="CommitmentTypeQualifier" type="AnyType" minOccurs="0"
<!-- Fin élément CommitmentTypeIndication -->
<!-- Début élément SignatureProductionPlace -->
<!-- Fin élément SignatureProductionPlace -->
<!-- Début élément SignerRole -->
<!-- Fin élément SignerRole -->
<!-- Début élément CompleteCertificateRefs -->
<!-- Fin élément CompleteCertificateRefs -->
<!-- Début élément CompleteRevocationRefs -->
<xsd:element name="CompleteRevocationRefs" type="CompleteRevocationRefsType"/>
<!-- Fin élément CompleteRevocationRefs-->
<!-- Début élément CertificateValues -->
<xsd:element name="EncapsulatedX509Certificate" type="EncapsulatedPKIDataType"/>
<!-- Fin élément CertificateValues -->
<!-- Début élément RevocationValues -->
<!-- Fin élément RevocationValues-->
<!ENTITY % Any.ANY ''>
<!ENTITY % XMLTimeStamp.ANY ''>
<!-- Début Any -->
<!ELEMENT Any (#PCDATA  %Any.ANY;)*>
<!-- Fin Any -->
<!-- Début ObjectIdentifier -->
<!ELEMENT ObjectIdentifier (Identifier, Description?, DocumentationReferences?)>
<!ELEMENT DocumentationReferences (DocumentationReference)+>
<!ELEMENT DocumentationReference (#PCDATA)>
<!-- Fin ObjectIdentifier -->
<!-- Début EncapsulatedPKIData -->
<!ELEMENT EncapsulatedPKIData (#PCDATA)>
<!ATTLIST EncapsulatedPKIData
<!-- Fin EncapsulatedPKIData -->
<!-- Début EncapsulatedTimeStamp -->
<!ELEMENT TimeStamp (HashDataInfo+, (EncapsulatedTimeStamp | XMLTimeStamp))>
<!ELEMENT HashDataInfo (Transforms?)>
<!ATTLIST HashDataInfo
<!ELEMENT EncapsulatedTimeStamp (#PCDATA)>
<!ATTLIST EncapsulatedTimeStamp
<!ELEMENT XMLTimeStamp (#PCDATA %XMLTimeStamp.ANY;)*>
<!-- Fin EncapsulatedTimeStamp -->
<!ELEMENT QualifyingProperties (SignedProperties, UnsignedProperties?)>
<!ATTLIST QualifyingProperties
<!ELEMENT SignedProperties (SignedSignatureProperties, SignedDataObjectProperties?)>
<!ATTLIST SignedProperties
<!ELEMENT UnsignedProperties (UnsignedSignatureProperties?, UnsignedDataObjectProperties?)>
<!ATTLIST UnsignedProperties
<!-- Début SignedSignatureProperties, SignedDataObjectProperties,
UnsignedSignatureProperties, UnsignedDataObjectProperties -->
<!ELEMENT SignedSignatureProperties (SigningTime, SigningCertificate,
SignaturePolicyIdentifier, SignatureProductionPlace?, SignerRole?)
<!ELEMENT SignedDataObjectProperties (DataObjectFormat*, CommitmentTypeIndication*,
AllDataObjectsTimeStamp*, IndividualDataObjectsTimeStamp*)
<!ELEMENT UnsignedSignatureProperties (CounterSignature*, SignatureTimeStamp*,
CompleteCertificateRefs?, CompleteRevocationRefs?,
(SigAndRefsTimeStamp* | RefsOnlyTimeStamp*), CertificateValues?,
RevocationValues?, ArchiveTimeStamp*)
<!ELEMENT UnsignedDataObjectProperties (UnsignedDataObjectProperty*)>
<!ELEMENT UnsignedDataObjectProperty (#PCDATA %Any.ANY; )*>
<!-- Fin SignedSignatureProperties, SignedDataObjectProperties,
<!ELEMENT QualifyingPropertiesReference (Transforms?)>
<!ATTLIST QualifyingPropertiesReference
<!-- Début SigningTime -->
<!ELEMENT SigningTime (#PCDATA)>
<!-- Fin SigningTime -->
<!-- Début SigningCertificate -->
<!ELEMENT SigningCertificate (Cert+)>
<!ELEMENT Cert (CertDigest, IssuerSerial)>
<!ELEMENT CertDigest (DigestMethod, DigestValue)>
<!ELEMENT IssuerSerial (X509IssuerName, X509SerialNumber)>
<!-- Fin SigningCertificate -->
<!-- Début SignaturePolicyIdentifier -->
<!ELEMENT SignaturePolicyIdentifier (SignaturePolicyId | SignaturePolicyImplied)>
<!ELEMENT SignaturePolicyId (SigPolicyId, Transforms?, SigPolicyHash, SigPolicyQualifiers?)>
<!ELEMENT SignaturePolicyImplied ANY>
<!ELEMENT SigPolicyId (Identifier, Description?, DocumentationReferences?)>
<!ELEMENT SigPolicyHash (DigestMethod, DigestValue)>
<!ELEMENT SigPolicyQualifiers (SigPolicyQualifier+)>
<!ELEMENT SigPolicyQualifier (#PCDATA %Any.ANY; )*>
<!-- Fin SignaturePolicyIdentifier -->
<!-- Début SPURI et SPUserNotice -->
<!ELEMENT SPURI (#PCDATA)>
<!ELEMENT SPUserNotice (NoticeRef?, ExplicitText?)>
<!ELEMENT NoticeRef (Organization, NoticeNumbers)>
<!ELEMENT ExplicitText (#PCDATA)>
<!ELEMENT NoticeNumbers (#PCDATA)*>
<!-- Fin SPURI et SPUserNotice -->
<!-- Début CounterSignature -->
<!ELEMENT CounterSignature (Signature)>
<!-- Fin CounterSignature -->
<!-- Début DataObjectFormat -->
<!ELEMENT DataObjectFormat (Description?, ObjectIdentifier?, MimeType?, Encoding?)>
<!ATTLIST DataObjectFormat
<!-- Fin DataObjectFormat -->
<!-- Début CommitmentTypeIndication -->
<!ELEMENT CommitmentTypeIndication (CommitmentTypeId,
(ObjectReference* | AllSignedDataObjects), CommitmentTypeQualifiers?)
<!ELEMENT CommitmentTypeId (Identifier, Description?, DocumentationReferences?)>
<!ELEMENT ObjectReference (#PCDATA)>
<!ELEMENT AllSignedDataObjects ANY>
<!ELEMENT CommitmentTypeQualifiers (CommitmentTypeQualifier*)>
<!ELEMENT CommitmentTypeQualifier (#PCDATA%Any.ANY; )*>
<!-- Fin CommitmentTypeIndication -->
<!-- Début SignatureProductionPlace -->
<!ELEMENT SignatureProductionPlace (City?, StateOrProvince?, PostalCode?, CountryName?)>
<!ELEMENT StateOrProvince (#PCDATA)>
<!ELEMENT CountryName (#PCDATA)>
<!-- Fin SignatureProductionPlace -->
<!-- Début SignerRole -->
<!ELEMENT SignerRole (ClaimedRoles?, CertifiedRoles?)>
<!ELEMENT ClaimedRoles (ClaimedRole+)>
<!ELEMENT CertifiedRoles (CertifiedRole+)>
<!ELEMENT ClaimedRole (#PCDATA %Any.ANY; )*>
<!ELEMENT CertifiedRole (#PCDATA)>
<!ATTLIST CertifiedRole
<!-- Fin SignerRole -->
<!-- Début AllDataObjectsTimeStamp, IndividualDataObjectsTimeStamp, SignatureTimeStamp -->
<!ELEMENT AllDataObjectsTimeStamp (HashDataInfo+, (EncapsulatedTimeStamp | XMLTimeStamp))>
<!ELEMENT IndividualDataObjectsTimeStamp (HashDataInfo+, (EncapsulatedTimeStamp | XMLTimeStamp))>
<!ELEMENT SignatureTimeStamp (HashDataInfo+, (EncapsulatedTimeStamp | XMLTimeStamp))>
<!-- Fin AllDataObjectsTimeStamp, IndividualDataObjectsTimeStamp, SignatureTimeStamp -->
<!-- Début CompleteCertificateRefs -->
<!ELEMENT CompleteCertificateRefs (CertRefs)>
<!ATTLIST CompleteCertificateRefs
<!ELEMENT CertRefs (Cert+)>
<!-- Fin CompleteCertificateRefs -->
<!-- Début CompleteRevocationRefs -->
<!ELEMENT CompleteRevocationRefs (CRLRefs?, OCSPRefs?, OtherRefs?)>
<!ATTLIST CompleteRevocationRefs
<!ELEMENT CRLRefs (CRLRef+)>
<!ELEMENT OCSPRefs (OCSPRef+)>
<!ELEMENT OtherRefs (OtherRef+)>
<!ELEMENT CRLRef (DigestAlgAndValue,CRLIdentifier?)>
<!ELEMENT OCSPRef (OCSPIdentifier, DigestAlgAndValue?)>
<!ELEMENT OtherRef (#PCDATA %Any.ANY; )*>
<!ELEMENT DigestAlgAndValue (DigestMethod, DigestValue)>
<!ELEMENT CRLIdentifier (Issuer, IssueTime, Number?)>
<!ELEMENT OCSPIdentifier (ResponderID, ProducedAt)>
<!ELEMENT IssueTime (#PCDATA)>
<!ELEMENT ResponderID (#PCDATA)>
<!ELEMENT ProducedAt (#PCDATA)>
<!-- Fin CompleteRevocationRefs -->
<!-- Début SigAndRefsTimeStamp, RefsOnlyTimeStamp  -->
<!ELEMENT SigAndRefsTimeStamp (HashDataInfo+, (EncapsulatedTimeStamp | XMLTimeStamp))>
<!ELEMENT RefsOnlyTimeStamp (HashDataInfo+, (EncapsulatedTimeStamp | XMLTimeStamp))>
<!-- Fin SigAndRefsTimeStamp, RefsOnlyTimeStamp  -->
<!-- Début CertificateValues -->
<!ELEMENT CertificateValues (EncapsulatedX509Certificate | OtherCertificate)*>
<!ATTLIST CertificateValues
<!ELEMENT EncapsulatedX509Certificate (#PCDATA)>
<!ATTLIST EncapsulatedX509Certificate
<!ELEMENT OtherCertificate (#PCDATA %Any.ANY; )*>
<!-- Fin CertificateValues -->
<!-- Début RevocationValues -->
<!ELEMENT RevocationValues (CRLValues?, OCSPValues?, OtherValues?)>
<!ATTLIST RevocationValues
<!ELEMENT CRLValues (EncapsulatedCRLValue+)>
<!ELEMENT OCSPValues (EncapsulatedOCSPValue+)>
<!ELEMENT OtherValues (OtherValue+)>
<!ELEMENT EncapsulatedCRLValue (#PCDATA)>
<!ATTLIST EncapsulatedCRLValue
<!ELEMENT EncapsulatedOCSPValue (#PCDATA)>
<!ATTLIST EncapsulatedOCSPValue
<!ELEMENT OtherValue (#PCDATA%Any.ANY; )*>
<!-- Fin RevocationValues -->
<!-- Début ArchiveTimeStamp -->
<!ELEMENT ArchiveTimeStamp (HashDataInfo+, (EncapsulatedTimeStamp | XMLTimeStamp))>
<!-- Fin ArchiveTimeStamp -->
Comme indiqué dans la partie normative du présent document, des nouveaux éléments ont été définis pour incorporer les propriétés (signées ou non) qui qualifient la signature entière, le signataire ou les objets-données signés individuels : QualifyingProperties, SignedProperties, UnsignedProperties, SignedSignatureProperties, UnsignedSignatureProperties, SignedDataObjectProperties et UnsignedDataProperties.
Cette annexe donne un exemple d'incorporation directe des propriétés de qualification ainsi qu'un exemple d'incorporation indirecte de ces propriétés.
Voici la structure générale résultante d'une incorporation directe :
(<ds:Transforms>)?
(<ds:KeyInfo>)?
<!-- Collection d'éléments XML signés
avec des propriétés qualifiant la signature
ou le signataire -->
avec des propriétés qualifiant individuellement
des objets-données signés -->
</SignedDataObjectPropertiesSigned>
<!-- Collection d'éléments XML non signés
<UnSignedDataObjectProperties>
</UnSignedDataObjectProperties>
Voici un exemple illustrant l'inclusion de trois ensembles de propriétés de qualification :
le premier ensemble inclut les propriétés signées qualifiant la signature, à savoir :
l'heure de la production de la signature (élément SigningTime) ;
un ensemble restreint de références aux certificats à utiliser pour la vérification de la signature. Il inclut également une référence au certificat contenant la clé publique, laquelle correspond à la clé privée utilisée pour le calcul de la signature (élément SigningCertificate) ;
une identification de la politique de signature selon laquelle la signature a été produite et devra être vérifiée (élément SignaturePolicyIdentifier).
le deuxième ensemble inclut les propriétés signées qualifiant l'objet-donnée signé, à savoir :
une date de l'objet-donnée signé, qui prouve que le contenu a été produit avant l'heure indiquée par la date (élément AllDataObjectsTimeStamp) ;
une indication sur le format de l'objet-données signé (élément DataObjectFormat).
le troisième ensemble inclut les propriétés non signées qualifiant la signature, à savoir :
une date apposée sur la signature elle-même, prouvant que la signature a été produite avant l'heure indiquée par la date en question (élément SignatureTimeStamp) ;
les références vers l'ensemble complet des certificats de l'autorité de certification que le vérificateur de la signature électronique a utilisé pour valider celle-ci (élément CompleteCertificateRefs) ;
les références au matériel de révocation (listes de révocation de certificats (CRL) ou réponses OCSP), employé pour la validation du signataire et des certificats des autorités de certification utilisés pour valider la signature électronique (élément CompleteRevocationRefs) ;
la date générée sur la signature électronique ainsi que les informations mentionnées précédemment (élément SigAndRefsTimeStamp) ;
l'ensemble complet des certificats de l'autorité de certification que le vérificateur de la signature électronique a utilisé pour valider celle-ci (élément CertificateValues) ;
le matériel de révocation (liste de révocation de certificats ou réponses OCSP), employé pour la validation du signataire et des certificats de l'autorité de certification utilisés pour valider la signature électronique (élément RevocationValues).
[s01]<ds:Signature Id="SignatureAvecProprietesSigneesEtNonSignees" xmlns="http://www.w3.org/2000/09/xmldsig#>
[s02]  <ds:SignedInfo>
[s03]    <ds:CanonicalizationMethod Algorithm="http://www.w3.org/TR/2000/WD-xml-c14n-20000710"/>
[s04]    <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"/>
[s05]    <ds:Reference URI="<http://www.example.org/docToBeSigned>" Id="PremierDocumentSigne">
[s06]      <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha"/>
[s07]      <ds:DigestValue>h9kmx3rvDH75vKtNpi4NbeBGDnl=</ds:DigestValue>
[s08]    </ds:Reference>
[s09]    <ds:Reference URI="#ProprietesSignees"
Type="http://uri.etsi.org/01903/v1.1.1#SignedProperties">
[s10]      <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
[s11]      <ds:DigestValue>..  </ds:DigestValue>
[s12]    </ds:Reference>
[s13]  </ds:SignedInfo>
[s14]  <ds:SignatureValue>....</SignatureValue>
[s15]  <ds:KeyInfo> <ds:KeyValue>...</ds:KeyValue></ds:KeyInfo>
[s16]  <ds:Object xmlns="http://uri.etsi.org/01903/v1.1.1#" xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
[s17]     <QualifyingProperties>
[s18]      <SignedProperties Target="#SignatureWithSignedAndUnsignedProperties" Id="ProprietesSignees">
[s19]        <SignedSignatureProperties >
[s20]          <SigningTime>2000-11-18T12:10:00Z</SigningTime>
[s21]          <SigningCertificate>....</SigningCertificate >
[s22]          <SignaturePolicyIdentifier>....</ SignaturePolicyIdentifier >
[s23]        </SignedSignatureProperties>
[s24]        <SignedDataObjectProperties>
[s25]          <DataObjectFormat>....</DataObjectFormat>
[s26]          <AllDataObjectsTimeStamp>.. </AllDataObjectsTimeStamp>
[s27]        </SignedDataObjectProperties>
[s28]      </SignedProperties>
[s29]      <UnsignedProperties >
[s30]        <UnsignedSignatureProperties>
[s31]          <SignatureTimeStamp>...</SignatureTimeStamp>
[s32]          <CompleteCertificateRefs>...</CompleteCertificateRefs>
[s33]          <CompleteRevocationRefs>...</CompleteRevocationRefs>
[s34]          <SigAndRefsTimeStamp>...</SigAndRefsTimeStamp >
[s35]          <CertificateValues>....</CertificateValues>
[s36]          <RevocationValues>...</RevocationValues>
[s37]        </UnsignedSignatureProperties>
[s38]      </UnsignedProperties>
[s39]    </QualifyingProperties>
[s40]  </ds:Object>
[s41]</ds:Signature>
[s01] Début de la signature XML. L'espace de nommage par défaut est celui défini dans la spécification [XMLDSIG].
[s02]-[s13] L'élément ds:SignedInfo contient les informations qui sont effectivement signées.
[s03] L'élément ds:CanonicalizationMethod indique l'algorithme utilisé pour obtenir une représentation canonique de l'élément ds:SignedInfo avant que celui-ci ne soit signé.
[s04] L'élément ds:SignatureMethod indique l'algorithme utilisé pour signer l'élément ds:SignedInfo.
[s05]-[s16] Les éléments ds:Reference contiennent les valeurs des empreintes numériques et l'indication de l'algorithme de hachage cryptographique de chaque objet-données devant être (indirectement) signés. Chacun d'eux possède également une référence vers l'objet-données correspondant. Ces éléments ont également un attribut Id qui peut servir à leur appel individuel.
[s05-s08] Le premier élément ds:Reference. Son attribut URI référence l'objet-données qui doit être signé. L'élément ds:DigestMethod indique l'algorithme de hachage cryptographique (ici, SHA-1) et l'élément ds:DigestValue contient la valeur de l'empreinte numérique filtrée en base64.
[s09-s12] Le deuxième élément ds:Reference. Son attribut URI pointe vers l'élément SignedProperties qui contient l'ensemble complet des propriétés signées. L'élément ds:DigestMethod indique l'algorithme de hachage cryptographique (ici, SHA-1) et l'élément ds:DigestValue contient la valeur de l'empreinte numérique filtrée en base 64. Cela signifie que la valeur de l'empreinte numérique de cet élément SignedProperties est incluse dans l'élément ds:SignedInfo et donc signée quand cet élément l'est. L'attribut Type indique que cet élément est une référence vers l'élément SignatureProperties, comme demandé dans la section 4.3.1 L'élément SigningProperties .
[s14] L'élément ds:SignatureValue contient la signature numérique calculée de l'élément ds:SignedInfo en base 64.
[s15] L'élément ds:KeyInfo contient le matériel cryptographique pour la vérification de la signature.
[s16-s40] L'élément ds:Object contient trois éléments qui qualifient à la fois la signature et l'objet-donnés signé.
[s17-39] L'élément QualifyingProperties contient l'ensemble complet des propriétés de qualification, celles signées (SignedProperties) et celles non signées (UnsignedProperties). L'espace de nommage par défaut de cet élément change : son contenu prend celui défini par défaut dans la définition de schéma donnée dans le présent document, afin de ne pas devoir qualifier l'ensemble entier des éléments. En outre, puisqu'on utilise, dans les définitions, des éléments déjà définis dans [XMLDSIG], son espace de nommage est également défini (préfixe ds).
[s18-s28] L'élément SignedProperties contient l'ensemble complet des propriétés de qualification signées, regroupées en deux séquences. La première (SignedSignatureProperties) contient toutes les propriétés signées qui qualifient la signature. La seconde (SignedDataObjectProperties) contient toutes les propriétés signées qui qualifient individuellement chaque objet-donnée signé.
[s19-ss23] L'élément SignedSignatureProperties contient toutes les propriétés signées qui qualifient la signature (SigningTime, SigningCertificate, SignaturePolicyIdentifier).
[s20] L'élément SigningTime contient l'heure de la signature, quand celle-ci a été calculée.
[s21] L'élément SigningCertificate contient, comme indiqué ci-dessus, un ensemble restreint de références aux certificats utlisés pour la vérification de la signature.
[s24-27] L'élément SignedDataObjectProperties contient toutes les propriétés signées qui qualifient individuellement chaque objet-données signé (AllDataObjectsTimeStamp, DataObjectFormat).
[s25] L'élément DataObjectFormat identifie le format de l'objet-données signé
[s26] L'élément AllDataObjectsTimeStamp est une date émise pour l'objet-données signé.
[s29-38] L'élément UnsignedProperties contient l'ensemble complet des propriétés de qualification non signées.
[s30-s37] L'élément UnsignedSignatureProperties contient l'ensemble complet des propriétés non signées qui qualifient la signature.
[s31] L'élément SignatureTimeStamp contient une date pour la signature elle-même.
[s32] L'élément CompleteCertificateRefs contient les références aux certificats de l'autorité de certification dans le chemin de certification utilisé pour vérifier la signature.
[s33] L'élément CompleteRevocationRefs contient les références aux informations de révocation utilisées pour vérifier la signature.
[s34] L'élément SigAndRefsTimeStamp contient une date sur la forme XAdES-C de la signature électronique.
[s35] L'élément CertificateValues contient les valeurs des certificats référencés dans l'élément CompleteCertificateRefs.
[s36] L'élément RevocationValues contient les données de révocation utilisées pour valider la signature électronique.
REMARQUE : L'arbre présenté dans cet exemple ne montre pas explicitement certains éléments XML (comme les éléments ds:Transforms). Pour une description complète de cet arbre, voir la spécification de la syntaxe et du traitement XML Signature [XMLDSIG].
Ci-dessous suivra un exemple d'incorporation indirecte de toutes les propriétés non signées. Dans cet exemple, les propriétés signées seront incorporées directement dans l'élément ds:Signature, comme dans l'exemple précédent. Cependant, les propriétés non signées seront stockées ailleurs séparément. Pour incorporer ces propriétés, on utilisera l'élément QualifyingPropertiesReference pointant vers l'élément qui les contient.
Voici le contenu de la signature XAdES en question :
[s01]<ds:Signature Id="SignatureAvecProprietesSigneesEtNonSignees" xmlns="http://www.w3.org/2000/09/xmldsig#">
Type=http://uri.etsi.org/01903/v1.1.1#SignedProperties">
[s11]      <ds:DigestValue>...</ds:DigestValue>
[s14]  <ds:SignatureValue>.....</SignatureValue>
[s18]      <SignedProperties Target="#SignatureAvecProprietesSigneesEtNonSignees" Id="ProprietesSignees">
[s21]          <SigningCertificate>...</SigningCertificate >
[s26]          <AllDataObjectsTimeStamp>...</AllDataObjectsTimeStamp>
[s28]    <QualifyingPropertiesReference>
[s29]      <Transforms> .. </Transforms>
[s30]      <URI>http://www.ac.upc.es/ETSI-XML/Indirect-Incorporation/exemple1#QualifyingProperties</URI>
[s31]    </ QualifyingPropertiesReference>
[s32]    </QualifyingProperties>
[s33]  </ds:Object>
[s34]</ds:Signature>
[s1-s27] Ce sont les mêmes lignes que dans le premier exemple. Elles montrent comment incorporer directement les propriétés signées.
[s28-s32] Ces lignes montrent comment incorporer indirectement les propriétés non signées, stockées ailleurs, en utilisant l'élément QualifyingPropertiesReference.
[s29] L'élément ds:Transforms contient l'ensemble complet des transformations à calculer sur le fichier où sont stockées les propriétés non signées.
[s30] L'élément URI contient l'adresse URI qui pointe vers l'élément QualifyingProperties contenant ces propriéés de qualification, incorporées indirectement. Ici, l'adresse URI pointe vers le fichier qui se trouve à l'adresse "http://www.ac.upc.es/ETSI-XML/Indirect-Incorporation/exemple1", contenant cet élément. Cet exemple se termine en montrant la partie du fichier, trouvé à "http://www.ac.upc.es/ETSI-XML/Indirect-Incorporation/exemple1", qui contient l'élément QualifyingProperties référencé dans l'élément QualifyingPropertiesReference.
<!-- Voici la partie du fichier (à <http://www.ac.upc.es/ETSI-XML/Indirect-Incorporation/exemple1>)
qui contient l'élément QualifyingProperties portant les propriétés non signées incorporées indirectement
dans la signature électronique évoluée -->
[si]     <QualifyingProperties>
[si+1]      <UnsignedProperties >
[si+2]        <UnsignedSignatureProperties>
[si+3]          <SignatureTimeStamp....</SignatureTimeStamp>
[si+4]          <CompleteCertificateRefs>..</CompleteCertificateRefs>
[si+5]          <CompleteRevocationRefs>...</CompleteRevocationRefs>
[si+6]          <SigAndRefsTimeStamp>...</SigAndRefsTimeStamp >
[si+7]          <CertificateValues>...</CertificateValues>
[si+8]          <RevocationValues>...</RevocationValues>
[si+9]        </UnsignedSignatureProperties>
[si+10]     </UnsignedProperties>
[si+11]  </QualifyingProperties>
<!-- Le reste du fichier à suivre... -->
Dans l'exemple ci-dessus, l'élément QualifyingProperties apparaît comme partie du fichier trouvé à l'adresse "http://www.ac.upc.es/ETSI-XML/Indirect-Incorporation/exemple1" et qui est désigné par l'élément URI de l'élément QualifyingPropertiesReference, dans la signature électronique évoluée.
Departament de Arquitectura de Computadors (DAC)
c/ Jordi Girona 1-3, Modul D6.103, Barcelona
téléphone : +34 93 4016790
e-mail : mailto:cruellas@ac.upc.es
téléphone : +43 (316) 873 5541
e-mail : mailto:gregor.kerlinger@iaik.at
Rue Jean Jaures BP 68
téléphone : +33 1 30 80 75 24
e-mail: mailto:Denis.Pinkas@bull.net
192 Moulsham Street Chelmsford Essex
Angleterre UK CM2 OLG
téléphone : +44 1245 347 021
e-mail: mailto:ross@secstan.com