On Fri, Jul 23, 2021 at 03:15:09AM +0200, Carsten Bormann wrote:
> > Overthinking is a result of underspecification in the COSE RFC/bis-draft.
>
> This is not underspecification; this is leaving decisions to the protocol
> using COSE.
Underexplained how/why to make specific decisions based on underspecified
semantics
of the header fields and missing examples ?
> I am trying to get you to make those decisions.
Sure, thats what we're doing here.
> > Constrained vouchers (application-type/voucher-cose+cbor, TBD3) SHOULD NOT
> > use the
> > COSE header "content type” field
>
> They CANNOT unless you allocate a media type for an unprotected voucher.
There is application/cbor, ID=60
I am not saying i find that useful, i was just suggesting the SHOULD NOT
instead of your MUST NOT because i couldn't figure out how to, nor
cared why to suggest a pithy explanation why something like application/cbor
in content type is useless.
> Are you also saying that they should/should not use “countersignature”?
> Maybe a single sentence that explains that there are no header parameters in
> use expect those that you specify would be enough.
I have not looked at any other COSE header parameters that might
be underspecified in the constrained voucher spec. I just stumbled
into the ones i discussed because of the early allocation request.
If you have opinions/suggestions, please offer them here
(e.g.: about countersignature).
Shortening the text to apply for multiple parameters is fine editorializing,
but should not come at the expense of dropping explanations of
decisions made by the document whose absence could leave implementers/readers
wondering.
> > because the encoding is never "ambiguous"
> > according to RFC8152 Section 3.1.
>
> Well, that is actually not true, as far as I know. How do you *know* that
> the signed payload is a voucher?
The way i see it, The COSE object is useless standalone, because
it does not even describe in its own structure what it is.
So you need to have somewhere else the media-type
application/voucher-cose+cbor and/or binary TBD3 to
know what it is.
But as soon as you know what it is, you have nailed down
the fact that the semantic is voucher and the COSE content
type is a CBOR encoded voucher.
> (Remember that the attacker can repackage anything that is not protected ad
> nauseam, so a tag/media type *outside* the signature is not such an
> indication.) Abadi-Needham #1.
I do not follow. Rephrase with step by step workflow example ?
But if i may guess: the constrained voucher draft does not need
to care if/how a non-COSE encapsulated CBOR encoded "voucher"
blob would be identified. That type of object is not used or needed
anywhere in the spec, and i would argue that the CBOR part
by itself isn't even a real voucher because the signature
in the COSE part is a core core part of a voucher.
Cheers
Toerless
> Grüße, Carsten
--
---
t...@cs.fau.de
_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
