Re: charter revisions

["David P. Kemp" <dpkemp@xxxxxxxxxxxxxx>]

Paul Hoffman / IMC wrote:
> 
> At 10:18 AM -0400 9/5/01, Steve Hanna wrote:
> >Paul Hoffman / IMC wrote
> >>  Are the risks any greater than what we have in 2459 now with spelling
> >>  errors or things like "FooCA type 1 certificate" vs. "FooCA type 2
> >>  certificate"? I agree with Russ that the benefits are higher, but I'm
> >>  not at all convinced that the risks are higher.
> >
> >Yes, the risks are greater than those encountered with textual names.
> >For one thing, name constraints provide an effective way to limit the
> >portion of the name space that can be reached via a cross certificate.
> >No corresponding mechanism has been suggested for logotypes nor does it
> >seem likely that such a mechanism could be developed.
> 
> I don't think that name constraints works well against spelling
> errors or the kinds of names I specified above. I agree that it will
> probably be impossible to constrain logotypes any more than it is to
> constrain the value within CN.


The distinction is that name constraints is a mechanism; there is no
analogous mechanism for logotypes.  If you have name constraint with
a permitted subtree under "FooCA Type 1", then your browser will reject
all certificates under "FooCA Type 2" regardless of whether the "2" is
an innocent spelling error or a malicious spoof attempt.  What makes
you believe that name constraints don't work well (i.e. that the rejection
of "2" is an undesired outcome)?


> >RFC 2418 (BCP 25) says that "IETF developed technologies should not add
> >insecurity to the environment in which they run." The IESG has enforced
> >this in the past and it seems especially pertinent to a working group in
> >the Security Area. I doubt that the IESG or the Security ADs will accept
> >this work item in our charter unless we can argue convincingly that we
> >can develop something that would not add insecurity to the environment
> >in which it is run. I don't think we're there yet.
> 
> Trying to predict what the IESG will do is just plain silly (even
> individual IESG members are bad at this).

There is a distinction between what BCP 25 says in black and white,
and attempting to predict how the IESG will interpret BCP 25 when
considering a new work item.   Rather than wasting bandwidth calling
prediction "silly", you should argue substantively about why logotypes
do not add insecurity to the environment in which they run.

I'm agnostic on the actual issue - logotypes in certificates are
both seductive and dangerous.  The potential harm from user
confusion will outweigh the cuteness factor in some circumstances
(promiscuous trust lists) and will not in others (trustworthy CAs who
attempt to make logos meaningful, distinct, and few).  What should
PKIX do about it?  I don't know.