idnits 2.17.00 (12 Aug 2021)
/tmp/idnits5646/draft-ietf-pkix-roadmap-09.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in
this document.
Expected boilerplate is as follows today (2022-05-14) according to
https://trustee.ietf.org/license-info :
IETF Trust Legal Provisions of 28-dec-2009, Section 6.a:
This Internet-Draft is submitted in full conformance with the provisions
of BCP 78 and BCP 79.
IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2:
Copyright (c) 2022 IETF Trust and the persons identified as the document
authors. All rights reserved.
IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3:
This document is subject to BCP 78 and the IETF Trust's Legal Provisions
Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided
without warranty as described in the Simplified BSD License.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
** The document seems to lack a 1id_guidelines paragraph about
Internet-Drafts being working documents.
== No 'Intended status' indicated for this document; assuming Proposed
Standard
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** The document seems to lack an IANA Considerations section. (See Section
2.2 of https://www.ietf.org/id-info/checklist for how to handle the case
when there are no actions for IANA.)
** The document seems to lack separate sections for Informative/Normative
References. All references will be assumed normative when checking for
downward references.
== There are 7 instances of lines with non-RFC2606-compliant FQDNs in the
document.
== There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses
in the document. If these are example addresses, they should be changed.
Miscellaneous warnings:
----------------------------------------------------------------------------
== Line 2848 has weird spacing: '...tion of these...'
-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
have content which was first submitted before 10 November 2008. If you
have contacted all the original authors and they are all willing to grant
the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
this comment. If not, you may need to add the pre-RFC5378 disclaimer.
(See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (July 2002) is 7243 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
== Missing Reference: 'FORMAT' is mentioned on line 1671, but not defined
== Missing Reference: 'DCVS' is mentioned on line 361, but not defined
== Missing Reference: 'TRNRS' is mentioned on line 364, but not defined
== Missing Reference: 'REP' is mentioned on line 386, but not defined
== Missing Reference: 'POLPROC' is mentioned on line 1444, but not defined
== Missing Reference: 'RFC2459' is mentioned on line 974, but not defined
** Obsolete undefined reference: RFC 2459 (Obsoleted by RFC 3280)
== Missing Reference: 'CMPT' is mentioned on line 1360, but not defined
== Missing Reference: 'CMCbis' is mentioned on line 1428, but not defined
== Missing Reference: 'DSV' is mentioned on line 1545, but not defined
== Missing Reference: 'TS 102023' is mentioned on line 1639, but not defined
== Missing Reference: 'HTTP' is mentioned on line 1764, but not defined
== Missing Reference: 'TCP' is mentioned on line 1775, but not defined
== Missing Reference: 'RFC 1738' is mentioned on line 2000, but not defined
** Obsolete undefined reference: RFC 1738 (Obsoleted by RFC 4248, RFC 4266)
== Unused Reference: 'RFC2119' is defined on line 2640, but no explicit
reference was found in the text
== Unused Reference: '2527bis' is defined on line 2657, but no explicit
reference was found in the text
== Unused Reference: 'SIMONETTI' is defined on line 2794, but no explicit
reference was found in the text
** Obsolete normative reference: RFC 3280 (ref. '2459bis') (Obsoleted by
RFC 5280)
** Obsolete normative reference: RFC 2510 (Obsoleted by RFC 4210)
** Obsolete normative reference: RFC 2511 (Obsoleted by RFC 4211)
** Obsolete normative reference: RFC 2527 (Obsoleted by RFC 3647)
-- Possible downref: Non-RFC (?) normative reference: ref. '2797bis'
** Obsolete normative reference: RFC 3281 (ref. 'AC') (Obsoleted by RFC
5755)
-- Possible downref: Non-RFC (?) normative reference: ref. 'ACRMF'
-- Possible downref: Non-RFC (?) normative reference: ref. 'ACMC'
-- Possible downref: Non-RFC (?) normative reference: ref. 'ADDSCHEMA'
** Obsolete normative reference: RFC 2797 (ref. 'CMC') (Obsoleted by RFC
5272)
-- Duplicate reference: RFC2510, mentioned in 'CMP', was also mentioned in
'2510bis'.
** Obsolete normative reference: RFC 2510 (ref. 'CMP') (Obsoleted by RFC
4210)
** Obsolete normative reference: RFC 2630 (ref. 'CMS') (Obsoleted by RFC
3369, RFC 3370)
-- Duplicate reference: RFC2511, mentioned in 'CRMF', was also mentioned in
'2511bis'.
** Obsolete normative reference: RFC 2511 (ref. 'CRMF') (Obsoleted by RFC
4211)
** Obsolete normative reference: RFC 2875 (ref. 'DHPOP') (Obsoleted by RFC
6955)
-- Possible downref: Non-RFC (?) normative reference: ref. 'DPD'
-- Possible downref: Non-RFC (?) normative reference: ref. 'DPV'
-- Possible downref: Non-RFC (?) normative reference: ref. 'DPREQ'
** Downref: Normative reference to an Experimental RFC: RFC 3029 (ref.
'DVCS')
-- Possible downref: Non-RFC (?) normative reference: ref. 'IPEXT'
** Obsolete normative reference: RFC 1883 (ref. 'IPv6') (Obsoleted by RFC
2460)
** Downref: Normative reference to an Informational RFC: RFC 2528 (ref.
'KEA')
-- Possible downref: Non-RFC (?) normative reference: ref. 'LAAP'
** Obsolete normative reference: RFC 1777 (ref. 'LDAPv2') (Obsoleted by RFC
3494)
-- Possible downref: Non-RFC (?) normative reference: ref. 'LOGO'
** Obsolete normative reference: RFC 2560 (ref. 'OCSP') (Obsoleted by RFC
6960)
-- Possible downref: Non-RFC (?) normative reference: ref. 'OCSPv2'
-- Possible downref: Non-RFC (?) normative reference: ref. 'MISPC'
** Downref: Normative reference to an Historic RFC: RFC 1422 (ref. 'PEM')
-- Possible downref: Non-RFC (?) normative reference: ref. 'PI'
** Obsolete normative reference: RFC 2559 (ref. 'PKI-LDAPv2') (Obsoleted by
RFC 3494)
-- Possible downref: Non-RFC (?) normative reference: ref. 'PKI-LDAPv3'
-- Duplicate reference: RFC2527, mentioned in 'POLPRAC', was also mentioned
in '2527bis'.
** Obsolete normative reference: RFC 2527 (ref. 'POLPRAC') (Obsoleted by
RFC 3647)
** Obsolete normative reference: RFC 3039 (ref. 'QC') (Obsoleted by RFC
3739)
-- Possible downref: Non-RFC (?) normative reference: ref. 'RLS'
** Obsolete normative reference: RFC 822 (Obsoleted by RFC 2822)
** Obsolete normative reference: RFC 2587 (ref. 'SCHEMA') (Obsoleted by RFC
4523)
-- Possible downref: Non-RFC (?) normative reference: ref. 'SCVP'
-- Possible downref: Non-RFC (?) normative reference: ref. 'SIMONETTI'
-- Possible downref: Non-RFC (?) normative reference: ref. 'SSKGKA'
-- Possible downref: Non-RFC (?) normative reference: ref. 'SUPPALGS'
-- Possible downref: Non-RFC (?) normative reference: ref. 'TECHNR'
-- Possible downref: Non-RFC (?) normative reference: ref. 'TPCMC'
-- Possible downref: Non-RFC (?) normative reference: ref. 'TPCMP'
-- Possible downref: Non-RFC (?) normative reference: ref. 'WARR'
-- Possible downref: Non-RFC (?) normative reference: ref. 'PKCS10'
Summary: 27 errors (**), 0 flaws (~~), 20 warnings (==), 29 comments
(--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 PKIX Working Group A. Arsenault
3 Internet Draft Diversinet
4 Document: draft-ietf-pkix-roadmap-09.txt S. Turner
5 Expires: January, 2003 IECA
6 July 2002
8 Internet X.509 Public Key Infrastructure: Roadmap
10 Status of this Memo
12 This document is an Internet-Draft and is in full conformance with
13 all provisions of Section 10 of [RFC2026].
15 This document is an Internet-Draft. Internet-Drafts are working
16 documents of the Internet Engineering Task Force (IETF), its areas,
17 and its working groups. Note that other groups may also distribute
18 working documents as Internet-Drafts.
20 Internet-Drafts are draft documents valid for a maximum of six
21 months and may be updated, replaced, or obsoleted by other documents
22 at any time. It is inappropriate to use Internet-Drafts as reference
23 material or to cite them other than as "work in progress."
25 The list of current Internet-Drafts can be accessed at
26 http://www.ietf.org/ietf/1id-abstracts.txt
28 The list of Internet-Draft Shadow Directories can be accessed at
29 http://www.ietf.org/shadow.html.
31 This draft is being discussed on the 'ietf-pkix' mailing list. To
32 subscribe, send a message to ietf-pkix-request@imc.org with the
33 single word subscribe in the body of the message. There is a Web
34 site for the mailing list at .
36 Abstract
38 This document provides an overview or "roadmap" of the work done by
39 the IETF PKIX working group. It describes some of the terminology
40 used in the working group's documents, and the theory behind an
41 X.509-based Public Key Infrastructure, Privilege Management
42 Infrastructure (PMI), and Time Stamping and Data Certification
43 Infrastructures. It identifies each document developed by the PKIX
44 working group, and describes the relationships among the various
45 documents. It also provides advice to would-be PKIX implementors
46 about some of the issues discussed at length during PKIX development,
47 in hopes of making it easier to build implementations that will
48 actually interoperate.
50 Arsenault, Turner 1
51 1 INTRODUCTION.....................................................3
52 1.1 THIS DOCUMENT..................................................3
53 1.2 TERMINOLOGY....................................................3
54 1.3 HISTORY........................................................5
55 2 PKI..............................................................8
56 2.1 THEORY.........................................................8
57 2.2 ARCHITECTURE MODEL.............................................9
58 2.3 PUBLIC KEY CERTIFICATES.......................................11
59 2.4 FUNCTIONS OF A PKI............................................11
60 2.4.1 REGISTRATION................................................11
61 2.4.2 INITIALIZATION..............................................12
62 2.4.3 CERTIFICATION...............................................12
63 2.4.4 KEY PAIR RECOVERY...........................................12
64 2.4.5 KEY GENERATION..............................................12
65 2.4.6 KEY UPDATE..................................................13
66 2.4.6.1 KEY EXPIRY................................................13
67 2.4.6.2 KEY COMPROMISE............................................13
68 2.4.7 CROSS-CERTIFICATION.........................................14
69 2.4.8 REVOCATION..................................................14
70 2.4.9 CERTIFICATE & REVOCATION NOTICE DISTRIBUTION & PUBLICATION..15
71 3 PMI.............................................................16
72 3.1 THEORY........................................................16
73 3.2 ARCHITECTURAL MODEL...........................................16
74 3.3 ATTRIBUTE CERTIFICATES........................................17
75 4 PKIX DOCUMENTS..................................................18
76 4.1 PROFILES......................................................18
77 4.2 OPERATIONAL PROTOCOLS.........................................22
78 4.3 MANAGEMENT PROTOCOLS..........................................25
79 4.4 POLICY OUTLINE................................................28
80 4.4 TIME STAMPING AND DATA CERTIFICATION..........................28
81 4.5 EXPIRED DRAFTS................................................32
82 5 IMPLEMENTATION ADVICE...........................................36
83 5.1 NAMES.........................................................36
84 5.1.1 NAME FORMS..................................................36
85 5.1.1.1 DISTINGUISHED NAMES.......................................36
86 5.1.1.2 SUBJECTALTNAME FORMS......................................37
87 5.1.1.2.1 INTERNET E-MAIL ADDRESSES...............................37
88 5.1.1.2.2 DNS NAMES...............................................38
89 5.1.1.2.4 URIS....................................................38
90 5.1.2 SCOPE OF NAMES..............................................38
91 5.1.3 CERTIFICATE PATH CONSTRUCTION...............................39
92 5.1.4 NAME CONSTRAINTS............................................40
93 5.1.4.1 RFC822NAMES...............................................41
94 5.1.4.2 DNSNAMES..................................................41
95 5.1.4.3 X.400 ADDRESSES...........................................42
96 5.1.4.5 DNS.......................................................42
97 5.1.4.6 URIS......................................................42
98 5.1.4.7 IPADDRESSES...............................................43
99 5.1.4.8 OTHERS....................................................43
100 5.1.5 WILDCARDS IN NAME FORMS.....................................43
101 5.1.6 NAME ENCODING...............................................44
102 5.2 POP...........................................................44
103 5.2.1 POP FOR SIGNING KEYS........................................44
105 Arsenault, Turner 2
106 5.2.2 POP FOR KEY MANAGEMENT KEYS.................................45
107 5.3 KEY USAGE BITS................................................47
108 5.4 NON-REPUDIATION...............................................48
109 5.5 TRUST MODELS..................................................49
110 5.5.1 HIERARCHICAL................................................49
111 5.5.2 LOCAL/FEDERATION............................................49
112 5.5.3 ROOT REPOSITORY.............................................50
113 5.5.4 RP'S PERSPECTIVE............................................50
114 6 REFERENCES......................................................50
115 7 SECURITY CONSIDERATIONS.........................................54
116 8 ACKNOWLEDGEMENTS................................................55
117 9 AUTHOR'S ADDRESSES..............................................55
119 1 Introduction
121 1.1 This Document
123 This document is an informational Internet-Draft that provides a
124 "roadmap" to the documents produced by the PKIX working group. It is
125 intended to provide information; there are no requirements or
126 specifications in this document.
128 Section 1.2 of this document defines key terms used in this document.
129 Section 1.3 covers some of the basic history behind the PKIX working
130 group. Section 2 covers Public Key Infrastructure (PKI) theory and
131 functions. Section 3 covers Privilege Management Infrastructure (PMI)
132 theory and functions. Section 4 provides an overview of the various
133 PKIX documents. It identifies which documents address which areas,
134 and describes the relationships among the various documents. Section
135 5 contains "Advice to implementors." Its primary purpose is to
136 capture some of the major issues discussed by the PKIX working group,
137 as a way of explaining why some of the requirements and
138 specifications say what they say. This explaination should cut down
139 on the number of misinterpretations of the documents, and help
140 developers build interoperable implementations. Section 6 contains a
141 list of contributors we wish to thank. Section 7 provides a list
142 references. Section 8 discusses security considerations, and Section
143 9 provides contact information for the editors.
145 1.2 Terminology
147 There are a number of terms used and misused throughout PKI-related,
148 PMI-related, and Time Stamp and Data Certification literature. To
149 limit confusion caused by some of those terms, used throughout this
150 document, we will use the following terms in the following ways:
152 - Attribute Authority (AA) - An authority trusted by one or more
153 users to create and sign attribute certificates. It is important
154 to note that the AA is responsible for the attribute
155 certificates during their whole lifetime, not just for issuing
156 them.
158 Arsenault, Turner 3
159 - Attribute Certificate (AC) - A data structure containing a set of
160 attributes for an end-entity and some other information, which
161 is digitally signed with the private key of the AA which issued
162 it.
164 - Certificate - Can refer to either an AC or a public key
165 certificate. Where there is no distinction made the context
166 should be assumed that the term could apply to both an AC or a
167 public key certificate.
169 - Certification Authority (CA) - An authority trusted by one or
170 more users to create and assign public key certificates.
171 Optionally the CA may create the user's keys. It is important to
172 note that the CA is responsible for the public key certificates
173 during their whole lifetime, not just for issuing them.
175 - Certificate Policy (CP) - A named set of rules that indicates the
176 applicability of a public key certificate to a particular
177 community or class of application with common security
178 requirements. For example, a particular certificate policy might
179 indicate applicability of a type of public key certificate to
180 the authentication of electronic data interchange transactions
181 for the trading of goods within a given price range.
183 - Certification Practice Statement (CPS) - A statement of the
184 practices which a CA employs in issuing public key certificates.
186 - End-entity - A subject of a certificate who is not a CA in the
187 PKI or an AA in the PMI. (An EE from the PKI can be an AA in the
188 PMI.)
190 - Public Key Certificate (PKC) - A data structure containing the
191 public key of an end-entity and some other information, which is
192 digitally signed with the private key of the CA which issued it.
194 - Public Key Infrastructure (PKI) - The set of hardware, software,
195 people, policies and procedures needed to create, manage, store,
196 distribute, and revoke PKCs based on public-key cryptography.
198 - Privilege Management Infrastructure (PMI) - A collection of ACs,
199 with their issuing AA's, subjects, relying parties, and
200 repositories, is referred to as a Privilege Management
201 Infrastructure.
203 - Registration Authority (RA) - An optional entity given
204 responsibility for performing some of the administrative tasks
205 necessary in the registration of subjects, such as: confirming
206 the subject's identity; validating that the subject is entitled
207 to have the values requested in a PKC; and verifying that the
208 subject has possession of the private key associated with the
209 public key requested for a PKC.
211 Arsenault, Turner 4
212 - Relying party - A user or agent (e.g., a client or server) who
213 relies on the data in a certificate in making decisions.
215 - Root CA - A CA that is directly trusted by an EE; that is,
216 securely acquiring the value of a Root CA public key requires
217 some out-of-band step(s). This term is not meant to imply that a
218 Root CA is necessarily at the top of any hierarchy, simply that
219 the CA in question is trusted directly. Note that the term
220 'trust anchor' is commonly used with the same meaning as 'root
221 CA' in this document.
223 - Subordinate CA - A "subordinate CA" is one that is not a Root CA
224 for the EE in question. Often, a subordinate CA will not be a
225 Root CA for any entity but this is not mandatory.
227 - Subject - A subject is the entity (AA, CA, or EE) named in a
228 certificate, either a PKC or AC. Subjects can be human users,
229 computers (as represented by Domain Name Service (DNS) names or
230 Internet Protocol (IP) addresses), or even software agents.
232 - Time Stamp Authority (TSA) - A TSA is a trusted Third Party who
233 provides a "proof-of-existence" for a particular datum prior to
234 an instant in time.
236 - Top CA - A CA that is at the top of a PKI hierarchy. Note: This
237 is often also called a "Root CA," since in data structures terms
238 and in graph theory, the node at the top of a tree is the
239 "root." However, to minimize confusion in this document, we
240 elect to call this node a "Top CA," and reserve "Root CA" where
241 there is a single CA directly trusted by the EE. Readers new to
242 PKIX should be aware that these terms are not used consistently
243 throughout the PKIX documents, as the Internet PKI profile
244 [2459bis] uses "Root CA" to refer to what this and other
245 documents call a "Top CA," and "most-trusted CA" to refer to
246 what this and other documents call a "Root CA."
248 1.3 History
250 The PKIX working group was formed in October of 1995 to develop
251 Internet standards necessary to support PKIs. The first work item was
252 a profile of the ITU-T Recommendation X.509 PKC [FORMAT]. X.509,
253 which is a widely accepted basis for a PKI, including data formats
254 and procedures related to distribution of public keys via PKCs
255 digitally signed by CAs. X.509 does not however include a profile to
256 specify the support requirements for many of the PKC data structure's
257 sub- fields, for any of the extensions, nor for certain data values.
258 The Internet PKI profile [FORMAT] went through many draft versions
259 before becoming an RFC. Other profiles have been developed in PKIX
260 for particular algorithms to make use of the Internet PKI Profile
261 [FORMAT]. There has been no sense of conflict between the authors
262 that developed these profiles as they are seen as complimentary. The
263 Internet PKI profile has been a draft standard for more than six
265 Arsenault, Turner 5
266 months and is currently going through an update process to clarify
267 any inconsistencies and to bolster certain sections, see [2459bis].
269 In parallel with the profile development, work was undertaken to
270 develop the protocols necessary to manage PKI-related information
271 was. The first developed was the Certificate Management Protocol
272 (CMP). It defines a message protocol to initialize, certify, update,
273 and revoke PKI entities [CMP]. The demand for an enrollment protocol
274 and the desire to use PKCS-10 message format as the certificate
275 request syntax lead to the development of two different documents in
276 two different groups. The Certificate Request Syntax (CRS) draft was
277 developed in the SMIME WG which used PKCS-10 [PKCS10] as the
278 certification request message format. Certificate Request Message
279 Format [CRMF] draft was also developed but in the PKIX WG. It was to
280 define a simple enrollment protocol that would subsume both the CMP
281 and CRS enrollment protocols, but it did not use PKCS-10 as the
282 certificate request message format. Then the certificate management
283 message format document, was developed to define an extended set of
284 management messages that flow between the components of the Internet
285 PKI. Certificate Management Messages over CMS (CMC) was developed to
286 allow the use of an existing protocol (S/MIME) as a PKI management
287 protocol, without requiring the development of an entirely new
288 protocol such as CMP [CMC]. It also included [PKCS10] as the
289 certificate request syntax, which caused work on the CRS draft to
290 stop. Information from the certificate management message format
291 document was moved into [CMP] and [CMC] so work on the certificate
292 management message format document was discontinued. After some
293 operational experience with [CMP], two drafts, one for using HTTP as
294 the transport protocol and one for Transmission Control Protocol
295 (TCP), were written to solve problems encountered by implementors.
296 These drafts were merged into one draft Transport Protocols for CMP
297 [TPCMP]. [CMP] has been a draft standard for more than six months and
298 is currently undergoing revisions to document. The transport section
299 has been removed and will remain in [TPCMP].
301 Another long debated topic in the WG dealt with certificate
302 revocation. Numerous drafts have been developed to address different
303 issues related certificate revocations. CMP supports revocation
304 request, response, revocation announcement, and requests for CRL
305 messages. CMC defines revocation request, revocation response, and
306 requests for CRL messages, but uses CMS as the encapsulating
307 protocol. [OCSP] was developed to address concerns that not all
308 relying parties want to go through the process checking CRLs from
309 every CA in the certification path. It defines an on-line mechanism
310 to determine the status of a given certificate, which may provide
311 more timely revocation information than is possible with CRLs. The
312 Simple Certification Verification Protocol (SCVP) was produced to
313 allow relying parties to off-load all of their certification
314 verification to another entity [SCVP]. The WG was arguably split over
315 whether such a function should be supported and whether it should be
316 its own protocol or included in OCSP. In response, a draft defining
317 OCSP Extensions was produced to include the functions of SCVP. [OCSP]
318 has been a draft standard for more than six months and is in the
320 Arsenault, Turner 6
321 process of being revised [OCSPv2]. To capture the work from the OCSP
322 Extensions, two drafts were developed: Delegated Path Validation
323 [DPV] and Delegated Path Discovery [DPD]. The WG recognizes an eed to
324 address online delegated path validation and delegated path
325 discovery. At least three candidates currently exist. There are:
326 OCSPv2, SCVP, and DVCS. Given this multiplicity, the WG undertook to
327 produce [DPREQ] in order to factilate selection from among these or
328 possibly others.
330 One other certificate status draft called Open CRL Distribution Point
331 (OCDP) was produced which documented two extensions: one to support
332 an alternative CRL partitioning mechanism to the CRL Distribution
333 Point mechanism documented in the Internet PKI Profile [FORMAT] and
334 one to support identifying other revocation sources available to
335 certificate-users. The work from this draft was subsumed by an ITU-T
336 | ISO/IEC Amendment to X.509, hence work on this draft was halted.
338 Development of the operational protocols has been slightly more
339 straightforward. Four documents for the Light Weight Directory Access
340 Protocol (LDAP) have been developed one for defining LDAPv2 as an
341 access protocol to repositories [PKI-LDAPv2]; two for storing PKI
342 information in an directory [SCHEMA] and [ADDSCHEMA]; and one for
343 LDAPv3 requirements for PKI [PKI-LDAPv3]. Using the File Transfer
344 Protocol (FTP) and the Hyper Text Transmission Protocol (HTTP) to
345 retrieve PKCs and CRLs from PKI repositories was documented in
346 [FTPHTTP]. Recognizing that LDAP directories are not the only
347 repository service, the working group draft a Repository Locator
348 Service [RLS] to make use of DNS SRV records to locate where and how
349 PKI information can be retrieved from a repository.
351 In late 1998 the PKIX charter was revised to include protocols for
352 time stamping and data certification services. [TSP] was developed to
353 define protocols required to interact with a Time Stamp Authority
354 (TSA) who asserts that a datum existed priot to a given time. [DVCS]
355 allows to verify and assert the validity of all signatures attached
356 to the signed document using all appropriate status information and
357 PKCs or to verify and assert the validity of one or more PKCs at the
358 specified time. Both [DVCS] and [TSP] use [CMS] as an encapsulating
359 mechanism (though in [TSP] request for a time stamp are not required
360 to use [CMS]). A draft for extending trust in tokens in time was
361 developed to use [DCVS] to maintain the trust in a token issued by a
362 non- repudiation Trusted Third Party (NR TTP) after the key initially
363 used to establish trust in the token expires; however, this draft has
364 expired. The [TRNRS] draft was developed to describe those features
365 of a service which processes signed documents that must be present in
366 order for that service to constitute a "technical non- repudiation"
367 service.
369 Around the same time, a work item for ACs, defined in [X.509], was
370 added. ACs are similar to PKCs, but they do not bind public keys to
371 identities rather they bind attributes to identities. The attributes
372 bound to the identity can represent anything, but are mostly used to
373 support rule-based and role-based access control decisions. Two
375 Arsenault, Turner 7
376 drafts have since been developed: the Internet Attribute Certificates
377 Profile for Authorizations [AC] and the Limited Attribute Certificate
378 Acquisition Protocol [LAAP]. The first profiles the fields and
379 extensions of the AC and the second provides a deliberately limited
380 protocol to access a repository when LDAP is not appropriate.
382 Other drafts have been produced to address specific issues. [DHPOP]
383 was developed to define two mechanisms by which a signature can
384 produced using a Diffie-Hellman pair. This draft provides a mechanism
385 to use Diffie-Hellam key pairs to authenticate a PKCS-10
386 certification request. [REP] was developed during the revision to the
387 Internet PKI Profile [FORMAT] to separate the definitions of the
388 object identifiers and encoding rules for keys and digital signatures
389 in PKCs. The Qualified Certificates [QC] and Permanent Identifier
390 [PI] drafts were developed to address naming issues.
392 From the alphabet soup above, it is clear why this roadmap is
393 required.
395 2 PKI
397 2.1 Theory
399 At the heart of recent efforts to improve Internet security are a
400 group of security protocols such as Secure Multipurpose Internet Mail
401 Extensions (S/MIME), Transport Layer Security (TLS), and Internet
402 Protocol Security (IPSec). All of these protocols rely on public-key
403 cryptography to provide services such as confidentiality, data
404 integrity, data origin authentication, and non-repudiation. The
405 purpose of a PKI is to provide trusted and efficient key and public
406 key certificate management, thus enabling the use of authentication,
407 non-repudiation, and confidentiality.
409 Users of public key-based systems must be confident that, any time
410 they rely on a public key, the subject that they are communicating
411 with owns the associated private key, this applies whether an
412 encryption or digital signature mechanism is used. This confidence is
413 obtained through the use of PKCs, which are data structures that bind
414 public key values to subjects. The binding is achieved by having a
415 trusted CA verify the subject's identity and digitally sign each PKC.
417 A PKC has a limited valid lifetime, which is indicated in its signed
418 contents. Because a PKC's signature and timeliness can be
419 independently checked by a certificate-using client, PKCs can be
420 distributed via untrusted communications and server systems, and can
421 be cached in unsecured storage in certificate-using systems.
423 PKCs are used in the process of validating signed data. Specifics
424 vary according to which algorithm is used, but the general process
425 works as follows (Note: there is no specific order in which the
426 checks listed below must be made; implementors are free to implement
427 them in the most efficient way for their systems):
429 Arsenault, Turner 8
430 - The recipient of signed data verifies that the claimed identity
431 of the user is in accordance with the identity contained in the
432 PKC;
434 - The recipient validates that no PKC in the path is revoked (e.g.,
435 by retrieving a suitably-current Certificate Revocation List
436 (CRL) or querying an on-line certificate status responder), and
437 that all PKCs are within their validity periods at the time the
438 data was signed;
440 - The recipient verifies that the data are not claimed to have any
441 values for which the PKC indicates that the signer is not
442 authorized;
444 - The recipient verifies that the data have not been altered since
445 signing, by using the public key in the PKC.
447 - If all of these checks pass, the recipient can accept that the
448 data was signed by the purported signer. The process for keys
449 used for encryption is similar.
451 Note: It is of course possible that the data was signed by someone
452 very different from the signer, if for example the purported signer's
453 private key was compromised. Security depends on all parts of the
454 certificate-using system, including but not limited to: physical
455 security of the place the computer resides; personnel security (i.e.,
456 the trustworthiness of the people who actually develop, install, run,
457 and maintain the system); the security provided by the operating
458 system on which the private key is used; and the security provided
459 the CA. A failure in any one of these areas can cause the entire
460 system security to fail. PKIX is limited in scope, however, and only
461 directly addresses issues related to the operation of the PKI
462 subsystem. For guidance in many of the other areas, see [POLPROC].
464 2.2 Architecture Model
466 A PKI is defined as:
468 The set of hardware, software, people, policies and procedures needed
469 to create, manage, store, distribute, and revoke PKCs based on
470 public-key cryptography.
472 A PKI consists of five types of components [MISPC]:
474 - Certification Authorities (CAs) that issue and revoke PKCs;
476 - Organizational Registration Authorities (ORAs) that vouch for the
477 binding between public keys and certificate holder identities
478 and other attributes;
480 Arsenault, Turner 9
481 - PKC holders are issued certificates and can sign digital
482 documents and decrypt documents using private keys;
484 - Clients that validate digital signatures and their certification
485 paths from a known public key of a trusted CA and that encrypt
486 document using public key from certificates of PKC holders;
488 - Repositories that store and make available PKCs and Certificate
489 Revocation Lists (CRLs).
491 Figure 1 is a simplified view of the architectural model assumed by
492 the PKIX Working Group.
494 +---+ cert. publish +------------+
495 | | <--------------------- | End Entity | <-------
496 | C | +------------+ "out-of-band"
497 | | | ^ loading
498 | e | | | initial
499 | r | | | registration/
500 | t | | | certification
501 | | | | key pair recovery
502 | / | | | key pair update
503 | | | | certificate update
504 | C | PKI "USERS" V | revocation request
505 | R | -------------------+-+-----+-+------+-+-------------------
506 | L | PKI MANAGEMENT | ^ | ^
507 | | ENTITIES | | | |
508 | | V | | |
509 | R | +------+ | |
510 | e | <------------ | RA | <-----+ | |
511 | p | cert. | | ----+ | | |
512 | o | publish +------+ | | | |
513 | s | | | | |
514 | i | V | V |
515 | t | +------------+
516 | o | <------------------------| CA |------->
517 | r | +------------+ "out-of-band"
518 | y | cert. publish | ^ publication
519 | | CRL publish | |
520 +---+ | | cross-certification
521 | | cross-certificate
522 | | update
523 | |
524 V |
525 +------+
526 | CA-2 |
527 +------+
529 Figure 1 - PKI Entities
531 Arsenault, Turner 10
532 2.3 Public Key Certificates
534 ITU-T X.509 (formerly CCITT X.509) or ISO|IEC/ITU 9594-8, which was
535 first published in 1988 as part of the X.500 Directory
536 recommendations, defines a standard PKC format [X.509]. The PKC
537 format in the 1988 standard is called the version 1 (v1) format.
539 When X.500 was revised in 1993, two more fields,
540 subjectUniqueIdentifier and issuerUniqueIdentifier were added,
541 resulting in the version 2 (v2) format. These two fields may be used
542 to support directory access control.
544 The Internet Privacy Enhanced Mail (PEM) RFCs, published in 1993,
545 include specifications for a public key infrastructure based on X.509
546 v1 public key certificates [PEM]. The experience gained in attempts
547 to deploy [PEM] made it clear that the v1 and v2 public key
548 certificate formats are deficient in several respects. Most
549 importantly, more fields were needed to carry information which PEM
550 design and implementation experience has proven necessary. In
551 response to these new requirements, ISO|IEC, ITU, and ANSI X9
552 developed the X.509 version 3 (v3) PKC format. The v3 format extends
553 the v2 format by adding provision for additional extension fields.
554 Particular extension field types may be specified in standards or may
555 be defined and registered by any organization or community. In June
556 1996, standardization of the basic v3 format was completed [X.509].
558 ISO|IEC, ITU, and ANSI X9 have also developed standard extensions for
559 use in the v3 extensions field [X.509][X9.55]. These extensions can
560 convey such data as additional subject identification information,
561 key attribute information, policy information, and certification path
562 constraints. However, the ISO/IEC/ITU and ANSI X9 standard extensions
563 are very broad in their applicability. In order to develop
564 interoperable implementations of X.509 v3 systems for Internet use,
565 it is necessary to specify a profile for use of the X.509 v3
566 extensions tailored for the Internet. It is one goal of PKIX to
567 specify a profile for Internet, electronic mail, and IPSec
568 applications, etc. Environments with additional requirements may
569 build on this profile or may replace it.
571 2.4 Functions of a PKI
573 This section describes the major functions of a PKI. In some cases,
574 PKIs may provide extra functions.
576 2.4.1 Registration
578 This is the process whereby a subject first makes itself known to a
579 CA (directly, or through an RA), prior to that CA issuing a PKC or
580 PKCs for that subject. Registration involves the subject providing
581 its name (e.g., common name, fully-qualified domain name, IP
582 address), and other attributes to be put in the PKC, followed by the
584 Arsenault, Turner 11
585 CA (possibly with help from the RA) verifying in accordance with its
586 Certification Practice Statement (CPS) that the name and other
587 attributes are correct.
589 2.4.2 Initialization
591 Initialization is when the subject (e.g., the user or client system)
592 gets the values needed to begin communicating with the PKI. For
593 example, initialization can involve providing the client system with
594 the public key or PKC of a CA, or generating the client system's own
595 public-private key pair.
597 2.4.3 Certification
599 This is the process in which a CA issues a PKC for a subject's public
600 key, and returns that PKC to the subject or posts that PKC in a
601 repository.
603 2.4.4 Key Pair Recovery
605 In some implementations, key exchange or encryption keys will be
606 required by local policy to be "backed up," or recoverable in case
607 the key is lost and access to previously-encrypted information is
608 needed. Such implementations can include those where the private key
609 exchange key is stored on a hardware token that can be lost or
610 broken, or when a private key file is protected by a password which
611 can be forgotten. Often, a company is concerned about being able to
612 read mail encrypted by or for a particular employee when that
613 employee is no longer available because she is ill or no longer works
614 for the company.
616 In these cases, the user's private key can be backed up by a CA or by
617 a separate key backup system. If a user or her employer needs to
618 recover these backed up key materials, the PKI must provide a system
619 that permits the recovery without providing an unacceptable risk of
620 compromise of the private key.
622 2.4.5 Key Generation
624 Depending on the CA's policy, the private-public key pair can either
625 be generated by the user in his local environment, or generated by
626 the CA. In the latter case, the key material may be distributed to
627 the user in an encrypted file or on a physical token (e.g., a smart
628 card or PC card).
630 Arsenault, Turner 12
631 2.4.6 Key Update
633 All key pairs need to be updated regularly (i.e., replaced with a new
634 key pair) and new PKCs issued. This will happen in two cases:
635 normally, when a key has passed its maximum usable lifetime; and
636 exceptionally, when a key has been compromised and must be replaced.
638 2.4.6.1 Key Expiry
640 In the normal case, a PKI needs to provide a facility to gracefully
641 transition from a PKC with an existing key to a new PKC with a new
642 key. This is particularly true when the key to be updated is that of
643 a CA. Users will know in advance that the key will expire on a
644 certain date; the PKI, working together with PKC-using applications,
645 should allow for appropriate keys to work before and after the
646 transition. There are a number of ways to do this; see [CMP] for an
647 example of one.
649 2.4.6.2 Key Compromise
651 In the case of a key compromise, the transition will not be
652 "graceful" in that there will be an unplanned switch of PKCs and
653 keys; users will not have known in advance what was about to happen.
654 Still, the PKI must support the ability to declare that the previous
655 PKC is now invalid and shall not be used, and to announce the
656 validity and availability of the new PKC.
658 Note: compromise of a private key associated with a Root CA is
659 catastrophic for users relying on that Root CA. If a Root CA's
660 private key is compromised, that CA's PKC must be revoked and all
661 PKCs subordinate to it must also be revoked. Until such time as the
662 Root CA has been issued a new PKC and the Root CA issues PKCs to
663 users relying upon it, users relying on that Root CA are cut off from
664 the rest of the system, as there is no way to develop a valid
665 certification path back to a trusted node.
667 Further, users will likely have to be notified by out-of-band
668 mechanisms about the change in CA keys. If the old key is
669 compromised, any "update" message telling subordinates to switch to a
670 new key could have come from an attacker in possession of the old
671 key, and could point to a new public key for which the attacker
672 already has the private key. It is possible to have anticipated this
673 event, and "pre-placed" replacement Root CA keys with all relying
674 parties, but some secure, out-of-band mechanism will have to be used
675 to tell users to make the switch, and this will only help if the
676 replacement key has not been compromised.
678 Additionally, once the Root CA is brought back up with a new key, it
679 will likely be necessary to re-issue PKCs, signed with the new key,
680 to all subordinate users, since their current PKC would be signed
681 with a now-revoked key.
683 Arsenault, Turner 13
684 2.4.7 Cross-certification
686 A CA certificate is a certificate in a hierarchy that is neither a
687 self-signed certificate, nor an end-entity certificate. [2459bis]
688 does not make a difference between a CA certificate and a cross
689 certificate since it defines a cross-certificate as "a certificate
690 issued by one CA to another CA". Some people in the WG believe that
691 a cross certificate is a special kind of CA certificate. A cross
692 certificate is issued by a CA under one Top CA for another CA under
693 a different Top CA. CAs in the same hierarchy have part of their
694 names imposed by the Top CA or by the CAs under that Top CAS. When a
695 cross certificate is issued, there is no relationship between the
696 names of the CAs.
698 Typically, a cross-certificate is used to allow client systems or
699 end entities in one administrative domain to communicate securely
700 with client systems or end users in another administrative domain.
701 Use of a cross-certificate issued from CA_1 to CA_2 allows user
702 Alice, who trusts CA_1, to accept a PKC used by Bob, which was
703 issued by CA_2. Cross-certificates can also be issued from one CA to
704 another CA in the same administrative domain, if required.
706 Cross-certificates can be issued in only one direction, or in both
707 directions, between two CA's. That is, just because CA_1 issues a
708 cross-certificate for CA_2, CA_2 does not have to issue a cross-
709 certificate for CA_1.
711 2.4.8 Revocation
713 When a PKC is issued, it is expected to be in use for its entire
714 validity period. However, various circumstances may cause a PKC to
715 become invalid prior to the expiration of the validity period. Such
716 circumstances include change of name, change of association between
717 subject and CA (e.g., an employee terminates employment with an
718 organization), and compromise or suspected compromise of the
719 corresponding private key. Under such circumstances, the CA needs to
720 revoke the PKC.
722 X.509 defines one method of PKC revocation. This method involves each
723 CA periodically issuing a signed data structure called a certificate
724 revocation list (CRL). A CRL is a list that identifies the
725 references of revoked PKCs. This list contains a date of issue and
726 is signed by a CA and made freely available in a public repository.
727 Each revoked PKC is identified in a CRL by its PKC serial number.
728 When a certificate-using system uses a PKC, that system not only
729 checks the PKC signature and validity but also acquires a suitably
730 recent CRL and checks that the PKC serial number is not on that CRL.
731 The meaning of "suitably recent" may vary with local policy, but it
732 usually means the most recently issued CRL. A CA issues a new CRL on
733 a regular periodic basis (e.g., hourly, daily, or weekly). CA's may
735 Arsenault, Turner 14
736 also issue CRLs aperiodically. For example, if an important key is
737 deemed compromised, the CA may issue a new CRL to expedite
738 notification of that fact, even if the next CRL does not have to be
739 issued for some time. (A problem of aperiodic CRL issuance is that
740 end-entities may not know that a new CRL has been issued, and thus
741 may not retrieve it from a repository.)
743 An entry is added to the CRL as part of the next update following
744 notification of revocation. An entry may be removed from the CRL
745 after appearing on one regularly scheduled CRL issued beyond the
746 revoked PKC's validity period. Leaving the revoked PKC on the CRL for
747 this extra period allows for PKCs that are revoked prior to issuing a
748 new CRL and whose invalidity date falls before the CRL issuing time
749 to be accounted for. If the revoked PKC is not retained on the CRL
750 for this extra period then the possibility arises that a revoked PKC
751 may never appear on a CRL.
753 An advantage of the CRL revocation method is that CRLs may be
754 distributed by exactly the same means as PKCs themselves, namely, via
755 untrusted communications and server systems.
757 One limitation of the CRL revocation method, using untrusted
758 communications and servers, is that the time granularity of
759 revocation is limited to the CRL issue period. For example, if a
760 revocation is reported now, that revocation will not be reliably
761 notified to certificate-using systems until the next CRL is issued,
762 which may be up to one hour, one day, or one week depending on the
763 frequency that the CA issues CRLs.
765 As with the X.509 v3 PKC format, in order to facilitate interoperable
766 implementations from multiple vendors, the X.509 v2 CRL format needed
767 to be profiled for Internet use. This was done as part of the
768 Internet PKI Profile [FORMAT]. However, PKIX does not require CAs to
769 issue CRLs. On-line methods of revocation notification may be
770 applicable in some environments as an alternative to the X.509 CRL.
771 PKIX defines a few protocols that support on-line checking. [OCSP],
772 [DVCS], and [SCVP] all support on-line checking of the status of
773 PKCs.
775 On-line revocation checking may significantly reduce the latency
776 between a revocation report and the distribution of the information
777 to relying parties. Once the CA accepts the report as authentic and
778 valid, any query to the on-line service will correctly reflect the
779 PKC validation impacts of the revocation. However, these methods
780 impose new security requirements; the PKC validator must trust the
781 on-line validation service while the repository does not need to be
782 trusted.
784 2.4.9 Certificate & Revocation Notice Distribution & Publication
786 As alluded to in sections 2.1 and 2.5.8 above, the PKI is responsible
787 for the distribution of PKCs and PKC revocation notices (whether in
789 Arsenault, Turner 15
790 CRL form or in some other form) in the system. "Distribution" of PKCs
791 includes transmission of the PKC to its owner, and may also include
792 publication of the PKC in a repository. "Distribution" of revocation
793 notices may involve posting CRLs in a repository, transmitting them
794 to end-entities, or forwarding them to on-line responders.
796 3 PMI
798 3.1 Theory
800 Many systems use the PKC to perform identity based access control
801 decisions (i.e., the identity may be used to support identity-based
802 access control decisions after the client proves that it has access
803 to the private key that corresponds to the public key contained in
804 the PKC). For many systems this is sufficient, but increasingly
805 systems are beginning to find that rule-based and role-based access
806 control is required. These forms of access control decisions require
807 additional information that is normally not included in a PKC,
808 because the lifetime of the information is much shorter than the
809 lifetime of the public-private key pair. To support binding this
810 information to a PKC the Attribute Certificate (AC) was defined in
811 ANSI and later incorporated into ITU-T Recommendation X.509. The AC
812 format allows any additional information to be bound to a PKC by
813 including, in a digitally signed data structure, a reference back to
814 one specific PKC or to multiple PKCs, useful when the subject has the
815 same identity in multiple PKCs. Additionally, the AC can be
816 constructed in such a way that it is only useful at one or more
817 particular targets (e.g., web server, mail host).
819 Users of a PMI must be confident that the identity purporting to
820 posses an attribute has the right to possess that attribute. This
821 confidence may be obtained through the use of PKCs or it may be
822 configured in the AC-using system. If PKCs are used the party making
823 the access control decision can determine "if the AC issuer is
824 trusted to issue ACs containing this attribute."
826 ACs are complicated by the fact that they can point to an identity
827 which may be in more than one PKC. If the RP has multiple
828 certification chains to chose from then it has to make the
829 determination as to which certification path to trust. Regardless,
830 before the RP uses the AC it must make sure that a path from the AC
831 back to its trust point is valid.
833 3.2 Architectural Model
835 A Privilege Management Infrastructure, or PMI, is defined as:
837 The set of hardware, software, people, policies and procedures needed
838 to create, manage, store, distribute, and revoke ACs.
840 A PMI consists of five types of components [AC]:
842 Arsenault, Turner 16
843 - Attribute Authorities (AAs), or Attribute Certificate Issuer,
844 that issue and revoke ACs;
846 Note: AAs may implicitly revoke ACs by using very short validity
847 periods.
849 - Attribute Certificate Users that parses or processes an AC;
851 - Attribute Certificate Verifiers that check the validity of an AC
852 and then makes use of the result;
854 - Clients that request an action for which authorization checks are
855 to be made;
857 - Repositories that store and make available certificates and
858 Certificate Revocation Lists (CRLs).
860 Figure 2 is an example of the exchanges that may involve ACs.
862 +--------------+
863 | | Server Acquisition
864 | AC issuer +----------------------------+
865 | | |
866 +--+-----------+ |
867 | |
868 | Client |
869 | Acquisition |
870 | |
871 +--+-----------+ +--+------------+
872 | | AC "push" | |
873 | Client +-------------------------+ Server |
874 | | (part of app. protocol) | |
875 +--+-----------+ +--+------------+
876 | |
877 | Client | Server
878 | Lookup +--------------+ | Lookup
879 | | | |
880 +---------------+ Repository +---------+
881 | |
882 +--------------+
884 Figure 2: AC Exchanges
886 3.3 Attribute Certificates
888 ANSI X.9 first published the Attribute Certificate format. It defined
889 the standard version 1 (v1) AC format. They later created a version 2
890 (v2) AC by modifying the owner field to point to either an identity
891 or a specific PKC and including an extension mechanism. In 1997 ITU-T
892 included it in [X.509].
894 Arsenault, Turner 17
895 ANSI, ITU-T, and IETF have developed standard extensions and
896 attributes for use in the v2 ACs. Extensions can convey such
897 information as an audit identity that can be used to create an audit
898 trail, identity specific servers and services where the AC owner can
899 use their AC, point to a specific issuer's key, and indicate where to
900 get revocation information. The AC is generic enough to allow any
901 attribute to be conveyed in the data structure. Without limiting the
902 attributes and extensions that can be included in an AC it is very
903 difficult to develop interoperable implementations for Internet use.
904 It is the goal of PKIX to specify a profile for the Internet,
905 electronic mail, IPSec applications, etc. Environments with
906 additional requirements may build on this profile or replace it.
908 The [AC] profile constrains many of the options allowed in X.509. For
909 example, the AC chains, like their PKC brethren, are allowed by
910 X.509, but the AC profile recommends that they not be supported in to
911 simplify the implementation.
913 4 PKIX Documents
915 This section identifies the five different areas in which the PKIX
916 working group has developed documents. The first area involves
917 profiles of the X.509 v3 PKC standards and the X.509 v2 CRL standards
918 for the Internet. The second area involves operational protocols, in
919 which relying parties can obtain information such as PKCs or PKC
920 status. The third area covers management protocols, in which
921 different entities in the system exchange information needed for
922 proper management of the PKI. The fourth area provides information
923 about certificate policies and certificate practice statements,
924 covering the areas of PKI security not directly addressed in the rest
925 of PKIX. The fifth area deals with providing time stamping and data
926 certification services, which can be used to build such services as
927 non-repudiation.
929 4.1 Profiles
931 An X.509 v3 PKC is a very complex data structure. It consists of
932 basic information fields, plus a number of optional extensions. Many
933 of the fields and numerous extensions can take on a wide range of
934 options. This provides an enormous degree of flexibility, which
935 allows the X.509 v3 PKC format to be used with a wide range of
936 applications in a wide range of environments. Unfortunately, this
937 same flexibility makes it extremely difficult to produce independent
938 implementations that will actually interoperate with one another. In
939 order to build an Internet PKI based on X.509 v3 PKCs, the PKIX
940 working group had to develop a profile of the X.509 v3 PKC
941 specification.
943 A profile of the X.509 v3 PKC specification is a description of the
944 contents of the PKC and which extensions must be supported, which
945 extensions may be supported, and which extensions may not be
947 Arsenault, Turner 18
948 supported. The Internet PKI Profile [FORMAT] provides such a profile
949 of X.509 v3 PKC for the Internet PKI. In addition, the Internet PKI
950 Profile [FORMAT] suggests ranges of values for many of the
951 extensions.
953 The Internet PKI Profile [FORMAT] also provides a profile for Version
954 2 CRLs for use in the Internet PKI. CRLs, like PKCs, have a number of
955 optional extensions. In order to promote interoperability, it is
956 necessary to constrain the choices an implementor supports.
958 In addition to profiling the PKC and CRL formats, it is necessary to
959 define particular Object Identifiers (OIDs) for certain encryption
960 algorithms, because there are a variety of OIDs registered for some
961 algorithm suites. PKIX has produced two documents ([RPKDS] and [KEA])
962 which provide guidance on the proper implementation of specific
963 algorithms.
965 Some countries are in a process of updating their legal frameworks in
966 order to regulate and incorporate recognition of signatures in
967 electronic form. Many of these frameworks introduce certain basic
968 requirements on PKCs, often termed Qualified Certificates, supporting
969 these types of "legal" signatures. Partly as a result of this there
970 is a need for a specific PKC profile providing standardized support
971 for certain related issues such as a common structure for expressing
972 unambiguous identities of certified subjects (unmistakable identity).
973 In December 1998, PKIX adopted as a work item the development of a
974 refinement of [RFC2459] that further profiles PKIX PKC into qualified
975 certificates. This work is reflected in [QC].
977 Like the X.509 v3 PKC, the AC also a very complex data structure
978 consisting of basic information fields, a number of optional
979 extensions, and a virtually unlimited number of attributes. Again,
980 many of the fields, extensions, and attributes can take on a wide
981 range of options allowing an enormous degree of flexibility. In order
982 to build an Internet PMI based on ACs, the PKIX working group had to
983 develop a profile of the AC.
985 The AC profile is description of the contents of the AC, the allowed
986 and required extensions, and applicable attributes. [AC] provides
987 such a profile of the X.509 v2 AC.
989 - DOCUMENT TITLE: Internet X.509 Public Key Infrastructure
990 Certificate and CRL Profile (RFC2459) [FORMAT]
992 DESCRIPTION: This document describes the profiles to be used for
993 X.509 v3 PKCs and version 2 CRLs by Internet PKI participants. The
994 profiles include the identification of ISO/IEC/ITU and ANSI
995 extensions which may be useful in the Internet PKI. The profiles
996 are presented in the 1988 Abstract Syntax Notation One (ASN.1)
997 rather than the 1994 syntax used in the ISO/IEC/ITU standards.
998 Would-be PKIX implementors and developers of certificate-using
999 applications should start with the Internet PKI Profile [FORMAT] to
1001 Arsenault, Turner 19
1002 ensure that their systems will be able to interoperate with other
1003 users of the PKI.
1005 The Internet PKI Profile [FORMAT] also includes path validation
1006 procedures. The procedures presented are based upon the ISO/IEC/ITU
1007 definition, but the presentation assumes one or more self-signed
1008 trusted CA PKCs. The procedures are provided as examples only.
1009 Implementations are not required to use the procedures provided;
1010 they may implement whichever procedures are efficient for their
1011 situation. However, implementations are required to derive the same
1012 results as the example procedures.
1014 STATUS: Proposed Standard.
1016 - DOCUMENT TITLE: Internet X.509 Public Key Infrastructure
1017 Representation of Key Exchange Algorithm (KEA) Keys in Internet
1018 X.509 Public Key Infrastructure Certificates (RFC 2528) [KEA]
1020 DESCRIPTION: This document provides Object Identifiers (OIDs) and
1021 other guidance for IPKI users who use the Key Exchange Algorithm
1022 (KEA). It profiles the format and semantics of the
1023 subjectPublicKeyInfo field and the keyUsage extension in X.509 v3
1024 PKCs containing KEA keys. This document should be used by anyone
1025 wishing to support KEA; others who do not support ECDSA are not
1026 required to comply with it.
1028 STATUS: Informational RFC.
1030 - DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Qualified
1031 Certificates (RFC 3039) [QC]
1033 DESCRIPTION: This document profiles the format for and defines
1034 requirements on information content in a specific type of PKCs
1035 called Qualified Certificates. A "Qualified Certificate" is a PKC
1036 that is issued to a natural person (i.e., a living human being);
1037 contains an unmistakable identity based on a real name or a
1038 pseudonym of the subject; exclusively indicates non-repudiation as
1039 the key usage for the certificate's public key; and meets a number
1040 of requirements.
1042 STATUS: Proposed Standard.
1044 - DOCUMENT TITLE: An Internet Attribute Certificate Profile for
1045 Authorizations [AC]
1047 DESCRIPTION: This document profiles the format for an defines
1048 requirements on X.509 v2 ACs to support authorization services
1049 required by various Internet protocols (TLS, CMS, and the consumers
1050 of CMS, etc.). Two profiles are defined in support of basic
1051 authorizations and in support of services that can operate via
1052 proxy.
1054 Arsenault, Turner 20
1055 STATUS: Approved as Proposed Standard; in RFC editor's Queue.
1056 Issuance as an RFC blocked until the normative reference [2459bis]
1057 progresses to Proposed Standard as well. (See below.)
1059 - DOCUMENT TITLE: Internet X.509 Public Key Infrastructure
1060 Certificate and CRL Profile
1061 [2459bis]
1063 DESCRIPTION: This document is an update of the Internet PKI Profile
1064 [2459bis]. The treatment of path validation is enhanced, and
1065 additional specificity is offered for various certificate and CRL
1066 extensions. This document omits the encoding and identification of
1067 public keys and digital signatures. (See [RPKDS] below.)
1069 STATUS: Tentatively approved by IESG.
1071 - DOCUMENT TITLE: Algorithms and Identifiers for the Internet X.509
1072 Public Key Infrastructure Certificate and CRL Profile [RPKDS]
1075 DESCRIPTION: This document specifies algorithm identifiers and
1076 encoding formats for the representation of cryptographic algorithms
1077 keys, associated parameters, and digital signatures in Internet PKI
1078 and X.509 certificates and certificate revocation lists. This draft
1079 does not attempt to define the cryptographic algorithms themselves.
1080 It instead references other appropriate standards. This draft
1081 incorporates information from Section 7 of RFC 2459 and the
1082 Internet-Draft "Representation of Elliptic Curve Digital Signature
1083 Algorithm (ECDSA) Keys in Internet X.509 Public Infrastructure
1084 Certificates."
1086 STATUS: Tentatively approved by IESG.
1088 - DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Permanent
1089 Identifier [PI]
1091 DESCRIPTION: This document defines a new form of name, the
1092 permanent identifier, which is a name assigned by an organization,
1093 unique within that organization, that singles out a particular
1094 entity from all other individuals. The permanent identifier is an
1095 optional feature that may be used by a CA to indicate that the
1096 certificate relates to the same individual even if the name or the
1097 affiliation of that entity has changed. The permanent identifier is
1098 important in the context of access control and of non-repudiation.
1100 STATUS: Under AD review.
1102 - DOCUMENT TITLE: Supplemental Algorithms and Identifiers for the
1103 Internet X.509 Public Key Infrastructure Certificate and CRL
1104 Profile [SUPPALGS]
1106 DESCRIPTION: This document supplements [RPKDS], defining specifies
1107 algorithm identifiers and encoding formats for the representation
1109 Arsenault, Turner 21
1110 of emerging cryptographic algorithms and associated keys. The
1111 document encompasses lattice-based public key algorithms as well as
1112 digital signatures using larger hash algorithms (e.g., SHA-256).
1114 STATUS: Under WG review.
1116 - DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Logotypes
1117 in X.509 Certificate [LOGO]
1119 DESCRIPTION: This document specifies a certificate extension for
1120 including logotypes in public key certificates and attribute
1121 certificates.
1123 STATUS: Under WG review.
1125 - DOCUMENT TITLE: X.509 Extensions for IP Addresses and AS
1126 Identifiers [IPEXT]
1128 DESCRIPTION: This document specifies a certificate extension for
1129 including logotypes in public key certificates and attribute
1130 certificates.
1132 STATUS: Under WG review.
1134 - DOCUMENT TITLE: Warranty Certificate Extension [WARR]
1137 DESCRIPTION: This document describes a certificate extension to
1138 explicitly state the warranty offered by a Certificate Authority
1139 (CA) for the certificate containing the extension.
1141 STATUS: Under WG review.
1143 4.2 Operational Protocols
1145 Operational protocols are required to deliver certificates and CRLs
1146 (or other certificate status information) to certificate using
1147 systems. Provision is needed for a variety of different means of
1148 certificate and CRL delivery, including distribution procedures based
1149 on DNS, LDAP, HTTP, FTP, and X.500. A limited protocol to support AC
1150 retrieval has also been documented.
1152 - DOCUMENT TITLE: Internet X.509 Public Key Infrastructure
1153 Operational Protocols - LDAPv2 (RFC 2559) [PKI-LDAPv2]
1155 DESCRIPTION: This document describes the use of LDAPv2 as a
1156 protocol for PKI elements to publish and retrieve certificates and
1157 CRLs from a repository. [LDAPv2] is a protocol that allows
1158 publishing and retrieving of information.
1160 STATUS: Proposed Standard.
1162 Arsenault, Turner 22
1163 - DOCUMENT TITLE: Internet X.509 Public Key Infrastructure LDAPv2
1164 Schema (RFC 2587) [SCHEMA]
1166 DESCRIPTION: This document defines a minimal schema necessary to
1167 support the use of LDAPv2 for PKC and CRL retrieval and related
1168 functions for PKIX. This document supplements [LDAPv2] by
1169 identifying the PKIX-related attributes that must be present.
1171 STATUS: Proposed Standard.
1173 - DOCUMENT TITLE: X.509 Internet Public Key Infrastructure Online
1174 Certificate Status Protocol - OCSP (RFC 2560) [OCSP]
1176 DESCRIPTION: This document specifies a protocol useful in
1177 determining the current status of a certificate without the use of
1178 CRLs. A major complaint about certificate-based systems is the need
1179 for a relying party to retrieve a current CRL as part of the
1180 certificate validation process. Depending on the size of the CRL,
1181 this can cause severe problems for bandwidth-challenged devices.
1182 Depending on the frequency of CRL issuance, this can also cause
1183 timeliness problems. (E.g., if CRLs are only published weekly, with
1184 no interim releases, a certificate could actually have been revoked
1185 for just short of one week without it being on the current CRL, and
1186 thus improper use of that certificate could still be occurring.)
1188 OCSP attempts to address those problems. It provides a mechanism
1189 whereby a relying party identifies one or more certificates to an
1190 approved OCSP "responder", and the responder sends back the current
1191 status of the certificate(s) - e.g., "revoked", "notRevoked",
1192 "unknown". This can dramatically reduce the bandwidth required to
1193 transmit revocation status - a relying party does not have to
1194 retrieve a CRL of many entries to check the status of one
1195 certificate. It can (although it is not guaranteed to) improve the
1196 timeliness of revocation notification, and thus reduce the window
1197 of opportunity for someone trying to use a revoked certificate.
1199 STATUS: Proposed Standard.
1201 - DOCUMENT TITLE: Internet X.509 Public Key Infrastructure
1202 Operational Protocols: FTP and HTTP (RFC 2585) [FTPHTTP]
1204 DESCRIPTION: This document describes the use of the File Transfer
1205 Protocol (FTP) and the Hyper-text Transfer Protocol (HTTP) to
1206 obtain certificates and CRLs from PKI repositories.
1208 STATUS: Proposed Standard.
1210 - DOCUMENT TITLE: Diffie-Hellman Proof-of-Possession Algorithms (RFC
1211 2875) [DHPOP]
1213 DESCRIPTION: It allows Diffie-Hellman, a key agreement algorithm,
1214 to be used instead of requiring that the public key being requested
1215 for certification correspond to an algorithm that is capable of
1217 Arsenault, Turner 23
1218 signing and encrypting. The first algorithm generates a signature
1219 for a specific verifier where the signer and recipient have the
1220 same public key parameters. The second algorithm generates a
1221 signature for arbitrary verifiers where the signer and recipient do
1222 not have the same public key parameters.
1224 STATUS: Proposed Standard.
1226 - DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Additional
1227 Schema for PKIs and PMIs
1228 [ADDSCHEMA]
1230 DESCRIPTION: This document describes the Lightweight Directory
1231 Access Protocol (LDAP) schema features that, in addition to RFC
1232 2587, are needed to support a Privilege Management Infrastructure
1233 and a Public Key Infrastructure. It also describes the schema for
1234 the storage and matching of attribute certificates and revocation
1235 lists in an LDAP directory server. This Internet Draft supplements,
1236 rather than revokes, the contents of RFC 2587.
1238 STATUS: Under WG review.
1240 - DOCUMENT TITLE: Delegated Path Validation and Delegated Path
1241 Discovery Protocol Requirements (DPV&DPD-REQ) [DPREQ]
1244 DESCRIPTION: This document specifies requirements for two
1245 request/response pairs. The first, called Delegated Path Validation
1246 (DPV), can be used to fully delegate a path validation processing
1247 to an DPV server. The second, called Delegated Path Discovery
1248 (DPD), can be used to delegate development of a path, including
1249 certificate status information, to a DPD server.
1251 STATUS: Under WG review.
1253 - DOCUMENT TITLE: Simple Certificate Validation Protocol (SCVP)
1254 [SCVP]
1256 DESCRIPTION: The SCVP protocol allows a client to offload
1257 certificate handling to a server. The server can give a variety of
1258 valuable information about the certificate, such as whether or not
1259 the certificate is valid, a chain to a trusted root, and so on.
1261 STATUS: Under WG review.
1263 - DOCUMENT TITLE: Internet X.509 Public Key Infrastructure
1264 Operational Protocols - LDAPv3
1265 [PKI-LDAPv3]
1267 DESCRIPTION: This document describes the features of the
1268 Lightweight Directory Access Protocol (LDAP) v3 that are needed in
1269 order to support a public key infrastructure based on x.509
1270 certificates and certificate revocation lists. Because LDAPv2 has a
1272 Arsenault, Turner 24
1273 number of deficiencies that may limit its usefulness in certain
1274 circumstances, the IETF has ceased its standardization and replaced
1275 it with LDAPv3. This document describes the features of LDAPv3 that
1276 are necessary, not required, or are optional for servers to support
1277 a PKI based on X.509.
1279 STATUS: Under WG Review.
1281 4.3 Management Protocols
1283 Management protocols are required to support on-line interactions
1284 between PKI user and management entities. For example, a management
1285 protocol might be used between a CA and a client system with which a
1286 key pair is associated, or between two CAs which cross-certify each
1287 other. A management protocol can be used to carry user or client
1288 system registration information, or a request for revocation of a
1289 certificate.
1291 There are two parts to a "management protocol." The first is the
1292 format of the messages that will be sent, and the second is the
1293 actual protocol that governs the transmission of those messages.
1294 Originally, the PKIX working group developed two documents, [CRMF]
1295 and certificate management message format (CMMF), that together
1296 described the necessary set of message formats, and two other
1297 documents, [CMP] and [CMC], that described protocols for exchanging
1298 those messages. However, the message formats defined in the CMMF
1299 draft were inserted into both [CMP] and [CMC], and thus the (CMMF)
1300 draft has been dropped as a PKIX document.
1302 - DOCUMENT TITLE: Certificate Management Messages over CMS (RFC 2797)
1303 [CMC]
1305 DESCRIPTION: This document defines the means by which PKI clients
1306 and servers may exchange PKI messages when using S/MIME's
1307 Cryptographic Message Syntax [CMS] as a transaction envelope. CMC
1308 supports the certificate request message body specified in the
1309 Certificate Request Message Format [CRMF] documents, as well as a
1310 variety of other certificate management messages. The primary
1311 purpose of this specification is to allow the use of an existing
1312 protocol (S/MIME) as a PKI management protocol, without requiring
1313 the development of an entirely new protocol such as CMP. A
1314 secondary purpose is to codify in IETF standards the current
1315 industry practice of using PKCS-10 messages [PKCS10] for
1316 certificate requests.
1318 STATUS: Proposed Standard.
1320 - DOCUMENT TITLE: Internet X.509 Certificate Request Message Format
1321 (RFC 2511) [CRMF]
1323 DESCRIPTION: CRMF specifies a format recommended for use whenever a
1324 relying party is requesting a certificate from a CA or requesting
1326 Arsenault, Turner 25
1327 that an RA help it get a certificate. The request message format
1328 was needed before many of the other message formats had to be
1329 finalized, and so it was put into a separate document. This
1330 document only specifies the format of a message. Specification of a
1331 protocol to transport that message is beyond the scope of CRMF.
1333 STATUS: Proposed Standard.
1335 - DOCUMENT TITLE: Internet X.509 Public Key Infrastructure
1336 Certificate Management Protocols (RFC 2510) [CMP]
1338 DESCRIPTION: This document specifies a new protocol specifically
1339 developed for the purpose of transporting messages like those
1340 specified in CRMF among PKI elements. In general, CMP will be used
1341 in conjunction with CRMF, and will then be run over a transfer
1342 service (e.g., S/MIME, HTTP) to provide a complete PKI management
1343 service.
1345 STATUS: Proposed Standard.
1347 - DOCUMENT TITLE: Certificate Request Message Format [2511bis]
1350 DESCRIPTION: This document is an update of [CRMF] and reflects the
1351 results of interoperability testing.
1353 STATUS: Awaiting documentation of Interoperability Testing results.
1355 - DOCUMENT TITLE: Certificate Management Protocols [2510bis]
1358 DESCRIPTION: This document is an update of [CMP] and reflects the
1359 results of interoperability testing. The document omits the
1360 transport protocols found in [CMP] which are addressed in [CMPT].
1361 (See below).
1363 STATUS: Awaiting documentation of Interoperability Testing results.
1365 - DOCUMENT TITLE: Transport Protocols for CMP [TPCMP]
1368 DESCRIPTION: This document describes how to layer Certificate
1369 Management Protocols (CMP) over various transport protocols. In
1370 Section 5 of RFC 2510, the process of sending DER-encoded CMP
1371 messages directly over various protocols is specified. Implementers
1372 found that the protocol was lacking in several regards. This
1373 document is an effort to enhance the protocol now in order to avoid
1374 interoperability conflicts later and to make the transport section
1375 a separate draft.
1377 STATUS: Under WG review.
1379 Arsenault, Turner 26
1380 - DOCUMENT TITLE: Certificate Management Messages over CMS [2797bis]
1383 DESCRIPTION: This document is an update to [CMC].
1385 STATUS: Under WG review.
1387 - DOCUMENT TITLE: CMC Transport
1388 [TPCMC]
1390 DESCRIPTION: This document defines a number of transport mechanisms
1391 that are used to move [CMC] messages. The transport mechanisms
1392 described in the document are: HTTP, file, mail and TCP.
1394 STATUS: Under WG review.
1396 - DOCUMENT TITLE: CMC Extensions: Server Side Key Generation and Key
1397 Archival [SSKGKA]
1399 DESCRIPTION: This document defines a set of extensions to [CMC]
1400 that address the desire for having two additional services:
1401 Server generation of keys, and server-side archival and subsequent
1402 recovery of key material by the server. These services are
1403 provided by the definition of additional control statements within
1404 the CMC architecture.
1406 STATUS: Under WG review.
1408 - DOCUMENT TITLE: Attribute Certificate Request Message Format
1409 [ACRMF]
1411 DESCRIPTION: The Certificate Request Message Format ([CRMF])
1412 specifies a format for requesting an X.509 public key certificate
1413 from a Certification Authority (CA), possibly with assistance from
1414 an Local Registration Authority (LRA). This specification, ACRMF,
1415 is modeled on CRMF, extending similar functionality to requests
1416 for X.509 attribute certificates from Attribute Authorities (AA),
1417 possibly via an Attribute Registration Authority (ARA).
1419 STATUS: Under WG review.
1421 - DOCUMENT TITLE: Attribute Certificate Management Messages over CMS
1422 [ACMC]
1424 DESCRIPTION: This document specifies modifications to the
1425 Certificate Management Messages over CMS specification ([CMCbis])
1426 to permit the management of attribute certificates. This document
1427 does not stand alone, but must be used in conjunction with
1428 [CMCbis]. It is expected that the modifications proposed here
1429 will also be used in conjunction with the Attribute Certificate
1430 Request Message Format specification ([ACRMF]).
1432 STATUS: Under WG review.
1434 Arsenault, Turner 27
1435 4.4 Policy Outline
1437 As mentioned before, profiling certificates and specifying
1438 operational and management protocols only addresses a part of the
1439 problem of actually developing and implementing a secure PKI. What is
1440 also needed is the development of a certificate policy (CP) and
1441 certification practice statement (CPS), and then following those
1442 documents. The CP and CPS should address physical and personnel
1443 security, subject identification requirements, revocation policy, and
1444 a number of other topics. [POLPROC] provides a framework for
1445 certification practice statements.
1447 - DOCUMENT TITLE: Internet X.509 Public Key Infrastructure
1448 Certificate Policy and Certification Practices Framework (RFC
1449 2527) [POLPRAC]
1451 DESCRIPTION: As noted before, the specification and implementation
1452 of certificate profiles, operational protocols, and management
1453 protocols is only part of building a PKI. Equally as important - if
1454 not more important - is the development and enforcement of a
1455 certificate security policy, and a Certification Practice Statement
1456 (CPS). The purpose of this document (PKIX-4) is to establish a
1457 clear relationship between certificate policies and CPSs, and to
1458 present a framework to assist the writers of certificate policies
1459 or CPSs with their tasks. In particular, the framework identifies
1460 the elements that may need to be considered in formulating a
1461 certificate policy or a CPS. The purpose is not to define
1462 particular certificate policies or CPSs, per se.
1464 STATUS: Informational RFC.
1466 - DOCUMENT TITLE: Internet X.509 Public Key Infrastructure
1467 Certificate Policy and Certification Practices Framework
1470 DESCRIPTION: This specification is an update to RFC 2527. As above,
1471 the purpose of this document is to establish a clear relationship
1472 between certificate policies and CPSs, and to present a framework
1473 to assist the writers of certificate policies or CPSs with their
1474 tasks. The framework specified in this documents is basically a
1475 superset of the framework specified in RFC 2527.
1477 STATUS: Under WG Review.
1479 4.4 Time Stamping and Data Certification
1481 In late 1998, the PKIX working group began two efforts that were not
1482 in the original working group charter, but were deemed to be
1483 appropriate because they described infrastructure services that could
1484 be used to provide desired security services. The first of these is
1486 Arsenault, Turner 28
1487 time stamping, described in [TSP]. Time stamping is a service in
1488 which a trusted third party - a Time Stamp Authority, or TSA - signs
1489 a message, in order to provide evidence that it existed prior to a
1490 given time. Time stamping provides some support for non- repudiation,
1491 in that a user cannot claim that a transaction was later forged after
1492 compromise of a private key, because the existence of the signed time
1493 stamp indicates that the transaction in question could not have been
1494 created after the indicated time.
1496 [TSP] also defines the role of a Temporal Data Authority, or TDA. A
1497 TDA is a Trusted Third Party (TTP) that creates a temporal data
1498 token. This temporal data token associates a message with a
1499 particular event and provides supplementary evidence for the time
1500 included in the time stamp token. For example, a TDA could associate
1501 the message with the most recent closing value of the Dow Jones
1502 Average. The temporal data with which the message is associated
1503 should be unpredictable in order to prevent forward dating of tokens.
1504 The third iteration of the draft removed support for TDAs as no one
1505 in the WG expressed a requirement for the role.
1507 At the Minneapolis IETF meeting (IETF 44), it was disclosed that the
1508 materials covered in [TSP] draft may be covered by patent(s). Use of
1509 the material covered by the patent(s) in question has not be granted
1510 by the patent holder. Thus, anyone interested in implementing the
1511 PKIX [TSP] draft must be aware of this intellectual property issue.
1513 The second new effort is the definition of a Data Validation and
1514 Certification Server, or DVCS, protocol [DVCS]. A DVCS is a Trusted
1515 Third Party that verifies the correctness of specific data submitted
1516 to it. It also allows the delegation of trustworthy servers and
1517 allows for chaining of verifications.
1519 This services offered by DVCS are different from the TSP service in
1520 that a TSA will not attempt to parse or verify a message sent to it
1521 for certification; instead, it will merely append a reliable
1522 indication of the current time, and sign the resulting string-of-
1523 bits. This offers an indication that the given string-of-bits existed
1524 at a specified time; it does not offer any indication of the
1525 correctness or relevance of that string of bits. By contrast, the
1526 DVCS certifies possession of data or the validity of another entity's
1527 signature. As part of this, the DVCS verifies the mathematical
1528 correctness of the actual signature value contained in the request
1529 and also checks the full certification path from the signing entity
1530 to a trusted point (e.g., the DVCS's CA, or the Root CA in a
1531 hierarchy).
1533 The DVCS supports non-repudiation in two ways. First, it provides
1534 evidence that a signature or PKC was valid at the time indicated in
1535 the token. The token can be used even after the corresponding PKC
1536 expires and its revocation information is no longer available on CRLs
1537 (for example). Second, the production of a data certification token
1538 in response to a signed request for certification of another
1540 Arsenault, Turner 29
1541 signature or PKC also provides evidence that due diligence was
1542 performed by the requester in validating the signature or PKC.
1544 The concept of a delegated signature validation server was introduced
1545 in [DSV] as an analog to the delegated path validation server. A DSV
1546 services permits the relying party to prove they validated a
1547 digitally signed object, including the certification path, at a
1548 particular time.
1550 - DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Time Stamp
1551 Protocols (RFC 3161) [TSP]
1553 DESCRIPTION: This document defines the specification for a time
1554 stamp service. It defines a Time Stamp Authority, or TSA, a trusted
1555 third party who maintains a reliable time service. When the TSA
1556 receives a time stamp request, it appends the current time to the
1557 request and signs it into a token to certify that the original
1558 request existed prior to the indicated time. This helps provide
1559 non- repudiation by preventing someone (either a legitimate user or
1560 an attacker who has successfully compromised a key) from "back-
1561 dating" a transaction. It also makes it more difficult to challenge
1562 a transaction by asserting that it has been back-dated. Note that
1563 the TSA does not provide any data parsing service; that is, the TSA
1564 does not attempt to validate that which it signs; it merely regards
1565 it as a string of bits whose meaning is unimportant, but existence
1566 is vital.
1568 STATUS: Proposed Standard.
1570 - DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Data
1571 Certification Server Protocols (RFC 3029) [DVCS]
1573 DESCRIPTION: This document describes a general Data Validation and
1574 Certification Server (DVCS) and the protocols to be used when
1575 communicating with it. The Data Validation and Certification
1576 Server is a Trusted Third Party (TTP) that can be used as one
1577 component in building reliable non-repudiation services.
1579 Useful Data Validation and Certification Server responsibilities
1580 in a PKI are to assert the validity of signed documents, public
1581 key certificates, and the possession or existence of data.
1583 As a result of the validation, a DVCS generates a Data Validation
1584 Certificate (DVC). The data validation certificate can be used
1585 for constructing evidence of non-repudiation relating to the
1586 validity and correctness of an entity's claim to possess data, the
1587 validity and revocation status of an entity's public key
1588 certificate and the validity and correctness of a digitally signed
1589 document.
1591 The presence of a data validation certificate supports non-
1592 repudiation by providing evidence that a digitally signed document
1594 Arsenault, Turner 30
1595 or public key certificate was valid at the time indicated in the
1596 DVC.
1598 A DVC validating a public key certificate can for example be used
1599 even after the public key certificate expires and its revocation
1600 information is no longer or not easily available. Determining the
1601 validity of a DVC is assumed to be a simpler task, for example, if
1602 the population of DVCS is significantly smaller than the
1603 population of public key certificate owners.
1605 The production of a data validation certificate in response to a
1606 signed request for validation of a signed document or public key
1607 certificate also provides evidence that due diligence was
1608 performed by the requester in validating a digital signature or
1609 public key certificate.
1611 STATUS: Experimental RFC.
1613 - DOCUMENT TITLE: Delegated Signature Validation Protocol
1614 Requirements (DSV-REQ)
1616 DESCRIPTION: This document specifies requirements to fully delegate
1617 the validation of a digital signature to a DSV (Delegated Signature
1618 Validation) server. The validation is performed using a set of
1619 rules, called a signature policy.
1621 It also defines the requirements for two optional request/response
1622 pairs, either for allowing to indicate to a signature validation
1623 server a signature policy, or giving the reference of a signature
1624 policy to obtain the details of an already defined signature
1625 policy.
1627 STATUS: Under WG review.
1629 - DOCUMENT TITLE: Policy Requirements for Time-Stamp Authorities
1630
1632 DESCRIPTION: This document specifies policy requirements relating
1633 to the operation of Time-stamping Authorities (TSAs). It defines
1634 policy requirements on the operation and management practices of
1635 TSAs such that subscribers and relying parties may have confidence
1636 in the operation of the time-stamping services.
1638 The contents of this Informational RFC is technically equivalent
1639 to ETSI TS 102 023 V1.1.1 (2002-01) [TS 102023]. The ETSI TS is
1640 under the ETSI Copyright (C). Individual copies of this ETSI
1641 deliverable can be downloaded from http://www.etsi.org.
1643 STATUS: Under WG review.
1645 Arsenault, Turner 31
1646 4.5 Expired Drafts
1648 There have been numerous drafts that have been produced by the
1649 working group that for some reason or another did not make it to RFC
1650 status. The following is a list of these drafts.
1652 - DOCUMENT TITLE: Internet X.509 Public Key Infrastructure
1653 Certificate Management Message Formats
1655 DESCRIPTION: This document contained the formats for a series of
1656 messages important in certificate and PKI management. These
1657 messages let CA's, RA's, and relying parties communicate with each
1658 other. Note that this document only specified message formats; it
1659 did not specify a protocol for transferring messages. That protocol
1660 could have be either CMP or CMC, or perhaps another custom
1661 protocol.
1663 STATUS: Work has been discontinued. All useful information from it
1664 has been moved into [CMP] and [CMC].
1666 - DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Enhanced
1667 CRL Distribution Options (OpenCDP)
1669 DESCRIPTION: This document proposed an alternative to the CRL
1670 Distribution Point (CDP) approach documented in the Internet PKI
1671 Profile [FORMAT]. OCDP separates the CRL location function from the
1672 process of certificate and CRL validation, and thus claimed some
1673 benefits over the CDP approach.
1675 STATUS: Work has been discontinued, as all useful information has
1676 been incorporated into [X.509]. An updated the Internet PKI Profile
1677 [2459bis] RFC should profile the use of the CDP approach.
1679 - DOCUMENT TITLE: Internet Public Key Infrastructure: Caching the
1680 Online Certificate Status Protocol
1682 DESCRIPTION: To improve the degree to which it can scale, OCSP
1683 allows caching of responses - e.g., at intermediary servers, or
1684 even at the relying party's end system. This document described how
1685 to support OCSP caching at intermediary servers.
1687 STATUS: Work has been discontinued.
1689 - DOCUMENT TITLE: WEB based Certificate Access Protocol-- WebCAP/1.0
1691 DESCRIPTION: This document specified a set of methods, headers, and
1692 content-types ancillary to HTTP/1.1 to publish, retrieve X.509 PKCs
1693 and Certificate Revocation Lists. This protocol also facilitated
1694 determining current status of a digital certificate without the use
1695 of CRLs. This protocol defined new methods, request and response
1696 bodies, error codes to HTTP/1.1 protocol for securely publishing,
1697 retrieving, and validating certificates across a firewall.
1699 Arsenault, Turner 32
1700 STATUS: Expired.
1702 - DOCUMENT TITLE: Basic Event Representation Token
1704 DESCRIPTION: This document defined a finite method of representing
1705 a discrete instant in time as a referable event. The Basic Event
1706 Representation Token (BERT) was a lightweight binary token designed
1707 for use in large numbers over short periods of time. The tokens
1708 contained only a single instance of an event stamp and the trust
1709 process is referenced against an external reference.
1711 STATUS: Expired.
1713 - DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Extending
1714 trust in non repudiation tokens in time
1716 DESCRIPTION: This document described a method to maintain the trust
1717 in a token issued by a non-repudiation Trusted Third Party (NR TTP)
1718 (DVCS/TSA/TDA) after the key initially used to establish trust in
1719 the token expires. The document described a general format for
1720 storage of DVCS/TS/TDA tokens for this purpose, which establishes a
1721 chain of custody for the data.
1723 STATUS: Expired.
1725 - DOCUMENT TITLE: Internet X.509 Public Key Infrastructure
1726 Representation of Elliptic Curve Digital Signature Algorithm
1727 (ECDSA) Keys and Signatures in Internet X.509 Public Key
1728 Infrastructure Certificates
1730 DESCRIPTION: This document provided Object Identifiers (OIDs) and
1731 other guidance for IPKI users who use the Elliptic Curve Digital
1732 Signature Algorithm (ECDSA). It profiled the format and semantics
1733 of the subjectPublicKeyInfo field and the keyUsage extension in
1734 X.509 v3 PKCs containing ECDSA keys. This document should have been
1735 used by anyone wishing to support ECDSA; others who do not support
1736 ECDSA are not required to comply with it.
1738 STATUS: Finished WG Last Call. Merged into Representation of Public
1739 Keys and Digital Signatures in Internet X.509 Public Key
1740 Infrastructure Certificates.
1742 - DOCUMENT TITLE: A String Representation of General Name
1744 DESCRIPTION: This document specified a string format for the ASN.1
1745 construct GeneralName.
1747 STATUS: Expired.
1749 - DOCUMENT TITLE: OCSP Extensions
1751 DESCRIPTION: This document defined Internet-standard extensions to
1752 OCSP that enable a client to delegate processing of certificate
1754 Arsenault, Turner 33
1755 acceptance functions to a trusted server. The client could control
1756 the degree to which delegation takes place. In addition limited
1757 support was provided for delegating authorization decisions.
1759 STATUS: The work has been incorporated into [DPV] and [DPD].
1761 - DOCUMENT TITLE: Using HTTP as a Transport Protocol for CMP
1763 DESCRIPTION: This document described how to layer [CMP] over
1764 [HTTP]. A simple method for doing so was described in [CMP], but
1765 that method does not accommodate a polling mechanism, which may be
1766 required in some environments. This document specified an
1767 alternative method that used the polling protocol defined in [CMP].
1768 A new Content-Type for messages was also defined.
1770 STATUS: The work has been merged into [TPCMP].
1772 - DOCUMENT TITLE: Using TCP as a Transport Protocol for CMP
1774 DESCRIPTION: This document described how to layer Certificate
1775 Management Protocols [CMP] over [TCP]. A method for doing so is
1776 described in [CMP], but that method did not solve problems
1777 encountered by implementors. This document specified an enhanced
1778 method which extends the protocol.
1780 STATUS: The work has been merged into [TPCMP].
1782 - DOCUMENT TITLE: Delegated Path Validation
1784 DESCRIPTION: This specification builds on the Online Certificate
1785 Status Protocol (OCSP) framework's extensibility by defining an
1786 Internet-standard extension to OCSP that can be used to fully
1787 delegate all path validation processing to an OCSP server. The
1788 Delegated Path Validation (DVP) extension to OCSP described in this
1789 document accomplishes the task of locating the certificate
1790 validation process within a trusted server. This in turn reduces
1791 the technical footprint of certificate-using applications and may
1792 ease the integration of certificate path processing with other
1793 authorized data.
1795 STATUS: Expired.
1797 - DOCUMENT TITLE: Delegated Path Discovery with OCSP
1799 DESCRIPTION: This document establishes an Internet-standard
1800 extension that enables relying-party software to acquire
1801 certification path data from an OCSP server rather than replicate
1802 the same functionality. This Delegated Path Discovery (DPD)
1803 extension delegates the acquisition process to a separate server,
1804 thereby greatly simplifying and reducing the size of public key
1805 based credential validation systems or other relying party
1806 software. The DPD extension also enables such software to select
1808 Arsenault, Turner 34
1809 from among various trust paths in the event of the existence of
1810 multiple paths.
1812 STATUS: Expired.
1814 - DOCUMENT TITLE: Online Certificate Status Protocol, Version 2
1816 DESCRIPTION: This document is an update to RFC 2560.
1818 STATUS: Expired.
1820 - DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Repository
1821 Locator Service
1823 DESCRIPTION: This document defines a PKI repository locator
1824 service, which enable certificate-using systems to locate PKI
1825 repositories based on a domain name, to identify the protocols that
1826 can be used to access the repository, and obtain addresses for the
1827 servers that host the repository service. The Internet Draft
1828 defines SRV records for a PKI repository locator service to enable
1829 PKI clients to obtain necessary information to connect to a
1830 domain's repository. It also includes the definition of a SRV RR
1831 format for this service.
1833 STATUS: Expired.
1835 - DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Technical
1836 Requirements for a non-Repudiation Service
1838 DESCRIPTION: This document describes those features of a service
1839 which processes signed documents which must be present in order for
1840 that service to constitute a "technical non-repudiation" service. A
1841 technical non-repudiation service must permit an independent
1842 verifier to determine whether a given signature was applied to a
1843 given data object by the private key associated with a given valid
1844 certificate, at a time later than the signature. The features of a
1845 technical non-repudiation service are expected to be necessary for
1846 a full non-repudiation service, although they may not be
1847 sufficient.
1849 This document is intended to clarify the definition of the "non-
1850 repudiation" service in RFC 2459. It should thus serve as a guide
1851 to when the nonRepudiation bit of the keyUsage extension should be
1852 set and to when a Certificate Authority is required to archive
1853 CRL's.
1855 STATUS: Expired.
1857 - DOCUMENT TITLE: Limited Attribute Certificate Acquisition Protocol
1858
1860 DESCRIPTION: This document specifies a deliberately limited
1861 protocol for requesting ACs from a server. It is intended to be
1863 Arsenault, Turner 35
1864 complementary to the use of LDAP for AC retrieval, covering those
1865 cases where use of an LDAP server is not suitable due to the type
1866 of authorization model being employed.
1868 STATUS: Expired.
1870 5 Implementation Advice
1872 This section provides guidance to those who would implement various
1873 parts of the PKIX suite of documents. The topics discussed in this
1874 section engendered significant discussion in the working group, and
1875 there, was at times, either widespread disagreement or widespread
1876 misunderstanding of them. Thus, this discussion is provided to help
1877 readers of the PKIX document set understand these issues, in the hope
1878 of fostering greater interoperability among eventual PKIX
1879 implementations.
1881 5.1 Names
1883 PKIX has been referred to as a "name-centric" PKI because the PKCs
1884 associate public keys with names of entities. Each PKC contains at
1885 least one name for the owner of a particular public key. The name can
1886 be an X.500 distinguished name, contained in the subjectDN field of
1887 the PKC. There can also be names such as RFC822 e-mail addresses, DNS
1888 domain names, and uniform resource identifiers (URIs) associated with
1889 the key; these attributes are kept in the subjectAltName extension of
1890 the PKC. A PKC must contain at least one of these name forms, it may
1891 contain multiple forms if deemed appropriate by the CA based on the
1892 intended usage of the PKC.
1894 5.1.1 Name Forms
1896 There are two possible places to put a name in an X.509 v3 PKC. One
1897 is the subject field in the base PKC (often called the "Distinguished
1898 Name" or "DN" field), and the other is in the subjectAltName
1899 extension.
1901 5.1.1.1 Distinguished Names
1903 According to the Internet PKI Profile [2459bis], a CA's PKC must have
1904 a non-null value in the subject field, while EE's PKCs are permitted
1905 to have an empty subject field. If a PKC has a non-null subject
1906 field, it must contain an X.500 Distinguished Name.
1908 Arsenault, Turner 36
1909 5.1.1.2 SubjectAltName Forms
1911 In addition to the DN, a PKIX PKC may have one or more values in the
1912 subjectAltName extension.
1914 The subjectAltName extension allows additional identities to be bound
1915 to the subject of the PKC (e.g., it allows "umbc.edu" and
1916 "130.85.1.3" to be associated with a particular subject, as well as
1917 "C=US, O=University of Maryland, L=Baltimore, CN=UMBC"). X.509-
1918 defined options for this extension include: Internet electronic mail
1919 addresses; DNS names; IP addresses; and URIs. Other options can
1920 exist, including locally-defined name forms.
1922 A single subjectAltName extension can include multiple name forms,
1923 and multiple instances of each name form.
1925 Whenever such alternate name forms are to be bound into a PKC, the
1926 subjectAltName (or issuerAltName) extension must be used. It is
1927 technically possible to embed an alternate name form in the subject
1928 field. For example, one could make a DN contain an IP address via a
1929 kludge such as "C=US, L=Baltimore, CN=130.85.1.3". However, this
1930 usage is deprecated; the alternative name extension is the preferred
1931 location for finding such information. As another example, some
1932 legacy implementations exist where an RFC822 name is embedded in the
1933 subject distinguished name as an EmailAddress attribute. Per Internet
1934 Profile [2459bis], PKIX-compliant implementations generating new PKCs
1935 with electronic mail addresses must use the rfc822Name in the
1936 subjectAltName extension to describe such EEs. Simultaneous inclusion
1937 of the EmailAddress attribute in the subject distinguished name to
1938 support legacy implementation is deprecated but permitted.
1940 In line with this, if the only subject identity included in a PKC is
1941 an alternative name form, then the subject distinguished name must be
1942 empty (technically, an empty sequence), and the subjectAltName
1943 extension must be present. If the subject field contains an empty
1944 sequence, the subjectAltName extension must be marked critical.
1946 If the subjectAltName extension is present, the sequence must contain
1947 at least one entry. Unlike the subject field, conforming CAs shall
1948 not issue PKCs with subjectAltNames containing empty GeneralName
1949 fields. For example, an rfc822Name is represented as an IA5String.
1950 While an empty string is a valid IA5String, such an rfc822Name is not
1951 permitted by PKIX. The behavior of clients that encounter such a PKC
1952 when processing a certification path is not defined by this working
1953 group. Because the subject's alternative name is considered to be
1954 definitively bound to the public key, all parts of the subject's
1955 alternative name must be verified by the CA.
1957 5.1.1.2.1 Internet e-mail addresses
1959 When the subjectAltName extension contains an Internet mail address,
1960 the address is included as an rfc822Name. The format of an rfc822Name
1962 Arsenault, Turner 37
1963 is an "addr-spec" as defined in [RFC-822]. An addr-spec has the form
1964 local-part@domain; it does not have a phrase (such as a common name)
1965 before it, or a comment (text surrounded in parentheses) after it,
1966 and it is not surrounded by "<" and ">".
1968 5.1.1.2.2 DNS Names
1970 When the subjectAltName extension contains a domain name service
1971 label, the domain name is stored in the dNSName attribute(an
1972 IA5String). The string shall be in the "preferred name syntax," as
1973 specified by [DNS]. Note that while upper and lower case letters are
1974 allowed in domain names, no significance is attached to the case. In
1975 addition, while the string " " is a legal domain name, subjectAltName
1976 extensions with a dNSName " " are not permitted. Finally, the use of
1977 the DNS representation for Internet mail addresses (wpolk.nist.gov
1978 instead of wpolk@nist.gov) is not permitted; such identities are to
1979 be encoded as rfc822Name.
1981 5.1.1.2.3 IP addresses
1983 When the subjectAltName extension contains an iPAddress, the address
1984 shall be stored in the octet string in "network byte order," as
1985 specified in [IP]. The least significant bit (LSB) of each octet is
1986 the LSB of the corresponding byte in the network address. For IP
1987 Version 4, as specified in [IP], the octet string must contain
1988 exactly four octets. For IP Version 6, as specified in [IPv6], the
1989 octet string must contain exactly sixteen octets.
1991 5.1.1.2.4 URIs
1993 The Internet PKI Profile [2459bis] notes "When the subjectAltName
1994 extension contains a URI, the name must be stored in the
1995 uniformResourceIdentifier (an IA5String). The name must be a non-
1996 relative URL, and must follow the URL syntax and encoding rules
1997 specified in [RFC 1738]. The name must include both a scheme (e.g.,
1998 "http" or "ftp") and a scheme-specific- part. The scheme-specific-
1999 part must include a fully qualified domain name or IP address as the
2000 host. As specified in [RFC 1738], the scheme name is not case-
2001 sensitive (e.g., "http" is equivalent to "HTTP"). The host part is
2002 also not case-sensitive, but other components of the scheme-specific-
2003 part may be case-sensitive. When comparing URIs, conforming
2004 implementations must compare the scheme and host without regard to
2005 case, but assume the remainder of the scheme-specific-part is case
2006 sensitive."
2008 5.1.2 Scope of Names
2010 The original X.500 work presumed that every subject in the world
2011 would have a globally unique distinguished name. Thus, every subject
2013 Arsenault, Turner 38
2014 could be easily located, and there would never be a conflict. All
2015 that would be needed is a sufficiently large name space, and rules
2016 for constructing names based on subordination and location.
2018 Obviously, that is not practical in the real world, for a variety of
2019 reasons. There is no single entity in the world trusted by everybody
2020 to reside at the top of the name space, and there is no way to
2021 enforce uniqueness on names for all entities. (These were among the
2022 reasons for the failure of PEM to be widely implemented.)
2024 This does not mean, however, that a name-based PKI cannot work. It is
2025 important to recognize that the scope of names in PKIX is local; they
2026 need to be defined and unique only within their own domain.
2028 Suppose for example that a Top CA is established with DN "O=IETF,
2029 OU=PKIX, CN=PKIX_CA". That CA will then issue PKCs for subjects
2030 subordinate to it. The only requirement, which can be enforced
2031 procedurally, is that no two distinct entities beneath this Top CA
2032 have the same name. We can't prevent somebody else in the world from
2033 creating her own CA, called "O=IETF, OU=PKIX, CN=PKIX_CA", and it is
2034 not necessary to do so. Within the domain of the original Top CA,
2035 there will be no conflict, and the fact that there is another CA of
2036 the same name in some other domain is irrelevant.
2038 This is analogous to the current DNS or IP address situations. On the
2039 Internet, there is only one node called www.ietf.org. The fact that
2040 there might be 10 different intranets, each with a host given the DNS
2041 name www.ietf.org, is irrelevant and causes no interoperability
2042 problems - those are different domains. However, if there were to be
2043 another node on the Internet with domain name www.ietf.org, then
2044 there would be a problem due to name duplication.
2046 The same applies for IP addresses. As long as only one node on the
2047 Internet responds to the IP address 130.85.1.3, there is no problem,
2048 despite the fact that there are 100 different corporate Intranets,
2049 each using that same IP address. However, if two different nodes on
2050 the Internet each responded to the IP address 130.85.1.3, there would
2051 be a problem.
2053 5.1.3 Certificate Path Construction
2055 Certificate path construction has been the topic of many discussions
2056 in the WG. The issue centered on how best to get a certificate when
2057 the connection between the subject's name and the name of their CA,
2058 as well as the CA's repository (or directory), may not be obvious.
2059 Many proposals were put forth, including implementing a global X.500
2060 Directory Service, using DNS SRV records, and using an extension to
2061 point to the directory provider. At the end of the discussion the
2062 group decided to use the authority information access extension
2063 defined in the Internet PKI Profile [2459bis], which allows the CA to
2064 indicate the access method and location of CA information and
2065 services. The extension would be included in subject's certificates
2067 Arsenault, Turner 39
2068 and could be used to associate an Internet style identity for the
2069 location of repository to retrieve the issuer's certificate in cases
2070 where such a location is not related to the issuer's name.
2072 Another discussion related to certificate path construction was where
2073 to store the CA and EE PKCs in the directory (specifically LDAPv2
2074 directories). Two camps emerged with different views on where to
2075 store CA and cross-certificates. In the CA's directory entry, one
2076 camp wanted self-issued PKCs stored in the cACertificate attribute,
2077 PKCs issued to this CA stored in the forward element of the
2078 crossCertificatePair, and PKCs issued from this CA for other CAs in
2079 the reverse element of the crossCertificatePair attribute. The other
2080 camp wanted all CA PKCs stored in the cACertificate attribute, and
2081 PKCs issued to and from another domain stored in the
2082 crossCertificatePair attribute. There was a short discussion that the
2083 second was more efficient than first and that one solution or the
2084 other was more widely deployed. The end result was to indicate that
2085 self-issued PKCs and PKCs issued to the CA by CAs in the same domain
2086 as the CA are stored in the cACertificate attribute. The
2087 crossCertificatePair attribute's forward element will include all but
2088 self-issued PKCs issued to the CA. The reverse element may include a
2089 subset of PKCs issued by the CA to other CAs. With this resolution
2090 both camp's implementations are supported and are free to choose the
2091 location of CA PKCs to best support their implementation.
2093 5.1.4 Name Constraints
2095 A question that has arisen a number of times is "how does one enforce
2096 Name constraints when there is more than one name form in a PKC?"
2097 That is, the Internet PKI Profile [2459bis] states that:
2099 Subject's alternative names may be constrained in the same manner as
2100 subject distinguished names using the name constraints extension as
2101 described in section 4.2.1.11.
2103 What does this mean? Suppose that there is a CA with DN "O=IETF,
2104 OU=PKIX, CN=PKIX_CA", with the subjectAltName extension having
2105 dNSName "PKIX_CA.IETF.ORG". Suppose that that CA has issued a PKC
2106 with an empty DN, with subjectAltName extension having dNSName set to
2107 "PKIX_CA.IETF.ORG", and rfc822Name set to Steve@PKIX_CA.IETF.ORG. The
2108 question is: are name constraints enforced on these two PKCs - is the
2109 name of the EE PKC considered to be properly subordinate to the name
2110 of the CA?
2112 The answer is "yes". The general rules for deciding whether a PKC
2113 meets name constraints are:
2115 - If a PKC complies with name constraints in any one of its name
2116 forms, then the PKC is deemed to comply with name constraints.
2118 - If a PKC contains a name form that its issuer does not, the PKC is
2119 deemed to comply with name constraints for that name form.
2121 Arsenault, Turner 40
2122 In deciding whether a name form meets name constraints, the following
2123 rules apply (in all cases Name B is the name in the name constraints
2124 extension):
2126 5.1.4.1 rfc822Names
2128 Three variations are allowed:
2130 - If the name constraint is specified as "larry@mail.mit.edu", then
2131 Name A is subordinate to Name B (in B's subtree) if Name A
2132 contains all of Name B's name (specifies a particular mailbox).
2133 For example, larry@mail.mit.edu is subordinate, but
2134 larry_sanders@mail.mit.edu is not.
2136 - If the name constraint is specified as "mail.mit.edu", then Name A
2137 is subordinate to Name B (in B's subtree) if Name A contains all
2138 of Name B's name (specified all mailboxes on host mail.mit.edu).
2139 For example, curly@mail.mit.edu and mo@mail.mit.edu are
2140 subordinate, but mo@mail6.mit.edu and curly@smtp.mail.mit.edu are
2141 not.
2143 - If the name constraint is specified as ".mit.edu", then Name A is
2144 subordinate to Name B (in B's subtree) if Name A contains all of
2145 Name B's name, with the addition of zero or more additional host
2146 or domain names to the left of Name B's name. That is,
2147 smtp.mit.edu is subordinate to .mit.edu, as is pop.mit.edu.
2148 However, mit.edu is not subordinate to .mit.edu. When the
2149 constraint begins with a "." it specifies any address within a
2150 domain. In the previous example, "mit.edu" is not in the domain of
2151 ".mit.edu".
2153 Note: If rfc822 names are constrained, but the PKC does not contain a
2154 subjectAltName extension, the EmailAddress attribute will be used to
2155 constrain the name in the subject distinguished name. For example (c
2156 is country, o is organization, ou is organizational unit, and em is
2157 EmailAddress), Name A ("c=US, o=MIT, ou=CS, em=curly@mail.mit.edu")
2158 is subordinate to Name B ("c=US, o=MIT, ou=CS") (in B's subtree) if
2159 Name A contains all of Name B's names.
2161 5.1.4.2 dNSNames
2163 Name A is subordinate to Name B (in B's subtree) if Name A contains
2164 all of Name B's name, with the addition of zero or more additional
2165 domain names to the left of Name B's name. That is, www.mit.edu is
2166 subordinate to mit.edu, as is larry.cs.mit.edu. However, www.mit.edu
2167 is not subordinate to web.mit.edu.
2169 Arsenault, Turner 41
2170 5.1.4.3 x.400 addresses
2172 Name A is subordinate to Name B (in B's subtree) if Name A contains
2173 all of Name B's name. For example (c is country-name, admd is
2174 administrative-domain-name, and o is organization-name, ou is
2175 organizational-unit-name, pn is personal-name, sn=surname, and gn is
2176 given-name in both Name A and B), the mnemonic X.400 address (using
2177 PrintableString choices for c and admd) "c=US, admd=AT&T, o=MIT,
2178 ou=cs, pn='sn=Doe,gn=John'" is subordinate to "c=US, admd=AT&T,
2179 o=MIT, ou=cs" and "c=US, admd=AT&T, o=MIT, pn='sn=DOE,gn=JOHN'" (pn
2180 is a SET that includes, among other things, sn and gn).
2182 5.1.4.5 DNs
2184 Name A is subordinate to Name B (in B's subtree), if Name A contains
2185 all of Name B's name, treating attribute values encoded in different
2186 types as different strings, ignoring case in PrintableString (in all
2187 other types case is not ignored), removing leading and trailing white
2188 space in PrintableString, and converting internal substrings of one
2189 or more consecutive white space characters to a single space. For
2190 example, (c is country, o is organization, ou is organizational unit,
2191 and cn is common name):
2193 - Assuming PrintableString types for all attribute values in Name A
2194 and B, "c=US, o=MIT, ou=CS" is subordinate to "c=us, o=MIT,
2195 ou=cs", as is "c=US, o=MIT, ou=CS, ou=administration". Another
2196 example, "c=US, o=MIT, ou=CS, cn= John Doe" (note the white
2197 spaces) is subordinate to "c=US, o=MIT, ou=CS, cn=John Doe".
2199 - Assuming UTF8String types for all attribute values in Name A and B,
2200 "c=US, o=MIT, ou=CS, ou=administration" is subordinate to "c=US,
2201 o=MIT, ou=CS", but "c=US, o=MIT, ou=cs, ou=Administration". "c=US,
2202 o=MIT, ou=CS, cn= John Smith" (note the white spaces) is not
2203 subordinate to "c=US, o=MIT, ou=CS, cn= John Smith".
2205 - Assuming UTF8String types for all attribute values in Name A and
2206 PrintableString types for all attribute values in Name B, "c=US,
2207 o=MIT, ou=cs" is subordinate to "c=US, o=MIT, ou=CS" if the
2208 verification software supports the full comparison algorithm in
2209 the X.500 series. "c=US, o=MIT, ou=cs" is NOT subordinate to
2210 "c=US, o=MIT, ou=CS" if the verification software supports the
2211 comparison algorithm in the Internet PKI Profile [2459bis].
2213 5.1.4.6 URIs
2215 The constraints apply only to the host part of the name. Two
2216 variations are allowed:
2218 - If the name constraint is specified as ".mit.edu", then Name A is
2219 subordinate to Name B (in B's subtree) if Name A contains all of
2220 Name B's name, with the addition of zero or more additional host
2222 Arsenault, Turner 42
2223 or domain names to the left of Name B's name. That is, www.mit.edu
2224 is subordinate to .mit.edu, as is curly.cs.mit.edu. However,
2225 mit.edu is not subordinate to .mit.edu. When the constraint begins
2226 with a "." it specifies a host.
2228 - If the name constraint is specified as "abc.mit.edu", then Name A
2229 is subordinate to Name B (in B's subtree) if Name A contains all
2230 of Name B's name. No leftward expansion of the host or domain name
2231 is allowed.
2233 5.1.4.7 iPaddresses
2235 Two variations are allowed depending on the IP version:
2237 - For IPv4 addresses: Name A (128.32.1.1 encoded as 80 20 01 01) is
2238 subordinate to Name B (128.32.1.0/255.255.255.0 encoded as 80 20
2239 00 00 FF FF FF 00) (in B's subtree) if Name A falls within the net
2240 denoted in Name B's CIDR notation.
2242 - For IPv6 addresses: Name A (4224.0.0.0.8.2048.8204.16762 encoded as
2243 10 80 00 00 00 00 00 00 00 08 08 00 20 0C 41 7A) is subordinate to
2244 Name B (4224.0.0.0.8.2048.8204.0/
2245 65535.65535.65535.65535.65535.65535.65535.0 encoded as 10 80 00 00
2246 00 00 00 00 00 08 08 00 20 0C 00 00 FF FF FF FF FF FF FF FF FF FF
2247 FF FF FF FF 00 00) (in B's subtree) if Name A falls within the net
2248 denoted in Name B's CIDR notation.
2250 5.1.4.8 Others
2252 As the Internet PKI Profile [2459bis] does not define requirements
2253 for the name forms otherName, ediPartyName, or registeredID there are
2254 no corresponding name constraints requirements.
2256 5.1.5 Wildcards in Name Forms
2258 A "wildcard" in a name form is a placeholder for a set of names
2259 (e.g., "*.mit.edu" meaning "any domain name ending in .mit.edu", and
2260 *@aol.com meaning "email address that uses aol.com"). There are many
2261 people who believe that allowing wildcards in name forms in PKIX PKCs
2262 would be a useful thing to do, because it would allow a single PKC to
2263 be used by all members of a group. These members would presumably
2264 have attributes in common; e.g., access rights to some set of
2265 resources, and so issuance of a PKC with a wildcard for the group
2266 would simplify management.
2268 After much discussion, the PKIX working group decided to permit the
2269 use of wildcards in PKCs. That is, it is permissible for a PKIX-
2270 conformant CA to issue a PKC with a wildcard. However, the semantics
2271 of subjectAltName extension that include wildcard characters are not
2273 Arsenault, Turner 43
2274 addressed by PKIX. Applications with specific requirements may use
2275 such names but must define the semantics.
2277 5.1.6 Name Encoding
2279 A very important topic that consumed much of the WG's time was the
2280 implementation of the directory string choices. While the long term
2281 goal of the IETF was clear, use UTF8String, the short term goals were
2282 not so clear. Many implementations only use PrintableString, others
2283 use BMPString, and still others use Latin1String (ISO 8859-1) and tag
2284 it as TeletexString (there are others still). To ensure that there is
2285 consistency with encodings the Internet PKI Profile [2459bis] defines
2286 a set of rules for the string choices. PrintableString was kept as
2287 the first choice because of it's widespread support by vendors.
2288 BMPString was the second choice, also for it's widespread vendor
2289 support. Failing support by PrintableString and BMPString, UTF8String
2290 must be used. In keeping with the IETF mandate, UTF8String can be
2291 used at any time if the CA supports it. Also, processing
2292 implementations that wish to support TeletexString should handle the
2293 entire ISO 8859-1 character set and not just the Latin1String subset.
2295 5.2 POP
2297 Proof of Possession, or POP, or also CA POP, means that the CA is
2298 adequately convinced that the entity requesting a PKC containing a
2299 public key Y has access to the private key X corresponding to that
2300 public key.
2302 There has been some debate whether POP was or not needed.
2304 This question needs to be addressed separately considering the
2305 context of use of the key, in particular whether a key is used for an
2306 authentication or non repudiation service, or in a confidentiality
2307 service. Note that this does not map to the key usage bit directly,
2308 since it is possible to use a confidentiality key to perform an
2309 authentication service, e.g. by asking to decrypt an encrypted
2310 challenge.
2312 5.2.1 POP for Signing Keys
2314 It is important to provide POP for keys used to sign material, in
2315 order to provide non-repudiation of transactions. For example,
2316 suppose Alice legitimately has private key X and its corresponding
2317 public key Y. Alice has a PKC from Charlie, a CA, containing Y. Alice
2318 uses X to sign a transaction T. Without POP, Mal could also get a PKC
2319 from Charlie containing the same public key, Y. Now without POP,
2320 there are two possible threats: Mal could claim to have been the real
2321 signer of T; or Alice can falsely deny signing T, claiming that it
2322 was instead Mal. Since no one can reliably prove that Mal did or did
2323 not ever possess X, neither of these claims can be refuted, and thus
2325 Arsenault, Turner 44
2326 the service provided by and the confidence in the PKI has been
2327 defeated. (Of course, if Mal really did possess X, Alice's private
2328 key, then no POP mechanism in the world will help, but that is a
2329 different problem.)
2331 Protection can be gained by having Alice, as the true signer of the
2332 transaction, include in the signed information her PKC or an
2333 identifier of her PKC (e.g., a hash of her PKC). This makes
2334 impossible for Mal to claim authorship because he does not know the
2335 private key from Alice and thus is unable to include his certificate
2336 under the signature.
2338 The adequate protection may be obtained in the general case, by
2339 mandating the inclusion of a reference of the certificate every time
2340 a signature (or non repudiation) key is being used in a protocol.
2342 However, because all the protocols were not doing so, a conservative
2343 measure has been taken by requesting POP to be performed by CAs. It
2344 should thus be understood, that this measure is not strictly
2345 necessary and is only a temporary measure to make old protocols
2346 secure. New protocols or data formats are being developed. If the key
2347 being used is always used in a context where the identifier of the
2348 certificate is included in the protocol, then POP by the CA is not
2349 necessary. The inclusion of the identifier of the certificate in the
2350 protocol or data format may be understood as POP being performed at
2351 the transaction time rather than by the CA, at the registration time
2352 of the user in the PKI.
2354 5.2.2 POP for Key Management Keys
2356 Suppose that Al is a new instructor in the Computer Science
2357 Department of a local University. Al has created a draft final exam
2358 for the Introduction to Networking course he is teaching. He wants to
2359 send a copy of the draft final to Dorothy, the Department Head, for
2360 her review prior to giving the exam. This exam will of course be
2361 encrypted, as several students have access to the computer system.
2362 However, a quick search of the PKC repository (e.g., search the
2363 repository for all records with subjectPublicKey=Dorothy's-value)
2364 turns up the fact that several students have PKCs containing the same
2365 public key management key as Dorothy. At this point, if no POP has
2366 been done by the CA, Al has no way of knowing whether all of the
2367 students have simply created these PKCs without knowing the
2368 corresponding private key (and thus it is safe to send the encrypted
2369 exam to Dorothy), or whether the students have somehow acquired
2370 Dorothy's private key (and thus it is certainly not safe to send the
2371 exam).
2373 The later case may seem unsafe. However, if the other students have
2374 acquired the key, they do not even need to publish their certificates
2375 and can simply decrypt in parallel.
2377 Arsenault, Turner 45
2378 The end story is that, if the key only known to Dorothy, there is no
2379 problem. Thus POP by the CA is not needed.
2381 If the key, like a Diffie-Hellman key, is used for an authentication
2382 service the answer depends from the protocol being used. In the
2383 former example, the decryption was done locally and no data was sent
2384 back on the wire. In an authentication protocol, the story is
2385 different because either some encrypted or decrypted data is sent
2386 back. If the data sent back contains the identifier of the
2387 certificate in a way that it cannot be modified without that
2388 modification being detected, then there is no need for POP. On the
2389 contrary, POP by the CA is needed.
2391 As a conservative measure, POP for encryption keys is recommended,
2392 but it should be realized that it is not always needed.
2394 In general it should be noticed that POP at the time of the
2395 transaction is much superior than POP made by the CA, since it is
2396 possible in real time to be sure that everything is correct, rather
2397 than rely on that verification to be done at the time of registration
2398 by the CA. Should the CA fail in that verification, then there is a
2399 security breach. On the contrary, doing POP at the time of the
2400 transaction, eliminates that problem.
2402 CMP requires that POP be provided for all keys, either through on-
2403 line or out-of-band means. There are any number of ways to provide
2404 POP, and the choice of which to use is a local matter. Additionally,
2405 a PKC requester can provide POP to either a CA or to an RA, if the RA
2406 can adequately assure the CA that POP has been performed. Some of the
2407 acceptable ways to provide POP include:
2409 - Out-of-band means:
2411 - For keys generated by the CA or an RA (e.g., on a token such as
2412 a smart card or PCMCIA card), possession of the token can
2413 provide adequate proof of possession of the private key.
2415 - For user-generated keys, another approach can be used in
2416 environments where "key recovery" requirements force the
2417 requester to provide a copy of the private key to the CA or an
2418 RA. In this case, the CA will not issue the requested PKC until
2419 such time as the requester has provided the private key. This
2420 approach is in general not recommended, as it is extremely risky
2421 (e.g., the system designers need to figure out a way to protect
2422 the private keys from compromise while they are being sent to
2423 the CA/RA/other authority, and how to protect them there), but
2424 it can be used.
2426 - On-line means:
2428 - For signature keys that are generated by an EE, the requester of
2429 a PKC can be required to sign some piece of data (typically, the
2430 PKC request itself) using the private key. The CA will then use
2432 Arsenault, Turner 46
2433 the requested public key to verify the signature. If the
2434 signature verification works, the CA can safely conclude that
2435 the requester had access to the private key. If the signature
2436 verification process fails, the CA can conclude that the
2437 requester did not have access to the correct private key, and
2438 reject the request.
2440 - For key management keys that are generated by the requester, the
2441 CA can send the user the requested public key, along with the
2442 CA's own public key, to encrypt some piece of data, and send it
2443 to the requester to be decrypted. For example, the CA can
2444 generate some random challenge, and require some action to be
2445 taken after decryption (e.g., "decrypt this encrypted random
2446 number and send it back to me"). If the requester does not take
2447 the requested action, the CA concludes that the requester did
2448 not possess the private key, and the PKC is not issued.
2450 Another method of providing POP for key management keys is for the CA
2451 to generate the requested PKC, and then send it to the requester in
2452 encrypted form. If the requester does not have access to the
2453 appropriate private key, the requester cannot decrypt the PKC, and
2454 thus cannot use it. After some period of time in which the PKC is not
2455 used, the CA will revoke the PKC. (This only works if the PKC is not
2456 made available to any untrusted entities until after the requester
2457 has successfully decrypted it.)
2459 5.3 Key Usage Bits
2461 The key usage extension defines the purpose (e.g., encipherment,
2462 signature, certificate signing) of the key contained in the PKC. This
2463 extension is used when a key that could be used for more than one
2464 operation is to be restricted. For example, if a CA's RSA key should
2465 be used only for signing CRLS, the cRLSign bit would be asserted.
2466 Likewise, when an RSA key should be used only for key management, the
2467 keyEncipherment bit would be asserted. When used, this extension
2468 should be marked critical.
2470 The Internet PKI Profile [2459bis] includes some text for how the
2471 bits in the KeyUsage type are used. Developing the text for some of
2472 the bits was easy; however, many discussions were needed to arrive at
2473 a common agreement on the meaning of the digitalSignature (DS bit)
2474 and nonRepudiation (NR bit) bits and when they should be set. The
2475 group quickly realized that key usage extension mixes services and
2476 mechanisms. The DS bit indicates a mechanism - a public key used to
2477 verify a digital signature. The NR bit indicates a service - a public
2478 key used to verify a digital signature and to provide a non-
2479 repudiation service. When trying to indicate when each bit should be
2480 indicated arguments were based on:
2482 The lifetime of the object being signed. Some felt that the DS bit
2483 should be set when the certificate is used to sign ephemeral objects
2484 (e.g., bind tokens) while the NR bit should be set for things that
2486 Arsenault, Turner 47
2487 are survive longer (e.g., documents). Of course, the problem with
2488 this distinction to determine how long is the time period for
2489 ephemeral?
2491 A conscious act taken by the signer. Many felt that the NR bit should
2492 be set only when the subject has expressly acknowledged that they
2493 want to use the private key to sign an object. Signing a document say
2494 where there is a conscious decision by the subject would be
2495 appropriate for the key usage extension to contain NR, but when the
2496 key is used for authentication purposes, which can occur
2497 automatically and more frequently, the DS bit is more appropriate.
2498 The discussion also concluded that since some authentication schemes
2499 occur automatically, that the DS bit and NR bit should never be set
2500 together in the same certificate. Some agreed to the differentiation
2501 of the bits based on the time, but did not agree that the two could
2502 not be in the same key usage extension.
2504 The procedures followed by the CA. Some felt that NR bit was kind of
2505 'quality mark' indicating to the verifier that the verifier could be
2506 assured that the CA is implementing appropriate procedures for
2507 checking the subject's identity, performing certificate archival,
2508 etc. Other felt that it was not entirely the CAs job and that some
2509 other entity must be involved.
2511 In the end the WG agreed to a few things:
2513 - Provision of the service of non-repudiation requires more than a
2514 single bit set in a PKC. It requires an entire infrastructure of
2515 components to preserve for some period of time the keys, PKCs,
2516 revocation status, signed material, etc., as well as a trusted
2517 source of time. However, the nonRepudiation key usage bit is
2518 provided as an indicator that such keys could be used as a
2519 component of a system providing a non-repudiation service.
2521 - The certificate policy is the appropriate place to indicate the
2522 permitted combinations of key usages. That is, a policy may
2523 indicate that the DS and NR bits can not be set in the same
2524 certificate while another may say that the DS and NR bits can be
2525 set in the same certificate.
2527 [2459bis] includes new text indicating the above agreements.
2529 5.4 Non-Repudiation
2531 The major benefit of the whole DS bit vs NR bit discussion is
2532 development of the Technical Requirements for Non-Repudiation
2533 [TECHNR] draft. To fill this void [TECHNR] was developed to "describe
2534 those features of a service which processes signed documents which
2535 must be present in order for that service to constitute a 'technical
2536 non-repudiation' service." The basic understanding of non-repudiation
2537 is that it requires that a digital signature be preserved in such a
2538 manner that it can convince a neutral third party that it was
2540 Arsenault, Turner 48
2541 actually created by someone with access to the private key of a
2542 certified key pair. Whether this definition of non-repudiation is
2543 enough to form a legally bind agreement is still being debated.
2545 5.5 Trust Models
2547 An important design decision is, for a given application, where the
2548 particular EE's trust points are located (i.e. what are the Top
2549 CAs). There are a number of models that have been developed and
2550 depending on the environment some models may be more suited than
2551 others. The following provides some background on the models.
2553 5.5.1 Hierarchical
2555 One of the initial trust models proposed was the hierarchical model.
2556 In this model the trust point or root CA for an entire domain is the
2557 top most CA. The root CA in turn issues certificates to subordinate
2558 CAs, and the subordinate CAs issue certificates to EEs. When
2559 verifying a PKC, the RP must verify ever certificate in the path from
2560 the EE's PKC to the root CA.
2562 The main benefit of the hierarchical model is the fact that controls
2563 imposed from the top down. For example, name constraints can be
2564 included in the subordinate CAs to limit the name space in which they
2565 are allowed to issue certificates. Further, the root CA ensure domain
2566 wide policies on cross-certification (though there are no controls to
2567 prevent another PKI from issuing PKCs to members of the domain, but
2568 then those members could be thought of as members of two distinct
2569 PKIs).
2571 Interoperability is achieved through the use of cross-certificates.
2572 Cross-certificates can be issued by the root CA or if allowed by
2573 subordinate CAs.
2575 5.5.2 Local/Federation
2577 Another model that has been around a long time is the local trust
2578 model. In this model, the RPs trust the CA that issued their
2579 certificate to them. The idea is that since the CA is local and
2580 probably known to the RP, that there is more trust rather than with
2581 some distant unknown CA.
2583 In order for EEs under different CAs to communicate the CAs issue
2584 each other certificates thereby creating a certification path from
2585 one EE to another. The process of the CAs issuing one another PKCs
2586 forms a kind of federation
2588 The main benefit of the local model is its flexibility. Many believe
2589 that the local CA knows best how to support its user community and
2591 Arsenault, Turner 49
2592 should be given cart blanche to generate certificates as it sees fit
2593 to allow the user community to perform their functions.
2595 5.5.3 Root Repository
2597 A model made famous in the web browser community is the root
2598 repository. This model uses a file to store the PKCs of many CAs. The
2599 RP then trusts any PKC included in the file. The PKC included in the
2600 root repository may be a root CA for some other domain or subordinate
2601 CA, but when included in the trust file whatever type of PKC it is in
2602 the other domain, it becomes a root CA for the RP. Obviously, the
2603 main advantage is the fact that cross-certification is not required.
2604 If the RP does not have the root CA's certificate and it is included
2605 in with the object, the RP can just add it to the file to "trust" it
2606 (this should only be done if the RP truly trusts the root CA).
2608 5.5.4 RP's Perspective
2610 Another model recently getting attention is the model where instead
2611 of the CA imposing restraints on the RP (in the PKC), the RP instead
2612 makes the determination as to which certificates to trust. The RP
2613 determines which domain it will accept certificates from, which key
2614 usages it will accept, etc. Cross-certification is also not required
2615 because the RP can just chose to trust a particular PKC or domain of
2616 PKCs. This obviously turns the first three models on their heads.
2617 Special care must be taken to ensure that the RP is properly
2618 configured.
2620 5.5.5 Validation Policies
2622 Another model considers a set of rules that apply to an application
2623 context. Every application context may have a different set of
2624 rules. When choosing to use certificates in the context of that
2625 application, the EE selects the set of rules for that context. In a
2626 set of rules, one or more Top CAs may be trusted, each one may be
2627 associated with different constraints, like the certificate policies
2628 that are trusted or the naming constraints that apply. These
2629 constrains may be specified either in self-signed certificates or in
2630 addition to self-signed certificates when they do not incorporate
2631 these constraints. This set of rules is called a validation policy
2632 (when validating a certificate) or a signature policy (when
2633 validating a digital signature).
2635 6 References
2637 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
2638 3", BCP 9, RFC 2026, October 1996.
2640 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
2641 Requirement Levels", BCP 14, RFC 2119, March 1997.
2643 Arsenault, Turner 50
2645 [2459bis] Housley, R., Ford, W., Polk, W., and Solo, D., "Internet
2646 X.509 Public Key Infrastructure Certificate and CRL Profile," RFC
2647 3280, April 2002.
2649 [2510bis] Adams, C., Farrell, S., "Internet X.509 Public Key
2650 Infrastructure Certificate Management Protocols," , December 2001.
2653 [2511bis] Myers, M., Adams, C., Solo, D., and Kemp D. "Internet X.509
2654 Public Key Infrastructure Certificate Request Message Format
2655 (CRMF)," , December 2001.
2657 [2527bis] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and Wu,
2658 S., "Internet X.509 Public Key Infrastructure Certificate Policy and
2659 Certification Practices Framework," , January 2002.
2662 [2797bis] Myers, M., Liu, X., Fox, B., and Weinstein, J.,
2663 "Certificate Management Messages over CMS," , February 2002.
2666 [AC] Farrell, S., and Housley, R., "An Internet Attribute Certificate
2667 Profile for Authorization," RFC 3281, April 2002.
2669 [ACRMF] Yee, P., "Attribute Certificate Request Message Format,"
2670 , March 2002.
2672 [ACMC] Yee, P., "Attribute Certificate Management Messages over CMS,"
2673 , March 2002.
2675 [ADDSCHEMA] Chadwick, D., Legg, S., "Internet X.509 Public Key
2676 Infrastructure Additional LDAP Schema for PKIs and PMIs," , November 2001.
2679 [CMC] Myers, M., Liu, X., Schaad, J., and Weinstein, J., "Certificate
2680 Management Messages over CMS," (RFC 2797), April 2000.
2682 [CMP] Adams, C., Farrell, S., "Internet X.509 Public Key
2683 Infrastructure Certificate Management Protocols," RFC 2510, March
2684 1999.
2686 [CMS] R. Housley, "Cryptographic Message Syntax," RFC 2630, July
2687 1999.
2689 [CRMF] Myers, M., Adams, C., Solo, D., and Kemp, D., "Internet X.509
2690 Certificate Request Message Format," RFC 2511, March 1999.
2692 [DNS] Mockapetris, P.V., "Domain names - concepts and facilities,"
2693 RFC 1034, November 1987.
2695 [DHPOP] Prafullchandra, H., and Schaad, J., "Diffie-Hellman Proof-
2696 of-Possession Algorithms," RFC 2875, July 2000 1999.
2698 Arsenault, Turner 51
2700 [DPD] Myers, M., Adams, C., Farrell, S., "Delegated Path Discovery
2701 with OCSP".
2703 [DPV] Myers, M., Adams, C., Farrell, S., "Delegated Path Validation".
2705 [DPREQ] Pinaks, D., Housley, R., "Delegated Path Validation and
2706 Delegated Path Discovery Protocol Requirements (DPV&DPD-REQ),"
2707 , April 2002.
2709 [DVCS] Adams, C., Sylvester, P., Zolotarev, M., Zuccherato, R.,
2710 "Internet X.509 Public Key Infrastructure Data Certification Server
2711 Protocols", RFC 3029, February 2001.
2713 [FTPHTTP] Housley, R., and Hoffman, P., "Internet X.509 Public Key
2714 Infrastructure Operational Protocols: FTP and HTTP," RFC 2585, July
2715 1998.
2717 [IP] Postel, J., "Internet Protocol," RFC 791, September 1981.
2719 [IPEXT] Lynn, C., Kent, S., Seo, K., "X.509 Extensions for IP
2720 Addresses and AS Identifiers," , February 2002.
2723 [IPv6] Deering, S., and Hinden, R., "Internet Protocol, Version 6
2724 [IPv6] Specification," RFC 1883, December 1995.
2726 [KEA] Housley, R., and Polk, W., "Internet X.509 Public Key
2727 Infrastructure Representation of Key Exchange Algorithm (KEA) Keys in
2728 Internet X.509 Public Key Infrastructure Certificates," RFC 2528,
2729 March 1999.
2731 [LAAP] Farrell, S., Chadwick, C.W., "Limited Attribute Certificate
2732 Acquisition Protocol".
2734 [LDAPv2] Yeong, Y., Howes, T., and Kille, S., "Lightweight Directory
2735 Access Protocol", RFC 1777, March 1995.
2737 [LOGO] Santesson, S. Housley, R., Freeman, T., "X.509 Internet Public
2738 Key Infrastructure Logotypes in X.509 Certificates," , April 2002.
2741 [OCSP] Myers, M., Ankney, R., Malpani, A., Galperin, S., and Adams,
2742 C., "X.509 Internet Public Key Infrastructure Online Certificate
2743 Status Protocol - OCSP," RFC 2560, June 1999.
2745 [OCSPv2] Myers, M., Ankney, R., Adams, C., "Online Certificate Status
2746 Protocol, version 2," , March 2001.
2748 [MISPC] Burr, W., Dodson, D., Nazario, N., and Polk, W., "MISPC
2749 Minimum Interoperability Specification for PKI Components, Version
2750 1", , 3 September 1997.
2752 Arsenault, Turner 52
2754 [PEM] Kent, S., "Privacy Enhancement for Internet Electronic Mail:
2755 Part II: Certificate-Based Key Management," RFC 1422, February 1993.
2757 [PI] Pinka, D., Gindin, T., "Internet X.509 Public Key Infrastructure
2758 Permanent Identifier," , February 2002.
2760 [PKI-LDAPv2] Boeyen, S., Howes, T., and Richard, P., "Internet X.509
2761 Public Key Infrastructure Operational Protocols - LDAPv2," RFC 2559,
2762 April 1999.
2764 [PKI-LDAPv3] Chadwick, D.W., "Internet X.509 Public Key
2765 Infrastructure Operational Protocols - LDAPv3," , January 2002.
2768 [POLPRAC] Chokhani, S., and Ford, W., "Internet X.509 Public Key
2769 Infrastructure Certificate Policy and Certification Practices
2770 Framework," RFC 2527, March 1999.
2772 [QC] Santesson, S., Polk, W., Barzin, P., and Nystrom, M., "Internet
2773 X.509 Public Key Infrastructure Qualified Certificates," RFC 3039,
2774 January 2001.
2776 [RLS] Boeyen, S., Hallam-Baker, P., "Internet X.509 Public Key
2777 Infrastructure Repository Locator Service," , July 2000.
2780 [RPKDS] Bassham, L., Housley, R., Polk, W., "Algorithms and
2781 Identifiers for the Internet X.509 Public Key Infrastructure
2782 Certificate and CRL Profile," RFC 3279, April 2002.
2784 [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text
2785 Messages," RFC 822, August 1982.
2787 [SCHEMA] Boeyen, S., Howes, T., and Richard, P., "Internet X.509
2788 Public Key Infrastructure LDAPv2 Schema," RFC 2587, June 1999.
2790 [SCVP] Malpani, A., Hoffman, P., Housley, R., and Freeman, T.,
2791 "Simple Certificate Validation Protocol (SCVP)," , March 2002.
2794 [SIMONETTI] Simonetti, D., "Re: German Key Usage", posting to ietf-
2795 pkix@imc.org mailing list, 12 August 1998.
2797 [SSKGKA] Schaad, J., " CMC Extensions: Server Side Key Generation and
2798 Key Archival," , July 2001.
2800 [SUPPALGS] Singer, A., and Whyte, W., "Supplemental Algorithms and
2801 Identifiers for the Internet X.509 Public Key Infrastructure
2802 Certificate and CRL Profile," ,
2803 March 2002.
2805 [TECHNR] Gindin, T., "Internet X.509 Public Key Infrastructure
2806 Technical Requirements for a non-Repudiation Service," December 2000.
2808 Arsenault, Turner 53
2810 [TPCMC] Schaad, J. Myers, M., Liu, X., Weinstein, J., "CMC
2811 Transport," , March 2002.
2813 [TPCMP] Kapoor , A., Tschalaer, R., "Transport Protocols for CMP,"
2814 , November 2000.
2816 [TSP] Adams, C., Cain, P., Pinkas, D., and Zuccherato, R., "Internet
2817 X.509 Public Key Infrastructure Time Stamp Protocols", RFC 3161,
2818 August 2001.
2820 [X.509] ITU-T Recommendation X.509 (1997 E): Information Technology -
2821 Open Systems Interconnection - The Directory: Authentication
2822 Framework, June 1997.
2824 [X9.42] ANSI X9.42-199x, Public Key Cryptography for The Financial
2825 Services Industry: Agreement of Symmetric Algorithm Keys Using
2826 Diffie-Hellman (Working Draft), December 1997.
2828 [X9.55] ANSI X9.55-1995, Public Key Cryptography For The Financial
2829 Services Industry: Extensions To Public Key Certificates And
2830 Certificate Revocation Lists, 8 December, 1995.
2832 [X9.57] ANSI X9.57-199x, Public Key Cryptography For The Financial
2833 Services Industry: Certificate Management (Working Draft), 21 June,
2834 1996.
2836 [WARR] Linsenbardt, D., Pontius, S., "Warranty Certificate
2837 Extension," , April 2002.
2839 [PKCS10] RSA Laboratories, "The Public-Key Cryptography
2840 Standards(PKCS)," RSA Data Security Inc., Redwood City, California,
2841 November 1993 Release.
2843 7 Security Considerations
2845 This document records the history and design philosophy of the of
2846 standards to support in a particular infrastructure or application.
2847 Individual PKIX documents specify a variety of message formats and
2848 protocols; a selection of these formats and protocols will be
2849 necessary to construct a complete infrastructure.
2851 This specification does not specify security considerations, since
2852 they are determined by selection of formats and protocols. However,
2853 each PKIX document specifies security considerations that are
2854 associated with the message formats or protocols defined in that
2855 particular standard. These security considerations must be
2856 considered in aggregate when deploying or designing a particular
2857 infrastructure or PKI-enabled application protocol.
2859 Arsenault, Turner 54
2860 8 Acknowledgements
2862 A lot of the information in this document was taken from the PKIX
2863 source documents; the authors of those deserve the credit for their
2864 own words. Other good material was taken from mail posted to the PKIX
2865 working group mail list (ietf-pkix@imc.org). Among those with good
2866 things to say were (with apologies to anybody we've missed): Sharon
2867 Boeyen, Santosh Chokhani, Warwick Ford, Russ Housley, Steve Kent,
2868 Ambarish Malpani, Matt Fite, Michael Myers, Tim Polk, Stefan
2869 Santesson, Dave Simonetti, Paul Hoffman, Denis Pinkas, Ed Gerck, Tom
2870 Gindin, Parag Namjoshi, Peter Sylvester, and Michael Zolotarev.
2872 9 Author's Addresses
2874 Alfred W. Arsenault
2875 Diversinet Corp.
2876 P.O. Box 6530
2877 Ellicott City, MD 21042-0530
2878 aarsenault@dvnet.com
2880 Sean Turner
2881 IECA, Inc.
2882 9010 Edgepark Road Vienna, VA 22182
2883 (703) 628-3180
2884 turners@ieca.com
2886 Expires January 2003
2888 Arsenault, Turner 55