idnits 2.17.1 draft-eastlake-additional-xmlsec-uris-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 888. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 899. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 906. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 912. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC4051]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == The 'Obsoletes: ' line in the draft header should list only the _numbers_ of the RFCs which will be obsoleted by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document obsoletes RFC4051, but the abstract doesn't seem to directly say this. It does mention RFC4051 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 2007) is 6006 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3447 (Obsoleted by RFC 8017) ** Obsolete normative reference: RFC 4634 (Obsoleted by RFC 6234) -- Obsolete informational reference (is this intentional?): RFC 3075 (Obsoleted by RFC 3275) -- Obsolete informational reference (is this intentional?): RFC 4051 (Obsoleted by RFC 6931) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Network Working Group 2 Obsoletes: RFC 4051 Donald E. Eastlake 3rd 3 Intended Status: Informational Motorola Laboratories 4 Expires: May 2008 November 2007 6 Additional XML Security Uniform Resource Identifiers (URIs) 8 10 Status of This Document 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Distribution of this document is unlimited. Comments should be sent 18 to the author. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/1id-abstracts.html 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html 36 Abstract 38 This document expands and updates the list of URIs intended for use 39 with XML Digital Signatures, Encryption, Canonnicalization, and Key 40 Management specified in RFC 4051. These URIs identify algorithms and 41 types of information. 43 Acknowledgements 45 The following were the alphabetic acknowledgements listed in 46 [RFC4051]: Glenn Adams, Merlin Hughs, Gregor Karlinger, Brian 47 LaMachia, Shiho Moriai, Joseph Reagle, Russ Housley, and Joel 48 Halpern. 50 Table of Contents 52 Status of This Document....................................1 53 Abstract...................................................1 55 Acknowledgements...........................................2 56 Table of Contents..........................................2 58 1. Introduction............................................4 59 1.1 Terminology............................................4 61 2. Algorithms..............................................5 62 2.1 DigestMethod Algorithms................................5 63 2.1.1 MD5..................................................5 64 2.1.2 SHA-224..............................................6 65 2.1.3 SHA-384..............................................6 66 2.2 SignatureMethod Message Authentication Code Algorithms.6 67 2.2.1 HMAC-MD5.............................................7 68 2.2.2 HMAC SHA Variations..................................7 69 2.2.3 HMAC-RIPEMD160.......................................8 70 2.3 SignatureMethod Public Key Signature Algorithms........8 71 2.3.1 RSA-MD5..............................................8 72 2.3.2 RSA-SHA256...........................................9 73 2.3.3 RSA-SHA384...........................................9 74 2.3.4 RSA-SHA512..........................................10 75 2.3.5 RSA-RIPEMD160.......................................10 76 2.3.6 ECDSA-SHA* and RIPEMD160............................10 77 2.3.7 ESIGN-SHA1..........................................11 78 2.4 Minimal Canonicalization..............................11 79 2.5 Transform Algorithms..................................11 80 2.5.1 XPointer............................................12 81 2.6 EncryptionMethod Algorithms...........................12 82 2.6.1 ARCFOUR Encryption Algorithm........................12 83 2.6.2 Camellia Block Encryption...........................13 84 2.6.3 Camellia Key Wrap...................................13 85 2.6.4 PSEC-KEM............................................14 87 3. KeyInfo................................................15 88 3.1 PKCS #7 Bag of Certificates and CRLs..................15 89 3.2 Additional RetrievalMethod Type Values................15 91 Table of Contents Continued 93 4. URI Index..............................................16 95 5. Fragment Index.........................................18 97 6. IANA Considerations....................................19 98 7. Security Considerations................................19 100 Normative References......................................20 101 Informative References....................................21 103 Changes from RFC 4051.....................................23 105 Disclaimer................................................24 106 Additional IPR Provisions.................................24 108 Author's Address..........................................25 109 Expiration and File Name..................................25 111 1. Introduction 113 XML Digital Signatures, Canonicalization, and Encryption have been 114 standardized by the W3C and by the joint IETF/W3C XMLDSIG working 115 group [W3C]. All of these are now W3C Recommendations and IETF 116 Informational or Standards Track documents. They are available as 117 follows: 119 IETF level W3C REC Topic 120 ----------- ------- ----- 122 [RFC3275] Draft Std [XMLDSIG] XML Digital Signatures 123 [RFC3076] Info [CANON] Canonical XML 1.0 124 - - - - - - [XMLENC] XML Encryption 125 [RFC3741] Info [XCANON] Exclusive XML Canonicalization 1.0 127 All of these standards and recommendations use URIs [RFC3986] to 128 identify algorithms and keying information types. This document is a 129 convenient reference list of URIs and descriptions for algorithms in 130 which there is substantial interest but which can not or have not 131 been included in the main documents for some reason. Note in 132 particular that raising XML digital signature to Draft Standard in 133 the IETF required remove of any algorithms for which there was not 134 demonstrated interoperability from the main standards document. This 135 required removal of the Minimal Canonicalization algorithm, in which 136 there appears to be continued interest, to be dropped from the 137 standards track specification. It was included in [RFC4051] and is 138 included here. 140 1.1 Terminology 142 Notwithstanding that this is an Informational document, standards 143 track type terms [RFC2119] are used in specifying the use of some of 144 the URIs as follows: 146 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 147 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 148 document are to be interpreted as described in RFC 2119. 150 2. Algorithms 152 The URI [RFC3986] being dropped from the standard due to the 153 transition from Proposed Standard to Draft Standard is included in 154 Section 2.4 below with its original 156 http://www.w3.org/2000/09/xmldsig# 158 prefix so as to avoid changing the XMLDSIG standard's namespace. 160 Additional algorithms in [RFC4051] were given URIs that start with 162 http://www.w3.org/2001/04/xmldsig-more# 164 while further algorithms added in this document are given URIs that 165 start with 167 http://www.w3.org/2007/05/xmldsig-more# 169 An "xmldsig-more" URI does not imply any official W3C status for 170 these algorithms or identifiers nor does it imply that they are only 171 useful in digital signatures. Currently, dereferencing such URIs may 172 or may not produce a temporary placeholder document. Permission to 173 use these URI prefixes has been given by the W3C. 175 2.1 DigestMethod Algorithms 177 These algorithms are usable wherever a DigestMethod element occurs. 179 2.1.1 MD5 181 Identifier: 182 http://www.w3.org/2001/04/xmldsig-more#md5 184 The MD5 algorithm [RFC1321] takes no explicit parameters. An example 185 of an MD5 DigestAlgorithm element is: 187 190 An MD5 digest is a 128-bit string. The content of the DigestValue 191 element shall be the base64 [RFC2045] encoding of this bit string 192 viewed as a 16-octet octet stream. 194 2.1.2 SHA-224 196 Identifier: 197 http://www.w3.org/2001/04/xmldsig-more#sha224 199 The SHA-224 algorithm [FIPS180-2?] [RFC4634] takes no explicit 200 parameters. An example of a SHA-224 DigestAlgorithm element is: 202 205 A SHA-224 digest is a 224 bit string. The content of the DigestValue 206 element shall be the base64 [RFC2045] encoding of this string viewed 207 as a 28-octet stream. Because it takes roughly the same amount of 208 effort to compute a SHA-224 message digest as a SHA-256 digest and 209 terseness is usually not a criteria in XML application, consideration 210 should be given to the use of SHA-256 as an alternative. 212 2.1.3 SHA-384 214 Identifier: 215 http://www.w3.org/2001/04/xmldsig-more#sha384 217 The SHA-384 algorithm [FIPS 180-2] takes no explicit parameters. An 218 example of a SHA-384 DigestAlgorithm element is: 220 223 A SHA-384 digest is a 384 bit string. The content of the DigestValue 224 element shall be the base64 [RFC2045] encoding of this string viewed 225 as a 48-octet stream. Because it takes roughly the same amount of 226 effort to compute a SHA-384 message digest as a SHA-512 digest and 227 terseness is usually not a criteria in XML application, consideration 228 should be given to the use of SHA-512 as an alternative. 230 2.2 SignatureMethod Message Authentication Code Algorithms 232 Note: Some text in this section is duplicated from [RFC3275] for the 233 convenience of the reader. RFC 3275 is normative in case of conflict. 235 2.2.1 HMAC-MD5 237 Identifier: 238 http://www.w3.org/2001/04/xmldsig-more#hmac-md5 240 The HMAC algorithm [RFC2104] takes the truncation length in bits as a 241 parameter; if the parameter is not specified then all the bits of the 242 hash are output. An example of an HMAC-MD5 SignatureMethod element is 243 as follows: 245 247 112 248 250 The output of the HMAC algorithm is ultimately the output (possibly 251 truncated) of the chosen digest algorithm. This value shall be base64 252 [RFC2045] encoded in the same straightforward fashion as the output 253 of the digest algorithms. Example: the SignatureValue element for the 254 HMAC-MD5 digest 256 9294727A 3638BB1C 13F48EF8 158BFC9D 258 from the test vectors in [RFC2104] would be 260 kpRyejY4uxwT9I74FYv8nQ== 262 Schema Definition: 264 265 266 268 DTD: 270 272 The Schema Definition and DTD immediately above are copied from 273 [RFC3275]. 275 Although cryptographic suspicions have recently been cast on MD5 for 276 use in signatures such as RSA-MD5 below, this does not effect use of 277 MD5 in HMAC. 279 2.2.2 HMAC SHA Variations 281 Identifiers: 282 http://www.w3.org/2001/04/xmldsig-more#hmac-sha224 283 http://www.w3.org/2001/04/xmldsig-more#hmac-sha256 284 http://www.w3.org/2001/04/xmldsig-more#hmac-sha384 285 http://www.w3.org/2001/04/xmldsig-more#hmac-sha512 287 SHA-224, SHA-256, SHA-384, and SHA-512 [FIPS180-2?] [RFC4634] can 288 also be used in HMAC as described in section 2.2.1 above for HMAC- 289 MD5. 291 2.2.3 HMAC-RIPEMD160 293 Identifier: 294 http://www.w3.org/2001/04/xmldsig-more#hmac-ripemd160 296 RIPEMD-160 [RIPEMD-160] can also be used in HMAC as described in 297 section 2.2.1 above for HMAC-MD5. 299 2.3 SignatureMethod Public Key Signature Algorithms 301 These algorithms are distinguished from those in Section 2.2 above in 302 that they use public key methods. That is to say, the verification 303 key is different from and not feasibly derivable from the signing 304 key. 306 2.3.1 RSA-MD5 308 Identifier: 309 http://www.w3.org/2001/04/xmldsig-more#rsa-md5 311 This implies the PKCS#1 v1.5 padding algorithm described in 312 [RFC3447]. An example of use is 314 318 The SignatureValue content for an RSA-MD5 signature is the base64 319 [RFC2045] encoding of the octet string computed as per [RFC3447] 320 section 8.1.1?, signature generation for the RSASSA-PKCS1-v1_5 321 signature scheme. As specified in the EMSA-PKCS1-V1_5-ENCODE function 322 in [RFC3447] section 9.2.1?, the value input to the signature 323 function MUST contain a pre-pended algorithm object identifier for 324 the hash function, but the availability of an ASN.1 parser and 325 recognition of OIDs is not required of a signature verifier. The 326 PKCS#1 v1.5 representation appears as: 328 CRYPT (PAD (ASN.1 (OID, DIGEST (data)))) 330 Note that the padded ASN.1 will be of the following form: 332 01 | FF* | 00 | prefix | hash 334 Vertical bar ("|") represents concatenation. "01", "FF", and "00" are 335 fixed octets of the corresponding hexadecimal value and the asterisk 336 ("*") after "FF" indicates repetition. "hash" is the MD5 digest of 337 the data. "prefix" is the ASN.1 BER MD5 algorithm designator prefix 338 required in PKCS #1 [RFC3447], that is, 340 hex 30 20 30 0c 06 08 2a 86 48 86 f7 0d 02 05 05 00 04 10 342 This prefix is included to make it easier to use standard 343 cryptographic libraries. The FF octet MUST be repeated enough times 344 that the value of the quantity being CRYPTed is exactly one octet 345 shorter than the RSA modulus. 347 Due to increases in computer processor power and advances in 348 cryptography, use of RSA-MD5 is NOT RECOMMENDED. 350 2.3.2 RSA-SHA256 352 Identifier: 353 http://www.w3.org/2001/04/xmldsig-more#rsa-sha256 355 This implies the PKCS#1 v1.5 padding algorithm [RFC3447] as described 356 in section 2.3.1 but with the ASN.1 BER SHA-256 algorithm designator 357 prefix. An example of use is 359 362 2.3.3 RSA-SHA384 364 Identifier: 365 http://www.w3.org/2001/04/xmldsig-more#rsa-sha384 367 This implies the PKCS#1 v1.5 padding algorithm [RFC3447] as described 368 in section 2.3.1 but with the ASN.1 BER SHA-384 algorithm designator 369 prefix. An example of use is 371 374 Because it takes about the same effort to calculate a SHA-384 message 375 digest as it does a SHA-512 message digest, it is suggested that RSA- 376 SHA512 be used in preference to RSA-SHA384 where possible. 378 2.3.4 RSA-SHA512 380 Identifier: 381 http://www.w3.org/2001/04/xmldsig-more#rsa-sha512 383 This implies the PKCS#1 v1.5 padding algorithm [RFC3447] as described 384 in section 2.3.1 but with the ASN.1 BER SHA-512 algorithm designator 385 prefix. An example of use is 387 391 2.3.5 RSA-RIPEMD160 393 Identifier: 394 http://www.w3.org/2001/04/xmldsig-more#rsa-ripemd160 396 This implies the PKCS#1 v1.5 padding algorithm [RFC3447] as described 397 in section 2.3.1 but with the ASN.1 BER RIPEMD160 algorithm 398 designator prefix. An example of use is 400 404 2.3.6 ECDSA-SHA* and RIPEMD160 406 Identifiers 407 http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha1 408 http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha224 409 http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha256 410 http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha384 411 http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha512 412 http://www.w3.org/2007/05/xmldsig-more#ecdsa-ripemd160 414 The Elliptic Curve Digital Signature Algorithm (ECDSA) [FIPS 186-2] 415 is the elliptic curve analogue of the DSA (DSS) signature method. For 416 a detailed specifications of how to use it with SHA hash functions 417 and XML Digital Signature, please see [X9.62] and [RFC4050]. The 418 #ecdsa-ripemd160 fragment of the new namespace identifies a signature 419 method processed in the same way as specified by the #ecdsa-sha1 420 fragment of this namespace with the exception that RIPEMD160 is used 421 instead of SHA-1. 423 2.3.7 ESIGN-SHA1 425 Identifier 426 http://www.w3.org/2001/04/xmldsig-more#esign-sha1 427 http://www.w3.org/2001/04/xmldsig-more#esign-sha224 428 http://www.w3.org/2001/04/xmldsig-more#esign-sha256 429 http://www.w3.org/2001/04/xmldsig-more#esign-sha384 430 http://www.w3.org/2001/04/xmldsig-more#esign-sha512 432 The ESIGN algorithm specified in [IEEE P1363a] is a signature scheme 433 based on the integer factorization problem. It is much faster than 434 previous digital signature schemes so ESIGN can be implemented on 435 smart cards without special co-processors. 437 An example of use is 439 443 2.4 Minimal Canonicalization 445 Thus far two independent interoperable implementations of Minimal 446 Canonicalization have not been announced. Therefore, when XML 447 Digital Signature was advanced from Proposed Standard [RFC3075] to 448 Draft Standard [RFC3275], Minimal Canonicalization was dropped from 449 the standard track documents. However, there is still interest. For 450 its definition, see [RFC3075] Section 6.5.1. 452 For reference, it's identifier remains: 453 http://www.w3.org/2000/09/xmldsig#minimal 455 2.5 Transform Algorithms 457 Note that all CanonicalizationMethod algorithms can also be used as 458 Transform algorithms. 460 2.5.1 XPointer 462 Identifier: 463 http://www.w3.org/2001/04/xmldsig-more#xptr 465 This transform algorithm takes an [XPointer] as an explicit 466 parameter. An example of use is: 468 470 472 xpointer(id("foo")) xmlns(bar=http://foobar.example) 473 xpointer(//bar:Zab[@Id="foo"]) 474 475 477 Schema Definition: 479 481 DTD: 483 485 Input to this transform is an octet stream (which is then parsed into 486 XML). 488 Output from this transform is a node set; the results of the XPointer 489 are processed as defined in the XMLDSIG specification [RFC3275] for a 490 same-document XPointer. 492 2.6 EncryptionMethod Algorithms 494 This subsection gives identifiers and information for several 495 EncryptionMethod Algorithms. 497 2.6.1 ARCFOUR Encryption Algorithm 499 Identifier: 500 http://www.w3.org/2001/04/xmldsig-more#arcfour 502 ARCFOUR is a fast, simple stream encryption algorithm that is 503 compatible with RSA Security's RC4 algorithm. An example 504 EncryptionMethod element using ARCFOUR is 505 507 40 508 510 Note that Arcfour makes use of the generic KeySize parameter 511 specified and defined in [XMLENC]. 513 2.6.2 Camellia Block Encryption 515 Identifiers: 516 http://www.w3.org/2001/04/xmldsig-more#camellia128-cbc 517 http://www.w3.org/2001/04/xmldsig-more#camellia192-cbc 518 http://www.w3.org/2001/04/xmldsig-more#camellia256-cbc 520 Camellia is an efficient and secure block cipher with the same 521 interface as the AES [Camellia] [RFC3713], that is 128-bit block size 522 and 128, 192, and 256 bit key sizes. In XML Encryption Camellia is 523 used in the same way as the AES: It is used in the Cipher Block 524 Chaining (CBC) mode with a 128-bit initialization vector (IV). The 525 resulting cipher text is prefixed by the IV. If included in XML 526 output, it is then base64 encoded. An example Camellia 527 EncryptionMethod is as follows: 529 534 2.6.3 Camellia Key Wrap 536 Identifiers: 537 http://www.w3.org/2001/04/xmldsig-more#kw-camellia128 538 http://www.w3.org/2001/04/xmldsig-more#kw-camellia192 539 http://www.w3.org/2001/04/xmldsig-more#kw-camellia256 541 Camellia [Camellia] [RFC3713] key wrap is identical to the AES key 542 wrap algorithm [RFC3394] specified in the XML Encryption standard 543 with "AES" replaced by "Camellia". As with AES key wrap, the check 544 value is 0xA6A6A6A6A6A6A6A6. 546 The algorithm is the same whatever the size of the Camellia key used 547 in wrapping, called the key encrypting key or KEK. The implementation 548 of Camellia is OPTIONAL. However, if it is supported, the same 549 implementation guidelines as to which combinations of KEK size and 550 wrapped key size should be required to be supported and which are 551 optional to be supported should be followed. That is to say, if 552 Camellia key wrap is supported, they wrapping 128-bit keys with a 553 128-bit KEK and wrapping 256-bit keys with a 256-bit KEK are REQUIRED 554 and all other combinations are OPTIONAL. 556 An example of use is: 558 563 2.6.4 PSEC-KEM 565 Identifier: 566 http://www.w3.org/2001/04/xmldsig-more#psec-kem 568 The PSEC-KEM algorithm, specified in [18033-2], is a key 569 encapsulation mechanism using elliptic curve encryption. 571 An example of use is: 573 575 576 version 577 id 578 curve 579 base 580 order 581 cofactor 582 583 585 See [18033-2] for information on the parameters above. 587 3. KeyInfo 589 In section 3.1 below a new KeyInfo element child is specified while 590 in section 3.2 additional KeyInfo Type values for use in 591 RetrievalMethod are specified. 593 3.1 PKCS #7 Bag of Certificates and CRLs 595 A PKCS #7 [RFC2315] "signedData" can also be used as a bag of 596 certificates and/or certificate revocation lists (CRLs). The 597 PKCS7signedData element is defined to accommodate such structures 598 within KeyInfo. The binary PKCS #7 structure is base64 [RFC2045] 599 encoded. Any signer information present is ignored. The following 600 is a example [RFC3092], eliding the base64 data: 602 604 ... 605 607 3.2 Additional RetrievalMethod Type Values 609 The Type attribute of RetrievalMethod is an optional identifier for 610 the type of data to be retrieved. The result of de-referencing a 611 RetrievalMethod reference for all KeyInfo types with an XML structure 612 is an XML element or document with that element as the root. The 613 various "raw" key information types return a binary value. Thus they 614 require a Type attribute because they are not unambiguously 615 parseable. 617 Identifiers: 618 http://www.w3.org/2001/04/xmldsig-more#KeyValue 619 http://www.w3.org/2001/04/xmldsig-more#RetrievalMethod 620 http://www.w3.org/2001/04/xmldsig-more#KeyName 621 http://www.w3.org/2001/04/xmldsig-more#rawX509CRL 622 http://www.w3.org/2001/04/xmldsig-more#rawPGPKeyPacket 623 http://www.w3.org/2001/04/xmldsig-more#rawSPKISexp 624 http://www.w3.org/2001/04/xmldsig-more#PKCS7signedData 625 http://www.w3.org/2001/04/xmldsig-more#rawPKCS7signedData 627 4. URI Index 629 The following is an index by URI of the algorithm and KeyInfo URIs 630 defined in this document and in the standards (plus the one KeyInfo 631 child element name defined in this document). The "Sec/Doc" column 632 has the section of this document or, if not specified in this 633 document, the standards document where the item is specified. 635 The initial "http://www.w3.org/" part of the URI is not included: 637 URI Sec/Doc Type 638 --- ------- ---- 640 2000/09/xmldsig#base64 [RFC3275] Transform 641 2000/09/xmldsig#dsa-sha1 [RFC3275] SignatureMethod 642 2000/09/xmldsig#enveloped-signature [RFC3275] Transform 643 2000/09/xmldsig@hmac-sha1 [RFC3275] SignatureMethod 644 2000/09/xmldsig#minimal 2.4 Canonicalization 645 2000/09/xmldsig@rsa-sha1 [RFC3275] SignatureMethod 646 2000/09/xmldsig#sha1 [RFC3275] DigestAlgorithm 648 2001/04/xmldsig-more#arcfour 2.6.1 EncryptionMethod 649 2001/04/xmldsig-more#camellia128-cbc 2.6.2 EncryptionMethod 650 2001/04/xmldsig-more#camellia192-cbc 2.6.2 EncryptionMethod 651 2001/04/xmldsig-more#camellia256-cbc 2.6.2 EncryptionMethod 652 2001/04/xmldsig-more#ecdsa-sha1 2.3.6 SignatureMethod 653 2001/04/xmldsig-more#ecdsa-sha224 2.3.6 SignatureMethod 654 2001/04/xmldsig-more#ecdsa-sha256 2.3.6 SignatureMethod 655 2001/04/xmldsig-more#ecdsa-sha384 2.3.6 SignatureMethod 656 2001/04/xmldsig-more#ecdsa-sha512 2.3.6 SignatureMethod 657 2001/04/xmldsig-more#esign-sha1 2.3.7 SignatureMethod 658 2001/04/xmldsig-more#esign-sha224 2.3.7 SignatureMethod 659 2001/04/xmldsig-more#esign-sha256 2.3.7 SignatureMethod 660 2001/04/xmldsig-more#esign-sha384 2.3.7 SignatureMethod 661 2001/04/xmldsig-more#esign-sha512 2.3.7 SignatureMethod 662 2001/04/xmldsig-more#hmac-md5 2.2.1 SignatureMethod 663 2001/04/xmldsig-more#hmac-ripemd160 2.2.3 SignatureMethod 664 2001/04/xmldsig-more#hmac-sha224 2.2.2 SignatureMethod 665 2001/04/xmldsig-more#hmac-sha256 2.2.2 SignatureMethod 666 2001/04/xmldsig-more#hmac-sha384 2.2.2 SignatureMethod 667 2001/04/xmldsig-more#hmac-sha512 2.2.2 SignatureMethod 668 2001/04/xmldsig-more#KeyName 3.2 Retrieval type 669 2001/04/xmldsig-more#KeyValue 3.2 Retrieval type 670 2001/04/xmldsig-more#kw-camellia128 2.6.3 EncryptionMethod 671 2001/04/xmldsig-more#kw-camellia192 2.6.3 EncryptionMethod 672 2001/04/xmldsig-more#kw-camellia256 2.6.3 EncryptionMethod 673 2001/04/xmldsig-more#md5 2.1.1 DigestAlgorithm 674 2001/04/xmldsig-more#PKCS7signedData 3.2 Retrieval type 675 2001/04/xmldsig-more#psec-kem 2.6.4 EncryptionMethod 676 2001/04/xmldsig-more#rawPGPKeyPacket 3.2 Retrieval type 677 2001/04/xmldsig-more#rawPKCS7signedData 3.2 Retrieval type 678 2001/04/xmldsig-more#rawSPKISexp 3.2 Retrieval type 679 2001/04/xmldsig-more#rawX509CRL 3.2 Retrieval type 680 2001/04/xmldsig-more#RetrievalMethod 3.2 Retrieval type 681 2001/04/xmldsig-more#rsa-md5 2.3.1 SignatureMethod 682 2001/04/xmldsig-more#rsa-sha256 2.3.2 SignatureMethod 683 2001/04/xmldsig-more#rsa-sha384 2.3.3 SignatureMethod 684 2001/04/xmldsig-more#rsa-sha512 2.3.4 SignatureMethod 685 2001/04/xmldsig-more#rsa-ripemd160 2.3.5 SignatureMethod 686 2001/04/xmldsig-more#sha224 2.1.2 DigestAlgorithm 687 2001/04/xmldsig-more#sha384 2.1.3 DigestAlgorithm 688 2001/04/xmldsig-more#xptr 2.5.1 Transform 689 2001/04/xmldsig-more:PKCS7signedData 3.1 KeyInfo child 691 2001/04/xmlenc#aes128-cbc [XMLENC] EncryptionMethod 692 2001/04/xmlenc#aes192-cbc [XMLENC] EncryptionMethod 693 2001/04/xmlenc#aes256-cbc [XMLENC] EncryptionMethod 694 2001/04/xmlenc#dh [XMLENC] AgreementMethod 695 2001/04/xmlenc#kw-aes128 [XMLENC] EncryptionMethod 696 2001/04/xmlenc#kw-aes192 [XMLENC] EncryptionMethod 697 2001/04/xmlenc#kw-aes256 [XMLENC] EncryptionMethod 698 2001/04/xmlenc#ripemd160 [XMLENC] DigestAlgorithm 699 2001/04/xmlenc#rsa-1_5 [XMLENC] EncryptionMethod 700 2001/04/xmlenc#rsa-oaep-mbg1p [XMLENC] EncryptionMethod 701 2001/04/xmlenc#sha256 [XMLENC] DigestAlgorithm 702 2001.04/xmlend#sha512 [XMLENC] DigestAlgorithm 703 2001/04/xmlenc#tripledes-cbc [XMLENC] EncryptionMethod 705 2007/05/xmldsig-more#ecdsa-ripemd160 2.3.6 SignatureMethod 707 TR/1999/REC-xpath-19991116 [XPATH] Transform 708 TR/1999/REC-xslt-19991116 [XSLT] Transform 709 TR/2001/06/xml-excl-c14n# [XCANON] Canonicalization 710 TR/2001/06/xml-excl-c14n#WithComments 711 [XCANON] Canonicalization 712 TR/2001/REC-xml-c14n-20010315 [CANON] Canonicalization 713 TR/2001/REC-xml-c14n-20010315#WithComments 714 [CANON] Canonicalization 715 TR/2001/REC-xmlschema-1-20010502 [Schema] Transform 717 5. Fragment Index 719 The following is an index as in Section 4 but sorted by the fragment 720 portion of the URI: 722 Prefix Fragment Sec/Doc Type 723 ------ -------- ------- ---- 725 TBD 727 6. IANA Considerations 729 None. 731 As it is easy for people to construct their own unique URIs [RFC3986] 732 and, if appropriate, to obtain a URI from the W3C, it is not intended 733 that any additional "http://www.w3.org/2007/05/xmldsig-more#" URIs be 734 created beyond those enumerated in this RFC. (W3C Namespace stability 735 rules prohibit the creation of new URIs under 736 "http://www.w3.org/2000/09/xmldsig#" and URIs under 737 "http"//www.w3.org/2001/04/#xmldsig-more" were frozen with the 738 publication of [RFC4051].) 740 7. Security Considerations 742 Due to computer speed and cryptographic advances, the use of MD5 as a 743 DigestMethod or in the RSA-MD5 SignatureMethod is NOT RECOMMENDED. 744 The cryptographic advances concerned do not effect the security of 745 HMAC-MD5; however, there is little reason not to go for one of the 746 SHA series of algorithms. 748 Additional security considerations are given in connection with the 749 description of some algorithms in the body of this document. 751 Normative References 753 [18033-2] - "Information technology -- Security techniques -- 754 Encryption algorithms -- Part 3: Asymmetric ciphers", ISO/IEC 755 18033-2, October 2002. 757 [Camellia] - "Camellia: A 128-bit Block Cipher Suitable for Multiple 758 Platforms - Design and Analysis -", K. Aoki, T. Ichikawa, M. Matsui, 759 S. Moriai, J. Nakajima, T. Tokita, In Selected Areas in Cryptography, 760 7th Annual International Workshop, SAC 2000, August 2000, 761 Proceedings, Lecture Notes in Computer Science 2012, pp. 39-56, 762 Springer-Verlag, 2001. 764 [FIPS 180-2] - "Secure Hash Standard", (SHA-1/256/384/512) US Federal 765 Information Processing Standard, Draft, not yet issued. 767 [FIPS 180-2change] - "FIPS 180-2, Secure Hash Standard Change Notice 768 1", adds SHA-224 to [FIPS 180-2]. 770 [FIPS 186-2] - "Digital Signature Standard", National Institute of 771 Standards and Technology, 2000. 773 [IEEE P1363a] - "Standard Specifications for Public Key Cryptography: 774 Additional Techniques", October 2002. 776 [RFC1321] - Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 777 April 1992. 779 [RFC2045] - Freed, N. and N. Borenstein, "Multipurpose Internet Mail 780 Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 781 2045, November 1996. 783 [RFC2104] - Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 784 Hashing for Message Authentication", RFC 2104, February 1997. 786 [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate 787 Requirement Levels", BCP 14, RFC 2119, March 1997. 789 [RFC2315] - Kaliski, B., "PKCS #7: Cryptographic Message Syntax 790 Version 1.5", RFC 2315, March 1998. 792 [RFC3275] - Eastlake 3rd, D., Reagle, J., and D. Solo, "(Extensible 793 Markup Language) XML-Signature Syntax and Processing", RFC 3275, 794 March 2002. 796 [RFC3394] - Schaad, J. and R. Housley, "Advanced Encryption Standard 797 (AES) Key Wrap Algorithm", RFC 3394, September 2002. 799 [RFC3447] - Jonsson, J. and B. Kaliski, "Public-Key Cryptography 800 Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", 801 RFC 3447, February 2003. 803 [RFC3713] - Matsui, M., Nakajima, J., and S. Moriai, "A Description 804 of the Camellia Encryption Algorithm", RFC 3713, April 2004. 806 [RFC3986] - Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 807 Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 808 2005. 810 [RFC4050] - Blake-Wilson, S., Karlinger, G., Kobayashi, T., and Y. 811 Wang, "Using the Elliptic Curve Signature Algorithm (ECDSA) for XML 812 Digital Signatures", RFC 4050, April 2005. 814 [RFC4634] - Eastlake 3rd, D. and T. Hansen, "US Secure Hash 815 Algorithms (SHA and HMAC-SHA)", RFC 4634, July 2006. 817 [RIPEMD-160] - ISO/IEC 10118-3:1998, "Information Technology - 818 Security techniques - Hash-functions - Part3: Dedicated hash- 819 functions", ISO, 1998. 821 [X9.62] - X9.62-200X, "Public Key Cryptography for the Financial 822 Services Industry: The Elliptic Curve Digital Signature Algorithm 823 (ECDSA)", Accredited Standards Committee X9, American National 824 Standards Institute. 826 [XMLENC] - "XML Encryption Syntax and Processing", J. Reagle, D. 827 Eastlake, December 2002. 830 [XPointer] - "XML Pointer Language (XPointer) Version 1.0", W3C 831 working draft, Steve DeRose, Eve Maler, Ron Daniel Jr., January 2001. 832 834 Informative References 836 [CANON] - John Boyer. "Canonical XML Version 1.0", 837 . 839 [RFC3075] - Eastlake 3rd, D., Reagle, J., and D. Solo, "XML-Signature 840 Syntax and Processing", RFC 3075, March 2001. 842 [RFC3076] - Boyer, J., "Canonical XML Version 1.0", RFC 3076, March 843 2001. 845 [RFC3092] - Eastlake 3rd, D., Manros, C., and E. Raymond, "Etymology 846 of "Foo"", RFC 3092, April 1 2001. 848 [RFC3741] - Boyer, J., Eastlake 3rd, D., and J. Reagle, "Exclusive 849 XML Canonicalization, Version 1.0", RFC 3741, March 2004. 851 [RFC4051] - Eastlake 3rd, D., "Additional XML Security Uniform 852 Resource Identifiers (URIs)", RFC 4051, April 2005. 854 [Schema] - 856 [W3C] - World Wide Web Consortium, . 858 [XCANON] - "Exclusive XML Canonicalization Version 1.0", D. 859 Eastlake, J. Reagle, 18 July 2002. . 862 [XMLDSIG] - 864 [XPATH] - 866 [XSLT] - 868 Changes from RFC 4051 870 Note to RFC Editor: This section should be deleted on publication. 872 1. Update numerous RFC and Internet-Draft references. 874 2. Add #ecdsa-ripemd160. 876 3. Incorporate RFC 4051 errata. 878 4. Add URI and Fragment index sections. 880 Disclaimer 882 This document and the information contained herein are provided on an 883 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 884 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 885 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 886 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 887 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 888 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 890 Additional IPR Provisions 892 The IETF takes no position regarding the validity or scope of any 893 Intellectual Property Rights or other rights that might be claimed to 894 pertain to the implementation or use of the technology described in 895 this document or the extent to which any license under such rights 896 might or might not be available; nor does it represent that it has 897 made any independent effort to identify any such rights. Information 898 on the procedures with respect to rights in RFC documents can be 899 found in BCP 78 and BCP 79. 901 Copies of IPR disclosures made to the IETF Secretariat and any 902 assurances of licenses to be made available, or the result of an 903 attempt made to obtain a general license or permission for the use of 904 such proprietary rights by implementers or users of this 905 specification can be obtained from the IETF on-line IPR repository at 906 http://www.ietf.org/ipr. 908 The IETF invites any interested party to bring to its attention any 909 copyrights, patents or patent applications, or other proprietary 910 rights that may cover technology that may be required to implement 911 this standard. Please address the information to the IETF at ietf- 912 ipr@ietf.org. 914 Copyright (C) The IETF Trust (2007). 916 This document is subject to the rights, licenses and restrictions 917 contained in BCP 78, and except as set forth therein, the authors 918 retain all their rights. 920 Author's Address 922 Donald E. Eastlake 3rd 923 Motorola Laboratories 924 155 Beaver Street 925 Milford, MA 01757 USA 927 Telephone: +1-508-786-7554 (w) 928 EMail: Donald.Eastlake@motorola.com 930 Expiration and File Name 932 This draft expires in May 2008. 934 Its file name is draft-eastlake-additional-xmlsec-uris-00.txt