[要約] RFC 8894は、Simple Certificate Enrolment Protocol（SCEP）に関する標準化された仕様書であり、PKI環境での証明書の簡素な発行と更新を可能にします。SCEPは、セキュアな通信を確保し、証明書の自動化された管理を支援することを目的としています。
Internet Engineering Task Force (IETF) P. Gutmann
Request for Comments: 8894 University of Auckland
Category: Informational September 2020
ISSN: 2070-1721
Simple Certificate Enrolment Protocol
単純な証明書登録プロトコル
Abstract
概要
This document specifies the Simple Certificate Enrolment Protocol (SCEP), a PKI protocol that leverages existing technology by using Cryptographic Message Syntax (CMS, formerly known as PKCS #7) and PKCS #10 over HTTP. SCEP is the evolution of the enrolment protocol sponsored by Cisco Systems, which enjoys wide support in both client and server implementations, as well as being relied upon by numerous other industry standards that work with certificates.
このドキュメントでは、Cryptographic Message Syntax（以前はPKCS＃7と呼ばれるCMS）を使用して既存のテクノロジ（以前はPKCS＃7と呼ばれる）およびHTTPを介してPKCS＃10を使用して、単純な証明書登録プロトコル（SCEP）を指定します。SCEPは、クライアントとサーバーの実装の両方で広くサポートされる、および証明書と扱う多数の他の業界標準の両方で広くサポートされることを享受する、シスコシステムズが後援する登録プロトコルの進化です。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
この文書はインターネット標準のトラック仕様ではありません。情報提供のために公開されています。
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). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
この文書は、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表します。それは公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による出版の承認を受けました。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/rfc8894.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/rfc8894で入手できます。
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.
この文書は、この文書の公開日に有効なIETF文書（https://truste.ietf.org/License-info）に関するBCP 78とIETF信頼の法的規定を受けています。この文書に関してあなたの権利と制限を説明するので、これらの文書を慎重に見直してください。この文書から抽出されたコードコンポーネントには、信頼法の法的規定のセクション4。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
この文書には、2008年11月10日以前に公開されたIETF文書または公開されたIETFの貢献からの資料を含めることができます。この材料のいくつかの著作権を制御する人は、そのような材料の修正を許可する権利を信頼する権利を与えられなかった人物IETF標準の外部プロセス。そのような材料の著作権を制御する人から適切なライセンスを取得せずに、この文書はIETF規格プロセスの外で修正されていない可能性があり、それをフォーマットすること以外はIETF標準プロセスの外ではデリバティブ作品が作成されない可能性があります。RFCとしての出版物、または英語以外の言語に翻訳する。
Table of Contents
目次
1. Introduction
1.1. Conventions Used in This Document
2. SCEP Overview
2.1. SCEP Entities
2.1.1. Client
2.1.2. Certificate Authority
2.2. CA Certificate Distribution
2.3. Client Authentication
2.4. Enrolment Authorisation
2.5. Certificate Enrolment/Renewal
2.5.1. Client State Transitions
2.6. Certificate Access
2.7. CRL Access
2.8. Certificate Revocation
2.9. Mandatory-to-Implement Functionality
3. SCEP Secure Message Objects
3.1. SCEP Message Object Processing
3.2. SCEP pkiMessage
3.2.1. Signed Transaction Attributes
3.2.1.1. transactionID
3.2.1.2. messageType
3.2.1.3. pkiStatus
3.2.1.4. failInfo and failInfoText
3.2.1.5. senderNonce and recipientNonce
3.2.2. SCEP pkcsPKIEnvelope
3.3. SCEP pkiMessage types
3.3.1. PKCSReq/RenewalReq
3.3.2. CertRep
3.3.2.1. CertRep SUCCESS
3.3.2.2. CertRep FAILURE
3.3.2.3. CertRep PENDING
3.3.3. CertPoll (GetCertInitial)
3.3.4. GetCert and GetCRL
3.4. Degenerate certificates-only CMS SignedData
3.5. CA Capabilities
3.5.1. GetCACaps HTTP Message Format
3.5.2. CA Capabilities Response Format
4. SCEP Transactions
4.1. HTTP POST and GET Message Formats
4.2. Get CA Certificate
4.2.1. Get CA Certificate Response Message Format
4.2.1.1. CA Certificate Response Message Format
4.2.1.2. CA Certificate Chain Response Message Format
4.3. Certificate Enrolment/Renewal
4.3.1. Certificate Enrolment/Renewal Response Message
4.4. Poll for Client Initial Certificate
4.4.1. Polling Response Message Format
4.5. Certificate Access
4.5.1. Certificate Access Response Message Format
4.6. CRL Access
4.6.1. CRL Access Response Message Format
4.7. Get Next Certificate Authority Certificate
4.7.1. Get Next CA Response Message Format
5. SCEP Transaction Examples
5.1. Successful Transactions
5.2. Transactions with Errors
6. IANA Considerations
6.1. Registration of the application/x-x509-ca-cert Media Type
6.2. Registration of the application/x-x509-ca-ra-cert Media
Type
6.3. Registration of the application/x-x509-next-ca-cert Media
Type
6.4. Registration of the application/x-pki-message Media Type
7. Security Considerations
7.1. General Security
7.2. Use of the CA Private Key
7.3. ChallengePassword Shared Secret Value
7.4. Lack of Certificate Issue Confirmation
7.5. GetCACaps Issues
7.6. Lack of PoP in Renewal Requests
7.7. Traffic Monitoring
7.8. Unnecessary Cryptography
7.9. Use of SHA-1
7.10. Use of HTTP
8. References
8.1. Normative References
8.2. Informative References
Appendix A. Background Notes
Acknowledgements
Author's Address
X.509 certificates serve as the basis for several standardised security protocols such as TLS [RFC8446], S/MIME [RFC8551], and IKE/ IPsec [RFC7296]. When an X.509 certificate is issued, there typically is a need for a certificate management protocol to enable a PKI client to request or renew a certificate from a Certificate Authority (CA). This specification defines a protocol, the Simple Certificate Enrolment Protocol (SCEP), for certificate management and certificate and CRL queries.
X.509証明書は、TLS [RFC8446]、S / MIME [RFC8551]、およびIKE / IPSecなどのいくつかの標準化されたセキュリティプロトコルの基礎として機能します。X.509証明書が発行されると、通常、PKIクライアントが認証局（CA）から証明書を要求または更新できるようにするための証明書管理プロトコルが必要とされています。この仕様は、証明書管理と証明書およびCRLクエリのプロトコル、単純な証明書登録プロトコル（SCEP）を定義しています。
The SCEP protocol supports the following general operations:
SCEPプロトコルは、次の一般的な操作をサポートしています。
* CA public key distribution * Certificate enrolment and issue * Certificate renewal * Certificate query * CRL query
* CA公開鍵配布*証明書登録と問題*証明書更新*証明書照会* CRLクエリ
SCEP makes extensive use of CMS [RFC5652] and PKCS #10 [RFC2986].
SCEPはCMS [RFC5652]とPKCS＃10 [RFC2986]を広く使用します。
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.
「必須」、「必須」、「必須」、「SHALL」、「必ず」、「推奨する」、「推奨する」、「推奨する」、「推奨する」、「推奨する」、「5月」「この文書では、BCP 14 [RFC2119] [RFC8174]に記載されている場合に解釈されるべきであり、ここに示すように、すべての首都に表示されます。
This document uses the Augmented Backus-Naur Form (ABNF) notation as specified in [RFC5234] for defining formal syntax of commands. Non-terminals not defined in [RFC5234] are defined in Section 4.1.
このドキュメントでは、コマンドの正式な構文を定義するために[RFC5234]で指定されているように、拡張されたBACKUS-NAUR形式（ABNF）表記法を使用しています。[RFC5234]で定義されていない非端末はセクション4.1で定義されています。
This section provides an overview of the functionality of SCEP.
このセクションでは、SCEPの機能の概要について説明します。
The entity types defined in SCEP are a client requesting a certificate and a Certificate Authority (CA) that issues the certificate. These are described in the following sections.
SCEPで定義されているエンティティタイプは、証明書を要求するクライアントと、証明書を発行する認証局（CA）です。以下のセクションで説明します。
A client MUST have the following information locally configured:
クライアントには、次の情報がローカルに設定されている必要があります。
1. The CA's fully qualified domain name or IP address.
1. CAの完全修飾ドメイン名またはIPアドレス。
2. Any identification and/or authorisation information required by the CA before a certificate will be issued, as described in Section 3.3.1.
2. セクション3.3.1で説明されているように、証明書が発行される前に、CAによって必要とされる識別および/または許可情報が発行されます。
3. The identifying information that is used for authentication of the CA in Section 4.2.1, typically a certificate fingerprint.
3. セクション4.2.1のCAの認証に使用される識別情報、通常は証明書の指紋です。
A SCEP CA is the entity that signs client certificates. A CA may enforce policies and apply them to certificate requests, and it may reject a request for any reason.
SCEP CAは、クライアント証明書に署名するエンティティです。CAはポリシーを強制し、それらを証明書要求に適用することができ、それは何らかの理由で要求を拒否するかもしれません。
Since the client is expected to perform signature verification and optionally encryption using the CA certificate, the keyUsage extension in the CA certificate MUST indicate that it is valid for digitalSignature and keyEncipherment (if the key is to be used for en/decryption) alongside the usual CA usages of keyCertSign and/or cRLSign.
クライアントはCA証明書を使用して署名の検証とオプションで暗号化を実行することが期待されているため、CA証明書のKeyUsage拡張機能は、DigitalSignatureおよびKeyEnctionmentに有効であることを示している必要があります（キーがEN /復号化に使用される場合）通常のようにKeyCertSignおよび/またはCRLSIGNのCAの使用。
If the CA certificate(s) have not previously been acquired by the client through some other means, the client MUST retrieve them before any PKI operation (Section 3) can be started. Since no public key has yet been exchanged between the client and the CA, the messages cannot be secured using CMS, and the CA certificate request and response data is instead transferred in the clear.
CA証明書が他の方法でクライアントによって以前に取得されていない場合、クライアントはPKI操作（セクション3）を開始する前にそれらを検索する必要があります。クライアントとCAとの間で公開鍵が交換されていないので、CMを使用してメッセージを保護することはできません.CA証明書要求と応答データは代わりにクリアに転送されます。
If an intermediate CA is in use, a certificates-only CMS SignedData message with a certificate chain consisting of all CA certificates is returned. Otherwise, the CA certificate itself is returned.
中間CAが使用中の場合、証明書のみのCMS SignedDataメッセージは、すべてのCA証明書からなる証明書チェーンを返します。それ以外の場合は、CA証明書自体が返されます。
The CA certificate MAY be provided out of band to the client. Alternatively, the CA certificate fingerprint MAY be used to authenticate a CA certificate distributed by the GetCACert response (Section 4.2) or via HTTP certificate-store access [RFC4387]. The fingerprint is created by calculating a SHA-256 hash over the whole CA certificate. (For legacy reasons, a SHA-1 hash may be used by some implementations.)
CA証明書はクライアントに帯域外に提供されてもよい。あるいは、CA証明書の指紋は、GetCacert Response（セクション4.2）またはHTTP証明書ストアアクセス[RFC4387]を介して配布されたCA証明書を認証するために使用されます。FingerPrintは、CA証明書全体にわたってSHA-256ハッシュを計算することによって作成されます。（レガシーの理由から、SHA-1ハッシュはいくつかの実装によって使用されるかもしれません。）
After the client gets the CA certificate, it SHOULD authenticate it in some manner unless this is deemed unnecessary, for example, because the device is being provisioned inside a trusted environment. For example, the client could compare the certificate's fingerprint with locally configured, out-of-band distributed, identifying information, or by some equivalent means such as a direct comparison with a locally stored copy of the certificate.
クライアントがCA証明書を取得した後、デバイスは信頼できる環境内でプロビジョニングされているため、これが不要と見なされないと、何らかの方法で認証されるべきです。たとえば、クライアントは、証明書の指紋とローカルに構成された、帯域外の分散、識別情報、あるいは証明書のローカルに保存されているコピーとの直接比較などの何らかの同等の手段によって比較できます。
Intermediate CA certificates, if any, are signed by a higher-level CA, so there is no need to authenticate them against the out-of-band data. Since intermediate CA certificates are rolled over more frequently than long-lived top-level CA certificates, clients MUST verify intermediate-level CA certificates before use during protocol exchanges in case the intermediate CA certificate has expired or otherwise been invalidated.
中間CA証明書がある場合は、上位レベルのCAによって署名されているため、帯域外データに対してそれらを認証する必要はありません。中間のCA証明書は長寿命のトップレベルのCA証明書よりも頻繁にロールされるため、中間CA証明書が満了したか無効化されている場合、クライアントはプロトコル交換中に使用する前に中間レベルのCA証明書を検証する必要があります。
When a CA certificate expires, certificates that have been signed by it may no longer be regarded as valid. CA key rollover provides a mechanism by which the CA can distribute a new CA certificate that will be valid in the future once the current certificate has expired. This is done via the GetNextCACert message (Section 4.7).
CA証明書の有効期限が切れると、署名されている証明書は有効と見なされなくなります。CAキーロールオーバーは、現在の証明書が期限切れになると、CAが将来有効になる新しいCA証明書を配布できるメカニズムを提供します。これはGetNextCacertメッセージを介して行われます（セクション4.7）。
As with every protocol that uses public-key cryptography, the association between the public keys used in the protocol and the identities with which they are associated must be authenticated in a cryptographically secure manner. Communications between the client and the CA are secured using SCEP Secure Message Objects as explained in Section 3, which specifies how CMS is used to encrypt and sign the data. In order to perform the signing operation, the client uses an appropriate local certificate:
パブリックキー暗号化を使用するすべてのプロトコルと同様に、プロトコルで使用されている公開鍵とそれらが関連付けられているIDとの間の関連付けは、暗号的に安全な方法で認証されなければなりません。クライアントとCAとの間の通信は、セクション3で説明されているSCEPセキュアメッセージオブジェクトを使用して保護されており、これはCMSをデータの暗号化および署名するために使用する方法を指定します。署名操作を実行するために、クライアントは適切なローカル証明書を使用します。
1. If the client does not have an appropriate existing certificate, then a locally generated self-signed certificate MUST be used. The keyUsage extension in the certificate MUST indicate that it is valid for digitalSignature and keyEncipherment (if available). The self-signed certificate SHOULD use the same subject name and key as in the PKCS #10 request. In this case, the messageType is PKCSReq (see Section 3.2.1.2).
1. クライアントに適切な既存の証明書がない場合は、ローカルに生成された自己署名証明書を使用する必要があります。証明書のKeyUsage拡張機能は、DigitalSignatureおよびkeyEncepherment（使用可能な場合）に有効であることを示している必要があります。自己署名証明書は、PKCS＃10の要求のように同じサブジェクト名とキーを使用する必要があります。この場合、MessageTypeはPKCSREQです（セクション3.2.1.2を参照）。
2. If the client already has a certificate issued by the SCEP CA, and the CA supports renewal (see Section 2.5), that certificate SHOULD be used. In this case, the messageType is RenewalReq (see Section 3.2.1.2).
2. クライアントがすでにSCEP CAによって発行された証明書を持っていて、CAは更新をサポートしています（セクション2.5を参照）、その証明書を使用する必要があります。この場合、MessageTypeはReneWalReqです（セクション3.2.1.2を参照）。
3. Alternatively, if the client has no certificate issued by the SCEP CA but has credentials from an alternate CA, then the certificate issued by the alternate CA MAY be used in a renewal request as described above. The SCEP CA's policy will determine whether the request can be accepted or not.
3. あるいは、クライアントがSCEP CAによって発行されていたが代替のCAから認証情報を持たない場合、代替CAによって発行された証明書は、上述のように更新要求で使用されてもよい。SCEP CAのポリシーは、要求を受け入れるかどうかを判断します。
Note that although the above text describes several different types of operations, for historical reasons, most implementations always apply the first one, even if an existing certificate already exists. For this reason, support for the first case is mandatory while support for the latter ones are optional (see Section 2.9).
上記のテキストでは、歴史的な理由から、既存の証明書がすでに存在していても、ほとんどの実装は常に最初の実装を適用します。このため、後者のサポートはオプションですが、最初のケースのサポートは必須です（セクション2.9を参照）。
During the certificate-enrolment process, the client MUST use the selected certificate's key when signing the CMS envelope (see Section 3). This certificate will be either the self-signed one matching the PKCS #10 request or the CA-issued one used to authorise a renewal, and it MUST be included in the signedData certificates field (possibly as part of a full certificate chain). If the key being certified allows encryption, then the CA's CertResp will use the same certificate's public key when encrypting the response.
証明書登録プロセス中に、CMSエンベロープに署名するときにクライアントは選択した証明書のキーを使用する必要があります（セクション3を参照）。この証明書は、PKCS＃10の要求または更新の承認に使用されるCA発行の1つと一致する自己署名付きのものになり、SignedData Certificatesフィールド（おそらく完全な証明書チェーンの一部として）含める必要があります。認定されているキーが暗号化を許可すると、CAのCertrespは応答を暗号化するときに同じ証明書の公開鍵を使用します。
Note that, in the case of renewal operations, this means that the request will be signed and authenticated with the key in the previously issued certificate rather than the key in the PKCS #10 request, and the response may similarly be returned encrypted with the key in the previously issued certificate. This has security implications; see Section 7.6.
更新操作の場合、これは、要求がPKCS＃10要求の鍵ではなく、前回発行された証明書のキーで署名され認証され、その応答は同様にキーで暗号化されることがあることを意味します。以前に発行された証明書に。これにはセキュリティの影響があります。7.6項を参照してください。
PKCS #10 [RFC2986] specifies a PKCS #9 [RFC2985] challengePassword attribute to be sent as part of the enrolment request. When utilising the challengePassword, the CA distributes a shared secret to the client, which will be used to authenticate the request from the client. It is RECOMMENDED that the challengePassword be a one-time authenticator value to limit the ability of an attacker who can capture the authenticator from the client or CA and reuse it to request further certificates.
PKCS＃10 [RFC2986]登録要求の一部として送信されるPKCS＃9 [RFC2985] ChallengePassword属性を指定します。チャレンジパスワードを利用する場合、CAはクライアントに共有シークレットを分散させます。クライアントからの要求を認証するために使用されます。CLANGERPASSWORDは、クライアントまたはCAから認証者をキャプチャできる攻撃者の能力を制限し、さらに証明書を要求するために再利用するためのワンタイムオーセンティケータ値になることをお勧めします。
Inclusion of the challengePassword by the SCEP client is RECOMMENDED; however, its omission allows for unauthenticated authorisation of enrolment requests (which may, however, require manual approval of each certificate issue if other security measures to control issue aren't in place; see below). Inclusion is OPTIONAL for renewal requests that are authenticated by being signed with an existing certificate. The CMS envelope protects the privacy of the challengePassword.
SCEPクライアントによってChallengePasswordを含めることをお勧めします。ただし、登録要求の認証されていない承認を可能にします（ただし、問題を管理するための他のセキュリティ対策が整合されていない場合は、各証明書の課題の手動承認を必要とする可能性があります。下記参照）。包含は、既存の証明書に署名されて認証されている更新要求にオプションです。CMS Envelopeは、ChargleSPASSWORDのプライバシーを保護します。
A client that is performing certificate renewal as per Section 2.5 SHOULD omit the challengePassword but MAY send the originally distributed shared secret in the challengePassword attribute. The SCEP CA MAY authenticate the request using the challengePassword in addition to the previously issued certificate that signs the request. The SCEP CA MUST NOT attempt to authenticate a client based on a self-signed certificate unless it has been verified through out-of-band means such as a certificate fingerprint.
セクション2.5に従って証明書更新を実行しているクライアントは、ChargleSPASSWORDを省略しますが、CLANGERPHASSWORD属性に元々分散共有シークレットを送信することがあります。SCEP CAは、要求に署名する以前に発行された証明書に加えて、ChallengePasswordを使用して要求を認証することができます。証明書の指紋などの帯域外の手段を通して検証されていない限り、SCEP CAは自己署名証明書に基づいてクライアントを認証しようとしてはならない。
To perform the authorisation in manual mode, the client's request is placed in the PENDING state until the CA operator authorises or rejects it. Manual authorisation is used when the client has only a self-signed certificate that hasn't been previously authenticated by the CA and/or a challengePassword is not available. The SCEP CA MAY either reject unauthorised requests or mark them for manual authorisation according to CA policy.
手動モードで認証を実行するには、CAオペレータが承認または拒否するまで、クライアントの要求は保留状態になります。マニュアル承認は、クライアントが以前に認証されていない自己署名証明書だけがCAおよび/またはChallengePasswordが利用できない場合に使用されます。SCEP CAは、不正な要求を拒否するか、CAポリシーに従って手動承認のマークを付けます。
A client starts an enrolment transaction (Section 3.3.1) by creating a certificate request using PKCS #10 and sends the request to the CA enveloped using CMS (Section 3).
クライアントは、PKCS＃10を使用して証明書要求を作成し、CMSを使用してCAに要求を送信することで、登録トランザクション（セクション3.3.1）を開始します（セクション3）。
If the CA supports certificate renewal and the CA policy permits, then a new certificate with new validity dates can be issued, even though the old one is still valid. To renew an existing certificate, the client uses the RenewalReq message (see Section 3.3) and signs it with the existing client certificate. The client SHOULD use a new keypair when requesting a new certificate but MAY request a new certificate using the old keypair.
CAが証明書更新とCAポリシーを許可している場合は、古いものがまだ有効であっても、新しい有効期限日付を持つ新しい証明書を発行できます。既存の証明書を更新するために、クライアントはReneWalReqメッセージを使用しています（セクション3.3を参照）、既存のクライアント証明書に署名します。クライアントは新しい証明書を要求するときに新しいキーペアを使用する必要がありますが、古いキーペアを使用して新しい証明書を要求することがあります。
If the CA returns a CertRep message (Section 3.3.2) with status set to PENDING, the client enters into polling mode by periodically sending a CertPoll message (Section 3.3.3) to the CA until the CA operator completes the manual authentication (approving or denying the request). The frequency of the polling operation is a CA/client configuration issue and may range from seconds or minutes when the issue process is automatic but not instantaneous, through to hours or days if the certificate-issue operation requires manual approval.
CAがSTATES MESSAGEを保留に設定してCARTREPメッセージを返す場合（セクション3.3.2）、CAオペレータが手動認証を完了するまでCERTPOLLメッセージ（セクション3.3.3）をCAに定期的にCAに送信することで、クライアントはポーリングモードに入ります（承認するまたは要求を拒否する）。ポーリング操作の頻度はCA /クライアント構成の問題であり、証明書の発行操作が手動の承認を必要とする場合は、発行プロセスが自動的で瞬時には瞬時には秒または数分までの範囲です。
If polling mode is being used, then the client will send a single PKCSReq/RenewalReq message (Section 3.3.1), followed by 0 or more CertPoll messages (Section 3.3.3). The CA will, in return, send 0 or more CertRep messages (Section 3.3.2) with status set to PENDING in response to CertPolls, followed by a single CertRep message (Section 3.3.2) with status set to either SUCCESS or FAILURE.
ポーリングモードが使用されている場合、クライアントは単一のPKCSREQ / RenewReqメッセージ（セクション3.3.1）を送信し、続いて0以上のCERTPOLLメッセージを送信します（セクション3.3.3）。CAは、取得時に0個以上のCertrepメッセージ（セクション3.3.2）をSTATUS SET（STATION）にSTATESが保留中のSTATE SET、続いてSTATUSまたはFASCENTIONまたは障害のいずれかを設定します。
The client state transitions during the SCEP process are indicated in Figure 1.
SCEPプロセス中のクライアント状態遷移は図1に示されています。
CertPoll
+-----<----+
| |
| | CertRep(PENDING)
| |
[CERT-NONEXISTENT] ------> [CERT-REQ-PENDING] --------> [CERT-ISSUED]
^ PKCSReq | CertRep(SUCCESS)
| RenewalReq |
| |
+-----------------------+
CertRep(FAILURE) or
Max-time/max-polls exceeded
Figure 1: State Transition Diagram
図1：状態遷移図
The certificate-issue process starts at state CERT-NONEXISTENT. Sending a PKCSReq/RenewalReq message changes the state to CERT-REQ-PENDING.
証明書 - 発行プロセスは、State Cert-NONES存在から始まります。PKCSREQ / ReneWalReqメッセージを送信すると、状態をcert-req-pendingに変更します。
If the CA returns a CertRep message with pkiStatus set to SUCCESS, then the state changes to CERT-ISSUED.
CAがPkIStatusセットを使用してCERTREPメッセージを返す場合、その状態は証明書発行されたものになります。
If the CA returns a CertRep message with pkiStatus set to FAILURE or there is no response, then the state reverts back to CERT-NONEXISTENT.
CAがPKISTATUSSセットを使用してCERTREPメッセージを返す場合、または応答がない場合は、状態はCert-NONDSISTENTに戻ります。
If the CA returns a CertRep message with pkiStatus set to PENDING, then the client will keep polling by sending a CertPoll message until either a CertRep message with status set to SUCCESS or FAILURE is received, a timeout occurs, or the maximum number of polls has been exceeded.
CAがPKISTATUSSをPCISTATUSSに保留してCAを返す場合、Status Setを持つSETORSを持つCERTREPメッセージが受信されるまで、クライアントは、タイムアウトが発生するか、または最大ポーリング数が発生するまで、クライアントはPOLLINGを保持します。超過しました。
Figure 2 shows a successful transaction in automatic mode
図2は、自動モードでの成功取引を示しています
CLIENT CA SERVER
クライアントCA Server.
PKCSReq: PKI cert. enrolment message
--------------------------------> CertRep: pkiStatus = SUCCESS
Certificate attached
<------------------------------
Receive issued certificate.
Figure 2: Automatic Mode
図2：自動モード
Figure 3 shows a successful transaction in manual mode:
図3は、手動モードでの成功取引を示しています。
CLIENT CA SERVER
クライアントCA Server.
PKCSReq: PKI cert. enrolment message
--------------------------------> CertRep: pkiStatus = PENDING
<------------------------------
CertPoll: Polling message
--------------------------------> CertRep: pkiStatus = PENDING
<------------------------------
................ <Manual identity authentication> ...............
CertPoll: Polling message
--------------------------------> CertRep: pkiStatus = SUCCESS
Certificate attached
<------------------------------
Receive issued certificate.
Figure 3: Manual Mode
図3：手動モード
A certificate query message is defined for clients to retrieve a copy of their own certificate from the CA. It allows clients that do not store their certificates locally to obtain a copy when needed. This functionality is not intended to provide a general-purpose certificate-access service, which may be achieved instead via HTTP certificate-store access [RFC4387] or Lightweight Directory Access Protocol (LDAP).
Certificateクエリメッセージは、クライアントがCAから独自の証明書のコピーを取得するために定義されています。必要に応じてコピーを取得するために、証明書をローカルに保存しないクライアントを使用できます。この機能は、汎用の証明書アクセスサービスを提供することを意図していません。
To retrieve a certificate from the CA, a client sends a request consisting of the certificate's issuer name and serial number. This assumes that the client has saved the issuer name and the serial number of the issued certificate from the previous enrolment transaction. The transaction to retrieve a certificate consists of one GetCert (Section 3.3.4) message and one CertRep (Section 3.3.2) message, as shown in Figure 4.
CAから証明書を取得するために、クライアントは証明書の発行者名とシリアル番号からなる要求を送信します。これは、クライアントが発行者名と発行された証明書のシリアル番号を以前の登録トランザクションから保存していると仮定しています。証明書を取得するためのトランザクションは、図4に示すように、1つのGetCert（セクション3.3.4）メッセージと1つのCertrep（セクション3.3.2）メッセージで構成されています。
CLIENT CA SERVER
クライアントCA Server.
GetCert: PKI certificate query message
-------------------------------> CertRep: pkiStatus = SUCCESS
Certificate attached
<-----------------------------
Receive the certificate.
Figure 4: Retrieving a Certificate
図4：証明書の取得
SCEP clients MAY request a CRL via one of three methods:
SCEPクライアントは、3つの方法のうちの1つを介してCRLを要求することがあります。
1. If the CA supports the CRL Distribution Points (CRLDPs) extension [RFC5280] in issued certificates, then the CRL MAY be retrieved via the mechanism specified in the CRLDP.
1. CAが発行された証明書においてCRL配布ポイント（CRLDPS）拡張子[RFC5280]をサポートしている場合、CRLはCRLDPで指定されたメカニズムを介して取得されてもよい。
2. If the CA supports HTTP certificate-store access [RFC4387], then the CRL MAY be retrieved via the AuthorityInfoAcces [RFC5280] location specified in the certificate.
2. CAがHTTP証明書 - ストアアクセス[RFC4387]をサポートしている場合、CRLは証明書に指定されているAuthoritionInfoacces [RFC5280]場所を介して取得できます。
3. Only if the CA does not support CRLDPs or HTTP access should a CRL query be composed by creating a GetCRL message consisting of the issuer name and serial number from the certificate whose revocation status is being queried.
3. CAがCRLDPSまたはHTTPアクセスをサポートしていない場合にのみ、失効ステータスが照会されている証明書から発行者名とシリアル番号からなるGetCrLメッセージを作成することでCRLクエリを作成する必要があります。
The message is sent to the SCEP CA in the same way as the other SCEP requests. The transaction to retrieve a CRL consists of one GetCRL PKI message and one CertRep PKI message, which contains only the CRL (no certificates) in a degenerate certificates-only CMS SignedData message (Section 3.4), as shown in Figure 5.
メッセージは他のSCEP要求と同じ方法でSCEP CAに送信されます。CRLを取得するためのトランザクションは、図5に示すように、縮退証明書のみのCMS SignedDataメッセージ（セクション3.4）にCRL（証明書なし）のみを含む1つのGETCRL PKIメッセージと1つのCERTREP PKIメッセージで構成されています。
CLIENT CA SERVER
クライアントCA Server.
GetCRL: PKI CRL query message
---------------------------------->
CertRep: CRL attached
<-----------------------------
Receive the CRL
Figure 5: Retrieving a CRL
図5：CRLの取得
SCEP does not specify a method to request certificate revocation. In order to revoke a certificate, the client must contact the CA using a non-SCEP-defined mechanism.
SCEPは証明書失効を要求する方法を指定しません。証明書を取り消すためには、クライアントは非SCEP定義のメカニズムを使用してCAに連絡する必要があります。
At a minimum, all SCEP implementations compliant with this specification MUST support GetCACaps (Section 3.5.1), GetCACert (Section 4.2), PKCSReq (Section 3.3.1) (and its associated response messages), communication of binary data via HTTP POST (Section 4.1), and the AES128-CBC [AES] and SHA-256 [SHA2] algorithms to secure pkiMessages (Section 3.2).
最低限、この仕様に準拠したすべてのSCEP実装は、GetCacaps（セクション3.5.1）、getCacert（セクション4.2）、PKCSREQ（およびそれに関連する応答メッセージ）、HTTP POSTを介したバイナリデータの通信をサポートしている必要があります（PKimessagesを固定するためのAES 4.1）、およびAES128-CBC [AES]およびSHA-256 [SHA2]アルゴリズム（セクション3.2）。
For historical reasons, implementations MAY support communications of binary data via HTTP GET (Section 4.1), and the triple DES-CBC and SHA-1 algorithms to secure pkiMessages (Section 3.2). Implementations MUST NOT support the obsolete and/or insecure single DES and MD5 algorithms used in earlier versions of this specification, since the unsecured nature of GetCACaps means that an in-path attacker can trivially roll back the encryption used to these insecure algorithms; see Section 7.5.
歴史的な理由から、実装は、HTTP GET（セクション4.1）を介したバイナリデータの通信をサポートし、PKimessagesを保護するためのトリプルDES-CBCおよびSHA-1アルゴリズム（セクション3.2）。getCacApsの無担保の性質は、In-PASE攻撃者がこれらの不安定なアルゴリズムに使用される暗号化を些細にロールバックできることを意味しているため、実装は以前のバージョンのこの仕様で使用されているOBSOLETEおよび/または不安定な単一のDESおよびMD5アルゴリズムをサポートしてはなりません。7.5を参照してください。
CMS is a general enveloping mechanism that enables both signed and encrypted transmission of arbitrary data. SCEP messages that require confidentiality use two layers of CMS, as shown using ASN.1-like pseudocode in Figure 6. By applying both enveloping and signing transformations, the SCEP message is protected both for the integrity of its end-to-end transaction information and the confidentiality of its information portion.
CMSは、任意のデータの符号付きおよび暗号化送信の両方を可能にする一般的なエンベロープメカニズムです。機密性を必要とするSCEPメッセージは、図6のASN.1のような疑似コードを使用して示されているように、2つのCMSを使用します。そしてその情報部分の機密性。
pkiMessage {
contentType = signedData { pkcs-7 2 },
content {
digestAlgorithms,
encapsulatedContentInfo {
eContentType = data { pkcs-7 1 },
eContent { -- pkcsPKIEnvelope, optional
contentType = envelopedData { pkcs-7 3 },
content {
recipientInfo,
encryptedContentInfo {
contentType = data { pkcs-7 1 },
contentEncrAlgorithm,
encryptedContent {
messageData -- Typically PKCS #10 request
}
}
}
}
},
certificates, -- Optional
crls, -- Optional
signerInfo {
signedAttrs {
transactionID,
messageType,
pkiStatus,
failInfo, -- Optional
senderNonce / recipientNonce,
},
signature
}
}
}
Figure 6: CMS Layering
図6：CMS階層化
When a particular SCEP message carries data, this data is carried in the messageData. CertRep messages will lack any signed content and consist only of a pkcsPKIEnvelope (Section 3.2.2).
特定のSCEPメッセージがデータを搬送すると、このデータはMessageDataで運ばれます。Certrepメッセージは署名されたコンテンツを欠いており、PKCSpkienvelopeのみで構成されます（セクション3.2.2）。
The remainder of this document will refer only to "messageData", but it is understood to always be encapsulated in the pkcsPKIEnvelope (Section 3.2.2). The format of the data in the messageData is defined by the messageType attribute (see Section 3.2) of the SignedData. If there is no messageData to be transmitted, the entire pkcsPKIEnvelope MUST be omitted.
この文書の残りの部分は「MessageData」のみを参照しますが、常にPKCSPKIENVELOPEPにカプセル化されていると理解されます（セクション3.2.2）。MessageData内のデータの形式は、SignedDataのMessageType属性（セクション3.2を参照）によって定義されています。送信されるMessageDataがない場合は、pkcspkienvelope全体を省略する必要があります。
Samples of SCEP messages are available through the JSCEP project [JSCEP] in the src/samples directory.
SCEPメッセージのサンプルは、src / samplesディレクトリのJSCEPプロジェクト[JSCEP]を介して入手できます。
Creating a SCEP message consists of several stages. The content to be conveyed (in other words, the messageData) is first encrypted, and the encrypted content is then signed.
SCEPメッセージの作成はいくつかの段階で構成されています。伝達されるコンテンツ（言い換えれば、MessageData）は最初に暗号化され、その後暗号化されたコンテンツが署名されます。
The form of encryption to be applied depends on the capabilities of the recipient's public key. If the key is encryption capable (for example, RSA), then the messageData is encrypted using the recipient's public key with the CMS KeyTransRecipientInfo mechanism. If the key is not encryption capable (for example, DSA or ECDSA), then the messageData is encrypted using the challengePassword with the CMS PasswordRecipientInfo mechanism.
適用される暗号化の形式は、受信者の公開鍵の機能によって異なります。キーが暗号化対応（たとえば、RSA）の場合、MessagedAtaはCMS KeyTransRecipientInfoメカニズムを使用して受信者の公開鍵を使用して暗号化されます。キーが暗号化対応（たとえば、DSAまたはECDSAなど）ではない場合、MessageDataはCMS PasswordRecipientInfoメカニズムを使用してChargleSPASSWORDを使用して暗号化されます。
Once the messageData has been encrypted, it is signed with the sender's public key. This completes the SCEP message, which is then sent to the recipient.
MessageDataが暗号化されたら、送信者の公開鍵と署名されています。これでSCEPメッセージは完了し、これは受信者に送信されます。
Note that some early implementations of this specification dealt with keys that were not encryption capable by omitting the encryption stage, based on the text in Section 3 that indicated that "the EnvelopedData is omitted". This alternative processing mechanism SHOULD NOT be used since it exposes in cleartext the challengePassword used to authorise the certificate issue.
この仕様のいくつかの早期実装は、「封筒が省略されている」と示されたセクション3のテキストに基づいて、暗号化段階を省略することができる暗号化ではなかったキーを処理したことに注意してください。この代替処理メカニズムは、ClearTextで公開しているため、証明書の問題を認証するために使用されるChallengePasswordで公開しないでください。
The basic building block of all secured SCEP messages is the SCEP pkiMessage. It consists of a CMS SignedData content type. The following restrictions apply:
保護されたすべてのSCEPメッセージの基本的な構成ブロックはSCEP PKimessageです。それはCMS SignedDataコンテンツタイプで構成されています。以下の制限が適用されます。
* The eContentType in encapsulatedContentInfo MUST be data ({pkcs-7 1}). * The signed content, if present (FAILURE and PENDING CertRep messages will lack any signed content), MUST be a pkcsPKIEnvelope (Section 3.2.2) and MUST match the messageType attribute. * The SignerInfo MUST contain a set of authenticatedAttributes (Section 3.2.1).
* EncapsulatedContentInfoのEcontentTypeはデータでなければなりません（{PKCS-7 1}）。*存在しているコンテンツ（失敗と保留中のCertrepメッセージには署名されたコンテンツが不足しています）が、PKCSpkienveLope（セクション3.2.2）でなければならず、MessageType属性と一致する必要があります。* SignerInfoには、AuthenticedAttributesのセットが含まれている必要があります（セクション3.2.1）。
At a minimum, all messages MUST contain the following authenticatedAttributes:
最低限、すべてのメッセージには、次の認証抽象関与を含める必要があります。
* A transactionID attribute (see Section 3.2.1.1). * A messageType attribute (see Section 3.2.1.2). * A fresh senderNonce attribute (see Section 3.2.1.5). However, note the comment about senderNonces and polling in Section 3.3.2 * Any attributes required by CMS.
* TransactionID属性（セクション3.2.1.1を参照）。* MessageType属性（セクション3.2.1.2を参照）。*新鮮なSenderNonce属性（セクション3.2.1.5を参照）。ただし、セクション3.3.2 * CMSに必要な属性をセクション3.3.2でのコメントに注意してください。
If the message is a CertRep, it MUST also include the following authenticatedAttributes:
メッセージがCERTREPの場合は、次の認証抽象化も含める必要があります。
* A pkiStatus attribute (see Section 3.2.1.3). * failInfo and optional failInfoText attributes (see Section 3.2.1.4) if pkiStatus = FAILURE. * A recipientNonce attribute (see Section 3.2.1.5) copied from the senderNonce in the request that this is a response to.
* pkistatus属性（セクション3.2.1.3を参照）。* failInfoとオプションのFailInfotext属性（3.2.1.4項を参照）（セクション3.2.1.4を参照）。*これが応答であることを要求に応じて、SenderNonceからコピーされたrecipientnonce属性（セクション3.2.1.5を参照）。
The following transaction attributes are encoded as authenticated attributes and carried in the SignerInfo for this SignedData.
次のトランザクション属性は認証済み属性としてエンコードされ、このSignedDataの署名者内で搭載されています。
+================+=================+==============================+
| Attribute | Encoding | Comment |
+================+=================+==============================+
| transactionID | PrintableString | Unique ID for this |
| | | transaction as a text string |
+----------------+-----------------+------------------------------+
| messageType | PrintableString | Decimal value as a numeric |
| | | text string |
+----------------+-----------------+------------------------------+
| pkiStatus | PrintableString | Decimal value as a numeric |
| | | text string |
+----------------+-----------------+------------------------------+
| failInfo | PrintableString | Decimal value as a numeric |
| | | text string |
+----------------+-----------------+------------------------------+
| failInfoText | UTF8String | Descriptive text for the |
| | | failInfo value |
+----------------+-----------------+------------------------------+
| senderNonce | OCTET STRING | Random nonce as a 16-byte |
| | | binary data string |
+----------------+-----------------+------------------------------+
| recipientNonce | OCTET STRING | Random nonce as a 16-byte |
| | | binary data string |
+----------------+-----------------+------------------------------+
Table 1: SCEP Attributes
表1：SCEP属性
The OIDs used for these attributes are as follows:
これらの属性に使用されるOIDは次のとおりです。
+======================+===============================+
| Name | ASN.1 Definition |
+======================+===============================+
| id-VeriSign | OBJECT_IDENTIFIER ::= {2 16 |
| | US(840) 1 VeriSign(113733)} |
+----------------------+-------------------------------+
| id-pki | OBJECT_IDENTIFIER ::= {id- |
| | VeriSign pki(1)} |
+----------------------+-------------------------------+
| id-attributes | OBJECT_IDENTIFIER ::= {id-pki |
| | attributes(9)} |
+----------------------+-------------------------------+
| id-transactionID | OBJECT_IDENTIFIER ::= {id- |
| | attributes transactionID(7)} |
+----------------------+-------------------------------+
| id-messageType | OBJECT_IDENTIFIER ::= {id- |
| | attributes messageType(2)} |
+----------------------+-------------------------------+
| id-pkiStatus | OBJECT_IDENTIFIER ::= {id- |
| | attributes pkiStatus(3)} |
+----------------------+-------------------------------+
| id-failInfo | OBJECT_IDENTIFIER ::= {id- |
| | attributes failInfo(4)} |
+----------------------+-------------------------------+
| id-senderNonce | OBJECT_IDENTIFIER ::= {id- |
| | attributes senderNonce(5)} |
+----------------------+-------------------------------+
| id-recipientNonce | OBJECT_IDENTIFIER ::= {id- |
| | attributes recipientNonce(6)} |
+----------------------+-------------------------------+
| id-scep | OBJECT IDENTIFIER ::= {id- |
| | pkix 24} |
+----------------------+-------------------------------+
| id-scep-failInfoText | OBJECT IDENTIFIER ::= {id- |
| | scep 1} |
+----------------------+-------------------------------+
Table 2: SCEP Attribute OIDs
表2：SCEP属性のOID
The attributes are detailed in the following sections.
属性は次のセクションで詳しく説明されています。
A PKI operation is a transaction consisting of the messages exchanged between a client and the CA. The transactionID is a text string provided by the client when starting a transaction. The client MUST use a unique string as the transaction identifier, encoded as a PrintableString, which MUST be used for all PKI messages exchanged for a given operation, such as a certificate issue.
PKI操作は、クライアントとCAとの間で交換されたメッセージからなるトランザクションです。TransactionIDは、トランザクションを開始するときにクライアントによって提供されるテキスト文字列です。クライアントは、証明書の問題などの特定の操作に対して交換されたすべてのPKIメッセージに使用する必要があるPrintableStringとしてエンコードされたトランザクションIDとして一意の文字列を使用する必要があります。
Note that the transactionID must be unique, but not necessarily randomly generated. For example, it may be a value assigned by the CA to allow the client to be identified by their transactionID, using a value such as the client device's Extended Unique Identifier (EUI), Remote Terminal Unit (RTU) ID, or a similar unique identifier. This can be useful when the client doesn't have a preassigned Distinguished Name through which the CA can identify their request -- for example, when enrolling Supervisory Control and Data Acquisition (SCADA) devices.
TransactionIDは一意である必要がありますが、必ずしもランダムに生成される必要はありません。たとえば、クライアントデバイスの拡張固有識別子（EUI）、リモート端末装置（RTU）ID、または同様のユニークなどの値を使用して、クライアントがTransactionIDによって識別されるようにCAによって割り当てられた値であり得る。識別子。これは、クライアントにCAが要求を識別できる事前に割り当てられた識別名を持っていない場合に役立ちます。たとえば、監視制御とデータ取得（SCADA）デバイスを登録するときなどです。
The messageType attribute specifies the type of operation performed by the transaction. This attribute MUST be included in all PKI messages. The following message types are defined:
MessageType属性は、トランザクションによって実行される操作の種類を指定します。この属性はすべてのPKIメッセージに含める必要があります。次のメッセージタイプが定義されています。
+=======+============+============================================+
| Value | Name | Description |
+=======+============+============================================+
| 0 | Reserved | |
+-------+------------+--------------------------------------------+
| 3 | CertRep | Response to certificate or CRL request. |
+-------+------------+--------------------------------------------+
| 17 | RenewalReq | PKCS #10 certificate request authenticated |
| | | with an existing certificate. |
+-------+------------+--------------------------------------------+
| 19 | PKCSReq | PKCS #10 certificate request authenticated |
| | | with a shared secret. |
+-------+------------+--------------------------------------------+
| 20 | CertPoll | Certificate polling in manual enrolment. |
+-------+------------+--------------------------------------------+
| 21 | GetCert | Retrieve a certificate. |
+-------+------------+--------------------------------------------+
| 22 | GetCRL | Retrieve a CRL. |
+-------+------------+--------------------------------------------+
Table 3: SCEP Message Types
表3：SCEPメッセージタイプ
Message types not defined above MUST be treated as errors unless their use has been negotiated through GetCACaps (Section 3.5.1).
上記で定義されていないメッセージタイプは、getCacapsを介してネゴシエートされていない限り、エラーとして扱われなければなりません（セクション3.5.1）。
All response messages MUST include transaction status information, which is defined as a pkiStatus attribute:
すべての応答メッセージには、pkistatus属性として定義されているトランザクションステータス情報を含める必要があります。
+=======+=========+========================================+
| Value | Name | Description |
+=======+=========+========================================+
| 0 | SUCCESS | Request granted. |
+-------+---------+----------------------------------------+
| 2 | FAILURE | Request rejected. In this case, the |
| | | failInfo attribute, as defined in |
| | | Section 3.2.1.4, MUST also be present. |
+-------+---------+----------------------------------------+
| 3 | PENDING | Request pending for manual approval. |
+-------+---------+----------------------------------------+
Table 4: pkiStatus Attributes
表4：pkistatus属性
PKI status values not defined above MUST be treated as errors unless their use has been negotiated through GetCACaps (Section 3.5.1).
上記で定義されていないPKIステータス値は、getCacapsを介してネゴシエートされていない限り、エラーとして扱われなければなりません（セクション3.5.1）。
The failInfo attribute MUST contain one of the following failure reasons:
failInfo属性には、次のいずれかの障害の理由が含まれている必要があります。
+=======+=================+==================================+
| Value | Name | Description |
+=======+=================+==================================+
| 0 | badAlg | Unrecognised or unsupported |
| | | algorithm. |
+-------+-----------------+----------------------------------+
| 1 | badMessageCheck | Integrity check (meaning |
| | | signature verification of the |
| | | CMS message) failed. |
+-------+-----------------+----------------------------------+
| 2 | badRequest | Transaction not permitted or |
| | | supported. |
+-------+-----------------+----------------------------------+
| 3 | badTime | The signingTime attribute from |
| | | the CMS authenticatedAttributes |
| | | was not sufficiently close to |
| | | the system time. This condition |
| | | may occur if the CA is concerned |
| | | about replays of old messages. |
+-------+-----------------+----------------------------------+
| 4 | badCertId | No certificate could be |
| | | identified matching the provided |
| | | criteria. |
+-------+-----------------+----------------------------------+
Table 5: failInfo Attributes
表5：FAILINFO属性
Failure reasons not defined above MUST be treated as errors unless their use has been negotiated through GetCACaps (Section 3.5.1).
上記で定義されていない障害の高い理由は、それらの使用がgetCacapsを介してネゴシエートされていない限りエラーとして扱われなければなりません（セクション3.5.1）。
The failInfoText is a free-form UTF-8 text string that provides further information in the case of pkiStatus = FAILURE. In particular, it may be used to provide details on why a certificate request was not granted that go beyond what's provided by the near-universal failInfo = badRequest status. Since this is a free-form text string intended for interpretation by humans, implementations SHOULD NOT assume that it has any type of machine-processable content.
FailInfotextは、pkistatus =障害の場合のさらなる情報を提供する自由形式のUTF-8テキスト文字列です。特に、Universal FailInfo = BadRequestステータスによって提供されるものを超えて、証明書要求が付与されなかった理由についての詳細を提供するために使用されることがあります。これは人間による解釈を目的とした自由形式のテキスト文字列であるため、実装はそれがあらゆる種類のマシンプロセス可能コンテンツを持っていると仮定しないでください。
The senderNonce and recipientNonce attributes are each a 16-byte random number generated for each transaction. These are intended to prevent replay attacks.
SenderNonce属性とRecipientNonce属性は、各トランザクションに対して生成された16バイトの乱数です。これらは再生攻撃を防ぐためのものです。
When a sender sends a PKI message to a recipient, a fresh senderNonce MUST be included in the message. The recipient MUST copy the senderNonce into the recipientNonce of the reply as a proof of liveliness. The original sender MUST verify that the recipientNonce of the reply matches the senderNonce it sent in the request. If the nonce does not match, then the message MUST be rejected.
送信者がPKIメッセージを受信者に送信すると、メッセージに新規のSenderNonceを含める必要があります。受信者は、居住の証明としての返信の受信者ノンクにSenderNonceをコピーする必要があります。元の送信者は、返信の受信者ノインソンが要求に送信されたSenderNonceと一致することを確認する必要があります。nonceが一致しない場合、メッセージは拒否されなければなりません。
Note that since SCEP exchanges consist of a single request followed by a single response, the use of distinct sender and recipient nonces is redundant, since the client sends a nonce in its request and the CA responds with the same nonce in its reply. In effect, there's just a single nonce, identified as senderNonce in the client's request and recipientNonce in the CA's reply.
SCEP交換は単一の要求とそれに続く単一の応答で構成されているので、クライアントはその要求にNonceを送信し、CAはその返信で同じNonceで応答するため、異なる送信者と受信者のノンスの使用は冗長です。実際には、CAの返信のクライアントの要求およびRecipientNonceのSenderNonceとして識別された単一のNonceだけがあります。
The information portion of a SCEP message is carried inside an EnvelopedData content type, as defined in CMS, with the following restrictions:
SCEPメッセージの情報部分は、CMSで定義されているように、CMSで定義されている封筒内容タイプ内で搭載されています。
* contentType in encryptedContentInfo MUST be data ({pkcs-7 1}). * encryptedContent MUST be the SCEP message being transported (see Section 4) and MUST match the messageType authenticated Attribute in the pkiMessage.
* EncryptedContentInfoのContentTypeはデータでなければなりません（{PKCS-7 1}）。*暗号化されているContentは、転送されているSCEPメッセージでなければならず（セクション4を参照）、PKimessageのMessageType認証済み属性と一致する必要があります。
All of the messages in this section are pkiMessages (Section 3.2), where the type of the message MUST be specified in the "messageType" authenticated Attribute. Each section defines a valid message type, the corresponding messageData formats, and mandatory authenticated attributes for that type.
このセクションのすべてのメッセージはPKIMESSAGES（セクション3.2）で、メッセージの種類は「MessageType」認証済み属性に指定する必要があります。各セクションは、有効なメッセージタイプ、対応するMessagedAdaフォーマット、およびその型の必須認証属性を定義します。
The messageData for this type consists of a PKCS #10 Certificate Request. The certificate request MUST contain at least the following items:
このタイプのMessageDataは、PKCS＃10証明書要求で構成されています。証明書要求には、少なくとも次の項目が含まれている必要があります。
* The subject Distinguished Name. * The subject public key. * For a PKCSReq, if authorisation based on a shared secret is being used, a challengePassword attribute.
* 主題の識別名。*本公開鍵。* PKCSREQの場合、共有秘密に基づく権限が使用されている場合は、ChargplePassword属性です。
In addition, the message must contain the authenticatedAttributes specified in Section 3.2.1.
さらに、メッセージには、セクション3.2.1で指定されている認証済みattributesを含める必要があります。
The messageData for this type consists of a degenerate certificates-only CMS SignedData message (Section 3.4). The exact content required for the reply depends on the type of request that this message is a response to. The request types are detailed in Sections 3.3.2.1 and 4. In addition, the message must contain the authenticatedAttributes specified in Section 3.2.1.
このタイプのMessageDataは、縮退証明書のみのCMS SignedDataメッセージで構成されています（セクション3.4）。応答に必要な正確なコンテンツは、このメッセージが応答である要求の種類によって異なります。要求タイプはセクション3.3.2.1および4に詳述されている。
Earlier draft versions of this specification required that this message include a senderNonce alongside the recipientNonce, which was to be used to chain to subsequent polling operations. However, if a single message was lost during the potentially extended interval over which polling could take place (see Section 5 for an example of this), then if the implementation were to enforce this requirement, the overall transaction would fail, even though nothing had actually gone wrong. Because of this issue, implementations mostly ignored the requirement to either carry this nonce over to subsequent polling messages or verify its presence. More recent versions of the specification no longer require the chaining of nonces across polling operations.
この仕様の以前のドラフトのバージョンは、このメッセージが受信者ノーンと並んでのSenderNonceを含むことが必要であり、これは後続のポーリング操作にチェーン化するために使用されます。ただし、ポーリングが行われる可能性がある潜在的に延長された間隔の間に単一のメッセージが失われた場合（これの例についてはセクション5を参照）、実装がこの要件を強制することになった場合は、何もしなかったとしても、トランザクション全体は失敗します。実際に間違っていた。この問題のため、実装は主にこのノンが後続のポーリングメッセージに対して実行するか、またはその存在を検証するための要件を無視しました。仕様の最近のバージョンは、ポーリング操作を越えたノンスの連鎖をもはや必要としません。
When the pkiStatus attribute is set to SUCCESS, the messageData for this message consists of a degenerate certificates-only CMS SignedData message (Section 3.4). The content of this degenerate certificates-only SignedData message depends on what the original request was, as outlined in Table 6.
pkistatus属性が成功するように設定されている場合、このメッセージのMessageDataは縮退証明書のみのCMS SignedDataメッセージで構成されています（セクション3.4）。この縮退証明書の内容 - 表6に概説したように、元の要求のみが何であるかによって異なります。
+==============+===============================================+
| Request-type | Reply-contents |
+==============+===============================================+
| PKCSReq | The reply MUST contain at least the issued |
| | certificate in the certificates field of the |
| | SignedData. The reply MAY contain additional |
| | certificates, but the issued certificate MUST |
| | be the leaf certificate. |
+--------------+-----------------------------------------------+
| RenewalReq | Same as PKCSReq |
+--------------+-----------------------------------------------+
| CertPoll | Same as PKCSReq |
+--------------+-----------------------------------------------+
| GetCert | The reply MUST contain at least the requested |
| | certificate in the certificates field of the |
| | SignedData. The reply MAY contain additional |
| | certificates, but the requested certificate |
| | MUST be the leaf certificate. |
+--------------+-----------------------------------------------+
| GetCRL | The reply MUST contain the CRL in the crls |
| | field of the SignedData. |
+--------------+-----------------------------------------------+
Table 6: CertRep Response Types
表6：CERTREPレスポンスタイプ
When the pkiStatus attribute is set to FAILURE, the reply MUST also contain a failInfo (Section 3.2.1.4) attribute set to the appropriate error condition describing the failure. The reply MAY also contain a failInfoText attribute providing extended details on why the operation failed, typically to expand on the catchall failInfo = badRequest status. The pkcsPKIEnvelope (Section 3.2.2) MUST be omitted.
pkistatus属性が障害に設定されている場合、応答にFailInfo（セクション3.2.1.4）属性が失敗を記述する適切なエラー状態に設定されている属性も含まなければなりません。応答には、aptionAll failinfo = badRequestステータスで展開するのか、通常、操作が失敗した理由に関する拡張された詳細を提供するFailInfotext属性を含みます。pkcspkienvelope（セクション3.2.2）は省略する必要があります。
When the pkiStatus attribute is set to PENDING, the pkcsPKIEnvelope (Section 3.2.2) MUST be omitted.
pkistatus属性が保留中に設定されている場合は、PKCSPKIENVELOPE（セクション3.2.2）を省略する必要があります。
This message is used for certificate polling. For unknown reasons, it was referred to as "GetCertInitial" in earlier draft versions of this specification. The messageData for this type consists of an IssuerAndSubject:
このメッセージは証明書ポーリングに使用されます。未知の理由で、それは本明細書の以前のドラフトバージョンで「getCertInitial」と呼ばれていました。このタイプのMessageDataは、IssuerandSubjectで構成されています。
issuerAndSubject ::= SEQUENCE {
issuer Name,
subject Name
}
The issuer is set to the subjectName of the CA (in other words, the intended issuerName of the certificate that's being requested). The subject is set to the subjectName used when requesting the certificate.
発行者は、CAの議題名（すなわち、要求されている証明書の意図されたissuername）に設定されています。件名は、証明書を要求するときに使用される件名に設定されます。
Note that both of these fields are redundant; the CA is identified by the recipientInfo in the pkcsPKIEnvelope (or in most cases, simply by the server that the message is being sent to), and the client/ transaction being polled is identified by the transactionID. Both of these fields can be processed by the CA without going through the cryptographically expensive process of unwrapping and processing the issuerAndSubject. For this reason, implementations SHOULD assume that the polling operation will be controlled by the recipientInfo and transactionID rather than the contents of the messageData. In addition, the message must contain the authenticatedAttributes specified in Section 3.2.1.
これらのフィールドの両方が冗長であることに注意してください。CAは、PKCSPKIENVELOPES（またはほとんどの場合、メッセージが送信されているサーバーによって）recipientInfoによって識別され、ポーリングされているクライアント/トランザクションはTransactionIDによって識別されます。これらのフィールドは両方とも、IssuerAndSubjectをアントラップして処理する暗号的に高価なプロセスを経て、CAによって処理できます。このため、実装は、ポーリング操作がMessageDataの内容ではなく、受信者内容とTransactionIDによって制御されると仮定する必要があります。さらに、メッセージには、セクション3.2.1で指定されている認証済みattributesを含める必要があります。
The messageData for these types consist of an IssuerAndSerialNumber, as defined in CMS, that uniquely identifies the certificate being requested, either the certificate itself for GetCert or its revocation status via a CRL for GetCRL. In addition, the message must contain the authenticatedAttributes specified in Section 3.2.1.
これらのタイプのMessageDataは、要求されている証明書を一意に識別し、証明書自体、またはGetCRLのCRLを介した失効状態のいずれかを一意に識別する、IssuerandSerialNumberで構成されています。さらに、メッセージには、セクション3.2.1で指定されている認証済みattributesを含める必要があります。
These message types, while included here for completeness, apply unnecessary cryptography and messaging overhead to the simple task of transferring a certificate or CRL (see Section 7.8). Implementations SHOULD prefer HTTP certificate-store access [RFC4387] or LDAP over the use of these messages.
これらのメッセージタイプは、完全性のためにここに含まれていますが、証明書またはCRLを転送する簡単なタスクに不要な暗号化とメッセージングオーバーヘッドを適用します（セクション7.8を参照）。これらのメッセージを使用するには、実装はHTTP証明書ストアアクセス[RFC4387]またはLDAPを好む必要があります。
CMS includes a degenerate case of the SignedData content type in which there are no signers. The use of such a degenerate case is to disseminate certificates and CRLs. For SCEP, the content field of the ContentInfo value of a degenerate certificates-only SignedData MUST be omitted. When carrying certificates, the certificates are included in the certificates field of the SignedData. When carrying a CRL, the CRL is included in the crls field of the SignedData.
CMSには、署名者がないSignedData Content Typeの縮退ケースが含まれています。そのような縮退する場合の使用は、証明書およびCRLを普及させることである。SCEPの場合、縮退証明書のContentInfo値のコンテンツフィールドは省略する必要があります。証明書を運ぶとき、証明書はSignedDataの証明書フィールドに含まれています。CRLを運ぶとき、CRLはSignedDataのCRLSフィールドに含まれています。
In order to provide support for future enhancements to the protocol, CAs MUST implement the GetCACaps message to allow clients to query which functionality is available from the CA.
プロトコルに対する将来の機能強化のためのサポートを提供するために、CAはクライアントがCAからどの機能を利用可能であるかクライアントを照会できるようにGetCacapsメッセージを実装する必要があります。
This message requests capabilities from a CA, with the format as described in Section 4.1:
このメッセージは、CAから機能を要求します。
"GET" SP SCEPPATH "?operation=GetCACaps" SP HTTP-version CRLF
"get" sp sceppath "？operation = getcacaps" sp http-version crlf
The response for a GetCACaps message is a list of CA capabilities, in plain text and in any order, separated by <CR><LF> or <LF> characters. This specification defines the following keywords (quotation marks are not sent):
GetCacAPSメッセージの応答は、プレーンテキスト内のCA機能、および任意の順序で、<CR> <LF>または<LF>文字で区切っています。この仕様は、次のキーワードを定義します（引用符は送信されません）。
+==================+========================================+
| Keyword | Description |
+==================+========================================+
| AES | CA supports the AES128-CBC encryption |
| | algorithm. |
+------------------+----------------------------------------+
| DES3 | CA supports the triple DES-CBC |
| | encryption algorithm. |
+------------------+----------------------------------------+
| GetNextCACert | CA supports the GetNextCACert message. |
+------------------+----------------------------------------+
| POSTPKIOperation | CA supports PKIOPeration messages sent |
| | via HTTP POST. |
+------------------+----------------------------------------+
| Renewal | CA supports the Renewal CA operation. |
+------------------+----------------------------------------+
| SHA-1 | CA supports the SHA-1 hashing |
| | algorithm. |
+------------------+----------------------------------------+
| SHA-256 | CA supports the SHA-256 hashing |
| | algorithm. |
+------------------+----------------------------------------+
| SHA-512 | CA supports the SHA-512 hashing |
| | algorithm. |
+------------------+----------------------------------------+
| SCEPStandard | CA supports all mandatory-to-implement |
| | sections of the SCEP standard. This |
| | keyword implies "AES", |
| | "POSTPKIOperation", and "SHA-256", as |
| | well as the provisions of Section 2.9. |
+------------------+----------------------------------------+
Table 7: GetCACaps Response Keywords
表7：GetCacAps Responseキーワード
Table 7 lists all of the keywords that are defined in this specification. A CA MAY provide additional keywords advertising further capabilities and functionality. A client MUST be able to accept and ignore any unknown keywords that might be sent by a CA.
表7に、この仕様で定義されているすべてのキーワードを示します。CAはさらなる機能および機能を広告する追加のキーワードを提供することができる。クライアントは、CAによって送信される可能性のある未知のキーワードを受け入れて無視できなければなりません。
The CA MUST use the text case specified here, but clients SHOULD ignore the text case when processing this message. Clients MUST accept the standard HTTP-style text delimited by <CR><LF> as well as the text delimited by <LF> specified in an earlier draft version of this specification.
CAはここで指定されたテキストケースを使用する必要がありますが、このメッセージを処理するときにクライアントはテキストの場合を無視する必要があります。クライアントは、<CR> <LF>で区切られた標準のHTTPスタイルのテキストと、この仕様の以前のドラフトバージョンで指定された<LF>で区切られたテキストを受け入れなければなりません。
The client SHOULD use SHA-256 in preference to SHA-1 hashing and AES128-CBC in preference to triple DES-CBC if they are supported by the CA. Although the CMS format allows any form of AES and SHA-2 to be specified, in the interests of interoperability the de facto universal standards of AES128-CBC and SHA-256 SHOULD be used.
クライアントは、CAでサポートされている場合、SHA-1ハッシュおよびAES128-CBCを好み、Triple DES-CBCを好みます。CMSフォーマットは、相互運用性の興味において、AES128-CBCおよびSHA-256の事実上のユニバーサル基準を使用する必要がある。
Announcing some of these capabilities individually is redundant, since they're required as mandatory-to-implement functionality (see Section 2.9) whose presence as a whole is signalled by the "SCEPStandard" capability. However, it may be useful to announce them in order to deal with older implementations that would otherwise default to obsolete, insecure algorithms and mechanisms.
これらの機能の一部を個別にアナウンスするのは冗長です。ただし、そうでなければデフォルトでは廃止され、不安定なアルゴリズムおよびメカニズムになることになる古い実装に対処するためにそれらをアナウンスするのに役立ちます。
If the CA supports none of the above capabilities, it SHOULD return an empty message. A CA MAY simply return an HTTP error. A client that receives an empty message or an HTTP error SHOULD interpret the response as if none of the capabilities listed are supported by the CA.
CAが上記の機能のどれもサポートしていない場合は、空のメッセージを返す必要があります。CAは単にHTTPエラーを返すことができます。空のメッセージまたはHTTPエラーを受信するクライアントは、リストされている機能のどれもCAでサポートされていないかのように応答を解釈する必要があります。
Note that at least one widely deployed server implementation supports several of the above operations but doesn't support the GetCACaps message to indicate that it supports them, and it will close the connection if sent a GetCACaps message. This means that the equivalent of GetCACaps must be performed through server fingerprinting, which can be done using the ID string "Microsoft-IIS". Newer versions of the same server, if sent a SCEP request using AES and SHA-2, will respond with an invalid response that can't be decrypted, requiring the use of 3DES and SHA-1 in order to obtain a response that can be processed, even if AES and/or SHA-2 are allegedly supported. In addition, the server will generate CA certificates that only have one, but not both, of the keyEncipherment and digitalSignature keyUsage flags set, requiring that the client ignore the keyUsage flags in order to use the certificates for SCEP.
少なくとも1つの広く展開されたサーバー実装は、上記の操作のいくつかをサポートしていますが、それがサポートしていることを示すためのGetCacapsメッセージをサポートしていないことに注意してください。つまり、GetCacapsの同等のサーバーのフィンガープリントを通して実行する必要があります。これはID文字列 "Microsoft-IIS"を使用して実行できます。同じサーバーの新しいバージョンが、AESとSHA-2を使用してSCEP要求を送信した場合、復号化できない無効な応答で応答し、3DESとSHA-1の使用を必要とします。AESおよび/またはSHA-2があったとしても、処理されても処理されています。さらに、サーバーは、キー暗号化とDigitalSignature KeyUsageフラグを設定しているが両方のみを持つCA証明書を生成し、クライアントはSCEPの証明書を使用するためにKeyUsageフラグを無視する必要があります。
The Content-type of the reply SHOULD be "text/plain". Clients SHOULD ignore the Content-type, as older implementations of SCEP may send various Content-types.
応答のコンテンツタイプは「テキスト/プレーン」にする必要があります。SCEPの古い実装がさまざまなコンテンツタイプを送信できるため、クライアントはContent-Typeを無視する必要があります。
Example:
例：
GET /cgi-bin/pkiclient.exe?operation=GetCACaps HTTP/1.1
might return:
戻るかもしれません：
AES GetNextCACert POSTPKIOperation SCEPStandard SHA-256
AES getNextCACERT POTPKIOPERATIORS SCEPSTANDARD SHA-256
This means that the CA supports modern crypto algorithms, and the GetNextCACert message allows PKIOperation messages (PKCSReq/ RenewalReq, GetCert, CertPoll, ...) to be sent using HTTP POST and is compliant with the final version of the SCEP standard.
つまり、CAが最新の暗号アルゴリズムをサポートし、getNextCacertメッセージではPKIoperationメッセージ（PKCSREQ / ReneWalReq、getCert、...）がHTTP POSTを使用して送信され、SCEP規格の最終バージョンに準拠しています。
This section describes the SCEP Transactions and their HTTP [RFC7230] transport mechanism.
このセクションでは、SCEPトランザクションとそのHTTP [RFC7230]トランスポートメカニズムについて説明します。
Note that SCEP doesn't follow best current practices on usage of HTTP. In particular, it recommends ignoring some media types and hard-codes specific URI paths. Guidance on the appropriate application of HTTP in these circumstances may be found in [HTTP].
SCEPはHTTPの使用方法に関する最良の現在の慣行に従わないことに注意してください。特に、一部のメディアタイプとハードコード固有のURIパスを無視することをお勧めします。これらの状況におけるHTTPの適切な適用に関するガイダンスは[HTTP]にあります。
SCEP uses the HTTP POST and GET methods [RFC7230] to exchange information with the CA. The following defines the ABNF syntax of HTTP POST and GET methods sent from a client to a CA:
SCEPはHTTP POSTとGETメソッド[RFC7230]を使用してCAと情報を交換します。以下は、HTTP POSTのABNF構文とクライアントからCAに送信されたメソッドの取得を定義します。
POSTREQUEST = "POST" SP SCEPPATH "?operation=" OPERATION SP HTTP-version CRLF
POSTREQUEST = "POST" SP SCEPPATH "" OPEROCT = "オペレーションsp http-version crlf
GETREQUEST = "GET" SP SCEPPATH "?operation=" OPERATION "&message=" MESSAGE SP HTTP-version CRLF
GetRequest = "get" sp sceppath "？operation ="演算 "＆message ="メッセージsp http-version crlf
where:
ただし：
* SCEPPATH is the HTTP URL path for accessing the CA. Clients SHOULD set SCEPPATH to the fixed string "/cgi-bin/pkiclient.exe" unless directed to do otherwise by the CA. * OPERATION depends on the SCEP transaction and is defined in the following sections. * HTTP-version is the HTTP version string, which is "HTTP/1.1" for [RFC7230]. * SP and CRLF are space and carriage return/linefeed, as defined in [RFC5234].
* SCEPPathは、CAにアクセスするためのHTTP URLパスです。クライアントは、CAによってそうでなければ指示されない限り、SCEPPATHを固定文字列 "/cgi-bin/pkiclient.exeに設定する必要があります。*操作はSCEPトランザクションによって異なり、次のセクションで定義されています。* HTTPバージョンはHTTPバージョン文字列です。[RFC7230]の「HTTP / 1.1」です。* SPとCRLFは、[RFC5234]で定義されているように、スペースとキャリッジリターン/ラインフィードです。
The CA will typically ignore SCEPPATH, since it's unlikely to be issuing certificates via a web server. Clients SHOULD set SCEPPATH to the fixed string "/cgi-bin/pkiclient.exe" unless directed to do otherwise by the CA. The CA SHOULD ignore the SCEPPATH unless its precise format is critical to the CA's operation.
CAは通常、Webサーバーを介して証明書を発行している可能性は低いため、SCEPPathを無視します。クライアントは、CAによってそうでなければ指示されない限り、SCEPPATHを固定文字列 "/cgi-bin/pkiclient.exeに設定する必要があります。CAは、正確な形式がCAの操作にとって重要でない限り、SCEPPATHを無視する必要があります。
Early SCEP drafts performed all communications via GET messages, including non-idempotent ones that should have been sent via POST messages; see [HTTP] for details. This has caused problems because of the way that the (supposedly) idempotent GET interacts with caches and proxies, and because the extremely large GET requests created by encoding CMS messages may be truncated in transit. These issues are typically not visible when testing on a LAN, but crop up during deployment over WANs. If the remote CA supports POST, the CMS-encoded SCEP messages MUST be sent via HTTP POST instead of HTTP GET. This applies to any SCEP message except GetCACert, GetNextCACert, and GetCACaps and avoids the need for base64 and URL encoding that's required for GET messaging. The client can verify that the CA supports SCEP messages via POST by looking for the "SCEPStandard" or "POSTPKIOperation" capability (see Section 3.5.2).
初期のSCEPドラフトは、POSTメッセージを介して送信されるべきであるIDEMPOTENT以外のものを含む、Getメッセージを介してすべての通信を行いました。詳細は[HTTP]を参照してください。これは、IdemPotentがキャッシュとプロキシと対話することを邪魔しているため、CMSメッセージをエンコードすることによって作成された非常に大きなGET要求がトランジットで切り捨てられる可能性があるため、問題が発生しました。これらの問題は通常、LANでテストするときは表示されませんが、WANSの展開中にクロムアップします。リモートCAがPOSTをサポートしている場合は、HTTP GETの代わりにCMSエンコードされたSCEPメッセージをHTTP POSTで送信する必要があります。これはGetCacert、getNextCacert、およびGetCacapsを除くSCEPメッセージにも適用され、メッセージングGet Messagingに必要なBase64とURLエンコーディングの必要性を回避します。クライアントは、「ScePStandard」または「PostpkIoperation」機能を探して、CAがPOSTを介してSCEPメッセージをサポートしていることを確認できます（セクション3.5.2を参照）。
If a client or CA uses HTTP GET and encounters HTTP-related problems such as messages being truncated, seeing errors such as HTTP 414 ("Request-URI too long"), or simply having the message not sent/ received at all when standard requests to the server (for example, via a web browser) work, then this is a symptom of the problematic use of HTTP GET. The solution to this problem is to update the implementation to use HTTP POST instead. In addition, when using GET, it's recommended to test the implementation from as many different network locations as possible to determine whether the use of GET will cause problems with communications.
クライアントまたはCAがHTTPを使用している場合、メッセージが切り捨てられているメッセージなどのHTTP関連の問題を取得し、HTTP関連の問題が発生した場合、HTTP 414（ "Request-Uri"）などのエラー（ "Request-Uri"）、または単に標準の要求がまったく送信されないサーバーに（たとえば、Webブラウザ経由）が機能し、これはHTTP GETの問題のある使用の症状です。この問題に対する解決策は、代わりにHTTP POSTを使用するように実装を更新することです。さらに、GETを使用する場合は、できるだけ多くの異なるネットワークの場所から実装をテストして、GETの使用に通信に問題が発生するかどうかを判断することをお勧めします。
When using GET messages to communicate binary data, base64 encoding as specified in Section 4 of [RFC4648] MUST be used. The base64-encoded data is distinct from "base64url" and may contain URI reserved characters; thus, it MUST be escaped as specified in [RFC3986] in addition to being base64 encoded. Finally, the encoded data is inserted into the MESSAGE portion of the HTTP GET request.
GETメッセージを使用してバイナリデータを通信する場合は、[RFC4648]のセクション4で指定されているBASE64エンコードを使用する必要があります。Base64エンコードされたデータは「Base64URL」とは異なり、URI予約文字を含めることができます。したがって、Base64エンコードされたものに加えて、[RFC3986]で指定されているとおりにエスケープする必要があります。最後に、符号化データがHTTP GET要求のメッセージ部分に挿入されます。
To get the CA certificate(s), the client sends a GetCACert message to the CA. The OPERATION MUST be set to "GetCACert". There is no request data associated with this message.
CA証明書を取得するには、クライアントはGetCacertメッセージをCAに送信します。操作は "getCACERT"に設定する必要があります。このメッセージに関連付けられている要求データはありません。
The response for GetCACert is different between the case where the CA directly communicates with the client during the enrolment and the case where an intermediate CA exists and the client communicates with this CA during the enrolment.
登録中にCAがクライアントと直接通信する場合と、中間CAが存在し、クライアントが登録中にこのCAと通信する場合との間で、GetCacertの応答は異なります。
If the CA does not have any intermediate CA certificates, the response consists of a single X.509 CA certificate. The response will have a Content-Type of "application/x-x509-ca-cert".
CAに中間のCA証明書がない場合、応答は単一のX.509 CA証明書で構成されています。応答には、Content-Typeが "Application / X-X509-CA-CER"にあります。
"Content-Type: application/x-x509-ca-cert"
"content-type：application / x-x509-ca-cert"
<binary X.509>
<バイナリX.509>
If the CA has intermediate CA certificates, the response consists of a degenerate certificates-only CMS SignedData message (Section 3.4) containing the certificates, with the intermediate CA certificate(s) as the leaf certificate(s). The response will have a Content-Type of "application/x-x509-ca-ra-cert". Note that this designation is used for historical reasons due to its use in older versions of this specification -- no special meaning should be attached to the label.
CAが中間CA証明書を持っている場合、応答は証明書を含む縮退証明書専用CMS SignedDataメッセージ（セクション3.4）で、中間CA証明書（S）がリーフ証明書として構成されています。応答には、 "application / x-x509-ca-ra-cert"のコンテンツ型があります。この指定は、この仕様の古いバージョンでの使用により歴史的な理由でこの指定が使用されています。
"Content-Type: application/x-x509-ca-ra-cert"
"content-type：application / x-x509-ca-ra-cert"
<binary CMS>
<バイナリCMS>
A PKCSReq/RenewalReq (Section 3.3.1) message is used to perform a certificate enrolment or renewal transaction. The OPERATION MUST be set to "PKIOperation". Note that when used with HTTP POST, the only OPERATION possible is "PKIOperation", so many CAs don't check this value or even notice its absence. When implemented using HTTP POST, the message is sent with a Content-Type of "application/x-pki-message" and might look as follows:
PKCSREQ / ReneWalReq（セクション3.3.1）メッセージは、証明書登録または更新トランザクションを実行するために使用されます。操作は「PKIOperation」に設定する必要があります。HTTP POSTで使用する場合は、可能な唯一の操作は「PKIOperation」であるため、多くのCASはこの値をチェックしたり、その不在に注目したりしません。HTTP POSTを使用して実装されると、メッセージは「アプリケーション/ X-PKIメッセージ」のコンテンツタイプで送信され、次のようになります。
POST /cgi-bin/pkiclient.exe?operation=PKIOperation HTTP/1.1
Content-Length: <length of data>
Content-Type: application/x-pki-message
<binary CMS data>
<バイナリCMSデータ>
When implemented using HTTP GET, this might look as follows:
HTTP GETを使用して実装されている場合、これは次のようになります。
GET /cgi-bin/pkiclient.exe?operation=PKIOperation& \
message=MIAGCSqGSIb3DQEHA6CAMIACAQAxgDCBzAIBADB2MG \
IxETAPBgNVBAcTCE......AAAAAA== HTTP/1.1
If the request is granted, a CertRep SUCCESS message (Section 3.3.2.1) is returned. If the request is rejected, a CertRep FAILURE message (Section 3.3.2.2) is returned. If the CA is configured to manually authenticate the client, a CertRep PENDING message (Section 3.3.2.3) MAY be returned. The CA MAY return a PENDING for other reasons.
要求が許可されている場合は、Certrep Success Message（セクション3.3.2.1）が返されます。要求が拒否された場合は、Certrep障害メッセージ（セクション3.3.2.2）が返されます。CAが手動でクライアントを認証するように構成されている場合は、Certrep保留中のメッセージ（セクション3.3.2.3）が返されます。CAは他の理由で保留中に戻ることがあります。
The response will have a Content-Type of "application/x-pki-message".
応答には、「アプリケーション/ X-PKIメッセージ」のコンテンツタイプがあります。
"Content-Type: application/x-pki-message"
"content-type：application / x-pki-message"
<binary CertRep message>
<バイナリCERTREPメッセージ>
When the client receives a CertRep message with pkiStatus set to PENDING, it will enter the polling state by periodically sending CertPoll messages to the CA until either the request is granted and the certificate is sent back or the request is rejected or some preconfigured time limit for polling or maximum number of polls is exceeded. The OPERATION MUST be set to "PKIOperation".
クライアントがPkIStatus SetをPhistatus Setで受信すると、要求が許可されているか、証明書が送信されるか、要求が拒否されるか、要求が拒否されるか、要求が拒否されるか、要求が拒否されるか、要求が拒否されるか、要求が拒否されるまで、クライアントがCertpollメッセージをCAに送信することで、Polling状態をCAに送信します。ポーリングまたは最大ポーリング数を超えました。操作は「PKIOperation」に設定する必要があります。
CertPoll messages exchanged during the polling period MUST carry the same transactionID attribute as the previous PKCSReq/RenewalReq. A CA receiving a CertPoll for which it does not have a matching PKCSReq/RenewalReq MUST reject this request.
ポーリング期間中に交換されたCertPollメッセージは、前のPKCSreq / ReneWalReqと同じTransactionID属性を持つ必要があります。Matching PhcSreq / RenewalReqが一致しないCERTPOLLを受信するCAは、この要求を拒否しなければなりません。
Since at this time the certificate has not been issued, the client can only use its own subject name (which was contained in the original PKCS# 10 sent via PKCSReq/RenewalReq) to identify the polled certificate request (but see the note on identification during polling in Section 3.3.3). In theory, there can be multiple outstanding requests from one client (for example, if different keys and different key usages were used to request multiple certificates), so the transactionID must also be included to disambiguate between multiple requests. In practice, however, the client SHOULD NOT have multiple requests outstanding at any one time, since this tends to confuse some CAs.
この時点で証明書が発行されていないので、クライアントは自分自身のサブジェクト名を使用しています（PKCSreq / ReneWalreqを介して送信された元のPKCS＃10に含まれていた）、ポーリングされた証明書要求を識別することができます（セクション3.3.3のポーリング）。理論的には、あるクライアントからの複数の未処理の要求がある可能性があります（たとえば、さまざまなキーとさまざまなキー使用量が複数の証明書を要求するために使用された場合）、TransactionIDも複数の要求間で曖昧さを損なうために含める必要があります。ただし、実際には、クライアントはいくつかのCAを混同する傾向があるため、一度に依頼されている複数の要求はありません。
The response messages for CertPoll are the same as in Section 4.3.1.
CertPollの応答メッセージはセクション4.3.1と同じです。
A client can query an issued certificate from the SCEP CA, as long as the client knows the issuer name and the issuer-assigned certificate serial number.
クライアントが発行者名と発行者が割り当てられた証明書のシリアル番号を知っている限り、クライアントはSCEP CAから発行された証明書を照会できます。
This transaction consists of one GetCert (Section 3.3.4) message sent to the CA by a client and one CertRep (Section 3.3.2) message sent back from the CA. The OPERATION MUST be set to "PKIOperation".
このトランザクションは、クライアントからCAに送信された1つのGetCert（セクション3.3.4）メッセージで構成されています。操作は「PKIOperation」に設定する必要があります。
In this case, the CertRep from the CA is same as in Section 4.3.1, except that the CA will either grant the request (SUCCESS) or reject it (FAILURE).
この場合、CAからCARはセクション4.3.1と同じですが、CAはリクエスト（成功）または拒否（失敗）を拒否します。
Clients can request a CRL from the SCEP CA, as described in Section 2.7. The OPERATION MUST be set to "PKIOperation".
セクション2.7で説明されているように、クライアントはSCEP CAからCRLを要求できます。操作は「PKIOperation」に設定する必要があります。
The CRL is sent back to the client in a CertRep (Section 3.3.2) message. The information portion of this message is a degenerate certificates-only SignedData (Section 3.4) that contains only the most recent CRL in the crls field of the SignedData.
CRLはCERTREP（セクション3.3.2）メッセージでクライアントに返送されます。このメッセージの情報部分は、SignedDataのCRLSフィールドに最新のCRLのみを含む縮退証明書のみのSignedData（セクション3.4）です。
When a CA certificate is about to expire, clients need to retrieve the CA's next CA certificate (i.e., the rollover certificate). This is done via the GetNextCACert message. The OPERATION MUST be set to "GetNextCACert". There is no request data associated with this message.
CA証明書が期限切れになっている場合、クライアントはCAの次のCA証明書（すなわち、ロールオーバー証明書）を取得する必要があります。これはGetNextCacertメッセージを介して行われます。操作は "getNextCacert"に設定する必要があります。このメッセージに関連付けられている要求データはありません。
The response consists of a SignedData CMS message, signed by the current CA signing key. Clients MUST validate the signature on the message before trusting any of its contents. The response will have a Content-Type of "application/x-x509-next-ca-cert".
応答は、現在のCA署名キーによって署名されたSignedData CMSメッセージで構成されています。クライアントは、その内容を信頼する前にメッセージの署名を検証する必要があります。応答には、 "application / x-x509-next-ca-cert"のコンテンツタイプがあります。
"Content-Type: application/x-x509-next-ca-cert"
"content-type：application / x-x509-next-ca-cert"
<binary CMS>
<バイナリCMS>
The content of the SignedData message is a degenerate certificates-only SignedData message (Section 3.4) containing the new CA certificate(s) to be used when the current CA certificate expires.
SignedDataメッセージの内容は、現在のCA証明書が期限切れになったときに使用される新しいCA証明書を含む縮退証明書専用SignedDataメッセージ（セクション3.4）です。
The following section gives several examples of client-to-CA transactions. Client actions are indicated in the left column, CA actions are indicated in the right column, and the transactionID is given in parentheses. For ease of reading, small integer values have been used; in practice, full transaction IDs would be used. The first transaction, for example, would read like this:
次のセクションでは、Client-To-CAトランザクションの例をいくつか示します。クライアントアクションは左側の列に示され、CAアクションは右側の列に表示され、TransactionIDは括弧内に表示されます。読みやすくするために、小さな整数値が使用されています。実際には、完全なトランザクションIDが使用されます。たとえば、最初のトランザクションは次のように読みます。
| Client Sends PKCSReq message with transactionID 1 to the CA. The
| CA signs the certificate and constructs a CertRep Message
| containing the signed certificate with a transaction ID 1. The
| client receives the message and installs the certificate locally.
PKCSReq (1) ----------> CA issues certificate
<---------- CertRep (1) SUCCESS
Client installs certificate
Figure 7: Successful Enrolment Case: Automatic Processing
図7：登録の成功事件：自動処理
PKCSReq (2) ----------> Cert request goes into queue
<---------- CertRep (2) PENDING
CertPoll (2) ----------> Still pending
<---------- CertRep (2) PENDING
CertPoll (2) ----------> CA issues certificate
<---------- CertRep (2) SUCCESS
Client installs certificate
Figure 8: Successful Enrolment Case: Manual Authentication Required
図8：登録の成功事件：手動認証が必要
GetNextCACert ---------->
<---------- New CA certificate
PKCSReq* ----------> CA issues certificate with
new key
<---------- CertRep SUCCESS
Client stores certificate
for installation when
existing certificate expires.
Figure 9: CA Certificate Rollover Case
図9：CA証明書のロールオーバーケース
* Enveloped for the new CA certificate. The CA will use the envelope to determine which key to use to issue the client certificate.
* 新しいCA証明書に包まれた。CAはエンベロープを使用して、クライアント証明書を発行するために使用するキーを決定します。
In the case of polled transactions that aren't completed automatically, there are two potential options for dealing with a transaction that's interrupted due to network or software/hardware issues. The first is for the client to preserve its transaction state and resume the CertPoll polling when normal service is restored. The second is for the client to begin a new transaction by sending a new PKCSReq/RenewalReq, rather than continuing the previous CertPoll. Both options have their own advantages and disadvantages.
自動的に完了していないポーリングされたトランザクションの場合、ネットワークまたはソフトウェア/ハードウェアの問題のために中断されたトランザクションに対処するための2つの潜在的なオプションがあります。1つ目は、クライアントがトランザクション状態を保持し、通常のサービスが復元されたときにCertPollポーリングを再開します。2つ目は、前のCERTPOLLを継続するのではなく、新しいPKCSREQ / ReneWalReqを送信することによって、クライアントが新しいトランザクションを開始することです。どちらの選択肢も独自の利点と短所を持っています。
The CertPoll continuation requires that the client maintain its transaction state for the time when it resumes polling. This is relatively simple if the problem is a brief network outage, but less simple when the problem is a client crash and restart. In addition, the CA may treat a lost network connection as the end of a transaction, so that a new connection followed by a CertPoll will be treated as an error.
CertPollの継続では、クライアントがポーリングを再開したときのトランザクション状態を維持する必要があります。問題が短いネットワークの停止である場合、これは比較的単純ですが、問題がクライアントのクラッシュして再起動したときに単純ではありません。さらに、CAは、失われたネットワーク接続をトランザクションの終わりとして扱うことができ、その後、CertPollが続く新しい接続がエラーとして扱われます。
The PKCSReq/RenewalReq continuation doesn't require any state to be maintained, since it's a new transaction. However, it may cause problems on the CA side if the certificate was successfully issued but the client never received it, since the resumed transaction attempt will appear to be a request for a duplicate certificate (see Section 7.4 for more on why this is a problem). In this case, the CA may refuse the transaction or require manual intervention to remove/ revoke the previous certificate before the client can request another one.
PKCSREQ / ReneWalreq継続は、新しいトランザクションであるため、維持されるべき状態を必要としません。ただし、証明書が正常に発行された場合はCA Sideで問題が発生する可能性がありますが、再開されたトランザクションの試行は重複証明書の要求であるように見えます（これが問題である理由については、セクション7.4を参照）。）。この場合、CAはトランザクションを拒否するか、またはクライアントが別の証明書を要求できる前に前の証明書を削除/取り消すために手動の介入を必要とする可能性があります。
Since the new-transaction resume is more robust in the presence of errors and doesn't require special-case handling by either the client or CA, clients SHOULD use the new-transaction option in preference to the resumed-CertPoll option to recover from errors.
新規トランザクションの再開はエラーが発生し、クライアントまたはCAのいずれかによる特別な場合の処理を必要としないため、クライアントは再開から回復するためにreplased-certpollオプションを好み、新しいトランザクションオプションを使用する必要があります。。
Resync Case 1: Client resyncs via new PKCSReq (recommended):
Resyncケース1：新しいPKCSREQを介してクライアント再同期（推奨）：
PKCSReq (3) ----------> Cert request goes into queue
<---------- CertRep (3) PENDING
CertPoll (3) ----------> Still pending
X-------- CertRep(3) PENDING
(Network outage)
(Client reconnects)
PKCSReq (4) ---------->
<---------- CertRep (4) PENDING
etc...
Figure 10: Resync Case 1
図10：Resyncケース1
Resync Case 2: Client resyncs via resumed CertPoll after a network outage (not recommended; use PKCSReq to resync):
Resyncケース2：ネットワークの停止後の再開されたCERTPOLLを介したクライアントResyncs（推奨されません。PKCSREQをRESYNCに使用）：
PKCSReq (5) ----------> Cert request goes into queue
<---------- CertRep (5) PENDING
CertPoll (5) ----------> Still pending
X-------- CertRep(5) PENDING
(Network outage)
(Client reconnects)
CertPoll (5) ----------> CA issues certificate
<---------- CertRep (5) SUCCESS
Client installs certificate
Figure 11: Resync Case 2
図11：Resyncケース2
Resync Case 3: Special-case variation of Case 2 where the CertRep SUCCESS rather than the CertRep PENDING is lost (recommended):
Resyncケース3：CERTREP保留でむしろCERTREPの成功が失われた場合のケース2の特殊な場合のバリエーション（推奨）：
PKCSReq (6) ----------> Cert request goes into queue
<---------- CertRep (6) PENDING
CertPoll (6) ----------> Still pending
<---------- CertRep (6) PENDING
CertPoll (6) ----------> CA issues certificate
X-------- CertRep(6) SUCCESS
(Network outage)
(Client reconnects)
PKCSReq (7) ----------> There is already a valid
certificate with this
Distinguished Name (DN).
<---------- CertRep (7) FAILURE
Admin revokes certificate
PKCSReq (8) ----------> CA issues new certificate
<---------- CertRep (8) SUCCESS
Client installs certificate
Figure 12: Resync Case 3
図12：Resyncケース3
Resync Case 4: Special-case variation of Case 1 where the CertRep SUCCESS rather than the CertRep PENDING is lost (not recommended; use PKCSReq to resync):
Resyncケース4：CERTREP保留ではなくCERTREPが成功した場合のケース1の特殊ケースの変動（推奨されません。PKCSREQを使用してください）：
PKCSReq (9) ----------> Cert request goes into queue
<---------- CertRep (9) PENDING
CertPoll (9) ----------> Still pending
<---------- CertRep (9) PENDING
CertPoll (9) ----------> CA issues certificate
X-------- CertRep(9) SIGNED CERT
(Network outage)
(Client reconnects)
CertPoll (9) ----------> Certificate already issued
<---------- CertRep (9) SUCCESS
Client installs certificate
Figure 13: Resync Case 4
図13：Resyncケース4
As these examples indicate, resumption from an error via a resumed CertPoll is tricky due to the state that needs to be held by both the client and/or the CA. A PKCSReq/RenewalReq resume is the easiest to implement, since it's stateless and is identical for both polled and nonpolled transactions, whereas a CertPoll resume treats the two differently. (A nonpolled transaction is resumed with a PKCSReq/ RenewalReq; a polled transaction is resumed with a CertPoll.) For this reason, error recovery SHOULD be handled via a new PKCSReq rather than a resumed CertPoll.
これらの例は、再開されたCERTPOLLを介してエラーからの再開は、クライアントおよび/またはCAの両方によって保持される必要がある状態のためにはいです。PKCSREQ / RenewalReq Resumeは、ステートレスであり、ポーリングされていないトランザクションと非公式の両方のトランザクションには同じであるため、実装が最も簡単ですが、CertPoll Resumeは2つを異なる方法で扱います。（非公式のトランザクションはPKCSREQ / ReneWalReqで再開されます。ポーリングされたトランザクションはCERTPOLLで再開されます。）この理由のために、エラー回復は再開されたCERTPOLLではなく新しいPKCSREQを介して処理されるべきです。
An object identifier for an arc to assign SCEP Attribute Identifiers has been assigned in the "SMI Security for PKIX" registry (1.3.6.1.5.5.7). This object identifer, Simple Certificate Enrollment Protocol Attributes, is denoted as id-scep:
SCEP属性識別子を割り当てるためのARCのオブジェクト識別子は、「SMIセキュリティfor PCIX」レジストリ（1.3.6.1.5.5.7）に割り当てられています。このオブジェクト識別子、単純な証明書登録プロトコル属性は、ID-SCEPとして表されます。
id-scep OBJECT IDENTIFIER ::= { id-pkix 24 }
IANA created the "SMI Security for SCEP Attribute Identifiers" registry (1.3.6.1.5.5.7.24) with the following entries with references to this document:
IANAは、このドキュメントへの参照を含む次のエントリを使用して、次のエントリを使用して、「SCEP属性識別子のSMIセキュリティ」レジストリ（1.3.6.1.5.5.7.24）を作成しました。
id-scep-failInfoText OBJECT IDENTIFIER ::= { id-scep 1 }
Entries in the registry are assigned according to the "Specification Required" policy defined in [RFC8126].
レジストリ内のエントリは、[RFC8126]で定義されている「指定必須」ポリシーに従って割り当てられています。
Section 3.2.1.2 describes an "SCEP Message Type" registry, and Section 3.5 describes an "SCEP CA Capabilities" registry; these registries are maintained by IANA and define a number of such code-point identifiers. Entries in the registry are assigned according to the "Specification Required" policy defined in [RFC8126].
セクション3.2.1.2では、「SCEPメッセージタイプ」レジストリ、およびセクション3.5に「SCEP CA機能」レジストリを説明しています。これらのレジストリはIANAによって維持され、そのようなコードポイント識別子の数を定義します。レジストリ内のエントリは、[RFC8126]で定義されている「指定必須」ポリシーに従って割り当てられています。
The "SCEP Message Types" registry has "Value", "Name", "Description", and "Reference" columns. The "Value" entry is a small positive integer; value "0" is reserved.
「SCEPメッセージタイプ」レジストリには、 "value"、 "name"、 "description"、および "参照"列があります。「値」エントリは小さい正の整数です。値 "0"は予約されています。
The "SCEP CA Capabilities" registry has "Keyword", "Description", and "Reference" columns. Although implementations SHOULD use the "SCEP CA Capabilities" registry, SCEP is often employed in situations where this isn't possible. In this case, private-use CA capabilities may be specified using a unique prefix such as an organisation identifier or domain name under the control of the entity that defines the capability. For example, the prefix would be "Example.com-", and the complete capability would be "Example.com-CapabilityName".
「SCEP CA機能」レジストリには、「キーワード」、「説明」、「参照」列があります。実装は "SCEP CA Capabilities"レジストリを使用する必要がありますが、SCEPはこれが不可能な状況で採用されます。この場合、能力を定義するエンティティの制御下にある組織識別子やドメイン名などの固有のプレフィックスを使用して、プライベート使用CA機能を指定できます。たとえば、接頭辞は "example.com-"になり、完全な機能は "example.com-capabilityName"になります。
IANA has registered four media types as defined in this document:
IANAはこの文書で定義されている4つのメディアタイプを登録しました。
* application/x-x509-ca-cert
* アプリケーション/ X-X509-CA-CERT
* application/x-x509-ca-ra-cert
* アプリケーション/ X-X509-CA-RA-CERT
* application/x-x509-next-ca-cert
* アプリケーション/ X-X509-NEXT-CA-CERT
* application/x-pki-message
* アプリケーション/ x-pki-message
Note that these are grandfathered media types registered as per Appendix A of [RFC6838]. Templates for registrations are specified below.
これらは[RFC6838]の付録Aに従って登録されている祖父型メディアタイプです。登録用のテンプレートを以下に示します。
Type name: application
タイプ名：アプリケーション
Subtype name: x-x509-ca-cert
サブタイプ名：X-X509-CA-CERT
Required parameters: none
必要なパラメータ：なし
Optional parameters: none
オプションのパラメータ：なし
Encoding considerations: binary
エンコードに関する考慮事項：バイナリ
Security considerations: This media type contains a certificate; see the Security Considerations section of [RFC5280]. There is no executable content.
セキュリティ上の考慮事項：このメディアタイプには証明書が含まれています。[RFC5280]の[セキュリティ上の考慮事項]セクションを参照してください。実行可能なコンテンツはありません。
Interoperability considerations: This is a grandfathered registration of an alias to application/pkix-cert (basically a single DER-encoded Certification Authority certificate), which is only used in SCEP.
相互運用性の考慮事項：これは、SCEPでのみ使用されているアプリケーション/ PKIX-CERT（基本的には単一のDERエンコードされた認証局証明書）へのエイリアスの祖父登録です。
Published specification: RFC 8894
公開仕様：RFC 8894
Applications that use this media type: SCEP uses this media type when returning a CA certificate.
このメディアタイプを使用するアプリケーション：SCEPはCA証明書を返すときにこのメディアタイプを使用します。
Fragment identifier considerations: N/A
フラグメント識別子の考慮事項：N / A.
Additional information:
追加情報：
Deprecated alias names for this type: N/A
このタイプの廃止予定のエイリアス名：N / A
Magic number(s): none
マジックナンバー：なし
File extension(s): N/A
Macintosh file type code(s): N/A
Person and email address to contact for further information: See the Authors' Addresses section of RFC 8894.
詳細については、連絡先のある人とEメールアドレス：RFC 8894の「作者の住所」セクションを参照してください。
Intended usage: LIMITED USE
意図された用途：限られた使用
Restrictions on usage: SCEP protocol
使用制限：SCEPプロトコル
Author: See the Authors' Addresses section of RFC 8894
著者：RFC 8894の作者の住所セクションを参照してください。
Change controller: IETF
変更コントローラ：IETF.
Provisional registration? No
暫定登録？番号
Type name: application
タイプ名：アプリケーション
Subtype name: x-x509-ca-ra-cert
サブタイプ名：X-X509-CA-RA-CERT
Required parameters: none
必要なパラメータ：なし
Optional parameters: none
オプションのパラメータ：なし
Encoding considerations: binary
エンコードに関する考慮事項：バイナリ
Security considerations: This media type consists of a degenerate certificates-only CMS SignedData message (Section 3.4) containing the certificates, with the intermediate CA certificate(s) as the leaf certificate(s). There is no executable content.
セキュリティ上の考慮事項：このメディアタイプは、リーフ証明書としての中間CA証明書を含む証明書を含む縮退証明書専用CMS SignedDataメッセージ（3.4項）で構成されています。実行可能なコンテンツはありません。
Interoperability considerations: This is a grandfathered registration that is only used in SCEP.
相互運用性の考慮事項：これはSCEPでのみ使用されている祖父登録です。
Published specification: RFC 8894
公開仕様：RFC 8894
Applications that use this media type: SCEP uses this media type when returning CA Certificate Chain Response.
このメディアタイプを使用するアプリケーション：SCEPは、CA証明書チェーンレスポンスを返すときにこのメディアタイプを使用します。
Fragment identifier considerations: N/A
フラグメント識別子の考慮事項：N / A.
Additional information:
追加情報：
Deprecated alias names for this type: N/A
このタイプの廃止予定のエイリアス名：N / A
Magic number(s): none
マジックナンバー：なし
File extension(s): N/A
Macintosh file type code(s): N/A
Person and email address to contact for further information: See the Authors' Addresses section of RFC 8894.
詳細については、連絡先のある人とEメールアドレス：RFC 8894の「作者の住所」セクションを参照してください。
Intended usage: LIMITED USE
意図された用途：限られた使用
Restrictions on usage: SCEP protocol
使用制限：SCEPプロトコル
Author: See the Authors' Addresses section of RFC 8894.
著者：RFC 8894の「作者の住所」セクションを参照してください。
Change controller: IETF
変更コントローラ：IETF.
Provisional registration? no
暫定登録？番号
Type name: application
タイプ名：アプリケーション
Subtype name: x-x509-next-ca-cert
サブタイプ名：X-X509-NEXT-CA-CERT
Required parameters: none
必要なパラメータ：なし
Optional parameters: none
オプションのパラメータ：なし
Encoding considerations: binary
エンコードに関する考慮事項：バイナリ
Security considerations: This media type consists of a SignedData CMS message, signed by the current CA signing key. There is no executable content.
セキュリティ上の考慮事項：このメディアタイプは、現在のCA署名キーによって署名されたSignedData CMSメッセージで構成されています。実行可能なコンテンツはありません。
Interoperability considerations: This is a grandfathered registration that is only used in SCEP.
相互運用性の考慮事項：これはSCEPでのみ使用されている祖父登録です。
Published specification: RFC 8894
公開仕様：RFC 8894
Applications that use this media type: SCEP uses this media type when returning a Get Next CA response.
このメディアタイプを使用するアプリケーション：SCEPは、取得次のCA応答を返すときにこのメディアタイプを使用します。
Fragment identifier considerations: N/A
フラグメント識別子の考慮事項：N / A.
Additional information:
追加情報：
Deprecated alias names for this type: N/A
このタイプの廃止予定のエイリアス名：N / A
Magic number(s): none
マジックナンバー：なし
File extension(s): N/A
Macintosh file type code(s): N/A
Person and email address to contact for further information: See the Authors' Addresses section of RFC 8894.
詳細については、連絡先のある人とEメールアドレス：RFC 8894の「作者の住所」セクションを参照してください。
Intended usage: LIMITED USE
意図された用途：限られた使用
Restrictions on usage: SCEP protocol
使用制限：SCEPプロトコル
Author: See the Authors' Addresses section of RFC 8894.
著者：RFC 8894の「作者の住所」セクションを参照してください。
Change controller: IETF
変更コントローラ：IETF.
Provisional registration? no
暫定登録？番号
Type name: application
タイプ名：アプリケーション
Subtype name: x-pki-message
サブタイプ名：X-PKI-MESSAGE.
Required parameters: none
必要なパラメータ：なし
Optional parameters: none
オプションのパラメータ：なし
Encoding considerations: binary
エンコードに関する考慮事項：バイナリ
Security considerations: This media type consists of a degenerate certificates-only CMS SignedData message. There is no executable content.
セキュリティ上の考慮事項：このメディアタイプは、縮退証明書のみのCMS SignedDataメッセージで構成されています。実行可能なコンテンツはありません。
Interoperability considerations: This is a grandfathered registration that is only used in SCEP.
相互運用性の考慮事項：これはSCEPでのみ使用されている祖父登録です。
Published specification: RFC 8894
公開仕様：RFC 8894
Applications that use this media type: SCEP uses this media type when returning a Certificate Enrolment/Renewal Response.
このメディアタイプを使用するアプリケーション：SCEPは、証明書登録/更新回答を返すときにこのメディアタイプを使用します。
Fragment identifier considerations: N/A
フラグメント識別子の考慮事項：N / A.
Additional information:
追加情報：
Deprecated alias names for this type: N/A
このタイプの廃止予定のエイリアス名：N / A
Magic number(s): none
マジックナンバー：なし
File extension(s): N/A
Macintosh file type code(s): N/A
Person and email address to contact for further information: See the Authors' Addresses section of RFC 8894.
詳細については、連絡先のある人とEメールアドレス：RFC 8894の「作者の住所」セクションを参照してください。
Intended usage: LIMITED USE
意図された用途：限られた使用
Restrictions on usage: SCEP protocol
使用制限：SCEPプロトコル
Author: See the Authors' Addresses section of RFC 8894.
著者：RFC 8894の「作者の住所」セクションを参照してください。
Change controller: IETF
変更コントローラ：IETF.
Provisional registration? no
暫定登録？番号
The security goal of SCEP is that no adversary can subvert the public key/identity binding from that intended. An adversary is any entity other than the client and the CA participating in the protocol.
SCEPのセキュリティ目標は、敵対者がその意図からの公開鍵/身元のバインディングを覆すことができることです。敵対者は、クライアント以外の任意のエンティティと、プロトコルに参加するCAです。
This goal is met through the use of CMS and PKCS #10 encryption and digital signatures using authenticated public keys. The CA's public key is authenticated via out-of-band means such as the checking of the CA fingerprint, and the SCEP client's public key is authenticated through manual or preshared secret authentication.
認証された公開鍵を使用して、CMSおよびPKCS＃10の暗号化およびデジタル署名を使用して、この目標が満たされています。CAの公開鍵は、CA FingerPrintのチェックなどの帯域外の手段を介して認証され、SCEPクライアントの公開鍵は手動または事前共有された秘密認証によって認証されています。
Common key-management considerations such as keeping private keys truly private and using adequate lengths for symmetric and asymmetric keys must be followed in order to maintain the security of this protocol. This is especially true for CA keys which, when compromised, compromise the security of all relying parties.
このプロトコルのセキュリティを維持するためには、秘密鍵を本当にプライベートで適切な長さを使用しているなどの一般的な鍵管理に関する考慮事項を守る必要があります。これはCAキーに特に当てはまりますが、妥協したときにすべての依存関係者の安全性を危うくする。
A CA private key is generally meant for, and usually flagged as, being usable for certificate (and CRL) signing exclusively rather than data signing or encryption. The SCEP protocol, however, uses the CA private key to both sign and optionally encrypt CMS transport messages. This is generally considered undesirable, as it widens the possibility of an implementation weakness and provides an additional location where the private key must be used (and hence is slightly more vulnerable to exposure) and where a side-channel attack might be applied.
CA秘密鍵は一般に、データ署名または暗号化ではなく、証明書（およびCRL）の署名に使用可能であると通常のフラグを立て、通常はフラグを立てています。ただし、SCEPプロトコルはCA PRICESTキーを使用して両方の符号を使用し、オプションでCMSトランスポートメッセージを暗号化します。これは一般に、実装の弱さの可能性を広げ、秘密鍵を使用しなければならない追加の場所を提供しているため、望ましくないと考えられています（したがって、露出に対してわずかに脆いです）、およびサイドチャネル攻撃が適用される場合があります。
The security measures that should be applied to the challengePassword shared secret depend on the manner in which SCEP is employed. In the simplest case, with SCEP used to provision devices with certificates in the manufacturing facility, the physical security of the facility may be enough to protect the certificate issue process with no additional measures explicitly required. In general, though, the security of the issue process depends on the security employed around the use of the challengePassword shared secret. While it's not possible to enumerate every situation in which SCEP may be utilised, the following security measures should be considered.
チャレンジパスワード共有秘密に適用されるべきセキュリティ対策は、SCEPが採用されている方法によって異なります。最も簡単な場合、SCEPは製造施設内の証明書を持つデバイスのプロビジョニングに使用されている場合、施設の物理的セキュリティは、証明書発行プロセスを明示的に必要としないものではなく、証明書発行プロセスを保護するのに十分な場合があります。しかし一般的に、問題プロセスのセキュリティは、ChallengePassword共有秘密の使用に関するセキュリティによって異なります。SCEPを利用することができるあらゆる状況を列挙することは不可能であるが、以下のセキュリティ対策を考慮する必要があります。
* The challengePassword, despite its name, shouldn't be a conventional password but a high-entropy shared-secret authentication string. Using the base64 encoding of a keying value generated or exchanged as part of standard device authentication protocols like the Extensible Authentication Protocol (EAP) or DNP3 Secure Authentication (DNP3-SA) makes for a good challengePassword. The use of high-entropy shared secrets is particularly important when the PasswordRecipientInfo option is used to encrypt SCEP messages; see Section 3.1. * If feasible, the challengePassword should be a one-time value used to authenticate the issue of a single certificate (subsequent certificate requests will be authenticated by being signed with the initial certificate). If the challengePassword is single use, then the arrival of subsequent requests using the same challengePassword can then be used to indicate a security breach. * The lifetime of a challengePassword can be limited, so that it can be used during initial device provisioning but will have expired at a later date if an attacker manages to compromise the challengePassword value -- for example, by compromising the device that it's stored in. * The CA should take appropriate measures to protect the challengePassword. Examples of possible measures include: physical security measures; storing it as a salted iterated hash or equivalent memory-hard function; storing it as a keyed MAC value if it's not being used for encryption; and storing it in encrypted form if it is being used for encryption.
* その名前にもかかわらず、ChallengePasswordは、従来のパスワードではなく、高エントロピー共有秘密認証文字列ではありません。 Extensible Authentication Protocol（EAP）またはDNP3 Secure Authentication（DNP3-SA）のような標準デバイス認証プロトコル（DNP3-SA）の一部として生成または交換されたキーイング値の符号化を使用すると、優れたChalllerPasswordが作成されます。高エントロピー共有秘密の使用は、PasswordRecipientInfoオプションを使用してSCEPメッセージを暗号化するときに特に重要です。セクション3.1を参照してください。 *実行可能であれば、ChallengePasswordは単一の証明書の問題を認証するために使用される1回限りの値にする必要があります（後続の証明書要求は、最初の証明書に署名されて認証されます）。チャレンジパスワードが単独で使用されている場合、同じChargleASPASSWORDを使用して後続の要求の到着は、セキュリティ違反を示すために使用できます。 * ChallengePasswordの有効期間は制限される可能性があるため、初期デバイスプロビジョニング中に使用できますが、攻撃者がChallengePasswordの値を侵害することを管理している場合は後の日付に期限切れになります。たとえば、それが保存されているデバイスを犠牲にすることによって。* CAは、ChallengePasswordを保護するための適切な措置を講じるべきです。考えられる措置の例には、物理的なセキュリティ対策が含まれます。塩漬けの反復ハッシュまたは同等のメモリハード関数として保管する。暗号化に使用されていない場合は、キー付きMAC値として保存します。暗号化に使用されている場合は暗号化された形式で保存してください。
SCEP provides no confirmation that the issued certificate was successfully received and processed by the client. This means that if the CertRep message is lost or can't be processed by the client, then the CA will consider the certificate successfully issued while the client won't. If this situation is of concern, then the correct issuance of the certificate will need to be verified by out-of-band means, for example, through the client sending a message signed by the newly issued certificate to the CA. This also provides the proof of possession that's not present in the case of a renewal operation; see Section 7.6.
SCEPは、発行された証明書がクライアントによって正常に受信され処理されたことを確認しません。つまり、CERTREPメッセージが失われた場合、またはクライアントによって処理できない場合、CAはクライアントがしない間に証明書が正常に発行されます。この状況が懸念されている場合、証明書の正しい発行は、新たに発行された証明書によって署名されたメッセージをCAに送信するクライアントを介して帯域外の手段によって検証される必要があります。これはまた、更新業務の場合には存在しない所有の証明を提供する。7.6項を参照してください。
The GetCACaps response is not authenticated by the CA. This allows an attacker to perform downgrade attacks on the cryptographic capabilities of the client/CA exchange. In particular, if the server were to support MD5 and single DES, then an in-path attacker could trivially roll back the encryption to use these insecure algorithms. By taking advantage of the presence of large amounts of static known plaintext in the SCEP messages, as of 2017, a DES rainbow table attack can recover most encryption keys in under a minute, and MD5 chosen-prefix collisions can be calculated for a few tens of cents of computing time using tools like HashClash. It is for this reason that this specification makes single DES and MD5 a MUST NOT feature. Note that all known servers support at least triple DES and SHA-1 (regardless of whether "DES3" and "SHA-1" are indicated in GetCACaps), so there should never be a reason to fall all the way back to single DES and MD5.
GetCacapsの応答はCAによって認証されていません。これにより、攻撃者はクライアント/ CA Exchangeの暗号化機能に対するダウングレード攻撃を実行できます。特に、サーバーがMD5と単一のDESをサポートすることになっている場合、In-PATH攻撃者はこれらの不安定なアルゴリズムを使用するために暗号化を簡単にロールバックすることができます。SCEPメッセージで大量の静的既知の平文の存在を利用することで、2017年の時点でDES Rainbow Table Attackが1分以内にほとんどの暗号化キーを回復する可能性があり、MD5選択されたプレフィックスの衝突を数十秒間計算できます。HashClashのようなツールを使用したコンピューティング時間のセントの。この仕様が単一のDESとMD5 Aを機能してはいけませんでした。すべての既知のサーバーが少なくともトリプルDESとSHA-1をサポートしています（「DE3」と「SHA-1」がGetCacapsに表示されているかどうかにかかわらず）。MD5。
One simple countermeasure to a GetCACaps downgrade attack is for clients that are operating in an environment where on-path attacks are possible and that expect the "SCEPStandard" capability to be indicated by the CA but don't see it in the GetCACaps response to treat its absence as a security issue, and either discontinue the exchange or continue as if "SCEPStandard" had been returned. This requires a certain trade-off between compatibility with old servers and security against active attacks.
GetCacaps Downgrade Attackへの簡単な対策は、オンパス攻撃が可能である環境で動作しているクライアントのためのものであり、CAによって「ScePStandard」機能を扱うことを期待していますが、治療へのGetCacaps対応でそれを見ないでください。セキュリティ上の問題として、およびExchangeを中止するか、または「SCEPStandard」が返されたかのように継続してください。これには、古いサーバーとの互換性とアクティブな攻撃に対するセキュリティの間の特定のトレードオフが必要です。
Renewal operations (but not standard certificate-issue operations) are processed via a previously issued certificate and its associated private key, not the key in the PKCS #10 request. This means that a client no longer demonstrates proof of possession (PoP) of the private key corresponding to the public key in the PKCS #10 request. It is therefore possible for a client to recertify an existing key used by a third party, so that two or more certificates exist for the same key. By switching out the certificate in a signature, an attacker can appear to have a piece of data signed by their certificate rather than the original signer's certificate. This, and other, attacks are described in S/MIME ESS [RFC2634].
更新操作（標準の証明書発行操作ではない）は、以前に発行された証明書とそれに関連付けられた秘密鍵を介して処理され、PKCS＃10の要求の鍵は鍵ではありません。つまり、クライアントは、PKCS＃10リクエストの公開鍵に対応する秘密鍵の所有者（POP）の証明をもはや証明していないことを意味します。したがって、クライアントが第三者によって使用される既存の鍵を再認証することが可能であるので、同じキーに対して2つ以上の証明書が存在する。証明書を署名に切り替えることによって、攻撃者は元の署名者の証明書ではなく証明書によって署名されたデータを持っているように見えることがあります。これ以上、攻撃はS / MIME ESS [RFC2634]に記載されています。
Avoiding these types of attacks requires situation-specific measures. For example, CMS/SMIME implementations may use the ESSCertID attribute from S/MIME ESS [RFC2634] or its successor, S/MIME ESSv2 [RFC5035], to unambiguously identify the signing certificate. However, since other mechanisms and protocols that the certificates will be used with typically don't defend against this problem, it's unclear whether this is an actual issue with SCEP.
これらの種類の攻撃を回避するには、状況固有の措置が必要です。たとえば、CMS / SMIME実装は、S / MIME ESS [RFC2634]またはその後継者S / MIME ESSV2 [RFC5035]からESSCertID属性を使用して、署名証明書を明確に識別することができます。ただし、証明書がこの問題に対して守らないという証明書が使用されるその他のメカニズムやプロトコルは、これがSCEPの実際の問題であるかどうかは不明です。
SCEP messages are signed with certificates that may contain identifying information. If these are sent over the public Internet and real identity information (rather than placeholder values or arbitrary device IDs) is included in the signing certificate data, an attacker may be able to monitor the identities of the entities submitting the certificate requests. If this is an issue, then [RFC7258] should be consulted for guidance.
SCEPメッセージは、情報を識別する可能性がある証明書で署名されています。これらがパブリックインターネットを介して（プレースホルダ値または任意のデバイスID）を介して送信されている場合、署名証明書データに含まれている場合、攻撃者は証明書要求を送信するエンティティの身元を監視できる可能性があります。これが問題である場合は、[RFC7258]はガイダンスのために相談されるべきです。
Some of the SCEP exchanges use unnecessary signing and encryption operations. In particular, the GetCert and GetCRL exchanges are encrypted and signed in both directions. The information requested is public, and thus encrypting the requests is of questionable value. In addition, CRLs and certificates sent in responses are already signed by the CA and can be verified by the recipient without requiring additional signing and encryption. More lightweight means of retrieving certificates and CRLs such as HTTP certificate-store access [RFC4387] and LDAP are recommended for this reason.
SCEP交換の中には、不要な署名および暗号化操作を使用しています。特に、GetCertやGetCrLの交換は暗号化され、両方向に署名されています。要求された情報はpublicであり、したがって要求を暗号化することは疑わしい値です。さらに、応答で送信されたCRLと証明書はすでにCAによって署名されており、追加の署名と暗号化を必要とせずに受信者によって検証できます。この理由から、[RFC4387]とLDAPなどの証明書とCRLを検索するより軽量な手段を推奨します。
The majority of the large number of devices that use SCEP today default to SHA-1, with many supporting only that hash algorithm with no ability to upgrade to a newer one. SHA-1 is no longer regarded as secure in all situations, but as used in SCEP, it's still safe. There are three reasons for this. The first is that attacking SCEP would require creating a fully general SHA-1 collision in close to real time alongside breaking AES (more specifically, it would require creating a fully general SHA-1 collision for the PKCS #10 request, breaking the AES encryption around the PKCS #10 request, and then creating a second SHA-1 collision for the signature on the encrypted data), which won't be feasible for a long time.
今日SCEPを使用する多数のデバイスの大部分はデフォルトでSHA-1になり、そのHASHアルゴリズムのみが新しいものにアップグレードすることはできません。SHA-1は、すべての状況で安全ではなく、SCEPで使用されているように、まだ安全です。これには3つの理由があります。最初のものは、SCEPを攻撃することが、最新のAESと並んでリアルタイムの近くで完全に一般的なSHA-1衝突を作成する必要があることです（より具体的には、PKCS＃10の要求に完全に一般的なSHA-1衝突を作成する必要があり、AES暗号化を破ることが必要になるでしょう。PKCS＃10の要求を要求してから、暗号化データの署名のための2番目のSHA-1衝突を作成します）。
The second reason is that the signature over the message -- in other words, the SHA-1 hash that isn't protected by encryption -- doesn't serve any critical cryptographic purpose: The PKCS #10 data itself is authenticated through its own signature, protected by encryption, and the overall request is authorised by the (encrypted) shared secret. The sole exception to this will be the small number of implementations that support the Renewal operation, which may be authorised purely through a signature, but presumably any implementation recent enough to support Renewal also supports SHA-2. Any legacy implementation that supports the historic core SCEP protocol would not be affected.
2番目の理由は、メッセージの上のシグネチャが暗号化によって保護されていないSHA-1ハッシュが重要な暗号的な目的ではありません.PKCS＃10データ自体はそれ自身で認証されています。暗号化によって保護されたシグネチャ、および全体的な要求は（暗号化された）共有秘密によって許可されています。これに対する唯一の例外は、更新操作をサポートする少数の実装であり、これは純粋に署名を通して承認されるかもしれませんが、提案されたすべての実装はSHA-2をサポートしています。歴史的なコアSCEPプロトコルをサポートする従来の実装は影響を受けません。
The third reason is that SCEP uses the same key for encryption and signing, so that even if an attacker were able to capture an outgoing renewal request that didn't include a shared secret (in other words, one that was only authorised through a signature), break the AES encryption, forge the SHA-1 hash in real time, and forward the forged request to the CA, they couldn't decrypt the returned certificate, which is protected with the same key that was used to generate the signature. While Section 7.8 points out that SCEP uses unnecessary cryptography in places, the additional level of security provided by the extra crypto makes it immune to any issues with SHA-1.
3番目の理由は、SCEPが暗号化と署名のために同じキーを使用するため、攻撃者が共有秘密を含まなかった発信更新要求をキャプチャできたとしても（言い換えれば、署名を通じて承認されたもの）、AES暗号化を破り、SHA-1ハッシュをリアルタイムで偽造し、CAへの偽リクエストを転送し、返された証明書を復号化できませんでした。これは署名の生成に使用された同じキーで保護されています。セクション7.8は、SCEPが場所で不要な暗号化を使用していることを指摘しているが、追加の暗号によって提供されるセキュリティのさらなるレベルは、それをSHA-1の問題に耐えます。
This doesn't mean that SCEP implementations should continue to use SHA-1 in perpetuity, merely that there's no need for a panicked switch to SHA-2.
これは、SCEPの実装が永続的なSHA-1を使用し続けるべきであるというわけではありません。
SCEP is an encrypted, authenticated certificate enrollment protocol that uses HTTP as a simple transport mechanism. Since SCEP messages are already cryptographically secured, it does not require transport layer security. Where HTTPS is elected, a performance hit may result from the TLS overhead, operational problems may result due to the more complex configuration, and potential security vulnerability may result due to the addition of an entire TLS protocol stack alongside the basic SCEP protocol.
SCEPは、単純なトランスポートメカニズムとしてHTTPを使用する暗号化認証された証明書登録プロトコルです。SCEPメッセージはすでに暗号的に保護されているので、トランスポート層のセキュリティは必要ありません。HTTPSが選択された場合、パフォーマンスヒットはTLSオーバーヘッドから生じる可能性があり、より複雑な構成のために動作上の問題が発生し、基本的なSCEPプロトコルと共にTLSプロトコルスタック全体が追加されたために発生する可能性があります。
In particular, experience has shown that the issue of configuring certificates, CAs, and trust for both TLS and SCEP often leads to interoperability problems because different certificates and trust models are used in each. Use of HTTPS to authenticate the server does not enable omission of the ChallengePassword or similar authenticator in the SCEP message on the assumption that using HTTPS instead of HTTP will somehow make this insecure usage secure again. HTTPS is not soy sauce for security and is unnecessary for SCEP, which uses cryptographically secured messages and does not require transport layer security.
特に、TLSとSCEPの両方に証明書、CAS、および信頼を構成するという問題は、さまざまな証明書と信頼モデルがそれぞれ使用されるため、相互運用性の問題を引き起こすことがわかっています。HTTPSを認証するためのHTTPSの使用は、HTTPの代わりにHTTPSを使用することを確認すると、SCEPメッセージ内のChallengePasswordまたは類似のオーセンティケータを省略しません。HTTPSはセキュリティのための醤油ではなく、暗号的に保護されたメッセージを使用し、トランスポート層のセキュリティを必要としないSCEPには不要です。
[AES] Technology, U. N. I. O. S. A., "The Advanced Encryption Standard (AES)", FIPS 197, DOI 10.6028/NIST.FIPS.197, November 2001, <https://doi.org/10.6028/NIST.FIPS.197>.
[AES] Technology、U. I.米国、「Advanced Encryption Standard（AES）」、FIPS 197、DOI 10.6028 / Nist.fips.197、2001年11月、<https://doi.org/10.6028/nist.fips.197>。
[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>。
[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>。
[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>。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <https://www.rfc-editor.org/info/rfc3986>.
[RFC3986] Berners-Lee、T.、Field、R.、およびL.Masinter、「Uniform Resource Identifier（URI）：汎用構文」、STD 66、RFC 3986、DOI 10.17487 / RFC3986、2005年1月、<https：//www.rfc-editor.org/info/rfc3986>。
[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>。
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>.
[RFC5234] Crocker、D.、ED。2008年1月、<https://www.rfc-editor.org/info/rfc-editor.org/info/rfc- editor.org/info/rfc523,2008、<https://www.rfc-editor.org/info/rfc- editor.org/info/rfc- editor.org/info/rfc- editor.org/info/rfc- editor.org/info/rfc- editor.org/info/rfc5234>。
[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, <https://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月、<https://www.rfc-editor.org/info/rfc5280>。
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, DOI 10.17487/RFC5652, September 2009, <https://www.rfc-editor.org/info/rfc5652>.
[RFC5652] Housley、R.、 "Cryptographic Message Syntax（CMS）"、STD 70、RFC 5652、DOI 10.17487 / RFC5652、2009年9月、<https：//www.rfc-editor.org/info/rfc5652>。
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, <https://www.rfc-editor.org/info/rfc6838>.
[RFC6838] Freed、N.、Klensin、J.、およびT.Hansen、「メディアタイプの仕様および登録手順」、BCP 13、RFC 6838、DOI 10.17487 / RFC6838、2013年1月、<https：///www.rfc-editor.org/info/rfc6838>。
[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>。
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2014, <https://www.rfc-editor.org/info/rfc7258>.
[RFC7258] Farrell、S.およびH.Tschofenig、「Pervasive Monitoringは攻撃」、BCP 188、RFC 7258、DOI 10.17487 / RFC7258、2014年5月、<https：//www.rfc-editor.org/info/rfc7258>。
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]綿、M.、Leiba、B.およびT.Narten、「RFCSのIANAに関する考察のためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487 / RFC8126、2017年6月、<HTTPS：// WWW.rfc-editor.org / info / rfc8126>。
[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>。
[SHA2] Technology, U. N. I. O. S. A., "Secure Hash Standard (SHS)", FIPS 180-3, October 2008.
[SHA2]テクノロジー、U。米国東部A.、「セキュアハッシュスタンダード（SHS）」、FIPS 180-3、2008年10月。
[HTTP] Nottingham, M., "Building Protocols with HTTP", Work in Progress, Internet-Draft, draft-ietf-httpbis-bcp56bis-09, November 1, 2019, <https://tools.ietf.org/html/draft-ietf-httpbis-bcp56bis-09>.
[HTTP]ノッティンガム、M.、「HTTPを使用したプロトコルの構築」、進行中の作業、インターネットドラフト、ドラフト - IETF-HTTPBIS-BCP56BIS-09、2019年11月1日、<https://tools.ietf.org/html/ draft-ietf-httpbis-bcp56bis-09>。
[JSCEP] "A Java implementation of the Simple Certificate Enrolment Protocol", commit 7410332, January 2020, <https://github.com/jscep/jscep>.
[JSCEP]「シンプルな証明書登録プロトコルのJava実装」、COMMIT 7410332、2020年1月、<https：//github.com/jscep/jscep>。
[RFC2634] Hoffman, P., Ed., "Enhanced Security Services for S/MIME", RFC 2634, DOI 10.17487/RFC2634, June 1999, <https://www.rfc-editor.org/info/rfc2634>.
[RFC2634] Hoffman、P.、ED。、「S / MIMEの強化されたセキュリティサービス」、RFC 2634、DOI 10.17487 / RFC2634、1999年6月、<https：//www.rfc-editor.org/info/rfc2634>。
[RFC4387] Gutmann, P., Ed., "Internet X.509 Public Key Infrastructure Operational Protocols: Certificate Store Access via HTTP", RFC 4387, DOI 10.17487/RFC4387, February 2006, <https://www.rfc-editor.org/info/rfc4387>.
[RFC4387] Gutmann、P.、ED。、「Internet X.509公開鍵インフラストラクチャー業務：httpによる証明書ストアアクセス」、RFC 4387、DOI 10.17487 / RFC4387、2006年2月、<https：//www.rfc-編集者.ORG / INFO / RFC4387>。
[RFC5035] Schaad, J., "Enhanced Security Services (ESS) Update: Adding CertID Algorithm Agility", RFC 5035, DOI 10.17487/RFC5035, August 2007, <https://www.rfc-editor.org/info/rfc5035>.
[RFC5035] Schaad、J.、「Enhanced Security Services（ESS）更新：証明書アルゴリズム俊敏性の追加」、RFC 5035、DOI 10.17487 / RFC5035、2007年8月、<https：//www.rfc-editor.org/info/rfc5035>。
[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, <https://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月、<https：//www.rfc-editor.org/info/rfc7296>。
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.
[RFC8446] RESCORLA、E.、「トランスポート層セキュリティ（TLS）プロトコルバージョン1.3」、RFC 8446、DOI 10.17487 / RFC8446、2018年8月、<https：//www.rfc-editor.org/info/rfc8446>。
[RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/ Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification", RFC 8551, DOI 10.17487/RFC8551, April 2019, <https://www.rfc-editor.org/info/rfc8551>.
[RFC8551] Schaad、J.、Ramsdell、B.、およびS。ターナー、「セキュア/多目的インターネットメール拡張（S / MIME /多目的インターネットメール拡張」、RFC 8551、DOI 10.17487 / RFC8551、2019年4月、<https：//www.rfc-editor.org/info/rfc8551>。
This specification has spent over twenty years in the draft stage. Its original goal, provisioning IPsec routers with certificates, has long since changed to general device/embedded system/IoT use. To fit this role, extra features were bolted on in a haphazard manner through the addition of a growing list of appendices and by inserting additional, often conflicting, paragraphs in various locations in the body text. Since existing features were never updated as newer ones were added, the specification accumulated large amounts of historical baggage over time. If OpenPGP was described as "a museum of 1990s crypto", then the SCEP document was its graveyard.
この仕様はドラフト段階で20年以上過ごしました。その元の目標、証明書を持つIPsecルータのプロビジョニングは、一般的なデバイス/組み込みシステム/ IOTの使用に変更されています。この役割を果たすために、追加の機能は、付録の増え続けているリストを追加し、身体のテキストのさまざまな場所に追加の、しばしば矛盾する段落を挿入することによって、haphazardの方法でボルトでボルトを付けました。既存の機能が新しいものが追加されたため更新されなかったので、仕様は大量の歴史的手荷物を経時的に累積しました。OpenPGPが「1990年代暗号の博物館」として説明されている場合、SCEP文書はその墓地でした。
About five years ago, the specification, which even at that point had seen only sporadic reposts of the existing document, was more or less abandoned by its original sponsors. Due to its widespread use in large segments of the industry, the specification was rebooted in 2015, cleaning up fifteen years' worth of accumulated cruft, fixing errors, clarifying ambiguities, and bringing the algorithms and standards used into the current century (prior to the update, the de facto lowest-common-denominator algorithms used for interoperability were the insecure forty-year-old single DES and broken MD5 hash algorithms).
5年前、その時点でさえ既存の文書の散発的な再投稿のみを見たことがある仕様は、元のスポンサーによって多かれ少なかれ放棄されました。業界の大規模なセグメントでの広範な使用のために、2015年に仕様は再起動され、15年の価値の累積されたCRUFTの累積、エラーの修正、明らかにされ、そして現在世紀に使用されているアルゴリズムと標準の導入更新された、相互運用性に使用される最低共通分母のアルゴリズムは、不安定な単一のSINGLESおよび破損MD5ハッシュアルゴリズムであった。
Note that although the text of the current specification has changed significantly due to the consolidation of features and appendices into the main document, the protocol that it describes is identical on the wire to the original (with the unavoidable exception of the switch from single DES and MD5 to AES and SHA-2). The only two changes introduced, the "SCEPStandard" indicator in GetCACaps and the failInfoText attribute, are both optional values and would be ignored by older implementations that don't support them, or can be omitted from messages if they are found to cause problems.
現在の仕様のテキストは、機能や付録の主な文書への付録の統合により大幅に変化しましたが、それが記述されているプロトコルはワイヤーと元のオリジナルの（単一のDESからの切り替えの不可避的な例外を持ちます）MD5からAESとSHA-2）。GetCacapsの "ScePStandard"インジケータとFailInfotext属性はどちらもオプションの値で、それらをサポートしていない古い実装によって無視されます。または、問題を引き起こす場合はメッセージから省略できます。
Other changes include:
その他の変更には以下が含まれます。
* Resolved contradictions in the text -- for example, a requirement given as a MUST in one paragraph and a SHOULD in the next, a MUST NOT in one paragraph and a MAY a few paragraphs later, a SHOULD NOT contradicted later by a MAY, and so on.
* テキストの矛盾を解決しました - 例えば、1つの段落に必要な要件と次の段落に与えられた要件、A 1段落にはいずれではなく、後で1段落が5月に矛盾していないはずであり、とても続いてください。
* Merged several later fragmentary addenda placed in appendices (for example, the handling of certificate renewal) with the body of the text.
* テキストの本文とともに、付録（たとえば、証明書更新の処理）に置かれたいくつかの後の断片的addendaをマージしました。
* Merged the "SCEP Transactions" and "SCEP Transport" sections, since the latter mostly duplicated (with occasional inconsistencies) the former.
* 後者が主に重複しているため、「SCEPトランザクション」および「SCEPトランスポート」をマージしました。
* Updated the algorithms to ones dating from at least this century.
* 少なくとも今世紀からデートするものにアルゴリズムを更新しました。
* Did the same for normative references to other standards.
* 他の標準への規範的な参照についても同じことをしました。
* Updated the text to use consistent terminology for the client and CA rather than a mixture of client, requester, requesting system, end entity, server, certificate authority, certification authority, and CA.
* クライアント、リクエスタ、システム、エンドエンティティ、サーバ、認証局、認証局、認証局、およびCAの混合品ではなく、クライアントとCAの一貫した用語を使用するテキストを更新しました。
* Corrected incorrect references to other standards, e.g., IssuerAndSerial -> IssuerAndSerialNumber.
* 他の規格、例えばISSUERANDSERIAL - > ISSUERANDSERIALNUMBERへの誤った参照を修正しました。
* Corrected errors such as a statement that when both signature and encryption certificates existed, the signature certificate was used for encryption.
* 署名証明書と暗号化証明書の両方が存在している場合、署名証明書が暗号化に使用されたというステートメントなどの修正エラー。
* Condensed redundant discussions of the same topic spread across multiple sections into a single location. For example, the description of intermediate CA handling previously existed in three different locations, with slightly different requirements in each one.
* 複数のセクションにわたって単一の場所に広がるのと同じトピックの縮退冗長ディスカッション。たとえば、以前に3つの異なる場所に存在し、それぞれがわずかに異なる要件を持ちます。
* Added a description of how pkiMessages were processed, which was never made explicit in the original specification. This led to creative interpretations that had security problems but were employed anyway due to the lack of specific guidance on what to do.
* PKimessagesがどのように処理されたかについての説明を追加しました。これは元の仕様に明示的にされませんでした。これはセキュリティ上の問題を抱えていたがとにかく雇用された創造的な解釈につながりました。
* Relaxed some requirements that didn't serve any obvious purpose and that major implementations didn't seem to be enforcing. For example, the requirement that the self-signed certificate used with a request MUST contain a subject name that matched the one in the PKCS #10 request was relaxed to a SHOULD, because a number of implementations either ignored the issue entirely or at worst performed some minor action like creating a log entry, after which they continued anyway.
* 明らかな目的に役立つものではなく、主要な実装が執行されていないように見えなかったいくつかの要件をリラックスしました。たとえば、リクエストで使用されている自己署名証明書には、PKCS＃10の要求に一致する主要な名前が必要であることを要件に含める必要があります。ログエントリを作成するようなマイナーなアクションは、とにかくそれらが続けられました。
* Removed discussion of the transactionID from the security considerations, since the instructions there were directly contradicted by the discussion of the use of the transactionID in Section 5.
* セキュリティ上の考慮事項からのTransactionIDの議論を削除しました。
* Added a requirement that the signed message include the signing certificate(s) in the signedData certificates field. This was implicit in the original specification (without it, the message couldn't be verified by the CA) and was handled by the fact that most PKCS #7/CMS libraries do this by default, but was never explicitly mentioned.
* 署名付きメッセージにSignedData証明書フィールドに署名証明書が含まれているという要件を追加しました。これは元の仕様（それなしではCAによって検証できなかった）で暗黙のうちに、ほとんどのPKCS＃7 / CMSライブラリがデフォルトでこれを行うという事実によって処理されましたが、明示的に言及されていませんでした。
* Clarified sections that were unclear or even made no sense -- for example, the requirement for a "hash on the public key" [sic] encoded as a PrintableString.
* たとえば、「公開鍵の上のHASH」が印刷されている「ハッシュ」の要件は、不明確なセクションを明確にしました。
* Renamed "RA certificates" to "intermediate CA certificates". The original document at some point added mention of RA certificates without specifying how the client was to determine that an RA was in use, how the RA operations were identified in the protocol, or how it was used. It's unclear whether what was meant was a true RA or merely an intermediate CA, as opposed to the default practice of having certificates issued directly from a single root CA certificate. This update uses the term "intermediate CA certificates", since this seems to have been the original intent of the text.
* 「RA証明書」を「中間CA証明書」に変更しました。RAがどのように使用されていたかを決定せずにRA証明書、RA操作がどのように特定されたか、プロトコル内でどのように識別されたか、または使用された方法を指定することなく、RA証明書についての元の文書が追加されました。単一のルートCA証明書から直接発行された証明書を持つデフォルトの慣行とは対照的に、本当のRAまたは単なる中間CAであるかどうかは不明です。このアップデートでは、「中間CA証明書」という用語を使用しています。これはテキストの元の意図であるようです。
* Redid the PKIMessage diagram to match what was specified in CMS; the original diagram omitted a number of fields and nested data structures, which meant that the diagram didn't match either the text or the CMS specification.
* Pkimessage図をCMSで指定されたものと一致させるようにredid。元の図は、いくつかのフィールドとネストされたデータ構造を省略しています。これは、ダイアグラムがテキストまたはCMS仕様のいずれかと一致しなかったことを意味します。
* Removed the requirement for a CertPoll to contain a recipientNonce, since CertPoll is a client message and will never be sent in response to a message containing a senderNonce. See also the note in Section 3.3.2.
* certpollはクライアントメッセージであり、SenderNonceを含むメッセージに応答して送信されることは決してないでください。3.3.2項のメモも参照してください。
* Clarified certificate renewal. This represents a capability that was bolted onto the original protocol with (at best) vaguely defined semantics, including a requirement by the CA to guess whether a particular request was a renewal or not. In response to developer feedback that they either avoided renewal entirely because of this uncertainty or hard-coded in particular behaviour on a per-CA basis, this specification explicitly identifies renewal requests as such and provides proper semantics for them.
* 明確化された証明書更新。これは、特定の要求が更新であるかどうかを推測するために、CAによる要件を含む漠然と定義されたセマンティクスで、元のプロトコルにボルト化された機能を表します。この不確実性またはCAごとに特に挙動のような挙動のために全く再生を回避する開発者フィードバックに応答して、この仕様はそのような更新要求を明示的に識別し、それらに適切な意味論を提供する。
* Corrected the requirement that "undefined message types are treated as an error", since this negates the effect of GetCACaps, which is used to define new message types. In particular, operations such as GetCACaps "Renewal" would be impossible if enforced as written, because the Renewal operation was an undefined message type at the time.
* 「未定義のメッセージタイプはエラーとして扱われるという要件を修正しました。これにより、GetCacapsの効果がネゲートされます。特に、getCacapsの「更新」などの操作は、更新されているように適用されても、その時点で未定義のメッセージタイプであるため、不可能です。
* In line with the above, added IANA registries for several entries that had previously been defined in an ad hoc manner in different locations in the text.
* 上記に沿って、テキスト内のさまざまな場所で、以前に広告ホックで定義されていたいくつかのエントリのためのIANAレジストリを追加しました。
* Added the "SCEPStandard" keyword to GetCACaps to indicate that the CA complies with the final version of the SCEP standard, since the definition of what constitutes SCEP standards compliance has changed significantly over the years.
* CAがSCEP規格の最終バージョンに準拠していることを示す「SCEPSTANDARD」キーワードを追加して、SCEP規格のコンプライアンスが長年にわたって大幅に変化したものがあるため、CAがSCEP規格の最終バージョンに準拠していることを示します。
* Added the optional failInfoText attribute to deal with the fact that failInfo was incapable of adequately communicating to clients why a certificate request operation had been rejected.
* FailInfoがクライアントに適切に通信できないという事実に対処するためのオプションのFailInfotext属性を追加しました。
* Removed the discussion in the security considerations of revocation issues, since SCEP doesn't support revocation as part of the protocol.
* SCEPはプロトコルの一部としての失効をサポートしていないため、失効の問題のセキュリティ上の考慮事項の議論を削除しました。
* Clarified the use of nonces, which if applied as originally specified would have made the use of polling in the presence of a lost message impossible.
* 最初に指定されたように適用された場合、失われたメッセージの存在下でのポーリングの使用を行った場合、ノンスの使用を明らかにしました。
* Removed the discussion of generating a given transactionID by hashing the public key, since this implied that there was some special significance in the value generated this way. Since it was neither a MUST nor a MAY, it was unsound to imply that servers could rely on the value being generated a certain way. In addition, it wouldn't work if multiple transactions as discussed in Section 4.4 were initiated, since the deterministic generation via hashing would lead to duplicate transactionIDs.
* これは、このように生成された値に特別な意味があることを暗示しているため、公開鍵をハッシュすることによって特定のTransactionIDを生成するという説明を削除しました。どちらも5月でもないので、サーバーが特定の方法で生成されている値に頼ることができることを意味するのは不足していました。さらに、セクション4.4で議論された複数のトランザクションが開始された場合、それは機能しませんでした。
* Added examples of SCEP messages to give implementers something to aim for.
* Implersを目指すようにするためのSCEPメッセージの例を追加しました。
Acknowledgements
謝辞
The editor would like to thank all of the previous editors, authors, and contributors for their work maintaining the document over the years: Cheryl Madson, Xiaoyi Liu, David McGrew, David Cooper, Andy Nourse, Max Pritikin, Jan Vilhuber, and others. The IETF reviewers provided much useful feedback that helped improve the document, and in particular spotted a number of things that were present in SCEP through established practice rather than by being explicitly described in the text. Numerous other people have contributed during the long life cycle of the document, and all deserve thanks. In addition, several PKCS #7 / CMS libraries contributed to interoperability by doing the right thing despite what earlier SCEP documents required.
編集者は、前年にわたって文書を維持する彼らの仕事のために、以前の編集者、作家、および貢献者のすべてに感謝します.Cheryl Madson、Xiaoyi Liu、David McGrew、David Cooper、Andy Nourse、Max Pritikin、Jan Vilhuberなど。IETFレビュー担当者は、文書を改善するのに役立つ、特に、本文中に明示的に説明されているのではなく、SCEPに存在していた多数のことを見つけました。文書の長いライフサイクルの間に他の多くの人々が貢献しています、そしてすべての関係に値する。さらに、いくつかのPKCS＃7 / CMSライブラリが、以前のSCEP文書が必要なのかにもかかわらず正しいものをすることによって相互運用性に寄与しました。
The authors of earlier draft versions of this document would like to thank Peter William of ValiCert, Inc. (formerly of VeriSign, Inc.), Alex Deacon of VeriSign, Inc., and Christopher Welles of IRE, Inc. for their contributions to early versions of this protocol and this document.
この文書の以前のドラフト版の著者は、ValiCert、Inc。のPeter William（旧Verisign、Inc。）、Verisign、Inc。のAlex Deacon、およびIre、Inc。のChristopher Wellesの早期への貢献のためにあります。このプロトコルとこの文書のバージョン。
Author's Address
著者の住所
Peter Gutmann University of Auckland Department of Computer Science Auckland New Zealand
Peter Gutmannオークランド大学コンピュータサイエンスオークランドニュージーランド
Email: pgut001@cs.auckland.ac.nz