PKIX Working Group S. Santesson (AddTrust) INTERNET-DRAFT Expires January, 2002 Internet X.509 Public Key Infrastructure Logotypes in X.509 certificates Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract This document contains an initial outline of a standard for inclusion of logotypes in certificates. The draft includes background discussions around different aspects of problems and solutions, forming a starting point for the creation of a complete standard. 1 Rationale The basic function of a certificate is to bind a public key to an entity (subject). From a strict technical viewpoint that would be satisfied by just signing the identity of the subject together with its public key. The art of PKI have however developed certificates far beyond this functionality in order to meet the needs from modern global networks and heterogeneous IT structures. A primary driver of the evolution from simple certificate formats to more complex structures is the need to distinguish between different certificate concepts, defining everything from assurance level, policies and procedures, fields of usage to name forms and semantics. Before a relying party can make an informed decision whether a particular certificate is trustworthy and relevant for its intended usage, a large number of aspects of the certificate may have to be processed. All of these aspects of certificates do mainly concern systematic processing in order to deliver a distinct Yes or No answer to the question whether the certificate match predefined prerequisites and thereby is regarded as appropriate for its intended usage. Even though these information objects in certificates are appropriate and effective for machine processing, they are poor instruments for a corresponding human trust and recognition process. The human mind prefer to structure information into categories and symbols. Complex structures of reality are encapsulated in easy recognizable logotypes and marks. The human trust process is to a smaller extent based on information and to a greater extent based on recognition and experience. Very few consumers actually read all terms and conditions they accept when accepting a service, instead they most commonly act in trust based on experience and recognition. A big part of this process is branding, where service providers invest a lot of money and resources into creating a strong relation between positive user experiences and easily recognizable trademarks and logotypes. This reality also extends to the realm of concepts, services and instruments for identification, ranging from ID-cards, passports and driver's licenses to credit cards, gasoline cards and loyalty cards etc, whose function is to identify an entity either as a person or as member of community, subscriber of a service, etc. These concepts and instruments of identification in physical form have in common the use logotypes and symbols, solely aimed to enhance human recognition and trust in the underlying concept. As certificates play an equivalent role in electronic exchange, to the use of physical ID's in physical exchange, some important questions deserves closer attention in the investigation whether the use of logotypes in certificates are relevant or not. 1.1 Are human recognition concepts relevant in electronic forms of identification? The answer depends on the answer to the fundamental underlying question whether certificates should be visible or invisible to human users and if certificates will be used in open environments. If certificates are to be used in open environments and in applications that brings the user in conscious contact with the result of a certificate based identification process, then human recognition of concept is highly relevant, and may even be a necessity. Examples of applications of these types are: - Web server identification where a user identifies the owner of the web site. - Peer entity e-mail exchange (in B2B, B2C and private communication exchange). - Other profession information processing and message exchange systems (such as medical records handling, and system for medical prescriptions) - Unstructured e-business applications (i.e. non EDI applications) Most applications that offer the user to view the result of a certificate based identification process do this by allowing the user to view the certificate of the identified entity. This solution has however two major problems. 1) The function to view a certificate is often rather hard to find for a non-technical user. 2) The presentation of the certificate is rather technical and not user friendly. Further it contains no graphic symbols and logotypes to enhance human recognition. Many investigations have shown that users in current applications don't "click" to view certificates. There is however a distinct possibility that this fact is due to how applications are structured and due to very poor user interfaces, much more than a proof that certificates should not be exposed to users at all. 1.2 Can the concepts of systematic verification processing and human recognition be combined in any sensible manner? Systematic verification of a certificate (including systematic verification of all certificates in the path built up to a trusted root) will at most give a user/system either the result "Verified according to defined policy" or "Failed verification according to defined policy". The systematic processing has in this case provided the user/system with assurance that the certificate is a valid document, but not who the subject of the certificate in fact is or what that entity is entitled/trusted to do. The latter is the task of an access control function, which may again be a systematic process or in fact a human recognition process, all dependent on application context. So in some situations a human person will be the sole handler of the post verification process of identification and authorization. It may in the end be a human decision to accept, act on or release information based on who and/or what the opponent is and whom he/she represents. The conclusion is that the distinction between systematic processing and human processing is rather straightforward and clear and has the character of being complementary rather than interfering. While the systematic process is focused on path processing and verification, the human acceptance process is focused on identification, recognition and authorization. Some interference issues do however exist as handled under security considerations section. 2. Different types of logotypes in certificates This report recommends standardized supported usage of 3 types of logotypes in certificates. 1) Concept logotype 2) Issuer organization logotype 3) Subject organization logotype The concept logotype - is the general mark for a service concept for entity identification and certificate issuance. Many issuers may use the concept logotypes to co-brand with a global concept in order to gain global recognition of its local service provision. This type of concept branding is very common in credit card business where local independent card issuers issue cards within a globally branded concept (such as VISA and. MasterCard etc.). Issuer organization logotype - is a logotype representing the organization identified as part of the issuer name in the certificate. Subject organization logotype - is a logotype representing the organization identified in the subject name in the certificate. 3. Technical solutions 3.1 General A general conclusion is that there is no need to include any logotype image data in a certificate. The same function may be achieved by including a hash of the logotype image in the certificate together with a URI/ URL identifying the location of the logotype image data. Applications may enhance processing and off-line functionality by cashing logotype data. Other minor aspects are: - that the URL also defines the file format for the image data. - that the solution includes algorithm information about the employed hash algorithm. The initially proposed general structure for logotype data is: LogotypeData ::= SEQUENCE { typeOfLogotype TypeOflogotype, hashAlgorithm AlgorithmIdentifier, logotypeDataHash OCTET STRING, sourceDataUri IA5String OPTIONAL } TypeOflogotype ::= CHOICE { predefinedLogotypeType PredefinedLogotypeType, LogotypeTypeID OBJECT IDENTIFIER } PredefinedLogotypeType ::= INTEGER { subject-organization-logotype(0), issuer-organization-logotype(1) concept-logotype(2)} (subject-organization-logotype| issuer-organization-logotype| concept-logotype,...) The predefined logotype types are subject-organization-logotype, if used, SHALL be used to include a logotype of the subject organization. The logotype SHALL be consistent with, and require the presence of, an organization name stored in the organization attribute in the subject field. issuer-organization-logotype, if used, SHALL be used to include a logotype of the issuer organization. The logotype SHALL be consistent with, and require the presence of, an organization name stored in the organization attribute in the issuer field. Concept-logotype, if used, SHALL be used to include a logotype representing the concept under which the issuer claims to issue this certificate. A concept may be shared within a network of CA services, provided by one or several independent CA organizations. 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 concept logotype, are relationships claimed by the issuer. The policy under which the issuer checks these logotypes is outside the scope of this standard. Any URI pointing to a file containing the logotype data SHALL include a file extension defining the file format (i.e. .GIF, .TIF, .JPG etc.) 3.2 Type of certificates Logotypes according to the present model may be used in 3 types of certificates: - Selfsigned CA certificates (root certificates) - Intermediate CA certificates - End entity certificates A reason to constrain inclusion of logotypes to end entity certificates would be to exclude the aspect of logotypes from path processing issues, where a path validating service would want to check consistency of logotypes in a chain. However, as discussed in the rationale, logotypes are not aimed to be part of path validation or any type of systematic processing since its sole purpose is to enhance display of a single particular certificate to a user regardless of its position or function in a path construct. The conclusions are: - Logotypes should not be an active component in path processing. - Logotypes should be allowed in all types of certificates, by the choice of the CA. 3.2 Place of inclusion So far there has been 3 solutions discussed regarding where to store logotype data in certificates. - Inclusion in a policy qualifier - Inclusion in Issuer and Subject Alternative names extensions - Inclusion in a separate private extension 3.2.1 Qualifier This solution would include logotype data as a newly defined policy qualifier. Pros: - This solution provides a mechanism to directly control the use and display of logotypes under a particular policy Cons: - Current practice and standards (RFC 2459) recommends against use of qualifiers - This is generally considered to be a major hack and stretch of semantics, since this type of data doesn't qualify a policy in any way. 3.2.2 Issuer and Subject Alt Names This solution would use the other name form to include; - issuer and concept logotypes in the issuer alt name extension; and - subject organization logo in the subject alt name extension. Pros: - This mechanism could possibly enable cross certifying CAs to deny any subordinate CA the right to include logotypes in descending end entity certificates by listing the logotypes name form in excludedSubtrees. Cons: - Logotypes are not a name form and can't be treated as a displayable name. - It is generally understood that it should be possible to apply general name constraint mechanisms (as described in RFC 2459 as well as son of RFC 2459) to names in the subject and issuer alt name ext. This is however not possible to do with logotypes due to it's non-name form. - This split storage of logotype data into 2 different locations, which may make life worse for applications with no interest in logotypes. - It is generally agreed that inclusion of logotype data by no means should be regarded as critical data. This may interfere with the criticality policy of the alt name extensions, especially if the certificate has no attributes in the subject field, forcing the subject alt name to be set to critical. - This usage would possibly interfere with the resolution between IETF and ITU-T regarding use of permitted subtrees. - Since this solution may break current implementations it would possibly block adoption of logotypes. 3.2.3 New extension This solution would create a new private (non critical) extension. logotypeInfo EXTENSION ::= { SYNTAX LogotypeSyntax IDENTIFIED BY id-pe-logotypeInfo } id-pe-logotypeInfo OBJECT IDENTIFIER ::= {id-pe XX} LogotypeSyntax ::= SEQUENCE OF LogotypeData Pros: - This is the cleanest solution. - Do not impact on legacy implementations. Cons: - This solution activates the issue whether this extension may be abused by a CA who include logotypes (in EE certificates) that violates the intention of a name constraints set by a chaining CA. This issue is addressed in the security consideration section below. 3.2.4 Conclusion The criteria for selecting a solution must be that it doesn't destroy current structures and doesn't create problems and confusion. Only the private extension solution meets this criterion and should therefore be selected. 4. Use in Clients All PKI implementations require that relying party software have some mechanism to determine whether a trusted CA issues a particular certificate. This is an issue for path validation of the certificate chain from a trusted root, including consistent policy and name checking. After passing this process, the general assumption must be that the CA is trusted to certify the information carried in any certificate extensions, given that the client decides to use that information. The assumption is regarded as general due to the fact that current standards do not provide any mechanism for cross-certifying CAs to constrain subordinate CAs from including private extensions (see security considerations). Consequently, if relying party software accepts a CA, then it should be prepared to (unquestioningly) display the associated logos to its human user, given that it is configured to do so. 5. Security considerations Logotypes are even worse than names regarding the possibility to securely and accurately define what is, and what is not, a legitimate logotype of an organization. There is a whole legal structure around this issue that doesn't need repetition in this document. As logotypes are hard (and sometimes expensive) to verify, this increases the possibility of errors related to falsely assigning wrong logotypes to organizations. This is however not a new issue for electronic identification instruments, but rather a well known problem that is already dealt with in numerous of similar situations in the physical world, including physical employment ID cards. Secondly there are situations where identification of logotypes is rather simple and straight forward, such as logotypes for well-known industries and institutes. These issues should not be stopping those service providers wanting to go into the issue of logotypes from doing so, where this is relevant. The new problem related to electronic identification instruments in the form of certificates are however that certificate chains may impose constraints that are systematically checked in path processing algorithms, which in theory may be violated by logotypes. Path processing algorithms does not, should not, and will never be able to control if any logotype included in any certificate violates any such constraints. I.e. a chaining CA may constraint subordinate CAs to only issue certificates to end entities within a limited name space. A potentially bad CA may comply with this constraint in included names but may still include a subject organization logotype that gives a relying party the impression that the subject is part of another organization or being part of a group of companies, which exceeds the freedom in the name constraint. The problem here is that the chaining CA has no means of preventing this since there is no mechanism to prevent subordinate CAs from including new extensions. This is however nothing unique with a logotype extension, but a general problem with X.509. The fact is that a chaining CA has no absolute technical control over subordinate CAs behaviour with respect to inclusion of new private extensions that may violate any policy or constraint set in a chaining certificate. The controls available to a chaining CA to protect itself against bad CAs are mainly: - Contractual agreements of suitable behaviour, including terms of liability and severance pay in case of material breach. - Control mechanisms and procedures to monitor and follow-up behaviour of subordinate CAs - Use of certificate policies to declare 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. This may not be an issue that can be given an easy and absolute technical solution. Maybe the correct response is to surrender to the fact that involved parties must settle some aspects of PKI outside the scope of technical controls, and to clearly identify and communicate the associated risks with that.