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 ietf-pkix@imc.org   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 .............................................   19Santesson, Housley, & Freeman                                   [Page 2]INTERNET DRAFT       Logotypes in X.509 Certificates       December 20021. 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 physicalSantesson, 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 toSantesson, 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 20023. 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