[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


Stefan,

Denis,

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

Good. I read the document (too) fast.

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.

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.

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



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. 

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 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."

This is fine.

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.



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."

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


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."



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.


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.



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

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.


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."


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

after the Atlanta meeting.

/Stefan





-----Original Message-----
From: owner-ietf-pkix@xxxxxxxxxxxx
[mailto:owner-ietf-pkix@xxxxxxxxxxxx]On Behalf Of Housley, Russ
Sent: Tuesday, October 29, 2002 3:17 PM
To: ietf-pkix@xxxxxxx
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