Maybe i am hallucinating this (then i will declare myself to be an AI, because they
seem to be allowed to hallucinate ;-), but this does look somewhat similar to the problems
we're facing in determining the right method to make application information available to network
elements as metadata (routers).
A step-by-step explanation of (one of) the most ibusiness mportant use-case in JWT for this would
be very helpful. Even if we might not like it, it could still open the door to say
"ah, this is crap, but we may not want to loose that market relevance when developers
want to move from JWT to CWT".
I was imagining that "software processing" could be infrastructures like caches that
would process files made up of these objects. Similarily to whats done in ACME for
e.g.: certificate and trust-anchor distribution. But that may be hallucination.
But such use-cases would IMHO only make sense if the metadata is also authenticated -
is that the case (not encrypted but authenticated) ?
In addition: If the libraries implied by this draft are really meant to pass on some
parts of the user/application provided data unencrypted without the user/app explicitly
directing the library to do so, then thats of course a complete NoGo. And if the
user/application explicitly asks to do this (this data here pls. only authenticate,
not encrypt), then its still the question why to duplicate and why it has to be
part of a header as opposed to (another block of) payload.
Cheers
Toerless
On Tue, Oct 31, 2023 at 03:58:39PM +0000, Michael Richardson wrote:
>
> <#secure method=pgpmime mode=sign>
>
> I have no opinion about this document, but enjoyed reading Hannes' review.
>
> Hannes Tschofenig via Datatracker <noreply@xxxxxxxx> wrote:
> > Even on a smaller scale (with the key id) this already creates problems
> > for developers of COSE / JOSE libraries because the layers get combined
> > and important security decisions are outsourced to the developer. We
> > know that developers, who use these libraries, are unable to make good
> > security decisions.
>
> Are they unable, unwilling, or ignorant?
> Should our specifications pessimistically coddle poor choices, or
> optimistically aspire towards well designed software architectures?
>
> I have to wonder if there are patterns (and anti-patterns) in library APIs
> that support better decisions, or encourage worse decisions. Are there
> language features that are better/worse here?
>
> I also wonder about the role of certifications (FIPS-140 specifically) that
> seem to force developers into (ab)using less well designed libraries, or
> prevent them from fixing libraries to suit their application needs.
>
>
>
> --
> Michael Richardson <mcr+IETF@xxxxxxxxxxxx>, Sandelman Software Works
> -= IPv6 IoT consulting =- *I*LIKE*TRAINS*
>
>
>
> --
> last-call mailing list
> last-call@xxxxxxxx
> https://www.ietf.org/mailman/listinfo/last-call
--
---
tte@xxxxxxxxx
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
