idnits 2.17.00 (12 Aug 2021) /tmp/idnits53904/draft-ietf-lamps-rfc3709bis-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document obsoletes RFC6170, but the abstract doesn't seem to directly say this. It does mention RFC6170 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document date (15 February 2022) is 95 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) -- Looks like a reference, but probably isn't: '0' on line 1607 -- Looks like a reference, but probably isn't: '1' on line 1469 -- Looks like a reference, but probably isn't: '2' on line 1514 -- Looks like a reference, but probably isn't: '3' on line 1603 -- Looks like a reference, but probably isn't: '4' on line 437 -- Possible downref: Non-RFC (?) normative reference: ref. 'GIF' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO15948' -- Possible downref: Non-RFC (?) normative reference: ref. 'JPEG' -- Possible downref: Non-RFC (?) normative reference: ref. 'MP3' -- Possible downref: Non-RFC (?) normative reference: ref. 'NEW-ASN1' ** Downref: Normative reference to an Informational RFC: RFC 1952 ** Obsolete normative reference: RFC 2396 (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 4288 (Obsoleted by RFC 6838) -- Possible downref: Non-RFC (?) normative reference: ref. 'SVGT' -- Obsolete informational reference (is this intentional?): RFC 3778 (Obsoleted by RFC 8118) Summary: 3 errors (**), 0 flaws (~~), 0 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Santesson 3 Internet-Draft IDsec Solutions 4 Obsoletes: 3709, 6170 (if approved) R. Housley 5 Intended status: Standards Track Vigil Security 6 Expires: 19 August 2022 T. Freeman 7 Amazon Web Services 8 L. Rosenthol 9 Adobe 10 15 February 2022 12 Internet X.509 Public Key Infrastructure: Logotypes in X.509 13 Certificates 14 draft-ietf-lamps-rfc3709bis-00 16 Abstract 18 This document specifies a certificate extension for including 19 logotypes in public key certificates and attribute certificates. 20 This document obsoletes RFC 3709 and RFC 6170. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on 19 August 2022. 39 Copyright Notice 41 Copyright (c) 2022 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 46 license-info) in effect on the date of publication of this document. 47 Please review these documents carefully, as they describe your rights 48 and restrictions with respect to this document. Code Components 49 extracted from this document must include Revised BSD License text as 50 described in Section 4.e of the Trust Legal Provisions and are 51 provided without warranty as described in the Revised BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1. Certificate-based Identification . . . . . . . . . . . . 4 57 1.2. Selection of Certificates . . . . . . . . . . . . . . . . 5 58 1.3. Combination of Verification Techniques . . . . . . . . . 5 59 1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 60 2. Different Types of Logotypes in Certificates . . . . . . . . 6 61 3. Logotype Data . . . . . . . . . . . . . . . . . . . . . . . . 7 62 4. Logotype Extension . . . . . . . . . . . . . . . . . . . . . 8 63 4.1. Extension Format . . . . . . . . . . . . . . . . . . . . 8 64 4.2. Conventions for LogotypeImageInfo . . . . . . . . . . . . 12 65 4.3. Embedded Images . . . . . . . . . . . . . . . . . . . . . 12 66 4.4. Other Logotypes . . . . . . . . . . . . . . . . . . . . . 13 67 4.4.1. Loyalty Logotype . . . . . . . . . . . . . . . . . . 13 68 4.4.2. Certificate Background Logotype . . . . . . . . . . . 13 69 4.4.3. Certificate Image Logotype . . . . . . . . . . . . . 14 70 5. Type of Certificates . . . . . . . . . . . . . . . . . . . . 15 71 6. Use in Clients . . . . . . . . . . . . . . . . . . . . . . . 15 72 7. Image Formats . . . . . . . . . . . . . . . . . . . . . . . . 17 73 8. Audio Formats . . . . . . . . . . . . . . . . . . . . . . . . 18 74 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 75 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 76 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 77 11.1. Acknowledgments from RFC 3709 . . . . . . . . . . . . . 22 78 11.2. Acknowledgments from RFC 6170 . . . . . . . . . . . . . 22 79 11.3. Additional Acknowledgments . . . . . . . . . . . . . . . 22 80 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 81 12.1. Normative References . . . . . . . . . . . . . . . . . . 22 82 12.2. Informative References . . . . . . . . . . . . . . . . . 24 83 Appendix A. ASN.1 Modules . . . . . . . . . . . . . . . . . . . 25 84 A.1. ASN.1 Modules with 1988 Syntax . . . . . . . . . . . . . 25 85 A.2. ASN.1 Module with 1997 Syntax . . . . . . . . . . . . . . 28 86 Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 31 87 B.1. Example from RFC 3709 . . . . . . . . . . . . . . . . . . 31 88 B.2. Issuer Logotype Example . . . . . . . . . . . . . . . . . 32 89 B.3. Embedded Image Example . . . . . . . . . . . . . . . . . 33 90 B.4. Embedded Certificate Image Example . . . . . . . . . . . 34 91 Appendix C. Changes Since RFC 3709 . . . . . . . . . . . . . . . 37 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 94 1. Introduction 96 This specification supplements [RFC5280], which profiles public-key 97 certificates and certificate revocation lists (CRLs) for use in the 98 Internet, and it supplements [RFC5755] which profiles attribute 99 certificates for use in the Internet. 101 This document obsoletes RFC 3709 and RFC 6170. Appendix C provides a 102 summary of the changes since the publication of RFC 3709. 104 The basic function of a certificate is to bind a public key to the 105 identity of an entity (the subject). From a strictly technical 106 viewpoint, this goal could be achieved by signing the identity of the 107 subject together with its public key. However, the art of Public Key 108 Infrastructure (PKI) has developed certificates far beyond this 109 functionality in order to meet the needs of modern global networks 110 and heterogeneous information technology structures. 112 Certificate users must be able to determine certificate policies, 113 appropriate key usage, assurance level, and name form constraints. 114 Before a relying party can make an informed decision whether a 115 particular certificate is trustworthy and relevant for its intended 116 usage, a certificate may be examined from several different 117 perspectives. 119 Systematic processing is necessary to determine whether a particular 120 certificate meets the predefined prerequisites for an intended usage. 121 Much of the information contained in certificates is appropriate and 122 effective for machine processing; however, this information is not 123 suitable for a corresponding human trust and recognition process. 125 Humans prefer to structure information into categories and symbols. 126 Most humans associate complex structures of reality with easily 127 recognizable logotypes and marks. Humans tend to trust things that 128 they recognize from previous experiences. Humans may examine 129 information to confirm their initial reaction. Very few consumers 130 actually read all terms and conditions they agree to in accepting a 131 service, rather they commonly act on trust derived from previous 132 experience and recognition. 134 A big part of this process is branding. Service providers and 135 product vendors invest a lot of money and resources into creating a 136 strong relation between positive user experiences and easily 137 recognizable trademarks, servicemarks, and logotypes. 139 Branding is also pervasive in identification instruments, including 140 identification cards, passports, driver's licenses, credit cards, 141 gasoline cards, and loyalty cards. Identification instruments are 142 intended to identify the holder as a particular person or as a member 143 of the community. The community may represent the subscribers of a 144 service or any other group. Identification instruments, in physical 145 form, commonly use logotypes and symbols, solely to enhance human 146 recognition and trust in the identification instrument itself. They 147 may also include a registered trademark to allow legal recourse for 148 unauthorized duplication. 150 Since certificates play an equivalent role in electronic exchanges, 151 we examine the inclusion of logotypes in certificates. We consider 152 certificate-based identification and certificate selection. 154 1.1. Certificate-based Identification 156 The need for human recognition depends on the manner in which 157 certificates are used and whether certificates need to be visible to 158 human users. If certificates are to be used in open environments and 159 in applications that bring the user in conscious contact with the 160 result of a certificate-based identification process, then human 161 recognition is highly relevant, and may be a necessity. 163 Examples of such applications include: 165 * Web server identification where a user identifies the owner of the 166 web site. 168 * Peer e-mail exchange in B2B, B2C, and private communications. 170 * Exchange of medical records, and system for medical prescriptions. 172 * Unstructured e-business applications (i.e., non-EDI applications). 174 * Wireless client authenticating to a service provider. 176 Most applications provide the human user with an opportunity to view 177 the results of a successful certificate-based identification process. 178 When the user takes the steps necessary to view these results, the 179 user is presented with a view of a certificate. This solution has 180 two major problems. First, the function to view a certificate is 181 often rather hard to find for a non-technical user. Second, the 182 presentation of the certificate is too technical and is not user 183 friendly. It contains no graphic symbols or logotypes to enhance 184 human recognition. 186 Many investigations have shown that users of today's applications do 187 not take the steps necessary to view certificates. This could be due 188 to poor user interfaces. Further, many applications are structured 189 to hide certificates from users. The application designers do not 190 want to expose certificates to users at all. 192 1.2. Selection of Certificates 194 One situation where software applications must expose human users to 195 certificates is when the user must select a single certificate from a 196 portfolio of certificates. In some cases, the software application 197 can use information within the certificates to filter the list for 198 suitability; however, the user must be queried if more than one 199 certificate is suitable. The human user must select one of them. 201 This situation is comparable to a person selecting a suitable plastic 202 card from his wallet. In this situation, substantial assistance is 203 provided by card color, location, and branding. 205 In order to provide similar support for certificate selection, the 206 users need tools to easily recognize and distinguish certificates. 207 Introduction of logotypes into certificates provides the necessary 208 graphic. 210 1.3. Combination of Verification Techniques 212 The use of logotypes will, in many cases, affect the users decision 213 to trust and use a certificate. It is therefore important that there 214 be a distinct and clear architectural and functional distinction 215 between the processes and objectives of the automated certificate 216 verification and human recognition. 218 Since logotypes are only aimed for human interpretation and contain 219 data that is inappropriate for computer based verification schemes, 220 the logotype extension MUST NOT be an active component in automated 221 certification path validation. 223 Automated certification path verification determines whether the end- 224 entity certificate can be verified according to defined policy. The 225 algorithm for this verification is specified in [RFC5280]. 227 The automated processing provides assurance that the certificate is 228 valid. It does not indicate whether the subject is entitled to any 229 particular information, or whether the subject ought to be trusted to 230 perform a particular service. These are access control decisions. 231 Automatic processing will make some access control decisions, but 232 others, depending on the application context, involve the human user. 234 In some situations, where automated procedures have failed to 235 establish the suitability of the certificate to the task, the human 236 user is the final arbitrator of the post certificate verification 237 access control decisions. In the end, the human will decide whether 238 or not to accept an executable email attachment, to release personal 239 information, or follow the instructions displayed by a web browser. 240 This decision will often be based on recognition and previous 241 experience. 243 The distinction between systematic processing and human processing is 244 rather straightforward. They can be complementary. While the 245 systematic process is focused on certification path construction and 246 verification, the human acceptance process is focused on recognition 247 and related previous experience. 249 There are some situations where systematic processing and human 250 processing interfere with each other. These issues are discussed in 251 the Section 9. 253 1.4. Terminology 255 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 256 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 257 "OPTIONAL" in this document are to be interpreted as described in 258 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 259 capitals, as shown here. 261 2. Different Types of Logotypes in Certificates 263 This specification defines the inclusion of three standard logotype 264 types: 266 * Community logotype 268 * Issuer organization logotype 270 * Subject organization logotype 272 The community logotype is the general mark for a community. It 273 identifies a service concept for entity identification and 274 certificate issuance. Many issuers may use a community logotype to 275 co-brand with a global community in order to gain global recognition 276 of its local service provision. This type of community branding is 277 very common in the credit card business, where local independent card 278 issuers include a globally recognized brand (such as VISA and 279 MasterCard). 281 Issuer organization logotype is a logotype representing the 282 organization identified as part of the issuer name in the 283 certificate. 285 Subject organization logotype is a logotype representing the 286 organization identified in the subject name in the certificate. 288 In addition to the standard logotype types, this specification 289 accommodates inclusion of other logotype types where each class of 290 logotype is defined by an object identifier. The object identifier 291 can be either locally defined or an identifier defined in Section 4.4 292 of this document. 294 3. Logotype Data 296 This specification defines two types of logotype data: image data and 297 audio data. Implementations MUST support image data; however, 298 support for audio data is OPTIONAL. 300 There is no need to significantly increase the size of the 301 certificate by including image and audio data of logotypes when a URI 302 identifying the location to the logotype data and a one-way hash of 303 the referenced data is included in the certificate. Embedding the 304 logotype in the certificate (as defined in Section 4.3) can 305 significantly increase the size of the certificate. 307 Several image objects, representing the same visual content in 308 different formats, sizes, and color palates, may represent each 309 logotype image. At least one of the image objects representing a 310 logotype SHOULD contain an image within the size range of 60 pixels 311 wide by 45 pixels high, and 200 pixels wide by 150 pixels high. 313 Several instances of audio data may further represent the same audio 314 sequence in different formats, resolutions, and languages. At least 315 one of the audio objects representing a logotype SHOULD have a play 316 time between 1 and 30 seconds. 318 If a logotype of a certain type (as defined in Section 1.1) is 319 represented by more than one image object, then the image objects 320 MUST contain variants of roughly the same visual content. Likewise, 321 if a logotype of a certain type is represented by more than one audio 322 object, then the audio objects MUST contain variants of the same 323 audio information. A spoken message in different languages is 324 considered a variation of the same audio information. Compliant 325 applications MUST NOT display more than one of the image objects and 326 MUST NOT play more than one of the audio object for any logotype type 327 at the same time. 329 A client MAY simultaneously display multiple logotypes of different 330 logotype types. For example, it may display one subject organization 331 logotype while also displaying a community logotype, but it MUST NOT 332 display multiple image variants of the same community logotype. 334 Each logotype present in a certificate MUST be represented by at 335 least one image data object. 337 Client applications SHOULD enhance processing and off-line 338 functionality by caching logotype data. 340 4. Logotype Extension 342 This section specifies the syntax and semantics of the logotype 343 certificate extension. 345 4.1. Extension Format 347 The logotype extension MAY be included in public key certificates 348 [RFC5280] or attribute certificates [RFC5755]. The logotype 349 extension MUST be identified by the following object identifier: 351 id-pe-logotype OBJECT IDENTIFIER ::= 352 { iso(1) identified-organization(3) dod(6) internet(1) 353 security(5) mechanisms(5) pkix(7) id-pe(1) 12 } 355 This extension MUST NOT be marked critical. 357 Logotype data may be referenced through either direct or indirect 358 addressing. Client applications MUST support both direct and 359 indirect addressing. Certificate issuing applications MUST support 360 direct addressing, and certificate issuing applications SHOULD 361 support indirect addressing. 363 The direct addressing includes information about each logotype in the 364 certificate, and URIs point to the image and audio data object. 365 Direct addressing supports cases where just one or a few alternative 366 images and audio objects are referenced. 368 The indirect addressing includes one reference to an external hashed 369 data structure that contains information on the type, content, and 370 location of each image and audio object. Indirect addressing 371 supports cases where each logotype is represented by many alternative 372 audio or image objects. 374 Both direct and indirect addressing accommodate alternative URIs to 375 obtain exactly the same item. This opportunity for replication is 376 intended to improve availability. Therefore, if a client is unable 377 to fetch the item from one URI, the client SHOULD try another URI in 378 the sequence. All direct addressing URIs SHOULD use either the HTTP 379 scheme (http://...) or the HTTPS scheme (https://...) or the DATA 380 scheme (data://...) [RFC2396]; however, the "data" URI scheme MUST 381 NOT be used with the indirect addressing. Clients MUST support 382 retrieval of referenced LogoTypeData with the HTTP/2 [RFC7540] and 383 the HTTPS/2 with TLS [RFC8740]. Client applications SHOULD also 384 support the "data" URI scheme [RFC2397] for direct addressing with 385 embedded logotype data within the extension. 387 The logotype extension MUST have the following syntax: 389 LogotypeExtn ::= SEQUENCE { 390 communityLogos [0] EXPLICIT SEQUENCE OF LogotypeInfo OPTIONAL, 391 issuerLogo [1] EXPLICIT LogotypeInfo OPTIONAL, 392 subjectLogo [2] EXPLICIT LogotypeInfo OPTIONAL, 393 otherLogos [3] EXPLICIT SEQUENCE OF OtherLogotypeInfo 394 OPTIONAL } 396 LogotypeInfo ::= CHOICE { 397 direct [0] LogotypeData, 398 indirect [1] LogotypeReference } 400 LogotypeData ::= SEQUENCE { 401 image SEQUENCE OF LogotypeImage OPTIONAL, 402 audio [1] SEQUENCE OF LogotypeAudio OPTIONAL } 404 LogotypeImage ::= SEQUENCE { 405 imageDetails LogotypeDetails, 406 imageInfo LogotypeImageInfo OPTIONAL } 408 LogotypeAudio ::= SEQUENCE { 409 audioDetails LogotypeDetails, 410 audioInfo LogotypeAudioInfo OPTIONAL } 412 LogotypeDetails ::= SEQUENCE { 413 mediaType IA5String, -- MIME media type name and optional 414 -- parameters 415 logotypeHash SEQUENCE SIZE (1..MAX) OF HashAlgAndValue, 416 logotypeURI SEQUENCE SIZE (1..MAX) OF IA5String } 418 LogotypeImageInfo ::= SEQUENCE { 419 type [0] LogotypeImageType DEFAULT color, 420 fileSize INTEGER, -- In octets 421 xSize INTEGER, -- Horizontal size in pixels 422 ySize INTEGER, -- Vertical size in pixels 423 resolution LogotypeImageResolution OPTIONAL, 424 language [4] IA5String OPTIONAL } -- RFC 5646 Language Tag 426 LogotypeImageType ::= INTEGER { grayScale(0), color(1) } 428 LogotypeImageResolution ::= CHOICE { 429 numBits [1] INTEGER, -- Resolution in bits 430 tableSize [2] INTEGER } -- Number of colors or grey tones 432 LogotypeAudioInfo ::= SEQUENCE { 433 fileSize INTEGER, -- In octets 434 playTime INTEGER, -- In milliseconds 435 channels INTEGER, -- 1=mono, 2=stereo, 4=quad 436 sampleRate [3] INTEGER OPTIONAL, -- Samples per second 437 language [4] IA5String OPTIONAL } -- RFC 5646 Language Tag 439 OtherLogotypeInfo ::= SEQUENCE { 440 logotypeType OBJECT IDENTIFIER, 441 info LogotypeInfo } 443 LogotypeReference ::= SEQUENCE { 444 refStructHash SEQUENCE SIZE (1..MAX) OF HashAlgAndValue, 445 refStructURI SEQUENCE SIZE (1..MAX) OF IA5String } 446 -- Places to get the same LogotypeData 447 -- image or audio object 449 HashAlgAndValue ::= SEQUENCE { 450 hashAlg AlgorithmIdentifier, 451 hashValue OCTET STRING } 453 When using indirect addressing, the URI (refStructURI) pointing to 454 the external data structure MUST point to a binary file containing 455 the DER-encoded data with the syntax LogotypeData. 457 At least one of the optional elements in the LogotypeExtn structure 458 MUST be present. Avoid the use of otherLogos whenever possible. 460 When using direct addressing, at least one of the optional elements 461 in the LogotypeData structure MUST be present. 463 The LogotypeReference and LogotypeDetails structures explicitly 464 identify one or more one-way hash functions employed to authenticate 465 referenced image or audio objects. CAs MUST include a hash value for 466 each referenced object, calculated on the whole object. CAs SHOULD 467 include a hash value that computed with the one-way hash function 468 associated with the certificate signature, and CAs MAY include other 469 hash values. Clients MUST compute a one-way hash value using one of 470 the identified functions, and clients MUST discard the logotype data 471 if the computed hash value does not match the hash value in the 472 certificate extension. 474 A MIME type is used to specify the format of the image or audio 475 object containing the logotype data. The mediaType field MUST 476 contain a string that is constructed according to the ABNF [RFC5234] 477 provided in Section 4.2 of [RFC4288]. MIME types MAY include 478 parameters. 480 Image format requirements are specified in Section 7, and audio 481 format requirements are specified in Section 8. 483 When language is specified, the language tag MUST use the [RFC5646] 484 syntax. 486 Logotype types defined in this specification are: 488 Community Logotype: If communityLogos is present, the logotypes 489 MUST represent one or more communities with which the certificate 490 issuer is affiliated. The communityLogos MAY be present in an end 491 entity certificate, a CA certificate, or an attribute certificate. 492 The communityLogos contains a sequence of Community Logotypes, 493 each representing a different community. If more than one 494 Community logotype is present, they MUST be placed in order of 495 preferred appearance. Some clients MAY choose to display a subset 496 of the present community logos; therefore the placement within the 497 sequence aids the client selection. The most preferred logotype 498 MUST be first in the sequence, and the least preferred logotype 499 MUST be last in the sequence. 501 Issuer Organization Logotype: If issuerLogo is present, the 502 logotype MUST represent the issuer's organization. The logotype 503 MUST be consistent with, and require the presence of, an 504 organization name stored in the organization attribute in the 505 issuer field (for either a public key certificate or attribute 506 certificate). The issuerLogo MAY be present in an end entity 507 certificate, a CA certificate, or an attribute certificate. 509 Subject Organization Logotype: If subjectLogo is present, the 510 logotype MUST represent the subject's organization. The logotype 511 MUST be consistent with, and require the presence of, an 512 organization name stored in the organization attribute in the 513 subject field (for either a public key certificate or attribute 514 certificate). The subjectLogo MAY be present in an end entity 515 certificate, a CA certificate, or an attribute certificate. 517 The relationship between the subject organization and the subject 518 organization logotype, and the relationship between the issuer and 519 either the issuer organization logotype or the community logotype, 520 are relationships asserted by the issuer. The policies and practices 521 employed by the issuer to check subject organization logotypes or 522 claims its issuer and community logotypes is outside the scope of 523 this document. 525 4.2. Conventions for LogotypeImageInfo 527 When the optional LogotypeImageInfo is included with a logotype 528 image, the parameters MUST be used with the following semantics and 529 restrictions. 531 The xSize and ySize fields represent the recommended display size for 532 the logotype image. When a value of 0 (zero) is present, no 533 recommended display size is specified. When non-zero values are 534 present and these values differ from corresponding size values in the 535 referenced image object, then the referenced image SHOULD be scaled 536 to fit within the size parameters of LogotypeImageInfo, while 537 preserving the x and y ratio. 539 The resolution field is redundant for all logotype image formats 540 listed in Section 7. The optional resolution field SHOULD be omitted 541 when the image format already contains this information. 543 4.3. Embedded Images 545 If the logotype image is provided through direct addressing, then the 546 image MAY be stored within the logotype certificate extension using 547 the "data" scheme [RFC2397]. The syntax of the "data" URI scheme 548 defined is included here for convenience: 550 dataurl := "data:" [ mediatype ] [ ";base64" ] "," data 551 mediatype := [ type "/" subtype ] *( ";" parameter ) 552 data := *urlchar 553 parameter := attribute "=" value 555 When including the image data in the logotype extension using the 556 "data" URI scheme, the following conventions apply: 558 * The value of mediaType in LogotypeDetails MUST be identical to the 559 media type value in the "data" URL. 561 * The hash of the image MUST be included in logotypeHash and MUST be 562 calculated over the same data as it would have been, had the image 563 been referenced through a link to an external resource. 565 NOTE: As the "data" URI scheme is processed as a data source rather 566 than as a URL, the image data is typically not limited by any URL 567 length limit settings that otherwise apply to URLs in general. 569 NOTE: Implementations need to be cautious about the size of images 570 included in a certificate in order to ensure that the size of the 571 certificate does not prevent the certificate from being used as 572 intended. 574 4.4. Other Logotypes 576 Logotypes identified by otherLogos (as defined in Section 4.1) can be 577 used to enhance the display of logotypes and marks that represent 578 partners, products, services, or any other characteristic associated 579 with the certificate or its intended application environment when the 580 standard logotype types are insufficient. 582 The conditions and contexts of the intended use of these logotypes 583 are defined at the discretion of the local client application. 585 Three other logotype types are defined in the follow subsections. 587 4.4.1. Loyalty Logotype 589 When a loyalty logotype appears in the otherLogos, it MUST be 590 identified by the id-logo-loyalty object identifier. 592 id-logo OBJECT IDENTIFIER ::= { id-pkix 20 } 594 id-logo-loyalty OBJECT IDENTIFIER ::= { id-logo 1 } 596 A loyalty logotype, if present, MUST contain a logotype associated 597 with a loyalty program related to the certificate or its use. The 598 relation between the certificate and the identified loyalty program 599 is beyond the scope of this document. The logotype extension MAY 600 contain more than one Loyalty logotype. 602 4.4.2. Certificate Background Logotype 604 When a certificate background logotype appears in the otherLogos, it 605 MUST be identified by the id-logo-background object identifier. 607 id-logo-background OBJECT IDENTIFIER ::= { id-logo 2 } 609 The certificate background logotype, if present, MUST contain a 610 graphical image intended as a background image for the certificate, 611 and/or a general audio sequence for the certificate. The background 612 image MUST allow black text to be clearly read when placed on top of 613 the background image. The logotype extension MUST NOT contain more 614 than one certificate background logotype. 616 4.4.3. Certificate Image Logotype 618 When a certificate image logotype appears in the otherLogos, it MUST 619 be identified by the id-logo-background object identifier. 621 id-logo-certImage OBJECT IDENTIFIER ::= { id-logo 3 } 623 The certificate image logotype, if present, aids human interpretation 624 of a certificate by providing meaningful visual information to the 625 user interface (UI). Typical situations when a human needs to 626 examine the visual representation of a certificate are: 628 * A person establishes a secured channel with an authenticated 629 service. The person needs to determine the identity of the 630 service based on the authenticated credentials. 632 * A person validates the signature on critical information, such as 633 signed executable code, and needs to determine the identity of the 634 signer based on the signer's certificate. 636 * A person is required to select an appropriate certificate to be 637 used when authenticating to a service or Identity Management 638 infrastructure. The person needs to see the available 639 certificates in order to distinguish between them in the selection 640 process. 642 The display of certificate information to humans is challenging due 643 to lack of well-defined semantics for critical identity attributes. 644 Unless the application has out-of-band knowledge about a particular 645 certificate, the application will not know the exact nature of the 646 data stored in common identification attributes such as serialNumber, 647 organizationName, country, etc. Consequently, the application can 648 display the actual data, but faces the problem of labeling that data 649 in the UI and informing the human about the exact nature (semantics) 650 of that data. It is also challenging for the application to 651 determine which identification attributes are important to display 652 and how to organize them in a logical order. 654 When present, the certificate image MUST be a complete visual 655 representation of the certificate. This means that the display of 656 this certificate image represents all information about the 657 certificate that the issuer subjectively defines as relevant to show 658 to a typical human user within the typical intended use of the 659 certificate, giving adequate information about at least the following 660 three aspects of the certificate: 662 * Certificate Context 664 * Certificate Issuer 666 * Certificate Subject 668 Certificate Context information is visual marks and/or textual 669 information that helps the typical user to understand the typical 670 usage and/or purpose of the certificate. 672 It is up to the issuer to decide what information -- in the form of 673 text, graphical symbols, and elements -- represents a complete visual 674 representation of the certificate. However, the visual 675 representation of Certificate Subject and Certificate Issuer 676 information from the certificate MUST have the same meaning as the 677 textual representation of that information in the certificate itself. 679 Applications providing a Graphical User Interface (GUI) to the 680 certificate user MAY present a certificate image according to this 681 standard in any given application interface, as the only visual 682 representation of a certificate. 684 5. Type of Certificates 686 Logotypes MAY be included in public key certificates and attribute 687 certificates at the discretion of the certificate issuer; however, 688 logotypes MUST NOT be part of certification path validation or any 689 type of automated processing. The sole purpose of logotypes is to 690 enhance the display of a particular certificate, regardless of its 691 position in a certification path. 693 6. Use in Clients 695 All PKI implementations require relying party software to have some 696 mechanism to determine whether a trusted CA issues a particular 697 certificate. This is an issue for certification path validation, 698 including consistent policy and name checking. 700 After a certification path is successfully validated, the replying 701 party trusts the information that the CA includes in the certificate, 702 including any certificate extensions. The client software can choose 703 to make use of such information, or the client software can ignore 704 it. If the client is unable to support a provided logotype, the 705 client MUST NOT report an error, rather the client MUST behave as 706 though no logotype extension was included in the certificate. 707 Current standards do not provide any mechanism for cross-certifying 708 CAs to constrain subordinate CAs from including private extensions 709 (see Section 9). 711 Consequently, if relying party software accepts a CA, then it should 712 be prepared to (unquestioningly) display the associated logotypes to 713 its human user, given that it is configured to do so. Information 714 about the logotypes is provided so that the replying party software 715 can select the one that will best meet the needs of the human user. 716 This choice depends on the abilities of the human user, as well as 717 the capabilities of the platform on which the replaying party 718 software is running. If none of the provided logotypes meets the 719 needs of the human user or matches the capabilities of the platform, 720 then the logotypes can be ignored. 722 A client MAY, subject to local policy, choose to display none, one, 723 or any number of the logotypes in the logotype extension. In many 724 cases, a client will be used in an environment with a good network 725 connection and also used in an environment with little or no network 726 connectivity. For example, a laptop computer can be docked with a 727 high-speed LAN connection, or it can be disconnected from the network 728 altogether. In recognition of this situation, the client MUST 729 include the ability to disable the fetching of logotypes. However, 730 locally cached logotypes can still be displayed when the user 731 disables the fetching of additional logotypes. 733 A client MAY, subject to local policy, choose any combination of 734 audio and image presentation for each logotype. That is, the client 735 MAY display an image with or without playing a sound, and it MAY play 736 a sound with or without displaying an image. A client MUST NOT play 737 more than one logotype audio sequence at the same time. 739 The logotype is to be displayed in conjunction with other identity 740 information contained in the certificate. The logotype is not a 741 replacement for this identity information. 743 Care is needed when designing replying party software to ensure that 744 an appropriate context of logotype information is provided. This is 745 especially difficult with audio logotypes. It is important that the 746 human user be able to recognize the context of the logotype, even if 747 other audio streams are being played. 749 If the relying party software is unable to successfully validate a 750 particular certificate, then it MUST NOT display any logotype data 751 associated with that certificate. 753 7. Image Formats 755 Animated images SHOULD NOT be used. 757 The following table lists many commons image formats and their 758 corresponding MIME type. The table also indicates which of the image 759 formats must be supported by implementations. The filename 760 extensions commonly used for each of these formats is also provided. 761 Implementations MAY support other image formats. 763 +========+====================+=========+============+============+ 764 | Format | MIME Type | .ext | References | Implement? | 765 +========+====================+=========+============+============+ 766 | JPEG | image/jpeg | .jpg | [JPEG] | MUST | 767 | | | .jpeg | [RFC2046] | support | 768 +--------+--------------------+---------+------------+------------+ 769 | GIF | image/gif | .gif | [GIF] | MUST | 770 | | | | [RFC2046] | support | 771 +--------+--------------------+---------+------------+------------+ 772 | SVG | image/svg+xml | .svg | [SVGT] | SHOULD | 773 | | | | [SVGR] | support | 774 +--------+--------------------+---------+------------+------------+ 775 | SVG + | image/svg+xml- | .svgz | [SVGT] | MUST | 776 | GZIP | compressed | .svg.gz | [SVGZR] | support | 777 +--------+--------------------+---------+------------+------------+ 778 | PNG | image/png | .png | [ISO15948] | SHOULD | 779 | | | | [PNGR] | support | 780 +--------+--------------------+---------+------------+------------+ 781 | PDF | application/pdf | .pdf | [ISO32000] | MAY | 782 | | | | [ISO19005] | support | 783 | | | | [RFC3778] | | 784 +--------+--------------------+---------+------------+------------+ 786 Table 1: Image Formats 788 NOTE: The image/svg+xml-compressed media type is widely implemented, 789 but it has not yet been registered with IANA. 791 When a Scalable Vector Graphics (SVG) image is used, whether the 792 image is compressed or not, the SVG Tiny profile [SVGT] MUST be 793 followed, with these additional restrictions: 795 * The SVG image MUST NOT contain any Internationalized Resource 796 Identifier (IRI) references to information stored outside of the 797 SVG image of type B, C, or D, according to Section 14.1.4 of 798 [SVGT]. 800 * The SVG image MUST NOT contain any 'script' element, according to 801 Section 15.2 of [SVGT]. 803 * The XML structure in the SVG file MUST use linefeed (0x0A) as the 804 end-of-line (EOL) character when calculating a hash over the SVG 805 image. 807 When a GZIP-compressed SVG image is fetched with HTTP, the client 808 will receive response that includes these headers: 810 Content-Type: image/svg+xml 811 Content-Encoding: gzip 813 In this case, the octet stream of type image/svg+xml is compressed 814 with GZIP [RFC1952] as specified in [SVGR]. 816 When a uncompressed SVG image is fetched with HTTP, the client will 817 receive response with the same Content-Type header, but no Content- 818 Encoding header. 820 Whether the SVG image is GZIP-compressed or uncompressed, the hash 821 value for the SVG image is calculated over the uncompressed SVG 822 content with canonicalized EOL characters as specified above. 824 When a SVG image is embedded in the certificate extension using the 825 "data" URL scheme, the SVG image data MUST be provided in GZIP- 826 compressed form, and the XML structure, prior to compression, SHOULD 827 use linefeed (0x0A) as the end-of-line (EOL) character. 829 When a bitmapped image is used, the PNG [ISO15948] format SHOULD be 830 used. 832 When a Portable Document Format (PDF) document according to 833 [ISO32000] is used, it MUST also be formatted according to the 834 profile PDF/A [ISO19005]. 836 8. Audio Formats 838 Implementations that support audio MUST support the MP3 audio format 839 [MP3] with a MIME type of "audio/mpeg" [RFC3003]. Implementations 840 MAY support other audio formats. 842 9. Security Considerations 844 Implementations that simultaneously display multiple logotype types 845 (subject organization, issuer, community, or other), MUST ensure that 846 there is no ambiguity as to the binding between the image and the 847 type of logotype that the image represents. "Logotype type" is 848 defined in Section 1.1, and it refers to the type of entity or 849 affiliation represented by the logotype, not the of binary format if 850 the image or audio. 852 Logotypes are very difficult to securely and accurately define. 853 Names are also difficult in this regard, but logotypes are even 854 worse. It is quite difficult to specify what is, and what is not, a 855 legitimate logotype of an organization. There is an entire legal 856 structure around this issue, and it will not be repeated here. 857 However, issuers should be aware of the implications of including 858 images associated with a trademark or servicemark before doing so. 859 As logotypes can be difficult (and sometimes expensive) to verify, 860 the possibility of errors related to assigning wrong logotypes to 861 organizations is increased. 863 This is not a new issue for electronic identification instruments. 864 It is already dealt with in a number of similar situations in the 865 physical world, including physical employee identification cards. In 866 addition, there are situations where identification of logotypes is 867 rather simple and straightforward, such as logotypes for well-known 868 industries and institutes. These issues should not stop those 869 service providers who want to issue logotypes from doing so, where 870 relevant. 872 It is impossible to prevent fraudulent creation of certificates by 873 dishonest or badly performing issuers, containing names and logotypes 874 that the issuer has no claim to or has failed to check correctly. 875 Such certificates could be created in an attempt to socially engineer 876 a user into accepting a certificate. The premise used for the 877 logotype work is thus that logotype graphics in a certificate are 878 trusted only if the certificate is successfully validated within a 879 valid path. It is thus imperative that the representation of any 880 certificate that fails to validate is not enhanced in any way by 881 using the logotype data. 883 This underlines the necessity for CAs to provide reliable services, 884 and the relying party's responsibility and need to carefully select 885 which CAs are trusted to provide public key certificates. 887 This also underlines the general necessity for relying parties to use 888 up-to-date software libraries to render or dereference data from 889 external sources, including logotype data in certificates, to 890 minimize risks related to processing potentially malicious data 891 before it has been adequately verified and validated. 893 Referenced image objects are hashed in order to bind the image to the 894 signature of the certificate. Some image types, such as SVG, allow 895 part of the image to be collected from an external source by 896 incorporating a reference to an external file that contains the 897 image. If this feature were used within a logotype image, the hash 898 of the image would only cover the URI reference to the external image 899 file, but not the referenced image data. Clients SHOULD verify that 900 SVG images meet all requirements listed in Section 7 and reject 901 images that contain references to external data. 903 Logotype data is fetched from a server when it is needed. By 904 watching activity on the network, an observer can determine which 905 clients are making use of certificates that contain particular 906 logotype data. This observation can potentially introduce privacy 907 issues. Since clients are expected to locally cache logotype data, 908 network traffic to the server containing the logotype data will not 909 be generated every time the certificate is used. In cases where 910 logotype data is not cashed, monitoring would reveal usage frequency. 911 In cases where logotype data is cached, monitoring would reveal when 912 a certain logotype image or audio sequence is used for the first 913 time. 915 CAs issuing certificates with embedded logotype images should be 916 cautious when accepting graphics from the certificate requestor for 917 inclusion in the certificate if the hash algorithm used to sign the 918 certificate is vulnerable to collision attacks. In such a case, the 919 accepted image may contain data that could help an attacker to obtain 920 colliding certificates with identical certificate signatures. 922 Certificates, and hence their logotype images, are commonly public 923 objects and as such usually will not contain privacy-sensitive 924 information. However, when a logotype image that is referenced from 925 a certificate contains privacy-sensitive information, appropriate 926 security controls should be in place to protect the privacy of that 927 information. Details of such controls are outside the scope of this 928 document. 930 Certification paths may also impose name constraints that are 931 systematically checked during certification path processing, which, 932 in theory, may be circumvented by logotypes. 934 Certificate path processing as defined in [RFC5280] does not 935 constrain the inclusion of logotype data in certificates. A parent 936 CA can constrain certification path validation such that subordinate 937 CAs cannot issue valid certificates to end-entities outside a limited 938 name space or outside specific certificate polices. A malicious CA 939 can comply with these name and policy requirements and still include 940 inappropriate logotypes in the certificates that it issues. These 941 certificates will pass the certification path validation algorithm, 942 which means the client will trust the logotypes in the certificates. 943 Since there is no technical mechanism to prevent or control 944 subordinate CAs from including the logotype extension or its 945 contents, where appropriate, a parent CA could employ a legal 946 agreement to impose a suitable restriction on the subordinate CA. 947 This situation is not unique to the logotype extension. 949 The controls available to a parent CA to protect itself from rogue 950 subordinate CAs are non-technical. They include: 952 * Contractual agreements of suitable behavior, including terms of 953 liability in case of material breach. 955 * Control mechanisms and procedures to monitor and follow-up 956 behavior of subordinate CAs. 958 * Use of certificate policies to declare an assurance level of 959 logotype data, as well as to guide applications on how to treat 960 and display logotypes. 962 * Use of revocation functions to revoke any misbehaving CA. 964 There is not a simple, straightforward, and absolute technical 965 solution. Rather, involved parties must settle some aspects of PKI 966 outside the scope of technical controls. As such, issuers need to 967 clearly identify and communicate the associated risks. 969 10. IANA Considerations 971 For the new ASN.1 Module in Appendix A.2, IANA is requested to assign 972 an object identifier (OID) for the module identifier. The OID for 973 the module should be allocated in the "SMI Security for PKIX Module 974 Identifier" registry (1.3.6.1.5.5.7.0). 976 11. Acknowledgments 977 11.1. Acknowledgments from RFC 3709 979 This document is the result of contributions from many professionals. 980 The authors appreciate contributions from all members of the IETF 981 PKIX Working Group. We extend a special thanks to Al Arsenault, 982 David Cross, Tim Polk, Russel Weiser, Terry Hayes, Alex Deacon, 983 Andrew Hoag, Randy Sabett, Denis Pinkas, Magnus Nystrom, Ryan Hurst, 984 and Phil Griffin for their efforts and support. 986 Russ Housley thanks the management at RSA Laboratories, especially 987 Burt Kaliski, who supported the development of this specification. 988 The vast majority of the work on this specification was done while 989 Russ was employed at RSA Laboratories. 991 11.2. Acknowledgments from RFC 6170 993 The authors recognize valuable contributions from members of the PKIX 994 working group, the CA Browser Forum, and James Manger, for their 995 review and sample data. 997 11.3. Additional Acknowledgments 999 Combining RFC 3709 and RFC 6170 has produced an improved 1000 specification. The authors appreciate contributions from all members 1001 of the IETF LAMPS Working Group. We extend a special thanks to Corey 1002 Bonnell for his carefule review and comments. 1004 12. References 1006 12.1. Normative References 1008 [GIF] CompuServe Incorporated, "Graphics Interchange Format", 1009 Version 89a, 31 July 1990, 1010 . 1012 [ISO15948] ISO/IEC, "Information technology -- Computer graphics and 1013 image processing -- Portable Network Graphics (PNG): 1014 Functional specification", ISO/IEC 15948:2004, 2004. 1016 [JPEG] ITU-T, "Information technology -- Digital compression and 1017 coding of continuous-tone still images: JPEG File 1018 Interchange Format (JFIF)", ITU-T Recommendation T.871, 1019 ISO/IEC 10918-5:2013, May 2011. 1021 [MP3] ISO/IEC, "Information technology -- Generic coding of 1022 moving pictures and associated audio information -- Part 1023 3: Audio", ISO/IEC 13818-3:1998, 1998. 1025 [NEW-ASN1] ITU-T, "Information technology -- Abstract Syntax Notation 1026 One (ASN.1): Specification of basic notation", ITU-T 1027 Recommendation X.680, ISO/IEC 8824-1:2021, February 2021, 1028 . 1030 [RFC1952] Deutsch, P., "GZIP file format specification version 4.3", 1031 RFC 1952, DOI 10.17487/RFC1952, May 1996, 1032 . 1034 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1035 Extensions (MIME) Part Two: Media Types", RFC 2046, 1036 DOI 10.17487/RFC2046, November 1996, 1037 . 1039 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1040 Requirement Levels", BCP 14, RFC 2119, 1041 DOI 10.17487/RFC2119, March 1997, 1042 . 1044 [RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1045 Resource Identifiers (URI): Generic Syntax", RFC 2396, 1046 DOI 10.17487/RFC2396, August 1998, 1047 . 1049 [RFC2397] Masinter, L., "The "data" URL scheme", RFC 2397, 1050 DOI 10.17487/RFC2397, August 1998, 1051 . 1053 [RFC3003] Nilsson, M., "The audio/mpeg Media Type", RFC 3003, 1054 DOI 10.17487/RFC3003, November 2000, 1055 . 1057 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 1058 Registration Procedures", RFC 4288, DOI 10.17487/RFC4288, 1059 December 2005, . 1061 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1062 Specifications: ABNF", STD 68, RFC 5234, 1063 DOI 10.17487/RFC5234, January 2008, 1064 . 1066 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1067 Housley, R., and W. Polk, "Internet X.509 Public Key 1068 Infrastructure Certificate and Certificate Revocation List 1069 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 1070 . 1072 [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying 1073 Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, 1074 September 2009, . 1076 [RFC5755] Farrell, S., Housley, R., and S. Turner, "An Internet 1077 Attribute Certificate Profile for Authorization", 1078 RFC 5755, DOI 10.17487/RFC5755, January 2010, 1079 . 1081 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 1082 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 1083 DOI 10.17487/RFC7540, May 2015, 1084 . 1086 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1087 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1088 May 2017, . 1090 [RFC8740] Benjamin, D., "Using TLS 1.3 with HTTP/2", RFC 8740, 1091 DOI 10.17487/RFC8740, February 2020, 1092 . 1094 [SVGT] World Wide Web Consortium, "Scalable Vector Graphics (SVG) 1095 Tiny 1.2 Specification", W3C PR-SVGTiny12-20081117, 17 1096 November 2008, 1097 . 1099 12.2. Informative References 1101 [ISO19005] ISO, "Document management -- Electronic document file 1102 format for long-term preservation -- Part 1: Use of PDF 1103 1.4 (PDF/A-1)", ISO 19005-1:2005, 2005. 1105 [ISO32000] ISO, "Document management -- Portable document format -- 1106 Part 1: PDF 1.7", ISO 32000-1:2008, 2008. 1108 [OLD-ASN1] CCITT, "Specification of Abstract Syntax Notation One 1109 (ASN.1)", CCITT Recommendation X.208, November 1988, 1110 . 1112 [PNGR] World Wide Web Consortium, "Media Type Registration for 1113 image/png", 1114 . 1116 [RFC3778] Taft, E., Pravetz, J., Zilles, S., and L. Masinter, "The 1117 application/pdf Media Type", RFC 3778, 1118 DOI 10.17487/RFC3778, May 2004, 1119 . 1121 [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the 1122 Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, 1123 DOI 10.17487/RFC5912, June 2010, 1124 . 1126 [RFC6268] Schaad, J. and S. Turner, "Additional New ASN.1 Modules 1127 for the Cryptographic Message Syntax (CMS) and the Public 1128 Key Infrastructure Using X.509 (PKIX)", RFC 6268, 1129 DOI 10.17487/RFC6268, July 2011, 1130 . 1132 [SVGR] World Wide Web Consortium, "Media Type Registration for 1133 image/svg+xml", . 1136 [SVGZR] "A separate MIME type for svgz files is needed", 1137 . 1139 Appendix A. ASN.1 Modules 1141 A.1. ASN.1 Modules with 1988 Syntax 1143 This appendix contains two ASN.1 modules, both using the old syntax 1144 [OLD-ASN1]. 1146 The first ASN.1 module provides the syntax for the Logotype 1147 certificate extension. Only comments have changed in the module from 1148 RFC 3709, and the IMPORTS now come from [RFC5280]. 1150 The second ASN.1 module provides the Certificate Image object 1151 identifier. The module is unchanged from RFC 6170. 1153 1154 LogotypeCertExtn 1155 { iso(1) identified-organization(3) dod(6) internet(1) 1156 security(5) mechanisms(5) pkix(7) id-mod(0) 1157 id-mod-logotype(22) } 1159 DEFINITIONS IMPLICIT TAGS ::= 1160 BEGIN 1162 IMPORTS 1163 AlgorithmIdentifier FROM PKIX1Explicit88 -- RFC 5280 1164 { iso(1) identified-organization(3) dod(6) internet(1) 1165 security(5) mechanisms(5) pkix(7) id-mod(0) 1166 id-pkix1-explicit(18) }; 1168 -- Logotype Extension OID 1169 id-pe-logotype OBJECT IDENTIFIER ::= 1170 { iso(1) identified-organization(3) dod(6) internet(1) 1171 security(5) mechanisms(5) pkix(7) id-pe(1) 12 } 1173 -- Logotype Extension Syntax 1175 LogotypeExtn ::= SEQUENCE { 1176 communityLogos [0] EXPLICIT SEQUENCE OF LogotypeInfo OPTIONAL, 1177 issuerLogo [1] EXPLICIT LogotypeInfo OPTIONAL, 1178 subjectLogo [2] EXPLICIT LogotypeInfo OPTIONAL, 1179 otherLogos [3] EXPLICIT SEQUENCE OF OtherLogotypeInfo 1180 OPTIONAL } 1182 -- Note: At least one of the OPTIONAL components MUST be present 1184 LogotypeInfo ::= CHOICE { 1185 direct [0] LogotypeData, 1186 indirect [1] LogotypeReference } 1188 LogotypeData ::= SEQUENCE { 1189 image SEQUENCE OF LogotypeImage OPTIONAL, 1190 audio [1] SEQUENCE OF LogotypeAudio OPTIONAL } 1192 -- Note: At least one of the OPTIONAL components MUST be present 1194 LogotypeImage ::= SEQUENCE { 1195 imageDetails LogotypeDetails, 1196 imageInfo LogotypeImageInfo OPTIONAL } 1198 LogotypeAudio ::= SEQUENCE { 1199 audioDetails LogotypeDetails, 1200 audioInfo LogotypeAudioInfo OPTIONAL } 1202 LogotypeDetails ::= SEQUENCE { 1203 mediaType IA5String, -- MIME media type name and optional 1204 -- parameters 1205 logotypeHash SEQUENCE SIZE (1..MAX) OF HashAlgAndValue, 1206 logotypeURI SEQUENCE SIZE (1..MAX) OF IA5String } 1208 LogotypeImageInfo ::= SEQUENCE { 1209 type [0] LogotypeImageType DEFAULT color, 1210 fileSize INTEGER, -- In octets 1211 xSize INTEGER, -- Horizontal size in pixels 1212 ySize INTEGER, -- Vertical size in pixels 1213 resolution LogotypeImageResolution OPTIONAL, 1214 language [4] IA5String OPTIONAL } -- RFC 5646 Language Tag 1216 LogotypeImageType ::= INTEGER { grayScale(0), color(1) } 1218 LogotypeImageResolution ::= CHOICE { 1219 numBits [1] INTEGER, -- Resolution in bits 1220 tableSize [2] INTEGER } -- Number of colors or grey tones 1222 LogotypeAudioInfo ::= SEQUENCE { 1223 fileSize INTEGER, -- In octets 1224 playTime INTEGER, -- In milliseconds 1225 channels INTEGER, -- 1=mono, 2=stereo, 4=quad 1226 sampleRate [3] INTEGER OPTIONAL, -- Samples per second 1227 language [4] IA5String OPTIONAL } -- RFC 5646 Language Tag 1229 OtherLogotypeInfo ::= SEQUENCE { 1230 logotypeType OBJECT IDENTIFIER, 1231 info LogotypeInfo } 1233 LogotypeReference ::= SEQUENCE { 1234 refStructHash SEQUENCE SIZE (1..MAX) OF HashAlgAndValue, 1235 refStructURI SEQUENCE SIZE (1..MAX) OF IA5String } 1236 -- Places to get the same LogotypeData 1237 -- image or audio object 1239 -- Note: The referenced LogotypeData binary file contain DER-encoded 1240 -- LogotypeData type 1242 HashAlgAndValue ::= SEQUENCE { 1243 hashAlg AlgorithmIdentifier, 1244 hashValue OCTET STRING } 1246 -- Other logotype type OIDs 1248 id-logo OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 1249 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 20 } 1251 id-logo-loyalty OBJECT IDENTIFIER ::= { id-logo 1 } 1253 id-logo-background OBJECT IDENTIFIER ::= { id-logo 2 } 1255 END 1257 CERT-IMAGE-MODULE { iso(1) identified-organization(3) dod(6) 1258 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 1259 id-mod-logotype-certimage(68) } 1261 DEFINITIONS EXPLICIT TAGS ::= 1262 BEGIN 1263 EXPORTS ALL; -- export all items from this module 1265 id-logo-certImage OBJECT IDENTIFIER ::= 1266 { iso(1) identified-organization(3) dod(6) internet(1) 1267 security(5) mechanisms(5) pkix(7) id-logo(20) 3 } 1269 END 1270 1272 A.2. ASN.1 Module with 1997 Syntax 1274 Some developers like to use the latest version of ASN.1 standards. 1275 This appendix provides an ASN.1 module to assist in that goal. It 1276 uses the ASN.1 syntax defined in [NEW-ASN1], and it follows the 1277 conventions established in [RFC5912] and [RFC6268]. 1279 This ASN.1 module incorporates the module from RFC 3709 and the 1280 module from RFC 6170. 1282 1283 LogotypeCertExtn 1284 { iso(1) identified-organization(3) dod(6) internet(1) 1285 security(5) mechanisms(5) pkix(7) id-mod(0) 1286 id-mod-logotype(TBD) } 1288 DEFINITIONS IMPLICIT TAGS ::= 1289 BEGIN 1291 IMPORTS 1292 EXTENSION 1293 FROM PKIX-CommonTypes-2009 -- RFC 5912 1294 { iso(1) identified-organization(3) dod(6) internet(1) 1295 security(5) mechanisms(5) pkix(7) id-mod(0) 1296 id-mod-pkixCommon-02(57) } 1298 AlgorithmIdentifier{}, DIGEST-ALGORITHM 1299 FROM AlgorithmInformation-2009 1300 { iso(1) identified-organization(3) dod(6) internet(1) 1301 security(5) mechanisms(5) pkix(7) id-mod(0) 1302 id-mod-algorithmInformation-02(58) } ; 1304 -- Logotype Extension 1306 ext-logotype EXTENSION ::= { 1307 SYNTAX LogotypeExtn 1308 IDENTIFIED BY id-pe-logotype } 1310 -- Logotype Extension OID 1312 id-pe-logotype OBJECT IDENTIFIER ::= 1313 { iso(1) identified-organization(3) dod(6) internet(1) 1314 security(5) mechanisms(5) pkix(7) id-pe(1) 12 } 1316 -- Logotype Extension Syntax 1318 LogotypeExtn ::= SEQUENCE { 1319 communityLogos [0] EXPLICIT SEQUENCE OF LogotypeInfo OPTIONAL, 1320 issuerLogo [1] EXPLICIT LogotypeInfo OPTIONAL, 1321 subjectLogo [2] EXPLICIT LogotypeInfo OPTIONAL, 1322 otherLogos [3] EXPLICIT SEQUENCE OF OtherLogotypeInfo 1323 OPTIONAL } 1324 -- At least one of the OPTIONAL components MUST be present 1325 ( WITH COMPONENTS { ..., communityLogos PRESENT } | 1326 WITH COMPONENTS { ..., issuerLogo PRESENT } | 1327 WITH COMPONENTS { ..., subjectLogo PRESENT } | 1328 WITH COMPONENTS { ..., otherLogos PRESENT } ) 1330 LogotypeInfo ::= CHOICE { 1331 direct [0] LogotypeData, 1332 indirect [1] LogotypeReference } 1334 LogotypeData ::= SEQUENCE { 1335 image SEQUENCE OF LogotypeImage OPTIONAL, 1336 audio [1] SEQUENCE OF LogotypeAudio OPTIONAL } 1337 -- At least one of the OPTIONAL components MUST be present 1338 ( WITH COMPONENTS { ..., image PRESENT } | 1339 WITH COMPONENTS { ..., audio PRESENT } ) 1341 LogotypeImage ::= SEQUENCE { 1342 imageDetails LogotypeDetails, 1343 imageInfo LogotypeImageInfo OPTIONAL } 1345 LogotypeAudio ::= SEQUENCE { 1346 audioDetails LogotypeDetails, 1347 audioInfo LogotypeAudioInfo OPTIONAL } 1349 LogotypeDetails ::= SEQUENCE { 1350 mediaType IA5String, -- MIME media type name and optional 1351 -- parameters 1352 logotypeHash SEQUENCE SIZE (1..MAX) OF HashAlgAndValue, 1353 logotypeURI SEQUENCE SIZE (1..MAX) OF IA5String } 1355 LogotypeImageInfo ::= SEQUENCE { 1356 type [0] LogotypeImageType DEFAULT color, 1357 fileSize INTEGER, -- In octets 1358 xSize INTEGER, -- Horizontal size in pixels 1359 ySize INTEGER, -- Vertical size in pixels 1360 resolution LogotypeImageResolution OPTIONAL, 1361 language [4] IA5String OPTIONAL } -- RFC 5646 Language Tag 1363 LogotypeImageType ::= INTEGER { grayScale(0), color(1) } 1365 LogotypeImageResolution ::= CHOICE { 1366 numBits [1] INTEGER, -- Resolution in bits 1367 tableSize [2] INTEGER } -- Number of colors or grey tones 1369 LogotypeAudioInfo ::= SEQUENCE { 1370 fileSize INTEGER, -- In octets 1371 playTime INTEGER, -- In milliseconds 1372 channels INTEGER, -- 1=mono, 2=stereo, 4=quad 1373 sampleRate [3] INTEGER OPTIONAL, -- Samples per second 1374 language [4] IA5String OPTIONAL } -- RFC 5646 Language Tag 1376 OtherLogotypeInfo ::= SEQUENCE { 1377 logotypeType OBJECT IDENTIFIER, 1378 info LogotypeInfo } 1380 LogotypeReference ::= SEQUENCE { 1381 refStructHash SEQUENCE SIZE (1..MAX) OF HashAlgAndValue, 1382 refStructURI SEQUENCE SIZE (1..MAX) OF IA5String } 1383 -- Places to get the same LogotypeData 1384 -- image or audio object 1386 -- Note: The referenced LogotypeData binary file contain DER-encoded 1387 -- LogotypeData type 1389 HashAlgAndValue ::= SEQUENCE { 1390 hashAlg AlgorithmIdentifier{DIGEST-ALGORITHM, {...}}, 1391 hashValue OCTET STRING } 1393 -- Other logotype type OIDs 1395 id-logo OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 1396 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 20 } 1398 id-logo-loyalty OBJECT IDENTIFIER ::= { id-logo 1 } 1400 id-logo-background OBJECT IDENTIFIER ::= { id-logo 2 } 1402 id-logo-certImage OBJECT IDENTIFIER ::= { id-logo 3 } 1404 END 1405 1407 Appendix B. Examples 1409 B.1. Example from RFC 3709 1411 The following example displays a logotype extension containing one 1412 Issuer logotype using direct addressing. The issuer logotype image 1413 is of the type image/gif. The logotype image is referenced through 1414 one URI and the image is hashed with SHA-1. This example is 1415 unchanged from RFC 3709, except that shallow indenting is used to 1416 keep the example within traditional margins. The use of SHA-1 was 1417 reasonable at the time that RFC 3709 was published, but many better 1418 choices are available today. 1420 The values on the left are the ASN.1 tag (in hexadecimal) and the 1421 length (in decimal). 1423 30 106: SEQUENCE { 1424 06 8: OBJECT IDENTIFIER logotype (1 3 6 1 5 5 7 1 12) 1425 04 94: OCTET STRING, encapsulates { 1426 30 92: SEQUENCE { 1427 A1 90: [1] { 1428 A0 88: [0] { 1429 30 86: SEQUENCE { 1430 30 84: SEQUENCE { 1431 30 82: SEQUENCE { 1432 16 9: IA5String 'image/gif' 1433 30 33: SEQUENCE { 1434 30 31: SEQUENCE { 1435 30 7: SEQUENCE { 1436 06 5: OBJECT IDENTIFIER sha1 (1 3 14 3 2 26) 1437 : } 1438 04 20: OCTET STRING 1439 : 8F E5 D3 1A 86 AC 8D 8E 6B C3 CF 80 6A D4 48 18 1440 : 2C 7B 19 2E 1441 : } 1442 : } 1443 30 34: SEQUENCE { 1444 16 32: IA5String 'http://logo.example.com/logo.gif' 1445 : } 1446 : } 1447 : } 1448 : } 1449 : } 1450 : } 1451 : } 1452 : } 1453 : } 1455 B.2. Issuer Logotype Example 1457 The following example displays a logotype extension containing one 1458 Issuer logotype using direct addressing. The issuer logotype image 1459 is of the type image/jpeg. The logotype image is referenced through 1460 one URI and the image is hashed with SHA-256. 1462 The values on the left are the ASN.1 tag (in hexadecimal) and the 1463 length (in decimal). 1465 30 124: SEQUENCE { 1466 06 8: OBJECT IDENTIFIER logotype (1 3 6 1 5 5 7 1 12) 1467 04 112: OCTET STRING, encapsulates { 1468 30 110: SEQUENCE { 1469 A1 108: [1] { 1470 A0 106: [0] { 1471 30 104: SEQUENCE { 1472 30 102: SEQUENCE { 1473 30 100: SEQUENCE { 1474 16 10: IA5String 'image/jpeg' 1475 30 49: SEQUENCE { 1476 30 47: SEQUENCE { 1477 30 11: SEQUENCE { 1478 06 9: OBJECT IDENTIFIER 1479 : sha-256 (2 16 840 1 101 3 4 2 1) 1480 : } 1481 04 32: OCTET STRING 1482 : 1E 8F 96 FD D3 50 53 EF C6 1C 9F FC F0 00 2E 53 1483 : B4 9C 24 9A 32 C5 E9 0C 2C 39 39 D3 AD 6D A9 09 1484 : } 1485 : } 1486 30 35: SEQUENCE { 1487 16 33: IA5String 'http://logo.example.com/logo.jpeg' 1488 : } 1489 : } 1490 : } 1491 : } 1492 : } 1493 : } 1494 : } 1495 : } 1496 : } 1498 B.3. Embedded Image Example 1500 The following example displays a logotype extension containing one 1501 Subject logotype using direct addressing. The subject logotype image 1502 uses image/svg+xml-compressed. The logotype image is embedded in the 1503 certificate extension with a "data:" URI and the image is hashed by 1504 SHA-256. This technique produces a large certificate extension, but 1505 offers reduced latency and improved privacy. 1507 The values on the left are the ASN.1 tag (in hexadecimal) and the 1508 length (in decimal). 1510 30 2160: SEQUENCE { 1511 06 8: OBJECT IDENTIFIER logotype (1 3 6 1 5 5 7 1 12) 1512 04 2146: OCTET STRING, encapsulates { 1513 30 2142: SEQUENCE { 1514 A2 2138: [2] { 1515 A0 2134: [0] { 1516 30 2130: SEQUENCE { 1517 30 2126: SEQUENCE { 1518 30 2122: SEQUENCE { 1519 16 24: IA5String 'image/svg+xml-compressed' 1520 30 49: SEQUENCE { 1521 30 47: SEQUENCE { 1522 30 11: SEQUENCE { 1523 06 9: OBJECT IDENTIFIER 1524 : sha-256 (2 16 840 1 101 3 4 2 1) 1525 : } 1526 04 32: OCTET STRING 1527 : C5 AC 94 1A 0A 25 1F B3 16 6F 97 C5 52 40 9B 49 1528 : 9E 7B 92 61 5A B0 A2 6C 19 BF B9 D8 09 C5 D9 E7 1529 : } 1530 : } 1531 30 2041: SEQUENCE { 1532 16 2037: IA5String 1533 : 'data:image/svg+xml-compressed;base64,H4sICIGpy2E' 1534 : 'AA2xvZ28tY29weS5zdmcApVbbbhs3EH3nV0y3Lw2Q9fK2JLe' 1535 : 'wHDROUBRo2iBxW+RRlTa2UFkypIWV5ut7zlB2UqF9cuLlUkt' 1536 : 'yLmfOzPD8xafbtdyPu/1qu5k17sw2sp/mm+V8vd2Ms2azbV5' 1537 : 'cmPNvXv16efXh7WvZ31/L299e/vzTpTRt1/0RLrvu1dUref/' 1538 : '7j+KtdXawsete/9IYaW6m6e77rjscDmeHcLbdXXdX7zpu6t6' 1539 : '9vmxxon08AREdRDt7tpyWDRRSz7+tgp2b/ew/hEKI5WGoPKy' 1540 : 'W082s8SmeWf13NzVyM66ub6ZZk+xXH+9X4+Hl9tOssWLly35' 1541 : '53ARpd7txP+7uxx/2d+NiejefVttZ8+nNavkBj9yO40RLb8d' 1542 : 'pvpxP8wtzuRvn07iUP/+Wu+20my9GcWfOPpfDbjVN44YLb8d' 1543 : 'p3Mn7cb3aXGNCAICCc+a8+yLo/FpwfLP/uN3dzhqdriH5uwf' 1544 : 'bnj9a+Uz2i/maK66utA+zZ435uFqvZ823R38Q1t32Lw3pZqT' 1545 : 'hd/PpRpaz5o2LNkocvCzaIm0vrQvSpog359lLy3my0ga+e3H' 1546 : 'p+B4InjVFPD9awdhnrGEFW30Sl/Pnpvta2QBVxUEVxFbJ2VU' 1547 : 'FfYC01pUs+O4GK84V/k6CHUFyhvhiDVQF8Y5aPDbmnsrXbS7' 1548 : '4DANjguwgENZLPwjUYVTRJQgEpiLR0ctiWj+Ig8rCvZAArxK' 1549 : 'ExEEWMJLqMA1F+ggnsQDXgpQeomJPCVhtCRycNrAWxgAI+g1' 1550 : 'Qsr6IUxlomBswjydYBEgOeVCDoRreBjiFjX2SdSA60BP5DgQ' 1551 : 'M63xoPlWHbNq+egAEeAzxyNAdCQz+sDEMOhaGisKJdSlS6gt' 1552 : 'WWm4M1rQwP0egEBIhhFLoXuCJhR4mT5RJBaiLKqqFROUEzYr' 1553 : '1idG0gahwCzEnk+AMJLdp0FevQQ6VZ+SKOwGlOIJOh1MVjo0' 1554 : 'eB6DRA10SRpSY6il/eFFKAm+MKSIWNFqSo4OFnORfwH5wJHC' 1555 : 'MNM0qlDRlcIwUEkDlgiSBhiEpBgMKOx5FdAYqI3KYewKKkAI' 1556 : 'tTABTkp5khI86kgbOgRywEBR0VGcwAjf8t9wqvdUMG6gLAbI' 1557 : '0QQ8CbzCTtCSn/DEhCbm++duQaiRG1mQkdWHnminHA+r5wpL' 1558 : 'vsJbCALUKsDW5NAj43J+AD5vpfamUzJqiRJACmCWwIMhQq4H' 1559 : 'mYGKaiiJPmIvpS80UzTtAjdSraApQZogslgFcJHw0y5WoEXD' 1560 : 'Yr/aTqfxk2qhcg3z6ETQL+S18llvHOZQvlEOVEVpzqCozE9V' 1561 : '6JZhh/lCslg7mUFY4AR7IlcApmgV6gz3DCSDe56fQ0SRS7el' 1562 : '0NJWO8mQ6mkc6ylPpaL7QUZ5IR/M/dEwoJiEp+L6iT4cdSyI' 1563 : 'p4ljDkoaZpQlgMoz0ApahjTiTWbZYu9v+MUqVjY61j2Bxr68' 1564 : 'bPF3uS1232qAyAQDMhr4MRyVZq5l2QcuwgY/oTozbgoIKycH' 1565 : '+yQxhzQsPJQ/ne9OmRKvYH1AeKA/EQRtzrmaYUiHUhpJOW4b' 1566 : 'reSaxZ/TVc3ZAQJKOagAJiw6pRHVkBMIBa5E+SUMWi0ZNW1R' 1567 : 'fn/xQXywHXyMHN5G8WF6gZ2IVjANHMIJQ1lAJQE8MJjZHJiU' 1568 : 'tQZAWzmkisDywTVWSqLkkQG2NNB3wwyaerqRGLNKpvwUOhaQ' 1569 : 'FiYcqviSjvp1n8WnRRzXFs9IXDxiiDd8HU/ROoAGn9+QgTPE' 1570 : 'Vu6HaN6i0VPuv1SCzwyZeHwBA1EjFYoAk2jJ3OFeJ5Gp1E+3' 1571 : 'Dlf3Aj70bbvmag5oyKHunVyGPq6+EnvTua/JUn3iadMHlqUa' 1572 : 'psK2T8SwCBJUF1JnEmhu0ntBthJoQpZqumsBk5mA1hRc0LR5' 1573 : 'ZFerdjksaCqt3IUWXcXW16vb6xdWyHLTgCaKXWKUKK1kOp9H' 1574 : 'K5B3ELjSdXb0loB5RYtS01L6h9yTPW51Wpqwgosr5I927aw6' 1575 : '401+YfwDria4WoQwAAA==' 1576 : } 1577 : } 1578 : } 1579 : } 1580 : } 1581 : } 1582 : } 1583 : } 1584 : } 1586 B.4. Embedded Certificate Image Example 1588 The following example displays a logotype extension containing one 1589 Certificate Image logotype using direct addressing. The Certificate 1590 Image logotype uses image/svg+xml-compressed. The logotype image is 1591 embedded in the certificate extension with a "data:" URI and the 1592 image is hashed by SHA-256. This example contains the image from 1593 Appendix B of RFC 6170, however, the media type used here is explicit 1594 about the use of GZIP compression [RFC1952]. 1596 The values on the left are the ASN.1 tag (in hexadecimal) and the 1597 length (in decimal). 1599 30 2910: SEQUENCE { 1600 06 8: OBJECT IDENTIFIER logotype (1 3 6 1 5 5 7 1 12) 1601 04 2896: OCTET STRING, encapsulates { 1602 30 2892: SEQUENCE { 1603 A3 2888: [3] { 1604 30 2884: SEQUENCE { 1605 30 2880: SEQUENCE { 1606 06 8: OBJECT IDENTIFIER '1 3 6 1 5 5 7 20 3' 1607 A0 2866: [0] { 1608 30 2862: SEQUENCE { 1609 30 2858: SEQUENCE { 1610 16 24: IA5String 'image/svg+xml-compressed' 1611 30 49: SEQUENCE { 1612 30 47: SEQUENCE { 1613 30 11: SEQUENCE { 1614 06 9: OBJECT IDENTIFIER 1615 : sha-256 (2 16 840 1 101 3 4 2 1) 1616 : } 1617 04 32: OCTET STRING 1618 : 83 14 B3 26 9B D3 8B 0B 2A E6 6E 42 74 E2 A7 57 1619 : 7A 40 B7 E1 2E 53 42 44 CC 7C AE 14 68 1B 0E B6 1620 : } 1621 : } 1622 30 2777: SEQUENCE { 1623 16 2773: IA5String 1624 : 'data:image/svg+xml-compressed;base64,H4sICLXutU0' 1625 : 'AA0NlcnRJbWFnZURlbW8uc3ZnANVaW2/bOBZ+n19BqBigwdo' 1626 : 'S7xK9jmeapB0EWHQHzez2WZZoR1tZMiQ5jvvr95CSL7Gl1Em' 1627 : '8C9d9iERSPOd85+O5EB3+9jhL0YMuyiTPLh3iYgfpLMrjJJt' 1628 : 'eOv/661M/cFBZhVkcpnmmL50sd34b/TIsH6YoiS+da11UySS' 1629 : 'Jwkqj21k41Q6CDbNyUMSTS+e+quYDz1sul+6SuXkx9YhSysP' 1630 : 'Uo7QPK/rlKqvCx35Wvmu+a/uGYow9EOigh0Qvr/LHSwcjjDj' 1631 : 'GiGHQ914n0/sKlMf4Vwctk7i6X7/sGEYdNA5L/WeRT5IUDKm' 1632 : 'SbLVWNoo2cqNCh1XyoKN8Nsuz0iqwVW8Qb1fOF0Vqp+PI06m' 1633 : 'e6awqPeISzxn9goYzXYVxWIUWpfWLCMwcGoLpgy83n8wzGkb' 1634 : 'R4GtefENmMBznC7DEroKpOBpM8mIWVqPEYGtA+BvoMfS2E5u' 1635 : 'F1Wqu7R6FLvNFEelWReNolpiV3l2VpGntMW9nk6RKdf0+9Br' 1636 : 'FrMbeVuWhtzbHvMR6UlobPyVpBWjXBk7six2vH5nCwY6nXCo' 1637 : '5xb7YusvFVPqCOGh16fSxSxglmPkScLfvmDDmC4FlDc1wov8' 1638 : 'IF2WZhNlVumgEPRliimDD3PhGPyTgUUMC6lKqKAjxaptq1bo' 1639 : 'UJvQFsvi+LOJyxZkPE/vCwHuAmXmoj1AarnRBatzqkbv7cK5' 1640 : 'Ls2ORfwM/vsOG5lURZqXxOnDXPKZw5t5jVzIhFKO0B6D6hAR' 1641 : 'SXDR6Fzqq7H7mQeJAOQiUSPvFIrUHOfuui3zrFI5dYVeAmpc' 1642 : 'OcOb9u63vLjae4kYX4yRifYPrTa2SlMigYdO+cEWeGADMLZL' 1643 : 'H96SH4R9xRYApl6q3Y02f+NzlRAl+cZSKhB6qSIVa80fsqMn' 1644 : 'WOqZJpmsXwAPoyNaQ95uNIGasKPwhxGzQzOXzMIIzBKabmLI' 1645 : 'il470zfSjWWn+kvpvLQ9g1l3yRIc8gukz0uysEcakcDfy3KM' 1646 : 'k+l0SOXlOopltJL7EPtUlzZfP4tnM70k8xkKCySt92MwfIXP' 1647 : 'oTe0pnu4dYbp7hJ/kxWySN0ey0o/1qbiCsxDXJMWWo37QekB' 1648 : 'cAUFPSGkPCnUJF5wwBacDK5cGlEp4BC2lYoJcrNNGVc7DzIq' 1649 : 'xT4CKsPlrAG8mL8whRejiQe9EmImIAoz3sds9NxP4RZEzugq' 1650 : 'zb7c3Q89u3WQKY9aegbsA/AUJB/bJs6pfJt9BHFEuk5DWITz' 1651 : 'OH5uZSThLUsDjQ5GE6RMsyihMTaQLfA6BIiAQMAhnHHN1sd6' 1652 : '1WtUhDVJiuhkrdBXd740+hLB9Vm1HjQe4ywLOBLWOMMiyQAX' 1653 : 'NB8sm9Gx2qdGgGkMG6wY8aLfqgH4dfnmrVc+pPrE/Z/QnZOs' 1654 : '8C1Okb2/ggwLdxlDC1D6DFPZDD98txv8xQf5TEc7Ax6ZyaDf' 1655 : '6BC4SylWKCMqtizp80+UMchATal63qHq0M3ZTs83Ob/XO6LY' 1656 : 'sFzpGVY5+iLxdWvwY+NaKoR/0iJIXL3dBjT2hG+wO+NXm53X' 1657 : 'StSh1eogfeojV35BTOaqh/cmPUe2Mdp91pQp2CjWOO2k7Oam' 1658 : 'hjU1HB3DLGm66n6iajz4bqn2oICmNFxDR/x2mC5s+rKhlkUA' 1659 : '3Ne3P8lgP0qJfjf9uvu+HWXSfFwNoH4uqGUmTadYMtOc7yjE' 1660 : 'Ed9EUhkwEEOcDSHKQ+yhnSvUYRH8miQo2FK5TCjWZZGWKB8i' 1661 : 'HPud16wApnCvTOzjIFAj9TQdCxa+ddOTizaa1xJvD0qMrKx+' 1662 : 'Ydaj6iwJQG0vaSdYWpTv4HwVRAP3Z6ONjOJunEIeKRVmhujp' 1663 : 'A2+wPmQR9WFQAFhh9bGQzFEXX+WwOnXq8pV35P2Acdn0pGeb' 1664 : 'cMg7OgQKaEdOKEAkFlk/9HuEKGBVwucc4AjnJ/LBYU09hVwW' 1665 : 'Y1F0HlBUC2lbyIuYF58O8p+adMwUt9YAoX/IwRtAC9NAdBAy' 1666 : 'GuEB3VR59u8/TGYx9/Xjz8bPB/Z/F9B0SghBK+4xxfiwtr0G' 1667 : 'XECqedQQ9PRVpEAQ+26MidbGSmPm8RwRzcQsT17EPSmoorH3' 1668 : '+av4Jcj78O/vIp/uzMEkHKAE6/F7VHHSj8HddR0Q3ymcGZfR' 1669 : 'VjwfmOnNn3GuWR+FzhcPmPqiptHcayacT28T8j3Cs0/LQCwo' 1670 : '6J2iYxP4R58AsobjFegusoJhuq7VNS2evRPcqASvQki+gbkB' 1671 : 'YwETNPt/1A2pT6UErR1zMzUITZRvF5Lp5basO1fk2U4aBSjk' 1672 : 'ji8quL3cDyW7TpI3unxezMcSTNhQJhfpGctKgKN2Amo7/7Sh' 1673 : 'Sev4oXicPSYS+6GkCm9a1Qw3VEchCUA+z5HtTcbQhK6F14YF' 1674 : 'Up+Yn7WgmzwpZCDf5DDiXT9B7U6RdHAHpdb7IqmLVjqZSLnT' 1675 : 'W61zjQ7/G7D3hm9E846uTDZoNMADmLlm7IG2ieXfUtu1US9T' 1676 : 'eNGUHibE9Nv//2jRJGZfQmK3v7ykJJOv1IXjBsDCPpmgWppe' 1677 : '6sHxR3KVSQKqp+WIqammuJbtqkxZmMHry4oS/9pLhdCXKq8u' 1678 : 'R0R+LDEqCKRxqc5VXdvPvIP+ggwR0RkyBfO9iKZvrWGAKVdz' 1679 : '31cuocvoO/qemClFMYEFEH7oI+vpkek4s4bCMBqK+5mHQUlD' 1680 : 'pE/oylpy+2/6pWXK31PEYagP04epV1cE50UMy6IQZeQM7+Ol' 1681 : '74Z+eHfpHNc7OjffQ/HeV0X8BopoDkGEkAAA=' 1682 : } 1683 : } 1684 : } 1685 : } 1686 : } 1687 : } 1688 : } 1689 : } 1690 : } 1691 : } 1693 Appendix C. Changes Since RFC 3709 1695 This appendix summarizes the changes since RFC 3709. The changes 1696 are: 1698 * Combine RFC 3709 and RFC 6170 into one document, and encourage 1699 implementers to support the "data" URI scheme (data:...) that was 1700 originally specified in RFC 6170. Merging RFC 3709 and RFC 6170 1701 lead to many editoral changes throughout the document. 1703 * Drop SHA-1 as the mandatory-to-implement hash algorithm, and 1704 encourage use of the one-way hash function that is employed by the 1705 certificate signature algorithm. 1707 * Update the reference for language tags to be RFC 5646 instead of 1708 the now obsolete RFC 3066. 1710 * No longer require support for the FTP scheme (ftp://...) URI. 1712 * Require support for the HTTP scheme (http://...) URI and the HTTPS 1713 scheme (https://...) URI. 1715 * Require support for the compressed SVG image format with the 1716 image/svg+xml-compressed media type. 1718 * Media types MUST follow the ABNF [RFC5234] that is provided in 1719 Section 4.2 of [RFC4288]. This change resolves Errata ID 2679. 1721 * Remove the requirement that the LogotypeData file name have a file 1722 extension of ".LTD". This change resolves Errata ID 2325. 1724 * Provide ASN.1 modules for the older syntax [OLD-ASN1] and most 1725 recent syntax [NEW-ASN1]. 1727 * Provide additional references. 1729 * Provide additional examples. 1731 Authors' Addresses 1732 Stefan Santesson 1733 IDsec Solutions AB 1734 Forskningsbyn Ideon 1735 SE-223 70 Lund 1736 Sweden 1738 Email: sts@aaa-sec.com 1740 Russ Housley 1741 Vigil Security, LLC 1742 516 Dranesville Road 1743 Herndon, VA, 20170 1744 United States of America 1746 Email: housley@vigilsec.com 1748 Trevor Freeman 1749 Amazon Web Services 1750 1918 8th Ave 1751 Seattle, WA, 98101 1752 United States of America 1754 Email: frtrevor@amazon.com 1756 Leonard Rosenthol 1757 Adobe 1758 345 Park Avenue 1759 San Jose, CA, 95110 1760 United States of America 1762 Email: lrosenth@adobe.com