Re: Logos: objection to charter revisions

[Stefan Santesson <stefan@xxxxxxxxxxxx>]

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:

> 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