RE: Logotypes in certificates

Andrew Hoag <AHoag@verisign.com> Mon, 19 March 2001 23:13 UTC

Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA25191 for <pkix-archive@odin.ietf.org>; Mon, 19 Mar 2001 18:13:35 -0500 (EST)
Received: from localhost (daemon@localhost) by above.proper.com (8.9.3/8.9.3) with SMTP id PAA16539; Mon, 19 Mar 2001 15:12:59 -0800 (PST)
Received: by mail.imc.org (bulk_mailer v1.12); Mon, 19 Mar 2001 15:12:57 -0800
Received: from eagle.verisign.com (eagle.verisign.com [208.206.241.105]) by above.proper.com (8.9.3/8.9.3) with ESMTP id PAA16509 for <ietf-pkix@imc.org>; Mon, 19 Mar 2001 15:12:56 -0800 (PST)
Received: from postal-gw2.verisign.com (verisign.com [63.104.27.102]) by eagle.verisign.com (8.9.3/BCH1.7.1) with ESMTP id PAA04620; Mon, 19 Mar 2001 15:15:08 -0800 (PST)
Received: by postal-gw.verisign.com with Internet Mail Service (5.5.2650.21) id <FXDRQB1Q>; Mon, 19 Mar 2001 15:12:53 -0800
Message-ID: <2F3EC696EAEED311BB2D009027C3F4F402AE685B@vhqpostal.verisign.com>
From: Andrew Hoag <AHoag@verisign.com>
To: 'Stefan Santesson' <stefan@accurata.se>, Trevor Freeman <trevorf@Exchange.Microsoft.com>, David Cross <dcross@microsoft.com>, ietf-pkix@imc.org
Subject: RE: Logotypes in certificates
Date: Mon, 19 Mar 2001 15:12:52 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe

The other issue being implied here is that of affinity and branding. 

Clearly we generally approach certificates from a security & risk management
perspective, but there are other commercial drivers as well. Most notably,
using a certificate that provides some sort of tie to the issuer or
authenticating entity. This is the same reason you may get a Visa card from
your airline frequent flyer program. 

Certainly in many usage cases it is beneficial, for both the company
providing certificates and to the end-user, to provide some sort of improved
UI for viewing certificates, including binding of a logo. 

A standard method for providing this type of user-friendly data would be
very helpful towards greater commercial use & applications of certificates.

Andrew Hoag


> -----Original Message-----
> From: Stefan Santesson [mailto:stefan@accurata.se]
> Sent: Sunday, March 18, 2001 9:07 PM
> To: Trevor Freeman; David Cross; ietf-pkix@imc.org
> Subject: RE: Logotypes in certificates
> 
> 
> Hi Trevor,
> 
> Thank you for this challenging question. This is a hard one 
> and I will try 
> to answer.
> 
> I think we are into the hen and egg problem.
> I see at least 3 big reasons why most users don't know what a 
> certificate is.
> - PKI hasn't yet reached into the bedroom of normal users.
> - Applications doesn't encourage users to se the certificate 
> content and;
> - If they do, there isn't so much interesting to see anyway 
> because the 
> display interface is normally not very user friendly.
> 
> I simply ask you to look beyond the horizon and try to grasp 
> a glimpse of 
> the future.
> 
> In a mature PKI, when a human user receives a signed message, the 
> applications will probably provide the user with a simple 
> button to view 
> signature details.
> 
> What is then interesting here?
> - Signature algorithm ?
> - Key length ?
> - Or maybe just WHO SIGNED THIS and
> - DO I TRUST THIS SIGNATURE?!
> 
> If the user has just a minor curiosity about who signed this, and who 
> stands behind the identification of this person, what better then to 
> display the signers certificate.
> 
> But I challenge you to display this in a interesting and 
> meaningful way to 
> the user if you cut of the possibility to tie logotypes to 
> the process.
> 
> If you denies this option you are STUCK with a pure text 
> interface, and 
> that won't do. Not if this is to grow out of the technical community.
> 
> At least this is what I see and the response I get from many 
> people I talk 
> to, among them initiated peoples related to European 
> electronic signature 
> legislation and standardization.
> 
> /Stefan
> 
> 
> At 10:42 2001-03-18 -0800, Trevor Freeman wrote:
> >Hi Stefan,
> >The fundamental gap here is that most users don't know what a
> >certificate is, and are happy that they just get a simple icon if
> >everything is ok or not rather than some UI detailing the 
> content of the
> >credential. Most users never look as the certificate UI.
> >Trevor
> >
> >-----Original Message-----
> >From: Stefan Santesson [mailto:stefan@accurata.se]
> >Sent: Saturday, March 17, 2001 4:14 PM
> >To: David Cross; ietf-pkix@imc.org
> >Subject: RE: Logotypes in certificates
> >
> >
> >David,
> >
> >Comment in line;
> >
> >At 18:46 2001-03-16 -0800, David Cross wrote:
> > >Stefan:
> > >
> > >Some comments -
> > >
> > >First:  I do not think that this should be considered for son of
> > >RFC2459
> > >- we do not want to hold this up to consider this proposal.
> >
> >That's OK with me.
> >
> > >
> > >Second:  I do not see how applications will make use of this
> > >information.  How do you see it being used?
> >
> >Well first I would like to state that I now of several 
> applications that
> >
> >would use this information if it was available. This is typically any
> >application which includes a function to display a certificates to a
> >human
> >user. These applications will seek to have a display format 
> which makes
> >sense to the user. These applications can, if logotype data 
> is present,
> >choose to download these logotypes and display them to the 
> user when a
> >certificate is displayed.
> >
> >Applications don't caring about logos won't be effected 
> since they just
> >ignore this information without problem. The logo is only a display
> >function and has no part in any DN or alternative name.
> >
> >We will surely implement this in certificates if this gets to be
> >supported
> >by any standard.
> >
> >/Stefan
> >
> > >
> > >Third:  People are complaining about size of certs now, this will
> > >expand that issue
> >
> >Everything is a tradeoff. In this case we can meet an 
> important business
> >
> >need with just a few bytes. I think this is one of those cases that
> >definitely is worth it.
> >
> >/Stefan
> >
> > >
> > >
> > >David B. Cross
> > >
> > >
> > >         -----Original Message-----
> > >         From: Stefan Santesson [mailto:stefan@accurata.se]
> > >         Sent: Thursday, March 15, 2001 3:22 PM
> > >         To: ietf-pkix@imc.org
> > >         Subject: Logotypes in certificates
> > >
> > >
> > >         In last PKIX meeting in San Diego I presented 
> some thoughts on
> >
> > >creating a new extension for inclusion of logotype information in
> > >certificates.
> > >
> > >         Last in this mail I include a primary suggested 
> outline for
> > >such extension.
> > >
> > >         But first a short summary of the rationale:
> > >
> > >         At a first glance it may seem irrelevant to 
> include logotype
> > >information in certificates and a natural first reaction 
> is "OH NO...
> > >NOT ANOTHER THING TO INCLUDE!! DON'T WE HAVE ENOUGH?!!!"
> > >
> > >         The fact is though that at the ETSI meeting this 
> week (In the
> > >group that handles European standards related to electronic
> > >signatures). IT WAS GENERALLY RECOGNIZED THAT INCLUSION OF LOGOTYPE
> > >DATA WOULD BE VERY USEFUL.
> > >
> > >         Why is that so?
> > >
> > >         The answer is that logotypes are carriers of trust and are
> > >widely recognized tools for trust recognition. Have you 
> ever thought
> > >why EVERY physical instrument of trust, from loyalty cards, credit
> > >cards to Passports, contain trust symbols in the form of logotypes.
> > >
> > >         Are certificates different? ABSOLUTELY NOT!!
> > >
> > >         If PKI is to take off in the private market, the 
> certificates
> > >must be user friendly and carry the same functionality (in 
> electronic
> > >form) as ID-cards, passports and other physical ID:s do in physical
> > >form. And logotypes are a FUNDAMENTAL part of that.
> > >
> > >         Without logotypes, certificates can only be handled and
> > >presented as textual information for technically oriented 
> users. This
> > >is the reality I see.
> > >
> > >         What is your observation?
> > >
> > >         How can we then do this?
> > >
> > >         Technically speaking, we don't have to include the actual
> > >logotype image and we don't have to destroy legacy applications.
> > >         I would suggest that we use the same mechanism that we
> > >specified for biometric data in RFC 3039 where a 
> non-critical extension
> >
> > >can include for each logotype:
> > >
> > >         -  type of logo
> > >         -  type of hash algorithm
> > >         -  hash of logotype data
> > >         -  URI to location of data
> > >
> > >         This will only take a few bytes but will allow new
> > >applications to import relevant logotypes, signed by the 
> issuer of the
> > >certificate, to be displayed to the user.
> > >
> > >         So... What to do with this?
> > >
> > >         If this is to be proceeded at all, It could be 
> part of son of
> > >RFC 2459, it could be part of a new RFC 3039 and it could be a new
> > >draft or merged with some other work. I'm open for suggestions.
> > >
> > >         I hope to be able to meet with many of you and 
> discuss this in
> >
> > >Minneapolis next week.
> > >
> > >         /Stefan Santesson
> > >
> > >
> > >         logotypeInfo  EXTENSION ::= {
> > >                   SYNTAX             LogotypeSyntax
> > >                   IDENTIFIED BY      id-pe-logotypeInfo }
> > >
> > >               id-pe-logotypeInfo OBJECT IDENTIFIER  ::= {id-pe XX}
> > >
> > >               LogotypeSyntax ::= SEQUENCE OF LogotypeData
> > >
> > >               LogotypeData ::= SEQUENCE {
> > >                   typeOfLogotype       TypeOflogotype,
> > >                   hashAlgorithm        AlgorithmIdentifier,
> > >                   logotypeDataHash     OCTET STRING,
> > >                   sourceDataUri        IA5String OPTIONAL }
> > >
> > >               TypeOflogotype ::= CHOICE {
> > >                   predefinedLogotypeType    
> PredefinedLogotypeType,
> > >                   LogotypeTypeID            OBJECT IDENTIFIER }
> > >
> > >               PredefinedLogotypeType ::= INTEGER {
> > >                   subject-organization-logotype(0),
> > >                   issuer-organization-logotype(1)
> > >                   CA-network-logotype(2)}
> > >                   (subject-organization-logotype|
> > >                    issuer-organization-logotype|
> > >                     CA-network-logotype,...)
> > >
> > >
> > >         The predefined logotype types are
> > >
> > >         subject-organization-logotype, if used, SHALL be used to
> > >include a logotype of the subject organization. The 
> logotype SHALL be
> > >consistent with, and require the presence of, an organization name
> > >stored in the organization attribute in the subject field.
> > >
> > >         issuer-organization-logotype, if used, SHALL be used to
> > >include a logotype of the issuer organization. The 
> logotype SHALL be
> > >consistent with, and require the presence of, an organization name
> > >stored in the organization attribute in the issuer field.
> > >
> > >         CA-network-logotype, if used, SHALL be used to include a
> > >logotype used by a network of CA services, provided by one 
> or several
> > >independent CA's, within which the issuer claims to issue this
> > >certificate.
> > >
> > >
>