From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc3709.txt | 1179 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1179 insertions(+) create mode 100644 doc/rfc/rfc3709.txt (limited to 'doc/rfc/rfc3709.txt') 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] + -- cgit v1.2.3