You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is a bit wobbly still, but IMO something we should clarify better:
What are the pieces that go into dereferencing a CoAP URI, especially when OSCORE is involved (which unlike DTLS does not bring its own scheme)?
It's tempting to claim that OSCORE makes this special, but even dereferencing a coaps URI needs a piece of policy: "How is the stack supposed to know whom to trust and which credentials to present?" In a web-browser-style deployment, the implied policy is "whoever presents a valid certificate for that name from the root CA", but different uses of CoAP exist, eg. on LwM2M where AIU there is a coaps URI with an IP literal of the bootstrap server, and next to it a certificate (or RPK) that needs to present.
And then there is the choice of whether or not a proxy should be taken. This can be a simple no/yes-and-which choice (as is offered by browsers), but can also become more complex when URIs are not DNS based (eg. with 6tisch.arpa, "where is my Tor entry point so I can resolve .onion addresses?").
All those are decisions that a CoAP stack probably may in good conscience claim to just solve automatically, but others may offer those as choices (and some applications need the choices). Right now there is no place that explains that there are choices in the first place.
The documentation of RIOT-rs has a current PR with some text on that matter (that is biased towards RIOT-rs's choices, but might provide some starting point); discussion around that PR triggered the creation of this issue.
The text was updated successfully, but these errors were encountered:
This is a bit wobbly still, but IMO something we should clarify better:
What are the pieces that go into dereferencing a CoAP URI, especially when OSCORE is involved (which unlike DTLS does not bring its own scheme)?
It's tempting to claim that OSCORE makes this special, but even dereferencing a coaps URI needs a piece of policy: "How is the stack supposed to know whom to trust and which credentials to present?" In a web-browser-style deployment, the implied policy is "whoever presents a valid certificate for that name from the root CA", but different uses of CoAP exist, eg. on LwM2M where AIU there is a coaps URI with an IP literal of the bootstrap server, and next to it a certificate (or RPK) that needs to present.
And then there is the choice of whether or not a proxy should be taken. This can be a simple no/yes-and-which choice (as is offered by browsers), but can also become more complex when URIs are not DNS based (eg. with
6tisch.arpa
, "where is my Tor entry point so I can resolve .onion addresses?").All those are decisions that a CoAP stack probably may in good conscience claim to just solve automatically, but others may offer those as choices (and some applications need the choices). Right now there is no place that explains that there are choices in the first place.
The documentation of RIOT-rs has a current PR with some text on that matter (that is biased towards RIOT-rs's choices, but might provide some starting point); discussion around that PR triggered the creation of this issue.
The text was updated successfully, but these errors were encountered: