Subject: RE: Logotypes in certificates

From: "Trevor Freeman" <[email-masked]>
Date: Sun, 18 Mar 2001 10:42:12 -0800

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:[email-masked]] 
Sent: Saturday, March 17, 2001 4:14 PM
To: David Cross; [email-masked]
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:[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.
>
>

---

From: Eric Murray <[email-masked]>
Date: Sun, 18 Mar 2001 16:07:44 -0800

> credential. Most users never look as the certificate UI.

Agreed.

I don't think that the logo extension would add that much data to the
cert.  There's already a whole load of junk people can put in certs,
what's another 1-200 bytes?

I am however concerned with how certs with the logo extension
would be issued.

Evil Trent is setting up a site to spoof the Bank of Alice web site.
Since Trent knows that the BofA customers all use the logo extension
to verify that they're really connected to Alice, he spoofs
the logo.  Trent creates a logo which is very similar to the BofA
logo, but with one pixel in the corner different.

When Trent goes to Verisign, do they check the logo before they sign
the cert?  How much do they check it- that it's hash is different from
all the other logos in their database?  If that's the case, Trent's
visually-identical logo is "different" and Trent gets his cert.

Trent puts up his spoof site, redirects traffic to it, and cleans out a
number of accounts.  Eventually Alice will find out that Trent is using a
logo that's too similar to Alice's.  There's already laws for this sort
of thing, so Alice can eventually prevail in the courts and get Trent
to stop using the confusing logo.  Before that happens, Trent moves to
some small country with weak extradition laws.

With DNs this is simple(er)- Verisign just won't sign a cert request
from Trent that says it's from Alice.  Of course "says it's from Alice"
is interpreted different by different CAs and to be 100% correct
you have to know each CA's naming convention.  But generally it's not
possible to get a Subject DN that's close enough to an existing issued
cert to spoof it.

How would this be handled with logos?  There's a body of law for
similarity of logos and trademarks, would that be followed?  Or would
someone at Verisign (or pick any CA) just look at the logos and reject any
that're "too similar".  There's probably also an international law problem
here- what if I get a cert issued with my logo, which is trademarked
in the US, and there's another very similar logo trademarked in the UK
for an entirely unrelated company?  Normally I and the other company
would not be competing in each other's territories, but now with the
net, we are, and our logos clash.  Who figures this out?  This problem
sounds very similar to the domain name situation, which as we all know,
is a bit of a mess.

I think that these issues (and probably more in the same vein)
should be thought through before going ahead with this.

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 19 Mar 2001 06:06:49 +0100

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

---

From: "Michael Myers" <[email-masked]>
Date: Sun, 18 Mar 2001 21:27:03 -0800

In my opinion, this issue is better addressed in a more industry-focused
forum.

Mike

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 19 Mar 2001 06:45:23 +0100

Hi Eric,

Thank you for interesting thoughts. Yes this is a challenging subject.

Let me first ask you to consider the case if we didn't use handwritten 
signatures today. Imagine that I now suggested that we start using a method 
to close contracts and deals where involved parties freely chooses any 
personal written symbol and let that represent them and their acceptance of 
a contract.

Can you imagine what philosophic debates that would cause? How easy it 
would be to forge and how hard it will be to prove who really signed a 
document!!! Pretty much the kind of challenges you just raised with respect 
to logotypes.

Identification and naming are not exact science. It is just like signatures 
- It is a phenomena which has evolved over long periods of times as it has 
proved its value despite its imperfection.

What we try to do with certificates is not to make this world more perfect, 
but to REFLECT that world and DOCUMENT the processes that makes up the 
fundament of trust in our lives and societies.

You can fool any PKI structure if you don't require the CA to 1) Be trusted 
and 2) prove that trustworthiness by being signed by a trusted ROOT CA.

Given that, we don't ask any CA to do more than to INVESTIGATE and DOCUMENT 
what it already out there, I don't see the problem. Personally I see no 
problem for a CA to validate a logotype of an organization since what a CA 
does is merely to identify the organization and then document what that 
legal entity CLAIMS to be its logotype.

If that claim is wrong, then there is legal ways to deal with that.

International conflicts of logos are there with or without certificates.

Logos are NOT replacements of DN:s and names of any kind, they are just 
complementing concepts of symbols developed over long period of time, 
proven valuable to the society as a carrier of trust, despite its imperfection.

/Stefan

---

From: Stephen Kent <[email-masked]>
Date: Mon, 19 Mar 2001 11:46:46 -0500

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: Dean Povey <[email-masked]>
Date: Tue, 20 Mar 2001 10:04:51 +1000

>value and might easily degrade security.

The following paper motivates the need for an extension similar to that 
proposed and shows a basic attack on SSL using a web browser that having
logos/visual cues in certificates helps mitigate.

A. Jøsang, I.G. Pedersen and D. Povey. PKI seeks a trusting relationship.
In Proceedings of the Fifth Australasian Conference on Information Security and
Privacy (ACISP 2000), Brisbane, July 2000. Springer. 
http://security.dstc.edu.au/papers/pkitrust.pdf

The basic idea is this:

1. The user is fooled into connecting to the attacker using a false URL 
   on a portal or by some other means (a sophisticated attack could 
   intercept the request and use HTTP redirects on unsecured HTTP leading
   to get them to connect to the attacker's web server.

2. The attacker's web page masquerades as a legitimate business.  They 
   could do this by simply replicating a target site's web page.  They then
   present a service to buy goods or perform some transaction using an
   SSL secure connection.

3. The user connects to the secure connection, accepts the SSL certificate
   and then submits their credit card details/bank account 
   PIN to the attacker.

Note that this attack will only work if:

  1. The user doesn't realise that the URL of the site they are connecting
     to is the wrong one for the legitimate business.  In practice this 
     will probably be true even if the attacker takes no steps to hide or
     mask this fact.  However the attacker can easily register domain names
     that could plausibly represent the target site (e.g. for Bank Of America 
     which of the following is correct: www.bankofamerica.com, www.bom.com,
     bom.commerce.net, www.bankofamerica.us, www.bankofamerica.tv etc.).
     Presumably most CAs will issue you an SSL server cert if you can prove
     ownership of the domain.

  2. The user doesn't bother to check the details of the Certificate. Note this 
     involves some effort and knowledge on behalf of the user, most users
     would just see the little lock icon and happily enter their details.

The problem is caused by lack of feedback from the security mechanism about
the trust aspects of the transaction.  While the browser goes to a lot of
trouble to verify the cryptographic aspects of the SSL connection, the link
between the authentication and the actual organisation the user thinks they
are contacting is quite tenuous.

Adding some sort of visual identifier, such as a company logo to a
certificate and displaying this in a prominent place in the browser would
go a long way to ameliorating this problem.

However, I for one would be more interested in seeing this in a separate
I-D/RFC rather than son-of-2459.  I also agree that is seems silly to stuff
the image in the certificate, instead something along the lines of:

SubjectLogo ::= SEQUENCE {
  location        GeneralName,              
  digestAlgorithm AlgorithmIdentifier,
  digest          OCTET STRING 
}

seems appropriate. If you really want to go for a space save you could
make the digestAlgorithm OPTIONAL and have it use whatever is used to
generate the signature if it is not present.

Which begs the question, having a signed embedded reference (as opposed to
something like SubjectDirectoryAttributes) to arbitrary external content in
a Certificate seems to me to be wholly useful thing to want to do (e.g.
CPS, user agreement, photo of user's cat etc).  So is it worth perhaps
generalising something like the above to support this, e.g.

SubjectAuthenticatedReferences ::= SEQUENCE OF AuthenticatedReference

AuthenticatedReference ::= SEQUENCE {
  location        GeneralName,              
  digestAlgorithm AlgorithmIdentifier,
  digest          OCTET STRING 
}

or numerous permutations thereof.  Or perhaps such a beast exists already?

Just my $0.02.

-- 
Dean Povey,         | e-m: [email-masked] | JCSI:  Java Crypto Toolkit 
Research Scientist  | ph:  +61 7 3864 5120   | uPKI:  C PKI toolkit for embedded
Security Unit, DSTC | fax: +61 7 3864 1282   |        systems
Brisbane, Australia | www: security.dstc.com | Oscar: C++ PKI toolkit

---

From: jim <[email-masked]>
Date: Mon, 19 Mar 2001 19:24:13 -0500

As long as we are each throwing in TWO CENTS, do we have to consider the difference
between licensed and public domain fonts and their use in the logotype.  After all,
Adobe and Bitstream might be perturbed and want a piece of the action if one of
their fonts is used in this manner.  Then there would be an investigation and a
court case to determine which font was used and the key management issue of opening
the messages would perturbate the whole scheme. ...   ASCII character sets, please.
Jim

---

From: Rich Salz <[email-masked]>
Date: Mon, 19 Mar 2001 19:59:06 -0500

> go a long way to ameliorating this problem.

And what's to prevent the badguy from just copying the info out of a
real cert?  Fear of violating the trademark law?
	/r$

---

From: Dean Povey <[email-masked]>
Date: Tue, 20 Mar 2001 11:20:38 +1000

>real cert?  Fear of violating the trademark law?

I should have explained.  It only works if the browser does something 
sensible like displays the logo in a prominent place where the user will 
notice and which can't be recreated by just straight HTML.  Kind of like 
the way the lock clicks on to tell you you have a secure connection.  
Presumably the CA will perform some due-dilligence when certifying company 
logos.

Cheers

---

From: Dean Povey <[email-masked]>
Date: Tue, 20 Mar 2001 12:06:26 +1000

>Presumably the CA will perform some due-dilligence when certifying company 

To make the scheme clearer, one of the other authors on the first paper I
mentioned has recommended a more recent paper with more detail.

A. Jøsang, M.A. Patton and A. Ho. Authentication for Humans. In the
Proceedings of the 9th International Conference on Telecommunication Systems.
Dallas, March 2001. http://security.dstc.edu.au/papers/authum.pdf

Cheers.