Hi Göran, On Wed, Jul 27, 2022 at 08:03:49AM +0000, Göran Selander wrote: > Hi Ben, > > As it was discussed in the COSE meeting, just to confirm that I agree with > your conclusion in this thread.
Thanks. > 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). Thanks for passing these along; I have been working in a local copy since the RFC Production Center always makes a number of changes to the XML as submitted, and I don't think I have direct github access to that repo. > [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" These are already fixed in the working copy. > > 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.” Good catch, thanks. Per -struct, "derive key" and "derive bits" are the official spellings. > > 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“ Got this one already. > 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" Apparently I had this one as 8.5.3, introducing a different error. Thanks for making me check again. > > 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 The IANA considerations look quite different in the RPC's versions. Since the URI is eminently guessable, I don't mind posting the link to their copy: https://www.rfc-editor.org/authors/rfc9053.html#name-iana-considerations Thanks again, Ben > > > 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
