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

From: "Trevor Freeman" <[email-masked]>
Date: Wed, 23 Oct 2002 17:09:28 -0700

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. 

Trevor

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

>
>If audio is supported in the protocol in a well structured manner, and
>nobody deploys it, then it's just dropped before it becomes standard.
>
>I do believe though that the deployment industry is likely to find some
use
>for it.

Err, I think the rule is that we start with a firm requirement and
implement something.  I think there has been a failure to demonstrate a
firm requirement. If someone can come up with a plausible meaningful
reason
to put audio in certificates then we can consider it.  Until then, we
should concentrate on solving actual problems, not dreaming up
hypothetical
ones.  Why isn't there support for MPEG movies in the draft for 
example? (I hope this doesn't give anyone ideas :-).

As someone who has to implement this stuff, let me just say that there
is a
cost to specifying something that won't (or shouldn't) be used.  You
still
end up having to implement and test it to give the perception that your
products are complying with standards.  It is precisely this
overspecification in the ITU-T standards that has led to so much garbage
which has to be supported already.  The certificate path processing
algorithm is a case in point.  Its complexity is created by a large
number
of rarely used extensions whose usefulness is dubious at best.

So, come up with a plausible use case for audio that cannot be met by
existing mechanisms, and it can be considered, otherwise drop it, and
make
implementers lives a little easier.

-- 
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: Thu, 24 Oct 2002 10:35:41 +1000

>Microsoft and other accessibly groups is to add audio the interface

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