[要約] RFC 8951は、Enrollment over Secure Transport (EST)に関する明確化を提供し、特に転送エンコーディングとASN.1の使用に焦点を当てています。この文書の目的は、ESTプロトコルの実装と運用を容易にするためのガイドラインを提供することです。利用場面としては、セキュアなデバイス証明書の登録や更新プロセスにおいて、通信の安全性と効率性を高めることが挙げられます。
Internet Engineering Task Force (IETF) M. Richardson
Request for Comments: 8951 Sandelman Software Works
Updates: 7030 T. Werner
Category: Standards Track Siemens
ISSN: 2070-1721 W. Pan
Huawei Technologies
November 2020
Clarification of Enrollment over Secure Transport (EST): Transfer Encodings and ASN.1
安全な輸送に対する登録の明確化（EST）：符号化とASN.1の転送
Abstract
概要
This document updates RFC 7030: Enrollment over Secure Transport to resolve some errata that were reported and that have proven to cause interoperability issues when RFC 7030 was extended.
このドキュメントは、RFC 7030を更新します。
This document deprecates the specification of "Content-Transfer-Encoding" headers for Enrollment over Secure Transport (EST) endpoints. This document fixes some syntactical errors in ASN.1 that were present.
この文書は、セキュアトランスポート（EST）エンドポイントを登録するための「コンテンツ転送エンコーディング」ヘッダの仕様を非推奨します。この文書は、存在していたASN.1の構文誤差を修正しています。
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 7841.
この文書は、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表します。それは公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による出版の承認を受けました。インターネット規格に関する詳細情報は、RFC 7841のセクション2で利用できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8951.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https：//www.rfc-editor.org/info/rfc8951で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（C）2020 IETFの信頼と文書著者として識別された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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トラストの法的規定（https://trustee.ietf.org/license-info）の対象となります。 これらのドキュメントは、このドキュメントに関するお客様の権利と制限について説明しているため、注意深く確認してください。 このドキュメントから抽出されたコードコンポーネントには、Trust LegalProvisionsのセクション4.eで説明されているSimplifiedBSD Licenseテキストが含まれている必要があり、Simplified BSDLicenseで説明されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction
2. Terminology
3. Changes to EST Endpoint Processing
3.1. White Space Processing
3.2. Changes to Section 4 of RFC 7030
3.2.1. Section 4.1.3
3.2.2. Section 4.3.1
3.2.3. Section 4.3.2
3.2.4. Section 4.4.2
3.2.5. Section 4.5.2
4. Clarification of ASN.1 for Certificate Attribute Set
5. Clarification of Error Messages for Certificate Enrollment
Operations
5.1. Updating Section 4.2.3: Simple Enroll and Re-enroll
Response
5.2. Updating Section 4.4.2: Server-Side Key Generation Response
6. Privacy Considerations
7. Security Considerations
8. IANA Considerations
9. References
9.1. Normative References
9.2. Informative References
Appendix A. ASN.1 Module
Acknowledgements
Authors' Addresses
Enrollment over Secure Transport (EST) is defined in [RFC7030]. The EST specification defines a number of HTTP endpoints for certificate enrollment and management. The details of the transaction were defined in terms of MIME headers, as defined in [RFC2045], rather than in terms of the HTTP protocol, as defined in [RFC7230] and [RFC7231].
セキュアトランスポートオーバー（EST）の登録は[RFC7030]で定義されています。EST仕様は、証明書登録および管理のためのHTTPエンドポイントの数を定義します。トランザクションの詳細は、[RFC7230]と[RFC7231]で定義されているように、[RFC2045]ではなく[RFC2045]で定義されているMIMEヘッダーに関して定義されました。
[RFC2616] and later Appendix A.5 of [RFC7231] have text specifically deprecating Content-Transfer-Encoding. However, [RFC7030] incorrectly uses this header.
[RFC2616]以降[RFC7231]の付録A.5には、コンテンツ転送エンコーディングを迅速なテキストがあります。ただし、[RFC7030]がこのヘッダーを誤って使用しています。
Any updates to [RFC7030] to bring it in line with HTTP processing risk changing the on-wire protocol in a way that is not backwards compatible. However, reports from implementers suggest that many implementations do not send the Content-Transfer-Encoding, and many of them ignore it. The consequence is that simply deprecating the header would remain compatible with current implementations.
[RFC7030]の更新は、HTTP処理リスクと一致して、下位互換性のない方法でオンイヤープロトコルを変更します。ただし、実装者からのレポートは、多くの実装がコンテンツ転送エンコーディングを送信しないことを示唆しており、それらの多くはそれを無視します。その結果、ヘッダーを非推奨するだけでは現在の実装と互換性があります。
[BRSKI] extends [RFC7030], adding new functionality. Interop testing of the protocol has revealed that unusual processing called out in [RFC7030] causes confusion.
[Brski] [RFC7030]を拡張し、新しい機能を追加します。プロトコルの相互運用テストは、[RFC7030]で呼び出された異常な処理が混乱を引き起こすことを明らかにしました。
EST is currently specified as part of [IEC62351] and is widely used in government, utilities, and financial markets today.
ESTは現在[IEC62351]の一部として指定されており、今日の政府、ユーティリティ、および金融市場で広く使用されています。
This document, therefore, revises [RFC7030] to reflect the field reality, deprecating the extraneous field.
したがって、この文書は、電界現実を反映するように[RFC7030]を改訂し、余分なフィールドを非難します。
This document deals with errata numbers [errata4384], [errata5107], [errata5108], and [errata5904].
この文書では、errata numbers [errata4384]、[errata5107]、[errata5108]、[errata5904]を扱います。
This document deals with [errata5107] and [errata5904] in Section 3. [errata5108] is dealt with in Section 5. [errata4384] is closed by correcting the ASN.1 Module in Section 4.
このドキュメントでは、[errata5107]と[errata5904]をセクション3で扱います。[errata5108]はセクション4でASN.1モジュールを修正することによって閉じられます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
Sections 4.1.3 (CA Certificates Response, /cacerts), 4.3.1 and 4.3.2 (Full CMC, /fullcmc), 4.4.2 (Server-Side Key Generation, /serverkeygen), and 4.5.2 (CSR Attributes, /csrattrs) of [RFC7030] specify the use of base64 encoding with a Content-Transfer-Encoding for requests and responses.
セクション4.1.3（CA証明書応答、/ CACERTS）、4.3.1および4.3.2（フルCMC、/ FULLCMC）、4.4.2（サーバーサイドキー生成、/ SERVERKEYGEN）、および4.5.2（CSR属性、[RFC7030]の/ CSRATTRは、要求と応答のためのコンテンツ転送エンコーディングを使用したBase64エンコーディングの使用を指定します。
This document updates [RFC7030] to require the POST request and payload response of all endpoints using base64 encoding, as specified in Section 4 of [RFC4648]. In both cases, the Distinguished Encoding Rules (DER) [X.690] are used to produce the input for the base64 encoding routine. This format is to be used regardless of any Content-Transfer-Encoding header, and any value in such a header MUST be ignored.
[RFC4648]のセクション4で指定されているように、Base64エンコーディングを使用して、すべてのエンドポイントのPOST要求とペイロード応答を必要とするために、このドキュメントの更新[RFC7030]。どちらの場合も、識別符号化規則（DER）[X.690]は、Base64符号化ルーチンの入力を生成するために使用されます。このフォーマットは、コンテンツ転送エンコーディングヘッダーに関係なく使用され、そのようなヘッダーの任意の値は無視されなければなりません。
Note that "base64" as used in the HTTP [RFC2616] does not permit CRLF, while the "base64" used in MIME [RFC2045] does. This specification clarifies that despite what [RFC2616] says, white space including CR, LF, spaces (ASCII 32), and tabs (ASCII 9) SHOULD be tolerated by receivers. Senders are not required to insert any kind of white space.
HTTP [RFC2616]で使用されている「Base64」では、MIME [RFC2045]で使用されている「BASE64」が実行されている間にCRLFを許可しません。この仕様では、[RFC2616]が何を述べているにもかかわらず、CR、LF、スペース（ASCII 32）、およびタブ（ASCII 9）を受信機によって許容されるべきであると説明しています。送信者はどのような種類の空白を挿入する必要はありません。
Replace:
置換：
| A successful response MUST be a certs-only CMC Simple PKI
| Response, as defined in [RFC5272], containing the certificates
| described in the following paragraph. The HTTP content-type of
| "application/pkcs7-mime" is used. The Simple PKI Response is sent
| with a Content-Transfer-Encoding of "base64" [RFC2045].
with:
with
| A successful response MUST be a certs-only CMC Simple PKI
| Response, as defined in [RFC5272], containing the certificates
| described in the following paragraph. The HTTP content-type of
| "application/pkcs7-mime" is used. The CMC Simple PKI Response is
| encoded in base64 [RFC4648].
Replace:
置換：
| If the HTTP POST to /fullcmc is not a valid Full PKI Request, the
| server MUST reject the message. The HTTP content-type used is
| "application/pkcs7-mime" with an smime-type parameter "CMC-
| request", as specified in [RFC5273]. The body of the message is
| the binary value of the encoding of the PKI Request with a
| Content-Transfer-Encoding of "base64" [RFC2045].
with:
with
| If the HTTP POST to /fullcmc is not a valid Full PKI Request, the
| server MUST reject the message. The HTTP content-type used is
| "application/pkcs7-mime" with an smime-type parameter "CMC-
| request", as specified in [RFC5273]. The body of the message is
| encoded in base64 [RFC4648].
Replace:
置換：
| The body of the message is the binary value of the encoding of the
| PKI Response with a Content-Transfer-Encoding of "base64"
| [RFC2045].
with:
with
| The body of the message is the base64 [RFC4648] encoding of the | PKI Response.
| ..メッセージの本文は基本64 [RFC4648]のエンコーディングです。PKI応答
Replace:
置換：
| An "application/pkcs8" part consists of the base64-encoded DER-
| encoded [X.690] PrivateKeyInfo with a Content-Transfer-Encoding of
| "base64" [RFC2045].
with:
with
| An "application/pkcs8" part consists of the base64-encoded, DER-| encoded [X.690] PrivateKeyInfo.
| ..「アプリケーション/ PKCS8」部分は、BASE64エンコードDER-で構成されています。Encoded [X.690] PrivateKeyInfo。
Replace:
置換：
| In all three additional encryption cases, the EnvelopedData is
| returned in the response as an "application/pkcs7-mime" part with
| an smime-type parameter of "server-generated-key" and a Content-
| Transfer-Encoding of "base64".
with:
with
| In all three additional encryption cases, the EnvelopedData is
| returned in the response as an "application/pkcs7-mime" part with
| an smime-type parameter of "server-generated-key". It is base64
| encoded [RFC4648].
This section is updated in its entirety in Section 4.
このセクションはセクション4において全体が更新されます。
Section 4.5.2 of [RFC7030] is to be replaced with the following text:
[RFC7030]のセクション4.5.2は、次のテキストに置き換えられます。
| 4.5.2 CSR Attributes Response
|
| If locally configured policy for an authenticated EST client
| indicates a CSR Attributes Response is to be provided, the server
| response MUST include an HTTP 200 response code. An HTTP response
| code of 204 or 404 indicates that a CSR Attributes Response is not
| available. Regardless of the response code, the EST server and CA
| MAY reject any subsequent enrollment requests for any reason,
| e.g., incomplete CSR attributes in the request.
|
| Responses to attribute request messages MUST be encoded as the
| content-type of "application/csrattrs" and are to be "base64"
| [RFC4648] encoded. The syntax for application/csrattrs body is as
| follows:
|
| CsrAttrs ::= SEQUENCE SIZE (0..MAX) OF AttrOrOID
|
| AttrOrOID ::= CHOICE {
| oid OBJECT IDENTIFIER,
| attribute Attribute {{AttrSet}} }
|
| AttrSet ATTRIBUTE ::= { ... }
|
| An EST server includes zero or more OIDs or attributes [RFC2986]
| that it requests the client to use in the certification request.
| The client MUST ignore any OID or attribute it does not recognize.
| When the server encodes CSR attributes as an empty SEQUENCE, it
| means that the server has no specific additional information it
| desires in a client certification request (this is functionally
| equivalent to an HTTP response code of 204 or 404).
|
| If the CA requires a particular cryptographic algorithm or use of
| a particular signature scheme (e.g., certification of a public key
| based on a certain elliptic curve or signing using a certain hash
| algorithm), it MUST provide that information in the CSR Attribute
| Response. If an EST server requires the linking of identity and
| POP information (see Section 3.5), it MUST include the
| challengePassword OID in the CSR Attributes Response.
|
| The structure of the CSR Attributes Response SHOULD, to the
| greatest extent possible, reflect the structure of the CSR it is
| requesting. Requests to use a particular signature scheme (e.g.,
| using a particular hash function) are represented as an OID to be
| reflected in the SignatureAlgorithm of the CSR. Requests to use a
| particular cryptographic algorithm (e.g., certification of a
| public key based on a certain elliptic curve) are represented as
| an attribute, to be reflected as the AlgorithmIdentifier of the
| SubjectPublicKeyInfo, with a type indicating the algorithm and the
| values indicating the particular parameters specific to the
| algorithm. Requests for descriptive information from the client
| are made by an attribute, to be represented as Attributes of the
| CSR, with a type indicating the [RFC2985] extensionRequest and the
| values indicating the particular attributes desired to be included
| in the resulting certificate's extensions.
|
| The sequence is Distinguished Encoding Rules (DER) encoded [X.690]
| and then base64 encoded (Section 4 of [RFC4648]). The resulting
| text forms the application/csrattr body, without headers.
|
| For example, if a CA requests that a client a) submit a
| certification request containing the challengePassword (indicating
| that linking of identity and POP information is requested; see
| Section 3.5), b) submit an extensionRequest with the Media Access
| Control (MAC) address [RFC2307] of the client, and c) use the
| secp384r1 elliptic curve to sign using the SHA384 hash function,
| then it takes the following:
|
| OID: challengePassword (1.2.840.113549.1.9.7)
|
| Attribute: type = extensionRequest (1.2.840.113549.1.9.14)
| value = macAddress (1.3.6.1.1.1.1.22)
|
| Attribute: type = id-ecPublicKey (1.2.840.10045.2.1)
| value = secp384r1 (1.3.132.0.34)
|
| OID: ecdsaWithSHA384 (1.2.840.10045.4.3.3)
|
| and encodes them into an ASN.1 SEQUENCE to produce:
|
| 30 41 06 09 2a 86 48 86 f7 0d 01 09 07 30 12 06 07 2a 86 48 ce 3d
| 02 01 31 07 06 05 2b 81 04 00 22 30 16 06 09 2a 86 48 86 f7 0d 01
| 09 0e 31 09 06 07 2b 06 01 01 01 01 16 06 08 2a 86 48 ce 3d 04 03
| 03
|
| and then base64 encodes the resulting ASN.1 SEQUENCE to produce:
|
| MEEGCSqGSIb3DQEJBzASBgcqhkjOPQIBMQcGBSuBBAAiMBYGCSqGSIb3DQEJDjEJ
| BgcrBgEBAQEWBggqhkjOPQQDAw==
5. Clarification of Error Messages for Certificate Enrollment Operations
5. 証明書登録業務のためのエラーメッセージの明確化
[errata5108] clarifies what format the error messages are to be in. Previously, a client might be confused into believing that an error returned with type text/plain was not intended to be an error.
[errata5108]エラーメッセージの形式があることを明確にします。以前は、TEXT / PLAIN型と返されたエラーがエラーになることを意図していないというエラーがあると信じている可能性があります。
Replace:
置換：
| If the content-type is not set, the response data MUST be a
| plaintext human-readable error message containing explanatory
| information describing why the request was rejected (for example,
| indicating that CSR attributes are incomplete).
with:
with
| If the content-type is not set, the response data MUST be a
| plaintext human-readable error message containing explanatory
| information describing why the request was rejected (for example,
| indicating that CSR attributes are incomplete). Servers MAY use
| the "text/plain" content-type [RFC2046] for human-readable errors.
Replace:
置換：
| If the content-type is not set, the response data MUST be a | plaintext human-readable error message.
| ..content-typeが設定されていない場合、応答データは|でなければなりません。平文の人間が読めるエラーメッセージ。
with:
with
| If the content-type is not set, the response data MUST be a
| plaintext human-readable error message. Servers MAY use the
| "text/plain" content-type [RFC2046] for human-readable errors.
This document does not disclose any additional identities that either an active or passive observer would see with [RFC7030].
この文書では、アクティブまたはパッシブオブザーバーのどちらかが[RFC7030]で表示されるような追加のアイデンティティを開示していません。
This document clarifies an existing security mechanism. It does not create any new protocol mechanisms.
この文書では、既存のセキュリティメカニズムを明確にします。新しいプロトコルメカニズムは作成されません。
All security considerations from [RFC7030] also apply to the clarifications described in this document.
[RFC7030]からのすべてのセキュリティ上の考慮事項もこの文書に記載されている説明に適用されます。
The ASN.1 module in Appendix A of this document makes use of object identifiers (OIDs).
このドキュメントの付録AのASN.1モジュールは、オブジェクト識別子（OID）を使用します。
IANA has registered an OID for id-mod-est-2019 (1.3.6.1.5.5.7.0.98) in the "SMI Security for PKIX Module Identifier" registry for the ASN.1 module.
IANAは、ASN.1モジュールの「PKIXモジュール識別子のSMIセキュリティ」レジストリに、ID-MOD-EST-2019（1.3.6.1.5.5.7.0.98）のOIDを登録しました。
The OID for the Asymmetric Decryption Key Identifier (1.2.840.113549.1.9.16.2.54) was previously defined in [RFC7030]. IANA has updated the Reference column for the Asymmetric Decryption Key Identifier attribute to also include a reference to this document.
非対称復号化キー識別子（1.2.840.113549.1.9.16.2.54）のOIDは、[RFC7030]で以前に定義されていました。IANAは、非対称復号化キー識別子属性の参照列を更新して、このドキュメントへの参照も含みます。
[errata4384] RFC Errata, Erratum ID 4384, RFC 7030, <https://www.rfc-editor.org/errata/eid4384>.
[errata4384] RFCエラータ、Erratum ID 4384、RFC 7030、<https://www.rfc-editor.org/errata/eid4384>。
[errata5107] RFC Errata, Erratum ID 5107, RFC 7030, <https://www.rfc-editor.org/errata/eid5107>.
[errata5107] RFCエラータ、Erratum ID 5107、RFC 7030、<https://www.rfc-editor.org/errata/eid5107>。
[errata5108] RFC Errata, Erratum ID 5108, RFC 7030, <https://www.rfc-editor.org/errata/eid5108>.
[errata5108] RFCエラータ、Erratum ID 5108、RFC 7030、<https://www.rfc-editor.org/errata/eid5108>。
[errata5904] RFC Errata, Erratum ID 5904, RFC 7030, <https://www.rfc-editor.org/errata/eid5904>.
[errata5904] RFCエラータ、Erratum ID 5904、RFC 7030、<https://www.rfc-editor.org/errata/eid5904>。
[IEC62351] International Electrotechnical Commission, "Power systems management and associated information exchange - Data and communications security - Part 9: Cyber security key management for power system equipment", ISO/ IEC 62351-9:2017, May 2017.
[IEC62351]国際電気技術委員会、「パワーシステム管理と関連情報交換 - データと通信セキュリティ - パート9：電力システム機器のサイバーセキュリティ鍵管理」、ISO / IEC 62351-9：2017、2017年5月。
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, <https://www.rfc-editor.org/info/rfc2045>.
[RFC2045] Freed、N.およびN.Borenstein、「マルチポーズインターネットメール拡張（MIME）パート1：インターネットメッセージボディのフォーマット」、RFC 2045、DOI 10.17487 / RFC2045、1996年11月、<https：///www.rfc-editor.org/info/rfc2045>。
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, DOI 10.17487/RFC2046, November 1996, <https://www.rfc-editor.org/info/rfc2046>.
[RFC2046] Freed、N.およびN.Borenstein、「MultiPurpose Internet Mail Extensions（MIME）パート2：メディアタイプ」、RFC 2046、DOI 10.17487 / RFC2046、1996年11月、<https：//www.rfc-editor.org/ info / rfc2046>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] BRADNER、S、「RFCSで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。
[RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification Request Syntax Specification Version 1.7", RFC 2986, DOI 10.17487/RFC2986, November 2000, <https://www.rfc-editor.org/info/rfc2986>.
[RFC2986] NYSTROM、M.およびB.Kaliski、「PKCS＃10：認証依頼版仕様バージョン1.7」、RFC 2986、DOI 10.17487 / RFC2986、2000年11月、<https：//www.rfc-editor.org/info/ RFC2986>。
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <https://www.rfc-editor.org/info/rfc4648>.
[RFC4648] Josefsson、S。、「Base16、Base32、およびBase64データエンコーディング」、RFC 4648、DOI 10.17487 / RFC4648、2006年10月、<https：//www.rfc-editor.org/info/rfc4648>。
[RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS (CMC)", RFC 5272, DOI 10.17487/RFC5272, June 2008, <https://www.rfc-editor.org/info/rfc5272>.
[RFC5272] Schaad、J.およびM. Myers、 "CMS（CMC）、RFC 5272、DOI 10.17487 / RFC5272、2008年6月、<https：//www.rfc-editor.org/info/rfc5272>。
[RFC5273] Schaad, J. and M. Myers, "Certificate Management over CMS (CMC): Transport Protocols", RFC 5273, DOI 10.17487/RFC5273, June 2008, <https://www.rfc-editor.org/info/rfc5273>.
[RFC5273] Schaad、J.およびM. Myers、「CMS（CMC上の証明書管理：トランスポートプロトコル」、RFC 5273、DOI 10.17487 / RFC5273、2008年6月、<https://www.rfc-editor.org/info/ RFC5273>。
[RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, DOI 10.17487/RFC5912, June 2010, <https://www.rfc-editor.org/info/rfc5912>.
[RFC5912] HOFFMAN、P.およびJ.Schaad、「X.509（PKIX）を使用した公開鍵インフラストラクチャのための新しいASN.1モジュール、RFC 5912、DOI 10.17487 / RFC5912、2010年6月、<https：// www。rfc-editor.org/info/rfc5912>
[RFC6268] Schaad, J. and S. Turner, "Additional New ASN.1 Modules for the Cryptographic Message Syntax (CMS) and the Public Key Infrastructure Using X.509 (PKIX)", RFC 6268, DOI 10.17487/RFC6268, July 2011, <https://www.rfc-editor.org/info/rfc6268>.
[RFC6268] Schaad、J.およびS. Turner、 "Cryptographic Message Syntax（CMS）および公開鍵インフラストラクチャのための追加の新しいASN.1モジュール（PKIX）、RFC 6268、DOI 10.17487 / RFC6268、7月2011年、<https://www.rfc-editor.org/info/rfc6268>。
[RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., "Enrollment over Secure Transport", RFC 7030, DOI 10.17487/RFC7030, October 2013, <https://www.rfc-editor.org/info/rfc7030>.
[RFC7030] Pritikin、M。、ED。、Yee、P.、Ed。、D. Harkins、Ed。、「セキュアトランスポートの登録」、RFC 7030、DOI 10.17487 / RFC7030、2013年10月、<https：//www.rfc-editor.org/info/rfc7030>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B、「RFC 2119キーワードの大文字の曖昧さ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。
[X.680] ITU-T, "Information technology -- Abstract Syntax Notation One (ASN.1): Specification of basic notation", ITU-T Recommendation X.680, ISO/IEC 8824-1:2015, August 2015, <https://www.itu.int/rec/T-REC-X.680-201508-I/en>.
[X.680] ITU-T、「情報技術 - 抽象構文表記1（ASN.1）：基本表記の仕様」、ITU-T勧告X.680、ISO / IEC 8824-1：2015、2015年8月、<https://www.itu.int/rec/t-rec-x.680-201508-i/ja>。
[X.681] ITU-T, "Information Technology - Abstract Syntax Notation One (ASN.1): Information object specification", ITU-T Recommendation X.681, ISO/IEC 8824-2:2015, August 2015, <https://www.itu.int/rec/T-REC-X.681>.
[X.681] ITU-T、「情報技術 - 抽象構文表記1（ASN.1）：Information Object Specification」、ITU-T勧告X.681、ISO / IEC 8824-2：2015、2015年8月、<HTTPS//www.itu.int/rec/t-rec-x.681>。
[X.682] ITU-T, "Information Technology - Abstract Syntax Notation One (ASN.1): Constraint specification", ITU-T Recommendation X.682, ISO/IEC 8824-3:2015, August 2015, <https://www.itu.int/rec/T-REC-X.682>.
[X.682] ITU-T、「情報技術 - 抽象構文表記法1（ASN.1）：制約仕様」、ITU-T勧告X.682、ISO / IEC 8824-3：2015、2015年8月、<https：//www.itu.int/rec/t-rec-x.682>。
[X.683] ITU-T, "Information Technology - Abstract Syntax Notation One (ASN.1): Parameterization of ASN.1 specifications", ITU-T Recommendation X.683, ISO/IEC 8824-4:2015, August 2015, <https://www.itu.int/rec/T-REC-X.683>.
[X.683] ITU-T、「情報技術 - 抽象構文表記1（ASN.1）：ASN.1仕様のパラメータ化」、ITU-T勧告X.683、ISO / IEC 8824-4：2015、2015年8月、<https://www.itu.int/rec/t-rec-x.683>。
[X.690] ITU-T, "Information Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", ITU-T Recommendation X.690, ISO/IEC 8825-1:2015, August 2015, <https://www.itu.int/rec/T-REC-X.690>.
[X.690] ITU-T、「情報技術 - ASN.1符号化規則：基本符号化規則（BER）、正規符号化規則（CER）および識別符号化規則（DER）」の仕様ITU-T勧告X.690、ISO / IEC 8825-1：2015、2015年8月、<https：//www.itu.int/rec/t-rec-x.690>。
[BRSKI] Pritikin, M., Richardson, M. C., Eckert, T., Behringer, M. H., and K. Watsen, "Bootstrapping Remote Secure Key Infrastructures (BRSKI)", Work in Progress, Internet-Draft, draft-ietf-anima-bootstrapping-keyinfra-45, 11 November 2020, <https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-45>.
[Brski] Pritikin、M.、Richardson、MC、Eckert、T.、Behringer、MH、およびK. Watsen、「ブートストラップリモートセキュリティキーインフラストラクチャ（Brski）」、進行中の作業、インターネットドラフト、ドラフト-IETF-ANIMA-bootstrapping-keyInfra-45、2020年11月11日、<https://tools.ietf.org/html/draft-ietf-anima-bootstrapp-keyInfra-45>。
[RFC2307] Howard, L., "An Approach for Using LDAP as a Network Information Service", RFC 2307, DOI 10.17487/RFC2307, March 1998, <https://www.rfc-editor.org/info/rfc2307>.
[RFC2307]ハワード、L.、「ネットワーク情報サービスとしてLDAPを使用するためのアプローチ」、RFC 2307、DOI 10.17487 / RFC2307、1998年3月、<https：//www.rfc-editor.org/info/rfc2307>。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, DOI 10.17487/RFC2616, June 1999, <https://www.rfc-editor.org/info/rfc2616>.
[RFC2616]フィールド化、R.、GetTys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、L. L.、Leach、P.、およびT.Berners-Lee、 "Hypertext Transfer Protocol - HTTP / 1.1"、RFC 2616、DOI 10.17487 / RFC2616、1999年6月、<https://www.rfc-editor.org/info/rfc2616>。
[RFC2985] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object Classes and Attribute Types Version 2.0", RFC 2985, DOI 10.17487/RFC2985, November 2000, <https://www.rfc-editor.org/info/rfc2985>.
[RFC2985] Nystrom、M.およびB. Kaliski、 "PKCS＃9：選択オブジェクトクラスおよび属性タイプバージョン2.0"、RFC 2985、DOI 10.17487 / RFC2985、2000年11月、<https://www.rfc-editor.org/ info / rfc2985>。
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, <https://www.rfc-editor.org/info/rfc7230>.
[RFC7230]フィールド、R.、ED。J.Reschke、ED。、「Hypertext Transfer Protocol（HTTP / 1.1）：メッセージ構文とルーティング」、RFC 7230、DOI 10.17487 / RFC7230、2014年6月、<https：//www.rfc-editor.org/info/RFC7230>。
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014, <https://www.rfc-editor.org/info/rfc7231>.
[RFC7231] Fielding、R.、Ed。J. Reschke、ED。、「Hypertext Transfer Protocol（HTTP / 1.1）：セマンティクスとコンテンツ」、RFC 7231、DOI 10.17487 / RFC7231、2014年6月、<https://www.rfc-editor.org/info/rfc7231>。
This annex provides the normative ASN.1 definitions for the structures described in this specification using ASN.1 as defined in [X.680], [X.681], [X.682], and [X.683].
この附属書は、[X.680]、[X.681]、[X.682]、[X.683]で定義されているASN.1を使用して、本明細書に記載されている構造の規範的ASN.1定義を提供します。
The ASN.1 modules makes imports from the ASN.1 modules in [RFC5912] and [RFC6268].
ASN.1モジュールは[RFC5912]と[RFC6268]のASN.1モジュールからインポートを行います。
There is no ASN.1 Module in [RFC7030]. This module has been created by combining the lines that are contained in the document body.
[RFC7030]にはASN.1モジュールはありません。このモジュールは、文書本体に含まれている行を組み合わせることによって作成されています。
PKIXEST-2019
{ iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7)
id-mod(0) id-mod-est-2019(98) }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
-- EXPORTS ALL --
- すべてのエクスポート -
IMPORTS
輸入
Attribute
FROM CryptographicMessageSyntax-2010 -- [RFC6268]
{ iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0)
id-mod-cms-2009(58) }
ATTRIBUTE
FROM PKIX-CommonTypes-2009 -- [RFC5912]
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkixCommon-02(57) } ;
-- CSR Attributes
- CSR属性
CsrAttrs ::= SEQUENCE SIZE (0..MAX) OF AttrOrOID
AttrOrOID ::= CHOICE {
oid OBJECT IDENTIFIER,
attribute Attribute {{AttrSet}} }
AttrSet ATTRIBUTE ::= { ... }
-- Asymmetric Decrypt Key Identifier Attribute
- 非対称復号化キー識別子属性
aa-asymmDecryptKeyID ATTRIBUTE ::=
{ TYPE AsymmetricDecryptKeyIdentifier
IDENTIFIED BY id-aa-asymmDecryptKeyID }
id-aa-asymmDecryptKeyID OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) aa(2) 54 }
AsymmetricDecryptKeyIdentifier ::= OCTET STRING
END
終わり
Acknowledgements
謝辞
Huawei Technologies supported the efforts of Wei Pan and Michael Richardson.
Huawei Technologiesは、Wei PanとMichael Richardsonの努力を支持していました。
The ASN.1 Module was assembled by Russ Housley and formatted by Sean Turner. Russ Housley provided editorial review.
ASN.1モジュールはRuss Houseleyによって組み立てられ、Sean Turnerによってフォーマットされました。Russ Housleyは編集レビューを提供しました。
Authors' Addresses
著者の住所
Michael Richardson Sandelman Software Works
Michael Richardson Sandelman Software Works.
Email: mcr+ietf@sandelman.ca
Thomas Werner Siemens
Thomas Werner Siemens
Email: thomas-werner@siemens.com
Wei Pan Huawei Technologies
Wei Pan Huawei Technologies
Email: william.panwei@huawei.com