This is the seventh draft of the Internet Public Key Infrastructure X.509 Certificate and CRL Profile. This
draft is a complete specification. This text includes minor modifications over the previous draft. This draft
introduces UTF8 support, updates the path validation process to conform with the current X.509
specification, forbids wildcarding in subject alternative names, and clarifies conformance requirements.
Please send comments on this document to the ietf-pkix@tandem.com mail list.
This document describes the Internet X.509 Public Key Infrastructure (PKI) Certificate Management
Protocols. Protocol messages are defined for all relevant aspects of certificate creation and management.
Note that 'certificate' in this document refers to an X.509v3 Certificate as defined in [COR95, X509-AM].
The protocol described in this document is designed to satisfy some of the operational requirements within
the Internet X.509 Public Key Infrastructure (IPKI). Specifically, this document addresses requirements to
provide access to Public Key Infrastructure (PKI) repositories for the purposes of retrieving PKI
information and managing that same information. The mechanism described in this document is based on
the Lightweight Directory Access Protocol (LDAP) v2, defined in RFC 1777, defining a profile of that
protocol for use within the IPKI and updates encodings for certificates and revocation lists from RFC 1778.
Additional mechanisms addressing PKIX operational requirements are specified in separate documents.
This document presents a framework to assist the writers of certificate policies or certification practice
statements for certification authorities and public key infrastructures. In particular, the framework provides
a comprehensive list of topics that potentially (at the writer's discretion) need to be covered in a certificate
policy definition or a certification practice statement. This document is being submitted to the RFC Editor
with a request for publication as an Informational RFC.
The protocol conventions described in this document satisfy some of the operational requirements of the
Internet Public Key Infrastructure (PKI). This document specifies the conventions for using the File
Transfer Protocol (FTP) and the Hypertext Transfer Protocol (HTTP) to obtain certificates and certificate
revocation lists (CRLs) from PKI repositories. Additional mechanisms addressing PKIX operational
requirements are specified in separate documents. Please send comments on this document to the
ietf-pkix@tandem.com mail list.
This document specifies a protocol useful in determining the current status of a digital certificate without the
use of CRLs. Additional mechanisms addressing PKIX operational requirements are specified in separate
documents. Section 2 provides an overview of the protocol. Section 3 goes establishes functional
requirements, while section 4 provides the details of the protocol. In section 5 we cover security issues with
the protocol. Appendix A demonstrates OCSP over HTTP and appendix B accumulates ASN.1 syntactic
elements.
This is the first draft of a profile for specification of Elliptic Curve Digital Signature Algorithm (ECDSA)
keys in Internet Public Key Infrastructure X.509 certificates. Please send comments on this document to the
ietf-pkix@tandem.com mail list.
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.
Please send comments on this document to the ietf-pkix@lists.tandem.com mail list.
This document defines the means by which PKI clients and servers may exchange PKI messages when
using the Cryptographic Message Syntax [CMS] as a transaction envelope. It extends concepts established
in the draft [CRS] version of this material by accommodating external specification of message bodies in the
Certificate Management Message Formats [CMMF] and Certificate Request Message Format [CRMF]
documents. Mandatory requirements are established which facilitate automated interoperability between a
wide variety of PKI clients and servers or services. Optional features are defined to address more localized
needs. This draft is being discussed on the ''ietf-pkix'' mailing list.
This is a draft of the Internet X.509 Public Key Infrastructure (PKI) Certificate Management Messages
Formats (CMMF). It establishes harmonized message formats to be used in conjunction with security
protocol implementations that require interaction with a Public Key Infrastructure (PKI).
The schema defined in this document is a minimal schema to support PKIX in an LDAPv2 environment, as
defined in draft-ietf-pkix-ipki- ldapv2-06.txt. Only PKIX-specific components are specified here. LDAP
servers, acting as PKIX repositories should support the auxi- liary object classes defined in this
specification and integrate this schema specification with the generic and other application- specific
schemas as appropriate, depending on the services to be supplied by that server. The key words ''MUST'',
''REQUIRED'', ''SHOULD'', ''RECOMMENDED'', and ''MAY'' in this document are to be interpreted as
described in RFC 2119.
The Online Certificate Status Protocol [OCSP] specifies how a client process may obtain certificate status
information online from a server. In order for OCSP to scale beyond small communities of users, a method
to cache certificate status information at intermediary servers is required. This document describes the
requirements of and assumptions behind OCSP caching, and defines the mechanisms through which such
caching can be accomplished.
This document describes the Internet X.509 Public Key Infrastructure (PKI) Certificate Access Protocols.
Protocol messages are defined for all relevant aspects of certificate creation and management. Note that
''certificate'' in this document refers to an X.509v3 Certificate as defined in [COR95, X509-AM]. This
document specifies a set of methods, headers, and content-types ancillary to HTTP/1.1 to publish, retrieve
X.509 certificates and Certificate Revocation Lists. This protocol also facilitates determining current status
of a digital certificate without the use of CRLs. This protocol defines new methods, request and response
bodies, error codes to HTTP/1.1 protocol for securely publishing, retrieving, and validation certificates
across a firewalls.
This Internet Draft specifies mechanisms for determining if a public-key certificate is valid or revoked,
using CRL partitions. These mechanisms are considered superior to the CRL Distribution Points (CDP)
mechanism defined in ISO/IEC 9504-8/ITU-T Rec. X.509 for several reasons. In particular, OpenCDP:
(a) accommodates dynamic partitioning as opposed to fixed partitioning; (b) better supports use of
certificates in multiple environments with different CRL stores; (c) includes a means for improving
cachability and timeliness characteristics with CRLs; and (d) is believed not to be encumbered by the
patent claims applying to CDPs.
The IETF Simple Public Key Infrastructure [SPKI] Working Group is
tasked with producing a certificate structure and operating procedure
to meet the needs of the Internet community for trust management in as
easy, simple and extensible a way as possible.
The SPKI WG first established a list of things one might want to do
with certificates (attached at the end of this document), and then
summarized that list of desires into requirements. This document
presents that summary of requirements.
This document specifies a standard form for digital certificates and access control lists. These structures
bind either names or authorizations to keys or names that resolve to keys. The name and authorization
structures can be used separately or together. We use S-expressions as the standard format for these
certificates and define a canonical form for those S-expressions. These structures are also known under
the name SDSI 2.0.
The SPKI Working Group has developed a standard form for digital certificates and access control lists.
These structures bind either names or authorizations to keys. The binding can be directly to a key, or
indirectly through the hash of the key or a name for it. The name and authorization structures can be used
separately or together. We use S-expressions as the standard format for these certificates and define a
canonical form for those S-expressions. This document gives the theory behind SPKI certificates and
ACLs without going into technical detail about those structures or their uses.
SPKI structures are defined for public keys, hash values, access control list (ACL) entries and certificates.
This document gives examples of such structures for real world applications. The examples here are not
tied to any specific application and should be taken as informative examples rather than standard formats.
However, once applications are fielded using such structures and we have experience with them, we can
consider publishing those formats as proposed standards. That effort is considered out of scope for this
document.
ISO/OSI Standards
PKIX-IPKI