Internet X.509 Certificate Request Message Format
RFC 2511
Document | Type |
RFC - Proposed Standard
(March 1999; No errata)
Obsoleted by RFC 4211
Was draft-ietf-pkix-crmf (pkix WG)
|
|
---|---|---|---|
Authors | Carlisle Adams , David Kemp , Michael Myers , Dave Solo | ||
Last updated | 2013-03-02 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 2511 (Proposed Standard) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | (None) | ||
Send notices to | (None) |
Network Working Group M. Myers Request for Comments: 2511 VeriSign Category: Standards Track C. Adams Entrust Technologies D. Solo Citicorp D. Kemp DoD March 1999 Internet X.509 Certificate Request Message Format Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. 1. Abstract This document describes the Certificate Request Message Format (CRMF). This syntax is used to convey a request for a certificate to a Certification Authority (CA) (possibly via a Registration Authority (RA)) for the purposes of X.509 certificate production. The request will typically include a public key and associated registration information. The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY" in this document (in uppercase, as shown) are to be interpreted as described in RFC 2119. 2. Overview Construction of a certification request involves the following steps: a) A CertRequest value is constructed. This value may include the public key, all or a portion of the end-entity's (EE's) name, other requested certificate fields, and additional control information related to the registration process. Myers, et. al. Standards Track [Page 1] RFC 2511 Internet X.509 CRMF March 1999 b) A proof of possession (of the private key corresponding to the public key for which a certificate is being requested) value may be calculated across the CertRequest value. c) Additional registration information may be combined with the proof of possession value and the CertRequest structure to form a CertReqMessage. d) The CertReqMessage is securely communicated to a CA. Specific means of secure transport are beyond the scope of this specification. 3. CertReqMessage Syntax A certificate request message is composed of the certificate request, an optional proof of possession field and an optional registration information field. CertReqMessages ::= SEQUENCE SIZE (1..MAX) OF CertReqMsg CertReqMsg ::= SEQUENCE { certReq CertRequest, pop ProofOfPossession OPTIONAL, -- content depends upon key type regInfo SEQUENCE SIZE(1..MAX) of AttributeTypeAndValue OPTIONAL } The proof of possession field is used to demonstrate that the entity to be associated with the certificate is actually in possession of the corresponding private key. This field may be calculated across the contents of the certReq field and varies in structure and content by public key algorithm type and operational mode. The regInfo field SHOULD only contain supplementary information related to the context of the certification request when such information is required to fulfill a certification request. This information MAY include subscriber contact information, billing information or other ancillary information useful to fulfillment of the certification request. Information directly related to certificate content SHOULD be included in the certReq content. However, inclusion of additional certReq content by RAs may invalidate the pop field. Data therefore intended for certificate content MAY be provided in regInfo. See Section 8 and Appendix B for example regInfo contents. Myers, et. al. Standards Track [Page 2] RFC 2511 Internet X.509 CRMF March 1999 4. Proof of Possession (POP) In order to prevent certain attacks and to allow a CA/RA to properly check the validity of the binding between an end entity and a key pair, the PKI management operations specified here make it possible for an end entity to prove that it has possession of (i.e., is able to use) the private key corresponding to the public key for which a certificate is requested. A given CA/RA is free to choose how to enforce POP (e.g., out-of-band procedural means versus the CRMF in- band message) in its certification exchanges (i.e., this may be aShow full document text