Subject: RE: Logos: objection to charter revisions

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 6 Sep 2001 10:54:49 -0700

I still fail to see the problem, if you have a cross certified cert chain
you should show the entire chain as logos.

So the user would see the following 

[VeriSign PCA3] -> [SureTrust] -> [British Stuff PLC] -> [Alice]

Or

[JIS RoT] -X-> [BAL RoT] -X-> [Bob]

In other words there is no need for constraints because the user is going to
see the trust chain explicitly.

I don't see any problem in stating that logotypes on end user certs should
only be displayed if the root of trust says to use 'em. I think it is pretty
clear that the app software vendors would want to load the new roots of
trust with the images in them.

I would not want to have to re-issue several thousand intermediate CAs to
support logotypes however. So the OID for the root cert would have to allow
for the following cases:

1) Show logotypes of any cert in the chain that has one.

2) Only show logotypes if every cert bellow this one in the chain has a
'show logotypes' OID.

		Phill

Phillip Hallam-Baker FBCS C.Eng.
Principal Scientist
VeriSign Inc.
[email-masked]
781 245 6996 x227

---

From: Peter Williams <[email-masked]>
Date: Mon, 24 Sep 2001 08:36:46 -0700

Steve proposed that individuals be
able to issue cross-certificates
to limit, by virtue of the name
constraints, the degree to which
trust is helf in a given CA, acting
in support of some secure interworking activity. 

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]]
Sent: Monday, September 24, 2001 7:20 AM
To: Stefan Santesson
Cc: PKIX (E-mail)
Subject: Re: Logos: objection to charter revisions

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.

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

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