Browse Prior Art Database

Internet X.509 Certificate Request Message Format (RFC2511)

IP.com Disclosure Number: IPCOM000003095D
Original Publication Date: 1999-Mar-01
Included in the Prior Art Database: 2019-Feb-11
Document File: 25 page(s) / 31K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

M. Myers: AUTHOR [+3]

Related Documents

10.17487/RFC2511: DOI

Abstract

This document describes the Certificate Request Message Format (CRMF). [STANDARDS-TRACK]

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 8% of the total text.

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...

Processing...
Loading...