rfc-4051

Additional XML Security Uniform Resource Identifiers (URIs)

D. Eastlake 3rd
date2005-04 streamIETF wgnon working group statusPROPOSED STANDARD pages17 canonicalhttps://www.rfc-editor.org/rfc/rfc4051 doi10.17487/RFC4051 errataview
A number of Uniform Resource Identifiers (URIs) intended for use with XML Digital Signatures, Encryption, and Canonicalization are defined. These URIs identify algorithms and types of keying information. [STANDARDS-TRACK]

obsoleted by

Extracted elements (28)

design-rationale §2.4

Minimal Canonicalization was dropped from the XML Digital Signature standards track (RFC 3275) because two independent interoperable implementations had not been demonstrated, as required for advancement from Proposed to Draft Standard. It is preserved in this document with its original URI prefix to avoid changing the XMLDSIG namespace.

crypto

design-rationale §2.1.2

SHA-224 and SHA-384 are noted to take roughly the same computational effort as SHA-256 and SHA-512 respectively, and since terseness is not a criterion in XML applications, use of SHA-256 or SHA-512 should be considered as alternatives.

crypto

design-rationale §2

The xmldsig-more# URI prefix was adopted for additional algorithms to avoid implying official W3C status while providing a stable namespace. Dereferencing such URIs may or may not produce a temporary placeholder document; permission to use the prefix was given by the W3C.

crypto

interoperability-note §2.2.1

Although cryptographic suspicions have been cast on MD5 for use in signatures such as RSA-MD5, this does not affect the security of HMAC-MD5. These are distinct uses and should be treated differently in security evaluations.

crypto, security

normative-requirement §2.3.1 MUST

For RSA-MD5, the value input to the signature function MUST contain a pre-pended algorithm object identifier for the hash function per EMSA-PKCS1-V1_5-ENCODE. The FF octet MUST be repeated enough times that the quantity being encrypted is exactly one octet shorter than the RSA modulus.

crypto, pkix

normative-requirement §2.6.3 REQUIRED

If Camellia key wrap is supported, wrapping 128-bit keys with a 128-bit KEK and wrapping 256-bit keys with a 256-bit KEK are REQUIRED; all other key size combinations are OPTIONAL. The implementation of Camellia itself is OPTIONAL.

crypto

normative-requirement §2.3.1 RECOMMENDED

RSA-MD5 use is NOT RECOMMENDED due to increases in computer processor power and advances in cryptography.

crypto, security

protocol-element §3.2

Additional RetrievalMethod Type URIs are defined for xmldsig-more#KeyValue, RetrievalMethod, KeyName, rawX509CRL, rawPGPKeyPacket, rawSPKISexp, PKCS7signedData, and rawPKCS7signedData. Raw key types require a Type attribute because they are not unambiguously parseable.

crypto, pkix

protocol-element §2.6.1

ARCFOUR EncryptionMethod (URI: http://www.w3.org/2001/04/xmldsig-more#arcfour) is a fast stream cipher compatible with RC4, using the generic KeySize parameter from XML Encryption for key length specification.

crypto

protocol-element §2.6.2

Camellia block encryption is defined in CBC mode with a 128-bit IV for 128, 192, and 256-bit key sizes (URIs: xmldsig-more#camellia128-cbc, camellia192-cbc, camellia256-cbc). The IV is prefixed to ciphertext; output is base64-encoded when in XML.

crypto

protocol-element §2.6.3

Camellia key wrap (URIs: xmldsig-more#kw-camellia128/192/256) is identical to AES key wrap [RFC3394] with 'AES' replaced by 'Camellia'. The check value is 0xA6A6A6A6A6A6A6A6, same as AES key wrap.

crypto

protocol-element §2.3.6

ECDSA-SHA* SignatureMethods are defined for SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512, with URIs http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha{1,224,256,384,512}. ECDSA is the elliptic curve analogue of DSA.

crypto

protocol-element §2.3.7

ESIGN-SHA* SignatureMethods (SHA-1, SHA-224, SHA-256, SHA-384, SHA-512) are defined via URIs http://www.w3.org/2001/04/xmldsig-more#esign-sha*. ESIGN is based on integer factorization and is faster than previous digital signature schemes, suitable for smart cards without special co-processors.

crypto

protocol-element §2.2.1

HMAC-MD5 SignatureMethod is identified by URI http://www.w3.org/2001/04/xmldsig-more#hmac-md5. The HMAC algorithm takes an optional truncation length in bits via HMACOutputLength; if not specified, all bits of the hash are output.

crypto

protocol-element §2.2.3

HMAC-RIPEMD160 SignatureMethod is identified by URI http://www.w3.org/2001/04/xmldsig-more#hmac-ripemd160, used in the same manner as HMAC-MD5.

crypto

protocol-element §2.2.2

HMAC SHA variants (SHA-224, SHA-256, SHA-384, SHA-512) are defined with URIs http://www.w3.org/2001/04/xmldsig-more#hmac-sha224/256/384/512, usable as SignatureMethod algorithms following the same pattern as HMAC-MD5.

crypto

protocol-element §2.1.1

MD5 DigestMethod is identified by URI http://www.w3.org/2001/04/xmldsig-more#md5. An MD5 digest is a 128-bit string encoded as base64 in the DigestValue element, viewed as a 16-octet stream.

crypto

protocol-element §2.4

Minimal Canonicalization retains its original identifier http://www.w3.org/2000/09/xmldsig#minimal. It was dropped from standards-track XML Digital Signature (RFC 3275) due to lack of two independent interoperable implementations but is preserved here for reference.

crypto

protocol-element §3.1

PKCS7signedData KeyInfo child element allows a PKCS #7 'signedData' structure to serve as a bag of certificates and/or CRLs within KeyInfo. The binary structure is base64-encoded; any signer information present is ignored.

crypto, pkix

protocol-element §2.6.4

PSEC-KEM (URI: http://www.w3.org/2001/04/xmldsig-more#psec-kem) is a key encapsulation mechanism using elliptic curve encryption per ISO/IEC 18033-2, parameterized with ECParameters including Version, FieldID, Curve, Base, Order, and Cofactor elements.

crypto

protocol-element §2.3.1

RSA-MD5 SignatureMethod (URI: http://www.w3.org/2001/04/xmldsig-more#rsa-md5) uses PKCS#1 v1.5 padding. The SignatureValue is base64-encoded and the padded structure is: 01 | FF* | 00 | ASN.1 prefix | MD5 hash.

crypto, pkix

protocol-element §2.3.5

RSA-RIPEMD160 SignatureMethod is identified by URI http://www.w3.org/2001/04/xmldsig-more/rsa-ripemd160 and uses PKCS#1 v1.5 padding with the ASN.1 BER RIPEMD160 algorithm designator prefix.

crypto, pkix

protocol-element §2.3.2

RSA-SHA256, RSA-SHA384, and RSA-SHA512 SignatureMethods use PKCS#1 v1.5 padding with the respective ASN.1 BER algorithm designator prefixes, identified by URIs http://www.w3.org/2001/04/xmldsig-more#rsa-sha256/sha384/sha512.

crypto, pkix

protocol-element §2.1.2

SHA-224 DigestMethod is identified by URI http://www.w3.org/2001/04/xmldsig-more#sha224. A SHA-224 digest is a 224-bit string base64-encoded as a 28-octet stream in DigestValue.

crypto

protocol-element §2.1.3

SHA-384 DigestMethod is identified by URI http://www.w3.org/2001/04/xmldsig-more#sha384. A SHA-384 digest is a 384-bit string base64-encoded as a 48-octet stream in DigestValue.

crypto

protocol-element §2.5.1

XPointer Transform is identified by URI http://www.w3.org/2001/04/xmldsig-more/xptr. It takes an XPointer as an explicit parameter via an XPointer child element; input is an octet stream parsed into XML, output is a node set.

crypto

registry §4

No new IANA registry is created. The document notes that people can construct their own unique URIs and the xmldsig-more# URI space is not intended to receive additional entries beyond those enumerated in this document. W3C Namespace stability rules prohibit new URIs under xmldsig#.

registry

security-consideration §5

Use of MD5 as a DigestMethod and in RSA-MD5 SignatureMethod is NOT RECOMMENDED due to computer speed increases and cryptographic advances. The concerned cryptographic advances do not affect the security of HMAC-MD5, but there is little reason not to use one of the SHA series of algorithms.

crypto, security