PKIX Working Group Surendra Reddy Internet Draft Oracle Corporation draft-ietf-pkix-webcap-00.txt April 19, 1998 Expires October 19, 1998 WEB based Certificate Access Protocol-- WebCAP/1.0 Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or made obsolete by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress". To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this document is unlimited. Please send comments to the PKIX working group at ietf-pkix@imc.org, which may be joined by sending a message with subject "subscribe" to ietf-pkix- request@imc.org. Abstract This document describes the Internet X.509 Public Key Infrastructure (PKI) Certificate Access Protocols. Protocol messages are defined for all relevant aspects of certificate creation and management. Note that ''certificate'' in this document refers to an X.509v3 Certificate as defined in [COR95, X509-AM]. This document specifies a set of methods, headers, and content-types ancillary to HTTP/1.1 to publish, retrieve X.509 certificates and Certificate Revocation Lists. This protocol also facilitates determining current status of a digital certificate without the use of CRLs. This protocol defines new methods, request and response bodies, error codes to HTTP/1.1 protocol for securely publishing, retrieving, and validation certificates across a firewalls. Surendra Reddy [Page 1] draft-ietf-pkix-webcap-00.txt April 1998 A various certificate related information that includes certificates, CRLs, and certification authority (CA) policy are retrieved from an integrated single authority access point specified in X.509 version 3 extensions. 1. Introduction WebCAP protocol provides a highly scalable and distributed architec- ture. Since HTTP is widely deployed protocol on the internet, deploying the PKI infrastructure on HTTP servers through WebCAP extensions provides more flexibility, all internet users can use it even if the site they belong has a firewall against intruders. The WEBCAP provides some useful facilities for PKI; an information cach- ing by both a proxy server and client software, a secure transport layer service for confidentiality, a flexible request forwarding which can be used in CA and CA communication. WebCAP protocol supports: o registration - whereby a user establishes its identity to CA prior to that CA issuing a certificate or certificates for that user. o initialization - initialization of necessary key materials into the client system. o certification - issues certificates to a user's public key and returns that certificate to the client system o revocation - performs certification revocation by authorized users. o queries - supports basic queries for certificate retrieval, validation. o cross certification - exchange information between CAs to establish a cross certifications. In HTTP/1.1, method parameter information was exclusively encoded in HTTP headers. Unlike HTTP/1.1, WebCAP, encodes method parameter information either in an Extensible Markup Language (XML) [Bray, Paoli, Sperberg-McQueen, 1998] request entity body, or in an HTTP header. The use of XML to encode method parameters was motivated by the ability to add extra XML elements to existing structures, pro- viding extensibility, and by XML's ability to encode information in ISO 10646 character sets, providing internationalization support. As a rule of thumb, parameters are encoded in XML entity bodies when Surendra Reddy [Page 2] draft-ietf-pkix-webcap-00.txt April 1998 they have unbounded length, or when they may be shown to a human user and hence require encoding in an ISO 10646 character set. Oth- erwise, parameters are encoded within HTTP headers. In addition to encoding method parameters, XML is used in WebCAP to encode the responses from methods, providing the extensibility and internationalization advantages of XML for method output, as well as input. The XML namespace extension is also used in this specification in order to allow for new XML elements to be added without fear of col- liding with other element names. While the status codes provided by HTTP/1.1 are sufficient to describe most error conditions encountered by WebCAP methods, there are some errors that do not fall neatly into the existing categories. 1.1. PKI Management Model Before specifying particular message formats and procedures we first define the entities involved in PKI management and their interac- tions (in terms of the PKI management functions required). We then group these functions in order to accommodate different identifiable types of end entities. 1.2. Definitions of PKI Entities The entities involved in PKI management include the end entity (i.e., the entity to be named in the subject field of a certificate) and the certification authority (i.e., the entity named in the issuer field of a certificate). A registration authority MAY also be involved in PKI management. 1.2.1. Subjects and End Entities The term "subject" is used here to refer to the entity named in the subject field of a certificate; when we wish to distinguish the tools and/or software used by the subject (e.g., a local certificate management module) we will use the term "subject equipment". In gen- eral, the term "end entity" (EE) rather than subject is preferred in order to avoid confusion with the field name. It is important to note that the end entities here will include not only human users of applications, but also applications themselves (e.g., for IP security). This factor influences the protocols which the PKI management operations use; for example, application software is far more likely to know exactly which certificate extensions are required than are human users. PKI management entities are also end entities in the sense that they are sometimes named in the subject field of a certificate or cross-certificate. Where appropriate, the Surendra Reddy [Page 3] draft-ietf-pkix-webcap-00.txt April 1998 term "end- entity" will be used to refer to end entities who are not PKI management entities. All end entities require secure local access to some information -- at a minimum, their own name and private key, the name of a CA which is directly trusted by this entity and that CA's public key (or a fingerprint of the public key where a self-certified version is available elsewhere). Implementations MAY use secure local storage for more than this minimum (e.g., the end entity's own certificate or application-specific information). The form of storage will also vary -- from files to tamper-resistant cryptographic tokens. Such local trusted storage is referred to here as the end entity's Per- sonal Security Environment (PSE). Though PSE formats are beyond the scope of this document (they are very dependent on equipment, et cetera), a generic interchange for- mat for PSEs is defined here - a certification response message MAY be used. 1.2.2. Certification Authority The certification authority (CA) may or may not actually be a real "third party" from the end entity's point of view. Quite often, the CA will actually belong to the same organization as the end entities it supports. Again, we use the term CA to refer to the entity named in the issuer field of a certificate; when it is necessary to distinguish the software or hardware tools used by the CA we use the term "CA equip- ment". The CA equipment will often include both an "off-line" component and an "on-line" component, with the CA private key only available to the "off- line" component. This is, however, a matter for imple- menters (though it is also relevant as a policy issue). We use the term "root CA" to indicate a CA that is directly trusted by an end entity; that is, securely acquiring the value of a root CA public key requires some out-of-band step(s). This term is not meant to imply that a root CA is necessarily at the top of any hierarchy, simply that the CA in question is trusted directly. A "subordinate CA" is one that is not a root CA for the end entity in question. Often, a subordinate CA will not be a root CA for any entity but this is not mandatory. 1.2.3. Registration Authority In addition to end-entities and CAs, many environments call for the existence of a Registration Authority (RA) separate from the Surendra Reddy [Page 4] draft-ietf-pkix-webcap-00.txt April 1998 Certification Authority. The functions which the registration author- ity may carry out will vary from case to case but MAY include per- sonal authentication, token distribution, revocation reporting, name assignment, key generation, archival of key pairs, et cetera. This document views the RA as an OPTIONAL component - when it is not present the CA is assumed to be able to carry out the RA's functions so that the PKI management protocols are the same from the end- entity's point of view. Again, we distinguish, where necessary, between the RA and the tools used (the "RA equipment"). Note that an RA is itself an end entity. We further assume that all RAs are in fact certified end entities and that RAs have private keys that are usable for signing. How a particular CA equipment identifies some end entities as RAs is an implementation issue (i.e., this docu- ment specifies no special RA certification operation). We do not man- date that the RA is certified by the CA with which it is interacting at the moment (so one RA may work with more than one CA whilst only being certified once). In some circumstances end entities will communicate directly with a CA even where an RA is present. For example, for initial registration and/or certification the subject may use its RA, but communicate directly with the CA in order to refresh its certificate. 1.3. PKI Management Requirements The protocols given here meet the following requirements on PKI management. 1. PKI management MUST conform to the ISO 9594-8 standard and the associated amendments (certificate extensions) 2. PKI management MUST conform to the other parts of this series. 3. It MUST be possible to regularly update any key pair without affecting any other key pair. 4. The use of confidentiality in PKI management protocols MUST be kept to a minimum in order to ease regulatory problems. 5. PKI management protocols MUST allow the use of different industry- standard cryptographic algorithms, (specifically including RSA, DSA, MD5, SHA-1) -- this means that any given CA, RA, or end entity may, in principle, use whichever algorithms suit it for its own key pair(s). Surendra Reddy [Page 5] draft-ietf-pkix-webcap-00.txt April 1998 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. 7. PKI management protocols MUST support the publication of certifi- cates by the end-entity concerned, by an RA, or by a CA. Different implementations and different environments may choose any of the above approaches. 8. PKI management protocols MUST support the production of Certifi- cate Revocation Lists (CRLs) by allowing certified end entities to make requests for the revocation of certificates - this MUST be done in such a way that the denial-of-service attacks which are possible are not made simpler. 9. PKI management protocols MUST be usable over a variety of "tran- sport" mechanisms, specifically including mail, http, TCP/IP and ftp. 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). 11. A graceful, scheduled change-over from one non-compromised CA key pair to the next (CA key update) MUST be supported (note that if the CA key is compromised, re-initialization MUST be performed for all entities in the domain of that CA). An end entity whose PSE con- tains the new CA public key (following a CA key update) MUST also be able to verify certificates verifiable using the old public key. End entities who directly trust the old CA key pair MUST also be able to verify certificates signed using the new CA private key. (Required for situations where the old CA public key is "hardwired" into the end entity's cryptographic equipment). 12. The Functions of an RA MAY, in some implementations or environ- ments, be carried out by the CA itself. The protocols MUST be designed so that end entities will use the same protocol (but, of Surendra Reddy [Page 6] draft-ietf-pkix-webcap-00.txt April 1998 course, not the same key!) regardless of whether the communication is with an RA or CA. 13. Where an end entity requests a certificate containing a given public key value, the end entity MUST be ready to demonstrate pos- session of the corresponding private key value. This may be accom- plished in various ways, depending on the type of certification request. See Section 2.3, "Proof of Possession of Private Key", for details of the in-band methods defined for the PKIX-CMP (i.e., Cer- tificate Management Protocol) messages. Surendra Reddy [Page 7] draft-ietf-pkix-webcap-00.txt April 1998 1.4. PKI Management Model Following is a simplified view of the architectural model assumed by the Internet PKI specifications. +---+ | C | +------------+ | e | <-------------------->| End entity | | r | Operational +------------+ | t | transactions ^ | | and management | Management | / | transactions | transactions | | | | C | PKI users v | R | -------+-------+--------+------ | L | PKI management ^ ^ | | entities | | | | v | | R | +------+ | | e | <-------------- | RA | <-----+ | | p | certificate | | | | | o | publish +------+ | | | s | | | | I | v v | t | +------------+ | o | <--------------------------| CA | | r | certificate publish +------------+ | y | CRL publish ^ | | | +---+ | Management | transactions v +------+ | CA | +------+ Figure 1 - Internet PKI Entities The components in this model are: End Entity: user of PKI certificates and/or end user system that is the subject of a certificate; CA: certification authority; RA: registration authority, i.e., an optional system to which a CA delegates certain management functions; Repository: a system or collection of distributed systems that store certificates and CRLs and serves as a means of Surendra Reddy [Page 8] draft-ietf-pkix-webcap-00.txt April 1998 distributing these certificates and CRLs to end entities. 1.5. Certificate and CRL Repository Some CAs mandate the use of on-line validation services, while oth- ers distribute CRLs to allow certificate users to perform certifi- cate validation themselves. In general, CAs make CRLs available to certificate users by publishing them in the Directory. The Direc- tory is also the normal distribution mechanism for certificates. However, Directory Services are not available in many parts of the Internet today. End entities and CAs may retrieve certificates and CRLs from the repository using HTTP based Certificate Access Protocol(WebCAP). End entities may publish their own certificate in the repository, and RAs and CAs may publish certificates and CRLs in the repository using WebCAP. 2. Notational Conventions Since this document describes a set of extensions to the HTTP/1.1 protocol, the augmented BNF used herein to describe protocol ele- ments is exactly the same as described in section 2.1 of [Fielding et al., 1997]. Since this augmented BNF uses the basic production rules provided in section 2.2 of [Fielding et al., 1997], these rules apply to this document as well. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [Bradner, 1997]. 3. Protocol Overview 3.1. Certificate Web Resource This section provides a description of new type of Web resource, the certificate, and discusses its interaction with the HTTP URL namespace. All CAP compliant servers MUST support HTTP URL namespace model specified herein. HTTP URL Namespace Model The HTTP URL namespace is a hierarchy is delimited with "/" charac- ter. CAP compliant servers must maintain the consistency of the HTTP URL namespace. This model is used to represent the PKI Management model. For example, http://us.oracle.com/us/oracle/certs represent certififcate repository namespace where country=us and organization=oracle. Similary, http://us.oracle.com/us/oracle/crls represent CRL repository for the same management domain. Surendra Reddy [Page 9] draft-ietf-pkix-webcap-00.txt April 1998 3.2. Registration Registration request is used for sending certification request to CA. This document specifies the MKCERT method to create new certifi- cate. The exact definition of the behavior of MKCERT is defined later in this document.All certificate registration requests all stored in http://hostname.com/country/organization/certreq namespace. Access to this namespace MUST be controlled by CAP servers through RA or CA authentication to the server by providing RA or CA credentials through authrequest xml element. CAP server must support additional security mechanisms to provide mkcert xml responses to CAs. CAP servers MUST support server-to-server communication so that the PKI management model can be mapped into HTTP URL namespace. 3.3. Certificate Revocation The revocation request is used to revoke a certificate. To prevent malicious PKI user from revoking other's certificate, this request should be sent with a proof of possession of the secret key. The simplest way is to use conventical application that supports digital signature. This document specifies the RMCERT method to revoke a certificate. 3.4. Certificate Retrieval The ceriticate retrieval request is used for retrieving and search- ing certificate, CRLs, and any other information. The CA server may forward a request to other CA server when it does not has sufficient information to response to the request. This document defines a GETCERT method for certificate or CRL retrieval. 3.5. Certificate Verification Verification request is used for validation check of certificate. This document defines a new method VRFYCERT to verify the certificate(s) or CRL. 3.6. Referrals If a request cannot be fulfilled as the requested certificate is not stored in the HTTP URL namespace, server shall SHALL manage to obtain the access path and send referral response to the user. CAP server includes the referral response specifying the URI of the CAP server which can provide this certificate. Surendra Reddy [Page 10] draft-ietf-pkix-webcap-00.txt April 1998 3.7. Chaining If a request cannot be fulfilled as the requested certificate is not stored in the WebCAP server, it can forward the request to the another well known access point and this chaining will propagate to the root of the PKI Management hierarchy the certificate is find in the namespace. To implement chaining model, the in root CA produces an extra mes- sage before it responds to the request originator. The request originator, CA1 or PKI application, does not have to send request many times, but have to wait longer time than that of referral model. According to [Mine], the estimated total round trip time is less than that of the referral model. Since CA communicates with a particular CA, the access control at firewall can be easily set up. 4. HTTP Methods for Certificate Access The following new HTTP methods use XML as a request and response format. All CAP compliant clients and servers MUST use XML parsers that are compliant with [Bray, Paoli, Sperberg-McQueen, 1998]. All XML used in either requests or responses MUST be, at minimum, well formed. If a server receives ill-formed XML in a request it MUST reject the entire request with a 400 Bad Request. If a client receives ill-formed XML in a response then it MUST NOT assume any- thing about the outcome of the executed method and SHOULD treat the server as malfunctioning. 4.1. MKCERT Method The MKCERT method is used to create a new certificate. All CAP com- pliant servers MUST support the MKCERT method. 4.1.1. Request MKCERT requests a new certificate with the Certification or Regis- tration Authority specified by the Request URI. If the CA or RA identified by the Request-URI is null or doesnot exist then the MKCERT MUST fail. A MKCERT method MUST be sent with a request message mkcert xml ele- ment containing the certificate request message encoded in [Base64]. CA or RAs may use the same method to publish the CRLs into CAP repo- sitory. CAP server MUST validate and authenticate clients depending the requested operations. Surendra Reddy [Page 11] draft-ietf-pkix-webcap-00.txt April 1998 4.1.2. Response Codes 201 Created - The certificate request was submitted successfully. 403 Forbidden - the server does not allow the creation of certifi- cate at the given location in its namespace. 4.1.3. Example - MKCERT >>Request RMCERT /us/oracle/ HTTP/1.1 Host: www.oracle.com Content-Type: text/xml Content-Length: xxxx MIIBaTCB9AIBADBvMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEV MBMGA1UEChQMT3JhY2xlIENvcnAuMRQwEgYDVQQLFAtJbnRlck9mZmljZTEeMBwG A1UEAxQVdm9sY2Fuby51cy5vcmFjbGUuY29tMHwwDQYJKoZIhvcNAQEBBQADawAw aAJhALl21FWSXjkKblhyI7JQaqeXxtWZOei+k0FmMP6XwXnddhyu8ydHmwE27TM5 i76GDdRxOrpgomBp/DSOT7F5QhmbAwN6T/j78Y5Y4pDqA+/mefaepz/ggp0Om2Im nDfwpwIDAQABoAAwDQYJKoZIhvcNAQEEBQADYQCYtA/KVwoYtNf1jORTXaXYVv1e yXgMEN3V/iPMNFh+zhqNyz3snlZX3h4TaqqtsyAd7WHULsw/AyzMrwt+4XoZSI4n 6W8/03oG4vwPKP/23APwMxqGffh32/xL5tUgJ+s= >>Response HTTP/1.1 201 Created Content-Type: text/xml Content-Length: xxxxx Your request for certificate creation has been forwarded to the certificate authority. When the certificate is created you will be notified through email or you may query the server using the ticketno. Surendra Reddy [Page 12] draft-ietf-pkix-webcap-00.txt April 1998 4.2. RMCERT The RMCERT method is used to revoke a certificate or set of certifi- cates. 4.2.1. Request The RMCERT method processes instructions specified in the request body to revoke certificates defined by the Request-URI. All CAP compliant servers MUST support the RMCERT method and MUST process instructions that are specified using the revokecert XML elements. Instruction processing MUST occur in the order instructions are received (i.e., from top to bottom). Instructions MUST either all be executed or none executed. Thus if any error occurs during pro- cessing all executed instructions MUST be undone and a proper error result returned. 4.2.2. Status Codes for use with Multi-Status The following are examples of response codes one would expect to be used in a Multi-Status response for this method. 200 OK - The command succeeded. As there can be a mixture of sets and removes in a body, a 201 Created seems inappropriate. 403 Forbidden - The client, for reasons the server chooses not to specify, cannot revoke the specified certificate. 409 Conflict - The client has provided a value whose semantics are not appropriate for the certificate. This includes trying to revoke the certificate already revoked. 4.2.3. Example - RMCERT >>Request RMCERT /us/oracle/ HTTP/1.1 Host:us.oracle.com Content-Type: text/xml Content-Length: xxxx MIICZzCCAfECAQIwDQYJKoZIhvcNAQEEBQAwgaQxCzAJBgNVBAYTAlVTMRMwEQYD VQQIEwpDYWxpZm9ybmlhMSowKAYDVQQKFCFDb25zZW5zdXMgRGV2ZWxvcG1lbnQg Q29ycG9yYXRpb24xIDAeBgNVBAsUF0NlcnQgUGx1cyBYLjUwOSBUb29sa2l0MTIw MAYDVQQDFClDb25zZW5zdXMgRGV2ZWxvcG1lbnQgVGVzdCBDQSBmb3IgUTMgMTk5 NzAeFw05NzA2MzAwMDAwMDBaFw05NzA5MzAyMzU5NTlaMIGXMQswCQYDVQQGEwJV UzETMBEGA1UECBMKQ2FsaWZvcm5pYTEqMCgGA1UEChQhQ29uc2Vuc3VzIERldmVs b3BtZW50IENvcnBvcmF0aW9uMS0wKwYDVQQLFCRTU0wgUGx1cyBURVNUSU5HIEFO RCBFVkFMVUFUSU9OIE9OTFkxGDAWBgNVBAMUDyouY29uc2Vuc3VzLmNvbTB8MA0G CSqGSIb3DQEBAQUAA2sAMGgCYQCmvUdBE7ivlxDrZKlHGFfaMhiDAD0/OGmm+98+ 4MlqLpF0Bm279kn7weCXzaWsPhCTlis3zi+BeTM8PDA3vZJvzfRcCSxChQZpxqrx HdaSWPuS0nhSyfBHEZ2a2tQiMtcCAwEAATANBgkqhkiG9w0BAQQFAANhAAohxBYT Hr+kH5gCjXFdfCUsMHIuN8qGzvmDCdJbz76nx3YVZmjCYvXJtkt4MMcIF5rKQNHi I4KxIDdjSY5rxpvhKG5GQ7+m2pq3fAtnbtB2ppC5sHjXe66duZYD33hi7A== MIICZzCCAfECAQIwDQYJKoZIhvcNAQEEBQAwgaQxCzAJBgNVBAYTAlVTMRMwEQYD VQQIEwpDYWxpZm9ybmlhMSowKAYDVQQKFCFDb25zZW5zdXMgRGV2ZWxvcG1lbnQg Q29ycG9yYXRpb24xIDAeBgNVBAsUF0NlcnQgUGx1cyBYLjUwOSBUb29sa2l0MTIw MAYDVQQDFClDb25zZW5zdXMgRGV2ZWxvcG1lbnQgVGVzdCBDQSBmb3IgUTMgMTk5 NzAeFw05NzA2MzAwMDAwMDBaFw05NzA5MzAyMzU5NTlaMIGXMQswCQYDVQQGEwJV UzETMBEGA1UECBMKQ2FsaWZvcm5pYTEqMCgGA1UEChQhQ29uc2Vuc3VzIERldmVs b3BtZW50IENvcnBvcmF0aW9uMS0wKwYDVQQLFCRTU0wgUGx1cyBURVNUSU5HIEFO RCBFVkFMVUFUSU9OIE9OTFkxGDAWBgNVBAMUDyouY29uc2Vuc3VzLmNvbTB8MA0G CSqGSIb3DQEBAQUAA2sAMGgCYQCmvUdBE7ivlxDrZKlHGFfaMhiDAD0/OGmm+98+ 4MlqLpF0Bm279kn7weCXzaWsPhCTlis3zi+BeTM8PDA3vZJvzfRcCSxChQZpxqrx HdaSWPuS0nhSyfBHEZ2a2tQiMtcCAwEAATANBgkqhkiG9w0BAQQFAANhAAohxBYT Hr+kH5gCjXFdfCUsMHIuN8qGzvmDCdJbz76nx3YVZmjCYvXJtkt4MMcIF5rKQNHi I4KxIDdjSY5rxpvhKG5GQ7+m2pq3fAtnbtB2ppC5sHjXe66duZYD33hi7A== NvcnBvcmF0aW9uMS0wKwYDVQQLFCRTU0wgU ETMBEGA1UECBMKQ2FsaWZvcm5pYTEqMC >> Response HTTP/1.1 207 Multi-Status Surendra Reddy [Page 14] draft-ietf-pkix-webcap-00.txt April 1998 Content-Type: text/xml Content-Length: xxxxx In this example, the client requests the server to revoke two certicates issued by a CA in US for Oracle Corp. 4.3. GETCERT The GETCERT method retrieves certificate(s) from the CA repository specified by the Request-URI. All CAP compliant resources MUST sup- port the GETCERT method and the getcert XML element along with all XML elements defined for use with that element. A client SHOULD submit a getcert XML element in the body of the request method describing what information is being requested. All servers MUST support returning a response of content type text/xml that contains a multi-status XML element that describes the results of the attempts to retrieve the various certificates. If there is an error retrieving a certificate then a proper error result MUST be included in the response. A request to retrieve the certificate which does not exist is an error and MUST be noted, if the response uses a multi-status XML element, with a response XML element which contains a 404 Not Found status value. The results of this method SHOULD NOT be cached. 4.3.1. Status Codes for use with Multi-Status The following are examples of response codes one would expect to be used in a Multi-Status response for this method. 200 OK - The command succeeded. As there can be a mixture of sets and removes in a body, a 201 Created seems inappropriate. 403 Forbidden - The client, for reasons the server chooses not to specify, cannot revoke the specified certificate. 409 Conflict - The client has provided a value whose semantics are not appropriate for the certificate. This includes trying to revoke the certificate already revoked. Surendra Reddy [Page 15] draft-ietf-pkix-webcap-00.txt April 1998 4.3.2. Example - Retrieving Certificate >>Request GETCERT /us/oracle/ HTTP/1.1 Host: us.oracle.com Content-type: text/xml Content-Length: xyz MBMGA1UEChQMT3JhY2xlIENvcnAuMRQwEgYDVQQLFAtJbnRlck9mZmljZTEeMBwG A1UEAxQVdm9sY2Fuby51cy5vcmFjbGUuY29tMHwwDQYJKoZIhvcNAQEBBQADawAw aAJhALl21FWSXjkKblhyI7JQaqeXxtWZOei+k0FmMP6XwXnddhyu8ydHmwE27TM5 i76GDdRxOrpgomBp/DSOT7F5QhmbAwN6T/j78Y5Y4pDqA+/mefaepz/ggp0Om2Im i76GDdRxOrpgomBp/DSOT7F5QhmbAwN6T/j78Y5Y4pDqA+/mefaepz/ggp0Om2Im nDfwpwIDAQABoAAwDQYJKoZIhvcNAQEEBQADYQCYtA/KVwoYtNf1jORTXaXYVv1e yXgMEN3V/iPMNFh+zhqNyz3snlZX3h4TaqqtsyAd7WHULsw/AyzMrwt+4XoZSI4n 6W8/03oG4vwPKP/23APwMxqGffh32/xL5tUgJ+s= >>Response HTTP/1.1 207 Multi-Status Content-Type: text/xml Content-Length: xxxxx Base64 encoded certificate goes here Base64 encoded crl goes here In this example, request is sent for retrieving certificates for subject name identified by Base64 encoded certificateRequest. CAP server return Surendra Reddy [Page 16] draft-ietf-pkix-webcap-00.txt April 1998 multi-status response containing certificates encoded in base64 format. 4.4. VRFYCERT The VRFYCERT method verifies the validity of the certificate speci- fied in the request body. All WebCAP compliant resources MUST support the VRFYCERT method. However, support for the VRFYCERT method does not guarantee the ability to verify the certificate successfully. For example, separate programs may control access to CIT access paths. As a result, it may not be possible to verify the certificates for its validity. In such case, server returns error code. 4.4.1. Status Codes for use with Multi-Status The following are examples of response codes one would expect to be used in a Multi-Status response for this method. 200 OK - The command succeeded. As there can be a mixture of sets and removes in a body, a 201 Created seems inappropriate. 403 Forbidden - The client, for reasons the server chooses not to specify, cannot revoke the specified certificate. 409 Conflict - The client has provided a value whose semantics are not appropriate for the certificate. This includes trying to revoke the certificate already revoked. 4.4.2. Example - VRFYCERT >>Request VRFYCERT /us/oracle/ HTTP/1.1 Host: us.oracle.com Content-Type: text/xml Content-Length: xxxx MIICZzCCAfECAQIwDQYJKoZIhvcNAQEEBQAwgaQxCzAJBgNVBAYTAlVTMRMwEQYD VQQIEwpDYWxpZm9ybmlhMSowKAYDVQQKFCFDb25zZW5zdXMgRGV2ZWxvcG1lbnQg Q29ycG9yYXRpb24xIDAeBgNVBAsUF0NlcnQgUGx1cyBYLjUwOSBUb29sa2l0MTIw MAYDVQQDFClDb25zZW5zdXMgRGV2ZWxvcG1lbnQgVGVzdCBDQSBmb3IgUTMgMTk5 NzAeFw05NzA2MzAwMDAwMDBaFw05NzA5MzAyMzU5NTlaMIGXMQswCQYDVQQGEwJV UzETMBEGA1UECBMKQ2FsaWZvcm5pYTEqMCgGA1UEChQhQ29uc2Vuc3VzIERldmVs b3BtZW50IENvcnBvcmF0aW9uMS0wKwYDVQQLFCRTU0wgUGx1cyBURVNUSU5HIEFO RCBFVkFMVUFUSU9OIE9OTFkxGDAWBgNVBAMUDyouY29uc2Vuc3VzLmNvbTB8MA0G Surendra Reddy [Page 17] draft-ietf-pkix-webcap-00.txt April 1998 CSqGSIb3DQEBAQUAA2sAMGgCYQCmvUdBE7ivlxDrZKlHGFfaMhiDAD0/OGmm+98+ 4MlqLpF0Bm279kn7weCXzaWsPhCTlis3zi+BeTM8PDA3vZJvzfRcCSxChQZpxqrx HdaSWPuS0nhSyfBHEZ2a2tQiMtcCAwEAATANBgkqhkiG9w0BAQQFAANhAAohxBYT Hr+kH5gCjXFdfCUsMHIuN8qGzvmDCdJbz76nx3YVZmjCYvXJtkt4MMcIF5rKQNHi I4KxIDdjSY5rxpvhKG5GQ7+m2pq3fAtnbtB2ppC5sHjXe66duZYD33hi7A== UzETMBEGA1UECBMKQ2FsaWZvcm5pYTEqMCgGA1UEChQhQ29uc2Vuc3VzIERldmVs b3BtZW50IENvcnBvcmF0aW9uMS0wKwYDVQQLFCRTU0wgUGx1cyBURVNUSU5HIEFO RCBFVkFMVUFUSU9OIE9OTFkxGDAWBgNVBAMUDyouY29uc2Vuc3VzLmNvbTB8MA0G MIICZzCCAfECAQIwDQYJKoZIhvcNAQEEBQAwgaQxCzAJBgNVBAYTAlVTMRMwEQYD VQQIEwpDYWxpZm9ybmlhMSowKAYDVQQKFCFDb25zZW5zdXMgRGV2ZWxvcG1lbnQg Q29ycG9yYXRpb24xIDAeBgNVBAsUF0NlcnQgUGx1cyBYLjUwOSBUb29sa2l0MTIw MAYDVQQDFClDb25zZW5zdXMgRGV2ZWxvcG1lbnQgVGVzdCBDQSBmb3IgUTMgMTk5 NzAeFw05NzA2MzAwMDAwMDBaFw05NzA5MzAyMzU5NTlaMIGXMQswCQYDVQQGEwJV CSqGSIb3DQEBAQUAA2sAMGgCYQCmvUdBE7ivlxDrZKlHGFfaMhiDAD0/OGmm+98+ 4MlqLpF0Bm279kn7weCXzaWsPhCTlis3zi+BeTM8PDA3vZJvzfRcCSxChQZpxqrx HdaSWPuS0nhSyfBHEZ2a2tQiMtcCAwEAATANBgkqhkiG9w0BAQQFAANhAAohxBYT Hr+kH5gCjXFdfCUsMHIuN8qGzvmDCdJbz76nx3YVZmjCYvXJtkt4MMcIF5rKQNHi I4KxIDdjSY5rxpvhKG5GQ7+m2pq3fAtnbtB2ppC5sHjXe66duZYD33hi7A== >>Response HTTP/1.1 207 Multi-Status Content-Type: text/xml Content-Length: xxxxx 4.5. The OPTIONS Method The OPTIONS method allows the client to discover the CAP server capabilities. 4.5.1. Request The client issues the OPTIONS method against a CAP server. This is a normal invocation of OPTIONS defined in [RFC2068]. 4.5.2. Example >> Request OPTIONS /us/oracle/ HTTP/1.1 Connection: Close Surendra Reddy [Page 18] draft-ietf-pkix-webcap-00.txt April 1998 Host:certserv.us.oracle.com >> Response HTTP/1.1 200 OK Date: Tue, 20 Jan 1998 20:52:29 GMT Connection: close Accept-Ranges: none Allow: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, MKCERT,GETCERT, RMCERT,VRFYCERT Public: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, MKCERT,GETCERT, RMCERT,VRFYCERT CAP: 1.0 5. HTTP Headers for Certificate Access 5.1. CAP Header CAP = "CAP" ":" "1.0" This header indicates that the resource supports the CAP schema and protocol as specified. All CAP compliant servers MUST return the CAP header on all OPTIONS responses. 6. Status Code Extensions to HTTP/1.1 The following status codes are added to those defined in HTTP/1.1 [Fielding et al., 1997]. 6.1. 102 Processing Methods can potentially take a long period of time to process, espe- cially validating certificates not in the access path of the WebCAP server. In such cases the client may time-out the connection while waiting for a response. To prevent this the server may return a 102 status code to indicate to the client that the server is still pro- cessing the method. 6.2. 207 Multi-Status The response provides status for multiple independent operations. 6.3. 424 Method Failure The method was not executed on a particular certificate within its scope because some part of the method's execution failed causing the entire method to be aborted. 6.4. 425 Insufficient Privileges The resource does not have sufficient privileges to perform the requested operation. Surendra Reddy [Page 19] draft-ietf-pkix-webcap-00.txt April 1998 7. Multi-Status Response The default 207 Multi-Status response body is a text/xml HTTP entity that contains a single XML element called multi-status, which con- tains a set of XML elements called response which contain 200, 300, 400, and 500 series status codes generated during the method invoca- tion. 100 series status codes SHOULD NOT be recorded in a response XML element. 8. XML Element Definitions 8.1. Element References A CAP XML element or one of its child XML elements, may contain an XML attribute that refers to another element. 8.2. Opaque Embedded Data Most of the CAP messages expects that opaque data will be embedded within CAP messages. For e.g., o the content of the Certificate element o the content of the Signature element The embedded data is called opaque because it is not processed by XML processor, but is instead passed to or from CAP server or client. 8.3. Identifying Languages CAP uses [XML] Language Identification to specify which languages used within the content and attributes of CAP Messages. o a mandatory XML:Lang attribute is contained on every CAP message which contains attributes or content which may need to be displayed or printed in a particular language 8.4. mkcert XML element mkcert XML element defines Base64 encoded certificate request mes- sage. 8.5. certrequest XML element certrequest XML element defines the certificate request message encoded in Base64. Surendra Reddy [Page 20] draft-ietf-pkix-webcap-00.txt April 1998 8.6. rmcert XML element revokecert XML element defines certificate revocation information encoded in Base64. 8.8. getcert XML element getcertinfo XML element defines subject information of the certificate that need to be retrieved from the certificate repository. This information is encoded in Base64. 8.10. vrfycert XML element 8.11.1. Attributes hashtype: The hash algorithm used to calculate the hash in the content of the element. Valid values are sha1, md2,md5 Surendra Reddy [Page 21] draft-ietf-pkix-webcap-00.txt April 1998 8.11.2. Content PCDATA: Contains the actual hash value, [Base64] encoded, of the element identified by "elementref" and calculated using the algo- rithm specified by hashtype. 8.12. signature XML element This contains the actual digital signature resulting from signing the information contained within signed XML element. Each Signature element digitally signs one or more messages. The signature element: o hashes one or more elements in one or more CAP Messages within the same CAP Transaction o concatenates these hashes and any additional information to be signed in the form of authenticated attributes into a signed xml element, and o signs the signed element using the certificate identified in the certref attribute of the signature element. Note that a signed element may be signed by more than one signature element. The definition of a signature XML element is as follows. 8.12.1. Attributes hashtype: The hash algorithm used to calculate the hash in the content of the element. Valid values are:sha1, md2,md5 algorithm: The algorithm used to calculate digital signature from the hash. Valid values are: RSA signature uses the [RSA] algorithm DSA signature uses the [DSA] algorithm Each Signature element digitally signs one or more messages. 8.13. certificate XML element A certificate XML element contains a digital certificate which is to be used in order to create or check a signature element. Surendra Reddy [Page 22] draft-ietf-pkix-webcap-00.txt April 1998 8.13.1. Attributes certtype: The type of Certificate contained within the XMLCertifi- cate element. Valid values are: x509v1, x509v2, x509v3. certref: unique id used to reference this element in other element in the same document tree. 8.13.2. Content PCDATA: The actual certificate of the type specified by certtype encoded in Base64 format. 9. Signing XML documents This section describes a simple procedure to sign and verify XML messages sent between CAP client and server. 1. The data signed is always an "entire" XML element. - for non EMPTY elements , whole XML element starting with leftmost "<" and ending with rightmost ">" of the end of the element tag. - for EMPTY elements, starting with, and including the leftmost "<" of the element and finishing with, and including, the rightmost ">" of the element. 2. Convert all characters in the element to [UTF8] format. 3. Resolve default attribute values, external entities and all character and entity references in the element so that they are completely resolved. Sort the original and generated attributes in ascending attribute name order according to the UTF8 encoding of the attribute name. 4. Donot include comments and processing instructions (PIs), 5. Reduce all attributes to their canonical form using the attribute type in the DTD. Replace all single and double quotes present in attributes with ' and " respectively so that attributes can be enclosed in double quotes 6. Remove non essential whitespace and represent required whitespace by a single space character . Remove all whitespace in the element content. 7. Generate the content of all start tags using only the element name and the attributes as described above. If the element is an "empty" element then generate it using the single empty tag Surendra Reddy [Page 23] draft-ietf-pkix-webcap-00.txt April 1998 format, with a trailing slash. Generate end tags using only the element name, with no added whitespace. 8. All character data is generated inside a CDATA section. Any CDATA end sequences ("]]>") within the data are replaced by "]]]]>" in order to escape the CDATA end sequence. 9. Start tags, end tags, empty tags, CDATA sections, and text sections are assembled in the same order as the original document. 9.1. Calculating Hashes and Signatures 1. Convert the data to be signed into a byte stream in the canonical encoding format defined above 2. Calculate the hash or signature using appropriate algorithm and rules assuming "big-endian" byte order. 3. Encode the result using [Base64] encoding. 4. Place the encoded result, most significant byte first, in either: - the content of the signed element , or - the content of the signature element. 9.2. Checking Hashes and Signatures Checking of a signature therefore consists of: 1. Verify the signed element and create a byte stream in the canonical encoding format defined above. 2. For each signed element in the signed element, verify if HASH values are correct or compute the signature from the certificate references included in the signed XML element. for each Hash Element in the signature: - check if the [XML] element identified by the "elementref" attribute of the Hash Element refers to an element available from the message stream. - if the [XML] element is available check that the hash value of the XML element contained inside the content of the signed element is correctly calculated. for the signature as a whole verifying that the content of the signature element has been correctly calculated. 10. Security Consideration Surendra Reddy [Page 24] draft-ietf-pkix-webcap-00.txt April 1998 10.1. Confidentiality of transaction To prevent message from being eavesdropped, secure communication channel such as SSL shall be used. Especially, initial registration process is critical to eavesdropping. 10.2. Non-Repudiation The verify request supports the time to be checked and digitally signed response. This can avoid a message sender from denying the message. To enable this service, any CA must manage all certificates which it has already issued, including revoked certificates. 10.3. Privacy In the lookup request, the support of substring matching facility may distribute private information to outsiders, and thereby may be used for sending an advertisement via email. 11. References [XML] Bray, Tim, Jean Paoli, and CM Sperberg-McQueen, "Extensible Markup Language(XML): Part I Syntax", World Wide Web Consortium Working Draft, February 1998. Available at http://www.w3.org/TR/REC-xml [COR95] ISO/IEC JTC 1/SC 21, Technical Corrigendum 2 to ISO/IEC 9594-8: 1990 & 1993 (1995:E), July 1995. [CRMF] M. Myers, C. Adams, D. Solo, D. Kemp, "Certificate Request Message Format", Internet Draft draft-ietf-pkix-crmf-0x.txt (work in progress). [PKCS7] RSA Laboratories, "The Public-Key Cryptography Standards (PKCS)", RSA Data Security Inc., Redwood City, California, November 1993 Release. [PKCS10] RSA Laboratories, "The Public-Key Cryptography Standards (PKCS)", RSA Data Security Inc., Redwood City, California, November 1993 Release. [PKCS11] RSA Laboratories, "The Public-Key Cryptography Standards - PKCS #11: Cryptographic token interface standard", RSA Data Secu- rity Inc., Redwood City, California, April 28, 1995. [RFC1847] J. Galvin, S. Murphy, S. Crocker, N. Freed, "Security Mul- tiparts for MIME: Multipart/Signed and Multipart/ Encrypted", Internet Request for Comments 1847, October 1995. [RFC2104] H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed Hashing Surendra Reddy [Page 25] draft-ietf-pkix-webcap-00.txt April 1998 for Message Authentication", Internet Request for Comments 2104, February, 1997. [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", Internet Request for Comments 2119 (Best Current Practice: BCP 14), March, 1997. [RFC2202] P. Cheng, R. Glenn, "Test Cases for HMAC-MD5 and HMAC- SHA-1", Internet Request for Comments 2202, September 1997. [X509-AM] ISO/IEC JTC1/SC 21, Draft Amendments DAM 4 to ISO/IEC 9594-2, DAM 2 to ISO/IEC 9594-6, DAM 1 to ISO/IEC 9594-7, and DAM 1 to ISO/IEC 9594-8 on Certificate Extensions, 12. Author's Address Surendra Reddy Oracle Corporation 500 Oracle Parkway M/S 6op3 Redwoodshores, CA 94065 Phone: +1 650 506 5441 Fax: +1 650 654 6205 EMail: SKREDDY@us.oracle.com Expires October 19, 1998 Surendra Reddy [Page 26]