Movatterモバイル変換

[0]ホーム
URL:

RFC 9321Signature Validation TokenOctober 2022
Santesson & HousleyInformational[Page]
Stream:
Independent Submission
RFC:
9321
Category:
Informational
Published:
ISSN:
2070-1721
Authors:
S. Santesson
IDsec Solutions
R. Housley
Vigil Security

RFC 9321

Signature Validation Token

Abstract

Electronic signatures have a limited lifespan with respect to the time period that theycan be validated and determined to be authentic. The Signature Validation Token (SVT)defined in this specification provides evidence that asserts the validity of anelectronic signature. The SVT is provided by a trusted authority, which asserts thata particular signature was successfully validated according to defined procedures ata certain time. Any future validation of that electronic signature can be satisfied byvalidating the SVT without any need to also validate the original electronic signature orthe associated digital certificates. The SVT supports electronic signatures in Cryptographic Message Syntax (CMS), XML,PDF, and JSON documents.

Status of This Memo

This document is not an Internet Standards Track specification; it is published for informational purposes.

This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained athttps://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) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

▲

Table of Contents

1.Introduction

Electronic signatures have a limited lifespan regarding when they can be validatedand determined to be authentic. Many factors make it more difficult to validateelectronic signatures over time. For example:

The challenges to validation of an electronic signature increaseover time, and eventually it may simply be impossible to verify thesignature with a sufficient level of assurance.

Existing standards, such as the ETSI XAdES[XADES] profile for XMLsignatures[XMLDSIG11], ETSI PAdES[PADES] profile for PDF signatures[ISOPDF2], and ETSI CAdES[CADES] profile for CMS signatures[RFC5652], can be used to extend the time within which a signature can bevalidated at the cost of significant complexity, which involves storing andvalidating significant amounts of external evidence data such as revocation data,signature time stamps, and archival time stamps.

The Signature Validation Token (SVT) defined in this specification takes atrusted signature validation process as an input and preserves the validation resultfor the associated signature and signed document. The SVT asserts that a particularelectronic signature was successfully validated by a trusted authority according todefined procedures at a certain time. Those proceduresMUST include checksthat the signature match the signed document, checks that the signature can be validated bythe signing certificate, and checks that the signing certificate pass certificatepath validation[RFC5280].Those proceduresMAY also include checks associated with a particular trust policy such asthat an acceptable certificate policy[RFC5280][RFC3647] was used to issue thesigner's certificate and checks that an acceptable signature policy was used bythe signer[RFC3125].

Once the SVT is issued by a trustedauthority, any future validation of that electronic signature can be satisfied by validatingthe SVT without any need to also revalidate the original electronic signature.

As the SVT is used to preserve validation results obtained through applying existingstandards for signature validation, it is complementary to and not a replacement for such standards,including the ETSI standards for long-term validation listed above.The SVT does, however, have the potentially positive effect that it may significantly reduce the need toapply complex long-term validation and preservation techniques for signature validationif an SVT is issued and applied to the signed document at an early stage where the signaturecan be validated without support of large amounts of external evidence.The use of SVTs may therefore drastically reduce the complexity of revalidation of oldarchived electronic signatures.

The SVT can be signed with private keys and algorithms thatprovide confidence for a considerable time period. In fact, multiple SVTs can be usedto offer greater assurance. For example, one SVT could be produced with a large RSAprivate key, a second one with a strong elliptic curve, and a third one with a quantumsafe digital signature algorithm to protect against advances in computing power andcryptanalytic capabilities. Further, the trusted authority can add additional SVTsin the future using fresh private keys and signatures to extend the lifetime of the SVTs if necessary.

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 use the following terms:

Signed Data:
The data covered by a particular electronic signature. This is typically equivalent to the signed content of a document, and it represents the data that the signer intended to sign. In some cases, such as in some XML signatures, the Signed Data can be the collection of several data fragments each referenced by the signature. In the case of PDF, this is the data covered by the "ByteRange" parameter in the signature dictionary. In JSON Web Signature (JWS), this is the unencoded payload data (before base64url encoding).
Signed Bytes:
These are the actual bytes of data that were hashed and signed by the digital signature algorithm. In most cases, this is not the actual Signed Data but a collection of signature metadata that includes references (hash) of the Signed Data as well as information about algorithms and other data bound to a signature. In XML, this is the canonicalized SignedInfo element. In CMS and PDF signatures, this is the DER-encoded SignedAttributes structure. In JWS, this is the protected header and payload data formatted according to[RFC7515].

When these terms are used as defined in this section, they appear with acapitalized first letter.

3.Signature Validation Token

3.1.Signature Validation Token Function

The Signature Validation Token (SVT) is created by a trusted service to assertevidence of successful electronic signature validation using a well-defined andtrustworthy signature validation process. The SVT binds the validation result tothe validated signature, the document signed by the signature, and the certificate of the signer.This allows a relying party to verify the validity of a signed documentwithout having to revalidate the original signature or to reuse any of its associatedcryptographic algorithms for as long as the SVT itself can be validated.The SVT achieves this by binding the following information toa specific electronic signature:

  • A unique identification of the electronic signature.
  • The data and metadata signed by the electronic signature.
  • The signer's certificate that was validated as part of electronic signature verification.
  • The certification path that was used to validate the signer's certificate.
  • An assertion providing evidence of signature verification, the time the verification was performed, the procedures used to verify the electronic signature, and the outcome of the verification.
  • An assertion providing evidence of the time at which the signature is known to have existed, the procedures used to validate the time of existence, and the outcome of the validation.

The SVT aims to support long-term validation that can be further extended into the future by applying the following strategies:

  • by using secure algorithms with long life expectancy when signing the SVT
  • by reissuing the SVT before it becomes insecure or is considered expired
  • optionally, by issuing multiple SVTs with different algorithms to provide redundancy in case one algorithm is broken

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 the following data types:

String:
JSON Data Type of string that contains an arbitrary case-sensitive string value.
Base64Binary:
JSON Data Type of string that contains a Base64-encoded byte array of binary data.
StringOrURI:
JSON Data Type of string that contains an arbitrary string or a URI as defined in[RFC7519]. It isREQUIRED 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-231 to 231-1).
Long:
JSON Data Type of number that contains a 64-bit signed integer value (from -263 to 263-1).
NumericDate:
JSON Data Type of number that contains data as defined in[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 orfalse.
Object<Class>:
A JSON object holding a claims object of a class defined in thisspecification (seeSection 3.2.2).
Map<Type>:
A JSON object with name-value pairs where the value is an object of thespecified Type in the notation. For example, Map<String> is a JSONobject 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 arrayis expressed in this specification by square brackets. For example, [String]indicates an array of String values, and [Object<DocHash>] indicates anarray of DocHash objects.
Null:
A JSON null that represents an absent value. A claim with a null value isequivalent with an absent claim.

3.2.2.Signature Validation Token JWT Claims

The SVTMUST contain only JWT claims in the following list:

"jti":
A String data type that is a "JWT ID" registered claim according to[RFC7519]. It isRECOMMENDED that the identifier holds a hexadecimal string representation of a 128-bit unsigned integer. An SVTMUST 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 valueSHOULD have the value of a URI based on a domain owned by the issuer. An SVTMUST 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 SVTMUST 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 identifierMAY identify a single entity, a group of entities, or a common policy adopted by a group of entities. If only one value is provided, itMAY be provided as a single StringOrURI data type value instead of as an array of values. Inclusion of the "Audience" claim in an SVT isOPTIONAL.
"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 isOPTIONAL.
"sig_val_claims":
An Object<SigValidation> data type that contains signature validation claims for this SVT extending the standard registered JWT claims above. An SVTMUST contain one sig_val_claims claim.

Note: An SVT asserts that a particular validation process was undertaken at a statedtime. This fact never changes and never expires. However, some other aspectsof the SVT such as liability for false claims or service provision related to a specificSVT may expire after a certain period of time, such as a service where an old SVT can beupgraded 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 objectholds all custom claims, and a SigValidation object contains the following parameters:

"ver":
A String data type representing the version. This parameterMUST 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 parameterMUST be present.
"hash_algo":
A URI data type that identifies the hash algorithm used to compute the hash values within the SVT. The URI identifierMUST be one defined in[RFC9231] or in the IANA registry defined by this specification. This parameterMUST be present.
"sig":
An [Object<Signature>] data type that gives information aboutvalidated electronic signatures as an array of Signature objects. If the SVTcontains signature validation evidence for more than one signature, then eachsignature is represented by a separate Signature object. At least oneSignature objectMUST be present.
"ext":
A Map<String> data type that provides additional claims related tothe SVT. Extension claims are added at the discretion of the SVT issuer;however, extension claimsMUST follow any conventions definedin a profile of this specification (seeSection 4). Inclusionof this parameter isOPTIONAL.

3.2.4.Signature Claims Object Class

The sig parameter in the SigValidation object class uses the Signature objectclass. The Signature object contains claims related to signature validationevidence for one signature, and it contains the following parameters:

"sig_ref":
An Object<SigReference> data type that contains referenceinformation identifying the target signature. This parameterMUST be present.
"sig_data_ref":
An [Object<SignedDataReference>] data type that contains an array ofreferences to Signed Data that was signed by the target electronicsignature. At least one SignedDataReference objectMUST bepresent.
"signer_cert_ref":
An Object<CertReference> data type that references the signer'scertificate and optionally references a supporting certification path thatwas used to verify the target electronic signature. This parameterMUST be present.
"sig_val":
An [Object<PolicyValidation>] data type that contains an array ofresults of signature verification according to defined procedures. At leastone PolicyValidation objectMUST be present.
"time_val":
An [Object<TimeValidation>] data type that contains an array of timeverification results showing that the target signature has existed at a specifictime in the past. Inclusion of this parameter isOPTIONAL.
"ext":
A MAP<String> data type that provides additional claims related tothe target signature. Extension claims are added at the discretion of the SVTissuer; however, extension claimsMUST follow any conventionsdefined in a profile of this specification (seeSection 4). Inclusion of this parameter isOPTIONAL.

3.2.5.SigReference Claims Object Class

The sig_ref parameter in the Signature object class uses the SigReference objectclass. The SigReference object provides information used to match the Signatureclaims object to a specific target electronic signature and to verify the integrityof 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 targetsignature. Inclusion of this parameter isOPTIONAL.
"sig_hash":
A Base64Binary data type that contains a hash value of the targetelectronic signature value. This parameterMUST be present.
"sb_hash":
A Base64Binary data type that contains a hash value of the Signed Bytes ofthe target electronic signature. This parameterMUST bepresent.

3.2.6.SignedDataReference Claims Object Class

The sig_data_ref parameter in the Signature object class uses the SignedDataReference objectclass. The SignedDataReference object provides information used to verify the target electronicsignature references to Signed Data as well as to verify the integrity of all data thatis signed by the target signature, and it contains the following parameters:

"ref":
A String data type that contains a reference identifier for the data ordata fragment covered by the target electronic signature. This parameterMUST be present.
"hash":
A Base64Binary data type that contains the hash value for the data coveredby the target electronic signature. This parameterMUST bepresent.

3.2.7.PolicyValidation Claims Object Class

The sig_val parameter in the Signature object class uses the PolicyValidation objectclass. The PolicyValidation object provides information about the result of a validationprocess according to a specific policy, and it contains the following parameters:

"pol":
A StringOrURI data type that contains the identifier of the policy governing the electronic signature verification process. This parameterMUST be present.
"res":
A String data type that contains the result of the electronic signature verification process. The valueMUST be one of "PASSED", "FAILED", or "INDETERMINATE" as defined by[ETSI319102-1]. This parameterMUST be present.
"msg":
A String data type that contains a message describing the result. Inclusion of this parameter isOPTIONAL.
"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 claimsMUST follow any conventions defined in a profile of this specification (seeSection 4). Inclusion of this parameter isOPTIONAL.

3.2.8.TimeValidation Claims Object Class

The time_val parameter in the Signature object class uses the TimeValidation objectclass. The TimeValidation claims object provides information about the result ofvalidating evidence of time asserting that the target signature existed at a particulartime 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 the following parameters:

"time":
A NumericDate data type that contains the verified time. This parameterMUST be present.
"type":
A StringOrURI data type that contains an identifier of the type of evidence of time. This parameterMUST be present.
"iss":
A StringOrURI data type that contains an identifier of the entity that issued the evidence of time. This parameterMUST be present.
"id":
A String data type that contains an unique identifier assigned to the evidence of time. Inclusion of this parameter isOPTIONAL.
"hash":
A Base64Binary data type that contains the hash value of the validated evidence of time. Inclusion of this parameter isOPTIONAL.
"val":
An [Object<PolicyValidation>] data type that contains an array of results of the time evidence validation according to defined validation procedures. Inclusion of this parameter isOPTIONAL.
"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 claimsMUST follow any conventions defined in a profile of this specification (seeSection 4). Inclusion of this parameter isOPTIONAL.

3.2.9.CertReference Claims Object Class

The signer_cert_ref parameter in the Signature object class uses the CertReference objectclass. The CertReference object references a single X.509 certificate or a X.509certification path either by providing the certificate data or by providing hashreferences for certificates that can be located in the target electronic signature, andit contains the following parameters:

"type":
A StringOrURI data type that contains an identifier of the type of reference. The type identifierMUST be one of the identifiers defined below, an identifier specified by the selected profile, or a URI identifier. This parameterMUST be present.
"ref":
A [String] data type that contains an array of string parameters according to conventions defined by the type identifier. At least one parameterMUST be present.

The following type identifiers are defined:

"chain":
The ref contains an array of Base64-encoded X.509 certificates[RFC5280]. The certificatesMUST be provided in the order starting with the end entity certificate. Any following certificate must be able to validate the signature on the previous certificate in the array.
"chain_hash":
The ref contains an array of one or more Base64-encoded hash values where each hash value is a hash over a X.509 certificate[RFC5280] used to validate the signature. The certificatesMUST 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 optionMUST 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 specificationMAY define alternative types of public key containers;however, a major function of these referenced certificates is not just to referencethe public key but also to provide the subject name of the signer. It is thereforeimportant for the full function of an SVT that the referenced public key container alsoprovides the means to identify the signer.

3.2.10.SVT JOSE Header

The SVT JWTMUST contain the following JSON Object Signing and Encryption (JOSE) header parameters in accordance withSection 5 of [RFC7519]:

"typ":
This parameterMUST have the string value "JWT" (uppercase).
"alg":
This parameter identifies the algorithm used to sign the SVT JWT. Thealgorithm identifierMUST be specified in[RFC7518] or the IANA "JSON Web Signature and Encryption Algorithms"registry[IANA-JOSE-REG]. The specified signature hashalgorithmMUST be identical to the hash algorithm specified inthe hash_algo parameter of the SigValidation object within the sig_val_claimsclaim.

The SVT headerMUST 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 inSection 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 anduse of several claims in the SVT.

At a minimum, each profileMUST define:

A profileMAY also define:

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 documentsMAY define other profiles thatMAY complement, amend, or supersede these profiles.

5.Signature Verification with an SVT

Signature verification based on an SVTMUST follow these steps:

  1. Locate all available SVTs available for the signed document that are relevant for the target electronic signature.
  2. Select the most recent SVT that can be successfully validated and meets the requirement of the relying party.
  3. Verify the integrity of the signature and the Signed Bytes of the target electronic signature using the sig_ref claim.
  4. Verify that the Signed Data reference in the original electronic signature matches the reference values in the sig_data_ref claim.
  5. Verify the integrity of referenced Signed Data using provided hash values in the sig_data_ref claim.
  6. Obtain the verified certificates supporting the asserted electronic signature verification through the signer_cert_ref claim.
  7. Verify that signature validation policy results satisfy the requirements of the relying party.
  8. 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 asthe trusted signer certificate binding the identity of the signer to the electronicsignature.

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 bySection 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 9321

6.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 9321

7.Security Considerations

7.1.Level of Reliance

An SVT allows a signature verifier to still validate the original signature usingthe original signature data and to use the information in the SVT selectively toconfirm the validity and integrity of the original data, such as confirming the integrity of Signed Data or the validity of the signer's certificate, etc.

Another way to use an SVT is to completely rely on the validation conclusion providedby the SVT and to omit revalidation of the original signature value and originalcertificate status checking data.

This choice is a decision made by the verifier according to its own policy and risk assessment.

However, even when relying on the SVT validation conclusion of an SVT, it is vital to still verify thatthe present SVT is correctly associated with the document and signature that is being validated byvalidating the hashed reference data in the SVT of the signature, signing certificate chain,Signed Data, and the Signed Bytes.

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 in cases where an algorithm protecting the SVT is getting close to its end of life.

One way to increase the resistance of algorithms becoming insecure, is to issue multiple SVTs for the same signature with different algorithms and key lengths where one algorithm could still be secure even if the corresponding algorithm used in the alternative SVT is broken.

8.References

8.1.Normative References

[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,.
[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,.
[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,.
[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,.
[RFC2119]
Bradner, S.,"Key words for use in RFCs to Indicate Requirement Levels",BCP 14,RFC 2119,DOI 10.17487/RFC2119,,<https://www.rfc-editor.org/info/rfc2119>.
[RFC3125]
Ross, J.,Pinkas, D., andN. Pope,"Electronic Signature Policies",RFC 3125,DOI 10.17487/RFC3125,,<https://www.rfc-editor.org/info/rfc3125>.
[RFC3161]
Adams, C.,Cain, P.,Pinkas, D., andR. Zuccherato,"Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)",RFC 3161,DOI 10.17487/RFC3161,,<https://www.rfc-editor.org/info/rfc3161>.
[RFC3647]
Chokhani, S.,Ford, W.,Sabett, R.,Merrill, C., andS. Wu,"Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework",RFC 3647,DOI 10.17487/RFC3647,,<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,,<https://www.rfc-editor.org/info/rfc5035>.
[RFC5280]
Cooper, D.,Santesson, S.,Farrell, S.,Boeyen, S.,Housley, R., andW. Polk,"Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile",RFC 5280,DOI 10.17487/RFC5280,,<https://www.rfc-editor.org/info/rfc5280>.
[RFC5652]
Housley, R.,"Cryptographic Message Syntax (CMS)",STD 70,RFC 5652,DOI 10.17487/RFC5652,,<https://www.rfc-editor.org/info/rfc5652>.
[RFC7515]
Jones, M.,Bradley, J., andN. Sakimura,"JSON Web Signature (JWS)",RFC 7515,DOI 10.17487/RFC7515,,<https://www.rfc-editor.org/info/rfc7515>.
[RFC7518]
Jones, M.,"JSON Web Algorithms (JWA)",RFC 7518,DOI 10.17487/RFC7518,,<https://www.rfc-editor.org/info/rfc7518>.
[RFC7519]
Jones, M.,Bradley, J., andN. Sakimura,"JSON Web Token (JWT)",RFC 7519,DOI 10.17487/RFC7519,,<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,,<https://www.rfc-editor.org/info/rfc8174>.
[RFC9231]
Eastlake 3rd, D.,"Additional XML Security Uniform Resource Identifiers (URIs)",RFC 9231,DOI 10.17487/RFC9231,,<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,.
[XMLDSIG11]
Eastlake 3rd, D.,Reagle, J.,Solo, D.,Hirsch, F.,Nystrom, M.,Roessler, T., andK. Yiu,"XML Signature Syntax and Processing Version 1.1",W3C Proposed Recommendation,.Latest version available athttps://www.w3.org/TR/xmldsig-core1/.

8.2.Informative References

[RFC8610]
Birkholz, H.,Vigano, C., andC. 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,,<https://www.rfc-editor.org/info/rfc8610>.

Appendix A.XML Signature Profile

This appendix defines a profile for implementing SVTs with a signed XML document and defines the following aspects of SVT usage:

XML documents can have any number of signature elements, signing an arbitrary number of fragments of XML documents. The actual signature element may be included in the signed XML document (enveloped), include the Signed Data (enveloping), or may be separate from the signed content (detached).

To provide a generic solution for any type of XML signature, an SVT is added to each XML signature element within the XML signature <ds:Object> element.

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 SVTMUST be provided for each XML signature.

An SVT embedded within the XML signature elementMUST be placed in a <svt:SignatureValidationToken> element as defined inAppendix A.2.1.

A.2.1.SignatureValidationToken Signature Property

The <svt:SignatureValidationToken> elementMUST be placed in a <ds:SignatureProperty> element in accordance with[XMLDSIG11]. The <ds:SignatureProperty> elementMUST 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, implementationsSHOULD 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 applicationsSHOULD NOT reject an SVT token because of Id and Target attribute mismatch andMUST 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 tokenMUST be included as a string representation of the SVT JWT. Note that this is the string representation of the JWT without further encoding. The SVTMUST NOT be represented by the Base64-encoded bytes of the JWT string.

Example:

<ds:Signature>  ...  <ds:Object>    <ds:SignatureProperties>      <ds:SignatureProperty>        <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, itSHOULD 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 applicationsMUST be able to handle signatures where the new SVT is located in a new <ds:Object> element.

A.3.XML Signature SVT Claims

A.3.1.XML Profile Identifier

When this profile is used, the SigValidation objectMUST contain a "profile" claim with the value "XML".

A.3.2.XML Signature Reference Data

The SVT Signature objectMUST 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 objectMUST contain one instance of the "sig_data" claim (SignedData object) for each <ds:Reference> element in the <ds:SignedInfo> element. The "sig_data" claimMUST 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 transformationalgorithms. 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 objectMUST contain a "signer_cert_ref" claim (CertReference object). The "type" parameter of the "signer_cert_ref" claimMUST be either "chain" or "chain_hash".

  • The "chain" typeMUST 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" typeMUST 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

The SVT JOSE header for XML signatures 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 SVTMUST 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 algorithmMUST be the same hash algorithm used when signing the SVT as specified by the "alg" Header Parameter.

Appendix B.PDF Signature Profile

This appendix defines a profile for implementing SVTs with a signed PDF document, and it defines the following aspects of SVT usage:

PDF document signatures are added as incremental updates to the signed PDF document and signs all data of the PDF document up until the current signature. When more than one signature is added to a PDF document the previous signature is signed by the next signature and can not be updated with additional data after this event.

To minimize the impact on PDF documents with multiple signatures and to stay backwards compatible with PDF software that does not understand SVTs, PDF documents add one SVT token for all signatures of the PDF as an extension to a document timestamp added to the signed PDF as an incremental update. This SVT covers all signatures of the signed PDF.

B.1.SVTs in PDF Documents

The SVT for a signed PDF documentMAY provide signature validation information about any of the present signatures in the PDF. The SVTMUST 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 documentMUST 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 SVTMUST be added to the timestamp token (TSTInfo) as an Extension object as defined inAppendix 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 SVT JWT, represented as a UTF-8-encoded string.

This extensionMUST 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 objectMUST contain a "profile" claim with the value "PDF".

B.2.2.PDF Signature Reference Data

The SVT Signature objectMUST 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 objectMUST contain one instance of the "sig_data" claim (SignedData object) with the following elements:

"ref":
The string representation of the ByteRange value of the PDF signature dictionary of the target signature. This is a sequence of integers separated by space where each integer pair specifies the start index and length of a byte range.
"hash":
The hash of all bytes identified by the ByteRange value. This is the concatenation of all byte ranges identified by the ByteRange value.

B.2.4.PDF Signer Certificate References

The SVT Signature objectMUST contain a "signer_cert_ref" claim (CertReference object). The "type" parameter of the "signer_cert_ref" claimMUST be either "chain" or "chain_hash".

  • The "chain" typeMUST 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" typeMUST 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 certificateMUST 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 SVTMUST 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 algorithmMUST be the same hash algorithm used when signing the SVT as specified by the "alg" Header Parameter. The referenced certificateSHOULD be the same certificate that was used to sign the document timestamp that contains the SVT.

Appendix C.JWS Profile

This appendix defines a profile for implementing SVTs with a JWS signed payload according to[RFC7515], and it defines the following aspects of SVT usage:

A JWS may have one or more signatures, depending on its serialization format, signing the same payload data. A JWS either contains the data to be signed (enveloping) or may sign any externally associated payload data (detached).

To provide a generic solution for JWS, an SVT is added to each present signature as a JWS Unprotected Header. If a JWS includes multiple signatures, then each signature includes its own SVT.

C.1.SVT in JWS

An SVT tokenMAY be added to any signature of a JWS to support validation of that signature. If more than one signature is present, then each present SVTMUST provide information exclusively related to one associated signature andMUST NOT include information about any other signature in the JWS.

Each SVT is stored in its associated signature's "svt" header as defined inAppendix 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 is stored using its natural string representation without further wrapping or encoding.

The "svt" Header Parameter, when used,MUST be included as a JWS Unprotected Header.

Note: A JWS Unprotected Header is not supported with JWS Compact Serialization. A consequence of adding an SVT token to a JWS is therefore that JWS JSON SerializationMUST 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 SVTMUST 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 objectMUST contain a "profile" claim with the value "JWS".

C.2.2.JWS Signature Reference Data

The SVT Signature objectMUST 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 objectMUST contain one instance of the "sig_data" claim (SignedData object) with the following elements:

"ref":

This parameterMUST hold one of the following three possible values:

  1. The explicit string value "payload" if the signed JWS Payload is embedded in a "payload" member of the JWS.
  2. The explicit string value "detached" if the JWS signs detached payload data without explicit reference.
  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 is outside the scope of this specification.
"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 objectMUST contain a "signer_cert_ref" claim (CertReference object). The "type" parameter of the "signer_cert_ref" claimMUST be either "chain" or "chain_hash".

  • The "chain" typeMUST 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" typeMUST 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 SVTMUST 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 algorithmMUST 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)

The following informative CDDL[RFC8610] expresses the structure of an SVT token:

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} / nullbinary-value = text             ; base64 classic with padding

D.2.JSON Schema

The following informative JSON schema describes the syntax of the SVT token payload.

{    "$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

The following example illustrates a basic SVT according to this specificationissued for a signed PDF document.

Note: Line breaks in the decoded example are inserted for readability. Linebreaks are not allowed in valid JSON data.

Signature validation token JWT:

eyJraWQiOiJPZW5JKzQzNEpoYnZmRG50ZlZcLzhyT3hHN0ZrdnlqYUtWSmFWcUlGQlhvaFZoQWU1Zks4YW5vdjFTNjg4cjdLYmFsK2Z2cGFIMWo4aWJnNTJRQnkxUFE9PSIsInR5cCI6IkpXVCIsImFsZyI6IlJTNTEyIn0.eyJhdWQiOiJodHRwOlwvXC9leGFtcGxlLmNvbVwvYXVkaWVuY2UxIiwiaXNzIjoiaHR0cHM6XC9cL3N3ZWRlbmNvbm5lY3Quc2VcL3ZhbGlkYXRvciIsImlhdCI6MTYwMzQ1ODQyMSwianRpIjoiNGQxMzk2ZjFmZjcyOGY0MGQ1MjQwM2I2MWM1NzQ0ODYiLCJzaWdfdmFsX2NsYWltcyI6eyJzaWciOlt7ImV4dCI6bnVsbCwic2lnX3ZhbCI6W3sibXNnIjoiT0siLCJleHQiOm51bGwsInJlcyI6IlBBU1NFRCIsInBvbCI6Imh0dHA6XC9cL2lkLnN3ZWRlbmNvbm5lY3Quc2VcL3N2dFwvc2lndmFsLXBvbGljeVwvdHMtcGtpeFwvMDEifV0sInNpZ19yZWYiOnsic2lnX2hhc2giOiJ5Y2VQVkxJemRjcEs5N0lZT2hGSWYxbnk3OUhtSUNiU1Z6SWVaTmJpem83ckdJd0hOTjB6WElTeUtHakN2bm9uT2FRR2ZMXC9QM3ZEdEI4OHlLU1dlWGc9PSIsImlkIjoiaWQtNzM5ODljNmZjMDYzNjM2YWI1ZTc1M2YxMGY3NTc0NjciLCJzYl9oYXNoIjoiQm9QVjRXQ0E5c0FJYWhqSzFIYWpmRnhpK0F6QzRKR1R1ZjM5VzNaV2pjekRDVVJ4ZGM5WWV0ZUh0Y3hHVmVnZ3B4SEo3NVwvY1E3SE4xZERkbGl5SXdnPT0ifSwic2lnbmVyX2NlcnRfcmVmIjp7InJlZiI6WyIxK2FhSmV0ZzdyZWxFUmxVRFlFaVU0WklaaFQ0UlV2aUlRWnVLN28xR0ZLYVRQUTZ5K2t4XC9QTnREcnB1cVE2WGZya0g5d1lESzRleTB5NFdyTkVybnc9PSIsImg0UER4YjVaS214MWVUU3F2VnZZRzhnMzNzMDVKendCK05nRUhGVTRnYzl0cUcwa2dIa2Y2VzNvTHprVHd3dXJJaDZZOUFhZlpZcWMyelAycEUycDRRPT0iLCJEZDJDNXNCMElPUWVNVm5FQmtNNVE5Vzk2bUJITnd3YTJ0elhNcytMd3VZY09VdlBrcnlHUjBhUEc4TzluSVAzbGJ3NktqUTFoRG1SazZ6Qzh4MmpkZz09Il0sInR5cGUiOiJjaGFpbl9oYXNoIn0sInNpZ19kYXRhX3JlZiI6W3sicmVmIjoiIiwiaGFzaCI6IkZjR3BPT2Y4aWxjUHQyMUdEZDJjR25MR0R4UlM1ajdzdk00YXBwMkg0MWRERUxtMkN6Y2VUWTAybmRlSmZXamludG1RMzc2SWxYVE9BcjMxeXpZenNnPT0ifSx7InJlZiI6IiN4YWRlcy0xMWExNTVkOTJiZjU1Nzc0NjEzYmI3YjY2MTQ3N2NmZCIsImhhc2giOiJLUmtnYlo2UFwvbmhVNjNJTWswR2lVZlVcL0RUd3ZlWWl0ZVFrd0dlSnFDNUJ6VE5WOGJRYnBlZFRUdVdKUHhxdkowUlk4NGh3bTdlWVwvZzBIckFPZWdLdz09In1dLCJ0aW1lX3ZhbCI6W119XSwiZXh0IjpudWxsLCJ2ZXIiOiIxLjAiLCJwcm9maWxlIjoiWE1MIiwiaGFzaF9hbGdvIjoiaHR0cDpcL1wvd3d3LnczLm9yZ1wvMjAwMVwvMDRcL3htbGVuYyNzaGE1MTIifX0.TdHCoIUSZj2zMINKg7E44-8VE_mJq6TG1OoPwnYSs_hyUbuXmrLJpuk8GR5YrndeOucPUYAwPxHt_f68JIQyFTi0agO9VJjn1R7Pj3Jt6WG9pYVNn5LH-D1maxD11ZxxbcYeHbsstd2Sy2uMa3BdpsstGdPymSmc6GxY5uJoL0-5vwo_3l-4Bb3LCTiuxYPcmztKIbDy2hEgJ3Hx1K4HF0SHgn3InpqBev3hm2SLw3hH5BCMrywBAhHYE6OGE0aOJ6ktA5UP0jIIHfaw9i1wIiJtHTaGuvtyWSLk5cshmun9HkdkkRTA75bzuq0Iyd0qh070rA8Gje-s4Tw4xzttgKx1KSkvy8n5FqvzWdsZvclCG2mYY9rMxh_7607NXcxajAP4yDOoKNs5nm937ULe0vCN8a7WTrFuiaGjry7HhzRM4C5AqxbDOBXPLyoMr4qn4LRJCHxOeLZ6o3ugvDOOWsyjk3eliyBwDu8qJH7UmyicLxDcCr0hUK_kvREqjD2Z

Decoded JWT Header:

{  "kid":"OenI+434JhbvfDntfV\/8rOxG7FkvyjaKVJaVqIFBXohVhAe5fK8anov         1S688r7Kbal+fvpaH1j8ibg52QBy1PQ==",  "typ":"JWT",  "alg":"RS512"}

Decoded JWT 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

Stefan Santesson
IDsec Solutions AB
Forskningsbyn Ideon
SE-223 70Lund
Sweden
Email:sts@aaa-sec.com
Russ Housley
Vigil Security, LLC
516 Dranesville Road
Herndon,VA20170
United States of America
Email:housley@vigilsec.com
[8]ページ先頭
©2009-2026 Movatter.jp