On 2018-10-03 08:00, Michael Richardson wrote:
>
> lear> I think we've lost sight of what we're talking about. We're talking
> lear> about a completely automated method for a local trust anchor to be
> lear> installed on a device, and a kick to EST for the device to receive a
> lear> local credential. For that to happen there needs to be a trusted
> lear> introduction, and the device manufacturer or its agent is in the
> best
> lear> position to do that.
>
> Randy Bush <ra...@psg.com> wrote:
> > no. the owner's trust controller is.
>
> Cool. It's a relief to know that we've missed something obvious.
> Could you please explain things more?
>
> We call the owner's trust controller the "Registrar", or sometimes the
> Join-Registrar/Coordinator. I don't mind calling it a trust controller, but
> maybe your term has a different meaning.
There's a point that close followers of Anima may know and that others
don't. There is a topic intentionally missed out of the BRSKI document,
which is how the registrar decides whether a particular device, let's
say device X12345, is allowed to join the secure domain in question.
This point is skated over in the draft; in fact there is a text glitch
in section 5.2 where it should be stated, already known to the authors.
(Sorry, but we didn't find that text glitch soon enough to fix it before
the IETF Last Call.)
The actual authorization mechanism - "X12345 is allowed to join" - is
not part of BRSKI. It is, as Randy rightly implies, not the business
of the manufacturer.
The MASA is used only to verify that X12345 is in fact X12345. It's
part of the trust model, not the authorization model.
If I had my wishes, the MASA would be optional, with a local voucher
store in the registrar as the alternative. But that wasn't the WG
consensus.
Brian
_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
