[要約] RFC 5081は、Transport Layer Security（TLS）認証のためにOpenPGPキーを使用する方法についての規格です。このRFCの目的は、OpenPGPキーをTLS認証に使用するための手順と要件を提供することです。
Network Working Group N. Mavrogiannopoulos
Request for Comments: 5081 Independent
Category: Experimental November 2007
Using OpenPGP Keys for Transport Layer Security (TLS) Authentication
輸送層のセキュリティ（TLS）認証にOpenPGPキーを使用する
Status of This Memo
本文書の位置付け
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティの実験プロトコルを定義します。いかなる種類のインターネット標準を指定しません。改善のための議論と提案が要求されます。このメモの配布は無制限です。
Abstract
概要
This memo proposes extensions to the Transport Layer Security (TLS) protocol to support the OpenPGP key format. The extensions discussed here include a certificate type negotiation mechanism, and the required modifications to the TLS Handshake Protocol.
このメモは、OpenPGPキー形式をサポートするために、Transport Layer Security（TLS）プロトコルへの拡張を提案しています。ここで説明する拡張機能には、証明書の種類交渉メカニズムと、TLSハンドシェイクプロトコルの必要な変更が含まれます。
Table of Contents
目次
1. Introduction ....................................................2
2. Terminology .....................................................2
3. Changes to the Handshake Message Contents .......................2
3.1. Client Hello ...............................................2
3.2. Server Hello ...............................................3
3.3. Server Certificate .........................................3
3.4. Certificate Request ........................................4
3.5. Client Certificate .........................................5
3.6. Other Handshake Messages ...................................5
4. Security Considerations .........................................5
5. IANA Considerations .............................................6
6. Acknowledgements ................................................6
7. References ......................................................6
7.1. Normative References .......................................6
7.2. Informative References .....................................7
The IETF has two sets of standards for public key certificates, one set for use of X.509 certificates [PKIX] and one for OpenPGP certificates [OpenPGP]. At the time of writing, TLS [TLS] standards are defined to use only X.509 certificates. This document specifies a way to negotiate 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証明書[PKIX]を使用するためのセット、1つはOpenPGP証明書[OpenPGP]に1つあります。執筆時点では、TLS [TLS]標準はX.509証明書のみを使用するように定義されています。このドキュメントは、TLSセッションのOpenPGP証明書の使用を交渉する方法を指定し、TLSを介してOpenPGP証明書を輸送する方法を指定します。提案されている拡張機能は、現在のTLS仕様との逆方向に互換性があるため、X.509証明書を使用する既存のクライアントとサーバーの実装は影響を受けません。
The term "OpenPGP key" is used in this document as in the OpenPGP specification [OpenPGP]. We use the term "OpenPGP certificate" to refer to OpenPGP keys that are enabled for authentication.
「OpenPGPキー」という用語は、OpenPGP仕様[OpenPGP]のように、このドキュメントで使用されます。「OpenPGP証明書」という用語を使用して、認証のために有効になっているOpenPGPキーを参照します。
This document uses the same notation and terminology used in the TLS Protocol specification [TLS].
このドキュメントでは、TLSプロトコル仕様[TLS]で使用されるのと同じ表記と用語を使用します。
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]に記載されているように解釈される。
This section describes the changes to the TLS handshake message contents when OpenPGP certificates are to be used for authentication.
このセクションでは、OpenPGP証明書を認証に使用する場合のTLSハンドシェイクメッセージコンテンツの変更について説明します。
In order to indicate the support of multiple certificate types, clients MUST include an extension of type "cert_type" (see Section 5) to the extended client hello message. The hello extension mechanism is described in [TLSEXT].
複数の証明書タイプのサポートを示すために、クライアントは拡張クライアントのHelloメッセージにタイプ「CERT_TYPE」（セクション5を参照）の拡張機能を含める必要があります。Hello Extensionメカニズムは[TLSEXT]で説明されています。
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.
この拡張機能には、クライアントが使用できるサポートされている証明書タイプのリストが搭載されており、クライアントの好みでソートされています。クライアントがX.509証明書のみをサポートする場合、この拡張機能を省略する必要があります。この拡張機能の「extension_data」フィールドには、certificatateTypeextension構造が含まれています。
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 compatible, with the key, key exchange method can be used in combination with OpenPGP certificates.
OpenPGP証明書を使用するには、新しい暗号スイートは必要ありません。互換性のあるキーのキー交換方法をサポートするすべての既存の暗号スイートは、OpenPGP証明書と組み合わせて使用できます。
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 connection with a fatal alert of type "unsupported_certificate".
サーバーが「CERT_TYPE」拡張機能を含むクライアントのHelloを受信し、証明書を必要とする暗号スイートを選択すると、2つの結果が可能です。サーバーは、拡張クライアントのextendedクライアントのcertifation_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.
サーバーによって選択された証明書の種類は、タイプ「CERT_TYPE」の拡張機能を使用して、拡張サーバーのHelloメッセージに含まれるCertificatateTypeextension構造でエンコードされます。X.509証明書のみをサポートするサーバーは、拡張サーバーHelloの「CERT_TYPE」拡張機能を含めて省略できます。
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.
サーバーからクライアントに送信され、その逆に送信された証明書メッセージの内容は、ネゴシエートされた証明書タイプと選択したCipher Suiteのキー交換アルゴリズムによって決定されます。
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 DSS public key that can be used for authentication.
DHE_DSS DSS認証に使用できる公開キー。
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 [OpenPGP].
証明書メッセージに表示されるOpenPGP証明書は、バイナリOpenPGP形式を使用して送信されます。証明書には、[OpenPGP]のセクション11.1で必要なすべての要素が含まれている必要があります。
The option is also available to send an OpenPGP fingerprint, instead of sending the entire certificate. The process of fingerprint generation is described in Section 12.2 of [OpenPGP]. 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 4 of [TLSEXT].
このオプションは、証明書全体を送信する代わりに、OpenPGP指紋を送信するためにも利用できます。指紋生成のプロセスは、[openPGP]のセクション12.2で説明されています。ピアは、指定された指紋を持つ証明書が見つからない場合、「証明書_Unobtainable」致命的なアラートで応答するものとします。「certificate_unobtainable」致命的なアラートは、[tlsext]のセクション4で定義されています。
enum {
cert_fingerprint (0), cert (1), (255)
} OpenPGPCertDescriptorType;
opaque OpenPGPCertFingerprint<16..20>;
opaque OpenPGPCert<0..2^24-1>;
struct {
OpenPGPCertDescriptorType descriptorType;
select (descriptorType) {
case cert_fingerprint: OpenPGPCertFingerprint;
case cert: OpenPGPCert;
}
} Certificate;
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」リストは空でなければなりません。
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 that contains an empty OpenPGPCert vector MUST be sent. The server SHOULD respond with a "handshake_failure" fatal alert if client authentication is required.
このメッセージは、証明書要求メッセージに応じてのみ送信されます。クライアント証明書メッセージは、サーバー証明書メッセージと同じフォーマットを使用して送信されます。また、交渉された証明書の種類に一致する証明書を提示する必要もあります。OpenPGP証明書が選択されており、クライアントから証明書が利用できない場合、空のOpenPGPCERTベクターを含む証明書構造を送信する必要があります。クライアント認証が必要な場合、サーバーは「handshake_failure」致命的なアラートで応答する必要があります。
All the other handshake messages are identical to the TLS specification.
他のすべてのハンドシェイクメッセージは、TLS仕様と同じです。
All security considerations discussed in [TLS], [TLSEXT], and [OpenPGP] apply to this document. Considerations about the use of the web of trust or identity and certificate verification procedure are outside the scope of this document. These are considered issues to be handled by the application layer protocols.
[TLS]、[TLSEXT]、および[OpenPGP]で説明されているすべてのセキュリティ上の考慮事項がこのドキュメントに適用されます。信頼またはアイデンティティのWebの使用に関する考慮事項と証明書検証手順は、このドキュメントの範囲外です。これらは、アプリケーションレイヤープロトコルによって処理される問題と見なされます。
The protocol for certificate type negotiation is identical in operation to ciphersuite negotiation of the [TLS] specification 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 ciphersuites, it is believed that the security properties of this negotiation are the same as with ciphersuite negotiation.
証明書タイプの交渉のプロトコルは、拡張機能が省略されたときにデフォルト値を追加すると、[TLS]仕様の暗号化された交渉と同一です。これらの省略は独自の意味を持ち、Ciphersuitesと同じように価値に同じ保護が適用されるため、この交渉のセキュリティプロパティはCiphersuite交渉と同じであると考えられています。
When using OpenPGP fingerprints instead of the full certificates, the discussion in Section 6.3 of [TLSEXT] 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 [OpenPGP]).
完全な証明書の代わりにOpenPGP指紋を使用する場合、「クライアント証明書URL」の[TLSEXT]のセクション6.3の議論は、特に外部サーバーを使用してキーを取得する場合に適用されます。ただし、大きな違いは、「client_certificate_url」拡張機能により、証明書のハッシュを含めることなく証明書を識別することができますが、これはここで提案されているプロトコルでは不可能です。このプロトコルでは、送信されない場合、証明書は常に指紋によって識別されます。これは、証明書の暗号化ハッシュとして機能します（[OpenPGP]のセクション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 certificates.
参加パーティーや盗聴者が利用できる情報（以前の握手で機密性が利用できない場合）は、保持している証明書の数とタイプに加えて、証明書の内容です。
This document defines a new TLS extension, "cert_type", assigned a value of 9 from the TLS ExtensionType registry defined in [TLSEXT]. This value is used as the extension number for the extensions in both the client hello message and the server hello message. The new extension type is used for certificate type negotiation.
このドキュメントでは、[TLSEXT]で定義されたTLS拡張タイプレジストリから9の値を割り当てた新しいTLS拡張機能「CERT_TYPE」を定義します。この値は、クライアントのhelloメッセージとサーバーのhelloメッセージの両方の拡張機能の拡張機能として使用されます。新しい拡張タイプは、証明書タイプの交渉に使用されます。
The "cert_type" extension contains an 8-bit CertificateType field, for which a new registry, named "TLS Certificate Types", is established in this document, to be maintained by IANA. The registry is segmented in the following way:
「CERT_TYPE」拡張機能には、「TLS証明書タイプ」という名前の新しいレジストリがこのドキュメントに確立され、IANAによって維持される8ビットの証明書型フィールドが含まれています。レジストリは次の方法でセグメント化されます。
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 IETF Consensus [RFC2434].
2. 2〜223の小数包含的値は、IETFコンセンサス[RFC2434]を介して割り当てられます。
3. Values from 224 decimal through 255 decimal inclusive are reserved for Private Use [RFC2434].
3. 224 10進数から255小数包括的値からの値は、私的使用のために予約されています[RFC2434]。
This document was based on earlier work made by Will Price and Michael Elkins.
この文書は、ウィルプライスとマイケルエルキンスの以前の作品に基づいています。
The author wishes to thank Werner Koch, David Taylor, Timo Schulz, Pasi Eronen, Jon Callas, Stephen Kent, Robert Sparks, and Hilarie Orman for their suggestions on improving this document.
著者は、この文書の改善に関する提案について、Werner Koch、David Taylor、Timo Schulz、Pasi Eronen、Jon Callas、Stephen Kent、Robert Sparks、Hilarie Ormanに感謝したいと考えています。
[TLS] Dierks, T. and E. Rescorla, "The TLS Protocol Version 1.1", RFC 4346, April 2006.
[TLS] Dierks、T。およびE. Rescorla、「TLSプロトコルバージョン1.1」、RFC 4346、2006年4月。
[OpenPGP] Callas, J., Donnerhacke, L., Finey, H., Shaw, D., and R. Thayer, "OpenPGP Message Format", RFC 4880, November 2007.
[OpenPGP] Callas、J.、Donnerhacke、L.、Finey、H.、Shaw、D。、およびR. Thayer、「OpenPGPメッセージ形式」、RFC 4880、2007年11月。
[TLSEXT] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 4366, April 2006.
[Tlsext] Blake-Wilson、S.、Nystrom、M.、Hopwood、D.、Mikkelsen、J。、およびT. Wright、「Transport Layer Security（TLS）Extensions」、RFC 4366、2006年4月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 2434, October 1998.
[RFC2434] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、RFC 2434、1998年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、RFC 2119、1997年3月。
[PKIX] Housley, R., Ford, W., Polk, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
[Pkix] Housley、R.、Ford、W.、Polk、W。、およびD. Solo、「インターネットX.509公開キーインフラストラクチャ証明書および証明書取消リスト（CRL）プロファイル」、RFC 3280、2002年4月。
Author's Address
著者の連絡先
Nikos Mavrogiannopoulos Independent Arkadias 8 Halandri, Attiki 15234 Greece
Nikos Mavrogiannopoulos Independer Arkadias 8 Halandri、Attiki 15234ギリシャ
EMail: nmav@gnutls.org
URI: http://www.gnutls.org/
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
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.
この文書は、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, THE IETF TRUST 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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
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への情報をお問い合わせください。