From cd295c13e18b1fb2c95230f0083df855273c03e9 Mon Sep 17 00:00:00 2001 From: Thomas Fossati Date: Wed, 18 Sep 2024 11:57:28 +0200 Subject: [PATCH 1/4] keyless workflow --- draft-birkholz-cose-tsa-tst-header-parameter.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/draft-birkholz-cose-tsa-tst-header-parameter.md b/draft-birkholz-cose-tsa-tst-header-parameter.md index 4034c95..7535de9 100644 --- a/draft-birkholz-cose-tsa-tst-header-parameter.md +++ b/draft-birkholz-cose-tsa-tst-header-parameter.md @@ -60,7 +60,7 @@ RFC 3161 {{-TSA}} provides a method to timestamp a message digest to prove that This document defines two new CBOR Object Signing and Encryption (COSE) {{-COSE}} header parameters that carry the TimestampToken (TST) output of RFC 3161, thus allowing existing and widely deployed trust infrastructure to be used with COSE structures used for signing (`COSE_Sign` and `COSE_Sign1`). -## Use Cases +## Use Cases This section discusses two use cases, each representing one of the two modes of use defined in {{modes}}. @@ -76,10 +76,10 @@ This usage scenario motivates the "Timestamp then COSE" mode defined in {{sec-ti A second use case is the notarization of a signed document by registering it at a Transparency Service. This is common for accountability and auditability of issued documents. Once a document is registered at a Transparency Service's append-only log, its log entry cannot be changed. -In certain cases, the registration policy of a Transparency Service may add a trustworthy timestamp to the signed document. +In certain cases, such as when a short-lived certificate is used for the signature, the registration policy of a Transparency Service may add a trustworthy timestamp to the signed document. This is done to lock the signature to a specific point in time. To achieve this, the Transparency Service acquires a TST from a TSA, bundles it alongside the signed document, and then registers it. -A relying party that wants to ascertain the authenticity of the document after the signing key has been compromised, can do so by making sure that no revocation information has been made public before the time asserted in the TST. +A relying party that wants to ascertain the authenticity of the document after the signing key has expired (or has been compromised), can do so by making sure that no revocation information has been made public before the time asserted in the TST. This usage scenario motivates the "COSE then Timestamp" mode described in {{sec-cose-then-timestamp}}. From 4f7a0d957f9c32c5fbf498e428e3de152b278ebd Mon Sep 17 00:00:00 2001 From: Thomas Fossati Date: Tue, 7 Jan 2025 14:40:50 +0100 Subject: [PATCH 2/4] fix abstract Signed-off-by: Thomas Fossati --- draft-birkholz-cose-tsa-tst-header-parameter.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-birkholz-cose-tsa-tst-header-parameter.md b/draft-birkholz-cose-tsa-tst-header-parameter.md index 4034c95..23480b1 100644 --- a/draft-birkholz-cose-tsa-tst-header-parameter.md +++ b/draft-birkholz-cose-tsa-tst-header-parameter.md @@ -49,7 +49,7 @@ entity: --- abstract -This document defines a CBOR Signing And Encrypted (COSE) header parameter for incorporating RFC 3161-based timestamping into COSE message structures (`COSE_Sign` and `COSE_Sign1`). +This document defines two CBOR Signing And Encrypted (COSE) header parameters for incorporating RFC 3161-based timestamping into COSE message structures (`COSE_Sign` and `COSE_Sign1`). This enables the use of established RFC 3161 timestamping infrastructure to prove the creation time of a message. --- middle From fc780ca58f9c44a2ecb9c4d1976d9c5577967b47 Mon Sep 17 00:00:00 2001 From: Thomas Fossati Date: Wed, 8 Jan 2025 09:31:42 +0100 Subject: [PATCH 3/4] =?UTF-8?q?move=20message=20imprint=20requirement=20fr?= =?UTF-8?q?om=20=C2=A72.1=20to=20=C2=A73.1?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: Thomas Fossati --- draft-birkholz-cose-tsa-tst-header-parameter.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/draft-birkholz-cose-tsa-tst-header-parameter.md b/draft-birkholz-cose-tsa-tst-header-parameter.md index 4034c95..f1db0a3 100644 --- a/draft-birkholz-cose-tsa-tst-header-parameter.md +++ b/draft-birkholz-cose-tsa-tst-header-parameter.md @@ -106,8 +106,6 @@ A signed COSE message is then built as follows: * The obtained timestamp token is added to the protected headers, * The original datum becomes the payload of the signed COSE message. -The message imprint sent to the TSA ({{Section 2.4 of -TSA}}) MUST be the hash of the payload field of the COSE signed object. - ~~~ aasvg {::include ascii-art/ttc-alt.ascii-art} ~~~ @@ -140,6 +138,8 @@ The `3161-ttc` COSE _protected_ header parameter MUST be used for the mode descr The `3161-ttc` protected header parameter contains a DER-encoded RFC3161 TimeStampToken wrapped in a CBOR byte string (Major type 2). +The MessageImprint sent to the TSA ({{Section 2.4 of -TSA}}) MUST be the hash of the payload field of the COSE signed object. + To minimize dependencies, the hash algorithm used for signing the COSE message SHOULD be the same as the algorithm used in the RFC3161 MessageImprint. ## `3161-ctt` {#sec-tst-hdr-ctt} From e57dac27b3e7e91953379783b8b680cbebc1490a Mon Sep 17 00:00:00 2001 From: Thomas Fossati Date: Wed, 8 Jan 2025 12:45:41 +0100 Subject: [PATCH 4/4] Use MessageImprint always Signed-off-by: Thomas Fossati --- ascii-art/ctt-alt.ascii-art | 2 +- ascii-art/ttc-alt.ascii-art | 2 +- draft-birkholz-cose-tsa-tst-header-parameter.md | 10 +++++----- 3 files changed, 7 insertions(+), 7 deletions(-) diff --git a/ascii-art/ctt-alt.ascii-art b/ascii-art/ctt-alt.ascii-art index 81b7163..c53259d 100644 --- a/ascii-art/ctt-alt.ascii-art +++ b/ascii-art/ctt-alt.ascii-art @@ -8,7 +8,7 @@ | +---------------+------------' | | | | | | | | .+. | | v .---------. | | | L | Clock | -| .---------. .----. | message | | | '+' | +| .---------. .----. | Message | | | '+' | | | Sign1 +->+ hash +->+ Imprint +-------->| | | | '-+-------' '----' '---------' | | v | | | .-------. | | .---------. | diff --git a/ascii-art/ttc-alt.ascii-art b/ascii-art/ttc-alt.ascii-art index 38f48db..b821427 100644 --- a/ascii-art/ttc-alt.ascii-art +++ b/ascii-art/ttc-alt.ascii-art @@ -5,7 +5,7 @@ | / private-key / | nonce +-------->+ / private-key / | | '-+-----------' '-------' | | '------+------' | | | .---------. | | | | -| | .-------. .----. | message | | | | | +| | .-------. .----. | Message | | | | | | | + datum +->+ hash +->+ Imprint +------->+ .+. | | | '-+-----' '----' '---------' | | | L | Clock | | | | | | '+' | diff --git a/draft-birkholz-cose-tsa-tst-header-parameter.md b/draft-birkholz-cose-tsa-tst-header-parameter.md index f1db0a3..71d9049 100644 --- a/draft-birkholz-cose-tsa-tst-header-parameter.md +++ b/draft-birkholz-cose-tsa-tst-header-parameter.md @@ -146,9 +146,9 @@ To minimize dependencies, the hash algorithm used for signing the COSE message S The `3161-ctt` COSE _unprotected_ header parameter MUST be used for the mode described in {{sec-cose-then-timestamp}}. -The message imprint sent in the request to the TSA MUST be either: +The MessageImprint sent in the request to the TSA MUST be: -* the hash of the signature field of the `COSE_Sign1` message. +* the hash of the signature field of the `COSE_Sign1` message, or * the hash of the signatures field of the `COSE_Sign` message. In either case, to minimize dependencies, the hash algorithm SHOULD be the same as the algorithm used for signing the COSE message. @@ -160,10 +160,10 @@ The `3161-ctt` unprotected header parameter contains a DER-encoded RFC3161 TimeS RFC 3161 timestamp tokens use CMS as signature envelope format. {{-CMS}} provides the details about signature verification, and {{-TSA}} provides the details specific to timestamp token validation. -The payload of the signed timestamp token is the TSTInfo structure defined in {{-TSA}}, which contains the message imprint that was sent to the TSA. -The hash algorithm is contained in the message imprint structure, together with the hash itself. +The payload of the signed timestamp token is the TSTInfo structure defined in {{-TSA}}, which contains the MessageImprint that was sent to the TSA. +The hash algorithm is contained in the MessageImprint structure, together with the hash itself. -As part of the signature verification, the receiver MUST make sure that the message imprint in the embedded timestamp token matches a hash of either the payload, signature, or signature fields, depending on the mode of use and type of COSE structure. +As part of the signature verification, the receiver MUST make sure that the MessageImprint in the embedded timestamp token matches a hash of either the payload, signature, or signature fields, depending on the mode of use and type of COSE structure. {{Appendix B of -TSA}} provides an example that illustrates how timestamp tokens can be used to verify signatures of a timestamped message when utilizing X.509 certificates.