Subject: [Anima] last minute changes to BRSKI to do endpoint discovery

From: Michael Richardson <[email-masked]>
Date: Tue, 21 Jul 2020 19:51:21 -0400

The BRSKI-AE authors have suggested that in order to make BRSKI more
easily extendable that prior to using the /.well-known/est end points (both RFC7030
ones and bootstrapping-keyinfra ones), that the pledge should ask for
/.well-known/brski, to get back a list.

The thread ending at https://mailarchive.ietf.org/arch/msg/anima/MQkNXJJjMkP0nqKlNEaxDZ94RgI
alludes to this, but the current -03 document does not include this proposal,
because it would need to go into BRSKI itself.

   REQ: GET /.well-known/brski

   RES: Content-Type: application/link-format   {see RFC6690}
     </brski/voucherrequest>,ct=voucher-cms+json
     </brski/voucher_status>,ct=json
     </brski/requestauditlog>,ct=json
     </brski/enrollstatus>,ct=json

     </est/cacerts>;ct=pkcs7-mime
     </est/cacerts>;ct=pkcs7-mime
     </est/simpleenroll>;ct=pkcs7-mime
     </est/simplereenroll>;ct=pkcs7-mime
     </est/fullcmc>;ct=pkcs7-mime
     </est/serverkeygen>;ct= pkcs7-mime
     </est/csrattrs>;ct=pkcs7-mime

      </cmp/initialization>;ct=pkixcmp
     </cmp/certification>;ct=pkixcmp
     </cmp/keyupdate>;ct=pkixcmp
     </cmp/p10>;ct=pkixcmp
     </cmp/getCAcert>;ct=pkixcmp
     </cmp/getCSRparam>;ct=pkixcmp

This is already done in draft-ietf-ace-coap-est-18, BTW.
But, it asks /.well-known/core?rt=ace.est rather than /.well-known/brski.

At this point, we are waiting for ACP document to be approved by the IESG.
Assuming that our AD was amenable, I think that this could be snuck in before
ACP is approved.   This email does not include my opinion, as it has not yet
been formed.

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

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 22 Jul 2020 13:43:00 +1200

No technical objection from me.

It isn't just the AD who decides though, is it? It's a substantive change.
That means, according to my Policy Wonk's Handbook, a brief WGLC, a brief
IETF LC, and another run at the IESG agenda.

If that's the case, I'd suggest another approach (either a future short RFC
that updates the BRSKI RFC, or make BRSKI-AE formally update the BRSKI RFC).

Regards
   Brian

On 22-Jul-20 11:51, Michael Richardson wrote:
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima
>

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Wed, 22 Jul 2020 07:59:22 +0000

> Von: Michael Richardson <[email-masked]>
> 
> 
> The BRSKI-AE authors have suggested that in order to make BRSKI more easily
> extendable that prior to using the /.well-known/est end points (both RFC7030
> ones and bootstrapping-keyinfra ones), that the pledge should ask for /.well-
> known/brski, to get back a list.
> 
> The thread ending at
> https://mailarchive.ietf.org/arch/msg/anima/MQkNXJJjMkP0nqKlNEaxDZ94RgI

I would appreciate to use /.well-known/brski for the endpoints specified in BRSKI and use /.well-known/est for those specified in RFC7030.
This offers more flexibility for future extensions like BSKI-AE.

- Hendrik

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

---

From: Michael Richardson <[email-masked]>
Date: Thu, 23 Jul 2020 23:46:27 -0400

> I would appreciate to use /.well-known/brski for the endpoints
    > specified in BRSKI and use /.well-known/est for those specified in
    > RFC7030.

Such a change would be large to BRSKI.

Brian suggests making this an update.
But, I think it would cause market confusion if we published an RFC with
/.well-known/est/requestvoucher, and then said, "no sorry, no we meant
/.well-known/brski/requestvoucher"

Would there be pledge implementations that would try one and then the other?
I will say that I'm *NOT* keen on including the Resource Link GET, but I can
tolerate it.

I think that we'd need to:
  1) blessing of our AD.
  2) pull document out of RFC-editor queue.
  3) revise it, do a WGLC on revision.
  4) get AD to put it back in queue.

The ROLL WG did this for a document last year when we realized that a new
document obsoleted some of the recommendations.  It took longer than planned,
but that was partly because the other document had to settle a bit.
I think we could do this in the time for the 2nd WGLC and about four days.

---

From: Michael Richardson <[email-masked]>
Date: Sun, 26 Jul 2020 17:33:55 -0400

Would BRSKI-AE want to do CoAPS instead of HTTPS?
Or in addition to HTTPS?

I propose to leave base HTTPS BRSKI as-is, and then do whatever renames you
like by merging BRSKI-AE into constrained-voucher, and all all of the
asynchronous efforts over CoAP.

This has the interesting possibilities of supporting BRSKI-AE CoAP over BTLE,
NFC, and SMS. (not necessarily with an IP layer)

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 27 Jul 2020 10:19:41 +1200

Yes. It's important to make extensions but only after freezing the base
RFCs. 

Regards
   Brian Carpenter

---

From: "Fries, Steffen" <[email-masked]>
Date: Mon, 27 Jul 2020 05:41:33 +0000

Hi Michael,

> From: Michael Richardson <[email-masked]>
The intention was not to include the discovery mechanism right away into BRSKI. It was rather the question to rename the BRSKI defined endpoints to /.well-known/brski to underline, that the voucher exchange is independent from the chosen enrollment protocol. The discovery should be done in BRSKI-AE, which should update the base specification then. I understand, that we should not state /.well-known/est and the immediately update it afterwards to /.well-known/brski . That would look awkward. If we just rename the endpoints in BRSKI, would that cause such a large change? 

Best regards
Steffen

> document obsoleted some of the recommendations.  It took longer than
> planned, but that was partly because the other document had to settle a bit.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 28 Jul 2020 08:26:45 +1200

>> /.well-known/brski/requestvoucher"

I meant that the update would say
"please *add* /.well-known/brski/requestvoucher"

An extension, not an amendment (draft-kuehlewind-update-tag).

   Brian