LAMPS S. Santesson Internet-Draft IDsec Solutions Intended status: Standards Track R. Housley Expires: 15 May 2026 Vigil Security 11 November 2025 One Signature Certificates draft-santesson-one-signature-certs-00 Abstract This document defines a profile for certificates that are issued for validation of the digital signature produced by a single signing operation. Each certificate is created at the time of signing and bound to the signed content. The associated signing key is generated, used to produce a single digital signature, and then immediately destroyed. The certificate never expires and is never revoked, which simplifies long-term validation. About This Document 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. 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 15 May 2026. Santesson & Housley Expires 15 May 2026 [Page 1] Internet-Draft OSC November 2025 Copyright Notice 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Basic features . . . . . . . . . . . . . . . . . . . . . 3 1.1.1. Revocation . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4 3. Certificate content . . . . . . . . . . . . . . . . . . . . . 4 3.1. The signedDocumentBinding extension . . . . . . . . . . . 5 3.2. Defined bindingType identifiers . . . . . . . . . . . . . 5 3.2.1. Default Binding . . . . . . . . . . . . . . . . . . . 6 3.2.2. CAdES Binding . . . . . . . . . . . . . . . . . . . . 6 3.2.3. XAdES Binding . . . . . . . . . . . . . . . . . . . . 6 3.2.4. JWS Binding . . . . . . . . . . . . . . . . . . . . . 7 3.2.5. COSE Binding . . . . . . . . . . . . . . . . . . . . 7 4. ASN.1 Module . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 7.2. Informative References . . . . . . . . . . . . . . . . . 10 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction The landscape of server-based signing services has changed over the decades. Recently, one type of signature service has gained favor, where the signing private key and the signing certificate are created for each digital signature, rather than re-using a static key and certificate over an extended time period. Some reasons why this type of signature services has been successful are: Santesson & Housley Expires 15 May 2026 [Page 2] Internet-Draft OSC November 2025 * 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; * Revocation of signing certificates is practically non-existent despite many years of operation and millions of signatures; and * The signature service holds no pre-stored user keys or certificates. While this type of signature service solves many 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 validation based on aging data. This document takes this one step further and allows validation at any time in the future as long as trust in the CA certificate can be established. 1.1. Basic features One signature certificates have the following common characteristics: * They never expire; * They are never revoked; * They are bound to a specific document content; and * They assert that the corresponding private key was destroyed immediately after signing. 1.1.1. Revocation 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 risks of loss, unauthorized usage, or theft. When many objects are signed with the same private key, the risk of exposure and the number of affected signed documents upon revocation increases, unless properly timestamped and properly verified. Santesson & Housley Expires 15 May 2026 [Page 3] Internet-Draft OSC November 2025 When a signing key is used only once, that risk of exposure is greatly reduced, and it has been shown that most usages of dedicated private keys and certificates no longer require revocation. The CA can readily attest that a certain procedure was followed when the certificate was issued. As a matter of policy, the certificate itself is an attestation that the CP and CPS [RFC3647] were 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. 2. Conventions and Definitions 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. Certificate content Conforming certificates SHALL meet all requirements of this section. Certificates MUST indicate that a certificate has no well-defined expiration date by setting the notAfter field to the GeneralizedTime value 99991231235959Z, as defined in [RFC5280]. Certificates MUST include the id-ce-noRevAvail extension in compliance with [RFC9608], indicating that this certificate is not supported by any revocation mechanism. Santesson & Housley Expires 15 May 2026 [Page 4] Internet-Draft OSC November 2025 Certificates MUST include the signedDocumentBinding extension, binding the certificate to a specific signed content. 3.1. The signedDocumentBinding extension The signedDocumentBinding extension binds a certificate to a specific signed content. When present, conforming CAs SHOULD mark this extension as non-critical. name id-pe-signedDocumentBinding OID { id-pe TBD } syntax SignedDocumentBinding criticality SHOULD be FALSE SignedDocumentBinding ::= SEQUENCE { dataTbsHash OCTET STRING, hashAlg DigestAlgorithmIdentifier, bindingType UTF8String OPTIONAL } The dataTbsHash field MUST contain a hash of the data to be signed. The hashAlg field MUST contain the AlgorithmIdentifier of the hash algorithm used to generate the dataTbsHash value. The bindingType field MAY contain an identifier that specifies how the data to be signed is derived from the digital object to be signed. 3.2. Defined bindingType identifiers The bindingType field defines how the data to be signed (dataTbsHash) is derived from the signed document. This field identifies a deterministic procedure for selecting the portion of the signed content that is included in the hash computation. When the field is omitted, the rules for the default binding type apply. The purpose of the dataTbsHash value is to bind the certificate to the document being signed, not to protect the document’s integrity. The integrity of the signed content is provided by the signature itself. If any byte of the signed document is modified, the calculated hash will no longer match the certificate. Therefore, the dataTbsHash enables validators and relying parties to confirm that the certificate was issued for the exact content that was signed. Validators SHOULD verify that the signed document matches the certificate’s binding information. This verification is not required for the signature to validate successfully but provides an additional safeguard against misuse or substitution of certificates. Santesson & Housley Expires 15 May 2026 [Page 5] Internet-Draft OSC November 2025 This document defines a set of bindingType identifiers. Additional bindingType identifiers MAY be defined by future specifications. 3.2.1. Default Binding When the bindingType is absent, the default binding applies. In this case, the dataTbsHash value is the hash of the exact data that is hashed and signed by the signature format in use. Examples include: - For XML Signatures [XMLDSIG11], the hash of the SignedInfo element. - For CMS Signatures [RFC5652], the DER-encoded SignedAttributes structure. - For other formats, the data structure input directly to the signature algorithm. This bindingType MUST NOT be used when the data to be signed includes either the signer certificate itself or a hash of the signer certificate. This includes JWS and COSE signed documents that can include signer certificates in the protected header. JWS signatures [RFC7515] MUST use the "jws" bindingType and COSE signatures [RFC8152] MUST use the "cose" binding type. 3.2.2. CAdES Binding Identifier: "cades" For CMS [RFC5652] or ETSI CAdES [CADES] signatures incorporating SigningCertificate or SigningCertificateV2 attributes [RFC5035] in signedAttrs, the dataTbsHash value is computed over the DER encoding of SignerInfo excluding any instances of SigningCertificate or SigningCertificateV2 attributes from the SignedAttributes set. This bindingType also applies to PDF [ISOPDF2] and ETSI PAdES [PADES] signed documents when applicable due to its use of CMS for signing. 3.2.3. XAdES Binding Identifier: "xades" Santesson & Housley Expires 15 May 2026 [Page 6] Internet-Draft OSC November 2025 For ETSI XML Advanced Electronic Signatures [XADES], the dataTbsHash value is computed over the canonicalized SignedInfo element, with any Reference elements whose Type attribute equals "http://uri.etsi.org/01903#SignedProperties" removed prior to hashing. This ensures that the SignedProperties element, which may contain references to the signing certificate, does not create a circular dependency. Extraction of the Reference element MUST be done by removing only the characters from the leading tag up to and including the ending tag, preserving all other bytes of SignedInfo unchanged, including any white space or line feeds. Note: This operation is purely textual and does not require XML parsing beyond locating the tag boundaries. 3.2.4. JWS Binding Identifier: "jws" For JSON Web Signatures (JWS) [RFC7515], the dataTbsHash value is computed over the payload only. The protected header and any unprotected header parameters MUST NOT be included in the hash calculation. This exclusion avoids circular dependencies where certificate data may appear in the protected header. 3.2.5. COSE Binding Identifier: "cose" For COSE signatures [RFC8152], the dataTbsHash value is computed over the payload only. The protected header and any unprotected header parameters MUST NOT be included in the hash calculation. This exclusion avoids circular dependencies where certificate data may appear in the protected header. 4. ASN.1 Module Santesson & Housley Expires 15 May 2026 [Page 7] Internet-Draft OSC November 2025 SignedDocumentBindingExtn { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-signedDocumentBinding(TBD) } DEFINITIONS IMPLICIT TAGS ::= BEGIN IMPORTS EXTENSION, id-pkix, id-pe FROM PKIX-CommonTypes-2009 -- RFC 5912 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-pkixCommon-02(57) } DigestAlgorithmIdentifier FROM CryptographicMessageSyntax-2010 -- RFC 6268 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) id-mod-cms-2009(58) } ; -- signedDocumentBinding Certificate Extension ext-SignedDocumentBinding EXTENSION ::= { SYNTAX SignedDocumentBinding IDENTIFIED BY id-pe-signedDocumentBinding } SignedDocumentBinding ::= SEQUENCE { dataTbsHash OCTET STRING, hashAlg DigestAlgorithmIdentifier, bindingType UTF8String OPTIONAL } -- signedDocumentBinding Certificate Extension OID id-pe-signedDocumentBinding OBJECT IDENTIFIER ::= { id-pe TBD } END 5. Security Considerations TODO Security Considerations. Including text on reliance on certificates without revocation. 6. IANA Considerations TBD IANA registry for bindingType identifiers Santesson & Housley Expires 15 May 2026 [Page 8] Internet-Draft OSC November 2025 7. References 7.1. Normative References [CADES] ETSI, "Electronic Signatures and Infrastructures (ESI); CAdES digital signatures; Part 1: Building blocks and CAdES baseline signatures", ETSI EN 319 122-1 v1.2.1, October 2021. [ISOPDF2] ISO, "Document management -- Portable document format -- Part 2: PDF 2.0", ISO 32000-2, July 2017. [PADES] ETSI, "Electronic Signatures and Infrastructures (ESI); PAdES digital signatures; Part 1: Building blocks and PAdES baseline signatures", ETSI EN 319 142-1 v1.2.1, January 2024. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. Wu, "Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework", RFC 3647, DOI 10.17487/RFC3647, November 2003, . [RFC5035] Schaad, J., "Enhanced Security Services (ESS) Update: Adding CertID Algorithm Agility", RFC 5035, DOI 10.17487/RFC5035, August 2007, . [RFC5280] 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, . [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, DOI 10.17487/RFC5652, September 2009, . [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, . Santesson & Housley Expires 15 May 2026 [Page 9] Internet-Draft OSC November 2025 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", RFC 8152, DOI 10.17487/RFC8152, July 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC9608] Housley, R., Okubo, T., and J. Mandel, "No Revocation Available for X.509 Public Key Certificates", RFC 9608, DOI 10.17487/RFC9608, June 2024, . [XADES] ETSI, "Electronic Signatures and Infrastructures (ESI); XAdES digital signatures; Part 1: Building blocks and XAdES baseline signatures", ETSI EN 319 132-1 v1.3.1, July 2024. [XMLDSIG11] Eastlake, D., Reagle, J., Solo, D., Hirsch, F., Nystrom, M., Roessler, T., and K. Yiu, "XML Signature Syntax and Processing Version 1.1", W3C Proposed Recommendation, 11 April 2013. 7.2. Informative References [RFC9321] Santesson, S. and R. Housley, "Signature Validation Token", RFC 9321, DOI 10.17487/RFC9321, October 2022, . Acknowledgments TODO acknowledge. Authors' Addresses Stefan Santesson IDsec Solutions AB Forskningsbyn Ideon SE-223 70 Lund Sweden Email: sts@aaa-sec.com Russ Housley Vigil Security, LLC Herndon, VA, United States of America Santesson & Housley Expires 15 May 2026 [Page 10] Internet-Draft OSC November 2025 Email: housley@vigilsec.com Santesson & Housley Expires 15 May 2026 [Page 11]