[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: charter revisions


At 10:18 AM -0400 9/5/01, Steve Hanna wrote:
Paul Hoffman / IMC wrote: 
 At 11:58 AM -0400 9/4/01, Steve Hanna wrote:
 >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. 

 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.

My original email cited several other security risks that are greater
for logotypes than for textual names: CAs may find it harder to verify a
certificate requester's right to use a logotype than their right to use
a textual name

That is not a security risk, and it is a supposition.

 and logotypes may change appearance radically on
different devices.

More radically than the way a UTF-8 name with non-ASCII characters will be displayed?

 Several other risks have been pointed out in the
recent email discussion: users may not be able to distinguish one
logotype from another,

Ditto for names ("Type 1" vs. "Type 3", similar-looking glyphs in various fonts)

 users may not recall which logotype corresponds
to which entity,

Ditto for names

 and logotypes are not accessible to vision-impaired
users or usable on text-only terminals.

This is indeed an issue.

The whole paragraph should be considered predicated by the first clause
("Unless..."). If that clause does not apply (i.e., we can develop a
fairly secure way to place logotypes in certificates), then I don't have
any objection to having this as a PKIX work item. But I have seen no
sign that the objections raised so far can be overcome.

Then that should come up when discussing the protocols, not the charter.

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).

--Paul Hoffman, Director
--Internet Mail Consortium