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

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 24 Oct 2002 10:22:38 -0700

I find it somewhat bizare that we have this level of opposition to a
feature that there is significant commercial demand for while the group
continues to spend time on whole document sets that there is no
commercial demand for.

If it is ok for a working group to do stuff like SCVP even though the
industry has declined to give support then surely it is OK for the group
to do audio logotypes.

		Phill

> -----Original Message-----
> From: Denis Pinkas [mailto:[email-masked]]
> Sent: Thursday, October 24, 2002 6:47 AM
> To: Housley, Russ
> Cc: [email-masked]
> Subject: Re: draft-ietf-pkix-logotypes-06.txt
> 
> 
> 
> Russ,
> 
> > Denis:
> > 
> >> 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.
> > 
> > 
> > I belive that the response from Tom Gindin shows that there 
> is support 
> > for audio in support if disabled users.  I believe that the 
> document is 
> > clear that the support is OPTIONAL.
> 
> The document was not clear that the support is OPTIONAL. 
> There is still much 
> controversy about the need for it. No convincing arguments have been 
> provided. Please delete or make a strawpol.
> 
> >> 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."
> > 
> > 
> > We have already had a dialogue on this point.  I hope it is 
> resolved.
> 
> Indeed.
> 
> >> 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".
> > 
> > 
> > I will add a similar sentence to the second paragraph of 
> section 6.  The 
> > paragraph now says:
> > 
> >    After a certification path is successfully validated, 
> the replying
> >    party trusts the information that the CA includes in the 
> certificate,
> >    including any certificate extensions. The client 
> software can choose
> >    to make use of such information, or the client software 
> can ignore
> >    it. 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. 
> Current standards
> >    do not provide any mechanism for cross-certifying CAs to 
> constrain
> >    subordinate CAs from including private extensions (see 
> the security
> >    considerations section).
> 
> This is fine.
> 
> >> 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
> > 
> > 
> > This is related to comment 1.  No change will be made.
> 
> See above.
> 
> >> 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.
> > 
> > 
> > This is not supported.  The certificate may only include 
> one image.  
> > That image could be a composite of many different logos, if 
> > appropriate.  We discussed this face-to-face in Yokohama.  
> Discussion 
> > with people what develop graphical interfaces do not think 
> it is a good 
> > idea to allow this complexity.  Too many images will 
> confuse the user.  
> 
> 
> > When it is appropriate to include several community logos, 
> they must be 
> > combined into one image to ensure that they are 
> consistently displayed.  
> > If this is not done, each client will render the images 
> differently...
> 
> We still have different views on that topic, which is far 
> more important 
> than audio. To give a parallel: some banks are members of 
> both VISA and 
> EuroCard. Transposed into certificates, this may mean two 
> logos. In the same 
> way, a CA may be certifed by two laboratories. The logo of these two 
> laboratories may be displayed.
> 
> So for community certificates, I am requesting the 
> possibility to have more 
> than one logo. The use of combined logos is not appropraite 
> to solve this issue.
> 
> >> 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 ???
> > 
> > 
> > Do you have a recommendation?
> 
> No. But I wonder whether the structure is correct. Has it 
> been verifed by an 
> image expert ? Many PDAs have B&N screens only because they 
> are cheaper.
> 
> >> 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."
> > 
> > 
> > We have tried to avoid such a statement.  Instead we allow 
> the inclusion 
> > of the same image at many different resolutions so that the 
> client can 
> > select the best fit.  This is also the reason that we use 
> MIME types to 
> > name the format.  It allows the greatest flexibility.
> 
>   ... but is does not provide any conformance clause.
> 
> Can we say that a client is logo-enabled if it only supports 10 x 10
> pixels ? Unless the minimumm size (whatever it is) is always 
> present in
> the logo, then it is not possible to say that the client is 
> logo-enabled.
> 
> >> 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 ?
> > 
> > 
> > The client is always allowed to ignore the logotype 
> altogether.  The 
> > stronger language added in response to your third comment 
> makes this clear.
> 
> Do you mean that if the logo is defined in color and the 
> terminal is only 
> B&N then the logo shall not be displayed ? If so, this should 
> be clearly said.
> 
> 
> >> 9. Page 9. Section 4.1. Since audio is a joke, text and 
> ASN.1 about audio
> >> should be deleted.
> > 
> > 
> > Again, related to your first comment. No change.
> 
> See above.
> 
> >> 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 ?
> > 
> > 
> > Okay.  That paragraph now reads:
> > 
> >    A MIME type is used to specify the format of the file 
> containing the
> >    logotype data. Implementations MUST support both the JPEG and GIF
> >    image formats (with MIME types of "image/jpeg" and "image/gif",
> >    respectively). Animated images SHOULD NOT be used. 
> Implementations
> >    that support audio MUST support the MP3 audio format (with a MIME
> >    type of "audio/mpeg").
> 
> The additional sentence for animated images is fine. No 
> comment on the 
> additional sentence for audio. See above.
> 
> >> 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".
> > 
> > 
> > This is already discussed in response to comment 5.  No change.
> 
> I maintain the request for it. See above.
> 
> >> 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".
> > 
> > 
> > David Cross spoke against this suggestion.
> 
> No. David Croos spoke about the *display* of the logo, not 
> the *presence* of 
> the logo. Please make the change or provide new arguments.
> 
> 
> Denis
> 
> > Russ
> 
> 
>