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 <[email protected]> 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 <[email protected]>, Sandelman Software Works
> -= IPv6 IoT consulting =- *I*LIKE*TRAINS*
>
>
>
> --
> last-call mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/last-call
--
---
[email protected]
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
