Copyright © 2010 W3C ® ( MIT , ERCIM , Keio ), All Rights Reserved. W3C liability , trademark and document use rules apply.
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
the
second
Public
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 a 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 public-xmlsec@w3.org ( subscribe , archives ). The Last Call period ends 10 June 2010. All feedback is welcome.
Publication as a Working Draft 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 progress.
This is a Last Call Working Draft and thus the Working Group has determined that this document has satisfied the relevant technical requirements and is sufficiently stable to advance through the Technical Recommendation process.
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 specifies an XML syntax and processing rules for generic hybrid ciphers and key encapsulation mechanisms based on [ ISO18033-2 ]. The document augments XML Encryption [ XMLENC-CORE1 ].
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
usage
use
of
these
algorithms
in
XML-based
security
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:
xmlns ghc="http://www.w3.org/2010/xmlsec-ghc#"
This
namespace
is
also
used
as
the
prefix
for
identifiers
defined
by
this
specification.
While
applications
must
support
XML
and
XML
namespaces,
the
use
of
internal
entities
or
our
the
XML
namespace
prefix
gh
ghc
and
defaulting/scoping
conventions
are
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.
The
URI
in
the
namespace
declaration
above
is
also
used
as
a
prefix
for
URIs
Identifiers
under
the
control
of
this
specification.
This
document
does
not
change
specification
are
coined
within
the
URI
associated
with
XML
Encryption
itself.
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
applicability
comments.
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
combines
combine
both
asymmetric
and
symmetric
cryptographic
techniques.
Schema
definition:
<element name="GenericHybridCipherMethod" type="ghc:GenericHybridCipherMethodType"/> <complexType name="GenericHybridCipherMethodType"> <sequence><element name="KeyEncapsulationMethod" type="gh:KeyEncapsulationMethodType"/><element name="KeyEncapsulationMethod" type="ghc:KeyEncapsulationMethodType"/> <element name="DataEncapsulationMethod" type="xenc:EncryptionMethodType"/> </sequence> </complexType>
The
KeyEncapsulationMethod
element
identifies
the
key
encapsulation
method
as
well
as
provides
values
for
its
parameters.
The
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.
The
GenericHybridCipherMethod
element
shall
appear
as
a
child
element
of
the
xenc:EncryptionMethod
when
generic-hybrid
is
specified
as
the
value
of
the
xenc:EncryptionMethod
Algorithm
attribute.
This
document
specifies
two
key
encapsulation
algorithms,
RSAES-KEM
and
ECIES-KEM,
for
use
with
the
Generic-Hybrid
cipher
in,
e.g.,
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>
The
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.
The
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 ]:
For use of the RSAES-KEM key encapsulation algorithm with Key Transport, see Section 5 .
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 ]):
For use of the ECIES-KEM key encapsulation algorithm with Key Transport, see Section 5 .
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
xenc:EncryptedKey
(the
ds:KeyInfo
element
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/2009/xmlsec-gh#rsaes-kem"
"http://www.w3.org/2010/xmlsec-ghc#rsaes-kem"
and
the
identification
of
an
RSA
public
key
instead
of
an
ECC
key
in
the
ds:KeyInfo
element.)
<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:gh="http://www.w3.org/2009/xmlsec-gh#"xmlns:ghc="http://www.w3.org/2010/xmlsec-ghc#" <xenc:EncryptionMethodAlgorithm="http://www.w3.org/2009/xmlsec-gh#generic-hybrid"> <gh:GenericHybridCipherMethod> <gh:KeyEncapsulationMethod Algorithm="http://www.w3.org/2009/xmlsec-gh#ecies-kem">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><gh:KeyLen>16</gh:KeyLen> </gh:KeyEncapsulationMethod> <gh:DataEncapsulationMethod<ghc:KeyLen>16</ghc:KeyLen> </ghc:KeyEncapsulationMethod> <ghc:DataEncapsulationMethod Algorithm="http://www.w3.org/2001/04/xmlenc#kw-aes128"/></gh:GenericHybridCipherMethod></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 C0 (expressed as<!-- 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.
TBD
Non-normative RELAX NG schema [ RELAXNG-SCHEMA ] information is available in a separate document [ XMLSEC-RELAXNG ].
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.