RE: Logotypes in certificates

Michael Zolotarev <michael.zolotarev@baltimore.com> Sun, 18 March 2001 23:46 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 SAA12213 for <pkix-archive@odin.ietf.org>; Sun, 18 Mar 2001 18:46:20 -0500 (EST)
Received: from localhost (daemon@localhost) by above.proper.com (8.9.3/8.9.3) with SMTP id PAA14469; Sun, 18 Mar 2001 15:45:43 -0800 (PST)
Received: by mail.imc.org (bulk_mailer v1.12); Sun, 18 Mar 2001 15:45:36 -0800
Received: from stargate.zergo.com.au (IDENT:root@stargate.zergo.com.au [203.2.208.130]) by above.proper.com (8.9.3/8.9.3) with ESMTP id PAA14418 for <ietf-pkix@imc.org>; Sun, 18 Mar 2001 15:45:30 -0800 (PST)
Received: from sweepau.baltimore.com.au (sweepau.zergo.com.au [10.61.2.6]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id JAA06475 for <ietf-pkix@imc.org>; Mon, 19 Mar 2001 09:54:52 +1100
Received: from sydneymail1.zergo.com.au (unverified) by sweepau.baltimore.com.au (Content Technologies SMTPRS 4.2.1) with ESMTP id <T5262e937d90a3d02061aa@sweepau.baltimore.com.au>; Mon, 19 Mar 2001 10:46:09 +1100
Received: by sydneymail1.zergo.com.au with Internet Mail Service (5.5.2650.21) id <HAVTGKDJ>; Mon, 19 Mar 2001 10:43:31 +1100
Message-ID: <D44EACB40164D311BEF00090274EDCCA1E7404@sydneymail1.zergo.com.au>
From: Michael Zolotarev <michael.zolotarev@baltimore.com>
To: 'Trevor Freeman' <trevorf@Exchange.Microsoft.com>, Ambarish Malpani <ambarish@valicert.com>, Stefan Santesson <stefan@accurata.se>, David Cross <dcross@microsoft.com>
Cc: ietf-pkix@imc.org
Subject: RE: Logotypes in certificates
Date: Mon, 19 Mar 2001 10:43:25 +1100
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

Time for a compromise?
Define an OID for a signed(!) logotype and keep it in LDAP together with a
cert. Whoever can retrieve the cert, can fetch the logotype as well. The
content of the cert does not have to be affected.
Leave the rest of exotic cases (i.e. there is no LDAP) to be sorted out on a
one-by-one base, if a real requirement ever shapes up.

M

-----Original Message-----
From: Trevor Freeman [mailto:trevorf@Exchange.Microsoft.com]
Sent: Monday, March 19, 2001 9:38 AM
To: Ambarish Malpani; Stefan Santesson; David Cross
Cc: ietf-pkix@imc.org
Subject: RE: Logotypes in certificates


Hi Ambarish,
Well this is software, and anything is possible! However you are now
suggesting that users will benefit from a second icon on there toolbar
in addition to the icon which denotes an SSL protected session. When in
reality users only just about understand what the existing icon means
and don't understand how, and what trusted or not trusted constitutes in
the CA world. 
Trevor

-----Original Message-----
From: Ambarish Malpani [mailto:ambarish@valicert.com] 
Sent: Sunday, March 18, 2001 11:38 AM
To: Trevor Freeman; Stefan Santesson; David Cross; ietf-pkix@imc.org
Subject: RE: Logotypes in certificates



Hi Trevor,
    Isn't it possible that IE/Communicator show the logo next to the
lock symbol when displaying securely downloaded pages? Doesn't require
the user to do something different and let's you associate the site with
a logo that you are familiar with.

Might help with the kinds of attacks where people try to send you to
paypai.com rather than paypal.com

Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  ambarish@valicert.com
339 N. Bernardo Ave.                          http://www.valicert.com
Mountain View, CA 94043


> -----Original Message-----
> From: Trevor Freeman [mailto:trevorf@Exchange.Microsoft.com]
> Sent: Sunday, March 18, 2001 10:42 AM
> To: Stefan Santesson; David Cross; ietf-pkix@imc.org
> Subject: RE: Logotypes in certificates
> 
> 
> 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.
> >
> >
> 


This footnote confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.


-----------------------------------------------------------------------------------------------------------------
The information contained in this message is confidential and is intended 
for the addressee(s) only.  If you have received this message in error or 
there are any problems please notify the originator immediately.  The 
unauthorized use, disclosure, copying or alteration of this message is 
strictly forbidden. Baltimore Technologies plc will not be liable for direct, 
special, indirect or consequential damages arising from alteration of the 
contents of this message by a third party or as a result of any virus being 
passed on.

In addition, certain Marketing collateral may be added from time to time to 
promote Baltimore Technologies products, services, Global e-Security or 
appearance at trade shows and conferences.
 
This footnote confirms that this email message has been swept by 
Baltimore MIMEsweeper for Content Security threats, including
computer viruses.