Subject: RE: draft-ietf-pkix-logotypes-06.txt

From: "Trevor Freeman" <[email-masked]>
Date: Wed, 23 Oct 2002 19:33:04 -0700

Dean,
The approach you suggest would put the onus on the application having
text to audio technology to support this case as apposed to simply
playing an audio file. And that text to audio technology must work for
all languages and cope with translation. That is a pretty high bar.
Playing an audio file is as you point out a well understood mechanism
which can be widely implemented and addresses the issue of language
because the client can pick the audio file appropriate for them. Your
suggestion also does not provide for the classes of image which the
draft supports. Equality if you are truly interested in implementation
simplicity your suggestion forces me into two radically different code
paths for audio and images which the current draft does not. 
We can certainly point out in the security section the need to ensure
that there is no ambiguity with other audio stream that many be being
played.

Trevor

-----Original Message-----
From: Dean Povey [mailto:[email-masked]] 
Sent: Wednesday, October 23, 2002 5:36 PM
To: Trevor Freeman
Cc: Stefan Santesson; [email-masked]
Subject: Re: draft-ietf-pkix-logotypes-06.txt 

On Wed, 23 Oct 2002 17:09:28 MST, "Trevor Freeman" wrote: 
>Dean,
>The case for audio is simple. People with specific types of visual
>disability will not gain any benefit from a logotype image even if you
>magnify the image. To help these people the general advice from
>Microsoft and other accessibly groups is to add audio the interface
>design. 

Hi Trevor,

As I stated in an earlier mail, it would be more appropriate for the
browser software to read the issuer/subject name of the cert and more in
keeping with the way that web accessibility is usually done.  This does
not
require any additional support.  The fact that logotypes are not useful
to 
people with visual impairment is irrelevant to the standard, as the
image 
simply acts as an aid to the trust process are not mandatory for it.  It

can be argued that accesibility software reading a message similar to:

"The following web page is authenticated by a certificate issued to X by
Y"

is as (more?) effective than a logotype in achieving the end goal of 
increasing the visibility (in the abstract sense) of the binding between

the content and the certificate.

However, I have just thought of another objection on security grounds.
Most web browsers support the playing of audio when a web page loads.
How
will you distinguish between the audio in the cert and something a
person
puts on a web page?  This problem does not exist for logotypes, as the
browser can reserve a part of its user interface for displaying the
logos
in a way that cannot be overridden by the page itself. AFAIK, this issue
is
not addressed in the current draft.  If concensus indicates that audio 
goes ahead, this will need to be addressed in the "Client Use" and/or 
"Security Considerations" sections.

Cheers.
-- 
Dean Povey,             |em: [email-masked]|JCSI: Java security
toolkit
Wedgetail Communications|ph:  +61 7 3023 5139   |uPKI: Embedded/C PKI
toolkit
Level 14, 388 Queen St, |fax: +61 7 3023 5199   |uSSL: Embedded/C SSL
toolkit
Brisbane, Australia     |www: www.wedgetail.com |XML Security: XML
Signatures

---

From: Dean Povey <[email-masked]>
Date: Fri, 25 Oct 2002 08:51:11 +1000

>all languages and cope with translation. That is a pretty high bar.

How else do you think visually impaired people read web pages?  I don't 
know a huge amount about this, but there is a variety of software (e.g. 
JAWS see http://www.freedomscientific.com/fs_products/software_jaws.asp) 
that does text to speech translation, and when you develop web sites for 
accessibility you consider how such software will "read" your 
site.

However, the comment about languages is interesting, will
internationalization issues be addressed in audio types?

I apologise for not raising this issue earlier than last call, but it 
seems there is sufficient controversy about this feature to warrant a 
decision.  I think most of the major arguments have been covered, and I 
have seen at least one other call for a straw poll on the feature.  I have 
no wish to hold up this draft endlessly.

I think the issue of accessibility is an important one, but perhaps this 
needs to be addressed in a separate draft that considers other parts of 
PKIX as well.

If we are to hold a straw poll, might I suggest rather than a simple 
plebiscite on whether audio is in or out that the options proposed be:

1. To exclude the audio type from the draft, and either provide text
   addressing accessibility concerns (for example using the suggestion that
   software read out the issuer and/or subject names), or make a work item
   to write a separate draft which deals with accessibility issues related
   to PKIX in general.

2. To leave the audio type in, and add text to security considerations to
   deal with the problem of distinguishing audio for trust purposes from 
   any other audio that an application might present, as well as address 
   the internationalisation issue.

Thoughts?
-- 
Dean Povey,             |em: [email-masked]|JCSI: Java security toolkit
Wedgetail Communications|ph:  +61 7 3023 5139   |uPKI: Embedded/C PKI toolkit
Level 14, 388 Queen St, |fax: +61 7 3023 5199   |uSSL: Embedded/C SSL toolkit
Brisbane, Australia     |www: www.wedgetail.com |XML Security: XML Signatures

---

From: "Stefan Santesson" <[email-masked]>
Date: Fri, 25 Oct 2002 17:27:38 +0200

Dean,

I'm not opposed to let people say what they think, but I don't think this is
a straw poll issue. At least not in a sense where you can count votes pro an
against to find a winner.

That is more appropriate for selecting 1 out of n solutions to a given
problem.

This case is different. This is about figuring out if there is enough
interest or not to support audio aspects of logotypes. If there is enough
interest, then we are home. No matter how many who won't use it.

I know that we all are here as individuals, but given the persons expressing
support for this, and given who they work for, I would say we have enough
support to go ahead without any straw poll (I bet Steve Kent will correct me
on this one :-), but for me this is still a valid aspect of reality).

/Stefan

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Dean Povey
> Sent: Friday, October 25, 2002 12:51 AM
> To: Trevor Freeman
> Cc: Stefan Santesson; Housley, Russ; [email-masked]

---

From: "Housley, Russ" <[email-masked]>
Date: Fri, 25 Oct 2002 11:52:00 -0400

Dean:

Reading the content of the certificate is what we are trying to avoid.  For 
the people without disabilities, the image is intended to provide a quickly 
identifiable affiliation.  We want a similar aid to the visually disabled.

Russ

---

From: Dean Povey <[email-masked]>
Date: Tue, 29 Oct 2002 09:55:11 +1000

>identifiable affiliation.  We want a similar aid to the visually disabled.

While I agree with the sentiment, I'm not sure I agree with the mechanism. 
However, I am willing to acquiesce in the interest of moving the draft forward.

On the security issue I raised, can we at least add something like the
following text to the Security Considerations.

"Applications that make use of certificate logotypes MUST ensure that 
their presentation cannot be masqueraded by the display of other dynamic 
mutlimedia content.  For example, it should not be possible for an image 
or audio content on a web page to be confused with a logotype for a 
certificate.  For image logotypes this MAY be done by reserving part of 
the user interface for the display of logotype images, and ensuring that 
no dynamic content can display an image at that location.  For audio 
logotypes (particularly in applications for the visually impaired, where 
all content is rendered solely in an audio form), there MUST be a 
mechanism for the user to distinguish the logotype audio, such as by 
requiring an action by the user before the audio is played."
-- 
Dean Povey,             |em: [email-masked]|JCSI: Java security toolkit
Wedgetail Communications|ph:  +61 7 3023 5139   |uPKI: Embedded/C PKI toolkit
Level 14, 388 Queen St, |fax: +61 7 3023 5199   |uSSL: Embedded/C SSL toolkit
Brisbane, Australia     |www: www.wedgetail.com |XML Security: XML Signatures

---

From: Dean Povey <[email-masked]>
Date: Tue, 29 Oct 2002 12:27:26 +1000

<snip>
>following text to the Security Considerations.

It occurred to me after I sent this, that the section on "Client use" may 
be a more appropriate place to put the text.