On 2021-07-22, at 22:55, Michael Richardson <mcr+i...@sandelman.ca> wrote: > > Signed PGP part > > Toerless Eckert <t...@cs.fau.de> wrote: >> So: if we wanted to support the COSE content-type field semantically >> correctly, we should ask for another registry entry: > >> application/voucher-cbor TBD4 > > I don't understand what that would be for.
If the intent is to use header parameter 3 (content type) to identify the payload of the COSE-Sign1, as has been discussed here, this only works if there is a media-type (and preferably also a content-format) for that payload. There may be other ways to provide that identification, but *if* the parameter 3 is chosen, a second media type for an unprotected voucher will be required. (Obviously with +cbor etc.; naming to be decided later.) > We already are registering application/voucher-cose+cbor in section 13.5.1 > We fit voucher-request into the same content. > (that's distinguished by the SID values) So that is also a COSE-Sign1 payload? (Too lazy to check, sorry.) > I think you are overthinking this. > And we transport constrained-vouchers with that MIME type over HTTPS between > Registrar and MASA. And we use it in the Accept: header. But these are all protected vouchers, so they don’t need the additional media type, right? (When I say “additional media type”, this of course also could be a content-type parameter, “; protected=no” or some such. Still need a second content-format number.) Grüße, Carsten
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
