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

[Alanna Paloma <[e-mail]>]

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
>> 
>