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

From: Sheng Jiang <[email-masked]>
Date: Thu, 18 Jun 2020 09:27:33 +0000

Hi, ANIMAer,

This message starts a two-week adoption call, it ends on July 1st, 2020.

draft-fries-anima-brski-async-enroll-03 has been presented to the WG for a long while and the WG showed good interest and had discussions. The draft is now clearly in scope of ANIMA charter 2 that was adopted around IETF106. The authors asked for adoption of the document. Giving the dependent BRSKI has passed the IESG evaluation, the chairs feel that it may be the right time to call the adoption.

We therefore are asking the ANIMA working group for adoption of the following work:

Title:    Support of asynchronous Enrollment in BRSKI

Name:     draft-fries-anima-brski-async-enroll-03

Authors:  S. Fries, H. Brockhaus and E. Lear

URL:      https://datatracker.ietf.org/doc/draft-fries-anima-brski-async-enroll/

This document is intended to become a standards track ANIMA WG document.

Please express your support or rejection. If you think this document should _not_ be adopted, please also explicitly indicate the reasons.

Regards,

Sheng

---

From: Michael Richardson <[email-masked]>
Date: Sun, 21 Jun 2020 20:59:26 -0400

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.

---

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 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.

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.
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.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: "Fries, Steffen" <[email-masked]>
Date: Mon, 22 Jun 2020 08:41:41 +0000

Hi Michael

> -----Original Message-----
> From: Anima <[email-masked]> On Behalf Of Michael Richardson
> Sent: Montag, 22. Juni 2020 02:59> 

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
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.

> 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 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
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

---

From: Eliot Lear <[email-masked]>
Date: Mon, 22 Jun 2020 10:56:45 +0200

Hi Sheng

Thanks for initiating this call.  As one of the co-authors, it should surprise you not at all the I have read it, and indeed have modestly contributed to it (Steffen did the heavy lifting).  I support its adoption.

Eliot

> On 18 Jun 2020, at 11:27, Sheng Jiang <[email-masked]> wrote:
> 
> Hi, ANIMAer,
>  
> URL:      https://datatracker.ietf.org/doc/draft-fries-anima-brski-async-enroll/ <https://datatracker.ietf.org/doc/draft-fries-anima-brski-async-enroll/>
>  
> _______________________________________________
> Anima mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/anima <https://www.ietf.org/mailman/listinfo/anima>

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 23 Jun 2020 08:29:32 +1200

Hi,

I believe this work fills an important gap in BRSKI scenarios so it should be adopted.

A couple of nits while I'm here: 

1) I think the section "History of changes" should be an Appendix, since it is distracting to the reader at present. Also it should be marked "[RFC Editor: please delete]".

2) The Abstract is too long. I think everything from "In the context of ..." belongs in the Introduction.

Regards
   Brian Carpenter

>> On 18 Jun 2020, at 11:27, Sheng Jiang <[email-masked] <mailto:[email-masked]>> wrote:
>>
>> Hi, ANIMAer,
>>  
>> https://www.ietf.org/mailman/listinfo/anima
> 
> 
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima
>

---

From: "Fries, Steffen" <[email-masked]>
Date: Wed, 24 Jun 2020 07:29:51 +0000

Hi Brian,

Thank you for the support. Points taken. I will consider them in the next update.

Best regards
Steffen

> From: Anima <[email-masked]> On Behalf Of Brian E Carpenter
> Sent: Montag, 22. Juni 2020 22:30
> To: Sheng Jiang <[email-masked]>
> Cc: [email-masked]; Rob Wilton (rwilton) <[email-masked]>; Anima
> WG <[email-masked]>
> Subject: Re: [Anima] Adoption call for draft-fries-anima-brski-async-enroll-
> 03, ends July 1st 2020
> 
> Hi,
> 
> 1) I think the section "History of changes" should be an Appendix, since it is
> distracting to the reader at present. Also it should be marked "[RFC Editor:
> please delete]".
> 
> >> draft-fries-anima-brski-async-enroll-03 has been presented to the WG for
> a long while and the WG showed good interest and had discussions. The
> draft is now clearly in scope of ANIMA charter 2 that was adopted around
> IETF106. The authors asked for adoption of the document. Giving the
> dependent BRSKI has passed the IESG evaluation, the chairs feel that it may
> be the right time to call the adoption.
> >>
> >> URL:
> >> https://datatracker.ietf.org/doc/draft-fries-anima-brski-async-enroll
> >> /
> >>
> >> Please express your support or rejection. If you think this document
> should _not_ be adopted, please also explicitly indicate the reasons.
> >>
> >> Regards,
> >>
> >> Sheng
> >>