Subject: [Anima] BRSKI-AE document split discussion

From: "Fries, Steffen" <[email-masked]>
Date: Mon, 2 Aug 2021 08:45:25 +0000

Hello,

Based on the discussion in the ANIMA WG last week, I would like to proceed with the discussion on the author's proposal to split the current BRSKI-AE draft (https://datatracker.ietf.org/doc/html/draft-ietf-anima-brski-async-enroll-03) to separate the contained use cases as they have developed differently. We did not finish the discussion during the meeting during lack of time, but for the way forward I would like to ask for support from the chairs to find the decision. I included this question also as open issue in the ANIMA github (https://github.com/anima-wg/anima-brski-async-enroll/issues/19)

- Use Case 1 targets the definition of requirements for a communication architecture using the existing BRSKI components and call model (pledge-initiator-mode, formerly PULL) to enable the use of alternative enrollment protocols for certificate enrollment (voucher handling untouched).

- Use Case 2 targets the specification of a reversed call model (pledge-responder-mode, formerly PUSH) in which the pledge has no or only limited connectivity to a registrar or cannot initiate requests to a registrar. To facilitate the interaction between pledge and registrar, the registrar-agent component is established. The interaction between pledge and registrar-agent results in new or enhanced data objects (voucher-request-trigger, voucher-request, voucher, enrollment-request-trigger, enrollment-request). Exchanges between registrar-agent and registrar follows BRSKI (RFC8995) and EST (RFC7030), with the enhanced objects.

Declaration of conformity to "AE" is difficult, as the use cases have developed in different directions. Therefore the proposal to split the draft into two separate documents for use case 1 and use case 2. We may also discuss, what the target for each document would be (informational / standard RFC).

If the WG is in favor of the split, the expectation would be that the resulting document would proceed as WG documents.

Please let us know what you think.

Best regards
Steffen

--
Steffen Fries
Siemens AG
T RDA CST

---

From: Michael Richardson <[email-masked]>
Date: Mon, 02 Aug 2021 15:55:42 -0400

Fries, Steffen <[email-masked]> wrote:
    > Based on the discussion in the ANIMA WG last week, I would like to
    > proceed with the discussion on the author's proposal to split the
    > current BRSKI-AE draft
    > (https://datatracker.ietf.org/doc/html/draft-ietf-anima-brski-async-enroll-03)
    > to separate the contained use cases as they have developed
    > differently. We did not finish the discussion during the meeting during
    > lack of time, but for the way forward I would like to ask for support
    > from the chairs to find the decision. I included this question also as
    > open issue in the ANIMA github
    > (https://github.com/anima-wg/anima-brski-async-enroll/issues/19)

    > Declaration of conformity to "AE" is difficult, as the use cases have
    > developed in different directions. Therefore the proposal to split the
    > draft into two separate documents for use case 1 and use case 2. We may
    > also discuss, what the target for each document would be (informational
    > / standard RFC).

...

    > If the WG is in favor of the split, the expectation would be that the
    > resulting document would proceed as WG documents.

Are there common parts that would argue for three documents
(B--referencing-->A, and C--referencing-->A)

"A" could also be RFC8366bis.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 3 Aug 2021 09:06:39 +1200

> (B--referencing-->A, and C--referencing-->A)

That was my question too. Splitting the document but having
Part 1 normatively reference Part 2 would be unfortunate.
 
> "A" could also be RFC8366bis.

Then we'd have 3 documents as an AUTH48 cluster, right? But
if the result is a more logical set of documents for future
readers, it's the right thing to do.

   Brian

---

From: Michael Richardson <[email-masked]>
Date: Mon, 02 Aug 2021 21:50:05 -0400

> readers, it's the right thing to do.

It's only an issue if the references are circular.

We do get clusters with the relationship is a DAG, but they aren't as much of
a problem, and just represent the RPC being overworked, I think.

---

From: "Fries, Steffen" <[email-masked]>
Date: Tue, 3 Aug 2021 15:01:41 +0000

Hi Michael, hi Brian,

> -----Original Message-----
> From: Brian E Carpenter <[email-masked]>
> Sent: Montag, 2. August 2021 23:07
> (https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata
> tracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-anima-brski-async-enroll-
> 03&amp;data=04%7C01%7Ccef9763c-149c-4881-b9c2-
> 5fedc277663a%40ad011.siemens.com%7C01cc5c134fa141586f2c08d955f9702
> d%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C6376353520778173
> 88%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM
> zIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=VikJIzx0apXELx7
> q8yDp7hVwgHnEU3HwIvPq6nAlZk8%3D&amp;reserved=0)
> > (https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit
> > hub.com%2Fanima-wg%2Fanima-brski-async-
> enroll%2Fissues%2F19&amp;data=0
> > 4%7C01%7Ccef9763c-149c-4881-b9c2-
> 5fedc277663a%40ad011.siemens.com%7C01
> >
> cc5c134fa141586f2c08d955f9702d%7C38ae3bcd95794fd4addab42e1495d55a%
> 7C1%
> >
> 7C0%7C637635352077817388%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4
> wLjAwMDAiL
> >
> CJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=jxU
> xUpv
> > XcTLXNjcXwRMgEUxtA7TlK1RzMyJpOM%2BXWks%3D&amp;reserved=0)
> >
> That was my question too. Splitting the document but having Part 1
> normatively reference Part 2 would be unfortunate.
> 
> Then we'd have 3 documents as an AUTH48 cluster, right? But if the result is a
> more logical set of documents for future readers, it's the right thing to do.
> 

The two use cases have technically less in common regarding the specific realization. Both are intended for scenarios in which the pledge has no or limited connectivity to a backend.
Use Case 1 is relying on RFC 8995 for communication flow and for the voucher handling, but targets to use alternative enrollment protocols to achieve a proof-of-identity binding to the certification request directly without relying on TLS to be able to "store and forward "certification requests". For alternative enrollment, use case 1 could use the Lightweight CMP profile https://datatracker.ietf.org/doc/draft-ietf-lamps-lightweight-cmp-profile/ to achieve its goal. So this document would have no reference to use case 2.

Use case 2, as currently described,  instead reverses the communication flow to let the pledge be a server by introducing the registrar-agent as new component. The communication between the registrar-agent and the pledge is defined based on the exchange of JOSE objects, which provide proof-of-identity on a message level to be independent of an underlying TLS connection. This also allows to utilize BTLE for instance as transport. The communication from the registrar-agent to the registrar is kept as close as possible to BRSKI by relying on an enhanced voucher and utilizing EST with enhanced objects for enrollment. Based on that, use case 2 document would not reference use case 1 document. 

So a way forward could be to simply take the use case 2 from the current BRSKI-AE document into a new document and add a motivation/use case for reversing the call flow as well as the targeted solution approach. From the scenarios, currently available in the draft, some could be adopted also for use case 2. 
Regarding the existing use case 1, the text is stable for quite a while now, and the authors think it should be easier to advance the draft faster because of this.  

That said, I don’t see a real need to have three documents and would propose to stick to the 2. One could argue to take out the application examples (2 pages) as a separate document, but I don’t think this justifies the effort. 

Best regards
Steffen

---

From: Michael Richardson <[email-masked]>
Date: Tue, 03 Aug 2021 12:28:09 -0400

Fries, Steffen <[email-masked]> wrote:
    > Use Case 1 is relying on RFC 8995 for communication flow and for the
    > voucher handling, but targets to use alternative enrollment protocols
    > to achieve a proof-of-identity binding to the certification request
    > directly without relying on TLS to be able to "store and forward
    > "certification requests". For alternative enrollment, use case 1 could
    > use the Lightweight CMP profile
    > https://datatracker.ietf.org/doc/draft-ietf-lamps-lightweight-cmp-profile/
    > to achieve its goal. So this document would have no reference to use
    > case 2.

    > Use case 2, as currently described,  instead reverses the communication
    > flow to let the pledge be a server by introducing the registrar-agent
    > as new component. The communication between the registrar-agent and the
    > pledge is defined based on the exchange of JOSE objects, which provide
    > proof-of-identity on a message level to be independent of an underlying
    > TLS connection. This also allows to utilize BTLE for instance as
    > transport. The communication from the registrar-agent to the registrar
    > is kept as close as possible to BRSKI by relying on an enhanced voucher
    > and utilizing EST with enhanced objects for enrollment. Based on that,
    > use case 2 document would not reference use case 1 document.

I thought that the enrollment objects in use case 2 could be CMP objects.

---

From: "Fries, Steffen" <[email-masked]>
Date: Wed, 4 Aug 2021 07:50:17 +0000

Hi Michael

> From: Michael Richardson <[email-masked]>
> Sent: Dienstag, 3. August 2021 18:28
> 
Yes it could be. What is specified in use case 2 is currently based on JOSE and realizes a simple wrapper of  a PKCS#10 to be able to utilize the BRSKI enrollment endpoint on a registrar. Different pledges may support different enrollment formats. The assumption is that one pledge supports only one enrollment format. The pledge-enrollment-request  format can be signaled via the content type header in the pledge's response. If other formats for the pledge-enrollment-request are used like CMP, it would require additional logic at the registrar-agent to be able to select the corresponding endpoints at the registrar. We have not included this so far, but if the pledge would support CMP, we could reference use case 1 from use case 2 for the communication from the registrar-agent to the registrar.

Best regards
Steffen

---

From: Michael Richardson <[email-masked]>
Date: Thu, 05 Aug 2021 09:58:06 -0400

Dear Area Director and WG Chairs,

While I am in favour of splitting the document into two, the number of
documents that the IESG is willing to process is not infinite.
One advantage of the split is that products can more clearly articulate which
RFC they support.
(RFCXXXX vs RFCZZZZ, or RFCYYYY section A, or RFCYYYY section B)

Can you comment on this thread about splitting things up?

I also have not heard very clearly about whether or not RFC8366bis will
be adopted and worked on.   If reducing number of documents is important,
then one possibility is to merge draft-ietf-anima-jws-voucher into RFC8366bis.

Plus: fewer documents.
Negative: potentially opens up RFC8366bis to new semantics?

---

From: "Fries, Steffen" <[email-masked]>
Date: Wed, 25 Aug 2021 14:32:20 +0000

Hi Toerless,

Just using the previous thread to ask if there has been a decision regarding the document split of BRSKI-AE, we proposed during IETF 111.

Best regards
Steffen

> From: Anima <[email-masked]> On Behalf Of Michael Richardson
> Sent: Donnerstag, 5. August 2021 15:58
> To: Robert Wilton <[email-masked]>; [email-masked]
> Subject: Re: [Anima] BRSKI-AE document split discussion
> 
> 
> One advantage of the split is that products can more clearly articulate which RFC
> they support.