Update to the Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 26 April 2027.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

This document updates [RFC3161]. It adds a requirement to ensure that the id-ct-TSTInfo content type is used to align with the best practices for signed attributes with CMS signed-data [I-D.ietf-lamps-cms-euf-cma-signeddata]. In addition, cross-protocol attacks are prevented by requiring that the Time Stamp Authority (TSA) dedicate the signature key pair to the time-stamping service.¶

2. Conventions

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.¶

3. Update to Section 4 of RFC 3161

Section 2.1 of [RFC3161] correctly requires that the time-stamping service use a key exclusively for signing time-stamp tokens. It says:¶

  10. to sign each time-stamp token using a key generated exclusively
      for this purpose and have this property of the key indicated on
      the corresponding certificate.

However, in real-world deployments, it has been reported that the same key pair has been used to sign time-stamp tokens of various similar formats, which creates the possibility for cross-protocol attacks.¶

ADD:¶

  7. As stated in Section 2.1, the TSA is REQUIRED to sign each
     time-stamp token using a key generated exclusively for this
     purpose.  The use of the same private key to sign time stamps
     in different formats may introduce the possibility of
     cross-protocol attacks.

4. Update to Section 2.4.2 of RFC 3161

OLD:¶

   eContentType is an object identifier that uniquely specifies the
   content type.  For a time-stamp token it is defined as:

   id-ct-TSTInfo  OBJECT IDENTIFIER ::= { iso(1) member-body(2)
   us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) ct(1) 4}

NEW:¶

   eContentType is an object identifier that uniquely specifies the
   content type.  For a time-stamp token defined in this document,
   eContentType MUST be:

      id-ct-TSTInfo  OBJECT IDENTIFIER ::= { iso(1) member-body(2)
         us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
         ct(1) 4 }

   In addition, the TSA MUST include id-ct-TSTInfo as content-type
   signed attribute in the signedAttrs of the signerInfo [CMS].

Note that [CMS] is updated to reference the most recent specification.¶

5. IANA Considerations

No IANA registry updates are needed.¶

6. Security Considerations

The above addition to the Security Considerations of [RFC3161] is intended to ensure that implementations do not use a signature private key that is used to sign a time-stamp token for any other purpose.¶

7. References

Acknowledgments

Thanks to Tom Tervoort for being the first person to spot the need for improvements in [RFC3161].¶

Authors' Addresses