Greetings,

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

This document defines an extension to include logotypes-- both image
and audio-- into certificates. It is well written. The Security
Considerations are thorough with the nit mentioned below.

The summary of the review is Ready With Nits. Nits are as follows:

   - section 4.1 says clients SHOULD support both direct and indirect
     addressing while certificate issuing applications MUST support
     direct and SHOULD support indirect. That doesn't seem like it
     maximizes for interoperability. Leaving it up to the clients to
     decide while forcing issuers to do something may result in
     RFC-compliant clients that are unable to process logos issued
     by RFC-compliant issuers. While that won't result in failure it
     does affect the utility of these extensions. Suggest picking a
     MTI for clients.

   - section 4.2, when the logoTypeImageInfo size differs from the
     size of the reference image should some kind of image dithering
     be done to ensure that the resulting image conveys the appropriate
     picture? I can imagine blind scaling-- take every 4th pixel-- may
     result in undesirable results. Might be worthwhile to mention it
     but not mandate it.

   - section 4.4.1, I'm a bit puzzled why there's normative text around
     the inclusion of loyalty logotypes-- they MUST be in some order--
     when failure to process a logotype does not result in failure and
     clients can ignore them entirely if they like. Maybe rethink that
     normative text.

   - I'm also a bit puzzled by the selection of MTIs in section 7.
     PNG and SVG are SHOULD but SVG+gzip is a MUST? Not really a nit
     you need addressing but it is curious.

   - in the Security Considerations it cautions issuers to be careful
     of embedded logotype images because they might contain data that
     could be useful to an attacker trying to obtain colliding
     certificates when the hash algorithm is not collision resistant.
     Do we really want to care about issuers not using collision
     resistant hash algorithms? And what about stenography? Is that
     not also a concern for an issuer using an embedded logotype
     image in a certificate?

   regards,

   Dan.

-- 
"The object of life is not to be on the side of the majority, but to
escape finding oneself in the ranks of the insane." -- Marcus Aurelius