Nota di Traduzione
XML Encryption Syntax and Processing
Nel tradurre questo documento, pur avendo solo l'originale valore normativo, si è cercato di attenersi il più possibile fedeli al testo inglese. A volte, per ragioni di esattezza scientifica, si è ritenuto di:
Traduttore: Daniele Gabriele. Data di pubblicazione: 10 gennaio 2005. Data di ultima revisione: 10 gennaio 2005.
Si prega di vedere gli errata per questo documento, i quali potrebbero includere alcune correzioni normative. Vedere anche le traduzioni.
Copyright © 2002 W3C® (MIT, INRIA, Keio), Tutti i Diritti Riservati. Si applicano le regole del W3C per responsabilità, marchio registrato, utilizzo del documento e licenza del software.
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.
Questo documento è la Raccomandazione (REC) del W3C per la Crittografia XML. Questo documento è stato revisionato dai Membri del W3C e da altre parti interessate ed è stato approvato dal Direttore come una Raccomandazione del W3C. È un documento definitivo e potrebbe essere utilizzato come materiale di riferimento o citato come un riferimento normativo da un altro documento. Il ruolo del W3C nel produrre la Raccomandazione è porre l'attenzione sulla specifica e promuoverne l'impiego diffuso. Ciò rafforza la funzionalità e l'interoperabilità del Web.
Questa specifica è stata prodotta dal Gruppo di Lavoro per la Crittografia XML del W3C (Attività) il quale ritiene che la specifica sia sufficiente per la creazione di implementazioni interoperabili indipendenti come dimostrato nella Relazione sull'Interoperabilità.
Rivelazioni di brevetto relative a questa specifica potrebbero trovarsi sulla pagina della rivelazione di brevetto del Gruppo di Lavoro in conformità con la politica del W3C.
Si prega di riportare gli errori in questo documento a xml-encryption@w3.org (archivio pubblico).
L'elenco degli errori conosciuti in questa specifica è disponibile presso http://www.w3.org/Encryption/2002/12-xmlenc-errata.
La versione in inglese di questa specifica è l'unica versione normativa. Informazioni sulle traduzioni di questo documento (se presenti) sono disponibili presso http://www.w3.org/Encryption/2002/12-xmlenc-translations.
Un elenco delle Raccomandazioni attuali del W3C e altri documenti tecnici possono trovarsi presso http://www.w3.org/TR/.
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.
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."
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].
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.).
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.
In aggiunta, ringraziamo di seguito per i loro interventi durante e successivamente all'Ultima Chiamata:
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.
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.
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
.
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>
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> </CipherDat
a> </EncryptedDat
a> </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.
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> </CipherDat
a> </EncryptedDat
a>
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>original
EncryptedData</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>new
EncryptedData</CipherValue> </CipherDat
a> </EncryptedDat
a> </pay:PaymentInf
o>
dove il contenuto CipherValue
di 'newEncryptedData
'
è la codifica in base64 della sequenza di ottetto criptata risultante
dallacrittografia dell'elemento EncryptedData
con Id='ED1'
.
EncryptedData
e EncryptedKey
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:KeyNam
e>
[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.
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:KeyNam
e>
[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.)
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'/>
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.
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.)
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>
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>
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>
ds:KeyInfo
Ci sono tre modi in cui si può fornire il materiale di manipolazione delle
chiavi necessario a decifrare
CipherData
:
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:
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.)
ds:KeyName
per riferirsi a un
EncryptedKey
CarriedKeyName
è RACCOMANDATO.
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).
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).
EncryptedKey
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.)
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
' />
-->
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>
EncryptionProperties
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>
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:
FPer ogni dato che deve essere crittografato come un EncryptedData
o
un
EncryptedKey
(elementi derivati da EncryptedType
), il
cifrante deve:
ds:KeyInfo
in modo appropriato (ad es.,
ds:KeyName
, ds:KeyValue
,
ds:RetrievalMethod
, etc.)
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. 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
").
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.
CipherData
all'interno di quello EncryptedType
,
allora la seuqenza di ottetti cifrata è codificata in base64 e inserita come
il contenuto di un elemento CipherValue
.
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
. 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)
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. Per ogni elemento derivato EncryptedType
, (cioé,
EncryptedData
o EncryptedKey
), che deve essere
decifrato, il
deciratore deve:
ds:KeyInfo
da usarsi. se viene omessa qualche informazione, l'applicazione
DEVE fornirla.
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.
CipherData
.
CipherValue
, allora viene
recuperato il valore testuale associato e decodificato in base64 in modo
tale da ottenere la sequenza di ottetti cifrata.
CipherReference
, l'URI e
le trasformazioni (se presenti) vengono usate per recuperare la seuqenza di
ottetti cifrata.
Type
dell' 'elemento'
o del 'contenuto'
di elemento.
Type
e i dati di carattere XML codificati in UTF-8. Il decifratore
è NON OBBLIGATO a eseguire la convalida dell'XML serializzato.
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.
Type
non è specificato o se
non è 'elemento' o 'contenuto'
di elemento.
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.
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
. 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]:
EmptyElemTag
| STag content ETag"
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].
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:
Dove X è l'insieme di nodi [XPath]
corrispondente a un documento XML ed e è un nodo di elemento
EncryptedData
in X.
EncryptedData
. Nel qual caso:
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:
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.
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.
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:
dummy
con gli attributi
di dichiarazione di namespace dichiarante tutti i namespace nel contesto di
parsing.
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>
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.
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.
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.
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.
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
.
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"/>
[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"/>
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>
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].
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>
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.
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>
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>
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
DigestMethod
child of AgreementMethod
.
EncryptionAlg
Algorithm
attribute of the
EncryptionMethod
child of the EncryptedData
or
EncryptedKey
grandparent of AgreementMethod
.
KA-Nonce
KA-Nonce
child of
AgreementMethod
, if present. If the KA-Nonce
element
is absent, it is null.
Counter
KeySize
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.
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.
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:
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]:
WKCKS = WK || CKS
, where || is concatenation.
TEMP2 = IV || TEMP1
.
TEMP2
and call the result
TEMP3
.
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]:
KEK
and an initialization vector (IV) of
0x4adda22c79e82105
. Call the output TEMP3
.
TEMP2
.
TEMP1
, the
remaining octets.
KEK
and
the IV found in the previous step. Call the result WKCKS
.
WKCKS
. CKS
is the last 8 octets and
WK
, the wrapped key, are those octets before the
CKS
.
WK
and compare with
the
CKS
extracted in the above step. If they are not equal, return
error.
WK
is the wrapped key, now extracted for use in data
decryption. 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.
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:
N
is 1
:
B=AES(K)enc(0xA6A6A6A6A6A6A6A6|P(1)
)
C(0)=MSB(B)
C(1)=LSB(B)
N>1
, perform the
following steps:
A
to 0xA6A6A6A6A6A6A6A6
i=1
to N
,R(i)=P(i)
j=0
to 5
,
i=1
to N
,t= i + j*N
B=AES(K)enc(A|R(i))
A=XOR(t,MSB(B))
R(i)=LSB(B)
C(0)=A
i=1
to N
,C(i)=R(i)
The key unwrap algorithm is as follows:
N
is 1
:
B=AES(K)dec(C(0)|C(1))
P(1)=LSB(B)
MSB(B)
is 0xA6A6A6A6A6A6A6A6
, return
success. Otherwise, return an integrity check failure error. N
>1, perform the following steps:
A=C(0)
i=1
to N
,R(i)=C(i)
j=5
to 0
,
i=N
to 1
,t= i + j*N
B=AES(K)dec(XOR(t,A)|R(i))
A=MSB(B)
R(i)=LSB(B)
i=1
to N
,P(i)=R(i)
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
.
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].)
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>
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.
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.
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.
XML Signature [XML-DSIG] is OPTIONAL to implement for XML encryption applications. It is the recommended way to provide key based authentication.
A Canonicalization of XML is a method of consistently serializing XML into an octet stream as is necessary prior to encrypting XML.
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.
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.
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:
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:
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.
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.
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.
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.
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.
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.
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'sQName
'sLocalPart
is'EncryptedData'
or 'EncryptedKey
' with an associated namespace name of 'http://www.w3.org/2001/04/xmlenc#'. Theapplication/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.