|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## PKIXwg
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
|
|
|
|
|
|
|
|
|
Last Update: May 9, 2008
-- Color Legend: RFC Editor Queue
/ Processed by IESG
/ ID Exists
/ Recently Expired
-- Each I-D name is a link to an I-D description, which points to a text version, a two-page and fit-in-window PDF version, as well as the IETF Tools' HTML version.
|
|
|
|
|
|
|
|
|
## PKIXwg
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
|
|
|
|
|
|
|
|
|
|
|
|
## PKIXwg
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
|
|
|
|
|
|
| The charter of the PKIX working group -- updated on January 31, 2008 --
is reported below.
|
|
|
|
The PKIX Working Group was established in the fall of 1995 with the
goal of developing Internet standards to support X.509-based Public
Key Infrastructures (PKIs). Initially PKIX pursued this goal by
profiling X.509 standards developed by the CCITT (later the ITU-T).
Later, PKIX initiated the development of standards that are not
profiles of ITU-T work, but rather are independent initiatives
designed to address X.509-based PKI needs in the Internet. Over time
this latter category of work has become the major focus of PKIX work,
i.e., most PKIX-generated RFCs are no longer profiles of ITU-T X.509
documents.
PKIX has produced a number of standards track and informational RFCs.
RFC 3280 (Certificate and CRL Profile), and RFC 3281 (Attribute
Certificate Profile) are recent examples of standards track RFCs that
profile ITU-T documents. RFC 2560 (Online Certificate Status
Profile), RFC 3779 (IP Address and AS Number Extensions), and RFC 3161
(Time Stamp Authority) are examples of standards track RFCs that
are IETF-initiated. RFC 4055 (RSA) and RFC 3874 (SHA2) are examples
of informational RFCs that describe how to use public key and hash
algorithms in PKIs.
PKIX Work Plan
PKIX will continue to track the evolution of ITU-T X.509 documents,
and will maintain compatibility between these documents and IETF PKI
standards, since the profiling of X.509 standards for use in the
Internet remains an important topic for the working group.
PKIX does not endorse the use of specific cryptographic algorithms
with its protocols. However, PKIX does publish standards track RFCs
that describe how to identify algorithms and represent associated
parameters in these protocols, and how to use these algorithms with
these protocols. We anticipate efforts in this arena will continue to
be required over time.
PKIX will pursue new work items in the PKI arena if working group
members express sufficient interest, and if approved by the cognizant
Security Area director. For example, certificate validation under X.
509 and PKIX standards calls for a relying party to use a trust
anchor as the start of a certificate path. Neither X.509 nor extant
PKIX standards define protocols for the management of trust anchors.
Existing mechanisms for managing trust anchors, e.g., in browsers,
are limited in functionality and non-standard. There is considerable
interest in the PKI community to define a standard model for trust
anchor management, and standard protocols to allow remote management.
Thus a future work item for PKIX is the definition of such protocols
and associated data models.
|
|
|
|
|
|
|
|
## PKIXwg
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| | |
RFC2560
06/1999
(23 p.)
[html]
[pdf(2)] |
M. Myers
R. Ankney
A. Malpani
S. Galperin
C. Adams |
|
X.509 Internet Public Key Infrastructure
Online Certificate Status Protocol - OCSP |
This document specifies a protocol useful in determining the current
status of a digital certificate without requiring CRLs. Additional
mechanisms addressing PKIX operational requirements are specified in
separate documents.
An overview of the protocol is provided in section 2. Functional
requirements are specified in section 4. Details of the protocol are
in section 5. We cover security issues with the protocol in section
6. Appendix A defines OCSP over HTTP, appendix B accumulates ASN.1
syntactic elements and appendix C specifies the mime types for the
messages.
|
|
|
| |
| Up List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
| | |
RFC2585
05/1999
(8 p.)
[html]
[pdf(2)] |
R. Housley
P. Hoffman |
|
Internet X.509 Public Key Infrastructure
Operational Protocols: FTP and HTTP |
|
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.
|
|
|
| |
| Up List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
| | |
RFC2797
04/2000
(47 p.)
[html]
[pdf(2)] |
M. Myers
X. Liu
J. Schaad
J. Weinstein |
|
Certificate Management Messages over CMS |
This document defines a Certificate Management protocol using CMS
(CMC). This protocol addresses two immediate needs within the
Internet PKI community:
| |
| 1. |
The need for an interface to public key certification products and
services based on [CMS] and [PKCS10], and
|
| |
| 2. |
The need in [SMIMEV3] for a certificate enrollment protocol for
DSA-signed certificates with Diffie-Hellman public keys.
|
| |
A small number of additional services are defined to supplement the
core certificate request service.
Throughout this specification the term CMS is used to refer to both
[CMS] and [PKCS7]. For both signedData and envelopedData, CMS is a
superset of the PKCS7. In general, the use of PKCS7 in this document
is aligned to the Cryptographic Message Syntax [CMS] that provides a
superset of the PKCS7 syntax. The term CMC refers to this
specification.
|
|
|
| |
| Up List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
| | |
RFC2875
07/2000
(23 p.)
[html]
[pdf(2)] |
H. Prafullchandra
J. Schaad |
|
Diffie-Hellman Proof-of-Possession Algorithms |
|
This document describes two methods for producing an integrity check
value from a Diffie-Hellman key pair. This behavior is needed for
such operations as creating the signature of a PKCS #10 certification
request. These algorithms are designed to provide a proof-of-
possession rather than general purpose signing.
|
|
|
| |
| Up List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
| | |
RFC3029
02/2001
(51 p.)
[html]
[pdf(2)] |
C. Adams
P. Sylvester
M. Zolotarev
R. Zuccherato |
|
Internet X.509 Public Key Infrastructure
Data Validation and Certification Server Protocols |
This document describes a general Data Validation and Certification
Server (DVCS) and the protocols to be used when communicating with
it. The Data Validation and Certification Server is a Trusted Third
Party (TTP) that can be used as one component in building reliable
non-repudiation services.
Useful Data Validation and Certification Server responsibilities in a
PKI are to assert the validity of signed documents, public key
certificates, and the possession or existence of data.
Assertions created by this protocol are called Data Validation
Certificates (DVC).
We give examples of how to use the Data Validation and Certification
Server to extend the lifetime of a signature beyond key expiry or
revocation and to query the Data Validation and Certification Server
regarding the status of a public key certificate. The document
includes a complete example of a time stamping transaction.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| | |
RFC3281
04/2002
(40 p.)
[html]
[pdf(2)] |
S. Farrell
R. Housley |
|
An Internet Attribute Certificate Profile for Authorization |
|
This specification defines a profile for the use of X.509 Attribute
Certificates in Internet Protocols. Attribute certificates may be
used in a wide range of applications and environments covering a
broad spectrum of interoperability goals and a broader spectrum of
operational and assurance requirements. The goal of this document is
to establish a common baseline for generic applications requiring
broad interoperability as well as limited special purpose
requirements. The profile places emphasis on attribute certificate
support for Internet electronic mail, IPSec, and WWW security
applications.
|
|
|
| |
| Up List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| | |
RFC3628
11/2003
(43 p.)
[html]
[pdf(2)] |
D. Pinkas
N. Pope
J. Ross |
|
Policy Requirements for Time-Stamping Authorities (TSAs) |
|
This document defines requirements for a baseline time-stamp policy
for Time-Stamping Authorities (TSAs) issuing time-stamp tokens,
supported by public key certificates, with an accuracy of one second
or better. A TSA may define its own policy which enhances the policy
defined in this document. Such a policy shall incorporate or further
constrain the requirements identified in this document.
|
|
|
|
|
|
|
|
|
|
|
| | |
RFC3647
11/2003
(94 p.)
[html]
[pdf(2)] |
S. Chokhani
W. Ford
R. Sabett
C. Merrill
S. Wu |
|
Internet X.509 Public Key Infrastructure
Certificate Policy and Certification Practices Framework |
|
This document presents a framework to assist the writers of
certificate policies or certification practice statements for
participants within public key infrastructures, such as certification
authorities, policy authorities, and communities of interest that
wish to rely on certificates. 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 or a
certification practice statement. This document supersedes RFC 2527.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
| | |
RFC3739
03/2004
(34 p.)
[html]
[pdf(2)] |
S. Santesson
M. Nystrom
T. Polk |
|
Internet X.509 Public Key Infrastructure:
Qualified Certificates Profile |
This document forms a certificate profile, based on RFC 3280, for
identity certificates issued to natural persons.
The profile defines specific conventions for certificates that are
qualified within a defined legal framework, named Qualified
Certificates. However, the profile does not define any legal
requirements for such Qualified Certificates.
The goal of this document is to define a certificate profile that
supports the issuance of Qualified Certificates independent of local
legal requirements. The profile is however not limited to Qualified
Certificates and further profiling may facilitate specific local
needs.
|
|
|
| |
| Up List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
| | |
RFC3779
06/2004
(27 p.)
[html]
[pdf(2)] |
C. Lynn
C. Lynn
K. Seo |
|
X.509 Extensions for IP Addresses and AS Identifiers |
|
This document defines two X.509 v3 certificate extensions. The first
binds a list of IP address blocks, or prefixes, to the subject of a
certificate. The second binds a list of autonomous system
identifiers to the subject of a certificate. These extensions may be
used to convey the authorization of the subject to use the IP
addresses and autonomous system identifiers contained in the
extensions.
|
|
|
| |
| Up List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
| | |
RFC3820
06/2004
(37 p.)
[html]
[pdf(2)] |
S. Tuecke
V. Welch
D. Engert
L. Pearlman
M. Thompson |
|
Internet X.509 Public Key Infrastructure (PKI) Proxy Certificate Profile |
|
This document forms a certificate profile for Proxy Certificates,
based on X.509 Public Key Infrastructure (PKI) certificates as
defined in RFC 3280, for use in the Internet. The term Proxy
Certificate is used to describe a certificate that is derived from,
and signed by, a normal X.509 Public Key End Entity Certificate or by
another Proxy Certificate for the purpose of providing restricted
proxying and delegation within a PKI based authentication system.
|
|
|
| |
| Up List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
| | |
RFC3874
09/2004
(6 p.)
[html]
[pdf(2)] |
S. Tuecke
V. Welch
D. Engert
L. Pearlman
M. Thompson |
|
A 224-bit One-way Hash Function: SHA-224 |
|
This document specifies a 224-bit one-way hash function, called
SHA-224. SHA-224 is based on SHA-256, but it uses a different
initial value and the result is truncated to 224 bits.
|
|
|
|
|
|
|
|
|
|
|
| | |
RFC4043
05/2005
(15 p.)
[html]
[pdf(2)] |
D. Pinkas
T. Gindin |
|
Internet X.509 Public Key Infrastructure Permanent Identifier |
This document defines a new form of name, called permanent
identifier, that may be included in the subjectAltName extension of a
public key certificate issued to an entity.
The permanent identifier is an optional feature that may be used by a
CA to indicate that two or more certificates relate to the same
entity, even if they contain different subject name (DNs) or
different names in the subjectAltName extension, or if the name or
the affiliation of that entity stored in the subject or another name
form in the subjectAltName extension has changed.
The subject name, carried in the subject field, is only unique for
each subject entity certified by the one CA as defined by the issuer
name field. However, the new name form can carry a name that is
unique for each subject entity certified by a CA.
|
|
|
| |
| Up List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| | |
RFC4158
09/2005
(81 p.)
[html]
[pdf(2)] |
M. Cooper
Y. Dzambasow
P. Hesse
S. Joseph
R. Nicholas |
|
Internet X.509 Public Key Infrastructure: Certification Path Building |
|
This document provides guidance and recommendations to developers
building X.509 public-key certification paths within their
applications. By following the guidance and recommendations defined
in this document, an application developer is more likely to develop
a robust X.509 certificate-enabled application that can build valid
certification paths across a wide range of PKI environments.
|
|
|
|
|
|
|
|
|
|
|
| | |
RFC4210
09/2005
(95 p.)
[html]
[pdf(2)] |
C. Adams
S. Farrell
T. Kause
T. Mononen |
|
Internet X.509 Public Key Infrastructure
Certificate Management Protocol (CMP) |
|
This document describes the Internet X.509 Public Key Infrastructure
(PKI) Certificate Management Protocol (CMP). Protocol messages are
defined for X.509v3 certificate creation and management. CMP
provides on-line interactions between PKI components, including an
exchange between a Certification Authority (CA) and a client system.
|
|
|
| |
| Up List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
| | |
RFC4211
09/2005
(40 p.)
[html]
[pdf(2)] |
J. Schaad |
|
Internet X.509 Public Key Infrastructure
Certificate Request Message Format (CRMF) |
|
This document describes the Certificate Request Message Format (CRMF)
syntax and semantics. 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 the
associated registration information. This document does not define a
certificate request protocol.
|
|
|
| |
| Up List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| | |
RFC4387
02/2006
(25 p.)
[html]
[pdf(2)] |
P. Gutmann |
|
Internet X.509 Public Key Infrastructure
Operational Protocols: Certificate Store Access via HTTP |
|
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 Hypertext Transfer Protocol (HTTP/HTTPS) as an interface
mechanism to obtain certificates and certificate revocation lists
(CRLs) from PKI repositories. Additional mechanisms addressing PKIX
operational requirements are specified in separate documents.
|
|
|
| |
| Up List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
| | |
RFC4476
05/2006
(11 p.)
[html]
[pdf(2)] |
C. Francis
D. Pinkas |
|
Attribute Certificate (AC) Policies Extension |
|
This document describes one certificate extension that explicitly
states the Attribute Certificate Policies (ACPs) that apply to a
given Attribute Certificate (AC). The goal of this document is to
allow relying parties to perform an additional test when validating
an AC, i.e., to assess whether a given AC carrying some attributes
can be accepted on the basis of references to one or more specific
ACPs.
|
|
|
| |
| Up List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| | |
RFC4683
10/2006
(20 p.)
[html]
[pdf(2)] |
J. Park
J. Lee
H. Lee
S. Park
T. Polk |
|
Internet X.509 Public Key Infrastructure
Subject Identification Method (SIM) |
|
This document defines the Subject Identification Method (SIM) for
including a privacy-sensitive identifier in the subjectAltName
extension of a certificate.
The SIM is an optional feature that may be used by relying parties to
determine whether the subject of a particular certificate is also the
person corresponding to a particular sensitive identifier.
|
|
|
| |
| Up List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
| | |
RFC5055
12/2007
(88 p.)
[html]
[pdf(2)] |
T. Freeman
R. Housley
A. Malpani
D. Cooper
W. Polk |
|
Server-Based Certificate Validation Protocol (SCVP) |
|
The Server-Based Certificate Validation Protocol (SCVP) allows a
client to delegate certification path construction and certification
path validation to a server. The path construction or validation
(e.g., making sure that none of the certificates in the path are
revoked) is performed according to a validation policy, which
contains one or more trust anchors. It allows simplification of
client implementations and use of a set of predefined validation
policies.
|
|
|
| |
| Up List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
| | |
RFC5280
05/2008
(151 p.)
[html]
[pdf(2)] |
D. Cooper
S. Santesson
S. Farrell
S. Boeyen
R. Housley
W. Polk |
|
Internet X.509 Public Key Infrastructure Certificate
and Certificate Revocation List (CRL) Profile |
|
This memo profiles the X.509 v3 certificate and X.509 v2 certificate
revocation list (CRL) for use in the Internet. An overview of this
approach and model is provided as an introduction. The X.509 v3
certificate format is described in detail, with additional
information regarding the format and semantics of Internet name
forms. Standard certificate extensions are described and two
Internet-specific extensions are defined. A set of required
certificate extensions is specified. The X.509 v2 CRL format is
described in detail along with standard and Internet-specific
extensions. An algorithm for X.509 certification path validation is
described. An ASN.1 module and examples are provided in the
appendices.
|
|
|
| |
| Up List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
|
|
|
## PKIXwg
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
|
|
|
|
|
|
|
|
| -
|
|
|
|
|
|
|
|
|
## PKIXwg
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
|
|
|
|
|
|
|
|
|
|
| | |
pkix-2797-bis-07
Approved-
Announcement sent
Mar 10, 2008
(92 p.)
[pdf(2)]
[html]
|
J. Schaad
M. Myers |
|
Certificate Management Messages over CMS |
This document defines the base syntax for CMC, a Certificate
Management protocol using the Cryptographic Message Syntax (CMS).
This protocol addresses two immediate needs within the Internet
Public Key Infrastructure (PKI) community:
| |
| 1. |
The need for an interface to public key certification products
and services based on CMS and PKCS #10 (Public Key Cryptography
Standard), and
|
| |
| 2. |
The need for a PKI enrollment protocol for encryption only keys
due to algorithm or hardware design.
|
| |
CMC also requires the use of the transport document and the
requirements usage document along with this document for a full
definition.
|
|
|
| |
| Up List |
Intended Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
|
|
## PKIXwg
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
|
|
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Standard Track |
|
|
|
|
|
|
|
|
|
|
