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
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的通用原始公钥支持
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密钥交换版本2（IKEv2）协议确实支持原始公钥，但它只支持RSA原始公钥。在受限环境中，使用其他类型的公钥是很有用的，例如基于椭圆曲线密码的公钥。本文档更新了RFC 7296，为IKEv2添加了对其他类型原始公钥的支持。
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/rfc7670.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7670.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 IETF信托基金和确定为文件作者的人员。版权所有。
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)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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 . . . . . . . . . . . . . . . . . . . . . . . . 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
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密钥交换版本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编码的RSA公钥结构（参见[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中描述的数字签名方法。
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_NULL类型[RFC7619]可用于指示ID有效负载与此身份验证无关。
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
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 ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 证书编码（1个八位字节）-此字段指示证书数据字段中包含的证书类型或证书相关信息。
Certificate Encoding Value
----------------------------------------------------
Raw Public Key 15
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.
为了在编码类型为“原始公钥”时提供指示密钥类型的简单标准方法，使用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.
除了证书有效负载外，原始公钥的证书编码还可以用于证书请求有效负载。在这种情况下，如果使用“原始公钥”证书编码，则证书颁发机构字段必须为空。
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不是证书的一部分，而是作为证书数据字段发送，实现也必须遵循PKIX的RSA加密附加算法和标识符（[RFC4055]）第1.2节中的公钥处理规则。这意味着在适用时必须发送SubjectPublicKeyInfo结构中的RSASSA-PSS和RSASSA PSS参数。
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部署需要利用带外公钥验证过程，以确保所用密钥的真实性。实现此目标的一种方法是使用配置机制将原始公钥提供到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].
另一种方法是依靠安全DNS，使用IPSECKEY DNS RRtype[RFC4025]将公钥与域名相关联。更多信息可以在基于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.
由于[RFC5996]中的IKEv2中已经提供了“原始RSA密钥”支持，因此本文档不会更改IKEv2规范所做的安全性假设。本文档仅概括了原始公钥支持。
This document allocates a new value from the IKEv2 Certificate Encodings registry:
本文档从IKEv2证书编码注册表分配一个新值：
15 Raw Public Key
15原始公钥
[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公钥基础设施证书和证书撤销列表（CRL）配置文件”，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，“互联网密钥交换协议版本2（IKEv2）”，STD 79，RFC 7296，DOI 10.17487/RFC72962014年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）中的空身份验证方法”，RFC 7619，DOI 10.17487/RFC7619，2015年8月<http://www.rfc-editor.org/info/rfc7619>.
[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，“公钥密码标准（PKCS）#1:RSA密码规范版本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.，“在DNS中存储IPsec密钥材料的方法”，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，“传输层安全（TLS）协议版本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]Turner，S.，Brown，D.，Yiu，K.，Housley，R.，和T.Polk，“椭圆曲线加密主题公钥信息”，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]巴恩斯，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.，和T.Kivinen，“在传输层安全性（TLS）和数据报传输层安全性（DTLS）中使用原始公钥”，RFC 7250，DOI 10.17487/RFC72502014年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月。
This appendix provides examples of the actual payloads sent on the wire.
本附录提供了通过电线发送的实际有效载荷的示例。
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
cb28e099 9b9c7715 fd0a80d8 e47a7707 9716cbbf 917dd72e 97566ea1 c066957c
o Public key y coordinate:
o 公钥y坐标：
2b57c023 5fb74897 68d058ff 4911c20f dbe71e36 99d91339 afbb903e e17255dc
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:对象标识符id ecPublicKey（1.2.840.10045.2.1）000d:对象标识符secp256r1（1.2.840.10045.3.1.7）0017:位字符串（66字节）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
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）表示没有“未使用位数”，第二个字节（04）表示未压缩形式（[RFC5480]）。这两个八位组后面是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 30130607 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
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 0004 00000020:cb28 e099 9b9c 7715 fd0a 80d8 e47a 770700000030:9716 cbbf 917d d72e 9756 6ea1 c066 957c 00000040:2b57 c023 5fb7 4897 68d0 58ff 4911 C2000000050:DBE36 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是下一个有效载荷类型（即，紧跟在该证书有效载荷之后的有效载荷类型）。
This second example uses a random 1024-bit RSA key.
第二个示例使用一个随机的1024位RSA密钥。
The public key is as follows:
公钥如下所示：
o Algorithm: rsaEncryption (1.2.840.113549.1.1.1)
o 算法：RSA加密（1.2.840.113549.1.1.1）
o Modulus n (1024 bits, decimal):
o 模数n（1024位，十进制）：
1323562071162740912417075551025599045700 3972512968992059076067098474693867078469 7654066339302927451756327389839253751712 9485277759962777278073526290329821841100 9721044682579432931952695408402169276996 5181887843758615443536914372816830537901 8976615344413864477626646564638249672329 04996914356093900776754835411
1323562071162740912417075551025599045700 3972512968992059076067098474693867078469 7654066339302927451756327389839253751712 9485277759962777278073526290329821841100 9721044682579432931952695408402169276996 5181887843758615443536914372816830537901 8976615344413864477626646564638249672329 04996914356093900776754835411
o Modulus n (1024 bits, hexadecimal):
o 模数n（1024位，十六进制）：
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
bc7b4347 49c7b386 00bfa84b 44f88187 9a2dda08 d1f0145a f5806c2a ed6a6172 ff0dc3d4 cd601638 e8ca348e bdca5742 CADC97 12e209b1 fddba58a 8c62b369 038a3d1e aa727c1f 39AE496 EBC30F8 d9b52e23 385a4019 1585C59 be72f343 fb1eb87b 16FFC50F8FE9 ecfa1230 66F335
o Exponent e (17 bits, decimal): 65537
o 指数e（17位，十进制）：65537
o Exponent e (17 bits, hexadecimal): 10001
o 指数e（17位，十六进制）：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:SEQUENCE 0003:SEQUENCE 0005:对象标识符RSA加密（1.2.840.113549.1.1）0016:NULL 0018:位字符串（141字节）00000000:0030 8189 0281 8100 bc7b 4347 49c7 b386 000000 10:00bf a84b 44f8 8187 9a2d da08 d1f0 145a 00000020:f580 6c2a ed6a 6172 ff0d c3d4 cd60 1638 000000 30:e8ca 348e bdca 5742 31ca dc97 12E209B1 00000040:fddb a58a 8c62 b369 038a 3d1e aa72 7c1f 00000050:39ae 49ed 6ebc 30f8 d9b5 5A 3819 00000060:1585 8c59 be72 FBF B7c5ab 000000 70:0f8f 8fe9 f7cb 3e66 3d8f e9f9 ecfa 1230 000000 80: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）表示没有“未使用位数”。在该位字符串中，有一个ASN.1序列有2个整数。第二个字节（30）表示这是序列的开始，下一个字节（81）表示长度不适合7位，但需要一个字节，因此长度在下一个字节（89）中。然后用标记（02）和长度（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
00000000:3081 9f30 0d06 092a 8648 86f7 0d01 0101000000:0500 0381 8d00 3081 8902 8181 00bc 7b43 000000 20:4749 c7b3 8600 bfa8 4b44 f881 879a 2dda 00000030:08d1 f014 5af5 806c 2ED 6a61 72ff 0dc3 00000040:d4cd 6016 38e8 ca34 8ebd ca57 4231 cadc 00000050:9712 e209 b1fd 8a8c 62B36903 8D DBA 00000060:08d1 f014 5af5 806c 2E BC600000070: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 000000 A0:0001
This will result in the final IKEv2 Certificate Payload:
这将导致最终的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 000000 10:f70d 0101 0105 0003 818d 0030 8189 0281 000000 20:8100 bc7b 4347 49c7 b386 00bf a84b 44f8 000000 30:8187 9a2d da08 d1f0 145a f580 6c2a ED6A00000040:6172 ff0d c3d4 cd60 1638 e8ca 348e bdca 00000050:5742 31ca dc97 12e2 09b1 fddb a58a C62 000000 60:8169 038a aa72 AED C1396EBC00000070: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 000000 A0: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 Kinkatu 28赫尔辛基FI-00180芬兰
Email: kivinen@iki.fi
Email: kivinen@iki.fi
Paul Wouters Red Hat
保罗·沃特斯红帽
Email: pwouters@redhat.com
Email: pwouters@redhat.com
Hannes Tschofenig
汉内斯·乔菲尼
Email: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at
Email: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at