idnits 2.17.1
draft-ietf-pkix-webcap-00.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 (2024-03-29) 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) 2024 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:
----------------------------------------------------------------------------
** Missing expiration date. The document expiration date should appear on
the first and last page.
** The document seems to lack a 1id_guidelines paragraph about
Internet-Drafts being working documents.
** The document seems to lack a 1id_guidelines paragraph about 6 months
document validity -- however, there's a paragraph with a matching
beginning. Boilerplate error?
** The document seems to lack a 1id_guidelines paragraph about the list of
current Internet-Drafts.
** The document seems to lack a 1id_guidelines paragraph about the list of
Shadow Directories.
** The document is more than 15 pages and seems to lack a Table of Contents.
== 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 91 instances of too long lines in the document, the longest
one being 8 characters in excess of 72.
** The abstract seems to contain references ([COR95,X509-AM]), which it
shouldn't. Please replace those with straight textual mentions of the
documents in question.
== There are 3 instances of lines with non-RFC2606-compliant FQDNs in the
document.
Miscellaneous warnings:
----------------------------------------------------------------------------
== Line 429 has weird spacing: '...request canno...'
== Line 871 has weird spacing: '...another eleme...'
== Line 1073 has weird spacing: '... create a byt...'
== The document seems to lack the recommended RFC 2119 boilerplate, even if
it appears to use RFC 2119 keywords -- however, there's a paragraph with
a matching beginning. Boilerplate error?
(The document does seem to have the reference to RFC 2119 which the
ID-Checklist requires).
-- The exact meaning of the all-uppercase expression 'MAY NOT' is not
defined in RFC 2119. If it is intended as a requirements expression, it
should be rewritten using one of the combinations defined in RFC 2119;
otherwise it should not be all-uppercase.
== Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD',
or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please
use uppercase 'NOT' together with RFC 2119 keywords (if that is what you
mean).
Found 'MUST not' in this paragraph:
6. PKI management protocols MUST not preclude the generation of key
pairs by the end-entity concerned, by an RA, or by a CA -- key
gen-eration MAY also occur elsewhere, but for the purposes of PKI
management we can regard key generation as occurring wherever the key is
first present at an end entity, RA, or CA.
== The expression 'MAY NOT', while looking like RFC 2119 requirements text,
is not defined in RFC 2119, and should not be used. Consider using 'MUST
NOT' instead (if that is what you mean).
Found 'MAY NOT' in this paragraph:
10. Final authority for certification creation rests with the CA;
no RA or end-entity equipment can assume that any certificate issued by a
CA will contain what was requested -- a CA MAY alter certificate field
values or MAY add, delete or alter extensions according to its operating
policy. In other words, all PKI entities (end-entities, RAs, and CAs)
MUST be capable of handling responses to requests for certificates in
which the actual certificate issued is different from that requested (for
example, a CA may shorten the validity period requested). Note that
policy MAY dictate that the CA MAY NOT publish or otherwise distribute
the certificate until the requesting entity has reviewed and accepted the
newly-created certificate (typ-ically through use of the PKIConfirm
message).
-- 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 (October 19, 1998) is 9293 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: 'Bradner' is mentioned on line 373, but not defined
-- Looks like a reference, but probably isn't: '1997' on line 373
== Missing Reference: 'Mine' is mentioned on line 447, but not defined
== Missing Reference: 'Bray' is mentioned on line 455, but not defined
== Missing Reference: 'Paoli' is mentioned on line 455, but not defined
== Missing Reference: 'Sperberg-McQueen' is mentioned on line 455, but not
defined
-- Looks like a reference, but probably isn't: '1998' on line 455
== Missing Reference: 'Base64' is mentioned on line 1063, but not defined
== Missing Reference: 'RFC2068' is mentioned on line 805, but not defined
** Obsolete undefined reference: RFC 2068 (Obsoleted by RFC 2616)
== Missing Reference: 'RSA' is mentioned on line 990, but not defined
== Missing Reference: 'DSA' is mentioned on line 991, but not defined
== Missing Reference: 'UTF8' is mentioned on line 1023, but not defined
== Unused Reference: 'CRMF' is defined on line 1117, but no explicit
reference was found in the text
== Unused Reference: 'PKCS7' is defined on line 1121, but no explicit
reference was found in the text
== Unused Reference: 'PKCS10' is defined on line 1125, but no explicit
reference was found in the text
== Unused Reference: 'PKCS11' is defined on line 1129, but no explicit
reference was found in the text
== Unused Reference: 'RFC1847' is defined on line 1133, but no explicit
reference was found in the text
== Unused Reference: 'RFC2104' is defined on line 1137, but no explicit
reference was found in the text
== Unused Reference: 'RFC2119' is defined on line 1141, but no explicit
reference was found in the text
== Unused Reference: 'RFC2202' is defined on line 1145, but no explicit
reference was found in the text
-- Possible downref: Non-RFC (?) normative reference: ref. 'XML'
-- Possible downref: Non-RFC (?) normative reference: ref. 'COR95'
-- No information found for draft-ietf-pkix-crmf-0x - is the name correct?
-- Possible downref: Normative reference to a draft: ref. 'CRMF'
-- Possible downref: Non-RFC (?) normative reference: ref. 'PKCS7'
-- Possible downref: Non-RFC (?) normative reference: ref. 'PKCS10'
-- Possible downref: Non-RFC (?) normative reference: ref. 'PKCS11'
** Downref: Normative reference to an Informational RFC: RFC 2104
** Downref: Normative reference to an Informational RFC: RFC 2202
-- Possible downref: Non-RFC (?) normative reference: ref. 'X509-AM'
Summary: 14 errors (**), 0 flaws (~~), 26 warnings (==), 13 comments
(--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 PKIX Working Group Surendra Reddy
3 Internet Draft Oracle Corporation
4 draft-ietf-pkix-webcap-00.txt April 19, 1998
5 Expires October 19, 1998
7 WEB based Certificate Access Protocol-- WebCAP/1.0
9 Status of this Memo
11 This document is an Internet-Draft. Internet-Drafts are working
12 documents of the Internet Engineering Task Force (IETF), its areas,
13 and its working groups. Note that other groups may also distribute
14 working documents as Internet-Drafts.
16 Internet-Drafts are draft documents valid for a maximum of six months
17 and may be updated, replaced, or made obsolete by other documents at
18 any time. It is inappropriate to use Internet-Drafts as reference
19 material or to cite them other than as "work in progress".
21 To view the entire list of current Internet-Drafts, please check the
22 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
23 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
24 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
25 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
27 Distribution of this document is unlimited. Please send comments to
28 the PKIX working group at ietf-pkix@imc.org, which may be joined by
29 sending a message with subject "subscribe" to ietf-pkix-
30 request@imc.org.
32 Abstract
34 This document describes the Internet X.509 Public Key Infrastructure
35 (PKI) Certificate Access Protocols. Protocol messages are defined for
36 all relevant aspects of certificate creation and management. Note
37 that ''certificate'' in this document refers to an X.509v3
38 Certificate as defined in [COR95, X509-AM].
40 This document specifies a set of methods, headers, and content-types
41 ancillary to HTTP/1.1 to publish, retrieve X.509 certificates and
42 Certificate Revocation Lists. This protocol also facilitates
43 determining current status of a digital certificate without the use
44 of CRLs. This protocol defines new methods, request and response
45 bodies, error codes to HTTP/1.1 protocol for securely publishing,
46 retrieving, and validation certificates across a firewalls.
48 A various certificate related information that includes certificates,
49 CRLs, and certification authority (CA) policy are retrieved from an
50 integrated single authority access point specified in X.509 version 3
51 extensions.
53 1. Introduction
55 WebCAP protocol provides a highly scalable and distributed architec-
56 ture. Since HTTP is widely deployed protocol on the internet,
57 deploying the PKI infrastructure on HTTP servers through WebCAP
58 extensions provides more flexibility, all internet users can use it
59 even if the site they belong has a firewall against intruders. The
60 WEBCAP provides some useful facilities for PKI; an information cach-
61 ing by both a proxy server and client software, a secure transport
62 layer service for confidentiality, a flexible request forwarding
63 which can be used in CA and CA communication.
65 WebCAP protocol supports:
67 o registration - whereby a user establishes its identity to CA
68 prior to that CA issuing a certificate or certificates for that
69 user.
71 o initialization - initialization of necessary key materials into
72 the client system.
74 o certification - issues certificates to a user's public key and
75 returns that certificate to the client system
77 o revocation - performs certification revocation by authorized
78 users.
80 o queries - supports basic queries for certificate retrieval,
81 validation.
83 o cross certification - exchange information between CAs to
84 establish a cross certifications.
86 In HTTP/1.1, method parameter information was exclusively encoded in
87 HTTP headers. Unlike HTTP/1.1, WebCAP, encodes method parameter
88 information either in an Extensible Markup Language (XML) [Bray,
89 Paoli, Sperberg-McQueen, 1998] request entity body, or in an HTTP
90 header. The use of XML to encode method parameters was motivated by
91 the ability to add extra XML elements to existing structures, pro-
92 viding extensibility, and by XML's ability to encode information in
93 ISO 10646 character sets, providing internationalization support.
94 As a rule of thumb, parameters are encoded in XML entity bodies when
95 they have unbounded length, or when they may be shown to a human
96 user and hence require encoding in an ISO 10646 character set. Oth-
97 erwise, parameters are encoded within HTTP headers.
99 In addition to encoding method parameters, XML is used in WebCAP to
100 encode the responses from methods, providing the extensibility and
101 internationalization advantages of XML for method output, as well as
102 input.
104 The XML namespace extension is also used in this specification in
105 order to allow for new XML elements to be added without fear of col-
106 liding with other element names.
108 While the status codes provided by HTTP/1.1 are sufficient to
109 describe most error conditions encountered by WebCAP methods, there
110 are some errors that do not fall neatly into the existing
111 categories.
113 1.1. PKI Management Model
114 Before specifying particular message formats and procedures we first
115 define the entities involved in PKI management and their interac-
116 tions (in terms of the PKI management functions required). We then
117 group these functions in order to accommodate different identifiable
118 types of end entities.
120 1.2. Definitions of PKI Entities
121 The entities involved in PKI management include the end entity
122 (i.e., the entity to be named in the subject field of a certificate)
123 and the certification authority (i.e., the entity named in the
124 issuer field of a certificate). A registration authority MAY also be
125 involved in PKI management.
127 1.2.1. Subjects and End Entities
128 The term "subject" is used here to refer to the entity named in the
129 subject field of a certificate; when we wish to distinguish the
130 tools and/or software used by the subject (e.g., a local certificate
131 management module) we will use the term "subject equipment". In gen-
132 eral, the term "end entity" (EE) rather than subject is preferred in
133 order to avoid confusion with the field name.
135 It is important to note that the end entities here will include not
136 only human users of applications, but also applications themselves
137 (e.g., for IP security). This factor influences the protocols which
138 the PKI management operations use; for example, application software
139 is far more likely to know exactly which certificate extensions are
140 required than are human users. PKI management entities are also end
141 entities in the sense that they are sometimes named in the subject
142 field of a certificate or cross-certificate. Where appropriate, the
143 term "end- entity" will be used to refer to end entities who are not
144 PKI management entities.
146 All end entities require secure local access to some information --
147 at a minimum, their own name and private key, the name of a CA which
148 is directly trusted by this entity and that CA's public key (or a
149 fingerprint of the public key where a self-certified version is
150 available elsewhere). Implementations MAY use secure local storage
151 for more than this minimum (e.g., the end entity's own certificate
152 or application-specific information). The form of storage will also
153 vary -- from files to tamper-resistant cryptographic tokens. Such
154 local trusted storage is referred to here as the end entity's Per-
155 sonal Security Environment (PSE).
157 Though PSE formats are beyond the scope of this document (they are
158 very dependent on equipment, et cetera), a generic interchange for-
159 mat for PSEs is defined here - a certification response message MAY
160 be used.
162 1.2.2. Certification Authority
163 The certification authority (CA) may or may not actually be a real
164 "third party" from the end entity's point of view. Quite often, the
165 CA will actually belong to the same organization as the end entities
166 it supports.
168 Again, we use the term CA to refer to the entity named in the issuer
169 field of a certificate; when it is necessary to distinguish the
170 software or hardware tools used by the CA we use the term "CA equip-
171 ment".
173 The CA equipment will often include both an "off-line" component and
174 an "on-line" component, with the CA private key only available to
175 the "off- line" component. This is, however, a matter for imple-
176 menters (though it is also relevant as a policy issue).
178 We use the term "root CA" to indicate a CA that is directly trusted
179 by an end entity; that is, securely acquiring the value of a root CA
180 public key requires some out-of-band step(s). This term is not meant
181 to imply that a root CA is necessarily at the top of any hierarchy,
182 simply that the CA in question is trusted directly.
184 A "subordinate CA" is one that is not a root CA for the end entity
185 in question. Often, a subordinate CA will not be a root CA for any
186 entity but this is not mandatory.
188 1.2.3. Registration Authority
189 In addition to end-entities and CAs, many environments call for the
190 existence of a Registration Authority (RA) separate from the
191 Certification Authority. The functions which the registration author-
192 ity may carry out will vary from case to case but MAY include per-
193 sonal authentication, token distribution, revocation reporting, name
194 assignment, key generation, archival of key pairs, et cetera.
196 This document views the RA as an OPTIONAL component - when it is not
197 present the CA is assumed to be able to carry out the RA's functions
198 so that the PKI management protocols are the same from the end-
199 entity's point of view.
201 Again, we distinguish, where necessary, between the RA and the tools
202 used (the "RA equipment").
204 Note that an RA is itself an end entity. We further assume that all
205 RAs are in fact certified end entities and that RAs have private keys
206 that are usable for signing. How a particular CA equipment identifies
207 some end entities as RAs is an implementation issue (i.e., this docu-
208 ment specifies no special RA certification operation). We do not man-
209 date that the RA is certified by the CA with which it is interacting
210 at the moment (so one RA may work with more than one CA whilst only
211 being certified once).
213 In some circumstances end entities will communicate directly with a
214 CA even where an RA is present. For example, for initial registration
215 and/or certification the subject may use its RA, but communicate
216 directly with the CA in order to refresh its certificate.
218 1.3. PKI Management Requirements
219 The protocols given here meet the following requirements on PKI
220 management.
222 1. PKI management MUST conform to the ISO 9594-8 standard and the
223 associated amendments (certificate extensions)
225 2. PKI management MUST conform to the other parts of this series.
227 3. It MUST be possible to regularly update any key pair without
228 affecting any other key pair.
230 4. The use of confidentiality in PKI management protocols MUST be
231 kept to a minimum in order to ease regulatory problems.
233 5. PKI management protocols MUST allow the use of different
234 industry- standard cryptographic algorithms, (specifically including
235 RSA, DSA, MD5, SHA-1) -- this means that any given CA, RA, or end
236 entity may, in principle, use whichever algorithms suit it for its
237 own key pair(s).
239 6. PKI management protocols MUST not preclude the generation of key
240 pairs by the end-entity concerned, by an RA, or by a CA -- key gen-
241 eration MAY also occur elsewhere, but for the purposes of PKI
242 management we can regard key generation as occurring wherever the
243 key is first present at an end entity, RA, or CA.
245 7. PKI management protocols MUST support the publication of certifi-
246 cates by the end-entity concerned, by an RA, or by a CA. Different
247 implementations and different environments may choose any of the
248 above approaches.
250 8. PKI management protocols MUST support the production of Certifi-
251 cate Revocation Lists (CRLs) by allowing certified end entities to
252 make requests for the revocation of certificates - this MUST be done
253 in such a way that the denial-of-service attacks which are possible
254 are not made simpler.
256 9. PKI management protocols MUST be usable over a variety of "tran-
257 sport" mechanisms, specifically including mail, http, TCP/IP and
258 ftp.
260 10. Final authority for certification creation rests with the CA; no
261 RA or end-entity equipment can assume that any certificate issued by
262 a CA will contain what was requested -- a CA MAY alter certificate
263 field values or MAY add, delete or alter extensions according to its
264 operating policy. In other words, all PKI entities (end-entities,
265 RAs, and CAs) MUST be capable of handling responses to requests for
266 certificates in which the actual certificate issued is different
267 from that requested (for example, a CA may shorten the validity
268 period requested). Note that policy MAY dictate that the CA MAY NOT
269 publish or otherwise distribute the certificate until the requesting
270 entity has reviewed and accepted the newly-created certificate (typ-
271 ically through use of the PKIConfirm message).
273 11. A graceful, scheduled change-over from one non-compromised CA
274 key pair to the next (CA key update) MUST be supported (note that if
275 the CA key is compromised, re-initialization MUST be performed for
276 all entities in the domain of that CA). An end entity whose PSE con-
277 tains the new CA public key (following a CA key update) MUST also be
278 able to verify certificates verifiable using the old public key. End
279 entities who directly trust the old CA key pair MUST also be able to
280 verify certificates signed using the new CA private key. (Required
281 for situations where the old CA public key is "hardwired" into the
282 end entity's cryptographic equipment).
284 12. The Functions of an RA MAY, in some implementations or environ-
285 ments, be carried out by the CA itself. The protocols MUST be
286 designed so that end entities will use the same protocol (but, of
287 course, not the same key!) regardless of whether the communication
288 is with an RA or CA.
290 13. Where an end entity requests a certificate containing a given
291 public key value, the end entity MUST be ready to demonstrate pos-
292 session of the corresponding private key value. This may be accom-
293 plished in various ways, depending on the type of certification
294 request. See Section 2.3, "Proof of Possession of Private Key", for
295 details of the in-band methods defined for the PKIX-CMP (i.e., Cer-
296 tificate Management Protocol) messages.
298 1.4. PKI Management Model
299 Following is a simplified view of the architectural model assumed by
300 the Internet PKI specifications.
301 +---+
302 | C | +------------+
303 | e | <-------------------->| End entity |
304 | r | Operational +------------+
305 | t | transactions ^
306 | | and management | Management
307 | / | transactions | transactions
308 | | |
309 | C | PKI users v
310 | R | -------+-------+--------+------
311 | L | PKI management ^ ^
312 | | entities | |
313 | | v |
314 | R | +------+ |
315 | e | <-------------- | RA | <-----+ |
316 | p | certificate | | | |
317 | o | publish +------+ | |
318 | s | | |
319 | I | v v
320 | t | +------------+
321 | o | <--------------------------| CA |
322 | r | certificate publish +------------+
323 | y | CRL publish ^
324 | | |
325 +---+ | Management
326 | transactions
327 v
328 +------+
329 | CA |
330 +------+
332 Figure 1 - Internet PKI Entities
334 The components in this model are:
335 End Entity: user of PKI certificates and/or end user system that
336 is the subject of a certificate;
338 CA: certification authority;
340 RA: registration authority, i.e., an optional system to
341 which a CA delegates certain management functions;
343 Repository: a system or collection of distributed systems that
344 store certificates and CRLs and serves as a means of
345 distributing these certificates and CRLs to end
346 entities.
348 1.5. Certificate and CRL Repository
349 Some CAs mandate the use of on-line validation services, while oth-
350 ers distribute CRLs to allow certificate users to perform certifi-
351 cate validation themselves. In general, CAs make CRLs available to
352 certificate users by publishing them in the Directory. The Direc-
353 tory is also the normal distribution mechanism for certificates.
354 However, Directory Services are not available in many parts of the
355 Internet today. End entities and CAs may retrieve certificates and
356 CRLs from the repository using HTTP based Certificate Access
357 Protocol(WebCAP). End entities may publish their own certificate in
358 the repository, and RAs and CAs may publish certificates and CRLs in
359 the repository using WebCAP.
361 2. Notational Conventions
362 Since this document describes a set of extensions to the HTTP/1.1
363 protocol, the augmented BNF used herein to describe protocol ele-
364 ments is exactly the same as described in section 2.1 of [Fielding
365 et al., 1997]. Since this augmented BNF uses the basic production
366 rules provided in section 2.2 of [Fielding et al., 1997], these
367 rules apply to this document as well.
369 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
370 "SHOULD", SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
371 document are to be interpreted as described in RFC 2119 [Bradner,
372 1997].
374 3. Protocol Overview
376 3.1. Certificate Web Resource
377 This section provides a description of new type of Web resource, the
378 certificate, and discusses its interaction with the HTTP URL
379 namespace. All CAP compliant servers MUST support HTTP URL namespace
380 model specified herein. HTTP URL Namespace Model
381 The HTTP URL namespace is a hierarchy is delimited with "/" charac-
382 ter. CAP compliant servers must maintain the consistency of the HTTP
383 URL namespace. This model is used to represent the PKI Management
384 model. For example, http://us.oracle.com/us/oracle/certs represent
385 certififcate repository namespace where country=us and
386 organization=oracle. Similary, http://us.oracle.com/us/oracle/crls
387 represent CRL repository for the same management domain.
389 3.2. Registration
390 Registration request is used for sending certification request to
391 CA. This document specifies the MKCERT method to create new certifi-
392 cate. The exact definition of the behavior of MKCERT is defined
393 later in this document.All certificate registration requests all
394 stored in http://hostname.com/country/organization/certreq
395 namespace. Access to this namespace MUST be controlled by CAP
396 servers through RA or CA authentication to the server by providing
397 RA or CA credentials through authrequest xml element. CAP server
398 must support additional security mechanisms to provide mkcert xml
399 responses to CAs.
401 CAP servers MUST support server-to-server communication so that the
402 PKI management model can be mapped into HTTP URL namespace.
404 3.3. Certificate Revocation
405 The revocation request is used to revoke a certificate. To prevent
406 malicious PKI user from revoking other's certificate, this request
407 should be sent with a proof of possession of the secret key. The
408 simplest way is to use conventical application that supports digital
409 signature. This document specifies the RMCERT method to revoke a
410 certificate.
412 3.4. Certificate Retrieval
413 The ceriticate retrieval request is used for retrieving and search-
414 ing certificate, CRLs, and any other information. The CA server may
415 forward a request to other CA server when it does not has sufficient
416 information to response to the request.
418 This document defines a GETCERT method for certificate or CRL
419 retrieval.
421 3.5. Certificate Verification
423 Verification request is used for validation check of certificate.
425 This document defines a new method VRFYCERT to verify the
426 certificate(s) or CRL.
428 3.6. Referrals
429 If a request cannot be fulfilled as the requested certificate is
430 not stored in the HTTP URL namespace, server shall SHALL manage to
431 obtain the access path and send referral response to the user. CAP
432 server includes the referral response specifying the URI of the CAP
433 server which can provide this certificate.
435 3.7. Chaining
436 If a request cannot be fulfilled as the requested certificate is not
437 stored in the WebCAP server, it can forward the request to the
438 another well known access point and this chaining will propagate to
439 the root of the PKI Management hierarchy the certificate is find in
440 the namespace.
442 To implement chaining model, the in root CA produces an extra mes-
443 sage before it responds to the request originator.
445 The request originator, CA1 or PKI application, does not have to
446 send request many times, but have to wait longer time than that of
447 referral model. According to [Mine], the estimated total round trip
448 time is less than that of the referral model. Since CA communicates
449 with a particular CA, the access control at firewall can be easily
450 set up.
452 4. HTTP Methods for Certificate Access
453 The following new HTTP methods use XML as a request and response
454 format. All CAP compliant clients and servers MUST use XML parsers
455 that are compliant with [Bray, Paoli, Sperberg-McQueen, 1998]. All
456 XML used in either requests or responses MUST be, at minimum, well
457 formed. If a server receives ill-formed XML in a request it MUST
458 reject the entire request with a 400 Bad Request. If a client
459 receives ill-formed XML in a response then it MUST NOT assume any-
460 thing about the outcome of the executed method and SHOULD treat the
461 server as malfunctioning.
463 4.1. MKCERT Method
465 The MKCERT method is used to create a new certificate. All CAP com-
466 pliant servers MUST support the MKCERT method.
468 4.1.1. Request
469 MKCERT requests a new certificate with the Certification or Regis-
470 tration Authority specified by the Request URI. If the CA or RA
471 identified by the Request-URI is null or doesnot exist then the
472 MKCERT MUST fail.
474 A MKCERT method MUST be sent with a request message mkcert xml ele-
475 ment containing the certificate request message encoded in [Base64].
477 CA or RAs may use the same method to publish the CRLs into CAP repo-
478 sitory. CAP server MUST validate and authenticate clients depending
479 the requested operations.
481 4.1.2. Response Codes
483 201 Created - The certificate request was submitted successfully.
485 403 Forbidden - the server does not allow the creation of certifi-
486 cate at the given location in its namespace.
488 4.1.3. Example - MKCERT
489 >>Request
490 RMCERT /us/oracle/ HTTP/1.1
491 Host: www.oracle.com
492 Content-Type: text/xml
493 Content-Length: xxxx
495
496
497
498
502 MIIBaTCB9AIBADBvMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEV
503 MBMGA1UEChQMT3JhY2xlIENvcnAuMRQwEgYDVQQLFAtJbnRlck9mZmljZTEeMBwG
504 A1UEAxQVdm9sY2Fuby51cy5vcmFjbGUuY29tMHwwDQYJKoZIhvcNAQEBBQADawAw
505 aAJhALl21FWSXjkKblhyI7JQaqeXxtWZOei+k0FmMP6XwXnddhyu8ydHmwE27TM5
506 i76GDdRxOrpgomBp/DSOT7F5QhmbAwN6T/j78Y5Y4pDqA+/mefaepz/ggp0Om2Im
507 nDfwpwIDAQABoAAwDQYJKoZIhvcNAQEEBQADYQCYtA/KVwoYtNf1jORTXaXYVv1e
508 yXgMEN3V/iPMNFh+zhqNyz3snlZX3h4TaqqtsyAd7WHULsw/AyzMrwt+4XoZSI4n
509 6W8/03oG4vwPKP/23APwMxqGffh32/xL5tUgJ+s=
510
511
513 >>Response
514 HTTP/1.1 201 Created
515 Content-Type: text/xml
516 Content-Length: xxxxx
518
519
520
521 Your request for certificate creation has been forwarded to the
522 certificate authority. When the certificate is created you
523 will be notified through email or you may query the server
524 using the ticketno.
525
527 4.2. RMCERT
528 The RMCERT method is used to revoke a certificate or set of certifi-
529 cates.
531 4.2.1. Request
532 The RMCERT method processes instructions specified in the request
533 body to revoke certificates defined by the Request-URI.
535 All CAP compliant servers MUST support the RMCERT method and MUST
536 process instructions that are specified using the revokecert XML
537 elements.
539 Instruction processing MUST occur in the order instructions are
540 received (i.e., from top to bottom). Instructions MUST either all
541 be executed or none executed. Thus if any error occurs during pro-
542 cessing all executed instructions MUST be undone and a proper error
543 result returned.
545 4.2.2. Status Codes for use with Multi-Status
547 The following are examples of response codes one would expect to be
548 used in a Multi-Status response for this method.
550 200 OK - The command succeeded. As there can be a mixture of sets
551 and removes in a body, a 201 Created seems inappropriate.
553 403 Forbidden - The client, for reasons the server chooses not to
554 specify, cannot revoke the specified certificate.
556 409 Conflict - The client has provided a value whose semantics are
557 not appropriate for the certificate. This includes trying to revoke
558 the certificate already revoked.
560 4.2.3. Example - RMCERT
561 >>Request
563 RMCERT /us/oracle/ HTTP/1.1
564 Host:us.oracle.com
565 Content-Type: text/xml
566 Content-Length: xxxx
568
569
570
572
573
577 MIICZzCCAfECAQIwDQYJKoZIhvcNAQEEBQAwgaQxCzAJBgNVBAYTAlVTMRMwEQYD
578 VQQIEwpDYWxpZm9ybmlhMSowKAYDVQQKFCFDb25zZW5zdXMgRGV2ZWxvcG1lbnQg
579 Q29ycG9yYXRpb24xIDAeBgNVBAsUF0NlcnQgUGx1cyBYLjUwOSBUb29sa2l0MTIw
580 MAYDVQQDFClDb25zZW5zdXMgRGV2ZWxvcG1lbnQgVGVzdCBDQSBmb3IgUTMgMTk5
581 NzAeFw05NzA2MzAwMDAwMDBaFw05NzA5MzAyMzU5NTlaMIGXMQswCQYDVQQGEwJV
582 UzETMBEGA1UECBMKQ2FsaWZvcm5pYTEqMCgGA1UEChQhQ29uc2Vuc3VzIERldmVs
583 b3BtZW50IENvcnBvcmF0aW9uMS0wKwYDVQQLFCRTU0wgUGx1cyBURVNUSU5HIEFO
584 RCBFVkFMVUFUSU9OIE9OTFkxGDAWBgNVBAMUDyouY29uc2Vuc3VzLmNvbTB8MA0G
585 CSqGSIb3DQEBAQUAA2sAMGgCYQCmvUdBE7ivlxDrZKlHGFfaMhiDAD0/OGmm+98+
586 4MlqLpF0Bm279kn7weCXzaWsPhCTlis3zi+BeTM8PDA3vZJvzfRcCSxChQZpxqrx
587 HdaSWPuS0nhSyfBHEZ2a2tQiMtcCAwEAATANBgkqhkiG9w0BAQQFAANhAAohxBYT
588 Hr+kH5gCjXFdfCUsMHIuN8qGzvmDCdJbz76nx3YVZmjCYvXJtkt4MMcIF5rKQNHi
589 I4KxIDdjSY5rxpvhKG5GQ7+m2pq3fAtnbtB2ppC5sHjXe66duZYD33hi7A==
590
591
595 MIICZzCCAfECAQIwDQYJKoZIhvcNAQEEBQAwgaQxCzAJBgNVBAYTAlVTMRMwEQYD
596 VQQIEwpDYWxpZm9ybmlhMSowKAYDVQQKFCFDb25zZW5zdXMgRGV2ZWxvcG1lbnQg
597 Q29ycG9yYXRpb24xIDAeBgNVBAsUF0NlcnQgUGx1cyBYLjUwOSBUb29sa2l0MTIw
598 MAYDVQQDFClDb25zZW5zdXMgRGV2ZWxvcG1lbnQgVGVzdCBDQSBmb3IgUTMgMTk5
599 NzAeFw05NzA2MzAwMDAwMDBaFw05NzA5MzAyMzU5NTlaMIGXMQswCQYDVQQGEwJV
600 UzETMBEGA1UECBMKQ2FsaWZvcm5pYTEqMCgGA1UEChQhQ29uc2Vuc3VzIERldmVs
601 b3BtZW50IENvcnBvcmF0aW9uMS0wKwYDVQQLFCRTU0wgUGx1cyBURVNUSU5HIEFO
602 RCBFVkFMVUFUSU9OIE9OTFkxGDAWBgNVBAMUDyouY29uc2Vuc3VzLmNvbTB8MA0G
603 CSqGSIb3DQEBAQUAA2sAMGgCYQCmvUdBE7ivlxDrZKlHGFfaMhiDAD0/OGmm+98+
604 4MlqLpF0Bm279kn7weCXzaWsPhCTlis3zi+BeTM8PDA3vZJvzfRcCSxChQZpxqrx
605 HdaSWPuS0nhSyfBHEZ2a2tQiMtcCAwEAATANBgkqhkiG9w0BAQQFAANhAAohxBYT
606 Hr+kH5gCjXFdfCUsMHIuN8qGzvmDCdJbz76nx3YVZmjCYvXJtkt4MMcIF5rKQNHi
607 I4KxIDdjSY5rxpvhKG5GQ7+m2pq3fAtnbtB2ppC5sHjXe66duZYD33hi7A==
608
609
610 NvcnBvcmF0aW9uMS0wKwYDVQQLFCRTU0wgU
611
612
616 ETMBEGA1UECBMKQ2FsaWZvcm5pYTEqMC
617
618
620 >> Response
621 HTTP/1.1 207 Multi-Status
622 Content-Type: text/xml
623 Content-Length: xxxxx
625
626
627
628
629 In this example, the client requests the server to revoke two certicates
630 issued by a CA in US for Oracle Corp.
632 4.3. GETCERT
633 The GETCERT method retrieves certificate(s) from the CA repository
634 specified by the Request-URI. All CAP compliant resources MUST sup-
635 port the GETCERT method and the getcert XML element along with all
636 XML elements defined for use with that element.
638 A client SHOULD submit a getcert XML element in the body of the
639 request method describing what information is being requested.
641 All servers MUST support returning a response of content type
642 text/xml that contains a multi-status XML element that describes the
643 results of the attempts to retrieve the various certificates.
645 If there is an error retrieving a certificate then a proper error
646 result MUST be included in the response. A request to retrieve the
647 certificate which does not exist is an error and MUST be noted, if
648 the response uses a multi-status XML element, with a response XML
649 element which contains a 404 Not Found status value.
651 The results of this method SHOULD NOT be cached.
653 4.3.1. Status Codes for use with Multi-Status
655 The following are examples of response codes one would expect to be
656 used in a Multi-Status response for this method.
658 200 OK - The command succeeded. As there can be a mixture of sets
659 and removes in a body, a 201 Created seems inappropriate.
661 403 Forbidden - The client, for reasons the server chooses not to
662 specify, cannot revoke the specified certificate.
664 409 Conflict - The client has provided a value whose semantics are
665 not appropriate for the certificate. This includes trying to revoke
666 the certificate already revoked.
668 4.3.2. Example - Retrieving Certificate
670 >>Request
672 GETCERT /us/oracle/ HTTP/1.1
673 Host: us.oracle.com
674 Content-type: text/xml
675 Content-Length: xyz
677
678
679
680
681 MBMGA1UEChQMT3JhY2xlIENvcnAuMRQwEgYDVQQLFAtJbnRlck9mZmljZTEeMBwG
682 A1UEAxQVdm9sY2Fuby51cy5vcmFjbGUuY29tMHwwDQYJKoZIhvcNAQEBBQADawAw
683 aAJhALl21FWSXjkKblhyI7JQaqeXxtWZOei+k0FmMP6XwXnddhyu8ydHmwE27TM5
684 i76GDdRxOrpgomBp/DSOT7F5QhmbAwN6T/j78Y5Y4pDqA+/mefaepz/ggp0Om2Im
685
686
687 i76GDdRxOrpgomBp/DSOT7F5QhmbAwN6T/j78Y5Y4pDqA+/mefaepz/ggp0Om2Im
688 nDfwpwIDAQABoAAwDQYJKoZIhvcNAQEEBQADYQCYtA/KVwoYtNf1jORTXaXYVv1e
689 yXgMEN3V/iPMNFh+zhqNyz3snlZX3h4TaqqtsyAd7WHULsw/AyzMrwt+4XoZSI4n
690 6W8/03oG4vwPKP/23APwMxqGffh32/xL5tUgJ+s=
691
692
694 >>Response
696 HTTP/1.1 207 Multi-Status
697 Content-Type: text/xml
698 Content-Length: xxxxx
700
701
702
703
704
708 Base64 encoded certificate goes here
709
710
711 Base64 encoded crl goes here
712
713
714 In this example, request is sent for retrieving certificates for subject
715 name identified by Base64 encoded certificateRequest. CAP server return
716 multi-status response containing certificates encoded in base64 format.
718 4.4. VRFYCERT
719 The VRFYCERT method verifies the validity of the certificate speci-
720 fied in the request body.
722 All WebCAP compliant resources MUST support the VRFYCERT method.
723 However, support for the VRFYCERT method does not guarantee the
724 ability to verify the certificate successfully. For example,
725 separate programs may control access to CIT access paths. As a
726 result, it may not be possible to verify the certificates for its
727 validity. In such case, server returns error code.
729 4.4.1. Status Codes for use with Multi-Status
731 The following are examples of response codes one would expect to be
732 used in a Multi-Status response for this method.
734 200 OK - The command succeeded. As there can be a mixture of sets
735 and removes in a body, a 201 Created seems inappropriate.
737 403 Forbidden - The client, for reasons the server chooses not to
738 specify, cannot revoke the specified certificate.
740 409 Conflict - The client has provided a value whose semantics are
741 not appropriate for the certificate. This includes trying to revoke
742 the certificate already revoked.
744 4.4.2. Example - VRFYCERT
746 >>Request
747 VRFYCERT /us/oracle/ HTTP/1.1
748 Host: us.oracle.com
749 Content-Type: text/xml
750 Content-Length: xxxx
752
753
754
755
756 MIICZzCCAfECAQIwDQYJKoZIhvcNAQEEBQAwgaQxCzAJBgNVBAYTAlVTMRMwEQYD
757 VQQIEwpDYWxpZm9ybmlhMSowKAYDVQQKFCFDb25zZW5zdXMgRGV2ZWxvcG1lbnQg
758 Q29ycG9yYXRpb24xIDAeBgNVBAsUF0NlcnQgUGx1cyBYLjUwOSBUb29sa2l0MTIw
759 MAYDVQQDFClDb25zZW5zdXMgRGV2ZWxvcG1lbnQgVGVzdCBDQSBmb3IgUTMgMTk5
760 NzAeFw05NzA2MzAwMDAwMDBaFw05NzA5MzAyMzU5NTlaMIGXMQswCQYDVQQGEwJV
761 UzETMBEGA1UECBMKQ2FsaWZvcm5pYTEqMCgGA1UEChQhQ29uc2Vuc3VzIERldmVs
762 b3BtZW50IENvcnBvcmF0aW9uMS0wKwYDVQQLFCRTU0wgUGx1cyBURVNUSU5HIEFO
763 RCBFVkFMVUFUSU9OIE9OTFkxGDAWBgNVBAMUDyouY29uc2Vuc3VzLmNvbTB8MA0G
764 CSqGSIb3DQEBAQUAA2sAMGgCYQCmvUdBE7ivlxDrZKlHGFfaMhiDAD0/OGmm+98+
765 4MlqLpF0Bm279kn7weCXzaWsPhCTlis3zi+BeTM8PDA3vZJvzfRcCSxChQZpxqrx
766 HdaSWPuS0nhSyfBHEZ2a2tQiMtcCAwEAATANBgkqhkiG9w0BAQQFAANhAAohxBYT
767 Hr+kH5gCjXFdfCUsMHIuN8qGzvmDCdJbz76nx3YVZmjCYvXJtkt4MMcIF5rKQNHi
768 I4KxIDdjSY5rxpvhKG5GQ7+m2pq3fAtnbtB2ppC5sHjXe66duZYD33hi7A==
769
770
771 UzETMBEGA1UECBMKQ2FsaWZvcm5pYTEqMCgGA1UEChQhQ29uc2Vuc3VzIERldmVs
772 b3BtZW50IENvcnBvcmF0aW9uMS0wKwYDVQQLFCRTU0wgUGx1cyBURVNUSU5HIEFO
773 RCBFVkFMVUFUSU9OIE9OTFkxGDAWBgNVBAMUDyouY29uc2Vuc3VzLmNvbTB8MA0G
774 MIICZzCCAfECAQIwDQYJKoZIhvcNAQEEBQAwgaQxCzAJBgNVBAYTAlVTMRMwEQYD
775 VQQIEwpDYWxpZm9ybmlhMSowKAYDVQQKFCFDb25zZW5zdXMgRGV2ZWxvcG1lbnQg
776 Q29ycG9yYXRpb24xIDAeBgNVBAsUF0NlcnQgUGx1cyBYLjUwOSBUb29sa2l0MTIw
777 MAYDVQQDFClDb25zZW5zdXMgRGV2ZWxvcG1lbnQgVGVzdCBDQSBmb3IgUTMgMTk5
778 NzAeFw05NzA2MzAwMDAwMDBaFw05NzA5MzAyMzU5NTlaMIGXMQswCQYDVQQGEwJV
779 CSqGSIb3DQEBAQUAA2sAMGgCYQCmvUdBE7ivlxDrZKlHGFfaMhiDAD0/OGmm+98+
780 4MlqLpF0Bm279kn7weCXzaWsPhCTlis3zi+BeTM8PDA3vZJvzfRcCSxChQZpxqrx
781 HdaSWPuS0nhSyfBHEZ2a2tQiMtcCAwEAATANBgkqhkiG9w0BAQQFAANhAAohxBYT
782 Hr+kH5gCjXFdfCUsMHIuN8qGzvmDCdJbz76nx3YVZmjCYvXJtkt4MMcIF5rKQNHi
783 I4KxIDdjSY5rxpvhKG5GQ7+m2pq3fAtnbtB2ppC5sHjXe66duZYD33hi7A==
784
785
787 >>Response
788 HTTP/1.1 207 Multi-Status
789 Content-Type: text/xml
790 Content-Length: xxxxx
792
793
794
795
796
797
799 4.5. The OPTIONS Method
800 The OPTIONS method allows the client to discover the CAP server
801 capabilities.
803 4.5.1. Request
804 The client issues the OPTIONS method against a CAP server. This is a
805 normal invocation of OPTIONS defined in [RFC2068].
807 4.5.2. Example
809 >> Request
810 OPTIONS /us/oracle/ HTTP/1.1
811 Connection: Close
812 Host:certserv.us.oracle.com
814 >> Response
815 HTTP/1.1 200 OK
816 Date: Tue, 20 Jan 1998 20:52:29 GMT
817 Connection: close
818 Accept-Ranges: none
819 Allow: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, MKCERT,GETCERT,
820 RMCERT,VRFYCERT
821 Public: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, MKCERT,GETCERT,
822 RMCERT,VRFYCERT
823 CAP: 1.0
825 5. HTTP Headers for Certificate Access
827 5.1. CAP Header
828 CAP = "CAP" ":" "1.0"
830 This header indicates that the resource supports the CAP schema and
831 protocol as specified. All CAP compliant servers MUST return the CAP
832 header on all OPTIONS responses.
834 6. Status Code Extensions to HTTP/1.1
835 The following status codes are added to those defined in HTTP/1.1
836 [Fielding et al., 1997].
838 6.1. 102 Processing
839 Methods can potentially take a long period of time to process, espe-
840 cially validating certificates not in the access path of the WebCAP
841 server. In such cases the client may time-out the connection while
842 waiting for a response. To prevent this the server may return a 102
843 status code to indicate to the client that the server is still pro-
844 cessing the method.
846 6.2. 207 Multi-Status
847 The response provides status for multiple independent operations.
849 6.3. 424 Method Failure
850 The method was not executed on a particular certificate within its
851 scope because some part of the method's execution failed causing the
852 entire method to be aborted.
854 6.4. 425 Insufficient Privileges
855 The resource does not have sufficient privileges to perform the
856 requested operation.
858 7. Multi-Status Response
859 The default 207 Multi-Status response body is a text/xml HTTP entity
860 that contains a single XML element called multi-status, which con-
861 tains a set of XML elements called response which contain 200, 300,
862 400, and 500 series status codes generated during the method invoca-
863 tion. 100 series status codes SHOULD NOT be recorded in a response
864 XML element.
866 8. XML Element Definitions
868 8.1. Element References
870 A CAP XML element or one of its child XML elements, may contain an
871 XML attribute that refers to another element.
873 8.2. Opaque Embedded Data
875 Most of the CAP messages expects that opaque data will be embedded
876 within CAP messages. For e.g.,
877 o the content of the Certificate element
879 o the content of the Signature element
881 The embedded data is called opaque because it is not processed
882 by XML processor, but is instead passed to or from CAP server or
883 client.
885 8.3. Identifying Languages
887 CAP uses [XML] Language Identification to specify which languages
888 used within the content and attributes of CAP Messages.
890 o a mandatory XML:Lang attribute is contained on every CAP
891 message which contains attributes or content which may need
892 to be displayed or printed in a particular language
894 8.4. mkcert XML element
895
897 mkcert XML element defines Base64 encoded certificate request mes-
898 sage.
900 8.5. certrequest XML element
901
903 certrequest XML element defines the certificate request message
904 encoded in Base64.
906 8.6. rmcert XML element
907
916 revokecert XML element defines certificate revocation information
917 encoded in Base64.
919 8.8. getcert XML element
920
929 getcertinfo XML element defines subject information of the certificate
930 that need to be retrieved from the certificate repository. This information
931 is encoded in Base64.
933 8.10. vrfycert XML element
934
944
948 8.11.1. Attributes hashtype: The hash algorithm used to calculate the
949 hash in the content of the element. Valid values are sha1,
950 md2,md5
951 8.11.2. Content
952 PCDATA: Contains the actual hash value, [Base64] encoded, of the
953 element identified by "elementref" and calculated using the algo-
954 rithm specified by hashtype.
956 8.12. signature XML element
958 This contains the actual digital signature resulting from signing
959 the information contained within signed XML element.
961 Each Signature element digitally signs one or more messages.
963 The signature element:
964 o hashes one or more elements in one or more CAP
965 Messages within the same CAP Transaction
967 o concatenates these hashes and any additional information to be
968 signed in the form of authenticated attributes into a
969 signed xml element, and
971 o signs the signed element using the certificate
972 identified in the certref attribute of the signature element.
974 Note that a signed element may be signed by more than one
975 signature element.
977 The definition of a signature XML element is as follows.
978
979
984 8.12.1. Attributes
985 hashtype: The hash algorithm used to calculate the hash in the
986 content of the element. Valid values are:sha1, md2,md5
987 algorithm: The algorithm used to calculate digital signature from
988 the hash. Valid values are:
990 RSA signature uses the [RSA] algorithm
991 DSA signature uses the [DSA] algorithm
992 Each Signature element digitally signs one or more messages.
994 8.13. certificate XML element
995 A certificate XML element contains a digital certificate which is to
996 be used in order to create or check a signature element.
997
998
1002 8.13.1. Attributes
1003 certtype: The type of Certificate contained within the XMLCertifi-
1004 cate element. Valid values are: x509v1, x509v2, x509v3. certref:
1005 unique id used to reference this element in other element in the
1006 same document tree.
1008 8.13.2. Content
1009 PCDATA: The actual certificate of the type specified by certtype
1010 encoded in Base64 format.
1012 9. Signing XML documents
1013 This section describes a simple procedure to sign and verify XML
1014 messages sent between CAP client and server.
1016 1. The data signed is always an "entire" XML element.
1017 - for non EMPTY elements , whole XML element starting with leftmost "<"
1018 and ending with rightmost ">" of the end of the element tag.
1020 - for EMPTY elements, starting with, and including the leftmost
1021 "<" of the element and finishing with, and including, the rightmost
1022 ">" of the element.
1023 2. Convert all characters in the element to [UTF8] format.
1025 3. Resolve default attribute values, external entities and all character
1026 and entity references in the element so that they are completely
1027 resolved. Sort the original and generated attributes in ascending
1028 attribute name order according to the UTF8 encoding of the
1029 attribute name.
1031 4. Donot include comments and processing instructions (PIs),
1033 5. Reduce all attributes to their canonical form using the
1034 attribute type in the DTD. Replace all single and double quotes
1035 present in attributes with ' and " respectively so that
1036 attributes can be enclosed in double quotes
1038 6. Remove non essential whitespace and represent required whitespace
1039 by a single space character . Remove all whitespace in the
1040 element content.
1042 7. Generate the content of all start tags using only the element
1043 name and the attributes as described above. If the element is
1044 an "empty" element then generate it using the single empty tag
1045 format, with a trailing slash. Generate end tags using only the
1046 element name, with no added whitespace.
1048 8. All character data is generated inside a CDATA section. Any
1049 CDATA end sequences ("]]>") within the data are replaced by
1050 "]]]]>" in order to escape the CDATA end sequence.
1052 9. Start tags, end tags, empty tags, CDATA sections, and text
1053 sections are assembled in the same order as the original
1054 document.
1056 9.1. Calculating Hashes and Signatures
1057 1. Convert the data to be signed into a byte stream in the
1058 canonical encoding format defined above
1060 2. Calculate the hash or signature using appropriate algorithm
1061 and rules assuming "big-endian" byte order.
1063 3. Encode the result using [Base64] encoding.
1065 4. Place the encoded result, most significant byte first, in
1066 either:
1067 - the content of the signed element , or
1068 - the content of the signature element.
1070 9.2. Checking Hashes and Signatures
1071 Checking of a signature therefore consists of:
1073 1. Verify the signed element and create a byte stream in the
1074 canonical encoding format defined above.
1076 2. For each signed element in the signed element, verify if HASH
1077 values are correct or compute the signature from the certificate
1078 references included in the signed XML element.
1079 for each Hash Element in the signature:
1080 - check if the [XML] element identified by the "elementref" attribute
1081 of the Hash Element refers to an element available from the message
1082 stream.
1083 - if the [XML] element is available check that the hash value
1084 of the XML element contained inside the content of the signed element
1085 is correctly calculated.
1086 for the signature as a whole verifying that the content of the
1087 signature element has been correctly calculated.
1089 10. Security Consideration
1090 10.1. Confidentiality of transaction
1092 To prevent message from being eavesdropped, secure communication
1093 channel such as SSL shall be used. Especially, initial registration
1094 process is critical to eavesdropping.
1096 10.2. Non-Repudiation
1097 The verify request supports the time to be checked and digitally
1098 signed response. This can avoid a message sender from denying the
1099 message. To enable this service, any CA must manage all certificates
1100 which it has already issued, including revoked certificates.
1102 10.3. Privacy
1103 In the lookup request, the support of substring matching facility
1104 may distribute private information to outsiders, and thereby may be
1105 used for sending an advertisement via email.
1107 11. References
1109 [XML] Bray, Tim, Jean Paoli, and CM Sperberg-McQueen, "Extensible
1110 Markup Language(XML): Part I Syntax", World Wide Web Consortium
1111 Working Draft, February 1998. Available at
1112 http://www.w3.org/TR/REC-xml
1114 [COR95] ISO/IEC JTC 1/SC 21, Technical Corrigendum 2 to ISO/IEC
1115 9594-8: 1990 & 1993 (1995:E), July 1995.
1117 [CRMF] M. Myers, C. Adams, D. Solo, D. Kemp, "Certificate Request
1118 Message Format", Internet Draft draft-ietf-pkix-crmf-0x.txt (work in
1119 progress).
1121 [PKCS7] RSA Laboratories, "The Public-Key Cryptography Standards
1122 (PKCS)", RSA Data Security Inc., Redwood City, California, November
1123 1993 Release.
1125 [PKCS10] RSA Laboratories, "The Public-Key Cryptography Standards
1126 (PKCS)", RSA Data Security Inc., Redwood City, California, November
1127 1993 Release.
1129 [PKCS11] RSA Laboratories, "The Public-Key Cryptography Standards -
1130 PKCS #11: Cryptographic token interface standard", RSA Data Secu-
1131 rity Inc., Redwood City, California, April 28, 1995.
1133 [RFC1847] J. Galvin, S. Murphy, S. Crocker, N. Freed, "Security Mul-
1134 tiparts for MIME: Multipart/Signed and Multipart/ Encrypted",
1135 Internet Request for Comments 1847, October 1995.
1137 [RFC2104] H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed Hashing
1138 for Message Authentication", Internet Request for Comments 2104,
1139 February, 1997.
1141 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
1142 Requirement Levels", Internet Request for Comments 2119 (Best
1143 Current Practice: BCP 14), March, 1997.
1145 [RFC2202] P. Cheng, R. Glenn, "Test Cases for HMAC-MD5 and HMAC-
1146 SHA-1", Internet Request for Comments 2202, September 1997.
1148 [X509-AM] ISO/IEC JTC1/SC 21, Draft Amendments DAM 4 to ISO/IEC
1149 9594-2, DAM 2 to ISO/IEC 9594-6, DAM 1 to ISO/IEC 9594-7, and DAM 1
1150 to ISO/IEC 9594-8 on Certificate Extensions,
1152 12. Author's Address
1154 Surendra Reddy
1155 Oracle Corporation
1156 500 Oracle Parkway
1157 M/S 6op3
1158 Redwoodshores, CA 94065
1160 Phone: +1 650 506 5441
1161 Fax: +1 650 654 6205
1162 EMail: SKREDDY@us.oracle.com
1164 Expires October 19, 1998