Subject: [COSE] questions for the WG from 8152bis AUTH48

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 17 Feb 2022 20:59:49 -0800

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?

The other question is in -algs; in
https://datatracker.ietf.org/doc/html/draft-ietf-cose-rfc8152bis-algs#section-8
we start off with a rather awkward sentence "There are some situations that
have been identified where identification of capabilities of an algorithm
or a key type need to be specified."  In particular (at least to me), the
"identification ... needs to be specified" seems like the verb tenses don't
even match up properly, or something of that nature, but I can't properly
describe exactly what seems off.  The current proposal from the RFC Editor
is to dramatically replace this sentence with the bland "The capabilities of
an algorithm or key type need to be specified in some situations".  Does
anyone object to that change?

Thanks,

Ben

---

From: Michael Richardson <[email-masked]>
Date: Fri, 18 Feb 2022 12:49:45 -0500

Benjamin Kaduk <[email-masked]> wrote:
    > 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.

Thanks for this.

    > 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.

My reading of this is that it is about some kind of DH key operation.
Do you think of your g^x as being public or derived from private?
The x is obviously private, and you need it to compute (g^y)^x.

I'm not sure what other method derives keys from two public things without
each party also having some private parts.

    > 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.

Here, I think you are asking if the COSE Key Common Parameters would contain
private keys?  I don't get that impression... the kid would identity what
private components are being referenced.

    > 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
    > 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?

I agree with you conclusion, but I'm not sure that I agree we got there the
same way.

    > we start off with a rather awkward sentence "There are some situations
    > that have been identified where identification of capabilities of an
    > algorithm or a key type need to be specified."

    > In particular (at least
    > to me), the "identification ... needs to be specified" seems like the
    > verb tenses don't even match up properly, or something of that nature,
    > but I can't properly describe exactly what seems off.  The current
    > proposal from the RFC Editor is to dramatically replace this sentence
    > with the bland "The capabilities of an algorithm or key type need to be
    > specified in some situations".  Does anyone object to that change?

I can live with that.
The repeated use of "identified" / "identification" is really really awkward,
and I think uselessly obtuse.   Maybe more detail from core-oscore-groupcomm
would help the reader.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 18 Feb 2022 20:36:46 +0200

> https://datatracker.ietf.org/doc/html/draft-ietf-cose-rfc8152bis-algs#section-8

On -algs, looks like table 16 in section 6.4.1. is inconsistent about
the KDF used. The KDF field lists HKDF, but description says Concat
KDF. I believe the HKDF is correct. This has then gotten copied into
the IANA registry, except the IANA registry does not seem to have the
KDF column, so IANA registry claims those codepoints are using Concat
KDF, which I do not think is correct.

-Ilari

---

From: Marco Tiloca <[email-masked]>
Date: Fri, 18 Feb 2022 19:50:35 +0100

Hi Ben and all,

On 2022-02-18 05:59, Benjamin Kaduk wrote:
> https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-cose-rfc8152bis-algs%23section-8&amp;data=04%7C01%7Cmarco.tiloca%40ri.se%7C634eeebfc73d4bda82d108d9f29b9b26%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637807572981435893%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=A1x%2BuzSMoO%2FwsjO%2BjpLGCj%2BCRhK2BRRLCdqLrKFTw88%3D&amp;reserved=0

==>MT
On -algs, I agree with the proposed simplification for the first 
sentence, and I have now also had a deeper look into the following 
sentence, i.e.:

"One example of this is in [I-D.ietf-core-oscore-groupcomm] where the 
capabilities of the counter signature algorithm are mixed into the 
traffic key derivation process."

Note that the COSE -algs document is referring to version -09 of 
-core-oscore-groupcomm. That version was indeed still using COSE 
capabilities, but not as part of a key derivation process. Rather, they 
were used to build the OSCORE external_aad to bind requests and 
responses, see [1].

After a few revisions, we removed the explicit use of COSE capabilities 
altogether from -core-oscore-groupcomm. In fact, it was agreed to rather 
have the external_aad including full-fledged authentication credentials, 
i.e., the public key together with metadata related to the signature 
algorithm. This is the case in the latest version -13, see [2].

Practically, it is probably better to remove the following two sentences 
from the COSE -algs document:

* In Section 8, the second sentence of the first paragraph, also quoted 
above, i.e., "One example of this ... key derivation process."

* In Section 8.3, the second sentence of the first paragraph, i.e., 
"This is the approach that is being used by the group communication KDF 
in [I-D.ietf-core-oscore-groupcomm]."

For what is worth, the COSE capabilities are used with a descriptive 
purpose in the ACE documents [3] and [4] about key provisioning for 
group communication. That is, the Key Distribution Center responsible 
for a group can leverage COSE capabilities to provide a description of 
how the group works, in terms of signature algorithm parameters and 
signature key parameters. I am not suggesting to add these examples to 
the COSE -algs document :-)

Best,
/Marco

[1] 
https://datatracker.ietf.org/doc/html/draft-ietf-core-oscore-groupcomm-09#section-4.3.1

[2] 
https://datatracker.ietf.org/doc/html/draft-ietf-core-oscore-groupcomm-13#section-4.3

[3] https://datatracker.ietf.org/doc/html/draft-ietf-ace-key-groupcomm

[4] 
https://datatracker.ietf.org/doc/html/draft-ietf-ace-key-groupcomm-oscore
<==

> Thanks,
>
> Ben
>
> _______________________________________________
> COSE mailing list
> [email-masked]
> https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fcose&amp;data=04%7C01%7Cmarco.tiloca%40ri.se%7C634eeebfc73d4bda82d108d9f29b9b26%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637807572981435893%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=j%2FhYXB2SOOMyUp8wKYztlpuOLJXSYtuOOkFxSXPcMik%3D&amp;reserved=0

-- 
Marco Tiloca
Ph.D., Senior Researcher

Division: Digital System
Department: Computer Science
Unit: Cybersecurity

RISE Research Institutes of Sweden
https://www.ri.se

Phone: +46 (0)70 60 46 501
Isafjordsgatan 22 / Kistagången 16
SE-164 40 Kista (Sweden)

---

From: Göran Selander <[email-masked]>
Date: Mon, 21 Feb 2022 15:18:01 +0000

On 2022-02-18, 06:00, "COSE on behalf of Benjamin Kaduk" <[email-masked] on behalf of [email-masked]> wrote:

    Hi all,

    In

[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"?

Göran