Internet DRAFT - draft-hallambaker-consensuscrypto

draft-hallambaker-consensuscrypto



Internet Engineering Task Force (IETF)              Phillip Hallam-Baker
Internet-Draft                                         Comodo Group Inc.
Intended Status: Standards Track                        October 27, 2014
Expires: April 30, 2015


                   Consensus Cryptographic Algorithms
                  draft-hallambaker-consensuscrypto-01

Abstract

   This document specifies conformance criteria for choices of 
   cryptographic algorithms. Conformance with this document establishes 
   that an implementation supports the community consensus for choice of
   cryptographic algorithms at the time of publication and that the 
   implementation can interoperate with other implementations compliant 
   with the specified criteria.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the 
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering 
   Task Force (IETF).  Note that other groups may also distribute 
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any 
   time.  It is inappropriate to use Internet-Drafts as reference 
   material or to cite them other than as "work in progress."

Copyright Notice

   Copyright (c) 2014 IETF Trust and the persons identified as the 
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal 
   Provisions Relating to IETF Documents 
   (http://trustee.ietf.org/license-info) in effect on the date of 
   publication of this document. Please review these documents 
   carefully, as they describe your rights and restrictions with respect
   to this document. Code Components extracted from this document must 
   include Simplified BSD License text as described in Section 4.e of 
   the Trust Legal Provisions and are provided without warranty as 
   described in the Simplified BSD License.









Hallam-Baker                 April 30, 2015                     [Page 1]

Internet-Draft     Consensus Cryptographic Algorithms       October 2014

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
      1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Consensus Cryptographic Algorithms . . . . . . . . . . . . . .  3
      2.1.  Complicance Criteria  . . . . . . . . . . . . . . . . . .  4
         2.1.1.  Enhanced Criteria  . . . . . . . . . . . . . . . . .  4
         2.1.2.  Exempt circumstances . . . . . . . . . . . . . . . .  4
      2.2.  Selection Criteria  . . . . . . . . . . . . . . . . . . .  5
         2.2.1.  Established Consensus  . . . . . . . . . . . . . . .  5
         2.2.2.  Unencumbered . . . . . . . . . . . . . . . . . . . .  5
      2.3.  Disqualification Criteria . . . . . . . . . . . . . . . .  5
         2.3.1.  Algorithm Weaknesses.  . . . . . . . . . . . . . . .  6
         2.3.2.  Intellectual Property Claim. . . . . . . . . . . . .  6
      2.4.  Algorithm Variations  . . . . . . . . . . . . . . . . . .  6
         2.4.1.  Cipher Modes . . . . . . . . . . . . . . . . . . . .  6
         2.4.2.  Key Sizes  . . . . . . . . . . . . . . . . . . . . .  6
         2.4.3.  Shared Parameters  . . . . . . . . . . . . . . . . .  7
         2.4.4.  Formats  . . . . . . . . . . . . . . . . . . . . . .  7
         2.4.5.  Required Algorithms  . . . . . . . . . . . . . . . .  7
         2.4.6.  Recommended Algorithms . . . . . . . . . . . . . . .  7
   3.  Required Algorithms  . . . . . . . . . . . . . . . . . . . . .  7
      3.1.  Symmetric Key . . . . . . . . . . . . . . . . . . . . . .  7
         3.1.1.  Cryptographic Digest . . . . . . . . . . . . . . . .  7
         3.1.2.  Message Authentication Code  . . . . . . . . . . . .  8
         3.1.3.  Encryption . . . . . . . . . . . . . . . . . . . . .  8
      3.2.  Public Key  . . . . . . . . . . . . . . . . . . . . . . .  9
         3.2.1.  Ephemeral Key Agreement  . . . . . . . . . . . . . .  9
         3.2.2.  Public Key Encryption  . . . . . . . . . . . . . . .  9
         3.2.3.  Digital Signature  . . . . . . . . . . . . . . . . .  9
   4.  Recommended Algorithms . . . . . . . . . . . . . . . . . . . . 10
      4.1.  Symmetric Key . . . . . . . . . . . . . . . . . . . . . . 10
         4.1.1.  Cryptographic Digest . . . . . . . . . . . . . . . . 10
         4.1.2.  Message Authentication Code  . . . . . . . . . . . . 10
         4.1.3.  Encryption . . . . . . . . . . . . . . . . . . . . . 10
      4.2.  Public Key  . . . . . . . . . . . . . . . . . . . . . . . 10
   5.  Obsolete Algorithms  . . . . . . . . . . . . . . . . . . . . . 11
   6.  Further Work . . . . . . . . . . . . . . . . . . . . . . . . . 11
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
      7.1.  Outdated recommendations  . . . . . . . . . . . . . . . . 12
      7.2.  Monoculture . . . . . . . . . . . . . . . . . . . . . . . 12
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
   9.  Acnowledgements  . . . . . . . . . . . . . . . . . . . . . . . 12
   10.  References  . . . . . . . . . . . . . . . . . . . . . . . . . 12
      10.1.  Normative References . . . . . . . . . . . . . . . . . . 12
      10.2.  Informative References . . . . . . . . . . . . . . . . . 13
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13







Hallam-Baker                 April 30, 2015                     [Page 2]

Internet-Draft     Consensus Cryptographic Algorithms       October 2014

1. Introduction

   Many IETF protocols may use of cryptographic algorithms to provide 
   confidentiality, integrity, or non-repudiation. For the mechanisms to
   work properly, communicating parties must support the same 
   cryptographic algorithm or algorithms. Yet, cryptographic algorithms 
   become weaker with time. As new cryptanalysis techniques are 
   developed and computing performance improves, the work factor to 
   break a particular cryptographic algorithm will reduce.

   Traditionally the protocol designers have been responsible for both 
   the implementation of a modular design that enables the use of 
   different algorithms and the choice of the initial algorithms 
   themselves. Changes to the set of mandatory to implement algorithms 
   requires revision of each standard in turn. 

   Since a cryptographic implementation is often only as secure as its 
   weakest link, failure to update algorithm requirements consistently 
   often means the advantage of doing so is lost. It is not the ability 
   to use stronger algorithms that improves the strength of a solution, 
   rather it is discontinuing the use of weak or compromised algorithms.

   This document describes a set of cryptographic algorithm choices that
   reflects current IETF consensus at the time of issue. Compliance with
   this document indicates that an implementation supports the use of a 
   set of cryptographic algorithms backed by the consensus of the IETF 
   community and does not in its default configuration support the use 
   of previously recommended algorithms that have been found to be 
   unsafe. 

1.1. Terminology

   The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 
   SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 
   document, are to be interpreted as described in [RFC2119]

2. Consensus Cryptographic Algorithms

   This document specifies three sets of cryptographic algorithms: 

      Required Algorithms
         A set of algorithms that is considered to represent the best 
         current tradeoff between security, efficiency and 
         interoperability.

      Recommended Algorithms
         A set of 'backup' algorithms to be held in reserve in case that
         a required algorithm is found to be unacceptable. 






Hallam-Baker                 April 30, 2015                     [Page 3]

Internet-Draft     Consensus Cryptographic Algorithms       October 2014

      Obsolete Algorithms
         A set of algorithms that were previously cited in IETF protocol
         specifications that have been found to be unsafe and unfit for 
         purpose.

   An application that only supports one cryptographic algorithm is 
   vulnerable to attack in the case that algorithm is broken. An 
   application that suports numerous algorithm choices is only as secure
   as the weakest algorithm choice an attacker can impose on it. 
   Consequently best practice for design of cryptographic protocols 
   holds that at least one REQUIRED algorithm choice be defined to 
   enable interoperability but that there be no more than one additional
   algorithm 

   Accordingly, the Required set of algorithms contains exactly one 
   choice for each algorithm type and the Recommended set contains at 
   most one choice of algorithm.

2.1. Complicance Criteria

   Implementations that are compliant with this specification are 
   REQUIRED to observe the following compliance criteria:

      *  Where the protocol indicates the need for a particular type of 
         cryptographic algorithm, the corresponding algorithm from the 
         Required Algorithm set is REQUIRED.

      *  Where the protocol indicates the need for a particular type of 
         cryptographic algorithm, the corresponding algorithm from the 
         Recommended Algorithm set is RECOMMENDED.

      *  Implementations MUST not support or accept algorithms in the 
         Obsolete Algorithm set except in exempt circumstances as 
         specified in [exempt]

2.1.1. Enhanced Criteria

   Protocol specifications citing this document normatively MAY impose 
   additional requirements. For example, a protocol designed for use in 
   an embedded systems application demanding a long term service life 
   might require implementation of algorithms in the Recomended set so 
   as to ensure that every deployed system supported a backup algorithm.

2.1.2. Exempt circumstances

   Implementations MUST not support or accept algorithms in the Obsolete
   Algorithm set unless one of the following conditions applies:

      *  The use of the algorithm is approved for that specific purpose 
         in the notice declaring it to be obsolete.




Hallam-Baker                 April 30, 2015                     [Page 4]

Internet-Draft     Consensus Cryptographic Algorithms       October 2014

      *  Support for the algorithm is disabled by default and can only 
         be enabled by explicit action by a duly authorized 
         administrator.

      *  Support for the algorithm is limited to a fixed transition 
         period established in the notice declaring the algorithm to be 
         obsolete.

2.2. Selection Criteria

2.2.1. Established Consensus

   It is the objective of this document to follow rather than lead the 
   development of community consensus on cryptographic algorithm 
   choices. Accordingly the definition of the Required algorithm set 
   follows established IETF and Industry practice and entries are only 
   specified in the Recommended algorithm set where there is a clear and
   overwhelming consensus to do so.

2.2.2. Unencumbered

   Current industry and community practice strongly discourages the 
   adoption of specifications that are encumbered by patent, copyright 
   or other intellectual property claims unless there is an overwhelming
   functional advantage in doing so. Since unencumbered algorithm 
   choices exist for each and every cryptographic algorithm specified in
   the Required set, it is hard to imagine a circumstance in which it 
   would be to the advantage of the community to intentionally select 
   alternatives that were subject to such claims. 

   Accordingly, only algorithms that are believed to be free from such 
   claims are considered eligible for selection. In the case that a 
   party were to establish a credible intellectual property claim in one
   of the algorithms in the Required or Recommended set, this would 
   constitute a valid disqualification criteria.

2.3. Disqualification Criteria

   Future revisions of this document may update entries in the Required 
   and/or Recommended algorithms set as determined by IETF process and 
   community consensus. Such updates should attempt to find a balance 
   between the need to protect security while avoiding unnecessary 
   impact on running code.

   The disqualification criteria set out here are intended to serve as a
   guide for such discussions rather than attempting to bind them to a 
   particular course of action.

   Since the Required and Recommended Algorithm sets serve different 
   purposes, the disqualification criteria for different for each set.




Hallam-Baker                 April 30, 2015                     [Page 5]

Internet-Draft     Consensus Cryptographic Algorithms       October 2014

2.3.1. Algorithm Weaknesses.

   An algorithm is disqualified as a member of the Required set of 
   algorithms if community consensus holds that the security of the 
   algorithm has been substantially compromised such that an attack on 
   the algorthm is feasible or expected to become feasible in the near 
   future.

   Rationale: Since algorithns in the Required set are intended for 
   ubiquitous use, disqualification of such algorithms represents a 
   significant cost and is not to be considered lightly. A purely 
   theoretical attack reducing the time complexity of breaking a 128 bit
   encryption algorithm to O(2^124) time with the use of 2^120 chosen 
   plaintexts would not justify making a change. An attack that reduced 
   the time complexity of an attack to O(2^100) would be cause for 
   considerably greater concern.

   An algorithm is disqualified as a member of the Required set of 
   algorithms if community consensus holds that the security of the 
   algorithm has been significantly compromised.

   Rationale: Since algorithms in the Recommended set are intended for 
   use as replacement algorithms in case the corresponding algorithm in 
   the Required set are found to be weak, the algorithms selected should
   be beyond reasonable suspicion.

2.3.2. Intellectual Property Claim.

   The algorithms selected for the Required set are all based on well 
   established technology that was not subject to patent claims or where
   the patent claims that existed have expired. Should a credible claim 
   be asserted subsequently it would stand as grounds for 
   disqualification.

2.4. Algorithm Variations

2.4.1. Cipher Modes

   This document does not address choice of cipher modes. The choice of 
   cipher mode is depends on the application for which it is to be used 
   and is therefore best considered as part of the protocol design.

2.4.2. Key Sizes 

   Most modern cryptographic algorithms offer a range of key sizes. For 
   example the AES standard defines 128 bit, 192 bit and 256 bit key 
   sizes. The RSA algorithm supports arbitrary key sizes but is only 
   considered acceptably secure for key sizes of 2048 bits or greater.






Hallam-Baker                 April 30, 2015                     [Page 6]

Internet-Draft     Consensus Cryptographic Algorithms       October 2014

   To avoid unnecessary burden on implementations, only specific key 
   sizes are REQUIRED or RECOMMENDED. The key sizes being chosen to 
   minimize implementation complexity. 

2.4.3. Shared Parameters

   Most public key algorithms have a set of shared parameters that are 
   not properly part of either the public or private key. In the RSA 
   algorithm, the public key exponent is typically chosen to be 65,537 
   for efficiency but other values may be used.

   In the case of Diffie-Hellman key Exchange [RFC2631], the public 
   exponent g and shared modulus p must be agreed by both parties before
   the public key values can be calculated. Prior agreement of a common 
   public exponent and shared modulus permits these steps to be 
   performed out of band and held in reserve for use when needed.

   Selection of shared parameter values where necessary is outside the 
   scope of this document. Rather, such selection of values is to be 
   determined in the separate specification describing the algorithm 
   specification.

2.4.4. Formats

   Except where the choice of data format affects the security of an 
   algorithm and is thus properly considered to be a part thereof, data 
   formats and encodings are outside the scope of these requirements.

2.4.5. Required Algorithms

2.4.6. Recommended Algorithms

   The purpose of the recommended algorithms is to provide a backup in 
   case the required algorithm is found to be weak. Accodingly:

      *  There should be a high degree of confidence that a weakness 
         affecting the required algorithm should not affect the 
         recommended algorithm

      *  Where possible, recommended algorithms should be the consensus 
         choice of successor algorithm.

      *  Recommended algorithms should be chosen for security over 
         speed.










Hallam-Baker                 April 30, 2015                     [Page 7]

Internet-Draft     Consensus Cryptographic Algorithms       October 2014

3. Required Algorithms

3.1. Symmetric Key

3.1.1. Cryptographic Digest

   REQUIRED: SHA2 256 [RFC6234]

   RECOMMENDED: SHA2 512 [RFC6234]

   Rationale: Although the SHA3 algorithms are believed to be superior 
   in strength, no IETF specifications currently mandate implementation 
   and to do so here would be to attempt to lead rather than follow 
   consensus. Further, the choice of SHA2 as required leaves SHA3 for 
   use as a reserve algorithm which would otherwise be empty.

3.1.2. Message Authentication Code

   REQUIRED: HMAC-SHA-256-128 [RFC4868]

   RECOMMENDED: AES-128-CCM [RFC3610]

   According to current practice, Message Authentication Codes (MAC) are
   currently implemented as a mode of use of either a cryptographic 
   digest or an encryption algorithm. While this approach reduces the 
   number of cryptographic algorithms that an implementation is required
   to support, such constructions must be considered as separate and 
   independent algorithms for the purpose of evaluating security.

   In theory an algorithm constructed in this fashion may become 
   vulnerable to attack due to a weakness of either the base algorithm 
   or the mode of use.

3.1.3. Encryption

   REQUIRED: AES 128 bit

   RECOMMENDED: AES 256 bit

   Rationale: AES is the de-facto industry standard encryption 
   algorithm. In addition to being widely used in applications, many 
   CPUs provide support for AES in dedicated or optimized hardware. AES 
   emerged from an open competition in which the process and execution 
   were commonly agreed to be open and fair.

   Although AES specifies three key sizes, the 128 bit key size should 
   be sufficient for any purpose unless either a weakness is discovered 
   in the algorithm itself or a new form of computing principle is 
   discovered that permits faster attacks. The 





Hallam-Baker                 April 30, 2015                     [Page 8]

Internet-Draft     Consensus Cryptographic Algorithms       October 2014

3.2. Public Key

   Three types of public key algorithm are defined:

      *  Ephemeral Key Agreement.

      *  Public Key Encryption / Key Agreement under long term key

      *  Digital Signature.

   For performance and security reasons, the use of public key 
   encryption is almost invariably restricted to key agreement in 
   Internet protocols: A symmetric key is randomly generated and 
   encrypted under the public encryption key of the intended recipient.

   While the Diffie-Hellman and RSA algorithms are both capable of 
   supporting key agreement, the practice has arisen that the RSA 
   encryption algorithm is used in cases where a key is to be published 
   or endorsed in some form of PKI and use of the Diffie-Hellman 
   algorithm is limited to ephemeral key exchange where the ability to 
   generate new public keypairs rapidly is a requirement.

3.2.1. Ephemeral Key Agreement

   REQUIRED: Diffie-Hellman key exchange as described in [RFC2631].

   Rationale: Diffie-Helleman is the currently the consensus choic of 
   key exchange algorithm in applications where rapid generation of key 
   pairs is desirable. Unlike RSA which requires a search for two large 
   primes, generation of Diffie Hellman keys only requires a large 
   random number.

3.2.2. Public Key Encryption

   REQUIRED: RSA Public Key Encryption as described in [RFC3447].

   Implementations MUST support RSA Public Encryption key sizes of 2048 
   and 4096 bits. Implementations MUST NOT accept key sizes of less than
   2048 bits 

   Note 1: Following industry practice, an RSA modulus is considered to 
   be a '2048 bit' key size provided that it is greater than 2^2046.

   Rationale: RSA is the industry standard choice for non-emphemeral key
   exchange. While the use in Internet protocols is almost exclusively 
   for key exchange as opposed to encryption of data, longstanding 
   practice is to distinguish these uses. 







Hallam-Baker                 April 30, 2015                     [Page 9]

Internet-Draft     Consensus Cryptographic Algorithms       October 2014

3.2.3. Digital Signature 

   REQUIRED: RSA Public Key Signature as described in [RFC3447].

   Implementations MUST support RSA Digital Signature key sizes of 2048 
   and 4096 bits. Implementations MUST NOT accept key sizes of less than
   2048 bits 

   Note 1: Following industry practice, an RSA modulus is considered to 
   be a '2048 bit' key size provided that it is greater than 2^2046.

4. Recommended Algorithms

   While there is a strong consensus in favor of a Required set of 
   algorithms, no such consensus currently supports the selection of 
   Recommended algorithms except in the case of Cryptographic Digests.

4.1. Symmetric Key

4.1.1. Cryptographic Digest

   RECOMMENDED: SHA-3

   Rationale

4.1.2. Message Authentication Code

   RECOMMENDED: HMAC-SHA3

   The 

4.1.3. Encryption

   No Reccomendation.

   One of the chief advantages of using AES is that many commodity CPU 
   devices provide support for AES in dedicated circuits or circuits 
   optimized for AES use. As a result the best alternative to use of 
   AES-128 today is to use the AES-256 which requires more rounds of 
   processing in addition to the larger key size.

4.2. Public Key

   No Reccomendation.

   Although developments in cryptanalysis of public key cryptographic 
   algorithms strongly suggest that there is an urgent need to specify 
   an alternative to algorithms such as RSA and Diffie-Hellman based on 
   the discrete log problem, there is currently no clear consensus on a 
   single successor.




Hallam-Baker                 April 30, 2015                    [Page 10]

Internet-Draft     Consensus Cryptographic Algorithms       October 2014

   Although it is generally agreed that Elliptic Curve algorithms 
   provide the strongest contenders for replacement algorithms, recent 
   events have cast doubt on the choice of parameters. 

5. Obsolete Algorithms

   On publication of this document as an RFC, IANA shall create a 
   registry of Obsolete cryptographic algorithms containing the 
   following information. The IANA policy RFC Required shall apply to 
   creation of new entries in the registry.

   The set of obsolete algorithms SHALL be the set of algorithms listed 
   in the registry created.

   To avoid the implication that algorithms not listed as obsolete are 
   to be considered 'safe', only algorithms that have been previously 
   published as an RFC or approved for use as a strong cryptographic 
   algorithm in a document previously published as an RFC are eligible 
   for inclusion. For example, MD4 is eligible for inclusion as it is 
   described in [RFC1320]. 

      Algorithm Identifier
         The commonly used abbreviation of the obsolete algorithm.

      Long Name
         The long name of the obsolete algorithm.

      Document
         RFC in which the algorithm is declared obsolete. For example, 
         by moving the original specification of the algorithm to 
         HISTORIC status.

6. Further Work

   As noted previously, best practice for implementation of 
   cryptographic applications strongly encourages support for a reserve 
   or backup algorithm as a transition plan in case the mandatory to 
   implement choice should be found to be defective. With the exception 
   of cryptographi digests however, no existing algorithms can claim the
   backing of a strong community consensus. Work on building such 
   consensus is thus clearly advised.

   Public Key algorithms, the area in which immediate attention is 
   generally considered to be most needed is fortunately the area in 
   which prospects for short term success are greatest. While there is a
   strong consensus that Elliptic Curve cryptography [RFC6090] provides 
   the best alternative to discrete logarithm problems, recent events 
   have cast doubt over proposals to use specific shared parameters. 






Hallam-Baker                 April 30, 2015                    [Page 11]

Internet-Draft     Consensus Cryptographic Algorithms       October 2014

   For the limited purpose of defining a reserve algorithm set it is 
   sufficient to either limit the recommendation to implementation of an
   algorithm alone, to select a set of curves that are known to be free 
   of backdoors or to generate a completely new set of curves under 
   controlled conditions.

   Definition of an alternative encryption algorithm presents a greater 
   challenge. If the need for a substitute algorithm suddenly became 
   urgent, one of the runners-up in the AES competition might be chosen 
   as an expedient choice. But absent such circumstances, it is highly 
   unlikely that consensus could be reached on an AES alternative unless
   the choice was made through a similarly open competition based 
   process.

7. Security Considerations

   Since this whole document is about security, the focus of the 
   security considerations is properly the risks created by the document
   itself.

7.1. Outdated recommendations

   Algorithms within the Required or Recommended set may become 
   vulnerable to attack without updated recomendations being issued.

7.2. Monoculture

   Adopting a single set of Required and Recommended algorithms may 
   result in an algorithm monoculture such that new algorithms are 
   unable to become established.

   One of the main reasons for not completing the set of recommended 
   algorithms for the sake of completeness is to identify areas where 
   additional algorithm choices are required and a consensus building 
   effort is needed.

8. IANA Considerations

   Create a registry of obsolete algorithms.

9. Acnowledgements

10. References

10.1. Normative References

   [RFC4868]  Kelly, S.,Frankel, S., "Using HMAC-SHA-256, HMAC-SHA-384, 
              and HMAC-SHA-512 with IPsec", RFC 4868, May 2007.






Hallam-Baker                 April 30, 2015                    [Page 12]

Internet-Draft     Consensus Cryptographic Algorithms       October 2014

   [RFC3610]  Whiting, D.,Housley, R.,Ferguson, N., "Counter with CBC-
              MAC (CCM)", RFC 3610, September 2003.

   [RFC3447]  Jonsson, J.,Kaliski, B., "Public-Key Cryptography 
              Standards (PKCS) #1: RSA Cryptography Specifications 
              Version 2.1", RFC 3447, February 2003.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate 
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2631]  Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC 
              2631, June 1999.

   [RFC6234]  Eastlake, D.,Hansen, T., "US Secure Hash Algorithms (SHA 
              and SHA-based HMAC and HKDF)", RFC 6234, May 2011.

10.2. Informative References

   [RFC6090]  McGrew, D.,Igoe, K.,Salter, M., "Fundamental Elliptic 
              Curve Cryptography Algorithms", RFC 6090, February 2011.

   [RFC1320]  Rivest, R., "The MD4 Message-Digest Algorithm", RFC 1320, 
              April 1992.

Author's Address

   Phillip Hallam-Baker
   Comodo Group Inc.

   philliph@comodo.com
























Hallam-Baker                 April 30, 2015                    [Page 13]