idnits 2.17.00 (12 Aug 2021) /tmp/idnits64986/draft-ietf-pkix-logotypes-02.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 IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == 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 (April 2002) is 7340 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 283, but not defined -- Looks like a reference, but probably isn't: '0' on line 291 -- Looks like a reference, but probably isn't: '1' on line 292 -- Looks like a reference, but probably isn't: '2' on line 293 -- Looks like a reference, but probably isn't: '3' on line 294 == Unused Reference: 'FIPS 180-1' is defined on line 492, but no explicit reference was found in the text == Unused Reference: 'OLD-PKIX-1' is defined on line 496, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS 180-1' -- Possible downref: Non-RFC (?) normative reference: ref. 'OLD-PKIX-1' -- Possible downref: Non-RFC (?) normative reference: ref. 'PKIX-1' -- Possible downref: Non-RFC (?) normative reference: ref. 'STDWORDS' Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PKIX Working Group S. Santesson (AddTrust) 3 INTERNET-DRAFT R. Housley (RSA Laboratories) 4 Expires August 2002 T. Freeman (Microsoft) 5 April 2002 7 Internet X.509 Public Key Infrastructure 9 Logotypes in X.509 certificates 11 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that other 20 groups may also distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Copyright (C) The Internet Society (2002). All Rights Reserved. 35 Abstract 37 This document specifies a certificate extension for including 38 logotypes in public key certificates and attribute certificates. 40 Please send comments on this document to the ietf-pkix@imc.org 41 mailing list. 43 Table of Contents 45 1 Introduction ................................................. 3 46 1.1 Certificate-based Identification .......................... 4 47 1.2 Selection of Certificates ................................. 4 48 1.3 Combination of Verification Techniques .................... 5 49 1.4 Terminology ............................................... 6 50 2 Different types of logotypes in Certificates ................. 6 51 3 Image formats ................................................ 6 52 4 Logotype extension ........................................... 7 53 5 Type of certificates ......................................... 9 54 6 Use in Clients ............................................... 9 55 7 Security considerations ...................................... 10 56 8 References ................................................... 11 57 9 Intellectual Property Rights ................................. 12 59 Appendices 61 A. ASN.1 definitions ........................................... 13 62 B. Logotype placement .......................................... 13 63 B.1 Qualifier ................................................. 13 64 B.2 Issuer and Subject Alt Names .............................. 13 65 B.3 New extension ............................................. 14 66 B.4 Conclusion ................................................ 14 67 C. Author Addresses ............................................ 15 68 D. Full Copyright Statement .................................... 16 70 1. Introduction 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 systematic certificate 181 verification and human recognition. 183 Systematic certification path verification determines whether the 184 end-entity certificate can be verified according to defined policy. 185 The algorithm for this verification is specified in RFC 186 [PKIX-1]. 188 The systematic processing provides assurance that the certificate is 189 valid. It does not indicate whether the subject is entitled to any 190 particular information or whether the subject ought to be trusted to 191 perform a particular service. These are access control decisions. 192 Automatic processing will make some access control decisions, but 193 others, depending on the application context, involve the human user. 195 In some situations, where automated procedures have failed to 196 establish the suitability of the certificate to the task, the human 197 user is the final arbitrator of the post certificate verification 198 access control decisions. In the end, the human will decide whether 199 or not to accept an executable email attachment, to release personal 200 information, or follow the instructions displayed by a web browser. 201 This decision will often be based on recognition and previous 202 experience. 204 The distinction between systematic processing and human processing is 205 rather straightforward. They can be complementary. While the 206 systematic process is focused on certification path construction and 207 verification, the human acceptance process is focused on recognition 208 and related previous experience. 210 There are some situations where systematic processing and human 211 processing interfere with each other. These issues are discussed in 212 the Security Considerations section. 214 1.4. Terminology 216 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 217 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 218 document are to be interpreted as described in RFC 2119 [STDWORDS]. 220 2. Different Types of Logotypes in Certificates 222 This specification defines the inclusion of three predefined logotype 223 types. 225 1) Community logotype 226 2) Issuer organization logotype 227 3) Subject organization logotype 229 The community logotype - is the general mark for a community. It 230 identifies a service concept for entity identification and 231 certificate issuance. Many issuers may use a community logotype to 232 co-brand with a global community in order to gain global recognition 233 of its local service provision. This type of community branding is 234 very common in the credit card business where local independent card 235 issuers include a globally recognized brand (such as VISA and 236 MasterCard). 238 Issuer organization logotype - is a logotype representing the 239 organization identified as part of the issuer name in the 240 certificate. 242 Subject organization logotype - is a logotype representing the 243 organization identified in the subject name in the certificate. 245 3. Image formats 247 This specification defines two image format types: 249 - High Resolution (included by reference) 250 - Low Resolution (icon-sized image embedded in the extension) 252 Format restrictions: 253 High Resolution Low Resolution 254 +-----------------+---------------------+--------------------+ 255 | Image format | JPEG or GIF | JPEG or GIF | 256 +-----------------+---------------------+--------------------+ 257 | Size | Max 150 x 50 pixels | 20 x 20 pixels | 258 +-----------------+---------------------+--------------------+ 259 | Color palette | Unlimited | 256 colors (8-bit) | 260 +-----------------+---------------------+--------------------+ 262 A high resolution image SHOULD include a black border. Exceptions are 263 such things as arrows or X's. These images SHOULD be fairly flat in 264 appearance with little dimensioning or shading. 266 There is no need to significantly increase the size of the 267 certificate by including image data of logotypes in high quality 268 format. Rather, a URI identifying the location to the logotype image 269 and a one-way hash of the referenced data is included in the 270 certificate. 272 To enhance functionality for off-line and low bandwidth situations 273 where reasonable access to high quality logotypes are not available, 274 the icon-sized version of the logotype may optionally be stored 275 directly in the certificate extension. 277 Applications may also enhance processing and off-line functionality 278 by cashing the higher quality logotype data. 280 4. Logotype extension 282 The logotype extension MAY be included in public key certificates 283 [PKIX-1] or attribute certificates [PKIX-AC]. The logotype extension 284 MUST be identified by the following object identifier: 286 id-pe-logotypeInfo OBJECT IDENTIFIER ::= {id-pe XX} 288 The logotype extension MUST have the following syntax: 290 LogotypeInfo ::= SEQUENCE { 291 communityLogo [0] LogotypeData OPTIONAL, 292 issuerLogo [1] LogotypeData OPTIONAL, 293 subjectLogo [2] LogotypeData OPTIONAL, 294 otherLogos [3] SEQUENCE OF OtherLogotypeData OPTIONAL } 296 OtherLogotypeData ::= SEQUENCE { 297 logotypeTypeID OBJECT IDENTIFIER, 298 logotypeData LogotypeData } 300 LogotypeData ::= SEQUENCE { 301 highRes LogotypeReference OPTIONAL, 302 lowRes EmbeddedLogotype OPTIONAL } 304 LogotypeReference ::= SEQUENCE { 305 hashAlgorithm AlgorithmIdentifier, 306 logotypeHash OCTET STRING, 307 logotypeUri IA5String } 309 EmbeddedLogotype ::= SEQUENCE { 310 imageFileExtn IA5String, -- MUST be "JPEG" or "JPG" or "GIF" 311 image OCTET STRING } 313 This extension MUST NOT be marked critical. 315 At least one of the optional elements in the LogotypeInfo structure 316 MUST be present. Whenever possible, the use of otherLogos should be 317 avoided. 319 The LogotypeReference structure explicitly identifies the one-way 320 hash function employed. Implementations MUST support the SHA-1 [FIPS 321 180-1] algorithm, and implementations MAY support other one-way hash 322 functions. 324 The predefined logotype types are: 326 Community Logotype. If communityLogo is present, the logotype MUST 327 represent the community to which the certificate issuer is a 328 member. The communityLogo MAY be present in an end entity 329 certificate or an attribute certificate. The communityLogo MUST 330 NOT be present in a CA certificate. 332 Issuer Organization Logotype. If issuerLogo is present, the 333 logotype MUST represent the issuer's organization. The logotype 334 MUST be consistent with, and require the presence of, an 335 organization name stored in the organization attribute in the 336 issuer field (for either a public key certificate or attribute 337 certificate). The issuerLogo MAY be present in an end entity 338 certificate, a CA certificate, or an attribute certificate. 340 Subject Organization Logotype. If subjectLogo is present, the 341 logotype MUST represent the subject's organization. The logotype 342 MUST be consistent with, and require the presence of, an 343 organization name stored in the organization attribute in the 344 subject field (for either a public key certificate or attribute 345 certificate). The subjectLogo MAY be present in an end entity 346 certificate, a CA certificate, or an attribute certificate. 348 The relationship between the subject organization and the subject 349 organization logotype and the relationship between the issuer and 350 either the issuer organization logotype or the community logotype, 351 are relationships claimed by the issuer. The policy under which the 352 issuer checks these logotypes is outside the scope of this standard. 354 Any URI pointing to a file containing the logotype data MUST include 355 a file extension defining the image file format. The file extension 356 is the last three or four letters of the file name, immediately 357 following a period. Implementations MUST support both the JPEG and 358 GIF image formats. The JPEG image format MUST be identifier using a 359 file extension of "JPG" or "JPEG". The GIF image format MUST be 360 identified using the "GIF" file extension. 362 The same three file extension strings ("JPG," "JPEG," and "GIF") are 363 used to identify the format of embedded images. 365 To ensure that certificates are not greatly enlarged by including 366 embedded logotypes, restrictions are imposed on image size and color 367 definition. Embedded images MUST NOT exceed 20 pixels by 20 pixels. 368 Embedded images MUST use a 256-color (8-bit) palette. The size of an 369 image conforming to these restrictions is about 750 octets. 371 5. Type of certificates 373 Logotypes MAY be present in three types of certificates: 375 - CA certificates 376 - End-entity certificates 377 - Attribute certificates 379 CA certificates include self-signed certificates (often used to 380 represent trust anchors) or Intermediate CA certificates. 382 Some types of logotypes are not permitted in CA certificates. This 383 ensures that logotypes are excludes from all aspects of certification 384 path processing. As discussed above, logotypes are not intended to be 385 part of certification path validation or any type of systematic 386 processing. The sole purpose of logotypes is to enhance display of a 387 particular certificate, regardless of its position in a certification 388 path. 390 Logotypes MUST NOT be an active component in certification path 391 processing, and they are included in public key certificates and 392 attribute certificates at the discretion of the certificate issuer. 394 6. Use in Clients 396 All PKI implementations require relying party software to have some 397 mechanism to determine whether a trusted CA issues a particular 398 certificate. This is an issue for certification path validation, 399 including consistent policy and name checking. 401 After a certification path is successfully validated, the replying 402 party must trust the information that the CA includes in the 403 certificate, including any certificate extensions. The client 404 software can choose to make use of such information, or the client 405 software can ignore it. Current standards do not provide any 406 mechanism for cross-certifying CAs to constrain subordinate CAs from 407 including private extensions (see the security considerations 408 section). 410 Consequently, if relying party software accepts a CA, then it should 411 be prepared to (unquestioningly) display the associated logotypes to 412 its human user, given that it is configured to do so. 414 However, if the relying party software is unable to successfully 415 validate a particular certificate, then it MUST NOT display any 416 associated logotype graphics. 418 7. Security considerations 420 Logotypes are very difficult to securely and accurately define. Names 421 are also difficult in this regard, but logotypes are even worse. It 422 is quite difficult to specify what is, and what is not, a legitimate 423 logotype of an organization. There is a whole legal structure around 424 this issue, and it will not be repeated here. However, issuers should 425 be aware of the implications of including images associated with a 426 trademark or servicemark before doing so. 428 As logotypes can be difficult (and sometimes expensive) to verify, 429 this increases the possibility of errors related to assigning wrong 430 logotypes to organizations. 432 This is not a new issue for electronic identification instruments. 433 It is already dealt with in numerous of similar situations in the 434 physical world, including physical employee identification cards. 435 Secondly, there are situations where identification of logotypes is 436 rather simple and straightforward, such as logotypes for well-known 437 industries and institutes. These issues should not stop those service 438 providers who want to issue logotypes from doing so, where relevant. 440 The premise used for the logotype work is that logotype graphics in a 441 certificate are trusted only if the certificate is successfully 442 validated within a valid path. It is however impossible to prevent 443 fraudulent creation of certificates by non-validated issuers, 444 containing names and logotypes that the issuer has no claim to. Such 445 certificates could be created in an attempt to socially engineer a 446 user into accepting a certificate. It is thus imperative that the 447 representation of any certificate that fails to validate is not 448 enhanced in any way by using the logotype graphic. 450 Certification paths may also impose name constraints that are 451 systematically checked during certification path processing, which, 452 in theory, may be circumvented by logotypes. 454 Certificate path processing does not constrain the inclusion of 455 logotype data in certificates. A parent CA can constrain 456 certification path validation such that subordinate CAs cannot issue 457 valid certificates to end-entities outside a limited name space or 458 outside specific certificate polices. A malicious CA can comply with 459 these name and policy requirements and still include inappropriate 460 logotypes in the certificates that it issues. These certificates will 461 pass the certification path validation algorithm, which means the 462 client will trust the logotypes in the certificates. Since there is 463 no technical mechanism to prevent or control subordinate CAs from 464 including the logotype extension or its contents, where appropriate, 465 a parent CA could employ a legal agreement to impose a suitable 466 restriction on the subordinate CA. This situation is not unique to 467 the logotype extension. 469 The controls available to a parent CA to protect itself from rogue 470 subordinate CAs are non-technical. They include: 472 - Contractual agreements of suitable behavior, including 473 terms of liability and severance pay in case of material 474 breach. 476 - Control mechanisms and procedures to monitor and 477 follow-up behavior of subordinate CAs. 479 - Use of certificate policies to declare assurance level 480 of logotype data as well as to guide applications on how 481 to treat and display logotypes. 483 - Use of revocation functions to revoke any misbehaving CA. 485 There is not a simple, straightforward, and absolute technical 486 solution. Rather, involved parties must settle some aspects of PKI 487 outside the scope of technical controls. As such, issuers need to 488 clearly identify and communicate the associated risks. 490 8. References 492 [FIPS 180-1] Federal Information Processing Standards Publication 493 (FIPS PUB) 180-1, Secure Hash Standard, 17 April 1995. 494 [Supersedes FIPS PUB 180 dated 11 May 1993.] 496 [OLD-PKIX-1] R. Housley, W. Ford, W. Polk, and D. Solo, "Internet 497 X.509 Public Key Infrastructure: Certificate and 498 CRL Profile", January 1999. 500 [PKIX-1] R. Housley, W. Ford, W. Polk, and D. Solo, "Internet 501 X.509 Public Key Infrastructure: Certificate and 502 CRL Profile", January 1999. 503 {Replace with Son-of-2459 as soon as it is published.} 505 [STDWORDS] S. Bradner, "Key words for use in RFCs to Indicate 506 Requirement Levels", March 1997. 508 9. Intellectual Property Rights 510 The IETF takes no position regarding the validity or scope of any 511 intellectual property or other rights that might be claimed to 512 pertain to the implementation or use of the technology described in 513 this document or the extent to which any license under such rights 514 might or might not be available; neither does it represent that it 515 has made any effort to identify any such rights. Information on the 516 IETF's procedures with respect to rights in standards-track and 517 standards related documentation can be found in BCP-11. Copies of 518 claims of rights made available for publication and any assurances of 519 licenses to be made available, or the result of an attempt made to 520 obtain a general license or permission for the use of such 521 proprietary rights by implementers or users of this specification can 522 be obtained from the IETF Secretariat. 524 The IETF invites any interested party to bring to its attention any 525 copyrights, patents or patent applications, or other proprietary 526 rights which may cover technology that may be required to practice 527 this standard. Please address the information to the IETF Executive 528 Director. 530 APPENDICES 532 A. ASN.1 definitions 534 TBD 536 B. Logotype Placement 538 This Appendix documents reasons and rationales behind the technical 539 solution selected in this standard. 541 Three alternatives for the placement of the logotypes in a 542 certificate have been considered. They are: 544 1. Inclusion in a policy qualifier; 545 2. Inclusion in Issuer and Subject Alternative names extensions; and 546 3. Inclusion in a separate certificate extension. 548 B.1 Qualifier 550 This alternative would include logotype data as a newly defined 551 policy qualifier. 553 Pros: 555 - This solution provides a mechanism to directly control the use and 556 display of logotypes under a particular policy. 558 Cons: 560 - RFC [PKIX-1] recommends against use of qualifiers. 562 - This is generally considered to be a major hack and stretch of 563 semantics, since this type of data doesn't qualify a policy in any 564 way. 566 B.2 Issuer and Subject Alt Names 568 This solution would use the other name form to include the issuer and 569 community logotypes in the issuer alt name extension, and subject 570 organization logo in the subject alt name extension. 572 Pros: 574 - This mechanism could possibly enable cross-certifying CAs to deny 575 any subordinate CA the right to include logotypes in descending end 576 entity certificates by listing the logotypes name form in 577 excludedSubtrees. 579 Cons: 581 - Logotypes are not a name form and should not be treated as a 582 displayable name. 584 - It is generally understood that it should be possible to apply 585 general name constraint mechanisms (as described in RFC 2459 as 586 well as RFC [PKIX-1]) to names in the subject and issuer 587 alt name extension. This is not possible to do with logotypes 588 since it is not a name form. 590 - This split storage of logotype data into 2 different locations, 591 which may make life worse for applications with no interest in 592 logotypes. 594 - It is generally agreed that inclusion of logotype data by no means 595 should be regarded as critical data. This may interfere with the 596 criticality policy of the alt name extensions, especially if the 597 certificate has no attributes in the subject field, forcing the 598 subject alt name to be set to critical. 600 - This usage would possibly interfere with the resolution between 601 IETF and ITU-T regarding use of permitted subtrees. 603 - Since this solution may break current implementations it would 604 possibly block adoption of logotypes. 606 B.3 New extension 608 This solution places logotype data in a new extension. 610 Pros: 612 - This is the cleanest solution. 614 - This does not impact on legacy implementations. 616 Cons: 618 - This solution activates the issue whether this extension may be 619 abused by a CA who include logotypes (in EE certificates) that 620 violates the intention of a name constraints set by a chaining CA. 621 This issue is addressed in the security consideration section 622 below. 624 B.4 Conclusion 626 We must not destroy current structures. We must not create problems 627 or confusion. 629 Only the private extension solution satisfies both of these criteria. 630 Therefore, the private extension was selected to carry logotype 631 information. 633 While the syntax and semantics of the X.509 public key certificate 634 were used in this analysis, the logotype private extension can also 635 be included in an X.509 attribute certificate. 637 C. Author Addresses 639 Stefan Santesson 640 AddTrust AB 641 P.O. Box 465 642 S-201 24 Malmoe 643 Sweden 644 stefan@addtrust.com 646 Russell Housley 647 RSA Laboratories 648 918 Spring Knoll Drive 649 Herndon, VA 20170 650 USA 651 rhousley@rsasecurity.com 653 Trevor Freeman 654 Microsoft Corporation 655 One Microsoft Way 656 Redmond WA 98052 657 USA 658 trevorf@microsoft.com 660 D. Full Copyright Statement 662 Copyright (C) The Internet Society (2002). All Rights Reserved. 664 This document and translations of it may be copied and furnished to 665 others, and derivative works that comment on or otherwise explain it 666 or assist in its implementation may be prepared, copied, published 667 and distributed, in whole or in part, without restriction of any 668 kind, provided that the above copyright notice and this paragraph are 669 included on all such copies and derivative works. In addition, the 670 ASN.1 modules presented in Appendices A and B may be used in whole or 671 in part without inclusion of the copyright notice. However, this 672 document itself may not be modified in any way, such as by removing 673 the copyright notice or references to the Internet Society or other 674 Internet organizations, except as needed for the purpose of 675 developing Internet standards in which case the procedures for 676 copyrights defined in the Internet Standards process shall be 677 followed, or as required to translate it into languages other than 678 English. 680 The limited permissions granted above are perpetual and will not be 681 revoked by the Internet Society or its successors or assigns. This 682 document and the information contained herein is provided on an "AS 683 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 684 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 685 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL 686 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY 687 OR FITNESS FOR A PARTICULAR PURPOSE.