Hi Ben, As it was discussed in the COSE meeting, just to confirm that I agree with your conclusion in this thread.
Some nits in draft-ietf-cose-rfc8152bis-algs-12 I found when I looked this up, mainly section references (maybe this is already taken care of, I couldn’t see any activity in the cose-wg github). [Paul: this list includes the nits I forwarded to you] OLD “2. Signature Algorithms Section 9.1 of [I-D.ietf-cose-rfc8152bis-struct] contains” NEW “2. Signature Algorithms Section 8.1 of [I-D.ietf-cose-rfc8152bis-struct] contains” OLD ”3. Message Authentication Code (MAC) Algorithms Section 9.2 of [I-D.ietf-cose-rfc8152bis-struct] contains” NEW ”3. Message Authentication Code (MAC) Algorithms Section 8.2 of [I-D.ietf-cose-rfc8152bis-struct] contains” OLD “4. Content Encryption Algorithms Section 9.3 of [I-D.ietf-cose-rfc8152bis-struct] contains” NEW “4. Content Encryption Algorithms Section 8.3 of [I-D.ietf-cose-rfc8152bis-struct] contains” OLD ”5. Key Derivation Functions (KDFs) Section 9.4 of [I-D.ietf-cose-rfc8152bis-struct] contains” NEW ”5. Key Derivation Functions (KDFs) Section 8.4 of [I-D.ietf-cose-rfc8152bis-struct] contains” OLD ”6. Content Key Distribution Methods Section 9.5 of [I-D.ietf-cose-rfc8152bis-struct]” NEW ”6. Content Key Distribution Methods Section 8.5 of [I-D.ietf-cose-rfc8152bis-struct]” OLD "6.1. Direct Encryption Direct encryption algorithm is defined in Section 9.5.1" NEW "6.1. Direct Encryption Direct encryption algorithm is defined in Section 8.5.1" 6.1.2 ”If the 'key_ops' field is present, it MUST include 'deriveKey' or 'deriveBits'.” whereas in 6.3.1 and 6.4.1 there is a different literal: ”If the 'key_ops' field is present, it MUST include 'derive key' or 'derive bits' for the private key.” OLD “6.2. Key Wrap Key wrap is defined in Section 9.5.1“ NEW “6.2. Key Wrap Key wrap is defined in Section 8.5.2“ OLD "6.3. Direct Key Agreement Key Transport is defined in Section 9.5.4" NEW "6.3. Direct Key Agreement Key Transport is defined in Section 8.5.4" OLD "Key Agreement with Key Wrap is defined in Section 9.5.5" NEW "Key Agreement with Key Wrap is defined in Section 8.5.5" "10. IANA Considerations IANA is requested to updte ll COSE registeries except for "COSE Header Parmeters" Needs to be proof-read Göran From: Benjamin Kaduk <[email protected]> Date: Monday, 11 July 2022 at 06:01 To: Göran Selander <[email protected]> Cc: [email protected] <[email protected]> Subject: Re: [COSE] questions for the WG from 8152bis AUTH48 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
