One document matched: draft-schaad-cose-alg-01.xml
<?xml version='1.0' encoding='ascii'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<rfc ipr="trust200902" docName="draft-schaad-cose-alg-01" category="info" obsoletes="" updates="" submissionType="IETF" xml:lang="en">
<front>
<title>CBOR Encoded Message Syntax: Additional Algorithms</title>
<author initials="J." surname="Schaad" fullname="Jim Schaad">
<organization>August Cellars</organization>
<address>
<email>ietf@augustcellars.com</email>
</address>
</author>
<date/>
<area>Security</area>
<workgroup>COSE Working Group</workgroup>
<abstract>
<t>This document defines the identifiers and usage for a set of additional cryptographic algorithms in the CBOR Encoded Message (COSE) Syntax. </t>
<t>The algorithms setup in this docment are: RSA-PSS, RSA-OAEP, .... !!TBD!! </t>
</abstract>
<note title="Contributing to this document">
<!--RFC EDITOR - Please remove this note before publishing -->
<t>The source for this draft is being maintained in GitHub. Suggested changes should be submitted as pull requests at <eref target="https://github.com/cose-wg/cose-algs"/>. Instructions are on that page as well. Editorial changes can be managed in GitHub, but any substantial issues need to be discussed on the COSE mailing list. </t>
</note>
</front>
<middle>
<section anchor="introduction" title="Introduction" toc="default">
<t>In the process of writing RFCXXXX <xref target="I-D.ietf-cose-msg" pageno="false" format="default"/> several algorithms were removed from that document to be addressed at a later date. This document deals with a large set of the cryptographic algorithms which were removed at that time. </t>
<t>This document provides the necessary conventions needed to use the algorithms defined in this document. This document additionally provides the necessary registration in the appropriate IANA registry tables. </t>
<section anchor="requirements-terminology" title="Requirements Terminology" toc="default">
<!--NOTE FOR AUTHORS: We use the following terms in the document field - an entry in a CBOR array parameter - an element in a CBOR map (as oppose to 'member' which is frequently used in JSON label - the key of an element in a CBOR map. Unless otherwise separated from text, enclose with single quote marks value - the value of an element in a CBOR map -->
<t>The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in <xref target="RFC2119" pageno="false" format="default"/>. </t>
<t>When the words appear in lower case, their natural language meaning is used. </t>
</section>
<!--Removed this section until such a time as CBOR grammar is needed <section anchor="cbor-grammar" title="CBOR Grammar"> <t> There currently is no standard CBOR grammar available for use by specifications. We therefore describe the CBOR structures in prose. There is a version of a CBOR grammar in the CBOR Data Definition Language (CDDL) <xref target="I-D.greevenbosch-appsawg-cbor-cddl"/>. An informational version of the CBOR grammar that reflects what is in the prose can be found in <xref target="Grammar_Appendix"/>. CDDL has not been fixed, so this grammar may will only work with the version of CDDL at the time of publishing. </t> <t> The document was developed by first working on the grammar and then developing the prose to go with it. An artifact of this is that the prose was written using the primitive type strings defined by early versions CDDL. In this specification the following primitive types are used: <list style="none"> <t>bstr - byte string (major type 2).</t> <t>int - an unsigned integer or a negative integer.</t> <t>nil - a null value (tag 7.22).</t> <t>nint - a negative integer (major type 1).</t> <t>tstr - a UTF-8 text string (major type 3).</t> <t>uint - an unsigned integer (major type 0).</t> </list> </t> <! - - RFC EDITOR - Please make sure the following paragraphs have been removed. - - > <t> Text from here to start of next section to be removed </t> <t> NOTE: For the purposes of review, we are currently interlacing the CDLL grammar into the text of document. This is being done for simplicity of comparision of the grammar againist the prose. The grammar will be removed to an appendix during WGLC. </t> <figure><artwork type='CDDL'> <![CDATA[ start = COSE_Untagged_Message / COSE_Tagged_Message / COSE_Key / COSE_KeySet ]]></artwork></figure> </section> -->
<section title="Document Terminology" toc="default">
<t>In this document we use the following terminology: <cref source="JLS">I have not gone through the document to determine what needs to be here yet. We mostly want to grab terms which are used in unusual ways or are not generally understood. </cref> </t>
</section>
</section>
<section title="Signature Algorithms" toc="default">
<t>This document defines two new signature algorithms: RSA-PSS and Edwards Curve Digital Signature Algorithm (EdDSA). Both of these signature algorithms are Signature Scheme with Appendix algorithms. (For a discussion on the difference between signature scheme with appendix and signature scheme with message recovery algorithms, see <xref target="I-D.ietf-cose-msg" pageno="false" format="default"/>.) </t>
<section title="RSASSA-PSS" toc="default">
<t>The RSASSA-PSS signature algorithm is defined in <xref target="RFC3447" pageno="false" format="default"/>. </t>
<t>The RSASSA-PSS signature algorithm is parametized with a hash function (h), a mask generation function (mgf) and a salt length (sLen). For this specification, the mask generation function is fixed to be MGF1 as defined in <xref target="RFC3447" pageno="false" format="default"/>. It has been recommended that the same hash function be used for hashing the data as well as in the mask generation function, for this specification we following this recommendation. The salt length is the same length as the hash function output. </t>
<t>Implementations need to check that the key type is 'RSA' when creating or verifying a signature. </t>
<t>The algorithms defined in this document can be found in <xref target="table-rsa-algs" pageno="false" format="default"/>. </t>
<texttable anchor="table-rsa-algs" title="RSASSA-PSS Algorithm Values" suppress-title="false" align="center" style="full">
<ttcol align="left">name</ttcol>
<ttcol align="left">value</ttcol>
<ttcol align="left">hash</ttcol>
<ttcol align="left">salt length</ttcol>
<ttcol align="left">description</ttcol>
<c>PS256</c>
<c>TBD1</c>
<c>SHA-256</c>
<c>32</c>
<c>RSASSA-PSS w/ SHA-256</c>
<c>PS384</c>
<c>TBD2</c>
<c>SHA-384</c>
<c>48</c>
<c>RSASSA-PSS w/ SHA-384</c>
<c>PS512</c>
<c>TBD3</c>
<c>SHA-512</c>
<c>64</c>
<c>RSASSA-PSS w/ SHA-512</c>
</texttable>
<section title="Security Considerations" anchor="RSASSA-PSS-considerations" toc="default">
<t>In addition to needing to worry about keys that are too small to provide the required security, there are issues with keys that are too large. Denial of service attacks have been mounted with overly large keys. This has the potential to consume resources with potentially bad keys. There are two reasonable ways to address this attack. First, a key should not be used for a cryptographic operation until it has been matched back to an authorized user. This approach means that no cryptography would be done except for authorized users. Second, applications can impose maximum as well as minimum length requirements on keys. This limits the resources consumed even if the matching is not performed until the cryptography has been done. </t>
<t>There is a theoretical hash substitution attack that can be mounted against RSASSA-PSS. However, the requirement that the same hash function be used consistently for all operations is an effective mitigation against it. Unlike ECDSA, hash functions are not truncated so that the full hash value is always signed. The internal padding structure of RSASSA-PSS means that one needs to have multiple collisions between the two hash functions in order to be successful in producing a forgery based on changing the hash function. This is highly unlikely. </t>
</section>
</section>
<section title="Edwards-curve Digital Signature Algorithms (EdDSA)" toc="default">
<t><xref target="I-D.irtf-cfrg-eddsa" pageno="false" format="default"/> describes the elliptic curve signature scheme Edwards-curve Digital Signature Algorithm (EdDSA). In that document, the signature algorithm is instantiated using parameters for edwards25519 and edwards448 curves. The document additionally describes two variants of the EdDSA algorithm: Pure EdDSA, where no hash function is applied to the content before signing and, HashEdDSA where a hash function is applied to the content before signing and the result of that hash function is signed. For use with COSE, on the pure EdDSA version is used. This is because it is not expected that extremely large contents are going to be needed and, based on the arrangement of the message structure, the entire message is going to need to be held in memory in order to create or verify a signature. Thus, the use of an incremental update process would not be useful. Applications can provide the same features by defining the content of the message as a hash value and transporting the COSE message and the content as separate items. </t>
<t>The algorithms defined in this document can be found in <xref target="table-eddsa-algs" pageno="false" format="default"/>. A single signature algorithm is defined which can be used for multiple curves. </t>
<texttable anchor="table-eddsa-algs" title="EdDSA Algorithm Values" suppress-title="false" align="center" style="full">
<ttcol align="left">name</ttcol>
<ttcol align="left">value</ttcol>
<ttcol align="left">description</ttcol>
<c>EdDSA</c>
<c>*</c>
<c>EdDSA</c>
</texttable>
<t><xref target="I-D.irtf-cfrg-eddsa" pageno="false" format="default"/> describes the method of encoding the signature value. </t>
<t>When using a COSE key for this algorithm the following checks are made: <list style="symbols"><t>The 'kty' field MUST be present and it MUST be 'OKP'.</t><t>The 'crv' field MUST be present, and it MUST be a curve defined for this signature algorithm.</t><t>If the 'alg' field is present, it MUST match 'EdDSA'.</t><t>If the 'key_ops' field is present, it MUST include 'sign' when creating an EdDSA signature.</t><t>If the 'key_ops' field is present, it MUST include 'verify' when verifying an EdDSA signature.</t></list> </t>
</section>
</section>
<section title="Message Authentication (MAC) Algorithms" toc="default">
<t>This document defines no new Message Authentication Code algorithms. </t>
</section>
<section title="Content Encryption Algorithms" toc="default">
<t>This document defines no new content inception algorithms. </t>
</section>
<section title="Key Derivation Functions (KDF)" toc="default">
<t>This document defines new new key derivation functions. </t>
</section>
<section title="Recipient Algorithms" anchor="key-management-algs" toc="default">
<section title="RSAES-OAEP" toc="default">
<t>RSAES-OAEP is an asymmetric key encryption algorithm. The defintion of RSAEA-OAEP can be find in Section 7.1 of <xref target="RFC3447" pageno="false" format="default"/>. The algorithm is parameterized using a masking generation function (mgf), a hash function (h) and encoding parameters (P). For the algorithm identifiers defined in this section: <list style="symbols"><t>mgf is always set to MFG1 from <xref target="RFC3447" pageno="false" format="default"/> and uses the same hash function as h.</t><t>P is always set to the empty octet string.</t></list> <xref target="table-RSA-OAEP" pageno="false" format="default"/> summarizes the rest of the values. </t>
<texttable anchor="table-RSA-OAEP" title="RSAES-OAEP Algorithm Values" suppress-title="false" align="center" style="full">
<ttcol align="left">name</ttcol>
<ttcol align="left">value</ttcol>
<ttcol align="left">hash</ttcol>
<ttcol align="left">description</ttcol>
<c>RSAES-OAEP w/SHA-256</c>
<c>-25</c>
<c>SHA-256</c>
<c>RSAES OAEP w/ SHA-256</c>
<c>RSAES-OAEP w/SHA-512</c>
<c>-26</c>
<c>SHA-512</c>
<c>RSAES OAEP w/ SHA-512</c>
</texttable>
<t>The key type MUST be 'RSA'. </t>
<section title="Security Considerations for RSAES-OAEP" toc="default">
<t>A key size of 2048 bits or larger MUST be used with these algorithms. This key size corresponds roughly to the same strength as provided by a 128-bit symmetric encryption algorithm. </t>
<t>It is highly recommended that checks on the key length be done before starting a decryption operation. One potential denial of service operation is to provide encrypted objects using either abnormally long or oddly sized RSA modulus values. Implementations SHOULD be able to encrypt and decrypt with modulus between 2048 and 16K bits in length. Applications can impose additional restrictions on the length of the modulus. </t>
</section>
</section>
<section title="ECDH" toc="default">
<t>The algorithm ECDH is defined for use in COSE in <xref target="I-D.ietf-cose-msg" pageno="false" format="default"/>. In this document the algorithm is extended to be used with the two curves defined in <xref target="I-D.irtf-cfrg-curves" pageno="false" format="default"/>. </t>
<t>The following updates <xref target="I-D.ietf-cose-msg" pageno="false" format="default"/> sections 12.4.1 and 12.5.1. <list style="symbols"><t>OLD: The 'kty' field MUST be present and it MUST be 'EC2'.</t><t>NEW: The 'kty' field MUST be present and it MUST be 'EC2' or 'OKP'.</t></list> All the rest of the checks remain the same. </t>
</section>
<!--<section title="Password"> <t> <cref source="JLS"> Do we want/need to support this? JOSE did it mainly to support the encryption of private keys. </cref> </t> <section title="PBES2"> <texttable> <ttcol align='left'>name</ttcol> <ttcol align='left'>value</ttcol> <ttcol align='left'>description</ttcol> <c>PBES2-HS256+A128KW</c> <c>*</c> <c>PBES2 w/ HMAC SHA-256 and AES Key wrap w/ 128 bit key</c> <c>PBES2-HS384+A192KW</c> <c>*</c> <c>PBES2 w/ HMAC SHA-384 and AES Key wrap w/ 192 bit key</c> <c>PBES2-HS512+A256KW</c> <c>*</c> <c>PBES2 w/ HMAC SHA-512 and AES Key wrap w/ 256 bit key</c> </texttable> </section> </section> -->
</section>
<section title="Keys" anchor="Key-specific-labels" toc="default">
<t>The COSE_Key object defines a way to hold a single key object, it is still required that the members of individual key types be defined. This section of the document is where we define an initial set of members for specific key types. </t>
<t>For each of the key types, we define both public and private members. The public members are what is transmitted to others for their usage. We define private members mainly for the purpose of archival of keys by individuals. However, there are some circumstances where private keys may be distributed by various entities in a protocol. Examples include: Entities which have poor random number generation. Centralized key creation for multi-cast type operations. Protocols where a shared secret is used as a bearer token for authorization purposes. </t>
<t>Key types are identified by the 'kty' member of the COSE_Key object. In this document we define four values for the member. </t>
<texttable title="Key Type Values" anchor="table_key_types" suppress-title="false" align="center" style="full">
<ttcol align="left">name</ttcol>
<ttcol align="left">value</ttcol>
<ttcol align="left">description</ttcol>
<c>OPK</c>
<c>TBDXX</c>
<c>Octet Key Pair</c>
<c>RSA</c>
<c>TBDXX1</c>
<c>RSA Keys</c>
</texttable>
<section title="Octet Key Pair" toc="default">
<t>A new key type is defined for Octet Key Pairs (OKP). Do not assume that keys using this type are elliptic curves. This key type could be used for other curve types (for example mathematics based on hyper-elliptic surfaces). </t>
<t>The key parameters defined in this section are summarized in <xref target="table-ec1-keys" pageno="false" format="default"/>. The members that are defined for this key type are: <list style="hanging"><t hangText="crv">contains an identifier of the curve to be used with the key. <cref source="JLS">Is is the same registry for both OKP and EC2? </cref> The curves defined in this document for this key type can be found in <xref target="table-ec-curves" pageno="false" format="default"/>. Other curves may be registered in the future and private curves can be used as well. </t><t hangText="x">contains the x coordinate for the EC point. The octet string represents a little-endian encoding of x. </t><t hangText="d">contains the private key. </t></list> </t>
<t>For public keys, it is REQUIRED that 'crv' and 'x' be present in the structure. For private keys, it is REQUIRED that 'crv' and 'd' be present in the structure. For private keys, it is RECOMMENDED that 'x' also be present, but it can be recomputed from the required elements and omitting it saves on space. </t>
<texttable title="EC Key Parameters" anchor="table-ec1-keys" suppress-title="false" align="center" style="full">
<ttcol align="left">name</ttcol>
<ttcol align="left">key type</ttcol>
<ttcol align="left">value</ttcol>
<ttcol align="left">type</ttcol>
<ttcol align="left">description</ttcol>
<c>crv</c>
<c>1</c>
<c>-1</c>
<c>int / tstr</c>
<c>EC Curve identifier - Taken from the COSE General Registry</c>
<c>x</c>
<c>1</c>
<c>-2</c>
<c>bstr</c>
<c>X Coordinate</c>
<c>d</c>
<c>1</c>
<c>-4</c>
<c>bstr</c>
<c>Private key</c>
</texttable>
<texttable title="EC Curves" anchor="table-ec-curves" suppress-title="false" align="center" style="full">
<ttcol align="left">name</ttcol>
<ttcol align="left">key type</ttcol>
<ttcol align="left">value</ttcol>
<ttcol align="left">description</ttcol>
<c>Curve25519</c>
<c>EC1</c>
<c>TBDYY1</c>
<c>Curve 25519</c>
<c>Curve448</c>
<c>EC1</c>
<c>TBDYY2</c>
<c>Curve 448</c>
</texttable>
</section>
<section title="RSA Keys" toc="default">
<t>This document defines a key structure for both the public and private halves of RSA keys. Together, an RSA public key and an RSA private key form an RSA key pair. <cref source="JLS">Looking at the CBOR specification, the bstr that we are looking in our table below should most likely be specified as big numbers rather than as binary strings. This means that we would use the tag 6.2 instead. From my reading of the specification, there is no difference in the encoded size of the resulting output. The specification of bignum does explicitly allow for integers encoded with leading zeros. </cref> </t>
<t>The document also provides support for the so-called "multi-prime" RSA where the modulus may have more than two prime factors. The benefit of multi-prime RSA is lower computational cost for the decryption and signature primitives. For a discussion on how multi-prime affects the security of RSA crypto-systems, the reader is referred to <xref target="MultiPrimeRSA" pageno="false" format="default"/>. </t>
<t>This document follows the naming convention of <xref target="RFC3447" pageno="false" format="default"/> for the naming of the fields of an RSA public or private key. The table <xref target="table-rsa-keys" pageno="false" format="default"/> provides a summary of the label values and the types associated with each of those labels. The requirements for fields for RSA keys are as follows: <list style="symbols"><t>For all keys, 'kty' MUST be present and MUST have a value of 3. </t><t>For public keys, the fields 'n' and 'e' MUST be present. All other fields defined in <xref target="table-rsa-keys" pageno="false" format="default"/> MUST be absent. </t><t>For private keys with two primes, the fields 'other', 'r_i', 'd_i' and 't_i' MUST be absent, all other fields MUST be present. </t><t>For private keys with more than two primes, all fields MUST be present. For the third to nth primes, each of the primes is represented as a map containing the fields 'r_i', 'd_i' and 't_i'. The field 'other' is an array of those maps. </t></list> </t>
<texttable title="RSA Key Parameters" anchor="table-rsa-keys" suppress-title="false" align="center" style="full">
<ttcol align="left">name</ttcol>
<ttcol align="left">key type</ttcol>
<ttcol align="left">value</ttcol>
<ttcol align="left">type</ttcol>
<ttcol align="left">description</ttcol>
<c>n</c>
<c>3</c>
<c>-1</c>
<c>bstr</c>
<c>Modulus Parameter</c>
<c>e</c>
<c>3</c>
<c>-2</c>
<c>int</c>
<c>Exponent Parameter</c>
<c>d</c>
<c>3</c>
<c>-3</c>
<c>bstr</c>
<c>Private Exponent Parameter</c>
<c>p</c>
<c>3</c>
<c>-4</c>
<c>bstr</c>
<c>First Prime Factor</c>
<c>q</c>
<c>3</c>
<c>-5</c>
<c>bstr</c>
<c>Second Prime Factor</c>
<c>dP</c>
<c>3</c>
<c>-6</c>
<c>bstr</c>
<c>First Factor CRT Exponent</c>
<c>dQ</c>
<c>3</c>
<c>-7</c>
<c>bstr</c>
<c>Second Factor CRT Exponent</c>
<c>qInv</c>
<c>3</c>
<c>-8</c>
<c>bstr</c>
<c>First CRT Coefficient</c>
<c>other</c>
<c>3</c>
<c>-9</c>
<c>array</c>
<c>Other Primes Info</c>
<c>r_i</c>
<c>3</c>
<c>-10</c>
<c>bstr</c>
<c>i-th factor, Prime Factor</c>
<c>d_i</c>
<c>3</c>
<c>-11</c>
<c>bstr</c>
<c>i-th factor, Factor CRT Exponent</c>
<c>t_i</c>
<c>3</c>
<c>-12</c>
<c>bstr</c>
<c>i-th factor, Factor CRT Coefficient</c>
</texttable>
</section>
</section>
<section anchor="iana-considerations" title="IANA Considerations" toc="default">
<section anchor="cose-header-key-table" title="COSE Header Parameter Registry" toc="default">
<t>There are currently no registration requests here </t>
</section>
<section anchor="IANA-Alg-Registry" title="COSE Header Algorithm Label Table" toc="default">
<t>TBD</t>
</section>
<section anchor="cose-algorithm-registry" title="COSE Algorithm Registry" toc="default">
<t>TBD</t>
</section>
<section anchor="cose-key-map-registry" title="COSE Key Common Parameter Registry" toc="default">
<t>There are currently no registration tasks inthis section. </t>
</section>
<section anchor="cose-key-parameter-registry" title="COSE Key Type Parameter Registry" toc="default">
<t>It is requested that IANA create a new registry “COSE Key Type Parameters”. </t>
<t>The columns of the table are: </t>
<t><list style="hanging"><t hangText="key type">This field contains a descriptive string of a key type. This should be a value that is in the COSE General Values table and is placed in the 'kty' field of a COSE Key structure. </t><t hangText="name">This is a descriptive name that enables easier reference to the item. It is not used in the encoding. </t><t hangText="label">The label is to be unique for every value of key type. The range of values is from -256 to -1. Labels are expected to be reused for different keys. </t><t hangText="CBOR type">This field contains the CBOR type for the field </t><t hangText="description">This field contains a brief description for the field </t><t hangText="specification">This contains a pointer to the public specification for the field if one exists </t></list> </t>
<t>This registry will be initially populated by the values in <xref target="table-ec1-keys" pageno="false" format="default"/>, and <xref target="table-rsa-keys" pageno="false" format="default"/>. The specification column for all of these entries will be this document. </t>
</section>
<section anchor="cose-curve-registry" title="COSE Elliptic Curve Registry" toc="default">
<t>It is requested that IANA create a new registry “COSE Elliptic Curve Parameters”. </t>
<t>The columns of the table are: </t>
<t><list style="hanging"><t hangText="name">This is a descriptive name that enables easier reference to the item. It is not used in the encoding. </t><t hangText="value">This is the value used to identify the curve. These values MUST be unique. The integer values from -256 to 255 are designated as Standards Track Document Required. The the integer values from 256 to 65535 and -65536 to -257 are designated as Specification Required. Integer values over 65535 are designated as first come first serve. Integer values less than -65536 are marked as private use. </t><t hangText="key type">This designates the key type(s) that can be used with this curve. </t><t hangText="description">This field contains a brief description of the curve. </t><t hangText="specification">This contains a pointer to the public specification for the curve if one exists. </t></list> </t>
<t>This registry will be initially populated by the values in <xref target="table_key_types" pageno="false" format="default"/>. The specification column for all of these entries will be this document. </t>
</section>
</section>
<section anchor="security-considerations" title="Security Considerations" toc="default">
<t>There are security considerations: </t>
<t><list style="numbers"><t>Protect private keys </t><t>MAC messages with more than one recipient means one cannot figure out who sent the message </t><t>Use of direct key with other recipient structures hands the key to other recipients. </t><t>Use of direct ECDH direct encryption is easy for people to leak information on if there are other recipients in the message. </t><t>Considerations about protected vs unprotected header fields. </t><t>Need to verify that: 1) the kty field of the key matches the key and algorithm being used. 2) that the kty field needs to be included in the trust decision as well as the other key fields. 3) that the algorithm be included in the trust decision. </t></list> </t>
</section>
</middle>
<back>
<references title="Normative References"><reference anchor="RFC2119" target="http://www.rfc-editor.org/info/rfc2119"><front><title>Key words for use in RFCs to Indicate Requirement Levels</title><author initials="S." surname="Bradner" fullname="S. Bradner"><organization/></author><date year="1997" month="March"/><abstract><t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t></abstract></front><seriesInfo name="BCP" value="14"/><seriesInfo name="RFC" value="2119"/><seriesInfo name="DOI" value="10.17487/RFC2119"/></reference> <reference anchor="RFC7049" target="http://www.rfc-editor.org/info/rfc7049"><front><title>Concise Binary Object Representation (CBOR)</title><author initials="C." surname="Bormann" fullname="C. Bormann"><organization/></author><author initials="P." surname="Hoffman" fullname="P. Hoffman"><organization/></author><date year="2013" month="October"/><abstract><t>The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack.</t></abstract></front><seriesInfo name="RFC" value="7049"/><seriesInfo name="DOI" value="10.17487/RFC7049"/></reference> </references>
<references title="Informative References"><reference anchor="I-D.greevenbosch-appsawg-cbor-cddl"><front><title>CBOR data definition language (CDDL): a notational convention to express CBOR data structures</title><author initials="C" surname="Vigano" fullname="Christoph Vigano"><organization/></author><author initials="H" surname="Birkholz" fullname="Henk Birkholz"><organization/></author><date month="October" day="18" year="2015"/><abstract><t>This document proposes a notational convention to express CBOR data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR.</t></abstract></front><seriesInfo name="Internet-Draft" value="draft-greevenbosch-appsawg-cbor-cddl-07"/><format type="TXT" target="http://www.ietf.org/internet-drafts/draft-greevenbosch-appsawg-cbor-cddl-07.txt"/></reference> <!--&CBCMAC; --><reference anchor="RFC2104" target="http://www.rfc-editor.org/info/rfc2104"><front><title>HMAC: Keyed-Hashing for Message Authentication</title><author initials="H." surname="Krawczyk" fullname="H. Krawczyk"><organization/></author><author initials="M." surname="Bellare" fullname="M. Bellare"><organization/></author><author initials="R." surname="Canetti" fullname="R. Canetti"><organization/></author><date year="1997" month="February"/><abstract><t>This document describes HMAC, a mechanism for message authentication using cryptographic hash functions. HMAC can be used with any iterative cryptographic hash function, e.g., MD5, SHA-1, in combination with a secret shared key. The cryptographic strength of HMAC depends on the properties of the underlying hash function. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind</t></abstract></front><seriesInfo name="RFC" value="2104"/><seriesInfo name="DOI" value="10.17487/RFC2104"/></reference> <reference anchor="RFC2633" target="http://www.rfc-editor.org/info/rfc2633"><front><title>S/MIME Version 3 Message Specification</title><author initials="B." surname="Ramsdell" fullname="B. Ramsdell" role="editor"><organization/></author><date year="1999" month="June"/><abstract><t>This document describes a protocol for adding cryptographic signature and encryption services to MIME data. [STANDARDS-TRACK]</t></abstract></front><seriesInfo name="RFC" value="2633"/><seriesInfo name="DOI" value="10.17487/RFC2633"/></reference> <reference anchor="RFC2898" target="http://www.rfc-editor.org/info/rfc2898"><front><title>PKCS #5: Password-Based Cryptography Specification Version 2.0</title><author initials="B." surname="Kaliski" fullname="B. Kaliski"><organization/></author><date year="2000" month="September"/><abstract><t>This document provides recommendations for the implementation of password-based cryptography, covering key derivation functions, encryption schemes, message-authentication schemes, and ASN.1 syntax identifying the techniques. This memo provides information for the Internet community.</t></abstract></front><seriesInfo name="RFC" value="2898"/><seriesInfo name="DOI" value="10.17487/RFC2898"/></reference> <reference anchor="RFC3394" target="http://www.rfc-editor.org/info/rfc3394"><front><title>Advanced Encryption Standard (AES) Key Wrap Algorithm</title><author initials="J." surname="Schaad" fullname="J. Schaad"><organization/></author><author initials="R." surname="Housley" fullname="R. Housley"><organization/></author><date year="2002" month="September"/></front><seriesInfo name="RFC" value="3394"/><seriesInfo name="DOI" value="10.17487/RFC3394"/></reference> <reference anchor="RFC3447" target="http://www.rfc-editor.org/info/rfc3447"><front><title>Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1</title><author initials="J." surname="Jonsson" fullname="J. Jonsson"><organization/></author><author initials="B." surname="Kaliski" fullname="B. Kaliski"><organization/></author><date year="2003" month="February"/><abstract><t>This memo represents a republication of PKCS #1 v2.1 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series, and change control is retained within the PKCS process. The body of this document is taken directly from the PKCS #1 v2.1 document, with certain corrections made during the publication process. This memo provides information for the Internet community.</t></abstract></front><seriesInfo name="RFC" value="3447"/><seriesInfo name="DOI" value="10.17487/RFC3447"/></reference> <reference anchor="RFC3610" target="http://www.rfc-editor.org/info/rfc3610"><front><title>Counter with CBC-MAC (CCM)</title><author initials="D." surname="Whiting" fullname="D. Whiting"><organization/></author><author initials="R." surname="Housley" fullname="R. Housley"><organization/></author><author initials="N." surname="Ferguson" fullname="N. Ferguson"><organization/></author><date year="2003" month="September"/><abstract><t>Counter with CBC-MAC (CCM) is a generic authenticated encryption block cipher mode. CCM is defined for use with 128-bit block ciphers, such as the Advanced Encryption Standard (AES).</t></abstract></front><seriesInfo name="RFC" value="3610"/><seriesInfo name="DOI" value="10.17487/RFC3610"/></reference> <reference anchor="RFC4231" target="http://www.rfc-editor.org/info/rfc4231"><front><title>Identifiers and Test Vectors for HMAC-SHA-224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512</title><author initials="M." surname="Nystrom" fullname="M. Nystrom"><organization/></author><date year="2005" month="December"/><abstract><t>This document provides test vectors for the HMAC-SHA-224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 message authentication schemes. It also provides ASN.1 object identifiers and Uniform Resource Identifiers (URIs) to identify use of these schemes in protocols. The test vectors provided in this document may be used for conformance testing. [STANDARDS-TRACK]</t></abstract></front><seriesInfo name="RFC" value="4231"/><seriesInfo name="DOI" value="10.17487/RFC4231"/></reference> <reference anchor="RFC4262" target="http://www.rfc-editor.org/info/rfc4262"><front><title>X.509 Certificate Extension for Secure/Multipurpose Internet Mail Extensions (S/MIME) Capabilities</title><author initials="S." surname="Santesson" fullname="S. Santesson"><organization/></author><date year="2005" month="December"/><abstract><t>This document defines a certificate extension for inclusion of Secure/Multipurpose Internet Mail Extensions (S/MIME) Capabilities in X.509 public key certificates, as defined by RFC 3280. This certificate extension provides an optional method to indicate the cryptographic capabilities of an entity as a complement to the S/MIME Capabilities signed attribute in S/MIME messages according to RFC 3851. [STANDARDS-TRACK]</t></abstract></front><seriesInfo name="RFC" value="4262"/><seriesInfo name="DOI" value="10.17487/RFC4262"/></reference> <reference anchor="RFC5480" target="http://www.rfc-editor.org/info/rfc5480"><front><title>Elliptic Curve Cryptography Subject Public Key Information</title><author initials="S." surname="Turner" fullname="S. Turner"><organization/></author><author initials="D." surname="Brown" fullname="D. Brown"><organization/></author><author initials="K." surname="Yiu" fullname="K. Yiu"><organization/></author><author initials="R." surname="Housley" fullname="R. Housley"><organization/></author><author initials="T." surname="Polk" fullname="T. Polk"><organization/></author><date year="2009" month="March"/><abstract><t>This document specifies the syntax and semantics for the Subject Public Key Information field in certificates that support Elliptic Curve Cryptography. This document updates Sections 2.3.5 and 5, and the ASN.1 module of "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3279. [STANDARDS-TRACK]</t></abstract></front><seriesInfo name="RFC" value="5480"/><seriesInfo name="DOI" value="10.17487/RFC5480"/></reference> <reference anchor="RFC5652" target="http://www.rfc-editor.org/info/rfc5652"><front><title>Cryptographic Message Syntax (CMS)</title><author initials="R." surname="Housley" fullname="R. Housley"><organization/></author><date year="2009" month="September"/><abstract><t>This document describes the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content. [STANDARDS-TRACK]</t></abstract></front><seriesInfo name="STD" value="70"/><seriesInfo name="RFC" value="5652"/><seriesInfo name="DOI" value="10.17487/RFC5652"/></reference> <reference anchor="RFC5751" target="http://www.rfc-editor.org/info/rfc5751"><front><title>Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification</title><author initials="B." surname="Ramsdell" fullname="B. Ramsdell"><organization/></author><author initials="S." surname="Turner" fullname="S. Turner"><organization/></author><date year="2010" month="January"/><abstract><t>This document defines Secure/Multipurpose Internet Mail Extensions (S/MIME) version 3.2. S/MIME provides a consistent way to send and receive secure MIME data. Digital signatures provide authentication, message integrity, and non-repudiation with proof of origin. Encryption provides data confidentiality. Compression can be used to reduce data size. This document obsoletes RFC 3851. [STANDARDS-TRACK]</t></abstract></front><seriesInfo name="RFC" value="5751"/><seriesInfo name="DOI" value="10.17487/RFC5751"/></reference> <reference anchor="RFC5752" target="http://www.rfc-editor.org/info/rfc5752"><front><title>Multiple Signatures in Cryptographic Message Syntax (CMS)</title><author initials="S." surname="Turner" fullname="S. Turner"><organization/></author><author initials="J." surname="Schaad" fullname="J. Schaad"><organization/></author><date year="2010" month="January"/><abstract><t>Cryptographic Message Syntax (CMS) SignedData includes the SignerInfo structure to convey per-signer information. SignedData supports multiple signers and multiple signature algorithms per signer with multiple SignerInfo structures. If a signer attaches more than one SignerInfo, there are concerns that an attacker could perform a downgrade attack by removing the SignerInfo(s) with the \'strong' algorithm(s). This document defines the multiple-signatures attribute, its generation rules, and its processing rules to allow signers to convey multiple SignerInfo objects while protecting against downgrade attacks. Additionally, this attribute may assist during periods of algorithm migration. [STANDARDS-TRACK]</t></abstract></front><seriesInfo name="RFC" value="5752"/><seriesInfo name="DOI" value="10.17487/RFC5752"/></reference> <reference anchor="RFC5869" target="http://www.rfc-editor.org/info/rfc5869"><front><title>HMAC-based Extract-and-Expand Key Derivation Function (HKDF)</title><author initials="H." surname="Krawczyk" fullname="H. Krawczyk"><organization/></author><author initials="P." surname="Eronen" fullname="P. Eronen"><organization/></author><date year="2010" month="May"/><abstract><t>This document specifies a simple Hashed Message Authentication Code (HMAC)-based key derivation function (HKDF), which can be used as a building block in various protocols and applications. The key derivation function (KDF) is intended to support a wide range of applications and requirements, and is conservative in its use of cryptographic hash functions. This document is not an Internet Standards Track specification; it is published for informational purposes.</t></abstract></front><seriesInfo name="RFC" value="5869"/><seriesInfo name="DOI" value="10.17487/RFC5869"/></reference> <reference anchor="RFC5990" target="http://www.rfc-editor.org/info/rfc5990"><front><title>Use of the RSA-KEM Key Transport Algorithm in the Cryptographic Message Syntax (CMS)</title><author initials="J." surname="Randall" fullname="J. Randall"><organization/></author><author initials="B." surname="Kaliski" fullname="B. Kaliski"><organization/></author><author initials="J." surname="Brainard" fullname="J. Brainard"><organization/></author><author initials="S." surname="Turner" fullname="S. Turner"><organization/></author><date year="2010" month="September"/><abstract><t>The RSA-KEM Key Transport Algorithm is a one-pass (store-and-forward) mechanism for transporting keying data to a recipient using the recipient's RSA public key. ("KEM" stands for "key encapsulation mechanism".) This document specifies the conventions for using the RSA-KEM Key Transport Algorithm with the Cryptographic Message Syntax (CMS). The ASN.1 syntax is aligned with an expected forthcoming change to American National Standard (ANS) X9.44.</t></abstract></front><seriesInfo name="RFC" value="5990"/><seriesInfo name="DOI" value="10.17487/RFC5990"/></reference> <reference anchor="RFC6090" target="http://www.rfc-editor.org/info/rfc6090"><front><title>Fundamental Elliptic Curve Cryptography Algorithms</title><author initials="D." surname="McGrew" fullname="D. McGrew"><organization/></author><author initials="K." surname="Igoe" fullname="K. Igoe"><organization/></author><author initials="M." surname="Salter" fullname="M. Salter"><organization/></author><date year="2011" month="February"/><abstract><t>This note describes the fundamental algorithms of Elliptic Curve Cryptography (ECC) as they were defined in some seminal references from 1994 and earlier. These descriptions may be useful for implementing the fundamental algorithms without using any of the specialized methods that were developed in following years. Only elliptic curves defined over fields of characteristic greater than three are in scope; these curves are those used in Suite B. This document is not an Internet Standards Track specification; it is published for informational purposes.</t></abstract></front><seriesInfo name="RFC" value="6090"/><seriesInfo name="DOI" value="10.17487/RFC6090"/></reference> <reference anchor="RFC6151" target="http://www.rfc-editor.org/info/rfc6151"><front><title>Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms</title><author initials="S." surname="Turner" fullname="S. Turner"><organization/></author><author initials="L." surname="Chen" fullname="L. Chen"><organization/></author><date year="2011" month="March"/><abstract><t>This document updates the security considerations for the MD5 message digest algorithm. It also updates the security considerations for HMAC-MD5. This document is not an Internet Standards Track specification; it is published for informational purposes.</t></abstract></front><seriesInfo name="RFC" value="6151"/><seriesInfo name="DOI" value="10.17487/RFC6151"/></reference> <reference anchor="RFC6979" target="http://www.rfc-editor.org/info/rfc6979"><front><title>Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA)</title><author initials="T." surname="Pornin" fullname="T. Pornin"><organization/></author><date year="2013" month="August"/><abstract><t>This document defines a deterministic digital signature generation procedure. Such signatures are compatible with standard Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA) digital signatures and can be processed with unmodified verifiers, which need not be aware of the procedure described therein. Deterministic signatures retain the cryptographic security features associated with digital signatures but can be more easily implemented in various environments, since they do not need access to a source of high-quality randomness.</t></abstract></front><seriesInfo name="RFC" value="6979"/><seriesInfo name="DOI" value="10.17487/RFC6979"/></reference> <reference anchor="RFC7159" target="http://www.rfc-editor.org/info/rfc7159"><front><title>The JavaScript Object Notation (JSON) Data Interchange Format</title><author initials="T." surname="Bray" fullname="T. Bray" role="editor"><organization/></author><date year="2014" month="March"/><abstract><t>JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data.</t><t>This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance.</t></abstract></front><seriesInfo name="RFC" value="7159"/><seriesInfo name="DOI" value="10.17487/RFC7159"/></reference> <reference anchor="RFC7252" target="http://www.rfc-editor.org/info/rfc7252"><front><title>The Constrained Application Protocol (CoAP)</title><author initials="Z." surname="Shelby" fullname="Z. Shelby"><organization/></author><author initials="K." surname="Hartke" fullname="K. Hartke"><organization/></author><author initials="C." surname="Bormann" fullname="C. Bormann"><organization/></author><date year="2014" month="June"/><abstract><t>The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation.</t><t>CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments.</t></abstract></front><seriesInfo name="RFC" value="7252"/><seriesInfo name="DOI" value="10.17487/RFC7252"/></reference> <reference anchor="RFC7515" target="http://www.rfc-editor.org/info/rfc7515"><front><title>JSON Web Signature (JWS)</title><author initials="M." surname="Jones" fullname="M. Jones"><organization/></author><author initials="J." surname="Bradley" fullname="J. Bradley"><organization/></author><author initials="N." surname="Sakimura" fullname="N. Sakimura"><organization/></author><date year="2015" month="May"/><abstract><t>JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and an IANA registry defined by that specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification.</t></abstract></front><seriesInfo name="RFC" value="7515"/><seriesInfo name="DOI" value="10.17487/RFC7515"/></reference> <reference anchor="RFC7516" target="http://www.rfc-editor.org/info/rfc7516"><front><title>JSON Web Encryption (JWE)</title><author initials="M." surname="Jones" fullname="M. Jones"><organization/></author><author initials="J." surname="Hildebrand" fullname="J. Hildebrand"><organization/></author><date year="2015" month="May"/><abstract><t>JSON Web Encryption (JWE) represents encrypted content using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries defined by that specification. Related digital signature and Message Authentication Code (MAC) capabilities are described in the separate JSON Web Signature (JWS) specification.</t></abstract></front><seriesInfo name="RFC" value="7516"/><seriesInfo name="DOI" value="10.17487/RFC7516"/></reference> <reference anchor="RFC7517" target="http://www.rfc-editor.org/info/rfc7517"><front><title>JSON Web Key (JWK)</title><author initials="M." surname="Jones" fullname="M. Jones"><organization/></author><date year="2015" month="May"/><abstract><t>A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data structure that represents a cryptographic key. This specification also defines a JWK Set JSON data structure that represents a set of JWKs. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries established by that specification.</t></abstract></front><seriesInfo name="RFC" value="7517"/><seriesInfo name="DOI" value="10.17487/RFC7517"/></reference> <reference anchor="RFC7518" target="http://www.rfc-editor.org/info/rfc7518"><front><title>JSON Web Algorithms (JWA)</title><author initials="M." surname="Jones" fullname="M. Jones"><organization/></author><date year="2015" month="May"/><abstract><t>This specification registers cryptographic algorithms and identifiers to be used with the JSON Web Signature (JWS), JSON Web Encryption (JWE), and JSON Web Key (JWK) specifications. It defines several IANA registries for these identifiers.</t></abstract></front><seriesInfo name="RFC" value="7518"/><seriesInfo name="DOI" value="10.17487/RFC7518"/></reference> <reference anchor="RFC7539" target="http://www.rfc-editor.org/info/rfc7539"><front><title>ChaCha20 and Poly1305 for IETF Protocols</title><author initials="Y." surname="Nir" fullname="Y. Nir"><organization/></author><author initials="A." surname="Langley" fullname="A. Langley"><organization/></author><date year="2015" month="May"/><abstract><t>This document defines the ChaCha20 stream cipher as well as the use of the Poly1305 authenticator, both as stand-alone algorithms and as a "combined mode", or Authenticated Encryption with Associated Data (AEAD) algorithm.</t><t>This document does not introduce any new crypto, but is meant to serve as a stable reference and an implementation guide. It is a product of the Crypto Forum Research Group (CFRG).</t></abstract></front><seriesInfo name="RFC" value="7539"/><seriesInfo name="DOI" value="10.17487/RFC7539"/></reference> <reference anchor="I-D.irtf-cfrg-curves"><front><title>Elliptic Curves for Security</title><author initials="A" surname="Langley" fullname="Adam Langley"><organization/></author><author initials="M" surname="Hamburg" fullname="Mike Hamburg"><organization/></author><date month="October" day="9" year="2015"/><abstract><t>This memo specifies two elliptic curves over prime fields that offer high practical security in cryptographic applications, including Transport Layer Security (TLS). These curves are intended to operate at the ~128-bit and ~224-bit security level, respectively, and are generated deterministically based on a list of required properties.</t></abstract></front><seriesInfo name="Internet-Draft" value="draft-irtf-cfrg-curves-11"/><format type="TXT" target="http://www.ietf.org/internet-drafts/draft-irtf-cfrg-curves-11.txt"/></reference> <reference anchor="I-D.irtf-cfrg-eddsa"><front><title>Edwards-curve Digital Signature Algorithm (EdDSA)</title><author initials="S" surname="Josefsson" fullname="Simon Josefsson"><organization/></author><author initials="I" surname="Liusvaara" fullname="Ilari Liusvaara"><organization/></author><date month="March" day="21" year="2016"/><abstract><t>The elliptic curve signature scheme Edwards-curve Digital Signature Algorithm (EdDSA) is described. The algorithm is instantiated with recommended parameters for the edwards25519 and edwards448 curves. An example implementation and test vectors are provided.</t></abstract></front><seriesInfo name="Internet-Draft" value="draft-irtf-cfrg-eddsa-05"/><format type="TXT" target="http://www.ietf.org/internet-drafts/draft-irtf-cfrg-eddsa-05.txt"/></reference> <reference anchor="I-D.ietf-cose-msg"><front><title>CBOR Encoded Message Syntax</title><author initials="J" surname="Schaad" fullname="Jim Schaad"><organization/></author><date month="February" day="7" year="2016"/><abstract><t>Concise Binary Object Representation (CBOR) is data format designed for small code size and small message size. There is a need for the ability to have the basic security services defined for this data format. This document specifies processing for signatures, message authentication codes, and encryption using CBOR. This document also specifies a representation for cryptographic keys using CBOR.</t></abstract></front><seriesInfo name="Internet-Draft" value="draft-ietf-cose-msg-10"/><format type="TXT" target="http://www.ietf.org/internet-drafts/draft-ietf-cose-msg-10.txt"/></reference> <reference anchor="AES-GCM"><front><title>NIST Special Publication 800-38D: Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC.</title><author initials="M." surname="Dworkin"><organization>U.S. National Institute of Standards and Technology</organization></author><date year="2007" month="Nov"/></front><format target="https://csrc.nist.gov/publications/nistpubs/800-38D/SP-800-38D.pdf" type="PDF"/></reference><reference anchor="MAC"><front><title>FIPS PUB 113: Computer Data Authentication</title><author initials="N" surname="NiST"/><date year="1985" month="May"/></front><format target="http://csrc.nist.gov/publications/fips/fips113/fips113.html" type="HTML"/></reference><reference anchor="DSS"><front><title>Digital Signature Standard (DSS)</title><author><organization>U.S. National Institute of Standards and Technology</organization></author><date year="2013" month="July"/></front><format target="http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf" type="PDF"/></reference><reference anchor="SP800-56A"><front><title>NIST Special Publication 800-56A: Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography</title><author initials="E." surname="Barker"><organization>U.S. National Institute of Standards and Technology</organization></author><author initials="L." surname="Chen"><organization>U.S. National Institute of Standards and Technology</organization></author><author initials="A." surname="Roginsky"><organization>U.S. National Institute of Standards and Technology</organization></author><author initials="M." surname="Smid"><organization>Orion Security Solutions, Inc.</organization></author><date year="2013" month="May"/></front><format target="https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Ar2.pdf" type="PDF"/></reference><reference anchor="SEC1"><front><title>SEC 1: Elliptic Curve Cryptography</title><author><organization>Standards for Efficient Cryptography Group</organization></author><date year="2009" month="May"/></front><format target="http://www.secg.org/sec1-v2.pdf" type="PDF"/></reference><reference anchor="MultiPrimeRSA"><front><title>On the Security of Multi-prime RSA</title><author initials="M. J." surname="Hinek"><organization>University of Waterloo</organization></author><author initials="D. R." surname="Cheriton"><organization>University of Waterloo</organization></author><date year="2006" month="June"/></front><format target="http://cacr.uwaterloo.ca/techreports/2006/cacr2006-16.pdf" type="PDF"/></reference><reference anchor="PVSig"><front><title>Formal Security Proofs for a Signature Scheme with Partial Message Recover</title><author initials="D." surname="Brown"/><author initials="D." surname="Johnson"/><date year="2000" month="February"/></front><format target="https://www.certicom.com/images/pdfs/CerticomWP-PVSigSec_login.pdf" type="PDF"/></reference></references>
<section title="Document Updates" toc="default">
<section title="Version -00" toc="default">
<t><list style="symbols"><t>TBD</t></list> </t>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 07:18:23 |