RE: Logotypes in certificates

"David Cross" <dcross@microsoft.com> Sat, 17 March 2001 02:47 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 VAA18428 for <pkix-archive@odin.ietf.org>; Fri, 16 Mar 2001 21:47:38 -0500 (EST)
Received: from localhost (daemon@localhost) by above.proper.com (8.9.3/8.9.3) with SMTP id SAA00812; Fri, 16 Mar 2001 18:47:04 -0800 (PST)
Received: by mail.imc.org (bulk_mailer v1.12); Fri, 16 Mar 2001 18:46:54 -0800
Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by above.proper.com (8.9.3/8.9.3) with SMTP id SAA00781 for <ietf-pkix@imc.org>; Fri, 16 Mar 2001 18:46:53 -0800 (PST)
Received: from 157.54.9.101 by mail2.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 16 Mar 2001 18:46:27 -0800 (Pacific Standard Time)
Received: from red-msg-02.redmond.corp.microsoft.com ([157.54.12.70]) by inet-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.1600); Fri, 16 Mar 2001 18:43:10 -0800
x-mimeole: Produced By Microsoft Exchange V6.0.4418.65
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: Logotypes in certificates
Date: Fri, 16 Mar 2001 18:46:26 -0800
Message-ID: <24A715275661C8428C00432EFCA5CB7C01A336F7@red-msg-02.redmond.corp.microsoft.com>
Thread-Topic: Logotypes in certificates
Thread-Index: AcCtp3+U+Sn5JIstTJWznd2HR/+X5AA4+ceA
From: David Cross <dcross@microsoft.com>
To: Stefan Santesson <stefan@accurata.se>, ietf-pkix@imc.org
X-OriginalArrivalTime: 17 Mar 2001 02:43:10.0326 (UTC) FILETIME=[01163160:01C0AE8C]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id SAA00782
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
Content-Transfer-Encoding: 8bit

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.
 
Second:  I do not see how applications will make use of this
information.  How do you see it being used?
 
Third:  People are complaining about size of certs now, this will expand
that issue
 

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.