Copyright © 2013 W3C ® ( MIT , ERCIM , Keio , Beihang ), 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 informative 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, and reserving identifiers for those algorithms. There is no requirement for implementation of this informative material and no interoperability testing has been performed.
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/.
The
XML
Security
Group
has
agreed
not
to
progress
this
the
Generic
Hybrid
Ciphers
specification
further
as
a
Recommendation
track
document,
electing
to
publish
it
as
an
informative
Working
Group
Note.
The
Working
Group
has
not
performed
interop
testing
on
the
material
in
this
document.
Other
than
publishing
as
a
W3C
This
Working
Group
Note,
the
only
changes
since
since
the
previous
Candidate
Recommendation
Working
Draft
Note
publication
are
an
update
to
the
abstract
includes
updated
references
and
introduction
minor
corrections
and
formatting
changes
to
note
that
the
example
(
diff
).
The
associated
schema
file
referenced
from
this
an
informative
document
and
an
update
to
has
had
the
references.
ghc
namespace
URI
corrected.
This document was published by the XML Security Working Group as a Working Group Note. If you wish to make comments regarding this document, please send them to public-xmlsec@w3.org ( subscribe , archives ). All comments are welcome.
Publication as a Working Group Note 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 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 informative document specifies an XML syntax and processing rules for generic hybrid ciphers and key encapsulation mechanisms based on [ ISO18033-2 ] and reserves identifiers for algorithms. The document augments XML Encryption [ XMLENC-CORE1 ]. There are no requirements for implementation of this material which has not been tested for interoperability.
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
MUST
"
and
"
optional
OPTIONAL
"
in
this
specification
are
to
be
interpreted
as
described
in
RFC2119
[
RFC2119
]:
"They
mustMUST 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
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
MUST
be
used
by
implementations
of
this
(dated)
specification
is:
xmlns ghc="http://www.w3.org/2010/xmlsec-ghc#"
While
applications
must
MUST
support
XML
and
XML
namespaces,
the
use
of
internal
entities
or
the
ghc
XML
namespace
prefix
is
optional
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
applicability
comments.
This
specification
defines
a
set
of
algorithms,
their
URIs,
and
requirements
for
implementation.
Levels
of
requirement
specified,
such
as
must
MUST
or
optional
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>
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.3 Key Encapsulation Algorithms 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 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. Using Key Encapsulation Algorithms for Key Transport .
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. Using Key Encapsulation Algorithms for Key Transport .
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.
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
ds:KeyInfo
element.)
<?xml version="1.0" encoding="utf-8"?> <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> </xenc11:KeyDerivationMethod> <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
MUST
/
required
REQUIRED
/
shall
SHALL
requirements.
This section is non-normative.
The contributions of the following Working Group members to this specification are gratefully acknowledged in accordance with the contributor policies and the active WG roster: Scott Cantor, Pratik Datta, Frederick Hirsch, Meiko Jensen, Brian LaMacchia, Hal Lockhart, Cynthia Martin, Magnus Nyström, Bruce Rich, Thomas Roessler, and Ed Simon.
Additionally, we thank Burt Kaliski of EMC for his comments during and subsequent to Last Call.
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.