One Signature Certificates
draft-ietf-lamps-one-signature-certs-02
| Document | Type | Active Internet-Draft (lamps WG) | |
|---|---|---|---|
| Authors | Stefan Santesson , Russ Housley | ||
| Last updated | 2026-07-01 | ||
| Replaces | draft-lamps-one-signature-certs | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Intended RFC status | Proposed Standard | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Document | |
| On agenda | lamps at IETF-126 | ||
| Document shepherd | Tim Hollebeek | ||
| IESG | IESG state | I-D Exists | |
| Consensus boilerplate | Yes | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | tim.hollebeek@digicert.com |
draft-ietf-lamps-one-signature-certs-02
LAMPS S. Santesson
Internet-Draft IDsec Solutions
Intended status: Standards Track R. Housley
Expires: 2 January 2027 Vigil Security
1 July 2026
One Signature Certificates
draft-ietf-lamps-one-signature-certs-02
Abstract
This document defines the signedDocumentBinding certificate
extension, which binds a certificate to the signed content of a
digital signature produced by a single signing operation. Each
certificate is created at the time of signing and the associated
signing key is generated, used to produce a single digital signature,
and then immediately destroyed. Certificates carrying this extension
are intended to be issued without a revocation mechanism and with no
expiration, 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-ietf-lamps-one-signature-
certs/.
Source for this draft and an issue tracker can be found at
https://github.com/lamps-wg/draft-ietf-lamps-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 2 January 2027.
Santesson & Housley Expires 2 January 2027 [Page 1]
Internet-Draft OSC July 2026
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
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 . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Basic features . . . . . . . . . . . . . . . . . . . . . 3
1.1.1. Revocation . . . . . . . . . . . . . . . . . . . . . 4
1.1.2. CA certificate validity . . . . . . . . . . . . . . . 5
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 5
3. Certificate content . . . . . . . . . . . . . . . . . . . . . 6
3.1. The signedDocumentBinding extension . . . . . . . . . . . 6
3.2. Defined bindingType identifiers . . . . . . . . . . . . . 7
3.2.1. Default Binding . . . . . . . . . . . . . . . . . . . 7
3.2.2. CAdES Binding . . . . . . . . . . . . . . . . . . . . 8
3.2.3. XAdES Binding . . . . . . . . . . . . . . . . . . . . 8
3.2.4. JWS Binding . . . . . . . . . . . . . . . . . . . . . 8
3.2.5. COSE Binding . . . . . . . . . . . . . . . . . . . . 9
4. ASN.1 Module . . . . . . . . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
5.1. Certificates Without Revocation . . . . . . . . . . . . . 11
5.2. Signed Document Binding . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
6.1. Registry for signedDocumentBinding bindingType
Identifiers . . . . . . . . . . . . . . . . . . . . . . . 11
6.1.1. Registry Contents . . . . . . . . . . . . . . . . . . 12
6.1.2. Registration Policy . . . . . . . . . . . . . . . . . 12
6.1.3. Initial Registry Contents . . . . . . . . . . . . . . 12
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.1. Normative References . . . . . . . . . . . . . . . . . . 13
7.2. Informative References . . . . . . . . . . . . . . . . . 14
Appendix A. Example Certificates . . . . . . . . . . . . . . . . 15
A.1. Certificate with Default Binding . . . . . . . . . . . . 15
A.2. Certificate with "cades" Binding . . . . . . . . . . . . 16
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
Santesson & Housley Expires 2 January 2027 [Page 2]
Internet-Draft OSC July 2026
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:
* 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 are bound to a specific document content;
* They assert that the corresponding private key was destroyed
immediately after signing; and
* They are typically issued without a revocation mechanism and with
no expiration.
Santesson & Housley Expires 2 January 2027 [Page 3]
Internet-Draft OSC July 2026
The signedDocumentBinding extension binds the public key in the
certificate to verification of the signature for the single
identified document. When this extension is present, it is
RECOMMENDED that the certificate not expire (notAfter is set to the
GeneralizedTime value of 99991231235959Z) and the noRevAvail
certificate extension [RFC9608] is also present to indicate that no
revocation information is available for this certificate.
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.
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.
When certificates are used to validate digital signatures the reasons
for revocation after the time of signing are not relevant when the
key is used only once. Under established signature validation
procedures [EN319102-1], a signature is assessed relative to a best-
signature-time: the earliest time at which the signature is proven to
have existed. A signing certificate that is revoked or that expires
after the best-signature-time does not invalidate the signature; the
past signature validation process treats such a signature as valid.
The same principle underlies the grace period concept described for
CAdES signatures [RFC5126]. Consequently, revocation information
whose effective time is after the time of signing is not relevant to
the validity of the signature.
Establishing the best-signature-time normally requires a trusted time
source such as a time-stamp [RFC3161] from a trusted authority. A
one signature certificate is created at the time of signing, so its
issuance time establishes the time of signing directly, with the
issuing CA fulfilling a role analogous to that of a time-stamp
authority. Any revocation of the certificate would necessarily take
effect after this time and would therefore not affect the validity of
the already-created signature.
Santesson & Housley Expires 2 January 2027 [Page 4]
Internet-Draft OSC July 2026
When revocation is due to key compromise, signature verifiers take
extra caution because the key compromise could have taken place
before the document signature was created. However, for a one
signature certificate, the signing key is generated for a single
signature and destroyed immediately afterwards, so the window during
which the private key exists and could be compromised is extremely
small.
1.1.2. CA certificate validity
Even if the end entity certificate has infinite validity, the
capability to validate the certificate is limited to the capability
to trust the CA. For initial validation, in a typical scenario, this
is limited by the validity period of the CA certificate.
However, a validation service may have several options available for
how to handle CA trust, in particular when re-validating archived
documents:
* The verifier may list the CA key and identity as trusted and treat
it as a trust anchor.
* The verifier may cross certify the CA and make it available for
validation to a local trusted Trust Anchor.
In addition, when a certificate repository is available, renewal of
the CA certificate can preserve the ability to validate the infinite
validity end entity certificate.
This specification assumes that initial validation of a signed
document is performed within the validity period of the CA
certificate. Realizing the full benefit of a non-expiring end entity
certificate for later re-validation MAY require additional trust
provisioning by the verifier.
Mechanisms for establishing trust in a CA beyond their certificate
validity period are outside the scope of this specification.
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.
Santesson & Housley Expires 2 January 2027 [Page 5]
Internet-Draft OSC July 2026
3. Certificate content
This document defines the signedDocumentBinding extension, which a CA
includes in a certificate to bind that certificate to a specific
signed content. The presence of this extension is the signal by
which a relying party recognizes a certificate as a one signature
certificate.
A certificate that includes the signedDocumentBinding extension
SHOULD also be issued with the properties described below, which
together provide the simplified long-term validation that motivates
this document.
Such a certificate SHOULD indicate that it has no well-defined
expiration date by setting the notAfter field to the GeneralizedTime
value 99991231235959Z, as defined in [RFC5280].
Such a certificate SHOULD include the id-ce-noRevAvail extension in
compliance with [RFC9608], indicating that the certificate is not
supported by any revocation mechanism.
A verifier MUST determine whether these properties apply by
inspecting the notAfter field and the presence of the id-ce-
noRevAvail extension.
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 37 }
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.
Santesson & Housley Expires 2 January 2027 [Page 6]
Internet-Draft OSC July 2026
The bindingType field MAY contain an identifier that specifies how
the data to be signed is derived from the digital object to be
signed.
Adding this extension to a certificate is a statement by the CA that
the signing key is generated exclusively for the purpose of signing
the document bound by this extension, and that the signing key is
destroyed after signing. The details for this procedure and how the
destruction of the signing key is assured SHOULD be outlined in the
certificate policy [RFC3647] of the issued certificate.
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 in order to prevent re-use of the signing
key for multiple signed documents. This enforces the contract that
the signing key is used only once for creation of one signature only.
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.
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
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.
Santesson & Housley Expires 2 January 2027 [Page 7]
Internet-Draft OSC July 2026
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"
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 <Reference> tag
up to and including the ending </Reference> 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.
Santesson & Housley Expires 2 January 2027 [Page 8]
Internet-Draft OSC July 2026
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 2 January 2027 [Page 9]
Internet-Draft OSC July 2026
<CODE BEGINS>
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 37 }
END
<CODE ENDS>
5. Security Considerations
Santesson & Housley Expires 2 January 2027 [Page 10]
Internet-Draft OSC July 2026
5.1. Certificates Without Revocation
One signature certificates are intended for use with the id-ce-
noRevAvail extension and no revocation mechanism. Such certificates
attest only to the state of trust and correctness of procedures at
the time of issuance. A verifier cannot infer this property from the
signedDocumentBinding extension alone and determines it by inspecting
the certificate for the id-ce-noRevAvail extension.
The Security considerations in [RFC9608] also applies to this
document.
5.2. Signed Document Binding
The signedDocumentBinding extension binds the certificate to specific
signed content by including a hash of the data to be signed.
Verification of this binding is not required for successful
cryptographic validation of the signature. A signature can therefore
validate correctly even if the binding is not checked.
However, a relying party SHOULD verify that the signed content
matches the dataTbsHash value in the signedDocumentBinding extension.
Performing this check ensures that the certificate is used only with
the content for which it was issued and enforces the intended scope
of the certificate.
The security model of this specification states that the associated
private key is generated for, and used in, exactly one signing
operation and is then destroyed. This property holds independently
of whether the binding is verified by the relying party.
Nevertheless, failure to verify the binding weakens the protections
provided by this specification and increases the risk of certificate
substitution or unintended certificate reuse.
When verified, the signedDocumentBinding extension provides an
additional safeguard against the use of the certificate for any
signature other than the one for which it was issued.
6. IANA Considerations
6.1. Registry for signedDocumentBinding bindingType Identifiers
IANA is requested to create a new registry entitled: “Signed Document
Binding Type Identifiers”
This registry shall contain identifiers used in the bindingType field
of the signedDocumentBinding certificate extension defined in this
document.
Santesson & Housley Expires 2 January 2027 [Page 11]
Internet-Draft OSC July 2026
6.1.1. Registry Contents
Each registry entry shall contain the following fields:
* Identifier: A UTF-8 string identifying the binding type.
* Description: A brief description of how the dataTbsHash value is
computed.
* Reference: A reference to the document that defines the binding
type.
6.1.2. Registration Policy
The registration policy for this registry is Specification Required
as defined in [RFC8174].
The designated expert(s) SHALL ensure that:
* The binding type definition clearly specifies a deterministic and
unambiguous procedure for computing the dataTbsHash value.
* The specification explains how circular dependencies with
certificate inclusion are avoided, where applicable.
* The identifier is unique within the registry.
6.1.3. Initial Registry Contents
IANA is requested to populate the registry with the following initial
values:
* Identifier: (absent)
* Description: Default binding as defined in this document
* Reference: This document
* Identifier: cades
* Description: CMS/CAdES binding excluding SigningCertificate
attributes
* Reference: This document
* Identifier: xades
* Description: XAdES binding excluding SignedProperties reference
Santesson & Housley Expires 2 January 2027 [Page 12]
Internet-Draft OSC July 2026
* Reference: This document
* Identifier: jws
* Description: JWS payload-only binding
* Reference: This document
* Identifier: cose
* Description: COSE payload-only binding
* Reference: This document
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,
<https://www.rfc-editor.org/rfc/rfc2119>.
[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,
<https://www.rfc-editor.org/rfc/rfc3647>.
[RFC5035] Schaad, J., "Enhanced Security Services (ESS) Update:
Adding CertID Algorithm Agility", RFC 5035,
DOI 10.17487/RFC5035, August 2007,
<https://www.rfc-editor.org/rfc/rfc5035>.
Santesson & Housley Expires 2 January 2027 [Page 13]
Internet-Draft OSC July 2026
[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,
<https://www.rfc-editor.org/rfc/rfc5280>.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, DOI 10.17487/RFC5652, September 2009,
<https://www.rfc-editor.org/rfc/rfc5652>.
[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
2015, <https://www.rfc-editor.org/rfc/rfc7515>.
[RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)",
RFC 8152, DOI 10.17487/RFC8152, July 2017,
<https://www.rfc-editor.org/rfc/rfc8152>.
[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>.
[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,
<https://www.rfc-editor.org/rfc/rfc9608>.
[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
[EN319102-1]
ETSI, "Electronic Signatures and Trust Infrastructures
(ESI); Procedures for Creation and Validation of AdES
Digital Signatures; Part 1: Creation and Validation",
ETSI EN 319 102-1 v1.4.1, June 2024.
Santesson & Housley Expires 2 January 2027 [Page 14]
Internet-Draft OSC July 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>.
[RFC5126] Pinkas, D., Pope, N., and J. Ross, "CMS Advanced
Electronic Signatures (CAdES)", RFC 5126,
DOI 10.17487/RFC5126, March 2008,
<https://www.rfc-editor.org/rfc/rfc5126>.
[RFC9321] Santesson, S. and R. Housley, "Signature Validation
Token", RFC 9321, DOI 10.17487/RFC9321, October 2022,
<https://www.rfc-editor.org/rfc/rfc9321>.
Appendix A. Example Certificates
This appendix contains non-normative example certificates that
conform to this specification.
Both certificates are issued to the subject "John Doe" by the issuing
CA "Example Org CA". Each certificate has no well-defined expiration
date (the notAfter field is set to the GeneralizedTime value
99991231235959Z), includes the id-ce-noRevAvail extension, asserts
the nonRepudiation key usage as a critical extension, includes an
authorityKeyIdentifier extension, and includes the
signedDocumentBinding extension. In both examples the data to be
signed is hashed with SHA-256, and the dataTbsHash value is the
32-octet sequence 0x01 0x02 ... 0x20.
A.1. Certificate with Default Binding
In this certificate the bindingType field is absent, so the default
binding applies. The signedDocumentBinding extension value contains
only the dataTbsHash and hashAlg fields:
Santesson & Housley Expires 2 January 2027 [Page 15]
Internet-Draft OSC July 2026
SignedDocumentBinding ::= SEQUENCE {
dataTbsHash 0102030405060708090A0B0C0D0E0F10
1112131415161718191A1B1C1D1E1F20,
hashAlg id-sha256 }
-----BEGIN CERTIFICATE-----
MIICKDCCAc6gAwIBAgIQVweFe0CFvyM8JFDu9wH/AzAKBggqhkjOPQQDAjA8MQsw
CQYDVQQGEwJTRTEUMBIGA1UECgwLRXhhbXBsZSBPcmcxFzAVBgNVBAMMDkV4YW1w
bGUgT3JnIENBMCAXDTI2MDcwMTE4MzkxMloYDzk5OTkxMjMxMjM1OTU5WjA2MQsw
CQYDVQQGEwJTRTEUMBIGA1UECgwLRXhhbXBsZSBPcmcxETAPBgNVBAMMCEpvaG4g
RG9lMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEoDGGE1EyIPv2VlXSzW00DNJU
gb5SD8U5GX1inZpc0oHAkNKwYrcFEOtiY4f8vYDN51M+7uvSS+eG3n7104AZdqOB
tTCBsjArBgNVHSMEJDAigCChSvYTV05U5D1HFAKxqhGCj1tR/2mj1gBGOs7VIwC9
KjApBgNVHQ4EIgQgbC4lcDHxDRh34nfrxo872YShaEZ6kKHIaYF5dD9Un3IwDgYD
VR0PAQH/BAQDAgZAMAkGA1UdOAQCBQAwPQYIKwYBBQUHASUEMTAvBCABAgMEBQYH
CAkKCwwNDg8QERITFBUWFxgZGhscHR4fIDALBglghkgBZQMEAgEwCgYIKoZIzj0E
AwIDSAAwRQIhAKAjo5DGTI++9lJZrilg0ir5UQbxn2IcDBIwImrkQI4jAiBiYxfj
CVdXwwJEx3AoRrfODm9KrOLsKjA5dRxIewoNlg==
-----END CERTIFICATE-----
A.2. Certificate with "cades" Binding
In this certificate the bindingType field is set to "cades",
indicating the CAdES binding defined in this document. The
signedDocumentBinding extension value contains the dataTbsHash,
hashAlg, and bindingType fields:
SignedDocumentBinding ::= SEQUENCE {
dataTbsHash 0102030405060708090A0B0C0D0E0F10
1112131415161718191A1B1C1D1E1F20,
hashAlg id-sha256,
bindingType "cades" }
-----BEGIN CERTIFICATE-----
MIICLzCCAdagAwIBAgIRAKkArNDJbg8prMEiyqT6MI0wCgYIKoZIzj0EAwIwPDEL
MAkGA1UEBhMCU0UxFDASBgNVBAoMC0V4YW1wbGUgT3JnMRcwFQYDVQQDDA5FeGFt
cGxlIE9yZyBDQTAgFw0yNjA3MDExODM5MTJaGA85OTk5MTIzMTIzNTk1OVowNjEL
MAkGA1UEBhMCU0UxFDASBgNVBAoMC0V4YW1wbGUgT3JnMREwDwYDVQQDDAhKb2hu
IERvZTBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABKAxhhNRMiD79lZV0s1tNAzS
VIG+Ug/FORl9Yp2aXNKBwJDSsGK3BRDrYmOH/L2AzedTPu7r0kvnht5+9dOAGXaj
gbwwgbkwKwYDVR0jBCQwIoAgoUr2E1dOVOQ9RxQCsaoRgo9bUf9po9YARjrO1SMA
vSowKQYDVR0OBCIEIGwuJXAx8Q0Yd+J368aPO9mEoWhGepChyGmBeXQ/VJ9yMA4G
A1UdDwEB/wQEAwIGQDAJBgNVHTgEAgUAMEQGCCsGAQUFBwElBDgwNgQgAQIDBAUG
BwgJCgsMDQ4PEBESExQVFhcYGRobHB0eHyAwCwYJYIZIAWUDBAIBDAVjYWRlczAK
BggqhkjOPQQDAgNHADBEAiBdNJa15qBpkYs7IP5Dlzb2ZeaudxNwwZhRUeE8Qvg6
uQIgLuiqo76eAQkHAiT8IlB/dn74SokUCs48f7ADk9p8zZA=
-----END CERTIFICATE-----
Santesson & Housley Expires 2 January 2027 [Page 16]
Internet-Draft OSC July 2026
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
Email: housley@vigilsec.com
Santesson & Housley Expires 2 January 2027 [Page 17]