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