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]