Telechat Review of draft-ietf-lamps-rfc3709bis-08
review-ietf-lamps-rfc3709bis-08-secdir-telechat-harkins-2022-12-04-00
review-ietf-lamps-rfc3709bis-08-secdir-telechat-harkins-2022-12-04-00
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