idnits 2.17.1 draft-sakurai-pkix-icap-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 7 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 8 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 1167: '... serialNumber [2] Integer } OPTIONAL,...' RFC 2119 keyword, line 1170: '... revokedReason [5] RevokedReason OPTIONAL,...' RFC 2119 keyword, line 1171: '... revokedOrHoldTime [6] GeneralizedTime OPTIONAL,...' RFC 2119 keyword, line 1172: '... holdExpirationTime [7] GeneralizedTime OPTIONAL,...' RFC 2119 keyword, line 1174: '... CertificationPath OPTIONAL }...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 542 has weird spacing: '...tusCode mean...' == Line 557 has weird spacing: '...tusCode statu...' == Line 641 has weird spacing: '...tusCode mean...' == Line 654 has weird spacing: '...tusCode statu...' == Line 736 has weird spacing: '... in the previ...' == (7 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 31, 1998) is 9401 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'Base64' is mentioned on line 436, but not defined == Missing Reference: 'PA1' is mentioned on line 784, but not defined == Missing Reference: 'PA2' is mentioned on line 784, but not defined -- Looks like a reference, but probably isn't: '0' on line 1163 -- Looks like a reference, but probably isn't: '1' on line 1166 -- Looks like a reference, but probably isn't: '2' on line 1167 -- Looks like a reference, but probably isn't: '3' on line 1168 -- Looks like a reference, but probably isn't: '4' on line 1169 -- Looks like a reference, but probably isn't: '5' on line 1170 -- Looks like a reference, but probably isn't: '6' on line 1171 -- Looks like a reference, but probably isn't: '7' on line 1172 -- Looks like a reference, but probably isn't: '8' on line 1173 == Missing Reference: 'TBD' is mentioned on line 1247, but not defined == Missing Reference: 'JP' is mentioned on line 1744, but not defined == Missing Reference: 'Tokyo' is mentioned on line 1748, but not defined == Missing Reference: 'Minato-ku' is mentioned on line 1752, but not defined == Missing Reference: 'Engineer' is mentioned on line 1769, but not defined == Missing Reference: 'TESTUSER' is mentioned on line 1798, but not defined == Missing Reference: 'TESTPASS' is mentioned on line 1802, but not defined == Missing Reference: 'PEPOP' is mentioned on line 1806, but not defined == Unused Reference: 'RFC2045' is defined on line 1681, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'PKIX-PROF' -- Possible downref: Non-RFC (?) normative reference: ref. 'PKIX-CMP' -- Possible downref: Non-RFC (?) normative reference: ref. 'PKIX-OCSP' -- Possible downref: Non-RFC (?) normative reference: ref. 'PKIX-OPP' -- Possible downref: Non-RFC (?) normative reference: ref. 'PKIX-LDAP' ** Downref: Normative reference to an Informational RFC: RFC 1945 (ref. 'HTTP') -- Possible downref: Non-RFC (?) normative reference: ref. 'SSL' -- Possible downref: Non-RFC (?) normative reference: ref. 'Mine' ** Obsolete normative reference: RFC 1779 (Obsoleted by RFC 2253, RFC 3494) ** Downref: Normative reference to an Informational RFC: RFC 2315 (ref. 'PKCS-7') -- Possible downref: Non-RFC (?) normative reference: ref. 'PKCS-9' ** Obsolete normative reference: RFC 2314 (ref. 'PKCS-10') (Obsoleted by RFC 2986) Summary: 14 errors (**), 0 flaws (~~), 21 warnings (==), 19 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PKIX Working Group M. Sakurai (NEC) 3 INTERNET-DRAFT H. Kikuchi (Tokai Univ) 4 H. Hattori (Meiji Univ) 5 Y. Sameshima (ICAT) 6 H. Kumagai (ICAT) 7 expires in six months July 31, 1998 9 Web-based Integrated CA services Protocol, ICAP 10 12 Status of this Memo 14 This document is an Internet-Draft. Internet-Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its areas, 16 and its working groups. Note that other groups may also distribute 17 working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet- Drafts as reference 22 material or to cite them other than as "work in progress." 24 To view the entire list of current Internet-Drafts, please check the 25 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 26 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 27 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 28 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 30 Abstract 32 This document provides a sub set of specifications how to issue, 33 publish X.509 certificates and certificate revocation lists (CRLs). 34 It also provides the certificate validation service by online. In 35 the proposed specifications, the World Wide Web (WWW) is used for 36 secure distributing certificates across a firewall in both human and 37 machine readable syntax. These specifications define not only the 38 protocols between the PKI clients and a single CA, but also the 39 protocols between the CAs. With the CA-CA communications, the PKI 40 clients can retrieve any certificates and CRLs without specifying the 41 location of the appropriate CA, by only asking to the neighbor CA. 43 Table of Contents 45 1 Introduction ............................................. 3 46 2 Basic Definition, Requirements and Assumptions ........... 4 47 2.1 CA model ............................................... 4 48 2.1.1 Registration Authority ............................... 5 49 2.1.2 Issuing Authority .................................... 5 50 2.1.3 Publishing Authority ................................. 5 51 2.1.4 Validation Authority ................................. 7 52 2.2 Requirement for PKI Application ........................ 8 53 2.3 Requirement for X.509 Version 3 Certificate and Extensions 54 ........................ 8 55 2.4 Requirement for X.509 CRL and Extensions .............. 9 56 3 Protocol Specification ................................... 9 57 3.1 transport protocol ..................................... 10 58 3.2 request format ......................................... 10 59 3.3 response format ........................................ 10 60 3.4 Type of Query .......................................... 11 61 3.5 certificate issuing request type "certreq" ............. 11 62 3.5.1 request .............................................. 11 63 3.5.2 response ............................................. 12 64 3.6 certificate retrieval type "lookupreq" ................. 13 65 3.6.1 "lookupreq" with email address ....................... 14 66 3.6.1.1 request ............................................ 14 67 3.6.1.2 response ........................................... 14 68 3.6.2 "lookupreq" with Distinguished Name .................. 15 69 3.6.2.1 request ............................................ 15 70 3.6.2.2 response ........................................... 16 71 3.6.3 "lookupreq" with Issuer and Serial Number ............ 16 72 3.6.3.1 request ............................................ 17 73 3.6.3.2 response ........................................... 17 74 3.6.4 PA-PA protocol in "lookupreq" ........................ 17 75 3.6.4.1 referral model ..................................... 19 76 3.6.4.2 chaining model ..................................... 20 77 3.7 CA certificate retrieval type "calookupreq" ............ 20 78 3.7.1 request .............................................. 20 79 3.7.2 response ............................................. 21 80 3.7.3 PA-PA protocol in "calookupreq" ...................... 21 81 3.8 CRL retrieval type "crlreq" ............................ 22 82 3.8.1 request .............................................. 22 83 3.8.2 response ............................................. 22 84 3.8.3 PA-PA protocol in "crlreq" ........................... 23 85 3.9 Certificate Verification type "verifyreq" .............. 24 86 3.9.1 request .............................................. 24 87 3.9.2 response ............................................. 24 88 3.9.2.1 the response in resptype "1" (not to be signed) ..... 24 89 3.9.2.2 the response in resptype "2" (to be signed) ......... 25 90 3.9.3 VA-VA protocol in "verifyreq" ........................ 27 91 3.10 certificate update type "updatereq" .................... 27 92 3.11 certificate revocation type "revokereq" ................ 27 93 3.12 Correspondence to preceding PKI draft ................. 28 94 4 Security Considerations .................................. 28 95 4.1 Confidentiality of transaction ......................... 28 96 4.2 Non-Repudiation ........................................ 28 97 4.3 Privacy ................................................ 28 98 5 Examples ................................................. 29 99 5.1 certreq ................................................ 29 100 5.2 lookupreq .............................................. 30 101 5.2.1 lookupreq with e-mail address ......................... 30 102 5.2.1.1 in case of multiple hits ............................ 30 103 5.2.1.2 in case of using Latest option ...................... 31 104 5.2.2 lookupreq with Distinguished Name ..................... 32 105 5.2.3 lookupreq with Issuer and Serial Number ............... 32 106 5.3 calookupreq ............................................ 33 107 5.4 crlreq ................................................. 34 108 5.5 verifyreq .............................................. 34 109 Acknowledgement ............................................. 35 110 References .................................................. 35 111 Security Considerations ..................................... 37 112 Author Addresses ............................................ 37 113 Appendix: ICAT-local OIDs ................................... 37 115 1. Introduction 117 This document defines a Web-based protocol to integrate typical CA 118 services such as certificate issuing request and certificates/CRLs 119 retrieval, based on a practical and compact CA model. In our model, a 120 CA supports: 122 o multiple application-specific certificate profiles 123 o online certificate issuance based on password authentication 124 o certificates and CRLs retrieval using CA-CA communications 126 First, [PKIX-PROF] defines the general X.509 Certificate and CRL 127 profile, and applications compliant to this profile will increase. 128 In fact, the certificate profile tends to be application-specific, 129 for example, a certificate format for S/MIME and one for SSL is 130 different in detail. Therefore it is practical that a CA should 131 support multiple application-specific certificate profiles. In this 132 model, a CA is required to be able to distinguish application types 133 among certificate issuing requests. Then, we define certificate 134 issuing request data including application types. 136 Second, in the practical point of view, determining an appropriate 137 certificate issuing procedure is very important in PKI. Of course, 138 there are several procedures appropriate for each authentication 139 level. A typical procedure is as follows: get a temporary password 140 after an authentication step, create key pairs, and have a 141 certificate issued using the password in online. In the model, CA is 142 required to manage password database, and confirms account and 143 password on each certificate issuing. We define certificate issuing 144 request data including account and password information. 146 Third, to make CA based applications available in the global 147 networks, it is required to retrieve certificates or CRLs not only 148 from local repository but also from other repositories. Furthermore, 149 it is convenient for applications that retrieval is done by throwing 150 only one query to neighbor CA, without specifying each repository 151 corresponding to the issuer CA of the certificate. In this model, a 152 CA is required to manage other CA's repository access point 153 information and communicate each other. We define certificate 154 retrieval protocols on supposition of CA hierarchy. 156 Though the certificate management protocol proposed in [PKIX-CMP] 157 does not specify unique transport protocol, HTTP is assumed in this 158 document. Now, World Wide Web (WWW) is ubiquitous, and almost all 159 internet users can use it even if the site they belong to has a 160 firewall against intruders. The WWW provides some useful facilities 161 for PKI; such as information caching at both proxy servers and client 162 softwares, a secure transport layer service for confidentiality, a 163 request forwarding which can be used for CA-CA communications, and 164 easy manipulating message format. 166 2. Basic Definition, Requirements and Assumptions 168 2.1 CA model 170 +------ CA --------+ +------ CA --------+ 171 +---+ | +----+ +----+ | | +----+ +----+ | 172 | E |---->| | RA | | IA | | | | RA | | IA | | 173 | n | | +----+ +----+ | | +----+ +----+ | 174 | d |--+ | | | | 175 | |==|===== firewall ======= === firewall ======= 176 | E | | | +----+ +----+ | | +----+ +----+ | 177 | n | +->| | VA | | PA |<------------>| PA | | VA | | 178 | t | | +----+ +----+ | | +----+ +----+ | 179 | i | | ^ | | ^ | 180 | t | | | | | | | 181 | y | | +-----------------------------------+ | 182 | | +------------------+ +------------------+ 183 +---+ ^ ^ 184 | | 185 +----------------------------------------------+ 186 | End Entity outside firewall | 187 +----------------------------------------------+ 188 Figure 1: CA model 190 In this model, it is assumed that a CA consists of four authorities: 191 Registration Authority (RA), Issuing Authority (IA), Publishing 192 Authority (PA), and Validation Authority (VA). This document defines 193 a protocol between RA and end entitity, a protocol between PA and end 194 entity, and a protocol between VA and end entity. It also defines 195 PA-PA protocols and a VA-VA protocol. But CA internal protocols, such 196 as RA-IA, IA-PA, or IA-VA is out of scope in this document. 198 The End Entity in the Figure 1 is a PKI application program rather 199 than a user. 201 2.1.1 Registration Authority 203 RA is the authority that confirms if the end entity requesting 204 service such as certificate issuing, revoking, or updating is the 205 real one and then decides to accept the request. For example, RA 206 manages accounts and passwords database. Each account may be bound to 207 a user or another RA. Passwords are desired to be disposable to 208 prevent replay attack. How to distribute these accounts and passwords 209 depends on the security level to be required. 211 If the certificate issuing request is acceptable, it is sent to IA. 212 There may be multiple RAs in a CA. 214 2.1.2 Issuing Authority 216 IA is the authority that issues X.509 certificates conformed to some 217 application-specific certificate profile and also issues X.509 CRLs. 218 IA manages a private key for issuing certificates and CRLs, and 219 certificate profile information. 221 For example, each application-specific certificate profile includes 222 information below: 223 o application type name 224 o public key algorithm 225 o signature algorithm 226 o validity of certificate 227 o X.509 version 228 o mandatory attributes in subject of the certificate 229 o (in case of X.509 version3) extension fields to be used 231 After issuing a certificate, it is sent to PA. After issuing a CRL, 232 it is sent to both PA and VA. Note that the certificate including the 233 public key of IA is so called the "CA certificate". 235 2.1.3 Publishing Authority 236 PA is the authority that stores and distributes X.509 certificates 237 and CRLs, that is, certificates and CRLs repository in PKI model 238 defined in PKIX WG. PA manages certificates and CRLs database. 240 To retrieve certificates or CRLs issued by other CA, PA communicates 241 with other PAs, and PA usually is placed outside organization's 242 firewalls. Proposing web-based protocol enables end entities inside a 243 firewall access to PA outside the firewall with existing web proxy. 245 To communicate with other PAs for certificate retrieval, simple 246 restricted hierarchical certificate infrastructure is assumed. 247 Figure 2 shows an example of hierarchy of PAs, where RootPA has two 248 subordinate PAs, PA1 and PA2, having two certificates Cert1 and 249 Cert2, respectively. Each of PA1 and PA2 has the database which at 250 least consists of three fields; the own administrative realm, the 251 RootPA's realm, and access point to the RootPA. The realm indicates 252 e-mail domains and Distinguished Name patterns in the certificates 253 managed by a PA. On the other hand, the RootPA has the database of 254 the own realm, the subordinate PA's administrative realm and access 255 point to each subordinate PA. 257 If an end entity throws a query to PA2 asking for Cert1 by some e- 258 mail address, PA2 checks its own database and finds the domain of the 259 e-mail address is not included in the own realm. PA2 then forwards 260 the query to the parent PA, RootPA. RootPA checks its own database 261 and finds the domain of the e-mail address in the query is included 262 in the own realm. Next RootPA examines each realm of the two 263 subordinate PAs, PA1 and PA2, and finds the realm of PA1 includes the 264 domain of the e-mail address in the query. After that, there are two 265 methods to get Cert1. One is that RootPA forwards the query to PA1, 266 receives Cert1 from PA1, returns Cert1 to PA2, and PA2 returns Cert1 267 to the end entity. The other is that RootPA just returns the access 268 point of PA1 to PA2, PA2 forwards the query to PA1, PA2 gets Cert1 269 from PA1, and PA2 returns Cert1 to the end entity. Thus the end 270 entity can get Cert1 without knowing the access point to PA1. 271 Section 3.6.4 describes the way the end entity gets Cert1 in detail. 273 +-----+ 274 | | 275 RootPA V | 276 +---+ | 277 +---->| *------+ 278 PA1 | +---+ 279 +---+ | 280 +--------| *-----+ 281 Cert1 | +---+ | 282 +---+ | | 283 | *----+ | 284 +---+ PA2 | 285 Cert2 +---+ | 286 +---+ | *-----+ 287 | *-------------+---+ 288 +---+ 290 Figure 2: Example of PAs hierarchy 292 To communicate with PAs for CRL retrieval, it is assumed that an end 293 entity already has some certificate to be examined and CRL 294 distribution points are included in certificate contents. So, if the 295 end entity throws the query to the PA2 for CRL of PA1 in Figure 2, 296 PA2 gets CRL distribution point from the given certificate, and 297 accesses to the point. In this example, the end entity may directly 298 access to the PA1 to get CRL, but this document provides PA-PA 299 communication for convenience. 301 2.1.4 Validation Authority 303 VA is the authority that decides if a specific certificate is valid 304 or not, similar to the responder supporting Online Certificate Status 305 Protocol (OCSP) [PKIX-OCSP]. VA is useful when it is anticipated that 306 CRL size is too big and each application cannot scan the CRL quickly 307 to examine validity of a certificate. VA has own CA's CRLs but does 308 not have parent CA's CRLs. It is not VAs but end entities that are 309 responsible for confirming hierarchical validation paths. 311 When VA replies to end entity's query without secure transport, it is 312 basically required to sign the reply to prevent forgery. So, VA may 313 have private key. To ask validity of a certificate issued by other 314 CA, VA communicates with other VAs. Considering that a query to VA 315 comes from other VAs or end entities outside organizations, VA is 316 placed outside of a firewall. And considering that a reply should be 317 returned quickly, the private key to sign replies is placed outside 318 of a firewall and used automatically in online. If the private key of 319 VA is same with that of IA, security level of the CA depends on that 320 of VA, no matter how the private key of IA is protected inside a 321 firewall. Then it is preferable that private key of VA is distinct 322 from that of IA. 324 It is assumed that end entity already has some certificate to be 325 examined and VA access points are included in certificate contents. 326 If the end entity throws the query to the neighbor VA, say VA1, to 327 check the validity of certificate issued by other CA, the VA1 gets 328 access point from the given certificate and forwards the query to the 329 access point, VA2. In this case, the end entity has direct access to 330 the VA2, but this document provides such a VA-VA communication for 331 convenience. 333 2.2 Requirement for PKI Application 335 The PKI application typically needs access to CA in the following 336 four cases; 338 1. certificate issuing request. 339 As one of installation steps of application, a new certificate 340 is required to be issued. 342 2. certificate retrieval. 343 For example, a sender of secure message wants to retrieve 344 the recipient's public key with which the message is to be 345 encrypted. Further, the recipient of secure message wants to 346 retrieve certificate of CA which issued the sender's certificate. 348 3. certificate verification. 349 The recipient of secure message checks if the sender's certificate 350 is not revoked by examining the corresponding CRL or asking 351 the CA directly. 353 4. certificate and CRL publication. 354 Soon after a certificate is issued by a CA, the new certificate 355 shall be got access for anybody who wants it. 357 2.3 Requirement for X.509 Version 3 Certificate and Extensions 359 This proposal supposes that subset of X.509 Version 3 is used to form 360 public key certificates. According to [PKIX-PROF], the subject and 361 issuer names in X.509 (Version 1) may be an empty sequence and 362 subjectAltName and issuerAltName extensions (Version 3) shall be 363 specified instead of the field. Even if the subject and issuer names 364 are specified, the subjectAltName shall be given as an identification 365 of certificate retrieval. 367 Most PKI applications require many kinds of information about 368 certificate including policy information, CRL, and VA information. In 369 [PKIX-PROF], several access methods are defined for each kind of 370 information. However, it is not so often case that a certain 371 application has multiple access methods to PKI. Therefore, this 372 document assumes that PKI application has an uniform access method of 373 HTTP for the simplification of PKI protocol. 375 If this proposal is used, a standard certificate must specify 377 - authorityInfoAccess 378 - cRLDistributionPoints 380 shall specify 382 - subjectAltName, 383 - issuerAltName, 385 may specify 387 - authorityKeyIdentifier, 388 - subjectKeyIdentifier, 389 - keyUsage, 390 - privateKeyUsagePeriod, 391 - certificagtePolicies, 392 - basicConstraints, 393 - nameConstraints, 394 - policyConstraints, 395 etc. 397 2.4 Requirement for X.509 CRL and Extensions 399 This proposal supposes that subset of X.509 Version 1 and Version 2 400 are used to form CRL. 402 If the X.509 Version 2 CRL is used, a standard CRL shall specify 404 - reasonCode 406 may specify 408 - CRL Number 409 etc. 411 3. Protocol Specification 413 3.1 transport protocol 414 This proposal assumes that either of a standard HTTP protocol or 415 HTTPS protocol i.e. HTTP/SSL [SSL], is used as transport protocol. 416 Thus, RA, IA, PA, and VA server can be implemented as a standard HTTP 417 server which enables CGI facility. 419 3.2 request format 421 The request is sent with the POST method of the HTTP. Thus, the 422 typical query is formatted as follows: 424 POST /cgi-bin/queryType HTTP/1.0 425 Content-length: xx 427 name1=value1&name2=value2&...&namen=valuen 429 where "queryType" is a type of query, and a pair of "name" and 430 "value" are used to send PKI message. All pairs are encoded according 431 to the rule defined in [HTTP]. 433 (Note1) When the content length is computed, return code is treated 434 as 2 length, which consists of CR and LF. 436 (Note2) When the value is encoded according to Base64 rule [Base64], 437 end entity must substitute "+" code of Base64 with 438 "%2b". And when the end entity sends the request on the 439 telnet protocol, not sending directly from the socket, "=" 440 code of Base64 must be also substituted with "%3d". 442 3.3 response format 444 In the response, text/plain content-type is used and simply formatted 445 as follows: 447 HTTP/1.0 200 OK 448 Date: Wednesday 449 MIME-version: 1.0 450 Content-type: text/plain 452 queryType 453 statusCode statusMessage 454 INFORMATION 456 The "queryType" is the same as the type given in sending request and 457 this shows the first line of response. Second line consists of 458 "statusCode" and "statusMessage". 460 The "statusCode" indicates brief processing status category. The 461 "statusCode" contains three digit codes. With at least one space, 462 the "statusMessage" follows and it contains the description of the 463 "statusCode". "2xx" of "statusCode" indicates successful processing, 464 and "3xx" of "statusCode" indicates error. 466 The "statusMessage" gives some hints on error handling, and it may 467 have several message patterns for a "statusCode". 469 The third line, "INFORMATION" is interpreted in corresponding 470 semantics. The syntax of "INFORMATION" depends on the query type, 471 and will be defined in the later sections. 473 This simple response format is appropriate for application to 474 interpret the response. 476 3.4 Type of Query 478 This document defines the following seven query types. Those names 479 are used as "queryType" value in request and response format. 481 1. certreq 2. lookupreq 3. calookupreq 482 4. crlreq 5. verifyreq 6. updatereq 483 7. revokereq 485 "certreq", "updatereq" and "revokereq" are requests to RA. 486 "lookupreq", "calookupreq", and "crlreq" are requests to PA. And, 487 "verifyreq" is a request to VA. 489 3.5 certificate issuing request type "certreq" 491 Type "certreq" is used for sending certificate issuing request to RA. 493 3.5.1 request 495 The certreq request shall be sent with the following pairs of name 496 and value. 498 name value 499 ---- ----- 500 PKCS10 extended PKCS#10 [PKCS-10] data, Base64 501 encoded 503 The extended PKCS#10 format must include the following fields: 504 o Subject 505 o SubjectPublicKeyInfo 506 o account and password attributes for authentication of the end 507 entity 508 o application type attribute to specify certificate profile 510 The extended PKCS#10 format may include the following field in 511 optional: 512 o extension fields attributes for the X.509 version3 extensions 514 Extension fields attributes may be used if the value of the 515 extension field should be specified by end entity itself, not CA 516 policy. 518 Subject and SubjectPublicKeyInfo conform to standard PKCS#10. The 519 rest four attributes, account, password, application type, and 520 extension fields are defined as follows: 522 Account ::= UnstructuredName 523 - account 524 Password ::= ChallengePassword 525 - password 526 App ::= PrintableString 527 - application type 528 V3Extn ::= Extensions 529 - extension field 531 Note that attribute "UnstructuredName" and "ChallengePassword" are 532 defined in PKCS#9 [PKCS-9]. Extensions are defined in [X.509] or also 533 described in [PKIX-PROF]. Attribute "App" and "V3Extn" are 534 originally defined and Appendix shows our local OID definitions for 535 these two attributes. 537 3.5.2 response 539 The response consists of statusCode, statusMessage and INFORMATION. 540 In "certreq" type, statusCode definition is as follows: 542 statusCode meaning 543 ---------- ----------------------------------------- 544 200 successfully processed 545 301 request is incomplete 546 302 the certificate has already been issued 547 303 request is rejected 548 304 service is not available 549 305 (reserved) 551 If the statusCode is "200", the INFORMATION in response is the issued 552 certificate encoded in Base64 format. Otherwise, INFORMATION is 553 empty. 555 statusMessage is defined as follows: 557 statusCode statusMessage 558 ---------- ------------- 559 200 "accept your request" 561 301 "not PKCS10 format" 563 301 "signature verification failed" 565 301 "missing mandatory field (xxx)" 566 where xxx is a name of missing field. 568 302 "detect duplicated DN" 570 303 "public key algorithm not supported " 572 303 "signature algorithm not supported " 574 303 "extension field (xxx) not supported " 575 where xxx is OID, e.g. "551d11" 577 303 "application (xxx) not supported" 578 where xxx is an application type name, 579 e.g. "smime" 581 303 "authentication failed" 583 303 "can't issue cert anymore" 585 303 "access denied" 587 304 "service not available" 589 3.6 certificate retrieval type "lookupreq" 591 The "lookupreq" type is used for retrieving and searching certificate 592 from PA. 594 Certificate is identified by either of the following name forms; 596 a. email address 597 b. Distinguished Name 598 c. Issuer and Serial Number 600 All name forms must be fully specified because a substring matching 601 rule might violate a privacy issue when the PA is the outside of 602 firewall. 604 The request and response format are described in the next clauses. 606 3.6.1 "lookupreq" with email address 608 3.6.1.1 request 610 The lookup query is sent with the following pairs of name and value. 612 name value 613 ---- ----- 614 EmailAddress e-mail address string 616 TimePeriod (optional) months and years string 617 conforming to the following syntax 618 YYYYMM[HH|HHMM|HHMMSS] 620 Latest (optional) "1" 622 KeyUsage (optional) 623 one of the following strings 624 "digitalSignature","nonRepudiation", 625 "keyEncipherment","dataEncipherment", 626 "keyAgreement",etc. 628 The "EmailAddress" pair is a mandatory for this type of request. 629 "TimePeriod" may be used when the end entity wants some expired or 630 revoked certificates. If "TimePeriod" is not specified, expired or 631 revoked certificates are not searched. "Latest" may be used when the 632 end entity wants the latest certificate even if the multiple 633 certificates are hit. "KeyUsage" may be used if the end entity wants 634 to get some certificate for a specific purpose. 636 3.6.1.2 response 638 The response consists of statusCode, statusMessage and INFORMATION. 639 In "lookupreq" type, statusCode definition is as follows: 641 statusCode meaning 642 ---------- ----------------------------------------- 643 200 successfully processed and uniquely retrieved. 644 201 successfully processed but got multiple hits 645 301 request is incomplete 646 303 request is rejected 647 304 service is not available 649 If the statusCode is "200", the INFORMATION in response format is 650 the certificate encoded in Base64 format. If the statusCode is 651 "201", the INFORMATION in response format is DN lists originally 652 defined in this document. Otherwise, INFORMATION is empty. 654 statusCode statusMessage 655 ---------- ------------- 656 200 "accept your request" 658 201 "found several certs" 660 301 "existed, but revoked" 662 303 "existed, but expired" 664 303 "no match" 666 303 "unknown CA" 668 303 "unknown mail domain" 670 303 "not correct input" 672 303 "hit too many cert" 673 note that it depends on CA policy whether this 674 message is used or not. 676 304 "service not available" 678 DN list syntax is defined as follows: 679 IssuerAndSerialNumberData + ":" + DistinguishedNameData 681 IssuerAndSerialNumberData is IssuerAndSerialNumber data defined in 682 PKCS#7 [PKCS-7], encoded in Base64 format. DistinguishedNameData is a 683 string representation of Distinguished Names defined in [RFC1779]. 685 The DN list example is shown here: 687 MIIDSzCCAw0CAQAwggEZMRAwDgYDVQQGEwcbJEJGfEtcMREwDw:CN=Christian 688 Huitema, O=INRIA, C=FR 690 Note that this is one line. 692 3.6.2 "lookupreq" with Distinguished Name 694 3.6.2.1 request 696 The lookup query is sent with the following pairs of name and value. 698 name value 699 ---- ----- 700 c Country 702 o Organization 704 cn Common name 706 ou1 (optional) Organizational unit 708 ou2 (optional) Organizational unit 2 710 ou3 (optional) Organizational unit 3 712 ou4 (optional) Organizational unit 4 714 sopn (optional) StateOrProvinceName 716 Locality (optional) Locality 718 StrAddr (optional) StreetAddress 720 pcode (optional) postal code 722 phnum (optional) phone number 724 title (optional) title 726 TimePeriod (optional) months and years 727 conforming to the following syntax 728 YYYYMM[HH|HHMM|HHMMSS] 730 The pairs of "c", "o", "cn" are mandatory. When the specification 731 is incomplete, the PA may reject it for privacy issue or accept it as 732 substring matching. 734 3.6.2.2 response 736 The response is same with the one defined in the previous clause 737 3.6.1.2 except that "303 unknown mail domain" is replaced below: 739 statusCode statusMessage 740 ---------- ------------- 741 303 "unknown DN" 743 3.6.3 "lookupreq" with Issuer and Serial Number 745 3.6.3.1 request 746 The lookup query is sent with the following pairs of name and value. 748 name value 749 ---- ----- 750 IASN IssuerAndSerialNumber data defined in 751 PKCS#7 [PKCS-7], encoded in Base64 format 753 3.6.3.2 response 755 The response is same with the one defined in clause 3.6.1.2 except 756 "201" response, because IASN should specify unique certificate. 758 3.6.4 PA-PA protocol in "lookupreq" 760 A PA server may forward a request to another PA server when it does 761 not have sufficient information to response to the request. If a PA 762 which does not support PA-PA protocol should response the statusCode 763 "303" with the statusMessage "unknown CA". 765 Suppose that there are PA1, PA2 and RootPA, and PA1 has a request for 766 retrieving a certificate from PA2. The PA1 and the PA2 does not have 767 their access point but the access point to RootPA. There are two 768 possibilities for PA1 to get access to PA2 (Figure 3). 770 - Model 1. [referral] PA1 sends the request to RootPA (1), which 771 then replies to PA1 with the access point to PA2 (2). 772 PA1 forwards the request to PA2 again (3), and finally PA1 773 gets the information from PA2. 775 - Model 2. [chaining] PA1 sends the request to RootPA (1), which 776 redirects it to PA2 on behalf of PA1 (2). PA2 answers 777 to Root PA (3), which forwards it to PA1 (4). 779 +---->[RootPA] +---->[RootPA](2)---+ 780 | +---(2) | +---(4) <---+ | 781 | |PA2 | | | | 782 | | | | | | 783 (1)| V (1)| V (3)| V 784 [PA1] (3)-----------> [PA2] [PA1] [PA2] 785 <-----------(4) 786 Referral Chaining 788 Figure 3. PA-PA models 790 To implement these two models, each PA must have information about 791 its own realm in order to determine if the "lookupreq" request should 792 be forwarded. Since the request includes an e-mail address or part of 793 a Distinguished Name in a certificate, if the realm is represented 794 with e-mail address domain lists or Distinguished Name patterns, PA 795 can easily decide to answer directly or to forward. 797 Addition to its own realm information, PA1 and PA2 must know the URL 798 of RootPA server to forward the request. In general, there may be 799 multiple root PAs for a PA. RootPA, which does not necessarily 800 correspond to the root of a CA hierarchy, must know the URL of PA1 801 and PA2 as subordinate PAs to forward the request (in the chaining 802 model) or return the location information (in the referral model). 804 In the Figure 3, the depth of the virtual PA hierarchy is only one 805 and there are only a root PA and leaf PAs. However, there could be 806 deeper PA hierarchies and mediate PAs can exist. A mediate PA acts 807 like a router, i.e. it forwards a request to a parent PA or a child 808 PA according to its own realm information. Then each PA must know 809 which topology type it belongs to; top, leaf or mediate. 811 In this example, RootPA manages the database in the following form: 813 Me:TOP:RootPA.lll.or.jp:aaa.bb.co.jp, ccc.bb.co.jp, foo.ff.co.jp, 814 bar.ff.co.jp 815 Child:LEAF:PA1.bb.co.jp:aaa.bb.co.jp, ccc.bb.co.jp 816 Child:LEAF:PA2.ff.co.jp:foo.ff.co.jp, bar.ff.co.jp 818 Each line in the database consists of ":" separated fields. 820 If the first field of each line is "Me", then the line contains the 821 information about the owner PA of the database. If the first field of 822 each line is "Child", then the line contains the information about a 823 child PA for the owner PA of the database. If the first field of 824 each line is "Parent", then the line contains the information about a 825 parent PA for the owner PA of the database. 827 If the second field of each line is "TOP", then the PA is the root in 828 a PA hierarchy. If the second field of each line is "MEDIATE", then 829 the PA is mediate in a PA hierarchy. If the second field of each 830 line is "LEAF", then the PA is a leaf in a PA hierarchy. 832 The third field of each line shows the PA server's name and the 833 fourth field of each line shows a realm with e-mail domain lists, 834 separated with commmas. For simplicity, the DN pattern lists are 835 omitted in this database. 837 In the example above, the first line indicates that RootPA is a TOP 838 in the PA tree, the hostname is "RootPA.lll.or.jp", and the realm 839 includes the four e-mail domains; "aaa.bb.co.jp", "ccc.bb.co.jp", 840 "foo.ff.co.jp" and "bar.ff.co.jp". The next two lines indicates that 841 RootPA has two child PAs, both PAs are a LEAF in the PA tree; one is 842 "PA1.bb.co.jp" and another is "PA2.ff.co.jp". Note that an union of 843 these two child PA realms makes RootPA realm. 845 Similarly, PA1 manages the database in the following form: 847 Me:LEAF:PA1.bb.co.jp:aaa.bb.co.jp, ccc.bb.co.jp 848 Parent:TOP:RootPA.lll.or.jp:aaa.bb.co.jp, ccc.bb.co.jp, foo.ff.co.jp, 849 bar.ff.co.jp 851 In this example, the first line indicates that PA1 is a LEAF in the 852 PA tree, the hostname is "PA1.bb.co.jp", and the realm includes the 853 two e-mail domains; "aaa.bb.co.jp" and "cc.bb.co.jp". The second line 854 indicates that PA1 has a parent PA, named with "RootPA.lll.or.jp", 855 and the parent PA realm includes the four e-mail domains; 856 "aaa.bb.co.jp", "ccc.bb.co.jp", "foo.ff.co.jp" and "bar.ff.co.jp". 858 If the realm of RootPA is changed, the all subordinate PAs, PA1 and 859 PA2 must update the realm field of "Parent" line in the database. To 860 solve this problem, special server such as SecureDNS is required to 861 manage the correspondences between a realm of a PA and an access 862 point to the PA server, such as URL. Thus, each PA can examine the 863 access point to the target PA by asking to the special server instead 864 of RootPA. Even if the topology of the PA tree is changed, only the 865 special server's database is to be updated. 867 3.6.4.1 Referral Model 869 To redirect a request to another PA server, the root PA responds to 870 the requester with the following format. 872 statusCode statusMessage INFORMATION 873 ---------- -------------------- ------------ 874 202 "ask other CA" URL 876 The example of URL is "http://xxx.yy:zz/cgi-bin/lookupreq", which 877 provides information where the query should be sent next. 879 The root PA must respond with either correct PA location or error 880 message to mean that there is no certificate. 882 Each round trip time is short, but the neighbor PA for a requestor 883 has to send the same query to several servers. 885 3.6.4.2 Chaining Model 887 To implement chaining model, the CGI script of the root PA produces 888 an extra CGI message before it responds to the request originator. 890 The request originator, PA1 or PKI application, does not have to send 891 request many times, but have to wait longer time than that of 892 referral model. According to [Mine], the estimated total round trip 893 time is more than that of the referral model. Many requests in a 894 short time makes load of the root PA server heavy. But, if the 895 network speed between PA1 and PA2 is slower than that between PA2 and 896 root PA, chaining model is useful. 898 In our experiment, ten requests a minute makes no significant 899 difference in round trip time between these 2 models. 901 3.7 CA certificate retrieval type "calookupreq" 903 The "calookupreq" type is used for retrieving and searching the CA 904 certificate from PA. 906 3.7.1 request 908 The calookupreq query is sent with the following pairs of name and 909 value. 911 name value 912 ---- ----- 913 cert (optional) certificate encoded in Base64 914 format 916 TimePeriod (optional) months and years string 917 conforming to the following syntax 918 YYYYMM[HH|HHMM|HHMMSS] 920 KeyUsage (optional) 921 one of the following strings 922 "keyCertSign", "cRLSign", etc. 924 All the pairs are optional in "calookupreq". If the "cert" is not 925 specified, it is assumed that the PA is required to response the 926 certificate of own CA. "TimePeriod" may be used when the end entity 927 wants some expired or revoked CA certificates. If "TimePeriod" is not 928 specified, expired or revoked certificates are not searched. 929 "KeyUsage" may be used if the end entity wants to get some CA 930 certificate for a specific purpose. 932 3.7.2 response 934 The response consists of statusCode, statusMessage and INFORMATION. 935 In "calookupreq" type, statusCode definition is as follows: 937 statusCode meaning 938 ---------- ----------------------------------------- 939 200 successfully processed 940 303 request is rejected 941 304 service is not available 943 If the status code is "200", the CA certificate encoded in Base64 944 format is appeared as INFORMATION in response format. Otherwise, 945 INFORMATION field is empty. 947 statusMessage is defined as follows: 949 statusCode statusMessage 950 ---------- ------------- 951 200 "accept your request" 953 303 "not certificate format" 955 303 "unknown CA" 957 303 "the URL not found" 959 303 "AuthorityInfoAccess not included" 961 304 "timeout" 963 304 "service not available" 965 3.7.3 PA-PA protocol in "calookupreq" 967 A PA server may forward a request to another PA server when it does 968 not have sufficient information to response to the request. If a PA 969 which does not support PA-PA protocol should response the statusCode 970 "303" with the statusMessage "unknown CA". 972 Suppose that there are PA1 corresponding to CA1, and PA2 973 corresponding to CA2, and PA1 has a request for CA2 certificate from 974 PA2. PA1 gets the URL to PA2 from the AuthorityInfoAccess field in 975 the certificate which PA1 received from the requester. Then PA1 976 forwards the request to PA2, receiving the response from PA2, and 977 returns the response to the requester. 979 3.8 CRL retrieval type "crlreq" 981 The "crlreq" type is used for retrieving a CRL from PA. 983 3.8.1 request 985 The crlreq query is sent with the following pairs of name and value. 987 name value 988 ---- ----- 989 cert (optional) certificate encoded in Base64 990 format 992 reason (optional) specifying CRL reason code 993 one of the following strings 994 "keyCompromise","cACompromise", 995 "affiliationChanged","superseded", 996 "cessationOfOperation", "certificateHold", 997 etc. 999 All the pairs are optional in crlreq. If the "cert" is not 1000 specified, it is assumed that the PA is required to response the CRL 1001 of own CA. The "reason" may be used when the end entity wants some 1002 reason-specific CRL. 1004 3.8.2 response 1006 The response consists of statusCode, statusMessage and INFORMATION. 1007 In "crlreq" type, statusCode definition is as follows: 1009 statusCode meaning 1010 ---------- ----------------------------------------- 1011 200 successfully processed 1012 201 successfully processed, but CRL doesn't exist 1013 202 successfully processed, but multiple CRLs exist 1014 303 request is rejected 1015 304 service is not available 1017 If the status code is "200", INFORMATION in response format is the 1018 CRL encoded in Base64 format. If the status code is "202", 1019 INFORMATION in response format is the reason list strings which shows 1020 the CRLreasoncode of each CRL, so that the end entity could specify 1021 the "reason" in the next request. Otherwise, INFORMATION in response 1022 format is empty. 1024 The reason list is defined as comma separated strings. Each string is 1025 the same with "reason" value in the request. The order is not 1026 considered. 1028 ["keyCompromise"][,]["caCompromise"][,]["affiliationChanged"][,] 1029 ["superseded"][,]["cessationOfOperation"][,]["certificateHold"] 1031 The statusMessage is defined as follows: 1033 statusCode statusMessage 1034 ---------- ------------------------------ 1035 200 "accept your request" 1037 201 "not issued" 1039 202 "specify CRL reason" 1041 303 "not certificate format" 1043 303 "unknown CA" 1045 303 "CRLDistributionPoints not included" 1047 303 "the URL not found" 1049 304 "timeout" 1051 304 "service not available" 1053 3.8.3 PA-PA protocol in "crlreq" 1055 A PA server may forward a request to other PA server when it does not 1056 have sufficient information to response to the request. If a PA which 1057 does not support PA-PA protocol should response the statusCode "303" 1058 with the statusMessage "unknown CA". 1060 Suppose that there are PA1 corresponding to CA1, and PA2 1061 corresponding to CA2, and PA1 has a request for CA2 CRL from PA2. PA1 1062 gets the URL to PA2 from the cRLDistributionPoints field in the 1063 certificate which PA1 received from the requester. Then PA1 forwards 1064 the request to PA2, receiving a response from PA2, and returns the 1065 response to the requester. 1067 3.9 Certificate Verification type "verifyreq" 1069 The "verifyreq" type is used for validation check of certificate. 1071 This document does not support path validation. 1073 3.9.1 request 1075 The verifyreq request shall be sent with the following pairs of name 1076 and value. 1078 name value 1079 ---- ----- 1080 cert certificate encoded in Base64 format 1082 resptype response type string, "1" or "2" 1083 "1" requires the response not to be signed, 1084 "2" requires the response to be signed. 1086 All these pairs are mandatory in verifyreq. The "resptype" is used 1087 for specifying whether the response is required to be signed ("2") or 1088 not ("1"). The end entity should decide the response type depending 1089 on the transport or network environment. 1091 The response is defined separately according to the "resptype". 1093 3.9.2 response 1095 3.9.2.1 the response in resptype "1" (not to be signed) 1097 The response consists of statusCode, statusMessage and INFORMATION. 1098 The statusCode definition is as follows: 1100 statusCode meaning 1101 ---------- ----------------------------------------- 1102 200 successfully processed and valid 1103 201 successfully processed and invalid 1104 202 successfully processed and revoked 1105 203 successfully processed and expired 1106 204 successfully processed and hold 1107 303 request is rejected 1108 304 service is not available 1110 If the statusCode is "202", the INFORMATION in the response format is 1111 the UTCtime string of revoked time. Otherwise, the INFORMATION in the 1112 response format is empty. 1114 The statusMessage is defined as follows: 1116 statusCode statusMessage 1117 ---------- ------------------------------ 1118 200 "valid" 1120 201 "invalid" 1122 202 "revoked" 1124 203 "expired" 1126 204 "hold" 1128 303 "not certificate format" 1130 303 "the URL not found" 1132 303 "unknown response type" 1134 303 "unknown CA" 1136 303 "AuthorityInfoAccess not included" 1138 303 "signature verification failed" 1140 304 "timeout" 1142 304 "service not available" 1144 3.9.2.2 the response in resptype "2" (to be signed) 1146 The response consists of statusCode, statusMessage and INFORMATION. 1147 The statusCode definition is as follows: 1149 statusCode meaning 1150 ---------- ----------------------------------------- 1151 200 successfully processed 1152 303 request is rejected 1153 304 service is not available 1155 If the statusCode is "200", the INFORMATION in the response format is 1156 the digitally signed verification result defined originally in ASN.1, 1157 encoded in Base64 format. Otherwise, the INFORMATION in the response 1158 format is empty. 1160 The signed verification result format is defined as follows: 1162 Reply ::= SEQUENCE { SIGNED SET { 1163 version [0] INTEGER default 0, 1164 SEQUENCE { 1166 issuer [1] Name, 1167 serialNumber [2] Integer } OPTIONAL, 1168 verificationResult [3] VerificationResult, 1169 validationTime [4] GeneralizedTime 1170 revokedReason [5] RevokedReason OPTIONAL, 1171 revokedOrHoldTime [6] GeneralizedTime OPTIONAL, 1172 holdExpirationTime [7] GeneralizedTime OPTIONAL, 1173 holdInstructionCode [8] OBJECT IDENTIFIER OPTIONAL} 1174 CertificationPath OPTIONAL } 1176 VerificationResult ::= ENUMERATE { 1177 notRevoked(0), revoked(1), expired(2), hold(3) } 1179 RevokedReason ::= ENUMERATE { 1180 unspecified (0), 1181 keyCompromise (1), 1182 caCompromise (2), 1183 affiliationChanged (3), 1184 superseded (4), 1185 cessationOfOperation (5) } 1187 holdInstructionCode ::= OBJECT IDENTIFIER 1189 holdInstruction OBJECT IDENTIFIER ::= 1190 { iso(1) member-body(2) us(840) x9-57(10040) 2 } 1192 id-holdinstruction-none OBJECT IDENTIFIER ::= 1193 {holdInstruction 1} 1194 id-holdinstruction-callissuer 1195 OBJECT IDENTIFIER ::= 1196 {holdInstruction 2} 1197 id-holdinstruction-reject OBJECT IDENTIFIER ::= 1198 {holdInstruction 3} 1200 The statusMessage is defined as follows: 1202 statusCode statusMessage 1203 ---------- ------------------------------ 1204 200 "accept your request" 1206 303 "not certificate format" 1208 303 "the URL not found" 1210 303 "unknown response type" 1212 303 "unknown CA" 1213 303 "AuthorityInfoAccess not included" 1215 304 "timeout" 1217 304 "service not available" 1219 3.9.3 VA-VA protocol in "verifyreq" 1221 A VA server may forward a request to other VA server when it does not 1222 have sufficient information to response to the request. If a VA which 1223 does not support VA-VA protocol should response the statusCode "303" 1224 with the statusMessage "unknown CA". 1226 Suppose that there are VA1 corresponding to CA1, and VA2 1227 corresponding to CA2, and VA1 has a request for CA2 CRL from VA2. VA1 1228 gets the URL to VA2 from the authorityInfoAccess field in the 1229 certificate which VA1 received 1230 from the requester. Then VA1 forwards the request to VA2, receiving 1231 a response from VA2, and returns the response to the requester. 1233 3.10 certificate update type "updatereq" 1235 The "updatereq" is a request to update a certificate. 1237 [TBD] 1239 3.11 certificate revocation type "revokereq" 1241 The "revokereq" is a request to revoke a certificate. To prevent 1242 malicious PKI user from revoking other's certificate, this request 1243 should be sent with a proof of possession of the secret key. The 1244 simplest way is to use conventional application that supports digital 1245 signature. 1247 [TBD] 1249 3.12 Correspondence to preceding PKI draft 1251 This document corresponds to PKI management protocol defined in 1252 [PKIX-CMP],[PKIX-OCSP],[PKIX-OPP],[PKIX-LDAP]. Table 1 shows the 1253 correspondence. 1255 Table 1. Correspondence of methods 1257 ICAP method PKI method 1258 ----------- ---------- 1259 certreq CMP(PKCS #10 Cert. Req), WebCAP(MKCERT) 1260 lookupreq OPP(FTP and HTTP),OPP(LDAP), WebCAP(GETCERT) 1261 calookupreq OPP(LDAP) 1262 crlreq OPP(LDAP), WebCAP(GETCERT) 1263 verifyreq OCSP, WebCAP(VRFYCERT) 1264 revokereq CMP(Revocation Request), WebCAP(RMCERT) 1265 updatereq 1267 4. Security Considerations 1269 4.1 Confidentiality of transaction 1271 To prevent message from being eavesdropped, secure communication 1272 channel such as SSL(TLS) shall be used. Especially, initial 1273 registration process is critical to eavesdropping. Since user 1274 authentication is checked with account and password, a client 1275 software is not required to have its own certificate. Under this 1276 assumption, PKI message protection proposed in [PKIX-CMP] need not 1277 here. 1279 4.2 Non-Repudiation 1281 The verifyreq supports the time to be checked and digitally signed 1282 response. This can avoid a message sender from denying the message. 1283 To enable this service, any PA must manage all certificates which it 1284 has already been issued, including revoked certificates. 1286 4.3 Privacy 1288 In the lookupreq, the support of substring matching facility may 1289 distribute private information to outsiders, and thereby may be used 1290 for sending an advertisement via email. 1292 5. Examples 1294 5.1 certreq 1296 %telnet cahost1 80 1297 Trying 123.16.5.41 ... 1298 Connected to cahost1. 1299 Escape character is '^]'. 1300 POST /cgi-bin/certreq HTTP/1.0 1301 Content-length: 1137 1303 PKCS10=MIIDPzCCAwYCAQAwggEUMQswCQYDVQQGEwJKUDERMA8GA1UECBMIWW9rb2hh 1304 bWExEzARBgNVBAcTClRvdHN1a2Eta3UxFDASBgNVBAkTC1RvdHN1a2EtY2hvMS8wLQY 1305 DVQQKEyZIaXRhY2hpIFNvZnR3YXJlIEVuZ2luZWVyaW5nIENvLiwgTHRkLjEbMBkGA1 1306 UECxMSRGF0YSBDb21tdW5pY2F0aW9uMQ0wCwYDVQQMEwRISVJBMQwwCgYDVQQREwMyN 1307 DQxFTATBgNVBBQTDDAxMjAtNDY4ODEyMTEYMBYGA1UEAxMPSGl0b3NoaSBLdW1hZ2Fp 1308 MSswKQYJKoZIhvcNAQkBExxoaXRvc2hpQG9yaS5oaXRhY2hpLXNrLmNvLmpwMIHXMIG 1309 pBgoqgwiGjScHAQUBMIGaAgEBMCMGCiqDCIaNJwcBBgECFQD///////////mvyqjt91 1310 qfEHYKrzAsBBQAAAAAAAAAAAAAAAAAAAAAAAAAAAQUAAAAAAAAAAAAAAAAAAAAAAAAA 1311 MAEKAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAABACFQD///// 1312 //////mvyqjt91qfEHYKrwIBAAMpAPI7g4TgW3RXWs2beo0BFCGHgNaQp//etDYwV9H 1313 F3DlMy5u/ZP3CrTmgggENMBQGCSqGSIb3DQEJAjEHFgVTTUlNRTAUBgkqhkiG9w0BCQ 1314 cxBxMFU01JTUUwFAYJqqqqqqqqqqqqMQcTBVBFUE9QMIHIBgm7u7u7u7u7u7sxgbowg 1315 bcwgbQGBv///////wEBAASBpjCBozCBgjAvBgNVBAoxKBMmSGl0YWNoaSBTb2Z0d2Fy 1316 ZSBFbmdpbmVlcmluZyBDby4sIEx0ZC4wEwYDVQQHMQwTClRvdHN1a2Eta3UwDQYDVQQ 1317 MMQYTBEhJUkEwKwYJKoZIhvcNAQkBMR4WHGhpdG9zaGlAb3JpLmhpdGFjaGktc2suY2 1318 8uanAXDTAwMDAwMDAwMDAwMFoXDTAwMDAwMDAwMDAwMFowCQYF/////wQFAAMokGUe2 1319 gyH92D5W7J/ms8119ibcQlXXU54Rtne9GEh15462oYwqnAraw%3d%3d 1321 HTTP/1.0 200 Document follows 1322 Date: Thu, 25 Sep 1997 10:50:46 GMT 1323 Server: NCSA/1.5.1 1324 Content-type: text/plain 1326 certreq 1327 200 accept your request 1328 MIIENzCCA9SgAwIBAgIBJjAOBgoqgwiGjScHAQIHBQAwTTELMAkGA1UEBhMCSlAx 1329 DDAKBgNVBAoTA05FQzEwMC4GA1UECxMnTmV0d29ya2luZyBTeXN0ZW1zIExhYnMg 1330 RXhwZXJpbWVudGFsIENBMB4XDTk3MDkyNTEwNTA0NFoXDTk3MTIyNDEwNTA0NFow 1331 gf0xCzAJBgNVBAYTAkpQMREwDwYDVQQIEwhZb2tvaGFtYTETMBEGA1UEBxMKVG90 1332 c3VrYS1rdTEUMBIGA1UECRMLVG90c3VrYS1jaG8xDDAKBgNVBBETAzI0NDEvMC0G 1333 A1UEChMmSGl0YWNoaSBTb2Z0d2FyZSBFbmdpbmVlcmluZyBDby4sIEx0ZC4xGzAZ 1334 BgNVBAsTEkRhdGEgQ29tbXVuaWNhdGlvbjEYMBYGA1UEAxMPSGl0b3NoaSBLdW1h 1335 Z2FpMQ0wCwYDVQQMEwRISVJBMSswKQYJKoZIhvcNAQkBFhxoaXRvc2hpQG9yaS5o 1336 aXRhY2hpLXNrLmNvLmpwMIHXMIGpBgoqgwiGjScHAQUBMIGaAgEBMCMGCiqDCIaN 1337 JwcBBgECFQD///////////mvyqjt91qfEHYKrzAsBBQAAAAAAAAAAAAAAAAAAAAA 1338 AAAAAAQUAAAAAAAAAAAAAAAAAAAAAAAAAMAEKAAAAAAAAAAAAAAAAAAAAAAAAAAE 1339 AAAAAAAAAAAAAAAAAAAAAAAAABACFQD///////////mvyqjt91qfEHYKrwIBAAMp 1340 API7g4TgW3RXWs2beo0BFCGHgNaQp//etDYwV9HF3DlMy5u/ZP3CrTmjggFvMIIB 1341 azAPBgNVHRMBAQAEBTADAQEAMGcGBisGAQUDAgEBAARaMFigK4YpaHR0cDovL3d3 1342 dy5teWNhLmNvLmpwL2NnaS1iaW4vY2Fsb29rdXByZXGhKYYnaHR0cDovL3d3dy5t 1343 eWNhLmNvLmpwL2NnaS1iaW4vdmVyaWZ5cmVxMIG0Bgb///////8BAQAEgaYwgaMw 1344 gYIwLwYDVQQKMSgTJkhpdGFjaGkgU29mdHdhcmUgRW5naW5lZXJpbmcgQ28uLCBM 1345 dGQuMBMGA1UEBzEMEwpUb3RzdWthLWt1MA0GA1UEDDEGEwRISVJBMCsGCSqGSIb3 1346 DQEJATEeFhxoaXRvc2hpQG9yaS5oaXRhY2hpLXNrLmNvLmpwFw05NzA5MjUxMDUw 1347 NDRaFw05NzEwMjUxMDUwNDRaMDgGA1UdHwEBAAQuMCwwKqAooCaGJGh0dHA6Ly93 1348 d3cubXljYS5jby5qcC9jZ2ktYmluL2NybHJlcTAOBgoqgwiGjScHAQIHBQADTQAp 1349 EQJUCpr0S23/YhvkPKTVblhX1YQ60/Dy+5xiB9zxvdG6RsCZ9Zd58Eh8HKUSbpnm 1350 AQFx37tMe5jXXT0VyU4HyIdTh17L2u27uZtp 1352 Connection closed by foreign host. 1354 5.2 lookupreq 1356 5.2.1 lookupreq with e-mail address 1358 5.2.1.1 in case of multiple hits 1360 Note that the result line is folded in this example. 1362 % telnet cahost1 80 1363 Trying 123.16.5.41 ... 1364 Connected to cahost1. 1365 Escape character is '^]'. 1366 POST /cgi-bin/lookupreq HTTP/1.0 1367 Content-length: 32 1369 EmailAddress=alpha@abc.nec.co.jp 1370 HTTP/1.1 200 OK 1371 Date: Sat, 25 Oct 1997 09:30:01 GMT 1372 Server: Apache/1.2.1 1373 Connection: close 1374 Content-Type: text/plain 1376 lookupreq 1377 201 found several certs 1378 ME8wSjELMAkGA1UEBhMCSlAxGDAWBgNVBAoTD05FQyBDb3Jwb3JhdGlvbjEhMB8GA 1379 1UECxMYTmV0bGFiIEV4cGVyaW1lbnRhbCAxMDI0AgED:CN=ALPHA Tom, 1380 EM=alpha@abc.nec.co.jp, rpEM=alpha@abc.nec.co.jp, ou=Internet Div., 1381 O=NEC Corporation, C=JP 1382 ME8wSjELMAkGA1UEBhMCSlAxGDAWBgNVBAoTD05FQyBDb3Jwb3JhdGlvbjEhMB8GA 1383 1UECxMYTmV0bGFiIEV4cGVyaW1lbnRhbCAxMDI0AgEE:CN=ALPHA Tom, EM=alpha 1384 @abc.nec.co.jp, rpEM=alpha@abc.nec.co.jp, ou=Internet Div., O=NEC 1385 Corporation, C=JP 1386 MFEwSjELMAkGA1UEBhMCSlAxGDAWBgNVBAoTD05FQyBDb3Jwb3JhdGlvbjEhMB8GA 1387 1UECxMYTmV0bGFiIEV4cGVyaW1lbnRhbCAxMDI0AgMAgAA=:CN=ALPHA Tom, EM= 1388 alpha@abc.nec.co.jp, rpEM=alpha@abc.nec.co.jp, ou=Internet Div., 1389 O=NEC Corporation, C=JP 1390 MFIwSjELMAkGA1UEBhMCSlAxGDAWBgNVBAoTD05FQyBDb3Jwb3JhdGlvbjEhMB8GA 1391 1UECxMYTmV0bGFiIEV4cGVyaW1lbnRhbCAxMDI0AgQAgAAA:CN=ALPHA Tom, EM= 1392 alpha@abc.nec.co.jp, rpEM=alpha@abc.nec.co.jp, ou=Internet Div., 1393 O=NEC Corporation, C=JP 1394 MFMwSjELMAkGA1UEBhMCSlAxGDAWBgNVBAoTD05FQyBDb3Jwb3JhdGlvbjEhMB8GA 1395 1UECxMYTmV0bGFiIEV4cGVyaW1lbnRhbCAxMDI0AgUAgAAAAA==:CN=ALPHA Tom, 1396 EM=alpha@abc.nec.co.jp, rpEM=alpha@abc.nec.co.jp, ou=Internet Div. 1397 , O=NEC Corporation, C=JP 1399 Connection closed by foreign host. 1401 5.2.1.2 in case of using Latest option 1403 % telnet cahost1 80 1404 Trying 123.16.5.41 ... 1405 Connected to cahost1. 1406 Escape character is '^]'. 1407 POST /cgi-bin/lookupreq HTTP/1.0 1408 Content-length: 41 1410 EmailAddress=alpha@abc.nec.co.jp&Latest=1 1411 HTTP/1.1 200 OK 1412 Date: Sat, 25 Oct 1997 09:34:17 GMT 1413 Server: Apache/1.2.1 1414 Connection: close 1415 Content-Type: text/plain 1417 lookupreq 1418 200 accept your request 1419 MIIDmTCCA1qgAwIBAgIFAIAAAAAwDgYKKoMIgZxfCwEEAQUAMEoxCzAJBgNVBAYT 1420 AkpQMRgwFgYDVQQKEw9ORUMgQ29ycG9yYXRpb24xITAfBgNVBAsTGE5ldGxhYiBF 1421 eHBlcmltZW50YWwgMTAyNDAeFw05NzEwMjQxMDM0NDdaFw05ODAxMjIxMDM0NDda 1422 MIGsMQswCQYDVQQGEwJKUDEYMBYGA1UEChMPTkVDIENvcnBvcmF0aW9uMSAwHgYD 1423 VQQLExdOZXR3b3JraW5nIFN5c3RlbXMgTGFiczEWMBQGA1UECxMNSW50ZXJuZXQg 1424 RGl2LjESMBAGA1UEAxMJQUxQSEEgVG9tMREwDwYDVQQMEwhFbmdpbmVlcjEiMCAG 1425 CSqGSIb3DQEJARYTYWxwaGFAYWJjLm5lYy5jby5qcDCB1zCBqQYKKoMIho0nBwEF 1426 ATCBmgIBATAjBgoqgwiGjScHAQYBAhUA///////////5r8qo7fdanxB2Cq8wLAQU 1427 AAAAAAAAAAAAAAAAAAAAAAAAAAAEFAAAAAAAAAAAAAAAAAAAAAAAAADABCgAAAAA 1428 AAAAAAAAAAAAAAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAQAhUA///////////5 1429 r8qo7fdanxB2Cq8CAQADKQAqhr1NSXL41WmWPilsNHPU7QqkTXou5PE9BggsfFxy 1430 h4JOt5TS9uU3o4IBRTCCAUEwDwYDVR0TAQEABAUwAwEBADBsBgsqgwiBnF8LAwEd 1431 AgEBAARaMFigK4YpaHR0cDovL3d3dy5teWNhLmNvLmpwL2NnaS1iaW4vY2Fsb29r 1432 dXByZXGhKYYnaHR0cDovL3d3dy5teWNhLmNvLmpwL2NnaS1iaW4vdmVyaWZ5cmVx 1433 MIGFBgsqgwiBnF8LAwEdAQEBAARzMHEwUTAYBgNVBAoxERMPTkVDIENvcnBvcmF0 1434 aW9uMBEGA1UEDDEKEwhFbmdpbmVlcjAiBgkqhkiG9w0BCQExFRYTYWxwaGFAYWJj 1435 Lm5lYy5jby5qcBcNOTcxMDI0MTAzNDQ3WhcNOTcxMjIzMTAzNDQ3WjA4BgNVHR8B 1436 AQAELjAsMCqgKKAmhiRodHRwOi8vd3d3Lm15Y2EuY28uanAvY2dpLWJpbi9jcmxy 1437 ZXEwDgYKKoMIgZxfCwEEAQUAAykAVKRtTcur9tuvYOQxG2RJtt4ONcCEV/yoPqQo 1438 jXiDaD6Qg0BkVyELYg== 1440 Connection closed by foreign host. 1442 5.2.2 lookupreq with Distinguished Name 1444 % telnet cahost1 80 1445 Trying 123.16.5.41 ... 1446 Connected to cahost1. 1447 Escape character is '^]'. 1448 POST /cgi-bin/lookupreq HTTP/1.0 1449 Content-length: 18 1451 c=JP&o=NEC&cn=koji 1452 HTTP/1.1 200 OK 1453 Date: Sat, 04 Oct 1997 08:05:32 GMT 1454 Server: Apache/1.2.1 1455 Connection: close 1456 Content-Type: text/plain 1458 lookupreq 1459 200 accept your request 1460 MIIBlTCCAT8CAQQwDQYJKoZIhvcNAQECBQAwZjELMAkGA1UEBhMCSlAxGDAWBgNV 1461 BAoTD05FQyBDb3Jwb3JhdGlvbjElMCMGA1UECxMcTmV0d29ya2luZyBTeXN0ZW1z 1462 IExhYnMuIENBNDEWMBQGA1UECxMNaW50ZXJuZXQgZGl2LjAeFw05NzEwMDIxMjIz 1463 MDZaFw05ODAzMzExMjIzMDZaMHAxCzAJBgNVBAYTAkpQMRgwFgYDVQQKEw9ORUMg 1464 Q29ycG9yYXRpb24xITAfBgNVBAsTGE5ldHdvcmtpbmcgU3lzdGVtcyBMYWJzLjEO 1465 MAwGA1UECxMFU291bXUxFDASBgNVBAMTC0tvamkgVGFraWRhMDEwDQYJKoZIhvcN 1466 AQEBBQADIAAwHQIWABIwmAmAmAm5gICYCYyYCY2YCKCYMAIDAQABMA0GCSqGSIb3 1467 DQEBAgUAA0EAHuIJIRU70hz/QzEFKOty5a7d7gb6nQ2iyxNUA/ykAyZJPcFPOuCT 1468 IeaoEKGu7oijoDWCMCyPQied5bi2fEK2UK== 1470 Connection closed by foreign host. 1472 5.2.3 lookupreq with Issuer and Serial Number 1474 % telnet cahost1 80 1475 Trying 123.16.5.41 ... 1476 Connected to cahost1. 1477 Escape character is '^]'. 1478 POST /cgi-bin/lookupreq HTTP/1.0 1479 Content-length: 158 1481 IASN=MGswZjELMAkGA1UEBhMCSlAxGDAWBgNVBAoTD05FQyBDb3Jwb3JhdGlvbjElMCMG 1482 A1UECxMcTmV0d29ya2luZyBTeXN0ZW1zIExhYnMuIENBNDEWMBQGA1UECxMNaW50 1483 ZXJuZXQgZGl2LgIBBA%3d%3d 1484 HTTP/1.1 200 OK 1485 Date: Sat, 04 Oct 1997 08:34:37 GMT 1486 Server: Apache/1.2.1 1487 Connection: close 1488 Content-Type: text/plain 1490 lookupreq 1491 200 accept your request 1492 MIIBlTCCAT8CAQQwDQYJKoZIhvcNAQECBQAwZjELMAkGA1UEBhMCSlAxGDAWBgNV 1493 BAoTD05FQyBDb3Jwb3JhdGlvbjElMCMGA1UECxMcTmV0d29ya2luZyBTeXN0ZW1z 1494 IExhYnMuIENBNDEWMBQGA1UECxMNaW50ZXJuZXQgZGl2LjAeFw05NzEwMDIxMjIz 1495 MDZaFw05ODAzMzExMjIzMDZaMHAxCzAJBgNVBAYTAkpQMRgwFgYDVQQKEw9ORUMg 1496 Q29ycG9yYXRpb24xITAfBgNVBAsTGE5ldHdvcmtpbmcgU3lzdGVtcyBMYWJzLjEO 1497 MAwGA1UECxMFU291bXUxFDASBgNVBAMTC0tvamkgVGFraWRhMDEwDQYJKoZIhvcN 1498 AQEBBQADIAAwHQIWABIwmAmAmAm5gICYCYyYCY2YCKCYMAIDAQABMA0GCSqGSIb3 1499 DQEBAgUAA0EAHuIJIRU70hz/QzEFKOty5a7d7gb6nQ2iyxNUA/ykAyZJPcFPOuCT 1500 IeaoEKGu7oijoDWCMCyPQied5bi2fEK2UK== 1502 Connection closed by foreign host. 1504 5.3 calookupreq 1506 % telnet cahost1 80 1507 Trying 123.16.5.41 ... 1508 Connected to cahost1. 1509 Escape character is '^]'. 1510 POST /cgi-bin/calookupreq HTTP/1.0 1511 Content-length: 601 1513 cert=MIIBqTCCAVMCAQIwDQYJKoZIhvcNAQECBQAwZjELMAkGA1UEBhMCSlAxGDAWBgNV 1514 BAoTD05FQyBDb3Jwb3JhdGlvbjElMCMGA1UECxMcTmV0d29ya2luZyBTeXN0ZW1z 1515 IExhYnMuIENBNDEWMBQGA1UECxMNaW50ZXJuZXQgZGl2LjAeFw05NzEwMDIxMDQy 1516 NDJaFw05ODAzMzExMDQyNDJaMGIxCzAJBgNVBAYTAkpQMRgwFgYDVQQKEw9ORUMg 1517 Q29ycG9yYXRpb24xITAfBgNVBAsTGE5ldHdvcmtpbmcgU3lzdGVtcyBMYWJzLjEW 1518 MBQGA1UEAxMNVG9yYSBMdXRyYSgyKTBTMAQGAAUAA0sAMEgCQQCVs6HJAXV0qtMV 1519 wP89UeMbmHNaVPBi5ceQDJMPxux3JvPxDwQ9bNVo5ZTFp7rvRBQP/KKxpWAPgh0V 1520 %2blh6IwvLAgMBAAEwDQYJKoZIhvcNAQECBQADQQBxImito7%2b4omMh1TPbhyqZ/ghm 1521 NUC/GBeZaFN29Wm8rmcgH7RjgrcD9iht3FFTW5Lq8Zw5%2bpEh6bKrFiYbKQsY 1522 HTTP/1.1 200 OK 1523 Date: Sat, 04 Oct 1997 08:54:56 GMT 1524 Server: Apache/1.2.1 1525 Connection: close 1526 Content-Type: text/plain 1528 calookupreq 1529 200 accept your request 1530 MIIBtjCCAWACAQAwDQYJKoZIhvcNAQECBQAwZjELMAkGA1UEBhMCSlAxGDAWBgNV 1531 BAoTD05FQyBDb3Jwb3JhdGlvbjElMCMGA1UECxMcTmV0d29ya2luZyBTeXN0ZW1z 1532 IExhYnMuIENBNDEWMBQGA1UECxMNaW50ZXJuZXQgZGl2LjAeFw05NzEwMDIxMTIw 1533 NDJaFw05ODEwMDIxMTIwNDJaMGYxCzAJBgNVBAYTAkpQMRgwFgYDVQQKEw9ORUMg 1534 Q29ycG9yYXRpb24xJTAjBgNVBAsTHE5ldHdvcmtpbmcgU3lzdGVtcyBMYWJzLiBD 1535 QTQxFjAUBgNVBAsTDWludGVybmV0IGRpdi4wXDANBgkqhkiG9w0BAQEFAANLADBI 1536 AkEAgDwky4mQrRadX7WT5AtpV9CFpFk0QhwL43mOwhSnykl5wDksC33KMThg+sBC 1537 nC3HNl7fb1iB6nYzsJSUirK3+wIDAQABMA0GCSqGSIb3DQEBAgUAA0EAXXGVLbQw 1538 lJXTLO6iNUzDXpMhN3aUsYc3dHfS0hWXE0s7yKIMxZrqg8Z6WDI4gVAnstLq6YPo 1539 mgewuYcONPWq6p== 1541 Connection closed by foreign host. 1543 5.4 crlreq 1544 % telnet cahost1 80 1545 Trying 123.16.5.41 ... 1546 Connected to cahost1. 1547 Escape character is '^]'. 1548 POST /cgi-bin/crlreq HTTP/1.0 1549 Content-length: 495 1551 cert=MIIBYzCCARYCAR4wBAYABQAwTTELMAkGA1UEBhMCSlAxDDAKBgNVBAoTA05FQzEw 1552 MC4GA1UECxMnTmV0d29ya2luZyBTeXN0ZW1zIExhYnMgRXhwZXJpbWVudGFsIENB 1553 MB4XDTk3MDcyMjA5NTIxMloXDTk3MTAzMTIzNTk1OVowPjELMAkGA1UEBhMCSlAx 1554 FTATBgNVBAoTDFdJREUgUHJvamVjdDEYMBYGA1UEAxMPbWluZSBzYWt1cmFpKDMp 1555 MFwwDQYJKoZIhvcNAQEBBQADSwAwSAJBAJpfMGvJfeRBelpIfdRDj4a9PkGlFMny 1556 OX78pm8kKkD3pCNdHcMXac%2bAIp8CApA186O40O9Q9QHjftNI5scCs8sCAwEAATAE 1557 BgAFAANBAGoH44rvFVZf6HdrbCu5est417IStth5ZfL5zZlRZlhxL3GlcEFBuqpI 1558 xp7QbKOfstV4ppcVIKX48IJcehn4RK9%3d 1559 HTTP/1.0 200 Document follows 1560 Date: Sun, 14 Sep 1997 10:13:43 GMT 1561 Server: NCSA/1.5.1 1562 Content-type: text/plain 1564 crlreq 1565 200 accept your request 1566 MIHnMIGSMA0GCSqGSIb3DQEBAgUAME0xCzAJBgNVBAYTAkpQMQwwCgYDVQQKEwNO 1567 RUMxMDAuBgNVBAsTJ05ldHdvcmtpbmcgU3lzdGVtcyBMYWJzIEV4cGVyaW1lbnRh 1568 bCBDQRcNOTcwNDIyMDc1MzQ5WhcNOTcwNTIyMDc1MzQ5WjAUMBICAQEXDTk3MDQy 1569 MjA3NTMwMlowDQYJKoZIhvcNAQECBQADQQBKUqMwSBwssoKOACJAN9jY8QvZhKCq 1570 JFoyIfFyaKgoIOHzCw5LY/MlIPVuSZ4a/mZAP4k89BbLxID26ZpBe8+/ 1572 Connection closed by foreign host. 1574 5.5 verifyreq 1576 % telnet cahost1 80 1577 Trying 123.16.5.41 ... 1578 Connected to cahost1. 1579 Escape character is '^]'. 1580 POST /cgi-bin/verifyreq HTTP/1.0 1581 Content-length: 1200 1583 resptype=1&cert=MIIDVDCCAxWgAwIBAgIBAjAOBgoqgwiBnF8LAQQBBQAwSjEL 1584 MAkGA1UEBhMCSlAxGDAWBgNVBAoTD05FQyBDb3Jwb3JhdGlvbjEhMB8GA1UECxMY 1585 TkVDIEV4cGVyaW1lbnRhbCBDQSAxMjAyMB4XDTk3MTIwMjA4Mjc1OVoXDTk4MDMw 1586 MjA4Mjc1OVowga8xCzAJBgNVBAYTAkpQMQ4wDAYDVQQIEwVUb2t5bzEMMAoGA1UE 1587 ERMDMTA4MRgwFgYDVQQKEw9ORUMgQ29ycG9yYXRpb24xGDAWBgNVBAsTD0NvbXB1 1588 dGVyIENlbnRlcjEVMBMGA1UEAxMMV2Fyd2ljayBNb29uMREwDwYDVQQMEwhFbmdp 1589 bmVlcjEkMCIGCSqGSIb3DQEJARYVd2Fyd2lja0BhYmMubmVjLmNvLmpwMIHWMIGo 1590 BgoqgwiGjScHAQUBMIGZAgEBMCMGCiqDCIaNJwcBBgECFQD///////////////// 1591 ///////4IzAsBBQAAAAAAAAAAAAAAAAAAAAAAAAAAAQUAAAAAAAAAAAAAAAAAAAA 1592 AAAAAAQEKHREkIEzBgj2pQP3jxfqq/HGpF5IjXaPj5/323zM8GqV5jc7d9QTWlIC 1593 FAaQaQaQaQaQaQaJGF5nDdBMGhjrAgEAAykADlDr4ahA3gN89hnQHQQUGShmZJxe 1594 FCXBf5qqQhtFszd9scSZyvjrN6OCAQIwgf8wDwYDVR0TAQEABAUwAwEBADAOBgNV 1595 HQ8BAQAEBAMCAaAwPQYDVR0gAQEABDMwMTAvBgkqgwiBnF8LBAEwIjAgBgYrBgEF 1596 AwQWFmh0dHA6Ly93d3cuaWNhdC5vci5qcC8wZgYLKoMIgZxfCwMBHQIBAQAEVDBS 1597 oCiGJmh0dHA6Ly9zcGxzOTU6ODAwMC9jZ2ktYmluL2NhbG9va3VwcmVxoSaGJGh0 1598 dHA6Ly9zcGxzOTU6ODAwMC9jZ2ktYmluL3ZlcmlmeXJlcTA1BgNVHR8BAQAEKzAp 1599 MCegJaAjhiFodHRwOi8vc3Bsczk1OjgwMDAvY2dpLWJpbi9jcmxyZXEwDgYKKoMI 1600 gZxfCwEEAQUAAykATQ4X5uxUoVw0rvgX1G1mygXkNYuZGQM3g18eboLgvFrQo5xA 1601 AoCDaA%3d%3d 1602 HTTP/1.1 200 OK 1603 Date: Wed, 03 Dec 1997 02:39:00 GMT 1604 Server: Apache/1.2.1 1605 Connection: close 1606 Content-Type: text/plain 1608 verifyreq 1609 200 valid 1610 Connection closed by foreign host. 1612 Acknowledgement 1614 The authors thank Mr. Ohbayashi, Mr. Kitano, Mr. Kobayashi, Mr. 1615 Kuroda, Mr.Fujimoto, and Mr. Wada for their comments to this 1616 proposal. The authors also thank the other researchers joining the 1617 Initiatives for Computer Authentication Technology (ICAT), and the 1618 members of WIDE project. 1620 References 1622 [X.509] ITU-T Recommendation X.509 (1197 E): 1623 Information Technology - Open Systems Interconnection - 1624 The Directory: Authentication Framework, June 1997 1626 [PKIX-PROF] R. Housley, et. al., 1627 "Internet Public Key Infrastructure 1628 X.509 Certificate and CRL Profile," 1629 , June 1998 1631 [PKIX-CMP] C. Adams and S. Farrell, 1632 Internet Public Key Infrastructure 1633 Certificate Management Protocols," 1634 , February 1998 1636 [PKIX-OCSP] C. Adams, et. al., 1637 "X.509 Internet Public Key Infrastructure 1638 Online Certificate Status Protocol - OCSP", 1639 , July 1998 1641 [PKIX-OPP] R. Housley, 1642 "Internet X.509 Public Key Infrastructure 1643 Operational Protocols: FTP and HTTP", 1644 , April 1998 1646 [PKIX-LDAP] S. Boeyen, et. al., 1647 "Internet X.509 Public Key Infrastructure 1648 LDAPv2 Schema", 1649 , March 1998 1651 [HTTP] T. Berners-Lee, R. Fielding, H. Nielsen, "Hypertext Transfer 1652 Protocol -- HTTP/1.0", RFC 1945, May 1996 1654 [SSL] http://home.netscape.com/eng/ssl3/draft302.txt, 1997 1656 [ASN.1] B. Kaliski, "A Layman's Guide to a Subset of ASN.1, BER, 1657 and DER", ftp://ftp.rsa.com (layman.ps), June 1991 1659 [Mine] M. Sakurai, et.al., "A Design of Certificate or CRL 1660 Distribution Architecture between Certification 1661 Authorities", 1662 The 1997 Symp. on Cryptography and Information Security 1663 (SCIS'97), 8D, January 1997 1665 [RFC1779] S. Kille, 1666 "A String Representation of Distinguished Names", 1667 RFC 1779, March 1995 1669 [PKCS-7] B. Kaliski, 1670 "PKCS 7: Cryptographic Message Syntax Version 1-5", 1671 RFC 2315, March 1998 1673 [PKCS-9] RSA Laboratories, 1674 "PKCS #9: Selected Attribute Types", 1675 An RSA Laboatories Technical Note, November 1993 1677 [PKCS-10] B. Kaliski, 1678 "PKCS 10: Certification Request Syntax Version 1-5", 1679 RFC 2314, March 1998 1681 [RFC2045] N. Freed & N. Borenstein, 1682 "Multipurpose Internet Mail Extensions (MIME) Part 1683 One: Format of Internet Message Bodies", 1684 RFC2045, November 1996 1686 Security Considerations 1688 This entire memo is about security mechanisms. 1690 Author Addresses: 1692 Mine Sakurai 1693 NEC Corporation 1694 Igarashi bldg., 2-11-5 Shibaura, Minato-ku, Tokyo 108-8557, Japan 1695 m-sakura@ccs.mt.nec.co.jp 1697 Hiroaki Kikuchi 1698 Dept. of Electrical Engineering 1699 Tokai University 1700 1117 Kitakaname, Hiratsuka, Kanagawa 259-1292, Japan 1701 kikn@ep.u-tokai.ac.jp 1703 Hiroyuki Hattori 1704 Meiji University 1705 1-1, Kandasurugadai, Chiyoda-ku, Tokyo 101-8301, Japan 1706 hhat@isc.meiji.ac.jp 1708 Yoshiki Sameshima 1709 Initiatives for Computer Authentication Technology 1710 Information Security Office, 1711 Japan Information Processing Development Center 1712 3-5-8 Shiba-Kouen, Minato Ku, 105, Tokyo, Japan 1714 Hitoshi Kumagai 1715 Initiatives for Computer Authentication Technology 1716 Information Security Office, 1717 Japan Information Processing Development Center 1718 3-5-8 Shiba-Kouen, Minato Ku, 105, Tokyo, Japan 1720 Appendix: ICAT-local OIDs 1722 In our sample implementation, two OIDs are originally defined and 1723 used. One is "App", and another is "V3Extn". 1725 ICAT OBJECT IDENTIFIER ::= 1726 { iso(1) member-body(2) jisc(392) JIPDEC(20063) 11} 1728 App OBJECT IDENTIFIER ::= 1729 {ICAT PKI(2) PKCS10(1) 1} 1731 V3Extn OBJECT IDENTIFIER ::= 1732 {ICAT PKI(2) PKCS10(1) 2} 1734 The example of extended PKCS#10 message, encoded in BER, is as 1735 follows: 1737 30 (739) 1738 30 (676) 1739 02 (1) 00 1740 30 (181) 1741 31 (11) 1742 30 (9) 1743 06 (3) 550406 1744 13 (2) [JP] 1745 31 (14) 1746 30 (12) 1747 06 (3) 550408 1748 13 (5) [Tokyo] 1749 31 (18) 1750 30 (16) 1751 06 (3) 550407 1752 13 (9) [Minato-ku] 1753 31 (24) 1754 30 (22) 1755 06 (3) 55040a 1757 13 (15) [NEC Corporation] 1758 31 (24) 1759 30 (22) 1760 06 (3) 55040b 1761 13 (15) [Computer Center] 1762 31 (20) 1763 30 (18) 1764 06 (3) 550403 1765 13 (11) [Taro Tanaka] 1766 31 (17) 1767 30 (15) 1768 06 (3) 55040c 1769 13 (8) [Engineer] 1770 31 (37) 1771 30 (35) 1772 06 (9) 2a864886f70d010901 1773 16 (22) [taro@aaa.bbb.nec.co.jp] 1774 30 (214) 1775 30 (168) 1776 06 (10) 2a8308868d2707010501 1777 30 (153) 1778 02 (1) 01 1779 30 (35) 1780 06 (10) 2a8308868d2707010601 1781 02 (21) 00ffffffffffffffffffffffffffffffffff 1782 fff823 1783 30 (44) 1784 04 (20) 000000000000000000000000000000000000 1785 0000 1786 04 (20) 000000000000000000000000000000000000 1787 0004 1788 04 (40) 74449081330608f6a503f78f17eaabf1c6a45e48 1789 8d768f8f9ff7db7cccf06a95e6373b77d4135a52 1790 02 (20) 0690690690690690690689185e670dd04c1a18eb 1791 02 (1) 00 1792 03 (41) 006d4cf2c4c6ba1c75f4dd6b330dea86f82934b99704937d 1793 7b85f4a4a6010b539df905329342f10a17 1794 A0 (268) 1795 30 (23) 1796 06 (9) 2a864886f70d010902 1797 31 (10) 1798 16 (8) [TESTUSER] 1799 30 (23) 1800 06 (9) 2a864886f70d010907 1801 31 (10) 1802 13 (8) [TESTPASS] 1803 30 (21) 1804 06 (10) 2a8308819c5f0b020101 1805 31 (7) 1806 13 (5) [PEPOP] 1807 30 (192) 1808 06 (10) 2a8308819c5f0b020102 1809 31 (177) 1810 30 (174) 1811 30 (15) 1812 06 (3) 551d13 1813 01 (1) 00 1814 04 (5) 3003010100 1815 30 (154) 1816 06 (11) 2a8308819c5f0b03011d01 1817 01 (1) 00 1818 04 (135) 30818430643018060355040a3111130 1819 f4e454320436f72706f726174696f6e300e060355040831071305546f6b796f30110 1820 60355040c310a1308456e67696e656572302506092a864886f70d010901311816167 1821 461726f406161612e6262622e6e65632e636f2e6a70170d393730383235303030303 1822 0305a170d3937313132353030303030305a 1823 30 (14) 1824 06 (10) 2a8308819c5f0b010401 1825 05 (0) 1826 03 (41) 00fa54b614e767e8a8ccd6c595dae74fce02a25d8faf78bd080c70ca 1827 85b00b5c0354966f9f02ad2c9a 1829 Note1: Strings in () are represented in decimal. 1831 Note2: In this example, we use Matsushita's Elliptic Curve 1832 Cryptosystems, My-Ellty, as public-key algorithm.