idnits 2.17.1 draft-hallambaker-consensuscrypto-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == 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). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: * Implementations MUST not support or accept algorithms in the Obsolete Algorithm set except in exempt circumstances as specified in [exempt] == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Implementations MUST not support or accept algorithms in the Obsolete Algorithm set unless one of the following conditions applies: -- The document date (October 27, 2014) is 3461 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) ** Downref: Normative reference to an Informational RFC: RFC 3610 ** Obsolete normative reference: RFC 3447 (Obsoleted by RFC 8017) ** Downref: Normative reference to an Informational RFC: RFC 6234 -- Obsolete informational reference (is this intentional?): RFC 1320 (Obsoleted by RFC 6150) Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force (IETF) Phillip Hallam-Baker 2 Internet-Draft Comodo Group Inc. 3 Intended Status: Standards Track October 27, 2014 4 Expires: April 30, 2015 6 Consensus Cryptographic Algorithms 7 draft-hallambaker-consensuscrypto-01 9 Abstract 11 This document specifies conformance criteria for choices of 12 cryptographic algorithms. Conformance with this document establishes 13 that an implementation supports the community consensus for choice of 14 cryptographic algorithms at the time of publication and that the 15 implementation can interoperate with other implementations compliant 16 with the specified criteria. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 Copyright Notice 35 Copyright (c) 2014 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Consensus Cryptographic Algorithms . . . . . . . . . . . . . . 3 53 2.1. Complicance Criteria . . . . . . . . . . . . . . . . . . 4 54 2.1.1. Enhanced Criteria . . . . . . . . . . . . . . . . . 4 55 2.1.2. Exempt circumstances . . . . . . . . . . . . . . . . 4 56 2.2. Selection Criteria . . . . . . . . . . . . . . . . . . . 5 57 2.2.1. Established Consensus . . . . . . . . . . . . . . . 5 58 2.2.2. Unencumbered . . . . . . . . . . . . . . . . . . . . 5 59 2.3. Disqualification Criteria . . . . . . . . . . . . . . . . 5 60 2.3.1. Algorithm Weaknesses. . . . . . . . . . . . . . . . 6 61 2.3.2. Intellectual Property Claim. . . . . . . . . . . . . 6 62 2.4. Algorithm Variations . . . . . . . . . . . . . . . . . . 6 63 2.4.1. Cipher Modes . . . . . . . . . . . . . . . . . . . . 6 64 2.4.2. Key Sizes . . . . . . . . . . . . . . . . . . . . . 6 65 2.4.3. Shared Parameters . . . . . . . . . . . . . . . . . 7 66 2.4.4. Formats . . . . . . . . . . . . . . . . . . . . . . 7 67 2.4.5. Required Algorithms . . . . . . . . . . . . . . . . 7 68 2.4.6. Recommended Algorithms . . . . . . . . . . . . . . . 7 69 3. Required Algorithms . . . . . . . . . . . . . . . . . . . . . 7 70 3.1. Symmetric Key . . . . . . . . . . . . . . . . . . . . . . 7 71 3.1.1. Cryptographic Digest . . . . . . . . . . . . . . . . 7 72 3.1.2. Message Authentication Code . . . . . . . . . . . . 8 73 3.1.3. Encryption . . . . . . . . . . . . . . . . . . . . . 8 74 3.2. Public Key . . . . . . . . . . . . . . . . . . . . . . . 9 75 3.2.1. Ephemeral Key Agreement . . . . . . . . . . . . . . 9 76 3.2.2. Public Key Encryption . . . . . . . . . . . . . . . 9 77 3.2.3. Digital Signature . . . . . . . . . . . . . . . . . 9 78 4. Recommended Algorithms . . . . . . . . . . . . . . . . . . . . 10 79 4.1. Symmetric Key . . . . . . . . . . . . . . . . . . . . . . 10 80 4.1.1. Cryptographic Digest . . . . . . . . . . . . . . . . 10 81 4.1.2. Message Authentication Code . . . . . . . . . . . . 10 82 4.1.3. Encryption . . . . . . . . . . . . . . . . . . . . . 10 83 4.2. Public Key . . . . . . . . . . . . . . . . . . . . . . . 10 84 5. Obsolete Algorithms . . . . . . . . . . . . . . . . . . . . . 11 85 6. Further Work . . . . . . . . . . . . . . . . . . . . . . . . . 11 86 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 87 7.1. Outdated recommendations . . . . . . . . . . . . . . . . 12 88 7.2. Monoculture . . . . . . . . . . . . . . . . . . . . . . . 12 89 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 90 9. Acnowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 91 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 92 10.1. Normative References . . . . . . . . . . . . . . . . . . 12 93 10.2. Informative References . . . . . . . . . . . . . . . . . 13 94 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 96 1. Introduction 98 Many IETF protocols may use of cryptographic algorithms to provide 99 confidentiality, integrity, or non-repudiation. For the mechanisms to 100 work properly, communicating parties must support the same 101 cryptographic algorithm or algorithms. Yet, cryptographic algorithms 102 become weaker with time. As new cryptanalysis techniques are 103 developed and computing performance improves, the work factor to 104 break a particular cryptographic algorithm will reduce. 106 Traditionally the protocol designers have been responsible for both 107 the implementation of a modular design that enables the use of 108 different algorithms and the choice of the initial algorithms 109 themselves. Changes to the set of mandatory to implement algorithms 110 requires revision of each standard in turn. 112 Since a cryptographic implementation is often only as secure as its 113 weakest link, failure to update algorithm requirements consistently 114 often means the advantage of doing so is lost. It is not the ability 115 to use stronger algorithms that improves the strength of a solution, 116 rather it is discontinuing the use of weak or compromised algorithms. 118 This document describes a set of cryptographic algorithm choices that 119 reflects current IETF consensus at the time of issue. Compliance with 120 this document indicates that an implementation supports the use of a 121 set of cryptographic algorithms backed by the consensus of the IETF 122 community and does not in its default configuration support the use 123 of previously recommended algorithms that have been found to be 124 unsafe. 126 1.1. Terminology 128 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 129 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 130 document, are to be interpreted as described in [RFC2119] 132 2. Consensus Cryptographic Algorithms 134 This document specifies three sets of cryptographic algorithms: 136 Required Algorithms 137 A set of algorithms that is considered to represent the best 138 current tradeoff between security, efficiency and 139 interoperability. 141 Recommended Algorithms 142 A set of 'backup' algorithms to be held in reserve in case that 143 a required algorithm is found to be unacceptable. 145 Obsolete Algorithms 146 A set of algorithms that were previously cited in IETF protocol 147 specifications that have been found to be unsafe and unfit for 148 purpose. 150 An application that only supports one cryptographic algorithm is 151 vulnerable to attack in the case that algorithm is broken. An 152 application that suports numerous algorithm choices is only as secure 153 as the weakest algorithm choice an attacker can impose on it. 154 Consequently best practice for design of cryptographic protocols 155 holds that at least one REQUIRED algorithm choice be defined to 156 enable interoperability but that there be no more than one additional 157 algorithm 159 Accordingly, the Required set of algorithms contains exactly one 160 choice for each algorithm type and the Recommended set contains at 161 most one choice of algorithm. 163 2.1. Complicance Criteria 165 Implementations that are compliant with this specification are 166 REQUIRED to observe the following compliance criteria: 168 * Where the protocol indicates the need for a particular type of 169 cryptographic algorithm, the corresponding algorithm from the 170 Required Algorithm set is REQUIRED. 172 * Where the protocol indicates the need for a particular type of 173 cryptographic algorithm, the corresponding algorithm from the 174 Recommended Algorithm set is RECOMMENDED. 176 * Implementations MUST not support or accept algorithms in the 177 Obsolete Algorithm set except in exempt circumstances as 178 specified in [exempt] 180 2.1.1. Enhanced Criteria 182 Protocol specifications citing this document normatively MAY impose 183 additional requirements. For example, a protocol designed for use in 184 an embedded systems application demanding a long term service life 185 might require implementation of algorithms in the Recomended set so 186 as to ensure that every deployed system supported a backup algorithm. 188 2.1.2. Exempt circumstances 190 Implementations MUST not support or accept algorithms in the Obsolete 191 Algorithm set unless one of the following conditions applies: 193 * The use of the algorithm is approved for that specific purpose 194 in the notice declaring it to be obsolete. 196 * Support for the algorithm is disabled by default and can only 197 be enabled by explicit action by a duly authorized 198 administrator. 200 * Support for the algorithm is limited to a fixed transition 201 period established in the notice declaring the algorithm to be 202 obsolete. 204 2.2. Selection Criteria 206 2.2.1. Established Consensus 208 It is the objective of this document to follow rather than lead the 209 development of community consensus on cryptographic algorithm 210 choices. Accordingly the definition of the Required algorithm set 211 follows established IETF and Industry practice and entries are only 212 specified in the Recommended algorithm set where there is a clear and 213 overwhelming consensus to do so. 215 2.2.2. Unencumbered 217 Current industry and community practice strongly discourages the 218 adoption of specifications that are encumbered by patent, copyright 219 or other intellectual property claims unless there is an overwhelming 220 functional advantage in doing so. Since unencumbered algorithm 221 choices exist for each and every cryptographic algorithm specified in 222 the Required set, it is hard to imagine a circumstance in which it 223 would be to the advantage of the community to intentionally select 224 alternatives that were subject to such claims. 226 Accordingly, only algorithms that are believed to be free from such 227 claims are considered eligible for selection. In the case that a 228 party were to establish a credible intellectual property claim in one 229 of the algorithms in the Required or Recommended set, this would 230 constitute a valid disqualification criteria. 232 2.3. Disqualification Criteria 234 Future revisions of this document may update entries in the Required 235 and/or Recommended algorithms set as determined by IETF process and 236 community consensus. Such updates should attempt to find a balance 237 between the need to protect security while avoiding unnecessary 238 impact on running code. 240 The disqualification criteria set out here are intended to serve as a 241 guide for such discussions rather than attempting to bind them to a 242 particular course of action. 244 Since the Required and Recommended Algorithm sets serve different 245 purposes, the disqualification criteria for different for each set. 247 2.3.1. Algorithm Weaknesses. 249 An algorithm is disqualified as a member of the Required set of 250 algorithms if community consensus holds that the security of the 251 algorithm has been substantially compromised such that an attack on 252 the algorthm is feasible or expected to become feasible in the near 253 future. 255 Rationale: Since algorithns in the Required set are intended for 256 ubiquitous use, disqualification of such algorithms represents a 257 significant cost and is not to be considered lightly. A purely 258 theoretical attack reducing the time complexity of breaking a 128 bit 259 encryption algorithm to O(2^124) time with the use of 2^120 chosen 260 plaintexts would not justify making a change. An attack that reduced 261 the time complexity of an attack to O(2^100) would be cause for 262 considerably greater concern. 264 An algorithm is disqualified as a member of the Required set of 265 algorithms if community consensus holds that the security of the 266 algorithm has been significantly compromised. 268 Rationale: Since algorithms in the Recommended set are intended for 269 use as replacement algorithms in case the corresponding algorithm in 270 the Required set are found to be weak, the algorithms selected should 271 be beyond reasonable suspicion. 273 2.3.2. Intellectual Property Claim. 275 The algorithms selected for the Required set are all based on well 276 established technology that was not subject to patent claims or where 277 the patent claims that existed have expired. Should a credible claim 278 be asserted subsequently it would stand as grounds for 279 disqualification. 281 2.4. Algorithm Variations 283 2.4.1. Cipher Modes 285 This document does not address choice of cipher modes. The choice of 286 cipher mode is depends on the application for which it is to be used 287 and is therefore best considered as part of the protocol design. 289 2.4.2. Key Sizes 291 Most modern cryptographic algorithms offer a range of key sizes. For 292 example the AES standard defines 128 bit, 192 bit and 256 bit key 293 sizes. The RSA algorithm supports arbitrary key sizes but is only 294 considered acceptably secure for key sizes of 2048 bits or greater. 296 To avoid unnecessary burden on implementations, only specific key 297 sizes are REQUIRED or RECOMMENDED. The key sizes being chosen to 298 minimize implementation complexity. 300 2.4.3. Shared Parameters 302 Most public key algorithms have a set of shared parameters that are 303 not properly part of either the public or private key. In the RSA 304 algorithm, the public key exponent is typically chosen to be 65,537 305 for efficiency but other values may be used. 307 In the case of Diffie-Hellman key Exchange [RFC2631], the public 308 exponent g and shared modulus p must be agreed by both parties before 309 the public key values can be calculated. Prior agreement of a common 310 public exponent and shared modulus permits these steps to be 311 performed out of band and held in reserve for use when needed. 313 Selection of shared parameter values where necessary is outside the 314 scope of this document. Rather, such selection of values is to be 315 determined in the separate specification describing the algorithm 316 specification. 318 2.4.4. Formats 320 Except where the choice of data format affects the security of an 321 algorithm and is thus properly considered to be a part thereof, data 322 formats and encodings are outside the scope of these requirements. 324 2.4.5. Required Algorithms 326 2.4.6. Recommended Algorithms 328 The purpose of the recommended algorithms is to provide a backup in 329 case the required algorithm is found to be weak. Accodingly: 331 * There should be a high degree of confidence that a weakness 332 affecting the required algorithm should not affect the 333 recommended algorithm 335 * Where possible, recommended algorithms should be the consensus 336 choice of successor algorithm. 338 * Recommended algorithms should be chosen for security over 339 speed. 341 3. Required Algorithms 343 3.1. Symmetric Key 345 3.1.1. Cryptographic Digest 347 REQUIRED: SHA2 256 [RFC6234] 349 RECOMMENDED: SHA2 512 [RFC6234] 351 Rationale: Although the SHA3 algorithms are believed to be superior 352 in strength, no IETF specifications currently mandate implementation 353 and to do so here would be to attempt to lead rather than follow 354 consensus. Further, the choice of SHA2 as required leaves SHA3 for 355 use as a reserve algorithm which would otherwise be empty. 357 3.1.2. Message Authentication Code 359 REQUIRED: HMAC-SHA-256-128 [RFC4868] 361 RECOMMENDED: AES-128-CCM [RFC3610] 363 According to current practice, Message Authentication Codes (MAC) are 364 currently implemented as a mode of use of either a cryptographic 365 digest or an encryption algorithm. While this approach reduces the 366 number of cryptographic algorithms that an implementation is required 367 to support, such constructions must be considered as separate and 368 independent algorithms for the purpose of evaluating security. 370 In theory an algorithm constructed in this fashion may become 371 vulnerable to attack due to a weakness of either the base algorithm 372 or the mode of use. 374 3.1.3. Encryption 376 REQUIRED: AES 128 bit 378 RECOMMENDED: AES 256 bit 380 Rationale: AES is the de-facto industry standard encryption 381 algorithm. In addition to being widely used in applications, many 382 CPUs provide support for AES in dedicated or optimized hardware. AES 383 emerged from an open competition in which the process and execution 384 were commonly agreed to be open and fair. 386 Although AES specifies three key sizes, the 128 bit key size should 387 be sufficient for any purpose unless either a weakness is discovered 388 in the algorithm itself or a new form of computing principle is 389 discovered that permits faster attacks. The 391 3.2. Public Key 393 Three types of public key algorithm are defined: 395 * Ephemeral Key Agreement. 397 * Public Key Encryption / Key Agreement under long term key 399 * Digital Signature. 401 For performance and security reasons, the use of public key 402 encryption is almost invariably restricted to key agreement in 403 Internet protocols: A symmetric key is randomly generated and 404 encrypted under the public encryption key of the intended recipient. 406 While the Diffie-Hellman and RSA algorithms are both capable of 407 supporting key agreement, the practice has arisen that the RSA 408 encryption algorithm is used in cases where a key is to be published 409 or endorsed in some form of PKI and use of the Diffie-Hellman 410 algorithm is limited to ephemeral key exchange where the ability to 411 generate new public keypairs rapidly is a requirement. 413 3.2.1. Ephemeral Key Agreement 415 REQUIRED: Diffie-Hellman key exchange as described in [RFC2631]. 417 Rationale: Diffie-Helleman is the currently the consensus choic of 418 key exchange algorithm in applications where rapid generation of key 419 pairs is desirable. Unlike RSA which requires a search for two large 420 primes, generation of Diffie Hellman keys only requires a large 421 random number. 423 3.2.2. Public Key Encryption 425 REQUIRED: RSA Public Key Encryption as described in [RFC3447]. 427 Implementations MUST support RSA Public Encryption key sizes of 2048 428 and 4096 bits. Implementations MUST NOT accept key sizes of less than 429 2048 bits 431 Note 1: Following industry practice, an RSA modulus is considered to 432 be a '2048 bit' key size provided that it is greater than 2^2046. 434 Rationale: RSA is the industry standard choice for non-emphemeral key 435 exchange. While the use in Internet protocols is almost exclusively 436 for key exchange as opposed to encryption of data, longstanding 437 practice is to distinguish these uses. 439 3.2.3. Digital Signature 441 REQUIRED: RSA Public Key Signature as described in [RFC3447]. 443 Implementations MUST support RSA Digital Signature key sizes of 2048 444 and 4096 bits. Implementations MUST NOT accept key sizes of less than 445 2048 bits 447 Note 1: Following industry practice, an RSA modulus is considered to 448 be a '2048 bit' key size provided that it is greater than 2^2046. 450 4. Recommended Algorithms 452 While there is a strong consensus in favor of a Required set of 453 algorithms, no such consensus currently supports the selection of 454 Recommended algorithms except in the case of Cryptographic Digests. 456 4.1. Symmetric Key 458 4.1.1. Cryptographic Digest 460 RECOMMENDED: SHA-3 462 Rationale 464 4.1.2. Message Authentication Code 466 RECOMMENDED: HMAC-SHA3 468 The 470 4.1.3. Encryption 472 No Reccomendation. 474 One of the chief advantages of using AES is that many commodity CPU 475 devices provide support for AES in dedicated circuits or circuits 476 optimized for AES use. As a result the best alternative to use of 477 AES-128 today is to use the AES-256 which requires more rounds of 478 processing in addition to the larger key size. 480 4.2. Public Key 482 No Reccomendation. 484 Although developments in cryptanalysis of public key cryptographic 485 algorithms strongly suggest that there is an urgent need to specify 486 an alternative to algorithms such as RSA and Diffie-Hellman based on 487 the discrete log problem, there is currently no clear consensus on a 488 single successor. 490 Although it is generally agreed that Elliptic Curve algorithms 491 provide the strongest contenders for replacement algorithms, recent 492 events have cast doubt on the choice of parameters. 494 5. Obsolete Algorithms 496 On publication of this document as an RFC, IANA shall create a 497 registry of Obsolete cryptographic algorithms containing the 498 following information. The IANA policy RFC Required shall apply to 499 creation of new entries in the registry. 501 The set of obsolete algorithms SHALL be the set of algorithms listed 502 in the registry created. 504 To avoid the implication that algorithms not listed as obsolete are 505 to be considered 'safe', only algorithms that have been previously 506 published as an RFC or approved for use as a strong cryptographic 507 algorithm in a document previously published as an RFC are eligible 508 for inclusion. For example, MD4 is eligible for inclusion as it is 509 described in [RFC1320]. 511 Algorithm Identifier 512 The commonly used abbreviation of the obsolete algorithm. 514 Long Name 515 The long name of the obsolete algorithm. 517 Document 518 RFC in which the algorithm is declared obsolete. For example, 519 by moving the original specification of the algorithm to 520 HISTORIC status. 522 6. Further Work 524 As noted previously, best practice for implementation of 525 cryptographic applications strongly encourages support for a reserve 526 or backup algorithm as a transition plan in case the mandatory to 527 implement choice should be found to be defective. With the exception 528 of cryptographi digests however, no existing algorithms can claim the 529 backing of a strong community consensus. Work on building such 530 consensus is thus clearly advised. 532 Public Key algorithms, the area in which immediate attention is 533 generally considered to be most needed is fortunately the area in 534 which prospects for short term success are greatest. While there is a 535 strong consensus that Elliptic Curve cryptography [RFC6090] provides 536 the best alternative to discrete logarithm problems, recent events 537 have cast doubt over proposals to use specific shared parameters. 539 For the limited purpose of defining a reserve algorithm set it is 540 sufficient to either limit the recommendation to implementation of an 541 algorithm alone, to select a set of curves that are known to be free 542 of backdoors or to generate a completely new set of curves under 543 controlled conditions. 545 Definition of an alternative encryption algorithm presents a greater 546 challenge. If the need for a substitute algorithm suddenly became 547 urgent, one of the runners-up in the AES competition might be chosen 548 as an expedient choice. But absent such circumstances, it is highly 549 unlikely that consensus could be reached on an AES alternative unless 550 the choice was made through a similarly open competition based 551 process. 553 7. Security Considerations 555 Since this whole document is about security, the focus of the 556 security considerations is properly the risks created by the document 557 itself. 559 7.1. Outdated recommendations 561 Algorithms within the Required or Recommended set may become 562 vulnerable to attack without updated recomendations being issued. 564 7.2. Monoculture 566 Adopting a single set of Required and Recommended algorithms may 567 result in an algorithm monoculture such that new algorithms are 568 unable to become established. 570 One of the main reasons for not completing the set of recommended 571 algorithms for the sake of completeness is to identify areas where 572 additional algorithm choices are required and a consensus building 573 effort is needed. 575 8. IANA Considerations 577 Create a registry of obsolete algorithms. 579 9. Acnowledgements 581 10. References 583 10.1. Normative References 585 [RFC4868] Kelly, S.,Frankel, S., "Using HMAC-SHA-256, HMAC-SHA-384, 586 and HMAC-SHA-512 with IPsec", RFC 4868, May 2007. 588 [RFC3610] Whiting, D.,Housley, R.,Ferguson, N., "Counter with CBC- 589 MAC (CCM)", RFC 3610, September 2003. 591 [RFC3447] Jonsson, J.,Kaliski, B., "Public-Key Cryptography 592 Standards (PKCS) #1: RSA Cryptography Specifications 593 Version 2.1", RFC 3447, February 2003. 595 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 596 Requirement Levels", BCP 14, RFC 2119, March 1997. 598 [RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC 599 2631, June 1999. 601 [RFC6234] Eastlake, D.,Hansen, T., "US Secure Hash Algorithms (SHA 602 and SHA-based HMAC and HKDF)", RFC 6234, May 2011. 604 10.2. Informative References 606 [RFC6090] McGrew, D.,Igoe, K.,Salter, M., "Fundamental Elliptic 607 Curve Cryptography Algorithms", RFC 6090, February 2011. 609 [RFC1320] Rivest, R., "The MD4 Message-Digest Algorithm", RFC 1320, 610 April 1992. 612 Author's Address 614 Phillip Hallam-Baker 615 Comodo Group Inc. 617 philliph@comodo.com