Subject: RE: Logotypes in certificates

From: Tim Moses <[email-masked]>
Date: Tue, 20 Mar 2001 08:58:10 -0500

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.

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]]
Sent: Monday, March 19, 2001 11:47 AM
To: Stefan Santesson
Cc: [email-masked]
Subject: RE: Logotypes in certificates

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: Stephen Kent <[email-masked]>
Date: Tue, 20 Mar 2001 12:34:13 -0500

At 8:58 AM -0500 3/20/01, Tim Moses wrote:
>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.

Tim,

My comment re validation processing arises because of the possible 
undermining of name constraints, as I noted earlier. So, for example, 
I might be comfortable accepting a cert with a logo reference IF the 
cert path validation did not include a name constraints extension. 
But, how do I enforce this sort of rule without changing the path 
validation algorithm?

Steve

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 20 Mar 2001 23:06:38 +0100

Steve,

I think you comment is valid, but I challenge your conclusion that we 
better not use logotypes with certificates.

I think we agree that a logo in a certificate doesn't affect path 
validation processing technically (they are not part of the process), with 
or without name constraints. So when you talk about logotypes undermining 
the name constraints function I suppose you identify the case when:

1) A CA have a DN which doesn't violate name constraints from any cross 
certifying CA
2) This CA use a logotype which in fact does conflict with the same name 
constraints
3) A user looks at the logotype and ignores the DN.

For this to be true, the certificate must contain conflicting information. 
I.e. the certificate must contain a DN and a logotype which doesn't match.

I wander what CA, being certified by a significant trust anchor, that would 
do this and at the same time sign and seal this information fraud with its 
own signature? The CA simply couldn't get away with it!

I also suppose that the only way a logotype could undermine the naming 
schema is if logotypes have such significant impact on entity recognition, 
that users in general would se the logo and not notice that the DN is in 
conflict with the logotype.

If this is correct then you acknowledge the importance of logotypes as 
instrument of recognition, which speaks for that we should find a way to 
handle logotypes in certificates and not the opposite.

Personally I think that a conflict between a logotypes and a names in 
certificates can be handled on a contractual/legal level and should not 
stop us from using them in certificates.

/Stefan

At 12:34 2001-03-20 -0500, you wrote:
>>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.
>
>Tim,
>
>undermining of name constraints, as I noted earlier. So, for example, I 
>might be comfortable accepting a cert with a logo reference IF the cert 
>path validation did not include a name constraints extension. But, how do 
>I enforce this sort of rule without changing the path validation algorithm?
>
>Steve

---

From: Dean Povey <[email-masked]>
Date: Wed, 21 Mar 2001 14:09:47 +1000

>handle logotypes in certificates and not the opposite.

Surely it would be the responsibility of the CA to determine the logo -> 
DN mapping.  From a software perspective the path validation algorithm 
should not be affected. The logo is just there to help the user make a 
better decision about whether to trust the certificate.

Cheers.

-- 
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: Stephen Kent <[email-masked]>
Date: Tue, 20 Mar 2001 23:56:53 -0500

Dean and Stefan,

As a security kinda' guy, I always approach this from the "what will 
the bad giy do" perspective.  From that perspective, I worry that a 
TTP CA will cerfity company X, putting the company X logo in the 
cert. Then company X will issue a cert to a subordinate CA, and put 
in that cert an inappropriate logo. It is not realistic for an app to 
display a chain of logos, and expect a user to pay attention, any 
more that if one displayed a chain of DNs.  I still maintain that we 
can agree on what would be a reasonable set of circumstances in which 
the logo extension would be useful and safe, but I don't see a 
technical means of enforcing these circumstances without changes to 
the path validation algorithm. I am open to suggestions that provide 
the necessary controls and don't have this unfortunate side effect, 
but I have yet to see an example of such.

Steve