On Thu, 2024-01-04 at 15:40 +0100, Carsten Bormann wrote:
> A lot of people seem to like this document, so I apologize for having to rain
> on this parade.
>
> I'm not at all convinced this document is ready for WG adoption.
I agree with Carsten on all points here.
The only measure proposed in the current draft is highly questionable,
as it completely redefines an attribute with semantics that are
absolutely not what the standard reserves it for.
The rest are intentions, and adoption should be based on proposed text,
not intentions.
Surely the drafter can at least come up with some substantive text and
a modicum of agreement on the goals before asking for adoption?
(I maintain a Jose implementation in case that matters).
> (1) I don't understand the scope of this effort. The document is titled
> "Guidance for COSE and JOSE Protocol Designers and Implementers", but it
> actually only discusses one single subject. Is the document meant to stick
> with its current actual scope, or is the intention to cover what it promised
> by the title and abstract? It doesn’t even mention RFC 8725!
>
> (2) For COSE, the one subject discussed leads to a new MUST on a header
> parameter that defined in STD96 (kid, defined in RFC 9052, Section 3.1). I
> don't think a BCP can redefine a parameter defined in a standards-track
> document. RFC 9052 is quite explicit that »Applications MUST NOT assume that
> "kid" values are unique«:
>
> kid: This header parameter identifies one piece of data that can be
> used as input to find the needed cryptographic key. The value of
> this header parameter can be matched against the "kid" member in a
> COSE_Key structure. Other methods of key distribution can define
> an equivalent field to be matched. Applications MUST NOT assume
> that "kid" values are unique. There may be more than one key with
> the same "kid" value, so all of the keys associated with this
> "kid" may need to be checked. The internal structure of "kid"
> values is not defined and cannot be relied on by applications.
> Key identifier values are hints about which key to use. This is
> not a security-critical field. For this reason, it can be placed
> in the unprotected-header-parameters bucket.
>
> (3) The rationale given in the draft for replacing the definition of this
> parameter with what essentially is a new definition is rather wobbly. It
> seems that the intention is not really to add security, but just to reduce
> the attack surface for attacks that continue to be possible if the "guidance"
> of the document is heeded.
>
> (4) The term "globally unique" is not defined. I don't think it actually
> means anything in the specification as it is being used.
>
> If the intention is to define a globally unique Key ID, please define a
> header parameter that has the desired properties (e.g, "gukid", globally
> unique kid). For this, please define "globally unique".
>
> Or what we maybe should do here is define specific forms of the "kid" value
> that do have some desirable uniqueness properties. Proponents of the
> approach of this document can then recommend the use of one of these forms.
>
> But what this document really tries to do has little to do with "kid", but
> can be summarized by a list of recommendations an expression of which I'll
> steal from an off-list discussion:
>
> 1. try not to deserialize untrusted data needlessly (reducing attack surface,
> not actually increasing security) — this is not just about kid.
>
> kid-related:
> 2. try not to use identifiers for keys that suck (yes, need an operational
> definition of what that means)
> 3. you are still responsible for establishing the actual authorization
> properties of the key ("trusting" it) before using it to verify / decrypt...
> -- but did you read all the warnings about how headers can be misleading,
> and maybe you are holding the wrong key?
>
> Grüße, Carsten
>
> _______________________________________________
> jose mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/jose
--
Simo Sorce,
DE @ RHEL Crypto Team,
Red Hat, Inc
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
