Internet X.509 Public Key Infrastructure: Logotypes in X.509 Certificates
draft-ietf-lamps-rfc3709bis-10

# Internet AD comments for draft-ietf-lamps-rfc3709bis-07
CC @ekline

## Nits

### S1.2

* "from his wallet" -> "from their wallet", perhaps

### S6

* "replying party software" -> "relying party software"

Thank you for the work on this document.

Many thanks to Shuping Peng for her ART ART review: https://mailarchive.ietf.org/arch/msg/art/8siu5xkhxN6Y2quxSVkBPoyD4-Y/.

Original DISCUSS:
------------------
Don't Panic! As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is a request to have a discussion...

I'm assuming that I'm missing something really obvious here, but this *feels* like a bad idea to me...

The document says: "The use of logotypes will, in many cases, affect the users decision to trust and use a certificate." Yes, but that seems like a bad outcome...

Random things on the Internet tell me that Microsoft has a well recognized logo. Seems plausible, let's use that as an example. When a user is trying to figure out if a certificate actually belongs to Microsoft they are likely to go "Oh, yes, it's a square composed of other colored squares, this must really be Microsoft", even if the CN is for www.evil-attackers-r-us.net. Even without an attacker intentionally creating visually confusing logos, many are similar - for example, https://icn.bg/ looks really similar to Microsoft's logo (and many things look very similar to the Pepsi logo - https://yourmileagemayvary.net/2021/05/23/look-up-in-the-sky-its-a-coke-plane-its-a-pepsi-plane-its/ ).

Here is an image with two logos: https://cdn.mos.cms.futurecdn.net/hD95PaJgx5ZZVCFduTWhtg-1200-80.jpg.webp One of these is for airbnb, and one is for a Japanese drive-in. Keeping in mind that, as a user, the logotype is likely to affect your decision to trust and use the cert, when entering your credit-card info to book your next vacation rental, do you know which of these you should expect? If you get the drive-in one, would you really recognize that?

The document uses VISA and MasterCard as examples, but, without looking in your wallet to actually confirm what their logos look like, are you *sure* that you would be able to unambiguously identify them if placed next to logos made by an attacker? 

Ok, so now that I've had my soapbox rant: This document updates RFC 3709 and RFC 6170, which been around since 2004 and 2011 respectively. Apparently the sky hasn't actually fallen yet, and so I must be missing something. I did spend quite a while trying to find examples using RFC3709/RFC6170, so I could figure out what I'm missing, but failed. I *did* find a few CA certs with this, but they just had links to http://logo.verisign.com/vslogo.gif (which doesn't resolve). The only "live" cert was for https://www.dtihost.cz/, but it's not valid.

Again, I'm probably missing something obvious, and so clue-bat appreciated...

# Éric Vyncke, INT AD, comments for draft-ietf-lamps-rfc3709bis-07
CC @evyncke

Thank you for the work put into this document. 

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits.

Special thanks to Tim Hollebeek for the shepherd's write-up including the WG consensus *and* the justification of the intended status. 

Thanks also to Don Eastlake for his internet directorate review that I requested, see:
https://datatracker.ietf.org/doc/review-ietf-lamps-rfc3709bis-07-intdir-telechat-eastlake-2022-11-23/
I have noted that Russ, as author, has already replied and addressed the Don's comments.

I hope that this review helps to improve the document,

Regards,

-éric

## COMMENTS

### Section 1

Just a minor regret as several points about human beings are written but no reference is provided. As a human being, I would tend to agree strongly with the authors of course but a reference, if any, would have been nice ;-)

### Section 1.1

Suggest to expand the B2B and B2C acronyms as they are not part of https://www.rfc-editor.org/materials/abbrev.expansion.txt

### Section 4.1

The I-D seems to allow for plain HTTP transport, which is a little surprising. Of course, there could be a chicken and egg issue and anyway the hash should provide authenticity of the logo. At least, FTP was removed ;-)

### Strength of the hash

Probably a naive question but should the crypto strength of the hash be linked to the strength of the public key / signature of the certificate ? I.e., if a human being is about to trust a cert based on a logo, I would naively assume that the logo is more protected than the cert itself.

### Section 7 image/svg+xml-compressed

The note about "image/svg+xml-compressed" is interesting: is there work somewhere to register to IANA ? If and when it happens, then will it be allowed to be used in this specification ?

## NITS

### Section 3

Isn't "one-way hash" a pleonasm ? I.e., should "hash" be enough ?

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. 

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments

# GEN AD review of draft-ietf-lamps-rfc3709bis-08

CC @larseggert

Thanks to Paul Kyzivat for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/IiFgJfnLGPzwxj92raQWE4oI108).

## Comments

### Section 4.1, paragraph 8
```
     Note that the HTTPS scheme (https://...) requires the validation of
     other certificates to establish a secure connection.  For this
     reason, the HTTP scheme (http://...) may be easier for a client to
     handle.  Also, the hash of the logotype data provides data integrity.
```
It may be easier, but it's also insecure. I find it odd that we don't
recommend HTTPS over HTTP here?

### Inclusive language

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

 * Term `his`; alternatives might be `they`, `them`, `their`
 * Term `traditional`; alternatives might be `classic`, `classical`, `common`,
   `conventional`, `customary`, `fixed`, `habitual`, `historic`,
   `long-established`, `popular`, `prescribed`, `regular`, `rooted`,
   `time-honored`, `universal`, `widely used`, `widespread`

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Typos

#### Section 3, paragraph 6
```
-    applications where the audio text is placed as the "alt" atttribute
-                                                                -
```

#### Section 3, paragraph 6
```
-    value of an html image (img) element and the language value obtained
-                ^^^^
+    value of an HTML image (img) element and the language value obtained
+                ^^^^
```

#### Section 7, paragraph 16
```
-    When a bitmapped image is used, the PNG [ISO15948] format SHOULD be
-                 ---
```

### URLs

These URLs in the document can probably be converted to HTTPS:

 * http://www.w3.org/TR/2008/PR-SVGTiny12-20081117

### Grammar/style

#### Section 1, paragraph 3
```
tificate may be examined from several different perspectives. Systematic pro
                              ^^^^^^^^^^^^^^^^^
```
Consider using "several".

#### Section 1, paragraph 9
```
a user identifies the owner of the web site. * Peer e-mail exchange in busin
                                   ^^^^^^^^
```
Nowadays, it's more common to write this as one word.

#### Section 1.1, paragraph 4
```
ate is too technical and is not user friendly. It contains no graphic symbol
                                ^^^^^^^^^^^^^
```
This word is normally spelled with a hyphen.

#### Section 1.3, paragraph 3
```
the end, the human will decide whether or not to accept an executable email a
                               ^^^^^^^^^^^^^^
```
Consider shortening this phrase to just "whether". It is correct though if you
mean "regardless of whether".

#### Section 6, paragraph 7
```
references to information stored outside of the SVG image of type B, C, or D
                                 ^^^^^^^^^^
```
This phrase is redundant. Consider using "outside".

#### Section 7, paragraph 2
```
FC1952] as specified in [SVGR]. When a uncompressed SVG image is fetched wit
                                     ^
```
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

#### Section 7, paragraph 3
```
 characters as specified above. When a SVG image is embedded in the certific
                                     ^
```
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool

Hi,

Thanks for this document.  This is quite a long way outside my area of expertise and given that this is a bis document, I only looked over the diff relative to RFC 3709.

On a general note, I was wondering how widely deployed logotypes are?  I tried various web searches for "logotype" with and without "X.509/certificates" and didn't seem to find any obvious matches.  Perhaps a different commercial name is used for this?

I also have one specific comment on the text:

 All direct addressing URIs SHOULD
   use the HTTPS scheme (https://...) or the HTTP scheme (http://...) or
   the DATA scheme (data://...) [RFC3986].  However, the "data" URI
   scheme MUST NOT be used with the indirect addressing.  Clients MUST
   support retrieval of referenced LogoTypeData with the HTTP [RFC9110]
   and the HTTP with TLS [RFC8446], or subsequent versions of these
   protocols.  Client applications SHOULD also support the "data" URI
   scheme [RFC2397] for direct addressing with embedded logotype data
   within the extension.

I find this text (specifically the SHOULD in the first sentence, and MUST/SHOULD in the subsequent sentences to be somewhat ambiguous.  E.g., it is unclear to me whether using an alternative scheme from the three listed is allowed, and if so under what circumstances such a scheme can be used?  If no other schemes can be used then perhaps the first sentence should just be: "All direct addressing URIs use the HTTPS scheme (https://...) or the HTTP scheme (http://...) or the DATA scheme (data://...) [RFC3986]."

Regards,
Rob

// I would also like to thank Sheng for the OPSDIR review.