[要約] RFC 9399 は、公開鍵証明書や属性証明書にロゴタイプを含めるための拡張機能を定義しています。目的は、RFC 3709 と RFC 6170 を廃止し、新しい標準を提供することです。
Internet Engineering Task Force (IETF) S. Santesson
Request for Comments: 9399 IDsec Solutions
Obsoletes: 3709, 6170 R. Housley
Category: Standards Track Vigil Security
ISSN: 2070-1721 T. Freeman
Amazon Web Services
L. Rosenthol
Adobe
May 2023
This document specifies a certificate extension for including logotypes in public key certificates and attribute certificates. This document obsoletes RFCs 3709 and 6170.
このドキュメントは、公開キーの証明書と属性証明書にロゴタイプを含めるための証明書拡張機能を指定します。このドキュメントは、RFCS 3709および6170を廃止します。
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、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/rfc9399.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9399で取得できます。
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2023 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. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
1.1. Certificate-Based Identification
1.2. Selection of Certificates
1.3. Combination of Verification Techniques
1.4. Requirements Language
2. Different Types of Logotypes in Certificates
3. Logotype Data
4. Logotype Certificate Extension
4.1. Extension Format
4.2. Conventions for LogotypeImageInfo
4.3. Embedded Images
4.4. Other Logotypes
4.4.1. Loyalty Logotype
4.4.2. Certificate Background Logotype
4.4.3. Certificate Image Logotype
5. Type of Certificates
6. Use in Clients
7. Image Formats
8. Audio Formats
9. Security Considerations
10. Privacy Considerations
11. IANA Considerations
12. References
12.1. Normative References
12.2. Informative References
Appendix A. ASN.1 Modules
A.1. ASN.1 Modules with 1988 Syntax
A.2. ASN.1 Module with 2002 Syntax
Appendix B. Examples
B.1. Example from RFC 3709
B.2. Issuer Organization Logotype Example
B.3. Embedded Image Example
B.4. Embedded Certificate Image Example
B.5. Full Certificate Example
Appendix C. Changes since RFCs 3709 and 6170
Acknowledgments
Authors' Addresses
This specification supplements [RFC5280], which profiles public key certificates and certificate revocation lists (CRLs) for use in the Internet, and it supplements [RFC5755], which profiles attribute certificates for use in the Internet.
この仕様は、インターネットで使用する公開キー証明書と証明書の取り消しリスト（CRL）をプロファイルする[RFC5280]をサプリメントし、インターネットで使用する証明書をプロファイルするプロファイルを補完します[RFC5755]。
This document obsoletes [RFC3709] and [RFC6170]. Appendix C provides a summary of the changes since the publication of [RFC3709] and [RFC6170].
この文書は、[RFC3709]および[RFC6170]を廃止します。付録Cは、[RFC3709]および[RFC6170]の公開以来の変更の要約を提供します。
The basic function of a certificate is to bind a public key to the identity of an entity (the subject). From a strictly technical viewpoint, this goal could be achieved by signing the identity of the subject together with its public key. However, the art of Public Key Infrastructure (PKI) has developed certificates far beyond this functionality in order to meet the needs of modern global networks and heterogeneous information and operational technology structures.
証明書の基本機能は、公開鍵をエンティティ（主題）のIDに結合することです。厳密に技術的な視点から、この目標は、主題のアイデンティティをその公開鍵と一緒に署名することで達成できます。ただし、公開キーインフラストラクチャ（PKI）のArtは、最新のグローバルネットワークと異種情報および運用技術構造のニーズを満たすために、この機能をはるかに超えた証明書を開発しました。
Certificate users must be able to determine certificate policies, appropriate key usage, assurance level, and name form constraints. Before a relying party can make an informed decision whether a particular certificate is trustworthy and relevant for its intended usage, a certificate may be examined from several different perspectives.
証明書ユーザーは、証明書ポリシー、適切な主要な使用法、保証レベル、および名前の制約を決定できる必要があります。頼る当事者が、特定の証明書が意図された使用法に信頼できるかどうかに関連しているかどうかに基づいた情報に基づいた決定を下す前に、証明書をいくつかの異なる視点から検討することができます。
Systematic processing is necessary to determine whether a particular certificate meets the predefined prerequisites for an intended usage. Much of the information contained in certificates is appropriate and effective for machine processing; however, this information is not suitable for a corresponding human trust and recognition process.
特定の証明書が意図した使用法の事前定義された前提条件を満たすかどうかを判断するために、体系的な処理が必要です。証明書に含まれる情報の多くは、機械処理に適切かつ効果的です。ただし、この情報は、対応する人間の信頼と認識プロセスには適していません。
Humans prefer to structure information into categories and symbols. Most humans associate complex structures of reality with easily recognizable logotypes and marks. Humans tend to trust things that they recognize from previous experiences. Humans may examine information to confirm their initial reaction. Very few consumers actually read all terms and conditions they agree to in accepting a service; instead, they commonly act on trust derived from previous experience and recognition.
人間は、情報をカテゴリとシンボルに構築することを好みます。ほとんどの人間は、現実の複雑な構造を簡単に認識できるロゴタイプとマークと関連付けています。人間は、以前の経験から認識していることを信頼する傾向があります。人間は情報を調べて最初の反応を確認することができます。実際に、サービスを受け入れる際に同意するすべての条件を実際に読む消費者はほとんどいません。代わりに、彼らは一般的に以前の経験と認識から派生した信頼に基づいて行動します。
A big part of this process is branding. Service providers and product vendors invest a lot of money and resources into creating a strong relation between positive user experiences and easily recognizable trademarks, servicemarks, and logotypes.
このプロセスの大部分はブランディングです。サービスプロバイダーと製品ベンダーは、多くのお金とリソースを投資して、ポジティブなユーザーエクスペリエンスと簡単に認識できる商標、サービスマーク、ロゴタイプとの強い関係を生み出します。
Branding is also pervasive in identification instruments, including identification cards, passports, driver's licenses, credit cards, gasoline cards, and loyalty cards. Identification instruments are intended to identify the holder as a particular person or as a member of the community. The community may represent the subscribers of a service or any other group. Identification instruments, in physical form, commonly use logotypes and symbols, solely to enhance human recognition and trust in the identification instrument itself. They may also include a registered trademark to allow legal recourse for unauthorized duplication.
ブランディングは、身分証明書、パスポート、ドライバーズライセンス、クレジットカード、ガソリンカード、ロイヤルティカードなど、身分証明書にも普及しています。識別機器は、所有者を特定の人として、またはコミュニティのメンバーとして識別することを目的としています。コミュニティは、サービスまたは他のグループの加入者を代表する場合があります。識別機器は、物理的な形で、一般的にロゴタイプと記号を使用して、識別器自体に対する人間の認識と信頼を高めるためだけに使用します。また、不正な重複の法的手段を許可するために、登録商標を含めることもできます。
Since certificates play an equivalent role in electronic exchanges, we examine the inclusion of logotypes in certificates. We consider certificate-based identification and certificate selection.
証明書は電子交換で同等の役割を果たすため、証明書にロゴタイプを含めることを調べます。証明書ベースの識別と証明書の選択を検討します。
The need for human recognition depends on the manner in which certificates are used and whether certificates need to be visible to human users. If certificates are to be used in open environments and in applications that bring the user in conscious contact with the result of a certificate-based identification process, then human recognition is highly relevant and may be a necessity.
人間の認識の必要性は、証明書の使用方法と、証明書を人間のユーザーに見える必要があるかどうかに依存します。証明書ベースの識別プロセスの結果とユーザーに意識的に接触するアプリケーションおよびアプリケーションで証明書が使用される場合、人間の認識は非常に関連性が高く、必要になる可能性があります。
Examples of such applications include:
そのようなアプリケーションの例は次のとおりです。
* Web server identification where a user identifies the owner of the website.
* ユーザーがWebサイトの所有者を識別するWebサーバー識別。
* Peer email exchange in business-to-business (B2B), business-to-consumer (B2C), and private communications.
* ビジネスからビジネスへのピアメール交換（B2B）、企業間消費者（B2C）、およびプライベートコミュニケーション。
* Exchange of medical records and system for medical prescriptions.
* 医療記録と医療処方のシステムの交換。
* Unstructured e-business applications (i.e., non-EDI applications).
* 非構造化されていない電子ビジネスアプリケーション（つまり、EDI以外のアプリケーション）。
* Wireless client authenticating to a service provider.
* サービスプロバイダーに認証されているワイヤレスクライアント。
Most applications provide the human user with an opportunity to view the results of a successful certificate-based identification process. When the user takes the steps necessary to view these results, the user is presented with a view of a certificate. This solution has two major problems. First, the function to view a certificate is often rather hard to find for a non-technical user. Second, the presentation of the certificate is too technical and is not user friendly. It contains no graphic symbols or logotypes to enhance human recognition.
ほとんどのアプリケーションは、人間のユーザーに、証明書ベースの識別プロセスを成功させる結果を表示する機会を提供します。ユーザーがこれらの結果を表示するために必要な手順を実行すると、ユーザーは証明書のビューを表示されます。このソリューションには2つの大きな問題があります。まず、証明書を表示する関数は、非技術的なユーザーにとって見つけるのがかなり難しいことがよくあります。第二に、証明書のプレゼンテーションは技術的すぎて、ユーザーフレンドリーではありません。人間の認識を高めるためのグラフィックシンボルやロゴタイプは含まれていません。
Many investigations have shown that users of today's applications do not take the steps necessary to view certificates. This could be due to poor user interfaces. Further, many applications are structured to hide certificates from users. The application designers do not want to expose certificates to users at all.
多くの調査により、今日のアプリケーションのユーザーは、証明書を表示するために必要な措置を講じていないことが示されています。これは、ユーザーインターフェイスの低下による可能性があります。さらに、多くのアプリケーションは、ユーザーから証明書を非表示にするために構成されています。アプリケーションデザイナーは、証明書をユーザーにまったく公開したくありません。
One situation where software applications must expose human users to certificates is when the user must select a single certificate from a portfolio of certificates. In some cases, the software application can use information within the certificates to filter the list for suitability; however, the user must be queried if more than one certificate is suitable. The human user must select one of them.
ソフトウェアアプリケーションが人間のユーザーを証明書に公開する必要がある状況の1つは、ユーザーが証明書のポートフォリオから単一の証明書を選択する必要がある場合です。場合によっては、ソフトウェアアプリケーションは証明書内の情報を使用して、適合性のためにリストをフィルタリングすることができます。ただし、複数の証明書が適切である場合、ユーザーは質問する必要があります。人間のユーザーはそのいずれかを選択する必要があります。
This situation is comparable to a person selecting a suitable plastic card from their wallet. In this situation, substantial assistance is provided by card color, location, and branding.
この状況は、財布から適切なプラスチックカードを選択する人に匹敵します。この状況では、カードの色、場所、ブランディングによって実質的な支援が提供されます。
In order to provide similar support for certificate selection, the users need tools to easily recognize and distinguish certificates. Introduction of logotypes into certificates provides the necessary graphic.
証明書の選択に同様のサポートを提供するために、ユーザーは証明書を簡単に認識して区別するためのツールを必要とします。ロゴタイプを証明書に導入すると、必要なグラフィックが提供されます。
The use of logotypes will, in many cases, affect the user's decision to trust and use a certificate. It is therefore important that there be a distinct and clear architectural and functional distinction between the processes and objectives of the automated certificate verification and human recognition.
ロゴタイプの使用は、多くの場合、証明書を信頼して使用するというユーザーの決定に影響します。したがって、自動化された証明書の検証と人間の認識のプロセスと目的の間には、明確で明確な建築的および機能的な区別があることが重要です。
Since logotypes are only aimed for human interpretation and contain data that is inappropriate for computer-based verification schemes, the logotype certificate extension MUST NOT be an active component in automated certification path validation, as specified in Section 6 of [RFC5280].
ロゴタイプは人間の解釈を目的としており、コンピューターベースの検証スキームに不適切なデータを含むため、ロゴタイプ証明書拡張は[RFC5280]のセクション6で指定されているように、自動認証パス検証のアクティブなコンポーネントであってはなりません。
Automated certification path verification determines whether the end entity certificate can be verified according to defined policy. The algorithm for this verification is specified in [RFC5280].
自動化された認証パス検証により、定義されたポリシーに従って最終エンティティ証明書を検証できるかどうかが判断されます。この検証のアルゴリズムは[RFC5280]で指定されています。
The automated processing provides assurance that the certificate is valid. It does not indicate whether the subject is entitled to any particular information or whether the subject ought to be trusted to perform a particular service. These are authorization decisions. Automatic processing will make some authorization decisions, but others, depending on the application context, involve the human user.
自動処理は、証明書が有効であるという保証を提供します。被験者が特定の情報を受ける権利があるかどうか、または被験者が特定のサービスを実行すると信頼されるべきかどうかは示されません。これらは許可決定です。自動処理はいくつかの承認決定を下しますが、その他はアプリケーションのコンテキストに応じて、人間のユーザーが関与します。
In some situations, where automated procedures have failed to establish the suitability of the certificate to the task, the human user is the final arbitrator of the post certificate verification authorization decisions. In the end, the human will decide whether or not to accept an executable email attachment, to release personal information, or to follow the instructions displayed by a web browser. This decision will often be based on recognition and previous experience.
自動化された手順がタスクに対する証明書の適合性を確立できなかった状況では、人間のユーザーは、証明書の検証承認決定の最終仲裁人です。最終的に、人間は、実行可能な電子メールの添付ファイルを受け入れるか、個人情報を公開するか、Webブラウザーによって表示される指示に従うかを決定します。この決定は、多くの場合、認識と以前の経験に基づいています。
The distinction between systematic processing and human processing is rather straightforward. They can be complementary. While the systematic process is focused on certification path construction and verification, the human acceptance process is focused on recognition and related previous experience.
系統的処理と人間の処理の区別はかなり簡単です。それらは補完的です。体系的なプロセスは認証パスの構築と検証に焦点を当てていますが、人間の受け入れプロセスは、認識と関連する以前の経験に焦点を当てています。
There are some situations where systematic processing and human processing interfere with each other. These issues are discussed in the Section 9.
体系的な処理と人間の処理が互いに干渉する状況がいくつかあります。これらの問題については、セクション9で説明します。
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 specification defines the inclusion of three standard logotype types:
この仕様は、3つの標準ロゴタイプタイプを含めることを定義しています。
* community logotype
* コミュニティロゴタイプ
* issuer organization logotype
* 発行者組織ロゴタイプ
* subject organization logotype
* サブジェクト組織ロゴタイプ
The community logotype is the general mark for a community. It identifies a service concept for entity identification and certificate issuance. Many issuers may use a community logotype to co-brand with a global community in order to gain global recognition of its local service provision. This type of community branding is very common in the credit card business, where local independent card issuers include a globally recognized brand (such as Visa and Mastercard). Certificate issuers may include more than one community logotype to indicate participation in more than one global community.
コミュニティのロゴタイプは、コミュニティの一般的なマークです。エンティティの識別と証明書の発行のためのサービス概念を識別します。多くの発行者は、コミュニティのロゴタイプを使用して、ローカルサービスの提供をグローバルに認識するために、グローバルコミュニティと共同ブランドを付けます。このタイプのコミュニティブランディングは、地元の独立したカード発行者にはグローバルに認められたブランド（VisaやMasterCardなど）が含まれるクレジットカードビジネスで非常に一般的です。証明書発行者には、複数のグローバルコミュニティへの参加を示すために、複数のコミュニティロゴタイプを含めることができます。
The issuer organization logotype is a logotype representing the organization identified as part of the issuer name in the certificate.
発行者組織のロゴタイプは、証明書の発行者名の一部として特定された組織を表すロゴタイプです。
The subject organization logotype is a logotype representing the organization identified in the subject name in the certificate.
対象組織のロゴタイプは、証明書の件名で識別された組織を表すロゴタイプです。
In addition to the standard logotype types, this specification accommodates inclusion of other logotype types where each class of logotype is defined by an object identifier. The object identifier can be either locally defined or an identifier defined in Section 4.4 of this document.
標準のロゴタイプタイプに加えて、この仕様は、ロゴタイプの各クラスがオブジェクト識別子によって定義される他のロゴタイプタイプを含めることに対応します。オブジェクト識別子は、このドキュメントのセクション4.4で定義されている識別子を定義することができます。
This specification defines two types of logotype data: image data and audio data. Implementations MUST support image data; however, support for audio data is OPTIONAL.
この仕様では、画像データとオーディオデータの2種類のロゴタイプデータを定義します。実装は画像データをサポートする必要があります。ただし、オーディオデータのサポートはオプションです。
Image and audio data for logotypes can be provided by reference by including a URI that identifies the location to the logotype data and a one-way hash of the referenced data in the certificate. The privacy-related properties for remote logotype data depend on four parties: the certificate relying parties that use the information in the certificate extension to fetch the logotype data, the certificate issuers that populate the certificate extension, certificate subscribers that request certificates that include the certificate extension, and server operators that provide the logotype data.
ロゴタイプの画像およびオーディオデータは、ロゴタイプデータの場所を識別するURIと、証明書内の参照データの一方向のハッシュを含めることにより、参照によって提供できます。リモートロゴタイプデータのプライバシー関連のプロパティは、4つの関係者に依存します。証明書拡張機能の情報を使用する証明書に依存して、ロゴタイプデータを取得します。拡張機能、およびロゴタイプデータを提供するサーバー演算子。
Alternatively, embedding the logotype data in the certificate with direct addressing (as defined in Section 4.3) provides improved privacy properties and depends upon fewer parties. However, this approach can significantly increase the size of the certificate.
あるいは、直接アドレス指定（セクション4.3で定義されている）を使用して、証明書にロゴタイプデータを埋め込むと、プライバシープロパティが改善され、より少ない当事者に依存します。ただし、このアプローチは証明書のサイズを大幅に増加させる可能性があります。
Several image objects, representing the same visual content in different formats, sizes, and color palates, may represent each logotype image. At least one of the image objects representing a logotype SHOULD contain an image with a width between 60 pixels and 200 pixels and a height between 45 pixels and 150 pixels.
さまざまな形式、サイズ、色の味覚で同じ視覚コンテンツを表すいくつかの画像オブジェクトは、各ロゴタイプの画像を表す場合があります。 ロゴタイプを表す画像オブジェクトの少なくとも1つは、幅60ピクセルから200ピクセル、高さは45ピクセルと150ピクセルの高さの画像を含める必要があります。
Several instances of audio data may further represent the same audio sequence in different formats, resolutions, and languages. At least one of the audio objects representing a logotype SHOULD provide text-based audio data suitable for processing by text-to-speech software.
オーディオデータのいくつかのインスタンスは、異なる形式、解像度、言語で同じオーディオシーケンスをさらに表す場合があります。ロゴタイプを表すオーディオオブジェクトの少なくとも1つは、テキストからスピーチソフトウェアによる処理に適したテキストベースのオーディオデータを提供する必要があります。
A typical use of text-based audio data is inclusion in web applications where the audio text is placed as the "alt" attribute value of an HTML image (img) element, and the language value obtained from LogotypeAudioInfo is included as the "lang" attribute of that image.
テキストベースのオーディオデータの典型的な使用は、オーディオテキストがHTMLイメージ（IMG）要素の「ALT」属性値として配置され、ログオタイプアウディオインフォから得られた言語値が「LANG」として含まれているWebアプリケーションに含まれています。その画像の属性。
If a logotype of a certain type (as defined in Section 2) is represented by more than one image object, then each image object MUST contain variants of roughly the same visual content. Likewise, if a logotype of a certain type is represented by more than one audio object, then the audio objects MUST contain variants of the same audio information. A spoken message in different languages is considered a variation of the same audio information. When more than one image object or more than one audio object for the same logotype type is included in the certificate, the certificate issuer is responsible for ensuring that the objects contain roughly the same content. Compliant applications MUST NOT display more than one of the image objects and MUST NOT play more than one of the audio objects for any logotype type (see Section 2) at the same time.
特定のタイプのロゴタイプ（セクション2で定義）が複数の画像オブジェクトで表される場合、各画像オブジェクトにはほぼ同じ視覚コンテンツのバリアントを含める必要があります。同様に、特定のタイプのロゴタイプが複数のオーディオオブジェクトで表されている場合、オーディオオブジェクトには同じオーディオ情報のバリアントを含める必要があります。異なる言語での音声メッセージは、同じオーディオ情報のバリエーションと見なされます。同じロゴタイプタイプの複数の画像オブジェクトまたは複数のオーディオオブジェクトが証明書に含まれている場合、証明書発行者は、オブジェクトがほぼ同じコンテンツを含むことを保証する責任があります。準拠したアプリケーションは、画像オブジェクトを複数表示してはならず、同時にロゴタイプタイプ（セクション2を参照）に対してオーディオオブジェクトを複数再生してはなりません。
A client MAY simultaneously display multiple logotypes of different logotype types. For example, it may display one subject organization logotype while also displaying a community logotype, but it MUST NOT display multiple image variants of the same community logotype.
クライアントは、異なるロゴタイプタイプの複数のロゴタイプを同時に表示できます。たとえば、コミュニティのロゴタイプも表示しながら、1つの主題組織ロゴタイプを表示する場合がありますが、同じコミュニティロゴタイプの複数の画像バリエーションを表示してはなりません。
Each logotype present in a certificate MUST be represented by at least one image data object.
証明書に存在する各ロゴタイプは、少なくとも1つの画像データオブジェクトで表す必要があります。
Client applications SHOULD enhance processing and off-line functionality by caching logotype data.
クライアントアプリケーションは、ロゴタイプデータをキャッシュすることにより、処理とオフラインの機能を強化する必要があります。
This section specifies the syntax and semantics of the logotype certificate extension.
このセクションでは、ロゴタイプ証明書拡張の構文とセマンティクスを指定します。
The logotype certificate extension MAY be included in public key certificates [RFC5280] or attribute certificates [RFC5755]. The logotype certificate extension MUST be identified by the following object identifier:
ロゴタイプ証明書拡張は、公開キー証明書[RFC5280]または属性証明書[RFC5755]に含まれる場合があります。ロゴタイプ証明書拡張機能は、次のオブジェクト識別子によって識別される必要があります。
id-pe-logotype OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-pe(1) 12 }
This extension MUST NOT be marked critical.
この拡張機能は、クリティカルとマークされてはなりません。
Logotype data may be referenced through either direct or indirect addressing. Client applications SHOULD support both direct and indirect addressing. Certificate issuing applications MUST support direct addressing, and certificate issuing applications SHOULD support indirect addressing.
ロゴタイプデータは、直接または間接的なアドレス指定を通じて参照される場合があります。クライアントアプリケーションは、直接および間接的なアドレス指定の両方をサポートする必要があります。証明書の発行申請は、直接のアドレス指定をサポートする必要があり、証明書の発行申請は間接的なアドレス指定をサポートする必要があります。
The direct addressing includes information about each logotype in the certificate, and URIs point to the image and audio data object. Multiple URIs MAY be included for locations for obtaining the same logotype object. Multiple hash values MAY be included, each computed with a different one-way hash function. Direct addressing supports cases where just one or a few alternative images and audio objects are referenced.
直接のアドレス指定には、証明書の各ロゴタイプに関する情報が含まれており、URISは画像とオーディオデータオブジェクトを指しています。同じロゴタイプオブジェクトを取得するための場所には、複数のURIが含まれる場合があります。複数のハッシュ値が含まれ、それぞれが異なる一方向ハッシュ関数で計算されます。直接アドレス指定は、1つまたはいくつかの代替画像とオーディオオブジェクトが参照される場合をサポートします。
The indirect addressing includes one or more references to an external hashed data structure that contains information on the type, content, and location of each image and audio object. Indirect addressing supports cases where each logotype is represented by many alternative audio or image objects.
間接的なアドレス指定には、各画像とオーディオオブジェクトのタイプ、コンテンツ、および場所に関する情報を含む外部ハッシュされたデータ構造への1つ以上の参照が含まれます。間接的なアドレス指定は、各ロゴタイプが多くの代替オーディオまたは画像オブジェクトで表されるケースをサポートします。
Both direct and indirect addressing accommodate alternative URIs to obtain exactly the same logotype data. This opportunity for replication is intended to improve availability. Therefore, if a client is unable to fetch the item from one URI, the client SHOULD try another URI in the sequence. All direct addressing URIs SHOULD use the HTTPS scheme (https://...), the HTTP scheme (http://...), or the DATA scheme (data://...) [RFC3986]. However, the "data" URI scheme MUST NOT be used with the indirect addressing. Clients MUST support retrieval of the referenced LogotypeData with HTTP [RFC9110], HTTP with TLS [RFC8446], or subsequent versions of these protocols. Client applications SHOULD also support the "data" URI scheme [RFC2397] for direct addressing with embedded logotype data within the extension.
直接的および間接的なアドレス指定は、まったく同じロゴタイプデータを取得するための代替URIに対応します。この複製の機会は、可用性を改善することを目的としています。したがって、クライアントが1つのURIからアイテムを取得できない場合、クライアントはシーケンスで別のURIを試す必要があります。すべての直接アドレス指定URIは、HTTPSスキーム（https：// ...）、httpスキーム（http：// ...）、またはデータスキーム（data：// ...）[rfc3986]を使用する必要があります。ただし、「データ」URIスキームは、間接的なアドレス指定で使用してはなりません。クライアントは、HTTP [RFC9110]、TLS [RFC8446]を使用したHTTP、またはこれらのプロトコルの後続のバージョンで参照されたLogotypeDataの取得をサポートする必要があります。クライアントアプリケーションは、拡張機能内に埋め込まれたロゴタイプデータを使用して直接アドレス指定するために、「データ」URIスキーム[RFC2397]をサポートする必要があります。
Note that the HTTPS scheme (https://...) requires the validation of other certificates to establish a secure connection. For this reason, the HTTP scheme (http://...) may be easier for a client to handle. Also, the hash of the logotype data provides data integrity.
HTTPSスキーム（https：// ...）には、安全な接続を確立するために他の証明書の検証が必要であることに注意してください。このため、HTTPスキーム（http：// ...）は、クライアントが処理しやすい場合があります。また、ロゴタイプデータのハッシュはデータの整合性を提供します。
The logotype certificate extension MUST have the following syntax:
ロゴタイプ証明書拡張には、次の構文が必要です。
LogotypeExtn ::= SEQUENCE {
communityLogos [0] EXPLICIT SEQUENCE OF LogotypeInfo OPTIONAL,
issuerLogo [1] EXPLICIT LogotypeInfo OPTIONAL,
subjectLogo [2] EXPLICIT LogotypeInfo OPTIONAL,
otherLogos [3] EXPLICIT SEQUENCE OF OtherLogotypeInfo
OPTIONAL }
LogotypeInfo ::= CHOICE {
direct [0] LogotypeData,
indirect [1] LogotypeReference }
LogotypeData ::= SEQUENCE {
image SEQUENCE OF LogotypeImage OPTIONAL,
audio [1] SEQUENCE OF LogotypeAudio OPTIONAL }
LogotypeImage ::= SEQUENCE {
imageDetails LogotypeDetails,
imageInfo LogotypeImageInfo OPTIONAL }
LogotypeAudio ::= SEQUENCE {
audioDetails LogotypeDetails,
audioInfo LogotypeAudioInfo OPTIONAL }
LogotypeDetails ::= SEQUENCE {
mediaType IA5String, -- Media type name and optional
-- parameters
logotypeHash SEQUENCE SIZE (1..MAX) OF HashAlgAndValue,
logotypeURI SEQUENCE SIZE (1..MAX) OF IA5String }
LogotypeImageInfo ::= SEQUENCE {
type [0] LogotypeImageType DEFAULT color,
fileSize INTEGER, -- In octets, 0=unspecified
xSize INTEGER, -- Horizontal size in pixels
ySize INTEGER, -- Vertical size in pixels
resolution LogotypeImageResolution OPTIONAL,
language [4] IA5String OPTIONAL } -- RFC 5646 Language Tag
LogotypeImageType ::= INTEGER { grayScale(0), color(1) }
LogotypeImageResolution ::= CHOICE {
numBits [1] INTEGER, -- Resolution in bits per pixel
tableSize [2] INTEGER } -- Number of colors or grey tones
LogotypeAudioInfo ::= SEQUENCE {
fileSize INTEGER, -- In octets, 0=unspecified
playTime INTEGER, -- In milliseconds, 0=unspecified
channels INTEGER, -- 0=unspecified,
-- 1=mono, 2=stereo, 4=quad
sampleRate [3] INTEGER OPTIONAL, -- Samples per second
language [4] IA5String OPTIONAL } -- RFC 5646 Language Tag
OtherLogotypeInfo ::= SEQUENCE {
logotypeType OBJECT IDENTIFIER,
info LogotypeInfo }
LogotypeReference ::= SEQUENCE {
refStructHash SEQUENCE SIZE (1..MAX) OF HashAlgAndValue,
refStructURI SEQUENCE SIZE (1..MAX) OF IA5String }
-- Places to get the same LogotypeData
-- image or audio object
HashAlgAndValue ::= SEQUENCE {
hashAlg AlgorithmIdentifier,
hashValue OCTET STRING }
When using indirect addressing, the URI (refStructURI) pointing to the external data structure MUST point to a resource that contains the DER-encoded data with the syntax LogotypeData.
間接的なアドレス指定を使用する場合、外部データ構造を指すURI（Refstructuri）は、Syntax Logotypedataを使用してDERエンコードされたデータを含むリソースを指す必要があります。
At least one of the optional elements in the LogotypeExtn structure MUST be present.
LogotypeExtn構造の少なくとも1つのオプション要素が存在する必要があります。
When using direct addressing, at least one of the optional elements in the LogotypeData structure MUST be present.
直接アドレス指定を使用する場合、ロゴタイプEDATA構造のオプション要素の少なくとも1つが存在する必要があります。
The LogotypeReference and LogotypeDetails structures explicitly identify one or more one-way hash functions employed to authenticate referenced image or audio objects. Certification Authorities (CAs) MUST include a hash value for each referenced object, calculated on the whole object. CAs MUST use the one-way hash function that is associated with the certificate signature to compute one hash value, and CAs MAY include other hash values. Clients MUST compute a one-way hash value using one of the identified functions, and clients MUST discard the logotype data if the computed hash value does not match the hash value in the certificate extension.
LogotypereferenceおよびlogotypeDetails構造は、参照された画像またはオーディオオブジェクトを認証するために使用される1つまたは複数の一方向ハッシュ関数を明示的に識別します。認証当局（CAS）には、オブジェクト全体で計算された各参照オブジェクトのハッシュ値を含める必要があります。CASは、証明書署名に関連付けられている一方向ハッシュ関数を使用して1つのハッシュ値を計算する必要があり、CASには他のハッシュ値が含まれる場合があります。クライアントは、識別された関数のいずれかを使用して一方向ハッシュ値を計算する必要があり、計算されたハッシュ値が証明書拡張のハッシュ値と一致しない場合、クライアントはロゴタイプデータを破棄する必要があります。
A media type is used to specify the format of the image or audio object containing the logotype data. The mediaType field MUST contain a string that is constructed according to the ABNF [RFC5234] rule for media-type provided in Section 8.3.1 of [RFC9110]. Media types MAY include parameters. To keep the mediaType field as small as possible, optional whitespace SHOULD NOT be included.
メディアタイプは、ロゴタイプデータを含む画像またはオーディオオブジェクトの形式を指定するために使用されます。MediATypeフィールドには、[RFC9110]のセクション8.3.1に記載されているメディアタイプのABNF [RFC5234]ルールに従って構築される文字列を含める必要があります。メディアタイプにはパラメーターが含まれる場合があります。mediatypeフィールドを可能な限り小さく保つために、オプションの両方の空白を含めるべきではありません。
Image format requirements are specified in Section 7, and audio format requirements are specified in Section 8.
画像形式の要件はセクション7で指定されており、オーディオ形式の要件はセクション8で指定されています。
When language is specified, the language tag MUST use the syntax in [RFC5646].
言語が指定されている場合、言語タグは[RFC5646]の構文を使用する必要があります。
The following logotype types are defined in this specification:
次のロゴタイプタイプは、この仕様で定義されています。
* community logotype: If communityLogos is present, the logotypes MUST represent one or more communities with which the certificate issuer is affiliated. The communityLogos MAY be present in an end entity certificate, a CA certificate, or an attribute certificate. The communityLogos contains a sequence of community logotypes, each representing a different community. If more than one community logotype is present, they MUST be placed in order of preferred appearance. Some clients MAY choose to display a subset of the present community logos; therefore, the placement within the sequence aids the client selection. The most preferred logotype MUST be first in the sequence, and the least preferred logotype MUST be last in the sequence.
* コミュニティロゴタイプ：CommunityLogosが存在する場合、ロゴタイプは、証明書発行者が提携している1つ以上のコミュニティを表す必要があります。CommunityLogosは、End Entity証明書、CA証明書、または属性証明書に存在する場合があります。CommunityLogosには、それぞれが異なるコミュニティを表す一連のコミュニティロゴタイプが含まれています。複数のコミュニティロゴタイプが存在する場合、それらは好ましい外観の順に配置する必要があります。一部のクライアントは、現在のコミュニティロゴのサブセットを表示することを選択できます。したがって、シーケンス内の配置は、クライアントの選択を支援します。最も好ましいロゴタイプは最初にシーケンスでなければならず、最小のロゴタイプはシーケンスで最後でなければなりません。
* issuer organization logotype: If issuerLogo is present, the logotype MUST represent the issuer's organization. The logotype MUST be consistent with, and require the presence of, an organization name stored in the organization attribute in the issuer field (for either a public key certificate or attribute certificate). The issuerLogo MAY be present in an end entity certificate, a CA certificate, or an attribute certificate.
* 発行者組織ロゴタイプ：IssuerLogoが存在する場合、ロゴタイプは発行者の組織を表す必要があります。ロゴタイプは、発行者フィールドに組織属性に保存されている組織名と一致し、存在する必要があります（公開鍵証明書または属性証明書のいずれか）。IssuerLogoは、End Entity証明書、CA証明書、または属性証明書に存在する場合があります。
* subject organization logotype: If subjectLogo is present, the logotype MUST represent the subject's organization. The logotype MUST be consistent with, and require the presence of, an organization name stored in the organization attribute in the subject field (for either a public key certificate or attribute certificate). The subjectLogo MAY be present in an end entity certificate, a CA certificate, or an attribute certificate.
* 対象組織ロゴタイプ：件名が存在する場合、ロゴタイプは被験者の組織を表す必要があります。ロゴタイプは、主題フィールドに組織属性に保存されている組織名と一致し、存在する必要があります（公開鍵証明書または属性証明書のいずれか）。件名は、エンティティ証明書、CA証明書、または属性証明書に存在する場合があります。
The relationship between the subject organization and the subject organization logotype, and the relationship between the issuer and either the issuer organization logotype or the community logotype, are relationships asserted by the issuer. The policies and practices employed by the issuer that check subject organization logotypes or claims about its issuer and community logotypes are outside the scope of this document.
対象組織と対象組織のロゴタイプとの関係、および発行者と発行者組織のロゴタイプまたはコミュニティロゴタイプのいずれかの関係は、発行者によって主張されている関係です。発行者が採用しているポリシーと慣行は、サブジェクト組織のロゴタイプまたはその発行者とコミュニティのロゴタイプについて主張することを確認します。このドキュメントの範囲外です。
When the optional LogotypeImageInfo is included with a logotype image, the parameters MUST be used with the following semantics and restrictions.
オプションのロゴタイプイメージインフーがロゴタイプ画像に含まれている場合、パラメーターは次のセマンティクスと制限で使用する必要があります。
The xSize and ySize fields represent the recommended display size for the logotype image. When a value of 0 (zero) is present, no recommended display size is specified. When non-zero values are present and these values differ from corresponding size values in the referenced image object, then the referenced image SHOULD be scaled to fit within the size parameters of LogotypeImageInfo while preserving the x and y ratio. Dithering may produce a more appropriate image than linear scaling.
XsizeおよびYsizeフィールドは、ロゴタイプ画像の推奨表示サイズを表します。0（ゼロ）の値が存在する場合、推奨されるディスプレイサイズは指定されていません。ゼロ以外の値が存在し、これらの値が参照される画像オブジェクトの対応するサイズ値と異なる場合、参照される画像は、xとyの比を保持しながら、ロゴタイプイメージインのサイズパラメーター内に収まるようにスケーリングする必要があります。ディザリングは、線形スケーリングよりも適切な画像を生成する場合があります。
The resolution field is redundant for all logotype image formats listed in Section 7. The optional resolution field SHOULD be omitted when the image format already contains this information.
解像度フィールドは、セクション7にリストされているすべてのロゴタイプ画像形式で冗長です。オプションの解像度フィールドは、画像形式にこの情報が既に含まれている場合に省略する必要があります。
If the logotype image is provided through direct addressing, then the image MAY be stored within the logotype certificate extension using the "data" scheme [RFC2397]. The syntax of the "data" URI scheme is shown below, which incorporates Errata ID 2045 and uses modern ABNF [RFC5234]:
ロゴタイプの画像が直接アドレス指定を通じて提供される場合、「データ」スキーム[RFC2397]を使用して、画像はロゴタイプ証明書拡張機能内に保存される場合があります。「データ」URIスキームの構文を以下に示します。これには、Errata ID 2045が組み込まれ、最新のABNF [RFC5234]を使用しています。
dataurl = "data:" [ media-type ] [ ";base64" ] "," data
data = *(reserved / unreserved / escaped)
reserved = ";" / "/" / "?" / ":" / "@" / "&" / "=" / "+" /
"$" / ","
unreserved = alphanum / mark
alphanum = ALPHA / DIGIT
mark = "-" / "_" / "." / "!" / "~" / "*" / "'" / "(" / ")"
escaped = "%" hex hex
hex = HEXDIG / "a" / "b" / "c" / "d" / "e" / "f"
where media-type is defined in Section 8.3.1 of [RFC9110] and ALPHA, DIGIT, and HEXDIG are defined in Appendix B.1 of [RFC5234].
ここで、メディアタイプは[RFC9110]のセクション8.3.1で定義されており、アルファ、桁、およびhexDigは[RFC5234]の付録B.1で定義されています。
When including the image data in the logotype certificate extension using the "data" URI scheme, the following conventions apply:
「データ」URIスキームを使用してロゴタイプ証明書拡張機能に画像データを含める場合、次の規則が適用されます。
* The value of mediaType in LogotypeDetails MUST be identical to the media type value in the "data" URL.
* LogotypedEtailsのMediAtypeの値は、「データ」URLのメディアタイプの値と同一でなければなりません。
* The hash of the image MUST be included in logotypeHash and MUST be calculated over the same data as it would have been if the image had been referenced through a link to an external resource.
* 画像のハッシュはLogotypeHashに含める必要があり、画像が外部リソースへのリンクを介して参照されていた場合と同じデータで計算する必要があります。
NOTE: As the "data" URI scheme is processed as a data source rather than as a URL, the image data is typically not limited by any URL length limit settings that otherwise apply to URLs in general.
注：「データ」URIスキームは、URLとしてではなくデータソースとして処理されるため、通常、URLに適用されるURL長い制限設定によって画像データは制限されません。
NOTE: Implementations need to be cautious about the size of images included in a certificate in order to ensure that the size of the certificate does not prevent the certificate from being used as intended.
注：実装は、証明書のサイズが証明書が意図されているように使用されないようにするために、証明書に含まれる画像のサイズについて注意する必要があります。
Logotypes identified by otherLogos (as defined in Section 4.1) can be used to enhance the display of logotypes and marks that represent partners, products, services, or any other characteristic associated with the certificate or its intended application environment when the standard logotype types are insufficient.
他のロゴによって識別されたロゴタイプ（セクション4.1で定義されている）は、標準のロゴタイプタイプが不十分な場合、証明書またはその目的のアプリケーション環境に関連付けられたパートナー、製品、サービス、またはその他の特性を表すロゴタイプとマークの表示を強化するために使用できます。。
The conditions and contexts of the intended use of these logotypes are defined at the discretion of the local client application.
これらのロゴタイプの意図された使用の条件とコンテキストは、ローカルクライアントアプリケーションの裁量で定義されます。
Three other logotype types are defined in the follow subsections.
他の3つのロゴタイプタイプは、フォローサブセクションで定義されています。
When a loyalty logotype appears in otherLogos, it MUST be identified by the id-logo-loyalty object identifier.
ロイヤルティロゴタイプが他のロゴに表示される場合、ID-Logo-Loyaltyオブジェクト識別子によって識別する必要があります。
id-logo OBJECT IDENTIFIER ::= { id-pkix 20 }
id-logo-loyalty OBJECT IDENTIFIER ::= { id-logo 1 }
A loyalty logotype, if present, MUST contain a logotype associated with a loyalty program related to the certificate or its use. The relation between the certificate and the identified loyalty program is beyond the scope of this document. The logotype certificate extension MAY contain more than one loyalty logotype.
ロイヤルティロゴタイプが存在する場合、証明書またはその使用に関連するロイヤルティプログラムに関連するロゴタイプを含める必要があります。証明書と特定されたロイヤルティプログラムとの関係は、このドキュメントの範囲を超えています。ロゴタイプ証明書拡張には、複数のロイヤルティロゴタイプが含まれる場合があります。
If more than one loyalty logotype is present, they MUST be placed in order of preferred appearance. Some clients MAY choose to display a subset of the present loyalty logotype data; therefore, the placement within the sequence aids the client selection. The most preferred loyalty logotype data MUST be first in the sequence, and the least preferred loyalty logotype data MUST be last in the sequence.
複数のロイヤルティロゴタイプが存在する場合、それらは好ましい外観の順に配置する必要があります。一部のクライアントは、現在のロイヤルティロゴタイプデータのサブセットを表示することを選択できます。したがって、シーケンス内の配置は、クライアントの選択を支援します。最も優先されるロイヤルティロゴタイプデータは、最初にシーケンスでなければならず、最も優先されるロイヤルティロゴタイプデータは、シーケンスで最後でなければなりません。
When a certificate background logotype appears in otherLogos, it MUST be identified by the id-logo-background object identifier.
証明書のバックグラウンドロゴタイプが他のロゴに表示される場合、ID-Logo-Backgroundオブジェクト識別子によって識別する必要があります。
id-logo-background OBJECT IDENTIFIER ::= { id-logo 2 }
The certificate background logotype, if present, MUST contain a graphical image intended as a background image for the certificate and/or a general audio sequence for the certificate. The background image MUST allow black text to be clearly read when placed on top of the background image. The logotype certificate extension MUST NOT contain more than one certificate background logotype.
証明書のバックグラウンドロゴタイプが存在する場合、証明書の背景画像として意図されたグラフィカルな画像および/または証明書の一般的なオーディオシーケンスを含める必要があります。背景画像は、背景画像の上に置かれたときに黒いテキストを明確に読むことができなければなりません。ロゴタイプ証明書拡張には、複数の証明書のバックグラウンドロゴタイプを含めてはなりません。
When a certificate image logotype appears in otherLogos, it MUST be identified by the id-logo-certImage object identifier.
証明書の画像ロゴタイプが他のロゴに表示される場合、ID-Logo-Certimageオブジェクト識別子によって識別する必要があります。
id-logo-certImage OBJECT IDENTIFIER ::= { id-logo 3 }
The certificate image logotype, if present, aids human interpretation of a certificate by providing meaningful visual information to the user interface (UI). The logotype certificate extension MUST NOT contain more than one certificate image logotype.
証明書イメージロゴタイプが存在する場合、ユーザーインターフェイス（UI）に意味のある視覚情報を提供することにより、証明書の人間の解釈を支援します。ロゴタイプ証明書拡張には、複数の証明書イメージロゴタイプを含めることはできません。
Typical situations when a human needs to examine the visual representation of a certificate are:
人間が証明書の視覚的表現を調べる必要がある場合の典型的な状況は次のとおりです。
* A person establishes a secured channel with an authenticated service. The person needs to determine the identity of the service based on the authenticated credentials.
* 人は、認証されたサービスで安全なチャネルを確立します。その人は、認証された資格情報に基づいてサービスの身元を決定する必要があります。
* A person validates the signature on critical information, such as signed executable code, and needs to determine the identity of the signer based on the signer's certificate.
* 人は、署名済みの実行可能コードなどの重要な情報に関する署名を検証し、署名者の証明書に基づいて署名者の身元を決定する必要があります。
* A person is required to select an appropriate certificate to be used when authenticating to a service or identity management infrastructure. The person needs to see the available certificates in order to distinguish between them in the selection process.
* サービスまたはID管理インフラストラクチャを認証するときに、使用する適切な証明書を選択する必要があります。その人は、選択プロセスでそれらを区別するために、利用可能な証明書を見る必要があります。
The display of certificate information to humans is challenging due to lack of well-defined semantics for critical identity attributes. Unless the application has out-of-band knowledge about a particular certificate, the application will not know the exact nature of the data stored in common identification attributes, such as serialNumber, organizationName, country, etc. Consequently, the application can display the actual data but faces the problem of labeling that data in the UI and informing the human about the exact nature (semantics) of that data. It is also challenging for the application to determine which identification attributes are important to display and how to organize them in a logical order.
人間への証明書情報の表示は、重要なアイデンティティ属性の明確に定義されたセマンティクスがないため、困難です。アプリケーションが特定の証明書に関する帯域外の知識を持っていない限り、アプリケーションは、SerialNumber、OrganizationName、国などの共通識別属性に保存されているデータの正確な性質を知りません。その結果、アプリケーションは実際のものを表示できます。データは、UIのデータにラベルを付け、そのデータの正確な性質（セマンティクス）について人間に通知する問題に直面しています。また、どの識別属性が表示するのに重要であり、それらを論理的な順序で整理する方法を決定することは、アプリケーションにとっても困難です。
When present, the certificate image MUST be a complete visual representation of the certificate. This means that the display of this certificate image represents all information about the certificate that the issuer subjectively defines as relevant to show to a typical human user within the typical intended use of the certificate, giving adequate information about at least the following three aspects of the certificate:
存在する場合、証明書イメージは証明書の完全な視覚的表現でなければなりません。これは、この証明書イメージの表示は、発行者が証明書の典型的な意図された使用内で典型的な人間のユーザーに表示するために主観的に定義する証明書に関するすべての情報を表し、少なくとも次の3つの側面に関する適切な情報を提供することを意味します。証明書：
* certificate context
* 証明書のコンテキスト
* certificate issuer
* 証明書発行者
* certificate subject
* 証明書科目
Certificate context information is visual marks and/or textual information that helps the typical user to understand the typical usage and/or purpose of the certificate.
証明書のコンテキスト情報は、典型的なユーザーが証明書の典型的な使用および/または目的を理解するのに役立つ視覚マークおよび/またはテキスト情報です。
It is up to the issuer to decide what information -- in the form of text, graphical symbols, and elements -- represents a complete visual representation of the certificate. However, the visual representation of certificate subject and certificate issuer information from the certificate MUST have the same meaning as the textual representation of that information in the certificate itself.
テキスト、グラフィカルなシンボル、要素の形式でどの情報を決定するかは、証明書の完全な視覚的表現を表すものを決定するのは発行者次第です。ただし、証明書の主題と証明書の発行者情報の視覚的表現は、証明書自体のその情報のテキスト表現と同じ意味を持たなければなりません。
Applications providing a Graphical User Interface (GUI) to the certificate user MAY present a certificate image as the only visual representation of a certificate; however, the certificate user SHOULD be able to easily obtain the details of the certificate content.
証明書ユーザーにグラフィカルユーザーインターフェイス（GUI）を提供するアプリケーションは、証明書の唯一の視覚表現として証明書イメージを提示することができます。ただし、証明書ユーザーは、証明書のコンテンツの詳細を簡単に取得できる必要があります。
Logotypes MAY be included in public key certificates and attribute certificates at the discretion of the certificate issuer; however, the relying party MUST NOT use the logotypes as part of certification path validation or automated trust decisions. The sole purpose of logotypes is to enhance the display of a particular certificate, regardless of its position in a certification path.
ロゴタイプは、証明書発行者の裁量で公開キー証明書および属性証明書に含まれる場合があります。ただし、頼る当事者は、認証パス検証または自動化された信頼の決定の一部としてロゴタイプを使用してはなりません。ロゴタイプの唯一の目的は、認定パスでの位置に関係なく、特定の証明書の表示を強化することです。
All PKI implementations require relying party software to have some mechanism to determine whether a trusted CA issues a particular certificate. This is an issue for certification path validation, including consistent policy and name checking.
すべてのPKI実装では、信頼できるCAが特定の証明書を発行するかどうかを判断するために、一部のメカニズムを持つためにパーティーソフトウェアに依存する必要があります。これは、一貫したポリシーや名前のチェックなど、認証パス検証の問題です。
After a certification path is successfully validated, the replying party trusts the information that the CA includes in the certificate, including any certificate extensions. The client software can choose to make use of such information, or the client software can ignore it. If the client is unable to support a provided logotype, the client MUST NOT report an error; instead, the client MUST behave as though no logotype certificate extension was included in the certificate. Current standards do not provide any mechanism for cross-certifying CAs to constrain subordinate CAs from including private extensions (see Section 9).
認定パスが正常に検証された後、返信者は、証明書拡張を含むCAが証明書に含む情報を信頼します。クライアントソフトウェアは、そのような情報を使用することを選択できます。クライアントソフトウェアは無視できます。クライアントが提供されたロゴタイプをサポートできない場合、クライアントはエラーを報告してはなりません。代わりに、クライアントは、証明書にロゴタイプ証明書延長が含まれていないかのように振る舞う必要があります。現在の標準では、相互認定CASが従属CASにプライベートエクステンションを含めることを制限するメカニズムを提供しません（セクション9を参照）。
Consequently, if relying party software accepts a CA, then it should be prepared to (unquestioningly) display the associated logotypes to its human user, given that it is configured to do so. Information about the logotypes is provided so that the replying party software can select the one that will best meet the needs of the human user. This choice depends on the abilities of the human user, as well as the capabilities of the platform on which the replaying party software is running. If none of the provided logotypes meets the needs of the human user or matches the capabilities of the platform, then the logotypes can be ignored.
したがって、頼るパーティーソフトウェアがCAを受け入れる場合、それが設定されていることを考えると、関連するロゴタイプを人間のユーザーに（疑いなく）表示する準備をする必要があります。ロゴタイプに関する情報は、返信パーティーソフトウェアが人間のユーザーのニーズを最もよく満たすものを選択できるように提供されます。この選択は、人間のユーザーの能力と、再生パーティーソフトウェアが実行されているプラットフォームの機能に依存します。提供されたロゴタイプのいずれも、人間のユーザーのニーズを満たしていない場合、またはプラットフォームの機能と一致しない場合、ロゴタイプは無視できます。
A client MAY, subject to local policy, choose to display none, one, or any number of the logotypes in the logotype certificate extension. In many cases, a client will be used in an environment with a good network connection and also used in an environment with little or no network connectivity. For example, a laptop computer can be docked with a high-speed LAN connection, or it can be disconnected from the network altogether. In recognition of this situation, the client MUST include the ability to disable the fetching of logotypes. However, locally cached logotypes can still be displayed when the user disables the fetching of additional logotypes.
クライアントは、ローカルポリシーに従って、ロゴタイプ証明書拡張にロゴタイプを1つ、、または任意の数を表示することを選択できます。多くの場合、クライアントは良好なネットワーク接続を備えた環境で使用され、ネットワーク接続がほとんどまたはまったくない環境でも使用されます。たとえば、ラップトップコンピューターは高速LAN接続でドッキングすることも、ネットワークから完全に切断することもできます。この状況を認識して、クライアントはロゴタイプのフェッチを無効にする機能を含める必要があります。ただし、ユーザーが追加のロゴタイプの取得を無効にすると、ローカルにキャッシュされたロゴタイプを表示できます。
A client MAY, subject to local policy, choose any combination of audio and image presentation for each logotype. That is, the client MAY display an image with or without playing a sound, and it MAY play a sound with or without displaying an image. A client MUST NOT play more than one logotype audio sequence at the same time.
クライアントは、ローカルポリシーに従って、各ロゴタイプのオーディオと画像のプレゼンテーションの任意の組み合わせを選択できます。つまり、クライアントはサウンドを再生するかなしで画像を表示する場合があり、画像を表示する場合または表示せずにサウンドを再生できます。クライアントは、同時に複数のロゴタイプオーディオシーケンスを再生してはなりません。
The logotype is to be displayed in conjunction with other identity information contained in the certificate. The logotype is not a replacement for this identity information.
ロゴタイプは、証明書に含まれる他の身元情報と併せて表示されます。ロゴタイプは、このID情報の代替ではありません。
Care is needed when designing replying party software to ensure that an appropriate context of logotype information is provided. This is especially difficult with audio logotypes. It is important that the human user be able to recognize the context of the logotype, even if other audio streams are being played.
ロゴタイプ情報の適切なコンテキストが提供されるように、返信パーティーソフトウェアを設計するときは注意が必要です。これは、オーディオロゴタイプで特に困難です。他のオーディオストリームが再生されていても、人間のユーザーがロゴタイプのコンテキストを認識できることが重要です。
If the relying party software is unable to successfully validate a particular certificate, then it MUST NOT display any logotype data associated with that certificate.
頼るパーティーソフトウェアが特定の証明書を正常に検証できない場合、その証明書に関連付けられたロゴタイプデータを表示してはなりません。
Animated images SHOULD NOT be used.
アニメーション画像を使用しないでください。
The following table lists common image formats and the corresponding media type. The table also indicates the support requirements for these image formats. The file name extensions commonly used for each of these formats is also provided. Implementations MAY support other image formats.
次の表には、一般的な画像形式と対応するメディアタイプを示します。この表は、これらの画像形式のサポート要件も示しています。これらの各形式で一般的に使用されるファイル名拡張機能も提供されます。実装は、他の画像形式をサポートする場合があります。
+========+==============+===========+============+============+
| Format | Media Type | Extension | References | Implement? |
+========+==============+===========+============+============+
| JPEG | image/jpeg | .jpg | [JPEG] | MUST |
| | | .jpeg | [RFC2046] | support |
+--------+--------------+-----------+------------+------------+
| GIF | image/gif | .gif | [GIF] | MUST |
| | | | [RFC2046] | support |
+--------+--------------+-----------+------------+------------+
| SVG | image/ | .svg | [SVGT] | SHOULD |
| | svg+xml | | [SVGR] | support |
+--------+--------------+-----------+------------+------------+
| SVG + | image/ | .svgz | [SVGT] | MUST |
| GZIP | svg+xml+gzip | .svg.gz | [SVGZR] | support |
+--------+--------------+-----------+------------+------------+
| PNG | image/png | .png | [ISO15948] | SHOULD |
| | | | [PNGR] | support |
+--------+--------------+-----------+------------+------------+
| PDF | application/ | .pdf | [ISO32000] | MAY |
| | pdf | | [ISO19005] | support |
| | | | [RFC8118] | |
+--------+--------------+-----------+------------+------------+
Table 1: Image Formats
表1：画像形式
NOTE: The image/svg+xml-compressed media type is widely implemented, but it has not yet been registered with IANA.
注：画像/SVG XML圧縮されたメディアタイプは広く実装されていますが、IANAにはまだ登録されていません。
When a Scalable Vector Graphics (SVG) image is used, whether the image is compressed or not, the SVG Tiny profile [SVGT] MUST be followed, with these additional restrictions:
画像が圧縮されているかどうかにかかわらず、スケーラブルベクトルグラフィックス（SVG）画像を使用する場合、これらの追加の制限を使用して、SVG Tinyプロファイル[SVGT]に従う必要があります。
* The SVG image MUST NOT contain any Internationalized Resource Identifier (IRI) references to information stored outside of the SVG image of type B, C, or D, according to Section 14.1.4 of [SVGT].
* SVG画像には、[SVGT]のセクション14.1.4に従って、タイプB、C、またはDのSVG画像の外側に保存されている情報への国際化されたリソース識別子（IRI）の参照を含めてはなりません。
* The SVG image MUST NOT contain any script element, according to Section 15.2 of [SVGT].
* [SVGT]のセクション15.2に従って、SVG画像にはスクリプト要素を含めてはなりません。
* The XML structure in the SVG file MUST use linefeed (0x0A) as the end-of-line (EOL) character when calculating a hash over the SVG image.
* SVGファイルのXML構造は、SVG画像の上でハッシュを計算する際に、ラインフィード（0x0a）を行の終了（EOL）文字として使用する必要があります。
When a GZIP-compressed SVG image is fetched with HTTP, the client will receive a response that includes these headers:
GZIP圧縮されたSVG画像がHTTPでフェッチされると、クライアントはこれらのヘッダーを含む応答を受け取ります。
Content-Type: image/svg+xml
Content-Encoding: gzip
In this case, the octet stream of type image/svg+xml is compressed with GZIP [RFC1952], as specified in [SVGR].
この場合、[SVGR]で指定されているように、タイプ画像/SVG XMLのオクテットストリームはGZIP [RFC1952]で圧縮されます。
When an uncompressed SVG image is fetched with HTTP, the client will receive a response with the same Content-Type header but no Content-Encoding header.
非圧縮SVGイメージがHTTPでフェッチされると、クライアントは同じコンテンツタイプのヘッダーで応答を受け取りますが、コンテンツをコードするヘッダーはありません。
Whether the SVG image is GZIP-compressed or uncompressed, the hash value for the SVG image is calculated over the uncompressed SVG content with canonicalized EOL characters, as specified above.
SVG画像がGZIP圧縮または非圧縮されているかどうかにかかわらず、SVG画像のハッシュ値は、上記で指定されているように、標準化されたEOL文字を使用して非圧縮されたSVGコンテンツで計算されます。
When an SVG image is embedded in the certificate extension using the "data" URL scheme, the SVG image data MUST be provided in GZIP-compressed form, and the XML structure, prior to compression, SHOULD use linefeed (0x0A) as the end-of-line (EOL) character.
「データ」URLスキームを使用してSVGイメージが証明書拡張機能に埋め込まれている場合、SVG画像データはGZIP圧縮形式で提供され、圧縮の前にXML構造を使用する必要があります。of-line（eol）文字。
When a bitmap image is used, the PNG [ISO15948] format SHOULD be used.
ビットマップ画像を使用する場合、PNG [ISO15948]形式を使用する必要があります。
According to [ISO32000], when a Portable Document Format (PDF) document is used, it MUST also be formatted according to the profile PDF/A [ISO19005].
[ISO32000]によれば、ポータブルドキュメント形式（PDF）ドキュメントを使用する場合、プロファイルPDF/A [ISO19005]に従ってフォーマットする必要があります。
Implementations that support audio MUST support the MP3 audio format [MP3] with a media type of "audio/mpeg" [RFC3003]. Implementations SHOULD support text-based audio data with a media type of "text/ plain;charset=UTF-8". Implementations MAY support other audio formats.
オーディオをサポートする実装は、メディアタイプの「Audio/MPEG」[RFC3003]を使用してMP3オーディオ形式[MP3]をサポートする必要があります。実装は、メディアタイプの「テキスト/プレーン、charset = utf-8」を使用してテキストベースのオーディオデータをサポートする必要があります。実装は、他のオーディオ形式をサポートする場合があります。
Text-based audio data using the media type of "text/ plain;charset=UTF-8" is intended to be used by text-to-speech software. When this audio type is used, the following requirements apply:
メディアタイプの「Text/ Plain; charset = utf-8」を使用したテキストベースのオーディオデータは、テキストからスピーチソフトウェアで使用することを目的としています。このオーディオタイプを使用すると、次の要件が適用されます。
* LogotypeAudioInfo MUST be present and specify the language of the text.
* logotypeaudioinfoが存在し、テキストの言語を指定する必要があります。
* The fileSize, playTime, and channels elements of LogotypeAudioInfo MUST have the value of 0.
* ロゴタイプのファイルサイズ、再生時間、およびチャンネルの要素は、値が0の値を持っている必要があります。
* The sampleRate element of LogotypeAudioInfo MUST be absent.
* LogotypeaudioInfoのサンプル要素はない必要があります。
Implementations that simultaneously display multiple logotype types (subject organization, issuer organization, community, or other) MUST ensure that there is no ambiguity as to the binding between the image and the type of logotype that the image represents. "Logotype type" is defined in Section 1.1, and it refers to the type of entity or affiliation represented by the logotype, not the of binary format of the image or audio.
複数のロゴタイプタイプ（サブジェクト組織、発行者組織、コミュニティ、またはその他）を同時に表示する実装は、画像と画像が表すロゴタイプのタイプとの間の拘束力について曖昧さがないことを確認する必要があります。「ロゴタイプタイプ」はセクション1.1で定義されており、画像またはオーディオのバイナリ形式ではなく、ロゴタイプで表されるエンティティまたは提携の種類を指します。
Logotypes are very difficult to securely and accurately define. Names are also difficult in this regard, but logotypes are even worse. It is quite difficult to specify what is, and what is not, a legitimate logotype of an organization. There is an entire legal structure around this issue, and it will not be repeated here. However, issuers should be aware of the implications of including images associated with a trademark or servicemark before doing so. As logotypes can be difficult (and sometimes expensive) to verify, the possibility of errors related to assigning wrong logotypes to organizations is increased.
ロゴタイプは、安全かつ正確に定義することが非常に困難です。この点でも名前は困難ですが、ロゴタイプはさらに悪化しています。組織の合法的なロゴタイプであるものと何がないかを指定することは非常に困難です。この問題には法的構造全体があり、ここでは繰り返されません。ただし、発行者は、その前に商標またはサービスマークに関連付けられた画像を含めることの意味を認識する必要があります。ロゴタイプは検証するのが難しい（そして時には高価な）可能性があるため、間違ったロゴタイプを組織に割り当てることに関連するエラーの可能性が増加します。
This is not a new issue for electronic identification instruments. It is already dealt with in a number of similar situations in the physical world, including physical employee identification cards. In addition, there are situations where identification of logotypes is rather simple and straightforward, such as logotypes for well-known industries and institutes. These issues should not stop those service providers who want to issue logotypes from doing so, where relevant.
これは、電子識別機器の新しい問題ではありません。物理的な従業員の識別カードを含む、物理的な世界では、すでに多くの同様の状況で扱われています。さらに、有名な産業や研究所のロゴタイプなど、ロゴタイプの識別がかなり単純で簡単な状況があります。これらの問題は、ロゴタイプを発行したいサービスプロバイダーが、関連する場合はそうすることを止めるべきではありません。
It is impossible to prevent fraudulent creation of certificates by dishonest or badly performing issuers, containing names and logotypes that the issuer has no claim to or has failed to check correctly. Such certificates could be created in an attempt to socially engineer a user into accepting a certificate. The premise used for the logotype work is thus that logotype graphics in a certificate are trusted only if the certificate is successfully validated within a valid path. It is thus imperative that the representation of any certificate that fails to validate is not enhanced in any way by using the logotype data.
発行者が正しくチェックしていない、または正しくチェックできなかった、またはロゴタイプを含む不正またはパフォーマンスの発行者による証明書の不正な作成を防ぐことは不可能です。このような証明書は、ユーザーをソーシャルエンジニアにして証明書を受け入れるようにするために作成できます。したがって、ロゴタイプの作業に使用される前提は、証明書のロゴタイプグラフィックスが有効なパス内で正常に検証されている場合にのみ信頼されることです。したがって、検証に失敗した証明書の表現は、ロゴタイプデータを使用していかなる方法でも強化されないことが不可欠です。
This underlines the necessity for CAs to provide reliable services and the relying party's responsibility and need to carefully select which CAs are trusted to provide public key certificates.
これは、CASが信頼できるサービスを提供する必要性と、頼る当事者の責任を提供し、公開キー証明書を提供するために信頼されているCASを慎重に選択する必要があることを強調しています。
This also underlines the general necessity for relying parties to use up-to-date software libraries to render or dereference data from external sources, including logotype data in certificates, to minimize risks related to processing potentially malicious data before it has been adequately verified and validated. Implementers should review the guidance in Section 7 of [RFC3986].
これはまた、当事者が最新のソフトウェアライブラリを使用して、証明書のロゴタイプデータを含む外部ソースからデータをレンダリングまたは繰り返し、潜在的に悪意のあるデータの処理に関連するリスクを最小限に抑えるための一般的な必要性を強調しています。。実装者は、[RFC3986]のセクション7のガイダンスを確認する必要があります。
Referenced image objects are hashed in order to bind the image to the signature of the certificate. Some image types, such as SVG, allow part of the image to be collected from an external source by incorporating a reference to an external file that contains the image. If this feature were used within a logotype image, the hash of the image would only cover the URI reference to the external image file but not the referenced image data. Clients SHOULD verify that SVG images meet all requirements listed in Section 7 and reject images that contain references to external data.
参照された画像オブジェクトは、画像を証明書の署名にバインドするためにハッシュされます。SVGなどの一部の画像タイプにより、画像を含む外部ファイルへの参照を組み込むことにより、画像の一部を外部ソースから収集できます。この機能がロゴタイプ画像内で使用された場合、画像のハッシュは、URI参照が外部画像ファイルへのみをカバーしますが、参照された画像データはカバーしません。クライアントは、SVG画像がセクション7にリストされているすべての要件を満たしていることを確認し、外部データへの参照を含む画像を拒否することを確認する必要があります。
CAs issuing certificates with embedded logotype images should be cautious when accepting graphics from the certificate requester for inclusion in the certificate if the hash algorithm used to sign the certificate is vulnerable to collision attacks, as described in [RFC6151]. In such a case, the accepted image may contain data that could help an attacker to obtain colliding certificates with identical certificate signatures.
[RFC6151]に記載されているように、証明書に署名するために使用されたハッシュアルゴリズムが衝突攻撃に対して脆弱である場合、埋め込まれたロゴタイプ画像を使用して証明書要求者からグラフィックスを受け入れる場合は、証明書に含めるためのグラフィックスを受け入れる場合は、CASが慎重です。そのような場合、受け入れられた画像には、攻撃者が同一の証明書署名を持つ衝突証明書を取得するのに役立つデータが含まれている場合があります。
Certification paths may also impose name constraints that are systematically checked during certification path processing, which, in theory, may be circumvented by logotypes.
認定パスは、認証パス処理中に体系的にチェックされる名前の制約を課す場合があります。理論的には、ロゴタイプによって回避される場合があります。
Certificate path processing, as defined in [RFC5280], does not constrain the inclusion of logotype data in certificates. A parent CA can constrain certification path validation such that subordinate CAs cannot issue valid certificates to end entities outside a limited name space or outside specific certificate policies. A malicious CA can comply with these name and policy requirements and still include inappropriate logotypes in the certificates that it issues. These certificates will pass the certification path validation algorithm, which means the client will trust the logotypes in the certificates. Since there is no technical mechanism to prevent or control subordinate CAs from including the logotype certificate extension or its contents, where appropriate, a parent CA could employ a legal agreement to impose a suitable restriction on the subordinate CA. This situation is not unique to the logotype certificate extension.
[RFC5280]で定義されている証明書経路処理は、証明書にロゴタイプデータを含めることを制約しません。親のCAは、認証パス検証を制約することができ、そのため、下位のCASは有効な証明書を発行して、限られた名前のスペースまたは特定の証明書ポリシー以外のエンティティを終了できません。悪意のあるCAは、これらの名前とポリシーの要件に準拠し、それが発行する証明書に不適切なロゴタイプを含めることができます。これらの証明書は、認定パス検証アルゴリズムを渡すことになります。つまり、クライアントは証明書のロゴタイプを信頼します。従属CASを防止または制御するための技術的メカニズムがないため、ロゴタイプ証明書の拡張またはその内容を含むことを防止または制御するため、適切な場合、親CAは法的契約を採用して下位CAに適切な制限を課すことができます。この状況は、ロゴタイプ証明書拡張に固有のものではありません。
When a relying party fetches remote logotype data, a mismatch between the media type provided in the mediaType field of the LogotypeDetails and the Content-Type HTTP header of the retrieved object MUST be treated as a failure, and the fetched logotype data should not be presented to the user. However, if more than one location for the remote logotype data is provided in the certificate extension, the relying party MAY try to fetch the remote logotype data from an alternate location to resolve the failure.
依存しているパーティがリモートロゴタイプデータを取得する場合、ロゴタイプテールのメディアタイプフィールドで提供されるメディアタイプと取得オブジェクトのコンテンツタイプのHTTPヘッダーが障害として扱われ、フェッチされたロゴタイプデータを提示する必要があります。ユーザーに。ただし、リモートロゴタイプデータの複数の場所が証明書拡張機能に提供されている場合、依存者は、失敗を解決するために、代替場所からリモートロゴタイプデータを取得しようとする場合があります。
When a subscriber requests the inclusion of remote logotype data in a certificate, the CA cannot be sure that any logotype data will be available at the provided URI for the entire validity period of the certificate. To mitigate this concern, the CA may provide the logotype data from a server under its control, rather than a subscriber-controlled server.
サブスクライバーが証明書にリモートロゴタイプデータを含めることを要求する場合、CAは、証明書の有効期間全体で提供されたURIでロゴタイプデータが利用可能になることを確認することはできません。この懸念を軽減するために、CAは、サブスクライバー制御サーバーではなく、その制御下にあるサーバーからロゴタイプデータを提供する場合があります。
The controls available to a parent CA to protect itself from rogue subordinate CAs are non-technical. They include:
親CAが利用できるコントロールは、不正な従属CAから身を守るための非技術です。それらは次のとおりです：
* Contractual agreements of suitable behavior, including terms of liability in case of material breach.
* 重大な違反の場合の責任条件を含む、適切な行動の契約上の契約。
* Control mechanisms and procedures to monitor and follow the behavior of subordinate CAs, including Certificate Transparency [RFC9162].
* 証明書の透明性[RFC9162]を含む、下位CAの動作を監視および追跡するための制御メカニズムと手順。
* Use of certificate policies to declare an assurance level of logotype data, as well as to guide applications on how to treat and display logotypes.
* ロゴタイプデータの保証レベルを宣言するために、証明書ポリシーの使用、およびロゴタイプの治療方法と表示方法に関するアプリケーションをガイドするために使用します。
* Use of revocation functions to revoke any misbehaving CA.
* 失効関数を使用して、不正行為を取り消すことができます。
There is not a simple, straightforward, and absolute technical solution. Rather, involved parties must settle some aspects of PKI outside the scope of technical controls. As such, issuers need to clearly identify and communicate the associated risks.
シンプルで、単純で絶対的な技術的なソリューションはありません。むしろ、関与する当事者は、技術的な管理の範囲外でPKIのいくつかの側面を解決しなければなりません。そのため、発行者は関連するリスクを明確に特定して伝える必要があります。
Certificates are commonly public objects, so the inclusion of privacy-sensitive information in certificates should be avoided. The more information that is included in a certificate, the greater the likelihood that the certificate will reveal privacy-sensitive information. The inclusion of logotype data needs to be considered in this context.
証明書は一般的に公開オブジェクトなので、証明書にプライバシーに敏感な情報を含めることは避けるべきです。証明書に含まれる情報が多いほど、証明書がプライバシーに敏感な情報を明らかにする可能性が高くなります。このコンテキストでは、ロゴタイプデータを含める必要があります。
Logotype data might be fetched from a server when it is needed. By watching activity on the network, an observer can determine which clients are making use of certificates that contain particular logotype data. Since clients are expected to locally cache logotype data, network traffic to the server containing the logotype data will not be generated every time the certificate is used. Further, when logotype data is not cached, activity on the network might reveal certificate usage frequency. Even when logotype data is cached, regardless of whether direct or indirect addressing is employed, network traffic monitoring could reveal when logotype data is fetched for the first time. Implementations MAY encrypt fetches of logotype data using HTTPS, padding the data to a common size to reduce visibility into the data that is being fetched. Likewise, servers MAY reduce visibility into the data that is being returned by encrypting with HTTPS and padding to a few common sizes.
ロゴタイプデータは、必要なときにサーバーからフェッチされる場合があります。ネットワーク上のアクティビティを視聴することにより、オブザーバーは、特定のロゴタイプデータを含む証明書を使用しているクライアントを決定できます。クライアントはロゴタイプデータをローカルにキャッシュすることが期待されるため、ロゴタイプデータを含むサーバーへのネットワークトラフィックは、証明書が使用されるたびに生成されません。さらに、ロゴタイプデータがキャッシュされていない場合、ネットワーク上のアクティビティは証明書の使用頻度を明らかにする可能性があります。ロゴタイプデータがキャッシュされた場合でも、直接的または間接的なアドレス指定が使用されているかどうかに関係なく、ネットワークトラフィック監視は、ロゴタイプデータが初めてフェッチされると明らかになります。実装は、HTTPを使用してロゴタイプデータのフェッチを暗号化し、データを共通のサイズにパディングして、フェッチされているデータの可視性を低下させる場合があります。同様に、サーバーは、HTTPSとパディングをいくつかの一般的なサイズに暗号化することにより、返されるデータへの可視性を低下させる場合があります。
Similarly, when fetching logotype data from a server, the server operator can determine which clients are making use of certificates that contain particular logotype data. As above, locally caching logotype data will eliminate the need to fetch the logotype data each time the certificate is used, and lack of caching would reveal usage frequency. Even when implementations cache logotype data, regardless of whether direct or indirect addressing is employed, the server operator could observe when logotype data is fetched for the first time.
同様に、サーバーからロゴタイプデータを取得するとき、サーバーオペレーターは、特定のロゴタイプデータを含む証明書を使用しているクライアントを決定できます。上記のように、ローカルでキャッシュロゴタイプデータは、証明書が使用されるたびにロゴタイプデータを取得する必要性を排除し、キャッシュの欠如により使用頻度が明らかになります。実装がロゴタイプデータをキャッシュする場合でも、直接または間接的なアドレス指定が採用されているかどうかにかかわらず、サーバーオペレーターは、ロゴタイプデータが初めてフェッチされたときに観察できます。
In addition, the use of an encrypted DNS mechanism, such as DNS over TLS (DoT) [RFC7858] or DNS over HTTPS (DoH) [RFC9230], hides the name resolution traffic, which is usually a first step in fetching remote logotype objects.
さらに、TLS（DOT）[RFC7858]を介したDNSなどの暗号化されたDNSメカニズムの使用は、HTTPS（DOH）[RFC9230]を介したDNSを使用することで、名前解像度トラフィックを隠します。。
When the "data" URI scheme is used with direct addressing, there is no network traffic to fetch logotype data, which avoids the observations of network traffic or server operations described above. To obtain this benefit, the certificate will be larger than one that contains a URL. Due to the improved privacy posture, the "data" URI scheme with direct addressing will be the only one that is supported by some CAs. Privacy-aware certificate subscribers MAY wish to insist that logotype data is embedded in the certificate with the "data" URI scheme with direct addressing.
「データ」URIスキームが直接アドレス指定で使用される場合、ロゴタイプデータを取得するためのネットワークトラフィックはありません。これにより、上記のネットワークトラフィックまたはサーバー操作の観察が回避されます。この利益を得るために、証明書はURLを含むものよりも大きくなります。プライバシーの姿勢が改善されているため、直接アドレス指定を伴う「データ」URIスキームは、一部のCASによってサポートされている唯一のものです。プライバシー認識証明書サブスクライバーは、ロゴタイプデータが直接アドレス指定を伴う「データ」URIスキームを使用して証明書に埋め込まれていることを主張することをお勧めします。
In cases where logotype data is cached by the relying party, the cache index should include the hash values of the associated logotype data with the goal of fetching the logotype data only once, even when it is referenced by multiple URIs. The index should include hash values for all supported hash algorithms. The cached data should include the media type as well as the logotype data. Implementations should give preference to logotype data that is already in the cache when multiple alternatives are offered in the LogotypeExtn certificate extension.
ロゴタイプデータが依存関係者によってキャッシュされている場合、キャッシュインデックスには、複数のURIが参照されている場合でも、ロゴタイプデータを1回だけ取得することを目的とした、関連するロゴタイプデータのハッシュ値を含める必要があります。インデックスには、サポートされているすべてのハッシュアルゴリズムのハッシュ値を含める必要があります。キャッシュされたデータには、メディアタイプとロゴタイプデータを含める必要があります。実装は、LogotypeExtn証明書拡張で複数の代替案が提供されている場合、すでにキャッシュ中のロゴタイプデータを優先する必要があります。
When the "data" URI scheme is used, the relying party MAY add the embedded logotype data to the local cache, which could avoid the need to fetch the logotype data if it is referenced by a URL in another certificate.
「データ」URIスキームが使用されると、頼る当事者は、埋め込まれたロゴタイプデータをローカルキャッシュに追加する場合があります。
When fetching remote logotype data, relying parties should use the most privacy-preserving options that are available to minimize the opportunities for servers to "fingerprint" clients. For example, avoid cookies, ETags, and client certificates.
リモートロゴタイプデータを取得するとき、頼るパーティーは、サーバーがクライアントを「指紋」する機会を最小限に抑えるために利用できる最もプライバシーを提供するオプションを使用する必要があります。たとえば、Cookie、ETAG、およびクライアント証明書を避けてください。
When a relying party encounters a new certificate, the lack of network traffic to fetch logotype data might indicate that a certificate with references to the same logotype data has been previously processed and cached.
依存している当事者が新しい証明書に遭遇すると、ロゴタイプデータを取得するためのネットワークトラフィックの欠如は、同じロゴタイプデータへの参照がある証明書が以前に処理され、キャッシュされたことを示している可能性があります。
TLS 1.3 [RFC8446] includes the ability to encrypt the server's certificate in the TLS handshake, which helps hide the server's identity from anyone that is watching activity on the network. If the server's certificate includes remote logotype data, the client fetching that data might disclose the otherwise protected server identity.
TLS 1.3 [RFC8446]には、TLSハンドシェイクでサーバーの証明書を暗号化する機能が含まれています。これは、ネットワーク上でアクティビティを見ている人からサーバーの身元を隠すのに役立ちます。サーバーの証明書にリモートロゴタイプデータが含まれている場合、そのデータを取得すると、それ以外の場合は保護されているサーバーのアイデンティティが開示される可能性があります。
For the new ASN.1 module in Appendix A.2, IANA has assigned the following OID in the "SMI Security for PKIX Module Identifier" registry (1.3.6.1.5.5.7.0):
付録A.2の新しいASN.1モジュールの場合、IANAは次のOIDを「PKIXモジュール識別子のSMIセキュリティ」レジストリ（1.3.6.1.5.5.5.7.0）に割り当てました。
+=========+======================+============+
| Decimal | Description | References |
+=========+======================+============+
| 107 | id-mod-logotype-2022 | RFC 9399 |
+---------+----------------------+------------+
Table 2
IANA has updated the entries in the "Structure of Management Information (SMI) Numbers" registry that referred to [RFC3709] or [RFC6170] to refer to this document. These entries are noted in the tables below.
IANAは、[RFC3709]または[RFC6170]に言及した「管理情報の構造（SMI）番号」レジストリのエントリを更新して、このドキュメントを参照しています。これらのエントリは、以下の表に記載されています。
From the "SMI Security for PKIX Module Identifier" registry (1.3.6.1.5.5.7.0):
「PKIXモジュール識別子のSMIセキュリティ」レジストリ（1.3.6.1.1.5.5.7.0）から：
+=========+===========================+============+
| Decimal | Description | References |
+=========+===========================+============+
| 22 | id-mod-logotype | RFC 9399 |
+---------+---------------------------+------------+
| 68 | id-mod-logotype-certimage | RFC 9399 |
+---------+---------------------------+------------+
Table 3
From the "SMI Security for PKIX Certificate Extension" registry (1.3.6.1.5.5.7.1):
「PKIX証明書拡張のSMIセキュリティ」レジストリ（1.3.6.1.5.5.7.1）から：
+=========+================+============+
| Decimal | Description | References |
+=========+================+============+
| 12 | id-pe-logotype | RFC 9399 |
+---------+----------------+------------+
Table 4
From the "SMI Security for PKIX Other Logotype Identifiers" registry (1.3.6.1.5.5.7.20):
「PKIXのSMIセキュリティ他のロゴタイプ識別子」レジストリ（1.3.6.1.5.5.7.20）：
+=========+====================+============+
| Decimal | Description | References |
+=========+====================+============+
| 1 | id-logo-loyalty | RFC 9399 |
+---------+--------------------+------------+
| 2 | id-logo-background | RFC 9399 |
+---------+--------------------+------------+
| 3 | id-logo-certImage | RFC 9399 |
+---------+--------------------+------------+
Table 5
[GIF] CompuServe Incorporated, "Graphics Interchange Format",
Version 89a, July 1990,
<https://www.w3.org/Graphics/GIF/spec-gif89a.txt>.
[ISO15948] ISO/IEC, "Information technology -- Computer graphics and
image processing -- Portable Network Graphics (PNG):
Functional specification", ISO/IEC 15948:2004, March 2004.
[JPEG] ITU-T, "Information technology -- Digital compression and
coding of continuous-tone still images: JPEG File
Interchange Format (JFIF)", ITU-T Recommendation T.871,
ISO/IEC 10918-5:2013, May 2013.
[MP3] ISO/IEC, "Information technology -- Generic coding of
moving pictures and associated audio information -- Part
3: Audio", ISO/IEC 13818-3:1998, April 1998.
[NEW-ASN1] ITU-T, "Information technology -- Abstract Syntax Notation
One (ASN.1): Specification of basic notation", ITU-T
Recommendation X.680, ISO/IEC 8824-1:2021, February 2021,
<https://www.itu.int/rec/T-REC-X.680>.
[RFC1952] Deutsch, P., "GZIP file format specification version 4.3",
RFC 1952, DOI 10.17487/RFC1952, May 1996,
<https://www.rfc-editor.org/info/rfc1952>.
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046,
DOI 10.17487/RFC2046, November 1996,
<https://www.rfc-editor.org/info/rfc2046>.
[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>.
[RFC2397] Masinter, L., "The "data" URL scheme", RFC 2397,
DOI 10.17487/RFC2397, August 1998,
<https://www.rfc-editor.org/info/rfc2397>.
[RFC3003] Nilsson, M., "The audio/mpeg Media Type", RFC 3003,
DOI 10.17487/RFC3003, November 2000,
<https://www.rfc-editor.org/info/rfc3003>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>.
[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>.
[RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying
Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646,
September 2009, <https://www.rfc-editor.org/info/rfc5646>.
[RFC5755] Farrell, S., Housley, R., and S. Turner, "An Internet
Attribute Certificate Profile for Authorization",
RFC 5755, DOI 10.17487/RFC5755, January 2010,
<https://www.rfc-editor.org/info/rfc5755>.
[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>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", STD 97, RFC 9110,
DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/info/rfc9110>.
[SVGT] World Wide Web Consortium, "Scalable Vector Graphics (SVG)
Tiny 1.2 Specification", W3C REC-SVGTiny12-20081222,
December 2008,
<http://www.w3.org/TR/2008/REC-SVGTiny12-20081222/>.
[ISO19005] ISO, "Document management -- Electronic document file
format for long-term preservation -- Part 1: Use of PDF
1.4 (PDF/A-1)", ISO 19005-1:2005, October 2005.
[ISO32000] ISO, "Document management -- Portable document format --
Part 1: PDF 1.7", ISO 32000-1:2008, July 2008.
[OLD-ASN1] CCITT, "Specification of Abstract Syntax Notation One
(ASN.1)", CCITT Recommendation X.208, November 1988,
<https://www.itu.int/rec/T-REC-X.208/en>.
[PNGR] World Wide Web Consortium, "Media Type Registration for
image/png",
<https://www.iana.org/assignments/media-types/image/png>.
[RFC3709] Santesson, S., Housley, R., and T. Freeman, "Internet
X.509 Public Key Infrastructure: Logotypes in X.509
Certificates", RFC 3709, DOI 10.17487/RFC3709, February
2004, <https://www.rfc-editor.org/info/rfc3709>.
[RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the
Public Key Infrastructure Using X.509 (PKIX)", RFC 5912,
DOI 10.17487/RFC5912, June 2010,
<https://www.rfc-editor.org/info/rfc5912>.
[RFC6151] Turner, S. and L. Chen, "Updated Security Considerations
for the MD5 Message-Digest and the HMAC-MD5 Algorithms",
RFC 6151, DOI 10.17487/RFC6151, March 2011,
<https://www.rfc-editor.org/info/rfc6151>.
[RFC6170] Santesson, S., Housley, R., Bajaj, S., and L. Rosenthol,
"Internet X.509 Public Key Infrastructure -- Certificate
Image", RFC 6170, DOI 10.17487/RFC6170, May 2011,
<https://www.rfc-editor.org/info/rfc6170>.
[RFC6268] Schaad, J. and S. Turner, "Additional New ASN.1 Modules
for the Cryptographic Message Syntax (CMS) and the Public
Key Infrastructure Using X.509 (PKIX)", RFC 6268,
DOI 10.17487/RFC6268, July 2011,
<https://www.rfc-editor.org/info/rfc6268>.
[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
and P. Hoffman, "Specification for DNS over Transport
Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
2016, <https://www.rfc-editor.org/info/rfc7858>.
[RFC8118] Hardy, M., Masinter, L., Markovic, D., Johnson, D., and M.
Bailey, "The application/pdf Media Type", RFC 8118,
DOI 10.17487/RFC8118, March 2017,
<https://www.rfc-editor.org/info/rfc8118>.
[RFC9162] Laurie, B., Messeri, E., and R. Stradling, "Certificate
Transparency Version 2.0", RFC 9162, DOI 10.17487/RFC9162,
December 2021, <https://www.rfc-editor.org/info/rfc9162>.
[RFC9216] Gillmor, D. K., Ed., "S/MIME Example Keys and
Certificates", RFC 9216, DOI 10.17487/RFC9216, April 2022,
<https://www.rfc-editor.org/info/rfc9216>.
[RFC9230] Kinnear, E., McManus, P., Pauly, T., Verma, T., and C.A.
Wood, "Oblivious DNS over HTTPS", RFC 9230,
DOI 10.17487/RFC9230, June 2022,
<https://www.rfc-editor.org/info/rfc9230>.
[SVGR] World Wide Web Consortium, "Media Type Registration for
image/svg+xml", <https://www.iana.org/assignments/media-
types/image/svg+xml>.
[SVGZR] "A separate MIME type for svgz files is needed",
<https://github.com/w3c/svgwg/issues/701>.
This appendix contains two ASN.1 modules, both using the old syntax [OLD-ASN1].
この付録には、2つのASN.1モジュールが含まれており、どちらも古い構文[Old-ASN1]を使用しています。
The first ASN.1 module provides the syntax for the logotype certificate extension. Only comments have changed in the module from [RFC3709] and the IMPORTS now come from [RFC5280].
最初のASN.1モジュールは、ロゴタイプ証明書拡張の構文を提供します。モジュールのコメントのみが[RFC3709]から変更されており、インポートは現在[RFC5280]から来ています。
The second ASN.1 module provides the certificate image object identifier. The module is unchanged from [RFC6170].
2番目のASN.1モジュールは、証明書の画像オブジェクト識別子を提供します。モジュールは[RFC6170]から変更されていません。
LogotypeCertExtn
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-logotype(22) }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
IMPORTS
AlgorithmIdentifier FROM PKIX1Explicit88 -- RFC 5280
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-explicit(18) };
-- Logotype Certificate Extension OID
id-pe-logotype OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-pe(1) 12 }
-- Logotype Certificate Extension Syntax
LogotypeExtn ::= SEQUENCE {
communityLogos [0] EXPLICIT SEQUENCE OF LogotypeInfo OPTIONAL,
issuerLogo [1] EXPLICIT LogotypeInfo OPTIONAL,
subjectLogo [2] EXPLICIT LogotypeInfo OPTIONAL,
otherLogos [3] EXPLICIT SEQUENCE OF OtherLogotypeInfo
OPTIONAL }
-- Note: At least one of the OPTIONAL components MUST be present
LogotypeInfo ::= CHOICE {
direct [0] LogotypeData,
indirect [1] LogotypeReference }
LogotypeData ::= SEQUENCE {
image SEQUENCE OF LogotypeImage OPTIONAL,
audio [1] SEQUENCE OF LogotypeAudio OPTIONAL }
-- Note: At least one of the OPTIONAL components MUST be present
LogotypeImage ::= SEQUENCE {
imageDetails LogotypeDetails,
imageInfo LogotypeImageInfo OPTIONAL }
LogotypeAudio ::= SEQUENCE {
audioDetails LogotypeDetails,
audioInfo LogotypeAudioInfo OPTIONAL }
LogotypeDetails ::= SEQUENCE {
mediaType IA5String, -- Media type name and optional
-- parameters
logotypeHash SEQUENCE SIZE (1..MAX) OF HashAlgAndValue,
logotypeURI SEQUENCE SIZE (1..MAX) OF IA5String }
LogotypeImageInfo ::= SEQUENCE {
type [0] LogotypeImageType DEFAULT color,
fileSize INTEGER, -- In octets, 0=unspecified
xSize INTEGER, -- Horizontal size in pixels
ySize INTEGER, -- Vertical size in pixels
resolution LogotypeImageResolution OPTIONAL,
language [4] IA5String OPTIONAL } -- RFC 5646 Language Tag
LogotypeImageType ::= INTEGER { grayScale(0), color(1) }
LogotypeImageResolution ::= CHOICE {
numBits [1] INTEGER, -- Resolution in bits per pixel
tableSize [2] INTEGER } -- Number of colors or grey tones
LogotypeAudioInfo ::= SEQUENCE {
fileSize INTEGER, -- In octets, 0=unspecified
playTime INTEGER, -- In milliseconds, 0=unspecified
channels INTEGER, -- 0=unspecified,
-- 1=mono, 2=stereo, 4=quad
sampleRate [3] INTEGER OPTIONAL, -- Samples per second
language [4] IA5String OPTIONAL } -- RFC 5646 Language Tag
OtherLogotypeInfo ::= SEQUENCE {
logotypeType OBJECT IDENTIFIER,
info LogotypeInfo }
LogotypeReference ::= SEQUENCE {
refStructHash SEQUENCE SIZE (1..MAX) OF HashAlgAndValue,
refStructURI SEQUENCE SIZE (1..MAX) OF IA5String }
-- Places to get the same LogotypeData
-- image or audio object
-- Note: The referenced LogotypeData binary file contains a
-- DER-encoded LogotypeData type
HashAlgAndValue ::= SEQUENCE {
hashAlg AlgorithmIdentifier,
hashValue OCTET STRING }
-- Other logotype type OIDs
id-logo OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) 20 }
id-logo-loyalty OBJECT IDENTIFIER ::= { id-logo 1 }
id-logo-background OBJECT IDENTIFIER ::= { id-logo 2 }
END
CERT-IMAGE-MODULE { iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-logotype-certimage(68) }
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
EXPORTS ALL; -- export all items from this module
id-logo-certImage OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-logo(20) 3 }
END
Some developers like to use the latest version of ASN.1 standards. This appendix provides an ASN.1 module to assist in that goal. It uses the ASN.1 syntax defined in [NEW-ASN1], and it follows the conventions established in [RFC5912] and [RFC6268].
一部の開発者は、ASN.1標準の最新バージョンを使用することを好みます。この付録は、その目標を支援するASN.1モジュールを提供します。[new-asn1]で定義されているasn.1構文を使用し、[rfc5912]および[rfc6268]で確立された規則に従います。
This ASN.1 module incorporates the module from [RFC3709] and the module from [RFC6170].
このASN.1モジュールには、[RFC3709]のモジュールと[RFC6170]のモジュールが組み込まれています。
Note that [NEW-ASN1] was published in 2021, and all of the features used in this module are backward compatible with the specification that was published in 2002.
[New-ASN1]は2021年に公開されており、このモジュールで使用されるすべての機能は、2002年に公開された仕様と後方互換性があることに注意してください。
LogotypeCertExtn-2022
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-logotype-2022(107) }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
IMPORTS
EXTENSION
FROM PKIX-CommonTypes-2009 -- RFC 5912
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkixCommon-02(57) }
AlgorithmIdentifier{}, DIGEST-ALGORITHM
FROM AlgorithmInformation-2009
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-algorithmInformation-02(58) } ;
-- Logotype Certificate Extension
ext-logotype EXTENSION ::= {
SYNTAX LogotypeExtn
IDENTIFIED BY id-pe-logotype }
-- Logotype Certificate Extension OID
id-pe-logotype OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-pe(1) 12 }
-- Logotype Certificate Extension Syntax
LogotypeExtn ::= SEQUENCE {
communityLogos [0] EXPLICIT SEQUENCE OF LogotypeInfo OPTIONAL,
issuerLogo [1] EXPLICIT LogotypeInfo OPTIONAL,
subjectLogo [2] EXPLICIT LogotypeInfo OPTIONAL,
otherLogos [3] EXPLICIT SEQUENCE OF OtherLogotypeInfo
OPTIONAL }
-- At least one of the OPTIONAL components MUST be present
( WITH COMPONENTS { ..., communityLogos PRESENT } |
WITH COMPONENTS { ..., issuerLogo PRESENT } |
WITH COMPONENTS { ..., subjectLogo PRESENT } |
WITH COMPONENTS { ..., otherLogos PRESENT } )
LogotypeInfo ::= CHOICE {
direct [0] LogotypeData,
indirect [1] LogotypeReference }
LogotypeData ::= SEQUENCE {
image SEQUENCE OF LogotypeImage OPTIONAL,
audio [1] SEQUENCE OF LogotypeAudio OPTIONAL }
-- At least one image component MUST be present
( WITH COMPONENTS { ..., image PRESENT } )
LogotypeImage ::= SEQUENCE {
imageDetails LogotypeDetails,
imageInfo LogotypeImageInfo OPTIONAL }
LogotypeAudio ::= SEQUENCE {
audioDetails LogotypeDetails,
audioInfo LogotypeAudioInfo OPTIONAL }
LogotypeDetails ::= SEQUENCE {
mediaType IA5String, -- Media type name and optional
-- parameters
logotypeHash SEQUENCE SIZE (1..MAX) OF HashAlgAndValue,
logotypeURI SEQUENCE SIZE (1..MAX) OF IA5String }
LogotypeImageInfo ::= SEQUENCE {
type [0] LogotypeImageType DEFAULT color,
fileSize INTEGER, -- In octets, 0=unspecified
xSize INTEGER, -- Horizontal size in pixels
ySize INTEGER, -- Vertical size in pixels
resolution LogotypeImageResolution OPTIONAL,
language [4] IA5String OPTIONAL } -- RFC 5646 Language Tag
LogotypeImageType ::= INTEGER { grayScale(0), color(1) }
LogotypeImageResolution ::= CHOICE {
numBits [1] INTEGER, -- Resolution in bits
tableSize [2] INTEGER } -- Number of colors or grey tones
LogotypeAudioInfo ::= SEQUENCE {
fileSize INTEGER, -- In octets, 0=unspecified
playTime INTEGER, -- In milliseconds, 0=unspecified
channels INTEGER, -- 0=unspecified
-- 1=mono, 2=stereo, 4=quad
sampleRate [3] INTEGER OPTIONAL, -- Samples per second
language [4] IA5String OPTIONAL } -- RFC 5646 Language Tag
OtherLogotypeInfo ::= SEQUENCE {
logotypeType OBJECT IDENTIFIER,
info LogotypeInfo }
LogotypeReference ::= SEQUENCE {
refStructHash SEQUENCE SIZE (1..MAX) OF HashAlgAndValue,
refStructURI SEQUENCE SIZE (1..MAX) OF IA5String }
-- Places to get the same LogotypeData
-- image or audio object
-- Note: The referenced LogotypeData binary file contains a
-- DER-encoded LogotypeData type
HashAlgAndValue ::= SEQUENCE {
hashAlg AlgorithmIdentifier{DIGEST-ALGORITHM, {...}},
hashValue OCTET STRING }
-- Other logotype type OIDs
id-logo OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) 20 }
id-logo-loyalty OBJECT IDENTIFIER ::= { id-logo 1 }
id-logo-background OBJECT IDENTIFIER ::= { id-logo 2 }
id-logo-certImage OBJECT IDENTIFIER ::= { id-logo 3 }
END
The following example displays a logotype certificate extension containing one issuer organization logotype using direct addressing. The issuer organization logotype image is of the type image/gif. The logotype image is referenced through one URI, and the image is hashed with SHA-256. This example is changed from [RFC3709] to use SHA-256 instead of SHA-1.
次の例には、直接アドレス指定を使用した1つの発行者組織ロゴタイプを含むロゴタイプ証明書拡張機能が表示されます。発行者組織のロゴタイプイメージは、タイプ画像/GIFです。ロゴタイプの画像は1つのURIを介して参照され、画像はSHA-256でハッシュされます。この例は、[RFC3709]からSHA-1の代わりにSHA-256を使用するように変更されます。
The values on the left are the ASN.1 tag (in hexadecimal) and the length (in decimal).
左の値は、asn.1タグ（16進数）と長さ（10進数）です。
30 122: SEQUENCE {
06 8: OBJECT IDENTIFIER logotype (1 3 6 1 5 5 7 1 12)
04 110: OCTET STRING, encapsulates {
30 108: SEQUENCE {
A1 106: [1] {
A0 104: [0] {
30 102: SEQUENCE {
30 100: SEQUENCE {
30 98: SEQUENCE {
16 9: IA5String 'image/gif'
30 49: SEQUENCE {
30 47: SEQUENCE {
30 11: SEQUENCE {
06 9: OBJECT IDENTIFIER
: sha-256 (2 16 840 1 101 3 4 2 1)
: }
04 32: OCTET STRING
: 6A 58 50 2E 59 67 F9 DD D1 8A FE BD 0D B1 FE 60
: A5 13 1B DF 0F B2 BE F0 B5 73 45 50 BA 1B BF 19
: }
: }
30 34: SEQUENCE {
16 32: IA5String 'http://logo.example.com/logo.gif'
: }
: }
: }
: }
: }
: }
: }
: }
: }
The following example displays a logotype certificate extension containing one issuer organization logotype using direct addressing. The issuer organization logotype image is of the type image/jpeg. The logotype image is referenced through one URI, and the image is hashed with SHA-256.
次の例には、直接アドレス指定を使用した1つの発行者組織ロゴタイプを含むロゴタイプ証明書拡張機能が表示されます。発行者組織のロゴタイプ画像は、タイプ画像/jpegです。ロゴタイプの画像は1つのURIを介して参照され、画像はSHA-256でハッシュされます。
The values on the left are the ASN.1 tag (in hexadecimal) and the length (in decimal).
左の値は、asn.1タグ（16進数）と長さ（10進数）です。
30 124: SEQUENCE {
06 8: OBJECT IDENTIFIER logotype (1 3 6 1 5 5 7 1 12)
04 112: OCTET STRING, encapsulates {
30 110: SEQUENCE {
A1 108: [1] {
A0 106: [0] {
30 104: SEQUENCE {
30 102: SEQUENCE {
30 100: SEQUENCE {
16 10: IA5String 'image/jpeg'
30 49: SEQUENCE {
30 47: SEQUENCE {
30 11: SEQUENCE {
06 9: OBJECT IDENTIFIER
: sha-256 (2 16 840 1 101 3 4 2 1)
: }
04 32: OCTET STRING
: 1E 8F 96 FD D3 50 53 EF C6 1C 9F FC F0 00 2E 53
: B4 9C 24 9A 32 C5 E9 0C 2C 39 39 D3 AD 6D A9 09
: }
: }
30 35: SEQUENCE {
16 33: IA5String 'http://logo.example.com/logo.jpeg'
: }
: }
: }
: }
: }
: }
: }
: }
: }
The following example displays a logotype certificate extension containing one subject organization logotype using direct addressing. The subject organization logotype image uses image/svg+xml+gzip. The logotype image is embedded in the certificate extension with a "data:" URI, and the image is hashed by SHA-256. This technique produces a large certificate extension but offers reduced latency and improved privacy.
次の例には、直接アドレス指定を使用して1つのサブジェクト組織ロゴタイプを含むロゴタイプ証明書拡張機能が表示されます。サブジェクト組織ロゴタイプイメージは、画像/SVG XML GZIPを使用します。ロゴタイプの画像は、「データ： "uri、および画像がSHA-256によってハッシュされている「データ」を使用して証明書拡張機能に埋め込まれています。この手法では、大規模な証明書拡張機能が生成されますが、レイテンシの削減とプライバシーの改善を提供します。
The values on the left are the ASN.1 tag (in hexadecimal) and the length (in decimal).
左の値は、asn.1タグ（16進数）と長さ（10進数）です。
30 2148: SEQUENCE {
06 8: OBJECT IDENTIFIER logotype (1 3 6 1 5 5 7 1 12)
04 2134: OCTET STRING, encapsulates {
30 2130: SEQUENCE {
A2 2126: [2] {
A0 2122: [0] {
30 2118: SEQUENCE {
30 2114: SEQUENCE {
30 2110: SEQUENCE {
16 18: IA5String 'image/svg+xml+gzip'
30 49: SEQUENCE {
30 47: SEQUENCE {
30 11: SEQUENCE {
06 9: OBJECT IDENTIFIER
: sha-256 (2 16 840 1 101 3 4 2 1)
: }
04 32: OCTET STRING
: C5 AC 94 1A 0A 25 1F B3 16 6F 97 C5 52 40 9B 49
: 9E 7B 92 61 5A B0 A2 6C 19 BF B9 D8 09 C5 D9 E7
: }
: }
30 2035: SEQUENCE {
16 2031: IA5String
: 'data:image/svg+xml+gzip;base64,H4sICIGpy2EAA2xvZ'
: '28tY29weS5zdmcApVbbbhs3EH3nV0y3Lw2Q9fK2JLewHDROU'
: 'BRo2iBxW+RRlTa2UFkypIWV5ut7zlB2UqF9cuLlUktyLmfOz'
: 'PD8xafbtdyPu/1qu5k17sw2sp/mm+V8vd2Ms2azbV5cmPNvX'
: 'v16efXh7WvZ31/L299e/vzTpTRt1/0RLrvu1dUref/7j+Ktd'
: 'Xawsete/9IYaW6m6e77rjscDmeHcLbdXXdX7zpu6t69vmxxo'
: 'n08AREdRDt7tpyWDRRSz7+tgp2b/ew/hEKI5WGoPKyW082s8'
: 'SmeWf13NzVyM66ub6ZZk+xXH+9X4+Hl9tOssWLly3553ARpd'
: '7txP+7uxx/2d+NiejefVttZ8+nNavkBj9yO40RLb8dpvpxP8'
: 'wtzuRvn07iUP/+Wu+20my9GcWfOPpfDbjVN44YLb8dp3Mn7c'
: 'b3aXGNCAICCc+a8+yLo/FpwfLP/uN3dzhqdriH5uwfbnj9a+'
: 'Uz2i/maK66utA+zZ435uFqvZ823R38Q1t32Lw3pZqThd/PpR'
: 'paz5o2LNkocvCzaIm0vrQvSpog359lLy3my0ga+e3Hp+B4In'
: 'jVFPD9awdhnrGEFW30Sl/Pnpvta2QBVxUEVxFbJ2VUFfYC01'
: 'pUs+O4GK84V/k6CHUFyhvhiDVQF8Y5aPDbmnsrXbS74DANjg'
: 'uwgENZLPwjUYVTRJQgEpiLR0ctiWj+Ig8rCvZAArxKExEEWM'
: 'JLqMA1F+ggnsQDXgpQeomJPCVhtCRycNrAWxgAI+g1Qsr6IU'
: 'xlomBswjydYBEgOeVCDoRreBjiFjX2SdSA60BP5DgQM63xoP'
: 'lWHbNq+egAEeAzxyNAdCQz+sDEMOhaGisKJdSlS6gtWWm4M1'
: 'rQwP0egEBIhhFLoXuCJhR4mT5RJBaiLKqqFROUEzYr1idG0g'
: 'ahwCzEnk+AMJLdp0FevQQ6VZ+SKOwGlOIJOh1MVjo0eB6DRA'
: '10SRpSY6il/eFFKAm+MKSIWNFqSo4OFnORfwH5wJHCMNM0ql'
: 'DRlcIwUEkDlgiSBhiEpBgMKOx5FdAYqI3KYewKKkAItTABTk'
: 'p5khI86kgbOgRywEBR0VGcwAjf8t9wqvdUMG6gLAbI0QQ8Cb'
: 'zCTtCSn/DEhCbm++duQaiRG1mQkdWHnminHA+r5wpLvsJbCA'
: 'LUKsDW5NAj43J+AD5vpfamUzJqiRJACmCWwIMhQq4HmYGKai'
: 'iJPmIvpS80UzTtAjdSraApQZogslgFcJHw0y5WoEXDYr/aTq'
: 'fxk2qhcg3z6ETQL+S18llvHOZQvlEOVEVpzqCozE9V6JZhh/'
: 'lCslg7mUFY4AR7IlcApmgV6gz3DCSDe56fQ0SRS7el0NJWO8'
: 'mQ6mkc6ylPpaL7QUZ5IR/M/dEwoJiEp+L6iT4cdSyIp4ljDk'
: 'oaZpQlgMoz0ApahjTiTWbZYu9v+MUqVjY61j2Bxr68bPF3uS'
: '1232qAyAQDMhr4MRyVZq5l2QcuwgY/oTozbgoIKycH+yQxhz'
: 'QsPJQ/ne9OmRKvYH1AeKA/EQRtzrmaYUiHUhpJOW4breSaxZ'
: '/TVc3ZAQJKOagAJiw6pRHVkBMIBa5E+SUMWi0ZNW1Rfn/xQX'
: 'ywHXyMHN5G8WF6gZ2IVjANHMIJQ1lAJQE8MJjZHJiUtQZAWz'
: 'mkisDywTVWSqLkkQG2NNB3wwyaerqRGLNKpvwUOhaQFiYcqv'
: 'iSjvp1n8WnRRzXFs9IXDxiiDd8HU/ROoAGn9+QgTPEVu6HaN'
: '6i0VPuv1SCzwyZeHwBA1EjFYoAk2jJ3OFeJ5Gp1E+3Dlf3Aj'
: '70bbvmag5oyKHunVyGPq6+EnvTua/JUn3iadMHlqUapsK2T8'
: 'SwCBJUF1JnEmhu0ntBthJoQpZqumsBk5mA1hRc0LR5ZFerdj'
: 'ksaCqt3IUWXcXW16vb6xdWyHLTgCaKXWKUKK1kOp9HK5B3EL'
: 'jSdXb0loB5RYtS01L6h9yTPW51Wpqwgosr5I927aw6401+Yf'
: 'wDria4WoQwAAA=='
: }
: }
: }
: }
: }
: }
: }
: }
: }
The following example displays a logotype certificate extension containing one certificate image logotype using direct addressing. The certificate image logotype uses image/svg+xml+gzip. The logotype image is embedded in the certificate extension with a "data:" URI, and the image is hashed by SHA-256. This example contains the image from Appendix B of [RFC6170]; however, the media type used here is explicit about the use of GZIP compression [RFC1952].
次の例には、直接アドレス指定を使用して1つの証明書イメージロゴタイプを含むロゴタイプ証明書拡張機能が表示されます。証明書の画像ロゴタイプは、画像/SVG XML GZIPを使用します。ロゴタイプの画像は、「データ： "uri、および画像がSHA-256によってハッシュされている「データ」を使用して証明書拡張機能に埋め込まれています。この例には、[RFC6170]の付録Bの画像が含まれています。ただし、ここで使用されるメディアタイプは、GZIP圧縮の使用について明示的です[RFC1952]。
The values on the left are the ASN.1 tag (in hexadecimal) and the length (in decimal).
左の値は、asn.1タグ（16進数）と長さ（10進数）です。
30 2902: SEQUENCE {
06 8: OBJECT IDENTIFIER logotype (1 3 6 1 5 5 7 1 12)
04 2888: OCTET STRING, encapsulates {
30 2884: SEQUENCE {
A3 2880: [3] {
30 2876: SEQUENCE {
30 2872: SEQUENCE {
06 8: OBJECT IDENTIFIER '1 3 6 1 5 5 7 20 3'
A0 2858: [0] {
30 2854: SEQUENCE {
30 2850: SEQUENCE {
30 2846: SEQUENCE {
16 18: IA5String 'image/svg+xml+gzip'
30 49: SEQUENCE {
30 47: SEQUENCE {
30 11: SEQUENCE {
06 9: OBJECT IDENTIFIER
: sha-256 (2 16 840 1 101 3 4 2 1)
: }
04 32: OCTET STRING
: 83 14 B3 26 9B D3 8B 0B 2A E6 6E 42 74 E2 A7 57
: 7A 40 B7 E1 2E 53 42 44 CC 7C AE 14 68 1B 0E B6
: }
: }
30 2771: SEQUENCE {
16 2767: IA5String
: 'data:image/svg+xml+gzip;base64,H4sICLXutU0AA0Nlc'
: 'nRJbWFnZURlbW8uc3ZnANVaW2/bOBZ+n19BqBigwdoS7xK9j'
: 'meapB0EWHQHzez2WZZoR1tZMiQ5jvvr95CSL7Gl1Em8C9d9i'
: 'ERSPOd85+O5EB3+9jhL0YMuyiTPLh3iYgfpLMrjJJteOv/66'
: '1M/cFBZhVkcpnmmL50sd34b/TIsH6YoiS+da11UySSJwkqj2'
: '1k41Q6CDbNyUMSTS+e+quYDz1sul+6SuXkx9YhSysPUo7QPK'
: '/rlKqvCx35Wvmu+a/uGYow9EOigh0Qvr/LHSwcjjDjGiGHQ9'
: '14n0/sKlMf4Vwctk7i6X7/sGEYdNA5L/WeRT5IUDKmSbLVWN'
: 'oo2cqNCh1XyoKN8Nsuz0iqwVW8Qb1fOF0Vqp+PI06me6awqP'
: 'eISzxn9goYzXYVxWIUWpfWLCMwcGoLpgy83n8wzGkbR4Gtef'
: 'ENmMBznC7DEroKpOBpM8mIWVqPEYGtA+BvoMfS2E5uF1Wqu7'
: 'R6FLvNFEelWReNolpiV3l2VpGntMW9nk6RKdf0+9BrFrMbeV'
: 'uWhtzbHvMR6UlobPyVpBWjXBk7six2vH5nCwY6nXCo5xb7Yu'
: 'svFVPqCOGh16fSxSxglmPkScLfvmDDmC4FlDc1wov8IF2WZh'
: 'NlVumgEPRliimDD3PhGPyTgUUMC6lKqKAjxaptq1boUJvQFs'
: 'vi+LOJyxZkPE/vCwHuAmXmoj1AarnRBatzqkbv7cK5Ls2ORf'
: 'wM/vsOG5lURZqXxOnDXPKZw5t5jVzIhFKO0B6D6hARSXDR6F'
: 'zqq7H7mQeJAOQiUSPvFIrUHOfuui3zrFI5dYVeAmpcOcOb9u'
: '63vLjae4kYX4yRifYPrTa2SlMigYdO+cEWeGADMLZLH96SH4'
: 'R9xRYApl6q3Y02f+NzlRAl+cZSKhB6qSIVa80fsqMnWOqZJp'
: 'msXwAPoyNaQ95uNIGasKPwhxGzQzOXzMIIzBKabmLIil470z'
: 'fSjWWn+kvpvLQ9g1l3yRIc8gukz0uysEcakcDfy3KMk+l0SO'
: 'XlOopltJL7EPtUlzZfP4tnM70k8xkKCySt92MwfIXPoTe0pn'
: 'u4dYbp7hJ/kxWySN0ey0o/1qbiCsxDXJMWWo37QekBcAUFPS'
: 'GkPCnUJF5wwBacDK5cGlEp4BC2lYoJcrNNGVc7DzIqxT4CKs'
: 'PlrAG8mL8whRejiQe9EmImIAoz3sds9NxP4RZEzugqzb7c3Q'
: '89u3WQKY9aegbsA/AUJB/bJs6pfJt9BHFEuk5DWITzOH5uZS'
: 'ThLUsDjQ5GE6RMsyihMTaQLfA6BIiAQMAhnHHN1sd61WtUhD'
: 'VJiuhkrdBXd740+hLB9Vm1HjQe4ywLOBLWOMMiyQAXNB8sm9'
: 'Gx2qdGgGkMG6wY8aLfqgH4dfnmrVc+pPrE/Z/QnZOs8C1Okb'
: '2/ggwLdxlDC1D6DFPZDD98txv8xQf5TEc7Ax6ZyaDf6BC4Sy'
: 'lWKCMqtizp80+UMchATal63qHq0M3ZTs83Ob/XO6LYsFzpGV'
: 'Y5+iLxdWvwY+NaKoR/0iJIXL3dBjT2hG+wO+NXm53XStSh1e'
: 'ogfeojV35BTOaqh/cmPUe2Mdp91pQp2CjWOO2k7OamhjU1HB'
: '3DLGm66n6iajz4bqn2oICmNFxDR/x2mC5s+rKhlkUA3Ne3P8'
: 'lgP0qJfjf9uvu+HWXSfFwNoH4uqGUmTadYMtOc7yjEEd9EUh'
: 'kwEEOcDSHKQ+yhnSvUYRH8miQo2FK5TCjWZZGWKB8iHPud16'
: 'wApnCvTOzjIFAj9TQdCxa+ddOTizaa1xJvD0qMrKx+Ydaj6i'
: 'wJQG0vaSdYWpTv4HwVRAP3Z6ONjOJunEIeKRVmhujpA2+wPm'
: 'QR9WFQAFhh9bGQzFEXX+WwOnXq8pV35P2Acdn0pGebcMg7Og'
: 'QKaEdOKEAkFlk/9HuEKGBVwucc4AjnJ/LBYU09hVwWY1F0Hl'
: 'BUC2lbyIuYF58O8p+adMwUt9YAoX/IwRtAC9NAdBAyGuEB3V'
: 'R59u8/TGYx9/Xjz8bPB/Z/F9B0SghBK+4xxfiwtr0GXECqed'
: 'QQ9PRVpEAQ+26MidbGSmPm8RwRzcQsT17EPSmoorH3+av4Jc'
: 'j78O/vIp/uzMEkHKAE6/F7VHHSj8HddR0Q3ymcGZfRVjwfmO'
: 'nNn3GuWR+FzhcPmPqiptHcayacT28T8j3Cs0/LQCwo6J2iYx'
: 'P4R58AsobjFegusoJhuq7VNS2evRPcqASvQki+gbkBYwETNP'
: 't/1A2pT6UErR1zMzUITZRvF5Lp5basO1fk2U4aBSjkji8quL'
: '3cDyW7TpI3unxezMcSTNhQJhfpGctKgKN2Amo7/7ShSev4oX'
: 'icPSYS+6GkCm9a1Qw3VEchCUA+z5HtTcbQhK6F14YFUp+Yn7'
: 'WgmzwpZCDf5DDiXT9B7U6RdHAHpdb7IqmLVjqZSLnTW61zjQ'
: '7/G7D3hm9E846uTDZoNMADmLlm7IG2ieXfUtu1US9TeNGUHi'
: 'bE9Nv//2jRJGZfQmK3v7ykJJOv1IXjBsDCPpmgWppe6sHxR3'
: 'KVSQKqp+WIqammuJbtqkxZmMHry4oS/9pLhdCXKq8uR0R+LD'
: 'EqCKRxqc5VXdvPvIP+ggwR0RkyBfO9iKZvrWGAKVdz31cuoc'
: 'voO/qemClFMYEFEH7oI+vpkek4s4bCMBqK+5mHQUlDpE/oyl'
: 'py+2/6pWXK31PEYagP04epV1cE50UMy6IQZeQM7+Ol74Z+eH'
: 'fpHNc7OjffQ/HeV0X8BopoDkGEkAAA='
: }
: }
: }
: }
: }
: }
: }
: }
: }
: }
: }
The following example contains a certificate for Alice; it is essentially a renewal of the certificate that appears in [RFC9216]. Of course, the serial number and issue dates are different. In addition, Alice's certificate now has a logotype certificate extension. The extension contains URLs for two community logotype images, both at fictional URLs. The extension also contains URLs for two subject organization logotype images, both at fictional URLs. An implementation would display at most three of these images, both of the community logotype images and one of the subject organization logotype images. Direct addressing is used for all of the images, and the images are hashed by SHA-256.
次の例には、アリスの証明書が含まれています。基本的に[RFC9216]に表示される証明書の更新です。もちろん、シリアル番号と発行日は異なります。さらに、アリスの証明書には、ロゴタイプ証明書拡張機能があります。拡張機能には、架空のURLでの2つのコミュニティロゴタイプ画像のURLが含まれています。拡張機能には、架空のURLでの2つのサブジェクト組織ロゴタイプ画像のURLも含まれています。実装は、コミュニティロゴタイプ画像と対象組織のロゴタイプ画像の1つの両方で、これらの画像の最大3つに表示されます。直接アドレス指定はすべての画像に使用され、画像はSHA-256によってハッシュされます。
-----BEGIN CERTIFICATE-----
MIIFpTCCBI2gAwIBAgITN0EFee11f0Kpolw69Phqzpqx1zANBgkqhkiG9w0BAQ0F
ADBVMQ0wCwYDVQQKEwRJRVRGMREwDwYDVQQLEwhMQU1QUyBXRzExMC8GA1UEAxMo
U2FtcGxlIExBTVBTIFJTQSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAgFw0yMjA2
MTUxODE4MThaGA8yMDUyMDkyNzA2NTQxOFowOzENMAsGA1UEChMESUVURjERMA8G
A1UECxMITEFNUFMgV0cxFzAVBgNVBAMTDkFsaWNlIExvdmVsYWNlMIIBIjANBgkq
hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtPSJ6Fg4Fj5Nmn9PkrYo0jTkfCv4TfA/
pdO/KLpZbJOAEr0sI7AjaO7B1GuMUFJeSTulamNfCwDcDkY63PQWl+DILs7GxVwX
urhYdZlaV5hcUqVAckPvedDBc/3rz4D/esFfs+E7QMFtmd+K04s+A8TCNO12DRVB
DpbP4JFD9hsc8prDtpGmFk7rd0q8gqnhxBW2RZAeLqzJOMayCQtws1q7ktkNBR2w
ZX5ICjecF1YJFhX4jrnHwp/iELGqqaNXd3/Y0pG7QFecN7836IPPdfTMSiPR+peC
rhJZwLSewbWXLJe3VMvbvQjoBMpEYlaJBUIKkO1zQ1Pq90njlsJLOwIDAQABo4IC
hDCCAoAwDAYDVR0TAQH/BAIwADAXBgNVHSAEEDAOMAwGCmCGSAFlAwIBMAEwHgYD
VR0RBBcwFYETYWxpY2VAc21pbWUuZXhhbXBsZTATBgNVHSUEDDAKBggrBgEFBQcD
BDAOBgNVHQ8BAf8EBAMCBsAwHQYDVR0OBBYEFLv2zLItHQYSHJeuKWqQENMgZmZz
MB8GA1UdIwQYMBaAFJEwjnwHFwyn8QkoZTYaZxxodvRZMIIB0AYIKwYBBQUHAQwE
ggHCMIIBvqCB4zCB4KBvMG0wazBpFgppbWFnZS9qcGVnMDEwLzALBglghkgBZQME
AgEEIK/8EBZGy1YltJl95Yk+rjqEb1oC04LW2o7U7vh8vR3tMCgWJmh0dHA6Ly93
d3cuZXhhbXBsZS5uZXQvaW1hZ2VzL2xvZ28uanBnoG0wazBpMGcWCWltYWdlL2dp
ZjAxMC8wCwYJYIZIAWUDBAIBBCCIkIGBrftmri9m0EmgTY6g7E6oZEI4WzZKvyyL
0unpZjAnFiVodHRwOi8vd3d3LmV4YW1wbGUub3JnL2xvZ28taW1hZ2UuZ2lmooHV
oIHSMIHPMGUwYxYJaW1hZ2UvZ2lmMDEwLzALBglghkgBZQMEAgEEIGpYUC5ZZ/nd
0Yr+vQ2x/mClExvfD7K+8LVzRVC6G78ZMCMWIWh0dHA6Ly93d3cuc21pbWUuZXhh
bXBsZS9sb2dvLmdpZjBmMGQWCmltYWdlL2pwZWcwMTAvMAsGCWCGSAFlAwQCAQQg
vct7dXJtjBszpCzerHly2krZ8nmEClhYas4vAoDq16UwIxYhaHR0cDovL3d3dy5z
bWltZS5leGFtcGxlL2xvZ28uanBnMA0GCSqGSIb3DQEBDQUAA4IBAQBbjdCNVFA/
emCc5uKX5WSPrdvRFZSs57SEhE0odxvhTrOs13VM8Om0TxhNJ0Pl6d9CJdbUxtFw
SSnSu9fnghDO7OZDJnPiIYLNY5eTTzY6sx85mde9TLaBTE7RZf0W7NV0hqDqcfM+
9HnQrU4TtPSvtPS5rr5SvqkaMM0k89bpbkgZlh9HH14+x+DIeT0dLythiXJvkVod
qEfyZTcdplQHQ4szWO7lsjmvHrUIbS1tdAJnah8AZRZfqiJEFeiUp06hvAWnPc3y
1TMwYI8onfwPIVzyT6YLgjiT6PuLwSB/wtlhI+vWfdINaHdotegjawLm/3jZ+ceN
tu39FvbV0uKJ
-----END CERTIFICATE-----
The following displays the logotype certificate extension from Alice's certificate. The values on the left are the ASN.1 tag (in hexadecimal) and the length (in decimal).
以下には、アリスの証明書からのロゴタイプ証明書延長を表示します。左の値は、asn.1タグ（16進数）と長さ（10進数）です。
30 464: SEQUENCE {
06 8: OBJECT IDENTIFIER logotype (1 3 6 1 5 5 7 1 12)
04 450: OCTET STRING, encapsulates {
30 446: SEQUENCE {
A0 227: [0] {
30 224: SEQUENCE {
A0 111: [0] {
30 109: SEQUENCE {
30 107: SEQUENCE {
30 105: SEQUENCE {
16 10: IA5String 'image/jpeg'
30 49: SEQUENCE {
30 47: SEQUENCE {
30 11: SEQUENCE {
06 9: OBJECT IDENTIFIER
: sha-256 (2 16 840 1 101 3 4 2 1)
: }
04 32: OCTET STRING
: AF FC 10 16 46 CB 56 25 B4 99 7D E5 89 3E AE 3A
: 84 6F 5A 02 D3 82 D6 DA 8E D4 EE F8 7C BD 1D ED
: }
: }
30 40: SEQUENCE {
16 38: IA5String 'http://www.example.net/images/logo.jpg'
: }
: }
: }
: }
: }
A0 109: [0] {
30 107: SEQUENCE {
30 105: SEQUENCE {
30 103: SEQUENCE {
16 9: IA5String 'image/gif'
30 49: SEQUENCE {
30 47: SEQUENCE {
30 11: SEQUENCE {
06 9: OBJECT IDENTIFIER
: sha-256 (2 16 840 1 101 3 4 2 1)
: }
04 32: OCTET STRING
: 88 90 81 81 AD FB 66 AE 2F 66 D0 49 A0 4D 8E A0
: EC 4E A8 64 42 38 5B 36 4A BF 2C 8B D2 E9 E9 66
: }
: }
30 39: SEQUENCE {
16 37: IA5String 'http://www.example.org/logo-image.gif'
: }
: }
: }
: }
: }
: }
: }
A2 213: [2] {
A0 210: [0] {
30 207: SEQUENCE {
30 101: SEQUENCE {
30 99: SEQUENCE {
16 9: IA5String 'image/gif'
30 49: SEQUENCE {
30 47: SEQUENCE {
30 11: SEQUENCE {
06 9: OBJECT IDENTIFIER
: sha-256 (2 16 840 1 101 3 4 2 1)
: }
04 32: OCTET STRING
: 6A 58 50 2E 59 67 F9 DD D1 8A FE BD 0D B1 FE 60
: A5 13 1B DF 0F B2 BE F0 B5 73 45 50 BA 1B BF 19
: }
: }
30 35: SEQUENCE {
16 33: IA5String 'http://www.smime.example/logo.gif'
: }
: }
: }
30 102: SEQUENCE {
30 100: SEQUENCE {
16 10: IA5String 'image/jpeg'
30 49: SEQUENCE {
30 47: SEQUENCE {
30 11: SEQUENCE {
06 9: OBJECT IDENTIFIER
: sha-256 (2 16 840 1 101 3 4 2 1)
: }
04 32: OCTET STRING
: BD CB 7B 75 72 6D 8C 1B 33 A4 2C DE AC 79 72 DA
: 4A D9 F2 79 84 0A 58 58 6A CE 2F 02 80 EA D7 A5
: }
: }
30 35: SEQUENCE {
16 33: IA5String 'http://www.smime.example/logo.jpg'
: }
: }
: }
: }
: }
: }
: }
: }
: }
This appendix summarizes the changes since [RFC3709]. The changes are:
この付録は、[RFC3709]以降の変更を要約しています。変更は次のとおりです。
* Combine RFCs 3709 and 6170 into one document, and encourage implementers to support the "data" URI scheme (data:...) that was originally specified in RFC 6170. Merging RFCs 3709 and 6170 led to many editorial changes throughout the document.
* RFCS 3709と6170を1つのドキュメントに組み合わせて、RFC 6170で最初に指定された「データ」URIスキーム（データ：...）をサポートするように実装者に奨励します。
* Drop SHA-1 as the mandatory-to-implement hash algorithm, and encourage use of the one-way hash function that is employed by the certificate signature algorithm.
* sha-1を必須から実装するハッシュアルゴリズムとしてドロップし、証明書署名アルゴリズムで採用されている一方向ハッシュ関数の使用を奨励します。
* RFC 3709 required client applications to support both direct and indirect addressing. This requirement is changed to SHOULD support both direct and indirect addressing to allow implementations to be more privacy preserving.
* RFC 3709は、直接および間接的なアドレス指定の両方をサポートするためにクライアントアプリケーションを必要としました。この要件は、実装をよりプライバシー保存にするために、直接的および間接的なアドレス指定の両方をサポートするために変更されます。
* Update the reference for language tags to be RFC 5646 instead of the now obsolete RFC 3066.
* 言語タグのリファレンスを、現在廃止されたRFC 3066の代わりにRFC 5646に更新します。
* Update the reference for the URI Generic Syntax to be RFC 3986 instead of the now obsolete RFC 2396.
* URI Generic構文の参照を、現在廃止されたRFC 2396の代わりにRFC 3986に更新します。
* Update the reference for the application/pdf media type to be RFC 8118 instead of the now obsolete RFC 3778.
* アプリケーション/PDFメディアタイプのリファレンスを、現在廃止されたRFC 3778の代わりにRFC 8118に更新します。
* No longer require support for the FTP scheme (ftp://...) URI.
* FTPスキーム（ftp：// ...）URIのサポートはもう必要ありません。
* Require support for the HTTP scheme (http://...) URI and the HTTPS scheme (https://...) URI.
* HTTPスキーム（http：// ...）uriおよびhttpsスキーム（https：// ...）uriのサポートが必要です。
* Provide syntax of the "data" URI scheme using modern ABNF.
* 最新のABNFを使用して、「データ」URIスキームの構文を提供します。
* Require support for the compressed SVG image format with the image/svg+xml+gzip media type.
* Image/SVG XML GZIPメディアタイプを使用して、圧縮されたSVG画像形式のサポートが必要です。
* Media types MUST follow the ABNF [RFC5234] that is provided in Section 8.3.1 of [RFC9110]. This change resolves Errata ID 2679.
* メディアタイプは、[RFC9110]のセクション8.3.1に記載されているABNF [RFC5234]に従う必要があります。この変更により、Errata ID 2679が解決されます。
* Remove the requirement that the LogotypeData file name have a file extension of ".LTD". This change resolves Errata ID 2325.
* logotypedataファイル名に「.ltd」のファイル拡張子があるという要件を削除します。この変更により、Errata ID 2325が解決されます。
* Encourage, instead of requiring, each logotype to be represented by at least one image.
* 各ロゴタイプを要求する代わりに、少なくとも1つの画像で表現することを奨励します。
* Encourage the inclusion of text-based audio data suitable for processing by a text-to-speech software using the media type of "text/plain;charset=UTF-8".
* メディアタイプの「Text/Plain; charset = utf-8」を使用して、テキストからスピーチへのソフトウェアによる処理に適したテキストベースのオーディオデータを含めることを奨励します。
* Encourage the use of dithering if an image needs to be scaled.
* 画像をスケーリングする必要がある場合は、ディザリングの使用を奨励します。
* Require that the logotype certificate extension not contain more than one certificate image logotype.
* ロゴタイプ証明書拡張機能には、複数の証明書イメージロゴタイプが含まれていないことが要求されます。
* Privacy-related topics that were previously discussed in the Security Considerations section are now covered in a separate Privacy Considerations section. Additional topics are covered in both sections.
* セキュリティに関する考慮事項セクションで以前に議論されたプライバシー関連のトピックについては、別のプライバシーに関する考慮事項セクションで説明しています。追加のトピックについては、両方のセクションで説明しています。
* Provide ASN.1 modules for both the older syntax [OLD-ASN1] and the most recent ASN.1 syntax [NEW-ASN1].
* 古い構文[Old-ASN1]と最新のASN.1構文[New-ASN1]の両方にASN.1モジュールを提供します。
* Provide additional references.
* 追加の参照を提供します。
* Provide additional examples.
* 追加の例を提供します。
* Several editorial changes to improve clarity.
* 明確さを改善するためのいくつかの編集上の変更。
* The example in Appendix B.1 was changed to use SHA-256 instead of SHA-1.
* 付録B.1の例は、SHA-1の代わりにSHA-256を使用するように変更されました。
* Acknowledgments from RFC 3709
* RFC 3709からの謝辞
* This document is the result of contributions from many professionals. The authors appreciate contributions from all members of the IETF PKIX Working Group. We extend a special thanks to Al Arsenault, David Cross, Tim Polk, Russel Weiser, Terry Hayes, Alex Deacon, Andrew Hoag, Randy Sabett, Denis Pinkas, Magnus Nystrom, Ryan Hurst, and Phil Griffin for their efforts and support.
* この文書は、多くの専門家からの貢献の結果です。著者は、IETF PKIXワーキンググループのすべてのメンバーからの貢献に感謝しています。アル・アルセノー、デビッド・クロス、ティム・ポーク、ラッセル・ワイザー、テリー・ヘイズ、アレックス・ディーコン、アンドリュー・ホーグ、ランディ・サベット、デニス・ピンカス、マグナス・ニシトロム、ライアン・ハースト、フィル・グリフィンの努力とサポートに感謝します。
* Russ Housley thanks the management at RSA Laboratories, especially Burt Kaliski, who supported the development of this specification. The vast majority of the work on this specification was done while Russ was employed at RSA Laboratories.
* Russ Housleyは、RSA Laboratories、特にこの仕様の開発を支援したBurt Kaliskiの経営陣に感謝します。この仕様の作業の大部分は、RUSがRSA研究所で採用されている間に行われました。
* Acknowledgments from RFC 6170
* RFC 6170からの謝辞
* The authors recognize valuable contributions from members of the PKIX working group, the CA Browser Forum, and James Manger, for their review and sample data.
* 著者は、レビューとサンプルデータについて、PKIXワーキンググループ、CAブラウザフォーラム、およびJames Mangerのメンバーからの貴重な貢献を認識しています。
* Additional Acknowledgments
* 追加の謝辞
* Combining RFCs 3709 and 6170 has produced an improved specification. The authors appreciate contributions from all members of the IETF LAMPS Working Group. We extend a special thanks to Alexey Melnikov for his guidance on media types. We extend a special thanks to Tim Geiser for his careful checking of the new examples in Appendices B.4 and B.5. We extend a special thanks to Corey Bonnell, Daniel Kahn Gillmor, Roman Danyliw, Paul Wouters, Paul Kyzivat, Shuping Peng, Sheng Jiang, Rob Wilton, Éric Vyncke, Donald Eastlake 3rd, and Dan Harkins for their careful review and helpful comments.
* RFCS 3709と6170を組み合わせることで、改善された仕様が生成されました。著者は、IETFランプワーキンググループのすべてのメンバーからの貢献に感謝しています。メディアタイプに関する彼のガイダンスについて、Alexey Melnikovに感謝します。付録B.4およびB.5の新しい例を注意深くチェックしてくれたTim Geiserに感謝します。Corey Bonnell、Daniel Kahn Gillmor、Roman Danyliw、Paul Wouters、Paul Kyzivat、Shuping Peng、Sheng Jiang、Rob Wilton、Eric Vyncke、Donald Eastlake 3、およびDan Harkinsに感謝します。
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
Trevor Freeman
Amazon Web Services
1918 8th Ave
Seattle, WA 98101
United States of America
Email: frtrevor@amazon.com
Leonard Rosenthol
Adobe
345 Park Avenue
San Jose, CA 95110
United States of America
Email: lrosenth@adobe.com