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

From: "Hamrick, Matt" <[email-masked]>
Date: Thu, 24 Oct 2002 19:24:08 -0400

I suspect that the issue is that commercial entities with a vested interest
in protecting and promoting brand awareness wish to require certain
presentations when certificates are presented. And who can blame them? If
they ran the world, all compatible products that displayed certificate
information would be REQUIRED to play the contents of certain audio
extensions.

However, they do not run the world, and it is unlikely (in my opinion) that
there will ever be a component that plays an audio clip when a certificate
is "viewed." Look at the quality of existing tools in popular software to
view certificates: Netscape, Outlook, IE, etc. It is only recently that we
have IE components that can figure out how to display even the most basic
extensions. I find it hard to believe that Microsoft, with all it's
resources, could be convinced to add such a feature (the playing of audio
clips referenced in certificate extensions.) MS and other vendors of
consumer software have been trying their best to push the interface that
describes certificate details as far away from the user as possible. Where
it is seen, it is generally considered an "advanced" feature for a few
power-users, and I just don't think there's any great benefit to spending
money to support a feature to "market" to such a small audience.

Remember, the logotype is not a replacement for identity information, and it
is to be displayed/played, "given that it [the RP's cert viewing software]
is configured to do so."

In that certain members of this list affiliated with certain very large
software marketing organizations have indicated they are interested in
standardizing the representation of a URI and mime type representing a sound
representative of their corporate identity, I can hardly see the harm in
allowing them to pursue their folly. (Well... maybe it's not folly, they did
actually spend time working on the draft...)

-----Original Message-----
From: Trevor Freeman [mailto:[email-masked]]
Sent: Thursday, October 24, 2002 1:46 PM
To: Denis Pinkas; Stefan Santesson
Cc: pkix
Subject: RE: draft-ietf-pkix-logotypes-06.txt

Hi Denis,
Can you please elaborate on you comment of "... adding audio to the
interface design does not mean adding audio for everything" I don't
understand the point you are making. 

The decision on if or when to display the logotype / play the audio is
down to the interface designer. There are plenty of UI designs shipped
in products for X.509 certificates just displaying text names which are
unusable - but I don't hold that to be the problem RFC3280.

Trevor

-----Original Message-----
From: Denis Pinkas [mailto:[email-masked]] 
Sent: Thursday, October 24, 2002 2:37 AM
To: Stefan Santesson
Cc: pkix
Subject: Re: draft-ietf-pkix-logotypes-06.txt

Stefan,

> I mostly agree with you.
> 
> What I mean is that there is some line, beyond which you just need to
accept
> the whish to do something and say - OK if some implementers want to do
this
> type of thing, what is the best way to do it?
> 
> I think the most cases where a firm requirement is badly needed is
where
> someone what to do something in a different way, where current
standard
> gives another way of doing almost the same thing, and where doing the
> proposed changes/amendments would produce alternative solutions to
closely
> related problem (Like the PI versus serialNumber Attributes, OCSPv2
versus
> SCVP, CMP versus CMC .....)
> 
> I think Trevor has demonstrated a reasonable need to use audio with
> Logotypes.

The argument from Trevor is not convincing: adding audio to the
interface 
design does not mean adding audio for everything.

  ... but this demonstrates that it was *not* a joke (either god or
bad), 
from at least two of the co-editors of the document. :-(

Denis

> /Stefan
> 
> 
>>-----Original Message-----
>>From: [email-masked]
>>[mailto:[email-masked]]On Behalf Of Dean Povey
>>Sent: Thursday, October 24, 2002 1:04 AM
>>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
>>
>>
>>
> 
> 
>