idnits 2.17.1 draft-santesson-svt-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (3 September 2021) is 965 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'String' is mentioned on line 514, but not defined == Missing Reference: 'StringOrURI' is mentioned on line 307, but not defined ** Obsolete normative reference: RFC 6931 (Obsoleted by RFC 9231) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Santesson 3 Internet-Draft IDsec Solutions 4 Intended status: Informational R. Housley 5 Expires: 7 March 2022 Vigil Security 6 3 September 2021 8 Signature Validation Token 9 draft-santesson-svt-02 11 Abstract 13 Electronic signatures have a limited lifespan with respect to the 14 time period that they can be validated and determined to be 15 authentic. The Signature Validation Token (SVT) defined in this 16 specification provides evidence that asserts the validity of an 17 electronic signature. The SVT is provided by a trusted authority, 18 which asserts that a particular signature was successfully validated 19 according to defined procedures at a certain time. Any future 20 validation of that electronic signature can be satisfied by 21 validating the SVT without any need to also validate the original 22 electronic signature or the associated digital certificates. SVT 23 supports electronic signatures in CMS, XML, and PDF documents. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on 7 March 2022. 42 Copyright Notice 44 Copyright (c) 2021 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 49 license-info) in effect on the date of publication of this document. 50 Please review these documents carefully, as they describe your rights 51 and restrictions with respect to this document. Code Components 52 extracted from this document must include Simplified BSD License text 53 as described in Section 4.e of the Trust Legal Provisions and are 54 provided without warranty as described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3. Signature Validation Token . . . . . . . . . . . . . . . . . 4 61 3.1. Signature Validation Token Function . . . . . . . . . . . 5 62 3.2. Signature Validation Token Syntax . . . . . . . . . . . . 6 63 3.2.1. Data Types . . . . . . . . . . . . . . . . . . . . . 6 64 3.2.2. Signature Validation Token JWT Claims . . . . . . . . 7 65 3.2.3. SigValidation Object Class . . . . . . . . . . . . . 8 66 3.2.4. Signature Claims Object Class . . . . . . . . . . . . 9 67 3.2.5. SigReference Claims Object Class . . . . . . . . . . 9 68 3.2.6. SignedData Claims Object Class . . . . . . . . . . . 10 69 3.2.7. PolicyValidation Claims Object Class . . . . . . . . 10 70 3.2.8. TimeValidation Claims Object Class . . . . . . . . . 11 71 3.2.9. CertReference Claims Object Class . . . . . . . . . . 11 72 3.2.10. SVT JOSE Header . . . . . . . . . . . . . . . . . . . 12 73 4. Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . 13 74 5. Signature Verification with a SVT . . . . . . . . . . . . . . 13 75 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 76 6.1. Claim Names Registration . . . . . . . . . . . . . . . . 14 77 6.1.1. Registry Contents . . . . . . . . . . . . . . . . . . 14 78 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 79 7.1. Level of reliance . . . . . . . . . . . . . . . . . . . . 15 80 7.2. Aging algorithms . . . . . . . . . . . . . . . . . . . . 15 81 8. Normative References . . . . . . . . . . . . . . . . . . . . 15 82 Appendix A. Appendix: Examples . . . . . . . . . . . . . . . . . 17 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 85 1. Introduction 87 Electronic signatures have a limited lifespan regarding when they can 88 be validated and determined to be authentic. Many factors make it 89 more difficult to validate electronic signatures over time. For 90 example: 92 * Trusted information about the validity of the certificate 93 containing the signer's public key is not available. 95 * Trusted information about the date and time when the signature was 96 actually created is not available. 98 * Algorithms used to create the electronic signature are no longer 99 considered secure. 101 * Services necessary to validate the signature are no longer 102 available. 104 * Supporting evidence such as CA certificates, OCSP responses, CRLs, 105 or timestamps. 107 The challenges to validation of an electronic signature increases 108 over time, and eventually it is simply impossible to verify the 109 signature with a sufficient level of assurance. 111 Existing standards, such as the ETSI XAdES [XADES] profile for XML 112 signatures [XMLDSIG11], ETSI PAdES [PADES] profile for PDF signatures 113 [ISOPDF2], and ETSI CAdES [CADES] profile for CMS signatures 114 [RFC5652] can be used to prolong the lifetime of a signature by 115 storing data that supports validation of the electronic signature 116 beyond the lifetime of the certificate containing the signer's public 117 key, which is often referred to as the signing certificate. The 118 problem with this approach is that the amount of information that 119 must be stored along with the electronic signature constantly grows 120 over time. The increasing amount of information and signed objects 121 that need to be validated in order to verify the original electronic 122 signature grows in complexity to the point where validation of the 123 electronic signature may become infeasible. 125 The Signature Validation Token (SVT) defined in this specification 126 takes a fundamentally different approach to the problem by providing 127 evidence by a trusted authority that asserts the validity of an 128 electronic signature. The SVT asserts that a particular electronic 129 signature was successfully validated by a trusted authority according 130 to defined procedures at a certain date and time. Once the SVT is 131 issued by a trusted authority, any future validation of that 132 electronic signature is satisfied by validating the SVT, without any 133 need to also validate the original electronic signature. 135 This approach drastically reduces the complexity of validation of 136 older electronic signatures for the simple reason that validating the 137 SVT eliminates the need to validate the many signed objects that 138 would otherwise been needed to provide the same level of assurance. 139 The SVT can be signed with private keys and algorithms that provide 140 confidence for a considerable time period. In fact, multiple SVTs 141 can be used to offer greater assurance. For example, one SVT could 142 be produced with a large RSA private key, a second one with a strong 143 elliptic curve, and a third one with a quantum safe digital signature 144 algorithm to protect against advances in computing power and 145 cryptanalytic capabilities. Further, the trusted authority can add 146 additional SVTs in the future using fresh private keys and signatures 147 to extend the lifetime of the, if necessary. 149 2. Definitions 151 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 152 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 153 "OPTIONAL" in this document are to be interpreted as described in 154 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 155 capitals, as shown here. 157 This document use the following terms: 159 * Signed Data - The data covered by a particular electronic 160 signature. This is typically equivalent to the signed content of 161 a document, and it represents the data that the signer intended to 162 sign. In some cases, such as in some XML signatures, the signed 163 data can be the collection of several data fragments each 164 referenced by the signature. In the case of PDF, this is the data 165 covered by the "ByteRange" parameter in the signature dictionary. 167 * Signed Bytes - These are the actual bytes of data that were hashed 168 and signed by the digital signature algorithm. In most cases, 169 this is not the actual Signed Data, but a collection of signature 170 metadata that includes references (hash) of the Signed Data as 171 well as information about algorithms and other data bound to a 172 signature. In XML, this is the canonicalized SignedInfo element. 173 In CMS and PDF signatures, this is the DER-encoded 174 SignedAttributes structure. 176 When these terms are used as defined in this section, they appear 177 with a capitalized first letter. 179 3. Signature Validation Token 181 The Signature Validation Token (SVT) is created by a trusted service 182 to capture evidence of successful electronic signature verification, 183 and then relying parties can depend on the checking that has already 184 taken place by the trusted service. 186 3.1. Signature Validation Token Function 188 The function of the SVT is to capture evidence of electronic 189 signature validity at one instance of secure signature validation 190 process and to use that evidence to eliminate the need to perform any 191 repeated cryptographic validation of the original electronic 192 signature value, as well as reliance on any hash values bound to that 193 signature. The SVT achieves this by binding the following 194 information to a specific electronic signature: 196 * A unique identification of the electronic signature. 198 * The data and metadata signed by the electronic signature. 200 * The signer's certificate that was validated as part of electronic 201 signature verification. 203 * The certification path that was used to validate the signer's 204 certificate. 206 * An assertion providing evidence of that the signature was 207 verified, the date and time the verification was performed, the 208 procedures used to verify the electronic signature, and the 209 outcome of the verification. 211 * An assertion providing evidence of the date and time at which the 212 signature is known to have existed, the procedures used to 213 validate the date and time of existence, and the outcome of the 214 validation. 216 Using an SVT is equivalent to validating a signed document in a 217 system once, and then using that document multiple times without 218 subsequent revalidating the electronic signature for each usage. 219 Such procedures are common in systems where the document is residing 220 in a safe and trusted environment where it is protected against 221 modification. The SVT allows the safe and trusted environment to 222 expand beyond a locally controlled environment, and the SVT allows a 223 greater period between original electronic signature verification and 224 subsequent usage. 226 Using the SVT, the electronic signature verification of a document 227 can be take place once using a reliable trusted service, and then any 228 relying party that is able to depend on the verification process 229 already performed by the trusted service. The SVT is therefore not 230 only a valuable tool to extend the lifetime of a signed document, but 231 also avoids the need for careful integration between electronic 232 signature verification and document usage. 234 3.2. Signature Validation Token Syntax 236 The SVT is carried in a JSON Web Token (JWT) as defined in [RFC7519]. 238 3.2.1. Data Types 240 The contents of claims in an SVT are specified using the following 241 data types: 243 * String - JSON Data Type of string that contains an arbitrary case 244 sensitive string value. 246 * Base64Binary - JSON Data Type of string that contains of Base64 247 encoded byte array of binary data. 249 * StringOrURI - JSON Data Type of string that contains an arbitrary 250 string or an URI as defined in [RFC7519], which REQUIRES a value 251 containing the colon character (":") to be a URI. 253 * URI - JSON Data Type of string that contains an URI as defined in 254 [RFC7519]. 256 * Integer - JSON Data Type of number that contains a 32-bit signed 257 integer value (from -2^31 to 2^31-1). 259 * Long - JSON Data Type of number that contains a 64-bit signed 260 integer value (from -2^63 to 2^63-1). 262 * NumericDate - JSON Data Type of number that contains a data as 263 defined in [RFC7519], which is the number of seconds from 264 1970-01-01T00:00:00Z UTC until the specified UTC date/time, 265 ignoring leap seconds. 267 * Boolean - JSON Data Type of boolean that contains explicit value 268 of true or false. 270 * Object - A JSON object holding a claims object of a class 271 defined in this specification (see Section 3.2.2). 273 * Map - A JSON object with name-value pairs where the value is 274 an object of the specified Type in the notation. For example, 275 Map is a JSON object with name value pairs where all 276 values are of type String. 278 * Array - A JSON array of a specific data type as defined in this 279 section. An array is expressed in this specification by square 280 brackets. For example, [String] indicates an array of String 281 values, and [Object] indicates an array of DocHash 282 objects. 284 * Null - A JSON null that represents an absent value. A claim with 285 a null value is equivalent with an absent claim. 287 3.2.2. Signature Validation Token JWT Claims 289 The SVT MUST contain only JWT claims in the following list: 291 * jti - A String data type that is a "JWT ID" registered claim 292 according to [RFC7519]. It is RECOMMENDED that the identifier 293 holds a hexadecimal string representation of a 128-bit unsigned 294 integer. A SVT MUST contain one "JWT ID" claim. 296 * iss - A StringOrURI data type that is an "Issuer" registered claim 297 according to [RFC7519], which is an arbitrary unique identifier of 298 the SVT issuer. This value SHOULD have the value of an URI based 299 on a domain owned by the issuer. A SVT MUST contain one "Issuer" 300 claim. 302 * iat - A NumericDate data type that is an "Issued At" registered 303 claim according to [RFC7519], which expresses the date and time 304 when this SVT was issued. A SVT MUST contain one "Issued At" 305 claim. 307 * aud - A [StringOrURI] data type or a StringOrURI data type that is 308 an "Audience" registered claim according to [RFC7519]. The 309 audience claim is an array of one or more identifiers, identifying 310 intended recipients of the SVT. Each identifier MAY identify a 311 single entity, a group of entities or a common policy adopted by a 312 group of entities. If only one value is provided it MAY be 313 provided as a single StringOrURI data type value instead of as an 314 array of values. Inclusion of the "Audience" claim in a SVT is 315 OPTIONAL. 317 * exp - A NumericDate data type that is an "Expiration Time" 318 registered claim according to [RFC7519], which expresses the date 319 and time when services and responsibilities related to this SVT is 320 no longer provided by the SVT issuer. The precise meaning of the 321 expiration time claim is defined by local policies. See 322 implementation note below. Inclusion of the "Expiration Time" 323 claim in a SVT is OPTIONAL. 325 * sig_val_claims - A Object data type that contains 326 signature validation claims for this SVT extending the standard 327 registered JTW claims above. A SVT MUST contain one 328 sig_val_claims claim. 330 Note: An SVT asserts that a particular validation process was 331 undertaken at a stated date and time. This fact never changes and 332 never expires. However, some other aspects of the SVT such as 333 liability for false claims or service provision related to a specific 334 SVT may expire after a certain period of time, such as a service 335 where an old SVT can be upgraded to a new SVT signed with fresh keys 336 and algorithms. 338 3.2.3. SigValidation Object Class 340 The sig_val_claims JWT claim uses the SigValidation object class. A 341 SigValidation object holds all custom claims, and a SigValidation 342 object contains the following parameters: 344 * ver - A String data type representing the version. This parameter 345 MUST be present, and the version in this specification indicated 346 by the value "1.0". 348 * profile - A StringOrURI data type representing the name of a 349 profile that defines conventions followed for specific claims and 350 any extension points used by the SVT issuer. Inclusion of this 351 parameter is OPTIONAL. 353 * hash_algo - A URI data type that identifies the hash algorithm 354 used to compute the hash values within the SVT. The URI 355 identifier MUST be one defined in [RFC6931] or in the IANA 356 registry defined by this specification. This parameter MUST be 357 present. 359 * sig - A [Object] data type that gives information about 360 validated electronic signatures as an array of Signature objects. 361 If the SVT contains signature validation evidence for more than 362 one signature, then each signature is represented by a separate 363 Signature object. At least one Signature object MUST be present. 365 * ext - A Map data type that provides additional claims 366 related to the SVT. Extension claims are added at the discretion 367 of the SVT issuer; however, extension claims MUST follow any 368 conventions defined in a profile of this specification (see 369 Section 4). Inclusion of this parameter is OPTIONAL. 371 3.2.4. Signature Claims Object Class 373 The sig parameter in the SigValidation object class uses the 374 Signature object class. The Signature object contains claims related 375 to signature validation evidence for one signature, and it contains 376 the following parameters: 378 * sig_ref - A Object data type that contains reference 379 information identifying the target signature. This parameter MUST 380 be present. 382 * sig_data - A [Object] data type that contains an array 383 of references to Signed Data that was signed by the target 384 electronic signature. This parameter MUST be present. 386 * signer_cert_ref - A Object data type that 387 references the signer's certificate and optionally reference to a 388 supporting certification path that was used to verify the target 389 electronic signature. This parameter MUST be present. 391 * sig_val - A [Object] data type that contains an 392 array of results of signature verification according to defined 393 procedures. This parameter MUST be present. 395 * time_val - A [Object] data type that contains an 396 array of time verification results that the target signature has 397 existed at a specific date and time in the past. Inclusion of 398 this parameter is OPTIONAL. 400 * ext - A MAP data type that provides additional claims 401 related to the target signature. Extension claims are added at 402 the discretion of the SVT Issuer; however, extension claims MUST 403 follow any conventions defined in a profile of this specification 404 (see Section 4). Inclusion of this parameter is OPTIONAL. 406 3.2.5. SigReference Claims Object Class 408 The sig_ref parameter in the Signature object class uses the 409 SigReference object class. The SigReference object provides 410 information used to match the Signature claims object to a specific 411 target electronic signature and to verify the integrity of the target 412 signature value and Signed Bytes, and it contains the following 413 parameters: 415 * id - A String data type that contains an identifier assigned to 416 the target signature. Inclusion of this parameter is OPTIONAL. 418 * sig_hash - A Base64Binary data type that contains a hash value of 419 the target electronic signature value. This parameter MUST be 420 present. 422 * sb_hash - A Base64Binary data type that contains a hash value of 423 the Signed Bytes of the target electronic signature. This 424 parameter MUST be present. 426 3.2.6. SignedData Claims Object Class 428 The sig_data parameter in the Signature object class uses the 429 SignedData object class. The SignedData object provides information 430 used to verify the target electronic signature references to Signed 431 Data as well as to verify the integrity of all data that is signed by 432 the target signature, and it contains the following parameters: 434 * ref - A String data type that contains a reference identifier for 435 the data or data fragment covered by the target electronic 436 signature. This parameter MUST be present. 438 * hash - A Base64Binary data type that contains the hash value for 439 the data covered by the target electronic signature. This 440 parameter MUST be present. 442 3.2.7. PolicyValidation Claims Object Class 444 The sig_val parameter in the Signature object class uses the 445 PolicyValidation object class. The PolicyValidation object provides 446 information about the result of a validation process according to a 447 spefific policy, and it contains the following parameters: 449 * pol - A StringOrURI data type that contains the identifier of the 450 policy governing the electronic signature verification process. 451 This parameter MUST be present. 453 * res - A String data type that contains the result of the 454 electronic signature verification process. The value MUST be one 455 of "PASSED", "FAILED" or "INDETERMINATE" as defined by 456 [ETSI319102-1]. This parameter MUST be present. 458 * msg - A String data type that contains a message describing the 459 result. Inclusion of this parameter is OPTIONAL. 461 * ext - A MAP data type that provides additional claims 462 related to the target signature. Extension claims are added at 463 the discretion of the SVT Issuer; however, extension claims MUST 464 follow any conventions defined in a profile of this specification 465 (see Section 4). Inclusion of this parameter is OPTIONAL. 467 3.2.8. TimeValidation Claims Object Class 469 The time_val parameter in the Signature object class uses the 470 TimeValidation object class. The TimeValidation claims object 471 provides information about the result of validating time evidence 472 asserting that the target signature existed at a particular date and 473 time in the past, and it contains the following parameters: 475 * time - A NumericDate data type that contains the verified time. 476 This parameter MUST be present. 478 * type - A StringOrURI data type that contains an identifier of the 479 type of evidence of time. This parameter MUST be present. 481 * iss - A StringOrURI data type that contains an identifier of the 482 entity that issued the evidence of time. This parameter MUST be 483 present. 485 * id - A String data type that contains an unique identifier 486 assigned to the evidence of time. Inclusion of this parameter is 487 OPTIONAL. 489 * val - A [Object] data type that contains an 490 array of results of the time evidence validation according to 491 defined validation procedures. Inclusion of this parameter is 492 OPTIONAL. 494 * ext - A MAP data type that provides additional claims 495 related to the target signature. Extension claims are added at 496 the discretion of the SVT Issuer; however, extension claims MUST 497 follow any conventions defined in a profile of this specification 498 (see Section 4). Inclusion of this parameter is OPTIONAL. 500 3.2.9. CertReference Claims Object Class 502 The signer_cert_ref parameter in the Signature object class uses the 503 CertReference object class. The CertReference object references a 504 single X.509 certificate or a X.509 certification path, either by 505 providing the certificate data or by providing hash references for 506 certificates that can be located in the target electronic signature, 507 and it contains the following parameters: 509 * type - A StringOrURI data type that contains an identifier of the 510 type of reference. The type identifier MUST be one of the 511 identifiers defined below, an identifier specified by the selected 512 profile, or a URI identifier. This parameter MUST be present. 514 * ref - A [String] data type that contains an array of string 515 parameters according to conventions defined by the type 516 identifier. This parameter MUST be present. 518 The following type identifiers are defined: 520 * chain - The ref contains an array of Base64 encoded X.509 521 certificates [RFC5280]. The certificates MUST be provided in the 522 order starting with the end entity certificate. Any following 523 certificate must be able to validate the signature on the previous 524 certificate in the array. 526 * chain_hash - The ref contains an array of one or more Base64 527 encoded hash values where each hash value is a hash over a X.509 528 certificate [RFC5280] used to validate the signature. The 529 certificates MUST be provided in the order starting with the end 530 entity certificate. Any following certificate must be able to 531 validate the signature on the previous certificate in the array. 532 This option MUST NOT be used unless all hashed certificates are 533 present in the target electronic signature. 535 Note: All certificates referenced using the identifiers above are 536 X.509 certificates. Profiles of this specification MAY define 537 alternative types of public key containers; however, a major function 538 of these referenced certificates is not just to reference the public 539 key, but also to provide the subject name of the signer. It is 540 therefore important for the full function of an SVT that the 541 referenced public key container also provides the means to identify 542 of the signer. 544 3.2.10. SVT JOSE Header 546 The SVT JWT MUST contain the following JOSE header parameters in 547 accordance with Section 5 of [RFC7519]: 549 * typ - This parameter MUST have the string value "JWT" (upper 550 case). 552 * alg - This parameter identifies the algorithm used to sign the SVT 553 JWT. The algorithm identifier MUST be specified in [RFC7518] or 554 the IANA JSON Web Signature and Encryption Algorithms Registry [ 555 add a ref ]. The specified signature hash algorithm MUST be 556 identical to the hash algorithm specified in the hash_algo 557 parameter of the SigValidation object within the sig_val_claims 558 claim. 560 The SVT header MUST contain a public key or a reference to a public 561 key used to verify the signature on the SVT in accordance with 562 [RFC7515]. Each profile, as discussed in Section 4, MUST define the 563 requirements for how the key or key reference is included in the 564 header. 566 4. Profiles 568 Each signed document and signature type will have to define the 569 precise content and use of several claims in the SVT. 571 Each profile MUST as a minimum define: 573 * How to reference the Signed Data content of the signed document. 575 * How to reference to the target electronic signature and the Signed 576 Bytes of the signature. 578 * How to reference certificates supporting each electronic 579 siganture. 581 * How to include public keys or references to public keys in the 582 SVT. 584 * Whether each electronic signature is supported by a single SVT, or 585 whether one SVT may support multiple electronic signatures of the 586 same document. 588 A profile MAY also define: 590 * Explicit information on how to perform signature validation based 591 on an SVT. 593 * How to attach an SVT to an electronic signature or signed 594 document. 596 5. Signature Verification with a SVT 598 Signature verification based on an a SVT MUST follow these steps: 600 1. Locate all available SVTs available for the signed document that 601 are relevant for the target electronic signature. 603 2. Select the most recent SVT that can be successfully validated and 604 meets the requirement of the relying party. 606 3. Verify the integrity of the signature and the Signed Bytes of the 607 target electronic signature using the sig_ref claim. 609 4. Verify that the Signed Data reference in the original electronic 610 signature matches the reference values in the sig_data_ref claim. 612 5. Verify the integrity of referenced Signed Data using provided 613 hash values in the sig_data_ref claim. 615 6. Obtain the verified certificates supporting the asserted 616 electronic signature verification through the signer_cert_ref 617 claim. 619 7. Verify that signature validation policy results satisfy the 620 requirements of the relying party. 622 8. Verify that verified time results satisfy the context for the use 623 of the signed document. 625 After successfully performing these steps, signature validity is 626 established as well as the trusted signer certificate binding the 627 identity of the signer to the electronic signature. 629 6. IANA Considerations 631 6.1. Claim Names Registration 633 This section registers the "sig_val_claims" claim name in the IANA 634 "JSON Web Token Claims" registry established by Section 10.1 in 635 [RFC7519]. 637 6.1.1. Registry Contents 639 * Claim Name: "sig_val_claims" 641 * Claim Description: Signature Validation Token 643 * Change Controller: IESG 645 * Specification Document(s): Section 3.2.3 of {this document} 647 NOTE to RFC editor: Please replace {this document} with its assigned 648 RFC number. 650 7. Security Considerations 651 7.1. Level of reliance 653 An SVT allows a signature verifier to still validate the original 654 signature using the original signature data and to use the 655 information in the SVT selectively to either just confirm the 656 validity and integrity of the original data, such as confirming the 657 integrity of signed data or the validity of the signer's certificate 658 etc. 660 Another way to use an SVT is to completely rely on the validation 661 conclusion provided by the SVT and to omit re-validation of the 662 original signature value and original certificate status checking 663 data. 665 This choice is a decision made by the verifier according to its own 666 policy and risk assessment. 668 However, even when relying on the SVT validation conclusion of an SVT 669 it is vital to still verify that the present SVT is correctly 670 associated with the document and signature that is being validated by 671 validating the hashed reference data in the SVT of the signature, 672 signing certificate chain, signed data and the signed bytes. 674 7.2. Aging algorithms 676 Even if the SVT provides protection against algorithms becoming 677 weakened or broken over time, this protection is only valid for as 678 long as the algorithms used to sign the SVT are still considered 679 secure. It is advisable to re-issue SVT in cases where an algorithm 680 protecting the SVT is getting close to its end of life. 682 One way to increase the resistance of algorithms becoming insecure, 683 is to issue multiple SVT for the same signature with different 684 algorithms and key lengths where one algorithm could still be secure 685 even if the corresponding algorithm used in the alternative SVT is 686 broken. 688 8. Normative References 690 [CADES] ETSI, "Electronic Signatures and Infrastructures (ESI); 691 CAdES digital signatures; Part 1: Building blocks and 692 CAdES baseline signatures", ETSI EN 319 122-1 v1.1.1, 693 April 2016. 695 [ETSI319102-1] 696 ETSI, "ETSI - Electronic Signatures and Infrastructures 697 (ESI); Procedures for Creation and Validation of AdES 698 Digital Signatures; Part 1: Creation and Validation", 699 ETSI EN 319 102-1 v1.1.1, May 2016. 701 [ISOPDF2] ISO, "Document management -- Portable document format -- 702 Part 2: PDF 2.0", ISO 32000-2, July 2017. 704 [PADES] ETSI, "Electronic Signatures and Infrastructures (ESI); 705 PAdES digital signatures; Part 1: Building blocks and 706 PAdES baseline signatures", ETSI EN 319 142-1 v1.1.1, 707 April 2016. 709 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 710 Requirement Levels", BCP 14, RFC 2119, 711 DOI 10.17487/RFC2119, March 1997, 712 . 714 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 715 Housley, R., and W. Polk, "Internet X.509 Public Key 716 Infrastructure Certificate and Certificate Revocation List 717 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 718 . 720 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 721 RFC 5652, DOI 10.17487/RFC5652, September 2009, 722 . 724 [RFC6931] Eastlake 3rd, D., "Additional XML Security Uniform 725 Resource Identifiers (URIs)", RFC 6931, 726 DOI 10.17487/RFC6931, April 2013, 727 . 729 [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 730 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 731 2015, . 733 [RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, 734 DOI 10.17487/RFC7518, May 2015, 735 . 737 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 738 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 739 . 741 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 742 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 743 May 2017, . 745 [XADES] ETSI, "Electronic Signatures and Infrastructures (ESI); 746 XAdES digital signatures; Part 1: Building blocks and 747 XAdES baseline signatures", ETSI EN 319 132-1 v1.1.1, 748 April 2016. 750 [XMLDSIG11] 751 Eastlake, D., Reagle, J., Solo, D., Hirsch, F., Nystrom, 752 M., Roessler, T., and K. Yiu, "XML Signature Syntax and 753 Processing Version 1.1", W3C Proposed Recommendation, 11 754 April 2013. 756 Appendix A. Appendix: Examples 758 The following example illustrates a basic SVT according to this 759 specification issued for a signed PDF document. 761 Note: Line breaks in the decoded example are inserted for 762 readablilty. Line breaks are not allowed in valid JSON data. 764 Signature validation token JWT: 766 eyJraWQiOiJPZW5JKzQzNEpoYnZmRG50ZlZcLzhyT3hHN0ZrdnlqYUtWSmFWcUlG 767 QlhvaFZoQWU1Zks4YW5vdjFTNjg4cjdLYmFsK2Z2cGFIMWo4aWJnNTJRQnkxUFE9 768 PSIsInR5cCI6IkpXVCIsImFsZyI6IlJTNTEyIn0.eyJhdWQiOiJodHRwOlwvXC9l 769 eGFtcGxlLmNvbVwvYXVkaWVuY2UxIiwiaXNzIjoiaHR0cHM6XC9cL3N3ZWRlbmNv 770 bm5lY3Quc2VcL3ZhbGlkYXRvciIsImlhdCI6MTYwMzQ1ODQyMSwianRpIjoiNGQx 771 Mzk2ZjFmZjcyOGY0MGQ1MjQwM2I2MWM1NzQ0ODYiLCJzaWdfdmFsX2NsYWltcyI6 772 eyJzaWciOlt7ImV4dCI6bnVsbCwic2lnX3ZhbCI6W3sibXNnIjoiT0siLCJleHQi 773 Om51bGwsInJlcyI6IlBBU1NFRCIsInBvbCI6Imh0dHA6XC9cL2lkLnN3ZWRlbmNv 774 bm5lY3Quc2VcL3N2dFwvc2lndmFsLXBvbGljeVwvdHMtcGtpeFwvMDEifV0sInNp 775 Z19yZWYiOnsic2lnX2hhc2giOiJ5Y2VQVkxJemRjcEs5N0lZT2hGSWYxbnk3OUht 776 SUNiU1Z6SWVaTmJpem83ckdJd0hOTjB6WElTeUtHakN2bm9uT2FRR2ZMXC9QM3ZE 777 dEI4OHlLU1dlWGc9PSIsImlkIjoiaWQtNzM5ODljNmZjMDYzNjM2YWI1ZTc1M2Yx 778 MGY3NTc0NjciLCJzYl9oYXNoIjoiQm9QVjRXQ0E5c0FJYWhqSzFIYWpmRnhpK0F6 779 QzRKR1R1ZjM5VzNaV2pjekRDVVJ4ZGM5WWV0ZUh0Y3hHVmVnZ3B4SEo3NVwvY1E3 780 SE4xZERkbGl5SXdnPT0ifSwic2lnbmVyX2NlcnRfcmVmIjp7InJlZiI6WyIxK2Fh 781 SmV0ZzdyZWxFUmxVRFlFaVU0WklaaFQ0UlV2aUlRWnVLN28xR0ZLYVRQUTZ5K2t4 782 XC9QTnREcnB1cVE2WGZya0g5d1lESzRleTB5NFdyTkVybnc9PSIsImg0UER4YjVa 783 S214MWVUU3F2VnZZRzhnMzNzMDVKendCK05nRUhGVTRnYzl0cUcwa2dIa2Y2VzNv 784 THprVHd3dXJJaDZZOUFhZlpZcWMyelAycEUycDRRPT0iLCJEZDJDNXNCMElPUWVN 785 Vm5FQmtNNVE5Vzk2bUJITnd3YTJ0elhNcytMd3VZY09VdlBrcnlHUjBhUEc4Tzlu 786 SVAzbGJ3NktqUTFoRG1SazZ6Qzh4MmpkZz09Il0sInR5cGUiOiJjaGFpbl9oYXNo 787 In0sInNpZ19kYXRhX3JlZiI6W3sicmVmIjoiIiwiaGFzaCI6IkZjR3BPT2Y4aWxj 788 UHQyMUdEZDJjR25MR0R4UlM1ajdzdk00YXBwMkg0MWRERUxtMkN6Y2VUWTAybmRl 789 SmZXamludG1RMzc2SWxYVE9BcjMxeXpZenNnPT0ifSx7InJlZiI6IiN4YWRlcy0x 790 MWExNTVkOTJiZjU1Nzc0NjEzYmI3YjY2MTQ3N2NmZCIsImhhc2giOiJLUmtnYlo2 791 UFwvbmhVNjNJTWswR2lVZlVcL0RUd3ZlWWl0ZVFrd0dlSnFDNUJ6VE5WOGJRYnBl 792 ZFRUdVdKUHhxdkowUlk4NGh3bTdlWVwvZzBIckFPZWdLdz09In1dLCJ0aW1lX3Zh 793 bCI6W119XSwiZXh0IjpudWxsLCJ2ZXIiOiIxLjAiLCJwcm9maWxlIjoiWE1MIiwi 794 aGFzaF9hbGdvIjoiaHR0cDpcL1wvd3d3LnczLm9yZ1wvMjAwMVwvMDRcL3htbGVu 795 YyNzaGE1MTIifX0.TdHCoIUSZj2zMINKg7E44-8VE_mJq6TG1OoPwnYSs_hyUbuX 796 mrLJpuk8GR5YrndeOucPUYAwPxHt_f68JIQyFTi0agO9VJjn1R7Pj3Jt6WG9pYVN 797 n5LH-D1maxD11ZxxbcYeHbsstd2Sy2uMa3BdpsstGdPymSmc6GxY5uJoL0-5vwo_ 798 3l-4Bb3LCTiuxYPcmztKIbDy2hEgJ3Hx1K4HF0SHgn3InpqBev3hm2SLw3hH5BCM 799 rywBAhHYE6OGE0aOJ6ktA5UP0jIIHfaw9i1wIiJtHTaGuvtyWSLk5cshmun9Hkdk 800 kRTA75bzuq0Iyd0qh070rA8Gje-s4Tw4xzttgKx1KSkvy8n5FqvzWdsZvclCG2mY 801 Y9rMxh_7607NXcxajAP4yDOoKNs5nm937ULe0vCN8a7WTrFuiaGjry7HhzRM4C5A 802 qxbDOBXPLyoMr4qn4LRJCHxOeLZ6o3ugvDOOWsyjk3eliyBwDu8qJH7UmyicLxDc 803 Cr0hUK_kvREqjD2Z 805 Decoded JWT Header: 807 { 808 "kid":"OenI+434JhbvfDntfV\/8rOxG7FkvyjaKVJaVqIFBXohVhAe5fK8anov 809 1S688r7Kbal+fvpaH1j8ibg52QBy1PQ==", 810 "typ":"JWT", 811 "alg":"RS512" 812 } 813 Decoded JWT Claims: 815 { 816 "aud" : "http://example.com/audience1", 817 "iss" : "https://swedenconnect.se/validator", 818 "iat" : 1603458421, 819 "jti" : "4d1396f1ff728f40d52403b61c574486", 820 "sig_val_claims" : { 821 "sig" : [ { 822 "ext" : null, 823 "sig_val" : [ { 824 "msg" : "OK", 825 "ext" : null, 826 "res" : "PASSED", 827 "pol" : "http://id.swedenconnect.se/svt/sigval-policy/ 828 ts-pkix/01" 829 } ], 830 "sig_ref" : { 831 "sig_hash" : "ycePVLIzdcpK97IYOhFIf1ny79HmICbSVzIeZNbizo7rGIw 832 HNN0zXISyKGjCvnonOaQGfL/P3vDtB88yKSWeXg==", 833 "id" : "id-73989c6fc063636ab5e753f10f757467", 834 "sb_hash" : "BoPV4WCA9sAIahjK1HajfFxi+AzC4JGTuf39W3ZWjczDCURx 835 dc9YeteHtcxGVeggpxHJ75/cQ7HN1dDdliyIwg==" 836 }, 837 "signer_cert_ref" : { 838 "ref" : [ "1+aaJetg7relERlUDYEiU4ZIZhT4RUviIQZuK7o1GFKaTPQ6y+ 839 kx/PNtDrpuqQ6XfrkH9wYDK4ey0y4WrNErnw==", 840 "h4PDxb5ZKmx1eTSqvVvYG8g33s05JzwB+NgEHFU4gc9tqG0kgH 841 kf6W3oLzkTwwurIh6Y9AafZYqc2zP2pE2p4Q==", 842 "Dd2C5sB0IOQeMVnEBkM5Q9W96mBHNwwa2tzXMs+LwuYcOUvPkr 843 yGR0aPG8O9nIP3lbw6KjQ1hDmRk6zC8x2jdg==" ], 844 "type" : "chain_hash" 845 }, 846 "sig_data_ref" : [ { 847 "ref" : "", 848 "hash" : "FcGpOOf8ilcPt21GDd2cGnLGDxRS5j7svM4app2H41dDELm2Czc 849 eTY02ndeJfWjintmQ376IlXTOAr31yzYzsg==" 850 }, { 851 "ref" : "#xades-11a155d92bf55774613bb7b661477cfd", 852 "hash" : "KRkgbZ6P/nhU63IMk0GiUfU/DTwveYiteQkwGeJqC5BzTNV8bQb 853 pedTTuWJPxqvJ0RY84hwm7eY/g0HrAOegKw==" 854 } ], 855 "time_val" : [ ] 856 } ], 857 "ext" : null, 858 "ver" : "1.0", 859 "profile" : "XML", 860 "hash_algo" : "http://www.w3.org/2001/04/xmlenc#sha512" 862 } 863 } 865 Authors' Addresses 867 Stefan Santesson 868 IDsec Solutions AB 869 Forskningsbyn Ideon 870 SE-223 70 Lund 871 Sweden 873 Email: sts@aaa-sec.com 875 Russ Housley 876 Vigil Security, LLC 877 516 Dranesville Road 878 Herndon, VA, 20170 879 United States of America 881 Email: housley@vigilsec.com