Generic hybrid ciphers allow for a consistent treatment of asymmetric ciphers when encrypting data and consist of a key encapsulation algorithm with associated parameters and a data encapsulation algorithm with associated parameters. Further, the key encapsulation algorithms introduced in this specification have attractive security properties.
This document augments XML Encryption Version 1.1 [ XMLENC-CORE1 ] by defining algorithms, XML types and elements necessary to enable use of generic hybrid ciphers in XML Security applications.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
This is a Last Call Working
Draft of "XML
Security Generic Hybrid Ciphers". Changes from the previous working draft include a revision of the namespace and
editorial corrections. Please review differences between the previous and this
Working Draft .
This document was published by the XML Security Working Group as
Last Call Working Draft. This document is
intended to become a W3C Recommendation. If you wish to make
comments regarding this document, please send them to email@example.com ( subscribe
). The Last Call period ends 10
All feedback is welcome.
Publication as a
does not imply
endorsement by the W3C Membership. This is a draft document and may
be updated, replaced or obsoleted by other documents at any time.
It is inappropriate to cite this document as other than work in
This document was produced by a group operating under the 5 February 2004 W3C Patent Policy . W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy .
This document does not normatively specify when and how generic hybrid ciphers and key encapsulation mechanisms are to be used; rather it focuses on the basis for interoperability, namely the fundamental data types required for use of these algorithms in conjunction with XML Security applications and the meaning of those data types, as well as identification of specific algorithms.
The key words " must " and " optional " in this specification are to be interpreted as described in RFC2119 [ RFC2119 ]:
"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, these capitalized keywords are used 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. For instance, an XML attribute might be described as being "optional."
Note also that this entire specification is optional ; hence the keywords apply only when compliance with this specification is claimed.
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 XML namespace [ XML-NAMES ] URI that must be used by implementations of this (dated) specification is:
While applications must
support XML and XML namespaces, the use of internal entities or the
ghc XML namespace prefix is optional ; we use these facilities to provide
compact and readable examples.
This specification uses Uniform Resource Identifiers [ URI ] to identify resources, algorithms, and semantics. Identifiers under the control of this specification are coined within the scope of the above namespace.
The term "generic hybrid cipher" is defined in [ ISO18033-2 ] as an asymmetric cipher that combines both asymmetric and symmetric cryptographic techniques. Generic hybrid ciphers that meet the requirements laid out in [ ISO18033-2 ] have attractive security properties. They are introduced in this document to enable applications to use cryptographic algorithms with tight security proofs.
Generic hybrid ciphers allow for a consistent treatment of asymmetric ciphers when encrypting data and consists of a key encapsulation algorithm with associated parameters and a data encapsulation algorithm with associated parameters. The key encapsulation algorithm results in an encapsulated shared key that is then used with the data encapsulation algorithm, e.g. for encryption.
This section discusses and identifies algorithms to be used with
this specification. Entries contain the identifier to be used as
the value of the
Algorithm attribute of the
EncryptionMethod element or other element representing
the role of the algorithm, a reference to the formal specification,
definitions for the representation of keys and the results of
cryptographic operations where applicable, and general
This specification defines a set of algorithms, their URIs, and requirements for implementation. Levels of requirement specified, such as must or optional , refer to implementation, not use.
Generic-hybrid encryption algorithms combine both asymmetric and symmetric cryptographic techniques. Schema definition:
<element name="GenericHybridCipherMethod" type="ghc:GenericHybridCipherMethodType"/> <complexType name="GenericHybridCipherMethodType"> <sequence> <element name="KeyEncapsulationMethod" type="ghc:KeyEncapsulationMethodType"/> <element name="DataEncapsulationMethod" type="xenc:EncryptionMethodType"/> </sequence> </complexType>
KeyEncapsulationMethod element identifies the
key encapsulation method as well as provides values for its
DataEncapsulationMethod element identifies the
data encapsulation (encryption) method as well as provides any
parameters associated with the data encapsulation method.
The Generic-Hybrid encryption algorithm may be used for a
variety of purposes; in particular, when used with a key
encapsulation mechanism such as those specified in
Section 4.2 and a suitable key wrap algorithm, it can be
used for key transport with tight security proofs.
GenericHybridCipherMethod element shall appear
as a child element of the
generic-hybrid is specified as the value of the
This document specifies two key encapsulation algorithms, RSAES-KEM and ECIES-KEM, for use with the Generic-Hybrid cipher in key transport scenarios.
<complexType name="KeyEncapsulationMethodType"> <sequence> <element ref="xenc11:KeyDerivationMethod"/> <element name="KeyLen" type="positiveInteger"/> <any namespace="##other" minOccurs="0" maxOccurs="unbounded"/> </sequence> <attribute name="Algorithm" type="anyURI" use="required"/> </complexType>
xenc11:KeyDerivationMethod element of the
KeyEncapsulationMethodType specifies a key derivation
method to use when deriving a key from key material generated in
accordance with the key encapsulation mechanism. The
xenc11:KeyDerivationMethod element is defined in [
XMLENC-CORE1 ]. The
KeyLen element specifies length of the derived key.
Algorithm attribute identifies the actual key
encapsulation method used.
RSAES-KEM is a key encapsulation algorithm based on the RSA encryption scheme.
Given a recipient's public RSA key (n, e) where n is the RSA modulus and e is the public exponent, the following steps shall be taken to encapsulate a symmetric key when the RSAES-KEM key encapsulation algorithm is used (these are the same steps as specified in Section 11.5.3 of [ ISO18033-2 ]):
Given a recipient's private RSA key (n, d) where n is the RSA modulus and d is the private exponent, the following steps shall be taken to decrypt an encapsulated symmetric key from ciphertext C0 when the RSAES-KEM key encapsulation algorithm is used (these are the same steps as specified in Section 11.5.4 of [ ISO18033-2 ]:
ECIES-KEM is a key encapsulation algorithm based on the Elliptic Curve scheme.
Given a recipient's public EC key h and an elliptic curve E with base point g and order (size) o, the following steps shall be taken to encapsulate a symmetric key when the ECIES-KEM key encapsulation algorithm is used (these are the same steps as specified in Section 10.2.3 of [ ISO18033-2 ]):
Given a recipient's private EC key x and an elliptic curve E with base point g and order (size) o, the following steps shall be taken to decrypt an encapsulated symmetric key from ciphertext C0 when the ECIES-KEM key encapsulation algorithm is used (these are the same steps as specified in Section 10.2.4 of [ ISO18033-2 ]):
When using a Key Encapsulation algorithm such as RSAES-KEM or
ECIES-KEM for key transport, the key K which is one of the outputs
of the KEM algorithm (see RSAES-KEM
and ECIES-KEM ) is now used as a
wrapping key, encrypting a data-encryption key DEK: C1 = WRAP(K,
DEK). The combined ciphertext C0 | C1 (where C0 is the other output
of the KEM algorithm) is then placed in the
xenc:CipherValue element of the
xenc:CipherData child element of the
will identify the recipient's public key).
This section is non-normative.
The following is a syntactically correct example of an
xenc:EncryptedKey element using the Generic-Hybrid
method together with the ECIES-KEM algorithm for key encapsulation
and AES-128 KeyWrap for wrapping the content key using the
encapsulated key (the example would look precisely the same when
using the RSAES-KEM algorithm except for the identification of the
Key Encapsulation Algorithm which instead would have the value
"http://www.w3.org/2010/xmlsec-ghc#rsaes-kem" and the
identification of an RSA public key instead of an ECC key in the
<xenc:EncryptedKey xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:dsig11="http://www.w3.org/2009/xmldsig11#" xmlns:xenc11="http://www.w3.org/2009/xmlenc11#" xmlns:ghc="http://www.w3.org/2010/xmlsec-ghc#" <xenc:EncryptionMethod Algorithm="http://www.w3.org/2010/xmlsec-ghc#generic-hybrid"> <ghc:GenericHybridCipherMethod> <ghc:KeyEncapsulationMethod Algorithm="http://www.w3.org/2010/xmlsec-ghc#ecies-kem"> <xenc11:KeyDerivationMethod Algorithm="http://www.w3.org/2009/xmlenc11#ConcatKDF"> <xenc11:ConcatKDFParams AlgorithmID="0000" PartyUInfo="03D8" PartyVInfo=""> <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/> </xenc11:ConcatKDFParams> <ghc:KeyLen>16</ghc:KeyLen> </ghc:KeyEncapsulationMethod> <ghc:DataEncapsulationMethod Algorithm="http://www.w3.org/2001/04/xmlenc#kw-aes128"/> </ghc:GenericHybridCipherMethod> </xenc:EncryptionMethod> <ds:KeyInfo> <dsig11:ECKeyValue> <dsig11:NamedCurve URI="urn:oid:1.2.840.10045.3.1.7"/> <dsig11:PublicKey>DEADBEEF</dsig11:PublicKey> </dsig11:ECKeyValue> </ds:KeyInfo> <xenc:CipherData> <xenc:CipherValue>DEADBEEF</xenc:CipherValue> <!-- Is concatenation of originator's ephemeral key (expressed as an octet string) and the wrapped key --> </xenc:CipherData> </xenc:EncryptedKey>
Generic hybrid ciphers with key encapsulation mechanisms as specified in this document provides a high security level assuming key derivation algorithms and other security parameters have been properly chosen. See further [ ISO18033-2 ], Annex B for a deeper security discussion on these constructions.
An implementation is conformant to this specification if it successfully generates syntax according to the schema definitions and satisfies any and all must / required / shall requirements.The full normative grammar is defined by the XSD schema and the normative text in this specification. The standalone XSD schema file is authoritative in case there is any disagreement between it and the XSD schema portions in this specification.
This section is non-normative.
Dated references below are to the latest known or appropriate edition of the referenced work. The referenced works may be subject to revision, and conformant implementations may follow, and are encouraged to investigate the appropriateness of following, some or all more recent editions or replacements of the works cited. It is in each case implementation-defined which editions are supported.