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:
> 
> 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 protected]>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
> 
> 
> _______________________________________________
> Anima mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/anima
> 

_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima

Reply via email to