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
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
andtag. This notation is useful when PKI application transfers the whole certificate without interpreting the contents. The encoding rule allows no optional notation, no tagged type and no default value. Every data type is specified explicitly in order to for uniquely distinguishing data types. Table 2 shows main data type and the encoding format. Where, "n", "s" are examples of numbers and string, and "a" and "b" are of any ASN.1 data type. For example, an integer 12 is coded by "
xxx5.2 Example A PKI message format and the corresponding encoding are as follows. Note that the tagged data protection and extraCerts are not omitted. PKIMessage ::= SEQUENCE { header PKIHeader, body PKIBody, protection [0] PKIProtection OPTIONAL, extraCerts [1] SEQUENCE OF Certificate OPTIONAL }