[要約] RFC 9321 - Signature Validation Tokenは、電子署名の有効性を証明するためのトークンであり、信頼できる機関によって提供されます。SVTは、将来の電子署名の検証において、元の電子署名や関連するデジタル証明書を検証する必要なく、SVTのみを検証することで満たすことができます。
Independent Submission S. Santesson
Request for Comments: 9321 IDsec Solutions
Category: Informational R. Housley
ISSN: 2070-1721 Vigil Security
October 2022
Signature Validation Token
署名検証トークン
Abstract
概要
Electronic signatures have a limited lifespan with respect to the time period that they can be validated and determined to be authentic. The Signature Validation Token (SVT) defined in this specification provides evidence that asserts the validity of an electronic signature. The SVT is provided by a trusted authority, which asserts that a particular signature was successfully validated according to defined procedures at a certain time. Any future validation of that electronic signature can be satisfied by validating the SVT without any need to also validate the original electronic signature or the associated digital certificates. The SVT supports electronic signatures in Cryptographic Message Syntax (CMS), XML, PDF, and JSON documents.
電子署名は、それらを検証し、本物であると判断できる期間に関して寿命が限られています。この仕様で定義されている署名検証トークン（SVT）は、電子署名の有効性を主張する証拠を提供します。SVTは信頼できる当局によって提供されます。これは、特定の署名が特定の時間に定義された手順に従って正常に検証されたと主張しています。その電子署名の将来の検証は、元の電子署名または関連するデジタル証明書を検証する必要なく、SVTを検証することにより、満たすことができます。SVTは、暗号化メッセージ構文（CMS）、XML、PDF、およびJSONドキュメントの電子署名をサポートしています。
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.
これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。RFCエディターは、このドキュメントの裁量でこのドキュメントを公開することを選択しており、実装または展開に対する価値について声明を発表しません。RFCエディターによって公開が承認されたドキュメントは、インターネット標準のレベルの候補者ではありません。RFC 7841のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9321.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9321で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2022 IETF Trustおよび文書著者として特定された人。全著作権所有。
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.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
Table of Contents
目次
1. Introduction
2. Definitions
3. Signature Validation Token
3.1. Signature Validation Token Function
3.2. Signature Validation Token Syntax
3.2.1. Data Types
3.2.2. Signature Validation Token JWT Claims
3.2.3. SigValidation Object Class
3.2.4. Signature Claims Object Class
3.2.5. SigReference Claims Object Class
3.2.6. SignedDataReference Claims Object Class
3.2.7. PolicyValidation Claims Object Class
3.2.8. TimeValidation Claims Object Class
3.2.9. CertReference Claims Object Class
3.2.10. SVT JOSE Header
4. Profiles
4.1. Defined Profiles
5. Signature Verification with an SVT
6. IANA Considerations
6.1. Claim Names Registration
6.1.1. Registry Contents
6.2. Header Parameter Names Registration
6.2.1. Registry Contents
7. Security Considerations
7.1. Level of Reliance
7.2. Aging Algorithms
8. References
8.1. Normative References
8.2. Informative References
Appendix A. XML Signature Profile
A.1. Notation
A.1.1. References to XML Elements from XML Schemas
A.2. SVT in XML Documents
A.2.1. SignatureValidationToken Signature Property
A.2.2. Multiple SVTs in an XML Signature
A.3. XML Signature SVT Claims
A.3.1. XML Profile Identifier
A.3.2. XML Signature Reference Data
A.3.3. XML Signed Data Reference Data
A.3.4. XML Signer Certificate References
A.4. JOSE Header
A.4.1. SVT Signing Key Reference
Appendix B. PDF Signature Profile
B.1. SVTs in PDF Documents
B.1.1. SVT Extension to Timestamp Tokens
B.2. PDF Signature SVT Claims
B.2.1. PDF Profile Identifier
B.2.2. PDF Signature Reference Data
B.2.3. PDF Signed Data Reference Data
B.2.4. PDF Signer Certificate References
B.3. JOSE Header
B.3.1. SVT Signing Key Reference
Appendix C. JWS Profile
C.1. SVT in JWS
C.1.1. "svt" Header Parameter
C.1.2. Multiple SVTs in a JWS Signature
C.2. JWS Signature SVT Claims
C.2.1. JWS Profile Identifier
C.2.2. JWS Signature Reference Data
C.2.3. JWS Signed Data Reference Data
C.2.4. JWS Signer Certificate References
C.3. SVT JOSE Header
C.3.1. SVT Signing Key Reference
Appendix D. Schemas
D.1. Concise Data Definition Language (CDDL)
D.2. JSON Schema
Appendix E. Examples
Authors' Addresses
Electronic signatures have a limited lifespan regarding when they can be validated and determined to be authentic. Many factors make it more difficult to validate electronic signatures over time. For example:
電子署名は、それらをいつ検証し、本物であると判断できるかに関して限られた寿命を持っています。多くの要因により、時間の経過とともに電子署名を検証することがより困難です。例えば：
* Trusted information about the validity of the certificate containing the signer's public key is not available.
* 署名者の公開鍵を含む証明書の有効性に関する信頼できる情報は利用できません。
* Trusted information about the time when the signature was actually created is not available.
* 署名が実際に作成された時期に関する信頼できる情報は利用できません。
* Algorithms used to create the electronic signature may no longer be considered secure at the time of validation and may therefore no longer be available in software libraries.
* 電子署名を作成するために使用されるアルゴリズムは、検証時にはもはや安全ではないと見なされる可能性があるため、ソフトウェアライブラリで利用できなくなる場合があります。
* Services necessary to validate the signature are no longer available at the time of validation.
* 署名を検証するために必要なサービスは、検証時には利用できなくなりました。
* Supporting evidence such as certification authority (CA) certificates, Online Certificate Status Protocol (OCSP) responses, Certificate Revocation Lists (CRLs), or timestamps is not available or can't be validated.
* 認証機関（CA）証明書、オンライン証明書ステータスプロトコル（OCSP）応答、証明書の取り消しリスト（CRL）、またはタイムスタンプなどの証拠のサポートは利用できません。
The challenges to validation of an electronic signature increase over time, and eventually it may simply be impossible to verify the signature with a sufficient level of assurance.
電子署名の検証への課題は時間とともに増加し、最終的には十分なレベルの保証で署名を検証することは不可能かもしれません。
Existing standards, such as the ETSI XAdES [XADES] profile for XML signatures [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 be validated at the cost of significant complexity, which involves storing and validating significant amounts of external evidence data such as revocation data, signature time stamps, and archival time stamps.
XML署名[XMLDSIG11]のETSI Xades [Xades]プロファイル、PDF署名[ISOPDF2]のETSI PADES [PADES]プロファイルなどの既存の標準、およびCMS署名[RFC5652]のETSIケード[ケード]プロファイルは、使用することができます。署名を有意な複雑さのコストで検証できる時間を延長します。これには、取り消しデータ、署名タイムスタンプ、アーカイブタイムスタンプなどのかなりの量の外部エビデンスデータの保存と検証が含まれます。
The Signature Validation Token (SVT) defined in this specification takes a trusted signature validation process as an input and preserves the validation result for the associated signature and signed document. The SVT asserts that a particular electronic signature was successfully validated by a trusted authority according to defined procedures at a certain time. Those procedures MUST include checks that the signature match the signed document, checks that the signature can be validated by the signing certificate, and checks that the signing certificate pass certificate path validation [RFC5280]. Those procedures MAY also include checks associated with a particular trust policy such as that an acceptable certificate policy [RFC5280] [RFC3647] was used to issue the signer's certificate and checks that an acceptable signature policy was used by the signer [RFC3125].
この仕様で定義されている署名検証トークン（SVT）は、信頼できる署名検証プロセスを入力として取得し、関連する署名ドキュメントと署名ドキュメントの検証結果を保持します。SVTは、特定の電子署名が、特定の時間に定義された手順に従って信頼できる当局によって正常に検証されたと主張しています。これらの手順には、署名が署名ドキュメントと一致すること、署名証明書によって署名が検証できることをチェックし、署名証明書証明書のパス検証[RFC5280]をチェックすることをチェックする必要があります。これらの手順には、許容可能な証明書ポリシー[RFC5280] [RFC3647]が署名者の証明書を発行するために使用され、署名者[RFC3125]が許容可能な署名ポリシーが使用されたことをチェックするなど、特定の信頼ポリシーに関連するチェックも含まれます。
Once the SVT is issued by a trusted authority, any future validation of that electronic signature can be satisfied by validating the SVT without any need to also revalidate the original electronic signature.
SVTが信頼できる当局によって発行されると、元の電子署名を再調整する必要なくSVTを検証することにより、その電子署名の将来の検証を満たすことができます。
As the SVT is used to preserve validation results obtained through applying existing standards for signature validation, it is complementary to and not a replacement for such standards, including the ETSI standards for long-term validation listed above. The SVT does, however, have the potentially positive effect that it may significantly reduce the need to apply complex long-term validation and preservation techniques for signature validation if an SVT is issued and applied to the signed document at an early stage where the signature can be validated without support of large amounts of external evidence. The use of SVTs may therefore drastically reduce the complexity of revalidation of old archived electronic signatures.
SVTは、署名検証に既存の標準を適用することで得られた検証結果を保持するために使用されるため、上記の長期検証のETSI標準を含む、そのような標準の代替ではなく、補完的であり、そのような標準の代替ではありません。ただし、SVTは、SVTが発行され、署名が署名ができる初期段階で署名文書に適用された場合、署名検証に複雑な長期検証と保存技術を適用する必要性を大幅に減らす可能性があるという潜在的にプラスの効果があります。大量の外部証拠を支持することなく検証されます。したがって、SVTの使用は、古いアーカイブされた電子署名の再検証の複雑さを大幅に減らす可能性があります。
The SVT can be signed with private keys and algorithms that provide confidence for a considerable time period. In fact, multiple SVTs can be used to offer greater assurance. For example, one SVT could be produced with a large RSA private key, a second one with a strong elliptic curve, and a third one with a quantum safe digital signature algorithm to protect against advances in computing power and cryptanalytic capabilities. Further, the trusted authority can add additional SVTs in the future using fresh private keys and signatures to extend the lifetime of the SVTs if necessary.
SVTは、かなりの期間にわたって信頼性を提供するプライベートキーとアルゴリズムで署名できます。実際、複数のSVTを使用して、より大きな保証を提供できます。たとえば、1つのSVTは、大規模なRSA秘密キー、強力な楕円曲線を備えた2番目のRSAキー、およびコンピューティングパワーと暗号化機能の進歩から保護する量子安全なデジタル署名アルゴリズムを備えた3つ目のSVTを生成できます。さらに、信頼できる当局は、新鮮なプライベートキーと署名を使用して、必要に応じてSVTの寿命を延長するために、将来SVTを追加することができます。
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.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
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).
署名データ：特定の電子署名でカバーされているデータ。これは通常、ドキュメントの署名されたコンテンツと同等であり、署名者が署名することを意図したデータを表します。一部のXML署名など、場合によっては、署名されたデータは、それぞれ署名によって参照されるいくつかのデータフラグメントのコレクションになります。PDFの場合、これは署名辞書の「Byterange」パラメーターでカバーされているデータです。JSON Web Signature（JWS）では、これはエンコードされていないペイロードデータです（base64urlエンコードの前）。
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].
署名されたバイト：これらは、デジタル署名アルゴリズムによってハッシュされて署名されたデータの実際のバイトです。ほとんどの場合、これは実際の署名データではなく、署名されたデータの参照（ハッシュ）、および署名に結合したアルゴリズムやその他のデータに関する情報を含む署名メタデータのコレクションです。XMLでは、これは標準化されたSignedInfo要素です。CMSおよびPDFシグネチャでは、これはDERエンコードされたSigneDattributes構造です。JWSでは、これは[RFC7515]に従ってフォーマットされた保護されたヘッダーとペイロードデータです。
When these terms are used as defined in this section, they appear with a capitalized first letter.
これらの用語がこのセクションで定義されているように使用される場合、それらは大文字の最初の文字で表示されます。
The Signature Validation Token (SVT) is created by a trusted service to assert evidence of successful electronic signature validation using a well-defined and trustworthy signature validation process. The SVT binds the validation result to the validated signature, the document signed by the signature, and the certificate of the signer. This allows a relying party to verify the validity of a signed document without having to revalidate the original signature or to reuse any of its associated cryptographic algorithms for as long as the SVT itself can be validated. The SVT achieves this by binding the following information to a specific electronic signature:
署名検証トークン（SVT）は、信頼できるサービスによって作成され、明確で信頼できる署名検証プロセスを使用して、電子署名検証を成功させる証拠を主張します。SVTは、検証結果を検証済みの署名、署名によって署名されたドキュメント、および署名者の証明書に結合します。これにより、頼る当事者は、SVT自体を検証できる限り、元の署名を再確認することなく、元の署名を再確認することなく、署名されたドキュメントの妥当性を検証することができます。SVTは、次の情報を特定の電子署名に結合することでこれを達成します。
* 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:
SVTは、次の戦略を適用することにより、将来にさらに拡張できる長期的な検証をサポートすることを目指しています。
* by using secure algorithms with long life expectancy when signing the SVT
* SVTに署名する際に長寿命を延ばして安全なアルゴリズムを使用することにより
* by reissuing the SVT before it becomes insecure or is considered expired
* SVTが不安になる前にSVTを再発行するか、期限切れと見なされることにより
* optionally, by issuing multiple SVTs with different algorithms to provide redundancy in case one algorithm is broken
* オプションでは、異なるアルゴリズムを使用して複数のSVTを発行して、1つのアルゴリズムが壊れた場合に冗長性を提供することにより
The SVT is carried in a JSON Web Token (JWT) as defined in [RFC7519].
SVTは、[RFC7519]で定義されているように、JSON Webトークン（JWT）で運ばれます。
The contents of claims in an SVT are specified using the following data types:
SVTのクレームの内容は、次のデータ型を使用して指定されています。
String: JSON Data Type of string that contains an arbitrary case-sensitive string value.
文字列：任意のケースに敏感な文字列値を含む文字列のJSONデータ型。
Base64Binary: JSON Data Type of string that contains a Base64-encoded byte array of binary data.
base64binary：base64エンコードされたバイト配列のバイナリデータを含むjsonデータ型文字列。
StringOrURI: JSON Data Type of string that contains an arbitrary string or a URI as defined in [RFC7519]. It is REQUIRED to contain the colon character (":") to be a URI.
stringoruri：[RFC7519]で定義されている任意の文字列またはURIを含む文字列のJSONデータ型。コロン文字（ "："）をURIにする必要があります。
URI: JSON Data Type of string that contains a URI as defined in [RFC7519].
URI：[RFC7519]で定義されているURIを含む文字列のJSONデータ型。
Integer: JSON Data Type of number that contains a 32-bit signed integer value (from -2^31 to 2^31-1).
整数：32ビットの署名された整数値を含むJSONデータ型（-2^31から2^31-1）。
Long: JSON Data Type of number that contains a 64-bit signed integer value (from -2^63 to 2^63-1).
LONG：64ビットの署名された整数値（-2^63から2^63-1）を含むJSONデータ型。
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.
数値：[RFC7519]で定義されているデータを含むJSONデータタイプ。これは、1970-01-01T00：00：00Z UTCから指定されたUTCの日付/時刻を無視して、秒数を無視する秒数です。
Boolean: JSON Data Type of boolean that contains the explicit value of true or false.
Boolean：JSONデータ型Trueまたはfalseの明示的な値を含むブール値。
Object<Class>: A JSON object holding a claims object of a class defined in this specification (see Section 3.2.2).
Object <class>：この仕様で定義されているクラスのクレームオブジェクトを保持しているJSONオブジェクト（セクション3.2.2を参照）。
Map<Type>: A JSON object with name-value pairs where the value is an object of the specified Type in the notation. For example, Map<String> is a JSON object with name-value pairs where all values are of type String.
MAP <Type>：name-valueペアを持つJSONオブジェクトが、値が表記の指定されたタイプのオブジェクトです。たとえば、Map <String>は、すべての値が型文字列の名前と値のペアを持つJSONオブジェクトです。
Array: A JSON array of a specific data type as defined in this section. An array is expressed in this specification by square brackets. For example, [String] indicates an array of String values, and [Object<DocHash>] indicates an array of DocHash objects.
配列：このセクションで定義されている特定のデータ型のJSON配列。この仕様では、四角い括弧で配列が表されます。たとえば、[string]は文字列値の配列を示し、[object <dochash>]はdochashオブジェクトの配列を示します。
Null: A JSON null that represents an absent value. A claim with a null value is equivalent with an absent claim.
null：存在しない値を表すjson null。ヌル値を持つクレームは、請求がないことと同等です。
The SVT MUST contain only JWT claims in the following list:
SVTには、次のリストにJWTクレームのみを含める必要があります。
"jti": A String data type that is a "JWT ID" registered claim according to [RFC7519]. It is RECOMMENDED that the identifier holds a hexadecimal string representation of a 128-bit unsigned integer. An SVT MUST contain one "JWT ID" claim.
「JTI」：[RFC7519]に従って登録された「JWT ID」登録された文字列データ型。識別子は、128ビットの署名されていない整数の16進の文字列表現を保持することをお勧めします。SVTには、1つの「JWT ID」クレームを含める必要があります。
"iss": A StringOrURI data type that is an "Issuer" registered claim according to [RFC7519], which is an arbitrary unique identifier of the SVT issuer. This value SHOULD have the value of a URI based on a domain owned by the issuer. An SVT MUST contain one "Issuer" claim.
「ISS」：SVT発行者の任意の一意の識別子である[RFC7519]に従って、「発行者」の登録請求であるstringoruriデータ型。この値は、発行者が所有するドメインに基づいてURIの値を持つ必要があります。SVTには、1つの「発行者」請求を含める必要があります。
"iat": A NumericDate data type that is an "Issued At" registered claim according to [RFC7519], which expresses the time when this SVT was issued. An SVT MUST contain one "Issued At" claim.
「IAT」：[RFC7519]に従って「発行された」登録請求である数値データ型は、このSVTが発行された時間を表します。SVTには、「発行された」クレームを含める必要があります。
"aud": A [StringOrURI] data type or a StringOrURI data type that is an "Audience" registered claim according to [RFC7519]. The audience claim is an array of one or more identifiers, identifying intended recipients of the SVT. Each identifier MAY identify a single entity, a group of entities, or a common policy adopted by a group of entities. If only one value is provided, it MAY be provided as a single StringOrURI data type value instead of as an array of values. Inclusion of the "Audience" claim in an SVT is OPTIONAL.
「aud」：[rfc7519]に従って「聴衆」の登録請求である[stringoruri]データ型またはstringoruriデータ型。聴衆の主張は、SVTの意図された受信者を識別する1つ以上の識別子の配列です。各識別子は、単一のエンティティ、エンティティのグループ、またはエンティティグループによって採用された共通のポリシーを識別できます。1つの値のみが提供されている場合、値の配列ではなく、単一のstringoruriデータ型値として提供される場合があります。SVTに「オーディエンス」請求を含めることはオプションです。
"exp": A NumericDate data type that is an "Expiration Time" registered claim according to [RFC7519], which expresses the time when services and responsibilities related to this SVT are no longer provided by the SVT issuer. The precise meaning of the expiration time claim is defined by local policies. See implementation note below. Inclusion of the "Expiration Time" claim in an SVT is OPTIONAL.
「Exp」：[RFC7519]に従って「有効期限」登録請求である数値データ型は、このSVTに関連するサービスと責任がSVT発行者によって提供されなくなった時間を表しています。有効期限の請求の正確な意味は、ローカルポリシーによって定義されます。以下の実装注を参照してください。SVTに「有効期限」請求を含めることはオプションです。
"sig_val_claims": An Object<SigValidation> data type that contains signature validation claims for this SVT extending the standard registered JWT claims above. An SVT MUST contain one sig_val_claims claim.
「SIG_VAL_CLAIMS」：上記の標準登録JWTクレームを拡張するこのSVTの署名検証請求を含むオブジェクト<SigValidation>データ型。SVTには、1つのsig_val_claimsクレームが含まれている必要があります。
Note: An SVT asserts that a particular validation process was undertaken at a stated time. This fact never changes and never expires. However, some other aspects of the SVT such as liability for false claims or service provision related to a specific SVT may expire after a certain period of time, such as a service where an old SVT can be upgraded to a new SVT signed with fresh keys and algorithms.
注：SVTは、特定の検証プロセスが定められた時点で行われたと主張しています。この事実は変わることはなく、期限切れになりません。ただし、特定のSVTに関連する虚偽の請求やサービス提供の責任やサービスの提供など、SVTの他の側面は、古いSVTを新鮮なキーで署名した新しいSVTにアップグレードできるサービスなど、一定期間後に期限切れになる場合があります。およびアルゴリズム。
The sig_val_claims JWT claim uses the SigValidation object class. A SigValidation object holds all custom claims, and a SigValidation object contains the following parameters:
sig_val_claims jwtクレームは、sigvalidationオブジェクトクラスを使用します。sigvalidationオブジェクトはすべてのカスタムクレームを保持し、sigvalidationオブジェクトには次のパラメーターが含まれています。
"ver": A String data type representing the version. This parameter MUST be present and the version in this specification indicated by the value "1.0".
「Ver」：バージョンを表す文字列データ型。このパラメーターは存在する必要があり、この仕様のバージョンは値「1.0」で示されています。
"profile": A StringOrURI data type representing the name of a profile that defines conventions followed for specific claims and any extension points used by the SVT issuer. This parameter MUST be present.
「プロファイル」：特定のクレームとSVT発行者が使用する拡張ポイントについて続いた慣習を定義するプロファイルの名前を表すstringoruriデータ型。このパラメーターが存在する必要があります。
"hash_algo": A URI data type that identifies the hash algorithm used to compute the hash values within the SVT. The URI identifier MUST be one defined in [RFC9231] or in the IANA registry defined by this specification. This parameter MUST be present.
「HASH_ALGO」：SVT内のハッシュ値を計算するために使用されるハッシュアルゴリズムを識別するURIデータ型。URI識別子は、[RFC9231]またはこの仕様で定義されたIANAレジストリで定義されているものでなければなりません。このパラメーターが存在する必要があります。
"sig": An [Object<Signature>] data type that gives information about validated electronic signatures as an array of Signature objects. If the SVT contains signature validation evidence for more than one signature, then each signature is represented by a separate Signature object. At least one Signature object MUST be present.
「SIG」：署名オブジェクトの配列として検証された電子署名に関する情報を提供する[Object <Signature>]データ型。SVTに複数の署名の署名検証証拠が含まれている場合、各署名は別の署名オブジェクトで表されます。少なくとも1つの署名オブジェクトが存在する必要があります。
"ext": A Map<String> data type that provides additional claims related to the SVT. Extension claims are added at the discretion of the SVT issuer; however, extension claims MUST follow any conventions defined in a profile of this specification (see Section 4). Inclusion of this parameter is OPTIONAL.
「ext」：SVTに関連する追加のクレームを提供するマップ<文字列>データ型。拡張請求は、SVT発行者の裁量で追加されます。ただし、拡張クレームは、この仕様のプロファイルで定義された条件に従う必要があります（セクション4を参照）。このパラメーターを含めることはオプションです。
The sig parameter in the SigValidation object class uses the Signature object class. The Signature object contains claims related to signature validation evidence for one signature, and it contains the following parameters:
SigValidationオブジェクトクラスのSIGパラメーターは、署名オブジェクトクラスを使用します。署名オブジェクトには、1つの署名の署名検証証拠に関連するクレームが含まれており、次のパラメーターが含まれています。
"sig_ref": An Object<SigReference> data type that contains reference information identifying the target signature. This parameter MUST be present.
「Sig_ref」：ターゲット署名を識別する参照情報を含むオブジェクト<sigreference>データ型。このパラメーターが存在する必要があります。
"sig_data_ref": An [Object<SignedDataReference>] data type that contains an array of references to Signed Data that was signed by the target electronic signature. At least one SignedDataReference object MUST be present.
「SIG_DATA_REF」：ターゲット電子署名によって署名された署名されたデータへの参照の配列を含む[Object <SignedDatareference>]データ型。少なくとも1つのSignedDatareferenceオブジェクトが存在する必要があります。
"signer_cert_ref": An Object<CertReference> data type that references the signer's certificate and optionally references a supporting certification path that was used to verify the target electronic signature. This parameter MUST be present.
「Signer_Cert_Ref」：署名者の証明書を参照し、オプションでターゲットの電子署名を検証するために使用されたサポート認定パスをオプションで参照するオブジェクト<CertReference>データ型。このパラメーターが存在する必要があります。
"sig_val": An [Object<PolicyValidation>] data type that contains an array of results of signature verification according to defined procedures. At least one PolicyValidation object MUST be present.
「Sig_val」：定義された手順に従って署名検証の結果の配列を含む[Object <PolicyValidation>]データ型。少なくとも1つのPolicyValidationオブジェクトが存在する必要があります。
"time_val": An [Object<TimeValidation>] data type that contains an array of time verification results showing that the target signature has existed at a specific time in the past. Inclusion of this parameter is OPTIONAL.
「Time_val」：ターゲット署名が過去の特定の時期に存在していたことを示す時間検証結果の配列を含む[Object <TimeValidation>]データ型。このパラメーターを含めることはオプションです。
"ext": A MAP<String> data type that provides additional claims related to the target signature. Extension claims are added at the discretion of the SVT issuer; however, extension claims MUST follow any conventions defined in a profile of this specification (see Section 4). Inclusion of this parameter is OPTIONAL.
「ext」：ターゲット署名に関連する追加のクレームを提供するマップ<文字列>データ型。拡張請求は、SVT発行者の裁量で追加されます。ただし、拡張クレームは、この仕様のプロファイルで定義された条件に従う必要があります（セクション4を参照）。このパラメーターを含めることはオプションです。
The sig_ref parameter in the Signature object class uses the SigReference object class. The SigReference object provides information used to match the Signature claims object to a specific target electronic signature and to verify the integrity of the target signature value and Signed Bytes, and it contains the following parameters:
署名オブジェクトクラスのSIG_REFパラメーターは、SigReferenceオブジェクトクラスを使用します。Sigreferenceオブジェクトは、署名クレームオブジェクトを特定のターゲット電子署名に一致させ、ターゲット署名値と署名されたバイトの整合性を確認するために使用される情報を提供し、次のパラメーターが含まれています。
"id": A String data type that contains an identifier assigned to the target signature. Inclusion of this parameter is OPTIONAL.
「ID」：ターゲット署名に割り当てられた識別子を含む文字列データ型。このパラメーターを含めることはオプションです。
"sig_hash": A Base64Binary data type that contains a hash value of the target electronic signature value. This parameter MUST be present.
「SIG_HASH」：ターゲット電子署名値のハッシュ値を含むbase64binaryデータ型。このパラメーターが存在する必要があります。
"sb_hash": A Base64Binary data type that contains a hash value of the Signed Bytes of the target electronic signature. This parameter MUST be present.
「SB_HASH」：ターゲット電子署名の署名されたバイトのハッシュ値を含むbase64binaryデータ型。このパラメーターが存在する必要があります。
The sig_data_ref parameter in the Signature object class uses the SignedDataReference object class. The SignedDataReference object provides information used to verify the target electronic signature references to Signed Data as well as to verify the integrity of all data that is signed by the target signature, and it contains the following parameters:
署名オブジェクトクラスのSIG_DATA_REFパラメーターは、SignedDatareferenceオブジェクトクラスを使用します。SignedDatareferenceオブジェクトは、標的電子署名参照を署名データへのターゲットの署名参照を確認するために使用される情報と、ターゲット署名によって署名されたすべてのデータの整合性を確認するために提供され、次のパラメーターが含まれています。
"ref": A String data type that contains a reference identifier for the data or data fragment covered by the target electronic signature. This parameter MUST be present.
「Ref」：ターゲット電子署名でカバーされているデータまたはデータフラグメントの参照識別子を含む文字列データ型。このパラメーターが存在する必要があります。
"hash": A Base64Binary data type that contains the hash value for the data covered by the target electronic signature. This parameter MUST be present.
「ハッシュ」：ターゲット電子署名でカバーされているデータのハッシュ値を含むbase64binaryデータ型。このパラメーターが存在する必要があります。
The sig_val parameter in the Signature object class uses the PolicyValidation object class. The PolicyValidation object provides information about the result of a validation process according to a specific policy, and it contains the following parameters:
署名オブジェクトクラスのSig_valパラメーターは、PolicyValidationオブジェクトクラスを使用します。PolicyValidationオブジェクトは、特定のポリシーに従って検証プロセスの結果に関する情報を提供し、次のパラメーターが含まれています。
"pol": A StringOrURI data type that contains the identifier of the policy governing the electronic signature verification process. This parameter MUST be present.
「Pol」：電子署名検証プロセスを管理するポリシーの識別子を含むstringoruriデータ型。このパラメーターが存在する必要があります。
"res": A String data type that contains the result of the electronic signature verification process. The value MUST be one of "PASSED", "FAILED", or "INDETERMINATE" as defined by [ETSI319102-1]. This parameter MUST be present.
「RES」：電子署名検証プロセスの結果を含む文字列データ型。値は、[ETSI319102-1]で定義されているように、「渡された」、「失敗」、または「不確定」の1つでなければなりません。このパラメーターが存在する必要があります。
"msg": A String data type that contains a message describing the result. Inclusion of this parameter is OPTIONAL.
「MSG」：結果を説明するメッセージを含む文字列データ型。このパラメーターを含めることはオプションです。
"ext": A MAP<String> data type that provides additional claims related to the target signature. Extension claims are added at the discretion of the SVT issuer; however, extension claims MUST follow any conventions defined in a profile of this specification (see Section 4). Inclusion of this parameter is OPTIONAL.
「ext」：ターゲット署名に関連する追加のクレームを提供するマップ<文字列>データ型。拡張請求は、SVT発行者の裁量で追加されます。ただし、拡張クレームは、この仕様のプロファイルで定義された条件に従う必要があります（セクション4を参照）。このパラメーターを含めることはオプションです。
The time_val parameter in the Signature object class uses the TimeValidation object class. The TimeValidation claims object provides information about the result of validating evidence of time asserting that the target signature existed at a particular time in the past. Evidence of time is typically a timestamp according to [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_valパラメーターは、timevalidationオブジェクトクラスを使用します。TimeValidationクレームオブジェクトは、ターゲットの署名が過去の特定の時期に存在していたと主張する時間の証拠を検証した結果に関する情報を提供します。時間の証拠は通常、[RFC3161]によるとタイムスタンプですが、この署名のために以前に発行されたSVTなど、他のタイプの証拠が使用される場合があります。TimeValidationクレームオブジェクトには、次のパラメーターが含まれています。
"time": A NumericDate data type that contains the verified time. This parameter MUST be present.
「時間」：検証された時間を含む数値データ型。このパラメーターが存在する必要があります。
"type": A StringOrURI data type that contains an identifier of the type of evidence of time. This parameter MUST be present.
「タイプ」：時間の証拠の種類の識別子を含むstringoruriデータ型。このパラメーターが存在する必要があります。
"iss": A StringOrURI data type that contains an identifier of the entity that issued the evidence of time. This parameter MUST be present.
「ISS」：時間の証拠を発行したエンティティの識別子を含むstringoruriデータ型。このパラメーターが存在する必要があります。
"id": A String data type that contains an unique identifier assigned to the evidence of time. Inclusion of this parameter is OPTIONAL.
「ID」：時間の証拠に割り当てられた一意の識別子を含む文字列データ型。このパラメーターを含めることはオプションです。
"hash": A Base64Binary data type that contains the hash value of the validated evidence of time. Inclusion of this parameter is OPTIONAL.
「ハッシュ」：検証された時間の証拠のハッシュ値を含むbase64binaryデータ型。このパラメーターを含めることはオプションです。
"val": An [Object<PolicyValidation>] data type that contains an array of results of the time evidence validation according to defined validation procedures. Inclusion of this parameter is OPTIONAL.
「Val」：定義された検証手順に従って時間証拠検証の結果の配列を含む[Object <PolicyValidation>]データ型。このパラメーターを含めることはオプションです。
"ext": A MAP<String> data type that provides additional claims related to the target signature. Extension claims are added at the discretion of the SVT issuer; however, extension claims MUST follow any conventions defined in a profile of this specification (see Section 4). Inclusion of this parameter is OPTIONAL.
「ext」：ターゲット署名に関連する追加のクレームを提供するマップ<文字列>データ型。拡張請求は、SVT発行者の裁量で追加されます。ただし、拡張クレームは、この仕様のプロファイルで定義された条件に従う必要があります（セクション4を参照）。このパラメーターを含めることはオプションです。
The signer_cert_ref parameter in the Signature object class uses the CertReference object class. The CertReference object references a single X.509 certificate or a X.509 certification path either by providing the certificate data or by providing hash references for certificates that can be located in the target electronic signature, and it contains the following parameters:
Signature ObjectクラスのSigner_Cert_Refパラメーターは、Certreference Objectクラスを使用します。CertReferenceオブジェクトは、証明書データを提供するか、ターゲット電子署名に配置できる証明書のハッシュ参照を提供することにより、単一のx.509証明書またはX.509認証パスを参照します。
"type": A StringOrURI data type that contains an identifier of the type of reference. The type identifier MUST be one of the identifiers defined below, an identifier specified by the selected profile, or a URI identifier. This parameter MUST be present.
「タイプ」：参照のタイプの識別子を含むstringoruriデータ型。型識別子は、以下に定義された識別子のいずれか、選択したプロファイルによって指定された識別子、またはURI識別子でなければなりません。このパラメーターが存在する必要があります。
"ref": A [String] data type that contains an array of string parameters according to conventions defined by the type identifier. At least one parameter MUST be present.
"ref"：型識別子で定義された規則に従って文字列パラメーターの配列を含む[文字列]データ型。少なくとも1つのパラメーターが存在する必要があります。
The following type identifiers are defined:
次のタイプ識別子が定義されています。
"chain": The ref contains an array of Base64-encoded X.509 certificates [RFC5280]. The certificates MUST be provided in the order starting with the end entity certificate. Any following certificate must be able to validate the signature on the previous certificate in the array.
「チェーン」：REFには、Base64エンコードX.509証明書の配列が含まれています[RFC5280]。証明書は、End Entity証明書から始まる注文で提供する必要があります。次の証明書は、配列内の前の証明書の署名を検証できる必要があります。
"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 certificates MUST be provided in the order starting with the end entity certificate. Any following certificate must be able to validate the signature on the previous certificate in the array. This option MUST NOT be used unless all hashed certificates are present in the target electronic signature.
"Chain_hash"：refには、各ハッシュ値が署名を検証するために使用されるx.509証明書[RFC5280]を超えるハッシュ値がある1つ以上のbase64エンコードハッシュ値の配列が含まれています。証明書は、End Entity証明書から始まる注文で提供する必要があります。次の証明書は、配列内の前の証明書の署名を検証できる必要があります。このオプションは、すべてのハッシュされた証明書がターゲット電子署名に存在しない限り、使用しないでください。
Note: All certificates referenced using the identifiers above are X.509 certificates. Profiles of this specification MAY define alternative types of public key containers; however, a major function of these referenced certificates is not just to reference the public key but also to provide the subject name of the signer. It is therefore important for the full function of an SVT that the referenced public key container also provides the means to identify the signer.
注：上記の識別子を使用して参照されるすべての証明書はX.509証明書です。この仕様のプロファイルは、代替タイプの公開キーコンテナを定義する場合があります。ただし、これらの参照されている証明書の主要な機能は、公開鍵を参照するだけでなく、署名者の件名を提供することでもあります。したがって、参照される公開キーコンテナが署名者を識別する手段も提供することがSVTの完全な機能にとって重要です。
The SVT JWT MUST contain the following JSON Object Signing and Encryption (JOSE) header parameters in accordance with Section 5 of [RFC7519]:
SVT JWTには、[RFC7519]のセクション5に従って、次のJSONオブジェクトの署名および暗号化（ホセ）ヘッダーパラメーターを含める必要があります。
"typ": This parameter MUST have the string value "JWT" (upper case).
「typ」：このパラメーターには、文字列値「JWT」（上品）が必要です。
"alg": This parameter identifies the algorithm used to sign the SVT JWT. The algorithm identifier MUST be specified in [RFC7518] or the IANA "JSON Web Signature and Encryption Algorithms" registry [IANA-JOSE-REG]. The specified signature hash algorithm MUST be identical to the hash algorithm specified in the hash_algo parameter of the SigValidation object within the sig_val_claims claim.
「alg」：このパラメーターは、SVT JWTに署名するために使用されるアルゴリズムを識別します。アルゴリズム識別子は、[RFC7518]またはIANA "JSON Web署名および暗号化アルゴリズム"レジストリ[iana-jose-reg]で指定する必要があります。指定された署名ハッシュアルゴリズムは、SIG_VAL_CLAIMSクレーム内のSIGValidationオブジェクトのHASH_ALGOパラメーターで指定されたハッシュアルゴリズムと同一でなければなりません。
The SVT header MUST contain a public key or a reference to a public key used to verify the signature on the SVT in accordance with [RFC7515]. Each profile, as discussed in Section 4, MUST define the requirements for how the key or key reference is included in the header.
SVTヘッダーには、[RFC7515]に従ってSVTの署名を検証するために使用される公開キーまたは公開キーへの参照を含める必要があります。セクション4で説明した各プロファイルは、キーまたはキー参照がヘッダーに含まれる方法の要件を定義する必要があります。
Each signed document and signature type will have to define the precise content and use of several claims in the SVT.
各署名されたドキュメントと署名タイプは、SVTでのいくつかのクレームの正確なコンテンツと使用を定義する必要があります。
At a minimum, each profile MUST define:
少なくとも、各プロファイルを定義する必要があります。
* The identifier of the profile
* プロファイルの識別子
* How to reference the Signed Data content of the signed document
* 署名されたドキュメントの署名されたデータコンテンツを参照する方法
* How to reference the target electronic signature and the Signed Bytes of the signature
* ターゲットの電子署名と署名の署名されたバイトを参照する方法
* How to reference certificates supporting each electronic signature
* 各電子署名をサポートする証明書を参照する方法
* How to include public keys or references to public keys in the SVT
* SVTのパブリックキーや公開キーへの参照を含める方法
* Whether each electronic signature is supported by a single SVT, or one SVT may support multiple electronic signatures of the same document
* 各電子署名が単一のSVTによってサポートされているか、1つのSVTが同じドキュメントの複数の電子署名をサポートできるかどうか
A profile MAY also define:
プロファイルも定義する場合があります。
* Explicit information on how to perform signature validation based on an SVT
* SVTに基づいて署名検証を実行する方法に関する明示的な情報
* How to attach an SVT to an electronic signature or signed document
* SVTを電子署名または署名ドキュメントに添付する方法
The following profiles are defined in appendixes of this document:
次のプロファイルは、このドキュメントの付録で定義されています。
Appendix A: XML Signature Profile
付録A：XML署名プロファイル
Appendix B: PDF Signature Profile
付録B：PDF署名プロファイル
Appendix C: JWS Profile
付録C：JWSプロファイル
Other documents MAY define other profiles that MAY complement, amend, or supersede these profiles.
他のドキュメントは、これらのプロファイルを補完、修正、または置き換える可能性のある他のプロファイルを定義する場合があります。
Signature verification based on an SVT MUST follow these steps:
SVTに基づく署名検証は、次の手順に従う必要があります。
1. Locate all available SVTs available for the signed document that are relevant for the target electronic signature.
1. ターゲット電子署名に関連する署名されたドキュメントで利用可能なすべてのSVTを見つけます。
2. Select the most recent SVT that can be successfully validated and meets the requirement of the relying party.
2. 正常に検証できる最新のSVTを選択し、頼る当事者の要件を満たすことができます。
3. Verify the integrity of the signature and the Signed Bytes of the target electronic signature using the sig_ref claim.
3. SIG_REFクレームを使用して、標的電子署名の署名と署名されたバイトの整合性を確認します。
4. Verify that the Signed Data reference in the original electronic signature matches the reference values in the sig_data_ref claim.
4. 元の電子署名の署名されたデータ参照がSIG_DATA_REFクレームの参照値と一致することを確認します。
5. Verify the integrity of referenced Signed Data using provided hash values in the sig_data_ref claim.
5. SIG_DATA_REFクレームで提供されたハッシュ値を使用して、参照された署名されたデータの整合性を確認します。
6. Obtain the verified certificates supporting the asserted electronic signature verification through the signer_cert_ref claim.
6. Signer_Cert_Refクレームを介して主張された電子署名検証をサポートする検証済みの証明書を取得します。
7. Verify that signature validation policy results satisfy the requirements of the relying party.
7. 署名検証ポリシーの結果が、頼る当事者の要件を満たしていることを確認します。
8. Verify that verified time results satisfy the context for the use of the signed document.
8. 検証された時間結果が、署名されたドキュメントを使用するためのコンテキストを満たすことを確認します。
After successfully performing these steps, signature validity is established as well as the trusted signer certificate binding the identity of the signer to the electronic signature.
これらの手順を正常に実行した後、署名の妥当性が確立され、信頼できる署名者証明書が署名者の身元を電子署名に拘束します。
IANA has registered the "sig_val_claims" claim name in the "JSON Web Token Claims" registry established by Section 10.1 of [RFC7519].
IANAは、[RFC7519]のセクション10.1で確立された「JSON Webトークンクレーム」レジストリに「sig_val_claims」クレーム名を登録しました。
Claim Name: sig_val_claims
クレーム名：sig_val_claims
Claim Description: Signature Validation Token
クレームの説明：署名検証トークン
Change Controller: IESG
Change Controller：IESG
Specification Document(s): Section 3.2.3 of RFC 9321
仕様文書：RFC 9321のセクション3.2.3
IANA has registered the "svt" Header Parameter in the "JSON Web Signature and Encryption Header Parameters" registry established by [RFC7515].
IANAは、[RFC7515]によって確立された「JSON Web署名および暗号化ヘッダーパラメーター」レジストリに「SVT」ヘッダーパラメーターを登録しています。
Header Parameter Name: svt
ヘッダーパラメーター名：SVT
Header Parameter Description: Signature Validation Token
ヘッダーパラメーター説明：署名検証トークン
Header Parameter Usage Location(s): JWS
ヘッダーパラメーターの使用場所：JWS
Change Controller: IESG
Change Controller：IESG
Specification Document(s): Appendix C.1.1 of RFC 9321
仕様文書：RFC 9321の付録C.1.1
An SVT allows a signature verifier to still validate the original signature using the original signature data and to use the information in the SVT selectively to confirm the validity and integrity of the original data, such as confirming the integrity of Signed Data or the validity of the signer's certificate, etc.
SVTを使用すると、署名検証者は元の署名データを使用して元の署名を検証し、SVTの情報を選択的に使用して、署名データの整合性やsignedデータの整合性の確認など、元のデータの有効性と整合性を確認できます。署名者の証明書など。
Another way to use an SVT is to completely rely on the validation conclusion provided by the SVT and to omit revalidation of the original signature value and original certificate status checking data.
SVTを使用する別の方法は、SVTが提供する検証の結論に完全に依存し、元の署名値と元の証明書ステータスチェックデータの再確認を省略することです。
This choice is a decision made by the verifier according to its own policy and risk assessment.
この選択は、それ自体のポリシーとリスク評価に従って、検証者によって行われた決定です。
However, even when relying on the SVT validation conclusion of an SVT, it is vital to still verify that the present SVT is correctly associated with the document and signature that is being validated by validating the hashed reference data in the SVT of the signature, signing certificate chain, Signed Data, and the Signed Bytes.
ただし、SVTのSVT検証結論に依存している場合でも、現在のSVTが署名のSVTのハッシュされた参照データを検証することにより検証されているドキュメントと署名に正しく関連付けられていることを確認することが重要です。証明書チェーン、署名データ、および署名されたバイト。
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.
SVTがアルゴリズムに対する保護を時間の経過とともに弱めたり壊したりすることに対して保護を提供したとしても、この保護は、SVTの署名に使用されるアルゴリズムが依然として安全であると見なされる限りのみ有効です。SVTを保護するアルゴリズムが終末期に近づいている場合、SVTを再発行することをお勧めします。
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.
アルゴリズムの抵抗を高める1つの方法は、異なるアルゴリズムとキー長さで同じ署名に対して複数のSVTを発行することです。これにより、代替SVTで使用されているアルゴリズムが破損していても、1つのアルゴリズムがまだ安全である可能性があります。
[CADES] ETSI, "Electronic Signatures and Infrastructures (ESI); CAdES digital signatures; Part 1: Building blocks and CAdES baseline signatures", v1.1.1, ETSI EN 319 122-1, April 2016.
[Cades] Etsi、「電子署名とインフラストラクチャ（ESI）;ケードデジタル署名;パート1：ビルディングブロックとケードベースライン署名」、v1.1.1、Etsi EN 319 122-1、2016年4月。
[ETSI319102-1] ETSI, "Electronic Signatures and Infrastructures (ESI); Procedures for Creation and Validation of AdES Digital Signatures; Part 1: Creation and Validation", v1.1.1, ETSI EN 319 102-1, May 2016.
[ETSI319102-1] ETSI、「電子署名とインフラストラクチャ（ESI）、ADESデジタル署名の作成と検証の手順、パート1：作成と検証」、v1.1.1、ETSI EN 319 102-1、2016年5月。
[IANA-JOSE-REG] IANA, "JSON Object Signing and Encryption (JOSE)", <https://www.iana.org/assignments/jose/>.
[Iana-jose-reg] iana、 "jsonオブジェクト署名と暗号化（ホセ）"、<https://www.iana.org/assignments/jose/>。
[ISOPDF2] ISO, "Document management -- Portable document format -- Part 2: PDF 2.0", ISO 32000-2:2020, December 2020.
[ISOPDF2] ISO、「ドキュメント管理 - ポータブルドキュメント形式 - パート2：PDF 2.0」、ISO 32000-2：2020、2020年12月。
[PADES] ETSI, "Electronic Signatures and Infrastructures (ESI); PAdES digital signatures; Part 1: Building blocks and PAdES baseline signatures", v1.1.1, ETSI EN 319 142-1, April 2016.
[PADES] ETSI、「電子署名とインフラストラクチャ（ESI）; Padesデジタル署名;パート1：ビルディングブロックとパッドベースライン署名」、v1.1.1、Etsi EN 319 142-1、2016年4月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487/RFC2119、1997年3月、<https://www.rfc-editor.org/info/RFC2119>。
[RFC3125] Ross, J., Pinkas, D., and N. Pope, "Electronic Signature Policies", RFC 3125, DOI 10.17487/RFC3125, September 2001, <https://www.rfc-editor.org/info/rfc3125>.
[RFC3125] Ross、J.、Pinkas、D。、およびN. Pope、「電子署名ポリシー」、RFC 3125、DOI 10.17487/RFC3125、2001年9月、<https://www.rfc-editor.org/info/RFC3125>。
[RFC3161] Adams, C., Cain, P., Pinkas, D., and R. Zuccherato, "Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)", RFC 3161, DOI 10.17487/RFC3161, August 2001, <https://www.rfc-editor.org/info/rfc3161>.
[RFC3161] Adams、C.、Cain、P.、Pinkas、D。、およびR. Zuccherato、「Internet X.509公開キーインフラストラクチャタイムスタンププロトコル（TSP）」、RFC 3161、DOI 10.17487/RFC3161、2001年8月、<https://www.rfc-editor.org/info/rfc3161>。
[RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. Wu, "Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework", RFC 3647, DOI 10.17487/RFC3647, November 2003, <https://www.rfc-editor.org/info/rfc3647>.
[RFC3647] Chokhani、S.、Ford、W.、Sabett、R.、Merrill、C。、およびS. Wu、「Internet X.509公開キーインフラストラクチャ証明書ポリシーおよび認証慣行フレームワーク」、RFC 3647、DOI 10.17487/RFC3647、2003年11月、<https://www.rfc-editor.org/info/rfc3647>。
[RFC5035] Schaad, J., "Enhanced Security Services (ESS) Update: Adding CertID Algorithm Agility", RFC 5035, DOI 10.17487/RFC5035, August 2007, <https://www.rfc-editor.org/info/rfc5035>.
[RFC5035] Schaad、J。、「強化されたセキュリティサービス（ESS）アップデート：CertID Algorithm Agilityの追加」、RFC 5035、DOI 10.17487/RFC5035、2007年8月、<https://www.rfc-editor.org/info/RFC5035555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555>。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/info/rfc5280>.
[RFC5280] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R.、およびW. Polk、 "Internet X.509公開キーインフラストラクチャ証明書および証明書失効リスト（CRL）プロファイル"、RFC 5280、DOI 10.17487/RFC5280、2008年5月、<https://www.rfc-editor.org/info/rfc5280>。
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, DOI 10.17487/RFC5652, September 2009, <https://www.rfc-editor.org/info/rfc5652>.
[RFC5652] Housley、R。、「暗号化メッセージ構文（CMS）」、STD 70、RFC 5652、DOI 10.17487/RFC5652、2009年9月、<https://www.rfc-editor.org/info/rfc5652>
[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, <https://www.rfc-editor.org/info/rfc7515>.
[RFC7515] Jones、M.、Bradley、J。、およびN. Sakimura、「JSON Web Signature（JWS）」、RFC 7515、DOI 10.17487/RFC7515、2015年5月、<https://www.rfc-editor.org/info/rfc7515>。
[RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, DOI 10.17487/RFC7518, May 2015, <https://www.rfc-editor.org/info/rfc7518>.
[RFC7518]ジョーンズ、M。、「JSON Webアルゴリズム（JWA）」、RFC 7518、DOI 10.17487/RFC7518、2015年5月、<https://www.rfc-editor.org/info/rfc7518>
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, <https://www.rfc-editor.org/info/rfc7519>.
[RFC7519] Jones、M.、Bradley、J。、およびN. Sakimura、「JSON Web Token（JWT）」、RFC 7519、DOI 10.17487/RFC7519、2015年5月、<https：//www.rfc-editor.org/info/rfc7519>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487/RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。
[RFC9231] Eastlake 3rd, D., "Additional XML Security Uniform Resource Identifiers (URIs)", RFC 9231, DOI 10.17487/RFC9231, July 2022, <https://www.rfc-editor.org/info/rfc9231>.
[RFC9231] EastLake 3rd、D。、「追加のXMLセキュリティユニフォームリソース識別子（URIS）」、RFC 9231、DOI 10.17487/RFC9231、2022年7月、<https://www.rfc-editor.org/info/rfc9231>。
[XADES] ETSI, "Electronic Signatures and Infrastructures (ESI); XAdES digital signatures; Part 1: Building blocks and XAdES baseline signatures", v1.1.1, ETSI EN 319 132-1, April 2016.
[Xades] Etsi、「電子署名とインフラストラクチャ（ESI）; Xadesデジタル署名;パート1：ビルディングブロックとXadesベースライン署名」、v1.1.1、Etsi EN 319 132-1、2016年4月。
[XMLDSIG11] Eastlake 3rd, D., Reagle, J., Solo, D., Hirsch, F., Nystrom, M., Roessler, T., and K. Yiu, "XML Signature Syntax and Processing Version 1.1", W3C Proposed Recommendation, April 2013. Latest version available at https://www.w3.org/TR/xmldsig- core1/.
[xmldsig11] Eastlake 3rd、D.、Reagle、J.、Solo、D.、Hirsch、F.、Nystrom、M.、Roessler、T。、およびK. Yiu、 "XML Signature Syntax and Processingバージョン1.1"、W3C提案された推奨、2013年4月。最新バージョンhttps://www.w3.org/tr/xmldsig-core1/で入手可能。
[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, June 2019, <https://www.rfc-editor.org/info/rfc8610>.
[RFC8610] Birkholz、H.、Vigano、C。、およびC. Bormann、「Scise Data Definition Language（CDDL）：簡潔なバイナリオブジェクト表現（CBOR）およびJSONデータ構造を表現する表記規則」、RFC 8610、DOI 10.17487/RFC8610、2019年6月、<https://www.rfc-editor.org/info/rfc8610>。
This appendix defines a profile for implementing SVTs with a signed XML document and defines the following aspects of SVT usage:
この付録は、署名済みXMLドキュメントを使用してSVTを実装するためのプロファイルを定義し、SVT使用の次の側面を定義します。
* How to include reference data related to XML signatures and XML documents in an SVT
* SVTにXML署名とXMLドキュメントに関連する参照データを含める方法
* How to add an SVT token to an XML signature
* XML署名にSVTトークンを追加する方法
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).
XMLドキュメントには、XMLドキュメントの任意の数のフラグメントに署名する任意の数の署名要素を持つことができます。実際の署名要素は、署名されたXMLドキュメント（包括された）に含まれたり、署名されたデータ（封筒）を含めたり、署名されたコンテンツ（デタッチ）とは別に含まれたりすることがあります。
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.
あらゆるタイプのXML署名に一般的なソリューションを提供するために、XML署名<DS：Object>要素内の各XML署名要素にSVTが追加されます。
When referring to elements from the W3C XML Signature namespace (https://www.w3.org/2000/09/xmldsig#), the following syntax is used:
W3C XML署名名空間（https://www.w3.org/2000/09/xmldsig#）の要素を参照する場合、次の構文を使用します。
* <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:
ETSI Xades XML Signature Namespace（https://uri.etsi.org/01903/V1.3.2#）の要素を参照する場合、次の構文が使用されます。
* <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:
この仕様（http://id.swedenconnect.se/svt/1.0/sig-prop/ns）で定義されている要素を参照する場合、次の構文が使用されます。
* <svt:Element>
When SVTs are provided for XML signatures, then one SVT MUST be provided for each XML signature.
XML署名にSVTが提供される場合、各XML署名に対して1つのSVTを提供する必要があります。
An SVT embedded within the XML signature element MUST be placed in a <svt:SignatureValidationToken> element as defined in Appendix A.2.1.
XML署名要素内に埋め込まれたSVTは、付録A.2.1で定義されているように、<SVT：SignatureValidationToken>要素に配置する必要があります。
The <svt:SignatureValidationToken> element MUST be placed in a <ds:SignatureProperty> element in accordance with [XMLDSIG11]. The <ds:SignatureProperty> element MUST be placed inside a <ds:SignatureProperties> element inside a <ds:Object> element inside a <ds:Signature> element.
<svt：signaturevalidationtoken>要素は、[xmldsig11]に従って<ds：signatureProperty>要素に配置する必要があります。<ds：signatureProperty>要素は、<ds：signatureproperties> <ds：object>要素内の<ds：signature>要素内に配置する必要があります。
Note: [XMLDSIG11] requires the Target attribute to be present in <ds:SignatureProperty>, referencing the signature targeted by this signature property. If an SVT is added to a signature that does not have an Id attribute, implementations SHOULD add an Id attribute to the <ds:Signature> element and reference that Id in the Target attribute. This Id attribute and Target attribute value matching is required by the [XMLDSIG11] standard, but it is redundant in the context of SVT validation as the SVT already contains information that uniquely identifies the target signature. Validation applications SHOULD NOT reject an SVT token because of Id and Target attribute mismatch and MUST rely on matching against a signature using signed information in the SVT itself.
注：[XMLDSIG11]では、この署名プロパティの標的を参照する<DS：SignatureProperty>にターゲット属性を存在する必要があります。SVTがID属性を持たない署名に追加された場合、実装は<DS：signature>要素にID属性を追加し、ターゲット属性のIDを参照する必要があります。このID属性とターゲット属性の値マッチングは[XMLDSIG11]標準で必要ですが、SVTにはターゲット署名を一意に識別する情報が既に含まれているため、SVT検証のコンテキストでは冗長です。検証アプリケーションは、IDおよびターゲット属性の不一致のためにSVTトークンを拒否しないでください。また、SVT自体の署名情報を使用して署名と一致することに依存する必要があります。
The <svt:SignatureValidationToken> element is defined by the following XML Schema:
<svt：signaturevalidationtoken>要素は、次のXMLスキーマで定義されています。
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
targetNamespace="http://id.swedenconnect.se/svt/1.0/sig-prop/ns"
xmlns:svt="http://id.swedenconnect.se/svt/1.0/sig-prop/ns">
<xs:element name="SignatureValidationToken"
type="svt:SignatureValidationTokenType" />
<xs:complexType name="SignatureValidationTokenType">
<xs:simpleContent>
<xs:extension base="xs:string">
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:schema>
The SVT token MUST be included as a string representation of the SVT JWT. Note that this is the string representation of the JWT without further encoding. The SVT MUST NOT be represented by the Base64-encoded bytes of the JWT string.
SVTトークンは、SVT JWTの文字列表現として含める必要があります。これは、それ以上エンコードせずにJWTの文字列表現であることに注意してください。SVTは、JWT文字列のBase64エンコードバイトで表されてはなりません。
Example:
例：
<ds:Signature Id="MySignatureId">
...
<ds:Object>
<ds:SignatureProperties>
<ds:SignatureProperty Target="#MySignatureId">
<svt:SignatureValidationToken>
eyJ0eXAiOiJKV1QiLCJhb...2aNZ
</svt:SignatureValidationToken>
</ds:SignatureProperty>
</ds:SignatureProperties>
</ds:Object>
</ds:Signature>
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.
新しいSVTが以前に発行されたSVTを既に含む署名に保存されている場合、実装は既存のSVTを交換するか、既存のSVTに加えて新しいSVTを保存するために選択できます。
If the new SVT is stored in addition to the old SVT, it SHOULD be stored in a new <ds:SignatureProperty> element inside the existing <ds:SignatureProperties> element where the old SVT is located.
新しいSVTが古いSVTに加えて保存されている場合、古いSVTが配置されている既存の<DS：Signature Properties>要素内の新しい<DS：Signatureプロパティ>要素に保存する必要があります。
For interoperability robustness, signature validation applications MUST be able to handle signatures where the new SVT is located in a new <ds:Object> element.
相互運用性の堅牢性のために、署名検証アプリケーションは、新しいSVTが新しい<DS：Object>要素に配置されている署名を処理できる必要があります。
When this profile is used, the SigValidation object MUST contain a "profile" claim with the value "XML".
このプロファイルを使用する場合、sigvalidationオブジェクトには、値「XML」の「プロファイル」クレームを含める必要があります。
The SVT Signature object MUST contain a "sig_ref" claim (SigReference object) with the following elements:
SVT署名オブジェクトには、次の要素を持つ「Sig_ref」クレーム（Sigreferenceオブジェクト）が含まれている必要があります。
"id": The Id-attribute of the XML signature, if present.
「ID」：存在する場合はXML署名のIDアトリブ。
"sig_hash": The hash over the signature value bytes.
「Sig_Hash」：署名値のバイトに対するハッシュ。
"sb_hash": The hash over the canonicalized <ds:SignedInfo> element (the bytes the XML signature algorithm has signed to generate the signature value).
"sb_hash"：標準化された<ds：signedinfo>要素の上のハッシュ（XML署名アルゴリズムが署名して署名値を生成するバイト）。
The SVT Signature object MUST contain one instance of the "sig_data" claim (SignedData object) for each <ds:Reference> element in the <ds:SignedInfo> element. The "sig_data" claim MUST contain the following elements:
SVT署名オブジェクトには、各<DS：参照>要素の「SIG_DATA」クレーム（SignedDataオブジェクト）の1つのインスタンスを含める必要があります。「SIG_DATA」クレームには、次の要素が含まれている必要があります。
"ref": The value of the URI attribute of the corresponding <ds:Reference> element.
「Ref」：対応する<DS：参照>要素のURI属性の値。
"hash": The hash of all bytes that were identified by the corresponding <ds:Reference> element after applying all identified canonicalization and transformation algorithms. These are the same bytes that are hashed by the hash value in the <ds:DigestValue> element inside the <ds:Reference> element.
「ハッシュ」：識別されたすべての標準化および変換アルゴリズムを適用した後、対応する<DS：参照>要素によって識別されたすべてのバイトのハッシュ。これらは、<ds：digestvalue>要素のハッシュ値によってハッシュされた同じバイトです<ds：参照>要素。
The SVT Signature object MUST contain a "signer_cert_ref" claim (CertReference object). The "type" parameter of the "signer_cert_ref" claim MUST be either "chain" or "chain_hash".
SVT署名オブジェクトには、「Signer_Cert_Ref」クレーム（certreferenceオブジェクト）が含まれている必要があります。「signer_cert_ref」クレームの「タイプ」パラメーターは、「チェーン」または「chain_hash」のいずれかでなければなりません。
* The "chain" type MUST be used when signature validation was performed using one or more certificates where some or all of the certificates in the chain are not present in the target signature.
* 「チェーン」タイプは、標的署名にチェーン内の証明書の一部またはすべてが存在しない1つ以上の証明書を使用して署名検証を実行した場合に使用する必要があります。
* The "chain_hash" type MUST be used when signature validation was performed using one or more certificates where all of the certificates are present in the target signature.
* 署名検証がターゲット署名にすべての証明書が存在する1つ以上の証明書を使用して署名検証が実行された場合、「chain_hash」タイプを使用する必要があります。
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:
XML署名用のSVTホセヘッダーには、SVTの署名を検証するために使用される公開キーへの参照を保存するために、[RFC7515]に従って次のヘッダーパラメーターのいずれかを含める必要があります。
"x5c": Holds an X.509 certificate [RFC5280] or a chain of certificates. The certificate holding the public key that verifies the signature on the SVT MUST be the first certificate in the chain.
「X5C」：X.509証明書[RFC5280]または一連の証明書を保持します。SVTの署名を検証する公開キーを保持している証明書は、チェーン内の最初の証明書でなければなりません。
"kid": A key identifier holding the Base64-encoded hash value of the certificate that can verify the signature on the SVT. The hash algorithm MUST be the same hash algorithm used when signing the SVT as specified by the "alg" Header Parameter.
「KID」：SVTの署名を確認できる証明書のbase64エンコードのハッシュ値を保持しているキー識別子。ハッシュアルゴリズムは、「アルグ」ヘッダーパラメーターで指定されているようにSVTに署名するときに使用されるハッシュアルゴリズムと同じでなければなりません。
This appendix defines a profile for implementing SVTs with a signed PDF document, and it defines the following aspects of SVT usage:
この付録は、署名されたPDFドキュメントを使用してSVTを実装するためのプロファイルを定義し、SVT使用の次の側面を定義します。
* How to include reference data related to PDF signatures and PDF documents in an SVT.
* SVTにPDF署名とPDFドキュメントに関連する参照データを含める方法。
* How to add an SVT token to a PDF document.
* SVTトークンをPDFドキュメントに追加する方法。
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.
PDFドキュメント署名は、署名されたPDFドキュメントの増分更新として追加され、現在の署名までPDFドキュメントのすべてのデータに署名します。PDFドキュメントに複数の署名が追加された場合、以前の署名は次の署名によって署名され、このイベントの後に追加のデータで更新することはできません。
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.
複数の署名を持つPDFドキュメントへの影響を最小限に抑え、SVTSを理解していないPDFソフトウェアと互換性のある順に留まるために、PDFドキュメントは、署名されたPDFに追加されたドキュメントタイムスタンプへの拡張機能として、PDFのすべての署名に対して1つのSVTトークンを追加します。増分更新。このSVTは、署名されたPDFのすべての署名をカバーしています。
The SVT for a signed PDF document MAY provide signature validation information about any of the present signatures in the PDF. The SVT MUST contain a separate "sig" claim (Signature object) for each signature on the PDF that is covered by the SVT.
署名されたPDFドキュメントのSVTは、PDFの現在の署名に関する署名検証情報を提供できます。SVTには、SVTでカバーされているPDFの各署名に対して、個別の「SIG」クレーム（署名オブジェクト）を含める必要があります。
An SVT added to a signed PDF document MUST be added to a document timestamp in accordance with ISO 32000-2:2020 [ISOPDF2].
署名されたPDFドキュメントに追加されたSVTは、ISO 32000-2：2020 [ISOPDF2]に従ってドキュメントタイムスタンプに追加する必要があります。
The document timestamp contains an [RFC3161] timestamp token (TSTInfo) in EncapsulatedContentInfo of the CMS signature. The SVT MUST be added to the timestamp token (TSTInfo) as an Extension object as defined in Appendix B.1.1.
ドキュメントタイムスタンプには、CMS署名のcapsulatedContentInfoの[RFC3161]タイムスタンプトークン（TSTINFO）が含まれています。付録B.1.1で定義されているように、拡張オブジェクトとして、SVTをタイムスタンプトークン（TSTINFO）に追加する必要があります。
The SVT extension is an Extension suitable to be included in TSTInfo as defined by [RFC3161].
SVT拡張は、[RFC3161]で定義されているように、TSTINFOに含まれるのに適した拡張機能です。
The SVT extension is identified by the Object Identifier (OID) 1.2.752.201.5.2.
SVT拡張は、オブジェクト識別子（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.
この拡張データ（Octet String）は、UTF-8エンコード文字列として表されるSVT JWTのバイトを保持します。
This extension MUST NOT be marked critical.
この拡張機能は重要ではないとマークする必要はありません。
Note: Extensions in timestamp tokens according to [RFC3161] are imported from the definition of the X.509 certificate extensions defined in [RFC5280].
注：[RFC3161]によるタイムスタンプトークンの拡張は、[RFC5280]で定義されたX.509証明書拡張機能の定義からインポートされます。
When this profile is used, the SigValidation object MUST contain a "profile" claim with the value "PDF".
このプロファイルを使用する場合、sigvalidationオブジェクトには、値「PDF」の「プロファイル」クレームを含める必要があります。
The SVT Signature object MUST contain a "sig_ref" claim (SigReference object) with the following elements:
SVT署名オブジェクトには、次の要素を持つ「Sig_ref」クレーム（Sigreferenceオブジェクト）が含まれている必要があります。
"id": Absent or a Null value.
「ID」：不在またはヌル値。
"sig_hash": The hash over the signature value bytes.
「Sig_Hash」：署名値のバイトに対するハッシュ。
"sb_hash": The hash over the DER-encoded SignedAttributes in SignerInfo.
「SB_HASH」：SignerInfoのDer-Encoded Signedattributesのハッシュ。
The SVT Signature object MUST contain one instance of the "sig_data" claim (SignedData object) with the following elements:
SVT署名オブジェクトには、次の要素を含む「Sig_Data」クレーム（SignedDataオブジェクト）の1つのインスタンスを含める必要があります。
"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.
「Ref」：ターゲット署名のPDF署名辞書のバイテンジ値の文字列表現。これは、各整数ペアがバイト範囲の開始インデックスと長さを指定する空間で区切られた整数のシーケンスです。
"hash": The hash of all bytes identified by the ByteRange value. This is the concatenation of all byte ranges identified by the ByteRange value.
「ハッシュ」：バイテンジ値によって識別されるすべてのバイトのハッシュ。これは、バイテンジ値によって識別されるすべてのバイト範囲の連結です。
The SVT Signature object MUST contain a "signer_cert_ref" claim (CertReference object). The "type" parameter of the "signer_cert_ref" claim MUST be either "chain" or "chain_hash".
SVT署名オブジェクトには、「Signer_Cert_Ref」クレーム（certreferenceオブジェクト）が含まれている必要があります。「signer_cert_ref」クレームの「タイプ」パラメーターは、「チェーン」または「chain_hash」のいずれかでなければなりません。
* The "chain" type MUST be used when signature validation was performed using one or more certificates where some or all of the certificates in the chain are not present in the target signature.
* 「チェーン」タイプは、標的署名にチェーン内の証明書の一部またはすべてが存在しない1つ以上の証明書を使用して署名検証を実行した場合に使用する必要があります。
* The "chain_hash" type MUST be used when signature validation was performed using one or more certificates where all of the certificates are present in the target signature.
* 署名検証がターゲット署名にすべての証明書が存在する1つ以上の証明書を使用して署名検証が実行された場合、「chain_hash」タイプを使用する必要があります。
Note: The referenced signer certificate MUST match any certificates referenced using ESSCertID or ESSCertIDv2 from [RFC5035].
注：参照される署名者証明書は、[RFC5035]のEsscertIDまたはEsscertIDV2を使用して参照されている証明書と一致する必要があります。
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:
SVTホセヘッダーは、SVTの署名を検証するために使用される公開キーへの参照を保存するために、[RFC7515]に従って次のヘッダーパラメーターのいずれかを含める必要があります。
"x5c": Holds an X.509 certificate [RFC5280] or a chain of certificates. The certificate holding the public key that verifies the signature on the SVT MUST be the first certificate in the chain.
「X5C」：X.509証明書[RFC5280]または一連の証明書を保持します。SVTの署名を検証する公開キーを保持している証明書は、チェーン内の最初の証明書でなければなりません。
"kid": A key identifier holding the Base64-encoded hash value of the certificate that can verify the signature on the SVT. The hash algorithm MUST be the same hash algorithm used when signing the SVT as specified by the "alg" Header Parameter. The referenced certificate SHOULD be the same certificate that was used to sign the document timestamp that contains the SVT.
「KID」：SVTの署名を確認できる証明書のbase64エンコードのハッシュ値を保持しているキー識別子。ハッシュアルゴリズムは、「アルグ」ヘッダーパラメーターで指定されているようにSVTに署名するときに使用されるハッシュアルゴリズムと同じでなければなりません。参照されている証明書は、SVTを含むドキュメントタイムスタンプに署名するために使用された同じ証明書である必要があります。
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:
この付録は、[RFC7515]に従ってJWS署名されたペイロードを使用してSVTを実装するためのプロファイルを定義し、SVT使用法の次の側面を定義します。
* How to include reference data related to JWS signatures in an SVT.
* SVTのJWS署名に関連する参照データを含める方法。
* How to add an SVT token to JWS signatures.
* SVTトークンをJWS署名に追加する方法。
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).
JWSには、シリアル化形式に応じて1つ以上の署名があり、同じペイロードデータに署名する場合があります。JWSには、署名するデータ（包み込み）に含まれるか、外部に関連するペイロードデータ（デタッチ）に署名する場合があります。
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.
JWSにジェネリックソリューションを提供するために、SVTがJWSの保護されていないヘッダーとして各署名に追加されます。JWSに複数の署名が含まれている場合、各署名には独自のSVTが含まれます。
An SVT token MAY be added to any signature of a JWS to support validation of that signature. If more than one signature is present, then each present SVT MUST provide information exclusively related to one associated signature and MUST NOT include information about any other signature in the JWS.
SVTトークンをJWSの署名に追加して、その署名の検証をサポートすることができます。複数の署名が存在する場合、現在の各SVTは、1つの関連する署名のみに関連する情報を提供する必要があり、JWSの他の署名に関する情報を含めてはなりません。
Each SVT is stored in its associated signature's "svt" header as defined in Appendix C.1.1.
各SVTは、付録C.1.1で定義されているように、関連する署名の「SVT」ヘッダーに保存されます。
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.
「SVT」（署名検証トークン）ヘッダーパラメーターは、関連する署名の検証をサポートするために、一連のSVTトークンを含むために使用されます。配列内の各SVTトークンには、[RFC7519]で定義されているJWTの形式があり、さらにラッピングやエンコードなしで自然な文字列表現を使用して保存されます。
The "svt" Header Parameter, when used, MUST be included as a JWS Unprotected Header.
「SVT」ヘッダーパラメーターは、使用する場合は、JWSの保護されていないヘッダーとして含める必要があります。
Note: A JWS Unprotected Header is not supported with JWS Compact Serialization. A consequence of adding an SVT token to a JWS is therefore that JWS JSON Serialization MUST be used either in the form of general JWS JSON Serialization (for one or more signatures) or in the form of flattened JWS JSON Serialization (optionally used when only one signature is present in the JWS).
注：JWSコンパクトシリアル化では、JWSの保護されていないヘッダーはサポートされていません。したがって、SVTトークンをJWSに追加した結果、JWS JSONシリアル化は、一般的なJWS JSONシリアル化（1つ以上のシグネチャ用）の形式またはフラット化されたJWS JSONシリアル化の形で使用する必要があります（オプションで1つだけの場合に使用されます。署名はJWSに存在します）。
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.
新しいSVTが以前に発行されたSVTを既に含む署名に保存されている場合、実装は既存のSVTを交換するか、既存のSVTに加えて新しいSVTを保存するために選択できます。
If a JWS signature already contains an array of SVTs and a new SVT is to be added, then the new SVT MUST be added to the array of SVT tokens in the existing "svt" Header Parameter.
JWS署名が既にSVTの配列を含み、新しいSVTを追加する場合、既存の「SVT」ヘッダーパラメーターのSVTトークンの配列に新しいSVTを追加する必要があります。
When this profile is used, the SigValidation object MUST contain a "profile" claim with the value "JWS".
このプロファイルを使用する場合、sigvalidationオブジェクトには、値「JWS」の「プロファイル」クレームを含める必要があります。
The SVT Signature object MUST contain a "sig_ref" claim (SigReference object) with the following elements:
SVT署名オブジェクトには、次の要素を持つ「Sig_ref」クレーム（Sigreferenceオブジェクト）が含まれている必要があります。
"sig_hash": The hash over the associated signature value (the bytes of the base64url-decoded signature parameter).
「SIG_HASH」：関連する署名値（Base64URL-DECODED署名パラメーターのバイト）のハッシュ。
"sb_hash": The hash over all bytes signed by the associated signature (the JWS Signing Input according to [RFC7515]).
「SB_HASH」：関連する署名によって署名されたすべてのバイトのハッシュ（[RFC7515]に従ってJWS署名入力）。
The SVT Signature object MUST contain one instance of the "sig_data" claim (SignedData object) with the following elements:
SVT署名オブジェクトには、次の要素を含む「Sig_Data」クレーム（SignedDataオブジェクト）の1つのインスタンスを含める必要があります。
"ref": This parameter MUST hold one of the following three possible values:
「REF」：このパラメーターは、次の3つの可能な値のいずれかを保持する必要があります。
1. The explicit string value "payload" if the signed JWS Payload is embedded in a "payload" member of the JWS.
1. 署名されたJWSペイロードがJWSの「ペイロード」メンバーに埋め込まれている場合、明示的な文字列値「ペイロード」。
2. The explicit string value "detached" if the JWS signs detached payload data without explicit reference.
2. JWSが明示的な参照なしにペイロードデータを分離した場合、明示的な文字列値は「分離」されます。
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.
3. 分離された署名されたデータを識別またはフェッチするために使用できるURI。分離された署名されたデータのURIを決定する手段は、この仕様の範囲外です。
"hash": The hash over the JWS Payload data bytes (not its base64url-encoded string representation).
「ハッシュ」：JWSペイロードデータバイトのハッシュ（Base64urlエンコード文字列表現ではありません）。
The SVT Signature object MUST contain a "signer_cert_ref" claim (CertReference object). The "type" parameter of the "signer_cert_ref" claim MUST be either "chain" or "chain_hash".
SVT署名オブジェクトには、「Signer_Cert_Ref」クレーム（certreferenceオブジェクト）が含まれている必要があります。「signer_cert_ref」クレームの「タイプ」パラメーターは、「チェーン」または「chain_hash」のいずれかでなければなりません。
* The "chain" type MUST be used when signature validation was performed using one or more certificates where some or all of the certificates in the chain are not present in the target signature.
* 「チェーン」タイプは、標的署名にチェーン内の証明書の一部またはすべてが存在しない1つ以上の証明書を使用して署名検証を実行した場合に使用する必要があります。
* The "chain_hash" type MUST be used when signature validation was performed using one or more certificates where all of the certificates are present in the target signature JOSE header using the "x5c" Header Parameter.
* 「x5c」ヘッダーパラメーターを使用してターゲット署名ホセヘッダーにすべての証明書が存在する1つ以上の証明書を使用して署名検証を実行した場合、「chain_hash」タイプを使用する必要があります。
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:
SVTホセヘッダーは、SVTの署名を検証するために使用される公開キーへの参照を保存するために、[RFC7515]に従って次のヘッダーパラメーターのいずれかを含める必要があります。
"x5c": Holds an X.509 certificate [RFC5280] or a chain of certificates. The certificate holding the public key that verifies the signature on the SVT MUST be the first certificate in the chain.
「X5C」：X.509証明書[RFC5280]または一連の証明書を保持します。SVTの署名を検証する公開キーを保持している証明書は、チェーン内の最初の証明書でなければなりません。
"kid": A key identifier holding the Base64-encoded hash value of the certificate that can verify the signature on the SVT. The hash algorithm MUST be the same hash algorithm used when signing the SVT as specified by the "alg" Header Parameter.
「KID」：SVTの署名を確認できる証明書のbase64エンコードのハッシュ値を保持しているキー識別子。ハッシュアルゴリズムは、「アルグ」ヘッダーパラメーターで指定されているようにSVTに署名するときに使用されるハッシュアルゴリズムと同じでなければなりません。
The following informative CDDL [RFC8610] expresses the structure of an SVT token:
次の有益なCDDL [RFC8610]は、SVTトークンの構造を表しています。
svt = {
jti: text
iss: text
iat: uint
? aud: text / [* text]
? exp: uint
sig_val_claims: SigValClaims
}
SigValClaims = {
ver: text
profile: text
hash_algo: text
sig: [+ Signature]
? ext: Extension
}
Signature = {
sig_ref: SigReference
sig_data_ref: [+ SignedDataReference]
signer_cert_ref: CertReference
sig_val: [+ PolicyValidation]
? time_val: [* TimeValidation]
? ext: Extension
}
SigReference = {
? id: text / null
sig_hash: binary-value
sb_hash: binary-value
}
SignedDataReference = {
ref: text
hash: binary-value
}
CertReference = {
type: "chain" / "chain_hash"
ref: [+ text]
}
PolicyValidation = {
pol: text
res: "PASSED" / "FAILED" / "INDETERMINATE"
? msg: text / null
? ext: Extension
}
TimeValidation = {
"time": uint
type: text
iss: text
? id: text / null
? hash: binary-value / null
? val: [* PolicyValidation]
? ext: Extension
}
Extension = {
+ text => text
} / null
binary-value = text ; base64 classic with padding
binary-value = text;パディング付きBase64クラシック
The following informative JSON schema describes the syntax of the SVT token payload.
以下の有益なJSONスキーマは、SVTトークンペイロードの構文を説明しています。
{
"$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"
}
}
}
}
The following example illustrates a basic SVT according to this specification issued for a signed PDF document.
次の例は、署名されたPDFドキュメントのために発行されたこの仕様に従って、基本的なSVTを示しています。
Note: Line breaks in the decoded example are inserted for readability. Line breaks are not allowed in valid JSON data.
注：デコードされた例のラインブレークは、読みやすくするために挿入されます。有効なJSONデータでは、ラインブレークは許可されていません。
Signature validation token JWT:
署名検証トークンJWT：
eyJraWQiOiJPZW5JKzQzNEpoYnZmRG50ZlZcLzhyT3hHN0ZrdnlqYUtWSmFWcUlG QlhvaFZoQWU1Zks4YW5vdjFTNjg4cjdLYmFsK2Z2cGFIMWo4aWJnNTJRQnkxUFE9 PSIsInR5cCI6IkpXVCIsImFsZyI6IlJTNTEyIn0.eyJhdWQiOiJodHRwOlwvXC9l eGFtcGxlLmNvbVwvYXVkaWVuY2UxIiwiaXNzIjoiaHR0cHM6XC9cL3N3ZWRlbmNv bm5lY3Quc2VcL3ZhbGlkYXRvciIsImlhdCI6MTYwMzQ1ODQyMSwianRpIjoiNGQx Mzk2ZjFmZjcyOGY0MGQ1MjQwM2I2MWM1NzQ0ODYiLCJzaWdfdmFsX2NsYWltcyI6 eyJzaWciOlt7ImV4dCI6bnVsbCwic2lnX3ZhbCI6W3sibXNnIjoiT0siLCJleHQi Om51bGwsInJlcyI6IlBBU1NFRCIsInBvbCI6Imh0dHA6XC9cL2lkLnN3ZWRlbmNv bm5lY3Quc2VcL3N2dFwvc2lndmFsLXBvbGljeVwvdHMtcGtpeFwvMDEifV0sInNp Z19yZWYiOnsic2lnX2hhc2giOiJ5Y2VQVkxJemRjcEs5N0lZT2hGSWYxbnk3OUht SUNiU1Z6SWVaTmJpem83ckdJd0hOTjB6WElTeUtHakN2bm9uT2FRR2ZMXC9QM3ZE dEI4OHlLU1dlWGc9PSIsImlkIjoiaWQtNzM5ODljNmZjMDYzNjM2YWI1ZTc1M2Yx MGY3NTc0NjciLCJzYl9oYXNoIjoiQm9QVjRXQ0E5c0FJYWhqSzFIYWpmRnhpK0F6 QzRKR1R1ZjM5VzNaV2pjekRDVVJ4ZGM5WWV0ZUh0Y3hHVmVnZ3B4SEo3NVwvY1E3 SE4xZERkbGl5SXdnPT0ifSwic2lnbmVyX2NlcnRfcmVmIjp7InJlZiI6WyIxK2Fh SmV0ZzdyZWxFUmxVRFlFaVU0WklaaFQ0UlV2aUlRWnVLN28xR0ZLYVRQUTZ5K2t4 XC9QTnREcnB1cVE2WGZya0g5d1lESzRleTB5NFdyTkVybnc9PSIsImg0UER4YjVa S214MWVUU3F2VnZZRzhnMzNzMDVKendCK05nRUhGVTRnYzl0cUcwa2dIa2Y2VzNv THprVHd3dXJJaDZZOUFhZlpZcWMyelAycEUycDRRPT0iLCJEZDJDNXNCMElPUWVN Vm5FQmtNNVE5Vzk2bUJITnd3YTJ0elhNcytMd3VZY09VdlBrcnlHUjBhUEc4Tzlu SVAzbGJ3NktqUTFoRG1SazZ6Qzh4MmpkZz09Il0sInR5cGUiOiJjaGFpbl9oYXNo In0sInNpZ19kYXRhX3JlZiI6W3sicmVmIjoiIiwiaGFzaCI6IkZjR3BPT2Y4aWxj UHQyMUdEZDJjR25MR0R4UlM1ajdzdk00YXBwMkg0MWRERUxtMkN6Y2VUWTAybmRl SmZXamludG1RMzc2SWxYVE9BcjMxeXpZenNnPT0ifSx7InJlZiI6IiN4YWRlcy0x MWExNTVkOTJiZjU1Nzc0NjEzYmI3YjY2MTQ3N2NmZCIsImhhc2giOiJLUmtnYlo2 UFwvbmhVNjNJTWswR2lVZlVcL0RUd3ZlWWl0ZVFrd0dlSnFDNUJ6VE5WOGJRYnBl ZFRUdVdKUHhxdkowUlk4NGh3bTdlWVwvZzBIckFPZWdLdz09In1dLCJ0aW1lX3Zh bCI6W119XSwiZXh0IjpudWxsLCJ2ZXIiOiIxLjAiLCJwcm9maWxlIjoiWE1MIiwi aGFzaF9hbGdvIjoiaHR0cDpcL1wvd3d3LnczLm9yZ1wvMjAwMVwvMDRcL3htbGVu YyNzaGE1MTIifX0.TdHCoIUSZj2zMINKg7E44-8VE_mJq6TG1OoPwnYSs_hyUbuX mrLJpuk8GR5YrndeOucPUYAwPxHt_f68JIQyFTi0agO9VJjn1R7Pj3Jt6WG9pYVN n5LH-D1maxD11ZxxbcYeHbsstd2Sy2uMa3BdpsstGdPymSmc6GxY5uJoL0-5vwo_ 3l-4Bb3LCTiuxYPcmztKIbDy2hEgJ3Hx1K4HF0SHgn3InpqBev3hm2SLw3hH5BCM rywBAhHYE6OGE0aOJ6ktA5UP0jIIHfaw9i1wIiJtHTaGuvtyWSLk5cshmun9Hkdk kRTA75bzuq0Iyd0qh070rA8Gje-s4Tw4xzttgKx1KSkvy8n5FqvzWdsZvclCG2mY Y9rMxh_7607NXcxajAP4yDOoKNs5nm937ULe0vCN8a7WTrFuiaGjry7HhzRM4C5A qxbDOBXPLyoMr4qn4LRJCHxOeLZ6o3ugvDOOWsyjk3eliyBwDu8qJH7UmyicLxDc Cr0hUK_kvREqjD2Z
eyJraWQiOiJPZW5JKzQzNEpoYnZmRG50ZlZcLzhyT3hHN0ZrdnlqYUtWSmFWcUlG QlhvaFZoQWU1Zks4YW5vdjFTNjg4cjdLYmFsK2Z2cGFIMWo4aWJnNTJRQnkxUFE9 PSIsInR5cCI6IkpXVCIsImFsZyI6IlJTNTEyIn0.eyJhdWQiOiJodHRwOlwvXC9l eGFtcGxlLmNvbVwvYXVkaWVuY2UxIiwiaXNzIjoiaHR0cHM6XC9cL3N3ZWRlbmNv bm5lY3Quc2VcL3ZhbGlkYXRvciIsImlhdCI6MTYwMzQ1ODQyMSwianRpIjoiNGQx Mzk2ZjFmZjcyOGY0MGQ1MjQwM2I2MWM1NzQ0ODYiLCJzaWdfdmFsX2NsYWltcyI6 eyJzaWciOlt7ImV4dCI6bnVsbCwic2lnX3ZhbCI6W3sibXNnIjoiT0siLCJleHQi Om51bGwsInJlcyI6IlBBU1NFRCIsInBvbCI6Imh0dHA6XC9cL2lkLnN3ZWRlbmNv bm5lY3Quc2VcL3N2dFwvc2lndmFsLXBvbGljeVwvdHMtcGtpeFwvMDEifV0sInNp Z19yZWYiOnsic2lnX2hhc2giOiJ5Y2VQVkxJemRjcEs5N0lZT2hGSWYxbnk3OUht SUNiU1Z6SWVaTmJpem83ckdJd0hOTjB6WElTeUtHakN2bm9uT2FRR2ZMXC9QM3ZE dEI4OHlLU1dlWGc9PSIsImlkIjoiaWQtNzM5ODljNmZjMDYzNjM2YWI1ZTc1M2Yx MGY3NTc0NjciLCJzYl9oYXNoIjoiQm9QVjRXQ0E5c0FJYWhqSzFIYWpmRnhpK0F6 QzRKR1R1ZjM5VzNaV2pjekRDVVJ4ZGM5WWV0ZUh0Y3hHVmVnZ3B4SEo3NVwvY1E3 SE4xZERkbGl5SXdnPT0ifSwic2lnbmVyX2NlcnRfcmVmIjp7InJlZiI6WyIxK2Fh SmV0ZzdyZWxFUmxVRFlFaVU0W klaaFQ0UlV2aUlRWnVLN28xR0ZLYVRQUTZ5K2t4 XC9QTnREcnB1cVE2WGZya0g5d1lESzRleTB5NFdyTkVybnc9PSIsImg0UER4YjVa S214MWVUU3F2VnZZRzhnMzNzMDVKendCK05nRUhGVTRnYzl0cUcwa2dIa2Y2VzNv THprVHd3dXJJaDZZOUFhZlpZcWMyelAycEUycDRRPT0iLCJEZDJDNXNCMElPUWVN Vm5FQmtNNVE5Vzk2bUJITnd3YTJ0elhNcytMd3VZY09VdlBrcnlHUjBhUEc4Tzlu SVAzbGJ3NktqUTFoRG1SazZ6Qzh4MmpkZz09Il0sInR5cGUiOiJjaGFpbl9oYXNo In0sInNpZ19kYXRhX3JlZiI6W3sicmVmIjoiIiwiaGFzaCI6IkZjR3BPT2Y4aWxj UHQyMUdEZDJjR25MR0R4UlM1ajdzdk00YXBwMkg0MWRERUxtMkN6Y2VUWTAybmRl SmZXamludG1RMzc2SWxYVE9BcjMxeXpZenNnPT0ifSx7InJlZiI6IiN4YWRlcy0x MWExNTVkOTJiZjU1Nzc0NjEzYmI3YjY2MTQ3N2NmZCIsImhhc2giOiJLUmtnYlo2 UFwvbmhVNjNJTWswR2lVZlVcL0RUd3ZlWWl0ZVFrd0dlSnFDNUJ6VE5WOGJRYnBl ZFRUdVdKUHhxdkowUlk4NGh3bTdlWVwvZzBIckFPZWdLdz09In1dLCJ0aW1lX3Zh bCI6W119XSwiZXh0IjpudWxsLCJ2ZXIiOiIxLjAiLCJwcm9maWxlIjoiWE1MIiwi aGFzaF9hbGdvIjoiaHR0cDpcL1wvd3d3LnczLm9yZ1wvMjAwMVwvMDRcL3htbGVu YyNzaGE1MTIifX0.TdHCoIUSZj2zMINKg7E44-8VE_mJq6TG1OoPwnYSs_hyUbuX mrLJpuk8GR5YrndeOucPUYAwPxHt_f68JIQyFTi0agO9VJjn1R 7Pj3Jt6WG9pYVN n5LH-D1maxD11ZxxbcYeHbsstd2Sy2uMa3BdpsstGdPymSmc6GxY5uJoL0-5vwo_ 3l-4Bb3LCTiuxYPcmztKIbDy2hEgJ3Hx1K4HF0SHgn3InpqBev3hm2SLw3hH5BCM rywBAhHYE6OGE0aOJ6ktA5UP0jIIHfaw9i1wIiJtHTaGuvtyWSLk5cshmun9Hkdk kRTA75bzuq0Iyd0qh070rA8Gje-s4Tw4xzttgKx1KSkvy8n5FqvzWdsZvclCG2mY Y9rMxh_7607NXcxajAP4yDOoKNs5nm937ULe0vCN8a7WTrFuiaGjry7HhzRM4C5A qxbDOBXPLyoMr4qn4LRJCHxOeLZ6o3ugvDOOWsyjk3eliyBwDu8qJH7UmyicLxDc Cr0hUK_kvREqjD2Z
Decoded JWT Header:
デコードされたJWTヘッダー：
{
"kid":"OenI+434JhbvfDntfV\/8rOxG7FkvyjaKVJaVqIFBXohVhAe5fK8anov
1S688r7Kbal+fvpaH1j8ibg52QBy1PQ==",
"typ":"JWT",
"alg":"RS512"
}
Decoded JWT Claims:
解読されたJWTの主張：
{
"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 70 Lund Sweden Email: sts@aaa-sec.com
Stefan Santesson Idsec Solutions AB Forskningsbyn IDEON SE-223 70 Lund Sweden Email：sts@aaa-sec.com
Russ Housley Vigil Security, LLC 516 Dranesville Road Herndon, VA 20170 United States of America Email: housley@vigilsec.com
Russ Housley Vigil Security、LLC 516 Dranesville Road Herndon、バージニア州20170アメリカ合衆国電子メール：housley@vigilsec.com