Internet X.509 Certificate Request Message Format
RFC 2511

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 01

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 a