PKIX Working Group Tae Kyu Choi Internet Draft Hyangjin Lee Document: draft-choi-pkix-ui-01.txt In Kyoung Jeon Expires: April 24, 2005 BaeHyo Park Target category : Non-Standard Track Jaeil Lee KISA October 25, 2004 User Interface Requirement for the Internet X.509 Public Key Infrastructure Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of [RFC 2026]. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. IPR Statement By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Choi, et. al. Expires - April 2005 [Page 1] INTERNET-DRAFT User Interface Requirement for the PKI October 2004 Abstract This document provides basic requirements of user interface at PKI client software that satisfy a full of PKI implementation with usability. To meet with the requirements, it defines root CA certificate trust mechanism, certificate sharing mechanism, and certificate representation method. 1. Introduction For effective PKI implementation, this document defines a basic requirement for developing user interface in terms of security, interoperability, and usability aspect. 2. Requirements 2.1 Security Client software that is downloaded from PKI application servers must be installed and upgraded with a reliable and secure manner. After that, it is to establish secure trust relationship with root CA in order to receive root CA public key. If the root CA cer-tificate is updated, the client software also must establish trust with the updated root CA certificate. 2.1.1 Client software installation and upgrade Client software should be obtained in secure manner for installation. It is necessary to provide a secure method to distribute client software and this document defines it as automatic update function, which is a similar concept with Window update in MS Windows. Automatic update function is also used for software upgrade purpose. 2.1.2 Root CA certificate trust mechanism The relying party should obtain the root CA certificate and public key in secure manner. Major root CA certificates are installed in major web browsers and it is automatically installed from beginning installation so that user can easily make trust with root CA. However, a user from third party certificate that cannot install in web browser has difficulty in identifying their own root public key trust relationship. In addition, it becomes inevitable situation when trusted certificate is expired or updated. Therefore, it is necessary to provide a secure method to distribute root public key and this document defines it as automatic update function, which is a similar Choi, et. al. Expires - April 2005 [Page 2] INTERNET-DRAFT User Interface Requirement for the PKI October 2004 concept with Window update in MS Windows. An end entity must securely possess the public key of its root CA during the end entity initialization process [RFC2510] by acquiring root CA certificate. It can be done through many ways but this document describes the root CA certificate trust mechanism using client software. The root CA can make arrangements with manufactures of application software to deliver the root CA certificate within their software. End entities can acquire the root CA certificate after installation of client software. The end entity can show the hash value of acquired root CA certificate to trust it. The end entity may acquire the hash value of root CA certificate through face-to-face contacting or root CA web site before software installation. If the root CA certificate is expired, then all PKI entities can not use their certificate. Therefore, the root CA certificate must me updated before expiration date of it, and the client software also must acqurie the updated root CA certificate. At this point, the end entity can use the client software upgrade fuction. During client software upgrading, it can download the updated root CA certificate. And then it can trust the updated root CA certificate using the same mechanism with an initial installation of old root CA certificate. This approach is more convinient and secure way to manage root CA public key information, especially when the root CA public key is more then one or requires frequent update. 2.2 Interoperability Interoperability can be accomplished by using one certificate to many PKI applications. It can be defined as certificate and private key sharing mechanism that mainly aims for increasing certificate mobility, which benefits the user's convenience. This section will introduce certificate and private key sharing mechanism as covering three management rules of certificate and private key. 2.2.1 Certificate sharing mechanism Generally, PKI application such as web browser or mail application defines the user's certificate and private key location by their own way. However, most users want to use multi PKI programs by one certificate without each certificate per programs under one CA. Therefore, we define common storage location by storing devices for various operating systems. To classify common storage location of certificate and private key, the types of required operating systems should be classified as Choi, et. al. Expires - April 2005 [Page 3] INTERNET-DRAFT User Interface Requirement for the PKI October 2004 following: - MS Windows - Linux/Unix - Mac The common storage location of these operating systems is defined in Section 2.2.1.1. 2.2.1.1 Common storage location To increase compatibility in different client softwares, user interface defines to make a common path to store certificate and private key for various storage mediums in each operating system. For example, a common storage location of hard disk in different systems is assigned to be: - MS Windows : C:Program FilesIETFPKIX - Linux/Unix : (User Account)/IETF/PKIX - Mac : (Hard disk label): At this path, the directory name of 'IETF' location is replaced by PKI domain name, and the directory name of 'PKIX' location is assigned by organization value of distinguished names in certificate. 2.2.1.2 Storage format Considering certificate size stored at storage medium and compatibility with other operating systems, it must define storage format that satisfy these requirements such as DER or PEM format. For storage format of private key, it has to use PKCS#5, which is a password based cryptographic method. Afterward, it is stored to storage medium according to PKCS#8. 2.2.1.3 File naming rule of certificate and private key On occasion of updating CA certificate and having a certificate which has muti identical DN, it uses an unique file name as a form of extension field and certificate serial number within certificate and private key file name of CA in order to establish certificate validation path. Namely, a form of the file name for root CA or CA certificate is defined as 'SKI value_serial number.der'. SKI(Subject Key Identifier) is an extension field value of Subject Key Identifier and it Choi, et. al. Expires - April 2005 [Page 4] INTERNET-DRAFT User Interface Requirement for the PKI October 2004 represents as a hex number of forty digits. Serial number represents as decimal number. For example of MS Windows, Linux/Unix, and Mac in hard disk, absolute file path and name of CA certificate can be represented as following: - MS Windows : C:Program FilesIETFPKIX value_serial number.der - Linux/Unix : (User Account)/IETF/PKIX/SKI value_serial number.der - Mac : (Disk label):al number.der Regarding as individual certificate and private key, it should be stored as a form of xxx.der or xxx.key, after creating a directory named by DN. xxx naming is identically used for distinguishing between digital signature and certificate distribution purpose. 2.2.2 Import and export function To use certificate in other PKI applications on the Internet X.509 Public Key Infrastructure, user interface should offer certificate export and import function according to PKCS#12. 2.3 Usability User interface must consider usability on implementing PKI functions, so that a user who doesn't know about any PKI knowledge can easily and safely use PKI services. In this section, it specifies certificate representation method and categorization of storage medium at PKI client software. 2.3.1 Certificate representation Essential part of initial user inteface must be composed of three kinds of representaion areas; - Certificate information area - Storage type selection area - Certificate management area Certificate information area in client software is to displaying certificate that was automatically searched by client software so that user can select the certificate to be log in. At this point, a detail information of certificate including subject name, expiration date, issuer about certificate should be listed. For selecting various storage types, storage type selection area in client software should appropriately display its storage medium by categorization defined Section 2.3.2. Choi, et. al. Expires - April 2005 [Page 5] INTERNET-DRAFT User Interface Requirement for the PKI October 2004 Additionally, certificate management area should offer certificate management functions as required; - Import and export function - Public key password change - Certificate delete function - Certificate verification function 2.3.2 Categorization of Storage Medium On the certificate representation, a choice for storage medium should effectively provide for user to select the desired choice. In order to do so, storage medium is independently categorized by the nature of storage medium. User interface may consider to include the following: - Hard disk - Floppy Diskette - USB Drive, token, and key - Smartcard - CD 3. Reference [PKCS5] RSA Laboratories, PKCS#5 v2.0 "Password-Based Cryptography Standard", RSA Data Security Inc., 1993 [PKCS8] RSA Laboratories, PKCS#8 v1.2 "Private Key Information Syntax Standard", RSA Data Security Inc., 1993 [PKCS12] RSA Laboratories, PKCS#12 v1.0 "Personal Key Information Exchange Syntax Standard", RSA Data Security Inc., 1993 [RFC2459] R.Housley, "Internet X.509 Public Key Infrastructure Certificate and CRL Profile", RFC 2459, January 1999 [RFC2119] S.Bradner, "Key words for use in RFCs to Indicate Requirement Levels",RFC3467, March 1997 4. Intellectual Property and Copyright Statement Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has Choi, et. al. Expires - April 2005 [Page 6] INTERNET-DRAFT User Interface Requirement for the PKI October 2004 made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. 5. Authors' Address Tae Kyu Choi Korea Information Security Agency Phone: +82-2-405-5448 FAX : +82-2-405-5499 Email: tkchoi@kisa.or.kr Hyangjin Lee Korea Information Security Agency Phone: +82-2-405-5448 FAX : +82-2-405-5499 Email: jiinii@kisa.or.kr Choi, et. al. Expires - April 2005 [Page 7] INTERNET-DRAFT User Interface Requirement for the PKI October 2004 Inkyoung Jeon Korea Information Security Agency Phone: +82-2-405-5432 FAX : +82-2-405-5499 Email: inkyoung@kisa.or.kr BaeHyo Park Korea Information Security Agency Phone: +82-2-405-5443 FAX : +82-2-405-5499 Email: parkbh@kisa.or.kr Jaeil Lee Korea Information Security Agency Phone: +82-2-405-5300 FAX : +82-2-405-5499 Email: jilee@kisa.or.kr Choi, et. al. Expires - April 2005 [Page 8]