| Internet-Draft | OSC | October 2025 |
| Santesson | Expires 3 May 2026 | [Page] |
Electronic signatures based on multipurpose expiring certificates that may be revoked introduce many challenges when a signed document has to be maintained over time. Solutions include timestamping, storing revocation records and advanced verification procedures. This draft introduces a new type of certificates for a key that is used and bound to just one signing instance. The certificate is created at the time of signing, and the signature key is destroyed after signing is completed. These certificates never expire and are never revoked, which drastically reduce the burden of future signature validation.¶
This note is to be removed before publishing as an RFC.¶
Status information for this document may be found at https://datatracker.ietf.org/doc/draft-santesson-one-signature-certs/.¶
Source for this draft and an issue tracker can be found at https://github.com/Razumain/one-signature-certs.¶
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 3 May 2026.¶
Copyright (c) 2025 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.¶
The landscape of server-based signing services has changed over the last decades. During the past years one type of signature service has gained a lot of traction where the signing key and signing certificate are created for each instance of signing, rather than re-using a static key and certificate over time.¶
Some reasons why this type of signature services has been successful are:¶
The certificate will always have a predictable validity time from the time of signing¶
The time of signing is guaranteed by the certificate issue date¶
The identity information in the certificate can be adapted to the signing context for each instance of signing¶
Revocation of signing certificates is practically non-existent despite many years of operation and millions of signatures.¶
Service providers are not bound to using the signature service where the signer's key and certificate is located, but can choose one signature service it integrates with that holds no pre-stored user keys and certificates.¶
While this type of signature service solves a lot of problems, it still suffers from the complexity caused by expiring signing certificates. One solution to this problem is the Signature Validation Token (SVT) [RFC9321] where future validation can rely on a previous successful validation rather than making a new re-validation based on aging data.¶
This document takes this one step further and allows future re-validation at any time in the future as long as trust in the CA certificate can be established.¶
One signature certificates have the following common characteristics:¶
They never expire¶
They are never revoked¶
They are bound to a specific document content¶
They assert that the corresponding private key was destroyed after signing¶
Traditional certificates that are re-used over time have many legitimate reasons for revocation, such as if the private key is lost or compromised. This can lead to large volumes of revocation data.¶
The fact that the same key is used many times exposes the key for the risk of unauthorized usage or theft. When many objects are signed with the same key, the risk of exposure and the number of affected signed documents upon revocation increases, unless properly timestamped and properly verified.¶
When a signing key is used only once, that risk of exposure is drastically reduced, and it has been shown that most usages of dedicated keys and certificates no longer require revocation.¶
No CA can guarantee that a certificate is correctly issued. What the CA does is to attest that a certain procedure was followed when the certificate was issued, and the certificate itself is an attestation that this process was followed successfully when the signature was created. Certificates issued according to this profile therefore only attest to the validity at the time of issuance and signing, rather than a retroactive state at the time of validation. This profile is intended for those applications where this declaration of validity is relevant and useful.¶
Applications that require traditional revocation checking that provides the state at the time of validation MUST NOT use this profile.¶
An example usage where this is useful is in services where the signed document is stored as an internal evidence record, such as when a Tax agency allows citizens to sign their tax declarations. This record is then pulled out and used only in case of a dispute where the identified signer challenges the signature. A revocation service is less likely to contribute to this process. If the challenge is successful, the signed document will be removed without affecting any other signed documents in the archive.¶
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.¶
Certificates issued according to this profile SHALL meet all requirements of this section.¶
To indicate that a certificate has no well-defined expiration date, the notAfter field SHALL be assigned the GeneralizedTime value 99991231235959Z, as defined in [RFC5280]¶
TODO Security¶
This document has no IANA actions.¶
TODO acknowledge.¶