Copyright © 2013 W3C ® ( MIT , ERCIM , Keio , Beihang ), All Rights Reserved. W3C liability , trademark and document use rules apply.
This Note summarizes XML Security algorithm URI identifiers and the specifications associated with them.
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/.
Changes
since
the
last
publication
of
this
draft
include
the
following
changes
(see
redline
):
Clarified
implementation
requirements.
Added
RSA-SHA224,
HMAC-SHA224,
AES192-GCM
Updated
AES-128/192/256-pad
symmetric
key
wrap
algorithm
descriptions
to
reference
Appendix
A.1
of
XML
Encryption
1.1,
note
that
Note
:
On
23
April
2013,
the
specification
is
informative
and
reference
to
repeat
the
statement
from
"Additional
XML
Encryption
1.1:
"
This
informative
section
outlines
Security
URIs"
RFC
was
updated.
The
Director
previously
authorized
the
definition
and
reserves
identifiers
for
algorithms
publication
knowing
that
have
no
requirements
for
implementation
and
have
not
been
tested
for
interoperability."
Changed
"Exclusive
Canonicalization
XML
1.0
(omit
comments)"
to
required,
reflecting
change
in
XML
Signature
1.1
Updated
status
of
DSA-SHA1
noting
mandatory
to
implement
in
XML
Signature
1.1
only
for
verification,
use
discouraged
for
signing.
Updated
status
to
discourage
use
of
SHA-1
algorithms
in
XML
Signature
1.1,
including
discouraging
use
of
RSA-SHA1
for
signing,
and
use
of
SHA-1
as
digest.
Updated
status
of
SHA-256,
RSA-SHA256,
ECDSA-SHA256,
HMAC-SHA256
as
mandatory
to
implement
algorithms
in
XML
Signature
1.1.
Updated
status
of
RSA-OAEP
(including
MGF1
with
SHA1
MGF)
as
mandatory
to
implement
in
XML
Encryption
1.1.
Updated
status
of
ConcatKDF
as
mandatory
to
implement
in
XML
Encryption
1.1.
Changed
RSA
v1.5
key
transport
algorithm
to
optional
in
XML
Encryption
1.1
and
recommended
it
not
the
reference
would
be
implemented.
Updated
Elliptic
Key
Diffie-Hellman
Key
Agreement
(Ephemeral-Static
Mode)
as
mandatory
to
implement
in
XML
Encryption
1.1.
Noted
that
KeyInfoReference
is
preferred
over
RetrievalMethod
updated
in
XML
Signature
1.1.
Noted
that
a
near
future.
Changes
since
the
following
are
recommended
previous
publication
include
updates
to
implement
in
XML
Signature
1.1
:
Canonical
XML
1.0
with
comments,
Canonical
XML
1.1
the
references,
including
replacing
RFC
4051
with
comments,
Exclusive
Canonicalization
omit
comments,
XPath
filtering,
XML-Signature
XPath
Filter
2.0.
Updated
links
to
TR/xmlenc-core1/
rather
than
specific
versions
of
XML
Encryption
1.1,
replace
link
to
editors
draft
for
XML
Signature
1.1
to
TR
version.
Updated
references.
RFC
6931
which
updates
it
(
diff
).
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 .
The various XML Security specifications have defined a number of algorithms of various types, while allowing and expecting additional algorithms to be defined later. Over time, these identifiers have been defined in a number of different specifications, including XML Signature, XML Encryption, RFCs and elsewhere.
This makes it difficult for users of the XML Security specifications to know whether and where a URI for an algorithm of interest has been defined, and can lead to the use of incorrect URIs. The purpose of this Note is to collect the various known URIs at the time of its publication and indicate the specifications in which they are defined in order to avoid confusion and errors.
This note is not intended as an exhaustive list of all known related identifiers, some of which may have been defined by other standards or specifications. Furthermore, this note is not to be taken as normative regarding the information provided; if information here conflicts with the referenced specification, the specification takes precedence in all cases.
The
architecture
of
the
XML
Security
specifications
distinguishes
between
the
(universally
useful)
identifiers
for
algorithms
and
the
roles
that
these
algorithms
can
take.
Roles
are
identified
through
elements
like
ds:SignatureMethod
,
ds:DigestMethod
,
ds:CanonicalizationMethod
,
or
ds:Transform
,
whereas
the
algorithms
are
identified
through
URIs.
Explicit
parameters
for
the
respective
algorithms
are
transmitted
in
child
elements
of
the
role
element.
This
note
indicates
explicitly
whether
an
algorithm
is
mandatory
or
recommended
in
other
specifications.
If
nothing
is
said,
then
readers
should
assume
that
support
for
the
algorithms
given
is
optional
OPTIONAL
.
This document applies to [ XMLDSIG-CORE1 ] and [ XMLENC-CORE1 ] unless otherwise noted.
This specification uses the following XML namespace prefixes:
ds
http://www.w3.org/2000/09/xmldsig#
xenc
http://www.w3.org/2001/04/xmlenc#
dsig11
http://www.w3.org/2009/xmldsig11#
dsigmore
http://www.w3.org/2001/04/xmldsig-more#
Algorithm URIs have been coined in a variety of namespaces, and are always given in full.
The
algorithms
listed
in
this
section
are
typically
used
in
the
signature
algorithm
role,
identified
through
the
ds:SignatureMethod
role
element
(
[
XMLDSIG-CORE
]
,
section
4.3.2).
Each
signature
method
takes
an
octet-stream
as
input,
and
produces
a
signature
value
(an
octet-stream
that
is
always
base64
encoded,
see
section
4.2
of
[
XMLDSIG-CORE
]
).
A
container
for
key
material,
ds:DSAKeyValue
,
is
defined
in
section
4.4.2.1
of
[
XMLDSIG-CORE
]
.
When
used
with
ds:RetrievalMethod
,
this
container
type
is
identified
through
the
URI
http://www.w3.org/2000/09/xmldsig#DSAKeyValue
.
Implementation of this algorithm is required in [ XMLDSIG-CORE2002 ] and [ XMLDSIG-CORE ]. It is mandatory to implement in [ XMLDSIG-CORE1 ] for signature verification. [ XMLDSIG-CORE1 ] allows verification support for 1024 bit key legacy signatures, but requires that 1024 bit keys must not be used for new signatures.
Implementation of this algorithm is optional. Permissible lengths of the prime modulus are 2048 and 3072.
This
section
lists
variants
of
the
RSA
algorithm.
A
container
for
key
material,
ds:RSAKeyValue
,
is
defined
in
section
4.4.2.2
of
[
XMLDSIG-CORE2002
]
.
When
used
with
ds:RetrievalMethod
,
this
container
type
is
identified
through
the
URI
http://www.w3.org/2000/09/xmldsig#RSAKeyValue
.
We only list the algorithm URI for RSA-MD5 for the sake of completeness. The cryptographic strength of the MD5 algorithm is sufficiently doubtful that its use is discouraged at this time. It is not listed as an algorithm in [ XMLDSIG-CORE1 ].
Implementation of this algorithm is recommended in [ XMLDSIG-CORE2002 ] and [ XMLDSIG-CORE ] . Use of this algorithm for signature generation is discouraged [ XMLDSIG-CORE1 ].
This algorithm is a mandatory to implement algorithm for [ XMLDSIG-CORE1 ].
This algorithm is listed for the sake of completeness but does not have an [ XMLDSIG-CORE1 ] implementation requirement.
This
section
lists
various
variants
of
the
Elliptic
Curve
DSA
(ECDSA)
algorithm.
A
container
for
key
material,
the
ECKeyValue
element,
is
defined
in
[
XMLDSIG-CORE1
]
in
section
4.5.2.3
.
Given recent cryptographic results about the SHA1 hash algorithm, users of this algorithm should apply similar caution to other SHA1 based algorithms, and treat it as an algorithm whose use is discouraged.
This algorithm is a mandatory to implement algorithm for [ XMLDSIG-CORE1 ].
The
following
URIs
have
been
defined
for
various
Message
Authentication
Codes
that
use
the
HMAC
construction
[
HMAC
]
.
All
of
these
algorithms
take
an
explicit
truncation
length
parameter.
A
container
for
this
parameter,
ds:HMACOutputLength
,
is
defined
in
section
6.3.1
of
[
XMLDSIG-CORE
]
.
This
container
occurs
as
a
child
element
of
the
role
element.
This algorithm is used as the default MAC algorithm in [ XKMS2 ] . It is mandatory to implement in XML Signature [ XMLDSIG-CORE2002 ], [ XMLDSIG-CORE ], [ XMLDSIG-CORE1 ]. Use of this algorithm for signature generation is discouraged [ XMLDSIG-CORE1 ] due to the weaknesses of SHA-1.
This algorithm is a mandatory to implement algorithm for [ XMLDSIG-CORE1 ].
Implementation of this algorithm is recommended in [ XMLDSIG-CORE1 ].
Implementation of this algorithm is recommended in [ XMLDSIG-CORE1 ].
This algorithm is listed for the sake of completeness but does not have an [ XMLDSIG-CORE1 ] implementation requirement.
The
following
URIs
have
been
defined
for
Digest
Methods.
They
are
typically
used
in
the
ds:DigestMethod
role
in
[
XMLDSIG-CORE2002
]
.
Note
that
ds:DigestMethod
also
occurs
as
in
the
context
of
xenc:AgreementMethod
,
as
specified
in
the
Key
Agreement
part
of
[
XMLENC-CORE
]
.
We only list the algorithm URI for MD5 for the sake of completeness. The cryptographic strength of this algorithm is sufficiently doubtful that its use is not recommended at this time.
Note
that
URIs
for
the
various
algorithms
of
the
Secure
Hash
Algorithm
family
have
been
coined
in
a
number
of
name
spaces
and
specifications,
specifically
[
XMLDSIG-CORE2002
]
(and,
in
this
regard
identically,
[
XMLDSIG-CORE
]
),
[
XMLENC-CORE
]
,
and
[
RFC4051
RFC6931
]
.
SHA-1 is the only digest algorithm defined in [ XMLDSIG-CORE ] and is mandatory to implement in that specification and in [ XMLENC-CORE ]. Use of SHA-1 is discouraged in [ XMLDSIG-CORE1 ] and [ XMLENC-CORE1 ] both of which mandate SHA-256 as mandatory to implement and offer a number of other optional SHA algorithms.
This algorithm is a mandatory to implement algorithm for [ XMLDSIG-CORE1 ].
The
following
URIs
have
been
defined
for
symmetric
key
encryption
algorithms.
They
typically
appear
in
the
xenc:EncryptionMethod
role.
This algorithm is mandatory to implement in [ XMLENC-CORE ] .
This algorithm is mandatory to implement in [ XMLENC-CORE ] .
This algorithm is mandatory to implement in [ XMLENC-CORE ] .
This algorithm is mandatory to implement in [ XMLENC-CORE1 ].
These algorithms are not in the [ XMLDSIG-CORE1 ] or [ XMLENC-CORE1 ] implementation requirements but are listed for completeness.
The following URIs have been defined for key transport algorithms.
This
algorithm
is
optional
to
implement
in
[
XMLENC-CORE
].
Implementation
of
RSA
v1.5
is
not
recommended
NOT
RECOMMENDED
due
to
security
risks
associated
with
the
algorithm.
This algorithm is mandatory to implement in [ XMLENC-CORE ].
The following URIs have been defined for key derivation algorithms.
This algorithm is mandatory to implement in [ XMLENC-CORE ].
The following URIs have been defined for key agreement algorithms.
While this is the only key agreement algorithm defined in [ XMLENC-CORE ], it is optional to implement.
A
container
for
key
material
for
this
key
agreement
algorithm,
xenc:DHKeyValue
,
is
defined
in
section
5.5.1
of
[
XMLENC-CORE
]
.
When
used
with
ds:RetrievalMethod
,
this
container
type
is
identified
through
the
URI
http://www.w3.org/2001/04/xmlenc#dh
.
This algorithm is a mandatory to implement algorithm for [ XMLENC-CORE1 ].
The following URIs have been defined for symmetric key wrap algorithms.
This algorithm is mandatory to implement in [ XMLENC-CORE ] .
This algorithm is mandatory to implement in [ XMLENC-CORE ] .
This algorithm is mandatory to implement in [ XMLENC-CORE ] .
These algorithms are not in the [ XMLDSIG-CORE1 ] or [ XMLENC-CORE1 ] implementation requirements but are listed for completeness.
The following URIs have been defined for generic hybrid cipher algorithms.
Canonicalization
algorithms
are
used
in
[
XMLDSIG-CORE2002
]
;
they
are
typically
used
in
the
ds:CanonicalizationMethod
and
ds:Transform
roles.
Canonical XML 1.0 [ XML-C14N ] without comments is mandatory to implement in both XML Signature [ XMLDSIG-CORE2002 ] and XML Signature Second Edition [ XMLDSIG-CORE ] . XML Signature Second Edition recommends use of Canonical XML 1.1 [ XML-C14N11 ] over use of Canonical XML 1.0 when inclusive canonicalization is desired, to address known issues with Canonical XML 1.0.
The canonicalization methods listed in this section accept a node-set or octet-stream as input, and produce an octet-stream as output.
This algorithm is mandatory to implement in [ XMLDSIG-CORE2002 ] and [ XMLDSIG-CORE ] .
Implementation of this algorithm is recommended in [ XMLDSIG-CORE1 ].
This algorithm is mandatory to implement in [ XMLDSIG-CORE ] . Its use is recommended over Canonical XML 1.0.
Implementation of this algorithm is recommended in [ XMLDSIG-CORE1 ].
Implementation of this algorithm is required in [ XMLDSIG-CORE1 ].
Implementation is required in [ XMLDSIG-CORE ] and [ XMLENC-CORE ]. Note that the same URI is used to identify base64 both in "encoding" context as well as in "transform" context.
This
section
lists
algorithms
that
typically
occur
in
the
ds:Transform
role.
ds:Transform
is
defined
in
detail
in
the
XML
Signature
Reference
Processing
Model
(
[
XMLDSIG-CORE
]
,
section
4.3.3.2).
This
processing
model
is,
in
turn,
applied
both
to
signed
material,
and
to
key
material
referenced
through
ds:RetrievalMethod
(
[
XMLDSIG-CORE
]
,
section
4.4.3
).
The
ds:Transform
role
element
is
also
used
by
the
optional
xenc:Transforms
feature
which
is
specified
in
the
context
of
xenc:CipherReference
in
XML
Encryption
(
[
XMLENC-CORE
],
section
3.3.1
).
Transform algorithms can take an octet-stream or a node-set as input, and can produce either an octet-stream or a node-set as output.
Implementation is required in [ XMLDSIG-CORE ] and [ XMLENC-CORE ]. Note that the same URI is used to identify base64 both in "encoding" context as well as in "transform" context.
Implementation of this algorithm is recommended in [ XMLDSIG-CORE1 ].
Implementation of this algorithm is recommended in [ XMLDSIG-CORE1 ].
This transform is required in [ XMLDSIG-CORE2002 ] , [ XMLDSIG-CORE ] .
The
ds:RetrievalMethod
element
permits
referencing
key
material
that
is
stored
outside
a
ds:KeyInfo
element.
The
type
of
the
material
that
results
from
retrieval
of
the
URI
reference
(and
possible
transform
processing)
can
be
identified
using
the
Type
attribute.
Note:
The
KeyInfoReference
element
introduced
in
[
XMLDSIG-CORE1
]
is
preferred
over
use
of
RetrievalMethod
as
it
avoids
use
of
Transform
child
elements
that
introduce
security
risk
and
implementation
challenges.
The
following
Type
values
identify
an
XML
element
or
document
with
the
given
element
as
its
root:
ds:DSAKeyValue
,
see
section
4.4.2.1
of
[
XMLDSIG-CORE
]
.
ds:RSAKeyValue
,
see
section
4.4.2.2
of
[
XMLDSIG-CORE
]
.
ds:X509Data
,
see
section
4.4.4
of
[
XMLDSIG-CORE
]
.
ds:PGPData
,
see
section
4.4.5
of
[
XMLDSIG-CORE
]
.
ds:SPKIData
,
see
section
4.4.6
of
[
XMLDSIG-CORE
]
.
ds:MgmtData
,
see
section
4.4.7
of
[
XMLDSIG-CORE
]
.
ds:KeyValue
,
see
section
4.4.2
of
[
XMLDSIG-CORE
]
.
ds:RetrievalMethod
,
see
section
4.4.3
of
[
XMLDSIG-CORE
]
.
ds:KeyName
,
see
section
4.4.1
of
[
XMLDSIG-CORE
]
.
dsigmore:PKCS7signedData
,
see
section
3.1
of
[
dsig11:ECKeyValue
,
see
section
4.5.2.3
of
[
XMLDSIG-CORE1
]
.
dsig11:DEREncodedKeyValue
,
see
section
4.5.9
of
[
XMLDSIG-CORE1
]
.
The
following
Type
values
identify
the
type
of
raw
binary
data:
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.