idnits 2.17.1 draft-eastlake-xmldsig-uri-09.txt: -(93): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(131): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(727): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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 3667, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 626. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3978 Section 5.4 (updated by RFC 4748) Copyright Line. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == There are 6 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Authors' Addresses Section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (September 2004) is 7163 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'W3C' is mentioned on line 100, but not defined == Missing Reference: 'XMLDSIG' is mentioned on line 106, but not defined == Missing Reference: 'RFC 2045' is mentioned on line 159, but not defined == Missing Reference: 'RFC2045' is mentioned on line 192, but not defined == Unused Reference: 'FIPS 180-1' is defined on line 641, but no explicit reference was found in the text == Unused Reference: 'RFC 2119' is defined on line 666, but no explicit reference was found in the text == Unused Reference: 'RFC 3874' is defined on line 696, but no explicit reference was found in the text == Unused Reference: 'RFC 3092' is defined on line 727, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'Camellia' -- No information found for draft-blake-wilson-xmldsig-ecdsa- - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'ECDSA' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS 180-1' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS 180-2' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS 186-2' ** Downref: Normative reference to an Informational RFC: RFC 1321 ** Downref: Normative reference to an Informational RFC: RFC 2104 ** Obsolete normative reference: RFC 2396 (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 2437 (Obsoleted by RFC 3447) ** Downref: Normative reference to an Informational RFC: RFC 2315 -- Duplicate reference: RFC3275, mentioned in 'RFC 3275', was also mentioned in 'RFC 3075'. ** Downref: Normative reference to an Informational RFC: RFC 3394 ** Downref: Normative reference to an Informational RFC: RFC 3713 ** Downref: Normative reference to an Informational RFC: RFC 3874 -- Possible downref: Non-RFC (?) normative reference: ref. 'RIPEMD-160' -- Possible downref: Non-RFC (?) normative reference: ref. 'XMLENC' -- Possible downref: Non-RFC (?) normative reference: ref. 'XPointer' Summary: 19 errors (**), 0 flaws (~~), 11 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Donald E. Eastlake 3rd 2 Motorola Laboratories 3 Expires: March 2005 September 2004 5 Additional XML Security URIs 6 ---------- --- -------- ---- 7 9 Donald E. Eastlake 3rd 11 Status of This Document 12 By submitting this Internet-Draft, I certify that any applicable 13 patent or other IPR claims of which I am aware have been disclosed, 14 or will be disclosed, and any of which I become aware will be 15 disclosed, in accordance with RFC 3668. 17 Distribution of this document is unlimited. Comments should be sent 18 to the author. Internet-Drafts are working documents of the Internet 19 Engineering Task Force (IETF), its areas, and its working groups. 20 Note that other groups may also distribute working documents as 21 Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than a "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/1id-abstracts.html 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 Copyright (C) 2004 The Internet Society. All Right Reserved. 36 Abstract 38 A number of URIs intended for use with XML Digital Signatures, 39 Encryption, and Canonnicalization are defined. These URIs identify 40 algorithms and types of keying information. 42 Acknowledgements 44 Glenn Adams, Merlin Hughs, Gregor Karlinger, Brian LaMachia, Shiho 45 Moriai, Joseph Reagle, Russ Housley, and Joel Halpern. 47 Table of Contents 49 Status of This Document....................................1 50 Abstract...................................................1 51 Acknowledgements...........................................1 53 Table of Contents..........................................2 55 1. Introduction............................................3 57 2. Algorithms..............................................4 58 2.1 DigestMethod Algorithms................................4 59 2.1.1 MD5..................................................4 60 2.1.2 SHA-224..............................................4 61 2.1.3 SHA-384..............................................5 62 2.2 SignatureMethod Message Authentication Code Algorithms.5 63 2.2.1 HMAC-MD5.............................................5 64 2.2.2 HMAC SHA Variations..................................6 65 2.2.3 HMAC-RIPEMD160.......................................7 66 2.3 SignatureMethod Public Key Signature Algorithms........7 67 2.3.1 RSA-MD5..............................................7 68 2.3.2 RSA-SHA256...........................................8 69 2.3.3 RSA-SHA384...........................................8 70 2.3.4 RSA-SHA512...........................................9 71 2.3.5 RSA-RIPEMD160........................................9 72 2.3.6 ECDSA-SHA*...........................................9 73 2.3.7 ESIGN-SHA1...........................................9 74 2.4 Minimal Canonicalization..............................10 75 2.5 Transform Algorithms..................................10 76 2.5.1 XPointer............................................10 77 2.6 EncryptionMethod Algorithms...........................11 78 2.6.1 ARCFOUR Encryption Algorithm........................11 79 2.6.2 Camellia Block Encryption...........................12 80 2.6.3 Camellia Key Wrap...................................12 81 2.6.4 PSEC-KEM............................................13 82 3. KeyInfo................................................13 83 3.1 PKCS #7 Bag of Certificates and CRLs..................13 84 3.2 Additional RetrievalMethod Type Values................14 86 4. IANA Considerations....................................15 87 5. Security Considerations................................15 88 6. Copyright and Disclaimer...............................15 90 Normative References......................................16 91 Informative References....................................17 93 Author���s Address..........................................19 94 Expiration and File Name..................................19 96 1. Introduction 98 XML Digital Signatures, Canonicalization, and Encryption have been 99 standardized by the W3C and by the joint IETF/W3C XMLDSIG working 100 group [W3C]. All of these are now W3C Recommendations and IETF 101 Informational or Standards Track documents. They are available as 102 follows: 104 IETF level W3C REC Topic 105 ----------- ------- ----- 106 [RFC 3275] Draft Std [XMLDSIG] XML Digital Signatures 107 [RFC 3076] Info [CANON] Canonical XML 108 - - - - - - [XMLENC] XML Encryption 109 [RFC 3741] Info [EXCANON] Exclusive XML Canonicalization 111 All of these standards and recommendations use URIs [RFC 2396] to 112 identify algorithms and keying information types. This document is a 113 convenient reference list of URIs and descriptions for algorithms in 114 which there is substantial interest but which can not or have not 115 been included in the main documents for some reason. Note in 116 particular that raising XML digital signature to Draft Standard in 117 the IETF required remove of any algorithms for which there was not 118 demonstrated interoperability from the main standards document. This 119 required removal of the Minimal Canonicalization algorithm, in which 120 there appears to be continued interest, to be dropped from the 121 standards track specification. It is included here. 123 2. Algorithms 125 The URI [RFC 2396] being dropped from the standard due to the 126 transition from Proposed Standard to Draft Standard is included in 127 Section 2.4 below with its original 129 http://www.w3.org/2000/09/xmldsig# 131 prefix so as to avoid changing the XMLDSIG standard���s namespace. 133 Additional algorithms are given URIs that start with 135 http://www.w3.org/2001/04/xmldsig-more# 137 An "xmldsig-more" URI does not imply any official W3C status for 138 these algorithms or identifiers nor does it imply that they are only 139 useful in digital signatures. Currently, dereferencing such URIs may 140 or may not produce a temporary placeholder document. Permission to 141 use these this URI prefix has been given by the W3C. 143 2.1 DigestMethod Algorithms 145 These algorithms are usable wherever a DigestMethod element occurs. 147 2.1.1 MD5 149 Identifier: 150 http://www.w3.org/2001/04/xmldsig-more#md5 152 The MD5 algorithm [RFC 1321] takes no explicit parameters. An example 153 of an MD5 DigestAlgorithm element is: 155 158 An MD5 digest is a 128-bit string. The content of the DigestValue 159 element shall be the base64 [RFC 2045] encoding of this bit string 160 viewed as a 16-octet octet stream. 162 2.1.2 SHA-224 164 Identifier: 165 http://www.w3.org/2001/04/xmldsig-more#sha224 167 The SHA-224 algorithm [FIPS 180-2change, RFC 3874] takes no explicit 168 parameters. An example of a SHA-224 DigestAlgorithm element is: 170 173 A SHA-224 digest is a 224 bit string. The content of the DigestValue 174 element shall be the base64 [RFC2045] encoding of this string viewed 175 as a 28-octet stream. Because it takes roughly the same amount of 176 effort to compute a SHA-224 message digest as a SHA-256 digest and 177 terseness is usually not a criteria in XML application, consideration 178 should be given to the use of SHA-256 as an alternative. 180 2.1.3 SHA-384 182 Identifier: 183 http://www.w3.org/2001/04/xmldsig-more#sha384 185 The SHA-384 algorithm [FIPS 180-2] takes no explicit parameters. An 186 example of a SHA-384 DigestAlgorithm element is: 188 191 A SHA-384 digest is a 384 bit string. The content of the DigestValue 192 element shall be the base64 [RFC2045] encoding of this string viewed 193 as a 48-octet stream. Because it takes roughly the same amount of 194 effort to compute a SHA-384 message digest as a SHA-512 digest and 195 terseness is usually not a criteria in XML application, consideration 196 should be given to the use of SHA-512 as an alternative. 198 2.2 SignatureMethod Message Authentication Code Algorithms 200 Note: Some text in this section is duplicated from [RFC 3275] for the 201 convenience of the reader. 3275 is normative in case of conflict. 203 2.2.1 HMAC-MD5 205 Identifier: 206 http://www.w3.org/2001/04/xmldsig-more#hmac-md5 208 The HMAC algorithm [RFC 2104] takes the truncation length in bits as 209 a parameter; if the parameter is not specified then all the bits of 210 the hash are output. An example of an HMAC-MD5 SignatureMethod 211 element is as follows: 213 215 112 216 218 The output of the HMAC algorithm is ultimately the output (possibly 219 truncated) of the chosen digest algorithm. This value shall be base64 220 [RFC 2405] encoded in the same straightforward fashion as the output 221 of the digest algorithms. Example: the SignatureValue element for the 222 HMAC-MD5 digest 224 9294727A 3638BB1C 13F48EF8 158BFC9D 226 from the test vectors in [RFC 2104] would be 228 kpRyejY4uxwT9I74FYv8nQ== 230 Schema Definition: 232 233 234 236 DTD: 238 240 The Schema Definition and DTD immediately above are copied from [RFC 241 3275]. 243 Although some cryptographic suspicions have recently been cast on MD5 244 for use in signatures such as RSA-MD5 below, this does not effect use 245 of MD5 in HMAC. 247 2.2.2 HMAC SHA Variations 249 Identifiers: 250 http://www.w3.org/2001/04/xmldsig-more#hmac-sha224 251 http://www.w3.org/2001/04/xmldsig-more#hmac-sha256 252 http://www.w3.org/2001/04/xmldsig-more#hmac-sha384 253 http://www.w3.org/2001/04/xmldsig-more#hmac-sha512 255 SHA-224, SHA-256, SHA-384, and SHA-512 [FIPS 180-2, FIPS 180-2change, 256 RFC 3874] can also be used in HMAC as described in section 2.2.1 257 above for HMAC-MD5. 259 2.2.3 HMAC-RIPEMD160 261 Identifier: 262 http://www.w3.org/2001/04/xmldsig-more#hmac-ripemd160 264 RIPEMD-160 [RIPEMD-160] can also be used in HMAC as described in 265 section 2.2.1 above for HMAC-MD5. 267 2.3 SignatureMethod Public Key Signature Algorithms 269 These algorithms are distinguished from those in Section 2.2 above in 270 that they use public key methods. That is to say, the verification 271 key is different from and not feasibly derivable from the signing 272 key. 274 2.3.1 RSA-MD5 276 Identifier: 277 http://www.w3.org/2001/04/xmldsig-more#rsa-md5 279 This implies the PKCS#1 v1.5 padding algorithm described in [RFC 280 2437]. An example of use is 282 286 The SignatureValue content for an RSA-MD5 signature is the base64 287 [RFC 2405] encoding of the octet string computed as per [RFC 2437], 288 section 8.1.1, signature generation for the RSASSA-PKCS1-v1_5 289 signature scheme. As specified in the EMSA-PKCS1-V1_5-ENCODE function 290 in [RFC 2437, section 9.2.1], the value input to the signature 291 function MUST contain a pre-pended algorithm object identifier for 292 the hash function, but the availability of an ASN.1 parser and 293 recognition of OIDs is not required of a signature verifier. The 294 PKCS#1 v1.5 representation appears as: 296 CRYPT (PAD (ASN.1 (OID, DIGEST (data)))) 298 Note that the padded ASN.1 will be of the following form: 300 01 | FF* | 00 | prefix | hash 302 Vertical bar ("|") represents concatenation. "01", "FF", and "00" are 303 fixed octets of the corresponding hexadecimal value and the asterisk 304 ("*") after "FF" indicates repetition. "hash" is the MD5 digest of 305 the data. "prefix" is the ASN.1 BER MD5 algorithm designator prefix 306 required in PKCS #1 [RFC 2437], that is, 308 hex 30 20 30 0c 06 08 2a 86 48 86 f7 0d 02 05 05 00 04 10 310 This prefix is included to make it easier to use standard 311 cryptographic libraries. The FF octet MUST be repeated enough times 312 that the value of the quantity being CRYPTed is exactly one octet 313 shorter than the RSA modulus. 315 Due to increases in computer processor power and advances in 316 cryptography, use of RSA-MD5 is NOT RECOMMENDED. 318 2.3.2 RSA-SHA256 320 Identifier: 321 http://www.w3.org/2001/04/xmldsig-more#rsa-sha256 323 This implies the PKCS#1 v1.5 padding algorithm [RFC 2437] as 324 described in section 2.3.1 but with the ASN.1 BER SHA-256 algorithm 325 designator prefix. An example of use is 327 330 2.3.3 RSA-SHA384 332 Identifier: 333 http://www.w3.org/2001/04/xmldsig-more#rsa-sha384 335 This implies the PKCS#1 v1.5 padding algorithm [RFC 2437] as 336 described in section 2.3.1 but with the ASN.1 BER SHA-384 algorithm 337 designator prefix. An example of use is 339 343 Because it takes about the same effort to calculate a SHA-384 message 344 digest as it does a SHA-512 message digest, it is suggested that RSA- 345 SHA512 be used in preference to RSA-SHA384 where possible. 347 2.3.4 RSA-SHA512 349 Identifier: 350 http://www.w3.org/2001/04/xmldsig-more#rsa-sha512 352 This implies the PKCS#1 v1.5 padding algorithm [RFC 2437] as 353 described in section 2.3.1 but with the ASN.1 BER SHA-512 algorithm 354 designator prefix. An example of use is 356 360 2.3.5 RSA-RIPEMD160 362 Identifier: 363 http://www.w3.org/2001/04/xmldsig-more/rsa-ripemd160 365 This implies the PKCS#1 v1.5 padding algorithm [RFC 2437] as 366 described in section 2.3.1 but with the ASN.1 BER RIPEMD160 algorithm 367 designator prefix. An example of use is 369 373 2.3.6 ECDSA-SHA* 375 Identifiers 376 http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha1 377 http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha224 378 http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha256 379 http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha384 380 http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha512 382 The Elliptic Curve Digital Signature Algorithm (ECDSA) [FIPS 186-2] 383 is the elliptic curve analogue of the DSA (DSS) signature method. For 384 a detailed specifications of how to use it with SHA hash functions 385 and XML Digital Signature, please see [X9.62] and [ECDSA]. 387 2.3.7 ESIGN-SHA1 389 Identifier 390 http://www.w3.org/2001/04/xmldsig-more#esign-sha1 391 http://www.w3.org/2001/04/xmldsig-more#esign-sha224 392 http://www.w3.org/2001/04/xmldsig-more#esign-sha256 393 http://www.w3.org/2001/04/xmldsig-more#esign-sha384 394 http://www.w3.org/2001/04/xmldsig-more#esign-sha512 396 The ESIGN algorithm specified in [IEEE P1363a] is a signature scheme 397 based on the integer factorization problem. It is much faster than 398 previous digital signature schemes so ESIGN can be implemented on 399 smart cards without special co-processors. 401 An example of use is 403 407 2.4 Minimal Canonicalization 409 Thus far two independent interoperable implementations of Minimal 410 Canonicalization have not been announced. Therefore, when XML 411 Digital Signature was advanced from Proposed Standard [RFC 3075] to 412 Draft Standard [RFC 3275], Minimal Canonicalization was dropped from 413 the standard track documents. However, there is still interest and 414 indicates of possible future use for Minimal Canonicalization. For 415 its definition, see [RFC 3075], Section 6.5.1. 417 For reference, it���s identifier remains: 418 http://www.w3.org/2000/09/xmldsig#minimal 420 2.5 Transform Algorithms 422 Note that all CanonicalizationMethod algorithms can also be used as 423 Transform algorithms. 425 2.5.1 XPointer 427 Identifier: 428 http://www.w3.org/2001/04/xmldsig-more/xptr 430 This transform algorithm takes an [XPointer] as an explicit 431 parameter. An example of use is: 433 435 437 xpointer(id("foo")) xmlns(bar=http://foobar.example) 438 xpointer(//bar:Zab[@Id="foo"]) 439 440 442 Schema Definition: 444 446 DTD: 448 450 Input to this transform is an octet stream (which is then parsed into 451 XML). 453 Output from this transform is a node set; the results of the XPointer 454 are processed as defined in the XMLDSIG specification [RFC 3275] for 455 a same-document XPointer. 457 2.6 EncryptionMethod Algorithms 459 This subsection gives identifiers and information for several 460 EncryptionMethod Algorithms. 462 2.6.1 ARCFOUR Encryption Algorithm 464 Identifier: 465 http://www.w3.org/2001/04/xmldsig-more#arcfour 467 ARCFOUR is a fast, simple stream encryption algorithm that is 468 compatible with RSA Security���s RC4 algorithm. An example 469 EncryptionMethod element using ARCFOUR is 471 473 40 474 476 Note that Arcfour makes use of the generic KeySize parameter 477 specified and defined in [XMLENC]. 479 2.6.2 Camellia Block Encryption 481 Identifiers: 482 http://www.w3.org/2001/04/xmldsig-more#camellia128-cbc 483 http://www.w3.org/2001/04/xmldsig-more#camellia192-cbc 484 http://www.w3.org/2001/04/xmldsig-more#camellia256-cbc 486 Camellia is an efficient and secure block cipher with the same 487 interface as the AES [Camellia, RFC 3713], that is 128-bit block size 488 and 128, 192, and 256 bit key sizes. In XML Encryption Camellia is 489 used in the same way as the AES: It is used in the Cipher Block 490 Chaining (CBC) mode with a 128-bit initialization vector (IV). The 491 resulting cipher text is prefixed by the IV. If included in XML 492 output, it is then base64 encoded. An example Camellia 493 EncryptionMethod is as follows: 495 500 2.6.3 Camellia Key Wrap 502 Identifiers: 503 http://www.w3.org/2001/04/xmldsig-more#kw-camellia128 504 http://www.w3.org/2001/04/xmldsig-more#kw-camellia192 505 http://www.w3.org/2001/04/xmldsig-more#kw-camellia256 507 Camellia [Camellia, RFC 3713] key wrap is identical to the AES key 508 wrap algorithm [RFC 3394] specified in the XML Encryption standard 509 with "AES" replaced by "Camellia". As with AES key wrap, the check 510 value is 0xA6A6A6A6A6A6A6A6. 512 The algorithm is the same whatever the size of the Camellia key used 513 in wrapping, called the key encrypting key or KEK. The implementation 514 of Camellia is OPTIONAL. However, if it is supported, the same 515 implementation guidelines as to which combinations of KEK size and 516 wrapped key size should be required to be supported and which are 517 optional to be supported should be followed. That is to say, if 518 Camellia key wrap is supported, they wrapping 128-bit keys with a 519 128-bit KEK and wrapping 256-bit keys with a 256-bit KEK are REQUIRED 520 and all other combinations are OPTIONAL. 522 An example of use is: 524 530 2.6.4 PSEC-KEM 532 Identifier: 533 http://www.w3.org/2001/04/xmldsig-more#psec-kem 535 The PSEC-KEM algorithm, specified in [ISO/IEC 18033-2], is a key 536 encapsulation mechanism using elliptic curve encryption. 538 An example of use is: 540 542 543 version 544 id 545 curve 546 base 547 order 548 cofactor 549 550 552 See [ISO/IEC 18033-2] for information on the parameters above. 554 3. KeyInfo 556 In section 3.1 below a new KeyInfo element child is specified while 557 in section 3.2 additional KeyInfo Type values for use in 558 RetrievalMethod are specified. 560 3.1 PKCS #7 Bag of Certificates and CRLs 562 A PKCS #7 [RFC 2315] "signedData" can also be used as a bag of 563 certificates and/or certificate revocation lists (CRLs). The 564 PKCS7signedData element is defined to accommodate such structures 565 within KeyInfo. The binary PKCS #7 structure is base64 [RFC 2405] 566 encoded. Any signer information present is ignored. The following 567 is a example, eliding the base64 data: 569 571 ... 572 574 3.2 Additional RetrievalMethod Type Values 576 The Type attribute of RetrievalMethod is an optional identifier for 577 the type of data to be retrieved. The result of de-referencing a 578 RetrievalMethod reference for all KeyInfo types with an XML structure 579 is an XML element or document with that element as the root. The 580 various "raw" key information types return a binary value. Thus they 581 require a Type attribute because they are not unambiguously 582 parseable. 584 Identifiers: 585 http://www.w3.org/2001/04/xmldsig-more#KeyValue 586 http://www.w3.org/2001/04/xmldsig-more#RetrievalMethod 587 http://www.w3.org/2001/04/xmldsig-more#KeyName 588 http://www.w3.org/2001/04/xmldsig-more#rawX509CRL 589 http://www.w3.org/2001/04/xmldsig-more#rawPGPKeyPacket 590 http://www.w3.org/2001/04/xmldsig-more#rawSPKISexp 591 http://www.w3.org/2001/04/xmldsig-more#PKCS7signedData 592 http://www.w3.org/2001/04/xmldsig-more#rawPKCS7signedData 594 4. IANA Considerations 596 None. 598 As it is easy for people to construct their own unique URIs [RFC 599 2396] and, possible, if appropriate, to obtain a URI from the W3C, it 600 is not intended that any additional 601 "http://www.w3.org/2001/04/xmldsig-more#" URIs be created beyond 602 those enumerated in this document. (W3C Namespace stability rules 603 prohibit the creation of new URIs under 604 "http://www.w3.org/2000/09/xmldsig#".) 606 5. Security Considerations 608 Due to computer speed and cryptographic advances, the use of MD5 as a 609 DigestMethod or in the RSA-MD5 SignatureMethod is NOT RECOMMENDED. 610 The cryptographic advances concerned do not effect the security of 611 HMAC-MD5; however, there is little reason not to go for one of the 612 SHA series of algorithms. 614 6. Copyright and Disclaimer 616 Copyright (C) 2004 The Internet Society. This document is subject to 617 the rights, licenses and restrictions contained in BCP 78 and except 618 as set forth therein, the authors retain all their rights. 620 This document and the information contained herein are provided on an 621 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 622 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 623 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 624 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 625 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 626 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 628 Normative References 630 [Camellia] - "Camellia: A 128-bit Block Cipher Suitable for Multiple 631 Platforms - Design and Analysis -", K. Aoki, T. Ichikawa, M. Matsui, 632 S. Moriai, J. Nakajima, T. Tokita, In Selected Areas in Cryptography, 633 7th Annual International Workshop, SAC 2000, August 2000, 634 Proceedings, Lecture Notes in Computer Science 2012, pp. 39-56, 635 Springer-Verlag, 2001. 637 [ECDSA] - "ECDSA with XML-Signature Syntax", S. Blake-Wilson, G. 638 Karlinger, T. Kobayashi, Y. Want, January 2004. draft-blake-wilson- 639 xmldsig-ecdsa-*.txt 641 [FIPS 180-1] - "Secure Hash Standard", (SHA-1) US Federal Information 642 Processing Standard, 17 April 1995. 644 [FIPS 180-2] - "Secure Hash Standard", (SHA-1/256/384/512) US Federal 645 Information Processing Standard, Draft, not yet issued. 647 [FIPS 180-2change] - "FIPS 180-2, Secure Hash Standard Change Notice 648 1", adds SHA-224 to [FIPS 180-2]. 650 [FIPS 186-2] - "Digital Signature Standard", National Institute of 651 Standards and Technology, 2000. 653 [IEEE P1363a] - "Standard Specifications for Public Key Cryptography: 654 Additional Techniques", October 2002. 656 [ISO/IEC 18033-2] - "Information technology -- Security techniques -- 657 Encryption algorithms -- Part 3: Asymmetric ciphers", CD, October 658 2002. 660 [RFC 1321] - "The MD5 Message-Digest Algorithm", R. Rivest, April 661 1992. 663 [RFC 2104] - "HMAC: Keyed-Hashing for Message Authentication", H. 664 Krawczyk, M. Bellare, R. Canetti, February 1997. 666 [RFC 2119] - "Key words for use in RFCs to Indicate Requirement 667 Levels", S. Bradner, March 1997. 669 [RFC 2396] - "Uniform Resource Identifiers (URI): Generic Syntax", T. 670 Berners-Lee, R. Fielding, L. Masinter, August 1998. 672 [RFC 2405] - "Multipurpose Internet Mail Extensions (MIME) Part One: 673 Format of Internet Message Bodies", N. Freed, N. Borenstein, November 674 1996. 676 [RFC 2437] - "PKCS #1: RSA Cryptography Specifications Version 2.0", 677 B. Kaliski, J. Staddon, October 1998. 679 [RFC 2315] - "PKCS #7: Cryptographic Message Syntax Version 1.5", B. 680 Kaliski, March 1998. 682 [RFC 3075] - "XML-Signature Syntax and Processing", D. Eastlake, J. 683 Reagle, D. Solo, March 2001. (RFC 3075 was obsoleted by RFC 3275 but 684 is referenced in this document for its description of Minimal 685 Canonicalization which was dropped in RFC 3275.) 687 [RFC 3275] - "XML-Signature Syntax and Processing", D. Eastlake, J. 688 Reagle, D. Solo, March 2002. 690 [RFC 3394] - "Advanced Encryption Standard (AES) Key Wrap Algorithm", 691 J. Schaad, R. Housley, September 2002. 693 [RFC 3713] - "A Description of the Camellia Encryption Algorithm", M. 694 Matsui, J. Nakajima, S. Moriai, April 2004. 696 [RFC 3874] - "A 224-bit One-way Hash Function: SHA-224", R. Housley, 697 September 2004. 699 [RIPEMD-160] - ISO/IEC 10118-3:1998, "Information Technology - 700 Security techniques - Hash-functions - Part3: Dedicated hash- 701 functions", ISO, 1998. 703 [X9.62] - X9.62-200X, "Public Key Cryptography for the Financial 704 Services Industry: The Elliptic Curve Digital Signature Algorithm 705 (ECDSA)", Accredited Standards Committee X9, American National 706 Standards Institute. 708 [XMLENC] - "XML Encryption Syntax and Processing", J. Reagle, D. 709 Eastlake, December 2002. 712 [XPointer] - "XML Pointer Language (XPointer) Version 1.0", W3C 713 working draft, Steve DeRose, Eve Maler, Ron Daniel Jr., January 2001. 714 716 Informative References 718 [CANON] - "Canonical XML Version 1.0", John Boyer. 719 . 721 [EXCANON] - "Exclusive XML Canonicalization Version 1.0", D. 722 Eastlake, J. Reagle, 18 July 2002. . 725 [RFC 3076] - "Canonical XML Version 1.0", J. Boyer, March 2001. 727 [RFC 3092] - "Etymology of ���Foo���", D. Eastlake 3rd, C. Manros, E. 728 Raymond, 1 April 2001. 730 [RFC 3741] - "Exclusive XML Canonicalization Version 1.0", J. Boyer, 731 D. Eastlake 3rd, J. Reagle, March 2004. 733 Author���s Address 735 Donald E. Eastlake 3rd 736 Motorola Laboratories 737 155 Beaver Street 738 Milford, MA 01757 USA 740 Telephone: +1-508-786-7554 (w) 741 +1-508-634-2066 (h) 742 EMail: Donald.Eastlake@motorola.com 744 Expiration and File Name 746 This draft expires in March 2005. 748 Its file name is draft-eastlake-xmldsig-uri-09.txt