[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: draft-ietf-pkix-logotypes-06.txt
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:Denis.Pinkas@xxxxxxxx]
> Sent: Tuesday, October 15, 2002 12:47 AM
> To: Housley, Russ
> Cc: ietf-pkix@xxxxxxx
> 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