From: "Fries, Steffen" <steffen.fries@siemens.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>
CC: Sheng Jiang <jiangsheng@huawei.com>, Anima WG <anima@ietf.org>,
 "anima-chairs@ietf.org" <anima-chairs@ietf.org>, "Rob Wilton (rwilton)"
 <rwilton@cisco.com>
Thread-Topic: [Anima] Adoption call for
 draft-fries-anima-brski-async-enroll-03, ends July 1st 2020
Thread-Index: AQHWSDBtaclimbANOkiK+Y6kXbVaTajkH8nQ
Date: Mon, 22 Jun 2020 08:41:41 +0000
Message-ID: <9641bc176f334dec818c0105e64d4a39@siemens.com>
References: <f8c2df730dad489d88303c6d8682caee@huawei.com>
 <8922.1592787566@localhost>
In-Reply-To: <8922.1592787566@localhost>
Accept-Language: en-US, de-DE
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/WQLr3QraDn0fDAK7s2kJF0eVdC4>
Subject: Re: [Anima] Adoption call for
 draft-fries-anima-brski-async-enroll-03, ends July 1st 2020
Precedence: list

Hi Michael

> -----Original Message-----
> From: Anima <anima-bounces@ietf.org> On Behalf Of Michael Richardson
> Sent: Montag, 22. Juni 2020 02:59>=20
> I have read draft-fries-anima-brski-async-enroll-03 and I would be happy =
to
> have it as the basis for an extension.   PLEASE ADOPT.

Thanks for the support.

> ---
>=20
> While I think that section 4 is very well fleshed out, I think that secti=
on 5 will
> need revisions.  While it attempts to mirror the structure of the BRSKI
> document, I think that probably is both unnecessary, and also too verbose=
.
I'm currently about to update that section as well as section 6 to remove a=
ny duplication of BRSKI approaches already described and kept unchanged.

> I think that use of EST is probably wrong: more choices here is not bette=
r.
> CMP is the right protocol, because there will not be a consistent transpo=
rt to
> secure.  I am not sure how to integrate RFC8366 vouchers into CMP.
We strive for a protocol agnostic approach, which allows to use existing en=
rollment protocols. As EST also supports signed objects with fullcmc it can=
 be used as well. It would most likely require to enhance EST to specify ho=
w fullcmc is supported, which may go into a similar direction as the lightw=
eight CMC.=20
Also, in BRSKI we did not change the defined voucher exchange to be carried=
 out with other enrollment protocols. We have not seen this as integral par=
t of EST. At least for CMP it would be possible to transmit the voucher as =
part of a general message. But we tried to leave as much as possible from t=
he original approach to keep the registrar enhancements focused on the enro=
llment only.=20

> I believe that this work needs focus on the lightweight CMP profile.
> I don't know CMP well enough to comment on how to do this yet.
We currently have a usage mapping to lightweight CMP and EST included in se=
ction 7.

> Since we are dealing with signed objects, I wonder if COSE/CoID objects
> would not be better signed containers.  That's clearly *not* bits-on-the-=
wire
> CMP, but if it's 1:1 with CMP objects, then it may be easier to integrate=
d into
> existing CMP infrastructure.
Good point. While we are currently focusing on being protocol agnostic, obj=
ect agnostic came into the game as well. In the next update we also support=
 a discovery mechanism for supported enrollment protocols on the registrar,=
 which should also allow to transport the information about the different e=
ncodings supported by the registrar as context type.=20

Best regards
Steffen
>=20
> --
> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
> -=3D IPv6 IoT consulting =3D-