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

Alanna Paloma <apaloma@amsl.com> Fri, 28 April 2023 21:20 UTC

Return-Path: <apaloma@amsl.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 239B2C1516EB; Fri, 28 Apr 2023 14:20:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level:
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham 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 py1Umgg2N8j4; Fri, 28 Apr 2023 14:20:08 -0700 (PDT)
Received: from c8a.amsl.com (c8a.amsl.com [4.31.198.40]) (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 7E5ECC151531; Fri, 28 Apr 2023 14:20:08 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 67FD4424FFE3; Fri, 28 Apr 2023 14:20:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Att0zxQRYkgd; Fri, 28 Apr 2023 14:20:08 -0700 (PDT)
Received: from amss-mbp.attlocal.net (unknown [IPv6:2600:1700:bac0:1070:94bc:d512:1ffb:8162]) by c8a.amsl.com (Postfix) with ESMTPSA id EDECD424CD3F; Fri, 28 Apr 2023 14:20:07 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
From: Alanna Paloma <apaloma@amsl.com>
In-Reply-To: <BN2P110MB1107931A2A88712CFA848322DC6B9@BN2P110MB1107.NAMP110.PROD.OUTLOOK.COM>
Date: Fri, 28 Apr 2023 14:20:07 -0700
Cc: RFC Editor <rfc-editor@rfc-editor.org>, "lamps-ads@ietf.org" <lamps-ads@ietf.org>, LAMPS Chairs <lamps-chairs@ietf.org>, Tim Hollebeek <tim.hollebeek@digicert.com>, "auth48archive@rfc-editor.org" <auth48archive@rfc-editor.org>, Carsten Bormann <cabo@tzi.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <4967EBF0-15E1-4581-933D-59794C3B02B3@amsl.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> <D6676E31-7723-448B-901B-46ED9E1F0822@vigilsec.com> <56202EBA-3786-4223-9558-80CAFDBBCAA3@amsl.com> <400DDF13-5BCC-4F00-912B-FB301A8EF395@vigilsec.com> <E205A72C-8BDE-4501-8BBA-D3185DADBAA9@amsl.com> <BN2P110MB1107931A2A88712CFA848322DC6B9@BN2P110MB1107.NAMP110.PROD.OUTLOOK.COM>
To: Roman Danyliw <rdd@cert.org>, Russ Housley <housley@vigilsec.com>, Stefan Santesson <sts@aaa-sec.com>, Trevor Freeman <frtrevor@amazon.com>, Leonard Rosenthol <lrosenth@adobe.com>
X-Mailer: Apple Mail (2.3608.120.23.2.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/auth48archive/CRyVShNmI20pYVoWQhjpnZck0rI>
Subject: Re: [auth48] 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: Fri, 28 Apr 2023 21:20:12 -0000

All,

We have noted Roman’s approval on the AUTH48 status page:
https://www.rfc-editor.org/auth48/rfc9399

With that, we have now received all necessary approvals and consider AUTH48 complete.

Thank you for your attention and guidance during the AUTH48 process.
We will move this document forward in the publication process at this time.

RFC Editor/ap

> On Apr 28, 2023, at 11:35 AM, Roman Danyliw <rdd@cert.org> wrote:
> 
> Good afternoon Alanna!
> 
> This looks good to me to proceed.
> 
> Thanks,
> Roman
> 
>> -----Original Message-----
>> From: Alanna Paloma <apaloma@amsl.com>
>> Sent: Wednesday, April 26, 2023 12:10 PM
>> To: Russ Housley <housley@vigilsec.com>; Roman Danyliw <rdd@cert.org>
>> Cc: RFC Editor <rfc-editor@rfc-editor.org>; Stefan Santesson <sts@aaa-
>> sec.com>; 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>
>> 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 <housley@vigilsec.com> 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 <apaloma@amsl.com> 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 <housley@vigilsec.com> 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 <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
>>>>>> 
>>>>> 
>>>> 
>>> 
>