LAMPS R. Housley Internet-Draft Vigil Security Updates: 3161 (if approved) S. Santesson Intended status: Standards Track IDsec Solutions Expires: 26 April 2027 23 October 2026 Update to the Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP) draft-housley-lamps-rfc3161-update-01 Abstract This document updates RFC 3161. 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. 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. 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. Housley & Santesson Expires 26 April 2027 [Page 1] Internet-Draft Update to RFC 3161 October 2026 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Update to Section 4 of RFC 3161 . . . . . . . . . . . . . . . 2 4. Update to Section 2.4.2 of RFC 3161 . . . . . . . . . . . . . 3 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 7.1. Normative References . . . . . . . . . . . . . . . . . . 4 7.2. Informative References . . . . . . . . . . . . . . . . . 4 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 4 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 4 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: Housley & Santesson Expires 26 April 2027 [Page 2] Internet-Draft Update to RFC 3161 October 2026 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. Housley & Santesson Expires 26 April 2027 [Page 3] Internet-Draft Update to RFC 3161 October 2026 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 7.1. Normative References [CMS] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, DOI 10.17487/RFC5652, September 2009, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3161] Adams, C., Cain, P., Pinkas, D., and R. Zuccherato, "Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)", RFC 3161, DOI 10.17487/RFC3161, August 2001, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 7.2. Informative References [I-D.ietf-lamps-cms-euf-cma-signeddata] Van Geest, D. and F. Strenzke, "Best Practices for Signed Attributes in CMS SignedData", Work in Progress, Internet- Draft, draft-ietf-lamps-cms-euf-cma-signeddata-03, 14 September 2026, . Acknowledgments Thanks to Tom Tervoort for being the first person to spot the need for improvements in [RFC3161]. Authors' Addresses Housley & Santesson Expires 26 April 2027 [Page 4] Internet-Draft Update to RFC 3161 October 2026 Russ Housley Vigil Security, LLC Herndon, VA, United States of America Email: housley@vigilsec.com Stefan Santesson IDsec Solutions AB Forskningsbyn Ideon SE-223 70 Lund Sweden Email: sts@aaa-sec.com Housley & Santesson Expires 26 April 2027 [Page 5]