> -----Original Message-----
> From: Anima <[email protected]> On Behalf Of Michael Richardson
> Sent: Montag, 5. Juli 2021 01:30
> To: Esko Dijk <[email protected]>; [email protected]
> Subject: Re: [Anima] BRSKI design team meeting on Thursday
>
>
> Esko Dijk <[email protected]> wrote:
> > Let's meet tomorrow and see who is there and what we can discuss. In
> particular, the following would be useful agenda points
>
> > * July constrained-voucher interop: define the details to use for the
> > Registrar <-> MASA interface. For example, is the following supported
> > if we try Registrar/MASA interop of different implementations:
>
> Thanks for nailing this down. I thought that
>
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1T8Rtfk1zia_p05_6eb
> _WQA2Mmid-eP1-cAgnwdpF9Xk%2Fedit%3Fusp%3Dsharing&data=04%7C01%7Cthomas-
> werner%40siemens.com%7Cf8edf21940f545cc69c908d93f43b66c%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C6376103827
> 83828128%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&a
> mp;sdata=QfiW96r3BzSDsQzAlTAtKY4tiM73BaGIjW%2FvMHcMDJ8%3D&reserved=0
>
> and the documents already said:
>
> > - Registrar's Voucher Request: application/voucher-cms+json over HTTPS
> , per [RFC 8995]
>
> > - MASA's Voucher Response: application/voucher-cose+cbor over HTTPS
> > (Registrar client included an Accept header indicating this
> > Content-Type)
>
> I guess I'm wondering why this is still uncertain?
>
> > - MASA does not verify client authorization (i.e. any Registrar client
> > is allowed to connect with TLS)
>
> I think that Siemens-BT requires that it knows about the Registrar.
> Thomas, can you confirm? Can we collect Registrar client certificates as go
> into the Hackathon?
Our Siemens interop MASA is not enforcing TLS client authentication of a
registrar.
But checks the "registrar-voucher-request" signature, think this was meant by
"knows about the Registrar ".
So a trust anchor of the "registrar-voucher-request" signing cert is required,
should be collected in advance to the Hackathon (or I could get it from the
MASA logs, which is more effort during testing)
>
> I'll also say that my Registrars support hostname:9443/version.json and
> hostname:9443/status.json. I accept this from any origin, not
> validating the TLS Client Certificate.
>
> I wonder if an additional target like, "/diag.json", or "/diag.cbor" (or
> using Accept: headers), which does validate the TLS Client
> Certificate, and then spits back some info about what it thought about the
> client.
> Would that be useful to people writing Registrars?
>
> > - Registrar does not verify MASA server is authorized (i.e. any MASA
> > server is allowed to connect with TLS)
>
> This could mean a few things:
> 1) Registrar doesn't verify MASA TLS Server Certificate at all.
> 2) Registrar will only connect to MASA with configured TLS anchors,
> including possibly WebPKI list of anchors.
> 3) Registrar will only onboard devices with Manufacturer's listed as
> trusted.
> (In the context of above statement, it means that Registrar will
> operate with any manufacturer, that is, not{3})
>
> > * New issue #122: Use of CoAP 4.03 Forbidden vs 4.01 Unauthorized
> > -
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fanima-wg%2Fconstrained-
> voucher%2Fissues%2F122&data=04%7C01%7Cthomas-
> werner%40siemens.com%7Cf8edf21940f545cc69c908d93f43b66c%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C6376103827
> 83838119%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&a
> mp;sdata=bo8rZ7uyDjd0Sg9IO3GWjOmQL6G2ykuPGthUJ4XVUyw%3D&reserved=0
>
>
>
> --
> Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting )
> Sandelman Software Works Inc, Ottawa and Worldwide
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
