Abstract
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.
applications,
and
reserving
identifiers
for
those
algorithms.
There
is
no
requirement
for
implementation
of
this
informative
material
and
no
interoperability
testing
has
been
performed.
Status
of
This
Document
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/.
There
is
no
previous
W3C
Recommendation
of
The
XML
Security
Generic
Hybrid
Ciphers.
No
substantive
changes
have
been
made
Group
has
agreed
not
to
progress
this
Generic
Hybrid
Ciphers
specification
since
the
previous
Last
Call
further
as
a
Recommendation
track
document,
electing
to
publish
it
as
an
informative
Working
Draft.
Please
review
differences
between
the
previous
Last
Call
Group
Note.
The
Working
Draft
and
Group
has
not
performed
interop
testing
on
the
material
in
this
Candidate
Recommendation
.
document.
Changes
Other
than
publishing
as
a
W3C
Working
Group
Note,
the
only
changes
since
since
the
previous
Last
Call
include
updated
References,
editorial
updates
and
corrections
related
Candidate
Recommendation
Working
Draft
publication
are
an
update
to
references
the
abstract
and
introduction
to
sections
within
referenced
documents,
example
formatting
note
that
this
an
informative
document
and
addition
of
acknowledgments.
an
update
to
the
references.
This
document
was
published
by
the
XML
Security
Working
Group
as
a
Candidate
Recommendation.
This
document
is
intended
to
become
a
W3C
Recommendation.
Working
Group
Note.
If
you
wish
to
make
comments
regarding
this
document,
please
send
them
to
public-xmlsec@w3.org
(
subscribe
,
archives
).
W3C
publishes
a
Candidate
Recommendation
to
indicate
that
the
document
is
believed
to
be
stable
and
to
encourage
implementation
by
the
developer
community.
This
Candidate
Recommendation
is
expected
to
advance
to
Proposed
Recommendation
no
earlier
than
01
June
2011.
All
feedback
is
comments
are
welcome.
Publication
as
a
Candidate
Recommendation
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
.
1.
Introduction
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.
1.1
Editorial
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.
2.
Versions,
Namespaces
and
Identifiers
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#"
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.
3.
Generic
Hybrid
Ciphers
Overview
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.
4.
Algorithms
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.
4.2
Generic
Hybrid
Encryption
Algorithms
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.
4.2.1
Generic-Hybrid
-
Identifier:
-
http://www.w3.org/2010/xmlsec-ghc#generic-hybrid
(
required
)
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.
4.3
Key
Encapsulation
Algorithms
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.
4.3.1
RSAES-KEM
-
Identifier
-
http://www.w3.org/2010/xmlsec-ghc#rsaes-kem
(
required
)
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
]):
-
Generate
a
non-negative
random
number
r
less
than
the
modulus
n;
-
Set
R
=
I2OSP(r,
len(n))
where
I2OSP
is
the
integer
to
octet
string
conversion
specified
in
Section
4.1
of
PKCS
#1
[
PKCS1
]
and
len(n)
is
the
length
of
the
modulus
n;
-
Set
c0
=
RSAEP((n
,
e),
r)
where
RSAEP
is
the
RSA
encryption
primitive
defined
in
Section
5.1.1
of
PKCS
#1
[
PKCS1
]
(i.e.
no
padding);
-
Set
C0
=
I2OSP(c0,
len(n));
-
Compute
K
=
KDF(R,
KeyLen,
OtherInfo)
where
KDF
is
the
key
derivation
function,
KeyLen
is
the
length
of
the
encapsulated
key
and
OtherInfo
is
optional
other
info
(subject
to
the
input
parameters
for
the
key
derivation
function,
see
[
XMLENC-CORE1
]
Section
5.4);
-
Output
the
key
K
and
ciphertext
C0.
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
]:
-
Set
c0
=
OS2IP(C0)
where
OS2IP
is
the
octet
string
to
integer
conversion
specified
in
Section
4.2
of
PKCS
#1
[
PKCS1
].
-
Set
r
=
RSADP((n
,
d),
c0)
where
RSADP
is
the
RSA
decryption
primitive
defined
in
Section
5.1.2
of
PKCS
#1
[
PKCS1
]
(i.e.
no
padding);
-
Set
R
=
I2OSP(r,
len(n));
-
Compute
K
=
KDF(R,
KeyLen,
OtherInfo)
where
KDF
is
the
key
derivation
function,
KeyLen
is
the
length
of
the
encapsulated
key
and
OtherInfo
is
optional
other
info
(subject
to
the
input
parameters
for
the
key
derivation
function,
see
[
XMLENC-CORE1
]
Section
5.4);
-
Output
the
secret
key
K.
For
use
of
the
RSAES-KEM
key
encapsulation
algorithm
with
Key
Transport,
see
section
5.
Using
Key
Encapsulation
Algorithms
for
Key
Transport
.
4.3.2
ECIES-KEM
-
Identifier
-
http://www.w3.org/2010/xmlsec-ghc#ecies-kem
(
required
)
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
]):
-
Generate
a
positive
random
number
r
less
than
o;
-
Compute
the
elliptic
curve
point
G
=
r
*
g
where
*
denotes
scalar
multiplication;
-
Compute
the
elliptic
curve
point
H
=
r
*
h;
-
Set
C0
=
ENCODE
(
G
)
where
ENCODE
is
the
encoding
of
the
elliptic
curve
point
G
as
specified
in
Section
4.4.2
of
[
XMLDSIG-CORE1
].
-
Set
P
=
ENCODE
(
H
)
where
ENCODE
is
the
encoding
of
the
elliptic
curve
point
H;
since
H
is
a
point
on
the
curve
the
encoding
shall
again
be
as
specified
in
Section
4.4.2
of
[
XMLDSIG-CORE1
];
-
Set
K
=
KDF(
C0
|
P,
KeyLen,
OtherInfo
)
where
KDF
is
the
key
derivation
function,
KeyLen
is
the
length
of
the
derived
key
and
OtherInfo
is
optional
other
info
(subject
to
the
input
parameters
for
the
key
derivation
function,
see
[
XMLDSIG-CORE1
];
Section
5.4);
-
Output
the
key
K
and
ciphertext
C0.
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
]):
-
Set
G
=
DECODE
(
C0
)
where
DECODE
is
the
decoding
function
which
is
the
reverse
of
the
ENCODE
function
previously
described;
-
Compute
the
elliptic
curve
point
H
=
x
*
G
where
*
denotes
scalar
multiplication;
-
If
H
=
0,
then
fail;
-
Set
P
=
ENCODE
(
H
)
where
ENCODE
is
the
encoding
of
the
elliptic
curve
point
H
as
specified
in
Section
4.4.2
of
[
XMLDSIG-CORE1
].
-
Set
K
=
KDF(
C0
|
P,
KeyLen,
OtherInfo
)
where
KDF
is
the
key
derivation
function,
KeyLen
is
the
length
of
the
derived
key
and
OtherInfo
is
optional
other
info
(subject
to
the
input
parameters
for
the
key
derivation
function,
see
[
XMLDSIG-CORE1
]
Section
5.4);
-
Output
the
secret
key
K.
For
use
of
the
ECIES-KEM
key
encapsulation
algorithm
with
Key
Transport,
see
section
5.
Using
Key
Encapsulation
Algorithms
for
Key
Transport
.
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).
7.
Security
Considerations
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.
A.
References
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.