< draft-ietf-cose-hash-sig-07.txt   draft-ietf-cose-hash-sig-08.txt >
Network Working Group R. Housley Network Working Group R. Housley
Internet-Draft Vigil Security Internet-Draft Vigil Security
Intended status: Standards Track November 03, 2019 Intended status: Standards Track December 05, 2019
Expires: May 6, 2020 Expires: June 7, 2020
Use of the HSS/LMS Hash-based Signature Algorithm with CBOR Object Use of the HSS/LMS Hash-based Signature Algorithm with CBOR Object
Signing and Encryption (COSE) Signing and Encryption (COSE)
draft-ietf-cose-hash-sig-07 draft-ietf-cose-hash-sig-08
Abstract Abstract
This document specifies the conventions for using the Hierarchical This document specifies the conventions for using the Hierarchical
Signature System (HSS) / Leighton-Micali Signature (LMS) hash-based Signature System (HSS) / Leighton-Micali Signature (LMS) hash-based
signature algorithm with the CBOR Object Signing and Encryption signature algorithm with the CBOR Object Signing and Encryption
(COSE) syntax. The HSS/LMS algorithm is one form of hash-based (COSE) syntax. The HSS/LMS algorithm is one form of hash-based
digital signature; it is described in RFC 8554. digital signature; it is described in RFC 8554.
Status of This Memo Status of This Memo
skipping to change at page 1, line 35 skipping to change at page 1, line 35
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 6, 2020. This Internet-Draft will expire on June 7, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 17 skipping to change at page 2, line 17
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. LMS Digital Signature Algorithm Overview . . . . . . . . . . 3 2. LMS Digital Signature Algorithm Overview . . . . . . . . . . 3
2.1. Hierarchical Signature System (HSS) . . . . . . . . . . . 4 2.1. Hierarchical Signature System (HSS) . . . . . . . . . . . 4
2.2. Leighton-Micali Signature (LMS) . . . . . . . . . . . . . 5 2.2. Leighton-Micali Signature (LMS) . . . . . . . . . . . . . 5
2.3. Leighton-Micali One-time Signature Algorithm (LM-OTS) . . 6 2.3. Leighton-Micali One-time Signature Algorithm (LM-OTS) . . 6
3. Hash-based Signature Algorithm Identifiers . . . . . . . . . 7 3. Hash-based Signature Algorithm Identifiers . . . . . . . . . 7
4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
4.1. Implementation Security Considerations . . . . . . . . . 7 5. Operational Considerations . . . . . . . . . . . . . . . . . 9
5. Operational Considerations . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6.1. COSE Algorithms Registry Entry . . . . . . . . . . . . . 9 6.1. COSE Algorithms Registry Entry . . . . . . . . . . . . . 9
6.2. COSE Key Types Registry Entry . . . . . . . . . . . . . . 9 6.2. COSE Key Types Registry Entry . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 6.3. COSE Key Type Parameters Registry Entry . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . . 9 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.2. Informative References . . . . . . . . . . . . . . . . . 10 7.1. Normative References . . . . . . . . . . . . . . . . . . 10
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 11 7.2. Informative References . . . . . . . . . . . . . . . . . 11
A.1. Example COSE Full Message Signature . . . . . . . . . . . 11 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 12
A.2. Example COSE_Sign1 Message . . . . . . . . . . . . . . . 13 A.1. Example COSE Full Message Signature . . . . . . . . . . . 13
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 15 A.2. Example COSE_Sign1 Message . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
This document specifies the conventions for using the Hierarchical This document specifies the conventions for using the Hierarchical
Signature System (HSS) / Leighton-Micali Signature (LMS) hash-based Signature System (HSS) / Leighton-Micali Signature (LMS) hash-based
signature algorithm with with the CBOR Object Signing and Encryption signature algorithm with with the CBOR Object Signing and Encryption
(COSE) [RFC8152] syntax. The LMS system provides a one-time digital (COSE) [RFC8152] syntax. The LMS system provides a one-time digital
signature that is a variant of Merkle Tree Signatures (MTS). The HSS signature that is a variant of Merkle Tree Signatures (MTS). The HSS
is built on top of the LMS system to efficiently scale for a larger is built on top of the LMS system to efficiently scale for a larger
numbers of signatures. The HSS/LMS algorithm is one form of hash- numbers of signatures. The HSS/LMS algorithm is one form of hash-
skipping to change at page 3, line 14 skipping to change at page 3, line 14
1.1. Motivation 1.1. Motivation
Recent advances in cryptanalysis [BH2013] and progress in the Recent advances in cryptanalysis [BH2013] and progress in the
development of quantum computers [NAS2019] pose a threat to widely development of quantum computers [NAS2019] pose a threat to widely
deployed digital signature algorithms. As a result, there is a need deployed digital signature algorithms. As a result, there is a need
to prepare for a day that cryptosystems such as RSA and DSA that to prepare for a day that cryptosystems such as RSA and DSA that
depend on discrete logarithm and factoring cannot be depended upon. depend on discrete logarithm and factoring cannot be depended upon.
If large-scale quantum computers are ever built, these computers will If large-scale quantum computers are ever built, these computers will
be able to break many of the public-key cryptosystems currently in have more than a trivial number of quantum bits (qubits) and they
use. A post-quantum cryptosystem [PQC] is a system that is secure will be able to break many of the public-key cryptosystems currently
against quantum computers that have more than a trivial number of in use. A post-quantum cryptosystem [PQC] is a system that is secure
quantum bits (qubits). It is open to conjecture when it will be against against such large-scale quantum computers. It is open to
feasible to build such computers; however, RSA, DSA, ECDSA, and EdDSA conjecture when it will be feasible to build such computers; however,
are all vulnerable if large-scale quantum computers come to pass. RSA [RFC8017], DSA [DSS], ECDSA [DSS], and EdDSA [RFC8032] are all
vulnerable if large-scale quantum computers come to pass.
Since the HSS/LMS signature algorithm does not depend on the Since the HSS/LMS signature algorithm does not depend on the
difficulty of discrete logarithm or factoring, the HSS/LMS signature difficulty of discrete logarithm or factoring, the HSS/LMS signature
algorithm is considered to be post-quantum secure. The use of HSS/ algorithm is considered to be post-quantum secure. The use of HSS/
LMS hash-based signatures to protect software update distribution, LMS hash-based signatures to protect software update distribution
perhaps using the format that is being specified by the IETF SUIT will allow the deployment of future software that implements new
Working Group, will allow the deployment of software that implements cryptosystems. By deploying HSS/LMS today, authentication and
new cryptosystems. integrity protection of the future software can be provided, even if
advances break current digital signature mechanisms.
1.2. Terminology 1.2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2. LMS Digital Signature Algorithm Overview 2. LMS Digital Signature Algorithm Overview
skipping to change at page 4, line 6 skipping to change at page 4, line 13
The hash-based signature algorithm has three major components: The hash-based signature algorithm has three major components:
o Hierarchical Signature System (HSS) -- see Section 2.1; o Hierarchical Signature System (HSS) -- see Section 2.1;
o Leighton-Micali Signature (LMS) -- see Section 2.2; and o Leighton-Micali Signature (LMS) -- see Section 2.2; and
o Leighton-Micali One-time Signature Algorithm (LM-OTS) -- see o Leighton-Micali One-time Signature Algorithm (LM-OTS) -- see
Section 2.3. Section 2.3.
As implied by the name, the hash-based signature algorithm depends on As implied by the name, the hash-based signature algorithm depends on
a collision-resistant hash function. The the hash-based signature a collision-resistant hash function. The hash-based signature
algorithm specified in [HASHSIG] currently makes use of the SHA-256 algorithm specified in [HASHSIG] currently makes use of the SHA-256
one-way hash function [SHS], but it also establishes an IANA registry one-way hash function [SHS], but it also establishes an IANA registry
to permit the registration of additional one-way hash functions in to permit the registration of additional one-way hash functions in
the future. the future.
2.1. Hierarchical Signature System (HSS) 2.1. Hierarchical Signature System (HSS)
The hash-based signature algorithm specified in [HASHSIG] uses a The hash-based signature algorithm specified in [HASHSIG] uses a
hierarchy of trees. The Hierarchical N-time Signature System (HSS) hierarchy of trees. The Hierarchical N-time Signature System (HSS)
allows subordinate trees to be generated when needed by the signer. allows subordinate trees to be generated when needed by the signer.
skipping to change at page 4, line 35 skipping to change at page 4, line 42
tree signs the actual message. The signature over the public key and tree signs the actual message. The signature over the public key and
the signature over the actual message are LMS signatures as described the signature over the actual message are LMS signatures as described
in Section 2.2. in Section 2.2.
The elements of the HSS signature value for a stand-alone tree (a top The elements of the HSS signature value for a stand-alone tree (a top
tree with no children) can be summarized as: tree with no children) can be summarized as:
u32str(0) || u32str(0) ||
lms_signature /* signature of message */ lms_signature /* signature of message */
where, the notation comes from [HASHSIG].
The elements of the HSS signature value for a tree with Nspk signed The elements of the HSS signature value for a tree with Nspk signed
public keys can be summarized as: public keys can be summarized as:
u32str(Nspk) || u32str(Nspk) ||
signed_public_key[0] || signed_public_key[0] ||
signed_public_key[1] || signed_public_key[1] ||
... ...
signed_public_key[Nspk-2] || signed_public_key[Nspk-2] ||
signed_public_key[Nspk-1] || signed_public_key[Nspk-1] ||
lms_signature /* signature of message */ lms_signature /* signature of message */
where, as defined in Section 3.3 of [HASHSIG], a signed_public_key is where, as defined in Section 3.3 of [HASHSIG], a signed_public_key is
the lms_signature over the public key followed by the public key the lms_signature over the public key followed by the public key
itself. Note that Nspk is the number of levels in the hierarchy of itself. Note that Nspk is the number of levels in the hierarchy of
trees minus 1. trees minus 1.
2.2. Leighton-Micali Signature (LMS) 2.2. Leighton-Micali Signature (LMS)
Each tree in the hash-based signature algorithm specified in Subordinate LMS trees are placed in the the HSS structure discussed
[HASHSIG] uses the Leighton-Micali Signature (LMS) system. LMS in Section 2.1. Each tree in the hash-based signature algorithm
systems have two parameters. The first parameter is the height of specified in [HASHSIG] uses the Leighton-Micali Signature (LMS)
the tree, h, which is the number of levels in the tree minus one. system. LMS systems have two parameters. The first parameter is the
The [HASHSIG] includes support for five values of this parameter: height of the tree, h, which is the number of levels in the tree
h=5; h=10; h=15; h=20; and h=25. Note that there are 2^h leaves in minus one. The [HASHSIG] includes support for five values of this
the tree. The second parameter is the number of bytes output by the parameter: h=5; h=10; h=15; h=20; and h=25. Note that there are 2^h
hash function, m, which is the amount of data associated with each leaves in the tree. The second parameter is the number of bytes
node in the tree. This specification supports only SHA-256, with output by the hash function, m, which is the amount of data
m=32. An IANA registry is defined so that other hash functions could associated with each node in the tree. The [HASHSIG] specification
be used in the future. supports only SHA-256, with m=32. An IANA registry is defined so
that other hash functions could be used in the future.
The [HASHSIG] specification supports five tree sizes: The [HASHSIG] specification supports five tree sizes:
LMS_SHA256_M32_H5; LMS_SHA256_M32_H5;
LMS_SHA256_M32_H10; LMS_SHA256_M32_H10;
LMS_SHA256_M32_H15; LMS_SHA256_M32_H15;
LMS_SHA256_M32_H20; and LMS_SHA256_M32_H20; and
LMS_SHA256_M32_H25. LMS_SHA256_M32_H25.
The [HASHSIG] specification establishes an IANA registry to permit The [HASHSIG] specification establishes an IANA registry to permit
the registration of additional hash functions and additional tree the registration of additional hash functions and additional tree
sizes in the future. sizes in the future.
The [HASHSIG] specification defines the value I as the private key The [HASHSIG] specification defines the value I as the private key
identifier, and the same I value is used for all computations with identifier, and the same I value is used for all computations with
the same LMS tree. In addition, the [HASHSIG] specification defines the same LMS tree. The value I is also available in the public key.
the value T[i] as the m-byte string associated with the ith node in In addition, the [HASHSIG] specification defines the value T[i] as
the LMS tree, where and the nodes are indexed from 1 to 2^(h+1)-1. the m-byte string associated with the ith node in the LMS tree, where
Thus, T[1] is the m-byte string associated with the root of the LMS and the nodes are indexed from 1 to 2^(h+1)-1. Thus, T[1] is the
tree. m-byte string associated with the root of the LMS tree.
The LMS public key can be summarized as: The LMS public key can be summarized as:
u32str(lms_algorithm_type) || u32str(otstype) || I || T[1] u32str(lms_algorithm_type) || u32str(otstype) || I || T[1]
As specified in [HASHSIG], the LMS signature consists of four As specified in [HASHSIG], the LMS signature consists of four
elements: the number of the leaf associated with the LM-OTS elements: the number of the leaf associated with the LM-OTS
signature, an LM-OTS signature as described in Section 2.3, a signature, an LM-OTS signature as described in Section 2.3, a
typecode indicating the particular LMS algorithm, and an array of typecode indicating the particular LMS algorithm, and an array of
values that is associated with the path through the tree from the values that is associated with the path through the tree from the
skipping to change at page 6, line 21 skipping to change at page 6, line 35
u32str(type) || u32str(type) ||
path[0] || path[1] || ... || path[h-1] path[0] || path[1] || ... || path[h-1]
2.3. Leighton-Micali One-time Signature Algorithm (LM-OTS) 2.3. Leighton-Micali One-time Signature Algorithm (LM-OTS)
The hash-based signature algorithm depends on a one-time signature The hash-based signature algorithm depends on a one-time signature
method. This specification makes use of the Leighton-Micali One-time method. This specification makes use of the Leighton-Micali One-time
Signature Algorithm (LM-OTS) [HASHSIG]. An LM-OTS has five Signature Algorithm (LM-OTS) [HASHSIG]. An LM-OTS has five
parameters: parameters:
n - The number of bytes output by the hash function. This n - The number of bytes output by the hash function. For
specification supports only SHA-256 [SHS], with n=32. SHA-256 [SHS], n=32.
H - A preimage-resistant hash function that accepts byte strings H - A preimage-resistant hash function that accepts byte strings
of any length, and returns an n-byte string. This of any length, and returns an n-byte string.
specification supports only SHA-256 [SHS].
w - The width in bits of the Winternitz coefficients. [HASHSIG] w - The width in bits of the Winternitz coefficients. [HASHSIG]
supports four values for this parameter: w=1; w=2; w=4; and supports four values for this parameter: w=1; w=2; w=4; and
w=8. w=8.
p - The number of n-byte string elements that make up the LM-OTS p - The number of n-byte string elements that make up the LM-OTS
signature. signature.
ls - The number of left-shift bits used in the checksum function, ls - The number of left-shift bits used in the checksum function,
which is defined in Section 4.5 of [HASHSIG]. which is defined in Section 4.5 of [HASHSIG].
skipping to change at page 7, line 10 skipping to change at page 7, line 21
The [HASHSIG] specification establishes an IANA registry to permit The [HASHSIG] specification establishes an IANA registry to permit
the registration of additional hash functions and additional the registration of additional hash functions and additional
parameter sets in the future. parameter sets in the future.
Signing involves the generation of C, which is an n-byte random Signing involves the generation of C, which is an n-byte random
value. value.
The LM-OTS signature value can be summarized as the identifier of the The LM-OTS signature value can be summarized as the identifier of the
LM-OTS variant, the random value, and a sequence of hash values (y[0] LM-OTS variant, the random value, and a sequence of hash values (y[0]
through y[p-1]) that correspond to the elements of the public key as through y[p-1]) as described in Section 4.5 of [HASHSIG]:
described in Section 4.5 of [HASHSIG]:
u32str(otstype) || C || y[0] || ... || y[p-1] u32str(otstype) || C || y[0] || ... || y[p-1]
3. Hash-based Signature Algorithm Identifiers 3. Hash-based Signature Algorithm Identifiers
The CBOR Object Signing and Encryption (COSE) [RFC8152] supports two The CBOR Object Signing and Encryption (COSE) [RFC8152] supports two
signature algorithm schemes. This specification makes use of the signature algorithm schemes. This specification makes use of the
signature with appendix scheme for hash-based signatures. signature with appendix scheme for hash-based signatures.
The signature value is a large byte string as described in Section 2. The signature value is a large byte string as described in Section 2.
The byte string is designed for easy parsing. The HSS, LMS, and The byte string is designed for easy parsing. The HSS, LMS, and
LMOTS components of the signature value format include counters and LMOTS components of the signature value format include counters and
type codes that indirectly provide all of the information that is type codes that indirectly provide all of the information that is
needed to parse the byte string during signature validation. needed to parse the byte string during signature validation.
When using a COSE key for this algorithm, the following checks are When using a COSE key for this algorithm, the following checks are
made: made:
o The 'kty' field MUST be present, and it MUST be 'HSS-LMS'. o The 'kty' field MUST be 'HSS-LMS'.
o If the 'alg' field is present, and it MUST be 'HSS-LMS'. o If the 'alg' field is present, it MUST be 'HSS-LMS'.
o If the 'key_ops' field is present, it MUST include 'sign' when o If the 'key_ops' field is present, it MUST include 'sign' when
creating a hash-based signature. creating a hash-based signature.
o If the 'key_ops' field is present, it MUST include 'verify' o If the 'key_ops' field is present, it MUST include 'verify'
when verifying a hash-based signature. when verifying a hash-based signature.
o If the 'kid' field is present, it MAY be used to identify the o If the 'kid' field is present, it MAY be used to identify the
top of the HSS tree. In [HASHSIG], this identifier is called top of the HSS tree. In [HASHSIG], this identifier is called
'I', and it is the 16-byte identifier of the LMS public key 'I', and it is the 16-byte identifier of the LMS public key
for the tree. for the tree.
4. Security Considerations 4. Security Considerations
4.1. Implementation Security Considerations The Security considerations from [RFC8152] and [HASHSIG] are relevant
to implementations of this specification.
There are a number of security considerations that need to be taken
into account by implementers of this specification.
Implementations MUST protect the private keys. Compromise of the Implementations MUST protect the private keys. Compromise of the
private keys may result in the ability to forge signatures. Along private keys may result in the ability to forge signatures. Along
with the private key, the implementation MUST keep track of which with the private key, the implementation MUST keep track of which
leaf nodes in the tree have been used. Loss of integrity of this leaf nodes in the tree have been used. Loss of integrity of this
tracking data can cause a one-time key to be used more than once. As tracking data can cause a one-time key to be used more than once. As
a result, when a private key and the tracking data are stored on non- a result, when a private key and the tracking data are stored on non-
volatile media or stored in a virtual machine environment, failed volatile media or stored in a virtual machine environment, failed
writes, virtual machine snapshotting or cloning, and other writes, virtual machine snapshotting or cloning, and other
operational concerns must be considered to ensure confidentiality and operational concerns must be considered to ensure confidentiality and
skipping to change at page 9, line 13 skipping to change at page 9, line 40
trees. trees.
6. IANA Considerations 6. IANA Considerations
IANA is requested to add entries for hash-based signatures in the IANA is requested to add entries for hash-based signatures in the
"COSE Algorithms" registry and hash-based public keys in the "COSE "COSE Algorithms" registry and hash-based public keys in the "COSE
Key Types" registry. Key Types" registry.
6.1. COSE Algorithms Registry Entry 6.1. COSE Algorithms Registry Entry
The new entry in the "COSE Algorithms" registry has the following The new entry in the "COSE Algorithms" registry [IANA] has the
columns: following columns:
Name: HSS-LMS Name: HSS-LMS
Value: TBD (Value between -256 and 255 to be assigned by IANA) Value: TBD1 (Value between -256 and 255 to be assigned by IANA,
with a preferrence for -46)
Description: HSS/LMS hash-based digital signature Description: HSS/LMS hash-based digital signature
Reference: This document (Number to be assigned by RFC Editor) Reference: This document (Number to be assigned by RFC Editor)
Recommended: Yes Recommended: Yes
6.2. COSE Key Types Registry Entry 6.2. COSE Key Types Registry Entry
The new entry in the "COSE Key Types" registry has the following The new entry in the "COSE Key Types" registry [IANA] has the
columns: following columns:
Name: HSS-LMS Name: HSS-LMS
Value: TBD (Value to be assigned by IANA) Value: TBD2 (Value to be assigned by IANA)
Description: Public key for HSS/LMS hash-based digital signature
Reference: This document (Number to be assigned by RFC Editor)
6.3. COSE Key Type Parameters Registry Entry
The new entry in the "COSE Key Type Parameters" registry [IANA] has
the following columns:
Key Type: TBD2 (Value to be assigned above by IANA)
Name: pub
Label: TBD3 (Value to be assigned by IANA)
CBOR Type: bstr
Description: Public key for HSS/LMS hash-based digital signature Description: Public key for HSS/LMS hash-based digital signature
Reference: This document (Number to be assigned by RFC Editor) Reference: This document (Number to be assigned by RFC Editor)
7. References 7. References
7.1. Normative References 7.1. Normative References
[HASHSIG] McGrew, D., Curcio, M., and S. Fluhrer, "Leighton-Micali [HASHSIG] McGrew, D., Curcio, M., and S. Fluhrer, "Leighton-Micali
skipping to change at page 10, line 23 skipping to change at page 11, line 28
[SHS] National Institute of Standards and Technology (NIST), [SHS] National Institute of Standards and Technology (NIST),
"Secure Hash Standard", FIPS Publication 180-3, 2008. "Secure Hash Standard", FIPS Publication 180-3, 2008.
7.2. Informative References 7.2. Informative References
[BH2013] Ptacek, T., Ritter, T., Samuel, J., and A. Stamos, "The [BH2013] Ptacek, T., Ritter, T., Samuel, J., and A. Stamos, "The
Factoring Dead: Preparing for the Cryptopocalypse", August Factoring Dead: Preparing for the Cryptopocalypse", August
2013, <https://media.blackhat.com/us-13/us-13-Stamos-The- 2013, <https://media.blackhat.com/us-13/us-13-Stamos-The-
Factoring-Dead.pdf>. Factoring-Dead.pdf>.
[DSS] National Institute of Standards and Technology (NIST),
"Digital Signature Standard (DSS)", FIPS
Publication 186-6, 2013.
[IANA] "IANA Registry for CBOR Object Signing and Encryption
(COSE)", n.d.,
<https://www.iana.org/assignments/cose/cose.xhtml>.
[LM] Leighton, F. and S. Micali, "Large provably fast and [LM] Leighton, F. and S. Micali, "Large provably fast and
secure digital signature schemes from secure hash secure digital signature schemes from secure hash
functions", U.S. Patent 5,432,852, July 1995. functions", U.S. Patent 5,432,852, July 1995.
[M1979] Merkle, R., "Secrecy, Authentication, and Public Key [M1979] Merkle, R., "Secrecy, Authentication, and Public Key
Systems", Stanford University Information Systems Systems", Stanford University Information Systems
Laboratory Technical Report 1979-1, 1979. Laboratory Technical Report 1979-1, 1979.
[M1987] Merkle, R., "A Digital Signature Based on a Conventional [M1987] Merkle, R., "A Digital Signature Based on a Conventional
Encryption Function", Lecture Notes in Computer Encryption Function", Lecture Notes in Computer
skipping to change at page 11, line 16 skipping to change at page 12, line 25
"Randomness Requirements for Security", BCP 106, RFC 4086, "Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005, DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/info/rfc4086>. <https://www.rfc-editor.org/info/rfc4086>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>. <https://www.rfc-editor.org/info/rfc5280>.
[RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch,
"PKCS #1: RSA Cryptography Specifications Version 2.2",
RFC 8017, DOI 10.17487/RFC8017, November 2016,
<https://www.rfc-editor.org/info/rfc8017>.
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032,
DOI 10.17487/RFC8032, January 2017,
<https://www.rfc-editor.org/info/rfc8032>.
[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
Definition Language (CDDL): A Notational Convention to
Express Concise Binary Object Representation (CBOR) and
JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
June 2019, <https://www.rfc-editor.org/info/rfc8610>.
Appendix A. Examples Appendix A. Examples
This appendix provides a non-normative example of a COSE full message This appendix provides a non-normative example of a COSE full message
signature and an example of a COSE_Sign1 message. This section signature and an example of a COSE_Sign1 message. This section is
follows the formatting used in [RFC8152]. formatted according to the extended CBOR diagnostic format defined by
[RFC8610].
The programs that were used to generate the examples can be found at The programs that were used to generate the examples can be found at
https://github.com/cose-wg/Examples. https://github.com/cose-wg/Examples.
A.1. Example COSE Full Message Signature A.1. Example COSE Full Message Signature
This section provides an example of a COSE full message signature. This section provides an example of a COSE full message signature.
Size of binary file is 2560 bytes. Size of binary file is 2560 bytes.
{{{ RFC Editor: This example assumes that -46 will be assigned for
the HSS-LMS algorithm. If another value is assigned, then the
example needs to be regenerated. }}}
98( 98(
[ [
/ protected / h'a10300' / { / protected / h'a10300' / {
\ content type \ 3:0 \ content type \ 3:0
} / , } / ,
/ unprotected / {}, / unprotected / {},
/ payload / 'This is the content.', / payload / 'This is the content.',
/ signatures / [ / signatures / [
[ [
/ protected / h'a101382d' / { / protected / h'a101382d' / {
skipping to change at page 13, line 35 skipping to change at page 15, line 19
] ]
] ]
) )
A.2. Example COSE_Sign1 Message A.2. Example COSE_Sign1 Message
This section provides an example of a COSE_Sign1 message. This section provides an example of a COSE_Sign1 message.
Size of binary file is 2552 bytes. Size of binary file is 2552 bytes.
{{{ RFC Editor: This example assumes that -46 will be assigned for
the HSS-LMS algorithm. If another value is assigned, then the
example needs to be regenerated. }}}
18( 18(
[ [
/ protected / h'a101382d' / { / protected / h'a101382d' / {
\ alg \ 1:-46 \ HSS-LMS \ \ alg \ 1:-46 \ HSS-LMS \
} / , } / ,
/ unprotected / { / unprotected / {
/ kid / 4:'ItsBig' / kid / 4:'ItsBig'
}, },
/ payload / 'This is the content.', / payload / 'This is the content.',
/ signature / h'00000000000000000000000391291de76ce6e24d1e2a9b60 / signature / h'00000000000000000000000391291de76ce6e24d1e2a9b60
skipping to change at page 15, line 28 skipping to change at page 17, line 16
96cef93c6a552456bf96e9d075e383bb7543c675842bafbfc7cdb88483b3276c29d4 96cef93c6a552456bf96e9d075e383bb7543c675842bafbfc7cdb88483b3276c29d4
f0a341c2d406e40d4653b7e4d045851acf6a0a0ea9c710b805cced4635ee8c107362 f0a341c2d406e40d4653b7e4d045851acf6a0a0ea9c710b805cced4635ee8c107362
f0fc8d80c14d0ac49c516703d26d14752f34c1c0d2c4247581c18c2cf4de48e9ce94 f0fc8d80c14d0ac49c516703d26d14752f34c1c0d2c4247581c18c2cf4de48e9ce94
9be7c888e9caebe4a415e291fd107d21dc1f084b1158208249f28f4f7c7e931ba7b3 9be7c888e9caebe4a415e291fd107d21dc1f084b1158208249f28f4f7c7e931ba7b3
bd0d824a4570' bd0d824a4570'
] ]
) )
Appendix B. Acknowledgements Appendix B. Acknowledgements
Many thanks to Roman Danyliw, Scott Fluhrer, Laurence Lundblade, John Many thanks to Roman Danyliw, Elwyn Davies, Scott Fluhrer, Ben Kaduk,
Mattsson, Jim Schaad, and Tony Putman for their valuable review and Laurence Lundblade, John Mattsson, Jim Schaad, and Tony Putman for
insights. In addition, an extra special thank you to Jim Schaad for their valuable review and insights. In addition, an extra special
generating the examples in Appendix A. thank you to Jim Schaad for generating the examples in Appendix A.
Author's Address Author's Address
Russ Housley Russ Housley
Vigil Security, LLC Vigil Security, LLC
516 Dranesville Road 516 Dranesville Road
Herndon, VA 20170 Herndon, VA 20170
US US
Email: housley@vigilsec.com Email: housley@vigilsec.com
 End of changes. 27 change blocks. 
64 lines changed or deleted 122 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/