Hi Christian, I'm excited by your document.
First some editorial suggestions.  IN section 1.1, without having given a
picture of what you are doing you start to say:
        "The alternative to this constraint is to declare this a blob"
and this is really distracting to understanding what you *ARE* doing.

"the pledge initiates EDHOC to the lake-authz.arpa anycast address, sending
 an encrypted identifier for its MASA (party W) in EAD_1."

This sounds like it's a new thing, but I think it's just the lake-authz step
one, right?

You did a bunch of YANG:
  uses "vch:voucher-artifact-grouping" {
     augment "voucher" {

And I really wish that it worked that way.
But, it just doesn't.

https://play.conf.meetecho.com/Playout/?session=IETF116-NETMOD-20230331-0030
Start at 1:53:00.

My repo of examples is at: https://github.com/mcr/yang-augment-test
I can chase down the ML posts about this if it helpful.

--- on to your problem.

My impression is that you don't really want the *MANUFACTURER* (authorized)
to send down some ACE keying material.  That is, Volvo shouldn't be sending
your car a key to open your building garage door, rather, your building owner
should be.

So, augmenting the voucher, which comes from the Manufacuter (MASA, aka W) to
your pledge is wrong.  You want the ACE Authorization Server, aka V, to
actually send the right keys.

I think that either you want to use the new V/W relationship that EDHOC,
lake-authz setup to send the keys in message 4, or you want to do a new FETCH
on some some new resource to get them.

--
Michael Richardson <mcr+i...@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide




Attachment: signature.asc
Description: PGP signature

_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Reply via email to