Re: [Anima] [anima-wg/constrained-voucher] Unclear how MASA obtains Domain CA cert for pinning, in case of COSE-signed Voucher Request (#49)

[Michael Richardson <[e-mail]>]

In https://github.com/anima-wg/constrained-voucher/issues/49, Esko Dijk asks:

> In BRSKI (5.5.2  MASA pinning of registrar) it is clear how the MASA can
> get the complete cert chain of the Registrar from the CMS signature
> structure. The Registrar's Domain CA cert is included in there and is used
> as the pinned domain cert in the Voucher.  However, when we now use
> COSE-signed Voucher Request by the Registrar, the Registrar's Domain CA
> cert is not included in the COSE-sign structure so the MASA cannot
> "extract" it per BRSKI 5.5.2.

> It would be good to make more explicit how the MASA should extract the
> Registrar's Domain CA cert in this case (Note: the Domain CA could be the
> Registrar itself but not necessarily.)  The obvious candidate is to get it
> from the DTLS or TLS handshake that Registrar performs with MASA. This is
> already hinted at in the text in section 6.1.3 / 6.2.3 inside the YANG
> module description "... it is wasteful ... " but that is not quite
> clear. When Registrar is using COSE signing the MASA *has* to get the
> certificate from the handshake if the MASA wants to pin the entire
> certificate in the Voucher, there seems to be no other option. Section
> 6.3.2 now mentions "out of band" distribution but that's not very clever if
> you want automated bootstrapping - it needs to go all in-protocol /
> in-band.

> It should be noted also that this modifies the BRSKI requirement section
> 5.5.2 on how the pinned Domain CA cert is obtained.

In the more constrained cases, the Registrar is identified by a Raw Public
Key. [This works in DTLS and will work in LAKE by design]
This is what should be pinned by the MASA, because that's what the pledge saw.

If you are using a certificate chain for the Registrar end point, the MASA
does not have to pin the Domain CA, it can instead pin the Registrar
certificate, since again, that's what the pledge saw (and signed).

If you want us to define a way to pin the domain CA, then I think that right
answer is to pass that entire chain along to the Pledge in the BRSKI-EST
channel in the DTLS header, and have the pledge sign that entire object.
This wouldn't be very constrained, so I am not sure why one would do this
rather than using TLS in that case.

--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-