Subject: Re: [Anima] Proposal of enhancing the BRSKI example scope with CMP

From: Toerless Eckert <[email-masked]>
Date: Thu, 1 Mar 2018 18:36:19 +0100

On Thu, Mar 01, 2018 at 06:45:27AM +0000, Fries, Steffen wrote:
> We came up with the proposal as the current title of the document gives the impression, that BRSKI would solely work with EST as it is the only example stated. As we see different use cases, which already target CMP, we thought it would be good to cover it in the base document. If the schedule of the document is that tight, then an extension in terms of a separate document might be the way to go.

Lets see, i think the WG hat is most fitting for this email, but not quite sure:

Its not only the timing, its also the complexity of a resulting document. How about we wire an RFC that descrbies both IPv4 and IPv6 together in one doc ? Would you think thats a good document structure ? The comparison may suck, but i think the resulting documents would suck even more ;-)

We already have in all our first round documents that we 
>re just finishing now the problem of scope creep and i wish we could have more modularized document structure, but i think this is a common problem of starting working groups, that if you start with many documents, especially when you're interdepending, you increase the chance of failing on a piece. 

Once we have shown success of round one with BRSKI/ACP, i think it will be a lot easier, to get variations of these themes as working group drafts, especially when there is a clear industry desire for such variations:

For once, a variation can always be less explanatory by hopefully being able to refer to
the base document (like BRSKI) for explanations and/or reuse. 

Secondly, the scope of such new documents is likely much easier to set than it was with the
original documents.

Thirdly, IMHO, such variations might not even need re-chartering as long as they can be
interpreted to do the same thing as what we've already chartered.

In the case of the ''BRSKI'' charter item, i would say that procedures for better support of 
offline device bootstrap should already be in charter. BRSKI has already some loose suggestions
in appendices. Of course, AD ultimately decides (after WG proposes ;-).

I personally do very much welcome document submissions for work in this area, even if just
to stop scope creep discussion for the BRSKI document, but i think as a WG we should not
try to accept this as a WG item before we have pushed BRSKI to IESG, but i would really like that to
happen before 102. More importantly though, it would be nice to discuss what scope specific documents
should have. We already have variations of BRSKI and vouchers coming up, and i can see
especially for supporting offline operations a lot of possible varieties.

Cheers
    Toerless

> >    Brian
> 
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima

-- 
---
[email-masked]

---

From: "Fries, Steffen" <[email-masked]>
Date: Thu, 1 Mar 2018 20:40:39 +0000

> On 1. Mar 2018, at 18:36, Toerless Eckert <[email-masked]> wrote:
> 
Well, I see were you are heading to ;-) The intention of the proposal was not to increase the complexity of the base document. But given your example, having a base document that is agnostic to the enrollment and enhancement documents that map an enrollment protocol would probably be ideal regarding complexity. From your  statement below, I conclude that the process of document creation and scoping can be cumbersome.  But‚ I‘m certainly not in the position to argue about document structure as I’m stepping in late. 

> the base document (like BRSKI) for explanations and/or reuse. 
This supports my impression of the base document and additional enhancement documents.
> Secondly, the scope of such new documents is likely much easier to set than it was with the
Agreed

> in appendices. Of course, AD ultimately decides (after WG proposes ;-).
Step 5 in section 2.1 in BRSKI mentions EST as example for an enrollment protocol. Based on that I assumed other enrollment protocols would in general applicable as well.

> happen before 102.
You made it clear that finishing the base spec has the highest priority.

> More importantly though, it would be nice to discuss what scope specific documents
Yes, I‘m sure there are several approaches for offline enrollment. The reason for proposing a profile of CMP basically stems on its success in existing deployments for online and offline use cases in a single solution. 

Regards
   Steffen

---

From: Michael Richardson <[email-masked]>
Date: Thu, 01 Mar 2018 16:39:11 -0500

Fries, Steffen <[email-masked]> wrote:
    >> <[email-masked]> wrote:
    >>
    >> On 01/03/2018 11:46, Michael Richardson wrote: ...
    >>>> Even though the BRSKI document is already advanced, we would like to
    >>>> propose to also include CMP as further example for certificate
    >>>> enrollment in BRSKI. This inclusion would make it also easier for
    >>>> other standards or frameworks to consider security bootstrapping
    >>>> based on BRSKI.
    >>>
    >>> I think that it would be very difficult to hack CMP into the BRSKI
    >>> document at this point.
    >>
    >> As a matter of principle, it seems better to get BRSKI published as
    >> quickly as possible to meet the WG milestone, and then publish any
    >> extensions as separate documents.

    > I was looking into the charter and based on the date of the initial
    > draft of the document I somehow feared that the document is already in
    > the final state. I did not find an expected timeline on when the draft
    > is expected to be finalized.

As soon I get back to the Shepherd review (sometime later tonight perhaps),
then I hope that we'll get into WGLC.

    >> It seems like a good idea to work on such extensions. But one step at
    >> a time :-).

    > We came up with the proposal as the current title of the document gives
    > the impression, that BRSKI would solely work with EST as it is the only
    > example stated. As we see different use cases, which already target
    > CMP, we thought it would be good to cover it in the base document. If
    > the schedule of the document is that tight, then an extension in terms
    > of a separate document might be the way to go.

BRSKI is an extension of EST.
Making it an extension of CMP would be a different protocol.

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