[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: draft-ietf-pkix-logotypes-06.txt
The presence of the logotype extension sets no more a precedence that
having a subject alternate name extension. When given multiple name
forms in a certificate PK clients make a choice on which names to
display (if any) given the context of the applications using the
certificate. Email clients tend to use the RFC822 name, browsers the DNS
name. RFC3039 is another example where additional information is
available in an extension and I don't see any great problem with clients
feeling compelled to display that information if they don't want to.
Where a developer feeds this information makes sense for their
application - I am sure this will get adopted. Developers will not spend
time on things they don't consider important.
-----Original Message-----
From: Peter Gutmann [mailto:pgut001@xxxxxxxxxxxxxxxxx]
Sent: Monday, October 21, 2002 8:39 AM
To: Denis.Pinkas@xxxxxxxx; David Cross
Cc: ietf-pkix@xxxxxxx
Subject: RE: draft-ietf-pkix-logotypes-06.txt
"David Cross" <dcross@xxxxxxxxxxxxx> writes:
>I my opinion, I am afraid that the presence of logotypes in additonal
types
>of certificates will imply that clients should display such logos when
path
>validation or revocation check is performed. For example, every time a
mail
>message is processed and signature check performed, should the mail
client
>display the logo for the OCSP responder to the end user? In that
example, I
>would argue strongly that we have extended from the useful scenario of
>enabling simpler certificate selection for end users to an intolerable
user
>experience.
As long as implementors follow the standard tradition of adding a "Don't
show
me this again" checkbox (checked by default) to the display, we'll be
OK.
This probably doesn't make the addition of logotypes too useful though,
since
you'll only see them the first time the software is run.
Peter.