PKIX Working Group S. Santesson (AddTrust)
INTERNET-DRAFT
Expires January, 2002
Internet X.509 Public Key Infrastructure
Logotypes in X.509 certificates
<draft-ietf-pkix-logotypes-00.txt>
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.