Re: charter revisions

[Steve Hanna <steve.hanna@xxxxxxx>]

Russ Housley wrote:
> I do not think that we will see widespread deployment of
> certificates without logos.  One measure of success will be the
> number of certificates that average Internet user have.  Hopefully
> every Internet user will have at least one.  I suspect that as we
> become successful, these logos will be the tag by which users
> select a certificate.

This is an interesting argument. I think you're saying that the user
will find the logo useful when deciding which of his certificates to
use (such as when signing an email or performing client authentication
over SSL). If this were the primary use of logotypes in certificates,
then the risks of displaying an invalid logo would be considerably
reduced (the user might select the wrong one of his certificates to
authenticate with). However, the current logotype Internet Draft does
not describe this use case. All of the use cases described in section
1.1 of that document have the user looking at a logo to decide
whether a certificate presented by some other party is trustworthy.
In those cases, the risks of making an error are much greater.

Unless the author of the Internet Draft indicates otherwise, I will
assume that the primary purpose of putting logotypes in certificates
is so that users can view them to make decisions about whether the
certificates are trustworthy. In that case, the risks are much greater
than those for the use case you described.

> I do not want to see more than one way that logos can be put into
> certificates. That is the most important reason for PKIX to be
> involved in the definition. You seem to agree that the market has
> a demand for logos. Letting each vendor devise an independent way
> to meet this marketing requirement would be very bad for all
> implementors.

Unless we can develop a fairly secure way to meet the "marketing
requirement" for logotypes in certificates, I would say that it is
our obligation as an IETF working group to NOT accept this as a
work item. Much better to have multiple incompatible ways
to do something insecure (probably resulting in little deployment
of this feature) than to have the PKIX working group issue an RFC
explaining the one true way to do it. We are in the Security area,
after all!

> Anyway, we should not have the complete technical debate on a
> threat about the charter.

Certainly, we don't need to have the complete technical debate at
this point. But there should be some requirement that work items
be feasible and provide some security benefit before they are
accepted by this working group. Otherwise, we will waste our time
(and confuse the public) by accepting all sort of ideas and then
having to throw them out.

-Steve