Subject: Re: I-D ACTION:draft-ietf-pkix-new-part1-07.txt

From: "Tom Gindin" <[email-masked]>
Date: Mon, 2 Jul 2001 20:28:55 -0400

Your first case is indeed certainly a security concern, but I'm not
sure the second one is easily distinguishable from an LDAP problem - what
attacker is suppressing the extra CRL's?  I am skeptical, as you may have
seen from my discussion with Santosh, that X.509 does NOT rely on the
security of the repositories or of their administrators.  This statement is
true only insofar as the RP is expected to verify the signature of CRL's or
certificates retrieved from the repositories so that data which was never
valid cannot be imposed on the RP.  It does not really apply to the
suppression of unscheduled CRL's (including most deltas, I think) - since
an RP will not know that the unscheduled CRL is missing and will wrongly
assume that the base CRL (or the earlier CRL if deltas are not used) is the
current intended set of revocation information.
     To rephrase my earlier statement to Santosh, while the primary
reliance in a distributed PKI is on the key, I do not believe that this
reliance should be exclusive.  This statement is not purely philosophical,
as it can have direct impact on the set of inputs needed to represent a
trust anchor, for example.

          Tom Gindin

Denis Pinkas <[email-masked]> on 07/02/2001 05:07:18 AM

To:   Tom Gindin/Watson/IBM@IBMUS
cc:   "Housley, Russ" <[email-masked]>, [email-masked], Tim
      Polk <[email-masked]>
Subject:  Re: I-D ACTION:draft-ietf-pkix-new-part1-07.txt

Tom,

(snip)

> I have some problems with this text, first with "most current" and then
> with the two last MUST. I propose the following fix:

>  An application that supports delta CRLs MAY be able to construct a
>  complete CRL for a reference time T prior to the current time by
combining
>  a complete CRL issued no later than T and a delta CRL valid as of T.
>  A delta CRL is considered to be valid at a given time T if T is
>  between the times contained in the thisUpdate and nextUpdate fields.
>  If more than one current delta CRL for a given scope as of T is
>  encountered, the application SHOULD consider the one with the latest
value
>  in thisUpdate to be the most current one; while if only one current
delta
>  CRL for a given scope as of T is encountered, the application SHOULD
>  consider it to be the most current one. Note that if two delta CRLs,
valid
>  at time T, are placed in a repository, unless additional security
measures
>  are taken, there is no guarantee that both will necessarilly be seen.

 [Tom] I'll leave SHOULD vs. MUST for Russ, although I don't understand
what
 would lead a retrospective verifier to use the second or third most
current
 delta CRL rather than the most current, if he recognizes them as such.
 Your last sentence is helpful, although I don't think that the measures
 which guarantee both deltas being seen are security measures.  The most
 common reason to only see one would be an LDAP client implementation which
 only picked up one value of a multi-valued attribute.

The most common reason to only see one CRL has nothing to do with LDAP.
The reasons are among the following:

  a) the administrator of one of the repositories where the CRLs are
    replicated has purposely suppressed some CRLs. This is a suppression
    while in storage.

  b) during the replication process some CRLs have been removed. This is
     a suppression while in transit.

X509 does NOT rely on the security of the repositories (called Directories)
or of their administrators.

Denis

(snip)

---

From: "David P. Kemp" <[email-masked]>
Date: Tue, 03 Jul 2001 09:43:24 -0400

Tom,

It isn't a question of whether "X.509" does or does not rely on the security
of repositories and administrators.  The question I see is:  "I have to design
a secure system -- what is the minimal set of properties that that system must
have in order to meet the desired level of assurance?"

You always have to analyze the personnel and practices of the CA and CRL issuer.
But if you choose a design that requires repositories to have security
properties,
you also have to analyze the personnel and practices of all the repositories
that might be used by client applications.  If there's only one repository
controlled by the CA, that might not be too much of an extra burden.  But if
there are geographically distributed repositories then that is just N extra
security evaluations to be performed.  If you use HTTP for CRL caching and
distribution, as I believe is desirable, you would be required to evaluate
the security of independent service providers who provide reliable, available,
high capacity service but who may not even be able to spell PKI.

The easier way is to use writer-to-reader (CRL issuer-to-application) security.
Issue delta CRLs as often as the most critical application needs revocation
information - I don't think every 15 minutes is too extreme an issuance period
for high-risk applications.  Allow, but don't rely on guaranteed receipt of,
unscheduled CRLs and your assurance job will be much easier.

On this point I agree with Denis.

Dave

---

From: Tim Polk <[email-masked]>
Date: Thu, 05 Jul 2001 16:20:15 -0400

Folks,

You may have noticed a new draft of son-of-2459 is now available.  I 
strongly believe this draft represents rough consensus for the WG, and wish 
to forward this draft to the ADs.  I recognize that many people have some 
level of discomfort in different areas, but this document is the best we 
can do.

We have worked certain areas to death, such as delta CRLs, without reaching 
perfect consensus.  *It is my opinion that we never will reach perfect 
consensus in these areas.*  It is also my opinion that this draft reflects 
the thinking of a clear majority of the WG in the disputed areas.  In light 
of this, I believe we (the WG) should limit ours discussion of this draft 
to (1) errors introduced inadvertently in the last editing cycle or (2) 
areas where you believe the editors misrepresented the WG consensus.

As long as we stay at Internet-Draft we are encouraging developers to use 
the old spec.   I believe this document provides a significant enhancement 
over RFC 2459 in many areas, and the industry needs to move to this 
specification.  The path validation and CRL validation sections are far 
more comprehensive and complete than in 2459; the description of CRL s and 
CRL extensions is more complete as well.  This document is aligned with the 
current ISO X.509 and is compatible with the ETSI digital signature 
draft.  In short, there is no *compelling reason* to delay this document 
any further.

It's time to move on to the implementation phase.  Remember, we are cycling 
at Proposed Standard here.  After we perform our interoperability testing, 
we can refine this document as we go to draft standard.

I just completed a review of the diff of the 07 and 08 nroff files.  In my 
opinion, all the differences are minor.  I have summarized them all below:

The differences in technical content between drafts 07 and 08 are as follows:

(a) The text has been clarified regarding the difference between 
self-signed and self-issued certificates.  (various sections)

(b)  The text has been clarified regarding the conformance requirements for 
CRL support.  (section 5).

(c)  The text has been clarified encoding of DNS names in the issuer and 
issuer alternative name fields: both the domainComponent form in the issuer 
field and the DNS name in the issuer alternative name field are 
permitted.  (section 5.2.2, Issuer Alternative Name).

(d)  The text in Section 5.2.4 that describes when a certificate should be 
listed on a delta CRL has been rewritten for consistency with ISO 
X.509.  When a revocation reason is changed (e.g., from keyCompromise to 
affilitationChanged) and the new reason was outside the scope of the delta 
CRL, the 07 text listed the certificate with "removeFromCRL".  After 
discussion with the ISO X.509 editor, this was determined to be 
inappropriate; removeFromCRL is *only* used when a certificate is removed 
from hold.  A client might be confused into accepting the certificate as 
valid.  The 08 text maintains the revocation listing on a delta without a 
reason code as long as some valid base CRL lists the revocation with the 
incorrect reason code.  [check this one out.] (5.2.4)

(e) The text defines "current delta CRL" as a delta where current time is 
between this update and next update.  The text recommends that an 
application that encounters mutiple "current deltas should use the one with 
the latest this update.  (end of 5.2.4)

(f) The text for the freshest CRL extension adds semantics.  Previously, 
this text just pointed to 4.2.1.14 for syntax.  (5.2.6)

(g) The certification path validation algorithm assumes validation with 
respect to current time, just like the CRL text.  The text explicitly notes 
that the algorithm may be extended to handle times in the past. [This 
change was made so that path validation and CRL validation were 
parallel.  Validation with respect to a time in the past is not mandatory 
to implement, so we excluded it in both sections.] (section 6.1)

(h) We added examples for the processing of name constraints.  Intersection 
and union of name spaces isn't particularly intuitive. (6.1.4, steps (g) 
(1) and (g) (2))

(i) We added the requirement that implementations process noncritical 
extensions that they recognize in addition to all critical extensions. 
(6.1.4, step (o))

(j) We expanded the text describing matching the CRL to the certificate 
using the IDP in the CRL and the DP in the certificate. (6.3.3, step (b) 
(2) (i))

(j) We replaced the certificate and CRL examples, using the most recent 
version of the dumpasn1 program.  We had used an older version that did not 
parse the "encapsulated" ASN.1 found in certificate extensions, etc.

(k) We added new paragraphs to the ASN.1 implementers notes covering the 
following topics:  ampersand and underscore aren't in PrintableString; 
encoding of named bit lists; and DER encoding of components that have 
DEFAULT values.

There were also a number of editorial corrections:

(1) We changed the word "null" to "empty" in a few cases to eliminate 
confusion between the ASN.1 NULL and an empty sequence.

(2) We fixed a reference to X.660.

(3) Russ made a number of formatting changes for the sake of consistency, 
such as two spaces after a list number or letter (e.g., (a) or (1) ).

This seems like a long list, but as I said above, I believe all are minor!

It is my goal to forward this document to the ADs Tuesday the 10th at close 
of business.  (I am on vacation the 11th through the 13th.)  Please look at 
the changes noted above.  If the editors have misrepresented consensus, 
let's fix it.  Otherwise, it is time to move forward.

Thanks,

Tim Polk

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working 
Group of the IETF.

         Title           : Internet X.509 Public Key Infrastructure 
Certificate
                           and CRL Profile
         Author(s)       : R. Housley, W. Ford, W. Polk, D. Solo
         Filename        : draft-ietf-pkix-new-part1-08.txt
         Pages           : 128
         Date            : 02-Jul-01

This is the eighth draft of a specification based upon RFC 2459.
When complete, this specification will obsolete RFC 2459.
Please send comments on this document to the [email-masked] mail
list.
This memo profiles the X.509 v3 certificate and X.509 v2 CRL for use
in the Internet.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-new-part1-08.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
         "get draft-ietf-pkix-new-part1-08.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
         [email-masked].
In the body type:
         "FILE /internet-drafts/draft-ietf-pkix-new-part1-08.txt".

NOTE:   The mail server at ietf.org can return the document in
         MIME-encoded form by using the "mpack" utility.  To use this
         feature, insert the command "ENCODING mime" before the "FILE"
         command.  To decode the response(s), you will need "munpack" or
         a MIME-compliant mail reader.  Different MIME-compliant mail readers
         exhibit different behavior, especially when dealing with
         "multipart" MIME messages (i.e. documents which have been split
         up into multiple messages), so check your local documentation on
         how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
Content-Type: text/plain
Content-ID:     <[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-new-part1-08.txt

<ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-new-part1-08.txt>

---

From: "Anders Rundgren" <[email-masked]>
Date: Tue, 10 Jul 2001 15:09:49 +0200

"4.2  Certificate Extensions

   The extensions defined for X.509 v3 certificates provide methods for
   associating additional attributes with users or public keys and for
   managing the certification hierarchy.  The X.509 v3 certificate
   format also allows communities to define private extensions to carry
   information unique to those communities."

Then there is a section Private Internet Extesions where two specific
extension are specified.  I assume that this is the same as the private
extensions mentioned above.

Question: How are arbitrary private extensions supposed to be added?
You must register/define an OID?

Regards
Anders R

---

From: "Housley, Russ" <[email-masked]>
Date: Tue, 10 Jul 2001 11:39:25 -0400

Anders:

Use of private extensions is discouraged (especially critical ones).

You can assign the OIDs for private extensions from any arc that you 
control.  I strongly suspect that an organization like Telia already has an 
arc assigned.  Locating the registrar within Telia is left as an exercise 
to the reader.

Russ

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 11 Jul 2001 18:05:57 +0200

All,

During my previous attempts to raise the issue regarding logotypes and 
branding related to certificates, Steve Kent asked me to come back with a 
more extensive discussion report on this issue with rationales, problems 
and solutions.

Since last  IETF I have worked on this from time to time with an informal 
group of peoples from other vendors who may want to make them self known at 
their own discretion.

The result of this discussion is this report that I propose to be the 
starting point of a new RFC to be developed in PKIX.

/Stefan Santesson

Report on Logotypes in X.509 Certificates

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 report.

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.

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.