> Well, Postel’s principle doesn’t apply to wanton extension of the protocol (~
> somebody might decide to do something different from the standard, so I’ll
> implement my idea of what that could be).
> If it says you need to have X, allowing Y just to get clients to rely on that
> and make life harder for other server implementations is also known as a
> common standards-busting strategy…
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. 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. 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.
> 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).
Esko
-----Original Message-----
From: Carsten Bormann <[email protected]>
Sent: Thursday, July 22, 2021 10:39
To: Esko Dijk <[email protected]>
Cc: [email protected]; Toerless Eckert
<[email protected]>; [email protected]
Subject: Re: [Anima] draft-ietf-anima-constrained-voucher COSE confusion
On 2021-07-22, at 10:23, Esko Dijk <[email protected]> wrote:
>
> be liberal in what it accepts
Well, Postel’s principle doesn’t apply to wanton extension of the protocol (~
somebody might decide to do something different from the standard, so I’ll
implement my idea of what that could be). If it says you need to have X,
allowing Y just to get clients to rely on that and make life harder for other
server implementations is also known as a common standards-busting strategy…
(Not accusing you of this, just trying to explain my strong reaction.)
[1]: https://datatracker.ietf.org/doc/draft-iab-protocol-maintenance/
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]).
Grüße, Carsten
[2] M. Abadi and R. Needham. Prudent Engineering Practice for Cryptographic
Protocols. In 1994 IEEE Computer Society Symposium on Research in Security and
Privacy, pages 122–136. IEEE Computer Society, May 1994. DOI
10.1109/RISP.1994.296587.
Principle 1
Every message should say what it means:
the interpretation of the message should depend only on its content.
It should be possible to write down a straightforward English
sentence describing the content-though if there is a suitable
formalism available that is good too.
[Note that “describing” here is semantic, a CDDL description is good too, but
just structural.]
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
