Re: [auth48] [AD] AUTH48: RFC-to-be 9447 <draft-ietf-acme-authority-token-09> for your review
Roman Danyliw <rdd@cert.org> Mon, 14 August 2023 16:13 UTC
Return-Path: <rdd@cert.org>
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 7827DC1519BD; Mon, 14 Aug 2023 09:13:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Level:
X-Spam-Status: No, score=-2.107 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, RCVD_IN_ZEN_BLOCKED_OPENDNS=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 (1024-bit key) header.d=cert.org
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 AW3FzHrHcD_H; Mon, 14 Aug 2023 09:13:29 -0700 (PDT)
Received: from USG02-BN3-obe.outbound.protection.office365.us (mail-bn3usg02on0728.outbound.protection.office365.us [IPv6:2001:489a:2202:c::728]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95FBFC1519B8; Mon, 14 Aug 2023 09:13:29 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector5401; d=microsoft.com; cv=none; b=Pg+8eZYJuCnZU8ZX0YFW/beP9h+QeVyQSVcYE7+5WxLSQ0dYZxLDSW9G4eZ6Flu10zUS8TyslBdvkJempwg/CK/bLvsjl6VYEoDeEhFVOKwxIrqC1LFWgOmYVfe9J+iN5tiwZpH92RTkG7VlLwN5ssZxRrZmSMwtP8P38Ym3zrErYLujEsN2xXldeyjrs2Zs3BA6f1NfRhP5hUAeuXJTGF00pr1BIPYl12qo8gsHI4F9CSHhVvdgw61XHRb/rrBwZ8NJvFq31QcYHfm67NHTuM76LJYGVB/UcXiuCzbVU90PUK/koHY8BvhwcQ9e+2uEwgY76cFQgyww1yuGMT81Ig==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector5401; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=8hmDnoEu3xxc2YAt28+jSY0N4DFyRAyzMgkqT73bU0g=; b=U0r/SPGDgv/y5jc+Fch2kOZkxtVwJ57Mii/UVX21JNTQu1CCSw+N5RLoESLI0myj5XPF7bBgLfPaQSmJMF2dJcNfUSoVR1/R/r08dpnn0VvgjRcr0FBA40RSpLOz10CbCYjkyofvMZUDgQgWSRhNP3fLOGlAy4IL5sJliOeBdX0IgIIIz8nLcVGFnY1cP03ha/ijfL/tZmQ6uDSf4Rwn5CME2DBx1OtP7Ccezkx035bcGX14LAk8L3nQiI1shibds6cqv+WRZWeaZQSziAom4LN4WaHENWyfw16eHvsd/1tvNIcVp4/5nuj2PX5VjMFB08av/S9q0X2UPM8QhCypcg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cert.org; dmarc=pass action=none header.from=cert.org; dkim=pass header.d=cert.org; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8hmDnoEu3xxc2YAt28+jSY0N4DFyRAyzMgkqT73bU0g=; b=o7Ao7ye6UMf6Jm2wnQSoaW9E3GDk8kgWYModG+6wMvofTOLsb8JDljE/kOn6qwuVqFnRWmh1bcMY1I2jbo5lpVz7A96ko2Dy2ZvwZaqrPjNuai3eZ5R8NP6VHgkbbjIxV+xzC5pzu+1VIDupi+Wt8DSXi3t0KoV89L5/ye2CetM=
Received: from BN2P110MB1107.NAMP110.PROD.OUTLOOK.COM (2001:489a:200:168::11) by BN2P110MB1173.NAMP110.PROD.OUTLOOK.COM (2001:489a:200:179::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6652.33; Mon, 14 Aug 2023 16:13:23 +0000
Received: from BN2P110MB1107.NAMP110.PROD.OUTLOOK.COM ([fe80::2bb4:7f24:a90f:44d9]) by BN2P110MB1107.NAMP110.PROD.OUTLOOK.COM ([fe80::2bb4:7f24:a90f:44d9%7]) with mapi id 15.20.6652.033; Mon, 14 Aug 2023 16:13:23 +0000
From: Roman Danyliw <rdd@cert.org>
To: Alanna Paloma <apaloma@amsl.com>, "Peterson, Jon" <Jon.Peterson@transunion.com>, "davidhancock.ietf@gmail.com" <davidhancock.ietf@gmail.com>, "chris-ietf@chriswendt.net" <chris-ietf@chriswendt.net>
CC: 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>, "jon.peterson@team.neustar" <jon.peterson@team.neustar>, "rfc-editor@rfc-editor.org" <rfc-editor@rfc-editor.org>, "rsalz@akamai.com" <rsalz@akamai.com>
Thread-Topic: [AD] AUTH48: RFC-to-be 9447 <draft-ietf-acme-authority-token-09> for your review
Thread-Index: AQHZzG/lgJWVePr3sEaxcxYZ9c7bfq/p+5PA
Date: Mon, 14 Aug 2023 16:13:23 +0000
Message-ID: <BN2P110MB1107D007B5B8C529F5CCD31FDC17A@BN2P110MB1107.NAMP110.PROD.OUTLOOK.COM>
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>
In-Reply-To: <6BDA66BE-0E85-42F8-B0B4-20E68DD30216@amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=cert.org;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: BN2P110MB1107:EE_|BN2P110MB1173:EE_
x-ms-office365-filtering-correlation-id: 019a8f7c-a265-497c-1411-08db9ce1629a
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: oe19CibNWAUbD8052WbdI5W5xUgxu/dys+EOeAOTqO4olJsEavS/hsX5JcmCCATXGwgdUe0KbOx1OkBv6FX8DWt90eCAKHp6EhwgqOAEVxKsyRxGUvE2dATpRe1uyxVOtNA5pb4HdBr5TNoqZQKLAy3HI7+WGU9IEtJ9VKzfJ6qW7SolK8L6IJR3ejeaL70wYxBqxeAdFe6Ixg4Yy+7dqcbZ/LYRY2jl9zNRa6WcLFjFhWJn88o1Q/gRWjneNg33yD+UUAEA2CHmPkgh2MkYIMW2/sn8eNtL1rlhI8a7BrjSURjSmeaD9d8kqtRHW1ounivcdmywRmEsIl/nwO3ohvac7FiGGW/t5aKvILb5cDjcKVsQjmSaT0p3Til5mRxh7mYafmNoL7DGHIe81XoQT/Bxhoow/5QWjr5amk1/NDu6D050t79M7rZt7jWJ3JF+KcNFcMq36/Y+zo8FpFD8Kl/hqauqVmSpwK0Rp4UDODpn8Gq0rnxl0tBR9QcYLWD/qPG4y/HsnkOJYaK4s42eZyD/6ZBejYGRSk5HK8kfRUMIdBaPFclQ9cxwo/AC4p4pMeMmSt9XZb5s6HVHGlHB85tbPB4qoCd8jPAeCbdHPQ3e2zu9KEpWA5bO9vPtou6UMuarSSW0AqYhus6fstS7YQ==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN2P110MB1107.NAMP110.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(13230028)(39830400003)(136003)(396003)(366004)(186006)(451199021)(1800799006)(66946007)(66556008)(64756008)(66476007)(66446008)(76116006)(110136005)(19627235002)(41300700001)(54906003)(8936002)(8676002)(52536014)(5660300002)(508600001)(7416002)(71200400001)(2906002)(966005)(53546011)(30864003)(9686003)(6506007)(83380400001)(26005)(7696005)(4326008)(82960400001)(55016003)(38070700005)(122000001)(38100700002)(86362001)(33656002)(41320700001)(559001)(579004)(19607625013); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: RbJo0J5DNO0Hrc/08da4COHY+Ca9UEEFhgjvu0UsCEZl4+9EfKt4MfqVftvs07De1LIxzKwnpvZ+TSSIXQJ557AwQdKpDOqrXq0lTtSS3s98LIQxvUnfSc9RwMguzBz6gvDg6dN729izDvXoZuX5QWxSlIMlTM44MBEJrAaTIXoyH3/S2NUGX5YDHq1lz/3t9Mku0juDliwPyooVVTQR/ADuoQTPvg6ZUrnOAVL72QMso9hkRotDPQ55IpoHVJoK3+M2wT/zqRORizRYlvxnFWJsAeVUeOU2GeiO/yhJCiZCOIM0NPW4nmIWdw77KC+1bxuX3kvIVWhO51n7paa6kHNWWGoc/4Ar1ZVfBeGfydO72u8RzYgKCXlrg73Hnlx2+1ZMDMF14egymAh20deIAHyKIBCju+hk7c/ff2i5qTA=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: cert.org
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BN2P110MB1107.NAMP110.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: 019a8f7c-a265-497c-1411-08db9ce1629a
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Aug 2023 16:13:23.8492 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 95a9dce2-04f2-4043-995d-1ec3861911c6
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN2P110MB1173
Archived-At: <https://mailarchive.ietf.org/arch/msg/auth48archive/UDoJPHGbfW8CtMwnyP08qyfr-6E>
Subject: Re: [auth48] [AD] 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: Mon, 14 Aug 2023 16:13:34 -0000
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