idnits 2.17.1 draft-ietf-pkix-logotypes-13.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Authors' Addresses Section. ** There are 11 instances of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The first octets (the first characters of the first line) of this draft are 'PK', which can make Internet Explorer erroneously think that it is a zip file. It is recommended that you change this, for instance by inserting a blank line before the line starting with 'PK'. == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 2003) is 7428 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'PKIX-AC' is mentioned on line 307, but not defined -- Looks like a reference, but probably isn't: '0' on line 866 -- Looks like a reference, but probably isn't: '1' on line 865 -- Looks like a reference, but probably isn't: '2' on line 817 -- Looks like a reference, but probably isn't: '3' on line 823 -- Looks like a reference, but probably isn't: '4' on line 824 == Unused Reference: 'CMS' is defined on line 747, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3066 (ref. 'LANGCODES') (Obsoleted by RFC 4646, RFC 4647) ** Obsolete normative reference: RFC 3280 (ref. 'PKIX-1') (Obsoleted by RFC 5280) -- Possible downref: Non-RFC (?) normative reference: ref. 'SHS' ** Obsolete normative reference: RFC 2396 (ref. 'URI') (Obsoleted by RFC 3986) -- Obsolete informational reference (is this intentional?): RFC 3369 (ref. 'CMS') (Obsoleted by RFC 3852) Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PKIX Working Group S. Santesson (Microsoft) 2 INTERNET-DRAFT R. Housley (Vigil Security) 3 Expires June 2004 T. Freeman (Microsoft) 4 December 2003 6 Internet X.509 Public Key Infrastructure: 7 Logotypes in X.509 certificates 8 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that other 17 groups may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Copyright (C) The Internet Society (2002). All Rights Reserved. 32 Abstract 34 This document specifies a certificate extension for including 35 logotypes in public key certificates and attribute certificates. 37 Please send comments on this document to the ietf-pkix@imc.org 38 mailing list. 40 Table of Contents 42 1 Introduction ................................................ 3 43 1.1 Certificate-based Identification ........................ 4 44 1.2 Selection of Certificates ............................... 4 45 1.3 Combination of Verification Techniques .................. 5 46 1.4 Terminology ............................................. 6 47 2 Different types of logotypes in Certificates ................ 6 48 3 Logotype data ............................................... 7 49 4 Logotype extension .......................................... 7 50 4.1 Extension format ........................................ 8 51 4.2 Other Logotypes ......................................... 11 52 5 Type of certificates ........................................ 12 53 6 Use in Clients .............................................. 12 54 7 Security considerations ..................................... 13 55 8 IANA Considerations ......................................... 15 56 9 IPR Considerations .......................................... 15 57 10 References .................................................. 16 58 A ASN.1 Module ................................................ 18 59 B Example Extension ........................................... 21 60 C Acknowledgments ............................................. 22 61 D Author Addresses ............................................ 22 62 Full Copyright Statement ....................................... 23 64 1. Introduction 66 This specification supplements RFC 3280 [PKIX-1], which profiles 67 X.509 certificates and certificate revocation lists (CRLs) for use in 68 the Internet. The X.509 certificate and CRL definitions use ASN.1 69 [X.208-88], the Basic Encoding Rules (BER) [X.209-88], and the 70 Distinguished Encoding Rules (DER) [X.509-88]. 72 The basic function of a certificate is to bind a public key to the 73 identity of an entity (the subject). From a strictly technical 74 viewpoint, this goal could be achieved by signing the identity of the 75 subject together with its public key. However, the art of PKI has 76 developed certificates far beyond this functionality in order to meet 77 the needs of modern global networks and heterogeneous IT structures. 79 Certificate users must be able to determine certificate policies, 80 appropriate key usage, assurance level, and name form constraints. 81 Before a relying party can make an informed decision whether a 82 particular certificate is trustworthy and relevant for its intended 83 usage, a certificate may be examined from several different 84 perspectives. 86 Systematic processing is necessary to determine whether a particular 87 certificate meets the predefined prerequisites for an intended usage. 88 Much of the information contained in certificates is appropriate and 89 effective for machine processing; however, this information is not 90 suitable for a corresponding human trust and recognition process. 92 Humans prefer to structure information into categories and symbols. 93 Most humans associate complex structures of reality with easy 94 recognizable logotypes and marks. Humans tend to trust things that 95 they recognize from previous experiences. Humans may examine 96 information to confirm their initial reaction. Very few consumers 97 actually read all terms and conditions they accept when accepting a 98 service, rather they commonly act on trust derived from previous 99 experience and recognition. 101 A big part of this process is branding. Service providers and product 102 vendors invest a lot of money and resources into creating a strong 103 relation between positive user experiences and easily recognizable 104 trademarks, servicemarks, and logotypes. 106 Branding is also pervasive in identification instruments, including 107 identification cards, passports, driver's licenses, credit cards, 108 gasoline cards, and loyalty cards. Identification instruments are 109 intended to identify the holder as a particular person or as member 110 of community. The community may represent the subscribers of a 111 service or any other group. Identification instruments, in physical 112 form, commonly use logotypes and symbols, solely to enhance human 113 recognition and trust in the identification instrument itself. They 114 may also include a registered trademark to allow legal recourse for 115 unauthorized duplication. 117 Since certificates play an equivalent role in electronic exchanges, 118 we examine the inclusion of logotypes in certificates. We consider 119 certificate-based identification and certificate selection. 121 1.1. Certificate-based Identification 123 The need for human recognition depends on the manner in which 124 certificates are used and whether certificates need to be visible to 125 human users. If certificates are to be used in open environments and 126 in applications that bring the user in conscious contact with the 127 result of a certificate-based identification process, then human 128 recognition is highly relevant, and it may be a necessity. 130 Examples of such applications include: 132 - Web server identification where a user identifies the owner 133 of the web site. 134 - Peer e-mail exchange in B2B, B2C, and private communications. 135 - Exchange of medical records, and system for medical 136 prescriptions. 137 - Unstructured e-business applications (i.e., non-EDI 138 applications). 139 - Wireless client authenticating to a service provider. 141 Most applications provide the human user with an opportunity to view 142 the results of a successful certificate-based identification process. 143 When the user takes the steps necessary to view these results, the 144 user is presented with a view of a certificate. This solution has two 145 major problems. First, the function to view a certificate is often 146 rather hard to find for a non-technical user. Second, the 147 presentation of the certificate is too technical and, it is not user 148 friendly. It contains no graphic symbols or logotypes to enhance 149 human recognition. 151 Many investigations have shown that users of today's applications do 152 not take the steps necessary to view certificates. This could be due 153 to poor user interfaces. Further, many applications are structured to 154 hide certificates from users. The application designers do not want 155 to expose certificates to users at all. 157 1.2. Selection of Certificates 159 One situation where software applications must expose human users to 160 certificates is when the user must select a single certificate from a 161 portfolio of certificates. In some cases, the software application 162 can use information within the certificates to filter the list for 163 suitability; however, the user must be queried if more than one 164 certificate is suitable. The human user must select one of them. 166 This situation is comparable to a person selecting a suitable plastic 167 card from his wallet. In this situation, substantial assistance is 168 provided by card color, location, and branding. 170 In order to provide similar support for certificate selection, the 171 users need tools to easily recognize and distinguish certificates. 172 Introduction of logotypes into certificates provides the necessary 173 graphic. 175 1.3. Combination of Verification Techniques 177 The use of logotypes will in many cases affect the users decision to 178 trust and use a certificate. It is therefore important that there is 179 a distinct and clear architectural and functional distinction between 180 the processes and objectives of the automated certificate 181 verification and human recognition. 183 Since logotypes are only aimed for human interpretation and contain 184 data that is inappropriate for computer based verification schemes, 185 the logotype extension MUST NOT be an active component in automated 186 certification path validation. 188 Automated certification path verification determines whether the end- 189 entity certificate can be verified according to defined policy. The 190 algorithm for this verification is specified in RFC 3280 [PKIX-1]. 192 The automated processing provides assurance that the certificate is 193 valid. It does not indicate whether the subject is entitled to any 194 particular information or whether the subject ought to be trusted to 195 perform a particular service. These are access control decisions. 196 Automatic processing will make some access control decisions, but 197 others, depending on the application context, involve the human user. 199 In some situations, where automated procedures have failed to 200 establish the suitability of the certificate to the task, the human 201 user is the final arbitrator of the post certificate verification 202 access control decisions. In the end, the human will decide whether 203 or not to accept an executable email attachment, to release personal 204 information, or follow the instructions displayed by a web browser. 205 This decision will often be based on recognition and previous 206 experience. 208 The distinction between systematic processing and human processing is 209 rather straightforward. They can be complementary. While the 210 systematic process is focused on certification path construction and 211 verification, the human acceptance process is focused on recognition 212 and related previous experience. 214 There are some situations where systematic processing and human 215 processing interfere with each other. These issues are discussed in 216 the Security Considerations section. 218 1.4. Terminology 220 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 221 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 222 document are to be interpreted as described in RFC 2119 [STDWORDS]. 224 2. Different Types of Logotypes in Certificates 226 This specification defines the inclusion of three standard logotype 227 types. 229 1) Community logotype 230 2) Issuer organization logotype 231 3) Subject organization logotype 233 The community logotype - is the general mark for a community. It 234 identifies a service concept for entity identification and 235 certificate issuance. Many issuers may use a community logotype to 236 co-brand with a global community in order to gain global recognition 237 of its local service provision. This type of community branding is 238 very common in the credit card business where local independent card 239 issuers include a globally recognized brand (such as VISA and 240 MasterCard). 242 Issuer organization logotype - is a logotype representing the 243 organization identified as part of the issuer name in the 244 certificate. 246 Subject organization logotype - is a logotype representing the 247 organization identified in the subject name in the certificate. 249 In addition to the standard logotype types this specification 250 accommodates inclusion of other logotype types where each class of 251 logotype is defined by an object identifier. The object identifier 252 can be either locally defined or an identifier defined in section 4.2 253 of this standard. 255 3. Logotype data 257 This specification defines two types of logotype data: image data and 258 audio data. Implementations MUST support image data; however, support 259 for audio data is OPTIONAL. 261 There is no need to significantly increase the size of the 262 certificate by including image and audio data of logotypes. Rather, a 263 URI identifying the location to the logotype data and a one-way hash 264 of the referenced data is included in the certificate. 266 Several image files, representing the same image in different 267 formats, sizes, and color palates, may represent each logotype image. 268 At least one of the image files representing a logotype SHOULD 269 contain an image within the size range of 60 pixels wide by 45 pixels 270 high and 200 pixels wide by 150 pixels high. 272 Several audio files may further represent the same audio sequence in 273 different formats and resolutions. At least one of the audio files 274 representing a logotype SHOULD have a play time between 1 and 30 275 seconds. 277 If a logotype of a certain type (as defined in section 2) is 278 represented by more than one image file, then the image files MUST 279 contain variants of roughly the same image. Likewise, if a logotype 280 of a certain type is represented by more than one audio file, then 281 the audio files MUST contain variants of the same audio information. 282 A spoken message in different languages is considered variants of the 283 same audio information. Compliant applications MUST NOT display more 284 than one of the images and MUST NOT play more than one of the audio 285 sequences for any logotype type at the same time. 287 A client MAY simultaneously display multiple logotypes of different 288 logotype types. For example, it may display one subject organization 289 logotype at the same time as displaying a community logotype, but it 290 MUST NOT display multiple image variants of the same community 291 logotype. 293 Each logotype present in a certificate MUST be represented by at 294 least one image data file. 296 Applications SHOULD enhance processing and off-line functionality by 297 caching logotype data. 299 4. Logotype extension 301 This section specifies the syntax and semantics of the logotype 302 extension. 304 4.1 Extension format 306 The logotype extension MAY be included in public key certificates 307 [PKIX-1] or attribute certificates [PKIX-AC]. The logotype extension 308 MUST be identified by the following object identifier: 310 id-pe-logotype OBJECT IDENTIFIER ::= 311 { iso(1) identified-organization(3) dod(6) internet(1) 312 security(5) mechanisms(5) pkix(7) id-pe(1) 12 } 314 This extension MUST NOT be marked critical. 316 Logotype data may be referenced through either direct or indirect 317 addressing. Clients MUST support both direct and indirect addressing. 318 Certificate issuing applications MUST support direct addressing, and 319 certificate issuing applications SHOULD support indirect addressing. 321 The direct addressing includes information about each logotype in the 322 certificate, and URIs point to the image and audio data files. Direct 323 addressing supports cases where just one or a few alternative images 324 and audio files are referenced. 326 The indirect addressing includes one reference to an external hashed 327 data structure that contains information on the type, content and 328 location of each image and audio file. Indirect addressing supports 329 cases where each logotype is represented by many alternative audio or 330 image files. 332 Both direct and indirect addressing accommodate alternative URIs to 333 obtain exactly the same item. This opportunity for replication is 334 intended to improve availability. Therefore, if a client is unable to 335 fetch the item from one URI, the client SHOULD try another URI in the 336 sequence. All URI MUST use either the HTTP scheme (http://...) or 337 the FTP scheme (ftp://...) [URI]. At least one URI in each sequence 338 MUST use the HTTP scheme. Clients MUST support retrieval of 339 referenced LogoTypeData with HTTP/1.1 [HTTP/1.1]. Clients MAY support 340 retrieval using FTP [FTP]. 342 The logotype extension MUST have the following syntax: 344 LogotypeExtn ::= SEQUENCE { 345 communityLogos [0] EXPLICIT SEQUENCE OF LogotypeInfo OPTIONAL, 346 issuerLogo [1] EXPLICIT LogotypeInfo OPTIONAL, 347 subjectLogo [2] EXPLICIT LogotypeInfo OPTIONAL, 348 otherLogos [3] EXPLICIT SEQUENCE OF OtherLogotypeInfo OPTIONAL } 350 LogotypeInfo ::= CHOICE { 351 direct [0] LogotypeData, 352 indirect [1] LogotypeReference } 354 LogotypeData ::= SEQUENCE { 355 image SEQUENCE OF LogotypeImage OPTIONAL, 356 audio [1] SEQUENCE OF LogotypeAudio OPTIONAL } 358 LogotypeImage ::= SEQUENCE { 359 imageDetails LogotypeDetails, 360 imageInfo LogotypeImageInfo OPTIONAL } 362 LogotypeAudio ::= SEQUENCE { 363 audioDetails LogotypeDetails, 364 audioInfo LogotypeAudioInfo OPTIONAL } 366 LogotypeDetails ::= SEQUENCE { 367 mediaType IA5String, -- MIME media type name and optional 368 -- parameters 369 logotypeHash SEQUENCE SIZE (1..MAX) OF HashAlgAndValue, 370 logotypeURI SEQUENCE SIZE (1..MAX) OF IA5String } 372 LogotypeImageInfo ::= SEQUENCE { 373 type [0] LogotypeImageType DEFAULT color, 374 fileSize INTEGER, -- In octets 375 xSize INTEGER, -- Horizontal size in pixels 376 ySize INTEGER, -- Vertical size in pixels 377 resolution LogotypeImageResolution OPTIONAL, 378 language [4] IA5String OPTIONAL } -- RFC 3066 Language Tag 380 LogotypeImageType ::= INTEGER { grayScale(0), color(1) } 382 LogotypeImageResolution ::= CHOICE { 383 numBits [1] INTEGER, -- Resolution in bits 384 tableSize [2] INTEGER } -- Number of colors or grey tones 386 LogotypeAudioInfo ::= SEQUENCE { 387 fileSize INTEGER, -- In octets 388 playTime INTEGER, -- In milliseconds 389 channels INTEGER, -- 1=mono, 2=stereo, 4=quad 390 sampleRate [3] INTEGER OPTIONAL, -- Samples per second 391 language [4] IA5String OPTIONAL } -- RFC 3066 Language Tag 393 OtherLogotypeInfo ::= SEQUENCE { 394 logotypeType OBJECT IDENTIFIER, 395 info LogotypeInfo } 397 LogotypeReference ::= SEQUENCE { 398 refStructHash SEQUENCE SIZE (1..MAX) OF HashAlgAndValue, 399 refStructURI SEQUENCE SIZE (1..MAX) OF IA5String } 400 -- Places to get the same "LTD" file 402 HashAlgAndValue ::= SEQUENCE { 403 hashAlg AlgorithmIdentifier, 404 hashValue OCTET STRING } 406 When using indirect addressing, the URI (refStructURI) pointing to 407 the external data structure MUST point to a binary file containing 408 the DER encoded data with the syntax LogotypeData. The referenced 409 file name SHOULD include a file extension of "LTD". 411 At least one of the optional elements in the LogotypeExtn structure 412 MUST be present. Avoid the use of otherLogos whenever possible. 414 The LogotypeReference and LogotypeDetails structures explicitly 415 identify one or more one-way hash functions employed to authenticate 416 referenced data files. Clients MUST support the SHA-1 [SHS] one-way 417 hash function, and clients MAY support other one-way hash functions. 418 CAs MUST include a SHA-1 hash value for each referenced file, 419 calculated on the whole file, and CAs MAY include other one-way hash 420 values. Clients MUST compute a one-way hash value using one of the 421 identified functions, and clients MUST discard the logotype data if 422 the computed one-way hash function value does not match the one-way 423 hash function value in the certificate extension. 425 A MIME type is used to specify the format of the file containing the 426 logotype data. Implementations MUST support both the JPEG and GIF 427 image formats (with MIME types of "image/jpeg" and "image/gif" 428 [MEDIA], respectively). Animated images SHOULD NOT be used. 429 Implementations that support audio MUST support the MP3 audio format 430 (with a MIME type of "audio/mpeg" [AUDIO/MPEG]). MIME types MAY 431 include parameters. 433 When language is specified, the language tag MUST use the RFC 3066 434 [LANGCODES] syntax. 436 Logotype types defined in this specification are: 438 Community Logotype. If communityLogos is present, the logotypes 439 MUST represent one or more communities to which the certificate 440 issuer is affiliated. The communityLogos MAY be present in an end 441 entity certificate, a CA certificate, or an attribute certificate. 442 The communityLogos contains a sequence of Community Logotypes, 443 each representing different community. If more than one Community 444 logotype is present, they MUST be placed in order of preferred 445 appearance. Some clients MAY choose to display a subset of the 446 present community logos, therefore the placement within the 447 sequence aids the client selection. The most preferred logotype 448 MUST be first in the sequence, and the least preferred logotype 449 MUST be last in the sequence. 451 Issuer Organization Logotype. If issuerLogo is present, the 452 logotype MUST represent the issuer's organization. The logotype 453 MUST be consistent with, and require the presence of, an 454 organization name stored in the organization attribute in the 455 issuer field (for either a public key certificate or attribute 456 certificate). The issuerLogo MAY be present in an end entity 457 certificate, a CA certificate, or an attribute certificate. 459 Subject Organization Logotype. If subjectLogo is present, the 460 logotype MUST represent the subject's organization. The logotype 461 MUST be consistent with, and require the presence of, an 462 organization name stored in the organization attribute in the 463 subject field (for either a public key certificate or attribute 464 certificate). The subjectLogo MAY be present in an end entity 465 certificate, a CA certificate, or an attribute certificate. 467 The relationship between the subject organization and the subject 468 organization logotype and the relationship between the issuer and 469 either the issuer organization logotype or the community logotype, 470 are relationships asserted by the issuer. The policies and practices 471 employed by the issuer to check subject organization logotypes or 472 claims its issuer and community logotypes is outside the scope of 473 this standard. 475 4.2 Other Logotypes 477 Logotypes identified by otherLogos (as defined in 4.1) can be used to 478 enhance display of logotypes and marks that represent partners, 479 products, services, or any other characteristic associated with the 480 certificate or its intended application environment when the standard 481 logotype types are insufficient. 483 The conditions and contexts of the intended use of these logotypes 484 are defined at the discretion of the local client application. 486 The following other logotype types are defined in this standard: 488 - Loyalty logotype 489 - Certificate Background logotype 491 OID Definitions: 493 id-logo OBJECT IDENTIFIER ::= { id-pkix 20 } 495 id-logo-loyalty OBJECT IDENTIFIER ::= { id-logo 1 } 496 id-logo-background OBJECT IDENTIFIER ::= { id-logo 2 } 498 A loyalty logotype, if present, MUST contain a logotype associated 499 with a loyalty program related to the certificate or its use. The 500 relation between the certificate and the identified loyalty program 501 is beyond the scope of this standard. The logotype extension MAY 502 contain more than one Loyalty logotype. 504 The certificate background logotype, if present, MUST contain a 505 graphical image intended as background image for the certificate, 506 and/or a general audio sequence for the certificate. The background 507 image MUST allow black text to be clearly read when placed on top of 508 the background image. The logotype extension MUST NOT contain more 509 than one certificate background logotype. 511 5. Type of certificates 513 Logotypes MAY be included in public key certificates and attribute 514 certificates at the discretion of the certificate issuer; however; 515 logotypes MUST NOT be part of certification path validation or any 516 type of automated processing. The sole purpose of logotypes is to 517 enhance display of a particular certificate, regardless of its 518 position in a certification path. 520 6. Use in Clients 522 All PKI implementations require relying party software to have some 523 mechanism to determine whether a trusted CA issues a particular 524 certificate. This is an issue for certification path validation, 525 including consistent policy and name checking. 527 After a certification path is successfully validated, the replying 528 party trusts the information that the CA includes in the certificate, 529 including any certificate extensions. The client software can choose 530 to make use of such information, or the client software can ignore 531 it. If client is unable to support a provided logotype, the client 532 MUST NOT report an error, rather the client MUST behave as though no 533 logotype extension was included in the certificate. Current standards 534 do not provide any mechanism for cross-certifying CAs to constrain 535 subordinate CAs from including private extensions (see the security 536 considerations section). 538 Consequently, if relying party software accepts a CA, then it should 539 be prepared to (unquestioningly) display the associated logotypes to 540 its human user, given that it is configured to do so. Information 541 about the logotypes is provided so that the replying party software 542 can select the one that will best meet the needs of the human user. 543 This choice depends on the abilities of the human user as well as the 544 capabilities of the platform on which the replaying party software is 545 running. If none of the provided logotypes meets the needs of the 546 human user or matches the capabilities of the platform, then the 547 logotypes can be ignored. 549 A client MAY, subject to local policy, choose to display none, one or 550 any number of the logotypes in the logotype extension. 552 In many cases, a client will be used in an environment with a good 553 network connection and also used in an environment with little or no 554 network connectivity. For example, a laptop computer can be docked 555 with a high-speed LAN connection, or it can be disconnected from the 556 network altogether. In recognition of this situation, the client MUST 557 include the ability to disable the fetching of logotypes. However, 558 locally cached logotypes can still be displayed when the user 559 disables the fetching of additional logotypes. 561 A client MAY, subject to local policy, choose any combination of 562 audio and image presentation for each logotype. That is, the client 563 MAY display an image with or without playing a sound, and it MAY play 564 a sound with or without displaying an image. A client MUST NOT play 565 more than one logotype audio sequence at the same time. 567 The logotype is to be displayed in conjunction with other identity 568 information contained in the certificate. The logotype is not a 569 replacement for this identity information. 571 Care is needed when designing replying party software to ensure that 572 appropriate context of logotype information is provided. This is 573 especially difficult with audio logotypes. It is important that the 574 human user is able to distinguish the context of the logotype even if 575 other audio streams are being played. 577 If the relying party software is unable to successfully validate a 578 particular certificate, then it MUST NOT display any logotype data 579 associated with that certificate. 581 7. Security considerations 583 Implementations that simultaneously display multiple logotype types 584 (subject organization, issuer, community or other), MUST ensure that 585 there is no ambiguity as to the binding between the image and the 586 type of logotype that the image represents. "Logotype type" is 587 defined in section 2, and it refers to the type of entity or 588 affiliation represented by the logotype, not the type of binary 589 format. 591 Logotypes are very difficult to securely and accurately define. Names 592 are also difficult in this regard, but logotypes are even worse. It 593 is quite difficult to specify what is, and what is not, a legitimate 594 logotype of an organization. There is a whole legal structure around 595 this issue, and it will not be repeated here. However, issuers should 596 be aware of the implications of including images associated with a 597 trademark or servicemark before doing so. 599 As logotypes can be difficult (and sometimes expensive) to verify, 600 this increases the possibility of errors related to assigning wrong 601 logotypes to organizations. 603 This is not a new issue for electronic identification instruments. It 604 is already dealt with in numerous of similar situations in the 605 physical world, including physical employee identification cards. 606 Secondly, there are situations where identification of logotypes is 607 rather simple and straightforward, such as logotypes for well-known 608 industries and institutes. These issues should not stop those service 609 providers who want to issue logotypes from doing so, where relevant. 611 It is impossible to prevent fraudulent creation of certificates by 612 dishonest or badly performing issuers, containing names and logotypes 613 that the issuer has no claim to or has failed to check correctly. 614 Such certificates could be created in an attempt to socially engineer 615 a user into accepting a certificate. The premise used for the 616 logotype work is thus that logotype graphics in a certificate are 617 trusted only if the certificate is successfully validated within a 618 valid path. It is thus imperative that the representation of any 619 certificate that fails to validate is not enhanced in any way by 620 using the logotype graphic. 622 Logotype data is fetched from a server when it is needed. By watching 623 activity on the network, an observer can determine which clients are 624 making use of certificates that contains particular logotype data. 625 This observation can potentially introduce privacy issues. Since 626 clients are expected to locally cache logotype data, network traffic 627 to the server containing the logotype data will not be generated 628 every time the certificate is used. In cases where logotype data is 629 not cashed, monitoring would reveal usage frequency. In cases where 630 logotype data is cached, monitoring would reveal when a certain 631 logotype image or audio sequence is used for the first time. 633 Certification paths may also impose name constraints that are 634 systematically checked during certification path processing, which, 635 in theory, may be circumvented by logotypes. 637 Certificate path processing as defined in RFC 3280 [PKIX-1] does not 638 constrain the inclusion of logotype data in certificates. A parent CA 639 can constrain certification path validation such that subordinate CAs 640 cannot issue valid certificates to end-entities outside a limited 641 name space or outside specific certificate polices. A malicious CA 642 can comply with these name and policy requirements and still include 643 inappropriate logotypes in the certificates that it issues. These 644 certificates will pass the certification path validation algorithm, 645 which means the client will trust the logotypes in the certificates. 646 Since there is no technical mechanism to prevent or control 647 subordinate CAs from including the logotype extension or its 648 contents, where appropriate, a parent CA could employ a legal 649 agreement to impose a suitable restriction on the subordinate CA. 650 This situation is not unique to the logotype extension. 652 The controls available to a parent CA to protect itself from rogue 653 subordinate CAs are non-technical. They include: 655 - Contractual agreements of suitable behavior, including 656 terms of liability in case of material breach. 658 - Control mechanisms and procedures to monitor and 659 follow-up behavior of subordinate CAs. 661 - Use of certificate policies to declare assurance level 662 of logotype data as well as to guide applications on how 663 to treat and display logotypes. 665 - Use of revocation functions to revoke any misbehaving CA. 667 There is not a simple, straightforward, and absolute technical 668 solution. Rather, involved parties must settle some aspects of PKI 669 outside the scope of technical controls. As such, issuers need to 670 clearly identify and communicate the associated risks. 672 8. IANA Considerations 674 Certificate extensions and attribute certificate extensions are 675 identified by object identifiers (OIDs). The OID for the extension 676 defined in this document was assigned from an arc delegated by the 677 IANA to the PKIX Working Group. No further action by the IANA is 678 necessary for this document or any anticipated updates 680 9. IPR Considerations 682 The IETF takes no position regarding the validity or scope of any 683 intellectual property or other rights that might be claimed to 684 pertain to the implementation or use of the technology described in 685 this document or the extent to which any license under such rights 686 might or might not be available; neither does it represent that it 687 has made any effort to identify any such rights. Information on the 688 IETF's procedures with respect to rights in standards-track and 689 standards-related documentation can be found in BCP-11. Copies of 690 claims of rights made available for publication and any assurances of 691 licenses to be made available, or the result of an attempt made to 692 obtain a general license or permission for the use of such 693 proprietary rights by implementors or users of this specification can 694 be obtained from the IETF Secretariat. 696 The IETF invites any interested party to bring to its attention any 697 copyrights, patents or patent applications, or other proprietary 698 rights which may cover technology that may be required to practice 699 this standard. Please address the information to the IETF Executive 700 Director. 702 10. References 704 10.1. Normative References 706 [LANGCODES] H. T. Alvestrand, "Tags for Identification of Languages", 707 RFC 3066, January 2001. 709 [PKIX-1] R. Housley, W. Polk, W. Ford, and D. Solo, "Internet 710 X.509 Public Key Infrastructure: Certificate and 711 Certificate Revocation List (CRL) Profile", RFC 3280, 712 April 2002. 714 [SHS] Federal Information Processing Standards Publication 715 (FIPS PUB) 180-1, Secure Hash Standard, 17 April 1995. 716 [Supersedes FIPS PUB 180 dated 11 May 1993.] 718 [STDWORDS] S. Bradner, "Key words for use in RFCs to Indicate 719 Requirement Levels", RFC 2119, March 1997. 721 [HTTP/1.1] UC Irvine, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, 722 P. Leach and T. Berners-Lee, "Hypertext Transfer Protocol 723 -- HTTP/1.1", RFC 2616 725 [FTP] J. Postel, and J. K. Reynolds, "File Transfer Protocol 726 (FTP)", RFC 959, October 1985. 728 [URI] T. Berners-Lee, R. Fielding, L. Masinter, "Uniform Resource 729 Identifiers (URI): Generic Syntax", RFC 2396, August 1998. 731 [MEDIA] N. Freed and N. Borenstein, "Multipurpose Internet Mail 732 Extensions (MIME) Part Two: Media Types", RFC 2046, 733 November 1996 735 [AUDIO/MPEG] M. Nilsson, "The audio/mpeg Media Type", RFC 3003, 736 November 2000 738 [X.208-88] CCITT Recommendation X.208: Specification of Abstract 739 Syntax Notation One (ASN.1), 1988. 741 [X.209-88] CCITT Recommendation X.209: Specification of Basic 742 Encoding Rules for Abstract Syntax Notation One (ASN.1), 743 1988. 745 10.2. Informative References 747 [CMS] R. Housley, Cryptographic Message Syntax (CMS), RFC 3369, 748 August 2002. 750 [X.509-88] CCITT Recommendation X.509: The Directory - 751 Authentication Framework. 1988. 753 APPENDIX A. ASN.1 Module 755 LogotypeCertExtn 756 { iso(1) identified-organization(3) dod(6) internet(1) 757 security(5) mechanisms(5) pkix(7) id-mod(0) 758 id-mod-logotype(22) } 760 DEFINITIONS IMPLICIT TAGS ::= 761 BEGIN 763 IMPORTS 764 AlgorithmIdentifier FROM PKIX1Explicit88 -- RFC 3280 765 { iso(1) identified-organization(3) dod(6) internet(1) 766 security(5) mechanisms(5) pkix(7) id-mod(0) 767 id-pkix1-explicit(18) }; 769 -- Logotype Extension OID 771 id-pe-logotype OBJECT IDENTIFIER ::= 772 { iso(1) identified-organization(3) dod(6) internet(1) 773 security(5) mechanisms(5) pkix(7) id-pe(1) 12 } 775 -- Logotype Extension Syntax 777 LogotypeExtn ::= SEQUENCE { 778 communityLogos [0] EXPLICIT SEQUENCE OF LogotypeInfo OPTIONAL, 779 issuerLogo [1] EXPLICIT LogotypeInfo OPTIONAL, 780 subjectLogo [2] EXPLICIT LogotypeInfo OPTIONAL, 781 otherLogos [3] EXPLICIT SEQUENCE OF OtherLogotypeInfo OPTIONAL } 783 LogotypeInfo ::= CHOICE { 784 direct [0] LogotypeData, 785 indirect [1] LogotypeReference } 787 LogotypeData ::= SEQUENCE { 788 image SEQUENCE OF LogotypeImage OPTIONAL, 789 audio [1] SEQUENCE OF LogotypeAudio OPTIONAL } 791 LogotypeImage ::= SEQUENCE { 792 imageDetails LogotypeDetails, 793 imageInfo LogotypeImageInfo OPTIONAL } 795 LogotypeAudio ::= SEQUENCE { 796 audioDetails LogotypeDetails, 797 audioInfo LogotypeAudioInfo OPTIONAL } 799 LogotypeDetails ::= SEQUENCE { 800 mediaType IA5String, -- MIME media type name and optional 801 -- parameters 802 logotypeHash SEQUENCE SIZE (1..MAX) OF HashAlgAndValue, 803 logotypeURI SEQUENCE SIZE (1..MAX) OF IA5String } 805 LogotypeImageInfo ::= SEQUENCE { 806 type [0] LogotypeImageType DEFAULT color, 807 fileSize INTEGER, -- In octets 808 xSize INTEGER, -- Horizontal size in pixels 809 ySize INTEGER, -- Vertical size in pixels 810 resolution LogotypeImageResolution OPTIONAL, 811 language [4] IA5String OPTIONAL } -- RFC 3066 Language Tag 813 LogotypeImageType ::= INTEGER { grayScale(0), color(1) } 815 LogotypeImageResolution ::= CHOICE { 816 numBits [1] INTEGER, -- Resolution in bits 817 tableSize [2] INTEGER } -- Number of colors or grey tones 819 LogotypeAudioInfo ::= SEQUENCE { 820 fileSize INTEGER, -- In octets 821 playTime INTEGER, -- In milliseconds 822 channels INTEGER, -- 1=mono, 2=stereo, 4=quad 823 sampleRate [3] INTEGER OPTIONAL, -- Samples per second 824 language [4] IA5String OPTIONAL } -- RFC 3066 Language Tag 826 OtherLogotypeInfo ::= SEQUENCE { 827 logotypeType OBJECT IDENTIFIER, 828 info LogotypeInfo } 830 LogotypeReference ::= SEQUENCE { 831 refStructHash SEQUENCE SIZE (1..MAX) OF HashAlgAndValue, 832 refStructURI SEQUENCE SIZE (1..MAX) OF IA5String } 833 -- Places to get the same "LTD" file 835 -- Note: The content of referenced "LTD" files is defined by the 836 -- LogotypeData type 838 HashAlgAndValue ::= SEQUENCE { 839 hashAlg AlgorithmIdentifier, 840 hashValue OCTET STRING } 842 -- Other logotype type OIDs 844 id-logo OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 845 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 20 } 847 id-logo-loyalty OBJECT IDENTIFIER ::= { id-logo 1 } 848 id-logo-background OBJECT IDENTIFIER ::= { id-logo 2 } 850 END 852 APPENDIX B. Example extension 854 The following example displays a logotype extension containing one 855 Issuer logotype using direct addressing. The issuer logotype image is 856 of the type image/gif. The logotype image file is referenced through 857 1 URI and the image is hashed by one sha1 hash value. 859 The values on the left are the ASN.1 tag and length, in hexadecimal. 861 30 106: SEQUENCE { 862 06 8: OBJECT IDENTIFIER '1 3 6 1 5 5 7 1 12' 863 04 94: OCTET STRING, encapsulates { 864 30 92: SEQUENCE { 865 A1 90: [1] { 866 A0 88: [0] { 867 30 86: SEQUENCE { 868 30 84: SEQUENCE { 869 30 82: SEQUENCE { 870 16 9: IA5String 'image/gif' 871 30 33: SEQUENCE { 872 30 31: SEQUENCE { 873 30 7: SEQUENCE { 874 06 5: OBJECT IDENTIFIER sha1 (1 3 14 3 2 26) 875 : } 876 04 20: OCTET STRING 877 : 8F E5 D3 1A 86 AC 8D 8E 6B C3 CF 80 6A D4 48 18 878 : 2C 7B 19 2E 879 : } 880 : } 881 30 34: SEQUENCE { 882 16 32: IA5String 'http://logo.example.com/logo.gif' 883 : } 884 : } 885 : } 886 : } 887 : } 888 : } 889 : } 890 : } 891 : } 893 APPENDIX C. Acknowledgments 895 This document is the result of contributions from many professionals. 896 The authors appreciate contributions from all members of the IETF 897 PKIX Working Group. We extend a special thanks to Al Arsenault, David 898 Cross, Tim Polk, Russel Weiser, Terry Hayes, Alex Deacon, Andrew 899 Hoag, Randy Sabett, Denis Pinkas, Magnus Nystrom, Ryan Hurst, and 900 Phil Griffin for their efforts and support. 902 Russ Housley thanks the management at RSA Laboratories, especially 903 Burt Kaliski, who supported the development of this specification. 904 The vast majority of the work on this specification was done while 905 Russ was employed at RSA Laboratories. 907 APPENDIX D. Author Addresses 909 Stefan Santesson 910 Microsoft Denmark 911 Tuborg Boulevard 12 912 DK-2900 Hellerup 913 Denmark 914 stefans@microsoft.com 916 Russell Housley 917 Vigil Security, LLC 918 918 Spring Knoll Drive 919 Herndon, VA 20170 920 USA 921 housley@vigilsec.com 923 Trevor Freeman 924 Microsoft Corporation 925 One Microsoft Way 926 Redmond WA 98052 927 USA 928 trevorf@microsoft.com 930 Full Copyright Statement 932 Copyright (C) The Internet Society (2003). All Rights Reserved. 934 This document and translations of it may be copied and furnished to 935 others, and derivative works that comment on or otherwise explain it 936 or assist in its implementation may be prepared, copied, published 937 and distributed, in whole or in part, without restriction of any 938 kind, provided that the above copyright notice and this paragraph are 939 included on all such copies and derivative works. In addition, the 940 ASN.1 modules presented in Appendices A and B may be used in whole or 941 in part without inclusion of the copyright notice. However, this 942 document itself may not be modified in any way, such as by removing 943 the copyright notice or references to the Internet Society or other 944 Internet organizations, except as needed for the purpose of 945 developing Internet standards in which case the procedures for 946 copyrights defined in the Internet Standards process shall be 947 followed, or as required to translate it into languages other than 948 English. 950 The limited permissions granted above are perpetual and will not be 951 revoked by the Internet Society or its successors or assigns. This 952 document and the information contained herein is provided on an "AS 953 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 954 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 955 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL 956 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY 957 OR FITNESS FOR A PARTICULAR PURPOSE.