GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc3709

Network Working Group S. Santesson Request for Comments: 3709 Microsoft Category: Standards Track R. Housley

                                                        Vigil Security
                                                            T. Freeman
                                                             Microsoft
                                                         February 2004
             Internet X.509 Public Key Infrastructure:
                  Logotypes in X.509 Certificates

Status of this Memo

 This document specifies an Internet standards track protocol for the
 Internet community, and requests discussion and suggestions for
 improvements.  Please refer to the current edition of the "Internet
 Official Protocol Standards" (STD 1) for the standardization state
 and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

 Copyright (C) The Internet Society (2004).  All Rights Reserved.

Abstract

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

Santesson, et al. Standards Track [Page 1] RFC 3709 Logotypes in X.509 Certificates February 2004

Table of Contents

 1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
     1.1.  Certificate-based Identification . . . . . . . . . . . .  3
     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. . . . . . . . . . . . . . . . . . . . . . . . .  6
 4.  Logotype Extension . . . . . . . . . . . . . . . . . . . . . .  7
     4.1.  Extension Format . . . . . . . . . . . . . . . . . . . .  7
     4.2.  Other Logotypes. . . . . . . . . . . . . . . . . . . . . 11
 5.  Type of Certificates . . . . . . . . . . . . . . . . . . . . . 12
 6.  Use in Clients . . . . . . . . . . . . . . . . . . . . . . . . 12
 7.  Security Considerations. . . . . . . . . . . . . . . . . . . . 13
 8.  IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 15
 9.  Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 15
 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
     10.1. Normative References . . . . . . . . . . . . . . . . . . 16
     10.2. Informative References . . . . . . . . . . . . . . . . . 16
 A.  ASN.1 Module . . . . . . . . . . . . . . . . . . . . . . . . . 17
 B.  Example Extension. . . . . . . . . . . . . . . . . . . . . . . 19
 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 21

1. Introduction

 This specification supplements RFC 3280 [PKIX-1], which profiles
 X.509 [X.509] certificates and certificate revocation lists (CRLs)
 for use in the Internet.
 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 Public-Key
 Infrastructure (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.

Santesson, et al. Standards Track [Page 2] RFC 3709 Logotypes in X.509 Certificates February 2004

 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 easily
 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 agree to in 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 a member
 of the community.  The community may represent the subscribers of a
 service or any other group.  Identification instruments, in physical
 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 may be a necessity.
 Examples of such applications include:
  1. Web server identification where a user identifies the owner of

the web site.

Santesson, et al. Standards Track [Page 3] RFC 3709 Logotypes in X.509 Certificates February 2004

  1. Peer e-mail exchange in B2B, B2C, and private communications.
  1. Exchange of medical records, and system for medical

prescriptions.

  1. Unstructured e-business applications (i.e., non-EDI

applications).

  1. 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 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
 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.

Santesson, et al. Standards Track [Page 4] RFC 3709 Logotypes in X.509 Certificates February 2004

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
 be 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.
 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.

Santesson, et al. Standards Track [Page 5] RFC 3709 Logotypes in X.509 Certificates February 2004

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 BCP 14, 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 document.

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.

Santesson, et al. Standards Track [Page 6] RFC 3709 Logotypes in X.509 Certificates February 2004

 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 1 and 30
 seconds.
 If a logotype of a certain type (as defined in section 2) is
 represented by more than one image file, then the image files MUST
 contain variants of roughly the same image.  Likewise, if a logotype
 of a certain type is represented by more than one audio file, then
 the audio files MUST contain variants of the same audio information.
 A spoken message in different languages is considered a variation of
 the same audio information.  Compliant applications MUST NOT display
 more than one of the images and MUST NOT play more than one of the
 audio sequences for any logotype type at the same time.
 A client MAY simultaneously display multiple logotypes of different
 logotype types.  For example, it may display one subject organization
 logotype while also displaying a community logotype, but it MUST NOT
 display multiple image variants of the same community logotype.
 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
 caching logotype data.

4. Logotype Extension

 This section specifies the syntax and semantics of the logotype
 extension.

4.1. Extension Format

 The logotype extension MAY be included in public key certificates
 [PKIX-1] or attribute certificates [PKIX-AC].  The logotype extension
 MUST be identified by the following object identifier:
    id-pe-logotype  OBJECT IDENTIFIER  ::=
       { iso(1) identified-organization(3) dod(6) internet(1)
         security(5) mechanisms(5) pkix(7) id-pe(1) 12 }
 This extension MUST NOT be marked critical.

Santesson, et al. Standards Track [Page 7] RFC 3709 Logotypes in X.509 Certificates February 2004

 Logotype data may be referenced through either direct or indirect
 addressing.  Clients MUST support both direct and indirect
 addressing.  Certificate issuing applications MUST support direct
 addressing, and certificate issuing applications SHOULD support
 indirect addressing.
 The direct addressing includes information about each logotype in the
 certificate, and URIs point to the image and audio data files.
 Direct addressing supports cases where just one or a few alternative
 images and audio files are referenced.
 The indirect addressing includes one reference to an external hashed
 data structure that contains information on the type, content, and
 location of each image and audio file.  Indirect addressing supports
 cases where each logotype is represented by many alternative audio or
 image files.
 Both direct and indirect addressing accommodate alternative URIs to
 obtain exactly the same item.  This opportunity for replication is
 intended to improve availability.  Therefore, if a client is unable
 to fetch the item from one URI, the client SHOULD try another URI in
 the sequence.  All URIs MUST use either the  HTTP scheme (http://...)
 or the FTP scheme (ftp://...) [URI].  At least one URI in each
 sequence MUST use the HTTP scheme.  Clients MUST support retrieval of
 referenced LogoTypeData with HTTP/1.1 [HTTP/1.1].  Clients MAY
 support retrieval using FTP [FTP].
 The logotype extension MUST have the following syntax:

LogotypeExtn ::= SEQUENCE {

 communityLogos  [0] EXPLICIT SEQUENCE OF LogotypeInfo OPTIONAL,
 issuerLogo      [1] EXPLICIT LogotypeInfo OPTIONAL,
 subjectLogo     [2] EXPLICIT LogotypeInfo OPTIONAL,
 otherLogos      [3] EXPLICIT SEQUENCE OF OtherLogotypeInfo OPTIONAL }

LogotypeInfo ::= CHOICE {

 direct          [0] LogotypeData,
 indirect        [1] LogotypeReference }

LogotypeData ::= SEQUENCE {

 image           SEQUENCE OF LogotypeImage OPTIONAL,
 audio           [1] SEQUENCE OF LogotypeAudio OPTIONAL }

LogotypeImage ::= SEQUENCE {

 imageDetails    LogotypeDetails,
 imageInfo       LogotypeImageInfo OPTIONAL }

Santesson, et al. Standards Track [Page 8] RFC 3709 Logotypes in X.509 Certificates February 2004

LogotypeAudio ::= SEQUENCE {

 audioDetails    LogotypeDetails,
 audioInfo       LogotypeAudioInfo OPTIONAL }

LogotypeDetails ::= SEQUENCE {

 mediaType       IA5String, -- MIME media type name and optional
                            -- parameters
 logotypeHash    SEQUENCE SIZE (1..MAX) OF HashAlgAndValue,
 logotypeURI     SEQUENCE SIZE (1..MAX) OF IA5String }

LogotypeImageInfo ::= SEQUENCE {

 type            [0] LogotypeImageType DEFAULT color,
 fileSize        INTEGER,  -- In octets
 xSize           INTEGER,  -- Horizontal size in pixels
 ySize           INTEGER,  -- Vertical size in pixels
 resolution      LogotypeImageResolution OPTIONAL,
 language        [4] IA5String OPTIONAL }  -- RFC 3066 Language Tag

LogotypeImageType ::= INTEGER { grayScale(0), color(1) }

LogotypeImageResolution ::= CHOICE {

 numBits         [1] INTEGER,   -- Resolution in bits
 tableSize       [2] INTEGER }  -- Number of colors or grey tones

LogotypeAudioInfo ::= SEQUENCE {

 fileSize        INTEGER,  -- In octets
 playTime        INTEGER,  -- In milliseconds
 channels        INTEGER,  -- 1=mono, 2=stereo, 4=quad
 sampleRate      [3] INTEGER OPTIONAL,  -- Samples per second
 language        [4] IA5String OPTIONAL }  -- RFC 3066 Language Tag

OtherLogotypeInfo ::= SEQUENCE {

 logotypeType    OBJECT IDENTIFIER,
 info            LogotypeInfo }

LogotypeReference ::= SEQUENCE {

 refStructHash   SEQUENCE SIZE (1..MAX) OF HashAlgAndValue,
 refStructURI    SEQUENCE SIZE (1..MAX) OF IA5String }
                  -- Places to get the same "LTD" file

HashAlgAndValue ::= SEQUENCE {

 hashAlg         AlgorithmIdentifier,
 hashValue       OCTET STRING }
 When using indirect addressing, the URI (refStructURI) pointing to
 the external data structure MUST point to a binary file containing
 the DER encoded data with the syntax LogotypeData.  The referenced
 file name SHOULD include a file extension of "LTD".

Santesson, et al. Standards Track [Page 9] RFC 3709 Logotypes in X.509 Certificates February 2004

 At least one of the optional elements in the LogotypeExtn structure
 MUST be present.  Avoid the use of otherLogos whenever possible.
 The LogotypeReference and LogotypeDetails structures explicitly
 identify one or more one-way hash functions employed to authenticate
 referenced data files.  Clients MUST support the SHA-1 [SHS] one-way
 hash function, and clients MAY support other one-way hash functions.
 CAs MUST include a SHA-1 hash value for each referenced file,
 calculated on the whole file, and CAs MAY include other one-way hash
 values.  Clients MUST compute a one-way hash value using one of the
 identified functions, and clients MUST discard the logotype data if
 the computed one-way hash function value does not match the one-way
 hash function value in the certificate extension.
 A MIME type is used to specify the format of the file containing the
 logotype data.  Implementations MUST support both the JPEG and GIF
 image formats (with MIME types of "image/jpeg" and "image/gif"
 [MEDIA], respectively).  Animated images SHOULD NOT be used.
 Implementations that support audio MUST support the MP3 audio format
 (with a MIME type of "audio/mpeg" [AUDIO/MPEG]).  MIME types MAY
 include parameters.
 When language is specified, the language tag MUST use the RFC 3066
 [LANGCODES] syntax.
 Logotype types defined in this specification are:
    Community Logotype:  If communityLogos is present, the logotypes
    MUST represent one or more communities with which the certificate
    issuer is affiliated.  The communityLogos MAY be present in an end
    entity certificate, a CA certificate, or an attribute certificate.
    The communityLogos contains a sequence of Community Logotypes,
    each representing a different community.  If more than one
    Community logotype is present, they MUST be placed in order of
    preferred appearance.  Some clients MAY choose to display a subset
    of the present community logos; therefore the placement within the
    sequence aids the client selection.  The most preferred logotype
    MUST be first in the sequence, and the least preferred logotype
    MUST be last in the sequence.
    Issuer Organization Logotype:  If issuerLogo is present, the
    logotype MUST represent the issuer's organization.  The logotype
    MUST be consistent with, and require the presence of, an
    organization name stored in the organization attribute in the
    issuer field (for either a public key certificate or attribute
    certificate).  The issuerLogo MAY be present in an end entity
    certificate, a CA certificate, or an attribute certificate.

Santesson, et al. Standards Track [Page 10] RFC 3709 Logotypes in X.509 Certificates February 2004

    Subject Organization Logotype:  If subjectLogo is present, the
    logotype MUST represent the subject's organization.  The logotype
    MUST be consistent with, and require the presence of, an
    organization name stored in the organization attribute in the
    subject field (for either a public key certificate or attribute
    certificate).  The subjectLogo MAY be present in an end entity
    certificate, a CA certificate, or an attribute certificate.
 The relationship between the subject organization and the subject
 organization logotype, and the relationship between the issuer and
 either the issuer organization logotype or the community logotype,
 are relationships asserted by the issuer.  The policies and practices
 employed by the issuer to check subject organization logotypes or
 claims its issuer and community logotypes is outside the scope of
 this document.

4.2. Other Logotypes

 Logotypes identified by otherLogos (as defined in 4.1) can be used to
 enhance the display of logotypes and marks that represent partners,
 products, services, or any other characteristic associated with the
 certificate or its intended application environment when the standard
 logotype types are insufficient.
 The conditions and contexts of the intended use of these logotypes
 are defined at the discretion of the local client application.
 The following other logotype types are defined in this document:
  1. Loyalty logotype
  2. Certificate Background logotype
 OID Definitions:
       id-logo OBJECT IDENTIFIER ::= { id-pkix 20 }
       id-logo-loyalty    OBJECT IDENTIFIER ::= { id-logo 1 }
       id-logo-background OBJECT IDENTIFIER ::= { id-logo 2 }
 A loyalty logotype, if present, MUST contain a logotype associated
 with a loyalty program related to the certificate or its use.  The
 relation between the certificate and the identified loyalty program
 is beyond the scope of this document.  The logotype extension MAY
 contain more than one Loyalty logotype.

Santesson, et al. Standards Track [Page 11] RFC 3709 Logotypes in X.509 Certificates February 2004

 The certificate background logotype, if present, MUST contain a
 graphical image intended as a background image for the certificate,
 and/or a general audio sequence for the certificate.  The background
 image MUST allow black text to be clearly read when placed on top of
 the background image.  The logotype extension MUST NOT contain more
 than one certificate background logotype.

5. Type of Certificates

 Logotypes MAY be included in public key certificates and attribute
 certificates at the discretion of the certificate issuer; however,
 logotypes MUST NOT be part of certification path validation or any
 type of automated processing.  The sole purpose of logotypes is to
 enhance the display of a particular certificate, regardless of its
 position in a certification path.

6. Use in Clients

 All PKI implementations require relying party software to have some
 mechanism to determine whether a trusted CA issues a particular
 certificate.  This is an issue for certification path validation,
 including consistent policy and name checking.
 After a certification path is successfully validated, the replying
 party trusts the information that the CA includes in the certificate,
 including any certificate extensions.  The client software can choose
 to make use of such information, or the client software can ignore
 it.  If the client is unable to support a provided logotype, the
 client MUST NOT report an error, rather the client MUST behave as
 though no logotype extension was included in the certificate.
 Current standards do not provide any mechanism for cross-certifying
 CAs to constrain subordinate CAs from including private extensions
 (see the security considerations section).
 Consequently, if relying party software accepts a CA, then it should
 be prepared to (unquestioningly) display the associated logotypes to
 its human user, given that it is configured to do so.  Information
 about the logotypes is provided so that the replying party software
 can select the one that will best meet the needs of the human user.
 This choice depends on the abilities of the human user, as well as
 the capabilities of the platform on which the replaying party
 software is running.  If none of the provided logotypes meets the
 needs of the human user or matches the capabilities of the platform,
 then the logotypes can be ignored.
 A client MAY, subject to local policy, choose to display none, one,
 or any number of the logotypes in the logotype extension.

Santesson, et al. Standards Track [Page 12] RFC 3709 Logotypes in X.509 Certificates February 2004

 In many cases, a client will be used in an environment with a good
 network connection and also used in an environment with little or no
 network connectivity.  For example, a laptop computer can be docked
 with a high-speed LAN connection, or it can be disconnected from the
 network altogether.  In recognition of this situation, the client
 MUST include the ability to disable the fetching of logotypes.
 However, locally cached logotypes can still be displayed when the
 user disables the fetching of additional logotypes.
 A client MAY, subject to local policy, choose any combination of
 audio and image presentation for each logotype.  That is, the client
 MAY display an image with or without playing a sound, and it MAY play
 a sound with or without displaying an image.  A client MUST NOT play
 more than one logotype audio sequence at the same time.
 The logotype is to be displayed in conjunction with other identity
 information contained in the certificate.  The logotype is not a
 replacement for this identity information.
 Care is needed when designing replying party software to ensure that
 an appropriate context of logotype information is provided.  This is
 especially difficult with audio logotypes.  It is important that the
 human user be able to recognize the context of the logotype, even if
 other audio streams are being played.
 If the relying party software is unable to successfully validate a
 particular certificate, then it MUST NOT display any logotype data
 associated with that certificate.

7. Security Considerations

 Implementations that simultaneously display multiple logotype types
 (subject organization, issuer, community or other), MUST ensure that
 there is no ambiguity as to the binding between the image and the
 type of logotype that the image represents.  "Logotype type" is
 defined in section 2, and it refers to the type of entity or
 affiliation represented by the logotype, not the type of binary
 format.
 Logotypes are very difficult to securely and accurately define.
 Names are also difficult in this regard, but logotypes are even
 worse.  It is quite difficult to specify what is, and what is not, a
 legitimate logotype of an organization.  There is an entire legal
 structure around this issue, and it will not be repeated here.
 However, issuers should be aware of the implications of including
 images associated with a trademark or servicemark before doing so.

Santesson, et al. Standards Track [Page 13] RFC 3709 Logotypes in X.509 Certificates February 2004

 As logotypes can be difficult (and sometimes expensive) to verify,
 the possibility of errors related to assigning wrong logotypes to
 organizations is increased.
 This is not a new issue for electronic identification instruments.
 It is already dealt with in a number of similar situations in the
 physical world, including physical employee identification cards.
 Secondly, there are situations where identification of logotypes is
 rather simple and straightforward, such as logotypes for well-known
 industries and institutes.  These issues should not stop those
 service providers who want to issue logotypes from doing so, where
 relevant.
 It is impossible to prevent fraudulent creation of certificates by
 dishonest or badly performing issuers, containing names and logotypes
 that the issuer has no claim to or has failed to check correctly.
 Such certificates could be created in an attempt to socially engineer
 a user into accepting a certificate.  The premise used for the
 logotype work is thus that logotype graphics in a certificate are
 trusted only if the certificate is successfully validated within a
 valid path.  It is thus imperative that the representation of any
 certificate that fails to validate is not enhanced in any way by
 using the logotype graphic.
 Logotype data is fetched from a server when it is needed.  By
 watching activity on the network, an observer can determine which
 clients are making use of certificates that contain particular
 logotype data.  This observation can potentially introduce privacy
 issues.  Since clients are expected to locally cache logotype data,
 network traffic to the server containing the logotype data will not
 be generated every time the certificate is used.  In cases where
 logotype data is not cashed, monitoring would reveal usage frequency.
 In cases where logotype data is cached, monitoring would reveal when
 a certain logotype image or audio sequence is used for the first
 time.
 Certification paths may also impose name constraints that are
 systematically checked during certification path processing, which,
 in theory, may be circumvented by logotypes.
 Certificate path processing as defined in RFC 3280 [PKIX-1] does not
 constrain the inclusion of logotype data in certificates.  A parent
 CA can constrain certification path validation such that subordinate
 CAs cannot issue valid certificates to end-entities outside a limited
 name space or outside specific certificate polices.  A malicious CA
 can comply with these name and policy requirements and still include
 inappropriate logotypes in the certificates that it issues.  These
 certificates will pass the certification path validation algorithm,

Santesson, et al. Standards Track [Page 14] RFC 3709 Logotypes in X.509 Certificates February 2004

 which means the client will trust the logotypes in the certificates.
 Since there is no technical mechanism to prevent or control
 subordinate CAs from including the logotype extension or its
 contents, where appropriate, a parent CA could employ a legal
 agreement to impose a suitable restriction on the subordinate CA.
 This situation is not unique to the logotype extension.
 The controls available to a parent CA to protect itself from rogue
 subordinate CAs are non-technical.  They include:
  1. Contractual agreements of suitable behavior, including terms of

liability in case of material breach.

  1. Control mechanisms and procedures to monitor and follow-up

behavior of subordinate CAs.

  1. Use of certificate policies to declare an assurance level of

logotype data, as well as to guide applications on how to treat

       and display logotypes.
  1. Use of revocation functions to revoke any misbehaving CA.
 There is not a simple, straightforward, and absolute technical
 solution.  Rather, involved parties must settle some aspects of PKI
 outside the scope of technical controls.  As such, issuers need to
 clearly identify and communicate the associated risks.

8. IANA Considerations

 Certificate extensions and attribute certificate extensions are
 identified by object identifiers (OIDs).  The OID for the extension
 defined in this document was assigned from an arc delegated by the
 IANA to the PKIX Working Group.  No further action by the IANA is
 necessary for this document or any anticipated updates.

9. Acknowledgments

 This document is the result of contributions from many professionals.
 The authors appreciate contributions from all members of the IETF
 PKIX Working Group.  We extend a special thanks to Al Arsenault,
 David Cross, Tim Polk, Russel Weiser, Terry Hayes, Alex Deacon,
 Andrew Hoag, Randy Sabett, Denis Pinkas, Magnus Nystrom, Ryan Hurst,
 and Phil Griffin for their efforts and support.
 Russ Housley thanks the management at RSA Laboratories, especially
 Burt Kaliski, who supported the development of this specification.
 The vast majority of the work on this specification was done while
 Russ was employed at RSA Laboratories.

Santesson, et al. Standards Track [Page 15] RFC 3709 Logotypes in X.509 Certificates February 2004

10. References

10.1. Normative References

 [LANGCODES]  Alvestrand, H., "Tags for Identification of Languages",
              BCP 47, RFC 3066, January 2001.
 [PKIX-1]     Housley, R., Polk, W., Ford, W. and D. Solo, "Internet
              X.509 Public Key Infrastructure: Certificate and
              Certificate Revocation List (CRL) Profile", RFC 3280,
              April 2002.
 [PKIX-AC]    Farrell, S. and R. Housley, "An Internet Attribute
              Certificate Profile for Authorization", RFC 3281, April
              2002.
 [SHS]        Federal Information Processing Standards Publication
              (FIPS PUB) 180-1, Secure Hash Standard, 17 April 1995.
              [Supersedes FIPS PUB 180 dated 11 May 1993.]
 [STDWORDS]   Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.
 [HTTP/1.1]   Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
              Masinter, L., Leach P. and T. Berners-Lee, "Hypertext
              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
 [FTP]        Postel, J. and J. Reynolds, "File Transfer Protocol",
              STD 9, RFC 959, October 1985.
 [URI]        Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
              Resource Identifiers (URI): Generic Syntax", RFC 2396,
              August 1998.
 [MEDIA]      Freed, N. and N. Borenstein, "Multipurpose Internet Mail
              Extensions (MIME) Part Two: Media Types", RFC 2046,
              November 1996.
 [AUDIO/MPEG] Nilsson, M., "The audio/mpeg Media Type", RFC 3003,
              November 2000.

10.2. Informative References

 [X.509]      ITU-T Recommendation X.509 (2000) | ISO/IEC 9594-8:2001,
              Information technology - Open Systems Interconnection -
              The Directory: Public-key and attribute certificate
              frameworks

Santesson, et al. Standards Track [Page 16] RFC 3709 Logotypes in X.509 Certificates February 2004

APPENDIX A. ASN.1 Module

LogotypeCertExtn

{ iso(1) identified-organization(3) dod(6) internet(1)
  security(5) mechanisms(5) pkix(7) id-mod(0)
  id-mod-logotype(22) }

DEFINITIONS IMPLICIT TAGS ::= BEGIN

IMPORTS

 AlgorithmIdentifier FROM PKIX1Explicit88 -- RFC 3280
   { iso(1) identified-organization(3) dod(6) internet(1)
     security(5) mechanisms(5) pkix(7) id-mod(0)
     id-pkix1-explicit(18) };

– Logotype Extension OID

id-pe-logotype OBJECT IDENTIFIER ::=

 { iso(1) identified-organization(3) dod(6) internet(1)
   security(5) mechanisms(5) pkix(7) id-pe(1) 12 }

– Logotype Extension Syntax

LogotypeExtn ::= SEQUENCE {

 communityLogos  [0] EXPLICIT SEQUENCE OF LogotypeInfo OPTIONAL,
 issuerLogo      [1] EXPLICIT LogotypeInfo OPTIONAL,
 subjectLogo     [2] EXPLICIT LogotypeInfo OPTIONAL,
 otherLogos      [3] EXPLICIT SEQUENCE OF OtherLogotypeInfo OPTIONAL }

LogotypeInfo ::= CHOICE {

 direct          [0] LogotypeData,
 indirect        [1] LogotypeReference }

LogotypeData ::= SEQUENCE {

 image           SEQUENCE OF LogotypeImage OPTIONAL,
 audio           [1] SEQUENCE OF LogotypeAudio OPTIONAL }

LogotypeImage ::= SEQUENCE {

 imageDetails    LogotypeDetails,
 imageInfo       LogotypeImageInfo OPTIONAL }

LogotypeAudio ::= SEQUENCE {

 audioDetails    LogotypeDetails,
 audioInfo       LogotypeAudioInfo OPTIONAL }

Santesson, et al. Standards Track [Page 17] RFC 3709 Logotypes in X.509 Certificates February 2004

LogotypeDetails ::= SEQUENCE {

 mediaType       IA5String, -- MIME media type name and optional
                            -- parameters
 logotypeHash    SEQUENCE SIZE (1..MAX) OF HashAlgAndValue,
 logotypeURI     SEQUENCE SIZE (1..MAX) OF IA5String }

LogotypeImageInfo ::= SEQUENCE {

 type            [0] LogotypeImageType DEFAULT color,
 fileSize        INTEGER,  -- In octets
 xSize           INTEGER,  -- Horizontal size in pixels
 ySize           INTEGER,  -- Vertical size in pixels
 resolution      LogotypeImageResolution OPTIONAL,
 language        [4] IA5String OPTIONAL }  -- RFC 3066 Language Tag

LogotypeImageType ::= INTEGER { grayScale(0), color(1) }

LogotypeImageResolution ::= CHOICE {

 numBits         [1] INTEGER,   -- Resolution in bits
 tableSize       [2] INTEGER }  -- Number of colors or grey tones

LogotypeAudioInfo ::= SEQUENCE {

 fileSize        INTEGER,  -- In octets
 playTime        INTEGER,  -- In milliseconds
 channels        INTEGER,  -- 1=mono, 2=stereo, 4=quad
 sampleRate      [3] INTEGER OPTIONAL,  -- Samples per second
 language        [4] IA5String OPTIONAL }  -- RFC 3066 Language Tag

OtherLogotypeInfo ::= SEQUENCE {

 logotypeType    OBJECT IDENTIFIER,
 info            LogotypeInfo }

LogotypeReference ::= SEQUENCE {

 refStructHash   SEQUENCE SIZE (1..MAX) OF HashAlgAndValue,
 refStructURI    SEQUENCE SIZE (1..MAX) OF IA5String }
                    -- Places to get the same "LTD" file

– Note: The content of referenced "LTD" files is defined by the – LogotypeData type

HashAlgAndValue ::= SEQUENCE {

 hashAlg         AlgorithmIdentifier,
 hashValue       OCTET STRING }

– Other logotype type OIDs

id-logo OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)

 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 20 }

Santesson, et al. Standards Track [Page 18] RFC 3709 Logotypes in X.509 Certificates February 2004

id-logo-loyalty OBJECT IDENTIFIER ::= { id-logo 1 }

id-logo-background OBJECT IDENTIFIER ::= { id-logo 2 }

END

APPENDIX B. Example Extension

 The following example displays a logotype extension containing one
 Issuer logotype using direct addressing.  The issuer logotype image
 is of the type image/gif.  The logotype image file is referenced
 through 1 URI and the image is hashed by one sha1 hash value.
 The values on the left are the ASN.1 tag and length, in hexadecimal.

30 106: SEQUENCE { 06 8: OBJECT IDENTIFIER '1 3 6 1 5 5 7 1 12' 04 94: OCTET STRING, encapsulates { 30 92: SEQUENCE { A1 90: [1] { A0 88: [0] { 30 86: SEQUENCE { 30 84: SEQUENCE { 30 82: SEQUENCE { 16 9: IA5String 'image/gif' 30 33: SEQUENCE { 30 31: SEQUENCE { 30 7: SEQUENCE { 06 5: OBJECT IDENTIFIER sha1 (1 3 14 3 2 26)

     :                       }

04 20: OCTET STRING

     :           8F E5 D3 1A 86 AC 8D 8E 6B C3 CF 80 6A D4 48 18
     :           2C 7B 19 2E
     :                     }
     :                   }

30 34: SEQUENCE { 16 32: IA5String 'http://logo.example.com/logo.gif'

     :                   }
     :                 }
     :               }
     :             }
     :           }
     :         }
     :       }
     :     }
     :   }

Santesson, et al. Standards Track [Page 19] RFC 3709 Logotypes in X.509 Certificates February 2004

Authors' Addresses

 Stefan Santesson
 Microsoft Denmark
 Tuborg Boulevard 12
 DK-2900 Hellerup
 Denmark
 EMail: stefans@microsoft.com
 Russell Housley
 Vigil Security, LLC
 918 Spring Knoll Drive
 Herndon, VA 20170
 USA
 EMail: housley@vigilsec.com
 Trevor Freeman
 Microsoft Corporation
 One Microsoft Way
 Redmond WA 98052
 USA
 EMail: trevorf@microsoft.com

Santesson, et al. Standards Track [Page 20] RFC 3709 Logotypes in X.509 Certificates February 2004

Full 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.
 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.

Intellectual Property

 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 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.

Acknowledgement

 Funding for the RFC Editor function is currently provided by the
 Internet Society.

Santesson, et al. Standards Track [Page 21]

/data/webs/external/dokuwiki/data/pages/rfc/rfc3709.txt · Last modified: 2004/02/17 20:55 (external edit)