diff --git a/draft-ietf-cose-hash-algs.xml b/draft-ietf-cose-hash-algs.xml new file mode 100644 index 0000000..ac337d0 --- /dev/null +++ b/draft-ietf-cose-hash-algs.xml @@ -0,0 +1,366 @@ + + + + + + + + + CBOR Object Signing and Encryption (COSE): Hash Algorithms + + + August Cellars +
+ ietf@augustcellars.com +
+ + + Security + + + The CBOR Object Signing and Encryption (COSE) syntax does not define any direct methods for using hash algorithms. + There are however circumstances where hash algorithms are used: + Indirect signatures where the hash of one or more contents are signed. + X.509 certificate or other object identification by the use of a thumbprint. + This document defines a set of hash algorithms that are identified by COSE Algorithm Identifiers. + + + + Contributing to this document + + + The source for this draft is being maintained in GitHub. + Suggested changes should be submitted as pull requests at TBD. + Editorial changes can be managed in GitHub, but any substantial issues need to be discussed on the COSE mailing list. + + + + +
+ Introduction + + The CBOR Object Signing and Encryption (COSE) syntax does not define any direct methods for the use of hash algorithms. + It also does not define a structure syntax that is used to encode a digested object structure along the lines of the DigestedData ASN.1 structure in . + This omission was intentional as a structure consisting of jut a digest identifier, the content, and a digest value does not by itself provide any strong security service. + Additional, an application is going to be better off defining this type of structure so that it can add any additional data that needs to be hashed as well as methods of obtaining the data. + + + While the above is true, there are some cases where having some standard hash algorithms defined for COSE with a common identifier makes a great deal of sense. + Two of the cases where these are going to be used are: + +
    +
  • + Indirect signing of content, and +
    • +
  • + Object identification. +
    • +
+ + Indirect signing of content is a paradigm where the content is not directly signed, but instead a hash of the content is computed and that hash value, along with the hash algorithm, is included in the content that will be signed. + Doing indirect signing allows for the a signature to be validated without first downloading all of the content associated with the signature. + This capability can be of even grater importance in a constrained environment as not all of the content signed may be needed by the device. + + + The use of hashes to identify objects is something that has been very common. + One of the primary things that has been identified by a hash function for secure message is a certificate. + Two examples of this can be found in and the newly defined COSE equivalents in . + +
+ Requirements Terminology + + 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 BCP 14 when, and only when, they appear in all capitals, as shown here. + +
+ +
+ Open Issues +
    +
  • + Are there additional SHA-2 formulations that need to be added or should some of the ones in this document be removed? +
    • +
  • + Should additional hash algorithms be added to the document? +
    • +
  • + Review the Recommended column in all of the tables to make sure that the values are correct. +
    • +
  • + Are there recommendations that should be provided on what range of identifiers should be used for these algorithms? + Inputs would include the expected frequency of use for each algorithm. +
    • +
+
+
+
+ Hash Algorithm Identifiers + +
+ SHA-1 Hash Algorithm + + The SHA-1 hash algorithm wsa designed by the United States National Security Agenciy and published in 1995. + Since that time a large amount of cryptographic analysis has been applied to this algorithm and a successful collision attack has been created (). + The IETF formally started discouraging the use of SHA-1 with the publishing of . + + + + Dispite the above, there are still times where SHA-1 needs to be used and therefore it makes sense to assign a point for the use of this hash algorithm. + Some of these situations are with historic HSMs where only SHA-1 is implemented or where the SHA-1 value is used for the purpose of filtering and thus the collision resistance property is not needed. + + + + Because of the known issues for SHA-1 and the fact that is should no longer be used, the algorithm will be registered with the recommendation of "Depreciated". + + + + SHA-1 Hash Algorithm + + + + + + + + + + + + + + + + + + +
NameValueDescriptionReferenceRecommended
SHA-1TBD6SHA-1 Hash[This Document]Depreciated
+ +
+ +
+ SHA-2 Hash Algorithms + + The family of SHA-2 hash algorithms was designed by the United States National Security Agency and published in 2001. + Since that time some additional algorithms have been added to the original set to deal with length extension attacks and some performance issues. + While the SHA-3 hash algorithms has been published since that time, the SHA-2 algorithms are still broadly used. + + + + There are a number of different parameters for the SHA-2 hash functions. + The set of hash functions which have been chosen for inclusion in this document are based on those different parameters and some of the trade-offs involved. + +
    +
  • + + SHA-256/64 provides a truncated hash. + The length of the truncation is designed to allow for smaller transmission size. + The trade-off is that the odds that a collision will occur increase proportionally. + Locations that use this hash function need either to analysis the potential problems with having a collision occur, or where the only function of the hash is to narrow the possible choices. + + + The latter is the case for , the hash value is used to select possible certificates and, if there are multiple choices then, each choice can be tested by using the public key. + +
    • +
  • + SHA-256 is probably the most common hash function used currently. + SHA-256 is the most efficient hash algorithm for 32-bit hardware. +
    • +
  • + SHA-384 and SHA-512 hash functions are more efficient when run on 64-bit hardware. +
    • +
  • + SHA-512/256 provides a hash function that runs more efficiently on 64-bit hardware, but offers the same security levels as SHA-256. +
    • +
+ + + SHA-2 Hash Algorithms + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
NameValueDescriptionReferenceRecommended
SHA-256/64TBD1SHA-2 256-bit Hash truncated to 64-bits[This Document]No
SHA-256TBD2SHA-2 256-bit Hash[This Document]Yes
SHA-384TBD3SHA-2 384-bit Hash[This Document]Yes
SHA-512TBD4SHA-2 512-bit Hash[This Document]Yes
SHA-512/256TBD5SHA-2 512-bit Hash truncated to 256-bits[This Document]Yes
+
+ +
+ SHAKE Algorithms + + + The family SHA-3 hash algorithms was the result of a competition run by NIST. + The pair of algorithms known as SHAKE-128 and SHAKE-256 are the instances of SHA-3 that are currently being standardized in the IETF. + + + + The SHA-3 hash algorithms have a significantly different structure than the SHA-3 hash algorithms. + One of the benefits of this differences is that when computing a truncated SHAKE hash value, the value is not a prefix of a longer version of the same value. + + + + MAYBE TEXT: + Might not need to define truncated versions of this hash algorithm because the length of the resulting value is always going to generate a unique value since you cannot just truncate it like you can with SHA-1 and SHA-2. + + + + SHAKE Hash Functions + + + + + + + + + + + + + + + + + + + + + + + + + +
NameValueDescriptionReferenceRecommended
SHAKE128TBD10128-bit SHAKE[This Document]Yes
SHAKE256TBD11256-bit SHAKE[This Document]Yes
+
+
+ +
+ IANA Considerations +
+ COSE Algorithm Registry + + IANA is requested to register the following algorithms in the "COSE Algorithms" registry. + +
    +
  • + The SHA-1 hash function found in . +
    • +
  • + The set of SHA-2 hash functions found in . +
    • +
  • + The set of SHAKE hash functions found in . +
    • +
+ + + Many of the hash values produced are relatively long and as such the use of a two byte algorithm identifier seems reasonable. + SHA-1 is tagged as deprecated and thus a longer algorithm identifier is appropriate even though it is a shorter hash value. + +
+
+ +
+ Security Considerations + + There are security considerations: + +
+ + + + + + + + + + + + + + Secure Hash Standard + + National Institute of Standards and Technology + + + + + + + + + + + + + + + + + + + + + + The first collision for full SHA-1 + + + + + + + + + + + diff --git a/draft-ietf-cose-x509.xml b/draft-ietf-cose-x509.xml index ae1035b..307cfbc 100644 --- a/draft-ietf-cose-x509.xml +++ b/draft-ietf-cose-x509.xml @@ -1,40 +1,6 @@ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ]> @@ -58,14 +24,10 @@ Security - The CBOR Encoded Message (COSE) structure syntax uses the COSE Key structure for placing keys in a message. - This document extends the way that keys can be identified and transported by providing parameters that refer to or contain X.509 certificates in messages and in the COSE Key structure. + The CBOR Signing And Encrypted Message (COSE) structure syntax uses the COSE Key structure for placing keys in a message. + This document extends the way that keys can be identified and transported by providing attributes that refer to or contain X.509 certificates. - - This document defines a set of hash algorithms for COSE. - These algorithms are needed in order to have X.509 certificates referred to by a thumbprint. - @@ -84,9 +46,9 @@
In the process of writing discussions where held on the question of X.509 certificates and if there was a needed to provide for them. - At the time there were no use cases presented that appeared to have a sufficient set of support to include these headers. + At the time there were no use cases presented that appeared to have a sufficient need for these attributes. Since that time a number of cases where X.509 certificate support is necessary have been defined. - This document provides a set of headers that will allow applications to transport and refer to X.509 certificates in a consistent manner. + This document provides a set of attributes that will allow applications to transport and refer to X.509 certificates in a consistent manner. @@ -98,10 +60,8 @@ - When was written, there were no requirements for hash algorithms to be included in the algorithm registry. - The use of thumbprints to refer to X.509 certificates is defined in this document which requires the use of hash algorithms. - There have also been other working groups in the IETF that have expressed a requirement for hash algorithms to do have sections of content be provided by reference rather than including it in the main message. - This document defines a set of hash algorithms for both of these purposes. + Example COSE messages for the various headers defined below can be found at https://github.com/cose-wg/Examples. + THIS IS NOT YET DONE BUT SHOULD BE COMING NOT LONG AFTER THE F2F MEETING.
@@ -130,10 +90,13 @@ Are there any special certificate valiation text to be added? - List of other hash algorithms to be added. + Specific security considerations issues. - Specific security considerations issues. + Revocation info? + + + Ties to a COSE_Key? @@ -160,20 +123,20 @@ - The header parameters defined in this document are: + The header attributes defined in this document are: - This header parameters contains a bag of X.509 certificates. + This header attributes contains a bag of X.509 certificates. The set of certificates in this header are unordered and may contain self-signed certificates. The certificate bag can contain certificates which are completely extraneous to the message. (An example of this would be to carry a certificate with a key agreement key usage in a signed message.) As the certificates are unordered, the party evaluating the signature will need to do the necessary path building. Certificates needed for any particular chain to be built may be absent from the bag. - As this header element does not provide any trust, the header parameter can be in either a protected or unprotected header bag. + As this header element does not provide any trust, the header attribute can be in either a protected or unprotected header attribute. - This header parameter allows for a single or a bag of X.509 certificates to be carried in the message. + This header attribute allows for a single or a bag of X.509 certificates to be carried in the message. If a single certificate is conveyed, it is placed in a CBOR bstr. @@ -186,13 +149,14 @@ - This header parameter contains an ordered array of X.509 certificates. + This header attribute contains an ordered array of X.509 certificates. The certificates are to be ordered starting with the certificate containing the end-entity key followed by the certificate which signed it and so on. There is no requirement for the entire chain to be present in the element if there is reason to believe that the relying party will already have it. + This means that the relying party is still required to do path building, but that a candidate path is proposed in this attribute. - As this header element does not provide any trust, the header parameter can be in either a protected or unprotected header bag. + As this header element does not provide any trust, the header attribute can be in either a protected or unprotected header attribute. - This header parameter allows for a single or a bag of X.509 certificates to be carried in the message. + This header attribute allows for a single or a chain of X.509 certificates to be carried in the message. If a single certificate is conveyed, it is placed in a CBOR bstr. @@ -205,29 +169,29 @@ - This header parameter provides the ability to identify an X.509 certificate by a hash value. - The parameter is an array of two elements. - The first element is an algorithm identifier which is a signed integer or a string containing the hash algorithm identifier. + This header attribute provides the ability to identify an X.509 certificate by a hash value. + The attribute is an array of two elements. + The first element is an algorithm identifier which is an integer or a string containing the hash algorithm identifier. The second element is a binary string containing the hash value. - As this header element does not provide any trust, the header parameter can be in either a protected or unprotected header bag. + As this header element does not provide any trust, the header attribute can be in either a protected or unprotected header attribute. - For interoperability, applications which use this header parameter MUST support the hash algorithm 'sha256', but can use other hash algorithms. + For interoperability, applications which use this header attribute MUST support the hash algorithm 'sha256', but can use other hash algorithms. - This header parameter provides the ability to identify an X.509 certificate by a URL. + This header attribute provides the ability to identify an X.509 certificate by a URL. The referenced resource can be any of the following media types: application/pkix-cert application/pkcs7-mime; smime-type="certs-only" - application/x-pem-file Should we support a PEM type? I cannot find a registered media type for one + application/pem-certificate-chain - As this header element implies a trust relationship, the header parameter MUST be in the protected header bag. + As this header attribute implies a trust relationship, the attribute MUST be in the protected attributes. The URL provided MUST provide integrity protection and server authentication. - For example, an HTTP or CoAP GET request to retrieve a certificate MUST use TLS or DTLS. + For example, an HTTP or CoAP GET request to retrieve a certificate MUST use TLS or DTLS . If the certificate does not chain to an existing trust anchor, the certificate MUST NOT be trusted unless the server is configured as trusted to provide new trust anchors. This will normally be the situation when self-signed certificates are used. @@ -235,7 +199,7 @@ - The header parameters used in the following locations: + The header attributes are used in the following locations: COSE_Signature and COSE_Sign0 objects, in these objects they identify the key that was used for generating signature. @@ -269,60 +233,47 @@ COSE_CertHash = [ hashAlg: (int / tstr), hashValue: bstr ]
- The header parameters defined in the previous section are used to identify the recipient certificates for the ECDH key agreement algorithms. + The header attributes defined in the previous section are used to identify the recipient certificates for the ECDH key agreement algorithms. In this section we define the algorithm specific parameters that are used for identifying or transporting the senders key for static-static key agreement algorithms. + + + These attributes are defined analogously to those in the previous section. + There is no definition for the certificate bag as the same attribute would be used for both the sender and recipient certificates. + + + + This header attribute contains the chain of certificates starting with the sender's key exchange certificate. + The structure is the same as 'x5bag'. + + + This header attribute contains the hash value for the sender's key exchange certificate. + The structure is the same as 'x5t'. + + + This header attribute contains a URL for the sender's key exchange certificate. + The structure and processing are the same as 'x5u'. + + + - NameValueTypeAlgorithmDescription> - static key X.509 thumbprintTBDCOSE_CertHash + NameValueTypeAlgorithmDescription + x5t-senderTBDCOSE_CertHash ECDH-SS+HKDF-256, ECDH-SS+HKDF-512, ECDH-SS+A128KW, ECDH-SS+AES192KW, ECDH-SS+AES256KW Thumbprint for the senders X.509 certificate - static key X.509 URLTBDuri + x5u-senderTBDuri ECDH-SS+HKDF-256, ECDH-SS+HKDF-512, ECDH-SS+A128KW, ECDH-SS+AES192KW, ECDH-SS+AES256KW URL for the senders X.509 certificate - static key X.509 cert chainTBDCOSE_X509 + x5chain-senderTBDCOSE_X509 ECDH-SS+HKDF-256, ECDH-SS+HKDF-512, ECDH-SS+A128KW, ECDH-SS+AES192KW, ECDH-SS+AES256KW static key X.509 certificate chain
-
- - The core COSE document did have a need for a standalone hash algorithm, and thus did not define any. - In this document, two hash algorithms are defined for use with the 'x5t' header parameter. - - -
- - - Define an algorithm identifier for SHA-256. - -
- -
- - This hash function uses the SHA-2 256-bit hash function as in the previous section, however it truncates the result to 64-bits for transmission. - The fact that it is a truncated hash means that there is now a high likelihood that collisions will occur, thus this hash function cannot be used in situations where a unique items is required to be identified. - Luckily for the case of identifying a certificate that is not a requirement, the only requirement is that the number of potential certificates (and thus keys) to be tried is reduced to a small number. - (Hopefully that number is one, but it can not be assumed to be.) - After the set of certificates has been filtered down, the public key in each certificate will need to be tried for the operation in question. - The certificate can be validated either before or after it has been checked as working. - The trade-offs involved are: - - Certificate validation before using the key will imply that more network traffic may be required in order to fetch certificates and do revocation checking. - - Certificate validation after using the key means that bad keys can be used and, if not carefully checked, the result may be used prior to completing the certificate validation. - Using unvalidated keys can expose the device to more timing and oracle attacks as the attacker would be able to see if the key operation succeeded or failed as no network traffic to validate the certificate would ensue. - - - -
-
-
@@ -330,7 +281,6 @@ COSE_CertHash = [ hashAlg: (int / tstr), hashValue: bstr ] IANA is requested to register the new COSE Header items in in the "COSE Header Parameters" registry. -
@@ -339,27 +289,8 @@ COSE_CertHash = [ hashAlg: (int / tstr), hashValue: bstr ] IANA is requested to register the new COSE Header items in in the "COSE Header Algorithm Parameters" registry. - - - -
- -
- - - IANA is requested to register the following algorithms in the "COSE Algorithms" registry. - - Name - Value - Description - Reference - Recommended - SHA-256TBDSHA-2 256-bit Hash[This Document]Yes - SHA-256/64TBDSHA-2 256-bit Hash trucated to 64-bits[This Document]No - -
@@ -383,21 +314,23 @@ COSE_CertHash = [ hashAlg: (int / tstr), hashValue: bstr ] - &RFC5280; + - &RFC5246; + + - &RFC2585; - &EDHOC; - + + + +