PKIX Working Group Hyangjin Lee
Internet Draft Tae Kyu Choi
Document: draft-choi-pkix-ui-00.txt In Kyoung Jeon
Expires: October 9, 2004 Jaeil Lee
Target category : Standard Track KISA
July 10, 2004
User Interface Requirement for the Internet X.509 Public Key Infrastructure
<draft-choi-pkix-ui-00.txt>
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.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
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.
Lee, et. al. Expires - October 2004 [Page 1]
INTERNET-DRAFT User Interface Requirement for the PKI July 2004
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
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
Lee, et. al. Expires - October 2004 [Page 2]
INTERNET-DRAFT User Interface Requirement for the PKI July 2004
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.
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 MS Windows
system is assigned to be:
C:\Program Files\IETF\PKIX
Lee, et. al. Expires - October 2004 [Page 3]
INTERNET-DRAFT User Interface Requirement for the PKI July 2004
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
represents as a hex number of forty digits. Serial number represents
as decimal number.
For example of MS Windows, absolute file path and name of CA
certificate can be represented as following:
C:\Program Files\IETF\PKIX\SKI value_serial 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.
Lee, et. al. Expires - October 2004 [Page 4]
INTERNET-DRAFT User Interface Requirement for the PKI July 2004
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.
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
Lee, et. al. Expires - October 2004 [Page 5]
INTERNET-DRAFT User Interface Requirement for the PKI July 2004
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. Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished
to others, and derivative works that comment on or otherwise
explain it or assist in its implmentation may be prepared, copied,
published and distributed, in whole or in part, without
restriction of any kind, provided that the above copyright notice
and this paragraph are included on all such copies and derivative
works. However, this document itself may not be modified in any
way, such as by removing the copyright notice or references to the
Internet Society or other Internet organizations, except as needed
for the purpose of developing Internet standards in which case the
procedures for copyrights defined in the Internet Standards
process must be followed, or as required to translate it into
languages other than English.
The limited permissions granted above are perpetual and will not
be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on
an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS 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."
Lee, et. al. Expires - October 2004 [Page 6]
INTERNET-DRAFT User Interface Requirement for the PKI July 2004
5. Authors' Address
Hyangjin Lee
Korea Information Security Agency
Phone: +82-2-405-5448
FAX : +82-2-405-5499
Email: jiinii@kisa.or.kr
Tae Kyu Choi
Korea Information Security Agency
Phone: +82-2-405-5448
FAX : +82-2-405-5499
Email: tkchoi@kisa.or.kr
Inkyoung Jeon
Korea Information Security Agency
Phone: +82-2-405-5432
FAX : +82-2-405-5499
Email: inkyoung@kisa.or.kr
Jaeil Lee
Korea Information Security Agency
Phone: +82-2-405-5300
FAX : +82-2-405-5499
Email: jilee@kisa.or.kr
Lee, et. al. Expires - October 2004 [Page 7]