Subject: RE: Logotypes in certificates

From: Michael Zolotarev <[email-masked]>
Date: Sat, 17 Mar 2001 14:09:07 +1100

Probably a better alternative to including a logotype into a certificate
would be to include a reference to a [signed] logotype. As an extension,
containing a uri of a logotype which is stored somewhere. The drawback is
that it requires the verifier to be connected, obviously. But certificate
verification normally assumes that you are connected. The size of a logotype
won't matter much.

Naturally, a logotype should be signed by the same entity which issued the
certificate which contains the reference to the logotype. it also allows
flexible update of logotype if necessary, should a change be made within
validity period of the certificate (i.e. a new photo required because I've
grown a bead).

Michael

> -----Original Message-----
> From: David Cross [mailto:[email-masked]]
> Sent: Saturday, 17 March 2001 13:46
> To: Stefan Santesson; [email-masked]
> Subject: RE: Logotypes in certificates
> 
> 
> 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:[email-masked]] 
> 	Sent: Thursday, March 15, 2001 3:22 PM
> 	To: [email-masked]
> 	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.

---

From: "David Cross" <[email-masked]>
Date: Sat, 17 Mar 2001 13:11:42 -0800

Sounds like a reasonable suggestion.  Still, I would not want this in
son-of-RFC2459.

David B. Cross

-----Original Message-----
From: Michael Zolotarev [mailto:[email-masked]] 
Sent: Friday, March 16, 2001 7:09 PM
To: David Cross; Stefan Santesson; [email-masked]
Subject: RE: Logotypes in certificates

Probably a better alternative to including a logotype into a certificate
would be to include a reference to a [signed] logotype. As an extension,
containing a uri of a logotype which is stored somewhere. The drawback
is that it requires the verifier to be connected, obviously. But
certificate verification normally assumes that you are connected. The
size of a logotype won't matter much.

Naturally, a logotype should be signed by the same entity which issued
the certificate which contains the reference to the logotype. it also
allows flexible update of logotype if necessary, should a change be made
within validity period of the certificate (i.e. a new photo required
because I've grown a bead).

Michael

---

From: Stefan Santesson <[email-masked]>
Date: Sun, 18 Mar 2001 01:13:43 +0100

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

That's OK with me.

>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

>group that handles European standards related to electronic signatures).
>widely recognized tools for trust recognition. Have you ever thought why
>EVERY physical instrument of trust, from loyalty cards, credit cards to
>presented as textual information for technically oriented users. This is
>the reality I see.
>
>RFC 2459, it could be part of a new RFC 3039 and it could be a new draft
>a logotype of the subject organization. The logotype SHALL be consistent
>a logotype of the issuer organization. The logotype SHALL be consistent

---

From: Ambarish Malpani <[email-masked]>
Date: Sun, 18 Mar 2001 11:37:41 -0800

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.                                  [email-masked]
339 N. Bernardo Ave.                          http://www.valicert.com
Mountain View, CA 94043

> From: Trevor Freeman [mailto:[email-masked]]
> Sent: Sunday, March 18, 2001 10:42 AM
> To: Stefan Santesson; David Cross; [email-masked]
> 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
> 
> Sent: Saturday, March 17, 2001 4:14 PM
> To: David Cross; [email-masked]
> >Third:  People are complaining about size of certs now, this will 
> >expand that issue
> 
> >         Last in this mail I include a primary suggested outline for 
> >such extension.
> >
> >signatures). IT WAS GENERALLY RECOGNIZED THAT INCLUSION OF LOGOTYPE 
> >DATA WOULD BE VERY USEFUL.
> >
> >         Why is that so?
> >
> >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.
> >
> users. This 
> >is the reality I see.
> >         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
> >         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.
> >
> >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.
> >
> >         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.
> >

---

From: "Trevor Freeman" <[email-masked]>
Date: Sun, 18 Mar 2001 14:38:02 -0800

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:[email-masked]] 
Sent: Sunday, March 18, 2001 11:38 AM
To: Trevor Freeman; Stefan Santesson; David Cross; [email-masked]
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

> everything is ok or not rather than some UI detailing the content of 
> the credential. Most users never look as the certificate UI.
> Trevor
> 
> We will surely implement this in certificates if this gets to be 
> supported by any standard.
> 
> /Stefan
> 
> >

---

From: Michael Zolotarev <[email-masked]>
Date: Mon, 19 Mar 2001 10:43:25 +1100

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:[email-masked]]
Sent: Monday, March 19, 2001 9:38 AM
To: Ambarish Malpani; Stefan Santesson; David Cross
Cc: [email-masked]
Subject: RE: Logotypes in certificates

Hi Ambarish,

-----Original Message-----
From: Ambarish Malpani [mailto:[email-masked]] 
Sent: Sunday, March 18, 2001 11:38 AM
To: Trevor Freeman; Stefan Santesson; David Cross; [email-masked]
Subject: RE: Logotypes in certificates

Hi Trevor,

Regards,
Ambarish

---

From: Andrew Hoag <[email-masked]>
Date: Mon, 19 Mar 2001 15:12:52 -0800

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

> Sent: Sunday, March 18, 2001 9:07 PM
> To: Trevor Freeman; David Cross; [email-masked]
> 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,
> > >include a logotype of the subject organization. The 
> logotype SHALL be

---

From: [email-masked]
Date: Tue, 20 Mar 2001 15:20:14 +0000

--
Regards,
Todd
> Colleagues - I am supportive of the idea of including branding information
> in certificates.  I recognize Steve's concern.  But, I suggest that there
> should be no impact on processing rules ... other than ... in applications
> where the relying party is a human, the logo from the very first certificate
> in the path should be displayed to him/her.  When a relying party accepts a
> trust anchor, their experience should be identical regardless of the details
> of the remainder of the path.  Best regards.  Tim.

This this is an instance wherein you are talking about 
is the end-use model for the cert and not the cert 
content. It is important to differentiate the two 
since use of a cert is more an applications level effort.

The concept in "displaying" squat to anyone takes the 
issue out of the "content" and into the "use of" realms
which seems to be more "application oriented" than ANYTHING,
and as such not something that PKIX should be 
concerning itself with unless it is going to change again
and start to publish certified use models for its wares.

In which case the structure and accountability of PKIX for 
what it is producing must also change significantly more 
towards the ISO standards I think.

> From: Stephen Kent [mailto:[email-masked]]
> Sent: Monday, March 19, 2001 11:47 AM
> To: Stefan Santesson
> Cc: [email-masked]
> Stefan,
> I have mixed feelings about this proposal. We have, in the 
> NameConstraints extension, a powerful mechanism for making cross 
> certification a safe thing to do. If one were to include a logotype 
> extension in a cert that was issued by a CA who had been cross 
> certified using name constraints, it holds the potential for 
> seriously undermining the controls imposed by NameConstraints.
> 
> There is an issue here that merits discussion: the logotype is 
> presumably useful only when people are being asked to accept/reject 
> certs, in addition to or in lieu of the many software-based controls 
> that v3 certs offer. If the use is in lieu of use of more extensive 
> software-based controls, there may not be a conflict, since the 
> context is probably that of a TTP CA where NameConstraints and 
> similar controls are of minimal use. However, if the syntactic 
> controls are also in use, a logotype extension may be of limited 
> value and might easily degrade security.
> 
> So, I would be opposed to PKIX approving this sort of extension (even 
> as a separate RFC from 2459bis) without imposing significant 
> constraints on the contexts in which it is to be used, including 
> limitations on its use in conjunction with other extensions, e.g., 
> NameConstraints. What worries me even more, is that we might have to 
> extend/modify the validation procedure to enforce such 
> inter-extension constraints, which would then affect 2459bis!
> 
> Steve

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 20 Mar 2001 16:44:11 +0100

Todd,

I may have misunderstood you but the proposal to include logotype 
information is definitely about certificate content.

The proposal suggests a method to contain relevant information about 
logotypes in certificates in a way that allows a client to get, validate 
and display the logo to an end user.

How the client does that is not the major issue, just to provide the 
possibility.

/Stefan

---

From: [email-masked] (Peter Gutmann)
Date: Thu, 22 Mar 2001 05:56:23 (NZST)

"Tom Gindin" <[email-masked]> writes:

>Wouldn't Logotypes most easily be implemented as an OTHER-NAME within one of
>the alternate name fields (probably SubjectAltName)?  If so, how would they
>affect NameConstraints and the like?  IMHO, they would have little effect on
>them since logos are not hierarchical names and thus couldn't easily be
>governed by NameConstraints.

That sounds like a sensible way to do it, if your cert is issued by (say) VISA
then they'll put the VISA logo in the issuer's other-name.  I used an other-
name for the MPEG-of-cat cert I created a few years back and both MSIE/Windows
and Netscape accepted it (meaning they didn't reject the cert or crash) so it
looks like a fairly clean way to do it.

Peter.

---

From: Hal Lockhart <[email-masked]>
Date: Wed, 21 Mar 2001 14:26:47 -0500

I'm confused. I thought the proposal was to allow a logotype that
corresponds to the Subject not the Issuer.

Hal

> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, March 22, 2001 12:56 AM
> To: [email-masked]
> Cc: [email-masked]

---

From: "David Cross" <[email-masked]>
Date: Wed, 21 Mar 2001 18:53:59 -0800

Steve:

-->No, the argument is not the same.  We have the nameConstraints 
extension as a technical means of preventing a CA and subordinate CAs 
from issuing certs with names outside of a well defined range. We do 
not have a means to enforce similar controls re logos. That's the 
whole point of my concern.

I agree this is a valid concern and should be addressed before moving
forward.
 
David B. Cross

---

From: Michael Zolotarev <[email-masked]>
Date: Fri, 23 Mar 2001 05:56:12 +1100

Now I'm really confused.

The whole problem is, as Stephen has neatly put it, that "the whole purpose
of including a displayable logo is precisely an attempt by a CA to gain the
trust of users".

A CA requires to gain trust of a user if it is not still trusted
(obviously). Which is the case when a path construction 
(not validation!) ended up at some self-signed CA which is not among the
user's trusted roots set. This is the only case I can think of when a
decision is to be made by the user, i.e. whether to trust that CA or not. 

I cannot think of any other situation when a CA would require to "gain the
trust of users".

If so, then the scope of analysis of logotype's impact is limited to path
construction, not to path validation. Because, again, validation begins when
the trust is already defined, and it is to late for the user to intervene. 

Path validation algorithm is 'silent', it does not need to present anything
to the user. Therefore, presence of a logotype cannot possible affect the
result of the validation, as the user is not asked about anything, or
presented anything, at that stage.

Consiquently, I'm failing to understand how path validation parameters and
constrains can be affected by the logotypes.

I guess there may be something fundamental I'm missing...

Regards
Michael

-----Original Message-----
From: Stefan Santesson [mailto:[email-masked]]
Sent: Friday, March 23, 2001 4:56 AM
To: Stephen Kent; Michael Zolotarev
Cc: [email-masked]
Subject: RE: Logotypes in certificates

Steve,

There was a suggestion during a dinner yesterday that logotypes actually 
could be provided as a policy qualifier. That would actually solve your 
problem since you could directly tie acceptance of logotypes in 
certificates to a particular policy.

This enables you to control the path validation problem with the use of 
policy constraints.

/Stefan

At 18:21 2001-03-21 -0500, Stephen Kent wrote:
>Michael,
>
>>Though I don't favor including logotype or reference to a logotype to a
>>cert, considering it as a pure marketing trick (sorry, Stefan :), but my
>>realisation was that a logotype is by no means related to the
establishment
>>of trust. It is 100% meant for a human eye only, and verification
algorithm
>>should simply ignore it, as it ingores any other proprietory extentions.
If
>>the verification comes up with an answer 'not validated', and the software
>>prompts a user saying 'couldn't validate', and the user still makes a
>>decision to trust the cert, it is an application's problem, which already
>>exists now, and logotypes add no extra pitch to it.
>
>I think the whole purpose of including a displayable logo is precisely an 
>attempt by a CA to gain the trust of users, so I disagree with your 
>stating point. The concern I raised is not one that is addressed by your 
>example, i.e., my example of a "bad outcome" is a cert that carries a logo 
>which will be recognized by a user and thus will engender the user's 
>confidence, but it is contained in a cert that, while valid under our path 
>validation controls, has nothing to do with the entity whose logo appears 
>in the cert and which is displayed to the user.
>
>>As an extreme, if a CA considers logotypes to be anyhow harmful, it simply
>>won't have a logotype in its own cert, and refuse certification of
>>logotypes.
>
>As a CA I can refuse to certify a logo-equipped cert one layer down, but 
>not farther, unless we adopt a means of representing the logo that is 
>subject to existing controls. Tom suggested on possible means, if we put 
>the logo in an altname field and make it a type which can be prohibited 
>using nameConstraints.
>
>Steve

---

From: [email-masked]
Date: Thu, 22 Mar 2001 19:48:03 +0000

As I have said a number of times already, there is no use
between machines for the Logo as part of the cert. 

This is purely for human's that might want to look at a
redition of the cert in a paper-like framework, which BTW
is essentially a per-use type of decision and not ANYTHIG
having to do with the negotiability or negotiations
process of the cert itself.

As Mssr. Kemp has pointed out as well, let the
application, if it needs to, deal with displaying a Logo
as part of its opeations.

If this presists as a topic of conversation then I would
suggest that a formal specification for the "CertViewer"
is needed as part of this same scheme so that the Logo's
will render and look the same everywhere otherwise the
logo and its intended use is pointless and the fact that
it is "potentially different" on a number of platforms
will lesson the value and increase the potential
confusion factor for the use of these additions.

--
Regards,
Todd

---

From: Michael Zolotarev <[email-masked]>
Date: Fri, 23 Mar 2001 10:15:29 +1100

I agree with Todd that once we touch the slippery path of using graphical
images as a formal constituent of trust establishement, the problem will
become a far more exotic one than defining a set of rules for verification
algorithm.

I feel that there is no common understanding of the logotype's intended
purpose (purpose, not handling!), and therefore the arguments are making
rounds. Following are the points which require clarification, in order to be
certain what use scenario we are talking about:

1 Logotypes are allowed in (to be referenced from) EE PKC:
1.1 Logotypes in EE PKC are there for 'informational use only'. They are not
part of the Subject's name, in whatever form. They must be ignored by
validation process. Identity with a logotype is no different from the same
identity less logotype.

1.2 Logotype in EE PKC is a valid component of the Subject's identity.
Identity with a logotype is different from the same identity less logotype.
A single PK cannot be bound to the two identities.

2 Logotypes are allowed to be referenced from CA certificates.
2.1 Logotypes are only allowed in self-signed CA certificates.

My original understanding of the proposal was 1.1-yes, 1.2-no, 2-yes,
2.1-no.

This way, logotypes have a simple purpose of branding and pleasing humal
eyes. No trust. I can reference a logotype url from my certificate, and
later remove the logotype (so that the url becomes a dead one). It should
not affect the acceptance of my certificate by formal validation procedures.

(I'm not saying that branding and eyes pleasure justify the troubles :)

Michael

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, March 23, 2001 6:48 AM
To: Michael Zolotarev
Cc: 'Stefan Santesson'; Stephen Kent; Michael Zolotarev;
[email-masked]

--
Regards,
Todd

> MIMEsweeper for the presence of computer viruses.
----------------------------------------------------------------------------
----
> ---------------------------------

---

From: "Bob Jueneman" <[email-masked]>
Date: Fri, 30 Mar 2001 17:53:33 -0700

I've been behind on my e-mail or I would have jumped 
into this discussion much earlier, for I think that Stefan 
is dead on, and it isn't just about branding.

I proposed including logos in certificates about three or 
four years ago or longer, due to one overwhelming problem
when it comes to human acceptance of certificates,
and that is the issue of multiple language support and
non-ASCII characters.

I don't know about anyone else, but my Russian is extremely
rusty, and I can barely read the alphabet. I don't speak or
read Greek, but I can at least read the alphabet.

Now, if someone sends me a certificate with a name in 
Japanese, Chinese, Hebrew, Arabic, Sanscrit, Thai,
or Klingon -- arbitrary Unicode characters, if you
will --  what I am supposed to do with it? I can't even read 
the characters well enough to do a visual comparison
for equality.

And it gets worse when you consider the issue of "right to
use" names, particularly in some of the Asian countries where 
the CAs are closely tied to the government -- they will 
insist on the native language of that country being
used.

Yes, you could put either an English translation or
transliteration in an alternate subject name, but those 
names probably aren't in any sense official, and 
there are therefore significant right to use issues.
When you translate from the Cyrillic, should the name
be "Krasny Izvestia" , or "Red Star"?  Likewise
there are the "Peking" vs. "Beijing" issues, etc.
To us these issues seem be relatively unimportant, but
wars have been fought  over such linguistic matters.

My options would therefore seem to be:

1. Accept everything that comes from VeriSign, etc.,
whether I can read the entity's name or not.

2. Reject everything that comes from VeriSign, etc.,
whether I can read the entity's name or not, and
especially if I can't -- make everyone speak English! :-)

3. Participate only in closed user groups where
the decisions as to whether I should accept a
certificate are taken out of my hands and are
enforced by my MIS organization or higher-ups.

None of these are acceptable, in my opinion.

But if I put a logo in the certificate, in all likelihood
that logo is a trademark that is vigorously defended
and may be recognized worldwide.

Yes, the CAs will have to worry about trademark right 
to use issues, but in fact those issues are well understood
from a legal perspective, and certainly under better 
control than the slippery issue of right-to-use for DNS names.

I don't have an opinion yet as to issues of precisely how
such information should be encoded, and/or whether
name subordination ought to apply, but I think there is
a strong justification for the ability to include a logo
in a certificate.

Off the top of my head, I believe it ought to be possible to
associate a logo with both Subject and Issuer, and
I absolutely agree with Russ -- a policy OID or constraint
would be an absolutely terrible place to put it, except perhaps
as a seal of approval or qualification mark for a closed 
user group or association.

Bob

Robert R. Jueneman
Security Architect

Novell, Inc -- the leading provider of Net services software