Digging up an old thread...
On Mon, Feb 21, 2022 at 03:18:01PM +0000, Göran Selander wrote:
>
>
> On 2022-02-18, 06:00, "COSE on behalf of Benjamin Kaduk"
> <[email protected] on behalf of [email protected]> wrote:
>
> Hi all,
>
> The chairs and I are continuing to work through the AUTH48 process for the
> 8152bis drafts, and a couple topics have come up that would benefit from
> some broader input.
>
> In
>
> https://datatracker.ietf.org/doc/html/draft-ietf-cose-rfc8152bis-struct-15#section-7.1
> we we have a table of "Key Operation Values", discussing the various
> operations that are possible. Some of them include the statement
> "Requires
> private key fields", and for operations like "sign" or "unwraap key" this
> is pretty obviously true. But for "derive key" and "derive bits" this is
> less clear to me. In particular, my understanding is that I can do the
> derivation operations by combining a public key I control and a public key
> received from the peer. That, in turn, seems to imply that the serialized
> public key that I receive from the peer would be intended to be used for a
> derivation operation but would not contain the private key fields. Are we
> supposed to indicate the derivation operations in the "key_ops" field of
> such a public-key-only COSE_Key? I believe we are supposed to, and so
> have
> directed the RFC Editor to just remove the statement about "requires
> private key fields" for those two entries. This seems low-risk in that
> the
> statement itself is mostly informative, so we're either removing a false
> statement or removing something that's informative but obvious when you go
> to implement it. Do people agree with that interpretation of the
> "key_ops"
> for public-key-only key objects destined for derivation operations?
>
> [GS] I think it is fine to remove the text about private key fields here. But
> the use of "key_ops" as inherited from JOSE is not fully clear to me. To the
> extent it is useful to include a signature private key in a COSE_Key and
> restrict the operation to "sign", it is perhaps also useful to include a
> Diffie-Hellman private key in a COSE_Key, but what should the "key_ops" be?
> Computing the DH shared secret requires two keys, and as it should not be
> used directly as key, perhaps "derive bits" is the right operation? Or is
> there a missing operation "key agreement"?
It turns out that there is some more guidance in
draft-ietf-cose-rfc8152bis-algs that seems to clarify the situation fully
for me. In particular, in sections 6.3.1 and 6.4.1 thereof, there's a
stanza "When using a COSE key for this algorithm, the following checks are
made" that includes:
* If the "key_ops" field is present, it MUST include "derive key" or "derive
bits" for the private key.
* If the "key_ops" field is present, it MUST be empty for the public key.
So that's clear about "derive key"/"derive bits" for the private key, and
that we don't use either of those for the public key. That's not the setup
I would have written if starting from scratch, but it's what we've got, and
it's also what was in RFC 8152 itself. So (bearing in mind that -struct is
going for full Internet Standard), I think we want to leave the "requires
private key fields" text in place for derive key/derive bits.
Thanks all for the discussion, and sorry that I ended up convincing myself
that there's not anything to change on this front.
-Ben
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
