Sintesi

Questo documento specifica un processo per crittografare i dati e rappresentare il risultato in XML. I dati potrebbero essere dati arbitrari (incluso un documento XML), un elemento XML o il contenuto di un elemento XML. Il risultato di crittografare i dati è un elemento di Crittografia XML il quale contiene o fa riferimento a dati cifrati.

Status di questo documento

Sommario

1. Introduzione
   1. Convenzioni Editoriali e di Conformità
   2. Filosofia di Progetto
   3. Versioni, Namespace, URI e Identificatori
   4. Riconoscimenti
2. Panoramica ed Esempi di Crittografia
   1. Granularità della Crittografia
      1. Crittografare un Elemento XML
      2. Crittografare il Contenuto dell'Elemento XML (gli Elementi)
      3. Crittografare il Contenuto dell'Elemento XML (i Dati di Carattere)
      4. Crittografare Dati Arbitrari e Documenti XML
      5. Super-Crittografia: Crittografare EncryptedData
   2. Uso di EncryptedData e EncryptedKey
      1. EncryptedData con Chiave Simmetrica (KeyName)
      2. EncryptedKey (ReferenceList, ds:RetrievalMethod,CarriedKeyName)
3. Sintassi di Crittografia
   1. L'Elemento EncryptedType
   2. L'Elemento EncryptionMethod
   3. L'Elemento CipherData
      1. L'Elemento CipherReference
   4. L'Elemento EncryptedData
   5. Le Estensioni all'Elemento ds:KeyInfo
      1. L'Elemento EncryptedKey
      2. L'Elemento ds:RetrievalMethod
   6. L'Elemento ReferenceList
   7. L'Elemento EncryptionProperties
4. Regole di Elaborazione
   1. Crittografia
   2. Decifrazione
   3. Crittografare XML
      1. Una Implementazione di Crittografia (non-normativa)
      2. Una Implementazione di Crittografia e Sostituzione (non-normativa)
      3. Serializzare XML (non-normativa)
      4. Andare a Capo nel Testo (non-normativa)
5. Algoritmi
   1. Identificatori dell'Algoritmo e Requisiti dell'Implementazione
   2. Algoritmi della Crittografia a Blocco
   3. Algoritmi della Crittografia a Flusso
   4. Trasporto della Chiave
   5. Accordo sulla Chiave
   6. Separazione della Chiave Simmetrica
   7. Riassunto del Messaggio
   8. Autenticazione del Messaggio
   9. Canonizzazione
6. Considerazioni sulla Sicurezza
   1. Relazione con le Firme Digitali XML
   2. Informazione Rivelata
   3. Nonce e IV (Valore o Vettore di Inizializzazione)
   4. Rifiuto di Servizio
   5. Contenuto Insicuro
7. Conformità
8. Tipo di Medium della Crittografia XML
   1. Introduzione
   2. Registrazione di application/xenc+xml
9. Schema ed Esempi Validi
10. Riferimenti

1 Introduzione

Questo documento specifica un processo per crittografare i dati e rappresentare il risultato in XML. I dati potrebbero essere dati arbitrari (incluso un documento XML), un elemento XML, oppure il contenuto di un elemento XML. Il risultato della crittografia dei dati è un elemento di Crittografia XML EncryptedData il quale contiene (attraverso uno dei contenuti dei suoi figli) o identifica (attraverso un riferimento URI) il dato cifrato.

Quando si crittografa un elemento o un contenuto di elemento XML l'elemento EncryptedData sostituisce l'elemento o il contenuto (rispettivamente) nella versione crittografata del documento XML..

Quando si crittografano dei dati arbitrari (inclusi interi documenti XML), l'elemento EncryptedData potrebbe diventare la radice di un nuovo documento XML o diventare un elemento figlio di un documento XML specifico per applicazione.

1.1 Convenzioni  Editoriali e di Conformità

Questa specifica usa gli schemi XML [XML-schema] per descrivere il modello di contenuto.

Le parole chiave "DEVE", "NON DEVE", "OBBLIGATORIO", "DOVRÀ", "NON DOVRÀ", "DOVREBBE", "NON DOVREBBE", "RACCOMANDATO", "HA FACOLTÀ/POTREBBE", e "FACOLTATIVO" in questa specifica sono da interpretarsi come descritto in RFC2119 [KEYWORDS]:

"esse DEVONO essere usate solo quando è veramente richiesto per operazioni interdipendenti o per limitare comportamenti che sono potenzialmente nocivi (ad es., limitare ritrasmissioni)"

Di conseguenza, usiamo queste parole chiave in maiuscolo per specificare in maniera non ambigua i requisiti per il protocollo o per le caratteristiche dell'applicazione e comportamenti che afferiscano all'interoperabilità e alla sicurezza delle implementazioni. Queste parole chiave non vengono utilizzate (in maiuscolo) per descrivere la grammatica XML; le definizioni di schema descrivono in maniera non ambigua tali requisiti e desideriamo riservare il risalto di questi termini per le descrizioni nel linguaggio naturale dei protocolli e delle caratteristiche. Per esempio, un attributo XML potrebbe essere descritto come "facoltativo". La conformità alla specifica di namespace-XML [XML-NS] viene descritta come "OBBLIGATORIA."

1.2 Filosofia di Progetto

Per la filosofia di progetto e i requisiti di questa specifica (incluse le limitazioni relative alla validità dell'istanza) indirizzarsi ai Requisiti della Crittografia XML [EncReq].

1.3 Versioni, Namespace, URI, e Identificatori

Non viene fornito alcun numero di versione esplicito in questa sintassi. Se si renderà necessaria una versione futura, userà un namespace differente. L'URI del namespace XML sperimentale [XML-NS] che DEVE essere usato dalle implementazioni di questa specifica (datata) è:

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

Questo namespace viene anche usato come il prefisso per gli identificatori di algoritmo utilizzati da questa specifica. mentre le applicazioni DEVONO supportare XML e i namespace XML, l'uso di entità interne [XML, sezione 4.2.1], il prefisso di namespace XML "xenc" [XML-NS, sezione 2] e le convenzioni di valorizzazione predefinita/di ambito sono FACOLTATIVE; usiamo queste alternative per fornire esempi compatti e leggibili. In aggiunta, l'entità &xenc; viene definita così per fornire identificatori abbreviati per gli URI definiti in questa specifica. Per esempio "&xenc;Element" corrisponde a "http://www.w3.org/2001/04/xmlenc#Element".

Questa specifica fa uso del namespace e delle definizioni di schema della Firma XML  [XML-DSIG]

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

Gli URI [URI] DEVONO tollearare la definizione di tipo di [XML-Schema] anyURI la specifica [XML-DSIG, 4.3.3.1 The URI Attribute] (ovvero, caratteri permessi, codifica escape dei caratteri, supporto allo schema, etc.).

1.4  Riconoscimenti

Vengono testimoniati con riconoscenza i contributi dei seguenti membri del Gruppo di Lavoro a questa specifica in accordo alle politiche di contribuzione e all'elenco del GL attivo.

• Joseph Ashwood
• Simon Blake-Wilson, Certicom
• Frank D. Cavallito, BEA Systems
• Eric Cohen, PricewaterhouseCoopers
• Blair Dillaway, Microsoft (Autore)
• Blake Dournaee, RSA Security
• Donald Eastlake, Motorola (Curatore)
• Barb Fox, Microsoft
• Christian Geuer-Pollmann, Università di 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 (Autore)
• 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 (Presidente, Curatore)
• Aleksey Sanin
• Jim Schaad, Soaring Hawk Consulting
• Ed Simon, XMLsec (Autore)
• Daniel Toth, Ford
• Yongge Wang, Certicom
• Steve Wiley, myProof

In aggiunta, ringraziamo di seguito per i loro interventi durante e successivamente all'Ultima Chiamata:

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

2 Panoramica sulla Crittografia ed Esempi (Non-normativo)

Questa sezione fornisce una panoramica ed esempi di sintassi di Crittografia XML. La sintassi formale si trova in Sintassi di Crittografia (sezione 3); l'elaborazione specifica viene data in Regole di Elaborazione (sezione 4).

Espresso in forma abbreviata, l'elemento EncryptedData ha la seguente struttura (dove "?" indica zero o una occorrenza; "+" indica una o più occorrenze; "*" indica zero o più occorrenze; e il tag di elemento vuoto significa che l'elemento deve essere vuoto):

  <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'elemento CipherData racchiude o fa riferimento ai dati crittografati grezzi. Se racchiusi, i dati crittografati grezzi sono il contenuto dell'elemento CipherValue; se referenziati, l'attributo URI dell'elemento CipherReference punta alla posizione dei dati crittografati grezzi.

2.1 Granularità della Crittografia

Si considerino le seguenti finte informazioni di pagamento, le quali includono informazioni di identificazione e appropriate a descrivere un metodo di pagamento (ad es., carta di credito, trasferimento di fondi, o assegno elettronico):

  <?xml version='1.0'?>
  <PaymentInfo xmlns='http://example.org/paymentv2'>
    <Name>John Smith</Name>
    <CreditCard Limit='5,000' Currency='USD'>
      <Number>4019 2445 0277 5567</Number>
      <Issuer>Example Bank</Issuer>
      <Expiration>04/02</Expiration>
    </CreditCard>
  </PaymentInfo>

Questa marcatura sta a rappresentare che John Smith sta utilizzando la sua carta di credito con un limite di $5,000USD.

2.1.1 Crittografare un Elemento XML

Il numero della carta di credito di Smith è un'informazione sensibile! Se l'applicazione desidera mantenere riservata quella informazione, può crittografarle l'elemento  CreditCard:

  <?xml version='1.0'?>
  <PaymentInfo xmlns='http://example.org/paymentv2'>
    <Name>John Smith</Name>
    <EncryptedData Type='http://www.w3.org/2001/04/xmlenc#Element'
     xmlns='http://www.w3.org/2001/04/xmlenc#'>
      <CipherData>
        <CipherValue>A23B45C56</CipherValue>
      </CipherData>
    </EncryptedData>
  </PaymentInfo>

Crittografando l'intero elemento CreditCard dal suo tag di inizio a quello di fine, viene nascosta l'identità dell'elemento stesso. (Un impiccione non sa se egli ha utilizzato una carta di credito o un trasferimento di fondi.) L'elemento CipherData contiene la serializzazione crittografata dell'elemento CreditCard.

2.1.2 Crittografare il Contenuto dell'Elemento XML (gli Elementi)

Come scenario alternativo, potrebbe essere utile per degli agenti intermedi sapere che John utilizza una carta di credito con un particolare limite, ma non il numero di carta di credito, il soggetto emittente, e la data di scadenza. In questo caso, viene crittografato il contenuto (i dati di carattere o gli elementi figli) dell'elemento CreditCard:

  <?xml version='1.0'?> 
  <PaymentInfo xmlns='http://example.org/paymentv2'>
    <Name>John Smith</Name>
    <CreditCard Limit='5,000' Currency='USD'>
      <EncryptedData xmlns='http://www.w3.org/2001/04/xmlenc#'
       Type='http://www.w3.org/2001/04/xmlenc#Content'>
        <CipherData>
          <CipherValue>A23B45C56</CipherValue>
        </CipherData>
      </EncryptedData>
    </CreditCard>
  </PaymentInfo>

2.1.3 Crittografare il Contenuto dell'Elemento XML (i Dati di Carattere)

Oppure, si consideri lo scenario nel quale tutte le informazioni eccetto l'effettivo numero della carta di credito possano essere in chiaro, incluso il fatto che l'elemento Number esista:

  <?xml version='1.0'?> 
  <PaymentInfo xmlns='http://example.org/paymentv2'>
    <Name>John Smith</Name>
    <CreditCard Limit='5,000' Currency='USD'>
      <Number>
        <EncryptedData xmlns='http://www.w3.org/2001/04/xmlenc#'
         Type='http://www.w3.org/2001/04/xmlenc#Content'>
          <CipherData>
            <CipherValue>A23B45C56</CipherValue>
          </CipherData>
        </EncryptedData>
      </Number>
      <Issuer>Example Bank</Issuer>
      <Expiration>04/02</Expiration>
    </CreditCard>
  </PaymentInfo>

Sia CreditCard che Number sono in chiaro, ma il contenuto dei dati di carattere di Number sono criptati.

2.1.4 Crittografare Dati Arbitrari e Documenti XML

Se lo scenario dell'applicazione richiede che tutte le informazioni siano criptate, l'intero documento viene crittografato come una sequenza di ottetti. Ciò si applica ai dati arbitrari inclusi i documenti 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 Super-Crittografia: Crittografare EncryptedData

Un documento XML potrebbe contenere zero o più elementi EncryptedData. EncryptedData non può essere genitore o figlio di un altro elemento EncryptedData. Comunque, i dati effettivi criptati possono essere di qualunque tipo, inclusi gli elementi EncryptedData e EncryptedKey (ovvero, super-crittografia). Durante la super-crittografia di un elemento EncryptedData o EncryptedKey, si deve crittografare l'intero elemento. Crittografando solo il contenuto di questi elementi, o crittografando elementi figli selezionati è un'istanza non valida per lo schema fornito.
Per esempio, si consideri il seguente:

  <pay:PaymentInfo xmlns:pay='http://example.org/paymentv2'>
    <EncryptedData Id='ED1' xmlns='http://www.w3.org/2001/04/xmlenc#'
     Type='http://www.w3.org/2001/04/xmlenc#Element'>
      <CipherData>
        <CipherValue>originalEncryptedData</CipherValue>
      </CipherData>
    </EncryptedData>
  </pay:PaymentInfo>

Una super-crittografia valida di "//xenc:EncryptedData[@Id='ED1']" sarebbe:

  <pay:PaymentInfo xmlns:pay='http://example.org/paymentv2'>
    <EncryptedData Id='ED2' xmlns='http://www.w3.org/2001/04/xmlenc#'
     Type='http://www.w3.org/2001/04/xmlenc#Element'>
      <CipherData>
        <CipherValue>newEncryptedData</CipherValue>
      </CipherData>
    </EncryptedData>
  </pay:PaymentInfo>

dove il contenuto CipherValue di 'newEncryptedData' è la codifica in base64 della sequenza di ottetto criptata risultante dallacrittografia dell'elemento EncryptedData con Id='ED1'.

2.2 Uso di EncryptedData e EncryptedKey

2.2.1 EncryptedData con Chiave Simmetrica  (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>John Smith</ds:KeyName>
  [s5]   </ds:KeyInfo>
  [s6]   <CipherData><CipherValue>DEADBEEF</CipherValue></CipherData>
  [s7] </EncryptedData>

[s1] Il tipo di dato crittografato potrebbe essere rappresentato come un valore di attributo di aiuto nella decifrazione e nella conseguente elaborazione. In questo caso, i dati criptati erano un 'elemento'. Altre alternative includono il 'contenuto' di un elemento, o una sequenza di ottetti esterna che può anche essere identificata tramite gli attributi MimeType e Encoding.

[s2] Questa (3DES CBC) è una cifratura a chiave simmetrica.

[s4] La chiave simmetrica ha un nome associato "John Smith".

[s6] CipherData contiene un CipherValue, che è una sequenza di ottetti codificata in base64. In alternativa, potrebbe contenere un CipherReference, che è un riferimento di URI insieme a trasformazioni necessarie per ottenere i dati crittografati come una sequenza di ottetti.

2.2.2 EncryptedKey (ReferenceList, ds:RetrievalMethod, CarriedKeyName)

La seguente struttura di EncryptedData è molto simile a quella di cui sopra, eccetto che questa volta si fa riferimento alla chiave usando un 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>Sally Doe</ds:KeyName>
  [t06]   </ds:KeyInfo>
  [t07]   <CipherData><CipherValue>DEADBEEF</CipherValue></CipherData>
  [t08] </EncryptedData>

[t02] Questa (AES-128-CBC) è una cifratura a chiave simmetrica.

[t04] ds:RetrievalMethod viene usato per indicare la posizione della chiave di tipo &xenc;EncryptedKey. La chiave (AES) si trova presso '#EK'.

[t05] ds:KeyName fornisce un metodo alternativo per identificare la chiave necessaria a decifrare il CipherData. Da soli o insieme ds:KeyName e ds:KeyRetrievalMethod potrebbero essere utilizzati per identificare la stessa chiave.

All'interno del medesimo documento XML, esisteva una struttura EncryptedKey alla quale si faceva riferimento dentro [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>John Smith</ds:KeyName>
  [t13]   </ds:KeyInfo>
  [t14]   <CipherData><CipherValue>xyzabc</CipherValue></CipherData>
  [t15]   <ReferenceList>
  [t16]     <DataReference URI='#ED'/>
  [t17]   </ReferenceList>
  [t18]   <CarriedKeyName>Sally Doe</CarriedKeyName>
  [t19] </EncryptedKey>

[t09] L'elemento EncryptedKey è simile all'elemento EncryptedData eccetto che i dati crittografati sono sempre un valore di chiave.

[t10] Il EncryptionMethod è l'algoritmo a chiave pubblica di RSA.

[t12] ds:KeyName di "John Smith" è una proprietà della chiave necessaria per la decifrazione (usando RSA) di CipherData.

[t14] Il CipherValue di CipherData è una sequenza di ottetti che viene elaborata (serializzata, crittografata, e codificata) da un oggetto criptato di riferimento appartenente a EncryptionMethod. (Si noti, un EncryptionMethod di EncryptedKey è un algoritmo usato per crittografare questi ottetti e non dice nulla su quale tipo di ottetti essi siano.)

[t15-17] Una ReferenceList identifica gli oggetti criptati (DataReference e KeyReference) crittografati con questa chiave. Il ReferenceList contiene un elenco di riferimenti a dati crittografati da una chiave simmetrica trasportata all'interno di questa struttura.

[t18] L'elemento CarriedKeyName viene usato per identificare il valore di chiave crittografata al quale si può far riferimento dall'elemento KeyName in ds:KeyInfo. (Dal momento che i valori di attributo devono essere univoci per un documento, CarriedKeyName può indicare che alcune strutture EncryptedKey contengono lo stesso valore di chiave crittografata per differenti destinatari.)

3 Sintassi di Crittografia

Questa sezione fornisce una descrizione dettagliata della sintassi e delle caratteristiche della Crittografia XML. Le caratteristiche descritte in questa sezione DEVONO essere implementate ameno che non sia diversamente espresso. a sintassi viene definita attraverso [XML-Schema] con i seguenti preambolo, dichiarazione, entità interna, e importazione di XML:

  Definizione dello Schema:

  <?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'Elemento EncryptedType

EncryptedType è il tipo astratto dal quale sono derivati EncryptedData e EncryptedKey. Mentre questi ultimi due tipi di elemento sono molto simili rispetto ai loro modelli di contentuo, è utile per l'elaborazione una distinzione sintattica. L'implementazione DEVE generare in modo lasco uno schema valido [XML-schema] EncryptedData o EncryptedKey come specificato dalle successive dichiarazioni di schema. (Si noti che la generazione di schemi validi in modo lasco significa he il contenuto permesso da xsd:ANY non ha bisogno di essere valido.) Le implementazioni DOVREBBERO creare queste strutture XML (gli elementi EncryptedType e i loro discendenti/contenuti) nella Forma di Normalizzazione C [NFC, NFC-Corrigendum].

  Definizione dello Schema:

  <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>

EncryptionMethod è un elemento facoltativo che descrive l'algoritmo di cifratura applicato ai dati cifrati. Se l'elemento è assente, l'algoritmo di cifratura deve essere conosciuto dal destinatario oppure la decifrazione fallirà.

ds:KeyInfo è un elemento facoltativo, definito da [XML-DSIG], che porta l'informazione sulla chiave utilizzata per crittografare i dati. Le sezioni seguenti di questa specifica definiscono nuovi elementi che potrebbero apparire come figli di ds:KeyInfo.

CipherData è un elemento obbligatorio che contiene i CipherValue o CipherReference con i dati criptati.

EncryptionProperties può contenere informazioni aggiuntive concernenti la generazione del EncryptedType (ad es., la marca data/ora).

Id è un attributo facoltativo che fornisce il metodo standard di assegnazione di un id stringa all'elemento all'interno del contesto del documento.

Type è un attributo facoltativo che identifica il tipo di informazione riguardo alla forma in testo semplice del contenuto crittografato. Benché facoltativo, questa specifica si avvantaggia di esso per l'elaborazione obbligatoria descritta in Decifrazione: Regole di Elaborazione (sezione 4.2). Se l'elemento EncryptedData contiene i dati dell' 'elemento' Type o del 'contenuto' dell'elemento, e sostituisce quei dati in un contesto di documento XML, si raccomanda fortememnte di fornire l'attirbuto Type. Senza questa informazione, il decifrante non sarà in grado di ripristinare automaticamente il documento XML nella sua forma originale testuale in chiaro.

MimeType è un attributo facoltativo (di suggerimento) che descrive il tipo di medium dei dati che sono stati crittografati. Il valore di questo attributo è una stringa con valori definiti da [MIME]. Per esempio, se i dati che sono crittografati sono un PNG codificato in base64, il trasferimento Encoding potrebbe essere specificato come 'http://www.w3.org/2000/09/xmldsig#base64' e il MimeType come 'image/png'. Questo attributo è puramente indicativo, non è richiesta alcuna convalida dell'informazione sul MimeType e non richiede all'applicazione di crittografia di dover far alcuna elaborazione aggiuntiva. Si noti, questa informazione potrebbe non essere necessaria se è già ricollegata all'identificatore nell'attributo Type. Per esempio, i tipi Element e Content definiti in questa specifica sono sempre testo codificato in UTF-8.

3.2 L'Elemento EncryptionMethod

EncryptionMethod è un elemento facoltativo che descrive l'algoritmo di crittografia applicato ai dati cifrati. Se l'elemento è assente, l'algoritmo di crittografia deve essere conosciuto dal destinatario o la decifrazione fallirà.

  Definizione dello Schema:

  <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>

Gli elementi figlio di EncryptionMethod permessi sono determinati dallo specifico valore URI dell'attributo Algorithm, e l'elemento figlio KeySize è sempre permesso. Per esempio, l'algorimo RSA-OAEP (sezione 5.4.2) utilizza gli elementi ds:DigestMethod e OAEPparams. (Ci appoggiamo al costrutto dello schema ANY perché non è possibile specificare contenuto di elemento basato sul valore di un attributo.)

La presenza di un qualsisasi elemento figlio sotto EncryptionMethod che non sia permesso dall'algoritmo o dalla presenza di un figlio KeySize inconsistente con l'algoritmo DEVE essere trattato come un errore. (Tutti gli URI di algoritmo specificati in questo documento implicano una lunghezza di chiave ma ciò non è vero in generale. Gli algoritmi più popolari di crittografia a flusso richiedono lunghezze di chiave variabili.)

3.3 L'Elemento CipherData

Il CipherData è un elemento obbligatorio che fornisce i dati crittografti. Deve contenere sia la sequenza di ottetti crittografata come testo codificato in base64 dell'elemento CipherValue, oppure fornisce un riferimento a una posizione esterna contenente la sequenza di ottetti crittografata, tramite l'elemento CipherReference.

  Definizione di Schema:

  <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'Elemento CipherReference

Se CipherValue non è fornito direttamente, il CipherReference identifica una fonte che, quando elaborata, produce una sequenza di ottetti crittografata.

Il valore effettivo viene ottenuto come segue. L'URI di CipherReference contiene un identificatore che viene de-referenziato. L'elemento CipherReference dovrebbe contenere una sequenza FACOLTATIVA dei Transform, i dati risultanti dal de-referenziamento dell'URI viene trasformato come specificato così da produrre il valore criptato voluto. Per esempio, se il valore è codificato in base64 all'interno di un documento XML; i Transforms potrebbero specificare un'espressione XPath seguita da una decodifica in base64 così da estrarre gli ottetti.

La sintassi dell'URI e dei Transforms è simile a quella di [XML-DSIG]. Comunque, vi è una differenza tra l'elaborazione della firma e della crittografia. In [XML-DSIG] l'elaborazione sia della generazione che della convalida cominciano con gli stessi dati sorgente ed effettuano quella trasformazione nel medesimo ordine. Nella crittografia, il decifratore possiede solo i dati cifrati e le trasformazioni specificate sono enumerate per il decifratore, nell'ordine necessario ad ottenere gli ottetti. Di conseguenza, poiché ha una semantica differente Transforms si trova nel namespace di &xenc;.

Per esempio, se il valore cifrato in questione viene intercettato dentro un elemento CipherValue all'interno di un documento XML differente, il CipherReference potrebbe apparire come segue:

  <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.org/repository">
            self::text()[parent::rep:CipherValue[@Id="example1"]]
          </ds:XPath>
      </ds:Transform>
      <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#base64"/>
    </Transforms>
  </CipherReference>

Le implementazioni DEVONO supportare la caratteristica CipherReference e gli stessi codifica, de-referenziamento e schema dell'URI, e i codici di risposta HTTP come quella di [XML-DSIG]. La caratteristica Transform e gli algoritmi di trasformazione particolari sono FACOLTATIVI.

  Definizione di Schema:

  <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'Elemento EncryptedData

L'elemento EncryptedData è l'elemento fondamentale della sintassi. Non solo i suoi figli CipherData contengono i dati crittografati, ma è anche l'elemento che sostituisce l'elemento crittografato, oppure funge da nuova radice del documento.

  Definizione di Schema:

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

3.5 Le Estensioni all'Elemento ds:KeyInfo

Ci sono tre modi in cui si può fornire il materiale di manipolazione delle chiavi necessario a decifrare CipherData:

1. L'elemento EncryptedData o EncryptedKey specificano il materiale di manipolazione delle chiavi associato tramite un figlio di ds:KeyInfo. Tutti gli elementi figlio di  ds:KeyInfo specificati in [XML-DSIG] POTREBBERO essere utilizzati come definito:
   1. Il supporto per ds:KeyValue è facoltativo e potrebbe essere usato pe trasportare le chiavi pubbliche, come i valori di chiave Diffie-Hellman (sezione 5.5.1). (Includere la chiave di decifratura in testo semplice, se chiave privata o chiave segreta, ovviamente è NON RACCOMANDATO.)
   2. Il supporto di ds:KeyName per riferirsi a un EncryptedKey CarriedKeyName è RACCOMANDATO.
   3. Il supporto per lo stesso documento ds:RetrievalMethod è OBBLIGATORIO.

   In aggiunta, forniamo due elementi figli addizionali: le applicazioni DEVONO supportare EncryptedKey (sezione 3.5.1) e POTREBBERO supportare AgreementMethod (sezione 5.5).

2. Un elemento distaccato (non dentro ds:KeyInfo) EncryptedKey può specificare l'EncryptedData o l'EncryptedKey al quale si applicherà la sua chiave decriptata tramite un DataReference o un KeyReference (sezione 3.6).
3. Il materiale di manipolazione delle chiavi può essere determinato dal destinatario attraverso il contesto dell'applicazione e così non occorre che sia menzionato esplicitamente nell'XML trasmesso.

3.5.1 L'Elemento EncryptedKey

Identificatore

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

(Questo può essere usato all'interno di un elemento ds:RetrievalMethod per identificare il tipo di referente.)

L'elemento EncryptedKey viene usato per trasportare le chiavi di cifratura dalla fonte originaria fino a uno o più destinatari conosciuti. Potrebbe essere usato come un documento XML autonomo, essere piazzato all'interno di un documento di applicazione, oppure comparire dentro un elemento EncryptedData come un figlio di un elemento ds:KeyInfo. Il valore di chiave è sempre crittografato per il/i destinatari/o. Quando EncryptedKey viene decifrato gli ttetti risultanti divengono disponibili per l'algoritmo EncryptionMethod senza alcuna elaborazione aggiuntiva.

  Definizione di Schema:

  <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>

ReferenceList è un elemento facoltativo contenente i puntatori ai dati e alle chiavi crittografati usando questa chiave. L'elenco dei riferimenti potrebbe contenere riferimenti multipli a elementi EncryptedKey e EncryptedData. Ciò viene fatto utilizzando rispettivamente gli elementi KeyReference e DataReference. Questi sono definiti più sotto.

CarriedKeyName è un elemento facoltativo per associare un nome utente leggibile al valore di chiave. Ciò potrebbe quindi venire usato per far riferimento alla chiave utilizzando l'elemento ds:KeyName dentro ds:KeyInfo. La stessa etichetta CarriedKeyName, a differenza di un tipo ID, potrebbe ricorrere molteplici volte all'interno di un singolo documento. Il valore della chiave deve essere lo sesso in tutti gli elementi EncryptedKey identificati dalla stessa etichetta CarriedKeyName all'interno di un singolo documento XML. Si noti che poiché lo spazio bianco è significativo nel valore dell'elemento ds:KeyName, lo spazio bianco è significativo anche nel valore dll'elemento  CarriedKeyName.

Recipient è un attributo facoltativo che contiene un suggerimento per indicare a quale destinatario sia diretto questo valore di chiave crittografato. I suoi contenuti sono dipendenti dall'applicazione.

L'attributo Type ereditato da EncryptedType può essere usato per specificare ulteriormente il tipo della chiave crittografata se l'algoritmo di EncryptionMethod non definisce una codifica/rappresentazione non ambigua. (Si noti, tutti gli algoritmi in questa specifica possiedono una rappresentazione non ambigua per le strutture di chiave associate.)

3.5.2 L'Elemento ds:RetrievalMethod

Il ds:RetrievalMethod [XML-DSIG]con un Type di 'http://www.w3.org/2001/04/xmlenc#EncryptedKey' fornisce un modo per esprimere un collegamento a un elemento EncryptedKey contenente la chiave necessaria a decifrare il CipherData associato con un elemento EncryptedData o EncryptedKey. Il ds:RetrievalMethod con questo tipo è sempre un figlio dell'elemento ds:KeyInfo e potrebbe comparire molteplici volte. Se esiste più di una istanza di un ds:RetrievalMethod in un ds:KeyInfo di questo tipo, allora gli oggetti EncryptedKey a cui ci si riferisce devono contenere lo stesso valore di chiave, possibilmente crittografato in modi diversi o per destinatari differenti.

  Definizione di Schema:

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

3.6 L'Elemento ReferenceList

ReferenceList è un elemento che contiene puntatori da un valore di chiave di un EncryptedKey agli elementi crittografati da quel valore di chiave (elementi EncryptedData o EncryptedKey).

  Definizione di Schema:

  <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>

Gli elementi DataReference vengono usati per riferirsi a elementi EncryptedData che sono stati crittografati usando la chiave defita nell'elemento EncryptedKey che li racchiude. Possono ricorrere molteplici elementi DataReference se esistono molteplici elementi EncryptedData che sono crittografati dalla stessa chiave.

Gli elementi KeyReference vengono usati per riferirsi a elementi EncryptedKey che sono stati crittografati usando a chiave defibita nell'elemento EncryptedKey che li racchiude. Possono ricorrere molteplici elementi KeyReference se esistono molteplici elememnti EncryptedKey che sono crittografati dalla stessa chiave.

Per entrambi i tipi di riferimenti si potrebbe specificare facoltativamente gli elementi figli per aiutare il destinatario nel recupero degli elementi EncryptedKey e/o EncryptedData. Questi potrebbero includere informazioni come le trasformazioni XPath, le trasformazioni i decompressione, o le informazioni su come recuperare gli elementi da un programma per l'archiviazione di documenti. Per esempio:

  <ReferenceList>
    <DataReference URI="#invoice34">
      <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="example1"]
          </ds:XPath>
        </ds:Transform>
      </ds:Transforms>
    </DataReference>
  </ReferenceList>

3.7 L'Elemento EncryptionProperties

Identificatore

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

(Questo può essere usato all'interno di un elemento ds:Reference per identificare il tipo di referente.)

AElementi di informazione aggiuntivi concernenti la generazioni dell'EncryptedData o dell'EncryptedKey possono essere posti un un elemento EncryptionProperty (ad es., la marcatura temporale o il numero di serie o l'hardware crittografico utilizzato durante la cifratura). L'attributo Target identifica la struttura EncryptedType da descriversi. anyAttribute permette l'inclusione di attributi dal namespace XML che devono essere inclusi (ovvero, xml:space, xml:lang, e xml:base).

  Definizione di Schema:

  <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 Regole di Elaborazione

Questa sezione descrive le operazioi da effettuarsi come parte dell'elaborazione della crittografia e della decifratura da arte delle implementazioni di questa specifica. i requisiti di conformità sono specificati sui seguenti ruoli:

Applicazione

TL'applicazione che fa richiesta di un'implementazione di Crittografia XML attraverso la fornitura dei dati e dei parametri necessari per la sua elaborazione.

Cifratore

AUn'implementazione di Crittografia XML con il ruolo di crittografare i dati.

Decifratore

AUn'implementazione di Crittografia XML con il ruolo di decifrare i dati.

4.1 Crittografia

FPer ogni dato che deve essere crittografato come un EncryptedData o un EncryptedKey (elementi derivati da EncryptedType), il cifrante deve:

1. Selezionare l'algoritmo /e i parametri) da usarsi nel crittografare questo dato.
2. Ottenere e (facoltativamente) rappresntare la chiave.
   1. ISe la chiave deve essere identificata (attraverso la nomenclautra, l'URI, o inclusa in un elemento figlio), costruire il ds:KeyInfo in modo appropriato (ad es., ds:KeyName, ds:KeyValue, ds:RetrievalMethod, etc.)
   2. ISe è la chiave stessa a dover essere crittografata, costruire un elemento EncryptedKey applicando in modo ricorsivo questo processo di crittografia. Il risultato potrebbe essere quindi un figlio di ds:KeyInfo, o potrebbe esistere in qualche altro posto e potrebbe essere stato identificato nel passaggio precedente.
3.  Crittografare il dato
   1. ISe il dato è un 'elemento' [XML, sezione 3] o il 'contenuto' di un elemento [XML, sezione 3.1], ottenere gli ottetti serializzando il dato in UTF-8 come specificato in [XML]. (L'applicazione DEVE fornire i dati XML in [NFC].) Il cifratore HA FACOLTÀ di effettuare la serializzazione. Se il cifratore non serializza, allora l'applicazione DEVE compiere la serializzazione.
   2. ISe il dato è di un qualsiasi altro tipo che non sia già in ottetti, l'applicazione DEVE serializzarlo come ottetti.
   3. ECrittografare gli ottetti usando l'algoritmo e la chiave dai passaggi 1 e 2.
   4. UA meno che il decifratore conoscerà implicitamente il tipo del dato crittografato, il cifratore DOVREBBE fornire il tipo per la rappresentazione.

      TLa definizione di questo tipo come ricollegato a un identificatore specifica come ottenere e interpretare gli ottetti in testo semplice dopo la decifrazione. per esempio, l'identificatore potrebbe indicare che il dato è un'istanza di un'altra applicazione (ad es. alucne applicazioni di compressione XML) che devono essere ulteriormente elaborate. oppure, se il dato è una semplice sequenza di ottetti POTREBBE essere descritto con gli attributi MimeType e Encoding. Per esempio, il dato potrebbe essere un documento XML (MimeType="text/xml"), una sequenza di caratteri (MimeType="text/plain"), o dati binari di un'immagine (MimeType="image/png").

4. Costruire la struttura EncryptedType (EncryptedData o EncryptedKey):

   Una struttura EncryptedType rappresenta tutte le informazioni precedentemente discusse inclusi il tipo dei dati cifrati, l'algoritmo di crittografia, i parametri, la chiave etc.

   1. ISe la seuqenza di ottetti cifrata ottenuta nel passaggio 3 deve essere accolta nell'elemento CipherData all'interno di quello EncryptedType, allora la seuqenza di ottetti cifrata è codificata in base64 e inserita come il contenuto di un elemento CipherValue.
   2. ISe la seuqenza di ottetti cifrata dee essere accolta esternamente alla struttura EncryptedType, allora si accolga o si restituisca la sequenza di ottetti cifrata, e si rappresenti l'RI e le trasformazioni (se presenti) richieste al decifratore per recuperare la sequenza di ottetti all'interno di un elemento CipherReference.
5. Elaborare EncryptedData
   1. ISe il Type del dato cifrato è 'elemento' o 'contenuto' di elemento, allora il cifratore DEVE essere in grado di restituire l'elemento EncryptedData all'applicazione. L'applicazione HA FACOLTÀ di utilizzare questo come elemento di massimo livello in un nuovo documento XML o inserirlo in un altro documento XML, il quale potrebbe richiedere una ri-codifica.

      TIl cifratore DOVRBBE essere in grado di sostituire un 'elemento' non cifrato o un 'contenuto' con l'elemento EncryptedData. Quando un'applicazione richiede che un elemento o contenuto XML debba essere sostituito, essa fornisce il contesto del documento XML in aggiunta per identificare l'elemento o il contenuto da sostuirsi. Il cifratore rimuove l'elemento o il contenuto identificato e inserisce al suo posto l'elemento EncryptedData.

      (Nota: Se il Type è "contenuto" il documento risultante dalla decifrazione non sarà ben-formato se (a) il testo semplice originale non era ben-formato (ad es., PCDATA stesso non è ben-formato) e (b) l'elemento EncryptedData è stato precedentemente l'elemento radice del documento)

   2. If the Type of the encrypted data is not 'element' or element 'content', then the encryptor MUST always return the EncryptedData element to the application. The application MAY use this as the top-level element in a new XML document or insert it into another XML document, which may require a re-encoding.

4.2 Decifrazione

Per ogni elemento derivato EncryptedType, (cioé, EncryptedData o EncryptedKey), che deve essere decifrato, il deciratore deve:

1. Elaborare l'elemento per determinare l'algoritmo, i parametri e l'elemento ds:KeyInfo da usarsi. se viene omessa qualche informazione, l'applicazione DEVE fornirla.
2. Localizzare la chiave di cifratura dei dati in accordo all'elemento ds:KeyInfo, il quale potrebbe contenere uno o più elementi figlio. Questi figli non hanno un ordine di elaborazione implicito. Se la chiave di cifratura dei dati è cifrata, localizzare la chiave corrispondente per decifrarla. (Questopotrebbe diventareun passaggio ricorsivo poiché la chiave di cifratura-chiave potrebbe essere essa stessa cifrata.) oppure, si potrebbe recuperare la chiave di cifratura dei dati da un archivio locale usando gli attributi o il collegamento implicito forniti.
3. Decifrare i dati contenuti nell'elemento CipherData.
   1. ISe è presente un elemento figlio CipherValue, allora viene recuperato il valore testuale associato e decodificato in base64 in modo tale da ottenere la sequenza di ottetti cifrata.
   2. ISe è presente un elemento figlio CipherReference, l'URI e le trasformazioni (se presenti) vengono usate per recuperare la seuqenza di ottetti cifrata.
   3. TLa seuqenza di otteti cifrata è decifrata usando l'algoritmo/i parametri e il valore di chiave già determinati dai passaggi 1 e 2.
4. Elaborare i dati decifrati del Type dell' 'elemento' o del 'contenuto' di elemento.
   1. TLa sequenza di ottetti in testo in chiaro ottenuta nel passaggio 3 viene interpretato come dati di carattere codificati in UTF-8.
   2. TIl decifratore DEVE essere in grado di restituire il valore del Type e i dati di carattere XML codificati in UTF-8. Il decifratore è NON OBBLIGATO a eseguire la convalida dell'XML serializzato.
   3. TIl decifratore DOVREBBE supportare la possibilità di sostituire l'elemento EncryptedData con l' 'elemento' o con il 'contenuto' di elemento decifrati rappresentati dai caratteri codificati in UTF-8. Il decifratore è NON OBBLIGATO a eseguire la convalida del risultato di questa operazione di sostituzione.

      TL'applicazione fornisce il contesto del documento XML e identifica l'elemento EncryptedData da sostituirsi. Se il documento nel quale è ricorsa la sostituzione non è UTF-8, il decifratore DEVE transcodificare i caratteri codificati in UTF-8 nella codifica di destinazione.

5. PElaborare i dati decifrati se il Type non è specificato o se non è 'elemento' o 'contenuto' di elemento.
   1. TLa sequenza di ottetti in testo in chiaro ottenuta nel Passaggio 3 DEVE essere restituita all'applicazione per ulteriore elaborazione insieme con i valori di attibuto di Type, MimeType, e Encoding quando specificati. MimeType e Encoding sono di suggerimento. Il valore di Type è normativo siccome potrebbe contenere informazioni necessarie per l'elaborazione o l'interpretazione dei dati dall'applicazione.
   2. NSi noti, questo passaggio include l'elaborazione di dati decifrati da un EncryptedKey. La seuqenza di ottetti in testo in chiaro rapresenta un valore i chiave e viene usata dall'applicazione nella decifrazione di altro/i elemento/i EncryptedType.

4.3 Crittografia XML

ELe operazioni di cifratura e decifratura sono trasformazioni di ottetti. L'applicazione è responsabile dell'ordinamento dell'XML in modo tale che esso possa essere serializzato in una sequenza di ottetti, cifrata, decifrata, ed essere utile al destinatario.

FPer esempio, se l'applicazione desidera to canonicalize i suoi dati o codificare/comprimere i dati in un formato di impacchettamento XML, l'applicazione necessita di fare l'ordinamento dell'XML in modo concordante e di identificare il tipo risultante attraverso l'attributo EncryptedData Type. The likelihood di una decifrazione corretta e di una successiva elaborazione sarà dipendente dal supporto del destinatario alla tipologia data. inoltre, se si intende elaborare i dati sia prima della crittografia che dopo la decifrazione (ad es., convalida di Firma XML [XML-DSIG] o una trasformazione XSLT) l'applicazione cifrante deve stare molto attenta a preservare le informazioni necessarie per il successo di quella elaborazione.

FPer ragioni di interoperabilità, i seguenti tipi DEVONO essere implementati cosicché un'implementazione sarà in grado di prendere come ingresso e produrre in uscita i dati corrispondenti alle regole di produzione 39 e 43 da [XML]:

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

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

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

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

TLe sezioni seguenti contengono specifiche per decifrare, sostituire, e serializzare il contenuto XML (cioé, l' 'elemento' Type o il 'contenuto' di elemento) usando il modello di dati [XPath]. Queste sezioni sono non-normative e FACOLTATIVE per gli implementatori di questa specifica, ma a esse si potrebbe far riferimento in modo normativo ed essere OBBLIGATORIE per altre specifiche che richedono un'elaborazione consistente per applicazioni, quali [XML-DSIG-Decrypt].

4.3.1 Un'Implementazione di Decifrazione (Non-normativa)

Dove P è il contesto nel quale l'XML serializzato dovrebbe subire il parsing (un nodo di documento o un nodo di elemento) e O è la sequenza di ottetti rappresentante i caratteri codificati in UTF-8 risultanti dal passaggio 4.3 nell'Elaborazione di Decifrazione (sezione 4.2). Y è un insieme di nodi rappresentante il contenuto decifrato ottenuto dai seguenti pasaggi:

1. Far sì che C sia il contesto di parsing di un figlio di P, che consta dei seguenti elementi:
   • Prefisso e nome di namespace di ogni namespace che sia nell'ambito di P.
   • Nome e valore di ogni entità generale che sia effettiva per il documento XML che causa P.
2. Wrap il flusso di ottetti decifrato O nel contesto C come specificato in Text Wrapping.
3. Eseguire il parsing del flusso di ottetti wrapped come descritto in Il Modello di Elaborazione del Riferimento (sezione 4.3.3.2) di [XML-Signature], risultante in un insieme di nodi.
4. Y è l'insieme di nodi ottenuto rimuovendo il nodo radice, il nodo di elemento wrapping, e l'insieme di attributi e nodi di namespace ad esso associati dall'insieme di nodi ottenuto nel Passaggio 3.

4.3.2 Un'Implementazione di Decifrazione e Sostituzione (Non-normativa)

Dove X è l'insieme di nodi [XPath] corrispondente a un documento XML ed e è un nodo di elemento EncryptedData in X.

1. Z è un insieme di nodi [XPath] identico a X eccetto dove il nodo di elemento e è un tipo di elemento EncryptedData. Nel qual caso:
   1. Decifrare e nel contesto del suo nodo genitore come specificato nell'Implementazione di Decifrazione (sezione 4.3.1) producendo Y, un insieme di nodi [XPath].
   2. Inserire Y al posto di e e i suoi discendenti X. Dal momento che [XPath] non definisce metodi di sostituzione degli insiemi di nodi da documenti differenti, il risultato DEVE essere equivalente al sostituire e con il flusso di ottetti risultante dalla sua decifrazione nella forma serializzata di X e al rieffettuare il parsing del documento. Comunque, il metodo effettivo di compiere questa operazione viene lasciato all'implementatore.

4.3.3 Serializzare XML (Non-normativa)

Considerazioni di Namespace Predefinito

In Crittografare XML (sezione 4.1, passaggio 3.1), quando si serializza un frammento XML un'attenzione speciale DOVREBBE prendersi rispetto ai namespace predefiniti. Se i dati saranno successivamente decifrati nel contesto di un documento XML genitore allora la serializzazione può produrre elementi nel namespace sbagliato. Si consideri il seguente frammento di XML:

  <Document xmlns="http://example.org/">
    <ToBeEncrypted xmlns="" />
  </Document>

La serializzazione del frammento dell'elemento ToBeEncrypted tramite [XML-C14N] risulterebbe nei caratteri "<ToBeEncrypted></ToBeEncrypted>" come un flusso di ottetti. Il documento crittografato che ne risulta sarebbe:

  <Document xmlns="http://example.org/">
    <EncryptedData xmlns="...">
      <!-- Containing the encrypted 
           "<ToBeEncrypted></ToBeEncrypted>" -->
    </EncryptedData>
  </Document>

Decifrare e sostituire l'EncryptedData all'interno di questo documento produrrebbe il risultato errato:

  <Document xmlns="http://example.org/">
    <ToBeEncrypted/>
  </Document> 

Questo problema sorge perché la maggior parte delle serializzazioni XML presumono che i dati serializzati subiranno il parsing direttamente in un contesto dove non esiste una dichiarazione di namespace predefinito. Di conseguenza, essi non dichiarano in modo ridondante il namespace predefinito vuoto con un xmlns="". Se, comunque, i dati serializzati subiscono il parsing in un contesto dove esiste una dichiarazione di namespace predefinito nell'ambito (ad es., il contesto di parsing di Un'Implementazione di Decifrazione (sezione 4.3.1)), allora potrebbe influire sull'interpretazione dei dati serializzati.

Per risolvere questo problema, un algoritmo di canonizzazione POTREBBE essere ampliato come segue per essere usato come un serializzatore di crittografia XML:

• Una dichiarazione di namespace predefinito con un valore vuoto (cioè, xmlns="") DOVREBBE essere emesso dove sarebbe stato normalmente soppresso dall'algoritmo di canonizzazione.

Per quanto il risultato potrebbe non essere nel formato canonico appropriato, ciò non è dannoso poiché il flusso di ottetti risultante non sarà usato direttamente nel calcolo di un valore di firma [XML-Signature]. Tornando all'esempio precedente con il nostro nuovo ampliamento, l'elemento ToBeEncrypted sarebbe serializzato come segue:

<ToBeEncrypted xmlns=""></ToBeEncrypted>

Quando elaborato nel contesto del documento genitore, questo frammento serializzato subirà un parsing e sarà interpretato correttamente.

Questo ampliamento può essere applicato retroattivamente a una implementazione di canonizzazione esistente canonizzando ogni nodo apice e i suoi discendenti dall'insieme dei nodi, inserendo xmlns="" nei punti appropriati, e concatenando i flussi di ottetti risultanti.

Considerazioni di Attributo XML

SUn'attenzione simile fra la relazione di un frammento e il contesto nel quale sta per essere inserito dovrebbe essere posta agli attributi di xml:base, xml:lang, e xml:space come menzionati nelle Considerazioni di Sicurezza di [XML-exc-C14N]. Per esempio, se l'elemento:

  <Bongo href="example.xml"/>

viene preso da un cotesto e serializzato senza alcun attributo di xml:base [XML-Base] e subisce il parsing nel contesto dell'elemento:

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

il risultato sarà:

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

L'href di Bongo successivamente viene interpretato come "http://example.org/example.xml". Se questo non è l'URI corretto, Bongo dovrebbe essere stato serializzato con il proprio attributo di xml:base.

USfortunatamanete, la raccomandazione che un valore vuoto sia emesso per separare il namespcae predefinito del frammento dal contesto nel quale sta per essere inserito non può esser fatto per gli attributi xml:base, e xml:space. (L'Errore 41 degli Errata della Specifica di XML 1.0 Seconda Edizione chiarisce che un valore di stringa vuoto dell'attributo xml:lang è considerato come se, "non sia disponibile alcuna informazione sulla lingua, proprio come se xml:lang non foss stato specificato".) L'interpretazione di un valore vuoto per gli attributi di xml:base o xml:space è indefinita oppure mantiene il valore contestualeattributes is undefined or maintains the contextual value. Consequently, applications SHOULD ensure (1) fragments that are to be encrypted are not dependent on XML attributes, or (2) if they are dependent and the resulting document is intended to be valid [XML], the fragment's definition permits the presence of the attributes and that the attributes have non-empty values.

4.3.4 Circoscrivere il Testo (Non-normativa)

Questa sezione specifica il processo per circoscrivere il testo in un dato contesto di parsing. Il processo è basato sulla proposta di Richard Tobin [Tobin] per costruire l'infoset [XML-Infoset] di un'entità esterna.

Il processo consiste nei seguenti passaggi:

1. Se il contesto di parsing contiene qualsiasi entità generale, allora emette una dichiarazione di tipo di documento che fornisce le dichiarazione di entità.
2. Emette un tag-di-inizio di elemento dummy con gli attributi di dichiarazione di namespace dichiarante tutti i namespace nel contesto di parsing.
3. Emette il testo.
4. Emette un tag-di-fine di elemento dummy.

INei passaggi di cui sopra, la dichiarazione del tipo di documento e i tag dell'elemento dummy DEVONO essere codificati in UTF-8.

CSi consideri il seguente documento contenente un elemento EncryptedData:

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

Se l'elemento EncryptedData è riempito viene decifrato nel testo "<One><foo:Two/></One>", per cui la forma circoscritta è come segue:

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

5. Algoritmi

TQuesta sezione discute gli algoritmi utilizzati con la specifica di Crittografia XML. Le voci contengono l'identificatore da usarsi come il valore dell'attributo Algorithm dell'elemento EncryptionMethod o di altro elemento rappresentante il ruolo dell'algoritmo, un riferimento alla specifica formale, le definizioni per la rappresentazione di chiavi e i risultati delle operazioni crittografiche dove applicabile, e commenti di applicabilità generale.

5.1 Identificatori di Algoritmo e Requisiti di Implementazione

Tutti gli algoritmi sotto-elencati hanno dei parametri impliciti dipendenti dal loro ruolo. Per esempio, i dati da crittografare o decifrare, i materiali di manipolazione delle chiavi, e la direzione dell'operazione (cifratura o decifrazione) per gli algoritmi di crittografia. Qualsiasi parametro esplicito aggiuntivo di un algoritmo compare come gli elementi di contenuto all'interno dell'elemento. Tali parametri di elementi figli hanno nomi di elemento descrittivi, i quali frequentemente sono specifici per l'algoritmo, e DOVREBBERO essere nello stesso namespace come questa specifica di Crittografia XML, la specifica di Firma XML, oppure in un namespace specifico di algoritmo. Un esempio di un simile parametro esplicito potrebbe essere un'occasione (quantità unica) fornita all'algoritmo di accordo sulla chiave.

TQuesta specifica definisce un insieme di algoritmi, i loro URI, e i requisiti per l'implementazione. I livelli di requisito specificati, come "OBBLIGATORIO" o "FACOLTATIVO", si riferiscono all'implementazione, non all'uso. Inoltre, il meccanismo è estensibile, e potrebbero essere usati algoritmi alternativi.

Tavola degli Algoritmi

TLa tavola qui di sotto elenca le categorie di algoritmi. All'interno di ogni categoria, un nome breve, il livello di requisito dell'implementazione, e viene fornito un URI identificativo per ogni algoritmo.

Crittografia a Blocco

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

Crittografia a Flusso

1. nessuno
   La sintassi e le raccomandazioni per supportare algoritmi specificati dall'utente vengono fornite qui sotto.

Trasporto della Chiave

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

Accordo sulla Chiave

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

Copertura della Chiave Simmetrica

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

Digest del Messaggio

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

Autenticazione del Messaggio

1. RACCOMANDATO XML Digital Signature
   http://www.w3.org/2000/09/xmldsig#

Canonizzazione

1. FACOLTATIVO Canonical XML (omits comments)
   http://www.w3.org/TR/2001/REC-xml-c14n-20010315
2. FACOLTATIVO Canonical XML with Comments
   http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments
3. FACOLTATIVO Exclusive XML Canonicalization (omits comments)
   http://www.w3.org/2001/10/xml-exc-c14n#
4. FACOLTATIVO Exclusive XML Canonicalization with Comments
   http://www.w3.org/2001/10/xml-exc-c14n#WithComments

Codifica

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

5.2 Algoritmi di Crittografia a Blocco

BGli algoritmi di crittografia a blocco sono progettati per cifrare e decifrare i dati in dimensione fissa, a blocchi di ottetti multipli. I loro identificatori compaiono come il valore degli attributi Algorithm degli elementi EncryptionMethod che sono figli di EncryptedData.

BGli algoritmi di crittografia a blocco prendono, come argomenti impliciti, i dati da crittogrfare o decifrare, il materale di manipolazione delle chiavi, e le loro direzioni di operazione. Per tutti questi algoritmi specificati qui sotto, viene richiesto un vettore di inizializzazione (IV) che sia codificato con il testo cifrato. Per gli algoritmi di crittografia a blocco specificati dall'utente, l'IV, se presente, potrebbe essere specificato che sia con i dati cifrati, come un elemento di contenuto di algoritmo, o altrove.

TL'IV viene codificato, e prima, con il testo cifrato per gli algoritmi sottostanti per facilitare la disponibilità del codice di decifrazione e per enfatizzare la sua associazione con il testo cifrato. La buona pratica crittografica richiede che per ogni cifratura venga usato un IV differente.

Riempimento

SDal momento che i dati da crittografare sono un numero arbitrario di ottetti, potrebbe non essere un multiplo della dimensione del blocco. Ciò può essere risolto riempiendo il testo semplice fino alla dimensione dl blocco prima della crittografia e togliendo il riempimento dopo la decifrazione. L'algoritmo di riempimento è calcolare il numero non-zero più piccolo di ottetti, diciamo N, che devono essere aggiunti come suffisso al testo semplice per portarlo fino a un multiplo della dimensione del blocco. Presumeremo che la dimensione del blocco è di B ottetti cosicché N è nell'intervallo da 1 a B. Riempire aggiungendo come suffisso al testo semplice N-1 byte arbitrari di riempimento e un byte finale il valore del quale sia N. In decifrazione, basta prendere l'ultimo byte e, dopo averne verificato la correttezza, tagliar via quei byte dalla fine dl testo cifrato decrittografato.

FPer esempio, presumiamo una dimensione di blocco di 8 byte e il testo semplice di 0x616263. Il testo semplice riempito sarebbe quindi 0x616263????????05 dove i bute "??" posono essere qualsiasi valore. In modo simile, il testo semplice di 0x2122232425262728 sarebbe riempito fino a 0x2122232425262728??????????????08.

5.2.1 Triple DES

Identificatore:

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

ANSI X9.52 [TRIPLEDES] specifica tre operazioni FIPS 46-3 [DES] sequenziali. La crittografia XML TRIPLEDES consiste di una cifratura DES, una decifrazione DES, e una cifratua DES usata in modalità Cifratura a Blocchi Concatenante {Cipher Block Chaining} (CBC) con 192 bit di chiave e un Vettore di Inizializzazione (IV) a 64 bit. Dei bit della chiave, i primi 64 vengono usati nella prima operaiozne DES, i secondi 64 bit nell'operazione DES mediana, e i terzi 64 bit nell'ultima operazione DES.

Nota: Ognuno di questi 64 bit della chiave cotengono 56 bit effettivi e 8 bit di arità. In tal modo ci sono solo 168 bit operativi sui 192 che sono trasportati per una chiave TRIPLEDES. (A seconda del criterio utilizzato per l'analisi, si potrebbe pensare che la robustezza effettiva della chiave sia di 112 bit (dovuti per gli attacchi mediani) o anche meno.)

Al testo cifrato risultante viene aggiunto come prefisso l'IV. Se incluso nell'XML in uscita, è codificata in base64. Un esempio di EncryptionMethod TRIPLEDES è il seguente:

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

5.2.2 AES

Identificatore:

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

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

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

[AES] viene usato nella modalità Cifratura a Blocchi Concatenante (CBC) con un vettore di inizializzazione (IV) a 128 bit. Al testo cifrato risultante viene aggiunto come prefisso l'IV. Se incluso nell'XML in uscita, allora viene codificato in base64. Un esempio di EncryptionMethod AES è il seguente:

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

5.3 Algoritmi di Crittografia a Flusso

SGli algoritmi semplici di crittografia a flusso generano, in base alla ciave, un flusso di byte che sono sottoposti a XOR contro i dati del testo semplice per produrre il testo cifrato in cifratura e con i byte del testo cifrato per produrre testo semplice in decifrazione- Normalmente vengono usati per la crittografia dei dati e sono specificati dal valore dell'attributo Algorithm del figlio EncryptionMethod di un elemento EncryptedData.

NOTA: È critico che ogni chiave di cifratura a flusso semplice (o la chiave e il vettore di inizializzazione (IV) se viene usato anche un IV) venga usato una sola volta. Se la stessa chiave (o chiave e IV) è stata mai utilizzata per due messaggi allora, sottoponendo a XOR i due testi cifrati, si può ottenere il risultato XOR dei due testi semplici. Ciò di solito è parecchio compromettente.

Nessun algoritmo a flusso particolare è specificato nella presente ma questa sezione viene inserita per fornire linee guida generali.

SGli algoritmi a flusso tipicamente utilzzano il parametro esplicito facoltativo KeySize. Nei casi in cui la dimensione di chiave non è evidente dall'URI dell'algoritmo o dall'origine della chiave, come nell'uso dei metodi di accordo sulla chiave, questo parametro imposta la dimensione di chiave. Se la dimensione della chiave da usarsi è evidente e non concorda con il parametro KeySize, DEVE essere restituito un errore. L'implemetazione di qualsiasi algoritmo a flusso è facoltativa. lo schema per il parametro KeySize è il seguente:

  Definizione di Schema:

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

5.4 Trasporto della Chiave

KGli algoritmi di trsporto della chiave sono algoritmi di crittoagrafia a chiave pubblica specifici in particlar modo per cifrare e decifrare le chiavi. I loro identificaotri compaiono come attributi Algorithm degli elementi EncryptionMethod che sono figli di EncryptedKey. EncryptedKey è a turno il figlio di un elemento ds:KeyInfo. Il tipo della chiave che deve essere trasportata, sarebbe a dire l'algoritmo che è previsto utilizzi la chiave trasportata, viene dato dallattributo Algorithm del figlio EncryptionMethod del genitore EncryptedData o EncryptedKey di questo elemento ds:KeyInfo.

(Gli algoritmi di trasporto della chiave potrebbero facoltativamente essere usati per cifrare i dati nel qual caso essi compaiono direttamente come attributo Algorithm di un figlio EncryptionMethod di un elemento EncryptedData. Poiché usano di algoritmi a chiave pubblica in modo diretto, gi algoritmi per il Trasporto di Chiave non sono efficienti per il trasporto di qualsiasi quantitativo di dati significativamente maggiore delle chiavi simmetriche.)

TL'algoritmo di trasporto di Chiave RSA v1.5 fornito qui sotto è quello usato in congiunzione con TRIPLEDES e la Sintassi di Messaggio Crittografico {Cryptographic Message Syntax} (CMS) del S/MIME [CMS-Algorithms]. L'algoritmo di Trasporto di Chiave RSA v2 fornito qui sotto è quello usato in congiunzione con AES e CMS [AES-WRAP].

5.4.1 RSA Versione 1.5

Identificatore:

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

TL'algoritmo RSAES-PKCS1-v1_5, specificato in RFC 2437 [PKCS1], non accetta parametri espliciti. Un esempio di un elemento EncryptionMethod RSA Version 1.5 è:

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

TIl CipherValue per una tale chiave cifrata è la codifica [MIME] in base64 della stringa di ottetti calcolata come per RFC 2437 [PKCS1, sezione 7.2.1: Operazione di Cifratura]. Come specificato nella funzione EME-PKCS1-v1_5 della RFC 2437 [PKCS1, sezione 9.1.2.1], il valore in ingresso della funzione per il trasporto di chiave è il seguente:

   CRYPT ( PAD ( KEY ))

dove il riempimento è in una delle forme speciali che seguono:

   02 | PS* | 00 | key

dove "|" sta per concatenazione, "02" e "00" sono ottetti fissi del corrispondente valore esadecimale, PS è una stringa di ottetti forti pseudo-casuali [RANDOM] lunghi almeno otto ottetti, contenenti ottetti non zero, e lunghi abbastanza perché il valore della quantità da cifrata on la funzione CRYPT è di un solo ottetto più corto del modulo RSA, e la "chiave" è la chiave da trasportarsi. La chiave è a 192 bit per TRIPLEDES e 128, 192, o 256 bit per AES. È OBBLIGATORIO implementare il supporto di questo algoritmo di trasporto di chiave per trasportare chiavi a 192 bit. È FACOLTATIVO il supporto di questo algoritmo per trasportare altre chiavi. RSA-OAEP è RACCOMANDATO per il trasporto di chiavi AES.

La stringa [MIME] in base64 risultante è il valore del nodo di testo figlio dell'elemento CipherData element, ad es.

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

5.4.2 RSA-OAEP

Identificatore:

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

L'algoritmo RSAES-OAEP-ENCRYPT, come specificato in RFC 2437 [PKCS1], accetta tre parametri. I due parametri specificati dall'utente sono una funzione OBBLIGATORIA di digest di messaggio e una stringa OAEPparams FACOLTATIVA di ottetti codificata. La funzione di digest di messaggio viene indicata dall'attributo Algorithm di un elemento figlio ds:DigestMethod e la funzione di generazione maschera, il terzo parametro, è sempre MGF1 con SHA1 (mgf1SHA1Identifier). Sia la funzione per il digest di messaggio che per la generazione maschera vengono usati nell'operazione EME-OAEP-ENCODE come parte di RSAES-OAEP-ENCRYPT. La stringa di ottetti codificata è la decodifica in base64 del contenuto di un elemento figlio OAEPparams facoltativo . Se non viene fornito alcun figlio OAEPparams, viene usata una stringa nulla.

Definizione di Schema:
     <!-- use these element types as children of EncryptionMethod
          when used with RSA-OAEP -->
     <element name='OAEPparams' minOccurs='0' type='base64Binary'/>
     <element ref='ds:DigestMethod' minOccurs='0'/>

Un esempio di un elemento 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>

Il CipherValue per una chiave cifrata RSA-OAEP è una codifica [MIME] in base64 della stringa di ottetti calcolata come per RFC 2437 [PKCS1, sezione 7.1.1: Operazione di crittografia]. Come descritto nella funzione EME-OAEP-ENCODE RFC 2437 [PKCS1, sezione 9.1.1.1], il valore in ingresso per la funzione della chiave di trasporto è calcolata utilizzando la funzione del digest di messaggio e la stringa specificata negli elementi DigestMethod e OAEPparams e utilizzando la funzione di generazione maschera MGF1 (con SHA1) specificata in RFC 2437. La lunghezza desiderata in uscita per EME-OAEP-ENCODE è di un byte più breve del modulo RSA.

TLa dimensione della chiave di trasporto è di 192 bit per TRIPLEDES e 128, 192, o 256 per AES. Le implementazioni DEVONO implementare RSA-OAEP per il trasporto di chiavi a 128 e 256 bit. Esse HANNO FACOLTÀ di implementare RSA-OAEP per il trasporto di altre chiavi.

5.5 Accordo sulla Chiave

AUn algoritmo di Accordo sulla Chiave fornisce la derivazione di una chiave segreta condivisa basata su una segreta condivisa calcolata a partire da certi tipi di chiavi pubbliche compatibili sia per il mittente che per il destinatario. Le informazioni dal soggetto originario per determinare il segreto vengono indicate da un parametro OriginatorKeyInfo facoltativo figlio di un elemento AgreementMethod mentre quelle associate al destinatario vengono indicate da un RecipientKeyInfo facoltativo. Una chiave condivisa deriva da questo segreto condiviso tramite un metodo determinato dall'algoritmo di Accordo sulla Chiave.

Nota: la Crittografia XML non fornisce un protocollo di negoziazione in linea per l'accordo sulla chiave. L'elemento AgreementMethod può essere usato dal soggetto originario per identificare le chiavi e la procedura di calcolo che è stata usata per ottenere la chiave di cifratura condivisa. Il metodo utilizzato per ottenere o selezionare le chiavi o l'algoritmo usati per la computazione dell'accordo va al di là dell'ambito di questa specifica.

TL'elemento AgreementMethod compare come il contenuto di un ds:KeyInfo dal momento che, come gli altri figli ds:KeyInfo, esso produce una chiave. Questo ds:KeyInfo è di volta in volta un figlio di un elemento EncryptedData o di un elemento EncryptedKey. L'attributo Algorithm e il figlio KeySize dell'elemento EncryptionMethod sotto questo elemento EncryptedData o EncryptedKey sono parametri impliciti per la computazione dell'accordo sulla chiave. Nei casi in cui questo URI di algoritmo EncryptionMethod sia insufficiente a determinare la lunghezza della chiave, DEVE essere stato incluso un KeySize. In aggiunta, il mittente potrebbe collocare un elemento KA-Nonce sotto AgreementMethod per assicurare che il differente materiale di manipolazione delle chiavi sia generao perfino per accordi reiterati usando le chiavi pubbliche degli stessi mittenti e destinatari. Per esempio:

 <EncryptedData>
   <EncryptionMethod Algorithm="Example:Block/Alg"
     <KeySize>80</KeySize>
   </EncryptionMethod>
   <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
     <AgreementMethod Algorithm="example:Agreement/Algorithm">
       <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>

Se si sta usando la chiave concordata per coprire una chiave, piuttosto che i dati come sopra, allora dovrebbe comparire AgreementMethod all'interno di un ds:KeyInfo dentro un elemento EncryptedKey.

Lo Schema per AgreementMethod è il seguente:

  Definizione di Schema:

  <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 Valori di Chiave Diffie-Hellman

Identificatore:

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

Le chiavi Diffie-Hellman possono comparire direttamente dentro agli elementi KeyValue o essere ottenuti dai risultati di ds:RetrievalMethod come pure possono comparire nei certificati e simili. L'identificatore di cui sopra si può utilizzare come il valore dell'attributo Type degli elementi Reference o ds:RetrievalMethod.

Come specificato in [ESDH], un chiave pubblica DH consiste di fino a sei quantità, due grandi numeri primi p e q, un "generatore" g, la chiave pubblica, e i parametri di convalida "seed" e "pgenCounter". Questi si relazionano come segue: La chiave pubblica = ( g**x mod p ) dove x è la chiave privata corrispondente; p = j*q + 1 dove j >= 2. "seed" e "pgenCounter" sono facoltativi e possono essere usati per determinare se la chiave Diffie-Hellman è stata generata in conformità all'algroitmo specificato in [ESDH]. Poiché i numeri primi e il generatore possono essere condivisi in sicurezza con molte chiavi DH, esse potrebbero essere conosciute dall'ambiente applicativo e sono facoltative. lo schema per un DHKeyValue è il seguente:

  Definizione di Schema:

  <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 Diffie-Hellman Key Agreement

Identifier:

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

The Diffie-Hellman (DH) key agreement protocol [ESDH] involves the derivation of shared secret information based on compatible DH keys from the sender and recipient. Two DH public keys are compatible if they have the same prime and generator. If, for the second one, Y = g**y mod p, then the two parties can calculate the shared secret ZZ = ( g**(x*y) mod p ) even though each knows only their own private key and the other party's public key. Leading zero bytes MUST be maintained in ZZ so it will be the same length, in bytes, as p. The size of p MUST be at least 512 bits and g at least 160 bits. There are numerous other complex security considerations in the selection of g, p, and a random x as described in [ESDH].

Diffie-Hellman key agreement is optional to implement. An example of a DH AgreementMethod element is as follows:

  <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>

Assume the Diffie-Hellman shared secret is the octet sequence ZZ. The shared keying material needed will then be calculated as follows:

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

where "|" is byte stream concatenation and

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

DigestAlg

The message digest algorithm specified by the DigestMethod child of AgreementMethod.

EncryptionAlg

The URI of the encryption algorithm, including possible key wrap algorithms, in which the derived keying material is to be used ("Example:Block/Alg" in the example above), not the URI of the agreement algorithm. This is the value of the Algorithm attribute of the EncryptionMethod child of the EncryptedData or EncryptedKey grandparent of AgreementMethod.

KA-Nonce

The base64 decoding the content of the KA-Nonce child of AgreementMethod, if present. If the KA-Nonce element is absent, it is null.

Counter

A one byte counter starting at one and incrementing by one. It is expressed as two hex digits where letters A through F are in upper case.

KeySize

The size in bits of the key to be derived from the shared secret as the UTF-8 string for the corresponding decimal integer with only digits in the string and no leading zeros. For some algorithms the key size is inherent in the URI. For others, such as most stream ciphers, it must be explicitly provided.

For example, the initial (KM(1)) calculation for the EncryptionMethod of the Key Agreement example (section 5.5) would be as follows, where the binary one byte counter value of 1 is represented by the two character UTF-8 sequence 01, ZZ is the shared secret, and "foo" is the base64 decoding of "Zm9v".

  SHA-1 ( ZZ01Example:Block/Algfoo80 )

Assuming that ZZ is 0xDEADBEEF, that would be

  SHA-1( 0xDEADBEEF30314578616D706C653A426C6F636B2F416C67666F6F3830 )

whose value is

  0x534C9B8C4ABDCB50038B42015A181711068B08C1

Each application of DigestAlg for successive values of Counter will produce some additional number of bytes of keying material. From the concatenated string of one or more KM's, enough leading bytes are taken to meet the need for an actual key and the remainder discarded. For example, if DigestAlg is SHA-1 which produces 20 octets of hash, then for 128 bit AES the first 16 bytes from KM(1) would be taken and the remaining 4 bytes discarded. For 256 bit AES, all of KM(1) suffixed with the first 12 bytes of KM(2) would be taken and the remaining 8 bytes of KM(2) discarded.

5.6 Symmetric Key Wrap

Symmetric Key Wrap algorithms are shared secret key encryption algorithms especially specified for encrypting and decrypting symmetric keys. Their identifiers appear as Algorithm attribute values to EncryptionMethod elements that are children of EncryptedKey which is in turn a child of ds:KeyInfo which is in turn a child of EncryptedData or another EncryptedKey. The type of the key being wrapped is indicated by the Algorithm attribute of EncryptionMethod child of the parent of the ds:KeyInfo grandparent of the EncryptionMethod specifying the symmetric key wrap algorithm.

5.6.1 CMS Key Checksum

Some key wrap algorithms make use of a key checksum as defined in CMS [CMS-Wrap]. The algorithm that provides an integrity check value for the key being wrapped is:

1. Compute the 20 octet SHA-1 hash on the key being wrapped.
2. Use the first 8 octets of this hash as the checksum value.

5.6.2 CMS Triple DES Key Wrap

Identifiers and Requirements:

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

XML Encryption implementations MUST support TRIPLEDES wrapping of 168 bit keys and may optionally support TRIPLEDES wrapping of other keys.

An example of a TRIPLEDES Key Wrap EncryptionMethod element is as follows:

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

The following algorithm wraps (encrypts) a key (the wrapped key, WK) under a TRIPLEDES key-encryption-key (KEK) as adopted from [CMS-Algorithms]:

1. Represent the key being wrapped as an octet sequence. If it is a TRIPLEDES key, this is 24 octets (192 bits) with odd parity bit as the bottom bit of each octet.
2. Compute the CMS key checksum (section 5.6.1) call this CKS.
3. Let WKCKS = WK || CKS, where || is concatenation.
4. Generate 8 random octets [RANDOM] and call this IV.
5. Encrypt WKCKS in CBC mode using KEK as the key and IV as the initialization vector. Call the results TEMP1.
6. Let TEMP2 = IV || TEMP1.
7. Reverse the order of the octets in TEMP2 and call the result TEMP3.
8. Encrypt TEMP3 in CBC mode using the KEK and an initialization vector of 0x4adda22c79e82105. The resulting cipher text is the desired result. It is 40 octets long if a 168 bit key is being wrapped.

The following algorithm unwraps (decrypts) a key as adopted from [CMS-Algorithms]:

1. Check if the length of the cipher text is reasonable given the key type. It must be 40 bytes for a 168 bit key and either 32, 40, or 48 bytes for a 128, 192, or 256 bit key. If the length is not supported or inconsistent with the algorithm for which the key is intended, return error.
2. Decrypt the cipher text with TRIPLEDES in CBC mode using the KEK and an initialization vector (IV) of 0x4adda22c79e82105. Call the output TEMP3.
3. Reverse the order of the octets in TEMP3 and call the result TEMP2.
4. Decompose TEMP2 into IV, the first 8 octets, and TEMP1, the remaining octets.
5. Decrypt TEMP1 using TRIPLEDES in CBC mode using the KEK and the IV found in the previous step. Call the result WKCKS.
6. Decompose WKCKS. CKS is the last 8 octets and WK, the wrapped key, are those octets before the CKS.
7. Calculate a CMS key checksum (section 5.6.1) over the WK and compare with the CKS extracted in the above step. If they are not equal, return error.
8. WK is the wrapped key, now extracted for use in data decryption.

5.6.3 AES KeyWrap

Identifiers and Requirements:

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

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

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

Implementation of AES key wrap is described below, as suggested by NIST. It provides for confidentiality and integrity. This algorithm is defined only for inputs which are a multiple of 64 bits. The information wrapped need not actually be a key. The algorithm is the same whatever the size of the AES key used in wrapping, called the key encrypting key or KEK. The implementation requirements are indicated below.

128 bit AES Key Encrypting Key

Implementation of wrapping 128 bit keys REQUIRED.
Wrapping of other key sizes OPTIONAL.

192 bit AES Key Encrypting Key

All support OPTIONAL.

256 bit AES Key Encrypting Key

Implementation of wrapping 256 bit keys REQUIRED.
Wrapping of other key sizes OPTIONAL.

Assume that the data to be wrapped consists of N 64-bit data blocks denoted P(1), P(2), P(3) ... P(N). The result of wrapping will be N+1 64-bit blocks denoted C(0), C(1), C(2), ... C(N). The key encrypting key is represented by K. Assume integers i, j, and t and intermediate 64-bit register A, 128-bit register B, and array of 64-bit quantities R(1) through R(N).

"|" represents concatentation so x|y, where x and y and 64-bit quantities, is the 128-bit quantity with x in the most significant bits and y in the least significant bits. AES(K)enc(x) is the operation of AES encrypting the 128-bit quantity x under the key K. AES(K)dec(x) is the corresponding decryption opteration. XOR(x,y) is the bitwise exclusive or of x and y. MSB(x) and LSB(y) are the most significant 64 bits and least significant 64 bits of x and y respectively.

If N is 1, a single AES operation is performed for wrap or unwrap. If N>1, then 6*N AES operations are performed for wrap or unwrap.

The key wrap algorithm is as follows:

1. If N is 1:
   • B=AES(K)enc(0xA6A6A6A6A6A6A6A6|P(1))
   • C(0)=MSB(B)
   • C(1)=LSB(B)
   If N>1, perform the following steps:
2. Initialize variables:
   • Set A to 0xA6A6A6A6A6A6A6A6
   • Fori=1 to N,
     R(i)=P(i)
3. Calculate intermediate values:
   • Forj=0 to 5,
     • For i=1 to N,
       t= i + j*N
B=AES(K)enc(A|R(i))
A=XOR(t,MSB(B))
R(i)=LSB(B)
4. Output the results:
   • Set C(0)=A
   • For i=1 to N,
     C(i)=R(i)

The key unwrap algorithm is as follows:

1. If N is 1:
   • B=AES(K)dec(C(0)|C(1))
   • P(1)=LSB(B)
   • If MSB(B) is 0xA6A6A6A6A6A6A6A6, return success. Otherwise, return an integrity check failure error.
   If N>1, perform the following steps:
2. Initialize the variables:
   • A=C(0)
   • For i=1 to N,
     R(i)=C(i)
3. Calculate intermediate values:
   • For j=5 to 0,
     • For i=N to 1,
       t= i + j*N
B=AES(K)dec(XOR(t,A)|R(i))
A=MSB(B)
R(i)=LSB(B)
4. Output the results:
   • For i=1 to N,
     P(i)=R(i)
   • If A is 0xA6A6A6A6A6A6A6A6, return success. Otherwise, return an integrity check failure error.

For example, wrapping the data 0x00112233445566778899AABBCCDDEEFF with the KEK 0x000102030405060708090A0B0C0D0E0F produces the ciphertext of 0x1FA68B0A8112B447, 0xAEF34BD8FB5A7B82, 0x9D3E862371D2CFE5.

5.7 Message Digest

Message digest algorithms can be used in AgreementMethod as part of the key derivation, within RSA-OAEP encryption as a hash function, and in connection with the HMAC message authentication code method as described in [XML-DSIG].)

5.7.1 SHA1

Identifier:

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

The SHA-1 algorithm [SHA] takes no explicit parameters. An example of an SHA-1 DigestMethod element is:

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

A SHA-1 digest is a 160-bit string. The content of the DigestValue element shall be the base64 encoding of this bit string viewed as a 20-octet octet stream. For example, the DigestValue element for the message digest:

   A9993E36 4706816A BA3E2571 7850C26C 9CD0D89D

from Appendix A of the SHA-1 standard would be:

   <DigestValue>qZk+NkcGgWq6PiVxeFDCbJzQ2J0=</DigestValue>

5.7.2 SHA256

Identifier:

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

The SHA-256 algorithm [SHA] takes no explicit parameters. An example of an SHA-256 DigestMethod element is:

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

A SHA-256 digest is a 256-bit string. The content of the DigestValue element shall be the base64 encoding of this bit string viewed as a 32-octet octet stream.

5.7.3 SHA512

Identifier:

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

The SHA-512 algorithm [SHA] takes no explicit parameters. An example of an SHA-512 DigestMethod element is:

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

A SHA-512 digest is a 512-bit string. The content of the DigestValue element shall be the base64 encoding of this bit string viewed as a 64-octet octet stream.

5.7.4 RIPEMD-160

Identifier:

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

The RIPEMD-160 algorithm [RIPEMD-160] takes no explicit parameters. An example of an RIPEMD-160 DigestMethod element is:

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

A RIPEMD-160 digest is a 160-bit string. The content of the DigestValue element shall be the base64 encoding of this bit string viewed as a 20-octet octet stream.

5.8 Message Authentication

Identifier:

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

XML Signature [XML-DSIG] is OPTIONAL to implement for XML encryption applications. It is the recommended way to provide key based authentication.

5.9 Canonicalization

A Canonicalization of XML is a method of consistently serializing XML into an octet stream as is necessary prior to encrypting XML.

5.9.1 Inclusive Canonicalization

Identifiers:

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

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

Canonical XML [Canon] is a method of serializing XML which includes the in scope namespace and xml namespace attribute context from ancestors of the XML being serialized.

If XML is to be encrypted and then later decrypted into a different environment and it is desired to preserve namespace prefix bindings and the value of attributes in the "xml" namespace of its original environment, then the canonical XML with comments version of the XML should be the serialization that is encrypted.

5.9.2 Exclusive Canonicalization

Identifiers:

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

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

Exclusive XML Canonicalization [Exclusive] serializes XML in such a way as to include to the minimum extent practical the namespace prefix binding and xml namespace attribute context inherited from ancestor elements.

It is the recommended method where the outer context of a fragment which was signed and then encrypted may be changed. Otherwise the validation of the signature over the fragment may fail because the canonicalization by signature validation may include unnecessary namespaces into the fragment.

6 Security Considerations

6.1 Relationship to XML Digital Signatures

The application of both encryption and digital signatures over portions of an XML document can make subsequent decryption and signature verification difficult. In particular, when verifying a signature one must know whether the signature was computed over the encrypted or unencrypted form of elements.

A separate, but important, issue is introducing cryptographic vulnerabilities when combining digital signatures and encryption over a common XML element. Hal Finney has suggested that encrypting digitally signed data, while leaving the digital signature in the clear, may allow plaintext guessing attacks. This vulnerability can be mitigated by using secure hashes and the nonces in the text being processed.

In accordance with the requirements document [EncReq] the interaction of encryption and signing is an application issue and out of scope of the specification. However, we make the following recommendations:

1. When data is encrypted, any digest or signature over that data should be encrypted. This satisfies the first issue in that only those signatures that can be seen can be validated. It also addresses the possibility of a plaintext guessing vulnerability, though it may not be possible to identify (or even know of) all the signatures over a given piece of data.
2. Employ the "decrypt-except" signature transform [XML-DSIG-Decrypt]. It works as follows: during signature transform processing, if you encounter a decrypt transform, decrypt all encrypted content in the document except for those excepted by an enumerated set of references.

Additionally, while the following warnings pertain to incorrect inferences by the user about the authenticity of information encrypted, applications should discourage user misapprehension by communicating clearly which information has integrity, or is authenticated, confidential, or non-repudiable when multiple processes (e.g., signature and encryption) and algorithms (e.g., symmetric and asymmetric) are used:

1. When an encrypted envelope contains a signature, the signature does not necessarily protect the authenticity or integrity of the ciphertext [Davis] .
2. While the signature secures plaintext it only covers that which is signed, recipients of encrypted messages must not infer integrity or authenticity of other unsigned information (e.g., headers) within the encrypted envelope, see [XML-DSIG, 8.1.1 Only What is Signed is Secure].

6.2 Information Revealed

Where a symmetric key is shared amongst multiple recipients, that symmetric key should only be used for the data intended for all recipients; even if one recipient is not directed to information intended (exclusively) for another in the same symmetric key, the information might be discovered and decrypted.

Additionally, application designers should be careful not to reveal any information in parameters or algorithm identifiers (e.g., information in a URI) that weakens the encryption.

6.3 Nonce and IV (Initialization Value or Vector)

An undesirable characteristic of many encryption algorithms and/or their modes is that the same plaintext when encrypted with the same key has the same resulting ciphertext. While this is unsurprising, it invites various attacks which are mitigated by including an arbitrary and non-repeating (under a given key) data with the plaintext prior to encryption. In encryption chaining modes this data is the first to be encrypted and is consequently called the IV (initalization value or vector).

Different algorithms and modes have further requirements on the characteristic of this information (e.g., randomness and secrecy) that affect the features (e.g., confidentiality and integrity) and their resistence to attack.

Given that XML data is redundant (e.g., Unicode encodings and repeated tags ) and that attackers may know the data's structure (e.g., DTDs and schemas) encryption algorithms must be carefully implemented and used in this regard.

For the Cipher Block Chaining (CBC) mode used by this specification, the IV must not be reused for any key and should be random, but it need not be secret. Additionally, under this mode an adversary modifying the IV can make a known change in the plain text after decryption. This attack can be avoided by securing the integrity of the plain text data, for example by signing it.

6.4 Denial of Service

This specification permits recursive processing. For example, the following scenario is possible: EncryptedKey A requires EncryptedKey B to be decrypted, which itself requires EncryptedKey A! Or, an attacker might submit an EncryptedData for decryption that references network resources that are very large or continually redirected. Consequently, implementations should be able to restrict arbitrary recursion and the total amount of processing and networking resources a request can consume.

6.5 Unsafe Content

XML Encryption can be used to obscure, via encryption, content that applications (e.g., firewalls, virus detectors, etc.) consider unsafe (e.g., executable code, viruses, etc.). Consequently, such applications must consider encrypted content to be as unsafe as the unsafest content transported in its application context. Consequently, such applications may choose to (1) disallow such content, (2) require access to the decrypted form for inspection, or (3) ensure that arbitrary content can be safely processed by receiving applications.

7 Conformance

An implementation is conformant to this specification if it successfully generates syntax according to the schema definitions and satisfies all MUST/REQUIRED/SHALL requirements, including algorithm support and processing. Processing requirements are specified over the roles of decryptor, encryptor, and their calling application.

8 XML Encryption Media Type

8.1 Introduction

XML Encryption Syntax and Processing [XML-Encryption] specifies a process for encrypting data and representing the result in XML. The data may be arbitrary data (including an XML document), an XML element, or XML element content. The result of encrypting data is an XML Encryption element which contains or references the cipher data.

The application/xenc+xml media type allows XML Encryption applications to identify encrypted documents. Additionally it allows applications cognizant of this media-type (even if they are not XML Encryption implementations) to note that the media type of the decrypted (original) object might be a type other than XML.

8.2 application/xenc+xml Registration

This is a media type registration as defined in Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures [MIME-REG]

MIME media type name: application

MIME subtype name: xenc+xml

Required parameters: none

Optional parameters: charset

The allowable and recommended values for, and interpretation of the charset parameter are identical to those given for 'application/xml' in section 3.2 of RFC 3023 [XML-MT].

Encoding considerations:

The encoding considerations are identical to those given for 'application/xml' in section 3.2 of RFC 3023 [XML-MT].

Security considerations:

See the [XML-Encryption] Security Considerations section.

Interoperability considerations: none

Published specification: [XML-Encryption]

Applications which use this media type:

XML Encryption is device-, platform-, and vendor-neutral and is supported by a range of Web applications.

Additional Information:

Magic number(s): none

Although no byte sequences can be counted on to consistently identify XML Encryption documents, they will be XML documents in which the root element's QName's LocalPart is 'EncryptedData' or 'EncryptedKey' with an associated namespace name of 'http://www.w3.org/2001/04/xmlenc#'. The application/xenc+xml type name MUST only be used for data objects in which the root element is from the XML Encryption namespace. XML documents which contain these element types in places other than the root element can be described using facilities such as [XML-schema].

File extension(s): .xml

Macintosh File Type Code(s): "TEXT"

Person & email address to contact for further information:

Joseph Reagle <reagle@w3.org>

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

Intended usage: COMMON

Author/Change controller:

The XML Encryption specification is a work product of the World Wide Web Consortium (W3C) which has change control over the specification.

9 Schema and Valid Examples

Schema

xenc-schema.xsd

Example

enc-example.xml (not cryptographically valid but excercises much of the schema)

10 References

TRIPLEDES

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

AES

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

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

AES-WRAP

RFC3394: Advanced Encryption Standard (AES) Key Wrap Algorithm. J. Schaad and R. Housley. Informational, September 2002.

CMS-Algorithms

RFC3370: Cryptographic Message Syntax (CMS) Algorithms. R. Housley. Informational, February 2002.

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

CMS-Wrap

RFC3217: Triple-DES and RC2 Key Wrapping. R. Housley. Informational, December 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). October 1999.

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

EncReq

XML Encryption Requirements. J. Reagle. W3C Note, March 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. Informational, May 2000.

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

HMAC

RFC 2104: HMAC: Keyed-Hashing for Message Authentication. H. Krawczyk, M. Bellare, and R. Canetti. Informational, February 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, and T. Berners-Lee. Standards Track, June 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, March 1997.

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

MD5

RFC 1321: The MD5 Message-Digest Algorithm. R. Rivest. Informational, April 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, November 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, and J. Postel. Best Current Practice, November 1996.

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

NFC

TR15, Unicode Normalization Forms. M. Davis and M. Dürst. Revision 18: November 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 and B. LaMacchia. Aug 2000.

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

prop2

Another proposal of XML Encryption. T. Imamura. Aug 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, and E. Simon. December 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 and J. Staddon. Informational, October 1998.

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

RANDOM

RFC 1750: Randomness Recommendations for Security. D. Eastlake, S. Crocker, and J. Schiller. Informational, December 1994.

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

RIPEMD-160

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

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

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

SHA

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

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

Secure Hash Standard. NIST Draft FIPS 180-2. 2001. (Extended to include SHA-384, SHA-256, and SHA-512)

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

Tobin

R. Tobin. Infoset for external entities, XML Core mailing list, 2000 [W3C Member Only].

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 and F. Yergeau. Informational, February 2000.

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

UTF-8

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

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

URI

RFC 2396: Uniform Resource Identifiers (URI): Generic Syntax. T. Berners-Lee, R. Fielding, and L. Masinter. Standards Track, August 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. June 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

Extensible Markup Language (XML) 1.0 (Second Edition). T. Bray, J. Paoli, C. M. Sperberg-McQueen, and E. Maler. W3C Recommendation, October 2000.

XML-Base

XML Base. J. Marsh. W3C Recommendation, June 2001.

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

XML-C14N

Canonical XML. J. Boyer. W3C Recommendation, March 2001.

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

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

XML-exc-C14N

Exclusive XML Canonicalization. J. Boyer, D. Eastlake, and J. Reagle. W3C Recommendation, July 2002.

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

XML-DSIG

XML-Signature Syntax and Processing. D. Eastlake, J. Reagle, and D. Solo. W3C Recommendation, February 2002.

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

XML-DSIG-Decrypt

Decryption Transform for XML Signature. M. Hughes, T. Imamura and H. Maruyama. W3C Recommendation, December 2002.

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

XML-Encryption

XML Encryption Syntax and Processing. D. Eastlake and J. Reagle. W3C Candidate Recommendation, December 2002.

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

XML-Infoset

XML Information Set. J. Cowan and R. Tobin. W3C Recommendation, October 2001

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

XML-MT

RFC 3023: XML Media Types. M. Murata, S. St. Laurent, and D. Kohn. Informational, January 2001.

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

XML-NS

Namespaces in XML. T. Bray, D. Hollander, and A. Layman. W3C Recommendation, January 1999.

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

XML-schema

XML Schema Part 1: Structures D. Beech, M. Maloney, and N. Mendelsohn. W3C Recommendation, May 2001.

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

XML Schema Part 2: Datatypes. P. Biron and A. Malhotra. W3C Recommendation, May 2001.

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

XPath

XML Path Language (XPath) Version 1.0. J. Clark and S. DeRose. W3C Recommendation, October 1999.
http://www.w3.org/TR/1999/REC-xpath-19991116