[Anima] FW: Antwort an Mahesh (BRSKI-AE AD review), war RE: Ich falle erst mal aus - Re: AD review of draft-ietf-anima-brski-ae-10

"Fries, Steffen" <steffen.fries@siemens.com> Mon, 03 June 2024 13:57 UTC

Return-Path: <steffen.fries@siemens.com>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27F24C169430; Mon, 3 Jun 2024 06:57:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=siemens.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 yMgA8x5_sWo6; Mon, 3 Jun 2024 06:56:57 -0700 (PDT)
Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2077.outbound.protection.outlook.com [40.107.22.77]) (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 584B1C1654EB; Mon, 3 Jun 2024 06:56:55 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=l9KS+wKPJncsBkoONP4bB0GwQZyykB+AyV8DPalAA3r8SZLJOYMXZbvOjCEwk0Kjc6UeEGMlSaO3TQshHNpJUSULO2wvIgIkZV2W+VfcFScY5Kpg7oPr3gaQ1a/8UYreIfdvKZryBngLOtiwsm0kRMxL11nqTNHq1xcf7a/0S+zaPGWJk7hYfCQwfFOmoVXi9G63PF1tjLlaqzhyskik8yPk5JAh0gGEPVjvPkN+fgVBXhn+qMFoJXS95Vp5sxU2EiIaeTy73rxHQLSk1ODOb43+9XLN6h/eZnXlntkCBwz0zhNp7qFPBox8fxz/Yby1lVGIkstcr0f3M2wQCUqAMQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; 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=fpmFMVUVLhx0RqVkRiRSMZpN43YmWczb17qD31doDuU=; b=A5cdVhv3E3dLabNBWzjBZ5q2vTopDCtf9YAo4NfdcISBbeRN+C7DhJy7W0zaEg8YGPhhksi6lCax12Y2nGtMXSEz+xd03s5N14T5HtuskyQVfZGkZQObVz9i5Fc1Eic/WGOWh5lWRBnT+bBAKedZWQnv5L6T3I8b6PsDH1ocAylIWtkJ9pL0NOuOkB/KxUjocXM95+2R08UdW7jr5ZTNhloLtsGRQ8ELoAYwGcyX1L/CT+jkxBBZcYs4wgNu+Wycl+GdqncKhSEDpsUrRkC3LT08e+DqYbtHj8lFaGn9BxtzMvihR6F9e7IKonMLI82rC9eQOPJRraM9IqPTB4kUoA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=siemens.com; dmarc=pass action=none header.from=siemens.com; dkim=pass header.d=siemens.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=siemens.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fpmFMVUVLhx0RqVkRiRSMZpN43YmWczb17qD31doDuU=; b=qsBkkUbg7qdENdkIk2zfrHItWV22bdPPFFQVfQIocNbCZlmpEO/VKAgZkZMmZvzdK/kn2FuDvUmPdZRaqi5TbO1gNgjrFyP2LXkDpjY9gd3mFUNgiNCbq5cOtWZ++UADtKheMLBGpOJxdRdxwrKB14fvpJJvXs2sqvGpVolXnwthaTgoFmNN472poJ49l2Wk3jtbt8GBnKmIaMdZRog5kSa4cCd1dJSDTWCmwRWKb+cJXv/q/gGI/Bi9eLbBQoZNy0VfM1wAbtS4Fs9rGUg9kSBsqPlr4Z/rOSqtDiPRUs3YIIpN/iEdIg4FnlreMLCRanlrxurcJZD5wrlOEcYxPg==
Received: from AS8PR10MB6337.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:20b:53f::19) by AS8PR10MB5901.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:20b:526::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7633.24; Mon, 3 Jun 2024 13:56:51 +0000
Received: from AS8PR10MB6337.EURPRD10.PROD.OUTLOOK.COM ([fe80::83fa:ab8c:9c9f:1157]) by AS8PR10MB6337.EURPRD10.PROD.OUTLOOK.COM ([fe80::83fa:ab8c:9c9f:1157%6]) with mapi id 15.20.7633.021; Mon, 3 Jun 2024 13:56:50 +0000
From: "Fries, Steffen" <steffen.fries@siemens.com>
To: Mahesh Jethanandani <mjethanandani@gmail.com>, "draft-ietf-anima-brski-ae@ietf.org" <draft-ietf-anima-brski-ae@ietf.org>
Thread-Topic: Antwort an Mahesh (BRSKI-AE AD review), war RE: Ich falle erst mal aus - Re: AD review of draft-ietf-anima-brski-ae-10
Thread-Index: AQHanAv6EiVfdW2EV06YkAA0NZpv07GUxD8AgAh7hoCABDS6gIAAKIAwgAMhsoCAAgkLsIAPb8kg
Date: Mon, 03 Jun 2024 13:56:50 +0000
Message-ID: <AS8PR10MB63375AAAFAAABF0B38F07DBBF3FF2@AS8PR10MB6337.EURPRD10.PROD.OUTLOOK.COM>
References: <1301116B-39AC-4F13-BA67-88E2E71FD12F@gmail.com> <8e7f9105-a286-444b-a40c-f32852a62a42@siemens.com> <DB9PR10MB571508AE49688C100B673BB7FEEF2@DB9PR10MB5715.EURPRD10.PROD.OUTLOOK.COM> <DB9PR10MB57154B02CAC9071F154D551BFEEA2@DB9PR10MB5715.EURPRD10.PROD.OUTLOOK.COM> <DB9PR10MB6354893DDF3F85681DECE6C2F3EA2@DB9PR10MB6354.EURPRD10.PROD.OUTLOOK.COM> <497f63ab-cd4e-4591-999f-1c6c12fe5a3d@siemens.com> <DB9PR10MB635461C3D102C1C48BB19149F3F52@DB9PR10MB6354.EURPRD10.PROD.OUTLOOK.COM>
In-Reply-To: <DB9PR10MB635461C3D102C1C48BB19149F3F52@DB9PR10MB6354.EURPRD10.PROD.OUTLOOK.COM>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_9d258917-277f-42cd-a3cd-14c4e9ee58bc_ActionId=50b50394-0078-4822-b337-5f2a92c5939a;MSIP_Label_9d258917-277f-42cd-a3cd-14c4e9ee58bc_ContentBits=0;MSIP_Label_9d258917-277f-42cd-a3cd-14c4e9ee58bc_Enabled=true;MSIP_Label_9d258917-277f-42cd-a3cd-14c4e9ee58bc_Method=Standard;MSIP_Label_9d258917-277f-42cd-a3cd-14c4e9ee58bc_Name=restricted;MSIP_Label_9d258917-277f-42cd-a3cd-14c4e9ee58bc_SetDate=2024-05-24T14:36:35Z;MSIP_Label_9d258917-277f-42cd-a3cd-14c4e9ee58bc_SiteId=38ae3bcd-9579-4fd4-adda-b42e1495d55a;
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=siemens.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: AS8PR10MB6337:EE_|AS8PR10MB5901:EE_
x-ms-office365-filtering-correlation-id: df5edc8c-d8e9-427d-0cc2-08dc83d504ab
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230031|1800799015|366007|376005|38070700009;
x-microsoft-antispam-message-info: Mw121+c9Ayf0lxF0xErIqY1vk3hlfTWLa2CnDZpDW3DaGOevzgQa9xLBlH6hHgQ1fy7h+jjMH0HknQfZgRFO4RlEKK57fLHiX6jbSkNNhqXL8RU4hxCe2ngwM/lqh7ywQYNDpQfXhLxIjigPHULTLLeR3ubg5KxuNXHM5KwHn4QSF9zV6Ru1JSATyTYT54YStb+gOwuw7ROfb1rsAGO9PeneFJsEcvAcoQ9HkY7NiYvesjvd3JqWUKIw6jALpvnuVmr7RyRSwDT7g0ID2RgFBaF4Iu7PGgBlGh6fpZ7SGqUwnPIvR72rf75WdHL/W8/Un7dF3WjAqafK/dz/D1xM3ThI9CQqeGfPUZSaF7lHEUz/4Fw9s6Lc0Cw5cs0jNgXcSRvLhKaLb3CtfWtSUP2f8KISfvWMaSqaQWq8tmY0Sv1jpcTes+eHU6lofEWJiGPEm+2z9puVW9CexTQRPD7w9r6k0USrY0J6lVVaj3LbO+pwgO5BN0iPxKG21XMW/Ddf5ukyBoN9TAyjTnloVD9k7fWp46Pj9GUp3JzYmR6++SeJRYJRSJ1Mwzq2IQ9ScbkZIOmkEKP9NzfBJ5jhhcIaetjXkh8Dz4gYjDi6xJbEhGrEap9lBNid1y82FbKk2LaULtTLiJ1a3hJAKIjbj9NZhuEeKHRDrDpktC3Bje1O/5tUlKYy8goyR1cv4MsLiDFAijRASm2em7scfiXs9irN5rtXsv4bWw1tY2KpdXM3epdf9R/L/AwBBUjmX2hskKI4BMREHZtkCX+0vh52I3PmtH73iKjUkckI4PPIgSaYoxXps9XP5t0f1FFbGA4izjd5joaXBbn9ADNARdNZZZueiLqXTYDnMIZ0Jv75P9zu7FuoBEoxvP6rU3pnR45Tpt3D44tC2+V9KOfLjXWgE+xSkOuFT1YtBepESs06Wox2FpKIODDGKtOfEIyMDuj/P8oQvSKv6uisKlSOP9tncf15WJ4afg41yi9jTf0wxFrLKP1W0bkDK5+Fxo6OyeHfTXjpgHJ+TY66EW2yYbnMS9wqA1cMoJ6xgOnjgVMkhWmVYA0I2R8xxc1rk7pi1mBzdmjIps6P1zyrp7FvgwKQxwP+fHWMsW1xpB2dlKr7pbjKuXESUwTnTbfpOObFGF7rSWd0DbSx00xl5ATY5I0hcTi88LeTrSw7NbNuQy2+fl9sC1BB6IRIz6f5M5t4BHA0z1SCeDZycwgv29iU6vGEl19z2swj4vvMw5k3RE+6draz72fPJxXOVdHi082yeIEqSHGH/g7bMj2etqN9kGNnZ9pGvQ==
x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS8PR10MB6337.EURPRD10.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230031)(1800799015)(366007)(376005)(38070700009);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: yx8QKyaQnl/kb/exo5o76drY/z918cw1RYof/Y9LYSDbHKJKoyfSiIyD6/h1qjF63wkcyI9YbuAxyztaQtn/+4aYy60R2etf/SoZK/X9mTSLxnz8ZLQ77XSGY/VO4gdqieizYDJRg2e4eA9Lz7ll56mzkNZL0t2zJfWmsVTUBPp8Z2vWlc5WlUcaRVBt+taLgHySiUYFg48vsz2Q/r5kpMMIS6Q2SYdsnxK/kzkK4bQ7HI4hl4Kk+2lgrBvd+j5I5NJ+w1k+9kZPAIj6H/AdZ7+FCijRTJoJtXc1bNxBdMegCWIYJei6BvHcRZBEENnjDGGSNTuiRug6N4+NueTRAfM/dIjedhKKckwz/fLYMxsILa1BiROM1k5DP/GfQm3SBLa12ER13fXhIssOqZwGNhjs7BHj4e2fz+mmeQvlgwcTpVhMIZKReHkVNx5MhYm1TiMO9ROJswzd5ZxvaFH+hjFO9XEcYA+EdA/S4RwMYQc5qEDxGk+u/B+d9jFXSK+uAbXZSEeoqM+CE1TaZ5W22l6Sc95ZzhONRRGPkYihL0CEOzQWsneZ1ux8ycFHSyaYTafalzaSgnRp0OUM2lHznz36/9BgEBIkGdN1S8y3GjxxCWHlDqkhlxWOkImcPcV/SYanOhMRV18GT9NyZx8aJD3AMl0t/IpsVyMwaOb4M+HFkByZjmoK7WgrdbMW/Nck0pHrjkYTdu37hVmuZON+R3yOMBOF8/nDyAjzhpFJFrXRcDOXwtpTPkno9z9p8JWxduNycIkqGt5vinRmwsK/YwwIKDTjQZTF+3eckq6zRhnsikNBVjdmOAtPWO7sxDq/UaZKvLLhSqP23qKpgcSFIvD82ayGCwnWklepx2D6ZUB3dTHWG8A8zCHtvCa1lhfqP5Een0ubkQUco0kfTfQFohVmDZ1n+ngrmXoBsLLcnKLc97Z3sxqwetF5T8X2ydR2bmFq5zcsKU35ihJCXmWjneXB8VbWPWur2xi8a+ABQNFP1ijspt1FqXM7PfI5eiyONccDDDkQuzDwTh/A0c80impCaOpLDERWyKog6mf824PZQ2sVqqsfCs5KTAxnNPfSDYmCWmqgn3IJtZurhIYT6kiZyUibeaXq3UBPKLmsCwWkJPlQ1gPSY0/p3qVqKbfvp4Fsdrhoz/H1eYa+u1Xr1XwoJOO43IbiCrRZC/vRpjDK5IXSX2CcuVrgEhHn3Fhz+uhzX77BwntSaGEV0HV2waJ+HvZF6pQzWlYIszc7Tq+MUpbNdssVapBXpBTVNP4LDX5zAj/gxB0lGlEFH+LO+Bvhw3bIKs0/41SMFT2NFm8HUzMMxRnrYD3AbH+b8xMfJsS0CDZzay5LXH6Nrv1ch2nhazfIGK7CgYPQMTkHk42H0UMNjuf5A4mp4IDHRR0wRmAudUzmZnl3TtQteKPjT9o3ozk7LFfAX14ERjybiB2ACSjmKUQmcVFYqIdXtx4NEX35+VrY5CHq0KzQb8OaawUmQNnept1tFFenR84TguuIKyWNTfNhstPODU4akVanzE1gWB57j/rjmZhESDyGL0akfP9Mv107nONDPg723RJKyyTiZ567ZnOsVSJqs/+l
Content-Type: multipart/alternative; boundary="_000_AS8PR10MB63375AAAFAAABF0B38F07DBBF3FF2AS8PR10MB6337EURP_"
MIME-Version: 1.0
X-OriginatorOrg: siemens.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: AS8PR10MB6337.EURPRD10.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: df5edc8c-d8e9-427d-0cc2-08dc83d504ab
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jun 2024 13:56:50.9011 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 38ae3bcd-9579-4fd4-adda-b42e1495d55a
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: vx6ECMot07nsTi7eLqfI66OWJJAVdsL8G4qGr4So/5ECtJrul5X/kfOQbIx4lXVM3jOu2GPe7bgTeI8sf7aQBCwWD5QOXZhmtgECbrOTtrc=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR10MB5901
Message-ID-Hash: JDO7OEZN554V2KY6IGOQTATYTCHUJD2Q
X-Message-ID-Hash: JDO7OEZN554V2KY6IGOQTATYTCHUJD2Q
X-MailFrom: steffen.fries@siemens.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-anima.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: "anima-chairs@ietf.org" <anima-chairs@ietf.org>, "anima@ietf.org" <anima@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [Anima] FW: Antwort an Mahesh (BRSKI-AE AD review), war RE: Ich falle erst mal aus - Re: AD review of draft-ietf-anima-brski-ae-10
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/sgGi3zWyqWkRNLBJmT8sp-bgBsc>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Owner: <mailto:anima-owner@ietf.org>
List-Post: <mailto:anima@ietf.org>
List-Subscribe: <mailto:anima-join@ietf.org>
List-Unsubscribe: <mailto:anima-leave@ietf.org>

Hello Mahesh,

Thank you very much for your thoughtful review. We finally managed to go through all of your comments and incorporated changes accordingly.

Below you find the list of your comments with the resolution description. We will also post an updated draft (version 11) soon.
Best regards
David, Hendrik, and Steffen
On 01.05.24 23:10, Mahesh Jethanandani wrote:
Hi Authors,

Thank you for working on the document, and thanks to Toerless for shepherding the document. The document was fairly easy read, but could be improved.

Here is my review of the document. It is divided between COMMENTs and NITs. I expect some resolution of the COMMENTs, and it would be nice to see the NITs also addressed.



-------------------------------------------------------------------------------
COMMENT
-------------------------------------------------------------------------------

Overall:

My overall comment on the document is related to two items. One is the use of Note(s) liberally in the document, and use of words like "could" and "can" throughout the document.

On the use of Notes, I would strongly suggest that they should be formalized, i.e., the prefix "Note:" should be removed, or replaced with text such as "It should be noted ..." or something more formal.

As explained, we would generally have preferred to keep the existing style using "Note:",
yet we have replaced most such occurrences, as follows:

Section 1:

OLD

Note: The BRSKI voucher exchange of the pledge

NEW

Note that the BRSKI voucher exchange of the pledge



OLD

Note: BRSKI (RFC 8995) specifies how to use HTTP over TLS,

NEW

It may be noted that BRSKI (RFC 8995) specifies how to use HTTP over TLS,



Section 3.1:

OLD

  Note: The integrity protection of CSRs includes the public key

NEW

  It should be noted that the integrity protection of CSRs includes the public key


Section 4.1:

OLD
Note: To support end-to-end authentication of the pledge

NEW

To support end-to-end authentication of the pledge


Section 4.2.4:


OLD

Note: Connections between the registrar and the PKI components

NEW

It may be noted that connections between the registrar and the PKI components



OLD

Note:
The decision of whether to forward a request or to answer it directly can depend

NEW

The decision of whether to forward a request or to answer it directly can depend



OLD

Note:
There are several options for how the registrar could be able to directly answer

NEW

Note that there are several options for how the registrar could be able to directly answer



OLD

Note:
Certification requests typically need to be handled by the backend PKI,

NEW

Further note that Certification requests typically need to be handled by the backend PKI,



Section 5.1:

OLD

  Note: When the registrar forwards a certification request by the pledge to
  a backend RA, the registrar is recommended to wrap the original

NEW

  While the way in which the registrar forwards a certification request to the backend PKI
  is out of scope of this document, the registrar is recommended to wrap the original



OLD

Note: Independently of certificate confirmation within CMP,

NEW

Note that independently of certificate confirmation within CMP,



OLD

Note:
How messages are exchanged between the registrar and backend PKI

NEW

How messages are exchanged between the registrar and backend PKI


On the use of words such as "could", "can" etc., I would suggest that the authors review them and use BCP 14 suggested words such as SHOULD, MAY etc.

We have reviewed the specific points you mention below
and confirmed for ourselves that we follow BCP 14 (RFC 2119 and 8174) where suitable
and changed one "may" to "MAY".
We give more details on this on each such point below.


"Abstract", paragraph 2
>    This offers the following advantages.  The origin of requests and
>    responses can be authenticated independently of message transfer.
>    This supports end-to-end authentication (proof of origin) also over
>    multiple hops, as well as asynchronous operation of certificate
>    enrollment.  This in turn provides architectural flexibility where
>    and when to ultimately authenticate and authorize certification
>    requests while retaining full-strength integrity and authenticity of
>    certification requests.

This paragraph should be moved to the Introduction (or at least removed from here) to keep the abstract truly an abstract. That section already details how BRSKI-AE is different from BRSKI, and covers the advantage of this approach.

Moved the paragraph to the introduction, where it fit nicely as a new 2nd paragraph,
now starting like this: "This approach provides the following advantages. "


Section 1, paragraph 8
>    Note: The BRSKI voucher exchange of the pledge with the registrar and
>    MASA uses authenticated self-contained objects, so the voucher
>    exchange already has these properties.

To formalize the Note, could the sentence be changed to say "It is useful to note that the BRSKI voucher ...", or something like that? See note above.

Done, see above.
Section 1.1, paragraph 4
>       -  the registration Authority (RA) not being co-located with the
>          registrar while requiring end-to-end authentication of
>          requesters, which EST does not support over multiple hops

Consider using assertive language vs passive language for most of these bullet items. For example, in this bullet item, based on my understanding, the reason that EST cannot be used is because it does not support multiple hops for end-to-end authentication. Therefore, anything that is more than one hop away cannot be authenticated. If that is the intent of this bullet item, can it reworded to say that?

Simplified the language for the whole (nested) list as follows:

OLD

* pledges and/or the target domain reusing an already established
   certificate enrollment protocol different from EST, such as CMP.

* scenarios indirectly excluding the use of EST for certificate enrollment,
  such as:
  - the registration Authority (RA) not being co-located with the registrar
  while requiring end-to-end
  authentication of requesters, which EST does not support over multiple hops
  - the RA or certification authority (CA) operator requiring
  auditable proof of origin for Certificate Signing Requests (CSRs), which is
  not possible with the transient source authentication provided by TLS.
  - certificate requests for types of keys that do not support signing,
  such as Key Encapsulation Mechanism (KEM) and key agreement keys,
  which is not supported by EST because it uses CSR in PKCS #10 {{RFC2986}}
  format expecting proof-of-possession via a self-signature
  - pledge implementations using security libraries not providing EST support or
  a TLS library that does not support providing the so-called tls-unique value
  {{RFC5929}} needed by EST for strong binding of the source authentication

* no full RA functionality being available on-site in the target domain, while
   connectivity to an off-site RA may be intermittent or entirely offline.

* authoritative actions of a local RA at the registrar being not sufficient
  for fully and reliably authorizing pledge certification requests, which
   may be due to missing data access or due to an insufficient level of security,
  for instance regarding the local storage of private keys


NEW1

* Pledges and/or the target domain reuse an already established
   certificate enrollment protocol different from EST, such as CMP.

* The application scenario indirectly excludes the use of EST
  for certificate enrollment, for reasons like these:
  - The Registration Authority (RA) is not co-located with the registrar
  while it requires end-to-end authentication of requesters.
  Yet EST does not support end-to-end authentication over multiple hops.
  - The RA or certification authority (CA) operator requires
  auditable proof of origin for Certificate Signing Requests (CSRs). This is not
  possible with TLS because it provides only transient source authentication.
  - Certificates are requested for types of keys that do not support signing,
  such as Key Encapsulation Mechanism (KEM) and key agreement keys.
  This is not supported by EST because it uses CSR in PKCS #10 {{RFC2986}}
  format expecting proof-of-possession via a self-signature.
  - The Pledge implementation uses security libraries not providing EST support
  or uses a TLS library that does not support providing
  the so-called tls-unique value {{RFC5929}},
  which is needed by EST for strong binding of the source authentication.

* No full RA functionality is available on-site in the target domain, while
   connectivity to an off-site RA may be intermittent or entirely offline.

* Authoritative actions of a local RA at the registrar is not sufficient
  for fully and reliably authorizing pledge certification requests. This
  may be due to missing data access or due to an insufficient level of security,
  for instance regarding the local storage of private keys.

On this occasion, I further improved the item on proof of possession (adding an informative reference to RFC 6955):

OLD2

  - Certificates are requested for types of keys that do not support signing,
  such as Key Encapsulation Mechanism (KEM) and key agreement keys.
  This is not supported by EST because it uses CSR in PKCS #10 {{RFC2986}}
  format expecting proof-of-possession via a self-signature.

NEW

  - Certificates are requested for types of keys, such as Key Encapsulation
  Mechanism (KEM) keys, that do not support signing (nor alternative forms
  of single-shot proof of possession like those described in {{RFC6955}}).
  This is not supported by EST because it uses CSRs in PKCS #10 {{RFC2986}}
  format, which can only use proof-of-possession methods that
  need just a single message, while proof of possession for KEM keys,
  for instance, requires receiving a fresh challenge value beforehand.


Section 1.1, paragraph 3
>       -  the RA or certification authority (CA) operator requiring
>          auditable proof of origin for Certificate Signing Requests
>          (CSRs), which is not possible with the transient source
>          authentication provided by TLS.

Similarly, I read this as "TLS provides transient source authentication, while RA an CA operators require proof of origin for CSRs".
Right, TLS provides transient source authentication.
Yet part of RA and CA operators require an end-to-end proof of origin for CSRs.
We just slightly re-phrased the this point as given above (in the part marked "NEW1").
Section 1.2, paragraph 8
>    Bootstrapping can be handled in various ways, depending on the
>    application domains.  The informative Appendix A provides
>    illustrative examples from various industrial control system
>    environments and operational setups.  They motivate the support of
>    alternative enrollment protocols, based on the following examples of
>    operational environments:
>
>    *  rolling stock
>
>    *  building automation
>
>    *  electrical substation automation
>
>    *  electric vehicle charging infrastructures
>
>    *  infrastructure isolation policy
>
>    *  sites with insufficient level of operational security

Consider moving this section to the Appendix where the examples are, or removing this entire section as it is describing an use case scenario, and does very little to help the specification itself.

Well, as written, these examples motivate the support of alternative enrollment protocols,
and this little section is essentially a forward reference to the examples, which we had moved to the appendix before.

We have now removed section 1.2 by merging its first paragraph into the preceding section 1.1 and removing the bullet list (which anyway was redundant with the subsection headers in Appendix A).

OLD

1.2. <https://datatracker.ietf.org/doc/html/draft-ietf-anima-brski-ae-10#section-1.2> List of Application Examples<https://datatracker.ietf.org/doc/html/draft-ietf-anima-brski-ae-10#name-list-of-application-example>

Bootstrapping can be handled in various ways, depending on the application domains. The informative Appendix A<https://datatracker.ietf.org/doc/html/draft-ietf-anima-brski-ae-10#app-examples> provides illustrative examples from various industrial control system environments and operational setups. They motivate the support of alternative enrollment protocols, based on the following examples of operational environments:¶<https://datatracker.ietf.org/doc/html/draft-ietf-anima-brski-ae-10#section-1.2-1>

  *   rolling stock¶<https://datatracker.ietf.org/doc/html/draft-ietf-anima-brski-ae-10#section-1.2-2.1.1>
  *   building automation¶<https://datatracker.ietf.org/doc/html/draft-ietf-anima-brski-ae-10#section-1.2-2.2.1>
  *   electrical substation automation¶<https://datatracker.ietf.org/doc/html/draft-ietf-anima-brski-ae-10#section-1.2-2.3.1>
  *   electric vehicle charging infrastructures¶<https://datatracker.ietf.org/doc/html/draft-ietf-anima-brski-ae-10#section-1.2-2.4.1>
  *   infrastructure isolation policy¶<https://datatracker.ietf.org/doc/html/draft-ietf-anima-brski-ae-10#section-1.2-2.5.1>
  *   sites with insufficient level of operational security¶<https://datatracker.ietf.org/doc/html/draft-ietf-anima-brski-ae-10#section-1.2-2.6.1>

NEW

Bootstrapping can be handled in various ways, depending on the application domains. The informative Appendix A<https://datatracker.ietf.org/doc/html/draft-ietf-anima-brski-ae-10#app-examples> provides illustrative examples from various industrial control system environments and operational setups motivating the support of alternative enrollment protocols.¶<https://datatracker.ietf.org/doc/html/draft-ietf-anima-brski-ae-10#section-1.2-1>


Section 3, paragraph 2
>    At least the following properties are required for a certification
>    request:

Consider removing the phrase, "At least".

Done:

OLD

At least the following properties are required for a certification

NEW

The following properties are required for a certification

Section 3.1, paragraph 4
>    Note: The integrity protection of CSRs includes the public key
>    because it is part of the data signed by the corresponding private
>    key.  Yet this signature does not provide data origin authentication,
>    i.e., proof of identity of the requester because the key pair
>    involved is fresh.

It is not clear what it means for "the key pair involved is fresh".

Changed; hopefully it becomes clear this way:

OLD

the key pair involved is fresh.

NEW

the key pair is new and therefore does not yet have a confirmed identity associated with it.


Section 3.2, paragraph 5
>       Yet this binding is only valid in the context of the TLS session
>       established with the registrar acting as the EST server and
>       typically also as an RA.  So even such a cryptographic binding of
>       the authenticated pledge identity to the CSR is not visible nor
>       verifiable to authorization points outside the registrar, such as
>       a (second) RA in the backend.  What the registrar must do is to
>       authenticate and pre-authorize the pledge and to indicate this to
>       the (second) RA by signing the forwarded certificate request with
>       its private key and a related certificate that has the id-kp-cmcRA
>       extended key usage attribute.

Consider using MUST instead of lowercase must in this paragraph.
This is not a MUST in the sense of interoperability, but more in the sense of security-wise necessity.
This paragraph just mentions here requirements of a different spec, namely EST, in a non-normative way.
Changed to "needs to" for clarity:

OLD
What the registrar must do
NEW
What the registrar needs to do

Section 3.2, paragraph 8
>    To sum up, EST does not meet the requirements for authenticated self-
>    contained objects, but SCEP, CMP, and CMC do.  This document
>    primarily focuses on CMP as it has more industrial relevance than CMC
>    and SCEP has issues not detailed here.

What does "industrial relevance" mean? Or did you mean to say "industry adotption"?

Changed to "industry adoption".
Section 4.1, paragraph 1
>    The key element of BRSKI-AE is that the authorization of a
>    certification request MUST be performed based on an authenticated
>    self-contained object.  The certification request is bound in a self-
>    contained way to a proof of origin based on the IDevID credentials.
>    Consequently, the certification request may be transferred using any
>    mechanism or protocol.  Authentication and authorization of the
>    certification request can be done by the domain registrar and/or by
>    backend domain components.  As mentioned in Section 1.1, these
>    components may be offline or off-site.  The registrar and other on-
>    site domain components may have no or only temporary (intermittent)
>    connectivity to them.

Consider using BCP 14 terms like MAY in the above paragraph.
These three instances of "may" express possibilities.
The first of them is in scope, and as it can be seen as implementation options
according to https://datatracker.ietf.org/doc/html/rfc2119#section-5, changed:
OLD
Consequently, the certification request may be transferred
NEW
Consequently, the certification request MAY be transferred

Concerning the other two instances of "may" in the above quoted paragraph:
The transfer of those self-contained messages between registrar and backend systems
is not in scope of this specification and so we believe we the "may" cannot be stated normatively.

Section 4.1, paragraph 8
>       2.  Rather than having full RA functionality, the registrar MAY
>           act as a local registration authority (LRA) and delegate part
>           of its involvement in certificate enrollment to a backend RA,
>           called RA.  In such scenarios the registrar optionally checks
>           certification requests it receives from pledges and forwards
>           them to the RA.  The RA performs the remaining parts of the
>           enrollment request validation and authorization.  Note that to
>           this end the RA may need information regarding the
>           authorization of pledges from the registrar or from other
>           sources.  On the way back, the registrar forwards responses by
>           the PKI to the pledge on the same channel.

Consider giving RA a different or more qualified name, otherwise it is not clear how is this RA different from a "normal" RA. How about Backend RA, or a Full RA or something similar?

Changed "RA" to "backend RA", also in the subsequent paragraph.

Section 4.1, paragraph 8
>           Note: In order to support end-to-end authentication of the
>           pledge across the registrar to the RA, the certification
>           request structure signed by the pledge needs to be retained by
>           the registrar, and the registrar cannot use for its
>           communication with the PKI a enrollment protocol different to
>           the one used by the pledge.

This note is confusing. It is not clear what it means for the certification request structure to be "retained by the registrar". By retained, do you mean it is stored locally, and a new request is initiated by the registrar. Also, the sentence "registrar cannot use its communication with the PKI an enrollment protocol" does not parse for me. Can it be reworded? Finally, as noted below, please be consistent in the use of "certificate request", "certification request", and "certs request".

Changed for clarity, consistency, and readability:

OLD

the certification request structure signed by the pledge
needs to be retained by the registrar, and the registrar cannot use for its communication
with the PKI a enrollment protocol different to the one used by the pledge.

NEW

the certification request signed by the pledge
needs to be upheld and forwarded by the registrar.
Therefore, the registrar can not use an enrollment protocol,
which is different from the enrollment protocol used between
the pledge and the registrar, for its communication with the
backend PKI.

For consistency we changed in the overall text
the few further remnant "certificate request" occurrences to "certification request".
OTOH, the "CA Certs Request" is something different, so this does not change.


Section 4.1, paragraph 8
>       3.  The use of a certificate enrollment protocol with
>           authenticated self-contained objects gives freedom how to
>           transfer enrollment messages between pledge and RA.
>           Regardless how this transfer is protected and how messages are
>           routed, also in case that the RA is not part of the registrar
>           it MUST be guaranteed, like in BRSKI, that the RA accepts
>           certification requests for LDevIDs only with the consent of
>           the registrar.  See Section 7 for details how this can be
>           achieved.

After the first sentence, I got lost in the "also", "like", and "only". Can the rest of paragraph be broken up into multiple statements?

We split up the complex 2nd sentence of the paragraph:

OLD
Regardless how this transfer is protected and how messages
are routed, also in case that the RA is not part of the
registrar it MUST be guaranteed, like in BRSKI, that the RA
accepts certification requests for LDevIDs only with the
consent of the registrar. See Section 7 for details how this
can be achieved.
NEW
BRSKI demands that the RA accepts certification requests for
LDevIDs only with the consent of the registrar. BRSKI-AE
guarantees this also in case that the RA is not part of the
registrar, even if the further message transfer is unprotected
and involves further transport hops. See Section 7 for
details on how this can be achieved.


Section 4.2.4, paragraph 6
>    Note: Connections between the registrar and the PKI components of the
>    operator (RA, CA, etc.) may be intermittent or off-line.  Messages
>    should be sent as soon as sufficient transfer capacity is available.

There are several uses of the word "could", "can" in the notes below. Consider using BCP 14 keywords. See note above.

Also here, the words like "may" and "should" are deliberately not meant as normative the sense of BCP 14 expressing feature options or normative recommendations. Instead, they express possibilities and hints on the message transfer, which is not in scope.


Section 4.2.4, paragraph 9
>    Also certificate confirmation messages will usually be forwarded to
>    the backend PKI, but if the registrar knows that they are not needed
>    or wanted there it can acknowledge such messages directly.

Is this paragraph part of the above Note? If so, consider combining them.

Yes, it's meant as a second part of the Note, separated by a newline for hopefully better readability.
Anyway, removed the newline to prevent ambiguity.


Section 4.2.4, paragraph 14
>    *  Attribute Response (4): This MUST contain the attributes to be
>       included in the subsequent certification request.

Shouldn't the response contain the attributes requested in (3)? If so, should it not be stated here? Also, it would be useful to describe what happens if no attributes are returned.

For clarity, re-phrased this part
and moved the ACP example, which so far was given before (4), after (4):

OLD

   For example, {{RFC8994, Section 6.11.7.2}} specifies
   how the attribute request is used to signal to the pledge
   the acp-node-name field required for enrollment into an ACP domain.

*  Attribute Response (4): This MUST contain the attributes to be included
    in the subsequent certification request.

NEW

* Attribute Response (4): This MUST contain the attributes requested in (3)
   to be included in the subsequent Certification Request (5).

   For example, {{RFC8994, Section 6.11.7.2}} specifies
   how the attribute request is used to signal to the pledge
   the acp-node-name field required for enrollment into an ACP domain.

Section 4.3, paragraph 3
>    A pledge SHOULD use the endpoints defined for the enrollment
>    protocol(s) that it is capable of and is willing to use.  It will
>    recognize whether its preferred protocol or the request that it tries
>    to perform is understood and supported by the domain registrar by
>    sending a request to its preferred enrollment endpoint according to
>    the above addressing scheme and evaluating the HTTP status code in
>    the response.  If the pledge uses endpoints that are not
>    standardized, it risks that the registrar does not recognize and
>    accept them even if supporting the intended protocol and operation.

The last sentence does not parse for me. Did you mean to say that the registrar does not recognize the request, but still goes ahead and accepts it, even if it does not support the intended protocol? This should be highlighted in the Security Considerations section also.

Oh, the "not" was meant to distribute over "recognize" and "accept", but this was ambiguous.
Re-phrased for simplicity and clarity:

OLD
A pledge SHOULD use the endpoints defined for the enrollment
protocol(s) that it is capable of and is willing to use. It will
recognize whether its preferred protocol or the request that it tries
to perform is understood and supported by the domain registrar by
sending a request to its preferred enrollment endpoint according to
the above addressing scheme and evaluating the HTTP status code in
the response. If the pledge uses endpoints that are not standardized,
it risks that the registrar does not recognize and accept them even
if supporting the intended protocol and operation.

NEW
A pledge SHOULD use the endpoints defined for the enrollment
protocol(s) that it can use. It will
recognize whether the protocol it uses and the specific request it wants
to perform is understood and supported by the domain registrar by
sending the request to the respective endpoint according to
the above addressing scheme and then evaluating the HTTP status code of
the response. If the pledge uses endpoints that are not standardized,
it risks that the registrar does not recognize a request and thus may reject it, even
if the registrar supports the intended protocol and operation.

We see no need to highlight this in the Security Considerations section
because this is not a security issue, but just an interoperability issue:
a request may be rejected in this case though the server would be able to handle it, but it was received on an unspecified endpoint.

Section 5.1, paragraph 2
>    *  CA Certs Request (1) and Response (2):
>       Requesting CA certificates over CMP is OPTIONAL.
>       If supported, it SHALL be implemented as specified in [RFC9483],
>       Section 4.3.1.

Is it "CA Certs Request" or "CA Certificate Request"? Let us be consistent.
It is "CA Certs Request" and "CA Certs Response", as written.
These are different from certification requests by the pledge for getting new certificates for itself
as outlined in Figure 2 in section 4.2.4. Note that the messages defined are based on LCMPP.

Section 5.1, paragraph 2
>    *  Attribute Request (3) and Response (4):
>       Requesting certificate request attributes over CMP is OPTIONAL.
>       If supported, it SHALL be implemented as specified in [RFC9483],
>       Section 4.3.3.

Is requesting attributes optional, or requesting them over CMP is OPTIONAL?
The optionality was mentioned in Figure 2, but not in the abstract description of the flow.

Like for CA Certs Request (1) and Response (2),
Attribute Request (3) and Response (4) are marked OPTIONAL both in the figure and in its description.
And correct that "over CMP" is ambiguous, namely whether these exchanges are generally (regardless of the way being done) optional.
We wrote in both these exchanges "over CMP", but this was confusing.
(If these exchanges were performed by other, non-CMP, means this would not be interoperable.)
So we removed both instances of "over CMP" for clarity.

Note that we also removed the occurrence of “within CMP” in the note following “Certificate Confirm (7) and PKI/Registrar Confirm (8):” for clarity

Section 5.1, paragraph 5
>       Note: When the registrar forwards a certification request by the
>       pledge to a backend RA, the registrar is recommended to wrap the
>       original certification request in a nested message signed with its
>       own credentials as described in [RFC9483], Section 5.2.2.1.  This
>       explicitly conveys the consent by the registrar to the RA while
>       retaining the certification request with its proof of origin
>       provided by the pledge signature.

Let us be consistent in the use of "Certificate Request". I see "Certs Request", "Certification Request" etc.
"certification request" is the general term, now used consistently throughout the text.
In the figure and its description, changed "Certificate Request/Response" to "Certification Request/Response",
for consistency, while using here upper case to emphasize that here we mean the specific CMP message syntax.
As partly mentioned above, a "CA Certs Request" is something different:
not a request for a new device certificate, but for a list of already existing CA certificates.

Note that we included the following additional terminology definition in section 2, to shortly introduce the utilized generic terminology for PKI management operation to e independent of the utilized enrollment protocol.

NEW

Note that this document utilizes a more generic terminology regarding PKI management operations to be independent of a specific enrollment protocol terminology

certification request:

: describes the request of a certificate with proof of identity

certification response:

:describes the answer to the certification request

attribute request:

: describes the request of content to be included in the certification request

attribute response:

: describes the describes the answer to the attribute request

CA Certs request:

: describes the request of CA certificates.

CA Certs response:

: describes the describes the answer to the CA Certs request

certificate confirm:

: describes a confirmation message to be used if a backend PKI requires a confirmation of the certificate acceptance by a pledge.

PKI/registrar confirm:

: describes an acknowledgement of the PKI to the certificate confirm


Section 5.1, paragraph 8
>    *  If delayed delivery of responses (for instance, to support
>       asynchronous enrollment) within CMP is needed, it SHALL be
>       performed as specified in Section 4.4 and Section 5.1.2 of
>       [RFC9483].

This bullet item does not parse for me.



Reformulated and simplified.

OLD
*  If delayed delivery of responses (for instance, to support
    asynchronous enrollment) within CMP is needed, it SHALL be
    performed as specified in Section 4.4 and Section 5.1.2 of
    [RFC9483].



NEW

* If delayed delivery of responses is needed

  (for instance, to support enrollment over an asynchronous channel),

  it SHALL be performed as specified in
  in Section 4.4 and Section 5.1.2 of
   [RFC9483].




Section 5.1, paragraph 8
>    Note: The way in which messages are exchanged between the registrar
>    and backend PKI components (i.e., RA or CA) is out of scope of this
>    document.  Due to the general independence of CMP of message
>    transfer, it can be freely chosen according to the needs of the
>    application scenario (e.g., using HTTP), while security
>    considerations apply, see Section 7, and guidance can be found in
>    [RFC9483], Section 6.

This paragraph also does not parse for me.

OLD
Note: The way in which messages are exchanged between the registrar
and backend PKI components (i.e., RA or CA) is out of scope of this
document.  Due to the general independence of CMP of message
transfer, it can be freely chosen according to the needs of the
application scenario (e.g., using HTTP), while security
considerations apply, see Section 7, and guidance can be found in
[RFC9483], Section 6.

NEW

Since CMP is independent of message transfer, the transfer mechanism
can be freely chosen according to the needs of the application scenario.


Section 7, paragraph 9
>    Note that CMP messages are not encrypted.  This may give
>    eavesdroppers insight on which devices are bootstrapped into the
>    domain, and this in turn might also be used to selectively block the
>    enrollment of certain devices.  To prevent this, the underlying
>    message transport channel can be encrypted, for instance by employing
>    TLS.  On the link between the pledge and the registrar this is easily
>    achieved by reusing the existing TLS channel between them.

As noted above, what happens if a device masquerades itself as a registrar? Is such a scenario possible? If so, it should be highlighted here.

I did not find any other mention of this topic.
Like with vanilla BRSKI, a device cannot masquerade as a registrar because the only identity it has at this point is the IDevID.
The respective certificate looks quite different then the certificate of a legitimate registrar and  is rooted into an entirely
different PKI hierarchy (namely, of its manufacturer) than the registrar certificate (which belongs to an operator PKI hierarchy).
This does not change for BRSKI-AE, so no need to address this topic here.

Based on the comment we further discussed the reuse of the TLS session for CMP message protection. As the TLS channel has been established anyway and CMP is independent of the underlying transport it is simpler to utilize the existing TLS session instead of using a secured and unsecured communication link in parallel. We reflected this in a change in section 4.1:

OLD
For transporting the certificate enrollment request and response
messages, the (D)TLS channel established between pledge and
registrar is RECOMMENDED to use. To this end, the enrollment
protocol, the pledge, and the registrar need to support the usage
of the existing channel for certificate enrollment. Due to this
recommended architecture, typically the pledge does not need to
establish additional connections for certificate enrollment and
the registrar retains full control over the certificate enrollment
traffic.

NEW
For transporting the certificate enrollment request and response
messages, the (D)TLS channel established between pledge and
registrar is MANDATORY to use. To this end, the enrollment
protocol, the pledge, and the registrar MUST support the usage
of the existing channel for certificate enrollment. Due to this
architecture, the pledge SHOULD NOT establish additional
connections for certificate enrollment and the registrar MUST
retain full control over the certificate enrollment traffic.



Consequently, we changed the respective paragraph 9 in Section 7.

OLD
Note that CMP messages are not encrypted.  This may give
eavesdroppers insight on which devices are bootstrapped into the
domain, and this in turn might also be used to selectively block the
enrollment of certain devices.  To prevent this, the underlying
message transport channel can be encrypted, for instance by employing
TLS.  On the link between the pledge and the registrar this is easily
achieved by reusing the existing TLS channel between them.

NEW

Note that CMP messages are not encrypted.
This may give eavesdroppers insight into which devices are bootstrapped into the
domain, and this in turn might also be used to selectively block the enrollment
of certain devices. To prevent this, the underlying message transport channel
can be encrypted, for instance by employing TLS.
For the communication between the pledge and the registrar, the use of TLS is already provided
but needs to be obeyed for the further transport from the registrar to a backend RA.
No reference entries found for these items, which were mentioned in the text:
[LCMPP], [draft-ietf-anima-brski-async-enroll-03], [THISRFC], and
[draft-ietf-anima-brski-async-enroll].

"LCMPP" is introduced as an abbreviation in Section 2: LCMPP: Lightweight CMP Profile [RFC9483]
So far, the figure contained two occurrences of [LCMPP], which confusingly looked like document references.
Removed the square braces.

"draft-ietf-anima-brski-async-enroll-03" does not occur with square braces.
It is used only in the history of changes, which will be deleted before publication,
and has a clickable URI which allows reviewers to conveniently access that specific draft version.

"draft-ietf-anima-brski-async-enroll-03" does not occur with square braces.
It is used only in the history of changes, which will be deleted before publication,
to denote the earlier name of the draft. Added simple quotes around the name for clarity.

"[THISRFC]" is the usual placeholder use when the document is going to refer to itself.
Upon publication this will be expanded to a proper reference including the RFC number.



Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

 * Terms "him" and "his"; alternatives might be "they", "them", "their"
I did not find the word 'his' (just 'this' and 'history').

The term 'him' was just used at one place used as a personal pronoun for Eliot Lear, which we changed to “Eliot”

The term 'he' occurred once as a typo; corrected to 'the'.

The term 'she' does not occur.



-------------------------------------------------------------------------------
NIT
-------------------------------------------------------------------------------

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool) so there
will likely be some false positives.

This caught a number of mostly grammar nits, so I'm glad about them.
Yes, there were a couple of false positives.
There were also several cases where just the original text (preceded by "-")
but not the suggested improvement (preceded by "+") was present - there I simply guessed what was meant.


There is no need to let me know what youdid with these suggestions.

Fine. Anyway, I include some little responses here also as notes to me and the co-authors of what changed why,
just in case needed.



"Abstract", paragraph 6
-    Source for this draft and an issue tracker can be found at
-    ^
+    The source for this draft and an issue tracker can be found at
+    ^^^^^

False positive:
This RFC Editor Note is not by us, but auto-generated, and is going to disappear anyway.



Section 1, paragraph 1
-    authenticated self-contained objects for device certificate
+    authenticated self-contained objects for the device certificate
+                                             ++++

Thanks, included „the“



Section 1, paragraph 5
-       certificate, called LDevID certificate.  On success it receives
+       certificate, called LDevID certificate.  On success, it receives
+                                                          +

changed



Section 1.1, paragraph 1
-    BRSKI-AE is intended to be used situations like the following.
+    BRSKI-AE is intended to be used in situations like the following.
+                                    +++

fixed



Section 2, paragraph 4
-    authenticated self-contained object:  data structure that is
+    authenticated self-contained object: a data structure that is
+                                         +

changed



Section 2, paragraph 13
-       needed if a backend RA is used, and in this case the LRA is co-
+       needed if a backend RA is used, and in this case, the LRA is co-
+                                                       +

changed



Section 3, paragraph 5
-    The rest of this section gives an non-exhaustive list of solution
-                                    -
OLD
The rest of this section gives an non-exhaustive list of solution
examples, based on existing technology described in IETF documents:
NEW
The rest of this section gives a non-exhaustive list of solution
examples, based on existing technology described in IETF documents.

Section 3.1, paragraph 3
-       signature is used generated over (part of) the structure with the
-                                 -
+       signature is used to generate over (part of) the structure with the
+                         +++

inserted: ", which is"



Section 3.2, paragraph 4
-       CSR was not designed to include a proof of origin, there is a
-                                       --

The proposed improvement is missing -
anyway, changed "was not" to "has not been"  and deleted the “a”



Section 3.2, paragraph 6
-       This would allow for source authentication at message level, such
+       This would allow for source authentication at the message level, such
+                                                     ++++

fixed



Section 4, paragraph 2
-    The enhancements needed are kept to a minimum in order to ensure
-                                                  ---------



Removed “in order”

Section 4, paragraph 2
-    reuse of already defined architecture elements and interactions.  In
+    the reuse of already defined architecture elements and interactions.  In
+   ++++

changed



Section 4.1, paragraph 5
-    as BRSKI, but with more flexible placement of the authentication and
+    as BRSKI, but with a more flexible placement of the authentication and
+                      ++
fixed

Section 4.1, paragraph 7
-       onboarding new devices and to facilitate the communication of
-                                  ---         ^
+       onboarding new devices and facilitating the communication of
+                                           ^^^



Section 4.1, paragraph 9
-           called RA.  In such scenarios the registrar optionally checks
+           called RA.  In such scenarios, the registrar optionally checks
+                                        +

changed



Section 4.1, paragraph 9
-           authorization of pledges from the registrar or from other
-                                                          -----
likely a false positive.


Section 4.1, paragraph 10
-           Note: In order to support end-to-end authentication of the
-                 ^^^^^^^^^^
+           Note: To support end-to-end authentication of the
+                 ^

changed



Section 4.1, paragraph 10
-           the registrar, and the registrar cannot use for its
-                        -                              ----
Section 4.1, paragraph 10
-           communication with the PKI a enrollment protocol different to
+           communication with the PKI an enrollment protocol different to
+                                       +

Fixed, already addressed above.

OLD
        Note: In order to support end-to-end authentication of the
          pledge across the registrar to the RA, the certification
          request structure signed by the pledge needs to be retained by
          the registrar, and the registrar cannot use for its
          communication with the PKI a enrollment protocol different to
          the one used by the pledge.

NEW

To support end-to-end authentication of the pledge across the registrar to
the backend RA, the certification request signed by the pledge needs to be
upheld and forwarded by the registrar. Therefore, the registrar can not use
an enrollment protocol, which is different from the enrollment protocol used
between the pledge and the registrar, for its communication with the backend PKI.



Section 4.1, paragraph 11
-           Regardless how this transfer is protected and how messages are
+           Regardless of how this transfer is protected and how messages are
+                     +++

fixed



Section 4.1, paragraph 11
-           the registrar.  See Section 7 for details how this can be
+           the registrar.  See Section 7 for details on how this can be
+                                                     +++

fixed



Section 4.1, paragraph 12
-    Despite of the above generalizations to the enrollment phase, the
-           ---
removed "of"



Section 4.1, paragraph 17
-    may be located on-site or off-site in the target domain.
-       -

Changed to “maybe”



Section 4.1, paragraph 19
-       and authorized by the registrar and/or and an extra RA.
-                                                ----
Also here the proposed improvement is missing -
removed extra "and"


Section 4.1, paragraph 26
-       messages, the (D)TLS channel established between pledge and
+       messages, the (D)TLS channel established between the pledge and
+                                                        ++++

fixed



Section 4.2.1, paragraph 1
-    discovery of registrars with enhanced feature sets.  A pledge cannot
+    the discovery of registrars with enhanced feature sets.  A pledge cannot
+   ++++

fixed



Section 4.2.4, paragraph 2
-    The certificate enrollment phase may involve transmission of several
+    The certificate enrollment phase may involve the transmission of several
+                                                  ++++

fixed



Section 4.2.4, paragraph 8
-    answer the request directly itself.  In this case, it MUST
-                               -------

Also here the proposed improvement is missing -
anyway, removed "itself".



Section 4.2.4, paragraph 8
-    authenticating itself at TLS level for the voucher exchange.
-    Otherwise the registrar MUST forward the request to the RA and
+    authenticating itself at the TLS level for the voucher exchange.
+                            ++++
+    Otherwise, the registrar MUST forward the request to the RA and
+             +

both fixed



Section 4.2.4, paragraph 9
-    Note: The decision whether to forward a request or to answer it
+    Note: The decision of whether to forward a request or to answer it
+                      +++

fixed



Section 4.2.4, paragraph 10
-    Note: There are several options how the registrar could be able to
-    directly answer requests for CA certificates or for certificate
-                                                    ----
+    Note: There are several options for how the registrar could be able to
+                                   ++++

fixed



Section 4.2.4, paragraph 10
-    asking for the same data.  The contents could also be explicit
+    asking for the same data.  The contents could also be explicitly
+                                                                  ++

fixed



Section 4.2.4, paragraph 11
-    rejected, for instance because is not properly authenticated or not
+    rejected, for instance, because it is not properly authenticated or not
+                          +        +++

fixed



Section 4.2.4, paragraph 11
-    Also certificate confirmation messages will usually be forwarded to
+    Also, certificate confirmation messages will usually be forwarded to
+        +

fixed



Section 4.2.4, paragraph 13
-       cert (which is contained in the voucher and may be just the domain
-                                                      -
Also here the proposed improvement is missing -
anyway, added "which" before "may"

Section 4.2.4, paragraph 15
-       additional attributes specific to the target domain into the
-                                                             --

re-structured the sentence.

OLD
      Nevertheless, there are cases in which the pledge may also include
      additional attributes specific to the target domain into the
      certification request.

NEW

Nevertheless, there are cases in which the pledge may also include in the Certification
Request (5) additional attributes that are specific to the target domain.





Section 4.2.4, paragraph 18
-       contained object ensuring both proof of possession of the
+       contained object ensuring both the proof of possession of the
+                                      ++++

fixed, also a 2nd time in the same sentence



Section 4.2.5, paragraph 2
-    step, but due to the generalization on the enrollment protocol
-                                         ^
-    described in this document its regarded as a separate phase here.
+    step, but due to the generalization of the enrollment protocol
+                                         ^
+    described in this document it is regarded as a separate phase here.
+                                 ++

fixed



Section 4.3, paragraph 1
-    certification requests.  As this is supported by various existing
-                             ^^^^
+    certification requests.  This is supported by various existing
+                             ^

Simplified the whole sentence


Section 4.3, paragraph 3
-       protocols such as CMC and SCEP, or for newly defined protocols are
-                                          ----

replaced "or" by "as well as".

Section 4.3, paragraph 5
-    supported at the registrar.
-              ^^
+    supported by the registrar.
+              ^^

changed



Section 4.3, paragraph 7
-    The following list of endpoints provides an illustrative example for
-                                                                      --
+    The following list of endpoints provides an illustrative example of
+                                                                     +

fixed



Section 5.1, paragraph 5
-       Alternatively, the registrar MAY modify the contents of requested
+       Alternatively, the registrar MAY modify the contents of the requested
+                                                               ++++

fixed



Section 5.1, paragraph 12
-       asynchronous enrollment) within CMP is needed, it SHALL be
-                                ^^^^^^
+       asynchronous enrollment) If CMP is needed, it SHALL be
+                                ^^

replaced "within CMP is needed" by "is needed at the CMP level"



Section 5.1, paragraph 13
-    Note: The way in which messages are exchanged between the registrar
-          ^^^^ -----------
-    and backend PKI components (i.e., RA or CA) is out of scope of this
-                                                ^^
+    Note: How messages are exchanged between the registrar
+          ^^
+    and backend PKI components (i.e., RA or CA) are out of scope of this
+                                                ^^^

simplified as suggested, while "is -> are" is a false positive



Section 5.1, paragraph 14
-    In this scenario, of course the EST-specific parts of
+    In this scenario, of course, the EST-specific parts of
+

changed



Section 6, paragraph 3
-    LCMPP being necessary and sufficient.
-          -- ^^
+    LCMPP is necessary and sufficient.
+           ^

changed



Section 7, paragraph 1
-    The security considerations laid out in BRSKI [RFC8995] apply for the
-                                                                  ^ -
+    The security considerations laid out in BRSKI [RFC8995] apply to the
+                                                                  ^

fixed



Section 7, paragraph 2
-    cannot circumvent the registrar in the decision whether it is granted
+    cannot circumvent the registrar in the decision of whether it is granted
+                                                    +++

fixed


Section 7, paragraph 9
-    eavesdroppers insight on which devices are bootstrapped into the
-                           -
+    eavesdroppers insight into which devices are bootstrapped into the
+                          +++

changed



Section 7, paragraph 9
-    TLS.  On the link between the pledge and the registrar this is easily
+    TLS.  On the link between the pledge and the registrar, this is easily
+                                                          +

changed



"Appendix A.", paragraph 1
-    This informative annex provides some detail to the application
-                                                 -
+    This informative annex provides some details about the application
+                                               + ++++

fixed



"A.1.", paragraph 1
-    asynchronous enrollment will include generating certification
+    asynchronous enrollment will include generating a certification
+                                                    ++

false positive


"A.1.", paragraph 2
-    UNISIG has included a CMP profile for enrollment of TLS client and
+    UNISIG has included a CMP profile for the enrollment of TLS client and
+                                          ++++

fixed



"A.2.", paragraph 1
-    controllers that are connected with each other in a local network but
-                                   -- ------- -------

changed "with" by "to”

"A.2.", paragraph 2
-    network as preparation for the operational phase.  In this case,
-            ^^
+    network in preparation for the operational phase.  In this case,
+            ^^

fixed



"A.3.", paragraph 1
-    of several enrollment protocols in order to support the various
-                                    ---------
simplified "in order to" to "to"

"A.4.", paragraph 1
-    mutual authentication is required.  In both cases the charging point
+    mutual authentication is required.  In both cases, the charging point
+                                                     +

changed



"Appendix B.", paragraph 6
-       one and thus is no more applicable here.
-                          ^  -
+       one and thus is no longer applicable here.
+                          ^ +++


No change done as Appendix B will be deleted by the RFC Editor

"Abstract", paragraph 1

s/authenticated independently of/authenticated independent of/

fixed



Section 3.2, paragraph 8
>    *  CMC [RFC5272] also supports utilizing a shared secret (passphrase)
>       or an existing certificate to protect certification requests,
>       which can be either in CRMF or PKCS #10 structure.  The proof of
>       identity can be provided as part of a FullCMCRequest, based on CMS
>       [RFC5652] and signed with an existing IDevID secret.  Thus also
>       CMC does not rely on the security of the underlying message
>       transfer.

s/Thus also CMC/Thus CMC/

changed


Section 4, paragraph 1
>    To enable using alternative certificate enrollment protocols
>    supporting end-to-end authentication, asynchronous enrollment, and
>    more general system architectures, BRSKI-AE provides some
>    generalizations on BRSKI [RFC8995].  This way, authenticated self-
>    contained objects such as those described in Section 3 above can be
>    used for certificate enrollment, and RA functionality can be
>    distributed freely in the target domain.

s/functionality can be distributed/functionality can be deployed/
Here really was meant to distribute (over more than one component).
Yet since this was hard to understand, made the change as suggested and added.
OLD
and RA functionality can be distributed freely in the target domain.
NEW
and RA functionality can be deployed freely in the target domain.
Parts of the RA functionality can even be distributed over several nodes.


Section 4.1, paragraph 8

s/different to/different from/

fixed



Section 4.2.4, paragraph 1
>    This replaces the EST integration for PKI bootstrapping described in
>    [RFC8995], Section 5.9 (while [RFC8995], Section 5.9.4 remains as the
>    final phase, see below).

s/This/This section/

changed


s/Section 5.9.4/Section 5.9.4 of [RFC8995]/

This rendering is automatic - changing it would remove the link to the section.



Section 4.2.4, paragraph 13

s/certification request/Certificate Request/
We generally write "certification request", while "Certificate Request" is used just for the syntax in this figure.

Section 4.2.4, paragraph 17
>    *  PKI/Registrar Confirm (8): An acknowledgment by the PKI that MUST
>       be sent on reception of the Cert Confirm.


s/Cert Confirm/Certificate Confirm/

fixed



Section 4.3, paragraph 1
>    BRSKI-AE provides generalizations to the addressing scheme defined in
>    BRSKI [RFC8995], Section 5 to accommodate alternative enrollment
>    protocols that use authenticated self-contained objects for
>    certification requests.  As this is supported by various existing
>    enrollment protocols, they can be employed without modifications to
>    existing RAs/CAs supporting the respective enrollment protocol (see
>    also Section 5).


s/enrollment protocols, they/enrollment protocols. They/

Simplified the text

OLD
BRSKI-AE provides generalizations to the addressing scheme defined in
BRSKI [RFC8995], Section 5 to accommodate alternative enrollment
protocols that use authenticated self-contained objects for
certification requests.  As this is supported by various existing
enrollment protocols, they can be employed without modifications to
existing RAs/CAs supporting the respective enrollment protocol (see
also Section 5).

NEW

BRSKI-AE provides generalizations to the addressing scheme defined in
BRSKI [RFC8995], Section 5 to accommodate alternative enrollment
protocols that use authenticated self-contained objects for certification
requests. In existing RAs/CAs supporting such an enrollment protocol
(see also Section 5), these generalizations can be employed without
modifications.



Section 4.3, paragraph 1
>    The addressing scheme in BRSKI for certification requests and the
>    related CA certificates and CSR attributes retrieval functions uses
>    the definition from EST [RFC7030], here on the example of simple
>    enrollment: "/.well-known/est/simpleenroll".  This approach is
>    generalized to the following notation: "/.well-known/<enrollment-
>    protocol>/<request>" in which <enrollment-protocol> refers to a
>    certificate enrollment protocol.  Note that enrollment is considered
>    here a message sequence that contains at least a certification
>    request and a certification response.  The following conventions are
>    used to provide maximal compatibility with BRSKI:


s/[RFC7030], here on/[RFC7030]. Here is/

changed



Section 4.3, paragraph 1
>    *  <enrollment-protocol>: MUST reference the protocol being used.
>       Existing values include 'est' [RFC7030] as in BRSKI and 'cmp' as
>       in [RFC9483] and Section 5.1 below.  Values for other existing
>       protocols such as CMC and SCEP, or for newly defined protocols are
>       outside the scope of this document.  For use of the <enrollment-
>       protocol> and <request> URI components, they would need to be
>       specified in a suitable RFC and placed into the Well-Known URIs
>       registry, as for EST in [RFC7030].


s/as for/just as/

changed



Section 5, paragraph 0
> 5.  Instantiation to Existing Enrollment Protocols

s/Instantiation to/Instantiation of/
Changed "to" to "with"

Section 5.1, paragraph 0
> 5.1.  BRSKI-CMP: Instantiation to CMP

s/Instantiation to/Instantiation of/

Changed

OLD

BRSKI-CMP: Instantiation to CMP

NEW

BRSKI-CMP: BRSKI-AE instantiated with CMP



Section 5.1, paragraph 8
>    BRSKI-AE with CMP can also be combined with Constrained BRSKI
>    [I-D.ietf-anima-constrained-voucher], using CoAP for enrollment
>    message transport as described by CoAP Transport for CMP [RFC9482].
>    In this scenario, of course the EST-specific parts of
>    [I-D.ietf-anima-constrained-voucher] do not apply.

Suggest to drop the phrase "of course".

done

Document references draft-ietf-anima-constrained-voucher-23, but -24 is the
latest available revision.

The latest version is added automatically and will be updated with the next version of BRSKI-AE.

Section 1.1, paragraph 2
> e reason that EST cannot be used is because it does not support multiple hop
>                                  ^^^^^^^^^^
The word "because" means "for the reason that" and thus introduces redundancy.

I did not find this item in the text, presumably due to a change in between



Section 2, paragraph 21
> on of the certification request. Typically this is achieved by a signature u
>                                  ^^^^^^^^^
A comma may be missing after the conjunctive/linking adverb "Typically".

added it


Section 3, paragraph 4
> ity protection and proof of possession- Typically a self-signature is used to
>                             ^^^^^^^^^^^^^^^^^^^^^
This word seems to be formatted incorrectly. Consider fixing the spacing or
removing the hyphen completely.

The hyphen was misplaced - removed it.


Section 3.2, paragraph 6
> ned with an existing IDevID secret. Thus also CMC does not rely on the securi
>                                     ^^^^
A comma may be missing after the conjunctive/linking adverb "Thus".

added it


Section 7, paragraph 2
> e 4 of the BRSKI-AE draft 04 status update at IETF 116. [I-D.eckert-anima-brs
>                                     ^^^^^^
Possible agreement error. The noun "update" seems to be countable.

Re-phrased to: "of the status update on the BRSKI-AE draft 04 at IETF 116"



Section 7, paragraph 7
> munications security - Part 9: Cyber security key management for power syste
>                                ^^^^^^^^^^^^^^
The word "cybersecurity" is spelled as one.

Agreed, but in this IEEE document title it was spelled as given.



Section 7, paragraph 9
> American Reliability Council, "Cyber Security -Electronic Security Perimeter
>                                ^^^^^^^^^^^^^^
The word "cybersecurity" is spelled as one.

Agreed, but in this NERC document title it was spelled as given.





Section 9.2, paragraph 4
> bset-137 specifying the ETRAM/ETCS online key management for train control s
>                                    ^^^^^^
Do not mix variants of the same word ("online" and "on-line") within a single
text.

Usually the word is written as one, but in that UNISIG document title it was spelled with a hyphen.

Mahesh Jethanandani
mjethanandani@gmail.com<mailto:mjethanandani@gmail.com>