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. > 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 :-). > 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.) Grüße, Carsten _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
