Re: charter revisions

[Steve Hanna <steve.hanna@xxxxxxx>]

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.

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 and logotypes may change appearance radically on
different devices. Several other risks have been pointed out in the
recent email discussion: users may not be able to distinguish one
logotype from another, users may not recall which logotype corresponds
to which entity, and logotypes are not accessible to vision-impaired
users or usable on text-only terminals.

> >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!
> 
> The end of that paragraph doesn't follow from the beginning of the
> paragraph. As long as the method we described doesn't have any
> security holes, it doesn't matter if we meet some pre-existing
> marketing "need". Further, some of the multiple, non-interoperable
> protocols are likely to have security problems; that is worse than
> having one protocol that doesn't meet the need of some CAs.

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.

> Mike Myers wrote:
> >I agree with Stephen Farrell and Steve Hanna that logotypes are
> >out of scope.
> 
> They are out of scope; the discussion is whether to add them to
> the scope.

Of course, you are right. This is a charter discussion.

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.

-Steve