rfc9321.original   rfc9321.txt 
Network Working Group S. Santesson Independent Submission S. Santesson
Internet-Draft IDsec Solutions Request for Comments: 9321 IDsec Solutions
Intended status: Informational R. Housley Category: Informational R. Housley
Expires: 18 November 2022 Vigil Security ISSN: 2070-1721 Vigil Security
17 May 2022 October 2022
Signature Validation Token Signature Validation Token
draft-santesson-svt-08
Abstract Abstract
Electronic signatures have a limited lifespan with respect to the Electronic signatures have a limited lifespan with respect to the
time period that they can be validated and determined to be time period that they can be validated and determined to be
authentic. The Signature Validation Token (SVT) defined in this authentic. The Signature Validation Token (SVT) defined in this
specification provides evidence that asserts the validity of an specification provides evidence that asserts the validity of an
electronic signature. The SVT is provided by a trusted authority, electronic signature. The SVT is provided by a trusted authority,
which asserts that a particular signature was successfully validated which asserts that a particular signature was successfully validated
according to defined procedures at a certain time. Any future according to defined procedures at a certain time. Any future
validation of that electronic signature can be satisfied by validation of that electronic signature can be satisfied by
validating the SVT without any need to also validate the original validating the SVT without any need to also validate the original
electronic signature or the associated digital certificates. SVT electronic signature or the associated digital certificates. The SVT
supports electronic signatures in CMS, XML, PDF and JSON documents. supports electronic signatures in Cryptographic Message Syntax (CMS),
XML, PDF, and JSON documents.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
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 This is a contribution to the RFC Series, independently of any other
and may be updated, replaced, or obsoleted by other documents at any RFC stream. The RFC Editor has chosen to publish this document at
time. It is inappropriate to use Internet-Drafts as reference its discretion and makes no statement about its value for
material or to cite them other than as "work in progress." 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.
This Internet-Draft will expire on 18 November 2022. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9321.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Definitions
3. Signature Validation Token . . . . . . . . . . . . . . . . . 5 3. Signature Validation Token
3.1. Signature Validation Token Function . . . . . . . . . . . 6 3.1. Signature Validation Token Function
3.2. Signature Validation Token Syntax . . . . . . . . . . . . 7 3.2. Signature Validation Token Syntax
3.2.1. Data Types . . . . . . . . . . . . . . . . . . . . . 7 3.2.1. Data Types
3.2.2. Signature Validation Token JWT Claims . . . . . . . . 8 3.2.2. Signature Validation Token JWT Claims
3.2.3. SigValidation Object Class . . . . . . . . . . . . . 9 3.2.3. SigValidation Object Class
3.2.4. Signature Claims Object Class . . . . . . . . . . . . 10 3.2.4. Signature Claims Object Class
3.2.5. SigReference Claims Object Class . . . . . . . . . . 10 3.2.5. SigReference Claims Object Class
3.2.6. SignedDataReference Claims Object Class . . . . . . . 11 3.2.6. SignedDataReference Claims Object Class
3.2.7. PolicyValidation Claims Object Class . . . . . . . . 11 3.2.7. PolicyValidation Claims Object Class
3.2.8. TimeValidation Claims Object Class . . . . . . . . . 12 3.2.8. TimeValidation Claims Object Class
3.2.9. CertReference Claims Object Class . . . . . . . . . . 13 3.2.9. CertReference Claims Object Class
3.2.10. SVT JOSE Header . . . . . . . . . . . . . . . . . . . 13 3.2.10. SVT JOSE Header
4. Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4. Profiles
4.1. Defined Profiles . . . . . . . . . . . . . . . . . . . . 15 4.1. Defined Profiles
5. Signature Verification with a SVT . . . . . . . . . . . . . . 15 5. Signature Verification with an SVT
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 6. IANA Considerations
6.1. Claim Names Registration . . . . . . . . . . . . . . . . 16 6.1. Claim Names Registration
6.1.1. Registry Contents . . . . . . . . . . . . . . . . . . 16 6.1.1. Registry Contents
6.2. Header Parameter Names Registration . . . . . . . . . . . 16 6.2. Header Parameter Names Registration
6.2.1. Registry Contents . . . . . . . . . . . . . . . . . . 16 6.2.1. Registry Contents
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 7. Security Considerations
7.1. Level of reliance . . . . . . . . . . . . . . . . . . . . 17 7.1. Level of Reliance
7.2. Aging algorithms . . . . . . . . . . . . . . . . . . . . 17 7.2. Aging Algorithms
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 8. References
8.1. Normative References . . . . . . . . . . . . . . . . . . 17 8.1. Normative References
8.2. Informative References . . . . . . . . . . . . . . . . . 19 8.2. Informative References
Appendix A. Appendix: XML signature profile . . . . . . . . . . 19 Appendix A. XML Signature Profile
A.1. Notation . . . . . . . . . . . . . . . . . . . . . . . . 20 A.1. Notation
A.1.1. References to XML Elements from XML Schemas . . . . . 20 A.1.1. References to XML Elements from XML Schemas
A.2. SVT in XML Documents . . . . . . . . . . . . . . . . . . 20 A.2. SVT in XML Documents
A.2.1. SignatureValidationToken Signature Property . . . . . 20 A.2.1. SignatureValidationToken Signature Property
A.2.2. Multiple SVT in an XML signature . . . . . . . . . . 22 A.2.2. Multiple SVTs in an XML Signature
A.3. XML signature SVT Claims . . . . . . . . . . . . . . . . 22 A.3. XML Signature SVT Claims
A.3.1. XML Profile Identifier . . . . . . . . . . . . . . . 22 A.3.1. XML Profile Identifier
A.3.2. XML Signature Reference Data . . . . . . . . . . . . 22 A.3.2. XML Signature Reference Data
A.3.3. XML Signed Data Reference Data . . . . . . . . . . . 23 A.3.3. XML Signed Data Reference Data
A.3.4. XML Signer Certificate References . . . . . . . . . . 23 A.3.4. XML Signer Certificate References
A.4. JOSE Header
A.4. JOSE Header . . . . . . . . . . . . . . . . . . . . . . . 23 A.4.1. SVT Signing Key Reference
A.4.1. SVT Signing Key Reference . . . . . . . . . . . . . . 23 Appendix B. PDF Signature Profile
Appendix B. Appendix: PDF signature profile . . . . . . . . . . 24 B.1. SVTs in PDF Documents
B.1. SVT in PDF Documents . . . . . . . . . . . . . . . . . . 24 B.1.1. SVT Extension to Timestamp Tokens
B.1.1. SVT Extension to Timestamp Tokens . . . . . . . . . . 24 B.2. PDF Signature SVT Claims
B.2. PDF signature SVT Claims . . . . . . . . . . . . . . . . 25 B.2.1. PDF Profile Identifier
B.2.1. PDF Profile Identifier . . . . . . . . . . . . . . . 25 B.2.2. PDF Signature Reference Data
B.2.2. PDF Signature Reference Data . . . . . . . . . . . . 25 B.2.3. PDF Signed Data Reference Data
B.2.3. PDF Signed Data Reference Data . . . . . . . . . . . 25 B.2.4. PDF Signer Certificate References
B.2.4. PDF Signer Certificate References . . . . . . . . . . 25 B.3. JOSE Header
B.3. JOSE Header . . . . . . . . . . . . . . . . . . . . . . . 26 B.3.1. SVT Signing Key Reference
B.3.1. SVT Signing Key Reference . . . . . . . . . . . . . . 26 Appendix C. JWS Profile
Appendix C. Appendix: JWS Profile . . . . . . . . . . . . . . . 26 C.1. SVT in JWS
C.1. SVT in JWS . . . . . . . . . . . . . . . . . . . . . . . 27 C.1.1. "svt" Header Parameter
C.1.1. "svt" Header Parameter . . . . . . . . . . . . . . . 27 C.1.2. Multiple SVTs in a JWS Signature
C.1.2. Multiple SVT in a JWS signature . . . . . . . . . . . 27 C.2. JWS Signature SVT Claims
C.2. JWS signature SVT Claims . . . . . . . . . . . . . . . . 27 C.2.1. JWS Profile Identifier
C.2.1. JWS Profile Identifier . . . . . . . . . . . . . . . 28 C.2.2. JWS Signature Reference Data
C.2.2. JWS Signature Reference Data . . . . . . . . . . . . 28 C.2.3. JWS Signed Data Reference Data
C.2.3. JWS Signed Data Reference Data . . . . . . . . . . . 28 C.2.4. JWS Signer Certificate References
C.2.4. JWS Signer Certificate References . . . . . . . . . . 28 C.3. SVT JOSE Header
C.3. SVT JOSE Header . . . . . . . . . . . . . . . . . . . . . 29 C.3.1. SVT Signing Key Reference
C.3.1. SVT Signing Key Reference . . . . . . . . . . . . . . 29 Appendix D. Schemas
Appendix D. Appendix: Schemas . . . . . . . . . . . . . . . . . 29 D.1. Concise Data Definition Language (CDDL)
D.1. Concise Data Definition Language (CDDL) . . . . . . . . . 29 D.2. JSON Schema
D.2. JSON Schema . . . . . . . . . . . . . . . . . . . . . . . 31 Appendix E. Examples
Appendix E. Appendix: Examples . . . . . . . . . . . . . . . . . 36 Authors' Addresses
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39
1. Introduction 1. Introduction
Electronic signatures have a limited lifespan regarding when they can Electronic signatures have a limited lifespan regarding when they can
be validated and determined to be authentic. Many factors make it be validated and determined to be authentic. Many factors make it
more difficult to validate electronic signatures over time. For more difficult to validate electronic signatures over time. For
example: example:
* Trusted information about the validity of the certificate * Trusted information about the validity of the certificate
containing the signer's public key is not available. containing the signer's public key is not available.
* Trusted information about the date and time when the signature was * Trusted information about the time when the signature was actually
actually created is not available. created is not available.
* Algorithms used to create the electronic signature may no longer * Algorithms used to create the electronic signature may no longer
be considered secure at the time of validation and may therefore be considered secure at the time of validation and may therefore
no longer be available in software libraries. no longer be available in software libraries.
* Services necessary to validate the signature are no longer * Services necessary to validate the signature are no longer
available at the time of validation. available at the time of validation.
* Supporting evidence such as CA certificates, OCSP responses, CRLs, * Supporting evidence such as certification authority (CA)
or timestamps. 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 increases The challenges to validation of an electronic signature increase over
over time, and eventually it may simply be impossible to verify the time, and eventually it may simply be impossible to verify the
signature with a sufficient level of assurance. signature with a sufficient level of assurance.
Existing standards, such as the ETSI XAdES [XADES] profile for XML Existing standards, such as the ETSI XAdES [XADES] profile for XML
signatures [XMLDSIG11], ETSI PAdES [PADES] profile for PDF signatures signatures [XMLDSIG11], ETSI PAdES [PADES] profile for PDF signatures
[ISOPDF2], and ETSI CAdES [CADES] profile for CMS signatures [ISOPDF2], and ETSI CAdES [CADES] profile for CMS signatures
[RFC5652] can be used to extend the time within which a signature can [RFC5652], can be used to extend the time within which a signature
be validated at the cost of significant complexity which involves can be validated at the cost of significant complexity, which
storing and validating significant amounts of external evidence data involves storing and validating significant amounts of external
such as revocation data, signature time stamps and archival time evidence data such as revocation data, signature time stamps, and
stamps. archival time stamps.
The Signature Validation token (SVT) defined in this specification The Signature Validation Token (SVT) defined in this specification
takes a trusted signature validation process as an input and takes a trusted signature validation process as an input and
preserves the validation result for the associated signature and preserves the validation result for the associated signature and
signed document. The SVT asserts that a particular electronic signed document. The SVT asserts that a particular electronic
signature was successfully validated by a trusted authority according signature was successfully validated by a trusted authority according
to defined procedures at a certain date and time. Those procedures to defined procedures at a certain time. Those procedures MUST
MUST include checks that the signature match the signed document, include checks that the signature match the signed document, checks
checks that the signature can be validated by the signing certificate that the signature can be validated by the signing certificate, and
and checks that the signing certificate pass certificate path checks that the signing certificate pass certificate path validation
validation [RFC5280]. Those procedures MAY also include checks [RFC5280]. Those procedures MAY also include checks associated with
associated with a particular trust policy such as that an acceptable a particular trust policy such as that an acceptable certificate
certificate policy [RFC5280] [RFC3647] was used to issue the signer's policy [RFC5280] [RFC3647] was used to issue the signer's certificate
certificate and checks that an acceptable signature policy was used and checks that an acceptable signature policy was used by the signer
by the signer [RFC3125]. [RFC3125].
Once the SVT is issued by a trusted authority, any future validation Once the SVT is issued by a trusted authority, any future validation
of that electronic signature can be satisfied by validating the SVT, of that electronic signature can be satisfied by validating the SVT
without any need to also re-validate the original electronic without any need to also revalidate the original electronic
signature. signature.
As SVT is used to preserve validation result obtained through As the SVT is used to preserve validation results obtained through
applying existing standards for signature validation, it is applying existing standards for signature validation, it is
complementary to and not a replacement for such standards, including complementary to and not a replacement for such standards, including
the ETSI standards for long term validation listed above. SVT do the ETSI standards for long-term validation listed above. The SVT
however have the potentially positive effect that it may does, however, have the potentially positive effect that it may
significantly reduce the need to apply complex long-term validation significantly reduce the need to apply complex long-term validation
and preservation techniques for signature validation if an SVT is and preservation techniques for signature validation if an SVT is
issued and applied to the signed document at an early stage where the issued and applied to the signed document at an early stage where the
signature can be validated without support of large amounts of signature can be validated without support of large amounts of
external evidence. The use of SVT may therefore drastically reduce external evidence. The use of SVTs may therefore drastically reduce
the complexity of re-validation of old archived electronic the complexity of revalidation of old archived electronic signatures.
signatures.
The SVT can be signed with private keys and algorithms that provide The SVT can be signed with private keys and algorithms that provide
confidence for a considerable time period. In fact, multiple SVTs confidence for a considerable time period. In fact, multiple SVTs
can be used to offer greater assurance. For example, one SVT could 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 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 elliptic curve, and a third one with a quantum safe digital signature
algorithm to protect against advances in computing power and algorithm to protect against advances in computing power and
cryptanalytic capabilities. Further, the trusted authority can add cryptanalytic capabilities. Further, the trusted authority can add
additional SVTs in the future using fresh private keys and signatures additional SVTs in the future using fresh private keys and signatures
to extend the lifetime of the, if necessary. to extend the lifetime of the SVTs if necessary.
2. Definitions 2. Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
This document use the following terms: This document use the following terms:
* Signed Data -- The data covered by a particular electronic Signed Data: The data covered by a particular electronic signature.
signature. This is typically equivalent to the signed content of This is typically equivalent to the signed content of a document,
a document, and it represents the data that the signer intended to and it represents the data that the signer intended to sign. In
sign. In some cases, such as in some XML signatures, the signed some cases, such as in some XML signatures, the Signed Data can be
data can be the collection of several data fragments each the collection of several data fragments each referenced by the
referenced by the signature. In the case of PDF, this is the data signature. In the case of PDF, this is the data covered by the
covered by the "ByteRange" parameter in the signature dictionary. "ByteRange" parameter in the signature dictionary. In JSON Web
In JWS, this is the unencoded payload data (before base64url Signature (JWS), this is the unencoded payload data (before
encoding). base64url encoding).
* Signed Bytes -- These are the actual bytes of data that were Signed Bytes: These are the actual bytes of data that were hashed
hashed and signed by the digital signature algorithm. In most and signed by the digital signature algorithm. In most cases,
cases, this is not the actual Signed Data, but a collection of this is not the actual Signed Data but a collection of signature
signature metadata that includes references (hash) of the Signed metadata that includes references (hash) of the Signed Data as
Data as well as information about algorithms and other data bound well as information about algorithms and other data bound to a
to a signature. In XML, this is the canonicalized SignedInfo signature. In XML, this is the canonicalized SignedInfo element.
element. In CMS and PDF signatures, this is the DER-encoded In CMS and PDF signatures, this is the DER-encoded
SignedAttributes structure. In JWS, this is the protected header SignedAttributes structure. In JWS, this is the protected header
and payload data formatted according to [RFC7515]. and payload data formatted according to [RFC7515].
When these terms are used as defined in this section, they appear When these terms are used as defined in this section, they appear
with a capitalized first letter. with a capitalized first letter.
3. Signature Validation Token 3. Signature Validation Token
3.1. Signature Validation Token Function 3.1. Signature Validation Token Function
Signature Validation Token (SVT) is created by a trusted service to The Signature Validation Token (SVT) is created by a trusted service
assert evidence of successful electronic signature validation using a to assert evidence of successful electronic signature validation
well-defined and trustworthy signature validation process. The SVT using a well-defined and trustworthy signature validation process.
binds the validation result to the validated signature, the document The SVT binds the validation result to the validated signature, the
signed by the signature and the certificate of the signer. This document signed by the signature, and the certificate of the signer.
allows a relying party to verify the validity of a signed document This allows a relying party to verify the validity of a signed
without having to re-validate the original signature or to re-use any document without having to revalidate the original signature or to
of its associated cryptographic algorithms for as long as the SVT reuse any of its associated cryptographic algorithms for as long as
itself can be validated. The SVT achieves this by binding the the SVT itself can be validated. The SVT achieves this by binding
following information to a specific electronic signature: the following information to a specific electronic signature:
* A unique identification of the electronic signature. * A unique identification of the electronic signature.
* The data and metadata signed by the electronic signature. * The data and metadata signed by the electronic signature.
* The signer's certificate that was validated as part of electronic * The signer's certificate that was validated as part of electronic
signature verification. signature verification.
* The certification path that was used to validate the signer's * The certification path that was used to validate the signer's
certificate. certificate.
* An assertion providing evidence of that the signature was * An assertion providing evidence of signature verification, the
verified, the date and time the verification was performed, the time the verification was performed, the procedures used to verify
procedures used to verify the electronic signature, and the the electronic signature, and the outcome of the verification.
outcome of the verification.
* An assertion providing evidence of the date and time at which the * An assertion providing evidence of the time at which the signature
signature is known to have existed, the procedures used to is known to have existed, the procedures used to validate the time
validate the date and time of existence, and the outcome of the of existence, and the outcome of the validation.
validation.
The SVT aims to support long term validation that can be further The SVT aims to support long-term validation that can be further
extended into the future by applying the following strategies: extended into the future by applying the following strategies:
* By using secure algorithms with long life exepectancy when signing * by using secure algorithms with long life expectancy when signing
the SVT. the SVT
* By re-issuing the SVT before it becomes insecure or is considered * by reissuing the SVT before it becomes insecure or is considered
expired. expired
* Optionally, by issuing multipple SVT:s with different algorithms * optionally, by issuing multiple SVTs with different algorithms to
to provide redundancy in case one algorithm is broken. provide redundancy in case one algorithm is broken
3.2. Signature Validation Token Syntax 3.2. Signature Validation Token Syntax
The SVT is carried in a JSON Web Token (JWT) as defined in [RFC7519]. The SVT is carried in a JSON Web Token (JWT) as defined in [RFC7519].
3.2.1. Data Types 3.2.1. Data Types
The contents of claims in an SVT are specified using the following The contents of claims in an SVT are specified using the following
data types: data types:
* String -- JSON Data Type of string that contains an arbitrary case String: JSON Data Type of string that contains an arbitrary case-
sensitive string value. sensitive string value.
* Base64Binary -- JSON Data Type of string that contains of Base64 Base64Binary: JSON Data Type of string that contains a
encoded byte array of binary data. Base64-encoded byte array of binary data.
* StringOrURI -- JSON Data Type of string that contains an arbitrary StringOrURI: JSON Data Type of string that contains an arbitrary
string or an URI as defined in [RFC7519], which REQUIRES a value string or a URI as defined in [RFC7519]. It is REQUIRED to
containing the colon character (":") to be a URI. contain the colon character (":") to be a URI.
* URI -- JSON Data Type of string that contains an URI as defined in URI: JSON Data Type of string that contains a URI as defined in
[RFC7519]. [RFC7519].
* Integer -- JSON Data Type of number that contains a 32-bit signed Integer: JSON Data Type of number that contains a 32-bit signed
integer value (from -2^31 to 2^31-1). integer value (from -2^31 to 2^31-1).
* Long -- JSON Data Type of number that contains a 64-bit signed Long: JSON Data Type of number that contains a 64-bit signed integer
integer value (from -2^63 to 2^63-1). value (from -2^63 to 2^63-1).
* NumericDate -- JSON Data Type of number that contains a data as NumericDate: JSON Data Type of number that contains data as defined
defined in [RFC7519], which is the number of seconds from in [RFC7519], which is the number of seconds from
1970-01-01T00:00:00Z UTC until the specified UTC date/time, 1970-01-01T00:00:00Z UTC until the specified UTC date/time,
ignoring leap seconds. ignoring leap seconds.
* Boolean -- JSON Data Type of boolean that contains explicit value Boolean: JSON Data Type of boolean that contains the explicit value
of true or false. of true or false.
* Object<Class> -- A JSON object holding a claims object of a class Object<Class>: A JSON object holding a claims object of a class
defined in this specification (see Section 3.2.2). defined in this specification (see Section 3.2.2).
* Map<Type> -- A JSON object with name-value pairs where the value Map<Type>: A JSON object with name-value pairs where the value is an
is an object of the specified Type in the notation. For example, object of the specified Type in the notation. For example,
Map<String> is a JSON object with name value pairs where all Map<String> is a JSON object with name-value pairs where all
values are of type String. values are of type String.
* Array -- A JSON array of a specific data type as defined in this Array: A JSON array of a specific data type as defined in this
section. An array is expressed in this specification by square section. An array is expressed in this specification by square
brackets. For example, [String] indicates an array of String brackets. For example, [String] indicates an array of String
values, and [Object<DocHash>] indicates an array of DocHash values, and [Object<DocHash>] indicates an array of DocHash
objects. objects.
* Null -- A JSON null that represents an absent value. A claim with Null: A JSON null that represents an absent value. A claim with a
a null value is equivalent with an absent claim. null value is equivalent with an absent claim.
3.2.2. Signature Validation Token JWT Claims 3.2.2. Signature Validation Token JWT Claims
The SVT MUST contain only JWT claims in the following list: The SVT MUST contain only JWT claims in the following list:
* jti -- A String data type that is a "JWT ID" registered claim "jti": A String data type that is a "JWT ID" registered claim
according to [RFC7519]. It is RECOMMENDED that the identifier according to [RFC7519]. It is RECOMMENDED that the identifier
holds a hexadecimal string representation of a 128-bit unsigned holds a hexadecimal string representation of a 128-bit unsigned
integer. A SVT MUST contain one "JWT ID" claim. integer. An SVT MUST contain one "JWT ID" claim.
* iss -- A StringOrURI data type that is an "Issuer" registered
claim according to [RFC7519], which is an arbitrary unique
identifier of the SVT issuer. This value SHOULD have the value of
an URI based on a domain owned by the issuer. A SVT MUST contain
one "Issuer" claim.
* iat -- A NumericDate data type that is an "Issued At" registered "iss": A StringOrURI data type that is an "Issuer" registered claim
claim according to [RFC7519], which expresses the date and time according to [RFC7519], which is an arbitrary unique identifier of
when this SVT was issued. A SVT MUST contain one "Issued At" 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. claim.
* aud -- A [StringOrURI] data type or a StringOrURI data type that "iat": A NumericDate data type that is an "Issued At" registered
is an "Audience" registered claim according to [RFC7519]. The claim according to [RFC7519], 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 [RFC7519]. The
audience claim is an array of one or more identifiers, identifying audience claim is an array of one or more identifiers, identifying
intended recipients of the SVT. Each identifier MAY identify a intended recipients of the SVT. Each identifier MAY identify a
single entity, a group of entities or a common policy adopted by a single entity, a group of entities, or a common policy adopted by
group of entities. If only one value is provided it MAY be 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 provided as a single StringOrURI data type value instead of as an
array of values. Inclusion of the "Audience" claim in a SVT is array of values. Inclusion of the "Audience" claim in an SVT is
OPTIONAL. OPTIONAL.
* exp -- A NumericDate data type that is an "Expiration Time" "exp": A NumericDate data type that is an "Expiration Time"
registered claim according to [RFC7519], which expresses the date registered claim according to [RFC7519], which expresses the time
and time when services and responsibilities related to this SVT is when services and responsibilities related to this SVT are no
no longer provided by the SVT issuer. The precise meaning of the longer provided by the SVT issuer. The precise meaning of the
expiration time claim is defined by local policies. See expiration time claim is defined by local policies. See
implementation note below. Inclusion of the "Expiration Time" implementation note below. Inclusion of the "Expiration Time"
claim in a SVT is OPTIONAL. claim in an SVT is OPTIONAL.
* sig_val_claims -- A Object<SigValidation> data type that contains "sig_val_claims": An Object<SigValidation> data type that contains
signature validation claims for this SVT extending the standard signature validation claims for this SVT extending the standard
registered JTW claims above. A SVT MUST contain one registered JWT claims above. An SVT MUST contain one
sig_val_claims claim. sig_val_claims claim.
Note: An SVT asserts that a particular validation process was Note: An SVT asserts that a particular validation process was
undertaken at a stated date and time. This fact never changes and undertaken at a stated time. This fact never changes and never
never expires. However, some other aspects of the SVT such as expires. However, some other aspects of the SVT such as liability
liability for false claims or service provision related to a specific for false claims or service provision related to a specific SVT may
SVT may expire after a certain period of time, such as a service expire after a certain period of time, such as a service where an old
where an old SVT can be upgraded to a new SVT signed with fresh keys SVT can be upgraded to a new SVT signed with fresh keys and
and algorithms. algorithms.
3.2.3. SigValidation Object Class 3.2.3. SigValidation Object Class
The sig_val_claims JWT claim uses the SigValidation object class. A The sig_val_claims JWT claim uses the SigValidation object class. A
SigValidation object holds all custom claims, and a SigValidation SigValidation object holds all custom claims, and a SigValidation
object contains the following parameters: object contains the following parameters:
* ver -- A String data type representing the version. This "ver": A String data type representing the version. This parameter
parameter MUST be present, and the version in this specification MUST be present and the version in this specification indicated by
indicated by the value "1.0". the value "1.0".
* profile -- A StringOrURI data type representing the name of a "profile": A StringOrURI data type representing the name of a
profile that defines conventions followed for specific claims and profile that defines conventions followed for specific claims and
any extension points used by the SVT issuer. This parameter MUST any extension points used by the SVT issuer. This parameter MUST
be present. be present.
* hash_algo -- A URI data type that identifies the hash algorithm "hash_algo": A URI data type that identifies the hash algorithm used
used to compute the hash values within the SVT. The URI to compute the hash values within the SVT. The URI identifier
identifier MUST be one defined in [RFC6931] or in the IANA MUST be one defined in [RFC9231] or in the IANA registry defined
registry defined by this specification. This parameter MUST be by this specification. This parameter MUST be present.
present.
* sig -- A [Object<Signature>] data type that gives information "sig": An [Object<Signature>] data type that gives information about
about validated electronic signatures as an array of Signature validated electronic signatures as an array of Signature objects.
objects. If the SVT contains signature validation evidence for If the SVT contains signature validation evidence for more than
more than one signature, then each signature is represented by a one signature, then each signature is represented by a separate
separate Signature object. At least one Signature object MUST be Signature object. At least one Signature object MUST be present.
present.
* ext -- A Map<String> data type that provides additional claims "ext": A Map<String> data type that provides additional claims
related to the SVT. Extension claims are added at the discretion related to the SVT. Extension claims are added at the discretion
of the SVT issuer; however, extension claims MUST follow any of the SVT issuer; however, extension claims MUST follow any
conventions defined in a profile of this specification (see conventions defined in a profile of this specification (see
Section 4). Inclusion of this parameter is OPTIONAL. Section 4). Inclusion of this parameter is OPTIONAL.
3.2.4. Signature Claims Object Class 3.2.4. Signature Claims Object Class
The sig parameter in the SigValidation object class uses the The sig parameter in the SigValidation object class uses the
Signature object class. The Signature object contains claims related Signature object class. The Signature object contains claims related
to signature validation evidence for one signature, and it contains to signature validation evidence for one signature, and it contains
the following parameters: the following parameters:
* sig_ref -- A Object<SigReference> data type that contains "sig_ref": An Object<SigReference> data type that contains reference
reference information identifying the target signature. This information identifying the target signature. This parameter MUST
parameter MUST be present. be present.
* sig_data_ref -- A [Object<SignedDataReference>] data type that "sig_data_ref": An [Object<SignedDataReference>] data type that
contains an array of references to Signed Data that was signed by contains an array of references to Signed Data that was signed by
the target electronic signature. At least one SignedDataReference the target electronic signature. At least one SignedDataReference
object MUST be present. object MUST be present.
* signer_cert_ref -- A Object<CertReference> data type that "signer_cert_ref": An Object<CertReference> data type that
references the signer's certificate and optionally reference to a references the signer's certificate and optionally references a
supporting certification path that was used to verify the target supporting certification path that was used to verify the target
electronic signature. This parameter MUST be present. electronic signature. This parameter MUST be present.
* sig_val -- A [Object<PolicyValidation>] data type that contains an "sig_val": An [Object<PolicyValidation>] data type that contains an
array of results of signature verification according to defined array of results of signature verification according to defined
procedures. At least one PolicyValidation object MUST be present. procedures. At least one PolicyValidation object MUST be present.
* time_val -- A [Object<TimeValidation>] data type that contains an "time_val": An [Object<TimeValidation>] data type that contains an
array of time verification results that the target signature has array of time verification results showing that the target
existed at a specific date and time in the past. Inclusion of signature has existed at a specific time in the past. Inclusion
this parameter is OPTIONAL. of this parameter is OPTIONAL.
* ext -- A MAP<String> data type that provides additional claims "ext": A MAP<String> data type that provides additional claims
related to the target signature. Extension claims are added at related to the target signature. Extension claims are added at
the discretion of the SVT Issuer; however, extension claims MUST the discretion of the SVT issuer; however, extension claims MUST
follow any conventions defined in a profile of this specification follow any conventions defined in a profile of this specification
(see Section 4). Inclusion of this parameter is OPTIONAL. (see Section 4). Inclusion of this parameter is OPTIONAL.
3.2.5. SigReference Claims Object Class 3.2.5. SigReference Claims Object Class
The sig_ref parameter in the Signature object class uses the The sig_ref parameter in the Signature object class uses the
SigReference object class. The SigReference object provides SigReference object class. The SigReference object provides
information used to match the Signature claims object to a specific information used to match the Signature claims object to a specific
target electronic signature and to verify the integrity of the target target electronic signature and to verify the integrity of the target
signature value and Signed Bytes, and it contains the following signature value and Signed Bytes, and it contains the following
parameters: parameters:
* id -- A String data type that contains an identifier assigned to "id": A String data type that contains an identifier assigned to the
the target signature. Inclusion of this parameter is OPTIONAL. target signature. Inclusion of this parameter is OPTIONAL.
* sig_hash -- A Base64Binary data type that contains a hash value of "sig_hash": A Base64Binary data type that contains a hash value of
the target electronic signature value. This parameter MUST be the target electronic signature value. This parameter MUST be
present. present.
* sb_hash -- A Base64Binary data type that contains a hash value of "sb_hash": A Base64Binary data type that contains a hash value of
the Signed Bytes of the target electronic signature. This the Signed Bytes of the target electronic signature. This
parameter MUST be present. parameter MUST be present.
3.2.6. SignedDataReference Claims Object Class 3.2.6. SignedDataReference Claims Object Class
The sig_data_ref parameter in the Signature object class uses the The sig_data_ref parameter in the Signature object class uses the
SignedDataReference object class. The SignedDataReference object SignedDataReference object class. The SignedDataReference object
provides information used to verify the target electronic signature provides information used to verify the target electronic signature
references to Signed Data as well as to verify the integrity of all 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 data that is signed by the target signature, and it contains the
following parameters: following parameters:
* ref -- A String data type that contains a reference identifier for "ref": A String data type that contains a reference identifier for
the data or data fragment covered by the target electronic the data or data fragment covered by the target electronic
signature. This parameter MUST be present. signature. This parameter MUST be present.
* hash -- A Base64Binary data type that contains the hash value for "hash": A Base64Binary data type that contains the hash value for
the data covered by the target electronic signature. This the data covered by the target electronic signature. This
parameter MUST be present. parameter MUST be present.
3.2.7. PolicyValidation Claims Object Class 3.2.7. PolicyValidation Claims Object Class
The sig_val parameter in the Signature object class uses the The sig_val parameter in the Signature object class uses the
PolicyValidation object class. The PolicyValidation object provides PolicyValidation object class. The PolicyValidation object provides
information about the result of a validation process according to a information about the result of a validation process according to a
spefific policy, and it contains the following parameters: specific policy, and it contains the following parameters:
* pol -- A StringOrURI data type that contains the identifier of the "pol": A StringOrURI data type that contains the identifier of the
policy governing the electronic signature verification process. policy governing the electronic signature verification process.
This parameter MUST be present. This parameter MUST be present.
* res -- A String data type that contains the result of the "res": A String data type that contains the result of the electronic
electronic signature verification process. The value MUST be one signature verification process. The value MUST be one of
of "PASSED", "FAILED" or "INDETERMINATE" as defined by "PASSED", "FAILED", or "INDETERMINATE" as defined by
[ETSI319102-1]. This parameter MUST be present. [ETSI319102-1]. This parameter MUST be present.
* msg -- A String data type that contains a message describing the "msg": A String data type that contains a message describing the
result. Inclusion of this parameter is OPTIONAL. result. Inclusion of this parameter is OPTIONAL.
* ext -- A MAP<String> data type that provides additional claims "ext": A MAP<String> data type that provides additional claims
related to the target signature. Extension claims are added at related to the target signature. Extension claims are added at
the discretion of the SVT Issuer; however, extension claims MUST the discretion of the SVT issuer; however, extension claims MUST
follow any conventions defined in a profile of this specification follow any conventions defined in a profile of this specification
(see Section 4). Inclusion of this parameter is OPTIONAL. (see Section 4). Inclusion of this parameter is OPTIONAL.
3.2.8. TimeValidation Claims Object Class 3.2.8. TimeValidation Claims Object Class
The time_val parameter in the Signature object class uses the The time_val parameter in the Signature object class uses the
TimeValidation object class. The TimeValidation claims object TimeValidation object class. The TimeValidation claims object
provides information about the result of validating evidence of time provides information about the result of validating evidence of time
asserting that the target signature existed at a particular date and asserting that the target signature existed at a particular time in
time in the past. Evidence of time is typically a timestamp the past. Evidence of time is typically a timestamp according to
according to [RFC3161] but other types of evidence may be used such [RFC3161], but other types of evidence may be used such as a
as a previously issued SVT for this signature. The TimeValidation previously issued SVT for this signature. The TimeValidation claims
claims object contains the following parameters: object contains the following parameters:
* time -- A NumericDate data type that contains the verified time. "time": A NumericDate data type that contains the verified time.
This parameter MUST be present. This parameter MUST be present.
* type -- A StringOrURI data type that contains an identifier of the "type": A StringOrURI data type that contains an identifier of the
type of evidence of time. This parameter MUST be present. type of evidence of time. This parameter MUST be present.
* iss -- A StringOrURI data type that contains an identifier of the "iss": A StringOrURI data type that contains an identifier of the
entity that issued the evidence of time. This parameter MUST be entity that issued the evidence of time. This parameter MUST be
present. present.
* id -- A String data type that contains an unique identifier "id": A String data type that contains an unique identifier assigned
assigned to the evidence of time. Inclusion of this parameter is to the evidence of time. Inclusion of this parameter is OPTIONAL.
OPTIONAL.
* hash -- A Base64Binary data type that contains the hash value of "hash": A Base64Binary data type that contains the hash value of the
the validated evidence of time. Inclusion of this parameter is validated evidence of time. Inclusion of this parameter is
OPTIONAL. OPTIONAL.
* val -- A [Object<PolicyValidation>] data type that contains an "val": An [Object<PolicyValidation>] data type that contains an
array of results of the time evidence validation according to array of results of the time evidence validation according to
defined validation procedures. Inclusion of this parameter is defined validation procedures. Inclusion of this parameter is
OPTIONAL. OPTIONAL.
* ext -- A MAP<String> data type that provides additional claims "ext": A MAP<String> data type that provides additional claims
related to the target signature. Extension claims are added at related to the target signature. Extension claims are added at
the discretion of the SVT Issuer; however, extension claims MUST the discretion of the SVT issuer; however, extension claims MUST
follow any conventions defined in a profile of this specification follow any conventions defined in a profile of this specification
(see Section 4). Inclusion of this parameter is OPTIONAL. (see Section 4). Inclusion of this parameter is OPTIONAL.
3.2.9. CertReference Claims Object Class 3.2.9. CertReference Claims Object Class
The signer_cert_ref parameter in the Signature object class uses the The signer_cert_ref parameter in the Signature object class uses the
CertReference object class. The CertReference object references a CertReference object class. The CertReference object references a
single X.509 certificate or a X.509 certification path, either by single X.509 certificate or a X.509 certification path either by
providing the certificate data or by providing hash references for providing the certificate data or by providing hash references for
certificates that can be located in the target electronic signature, certificates that can be located in the target electronic signature,
and it contains the following parameters: and it contains the following parameters:
* type -- A StringOrURI data type that contains an identifier of the "type": A StringOrURI data type that contains an identifier of the
type of reference. The type identifier MUST be one of the type of reference. The type identifier MUST be one of the
identifiers defined below, an identifier specified by the selected identifiers defined below, an identifier specified by the selected
profile, or a URI identifier. This parameter MUST be present. profile, or a URI identifier. This parameter MUST be present.
* ref -- A [String] data type that contains an array of string "ref": A [String] data type that contains an array of string
parameters according to conventions defined by the type parameters according to conventions defined by the type
identifier. At least one parameter MUST be present. identifier. At least one parameter MUST be present.
The following type identifiers are defined: The following type identifiers are defined:
* chain -- The ref contains an array of Base64 encoded X.509 "chain": The ref contains an array of Base64-encoded X.509
certificates [RFC5280]. The certificates MUST be provided in the certificates [RFC5280]. The certificates MUST be provided in the
order starting with the end entity certificate. Any following order starting with the end entity certificate. Any following
certificate must be able to validate the signature on the previous certificate must be able to validate the signature on the previous
certificate in the array. certificate in the array.
* chain_hash -- The ref contains an array of one or more Base64 "chain_hash": The ref contains an array of one or more
encoded hash values where each hash value is a hash over a X.509 Base64-encoded hash values where each hash value is a hash over a
certificate [RFC5280] used to validate the signature. The X.509 certificate [RFC5280] used to validate the signature. The
certificates MUST be provided in the order starting with the end certificates MUST be provided in the order starting with the end
entity certificate. Any following certificate must be able to entity certificate. Any following certificate must be able to
validate the signature on the previous certificate in the array. validate the signature on the previous certificate in the array.
This option MUST NOT be used unless all hashed certificates are This option MUST NOT be used unless all hashed certificates are
present in the target electronic signature. present in the target electronic signature.
Note: All certificates referenced using the identifiers above are Note: All certificates referenced using the identifiers above are
X.509 certificates. Profiles of this specification MAY define X.509 certificates. Profiles of this specification MAY define
alternative types of public key containers; however, a major function alternative types of public key containers; however, a major function
of these referenced certificates is not just to reference the public of these referenced certificates is not just to reference the public
key, but also to provide the subject name of the signer. It is key but also to provide the subject name of the signer. It is
therefore important for the full function of an SVT that the therefore important for the full function of an SVT that the
referenced public key container also provides the means to identify referenced public key container also provides the means to identify
of the signer. the signer.
3.2.10. SVT JOSE Header 3.2.10. SVT JOSE Header
The SVT JWT MUST contain the following JOSE header parameters in The SVT JWT MUST contain the following JSON Object Signing and
accordance with Section 5 of [RFC7519]: Encryption (JOSE) header parameters in accordance with Section 5 of
[RFC7519]:
* typ -- This parameter MUST have the string value "JWT" (upper "typ": This parameter MUST have the string value "JWT" (upper case).
case).
* alg -- This parameter identifies the algorithm used to sign the "alg": This parameter identifies the algorithm used to sign the SVT
SVT JWT. The algorithm identifier MUST be specified in [RFC7518] JWT. The algorithm identifier MUST be specified in [RFC7518] or
or the IANA JSON Web Signature and Encryption Algorithms Registry the IANA "JSON Web Signature and Encryption Algorithms" registry
[ add a ref ]. The specified signature hash algorithm MUST be [IANA-JOSE-REG]. The specified signature hash algorithm MUST be
identical to the hash algorithm specified in the hash_algo identical to the hash algorithm specified in the hash_algo
parameter of the SigValidation object within the sig_val_claims parameter of the SigValidation object within the sig_val_claims
claim. claim.
The SVT header MUST contain a public key or a reference to a public 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 key used to verify the signature on the SVT in accordance with
[RFC7515]. Each profile, as discussed in Section 4, MUST define the [RFC7515]. Each profile, as discussed in Section 4, MUST define the
requirements for how the key or key reference is included in the requirements for how the key or key reference is included in the
header. header.
4. Profiles 4. Profiles
Each signed document and signature type will have to define the Each signed document and signature type will have to define the
precise content and use of several claims in the SVT. precise content and use of several claims in the SVT.
Each profile MUST as a minimum define: At a minimum, each profile MUST define:
* The identifier of the profile. * The identifier of the profile
* How to reference the Signed Data content of the signed document. * How to reference the Signed Data content of the signed document
* How to reference to the target electronic signature and the Signed * How to reference the target electronic signature and the Signed
Bytes of the signature. Bytes of the signature
* How to reference certificates supporting each electronic * How to reference certificates supporting each electronic signature
siganture.
* How to include public keys or references to public keys in the * How to include public keys or references to public keys in the SVT
SVT.
* Whether each electronic signature is supported by a single SVT, or * Whether each electronic signature is supported by a single SVT, or
whether one SVT may support multiple electronic signatures of the one SVT may support multiple electronic signatures of the same
same document. document
A profile MAY also define: A profile MAY also define:
* Explicit information on how to perform signature validation based * Explicit information on how to perform signature validation based
on an SVT. on an SVT
* How to attach an SVT to an electronic signature or signed * How to attach an SVT to an electronic signature or signed document
document.
4.1. Defined Profiles 4.1. Defined Profiles
The following profiles are defined in Appendixes of this document: The following profiles are defined in appendixes of this document:
* Appendix A: XML Profile Appendix A: XML Signature Profile
* Appendix B: PDF Profile Appendix B: PDF Signature Profile
* Appendix C: JWS Profile Appendix C: JWS Profile
Other documents MAY define other profiles that MAY complement, ammend Other documents MAY define other profiles that MAY complement, amend,
or supersede these profiles. or supersede these profiles.
5. Signature Verification with a SVT 5. Signature Verification with an SVT
Signature verification based on an a SVT MUST follow these steps: Signature verification based on an SVT MUST follow these steps:
1. Locate all available SVTs available for the signed document that 1. Locate all available SVTs available for the signed document that
are relevant for the target electronic signature. are relevant for the target electronic signature.
2. Select the most recent SVT that can be successfully validated and 2. Select the most recent SVT that can be successfully validated and
meets the requirement of the relying party. meets the requirement of the relying party.
3. Verify the integrity of the signature and the Signed Bytes of the 3. Verify the integrity of the signature and the Signed Bytes of the
target electronic signature using the sig_ref claim. target electronic signature using the sig_ref claim.
skipping to change at page 16, line 4 skipping to change at line 696
requirements of the relying party. requirements of the relying party.
8. Verify that verified time results satisfy the context for the use 8. Verify that verified time results satisfy the context for the use
of the signed document. of the signed document.
After successfully performing these steps, signature validity is After successfully performing these steps, signature validity is
established as well as the trusted signer certificate binding the established as well as the trusted signer certificate binding the
identity of the signer to the electronic signature. identity of the signer to the electronic signature.
6. IANA Considerations 6. IANA Considerations
6.1. Claim Names Registration 6.1. Claim Names Registration
This section registers the "sig_val_claims" claim name in the IANA IANA has registered the "sig_val_claims" claim name in the "JSON Web
"JSON Web Token Claims" registry established by Section 10.1 in Token Claims" registry established by Section 10.1 of [RFC7519].
[RFC7519].
6.1.1. Registry Contents 6.1.1. Registry Contents
* Claim Name: "sig_val_claims" Claim Name: sig_val_claims
* Claim Description: Signature Validation Token
* Change Controller: IESG Claim Description: Signature Validation Token
* Specification Document(s): Section 3.2.3 of {this document} Change Controller: IESG
NOTE to RFC editor: Please replace {this document} with its assigned Specification Document(s): Section 3.2.3 of RFC 9321
RFC number.
6.2. Header Parameter Names Registration 6.2. Header Parameter Names Registration
This section registers the "svt" Header Parameter in the IANA "JSON IANA has registered the "svt" Header Parameter in the "JSON Web
Web Signature and Encryption Header Parameters" registry established Signature and Encryption Header Parameters" registry established by
by [RFC7515]. [RFC7515].
6.2.1. Registry Contents 6.2.1. Registry Contents
* Header Parameter Name: "svt" Header Parameter Name: svt
* Header Parameter Description: Signature Validation Token
* Header Parameter Usage Location(s): JWS Header Parameter Description: Signature Validation Token
* Change Controller: IESG Header Parameter Usage Location(s): JWS
* Specification Document(s): Appendix C.1.1 of {this document} Change Controller: IESG
NOTE to RFC editor: Please replace {this document} with its assigned Specification Document(s): Appendix C.1.1 of RFC 9321
RFC number.
7. Security Considerations 7. Security Considerations
7.1. Level of reliance
7.1. Level of Reliance
An SVT allows a signature verifier to still validate the original An SVT allows a signature verifier to still validate the original
signature using the original signature data and to use the signature using the original signature data and to use the
information in the SVT selectively to either just confirm the information in the SVT selectively to confirm the validity and
validity and integrity of the original data, such as confirming the integrity of the original data, such as confirming the integrity of
integrity of signed data or the validity of the signer's certificate Signed Data or the validity of the signer's certificate, etc.
etc.
Another way to use an SVT is to completely rely on the validation Another way to use an SVT is to completely rely on the validation
conclusion provided by the SVT and to omit re-validation of the conclusion provided by the SVT and to omit revalidation of the
original signature value and original certificate status checking original signature value and original certificate status checking
data. data.
This choice is a decision made by the verifier according to its own This choice is a decision made by the verifier according to its own
policy and risk assessment. policy and risk assessment.
However, even when relying on the SVT validation conclusion of an SVT However, even when relying on the SVT validation conclusion of an
it is vital to still verify that the present SVT is correctly SVT, it is vital to still verify that the present SVT is correctly
associated with the document and signature that is being validated by associated with the document and signature that is being validated by
validating the hashed reference data in the SVT of the signature, validating the hashed reference data in the SVT of the signature,
signing certificate chain, signed data and the signed bytes. signing certificate chain, Signed Data, and the Signed Bytes.
7.2. Aging algorithms 7.2. Aging Algorithms
Even if the SVT provides protection against algorithms becoming Even if the SVT provides protection against algorithms becoming
weakened or broken over time, this protection is only valid for as weakened or broken over time, this protection is only valid for as
long as the algorithms used to sign the SVT are still considered long as the algorithms used to sign the SVT are still considered
secure. It is advisable to re-issue SVT in cases where an algorithm secure. It is advisable to reissue SVTs in cases where an algorithm
protecting the SVT is getting close to its end of life. protecting the SVT is getting close to its end of life.
One way to increase the resistance of algorithms becoming insecure, One way to increase the resistance of algorithms becoming insecure,
is to issue multiple SVT for the same signature with different is to issue multiple SVTs for the same signature with different
algorithms and key lengths where one algorithm could still be secure algorithms and key lengths where one algorithm could still be secure
even if the corresponding algorithm used in the alternative SVT is even if the corresponding algorithm used in the alternative SVT is
broken. broken.
8. References 8. References
8.1. Normative References 8.1. Normative References
[CADES] ETSI, "Electronic Signatures and Infrastructures (ESI); [CADES] ETSI, "Electronic Signatures and Infrastructures (ESI);
CAdES digital signatures; Part 1: Building blocks and CAdES digital signatures; Part 1: Building blocks and
CAdES baseline signatures", ETSI EN 319 122-1 v1.1.1, CAdES baseline signatures", v1.1.1, ETSI EN 319 122-1,
April 2016. April 2016.
[ETSI319102-1] [ETSI319102-1]
ETSI, "ETSI - Electronic Signatures and Infrastructures ETSI, "Electronic Signatures and Infrastructures (ESI);
(ESI); Procedures for Creation and Validation of AdES Procedures for Creation and Validation of AdES Digital
Digital Signatures; Part 1: Creation and Validation", Signatures; Part 1: Creation and Validation", v1.1.1, ETSI
ETSI EN 319 102-1 v1.1.1, May 2016. EN 319 102-1, May 2016.
[IANA-JOSE-REG]
IANA, "JSON Object Signing and Encryption (JOSE)",
<https://www.iana.org/assignments/jose/>.
[ISOPDF2] ISO, "Document management -- Portable document format -- [ISOPDF2] ISO, "Document management -- Portable document format --
Part 2: PDF 2.0", ISO 32000-2, July 2017. Part 2: PDF 2.0", ISO 32000-2:2020, December 2020.
[PADES] ETSI, "Electronic Signatures and Infrastructures (ESI); [PADES] ETSI, "Electronic Signatures and Infrastructures (ESI);
PAdES digital signatures; Part 1: Building blocks and PAdES digital signatures; Part 1: Building blocks and
PAdES baseline signatures", ETSI EN 319 142-1 v1.1.1, PAdES baseline signatures", v1.1.1, ETSI EN 319 142-1,
April 2016. April 2016.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3125] Ross, J., Pinkas, D., and N. Pope, "Electronic Signature [RFC3125] Ross, J., Pinkas, D., and N. Pope, "Electronic Signature
Policies", RFC 3125, DOI 10.17487/RFC3125, September 2001, Policies", RFC 3125, DOI 10.17487/RFC3125, September 2001,
<https://www.rfc-editor.org/info/rfc3125>. <https://www.rfc-editor.org/info/rfc3125>.
skipping to change at page 19, line 5 skipping to change at line 830
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>. <https://www.rfc-editor.org/info/rfc5280>.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, DOI 10.17487/RFC5652, September 2009, RFC 5652, DOI 10.17487/RFC5652, September 2009,
<https://www.rfc-editor.org/info/rfc5652>. <https://www.rfc-editor.org/info/rfc5652>.
[RFC6931] Eastlake 3rd, D., "Additional XML Security Uniform
Resource Identifiers (URIs)", RFC 6931,
DOI 10.17487/RFC6931, April 2013,
<https://www.rfc-editor.org/info/rfc6931>.
[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
2015, <https://www.rfc-editor.org/info/rfc7515>. 2015, <https://www.rfc-editor.org/info/rfc7515>.
[RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, [RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518,
DOI 10.17487/RFC7518, May 2015, DOI 10.17487/RFC7518, May 2015,
<https://www.rfc-editor.org/info/rfc7518>. <https://www.rfc-editor.org/info/rfc7518>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<https://www.rfc-editor.org/info/rfc7519>. <https://www.rfc-editor.org/info/rfc7519>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC9231] Eastlake 3rd, D., "Additional XML Security Uniform
Resource Identifiers (URIs)", RFC 9231,
DOI 10.17487/RFC9231, July 2022,
<https://www.rfc-editor.org/info/rfc9231>.
[XADES] ETSI, "Electronic Signatures and Infrastructures (ESI); [XADES] ETSI, "Electronic Signatures and Infrastructures (ESI);
XAdES digital signatures; Part 1: Building blocks and XAdES digital signatures; Part 1: Building blocks and
XAdES baseline signatures", ETSI EN 319 132-1 v1.1.1, XAdES baseline signatures", v1.1.1, ETSI EN 319 132-1,
April 2016. April 2016.
[XMLDSIG11] [XMLDSIG11]
Eastlake, D., Reagle, J., Solo, D., Hirsch, F., Nystrom, Eastlake 3rd, D., Reagle, J., Solo, D., Hirsch, F.,
M., Roessler, T., and K. Yiu, "XML Signature Syntax and Nystrom, M., Roessler, T., and K. Yiu, "XML Signature
Processing Version 1.1", W3C Proposed Recommendation, 11 Syntax and Processing Version 1.1", W3C Proposed
April 2013. Recommendation, April 2013. Latest version available at
https://www.w3.org/TR/xmldsig- core1/.
8.2. Informative References 8.2. Informative References
[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
Definition Language (CDDL): A Notational Convention to Definition Language (CDDL): A Notational Convention to
Express Concise Binary Object Representation (CBOR) and Express Concise Binary Object Representation (CBOR) and
JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
June 2019, <https://www.rfc-editor.org/info/rfc8610>. June 2019, <https://www.rfc-editor.org/info/rfc8610>.
Appendix A. Appendix: XML signature profile Appendix A. XML Signature Profile
This appendix defines a profile for implementing SVT with a signed This appendix defines a profile for implementing SVTs with a signed
XML document, and defines the following aspects of SVT usage: XML document and defines the following aspects of SVT usage:
* How to include reference data related to XML signatures and XML * How to include reference data related to XML signatures and XML
documents in an SVT. documents in an SVT
* How to add an SVT token to a XML signature. * How to add an SVT token to an XML signature
XML documents can have any number of signature elements, signing an XML documents can have any number of signature elements, signing an
arbitrary number of fragments of XML documents. The actual signature arbitrary number of fragments of XML documents. The actual signature
element may be included in the signed XML document (enveloped), element may be included in the signed XML document (enveloped),
include the signed data (enveloping) or may be separate from the include the Signed Data (enveloping), or may be separate from the
signed content (detached). signed content (detached).
To provide a generic solution for any type of XML signature an SVT is To provide a generic solution for any type of XML signature, an SVT
added to each XML signature element within the XML signature is added to each XML signature element within the XML signature
<ds:Object> element. <ds:Object> element.
A.1. Notation A.1. Notation
A.1.1. References to XML Elements from XML Schemas A.1.1. References to XML Elements from XML Schemas
When referring to elements from the W3C XML Signature namespace When referring to elements from the W3C XML Signature namespace
(http://www.w3.org/2000/09/xmldsig#) the following syntax is used: (https://www.w3.org/2000/09/xmldsig#), the following syntax is used:
* <ds:Signature> * <ds:Signature>
When referring to elements from the ETSI XAdES XML Signature When referring to elements from the ETSI XAdES XML Signature
namespace (http://uri.etsi.org/01903/v1.3.2#) the following syntax is namespace (https://uri.etsi.org/01903/v1.3.2#), the following syntax
used: is used:
* <xades:CertDigest> * <xades:CertDigest>
When referring to elements defined in this specification When referring to elements defined in this specification
(http://id.swedenconnect.se/svt/1.0/sig-prop/ns) the following syntax (http://id.swedenconnect.se/svt/1.0/sig-prop/ns), the following
is used: syntax is used:
* <svt:Element> * <svt:Element>
A.2. SVT in XML Documents A.2. SVT in XML Documents
When SVT is provided for XML signatures then one SVT MUST be provided When SVTs are provided for XML signatures, then one SVT MUST be
for each XML signature. provided for each XML signature.
An SVT embedded within the XML signature element MUST be placed in a An SVT embedded within the XML signature element MUST be placed in a
<svt:SignatureValidationToken> element as defined in Appendix A.2.1. <svt:SignatureValidationToken> element as defined in Appendix A.2.1.
A.2.1. SignatureValidationToken Signature Property A.2.1. SignatureValidationToken Signature Property
The <svt:SignatureValidationToken> element MUST be placed in a The <svt:SignatureValidationToken> element MUST be placed in a
<ds:SignatureProperty> element in accordance with [XMLDSIG11]. The <ds:SignatureProperty> element in accordance with [XMLDSIG11]. The
<ds:SignatureProperty> element MUST be placed inside a <ds:SignatureProperty> element MUST be placed inside a
<ds:SignatureProperties> element inside a <ds:Object> element inside <ds:SignatureProperties> element inside a <ds:Object> element inside
a <ds:Signature> element. a <ds:Signature> element.
Note: [XMLDSIG11] requires the Target attribute to be present in Note: [XMLDSIG11] requires the Target attribute to be present in
<ds:SignatureProperty>, referencing the signature targeted by this <ds:SignatureProperty>, referencing the signature targeted by this
signature property. If an SVT is added to a signature that do not signature property. If an SVT is added to a signature that does not
have an Id attribute, implementations SHOULD add an Id attribute to have an Id attribute, implementations SHOULD add an Id attribute to
the <ds:Signature> element and reference that Id in the Target the <ds:Signature> element and reference that Id in the Target
attribute. This Id attribute and Target attribute value matching is attribute. This Id attribute and Target attribute value matching is
required by the [XMLDSIG11] standard, but it is redundant in the required by the [XMLDSIG11] standard, but it is redundant in the
context of SVT validation as the SVT already contains information context of SVT validation as the SVT already contains information
that uniquely identifies the target signature. Validation that uniquely identifies the target signature. Validation
applications SHOULD not reject an SVT token because of Id and Target applications SHOULD NOT reject an SVT token because of Id and Target
attribute mismatch, and MUST rely on matching against signature using attribute mismatch and MUST rely on matching against a signature
signed information in the SVT itself. using signed information in the SVT itself.
The <svt:SignatureValidationToken> element is defined by the The <svt:SignatureValidationToken> element is defined by the
following XML Schema: following XML Schema:
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" elementFormDefault="qualified"
targetNamespace="http://id.swedenconnect.se/svt/1.0/sig-prop/ns" targetNamespace="http://id.swedenconnect.se/svt/1.0/sig-prop/ns"
xmlns:svt="http://id.swedenconnect.se/svt/1.0/sig-prop/ns"> xmlns:svt="http://id.swedenconnect.se/svt/1.0/sig-prop/ns">
skipping to change at page 21, line 41 skipping to change at line 964
<xs:simpleContent> <xs:simpleContent>
<xs:extension base="xs:string"> <xs:extension base="xs:string">
</xs:extension> </xs:extension>
</xs:simpleContent> </xs:simpleContent>
</xs:complexType> </xs:complexType>
</xs:schema> </xs:schema>
The SVT token MUST be included as a string representation of the SVT 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 JWT. Note that this is the string representation of the JWT without
further encoding. The SVT MUST NOT be represented by the Base64 further encoding. The SVT MUST NOT be represented by the
encoded bytes of the JWT string. Base64-encoded bytes of the JWT string.
Example: Example:
<ds:Signature Id="MySignatureId"> <ds:Signature Id="MySignatureId">
... ...
<ds:Object> <ds:Object>
<ds:SignatureProperties> <ds:SignatureProperties>
<ds:SignatureProperty Target="#MySignatureId"> <ds:SignatureProperty Target="#MySignatureId">
<svt:SignatureValidationToken> <svt:SignatureValidationToken>
eyJ0eXAiOiJKV1QiLCJhb...2aNZ eyJ0eXAiOiJKV1QiLCJhb...2aNZ
</svt:SignatureValidationToken> </svt:SignatureValidationToken>
</ds:SignatureProperty> </ds:SignatureProperty>
</ds:SignatureProperties> </ds:SignatureProperties>
</ds:Object> </ds:Object>
</ds:Signature> </ds:Signature>
A.2.2. Multiple SVT in an XML signature A.2.2. Multiple SVTs in an XML Signature
If a new SVT is stored in a signature which already contains a If a new SVT is stored in a signature that already contains a
previously issued SVT, implementations can choose to either replace previously issued SVT, implementations can choose either to replace
the existing SVT or to store the new SVT in addition to the existing the existing SVT or to store the new SVT in addition to the existing
SVT. SVT.
If the new SVT is stored in addition to the old SVT, it SHOULD be 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 stored in a new <ds:SignatureProperty> element inside the existing
<ds:SignatureProperties> element where the old SVT is located. <ds:SignatureProperties> element where the old SVT is located.
For interoperability robustness, signature validation applications For interoperability robustness, signature validation applications
MUST be able to handle signatures where the new SVT is located in a MUST be able to handle signatures where the new SVT is located in a
new <ds:Object> element. new <ds:Object> element.
A.3. XML signature SVT Claims A.3. XML Signature SVT Claims
A.3.1. XML Profile Identifier A.3.1. XML Profile Identifier
When this profile is used the SigValidation object MUST contain a When this profile is used, the SigValidation object MUST contain a
"profile" claim with the value "XML". "profile" claim with the value "XML".
A.3.2. XML Signature Reference Data A.3.2. XML Signature Reference Data
The SVT Signature object MUST contain a "sig_ref" claim (SigReference The SVT Signature object MUST contain a "sig_ref" claim (SigReference
object) with the following elements: object) with the following elements:
* "id" -- The Id-attribute of the XML signature, if present. "id": The Id-attribute of the XML signature, if present.
* "sig_hash" -- The hash over the signature value bytes. "sig_hash": The hash over the signature value bytes.
* "sb_hash" -- The hash over the canonicalized <ds:SignedInfo> "sb_hash": The hash over the canonicalized <ds:SignedInfo> element
element (the bytes the XML signature algorithm has signed to (the bytes the XML signature algorithm has signed to generate the
generated the signature value). signature value).
A.3.3. XML Signed Data Reference Data A.3.3. XML Signed Data Reference Data
The SVT Signature object MUST contain one instance of the "sig_data" The SVT Signature object MUST contain one instance of the "sig_data"
claim (SignedData object) for each <ds:Reference> element in the claim (SignedData object) for each <ds:Reference> element in the
<ds:SignedInfo> element. The "sig_data" claim MUST contain the <ds:SignedInfo> element. The "sig_data" claim MUST contain the
following elements: following elements:
* "ref" -- The value of the URI attribute of the corresponding "ref": The value of the URI attribute of the corresponding
<ds:Reference> element. <ds:Reference> element.
* "hash" -- The hash of all bytes identified corresponding "hash": The hash of all bytes that were identified by the
<ds:Reference> element after applying all identified corresponding <ds:Reference> element after applying all identified
canonicalization and transformation algorithms. These are the canonicalization and transformation algorithms. These are the
same bytes that is hashed by the hash value in the same bytes that are hashed by the hash value in the
<ds:DigestValue> element inside the <ds:Reference> element. <ds:DigestValue> element inside the <ds:Reference> element.
A.3.4. XML Signer Certificate References A.3.4. XML Signer Certificate References
The SVT Signature object MUST contain a "signer_cert_ref" claim The SVT Signature object MUST contain a "signer_cert_ref" claim
(CertReference object). The "type" parameter of the (CertReference object). The "type" parameter of the
"signer_cert_ref" claim MUST be either "chain" or "chain_hash". "signer_cert_ref" claim MUST be either "chain" or "chain_hash".
* The "chain" type MUST be used when signature validation was * The "chain" type MUST be used when signature validation was
performed using one or more certificates where some or all of the performed using one or more certificates where some or all of the
skipping to change at page 23, line 40 skipping to change at line 1052
* The "chain_hash" type MUST be used when signature validation was * The "chain_hash" type MUST be used when signature validation was
performed using one or more certificates where all of the performed using one or more certificates where all of the
certificates are present in the target signature. certificates are present in the target signature.
A.4. JOSE Header A.4. JOSE Header
A.4.1. SVT Signing Key Reference A.4.1. SVT Signing Key Reference
The SVT JOSE header for XML signatures must contain one of the The SVT JOSE header for XML signatures must contain one of the
following header parameters in accordance with [RFC7515], for storing following header parameters in accordance with [RFC7515] for storing
a reference to the public key used to verify the signature on the a reference to the public key used to verify the signature on the
SVT: SVT:
* "x5c" -- Holds an X.509 certificate [RFC5280] or a chain of "x5c": Holds an X.509 certificate [RFC5280] or a chain of
certificates. The certificate holding the public key that certificates. The certificate holding the public key that
verifies the signature on the SVT MUST be the first certificate in verifies the signature on the SVT MUST be the first certificate in
the chain. the chain.
* "kid" -- A key identifier holding the Base64 encoded hash value of "kid": A key identifier holding the Base64-encoded hash value of the
the certificate that can verify the signature on the SVT. The certificate that can verify the signature on the SVT. The hash
hash algorithm MUST be the same hash algorithm used when signing algorithm MUST be the same hash algorithm used when signing the
the SVT as specified by the alg header parameter. SVT as specified by the "alg" Header Parameter.
Appendix B. Appendix: PDF signature profile Appendix B. PDF Signature Profile
This appendix defines a profile for implementing SVT with a signed This appendix defines a profile for implementing SVTs with a signed
PDF document, and defines the following aspects of SVT usage: PDF document, and it defines the following aspects of SVT usage:
* How to include reference data related to PDF signatures and PDF * How to include reference data related to PDF signatures and PDF
documents in an SVT. documents in an SVT.
* How to add an SVT token to a PDF document. * How to add an SVT token to a PDF document.
PDF document signatures are added as incremental updates to the PDF document signatures are added as incremental updates to the
signed PDF document and signs all data of the PDF document up until 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 the current signature. When more than one signature is added to a
PDF document the previous signature is signed by the next signature PDF document the previous signature is signed by the next signature
and can not be updated with additional data after this event. and can not be updated with additional data after this event.
To minimize the impact on PDF documents with multiple signatures and To minimize the impact on PDF documents with multiple signatures and
to stay backwards compatible with PDF software that do not understand to stay backwards compatible with PDF software that does not
SVT, PDF documents add one SVT token for all signatures of the PDF as understand SVTs, PDF documents add one SVT token for all signatures
an extension to a document timestamp added to the signed PDF as an of the PDF as an extension to a document timestamp added to the
incremental update. This SVT covers all signatures of the signed signed PDF as an incremental update. This SVT covers all signatures
PDF. of the signed PDF.
B.1. SVT in PDF Documents B.1. SVTs in PDF Documents
The SVT for a signed PDF document MAY provide signature validation The SVT for a signed PDF document MAY provide signature validation
information about any of the present signatures in the PDF. The SVT information about any of the present signatures in the PDF. The SVT
MUST contain a separate "sig" claim (Signature object) for each MUST contain a separate "sig" claim (Signature object) for each
signature on the PDF that is covered by the SVT. signature on the PDF that is covered by the SVT.
An SVT added to a signed PDF document MUST be added to a document An SVT added to a signed PDF document MUST be added to a document
timestamp accordance with ISO 32000-2:2017 [ISOPDF2]. timestamp in accordance with ISO 32000-2:2020 [ISOPDF2].
The document timestamp contains an [RFC3161] timestamp token The document timestamp contains an [RFC3161] timestamp token
(TSTInfo) in EncapsulatedContentInfo of the CMS signature. The SVT (TSTInfo) in EncapsulatedContentInfo of the CMS signature. The SVT
MUST be added to the timestamp token (TSTInfo) as an Extension object MUST be added to the timestamp token (TSTInfo) as an Extension object
as defined in Appendix B.1.1. as defined in Appendix B.1.1.
B.1.1. SVT Extension to Timestamp Tokens B.1.1. SVT Extension to Timestamp Tokens
The SVT extension is an Extension suitable to be included in TSTInfo The SVT extension is an Extension suitable to be included in TSTInfo
as defined by [RFC3161]. as defined by [RFC3161].
The SVT extension is identified by the Object Identifier (OID) The SVT extension is identified by the Object Identifier (OID)
1.2.752.201.5.2 1.2.752.201.5.2.
Editors note: This is the current used OID. Consider assigning an
IETF extension OID.
This extension data (OCTET STRING) holds the bytes of SVT JWT, This extension data (OCTET STRING) holds the bytes of SVT JWT,
represented as a UTF-8 encoded string. represented as a UTF-8-encoded string.
This extension MUST NOT be marked critical. This extension MUST NOT be marked critical.
Note: Extensions in timestamp tokens according to [RFC3161] are Note: Extensions in timestamp tokens according to [RFC3161] are
imported from the definition of the X.509 certificate extensions imported from the definition of the X.509 certificate extensions
defined in [RFC5280]. defined in [RFC5280].
B.2. PDF signature SVT Claims B.2. PDF Signature SVT Claims
B.2.1. PDF Profile Identifier B.2.1. PDF Profile Identifier
When this profile is used the SigValidation object MUST contain a When this profile is used, the SigValidation object MUST contain a
"profile" claim with the value "PDF". "profile" claim with the value "PDF".
B.2.2. PDF Signature Reference Data B.2.2. PDF Signature Reference Data
The SVT Signature object MUST contain a "sig_ref" claim (SigReference The SVT Signature object MUST contain a "sig_ref" claim (SigReference
object) with the following elements: object) with the following elements:
* "id" -- Absent or a Null value. "id": Absent or a Null value.
* "sig_hash" -- The hash over the signature value bytes. "sig_hash": The hash over the signature value bytes.
* "sb_hash" -- The hash over the DER encoded SignedAttributes in "sb_hash": The hash over the DER-encoded SignedAttributes in
SignerInfo. SignerInfo.
B.2.3. PDF Signed Data Reference Data B.2.3. PDF Signed Data Reference Data
The SVT Signature object MUST contain one instance of the "sig_data" The SVT Signature object MUST contain one instance of the "sig_data"
claim (SignedData object) with the following elements: claim (SignedData object) with the following elements:
* "ref" -- The string representation of the ByteRange value of the "ref": The string representation of the ByteRange value of the PDF
PDF signature dictionary of the target signature. This is a signature dictionary of the target signature. This is a sequence
sequence of integers separated by space where each integer pair of integers separated by space where each integer pair specifies
specifies the start index and length of a byte range. the start index and length of a byte range.
* "hash" -- The hash of all bytes identified by the ByteRange value. "hash": The hash of all bytes identified by the ByteRange value.
This is the concatenation of all byte ranges identified by the This is the concatenation of all byte ranges identified by the
ByteRange value. ByteRange value.
B.2.4. PDF Signer Certificate References B.2.4. PDF Signer Certificate References
The SVT Signature object MUST contain a "signer_cert_ref" claim The SVT Signature object MUST contain a "signer_cert_ref" claim
(CertReference object). The "type" parameter of the (CertReference object). The "type" parameter of the
"signer_cert_ref" claim MUST be either "chain" or "chain_hash". "signer_cert_ref" claim MUST be either "chain" or "chain_hash".
* The "chain" type MUST be used when signature validation was * The "chain" type MUST be used when signature validation was
skipping to change at page 26, line 21 skipping to change at line 1176
certificates are present in the target signature. certificates are present in the target signature.
Note: The referenced signer certificate MUST match any certificates Note: The referenced signer certificate MUST match any certificates
referenced using ESSCertID or ESSCertIDv2 from [RFC5035]. referenced using ESSCertID or ESSCertIDv2 from [RFC5035].
B.3. JOSE Header B.3. JOSE Header
B.3.1. SVT Signing Key Reference B.3.1. SVT Signing Key Reference
The SVT JOSE header must contain one of the following header The SVT JOSE header must contain one of the following header
parameters in accordance with [RFC7515], for storing a reference to parameters in accordance with [RFC7515] for storing a reference to
the public key used to verify the signature on the SVT: the public key used to verify the signature on the SVT:
* "x5c" -- Holds an X.509 certificate [RFC5280] or a chain of "x5c": Holds an X.509 certificate [RFC5280] or a chain of
certificates. The certificate holding the public key that certificates. The certificate holding the public key that
verifies the signature on the SVT MUST be the first certificate in verifies the signature on the SVT MUST be the first certificate in
the chain. the chain.
* "kid" -- A key identifier holding the Base64 encoded hash value of "kid": A key identifier holding the Base64-encoded hash value of the
the certificate that can verify the signature on the SVT. The certificate that can verify the signature on the SVT. The hash
hash algorithm MUST be the same hash algorithm used when signing algorithm MUST be the same hash algorithm used when signing the
the SVT as specified by the alg header parameter. The referenced SVT as specified by the "alg" Header Parameter. The referenced
certificate SHOULD be the same certificate that was used to sign certificate SHOULD be the same certificate that was used to sign
the document timestamp that contains the SVT. the document timestamp that contains the SVT.
Appendix C. Appendix: JWS Profile Appendix C. JWS Profile
This appendix defines a profile for implementing SVT with a JWS This appendix defines a profile for implementing SVTs with a JWS
signed payload according to [RFC7515], and defines the following signed payload according to [RFC7515], and it defines the following
aspects of SVT usage: aspects of SVT usage:
* How to include reference data related to JWS signatures in an SVT. * How to include reference data related to JWS signatures in an SVT.
* How to add an SVT token to JWS signatures. * How to add an SVT token to JWS signatures.
A JWS may have one or more signatures depending on its serialization A JWS may have one or more signatures, depending on its serialization
format, signing the same payload data. A JWS either contains the format, signing the same payload data. A JWS either contains the
data to be signed (enveloping) or may sign any externally associated data to be signed (enveloping) or may sign any externally associated
payload data (detached). payload data (detached).
To provide a generic solution for JWS, an SVT is added to each To provide a generic solution for JWS, an SVT is added to each
present signature as a JWS Unprotected Header. If a JWS includes present signature as a JWS Unprotected Header. If a JWS includes
multiple signatures, then each signature includes its own SVT. multiple signatures, then each signature includes its own SVT.
C.1. SVT in JWS C.1. SVT in JWS
An SVT token MAY be added to any signature of a JWS to support An SVT token MAY be added to any signature of a JWS to support
validation of that signature. If more than one signature is present validation of that signature. If more than one signature is present,
then each present SVT MUST provide information exclusively related to then each present SVT MUST provide information exclusively related to
one associated signature and MUST NOT include information about any one associated signature and MUST NOT include information about any
other signature in the JWS. other signature in the JWS.
Each SVT is stored in its associated signature's "svt" header as Each SVT is stored in its associated signature's "svt" header as
defined in Appendix C.1.1. defined in Appendix C.1.1.
C.1.1. "svt" Header Parameter C.1.1. "svt" Header Parameter
The "svt" (Signature Validation Token) Header Parameter is used to The "svt" (Signature Validation Token) Header Parameter is used to
contain an array of SVT tokens to support validation of the contain an array of SVT tokens to support validation of the
associated signature. Each SVT token in the array has the format of associated signature. Each SVT token in the array has the format of
a JWT as defined in [RFC7519] and is stored using its natural string a JWT as defined in [RFC7519] and is stored using its natural string
representation without further wrapping or encoding. representation without further wrapping or encoding.
The "svt" Header Parameter, when used, MUST be included as a JWS The "svt" Header Parameter, when used, MUST be included as a JWS
Unprotected Header. Unprotected Header.
Note: JWS Unprotected Header is not supported with JWS Compact Note: A JWS Unprotected Header is not supported with JWS Compact
Serialization. A consequence of adding an SVT token to a JWS is Serialization. A consequence of adding an SVT token to a JWS is
therefore that JWS JSON Serialization MUST be used, either in the therefore that JWS JSON Serialization MUST be used either in the form
form of general JWS JSON Serialization (for one or more signatures) of general JWS JSON Serialization (for one or more signatures) or in
or in the form of flattened JWS JSON Serialization (optionally used the form of flattened JWS JSON Serialization (optionally used when
when only one signature is present in the JWS). only one signature is present in the JWS).
C.1.2. Multiple SVT in a JWS signature C.1.2. Multiple SVTs in a JWS Signature
If a new SVT is stored in a signature which already contains a If a new SVT is stored in a signature that already contains a
previously issued SVT, implementations can choose to either replace previously issued SVT, implementations can choose either to replace
the existing SVT or to store the new SVT in addition to the existing the existing SVT or to store the new SVT in addition to the existing
SVT. SVT.
If a JWS signature already contains an array of SVTs and a new SVT is 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 to be added, then the new SVT MUST be added to the array of SVT
tokens in the existing "svt" Header Parameter. tokens in the existing "svt" Header Parameter.
C.2. JWS signature SVT Claims C.2. JWS Signature SVT Claims
C.2.1. JWS Profile Identifier C.2.1. JWS Profile Identifier
When this profile is used the SigValidation object MUST contain a When this profile is used, the SigValidation object MUST contain a
"profile" claim with the value "JWS". "profile" claim with the value "JWS".
C.2.2. JWS Signature Reference Data C.2.2. JWS Signature Reference Data
The SVT Signature object MUST contain a "sig_ref" claim (SigReference The SVT Signature object MUST contain a "sig_ref" claim (SigReference
object) with the following elements: object) with the following elements:
* "sig_hash" -- The hash over the associated signature value (the "sig_hash": The hash over the associated signature value (the bytes
bytes of the base64url-decoded signature parameter). of the base64url-decoded signature parameter).
* "sb_hash" -- The hash over all bytes signed by the associated "sb_hash": The hash over all bytes signed by the associated
signature (the JWS Signing Input according to [RFC7515]). signature (the JWS Signing Input according to [RFC7515]).
C.2.3. JWS Signed Data Reference Data C.2.3. JWS Signed Data Reference Data
The SVT Signature object MUST contain one instance of the "sig_data" The SVT Signature object MUST contain one instance of the "sig_data"
claim (SignedData object) with the following elements: claim (SignedData object) with the following elements:
* "ref" -- This parameter MUST hold one of the following thee "ref": This parameter MUST hold one of the following three possible
possible values. values:
1. The explicit string value "payload" if the signed JWS Payload 1. The explicit string value "payload" if the signed JWS Payload
is embedded in a "payload" member of the JWS. is embedded in a "payload" member of the JWS.
2. The explicit string value "detached" if the JWS signs detached 2. The explicit string value "detached" if the JWS signs detached
payload data without explicit reference. payload data without explicit reference.
3. A URI that can be used to identify or fetch the detached 3. 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. The means to determine the URI for the detached
signed data is outside the scope of this specification. Signed Data is outside the scope of this specification.
* "hash" -- The hash over the JWS Payload data bytes (not its "hash": The hash over the JWS Payload data bytes (not its base64url-
base64url-encoded string representation). encoded string representation).
C.2.4. JWS Signer Certificate References C.2.4. JWS Signer Certificate References
The SVT Signature object MUST contain a "signer_cert_ref" claim The SVT Signature object MUST contain a "signer_cert_ref" claim
(CertReference object). The "type" parameter of the (CertReference object). The "type" parameter of the
"signer_cert_ref" claim MUST be either "chain" or "chain_hash". "signer_cert_ref" claim MUST be either "chain" or "chain_hash".
* The "chain" type MUST be used when signature validation was * The "chain" type MUST be used when signature validation was
performed using one or more certificates where some or all of the performed using one or more certificates where some or all of the
certificates in the chain are not present in the target signature. certificates in the chain are not present in the target signature.
skipping to change at page 29, line 15 skipping to change at line 1309
* The "chain_hash" type MUST be used when signature validation was * The "chain_hash" type MUST be used when signature validation was
performed using one or more certificates where all of the performed using one or more certificates where all of the
certificates are present in the target signature JOSE header using certificates are present in the target signature JOSE header using
the "x5c" Header Parameter. the "x5c" Header Parameter.
C.3. SVT JOSE Header C.3. SVT JOSE Header
C.3.1. SVT Signing Key Reference C.3.1. SVT Signing Key Reference
The SVT JOSE header must contain one of the following header The SVT JOSE header must contain one of the following header
parameters in accordance with [RFC7515], for storing a reference to parameters in accordance with [RFC7515] for storing a reference to
the public key used to verify the signature on the SVT: the public key used to verify the signature on the SVT:
* "x5c" -- Holds an X.509 certificate [RFC5280] or a chain of "x5c": Holds an X.509 certificate [RFC5280] or a chain of
certificates. The certificate holding the public key that certificates. The certificate holding the public key that
verifies the signature on the SVT MUST be the first certificate in verifies the signature on the SVT MUST be the first certificate in
the chain. the chain.
* "kid" -- A key identifier holding the Base64 encoded hash value of "kid": A key identifier holding the Base64-encoded hash value of the
the certificate that can verify the signature on the SVT. The certificate that can verify the signature on the SVT. The hash
hash algorithm MUST be the same hash algorithm used when signing algorithm MUST be the same hash algorithm used when signing the
the SVT as specified by the alg header parameter. SVT as specified by the "alg" Header Parameter.
Appendix D. Appendix: Schemas Appendix D. Schemas
D.1. Concise Data Definition Language (CDDL) D.1. Concise Data Definition Language (CDDL)
The following informative CDDL [RFC8610] express the structure of an The following informative CDDL [RFC8610] expresses the structure of
SVT token: an SVT token:
svt = { svt = {
jti: text jti: text
iss: text iss: text
iat: uint iat: uint
? aud: text / [* text] ? aud: text / [* text]
? exp: uint ? exp: uint
sig_val_claims: SigValClaims sig_val_claims: SigValClaims
} }
skipping to change at page 31, line 13 skipping to change at line 1402
binary-value = text ; base64 classic with padding binary-value = text ; base64 classic with padding
D.2. JSON Schema D.2. JSON Schema
The following informative JSON schema describes the syntax of the SVT The following informative JSON schema describes the syntax of the SVT
token payload. token payload.
{ {
"$schema": "https://json-schema.org/draft/2020-12/schema", "$schema": "https://json-schema.org/draft/2020-12/schema",
"title": "Signature Validation Token JSON Schema", "title": "Signature Validation Token JSON Schema",
"description": "Schema defining the payload format for SVT", "description": "Schema defining the payload format for SVTs",
"type": "object", "type": "object",
"required": [ "required": [
"jti", "jti",
"iss", "iss",
"iat", "iat",
"sig_val_claims" "sig_val_claims"
], ],
"properties": { "properties": {
"jti": { "jti": {
"description": "JWT ID", "description": "JWT ID",
skipping to change at page 36, line 41 skipping to change at line 1671
"description": "Extension map", "description": "Extension map",
"type": ["object","null"], "type": ["object","null"],
"required": [], "required": [],
"additionalProperties": { "additionalProperties": {
"type": "string" "type": "string"
} }
} }
} }
} }
Appendix E. Appendix: Examples Appendix E. Examples
The following example illustrates a basic SVT according to this The following example illustrates a basic SVT according to this
specification issued for a signed PDF document. specification issued for a signed PDF document.
Note: Line breaks in the decoded example are inserted for Note: Line breaks in the decoded example are inserted for
readablilty. Line breaks are not allowed in valid JSON data. readability. Line breaks are not allowed in valid JSON data.
Signature validation token JWT: Signature validation token JWT:
eyJraWQiOiJPZW5JKzQzNEpoYnZmRG50ZlZcLzhyT3hHN0ZrdnlqYUtWSmFWcUlG eyJraWQiOiJPZW5JKzQzNEpoYnZmRG50ZlZcLzhyT3hHN0ZrdnlqYUtWSmFWcUlG
QlhvaFZoQWU1Zks4YW5vdjFTNjg4cjdLYmFsK2Z2cGFIMWo4aWJnNTJRQnkxUFE9 QlhvaFZoQWU1Zks4YW5vdjFTNjg4cjdLYmFsK2Z2cGFIMWo4aWJnNTJRQnkxUFE9
PSIsInR5cCI6IkpXVCIsImFsZyI6IlJTNTEyIn0.eyJhdWQiOiJodHRwOlwvXC9l PSIsInR5cCI6IkpXVCIsImFsZyI6IlJTNTEyIn0.eyJhdWQiOiJodHRwOlwvXC9l
eGFtcGxlLmNvbVwvYXVkaWVuY2UxIiwiaXNzIjoiaHR0cHM6XC9cL3N3ZWRlbmNv eGFtcGxlLmNvbVwvYXVkaWVuY2UxIiwiaXNzIjoiaHR0cHM6XC9cL3N3ZWRlbmNv
bm5lY3Quc2VcL3ZhbGlkYXRvciIsImlhdCI6MTYwMzQ1ODQyMSwianRpIjoiNGQx bm5lY3Quc2VcL3ZhbGlkYXRvciIsImlhdCI6MTYwMzQ1ODQyMSwianRpIjoiNGQx
Mzk2ZjFmZjcyOGY0MGQ1MjQwM2I2MWM1NzQ0ODYiLCJzaWdfdmFsX2NsYWltcyI6 Mzk2ZjFmZjcyOGY0MGQ1MjQwM2I2MWM1NzQ0ODYiLCJzaWdfdmFsX2NsYWltcyI6
eyJzaWciOlt7ImV4dCI6bnVsbCwic2lnX3ZhbCI6W3sibXNnIjoiT0siLCJleHQi eyJzaWciOlt7ImV4dCI6bnVsbCwic2lnX3ZhbCI6W3sibXNnIjoiT0siLCJleHQi
skipping to change at page 39, line 4 skipping to change at line 1777
"ref" : "#xades-11a155d92bf55774613bb7b661477cfd", "ref" : "#xades-11a155d92bf55774613bb7b661477cfd",
"hash" : "KRkgbZ6P/nhU63IMk0GiUfU/DTwveYiteQkwGeJqC5BzTNV8bQb "hash" : "KRkgbZ6P/nhU63IMk0GiUfU/DTwveYiteQkwGeJqC5BzTNV8bQb
pedTTuWJPxqvJ0RY84hwm7eY/g0HrAOegKw==" pedTTuWJPxqvJ0RY84hwm7eY/g0HrAOegKw=="
} ], } ],
"time_val" : [ ] "time_val" : [ ]
} ], } ],
"ext" : null, "ext" : null,
"ver" : "1.0", "ver" : "1.0",
"profile" : "XML", "profile" : "XML",
"hash_algo" : "http://www.w3.org/2001/04/xmlenc#sha512" "hash_algo" : "http://www.w3.org/2001/04/xmlenc#sha512"
} }
} }
Authors' Addresses Authors' Addresses
Stefan Santesson Stefan Santesson
IDsec Solutions AB IDsec Solutions AB
Forskningsbyn Ideon Forskningsbyn Ideon
SE-223 70 Lund SE-223 70 Lund
Sweden Sweden
Email: sts@aaa-sec.com Email: sts@aaa-sec.com
Russ Housley Russ Housley
Vigil Security, LLC Vigil Security, LLC
516 Dranesville Road 516 Dranesville Road
Herndon, VA, 20170 Herndon, VA 20170
United States of America United States of America
Email: housley@vigilsec.com Email: housley@vigilsec.com
 End of changes. 206 change blocks. 
470 lines changed or deleted 458 lines changed or added

This html diff was produced by rfcdiff 1.48.