Internet X.509 Public Key Infrastructure: Logotypes in X.509 Certificates
draft-ietf-pkix-logotypes-13

[Ballot comment]
I've cleared my discuss, but a couple of nits remain:

The field name for the media type is called "mediaSubType". This should be
changed to "mediaType" since it contains the entire media type string, not
just the subtype.

The restructuring that's been done fixes the problem of having to
use image types exclusively for images and audio types exclusively
for aduio, but this in turn means that the comment on the media type
field "MIME image or audio subtype" is no longer appropriate. Suggest
changing it to "MIME media type name and optional parameters".

I continue to believe that it is a mistake not to use media features
rather than inventing a new private nonextensible labelling scheme,
but my belief is not cause to block this document going forward.

[Ballot comment]
I have cleared my discuss based on version -12.
I still agree with Ned's comments about describing data, but will leave it to Ned to say if those issues have been addressed.
Still worried about the GIF reference, but it's not worth holding the document for.

[Ballot comment]
My DSICUSS question was:
  What do the numbers in the first column in appendix B represent?

The answer is that they are offsets into the certificate.
Russ and I agreed (via email) that it would be good to add a sentence
about that so that people can understand what the first column represents.

[Ballot discuss]
Image/JPEG, Image/GIF and Audio/MPEG are not included in references.
Image/JPEG is OK (registry refers to RFC 2046, which has a ref to the JPEG spec), but Image/GIF doesn't have a good reference (the RFC 2046 reference in IANA's database is erroneous).
Audio/MPEG is OK, but needs to reference RFC 3003.
I also agree with Ned's comments about describing data.
Also, the spec uses an URI without specifying any usage guidelines for it except that HTTP must be supported - in theory, one could validly insert an LDAP: URI or a mailto: URI - it's unclear how an interpreter is supposed to interpret that.
The text is weak in requiring relying parties to check the hash.
The security considerations do not mention the privacy issue that someone watching the connection between user and server can detect when someone is using a certificate for the first time.

[Ballot discuss]
Although I don't object, in principle, to the idea of associating logos
or sounds with certificates, I am having trouble understanding the value
of doing so.  Also, I found much of the text in this document to be
either confusing or disturbing.

The discussion of human psychology and branding in the introduction
seems misplaced in a protocol specification.

Also, there is a strange tension in this document between:

1) The  purpose of including logo information in a certificate 
  is that users will decide how much to trust a given certificate
  based on its "brand".
2) There is no way to authenticate that the logo information
  associated with a certificate is valid in any way.

The security considerations section says:

"It is thus imperative that the representation of any
certificate that fails to validate is not enhanced in any way by
using the logotype graphic unless an appropriate warning is given to
the end user."

But, other sections of the document have already acknowledged the
fact that the user will pay more attention to whether or not he
trusts the apparent "brand" of the certificate than to an obscure
warning message...

[Ballot discuss]
Section 1.

TH: I personally believe this whole line of reasoning is utterly bogus.
X.509 Certs are not human readable, and the idea that external reference
to human-readable symbols adds to their functionality doesn't fly.  The
*best* we can hope for is that the inclusion doesn't preclude the correct
functioning of the automated checks, so that they don't allow for
trivial social engineering around the cryptographic assurance these
are meant to apply.

Section 3.

TH: Once again, this conflates URI with the protocol processing needed
to dereference a file.  This should probably limited to a very restricted
set of agreed-on URI schemes.  It also needs to think very carefully about the
content negotiation aspects of this, as they have forbidden the display
or annunciation of multiple variants, yet there is no pointer to how to
select among them.  A ranked order system (like multipart-alternative)
or CONNEG style mechanism looks required.

Section 7>

draft: It is thus imperative that the representation of any
  certificate that fails to validate is not enhanced in any way by
  using the logotype graphic unless an appropriate warning is given to
  the end user.

TH: No. No. No.  No warning can overcome symbols where the naive
user has a strong reason to believe the symbol.  Take, for example,
a user who has downloaded a site with a self-signed certificate
in which the authority claims to be "United States GAO" and presents
the symbol of the great seal of the United States.  The *real*
site may have a VeriSign-issued cert, but the naive user is going
to believe it is reasonable for a sovereign nation to self-sign,
and providing a lifted logo is just going to make the social
engineering worse.

[Ballot discuss]
Image/JPEG, Image/GIF and Audio/MPEG are not included in references.
Image/JPEG is OK (registry refers to RFC 2046, which has a ref to the JPEG spec), but Image/GIF doesn't have a good reference (the RFC 2046 reference in IANA's database is erroneous).
Audio/MPEG is OK, but needs to reference RFC 3003.
I also agree with Ned's comments about describing data.
Also, the spec uses an URI without specifying any usage guidelines for it - in theory, one could validly insert an LDAP: URI or a mailto: URI - it's unclear how an interpreter is supposed to interpret that.

[Ballot discuss]
It isn't clear whether the mimeType field is restricted to a MIME type/subtype
pair or whether it allows for specification of MIME type parameters. I note that some audio types use parameters to communicate information that's needed in order to play back the audio stream correctly.

The restriction to subtypes of image and audio is... interesting. The rule
is that subtypes of image must be image formats and subtypes of audio must
be audio formats, but the converse -- that subtypes of other top-level types
cannot be used to describe images and audio -- is not true. For example,
application/postscript can be used for images. (It was placed under application
because it can be used for other things as well.)

There are also several problems with the definitions of the LogotypeGrayScaleImageInfo, LogotypeColorImageInfo, and LogotypeAudioInfo fields:

(1) Images can be language-specific, so why can't they be tagged with a
    langauge?

(2) It is perfectly reasonable to tag audio objects with a length but not all
    audio formats employ a fixed number of sample per second. Yet samples per
    second is a mandatory field in the LogotypeAudioInfo structure.

(3) I'm by no means an expert, but I'm fairly sure that not all image formats
    are amenable to the number of colors/greyscale levels being specified as
    a "number of bits". Yet these are also mandatory fields.

All this begs the question of why our existing media features facility wasn't
used here rather than defining what amounts to a new but limited feature tagging
facility.