Copyright © 2001 W3C® (MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.
This document 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.
This is an editors' copy that has absolutely no standing.
This document 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
EncryptedData
element which contains (via one of its
children's content) or identifies (via a URI reference) the cipher
data.
When encrypting an XML element or element content the
EncryptedData
element replaces the element or content
(respectively) in the encrypted version of the XML document.
When encrypting an entire XML document, the
EncryptedData
element may become the root of the new
document. And when encrypting arbitrary data, the the
EncryptedData
element may become the root of a new XML
document or become a child element in an application-chosen XML
document.
This specification uses XML Schemas [XML-schema] to describe the content model.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this specification are to be interpreted as described in RFC2119 [KEYWORDS]:
"they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmissions)"
Consequently, we use these capitalized keywords to unambiguously specify requirements over protocol and application features and behavior that affect the interoperability and security of implementations. These key words are not used (capitalized) to describe XML grammar; schema definitions unambiguously describe such requirements and we wish to reserve the prominence of these terms for the natural language descriptions of protocols and features. For instance, an XML attribute might be described as being "optional." Compliance with the XML-namespace specification [XML-NS] is described as "REQUIRED."
The design philosophy and requirements of this specification are addressed in the XML Encryption Requirements document [EncReq].
No provision is made for an explicit version number in this syntax. If a future version is needed, it will use a different namespace. The experimental XML namespace [XML-NS] URI that MUST be used by implementations of this (dated) specification is:
xmlns:enc='http://www.w3.org/2001/04/xmlenc#'
Additionally, this specification makes use of the XML Signature [XMLDSIG] namespace and schema definitions
xmlns:ds='http://www.w3.org/2000/09/xmldsig#'
This namespace is also used as the prefix for algorithm identifiers used by this specification. While applications MUST support XML and XML namespaces, the use of internal entities [XML] or our "enc" XML namespace prefix and defaulting/scoping conventions are OPTIONAL; we use these facilities to provide compact and readable examples.
The contributions of the following working group members to this specification are gratefully acknowledged:
...
This section provides an overview and examples of XML Encryption syntax. The formal syntax is found in Core Encryption Syntax (section 3); the specific processing is given in Processing Rules (section 4).
Expressed in shorthand form, the EncryptedData
element has the
following structure:
<EncryptedData (Id='')? (Type='')?> <EncryptionMethod/>? <KeyInfo> <EncryptedKey/>? <KeyRetrievalMethod
/>? </KeyInf
o>? <CipherData> <CipherValue>(encrypted character data)</CipherValu
e>? <CipherReference URI=''/>? </CipherDat
a> </EncryptedDat
a>
The CipherData
element envelopes or references to
the raw encrypted data. If enveloping, the raw encrypted data is
the CipherData
element's content; if referencing, the
CipherData
element's URI
attribute points
to the location of the raw encrypted data
Consider the following fictitious payment information, which includes identification information and information approriate to a payment method (e.g., credit card, money transfer, or electronic check):
<?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>Bank of the Internet</Issuer> <Expiration>04/02</Expiration> </CreditCar
d> </PaymentInf
o>
This markup represents that John Smith's is using his credit card with a limit of $5,000USD.
Smith's credit card number is sensitive information! If the
application wishes to keep that information confidential, it can
encrypt the CreditCard
element:
<?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>A23B45C56</CipherDat
a> </EncryptedDat
a> </PaymentInf
o>
By encrypting the entire CreditCard
element from
its start to end tags, the identity of the element itself is
hidden. (An evesdropper doesn't know whether he used a credit card
or money transfer.) The CipherData
element contains
the encrypted serialization of the CreditCard
element.
As an alternative scenario, it may be useful for intermediate
agents to know that John used a credit card with a particular
limit, but not the card's number, issuer, and expiration date. In
this case, the content (character data or children elements) of the
CreditCard
element is encrypted:
<?xml version='1.0'?> <PaymentInfo xmlns='http://example.org/paymentv2'> <Name>John Smith<Name/> <CreditCard Limit='5,000' Currency='USD'> <EncryptedData Type='http://www.w3.org/2001/04/xmlenc#Content' xmlns='http://www.w3.org/2001/04/xmlenc#'> <CipherData>A23B45C56</CipherDat
a> </EncryptedDat
a> </CreditCar
d> </PaymentInf
o>
Or, consider the scenario in which all the information except the actual credit card number can be in the clear, including the fact that the Number element exists:
<?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>A23B45C56</CipherDat
a> </EncryptedDat
a> </Number> <Issuer>Bank of the Internet</Issuer> <Expiration>04/02</Expiration> </CreditCar
d> </PaymentInf
o>
Both CreditCard
and Number
are in the
clear, but the character data content of Number
is
encrypted.
If the application scenario requires all of the information to be encrypted, the whole document is encrypted as an octet set. This applies to arbitrary data including XML documents.
<?xml version='1.0'?> <EncryptedData xmlns='http://www.w3.org/2001/04/xmlenc#' Type='http://www.isi.edu/in-notes/iana/assignments/media-types/text/xml'> <CipherData>A23B45C56</CipherDat
a> </EncryptedDat
a>
An XML document may contain zero or more
EncryptedData
elements. However, EncryptedData
can not be the parent or child of another
EncryptedData
element -- though the data encrypted by this
element can be anything, including EncryptedData
and
EncryptedKey
elements (i.e., super-encryption). During
super-encryption of an EncryptedData
or
EncryptedKey
element, one must encrypt the entire element.
Encrypting only the content of these elements, or encrypting
selected child elements, will result in invalid XML against the
schema defined in this specification.
For example, consider the following:
<pay:PaymentInfo
xmlns:pay='http://example.org/paymentv2'> <EncryptedData ID='ED1' Type='http://www.w3.org/2001/04/xmlenc#Element' xmlns='http://www.w3.org/2001/04/xmlenc#'> <CipherData>original
EncryptedData</CipherDat
a> </EncryptedDat
a> </pay:PaymentInf
o>
A valid super-encryption of
'
//EncryptedData[@ID='ED1']' would be:
<pay:PaymentInfo
xmlns:pay='http://example.org/paymentv2'> <EncryptedData ID='ED2' Type='http://www.w3.org/2001/04/xmlenc#Element' xmlns='http://www.w3.org/2001/04/xmlenc#'> <CipherData>new
EncryptedData</CipherDat
a> </EncryptedDat
a> </pay:PaymentInf
o>
where 'newEncryptedData
' is the base64 encoding of
the encrypted octet sequence resulting from encrypting the
EncryptedData
element with Id='ED1'
.
EncryptedData
and EncryptedKey
UsageEncryptedData
with Symmetric
Key (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#3des-cbc '/> [s3] <KeyInfo> [s4] <ds:KeyName
xmlns:ds='http://www.w3.org/2000/09/xmldsig#'> John Smith </ds:KeyNam
e> [s5] </KeyInf
o> [s6] <CipherData>DEADBEEF</CipherDat
a> [s7] </EncryptedDat
a>
[s1]
The type of data encrypted may be represented
as an attribute value as an aid in decryption and subsequent
processing. In this case, the data encrypted was an 'Element'.
Other alternatives include 'Content' of an element, or an an
external octet sequence that is identified by a media type URI.
[s2]
This (3DES CBC) is a symmetric key cipher.
[s4-s5]
The symmetric key has the name John
Smith.
[s6]
CipherData
will always be a
base64 encoded octet sequence or a URI reference with any
transforms necessary to obtain the cipher data as an octet
sequence.
EncryptedKey
(ReferenceList
,
KeyRetrievalMethod
,CarriedKeyName
)The following EncryptedData
structure is very
similar to the one above, except this time the key is referenced
using a KeyRetrievalMethod
:
[t01] <EncryptedData Id='ED' xmlns:enc='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] <KeyRetrievalMethod
URI='#EK'/> [t05] <ds:KeyNam
e>John Doe<ds:KeyNam
e> [t06] </ds:KeyInf
o> [t07] <CipherData>DEADBEEF</CipherDat
a> [t08] </EncryptedDat
a>
[t02]
This (AES-128-CBC) is a symmetric key
cipher.
[t03]
The (AES) key is located at '#EK'.
[t04]
KeyRetrievalMethod
is analogous
to the ds:RetrievalMethod
except that the type of the
referent is always of type EncryptedKey
:
[t05]
ds:KeyName
provides an
alternative method of identifying the key needed to decrypt the
CipherData
. Either or both the KeyName
and KeyRetrivalMethod
could be used to identify the
key.
[t09] <EncryptedKey Id='EK'CarriedKeyName
="John Doe" [t10] xmlns='http://www.w3.org/2001/04/xmlenc#'> [t11] <EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/> [t12] <ds:KeyInfo
xmlns:ds='http://www.w3.org/2000/09/xmldsig#'> [t13] <ds:KeyNam
e>John Smith</ds:KeyNam
e> [t14] </ds:KeyInf
o> [t15] <CipherData>xyzabc</CipherDat
a> [t16] <ReferenceList> [t17] <DataReference URI='#ED'/> [t18] </ReferenceLis
t> [t19] </EncryptedKe
y>
[t09]
The EncryptedKey
element is
similar to the EncryptedData
element except that the
data encrypted is always a key value. The
CarriedKeyName
attribute is used to identify the encrypted
key value which may be referenced by the KeyName
element in KeyInfo
.
[t11]
The EncryptionMethod
is the RSA
public key algorithm.
[t13]
ds:KeyName
of "John Smith" is
a property of the key necessary for decrypting (using RSA) the
CipherData
.
[t15]
The CipherData
is an octet
sequence that is encoded (e.g., padded) by a referring encrypted
object's EncryptionMethod
. (Note, an EncryptedKey's
EncryptionMethod
is the algorithm used to encrypt
these octets and does not speak about what type of octets they
are.)
[t16-18]
A ReferenceList
identifies
the encrypted objects (DataReference
and
KeyReference
) encrypted with this key. The
ReferenceList
contains a list of references to data
encrypted by the symmetric key carried within this structure.
This section provides a detailed description of the syntax and features for XML Encryption. Features described in this section are mandatory to implement unless otherwise noted. The syntax is defined via [XML-Schema] with the following XML preamble, declaration, internal entity, and import:
Schema Definition:
<?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:enc CDATA #FIXED 'http://www.w3.org/2001/04/xmlenc#'
xmlns:ds CDATA #FIXED 'http://www.w3.org/2000/09/xmldsig#'>
<!ENTITY % p ''>
<!ENTITY % s ''>
]>
<schema xmlns='http://www.w3.org/2001/XMLSchema' version='0.1'
xmlns:ds='http://www.w3.org/2000/09/xmldsig#'
xmlns:enc='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/2001/CR-xmldsig-core-20010419/xmldsig-core-schema.xsd'/>
EncryptedType
EncryptedType
is the abstract type from which
EncryptedData
and EncryptedKey
are
derived. While these two latter element types are very similar with
respect to their content models, a syntactical distinction is
useful to processing.
Schema Definition: <complexType name='EncryptedType
' abstract='true'> <sequence> <element name='EncryptionMethod
' type='ds:DigestMethodType
' minOccurs='0'/> <element ref='ds:KeyInfo
' minOccurs='0'/> <element ref='enc:CipherData
'/> </sequence> <attribute name='Id' type='ID' use='optional'/> </complexType>
EncryptionMethod
is an optional element that
describes the encryption algorithm applied to the
CipherData
contained in this element. If the element is
absent, the encryption algorithm assumed to be known by the
recipient.
KeyInfo
is an optional element, defined by [XMLDSIG], that carries information about the
key used to encrypt the CipherData
. The new elements
defined by this specification that may appear a children of
KeyInfo
are described in the subsequent sections.
CipherData
is a mandatory element that provides the
encrypted data.
Id
is an optional attribute providing for the
standard method of assigning a string id to the element within the
document context.
CipherData
ElementThe CipherData
is a mandatory element that provides
the encrypted data. It must either contain the encrypted octet
sequence as base64 encoded text of the CipherValue
element, or provide a reference to an external location containing
the encrypted octet sequence via the CipherReference
element.
The optional set of ds:DigestMethod
and
ds:DigestValue
elements are provided for ensuring the
integrity of the encrypted data. See section 5.6 of the algorithm
specification for more information.
Schema Definition: <element name='CipherData
' type='enc:CipherDataType
'/> <complexType name='CipherDataType
'> <sequence> <choice> <element name='CipherValue
' type='ds:CryptoBinary
'/> <element ref='enc:CipherReference
'/> </choice> <sequence minOccurs='0'> <element ref='ds:DigestMethod
'/> <element ref='ds:DigestValue
'/> </sequence> </sequence> </complexType>
CipherReference
ElementIf CipherValue
is not supplied directly, the
CipherReference
identifies a source which, when processed,
yields data equivelent to the content of a CipherValue
element (e.g., the base64 encoded encrypted octet sequence).
The actual value is obtained as follows. The
CipherReference
URI
contains an identifer that
is dereferenced. Should the CipherReference
element
contain an OPTIONAL sequence of Transforms
, the data
resulting from deferenced URI is transformed as specified so as to
yield the intended cipher value. For example, if the value is
contained in a base64 encoded XML document; the transforms could
specify a base64 decoding of the XML document, followed by an XPath
expression to extract the literal cipher value.
The syntax of the URI
and Transform
s
is similar to that of [XMLDSIG] reference validation. However, there is a difference
between signature and encryption processing. In [XMLDSIG] both generation and validation
processing start with the same source data and perform that
transform in the same order. In encryption, the decryptor has only
the cipher data and the specified transforms are enumerated for the
decryptor, in the order necessary to obtain the cipher value.
Consequently, in XML Encryption the specified transforms should
be reversible. For instance, while an XSLT is an approriate
transform in [XMLDSIG], it may not be in
the encryption context because given a resulting document and the
XSLT used to transform it, one can't necessarily obtain the source
document. Also, note that these transforms do not affect the
generation of CipherData
, only its representation at
the designated URI. Like [XMLDSIG], the
Transforms are optional hints for resolving a information and no
mandatory requirements over their processing is expressed by this
specification.
For example, if the relevant cipher value is captured within an
Entry
element within a base64 encoded XML document,
the CipherRerence
might look as follows:
<CipherReference URI="http://www.example.com/CipherValues.xml">
<Transforms>
<Transform Algorithm="decode"/>
<Transform
Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116">
<XPath xmlns:rep="&repository;">//rep:Entry[@='3'])
</XPath>
<Transform>
</Transforms>
</CipherReferenc
e>
Schema Definition: <element name='CipherReference
' type='enc:CipherReferenceType
'/> <complexType name='CipherReferenceType
'> <choice> <element name='Transforms' minOccurs='0'/> </choice> <attribute name='URI' type='anyURI' use='required'/> </complexType> <element name="Transforms" type="ds:TransformsType"/> <complexType name="TransformsType"> <sequence> <element ref="ds:Transform" maxOccurs="unbounded"/> </sequence> </complexType>
EncryptedData
elementThe EncryptedData
element is the core element in
the syntax. Not only does its CipherData
child contain
the encrypted data, but it's also the element that replaces the
encrypted element, or serves as the new document root.
Schema Definition: <element name='EncryptedData
' type='enc:EncryptedDataType
'/> <complexType name='EncryptedDataType
'> <complexContent> <extension base='enc:EncryptedType
'> <attribute name='Type' type='anyURI' use='optional'/> </extension> </complexContent> </complexType>
Type
is an optional attribute identifying type
information about the decrypted content.
KeyInfo
ElementThere are different ways to define the key material to be used
in decrypting the CipherData
:
EncryptedData
or EncryptedKey
element specifies the associated key material:
EncryptedKey
element
KeyRetrievalMethod
element used to indicate the URI of an
EncryptedKey
or a KeyName
element used to
indicate a key known by the recipient.EncryptedKey
element specifies the
EncryptedData
or EncryptedKey
element which
needs it:
EncryptedKey
element can refer to the
EncryptedData
element via a DataReference
element.This specification defines two elements that may be used as
children of the ds:KeyInfo
element. These are the
EncryptedKey
and KeyRetrievalMethod
elements described in subsequent sections.
EncryptedKey
ElementThe EncryptedKey
element is used to transport
encryption keys from the originator to a known recipient(s). It may
be used as a standalone XML document, be placed within an
application document, or appear inside an EncryptedData element as
a child of a KeyInfo
element. The key value is always
encrypted to the recipient(s).
Schema Definition: <element name='EncryptedKey
' type='enc:EncryptedKeyType
'/> <complexType name='EncryptedKeyType
'> <complexContent> <extension base='enc:EncryptedType
'> <sequence> <element ref='enc:ReferenceList
' minOccurs='0'/> </sequence> <attribute name='CarriedKeyName
' type='string' use='optional'/> <attribute name='Recipient' type='string' use='optional'/> </extension> </complexContent> </complexType>
ReferenceList
is an optional element containing
pointers to data and keys encrypted using this key. The reference
list may contain multiple references to EncryptedKey
and EncryptedData
elements. This is done using
KeyReference
and DataReference
elements
repectively. These are defined below.
CarriedKeyName
is an optional attribute for
associating a user readable name with the key value. This may then
be used to reference the key using the ds:KeyName
element within KeyInfo
. The same
CarriedKeyName
label, unlike an ID type, may occur multiple
times within a single document. The value of the key is to be the
same in all EncryptedKey
elements identified with the
same CarriedKeyName
label within a single XML
document
Recipient
is an optional attribute that contains a
hint as to which recipient this encrypted key value is intended
for. Its contents are application dependent.
KeyRetrievalMethod
ElementThe KeyRetrievalMethod
element provides a way to
express a link to an EncryptedKey element containing the key needed
to decrypt the CipherData
associated with an
EncryptedData
or EncryptedKey
element. The
KeyRetrievalMethod
is always a child of the
ds:KeyInfo
element and may appear multiple times. If there
is more than one instance of a KeyRetievalMethod
in a
KeyInfo, then the EncryptedKey
objects referred to
must contain the same key value, possibly encrypted in different
ways or for different recipients.
Schema Definition: <element name='KeyRetrievalMethod
' type='enc:KeyRetrievalMethodType
' /> <complexType name='KeyRetrievalMethodType
'> <complexContent> <restriction base='ds:RetrievalMethodType
'> <sequence> <element name='ds:Transforms' minOccurs='0'/> </sequence> <attribute name='URI' type='anyURI'/> <attribute name='Type' type='anyURI' use='optional' fixed='http://www.w3.org/2001/04/xmlenc#EncryptedKey
' /> </restriction> </complexContent> </complexType>
KeyRetrievalMethod
uses similar syntax and
dereferencing behavior to the RetrievalMethod element in [XMLDSIG], except the type attribute is always
fixed to be of type EncryptedKey
.
ReferenceList
ElementReferenceList
is an element that contains pointers
from a key value to items encrypted by that key value
(EncryptedData
or EncryptedKey
elements).
Schema Definition: <element name='ReferenceList
'> <complexType> <sequence> <element name='DataReference
' type='enc:ReferenceType
' minOccurs='0' maxOccurs='unbounded'/> <element name='KeyReference
' type='enc:ReferenceType
' minOccurs='0' maxOccurs='unbounded'/> </sequence> </complexType> </element> <complexType name='ReferenceType
'> <sequence> <any namespace='##other' minOccurs='0' maxOccurs='unbounded'/> </sequence> <attribute name='URI' type='anyURI' use='optional'/> </complexType>
DataReference
elements are used to refer to
EncryptedData
elements that were encrypted using the key
defined in the enclosing EncryptedKey
element.
Multiple DataReference
elements can occur if multiple
EncryptedData
elements exist that are encrypted by the
same key.
KeyReference
elements are used to refer to
EncryptedKey
objects that were encrypted using the key
defined in the enclosing EncryptedKey
element.
Multiple KeyReference
elements can occur if multiple
EncryptedKey
elements exist that are encrypted by the
same key.
For both types of references one may optionally specify child
elements to aid the recipient in retrieving the
EncryptedKey
and/or EncryptedData
elements.
These could include information such as XPath transforms,
decompression transforms, or information on how to retrieve the
objects from a document storage facility.
This section describes the operations to be performed as part of encryption and decryption processing.
For each data item or key to be encrypted:
EncryptedData
structure including or
referencing the encrypted data and use it as the top-level element
in a new XML Document or insert it into another XML document (this
is processing is application dependent).For each item to be decrypted (either an
EncryptedData
or EncryptedKey
element):
CipherData
element. When the data is XML, the resulting
octets are interpretated as an UTF-8 encoded string of XML
characters representing an element or element content.EncryptedData
structure and the type
is "Element" or "ElementContent", then place the resulting
characters in place of the
EncryptedData element with the
encoding of the parent XML document if necessary. Otherwise,
the octet sequence is the final result.The specification above presumes that the data to be encrypted
is processed as an octet sequence. The application is responsible
for serializing the XML into an octet sequence that will be useful
subsequent to decryption. For instance, if the applications wishes
to canonicalize (using [XML-C14N] or
some other serialization) or encode/compress the data in an XML
packaging format, the application needs to marshal the XML
accordingly and identify the resulting type with optional the
EncryptedData
Type
attribute. The
likelihood of interoperable decryption and subsequent use will be
dependent on the decryptors support for a given type. Also, if the
data is intended to be processed both before and after decryption
(e.g., XML Signature [XMLDSIG]
validation or XSLT transform) the encryptor must be careful to
preserve information necessary for that process's success.
For interoperability purposes, the following types MUST be implemented.
EmptyElemTag
| STag
content ETag" [XML]CharData
? ((element
|
Reference | CDSect |
PI |
Comment)
CharData
?)*" [XML]MediaType
'
http://www.isi.edu/in-notes/iana/assignments/media-types/*/*'TDB
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 be know whether the signature was computed over the encrypted or unencrypted representation 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.
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:
Where a symmetric key is shared amongst multiple
recipients, its encapsulating EncryptedKey
should not
reference or be referenced by other data not intended for all of
those multiple recipients. (Kind of complex...? [Shchaad supports
removal])
Where a symmetric key is shared amongst multiple recipients, that symmetric key should *only* be used for the data intended for those multiple recipients. (Quite strong.)
...
CarriedKeyName
attribute within
EncryptedKey
element.KeyRetrievalMethod
, and just
use dsig's RetrievalMethod
with a particular type? --
Reagle
CipherData
approriate? -- SchaadReferenceList
properly fall in
EncryptedKey
given its a sibling of other "inherited"
elements? -- Schaad.
EncReq
InfoSet
LaMacchia
. Aug 09 2000.LaMacchia
, Maruyama, Schaad, Simon. December
2000.McCahill
. December 1994.