[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: draft-ietf-pkix-logotypes-06.txt
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.
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