[要約] RFC 6170は、インターネット上でのX.509公開鍵基盤(PKI)の証明書イメージに関する標準仕様です。このRFCの目的は、証明書イメージの標準化と相互運用性の向上を促進することです。

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

インターネットX.509公開キーインフラストラクチャ - 証明書イメージ

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に従って新しい「他のロゴ」イメージタイプを定義することにより、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.

このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.

Copyright(c)2011 IETF Trustおよび文書著者として特定された人。全著作権所有。

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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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
        
1. Introduction
1. はじめに

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.

この標準は、証明書イメージを証明書にバインドする方法([RFC5280]で定義)にバインドする方法を指定し、[RFC3709]で定義されたロゴタイプ拡張機能を使用してその証明書の視覚的表現を提供し、新しい「他のロゴ」タイプとして証明書画像を指定します。

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.

- サービスまたは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のデータにラベルを付け、そのデータの正確な性質(セマンティクス)について人間に通知する問題に直面しています。また、どの識別属性が表示するのに重要であり、それらを論理的な順序で整理する方法を決定することは、アプリケーションにとっても困難です。

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の拡張機構を使用して完全な証明書イメージを含める方法を定義します。

1.1. Terminology
1.1. 用語

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].

「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。

2. Certificate Image
2. 証明書の画像

This section defines the certificate image as a new otherLogos type according to Section 4.1 of [RFC3709].

このセクションでは、[RFC3709]のセクション4.1に従って、証明書の画像を新しい他のロゴタイプとして定義します。

The certificate image otherLogos type is identified by the Object Identifier (OID) id-logo-certimage.

証明書の画像otherlogosタイプは、オブジェクト識別子(OID)id-logo-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:

存在する場合、証明書の画像は証明書の完全な視覚的表現でなければなりません。これは、この証明書イメージの表示が、発行者が証明書の典型的な意図された使用内で典型的な人間のユーザーに表示するために主観的に定義する証明書に関するすべての情報を表し、少なくとも次の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 according to this standard in any given application interface, as the only visual representation of a certificate.

証明書ユーザーにグラフィカルユーザーインターフェイス(GUI)を提供するアプリケーションは、証明書の唯一の視覚表現として、特定のアプリケーションインターフェイスのこの標準に従って証明書イメージを提示することができます。

3. LogotypeImageInfo
3. logotypeimageinfo

The optional LogotypeImageInfo structure is defined in [RFC3709] and is included here for convenience:

オプションのロゴタイプイメージインフォ構造は[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の比率を無傷に保ちながら、ロゴタイプのパラメーターのサイズパラメーターに適合するようにスケーリングする必要があります。

The resolution parameter is redundant for all image formats that are relevant for certificate images and MUST NOT be specified.

解像度パラメーターは、証明書イメージに関連するすべての画像形式で冗長であり、指定してはなりません。

4. Embedded Images
4. 埋め込まれた画像

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]で定義されているすべてのロゴタイプタイプは、RFC 2397 [RFC2397]で定義された「データ」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
        

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.

- 画像のハッシュは、ロゴタイプハッシュに含める必要があり、外部リソースへのリンクを通じて画像が参照されていれば、それと同じデータで計算する必要があります。

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.

注:実装は、証明書のサイズが証明書が意図されているように使用されないようにするために、証明書に含まれる画像のサイズについて注意する必要があります。

5. Certificate Image Formats
5. 証明書の画像形式

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)の使用を画像形式として指定します。

5.1. PDF
5.1. PDF

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メディアタイプを、ロゴタイプテールのmediatypeとして使用する必要があります。

application/pdf

アプリケーション/PDF

5.2. SVG
5.2. SVG

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:

証明書イメージは、スケーラブルベクトルグラフィックス(SVG)画像の形式で提供される場合があります。これは、次の修正でSVG Tiny Profile [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 SVG Tiny 1.2 [SVGT].

- SVG画像には、SVG Tiny 1.2 [SVGT]のセクション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 Tiny 1.2 [SVGT]のセクション15.2によると、SVG画像には「スクリプト」要素を含めてはなりません。

- 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ファイルのXML構造は、SVG画像上のハッシュを計算する際に、<LF>(LineFeed 0x0A)を行の終了(EOL)文字として使用する必要があります。

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 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ファイルは、SVGZファイルとしてGZIP圧縮[RFC1952]フォームで提供される場合があります。この場合、拡張「SVGZ」は「SVG.GZ」[RFC1952]のエイリアスとして使用されます。つまり、[SVGR]で指定されているようにGZIPで圧縮されたタイプイメージ/SVG XMLのオクテットストリームです。SVGZファイル上のハッシュは、上記で指定されているように、標準化されたEOL文字(<LF>)を使用して減圧された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画像のロゴタイプテールの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で定義されている「データ」URLスキームを使用してSVG画像が埋め込まれている場合、SVG画像データはSVGZ(GZIP圧縮)形式で提供する必要があります(つまり、非圧縮SVG形式で提供してはなりません)。

Compliant implementations of this specification SHOULD be able to process SVG images that are formatted according to this section.

この仕様の準拠の実装は、このセクションに従ってフォーマットされているSVG画像を処理できるはずです。

5.3. PNG
5.3. PNG

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画像は、ロゴタイプテールの次のmediatypeによって識別されます。

image/png

画像/PNG

6. Security Considerations
6. セキュリティに関する考慮事項

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.

これは、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 (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.

埋め込まれた証明書イメージを使用してCASが発行することは、証明書に署名するために使用されるハッシュアルゴリズムが衝突攻撃に対して脆弱である場合、証明書依頼者からグラフィックスを受け入れる場合は慎重になります。そのような場合、受け入れられた画像には、攻撃者が同一の証明書署名を持つ衝突証明書を取得するのに役立つデータが含まれている場合があります。

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.

証明書、したがって証明書の画像は一般に公開オブジェクトであるため、通常はプライバシーに敏感な情報は含まれません。ただし、証明書から参照される証明書画像にプライバシーに敏感な情報が含まれている場合、その情報のプライバシーを保護するために適切なセキュリティ制御を整える必要があります。このようなコントロールの詳細は、このドキュメントの範囲外です。

7. Acknowledgements
7. 謝辞

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のメンバーからの貴重な貢献を認識しています。

8. References
8. 参考文献
8.1. Normative References
8.1. 引用文献

[RFC1952] Deutsch, P., "GZIP file format specification version 4.3", RFC 1952, May 1996.

[RFC1952] Deutsch、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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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. Freeman、「インターネット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] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R.、およびW. Polk、 "Internet 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] Phillips、A.、ed。、およびM. Davis編、「言語を識別するためのタグ」、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)Tiny 1.2仕様」、2008年12月。

8.2. Informative References
8.2. 参考引用

[RFC3778] Taft, E., Pravetz, J., Zilles, S., and L. Masinter, "The application/pdf Media Type", RFC 3778, May 2004.

[RFC3778] Taft、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]「Image/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) }
        
   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=
        

Authors' Addresses

著者のアドレス

Stefan Santesson 3xA Security (AAA-sec.com) Bjornstorp 744 247 98 Genarp Sweden EMail: sts@aaa-sec.com

Stefan Santesson 3XA Security(AAA-Sec.com)bjornstorp 744 247 98 Genarp Sweden Email:sts@aaa-sec.com

Russell Housley Vigil Security, LLC 918 Spring Knoll Drive Herndon, VA 20170 USA EMail: housley@vigilsec.com

Russell Housley Vigil Security、LLC 918 Spring Knoll Drive Herndon、VA 20170 USAメール:housley@vigilsec.com

Siddharth Bajaj Symantec Corp. 350 Ellis Street Mountain View, CA 94043 USA EMail: siddharthietf@gmail.com

Siddharth Bajaj Symantec Corp. 350 Ellis Street Mountain View、CA 94043 USAメール:siddharthietf@gmail.com

Leonard Rosenthol 3533 Sunset Way Huntingdon Valley, PA 19006 USA EMail: leonardr@adobe.com

レナード・ローゼンホール3533サンセットウェイハンティンドンバレー、ペンシルベニア州19006 USAメール:leonardr@adobe.com