Re: [Anima] Adoption call for draft-fries-anima-brski-async-enroll-03, ends July 1st 2020

["Fries, Steffen" <[e-mail]>]

Hi Michael

> -----Original Message-----
> From: Anima <[e-mail]> On Behalf Of Michael Richardson
> Sent: Montag, 22. Juni 2020 02:59> 
> 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.

> ---
> 
> While I think that section 4 is very well fleshed out, I think that section 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 any duplication of BRSKI approaches already described and kept unchanged.

> I think that use of EST is probably wrong: more choices here is not better.
> CMP is the right protocol, because there will not be a consistent transport 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 enrollment 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 how fullcmc is supported, which may go into a similar direction as the lightweight CMC. 
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 part 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 the original approach to keep the registrar enhancements focused on the enrollment only. 

> 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 section 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 integrated into
> existing CMP infrastructure.
Good point. While we are currently focusing on being protocol agnostic, object 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 encodings supported by the registrar as context type. 

Best regards
Steffen
> 
> --
> Michael Richardson <[e-mail]>, Sandelman Software Works
> -= IPv6 IoT consulting =-