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 25 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. Update to Section 4 of RFC 3161

Section 2.1 of [RFC3161] properly 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 similare 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.

3. Update to Section 2.4.2 of RFC 6211

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

4. IANA Considerations

No IANA registry updates are needed.¶

5. Security Considerations

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

6. References

Acknowledgments

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

Authors' Addresses