[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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