Re: [auth48] AUTH48: RFC-to-be 9447 <draft-ietf-acme-authority-token-09> for your review
David Hancock <davidhancock.ietf@gmail.com> Tue, 22 August 2023 22:38 UTC
Return-Path: <davidhancock.ietf@gmail.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 48D2BC1527A6; Tue, 22 Aug 2023 15:38:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.104
X-Spam-Level:
X-Spam-Status: No, score=-2.104 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 QF_55pdEUUcY; Tue, 22 Aug 2023 15:38:09 -0700 (PDT)
Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 B8807C1526F4; Tue, 22 Aug 2023 15:38:09 -0700 (PDT)
Received: by mail-io1-xd2d.google.com with SMTP id ca18e2360f4ac-79246bb4131so41919239f.3; Tue, 22 Aug 2023 15:38:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1692743888; x=1693348688; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=FzOCpGkKINPkX1Ji9DHf4UR39X3ZFctxiKBcWsCvNzs=; b=luWzwGQImtCeGDymSk5ACd49LFeywoUwCwJD/vEF5xgSXHIQwzW4i1RMyw1yMcs6Mr FDVAW7f9MDdtElC6bbNUlTBEEof+p362l+0vi7IXLMQj8YqGiymQDev78TD0tQ+x2Rzy 4P5Su1dAh2CnZ6/Dm9VJydvNadON+PiSKnvhrMmDreVsWcR3Yey5jbozI1CvoMV/X07s TkCPjjKLq47MIetwVr2Myj5idx201F8sMLaihKASZLNrVwskX7J5NOYzuy7gg2UcLn5n rCTl8u2cRwrdBGI7+N1tK7A2avCJHPKC95BBGiAVOVQG7/ZpTz9Aei1atEw5kbPD/7dw 5rcw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692743888; x=1693348688; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=FzOCpGkKINPkX1Ji9DHf4UR39X3ZFctxiKBcWsCvNzs=; b=PbuEevnIjO7YrvYhAy4gBj/6wjb9/bKu4g3oQiYYRuCkWhzi0vMyEsdgh3nG/ekLQu 1L/yMumhXgXCYEAPuUDmJGqnxplqonE3gc20SrLvGyMOXwGWw1pJT40TyWlpL1LjtK6l s7uAhYmTrZ2PcUV4fP3PuMHq7eqivFygQTVCRAnEGZQzXZMH+A20adnENd4oVw9a0KZE dM9afnP4t1xNTycmuu8//alm7bT2F9crOEs8yyfmhpucs+LqWhXWA7dV79VMqFNEbRgE ZrAZQBkawivqLxCRJgdwB2BltcUr4sXEp9yxoeinAnPHtMgT0I1pNpMIkOM85N8y+crj xXLQ==
X-Gm-Message-State: AOJu0YyB4yeCtcc2oOgHCWjMVjVqfpmKWcQzP5HNT3tHKvbaegxvqPTh G4GogBBF+/OMSFCRFCFti3H+Ux4rsLTTfiNxmCE=
X-Google-Smtp-Source: AGHT+IEm3esjn3cEZOEj3Q1sMMLXCP26me2mQylDmF0cRZKEFJqhnQ7pKrFgtw0WwQxHPyZHNbufnK+0S7TiH401ImA=
X-Received: by 2002:a6b:dd08:0:b0:783:3899:e1d0 with SMTP id f8-20020a6bdd08000000b007833899e1d0mr1302790ioc.6.1692743888072; Tue, 22 Aug 2023 15:38:08 -0700 (PDT)
MIME-Version: 1.0
References: <20230725055613.60C6C3E8AF@rfcpa.amsl.com> <CO6PR17MB49784028ECB433846741F881FD08A@CO6PR17MB4978.namprd17.prod.outlook.com> <CAHBDyN7bz0dAyadJGWXkXp8yZ0056rYNygiAJcy5tnHvrWz3Mw@mail.gmail.com> <50B02C9D-21D0-4A03-8E74-D88F86D14B3A@amsl.com> <6BDA66BE-0E85-42F8-B0B4-20E68DD30216@amsl.com> <BN2P110MB1107D007B5B8C529F5CCD31FDC17A@BN2P110MB1107.NAMP110.PROD.OUTLOOK.COM> <C2C69C0D-5567-4108-ABD9-D585FFE33FE3@amsl.com> <72C5655D-5451-4030-B588-A0AA68B63D12@amsl.com> <108E448B-5F2B-482E-87F6-00B09F1B2B03@chriswendt.net> <CAM7yphY6m3JzyHcFd-6GTyCsK2nAbbNbR0Yh0=3A2=iqsF_yUA@mail.gmail.com> <EDE352F3-B802-4B6D-B265-CD65C04E6047@amsl.com>
In-Reply-To: <EDE352F3-B802-4B6D-B265-CD65C04E6047@amsl.com>
From: David Hancock <davidhancock.ietf@gmail.com>
Date: Tue, 22 Aug 2023 16:37:57 -0600
Message-ID: <CAM7yphZvPq9rq2s3=aUw+8KRrKXbDM-u9YufWe+TSEU6OdgDig@mail.gmail.com>
To: Alanna Paloma <apaloma@amsl.com>
Cc: Chris Wendt <chris-ietf@chriswendt.net>, "jon.peterson@team.neustar" <jon.peterson@team.neustar>, Roman Danyliw <rdd@cert.org>, "Peterson, Jon" <Jon.Peterson@transunion.com>, Mary Barnes <mary.ietf.barnes@gmail.com>, "acme-ads@ietf.org" <acme-ads@ietf.org>, "acme-chairs@ietf.org" <acme-chairs@ietf.org>, "auth48archive@rfc-editor.org" <auth48archive@rfc-editor.org>, "rfc-editor@rfc-editor.org" <rfc-editor@rfc-editor.org>, "rsalz@akamai.com" <rsalz@akamai.com>
Content-Type: multipart/alternative; boundary="00000000000024f75f06038aa634"
Archived-At: <https://mailarchive.ietf.org/arch/msg/auth48archive/DBuX0lCAsQAoikmkgu18jnguaY4>
Subject: Re: [auth48] AUTH48: RFC-to-be 9447 <draft-ietf-acme-authority-token-09> 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: Tue, 22 Aug 2023 22:38:14 -0000
The text file still shows my company affiliation as "Comcast". But I assume that's a glitch, since the pdf and html files show the correct affiliation. So I approve the document for publication. Thanks, David On Mon, Aug 21, 2023 at 4:13 PM Alanna Paloma <apaloma@amsl.com> wrote: > Hi Chris and David, > > Thank you for your replies. We have noted Chris’s approval on the AUTH48 > status page and updated David’s company affiliation accordingly. > > The files are available here: > https://www.rfc-editor.org/authors/rfc9447.xml > https://www.rfc-editor.org/authors/rfc9447.txt > https://www.rfc-editor.org/authors/rfc9447.pdf > https://www.rfc-editor.org/authors/rfc9447.html > > The relevant diff files have been posted here: > https://www.rfc-editor.org/authors/rfc9447-diff.html (comprehensive diff) > https://www.rfc-editor.org/authors/rfc9447-auth48diff.html (AUTH48 > changes) > https://www.rfc-editor.org/authors/rfc9447-lastdiff.html (last version > to this one) > > We will await approvals from David and John before continuing with the > publication process. > > For the AUTH48 status of this document, please see: > https://www.rfc-editor.org/auth48/rfc9447 > > Thank you, > RFC Editor/ap > > > On Aug 21, 2023, at 12:27 PM, David Hancock <davidhancock.ietf@gmail.com> > wrote: > > > > Please update my company affiliation from Comcast to Somos Inc. in two > places... > > > > --- > > On title page, authors list: > > OLD: > > D. Hancock > > Comcast > > C. Wendt > > Somos > > > > NEW: > > D. Hancock > > C.Wendt > > Somos > > > > On the last page, list of Authors' Addresses > > OLD: > > David Hancock > > Comcast > > Email: davidhancock.ietf@gmail.com > > > > NEW: > > David Hancock > > Somos > > Email: davidhancock.ietf@gmail.com > > --- > > Thanks, > > David > > > > > > On Mon, Aug 21, 2023 at 12:29 PM Chris Wendt <chris-ietf@chriswendt.net> > wrote: > > Everything looks good, i approve. > > > > > On Aug 21, 2023, at 1:27 PM, Alanna Paloma <apaloma@amsl.com> wrote: > > > > > > Hi John, David, and Chris, > > > > > > This is a friendly reminder that we await you reviews and approvals > before continuing with the publication process. > > > > > > Additionally, please let us know if/how you would like the “type” > attribute set for the <sourcecode> elements in this document: > > >>> 6) <!--[rfced] Please review the "type" attribute of each sourcecode > element > > >>> in the XML file to ensure correctness. If the current list of > preferred > > >>> values for "type" ( > https://www.rfc-editor.org/materials/sourcecode-types.txt) > > >>> does not contain an applicable type, then feel free to let us > > >>> know. Also, it is acceptable to leave the "type" attribute not set. > > >>> --> > > >>> > > >>> <JFP> I’m not aware I’m using sourcecode as an element in the XML. > These are all figure/artwork blocks. > > >> > > >> Currently, there are 3 instances of the <sourcecode> element in this > document: > > >> https://www.rfc-editor.org/authors/rfc9447.html#section-4-6 > > >> https://www.rfc-editor.org/authors/rfc9447.html#section-4-8 > > >> https://www.rfc-editor.org/authors/rfc9447.html#section-5.1-2 > > >> > > >> For background, "The <artwork> element should not be used for source > code and formal languages, the <sourcecode> element should be used > instead.” (https://authors.ietf.org/en/rfcxml-vocabulary#artwork). > <sourcecode> is used to contain code that compiles or does not; it can be > one of the preferred “type" values or no type at all. Please review and let > us know if/how you would like the “type” attribute set. > > > > > > The files are available here: > > > https://www.rfc-editor.org/authors/rfc9447.xml > > > https://www.rfc-editor.org/authors/rfc9447.txt > > > https://www.rfc-editor.org/authors/rfc9447.pdf > > > https://www.rfc-editor.org/authors/rfc9447.html > > > > > > AUTH48 diff: > > > https://www.rfc-editor.org/authors/rfc9447-auth48diff.html > > > > > > Comprehensive diffs: > > > https://www.rfc-editor.org/authors/rfc9447-diff.html > > > https://www.rfc-editor.org/authors/rfc9447-rfcdiff.html > > > > > > For the AUTH48 status of this document, please see: > > > https://www.rfc-editor.org/auth48/rfc9447 > > > > > > Thank you, > > > RFC Editor/ap > > > > > > > > >> On Aug 14, 2023, at 9:58 AM, Alanna Paloma <apaloma@amsl.com> wrote: > > >> > > >> Hi Roman, > > >> > > >> Thank you for your reply. Your approval has been noted on the AUTH48 > status page: > > >> https://www.rfc-editor.org/auth48/rfc9447 > > >> > > >> Best regards, > > >> RFC Editor/ap > > >> > > >>> On Aug 14, 2023, at 9:13 AM, Roman Danyliw <rdd@cert.org> wrote: > > >>> > > >>> Hi! > > >>> > > >>> Approved. > > >>> > > >>> Thanks, > > >>> Roman > > >>> > > >>>> -----Original Message----- > > >>>> From: Alanna Paloma <apaloma@amsl.com> > > >>>> Sent: Friday, August 11, 2023 12:21 PM > > >>>> To: Roman Danyliw <rdd@cert.org>; Peterson, Jon > > >>>> <Jon.Peterson@transunion.com>; davidhancock.ietf@gmail.com; chris- > > >>>> ietf@chriswendt.net > > >>>> Cc: Mary Barnes <mary.ietf.barnes@gmail.com>; acme-ads@ietf.org; > acme- > > >>>> chairs@ietf.org; auth48archive@rfc-editor.org; > jon.peterson@team.neustar; > > >>>> rfc-editor@rfc-editor.org; rsalz@akamai.com > > >>>> Subject: Re: [AD] AUTH48: RFC-to-be 9447 > <draft-ietf-acme-authority-token- > > >>>> 09> for your review > > >>>> > > >>>> Jon, David, Chris, and Roman*, > > >>>> > > >>>> *Roman (AD) - This is a friendly reminder that we await your review > and > > >>>> approval of the changes to the RFC 2119/8174 keywords in Sections 4 > and 7 > > >>>> and the removal of RFCs 3986 and 4648 from the Normative References > > >>>> section. These updates can be seen in this diff file: > > >>>> https://www.rfc-editor.org/authors/rfc9447-auth48diff.html > > >>>> > > >>>> Authors - Please let us know if/how you would like the “type” > attribute set for > > >>>> the <sourcecode> elements in this document: > > >>>>>> 6) <!--[rfced] Please review the "type" attribute of each > sourcecode > > >>>>>> element in the XML file to ensure correctness. If the current > list of > > >>>>>> preferred values for "type" > > >>>>>> (https://www.rfc-editor.org/materials/sourcecode-types.txt) > > >>>>>> does not contain an applicable type, then feel free to let us > know. > > >>>>>> Also, it is acceptable to leave the "type" attribute not set. > > >>>>>> --> > > >>>>>> > > >>>>>> <JFP> I’m not aware I’m using sourcecode as an element in the > XML. These > > >>>> are all figure/artwork blocks. > > >>>>> > > >>>>> Currently, there are 3 instances of the <sourcecode> element in > this > > >>>> document: > > >>>>> https://www.rfc-editor.org/authors/rfc9447.html#section-4-6 > > >>>>> https://www.rfc-editor.org/authors/rfc9447.html#section-4-8 > > >>>>> https://www.rfc-editor.org/authors/rfc9447.html#section-5.1-2 > > >>>>> > > >>>>> For background, "The <artwork> element should not be used for > source code > > >>>> and formal languages, the <sourcecode> element should be used > instead.” > > >>>> (https://authors.ietf.org/en/rfcxml-vocabulary#artwork). > <sourcecode> is used > > >>>> to contain code that compiles or does not; it can be one of the > preferred “type" > > >>>> values or no type at all. Please review and let us know if/how you > would like > > >>>> the “type” attribute set. > > >>>> > > >>>> > > >>>> We will await any further changes as well approvals from Jon, > David, Chris, and > > >>>> *Roman prior to moving forward in the publication process. > > >>>> > > >>>> The files are available here: > > >>>> https://www.rfc-editor.org/authors/rfc9447.xml > > >>>> https://www.rfc-editor.org/authors/rfc9447.txt > > >>>> https://www.rfc-editor.org/authors/rfc9447.pdf > > >>>> https://www.rfc-editor.org/authors/rfc9447.html > > >>>> > > >>>> AUTH48 diff: > > >>>> https://www.rfc-editor.org/authors/rfc9447-auth48diff.html > > >>>> > > >>>> Comprehensive diffs: > > >>>> https://www.rfc-editor.org/authors/rfc9447-diff.html > > >>>> https://www.rfc-editor.org/authors/rfc9447-rfcdiff.html > > >>>> > > >>>> For the AUTH48 status of this document, please see: > > >>>> https://www.rfc-editor.org/auth48/rfc9447 > > >>>> > > >>>> Thank you, > > >>>> RFC Editor/ap > > >>>> > > >>>>> On Aug 4, 2023, at 8:56 AM, Alanna Paloma <apaloma@amsl.com> > wrote: > > >>>>> > > >>>>> Hi Jon, Mary, and Roman* > > >>>>> > > >>>>> *Roman (AD) - Please review and approve of the changes to the RFC > > >>>> 2119/8174 keywords in Sections 4 and 7 and the removal of RFCs 3986 > and > > >>>> 4648 from the Normative References section. These updates can be > seen in this > > >>>> diff file: > > >>>>> https://www.rfc-editor.org/authors/rfc9447-auth48diff.html > > >>>>> > > >>>>> Authors - Thank you for your replies. We have updated the files > accordingly. > > >>>> Mary’s approval has been noted on the AUTH48 status page, and we > assume > > >>>> her assent to changes from the other coauthors unless we hear > otherwise. > > >>>>> > > >>>>>> 6) <!--[rfced] Please review the "type" attribute of each > sourcecode > > >>>>>> element in the XML file to ensure correctness. If the current > list of > > >>>>>> preferred values for "type" > > >>>>>> (https://www.rfc-editor.org/materials/sourcecode-types.txt) > > >>>>>> does not contain an applicable type, then feel free to let us > know. > > >>>>>> Also, it is acceptable to leave the "type" attribute not set. > > >>>>>> --> > > >>>>>> > > >>>>>> <JFP> I’m not aware I’m using sourcecode as an element in the > XML. These > > >>>> are all figure/artwork blocks. > > >>>>> > > >>>>> Currently, there are 3 instances of the <sourcecode> element in > this > > >>>> document: > > >>>>> https://www.rfc-editor.org/authors/rfc9447.html#section-4-6 > > >>>>> https://www.rfc-editor.org/authors/rfc9447.html#section-4-8 > > >>>>> https://www.rfc-editor.org/authors/rfc9447.html#section-5.1-2 > > >>>>> > > >>>>> For background, "The <artwork> element should not be used for > source code > > >>>> and formal languages, the <sourcecode> element should be used > instead.” > > >>>> (https://authors.ietf.org/en/rfcxml-vocabulary#artwork). > <sourcecode> is used > > >>>> to contain code that compiles or does not; it can be one of the > preferred “type" > > >>>> values or no type at all. Please review and let us know if/how you > would like > > >>>> the “type” attribute set. > > >>>>> > > >>>>> The files have been posted here (please refresh): > > >>>>> https://www.rfc-editor.org/authors/rfc9447.xml > > >>>>> https://www.rfc-editor.org/authors/rfc9447.txt > > >>>>> https://www.rfc-editor.org/authors/rfc9447.html > > >>>>> https://www.rfc-editor.org/authors/rfc9447.pdf > > >>>>> > > >>>>> The relevant diff files have been posted here: > > >>>>> https://www.rfc-editor.org/authors/rfc9447-diff.html > (comprehensive > > >>>>> diff) https://www.rfc-editor.org/authors/rfc9447-auth48diff.html > > >>>>> (AUTH48 changes) > > >>>>> > > >>>>> Please review the document carefully and contact us with any > further > > >>>> updates you may have. Note that we do not make changes once a > document is > > >>>> published as an RFC. > > >>>>> > > >>>>> We will await approvals from Jon, David, Chris, and *Roman (AD) > prior to > > >>>> moving this document forward in the publication process. > > >>>>> > > >>>>> For the AUTH48 status of this document, please see: > > >>>>> https://www.rfc-editor.org/auth48/rfc9447 > > >>>>> > > >>>>> Thank you, > > >>>>> RFC Editor/ap > > >>>>> > > >>>>>> On Aug 3, 2023, at 10:39 AM, Mary Barnes < > mary.ietf.barnes@gmail.com> > > >>>> wrote: > > >>>>>> > > >>>>>> I think the document is fine with consideration of Jon’s comments. > > >>>>>> > > >>>>>> Mary > > >>>>>> > > >>>>>> On Thu, Aug 3, 2023 at 7:26 AM Peterson, Jon > > >>>> <Jon.Peterson@transunion.com> wrote: > > >>>>>> Please see my responses marked as <JFP> below. Thanks! > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> From: rfc-editor@rfc-editor.org <rfc-editor@rfc-editor.org> > > >>>>>> Date: Tuesday, July 25, 2023 at 1:56 AM > > >>>>>> To: jon.peterson@team.neustar <jon.peterson@team.neustar>, > > >>>>>> mary.ietf.barnes@gmail.com <mary.ietf.barnes@gmail.com>, > > >>>>>> davidhancock.ietf@gmail.com <davidhancock.ietf@gmail.com>, > > >>>>>> chris-ietf@chriswendt.net <chris-ietf@chriswendt.net> > > >>>>>> Cc: rfc-editor@rfc-editor.org <rfc-editor@rfc-editor.org>, > > >>>>>> acme-ads@ietf.org <acme-ads@ietf.org>, acme-chairs@ietf.org > > >>>>>> <acme-chairs@ietf.org>, rsalz@akamai.com <rsalz@akamai.com>, > > >>>>>> rdd@cert.org <rdd@cert.org>, auth48archive@rfc-editor.org > > >>>>>> <auth48archive@rfc-editor.org> > > >>>>>> Subject: Re: AUTH48: RFC-to-be 9447 > > >>>>>> <draft-ietf-acme-authority-token-09> for your review > > >>>>>> > > >>>>>> Authors, > > >>>>>> > > >>>>>> While reviewing this document during AUTH48, please resolve (as > > >>>> necessary) the following questions, which are also in the XML file. > > >>>>>> > > >>>>>> 1) <!--[rfced] Please note the the title of the document has been > updated as > > >>>> follows. > > >>>>>> The abbreviation has been expanded per Section 3.6 of RFC 7322 > ("RFC Style > > >>>> Guide"). > > >>>>>> Please review. > > >>>>>> > > >>>>>> Original: > > >>>>>> ACME Challenges Using an Authority Token > > >>>>>> > > >>>>>> Current: > > >>>>>> Automated Certificate Management Environment (ACME) Challenges > Using > > >>>>>> an Authority Token > > >>>>>> --> > > >>>>>> > > >>>>>> > > >>>>>> <JFP> OK > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> 2) <!--[rfced] For clarity, should "Authority" be "Token > Authority" here? > > >>>>>> > > >>>>>> Original: > > >>>>>> For example, imagine a case where an Authority for DNS names knows > > >>>>>> that a client is eligible to receive certificates for > > >>>> "https://urldefense.proofpoint.com/v2/url?u=http- > > >>>> 3A__example.com&d=DwIFaQ&c=7gn0PlAmraV3zr- > > >>>> k385KhKAz9NTx0dwockj5vIsr5Sw&r=rQo6AhlF8tKhxgONBTTPp2dKudYXajoA6N > > >>>> 78vvkOkzA&m=H9shfntLUEToiZuf9zJVeNTFWR__v4jo7gIYfcjo6g_RlQcEpklq74D > > >>>> moqBuqfP-&s=FSP3n0qEZdE4lnN1EPjigIr1blbyoY7QMUl1ZNCvZpQ&e= " > > >>>>>> and "https://urldefense.proofpoint.com/v2/url?u=http- > > >>>> 3A__example.net&d=DwIFaQ&c=7gn0PlAmraV3zr- > > >>>> k385KhKAz9NTx0dwockj5vIsr5Sw&r=rQo6AhlF8tKhxgONBTTPp2dKudYXajoA6N > > >>>> 78vvkOkzA&m=H9shfntLUEToiZuf9zJVeNTFWR__v4jo7gIYfcjo6g_RlQcEpklq74D > > >>>> moqBuqfP-&s=4D7dUBWOxRL7tTWU2ITbtLplCX7E9Qd3UwLDnUwylWo&e= ". > > >>>>>> > > >>>>>> Perhaps: > > >>>>>> For example, imagine a case where a Token Authority for DNS names > > >>>> knows > > >>>>>> that a client is eligible to receive certificates for > > >>>> "https://urldefense.proofpoint.com/v2/url?u=http- > > >>>> 3A__example.com&d=DwIFaQ&c=7gn0PlAmraV3zr- > > >>>> k385KhKAz9NTx0dwockj5vIsr5Sw&r=rQo6AhlF8tKhxgONBTTPp2dKudYXajoA6N > > >>>> 78vvkOkzA&m=H9shfntLUEToiZuf9zJVeNTFWR__v4jo7gIYfcjo6g_RlQcEpklq74D > > >>>> moqBuqfP-&s=FSP3n0qEZdE4lnN1EPjigIr1blbyoY7QMUl1ZNCvZpQ&e= " > > >>>>>> and "https://urldefense.proofpoint.com/v2/url?u=http- > > >>>> 3A__example.net&d=DwIFaQ&c=7gn0PlAmraV3zr- > > >>>> k385KhKAz9NTx0dwockj5vIsr5Sw&r=rQo6AhlF8tKhxgONBTTPp2dKudYXajoA6N > > >>>> 78vvkOkzA&m=H9shfntLUEToiZuf9zJVeNTFWR__v4jo7gIYfcjo6g_RlQcEpklq74D > > >>>> moqBuqfP-&s=4D7dUBWOxRL7tTWU2ITbtLplCX7E9Qd3UwLDnUwylWo&e= ". > > >>>>>> > > >>>>>> <JFP> OK. Below is not correct. > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> Similarly (for the reverse), should "Token" be "Authority Token" > here? > > >>>>>> Or, perhaps using just one word was intended to mitigate > confusion? > > >>>>>> > > >>>>>> Original: > > >>>>>> ...an ACME server can use the > > >>>>>> binding to determine that a Token presented by a client was in > fact > > >>>>>> granted by the Token Authority based on a request from the client, > > >>>>>> and not from some other entity. > > >>>>>> > > >>>>>> Perhaps: > > >>>>>> ...an ACME server can use the > > >>>>>> binding to determine that an Authority Token presented by a > client was in > > >>>> fact > > >>>>>> granted by the Token Authority based on a request from the client, > > >>>>>> and not from some other entity. > > >>>>>> --> > > >>>>>> > > >>>>>> > > >>>>>> 3) <!--[rfced] As "OPTIONALLY" is not a key word that appears in > RFC > > >>>>>> 2119, may this sentence be rephrased to use "OPTIONAL"? > > >>>>>> > > >>>>>> Original: > > >>>>>> For this ACME Authority Token usage of JWT, the payload of the JWT > > >>>>>> OPTIONALLY contain an "iss" indicating the Token Authority that > > >>>>>> generated the token, if the "x5u" or "x5c" element in the header > does > > >>>>>> not already convey that information... > > >>>>>> > > >>>>>> Perhaps: > > >>>>>> For this ACME Authority Token usage of JWT, it is OPTIONAL for the > > >>>>>> payload of the JWT to contain an "iss" indicating the Token > Authority that > > >>>>>> generated the token if the "x5u" or "x5c" element in the header > does > > >>>>>> not already convey that information... > > >>>>>> --> > > >>>>>> > > >>>>>> > > >>>>>> <JFP> OK > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> 4) <!--[rfced] We note that RFC 8226 does not contain mention of > "tkvalue". > > >>>>>> Please review and let us know if/how this citation should be > updated. > > >>>>>> > > >>>>>> Original: > > >>>>>> Following the example of > [I-D.ietf-acme-authority-token-tnauthlist], > > >>>>>> the "tktype" identifier type could be the TNAuthList, with a > > >>>>>> "tkvalue" as defined in [RFC8226] that the Token Authority is > > >>>>>> attesting. > > >>>>>> --> > > >>>>>> > > >>>>>> > > >>>>>> <JFP> Good catch. We’re not saying that the “tkvalue” element is > defined in > > >>>> RFC8226, but that the value of the “tkvalue” element is a > TNAuthList has > > >>>> defiend in RFC8226. So maybe: > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> The “tktype” identifier type could be the TNAuthList (as defined > in > > >>>> [RFC8226]), which would be the value for the “tkvalue” element that > the Token > > >>>> Authority is attesting. > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> 5) <!--[rfced] In Section 4, the following lines in sourcecode > > >>>>>> exceeded the 69-character limit. Line breaks have been added as > > >>>>>> follows; please review and let us know if these lines should > appear in a > > >>>> different manner. > > >>>>>> > > >>>>>> Original (lines 407 and 408): > > >>>>>> > > >>>> > "atc":{"tktype":"TnAuthList","tkvalue":"F83n2a...avn27DN3==","fingerprint": > > >>>>>> "SHA256 > > >>>> 56:3E:CF:AE:83:CA:4D:15:B0:29:FF:1B:71:D3:BA:B9:19:81:F8:50: > > >>>>>> 9B:DF:4A:D4:39:72:E2:B1:F0:B9:38:E3"} > > >>>>>> > > >>>>>> Current: > > >>>>>> "atc":{"tktype":"TnAuthList","tkvalue":"F83n2a...avn27DN3==", > > >>>>>> "fingerprint":"SHA256 56:3E:CF:AE:83:CA:4D:15:B0:29:FF:1B:71:D3: > > >>>>>> BA:B9:19:81:F8:50:9B:DF:4A:D4:39:72:E2:B1:F0:B9:38:E3"} > > >>>>>> > > >>>>>> > > >>>>>> Original (lines 424 and 425): > > >>>>>> > "atc":{"tktype":"TnAuthList","tkvalue":"F83n2a...avn27DN3==","ca":true, > > >>>>>> "fingerprint":"SHA256 > > >>>> 56:3E:CF:AE:83:CA:4D:15:B0:29:FF:1B:71:D3:BA:B9:19:81:F8:50: > > >>>>>> 9B:DF:4A:D4:39:72:E2:B1:F0:B9:38:E3"} } > > >>>>>> > > >>>>>> Current: > > >>>>>> "atc":{"tktype":"TnAuthList","tkvalue":"F83n2a...avn27DN3==", > > >>>>>> "ca":true,"fingerprint":"SHA256 > 56:3E:CF:AE:83:CA:4D:15:B0:29:FF:1B: > > >>>>>> 71:D3:BA:B9:19:81:F8:50:9B:DF:4A:D4:39:72:E2:B1:F0:B9:38:E3"} } > > >>>>>> --> > > >>>>>> > > >>>>>> > > >>>>>> <JFP> OK. > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> 6) <!--[rfced] Please review the "type" attribute of each > sourcecode > > >>>>>> element in the XML file to ensure correctness. If the current > list of > > >>>>>> preferred values for "type" > > >>>>>> (https://www.rfc-editor.org/materials/sourcecode-types.txt) > > >>>>>> does not contain an applicable type, then feel free to let us > know. > > >>>>>> Also, it is acceptable to leave the "type" attribute not set. > > >>>>>> --> > > >>>>>> > > >>>>>> > > >>>>>> <JFP> I’m not aware I’m using sourcecode as an element in the > XML. These > > >>>> are all figure/artwork blocks. > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> 7) <!-- [rfced] RFC 7231 has been obsoleted by RFC 9110. May we > > >>>>>> replace RFC 7231 with RFC 9110 in this sentence? > > >>>>>> > > >>>>>> Original: > > >>>>>> In order to request an Authority Token from a Token Authority, a > > >>>>>> client sends a HTTPS POST request [RFC7231] . > > >>>>>> --> > > >>>>>> > > >>>>>> > > >>>>>> <JFP> OK. > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> 8) <!--[rfced] Per RFCs 2119 and 8174, may we update "SHOULD not" > to > > >>>> "SHOULD NOT" > > >>>>>> in the sentence below? > > >>>>>> > > >>>>>> Original: > > >>>>>> ACME services relying > > >>>>>> on Authority Tokens SHOULD not issue certificates with a longer > > >>>>>> expiry than the expiry of the Authority Token. > > >>>>>> --> > > >>>>>> > > >>>>>> > > >>>>>> <JFP> OK. > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> 9) <!--[rfced] The following references are not cited in the text. > > >>>>>> Please let us know where they should be cited or if these > references > > >>>>>> should be deleted from the References section. > > >>>>>> > > >>>>>> [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, > "Uniform > > >>>>>> Resource Identifier (URI): Generic Syntax", STD 66, > > >>>>>> RFC 3986, DOI 10.17487/RFC3986, January 2005, > > >>>>>> <https://urldefense.com/v3/__https://www.rfc- > > >>>> > editor.org/info/rfc3986__;!!N14HnBHF!57eJm6xYZhvvvv3CCsAFzcQ8b3OIuakb > > >>>> 08QLJ9xkR4ZfvCOjGflOJJjW2zx4mNN-RY-PWy14m14Ao11d1hY5bSGkYIcdPQ$ > > >>>>> . > > >>>>>> > > >>>>>> [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data > > >>>>>> Encodings", RFC 4648, DOI 10.17487/RFC4648, October > 2006, > > >>>>>> <https://urldefense.com/v3/__https://www.rfc- > > >>>> > editor.org/info/rfc4648__;!!N14HnBHF!57eJm6xYZhvvvv3CCsAFzcQ8b3OIuakb > > >>>> 08QLJ9xkR4ZfvCOjGflOJJjW2zx4mNN-RY-PWy14m14Ao11d1hY5bSH2BxuGBg$ > > >>>>> . > > >>>>>> --> > > >>>>>> > > >>>>>> > > >>>>>> <JFP> Um, I suppose we don’t need those cited. > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> 10) <!--[rfced] Throughout the text, "ACME Identifier Type", "ACME > > >>>>>> Identifier type", and "ACME identifier type" appear were used > > >>>>>> inconsistently. We have updated all occurrences to capitalized, > i.e., "ACME > > >>>> Identifier Type". > > >>>>>> Please review and let us know if you prefer otherwise. > > >>>>>> --> > > >>>>>> > > >>>>>> > > >>>>>> <JFP> I only see one instance of that construction where “type” is > > >>>> uncapitalized in the -09 XML source (and none where “identifier” is > > >>>> uncapitalized in that construction), but forcing capitalization is > fine. > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> 11) <!-- [rfced] FYI - We have added expansions for the following > > >>>>>> abbreviations per Section 3.6 of RFC 7322 ("RFC Style Guide"). > Please > > >>>>>> review each expansion in the document carefully to ensure > correctness. > > >>>>>> > > >>>>>> JSON Web Signature (JWS) > > >>>>>> Telephone Number Authorization List (TNAuthList) > > >>>>>> --> > > >>>>>> > > >>>>>> > > >>>>>> <JFP> OK. > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> 12) <!-- [rfced] Please review the "Inclusive Language" portion of > > >>>>>> the online Style Guide > > >>>>>> <https://urldefense.com/v3/__https://www.rfc- > > >>>> > editor.org/styleguide/part2/*inclusive_language__;Iw!!N14HnBHF!57eJm6xYZh > > >>>> vvvv3CCsAFzcQ8b3OIuakb08QLJ9xkR4ZfvCOjGflOJJjW2zx4mNN-RY- > > >>>> PWy14m14Ao11d1hY5bSHw1FLyNA$ > and let us know if any changes are > > >>>> needed. > > >>>>>> > > >>>>>> Note that our script did not flag any words in particular, but > this > > >>>>>> should still be reviewed as a best practice. > > >>>>>> --> > > >>>>>> > > >>>>>> > > >>>>>> <JFP> OK. > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> Thank you. > > >>>>>> > > >>>>>> > > >>>>>> <JFP> Thanks! > > >>>>>> > > >>>>>> > > >>>>>> RFC Editor/ar/ar > > >>>>>> > > >>>>>> > > >>>>>> On Jul 24, 2023, rfc-editor@rfc-editor.org wrote: > > >>>>>> > > >>>>>> *****IMPORTANT***** > > >>>>>> > > >>>>>> Updated 2023/07/24 > > >>>>>> > > >>>>>> RFC Author(s): > > >>>>>> -------------- > > >>>>>> > > >>>>>> Instructions for Completing AUTH48 > > >>>>>> > > >>>>>> Your document has now entered AUTH48. Once it has been reviewed > and > > >>>>>> approved by you and all coauthors, it will be published as an RFC. > > >>>>>> If an author is no longer available, there are several remedies > > >>>>>> available as listed in the FAQ (https://www.rfc-editor.org/faq). > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> You and you coauthors are responsible for engaging other parties > > >>>>>> (e.g., Contributors or Working Group) as necessary before > providing > > >>>>>> your approval. > > >>>>>> > > >>>>>> Planning your review > > >>>>>> --------------------- > > >>>>>> > > >>>>>> Please review the following aspects of your document: > > >>>>>> > > >>>>>> * RFC Editor questions > > >>>>>> > > >>>>>> Please review and resolve any questions raised by the RFC Editor > > >>>>>> that have been included in the XML file as comments marked as > > >>>>>> follows: > > >>>>>> > > >>>>>> <!-- [rfced] ... --> > > >>>>>> > > >>>>>> These questions will also be sent in a subsequent email. > > >>>>>> > > >>>>>> * Changes submitted by coauthors > > >>>>>> > > >>>>>> Please ensure that you review any changes submitted by your > > >>>>>> coauthors. We assume that if you do not speak up that you agree > to > > >>>>>> changes submitted by your coauthors. > > >>>>>> > > >>>>>> * Content > > >>>>>> > > >>>>>> Please review the full content of the document, as this cannot > > >>>>>> change once the RFC is published. Please pay particular > attention to: > > >>>>>> - IANA considerations updates (if applicable) > > >>>>>> - contact information > > >>>>>> - references > > >>>>>> > > >>>>>> * Copyright notices and legends > > >>>>>> > > >>>>>> Please review the copyright notice and legends as defined in RFC > > >>>>>> 5378 and the Trust Legal Provisions > > >>>>>> > > >>>>>> (TLP – > https://urldefense.com/v3/__https://trustee.ietf.org/license- > > >>>> info/__;!!N14HnBHF!57eJm6xYZhvvvv3CCsAFzcQ8b3OIuakb08QLJ9xkR4ZfvCOj > > >>>> GflOJJjW2zx4mNN-RY-PWy14m14Ao11d1hY5bSE9Ks8eAw$ ). > > >>>>>> > > >>>>>> * Semantic markup > > >>>>>> > > >>>>>> Please review the markup in the XML file to ensure that elements > of > > >>>>>> content are correctly tagged. For example, ensure that > <sourcecode> > > >>>>>> and <artwork> are set correctly. See details at > > >>>>>> <https://urldefense.com/v3/__https://authors.ietf.org/rfcxml- > > >>>> vocabulary__;!!N14HnBHF!57eJm6xYZhvvvv3CCsAFzcQ8b3OIuakb08QLJ9xkR4Z > > >>>> fvCOjGflOJJjW2zx4mNN-RY-PWy14m14Ao11d1hY5bSH6ck1Vaw$ >. > > >>>>>> > > >>>>>> * Formatted output > > >>>>>> > > >>>>>> Please review the PDF, HTML, and TXT files to ensure that the > > >>>>>> formatted output, as generated from the markup in the XML file, is > > >>>>>> reasonable. Please note that the TXT will have formatting > > >>>>>> limitations compared to the PDF and HTML. > > >>>>>> > > >>>>>> > > >>>>>> Submitting changes > > >>>>>> ------------------ > > >>>>>> > > >>>>>> To submit changes, please reply to this email using ‘REPLY ALL’ as > > >>>>>> all the parties CCed on this message need to see your changes. The > > >>>>>> parties > > >>>>>> include: > > >>>>>> > > >>>>>> * your coauthors > > >>>>>> > > >>>>>> * rfc-editor@rfc-editor.org (the RPC team) > > >>>>>> > > >>>>>> * other document participants, depending on the stream (e.g., > > >>>>>> IETF Stream participants are your working group chairs, the > > >>>>>> responsible ADs, and the document shepherd). > > >>>>>> > > >>>>>> * auth48archive@rfc-editor.org, which is a new archival mailing > list > > >>>>>> to preserve AUTH48 conversations; it is not an active discussion > > >>>>>> list: > > >>>>>> > > >>>>>> * More info: > > >>>>>> > > >>>>>> > https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/iet > > >>>>>> f-announce/yb6lpIGh- > > >>>> 4Q9l2USxIAe6P8O4Zc__;!!N14HnBHF!57eJm6xYZhvvvv3CC > > >>>>>> sAFzcQ8b3OIuakb08QLJ9xkR4ZfvCOjGflOJJjW2zx4mNN-RY- > > >>>> PWy14m14Ao11d1hY5bS > > >>>>>> Gj2dWypw$ > > >>>>>> > > >>>>>> * The archive itself: > > >>>>>> > > >>>>>> > https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/browse/ > > >>>>>> > > >>>> auth48archive/__;!!N14HnBHF!57eJm6xYZhvvvv3CCsAFzcQ8b3OIuakb08QLJ9x > > >>>> kR > > >>>>>> 4ZfvCOjGflOJJjW2zx4mNN-RY-PWy14m14Ao11d1hY5bSGJaGSrxw$ > > >>>>>> > > >>>>>> > > >>>>>> * Note: If only absolutely necessary, you may temporarily opt out > > >>>>>> of the archiving of messages (e.g., to discuss a sensitive > matter). > > >>>>>> If needed, please add a note at the top of the message that you > > >>>>>> have dropped the address. When the discussion is concluded, > > >>>>>> auth48archive@rfc-editor.org will be re-added to the CC list > and > > >>>>>> its addition will be noted at the top of the message. > > >>>>>> > > >>>>>> You may submit your changes in one of two ways: > > >>>>>> > > >>>>>> An update to the provided XML file > > >>>>>> — OR — > > >>>>>> An explicit list of changes in this format > > >>>>>> > > >>>>>> Section # (or indicate Global) > > >>>>>> > > >>>>>> OLD: > > >>>>>> old text > > >>>>>> > > >>>>>> NEW: > > >>>>>> new text > > >>>>>> > > >>>>>> You do not need to reply with both an updated XML file and an > > >>>>>> explicit list of changes, as either form is sufficient. > > >>>>>> > > >>>>>> We will ask a stream manager to review and approve any changes > that > > >>>>>> seem beyond editorial in nature, e.g., addition of new text, > deletion > > >>>>>> of text, and technical changes. Information about stream managers > > >>>>>> can be found in the FAQ. Editorial changes do not require > approval from a > > >>>> stream manager. > > >>>>>> > > >>>>>> > > >>>>>> Approving for publication > > >>>>>> -------------------------- > > >>>>>> > > >>>>>> To approve your RFC for publication, please reply to this email > > >>>>>> stating that you approve this RFC for publication. Please use > ‘REPLY > > >>>>>> ALL’, as all the parties CCed on this message need to see your > approval. > > >>>>>> > > >>>>>> > > >>>>>> Files > > >>>>>> ----- > > >>>>>> > > >>>>>> The files are available here: > > >>>>>> > > >>>>>> > > >>>>>> > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc944 > > >>>>>> > > >>>> 7.xml__;!!N14HnBHF!57eJm6xYZhvvvv3CCsAFzcQ8b3OIuakb08QLJ9xkR4ZfvCOj > > >>>> Gf > > >>>>>> lOJJjW2zx4mNN-RY-PWy14m14Ao11d1hY5bSGAUv8cyg$ > > >>>>>> > > >>>>>> > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc944 > > >>>>>> > > >>>> 7.html__;!!N14HnBHF!57eJm6xYZhvvvv3CCsAFzcQ8b3OIuakb08QLJ9xkR4ZfvC > > >>>> OjG > > >>>>>> flOJJjW2zx4mNN-RY-PWy14m14Ao11d1hY5bSG1gSddzQ$ > > >>>>>> > > >>>>>> > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc944 > > >>>>>> > > >>>> 7.pdf__;!!N14HnBHF!57eJm6xYZhvvvv3CCsAFzcQ8b3OIuakb08QLJ9xkR4ZfvCOj > > >>>> Gf > > >>>>>> lOJJjW2zx4mNN-RY-PWy14m14Ao11d1hY5bSG1VFJRqA$ > > >>>>>> > > >>>>>> > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc944 > > >>>>>> > > >>>> 7.txt__;!!N14HnBHF!57eJm6xYZhvvvv3CCsAFzcQ8b3OIuakb08QLJ9xkR4ZfvCOj > > >>>> Gf > > >>>>>> lOJJjW2zx4mNN-RY-PWy14m14Ao11d1hY5bSHQISexhQ$ > > >>>>>> > > >>>>>> Diff file of the text: > > >>>>>> > > >>>>>> > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc944 > > >>>>>> 7- > > >>>> diff.html__;!!N14HnBHF!57eJm6xYZhvvvv3CCsAFzcQ8b3OIuakb08QLJ9xkR4Zf > > >>>>>> vCOjGflOJJjW2zx4mNN-RY-PWy14m14Ao11d1hY5bSHex2QhVw$ > > >>>>>> > > >>>>>> > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc944 > > >>>>>> 7- > > >>>> rfcdiff.html__;!!N14HnBHF!57eJm6xYZhvvvv3CCsAFzcQ8b3OIuakb08QLJ9xkR > > >>>>>> 4ZfvCOjGflOJJjW2zx4mNN-RY-PWy14m14Ao11d1hY5bSHQGMBVAQ$ (side > > >>>> by > > >>>>>> side) > > >>>>>> > > >>>>>> Diff of the XML: > > >>>>>> > > >>>>>> > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc944 > > >>>>>> 7- > > >>>> xmldiff1.html__;!!N14HnBHF!57eJm6xYZhvvvv3CCsAFzcQ8b3OIuakb08QLJ9xk > > >>>>>> R4ZfvCOjGflOJJjW2zx4mNN-RY-PWy14m14Ao11d1hY5bSEF8uI1zw$ > > >>>>>> > > >>>>>> The following files are provided to facilitate creation of your > own > > >>>>>> diff files of the XML. > > >>>>>> > > >>>>>> Initial XMLv3 created using XMLv2 as input: > > >>>>>> > > >>>>>> > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc944 > > >>>>>> > > >>>> > 7.original.v2v3.xml__;!!N14HnBHF!57eJm6xYZhvvvv3CCsAFzcQ8b3OIuakb08QL > > >>>>>> J9xkR4ZfvCOjGflOJJjW2zx4mNN-RY-PWy14m14Ao11d1hY5bSG1XnidrQ$ > > >>>>>> > > >>>>>> XMLv3 file that is a best effort to capture v3-related format > updates > > >>>>>> only: > > >>>>>> > > >>>>>> > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc944 > > >>>>>> > > >>>> 7.form.xml__;!!N14HnBHF!57eJm6xYZhvvvv3CCsAFzcQ8b3OIuakb08QLJ9xkR4Z > > >>>> fv > > >>>>>> COjGflOJJjW2zx4mNN-RY-PWy14m14Ao11d1hY5bSFZcRTyPA$ > > >>>>>> > > >>>>>> > > >>>>>> Tracking progress > > >>>>>> ----------------- > > >>>>>> > > >>>>>> The details of the AUTH48 status of your document are here: > > >>>>>> > > >>>>>> > https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9447 > > >>>>>> > > >>>> __;!!N14HnBHF!57eJm6xYZhvvvv3CCsAFzcQ8b3OIuakb08QLJ9xkR4ZfvCOjGflOJ > > >>>> Jj > > >>>>>> W2zx4mNN-RY-PWy14m14Ao11d1hY5bSGd-lMzUg$ > > >>>>>> > > >>>>>> > > >>>>>> Please let us know if you have any questions. > > >>>>>> > > >>>>>> Thank you for your cooperation, > > >>>>>> > > >>>>>> RFC Editor > > >>>>>> > > >>>>>> -------------------------------------- > > >>>>>> RFC9447 (draft-ietf-acme-authority-token-09) > > >>>>>> > > >>>>>> Title : ACME Challenges Using an Authority Token > > >>>>>> Author(s) : J. Peterson, M. Barnes, D. Hancock, C. Wendt > > >>>>>> WG Chair(s) : Deb Cooley, Deb Cooley, Yoav Nir > > >>>>>> Area Director(s) : Roman Danyliw, Paul Wouters > > >>>>>> > > >>>>>> -- > > >>>>>> Sent from Gmail Mobile > > >>>>> > > >>> > > >> > > > > > > >
- [auth48] AUTH48: RFC-to-be 9447 <draft-ietf-acme-… rfc-editor
- Re: [auth48] AUTH48: RFC-to-be 9447 <draft-ietf-a… rfc-editor
- Re: [auth48] AUTH48: RFC-to-be 9447 <draft-ietf-a… Alanna Paloma
- Re: [auth48] AUTH48: RFC-to-be 9447 <draft-ietf-a… Peterson, Jon
- Re: [auth48] AUTH48: RFC-to-be 9447 <draft-ietf-a… Mary Barnes
- [auth48] [AD] Re: AUTH48: RFC-to-be 9447 <draft-i… Alanna Paloma
- Re: [auth48] [AD] AUTH48: RFC-to-be 9447 <draft-i… Alanna Paloma
- Re: [auth48] [AD] AUTH48: RFC-to-be 9447 <draft-i… Roman Danyliw
- Re: [auth48] AUTH48: RFC-to-be 9447 <draft-ietf-a… Alanna Paloma
- Re: [auth48] AUTH48: RFC-to-be 9447 <draft-ietf-a… Alanna Paloma
- Re: [auth48] AUTH48: RFC-to-be 9447 <draft-ietf-a… Chris Wendt
- Re: [auth48] AUTH48: RFC-to-be 9447 <draft-ietf-a… David Hancock
- Re: [auth48] AUTH48: RFC-to-be 9447 <draft-ietf-a… Alanna Paloma
- Re: [auth48] AUTH48: RFC-to-be 9447 <draft-ietf-a… David Hancock
- Re: [auth48] AUTH48: RFC-to-be 9447 <draft-ietf-a… Alanna Paloma
- Re: [auth48] AUTH48: RFC-to-be 9447 <draft-ietf-a… Alanna Paloma
- Re: [auth48] AUTH48: RFC-to-be 9447 <draft-ietf-a… Alanna Paloma
- Re: [auth48] AUTH48: RFC-to-be 9447 <draft-ietf-a… Peterson, Jon
- Re: [auth48] AUTH48: RFC-to-be 9447 <draft-ietf-a… Alanna Paloma