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 strawpoll.
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.
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.
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.
Logotypes MAY included in public key certificates and attribute certificates at the discretion of the certificate issuer; however; logotypes MUST NOT be part of certification path validation or any type of automated processing. The sole purpose of logotypes is to enhance display of a particular certificate, regardless of its position in a certification path.