Multipart for voucher response?

[csosto-pk]

This was first described by Michael in https://bitbucket.org/6tisch/draft-richardson-6tisch-dtsecurity-secure-join/commits/a2c01d7800509418957f7ce05a298a753758146f

The draft says

The CMS structure SHOULD also contain all the certificates leading up to and 
including the signer's trust anchor certificate known to the recipient.

When the voucher response include the rw public key or cert for the recipient to verify. Does that need to be done with a multipart response as we do with server side key generation in EST-coaps by referencing https://tools.ietf.org/html/draft-ietf-core-multipart-ct-03? Should that be stated in the document?

[mcr]

Panos K. <notifications@github.com> wrote: This was first described by Michael in https://bitbucket.org/6tisch/draft-richardson-6tisch-dtsecurity-secure-join/commits/a2c01d7800509418957f7ce05a298a753758146f The draft says ``` The CMS structure SHOULD also contain all the certificates leading up to and including the signer's trust anchor certificate known to the recipient. ``` There was a thread about this, which reached no conclusion. Maybe you could include that in slides for IETF105 again? I am using a multipart/mixed (in HTTPS) from MASA to Registrar, so that the Registrar can receive the correct certificates in order to validate the voucher. The Pledge *ought* never need this, since it ought to have all the anchors, except if pledge has only a multi-step certificate chain that it needs to receive. That puts certain restrictions on the CA structure of the MASA. When the voucher response include the rw public key or cert for the recipient to verify. Does that need to be done with a multipart response as we do with server side key generation in EST-coaps by referencing https://tools.ietf.org/html/draft-ietf-core-multipart-ct-03? Should that be stated in the document? If we intend to return the certificate chain to the pledge, then we ought to do with in the unprotected bucket of the voucher.

…

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

[csosto-pk]

Gotcha @mcr . Yes, HTTP mixed is what I meant. Agreed. I think it should be mentioned in the draft.

About the pledge, gotcha. I think this should be spelled out a little better even your BRSKI or Voucher drafts, but that is not important right now.

[EskoDijk]

The above multipart discussion seems to be applicable only between Registrar and MASA, so it would fall outside the current scope of constrained-voucher! This seems more like an update to BRSKI - so we should move this issue to BRSKI-bis , in any case close it here. If I don't hear an objection I will close it in 2 weeks ;-)

[mcr]

The reason it is withing constrained-voucher is because the issue arises when sending a constrained-voucher from MASA->Registrar.

[EskoDijk]

Ah ok, then it seems relevant indeed.

1. If the additional certs are needed for the Pledge, it would need to be included in the constrained voucher COSE structure (x5bag?) as mentioned in above comments.
2. If there's also a scenario where the Pledge does not need any additional certs (so no x5bag) but the Registrar needs the additional certs to validate something, then it would make sense to use Multipart response to the Registrar. Then the Registrar "splits" the multipart response into the Voucher part (to send to the Pledge) and the Registrar part with info for the Registrar to use but not relevant for the Pledge.

In case 1) I think we do not need multipart or I can't see a use for it since the preference is to include any additional information in the Voucher structure.
In case 2) there can be, however this requires updating BRSKI with a part "information from MASA for the Registrar only" . Which may be useful but is currently not standardized. No need to consider this for constrained-voucher I think.