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

Versions: 00 01                                                         
PKIX Working Group                                      M. Sakurai (NEC)
INTERNET-DRAFT                                   H. Kikuchi (Tokai Univ)
                                                 H. Hattori (Meiji Univ)
                                                     Y. Sameshima (ICAT)
                                                       H. Kumagai (ICAT)
expires in six months                                      July 31, 1998


            Web-based Integrated CA services Protocol, ICAP
                   <draft-sakurai-pkix-icap-00.txt>


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 obsoleted 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).

Abstract

   This document provides a sub set of specifications how to issue,
   publish X.509 certificates and certificate revocation lists (CRLs).
   It also provides the certificate validation service by online.  In
   the proposed specifications, the World Wide Web (WWW) is used for
   secure distributing certificates across a firewall in both human and
   machine readable syntax. These specifications define not only the
   protocols between the PKI clients and a single CA, but also the
   protocols between the CAs.  With the CA-CA communications, the PKI
   clients can retrieve any certificates and CRLs without specifying the
   location of the appropriate CA, by only asking to the neighbor CA.



                              Table of Contents

      1  Introduction .............................................  3



Sakurai,Kikuchi,Hattori,Sameshima,Kumagai                       [Page 1]


INTERNET-DRAFT                    ICAP                     July 31, 1998


      2  Basic Definition, Requirements and Assumptions ...........  4
      2.1  CA model ...............................................  4
      2.1.1  Registration Authority ...............................  5
      2.1.2  Issuing Authority ....................................  5
      2.1.3  Publishing Authority .................................  5
      2.1.4  Validation Authority .................................  7
      2.2  Requirement for PKI Application ........................  8
      2.3  Requirement for X.509 Version 3 Certificate and Extensions
                                           ........................  8
      2.4  Requirement for X.509 CRL and Extensions  ..............  9
      3  Protocol Specification ...................................  9
      3.1  transport protocol ..................................... 10
      3.2  request format ......................................... 10
      3.3  response format ........................................ 10
      3.4  Type of Query .......................................... 11
      3.5  certificate issuing request type "certreq" ............. 11
      3.5.1  request .............................................. 11
      3.5.2  response ............................................. 12
      3.6  certificate retrieval type "lookupreq" ................. 13
      3.6.1  "lookupreq" with email address ....................... 14
      3.6.1.1  request ............................................ 14
      3.6.1.2  response ........................................... 14
      3.6.2  "lookupreq" with Distinguished Name .................. 15
      3.6.2.1  request ............................................ 15
      3.6.2.2  response ........................................... 16
      3.6.3  "lookupreq" with Issuer and Serial Number ............ 16
      3.6.3.1  request ............................................ 17
      3.6.3.2  response ........................................... 17
      3.6.4  PA-PA protocol in "lookupreq" ........................ 17
      3.6.4.1  referral model ..................................... 19
      3.6.4.2  chaining model ..................................... 20
      3.7  CA certificate retrieval type "calookupreq" ............ 20
      3.7.1  request .............................................. 20
      3.7.2  response ............................................. 21
      3.7.3  PA-PA protocol in "calookupreq" ...................... 21
      3.8  CRL retrieval type "crlreq" ............................ 22
      3.8.1  request .............................................. 22
      3.8.2  response ............................................. 22
      3.8.3  PA-PA protocol in "crlreq" ........................... 23
      3.9  Certificate Verification type "verifyreq" .............. 24
      3.9.1  request .............................................. 24
      3.9.2  response ............................................. 24
      3.9.2.1 the response in resptype "1" (not to be signed) ..... 24
      3.9.2.2 the response in resptype "2" (to be signed) ......... 25
      3.9.3  VA-VA protocol in "verifyreq" ........................ 27
      3.10 certificate update type "updatereq" .................... 27
      3.11 certificate revocation type "revokereq" ................ 27
      3.12  Correspondence to preceding PKI draft ................. 28



Sakurai,Kikuchi,Hattori,Sameshima,Kumagai                       [Page 2]


INTERNET-DRAFT                    ICAP                     July 31, 1998


      4  Security Considerations .................................. 28
      4.1  Confidentiality of transaction ......................... 28
      4.2  Non-Repudiation ........................................ 28
      4.3  Privacy ................................................ 28
      5  Examples ................................................. 29
      5.1  certreq ................................................ 29
      5.2  lookupreq .............................................. 30
      5.2.1 lookupreq with e-mail address ......................... 30
      5.2.1.1 in case of multiple hits ............................ 30
      5.2.1.2 in case of using Latest option ...................... 31
      5.2.2 lookupreq with Distinguished Name ..................... 32
      5.2.3 lookupreq with Issuer and Serial Number ............... 32
      5.3  calookupreq ............................................ 33
      5.4  crlreq ................................................. 34
      5.5  verifyreq .............................................. 34
      Acknowledgement ............................................. 35
      References .................................................. 35
      Security Considerations ..................................... 37
      Author Addresses ............................................ 37
      Appendix: ICAT-local OIDs ................................... 37

1. Introduction

   This document defines a Web-based protocol to integrate typical CA
   services such as certificate issuing request and certificates/CRLs
   retrieval, based on a practical and compact CA model. In our model, a
   CA supports:

      o multiple application-specific certificate profiles
      o online certificate issuance based on password authentication
      o certificates and CRLs retrieval using CA-CA communications

   First, [PKIX-PROF] defines the general X.509 Certificate and CRL
   profile, and applications compliant to this profile will increase.
   In fact, the certificate profile tends to be application-specific,
   for example, a certificate format for S/MIME and one for SSL is
   different in detail.  Therefore it is practical that a CA should
   support multiple application-specific certificate profiles. In this
   model, a CA is required to be able to distinguish application types
   among certificate issuing requests. Then, we define certificate
   issuing request data including application types.

   Second, in the practical point of view, determining an appropriate
   certificate issuing procedure is very important in PKI. Of course,
   there are several procedures appropriate for each authentication
   level.  A typical procedure is as follows: get a temporary password
   after an authentication step, create key pairs, and have a
   certificate issued using the password in online.  In the model, CA is



Sakurai,Kikuchi,Hattori,Sameshima,Kumagai                       [Page 3]


INTERNET-DRAFT                    ICAP                     July 31, 1998


   required to manage password database, and confirms account and
   password on each certificate issuing.  We define certificate issuing
   request data including account and password information.

   Third, to make CA based applications available in the global
   networks, it is required to retrieve certificates or CRLs not only
   from local repository but also from other repositories.  Furthermore,
   it is convenient for applications that retrieval is done by throwing
   only one query to neighbor CA, without specifying each repository
   corresponding to the issuer CA of the certificate. In this model, a
   CA is required to manage other CA's repository access point
   information and communicate each other.  We define certificate
   retrieval protocols on supposition of CA hierarchy.

   Though the certificate management protocol proposed in [PKIX-CMP]
   does not specify unique transport protocol, HTTP is assumed in this
   document. Now, World Wide Web (WWW) is ubiquitous, and almost all
   internet users can use it even if the site they belong to has a
   firewall against intruders. The WWW provides some useful facilities
   for PKI; such as information caching at both proxy servers and client
   softwares, a secure transport layer service for confidentiality, a
   request forwarding which can be used for CA-CA communications, and
   easy manipulating message format.


2. Basic Definition, Requirements and Assumptions

2.1 CA model


                +------ CA --------+        +------ CA --------+
      +---+     |  +----+  +----+  |        |  +----+  +----+  |
      | E |---->|  | RA |  | IA |  |        |  | RA |  | IA |  |
      | n |     |  +----+  +----+  |        |  +----+  +----+  |
      | d |--+  |                  |        |                  |
      |   |==|===== firewall =======        === firewall =======
      | E |  |  |  +----+  +----+  |        |  +----+  +----+  |
      | n |  +->|  | VA |  | PA |<------------>| PA |  | VA |  |
      | t |     |  +----+  +----+  |        |  +----+  +----+  |
      | i |     |    ^             |        |            ^     |
      | t |     |    |             |        |            |     |
      | y |     |    +-----------------------------------+     |
      |   |     +------------------+        +------------------+
      +---+           ^        ^
                      |        |
                +----------------------------------------------+
                |     End  Entity outside firewall             |
                +----------------------------------------------+



Sakurai,Kikuchi,Hattori,Sameshima,Kumagai                       [Page 4]


INTERNET-DRAFT                    ICAP                     July 31, 1998


                            Figure 1: CA model

   In this model, it is assumed that a CA consists of four authorities:
   Registration Authority (RA), Issuing Authority (IA), Publishing
   Authority (PA), and Validation Authority (VA).  This document defines
   a protocol between RA and end entitity, a protocol between PA and end
   entity, and a protocol between VA and end entity. It also defines
   PA-PA protocols and a VA-VA protocol. But CA internal protocols, such
   as RA-IA, IA-PA, or IA-VA is out of scope in this document.

   The End Entity in the Figure 1 is a PKI application program rather
   than a user.

2.1.1 Registration Authority

   RA is the authority that confirms if the end entity requesting
   service such as certificate issuing, revoking, or updating is the
   real one and then decides to accept the request.  For example, RA
   manages accounts and passwords database. Each account may be bound to
   a user or another RA. Passwords are desired to be disposable to
   prevent replay attack. How to distribute these accounts and passwords
   depends on the security level to be required.

   If the certificate issuing request is acceptable, it is sent to IA.
   There may be multiple RAs in a CA.

2.1.2 Issuing Authority

   IA is the authority that issues X.509 certificates conformed to some
   application-specific certificate profile and also issues X.509 CRLs.
   IA manages a private key for issuing certificates and CRLs, and
   certificate profile information.

   For example, each application-specific certificate profile includes
   information below:
        o application type name
        o public key algorithm
        o signature algorithm
        o validity of certificate
        o X.509 version
        o mandatory attributes in subject of the certificate
        o (in case of X.509 version3) extension fields to be used

   After issuing a certificate, it is sent to PA. After issuing a CRL,
   it is sent to both PA and VA. Note that the certificate including the
   public key of IA is so called the "CA certificate".

2.1.3 Publishing Authority



Sakurai,Kikuchi,Hattori,Sameshima,Kumagai                       [Page 5]


INTERNET-DRAFT                    ICAP                     July 31, 1998


   PA is the authority that stores and distributes X.509 certificates
   and CRLs, that is, certificates and CRLs repository in PKI model
   defined in PKIX WG. PA manages certificates and CRLs database.

   To retrieve certificates or CRLs issued by other CA, PA communicates
   with other PAs, and PA usually is placed outside organization's
   firewalls. Proposing web-based protocol enables end entities inside a
   firewall access to PA outside the firewall with existing web proxy.

   To communicate with other PAs for certificate retrieval, simple
   restricted hierarchical certificate infrastructure is assumed.
   Figure 2 shows an example of hierarchy of PAs, where RootPA has two
   subordinate PAs, PA1 and PA2, having two certificates Cert1 and
   Cert2, respectively.  Each of PA1 and PA2 has the database which at
   least consists of three fields; the own administrative realm, the
   RootPA's realm, and access point to the RootPA. The realm indicates
   e-mail domains and Distinguished Name patterns in the certificates
   managed by a PA. On the other hand, the RootPA has the database of
   the own realm, the subordinate PA's administrative realm and access
   point to each subordinate PA.

   If an end entity throws a query to PA2 asking for Cert1 by some e-
   mail address, PA2 checks its own database and finds the domain of the
   e-mail address is not included in the own realm. PA2 then forwards
   the query to the parent PA, RootPA. RootPA checks its own database
   and finds the domain of the e-mail address in the query is included
   in the own realm. Next RootPA examines each realm of the two
   subordinate PAs, PA1 and PA2, and finds the realm of PA1 includes the
   domain of the e-mail address in the query.  After that, there are two
   methods to get Cert1. One is that RootPA forwards the query to PA1,
   receives Cert1 from PA1, returns Cert1 to PA2, and PA2 returns Cert1
   to the end entity. The other is that RootPA just returns the access
   point of PA1 to PA2, PA2 forwards the query to PA1, PA2 gets Cert1
   from PA1, and PA2 returns Cert1 to the end entity.  Thus the end
   entity can get Cert1 without knowing the access point to PA1.
   Section 3.6.4 describes the way the end entity gets Cert1 in detail.















Sakurai,Kikuchi,Hattori,Sameshima,Kumagai                       [Page 6]


INTERNET-DRAFT                    ICAP                     July 31, 1998



                                                       +-----+
                                                       |     |
                                                RootPA V     |
                                                    +---+    |
                                              +---->| *------+
                                      PA1     |     +---+
                                      +---+   |
                             +--------| *-----+
                  Cert1      |        +---+   |
                      +---+  |                |
                      | *----+                |
                      +---+           PA2     |
                  Cert2               +---+   |
                      +---+           | *-----+
                      | *-------------+---+
                      +---+


                    Figure 2: Example of PAs hierarchy

   To communicate with PAs for CRL retrieval, it is assumed that an end
   entity already has some certificate to be examined and CRL
   distribution points are included in certificate contents.  So, if the
   end entity throws the query to the PA2 for CRL of PA1 in Figure 2,
   PA2 gets CRL distribution point from the given certificate, and
   accesses to the point. In this example, the end entity may directly
   access to the PA1 to get CRL, but this document provides PA-PA
   communication for convenience.

2.1.4 Validation Authority

   VA is the authority that decides if a specific certificate is valid
   or not, similar to the responder supporting Online Certificate Status
   Protocol (OCSP) [PKIX-OCSP]. VA is useful when it is anticipated that
   CRL size is too big and each application cannot scan the CRL quickly
   to examine validity of a certificate. VA has own CA's CRLs but does
   not have parent CA's CRLs. It is not VAs but end entities that are
   responsible for confirming hierarchical validation paths.

   When VA replies to end entity's query without secure transport, it is
   basically required to sign the reply to prevent forgery. So, VA may
   have private key.  To ask validity of a certificate issued by other
   CA, VA communicates with other VAs. Considering that a query to VA
   comes from other VAs or end entities outside organizations, VA is
   placed outside of a firewall. And considering that a reply should be
   returned quickly, the private key to sign replies is placed outside
   of a firewall and used automatically in online. If the private key of



Sakurai,Kikuchi,Hattori,Sameshima,Kumagai                       [Page 7]


INTERNET-DRAFT                    ICAP                     July 31, 1998


   VA is same with that of IA, security level of the CA depends on that
   of VA, no matter how the private key of IA is protected inside a
   firewall.  Then it is preferable that private key of VA is distinct
   from that of IA.

   It is assumed that end entity already has some certificate to be
   examined and VA access points are included in certificate contents.
   If the end entity throws the query to the neighbor VA, say VA1, to
   check the validity of certificate issued by other CA, the VA1 gets
   access point from the given certificate and forwards the query to the
   access point, VA2.  In this case, the end entity has direct access to
   the VA2, but this document provides such a VA-VA communication for
   convenience.

2.2 Requirement for PKI Application

   The PKI application typically needs access to CA in the following
   four cases;

   1. certificate issuing request.
      As one of installation steps of application, a new certificate
      is required to be issued.

   2. certificate retrieval.
      For example, a sender of secure message wants to retrieve
      the recipient's public key with which the message is to be
      encrypted. Further, the recipient of secure message wants to
      retrieve certificate of CA which issued the sender's certificate.

   3. certificate verification.
      The recipient of secure message checks if the sender's certificate
      is not revoked by examining the corresponding CRL or asking
      the CA directly.

   4. certificate and CRL publication.
      Soon after a certificate is issued by a CA, the new certificate
      shall be got access for anybody who wants it.

2.3 Requirement for X.509 Version 3 Certificate and Extensions

   This proposal supposes that subset of X.509 Version 3 is used to form
   public key certificates. According to [PKIX-PROF], the subject and
   issuer names in X.509 (Version 1) may be an empty sequence and
   subjectAltName and issuerAltName extensions (Version 3) shall be
   specified instead of the field. Even if the subject and issuer names
   are specified, the subjectAltName shall be given as an identification
   of certificate retrieval.




Sakurai,Kikuchi,Hattori,Sameshima,Kumagai                       [Page 8]


INTERNET-DRAFT                    ICAP                     July 31, 1998


   Most PKI applications require many kinds of information about
   certificate including policy information, CRL, and VA information. In
   [PKIX-PROF], several access methods are defined for each kind of
   information.  However, it is not so often case that a certain
   application has multiple access methods to PKI. Therefore, this
   document assumes that PKI application has an uniform access method of
   HTTP for the simplification of PKI protocol.

   If this proposal is used, a standard certificate must specify

      - authorityInfoAccess
      - cRLDistributionPoints

   shall specify

      - subjectAltName,
      - issuerAltName,

   may specify

      - authorityKeyIdentifier,
      - subjectKeyIdentifier,
      - keyUsage,
      - privateKeyUsagePeriod,
      - certificagtePolicies,
      - basicConstraints,
      - nameConstraints,
      - policyConstraints,
      etc.

2.4 Requirement for X.509 CRL and Extensions

   This proposal supposes that subset of X.509 Version 1 and Version 2
   are used to form CRL.

   If the X.509 Version 2 CRL is used, a standard CRL shall specify

      - reasonCode

   may specify

      - CRL Number
      etc.

3. Protocol Specification

3.1 transport protocol




Sakurai,Kikuchi,Hattori,Sameshima,Kumagai                       [Page 9]


INTERNET-DRAFT                    ICAP                     July 31, 1998


   This proposal assumes that either of a standard HTTP protocol or
   HTTPS protocol i.e. HTTP/SSL [SSL], is used as transport protocol.
   Thus, RA, IA, PA, and VA server can be implemented as a standard HTTP
   server which enables CGI facility.

3.2 request format

   The request is sent with the POST method of the HTTP.  Thus, the
   typical query is formatted as follows:

           POST /cgi-bin/queryType HTTP/1.0
           Content-length: xx

           name1=value1&name2=value2&...&namen=valuen

   where "queryType" is a type of query, and a pair of "name" and
   "value" are used to send PKI message. All pairs are encoded according
   to the rule defined in [HTTP].

   (Note1) When the content length is computed, return code is treated
           as 2 length, which consists of CR and LF.

   (Note2) When the value is encoded according to Base64 rule [Base64],
           end entity must substitute "+" code of Base64 with
           "%2b". And when the end entity sends the request on the
           telnet protocol, not sending directly from the socket, "="
           code of Base64 must be also substituted with "%3d".

3.3 response format

   In the response, text/plain content-type is used and simply formatted
   as follows:

           HTTP/1.0 200 OK
           Date: Wednesday
           MIME-version: 1.0
           Content-type: text/plain

           queryType
           statusCode statusMessage
           INFORMATION

   The "queryType" is the same as the type given in sending request and
   this shows the first line of response.  Second line consists of
   "statusCode" and "statusMessage".

   The "statusCode" indicates brief processing status category. The
   "statusCode" contains three digit codes.  With at least one space,



Sakurai,Kikuchi,Hattori,Sameshima,Kumagai                      [Page 10]


INTERNET-DRAFT                    ICAP                     July 31, 1998


   the "statusMessage" follows and it contains the description of the
   "statusCode". "2xx" of "statusCode" indicates successful processing,
   and "3xx" of "statusCode" indicates error.

   The "statusMessage" gives some hints on error handling, and it may
   have several message patterns for a "statusCode".

   The third line, "INFORMATION" is interpreted in corresponding
   semantics.  The syntax of "INFORMATION" depends on the query type,
   and will be defined in the later sections.

   This simple response format is appropriate for application to
   interpret the response.

3.4 Type of Query

   This document defines the following seven query types.  Those names
   are used as "queryType" value in request and response format.

           1. certreq         2. lookupreq         3. calookupreq
           4. crlreq          5. verifyreq         6. updatereq
           7. revokereq

   "certreq", "updatereq" and "revokereq" are requests to RA.
   "lookupreq", "calookupreq", and "crlreq" are requests to PA.  And,
   "verifyreq" is a request to VA.

3.5 certificate issuing request type "certreq"

   Type "certreq" is used for sending certificate issuing request to RA.

3.5.1 request

   The certreq request shall be sent with the following pairs of name
   and value.

           name            value
           ----            -----
           PKCS10          extended PKCS#10 [PKCS-10] data,  Base64
                           encoded

   The extended PKCS#10 format must include the following fields:
     o  Subject
     o  SubjectPublicKeyInfo
     o  account and password attributes for authentication of the end
        entity
     o  application type attribute to specify certificate profile




Sakurai,Kikuchi,Hattori,Sameshima,Kumagai                      [Page 11]


INTERNET-DRAFT                    ICAP                     July 31, 1998


   The extended PKCS#10 format may include the following field in
   optional:
     o  extension fields attributes for the X.509 version3 extensions

        Extension fields attributes may be used if the value of the
        extension field should be specified by end entity itself, not CA
        policy.

   Subject and SubjectPublicKeyInfo conform to standard PKCS#10.  The
   rest four attributes, account, password, application type, and
   extension fields are defined as follows:


           Account     ::= UnstructuredName
                           - account
           Password    ::= ChallengePassword
                           - password
           App         ::= PrintableString
                           - application type
           V3Extn      ::= Extensions
                           - extension field


   Note that attribute "UnstructuredName" and "ChallengePassword" are
   defined in PKCS#9 [PKCS-9]. Extensions are defined in [X.509] or also
   described in [PKIX-PROF].  Attribute "App" and "V3Extn" are
   originally defined and Appendix shows our local OID definitions for
   these two attributes.


3.5.2 response

   The response consists of statusCode, statusMessage and INFORMATION.
   In "certreq" type, statusCode definition is as follows:

       statusCode   meaning
       ----------   -----------------------------------------
          200       successfully processed
          301       request is incomplete
          302       the certificate has already been issued
          303       request is rejected
          304       service is not available
          305       (reserved)

   If the statusCode is "200", the INFORMATION in response is the issued
   certificate encoded in Base64 format.  Otherwise, INFORMATION is
   empty.




Sakurai,Kikuchi,Hattori,Sameshima,Kumagai                      [Page 12]


INTERNET-DRAFT                    ICAP                     July 31, 1998


   statusMessage is defined as follows:

       statusCode  statusMessage
       ----------  -------------
           200     "accept your request"

           301     "not PKCS10 format"

           301     "signature verification failed"

           301     "missing mandatory field (xxx)"
                    where xxx is a name of missing field.

           302     "detect duplicated DN"

           303     "public key algorithm not supported "

           303     "signature algorithm not supported "

           303     "extension field (xxx) not supported "
                    where xxx is OID, e.g. "551d11"

           303     "application (xxx) not supported"
                    where xxx is an application type name,
                    e.g. "smime"

           303     "authentication failed"

           303     "can't issue cert anymore"

           303     "access denied"

           304     "service not available"

3.6 certificate retrieval type "lookupreq"

   The "lookupreq" type is used for retrieving and searching certificate
   from PA.

   Certificate is identified by either of the following name forms;

           a. email address
           b. Distinguished Name
           c. Issuer and Serial Number

   All name forms must be fully specified because a substring matching
   rule might violate a privacy issue when the PA is the outside of
   firewall.



Sakurai,Kikuchi,Hattori,Sameshima,Kumagai                      [Page 13]


INTERNET-DRAFT                    ICAP                     July 31, 1998


   The request and response format are described in the next clauses.

3.6.1 "lookupreq" with email address

3.6.1.1 request

   The lookup query is sent with the following pairs of name and value.

       name                value
       ----                -----
       EmailAddress        e-mail address string

       TimePeriod          (optional) months and years string
                           conforming to the following syntax
                           YYYYMM[HH|HHMM|HHMMSS]

       Latest              (optional) "1"

       KeyUsage            (optional)
                           one of the following strings
                           "digitalSignature","nonRepudiation",
                           "keyEncipherment","dataEncipherment",
                           "keyAgreement",etc.

   The "EmailAddress" pair is a mandatory for this type of request.
   "TimePeriod" may be used when the end entity wants some expired or
   revoked certificates. If "TimePeriod" is not specified, expired or
   revoked certificates are not searched.  "Latest" may be used when the
   end entity wants the latest certificate even if the multiple
   certificates are hit. "KeyUsage" may be used if the end entity wants
   to get some certificate for a specific purpose.

3.6.1.2 response

   The response consists of statusCode, statusMessage and INFORMATION.
   In "lookupreq" type, statusCode definition is as follows:

       statusCode   meaning
       ----------   -----------------------------------------
          200       successfully processed and uniquely retrieved.
          201       successfully processed but got multiple hits
          301       request is incomplete
          303       request is rejected
          304       service is not available

   If the statusCode is "200", the INFORMATION in response format is
   the certificate encoded in Base64 format.  If the statusCode is
   "201", the INFORMATION in response format is DN lists originally



Sakurai,Kikuchi,Hattori,Sameshima,Kumagai                      [Page 14]


INTERNET-DRAFT                    ICAP                     July 31, 1998


   defined in this document.  Otherwise, INFORMATION is empty.

       statusCode  statusMessage
       ----------  -------------
           200     "accept your request"

           201     "found several certs"

           301     "existed, but revoked"

           303     "existed, but expired"

           303     "no match"

           303     "unknown CA"

           303     "unknown mail domain"

           303     "not correct input"

           303     "hit too many cert"
                   note that it depends on CA policy whether this
                   message is used or not.

           304     "service not available"

   DN list syntax is defined as follows:
           IssuerAndSerialNumberData + ":" + DistinguishedNameData

   IssuerAndSerialNumberData is IssuerAndSerialNumber data defined in
   PKCS#7 [PKCS-7], encoded in Base64 format. DistinguishedNameData is a
   string representation of Distinguished Names defined in [RFC1779].

   The DN list example is shown here:

   MIIDSzCCAw0CAQAwggEZMRAwDgYDVQQGEwcbJEJGfEtcMREwDw:CN=Christian
   Huitema, O=INRIA, C=FR

   Note that this is one line.

3.6.2 "lookupreq" with Distinguished Name

3.6.2.1 request

   The lookup query is sent with the following pairs of name and value.

           name            value
           ----            -----



Sakurai,Kikuchi,Hattori,Sameshima,Kumagai                      [Page 15]


INTERNET-DRAFT                    ICAP                     July 31, 1998


           c               Country

           o               Organization

           cn              Common name

           ou1             (optional) Organizational unit

           ou2             (optional) Organizational unit 2

           ou3             (optional) Organizational unit 3

           ou4             (optional) Organizational unit 4

           sopn            (optional) StateOrProvinceName

           Locality        (optional) Locality

           StrAddr         (optional) StreetAddress

           pcode           (optional) postal code

           phnum           (optional) phone number

           title           (optional) title

       TimePeriod          (optional) months and years
                           conforming to the following syntax
                           YYYYMM[HH|HHMM|HHMMSS]

   The pairs of  "c", "o", "cn" are mandatory.  When the specification
   is incomplete, the PA may reject it for privacy issue or accept it as
   substring matching.

3.6.2.2 response

   The response is same with the one defined in the  previous clause
   3.6.1.2 except that "303 unknown mail domain" is replaced below:

       statusCode  statusMessage
       ----------  -------------
           303     "unknown DN"


3.6.3 "lookupreq" with Issuer and Serial Number

3.6.3.1 request




Sakurai,Kikuchi,Hattori,Sameshima,Kumagai                      [Page 16]


INTERNET-DRAFT                    ICAP                     July 31, 1998


   The lookup query is sent with the following pairs of name and value.

           name            value
           ----            -----
           IASN            IssuerAndSerialNumber data defined in
                           PKCS#7 [PKCS-7], encoded in Base64 format

3.6.3.2 response

   The response is same with the one defined in clause 3.6.1.2 except
   "201" response, because IASN should specify unique certificate.

3.6.4 PA-PA protocol in "lookupreq"

   A PA server may forward a request to another PA server when it does
   not have sufficient information to response to the request. If a PA
   which does not support PA-PA protocol should response the statusCode
   "303" with the statusMessage "unknown CA".

   Suppose that there are PA1, PA2 and RootPA, and PA1 has a request for
   retrieving a certificate from PA2. The PA1 and the PA2 does not have
   their access point but the access point to RootPA. There are two
   possibilities for PA1 to get access to PA2 (Figure 3).


    - Model 1. [referral] PA1 sends the request to RootPA (1), which
           then replies to PA1 with the access point to PA2 (2).
           PA1 forwards the request to PA2 again (3), and finally PA1
           gets the information from PA2.

    - Model 2. [chaining] PA1 sends the request to RootPA (1), which
           redirects it to PA2 on behalf of PA1 (2). PA2 answers
           to Root PA (3), which forwards it to PA1 (4).



        +---->[RootPA]                          +---->[RootPA](2)---+
        | +---(2)                               | +---(4)     <---+ |
        | |PA2                                  | |               | |
        | |                                     | |               | |
     (1)| V                                  (1)| V            (3)| V
       [PA1] (3)-----------> [PA2]             [PA1]             [PA2]
             <-----------(4)
              Referral                                Chaining


                          Figure 3. PA-PA models




Sakurai,Kikuchi,Hattori,Sameshima,Kumagai                      [Page 17]


INTERNET-DRAFT                    ICAP                     July 31, 1998


   To implement these two models, each PA must have information about
   its own realm in order to determine if the "lookupreq" request should
   be forwarded. Since the request includes an e-mail address or part of
   a Distinguished Name in a certificate, if the realm is represented
   with e-mail address domain lists or Distinguished Name patterns, PA
   can easily decide to answer directly or to forward.

   Addition to its own realm information, PA1 and PA2 must know the URL
   of RootPA server to forward the request. In general, there may be
   multiple root PAs for a PA.  RootPA, which does not necessarily
   correspond to the root of a CA hierarchy, must know the URL of PA1
   and PA2 as subordinate PAs to forward the request (in the chaining
   model) or return the location information (in the referral model).

   In the Figure 3, the depth of the virtual PA hierarchy is only one
   and there are only a root PA and leaf PAs. However, there could be
   deeper PA hierarchies and mediate PAs can exist. A mediate PA acts
   like a router, i.e. it forwards a request to a parent PA or a child
   PA according to its own realm information.  Then each PA must know
   which topology type it belongs to; top, leaf or mediate.

   In this example, RootPA manages the database in the following form:


   Me:TOP:RootPA.lll.or.jp:aaa.bb.co.jp, ccc.bb.co.jp, foo.ff.co.jp,
      bar.ff.co.jp
   Child:LEAF:PA1.bb.co.jp:aaa.bb.co.jp, ccc.bb.co.jp
   Child:LEAF:PA2.ff.co.jp:foo.ff.co.jp, bar.ff.co.jp


   Each line in the database consists of ":" separated fields.

   If the first field of each line is "Me", then the line contains the
   information about the owner PA of the database. If the first field of
   each line is "Child", then the line contains the information about a
   child PA for the owner PA of the database.  If the first field of
   each line is "Parent", then the line contains the information about a
   parent PA for the owner PA of the database.

   If the second field of each line is "TOP", then the PA is the root in
   a PA hierarchy.  If the second field of each line is "MEDIATE", then
   the PA is mediate in a PA hierarchy.  If the second field of each
   line is "LEAF", then the PA is a leaf in a PA hierarchy.

   The third field of each line shows the PA server's name and the
   fourth field of each line shows a realm with e-mail domain lists,
   separated with commmas. For simplicity, the DN pattern lists are
   omitted in this database.



Sakurai,Kikuchi,Hattori,Sameshima,Kumagai                      [Page 18]


INTERNET-DRAFT                    ICAP                     July 31, 1998


   In the example above, the first line indicates that RootPA is a TOP
   in the PA tree, the hostname is "RootPA.lll.or.jp", and the realm
   includes the four e-mail domains; "aaa.bb.co.jp", "ccc.bb.co.jp",
   "foo.ff.co.jp" and "bar.ff.co.jp". The next two lines indicates that
   RootPA has two child PAs, both PAs are a LEAF in the PA tree; one is
   "PA1.bb.co.jp" and another is "PA2.ff.co.jp". Note that an union of
   these two child PA realms makes RootPA realm.

   Similarly, PA1 manages the database in the following form:


   Me:LEAF:PA1.bb.co.jp:aaa.bb.co.jp, ccc.bb.co.jp
   Parent:TOP:RootPA.lll.or.jp:aaa.bb.co.jp, ccc.bb.co.jp, foo.ff.co.jp,
       bar.ff.co.jp


   In this example, the first line indicates that PA1 is a LEAF in the
   PA tree, the hostname is "PA1.bb.co.jp", and the realm includes the
   two e-mail domains; "aaa.bb.co.jp" and "cc.bb.co.jp". The second line
   indicates that PA1 has a parent PA, named with "RootPA.lll.or.jp",
   and the parent PA realm includes the four e-mail domains;
   "aaa.bb.co.jp", "ccc.bb.co.jp", "foo.ff.co.jp" and "bar.ff.co.jp".

   If the realm of RootPA is changed, the all subordinate PAs, PA1 and
   PA2 must update the realm field of "Parent" line in the database.  To
   solve this problem, special server such as SecureDNS is required to
   manage the correspondences between a realm of a PA and an access
   point to the PA server, such as URL. Thus, each PA can examine the
   access point to the target PA by asking to the special server instead
   of RootPA. Even if the topology of the PA tree is changed, only the
   special server's database is to be updated.

3.6.4.1 Referral Model

   To redirect a request to another PA server, the root PA responds to
   the requester with the following format.

       statusCode  statusMessage        INFORMATION
       ----------  -------------------- ------------
          202      "ask other CA"        URL

   The example of URL is "http://xxx.yy:zz/cgi-bin/lookupreq", which
   provides information where the query should be sent next.

   The root PA must respond with either correct PA location or error
   message to mean that there is no certificate.

   Each round trip time is short, but the neighbor PA for a requestor



Sakurai,Kikuchi,Hattori,Sameshima,Kumagai                      [Page 19]


INTERNET-DRAFT                    ICAP                     July 31, 1998


   has to send the same query to several servers.

3.6.4.2 Chaining Model

   To implement chaining model, the CGI script of the root PA produces
   an extra CGI message before it responds to the request originator.

   The request originator, PA1 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 more than that of the referral model. Many requests in a
   short time makes load of the root PA server heavy.  But, if the
   network speed between PA1 and PA2 is slower than that between PA2 and
   root PA, chaining model is useful.

   In our experiment, ten requests a minute makes no significant
   difference in round trip time between these 2 models.

3.7 CA certificate retrieval type "calookupreq"

   The "calookupreq" type is used for retrieving and searching the CA
   certificate from PA.

3.7.1 request

   The calookupreq query is sent with the following pairs of name and
   value.


       name                value
       ----                -----
       cert                (optional) certificate encoded in Base64
                           format

       TimePeriod          (optional) months and years string
                           conforming to the following syntax
                           YYYYMM[HH|HHMM|HHMMSS]


       KeyUsage            (optional)
                           one of the following strings
                           "keyCertSign",  "cRLSign", etc.


   All the pairs are optional in "calookupreq".  If the "cert" is not
   specified, it is assumed that the PA is required to response the
   certificate of own CA.  "TimePeriod" may be used when the end entity
   wants some expired or revoked CA certificates. If "TimePeriod" is not



Sakurai,Kikuchi,Hattori,Sameshima,Kumagai                      [Page 20]


INTERNET-DRAFT                    ICAP                     July 31, 1998


   specified, expired or revoked certificates are not searched.
   "KeyUsage" may be used if the end entity wants to get some CA
   certificate for a specific purpose.

3.7.2 response

   The response consists of statusCode, statusMessage and INFORMATION.
   In "calookupreq" type, statusCode definition is as follows:

       statusCode   meaning
       ----------   -----------------------------------------
          200       successfully processed
          303       request is rejected
          304       service is not available

   If the status code is "200", the CA certificate encoded in Base64
   format is appeared as INFORMATION in response format.  Otherwise,
   INFORMATION field is empty.

   statusMessage is defined as follows:

       statusCode   statusMessage
       ----------   -------------
          200       "accept your request"

          303       "not certificate format"

          303       "unknown CA"

          303       "the URL not found"

          303       "AuthorityInfoAccess not included"

          304       "timeout"

          304       "service not available"

3.7.3 PA-PA protocol in "calookupreq"

   A PA server may forward a request to another PA server when it does
   not have sufficient information to response to the request. If a PA
   which does not support PA-PA protocol should response the statusCode
   "303" with the statusMessage "unknown CA".

   Suppose that there are PA1 corresponding to CA1, and PA2
   corresponding to CA2, and PA1 has a request for CA2 certificate from
   PA2. PA1 gets the URL to PA2 from the AuthorityInfoAccess field in
   the certificate which PA1 received from the requester. Then PA1



Sakurai,Kikuchi,Hattori,Sameshima,Kumagai                      [Page 21]


INTERNET-DRAFT                    ICAP                     July 31, 1998


   forwards the request to PA2, receiving the response from PA2, and
   returns the response to the requester.

3.8 CRL retrieval type "crlreq"

   The "crlreq" type is used for retrieving a CRL from PA.

3.8.1 request

   The crlreq query is sent with the following pairs of name and value.

       name            value
       ----            -----
       cert            (optional) certificate encoded in Base64
                       format

       reason          (optional) specifying CRL reason code
                       one of the following strings
                        "keyCompromise","cACompromise",
                        "affiliationChanged","superseded",
                        "cessationOfOperation", "certificateHold",
                        etc.

   All the pairs are optional in crlreq.  If the "cert" is not
   specified, it is assumed that the PA is required to response the CRL
   of own CA.  The "reason" may be used when the end entity wants some
   reason-specific CRL.

3.8.2 response

   The response consists of statusCode, statusMessage and INFORMATION.
   In "crlreq" type, statusCode definition is as follows:

       statusCode   meaning
       ----------   -----------------------------------------
          200       successfully processed
          201       successfully processed, but CRL doesn't exist
          202       successfully processed, but multiple CRLs exist
          303       request is rejected
          304       service is not available

   If the status code is "200", INFORMATION in response format is the
   CRL encoded in Base64 format. If the status code is "202",
   INFORMATION in response format is the reason list strings which shows
   the CRLreasoncode of each CRL, so that the end entity could specify
   the "reason" in the next request.  Otherwise, INFORMATION in response
   format is empty.




Sakurai,Kikuchi,Hattori,Sameshima,Kumagai                      [Page 22]


INTERNET-DRAFT                    ICAP                     July 31, 1998


   The reason list is defined as comma separated strings. Each string is
   the same with "reason" value in the request. The order is not
   considered.

   ["keyCompromise"][,]["caCompromise"][,]["affiliationChanged"][,]
   ["superseded"][,]["cessationOfOperation"][,]["certificateHold"]


   The statusMessage is defined as follows:

        statusCode      statusMessage
        ----------      ------------------------------
           200          "accept your request"

           201          "not issued"

           202          "specify CRL reason"

           303          "not certificate format"

           303          "unknown CA"

           303          "CRLDistributionPoints not included"

           303          "the URL not found"

           304          "timeout"

           304          "service not available"


3.8.3 PA-PA protocol in "crlreq"

   A PA server may forward a request to other PA server when it does not
   have sufficient information to response to the request. If a PA which
   does not support PA-PA protocol should response the statusCode "303"
   with the statusMessage "unknown CA".

   Suppose that there are PA1 corresponding to CA1, and PA2
   corresponding to CA2, and PA1 has a request for CA2 CRL from PA2. PA1
   gets the URL to PA2 from the cRLDistributionPoints field in the
   certificate which PA1 received from the requester. Then PA1 forwards
   the request to PA2, receiving a response from PA2, and returns the
   response to the requester.

3.9 Certificate Verification type "verifyreq"

   The "verifyreq" type is used for validation check of certificate.



Sakurai,Kikuchi,Hattori,Sameshima,Kumagai                      [Page 23]


INTERNET-DRAFT                    ICAP                     July 31, 1998


   This document does not support path validation.

3.9.1 request

   The verifyreq request shall be sent with the following pairs of name
   and value.

           name            value
           ----            -----
           cert            certificate encoded in Base64 format

           resptype        response type string, "1" or "2"
                           "1" requires the response not to be signed,
                           "2" requires the response to be signed.

   All these pairs are mandatory in verifyreq.  The "resptype" is used
   for specifying whether the response is required to be signed ("2") or
   not ("1"). The end entity should decide the response type depending
   on the transport or network environment.

   The response is defined separately according to the "resptype".

3.9.2 response

3.9.2.1 the response in resptype "1" (not to be signed)

   The response consists of statusCode, statusMessage and INFORMATION.
   The statusCode definition is as follows:


       statusCode   meaning
       ----------   -----------------------------------------
          200       successfully processed and valid
          201       successfully processed and invalid
          202       successfully processed and revoked
          203       successfully processed and expired
          204       successfully processed and hold
          303       request is rejected
          304       service is not available

   If the statusCode is "202", the INFORMATION in the response format is
   the UTCtime string of revoked time. Otherwise, the INFORMATION in the
   response format is empty.

   The statusMessage is defined as follows:

        statusCode      statusMessage
        ----------      ------------------------------



Sakurai,Kikuchi,Hattori,Sameshima,Kumagai                      [Page 24]


INTERNET-DRAFT                    ICAP                     July 31, 1998


           200          "valid"

           201          "invalid"

           202          "revoked"

           203          "expired"

           204          "hold"

           303          "not certificate format"

           303          "the URL not found"

           303          "unknown response type"

           303          "unknown CA"

           303          "AuthorityInfoAccess not included"

           303          "signature verification failed"

           304          "timeout"

           304          "service not available"

3.9.2.2 the response in resptype "2" (to be signed)

   The response consists of statusCode, statusMessage and INFORMATION.
   The statusCode definition is as follows:


       statusCode   meaning
       ----------   -----------------------------------------
          200       successfully processed
          303       request is rejected
          304       service is not available

   If the statusCode is "200", the INFORMATION in the response format is
   the digitally signed verification result defined originally in ASN.1,
   encoded in Base64 format. Otherwise, the INFORMATION in the response
   format is empty.

   The signed verification result format is defined as follows:

    Reply ::= SEQUENCE { SIGNED SET {
        version [0] INTEGER default 0,
                SEQUENCE {



Sakurai,Kikuchi,Hattori,Sameshima,Kumagai                      [Page 25]


INTERNET-DRAFT                    ICAP                     July 31, 1998


        issuer  [1] Name,
        serialNumber [2] Integer } OPTIONAL,
        verificationResult [3] VerificationResult,
        validationTime  [4] GeneralizedTime
        revokedReason   [5] RevokedReason OPTIONAL,
        revokedOrHoldTime [6] GeneralizedTime OPTIONAL,
        holdExpirationTime [7] GeneralizedTime OPTIONAL,
        holdInstructionCode [8] OBJECT IDENTIFIER OPTIONAL}
        CertificationPath OPTIONAL }

        VerificationResult ::= ENUMERATE {
         notRevoked(0), revoked(1), expired(2), hold(3) }

        RevokedReason ::= ENUMERATE {
          unspecified (0),
          keyCompromise (1),
          caCompromise (2),
          affiliationChanged (3),
          superseded (4),
          cessationOfOperation (5) }

        holdInstructionCode ::= OBJECT IDENTIFIER

           holdInstruction    OBJECT IDENTIFIER ::=
                        { iso(1) member-body(2) us(840) x9-57(10040) 2 }

           id-holdinstruction-none   OBJECT IDENTIFIER ::=
                        {holdInstruction 1}
           id-holdinstruction-callissuer
                                     OBJECT IDENTIFIER ::=
                        {holdInstruction 2}
           id-holdinstruction-reject OBJECT IDENTIFIER ::=
                        {holdInstruction 3}


   The statusMessage is defined as follows:

        statusCode      statusMessage
        ----------      ------------------------------
           200          "accept your request"

           303          "not certificate format"

           303          "the URL not found"

           303          "unknown response type"

           303          "unknown CA"



Sakurai,Kikuchi,Hattori,Sameshima,Kumagai                      [Page 26]


INTERNET-DRAFT                    ICAP                     July 31, 1998


           303          "AuthorityInfoAccess not included"

           304          "timeout"

           304          "service not available"


3.9.3 VA-VA protocol in "verifyreq"

   A VA server may forward a request to other VA server when it does not
   have sufficient information to response to the request. If a VA which
   does not support VA-VA protocol should response the statusCode "303"
   with the statusMessage "unknown CA".

   Suppose that there are VA1 corresponding to CA1, and VA2
   corresponding to CA2, and VA1 has a request for CA2 CRL from VA2. VA1
   gets the URL to VA2 from the authorityInfoAccess field in the
   certificate which VA1 received
    from the requester. Then VA1 forwards the request to VA2, receiving
   a response from VA2, and returns the response to the requester.

3.10 certificate update type "updatereq"

   The "updatereq" is a request to update a certificate.

      [TBD]

3.11 certificate revocation type "revokereq"

   The "revokereq" is a request 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 conventional application that supports digital
   signature.

      [TBD]

3.12 Correspondence to preceding PKI draft

   This document corresponds to PKI management protocol defined in
   [PKIX-CMP],[PKIX-OCSP],[PKIX-OPP],[PKIX-LDAP]. Table 1 shows the
   correspondence.

                    Table 1. Correspondence of methods


      ICAP method   PKI method
      -----------   ----------



Sakurai,Kikuchi,Hattori,Sameshima,Kumagai                      [Page 27]


INTERNET-DRAFT                    ICAP                     July 31, 1998


      certreq       CMP(PKCS #10 Cert. Req), WebCAP(MKCERT)
      lookupreq     OPP(FTP and HTTP),OPP(LDAP), WebCAP(GETCERT)
      calookupreq   OPP(LDAP)
      crlreq        OPP(LDAP), WebCAP(GETCERT)
      verifyreq     OCSP, WebCAP(VRFYCERT)
      revokereq     CMP(Revocation Request), WebCAP(RMCERT)
      updatereq


4. Security Considerations

4.1 Confidentiality of transaction

   To prevent message from being eavesdropped, secure communication
   channel such as SSL(TLS) shall be used. Especially, initial
   registration process is critical to eavesdropping. Since user
   authentication is checked with account and password, a client
   software is not required to have its own certificate.  Under this
   assumption, PKI message protection proposed in [PKIX-CMP] need not
   here.

4.2 Non-Repudiation

   The verifyreq 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 PA must manage all certificates which it
   has already been issued, including revoked certificates.



4.3 Privacy

   In the lookupreq, the support of substring matching facility may
   distribute private information to outsiders, and thereby may be used
   for sending an advertisement via email.

5. Examples

5.1 certreq

   %telnet cahost1 80
   Trying 123.16.5.41 ...
   Connected to cahost1.
   Escape character is '^]'.
   POST /cgi-bin/certreq HTTP/1.0
   Content-length: 1137

   PKCS10=MIIDPzCCAwYCAQAwggEUMQswCQYDVQQGEwJKUDERMA8GA1UECBMIWW9rb2hh



Sakurai,Kikuchi,Hattori,Sameshima,Kumagai                      [Page 28]


INTERNET-DRAFT                    ICAP                     July 31, 1998


   bWExEzARBgNVBAcTClRvdHN1a2Eta3UxFDASBgNVBAkTC1RvdHN1a2EtY2hvMS8wLQY
   DVQQKEyZIaXRhY2hpIFNvZnR3YXJlIEVuZ2luZWVyaW5nIENvLiwgTHRkLjEbMBkGA1
   UECxMSRGF0YSBDb21tdW5pY2F0aW9uMQ0wCwYDVQQMEwRISVJBMQwwCgYDVQQREwMyN
   DQxFTATBgNVBBQTDDAxMjAtNDY4ODEyMTEYMBYGA1UEAxMPSGl0b3NoaSBLdW1hZ2Fp
   MSswKQYJKoZIhvcNAQkBExxoaXRvc2hpQG9yaS5oaXRhY2hpLXNrLmNvLmpwMIHXMIG
   pBgoqgwiGjScHAQUBMIGaAgEBMCMGCiqDCIaNJwcBBgECFQD///////////mvyqjt91
   qfEHYKrzAsBBQAAAAAAAAAAAAAAAAAAAAAAAAAAAQUAAAAAAAAAAAAAAAAAAAAAAAAA
   MAEKAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAABACFQD/////
   //////mvyqjt91qfEHYKrwIBAAMpAPI7g4TgW3RXWs2beo0BFCGHgNaQp//etDYwV9H
   F3DlMy5u/ZP3CrTmgggENMBQGCSqGSIb3DQEJAjEHFgVTTUlNRTAUBgkqhkiG9w0BCQ
   cxBxMFU01JTUUwFAYJqqqqqqqqqqqqMQcTBVBFUE9QMIHIBgm7u7u7u7u7u7sxgbowg
   bcwgbQGBv///////wEBAASBpjCBozCBgjAvBgNVBAoxKBMmSGl0YWNoaSBTb2Z0d2Fy
   ZSBFbmdpbmVlcmluZyBDby4sIEx0ZC4wEwYDVQQHMQwTClRvdHN1a2Eta3UwDQYDVQQ
   MMQYTBEhJUkEwKwYJKoZIhvcNAQkBMR4WHGhpdG9zaGlAb3JpLmhpdGFjaGktc2suY2
   8uanAXDTAwMDAwMDAwMDAwMFoXDTAwMDAwMDAwMDAwMFowCQYF/////wQFAAMokGUe2
   gyH92D5W7J/ms8119ibcQlXXU54Rtne9GEh15462oYwqnAraw%3d%3d

   HTTP/1.0 200 Document follows
   Date: Thu, 25 Sep 1997 10:50:46 GMT
   Server: NCSA/1.5.1
   Content-type: text/plain

   certreq
   200 accept your request
    MIIENzCCA9SgAwIBAgIBJjAOBgoqgwiGjScHAQIHBQAwTTELMAkGA1UEBhMCSlAx
    DDAKBgNVBAoTA05FQzEwMC4GA1UECxMnTmV0d29ya2luZyBTeXN0ZW1zIExhYnMg
    RXhwZXJpbWVudGFsIENBMB4XDTk3MDkyNTEwNTA0NFoXDTk3MTIyNDEwNTA0NFow
    gf0xCzAJBgNVBAYTAkpQMREwDwYDVQQIEwhZb2tvaGFtYTETMBEGA1UEBxMKVG90
    c3VrYS1rdTEUMBIGA1UECRMLVG90c3VrYS1jaG8xDDAKBgNVBBETAzI0NDEvMC0G
    A1UEChMmSGl0YWNoaSBTb2Z0d2FyZSBFbmdpbmVlcmluZyBDby4sIEx0ZC4xGzAZ
    BgNVBAsTEkRhdGEgQ29tbXVuaWNhdGlvbjEYMBYGA1UEAxMPSGl0b3NoaSBLdW1h
    Z2FpMQ0wCwYDVQQMEwRISVJBMSswKQYJKoZIhvcNAQkBFhxoaXRvc2hpQG9yaS5o
    aXRhY2hpLXNrLmNvLmpwMIHXMIGpBgoqgwiGjScHAQUBMIGaAgEBMCMGCiqDCIaN
    JwcBBgECFQD///////////mvyqjt91qfEHYKrzAsBBQAAAAAAAAAAAAAAAAAAAAA
    AAAAAAQUAAAAAAAAAAAAAAAAAAAAAAAAAMAEKAAAAAAAAAAAAAAAAAAAAAAAAAAE
    AAAAAAAAAAAAAAAAAAAAAAAAABACFQD///////////mvyqjt91qfEHYKrwIBAAMp
    API7g4TgW3RXWs2beo0BFCGHgNaQp//etDYwV9HF3DlMy5u/ZP3CrTmjggFvMIIB
    azAPBgNVHRMBAQAEBTADAQEAMGcGBisGAQUDAgEBAARaMFigK4YpaHR0cDovL3d3
    dy5teWNhLmNvLmpwL2NnaS1iaW4vY2Fsb29rdXByZXGhKYYnaHR0cDovL3d3dy5t
    eWNhLmNvLmpwL2NnaS1iaW4vdmVyaWZ5cmVxMIG0Bgb///////8BAQAEgaYwgaMw
    gYIwLwYDVQQKMSgTJkhpdGFjaGkgU29mdHdhcmUgRW5naW5lZXJpbmcgQ28uLCBM
    dGQuMBMGA1UEBzEMEwpUb3RzdWthLWt1MA0GA1UEDDEGEwRISVJBMCsGCSqGSIb3
    DQEJATEeFhxoaXRvc2hpQG9yaS5oaXRhY2hpLXNrLmNvLmpwFw05NzA5MjUxMDUw
    NDRaFw05NzEwMjUxMDUwNDRaMDgGA1UdHwEBAAQuMCwwKqAooCaGJGh0dHA6Ly93
    d3cubXljYS5jby5qcC9jZ2ktYmluL2NybHJlcTAOBgoqgwiGjScHAQIHBQADTQAp
    EQJUCpr0S23/YhvkPKTVblhX1YQ60/Dy+5xiB9zxvdG6RsCZ9Zd58Eh8HKUSbpnm
    AQFx37tMe5jXXT0VyU4HyIdTh17L2u27uZtp




Sakurai,Kikuchi,Hattori,Sameshima,Kumagai                      [Page 29]


INTERNET-DRAFT                    ICAP                     July 31, 1998


   Connection closed by foreign host.

5.2 lookupreq

5.2.1 lookupreq with e-mail address

5.2.1.1 in case of multiple hits

   Note that the result line is folded in this example.

   % telnet cahost1 80
   Trying 123.16.5.41 ...
   Connected to cahost1.
   Escape character is '^]'.
   POST /cgi-bin/lookupreq HTTP/1.0
   Content-length: 32

   EmailAddress=alpha@abc.nec.co.jp
   HTTP/1.1 200 OK
   Date: Sat, 25 Oct 1997 09:30:01 GMT
   Server: Apache/1.2.1
   Connection: close
   Content-Type: text/plain

   lookupreq
   201 found several certs
   ME8wSjELMAkGA1UEBhMCSlAxGDAWBgNVBAoTD05FQyBDb3Jwb3JhdGlvbjEhMB8GA
   1UECxMYTmV0bGFiIEV4cGVyaW1lbnRhbCAxMDI0AgED:CN=ALPHA Tom,
   EM=alpha@abc.nec.co.jp, rpEM=alpha@abc.nec.co.jp, ou=Internet Div.,
   O=NEC Corporation, C=JP
   ME8wSjELMAkGA1UEBhMCSlAxGDAWBgNVBAoTD05FQyBDb3Jwb3JhdGlvbjEhMB8GA
   1UECxMYTmV0bGFiIEV4cGVyaW1lbnRhbCAxMDI0AgEE:CN=ALPHA Tom, EM=alpha
   @abc.nec.co.jp, rpEM=alpha@abc.nec.co.jp, ou=Internet Div., O=NEC
   Corporation, C=JP
   MFEwSjELMAkGA1UEBhMCSlAxGDAWBgNVBAoTD05FQyBDb3Jwb3JhdGlvbjEhMB8GA
   1UECxMYTmV0bGFiIEV4cGVyaW1lbnRhbCAxMDI0AgMAgAA=:CN=ALPHA Tom, EM=
   alpha@abc.nec.co.jp, rpEM=alpha@abc.nec.co.jp, ou=Internet Div.,
   O=NEC Corporation, C=JP
   MFIwSjELMAkGA1UEBhMCSlAxGDAWBgNVBAoTD05FQyBDb3Jwb3JhdGlvbjEhMB8GA
   1UECxMYTmV0bGFiIEV4cGVyaW1lbnRhbCAxMDI0AgQAgAAA:CN=ALPHA Tom, EM=
   alpha@abc.nec.co.jp, rpEM=alpha@abc.nec.co.jp, ou=Internet Div.,
   O=NEC Corporation, C=JP
   MFMwSjELMAkGA1UEBhMCSlAxGDAWBgNVBAoTD05FQyBDb3Jwb3JhdGlvbjEhMB8GA
   1UECxMYTmV0bGFiIEV4cGVyaW1lbnRhbCAxMDI0AgUAgAAAAA==:CN=ALPHA Tom,
   EM=alpha@abc.nec.co.jp, rpEM=alpha@abc.nec.co.jp, ou=Internet Div.
   , O=NEC Corporation, C=JP

   Connection closed by foreign host.



Sakurai,Kikuchi,Hattori,Sameshima,Kumagai                      [Page 30]


INTERNET-DRAFT                    ICAP                     July 31, 1998


5.2.1.2 in case of using Latest option

   % telnet cahost1 80
   Trying 123.16.5.41 ...
   Connected to cahost1.
   Escape character is '^]'.
   POST /cgi-bin/lookupreq HTTP/1.0
   Content-length: 41

   EmailAddress=alpha@abc.nec.co.jp&Latest=1
   HTTP/1.1 200 OK
   Date: Sat, 25 Oct 1997 09:34:17 GMT
   Server: Apache/1.2.1
   Connection: close
   Content-Type: text/plain

   lookupreq
   200 accept your request
    MIIDmTCCA1qgAwIBAgIFAIAAAAAwDgYKKoMIgZxfCwEEAQUAMEoxCzAJBgNVBAYT
    AkpQMRgwFgYDVQQKEw9ORUMgQ29ycG9yYXRpb24xITAfBgNVBAsTGE5ldGxhYiBF
    eHBlcmltZW50YWwgMTAyNDAeFw05NzEwMjQxMDM0NDdaFw05ODAxMjIxMDM0NDda
    MIGsMQswCQYDVQQGEwJKUDEYMBYGA1UEChMPTkVDIENvcnBvcmF0aW9uMSAwHgYD
    VQQLExdOZXR3b3JraW5nIFN5c3RlbXMgTGFiczEWMBQGA1UECxMNSW50ZXJuZXQg
    RGl2LjESMBAGA1UEAxMJQUxQSEEgVG9tMREwDwYDVQQMEwhFbmdpbmVlcjEiMCAG
    CSqGSIb3DQEJARYTYWxwaGFAYWJjLm5lYy5jby5qcDCB1zCBqQYKKoMIho0nBwEF
    ATCBmgIBATAjBgoqgwiGjScHAQYBAhUA///////////5r8qo7fdanxB2Cq8wLAQU
    AAAAAAAAAAAAAAAAAAAAAAAAAAAEFAAAAAAAAAAAAAAAAAAAAAAAAADABCgAAAAA
    AAAAAAAAAAAAAAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAQAhUA///////////5
    r8qo7fdanxB2Cq8CAQADKQAqhr1NSXL41WmWPilsNHPU7QqkTXou5PE9BggsfFxy
    h4JOt5TS9uU3o4IBRTCCAUEwDwYDVR0TAQEABAUwAwEBADBsBgsqgwiBnF8LAwEd
    AgEBAARaMFigK4YpaHR0cDovL3d3dy5teWNhLmNvLmpwL2NnaS1iaW4vY2Fsb29r
    dXByZXGhKYYnaHR0cDovL3d3dy5teWNhLmNvLmpwL2NnaS1iaW4vdmVyaWZ5cmVx
    MIGFBgsqgwiBnF8LAwEdAQEBAARzMHEwUTAYBgNVBAoxERMPTkVDIENvcnBvcmF0
    aW9uMBEGA1UEDDEKEwhFbmdpbmVlcjAiBgkqhkiG9w0BCQExFRYTYWxwaGFAYWJj
    Lm5lYy5jby5qcBcNOTcxMDI0MTAzNDQ3WhcNOTcxMjIzMTAzNDQ3WjA4BgNVHR8B
    AQAELjAsMCqgKKAmhiRodHRwOi8vd3d3Lm15Y2EuY28uanAvY2dpLWJpbi9jcmxy
    ZXEwDgYKKoMIgZxfCwEEAQUAAykAVKRtTcur9tuvYOQxG2RJtt4ONcCEV/yoPqQo
    jXiDaD6Qg0BkVyELYg==

   Connection closed by foreign host.

5.2.2 lookupreq with Distinguished Name

   % telnet cahost1 80
   Trying 123.16.5.41 ...
   Connected to cahost1.
   Escape character is '^]'.
   POST /cgi-bin/lookupreq HTTP/1.0



Sakurai,Kikuchi,Hattori,Sameshima,Kumagai                      [Page 31]


INTERNET-DRAFT                    ICAP                     July 31, 1998


   Content-length: 18

   c=JP&o=NEC&cn=koji
   HTTP/1.1 200 OK
   Date: Sat, 04 Oct 1997 08:05:32 GMT
   Server: Apache/1.2.1
   Connection: close
   Content-Type: text/plain

   lookupreq
   200 accept your request
    MIIBlTCCAT8CAQQwDQYJKoZIhvcNAQECBQAwZjELMAkGA1UEBhMCSlAxGDAWBgNV
    BAoTD05FQyBDb3Jwb3JhdGlvbjElMCMGA1UECxMcTmV0d29ya2luZyBTeXN0ZW1z
    IExhYnMuIENBNDEWMBQGA1UECxMNaW50ZXJuZXQgZGl2LjAeFw05NzEwMDIxMjIz
    MDZaFw05ODAzMzExMjIzMDZaMHAxCzAJBgNVBAYTAkpQMRgwFgYDVQQKEw9ORUMg
    Q29ycG9yYXRpb24xITAfBgNVBAsTGE5ldHdvcmtpbmcgU3lzdGVtcyBMYWJzLjEO
    MAwGA1UECxMFU291bXUxFDASBgNVBAMTC0tvamkgVGFraWRhMDEwDQYJKoZIhvcN
    AQEBBQADIAAwHQIWABIwmAmAmAm5gICYCYyYCY2YCKCYMAIDAQABMA0GCSqGSIb3
    DQEBAgUAA0EAHuIJIRU70hz/QzEFKOty5a7d7gb6nQ2iyxNUA/ykAyZJPcFPOuCT
    IeaoEKGu7oijoDWCMCyPQied5bi2fEK2UK==

   Connection closed by foreign host.

5.2.3 lookupreq with Issuer and Serial Number

   % telnet cahost1 80
   Trying 123.16.5.41 ...
   Connected to cahost1.
   Escape character is '^]'.
   POST /cgi-bin/lookupreq HTTP/1.0
   Content-length: 158

   IASN=MGswZjELMAkGA1UEBhMCSlAxGDAWBgNVBAoTD05FQyBDb3Jwb3JhdGlvbjElMCMG
    A1UECxMcTmV0d29ya2luZyBTeXN0ZW1zIExhYnMuIENBNDEWMBQGA1UECxMNaW50
    ZXJuZXQgZGl2LgIBBA%3d%3d
   HTTP/1.1 200 OK
   Date: Sat, 04 Oct 1997 08:34:37 GMT
   Server: Apache/1.2.1
   Connection: close
   Content-Type: text/plain

   lookupreq
   200 accept your request
    MIIBlTCCAT8CAQQwDQYJKoZIhvcNAQECBQAwZjELMAkGA1UEBhMCSlAxGDAWBgNV
    BAoTD05FQyBDb3Jwb3JhdGlvbjElMCMGA1UECxMcTmV0d29ya2luZyBTeXN0ZW1z
    IExhYnMuIENBNDEWMBQGA1UECxMNaW50ZXJuZXQgZGl2LjAeFw05NzEwMDIxMjIz
    MDZaFw05ODAzMzExMjIzMDZaMHAxCzAJBgNVBAYTAkpQMRgwFgYDVQQKEw9ORUMg
    Q29ycG9yYXRpb24xITAfBgNVBAsTGE5ldHdvcmtpbmcgU3lzdGVtcyBMYWJzLjEO



Sakurai,Kikuchi,Hattori,Sameshima,Kumagai                      [Page 32]


INTERNET-DRAFT                    ICAP                     July 31, 1998


    MAwGA1UECxMFU291bXUxFDASBgNVBAMTC0tvamkgVGFraWRhMDEwDQYJKoZIhvcN
    AQEBBQADIAAwHQIWABIwmAmAmAm5gICYCYyYCY2YCKCYMAIDAQABMA0GCSqGSIb3
    DQEBAgUAA0EAHuIJIRU70hz/QzEFKOty5a7d7gb6nQ2iyxNUA/ykAyZJPcFPOuCT
    IeaoEKGu7oijoDWCMCyPQied5bi2fEK2UK==

   Connection closed by foreign host.

5.3 calookupreq

   % telnet cahost1 80
   Trying 123.16.5.41 ...
   Connected to cahost1.
   Escape character is '^]'.
   POST /cgi-bin/calookupreq HTTP/1.0
   Content-length: 601

   cert=MIIBqTCCAVMCAQIwDQYJKoZIhvcNAQECBQAwZjELMAkGA1UEBhMCSlAxGDAWBgNV
   BAoTD05FQyBDb3Jwb3JhdGlvbjElMCMGA1UECxMcTmV0d29ya2luZyBTeXN0ZW1z
   IExhYnMuIENBNDEWMBQGA1UECxMNaW50ZXJuZXQgZGl2LjAeFw05NzEwMDIxMDQy
   NDJaFw05ODAzMzExMDQyNDJaMGIxCzAJBgNVBAYTAkpQMRgwFgYDVQQKEw9ORUMg
   Q29ycG9yYXRpb24xITAfBgNVBAsTGE5ldHdvcmtpbmcgU3lzdGVtcyBMYWJzLjEW
   MBQGA1UEAxMNVG9yYSBMdXRyYSgyKTBTMAQGAAUAA0sAMEgCQQCVs6HJAXV0qtMV
   wP89UeMbmHNaVPBi5ceQDJMPxux3JvPxDwQ9bNVo5ZTFp7rvRBQP/KKxpWAPgh0V
   %2blh6IwvLAgMBAAEwDQYJKoZIhvcNAQECBQADQQBxImito7%2b4omMh1TPbhyqZ/ghm
   NUC/GBeZaFN29Wm8rmcgH7RjgrcD9iht3FFTW5Lq8Zw5%2bpEh6bKrFiYbKQsY
   HTTP/1.1 200 OK
   Date: Sat, 04 Oct 1997 08:54:56 GMT
   Server: Apache/1.2.1
   Connection: close
   Content-Type: text/plain

   calookupreq
   200 accept your request
    MIIBtjCCAWACAQAwDQYJKoZIhvcNAQECBQAwZjELMAkGA1UEBhMCSlAxGDAWBgNV
    BAoTD05FQyBDb3Jwb3JhdGlvbjElMCMGA1UECxMcTmV0d29ya2luZyBTeXN0ZW1z
    IExhYnMuIENBNDEWMBQGA1UECxMNaW50ZXJuZXQgZGl2LjAeFw05NzEwMDIxMTIw
    NDJaFw05ODEwMDIxMTIwNDJaMGYxCzAJBgNVBAYTAkpQMRgwFgYDVQQKEw9ORUMg
    Q29ycG9yYXRpb24xJTAjBgNVBAsTHE5ldHdvcmtpbmcgU3lzdGVtcyBMYWJzLiBD
    QTQxFjAUBgNVBAsTDWludGVybmV0IGRpdi4wXDANBgkqhkiG9w0BAQEFAANLADBI
    AkEAgDwky4mQrRadX7WT5AtpV9CFpFk0QhwL43mOwhSnykl5wDksC33KMThg+sBC
    nC3HNl7fb1iB6nYzsJSUirK3+wIDAQABMA0GCSqGSIb3DQEBAgUAA0EAXXGVLbQw
    lJXTLO6iNUzDXpMhN3aUsYc3dHfS0hWXE0s7yKIMxZrqg8Z6WDI4gVAnstLq6YPo
    mgewuYcONPWq6p==

   Connection closed by foreign host.

5.4 crlreq




Sakurai,Kikuchi,Hattori,Sameshima,Kumagai                      [Page 33]


INTERNET-DRAFT                    ICAP                     July 31, 1998


   % telnet cahost1 80
   Trying 123.16.5.41 ...
   Connected to cahost1.
   Escape character is '^]'.
   POST /cgi-bin/crlreq HTTP/1.0
   Content-length: 495

   cert=MIIBYzCCARYCAR4wBAYABQAwTTELMAkGA1UEBhMCSlAxDDAKBgNVBAoTA05FQzEw
   MC4GA1UECxMnTmV0d29ya2luZyBTeXN0ZW1zIExhYnMgRXhwZXJpbWVudGFsIENB
   MB4XDTk3MDcyMjA5NTIxMloXDTk3MTAzMTIzNTk1OVowPjELMAkGA1UEBhMCSlAx
   FTATBgNVBAoTDFdJREUgUHJvamVjdDEYMBYGA1UEAxMPbWluZSBzYWt1cmFpKDMp
   MFwwDQYJKoZIhvcNAQEBBQADSwAwSAJBAJpfMGvJfeRBelpIfdRDj4a9PkGlFMny
   OX78pm8kKkD3pCNdHcMXac%2bAIp8CApA186O40O9Q9QHjftNI5scCs8sCAwEAATAE
   BgAFAANBAGoH44rvFVZf6HdrbCu5est417IStth5ZfL5zZlRZlhxL3GlcEFBuqpI
   xp7QbKOfstV4ppcVIKX48IJcehn4RK9%3d
   HTTP/1.0 200 Document follows
   Date: Sun, 14 Sep 1997 10:13:43 GMT
   Server: NCSA/1.5.1
   Content-type: text/plain

   crlreq
   200 accept your request
    MIHnMIGSMA0GCSqGSIb3DQEBAgUAME0xCzAJBgNVBAYTAkpQMQwwCgYDVQQKEwNO
    RUMxMDAuBgNVBAsTJ05ldHdvcmtpbmcgU3lzdGVtcyBMYWJzIEV4cGVyaW1lbnRh
    bCBDQRcNOTcwNDIyMDc1MzQ5WhcNOTcwNTIyMDc1MzQ5WjAUMBICAQEXDTk3MDQy
    MjA3NTMwMlowDQYJKoZIhvcNAQECBQADQQBKUqMwSBwssoKOACJAN9jY8QvZhKCq
    JFoyIfFyaKgoIOHzCw5LY/MlIPVuSZ4a/mZAP4k89BbLxID26ZpBe8+/

   Connection closed by foreign host.

5.5 verifyreq

   % telnet cahost1 80
   Trying 123.16.5.41 ...
   Connected to cahost1.
   Escape character is '^]'.
   POST /cgi-bin/verifyreq HTTP/1.0
   Content-length: 1200

   resptype=1&cert=MIIDVDCCAxWgAwIBAgIBAjAOBgoqgwiBnF8LAQQBBQAwSjEL
   MAkGA1UEBhMCSlAxGDAWBgNVBAoTD05FQyBDb3Jwb3JhdGlvbjEhMB8GA1UECxMY
   TkVDIEV4cGVyaW1lbnRhbCBDQSAxMjAyMB4XDTk3MTIwMjA4Mjc1OVoXDTk4MDMw
   MjA4Mjc1OVowga8xCzAJBgNVBAYTAkpQMQ4wDAYDVQQIEwVUb2t5bzEMMAoGA1UE
   ERMDMTA4MRgwFgYDVQQKEw9ORUMgQ29ycG9yYXRpb24xGDAWBgNVBAsTD0NvbXB1
   dGVyIENlbnRlcjEVMBMGA1UEAxMMV2Fyd2ljayBNb29uMREwDwYDVQQMEwhFbmdp
   bmVlcjEkMCIGCSqGSIb3DQEJARYVd2Fyd2lja0BhYmMubmVjLmNvLmpwMIHWMIGo
   BgoqgwiGjScHAQUBMIGZAgEBMCMGCiqDCIaNJwcBBgECFQD/////////////////
   ///////4IzAsBBQAAAAAAAAAAAAAAAAAAAAAAAAAAAQUAAAAAAAAAAAAAAAAAAAA



Sakurai,Kikuchi,Hattori,Sameshima,Kumagai                      [Page 34]


INTERNET-DRAFT                    ICAP                     July 31, 1998


   AAAAAAQEKHREkIEzBgj2pQP3jxfqq/HGpF5IjXaPj5/323zM8GqV5jc7d9QTWlIC
   FAaQaQaQaQaQaQaJGF5nDdBMGhjrAgEAAykADlDr4ahA3gN89hnQHQQUGShmZJxe
   FCXBf5qqQhtFszd9scSZyvjrN6OCAQIwgf8wDwYDVR0TAQEABAUwAwEBADAOBgNV
   HQ8BAQAEBAMCAaAwPQYDVR0gAQEABDMwMTAvBgkqgwiBnF8LBAEwIjAgBgYrBgEF
   AwQWFmh0dHA6Ly93d3cuaWNhdC5vci5qcC8wZgYLKoMIgZxfCwMBHQIBAQAEVDBS
   oCiGJmh0dHA6Ly9zcGxzOTU6ODAwMC9jZ2ktYmluL2NhbG9va3VwcmVxoSaGJGh0
   dHA6Ly9zcGxzOTU6ODAwMC9jZ2ktYmluL3ZlcmlmeXJlcTA1BgNVHR8BAQAEKzAp
   MCegJaAjhiFodHRwOi8vc3Bsczk1OjgwMDAvY2dpLWJpbi9jcmxyZXEwDgYKKoMI
   gZxfCwEEAQUAAykATQ4X5uxUoVw0rvgX1G1mygXkNYuZGQM3g18eboLgvFrQo5xA
   AoCDaA%3d%3d
   HTTP/1.1 200 OK
   Date: Wed, 03 Dec 1997 02:39:00 GMT
   Server: Apache/1.2.1
   Connection: close
   Content-Type: text/plain

   verifyreq
   200 valid
   Connection closed by foreign host.

Acknowledgement

   The authors thank Mr. Ohbayashi, Mr. Kitano, Mr. Kobayashi, Mr.
   Kuroda, Mr.Fujimoto, and Mr. Wada for their comments to this
   proposal.  The authors also thank the other researchers joining the
   Initiatives for Computer Authentication Technology (ICAT), and the
   members of WIDE project.

References

   [X.509] ITU-T Recommendation X.509 (1197 E):
          Information Technology - Open Systems Interconnection -
          The Directory: Authentication Framework, June 1997

   [PKIX-PROF] R. Housley, et. al.,
          "Internet Public Key Infrastructure
          X.509 Certificate and CRL Profile,"
          <draft-ietf-pkix-ipki-part1-08.txt>, June 1998

   [PKIX-CMP] C. Adams and S. Farrell,
          Internet Public Key Infrastructure
          Certificate Management Protocols,"
          <draft-ietf-pkix-ipki3cmp-07.txt>, February 1998

   [PKIX-OCSP] C. Adams, et. al.,
          "X.509 Internet Public Key Infrastructure
          Online Certificate Status Protocol - OCSP",
          <draft-ietf-pkix-ocsp-05.txt>, July 1998



Sakurai,Kikuchi,Hattori,Sameshima,Kumagai                      [Page 35]


INTERNET-DRAFT                    ICAP                     July 31, 1998


   [PKIX-OPP] R. Housley,
          "Internet X.509 Public Key Infrastructure
          Operational Protocols: FTP and HTTP",
          <draft-ietf-pkix-opp-ftp-http-03.txt>, April 1998

   [PKIX-LDAP] S. Boeyen, et. al.,
          "Internet X.509 Public Key Infrastructure
          LDAPv2 Schema",
          <draft-ietf-pkix-ldapv2-schema-00.txt>, March 1998

   [HTTP] T. Berners-Lee, R. Fielding, H. Nielsen, "Hypertext Transfer
          Protocol -- HTTP/1.0", RFC 1945, May 1996

   [SSL] http://home.netscape.com/eng/ssl3/draft302.txt, 1997

   [ASN.1] B. Kaliski, "A Layman's Guide to a Subset of ASN.1, BER,
          and DER", ftp://ftp.rsa.com (layman.ps), June 1991

   [Mine] M. Sakurai, et.al., "A Design of Certificate or CRL
          Distribution Architecture between Certification
          Authorities",
          The 1997 Symp. on Cryptography and Information Security
          (SCIS'97), 8D, January 1997

   [RFC1779] S. Kille,
          "A String Representation of Distinguished Names",
          RFC 1779, March 1995

   [PKCS-7] B. Kaliski,
          "PKCS 7: Cryptographic Message Syntax Version 1-5",
          RFC 2315, March 1998

   [PKCS-9] RSA Laboratories,
          "PKCS #9: Selected Attribute Types",
          An RSA Laboatories Technical Note, November 1993

   [PKCS-10] B. Kaliski,
          "PKCS 10: Certification Request Syntax Version 1-5",
          RFC 2314, March 1998

   [RFC2045] N. Freed & N. Borenstein,
          "Multipurpose Internet Mail Extensions (MIME) Part
          One: Format of Internet Message Bodies",
          RFC2045, November 1996

Security Considerations

   This entire memo is about security mechanisms.



Sakurai,Kikuchi,Hattori,Sameshima,Kumagai                      [Page 36]


INTERNET-DRAFT                    ICAP                     July 31, 1998


Author Addresses:

   Mine Sakurai
   NEC Corporation
   Igarashi bldg., 2-11-5 Shibaura, Minato-ku, Tokyo 108-8557, Japan
   m-sakura@ccs.mt.nec.co.jp

   Hiroaki Kikuchi
   Dept. of Electrical Engineering
   Tokai University
   1117 Kitakaname, Hiratsuka, Kanagawa 259-1292, Japan
   kikn@ep.u-tokai.ac.jp

   Hiroyuki Hattori
   Meiji University
   1-1, Kandasurugadai, Chiyoda-ku, Tokyo 101-8301, Japan
   hhat@isc.meiji.ac.jp

   Yoshiki Sameshima
   Initiatives for Computer Authentication Technology
   Information Security Office,
   Japan Information Processing Development Center
   3-5-8 Shiba-Kouen, Minato Ku, 105, Tokyo, Japan

   Hitoshi Kumagai
   Initiatives for Computer Authentication Technology
   Information Security Office,
   Japan Information Processing Development Center
   3-5-8 Shiba-Kouen, Minato Ku, 105, Tokyo, Japan



Appendix:  ICAT-local OIDs

   In our sample implementation, two OIDs are originally defined and
   used. One is "App", and another is "V3Extn".

        ICAT OBJECT IDENTIFIER ::=
        { iso(1) member-body(2) jisc(392) JIPDEC(20063) 11}

        App OBJECT IDENTIFIER ::=
        {ICAT PKI(2) PKCS10(1) 1}

        V3Extn OBJECT IDENTIFIER ::=
        {ICAT PKI(2) PKCS10(1) 2}

   The example of extended PKCS#10 message, encoded in BER, is as
   follows:



Sakurai,Kikuchi,Hattori,Sameshima,Kumagai                      [Page 37]


INTERNET-DRAFT                    ICAP                     July 31, 1998



   30 (739)
       30 (676)
           02 (1) 00
           30 (181)
               31 (11)
                   30 (9)
                       06 (3) 550406
                       13 (2) [JP]
               31 (14)
                   30 (12)
                       06 (3) 550408
                       13 (5) [Tokyo]
               31 (18)
                   30 (16)
                       06 (3) 550407
                       13 (9) [Minato-ku]
               31 (24)
                   30 (22)
                       06 (3) 55040a

                       13 (15) [NEC Corporation]
               31 (24)
                   30 (22)
                       06 (3) 55040b
                       13 (15) [Computer Center]
               31 (20)
                   30 (18)
                       06 (3) 550403
                       13 (11) [Taro Tanaka]
               31 (17)
                   30 (15)
                       06 (3) 55040c
                       13 (8) [Engineer]
               31 (37)
                   30 (35)
                       06 (9) 2a864886f70d010901
                       16 (22) [taro@aaa.bbb.nec.co.jp]
           30 (214)
               30 (168)
                   06 (10) 2a8308868d2707010501
                   30 (153)
                       02 (1) 01
                       30 (35)
                           06 (10) 2a8308868d2707010601
                           02 (21) 00ffffffffffffffffffffffffffffffffff
   fff823
                       30 (44)



Sakurai,Kikuchi,Hattori,Sameshima,Kumagai                      [Page 38]


INTERNET-DRAFT                    ICAP                     July 31, 1998


                           04 (20) 000000000000000000000000000000000000
   0000
                           04 (20) 000000000000000000000000000000000000
   0004
                       04 (40) 74449081330608f6a503f78f17eaabf1c6a45e48
   8d768f8f9ff7db7cccf06a95e6373b77d4135a52
                       02 (20) 0690690690690690690689185e670dd04c1a18eb
                       02 (1) 00
               03 (41) 006d4cf2c4c6ba1c75f4dd6b330dea86f82934b99704937d
   7b85f4a4a6010b539df905329342f10a17
           A0 (268)
               30 (23)
                   06 (9) 2a864886f70d010902
                   31 (10)
                       16 (8) [TESTUSER]
               30 (23)
                   06 (9) 2a864886f70d010907
                   31 (10)
                       13 (8) [TESTPASS]
               30 (21)
                   06 (10) 2a8308819c5f0b020101
                   31 (7)
                       13 (5) [PEPOP]
               30 (192)
                   06 (10) 2a8308819c5f0b020102
                   31 (177)
                       30 (174)
                           30 (15)
                               06 (3) 551d13
                               01 (1) 00
                               04 (5) 3003010100
                           30 (154)
                               06 (11) 2a8308819c5f0b03011d01
                               01 (1) 00
                               04 (135) 30818430643018060355040a3111130
   f4e454320436f72706f726174696f6e300e060355040831071305546f6b796f30110
   60355040c310a1308456e67696e656572302506092a864886f70d010901311816167
   461726f406161612e6262622e6e65632e636f2e6a70170d393730383235303030303
   0305a170d3937313132353030303030305a
       30 (14)
           06 (10) 2a8308819c5f0b010401
           05 (0)
       03 (41) 00fa54b614e767e8a8ccd6c595dae74fce02a25d8faf78bd080c70ca
   85b00b5c0354966f9f02ad2c9a


   Note1: Strings in () are represented in decimal.




Sakurai,Kikuchi,Hattori,Sameshima,Kumagai                      [Page 39]


INTERNET-DRAFT                    ICAP                     July 31, 1998


   Note2: In this example, we use Matsushita's Elliptic Curve
   Cryptosystems, My-Ellty, as public-key algorithm.

















































Sakurai,Kikuchi,Hattori,Sameshima,Kumagai                      [Page 40]