Subject: [lamps] WG Last Call for draft-ietf-lamps-rfc3709bis-01

From: Tim Hollebeek <[email-masked]>
Date: Fri, 11 Mar 2022 21:37:00 +0000

Title: Internet X.509 Public Key Infrastructure: Logotypes in X.509 Certificates

Authors: Stefan Santesson, Russ Housley, Trevor Freeman, Leonard Rosenthol

Draft: https://www.ietf.org/archive/id/draft-ietf-lamps-rfc3709bis-01.txt
Datatracker: https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc3709bis/

This document specifies a certificate extension for including logotypes in public
key certificates and attribute certificates.  This document obsoletes RFC 3709
and RFC 6170.

The WG Last Call will run until Thursday, March 31st.  Please review the document

and respond with any comments or concerns on the mail list.

For the LAMPS WG Chairs,
Tim

---

From: Sean Turner <[email-masked]>
Date: Tue, 15 Mar 2022 10:51:37 -0400

Hi! I think these are nits, but thought I would throw send them:

0) s4.1 calls out HTTP/2, but says nothing about HTTP/3. HTTP/3 is in AUTH48 now - worth a mention for future proofing?

1) s7: As the table also calls out what SHOULD be implemented maybe:

OLD:

The table also indicates which of the image	
formats must be supported by implementations.

NEW:

The table also indicates the support requirements for image	
formats.

2) A.2: I think the title should be changed to reference the date in [NEW-ASN] or refer to the 2002 version as RFCs 5912 & 6268 do:

OLD:

A.2. ASN.1 Module with 1997 Syntax

NEW:

A.2. ASN.1 Module with 2021 Syntax
or
A.2. ASN.1 Module with 2002 Syntax

spt

> On Mar 11, 2022, at 16:37, Tim Hollebeek <tim.hollebeek=[email-masked]> wrote:
> 
> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm

---

From: Russ Housley <[email-masked]>
Date: Tue, 15 Mar 2022 11:14:44 -0400

Sean:

Thanks for the review.

> 0) s4.1 calls out HTTP/2, but says nothing about HTTP/3. HTTP/3 is in AUTH48 now - worth a mention for future proofing?

I assume you are talking about this sentence:

   Clients MUST support
   retrieval of referenced LogoTypeData with the HTTP/2 [RFC7540] and
   the HTTPS/2 with TLS [RFC8740]. 

It seems too soon to add a MUST for HTTP/3.

However, it does seem reasonable to add something like:

   Clients MUST support
   retrieval of referenced LogoTypeData with the HTTP/2 [RFC7540] and
   the HTTPS/2 with TLS [RFC8740], or subsequent versions of these
   protocols.

> The table also indicates the support requirements for image	

Sure.  Minor tweak, I suggest:

   The table also indicates the support
   requirements these image formats.

> A.2. ASN.1 Module with 2002 Syntax

I suggest:

and then right before the module:

   Note that [NEW-ASN1] was published in 2021, and all of the features
   used in this module are backward compatible with the specification
   that was published in 2002.

Russ

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 29 Mar 2022 12:39:27 +0200

I would like to add something I brought up in an internal discussion
that never made it to the list.

In my experiences of UI and accessibility is that it is actually a big
deal to support images with aids (audio) to support blind people.

However, providing audio files is not how this works. At least not
anywhere I look.

The way this works IMO is that you provide textual information with an
image combined with language declaration. (e.g. alt and lang attributes
in HTML). You then allow the end user to choose how to consume this
content dependent on the user's local setting.

The advantages over audio files are quite obvious as we want the end
user to select voice, read speed etc, not to mention how much effort
would go into making actual voice recordings in all relevant languages.

Fortunately it would be very ease to fix this in 3709bis. Allowing text
based audio data could be enabled/supported by the following minor updates:

1) Allow "text/plain;charset=UTF-8" as audio media type and define this
to mean descriptive text of the image that may be consumed by the end
user's local speech engine or accessibility tools.

2) Specify that when textbased audio data is provided, implementations
SHOULD specify language using LogotypeAudioInfo

3) Extend definition of LogotypeAudioInfo and add that the value 0 =
unspecified for the parameters fileSize, playTime and channels

Change 3 is necessary to allow specification of language with sensible
values for the mandatory fileSize, playTime and channels parameters.

None of these changes should break existing implementations, but would
allow audio support in a meaningful way.

/Stefan

---

From: Russ Housley <[email-masked]>
Date: Tue, 29 Mar 2022 11:35:59 -0400

> 0) s4.1 calls out HTTP/2, but says nothing about HTTP/3. HTTP/3 is in AUTH48 now - worth a mention for future proofing?

I'd like to revise my previous response to this comment.  The just published RFC 9205, provides guidance about specifying the use of HTTP (see Section 4.1):

   Specifications should use [HTTP] as the primary reference for HTTP;
   it is not necessary to reference all of the specifications in the
   HTTP suite unless there are specific reasons to do so (e.g., a
   particular feature is called out).

[HTTP] = RFC 9110.

This seems to say that RFC 3709bis should say:

  Clients MUST support retrieval of referenced LogoTypeData with the
  HTTP [RFC9110] and the HTTP with TLS [RFC8446], or subsequent
  versions of these protocols.

Russ

---

From: Sean Turner <[email-masked]>
Date: Tue, 29 Mar 2022 14:59:12 -0400

> On Mar 29, 2022, at 11:35, Russ Housley <[email-masked]> wrote:
> 
> Sean:
> 

I think that would work nicely!

spt

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 30 Mar 2022 00:46:35 -0400

> and respond with any comments or concerns on the mail list.

I didn't respond directly to this message, but i did look at the draft
and offered many comments and suggestions on a separate thread in this
WG.

I don't think this draft ready to move on to the IESG in its current
form.  There are internal contradictions, significant structural and
terminology clarifications at least, not to mention potentially
significant security issues (a potential phishing channel) and a decent
range of privacy issues that are either unrepresented or swept under the
run.

I do think it's important to update RFC 3709, but i don't think this
draft update has been workshopped or reviewed enough to be a reasonable
update yet.

        --dkg

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 30 Mar 2022 00:32:31 -0400

Hi Stefan--

> would go into making actual voice recordings in all relevant languages.

I agree that automated reading of textual information about the
certificate seems preferable from an accessibility perspective.

> unspecified for the parameters fileSize, playTime and channels

This seems like one plausible approach.  Another approach would be to
add an optional "alt text" equivalent field (altText [5] UTF8String
OPTIONAL) to the LogotypeImageInfo.  Or maybe it belongs in
LogotypeDetails, since an altText might be relevant for either images or
audio.

One more approach would be to expect the certificate renderer to parse
the parts of the certificate that are relevant to path validation.  That
is, inject no new data in the certificate, but document a convention for
how an X.509 certificate can be converted into a text string of a given
language, in a specific context.

I'm not sure how to evaluate among these three (four?) different
options.  the last option certainly seems appealing in that we don't
need to define new wire format structures or their semantics; and, it
would be a win for folks with vision or hearing difficulties as well,
because in addition to looking at logotype, they probably want to
understand something about how the validation worked (or didn't work).

           --dkg

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 30 Mar 2022 15:03:26 +0200

We need to keep backwards capability and something that makes sense
within the current structure of the extension.

I see no alternative that match those criteria and therefore I would
prefer to stick with the proposed solutions, or none at all.

/Stefan

---

From: Russ Housley <[email-masked]>
Date: Wed, 30 Mar 2022 14:40:56 -0400

I agree.  If this had been a common tractice when RFC 3709 was written, the suggestion by DKG would be clean, but it is not backward compatible.

Russ

> On Mar 30, 2022, at 9:03 AM, Stefan Santesson <[email-masked]> wrote:
>

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 30 Mar 2022 12:54:55 -0400

> within the current structure of the extension.

Agreed.  and i'll acknowledge that I don't understand ASN.1 parsers well
enough to know whether adding a field to LogotypeImageInfo would break
existing parsers.  If it does, then obviously that's not a good option,
and i withdraw the suggestion.

> prefer to stick with the proposed solutions, or none at all.

I agree that adding a textual fallback is worthwhile.  I don't much care
whether the textual fallback is structured/described as an "audio"
fallback or an "image" fallback -- maybe text/plain;charset=UTF could be
valid mediaType for both?  We definitely have a pretty established
history of "alt text" in other domains.

      --dkg

---

From: Russ Housley <[email-masked]>
Date: Thu, 31 Mar 2022 16:55:14 -0400

The WG Last Call for this document ends today.  Thanks for all of the comments.  The authors are working to resolve them.  There are several that need further discussion, and we hope to resolve them in the next few weeks.  We will ask Tim to make a consensus call once they have been resolved.

For the I-D authors,
  Russ