Re: charter revisions

[Steve Hanna <steve.hanna@xxxxxxx>]

Paul Hoffman / IMC wrote:
> >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.

The risk is that it may be quite easy for a certificate requester to get
an invalid logotype certified. However, this is a supposition, as you
say. We have heard the CA vendors say "Trust us, we can handle it." And
maybe they can. But I, for one, would be much more comfortable if
logotypes were ignored unless all certificates in the path indicate that
they should be supported. This shouldn't be a problem for those who
think that cross-certification is a bad idea.

> >  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?

Maybe not, especially when part of the UTF-8 name cannot be rendered
properly on the user's device (because it includes characters that
aren't present in any font on that device, for instance). We should
probably consider adding text to some future successor to 2459 warning
about this case. Maybe we can provide similar text warning that
logotypes in certificates should not be scaled or mapped to different
colors before display. If this requirement cannot be met, the
certificate should be treated as if it did not contain the logotype.

> >  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 who aren't concerned about security will always just click OK (or
enter their brokerage info at a web site without considering whether
this is secure). It's hard to provide much protection for such users
(although putting logotypes in certificates will make it harder for
programs that try to be smart about what's safe).

But we should try to avoid designing in features that nobody can use
securely. The current system allows a careful user with a properly
configured system to type a URL and have the browser check that the host
name matches the certificate or examine a name in a signed email and
decide whether it is the one desired (ignoring poor fonts, misspellings,
etc). Certifying and examining a logotype is a much more fuzzy process,
open to many more errors.

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

But we have a proposal on the table for how to include logotypes in
certificates and the proposal is demonstrably flawed (although this is
subject to some debate). Nobody has been able to come up with any way to
fix it. My conclusion is that it can't be fixed. Shouldn't the question
of whether the work item is feasible be relevant to a discussion of
whether it should be added to 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).

You're probably right. I suggest that our working group chairs make a
decision about whether they still want to include this work item in the
proposed charter. If they want to do so, I would ask that they inform
the Security ADs that the working group did not reach consensus on this
question and point the Security ADs to the discussion here on the list
so that they can make up their own mind. I believe that all of the
relevant arguments in favor and opposed have been raised.

Thanks,

Steve