Subject: Re: WG Last Call: Logotypes

From: Denis Pinkas <[email-masked]>
Date: Fri, 10 Jan 2003 13:30:54 +0100

> This message initiates working group Last Call for the logotypes 
> document.  In light of holiday schedules, Last Call will run for three 
> weeks rather than two weeks.  That is, Last Call will not close before 
> January 13.   The URL for this Internet-Draft is:
> 
>      http://www.ietf.org/internet-drafts/draft-ietf-pkix-logotypes-09.txt
> 
> The editors have informed us that "all of the items briefed at the 
> meeting in Atlanta as well as the request by the chairs have been 
> handled. In addition, a few comments from working group members that 
> sent us email have been addressed."

I acknowledge the fact that many improvements have been done to the 
specification.

However I have two remaining concerns:

1. In order to try to solve the minimum interoperability requirements 
between an application and a certificate issuer, the characteristics of the 
size of the picture have been indicated in the following way:

    At least one of the image files representing a logotype SHOULD
    contain an image within the size range of 60 pixels wide by 45 pixels
    high and 200 pixels wide by 150 pixels high.

This does not say what whether a client is able or not to display logos, 
which was the basic question.

I suggest to mandate clients to support at least images within the size 
range of 60 pixels wide by 45 pixels. This sentence does not exist in the 
document and should be added.

2. I have indicated that it would be nice to have an optional pointer to a 
web site where more information could be obtained about the logo. This is 
currently not possible with the current definition. From a non-technical 
point of view, it would be a very nice marketing tool.

This can easily be accomplished by adding one OPTIONAL element in the ASN.1 
syntax.

Denis

---

From: Russ Housley <[email-masked]>
Date: Fri, 10 Jan 2003 09:04:04 -0500

Denis:

>>handled. In addition, a few comments from working group members that sent 
>>us email have been addressed."
>
>between an application and a certificate issuer, the characteristics of 
>the size of the picture have been indicated in the following way:
>

I have no problem with this addition.

>This can easily be accomplished by adding one OPTIONAL element in the 
>ASN.1 syntax.

This addition opens a huge can of worms.  I would prefer to leave the lid 
tightly sealed.

The certificate issuer would be including a reference in the certificate to 
information that is maintained by another party, and that other party could 
make unacceptable changes after certificate issuance.  The usual mechanism 
to handle this situation is to include a hash value of the referenced 
object, preventing any changes.  However, in this context, this does not 
seem like an appropriate thing to do.  The organization that owns the logo 
will surely want to make changes to their web page.  And, it is not easy to 
handle links form that web page.  Handling links would require the 
definition of complicated canonicalization rules.

Russ

---

From: Denis Pinkas <[email-masked]>
Date: Fri, 10 Jan 2003 16:23:32 +0100

Russ,

Thanks for your prompt answer.

>>> document.  In light of holiday schedules, Last Call will run for 
>>> three weeks rather than two weeks.  That is, Last Call will not close 
>>> before January 13.   The URL for this Internet-Draft is:
>>>      
>> between an application and a certificate issuer, the characteristics 
>> of the size of the picture have been indicated in the following way:
>>
>> This does not say what whether a client is able or not to display 
>> logos, which was the basic question.
>>
>> I suggest to mandate clients to support at least images within the 
>> size range of 60 pixels wide by 45 pixels. This sentence does not 
>> exist in the document and should be added.
> 
> 

Fine.

>> 2. I have indicated that it would be nice to have an optional pointer 
>> to a web site where more information could be obtained about the logo. 
>> This is currently not possible with the current definition. From a 
>> non-technical point of view, it would be a very nice marketing tool.
>>
> This addition opens a huge can of worms.  I would prefer to leave the 
> lid tightly sealed.

I would rather go fishing with that huge can of worms. :-)

> The certificate issuer would be including a reference in the certificate 
> to information that is maintained by another party, and that other party 
> could make unacceptable changes after certificate issuance.  The usual 
> mechanism to handle this situation is to include a hash value of the 
> referenced object, preventing any changes.  However, in this context, 
> this does not seem like an appropriate thing to do.  The organization 
> that owns the logo will surely want to make changes to their web page.  
> And, it is not easy to handle links form that web page.  Handling links 
> would require the definition of complicated canonicalization rules.

The basic question is what the link contains. The intent is not to point to 
a link where you have the exact meaning of the logo, but to the entry point 
of a web site. Here is an example for such a URL:

http://www.cartes-bancaires.com/GB/Pages/Accueil2.htm

So we need to carefully state what the link contains.

Denis

---

From: Russ Housley <[email-masked]>
Date: Fri, 10 Jan 2003 11:14:49 -0500

Denis:

>The basic question is what the link contains. The intent is not to point 
>to a link where you have the exact meaning of the logo, but to the entry 
>point of a web site. Here is an example for such a URL:
>

I understand the manner that you wish to use the URL.  It is not 
appropriate to prevent changes to such a web page by including a hash in 
the certificate.  So, it is possible for changes to be unacceptable to the 
certificate issuer.  The only recourse would be the revocation of the 
certificate, and this punishes the wrong party.  The subject would have to 
get a new certificate (without the embedded URL), yet the subject had no 
part in the activities that lead to revocation.

I remain opposed.

Russ