From 6ec865b0fc6d4335f45ce05c19c07c0fb248d503 Mon Sep 17 00:00:00 2001 From: Henk Birkholz Date: Wed, 28 Aug 2024 14:30:17 +0200 Subject: [PATCH 01/17] first attempt at adding usage scenarios --- ...-birkholz-cose-tsa-tst-header-parameter.md | 29 +++++++++++++++++-- 1 file changed, 27 insertions(+), 2 deletions(-) diff --git a/draft-birkholz-cose-tsa-tst-header-parameter.md b/draft-birkholz-cose-tsa-tst-header-parameter.md index c4f2534..3b147f6 100644 --- a/draft-birkholz-cose-tsa-tst-header-parameter.md +++ b/draft-birkholz-cose-tsa-tst-header-parameter.md @@ -40,6 +40,9 @@ normative: =: RFC9052 -: COSE +informative: + I-D.ietf-scitt-architecture: SCITT + entity: SELF: "RFCthis" @@ -55,13 +58,35 @@ 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). +To motivate the two different modes of use that are specified in this documents, two usage scenarios are illustrated in {{use-one}} and {{use-two}} below. +{{sec-timestamp-then-cose}} and {{sec-cose-then-timestamp}} then define the corresponding modes of use. + +## Usage Scenario 1: A TST Included in Signed PDF Documents {#use-one} + +In support of legal assurances, the quality of a signed PDF document can be improved by including a trustworthy signed timestamp. +In essence, a PDF signer wants to strengthen the assertion that a PDF was not signed before a certain point in time ("the signature cannot be older than"). +To achieve this goal, the PDF signer acquires a TST from a TSA, includes it in the to-be-signed PDF that becomes the COSE payload and then signs it. +Using only its local clock instead, a PDF signer would be able to tamper with its clock and thereby falsify the recentness of the signing procedure. + +This usage scenario motivates the "Timestamp then COSE" mode below. + +## Usage Scenario 2: Registering a Signed Statement at a Transparency Service {#use-two} + +Transparency services as described in {{-SCITT}} notarize COSE-signed statements by registering them in verifiable data structures that constitute append-only logs. +Once a signed statement is registered, it cannot be changed. +In some applications, the registration policy of a transparency service could enforce adding a timestamp to the unprotected header of the COSE-signed statement in order to strengthen the assurance at which point of time the registration occurred ("the registration cannot have happened before"). +To achieve this goal, the transparency service acquires a TST from a TSA, includes it in the unprotected header of the COSE-signed statement and then registers it. +Using only its local clock instead, a transparency service would be able to tamper with its clock an thereby falsify the recentness of the registration procedure. + +This usage scenario motivates the "COSE then Timstamp" mode below. + ## Requirements Notation {::boilerplate bcp14-tagged} -# Modes of use +# Modes of Use -There are two different modes of composing COSE protection and timestamping. +There are two different modes of composing COSE protection and timestamping motivated by the usage scenarios above. ## Timestamp then COSE (TTC) {#sec-timestamp-then-cose} From 2d8cddad54fff5a36c3224a055515e51483b9eb9 Mon Sep 17 00:00:00 2001 From: Henk Birkholz Date: Fri, 30 Aug 2024 10:13:20 +0200 Subject: [PATCH 02/17] Update draft-birkholz-cose-tsa-tst-header-parameter.md --- draft-birkholz-cose-tsa-tst-header-parameter.md | 1 + 1 file changed, 1 insertion(+) diff --git a/draft-birkholz-cose-tsa-tst-header-parameter.md b/draft-birkholz-cose-tsa-tst-header-parameter.md index 3b147f6..70c41a7 100644 --- a/draft-birkholz-cose-tsa-tst-header-parameter.md +++ b/draft-birkholz-cose-tsa-tst-header-parameter.md @@ -59,6 +59,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). To motivate the two different modes of use that are specified in this documents, two usage scenarios are illustrated in {{use-one}} and {{use-two}} below. + {{sec-timestamp-then-cose}} and {{sec-cose-then-timestamp}} then define the corresponding modes of use. ## Usage Scenario 1: A TST Included in Signed PDF Documents {#use-one} From 93fd24637f5612aa707458ff0ea1b2ad56f2fab7 Mon Sep 17 00:00:00 2001 From: Henk Birkholz Date: Fri, 30 Aug 2024 10:24:25 +0200 Subject: [PATCH 03/17] Update draft-birkholz-cose-tsa-tst-header-parameter.md --- 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 70c41a7..c8555c4 100644 --- a/draft-birkholz-cose-tsa-tst-header-parameter.md +++ b/draft-birkholz-cose-tsa-tst-header-parameter.md @@ -64,7 +64,7 @@ To motivate the two different modes of use that are specified in this documents, ## Usage Scenario 1: A TST Included in Signed PDF Documents {#use-one} -In support of legal assurances, the quality of a signed PDF document can be improved by including a trustworthy signed timestamp. +In support of legal assurances, a signed PDF document can be augmented with a trustworthy timestamp. In essence, a PDF signer wants to strengthen the assertion that a PDF was not signed before a certain point in time ("the signature cannot be older than"). To achieve this goal, the PDF signer acquires a TST from a TSA, includes it in the to-be-signed PDF that becomes the COSE payload and then signs it. Using only its local clock instead, a PDF signer would be able to tamper with its clock and thereby falsify the recentness of the signing procedure. From 27e5bad35a81a99da3dfa52f00198206765dc6de Mon Sep 17 00:00:00 2001 From: Henk Birkholz Date: Fri, 30 Aug 2024 10:28:13 +0200 Subject: [PATCH 04/17] Update draft-birkholz-cose-tsa-tst-header-parameter.md --- 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 c8555c4..d9adfb9 100644 --- a/draft-birkholz-cose-tsa-tst-header-parameter.md +++ b/draft-birkholz-cose-tsa-tst-header-parameter.md @@ -62,7 +62,7 @@ To motivate the two different modes of use that are specified in this documents, {{sec-timestamp-then-cose}} and {{sec-cose-then-timestamp}} then define the corresponding modes of use. -## Usage Scenario 1: A TST Included in Signed PDF Documents {#use-one} +## Usage Scenario 1: A TST Included in Signed Documents {#use-one} In support of legal assurances, a signed PDF document can be augmented with a trustworthy timestamp. In essence, a PDF signer wants to strengthen the assertion that a PDF was not signed before a certain point in time ("the signature cannot be older than"). From f57983aed2f8c99237de0449aa083d342c6250f1 Mon Sep 17 00:00:00 2001 From: Henk Birkholz Date: Fri, 30 Aug 2024 10:28:21 +0200 Subject: [PATCH 05/17] Update draft-birkholz-cose-tsa-tst-header-parameter.md --- 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 d9adfb9..fcc483f 100644 --- a/draft-birkholz-cose-tsa-tst-header-parameter.md +++ b/draft-birkholz-cose-tsa-tst-header-parameter.md @@ -64,7 +64,7 @@ To motivate the two different modes of use that are specified in this documents, ## Usage Scenario 1: A TST Included in Signed Documents {#use-one} -In support of legal assurances, a signed PDF document can be augmented with a trustworthy timestamp. +In support of legal assurances, a signed document can be augmented with a trustworthy timestamp. In essence, a PDF signer wants to strengthen the assertion that a PDF was not signed before a certain point in time ("the signature cannot be older than"). To achieve this goal, the PDF signer acquires a TST from a TSA, includes it in the to-be-signed PDF that becomes the COSE payload and then signs it. Using only its local clock instead, a PDF signer would be able to tamper with its clock and thereby falsify the recentness of the signing procedure. From 35bbf7473b682b88182f11ef255cbc80847fbf27 Mon Sep 17 00:00:00 2001 From: Henk Birkholz Date: Fri, 30 Aug 2024 10:28:52 +0200 Subject: [PATCH 06/17] Update draft-birkholz-cose-tsa-tst-header-parameter.md --- 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 fcc483f..6ed4785 100644 --- a/draft-birkholz-cose-tsa-tst-header-parameter.md +++ b/draft-birkholz-cose-tsa-tst-header-parameter.md @@ -65,7 +65,7 @@ To motivate the two different modes of use that are specified in this documents, ## Usage Scenario 1: A TST Included in Signed Documents {#use-one} In support of legal assurances, a signed document can be augmented with a trustworthy timestamp. -In essence, a PDF signer wants to strengthen the assertion that a PDF was not signed before a certain point in time ("the signature cannot be older than"). +In essence, a document signer wants to strengthen the assertion that a certain document existed at a certain date. To achieve this goal, the PDF signer acquires a TST from a TSA, includes it in the to-be-signed PDF that becomes the COSE payload and then signs it. Using only its local clock instead, a PDF signer would be able to tamper with its clock and thereby falsify the recentness of the signing procedure. From 2dd8154f67e0d2bfc610db61f2aec20505ca4416 Mon Sep 17 00:00:00 2001 From: Henk Birkholz Date: Fri, 30 Aug 2024 10:29:08 +0200 Subject: [PATCH 07/17] Update draft-birkholz-cose-tsa-tst-header-parameter.md --- 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 6ed4785..a2cd105 100644 --- a/draft-birkholz-cose-tsa-tst-header-parameter.md +++ b/draft-birkholz-cose-tsa-tst-header-parameter.md @@ -67,7 +67,7 @@ To motivate the two different modes of use that are specified in this documents, In support of legal assurances, a signed document can be augmented with a trustworthy timestamp. In essence, a document signer wants to strengthen the assertion that a certain document existed at a certain date. To achieve this goal, the PDF signer acquires a TST from a TSA, includes it in the to-be-signed PDF that becomes the COSE payload and then signs it. -Using only its local clock instead, a PDF signer would be able to tamper with its clock and thereby falsify the recentness of the signing procedure. +Using only its local clock instead, a document signer would be able to tamper with its clock and thereby falsify the recentness of the signing procedure. This usage scenario motivates the "Timestamp then COSE" mode below. From c47031191c275e77ac1c3a848b4887bdab028e22 Mon Sep 17 00:00:00 2001 From: Thomas Fossati Date: Fri, 30 Aug 2024 10:30:53 +0200 Subject: [PATCH 08/17] fix typo --- 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 a2cd105..3bdb3cd 100644 --- a/draft-birkholz-cose-tsa-tst-header-parameter.md +++ b/draft-birkholz-cose-tsa-tst-header-parameter.md @@ -79,7 +79,7 @@ In some applications, the registration policy of a transparency service could en To achieve this goal, the transparency service acquires a TST from a TSA, includes it in the unprotected header of the COSE-signed statement and then registers it. Using only its local clock instead, a transparency service would be able to tamper with its clock an thereby falsify the recentness of the registration procedure. -This usage scenario motivates the "COSE then Timstamp" mode below. +This usage scenario motivates the "COSE then Timestamp" mode below. ## Requirements Notation From 5f4ddfd3bb7b71b05de22b6dec3a3ef88887ee7d Mon Sep 17 00:00:00 2001 From: Thomas Fossati Date: Fri, 30 Aug 2024 14:50:29 +0200 Subject: [PATCH 09/17] use cases reorg Signed-off-by: Thomas Fossati --- ...-birkholz-cose-tsa-tst-header-parameter.md | 41 ++++++++++--------- 1 file changed, 21 insertions(+), 20 deletions(-) diff --git a/draft-birkholz-cose-tsa-tst-header-parameter.md b/draft-birkholz-cose-tsa-tst-header-parameter.md index 3bdb3cd..6400075 100644 --- a/draft-birkholz-cose-tsa-tst-header-parameter.md +++ b/draft-birkholz-cose-tsa-tst-header-parameter.md @@ -48,7 +48,8 @@ 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 enables the use of established RFC 3161 timestamping infrastructure to prove the creation time of a message. +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 enables the use of established RFC 3161 timestamping infrastructure to prove the creation time of a message. --- middle @@ -56,38 +57,38 @@ This document defines a CBOR Signing And Encrypted (COSE) header parameter for i RFC 3161 {{-TSA}} provides a method to timestamp a message digest to prove that it was created before a given time. -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). +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`). -To motivate the two different modes of use that are specified in this documents, two usage scenarios are illustrated in {{use-one}} and {{use-two}} below. +## Use Cases -{{sec-timestamp-then-cose}} and {{sec-cose-then-timestamp}} then define the corresponding modes of use. +This section discusses two use cases, each representing one of the two modes of use defined in {{modes}}. -## Usage Scenario 1: A TST Included in Signed Documents {#use-one} +A first use case is a document signed alongside a trustworthy timestamp. +This is a common case in legal contracts. +In such scenario, the document signer wants to reinforce the claim that the document existed on a specific date. +To achieve this, the document signer acquires a fresh TST for the document from a TSA, combines it with the document, and then signs the bundle. +Later on, a relying party consuming the signed bundle can be certain that the document existed _at least_ at the time specified by the TSA. +The relying party does not have to trust the signer's clock, which may have been maliciously altered or simply inaccurate. -In support of legal assurances, a signed document can be augmented with a trustworthy timestamp. -In essence, a document signer wants to strengthen the assertion that a certain document existed at a certain date. -To achieve this goal, the PDF signer acquires a TST from a TSA, includes it in the to-be-signed PDF that becomes the COSE payload and then signs it. -Using only its local clock instead, a document signer would be able to tamper with its clock and thereby falsify the recentness of the signing procedure. +This usage scenario motivates the "Timestamp then COSE" mode defined in {{sec-timestamp-then-cose}}. -This usage scenario motivates the "Timestamp then COSE" mode below. - -## Usage Scenario 2: Registering a Signed Statement at a Transparency Service {#use-two} - -Transparency services as described in {{-SCITT}} notarize COSE-signed statements by registering them in verifiable data structures that constitute append-only logs. +A second use case is the registration of a signed statement at a Transparency Service. +Transparency Services, as described in {{-SCITT}}, notarize COSE-signed statements by registering them in verifiable append-only logs. Once a signed statement is registered, it cannot be changed. -In some applications, the registration policy of a transparency service could enforce adding a timestamp to the unprotected header of the COSE-signed statement in order to strengthen the assurance at which point of time the registration occurred ("the registration cannot have happened before"). -To achieve this goal, the transparency service acquires a TST from a TSA, includes it in the unprotected header of the COSE-signed statement and then registers it. -Using only its local clock instead, a transparency service would be able to tamper with its clock an thereby falsify the recentness of the registration procedure. +In certain cases, the registration policy of a Transparency Service may require adding a timestamp to the unprotected header of the COSE-signed statement. +This is done to enhance confidence in the timing of the registration, ensuring that the registration could not have occurred before a certain point in time. +To achieve this, the Transparency Service acquires a TST from a TSA, includes it in the unprotected header of the COSE-signed statement and then registers it. +Again, a relying party that wants to ascertain the time of registration of a given statement does not have to trust the Transparency Service's clock, which may have been maliciously altered or simply inaccurate. -This usage scenario motivates the "COSE then Timestamp" mode below. +This usage scenario motivates the "COSE then Timestamp" mode described in {{sec-cose-then-timestamp}}. ## Requirements Notation {::boilerplate bcp14-tagged} -# Modes of Use +# Modes of Use {#modes} -There are two different modes of composing COSE protection and timestamping motivated by the usage scenarios above. +There are two different modes of composing COSE protection and timestamping, motivated by the usage scenarios discussed above. ## Timestamp then COSE (TTC) {#sec-timestamp-then-cose} From a5bc18522911b196aed2eb97970698901b89de88 Mon Sep 17 00:00:00 2001 From: Henk Birkholz Date: Mon, 2 Sep 2024 16:55:54 +0200 Subject: [PATCH 10/17] abstracted the use case text for CTT --- draft-birkholz-cose-tsa-tst-header-parameter.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/draft-birkholz-cose-tsa-tst-header-parameter.md b/draft-birkholz-cose-tsa-tst-header-parameter.md index 6400075..8c7fcdd 100644 --- a/draft-birkholz-cose-tsa-tst-header-parameter.md +++ b/draft-birkholz-cose-tsa-tst-header-parameter.md @@ -63,7 +63,7 @@ This document defines two new CBOR Object Signing and Encryption (COSE) {{-COSE} This section discusses two use cases, each representing one of the two modes of use defined in {{modes}}. -A first use case is a document signed alongside a trustworthy timestamp. +A first use case is a digital document signed alongside a trustworthy timestamp. This is a common case in legal contracts. In such scenario, the document signer wants to reinforce the claim that the document existed on a specific date. To achieve this, the document signer acquires a fresh TST for the document from a TSA, combines it with the document, and then signs the bundle. @@ -72,13 +72,13 @@ The relying party does not have to trust the signer's clock, which may have been This usage scenario motivates the "Timestamp then COSE" mode defined in {{sec-timestamp-then-cose}}. -A second use case is the registration of a signed statement at a Transparency Service. -Transparency Services, as described in {{-SCITT}}, notarize COSE-signed statements by registering them in verifiable append-only logs. -Once a signed statement is registered, it cannot be changed. -In certain cases, the registration policy of a Transparency Service may require adding a timestamp to the unprotected header of the COSE-signed statement. +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, it cannot be changed. +In certain cases, the registration policy of a Transparency Service may require adding a trustworthy timestamp to the document at the time of registration. This is done to enhance confidence in the timing of the registration, ensuring that the registration could not have occurred before a certain point in time. -To achieve this, the Transparency Service acquires a TST from a TSA, includes it in the unprotected header of the COSE-signed statement and then registers it. -Again, a relying party that wants to ascertain the time of registration of a given statement does not have to trust the Transparency Service's clock, which may have been maliciously altered or simply inaccurate. +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 time of registration of a given document does not have to trust the Transparency Service's clock, which may have been maliciously altered or can simply be inaccurate. This usage scenario motivates the "COSE then Timestamp" mode described in {{sec-cose-then-timestamp}}. From f808dd839438289621c6d6ad5ed6967274dbc190 Mon Sep 17 00:00:00 2001 From: Henk Birkholz Date: Mon, 2 Sep 2024 16:56:28 +0200 Subject: [PATCH 11/17] removed scitt reference --- draft-birkholz-cose-tsa-tst-header-parameter.md | 3 --- 1 file changed, 3 deletions(-) diff --git a/draft-birkholz-cose-tsa-tst-header-parameter.md b/draft-birkholz-cose-tsa-tst-header-parameter.md index 8c7fcdd..ff50dca 100644 --- a/draft-birkholz-cose-tsa-tst-header-parameter.md +++ b/draft-birkholz-cose-tsa-tst-header-parameter.md @@ -40,9 +40,6 @@ normative: =: RFC9052 -: COSE -informative: - I-D.ietf-scitt-architecture: SCITT - entity: SELF: "RFCthis" From 2eb7db90e4e8a9c795ddd97facfad68bc46fd0c0 Mon Sep 17 00:00:00 2001 From: Henk Birkholz Date: Tue, 3 Sep 2024 08:11:13 +0200 Subject: [PATCH 12/17] more emphasis on document authenticity in use case two --- draft-birkholz-cose-tsa-tst-header-parameter.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/draft-birkholz-cose-tsa-tst-header-parameter.md b/draft-birkholz-cose-tsa-tst-header-parameter.md index ff50dca..b493c0b 100644 --- a/draft-birkholz-cose-tsa-tst-header-parameter.md +++ b/draft-birkholz-cose-tsa-tst-header-parameter.md @@ -71,11 +71,11 @@ 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, it cannot be changed. -In certain cases, the registration policy of a Transparency Service may require adding a trustworthy timestamp to the document at the time of registration. -This is done to enhance confidence in the timing of the registration, ensuring that the registration could not have occurred before a certain 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 time of registration of a given document does not have to trust the Transparency Service's clock, which may have been maliciously altered or can simply be inaccurate. +Once a document is registered at a Transparency Service's append-only log, it's log entry cannot be changed. +In certain cases, the registration policy of a Transparency Service may add a trustworthy timestamp to the document to show that the signature could also be validated at the time of registration. +This is done to enhance confidence in the authenticity of the document at the time of registration, enshrining that a signature was successfully validated. +To achieve this, the Transparency Service acquires a TST from a TSA when its registration policy is met, bundles it alongside the signed document, and then registers it. +A relying party that wants to ascertain the authenticity of a document at a certain time does not have to trust the Transparency Service's clock, which may have been maliciously altered or can simply be inaccurate. This usage scenario motivates the "COSE then Timestamp" mode described in {{sec-cose-then-timestamp}}. From 027ec2a9dadbe435d8412d1b0aa6933ed2622bff Mon Sep 17 00:00:00 2001 From: Henk Birkholz Date: Tue, 10 Sep 2024 12:26:58 +0200 Subject: [PATCH 13/17] Update draft-birkholz-cose-tsa-tst-header-parameter.md Co-authored-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 b493c0b..fd08c06 100644 --- a/draft-birkholz-cose-tsa-tst-header-parameter.md +++ b/draft-birkholz-cose-tsa-tst-header-parameter.md @@ -71,7 +71,7 @@ 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, it's log entry cannot be changed. +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 document to show that the signature could also be validated at the time of registration. This is done to enhance confidence in the authenticity of the document at the time of registration, enshrining that a signature was successfully validated. To achieve this, the Transparency Service acquires a TST from a TSA when its registration policy is met, bundles it alongside the signed document, and then registers it. From c737d7f072068f2634d36f607237579bdb468b19 Mon Sep 17 00:00:00 2001 From: Henk Birkholz Date: Tue, 10 Sep 2024 12:27:31 +0200 Subject: [PATCH 14/17] Update draft-birkholz-cose-tsa-tst-header-parameter.md Co-authored-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 fd08c06..1f54330 100644 --- a/draft-birkholz-cose-tsa-tst-header-parameter.md +++ b/draft-birkholz-cose-tsa-tst-header-parameter.md @@ -72,7 +72,7 @@ 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 document to show that the signature could also be validated at the time of registration. +In certain cases, the registration policy of a Transparency Service may add a trustworthy timestamp to the signed document. This is done to enhance confidence in the authenticity of the document at the time of registration, enshrining that a signature was successfully validated. To achieve this, the Transparency Service acquires a TST from a TSA when its registration policy is met, bundles it alongside the signed document, and then registers it. A relying party that wants to ascertain the authenticity of a document at a certain time does not have to trust the Transparency Service's clock, which may have been maliciously altered or can simply be inaccurate. From e8a53926896b12347d3e49fe55a5d0265bebf0b6 Mon Sep 17 00:00:00 2001 From: Henk Birkholz Date: Tue, 10 Sep 2024 12:41:11 +0200 Subject: [PATCH 15/17] Update draft-birkholz-cose-tsa-tst-header-parameter.md Co-authored-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 1f54330..990ff23 100644 --- a/draft-birkholz-cose-tsa-tst-header-parameter.md +++ b/draft-birkholz-cose-tsa-tst-header-parameter.md @@ -73,7 +73,7 @@ A second use case is the notarization of a signed document by registering it at 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. -This is done to enhance confidence in the authenticity of the document at the time of registration, enshrining that a signature was successfully validated. +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 when its registration policy is met, bundles it alongside the signed document, and then registers it. A relying party that wants to ascertain the authenticity of a document at a certain time does not have to trust the Transparency Service's clock, which may have been maliciously altered or can simply be inaccurate. From 058a90880ae5118118bea1af7093123d5f291209 Mon Sep 17 00:00:00 2001 From: Thomas Fossati Date: Tue, 10 Sep 2024 12:43:50 +0200 Subject: [PATCH 16/17] Update draft-birkholz-cose-tsa-tst-header-parameter.md Co-authored-by: Henk Birkholz --- 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 990ff23..3b2d5ba 100644 --- a/draft-birkholz-cose-tsa-tst-header-parameter.md +++ b/draft-birkholz-cose-tsa-tst-header-parameter.md @@ -74,7 +74,7 @@ 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. 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 when its registration policy is met, bundles it alongside the signed document, and then registers it. +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 a document at a certain time does not have to trust the Transparency Service's clock, which may have been maliciously altered or can simply be inaccurate. This usage scenario motivates the "COSE then Timestamp" mode described in {{sec-cose-then-timestamp}}. From d74bec9b735048ac66c71bdda9d1a3f558229160 Mon Sep 17 00:00:00 2001 From: Henk Birkholz Date: Tue, 10 Sep 2024 12:50:37 +0200 Subject: [PATCH 17/17] Update draft-birkholz-cose-tsa-tst-header-parameter.md Co-authored-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 3b2d5ba..3691fdf 100644 --- a/draft-birkholz-cose-tsa-tst-header-parameter.md +++ b/draft-birkholz-cose-tsa-tst-header-parameter.md @@ -75,7 +75,7 @@ Once a document is registered at a Transparency Service's append-only log, its l In certain cases, 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 a document at a certain time does not have to trust the Transparency Service's clock, which may have been maliciously altered or can simply be inaccurate. +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. This usage scenario motivates the "COSE then Timestamp" mode described in {{sec-cose-then-timestamp}}.