RFC 4051

Additional XML Security Uniform Resource Identifiers (URIs)

📅 published April 2005, from ietf

RFC 4051: Additional XML Security Uniform Resource Identifiers (URIs) 💖

  • Series: Network Working Group 🎀
  • Number: RFC 4051 ✨
  • Title: Additional XML Security Uniform Resource Identifiers (URIs)
  • Author: D. Eastlake 3rd, Motorola Laboratories 👑
  • Category: Standards Track 🦋
  • Date: April 2005 🌸
  • Obsoletes / Updates: the title block doesn't list anything this RFC obsoletes or updates 🙈

Status of This Memo 📜

This document specifies an Internet standards track protocol for the Internet community, and asks for discussion and suggestions for improvements. For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited. 🫶

Copyright (C) The Internet Society (2005).

Abstract 🧚

Okay so this doc defines a bunch of URIs for XML Digital Signatures, Encryption, and Canonicalization. These URIs name the algorithms and the types of keying information that those specs use. 💜

Table of Contents 📚

1.  Introduction..................................................  2
2.  Algorithms....................................................  3
    2.1.  DigestMethod Algorithms.................................  3
          2.1.1.  MD5.............................................  3
          2.1.2.  SHA-224.........................................  3
          2.1.3.  SHA-384.........................................  4
    2.2.  SignatureMethod Message Authentication Code Algorithms..  4
          2.2.1.  HMAC-MD5........................................  4
          2.2.2.  HMAC SHA Variations.............................  5
          2.2.3.  HMAC-RIPEMD160..................................  6
    2.3.  SignatureMethod Public Key Signature Algorithms.........  6
          2.3.1.  RSA-MD5.........................................  6
          2.3.2.  RSA-SHA256......................................  7
          2.3.3.  RSA-SHA384......................................  7
          2.3.4.  RSA-SHA512......................................  7
          2.3.5.  RSA-RIPEMD160...................................  8
          2.3.6.  ECDSA-SHA*......................................  8
          2.3.7.  ESIGN-SHA1......................................  8
    2.4.  Minimal Canonicalization................................  9
    2.5.  Transform Algorithms....................................  9
          2.5.1.  XPointer........................................  9

    2.6.  EncryptionMethod Algorithms............................. 10
          2.6.1.  ARCFOUR Encryption Algorithm.................... 10
          2.6.2.  Camellia Block Encryption....................... 10
          2.6.3.  Camellia Key Wrap............................... 11
          2.6.4.  PSEC-KEM........................................ 11
3.  KeyInfo....................................................... 12
    3.1.  PKCS #7 Bag of Certificates and CRLs.................... 12
    3.2.  Additional RetrievalMethod Type Values.................. 12
4.  IANA Considerations........................................... 13
5.  Security Considerations....................................... 13
Acknowledgements.................................................. 13
Normative References.............................................. 13
Informative References............................................ 15
Author's Address.................................................. 16
Full Copyright Statement.......................................... 17

1. Introduction ✨

XML Digital Signatures, Canonicalization, and Encryption were standardized by the W3C and the joint IETF/W3C XMLDSIG working group. All of these are now W3C Recommendations and IETF Informational or Standards Track documents. Here's where to find each one: 💅

IETF level           W3C REC     Topic
-----------          -------     -----
[RFC3275]  Draft Std [XMLDSIG]   XML Digital Signatures
[RFC3076]  Info      [CANON]     Canonical XML
 - - - - - -         [XMLENC]    XML Encryption
[RFC3741]  Info      [EXCANON]   Exclusive XML Canonicalization

All of these standards and recommendations use URIs [RFC2396] to name algorithms and keying information types. This document is a handy reference list of URIs and descriptions for algorithms that people are really interested in, but that couldn't or haven't been put into the main documents. 🔥

Also, raising XML digital signature to a Draft Standard in the IETF meant removing any algorithms whose interoperability hadn't been shown in the main standards document. That removal included the Minimal Canonicalization algorithm. People still seem interested in it, so it's dropped from the standards track specification but included here. 🥹

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 📖

2. Algorithms 🌈

The URI [RFC2396] being dropped from the standard, because of the move from Proposed Standard to Draft Standard, is kept in Section 2.4 with its original prefix so the XMLDSIG standard's namespace doesn't change. 🍓

http://www.w3.org/2000/09/xmldsig#

Additional algorithms get URIs that start with: 🧚

http://www.w3.org/2001/04/xmldsig-more#

An "xmldsig-more" URI doesn't mean the W3C officially endorses these algorithms or identifiers, and it doesn't mean they're only useful in digital signatures. Right now, dereferencing such a URI may or may not give you a temporary placeholder document. The W3C has given permission to use this URI prefix. 🫶

2.1. DigestMethod Algorithms 🍰

These algorithms can be used anywhere a DigestMethod element shows up.

2.1.1. MD5 💜

Identifier:

http://www.w3.org/2001/04/xmldsig-more#md5

The MD5 algorithm [RFC1321] takes no explicit parameters. Here's an example of an MD5 DigestAlgorithm element:

<DigestAlgorithm
   Algorithm="http://www.w3.org/2001/04/xmldsig-more#md5"/>

An MD5 digest is a 128-bit string. The content of the DigestValue element shall be the base64 [RFC2405] encoding of this bit string, viewed as a 16-octet octet stream. 🎀

2.1.2. SHA-224 🦋

Identifier:

http://www.w3.org/2001/04/xmldsig-more#sha224

The SHA-224 algorithm [FIPS-180-2change, RFC3874] takes no explicit parameters. Here's an example of a SHA-224 DigestAlgorithm element:

<DigestAlgorithm
   Algorithm="http://www.w3.org/2001/04/xmldsig-more#sha224" />

A SHA-224 digest is a 224-bit string. The content of the DigestValue element shall be the base64 [RFC2405] encoding of this string, viewed as a 28-octet stream. Computing a SHA-224 message digest takes roughly the same effort as a SHA-256 digest, and short output usually isn't a priority in an XML application, so consideration should be given to using SHA-256 instead. 🙈

2.1.3. SHA-384 🌸

Identifier:

http://www.w3.org/2001/04/xmldsig-more#sha384

The SHA-384 algorithm [FIPS-180-2] takes no explicit parameters. Here's an example of a SHA-384 DigestAlgorithm element:

<DigestAlgorithm
   Algorithm="http://www.w3.org/2001/04/xmldsig-more#sha384" />

A SHA-384 digest is a 384-bit string. The content of the DigestValue element shall be the base64 [RFC2405] encoding of this string, viewed as a 48-octet stream. Computing a SHA-384 message digest takes roughly the same effort as a SHA-512 digest, and terseness usually isn't a criteria in an XML application, so consideration should be given to using SHA-512 instead. 💅

2.2. SignatureMethod Message Authentication Code Algorithms 🔐

Note: some text in this section is copied from [RFC3275] so it's easier for you to read. RFC 3275 is normative in case of conflict. 🧚

2.2.1. HMAC-MD5 ✨

Identifier:

http://www.w3.org/2001/04/xmldsig-more#hmac-md5

The HMAC algorithm [RFC2104] takes the truncation length in bits as a parameter. If the parameter isn't specified, all the bits of the hash are output. Here's an example of an HMAC-MD5 SignatureMethod element:

<SignatureMethod
   Algorithm="http://www.w3.org/2001/04/xmldsig-more#hmac-md5">
   <HMACOutputLength>112</HMACOutputLength>
</SignatureMethod>

The output of the HMAC algorithm is ultimately the output (possibly truncated) of the chosen digest algorithm. This value shall be base64 [RFC2405] encoded in the same straightforward way as the output of the digest algorithms. For example, the SignatureValue element for the HMAC-MD5 digest from the test vectors in [RFC2104]:

9294727A 3638BB1C 13F48EF8 158BFC9D

would be:

kpRyejY4uxwT9I74FYv8nQ==

Schema Definition:

<simpleType name="HMACOutputLength">
   <restriction base="integer" />
</simpleType>

DTD:

<!ELEMENT HMACOutputLength (#PCDATA) >

The Schema Definition and DTD shown immediately above are taken from [RFC3275].

Although some cryptographic suspicions have recently been raised about MD5 for signatures such as RSA-MD5 below, this doesn't affect the use of MD5 in HMAC. 🫶

2.2.2. HMAC SHA Variations 🍓

Identifiers:

http://www.w3.org/2001/04/xmldsig-more#hmac-sha224
http://www.w3.org/2001/04/xmldsig-more#hmac-sha256
http://www.w3.org/2001/04/xmldsig-more#hmac-sha384
http://www.w3.org/2001/04/xmldsig-more#hmac-sha512

SHA-224, SHA-256, SHA-384, and SHA-512 [FIPS-180-2, FIPS-180-2change, RFC3874] can also be used in HMAC, the same way section 2.2.1 describes for HMAC-MD5. 🎀

2.2.3. HMAC-RIPEMD160 🌈

Identifier:

http://www.w3.org/2001/04/xmldsig-more#hmac-ripemd160

RIPEMD-160 [RIPEMD-160] can also be used in HMAC, the same way section 2.2.1 describes for HMAC-MD5. 🧚

2.3. SignatureMethod Public Key Signature Algorithms 🔑

These algorithms are different from the ones in Section 2.2 because they use public key methods. The verification key is different from the signing key and can't feasibly be derived from it. 👑

2.3.1. RSA-MD5 🎀

Identifier: http://www.w3.org/2001/04/xmldsig-more#rsa-md5

okay so RSA-MD5 brings along the PKCS#1 v1.5 padding algorithm from [RFC3447] 🫶 Here's how it looks in use:

<SignatureMethod
   Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-md5" />

The SignatureValue content for an RSA-MD5 signature is the base64 [RFC2405] encoding of the octet string made by the signature generation steps in [RFC3447], section 8.1.1, for the RSASSA-PKCS1-v1_5 scheme. Now here's the important bit ✨ The EMSA-PKCS1-V1_5-ENCODE function in [RFC3447, section 9.2.1] says the value fed into the signature function MUST include a pre-pended algorithm object identifier for the hash function. Verifiers don't have to be able to parse ASN.1 or recognise OIDs, though, so that part isn't required of them 💅 The PKCS#1 v1.5 representation looks like this:

CRYPT (PAD (ASN.1 (OID, DIGEST (data))))

The padded ASN.1 ends up in this shape:

01 | FF* | 00 | prefix | hash

The vertical bar ("|") means concatenation. "01", "FF", and "00" are fixed octets with those hex values, and the asterisk ("*") after "FF" means it repeats. "hash" is the MD5 digest of the data. "prefix" is the ASN.1 BER MD5 algorithm designator prefix that PKCS #1 [RFC3447] requires, which looks like this:

hex 30 20 30 0c 06 08 2a 86 48 86 f7 0d 02 05 05 00 04 10

This prefix is there to make life easier with standard cryptographic libraries 🧚 The FF octet MUST be repeated enough times that the thing being CRYPTed is exactly one octet shorter than the RSA modulus. Be precise about it, bestie 🙈

Honestly though, computers keep getting faster and cryptography keeps advancing, so using RSA-MD5 is NOT RECOMMENDED 💀

2.3.2. RSA-SHA256 🌸

Identifier: http://www.w3.org/2001/04/xmldsig-more#rsa-sha256

This one also uses the PKCS#1 v1.5 padding algorithm [RFC3447] from section 2.3.1, just with the ASN.1 BER SHA-256 algorithm designator prefix instead. Example time:

<SignatureMethod
   Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256" />

2.3.3. RSA-SHA384 🦋

Identifier: http://www.w3.org/2001/04/xmldsig-more#rsa-sha384

Same deal here: PKCS#1 v1.5 padding [RFC3447] as described in section 2.3.1, but with the ASN.1 BER SHA-384 algorithm designator prefix. Example:

<SignatureMethod
   Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha384" />

Quick tip from the original authors ✨ Calculating a SHA-384 message digest takes about the same effort as calculating a SHA-512 one, so it's suggested that you use RSA-SHA512 over RSA-SHA384 wherever you can 🍓

2.3.4. RSA-SHA512 👑

Identifier: http://www.w3.org/2001/04/xmldsig-more#rsa-sha512

PKCS#1 v1.5 padding [RFC3447] as described in section 2.3.1, with the ASN.1 BER SHA-512 algorithm designator prefix. Example:

<SignatureMethod
   Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha512" />

2.3.5. RSA-RIPEMD160 🌈

Identifier: http://www.w3.org/2001/04/xmldsig-more/rsa-ripemd160

This uses the PKCS#1 v1.5 padding algorithm [RFC3447], as described in section 2.3.1, with the ASN.1 BER RIPEMD160 algorithm designator prefix. Example:

<SignatureMethod
  Algorithm="http://www.w3.org/2001/04/xmldsig-more/rsa-ripemd160" />

2.3.6. ECDSA-SHA* 💜

Identifiers:

http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha1
http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha224
http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha256
http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha384
http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha512

ECDSA is the Elliptic Curve Digital Signature Algorithm [FIPS-186-2], and it's basically the elliptic curve version of the DSA (DSS) signature method 🔥 If you want the full details on using it with SHA hash functions and XML Digital Signature, check out [X9.62] and [ECDSA].

2.3.7. ESIGN-SHA1 ⭐

Identifiers:

http://www.w3.org/2001/04/xmldsig-more#esign-sha1
http://www.w3.org/2001/04/xmldsig-more#esign-sha224
http://www.w3.org/2001/04/xmldsig-more#esign-sha256
http://www.w3.org/2001/04/xmldsig-more#esign-sha384
http://www.w3.org/2001/04/xmldsig-more#esign-sha512

ESIGN, specified in [IEEE-P1363a], is a signature scheme built on the integer factorization problem. It's much faster than earlier digital signature schemes, which means it can run on smart cards without any special co-processors 🧚

Example:

<SignatureMethod
   Algorithm="http://www.w3.org/2001/04/xmldsig-more#esign-sha1" />

2.4. Minimal Canonicalization 🫧

Thus far, nobody has announced two independent interoperable implementations of Minimal Canonicalization. So when XML Digital Signature went from Proposed Standard [RFC3075] up to Draft Standard [RFC3275], Minimal Canonicalization got dropped from the standards track documents 😭 People are still interested in it though, so it might show up in the future. For its definition, see [RFC3075], Section 6.5.1.

For reference, its identifier is still:

http://www.w3.org/2000/09/xmldsig#minimal

2.5. Transform Algorithms 🦋

Heads up: every CanonicalizationMethod algorithm can also be used as a transform algorithm 💅

2.5.1. XPointer 🌸

Identifier: http://www.w3.org/2001/04/xmldsig-more/xptr

This transform algorithm takes an [XPointer] as an explicit parameter. Here's an example from [RFC3092]:

<Transform
   Algorithm="http://www.w3.org/2001/04/xmldsig-more/xptr">
   <XPointer
      xmlns="http://www.w3.org/2001/04/xmldsig-more/xptr">
         xpointer(id("foo")) xmlns(bar=http://foobar.example)
         xpointer(//bar:Zab[@Id="foo"])
   </XPointer>
</Transform>

Schema Definition:

<element name="XPointer" type="string">

DTD:

<!ELEMENT XPointer (#PCDATA) >

The input to this transform is an octet stream, which then gets parsed into XML. The output is a node set. The results of the XPointer are handled the way the XMLDSIG specification [RFC3275] defines for a same document XPointer ✨

2.6. EncryptionMethod Algorithms 🌈

This subsection gives identifiers and info for a few EncryptionMethod Algorithms.

2.6.1. ARCFOUR Encryption Algorithm 🍓

Identifier: http://www.w3.org/2001/04/xmldsig-more#arcfour

ARCFOUR is a fast, simple stream encryption algorithm that's compatible with RSA Security's RC4 algorithm. Here's an EncryptionMethod element using ARCFOUR:

<EncryptionMethod
   Algorithm="http://www.w3.org/2001/04/xmldsig-more#arcfour">
   <KeySize>40</KeySize>
</EncryptionMethod>

Note that ARCFOUR uses the generic KeySize parameter specified and defined in [XMLENC] 🫶

2.6.2. Camellia Block Encryption 💜

Identifiers:

http://www.w3.org/2001/04/xmldsig-more#camellia128-cbc
http://www.w3.org/2001/04/xmldsig-more#camellia192-cbc
http://www.w3.org/2001/04/xmldsig-more#camellia256-cbc

Camellia is an efficient, secure block cipher with the same interface as AES [Camellia, RFC3713]. That means a 128-bit block size and 128, 192, and 256 bit key sizes 🔥 In XML Encryption, Camellia gets used the same way AES does: in Cipher Block Chaining (CBC) mode with a 128-bit initialization vector (IV). The resulting cipher text is prefixed by the IV. If it's included in XML output, it then gets base64 encoded. Example Camellia EncryptionMethod:

<EncryptionMethod
   Algorithm=
   "http://www.w3.org/2001/04/xmldsig-more#camellia128-cbc" />

2.6.3. Camellia Key Wrap 🧚

Identifiers:

http://www.w3.org/2001/04/xmldsig-more#kw-camellia128
http://www.w3.org/2001/04/xmldsig-more#kw-camellia192
http://www.w3.org/2001/04/xmldsig-more#kw-camellia256

The Camellia [Camellia, RFC3713] key wrap is identical to the AES key wrap algorithm [RFC3394] from XML Encryption, just with "AES" swapped out for "Camellia". Same as AES key wrap, the check value is 0xA6A6A6A6A6A6A6A6 ✨

The algorithm is the same no matter what size Camellia key you use for wrapping (called the key encrypting key or KEK). Implementing Camellia is OPTIONAL 🎀 But if you do support it, you should follow the same implementation guidelines as AES for which combinations of KEK size and wrapped key size must be supported and which are optional. In other words, if Camellia key wrap is supported, then wrapping 128-bit keys with a 128-bit KEK and wrapping 256-bit keys with a 256-bit KEK are REQUIRED, and all other combinations are OPTIONAL 💅

Example:

<EncryptionMethod
   Algorithm=
   "http://www.w3.org/2001/04/xmldsig-more#kw-camellia128" />

2.6.4. PSEC-KEM 🦋

Identifier: http://www.w3.org/2001/04/xmldsig-more#psec-kem

PSEC-KEM, specified in [ISO/IEC-18033-2], is a key encapsulation mechanism that uses elliptic curve encryption 🌸

Example:

<EncryptionMethod
   Algorithm="http://www.w3.org/2001/04/xmlenc#psec-kem">
   <ECParameters>
      <Version>version</Version>
      <FieldID>id</FieldID>
      <Curve>curve</Curve>
      <Base>base</Base>
      <Order>order</Order>
      <Cofactor>cofactor</Cofactor>
   </ECParameters>

</EncryptionMethod>

For info on the parameters above, see [ISO/IEC-18033-2] 🫶

3. KeyInfo 🔑

Section 3.1 adds a new KeyInfo element child, and section 3.2 specifies extra KeyInfo Type values for use in RetrievalMethod 🌈

3.1. PKCS #7 Bag of Certificates and CRLs 🎀

A PKCS #7 [RFC2315] "signedData" can also be used as a bag of certificates and/or certificate revocation lists (CRLs). The PKCS7signedData element is defined to fit those structures inside KeyInfo. The binary PKCS #7 structure gets base64 [RFC2405] encoded. Any signer information present is ignored 🙈 Here's an example, with the base64 data left out [RFC3092]:

<foo:PKCS7signedData
   xmlns:foo="http://www.w3.org/2001/04/xmldsig-more">
   ...
</foo:PKCS7signedData>

3.2. Additional RetrievalMethod Type Values 💜

The Type attribute of RetrievalMethod is an optional identifier for the type of data to be retrieved. Dereferencing a RetrievalMethod reference for any KeyInfo type with an XML structure gives you an XML element or document with that element as the root. The various "raw" key information types return a binary value. That means they need a Type attribute, since they can't be unambiguously parsed 🧚

Identifiers:

http://www.w3.org/2001/04/xmldsig-more#KeyValue
http://www.w3.org/2001/04/xmldsig-more#RetrievalMethod
http://www.w3.org/2001/04/xmldsig-more#KeyName
http://www.w3.org/2001/04/xmldsig-more#rawX509CRL
http://www.w3.org/2001/04/xmldsig-more#rawPGPKeyPacket
http://www.w3.org/2001/04/xmldsig-more#rawSPKISexp
http://www.w3.org/2001/04/xmldsig-more#PKCS7signedData
http://www.w3.org/2001/04/xmldsig-more#rawPKCS7signedData

4. IANA Considerations 🌸

It's easy for people to build their own unique URIs [RFC2396], and they can get one from the W3C if that makes sense. So it's not intended that any more "http://www.w3.org/2001/04/xmldsig-more#" URIs get created beyond the ones listed in this document. (W3C Namespace stability rules forbid creating new URIs under "http://www.w3.org/2000/09/xmldsig#".) 🔒

http://www.w3.org/2001/04/xmldsig-
more#

5. Security Considerations 🔐

Okay, security is the dramatic plot twist of this whole doc 😭. Because computers keep getting faster and cryptographic advances keep happening, using MD5 as a DigestMethod is NOT RECOMMENDED 💀. The same goes for using MD5 in the RSA-MD5 SignatureMethod 🙈. Those advances don't affect the security of HMAC-MD5, but ngl there's little reason not to just use one of the SHA series of algorithms ✨🔥.

Acknowledgements 🫶

Huge thanks to Glenn Adams, Merlin Hughs, Gregor Karlinger, Brian LaMachia, Shiho Moriai, Joseph Reagle, Russ Housley, and Joel Halpern 💖. The people who made this possible are literally iconic 👑.

Normative References 📚

  • [Camellia] "Camellia: A 128-bit Block Cipher Suitable for Multiple Platforms - Design and Analysis -", K. Aoki, T. Ichikawa, M. Matsui, S. Moriai, J. Nakajima, T. Tokita, In Selected Areas in Cryptography, 7th Annual International Workshop, SAC 2000, August 2000, Proceedings, Lecture Notes in Computer Science 2012, pp. 39-56, Springer-Verlag, 2001. 🌸
  • [ECDSA] Blake-Wilson, S., Karlinger, G., Kobayashi, T., and Y. Wang, "Using the Elliptic Curve Signature Algorithm (ECDSA) for XML Digital Signatures", RFC 4050, April 2005. 🦋
  • [FIPS-180-2] "Secure Hash Standard", (SHA-1/256/384/512) US Federal Information Processing Standard, 1 August 2002. 🧚
  • [FIPS-180-2change] "FIPS 180-2, Secure Hash Standard Change Notice 1", adds SHA-224 to [FIPS 180-2], 25 February 2004. ✨
  • [FIPS-186-2] "Digital Signature Standard", National Institute of Standards and Technology, 2000. 💜
  • [IEEE-P1363a] "Standard Specifications for Public Key Cryptography: Additional Techniques", October 2002. 🌈
  • [ISO/IEC-18033-2] "Information technology -- Security techniques -- Encryption algorithms -- Part 3: Asymmetric ciphers", CD, October 2002. 🍓
  • [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm ", RFC 1321, April 1992. 🎀
  • [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997. 🔐
  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 💅
  • [RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. 🌸
  • [RFC2405] Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher Algorithm With Explicit IV", RFC 2405, November 1998. 🦋
  • [RFC2315] Kaliski, B., "PKCS #7: Cryptographic Message Syntax Version 1.5", RFC 2315, March 1998. ⭐
  • [RFC3075] Eastlake 3rd, D., Reagle, J., and D. Solo, "XML-Signature Syntax and Processing", RFC 3075, March 2001. (RFC 3075 was obsoleted by RFC 3275 but is referenced in this document for its description of Minimal Canonicalization which was dropped in RFC 3275.) 🙈
  • [RFC3275] Eastlake 3rd, D., Reagle, J., and D. Solo, "(Extensible Markup Language) XML-Signature Syntax and Processing", RFC 3275, March 2002. 💖
  • [RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard (AES) Key Wrap Algorithm", RFC 3394, September 2002. 🔥
  • [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003. 👑
  • [RFC3713] Matsui, M., Nakajima, J., and S. Moriai, "A Description of the Camellia Encryption Algorithm", RFC 3713, April 2004. 🌈
  • [RFC3874] Housley, R., "A 224-bit One-way Hash Function: SHA-224", RFC 3874, September 2004. 🍓
  • [RIPEMD-160] ISO/IEC 10118-3:1998, "Information Technology - Security techniques - Hash-functions - Part3: Dedicated hash- functions", ISO, 1998. 🧚
  • [X9.62] X9.62-200X, "Public Key Cryptography for the Financial Services Industry: The Elliptic Curve Digital Signature Algorithm (ECDSA)", Accredited Standards Committee X9, American National Standards Institute. 💜
  • [XMLDSIG] "XML-Signature Syntax and Processing", D. Eastlake 3rd, J. Reagle, & D. Solo, 12 February 2002. <http://www.w3.org/TR/xmldsig-core/> 🦋
  • [XMLENC] "XML Encryption Syntax and Processing", J. Reagle, D. Eastlake, December 2002. <http://www.w3.org/TR/2001/RED-xmlenc-core-20021210/> 🌸
  • [XPointer] "XML Pointer Language (XPointer) Version 1.0", W3C working draft, Steve DeRose, Eve Maler, Ron Daniel Jr., January 2001. <http://www.w3.org/TR/2001/WD-xptr-20010108> ✨

Informative References 💡

Author's Address 🖊️

Donald E. Eastlake 3rd Motorola Laboratories 155 Beaver Street Milford, MA 01757 USA

Phone: +1-508-786-7554 (w) +1-508-634-2066 (h) EMail: Donald.Eastlake@motorola.com

Copyright (C) The Internet Society (2005).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. 💜

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 🙈

Intellectual Property 🧾

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. 🌸

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. 🦋

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. ✨

Acknowledgement 🎀

Funding for the RFC Editor function is currently provided by the Internet Society. 💖

📦 where this page comes from