> Yes I read the IETF specs and then implement my idea of what these are trying
> to say. It helps if more people are looking at it, as we do in this case :)
> to avoid interpretation errors.
> From what I read, a COSE_Sign1 object can be adequately described by cf=18 so
> that's what I implemented.
A sign1 object is pretty much self-checking when you check the signature.
More interesting is — what was actually signed?
> There seems to be nothing wrong with that, except that
> draft-constrained-voucher says to use TBD3 for the case that this object is a
> Voucher/VR.
Exactly, so if it says that, and someone sends me ct=18, I shouldn’t use that,
because something went (accidentally or surreptitiously) wrong.
> So to be compliant to the draft I can remove support for cf=18 as soon as
> TBD3 is allocated. I still don't see how cf=18 could be 'wanton extension of
> the protocol' as it is just using CoAP/COSE defined mechanisms that
> apparently are overruled by draft-constrained-voucher.
Overruled they are.
(Unless/until we decide to change to them!)
>> The reason I was bringing up the benefits of identifying the payload as a
>> voucher is that it would serve to fulfill number one of the Abadi-Needham
>> principles: context-free messages ("Explicit communication" [2]).
> In this perspective and considering security it would be good if the COSE
> structure would have the 'content type' parameter inside set to 60 (CBOR).
> This way the server would never fall into the trap to parse a valid VR with
> non-CBOR payload as a CBOR payload (which in a rare case might trigger some
> bug/overflow and compromise security).
The payload would need to be validly signed before a sane implementation tries
to consume it, so I think that is a smaller concern. (Can the attacker validly
sign? Possibly…)
I still think it is important to solidly identify the signed part of the
message as a voucher, unless the keys are earmarked ONLY for this kind of
signature, in which case the voucherness would be implicit.
Grüße, Carsten
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
