Inline: On Mon, Jul 24, 2023 at 7:29 PM Carsten Bormann <[email protected]> wrote:
> On 2023-07-24, at 23:52, Brendan Moran <[email protected]> > wrote: > > > > As mentioned in the meeting: > > > > If an object with a "typ" element gains a countersignature, > > semantically speaking, the aggregate type is now changed. Is the typ > > element now wrong? > > The countersignature never is in the protected header (it would have had > to be there on the original signature). Since that really only signed the > protected header and the payload, I don’t think anything has changed. > > > This is complex, because it means that a countersignature effectively > > makes the type incorrect. > > It does add a topping, but the base flavor doesn’t change. > I agree, but possibly we should call this out better since many newer envelope formats seem to support unprotected headers, I expect this might have some relevance to SD-JWT and JWP in the future. > > > To resolve this, you are required to either: verify countersignatures > > first or disregard everything in the unprotected headers when > > interpreting the typ header parameter. > > I think the latter (and the former :-). > > Agree, `typ` is a value committed to by the original issuer / entity that secured the protected header + payload... intermediate users / attackers who control the unprotected header should have no say over the "type" of the envelope they are extending, but they do have control over how they extend it, so we should anticipate the nesting cases, for example typ: outer+cose ... unprotected ... ... ... counter signature: ... ... ... ... typ: inner1+cose ... ... scitt receipt: ... ... ... ... typ: inner2+cose ... ... ... ... unprotected ... ... ... ... ... ... scitt receipt: .. ... ... ... ... ... ... typ: inner3+cose (some envelopes will have recursive structures where the unprotected header contains values that are protected with a `typ`, that could be the same or different) > Both of these introduce the same semantic paradox: If the > > counter-signature(s) are excluded from the type, then the typ element > > doesn't actually tell me what the aggregate type is. In a naive > > interpretation, I don't know how to interpret the countersignatures > > because the typ doesn't include them. > > You need a COSE_Countersignature (and not a COSE_Countersignature0) to be > able to put a *new* typ into the protected header of the countersignature. > > (I deleted the rest of the message because I think do didn’t realize > countersignatures can have protected headers.) > Hmm, perhaps what I said above is wrong for counter signatures then? It still seems relevant to SCITT receipts. > Grüße, Carsten > > -- ORIE STEELE Chief Technology Officer www.transmute.industries <https://transmute.industries>
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
