Signature Validation TokenIDsec Solutions ABForskningsbyn IdeonLund223 70Swedensts@aaa-sec.comVigil Security, LLC516 Dranesville RoadHerndonVA20170United States of Americahousley@vigilsec.comdigital signatureelectronic signaturelong-term archiveElectronic 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.Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This is a contribution to the RFC Series, independently of any
other RFC stream. The RFC Editor has chosen to publish this
document at its discretion and makes no statement about its value
for implementation or deployment. Documents approved for
publication by the RFC Editor are not candidates for any level of
Internet Standard; see Section 2 of RFC 7841.
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
.
Copyright Notice
Copyright (c) 2022 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
() 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.
Table of Contents
. Introduction
. Definitions
. Signature Validation Token
. Signature Validation Token Function
. Signature Validation Token Syntax
. Data Types
. Signature Validation Token JWT Claims
. SigValidation Object Class
. Signature Claims Object Class
. SigReference Claims Object Class
. SignedDataReference Claims Object Class
. PolicyValidation Claims Object Class
. TimeValidation Claims Object Class
. CertReference Claims Object Class
. SVT JOSE Header
. Profiles
. Defined Profiles
. Signature Verification with an SVT
. IANA Considerations
. Claim Names Registration
. Registry Contents
. Header Parameter Names Registration
. Registry Contents
. Security Considerations
. Level of Reliance
. Aging Algorithms
. References
. Normative References
. Informative References
. XML Signature Profile
. Notation
. References to XML Elements from XML Schemas
. SVT in XML Documents
. SignatureValidationToken Signature Property
. Multiple SVTs in an XML Signature
. XML Signature SVT Claims
. XML Profile Identifier
. XML Signature Reference Data
. XML Signed Data Reference Data
. XML Signer Certificate References
. JOSE Header
. SVT Signing Key Reference
. PDF Signature Profile
. SVTs in PDF Documents
. SVT Extension to Timestamp Tokens
. PDF Signature SVT Claims
. PDF Profile Identifier
. PDF Signature Reference Data
. PDF Signed Data Reference Data
. PDF Signer Certificate References
. JOSE Header
. SVT Signing Key Reference
. JWS Profile
. SVT in JWS
. "svt" Header Parameter
. Multiple SVTs in a JWS Signature
. JWS Signature SVT Claims
. JWS Profile Identifier
. JWS Signature Reference Data
. JWS Signed Data Reference Data
. JWS Signer Certificate References
. SVT JOSE Header
. SVT Signing Key Reference
. Schemas
. Concise Data Definition Language (CDDL)
. JSON Schema
. Examples
Authors' Addresses
IntroductionElectronic signatures have a limited lifespan regarding when they can be validated
and determined to be authentic. Many factors make it more difficult to validate
electronic signatures over time. For example:
Trusted information about the validity of the certificate containing the signer's public key is not available.
Trusted information about the time when the signature was actually created is not available.
Algorithms used to create the electronic signature may no longer be considered secure at the time of validation and may therefore no longer be available in software libraries.
Services necessary to validate the signature are no longer available at the time of validation.
Supporting evidence such as certification authority (CA) certificates, Online Certificate Status Protocol (OCSP) responses, Certificate Revocation Lists (CRLs), or timestamps is not available or can't be validated.
The challenges to validation of an electronic signature increase
over time, and eventually it may simply be impossible to verify the
signature with a sufficient level of assurance.Existing standards, such as the ETSI XAdES profile for XML
signatures , ETSI PAdES profile for PDF signatures
, and ETSI CAdES profile for CMS signatures
, can be used to extend the time within which a signature can be
validated at the cost of significant complexity, which involves storing and
validating significant amounts of external evidence data such as revocation data,
signature time stamps, and archival time stamps.The Signature Validation Token (SVT) defined in this specification takes a
trusted signature validation process as an input and preserves the validation result
for the associated signature and signed document. The SVT asserts that a particular
electronic signature was successfully validated by a trusted authority according to
defined procedures at a certain time. Those procedures MUST include checks
that the signature match the signed document, checks that the signature can be validated by
the signing certificate, and checks that the signing certificate pass certificate
path validation .
Those procedures MAY also include checks associated with a particular trust policy such as
that an acceptable certificate policy was used to issue the
signer's certificate and checks that an acceptable signature policy was used by
the signer .Once the SVT is issued by a trusted
authority, any future validation of that electronic signature can be satisfied by validating
the SVT without any need to also revalidate the original electronic signature.As the SVT is used to preserve validation results obtained through applying existing
standards for signature validation, it is complementary to and not a replacement for such standards,
including the ETSI standards for long-term validation listed above.
The SVT does, however, have the potentially positive effect that it may significantly reduce the need to
apply complex long-term validation and preservation techniques for signature validation
if an SVT is issued and applied to the signed document at an early stage where the signature
can be validated without support of large amounts of external evidence.
The use of SVTs may therefore drastically reduce the complexity of revalidation of old
archived electronic signatures.The SVT can be signed with private keys and algorithms that
provide confidence for a considerable time period. In fact, multiple SVTs can be used
to offer greater assurance. For example, one SVT could be produced with a large RSA
private key, a second one with a strong elliptic curve, and a third one with a quantum
safe digital signature algorithm to protect against advances in computing power and
cryptanalytic capabilities. Further, the trusted authority can add additional SVTs
in the future using fresh private keys and signatures to extend the lifetime of the SVTs if necessary.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.
This document use the following terms:
Signed Data:
The data covered by a particular electronic signature. This is
typically equivalent to the signed content of a document, and it
represents the data that the signer intended to sign. In some cases,
such as in some XML signatures, the Signed Data can be the collection
of several data fragments each referenced by the signature. In the
case of PDF, this is the data covered by the "ByteRange" parameter in
the signature dictionary. In JSON Web Signature (JWS), this is the
unencoded payload data (before base64url encoding).
Signed Bytes:
These are the actual bytes of data that were hashed and signed by
the digital signature algorithm. In most cases, this is not the actual
Signed Data but a collection of signature metadata that includes
references (hash) of the Signed Data as well as information about
algorithms and other data bound to a signature. In XML, this is the
canonicalized SignedInfo element. In CMS and PDF signatures, this is
the DER-encoded SignedAttributes structure. In JWS, this is the
protected header and payload data formatted according to .
When these terms are used as defined in this section, they appear with a
capitalized first letter.Signature Validation TokenSignature Validation Token FunctionThe Signature Validation Token (SVT) is created by a trusted service to assert
evidence of successful electronic signature validation using a well-defined and
trustworthy signature validation process. The SVT binds the validation result to
the validated signature, the document signed by the signature, and the certificate of the signer.
This allows a relying party to verify the validity of a signed document
without having to revalidate the original signature or to reuse any of its associated
cryptographic algorithms for as long as the SVT itself can be validated.
The SVT achieves this by binding the following information to
a specific electronic signature:
A unique identification of the electronic signature.
The data and metadata signed by the electronic signature.
The signer's certificate that was validated as part of electronic signature verification.
The certification path that was used to validate the signer's certificate.
An assertion providing evidence of signature verification, the time the verification was performed, the procedures used to verify the electronic signature, and the outcome of the verification.
An assertion providing evidence of the time at which the signature is known to have existed, the procedures used to validate the time of existence, and the outcome of the validation.
The SVT aims to support long-term validation that can be further extended into the future by applying the following strategies:
by using secure algorithms with long life expectancy when signing the SVT
by reissuing the SVT before it becomes insecure or is considered expired
optionally, by issuing multiple SVTs with different algorithms to provide redundancy in case one algorithm is broken
Signature Validation Token SyntaxThe SVT is carried in a JSON Web Token (JWT) as defined in .Data TypesThe contents of claims in an SVT are specified using the following data types:
String:
JSON Data Type of string that contains an arbitrary
case-sensitive string value.
Base64Binary:
JSON Data Type of string that contains a Base64-encoded byte
array of binary data.
StringOrURI:
JSON Data Type of string that contains an arbitrary string or
a URI as defined in . It is REQUIRED to contain the colon character (":") to be a URI.
URI:
JSON Data Type of string that contains a URI as defined in
.
Integer:
JSON Data Type of number that contains a 32-bit signed integer value (from
-231 to 231-1).
Long:
JSON Data Type of number that contains a 64-bit signed integer value (from
-263 to 263-1).
NumericDate:
JSON Data Type of number that contains data as defined in , which is the number of seconds from 1970-01-01T00:00:00Z UTC until the specified
UTC date/time, ignoring leap seconds.
Boolean:
JSON Data Type of boolean that contains the explicit value of true or
false.
Object<Class>:
A JSON object holding a claims object of a class defined in this
specification (see ).
Map<Type>:
A JSON object with name-value pairs where the value is an object of the
specified Type in the notation. For example, Map<String> is a JSON
object with name-value pairs where all values are of type String.
Array:
A JSON array of a specific data type as defined in this section. An array
is expressed in this specification by square brackets. For example, [String]
indicates an array of String values, and [Object<DocHash>] indicates an
array of DocHash objects.
Null:
A JSON null that represents an absent value. A claim with a null value is
equivalent with an absent claim.
Signature Validation Token JWT ClaimsThe SVT MUST contain only JWT claims in the following list:
"jti":
A String data type that is a "JWT ID" registered claim according to
. It is RECOMMENDED that the
identifier holds a hexadecimal string representation of a 128-bit unsigned
integer. An SVT MUST contain one "JWT ID" claim.
"iss":
A StringOrURI data type that is an "Issuer" registered claim according
to , which is an arbitrary unique identifier of the
SVT issuer. This value SHOULD have the value of a URI based
on a domain owned by the issuer. An SVT MUST contain one
"Issuer" claim.
"iat":
A NumericDate data type that is an "Issued At" registered claim
according to , which expresses the time
when this SVT was issued. An SVT MUST contain one "Issued At"
claim.
"aud":
A [StringOrURI] data type or a StringOrURI data type that is an
"Audience" registered claim according to . The
audience claim is an array of one or more identifiers, identifying intended
recipients of the SVT. Each identifier MAY identify a single
entity, a group of entities, or a common policy adopted by a group of
entities. If only one value is provided, it MAY be provided
as a single StringOrURI data type value instead of as an array of
values. Inclusion of the "Audience" claim in an SVT is
OPTIONAL.
"exp":
A NumericDate data type that is an "Expiration Time" registered claim
according to , which expresses the time
when services and responsibilities related to this SVT are no longer
provided by the SVT issuer. The precise meaning of the expiration time claim
is defined by local policies. See implementation note below. Inclusion of
the "Expiration Time" claim in an SVT is OPTIONAL.
"sig_val_claims":
An Object<SigValidation> data type that contains signature
validation claims for this SVT extending the standard registered JWT claims
above. An SVT MUST contain one sig_val_claims claim.
Note: An SVT asserts that a particular validation process was undertaken at a stated
time. This fact never changes and never expires. However, some other aspects
of the SVT such as liability for false claims or service provision related to a specific
SVT may expire after a certain period of time, such as a service where an old SVT can be
upgraded to a new SVT signed with fresh keys and algorithms.SigValidation Object ClassThe sig_val_claims JWT claim uses the SigValidation object class. A SigValidation object
holds all custom claims, and a SigValidation object contains the following parameters:
"ver":
A String data type representing the version. This parameter
MUST be present and the version in this specification
indicated by the value "1.0".
"profile":
A StringOrURI data type representing the name of a profile that defines
conventions followed for specific claims and any extension points used by
the SVT issuer. This parameter MUST be present.
"hash_algo":
A URI data type that identifies the hash algorithm used to compute the
hash values within the SVT. The URI identifier MUST be one
defined in or in the IANA registry defined by this
specification. This parameter MUST be present.
"sig":
An [Object<Signature>] data type that gives information about
validated electronic signatures as an array of Signature objects. If the SVT
contains signature validation evidence for more than one signature, then each
signature is represented by a separate Signature object. At least one
Signature object MUST be present.
"ext":
A Map<String> data type that provides additional claims related to
the SVT. Extension claims are added at the discretion of the SVT issuer;
however, extension claims MUST follow any conventions defined
in a profile of this specification (see ). Inclusion
of this parameter is OPTIONAL.
Signature Claims Object ClassThe sig parameter in the SigValidation object class uses the Signature object
class. The Signature object contains claims related to signature validation
evidence for one signature, and it contains the following parameters:
"sig_ref":
An Object<SigReference> data type that contains reference
information identifying the target signature. This parameter
MUST be present.
"sig_data_ref":
An [Object<SignedDataReference>] data type that contains an array of
references to Signed Data that was signed by the target electronic
signature. At least one SignedDataReference object MUST be
present.
"signer_cert_ref":
An Object<CertReference> data type that references the signer's
certificate and optionally references a supporting certification path that
was used to verify the target electronic signature. This parameter
MUST be present.
"sig_val":
An [Object<PolicyValidation>] data type that contains an array of
results of signature verification according to defined procedures. At least
one PolicyValidation object MUST be present.
"time_val":
An [Object<TimeValidation>] data type that contains an array of time
verification results showing that the target signature has existed at a specific
time in the past. Inclusion of this parameter is OPTIONAL.
"ext":
A MAP<String> data type that provides additional claims related to
the target signature. Extension claims are added at the discretion of the SVT
issuer; however, extension claims MUST follow any conventions
defined in a profile of this specification (see ). Inclusion of this parameter is OPTIONAL.
SigReference Claims Object ClassThe sig_ref parameter in the Signature object class uses the SigReference object
class. The SigReference object provides information used to match the Signature
claims object to a specific target electronic signature and to verify the integrity
of the target signature value and Signed Bytes, and it contains the following parameters:
"id":
A String data type that contains an identifier assigned to the target
signature. Inclusion of this parameter is OPTIONAL.
"sig_hash":
A Base64Binary data type that contains a hash value of the target
electronic signature value. This parameter MUST be present.
"sb_hash":
A Base64Binary data type that contains a hash value of the Signed Bytes of
the target electronic signature. This parameter MUST be
present.
SignedDataReference Claims Object ClassThe sig_data_ref parameter in the Signature object class uses the SignedDataReference object
class. The SignedDataReference object provides information used to verify the target electronic
signature references to Signed Data as well as to verify the integrity of all data that
is signed by the target signature, and it contains the following parameters:
"ref":
A String data type that contains a reference identifier for the data or
data fragment covered by the target electronic signature. This parameter
MUST be present.
"hash":
A Base64Binary data type that contains the hash value for the data covered
by the target electronic signature. This parameter MUST be
present.
PolicyValidation Claims Object ClassThe sig_val parameter in the Signature object class uses the PolicyValidation object
class. The PolicyValidation object provides information about the result of a validation
process according to a specific policy, and it contains the following parameters:
"pol":
A StringOrURI data type that contains the identifier of the policy
governing the electronic signature verification process. This parameter
MUST be present.
"res":
A String data type that contains the result of the electronic signature
verification process. The value MUST be one of "PASSED",
"FAILED", or "INDETERMINATE" as defined by . This parameter MUST be present.
"msg":
A String data type that contains a message describing the
result. Inclusion of this parameter is OPTIONAL.
"ext":
A MAP<String> data type that provides additional claims related to
the target signature. Extension claims are added at the discretion of the
SVT issuer; however, extension claims MUST follow any
conventions defined in a profile of this specification (see ). Inclusion of this parameter is
OPTIONAL.
TimeValidation Claims Object ClassThe time_val parameter in the Signature object class uses the TimeValidation object
class. The TimeValidation claims object provides information about the result of
validating evidence of time asserting that the target signature existed at a particular
time in the past. Evidence of time is typically a timestamp according to , but other types of evidence may be used such as a previously issued SVT for this signature. The TimeValidation claims object contains the following parameters:
"time":
A NumericDate data type that contains the verified time. This parameter
MUST be present.
"type":
A StringOrURI data type that contains an identifier of the type of
evidence of time. This parameter MUST be present.
"iss":
A StringOrURI data type that contains an identifier of the entity that
issued the evidence of time. This parameter MUST be present.
"id":
A String data type that contains an unique identifier assigned to the
evidence of time. Inclusion of this parameter is OPTIONAL.
"hash":
A Base64Binary data type that contains the hash value of the validated
evidence of time. Inclusion of this parameter is OPTIONAL.
"val":
An [Object<PolicyValidation>] data type that contains an array of
results of the time evidence validation according to defined validation
procedures. Inclusion of this parameter is OPTIONAL.
"ext":
A MAP<String> data type that provides additional claims related to
the target signature. Extension claims are added at the discretion of the
SVT issuer; however, extension claims MUST follow any
conventions defined in a profile of this specification (see ). Inclusion of this parameter is
OPTIONAL.
CertReference Claims Object ClassThe signer_cert_ref parameter in the Signature object class uses the CertReference object
class. The CertReference object references a single X.509 certificate or a X.509
certification path either by providing the certificate data or by providing hash
references for certificates that can be located in the target electronic signature, and
it contains the following parameters:
"type":
A StringOrURI data type that contains an identifier of the type of
reference. The type identifier MUST be one of the
identifiers defined below, an identifier specified by the selected profile,
or a URI identifier. This parameter MUST be present.
"ref":
A [String] data type that contains an array of string parameters
according to conventions defined by the type identifier. At least one
parameter MUST be present.
The following type identifiers are defined:
"chain":
The ref contains an array of Base64-encoded X.509 certificates . The certificates MUST be provided in the
order starting with the end entity certificate. Any following certificate
must be able to validate the signature on the previous certificate in the
array.
"chain_hash":
The ref contains an array of one or more Base64-encoded hash values
where each hash value is a hash over a X.509 certificate used to validate the signature. The certificates
MUST be provided in the order starting with the end entity
certificate. Any following certificate must be able to validate the
signature on the previous certificate in the array. This option MUST NOT be used unless all hashed certificates are present in the target
electronic signature.
Note: All certificates referenced using the identifiers above are X.509 certificates.
Profiles of this specification MAY define alternative types of public key containers;
however, a major function of these referenced certificates is not just to reference
the public key but also to provide the subject name of the signer. It is therefore
important for the full function of an SVT that the referenced public key container also
provides the means to identify the signer.SVT JOSE HeaderThe SVT JWT MUST contain the following JSON Object Signing and Encryption (JOSE) header parameters in accordance with
:
"typ":
This parameter MUST have the string value "JWT" (upper
case).
"alg":
This parameter identifies the algorithm used to sign the SVT JWT. The
algorithm identifier MUST be specified in or the IANA "JSON Web Signature and Encryption Algorithms"
registry . The specified signature hash
algorithm MUST be identical to the hash algorithm specified in
the hash_algo parameter of the SigValidation object within the sig_val_claims
claim.
The SVT header MUST contain a public key or a reference to a public key used to verify the signature on the SVT in accordance with . Each profile, as discussed in , MUST define the requirements for how the key or key reference is included in the header.ProfilesEach signed document and signature type will have to define the precise content and
use of several claims in the SVT.At a minimum, each profile MUST define:
The identifier of the profile
How to reference the Signed Data content of the signed document
How to reference the target electronic signature and the Signed Bytes of the signature
How to reference certificates supporting each electronic signature
How to include public keys or references to public keys in the SVT
Whether each electronic signature is supported by a single SVT, or one SVT may support multiple electronic signatures of the same document
A profile MAY also define:
Explicit information on how to perform signature validation based on an SVT
How to attach an SVT to an electronic signature or signed document
Defined ProfilesThe following profiles are defined in appendixes of this document:
:
XML Signature Profile
:
PDF Signature Profile
:
JWS Profile
Other documents MAY define other profiles that MAY complement, amend, or supersede these profiles.Signature Verification with an SVTSignature verification based on an SVT MUST follow these steps:
Locate all available SVTs available for the signed document that are relevant for the target electronic signature.
Select the most recent SVT that can be successfully validated and meets the requirement of the relying party.
Verify the integrity of the signature and the Signed Bytes of the target electronic signature using the sig_ref claim.
Verify that the Signed Data reference in the original electronic signature matches the reference values in the sig_data_ref claim.
Verify the integrity of referenced Signed Data using provided hash values in the sig_data_ref claim.
Obtain the verified certificates supporting the asserted electronic signature verification through the signer_cert_ref claim.
Verify that signature validation policy results satisfy the requirements of the relying party.
Verify that verified time results satisfy the context for the use of the signed document.
After successfully performing these steps, signature validity is established as well as
the trusted signer certificate binding the identity of the signer to the electronic
signature.IANA ConsiderationsClaim Names RegistrationIANA has registered the "sig_val_claims" claim name in the "JSON Web Token Claims" registry established by .Registry Contents
Claim Name:
sig_val_claims
Claim Description:
Signature Validation Token
Change Controller:
IESG
Specification Document(s):
of RFC 9321
Header Parameter Names RegistrationIANA has registered the "svt" Header Parameter in the "JSON Web Signature and Encryption Header Parameters" registry established by .Registry Contents
Header Parameter Name:
svt
Header Parameter Description:
Signature Validation Token
Header Parameter Usage Location(s):
JWS
Change Controller:
IESG
Specification Document(s):
of RFC 9321
Security ConsiderationsLevel of RelianceAn SVT allows a signature verifier to still validate the original signature using
the original signature data and to use the information in the SVT selectively to
confirm the validity and integrity of the original data, such as confirming the integrity of Signed Data or the validity of the signer's certificate, etc.Another way to use an SVT is to completely rely on the validation conclusion provided
by the SVT and to omit revalidation of the original signature value and original
certificate status checking data.This choice is a decision made by the verifier according to its own policy and risk assessment.However, even when relying on the SVT validation conclusion of an SVT, it is vital to still verify that
the present SVT is correctly associated with the document and signature that is being validated by
validating the hashed reference data in the SVT of the signature, signing certificate chain,
Signed Data, and the Signed Bytes.Aging AlgorithmsEven if the SVT provides protection against algorithms becoming weakened or broken over time, this protection is only valid for as long as the algorithms used to sign the SVT are still considered secure. It is advisable to reissue SVTs in cases where an algorithm protecting the SVT is getting close to its end of life.One way to increase the resistance of algorithms becoming insecure, is to issue multiple SVTs for the same signature with different algorithms and key lengths where one algorithm could still be secure even if the corresponding algorithm used in the alternative SVT is broken.ReferencesNormative ReferencesElectronic Signatures and Infrastructures (ESI); CAdES digital signatures; Part 1: Building blocks and CAdES baseline signaturesETSIv1.1.1Electronic Signatures and Infrastructures (ESI); Procedures for Creation and Validation of AdES Digital Signatures; Part 1: Creation and ValidationETSIv1.1.1JSON Object Signing and Encryption (JOSE)IANADocument management -- Portable document format -- Part 2: PDF 2.0ISOElectronic Signatures and Infrastructures (ESI); PAdES digital signatures; Part 1: Building blocks and PAdES baseline signaturesETSIv1.1.1Key words for use in RFCs to Indicate Requirement LevelsIn 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.Electronic Signature PoliciesThis document defines signature policies for electronic signatures. A signature policy is a set of rules for the creation and validation of an electronic signature, under which the validity of signature can be determined. A given legal/contractual context may recognize a particular signature policy as meeting its requirements. This memo defines an Experimental Protocol for the Internet community.Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)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]Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices FrameworkThis 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.Enhanced Security Services (ESS) Update: Adding CertID Algorithm AgilityIn 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]Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) ProfileThis 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]Cryptographic Message Syntax (CMS)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)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.JSON Web Algorithms (JWA)This specification registers cryptographic algorithms and identifiers to be used with the JSON Web Signature (JWS), JSON Web Encryption (JWE), and JSON Web Key (JWK) specifications. It defines several IANA registries for these identifiers.JSON Web Token (JWT)JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted.Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 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.Additional XML Security Uniform Resource Identifiers (URIs)This document updates and corrects the IANA "XML Security URIs" registry that lists URIs intended for use with XML digital signatures, encryption, canonicalization, and key management. These URIs identify algorithms and types of information. This document also obsoletes and corrects three errata against RFC 6931.Electronic Signatures and Infrastructures (ESI); XAdES digital signatures; Part 1: Building blocks and XAdES baseline signaturesETSIv1.1.1XML Signature Syntax and Processing Version 1.1Latest version available at .Informative ReferencesConcise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data StructuresThis document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON.XML Signature ProfileThis appendix defines a profile for implementing SVTs with a signed XML document and defines the following aspects of SVT usage:
How to include reference data related to XML signatures and XML documents in an SVT
How to add an SVT token to an XML signature
XML documents can have any number of signature elements, signing an arbitrary number of fragments of XML documents. The actual signature element may be included in the signed XML document (enveloped), include the Signed Data (enveloping), or may be separate from the signed content (detached).To provide a generic solution for any type of XML signature, an SVT is added to each XML signature element within the XML signature <ds:Object> element.NotationReferences to XML Elements from XML SchemasWhen referring to elements from the W3C XML Signature namespace
(), the following syntax is used:
<ds:Signature>
When referring to elements from the ETSI XAdES XML Signature namespace
(), the following syntax is used:
<xades:CertDigest>
When referring to elements defined in this specification
(), the following syntax is used:
<svt:Element>
SVT in XML DocumentsWhen SVTs are provided for XML signatures, then one SVT MUST be provided for each XML signature.An SVT embedded within the XML signature element MUST be placed in a <svt:SignatureValidationToken> element as defined in .SignatureValidationToken Signature PropertyThe <svt:SignatureValidationToken> element MUST be placed in a <ds:SignatureProperty> element in accordance with . The <ds:SignatureProperty> element MUST be placed inside a <ds:SignatureProperties> element inside a <ds:Object> element inside a <ds:Signature> element.Note: requires the Target attribute to be present in <ds:SignatureProperty>, referencing the signature targeted by this signature property. If an SVT is added to a signature that does not have an Id attribute, implementations SHOULD add an Id attribute to the <ds:Signature> element and reference that Id in the Target attribute. This Id attribute and Target attribute value matching is required by the standard, but it is redundant in the context of SVT validation as the SVT already contains information that uniquely identifies the target signature. Validation applications SHOULD NOT reject an SVT token because of Id and Target attribute mismatch and MUST rely on matching against a signature using signed information in the SVT itself.The <svt:SignatureValidationToken> element is defined by the following XML Schema:
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
targetNamespace="http://id.swedenconnect.se/svt/1.0/sig-prop/ns"
xmlns:svt="http://id.swedenconnect.se/svt/1.0/sig-prop/ns">
<xs:element name="SignatureValidationToken"
type="svt:SignatureValidationTokenType" />
<xs:complexType name="SignatureValidationTokenType">
<xs:simpleContent>
<xs:extension base="xs:string">
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:schema>
The SVT token MUST be included as a string representation of the SVT JWT. Note that this is the string representation of the JWT without further encoding. The SVT MUST NOT be represented by the Base64-encoded bytes of the JWT string.Example:
<ds:Signature Id="MySignatureId">
...
<ds:Object>
<ds:SignatureProperties>
<ds:SignatureProperty Target="#MySignatureId">
<svt:SignatureValidationToken>
eyJ0eXAiOiJKV1QiLCJhb...2aNZ
</svt:SignatureValidationToken>
</ds:SignatureProperty>
</ds:SignatureProperties>
</ds:Object>
</ds:Signature>
Multiple SVTs in an XML SignatureIf a new SVT is stored in a signature that already contains a previously issued SVT, implementations can choose either to replace the existing SVT or to store the new SVT in addition to the existing SVT.If the new SVT is stored in addition to the old SVT, it SHOULD be stored in a new <ds:SignatureProperty> element inside the existing <ds:SignatureProperties> element where the old SVT is located.For interoperability robustness, signature validation applications MUST be able to handle signatures where the new SVT is located in a new <ds:Object> element.XML Signature SVT ClaimsXML Profile IdentifierWhen this profile is used, the SigValidation object MUST contain a "profile" claim with the value "XML".XML Signature Reference DataThe SVT Signature object MUST contain a "sig_ref" claim (SigReference object) with the following elements:
"id":
The Id-attribute of the XML signature, if present.
"sig_hash":
The hash over the signature value bytes.
"sb_hash":
The hash over the canonicalized <ds:SignedInfo> element
(the bytes the XML signature algorithm has signed to generate the
signature value).
XML Signed Data Reference DataThe SVT Signature object MUST contain one instance of the "sig_data" claim (SignedData object) for each <ds:Reference> element in the <ds:SignedInfo> element. The "sig_data" claim MUST contain the following elements:
"ref":
The value of the URI attribute of the corresponding <ds:Reference>
element.
"hash":
The hash of all bytes that were identified by the corresponding <ds:Reference>
element after applying all identified canonicalization and transformation
algorithms. These are the same bytes that are hashed by the hash value in the
<ds:DigestValue> element inside the <ds:Reference> element.
XML Signer Certificate ReferencesThe SVT Signature object MUST contain a "signer_cert_ref" claim (CertReference object). The "type" parameter of the "signer_cert_ref" claim MUST be either "chain" or "chain_hash".
The "chain" type MUST be used when signature validation was performed using one or more certificates where some or all of the certificates in the chain are not present in the target signature.
The "chain_hash" type MUST be used when signature validation was performed using one or more certificates where all of the certificates are present in the target signature.
JOSE HeaderSVT Signing Key ReferenceThe SVT JOSE header for XML signatures must contain one of the following header parameters in accordance with for storing a reference to the public key used to verify the signature on the SVT:
"x5c":
Holds an X.509 certificate or a chain
of certificates. The certificate holding the public key that
verifies the signature on the SVT MUST be the first
certificate in the chain.
"kid":
A key identifier holding the Base64-encoded hash value of the
certificate that can verify the signature on the SVT. The hash
algorithm MUST be the same hash algorithm used when
signing the SVT as specified by the "alg" Header Parameter.
PDF Signature ProfileThis appendix defines a profile for implementing SVTs with a signed PDF document, and it defines the following aspects of SVT usage:
How to include reference data related to PDF signatures and PDF documents in an SVT.
How to add an SVT token to a PDF document.
PDF document signatures are added as incremental updates to the signed PDF document and signs all data of the PDF document up until the current signature. When more than one signature is added to a PDF document the previous signature is signed by the next signature and can not be updated with additional data after this event.To minimize the impact on PDF documents with multiple signatures and to stay backwards compatible with PDF software that does not understand SVTs, PDF documents add one SVT token for all signatures of the PDF as an extension to a document timestamp added to the signed PDF as an incremental update. This SVT covers all signatures of the signed PDF.SVTs in PDF DocumentsThe SVT for a signed PDF document MAY provide signature validation information about any of the present signatures in the PDF. The SVT MUST contain a separate "sig" claim (Signature object) for each signature on the PDF that is covered by the SVT.An SVT added to a signed PDF document MUST be added to a document timestamp in accordance with ISO 32000-2:2020 .The document timestamp contains an timestamp token (TSTInfo) in EncapsulatedContentInfo of the CMS signature. The SVT MUST be added to the timestamp token (TSTInfo) as an Extension object as defined in .SVT Extension to Timestamp TokensThe SVT extension is an Extension suitable to be included in TSTInfo as defined by .The SVT extension is identified by the Object Identifier (OID) 1.2.752.201.5.2.This extension data (OCTET STRING) holds the bytes of SVT JWT, represented as a UTF-8-encoded string.This extension MUST NOT be marked critical.Note: Extensions in timestamp tokens according to are imported from the definition of the X.509 certificate extensions defined in .PDF Signature SVT ClaimsPDF Profile IdentifierWhen this profile is used, the SigValidation object MUST contain a "profile" claim with the value "PDF".PDF Signature Reference DataThe SVT Signature object MUST contain a "sig_ref" claim (SigReference object) with the following elements:
"id":
Absent or a Null value.
"sig_hash":
The hash over the signature value bytes.
"sb_hash":
The hash over the DER-encoded SignedAttributes in SignerInfo.
PDF Signed Data Reference DataThe SVT Signature object MUST contain one instance of the "sig_data" claim (SignedData object) with the following elements:
"ref":
The string representation of the ByteRange value of the PDF
signature dictionary of the target signature. This is a sequence
of integers separated by space where each integer pair specifies
the start index and length of a byte range.
"hash":
The hash of all bytes identified by the ByteRange value. This
is the concatenation of all byte ranges identified by the
ByteRange value.
PDF Signer Certificate ReferencesThe SVT Signature object MUST contain a "signer_cert_ref" claim (CertReference object). The "type" parameter of the "signer_cert_ref" claim MUST be either "chain" or "chain_hash".
The "chain" type MUST be used when signature validation was performed using one or more certificates where some or all of the certificates in the chain are not present in the target signature.
The "chain_hash" type MUST be used when signature validation was performed using one or more certificates where all of the certificates are present in the target signature.
Note: The referenced signer certificate MUST match any certificates referenced using ESSCertID or ESSCertIDv2 from .JOSE HeaderSVT Signing Key ReferenceThe SVT JOSE header must contain one of the following header parameters in accordance with for storing a reference to the public key used to verify the signature on the SVT:
"x5c":
Holds an X.509 certificate or a chain
of certificates. The certificate holding the public key that
verifies the signature on the SVT MUST be the first
certificate in the chain.
"kid":
A key identifier holding the Base64-encoded hash value of the
certificate that can verify the signature on the SVT. The hash
algorithm MUST be the same hash algorithm used when
signing the SVT as specified by the "alg" Header
Parameter. The referenced certificate SHOULD be the
same certificate that was used to sign the document timestamp that
contains the SVT.
JWS ProfileThis appendix defines a profile for implementing SVTs with a JWS signed payload according to , and it defines the following aspects of SVT usage:
How to include reference data related to JWS signatures in an SVT.
How to add an SVT token to JWS signatures.
A JWS may have one or more signatures, depending on its serialization format, signing the same payload data. A JWS either contains the data to be signed (enveloping) or may sign any externally associated payload data (detached).To provide a generic solution for JWS, an SVT is added to each present signature as a JWS Unprotected Header. If a JWS includes multiple signatures, then each signature includes its own SVT.SVT in JWSAn SVT token MAY be added to any signature of a JWS to support validation of that signature. If more than one signature is present, then each present SVT MUST provide information exclusively related to one associated signature and MUST NOT include information about any other signature in the JWS.Each SVT is stored in its associated signature's "svt" header as defined in ."svt" Header ParameterThe "svt" (Signature Validation Token) Header Parameter is used to contain an array of SVT tokens to support validation of the associated signature. Each SVT token in the array has the format of a JWT as defined in and is stored using its natural string representation without further wrapping or encoding.The "svt" Header Parameter, when used, MUST be included as a JWS Unprotected Header.Note: A JWS Unprotected Header is not supported with JWS Compact Serialization. A consequence of adding an SVT token to a JWS is therefore that JWS JSON Serialization MUST be used either in the form of general JWS JSON Serialization (for one or more signatures) or in the form of flattened JWS JSON Serialization (optionally used when only one signature is present in the JWS).Multiple SVTs in a JWS SignatureIf a new SVT is stored in a signature that already contains a previously issued SVT, implementations can choose either to replace the existing SVT or to store the new SVT in addition to the existing SVT.If a JWS signature already contains an array of SVTs and a new SVT is to be added, then the new SVT MUST be added to the array of SVT tokens in the existing "svt" Header Parameter.JWS Signature SVT ClaimsJWS Profile IdentifierWhen this profile is used, the SigValidation object MUST contain a "profile" claim with the value "JWS".JWS Signature Reference DataThe SVT Signature object MUST contain a "sig_ref" claim (SigReference object) with the following elements:
"sig_hash":
The hash over the associated signature value (the bytes of the
base64url-decoded signature parameter).
"sb_hash":
The hash over all bytes signed by the associated signature
(the JWS Signing Input according to ).
JWS Signed Data Reference DataThe SVT Signature object MUST contain one instance of the "sig_data" claim (SignedData object) with the following elements:
"ref":
This parameter MUST hold one of the
following three possible values:
The explicit string value
"payload" if the signed JWS Payload is embedded in a "payload"
member of the JWS.
The explicit string value "detached" if the JWS signs
detached payload data without explicit reference.
A URI that can be used to identify or fetch the detached
Signed Data. The means to determine the URI for the detached
Signed Data is outside the scope of this specification.
"hash":
The hash over the JWS Payload data bytes (not its
base64url-encoded string representation).
JWS Signer Certificate ReferencesThe SVT Signature object MUST contain a "signer_cert_ref" claim (CertReference object). The "type" parameter of the "signer_cert_ref" claim MUST be either "chain" or "chain_hash".
The "chain" type MUST be used when signature validation was performed using one or more certificates where some or all of the certificates in the chain are not present in the target signature.
The "chain_hash" type MUST be used when signature validation was performed using one or more certificates where all of the certificates are present in the target signature JOSE header using the "x5c" Header Parameter.
SVT JOSE HeaderSVT Signing Key ReferenceThe SVT JOSE header must contain one of the following header
parameters in accordance with for storing
a reference to the public key used to verify the signature on the
SVT:
"x5c":
Holds an X.509 certificate or a chain
of certificates. The certificate holding the public key that
verifies the signature on the SVT MUST be the first
certificate in the chain.
"kid":
A key identifier holding the Base64-encoded hash value of the
certificate that can verify the signature on the SVT. The hash
algorithm MUST be the same hash algorithm used when
signing the SVT as specified by the "alg" Header Parameter.