RFC 6091 - Using OpenPGP Keys for Transport Layer Security (TLS) Authentication 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc6091
タイトル : RFC 6091 - トランスポート層セキュリティ（TLS）認証のためのOpenPGPキーの使用
翻訳編集 : 自動生成

[要約] RFC 6091は、Transport Layer Security (TLS) 認証においてOpenPGPキーを使用する方法について記述しています。この文書の目的は、TLSプロトコルでOpenPGP公開鍵インフラを利用するための標準的な方法を提供することにあります。利用場面としては、Webサーバーやメールサーバーなど、TLSを使用して暗号化された通信を行う任意のサービスが挙げられます。関連するRFCには、TLSを定義するRFC 5246や、OpenPGPの仕様を定義するRFC 4880などがあります。このRFCにより、OpenPGPの広範なユーザーベースと既存の公開鍵インフラをTLS認証に活用することが可能になります。

Internet Engineering Task Force (IETF)              N. Mavrogiannopoulos
Request for Comments: 6091                                           KUL
Obsoletes: 5081                                               D. Gillmor
Category: Informational                                      Independent
ISSN: 2070-1721                                            February 2011

Using OpenPGP Keys for Transport Layer Security (TLS) Authentication

トランスポート層セキュリティ（TLS）認証のためのOpenPGPキーの使用

Abstract

概要

This memo defines Transport Layer Security (TLS) extensions and associated semantics that allow clients and servers to negotiate the use of OpenPGP certificates for a TLS session, and specifies how to transport OpenPGP certificates via TLS. It also defines the registry for non-X.509 certificate types.

このメモは、クライアントとサーバーがTLSセッションのOpenPGP証明書の使用をネゴシエートできるようにするトランスポート層セキュリティ（TLS）拡張と関連するセマンティクスを定義し、TLSを介してOpenPGP証明書をトランスポートする方法を指定します。また、X.509以外の証明書タイプのレジストリも定義します。

Status of This Memo

本文書の状態

This document is not an Internet Standards Track specification; it is published for informational purposes.

このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。

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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.

このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 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/rfc6091.

このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6091で入手できます。

著作権表示

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文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。

Table of Contents

   1. Introduction ....................................................2
   2. Terminology .....................................................2
   3. Changes to the Handshake Message Contents .......................3
      3.1. Client Hello ...............................................3
      3.2. Server Hello ...............................................4
      3.3. Server Certificate .........................................4
      3.4. Certificate Request ........................................6
      3.5. Client Certificate .........................................6
      3.6. Other Handshake Messages ...................................7
   4. Security Considerations .........................................7
   5. IANA Considerations .............................................7
   6. Acknowledgements ................................................8
   7. References ......................................................8
      7.1. Normative References .......................................8
      7.2. Informative References .....................................8
   Appendix A.  Changes from RFC 5081 .................................9

1. Introduction

1. はじめに

The IETF has two sets of standards for public key certificates: one set for the use of X.509 certificates [RFC5280], and one for OpenPGP certificates [RFC4880]. At the time of this writing, TLS [RFC5246] standards are defined to use X.509 certificates. This document specifies a way to negotiate the use of OpenPGP certificates for a TLS session, and specifies how to transport OpenPGP certificates via TLS. The proposed extensions are backward-compatible with the current TLS specification, so that existing client and server implementations that make use of X.509 certificates are not affected.

IETFには、公開鍵証明書に関する2つの標準セットがあります。1つはX.509証明書を使用するためのセット[RFC5280]で、もう1つはOpenPGP証明書のための[RFC4880]です。この記事の執筆時点では、TLS [RFC5246]標準はX.509証明書を使用するように定義されています。このドキュメントでは、TLSセッションでのOpenPGP証明書の使用をネゴシエートする方法と、TLSを介してOpenPGP証明書を転送する方法を指定します。提案された拡張機能は、現在のTLS仕様と下位互換性があるため、X.509証明書を使用する既存のクライアントおよびサーバーの実装は影響を受けません。

These extensions are not backward-compatible with [RFC5081], and the major differences are summarized in Appendix A. Although the OpenPGP CertificateType value is being reused by this memo with the same number as that specified in [RFC5081] but with different semantics, we believe that this causes no interoperability issues because the latter was not widely deployed.

これらの拡張機能は[RFC5081]との下位互換性がなく、主な違いは付録Aにまとめられています。OpenPGPCertificateType値は、[RFC5081]で指定されたものと同じ番号で、異なるセマンティクスでこのメモによって再利用されていますが、後者は広く展開されていなかったので、これは相互運用性の問題を引き起こさないと考えています。

2. Terminology

2. 用語

The term "OpenPGP key" is used in this document as in the OpenPGP specification [RFC4880]. We use the term "OpenPGP certificate" to refer to OpenPGP keys that are enabled for authentication.

このドキュメントでは、「OpenPGPキー」という用語がOpenPGP仕様[RFC4880]と同様に使用されています。「OpenPGP証明書」という用語は、認証が有効になっているOpenPGP鍵を指すのに使用します。

This document uses the same notation and terminology used in the TLS Protocol specification [RFC5246].

このドキュメントでは、TLSプロトコル仕様[RFC5246]で使用されているものと同じ表記法と用語を使用しています。

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」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。

3. Changes to the Handshake Message Contents

3. ハンドシェイクメッセージの内容の変更

This section describes the changes to the TLS handshake message contents when OpenPGP certificates are to be used for authentication.

このセクションでは、OpenPGP証明書を認証に使用する場合のTLSハンドシェイクメッセージの内容の変更について説明します。

3.1. Client Hello

3.1. こんにちは

In order to indicate the support of multiple certificate types, clients MUST include an extension of type "cert_type" to the extended client hello message. The "cert_type" TLS extension is assigned the value of 9 from the TLS ExtensionType registry. This value is used as the extension number for the extensions in both the client hello message and the server hello message. The hello extension mechanism is described in [RFC5246].

複数の証明書タイプのサポートを示すために、クライアントは、タイプ "cert_type"の拡張を拡張クライアントhelloメッセージに含める必要があります。「cert_type」TLS拡張には、TLS ExtensionTypeレジストリから値9が割り当てられます。この値は、クライアントhelloメッセージとサーバーhelloメッセージの両方の内線番号の内線番号として使用されます。 hello拡張メカニズムは[RFC5246]で説明されています。

This extension carries a list of supported certificate types the client can use, sorted by client preference. This extension MUST be omitted if the client only supports X.509 certificates. The "extension_data" field of this extension contains a CertificateTypeExtension structure. Note that the CertificateTypeExtension structure is being used both by the client and the server, even though the structure is only specified once in this document. Reusing a single specification for both client and server is common in other specifications, such as the TLS protocol itself [RFC5246].

この拡張機能は、クライアントが使用できるサポートされている証明書の種類のリストを、クライアントの優先度順に並べたものです。クライアントがX.509証明書のみをサポートする場合は、この拡張を省略しなければなりません。この拡張の「extension_data」フィールドには、CertificateTypeExtension構造が含まれています。このドキュメントでは一度だけ構造が指定されているにもかかわらず、CertificateTypeExtension構造はクライアントとサーバーの両方で使用されていることに注意してください。クライアントとサーバーの両方に単一の仕様を再利用することは、TLSプロトコル自体[RFC5246]などの他の仕様では一般的です。

      enum { client, server } ClientOrServerExtension;

      enum { X.509(0), OpenPGP(1), (255) } CertificateType;

      struct {
         select(ClientOrServerExtension) {
            case client:
               CertificateType certificate_types<1..2^8-1>;
            case server:
               CertificateType certificate_type;
         }
      } CertificateTypeExtension;

No new cipher suites are required to use OpenPGP certificates. All existing cipher suites that support a key exchange method compatible with the key in the certificate can be used in combination with OpenPGP certificates.

OpenPGP証明書を使用するために新しい暗号スイートは必要ありません。証明書の鍵と互換性のある鍵交換方式をサポートする既存のすべての暗号スイートは、OpenPGP証明書と組み合わせて使用できます。

3.2. Server Hello

3.2. サーバーこんにちは

If the server receives a client hello that contains the "cert_type" extension and chooses a cipher suite that requires a certificate, then two outcomes are possible. The server MUST either select a certificate type from the certificate_types field in the extended client hello or terminate the session with a fatal alert of type "unsupported_certificate".

サーバーが「cert_type」拡張を含むclient helloを受信し、証明書を必要とする暗号スイートを選択した場合、2つの結果が考えられます。サーバーは、拡張クライアントhelloのcertificate_typesフィールドから証明書タイプを選択するか、タイプ「unsupported_certificate」の致命的なアラートでセッションを終了する必要があります。

The certificate type selected by the server is encoded in a CertificateTypeExtension structure, which is included in the extended server hello message using an extension of type "cert_type". Servers that only support X.509 certificates MAY omit including the "cert_type" extension in the extended server hello.

サーバーによって選択された証明書タイプはCertificateTypeExtension構造にエンコードされます。これは、タイプ「cert_type」の拡張を使用して、拡張サーバーのhelloメッセージに含まれています。 X.509証明書のみをサポートするサーバーは、拡張サーバーhelloに「cert_type」拡張を含めることで省略できます。

3.3. Server Certificate

3.3. サーバー証明書

The contents of the certificate message sent from server to client and vice versa are determined by the negotiated certificate type and the selected cipher suite's key exchange algorithm.

サーバーからクライアントに、またはその逆に送信される証明書メッセージの内容は、ネゴシエートされた証明書タイプと選択された暗号スイートの鍵交換アルゴリズムによって決定されます。

If the OpenPGP certificate type is negotiated, then it is required to present an OpenPGP certificate in the certificate message. The certificate must contain a public key that matches the selected key exchange algorithm, as shown below.

OpenPGP証明書タイプがネゴシエートされる場合、証明書メッセージでOpenPGP証明書を提示する必要があります。証明書には、次に示すように、選択した鍵交換アルゴリズムと一致する公開鍵が含まれている必要があります。

Key Exchange Algorithm OpenPGP Certificate Type

鍵交換アルゴリズムOpenPGP証明書タイプ

RSA RSA public key that can be used for encryption.

暗号化に使用できるRSA RSA公開鍵。

DHE_DSS DSA public key that can be used for authentication.

DHE_DSS認証に使用できるDSA公開鍵。

DHE_RSA RSA public key that can be used for authentication.

DHE_RSA認証に使用できるRSA公開鍵。

An OpenPGP certificate appearing in the certificate message is sent using the binary OpenPGP format. The certificate MUST contain all the elements required by Section 11.1 of [RFC4880].

証明書メッセージに表示されるOpenPGP証明書は、バイナリOpenPGP形式を使用して送信されます。証明書には、[RFC4880]のセクション11.1で要求されるすべての要素が含まれている必要があります。

OpenPGP certificates to be transferred are placed in the Certificate structure and tagged with the OpenPGPCertDescriptorType "subkey_cert". Since those certificates might contain several subkeys, the subkey ID to be used for this session is explicitly specified in the OpenPGPKeyID field. The key ID must be specified even if the certificate has only a primary key. The peer, upon receiving this type, has to either use the specified subkey or terminate the session with a fatal alert of "unsupported_certificate".

転送されるOpenPGP証明書は証明書構造に配置され、OpenPGPCertDescriptorType "subkey_cert"でタグ付けされます。これらの証明書には複数のサブキーが含まれている可能性があるため、このセッションで使用されるサブキーIDは、OpenPGPKeyIDフィールドで明示的に指定されます。証明書に主キーしかない場合でも、キーIDを指定する必要があります。ピアは、このタイプを受信すると、指定されたサブキーを使用するか、「unsupported_certificate」の致命的なアラートでセッションを終了する必要があります。

The option is also available to send an OpenPGP fingerprint, instead of sending the entire certificate, by using the "subkey_cert_fingerprint" tag. This tag uses the OpenPGPSubKeyFingerprint structure and requires the primary key fingerprint to be specified, as well as the subkey ID to be used for this session. The peer shall respond with a "certificate_unobtainable" fatal alert if the certificate with the given fingerprint cannot be found. The "certificate_unobtainable" fatal alert is defined in Section 5 of [RFC6066].

「subkey_cert_fingerprint」タグを使用して、証明書全体を送信する代わりに、OpenPGPフィンガープリントを送信するオプションも利用できます。このタグはOpenPGPSubKeyFingerprint構造を使用し、このセッションで使用するサブキーIDだけでなく、主キーのフィンガープリントを指定する必要があります。ピアは、指定されたフィンガープリントの証明書が見つからない場合、「certificate_unobtainable」の致命的なアラートで応答します。「certificate_unobtainable」の致命的なアラートは、[RFC6066]のセクション5で定義されています。

Implementations of this protocol MUST ensure that the sizes of key IDs and fingerprints in the OpenPGPSubKeyCert and OpenPGPSubKeyFingerprint structures comply with [RFC4880]. Moreover, it is RECOMMENDED that the keys to be used with this protocol have the authentication flag (0x20) set.

このプロトコルの実装は、OpenPGPSubKeyCertおよびOpenPGPSubKeyFingerprint構造体のキーIDおよびフィンガープリントのサイズが[RFC4880]に準拠していることを保証する必要があります。さらに、このプロトコルで使用されるキーには認証フラグ（0x20）が設定されていることが推奨されます。

The process of fingerprint generation is described in Section 12.2 of [RFC4880].

指紋の生成プロセスは、[RFC4880]のセクション12.2で説明されています。

The enumerated types "cert_fingerprint" and "cert" of OpenPGPCertDescriptorType that were defined in [RFC5081] are not used and are marked as obsolete by this document. The "empty_cert" type has replaced "cert" and is a backward-compatible way to specify an empty certificate; "cert_fingerprint" MUST NOT be used with this updated specification, and hence that old alternative has been removed from the Certificate struct description.

[RFC5081]で定義されたOpenPGPCertDescriptorTypeの列挙型「cert_fingerprint」および「cert」は使用されておらず、このドキュメントでは廃止されたものとしてマークされています。「empty_cert」タイプは「cert」を置き換え、空の証明書を指定するための下位互換性のある方法です。「cert_fingerprint」はこの更新された仕様で使用してはならないため、Certificate structの説明から古い代替手段が削除されました。

      enum {
           empty_cert(1),
           subkey_cert(2),
           subkey_cert_fingerprint(3),
           (255)
      } OpenPGPCertDescriptorType;

uint24 OpenPGPEmptyCert = 0;

      struct {
          opaque OpenPGPKeyID<8..255>;
          opaque OpenPGPCert<0..2^24-1>;
      } OpenPGPSubKeyCert;

      struct {
          opaque OpenPGPKeyID<8..255>;
          opaque OpenPGPCertFingerprint<20..255>;
      } OpenPGPSubKeyFingerprint;

      struct {
           OpenPGPCertDescriptorType descriptorType;
           select (descriptorType) {
                case empty_cert: OpenPGPEmptyCert;
                case subkey_cert: OpenPGPSubKeyCert;
                case subkey_cert_fingerprint:
                    OpenPGPSubKeyCertFingerprint;
           }
      } Certificate;

3.4. Certificate Request

3.4. 証明書リクエスト

The semantics of this message remain the same as in the TLS specification. However, if this message is sent, and the negotiated certificate type is OpenPGP, the "certificate_authorities" list MUST be empty.

このメッセージのセマンティクスは、TLS仕様の場合と同じです。ただし、このメッセージが送信され、ネゴシエートされた証明書タイプがOpenPGPである場合、「certificate_authorities」リストは空である必要があります。

3.5. Client Certificate

3.5. クライアント証明書

This message is only sent in response to the certificate request message. The client certificate message is sent using the same formatting as the server certificate message, and it is also required to present a certificate that matches the negotiated certificate type. If OpenPGP certificates have been selected and no certificate is available from the client, then a certificate structure of type "empty_cert" that contains an OpenPGPEmptyCert value MUST be sent. The server SHOULD respond with a "handshake_failure" fatal alert if client authentication is required.

このメッセージは、証明書要求メッセージへの応答としてのみ送信されます。クライアント証明書メッセージは、サーバー証明書メッセージと同じフォーマットを使用して送信され、ネゴシエートされた証明書タイプと一致する証明書を提示することも必要です。 OpenPGP証明書が選択されていて、クライアントから使用できる証明書がない場合は、OpenPGPEmptyCert値を含む「empty_cert」タイプの証明書構造を送信する必要があります。クライアント認証が必要な場合、サーバーは「handshake_failure」致命的アラートで応答する必要があります（SHOULD）。

3.6. Other Handshake Messages

3.6. その他のハンドシェイクメッセージ

All the other handshake messages are identical to the TLS specification.

他のすべてのハンドシェイクメッセージは、TLS仕様と同じです。

4. Security Considerations

4. セキュリティに関する考慮事項

All security considerations discussed in [RFC5246], [RFC6066], and [RFC4880] apply to this document. Considerations about the use of the web of trust or identity and certificate verification procedures are outside the scope of this document. These are considered issues to be handled by the application layer protocols.

[RFC5246]、[RFC6066]、および[RFC4880]で説明されているすべてのセキュリティの考慮事項がこのドキュメントに適用されます。信頼またはアイデンティティのウェブの使用に関する考慮事項および証明書の検証手順は、このドキュメントの範囲外です。これらは、アプリケーション層プロトコルによって処理される問題と見なされます。

The protocol for certificate type negotiation is identical in operation to cipher suite negotiation as described in the TLS specification [RFC5246], with the addition of default values when the extension is omitted. Since those omissions have a unique meaning and the same protection is applied to the values as with cipher suites, it is believed that the security properties of this negotiation are the same as with cipher suite negotiation.

証明書タイプネゴシエーションのプロトコルは、TLS仕様[RFC5246]で説明されているように、暗号スイートネゴシエーションと動作が同じですが、拡張が省略されている場合はデフォルト値が追加されます。これらの省略には固有の意味があり、暗号スイートと同じ保護が値に適用されるため、このネゴシエーションのセキュリティプロパティは暗号スイートネゴシエーションと同じであると考えられています。

When using OpenPGP fingerprints instead of the full certificates, the discussion in Section 5 of [RFC6066] for "Client Certificate URLs" applies, especially when external servers are used to retrieve keys. However, a major difference is that although the "client_certificate_url" extension allows identifying certificates without including the certificate hashes, this is not possible in the protocol proposed here. In this protocol, the certificates, when not sent, are always identified by their fingerprint, which serves as a cryptographic hash of the certificate (see Section 12.2 of [RFC4880]).

完全な証明書の代わりにOpenPGPフィンガープリントを使用する場合、[RFC6066]のセクション5の「クライアント証明書のURL」に関する説明が適用されます。特に、外部サーバーを使用してキーを取得する場合に当てはまります。ただし、主な違いは、「client_certificate_url」拡張では証明書ハッシュを含めずに証明書を識別できるが、ここで提案されているプロトコルではこれが不可能であることです。このプロトコルでは、証明書が送信されない場合、証明書の暗号化ハッシュとして機能するフィンガープリントによって常に識別されます（[RFC4880]のセクション12.2を参照）。

The information that is available to participating parties and eavesdroppers (when confidentiality is not available through a previous handshake) is the number and the types of certificates they hold, plus the contents of the certificates.

参加者と盗聴者が利用できる情報（以前のハンドシェイクで機密性が利用できない場合）は、それらが保持する証明書の数と種類、および証明書の内容です。

5. IANA Considerations

5. IANAに関する考慮事項

This document uses a registry and the "cert_type" extension originally defined in [RFC5081]. Existing IANA references have been updated to point to this document.

このドキュメントでは、レジストリと、[RFC5081]で最初に定義された「cert_type」拡張を使用します。このドキュメントを指すように、既存のIANAリファレンスが更新されました。

In addition, the "TLS Certificate Types" registry established by [RFC5081] has been updated in the following ways:

さらに、[RFC5081]によって確立された「TLS証明書タイプ」レジストリは、次のように更新されました。

1. Values 0 (X.509) and 1 (OpenPGP) are defined in this document.

1. このドキュメントでは、値0（X.509）および1（OpenPGP）が定義されています。

2. Values from 2 through 223 decimal inclusive are assigned via "RFC Required" [RFC5226].

2. 2から223までの10進数の値は、「RFCが必要」[RFC5226]によって割り当てられます。

3. Values from 224 decimal through 255 decimal inclusive are reserved for Private Use [RFC5226].

3. 10進数で224から10進数で255までの値は、個人使用のために予約されています[RFC5226]。

6. Acknowledgements

6. 謝辞

The authors wish to thank Alfred Hoenes and Ted Hardie for their suggestions on improving this document.

著者は、このドキュメントを改善するための提案をしてくれたAlfred HoenesとTed Hardieに感謝します。

7. References

7. 参考文献

7.1. Normative References

7.1. 引用文献

[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月。

[RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. Thayer, "OpenPGP Message Format", RFC 4880, November 2007.

[RFC4880] Callas、J.、Donnerhacke、L.、Finney、H.、Shaw、D。、およびR. Thayer、「OpenPGP Message Format」、RFC 4880、2007年11月。

[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.

[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月。

[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.

[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.2」、RFC 5246、2008年8月。

[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, January 2011.

[RFC6066] Eastlake 3rd、D。、「Transport Layer Security（TLS）Extensions：Extension Definitions」、RFC 6066、2011年1月。

7.2. Informative References

7.2. 参考引用

[RFC5081] Mavrogiannopoulos, N., "Using OpenPGP Keys for Transport Layer Security (TLS) Authentication", RFC 5081, November 2007.

[RFC5081] Mavrogiannopoulos、N。、「トランスポート層セキュリティ（TLS）認証のためのOpenPGPキーの使用」、RFC 5081、2007年11月。

[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 Public Key Infrastructure Certificate and Certificate Revocation List（CRL）Profile "、RFC 5280、2008年5月。

Appendix A. Changes from RFC 5081

付録A. RFC 5081からの変更点

This document incorporates a major change in the "Server Certificate" and "Client Certificate" TLS messages that will make implementations following this protocol incompatible with those following [RFC5081]. This change requires the subkey IDs used for TLS authentication to be marked explicitly in the handshake procedure. This was decided in order to place no limitation on the OpenPGP certificates' contents that can be used with this protocol.

このドキュメントは、「サーバー証明書」と「クライアント証明書」のTLSメッセージに大きな変更を組み込んでおり、このプロトコルに従う実装は[RFC5081]に従うものと互換性がありません。この変更では、ハンドシェイク手順でTLS認証に使用されるサブキーIDを明示的にマークする必要があります。これは、このプロトコルで使用できるOpenPGP証明書の内容を制限しないために決定されました。

[RFC5081] required that an OpenPGP key or subkey be marked with the authentication flag; thus, authentication would have failed if this flag was not set or if this flag was set in more than one subkey. The protocol in this memo has no such limitation.

[RFC5081]は、OpenPGPキーまたはサブキーに認証フラグを付ける必要がありました。したがって、このフラグが設定されていない場合、またはこのフラグが複数のサブキーに設定されている場合、認証は失敗します。このメモのプロトコルにはそのような制限はありません。

Authors' Addresses

著者のアドレス

Nikos Mavrogiannopoulos ESAT/COSIC Katholieke Universiteit Leuven Kasteelpark Arenberg 10, bus 2446 Leuven-Heverlee, B-3001 Belgium

Nikos Mavrogiannopoulos ESAT / COSIC Katholieke Universiteit Leuven Kasteelpark Arenberg 10、box 2446 Leuven-Heverlee、B-3001 Belgium

   EMail: nikos.mavrogiannopoulos@esat.kuleuven.be

Daniel Kahn Gillmor Independent 119 Herkimer St. Brooklyn, NY 11216-2801 US

ダニエルカーンギルモアインディペンデント119 Herkimer St. Brooklyn、NY 11216-2801 US

   EMail: dkg@fifthhorseman.net