RFC 9321
Signature Validation Token
RFC 9321: Signature Validation Token ✨
Part 1 of 7 🎀
Title block, the bestie intro 💖 This one is an Independent Submission, which means it came in from outside the usual IETF process. It's written by S. Santesson (IDsec Solutions) and R. Housley (Vigil Security). The category is Informational, and the date is October 2022. It's listed under ISSN 2070-1721. The title block doesn't list anything it obsoletes or updates, so nothing gets replaced or patched by this one 🫶
Abstract 🦋
Okay so electronic signatures have a limited lifespan when it comes to how long they can be validated and confirmed as authentic 😭 The Signature Validation Token (SVT) defined here is the fix. It's evidence that says a signature is valid. A trusted authority issues it, and it says the signature passed validation under defined procedures at a specific time 🔥 Any future validation can be done by checking the SVT, so you don't have to re-validate the original signature or the certificates attached to it. The SVT works with electronic signatures in Cryptographic Message Syntax (CMS), XML, PDF, and JSON documents. Iconic 💅
Status of This Memo 🌸
This document is not an Internet Standards Track specification. It's published for informational purposes, so no vibe-checking for standards status here 🙈
It's a contribution to the RFC Series, separate from any other RFC stream. The RFC Editor chose to publish it at their discretion and makes no statement about how useful it is for implementation or deployment. Documents the RFC Editor approves for publication can't be candidates for any level of Internet Standard. See Section 2 of RFC 7841 for that.
If you want the latest on this document's status, any errata, or how to send feedback, check https://www.rfc-editor.org/info/rfc9321 ✨
Copyright Notice 💜
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the publication date. Please read these carefully, because they spell out your rights and restrictions for this document 📜
Table of Contents 🧚
1. Introduction
2. Definitions
3. Signature Validation Token
3.1. Signature Validation Token Function
3.2. Signature Validation Token Syntax
3.2.1. Data Types
3.2.2. Signature Validation Token JWT Claims
3.2.3. SigValidation Object Class
3.2.4. Signature Claims Object Class
3.2.5. SigReference Claims Object Class
3.2.6. SignedDataReference Claims Object Class
3.2.7. PolicyValidation Claims Object Class
3.2.8. TimeValidation Claims Object Class
3.2.9. CertReference Claims Object Class
3.2.10. SVT JOSE Header
4. Profiles
4.1. Defined Profiles
5. Signature Verification with an SVT
6. IANA Considerations
6.1. Claim Names Registration
6.1.1. Registry Contents
6.2. Header Parameter Names Registration
6.2.1. Registry Contents
7. Security Considerations
7.1. Level of Reliance
7.2. Aging Algorithms
8. References
8.1. Normative References
8.2. Informative References
Appendix A. XML Signature Profile
A.1. Notation
A.1.1. References to XML Elements from XML Schemas
A.2. SVT in XML Documents
A.2.1. SignatureValidationToken Signature Property
A.2.2. Multiple SVTs in an XML Signature
A.3. XML Signature SVT Claims
A.3.1. XML Profile Identifier
A.3.2. XML Signature Reference Data
A.3.3. XML Signed Data Reference Data
A.3.4. XML Signer Certificate References
A.4. JOSE Header
A.4.1. SVT Signing Key Reference
Appendix B. PDF Signature Profile
B.1. SVTs in PDF Documents
B.1.1. SVT Extension to Timestamp Tokens
B.2. PDF Signature SVT Claims
B.2.1. PDF Profile Identifier
B.2.2. PDF Signature Reference Data
B.2.3. PDF Signed Data Reference Data
B.2.4. PDF Signer Certificate References
B.3. JOSE Header
B.3.1. SVT Signing Key Reference
Appendix C. JWS Profile
C.1. SVT in JWS
C.1.1. "svt" Header Parameter
C.1.2. Multiple SVTs in a JWS Signature
C.2. JWS Signature SVT Claims
C.2.1. JWS Profile Identifier
C.2.2. JWS Signature Reference Data
C.2.3. JWS Signed Data Reference Data
C.2.4. JWS Signer Certificate References
C.3. SVT JOSE Header
C.3.1. SVT Signing Key Reference
Appendix D. Schemas
D.1. Concise Data Definition Language (CDDL)
D.2. JSON Schema
Appendix E. Examples
Authors' Addresses1. Introduction ✨
Electronic signatures have a limited lifespan when it comes to when they can be validated and confirmed as authentic. Lots of things make that harder as time goes on 😭 For example:
- Trusted info about whether the certificate holding the signer's public key is still valid isn't available.
- Trusted info about when the signature was actually created isn't available.
- The algorithms used to make the signature may no longer be considered secure at validation time, so they might not be in software libraries anymore.
- The services needed to validate the signature are gone by the time you need them.
- Supporting evidence like certification authority (CA) certificates, Online Certificate Status Protocol (OCSP) responses, Certificate Revocation Lists (CRLs), or timestamps isn't available or can't be validated.
Validating a signature gets harder over time, and eventually it may just be impossible to verify the signature with a sufficient level of assurance 💀
Existing standards can stretch how long a signature can be validated, like the ETSI XAdES [XADES] profile for XML signatures [XMLDSIG11], the ETSI PAdES [PADES] profile for PDF signatures [ISOPDF2], and the ETSI CAdES [CADES] profile for CMS signatures [RFC5652]. The catch is the complexity, because they mean storing and validating a lot of external evidence, like revocation data, signature time stamps, and archival time stamps 🙃
The Signature Validation Token (SVT) defined in this specification takes a trusted signature validation process as its input and preserves the validation result for the associated signature and signed document 🦋 The SVT asserts that a particular electronic signature was successfully validated by a trusted authority, following defined procedures, at a certain time. Those procedures MUST include checks that the signature matches the signed document, checks that the signature can be validated by the signing certificate, and checks that the signing certificate passes certificate path validation [RFC5280]. Those procedures MAY also include checks tied to a particular trust policy, like checking that an acceptable certificate policy [RFC5280] [RFC3647] was used to issue the signer's certificate, and checking that an acceptable signature policy was used by the signer [RFC3125].
Once the SVT is issued by a trusted authority, any future validation of that electronic signature can be satisfied by validating the SVT, with no need to also revalidate the original electronic signature. 🎀
The SVT is used to preserve validation results from applying existing signature validation standards, so it's complementary to those standards and not a replacement for them, including the ETSI long-term validation standards listed above. The SVT does have a potentially positive effect, though 👑 It may significantly reduce the need for complex long-term validation and preservation techniques, if an SVT is issued and applied to the signed document early on, while the signature can still be validated without lots of external evidence. So SVTs may drastically reduce the complexity of revalidating old archived electronic signatures 😭
The SVT can be signed with private keys and algorithms that give confidence for a long time. In fact, multiple SVTs can be used for greater assurance. For example, one SVT could be produced with a large RSA private key, a second with a strong elliptic curve, and a third with a quantum-safe digital signature algorithm to protect against advances in computing power and cryptanalytic capabilities 🌈 The trusted authority can also add more SVTs later, using fresh private keys and signatures, to extend the lifetime of the SVTs if needed.
2. Definitions 🌸
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here 💅
This document uses the following terms:
Signed Data: The data covered by a particular electronic signature. This is typically equivalent to the signed content of a document, and it represents the data the signer intended to sign. In some cases, like some XML signatures, the Signed Data can be a collection of several data fragments, each referenced by the signature. For PDF, this is the data covered by the "ByteRange" parameter in the signature dictionary. In JSON Web Signature (JWS), this is the unencoded payload data (before base64url encoding) ✨
Signed Bytes: These are the actual bytes of data that were hashed and signed by the digital signature algorithm. In most cases, this isn't the actual Signed Data. It's a collection of signature metadata that includes references (hashes) of the Signed Data, plus information about algorithms and other data bound to a signature. In XML, this is the canonicalized SignedInfo element. In CMS and PDF signatures, this is the DER-encoded SignedAttributes structure. In JWS, this is the protected header and payload data formatted according to [RFC7515] 🦋
When these terms are used as defined in this section, they appear with a capitalized first letter. Keep an eye out for that 👀
3. Signature Validation Token 🧚
3.1. Signature Validation Token Function ✨
okay so the Signature Validation Token (SVT) is made by a trusted service 🫶, and its whole job is to assert evidence that an electronic signature was validated successfully using a well-defined and trustworthy signature validation process. it's giving official stamp of approval 💅. the SVT binds the validation result to the validated signature, the document signed by that signature, and the certificate of the signer. this means a relying party can check that a signed document is valid without revalidating the original signature or reusing any of its associated cryptographic algorithms, for as long as the SVT itself can be validated 🔐.
the SVT pulls this off by binding the following info to one specific electronic signature:
- A unique identification of the electronic signature.
- The data and metadata signed by the electronic signature.
- The signer's certificate that was validated as part of electronic signature verification.
- The certification path that was used to validate the signer's certificate.
- An assertion providing evidence of signature verification, the time the verification was performed, the procedures used to verify the electronic signature, and the outcome of the verification.
- An assertion providing evidence of the time at which the signature is known to have existed, the procedures used to validate the time of existence, and the outcome of the validation.
the SVT is built for long-term validation that can keep getting extended into the future 🚀. to make that happen, it uses these strategies:
- by using secure algorithms with long life expectancy when signing the SVT
- by reissuing the SVT before it becomes insecure or is considered expired
- optionally, by issuing multiple SVTs with different algorithms to provide redundancy in case one algorithm is broken
3.2. Signature Validation Token Syntax 🎀
the SVT is carried in a JSON Web Token (JWT) as defined in [RFC7519].
3.2.1. Data Types 📝
the contents of claims in an SVT are specified using these data types, so let's go through them 🌸:
String: JSON Data Type of string that contains an arbitrary case-sensitive string value.Base64Binary: JSON Data Type of string that contains a Base64-encoded byte array of binary data.StringOrURI: JSON Data Type of string that contains an arbitrary string or a URI as defined in [RFC7519]. It is REQUIRED to contain the colon character (":") to be a URI.URI: JSON Data Type of string that contains a URI as defined in [RFC7519].Integer: JSON Data Type of number that contains a 32-bit signed integer value (from -2^31 to 2^31-1).Long: JSON Data Type of number that contains a 64-bit signed integer value (from -2^63 to 2^63-1).NumericDate: JSON Data Type of number that contains data as defined in [RFC7519], which is the number of seconds from 1970-01-01T00:00:00Z UTC until the specified UTC date/time, ignoring leap seconds.Boolean: JSON Data Type of boolean that contains the explicit value of true or false.Object<Class>: A JSON object holding a claims object of a class defined in this specification (see Section 3.2.2).Map<Type>: A JSON object with name-value pairs where the value is an object of the specified Type in the notation. For example,Map<String>is a JSON object with name-value pairs where all values are of type String.Array: A JSON array of a specific data type as defined in this section. An array is expressed in this specification by square brackets. For example,[String]indicates an array of String values, and[Object<DocHash>]indicates an array of DocHash objects.Null: A JSON null that represents an absent value. A claim with a null value is equivalent with an absent claim.
3.2.2. Signature Validation Token JWT Claims 🧾
the SVT MUST contain only JWT claims from the following list, no sneaking in extras 🙅♀️:
"jti": A String data type that is a "JWT ID" registered claim according to [RFC7519]. It is RECOMMENDED that the identifier holds a hexadecimal string representation of a 128-bit unsigned integer. An SVT MUST contain one "JWT ID" claim."iss": A StringOrURI data type that is an "Issuer" registered claim according to [RFC7519], which is an arbitrary unique identifier of the SVT issuer. This value SHOULD have the value of a URI based on a domain owned by the issuer. An SVT MUST contain one "Issuer" claim."iat": A NumericDate data type that is an "Issued At" registered claim according to [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 intended recipients of the SVT. Each identifier MAY identify a single entity, a group of entities, or a common policy adopted by a group of entities. If only one value is provided, it MAY be provided as a single StringOrURI data type value instead of as an array of values. Inclusion of the "Audience" claim in an SVT is OPTIONAL."exp": A NumericDate data type that is an "Expiration Time" registered claim according to [RFC7519], which expresses the time when services and responsibilities related to this SVT are no longer provided by the SVT issuer. The precise meaning of the expiration time claim is defined by local policies. See implementation note below. Inclusion of the "Expiration Time" claim in an SVT is OPTIONAL."sig_val_claims": An Object<SigValidation> data type that contains signature validation claims for this SVT extending the standard registered JWT claims above. An SVT MUST contain one sig_val_claims claim.
Note: An SVT asserts that a particular validation process was undertaken at a stated time. This fact never changes and never expires. However, some other aspects of the SVT such as liability for false claims or service provision related to a specific SVT may expire after a certain period of time, such as a service where an old SVT can be upgraded to a new SVT signed with fresh keys and algorithms. 🥹
3.2.3. SigValidation Object Class 💜
the sig_val_claims JWT claim uses the SigValidation object class. A SigValidation object holds all custom claims, and it contains the following parameters:
"ver": A String data type representing the version. This parameter MUST be present and the version in this specification indicated by the value "1.0"."profile": A StringOrURI data type representing the name of a profile that defines conventions followed for specific claims and any extension points used by the SVT issuer. This parameter MUST be present."hash_algo": A URI data type that identifies the hash algorithm used to compute the hash values within the SVT. The URI identifier MUST be one defined in [RFC9231] or in the IANA registry defined by this specification. This parameter MUST be present."sig": An [Object<Signature>] data type that gives information about validated electronic signatures as an array of Signature objects. If the SVT contains signature validation evidence for more than one signature, then each signature is represented by a separate Signature object. At least one Signature object MUST be present."ext": A Map<String> data type that provides additional claims related to the SVT. Extension claims are added at the discretion of the SVT issuer; however, extension claims MUST follow any conventions defined in a profile of this specification (see Section 4). Inclusion of this parameter is OPTIONAL.
3.2.4. Signature Claims Object Class 🌈
the sig parameter in the SigValidation object class uses the Signature object class. The Signature object contains claims related to signature validation evidence for one signature, and it contains the following parameters:
"sig_ref": An Object<SigReference> data type that contains reference information identifying the target signature. This parameter MUST be present."sig_data_ref": An [Object<SignedDataReference>] data type that contains an array of references to Signed Data that was signed by the target electronic signature. At least one SignedDataReference object MUST be present."signer_cert_ref": An Object<CertReference> data type that references the signer's certificate and optionally references a supporting certification path that was used to verify the target electronic signature. This parameter MUST be present."sig_val": An [Object<PolicyValidation>] data type that contains an array of results of signature verification according to defined procedures. At least one PolicyValidation object MUST be present."time_val": An [Object<TimeValidation>] data type that contains an array of time verification results showing that the target signature has existed at a specific time in the past. Inclusion of this parameter is OPTIONAL."ext": A MAP<String> data type that provides additional claims related to the target signature. Extension claims are added at the discretion of the SVT issuer; however, extension claims MUST follow any conventions defined in a profile of this specification (see Section 4). Inclusion of this parameter is OPTIONAL.
3.2.5. SigReference Claims Object Class 🦋
the sig_ref parameter in the Signature object class uses the SigReference object class. The SigReference object provides information used to match the Signature claims object to a specific target electronic signature and to verify the integrity of the target signature value and Signed Bytes, and it contains the following parameters:
"id": A String data type that contains an identifier assigned to the target signature. Inclusion of this parameter is OPTIONAL."sig_hash": A Base64Binary data type that contains a hash value of the target electronic signature value. This parameter MUST be present."sb_hash": A Base64Binary data type that contains a hash value of the Signed Bytes of the target electronic signature. This parameter MUST be present.
3.2.6. SignedDataReference Claims Object Class 🧚
the sig_data_ref parameter in the Signature object class uses the SignedDataReference object class. The SignedDataReference object provides information used to verify the target electronic signature references to Signed Data as well as to verify the integrity of all data that is signed by the target signature, and it contains the following parameters:
"ref": A String data type that contains a reference identifier for the data or data fragment covered by the target electronic signature. This parameter MUST be present."hash": A Base64Binary data type that contains the hash value for the data covered by the target electronic signature. This parameter MUST be present.
3.2.7. PolicyValidation Claims Object Class ✨
okay so the sig_val parameter in the Signature object class is where the PolicyValidation object class shows up 💅 It's basically the receipt for a validation run done under one specific policy, and it has these parameters:
"pol": a StringOrURI data type that holds the identifier of the policy governing the electronic signature verification process. This parameter MUST be present. 🎀"res": a String data type holding the result of the electronic signature verification process. The value MUST be one of"PASSED","FAILED", or"INDETERMINATE"as defined by [ETSI319102-1]. This parameter MUST be present. ✅"msg": a String data type with a message describing the result. Inclusion of this parameter is OPTIONAL. 🌸"ext": a MAP<String> data type that provides additional claims related to the target signature. The SVT issuer gets to decide when to add extension claims, but extension claims MUST follow any conventions defined in a profile of this specification (see Section 4). Inclusion of this parameter is OPTIONAL. 🧚
3.2.8. TimeValidation Claims Object Class 🦋
the time_val parameter in the Signature object class uses the TimeValidation object class. This one is the proof that the target signature existed at a particular time in the past ⏰ Evidence of time is typically a timestamp according to [RFC3161], but other types of evidence may be used, such as a previously issued SVT for this signature. The TimeValidation claims object contains these parameters:
"time": a NumericDate data type holding the verified time. This parameter MUST be present. 🕰️"type": a StringOrURI data type with an identifier of the type of evidence of time. This parameter MUST be present. 🏷️"iss": a StringOrURI data type with an identifier of the entity that issued the evidence of time. This parameter MUST be present. 🏛️"id": a String data type with a unique identifier assigned to the evidence of time. Inclusion of this parameter is OPTIONAL. 🔑"hash": a Base64Binary data type with the hash value of the validated evidence of time. Inclusion of this parameter is OPTIONAL. 🍓"val": an [Object<PolicyValidation>] data type holding an array of results of the time evidence validation according to defined validation procedures. Inclusion of this parameter is OPTIONAL. 📋"ext": a MAP<String> data type that provides additional claims related to the target signature. The SVT issuer decides when to add extension claims, but extension claims MUST follow any conventions defined in a profile of this specification (see Section 4). Inclusion of this parameter is OPTIONAL. 💜
3.2.9. CertReference Claims Object Class 🔐
the signer_cert_ref parameter in the Signature object class uses the CertReference object class. It references a single X.509 certificate or an X.509 certification path, either by giving the certificate data or by giving hash references for certificates that can be found in the target electronic signature. It has these parameters:
"type": a StringOrURI data type with an identifier of the type of reference. The type identifier MUST be one of the identifiers defined below, an identifier specified by the selected profile, or a URI identifier. This parameter MUST be present. 🪪"ref": a [String] data type holding an array of string parameters, following the conventions defined by the type identifier. At least one parameter MUST be present. 📦
The following type identifiers are defined:
"chain": the ref contains an array of Base64-encoded X.509 certificates [RFC5280]. The certificates MUST be provided in the order starting with the end entity certificate. Any following certificate must be able to validate the signature on the previous certificate in the array. ⛓️"chain_hash": the ref contains an array of one or more Base64-encoded hash values, where each hash value is a hash over an X.509 certificate [RFC5280] used to validate the signature. The certificates MUST be provided in the order starting with the end entity certificate. Any following certificate must be able to validate the signature on the previous certificate in the array. This option MUST NOT be used unless all hashed certificates are present in the target electronic signature. 🙈
Note: All certificates referenced using the identifiers above are X.509 certificates. Profiles of this specification MAY define alternative types of public key containers. However, a major function of these referenced certificates is not just to reference the public key but also to provide the subject name of the signer. So it is really important for the full function of an SVT that the referenced public key container also provides a way to identify the signer. 🫶
3.2.10. SVT JOSE Header 🪄
The SVT JWT MUST contain the following JSON Object Signing and Encryption (JOSE) header parameters, in accordance with Section 5 of [RFC7519]:
"typ": this parameter MUST have the string value"JWT"(upper case). 🔤"alg": this parameter identifies the algorithm used to sign the SVT JWT. The algorithm identifier MUST be specified in [RFC7518] or the IANA "JSON Web Signature and Encryption Algorithms" registry [IANA-JOSE-REG]. The specified signature hash algorithm MUST be identical to the hash algorithm specified in thehash_algoparameter of the SigValidation object within thesig_val_claimsclaim. 🔥
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 [RFC7515]. Each profile, as discussed in Section 4, MUST define the requirements for how the key or key reference is included in the header. 🗝️
4. Profiles 👑
Each signed document and signature type will have to define the precise content and use of several claims in the SVT. Think of it like each flavour of signature getting its own dress code 💅
At a minimum, each profile MUST define:
- The identifier of the profile 🪧
- How to reference the Signed Data content of the signed document 📄
- How to reference the target electronic signature and the Signed Bytes of the signature 🖊️
- How to reference certificates supporting each electronic signature 📜
- How to include public keys, or references to public keys, in the SVT 🔑
- Whether each electronic signature is supported by a single SVT, or whether one SVT may support multiple electronic signatures of the same document 🧩
A profile MAY also define:
- Explicit information on how to perform signature validation based on an SVT 🧭
- How to attach an SVT to an electronic signature or signed document 📎
4.1. Defined Profiles 🌈
The following profiles are defined in appendixes of this document:
- Appendix A: XML Signature Profile 🍰
- Appendix B: PDF Signature Profile 📕
- Appendix C: JWS Profile 🦄
Other documents MAY define other profiles that MAY complement, amend, or supersede these profiles. 💖
5. Signature Verification with an SVT 🔍
Signature verification based on an SVT MUST follow these steps:
- Locate all available SVTs for the signed document that are relevant for the target electronic signature. 🕵️
- Select the most recent SVT that can be successfully validated and meets the requirement of the relying party. 🥇
- Verify the integrity of the signature and the Signed Bytes of the target electronic signature using the
sig_refclaim. 🔒 - Verify that the Signed Data reference in the original electronic signature matches the reference values in the
sig_data_refclaim. 🔗 - Verify the integrity of referenced Signed Data using provided hash values in the
sig_data_refclaim. 🧮 - Obtain the verified certificates supporting the asserted electronic signature verification through the
signer_cert_refclaim. 📑 - Verify that signature validation policy results satisfy the requirements of the relying party. ✔️
- Verify that verified time results satisfy the context for the use of the signed document. ⏳
After successfully performing these steps, signature validity is established, as well as the trusted signer certificate binding the identity of the signer to the electronic signature. Main character energy, fr fr 👑✨
6. IANA Considerations 🏳️🌈
6.1. Claim Names Registration 🪪
IANA has registered the "sig_val_claims" claim name in the "JSON Web Token Claims" registry established by Section 10.1 of [RFC7519].
6.1.1. Registry Contents 📚
Claim Name: sig_val_claims
Claim Description: Signature Validation Token
Change Controller: IESG
Specification Document(s): Section 3.2.3 of RFC 93216.2. Header Parameter Names Registration 🏷️
IANA has registered the "svt" Header Parameter in the "JSON Web Signature and Encryption Header Parameters" registry established by [RFC7515].
6.2.1. Registry Contents 🎀
Header Parameter Name: svt
Header Parameter Description: Signature Validation Token
Header Parameter Usage Location(s): JWS
Change Controller: IESG
Specification Document(s): Appendix C.1.1 of RFC 93217. Security Considerations 🚨
7.1. Level of Reliance 🧠
An SVT lets a signature verifier still validate the original signature using the original signature data, and use the information in the SVT selectively to confirm the validity and integrity of the original data. For example, it can confirm the integrity of Signed Data or the validity of the signer's certificate, etc. 🔍
Another way to use an SVT is to completely rely on the validation conclusion provided by the SVT, and to skip revalidating the original signature value and the original certificate status checking data. 🙃
This choice is a decision made by the verifier according to its own policy and risk assessment. Choose wisely, bestie 💅
However, even when relying on the validation conclusion of an SVT, it is vital to still verify that the present SVT is correctly associated with the document and signature being validated. You do that by validating the hashed reference data in the SVT of the signature, the signing certificate chain, the Signed Data, and the Signed Bytes. No skipping this step, periodt 💀🔥
7.2. Aging Algorithms ⏳
Even if the SVT provides protection against algorithms becoming weakened or broken over time, this protection is only valid for as long as the algorithms used to sign the SVT are still considered secure. It is advisable to reissue SVTs when an algorithm protecting the SVT is getting close to its end of life. Expiry is not a vibe 😭
One way to increase resistance to algorithms becoming insecure is to issue multiple SVTs for the same signature, using different algorithms and key lengths. That way, one algorithm could still be secure even if the corresponding algorithm used in the alternative SVT is broken. Double coverage, iconic 🦋🛡️
8. References 📖
8.1. Normative References 📚
okay bestie, here's the must-read list 🫶 every doc below is something the spec leans on, so you need these to make sense of the rest:
[CADES] ETSI, "Electronic Signatures and Infrastructures (ESI); CAdES digital signatures; Part 1: Building blocks and CAdES baseline signatures", v1.1.1, ETSI EN 319 122-1, April 2016.
[ETSI319102-1] ETSI, "Electronic Signatures and Infrastructures (ESI); Procedures for Creation and Validation of AdES Digital Signatures; Part 1: Creation and Validation", v1.1.1, ETSI 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 -- Part 2: PDF 2.0", ISO 32000-2:2020, December 2020.
[PADES] ETSI, "Electronic Signatures and Infrastructures (ESI); PAdES digital signatures; Part 1: Building blocks and PAdES baseline signatures", v1.1.1, ETSI EN 319 142-1, April 2016.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC3125] Ross, J., Pinkas, D., and N. Pope, "Electronic Signature Policies", RFC 3125, DOI 10.17487/RFC3125, September 2001, <https://www.rfc-editor.org/info/rfc3125>.
[RFC3161] Adams, C., Cain, P., Pinkas, D., and R. Zuccherato, "Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)", RFC 3161, DOI 10.17487/RFC3161, August 2001, <https://www.rfc-editor.org/info/rfc3161>.
[RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. Wu, "Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework", RFC 3647, DOI 10.17487/RFC3647, November 2003, <https://www.rfc-editor.org/info/rfc3647>.
[RFC5035] Schaad, J., "Enhanced Security Services (ESS) Update: Adding CertID Algorithm Agility", RFC 5035, DOI 10.17487/RFC5035, August 2007, <https://www.rfc-editor.org/info/rfc5035>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/info/rfc5280>.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, DOI 10.17487/RFC5652, September 2009, <https://www.rfc-editor.org/info/rfc5652>.
[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, <https://www.rfc-editor.org/info/rfc7515>.
[RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, DOI 10.17487/RFC7518, May 2015, <https://www.rfc-editor.org/info/rfc7518>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, <https://www.rfc-editor.org/info/rfc7519>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/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 digital signatures; Part 1: Building blocks and XAdES baseline signatures", v1.1.1, ETSI EN 319 132-1, April 2016.
[XMLDSIG11] Eastlake 3rd, D., Reagle, J., Solo, D., Hirsch, F., Nystrom, M., Roessler, T., and K. Yiu, "XML Signature Syntax and Processing Version 1.1", W3C Proposed Recommendation, April 2013. Latest version available at https://www.w3.org/TR/xmldsig- core1/.
8.2. Informative References 🌸
[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, June 2019, <https://www.rfc-editor.org/info/rfc8610>.
Appendix A. XML Signature Profile 🎀
okay so this appendix is the XML profile for SVTs 💅 it's about signed XML docs, and it covers two things:
- How to include reference data related to XML signatures and XML documents in an SVT
- How to add an SVT token to an XML signature
XML documents can have any number of signature elements, and each one can sign an arbitrary number of fragments of XML documents. The actual signature element may be included in the signed XML document (enveloped), include the Signed Data (enveloping), or may be separate from the signed content (detached). Main character energy 👑
To provide a generic solution for any type of XML signature, an SVT is added to each XML signature element within the XML signature <ds:Object> element. 🦋
A.1. Notation ✨
A.1.1. References to XML Elements from XML Schemas
When referring to elements from the W3C XML Signature namespace (https://www.w3.org/2000/09/xmldsig#), the following syntax is used:
<ds:Signature>
When referring to elements from the ETSI XAdES XML Signature namespace (https://uri.etsi.org/01903/v1.3.2#), the following syntax is used:
<xades:CertDigest>
When referring to elements defined in this specification (http://id.swedenconnect.se/svt/1.0/sig-prop/ns), the following syntax is used:
<svt:Element>
A.2. SVT in XML Documents 🧚
When SVTs are provided for XML signatures, then one SVT MUST be provided for each XML signature.
An SVT embedded within the XML signature element MUST be placed in a <svt:SignatureValidationToken> element as defined in Appendix A.2.1.
A.2.1. SignatureValidationToken Signature Property 💖
The <svt:SignatureValidationToken> element MUST be placed in a <ds:SignatureProperty> element in accordance with [XMLDSIG11]. The <ds:SignatureProperty> element MUST be placed inside a <ds:SignatureProperties> element inside a <ds:Object> element inside a <ds:Signature> element.
Note: [XMLDSIG11] requires the Target attribute to be present in<ds:SignatureProperty>, referencing the signature targeted by this signature property. If an SVT is added to a signature that does not have an Id attribute, implementations SHOULD add an Id attribute to the<ds:Signature>element and reference that Id in the Target attribute. This Id attribute and Target attribute value matching is required by the [XMLDSIG11] standard, but it is redundant in the context of SVT validation as the SVT already contains information that uniquely identifies the target signature. Validation applications SHOULD NOT reject an SVT token because of Id and Target attribute mismatch and MUST rely on matching against a signature using signed information in the SVT itself.
The <svt:SignatureValidationToken> element is defined by the following XML Schema:
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
targetNamespace="http://id.swedenconnect.se/svt/1.0/sig-prop/ns"
xmlns:svt="http://id.swedenconnect.se/svt/1.0/sig-prop/ns">
<xs:element name="SignatureValidationToken"
type="svt:SignatureValidationTokenType" />
<xs:complexType name="SignatureValidationTokenType">
<xs:simpleContent>
<xs:extension base="xs:string">
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:schema>The SVT token MUST be included as a string representation of the SVT JWT. Note that this is the string representation of the JWT without further encoding. The SVT MUST NOT be represented by the Base64-encoded bytes of the JWT string.
Example:
<ds:Signature Id="MySignatureId">
...
<ds:Object>
<ds:SignatureProperties>
<ds:SignatureProperty Target="#MySignatureId">
<svt:SignatureValidationToken>
eyJ0eXAiOiJKV1QiLCJhb...2aNZ
</svt:SignatureValidationToken>
</ds:SignatureProperty>
</ds:SignatureProperties>
</ds:Object>
</ds:Signature>A.2.2. Multiple SVTs in an XML Signature 🍓
If a new SVT is stored in a signature that already contains a previously issued SVT, implementations can choose either to replace the existing SVT or to store the new SVT in addition to the existing SVT.
If the new SVT is stored in addition to the old SVT, it SHOULD be stored in a new <ds:SignatureProperty> element inside the existing <ds:SignatureProperties> element where the old SVT is located.
For interoperability robustness, signature validation applications MUST be able to handle signatures where the new SVT is located in a new <ds:Object> element. this one's a big deal, bestie 🙈
A.3. XML Signature SVT Claims 🌈
A.3.1. XML Profile Identifier
When this profile is used, the SigValidation object MUST contain a "profile" claim with the value "XML".
A.3.2. XML Signature Reference Data
The SVT Signature object MUST contain a "sig_ref" claim (SigReference object) with the following elements:
"id": The Id-attribute of the XML signature, if present."sig_hash": The hash over the signature value bytes."sb_hash": The hash over the canonicalized<ds:SignedInfo>element (the bytes the XML signature algorithm has signed to generate the signature value).
A.3.3. XML Signed Data Reference Data
The SVT Signature object MUST contain one instance of the "sig_data" claim (SignedData object) for each <ds:Reference> element in the <ds:SignedInfo> element. The "sig_data" claim MUST contain the following elements:
"ref": The value of the URI attribute of the corresponding<ds:Reference>element."hash": The hash of all bytes that were identified by the corresponding<ds:Reference>element after applying all identified canonicalization and transformation algorithms. These are the same bytes that are hashed by the hash value in the<ds:DigestValue>element inside the<ds:Reference>element.
A.3.4. XML Signer Certificate References
The SVT Signature object MUST contain a "signer_cert_ref" claim (CertReference object). The "type" parameter of the "signer_cert_ref" claim MUST be either "chain" or "chain_hash".
- The
"chain"type MUST be used when signature validation was performed using one or more certificates where some or all of the certificates in the chain are not present in the target signature. - The
"chain_hash"type MUST be used when signature validation was performed using one or more certificates where all of the certificates are present in the target signature.
A.4. JOSE Header 🦋
A.4.1. SVT Signing Key Reference ✨
okay so the SVT JOSE header for XML signatures must contain one of the following header parameters, following [RFC7515], to store a reference to the public key that verifies the signature on the SVT 🔑
"x5c": holds an X.509 certificate [RFC5280] or a chain of certificates. The certificate holding the public key that verifies the signature on the SVT MUST be the first certificate in the chain 💅"kid": a key identifier holding the Base64-encoded hash value of the certificate that can verify the signature on the SVT. The hash algorithm MUST be the same hash algorithm used when signing the SVT, as specified by the"alg"Header Parameter 🌸
Appendix B. PDF Signature Profile 📄
this appendix is the PDF glow-up 💖 it defines a profile for implementing SVTs with a signed PDF document, and it covers these aspects of SVT usage:
- How to include reference data related to PDF signatures and PDF documents in an SVT.
- How to add an SVT token to a PDF document.
PDF document signatures get added as incremental updates to the signed PDF document, and each one signs all data of the PDF document up until the current signature. When more than one signature is added to a PDF document, the previous signature is signed by the next signature, and it can not be updated with additional data after that happens 🦋
to keep things light on PDFs with multiple signatures, and to stay backwards compatible with PDF software that doesn't understand SVTs, PDF documents add one SVT token for all signatures of the PDF. It rides along as an extension to a document timestamp that's added to the signed PDF as an incremental update. This SVT covers all signatures of the signed PDF ✨
B.1. SVTs in PDF Documents
The SVT for a signed PDF document MAY provide signature validation information about any of the signatures present in the PDF 🎀 The SVT MUST contain a separate "sig" claim (Signature object) for each signature on the PDF that is covered by the SVT.
An SVT added to a signed PDF document MUST be added to a document timestamp in accordance with ISO 32000-2:2020 [ISOPDF2].
The document timestamp contains an [RFC3161] timestamp token (TSTInfo) in EncapsulatedContentInfo of the CMS signature. The SVT MUST be added to the timestamp token (TSTInfo) as an Extension object, as defined in Appendix B.1.1 🧚
B.1.1. SVT Extension to Timestamp Tokens
The SVT extension is an Extension suitable to be included in TSTInfo, as defined by [RFC3161] 💜
The SVT extension is identified by the Object Identifier (OID) 1.2.752.201.5.2.
This extension data (OCTET STRING) holds the bytes of the SVT JWT, represented as a UTF-8-encoded string.
This extension MUST NOT be marked critical.
Note: Extensions in timestamp tokens according to [RFC3161] are imported from the definition of the X.509 certificate extensions defined in [RFC5280] 🙈
B.2. PDF Signature SVT Claims
B.2.1. PDF Profile Identifier
When this profile is used, the SigValidation object MUST contain a "profile" claim with the value "PDF" 🌈
B.2.2. PDF Signature Reference Data
The SVT Signature object MUST contain a "sig_ref" claim (SigReference object) with the following elements:
"id": absent or a Null value."sig_hash": the hash over the signature value bytes."sb_hash": the hash over the DER-encoded SignedAttributes in SignerInfo.
B.2.3. PDF Signed Data Reference Data
The SVT Signature object MUST contain one instance of the "sig_data" claim (SignedData object) with the following elements:
"ref": the string representation of the ByteRange value of the PDF signature dictionary of the target signature. This is a sequence of integers separated by spaces, where each integer pair specifies the start index and length of a byte range."hash": the hash of all bytes identified by the ByteRange value. This is the concatenation of all byte ranges identified by the ByteRange value.
B.2.4. PDF Signer Certificate References
The SVT Signature object MUST contain a "signer_cert_ref" claim (CertReference object). The "type" parameter of the "signer_cert_ref" claim MUST be either "chain" or "chain_hash" 🫶
- The
"chain"type MUST be used when signature validation was performed using one or more certificates where some or all of the certificates in the chain are not present in the target signature. - The
"chain_hash"type MUST be used when signature validation was performed using one or more certificates where all of the certificates are present in the target signature.
Note: The referenced signer certificate MUST match any certificates referenced using ESSCertID or ESSCertIDv2 from [RFC5035] 🔥
B.3. JOSE Header
B.3.1. SVT Signing Key Reference
the SVT JOSE header must contain one of the following header parameters, in accordance with [RFC7515], for storing a reference to the public key used to verify the signature on the SVT 🗝️
"x5c": holds an X.509 certificate [RFC5280] or a chain of certificates. The certificate holding the public key that verifies the signature on the SVT MUST be the first certificate in the chain."kid": a key identifier holding the Base64-encoded hash value of the certificate that can verify the signature on the SVT. The hash algorithm MUST be the same hash algorithm used when signing the SVT, as specified by the"alg"Header Parameter. The referenced certificate SHOULD be the same certificate that was used to sign the document timestamp that contains the SVT 👑
Appendix C. JWS Profile 🦋
this appendix is the JWS era 🎀 It defines a profile for implementing SVTs with a JWS signed payload according to [RFC7515], and it covers these aspects of SVT usage:
- How to include reference data related to JWS signatures in an SVT.
- How to add an SVT token to JWS signatures.
A JWS may have one or more signatures, depending on its serialization format, all signing the same payload data. A JWS either contains the data to be signed (enveloping), or it may sign any externally associated payload data (detached) 🌸
To give JWS a generic solution, an SVT is added to each present signature as a JWS Unprotected Header. If a JWS includes multiple signatures, then each signature includes its own SVT 💅
C.1. SVT in JWS
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, then each present SVT MUST provide information exclusively related to one associated signature, and it MUST NOT include information about any other signature in the JWS ✨
Each SVT is stored in its associated signature's "svt" header, as defined in Appendix C.1.1.
C.1.1. "svt" Header Parameter
The "svt" (Signature Validation Token) Header Parameter is used to contain an array of SVT tokens to support validation of the associated signature. Each SVT token in the array has the format of a JWT, as defined in [RFC7519], and it is stored using its natural string representation without further wrapping or encoding 🍓
The "svt" Header Parameter, when used, MUST be included as a JWS Unprotected Header.
Note: A JWS Unprotected Header is not supported with JWS Compact Serialization. So adding an SVT token to a JWS means that JWS JSON Serialization MUST be used, either in the form of general JWS JSON Serialization (for one or more signatures) or in the form of flattened JWS JSON Serialization (optionally used when only one signature is present in the JWS) 🙈
C.1.2. Multiple SVTs in a JWS Signature
If a new SVT is stored in a signature that already contains a previously issued SVT, implementations can choose either to replace the existing SVT or to store the new SVT in addition to the existing SVT 🌈
If a JWS signature already contains an array of SVTs and a new SVT is to be added, then the new SVT MUST be added to the array of SVT tokens in the existing "svt" Header Parameter 🫶
C.2. JWS Signature SVT Claims
C.2.1. JWS Profile Identifier
When this profile is used, the SigValidation object MUST contain a "profile" claim with the value "JWS" 💖
C.2.2. JWS Signature Reference Data
The SVT Signature object MUST contain a "sig_ref" claim (SigReference object) with the following elements:
"sig_hash": the hash over the associated signature value (the bytes of the base64url-decoded signature parameter)."sb_hash": the hash over all bytes signed by the associated signature (the JWS Signing Input according to [RFC7515]).
C.2.3. JWS Signed Data Reference Data
The SVT Signature object MUST contain one instance of the "sig_data" claim (SignedData object) with the following elements:
"ref": this parameter MUST hold one of the following three possible values:- The explicit string value
"payload", if the signed JWS Payload is embedded in a"payload"member of the JWS. - The explicit string value
"detached", if the JWS signs detached payload data without explicit reference. - A URI that can be used to identify or fetch the detached Signed Data. The means to determine the URI for the detached Signed Data is outside the scope of this specification.
- The explicit string value
"hash": the hash over the JWS Payload data bytes (not its base64url-encoded string representation).
C.2.4. JWS Signer Certificate References
The SVT Signature object MUST contain a "signer_cert_ref" claim (CertReference object). The "type" parameter of the "signer_cert_ref" claim MUST be either "chain" or "chain_hash" 🎀
- The
"chain"type MUST be used when signature validation was performed using one or more certificates where some or all of the certificates in the chain are not present in the target signature. - The
"chain_hash"type MUST be used when signature validation was performed using one or more certificates where all of the certificates are present in the target signature JOSE header using the"x5c"Header Parameter.
C.3. SVT JOSE Header
C.3.1. SVT Signing Key Reference
the SVT JOSE header must contain one of the following header parameters, in accordance with [RFC7515], for storing a reference to the public key used to verify the signature on the SVT 🔐
"x5c": holds an X.509 certificate [RFC5280] or a chain of certificates. The certificate holding the public key that verifies the signature on the SVT MUST be the first certificate in the chain."kid": a key identifier holding the Base64-encoded hash value of the certificate that can verify the signature on the SVT. The hash algorithm MUST be the same hash algorithm used when signing the SVT, as specified by the"alg"Header Parameter.
Appendix D. Schemas 🧁
D.1. Concise Data Definition Language (CDDL) 💅
okay bestie, this part is the informative CDDL [RFC8610] that maps out what an SVT token looks like 🗺️ it's just a helpful map, so you can see the whole structure in one glance ✨
svt = {
jti: text
iss: text
iat: uint
? aud: text / [* text]
? exp: uint
sig_val_claims: SigValClaims
}
SigValClaims = {
ver: text
profile: text
hash_algo: text
sig: [+ Signature]
? ext: Extension
}
Signature = {
sig_ref: SigReference
sig_data_ref: [+ SignedDataReference]
signer_cert_ref: CertReference
sig_val: [+ PolicyValidation]
? time_val: [* TimeValidation]
? ext: Extension
}
SigReference = {
? id: text / null
sig_hash: binary-value
sb_hash: binary-value
}
SignedDataReference = {
ref: text
hash: binary-value
}
CertReference = {
type: "chain" / "chain_hash"
ref: [+ text]
}
PolicyValidation = {
pol: text
res: "PASSED" / "FAILED" / "INDETERMINATE"
? msg: text / null
? ext: Extension
}
TimeValidation = {
"time": uint
type: text
iss: text
? id: text / null
? hash: binary-value / null
? val: [* PolicyValidation]
? ext: Extension
}
Extension = {
+ text => text
} / null
binary-value = text ; base64 classic with paddingD.2. JSON Schema 🎀
next up is the informative JSON schema, which describes the syntax of the SVT token payload 💖 same vibe as the CDDL, just in JSON form so you can plug it into your tooling 🧚
{
"$schema": "https://json-schema.org/draft/2020-12/schema",
"title": "Signature Validation Token JSON Schema",
"description": "Schema defining the payload format for SVTs",
"type": "object",
"required": [
"jti",
"iss",
"iat",
"sig_val_claims"
],
"properties": {
"jti": {
"description": "JWT ID",
"type": "string"
},
"iss": {
"description": "Issuer",
"type": "string"
},
"iat": {
"description": "Issued At",
"type": "integer"
},
"aud": {
"description": "Audience",
"type": [
"string",
"array"
],
"items": {"type": "string"}
},
"exp": {
"description": "Expiration time (seconds since epoch)",
"type": "integer"
},
"sig_val_claims": {
"description": "Signature validation claims",
"type": "object",
"required": [
"ver",
"profile",
"hash_algo",
"sig"
],
"properties": {
"ver": {
"description": "Version",
"type": "string"
},
"profile": {
"description": "Implementation profile",
"type": "string"
},
"hash_algo": {
"description": "Hash algorithm URI",
"type": "string"
},
"sig": {
"description": "Validated signatures",
"type": "array",
"items": {
"$ref": "#/$def/Signature"
},
"minItems": 1
},
"ext": {
"description": "Extension map",
"$ref": "#/$def/Extension"
}
},
"additionalProperties": false
}
},
"additionalProperties": false,
"$def": {
"Signature":{
"type": "object",
"required": [
"sig_ref",
"sig_data_ref",
"signer_cert_ref",
"sig_val"
],
"properties": {
"sig_ref": {
"description": "Signature Reference",
"$ref": "#/$def/SigReference"
},
"sig_data_ref": {
"description": "Signed data array",
"type": "array",
"items": {
"$ref" : "#/$def/SignedDataReference"
},
"minItems": 1
},
"signer_cert_ref": {
"description": "Signer certificate reference",
"$ref": "#/$def/CertReference"
},
"sig_val": {
"description": "Signature validation results",
"type": "array",
"items": {
"$ref": "#/$def/PolicyValidation"
},
"minItems": 1
},
"time_val": {
"description": "Time validations",
"type": "array",
"items": {
"$ref": "#/$def/TimeValidation"
}
},
"ext": {
"description": "Extension map",
"$ref": "#/$def/Extension"
}
},
"additionalProperties": false
},
"SigReference":{
"type": "object",
"required": [
"sig_hash",
"sb_hash"
],
"properties": {
"sig_hash": {
"description": "Hash of the signature value",
"type": "string",
"format": "base64"
},
"sb_hash": {
"description": "Hash of the Signed Bytes",
"type": "string",
"format": "base64"
},
"id": {
"description": "Signature ID reference",
"type": ["string","null"]
}
},
"additionalProperties": false
},
"SignedDataReference": {
"type": "object",
"required": [
"ref",
"hash"
],
"properties": {
"ref": {
"description": "Reference to the signed data",
"type": "string"
},
"hash": {
"description": "Signed data hash",
"type": "string",
"format": "base64"
}
},
"additionalProperties": false
},
"CertReference":{
"type": "object",
"required": [
"type",
"ref"
],
"properties": {
"type": {
"description": "Type of certificate reference",
"type": "string",
"enum": ["chain","chain_hash"]
},
"ref": {
"description": "Certificate reference data",
"type": "array",
"items": {
"type": "string",
"format": "base64"
},
"minItems": 1
}
},
"additionalProperties": false
},
"PolicyValidation":{
"type": "object",
"required": [
"pol",
"res"
],
"properties": {
"pol": {
"description": "Policy identifier",
"type": "string"
},
"res": {
"description": "Signature validation result",
"type": "string",
"enum": ["PASSED","FAILED","INDETERMINATE"]
},
"msg": {
"description": "Message",
"type": ["string","null"]
},
"ext": {
"description": "Extension map",
"$ref": "#/$def/Extension"
}
},
"additionalProperties": false
},
"TimeValidation":{
"type": "object",
"required": [
"time",
"type",
"iss"
],
"properties": {
"time": {
"description": "Verified time",
"type": "integer"
},
"type": {
"description": "Type of time validation proof",
"type": "string"
},
"iss": {
"description": "Issuer of the time proof",
"type": "string"
},
"id": {
"description": "Time evidence identifier",
"type": ["string","null"]
},
"hash": {
"description": "Hash of time evidence",
"type": ["string","null"],
"format": "base64"
},
"val": {
"description": "Validation result",
"type": "array",
"items": {
"$ref": "#/$def/PolicyValidation"
}
},
"ext": {
"description": "Extension map",
"$ref": "#/$def/Extension"
}
},
"additionalProperties": false
},
"Extension": {
"description": "Extension map",
"type": ["object","null"],
"required": [],
"additionalProperties": {
"type": "string"
}
}
}
}Appendix E. Examples ✨
okay so this appendix is the vibe 🎀 it walks through a basic SVT from this spec, issued for a signed PDF document 📄 you get the whole token first, then the decoded header and claims so you can actually read what's inside 🫶
Heads up: line breaks in the decoded example are only there so it's easier to read 👀 real valid JSON can't have them 💅
Signature validation token JWT:
eyJraWQiOiJPZW5JKzQzNEpoYnZmRG50ZlZcLzhyT3hHN0ZrdnlqYUtWSmFWcUlG
QlhvaFZoQWU1Zks4YW5vdjFTNjg4cjdLYmFsK2Z2cGFIMWo4aWJnNTJRQnkxUFE9
PSIsInR5cCI6IkpXVCIsImFsZyI6IlJTNTEyIn0.eyJhdWQiOiJodHRwOlwvXC9l
eGFtcGxlLmNvbVwvYXVkaWVuY2UxIiwiaXNzIjoiaHR0cHM6XC9cL3N3ZWRlbmNv
bm5lY3Quc2VcL3ZhbGlkYXRvciIsImlhdCI6MTYwMzQ1ODQyMSwianRpIjoiNGQx
Mzk2ZjFmZjcyOGY0MGQ1MjQwM2I2MWM1NzQ0ODYiLCJzaWdfdmFsX2NsYWltcyI6
eyJzaWciOlt7ImV4dCI6bnVsbCwic2lnX3ZhbCI6W3sibXNnIjoiT0siLCJleHQi
Om51bGwsInJlcyI6IlBBU1NFRCIsInBvbCI6Imh0dHA6XC9cL2lkLnN3ZWRlbmNv
bm5lY3Quc2VcL3N2dFwvc2lndmFsLXBvbGljeVwvdHMtcGtpeFwvMDEifV0sInNp
Z19yZWYiOnsic2lnX2hhc2giOiJ5Y2VQVkxJemRjcEs5N0lZT2hGSWYxbnk3OUht
SUNiU1Z6SWVaTmJpem83ckdJd0hOTjB6WElTeUtHakN2bm9uT2FRR2ZMXC9QM3ZE
dEI4OHlLU1dlWGc9PSIsImlkIjoiaWQtNzM5ODljNmZjMDYzNjM2YWI1ZTc1M2Yx
MGY3NTc0NjciLCJzYl9oYXNoIjoiQm9QVjRXQ0E5c0FJYWhqSzFIYWpmRnhpK0F6
QzRKR1R1ZjM5VzNaV2pjekRDVVJ4ZGM5WWV0ZUh0Y3hHVmVnZ3B4SEo3NVwvY1E3
SE4xZERkbGl5SXdnPT0ifSwic2lnbmVyX2NlcnRfcmVmIjp7InJlZiI6WyIxK2Fh
SmV0ZzdyZWxFUmxVRFlFaVU0WklaaFQ0UlV2aUlRWnVLN28xR0ZLYVRQUTZ5K2t4
XC9QTnREcnB1cVE2WGZya0g5d1lESzRleTB5NFdyTkVybnc9PSIsImg0UER4YjVa
S214MWVUU3F2VnZZRzhnMzNzMDVKendCK05nRUhGVTRnYzl0cUcwa2dIa2Y2VzNv
THprVHd3dXJJaDZZOUFhZlpZcWMyelAycEUycDRRPT0iLCJEZDJDNXNCMElPUWVN
Vm5FQmtNNVE5Vzk2bUJITnd3YTJ0elhNcytMd3VZY09VdlBrcnlHUjBhUEc4Tzlu
SVAzbGJ3NktqUTFoRG1SazZ6Qzh4MmpkZz09Il0sInR5cGUiOiJjaGFpbl9oYXNo
In0sInNpZ19kYXRhX3JlZiI6W3sicmVmIjoiIiwiaGFzaCI6IkZjR3BPT2Y4aWxj
UHQyMUdEZDJjR25MR0R4UlM1ajdzdk00YXBwMkg0MWRERUxtMkN6Y2VUWTAybmRl
SmZXamludG1RMzc2SWxYVE9BcjMxeXpZenNnPT0ifSx7InJlZiI6IiN4YWRlcy0x
MWExNTVkOTJiZjU1Nzc0NjEzYmI3YjY2MTQ3N2NmZCIsImhhc2giOiJLUmtnYlo2
UFwvbmhVNjNJTWswR2lVZlVcL0RUd3ZlWWl0ZVFrd0dlSnFDNUJ6VE5WOGJRYnBl
ZFRUdVdKUHhxdkowUlk4NGh3bTdlWVwvZzBIckFPZWdLdz09In1dLCJ0aW1lX3Zh
bCI6W119XSwiZXh0IjpudWxsLCJ2ZXIiOiIxLjAiLCJwcm9maWxlIjoiWE1MIiwi
aGFzaF9hbGdvIjoiaHR0cDpcL1wvd3d3LnczLm9yZ1wvMjAwMVwvMDRcL3htbGVu
YyNzaGE1MTIifX0.TdHCoIUSZj2zMINKg7E44-8VE_mJq6TG1OoPwnYSs_hyUbuX
mrLJpuk8GR5YrndeOucPUYAwPxHt_f68JIQyFTi0agO9VJjn1R7Pj3Jt6WG9pYVN
n5LH-D1maxD11ZxxbcYeHbsstd2Sy2uMa3BdpsstGdPymSmc6GxY5uJoL0-5vwo_
3l-4Bb3LCTiuxYPcmztKIbDy2hEgJ3Hx1K4HF0SHgn3InpqBev3hm2SLw3hH5BCM
rywBAhHYE6OGE0aOJ6ktA5UP0jIIHfaw9i1wIiJtHTaGuvtyWSLk5cshmun9Hkdk
kRTA75bzuq0Iyd0qh070rA8Gje-s4Tw4xzttgKx1KSkvy8n5FqvzWdsZvclCG2mY
Y9rMxh_7607NXcxajAP4yDOoKNs5nm937ULe0vCN8a7WTrFuiaGjry7HhzRM4C5A
qxbDOBXPLyoMr4qn4LRJCHxOeLZ6o3ugvDOOWsyjk3eliyBwDu8qJH7UmyicLxDc
Cr0hUK_kvREqjD2ZDecoded JWT Header: here's the header all unwrapped so you can see the fields 🍓
{
"kid":"OenI+434JhbvfDntfV\/8rOxG7FkvyjaKVJaVqIFBXohVhAe5fK8anov
1S688r7Kbal+fvpaH1j8ibg52QBy1PQ==",
"typ":"JWT",
"alg":"RS512"
}Decoded JWT Claims: and now the good stuff, the claims 🧚✨
{
"aud" : "http://example.com/audience1",
"iss" : "https://swedenconnect.se/validator",
"iat" : 1603458421,
"jti" : "4d1396f1ff728f40d52403b61c574486",
"sig_val_claims" : {
"sig" : [ {
"ext" : null,
"sig_val" : [ {
"msg" : "OK",
"ext" : null,
"res" : "PASSED",
"pol" : "http://id.swedenconnect.se/svt/sigval-policy/
ts-pkix/01"
} ],
"sig_ref" : {
"sig_hash" : "ycePVLIzdcpK97IYOhFIf1ny79HmICbSVzIeZNbizo7rGIw
HNN0zXISyKGjCvnonOaQGfL/P3vDtB88yKSWeXg==",
"id" : "id-73989c6fc063636ab5e753f10f757467",
"sb_hash" : "BoPV4WCA9sAIahjK1HajfFxi+AzC4JGTuf39W3ZWjczDCURx
dc9YeteHtcxGVeggpxHJ75/cQ7HN1dDdliyIwg=="
},
"signer_cert_ref" : {
"ref" : [ "1+aaJetg7relERlUDYEiU4ZIZhT4RUviIQZuK7o1GFKaTPQ6y+
kx/PNtDrpuqQ6XfrkH9wYDK4ey0y4WrNErnw==",
"h4PDxb5ZKmx1eTSqvVvYG8g33s05JzwB+NgEHFU4gc9tqG0kgH
kf6W3oLzkTwwurIh6Y9AafZYqc2zP2pE2p4Q==",
"Dd2C5sB0IOQeMVnEBkM5Q9W96mBHNwwa2tzXMs+LwuYcOUvPkr
yGR0aPG8O9nIP3lbw6KjQ1hDmRk6zC8x2jdg==" ],
"type" : "chain_hash"
},
"sig_data_ref" : [ {
"ref" : "",
"hash" : "FcGpOOf8ilcPt21GDd2cGnLGDxRS5j7svM4app2H41dDELm2Czc
eTY02ndeJfWjintmQ376IlXTOAr31yzYzsg=="
}, {
"ref" : "#xades-11a155d92bf55774613bb7b661477cfd",
"hash" : "KRkgbZ6P/nhU63IMk0GiUfU/DTwveYiteQkwGeJqC5BzTNV8bQb
pedTTuWJPxqvJ0RY84hwm7eY/g0HrAOegKw=="
} ],
"time_val" : [ ]
} ],
"ext" : null,
"ver" : "1.0",
"profile" : "XML",
"hash_algo" : "http://www.w3.org/2001/04/xmlenc#sha512"
}
}Authors' Addresses 💜
meet the people behind this spec 🎀 here's where you can find them 🫶
Stefan Santesson
IDsec Solutions AB
Forskningsbyn Ideon
SE-223 70 Lund
Sweden
Email: sts@aaa-sec.comRuss Housley
Vigil Security, LLC
516 Dranesville Road
Herndon, VA 20170
United States of America
Email: housley@vigilsec.com📦 where this page comes from
- ietf: rfc9321 2022-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms