Internet Engineering Task Force (IETF) S. Santesson
Request for Comments: 6170 3xA Security
Updates: 3709 R. Housley
Category: Standards Track Vigil Security
ISSN: 2070-1721 S. Bajaj
Symantec Corp.
L. Rosenthol
Adobe
May 2011
Internet X.509 Public Key Infrastructure -- Certificate Image
Abstract
抽象
This document specifies a method to bind a visual representation of a certificate in the form of a certificate image to a public key certificate as defined in RFC 5280, by defining a new "otherLogos" image type according to RFC 3709.
この文書は、RFC 3709によると、新しい「otherLogos」イメージタイプを定義することによって、RFC 5280で定義されている公開鍵証明書の証明書の画像の形式における証明書の視覚的表現を結合する方法を指定します。
Status of This Memo
このメモのステータス
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 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。インターネット標準の詳細については、RFC 5741のセクション2で利用可能です。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6170.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6170で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Terminology ................................................3
2. Certificate Image ...............................................3
3. LogotypeImageInfo ...............................................4
4. Embedded Images .................................................5
5. Certificate Image Formats .......................................6
5.1. PDF ........................................................6
5.2. SVG ........................................................6
5.3. PNG ........................................................7
6. Security Considerations .........................................7
7. Acknowledgements ................................................8
8. References ......................................................9
8.1. Normative References .......................................9
8.2. Informative References .....................................9
Appendix A. ASN.1 Module .........................................10
Appendix B. Example ..............................................11
This standard specifies how to bind a certificate image to a certificate (defined in [RFC5280]), providing a visual representation of that certificate using the Logotype extension defined in [RFC3709] and specifying the certificate image as a new "otherLogos" type.
この規格は、[RFC3709]で定義されたロゴタイプの拡張子を使用して、新しい「otherLogos」タイプとして証明書の画像を指定その証明書の視覚的表現を提供する、（[RFC5280]で定義された）証明書の証明書の画像をバインドする方法を指定します。
The purpose of the certificate image is to aid human interpretation of a certificate by providing meaningful visual information to the user interface (UI).
証明書の画像の目的は、ユーザインタフェース（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.
- 人は、サービスまたはIdentity Managementインフラストラクチャへの認証時に使用する適切な証明書を選択する必要があります。人は選択プロセスでそれらを区別するために利用可能な証明書を確認する必要があります。
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での正確な性質について人間を知らせる（セマンティクス）の問題に直面しています。アプリケーションは属性が表示することが重要であり、どのように論理的な順序でそれらを整理するためにどの識別を決定することも困難です。
RFC 3709 [RFC3709] defines a certificate extension for binding images to a certificate, such as a community logo and issuer logo, enhancing the display of certificate information. The syntax is extensible and allows inclusion of new image types using the otherLogos structure. This standard defines how to include a complete certificate image using the extensibility mechanism of RFC 3709.
RFC 3709 [RFC3709]は、そのようなコミュニティロゴ及び発行者のロゴなどの証明書の画像を結合する証明書情報の表示を向上させるための証明書拡張を定義します。構文は、拡張可能であり、otherLogos構造を使用して新しいイメージタイプを含めることを可能にします。この標準は、RFC 3709の拡張メカニズムを使用して、完全な証明書の画像を含める方法を定義します。
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 [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
This section defines the certificate image as a new otherLogos type according to Section 4.1 of [RFC3709].
このセクションでは、新しいotherLogosは[RFC3709]のセクション4.1に従って入力すると、証明書の画像を規定します。
The certificate image otherLogos type is identified by the Object Identifier (OID) id-logo-certimage.
証明書の画像otherLogos型はオブジェクト識別子（OID）ID-ロゴcertimageによって識別されます。
id-pkix OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) }
id-logo OBJECT IDENTIFIER ::= { id-pkix 20 }
id-logo-certimage OBJECT IDENTIFIER ::= { id-logo 3 }
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:
存在する場合、証明書の画像は、証明書の完全な視覚的表現でなければなりません。これは、この証明書の画像の表示は、少なくとも次の三つの側面についての十分な情報を与え、発行者が主観的に証明書の一般的な使用目的の中の典型的な人間のユーザに表示するなどの関連規定する証明書に関するすべての情報を表すことを意味します証明書：
- 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 according to this standard in any given application interface, as the only visual representation of a certificate.
証明書のユーザにグラフィカル・ユーザ・インタフェース（GUI）を提供するアプリケーションは、証明書の唯一の視覚的表現として、任意の所与のアプリケーションインタフェースでは、この規格によれば、証明書の画像を提示することができます。
The optional LogotypeImageInfo structure is defined in [RFC3709] and is included here for convenience:
任意LogotypeImageInfo構造は[RFC3709]で定義されており、便宜上ここに含まれます。
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
NOTE: The referenced RFC 3066 in the structure above (from RFC 3709) is obsolete and is currently replaced by RFC 5646 [RFC5646]. The language tag may carry information about the language used to express any textual elements within the image as well as any audio information associated with the image.
注：（RFC 3709から）上記構造内の参照RFC 3066は廃止され、現在RFC 5646 [RFC5646]に置き換えられています。言語タグは、画像内の任意のテキスト要素と同様の画像に関連する任意のオーディオ情報を表現するために使用される言語についての情報を搬送することができます。
When the optional LogotypeImageInfo is included with a certificate image, the parameters shall be used with the following semantics and restrictions.
オプションのLogotypeImageInfoは、証明書の画像に含まれている場合、パラメータは、次のセマンティクスおよび制限付きで使用しなければなりません。
xSize and ySize represent the recommended display size for the 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 file, then the referenced image SHOULD be scaled to fit within the size parameters of LogotypeImageInfo, while keeping the x and y ratio intact.
XSIZEとYSIZEは、画像のための推奨表示サイズを表します。 0（ゼロ）の値が存在する場合、全く推奨表示サイズが指定されていません。ときに非ゼロ値が存在し、これらの値が参照される画像ファイル内の対応するサイズの値と異なる無傷のxとyの比率を維持したまま、次に、参照画像は、LogotypeImageInfoのサイズパラメータ内に収まるようにスケーリングされるべきです。
The resolution parameter is redundant for all image formats that are relevant for certificate images and MUST NOT be specified.
解像度パラメータは、証明書の画像に関連すると指定してはいけません、すべての画像フォーマットのために冗長です。
The certificate image otherLogos type defined in this specification and all logotype types defined in RFC 3709 [RFC3709] MAY be stored within the logotype extension using the "data" URL scheme defined in RFC 2397 [RFC2397] if the logotype image is provided through direct addressing, i.e., the image is referenced using the LogotypeDetails structure.
ロゴ画像は直接アドレッシングを介して提供される場合、証明書の画像otherLogos本明細書で定義されたタイプとRFC 3709で定義されているすべてのロゴタイプ[RFC3709]は[RFC2397] RFC 2397で定義された「データ」URLスキームを使用してロゴ拡張内に格納することができますすなわち、画像はLogotypeDetails構造を使用して参照されます。
The syntax of Logotype details defined in RFC 3709 is included here for convenience:
RFC 3709で定義されているロゴタイプの詳細の構文は、便宜のためにここに含まれています：
LogotypeDetails ::= SEQUENCE {
mediaType IA5String, -- MIME media type name and optional
-- parameters (see Section 5)
logotypeHash SEQUENCE SIZE (1..MAX) OF HashAlgAndValue,
logotypeURI SEQUENCE SIZE (1..MAX) OF IA5String }
The syntax of the "data" URL scheme defined in RFC 2397 is included here for convenience:
RFC 2397で定義された「データ」URLスキームの構文は便宜のためにここに含まれています：
dataurl := "data:" [ mediatype ] [ ";base64" ] "," data mediatype := [ type "/" subtype ] *( ";" parameter ) data := *urlchar parameter := attribute "=" value
dataurl：= "データ" [MEDIATYPE] [ "; BASE64"] "" データMEDIATYPE：= [タイプ "/" サブタイプ] *（ ";" パラメータ）データ：= * urlcharパラメータ：=属性 "=" 値
When including the image data in the logotype extension using the "data" URL scheme, the following conventions apply.
「データ」URLスキームを使用してロゴタイプの拡張子の画像データを含む場合は、次の規則が適用されます。
- 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, had the image been referenced through a link to an external resource.
- イメージのハッシュはlogotypeHashに含めなければならなくて、それは、画像が外部のリソースへのリンクを介して参照されていたであろうものと同じデータ上で計算しなければなりません。
NOTE: As the "data" URL 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.
注：「データ」URLスキームは、データソースとしてではなく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.
注：実装は、証明書のサイズが意図したとおりに使用されているから証明書を妨げないことを確実にするために、証明書に含まれる画像の大きさについては慎重にする必要があります。
Implementations of this specification MUST support JPEG and GIF as defined in RFC 3709 [RFC3709]. In addition to these mandatory-to-implement formats, this specification specifies the use of the Portable Document Format (PDF), Scalable Vector Graphics (SVG), and Portable Network Graphics (PNG) as image formats.
RFC 3709 [RFC3709]で定義されるように、この仕様の実装は、JPEGやGIFをサポートしなければなりません。これらの実装に必須のフォーマットに加えて、この仕様では、ポータブルドキュメントフォーマット（PDF）、スケーラブルベクターグラフィックス（SVG）、及び画像フォーマットとしてポータブルネットワークグラフィックス（PNG）の使用を指定します。
A certificate image MAY be provided in the form of a Portable Document Format (PDF) document according to [ISO32000] and following the conventions defined in this section. When a certificate image is formatted as a PDF document, it MUST also be formatted according to the profile PDF/A [ISO19005].
証明書の画像は、[ISO32000]によれば、このセクションで定義された規則に従うポータブルドキュメントフォーマット（PDF）ドキュメントの形で提供することができます。証明書の画像をPDF文書としてフォーマットされている場合、それはまた、プロファイルPDF / A [ISO19005]に従ってフォーマットしなければなりません。
When including a PDF document as a certificate image, the following MIME media type as specified in [RFC3778] MUST be used as mediaType in LogotypeDetails:
証明書の画像としてPDF文書を含む場合、[RFC3778]で指定されるように、次のMIMEメディアタイプはLogotypeDetailsにMEDIATYPEとして使用されなければなりません。
application/pdf
アプリケーション/ PDF
A certificate image MAY be provided in the form of a Scalable Vector Graphics (SVG) image, which MUST follow the SVG Tiny profile [SVGT] with the following amendments:
証明書の画像は、以下の修正と[SVGT] SVG小さなプロファイルに従わなければならないスケーラブルベクターグラフィックス（SVG）画像の形で提供されてもよいです。
- 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 SVG Tiny 1.2 [SVGT].
- SVG画像は、小型1.2 [SVGT] SVGのセクション14.1.4によれば、タイプB、C、又はDのSVG画像の外部に格納された情報への国際化リソース識別子（IRI）の参照を含んではなりません。
- The SVG image MUST NOT contain any 'script' element, according to Section 15.2 of SVG Tiny 1.2 [SVGT].
- SVG画像はSVG小型1.2 [SVGT]のセクション15.2によると、任意の「スクリプト」要素を含んではなりません。
- The XML structure in the SVG file MUST use <LF> (linefeed 0x0A) as the end-of-line (EOL) character when calculating a hash over the SVG image.
- SVG画像上ハッシュを計算する際に、SVGファイル内のXML構造は、エンドオブライン（EOL）文字として<LF>（ラインフィードは0x0A）を使用する必要があります。
The referenced SVG file MAY be provided in GZIP-compressed [RFC1952] form as an SVGZ file. In this case, the extension 'svgz' is used as an alias for 'svg.gz' [RFC1952], i.e., octet streams of type
参照SVGファイルは、SVGZファイルとしてGZIP圧縮[RFC1952]の形で提供することができます。この場合、拡張「SVGZ」は、すなわち「svg.gz」[RFC1952]、タイプのオクテットストリームの別名として使用され
image/svg+xml, subsequently compressed with gzip as specified in [SVGR]. The hash over the SVGZ file is calculated over the decompressed SVG content with canonicalized EOL characters (<LF>) as specified above.
画像/ SVG + XML、[SVGR]で指定されるように、続いてgzipで圧縮されました。 SVGZファイル上ハッシュは、上記指定された（<LF>）のように正規化EOL文字を解凍SVGコンテンツにわたって計算されます。
The following MIME media type, defined in Appendix M of [SVGT], MUST be included as mediaType in LogotypeDetails for all SVG and SVGZ images:
【SVGT]の付録Mで定義された次のMIMEメディアタイプは、すべてのSVGおよびSVGZ画像のLogotypeDetailsにMEDIATYPEとして含まれなければなりません。
image/svg+xml
画像/ SVG + xmlの
When the SVG image is embedded using the "data" URL scheme as defined in Section 4, SVG image data MUST be provided in SVGZ (GZIP compressed) form (i.e., it MUST NOT be provided in uncompressed SVG form).
セクション4で定義されるようにSVG画像は「データ」URLスキームを使用して埋め込まれている場合、SVG画像データ（すなわち、それが圧縮されていないSVG形式で提供してはいけません）SVGZ（GZIP圧縮された）形態で提供されなければなりません。
Compliant implementations of this specification SHOULD be able to process SVG images that are formatted according to this section.
この仕様の準拠実装は、このセクションに従ってフォーマットされているSVG画像を処理することができるべきです。
If a certificate image is provided as a bitmapped image, the PNG [ISO15948] format SHOULD be used.
証明書の画像をビットマップ画像として提供される場合、PNG [ISO15948]フォーマットを使用すべきです。
PNG images are identified by the following mediaType in LogotypeDetails:
PNG画像はLogotypeDetailsで、次のMEDIATYPEによって識別されます。
image/png
画像/ PNG
This document is based on and inherits all security considerations from RFC 3709 [RFC3709]. In particular, RFC 3709 discusses several issues a Certificate Authority (CA) should take into consideration when evaluating a request to issue a certificate with a certificate image.
このドキュメントは、に基づいており、RFC 3709 [RFC3709]からのすべてのセキュリティ上の考慮事項を継承しています。具体的には、RFC 3709には、証明書のイメージを持つ証明書を発行するための要求を評価する際に認証局（CA）が考慮すべきいくつかの問題について説明します。
Images incorporated according to RFC 3709 provide an additional possibility for a CA with bad intentions or bad security procedures to include false, conflicting, or malicious information to relying parties. Such a CA may, for example:
RFC 3709に従って組み込まれた画像は、依拠当事者に、悪意か悪いセキュリティ手順とCAのための追加の可能性は偽含めるように相反する、または悪質な情報を提供します。このようなCAは、例えば：
- include information in graphical form that is in conflict with information in provided text-based attributes or other name forms, and
- 提供されたテキストベースの属性または他の名前形式の情報と矛盾しているグラフィック形式の情報を含む、そして
- include malicious data that could exploit known security bugs in common software libraries used to render graphical images.
- グラフィック画像をレンダリングするために使用される一般的なソフトウェアライブラリで知られているセキュリティバグを悪用する可能性があり、悪意のあるデータが含まれます。
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.
CAは、信頼性の高いサービス、および依存者の責任を提供し、慎重に公開鍵証明書を提供するために、信頼されたCAを選択する必要がありますするためにこれは必要性を強調しています。
This also underlines the general necessity for relying parties to use up-to-date software libraries to render or dereference data from external sources (such as certificates), to minimize risks related to processing potentially malicious data before the data has been adequately verified and validated.
これは、データが十分に検証され、検証された前に、潜在的に悪質なデータを処理することに関連するリスクを最小限に抑えるために、（証明書など）外部ソースからデータをレンダリングするか、間接参照するために、最新のソフトウェア・ライブラリを使用するために依拠当事者のための一般的な必要性を強調します。
Referenced image files 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 image file. If this feature were used within a certificate image file, the hash of the image file would only cover the URI reference to the external image file, but not the referenced image data. Clients SHOULD verify that SVGT images meet all requirements listed in Section 5.2 and reject images that contain references to external data.
参照された画像ファイルは、証明書の署名に画像をバインドするために、ハッシュ化されています。このようなSVGのようないくつかの画像形式は、画像の一部が外部の画像ファイルへの参照を組み込むことによって、外部ソースから収集することを可能にします。この機能は、証明書の画像ファイル内で使用された場合は、画像ファイルのハッシュはURIの外部の画像ファイルへの参照ではなく、参照画像データをカバーします。クライアントは、そのSVGT画像は、セクション5.2に記載されているすべての要件を満たし、外部データへの参照が含まれている画像を拒絶確認する必要があります。
CAs issuing certificates with embedded certificate images should be cautious when accepting graphics from the certificate requestor for inclusion in the certificate if the hash algorithm used to sign the certificate is vulnerable to collision attacks. In such a case, the accepted image may contain data that could help an attacker to obtain colliding certificates with identical certificate signatures.
証明書に署名するために使用されるハッシュアルゴリズムは衝突攻撃に対して脆弱である場合、証明書に含めるために証明書要求者からグラフィックを受け付けたときに埋め込まれた証明書の画像と証明書を発行するCAは慎重であるべきです。このような場合には、受け付けた画像は、同一の証明書の署名に衝突証明書を取得するために、攻撃者を助けることができるデータを含むことができます。
Certificates, and hence their certificate images, are commonly public objects and as such usually will not contain privacy-sensitive information. However, when a certificate image that is referenced from a certificate contains privacy-sensitive information, appropriate security controls should be in place to protect the privacy of that information. Details of such controls are outside the scope of this document.
証明書、およびので、その証明書の画像は、一般的に、公共のオブジェクトであり、そのように、通常はプライバシーの機密情報が含まれません。ただし、証明書から参照されている証明書の画像は、プライバシーに敏感な情報が含まれている場合、適切なセキュリティコントロールは、その情報のプライバシーを保護するための場所である必要があります。そのような制御の詳細については、この文書の範囲外です。
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ブラウザフォーラム、およびジェームス・マンジェのメンバーから貴重な貢献を認識しています。
[RFC1952] Deutsch, P., "GZIP file format specification version 4.3", RFC 1952, May 1996.
[RFC1952]ドイツ、P.、 "GZIPファイル形式の仕様バージョン4.3"、RFC 1952、1996年5月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2397] Masinter, L., "The "data" URL scheme", RFC 2397, August 1998.
[RFC2397] Masinter、L.、 " "データ" URLスキーム"、RFC 2397、1998年8月。
[RFC3709] Santesson, S., Housley, R., and T. Freeman, "Internet X.509 Public Key Infrastructure: Logotypes in X.509 Certificates", RFC 3709, February 2004.
[RFC3709] Santesson、S.、Housley氏、R.、およびT.フリーマン、 "インターネットX.509公開鍵インフラストラクチャ：X.509証明書でロゴス"、RFC 3709、2004年2月。
[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, May 2008.
[RFC5280]クーパー、D.、Santesson、S.、ファレル、S.、Boeyen、S.、Housley氏、R.、およびW.ポーク、「インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト（CRL）のプロフィール」、RFC 5280、2008年5月。
[RFC5646] Phillips, A., Ed., and M. Davis, Ed., "Tags for Identifying Languages", BCP 47, RFC 5646, September 2009.
[RFC5646]フィリップス、A.編、およびM.デイビス、エド。、 "言語を識別するためのタグ"、BCP 47、RFC 5646、2009年9月。
[ISO15948] ISO/IEC 15948:2004, "Information technology -- Computer graphics and image processing -- Portable Network Graphics (PNG): Functional specification", 2004.
[ISO15948] ISO / IEC 15948：2004、 "情報技術 - コンピュータグラフィックスと画像処理 - ポータブルネットワークグラフィックス（PNG）：機能仕様"、2004年。
[ISO19005] ISO 19005-1:2005, "Document management -- Electronic document file format for long-term preservation -- Part 1: Use of PDF 1.4 (PDF/A-1)", 2005.
[ISO19005] ISO 19005-1：2005、 "文書管理 - 長期保存のための電子文書ファイルフォーマット - パート1：PDF 1.4の使用（PDF / A-1）"、2005年。
[ISO32000] ISO 32000-1:2008, "Document management -- Portable document format -- Part 1: PDF 1.7", April 2008.
[ISO32000] ISO 32000-1：2008、 "文書管理 - ポータブル・ドキュメント・フォーマット - パート1：PDF 1.7"、2008年4月。
[SVGT] W3C Recommendation, "Scalable Vector Graphics (SVG) Tiny 1.2 Specification", December 2008.
[SVGT] W3C勧告、 "スケーラブルベクターグラフィックス（SVG）タイニー1.2仕様"、2008年12月。
[RFC3778] Taft, E., Pravetz, J., Zilles, S., and L. Masinter, "The application/pdf Media Type", RFC 3778, May 2004.
[RFC3778]タフト、E.、Pravetz、J.、Zilles、S.、およびL. Masinter、 "アプリケーション/ PDFメディアタイプ"、RFC 3778、2004年5月。
[SVGR] "Media Type Registration for image/svg+xml", http://dev.w3.org/SVG/profiles/1.1F2/master/mimereg.html.
[SVGR] "画像/ SVG + xmlのためのメディアタイプ登録"、http://dev.w3.org/SVG/profiles/1.1F2/master/mimereg.html。
Appendix A. ASN.1 Module
付録A. ASN.1モジュール
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) }
CERT-IMAGEモジュール{ISO（1）同定された組織（3）DOD（6）インターネット（1）セキュリティ（5）メカニズム（5）PKIX（7）ID-MOD（0）ID-MOD-ロゴ-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
終わり
Appendix B. Example
付録B.例
The following example stores an embedded svgz-encoded SVG image using the "data" URL scheme.
次の例では、「データ」URLスキームを使用して埋め込まれたSVGZエンコードSVG画像を記憶します。
data:image/svg+xml;base64,H4sICLXutU0AA0NlcnRJbWFnZURlbW8uc3ZnANVa W2/bOBZ+n19BqBigwdoS7xK9jmeapB0EWHQHzez2WZZoR1tZMiQ5jvvr95CSL7Gl1E m8C9d9iERSPOd85+O5EB3+9jhL0YMuyiTPLh3iYgfpLMrjJJteOv/661M/cFBZhVkc pnmmL50sd34b/TIsH6YoiS+da11UySSJwkqj21k41Q6CDbNyUMSTS+e+quYDz1sul+ 6SuXkx9YhSysPUo7QPK/rlKqvCx35Wvmu+a/uGYow9EOigh0Qvr/LHSwcjjDjGiGHQ 914n0/sKlMf4Vwctk7i6X7/sGEYdNA5L/WeRT5IUDKmSbLVWNoo2cqNCh1XyoKN8Ns uz0iqwVW8Qb1fOF0Vqp+PI06me6awqPeISzxn9goYzXYVxWIUWpfWLCMwcGoLpgy83 n8wzGkbR4GtefENmMBznC7DEroKpOBpM8mIWVqPEYGtA+BvoMfS2E5uF1Wqu7R6FLv NFEelWReNolpiV3l2VpGntMW9nk6RKdf0+9BrFrMbeVuWhtzbHvMR6UlobPyVpBWjX Bk7six2vH5nCwY6nXCo5xb7YusvFVPqCOGh16fSxSxglmPkScLfvmDDmC4FlDc1wov 8IF2WZhNlVumgEPRliimDD3PhGPyTgUUMC6lKqKAjxaptq1boUJvQFsvi+LOJyxZkP E/vCwHuAmXmoj1AarnRBatzqkbv7cK5Ls2ORfwM/vsOG5lURZqXxOnDXPKZw5t5jVz IhFKO0B6D6hARSXDR6Fzqq7H7mQeJAOQiUSPvFIrUHOfuui3zrFI5dYVeAmpcOcOb9 u63vLjae4kYX4yRifYPrTa2SlMigYdO+cEWeGADMLZLH96SH4R9xRYApl6q3Y02f+N zlRAl+cZSKhB6qSIVa80fsqMnWOqZJpmsXwAPoyNaQ95uNIGasKPwhxGzQzOXzMIIz BKabmLIil470zfSjWWn+kvpvLQ9g1l3yRIc8gukz0uysEcakcDfy3KMk+l0SOXlOop ltJL7EPtUlzZfP4tnM70k8xkKCySt92MwfIXPoTe0pnu4dYbp7hJ/kxWySN0ey0o/1 qbiCsxDXJMWWo37QekBcAUFPSGkPCnUJF5wwBacDK5cGlEp4BC2lYoJcrNNGVc7DzI qxT4CKsPlrAG8mL8whRejiQe9EmImIAoz3sds9NxP4RZEzugqzb7c3Q89u3WQKY9ae gbsA/AUJB/bJs6pfJt9BHFEuk5DWITzOH5uZSThLUsDjQ5GE6RMsyihMTaQLfA6BIi AQMAhnHHN1sd61WtUhDVJiuhkrdBXd740+hLB9Vm1HjQe4ywLOBLWOMMiyQAXNB8sm 9Gx2qdGgGkMG6wY8aLfqgH4dfnmrVc+pPrE/Z/QnZOs8C1Okb2/ggwLdxlDC1D6DFP ZDD98txv8xQf5TEc7Ax6ZyaDf6BC4SylWKCMqtizp80+UMchATal63qHq0M3ZTs83O b/XO6LYsFzpGVY5+iLxdWvwY+NaKoR/0iJIXL3dBjT2hG+wO+NXm53XStSh1eogfeo jV35BTOaqh/cmPUe2Mdp91pQp2CjWOO2k7OamhjU1HB3DLGm66n6iajz4bqn2oICmN FxDR/x2mC5s+rKhlkUA3Ne3P8lgP0qJfjf9uvu+HWXSfFwNoH4uqGUmTadYMtOc7yj EEd9EUhkwEEOcDSHKQ+yhnSvUYRH8miQo2FK5TCjWZZGWKB8iHPud16wApnCvTOzjI FAj9TQdCxa+ddOTizaa1xJvD0qMrKx+Ydaj6iwJQG0vaSdYWpTv4HwVRAP3Z6ONjOJ unEIeKRVmhujpA2+wPmQR9WFQAFhh9bGQzFEXX+WwOnXq8pV35P2Acdn0pGebcMg7O gQKaEdOKEAkFlk/9HuEKGBVwucc4AjnJ/LBYU09hVwWY1F0HlBUC2lbyIuYF58O8p+ adMwUt9YAoX/IwRtAC9NAdBAyGuEB3VR59u8/TGYx9/Xjz8bPB/Z/F9B0SghBK+4xx fiwtr0GXECqedQQ9PRVpEAQ+26MidbGSmPm8RwRzcQsT17EPSmoorH3+av4Jcj78O/ vIp/uzMEkHKAE6/F7VHHSj8HddR0Q3ymcGZfRVjwfmOnNn3GuWR+FzhcPmPqiptHca yacT28T8j3Cs0/LQCwo6J2iYxP4R58AsobjFegusoJhuq7VNS2evRPcqASvQki+gbk BYwETNPt/1A2pT6UErR1zMzUITZRvF5Lp5basO1fk2U4aBSjkji8quL3cDyW7TpI3u nxezMcSTNhQJhfpGctKgKN2Amo7/7ShSev4oXicPSYS+6GkCm9a1Qw3VEchCUA+z5H tTcbQhK6F14YFUp+Yn7WgmzwpZCDf5DDiXT9B7U6RdHAHpdb7IqmLVjqZSLnTW61zj Q7/G7D3hm9E846uTDZoNMADmLlm7IG2ieXfUtu1US9TeNGUHibE9Nv//2jRJGZfQmK 3v7ykJJOv1IXjBsDCPpmgWppe6sHxR3KVSQKqp+WIqammuJbtqkxZmMHry4oS/9pLh dCXKq8uR0R+LDEqCKRxqc5VXdvPvIP+ggwR0RkyBfO9iKZvrWGAKVdz31cuocvoO/q emClFMYEFEH7oI+vpkek4s4bCMBqK+5mHQUlDpE/oylpy+2/6pWXK31PEYagP04epV 1cE50UMy6IQZeQM7+Ol74Z+eHfpHNc7OjffQ/HeV0X8BopoDkGEkAAA=
データ：画像/ SVG + XML、BASE64、H4sICLXutU0AA0NlcnRJbWFnZURlbW8uc3ZnANVa W2 / bOBZ + n19BqBigwdoS7xK9jmeapB0EWHQHzez2WZZoR1tZMiQ5jvvr95CSL7Gl1E m8C9d9iERSPOd85 + O5EB3 + 9jhL0YMuyiTPLh3iYgfpLMrjJJteOv / 661M / cFBZhVkc pnmmL50sd34b / TIsH6YoiS + da11UySSJwkqj21k41Q6CDbNyUMSTS + E + quYDz1sul + 6SuXkx9YhSysPUo7QPK / rlKqvCx35Wvmu + A / uGYow9EOigh0Qvr / LHSwcjjDjGiGHQ 914n0 / sKlMf4Vwctk7i6X7 / sGEYdNA5L / WeRT5IUDKmSbLVWNoo2cqNCh1XyoKN8Ns uz0iqwVW8Qb1fOF0Vqp + PI06me6awqPeISzxn9goYzXYVxWIUWpfWLCMwcGoLpgy83 n8wzGkbR4GtefENmMBznC7DEroKpOBpM8mIWVqPEYGtA + BvoMfS2E5uF1Wqu7R6FLv NFEelWReNolpiV3l2VpGntMW9nk6RKdf0 + 9BrFrMbeVuWhtzbHvMR6UlobPyVpBWjX Bk7six2vH5nCwY6nXCo5xb7YusvFVPqCOGh16fSxSxglmPkScLfvmDDmC4FlDc1wov 8IF2WZhNlVumgEPRliimDD3PhGPyTgUUMC6lKqKAjxaptq1boUJvQFsvi + LOJyxZkP E / vCwHuAmXmoj1AarnRBatzqkbv7cK5Ls2ORfwM / vsOG5lURZqXxOnDXPKZw5t5jVz IhFKO0B6D6hARSXDR6Fzqq7H7mQeJAOQiUSPvFIrUHOfuui3zrFI5dYVeAmpcOcOb9 u63vLjae4kYX4yRifYPrTa2SlMigYdO + cEWeGADMLZLH96SH4R9xRYApl6q3Y02f + N zlRAl + cZSKhB6qSIVa80fsqMnWOqZJpmsXwAPoyNaQ95uNIGasKPwhxGzQzOXz MIIz BKabmLIil470zfSjWWn + kvpvLQ9g1l3yRIc8gukz0uysEcakcDfy3KMk + l0SOXlOop ltJL7EPtUlzZfP4tnM70k8xkKCySt92MwfIXPoTe0pnu4dYbp7hJ / kxWySN0ey0o / 1 qbiCsxDXJMWWo37QekBcAUFPSGkPCnUJF5wwBacDK5cGlEp4BC2lYoJcrNNGVc7DzI qxT4CKsPlrAG8mL8whRejiQe9EmImIAoz3sds9NxP4RZEzugqzb7c3Q89u3WQKY9ae GBSA / AUJB / bJs6pfJt9BHFEuk5DWITzOH5uZSThLUsDjQ5GE6RMsyihMTaQLfA6BIi AQMAhnHHN1sd61WtUhDVJiuhkrdBXd740 + hLB9Vm1HjQe4ywLOBLWOMMiyQAXNB8sm 9Gx2qdGgGkMG6wY8aLfqgH4dfnmrVc + PPRE / Z / QnZOs8C1Okb2 / ggwLdxlDC1D6DFP ZDD98txv8xQf5TEc7Ax6ZyaDf6BC4SylWKCMqtizp80 + UMchATal63qHq0M3ZTs83O B / XO6LYsFzpGVY5 + iLxdWvwY + NaKoR / 0iJIXL3dBjT2hG + + NXm53XStSh1eogfeo jV35BTOaqh / cmPUe2Mdp91pQp2CjWOO2k7OamhjU1HB3DLGm66n6iajz4bqn2oICmN FxDR WO / x2mC5s + rKhlkUA3Ne3P8lgP0qJfjf9uvu + HWXSfFwNoH4uqGUmTadYMtOc7yj EEd9EUhkwEEOcDSHKQ + yhnSvUYRH8miQo2FK5TCjWZZGWKB8iHPud16wApnCvTOzjI FAj9TQdCxa + ddOTizaa1xJvD0qMrKx + Ydaj6iwJQG0vaSdYWpTv4HwVRAP3Z6ONjOJ unEIeKRVmhujpA2 + wPmQR9WFQAFhh9bGQzFEXX + WwOnXq8pV35P2Acdn0pGebcMg7O gQKaEdOKEAkFlk / 9HuEKGBVwucc4AjnJ / LBYU09hVwWY1F0HlBUC2lbyI uYF58O8p + adMwUt9YAoX / IwRtAC9NAdBAyGuEB3VR59u8 / TGYx9 / Xjz8bPB / Z / F9B0SghBK + 4XX fiwtr0GXECqedQQ9PRVpEAQ + 26MidbGSmPm8RwRzcQsT17EPSmoorH3 + av4Jcj78O / VIP / uzMEkHKAE6 / F7VHHSj8HddR0Q3ymcGZfRVjwfmOnNn3GuWR + FzhcPmPqiptHca yacT28T8j3Cs0 / LQCwo6J2iYxP4R58AsobjFegusoJhuq7VNS2evRPcqASvQki + GBK BYwETNPt / 1A2pT6UErR1zMzUITZRvF5Lp5basO1fk2U4aBSjkji8quL3cDyW7TpI3u nxezMcSTNhQJhfpGctKgKN2Amo7 / 7ShSev4oXicPSYS + 6GkCm9a1Qw3VEchCUA + z5H tTcbQhK6F14YFUp + Yn7WgmzwpZCDf5DDiXT9B7U6RdHAHpdb7IqmLVjqZSLnTW61zj Q7 / G7D3hm9E846uTDZoNMADmLlm7IG2ieXfUtu1US9TeNGUHibE9Nv // 2jRJGZfQmK 3v7ykJJOv1IXjBsDCPpmgWppe6sHxR3KVSQKqp + WIqammuJbtqkxZmMHry4oS / 9pLh dCXKq8uR0R + LDEqCKRxqc5VXdvPvIP + ggwR0RkyBfO9iKZvrWGAKVdz31cuocvoO / Q emClFMYEFEH7oI + vpkek4s4bCMBqK + 5mHQUlDpE / oylpy + 2 / 6pWXK31PEYagP04epV 1cE50UMy6IQZeQM7 + Ol74Z + eHfpHNc7OjffQ / HeV0X8BopoDkGEkAAA =
Authors' Addresses
著者のアドレス
Stefan Santesson 3xA Security (AAA-sec.com) Bjornstorp 744 247 98 Genarp Sweden EMail: sts@aaa-sec.com
ステファンSantesson 3XAセキュリティ（AAA-sec.com）Bjornstorp 744 247 98 Genarpスウェーデンメール：sts@aaa-sec.com
Russell Housley Vigil Security, LLC 918 Spring Knoll Drive Herndon, VA 20170 USA EMail: housley@vigilsec.com
ラッセルHousley氏ビジルセキュリティ、LLC 918春小山Driveハーンドン、VA 20170 USA電子メール：housley@vigilsec.com
Siddharth Bajaj Symantec Corp. 350 Ellis Street Mountain View, CA 94043 USA EMail: siddharthietf@gmail.com
シッダールタバジャジシマンテック350エリスストリートマウンテンビュー、CA 94043 USA電子メール：siddharthietf@gmail.com
Leonard Rosenthol 3533 Sunset Way Huntingdon Valley, PA 19006 USA EMail: leonardr@adobe.com
レナードRosenthol氏3533サンセット・ウェイハンティンドン・バレー、PA 19006 USA Eメール：leonardr@adobe.com