Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"keyless" workflow #32

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

"keyless" workflow #32

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 3 additions & 3 deletions draft-birkholz-cose-tsa-tst-header-parameter.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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}}.

Expand All @@ -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}}.

Expand Down
Loading