Subject: RE: Logos: objection to charter revisions

From: "Tom Gindin" <[email-masked]>
Date: Mon, 24 Sep 2001 14:03:54 -0400

While I am not sure that Steve proposed that individuals issue
cross-certs in his posting, I would like to record my view that allowing an
RP to extend trust to a specific root CA with restrictions similar to the
constraints extensions is a desirable feature in an API.  Since IMHO this
is basically an API issue, I'm not sure that it's within PKIX's scope.

          Tom Gindin

Peter Williams <[email-masked]>@mail.imc.org on 09/24/2001 11:36:46 AM

Sent by:  [email-masked]

To:   "'Stephen Kent'" <[email-masked]>, Stefan Santesson
      <[email-masked]>
cc:   "PKIX (E-mail)" <[email-masked]>
Subject:  RE: Logos: objection to charter revisions

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

---

From: Stephen Kent <[email-masked]>
Date: Mon, 24 Sep 2001 18:14:42 -0400

>is basically an API issue, I'm not sure that it's within PKIX's scope.
Right.  I did not say anything about "individuals" issuing cross 
certs.  I referred to organizational CAs, e.g., certified by other 
such CAs, or by bridge CAs, etc.

Steve