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

Mahesh Jethanandani <mjethanandani@gmail.com> Wed, 05 June 2024 18:51 UTC

Return-Path: <mjethanandani@gmail.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 55A11C169431; Wed, 5 Jun 2024 11:51:19 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i-o3QUcqK52T; Wed, 5 Jun 2024 11:51:14 -0700 (PDT)
Received: from mail-pf1-x42e.google.com (mail-pf1-x42e.google.com [IPv6:2607:f8b0:4864:20::42e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAF5BC137370; Wed, 5 Jun 2024 11:51:14 -0700 (PDT)
Received: by mail-pf1-x42e.google.com with SMTP id d2e1a72fcca58-7024d571d8eso107499b3a.0; Wed, 05 Jun 2024 11:51:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1717613474; x=1718218274; darn=ietf.org; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=10LvRS0QqZx6m7kj/vodJW+ZbI8B2wsktB2pc++Q/tE=; b=NVyCi8Akpt3in7zZW709FEywA8HWi3CU6++twsmxSnLPME/rZG6LDdsU4HzIK6qw51 Va1VqmR+gqbncs7OtbE5y+iy8dkz+/jDghmrjm/CfzkH3JnFph9HZe8o4qm/NAzqEO6c 88qhMIFZ/lwJ8NpmT+C6ClmwyphhP9W8j4VvusTNG3bVAildGJVpoiKZD17huSPcvNX2 idri5AfzoHMai+kCeFN3rBb5PB+C/wFU/h3uspDUIG3EMBmsp4pEJnSJ7ifnJQsEv6AF N6804VkxYyfANLiM9w97ZYbO92VHBcbfhs6vmceWJPakDzItcTKHTuVIWmefiBIkP73p 5Ftw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1717613474; x=1718218274; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=10LvRS0QqZx6m7kj/vodJW+ZbI8B2wsktB2pc++Q/tE=; b=fBpwHO2z/DySXAutI+TEENysUH9fLuDN0LwDc9iEBnACiBDAktX7qC6RWgElUOAC2X Pk+JCcPOPIYjvCOi7z0Auk/msIm27mrn/Jqs1uexOlTX3OrKEP+A0aHrbP97A6ZKaqN8 aBRC6dFRXbbKQrqwx/EWnoXaBAuM0XFbjTkwuadPqJUfDg5dLkqWHExsxM8CBMf7eldy L/4jqI+rBC8T2N3hHOaBNziIlz3/+3X/1VXA6GhCt9+EwNpqvlXxpydSN9CReyTbU9d/ M/ep7+8dyqvwjGmlCO4onxVwzXGwtE51AFh08tGW0AcH2nMCbpPRVTSpIlTpJY9JMsz0 9irQ==
X-Forwarded-Encrypted: i=1; AJvYcCXaDaClsRlm9y5xmzmp1IjyL+YNo/g0fYMBfHpr38m10Nu6ayJr92EmAxsIl09Xqwgzfbip9gu+YtFM+RBVI2aTeJDS0/3JC75Fui/F2Vgp7+SLfJqj
X-Gm-Message-State: AOJu0YzsKPY5Ool9CzOpj9UbxzlrLhrSL6AIRRgDkjf2aN9gQmcPcawj XI0J6Kb7pkT3NuwpNBYPMOCcZVsUv1NZoi8I/xo3fdSYmKmGpz8LNGqqjA==
X-Google-Smtp-Source: AGHT+IGWwjTaNPx1T8dkQKSquc2M7wejrLTfJ8e4XhrpqWWWj0HSc4btkIJqqGhbzFvElZ7ugt+Scg==
X-Received: by 2002:a05:6a20:a121:b0:1ac:3b5d:a3eb with SMTP id adf61e73a8af0-1b2b710b6d7mr4119702637.39.1717613472871; Wed, 05 Jun 2024 11:51:12 -0700 (PDT)
Received: from smtpclient.apple ([70.234.233.187]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-70251b2ecb0sm7487860b3a.197.2024.06.05.11.51.10 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Jun 2024 11:51:10 -0700 (PDT)
From: Mahesh Jethanandani <mjethanandani@gmail.com>
Message-Id: <AB277804-228A-42A1-BCF2-49906C478AF6@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_8CF99550-F2BD-4205-8F30-7BEBEE4050F3"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.15\))
Date: Wed, 05 Jun 2024 11:51:09 -0700
In-Reply-To: <AS8PR10MB63375AAAFAAABF0B38F07DBBF3FF2@AS8PR10MB6337.EURPRD10.PROD.OUTLOOK.COM>
To: "Fries, Steffen" <steffen.fries@siemens.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> <AS8PR10MB63375AAAFAAABF0B38F07DBBF3FF2@AS8PR10MB6337.EURPRD10.PROD.OUTLOOK.COM>
X-Mailer: Apple Mail (2.3654.120.0.1.15)
Message-ID-Hash: U2JDDYKEZFF5OXHCECQXJT6NZ52GTI3F
X-Message-ID-Hash: U2JDDYKEZFF5OXHCECQXJT6NZ52GTI3F
X-MailFrom: mjethanandani@gmail.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: "draft-ietf-anima-brski-ae@ietf.org" <draft-ietf-anima-brski-ae@ietf.org>, "anima-chairs@ietf.org" <anima-chairs@ietf.org>, "anima@ietf.org" <anima@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [Anima] Re: 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/_RzetPuMvV30ORTXjNchb92CwaI>
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>

Hi Steffen,

Thanks for addressing my comments. Based on the changes and updates made in -11 version of the draft, I will progress the draft.

Cheers.

> On Jun 3, 2024, at 6:56 AM, Fries, Steffen <steffen.fries@siemens.com> wrote:
> 
> 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 <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 <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 <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>
>  


Mahesh Jethanandani
mjethanandani@gmail.com