Network Working Group M. Blinov
Request for Comments: 4212 Guardeonic Solutions
Category: Informational C. Adams
University of Ottawa
October 2005
Alternative Certificate Formats for the
Public-Key Infrastructure Using X.509 (PKIX)
Certificate Management Protocols
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005).
IESG Note
This document is not a candidate for any level of Internet Standard.
The IETF disclaims any knowledge of the fitness of this document for
any purpose, and in particular notes that it has not had IETF review
for such things as security, congestion control, or inappropriate
interaction with deployed protocols. The RFC Editor has chosen to
publish this document at its discretion. Readers of this document
should exercise caution in evaluating its value for implementation
and deployment.
Abstract
The Public-Key Infrastructure using X.509 (PKIX) Working Group of the
Internet Engineering Task Force (IETF) has defined a number of
certificate management protocols. These protocols are primarily
focused on X.509v3 public-key certificates. However, it is sometimes
desirable to manage certificates in alternative formats as well.
This document specifies how such certificates may be requested using
the Certificate Request Message Format (CRMF) syntax that is used by
several different protocols. It also explains how alternative
certificate formats may be incorporated into such popular protocols
as PKIX Certificate Management Protocol (PKIX-CMP) and Certificate
Management Messages over CMS (CMC).
Blinov & Adams Informational [Page 1]RFC 4212 Alternative Certificate Formats October 20051. Introduction
Full certificate life-cycle management in a Public-Key Infrastructure
(PKI) requires protocol support in order to achieve automated
processing and end user transparency. Such protocols require
standardization in order to allow more than one vendor to supply
various pieces -- End Entity (EE), Certification Authority (CA),
Registration Authority (RA) -- in the PKI deployment of a single
organization, or to allow multiple, independently-deployed PKIs to be
interconnected usefully.
The IETF PKIX (Public-Key Infrastructure using X.509) Working Group
currently has several certificate management protocols and
certificate request syntax specifications on the standards track.
Although these specifications are primarily focused on X.509v3
public-key certificates, some of them can be easily extended to
handle certificates in alternative formats as well.
This document focuses on a popular certificate request syntax called
CRMF (Certificate Request Message Format) [CRMF]. Although the
original specification of CRMF is X.509-specific, extensions have
already been proposed to allow for alternative certificate templates
[CMP]. However, those extensions have only defined a framework; they
did not define the exact format to be used for various certificate
types.
This document builds on top of the framework mentioned above and
defines how CRMF can be used to request certificates of the following
types:
- X.509 attribute certificates [ATTCERT]
- OpenPGP certificates [OPENPGP]
The CRMF syntax is used by such popular protocols as PKIX-CMP (PKIX
Certificate Management Protocol) [CMP] and CMC (Certificate
Management Messages over CMS) [CMC]. This means that CRMF extensions
proposed in this document enable these protocols to request
certificates of the above types. However, it is not enough to be
able to request a certificate. The protocol should be prepared to
handle certificates of a particular type and, for example, return
them to the user.
This document proposes extensions to the PKIX-CMP and CMC protocols
that are required to manage certificates in alternative formats.
Blinov & Adams Informational [Page 2]RFC 4212 Alternative Certificate Formats October 2005
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
2. Certificate Template
One of the features of the CRMF format is its use of the CertTemplate
construct, which allows a requester (EE, or RA acting on behalf of an
EE) to specify as much or as little as they wish regarding the