]> IDsec Solutions AB

Forskningsbyn Ideon Lund 223 70 SE sts@aaa-sec.com

Vigil Security, LLC

Herndon, VA US housley@vigilsec.com

LAMPS certificate signature X.509 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 Status information for this document may be found at . Source for this draft and an issue tracker can be found at .

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) , 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.

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.

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 is also present to indicate that no revocation information is available for this certificate.

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 , 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 . 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 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. 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.

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.

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 when, and only when, they appear in all capitals, as shown here.

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 . Such a certificate SHOULD include the id-ce-noRevAvail extension in compliance with , 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.

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. 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. 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 of the issued certificate.

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.

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 , the hash of the SignedInfo element.
• For CMS Signatures , 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 MUST use the "jws" bindingType and COSE signatures MUST use the "cose" binding type.

CAdES Binding Identifier: "cades" For CMS or ETSI CAdES signatures incorporating SigningCertificate or SigningCertificateV2 attributes 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 and ETSI PAdES signed documents when applicable due to its use of CMS for signing.

XAdES Binding Identifier: "xades" For ETSI XML Advanced Electronic Signatures , 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.

JWS Binding Identifier: "jws" For JSON Web Signatures (JWS) , 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.

COSE Binding Identifier: "cose" For COSE signatures , 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.

ASN.1 Module

Security Considerations

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 also applies to this document.

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.

IANA Considerations

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.

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.

Registration Policy The registration policy for this registry is Specification Required as defined in . 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.

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
• Reference: This document
• Identifier: jws
• Description: JWS payload-only binding
• Reference: This document
• Identifier: cose
• Description: COSE payload-only binding
• Reference: This document

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document presents a framework to assist the writers of certificate policies or certification practice statements for participants within public key infrastructures, such as certification authorities, policy authorities, and communities of interest that wish to rely on certificates. In particular, the framework provides a comprehensive list of topics that potentially (at the writer's discretion) need to be covered in a certificate policy or a certification practice statement. This document supersedes RFC 2527. In the original Enhanced Security Services for S/MIME document (RFC 2634), a structure for cryptographically linking the certificate to be used in validation with the signature was introduced; this structure was hardwired to use SHA-1. This document allows for the structure to have algorithm agility and defines a new attribute for this purpose. [STANDARDS-TRACK] This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] This document describes the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content. [STANDARDS-TRACK] JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and an IANA registry defined by that specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need for the ability to have basic security services defined for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. X.509v3 public key certificates are profiled in RFC 5280. Short-lived certificates are seeing greater use in the Internet. The Certification Authority (CA) that issues these short-lived certificates do not publish revocation information because the certificate lifespan that is shorter than the time needed to detect, report, and distribute revocation information. Some long-lived X.509v3 public key certificates never expire, and they are never revoked. This specification defines the noRevAvail certificate extension so that a relying party can readily determine that the CA does not publish revocation information for the certificate, and it updates the certification path validation algorithm defined in RFC 5280 so that revocation checking is skipped when the noRevAvail certificate extension is present. ISO ETSI ETSI ETSI Informative References This document describes the format of a request sent to a Time Stamping Authority (TSA) and of the response that is returned. It also establishes several security-relevant requirements for TSA operation, with regards to processing requests to generate responses. [STANDARDS-TRACK] This document defines the format of an electronic signature that can remain valid over long periods. This includes evidence as to its validity even if the signer or verifying party later attempts to deny (i.e., repudiates) the validity of the signature. The format can be considered as an extension to RFC 3852 and RFC 2634, where, when appropriate, additional signed and unsigned attributes have been defined. The contents of this Informational RFC amount to a transposition of the ETSI Technical Specification (TS) 101 733 V.1.7.4 (CMS Advanced Electronic Signatures -- CAdES) and is technically equivalent to it. The technical contents of this specification are maintained by ETSI. The ETSI TS and further updates are available free of charge at: http://www.etsi.org/WebSite/Standards/StandardsDownload.aspx This memo provides information for the Internet community. Electronic signatures have a limited lifespan with respect to the time period that they can be validated and determined to be authentic. The Signature Validation Token (SVT) defined in this specification provides evidence that asserts the validity of an electronic signature. The SVT is provided by a trusted authority, which asserts that a particular signature was successfully validated according to defined procedures at a certain time. Any future validation of that electronic signature can be satisfied by validating the SVT without any need to also validate the original electronic signature or the associated digital certificates. The SVT supports electronic signatures in Cryptographic Message Syntax (CMS), XML, PDF, and JSON documents. ETSI

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.

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:

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:

Acknowledgments TODO acknowledge.