Re: [auth48] [AD] AUTH48: RFC-to-be 9399 <draft-ietf-lamps-rfc3709bis-10> for your review

[Roman Danyliw <[e-mail]>]

Good afternoon Alanna!

This looks good to me to proceed.

Thanks,
Roman

> -----Original Message-----
> From: Alanna Paloma <[e-mail]>
> Sent: Wednesday, April 26, 2023 12:10 PM
> To: Russ Housley <[e-mail]>; Roman Danyliw <[e-mail]>
> Cc: RFC Editor <[e-mail]>; Stefan Santesson <sts@aaa-
> sec.com>; Trevor Freeman <[e-mail]>; Leonard Rosenthol
> <[e-mail]>; [e-mail]; LAMPS Chairs <lamps-
> [e-mail]>; Tim Hollebeek <[e-mail]>;
> [e-mail]; Carsten Bormann <[e-mail]>
> Subject: Re: [AD] [auth48] AUTH48: RFC-to-be 9399 <draft-ietf-lamps-
> rfc3709bis-10> for your review
> 
> Hi Russ and *Roman,
> 
> *Roman (AD) - In addition, please review and approve of the added text in
> Appendix C, along with the updates in Sections 4.1 and 4.3 and Appendices A.2,
> B.3, and B.4 and the removal of RFC 6838 as a normative reference in the diff
> file below:
> https://www.rfc-editor.org/authors/rfc9399-auth48diff.html
> 
> Russ - Thank you for your reply. We have added this item to the list in Appendix
> C.
> 
> The files have been posted here (please refresh):
> https://www.rfc-editor.org/authors/rfc9399.xml
> https://www.rfc-editor.org/authors/rfc9399.txt
> https://www.rfc-editor.org/authors/rfc9399.html
> https://www.rfc-editor.org/authors/rfc9399.pdf
> 
> The relevant diff files have been posted here:
> https://www.rfc-editor.org/authors/rfc9399-diff.html (comprehensive diff)
> https://www.rfc-editor.org/authors/rfc9399-auth48diff.html (AUTH48
> changes) https://www.rfc-editor.org/authors/rfc9399-lastdiff.html (last version
> to this one)
> 
> For the AUTH48 status of this document, please see:
> https://www.rfc-editor.org/auth48/rfc9399
> 
> Thank you,
> RFC Editor/ap
> 
> > On Apr 25, 2023, at 12:42 PM, Russ Housley <[e-mail]> wrote:
> >
> > Thanks for making this change.  I think this needs to be added to the list of
> things that have been changed in Appendix C.
> >
> > I suggest:
> >
> > OLD:
> >
> >   *  Require support for the HTTP scheme (http://...) URI and the HTTPS
> >      scheme (https://...) URI.
> >
> >   *  Require support for the compressed SVG image format with the
> >      image/svg+xml+gzip media type.
> >
> > NEW:
> >
> >   *  Require support for the HTTP scheme (http://...) URI and the HTTPS
> >      scheme (https://...) URI.
> >
> >   *  Provide syntax of the "data" URI scheme using modern ABNF.
> >
> >   *  Require support for the compressed SVG image format with the
> >      image/svg+xml+gzip media type.
> >
> > Thanks,
> >  Russ
> >
> >
> >> On Apr 25, 2023, at 12:17 PM, Alanna Paloma <[e-mail]> wrote:
> >>
> >> Hi Russ and *Roman,
> >>
> >> *Roman (AD) - Please review and approve of the updates in Sections 4.1 and
> 4.3 and Appendices A.2, B.3, and B.4, as well as the removal of RFC 6838 as a
> normative reference in the diff file below:
> >> https://www.rfc-editor.org/authors/rfc9399-auth48diff.html
> >>
> >> We have updated the files accordingly. Once we have received approvals
> from Stefan, Trevor, and *Roman, we will move this document forward in the
> publication process.
> >>
> >> The files have been posted here (please refresh):
> >> https://www.rfc-editor.org/authors/rfc9399.xml
> >> https://www.rfc-editor.org/authors/rfc9399.txt
> >> https://www.rfc-editor.org/authors/rfc9399.html
> >> https://www.rfc-editor.org/authors/rfc9399.pdf
> >>
> >> The relevant diff files have been posted here:
> >> https://www.rfc-editor.org/authors/rfc9399-diff.html (comprehensive
> >> diff) https://www.rfc-editor.org/authors/rfc9399-auth48diff.html
> >> (AUTH48 changes)
> >> https://www.rfc-editor.org/authors/rfc9399-lastdiff.html (last
> >> version to this one)
> >>
> >> For the AUTH48 status of this document, please see:
> >> https://www.rfc-editor.org/auth48/rfc9399
> >>
> >> Thank you,
> >> RFC Editor/ap
> >>
> >>> On Apr 24, 2023, at 3:02 PM, Russ Housley <[e-mail]> wrote:
> >>>
> >>> I have chased this down, including Errata ID 2045.  The following addresses
> the concern that was raised about the ABNF.  The NEW ABNF compiles properly
> using BAP (after you chase down all of the dependencies).
> >>>
> >>> OLD:
> >>>
> >>> If the logotype image is provided through direct addressing, then
> >>> the image MAY be stored within the logotype certificate extension
> >>> using the "data" scheme [RFC2397].  The syntax of the "data" URI
> >>> scheme defined is included here for convenience:
> >>>
> >>>    dataurl    := "data:" [ mediatype ] [ ";base64" ] "," data
> >>>    mediatype  := [ type "/" subtype ] *( ";" parameter )
> >>>    data       := *urlchar
> >>>    parameter  := attribute "=" value
> >>>
> >>> NEW:
> >>>
> >>> If the logotype image is provided through direct addressing, then
> >>> the image MAY be stored within the logotype certificate extension
> >>> using the "data" scheme [RFC2397].  The syntax of the "data" URI
> >>> scheme is shown below, which incorporates Errata ID 2045 and uses
> >>> modern ABNF
> >>> [RFC5234]:
> >>>
> >>>    dataurl    = "data:" [ media-type ] [ ";base64" ] "," data
> >>>    data       = *(reserved / unreserved / escaped)
> >>>    reserved   = ";" / "/" / "?" / ":" / "@" / "&" / "=" / "+" /
> >>>                 "$" / ","
> >>>    unreserved = alphanum / mark
> >>>    alphanum   = ALPHA / DIGIT
> >>>    mark       = "-" / "_" / "." / "!" / "~" / "*" / "'" / "(" / ")"
> >>>    escaped    = "%" hex hex
> >>>    hex        = HEXDIG / "a" / "b" / "c" / "d" / "e" / "f"
> >>>
> >>> Where media-type is defined in Section 8.3.1 of [RFC9110]; and
> >>> ALPHA, DIGIT, and HEXDIG are defined in Appendix B.1 of [RFC5234].
> >>>
> >>> Russ
> >>>
> >>>
> >>>> On Apr 23, 2023, at 5:30 PM, Carsten Bormann <[e-mail]> wrote:
> >>>>
> >>>> On 23. Apr 2023, at 22:35, Russ Housley <[e-mail]> wrote:
> >>>>>
> >>>>> I think you are pointing out that the optional whitespace is not allowed
> in the [RFC2397] ABNF.  If you are saying more than that, I am missing it.
> >>>>
> >>>> Ah.  I was talking about a different form of BNF notation being used, not
> about a different grammar expressed in ABNF notation.
> >>>>
> >>>> The 989/1049/1341 BNF is using “:=“, where standard
> (822/2396/2234/5234) ABNF uses “=“.
> >>>> This alone should cause the tools to error out, which they did as Alanna
> mentioned.
> >>>> (The deviant BNF and ABNF otherwise look very similar, but I
> >>>> haven’t even looked for any other gratuitous changes, so I don’t
> >>>> know if there are any more.)
> >>>>
> >>>> Grüße, Carsten
> >>>>
> >>>
> >>
> >