RFC 7670 - Generic Raw Public-Key Support for IKEv2 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc7670
タイトル : RFC 7670 - IKEv2の汎用Raw公開鍵サポート
翻訳編集 : 自動生成

[要約] RFC 7670は、IKEv2における一般的な生の公開鍵サポートを提供するための仕様です。その目的は、IKEv2プロトコルで生の公開鍵を使用するための一般的な方法を定義することです。

Internet Engineering Task Force (IETF)                        T. Kivinen
Request for Comments: 7670                                 INSIDE Secure
Updates: 7296                                                 P. Wouters
Category: Standards Track                                        Red Hat
ISSN: 2070-1721                                            H. Tschofenig
                                                            January 2016

Generic Raw Public-Key Support for IKEv2

IKEv2の汎用Raw公開鍵サポート

Abstract

概要

The Internet Key Exchange Version 2 (IKEv2) protocol did have support for raw public keys, but it only supported RSA raw public keys. In constrained environments, it is useful to make use of other types of public keys, such as those based on Elliptic Curve Cryptography. This document updates RFC 7296, adding support for other types of raw public keys to IKEv2.

Internet Key Exchangeバージョン2（IKEv2）プロトコルは未加工の公開鍵をサポートしていましたが、RSA未加工の公開鍵のみをサポートしていました。制約のある環境では、楕円曲線暗号に基づくものなど、他のタイプの公開鍵を利用すると便利です。このドキュメントはRFC 7296を更新し、IKEv2に他のタイプの生の公開鍵のサポートを追加します。

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/rfc7670.

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

著作権表示

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 . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Certificate Encoding Payload  . . . . . . . . . . . . . . . .   3
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .   5
     6.2.  Informative References  . . . . . . . . . . . . . . . . .   5
   Appendix A.  Examples . . . . . . . . . . . . . . . . . . . . . .   7
     A.1.  ECDSA Example . . . . . . . . . . . . . . . . . . . . . .   7
     A.2.  RSA Example . . . . . . . . . . . . . . . . . . . . . . .   8
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1. Introduction

1. はじめに

This document replaces an algorithm-specific version of raw public keys of the Internet Key Exchange Version 2 (IKEv2) [RFC7296] with a generic version of raw public keys that is algorithm agnostic.

このドキュメントは、Internet Key Exchangeバージョン2（IKEv2）[RFC7296]の生の公開鍵のアルゴリズム固有のバージョンを、アルゴリズムにとらわれない生の公開鍵の一般的なバージョンに置き換えます。

In [RFC5996], IKEv2 had support for PKCS #1 encoded RSA keys, i.e., a DER-encoded RSAPublicKey structure (see [RSA] and [RFC3447]). Other raw public-key types are, however, not supported. In [RFC7296], this feature was removed; this document reintroduces support for raw public keys to IKEv2 in a more generic way.

[RFC5996]では、IKEv2はPKCS＃1でエンコードされたRSAキー、つまりDERエンコードされたRSAPublicKey構造をサポートしていました（[RSA]および[RFC3447]を参照）。ただし、他の生の公開鍵タイプはサポートされていません。 [RFC7296]では、この機能は削除されました。このドキュメントでは、IKEv2への未加工の公開鍵のサポートをより一般的な方法で再紹介しています。

DNSSEC allows public keys to be associated with domain names for usage with security protocols like IKEv2 and Transport Layer Security (TLS) [RFC5246] but it relies on extensions in those protocols to be specified.

DNSSECでは、IKEv2やトランスポート層セキュリティ（TLS）[RFC5246]などのセキュリティプロトコルで使用するために、公開鍵をドメイン名に関連付けることができますが、これらのプロトコルの拡張を指定する必要があります。

The Raw Public Keys in Transport Layer Security specification ([RFC7250]) adds generic support for raw public keys to TLS by reusing the SubjectPublicKeyInfo format from the X.509 Public-Key Infrastructure Certificate profile [RFC5280].

トランスポート層セキュリティ仕様（[RFC7250]）の未加工公開鍵は、X.509公開鍵インフラストラクチャ証明書プロファイル[RFC5280]のSubjectPublicKeyInfo形式を再利用することにより、未加工公開鍵の一般的なサポートをTLSに追加します。

This document is similar to the Raw Public Keys in Transport Layer Security specification and applies the concept to IKEv2 to support all public-key formats defined by PKIX. This approach also allows future public-key extensions to be supported without the need to introduce further enhancements to IKEv2.

このドキュメントは、トランスポート層セキュリティ仕様の未加工の公開鍵に類似しており、その概念をIKEv2に適用して、PKIXで定義されたすべての公開鍵形式をサポートします。このアプローチでは、IKEv2をさらに拡張する必要なく、将来の公開鍵拡張をサポートできます。

To support new types of public keys in IKEv2, the following changes are needed:

IKEv2で新しいタイプの公開鍵をサポートするには、次の変更が必要です。

o A new Certificate Encoding format needs to be defined for carrying the SubjectPublicKeyInfo structure. Section 3 specifies this new encoding format.

o SubjectPublicKeyInfo構造を伝送するには、新しい証明書エンコーディング形式を定義する必要があります。セクション3では、この新しいエンコード形式を指定しています。

o A new Certificate Encoding that has been allocated by IANA. Section 5 contains the details about the IANA registration.

o IANAによって割り当てられた新しい証明書エンコーディング。セクション5には、IANA登録の詳細が含まれています。

The base IKEv2 specification includes support for RSA and DSA signatures, but the Signature Authentication in IKEv2 [RFC7427] extended IKEv2 so that signature methods over any key type can be used. Implementations using raw public keys SHOULD use the Digital Signature method described in RFC 7427.

基本のIKEv2仕様には、RSAおよびDSA署名のサポートが含まれていますが、IKEv2の署名認証[RFC7427]はIKEv2を拡張したので、任意の鍵タイプの署名方式を使用できます。生の公開鍵を使用する実装では、RFC 7427で説明されているデジタル署名方式を使用する必要があります（SHOULD）。

When using raw public keys, the authenticated identity is not usually the identity from the ID payload, but instead the public key itself is used as the identity for the other end. This means that ID payload contents might not be useful for authentication purposes. It might still be used for policy decisions, for example to simplify the policy lookup. Alternatively, the ID_NULL type [RFC7619] can be used to indicate that the ID payload is not relevant to this authentication.

生の公開鍵を使用する場合、認証されたIDは通常、IDペイロードのIDではなく、公開鍵自体が相手側のIDとして使用されます。これは、IDペイロードの内容が認証の目的には役に立たない可能性があることを意味します。たとえば、ポリシーの検索を簡素化するために、ポリシーの決定に引き続き使用される場合があります。または、ID_NULLタイプ[RFC7619]を使用して、IDペイロードがこの認証に関連しないことを示すことができます。

2. Terminology

2. 用語

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. Certificate Encoding Payload

3. 証明書エンコーディングペイロード

Section 3.6 of RFC 7296 defines the Certificate payload format as shown in Figure 1.

RFC 7296のセクション3.6は、図1に示すように、証明書のペイロード形式を定義しています。

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Next Payload  |C|  RESERVED   |         Payload Length        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Cert Encoding |                                               |
   +-+-+-+-+-+-+-+-+                                               |
   ~                       Certificate Data                        ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 1: Certificate Payload Format

図1：証明書のペイロード形式

To support raw public keys, the field values are as follows:

生の公開鍵をサポートするためのフィールド値は次のとおりです。

o Certificate Encoding (1 octet) - This field indicates the type of certificate or certificate-related information contained in the Certificate Data field.

o Certificate Encoding（1 octet）-このフィールドは、Certificate Dataフィールドに含まれる証明書または証明書関連の情報のタイプを示します。

      Certificate Encoding                 Value
      ----------------------------------------------------
      Raw Public Key                       15

o Certificate Data (variable length) - Actual encoding of the certificate data.

o 証明書データ（可変長）-証明書データの実際のエンコード。

In order to provide a simple and standard way to indicate the key type when the encoding type is "Raw Public Key", the SubjectPublicKeyInfo structure of the PKIX certificate is used. This is a very simple encoding, as most of the ASN.1 part can be included literally and recognized by block comparison. See Appendix A of [RFC7250] for a detailed breakdown. In addition, Appendix A of this document has several examples.

エンコーディングタイプが「Raw Public Key」の場合にキータイプを示す簡単で標準的な方法を提供するために、PKIX証明書のSubjectPublicKeyInfo構造が使用されます。 ASN.1のほとんどの部分は文字どおりに含めることができ、ブロック比較で認識できるため、これは非常に単純なエンコーディングです。詳細な内訳については、[RFC7250]の付録Aをご覧ください。さらに、このドキュメントの付録Aにはいくつかの例があります。

In addition to the Certificate payload, the Cert Encoding for Raw Public Key can be used in the Certificate Request payload. In that case, the Certification Authority field MUST be empty if the "Raw Public Key" certificate encoding is used.

証明書ペイロードに加えて、未加工の公開鍵の証明書エンコーディングを証明書要求ペイロードで使用できます。その場合、「Raw Public Key」証明書エンコーディングが使用される場合、Certification Authorityフィールドは空でなければなりません。

For RSA keys, the implementations MUST follow the public-key processing rules of Section 1.2 of the Additional Algorithms and Identifiers for RSA Cryptography for PKIX ([RFC4055]) even when the SubjectPublicKeyInfo is not part of a certificate but is instead sent as a Certificate Data field. This means that RSASSA-PSS and RSASSA-PSS-params inside the SubjectPublicKeyInfo structure MUST be sent when applicable.

RSAキーの場合、SubjectPublicKeyInfoが証明書の一部ではなく、証明書として送信される場合でも、実装は、RSK Cryptography for PKIX（[RFC4055]）のセクション1.2の追加アルゴリズムと識別子の公開キー処理規則に従う必要があります。データフィールド。つまり、SubjectPublicKeyInfo構造内のRSASSA-PSSおよびRSASSA-PSS-paramsは、該当する場合に送信する必要があります。

4. Security Considerations

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

An IKEv2 deployment using raw public keys needs to utilize an out-of-band public-key validation procedure to be confident in the authenticity of the keys being used. One way to achieve this goal is to use a configuration mechanism for provisioning raw public keys into the IKEv2 software. "Smart object" deployments are likely to use such preconfigured public keys.

未加工の公開鍵を使用するIKEv2の展開では、使用される鍵の信頼性を確保するために、帯域外の公開鍵の検証手順を利用する必要があります。この目標を達成する1つの方法は、生の公開鍵をIKEv2ソフトウェアにプロビジョニングするための構成メカニズムを使用することです。「スマートオブジェクト」の展開では、このような事前設定された公開鍵が使用される可能性があります。

Another approach is to rely on secure DNS to associate public keys with domain names using the IPSECKEY DNS RRtype [RFC4025]. More information can be found in DNS-Based Authentication of Named Entities (DANE) [RFC6394].

別のアプローチは、IPSECKEY DNS RRtype [RFC4025]を使用して、公開鍵をドメイン名に関連付けるために安全なDNSに依存することです。詳細については、名前付きエンティティのDNSベースの認証（DANE）[RFC6394]を参照してください。

This document does not change the security assumptions made by the IKEv2 specification since "Raw RSA Key" support was already available in IKEv2 in [RFC5996]. This document only generalizes raw public-key support.

[Raw RSA Key]サポートは[RFC5996]のIKEv2ですでに利用可能だったため、このドキュメントはIKEv2仕様で行われたセキュリティの前提を変更しません。このドキュメントでは、生の公開鍵サポートのみを一般化しています。

5. IANA Considerations

5. IANAに関する考慮事項

This document allocates a new value from the IKEv2 Certificate Encodings registry:

このドキュメントでは、IKEv2 Certificate Encodingsレジストリから新しい値を割り当てます。

15 Raw Public Key

15生の公開鍵

6. References

6. 参考文献

6.1. Normative References

6.1. 引用文献

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。

[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, DOI 10.17487/RFC5280, May 2008, <http://www.rfc-editor.org/info/rfc5280>.

[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、DOI 10.17487 / RFC5280、2008年5月、<http://www.rfc-editor.org/info/rfc5280>。

[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2014, <http://www.rfc-editor.org/info/rfc7296>.

[RFC7296] Kaufman、C.、Hoffman、P.、Nir、Y.、Eronen、P。、およびT. Kivinen、「Internet Key Exchange Protocol Version 2（IKEv2）」、STD 79、RFC 7296、DOI 10.17487 / RFC7296 、2014年10月、<http://www.rfc-editor.org/info/rfc7296>。

[RFC7427] Kivinen, T. and J. Snyder, "Signature Authentication in the Internet Key Exchange Version 2 (IKEv2)", RFC 7427, DOI 10.17487/RFC7427, January 2015, <http://www.rfc-editor.org/info/rfc7427>.

[RFC7427] Kivinen、T。およびJ. Snyder、「インターネットキーエクスチェンジバージョン2（IKEv2）での署名認証」、RFC 7427、DOI 10.17487 / RFC7427、2015年1月、<http://www.rfc-editor.org / info / rfc7427>。

[RFC7619] Smyslov, V. and P. Wouters, "The NULL Authentication Method in the Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 7619, DOI 10.17487/RFC7619, August 2015, <http://www.rfc-editor.org/info/rfc7619>.

[RFC7619] Smyslov、V。およびP. Wouters、「インターネットキーエクスチェンジプロトコルバージョン2（IKEv2）のNULL認証方式」、RFC 7619、DOI 10.17487 / RFC7619、2015年8月、<http：//www.rfc- editor.org/info/rfc7619>。

6.2. Informative References

6.2. 参考引用

[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, DOI 10.17487/RFC3447, February 2003, <http://www.rfc-editor.org/info/rfc3447>.

[RFC3447] Jonsson、J。およびB. Kaliski、「Public-Key Cryptography Standards（PKCS）＃1：RSA Cryptography Specifications Version 2.1」、RFC 3447、DOI 10.17487 / RFC3447、2003年2月、<http：//www.rfc -editor.org/info/rfc3447>。

[RFC4025] Richardson, M., "A Method for Storing IPsec Keying Material in DNS", RFC 4025, DOI 10.17487/RFC4025, March 2005, <http://www.rfc-editor.org/info/rfc4025>.

[RFC4025] Richardson、M。、「A Method for Storing IPsec Keying Material in DNS」、RFC 4025、DOI 10.17487 / RFC4025、2005年3月、<http://www.rfc-editor.org/info/rfc4025>。

[RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 4055, DOI 10.17487/RFC4055, June 2005, <http://www.rfc-editor.org/info/rfc4055>.

[RFC4055] Schaad、J.、Kaliski、B。、およびR. Housley、「インターネットX.509公開鍵インフラストラクチャ証明書および証明書失効リスト（CRL）プロファイルで使用するためのRSA暗号化の追加のアルゴリズムと識別子」、RFC 4055 、DOI 10.17487 / RFC4055、2005年6月、<http://www.rfc-editor.org/info/rfc4055>。

[RFC4754] Fu, D. and J. Solinas, "IKE and IKEv2 Authentication Using the Elliptic Curve Digital Signature Algorithm (ECDSA)", RFC 4754, DOI 10.17487/RFC4754, January 2007, <http://www.rfc-editor.org/info/rfc4754>.

[RFC4754] Fu、D。およびJ. Solinas、「楕円曲線デジタル署名アルゴリズム（ECDSA）を使用したIKEおよびIKEv2認証」、RFC 4754、DOI 10.17487 / RFC4754、2007年1月、<http：//www.rfc-editor .org / info / rfc4754>。

[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>.

[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.2」、RFC 5246、DOI 10.17487 / RFC5246、2008年8月、<http://www.rfc-editor.org/info / rfc5246>。

[RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, "Elliptic Curve Cryptography Subject Public Key Information", RFC 5480, DOI 10.17487/RFC5480, March 2009, <http://www.rfc-editor.org/info/rfc5480>.

[RFC5480]ターナー、S。、ブラウン、D。、ユウ、K。、ハウズリー、R。、およびT.ポーク、「楕円曲線暗号化サブジェクト公開鍵情報」、RFC 5480、DOI 10.17487 / RFC5480、2009年3月、< http://www.rfc-editor.org/info/rfc5480>。

[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, DOI 10.17487/RFC5996, September 2010, <http://www.rfc-editor.org/info/rfc5996>.

[RFC5996] Kaufman、C.、Hoffman、P.、Nir、Y。、およびP. Eronen、「インターネットキー交換プロトコルバージョン2（IKEv2）」、RFC 5996、DOI 10.17487 / RFC5996、2010年9月、<http：/ /www.rfc-editor.org/info/rfc5996>。

[RFC6394] Barnes, R., "Use Cases and Requirements for DNS-Based Authentication of Named Entities (DANE)", RFC 6394, DOI 10.17487/RFC6394, October 2011, <http://www.rfc-editor.org/info/rfc6394>.

[RFC6394] Barnes、R。、「名前付きエンティティのDNSベースの認証（DANE）の使用例と要件」、RFC 6394、DOI 10.17487 / RFC6394、2011年10月、<http://www.rfc-editor.org/ info / rfc6394>。

[RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., Weiler, S., and T. Kivinen, "Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, June 2014, <http://www.rfc-editor.org/info/rfc7250>.

[RFC7250] Wouters、P.、Ed。、Tschofenig、H.、Ed。、Gilmore、J.、Weiler、S.、and T. Kivinen、 "Using Raw Public Keys in Transport Layer Security（TLS）and Datagram Transport Layerセキュリティ（DTLS）」、RFC 7250、DOI 10.17487 / RFC7250、2014年6月、<http://www.rfc-editor.org/info/rfc7250>。

[RSA] Rivest, R., Shamir, A., and L. Adleman, "A Method for Obtaining Digital Signatures and Public-Key Cryptosystems", February 1978.

[RSA] Rivest、R.、Shamir、A。、およびL. Adleman、「デジタル署名および公開鍵暗号システムを取得する方法」、1978年2月。

Appendix A. Examples

付録A.例

This appendix provides examples of the actual payloads sent on the wire.

この付録では、ネットワーク上で送信される実際のペイロードの例を示します。

A.1. ECDSA Example

A.1. ECDSAの例

This first example uses the 256-bit ECDSA private/public key pair defined in Section 8.1 of the IKEv2 ECDSA document [RFC4754].

この最初の例では、IKEv2 ECDSAドキュメント[RFC4754]のセクション8.1で定義されている256ビットECDSA秘密/公開鍵ペアを使用しています。

The public key is as follows:

公開鍵は次のとおりです。

o Algorithm: id-ecPublicKey (1.2.840.10045.2.1)

o アルゴリズム：id-ecPublicKey（1.2.840.10045.2.1）

o Fixed curve: secp256r1 (1.2.840.10045.3.1.7)

o 固定曲線：secp256r1（1.2.840.10045.3.1.7）

o Public key x coordinate:

o 公開鍵のx座標：

cb28e099 9b9c7715 fd0a80d8 e47a7707 9716cbbf 917dd72e 97566ea1 c066957c

o Public key y coordinate:

o 公開鍵のy座標：

2b57c023 5fb74897 68d058ff 4911c20f dbe71e36 99d91339 afbb903e e17255dc

The SubjectPublicKeyInfo ASN.1 object is as follows:

SubjectPublicKeyInfo ASN.1オブジェクトは次のとおりです。

0000 : SEQUENCE 0002 : SEQUENCE 0004 : OBJECT IDENTIFIER id-ecPublicKey (1.2.840.10045.2.1) 000d : OBJECT IDENTIFIER secp256r1 (1.2.840.10045.3.1.7) 0017 : BIT STRING (66 bytes) 00000000: 0004 cb28 e099 9b9c 7715 fd0a 80d8 e47a 00000010: 7707 9716 cbbf 917d d72e 9756 6ea1 c066 00000020: 957c 2b57 c023 5fb7 4897 68d0 58ff 4911 00000030: c20f dbe7 1e36 99d9 1339 afbb 903e e172 00000040: 55dc

0000：シーケンス0002：シーケンス0004：オブジェクトIDENTIFIER id-ecPublicKey（1.2.840.10045.2.1）000d：オブジェクトID secp256r1（1.2.840.10045.3.1.7）0017：ビット文字列（66バイト）00000000：0004 cb28 e099 9b9c 7715 fd 80d8 e47a 00000010：7707 9716 cbbf 917d d72e 9756 6ea1 c066 00000020：957c 2b57 c023 5fb7 4897 68d0 58ff 4911 00000030：c20f dbe7 1e36 99d9 1339 afbb 903e e172 00000040：55dc

The first byte (00) of the bit string indicates that there is no "number of unused bits", and the second byte (04) indicates uncompressed form ([RFC5480]). Those two octets are followed by the values of X and Y.

ビット列の最初のバイト（00）は「未使用ビット数」がないことを示し、2番目のバイト（04）は非圧縮形式（[RFC5480]）を示します。これらの2つのオクテットの後にXとYの値が続きます。

The final encoded SubjectPublicKeyInfo object is as follows:

最終的にエンコードされたSubjectPublicKeyInfoオブジェクトは次のとおりです。

00000000: 3059 3013 0607 2a86 48ce 3d02 0106 082a 00000010: 8648 ce3d 0301 0703 4200 04cb 28e0 999b 00000020: 9c77 15fd 0a80 d8e4 7a77 0797 16cb bf91 00000030: 7dd7 2e97 566e a1c0 6695 7c2b 57c0 235f 00000040: b748 9768 d058 ff49 11c2 0fdb e71e 3699 00000050: d913 39af bb90 3ee1 7255 dc

00000000：3059 3013 0607 2a86 48ce 3d02 0106 082a 00000010：8648 ce3d 0301 0703 4200 04cb 28e0 999b 00000020：9c77 15fd 0a80 d8e4 7a77 0797 16cb bf91 00000030：7dd7 2e97 566e a1c0c0c0c0c0c0c0c0c0c0c0f0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c956c0c0c0c7c0c0c0c0c0c0c0c0c0e0e0e0e0e0e0e0e00 00000050：d913 39af bb90 3ee1 7255 dc

This will result in the final IKEv2 Certificate Payload:

これにより、最終的なIKEv2証明書のペイロードが生成されます。

00000000: NN00 0060 0f30 5930 1306 072a 8648 ce3d 00000010: 0201 0608 2a86 48ce 3d03 0107 0342 0004 00000020: cb28 e099 9b9c 7715 fd0a 80d8 e47a 7707 00000030: 9716 cbbf 917d d72e 9756 6ea1 c066 957c 00000040: 2b57 c023 5fb7 4897 68d0 58ff 4911 c20f 00000050: dbe7 1e36 99d9 1339 afbb 903e e172 55dc

00000000：NN00 0060 0f30 5930 1306 072a 8648 CE3d 00000010：0201 0608 2a86 48ce 3d03 0107 0342 000420000 00000020：cb28 e099 9b9c 7715 fd0a 80d8 e47a 7707 00000030：9716 cbbf cbbf 917d d72000e 9756 d977e16e 16756 eaf 956d ddd72000 20007d7d92000e7d9e56e7af 956d 00000050：dbe7 1e36 99d9 1339 afbb 903e e172 55dc

Where NN is the next payload type (i.e., the type of payload that immediately follows this Certificate payload).

ここで、NNは次のペイロードタイプです（つまり、この証明書ペイロードの直後に続くペイロードのタイプ）。

A.2. RSA Example

A.2. RSAの例

This second example uses a random 1024-bit RSA key.

この2番目の例では、ランダムな1024ビットRSA鍵を使用しています。

The public key is as follows:

公開鍵は次のとおりです。

o Algorithm: rsaEncryption (1.2.840.113549.1.1.1)

o アルゴリズム：rsaEncryption（1.2.840.113549.1.1.1）

o Modulus n (1024 bits, decimal):

o 係数n（1024ビット、10進数）：

1323562071162740912417075551025599045700 3972512968992059076067098474693867078469 7654066339302927451756327389839253751712 9485277759962777278073526290329821841100 9721044682579432931952695408402169276996 5181887843758615443536914372816830537901 8976615344413864477626646564638249672329 04996914356093900776754835411

o Modulus n (1024 bits, hexadecimal):

o 係数n（1024ビット、16進数）：

bc7b4347 49c7b386 00bfa84b 44f88187 9a2dda08 d1f0145a f5806c2a ed6a6172 ff0dc3d4 cd601638 e8ca348e bdca5742 31cadc97 12e209b1 fddba58a 8c62b369 038a3d1e aa727c1f 39ae49ed 6ebc30f8 d9b52e23 385a4019 15858c59 be72f343 fb1eb87b 16ffc5ab 0f8f8fe9 f7cb3e66 3d8fe9f9 ecfa1230 66f36835 8ceaefd3

o Exponent e (17 bits, decimal): 65537

o 指数e（17ビット、10進数）：65537

o Exponent e (17 bits, hexadecimal): 10001

o 指数e（17ビット、16進数）：10001

The SubjectPublicKeyInfo ASN.1 object is as follows:

SubjectPublicKeyInfo ASN.1オブジェクトは次のとおりです。

0000 : SEQUENCE 0003 : SEQUENCE 0005 : OBJECT IDENTIFIER rsaEncryption (1.2.840.113549.1.1.1) 0016 : NULL 0018 : BIT STRING (141 bytes) 00000000: 0030 8189 0281 8100 bc7b 4347 49c7 b386 00000010: 00bf a84b 44f8 8187 9a2d da08 d1f0 145a 00000020: f580 6c2a ed6a 6172 ff0d c3d4 cd60 1638 00000030: e8ca 348e bdca 5742 31ca dc97 12e2 09b1 00000040: fddb a58a 8c62 b369 038a 3d1e aa72 7c1f 00000050: 39ae 49ed 6ebc 30f8 d9b5 2e23 385a 4019 00000060: 1585 8c59 be72 f343 fb1e b87b 16ff c5ab 00000070: 0f8f 8fe9 f7cb 3e66 3d8f e9f9 ecfa 1230 00000080: 66f3 6835 8cea efd3 0203 0100 01

0000：シーケンス0003：シーケンス0005：オブジェクトID rsaEncryption（1.2.840.113549.1.1.1）0016：NULL 0018：ビット文字列（141バイト）00000000：0030 8189 0281 8100 bc7b 4347 49c7 b386 00000010：00bf a84b 44f8 8187 9a2d da08 145a 00000020：f580 6c2a ed6a 6172 ff0d c3d4 cd60 1638 00000030：e8ca 348e bdca 5742 31ca dc97 12e2 09b1 00000040：fddb a58a 8c62 b369 038a 3d1e ab72 7c1f 00000050：39f823b 23c8e 23b e53c 23b 23b e23b e23b e23b e23c 8e bc e3c e3e3e e3e3e e3e3e e3e3e3e3e3e3e3e3e3e2e2e3e3e3e3e3e3e4e2e2e3e2e3e2e2e3e2e3e8e3bb3e3bb3e5e5e5e5e5e8e5e20bb8e5e5e5bb8bb3d8e5bb3b3bb3b3b3b3b3b3b3b3b3b3b3b3b3b方方c5ab 00000070：0f8f 8fe9 f7cb 3e66 3d8f e9f9 ecfa 1230 00000080：66f3 6835 8cea efd3 0203 0100 01

The first byte (00) of the bit string indicates that there is no "number of unused bits". Inside that bit string, there is an ASN.1 sequence having 2 integers. The second byte (30) indicates that this is the beginning of the sequence, and the next byte (81) indicates the length does not fit in 7 bits, but requires one byte, so the length is in the next byte (89). Then starts the first integer with tag (02) and length (81 81). After that we have the modulus (prefixed with 0 so it will not be a negative number). After the modulus, there follows the tag (02) and length (03) of the exponent, and the last 3 bytes are the exponent.

ビット列の最初のバイト（00）は、「未使用ビット数」がないことを示します。そのビット文字列内には、2つの整数を持つASN.1シーケンスがあります。 2番目のバイト（30）はこれがシーケンスの始まりであることを示し、次のバイト（81）は長さが7ビットに収まらないが1バイトを必要とすることを示しているため、長さは次のバイト（89）にあります。次に、最初の整数をタグ（02）と長さ（81 81）で開始します。その後、モジュラスを取得します（0が前に付いているため、負の数にはなりません）。係数の後には、指数のタグ（02）と長さ（03）が続き、最後の3バイトは指数です。

The final encoded SubjectPublicKeyInfo object is as follows:

最終的にエンコードされたSubjectPublicKeyInfoオブジェクトは次のとおりです。

00000000: 3081 9f30 0d06 092a 8648 86f7 0d01 0101 00000010: 0500 0381 8d00 3081 8902 8181 00bc 7b43 00000020: 4749 c7b3 8600 bfa8 4b44 f881 879a 2dda 00000030: 08d1 f014 5af5 806c 2aed 6a61 72ff 0dc3 00000040: d4cd 6016 38e8 ca34 8ebd ca57 4231 cadc 00000050: 9712 e209 b1fd dba5 8a8c 62b3 6903 8a3d 00000060: 1eaa 727c 1f39 ae49 ed6e bc30 f8d9 b52e 00000070: 2338 5a40 1915 858c 59be 72f3 43fb 1eb8 00000080: 7b16 ffc5 ab0f 8f8f e9f7 cb3e 663d 8fe9 00000090: f9ec fa12 3066 f368 358c eaef d302 0301 000000a0: 0001 This will result in the final IKEv2 Certificate Payload:

00000000：3081 9f30 0d06 092a 8648 86f7 0d01 0101 00000010：0500 0381 8d00 3081 8902 8181 00bc 7b43 00000020：4749 c7b3 8600 bfa8 4b44 f881 879a 2dda 00000030：08d1 f014 5af5 806c 2dc3d3e40e 6dc6e4040 4040e40e40e60e6d6e4e40e40e6d4d3e60e60d0d3d3e60e60d0d0e3d4d0d0d3d0d3d0d0e0 00000050：9712 e209 b1fd dba5 8a8c 62b3 6903 8a3d 00000060：1eaa 727c 1f39 ae49 ed6e bc30 f8d9 b52e 00000070：2338 5a40 1915 858c 59be 72f3 43fb 1ef8 ff6 ff5 af0 ff5 af0 ff5 ab0f0 ff6 af0 ff5 af0 ff5 ab0f0 000000a0：0001これにより、最終的なIKEv2証明書のペイロードが生成されます。

00000000: NN00 00a7 0f30 819f 300d 0609 2a86 4886 00000010: f70d 0101 0105 0003 818d 0030 8189 0281 00000020: 8100 bc7b 4347 49c7 b386 00bf a84b 44f8 00000030: 8187 9a2d da08 d1f0 145a f580 6c2a ed6a 00000040: 6172 ff0d c3d4 cd60 1638 e8ca 348e bdca 00000050: 5742 31ca dc97 12e2 09b1 fddb a58a 8c62 00000060: b369 038a 3d1e aa72 7c1f 39ae 49ed 6ebc 00000070: 30f8 d9b5 2e23 385a 4019 1585 8c59 be72 00000080: f343 fb1e b87b 16ff c5ab 0f8f 8fe9 f7cb 00000090: 3e66 3d8f e9f9 ecfa 1230 66f3 6835 8cea 000000a0: efd3 0203 0100 01

00000000：NN00 00a7 0f30 819f 300d 0609 2a86 4886 00000010：f70d 0101 0105 0003 818d 0030 8189 0281 00000020：8100 bc7b 4347 49c7 b386 00bf a84b 44f8 00000030：8187 00000050：5742 31ca dc97 12e2 09b1 fddb a58a 8c62 00000060：b369 038a 3d1e aa72 7c1f 39ae 49ed 6ebc 00000070：30f8 d9b5 2e23 385a 4019 1585 8c59 be72 800080：f3400 ecf 8c59 f72f400400400：f3400 ecf 8c59 f72f400400400：80 000000a0：efd3 0203 0100 01

Where NN is the next payload type (i.e., the type of the payload that immediately follows this Certificate payload).

ここで、NNは次のペイロードタイプ（つまり、この証明書ペイロードの直後に続くペイロードのタイプ）です。

Acknowledgements

謝辞

This document reproduces some parts of the similar TLS document ([RFC7250]).

このドキュメントは、同様のTLSドキュメント（[RFC7250]）の一部を複製します。

Authors' Addresses

著者のアドレス

Tero Kivinen INSIDE Secure Eerikinkatu 28 Helsinki FI-00180 Finland

Tero Kivinen INSIDE Secure Eerikinkatu 28ヘルシンキFI-00180フィンランド

   Email: kivinen@iki.fi

Paul Wouters Red Hat

ポール・ウーターズレッドハット

   Email: pwouters@redhat.com

Hannes Tschofenig

ハネス・チョフェニグ

   Email: Hannes.Tschofenig@gmx.net
   URI:   http://www.tschofenig.priv.at