diff options
Diffstat (limited to 'doc/rfc/rfc4051.txt')
| -rw-r--r-- | doc/rfc/rfc4051.txt | 955 |
1 files changed, 955 insertions, 0 deletions
diff --git a/doc/rfc/rfc4051.txt b/doc/rfc/rfc4051.txt new file mode 100644 index 0000000..9489e12 --- /dev/null +++ b/doc/rfc/rfc4051.txt @@ -0,0 +1,955 @@ + + + + + + +Network Working Group D. Eastlake 3rd +Request for Comments: 4051 Motorola Laboratories +Category: Standards Track April 2005 + + + Additional XML Security Uniform Resource Identifiers (URIs) + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +Abstract + + 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. + +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 + + + +Eastlake 3rd Standards Track [Page 1] + +RFC 4051 Additional XML Security URIs April 2005 + + + 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 have been + 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. They are available as follows: + + 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 + identify algorithms and keying information types. This document + provides a convenient reference list of URIs and descriptions for + algorithms in which there is substantial interest, but which cannot + or have not been included in the main documents. Note that raising + XML digital signature to a Draft Standard in the IETF required + removal of any algorithms for which interoperability from the main + standards document has not been demonstrated. This required removal + of the Minimal Canonicalization algorithm, in which there appears to + be a continued interest, to be dropped from the standards track + specification. It is 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]. + + + + + + +Eastlake 3rd Standards Track [Page 2] + +RFC 4051 Additional XML Security URIs April 2005 + + +2. Algorithms + + The URI [RFC2396] being dropped from the standard because of the + transition from Proposed Standard to Draft Standard is included in + Section 2.4 with its original prefix so as to avoid changing the + XMLDSIG standard's namespace. + + http://www.w3.org/2000/09/xmldsig# + + Additional algorithms are given URIs that start with: + + http://www.w3.org/2001/04/xmldsig-more# + + An "xmldsig-more" URI does not imply any official W3C status for + these algorithms or identifiers or that they are only useful in + digital signatures. Currently, dereferencing such URIs may or may + not produce a temporary placeholder document. Permission to use this + URI prefix has been given by the W3C. + +2.1. DigestMethod Algorithms + + These algorithms are usable wherever a DigestMethod element occurs. + +2.1.1. MD5 + + Identifier: + + http://www.w3.org/2001/04/xmldsig-more#md5 + + The MD5 algorithm [RFC1321] takes no explicit parameters. An example + of an MD5 DigestAlgorithm element is: + + <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. An example of a SHA-224 DigestAlgorithm element is: + + + + + +Eastlake 3rd Standards Track [Page 3] + +RFC 4051 Additional XML Security URIs April 2005 + + + <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. Because it takes roughly the same amount of + effort to compute a SHA-224 message digest as a SHA-256 digest, and + terseness is usually not a criteria in an XML application, + consideration should be given to the use of SHA-256 as an + alternative. + +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. An + example of a SHA-384 DigestAlgorithm element is: + + <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. Because it takes roughly the same amount of + effort to compute a SHA-384 message digest as a SHA-512 digest and + terseness is usually not a criteria in XML application, consideration + should be given to the use of SHA-512 as an alternative. + +2.2. SignatureMethod Message Authentication Code Algorithms + + Note: Some text in this section is duplicated from [RFC3275] for the + convenience of the reader. 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 is not specified then all the bits of the + hash are output. An example of an HMAC-MD5 SignatureMethod element + is as follows: + + + + + + + +Eastlake 3rd Standards Track [Page 4] + +RFC 4051 Additional XML Security URIs April 2005 + + + <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 fashion as the + output of the digest algorithms. For example, the SignatureValue + element for the HMAC-MD5 digest + + 9294727A 3638BB1C 13F48EF8 158BFC9D + + from the test vectors in [RFC2104] would be + + kpRyejY4uxwT9I74FYv8nQ== + + Schema Definition: + + <simpleType name="HMACOutputLength"> + <restriction base="integer" /> + </simpleType> + + DTD: + + <!ELEMENT HMACOutputLength (#PCDATA) > + + The Schema Definition and DTD immediately shown above are taken from + [RFC3275]. + + Although some cryptographic suspicions have recently been cast on MD5 + for use in signatures such as RSA-MD5 below, this does not effect 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 as described in section 2.2.1 for + HMAC-MD5. + + + + + + +Eastlake 3rd Standards Track [Page 5] + +RFC 4051 Additional XML Security URIs April 2005 + + +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 as described in + section 2.2.1 for HMAC-MD5. + +2.3. SignatureMethod Public Key Signature Algorithms + + These algorithms are distinguished from those in Section 2.2 in that + they use public key methods. The verification key is different from + and not feasibly derivable from the signing key. + +2.3.1. RSA-MD5 + + Identifier: + http://www.w3.org/2001/04/xmldsig-more#rsa-md5 + + RSA-MD5 implies the PKCS#1 v1.5 padding algorithm described in + [RFC3447]. An example of use is + + <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 computed as per [RFC3447], + section 8.1.1, signature generation for the RSASSA-PKCS1-v1_5 + signature scheme. As specified in the EMSA-PKCS1-V1_5-ENCODE + function in [RFC3447, section 9.2.1], the value input to the + signature function MUST contain a pre-pended algorithm object + identifier for the hash function, but the availability of an ASN.1 + parser and recognition of OIDs are not required of a signature + verifier. The PKCS#1 v1.5 representation appears as: + + CRYPT (PAD (ASN.1 (OID, DIGEST (data)))) + + Note that the padded ASN.1 will be of the following form: + + 01 | FF* | 00 | prefix | hash + + Vertical bar ("|") represents concatenation. "01", "FF", and "00" + are fixed octets of the corresponding hexadecimal value and the + asterisk ("*") after "FF" indicates repetition. "hash" is the MD5 + digest of the data. "prefix" is the ASN.1 BER MD5 algorithm + designator prefix required in PKCS #1 [RFC3447], that is: + + hex 30 20 30 0c 06 08 2a 86 48 86 f7 0d 02 05 05 00 04 10 + + + +Eastlake 3rd Standards Track [Page 6] + +RFC 4051 Additional XML Security URIs April 2005 + + + This prefix is included to facilitate the use of standard + cryptographic libraries. The FF octet MUST be repeated enough times + that the value of the quantity being CRYPTed is exactly one octet + shorter than the RSA modulus. + + Due to increases in computer processor power and advances in + cryptography, use of RSA-MD5 is NOT RECOMMENDED. + +2.3.2. RSA-SHA256 + + Identifier: + http://www.w3.org/2001/04/xmldsig-more#rsa-sha256 + + This implies the PKCS#1 v1.5 padding algorithm [RFC3447] as described + in section 2.3.1, but with the ASN.1 BER SHA-256 algorithm designator + prefix. An example of use is: + + <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 + + This implies the PKCS#1 v1.5 padding algorithm [RFC3447] as described + in section 2.3.1, but with the ASN.1 BER SHA-384 algorithm designator + prefix. An example of use is: + + <SignatureMethod + Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha384" /> + + Because it takes about the same effort to calculate a SHA-384 message + digest as a SHA-512 message digest, it is suggested that RSA-SHA512 + be used in preference to RSA-SHA384 where possible. + +2.3.4. RSA-SHA512 + + Identifier: + http://www.w3.org/2001/04/xmldsig-more#rsa-sha512 + + This implies the PKCS#1 v1.5 padding algorithm [RFC3447] as described + in section 2.3.1, but with the ASN.1 BER SHA-512 algorithm designator + prefix. An example of use is: + + <SignatureMethod + Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha512" /> + + + + +Eastlake 3rd Standards Track [Page 7] + +RFC 4051 Additional XML Security URIs April 2005 + + +2.3.5. RSA-RIPEMD160 + + Identifier: + http://www.w3.org/2001/04/xmldsig-more/rsa-ripemd160 + + This implies the PKCS#1 v1.5 padding algorithm [RFC3447], as + described in section 2.3.1, but with the ASN.1 BER RIPEMD160 + algorithm designator prefix. An example of use is: + + <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 + + The Elliptic Curve Digital Signature Algorithm (ECDSA) [FIPS-186-2] + is the elliptic curve analogue of the DSA (DSS) signature method. + For detailed specifications on how to use it with SHA hash functions + and XML Digital Signature, please see [X9.62] and [ECDSA]. + +2.3.7. ESIGN-SHA1 + + Identifier + 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 + + The ESIGN algorithm specified in [IEEE-P1363a] is a signature scheme + based on the integer factorization problem. It is much faster than + previous digital signature schemes so ESIGN can be implemented on + smart cards without special co-processors. + + An example of use is: + + <SignatureMethod + Algorithm="http://www.w3.org/2001/04/xmldsig-more#esign-sha1" /> + + + + + + + +Eastlake 3rd Standards Track [Page 8] + +RFC 4051 Additional XML Security URIs April 2005 + + +2.4. Minimal Canonicalization + + Thus far two independent interoperable implementations of Minimal + Canonicalization have not been announced. Therefore, when XML + Digital Signature was advanced from Proposed Standard [RFC3075] to + Draft Standard [RFC3275], Minimal Canonicalization was dropped from + the standards track documents. However, there is still interest in + Minimal Canonicalization, indicating its possible future use. For + its definition, see [RFC3075], Section 6.5.1. + + For reference, its identifier remains: + http://www.w3.org/2000/09/xmldsig#minimal + +2.5. Transform Algorithms + + Note that all CanonicalizationMethod algorithms can also be used as + transform algorithms. + +2.5.1. XPointer + + Identifier: + http://www.w3.org/2001/04/xmldsig-more/xptr + + This transform algorithm takes an [XPointer] as an explicit + parameter. An example of use is [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) > + + Input to this transform is an octet stream (which is then parsed into + XML). + + + + + + +Eastlake 3rd Standards Track [Page 9] + +RFC 4051 Additional XML Security URIs April 2005 + + + Output from this transform is a node set; the results of the XPointer + are processed as defined in the XMLDSIG specification [RFC3275] for a + same document XPointer. + +2.6. EncryptionMethod Algorithms + + This subsection gives identifiers and information for several + 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 is + compatible with RSA Security's RC4 algorithm. An example of the + EncryptionMethod element using ARCFOUR is + + <EncryptionMethod + Algorithm="http://www.w3.org/2001/04/xmldsig-more#arcfour"> + <KeySize>40</KeySize> + </EncryptionMethod> + + Note that Arcfour makes use of 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 and secure block cipher with the same + interface as the AES [Camellia, RFC3713], that is 128-bit block size + and 128, 192, and 256 bit key sizes. In XML Encryption, Camellia is + used in the same way as the AES: It is used in the Cipher Block + Chaining (CBC) mode with a 128-bit initialization vector (IV). The + resulting cipher text is prefixed by the IV. If included in XML + output, it is then base64 encoded. An example Camellia + EncryptionMethod is as follows: + + <EncryptionMethod + Algorithm= + "http://www.w3.org/2001/04/xmldsig-more#camellia128-cbc" /> + + + + + + +Eastlake 3rd Standards Track [Page 10] + +RFC 4051 Additional XML Security URIs April 2005 + + +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] specified in the XML Encryption standard + with "AES" replaced by "Camellia". As with AES key wrap, the check + value is 0xA6A6A6A6A6A6A6A6. + + The algorithm is the same regardless of the size of the Camellia key + used in wrapping (called the key encrypting key or KEK). The + implementation of Camellia is OPTIONAL. However, if it is supported, + the same implementation guidelines of which combinations of KEK size + and wrapped key size should be required to be supported and which are + optional to be supported should be followed as for AES. That is to + say, 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. + + An example of use is: + + <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 + + The PSEC-KEM algorithm, specified in [ISO/IEC-18033-2], is a key + encapsulation mechanism using elliptic curve encryption. + + An example of use is: + + <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> + + + +Eastlake 3rd Standards Track [Page 11] + +RFC 4051 Additional XML Security URIs April 2005 + + + </EncryptionMethod> + + See [ISO/IEC-18033-2] for information on the parameters above. + +3. KeyInfo + + In section 3.1 a new KeyInfo element child is specified, while in + section 3.2 additional KeyInfo Type values for use in RetrievalMethod + are specified. + +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 accommodate such structures + within KeyInfo. The binary PKCS #7 structure is base64 [RFC2405] + encoded. Any signer information present is ignored. The following + is an example, eliding the base64 data [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. The result of dereferencing a + RetrievalMethod reference for all KeyInfo types with an XML structure + is an XML element or document with that element as the root. The + various "raw" key information types return a binary value. Thus, + they require a Type attribute because they are not unambiguously + parseable. + + 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 + + + + + + + + +Eastlake 3rd Standards Track [Page 12] + +RFC 4051 Additional XML Security URIs April 2005 + + +4. IANA Considerations + + As it is easy for people to construct their own unique URIs [RFC2396] + and possibly obtain a URI from the W3C if appropriate, it is not + intended that any additional "http://www.w3.org/2001/04/xmldsig- + more#" URIs be created beyond those enumerated in this document. + (W3C Namespace stability rules prohibit the creation of new URIs + under "http://www.w3.org/2000/09/xmldsig#".) + +5. Security Considerations + + Due to computer speed and cryptographic advances, the use of MD5 as a + DigestMethod and the use of MD5 in the RSA-MD5 SignatureMethod is NOT + RECOMMENDED. The concerned cryptographic advances do not effect the + security of HMAC-MD5; however, there is little reason not to use one + of the SHA series of algorithms. + +Acknowledgements + + Glenn Adams, Merlin Hughs, Gregor Karlinger, Brian LaMachia, Shiho + Moriai, Joseph Reagle, Russ Housley, and Joel Halpern. + +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. + + + +Eastlake 3rd Standards Track [Page 13] + +RFC 4051 Additional XML Security URIs April 2005 + + + [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. + + + + + + + +Eastlake 3rd Standards Track [Page 14] + +RFC 4051 Additional XML Security URIs April 2005 + + + [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 + + [CANON] "Canonical XML Version 1.0", John Boyer. + <http://www.w3.org/TR/2001/REC-xml-c14n-20010315>. + + [EXCANON] "Exclusive XML Canonicalization Version 1.0", D. + Eastlake, J. Reagle, 18 July 2002. + <http://www.w3.org/TR/REC-xml-enc-c14n-20020718/>. + + [RFC3076] Boyer, J., "Canonical XML Version 1.0", RFC 3076, + March 2001. + + + + +Eastlake 3rd Standards Track [Page 15] + +RFC 4051 Additional XML Security URIs April 2005 + + + [RFC3092] Eastlake 3rd, D., Manros, C., and E. Raymond, + "Etymology of "Foo"", RFC 3092, 2001. + + [RFC3741] Boyer, J., Eastlake 3rd, D., and J. Reagle, + "Exclusive XML Canonicalization, Version 1.0", RFC + 3741, March 2004. + +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 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Eastlake 3rd Standards Track [Page 16] + +RFC 4051 Additional XML Security URIs April 2005 + + +Full Copyright Statement + + 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. + + + + + + + +Eastlake 3rd Standards Track [Page 17] + |