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.
- RE: Logotypes in certificates David Cross
- RE: Logotypes in certificates Michael Zolotarev
- Re: Logotypes in certificates Anders Rundgren
- RE: Logotypes in certificates David Cross
- RE: Logotypes in certificates Stefan Santesson
- RE: Logotypes in certificates Stefan Santesson
- Re: Logotypes in certificates Rich Salz
- RE: Logotypes in certificates Trevor Freeman
- RE: Logotypes in certificates Trevor Freeman
- RE: Logotypes in certificates Ambarish Malpani
- RE: Logotypes in certificates Trevor Freeman
- RE: Logotypes in certificates Michael Zolotarev
- Re: Logotypes in certificates Eric Murray
- RE: Logotypes in certificates Stefan Santesson
- RE: Logotypes in certificates Michael Myers
- Re: Logotypes in certificates Stefan Santesson
- RE: Logotypes in certificates Stephen Kent
- RE: Logotypes in certificates Andrew Hoag
- Re: Logotypes in certificates Dean Povey
- Re: Logotypes in certificates Dean Povey
- RE: Logotypes in certificates Tim Moses
- RE: Logotypes in certificates todd.glassey
- RE: Logotypes in certificates Stefan Santesson
- RE: Logotypes in certificates Stephen Kent
- RE: Logotypes in certificates Stefan Santesson
- Re: Logotypes in certificates Dean Povey
- Re: Logotypes in certificates Stephen Kent
- RE: Logotypes in certificates Ambarish Malpani
- RE: Logotypes in certificates Tom Gindin
- RE: Logotypes in certificates Michael Zolotarev
- Re: Logotypes in certificates Terry Hayes
- RE: Logotypes in certificates Peter Gutmann
- RE: Logotypes in certificates Hal Lockhart
- RE: Logotypes in certificates Stephen Kent
- RE: Logotypes in certificates Stephen Kent
- RE: Logotypes in certificates Stephen Kent
- RE: Logotypes in certificates David Cross
- RE: Logotypes in certificates Stefan Santesson
- RE: Logotypes in certificates Michael Zolotarev
- RE: Logotypes in certificates todd.glassey
- RE: Logotypes in certificates Trevor Freeman
- RE: Logotypes in certificates Russ Housley
- Re: Logotypes in certificates Dean Povey
- RE: Logotypes in certificates Michael Zolotarev
- RE: Logotypes in certificates Manger, James H
- RE: Logotypes in certificates Stephen Kent
- Re: Logotypes in certificates David P. Kemp
- Re: Logotypes in certificates Michael Ströder
- Re: Logotypes in certificates Dean Povey
- Re: Logotypes in certificates Michael Ströder
- Re: Logotypes in certificates Dean Povey
- Re: Logotypes in certificates Michael Ströder
- Re: Logotypes in certificates Stefan Santesson
- RE: Logotypes in certificates Bob Jueneman
- RE: Logotypes in certificates Stefan Santesson
- RE: Logotypes in certificates todd.glassey
- RE: Logotypes in certificates Stephen Kent
- Re: Logotypes in certificates Anders Rundgren
- RE: Logotypes in certificates Stefan Santesson