RFC 3709
Internet X.509 Public Key Infrastructure: Logotypes in X.509 Certificates
RFC 3709: Logotypes in X.509 Certificates 🎀
Okay bestie, this one is RFC 3709, titled Internet X.509 Public Key Infrastructure: Logotypes in X.509 Certificates 🦋 It was written by S. Santesson (Microsoft), R. Housley (Vigil Security), and T. Freeman (Microsoft). It's a Standards Track doc, dated February 2004. The header doesn't list anything it obsoletes or updates, so there's no drama there 💅
Status of This Memo ✨
This document specifies an Internet standards track protocol for the Internet community, and asks for discussion and suggestions for improvements. For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 💖
Copyright Notice 🌈
Copyright (C) The Internet Society (2004). All Rights Reserved. 💜
Abstract 🌸
This doc spells out a certificate extension for putting logotypes into public key certificates and attribute certificates. It's giving branding in your certs 🍓
Table of Contents 📋
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Certificate-based Identification . . . . . . . . . . . . 3
1.2. Selection of Certificates. . . . . . . . . . . . . . . . 4
1.3. Combination of Verification Techniques . . . . . . . . . 5
1.4. Terminology. . . . . . . . . . . . . . . . . . . . . . . 6
2. Different types of logotypes in Certificates . . . . . . . . . 6
3. Logotype Data. . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Logotype Extension . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Extension Format . . . . . . . . . . . . . . . . . . . . 7
4.2. Other Logotypes. . . . . . . . . . . . . . . . . . . . . 11
5. Type of Certificates . . . . . . . . . . . . . . . . . . . . . 12
6. Use in Clients . . . . . . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations. . . . . . . . . . . . . . . . . . . . 13
8. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 15
9. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
10.1. Normative References . . . . . . . . . . . . . . . . . . 16
10.2. Informative References . . . . . . . . . . . . . . . . . 16
A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . . . . . . 17
B. Example Extension. . . . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 211. Introduction ✨
Okay so this spec adds onto RFC 3280 [PKIX-1], which sets the rules for X.509 [X.509] certificates and certificate revocation lists (CRLs) so they work on the Internet 🧚
The main job of a certificate is to link a public key to the identity of an entity (the subject). Technically you could do that by signing the subject's identity together with its public key, and that's it. But PKI has glowed up way past that to handle modern global networks and messy mixed IT setups 💅
Certificate users need to be able to figure out certificate policies, proper key usage, assurance level, and name form constraints. Before a relying party can make an informed call on whether a certificate is trustworthy and relevant for what they want to do, that certificate may need to be looked at from a bunch of different angles 👀
Systematic processing is needed to work out whether a certificate meets the predefined prerequisites for a given use. A lot of the info in certificates is great for machines, but it isn't really suited to the human trust and recognition process 🤖
Humans love structure and symbols. Most of us connect complicated stuff to logotypes and marks we can instantly recognize, and we tend to trust things we've seen before. Humans may also dig into details to double-check their first gut reaction. Honestly, very few people read all the terms and conditions they agree to when signing up for a service. They mostly go off trust built from past experience and recognition 🫶
Branding is a huge deal here. Service providers and product vendors spend a ton of money and effort tying good user experiences to trademarks, servicemarks, and logotypes that are easy to recognize 🔥
Branding is everywhere in identification instruments too, like ID cards, passports, driver's licenses, credit cards, gas cards, and loyalty cards. These instruments are meant to identify the holder as a specific person or as a member of a community. That community might be the subscribers of a service or any other group. In physical form, identification instruments use logotypes and symbols purely to boost human recognition and trust in the instrument itself. They may also include a registered trademark so there's legal recourse if someone copies it without permission 💅
Since certificates play that same role in electronic exchanges, we look at putting logotypes into certificates. We also cover certificate-based identification and certificate selection 🌈
1.1. Certificate-based Identification 🔍
Whether humans need to recognize a certificate depends on how it's used and whether people actually get to see it. If certificates are used in open environments, or in apps where the user is consciously interacting with the result of a certificate-based identification process, then human recognition is highly relevant and might be a necessity 💖
Examples of these apps include:
- Web server identification, where a user identifies the owner of the web site.
- Peer e-mail exchange in B2B, B2C, and private communications.
- Exchange of medical records, and system for medical prescriptions.
- Unstructured e-business applications (i.e., non-EDI applications).
- Wireless client authenticating to a service provider.
Most apps give the human user a chance to view the results of a successful certificate-based identification process. When the user actually takes those steps, they get shown a view of a certificate. This has two big problems 😭 First, the function to view a certificate is often really hard to find for a non-technical user. Second, the presentation of the certificate is way too technical and not user friendly. It has no graphic symbols or logotypes to help people recognize it 🙈
Lots of investigations have shown that users today don't bother to view certificates. That could be because of bad user interfaces. Plus, many apps are built to hide certificates from users altogether. The app designers just don't want to expose certificates to people at all 💀
1.2. Selection of Certificates 🎀
Software apps have to show certificates to humans when a user needs to pick a single certificate out of a portfolio of them. Sometimes the app can use info inside the certificates to filter the list for suitability, but if more than one certificate is suitable, the user has to be asked. The human picks one of them 🧚
This is kind of like pulling a plastic card out of your wallet. Card color, location, and branding do a lot of the heavy lifting there 💜
So to give certificate selection similar support, users need tools that let them easily recognize and tell certificates apart. Putting logotypes into certificates gives them the graphic they need ✨
1.3. Combination of Verification Techniques 🦋
Logotypes will, in many cases, affect whether a user decides to trust and use a certificate. That's why it's important to have a clear and distinct architectural and functional split between automated certificate verification and human recognition, in terms of their processes and goals 👑
Logotypes are only meant for human interpretation, and they contain data that doesn't fit computer-based verification schemes. So the logotype extension MUST NOT be an active component in automated certification path validation. 🚫
Automated certification path verification figures out whether the end-entity certificate can be verified against defined policy. The algorithm for that is specified in RFC 3280 [PKIX-1] 🤓
Automated processing gives assurance that the certificate is valid. It doesn't tell you whether the subject is allowed to access any particular information, or whether the subject should be trusted to perform a particular service. Those are access control decisions. Automatic processing will make some access control decisions, but others depend on the application context and involve the human user 🙌
Sometimes automated procedures fail to establish that a certificate is suitable for the task. In those cases, the human user is the final arbiter of the post-verification access control decisions. In the end, the human decides whether to accept an executable email attachment, release personal info, or follow instructions shown by a web browser. That choice is often based on recognition and past experience 🫣
The split between systematic processing and human processing is pretty straightforward, and the two can complement each other. Systematic processing focuses on certification path construction and verification, while the human acceptance process focuses on recognition and related past experience 💅
There are some situations where systematic processing and human processing get in each other's way. These issues are covered in the Security Considerations section ⚠️
1.4. Terminology 📖
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [STDWORDS] 🌸
2. Different Types of Logotypes in Certificates ✨
okay so this spec defines three standard logotype types you can put in a certificate 🎀
- Community logotype
- Issuer organization logotype
- Subject organization logotype
The community logotype is the general mark for a community 💜. It's basically the branding for a service concept used for entity identification and certificate issuance. Lots of issuers use one to co-brand with a global community so their local service gets worldwide recognition 🌍. This is SO common in the credit card business, where local independent card issuers show off a globally recognized brand (like VISA and MasterCard) 💳. Iconic co-branding behavior 😭.
The issuer organization logotype is a logotype representing the organization named as part of the issuer name in the certificate 🏢.
The subject organization logotype is a logotype representing the organization named in the subject name in the certificate 🫶.
Also, this spec lets you include other logotype types too, and each class of logotype gets its own object identifier. That OID can be locally defined, or it can be one defined in section 4.2 of this document 🧚.
3. Logotype Data
This spec defines two types of logotype data: image data and audio data 🖼️🔊. Implementations MUST support image data. Support for audio data is OPTIONAL 💅.
No need to bloat the cert with the actual image and audio bytes, lol. Instead, the certificate includes a URI pointing to where the logotype data lives, plus a one-way hash of the referenced data 🦋.
Several image files, representing the same image in different formats, sizes, and colour palates, may represent each logotype image 🌈. At least one of those image files SHOULD contain an image within the size range of 60 pixels wide by 45 pixels high, and 200 pixels wide by 150 pixels high ✨.
Several audio files may further represent the same audio sequence in different formats and resolutions 🎧. At least one of the audio files representing a logotype SHOULD have a play time between 1 and 30 seconds 🙈.
If a logotype of a certain type (as defined in section 2) is represented by more than one image file, then the image files MUST contain variants of roughly the same image 🎀. Likewise, if a logotype of a certain type is represented by more than one audio file, the audio files MUST contain variants of the same audio information. A spoken message in different languages counts as a variation of the same audio info 🌸. Compliant applications MUST NOT display more than one of the images and MUST NOT play more than one of the audio sequences for any logotype type at the same time 🚫.
A client MAY simultaneously display multiple logotypes of different logotype types. For example, it may display one subject organization logotype while also displaying a community logotype, but it MUST NOT display multiple image variants of the same community logotype 👑.
Each logotype present in a certificate MUST be represented by at least one image data file 📸.
Applications SHOULD enhance processing and off-line functionality by caching logotype data 💾.
4. Logotype Extension ✨
This section is where the logotype extension gets its syntax and semantics spelled out 📜.
4.1. Extension Format
The logotype extension MAY be included in public key certificates [PKIX-1] or attribute certificates [PKIX-AC] 🎀. The logotype extension MUST be identified by the following object identifier:
id-pe-logotype OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-pe(1) 12 }This extension MUST NOT be marked critical 🙅♀️.
Logotype data may be referenced through either direct or indirect addressing. Clients MUST support both direct and indirect addressing. Certificate issuing applications MUST support direct addressing, and certificate issuing applications SHOULD support indirect addressing 🧩.
Direct addressing includes information about each logotype in the certificate, and URIs point to the image and audio data files. It's the move when only one or a few alternative images and audio files are referenced 💖.
Indirect addressing includes one reference to an external hashed data structure that holds the type, content, and location of each image and audio file. It's for cases where each logotype is represented by many alternative audio or image files 📚.
Both direct and indirect addressing can accommodate alternative URIs to obtain exactly the same item. This replication is meant to improve availability, so if a client can't fetch the item from one URI, the client SHOULD try another URI in the sequence 🔁. All URIs MUST use either the HTTP scheme (http://...) or the FTP scheme (ftp://...) [URI]. At least one URI in each sequence MUST use the HTTP scheme. Clients MUST support retrieval of referenced LogoTypeData with HTTP/1.1 [HTTP/1.1]. Clients MAY support retrieval using FTP [FTP] 🌐.
The logotype extension MUST have the following syntax:
LogotypeExtn ::= SEQUENCE {
communityLogos [0] EXPLICIT SEQUENCE OF LogotypeInfo OPTIONAL,
issuerLogo [1] EXPLICIT LogotypeInfo OPTIONAL,
subjectLogo [2] EXPLICIT LogotypeInfo OPTIONAL,
otherLogos [3] EXPLICIT SEQUENCE OF OtherLogotypeInfo OPTIONAL }
LogotypeInfo ::= CHOICE {
direct [0] LogotypeData,
indirect [1] LogotypeReference }
LogotypeData ::= SEQUENCE {
image SEQUENCE OF LogotypeImage OPTIONAL,
audio [1] SEQUENCE OF LogotypeAudio OPTIONAL }
LogotypeImage ::= SEQUENCE {
imageDetails LogotypeDetails,
imageInfo LogotypeImageInfo OPTIONAL }
LogotypeAudio ::= SEQUENCE {
audioDetails LogotypeDetails,
audioInfo LogotypeAudioInfo OPTIONAL }
LogotypeDetails ::= SEQUENCE {
mediaType IA5String, -- MIME media type name and optional
-- parameters
logotypeHash SEQUENCE SIZE (1..MAX) OF HashAlgAndValue,
logotypeURI SEQUENCE SIZE (1..MAX) OF IA5String }
LogotypeImageInfo ::= SEQUENCE {
type [0] LogotypeImageType DEFAULT color,
fileSize INTEGER, -- In octets
xSize INTEGER, -- Horizontal size in pixels
ySize INTEGER, -- Vertical size in pixels
resolution LogotypeImageResolution OPTIONAL,
language [4] IA5String OPTIONAL } -- RFC 3066 Language Tag
LogotypeImageType ::= INTEGER { grayScale(0), color(1) }
LogotypeImageResolution ::= CHOICE {
numBits [1] INTEGER, -- Resolution in bits
tableSize [2] INTEGER } -- Number of colors or grey tones
LogotypeAudioInfo ::= SEQUENCE {
fileSize INTEGER, -- In octets
playTime INTEGER, -- In milliseconds
channels INTEGER, -- 1=mono, 2=stereo, 4=quad
sampleRate [3] INTEGER OPTIONAL, -- Samples per second
language [4] IA5String OPTIONAL } -- RFC 3066 Language Tag
OtherLogotypeInfo ::= SEQUENCE {
logotypeType OBJECT IDENTIFIER,
info LogotypeInfo }
LogotypeReference ::= SEQUENCE {
refStructHash SEQUENCE SIZE (1..MAX) OF HashAlgAndValue,
refStructURI SEQUENCE SIZE (1..MAX) OF IA5String }
-- Places to get the same "LTD" file
HashAlgAndValue ::= SEQUENCE {
hashAlg AlgorithmIdentifier,
hashValue OCTET STRING }When using indirect addressing, the URI (refStructURI) pointing to the external data structure MUST point to a binary file containing the DER encoded data with the syntax LogotypeData. The referenced file name SHOULD include a file extension of "LTD" 📁.
At least one of the optional elements in the LogotypeExtn structure MUST be present. Avoid the use of otherLogos whenever possible 🙃.
The LogotypeReference and LogotypeDetails structures explicitly identify one or more one-way hash functions used to authenticate referenced data files 🔐. Clients MUST support the SHA-1 [SHS] one-way hash function, and clients MAY support other one-way hash functions. CAs MUST include a SHA-1 hash value for each referenced file, calculated on the whole file, and CAs MAY include other one-way hash values. Clients MUST compute a one-way hash value using one of the identified functions, and clients MUST discard the logotype data if the computed one-way hash function value does not match the one-way hash function value in the certificate extension 🗑️.
A MIME type is used to specify the format of the file containing the logotype data 🎨. Implementations MUST support both the JPEG and GIF image formats (with MIME types of "image/jpeg" and "image/gif" [MEDIA], respectively). Animated images SHOULD NOT be used. Implementations that support audio MUST support the MP3 audio format (with a MIME type of "audio/mpeg" [AUDIO/MPEG]). MIME types MAY include parameters 🎵.
When language is specified, the language tag MUST use the RFC 3066 [LANGCODES] syntax 🌏.
The logotype types defined in this specification are:
Community Logotype: If communityLogos is present, the logotypes MUST represent one or more communities with which the certificate issuer is affiliated. The communityLogos MAY be present in an end entity certificate, a CA certificate, or an attribute certificate. The communityLogos contains a sequence of Community Logotypes, each representing a different community. If more than one Community logotype is present, they MUST be placed in order of preferred appearance. Some clients MAY choose to display a subset of the present community logos, so the placement within the sequence helps the client select. The most preferred logotype MUST be first in the sequence, and the least preferred logotype MUST be last in the sequence 👑.
Issuer Organization Logotype: If issuerLogo is present, the logotype MUST represent the issuer's organization. The logotype MUST be consistent with, and require the presence of, an organization name stored in the organization attribute in the issuer field (for either a public key certificate or attribute certificate). The issuerLogo MAY be present in an end entity certificate, a CA certificate, or an attribute certificate 🏢.
Subject Organization Logotype: If subjectLogo is present, the logotype MUST represent the subject's organization. The logotype MUST be consistent with, and require the presence of, an organization name stored in the organization attribute in the subject field (for either a public key certificate or attribute certificate). The subjectLogo MAY be present in an end entity certificate, a CA certificate, or an attribute certificate 🫶.
The relationship between the subject organization and the subject organization logotype, and the relationship between the issuer and either the issuer organization logotype or the community logotype, are relationships asserted by the issuer. The policies and practices the issuer uses to check subject organization logotypes or claims about its issuer and community logotypes are outside the scope of this document 🧐.
4.2. Other Logotypes 🌈
okay so, logotypes identified by otherLogos (from 4.1) can be used to make logotypes and marks look extra 💅. They can represent partners, products, services, or literally anything else tied to the certificate or where it's being used, for when the standard logotype types just aren't cutting it 🫶
The conditions and contexts for using these logotypes are up to the local client application, so it gets to decide 💖
There are two other logotype types defined in this document:
- Loyalty logotype
- Certificate Background logotype
OID definitions (these are the IDs that tag each one 🔖):
id-logo OBJECT IDENTIFIER ::= { id-pkix 20 }
id-logo-loyalty OBJECT IDENTIFIER ::= { id-logo 1 }
id-logo-background OBJECT IDENTIFIER ::= { id-logo 2 }A loyalty logotype, if it's there, MUST contain a logotype tied to a loyalty program connected to the certificate or how it's used 🎀 How the certificate and that loyalty program are related is out of scope for this document, so we're not touching that one 🙈 The logotype extension MAY contain more than one Loyalty logotype, so go wild ✨
The certificate background logotype, if it's there, MUST contain a graphic meant to be a background image for the certificate, and/or a general audio sequence for the certificate. The background image MUST let black text be clearly read when it's placed on top of it 🖤 And the logotype extension MUST NOT contain more than one certificate background logotype. one background only, bestie 🦋
5. Type of Certificates ✨
Logotypes MAY be included in public key certificates and attribute certificates, but that's totally up to the certificate issuer 💅 However, logotypes MUST NOT be part of certification path validation or any type of automated processing 🙅♀️ The whole point of logotypes is to make a particular certificate look good when it's displayed, no matter where it sits in a certification path 🧚
6. Use in Clients 💖
Okay this section is a lot, but it's important bestie 🫶 All PKI implementations need relying party software to have some way to figure out whether a trusted CA issued a particular certificate. This is a problem for certification path validation, including consistent policy and name checking 🔍
After a certification path is successfully validated, the replying party trusts whatever info the CA puts in the certificate, including any certificate extensions 🌸 The client software can choose to use that info, or it can ignore it totally, no judgment 💅 If the client can't support a provided logotype, the client MUST NOT report an error. Instead, the client MUST behave as though there was no logotype extension in the certificate at all 🙈 Current standards don't give any mechanism for cross-certifying CAs to stop subordinate CAs from including private extensions (see the security considerations section). so that's a whole vibe 😭
So, if relying party software accepts a CA, it should be prepared to (unquestioningly) display the associated logotypes to its human user, as long as it's set up to do that ✨ The info about the logotypes is there so the replying party software can pick the one that best meets the human user's needs 🎯 That choice depends on the human user's abilities and on what the platform the replaying party software is running on can actually do 🖥️ If none of the provided logotypes meets the user's needs or matches the platform's capabilities, the logotypes can just be ignored 🫠
A client MAY, subject to local policy, choose to display none, one, or any number of the logotypes in the logotype extension 🌈
Real talk, a client is often used somewhere with a great network connection and also somewhere with little or no connectivity 💻 Like, a laptop can be docked to a high-speed LAN, or it can be totally offline 🔌 Because of that, the client MUST include the ability to disable fetching logotypes 🛑 Even so, locally cached logotypes can still be displayed when the user turns off fetching of additional logotypes 💾
A client MAY, subject to local policy, choose any combo of audio and image presentation for each logotype 🎶 That means the client MAY display an image with or without playing a sound, and it MAY play a sound with or without displaying an image 🖼️🔊 A client MUST NOT play more than one logotype audio sequence at the same time. no overlapping sounds, bestie 🙅♀️
The logotype is meant to be shown alongside the other identity info in the certificate. It is not a replacement for that identity info 🪪
Care is needed when designing replying party software so an appropriate context of logotype info is provided ⚠️ This is especially tricky with audio logotypes 😩 It's important that the human user can recognize the context of the logotype, even when other audio streams are playing 🎧
If the relying party software can't successfully validate a particular certificate, then it MUST NOT display any logotype data associated with that certificate. no validation, no logo, periodt 🚫💅
7. Security Considerations 🔐
Implementations that show multiple logotype types at once (subject organization, issuer, community or other) MUST make sure there's no ambiguity about the binding between the image and the type of logotype it represents 🧐 "Logotype type" is defined in section 2, and it refers to the type of entity or affiliation the logotype represents, not the type of binary format 🧠
Logotypes are super hard to define securely and accurately 😭 Names are also difficult in this regard, but logotypes are even worse. It's really hard to specify what is and isn't a legitimate logotype of an organization. There's a whole legal structure around this issue, and it won't be repeated here 📜 Still, issuers should be aware of the implications of including images tied to a trademark or servicemark before they do it ⚠️
Since logotypes can be difficult (and sometimes expensive) to verify, the chance of errors, like assigning the wrong logotype to an organization, goes up 📉
This isn't a new issue for electronic identification instruments. It's already handled in a bunch of similar situations in the physical world, including physical employee ID cards 🪪 Also, there are situations where identifying logotypes is pretty simple and straightforward, like logotypes for well-known industries and institutes 🏛️ These issues shouldn't stop service providers who want to issue logotypes from doing so, where it's relevant 💖
It's impossible to prevent fraudulent creation of certificates by dishonest or badly performing issuers, which contain names and logotypes the issuer has no claim to or hasn't checked correctly 🕵️ Those certificates could be made to socially engineer a user into accepting them 😬 So the premise behind the logotype work is that logotype graphics in a certificate are trusted only if the certificate is successfully validated within a valid path ✅ It's absolutely imperative that the representation of any certificate that fails to validate is not enhanced in any way by using the logotype graphic 🚨
Logotype data is fetched from a server when it's needed. By watching network activity, an observer can figure out which clients are using certificates that contain particular logotype data 👀 That can potentially cause privacy issues 🫣 Since clients are expected to cache logotype data locally, network traffic to the server with the logotype data won't be generated every time the certificate is used 💾 If logotype data isn't cashed, monitoring would reveal usage frequency. If logotype data is cached, monitoring would reveal when a certain logotype image or audio sequence is used for the first time 🕰️
Certification paths may also impose name constraints that are systematically checked during certification path processing, which, in theory, might be circumvented by logotypes 🌀
Certificate path processing as defined in RFC 3280 [PKIX-1] does not constrain the inclusion of logotype data in certificates 🙃 A parent CA can constrain certification path validation so that subordinate CAs can't issue valid certificates to end-entities outside a limited name space or outside specific certificate polices 🚧 A malicious CA can follow those name and policy requirements and still include inappropriate logotypes in the certificates it issues 😈 These certificates will pass the certification path validation algorithm, which means the client will trust the logotypes in them 😱 Since there's no technical mechanism to stop or control subordinate CAs from including the logotype extension or its contents, where appropriate, a parent CA could use a legal agreement to put a suitable restriction on the subordinate CA 📝 This situation isn't unique to the logotype extension, btw 🤷♀️
The controls a parent CA has to protect itself from rogue subordinate CAs are non-technical. They include:
- Contractual agreements of suitable behavior, including terms of liability in case of material breach.
- Control mechanisms and procedures to monitor and follow up on the behavior of subordinate CAs.
- Use of certificate policies to declare an assurance level of logotype data, as well as to guide applications on how to treat and display logotypes.
- Use of revocation functions to revoke any misbehaving CA.
There is not a simple, straightforward, and absolute technical solution. Involved parties have to settle some aspects of PKI outside the scope of technical controls. So issuers need to clearly identify and communicate the associated risks 🚨💅
8. IANA Considerations 🏷️
Certificate extensions and attribute certificate extensions are identified by object identifiers (OIDs). The OID for the extension defined in this document was assigned from an arc delegated by the IANA to the PKIX Working Group. No further action by the IANA is necessary for this document or any anticipated updates 🙌
9. Acknowledgments 🫶
This document is the result of contributions from many professionals 🌟 The authors appreciate contributions from all members of the IETF PKIX Working Group. We extend a special thanks to Al Arsenault, David Cross, Tim Polk, Russel Weiser, Terry Hayes, Alex Deacon, Andrew Hoag, Randy Sabett, Denis Pinkas, Magnus Nystrom, Ryan Hurst, and Phil Griffin for their efforts and support 👑
Russ Housley thanks the management at RSA Laboratories, especially Burt Kaliski, who supported the development of this specification. The vast majority of the work on this specification was done while Russ was employed at RSA Laboratories 💜
10. References 📚
10.1. Normative References ✨
- [LANGCODES] Alvestrand, H., "Tags for Identification of Languages", BCP 47, RFC 3066, January 2001. 🌸
- [PKIX-1] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet X.509 Public Key Infrastructure: Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002. 💅
- [PKIX-AC] Farrell, S. and R. Housley, "An Internet Attribute Certificate Profile for Authorization", RFC 3281, April 2002. 🦋
- [SHS] Federal Information Processing Standards Publication (FIPS PUB) 180-1, Secure Hash Standard, 17 April 1995. [Supersedes FIPS PUB 180 dated 11 May 1993.] 🔥
- [STDWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 👑
- [HTTP/1.1] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 🌈
- [FTP] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, October 1985. ⭐
- [URI] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. 🧚
- [MEDIA] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996. 💜
- [AUDIO/MPEG] Nilsson, M., "The audio/mpeg Media Type", RFC 3003, November 2000. 🎀
10.2. Informative References
- [X.509] ITU-T Recommendation X.509 (2000) | ISO/IEC 9594-8:2001, Information technology - Open Systems Interconnection - The Directory: Public-key and attribute certificate frameworks. 🫶
Appendix A. ASN.1 Module 💜
Okay, this is the whole ASN.1 module, and it's giving precision. The LogotypeCertExtn module defines the logotype extension OID, the extension syntax, the logotype types, and the other logotype type OIDs. Here it is, verbatim, because every single character matters 🙈
LogotypeCertExtn
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-logotype(22) }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
IMPORTS
AlgorithmIdentifier FROM PKIX1Explicit88 -- RFC 3280
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-explicit(18) };
-- Logotype Extension OID
id-pe-logotype OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-pe(1) 12 }
-- Logotype Extension Syntax
LogotypeExtn ::= SEQUENCE {
communityLogos [0] EXPLICIT SEQUENCE OF LogotypeInfo OPTIONAL,
issuerLogo [1] EXPLICIT LogotypeInfo OPTIONAL,
subjectLogo [2] EXPLICIT LogotypeInfo OPTIONAL,
otherLogos [3] EXPLICIT SEQUENCE OF OtherLogotypeInfo OPTIONAL }
LogotypeInfo ::= CHOICE {
direct [0] LogotypeData,
indirect [1] LogotypeReference }
LogotypeData ::= SEQUENCE {
image SEQUENCE OF LogotypeImage OPTIONAL,
audio [1] SEQUENCE OF LogotypeAudio OPTIONAL }
LogotypeImage ::= SEQUENCE {
imageDetails LogotypeDetails,
imageInfo LogotypeImageInfo OPTIONAL }
LogotypeAudio ::= SEQUENCE {
audioDetails LogotypeDetails,
audioInfo LogotypeAudioInfo OPTIONAL }
LogotypeDetails ::= SEQUENCE {
mediaType IA5String, -- MIME media type name and optional
-- parameters
logotypeHash SEQUENCE SIZE (1..MAX) OF HashAlgAndValue,
logotypeURI SEQUENCE SIZE (1..MAX) OF IA5String }
LogotypeImageInfo ::= SEQUENCE {
type [0] LogotypeImageType DEFAULT color,
fileSize INTEGER, -- In octets
xSize INTEGER, -- Horizontal size in pixels
ySize INTEGER, -- Vertical size in pixels
resolution LogotypeImageResolution OPTIONAL,
language [4] IA5String OPTIONAL } -- RFC 3066 Language Tag
LogotypeImageType ::= INTEGER { grayScale(0), color(1) }
LogotypeImageResolution ::= CHOICE {
numBits [1] INTEGER, -- Resolution in bits
tableSize [2] INTEGER } -- Number of colors or grey tones
LogotypeAudioInfo ::= SEQUENCE {
fileSize INTEGER, -- In octets
playTime INTEGER, -- In milliseconds
channels INTEGER, -- 1=mono, 2=stereo, 4=quad
sampleRate [3] INTEGER OPTIONAL, -- Samples per second
language [4] IA5String OPTIONAL } -- RFC 3066 Language Tag
OtherLogotypeInfo ::= SEQUENCE {
logotypeType OBJECT IDENTIFIER,
info LogotypeInfo }
LogotypeReference ::= SEQUENCE {
refStructHash SEQUENCE SIZE (1..MAX) OF HashAlgAndValue,
refStructURI SEQUENCE SIZE (1..MAX) OF IA5String }
-- Places to get the same "LTD" file
-- Note: The content of referenced "LTD" files is defined by the
-- LogotypeData type
HashAlgAndValue ::= SEQUENCE {
hashAlg AlgorithmIdentifier,
hashValue OCTET STRING }
-- Other logotype type OIDs
id-logo OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) 20 }
id-logo-loyalty OBJECT IDENTIFIER ::= { id-logo 1 }
id-logo-background OBJECT IDENTIFIER ::= { id-logo 2 }
ENDAppendix B. Example Extension 🎀
Here's a cute worked example 🧁 It's a logotype extension with one Issuer logotype using direct addressing. The image is image/gif, the file is referenced through 1 URI, and the image is hashed with one sha1 hash value.
The numbers on the left are the ASN.1 tag and length, written in hexadecimal. So you can literally follow the bytes like a treasure map 🗺️
30 106: SEQUENCE {
06 8: OBJECT IDENTIFIER '1 3 6 1 5 5 7 1 12'
04 94: OCTET STRING, encapsulates {
30 92: SEQUENCE {
A1 90: [1] {
A0 88: [0] {
30 86: SEQUENCE {
30 84: SEQUENCE {
30 82: SEQUENCE {
16 9: IA5String 'image/gif'
30 33: SEQUENCE {
30 31: SEQUENCE {
30 7: SEQUENCE {
06 5: OBJECT IDENTIFIER sha1 (1 3 14 3 2 26)
: }
04 20: OCTET STRING
: 8F E5 D3 1A 86 AC 8D 8E 6B C3 CF 80 6A D4 48 18
: 2C 7B 19 2E
: }
: }
30 34: SEQUENCE {
16 32: IA5String 'http://logo.example.com/logo.gif'
: }
: }
: }
: }
: }
: }
: }
: }
: }
Authors' Addresses 🖋️
The people behind this one, with their addresses:
Stefan Santesson
Microsoft Denmark
Tuborg Boulevard 12
DK-2900 Hellerup
Denmark
EMail: stefans@microsoft.com
Russell Housley
Vigil Security, LLC
918 Spring Knoll Drive
Herndon, VA 20170
USA
EMail: housley@vigilsec.com
Trevor Freeman
Microsoft Corporation
One Microsoft Way
Redmond WA 98052
USA
EMail: trevorf@microsoft.comFull Copyright Statement ⭐
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78 and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property 🔥
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
Acknowledgement 🫶
Funding for the RFC Editor function is currently provided by the Internet Society. 🌈
📦 where this page comes from
- ietf: rfc3709 2004-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms