Adam,
Not sure if you saw my reply to Alissas comments, but my biggest concern
no only to fudge more and more bits and pieces into thre tailend of this
draft (+1 to birans comment), but also to continue fudge them as protocol
extensions into the BRSKI protocol when in reality the problems we should
solve are at the architectural level, whatever protocol we use. All the
things discussed here, and i think including Eliots idea would for example
equally apply to RFC8572, so we would IMHO do a better job overall if from
now on we would try to figue out a way to define extensions to the voucher
system (or secure node behavior) in a protocol independent fashion
(architecturally)
first, and then just have simple adoptions to the specific protocols
that want to have those extensions (BRSKI, NetConf, or whatever IoT
derivations i am sure will come up).
Not sure yet how to best do that, hopefully something we can discuss @105.
Wrt to Eliots suggestion: Its quite interesting and maybe the only one
for some slice of products, but If was thinking what really would mean
"owning" to me, then thats the ability to replace the root trust
anchor(s) in the device with my own. And there are cases where products
at least support ADDING such trust anchors in a way that factory reset
won't remove them (and only leave vendor TAs).
Cheers
Toerless
On Mon, Jul 15, 2019 at 10:52:02AM -0500, Adam Roach wrote:
>
>
> > On Jul 15, 2019, at 02:39, Eliot Lear <[email protected]> wrote:
> >
> > To Adam???s broader point, there are at least several ways to approach
> > this. We can leave it to the vendor to decide which is correct, and we can
> > continue to look to standardize ideas such as the one Michael had in the
> > message I???m replying to now.
>
> Yes; I think this is the important thing, and that specific mechanisms ??? if
> we believe they are useful to define ??? could be worked on later.
>
> /a
> _______________________________________________
> Anima mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/anima
--
---
[email protected]
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
