[要約] RFC 3709は、X.509証明書におけるロゴタイプの使用に関するガイドラインを提供しています。このRFCの目的は、証明書にロゴタイプを含めることで、ユーザーに対して信頼性と識別性を提供することです。
Network Working Group S. Santesson
Request for Comments: 3709 Microsoft
Category: Standards Track R. Housley
Vigil Security
T. Freeman
Microsoft
February 2004
Internet X.509 Public Key Infrastructure: Logotypes in X.509 Certificates
インターネットX.509公開キーインフラストラクチャ：X.509証明書のロゴタイプ
Status of this Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004). All Rights Reserved.
著作権（c）The Internet Society（2004）。無断転載を禁じます。
Abstract
概要
This document specifies a certificate extension for including logotypes in public key certificates and attribute certificates.
このドキュメントは、公開キーの証明書と属性証明書にロゴタイプを含めるための証明書拡張機能を指定します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Certificate-based Identification . . . . . . . . . . . . 3
1.2. Selection of Certificates. . . . . . . . . . . . . . . . 4
1.3. Combination of Verification Techniques . . . . . . . . . 5
1.4. Terminology. . . . . . . . . . . . . . . . . . . . . . . 6
2. Different types of logotypes in Certificates . . . . . . . . . 6
3. Logotype Data. . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Logotype Extension . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Extension Format . . . . . . . . . . . . . . . . . . . . 7
4.2. Other Logotypes. . . . . . . . . . . . . . . . . . . . . 11
5. Type of Certificates . . . . . . . . . . . . . . . . . . . . . 12
6. Use in Clients . . . . . . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations. . . . . . . . . . . . . . . . . . . . 13
8. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 15
9. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
10.1. Normative References . . . . . . . . . . . . . . . . . . 16
10.2. Informative References . . . . . . . . . . . . . . . . . 16
A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . . . . . . 17
B. Example Extension. . . . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 21
This specification supplements RFC 3280 [PKIX-1], which profiles X.509 [X.509] certificates and certificate revocation lists (CRLs) for use in the Internet.
この仕様は、インターネットで使用するためのX.509 [X.509]証明書と証明書の取り消しリスト（CRL）をプロファイルするRFC 3280 [PKIX-1]をサプリメントします。
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 IT structures.
証明書の基本機能は、公開鍵をエンティティ（主題）のIDに結合することです。厳密に技術的な視点から、この目標は、主題のアイデンティティをその公開鍵と一緒に署名することで達成できます。ただし、Public-Key Infrastructure（PKI）の技術は、最新のグローバルネットワークと異種IT構造のニーズを満たすために、この機能をはるかに超えた証明書を開発しました。
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, rather 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 web site.
- ユーザーがWebサイトの所有者を識別するWebサーバー識別。
- Peer e-mail exchange in B2B, 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 his 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 users 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 extension MUST NOT be an active component in automated certification path validation.
ロゴタイプは人間の解釈のみを目的としており、コンピューターベースの検証スキームに不適切なデータを含むため、ロゴタイプ拡張は自動認定パス検証のアクティブなコンポーネントであってはなりません。
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 RFC 3280 [PKIX-1].
自動化された認証パス検証により、定義されたポリシーに従ってエンドエンティティ証明書を検証できるかどうかが判断されます。この検証のアルゴリズムは、RFC 3280 [PKIX-1]で指定されています。
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 access control decisions. Automatic processing will make some access control 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 access control decisions. In the end, the human will decide whether or not to accept an executable email attachment, to release personal information, or 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 Security Considerations section.
体系的な処理と人間の処理が互いに干渉する状況がいくつかあります。これらの問題については、セキュリティ上の考慮事項セクションで説明します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [STDWORDS].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、BCP 14、RFC 2119 [stdwords]に記載されているように解釈される。
This specification defines the inclusion of three standard logotype types.
この仕様は、3つの標準ロゴタイプタイプを含めることを定義します。
1) Community logotype 2) Issuer organization logotype 3) Subject organization logotype
1) コミュニティロゴタイプ2）発行者組織ロゴタイプ3）サブジェクト組織ロゴタイプ
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).
コミュニティロゴタイプ - は、コミュニティの一般的なマークです。エンティティの識別と証明書の発行のためのサービス概念を識別します。多くの発行者は、コミュニティのロゴタイプを使用して、ローカルサービスの提供をグローバルに認識するために、グローバルコミュニティと共同ブランドを付けます。このタイプのコミュニティブランディングは、地元の独立したカード発行者にはグローバルに認められたブランド（VisaやMasterCardなど）が含まれるクレジットカードビジネスで非常に一般的です。
Issuer organization logotype - is a logotype representing the organization identified as part of the issuer name in the certificate.
発行者組織ロゴタイプ - は、証明書の発行者名の一部として特定された組織を表すロゴタイプです。
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.2 of this document.
標準のロゴタイプタイプに加えて、この仕様は、ロゴタイプの各クラスがオブジェクト識別子によって定義される他のロゴタイプタイプを含めることに対応します。オブジェクト識別子は、このドキュメントのセクション4.2で定義されている識別子を定義するか、識別子を定義できます。
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種類のロゴタイプデータを定義します。実装は画像データをサポートする必要があります。ただし、オーディオデータのサポートはオプションです。
There is no need to significantly increase the size of the certificate by including image and audio data of logotypes. Rather, a URI identifying the location to the logotype data and a one-way hash of the referenced data is included in the certificate.
ロゴタイプの画像とオーディオデータを含めることにより、証明書のサイズを大幅に増やす必要はありません。むしろ、ロゴタイプデータの場所を識別するURIと参照データの一方向のハッシュが証明書に含まれています。
Several image files, representing the same image in different formats, sizes, and color palates, may represent each logotype image. At least one of the image files representing a logotype SHOULD contain an image within the size range of 60 pixels wide by 45 pixels high, and 200 pixels wide by 150 pixels high.
異なる形式、サイズ、色の味覚で同じ画像を表すいくつかの画像ファイルは、各ロゴタイプの画像を表す場合があります。ロゴタイプを表す画像ファイルの少なくとも1つは、幅60ピクセルのサイズの範囲内の画像を、高さ45ピクセル、幅200ピクセルx 150ピクセルの画像を含める必要があります。
Several audio files may further represent the same audio sequence in different formats and resolutions. At least one of the audio files representing a logotype SHOULD have a play time between 1 and 30 seconds.
いくつかのオーディオファイルは、異なる形式と解像度で同じオーディオシーケンスをさらに表す場合があります。ロゴタイプを表すオーディオファイルの少なくとも1つは、1〜30秒の間の再生時間を持つ必要があります。
If a logotype of a certain type (as defined in section 2) is represented by more than one image file, then the image files MUST contain variants of roughly the same image. Likewise, if a logotype of a certain type is represented by more than one audio file, then the audio files MUST contain variants of the same audio information. A spoken message in different languages is considered a variation of the same audio information. Compliant applications MUST NOT display more than one of the images and MUST NOT play more than one of the audio sequences for any logotype type 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 file.
証明書に存在する各ロゴタイプは、少なくとも1つの画像データファイルで表される必要があります。
Applications SHOULD enhance processing and off-line functionality by caching logotype data.
アプリケーションは、ロゴタイプデータをキャッシュすることにより、処理とオフラインの機能を強化する必要があります。
This section specifies the syntax and semantics of the logotype extension.
このセクションでは、ロゴタイプ拡張の構文とセマンティクスを指定します。
The logotype extension MAY be included in public key certificates [PKIX-1] or attribute certificates [PKIX-AC]. The logotype extension MUST be identified by the following object identifier:
ロゴタイプの拡張機能は、公開キー証明書[PKIX-1]または属性証明書[PKIX-AC]に含まれる場合があります。ロゴタイプの拡張は、次のオブジェクト識別子によって識別される必要があります。
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. Clients MUST 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 files. Direct addressing supports cases where just one or a few alternative images and audio files are referenced.
直接アドレス指定には、証明書の各ロゴタイプに関する情報が含まれており、URISは画像ファイルとオーディオデータファイルを指しています。直接のアドレス指定は、1つまたはいくつかの代替画像とオーディオファイルが参照されるケースをサポートします。
The indirect addressing includes one reference to an external hashed data structure that contains information on the type, content, and location of each image and audio file. Indirect addressing supports cases where each logotype is represented by many alternative audio or image files.
間接アドレス指定には、各画像とオーディオファイルのタイプ、コンテンツ、および場所に関する情報を含む外部ハッシュされたデータ構造への1つの参照が含まれます。間接的なアドレス指定は、各ロゴタイプが多くの代替オーディオまたは画像ファイルで表されるケースをサポートします。
Both direct and indirect addressing accommodate alternative URIs to obtain exactly the same item. 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 URIs MUST use either the HTTP scheme (http://...) or the FTP scheme (ftp://...) [URI]. At least one URI in each sequence MUST use the HTTP scheme. Clients MUST support retrieval of referenced LogoTypeData with HTTP/1.1 [HTTP/1.1]. Clients MAY support retrieval using FTP [FTP].
直接および間接的なアドレス指定の両方が、まったく同じアイテムを取得するための代替URIに対応します。この複製の機会は、可用性を改善することを目的としています。したがって、クライアントが1つのURIからアイテムを取得できない場合、クライアントはシーケンスで別のURIを試す必要があります。すべてのURIは、HTTPスキーム（http：// ...）またはftpスキーム（ftp：// ...）[uri]を使用する必要があります。各シーケンスに少なくとも1つのURIがHTTPスキームを使用する必要があります。クライアントは、HTTP/1.1 [HTTP/1.1]を使用して、参照されたLogotypedataの取得をサポートする必要があります。クライアントは、FTP [FTP]を使用して検索をサポートできます。
The logotype 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, -- MIME 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
xSize INTEGER, -- Horizontal size in pixels
ySize INTEGER, -- Vertical size in pixels
resolution LogotypeImageResolution OPTIONAL,
language [4] IA5String OPTIONAL } -- RFC 3066 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
playTime INTEGER, -- In milliseconds
channels INTEGER, -- 1=mono, 2=stereo, 4=quad
sampleRate [3] INTEGER OPTIONAL, -- Samples per second
language [4] IA5String OPTIONAL } -- RFC 3066 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 "LTD" file
HashAlgAndValue ::= SEQUENCE {
hashAlg AlgorithmIdentifier,
hashValue OCTET STRING }
When using indirect addressing, the URI (refStructURI) pointing to the external data structure MUST point to a binary file containing the DER encoded data with the syntax LogotypeData. The referenced file name SHOULD include a file extension of "LTD".
間接アドレス指定を使用する場合、外部データ構造を指すURI（Refstructuri）は、Syntax Logotypedataを使用してDerエンコードされたデータを含むバイナリファイルを指す必要があります。参照されたファイル名には、「LTD」のファイル拡張子を含める必要があります。
At least one of the optional elements in the LogotypeExtn structure MUST be present. Avoid the use of otherLogos whenever possible.
LogotypeExtn構造の少なくとも1つのオプション要素が存在する必要があります。可能な限り他のロゴの使用を避けてください。
The LogotypeReference and LogotypeDetails structures explicitly identify one or more one-way hash functions employed to authenticate referenced data files. Clients MUST support the SHA-1 [SHS] one-way hash function, and clients MAY support other one-way hash functions. CAs MUST include a SHA-1 hash value for each referenced file, calculated on the whole file, and CAs MAY include other one-way 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 one-way hash function value does not match the one-way hash function value in the certificate extension.
LogotypereferenceおよびlogotypeDetails構造は、参照されたデータファイルを認証するために使用される1つまたは複数の一方向ハッシュ関数を明示的に識別します。クライアントは、SHA-1 [SHS]一方向ハッシュ関数をサポートする必要があり、クライアントは他の一方向ハッシュ関数をサポートする場合があります。CASには、ファイル全体で計算された参照ファイルごとにSHA-1ハッシュ値を含める必要があり、CASには他の一方向ハッシュ値が含まれる場合があります。クライアントは、識別された関数のいずれかを使用して一方向ハッシュ値を計算する必要があり、クライアントは、計算された一方向ハッシュ関数値が証明書拡張の一方向ハッシュ関数値と一致しない場合、ロゴタイプデータを破棄する必要があります。
A MIME type is used to specify the format of the file containing the logotype data. Implementations MUST support both the JPEG and GIF image formats (with MIME types of "image/jpeg" and "image/gif" [MEDIA], respectively). Animated images SHOULD NOT be used. Implementations that support audio MUST support the MP3 audio format (with a MIME type of "audio/mpeg" [AUDIO/MPEG]). MIME types MAY include parameters.
MIMEタイプは、ロゴタイプデータを含むファイルの形式を指定するために使用されます。実装は、JPEGおよびGIFイメージ形式の両方をサポートする必要があります（それぞれ「画像/JPEG」と「Image/GIF」[メディア]のMIMEタイプを使用）。アニメーション画像を使用しないでください。オーディオをサポートする実装は、MP3オーディオ形式（「Audio/MPEG」[Audio/MPEG]のMIMEタイプを使用）をサポートする必要があります。MIMEタイプにはパラメーターが含まれる場合があります。
When language is specified, the language tag MUST use the RFC 3066 [LANGCODES] syntax.
言語が指定されている場合、言語タグはRFC 3066 [langcodes]構文を使用する必要があります。
Logotype types defined in this specification are:
この仕様で定義されているロゴタイプタイプは次のとおりです。
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 to check subject organization logotypes or claims its issuer and community logotypes is outside the scope of this document.
対象組織と対象組織のロゴタイプとの関係、および発行者と発行者組織のロゴタイプまたはコミュニティロゴタイプのいずれかの関係は、発行者によって主張されている関係です。発行者が採用したポリシーと慣行は、サブジェクト組織のロゴタイプを確認するか、発行者とコミュニティのロゴタイプがこのドキュメントの範囲外であると主張しています。
Logotypes identified by otherLogos (as defined in 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.
これらのロゴタイプの意図された使用の条件とコンテキストは、ローカルクライアントアプリケーションの裁量で定義されます。
The following other logotype types are defined in this document:
次の他のロゴタイプタイプは、このドキュメントで定義されています。
- Loyalty logotype - Certificate Background logotype
- ロイヤルティロゴタイプ - 証明書のバックグラウンドロゴタイプ
OID Definitions:
OID定義：
id-logo OBJECT IDENTIFIER ::= { id-pkix 20 }
id-logo-loyalty OBJECT IDENTIFIER ::= { id-logo 1 }
id-logo-background OBJECT IDENTIFIER ::= { id-logo 2 }
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 extension MAY contain more than one Loyalty logotype.
ロイヤルティロゴタイプが存在する場合、証明書またはその使用に関連するロイヤルティプログラムに関連するロゴタイプを含める必要があります。証明書と特定されたロイヤルティプログラムとの関係は、このドキュメントの範囲を超えています。ロゴタイプの拡張には、複数のロイヤルティロゴタイプが含まれている場合があります。
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 extension MUST NOT contain more than one certificate background logotype.
証明書のバックグラウンドロゴタイプが存在する場合、証明書の背景画像として意図されたグラフィカルな画像、および/または証明書の一般的なオーディオシーケンスを含める必要があります。背景画像は、背景画像の上に置かれたときに黒いテキストを明確に読むことができなければなりません。ロゴタイプの拡張機能には、複数の証明書のバックグラウンドロゴタイプを含めてはなりません。
Logotypes MAY be included in public key certificates and attribute certificates at the discretion of the certificate issuer; however, logotypes MUST NOT be part of certification path validation or any type of automated processing. 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, rather the client MUST behave as though no logotype 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 the security considerations section).
認定パスが正常に検証された後、返信者は、証明書拡張を含むCAが証明書に含む情報を信頼します。クライアントソフトウェアは、そのような情報を使用することを選択できます。クライアントソフトウェアは無視できます。クライアントが提供されたロゴタイプをサポートできない場合、クライアントはエラーを報告してはなりません。むしろ、クライアントはロゴタイプ拡張機能が証明書に含まれていないかのように動作する必要があります。現在の標準では、相互認定CASが従属CASにプライベートエクステンションを含めることを制限するメカニズムを提供しません（セキュリティ上の考慮事項セクションを参照）。
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 extension.
クライアントは、ローカルポリシーに従って、ロゴタイプ拡張機能内のロゴタイプを1つ、または任意の数を表示することを選択できます。
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.
多くの場合、クライアントは良好なネットワーク接続を備えた環境で使用され、ネットワーク接続がほとんどまたはまったくない環境でも使用されます。たとえば、ラップトップコンピューターは高速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.
頼るパーティーソフトウェアが特定の証明書を正常に検証できない場合、その証明書に関連付けられたロゴタイプデータを表示してはなりません。
Implementations that simultaneously display multiple logotype types (subject organization, issuer, 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 2, and it refers to the type of entity or affiliation represented by the logotype, not the type of binary format.
複数のロゴタイプタイプ（サブジェクト組織、発行者、コミュニティなど）を同時に表示する実装は、画像と画像が表すロゴタイプのタイプとの間のバインディングに関して曖昧さがないことを確認する必要があります。「ロゴタイプタイプ」はセクション2で定義されており、バイナリ形式のタイプではなく、ロゴタイプで表されるエンティティまたは所属のタイプを指します。
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. Secondly, 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 graphic.
発行者が正しくチェックしていない、または正しくチェックできなかった、またはロゴタイプを含む不正またはパフォーマンスの発行者による証明書の不正な作成を防ぐことは不可能です。このような証明書は、ユーザーをソーシャルエンジニアにして証明書を受け入れるようにするために作成できます。したがって、ロゴタイプの作業に使用される前提は、証明書のロゴタイプグラフィックスが有効なパス内で正常に検証されている場合にのみ信頼されることです。したがって、検証に失敗した証明書の表現は、ロゴタイプグラフィックを使用していかなる方法でも強化されないことが不可欠です。
Logotype data is 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. This observation can potentially introduce privacy issues. 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. In cases where logotype data is not cashed, monitoring would reveal usage frequency. In cases where logotype data is cached, monitoring would reveal when a certain logotype image or audio sequence is used for the first time.
ロゴタイプデータは、必要なときにサーバーからフェッチされます。ネットワーク上のアクティビティを視聴することにより、オブザーバーは、特定のロゴタイプデータを含む証明書を使用しているクライアントを決定できます。この観察は、プライバシーの問題を潜在的に導入する可能性があります。クライアントはロゴタイプデータをローカルにキャッシュすることが期待されるため、ロゴタイプデータを含むサーバーへのネットワークトラフィックは、証明書が使用されるたびに生成されません。ロゴタイプデータが現金化されていない場合、監視は使用頻度を明らかにします。ロゴタイプデータがキャッシュされている場合、特定のロゴタイプ画像またはオーディオシーケンスが初めて使用されると監視が明らかになります。
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 RFC 3280 [PKIX-1] 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 polices. 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 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 extension.
RFC 3280 [PKIX-1]で定義されている証明書パス処理は、証明書にロゴタイプデータを含めることを制約しません。親CAは、認証パス検証を制約することができ、そのため、下位のCASは、限られた名前のスペースまたは特定の証明書ポリシーの外側のエンドエンティティに有効な証明書を発行できません。悪意のあるCAは、これらの名前とポリシーの要件に準拠し、それが発行する証明書に不適切なロゴタイプを含めることができます。これらの証明書は、認定パス検証アルゴリズムを渡すことになります。つまり、クライアントは証明書のロゴタイプを信頼します。従属CASを防止または制御するための技術的メカニズムがないため、ロゴタイプの拡張またはその内容を含むことを防止または制御するため、必要に応じて、親CAは法的契約を採用して、下位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-up behavior of subordinate CAs.
- 下位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のいくつかの側面を解決しなければなりません。そのため、発行者は関連するリスクを明確に特定して伝える必要があります。
Certificate extensions and attribute certificate extensions are identified by object identifiers (OIDs). The OID for the extension defined in this document was assigned from an arc delegated by the IANA to the PKIX Working Group. No further action by the IANA is necessary for this document or any anticipated updates.
証明書拡張および属性証明書拡張は、オブジェクト識別子（OID）によって識別されます。このドキュメントで定義されている拡張機能のOIDは、IANAからPKIXワーキンググループに委任されたアークから割り当てられました。このドキュメントまたは予想される更新には、IANAによるさらなるアクションは必要ありません。
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研究所で採用されている間に行われました。
[LANGCODES] Alvestrand, H., "Tags for Identification of Languages", BCP 47, RFC 3066, January 2001.
[Langcodes] Alvestrand、H。、「言語の識別のためのタグ」、BCP 47、RFC 3066、2001年1月。
[PKIX-1] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet X.509 Public Key Infrastructure: Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
[PKIX-1] Housley、R.、Polk、W.、Ford、W。and D. Solo、「インターネットX.509公開キーインフラストラクチャ：証明書および証明書取消リスト（CRL）プロファイル」、RFC 3280、2002年4月。
[PKIX-AC] Farrell, S. and R. Housley, "An Internet Attribute Certificate Profile for Authorization", RFC 3281, April 2002.
[PKIX-AC] Farrell、S。およびR. Housley、「認証のためのインターネット属性証明書プロファイル」、RFC 3281、2002年4月。
[SHS] Federal Information Processing Standards Publication (FIPS PUB) 180-1, Secure Hash Standard, 17 April 1995. [Supersedes FIPS PUB 180 dated 11 May 1993.]
[SHS]連邦情報処理標準出版（FIPS Pub）180-1、Secure Hash Standard、1995年4月17日。
[STDWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[stdwords] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[HTTP/1.1] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[HTTP/1.1] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach P.およびT. Berners-Lee、「HyperText Transfer Protocol-HTTP/1.1」、RFC 2616、1999年6月。
[FTP] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, October 1985.
[FTP] Postel、J。およびJ. Reynolds、「ファイル転送プロトコル」、STD 9、RFC 959、1985年10月。
[URI] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[URI] Berners-Lee、T.、Fielding、R。and L. Masinter、「ユニフォームリソース識別子（URI）：汎用構文」、RFC 2396、1998年8月。
[MEDIA] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[Media] Freed、N。and N. Borenstein、「多目的インターネットメールエクステンション（MIME）パート2：メディアタイプ」、RFC 2046、1996年11月。
[AUDIO/MPEG] Nilsson, M., "The audio/mpeg Media Type", RFC 3003, November 2000.
[Audio/MPEG] Nilsson、M。、「オーディオ/MPEGメディアタイプ」、RFC 3003、2000年11月。
[X.509] ITU-T Recommendation X.509 (2000) | ISO/IEC 9594-8:2001, Information technology - Open Systems Interconnection - The Directory: Public-key and attribute certificate frameworks
[X.509] ITU-T推奨X.509（2000）|ISO/IEC 9594-8：2001、情報技術 - オープンシステムの相互接続 - ディレクトリ：パブリックキーおよび属性証明書フレームワーク
APPENDIX A. ASN.1 Module
付録A. ASN.1モジュール
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 3280
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-explicit(18) };
-- Logotype Extension OID
-Logotype 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 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 }
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, -- MIME 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
xSize INTEGER, -- Horizontal size in pixels
ySize INTEGER, -- Vertical size in pixels
resolution LogotypeImageResolution OPTIONAL,
language [4] IA5String OPTIONAL } -- RFC 3066 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
playTime INTEGER, -- In milliseconds
channels INTEGER, -- 1=mono, 2=stereo, 4=quad
sampleRate [3] INTEGER OPTIONAL, -- Samples per second
language [4] IA5String OPTIONAL } -- RFC 3066 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 "LTD" file
-- Note: The content of referenced "LTD" files is defined by the
-- LogotypeData type
HashAlgAndValue ::= SEQUENCE {
hashAlg AlgorithmIdentifier,
hashValue OCTET STRING }
-- Other logotype type OIDs
- その他のロゴタイプタイプのOID
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
終わり
APPENDIX B. Example Extension
付録B.拡張機能の例
The following example displays a logotype extension containing one Issuer logotype using direct addressing. The issuer logotype image is of the type image/gif. The logotype image file is referenced through 1 URI and the image is hashed by one sha1 hash value.
次の例は、直接アドレス指定を使用して1つの発行者ロゴタイプを含むロゴタイプ拡張機能を示しています。発行者ロゴタイプ画像は、タイプ画像/GIFです。ロゴタイプの画像ファイルは1 URIを介して参照され、画像は1つのSHA1ハッシュ値によってハッシュされます。
The values on the left are the ASN.1 tag and length, in hexadecimal.
左側の値は、16進数のasn.1タグと長さです。
30 106: SEQUENCE {
06 8: OBJECT IDENTIFIER '1 3 6 1 5 5 7 1 12'
04 94: OCTET STRING, encapsulates {
30 92: SEQUENCE {
A1 90: [1] {
A0 88: [0] {
30 86: SEQUENCE {
30 84: SEQUENCE {
30 82: SEQUENCE {
16 9: IA5String 'image/gif'
30 33: SEQUENCE {
30 31: SEQUENCE {
30 7: SEQUENCE {
06 5: OBJECT IDENTIFIER sha1 (1 3 14 3 2 26)
: }
04 20: OCTET STRING
: 8F E5 D3 1A 86 AC 8D 8E 6B C3 CF 80 6A D4 48 18
: 2C 7B 19 2E
: }
: }
30 34: SEQUENCE {
16 32: IA5String 'http://logo.example.com/logo.gif'
: }
: }
: }
: }
: }
: }
: }
: }
: }
Authors' Addresses
著者のアドレス
Stefan Santesson Microsoft Denmark Tuborg Boulevard 12 DK-2900 Hellerup Denmark
Stefan Santesson Microsoft Denmark Tuborg Boulevard 12 DK-2900 Hellerup Denmark
EMail: stefans@microsoft.com
Russell Housley Vigil Security, LLC 918 Spring Knoll Drive Herndon, VA 20170 USA
Russell Housley Vigil Security、LLC 918 Spring Knoll Drive Herndon、VA 20170 USA
EMail: housley@vigilsec.com
Trevor Freeman Microsoft Corporation One Microsoft Way Redmond WA 98052 USA
Trevor Freeman Microsoft Corporation One Microsoft Way Redmond WA 98052 USA
EMail: trevorf@microsoft.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78 and except as set forth therein, the authors retain all their rights.
著作権（c）The Internet Society（2004）。この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となりますが、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。