[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00                                                            
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

   <?xml version="1.0" ?>
   <?xml:namespace ns="CAP:" prefix="D" ?>
   <D:mkcert>
        <D:certrequest Common-name='volcano.us.oracle.com'
           Organization-Unit='InterOffice', Organization='Oracle Corp.'
           State='CA', Country='US', email='skreddy@us.oracle.com'
           contact='Surendra Reddy' ContentType='base64'>
                MIIBaTCB9AIBADBvMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEV
                MBMGA1UEChQMT3JhY2xlIENvcnAuMRQwEgYDVQQLFAtJbnRlck9mZmljZTEeMBwG
                A1UEAxQVdm9sY2Fuby51cy5vcmFjbGUuY29tMHwwDQYJKoZIhvcNAQEBBQADawAw
                aAJhALl21FWSXjkKblhyI7JQaqeXxtWZOei+k0FmMP6XwXnddhyu8ydHmwE27TM5
                i76GDdRxOrpgomBp/DSOT7F5QhmbAwN6T/j78Y5Y4pDqA+/mefaepz/ggp0Om2Im
                nDfwpwIDAQABoAAwDQYJKoZIhvcNAQEEBQADYQCYtA/KVwoYtNf1jORTXaXYVv1e
                yXgMEN3V/iPMNFh+zhqNyz3snlZX3h4TaqqtsyAd7WHULsw/AyzMrwt+4XoZSI4n
                6W8/03oG4vwPKP/23APwMxqGffh32/xL5tUgJ+s=
        </D:certrequest>
    </D:mkcert>

   >>Response
   HTTP/1.1 201 Created
   Content-Type: text/xml
   Content-Length: xxxxx

   <?xml version="1.0" ?>
   <?xml:namespace ns="CAP:" prefix="D" ?>
   <D:mkcertresp ticketno="10000120000">
                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.
   </D:mkcertresp>






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

   <?xml version="1.0" ?>
   <?xml:namespace ns="CAP:" prefix="D" ?>
   <?xml:namespace ns="http://www.w3.com/standards/z39.50/" prefix="Z"
   ?>
   <D:rmcert>
        <D:revokecert requestid="001" Common-name='volcano.us.oracle.com'



Surendra Reddy                                                 [Page 13]


draft-ietf-pkix-webcap-00.txt                                 April 1998


                Organization-Unit='InterOffice', Organization='Oracle Corp.'
                State='CA', Country='US', email='skreddy@us.oracle.com'
                contact='Surendra Reddy' ContentType='base64'>
                MIICZzCCAfECAQIwDQYJKoZIhvcNAQEEBQAwgaQxCzAJBgNVBAYTAlVTMRMwEQYD
                VQQIEwpDYWxpZm9ybmlhMSowKAYDVQQKFCFDb25zZW5zdXMgRGV2ZWxvcG1lbnQg
                Q29ycG9yYXRpb24xIDAeBgNVBAsUF0NlcnQgUGx1cyBYLjUwOSBUb29sa2l0MTIw
                MAYDVQQDFClDb25zZW5zdXMgRGV2ZWxvcG1lbnQgVGVzdCBDQSBmb3IgUTMgMTk5
                NzAeFw05NzA2MzAwMDAwMDBaFw05NzA5MzAyMzU5NTlaMIGXMQswCQYDVQQGEwJV
                UzETMBEGA1UECBMKQ2FsaWZvcm5pYTEqMCgGA1UEChQhQ29uc2Vuc3VzIERldmVs
                b3BtZW50IENvcnBvcmF0aW9uMS0wKwYDVQQLFCRTU0wgUGx1cyBURVNUSU5HIEFO
                RCBFVkFMVUFUSU9OIE9OTFkxGDAWBgNVBAMUDyouY29uc2Vuc3VzLmNvbTB8MA0G
                CSqGSIb3DQEBAQUAA2sAMGgCYQCmvUdBE7ivlxDrZKlHGFfaMhiDAD0/OGmm+98+
                4MlqLpF0Bm279kn7weCXzaWsPhCTlis3zi+BeTM8PDA3vZJvzfRcCSxChQZpxqrx
                HdaSWPuS0nhSyfBHEZ2a2tQiMtcCAwEAATANBgkqhkiG9w0BAQQFAANhAAohxBYT
                Hr+kH5gCjXFdfCUsMHIuN8qGzvmDCdJbz76nx3YVZmjCYvXJtkt4MMcIF5rKQNHi
                I4KxIDdjSY5rxpvhKG5GQ7+m2pq3fAtnbtB2ppC5sHjXe66duZYD33hi7A==
        </D:revokecert>
        <D:revokecert requestid="002" Common-name='volcano.us.oracle.com'
                Organization-Unit='InterOffice', Organization='Oracle Corp.'
                State='CA', Country='US', email='skreddy@us.oracle.com'
                contact='Surendra Reddy' ContentType='base64'>
                MIICZzCCAfECAQIwDQYJKoZIhvcNAQEEBQAwgaQxCzAJBgNVBAYTAlVTMRMwEQYD
                VQQIEwpDYWxpZm9ybmlhMSowKAYDVQQKFCFDb25zZW5zdXMgRGV2ZWxvcG1lbnQg
                Q29ycG9yYXRpb24xIDAeBgNVBAsUF0NlcnQgUGx1cyBYLjUwOSBUb29sa2l0MTIw
                MAYDVQQDFClDb25zZW5zdXMgRGV2ZWxvcG1lbnQgVGVzdCBDQSBmb3IgUTMgMTk5
                NzAeFw05NzA2MzAwMDAwMDBaFw05NzA5MzAyMzU5NTlaMIGXMQswCQYDVQQGEwJV
                UzETMBEGA1UECBMKQ2FsaWZvcm5pYTEqMCgGA1UEChQhQ29uc2Vuc3VzIERldmVs
                b3BtZW50IENvcnBvcmF0aW9uMS0wKwYDVQQLFCRTU0wgUGx1cyBURVNUSU5HIEFO
                RCBFVkFMVUFUSU9OIE9OTFkxGDAWBgNVBAMUDyouY29uc2Vuc3VzLmNvbTB8MA0G
                CSqGSIb3DQEBAQUAA2sAMGgCYQCmvUdBE7ivlxDrZKlHGFfaMhiDAD0/OGmm+98+
                4MlqLpF0Bm279kn7weCXzaWsPhCTlis3zi+BeTM8PDA3vZJvzfRcCSxChQZpxqrx
                HdaSWPuS0nhSyfBHEZ2a2tQiMtcCAwEAATANBgkqhkiG9w0BAQQFAANhAAohxBYT
                Hr+kH5gCjXFdfCUsMHIuN8qGzvmDCdJbz76nx3YVZmjCYvXJtkt4MMcIF5rKQNHi
                I4KxIDdjSY5rxpvhKG5GQ7+m2pq3fAtnbtB2ppC5sHjXe66duZYD33hi7A==
        </D:revokecert>
        <D:signed msgid="001" hashtype='sha1'>
                NvcnBvcmF0aW9uMS0wKwYDVQQLFCRTU0wgU
        </D:signed>
        <D:signed msgid="002" hashtype="md5>
                EBAQUAA2sAMGgCYQCmvUdBE7ivlxQQLFCRf
        </D:signed>
        <D:signature algorithm="sha-with-rsa-encryption">
                ETMBEGA1UECBMKQ2FsaWZvcm5pYTEqMC
        </D:signature>
   </D:rmcert>

   >> 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

   <?xml version="1.0" ?>
   <?xml:namespace ns="CAP:" prefix="D" ?>
   <D:multi-status>
   </D:multi-status>
    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

   <?xml version="1.0" ?>
   <?xml:namespace ns="CAP:" prefix="D" ?>
   <D:getcert>
        <D:getcertinfo msgid="001" repository="cert">
           MBMGA1UEChQMT3JhY2xlIENvcnAuMRQwEgYDVQQLFAtJbnRlck9mZmljZTEeMBwG
           A1UEAxQVdm9sY2Fuby51cy5vcmFjbGUuY29tMHwwDQYJKoZIhvcNAQEBBQADawAw
           aAJhALl21FWSXjkKblhyI7JQaqeXxtWZOei+k0FmMP6XwXnddhyu8ydHmwE27TM5
           i76GDdRxOrpgomBp/DSOT7F5QhmbAwN6T/j78Y5Y4pDqA+/mefaepz/ggp0Om2Im
        </D:gercertinfo>
        <D:getcertinfo msgid="002" repository="crl">
                i76GDdRxOrpgomBp/DSOT7F5QhmbAwN6T/j78Y5Y4pDqA+/mefaepz/ggp0Om2Im
                nDfwpwIDAQABoAAwDQYJKoZIhvcNAQEEBQADYQCYtA/KVwoYtNf1jORTXaXYVv1e
                yXgMEN3V/iPMNFh+zhqNyz3snlZX3h4TaqqtsyAd7WHULsw/AyzMrwt+4XoZSI4n
                6W8/03oG4vwPKP/23APwMxqGffh32/xL5tUgJ+s=
        </D:getcertinfo>
   </D:getcert>

>>Response

   HTTP/1.1 207 Multi-Status
   Content-Type: text/xml
   Content-Length: xxxxx

   <?xml version="1.0" ?>
   <?xml:namespace ns="CAP:" prefix="D" ?>
   <D:multi-status>
     <D:getcertresp msgid="001">
        <D:certinfo type = "certificate" common-name="Surendra Reddy"
                organization="Oracle"
                issuer-name="verisign" valid-date"01-DEC-1998"
                email="skreddy">
                Base64 encoded certificate goes here
        </D:certinfo>
        <D:certinfo type="crl">
                Base64 encoded crl goes here
        </D:certinfo>
   </D:multi-status>
    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

   <?xml version="1.0" ?>
   <?xml:namespace ns="CAP:" prefix="D" ?>
   <D:vrfycert>
        <D:vrfycertinfo msgid="001">
                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==
        </D:vrfycertinfo>
        <D:vrfycertinfo msgid="002">
                UzETMBEGA1UECBMKQ2FsaWZvcm5pYTEqMCgGA1UEChQhQ29uc2Vuc3VzIERldmVs
                b3BtZW50IENvcnBvcmF0aW9uMS0wKwYDVQQLFCRTU0wgUGx1cyBURVNUSU5HIEFO
                RCBFVkFMVUFUSU9OIE9OTFkxGDAWBgNVBAMUDyouY29uc2Vuc3VzLmNvbTB8MA0G
                MIICZzCCAfECAQIwDQYJKoZIhvcNAQEEBQAwgaQxCzAJBgNVBAYTAlVTMRMwEQYD
                VQQIEwpDYWxpZm9ybmlhMSowKAYDVQQKFCFDb25zZW5zdXMgRGV2ZWxvcG1lbnQg
                Q29ycG9yYXRpb24xIDAeBgNVBAsUF0NlcnQgUGx1cyBYLjUwOSBUb29sa2l0MTIw
                MAYDVQQDFClDb25zZW5zdXMgRGV2ZWxvcG1lbnQgVGVzdCBDQSBmb3IgUTMgMTk5
                NzAeFw05NzA2MzAwMDAwMDBaFw05NzA5MzAyMzU5NTlaMIGXMQswCQYDVQQGEwJV
                CSqGSIb3DQEBAQUAA2sAMGgCYQCmvUdBE7ivlxDrZKlHGFfaMhiDAD0/OGmm+98+
                4MlqLpF0Bm279kn7weCXzaWsPhCTlis3zi+BeTM8PDA3vZJvzfRcCSxChQZpxqrx
                HdaSWPuS0nhSyfBHEZ2a2tQiMtcCAwEAATANBgkqhkiG9w0BAQQFAANhAAohxBYT
                Hr+kH5gCjXFdfCUsMHIuN8qGzvmDCdJbz76nx3YVZmjCYvXJtkt4MMcIF5rKQNHi
                I4KxIDdjSY5rxpvhKG5GQ7+m2pq3fAtnbtB2ppC5sHjXe66duZYD33hi7A==
        </D:vrfycertinfo>
   </D:vrfycert>

   >>Response
   HTTP/1.1 207 Multi-Status
   Content-Type: text/xml
   Content-Length: xxxxx

   <?xml version="1.0" ?>
   <?xml:namespace ns="CAP:" prefix="D" ?>
   <D:multi-status>
        <D:vrfyresp msgid="001" status="Valid"/>
        <D:vrfyresp msgid="002" status="Revoked"/>
   </D:multi-status>

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
    <!ELEMENT mkcert(certrequest+)>

    mkcert XML element defines Base64 encoded certificate request mes-
    sage.

8.5.  certrequest XML element
    <!ELEMENT certrequest #PCDATA >

    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
    <!ELEMENT rmcert(revokecert+,certificate,signed,signature)

    rmcert XML element contains certificates to be revoked and there
    messages are signed using the requestor certificates.  certificate
    xml element contains the certificate of the requestor.

8.7.  revokecert XML element
    <!ELEMENT revokecert #PCDATA >

    revokecert XML element defines certificate revocation information
    encoded in Base64.

8.8.  getcert XML element
    <!ELEMENT getcert(getcertinfo+)

    getcert XML element defines subject information to retrieve the cer-
    tificates or crls from the Certificate repository pointed by
    request-URI.

8.9.  getcertinfo XML element
    <!ELEMENT getcertinfo #PCDATA>

    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
    <!ELEMENT vrfycert(certificate+)

    vrfycert XML element defines list of certificates that need to be
    verified by the CAP server.

8.11.  signed XML element
    signed XML element defines hash of all XML document references that
    need to be signed and computed hash values for these parts of the
    document.
            <!ELEMENT signed #PCDATA >
            <!ATTLIST signed
                hashtype      NMTOKEN 'SHA1'
                elementref    NMTOKEN #REQUIRED >

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.
       <!ELEMENT signature   #PCDATA>
       <!ATTLIST   signature
            hashtype      NMTOKEN 'SHA1'
            algorithmtype NMTOKEN 'RSA'
            certref        NMTOKEN #IMPLIED >

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.
        <!ELEMENT certificate ANY >



Surendra Reddy                                                 [Page 22]


draft-ietf-pkix-webcap-00.txt                                 April 1998


        <!ATTLIST certificate
         certtype  NMTOKEN        'x509v3'
         certref   NMTOKEN        #REQUIRED>

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 &#39; and &#34; respectively so that
       attributes can be enclosed in double quotes

    6. Remove non essential whitespace and represent required whitespace
       by a single space character &#32;. 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
       "]]]]><![CDATA[>" 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]