draft-ietf-pkix-logotypes-09.txt

PKIX的RFC英文文档

PKIX Working Group                               S. Santesson (AddTrust)
INTERNET-DRAFT                             R. Housley (RSA Laboratories)
Expires June 2003                                 T. Freeman (Microsoft)
                                                           December 2002

               Internet X.509 Public Key Infrastructure:
                    Logotypes in X.509 certificates
                   <draft-ietf-pkix-logotypes-09.txt>

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   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 (C) The Internet Society (2002). All Rights Reserved.

Abstract

   This document specifies a certificate extension for including
   logotypes in public key certificates and attribute certificates.

   Please send comments on this document to the [e-mail]
   mailing list.













Santesson, Housley, & Freeman                                   [Page 1]

INTERNET DRAFT       Logotypes in X.509 Certificates       December 2002


   Table of Contents

   1 Introduction .................................................    3
     1.1 Certificate-based Identification .........................    4
     1.2 Selection of Certificates ................................    4
     1.3 Combination of Verification Techniques ...................    5
     1.4 Terminology ..............................................    6
   2 Different types of logotypes in Certificates .................    6
   3 Logotype data ................................................    7
   4 Logotype extension ...........................................    7
     4.1 Extension format .........................................    8
     4.2 Other Logotypes ..........................................   11
   5 Type of certificates .........................................   12
   6 Use in Clients ...............................................   12
   7 Security considerations ......................................   13
   8 References ...................................................   15
   A ASN.1 Module .................................................   16
   B Acknowledgments ..............................................   19
   C Author Addresses .............................................   19
































Santesson, Housley, & Freeman                                   [Page 2]

INTERNET DRAFT       Logotypes in X.509 Certificates       December 2002


1. Introduction

   This specification supplements RFC 3280 [PKIX-1], which profiles
   X.509 certificates and certificate revocation lists (CRLs) for use in
   the Internet.  The X.509 certificate and CRL definitions use ASN.1
   [X.208-88], the Basic Encoding Rules (BER) [X.209-88], and the
   Distinguished Encoding Rules (DER) [X.509-88].

   The basic function of a certificate is to bind a public key to the
   identity of an entity (the subject). From a strictly technical
   viewpoint, this goal could be achieved by signing the identity of the
   subject together with its public key. However, the art of PKI has
   developed certificates far beyond this functionality in order to meet
   the needs of modern global networks and heterogeneous IT structures.

   Certificate users must be able to determine certificate policies,
   appropriate key usage, assurance level, and name form constraints.
   Before a relying party can make an informed decision whether a
   particular certificate is trustworthy and relevant for its intended
   usage, a certificate may be examined from several different
   perspectives.

   Systematic processing is necessary to determine whether a particular
   certificate meets the predefined prerequisites for an intended usage.
   Much of the information contained in certificates is appropriate and
   effective for machine processing; however, this information is not
   suitable for a corresponding human trust and recognition process.

   Humans prefer to structure information into categories and symbols.
   Most humans associate complex structures of reality with easy
   recognizable logotypes and marks. Humans tend to trust things that
   they recognize from previous experiences. Humans may examine
   information to confirm their initial reaction. Very few consumers
   actually read all terms and conditions they accept when accepting a
   service, rather they commonly act on trust derived from previous
   experience and recognition.

   A big part of this process is branding. Service providers and product
   vendors invest a lot of money and resources into creating a strong
   relation between positive user experiences and easily recognizable
   trademarks, servicemarks, and logotypes.

   Branding is also pervasive in identification instruments, including
   identification cards, passports, driver's licenses, credit cards,
   gasoline cards, and loyalty cards. Identification instruments are
   intended to identify the holder as a particular person or as member
   of community. The community may represent the subscribers of a
   service or any other group. Identification instruments, in physical



Santesson, Housley, & Freeman                                   [Page 3]

INTERNET DRAFT       Logotypes in X.509 Certificates       December 2002


   form, commonly use logotypes and symbols, solely to enhance human
   recognition and trust in the identification instrument itself. They
   may also include a registered trademark to allow legal recourse for
   unauthorized duplication.

   Since certificates play an equivalent role in electronic exchanges,
   we examine the inclusion of logotypes in certificates. We consider
   certificate-based identification and certificate selection.

1.1. Certificate-based Identification

   The need for human recognition depends on the manner in which
   certificates are used and whether certificates need to be visible to
   human users. If certificates are to be used in open environments and
   in applications that bring the user in conscious contact with the
   result of a certificate-based identification process, then human
   recognition is highly relevant, and it may be a necessity.

   Examples of such applications include:

     - Web server identification where a user identifies the owner
       of the web site.
     - Peer e-mail exchange in B2B, B2C, and private communications.
     - Exchange of medical records, and system for medical
       prescriptions.
     - Unstructured e-business applications (i.e., non-EDI
       applications).
     - Wireless client authenticating to a service provider.

   Most applications provide the human user with an opportunity to view
   the results of a successful certificate-based identification process.
   When the user takes the steps necessary to view these results, the
   user is presented with a view of a certificate. This solution has two
   major problems.  First, the function to view a certificate is often
   rather hard to find for a non-technical user. Second, the
   presentation of the certificate is too technical and, it is not user
   friendly. It contains no graphic symbols or logotypes to enhance
   human recognition.

   Many investigations have shown that users of today's applications do
   not take the steps necessary to view certificates. This could be due
   to poor user interfaces. Further, many applications are structured to
   hide certificates from users.  The application designers do not want
   to expose certificates to users at all.

1.2. Selection of Certificates

   One situation where software applications must expose human users to



Santesson, Housley, & Freeman                                   [Page 4]

INTERNET DRAFT       Logotypes in X.509 Certificates       December 2002


   certificates is when the user must select a single certificate from a
   portfolio of certificates. In some cases, the software application
   can use information within the certificates to filter the list for
   suitability; however, the user must be queried if more than one
   certificate is suitable. The human user must select one of them.

   This situation is comparable to a person selecting a suitable plastic
   card from his wallet. In this situation, substantial assistance is
   provided by card color, location, and branding.

   In order to provide similar support for certificate selection, the
   users need tools to easily recognize and distinguish certificates.
   Introduction of logotypes into certificates provides the necessary
   graphic.

1.3. Combination of Verification Techniques

   The use of logotypes will in many cases affect the users decision to
   trust and use a certificate. It is therefore important that there is
   a distinct and clear architectural and functional distinction between
   the processes and objectives of the automated certificate
   verification and human recognition.

   Since logotypes are only aimed for human interpretation and contain
   data that is inappropriate for computer based verification schemes,
   the logotype extension MUST NOT be an active component in automated
   certification path validation.

   Automated certification path verification determines whether the end-
   entity certificate can be verified according to defined policy. The
   algorithm for this verification is specified in RFC 3280 [PKIX-1].

   The automated processing provides assurance that the certificate is
   valid. It does not indicate whether the subject is entitled to any
   particular information or whether the subject ought to be trusted to
   perform a particular service. These are access control decisions.
   Automatic processing will make some access control decisions, but
   others, depending on the application context, involve the human user.

   In some situations, where automated procedures have failed to
   establish the suitability of the certificate to the task, the human
   user is the final arbitrator of the post certificate verification
   access control decisions. In the end, the human will decide whether
   or not to accept an executable email attachment, to release personal
   information, or follow the instructions displayed by a web browser.
   This decision will often be based on recognition and previous
   experience.




Santesson, Housley, & Freeman                                   [Page 5]

INTERNET DRAFT       Logotypes in X.509 Certificates       December 2002


   The distinction between systematic processing and human processing is
   rather straightforward. They can be complementary. While the
   systematic process is focused on certification path construction and
   verification, the human acceptance process is focused on recognition
   and related previous experience.

   There are some situations where systematic processing and human
   processing interfere with each other.  These issues are discussed in
   the Security Considerations section.

1.4. Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [STDWORDS].

2. Different Types of Logotypes in Certificates

   This specification defines the inclusion of three standard logotype
   types.

     1) Community logotype
     2) Issuer organization logotype
     3) Subject organization logotype

   The community logotype - is the general mark for a community. It
   identifies a service concept for entity identification and
   certificate issuance. Many issuers may use a community logotype to
   co-brand with a global community in order to gain global recognition
   of its local service provision. This type of community branding is
   very common in the credit card business where local independent card
   issuers include a globally recognized brand (such as VISA and
   MasterCard).

   Issuer organization logotype - is a logotype representing the
   organization identified as part of the issuer name in the
   certificate.

   Subject organization logotype - is a logotype representing the
   organization identified in the subject name in the certificate.

   In addition to the standard logotype types this specification
   accommodates inclusion of other logotype types where each class of
   logotype is defined by an object identifier. The object identifier
   can be either locally defined or an identifier defined in section 4.2
   of this standard.





Santesson, Housley, & Freeman                                   [Page 6]

INTERNET DRAFT       Logotypes in X.509 Certificates       December 2002


3. Logotype data

   This specification defines two types of logotype data: image data and
   audio data. Implementations MUST support image data; however, support
   for audio data is OPTIONAL.

   There is no need to significantly increase the size of the
   certificate by including image and audio data of logotypes. Rather, a
   URI identifying the location to the logotype data and a one-way hash
   of the referenced data is included in the certificate.

   Several image files, representing the same image in different
   formats, sizes, and color palates, may represent each logotype image.
   At least one of the image files representing a logotype SHOULD
   contain an image within the size range of 60 pixels wide by 45 pixels
   high and 200 pixels wide by 150 pixels high.

   Several audio files may further represent the same audio sequence in
   different formats and resolutions. At least one of the audio files
   representing a logotype SHOULD have a play time between 2 and 30
   seconds.

   If a logotype is represented by more than one image file, then the
   image files MUST contain variants of the roughly the same image.
   Likewise, if a logotype is represented by more than one audio file,
   then the audio files MUST contain variants of the roughly the same
   audio sequence. Compliant applications MUST display one or none of
   the images and play one or none of the audio sequences at the same
   time.

   Each logotype present in a certificate MUST be represented by at
   least one image data file.

   Applications SHOULD enhance processing and off-line functionality by