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

Russ Housley <housley@vigilsec.com> Mon, 24 April 2023 22:02 UTC

Return-Path: <housley@vigilsec.com>
X-Original-To: auth48archive@ietfa.amsl.com
Delivered-To: auth48archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49683C151983; Mon, 24 Apr 2023 15:02:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I5NZxGYg8ENN; Mon, 24 Apr 2023 15:02:16 -0700 (PDT)
Received: from mail3.g24.pair.com (mail3.g24.pair.com [66.39.134.11]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C361BC151981; Mon, 24 Apr 2023 15:02:16 -0700 (PDT)
Received: from mail3.g24.pair.com (localhost [127.0.0.1]) by mail3.g24.pair.com (Postfix) with ESMTP id 87B65195927; Mon, 24 Apr 2023 18:02:15 -0400 (EDT)
Received: from [192.168.1.161] (unknown [96.241.2.243]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail3.g24.pair.com (Postfix) with ESMTPSA id 596C5195987; Mon, 24 Apr 2023 18:02:15 -0400 (EDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\))
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <386B68B0-2CC7-401C-8CB4-619C65CECBB1@tzi.org>
Date: Mon, 24 Apr 2023 18:02:14 -0400
Cc: Stefan Santesson <sts@aaa-sec.com>, "Roman D. Danyliw" <rdd@cert.org>, Trevor Freeman <frtrevor@amazon.com>, Leonard Rosenthol <lrosenth@adobe.com>, lamps-ads@ietf.org, LAMPS Chairs <lamps-chairs@ietf.org>, Tim Hollebeek <tim.hollebeek@digicert.com>, auth48archive@rfc-editor.org, Carsten Bormann <cabo@tzi.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <D6676E31-7723-448B-901B-46ED9E1F0822@vigilsec.com>
References: <20230407181524.E739B7FDC0@rfcpa.amsl.com> <F90558EB-F03B-4461-9EE5-1C220530D488@tzi.org> <dee8a7d7-c023-f07a-4776-ac3c395ee553@aaa-sec.com> <3F480C86-C862-4A47-8CE6-C3A6A069B574@tzi.org> <9CFDA284-E444-492A-8D21-8406B12DA6F3@vigilsec.com> <9ABA86A8-7F07-42F8-BF84-A0BF0124B1A0@tzi.org> <D087B817-E5E5-4D4D-814E-6096526523E2@vigilsec.com> <ACE9B926-FB1B-4ED2-973F-13B61E25AC59@tzi.org> <4C588A9B-A63E-447E-BA32-4FBED6B00A52@vigilsec.com> <EEF19E07-F362-412D-A9BC-BA7B94411B30@tzi.org> <D16DC362-9EBB-43CA-935E-A12FEF84F64C@vigilsec.com> <16BA8E25-8ACF-4DF5-8D24-773E2796D989@tzi.org> <0A24F906-7F87-43A9-8B5C-4049839FD969@vigilsec.com> <B624C581-49CB-473B-9133-89109C82741D@tzi.org> <D772A5DF-3C30-4596-A748-53CF04702BCE@vigilsec.com> <D21F6756-C2AD-4BD3-A483-A9E9A10E6158@tzi.org> <B866202C-3073-41AE-BD03-57AD0323503A@amsl.com> <0FD1353E-9DFE-434C-A975-C0509DB9777D@tzi.org> <B73DE7BE-4596-4AF7-812A-A4132CF52156@vigilsec.com> <386B68B0-2CC7-401C-8CB4-619C65CECBB1@tzi.org>
To: Alanna Paloma <apaloma@amsl.com>, RFC Editor <rfc-editor@rfc-editor.org>
X-Mailer: Apple Mail (2.3445.104.21)
X-Scanned-By: mailmunge 3.11 on 66.39.134.11
Archived-At: <https://mailarchive.ietf.org/arch/msg/auth48archive/aqcNhG6VENj4wM-I79YDGh9fuu8>
Subject: Re: [auth48] [AD] AUTH48: RFC-to-be 9399 <draft-ietf-lamps-rfc3709bis-10> for your review
X-BeenThere: auth48archive@rfc-editor.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Archiving AUTH48 exchanges between the RFC Production Center, the authors, and other related parties" <auth48archive.rfc-editor.org>
List-Unsubscribe: <https://mailman.rfc-editor.org/mailman/options/auth48archive>, <mailto:auth48archive-request@rfc-editor.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/auth48archive/>
List-Post: <mailto:auth48archive@rfc-editor.org>
List-Help: <mailto:auth48archive-request@rfc-editor.org?subject=help>
List-Subscribe: <https://mailman.rfc-editor.org/mailman/listinfo/auth48archive>, <mailto:auth48archive-request@rfc-editor.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Apr 2023 22:02:19 -0000

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 <cabo@tzi.org> wrote:
> 
> On 23. Apr 2023, at 22:35, Russ Housley <housley@vigilsec.com> 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
>