Off-list:
It sounds from you rnote like either:
1) Anima admission process is seriously underspecified in a way that
affects itneroperability, or
2) BRSKI is actually irrelevant to ANIMA, and should be reviewed and
advanced (if desired) by some other working group.
I doubt either is your intention.
And statements such as Eliot's ill-formed comment that no one would do
that do not help the case for the Anima WG having thought this through.
Yours,
Joel
On 10/2/18 3:46 PM, Brian E Carpenter wrote:
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 <[email protected]> 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
[email protected]
https://www.ietf.org/mailman/listinfo/anima
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
