PKIX Working Group H. Kikuchi (Tokai Univ) Internet Draft M. Sakurai (NEC) H. Hattori (Meiji Univ) Y. Sameshima (Hitachi Soft) expires in six months March 1997 Internet Public Key Infrastructure: Web-based Certificate and CRL Repository 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 learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract This document provides a specification how to publish and retrieve X.509 certificates and certificate revocation lists (CRLs). In the proposed method, the World Wide Web (WWW) is used for securely distributing certificates across a firewall in both human and machine readable syntax. A various certificate concerning information that includes certificates, CRLs, and certification authority (CA) policy are retrieved from an integrated single authority access point specified in X.509 version 3 extensions. The information access point accepts certification and revocation requests in the uniform access method based on the standard WWW. Kikuchi [Page 1] Internet DRAFT March 1997 1. Introduction The first attempt for security enhancement of the Internet applications was electrionic mail. The Privacy Enhanced Mail (PEM) defined in [RFC-1421, 1422, 1423 and 1424] proposed X.509 public key certificates and hierarchically structured certification authorities (CAs), which are then adopted in MOSS [MOSS] and S/MIME [S/MIME]. These security protocols, however, require that a sender has to convey many certificates needed to certify its validity from a receiver because of the lack of certificates repository. Therefore, a big challenge to establish Public Key Infrastructure (PKI) is made by specifying profiles of the X.509 version 3 certificate and version 2 CRL [PKIX-1]. The PKI working group also proposed certificate management protocols in [PKIX-3], in which wide range of CA information format called PKI messages are defined by ASN.1 [ASN.1] that makes processing easier for management software, and simple socket based transport protocols. However, in the practical point of view, the socket based transport protocol is problematic. First, most commercial organization have a firewall, which prevents intruder from gaining access to internal LAN and might reject PKI message transfer. For this reason, they shall provide a proxy service for each protocol. Second problem is confidentiality of PKI messages. Although most PKI message are public information, the initializing message such as certification or revocation requests require an extra capability of message encryption for achieving confidentiality. The third problem is the scaleability, which makes the service available in the wide scale networks. The requirement involves reducing traffic cost by a certificates cashing or a distributed database. The last problem is ASN.1 based definition which forces Basic Encoding Rule (BER) to transfer a PKI messages. For easier implementation, human readable encoding rule is appropriate. To meet these requirements, this document defines World Wide Web (WWW) based certification and CRL repository. Since WWW is now one of the major application in the internet, almost all internet users can use it even if the site they belong has a firewall against intruders. The WWW provides some useful facilities for PKI; an information cashing by both a proxy server and client software, a secure transport layer service for confidentiality, a flexible request forwarding which can be used in CA and CA communication, and human readable and easier manipulating message format. Kikuchi [Page 2] Internet DRAFT March 1997 2. Basic Definition, Requirements and Assumptions 2.1 Overview This document suppose simple restricted hierarchical certificate infrastructure rather than complicated CA web. Figure 1 shows an example of hierarchy of Publishing Authority (PAs), where PA2 has two subordinary PAs, PA1 and PA2, and PA1 has two users having certificate Cert1 and Cert2, respectively. Every certificate has one information access point (IAP) from which any information with regards to users can be retrieved. The PA is responsible for all information it publishes. Thus, it also provides on-line validation service with and without CRLs. The PA certificate, which may be identical to the standard CA certificate, also has upper IAP entry. There is no different in IAP syntax among end entity, PA and CA. None of user and PAs publish certificate by theirselves, that is, subject information access extension is not necessary. The IAP specification is defined in Section 2.2. The communication between entities was based on Hyper Text Transfer Protocol (HTTP) and its variation. The Hyper Text Markup Language is used as message format. Note that a subordinate entity is subject to be message sender and the higher entity just response to the requester. Thus, the coordinate entities never get direct communication with them. This assumption is convenient for conformance. The end entity and PA protocol is defined in Section 3. +-----+ | | PA3 V | IAP3+---+ | +---->| *------+ PA1 | +---+ IAP1 +---+ | +------->| *-----+ Cert1 | +---+ | +---+ | | | *----+ | +---+ | PA2 | Cert2 | +---+ | +---+ | | *-----+ | *----+ +---+ +---+ Figure 1: Example of PAs hierarchy Kikuchi [Page 3] Internet DRAFT March 1997 2.2 Requirement for PKI Application The PKI application needs certificates and CRL repository in the following three cases; 1. certificate retrieval. For example, a sender of secure message wants to retrieve the recipient's public key by which the message is to be encrypted. 2. certificate verification. The recipient of secure message check if the sender's certificate is not revoked by examining the corresponding CRL or asking the CA directly. 3. 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 [PKIX1], the subject and issuer names in X.509 (v1) may be an empty sequence and subjectAltName and issuerAltName extensions (v3) 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. Most PKI applications require many kinds of information about certificate including policy information, CRL, and CA information. In [PKIX1], 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 for the simplification of PKI protocol. As the same reason, the subjectInfoAccess, the authrotyInfoAccess and the caInfoAccess can be unified to the authorityInfoAccess. The subjectInfoAccess may be meaningless because a PKI user needs the information access point in two cases; (1) when it wants to verify the sender's certificate after it receives a secure message, or (2) when it wants to retrieve its recipient's certificate before it sends. In the first case, he/she cannot believe any information provided by the subjectInfoAccess, which the sender itself specify, and thus may be altered. Hence, he/she shall use the authrotyInfoAccess instead of the subjectInfoAccess. The other case, Kikuchi [Page 4] Internet DRAFT March 1997 he/she has not yet known the subject information access point which is to be specified the recipient's certificate, which shall be retrieved from any authrotyInfoAccess point she/he knows. Once PKI user gets the recipient's certificate, the subjectInfoAccess is no longer necessary for him/her. Consequently, the subjectInfoAccess is useless. The AuthorityInfoAccess contains at least one AccessDescription in which the accessMethod and accessLocation shall specify httpID and appropriately URL that accepts "POST" method. If this proposal is used, a standard certificate must specify - authorityInfoAccess, shall specify - subjectAltName, - issuerAltName, may specify - authorityKeyIdentifier, - subjectKeyIdentifier, - keyUsage, - privateKeyUsagePeriod, - certificagtePolicies, - basicConstraints, - nameConstraints, - policyConstraints, must not specify for avoiding confusion - cRLDistributionPoints, - policyMappings, - subjectDirectoryAttributes, - subjectInfoAccess, - authorityInfoAccess, - caInfoAccess. 2.4 Requirement for Publishing Authority Since the number of PKI user increases step by step, the set of CAs always have to keep communicating with each other. Moreover, the number of CA also increases slightly, so, the hierarchical CAs structure is proposed in [RFC1422]. Where, the root CA is required to update all CAs and to manage the access path. Kikuchi [Page 5] Internet DRAFT March 1997 However, in practice, at the entrance to the Internet every organization has a firewall facility which restricts internet access to a particular application, service, and host in order for security consideration. Thus, generally, an CA runs within the firewall and only communicates with internal PKI users. Therefore, we need a publishing authority (PA) that is set up for each CA and works as a certificate repository outside of the firewall. Figure 2 shows this structure. The transaction between particular entities can be easily restricted by a firewall, thus, it does not spoil the security of CA. An internal static information access point provides a simple and uniform access method for PKI users. Any information stored in external PA is not secret information and may be different to that of internal PA. [root PA] The Internet | ---+------+---------+- | | | | | | [CA]--+---[PA] [PA]--+--[CA] /| | | | PKI users | | PKI users firewall firewall Figure 2. Relationship between PA and CA 3. Transport Protocol 3.1 Information Access Information access point (IAP) is specified by the subjectInfoAccess field in certificate extension. The IAP is a point from which certificates are distributed and on-line verification service is provided. The PA server can be implemented as a standard HTTP server which enables CGI facility. The IAP server works as PA, CRL distribution point, policy repository, verification server, and certificate repository. The PA server management certificates in a specific closed organization, and communicates with upper PA server which knows the all subordinate PA server's location. A PKI application points at least one IAP so as to retrieve locations of other IAPs. Kikuchi [Page 6] Internet DRAFT March 1997 An information transfer is based on HTTP with method POST. Thus, the typical query is formated as follows; POST IAP/queryType HTTP/1.0 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 fields are subject to be formed in standard encoding rule defined in [HTTP]. HTTP/1.0 200 OK Date: Wednesday MIME-version: 1.0 Content-type: text/html queryType

statusCode

statusMessage

information Where, "queryType" is the same as the type given in sending request. The "statusCode" contains a status with three digit codes. With at least one space, the "statusMessage" and "information" are interpreted in corresponding semantics. The syntax of "information" depends on the query type, and will be defined section 5. 3.2 Type of Query This document defines the followings query types. 1. certreq 2. revokereq 3. lookupreq 4. verifyreq 3.2.1 Initial Registration type "certreq" Type "certreq" is used for sending certification request to CA. This query may be used only if the PA works as CA or has some means to relay the request to the corresponding CA. The certreq request shall be sent with some of the following pairs of name and value. name value ---- ----- o Organization ou1 Organizational unit Kikuchi [Page 7] Internet DRAFT March 1997 ou2 Organizational unit 2 ou3 Organizational unit 3 ou4 Organizational unit 4 cn Common name n public component of RSA cryptosystem email RFC822 style email address info URL of user's home page key public key encoded in corresponding BER acct User identification pass User password loginname Manager identification password Manager password The pair "o", "cn", "n", "email" are critical pairs. The name "n" implicitly identifies a modulo value when public component of 0x10001 is used in RSA cryptosystem. Otherwise, name "key" shall be used to convey public key information which is encoded in the corresponding BER rule. Either of "n" and "key" must be given. The "acct" and "pass" may be used for user authentication. If these pairs are missing, the response shall contain the other pairs as hidden attribute and be used as confirmation of user information. Alternatively, the "loginname" and "password" may be used by the CA manage. The response consists of statusCode, statusMessage and information. statusCode statusMessage information ---------- ------------- ----------- 200 "accept your request" the issued certificate encoded in Base64 encoding rule. 301 "incomplete request" the missing pair and the other information 302 "duplicate request" the certificate has already been issued. 303 "reject your request" any other reason why the request failed. 304 "service not available" the PA does not accept this request. 3.2.2 Certificate Revocation "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 conventical application that supports digital signature. name value Kikuchi [Page 8] Internet DRAFT March 1997 ---- ----- sig digitally signed revocation message statusCode statusMessage information ---------- ------------- ----------- 200 "accept your request" nothing (the certificate is revoked) 301 "invalid signature" nothing 302 "duplicate request" nothing (the certificate has already been revoked) 303 "reject your request" any other reason why the request failed. 304 "service not available" the PA does not accept this request. 3.2.3 Certificate Distribution "lookupreq" The "lookupreq" type is used for retrieving and searching certificate, CRLs, and any other information. The PA server may forward a request to other PA server when it does not has sufficient information to response to the request. Certificate is identified by either of the following names; a. email address b. Distinguished Name Both identifiers must be fully specified because a substring matching rule might violate a privacy issue when the PA is the outside of firewall. The lookup query is sent with the following pairs of names and value. name value ---- ----- o Organization ou1 Organizational unit ou2 Organizational unit 2 ou3 Organizational unit 3 ou4 Organizational unit 4 cn Common name dn subject/CA Distinguished Name. email subject/CA email address object "policy" (policy description and mapping) "cert" (CA or subject certificate) "crl" (CA CRL) The pairs of "o", "ou1", "ou2", "ou3", "ou4", and "cn" specify intend distinguished name. Alternatively, the "dn" pair may be used to specify distinguished names. When the specification is incomplete, the PA may reject it for privacy issue or accept it as substring matching. Whether the request is for subject or for CA can be Kikuchi [Page 9] Internet DRAFT March 1997 identified by the distinguished name. For example, a distinguished name containing "cn=Authority" is a request for CA, otherwise for subject. The "object" specifies what information is required and takes "cert" in default. For instance, a request with "object=crl" is equivalent to the request by crlDistributionPoint extension. The response consists of statusCode, statusMessage and information. statusCode statusMessage information ---------- ------------- ----------- 200 "accept your request" the certificate, policy or CRL encoded in Base64 encoding rule. 301 "revoked" the reason of revoked 302 "reject your request" the reason why the request failed. 303 "service not available" the PA does not accept this request. 3.2.4 Certificate Verification "verifyreq" Type "verifyreq" is used for validation check of certificate. This document does not support path validation. The verifyreq request shall be sent with the following pairs of name and value. name value ---- ----- cert certificate embedded in CGI coding rule certsig certificate embedded in CGI coding rule crl DN of intended certificate sn serial number of a certificate time GENERALIZED TIME when certificate should be checked to be valid. dn request originator's distinguished name The "certsig" request has the PA digitally signed its response. The PKI user specify a certificate by either sending the whole certificate with "cert" or just sending "sn" when the implicit PA server can be determined. The "time" is optional pair, which means when the certificate to be examined. This option is used when one wants to verify if an old message was valid at that time. When "cert" is specified, the certificate to be verified is embedded into the value in CGI coding rule. The "certsig" is same as the "cert" except but it responses with message integrity check code. When "crl" is specified, PA server only make sure if the intended certificate is already revoked. Kikuchi [Page 10] Internet DRAFT March 1997 The "dn" is used when the PA provides verification service only to restricted users. The response of "cert" request is as follows. statusCode statusMessage information ---------- ------------- ----------- 200 "valid" nothing (the certificate is valid) 201 "not revoked" nothing (the certificate is not revoked) 301 "revoked" the reason of revoked 302 "hold" the reason of hold 303 "reject your request" any other reason why the request failed. 304 "service not avialable" the PA does not accept this request. Some example of reason of revoked are such that the key was compromised, or the affiliation was changed. 3.3 Correspondence to preceding PKI draft This document corresponds to PKI management protocol defined in [PKIX3]. Table 1 shows the correspondence and side effect occurred by a request. Table 1. Correspondence of methods PKI method PA method Side effect ------------ ---------- ----------- certStatus verify no certRetrieval lookup no caPolicy lookup no caCert lookup no CRLDistributionPoint lookup no certReq certreq yes revokeReq revokereq yes 3.4 Inter-PA Protocol If a request to a PA concerns information not stored in the PA, the PA shall manage to obtain it by relying the request to an appropriate PA. This section define an inter-PA transaction. Kikuchi [Page 11] Internet DRAFT March 1997 3.4.1 PA Model Suppose that there are PA1, PA2 and RootPA, and PA1 has a request for retrieving information from PA2. The PA1 and PA2 does not have their locations but the access point to RootCA. There are two possibilities for PA1 to get access to PA2 (Figure 3). - Model 1. [referral] PA1 sends the request to Root PA (1), which then replies to PA1 with the access point to PA2 (2). PA1 sends it to PA2 again (3), and finally PA1 gets the information from PA2. - Model 2. [chaining] PA1 sends the request to Root PA (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. Inter-PA models 3.4.2 Referral Model To redirect a request to another PA server, the root PA responds to the requester with the following HTTP redirect message consisting HTTP header and HTTP body. HTTP/1.0 302 Found Date: Monday, 20-Jan-97 13:33:29 GMT Server: NCSA/1.1 MIME-version: 1.0 Location: http://xxx.yy:zz/method Content-type: text/html Document moved

Document moved

This document has moved here.

Kikuchi [Page 12] Internet DRAFT March 1997 Where the URL "http://xxx.yy:zz/method" specified by the Location HTTP header provides information where the query to be sent next. This is a control message used in the standard HTTP transaction [HTTP]. The root PA must respond with either correct PA location or error message to mean that there is no certificate. To do this, all correspondences between identifiers and IAP locations should be notified by the root PA. In this model, PKI application or PA must support HTTP redirect message. Each round trip time is short, but PA has to send the same query to several servers. 3.4.3 CGI Chaining Model To implement CGI chaining model, the CGI script in 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 less than that of the referral model. Since PA communicates with a particular PA, the access control at firewall can be easily set up. 4. Security Consideration 4.1 Confidentiality of transaction To prevent message from being eavesdropped, secure communication channel such as SSL shall be used. Especially, initial registration process is critical to eavesdropping. Since user authentication is checked by "uid" and "passwd", a client software is not required to have its own certificate. Under the assumption, PKI message protection proposed in [PKIX3] need not here. 4.2 Non-Repudiation The verify request supports the time to be checked and digitally signed response. This can avoid a message sender from denying the message. To enable this service, any PA must manage all certificates which it has already issued, including revoked certificates. Kikuchi [Page 13] Internet DRAFT March 1997 4.3 Privacy In the lookup request, the support of substring matching facility may distribute private information to outsiders, and thereby may be used for sending an advertisement via email. 5. ASN.1 encoding rule in HTML 5.1 Definition A certificate management protocol is defined in ASN.1 syntax in [PKIX3]. The BER is not human readable but is better for security enhancements such as an integrity checking, whereas the ASCII text is human readable but not suitable for machine processing. Therefore, this document defines ASN.1 encoding rule in HTML, which can be both human and machine readable encoding. In the BER, any data type is formed with three elements, tag, length, and value. Instead of the length field, the HTML encoding identifies the value field by specifying the data start tag and the data end tag. The printable string data type and UTC time type are specified by the

and

tag. The other data type is defined by the
and
tag. The structured types, SET and SEQUENCE, are defined by the