Subject: RE: Logos: objection to charter revisions

From: "Manger, James H" <[email-masked]>
Date: Thu, 6 Sep 2001 19:14:58 +1100

Steve Hanna,

You says "nobody has been able to come up with any way to fix [the current
logo proposal]" and conclude "that it can't be fixed".  .. but you provide
fixes earlier in the same e-mail!

Your statement that logos should be "ignored unless all certificates in the
path indicate that they should be supported" is just the sort of "logo
constraint" that enables safe use of logos.

One good reason for looking at logos is that it focuses attention on the
limitations of the current name constraints mechanism.  Name constraints
should be able to deal with new name forms and with non-hierarchical name
forms (logos are both), but the current extension cannot.  Name constraints
should, for instance, be able to exclude names of specified types or only
permit names of specified types.  [Another problem with the current name
constraints is that the "constraints" have to use the same syntax as the
"name", which is not always appropriate.]

> ----------
> From: 	Steve Hanna [mailto:[email-masked]] 
> Sent:	Thursday, 6 September 2001 7:36
> 
	..I, for one, would be much more comfortable if logotypes were
ignored unless all certificates in the path indicate that they should be
supported..

	..provide similar text warning that logotypes in certificates should
not be scaled or mapped to different colors before display. If this
requirement cannot be met, the certificate should be treated as if it did
not contain the logotype.

	..the proposal is demonstrably flawed (although this is subject to
some debate). Nobody has been able to come up with any way to fix it. My
conclusion is that it can't be fixed.

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 06 Sep 2001 11:02:37 +0200

After seeing all that discussion about logos, I realized that we had 
a solution (i.e. the draft writen by Stefan) for an unknown problem.

1) Are logos to be used in server certificates ? 
   If so, what would be their intended meaning ?

2) Are logos to be used in human-user certificates ? 
   If so, what would be their intended meaning ?

3) Are logos to be used in CA certificates ? 
   If so, what would be their intended meaning ?

4) Are logos to be used in self-signed certificates ? 
   If so, what would be their intented meaning ?

I do not think that the meaning and the use of the logo information will
necessarilly be the same for all of the above cases.

If that topic is going to stay on the charter, before we define a solution
we should first define the requirements. So an INFORMATIONAL RFC on the
requirements should be the first step. This Informational RFC should at
least answer to the questions raised above.

Denis

---

From: Steve Hanna <[email-masked]>
Date: Thu, 06 Sep 2001 10:31:35 -0400

"Manger, James H" wrote:
> You says "nobody has been able to come up with any way to fix [the
> current logo proposal]" and conclude "that it can't be fixed".
>  .. but you provide fixes earlier in the same e-mail!

That will teach me to offer constructive suggestions! ;-)

> constraint" that enables safe use of logos.

I still wouldn't call this "safe". There are other concerns that haven't
have been addressed (problems with scaling or color mapping,
accessibility concerns, etc.). But at least a "logo constraint" (or,
more accurately, a "logo enabler") would restrict use of logos to
communities that have considered these concerns and decided that they
are acceptable.

-Steve

---

From: "Michael Myers" <[email-masked]>
Date: Thu, 6 Sep 2001 15:00:32 -0700

Further, of what utility is a logo to an IPSEC gateway, for example?  I
suspect about as much value as embedded text asserting a relying party's
obligations.

Mike

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Denis Pinkas
> Sent: Thursday, September 06, 2001 2:03 AM
> Cc: PKIX (E-mail)
> Subject: Re: Logos: objection to charter revisions
>
>
>
>

---

From: Denis Pinkas <[email-masked]>
Date: Mon, 24 Sep 2001 11:30:25 +0200

Stefan,

The current point is whether we include or not this work item on our "PKIX
plate". I wonder what the decision is at this time. Nevertheless, I will
provide you with some comments on your e-mail.

> Denis,
> 
> As I catch up the logo discussion, I think your questions are pretty much
> answered in the current draft.
> 
> In principle, there is no difference between the certificate types you
> mention regarding logos. What the logos means to the relying party is up to
> each relying party to define.

It seems difficult define extensions which have a left open and hence
undefined meaning !
 
> What is more important is that the different the logotypes have distinct
> meanings.
>
> 1) Subject organization logotype: The logotype of the organization
> specified in the subject field
> 2) Issuer Logotype: The logotype of the organization specified in the
> issuer field
> 3) Concept logotype: A logotype used by the issuer to represent the concept
> under which the certificate was issued.
> 
> The concept may represent a type of assurance level, policy or a family of
> distinct services shared between multiple CAs.
 
> The meaning of these logotypes are the same for any type of certificate,
> but in general they are only used to enhance human recognition after the
> certificate having passed all other validation criteria for certificate
> reliance.

This is the main point that puzzles me. In other words, this extension is
never checked when an automatic processing is being used, but is only
checked (how ???, using which criteria ???) by a human being. When this
extension appears in multiple certificates from a chain, shall all the
logotypes be displayed, or printed ? How should this be done ? 

But the main point is that this could lead to different results whether
human interactions or automatic processing is performed. 

Isn't it a problem ?  

Denis

> /Stefan
> 
> At 11:02 2001-09-06 +0200, Denis Pinkas wrote:
>

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 24 Sep 2001 10:05:02 +0200

Denis,

/Stefan

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 24 Sep 2001 14:50:49 +0200

Denis,

3 Issues:

1) Should logos be checked by automatic processing?
No. Logotypes can't be processed as part of certificate validation 
processing, with one exception which is the binary "allowed" or "not 
allowed" local policy.

2) What logotypes should be displayed in a chain of certificates?
This is up to applications to decide but in general: When you view a 
certificate, only the logos of that certificate is displayed. If you view a 
chain, then normally that view doesn't show certificate details and would 
not show any logo at all. Future applications may however show logotypes 
for each certificate as they display a chain but when displaying a single 
certificate i doubt that any other logos will be displayed.

3) Is there a conflict between automatic validation processing and human 
processing of logotypes
My view is that we have no conflict.
A validation process is the first pit-stop, which will check the 
trustworthiness of a certificate (including its chain) including:
- Chaining to a trusted root
- Validity periods
- Revocation status and presence of suitable status checking service
- key usage
- Key lengths and algorithms
- Suitability and acceptance of certificate policies
- Suitability and acceptance of present names and name forms
- Suitability and acceptance of extensions (including logos)

This process gives a yes and no answer to the question. "Is this 
certificate valid, trusted and fit for its purpose?"

If the user is a mashie. This stops here and goes directly to authorization 
processing in applications.

If not, then we have pit-stop number two, display of certificates, given 
that the certificates passed pit-stop 1
If the user is a person and if his client is configured to display logos. 
The user will have a convenient way to view the certificate through display 
of logos together with associated names in text.

Now, the concern here is if a CA issues a certificate with false logos, 
inconsistent with the present names. Could a user be fooled?
Yes of course would a user be fooled, but the flaw is not in the logotype 
presence. The flaw is that your validation processing allows trust in a bad 
CA. And if you have allowed trust in such CA, logos are the least of your 
problems.

In the end, the self regulating factor is also that nobody can issue 
certificates with bad information and hide from that fact. A bad CA, which 
isn't living up to its decalred practices, will soon be out of business and 
sued up to its ears.

I understand the fear for things we can not control, but names and logos 
are simply such things. Its use and trust in them must be handled by the 
market of CA's, not in a standards body.

But as I said. The protocol issues are standards work. Lets assume our 
responsibility and provide solid tools needed by the market, and make them 
good and globally interoperable.

Whether you like it or not. So far, all major market players I have talked 
to (and they are many), including members of the European CA forum (ECAF) 
and including the mobile world, wants and needs logos. Lets not hide from 
this fact in our own little dream world. Lets accept the challenge instead.

/Stefan

---

From: Stephen Kent <[email-masked]>
Date: Mon, 24 Sep 2001 10:19:45 -0400

Stefan,

><snip>

>Now, the concern here is if a CA issues a certificate with false 
>logos, inconsistent with the present names. Could a user be fooled?
>Yes of course would a user be fooled, but the flaw is not in the 
>logotype presence. The flaw is that your validation processing 
>allows trust in a bad CA. And if you have allowed trust in such CA, 
>logos are the least of your problems.

In fairness, your characterization seems to be based on the 
assumption that acceptance of certs issued by a CA represents an 
unqualified act of trust.  This may be the case for public CAs, but 
it is not for organizational CAs, for example. We have the name 
constraints extension to allow us to control the space of names that 
we will accept from CAs we cross certify.  So we already have 
mechanisms to avoid the need to trust completely every CA that we 
cross certify.

>certificates with bad information and hide from that fact. A bad CA, 
>which isn't living up to its decalred practices, will soon be out of 
>business and sued up to its ears.

Yes, but wherever possible we like to impose technical constraints on 
CA behavior, not just rely on remedial, legal, actions.  The question 
is to what extent can we do that with the proposed logotype extension?

>I understand the fear for things we can not control, but names and 
>logos are simply such things. Its use and trust in them must be 
>handled by the market of CA's, not in a standards body.

But, as noted above, we DO have some ability to control bad names.

>But as I said. The protocol issues are standards work. Lets assume 
>our responsibility and provide solid tools needed by the market, and 
>make them good and globally interoperable.
>
>Whether you like it or not. So far, all major market players I have 
>talked to (and they are many), including members of the European CA 
>forum (ECAF) and including the mobile world, wants and needs logos. 
>Lets not hide from this fact in our own little dream world. Lets 
>accept the challenge instead.

Endorsements from vendors and vendor fora of this sort have never 
been an acceptable justification for our adopting a proposed 
mechanism.  It's appropriate to cite such interest to justify 
spending the WG's time on this proposed work item, but it does not 
mean that we will create a standard based on such endorsements. This 
WG, like all others in the IETF, is composed of individual technical 
contributors who represent themselves in discussions and who strive 
to persuade other WG members of the technical merits of protocols 
that are offered as standards.

Steve

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 25 Sep 2001 13:28:51 +0200

Steve,

Thanks for the clarifications. I agree in general to everything you say.

Speking of users trust in a CA I wander though what mechanisms users have 
to quantify trust in the certificate and it's content (including 
extensions) after passing the validation mechanisms performed according to 
local policy.

Is the user (human person) supposed to know what kind of extension data 
that this particular CA is trusted to certify?

Havn't we failed if we are forced to use such assumtions?

Isn't it fair to require all cross certifying CA's to make sure that the 
CA's they cross certify have agreed to behave in such was that the user can 
perform an "unqualified act of trust"?

Do you have any suggestions regarding how to contrain CA's use of 
extensions and their content?

/Stefan

At 10:19 2001-09-24 -0400, Stephen Kent wrote:

>>presence. The flaw is that your validation processing allows trust in a 
>>bad CA. And if you have allowed trust in such CA, logos are the least of 
>>your problems.
>
>In fairness, your characterization seems to be based on the assumption 
>that acceptance of certs issued by a CA represents an unqualified act of 
>trust.  This may be the case for public CAs, but it is not for 
>organizational CAs, for example. We have the name constraints extension to 
>allow us to control the space of names that we will accept from CAs we 
>cross certify.  So we already have mechanisms to avoid the need to trust 
>completely every CA that we cross certify.
>
>Yes, but wherever possible we like to impose technical constraints on CA 
>behavior, not just rely on remedial, legal, actions.  The question is to 
>what extent can we do that with the proposed logotype extension?
>
>>responsibility and provide solid tools needed by the market, and make 
>>them good and globally interoperable.
>>
>>talked to (and they are many), including members of the European CA forum 
>>(ECAF) and including the mobile world, wants and needs logos. Lets not 
>>hide from this fact in our own little dream world. Lets accept the 
>>challenge instead.
>
>Endorsements from vendors and vendor fora of this sort have never been an 
>acceptable justification for our adopting a proposed mechanism.  It's 
>appropriate to cite such interest to justify spending the WG's time on 
>this proposed work item, but it does not mean that we will create a 
>standard based on such endorsements. This WG, like all others in the IETF, 
>is composed of individual technical contributors who represent themselves 
>in discussions and who strive to persuade other WG members of the 
>technical merits of protocols that are offered as standards.
>
>Steve