LAMPS R. Housley Internet-Draft Vigil Security Updates: 6211 (if approved) S. Santesson Intended status: Standards Track IDsec Solutions Expires: 25 April 2027 22 October 2026 Update to the Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP) draft-housley-lamps-rfc3161-update-00 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 25 April 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Housley & Santesson Expires 25 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. Update to Section 4 of RFC 3161 . . . . . . . . . . . . . . . 2 3. Update to Section 2.4.2 of RFC 6211 . . . . . . . . . . . . . 3 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 5. Security Considerations . . . . . . . . . . . . . . . . . . . 3 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 3 6.1. Normative References . . . . . . . . . . . . . . . . . . 3 6.2. Informative References . . . . . . . . . . . . . . . . . 3 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. 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: Housley & Santesson Expires 25 April 2027 [Page 2] Internet-Draft Update to RFC 3161 October 2026 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 6.1. Normative References [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, . 6.2. Informative References Housley & Santesson Expires 25 April 2027 [Page 3] Internet-Draft Update to RFC 3161 October 2026 [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 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 25 April 2027 [Page 4]