RFC 2511 (rfc2511) - Page 2 of 25
Internet X
Alternative Format: Original Text Document
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