[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: FYI - XML Security Work
|
The following was received this morning from the
XML-encryption listserv. For those not subscribed to that site, this may
be interesting. For all others, I apologize for forwarding the duplicative
information.
Ralph Berwanger.
|
This document specifies processing rules for encrypting specified portions of an XML document, syntax for representing encrypted parts, and processing rules for decrypting them. The encryption can be applied to multiple elements in an XML document, each of which is contained in another element. There are three formats: embedded, embedding, and detached types. The first two manage encrypted contents and information about the encryption operation together. The last one manages them separately.
The scenarios and requirements that motivated this specification are discussed in [REQ].
This section provides an overview of the XML encryption syntax, along with some examples.
The encryption can be applied to any number of elements. An element to be encrypted is encrypted (optionally after canonicalized), encoded using base64 [MIME], and contained in an EncryptedContent element. The information about the encryption operation is contained in the Encryption element. The Encryption element has the following structure (where * denotes zero or more occurrences):
<Encryption> (EncryptionInfos) (Object)* </Encryption> |
The Encryption and EncryptedContent elements can be managed together by the Encryption element containing the EncryptedContent element as a descendant of an Object element, or they can be managed separately. The former case, the syntax used would be the embedded or embedding type and the latter case, the detached type.
Suppose the cardinfo element in the following XML document being encrypted.
<invoice xmlns="http://www.foo.com/order">
<bookorder>...</bookorder>
<payment>...</payment>
<cardinfo>
<name>Hiroshi Maruyama</name>
<expiration>04/2001</expiration>
<number>0123 4567 8901 2345</number>
</cardinfo>
</invoice>
|
The cardinfo element is encrypted with a symmetric key and represented in the embedded type as follows:
[01] <invoice xmlns="http://www.foo.com/order"> [02] <bookorder>...</bookorder> [03] <payment>...</payment> [04] <Encryption xmlns="http://www.w3.org/xmlenc"> [05] <EncryptionInfos> [06] <EncryptionInfo> [07] <CEKIdentifier> [08] <KeyName>2781363</KeyName> [09] </CEKIdentifier> [10] <EncryptedContentInfo> [11] <ContentEncryptionMethod Algorithm="http://www.w3.org/xmlenc#des-ecb-pkcs5padding" /> [12] <Reference URI="#res0"> [13] <CanonicalizationMethod Algorithm="http://www.w3.org/TR/2000/WD-xml-c14n-20000710" /> [14] </Reference> [15] </EncryptedContentInfo> [16] </EncryptionInfo> [17] </EncryptionInfos> [18] <Object> [19] <EncryptedContent Id="res0">DDAKBgNV...</EncryptedContent> [20] </Object> [21] </Encryption> [22] </invoice> |
[05-17] The EncryptionInfos element contains information for each content-encryption key. The content-encryption key may be a symmetric key shared with the recipients or a symmetric key generated randomly (which is encrypted with recipients' public keys). Here the former symmetric key is used, and so this element contains an EncryptionInfo element for the key.
[07-09] The CEKIdentifier element specifies a content-encryption key. Here a key number or some other data is specified as a key identifier. This element is optional, and if omitted, the recipients are expected to be able to identify the key based on application context information.
[11] The ContentEncryptionMethod element specifies an encryption algorithm to be applied to a content. The URI indicating the algorithm is given to the Algorithm attribute. Some algorithms require some parameters (e.g., initialization vector, or IV) and such parameters are contained in this element.
[12-14] The Reference element specifies an EncryptedContent which contains an encrypted content using the URI referencing the element. The Reference element here is referencing the EncryptedContent element contained in the Object element.
[13] The CanonicalizationMethod element specifies a canonicalization algorithm to be applied to an element before the encryption operation using the URI indicating the algorithm.
[18-20] The Object element contains EncryptedContent elements. This syntax's type is the embedded, and so the EncryptedContent element here is contained as a child.
In the previous example, a single element was encrypted with a single key. The syntax is suitable for representing multiple elements encrypted with multiple keys. But it is not efficient for representing multiple elements encrypted with a single key because it contains the same information for the key repeatedly. In these instances, the embedding syntax type should be adopted.
The name and number elements in the XML document above are encrypted with a single symmetric key and represented in the embedding type as follows:
[01] <Encryption xmlns="http://www.w3.org/xmlenc"> [02] <EncryptionInfos> [03] <EncryptionInfo> [04] <CEKIdentifier> [05] <KeyName>2781363</KeyName> [06] </CEKIdentifier> [07] <EncryptedContentInfo> [08] <ContentEncryptionMethod Algorithm="http://www.w3.org/xmlenc#des-ecb-pkcs5padding" /> [09] <Reference URI="#res0"> [10] <CanonicalizationMethod Algorithm="http://www.w3.org/TR/2000/WD-xml-c14n-20000710" /> [11] </Reference> [12] <Reference URI="#res1"> [13] <CanonicalizationMethod Algorithm="http://www.w3.org/TR/2000/WD-xml-c14n-20000710" /> [14] </Reference> [15] </EncryptedContentInfo> [16] </EncryptionInfo> [17] </EncryptionInfos> [18] <Object> [19] <invoice xmlns="http://www.foo.com/order"> [20] <bookorder>...</bookorder> [21] <payment>...</payment> [22] <cardinfo> [23] <EncryptedContent xmlns="http://www.w3.org/xmlenc" Id="res0">EyMTcwMD...</EncryptedContent> [24] <expiration>04/2001</expiration> [25] <EncryptedContent xmlns="http://www.w3.org/xmlenc" Id="res1">DVQQKewN...</EncryptedContent> [26] </cardinfo> [27] </invoice> [28] </Object> [29] </Encryption> |
[07-15] The EncryptedContentInfo element contains two Reference elements. This denotes encrypted contents referenced by them were derived with a single key and a single algorithm.
[12-20] The Object element contains the totality of the XML document, but that is not necessary. In this case, all that is contained in this element is the cardinfo element and its descendant. What is contained is left for applications.
Some applications prefer to detach information about the encryption operation from the encrypted contents. In that case, the detached syntax type should be adopted.
The cardinfo element in the XML document above is encrypted with a symmetric key and represented in the detached type as follows (where Encryption and EncryptedContent elements are contained in head and body elements, respectively):
[01] <envelope xmlns="http://www.foo.com/envelope"> [02] <head> [03] <Encryption xmlns="http://www.w3.org/xmlenc"> [04] <EncryptionInfos> [05] <EncryptionInfo> [06] <CEKIdentifier> [07] <KeyName>2781363</KeyName> [08] </CEKIdentifier> [09] <EncryptedContentInfo> [10] <ContentEncryptionMethod Algorithm="http://www.w3.org/xmlenc#des-ecb-pkcs5padding" /> [11] <Reference URL="#res0" Id="ref0"> [12] <CanonicalizationMethod Algorithm="http://www.w3.org/TR/2000/WD-xml-c14n-20000710" /> [13] </Reference> [14] </EncryptedContentInfo> [15] </EncryptionInfo> [16] </EncryptionInfos> [17] </Encryption> [18] </head> [19] <body> [20] <invoice xmlns="http://www.foo.com/order"> [21] <bookorder>...</bookorder> [22] <payment>...</payment> [23] <EncryptedContent xmlns="http://www.w3.org/xmlenc" Id="res0" URL="#ref0">DDAKBgNV...</EncryptedContent> [24] </invoice> [25] </body> [26] </envelope> |
[03-17] Because the syntax in the detached type manages Encryption and EncryptedContent elements separately, the Encryption element does not contain any Object elements.
[23] Because the syntax in the detached type does not necessarily contain Encryption and EncryptedContent elements in a same XML document, the capability for the EncryptedContent element to reference the Reference element (thereby the Encryption element) is useful for processing. The EncryptedContent element here does so.
In the examples above, elements were encrypted with symmetric keys shared with recipients. Here is another example for encrypting an element with a symmetric key generated randomly and encrypting the key with a recipient's public key. The combination of the encrypted content and the encrypted content-encryption key for a recipient is called a digital envelope for that recipient.
[01] <invoice xmlns="http://www.foo.com/order"> [02] <bookorder>...</bookorder> [03] <payment>...</payment> [04] <Encryption xmlns="http://www.w3.org/xmlenc"> [05] <EncryptionInfos> [06] <EnvelopeInfo> [07] <RecipientInfos> [08] <KeyTransRecipientInfo> [09] <RecipientIdentifier> [10] <X509Data> [11] <X509IssuerAndSerial> [12] <X509Issuer>IBM Corp. CA</X509Issuer> [13] <X509Serial>389028</X509Serial> [14] </X509IssuerAndSerial> [15] </X509Data> [16] </RecipientIdentifier> [17] <KeyEncryptionMethod Algorithm="http://www.w3.org/xmlenc#rsa" /> [18] <EncryptedKey>k0xFFH56...</EncryptedKey> [19] </KeyTransRecipientInfo> [20] </RecipientInfos> [21] <EncryptedContentInfo> [22] <ContentEncryptionMethod Algorithm="http://www.w3.org/xmlenc#des-ecb-pkcs5padding" /> [23] <Reference URI="#res0"> [24] <CanonicalizationMethod Algorithm="http://www.w3.org/TR/2000/WD-xml-c14n-20000710" /> [25] </Reference> [26] </EncryptedContentInfo> [27] </EnvelopeInfo> [28] </EncryptionInfos> [29] <Object> [30] <EncryptedContent Id="res0">DDAKBgNV...</EncryptedContent> [31] </Object> [32] </Encryption> [33] </invoice> |
[05-28] The EncryptionInfos element contains an EnvelopeInfo element. The element is used for this case instead of the EncryptionInfo element.
[07-20] The RecipientInfos contains, for each recipient, a recipient's public key and a symmetric key encrypted with the public key. For this example, there is only one recipient, and so the element contains only one KeyTransRecipientInfo element as a child.
[09-16] The RecipientIdentifier element specifies a recipient's public key. It is specified using an X.509 issuer distinguished name/serial number pair.
[17] The KeyEncryptionMethod element specifies an encryption algorithm to be applied to a symmetric key using the URI indicating the algorithm. Some algorithms require some parameters similar to the ContentEncryptionMethod element.
[18] The EncryptedKey element contains an encrypted symmetric key.
This section provides detailed syntax and processing rules for encryption and decryption. The syntax and processing rules depends on whether contents are enveloped or directly encrypted. The syntax is defined via XML Schema with the following preamble (where the target namespace is temporarily http://www.w3.org/xmlenc):
<?xml version="1.0"?>
<schema targetNamespace="http://www.w3.org/xmlenc">
xmlns="http://www.w3.org/1999/XMLSchema"
xmlns:xenc="http://www.w3.org/xmlenc">
<simpleType name="base64-encoded-binary" base="binary">
<encoding value="base64"/>
</simpleType>
|
The Encryption element is the root element, which consists of EncryptionInfos and Object elements. The Object element can be omitted, and it is not used for the detached syntax type. The Encryption element may contain an optional Id attribute which will allow it to be referenced by other objects.
<element name="Encryption">
<complexType>
<element ref="xenc:EncryptionInfos" />
<element ref="xenc:Object" minOccurs="0" maxOccurs="unbounded" />
<attribute name="Id" type="ID" use="optional" />
</complexType>
</element>
|
EncryptionInfos is an element which specifies information about the encryption operation for each content-encryption key. The element contains one or more EnvelopeInfo or EncryptionInfo elements.
<element name="EncryptionInfos">
<complexType>
<choice minOccurs="1" maxOccurs="unbounded">
<element ref="xenc:EnvelopeInfo" />
<element ref="xenc:EncryptionInfo" />
</choice>
</complexType>
</element>
|
Object is an element which contains EncryptedContent elements containing encrypted contents. The EncryptedContent element is contained as a descendant.
<element name="Object">
<complexType>
<any minOccurs="1" maxOccurs="unbounded" />
</complexType>
</element>
|
The element of a KeyInfo type specifies a key. The key is identified by a name, a value, a certificate, and so on. While this specification provides some basic elements for identifying a key, applications may define and use any mechanism through inclusion of elements from another namespace.
Multiple identifiers within the KeyInfo type must refer to the same key.
<complexType name="KeyInfo">
<choice minOccurs="1" maxOccurs="unbounded" />
<any minOccurs="1" maxOccurs="unbounded" />
<element ref="KeyName" type="string" />
<element ref="xenc:KeyValue" />
<element ref="xenc:X509Data" />
</choice>
</complexType>
|
The KeyName element contains a string value which may be used by the sender to communicate a key identifier to the recipient. Common uses of this element include a simple name for a key, a key number, a distinguished name, an email address, etc.
The KeyValue element contains the value of a key. This specification provides only an element for RSA public keys, which is defined in Section 4.1: Key Management and Key Encryption Algorithms.
<element name="KeyValue">
<complexType>
<choice>
<any minOccurs="1" maxOccurs="unbounded" />
<element ref="xenc:RSAKeyValue" />
</choice>
</complexType>
</element>
|
The X509Data element contains one or more identifiers of an X.509 certificate. Four types of identifiers are provided. Multiple identifiers about a single certificate must be grouped inside a single X509Data element.
<element name="X509Data">
<complexType>
<choice>
<sequence minOccurs="1" maxOccurs="unbounded">
<choice>
<element ref="xenc:X509IssuerSerial" />
<element name="X509SKI" type="xenc:base64-encoded-binary" />
<element name="X509SubjectName" type="string" />
</choice>
</sequence>
<element name="X509Certificate" type="xenc:base64-encoded-binary" />
</choice>
</complexType>
</element>
|
The X509IssuerSerial element contains an X.509 issuer distinguished name/serial number pair.
<element name="X509IssuerSerial">
<complexType>
<element name="X509Issuer" type="string" />
<element name="X509Serial" type="integer" />
</complexType>
</element>
|
The X509SKI element contains the value of an X.509 subject key identifier. The value is always encoded using base64 [MIME].
The X509SubjectName element contains an X.509 subject distinguished name.
The X509Certificate element contains an X.509 certificate. The certificate is always encoded using base64 [MIME].
The EncryptedContentInfo element relates a content-encryption algorithm to an encrypted content. This element contains one ContentEncryptionMethod element and multiple Reference elements.
<element name="EncryptedContentInfo">
<complexType>
<element name="xenc:ContentEncryptionMethod" />
<element name="xenc:Reference" minOccurs="1" maxOccurs="unbounded" />
</complexType>
</element>
|
ContentEncryptionMethod is an element which specifies a content-encryption algorithm applied to a content. The URI identifying the algorithm is given to the Algorithm attribute. This element uses the general structure here for algorithms specified in Section 4.2: Content Encryption Algorithms.
<element name="ContentEncryptionMethod">
<complexType>
<any minOccurs="0" maxOccurs="unbounded" />
<attribute name="Algorithm" type="uriReference" use="required" />
</complexType>
</element>
|
Reference is an element which references an EncryptedContent element containing an encrypted content. The URI referencing the element is given to the URI attribute. Alternatively, the Reference element with the Id attribute may be referenced by an EncryptedContent element. The URI attribute is optional and can be omitted if the EncryptedContent element is unambiguously identified or references the Reference element.
<element name="Reference">
<complexType>
<element ref="xenc:CanonicalizationMethod" minOccurs="0" maxOccurs="1" />
<attribute name="URI" type="uriReference" use="optional" />
<attribute name="Id" type="ID" use="optional" />
<attribute name="MimeType" type="string" use="optional" />
</complexType>
</element>
|
MimeType is an optional attribute which describes the original content referenced by this element. This is a string defined in [MIME]. For example, an original content is XML, the MimeType attribute will be given text/xml. Because contents could be elements in this specification, MIME types other than text/xml will not be specified. This attribute is advisory; no validation of the MimeType information is required by this specification.
CanonicalizationMethod is an element which specifies a canonicalization algorithm applied to a content before the encryption operation. The URI identifying the algorithm is given to the Algorithm attribute. This element uses the general structure here for algorithms specified in Section 4.3: Canonicalization Algorithms. This element is optional, and if omitted, the canonicalization operation will not be performed.
<element name="CanonicalizationMethod">
<complexType>
<any minOccurs="0" maxOccurs="unbounded" />
<attribute name="Algorithm" type="uriReference" use="required" />
</complexType>
</element>
|
The EncryptedContent element contains an encrypted content. The encrypted content is always encoded using base64 [MIME]. The Id attribute enables a Reference element to reference this element. Alternatively, a URI attribute enables this to reference a Reference element. The Id attribute is optional and can be omitted if this element is unambiguously identified or references a Reference element.
<element name="EncryptedContent">
<complexType base="xenc:base64-encoded-binary" derivedBy="extension">
<attribute name="Id" type="ID" use="optional" />
<attribute name="URI" type="uriReference" use="optional" />
</complexType>
</element>
|
An enveloped content consists of an encrypted content and encrypted content-encryption keys for one or more recipients. The combination of the encrypted content and encrypted content-encryption key for a recipient is a digital envelope for that recipient. Only expected recipients can open the envelope. Contents can be enveloped for any number of recipients in parallel.
The process by which an enveloped content is constructed involves the following steps:
A recipient opens the envelope by decrypting one of the encrypted content-encryption keys and then decrypting the encrypted content with the recovered content-encryption key. The key for decrypting the encrypted content-encryption key is identified from information for the recipient.
The EnvelopeInfo element relates information for recipients to encrypted contents. This element contains a RecipientInfos element and EncryptedContentInfo elements.
<element name="EnvelopeInfo">
<complexType>
<element ref="xenc:RecipientInfos" />
<element ref="xenc:EncryptedContentInfo" minOccurs="1" maxOccurs="unbounded" />
</complexType>
</element>
|
RecipientInfos is an element which collects information for all the recipients together. This element contains one or more KeyTransRecipientInfo, KeyAgreeRecipientInfo, or KEKRecipientInfo elements. These elements are adapted to the three key management techniques that are supported: key transport, key agreement, and shared symmetric keys. Any of the three key management techniques can be used for each recipient of the same content-encryption key.
<element name="RecipientInfos">
<complexType>
<choice minOccurs="1" maxOccurs="unbounded">
<element ref="xenc:KeyTransRecipientInfo" />
<element ref="xenc:KeyAgreeRecipientInfo" />
<element ref="xenc:KEKRecipientInfo" />
</choice>
</complexType>
</element>
|
The KeyTransRecipientInfo element is selected when using key transport. This element collects information about a recipient's public key, a key-encryption algorithm, and an encrypted content-encryption key. This element contains RecipientIdentifier, KeyEncryptionMethod, and EncryptedKey elements. The EncryptedKey element is optional, and if omitted, the recipient is expected to be able to identify his private key based on application context information.
<element name="RecipientInfo">
<complexType>
<element name="RecipientIdentifier" type="xenc:KeyInfo" minOccurs="0" maxOccurs="1" />
<element ref="xenc:KeyEncryptionMethod" />
<element ref="xenc:EncryptedKey" />
</complexType>
</element>
|
The RecipientIdentifier element specifies a recipient's certificate or public key which was used to encrypt a content-encryption key. This element's type is KeyInfo.
KeyEncryptionMethod is an element which specifies a key-encryption algorithm applied to a content-encryption key. The URI identifying the algorithm is given to the Algorithm attribute. This element uses the general structure for algorithms specified in Section 4.1: Key Management and Key Encryption Algorithms.
<element name="KeyEncryptionMethod">
<complexType>
<any minOccurs="0" maxOccurs="unbounded" />
<attribute name="Algorithm" type="uriReference" use="required" />
</complexType>
</element>
|
The EncryptedKey element contains an encrypted content. The encrypted content is always encoded using base64 [MIME].
<element name="EncryptedKey" type="xenc:base64-encoded-binary" /> |
The KeyAgreeRecipientInfo element is selected when using key agreement. This element collects information about a sender's public key, information about pairwise key generation, a key-encryption algorithm, and encrypted content-encryption keys for recipients using the same key agreement algorithm and domain parameters for that algorithm. This element contains Originator, UserKeyingMaterial, KeyEncryptionMethod, and RecipientEncryptedKey elements. The Originator element is optional, and if omitted, the recipients are expected to be able to identify the sender's public key based on application context information.
<element name="KeyAgreeRecipientInfo">
<complexType>
<element name="Originator" type="xenc:KeyInfo" minOccurs="0" maxOccurs="1" />
<element name="UserKeyingMaterial" type="xenc:base64-encoded-binary" minOccurs="0" maxOccurs="1" />
<element ref="xenc:KeyEncryptionMethod" />
<element ref="xenc:RecipientEncryptedKey" minOccurs="1" maxOccurs="unbounded" />
</complexType>
</element>
|
Originator is an element which specifies a sender's key agreement public key. This element's type is KeyInfo.
The UserKeyingMaterial element contains User Keying Material (UKM). With some key agreement algorithms, a sender provides a UKM to ensure that a different key is generated each time the same two parties generate a pairwise key. The UKM is always encoded using base64 [MIME].
The RecipientEncryptedKey element relates a recipient's public key to an encrypted content-encryption key. This element contains KeyAgreeRecipientIdentifier and EncryptedKey elements. The KeyAgreeRecipientIdentifier element is optional, and if omitted, the recipient is expected to be able to identify his public key based on application context information.
<element name="RecipientEncryptedKey">
<complexType>
<element name="KeyAgreeRecipientIdentifier" type="xenc:KeyInfo" minOccurs="0" maxOccurs="1" />
<element ref="xenc:EncryptedKey" />
</complexType>
</element>
|
KeyAgreeRecipientInfo is an element which specifies a recipient's public key. This element's type is KeyInfo.
The KEKRecipientInfo element is selected when using a symmetric key shared with a recipient. This element collects information about the symmetric key, a key-encryption algorithm, and an encrypted content-encryption key. This element contains KEKIdentifier, KeyEncryptionMethod, and EncryptedKey elements. The KEKIdentifier element is optional, and if omitted, the recipient is expected to be able to identify the symmetric key based on application context information.
<element name="KEKRecipientInfo">
<complexType>
<element name="KEKIdentifier" type="xenc:KeyInfo" minOccurs="0" maxOccurs="1" />
<element ref="xenc:KeyEncryptionMethod" />
<element ref="xenc:EncryptedKey" />
</complexType>
</element>
|
KEKIdentifier is an element which specifies a symmetric key-encryption key. This element's type is KeyInfo.
Contents are directly encrypted with symmetric keys shared with recipients. The process by which an encrypted content is constructed involves the following steps:
A recipient decrypts the encrypted content with the symmetric key shared with the sender. The key for decrypting the encrypted content is identified from information specified in the syntax.
The EncryptionInfo element relates information about a symmetric key to an encrypted content. This element contains CEKIdentifier and EncryptedContentInfo elements. The CEKIdentifier element is optional, and if omitted, recipients are expected to be able to identify the symmetric key based on application context information.
<element name="EncryptionInfo">
<complexType>
<element name="CEKIdentifier" type="xenc:KeyInfo" minOccurs="0" maxOccurs="1" />
<element ref="xenc:EncryptedContentInfo" minOccurs="1" maxOccurs="unbounded" />
</complexType>
</element>
|
CEKIdentifier is an element which specifies a symmetric key shared with recipients. This element's type is KeyInfo.
This section specifies some algorithms supported in this specification. For each algorithm, a reference to the formal specification and an identifier used in Encryption elements are provided. The identifier is a URI.
Any symmetric encryption algorithm which an implementation includes as a content-encryption algorithm must also be included as a key-encryption algorithm.
Implementations must include key agreement using this algorithm. And implementations must include key agreement of Triple-DES pairwise key-encryption keys and Triple-DES wrapping of Triple-DES content-encryption keys.
This identifier is given to the Algorithm attribute of the KeyEncryptionMethod element contained in the KeyAgreeRecipientInfo element. If this identifier is given to the attribute, the KeyEncryptionMethod element must contain a KeyWrapMethod element.
KeyWrapMethod is an element which specifies a key-encryption algorithm used to encrypt a content-encryption key with a pairwise key generated using this key agreement algorithm. This element uses the general structure for various algorithms.
<element name="KeyWrapMethod">
<complexType>
<any minOccurs="0" maxOccurs="unbounded" />
<attribute name="Algorithm" type="uriReference" use="required" />
</complexType>
</element>
|
Implementations should include key transport using this algorithm. RSA implementation must include key transport of Triple-DES content-encryption keys.
This identifier is given to the Algorithm attribute of the KeyEncryptionMethod element contained in the KeyTransRecipientInfo element. If this identifier is given to the attribute, the RecipientIdentifier element may contain the value of an RSA public key. The value is specified using the RSAKeyValue element.
<element name="RSAKeyValue">
<complexType>
<element name="N" type="base64-encoded-binary" />
<element name="E" type="base64-encoded-binary" />
</complexType>
</element>
|
Implementations may include symmetric key-encryption key management. Such implementations must include Triple-DES key-encryption keys wrapping Triple-DES content-encryption keys. Implementations must include this algorithm whether they include the key management or not.
This identifier is given to the Algorithm attribute of the KeyEncryptionMethod element contained in the KEKRecipientInfo element.
Implementations must include Triple-DES in CBC mode and PKCS5 padding.
This identifier is given to the Algorithm attribute of the ContentEncryptionMethod element. If this identifier is given to the attribute, the ContentEncryptionMethod element must contain a IV element.
The IV element contain an initialization vector, or IV. The IV is always encoded using base64 [MIME].
<element name="IV" type="xenc:base64-encoded-binary" /> |
Implementations should include this algorithm.
Implementations must include this algorithm.
| [3DES] | ANSI. Triple Data Encryption Algorithm Modes of Operation, ANSI X9.52, 1998. |
| [C14N] | W3C. Canonical XML Version 1.0, 2000. |
| [CMS] | Cryptographic Message Syntax, RFC 2630, 1999. |
| [DSIG] | W3C. XML-Signature Syntax and Processing, 2000. |
| [ESDH] | Diffie-Hellman Key Agreement Method, RFC 2631, 1999. |
| [MIME] | Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies, RFC 2045, 1996. |
| [PKCS1] | PKCS #1: RSA Encryption Version 1.5, RFC2313, 1998. |
| [PKCS5] | RSA Laboratories. PKCS #5: Password-Based Encryption Standard, 1993. |
| [PKCS7] | PKCS #7: Cryptographic Message Syntax Version 1.5, RFC2315, 1998. |
| [REQ] | Hiroshi Maruyama and Takeshi Imamura, Element-wise XML Encryption, 2000. |
| [XSS4J] | IBM. XML Security Suite, 2000. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC