Toerless Eckert <[email protected]> wrote:
    >> Toerless Eckert <[email protected]> wrote:
    >> > As you point out, we can never be sure that rogue  domains are not
    >> > simply accepting devices they do not own. But we can build secure
    >> 
    >> 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 think the problem is that some people think they are going to
    >> sell $100K BFRs with audit-only policies?

    > Bad Feeble Router ? ;-)

Big Fu^WFriendly Router.

    >> > 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.

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"

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email protected]  http://www.sandelman.ca/        |   ruby on rails    [ 
        

Attachment: signature.asc
Description: PGP signature

_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima

Reply via email to