Subject: New draft-ietf-pkix-logotypes-08.txt

From: "Stefan Santesson" <[email-masked]>
Date: Fri, 15 Nov 2002 16:11:43 +0100

There is a new logotypes draft 08 available from:

http://www.addtrust.com/pub/logotypes-08_dr03.txt
or from:
ftp://ftp.rsasecurity.com/pub/rsalabs/tmp/draft-ietf-pkix-logotypes-08.txt

This draft support inclusion of multiple community logos.
There is still support for audio.

It is the authors view that this reflects the rough consensus of this list
and that it take care of the comments raised during WG last call.

This draft, or an agreed update to this draft, will be posted to ID directly
after the Atlanta meeting.

/Stefan

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Housley, Russ
> Sent: Tuesday, October 29, 2002 3:17 PM
> To: [email-masked]
> Subject: Re: I-D ACTION:draft-ietf-pkix-logotypes-07.txt
>
>
>
> This update captures the things that have agreed.  The biggest change is
> the support in the syntax for color and gray scale images.  Many other
> little changes are included.
>
> As I see it, there are two open issues:
>     1) Removal of audio; and
>     2) Support for more than one logotype in each of the categories
>
> These two topics are still being discussed on the list.
>
> Russ
>
> >         Title           : Internet X.509 Public Key Infrastructure:
> > Logotypes in
> >                           X.509 certificates
> >         Author(s)       : S. Santesson, R. Housley, T. Freeman
> >         Filename        : draft-ietf-pkix-logotypes-07.txt
> >         Pages           : 21
> >         Date            : 2002-10-28
>

---

From: Denis Pinkas <[email-masked]>
Date: Tue, 19 Nov 2002 11:38:12 +0100

> and that it take care of the comments raised during WG last call.

The following comments that have ben raised during the last call have not 
been solved:

3. Page 7. Section 4.1 Extension format

There is no text which states what the client should do whenever it is
unable to support a given logotype. Insert the following text:

  "Whenever a client is unable to support a given logotype, no error SHALL be
  reported and the client MUST behave as if there was no logotype included in
  the certificate".

This raises the point that section 3 is still incorrect:

    "This specification defines two types of logotype data: image data and
    audio data. Implementations MUST support image data; however, support
    for audio data is OPTIONAL."

There are no implementations that MUST support image data, since display is 
optional. However, we should define what is a client *capable of* displaying 
logotypes. We currently can't since comment 7 has not been addressed.

In the same way since it seems that this (?!?!) audio logotype is likely to 
stay, we should define what is a client capable of playing a logotype.

Proposed text:

    This specification defines two types of logotype data: image data and
    audio data. Implementations claiming conformance with this document
    MUST be able to support image data with some minimum caracteristics;
    however, they MAY also be able to support audio data, with some
    minimum caracteristics."

It is also proposed to add that key sentence to the abstract, which is 
currently too short:

    This document specifies a certificate extension for including
    logotypes in public key certificates and attribute certificates.

7. Page 9. Section 4.1.

        LogotypeImageInfo ::= SEQUENCE {
           fileSize        INTEGER,  -- In octets
           xSize           INTEGER,  -- In pixels
           ySize           INTEGER,  -- In pixels
           numColors       INTEGER } -- In bits

  It is of particular importance to say what means conformance to this
  document for a client with respect to the number of pixels to support and
  the colors to support.

  It is proposed to add a sentence along these lines:

  "Clients claiming to conform with this document SHALL support an image with
  a minimum size of 48 pixels (xSize) by 32 pixels (ySize) in black and white
  with X grey levels."

Denis

---

From: "Stefan Santesson" <[email-masked]>
Date: Tue, 19 Nov 2002 21:49:04 +0100

Denis,

Most of the issues are already handled in the document. See comments below.

Regarding sizes, we may consider providing some guidance regarding the sizes
to be expected. This should thus not be requirements for conformance, but
rather just guidance for implementers.

> From: Denis Pinkas [mailto:[email-masked]]
> Sent: Tuesday, November 19, 2002 11:38 AM
> To: [email-masked]
> Cc: Stefan Santesson; Housley, Russ; Trevor Freeman
> Subject: Re: New draft-ietf-pkix-logotypes-08.txt
>
>

This is covered in section 6 (use in clients)

Current texts says:
   "If client is unable to support a provided logotype, the client
   MUST NOT report an error, rather the client MUST behave as though no
   logotype extension was included in the certificate."

> logotypes. We currently can't since comment 7 has not been addressed.

This is also covered in section 6.

Current text says:
   "A client MAY, subject to local policy, choose to display none, one or
   any number of the logotypes in the logotype extension."

>     however, they MAY also be able to support audio data, with some

This says the same thing as the text in the beginning of section 3, except
for your wording "minimum characteristics", where we simply disagree that
this is appropriate wording, since the implementation has to accommodate the
display characteristics of the device it is running on.

>     logotypes in public key certificates and attribute certificates.

We think the abstract is fine, in any way we can't place requirements in the
abstract.

>   a minimum size of 48 pixels (xSize) by 32 pixels (ySize) in

This is addressed at the beginning of this mail.

/Stefan & Trevor

---

From: [email-masked]
Date: Tue, 19 Nov 2002 19:53:20 -0500

Folks,

I have been reviewing the list, and have been unable to determine whether the 
current draft represents rough consensus or not.  Denis has submitted comments 
that the editors have not addressed, believing that the current content 
represents the collective position of the WG.  The list has been silent 
regarding these topics.  As a result, I have only been able to determine the 
opinions of the editors and Denis.

I intend to conduct a strawpoll at the meeting tomorrow; I would appreciate it 
if those who are *not* in attendance this week and have an opinion would voice 
it on the list.  If the current specification represents rough consensus, we 
will forward the specification to the ADs.  If not, we will ask the editors to 
make the appropriate changes and then forward the resulting draft.

Thanks,

Tim Polk

---

From: [email-masked]
Date: Tue, 19 Nov 2002 19:53:15 -0500

Folks,

Thanks,

Tim Polk

---

From: [email-masked]
Date: Tue, 19 Nov 2002 20:47:23 -0500

Stefan,

Thanks for the detailed response.  This means we have only one outstanding 
issue...

Is it the sense of the group that conformance requirements can be mandated, or 
is implementor guidanjce sufficient??

As before, I will poll the room.  For those not in Atlanta, please post your 
poinion to the list.

Thanks,

Tim

---

From: Denis Pinkas <[email-masked]>
Date: Wed, 20 Nov 2002 12:36:17 +0100

Stefan,

> Most of the issues are already handled in the document. See comments below.

Good. I read the document (too) fast.

> rather just guidance for implementers.

Guidance is not sufficient. CAs may want to be sure that some logos included 
in their certificates can *always* be displayed. In this way, some clients 
can say that they are really "logo-enabled", which means conformant with the 
RFC.

So there is a need to mandate a minimum size for the image (as well as 
colors or greys). CAs using that minimun size can then be sure that if the 
client is logo-enabled then the logo can be displayed. Now, "if one size 
does not fit all", then several classes should be defined and clients would 
conform to class a, b or c.

See other responses below.

>>>It is the authors view that this reflects the rough consensus
>>
>>of this list
>>

This is fine.

>    any number of the logotypes in the logotype extension."

This sentence is fine, but this issue is not only related to the local 
policy, but to the display capabilities. So this point remains.

> We think the abstract is fine, in any way we can't place requirements in the

The abstract is not fine. At least both image logotypes and sound logotypes 
should be mentionned in the abstract. Then, why not mention the difference 
in the approach between image logotypes and sound logotypes? This should not 
be hidden in the main body of the document.

> This is addressed at the beginning of this mail.

This is indeed addressed, but we still do not agree.

Denis

> /Stefan & Trevor
> 
> 
>>Denis
>>
>>
>>>This draft, or an agreed update to this draft, will be posted
>>
>>to ID directly
>>

---

From: J Adrian Pickering <[email-masked]>
Date: Wed, 20 Nov 2002 12:55:00 +0000

At 00:53 20/11/2002, [email-masked] wrote:

>current draft represents rough consensus or not.

<snip>

>  If the current specification represents rough consensus, we

I continue to have the same misgivings as most do regarding the problem 
over masquerading. Logotypes just make this so much easier to do because 
they are so attractive to humans. However, this is honestly admitted in the 
security section. If there is anything more that can be done to strengthen 
the warnings or reduce the possibility of misleading logos let's do it. 
Otherwise, I think it is an inevitable and justifyable matter to pursue.

Adrian Pickering/
University of Southampton