Résumé

Ce document spécifie un processus pour le chiffrement des données et une représentation du résultat dans XML. Ces données peuvent être des données arbitraires (y compris un document XML), un élément XML ou le contenu d'un élément XML. Le résultat du chiffrement des données est un élément XML Encryption qui contient ou appelle les données cryptées.

Statut de ce document

Table des matières

1. Introduction
   1. Conventions d'écriture et de conformité
   2. La démarche conceptuelle
   3. Les versions, les adresses URI des espaces de nommage et les identificateurs
   4. Remerciements
2. Vue d'ensemble sur le chiffrement et exemples
   1. La granularité du chiffrement
      1. Le chiffrement d'un élément XML
      2. Le chiffrement du contenu d'un élément XML (les éléments)
      3. Le chiffrement du contenu d'un élément XML (les données textuelles)
      4. Le chiffrement de données arbitraires et des documents XML
      5. Le surchiffrement : le chiffrement d'un élément EncryptedData
   2. L'utilisation des éléments EncryptedData et EncryptedKey
      1. L'élément EncryptedData avec une clé symétrique (KeyName)
      2. L'élément EncryptedKey (ReferenceList, ds:RetrievalMethod, CarriedKeyName)
3. La syntaxe du chiffrement
   1. L'élément EncryptedType
   2. L'élément EncryptionMethod
   3. L'élément CipherData
      1. L'élément CipherReference
   4. L'élément EncryptedData
   5. Les extensions de l'élément ds:KeyInfo
      1. L'élément EncryptedKey
      2. L'élément ds:RetrievalMethod
   6. L'élément ReferenceList
   7. L'élément EncryptionProperties
4. Les règles de traitement
   1. Le chiffrement
   2. Le décryptage
   3. Le chiffrement de XML
      1. Une implémentation de décryptage (non normatif)
      2. Une implémentation de décryptage et de remplacement (non normatif)
      3. La sérialisation de XML (non normatif)
      4. L'emballage du texte (non normatif)
5. Les algorithmes
   1. Les identificateurs des algorithmes et les obligations des implémentations
   2. Les algorithmes de chiffrement par blocs
   3. Les algorithmes de chiffrement par flot
   4. Le transport des clés
   5. L'agrément des clés
   6. L'emballage des clés symétriques
   7. Les empreintes numériques
   8. L'authentification des messages
   9. La canonisation
6. Considérations sur la sécurité
   1. Les relations avec les signatures numériques XML
   2. L'information révélée
   3. Les tickets et les vecteurs (ou valeurs) d'initialisation (IV)
   4. Le déni de service
   5. Le contenu non sécurisé
7. La conformité
8. Le type de média XML Encryption
   1. Introduction
   2. L'enregistrement du type application/xenc+xml
9. Le schéma et des exemples valides
10. Références

1 Introduction

Ce document spécifie un processus pour le chiffrement des données et la représentation du résultat dans XML. Les données peuvent être des données arbitraires (y compris un document XML), un élément XML ou le contenu d'un élément XML. Le résultat du chiffrement des données est un élément XML Encryption EncryptedData qui contient (via le contenu de l'un de ses sous-éléments) ou identifie (via une adresse URI) les données cryptées.

Lors du chiffrement d'un élément ou du contenu d'un élément XML, l'élément EncryptedData remplace l'élément ou le contenu (respectivement) dans la version cryptée du document XML.

Lors du chiffrement de données arbitraires (y compris des documents XML entiers), l'élément EncryptedData peut devenir la racine d'un nouveau document XML ou devenir un sous-élément dans un document XML choisi par l'application.

1.1 Conventions d'écriture et de conformité

Cette spécification utilise des schémas XML [XML-schema] pour décrire le modèle de contenu.

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

On ne DOIT les employer qu'aux endroits où ils sont vraiment nécessaires pour une interopération ou pour limiter un comportement potentiellement néfaste (par exemple, la limitation des retransmissions).

Par conséquent, nous utilisons ces mots-clés en lettres majuscules pour clairement spécifier les exigences sur les fonctionnalités et le comportement des protocoles et des applications qui affectent l'interopérabilité et la sécurité des implémentations. Ces mots-clés ne sont pas capitalisés pour décrire la grammaire XML ; les définitions du schéma décrivent sans ambiguïté ces exigences et nous souhaitons réserver l'utilisation de ces termes pour les descriptions en langage naturel des protocoles et des fonctionnalités. Par exemple, on pourrait décrire un attribut XML comme étant optionnel. La conformité avec la spécification des espaces de nommage dans XML [XML-ns] est définie comme OBLIGATOIRE.

1.2 La démarche conceptuelle

La philosophie de la conception et les exigences de cette spécification (y compris les limitations en rapport avec la validité d'une instance) sont traitées dans Les conditions requises pour le chiffrement XML [EncReq].

1.3 Les versions, les adresses URI des espaces de nommage et les identificateurs

Il n'est pas prévu de numéro de version explicite dans cette syntaxe. Si une version ultérieure était nécessaire, elle utilisera un espace de nommage différent. L'adresse URI expérimentale de l'espace de nommage XML [XML-NS] qui DOIT être utilisé par les implémentations de cette spécification (datée) est :

   xmlns:xenc='http://www.w3.org/2001/04/xmlenc#'

Cette espace de nommage est également employé comme préfixe pour les identificateurs des algorithmes utilisés par cette spécification. Alors que les applications DOIVENT gérer XML et les espaces de nommage XML, l'utilisation d'entités internes [XML, section 4.2.1], le préfixe d'espace de nommage XML [XML-NS, section 2] "xenc" et les conventions de valeurs par défaut/portée sont OPTIONNELS ; nous utilisons ces facilités pour fournir des exemples compacts et lisibles. De surcroît, on définit l'entité &xenc; de façon à fournir des identificateurs abrégés pour les adresses URI définis dans cette spécification. Par exemple, "&xenc;Element" correspond à "http://www.w3.org/2001/04/xmlenc#Element".

Cette spécification fait usage de l'espace de nommage et des définitions de schéma de XML Signature [XML-DSIG].

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

Les adresses URI [URI] DOIVENT respecter le type de définition anyURI [XML-Schema] et la spécification [XML-DSIG, 4.3.3.1 L'attribut URI] (c'est-à-dire, les caractères autorisés, l'échappement des caractères, la gestion du dispositif, etc.).

1.4 Remerciements

Les contributions à cette spécification par les membres suivants du groupe de travail sont vivement remerciées, en accord avec les politiques de contribution et la liste active du groupe de travail.

• Joseph Ashwood
• Simon Blake-Wilson, Certicom
• Frank D. Cavallito, BEA Systems
• Eric Cohen, PricewaterhouseCoopers
• Blair Dillaway, Microsoft (auteur)
• Blake Dournaee, RSA Security
• Donald Eastlake, Motorola (rédacteur)
• Barb Fox, Microsoft
• Christian Geuer-Pollmann, University of Siegen
• Tom Gindin, IBM
• Jiandong Guo, Phaos
• Phillip Hallam-Baker, Verisign
• Amir Herzberg, NewGenPay
• Merlin Hughes, Baltimore
• Frederick Hirsch
• Maryann Hondo, IBM
• Takeshi Imamura, IBM (auteur)
• Mike Just, Entrust, Inc.
• Brian LaMacchia, Microsoft
• Hiroshi Maruyama, IBM
• John Messing, Law-on-Line
• Shivaram Mysore, Sun Microsystems
• Thane Plambeck, Verisign
• Joseph Reagle, W3C (président, rédacteur)
• Aleksey Sanin
• Jim Schaad, Soaring Hawk Consulting
• Ed Simon, XMLsec (auteur)
• Daniel Toth, Ford
• Yongge Wang, Certicom
• Steve Wiley, myProof

De plus, nous remercions les personnes suivantes pour leurs commentaires pendant et après le projet dans sa version en dernier appel :

• Martin Dürst, W3C
• Dan Lanz, Zolera
• Susan Lesch, W3C
• David Orchard, BEA Systems
• Ronald Rivest, MIT

2 Vue d'ensemble sur le chiffrement et exemples (non normatif)

Cette section offre un aperçu et des exemples sur la syntaxe de XML Encryption. La syntaxe formelle se trouve dans La syntaxe du chiffrement (section 3) ; le traitement spécifique est donné dans Les règles de traitement (section 4).

Exprimé dans une forme abrégée, l'élément EncryptedData a la structure suivante (où le caractère ? indique zéro ou une occurrence, un + une ou plusieurs occurrences, un * zéro occurrence ou plus et la balise de l'élément vide signifiant que l'élément doit être vide) :

  <EncryptedData Id? Type? MimeType? Encoding?>
    <EncryptionMethod/>?
    <ds:KeyInfo>
      <EncryptedKey>?
      <AgreementMethod>?
      <ds:KeyName>?
      <ds:RetrievalMethod>?
      <ds:*>?
    </ds:KeyInfo>?
    <CipherData>
      <CipherValue>?
      <CipherReference URI?>?
    </CipherData>
    <EncryptionProperties>?
  </EncryptedData>

L'élément CipherData enveloppe ou référence les données cryptées brutes. S'il est enveloppant, les données cryptées brutes représentent le contenu de l'élément CipherValue ; s'il est référençant, l'attribut URI de l'élément CipherReference pointe vers l'emplacement des données cryptées brutes.

2.1 La granularité du chiffrement

Considérons les informations de paiement fictives suivantes, qui comprennent une information d'identité et une information concernant la méthode de paiement (par exemple, carte de crédit, transfert monétaire ou chèque électronique) :

  <?xml version='1.0'?>
  <InfoPaiement xmlns='http://example.com/paiementv2'>
    <Nom>Marcel DUPOND</Nom>
    <CarteCredit Plafond='5000' Monnaie='EURO'>
      <Numero>4019 2445 0277 5567</Numero>
      <Emetteur>Example Bank</Emetteur>
      <Expiration>04/02</Expiration>
    </CarteCredit>
  </InfoPaiement>

Ce balisage établit que Marcel DUPOND fait usage de sa carte de crédit dont le plafond est de 5000 €.

2.1.1 Le chiffrement d'un élément XML

Le numéro de carte de crédit de M.DUPOND est une information sensible ! Si l'application souhaite garder cette information confidentielle, elle peut chiffrer l'élément CarteCredit :

  <?xml version='1.0'?>
  <InfoPaiement xmlns='http://example.com/paiementv2'>
    <Nom>Marcel DUPOND</Nom>
    <EncryptedData Type='http://www.w3.org/2001/04/xmlenc#Element'
     xmlns='http://www.w3.org/2001/04/xmlenc#'>
      <CipherData>
        <CipherValue>A23B45C56</CipherValue>
      </CipherData>
    </EncryptedData>
  </InfoPaiement>

En chiffrant l'élément CarteCredit entier, de la balise ouvrante jusqu'à la balise fermante, l'identité même de l'élément est dissimulée. (Une oreille indiscrète ne sait pas s'il s'agit d'une carte de crédit ou d'un transfert monétaire). L'élément CipherData contient la sérialisation cryptée de l'élément CarteCredit.

2.1.2 Le chiffrement du contenu d'un élément XML (les éléments)

Comme scénario alternatif, il peut être utile pour les agents intermédiaires de savoir que Marcel a utilisé une carte de crédit avec un plafond particulier, mais pas de connaître le numéro, l'émetteur et la date d'expiration de la carte. Auquel cas, le contenu (les données textuelles ou les sous-éléments) de l'élément CarteCredit est crypté :

  <?xml version='1.0'?> 
  <InfoPaiement xmlns='http://example.com/paymentv2'>
    <Nom>Marcel DUPOND</Nom>
    <CarteCredit Limite='5,000' Monnaie='EURO'>
      <EncryptedData xmlns='http://www.w3.org/2001/04/xmlenc#'
       Type='http://www.w3.org/2001/04/xmlenc#Content'>
        <CipherData>
          <CipherValue>A23B45C56</CipherValue>
        </CipherData>
      </EncryptedData>
    </CarteCredit>
  </InfoPaiement>

2.1.3 Le chiffrement du contenu d'un élément XML (les données textuelles)

Autrement, considérons le scénario selon lequel toutes les informations, excepté le numéro de la carte de crédit en question, sont en clair, y compris le fait de l'existence de l'élément Numero :

  <?xml version='1.0'?> 
  <InfoPaiement xmlns='http://example.com/paymentv2'>
    <Nom>Marcel DUPOND</Nom>
    <CarteCredit Limite='5,000' Monnaie='EURO'>
      <Numero>
        <EncryptedData xmlns='http://www.w3.org/2001/04/xmlenc#'
         Type='http://www.w3.org/2001/04/xmlenc#Content'>
          <CipherData>
            <CipherValue>A23B45C56</CipherValue>
          </CipherData>
        </EncryptedData>
      </Numero>
      <Emetteur>Example Bank</Emetteur>
      <Expiration>04/02</Expiration>
    </CarteCredit>
  </InfoPaiement>

Les éléments CarteCredit et Numero sont tous deux en clair, mais le contenu de données textuelles de Numero est crypté.

2.1.4 Le chiffrement de données arbitraires et des documents XML

Si le scénario de l'application exige que toutes les informations soient cryptées, le document entier est crypté en tant que séquence d'octets. Cela s'applique aux données arbitraires, y compris les documents XML.

  <?xml version='1.0'?> 
  <EncryptedData xmlns='http://www.w3.org/2001/04/xmlenc#'
   MimeType='text/xml'>
    <CipherData>
      <CipherValue>A23B45C56</CipherValue>
    </CipherData>
  </EncryptedData>

2.1.5 Le surchiffrement : le chiffrement de l'élément EncryptedData

Un document XML peut contenir zéro ou plus élément EncryptedData. L'élément EncryptedData ne peut être le parent ou le sous-élément d'un autre élément EncryptedData. Cependant, les données cryptées en question peuvent être n'importe quoi, y compris des éléments EncryptedData et EncryptedKey (c'est-à-dire, un surchiffrement). Lors du surchiffrement d'un élément EncryptedData ou EncryptedKey, on doit chiffrer l'élément entier. Le chiffrement du contenu seul de ces éléments ou le chiffrement de sous-éléments sélectionnés constituent des instances invalides pour le schéma fourni.
Par exemple, considérons ce qui suit :

  <pay:InfoPaiement xmlns:pay='http://example.com/paiementv2'>
    <EncryptedData Id='ED1' xmlns='http://www.w3.org/2001/04/xmlenc#'
     Type='http://www.w3.org/2001/04/xmlenc#Element'>
      <CipherData>
        <CipherValue>EncryptedDataOriginal</CipherValue>
      </CipherData>
    </EncryptedData>
  </pay:InfoPaiement>

Un surchiffrement valide de "//xenc:EncryptedData[@Id='ED1']" serait :

  <pay:InfoPaiement xmlns:pay='http://example.com/paiementv2'>
    <EncryptedData Id='ED2' xmlns='http://www.w3.org/2001/04/xmlenc#'
     Type='http://www.w3.org/2001/04/xmlenc#Element'>
      <CipherData>
        <CipherValue>EncryptedDataNouveau</CipherValue>
      </CipherData>
    </EncryptedData>
  </pay:InfoPaiement>

Dans lequel le contenu 'EncryptedDataNouveau' de l'élément CipherValue est le codage en base64 de la séquence d'octets résultant du chiffrement de l'élément EncryptedData ayant l'attribut Id='ED1'.

2.2 L'utilisation des éléments EncryptedData et EncryptedKey

2.2.1 L'élément EncryptedData avec une clé symétrique (KeyName)

  [s1] <EncryptedData xmlns='http://www.w3.org/2001/04/xmlenc#'
        Type='http://www.w3.org/2001/04/xmlenc#Element'/>
  [s2]   <EncryptionMethod
          Algorithm='http://www.w3.org/2001/04/xmlenc#tripledes-cbc'/>
  [s3]   <ds:KeyInfo xmlns:ds='http://www.w3.org/2000/09/xmldsig#'>
  [s4]     <ds:KeyName>Marcel DUPOND</ds:KeyName>
  [s5]   </ds:KeyInfo>
  [s6]   <CipherData><CipherValue>DEADBEEF</CipherValue></CipherData>
  [s7] </EncryptedData>

[s1] Le type des données cryptées peut être représenté par une valeur d'attribut pour faciliter le décryptage et le traitement ultérieur. Dans le cas présent, les données cryptées étaient de type "element". Les alternatives comprennent le type "content" d'un élément ou une séquence d'octets externe que l'on peut aussi identifier via les attributs MimeType et Encoding.

[s2] Ceci est une clé de chiffrement symétrique (3DES CBC).

[s4] Le nom "Marcel DUPOND" est associé à cette clé symétrique.

[s6] L'élément CipherData contient un élément CipherValue, qui est une séquence d'octets codés en base64. Autrement, celui-ci pourrait contenir un élément CipherReference, qui est une adresse URI soumise aux transformations nécessaires pour obtenir les données cryptées sous forme d'une séquence d'octets.

2.2.2 L'élément EncryptedKey (ReferenceList, ds:RetrievalMethod, CarriedKeyName)

La structure suivante de l'élément EncryptedData est très semblable à la précédente, sauf que cette fois-ci la clé est appelée à l'aide d'un élément ds:RetrievalMethod :

  [t01] <EncryptedData Id='ED' 
         xmlns='http://www.w3.org/2001/04/xmlenc#'>
  [t02]   <EncryptionMethod 
           Algorithm='http://www.w3.org/2001/04/xmlenc#aes128-cbc'/>
  [t03]   <ds:KeyInfo xmlns:ds='http://www.w3.org/2000/09/xmldsig#'>
  [t04]     <ds:RetrievalMethod URI='#EK'
             Type="http://www.w3.org/2001/04/xmlenc#EncryptedKey"/>
  [t05]     <ds:KeyName>Julie MARTIN</ds:KeyName>
  [t06]   </ds:KeyInfo>
  [t07]   <CipherData><CipherValue>DEADBEEF</CipherValue></CipherData>
  [t08] </EncryptedData>

[t02] Ceci est une clé de chiffrement symétrique (AES-128-CBC).

[t04] On utilise l'élément ds:RetrievalMethod pour indiquer l'emplacement d'une clé de type &xenc;EncryptedKey. La clé (AES) est située à '#EK'.

[t05] L'élément ds:KeyName offre une méthode d'identification alternative de la clé nécessaire pour décrypter l'élément CipherData. L'un, l'autre ou les deux éléments ds:KeyName et ds:KeyRetrievalMethod pourraient être utilisés pour identifier la même clé.

A l'intérieur du même document XML, il existait une structure EncryptedKey qui était appelée depuis [t04] :

  [t09] <EncryptedKey Id='EK' xmlns='http://www.w3.org/2001/04/xmlenc#'>
  [t10]   <EncryptionMethod 
           Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/>
  [t11]   <ds:KeyInfo xmlns:ds='http://www.w3.org/2000/09/xmldsig#'>
  [t12]     <ds:KeyName>Marcel DUPOND</ds:KeyName>
  [t13]   </ds:KeyInfo>
  [t14]   <CipherData><CipherValue>xyzabc</CipherValue></CipherData>
  [t15]   <ReferenceList>
  [t16]     <DataReference URI='#ED'/>
  [t17]   </ReferenceList>
  [t18]   <CarriedKeyName>Julie MARTIN</CarriedKeyName>
  [t19] </EncryptedKey>

[t09] L'élément EncryptedKey est similaire à l'élément EncryptedData, sauf que les données cryptées représentent toujours une valeur de clé.

[t10] L'élément EncryptionMethod est l'algorithme de clé publique RSA.

[t12] La valeur "Marcel DUPOND" de ds:KeyName est une propriété de la clé qui est nécessaire au décryptage (en utilisant RSA) de l'élément CipherData.

[t14] L'élément CipherValue dans CipherData est une séquence d'octets qui est traitée (sérialisée, cryptée et codée) selon l'objet crypté appelant dans l'élément EncryptionMethod. (Remarquer que l'élément EncryptionMethod dans un élément EncryptedKey est l'algorithme qui est employé pour chiffrer ces octets, sans préciser de quel type d'octets il s'agit).

[t15-17] Un élément ReferenceList identifie les objets cryptés (DataReference et KeyReference) chiffrés avec cette clé. L'élément ReferenceList contient une liste de références vers des données cryptées par la clé symétrique transportée dans cette structure.

[t18] L'élément CarriedKeyName est utilisé pour identifier la valeur de clé cryptée, qui peut être appelée par l'élément KeyName dans ds:KeyInfo. (Puisque l'attribut ID doit être unique pour un document, l'élément CarriedKeyName peut indiquer que plusieurs structures EncryptedKey contiennent la même valeur de clé, chiffrée pour divers destinataires).

3 La syntaxe du chiffrement

Cette section fournit une description détaillée de la syntaxe et des fonctionnalités de XML Encryption. Les fonctionnalités décrites dans cette section DOIVENT être mises en œuvre, à moins que ce ne soit indiqué autrement. La syntaxe est définie via [XML-Schema] avec le préambule XML, la déclaration, l'entité interne et l'import suivants :

  Définitions de schéma :

  <?xml version="1.0" encoding="utf-8"?>
  <!DOCTYPE schema  PUBLIC "-//W3C//DTD XMLSchema 200102//EN"
   "http://www.w3.org/2001/XMLSchema.dtd"
   [
     <!ATTLIST schema
       xmlns:xenc CDATA #FIXED 'http://www.w3.org/2001/04/xmlenc#'
       xmlns:ds CDATA #FIXED 'http://www.w3.org/2000/09/xmldsig#'>
     <!ENTITY xenc 'http://www.w3.org/2001/04/xmlenc#'>
     <!ENTITY % p ''>
     <!ENTITY % s ''>
    ]>
  
  <schema xmlns='http://www.w3.org/2001/XMLSchema' version='1.0'
          xmlns:ds='http://www.w3.org/2000/09/xmldsig#'
          xmlns:xenc='http://www.w3.org/2001/04/xmlenc#'
          targetNamespace='http://www.w3.org/2001/04/xmlenc#'
          elementFormDefault='qualified'>

    <import namespace='http://www.w3.org/2000/09/xmldsig#'
            schemaLocation='http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core-schema.xsd'/>

3.1 L'élément EncryptedType

L'élément EncryptedType est le type abstrait à partir duquel les éléments EncryptedData et EncryptedKey sont dérivés. Bien que ces deux derniers éléments soient très semblables par leur modèle de contenu, leur distinction syntaxique est utile au traitement. Une implémentation DOIT générer des éléments EncryptedData ou EncryptedKey avec une validation de schéma relâchée [XML-schema], comme spécifié par les déclarations de schéma suivantes. (Remarquer que la génération avec une validation de schéma relâchée signifie que le contenu permis par xsd:ANY ne doit pas forcément être valide). Les implémentations DEVRAIENT créer ces structures XML (les éléments EncryptedType et leurs descendants/contenus) dans la Forme de Normalisation C [NFC, NFC-Corrigendum].

  Définition de schéma :

  <complexType name='EncryptedType' abstract='true'>
    <sequence>
      <element name='EncryptionMethod' type='xenc:EncryptionMethodType' 
               minOccurs='0'/>
      <element ref='ds:KeyInfo' minOccurs='0'/>
      <element ref='xenc:CipherData'/>
      <element ref='xenc:EncryptionProperties' minOccurs='0'/>
    </sequence>
    <attribute name='Id' type='ID' use='optional'/>
    <attribute name='Type' type='anyURI' use='optional'/>
    <attribute name='MimeType' type='string' use='optional'/>
    <attribute name='Encoding' type='anyURI' use='optional'/> 
   </complexType>

L'élément EncryptionMethod est optionnel ; il décrit l'algorithme de chiffrement appliqué aux données cryptées. Si l'élément est absent, l'algorithme de chiffrement doit être connu du destinataire, sinon le décryptage échouera.

L'élément ds:KeyInfo est optionnel, défini par [XML-DSIG] ; il transporte des informations concernant la clé utilisée pour chiffrer les données. Les sections suivantes de cette spécification définissent des éléments nouveaux qui peuvent apparaître comme sous-éléments de ds:KeyInfo.

L'élément CipherData est obligatoire ; il contient des éléments CipherValue ou CipherReference avec les données cryptées.

L'élément EncryptionProperties peut contenir des informations supplémentaires concernant la génération de l'élément EncryptedType (par exemple, une estampille de date/heure).

L'attribut Id est optionnel ; c'est la méthode standard pour assigner une chaîne id à l'élément dans le contexte du document.

L'attribut Type est optionnel ; il identifie une information de type au sujet de la forme en texte clair du contenu crypté. Bien qu'optionnel, cette spécification l'utilise avantageusement pour un traitement obligatoire, décrit dans Les règles de traitement : le décryptage (section 4.2). Si l'élément EncryptedData contient des données de Type valant "element", ou "content", et remplace ces données dans le contexte d'un document XML, il est vivement recommandé de fournir un attribut Type. Sans cette information, le décrypteur sera incapable de rétablir automatiquement le document XML dans sa forme originale en texte clair.

L'attribut MimeType est optionnel (consultatif) et décrit le type de média des données qui ont été chiffrées. La valeur de cet attribut est une chaîne avec des valeurs définies par [MIME]. Par exemple, si les données cryptées représentent une image PNG codée en base64, le codage de transfert Encoding peut être spécifié par 'http://www.w3.org/2000/09/xmldsig#base64' et MimeType par 'image/png'. Cet attribut est purement consultatif ; aucune validation de l'information de MimeType n'est requise et elle n'enjoint pas l'application de chiffrement à effectuer un quelconque traitement supplémentaire. Remarque : cette information peut être superflue si elle est déjà reliée à l'identificateur dans l'attribut Type. Par exemple, les types "element" et "content" définis dans cette spécification sont toujours du texte codé en UTF-8.

3.2 L'élément EncryptionMethod

L'élément EncryptionMethod est optionnel ; il décrit l'algorithme de chiffrement appliqué aux données à chiffrer. Si l'élément est absent, l'algorithme de chiffrement doit être connu du destinataire, sinon le décryptage échouera.

  Définition de schéma :

  <complexType name='EncryptionMethodType' mixed='true'>
    <sequence>
      <element name='KeySize' minOccurs='0' type='xenc:KeySizeType'/>
      <element name='OAEPparams' minOccurs='0' type='base64Binary'/>
      <any namespace='##other' minOccurs='0' maxOccurs='unbounded'/>
    </sequence>
    <attribute name='Algorithm' type='anyURI' use='required'/>
  </complexType>

Les sous-éléments de EncryptionMethod autorisés sont déterminés par la valeur spécifique de l'adresse URI de l'attribut Algorithm, le sous-élément KeySize est toujours admis. Par exemple, l'algorithme RSA-OAEP (section 5.4.2) utilise les éléments ds:DigestMethod et OAEPparams. (Nous nous appuyons sur la construction de schéma ANY parce qu'il n'est pas possible de spécifier le contenu d'un élément en fonction de la valeur d'un attribut).

La présence de tout sous-élément, sous EncryptionMethod, qui n'est pas autorisée par l'algorithme, ou la présence d'un sous-élément KeySize en incohérence avec l'algorithme, DOIT être considérée comme une erreur. (Toutes les adresses URI des algorithmes spécifiés dans ce document supposent une taille de clé mais ce n'est pas vrai en général. La plupart des algorithmes courants de chiffrement par flot [NdT. stream cipher] admettent des tailles de clé variables).

3.3 L'élément CipherData

L'élément CipherData est obligatoire ; il fournit les données cryptées. Il doit soit contenir la séquence d'octets cryptée comme texte codé en base64 de l'élément CipherValue, soit fournir une référence vers un emplacement extérieur contenant la séquence d'octets cryptée, via l'élément CipherReference.

  Définition de schéma :

  <element name='CipherData' type='xenc:CipherDataType'/>
  <complexType name='CipherDataType'>
     <choice>
       <element name='CipherValue' type='base64Binary'/>
       <element ref='xenc:CipherReference'/>
     </choice>
   </complexType>

3.3.1 L'élément CipherReference

Si l'élément CipherValue n'est pas fourni directement, l'élément CipherReference identifie une source qui, une fois traitée, produit la séquence d'octets cryptée.

La valeur en question s'obtient comme suit. L'attribut URI de l'élément CipherReference contient un identificateur qui est résolu. Si l'élément CipherReference contient une séquence d'éléments Transform OPTIONNELS, les données issues de la résolution de l'adresse URI sont transformées comme spécifié, de manière à produire la valeur de chiffrement voulue. Par exemple, quand la valeur est codée en base64 à l'intérieur d'un document XML ; les transformations pourraient spécifier une expression XPath suivie par un décodage base64 de manière à extraire les octets.

Les syntaxes de l'attribut URI et de l'élément Transforms sont similaires à celles de [XML-DSIG]. Cependant, il existe une différence entre le traitement d'une signature et celui d'un chiffrement. Dans [XML-DSIG], les traitements de génération et de validation tous deux commencent avec les mêmes données source et réalisent cette transformation dans le même ordre. Dans le décryptage, le décrypteur ne dispose que des données cryptées et les transformations spécifiées sont énumérées, pour le décrypteur, dans l'ordre nécessaire pour obtenir les octets. Par conséquent, puisque l'élément Transforms a plusieurs significations, celui-ci se trouve dans l'espace de nommage &xenc;.

Par exemple, si la valeur cryptée concernée est capturée dans un élément CipherValue à l'intérieur d'un document XML différent, l'élément CipherReference pourrait ressembler à ceci :

  <CipherReference URI="http://www.example.com/CipherValues.xml">
    <Transforms>
      <ds:Transform 
       Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116">
          <ds:XPath xmlns:rep="http://www.example.com/repository">
            self::text()[parent::rep:CipherValue[@Id="exemple1"]]
          </ds:XPath>
      </ds:Transform>
      <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#base64"/>
    </Transforms>
  </CipherReference>

Les implémentations DOIVENT gérer les fonctionnalités de l'élément CipherReference et les mêmes codages, résolution, dispositif et codes de réponse HTTP des adresses URI que pour [XML-DSIG]. Les fonctionnalités de l'élément Transform et des algorithmes de transformation particuliers sont OPTIONNELLES.

  Définition de schéma :

  <element name='CipherReference' type='xenc:CipherReferenceType'/>
   <complexType name='CipherReferenceType'>
       <sequence>
         <element name='Transforms' type='xenc:TransformsType' minOccurs='0'/>
       </sequence>
       <attribute name='URI' type='anyURI' use='required'/>
   </complexType>

    <complexType name='TransformsType'>
       <sequence>
         <element ref='ds:Transform' maxOccurs='unbounded'/> 
       </sequence>
     </complexType>

3.4 L'élément EncryptedData

L'élément EncryptedData est l'élément principal dans la syntaxe. Non seulement son sous-élément CipherData contient les données cryptées, mais c'est aussi l'élément qui remplace l'élément crypté ou sert comme racine du nouveau document.

  Définition de schéma :

  <element name='EncryptedData' type='xenc:EncryptedDataType'/>
  <complexType name='EncryptedDataType'>
    <complexContent>
     <extension base='xenc:EncryptedType'>
     </extension>
    </complexContent>
  </complexType>

3.5 Les extensions de l'élément ds:KeyInfo

Il existe trois façons de fournir l'élément de mise à la clé [NdT. keying material] nécessaire pour décrypter l'élément CipherData :

1. Les éléments EncryptedData ou EncryptedKey spécifient l'élément de mise à la clé associé via un sous-élément de l'élément ds:KeyInfo. Tous les sous-éléments de ds:KeyInfo spécifiés dans [XML-DSIG] PEUVENT servir d'éléments qualifiés :
   1. La gestion de l'élément ds:KeyValue est OPTIONNELLE et peut être utilisée pour le transport des clés publiques, telles que des valeurs de clés Diffie-Hellman (section 5.5.1). (Inclure la clé de décryptage en texte clair, que ce soit une clé privée ou une clé publique, n'est évidemment PAS RECOMMANDÉ) ;
   2. La gestion de l'élément ds:KeyName pour se référer à l'élément CarriedKeyName d'un élément EncryptedKey est RECOMMANDÉ ;
   3. La gestion de l'élément ds:RetrievalMethod dans un même document est OBLIGATOIRE.

   De surcroît, on fournit deux sous-éléments supplémentaires : les applications DOIVENT gérer l'élément EncryptedKey (section 3.5.1) et PEUVENT gérer l'élément AgreementMethod (section 5.5).

2. Un élément EncryptedKey détaché (pas à l'intérieur d'un élément ds:KeyInfo) peut spécifier l'élément EncryptedData, ou EncryptedKey, sur lequel sa clé décryptée s'appliquera via un élément DataReference, ou KeyReference (section 3.6) ;
3. Le destinataire peut déterminer l'élément de mise à la clé selon le contexte de l'application et n'a donc pas besoin d'être mentionné explicitement dans le XML transmis.

3.5.1 L'élément EncryptedKey

Identificateur

Type="http://www.w3.org/2001/04/xmlenc#EncryptedKey"

(On peut l'utiliser à l'intérieur d'un élément ds:RetrievalMethod pour identifier le type de l'appelant).

L'élément EncryptedKey est utilisé pour le transport de clés de chiffrement, d'un donneur d'ordre vers un ou des destinataires. Il peut être employé comme document XML autonome, être placé dans le document d'une application ou apparaître dans un élément EncryptedData comme sous-élément d'un élément ds:KeyInfo. La valeur de clé est toujours chiffrée pour le ou les destinataires. Quand l'élément EncryptedKey est décrypté, les octets résultants sont mis à disposition de l'algorithme EncryptionMethod sans autre traitement supplémentaire.

  Définition de schéma :

  <element name='EncryptedKey' type='xenc:EncryptedKeyType'/>
  <complexType name='EncryptedKeyType'>
    <complexContent>
      <extension base='xenc:EncryptedType'>
        <sequence>
          <element ref='xenc:ReferenceList' minOccurs='0'/>
          <element name='CarriedKeyName' type='string' minOccurs='0'/>
        </sequence>
        <attribute name='Recipient' type='string' use='optional'/>
      </extension>
    </complexContent>   
  </complexType>

L'élément ReferenceList est optionnel et contient des pointeurs vers les données et les clés chiffrées avec cette clé. La liste de références peut contenir plusieurs références vers les éléments EncryptedKey et EncryptedData. Ceci est réalisé en utilisant des éléments KeyReference et DataReference respectivement. Leurs définitions suivent.

L'élément CarriedKeyName est optionnel ; il associe un nom lisible par l'utilisateur à la valeur de clé. On peut alors l'utiliser pour référencer la clé avec l'élément ds:KeyName dans un élément ds:KeyInfo. La même étiquette CarriedKeyName, à la différence d'un type ID, peut survenir plusieurs fois dans un seul document. La valeur de la clé devant être la même dans tous les éléments EncryptedKey identifiés par le même label CarriedKeyName dans un seul document XML. Remarquer, puisque les blancs sont significatifs dans la valeur de l'élément ds:KeyName, que ceux-ci le sont aussi dans la valeur de l'élément CarriedKeyName.

L'attribut Recipient est optionnel et contient une indication sur le destinataire auquel cette clé cryptée est destinée. Son contenu dépend de l'application donnée.

L'attribut Type, hérité de l'élément EncryptedType, peut être utilisé pour préciser le type de la clé cryptée, quand l'attribut Algorithm de l'élément EncryptionMethod ne définit pas de codage/représentation non équivoque. (Remarquer que tous les algorithmes dans cette spécification offrent une représentation sans ambiguïté de leurs structures de clés associées).

3.5.2 L'élément ds:RetrievalMethod

L'élément ds:RetrievalMethod [XML-DSIG], avec un attribut Type de valeur "http://www.w3.org/2001/04/xmlenc#EncryptedKey", fournit un moyen pour exprimer un lien vers un élément EncryptedKey, contenant la clé nécessaire pour décrypter l'élément CipherData associé à un élément EncryptedData, ou EncryptedKey. L'élément ds:RetrievalMethod, ayant ce type, est toujours un sous-élément de l'élément ds:KeyInfo et peut apparaître plusieurs fois. S'il y a plus d'une instance d'un élément ds:RetrievalMethod dans un élément ds:KeyInfo de ce type, alors les objets EncryptedKey qui sont appelés doivent contenir la même valeur de clé, éventuellement chiffrée de différentes manières ou pour différents destinataires.

  Définition de schéma :

  <!--
      <attribute name='Type' type='anyURI' use='optional'
      fixed='http://www.w3.org/2001/04/xmlenc#EncryptedKey' />
  -->

3.6 L'élément ReferenceList

L'élément ReferenceList contient des pointeurs, à partir d'une valeur de clé d'un élément EncryptedKey vers des items cryptés selon cette valeur de clé (éléments EncryptedData ou EncryptedKey).

  Définition de schéma :

  <element name='ReferenceList'>
    <complexType>
      <choice minOccurs='1' maxOccurs='unbounded'>
        <element name='DataReference' type='xenc:ReferenceType'/>
        <element name='KeyReference' type='xenc:ReferenceType'/>
      </choice>
    </complexType>
  </element>

  <complexType name='ReferenceType'>
    <sequence>
      <any namespace='##other' minOccurs='0' maxOccurs='unbounded'/>
    </sequence>
    <attribute name='URI' type='anyURI' use='required'/>
  </complexType>

Les éléments DataReference s'utilisent pour appeler les éléments EncryptedData qui ont été chiffrés à l'aide de la clé définie dans l'élément EncryptedKey englobant. Plusieurs éléments DataReference peuvent survenir s'il existe plusieurs éléments EncryptedData qui sont chiffrés par la même clé.

Les éléments KeyReference s'utilisent pour appeler les éléments EncryptedKey qui ont été chiffrés à l'aide de la clé définie dans l'élément EncryptedKey englobant. Plusieurs éléments KeyReference peuvent survenir s'il existe plusieurs éléments EncryptedKey qui sont chiffrés par la même clé.

Pour les deux types d'appel, on peut spécifier en option des sous-éléments pour aider le destinataire à ramener les éléments EncryptedKey et/ou EncryptedData. Ces sous-éléments pourraient apporter des informations telles que des transformations XPath, des transformations de décompression, ou des informations comment obtenir les éléments à partir d'un service de distribution de documents. Par exemple :

  <ReferenceList>
    <DataReference URI="#facture34">
      <ds:Transforms>
        <ds:Transform Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116">
          <ds:XPath xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
              self::xenc:EncryptedData[@Id="exemple1"]
          </ds:XPath>
        </ds:Transform>
      </ds:Transforms>
    </DataReference>
  </ReferenceList>

3.7 L'élément EncryptionProperties

Identificateur

Type="http://www.w3.org/2001/04/xmlenc#EncryptionProperties"

(On peut l'utiliser à l'intérieur d'un élément ds:Reference pour identifier le type de l'appelant).

Des items d'information supplémentaires concernant la génération des éléments EncryptedData ou EncryptedKey peuvent être placés dans un élément EncryptionProperty (par exemple, une estampille de date/heure ou le numéro de série du matériel employé pour le chiffrement). L'attribut Target identifie la structure EncryptedType en train d'être décrite. L'élément anyAttribute permet l'intégration des attributs de l'espace de nommage XML à inclure (c'est-à-dire, xml:space, xml:lang et xml:base).

  Définition de schéma :

  <element name='EncryptionProperties' type='xenc:EncryptionPropertiesType'/> 
  <complexType name='EncryptionPropertiesType'>
    <sequence>
      <element ref='xenc:EncryptionProperty' maxOccurs='unbounded'/> 
    </sequence>
    <attribute name='Id' type='ID' use='optional'/> 
  </complexType>

    <element name='EncryptionProperty' type='xenc:EncryptionPropertyType'/> 
    <complexType name='EncryptionPropertyType' mixed='true'>
      <choice maxOccurs='unbounded'>
        <any namespace='##other' processContents='lax'/>
      </choice>
      <attribute name='Target' type='anyURI' use='optional'/> 
      <attribute name='Id' type='ID' use='optional'/> 
      <anyAttribute namespace="http://www.w3.org/XML/1998/namespace"/>
    </complexType>

4 Les règles de traitement

Cette section décrit les opérations que les implémentations de cette spécification doivent effectuer pour le traitement du chiffrement et du décryptage. Les obligations de conformité sont spécifiées sur les rôles suivants :

Application

L'application qui demande une implémentation XML Encryption via la fourniture des données et des paramètres nécessaires pour leur traitement.

Chiffreur

Une implémentation XML Encryption ayant pour rôle de chiffrer des données.

Décrypteur

Une implémentation XML Encryption ayant pour rôle de décrypter des données.

4.1 Le chiffrement

Pour chaque item de données à chiffrer comme élément EncryptedData ou EncryptedKey (des éléments dérivés de EncryptedType), le chiffreur doit :

1. Sélectionner l'algorithme (et les paramètres) à employer pour le chiffrement de ces données ;
2. Obtenir et (en option) représenter la clé.
   1. Si la clé doit être identifiée (via un nommage, une adresse URI ou incorporée dans un sous-élément), construire la structure ds:KeyInfo comme il faut (par exemple, ds:KeyName, ds:KeyValue, ds:RetrievalMethod, etc.) ;
   2. Si la clé doit elle-même être chiffrée, construire un élément EncryptedKey en appliquant récursivement ce processus de chiffrement. Le résultat peut alors être un sous-élément de ds:KeyInfo, ou il peut exister ailleurs et être identifié dans l'étape précédente.
3. Chiffrer les données
   1. Si les données sont du type "element" [XML, section 3] ou "content" [XML, section 3.1], obtenir les octets par sérialisation des données en UTF-8, comme spécifié dans [XML]. (L'application DOIT fournir des données XML dans la forme [NFC]). La sérialisation PEUT être réalisée par le chiffreur. Si le chiffreur n'effectue pas la sérialisation, alors c'est l'application qui DOIT le faire ;
   2. Si les données sont d'un autre type, qui ne sont pas déjà des octets, l'application DOIT les sérialiser comme octets ;
   3. Chiffrer les octets en utilisant l'algorithme et la clé obtenus lors des étapes 1 et 2 ;
   4. À moins que le décrypteur ne connaisse implicitement le type des données cryptées, le chiffreur DEVRAIT fournir le type pour une représentation.

      La définition de ce type, comme attaché à un identificateur, spécifie comment obtenir et interpréter les octets en texte clair après décryptage. Par exemple, l'identificateur pourrait indiquer que les données sont une instance d'une autre application (telle une certaine application de compression XML) dont le traitement doit continuer. Ou bien, si les données forment une simple séquence d'octets, que celles-ci PEUVENT être décrites avec les attributs MimeType et Encoding. Par exemple, les données pourrait être un document XML (MimeType="text/xml"), une séquence de caractères (MimeType="text/plain") ou les données binaires d'une image (MimeType="image/png").

4. Construire la structure de l'élément EncryptedType (EncryptedData ou EncryptedKey) :

   Une structure EncryptedType représente toutes les informations commentées précédemment, y compris le type des données cryptées, l'algorithme de chiffrement, les paramètres, la clé, etc.

   1. Si la séquence d'octets obtenue dans l'étape 3 doit être stockée dans l'élément CipherData, dans l'élément EncryptedType, alors la séquence d'octets cryptée est codée en base64 et insérée comme contenu d'un élément CipherValue ;
   2. Si la séquence d'octets cryptée doit être stockée à l'extérieur de la structure EncryptedType, alors stocker ou retourner la séquence d'octets cryptée, et représenter l'adresse URI et les transformations (le cas échéant) requis par le chiffreur pour ramener la séquence d'octets cryptée dans un élément CipherReference.
5. Traiter l'élément EncryptedData
   1. Si la valeur de l'attribut Type de l'élément EncryptedData est "element" ou "content", alors le chiffreur DOIT être capable de retourner l'élément EncryptedData à l'application. L'application PEUT l'utiliser comme élément supérieur dans un nouveau document XML ou l'insérer dans un autre document XML, ce qui peut demander un nouveau codage.

      Le chiffreur DEVRAIT être capable de remplacer l'objet non chifré "element" ou "content" par l'élément EncryptedData. Quand une application demande à ce qu'un élément ou un contenu XML soit remplacé, elle fournit le contexte du document XML en plus d'identifier l'élément ou le contenu à remplacer. Le chiffreur retire l'élément identifié, ou le contenu, et insère l'élément EncryptedData à la place.

      (Remarque : Quand la valeur de l'attribut Type est "content", le document qui résulte du décryptage ne sera pas bien-formé si (a) le texte en clair original n'était pas bien-formé (par exemple, une valeur de type PCDATA n'est pas bien-formée en soi) et (b) l'élément EncryptedData n'était pas précédemment l'élément racine du document).

   2. Si la valeur de l'attribut Type de l'élément EncryptedData n'est pas "element" ou "content", alors le chiffreur DOIT toujours retourner l'élément EncryptedData à l'application. L'application PEUT l'utiliser comme élément supérieur dans un nouveau document XML ou l'insérer dans un autre document XML, ce qui peut demander un nouveau codage.

4.2 Le décryptage

Pour chaque élément dérivé de EncryptedType à décrypter (c'est-à-dire, EncryptedData ou EncryptedKey), le décrypteur doit :

1. Traiter l'élément pour déterminer l'algorithme, les paramètres et l'élément ds:KeyInfo à utiliser. Si certaines informations manquent, l'application DOIT les fournir ;
2. Localiser la clé de chiffrement des données en fonction de l'élément ds:KeyInfo, qui peut contenir un ou plusieurs sous-éléments. Ces sous-éléments n'ont pas d'ordre de traitement implicite. Si la clé de chiffrement des données est cryptée, localiser la clé adéquate pour la décrypter. (Cet étape peut être récursive, puisque la clé de la clé de chiffrement peut elle-même être cryptée). Ou bien, on pourrait ramener la clé de chiffrement des données d'un entrepôt local, en utilisant les attributs fournis ou une relation implicite ;
3. Décrypter les données contenues dans l'élément CipherData.
   1. Si un sous-élément CipherValue est présent, alors la valeur de texte associée est ramenée et décodée en base64, de façon à obtenir la séquence d'octets cryptée ;
   2. Si un sous-élément CipherReference est présent, on utilise l'adresse URI et les transformations (le cas échéant) pour ramener la séquence d'octets cryptée ;
   3. La séquence d'octets cryptée est décryptée en utilisant les algorithme, paramètres et valeur de clé déjà déterminés à partir des étapes 1 et 2.
4. Traiter les données décryptées de Type "element" ou "content".
   1. La séquence d'octets en texte clair obtenue dans l'étape 3 est interprétée comme des données textuelles codées en UTF-8 ;
   2. Le décrypteur DOIT être capable de retourner la valeur de l'attribut Type et les données textuelles codées en UTF-8. Le décrypteur N'EST PAS OBLIGÉ d'effectuer une validation du code XML sérialisé ;
   3. Le décrypteur DEVRAIT gérer la faculté de remplacer l'élément EncryptedData par le "element" ou le "content" décryptés, représentés par les caractères codés en UTF-8. Le décrypteur N'EST PAS OBLIGÉ d'effectuer une validation du résultat de cette opération de remplacement.

      L'application fournit le contexte du document XML et identifie l'élément EncryptedData qui est remplacé. Si le document dans lequel le remplacement survient n'est pas codé en UTF-8, le décrypteur DOIT transcoder les caractères codés en UTF-8 dans le codage de la cible.

5. Traiter les données décryptées si l'attribut Type n'est pas spécifié ou si sa valeur n'est pas "element" ou "content".
   1. La séquence d'octets en texte clair obtenue dans l'étape 3 DOIT être retournée à l'application pour un traitement supplémentaire, en même temps que les valeurs des attributs Type, MimeType et Encoding quand elles sont spécifiées. Les attributs MimeType et Encoding sont consultatif. La valeur de l'attribut Type est normative, puisqu'elle peut contenir des informations nécessaires au traitement ou à l'interprétation des données par l'application ;
   2. Remarquer que cette étape comprend le traitement des données décryptées provenant d'un élément EncryptedKey. La séquence d'octets en texte clair représente une valeur de clé qui est utilisée par l'application pour décrypter un ou plusieurs autres éléments EncryptedType.

4.3 Le chiffrement de XML

Les opérations de chiffrement et de décryptage sont effectuées sur des octets. L'application est responsable de la mise en ordre XML de sorte que celui-ci puisse être sérialisé en une séquence d'octets, crypté, décrypté et mis à la disposition du destinataire.

Par exemple, si l'application souhaite canoniser ses données ou coder/compresser les données dans un format d'emballage XML, elle aura besoin de mettre en ordre le XML en ce sens et d'identifier le type résultant via l'attribut Type de l'élément EncryptedData. La probabilité de réussite du décryptage et du traitement qui s'ensuit va dépendre de la gestion ou non du type donné par le destinataire. Également, si les données sont destinées à un traitement à la fois avant le chiffrement et après le décryptage (par exemple, une validation XML Signature [XML-DSIG] ou une transformation XSLT), l'application de chiffrement doit prendre soin de préserver les informations nécessaires pour le succès de l'opération.

Pour des raisons d'interopérabilité, les types suivants DOIVENT être implémentés, de sorte qu'une implémentation soit capable de recevoir en entrée et de produire en sortie des données qui correspondent aux règles de production 39 et 43 de [XML] :

element 'http://www.w3.org/2001/04/xmlenc#Element'

"[39] element  ::= EmptyElemTag | STag content ETag"

content 'http://www.w3.org/2001/04/xmlenc#Content'

"[43] content  ::= CharData? ((element | Reference | CDSect | PI | Comment) CharData?)*"

Les sections suivantes contiennent des spécifications pour le décryptage, le remplacement et la sérialisation d'un contenu XML (c'est-à-dire, de Type "element" ou "content"), en suivant le modèle de données [XPath]. Ces sections ne sont pas normatives et sont OPTIONNELLES pour l'implémentation de cette spécification, mais celles-ci peuvent être données en référence normativement et être OBLIGATOIRES pour d'autres spécifications qui demandent un traitement cohérent aux applications, telle que [XML-DSIG-Decrypt].

4.3.1 Une implémentation de décryptage (non normatif)

Soit P le contexte selon lequel le XML sérialisé devrait être analysé (un nœud de document ou un nœud d'élément) et O la séquence d'octets représentant les caractères codés en UTF-8 résultant de l'étape 4.3 dans Le traitement du décryptage (section 4.2). Y est l'ensemble de nœuds représentant le contenu décrypté obtenu au cours des étapes suivantes :

1. Soit C le contexte d'analyse d'un sous-élément de P, lequel contexte consiste des items suivants :
   • Le préfixe et le nom de l'espace de nommage de chaque espace de nommage qui se trouve dans la portée de P ;
   • Le nom et la valeur de chaque entité générale qui est effective pour le document XML causant P.
2. Emballer le flux d'octets décrypté O dans le contexte C, comme spécifié dans L'emballage du texte ;
3. Analyser le flux d'octets emballé, comme décrit dans Le modèle de traitement des références (section 4.3.3.2) de [XML-Signature], qui aboutit à un ensemble de nœuds ;
4. Y est l'ensemble de nœuds obtenu après avoir retiré le nœud racine, le nœud de l'élément enveloppant et son jeu d'attributs associé, et les nœuds des espaces de nommage de l'ensemble de nœuds issu de l'étape 3.

4.3.2 Une implémentation de décryptage et de remplacement (non normatif)

Soit X l'ensemble de nœuds [XPath] correspondant à un document XML et soit e le nœud d'un élément EncryptedData dans X.

1. Z est un ensemble de nœuds [XPath], identique à X sauf que e est un type d'élément EncryptedData. Auquel cas :
   1. Décrypter e dans le contexte de son nœud parent, comme spécifié dans Une implémentation de décryptage (section 4.3.1), qui produit Y un ensemble de nœuds [XPath] ;
   2. Inclure Y à la place de e et ses descendants dans X. Étant donné que [XPath] ne définit pas de méthode de remplacement des ensembles de nœuds issus de documents différents, le résultat DOIT être équivalent au remplacement de e par le flux d'octets, qui résulte de son décryptage dans la forme sérialisée de X, et à l'analyse à nouveau du document. Cependant, la méthode effective pour réaliser cette opération est laissée à l'implémenteur.

4.3.3 La sérialisation de XML (non normatif)

Considérations sur l'espace de nommage par défaut

Dans Le chiffrement de XML (section 4.1, étape 3.1), lorsqu'on sérialise un fragment XML, on DEVRAIT prendre un soin particulier par rapport aux espaces de nommage par défaut. Quand les données seront décryptées par la suite dans le contexte d'un document XML parent, alors la sérialisation peut produire des éléments dans un espace de nommage erroné. Considérons le fragment XML suivant :

  <Document xmlns="http://example.com/">
    <ObjetaCrypter xmlns="" />
  </Document>

La sérialisation du fragment élément ObjetaCrypter via [XML-C14N] aboutirait aux caractères "<ObjetaCrypter></ObjetaCrypter>" en tant que flux d'octets. Le document résultant crypté serait :

  <Document xmlns="http://example.com/">
    <EncryptedData xmlns="...">
      <!-- Contenant l'objet crypté 
           "<ObjetaCrypter></ObjetaCrypter>" -->
    </EncryptedData>
  </Document>

Le décryptage et le remplacement de l'élément EncryptedData à l'intérieur de ce document produirait le résultat incorrect suivant :

  <Document xmlns="http://example.com/">
    <ObjetaCrypter/>
  </Document> 

Ce problème survient parce que la plupart des sérialisations XML supposent que les données sérialisées seront analysées directement dans un contexte sans déclaration d'espace de nommage par défaut. Par conséquent, elles ne répètent pas la déclaration de l'espace de nommage par défaut vide avec un attribut xmlns="". Cependant, si les données sérialisées sont analysées dans le contexte d'action d'une déclaration espace de nommage par défaut (par exemple, le contexte d'analyse dans Une implémentation de décryptage (section 4.3.1)), alors celle-ci peut affecter l'interprétation des données sérialisées.

Pour résoudre ce problème, un algorithme de canonisation PEUT être augmenté comme suit pour une utilisation en tant que sérialiseur de chiffrement XML :

• Une déclaration d'espace de nommage par défaut avec une valeur vide (c'est-à-dire, xmlns="") DEVRAIT être émise là où elle aurait été normalement supprimée par l'algorithme de canonisation.

Bien que le résultat puisse ne pas être dans une forme canonique exacte, ceci est sans risque puisque le flux d'octets résultant ne sera pas utilisé directement dans le calcul d'une valeur de signature [XML-Signature]. En reprenant l'exemple précédent avec notre nouvelle augmentation, l'élément ObjetaCrypter serait sérialisé comme suit :

<ObjetaCrypter xmlns=""></ObjetaCrypter>

Lors de son traitement dans le contexte du document parent, ce fragment sérialisé sera analysé et interprété correctement.

On peut appliquer cette augmentation rétroactivement à une implémentation de canonisation existante en canonisant chaque nœud apex et ses descendants, qui proviennent de l'ensemble de nœuds, en insérant xmlns="" aux points appropriés et en concaténant les flux d'octets résultants.

Considérations sur les attributs XML

Une vigilance similaire, sur la relation entre un fragment et le contexte dans lequel celui-ci s'insère, devrait être exercée vis-à-vis des attributs xml:base, xml:lang et xml:space, comme indiqué dans Considérations sur la sécurité de [XML-exc-C14N]. Par exemple :

  <Bongo href="exemple.xml"/>

si cet élément, tiré d'un certain contexte, est sérialisé sans attribut xml:base [XML-Base] et analysé dans le contexte de l'élément :

  <Baz xml:base="http://example.com/"/>

le résultat sera :

  <Baz xml:base="http://example.com/"><Bongo href="exemple.xml"/></Baz>

L'attribut href de l'élément Bongo est interprété ensuite comme étant "http://example.com/exemple.xml". Si ce n'est pas l'adresse URI correcte, l'élément Bongo devrait avoir été sérialisé avec son propre attribut xml:base.

Malheureusement, on ne peut pas faire cette recommandation, comme quoi une valeur vide doit être émise pour séparer l'espace de nommage par défaut du fragment du contexte dans lequel celui-ci est inséré, pour les attributs xml:base et xml:space. (L'erreur 41 de l'errata de la spécification XML 1.0, seconde édition précise qu'une valeur de chaîne vide pour l'attribut xml:lang est considérée comme si il n'y avait pas d'information disponible sur la langue, comme si xml:lang n'avait pas été spécifié). L'interprétation d'une valeur vide pour les attributs xml:base ou xml:space est indéfinie ou conserve la valeur contextuelle. Par conséquent, les applications DEVRAIENT vérifier (1) que les fragments à chiffrer ne dépendent pas d'attributs XML ou, (2) s'ils en dépendent et si le document résultant est destiné à être valide [XML], que la définition du fragment permet la présence des attributs et que les attributs ont des valeurs non vides.

4.3.4 L'emballage du texte (non normatif)

Cette section spécifie le processus de l'emballage du texte dans un contexte d'analyse donné. Ce processus se base sur la proposition de Richard Tobin [Tobin] pour la construction de l'ensemble d'informations [XML-Infoset] d'une entité externe.

Le processus est constitué des étapes suivantes :

1. Si le contexte d'analyse contient d'éventuelles entités générales, alors émettre une déclaration de type de document qui fournit les déclarations d'entités ;
2. Émettre la balise ouvrante de l'élément dummy avec les attributs de déclaration d'espace de nommage déclarant tous les espaces de nommage dans le contexte d'analyse ;
3. Émettre le texte ;
4. Émettre la balise fermante de l'élément dummy.

Dans les étapes ci-dessus, la déclaration de type de document et les balises de l'élément dummy DOIVENT être codées en UTF-8.

Considérons le document suivant, qui contient un élément EncryptedData :

<!DOCTYPE Document [
  <!ENTITY dsig "http://www.w3.org/2000/09/xmldsig#">
]>
<Document xmlns="http://example.com/">
  <foo:Body xmlns:foo="http://example.com/foo">
    <EncryptedData xmlns="http://www.w3.org/2001/04/xmlenc#"
                   Type="http://www.w3.org/2001/04/xmlenc#Element">
      ...
    </EncryptedData> 
  </foo:Body>
</Document>

Si l'élément EncryptedData est nourri et se décrypte dans le texte "<Un><foo:Deux/></Un>", alors la forme emballée est comme suit :

<!DOCTYPE dummy [
  <!ENTITY dsig "http://www.w3.org/2000/09/xmldsig#">
]>
<dummy xmlns="http://example.com/"
       xmlns:foo="http://example.com/foo"><Un><foo:Deux/></Un></dummy>

5. Les algorithmes

Cette section présente les algorithmes utilisés avec la spécification XML Encryption. Les entrées contiennent l'identificateur à utiliser comme valeur de l'attribut Algorithm de l'élément EncryptionMethod ou d'un autre élément représentant le rôle de l'algorithme, une référence vers la spécification formelle, des définitions pour la représentation des clés et pour les résultats des opérations cryptographique où cela s'applique, et des commentaires généraux sur l'applicabilité.

5.1 Les identificateurs des algorithmes et les obligations des implémentations

Tous les algorithmes listés ci-dessous ont des paramètres implicites qui dépendent de leur rôle. Par exemple, les données à chiffrer ou à décrypter, l'élément de mise à la clé et le sens de l'opération (chiffrement ou décryptage) des algorithmes de chiffrement. Tous les paramètres explicites supplémentaires d'un algorithme apparaissent comme éléments de contenu à l'intérieur de l'élément. Ces sous-éléments paramètres ont des noms d'élément descriptifs, souvent propres à l'algorithme, et DEVRAIENT se trouver dans le même espace de nommage que celui de la présente spécification XML Encryption, de la spécification XML Signature, ou dans un espace de nommage propre à l'algorithme. Comme exemple pour un tel paramètre explicite, ce pourrait être un ticket [NdT. nonce] (une quantité unique) passé à un algorithme d'agrément de clé.

Cette spécification définit un jeu d'algorithmes, leur adresse URI et les obligations des implémentations. Les niveaux d'exigence spécifiés, tels que OBLIGATOIRE ou OPTIONNEL, se rapportent à l'implémentation, non à l'utilisation. En outre, le mécanisme est extensible et on peut recourir à d'autres algorithmes.

Le tableau des algorithmes

Le tableau ci-dessous dresse la liste des catégories d'algorithmes. Dans chaque catégorie, on donne un nom court, le niveau d'exigence pour l'implémentation et une adresse URI d'identification pour chaque algorithme.

Chiffrement par blocs

1. OBLIGATOIRE : TRIPLEDES
   http://www.w3.org/2001/04/xmlenc#tripledes-cbc
2. OBLIGATOIRE : AES-128
   http://www.w3.org/2001/04/xmlenc#aes128-cbc
3. OBLIGATOIRE : AES-256
   http://www.w3.org/2001/04/xmlenc#aes256-cbc
4. OPTIONNEL : AES-192
   http://www.w3.org/2001/04/xmlenc#aes192-cbc

Chiffrement par flot

1. aucun
   On donne ci-dessous la syntaxe et les recommandations pour la gestion des algorithmes spécifiés par l'utilisateur ;

Transport de clé

1. OBLIGATOIRE : RSA-v1.5
   http://www.w3.org/2001/04/xmlenc#rsa-1_5
2. OBLIGATOIRE : RSA-OAEP
   http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p

Agrément de clé

1. OPTIONNEL : Diffie-Hellman
   http://www.w3.org/2001/04/xmlenc#dh

Enveloppe de clé symétrique

1. OBLIGATOIRE : TRIPLEDES KeyWrap
   http://www.w3.org/2001/04/xmlenc#kw-tripledes
2. OBLIGATOIRE : AES-128 KeyWrap
   http://www.w3.org/2001/04/xmlenc#kw-aes128
3. OBLIGATOIRE : AES-256 KeyWrap
   http://www.w3.org/2001/04/xmlenc#kw-aes256
4. OPTIONNEL : AES-192 KeyWrap
   http://www.w3.org/2001/04/xmlenc#kw-aes192

Empreinte numérique

1. OBLIGATOIRE : SHA1
   http://www.w3.org/2000/09/xmldsig#sha1
2. RECOMMANDÉ : SHA256
   http://www.w3.org/2001/04/xmlenc#sha256
3. OPTIONNEL : SHA512
   http://www.w3.org/2001/04/xmlenc#sha512
4. OPTIONNEL : RIPEMD-160
   http://www.w3.org/2001/04/xmlenc#ripemd160

Authentification de message

1. RECOMMANDÉ : Signature numérique XML
   http://www.w3.org/2000/09/xmldsig#

Canonisation

1. OPTIONNEL : XML canonique (sans les commentaires)
   http://www.w3.org/TR/2001/REC-xml-c14n-20010315
2. OPTIONNEL : XML canonique avec les commentaires
   http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments
3. OPTIONNEL : Canonisation XML exclusive (sans les commentaires)
   http://www.w3.org/2001/10/xml-exc-c14n#
4. OPTIONNEL : Canonisation XML exclusive avec les commentaires
   http://www.w3.org/2001/10/xml-exc-c14n#WithComments

Codage

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

5.2 Les algorithmes de chiffrement par blocs

Les algorithmes de chiffrement par blocs sont conçus pour le chiffrement et le décryptage des données dans des blocs d'octets multiples à taille fixe. Leur identificateur apparaît comme valeur de l'attribut Algorithm des éléments EncryptionMethod qui sont les sous-éléments des éléments EncryptedData.

Les algorithmes de chiffrement par blocs admettent, comme arguments implicites, les données à chiffrer ou à décrypter, l'élément de mise à la clé et le sens de l'opération. Pour tous ces algorithmes spécifiés ci-dessous, un vecteur d'initialisation (IV) est nécessaire ; celui-ci est codé avec le texte crypté. Pour les algorithmes de chiffrement par blocs spécifiés par l'utilisateur, le vecteur d'initialisation, le cas échéant, pourrait être spécifié comme étant avec les données cryptées, comme un élément de contenu d'algorithme, ou bien ailleurs.

Le vecteur d'initialisation est codé avec et avant le texte crypté pour les algorithmes ci-dessous, pour en faciliter la disponibilité auprès du code de décryptage et pour renforcer le fait de son association avec le texte crypté. Une bonne pratique cryptographique exige qu'un vecteur d'initialisation différent soit employé pour chaque chiffrement.

Le remplissage

Comme les données en cours de chiffrement sont constituées d'un nombre arbitraire d'octets, ils ne peuvent pas être un multiple de la taille du bloc. On résoud ce problème en remplissant le texte en clair jusqu'à atteindre la taille du bloc avant chiffrement et en le désemplissant après décryptage. L'algorithme de remplissage [NdT. padding] consiste à calculer le plus petit nombre d'octets non nul, soit N, qu'il faut adjoindre au texte en clair pour l'amener à un multiple de la taille du bloc. Nous supposerons que la taille du bloc est de B octets, de sorte que N se trouve dans un intervalle de 1 à B. Remplir en ajoutant N-1 octets de remplissage arbitraires et un octet final dont la valeur est N à la fin du texte en clair. Lors du décryptage, prendre juste le dernier octet et, après vérification de la validité de celui-ci, retirer autant d'octets à partir de la fin du texte crypté une fois celui-ci décrypté.

Par exemple, supposons une taille de bloc de 8 octets et le texte en clair 0x616263. Le texte en clair rempli serait alors 0x616263????????05, dans lequel les octets "??" peuvent avoir une valeur quelconque. De la même manière, le texte en clair 0x2122232425262728 serait rempli en 0x2122232425262728??????????????08.

5.2.1 Triple DES

Identificateur :

http://www.w3.org/2001/04/xmlenc#tripledes-cbc (OBLIGATOIRE)

L'algorithme ANSI X9.52 [TRIPLEDES] spécifie trois opérations FIPS 46-3 [DES] successives. Le TRIPLEDES de XML Encryption consiste en un chiffrement DES, un décryptage DES et un chiffrement DES, utilisés dans le mode de chiffrement à enchaînement des blocs (CBC) avec une clé de 192 bits et un vecteur d'initialisation (IV) de 64 bits. Des bits de la clé, les 64 premiers sont utilisés dans la première opération DES, les 64 suivants dans la deuxième opération DES et les 64 derniers dans la troisième opération DES.

Remarque : Chacun de ces 64 bits de clé contient 56 bits effectifs et 8 bits de parité. Ainsi, il n'y a que 168 bits opérationnels sur les 192 qui sont transportés pour une clé TRIPLEDES. (Selon les critères retenus pour l'analyse, on peut considérer la force effective de la clé comme étant de 112 bits (en raison du bornage dans les attaques sur la partie centrale) ou même moins).

Le texte crypté résultant est préfixé par le vecteur d'initialisation. S'il est compris dans la sortie XML, il est alors codé en base64. Voici un exemple avec un élément EncryptionMethod TRIPLEDES :

  <EncryptionMethod
   Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"/>

5.2.2 AES

Identificateur :

http://www.w3.org/2001/04/xmlenc#aes128-cbc (OBLIGATOIRE)

http://www.w3.org/2001/04/xmlenc#aes192-cbc (OPTIONNEL)

http://www.w3.org/2001/04/xmlenc#aes256-cbc (OBLIGATOIRE)

L'algorithme [AES] est utilisé dans le mode de chiffrement à enchaînement des blocs (CBC) avec un vecteur d'initialisation (IV) de 128 bits. Le texte crypté résultant est préfixé par le vecteur d'initialisation. S'il est compris dans la sortie XML, il est alors codé en base64. Voici un exemple avec un élément EncryptionMethod AES :

  <EncryptionMethod
   Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>

5.3 Les algorithmes de chiffrement par flot

Les algorithmes de chiffrement par flot simples génèrent, en fonction de la clé, un flux d'octets qui sont comparés en disjonction exclusive (XOR) avec les octets de données du texte en clair pour produire le texte crypté lors du chiffrement et avec les octets du texte crypté pour produire le texte en clair lors du décryptage. Ils sont normalement utilisés pour le chiffrement des données et sont spécifiés par la valeur de l'attribut Algorithm du sous-élément EncryptionMethod d'un élément EncryptedData.

REMARQUE : Il est capital que chaque clé d'un chiffrement par flot simple (ou clé et vecteur d'initialisation (IV), si un vecteur est également utilisé) ne soit utilisée qu'une fois. Si la même clé (ou clé et vecteur IV) devait être utilisée sur deux messages, alors, par comparaison en disjonction exclusive des deux textes cryptés, on peut obtenir la disjonction exclusive des deux textes en clair. Ceci est généralement très compromettant.

Aucun algorithme de chiffrement par flot spécifique n'est décrit ici, cette section ne fournit que des principes généraux.

Les algorithmes de chiffrement par flot emploient généralement le paramètre explicite optionnel KeySize. Pour les cas où la taille de la clé ne se déduit pas de l'adresse URI ou de la source de la clé de l'algorithme, comme pour les méthodes d'agrément de clé, ce paramètre règle la taille de la clé. Si la taille de la clé est apparente et contredit le paramètre KeySize, une erreur DOIT être renvoyée. L'implémentation d'un algorithme par flot est optionnelle. Le schéma du paramètre KeySize est le suivant :

  Définition de schéma :

  <simpleType name='KeySizeType'>
    <restriction base="integer"/>
  </simpleType>

5.4 Le transport des clés

Les algorithmes de transport de clé sont des algorithmes de chiffrement à clé publique conçus spécialement pour le chiffrement et le décryptage de clés. Leurs identificateurs apparaissent en attributs Algorithm des éléments EncryptionMethod qui sont les sous-éléments d'éléments EncryptedKey. L'élément EncryptedKey est à son tour le sous-élément d'un élément ds:KeyInfo. Le type de clé qui est transporté, c'est-à-dire l'algorithme dans lequel il est prévu d'utiliser la clé transportée, est donné par l'attribut Algorithm du sous-élément EncryptionMethod de l'élément EncryptedData, ou EncryptedKey, parent de cet élément ds:KeyInfo.

(Les algorithmes de transport de clé peuvent en option servir à chiffrer des données, auquel cas ils apparaissent directement comme attribut Algorithm du sous-élément EncryptionMethod d'un élément EncryptedData. Parce qu'ils utilisent directement des algorithmes à clé publique, les algorithmes de transport de clé ne sont pas efficaces pour le transport des quantités de données significativement plus grandes que des clés symétriques).

L'algorithme de transport RSA v1.5 donné ci-dessous est celui employé en conjonction avec TRIPLEDES et la syntaxe de message cryptographique (CMS) de S/MIME [CMS-Algorithms]. L'algorithme de transport de clé RSA v2 donné ci-dessous est celui utilisé en conjonction avec AES et CMS [AES-WRAP].

5.4.1 RSA Version 1.5

Identificateur :

http://www.w3.org/2001/04/xmlenc#rsa-1_5 (OBLIGATOIRE)

L'algorithme RSAES-PKCS1-v1_5, spécifié dans RFC2437 [PKCS1], n'admet aucun paramètre explicite. Voici un exemple avec un élément EncryptionMethod RSA Version 1.5 :

  <EncryptionMethod
   Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/>

La valeur de l'élément CipherValue d'une telle clé cryptée correspond au codage en base64 [MIME] de la chaîne d'octets calculée selon RFC2437 [PKCS1, section 7.2.1 : L'opération de chiffrement]. Comme spécifié dans la fonction EME-PKCS1-v1_5 de RFC2437 [PKCS1, section 9.1.2.1], la valeur d'entrée pour la fonction de transport de clé est comme suit :

   CRYPT ( PAD ( KEY ))

dans laquelle le remplissage a la forme particulière suivante :

   02 | PS* | 00 | key

où le caractère | représente une concaténation, "02" et "00" sont des octets fixes de la valeur hexadécimale correspondante, PS une chaîne d'octets forts pseudo-aléatoires [RANDOM] d'au moins huit octets de long, ne contenant aucun octet nul et suffisamment longue pour que la valeur de la quantité qui est CRYPTée soit un octet plus courte que le module RSA, et key la clé qui est transportée. La clé fait 192 bits pour TRIPLEDES et 128, 192 ou 256 bits pour AES. La gestion de cet algorithme de transport de clé pour transporter des clés de 192 bits est OBLIGATOIRE à implémenter. La gestion de cet algorithme pour transporter d'autres clés est OPTIONNELLE. L'algorithme RSA-OAEP est RECOMMANDÉ pour le transport des clés AES.

La chaîne résultante en base64 [MIME] est la valeur du nœud de texte sous-élément de l'élément CipherData, par exemple :

  <CipherData> IWijxQjUrcXBYoCei4QxjWo9Kg8D3p9tlWoT4
     t0/gyTE96639In0FZFY2/rvP+/bMJ01EArmKZsR5VW3rwoPxw=
  </CipherData>

errata E01

5.4.2 RSA-OAEP

Identificateur :

http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p (OBLIGATOIRE)

L'algorithme RSAES-OAEP-ENCRYPT, comme spécifié dans RFC2437 [PKCS1], admet trois paramètres. Deux paramètres sont spécifiés par l'utilisateur : une fonction de hachage cryptographique [NdT. message digest function] OBLIGATOIRE et un flux d'octets de codage OAEPparams OPTIONNEL. La fonction de hachage cryptographique est spécifiée par l'attribut Algorithm d'un sous-élément ds:DigestMethod et la fonction de génération de masques, le troisième paramètre, est toujours MGF1 avec SHA1 (mgf1SHA1Identifier). Les fonctions de hachage cryptographique et de génération de masques sont toutes deux employées dans l'opération EME-OAEP-ENCODE comme partie de RSAES-OAEP-ENCRYPT. La chaîne d'octets de codage est le décodage en base64 du contenu d'un sous-élément OAEPparams optionnel. Si aucun sous-élément OAEPparams n'est fourni, une chaîne nulle sera utilisée.

Définition de schéma :
     <!-- utiliser ces types d'éléments comme sous-éléments
       de EncryptionMethod quand ils sont utilisés avec RSA-OAEP -->
     <element name='OAEPparams' minOccurs='0' type='base64Binary'/>
     <element ref='ds:DigestMethod' minOccurs='0'/>

Voici un exemple d'élément RSA-OAEP :

  <EncryptionMethod
     Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p">
    <OAEPparams> 9lWu3Q== </OAEPparams>
    <ds:DigestMethod
        Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
  <EncryptionMethod>

La valeur de l'élément CipherValue d'une clé cryptée RSA-OAEP correspond au codage en base64 [MIME] de la chaîne d'octets calculée selon RFC2437 [PKCS1, section 7.1.1 : L'opération de chiffrement]. Comme décrit dans la fonction EME-OAEP-ENCODE de RFC2437 [PKCS1, section 9.1.1.1], la valeur d'entrée pour la fonction de transport de clé est calculée en utilisant la fonction de hachage cryptographique et la chaîne, spécifiées par les éléments DigestMethod et OAEPparams, et en utilisant la fonction de génération de masques MGF1 (avec SHA1), spécifiée dans RFC2437. La longueur en sortie voulue pour EME-OAEP-ENCODE est d'un octet plus courte que le module RSA.

La taille de la clé transportée est de 192 bits pour TRIPLEDES et de 128, 192 ou 256 bits pour AES. Les implémentations DOIVENT implémenter RSA-OAEP pour le transport des clés de 128 et 256 bits. Elles PEUVENT implémenter RSA-OAEP pour le transport d'autres clés.

5.5 L'agrément des clés

Un algorithme d'agrément de clé pourvoit une clé secrète partagée, basée sur un secret partagé, qui est calculée à partir de certains types de clés publiques compatibles issues à la fois de l'émetteur et du destinataire. L'information provenant du donneur d'ordre pour déterminer le secret est indiquée par un sous-élément paramètre OriginatorKeyInfo optionnel d'un élément AgreementMethod, alors que celle associée au destinataire est indiquée par un élément RecipientKeyInfo optionnel. Une clé partagée est dérivée de ce secret partagé selon une méthode déterminée par l'algorithme d'agrément de clé.

Remarque : XML Encryption ne pourvoit pas de protocole de négociation pour l'agrément de clé en ligne. Le donneur d'ordre peut utiliser l'élément AgreementMethod pour identifier les clés et la procédure de calcul qui ont été employées pour obtenir la clé de chiffrement partagée. La méthode utilisée pour obtenir ou sélectionner les clés ou l'algorithme employés pour le calcul d'agrément est hors de l'objet de cette spécification.

L'élément AgreementMethod apparaît comme contenu d'un élément ds:KeyInfo car, comme tous les sous-éléments de ds:KeyInfo, il produit une clé. Cet élément ds:KeyInfo est lui-même le sous-élément d'un élément EncryptedData, ou EncryptedKey. L'attribut Algorithm et le sous-élément KeySize de l'élément EncryptionMethod sous cet élément EncryptedData, ou EncryptedKey, sont des paramètres implicites pour le calcul de l'agrément de clé. Pour les cas où l'adresse URI de l'algorithme de cet élément EncryptionMethod est insuffisante pour déterminer la longueur de la clé, un KeySize DOIT avoir été inclus. De surcroît, l'émetteur peut placer un élément KA-Nonce sous l'élément AgreementMethod pour garantir qu'un élément de mise à la clé différent soit généré, même pour des agréments répétés où interviennent les mêmes clés publiques de l'émetteur et du destinataire. Par exemple :

 <EncryptedData>
   <EncryptionMethod Algorithm="Exemple:Block/Alg"
     <KeySize>80</KeySize>
   </EncryptionMethod>
   <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
     <AgreementMethod Algorithm="exemple:Agrement/Algorithme">
       <KA-Nonce>Zm9v</KA-Nonce>
       <ds:DigestMethod
       Algorithm="http://www.w3.org/2001/04/xmlenc#sha1"/>
      <OriginatorKeyInfo>
         <ds:KeyValue>....</ds:KeyValue>
       </OriginatorKeyInfo>
       <RecipientKeyInfo>
         <ds:KeyValue>....</ds:KeyValue>
       </RecipientKeyInfo> 
     </AgreementMethod>
   </ds:KeyInfo>
   <CipherData>...</CipherData>
</EncryptedData>

Si la clé agréée est utilisée pour envelopper une clé plutôt que des données, comme ci-dessus, alors l'élément AgreementMethod apparaîtrait à l'intérieur d'un élément ds:KeyInfo dans un élément EncryptedKey.

Le schéma de l'élément AgreementMethod est comme suit :

  Définition de schéma :

  <element name="AgreementMethod" type="xenc:AgreementMethodType"/>
  <complexType name="AgreementMethodType" mixed="true">
    <sequence>
      <element name="KA-Nonce" minOccurs="0" type="base64Binary"/>
      <!-- <element ref="ds:DigestMethod" minOccurs="0"/> -->
      <any namespace="##other" minOccurs="0" maxOccurs="unbounded"/>
      <element name="OriginatorKeyInfo" minOccurs="0" 
               type="ds:KeyInfoType"/>
      <element name="RecipientKeyInfo" minOccurs="0" 
               type="ds:KeyInfoType"/>
    </sequence>
    <attribute name="Algorithm" type="anyURI" use="required"/>
  </complexType>

5.5.1 Les valeurs des clés Diffie-Hellman

Identificateur :

http://www.w3.org/2001/04/xmlenc#DHKeyValue (OPTIONNEL)

Les clés Diffie-Hellman (DH) peuvent apparaître directement dans les éléments KeyValue ou être obtenues par les rapports des éléments ds:RetrievalMethod, tout comme apparaître dans des certificats ou des objets du même genre. L'identificateur ci-dessous peut s'utiliser comme valeur de l'attribut Type des éléments Reference ou ds:RetrievalMethod.

Comme spécifié dans [ESDH], une clé publique DH comprend jusqu'à six quantités, deux grands nombres premiers p et q, un générateur g, la clé publique et les paramètres de validation "seed" et "pgenCounter". Ces quantités sont reliées comme suit : la clé publique = ( g**x mod p ), où x est la clé privée correspondante ; p = j*q + 1, où j >= 2. Les paramètres "seed" et "pgenCounter" sont optionnels et peuvent servir à déterminer si la clé Diffie-Hellman a été générée conformément à l'algorithme spécifié dans [ESDH]. Comme les entiers et le générateur peuvent être partagés en toute sécurité par de nombreuses clés DH, ils peuvent être connus de l'environnement de l'application et sont optionnels. Le schéma d'un élément DHKeyValue est le suivant :

   Définiton de schéma :

  <element name="DHKeyValue" type="xenc:DHKeyValueType"/>
  <complexType name="DHKeyValueType">
     <sequence>
        <sequence minOccurs="0">
           <element name="P" type="ds:CryptoBinary"/>
           <element name="Q" type="ds:CryptoBinary"/>
           <element name="Generator"type="ds:CryptoBinary"/>
        </sequence>
        <element name="Public" type="ds:CryptoBinary"/>
        <sequence minOccurs="0">
           <element name="seed" type="ds:CryptoBinary"/>
           <element name="pgenCounter" type="ds:CryptoBinary"/>
        </sequence>
     </sequence>
  </complexType>

5.5.2 L'agrément des clés Diffie-Hellman

Identificateur :

http://www.w3.org/2001/04/xmlenc#dh (OPTIONNEL)

Le protocole d'agrément des clé Diffie-Hellman (DH) [ESDH] implique la dérivation d'une information secrète partagée, basée sur les clés DH compatibles de l'émetteur et du destinataire. Deux clés publiques DH sont compatibles si elles ont les mêmes nombres premiers et générateur. Si, pour la seconde, Y = g**y mod p, alors les deux parties peuvent calculer le secret partagé ZZ = ( g**(x*y) mod p ), bien que chaque partie ne connaisse que sa propre clé privée et la clé publique de l'autre. Les octets à zéro de tête DOIVENT être conservés dans ZZ, qui ainsi aura la même longueur en octets que p. La taille de p DOIT être d'au moins 512 bits et celle de g d'au moins 160 bits. De nombreuses autres considérations complexes concernant la sécurité interviennent dans le choix de g, p et du nombre aléatoire x, comme décrit dans [ESDH].

L'implémentation de l'agrément de clé Diffie-Hellman est optionnelle. Voici un exemple d'élément AgreementMethod DH comme suit :

  <AgreementMethod
      Algorithm="http://www.w3.org/2001/04/xmlenc#dh"
      ds:xmlns="http://www.w3.org/2000/09/xmldsig#">
    <KA-Nonce>Zm9v</KA-Nonce>
    <ds:DigestMethod
     Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
    <OriginatorKeyInfo>
      <ds:X509Data><ds:X509Certificate>
        ...
      </ds:X509Certificate></ds:X509Data>
    </OriginatorKeyInfo>
    <RecipientKeyInfo><ds:KeyValue>
      ...
    </ds:KeyValue></RecipientKeyInfo>
  </AgreementMethod>

Supposons que le secret partagé Diffie-Hellman soit la séquence d'octets ZZ. L'élément de mis à la clé partagé nécessaire sera alors calculé comme suit :

  Keying Material = KM(1) | KM(2) | ...

dans lequel | représente une concaténation de flux d'octets,

  KM(counter) = DigestAlg ( ZZ | counter | EncryptionAlg |
                KA-Nonce | KeySize )

DigestAlg

L'algorithme de hachage cryptographique spécifié par le sous-élément DigestMethod de l'élément AgreementMethod.

EncryptionAlg

L'adresse URI de l'algorithme de chiffrement, y compris les éventuels algorithmes d'enveloppe de clé, dans lequel l'élément de mise à la clé dérivé doit être utilisé ("Example:Block/Alg" dans l'exemple ci-dessus), et non l'adresse URI de l'algorithme d'agrément. C'est la valeur de l'attribut Algorithm du sous-élément EncryptionMethod du grand-parent EncryptedData, ou EncryptedKey de l'élément AgreementMethod.

KA-Nonce

Le décodage en base64 du contenu du sous-élément KA-Nonce de l'élément AgreementMethod, s'il est présent. Si l'élément KA-Nonce est absent, il est nul.

Counter

Un compteur d'un octet, commençant à un et s'incrémentant d'une unité. Il s'exprime par deux chiffres hexadécimaux, où les lettres A à F sont en capitales.

KeySize

La taille de la clé en bits de la clé, à dériver du secret partagé, comme chaîne en UTF-8 de l'entier décimal correspondant, avec seulement des chiffres dans la chaîne et sans zéros de tête. Pour certains algorithmes, la taille de la clé est inhérente à l'adresse URI. Pour d'autres, comme pour la plupart des chiffrements par flot, elle doit être fournie explicitement.

Par exemple, le calcul initial de (KM(1)) pour l'élément EncryptionMethod de l'exemple de L'agrément des clés (section 5.5) serait le suivant, dans lequel la valeur de l'octet binaire du compteur de 1 est représentée par la séquence de deux caractères UTF-8 01, ZZ est le secret partagé et "foo" le décodage en base64 de "Zm9v".

  SHA-1 ( ZZ01Example:Block/Algfoo80 )

En supposant que ZZ soit de 0xDEADBEEF, ce serait :

  SHA-1( 0xDEADBEEF30314578616D706C653A426C6F636B2F416C67666F6F3830 )

dont la valeur est :

  0x534C9B8C4ABDCB50038B42015A181711068B08C1

Chaque application de DigestAlg pour les valeurs successives de Counter vont produire un certain nombre d'octets supplémentaires d'élément de mise à la clé. À partir de la chaîne concaténée formée d'un ou plusieurs KM, un nombre suffisant d'octets de tête sont pris pour correspondre au besoin d'une clé réelle et le reste est écarté. Par exemple, si DigestAlg représente l'algorithme SHA-1, qui produit 20 octets de hachage, alors pour une clé 128 bits AES, les 16 premiers octets de KM(1) serait pris et les 4 octets restants écartés. Pour une clé 256 bit AES, tout KM(1) suffixé par les 12 premiers octets de KM(2) serait pris et les 8 octets restants de KM(2) écartés.

5.6 L'emballage des clés symétriques

Les algorithmes d'emballage de clés symétriques sont des algorithmes de chiffrement à clé secrète partagée conçus spécialement pour le chiffrement et le décryptage des clés symétriques. Leurs identificateurs apparaissent comme valeurs de l'attribut Algorithm des sous-éléments EncryptionMethod d'un élément EncryptedKey, lui-même sous-élément d'un élément ds:KeyInfo à son tour le sous-élément d'un élément EncryptedData, ou autrement d'un élément EncryptedKey. Le type de la clé qui est emballée est indiqué par l'attribut Algorithm de l'élément EncryptionMethod, sous-élément du parent du grand-parent ds:KeyInfo de l'élément EncryptionMethod qui spécifie l'algorithme d'emballage de la clé symétrique.

5.6.1 La somme de contrôle de clé CMS

Certains algorithmes d'emballage de clés utilise une somme de contrôle de la clé, comme définie dans CMS [CMS-Wrap]. L'algorithme qui fournit une valeur de contrôle d'intégrité pour la clé qui est emballée est le suivant :

1. Calculer le hachage SHA-1 de 20 octets sur la clé qui est emballée ;
2. Utiliser les 8 premiers octets de ce hachage comme valeur de somme de contrôle.

5.6.2 L'emballage de clé Triple DES CMS

Identificateurs et obligations :

http://www.w3.org/2001/04/xmlenc#kw-tripledes (OBLIGATOIRE)

Les implémentations XML Encryption DOIVENT gérer l'emballage TRIPLEDES des clés de 168 bits et peuvent en option gérer l'emballage TRIPLEDES d'autres clés.

Voici l'exemple d'un élément EncryptionMethod avec un emballage de clé TRIPLEDES :

  <EncryptionMethod
   Algorithm="http://www.w3.org/2001/04/xmlenc#kw-tripledes"/>

L'algorithme suivant emballe (chiffre) une clé (la clé emballée WK) dans une clé de chiffrement de clé (KEK) TRIPLEDES, comme indiqué dans [CMS-Algorithms] :

1. Représenter la clé qui est emballée comme séquence d'octets. S'il s'agit d'une clé TRIPLEDES, c'est 24 octets (192 bits) avec un bit de parité impaire comme bit de fond de chaque octet ;
2. Calculer la somme de contrôle de clé CMS (section 5.6.1), notée CKS ;
3. Soit WKCKS = WK || CKS, où || est une concaténation ;
4. Générer 8 octets aléatoires [RANDOM], qu'on appelle IV ;
5. Chiffrer WKCKS en mode CBC, en utilisant KEK comme clé et IV comme vecteur d'initialisation. Appeler le résultat TEMP1 ;
6. Soit TEMP2 = IV || TEMP1 ;
7. Inverser l'ordre des octets de TEMP2 et appeler le résultat TEMP3 ;
8. Chiffrer TEMP3 en mode CBC, en utilisant la clé de chiffrement de clé KEK et le vecteur d'initialisation de 0x4adda22c79e82105. Le texte crypté obtenu correspond au résultat voulu. Il fait 40 octets de long quand une clé de 168 bits est emballée.

L'algorithme suivant déballe (décrypte) une clé, comme adopté de [CMS-Algorithms] :

1. Vérifier si la longueur du texte crypté est raisonnable par rapport au type de la clé. Elle doit faire 40 octets pour une clé de 168 bits, et 32, 40 ou 48 octets pour des clés de 128, 192 ou 256 bits respectivement. Si la longueur n'est pas reconnue ou est incohérente pour l'algorithme auquel la clé est destinée, renvoyer une erreur ;
2. Décrypter le texte crypté avec TRIPLEDES en mode CBC, en utilisant la clé de chiffrement de clé KEK et un vecteur d'initialisation (IV) de 0x4adda22c79e82105. Appeler la sortie TEMP3 ;
3. Inverser l'ordre des octets de TEMP3 et appeler le résultat TEMP2 ;
4. Décomposer TEMP2 en IV, les 8 premiers octets, et en TEMP1, les octets restants ;
5. Décrypter TEMP1, en utilisant TRIPLEDES en mode CBC, à l'aide de la clé de chiffrement de clé KEK et du vecteur d'initialisation IV obtenus à l'étape précédente. Appeler le résultat WKCKS ;
6. Décomposer WKCKS. Les 8 derniers octets sont la somme de contrôle de la clé CKS et les octets avant CKS représentent WK, la clé emballée ;
7. Calculer une somme de contrôle de clé CMS (section 5.6.1) sur WK et la comparer avec la somme de contrôle CKS extraite dans l'étape précédente. Si elles ne sont pas égales, renvoyer une erreur ;
8. WK est la clé emballée, maintenant extraite pour le décryptage des données.

5.6.3 L'emballage de clé AES

Identificateurs et obligations :

http://www.w3.org/2001/04/xmlenc#kw-aes128 (OBLIGATOIRE)

http://www.w3.org/2001/04/xmlenc#kw-aes192 (OPTIONNEL)

http://www.w3.org/2001/04/xmlenc#kw-aes256 (OBLIGATOIRE)

On décrit ci-dessous une implémentation d'emballage de clé AES, telle que suggérée par le NIST. Celle-ci offre confidentialité et intégrité. Cet algorithme n'est défini que pour des entrées qui sont un multiple de 64 bits. L'information emballée ne doit pas en fait forcément être une clé. L'algorithme est le même, quelle que soit la taille de la clé AES employée pour l'emballage, appelée clé de chiffrement de clé ou KEK. Les obligations de l'implémentation sont indiquées ci-dessous.

Clé de chiffrement de clé AES 128 bits

Implémentation des clés d'emballage de 128 bits OBLIGATOIRE.
Emballage d'autres tailles de clé OPTIONNEL.

Clé de chiffrement de clé AES 192 bits

Toute autre gestion OPTIONNELLE.

Clé de chiffrement de clé AES 256 bits

Implémentation des clés d'emballage de 256 bits OBLIGATOIRE.
Emballage d'autres tailles de clé OPTIONNEL.

Supposons que les données à emballer consistent en N blocs de données de 64 bits, notés P(1), P(2), P(3) ... P(N). Le résultat de l'emballage sera N+1 blocs de 64 bits, notés C(0), C(1), C(2), ... C(N). La clé de chiffrement de clé est représentée par K. Posons les entiers i, j et t, et le registre intermédiaire de 64 bits A, le registre intermédiaire de 128 bits B et le tableau intermédiaire de quantités de 64 bits R(1) jusqu'à R(N).

Le caractère | représente une concaténation de sorte que x|y, où x et y et les quantités de 64 bits, soit la quantité de 128 bits avec x parmi les bits les plus significatifs et y parmi les moins significatifs. AES(K)enc(x) est l'opération AES de chiffrement de la quantité de 128 bits x par la clé K. AES(K)dec(x) est l'opération de décryptage correspondante. XOR(x,y) est la disjonction exclusive au niveau bit de x et y. MSB(x) et LSB(y) sont les 64 bits les plus significatifs et les moins significatifs de x et y respectivement.

Si N vaut 1, une seule opération AES est effectuée pour l'emballage et le déballage. Si N>1, alors 6*N opérations AES sont effectuées pour emballer et déballer.

L'algorithme d'emballage de clé est le suivant :

1. Si N vaut 1 :
   • B=AES(K)enc(0xA6A6A6A6A6A6A6A6|P(1))
   • C(0)=MSB(B)
   • C(1)=LSB(B)
   Si N>1, réaliser les étapes suivantes :
2. Initialiser les variables :
   • Mettre A à 0xA6A6A6A6A6A6A6A6
   • Pour i=1 à N,
     R(i)=P(i)
3. Calculer les valeurs intermédiaires :
   • Pour j=0 à 5,
     • Pour i=1 à N,
       t= i + j*N
B=AES(K)enc(A|R(i))
A=XOR(t,MSB(B))
R(i)=LSB(B)
4. Renvoyer les résultats :
   • Mettre C(0)=A
   • Pour i=1 à N,
     C(i)=R(i)

L'algorithme de déballage de clé est le suivant :

1. Si N vaut 1 :
   • B=AES(K)dec(C(0)|C(1))
   • P(1)=LSB(B)
   • Si MSB(B) vaut 0xA6A6A6A6A6A6A6A6, c'est réussi. Sinon, renvoyer une erreur pour échec du test d'intégrité.
   Si N>1, réaliser les étapes suivantes :
2. Initialiser les variables :
   • A=C(0)
   • Pour i=1 à N,
     R(i)=C(i)
3. Calculer les valeurs intermédiaires :
   • Pour j=5 à 0,
     • Pour i=N à 1,
       t= i + j*N
B=AES(K)dec(XOR(t,A)|R(i))
A=MSB(B)
R(i)=LSB(B)
4. Sortir les résultats :
   • Pour i=1 à N,
     P(i)=R(i)
   • Si A vaut 0xA6A6A6A6A6A6A6A6, c'est réussi. Sinon, renvoyer une erreur pour échec du test d'intégrité.

Par exemple, l'emballage de ces données 0x00112233445566778899AABBCCDDEEFF par la clé de chiffrement de clé KEK 0x000102030405060708090A0B0C0D0E0F produit le texte crypté 0x1FA68B0A8112B447, 0xAEF34BD8FB5A7B82, 0x9D3E862371D2CFE5.

5.7 Les empreintes numériques

On peut utiliser des algorithmes de hachage cryptographique [NdT. message digest algorithm] dans l'élément AgreementMethod comme partie de la dérivation de la clé, dans un chiffrement RSA-OAEP comme fonction de hachage et en relation avec la méthode de code d'authentification de message HMAC, comme décrit dans la spécification [XML-DSIG]).

5.7.1 SHA1

Identificateur :

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

L'algorithme SHA-1 [SHA] n'admet aucun paramètre explicite. Voici un exemple d'élément DigestMethod avec SHA-1 :

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

Une empreinte numérique SHA-1 est une chaîne de 160 bits. Le contenu de l'élément DigestValue sera le codage en base64 de cette chaîne de bits, vue comme un flux d'octets de 20 octets. Par exemple, pour l'empreinte numérique suivante, issue de l'Annexe A de la norme SHA-1 :

   A9993E36 4706816A BA3E2571 7850C26C 9CD0D89D

La valeur de l'élément DigestValue serait :

   <DigestValue>qZk+NkcGgWq6PiVxeFDCbJzQ2J0=</DigestValue>

5.7.2 SHA256

Identificateur :

http://www.w3.org/2001/04/xmlenc#sha256 (RECOMMANDÉ)

L'algorithme SHA-256 [SHA] n'admet aucun paramètre explicite. Voici un exemple d'élément DigestMethod avec SHA-256 :

   <DigestMethod
    Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>

Une empreinte numérique SHA-256 est une chaîne de 256 bits. Le contenu de l'élément DigestValue devra être le codage en base64 de cette chaîne de bits, vue comme un flux d'octets de 32 octets.

5.7.3 SHA512

Identificateur :

http://www.w3.org/2001/04/xmlenc#sha512 (OPTIONNEL)

L'algorithme SHA-512 [SHA] n'admet aucun paramètre explicite. Voici un exemple d'élément DigestMethod avec SHA-512 :

   <DigestMethod
    Algorithm="http://www.w3.org/2001/04/xmlenc#sha512"/>

Une empreinte numérique SHA-512 est une chaîne de 512 bits. Le contenu de l'élément DigestValue devra être le codage en base64 de cette chaîne de bits, vue comme un flux d'octets de 64 octets.

5.7.4 RIPEMD-160

Identificateur :

http://www.w3.org/2001/04/xmlenc#ripemd160 (OPTIONNEL)

L'algorithme RIPEMD-160 [RIPEMD-160] n'admet aucun paramètre explicite. Voici un exemple d'élément DigestMethod avec RIPEMD-160 :

   <DigestMethod
    Algorithm="http://www.w3.org/2001/04/xmlenc#ripemd160"/>

Une empreinte numérique RIPEMD-160 est une chaîne de 160 bits. Le contenu de l'élément DigestValue sera le codage en base64 de cette chaîne de bits, vue comme un flux d'octets de 20 octets.

5.8 L'authentification des messages

Identificateur :

http://www.w3.org/2000/09/xmldsig# (RECOMMANDÉ)

L'implémentation de XML Signature [XML-DSIG] est OPTIONNELLE pour les applications XML Encryption. C'est la manière recommandée pour l'authentification basée sur une clé.

5.9 La canonisation

La canonisation de XML est une méthode pour sérialiser XML de manière cohérente en un flux d'octets si besoin était avant le chiffrement du code XML.

5.9.1 La canonisation inclusive

Identificateurs :

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

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

XML canonique [Canon] est une méthode de sérialisation XML qui inclut l'espace de nommage dans la portée et le contexte de l'attribut d'espace de nommage xml des ancêtres du code XML qui est sérialisé.

Si le code XML doit être chiffré puis décrypté ensuite dans un environnement différent et que l'on souhaite conserver les corrélations du préfixe d'espace de nommage et les valeurs des attributs dans l'espace de nommage "xml" de son environnement original, alors c'est la version XML canonique avec commentaires du code XML qui devrait être la sérialisation cryptée.

5.9.2 La canonisation exclusive

Identificateurs :

http://www.w3.org/2001/10/xml-exc-c14n# (OPTIONNEL)

http://www.w3.org/2001/10/xml-exc-c14n#WithComments (OPTIONNEL)

La canonisation XML exclusive [Exclusive] sérialise le code XML de sorte à inclure, dans le minimum pratique, la corrélation de préfixe d'espace de nommage et le contexte de l'attribut d'espace de nommage "xml" hérités des éléments ancêtres.

C'est la méthode recommandée par laquelle le contexte externe d'un fragment, qui a été signé puis chiffré, peut être modifié. Sinon, la validation de la signature sur le fragment peut échouer parce que la canonisation par validation de signature peut incorporer au fragment des espaces de nommage inutiles.

6 Considérations sur la sécurité

6.1 Les relations avec les signatures numériques XML

L'application consécutive d'un chiffrement et de signatures numériques sur des parties d'un document XML peuvent rendre difficiles le décryptage et la vérification de signature à suivre. En particulier, lors de la vérification d'une signature, il est nécessaire de savoir si la signature a été calculée sur la forme cryptée ou bien sur celle non cryptée des éléments.

Un problème différent mais d'importance se pose du fait de l'introduction de failles cryptographiques lorsqu'on combine des signatures numériques et un chiffrement sur un élément XML commun. Hal Finney a suggéré que le chiffrement de données signées numériquement, lorsque la signature numérique est laissée en clair, est susceptible de constituer une faille permettant les attaques par prédiction du texte en clair. Cette faille peut être corrigée en utilisant des hachages sécurisés et les tickets des textes traités.

Conformément au document des conditions requises [EncReq], l'interaction d'un chiffrement et d'une signature est du ressort de l'application et n'est pas traitée par cette spécification. Toutefois, nous faisons les recommandations suivantes :

1. Quand les données sont cryptées, tout hachage cryptographique ou toute signature de ces données devraient être cryptés. C'est une réponse au premier point selon lequel seules les signatures qui sont visibles peuvent être validées. Et cela permet également de limiter les risques contre les attaques par prédiction du texte en clair, même s'il est impossible d'identifier (ou même d'avoir connaissance de) toutes les signatures sur un tronçon de données particulier ;
2. Employer la transformation de signature décrypter-excepter [XML-DSIG-Decrypt]. Son principe est le suivant : lors du traitement de la transformation de signature, si on rencontre une transformation en décryptage, alors décrypter tous les contenus cryptés dans le document, sauf ceux exclus par un ensemble de références énuméré.

En outre, alors que les avertissements suivants concernent les déductions incorrectes de l'utilisateur sur l'authenticité de l'information cryptée, les applications devraient éviter que l'utilisateur se méprenne en annonçant clairement quelles informations sont intègres ou authentiques, confidentielles ou irréfutables, quand plusieurs processus (par exemple, signature et chiffrement) et plusieurs algorithmes (par exemple, symétrique et asymétrique) sont mis en œuvre :

1. Quand une enveloppe cryptée contient une signature, la signature ne protège pas forcément l'authenticité ou l'intégrité du texte crypté [Davis] ;
2. Alors que la signature sécurise un texte en clair, elle ne couvre que ce qui est signé, les destinataires ne doivent inférer ni l'intégrité ni l'authenticité des autres informations non signées (par exemple, les en-têtes) dans l'enveloppe cryptée, voir [XML-DSIG, 8.1.1 Seul ce qui est signé est sûr].

6.2 L'information révélée

Quand une clé symétrique est partagée par plusieurs destinataires, cette clé devrait seulement être utilisée pour les données destinées à l'ensemble des destinataires ; même si un destinataire n'est pas mené vers des informations destinées (exclusivement) à un autre dans la même clé symétrique, ces informations pourraient être découvertes et décryptées.

En outre, les concepteurs des applications devraient prendre garde de ne pas dévoiler d'informations, dans les paramètres ou dans les identificateurs des algorithmes (par exemple, une information dans une adresse URI), qui affaibliraient le chiffrement.

6.3 Les tickets et les vecteurs (ou valeurs) d'initialisation (IV)

Une caractéristique indésirable dans de nombreux algorithmes de chiffrement et/ou leur mode, c'est que le même texte en clair chiffré avec la même clé produit le même texte crypté. Sans surprises, cela induit diverses attaques qui sont contrecarrées en incluant des données arbitraires et non répétitives (par une clé donnée) dans le texte en clair avant chiffrement. Dans les modes de chiffrement à enchaînement des blocs, ces données sont les premières à être chiffrées, et c'est pourquoi on les appelle valeur ou vecteur d'initialisation (IV).

Les divers algorithmes et leurs modes ont des exigences différentes vis-à-vis des caractéristiques de ces informations (par exemple, le degré de hasard et le secret) qui affectent leurs fonctionnalités (par exemple, la confidentialité et l'intégrité) et leur résistance aux attaques.

Puisque les données XML sont redondantes (par exemple, les codages Unicode et la répétition des balises) et que les agresseurs peuvent connaître la structure des données (par exemple, les définitions de type de document et les schémas), les algorithmes de chiffrement doivent être mis en œuvre soigneusement et employés de même.

Pour le mode de chiffrement à enchaînement des blocs (CBC) employé par cette spécification, le vecteur d'initialisation ne doit pas être réutilisé pour chaque clé et devrait être aléatoire, mais ne doit pas forcément être secret. En outre, pour ce mode, un agresseur qui modifie le vecteur d'initialisation peut effectuer une modification connue dans le texte en clair après décryptage. Cette attaque peut être contrée en sécurisant l'intégrité des données en clair, par exemple en les signant.

6.4 Le déni de service

Cette spécification autorise un traitement récursif. Par exemple, le scénario suivant est possible : l'élément EncryptedKey A requiert que l'élément EncryptedKey B soit décrypté, qui lui-même requiert l'élément EncryptedKey A ! Ou encore, un agresseur pourrait soumettre un élément EncryptedData au décryptage, celui-ci appelant des ressources de réseau très grandes ou continuellement redirigées. Par conséquent, les implémentations devraient pouvoir fixer une limite à une récursion arbitraire ainsi que la quantité totale des traitements et des ressources en réseau qu'une requête peut consommer.

6.5 Le contenu non sécurisé

On peut employer XML Encryption pour dissimuler, via un chiffrement, un contenu que certaines application (par exemple, les pare-feux, les détecteurs de virus, etc.) considèrent non sûr. Ainsi, une telle application doit considérer un contenu crypté comme étant aussi peu sûr que le moins sûr des contenus transportés dans le contexte de l'application. Donc, une telle application peut choisir (1) d'interdire ce type de contenu, (2) d'exiger l'accès à la forme décryptée pour inspection ou (3) de garantir que le contenu arbitraire pourra être traité en toute sécurité par l'application réceptrice.

7 La conformité

Une implémentation est conforme à cette spécification, si elle génère avec succès une syntaxe en fonction des définitions du schéma et si elle satisfait à tous les niveaux d'exigence DOIT/OBLIGATOIRE/DEVRA, y compris la gestion et le traitement des algorithmes. Les obligations de traitement sont spécifiées pour les rôles du décrypteur, du chiffreur et de l'application qui les mobilise.

8 Le type de média XML Encryption

8.1 Introduction

La syntaxe et le traitement XML Encryption [XML-Encryption] spécifie une procédure pour le chiffrement des données et la représentation de ce résultat dans XML. Ces données peuvent être arbitraires (y compris un document XML), un élément XML ou un contenu XML. Le résultat du chiffrement des données est un élément XML Encryption qui contient ou référence les données cryptées.

Le type de média application/xenc+xml permet aux applications XML Encryption d'identifier des documents cryptés. De surcroît, il permet aux applications au fait de ce type de média (même si ce ne sont pas des implémentations XML Encryption) d'indiquer que le type de média de l'objet décrypté (l'original) pourrait être d'un type autre que XML.

8.2 L'enregistrement du type application/xenc+xml

C'est l'enregistrement d'un type de média, tel que défini dans les extensions de courrier internet multi-usages (MIME), quatrième partie : les procédures d'enregistrement [MIME-REG].

Nom du type de média MIME : application

Nom du sous-type MIME : xenc+xml

Paramètres requis : aucun

Paramètres optionnels : charset

Les valeurs admises et recommandées, ainsi que l'interprétation du paramètre de jeu de caractères sont identiques à celles données pour le type application/xml dans la section 3.2 de RFC3023 [XML-MT].

Considérations sur le codage :

Les considérations sur le codage sont identiques à celles données pour le type application/xml dans la section 3.2 de RFC3023 [XML-MT].

Considérations sur la sécurité :

Voir la section Les considérations sur la sécurité de [XML-Encryption].

Considérations sur l'interopérabilité : aucune

Spécification publiée : [XML-Encryption]

Applications qui utilisent ce type de média :

XML Encryption est indépendant de l'appareil, de la plate-forme et du vendeur ; il est reconnu par un certain ensemble d'applications Web.

Informations supplémentaires :

Nombre(s) magique(s) : aucun

Bien qu'on ne puisse pas compter sur des séquences d'octets pour identifier à coup sûr les documents XML Encryption, ce seront des documents XML dans lesquels la partie locale (LocalPart) du nom qualifié (QName) de l'élément racine sera EncryptedData ou EncryptedKey, avec le nom de l'espace de nommage associé http://www.w3.org/2001/04/xmlenc#. Le nom de type application/xenc+xml DOIT uniquement être employé pour les objets de données dans lesquels l'élément racine est issu de l'espace de nommage XML Encryption. On peut décrire les documents XML qui contiennent ce type d'élément ailleurs que dans l'élément racine à l'aide de facilités comme [XML-schema].

Extension(s) de fichier : .xml

Code(s) de type de fichier Macintosh : "TEXT"

Personnes à contacter pour des renseignements supplémentaires :

Joseph Reagle <reagle@w3.org>

XENC Working Group <xml-encryption@w3.org>

Utilisation prévue : COMMUNE

Auteur/gestionnaire des modifications :

La spécification XML Encryption est une production du World Wide Web Consortium (W3C), qui exerce le contrôle des modifications sur la spécification.

9 Le schéma et des exemples valides

Schéma

xenc-schema.xsd

errata E03

Exemple

enc-exemple.xml (qui n'est pas valide d'un point de vue cryptographique, mais qui démontre la plus grande partie du schéma)

10 Références

TRIPLEDES

ANSI X9.52: Triple Data Encryption Algorithm Modes of Operation. 1998.

AES

NIST FIPS 197: Advanced Encryption Standard (AES). Novembre 2001.

http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf

AES-WRAP

RFC3394: Advanced Encryption Standard (AES) Key Wrap Algorithm. J. Schaad et R. Housley. Informatif, septembre 2002.

CMS-Algorithms

RFC3370: Cryptographic Message Syntax (CMS) Algorithms. R. Housley. Informatif, février 2002.

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

CMS-Wrap

RFC3217: Triple-DES and RC2 Key Wrapping. R. Housley. Informatif, décembre 2001.

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

Davis

Defective Sign & Encrypt in S/MIME, PKCS#7, MOSS, PEM, PGP, and XML. D. Davis. USENIX Annual Technical Conference. 2001.

http://www.usenix.org/publications/library/proceedings/usenix01/davis.html

DES

NIST FIPS 46-3: Data Encryption Standard (DES). Octobre 1999.

http://csrc.nist.gov/publications/fips/fips46-3/fips46-3.pdf

EncReq

Les conditions requises pour le chiffrement XML. J. Reagle. Note du W3C, mars 2002.

http://www.w3.org/TR/2002/NOTE-xml-encryption-req-20020304

ESDH

RFC 2631: Diffie-Hellman Key Agreement Method. E. Rescorla. Standards Track, 1999.

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

http://www.w3.org/TR/2002/CR-xml-exc-c14n-20020212

Glossary

RFC 2828: Internet Security Glossary. R Shirey. Informatif, mai 2000.

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

HMAC

RFC 2104: HMAC: Keyed-Hashing for Message Authentication. H. Krawczyk, M. Bellare, R. Canetti. Informatif, février 1997.

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

HTTP

RFC 2616: Hypertext Transfer Protocol -- HTTP/1.1. J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach et T. Berners-Lee. Standards Track, juin 1999.

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

KEYWORDS

RFC 2119: Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. Best Current Practice, mars 1997.

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

MD5

RFC 1321: The MD5 Message-Digest Algorithm. R. Rivest. Informatif, avril 1992.

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

MIME

RFC 2045: Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies. N. Freed and N. Borenstein. Standards Track, novembre 1996.

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

MIME-REG

RFC 2048: Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures. N. Freed, J. Klensin et J. Postel. Best Current Practice, novembre 1996.

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

NFC

TR15, Unicode Normalization Forms. M. Davis et M. Dürst. Révision 18: novembre 1999.

http://www.unicode.org/unicode/reports/tr15/tr15-18.html.

NFC-Corrigendum

Corrigendum #2: Yod with Hiriq Normalization.

http://www.unicode.org/versions/corrigendum2.html.

prop1

XML Encryption strawman proposal.E. Simon et B. LaMacchia. août 2000.

http://lists.w3.org/Archives/Public/xml-encryption/2000Aug/0001.html

prop2

Another proposal of XML Encryption. T. Imamura. août 2000.

http://lists.w3.org/Archives/Public/xml-encryption/2000Aug/0005.html

prop3

XML Encryption Syntax and Processing. B. Dillaway, B. Fox, T. Imamura, B. LaMacchia, H. Maruyama, J. Schaad et E. Simon. Décembre 2000.

http://lists.w3.org/Archives/Public/xml-encryption/2000Dec/att-0024/01-XMLEncryption_v01.html

PKCS1

RFC 2437: PKCS #1: RSA Cryptography Specifications Version 2.0. B. Kaliski et J. Staddon. Informatif, Octobre 1998.

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

RANDOM

RFC 1750: Randomness Recommendations for Security. D. Eastlake, S. Crocker et J. Schiller. Informatif, Décembre 1994.

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

RIPEMD-160

CryptoBytes, Volume 3, Number 2. The Cryptographic Hash Function RIPEMD-160. RSA Laboratories. Automne 1997.

ftp://ftp.rsasecurity.com/pub/cryptobytes/crypto3n2.pdf

http://www.esat.kuleuven.ac.be/~cosicart/pdf/AB-9601/AB-9601.pdf

RIPEMD

Secure Hash Standard. NIST FIPS 180-1. (RFC 3174). Avril 1995.

http://www.itl.nist.gov/fipspubs/fip180-1.htm

Secure Hash Standard. NIST Draft FIPS 180-2. 2001. (Prolongé pour inclure SHA-384, SHA-256 et SHA-512)

http://csrc.nist.gov/encryption/shs/dfips-180-2.pdf

Tobin

R. Tobin. Infoset for external entities, XML Core mailing list, 2000 [Membres du W3C seulement].

http://lists.w3.org/Archives/Member/w3c-xml-core-wg/2000OctDec/0054

UTF-16

RFC 2781: UTF-16, an encoding of ISO 10646. P. Hoffman et F. Yergeau. Informatif, février 2000.

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

UTF-8

RFC 2279: UTF-8, a transformation format of ISO 10646F. F. Yergeau. Standards Track, janvier 1998.

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

URI

RFC 2396: Uniform Resource Identifiers (URI): Generic Syntax. T. Berners-Lee, R. Fielding et L. Masinter. Standards Track, août 1998.

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

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

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

RFC 2611: URN Namespace Definition Mechanisms. Best Current Practices. Daigle, D. van Gulik, R. Iannella, P. Falstrom. Juin 1999.

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

X509v3

ITU-T Recommendation X.509 version 3 (1997). "Information Technology - Open Systems Interconnection - The Directory Authentication Framework" ISO/IEC 9594-8:1997.

XML

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

XML-Base

XML Base. J. Marsh. Recommandation du W3C, juin 2001.

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

XML-C14N

XML canonique J. Boyer. Recommandation du W3C, mars 2001.

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

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

XML-exc-C14N

Canonisation XML exclusive. J. Boyer, D. Eastlake, and J. Reagle. Recommandation du W3C, juillet 2002.

http://www.w3.org/TR/2002/REC-xml-exc-c14n-20020718/

XML-DSIG

La syntaxe et le traitement XML Signature. D. Eastlake, J. Reagle et D. Solo. Recommandation du W3C, février 2002.

http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/

errata E02

XML-DSIG-Decrypt

La transformation de décryptage de XML Signature. M. Hughes, T. Imamura et H. Maruyama. Recommandation du W3C, Décembre 2002.

http://www.w3.org/TR/2002/REC-xmlenc-decrypt-20021210

XML-Encryption

La syntaxe et le traitement XML Encryption. D. Eastlake et J. Reagle. Recommandation candidate du W3C, décembre 2002.

http://www.w3.org/TR/2002/CR-xmlenc-core-20020802/

XML-Infoset

L'ensemble d'informations XML. J. Cowan et R. Tobin. Recommandation du W3C, octobre 2001

http://www.w3.org/TR/2001/REC-xml-infoset-20011024/

XML-MT

RFC 3023: XML Media Types. M. Murata, S. St. Laurent et D. Kohn. Informatif, janvier 2001.

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

XML-NS

Les espaces de nommage en XML. T. Bray, D. Hollander, and A. Layman. Recommandation du W3C, janvier 1999.

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

XML-schema

Les schémas XML (1ere partie) : les structures D. Beech, M. Maloney et N. Mendelsohn. Recommandation du W3C, mai 2001.

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

Les schémas XML (2eme partie) : les types de données. P. Biron et A. Malhotra. Recommandation du W3C, mai 2001.

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

XPath

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