RFC 6605 - Elliptic Curve Digital Signature Algorithm (DSA) for DNSSEC 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc6605
タイトル : RFC 6605 - DNSSEC用の楕円曲線デジタル署名アルゴリズム（DSA）
翻訳編集 : 自動生成

[要約] RFC 6605は、DNSSECにおける楕円曲線デジタル署名アルゴリズム（DSA）に関する仕様です。このRFCの目的は、DNSSECにおいてより効率的でセキュアな署名アルゴリズムを提供することです。

Internet Engineering Task Force (IETF)                        P. Hoffman
Request for Comments: 6605                                VPN Consortium
Category: Standards Track                              W.C.A. Wijngaards
ISSN: 2070-1721                                               NLnet Labs
                                                              April 2012

Elliptic Curve Digital Signature Algorithm (DSA) for DNSSEC

DNSSEC用の楕円曲線デジタル署名アルゴリズム（DSA）

Abstract

概要

This document describes how to specify Elliptic Curve Digital Signature Algorithm (DSA) keys and signatures in DNS Security (DNSSEC). It lists curves of different sizes and uses the SHA-2 family of hashes for signatures.

このドキュメントでは、DNSセキュリティ（DNSSEC）で楕円曲線デジタル署名アルゴリズム（DSA）のキーと署名を指定する方法について説明します。さまざまなサイズのカーブをリストし、署名にSHA-2ファミリーのハッシュを使用します。

Status of This Memo

本文書の状態

This is an Internet Standards Track document.

これは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). Further information on Internet Standards is available in Section 2 of RFC 5741.

このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、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/rfc6605.

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

著作権表示

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に記載されているように保証なしで提供されます。

1. Introduction

1. はじめに

DNSSEC, which is broadly defined in RFCs 4033, 4034, and 4035 ([RFC4033], [RFC4034], and [RFC4035]), uses cryptographic keys and digital signatures to provide authentication of DNS data. Currently, the most popular signature algorithm is RSA with SHA-1, using keys that are 1024 or 2048 bits long.

RFC 4033、4034、および4035（[RFC4033]、[RFC4034]、および[RFC4035]）で広く定義されているDNSSECは、暗号鍵とデジタル署名を使用してDNSデータの認証を提供します。現在、最も一般的な署名アルゴリズムは、1024または2048ビット長のキーを使用するSHA-1を使用したRSAです。

This document defines the DNSKEY and RRSIG resource records (RRs) of two new signing algorithms: ECDSA (Elliptic Curve DSA) with curve P-256 and SHA-256, and ECDSA with curve P-384 and SHA-384. (A description of ECDSA can be found in [FIPS-186-3].) This document also defines the DS RR for the SHA-384 one-way hash algorithm; the associated DS RR for SHA-256 is already defined in RFC 4509 [RFC4509]. [RFC6090] provides a good introduction to implementing ECDSA.

このドキュメントでは、2つの新しい署名アルゴリズムのDNSKEYおよびRRSIGリソースレコード（RR）を定義します。曲線P-256およびSHA-256のECDSA（楕円曲線DSA）、および曲線P-384およびSHA-384のECDSA。（ECDSAの説明は[FIPS-186-3]にあります。）このドキュメントでは、SHA-384一方向ハッシュアルゴリズムのDS RRも定義しています。 SHA-256に関連付けられたDS RRは、RFC 4509 [RFC4509]ですでに定義されています。 [RFC6090]は、ECDSAの実装に関する優れた紹介を提供します。

Current estimates are that ECDSA with curve P-256 has an approximate equivalent strength to RSA with 3072-bit keys. Using ECDSA with curve P-256 in DNSSEC has some advantages and disadvantages relative to using RSA with SHA-256 and with 3072-bit keys. ECDSA keys are much shorter than RSA keys; at this size, the difference is 256 versus 3072 bits. Similarly, ECDSA signatures are much shorter than RSA signatures. This is relevant because DNSSEC stores and transmits both keys and signatures.

現在の推定では、曲線P-256を使用するECDSAは、3072ビットの鍵を使用するRSAとほぼ同等の強度を持っています。 DNSSECで曲線P-256とECDSAを使用すると、RSAをSHA-256と3072ビットキーで使用する場合と比べて、いくつかの利点と欠点があります。 ECDSA鍵はRSA鍵よりもはるかに短いです。このサイズでは、差は256対3072ビットです。同様に、ECDSA署名はRSA署名よりもはるかに短いです。 DNSSECはキーと署名の両方を保存および送信するため、これは重要です。

In the two signing algorithms defined in this document, the size of the key for the elliptic curve is matched with the size of the output of the hash algorithm. This design is based on the widespread belief that the equivalent strength of P-256 and P-384 is half the length of the key, and also that the equivalent strength of SHA-256 and SHA-384 is half the length of the key. Using matched strengths prevents an attacker from choosing the weaker half of a signature algorithm. For example, in a signature that uses RSA with 2048-bit keys and SHA-256, the signing portion is significantly weaker than the hash portion, whereas the two algorithms here are balanced.

このドキュメントで定義されている2つの署名アルゴリズムでは、楕円曲線のキーのサイズは、ハッシュアルゴリズムの出力のサイズと一致しています。この設計は、P-256とP-384の同等の強度はキーの長さの半分であり、SHA-256とSHA-384の同等の強度はキーの長さの半分であるという広範な信念に基づいています。一致する強度を使用すると、攻撃者は署名アルゴリズムの弱い方を選択できなくなります。たとえば、2048ビットキーとSHA-256でRSAを使用する署名では、署名部分はハッシュ部分よりもかなり弱いですが、ここでの2つのアルゴリズムはバランスが取れています。

Signing with ECDSA is significantly faster than with RSA (over 20 times in some implementations). However, validating RSA signatures is significantly faster than validating ECDSA signatures (about 5 times faster in some implementations).

ECDSAを使用した署名は、RSAを使用した場合よりも大幅に高速です（一部の実装では20回以上）。ただし、RSA署名の検証は、ECDSA署名の検証よりも大幅に高速です（一部の実装では約5倍高速）。

Some of the material in this document is copied liberally from RFC 6460 [RFC6460].

このドキュメントの一部の資料は、RFC 6460 [RFC6460]から自由にコピーされています。

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 RFC 2119 [RFC2119].

このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。

2. SHA-384 DS Records

2. SHA-384 DSレコード

SHA-384 is defined in FIPS 180-3 [FIPS-180-3] and RFC 6234 [RFC6234], and is similar to SHA-256 in many ways. The implementation of SHA-384 in DNSSEC follows the implementation of SHA-256 as specified in RFC 4509 except that the underlying algorithm is SHA-384, the digest value is 48 bytes long, and the digest type code is 4.

SHA-384はFIPS 180-3 [FIPS-180-3]およびRFC 6234 [RFC6234]で定義されており、多くの点でSHA-256に似ています。 DNSSECでのSHA-384の実装は、基になるアルゴリズムがSHA-384、ダイジェスト値が48バイト、ダイジェストタイプコードが4であることを除いて、RFC 4509で指定されているSHA-256の実装に従います。

3. ECDSA Parameters

3. ECDSAパラメータ

Verifying ECDSA signatures requires agreement between the signer and the verifier of the parameters used. FIPS 186-3 [FIPS-186-3] lists some NIST-recommended elliptic curves. (Other documents give more detail on ECDSA than is given in FIPS 186-3.) These are the same curves listed in RFC 5114 [RFC5114]. The curves used in this document are:

ECDSA署名を検証するには、使用するパラメーターの署名者と検証者の間で合意が必要です。 FIPS 186-3 [FIPS-186-3]には、NIST推奨の楕円曲線がいくつかリストされています。（他のドキュメントでは、FIPS 186-3で提供されているものよりもECDSAの詳細が説明されています。）これらは、RFC 5114 [RFC5114]にリストされている曲線と同じです。このドキュメントで使用されている曲線は次のとおりです。

   FIPS 186-3                  RFC 5114
   ------------------------------------------------------------------
   P-256 (Section D.1.2.3)     256-bit Random ECP Group (Section 2.6)
   P-384 (Section D.1.2.4)     384-bit Random ECP Group (Section 2.7)

4. DNSKEY and RRSIG Resource Records for ECDSA

4. ECDSAのDNSKEYおよびRRSIGリソースレコード

ECDSA public keys consist of a single value, called "Q" in FIPS 186-3. In DNSSEC keys, Q is a simple bit string that represents the uncompressed form of a curve point, "x | y".

ECDSA公開鍵は、FIPS 186-3では「Q」と呼ばれる単一の値で構成されます。 DNSSECキーでは、Qは単純なビット文字列で、非圧縮形式の曲線ポイント「x | y」を表します。

The ECDSA signature is the combination of two non-negative integers, called "r" and "s" in FIPS 186-3. The two integers, each of which is formatted as a simple octet string, are combined into a single longer octet string for DNSSEC as the concatenation "r | s". (Conversion of the integers to bit strings is described in Section C.2 of FIPS 186-3.) For P-256, each integer MUST be encoded as 32 octets; for P-384, each integer MUST be encoded as 48 octets.

ECDSA署名は、FIPS 186-3で「r」と「s」と呼ばれる2つの非負整数の組み合わせです。それぞれが単純なオクテット文字列としてフォーマットされている2つの整数は、連結 "r | s"としてDNSSECの単一の長いオクテット文字列に結合されます。（整数からビット文字列への変換は、FIPS 186-3のセクションC.2で説明されています。）P-256の場合、各整数は32オクテットとしてエンコードする必要があります。 P-384の場合、各整数は48オクテットとしてエンコードされる必要があります。

The algorithm numbers associated with the DNSKEY and RRSIG resource records are fully defined in the IANA Considerations section. They are:

DNSKEYおよびRRSIGリソースレコードに関連付けられたアルゴリズム番号は、IANAに関する考慮事項のセクションで完全に定義されています。彼らです：

o DNSKEY and RRSIG RRs signifying ECDSA with the P-256 curve and SHA-256 use the algorithm number 13.

o P-256曲線およびSHA-256でECDSAを示すDNSKEYおよびRRSIG RRは、アルゴリズム番号13を使用します。

o DNSKEY and RRSIG RRs signifying ECDSA with the P-384 curve and SHA-384 use the algorithm number 14.

o P-384曲線およびSHA-384でECDSAを示すDNSKEYおよびRRSIG RRは、アルゴリズム番号14を使用します。

Conformant implementations that create records to be put into the DNS MUST implement signing and verification for both of the above algorithms. Conformant DNSSEC verifiers MUST implement verification for both of the above algorithms.

DNSに入れるレコードを作成する適合実装は、上記の両方のアルゴリズムの署名と検証を実装する必要があります。適合DNSSEC検証者は、上記の両方のアルゴリズムの検証を実装する必要があります。

5. Support for NSEC3 Denial of Existence

5. NSEC3存在拒否のサポート

RFC 5155 [RFC5155] defines new algorithm identifiers for existing signing algorithms to indicate that zones signed with these algorithm identifiers can use NSEC3 as well as NSEC records to provide denial of existence. That mechanism was chosen to protect implementations predating RFC 5155 from encountering resource records they could not know about. This document does not define such algorithm aliases.

RFC 5155 [RFC5155]は、既存の署名アルゴリズムの新しいアルゴリズム識別子を定義して、これらのアルゴリズム識別子で署名されたゾーンがNSEC3とNSECレコードを使用して存在を拒否できることを示しています。このメカニズムは、RFC 5155より前の実装が、知らないリソースレコードに遭遇しないようにするために選択されました。このドキュメントでは、このようなアルゴリズムのエイリアスを定義していません。

A DNSSEC validator that implements the signing algorithms defined in this document MUST be able to validate negative answers in the form of both NSEC and NSEC3 with hash algorithm 1, as defined in RFC 5155. An authoritative server that does not implement NSEC3 MAY still serve zones that use the signing algorithms defined in this document with NSEC denial of existence.

このドキュメントで定義されている署名アルゴリズムを実装するDNSSECバリデーターは、RFC 5155で定義されているように、ハッシュアルゴリズム1を使用してNSECとNSEC3の両方の形式で否定応答を検証できる必要があります。NSEC3を実装しない信頼できるサーバーは、引き続きゾーンにサービスを提供できます（MAY）。このドキュメントで定義されている署名アルゴリズムとNSECの存在拒否を使用するもの。

6. Examples

6. 例

The following are some examples of ECDSA keys and signatures in DNS format.

以下は、DNS形式のECDSA鍵と署名の例です。

6.1. P-256 Example

6.1. P-256の例

   Private-key-format: v1.2
   Algorithm: 13 (ECDSAP256SHA256)
   PrivateKey: GU6SnQ/Ou+xC5RumuIUIuJZteXT2z0O/ok1s38Et6mQ=

   example.net. 3600 IN DNSKEY 257 3 13 (
           GojIhhXUN/u4v54ZQqGSnyhWJwaubCvTmeexv7bR6edb
           krSqQpF64cYbcB7wNcP+e+MAnLr+Wi9xMWyQLc8NAA== )

example.net. 3600 IN DS 55648 13 2 ( b4c8c1fe2e7477127b27115656ad6256f424625bf5c1 e2770ce6d6e37df61d17 )

example.net。 3600 IN DS 55648 13 2（b4c8c1fe2e7477127b27115656ad6256f424625bf5c1 e2770ce6d6e37df61d17）

www.example.net. 3600 IN A 192.0.2.1 www.example.net. 3600 IN RRSIG A 13 3 3600 ( 20100909100439 20100812100439 55648 example.net. qx6wLYqmh+l9oCKTN6qIc+bw6ya+KJ8oMz0YP107epXA yGmt+3SNruPFKG7tZoLBLlUzGGus7ZwmwWep666VCw== )

www.example.net。 32.0 IN A 192.0.2.1 www.example.net。 3600 IN RRSIG A 13 3 3600（20100909100439 20100812100439 55648 example.net。qx6wLYqmh + l9oCKTN6qIc + bw6ya + KJ8oMz0YP107epXA yGmt + 3SNruPFKG7tZoLBLlUzGGus7ZwmwWep666VCw =）

6.2. P-384 Example

6.2. P-384の例

Private-key-format: v1.2 Algorithm: 14 (ECDSAP384SHA384) PrivateKey: WURgWHCcYIYUPWgeLmiPY2DJJk02vgrmTfitxgqcL4vw W7BOrbawVmVe0d9V94SR

秘密鍵の形式：v1.2アルゴリズム：14（ECDSAP384SHA384）秘密鍵：WURgWHCcYIYUPWgeLmiPY2DJJk02vgrmTfitxgqcL4vw W7BOrbawVmVe0d9V94SR

   example.net. 3600 IN DNSKEY 257 3 14 (
           xKYaNhWdGOfJ+nPrL8/arkwf2EY3MDJ+SErKivBVSum1
           w/egsXvSADtNJhyem5RCOpgQ6K8X1DRSEkrbYQ+OB+v8
           /uX45NBwY8rp65F6Glur8I/mlVNgF6W/qTI37m40 )

example.net. 3600 IN DS 10771 14 4 ( 72d7b62976ce06438e9c0bf319013cf801f09ecc84b8 d7e9495f27e305c6a9b0563a9b5f4d288405c3008a94 6df983d6 )

example.net。 3600 IN DS 10771 14 4（72d7b62976ce06438e9c0bf319013cf801f09ecc84b8 d7e9495f27e305c6a9b0563a9b5f4d288405c3008a94 6df983d6）

www.example.net. 3600 IN A 192.0.2.1 www.example.net. 3600 IN RRSIG A 14 3 3600 ( 20100909102025 20100812102025 10771 example.net. /L5hDKIvGDyI1fcARX3z65qrmPsVz73QD1Mr5CEqOiLP 95hxQouuroGCeZOvzFaxsT8Glr74hbavRKayJNuydCuz WTSSPdz7wnqXL5bdcJzusdnI0RSMROxxwGipWcJm )

www.example.net。 32.0 IN A 192.0.2.1 www.example.net。 3600 IN RRSIG A 14 3 3600（20100909102025 20100812102025 10771 example.net。/ L5hDKIvGDyI1fcARX3z65qrmPsVz73QD1Mr5CEqOiLP 95hxQouuroGCeZOvzFaxsT8Glr74hbavRKayJNuydcwjdmwdzcwjdzdwdzwdzwdzzwdzwdzwzdwzdzwzdzwzdzzwdzzwdzwdzwmwdzwdwdwddd0e）

7. IANA Considerations

7. IANAに関する考慮事項

This document updates the IANA registry for digest types in DS records, currently called "Delegation Signer (DS) Resource Record (RR) Type Digest Algorithms". The following entry has been added:

このドキュメントは、現在「委任署名者（DS）リソースレコード（RR）タイプダイジェストアルゴリズム」と呼ばれているDSレコードのダイジェストタイプのIANAレジストリを更新します。次のエントリが追加されました。

Value 4 Digest Type SHA-384 Status OPTIONAL

値4ダイジェストタイプSHA-384ステータスオプション

This document updates the IANA registry "Domain Name System Security (DNSSEC) Algorithm Numbers". The following two entries have been added to the registry:

このドキュメントは、IANAレジストリ「ドメインネームシステムセキュリティ（DNSSEC）アルゴリズム番号」を更新します。次の2つのエントリがレジストリに追加されました。

Number 13 Description ECDSA Curve P-256 with SHA-256 Mnemonic ECDSAP256SHA256 Zone Signing Y Trans. Sec. * Reference This document

番号13説明ECDSA曲線P-256、SHA-256ニーモニック付きECDSAP256SHA256ゾーン署名Yトランザクション。 Sec。 *このドキュメントを参照

Number 14 Description ECDSA Curve P-384 with SHA-384 Mnemonic ECDSAP384SHA384 Zone Signing Y Trans. Sec. * Reference This document

番号14説明ECDSA曲線P-384、SHA-384ニーモニック付きECDSAP384SHA384ゾーン署名Yトランス。 Sec。 *このドキュメントを参照

* There has been no determination of standardization of the use of this algorithm with Transaction Security.

* Transaction Securityでのこのアルゴリズムの使用の標準化の決定はありません。

8. Security Considerations

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

The cryptographic work factor of ECDSA with curve P-256 or P-384 is generally considered to be equivalent to half the size of the key, or 128 bits and 192 bits, respectively. Such an assessment could, of course, change in the future if new attacks that work better than the ones known today are found.

曲線P-256またはP-384を使用するECDSAの暗号化作業係数は、通常、鍵のサイズの半分、つまりそれぞれ128ビットと192ビットに相当すると見なされます。もちろん、そのような評価は、今日知られている攻撃よりもうまく機能する新しい攻撃が見つかった場合、将来的に変更される可能性があります。

The security considerations listed in RFC 4509 apply here as well.

RFC 4509にリストされているセキュリティの考慮事項もここに適用されます。

9. References

9. 参考文献

9.1. Normative References

9.1. 引用文献

[FIPS-180-3] National Institute of Standards and Technology, U.S. Department of Commerce, "Secure Hash Standard (SHS)", FIPS 180-3, October 2008.

[FIPS-180-3]米国国立標準技術研究所、米国商務省、「Secure Hash Standard（SHS）」、FIPS 180-3、2008年10月。

[FIPS-186-3] National Institute of Standards and Technology, U.S. Department of Commerce, "Digital Signature Standard", FIPS 186-3, June 2009.

[FIPS-186-3]米国国立標準技術研究所、米国商務省、「デジタル署名標準」、FIPS 186-3、2009年6月。

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

[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.

[RFC4033] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNSセキュリティの概要と要件」、RFC 4033、2005年3月。

[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005.

[RFC4034] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNS Security Extensionsのリソースレコード」、RFC 4034、2005年3月。

[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005.

[RFC4035] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNSセキュリティ拡張機能のプロトコル変更」、RFC 4035、2005年3月。

[RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs)", RFC 4509, May 2006.

[RFC4509] Hardaker、W。、「DNSSEC委任署名者（DS）リソースレコード（RR）でのSHA-256の使用」、RFC 4509、2006年5月。

[RFC5114] Lepinski, M. and S. Kent, "Additional Diffie-Hellman Groups for Use with IETF Standards", RFC 5114, January 2008.

[RFC5114] Lepinski、M。およびS. Kent、「IETF標準で使用するための追加のDiffie-Hellmanグループ」、RFC 5114、2008年1月。

[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS Security (DNSSEC) Hashed Authenticated Denial of Existence", RFC 5155, March 2008.

[RFC5155] Laurie、B.、Sisson、G.、Arends、R。、およびD. Blacka、「DNS Security（DNSSEC）Hashed Authenticated Denial of Existence」、RFC 5155、2008年3月。

9.2. Informative References

9.2. 参考引用

[RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic Curve Cryptography Algorithms", RFC 6090, February 2011.

[RFC6090] McGrew、D.、Igoe、K。、およびM. Salter、「Fundamental Elliptic Curve Cryptography Algorithms」、RFC 6090、2011年2月。

[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011.

[RFC6234] Eastlake 3rd、D。およびT. Hansen、「US Secure Hash Algorithms（SHA and SHA-based HMAC and HKDF）」、RFC 6234、2011年5月。

[RFC6460] Salter, M. and R. Housley, "Suite B Profile for Transport Layer Security (TLS)", RFC 6460, January 2012.

[RFC6460]ソルターM.およびR.ハウズリー、「トランスポート層セキュリティ（TLS）のスイートBプロファイル」、RFC 6460、2012年1月。

Authors' Addresses

著者のアドレス

Paul Hoffman VPN Consortium

ポールホフマンVPNコンソーシアム

   EMail: paul.hoffman@vpnc.org

Wouter C.A. Wijngaards NLnet Labs

Wouter C.A.ヴィンヤーズNLnetラボ

   EMail: wouter@nlnetlabs.nl