The main issue I have is with the term “end-to-end security”, both in general and especially as it’s applied in the text quoted below.  I don’t know what that term means, just as the general term “security” doesn’t have much meaning by itself.  “End-to-end encryption” is what we usually use, and its meaning is clear, but that isn’t what you generally mean in this document.  I suggest avoiding “end-to-end security” throughout, and being more specific about what you’re actually talking about in each instance (encryption, confidentiality, integrity, or whatever).

— Section 1.1.2 —

   This approach
   supports end-to-end security, without the need to trust in
   intermediate domain components.

This doesn’t seem to match what we usually think of as e2e security — which is better referred to as e2e encryption.  As I say above, I suggest avoiding that term here.  What you have is integrity protection for the enrollment objects, without having (and without needing) e2e encryption of the enrollment process.

   This
   enhancement of BRSKI is named BRSKI-AE, where AE stands for
   *A*lternative *E*nrollment and for *A*synchronous *E*nrollment.

It doesn’t seem a good practice to say that a particular abbreviation can stand for two different things.  I think it would be better to pick one to call out as what “AE” stands for.

— Section 2 —

Nit: “comprising of” isn’t proper English; it should just be “comprising” (or “composed of”, but “comprising” is better here).  Two instances.

— Section 4.1 —

   Consequently, the authentication and authorization of the
   certification request MAY be done by the domain registrar and/or by
   other domain components.  These components may be offline or reside
   in some central backend of the domain operator (off-site)

The “MAY” in the first sentence is just like the “may” in the second sentence: it should be lower case, as it’s not used as a BCP 14 key word.  (The other “MAY” at the end of the same paragraph looks fine.)

— Section 4.2.3 —

   The only generally MANDATORY message exchange is for the actual
   certificate request and response.

“MANDATORY” is not a BCP 14 key word.  Do you mean it as plain English “mandatory”?  Or do you mean it to be the BCP 14 key word “REQUIRED”?  In the diagram below (Figure 2) you should definitely use “REQUIRED” instead of “MANDATORY”.

— Section 4.3 —

   *  <enrollment-protocol>: MUST reference the protocol being used.
      Existing values include EST [RFC7030] as in BRSKI and CMP as in
      [I-D.ietf-lamps-lightweight-cmp-profile] and Section 5.1 below.
      Values for other existing protocols such as CMC and SCEP, or for
      newly defined protocols, require their own specifications for
      their use of the <enrollment-protocol> and <request> URI
      components and are outside the scope of this document.

They require not just their own specifications, but registration of their <enrollment-protocol> into the Well-Known URIs registry.  It would be good to say that, perhaps using RFC 7030 as an example.

   A pledge SHOULD use the endpoints defined for the enrollment
   protocol(s) that it is capable of.

Why “SHOULD” and not “MUST”?  What are the alternatives, why might the pledge not use the defined endpoints, and what are the consequences of not doing so?

— Section 5.1 —

         In certificate response messages the caPubs field, which
         generally in CMP may convey CA certificates to the requester,
         SHOULD NOT be used.

Similar to above: Why “SHOULD NOT”?  What happens if it *is* used?  Should there be any instructions about what to do with it (or ignore it, or whatever)?

— Section 7 —

You correctly note that the CMP security considerations apply.  Yet it strikes me that there might be security implications that are specific to applying CMP to BRSKI, as it’s a different way of binding things and authenticating than has been used in BRSKI before.  As I don’t know a lot about BRSKI to start with, I have no specific suggestions here, but I wonder how much this was thought about, and what the BRSKI-specific implications of this mechanism really are.  For example, are there possible issues with an attacker intercepting the data elements here, even if the elements are integrity-protected.  Are there possible issues with an attacker preventing delivery of some elements, or injecting the attacker’s own self-signed elements?  That sort of thing, which EST is protected from by the use of TLS.

Looking at the building automation example, for instance, which talks about many sensors, actuators, and controllers, could an attacker gain useful information by knowing what devices (and/or what types of devices) are being registered, or by blocking the registration of certain devices to create areas of vulnerability?

Just stuff to think about, if it hasn’t been considered and ruled out already.

And thanks for considering my review!