Update to the Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)
draft-housley-lamps-rfc3161-update-02
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (candidate for lamps WG) | |
|---|---|---|---|
| Authors | Russ Housley , Stefan Santesson | ||
| Last updated | 2026-10-26 | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | Call For Adoption By WG Issued | |
| Document shepherd | (None) | ||
| IESG | IESG state | I-D Exists | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-housley-lamps-rfc3161-update-02
LAMPS R. Housley
Internet-Draft Vigil Security
Updates: 3161 (if approved) S. Santesson
Intended status: Standards Track IDsec Solutions
Expires: 29 April 2027 26 October 2026
Update to the Internet X.509 Public Key Infrastructure Time-Stamp
Protocol (TSP)
draft-housley-lamps-rfc3161-update-02
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. Finally, the use of id-kp-timeStamping in the TSA
certificate is clarified.
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 29 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
Housley & Santesson Expires 29 April 2027 [Page 1]
Internet-Draft Update to RFC 3161 October 2026
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.3 of RFC 3161 . . . . . . . . . . . . . . 3
5. Update to Section 2.4.2 of RFC 3161 . . . . . . . . . . . . . 4
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
7. Security Considerations . . . . . . . . . . . . . . . . . . . 5
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
8.1. Normative References . . . . . . . . . . . . . . . . . . 5
8.2. Informative References . . . . . . . . . . . . . . . . . 6
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
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.
Finally, the use of id-kp-timeStamping in the TSA certificate is
clarified.
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.
Housley & Santesson Expires 29 April 2027 [Page 2]
Internet-Draft Update to RFC 3161 October 2026
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.3 of RFC 3161
OLD:
The corresponding certificate MUST contain only one instance of
the extended key usage field extension as defined in [RFC2459]
Section 4.2.1.13 with KeyPurposeID having value:
id-kp-timeStamping. This extension MUST be critical.
The following object identifier identifies the KeyPurposeID
having value id-kp-timeStamping.
id-kp-timeStamping OBJECT IDENTIFIER ::= {iso(1)
identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7)
kp (3) timestamping (8)}
NEW:
Housley & Santesson Expires 29 April 2027 [Page 3]
Internet-Draft Update to RFC 3161 October 2026
The corresponding TSA certificate MUST contain one and only one
instance of the extended key usage extension as defined in
Section 4.2.1.12 of [PKIX1]. The extended key usage extension
MUST contain a single KeyPurposeId containing the following
object identifier:
id-kp-timeStamping OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) kp (3) timestamping (8) }
This extended key usage extension MUST be critical.
Certification Authorities (CAs) MUST NOT include the
id-kp-timeStamping KeyPurposeId in certificates issued to
subjects that are not TSAs as specified in this document.
An application MUST reject a time-stamp if the TSA certificate
does not include a critical extended key usage extension with a
single KeyPurposeId of id-kp-timeStamping.
Note that [PKIX1] is updated to reference the most recent
specification.
5. 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:
Housley & Santesson Expires 29 April 2027 [Page 4]
Internet-Draft Update to RFC 3161 October 2026
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].
An application MUST reject a time-stamp if the CMS signed-data
does not include id-ct-TSTInfo in both the eContentType within
the EncapsulatedContentInfo structure and the content-type
signed attribute in the signedAttrs of the signerInfo structure.
Note that [CMS] is updated to reference the most recent
specification.
6. IANA Considerations
No IANA registry updates are needed.
7. 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.
8. References
8.1. Normative References
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, DOI 10.17487/RFC5652, September 2009,
<https://www.rfc-editor.org/rfc/rfc5652>.
[PKIX1] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/rfc/rfc5280>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
Housley & Santesson Expires 29 April 2027 [Page 5]
Internet-Draft Update to RFC 3161 October 2026
[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, <https://www.rfc-editor.org/rfc/rfc3161>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
8.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, <https://datatracker.ietf.org/doc/html/
draft-ietf-lamps-cms-euf-cma-signeddata-03>.
Acknowledgments
Thanks to Tom Tervoort for being the first person to spot the need
for improvements to [RFC3161].
Thanks to Tom Tervoort, Tim Hollebeek, Carl Wallace, and Mike StJohns
for their careful review and insightful suggestions.
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 29 April 2027 [Page 6]