summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3709.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3709.txt')
-rw-r--r--doc/rfc/rfc3709.txt1179
1 files changed, 1179 insertions, 0 deletions
diff --git a/doc/rfc/rfc3709.txt b/doc/rfc/rfc3709.txt
new file mode 100644
index 0000000..4b1d467
--- /dev/null
+++ b/doc/rfc/rfc3709.txt
@@ -0,0 +1,1179 @@
+
+
+
+
+
+
+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:
+
+ - 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
+
+
+ - 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 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:
+
+ - Loyalty logotype
+ - 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:
+
+ - Contractual agreements of suitable behavior, including terms of
+ liability in case of material breach.
+
+ - Control mechanisms and procedures to monitor and follow-up
+ behavior of subordinate CAs.
+
+ - 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.
+
+ - 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]
+