Hi Michael, Maybe I should've looked into the document first - sorry. The online doc actually says that the Registrar will send out the voucher request format to MASA which is equal to the voucher request format it received. So, typically [for constrained-voucher implementations] this is COSE-signed-CBOR. My proposal was to send CMS-signed-JSON always by the Registrar. That was because I didn't saw a reason to deviate from RFC 8995 on the unconstrained network path between Registrar and MASA. But MASA supporting both methods could also be an option for the interop.
> I wonder if an additional target like, "/diag.json", or "/diag.cbor" That sounds useful for debugging. With the following > - Registrar does not verify MASA server is authorized (i.e. any MASA > server is allowed to connect with TLS) I meant that the Registrar client will not abort the TLS handshake to MASA server for pure authentication/authorization reasons. Such reasons for typically aborting the TLS handshake may be 1* MASA's server certificate is not set to explicitly 'trusted' in a trust store of the Registrar 2* MASA's server certificate does not have a dnsName field in it 3* MASA's server certificate does have a dnsName in it but it does not match the DNS hostname used to contact the MASA server For other reasons (e.g. format errors, incorrect signature, etc.) it can of course abort the handshake. In my HTTPS client I saw that by default reasons 1/2/3 are enough to abort the connection; so the HTTPS client's verification level has to be lowered, and it seems good if implementations are doing so / are aware of this prior to the interop. Best regards Esko -----Original Message----- From: Michael Richardson <[email protected]> Sent: Monday, July 5, 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://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 _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
