[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: draft-ietf-pkix-logotypes-06.txt
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:povey@xxxxxxxxxxxxx]
Sent: Wednesday, October 23, 2002 5:36 PM
To: Trevor Freeman
Cc: Stefan Santesson; ietf-pkix@xxxxxxx
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: povey@xxxxxxxxxxxxx|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