1. Introduction

Cette section conserve le texte RFC relatif aux COSE timestamp token header parameters, y compris CTT and TTC modes, TimeStampToken handling, MessageImprint computation, COSE_Sign and COSE_Sign1 examples, IANA registrations et security considerations.

Texte RFC original

1.  Introduction

   RFC 3161 [RFC3161] provides a method for timestamping a message
   digest to prove that it was created before a given time.

   This document defines two new CBOR Object Signing and Encryption
   (COSE) [RFC9052] header parameters that carry the TimeStampToken
   (TST) output [RFC3161], thus allowing existing and widely deployed
   trust infrastructure to be used with COSE structures used for signing
   (COSE_Sign and COSE_Sign1).

1.1.  Use Cases

   This section discusses two use cases, each representing one of the
   two modes of use defined in Section 2.  As the security
   characteristics of the two cases differ, care must be taken when
   choosing the appropriate mode for a given application.  See
   Section 5.1 for a discussion on the security of the implementations.

   The primary use case is that of "long-term signatures", i.e.,
   signatures that can still be verified even after the signing
   certificate has expired.  This can address situations where it is
   important to prevent subsequent denial by the signer or to verify
   signatures made using (very) short-term certificates.  To achieve
   this, the document signer acquires a fresh TST for the document's
   signature from a trusted Time Stamping Authority (TSA) [RFC3161] and
   concatenates it with the document.  Later, when a relying party
   verifies the signed document and its associated TST, they can be
   certain that the document was signed _at least_ at the time specified
   by the TSA and that the signing certificate was valid at the time the
   signature was made.

   This primary usage scenario motivates the "COSE, Then Timestamp" mode
   described in Section 2.1.

   The second use case is new.  It is the notarization of a signed
   document by registering it with a transparency service.  This is
   common practice for ensuring the accountability and auditability of
   issued documents, which are typically referred to as "statements" in
   this context.  It is also common practice to only register the signed
   parts of a statement (the "signed statement" portion) with a
   transparency service, in order to reduce the complexity of
   consistency checks at a later stage and to avoid the need to retrieve
   or reconstruct unsigned parts.  Once the signed parts of a document
   have been registered in the append-only log at a transparency
   service, the log entry cannot be changed.  In order to avoid losing
   the TST during the registration process, the TST must be included in
   the signed statement.  To achieve this, the issuer acquires a TST
   from a TSA, includes it in the to-be-signed part of the statement so
   that the resulting signed statement includes the TST, and then
   registers the signed parts (rendering it a "transparent statement").
   Later on, a relying party consuming the transparent statement
   including the TST can be certain that the statement was signed by the
   issuer _at least_ at the time specified by the TSA.  If the issuer's
   signing key has expired (or has been compromised), the authenticity
   of the statement can be ascertained by ensuring that no revocation
   information was made public before the time asserted by the issuer
   and registered at the transparency service.

   This new usage scenario motivates the "Timestamp, Then COSE" mode
   defined in Section 2.2.

1.2.  Requirements Notation

   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 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.