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://docs.google.com/document/d/1T8Rtfk1zia_p05_6eb_WQA2Mmid-eP1-cAgnwdpF9Xk/edit?usp=sharing
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?
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://github.com/anima-wg/constrained-voucher/issues/122
--
Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
