On Wed, Jul 18, 2018 at 08:22:47PM -0400, Michael Richardson wrote:
> >> Please explain how this works.
> >> A Registrar that accepts a device that has an audit-only MASA is not
> >> rogue. It's doing exactly the right thing.
>
> > You don't legally own such a pledge just because you claim it on a MASA,
> > but doing so could easily be interpreted to be at least theft of
> service.
>
> That's an interesting legal concern.
> (To address Brian's concern about scope: I want the document to go the
> IESG too, but if this is a potential sticking point with the IESG,
> then it's better to address it sooner)
I don't think Brian raised an issue aobut this point. The only new issue
raised was the broken reference to the section about authorizing the pledge by
the domain. See the new github issue i opened.
The audit-only log is IMHO a great new option to explore and see where
it would fall out on the legal side if there is abuse (claims made by
non-legal owners).
> >> > the MASA should do more than just logging for every device, for
> >> > example if the MASA supports both lightbulbs and core routers, it's
> >> > clear that the MASA policies could be different.
> >>
> >> And given the ability to embed different URLs in the IDevID
> certificate,
> >> I'd want to run two completely different MASA :-)
>
> > And Trust Anchors. Epecially when you want to ve free to sell off
> > individual product lines in a large company.
>
> In the non-constrained (CMS/PKCS7) case, one can make the MASA trust anchor
> embedded in the pledge as abstract (i.e. with as deep a CA hierarchy) as you
> like. It's only in the COSE case (which isn't in *this* document), that there
> are issues with having a signing hierarchy deeper than one level.
I think we're in violent agreement.
> So I wrote before that we need an operational document for the domain
> registrar and ACP. Clearly we need operational advice for the manufacturer
> as well. Maybe someone should author a book... "ANIMA for dummies"
Well, this is an OPS WG, so its perfectly fine to elaborate on informational
operational aspects in our document. Even BCP. And if you find a formal
language to express operational processes i bet we could even go standard ;-)
Cheers
Toerless
> --
> ] Never tell me the odds! | ipv6 mesh networks
> [
> ] Michael Richardson, Sandelman Software Works | network architect
> [
> ] m...@sandelman.ca http://www.sandelman.ca/ | ruby on rails
> [
>
> _______________________________________________
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima
--
---
t...@cs.fau.de
_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
