Subject: RE: draft-ietf-pkix-logotypes-06.txt

From: "David Cross" <[email-masked]>
Date: Mon, 21 Oct 2002 06:37:01 -0700

Denis:

I my opinion, I am afraid that the presence of logotypes in additonal
types of certificates will imply that clients should display such logos
when path validation or revocation check is performed.  For example,
every time a mail message is processed and signature check performed,
should the mail client display the logo for the OCSP responder to the
end user?  In that example, I would argue strongly that we have extended
from the useful scenario of enabling simpler certificate selection for
end users to an intolerable user experience.

I don't have any strong technical argument for the limitation, just a
practical argument for implementors. 

Regards,

David B. Cross

David,

> Denis:
> 
> In general, I agree with most of your suggestions.  Thanks for taking 
> the time to perform a thorough review - I apologize for the delay in 
> response.  I do however, disagree with suggestion #12.  I disagree on 
> the basis that a relying party would want oir need to view logos for 
> certificates used in path and revocation processing.

My proposed phrasing is not in contradiction with your above statement. 
So I still do not understand why there should be any limitation. Could 
you argue and/or provide examples ?

Denis

> 12. Page 11. Section 5. Type of certificates
> 
>    Logotypes MAY be present in three types of certificates:
> 
>      - CA certificates
>      - End-entity certificates
>      - Attribute certificates
> 
> Why is there such a limitation ? CRL Issuers, OCSP responders or TSUs 
> may have logotypes present in their certificates.
> 
> Replace with : "Logotypes MAY be present in any type of certificate".
> 
> Regards,
> 
> David B. Cross
> 
> -----Original Message-----
> From: Denis Pinkas [mailto:[email-masked]]
> Sent: Tuesday, October 15, 2002 12:47 AM
> To: Housley, Russ
> Cc: [email-masked]
> Subject: Re: draft-ietf-pkix-logotypes-06.txt
> 
> Russ,
> 
> > We just posted an update to the logotypes draft.  There are two 
> > primary changes from the previous version.  First, we tried to be 
> > more
> 
> > clear about what is mandatory to implement and what is not.
> 
> This is not yet clear enough. See below.
> 
> > Second, we added support for more than one hash function without 
> > having to repeat a lot of data.
> >
> > The loudest objections (as opposed to jokes) came from Microsoft. 
> > Based on discussions with Trevor Freeman, I believe that Microsoft 
> > can
> 
> > accept this version.
> >
> > We are still in Working Group Last Call.....
> 
> Since we are still in Working Group Last Call, here are my 12 comments

> on that document.
> 
> 1. Page 6. Section 3. Logotype data
> 
> "Implementations MUST support image data; however, support for audio 
> data is OPTIONAL." Audio is a good joke, in the same way, as 
> pheromones. We are supposed to deal with serious documents. Please 
> delete.
> 
> 2. Page 7. Section 4.1 Extension format
> 
> "Clients MUST support both direct and indirect addressing."
> 
> I disagree. If an end-user certificate is included in a signature, it 
> may be interesting to display the logotype even if the terminal is 
> off-line. Indirect addressing would mandate an on-line connection.
> 
> Replace with:
> 
> "Clients claiming to conform with this document SHALL support direct 
> addressing. Clients MAY also support indirect addressing."
> 
> 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".
> 
> 4. Page 8. Section 4.1.
> 
>       LogotypeData ::= SEQUENCE {
>          image           SEQUENCE OF LogotypeImage     OPTIONAL,
>          audio           [1] SEQUENCE OF LogotypeAudio OPTIONAL }
> 
> Since audio support should be suppressed, replace with:
> 
>       LogotypeData ::= SEQUENCE OF LogotypeImage
> 
> 5. Page 7. Section 4.1.
> 
> We have:
> 
>       communityLogo   [0] EXPLICIT LogotypeInfo OPTIONAL,
> 
>       LogotypeInfo ::= CHOICE {
>          direct          [0] LogotypeData,
>          indirect        [1] LogotypeReference }
> 
>       LogotypeData ::= SEQUENCE {
>          image           SEQUENCE OF LogotypeImage OPTIONAL,
> 
> No explanations are given on the text about what to do for a client 
> when there is more than one LogotypeImage present in a communityLogo.
> 
> First of all, a communityLogo may contain more than one logo which 
> belongs to one or more communities. However the client has no way to 
> know whether the LogotypeData includes different versions from the 
> same logo (e.g. in black and white or in color) or different logos.
> 
> The ASN.1 structure is not adapted to make that difference. Therefore 
> it is proposed to modify the ASN.1 syntax along the following way:
> 
>          communityLogos   [0] EXPLICIT CommunityLogos OPTIONAL,
> 
> CommunityLogos ::= SEQUENCE OF CommunityLogo
> 
> CommunityLogo ::= LogotypeInfo
> 
> In this way, clients can make their best efforts to support only one 
> instance of version for each CommunityLogo.
> 
> 6. Page 9. Section 4.1.
> 
>       LogotypeImageInfo ::= SEQUENCE {
>          fileSize        INTEGER,  -- In octets
>          xSize           INTEGER,  -- In pixels
>          ySize           INTEGER,  -- In pixels
>          numColors       INTEGER } -- In bits
> 
> Text is missing to explain this structure. How is a grey scale 
> indicated for jpeg and for gif ???
> 
> 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."
> 
> 8. Page 9. Section 4.1.
> 
>       LogotypeImageInfo ::= SEQUENCE {
>          fileSize        INTEGER,  -- In octets
>          xSize           INTEGER,  -- In pixels
>          ySize           INTEGER,  -- In pixels
>          numColors       INTEGER } -- In bits
> 
> It would also be appropriate to say what to do when the image is in 
> color and that the client has no color display available. No display 
> at all ? Conversion into grey scale using which kind of transposition 
> ?
> 
> 9. Page 9. Section 4.1. Since audio is a joke, text and ASN.1 about 
> audio should be deleted.
> 
> 10. Page 9. Section 4.1. The text states:
> 
> "Implementations MUST support both the JPEG and GIF image formats 
> (with MIME types of "image/jpeg" and "image/gif", respectively)"
> 
> I would guess that Animated GIF should not be supported. Could we say 
> it ?
> 
> 11. Page 10. Section 4.1.
> 
>       Community Logotype. If communityLogo is present, the logotype
MUST
>       represent the community to which the certificate issuer is
>       affiliated. The communityLogo MAY be present in an end entity
>       certificate, a CA certificate or an attribute certificate.
> 
> A certificate issuer may belong to more than one community. Replace: 
> "the community " by :"the community or the communities".
> 
> 12. Page 11. Section 5. Type of certificates
> 
>    Logotypes MAY be present in three types of certificates:
> 
>      - CA certificates
>      - End-entity certificates
>      - Attribute certificates
> 
> Why is there such a limitation ? CRL Issuers, OCSP responders or TSUs 
> may have logotypes present in their certificates.
> 
> Replace with : "Logotypes MAY be present in any type of certificate".
> 
> Denis
> 
> >
> > Russ

---

From: Denis Pinkas <[email-masked]>
Date: Tue, 22 Oct 2002 09:46:10 +0200

David,

The issue is about the *presence* of the extension in the certificate, 
not about the *display* of the extension.

The proposed sentence is: 
"Logotypes MAY be present in any type of certificate".

Your argumentation is whether or not a logotype, if present in a
certificate, shall be displayed.

Since it is a MMI problem and not a protocol issue, it is quite hard to
place requirements on MMIs.

I believe that logotypes MAY be present in any type of certificate. 
Then, it is not because an extension is present that it should always 
be displayed.

I would have no problem to add text to state recommendations for display.

Denis