Dear ANIMA WG,
as mentioned in the below email and in the status report at IETF 117,
the BRSKI-AE draft would be ready for AD review,
except that after end of WGLC, a rather general open issue with all
upcoming BRSKI variants has been brought up by Toerless,
namely how to signal to the pledge the capabilities of the registrar,
i.e, which BRSKI variant(s) it supports with which parameter(s).
After some forth and back, as far as the BRSKI-AE draft is concerned, it
should be sufficient to extend its currently very brief section:
*4.2.1.<https://datatracker.ietf.org/doc/html/draft-ietf-anima-brski-ae#section-4.2.1>Pledge
- Registrar Discovery
<https://datatracker.ietf.org/doc/html/draft-ietf-anima-brski-ae#name-pledge-registrar-discovery>*
The discovery is done as specified in [RFC8995
<https://www.rfc-editor.org/info/rfc8995>].
with some guidance, such as the following text:
The pledge discovers the registrar basically as specified in [RFC8995
<https://www.rfc-editor.org/info/rfc8995>].
In an engineered environment, the pledge may simply assume that the
discovered registrar
supports the BRSKI-AE variant of BRSKI with the certificate enrolment
protocol it wants to use.
Note: In case the protocol is not supported by the registrar, this
would be detected only after
the pledge sent its certificate enrolment request, on which it would
receive an error (likely at HTTP level).
This late detection might be avoided in several ways.
The registrar might be able to determine by inspecting the IdevID used
by the pledge in the voucher request
which enrolment protocol the pledge is going to use and reject the
voucher request if it does not support this protocol.
The pledge could also include in its voucher request an explicit
indication which enrolment protocol it is going to use,
such that the registrar can safely reject the request if it does not
support this protocol. This may be achieved by
a simple optional extension of the voucher request structure with a
key-value pair,
where absence implies "EST" as the default protocol, and currently the
only other defined value would be "CMP".
As a more general solution, the discovery mechanism by BRSKI may be
extended to provide beforehand to the pledge
explicit information on the capabilities of the registrar, such as the
certificate enrolment protocol(s) it supports.
This needs to be specified a separate document; at the time of writing
this specification, it is being done in [TDB informative reference
toBRSKI-discovery
<https://github.com/anima-wg/brski-discovery/blob/main/draft-ietf-anima-brski-discovery.md>].
This topic, including the current state of the proposal, is meanwhile
being handled at https://github.com/anima-wg/anima-brski-ae/issues/32.
If you have any thoughts to share on it, I ask you to let us know by
email or by commenting on that page.
In particular, in case you have objections, please raise them to the
draft authors by the end of next week.
Regards,
David
On 02.05.23 16:56, David von Oheimb wrote:
Dear Brian, Toerless, Michael, et al.,
thank you
* Brian for your comment during the WGLC,
* Toerless for your further quick shepherd review thereafter, and
* Michael for your response on the latter on how to reference EST,
all quoted below.
I've meanwhile prepared an intermediate version of the draft that is
not yet officially submitted to IETF,
i.e., a preview of version 05, available at
https://github.com/anima-wg/anima-brski-ae
The change log so far is:
* Remove entries from the terminology section that should be clear
from BRSKI
* Tweak use of the terms IDevID and LDevID and replace PKI RA/CA by
RA/CA
* Add the abbreviation 'LwCMP' for Lightweight CMP to the
terminology section
* State clearly in Section 5.1 that LwCMP is mandatory when using CMP
* Change URL of BRSKI-AE-overview graphics to slide on IETF 116
meeting material
The first two items were suggested internally by Steffen,
while the remaining ones address the below points by Toerless and Brian.
Regarding the reference to EST, the authors discussed this and came to
the conclusion
that we better keep the reference to EST [RFC 7030] as /informative/
because we do not really depend on its contents
since the EST instance of BRSKI-AE has effectively been removed from
the draft (and just remain as a theoretical option).
The only "feature" that stems from EST that we take over in BRSKI-AE,
namely the endpoint naming scheme,
is already covered by the reference to BRSKI [RFC 8995], such that
having BRSKI as a /normative/ reference fully covers this.
OTOH, the references to CMP are clearly /normative/ for the case that
BRSKI-AE is instantiated to CMP,
which we have made more explicit in the upcoming version as stated in
the above change log.
Thus we believe that we have covered all open points,
and since the IPR poll has been finished as well,
the draft would be ready for being submitted and for AD review,
but:
On Thu, 2023-04-27 at 11:02 +0000, Fries, Steffen wrote:
To: [email protected] <[email protected]>
Subject: [Anima] Design Team Meeting discussion (April 25) on
BRSKI-PRM discovery with cross relation to BRSKI-AE
Independent of the final solution picked, as BRSKI-AE is also
enhancing the functionality of a BRSKI registrar by supporting
alternative enrollment protocols, the same approach is to be intended
for BRSKI-AE as well. Therefore, we will wait with the submission of
an updated BRSKI-AE draft until the discussion has ended.
So we are holding back the draft until this has been sorted out,
most likely resulting in a small paragraph to be added to BRSKI-AE.
If there is any further comment or suggestion for improval, please let
us (the authors) know.
Best,
David
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
