Subject: [core] Comments on draft-ietf-core-oscore-groupcomm-05

From: Jim Schaad <[email-masked]>
Date: Sun, 7 Jul 2019 21:07:36 -0700

This is not a full review, I did a fast look at the differences in between
-04 and -05 and am commenting on these.

1.   The addition of two optional parameters in the aad_array in section
3.1.  In terms of have a deterministic string result this is considered bad
practice as if only one of them is supplied, it could be confused with the
other one.

2.  Who is supposed to validate the parameters dealing with signatures?  Is
this the responsibility of the KDC or does each entity need to do this?  Is
there an optimization that can be applied so that all of these parameters
don't need to be distributed with the rest of the public key fields at a
later date?

3.  I am not sure why RSA-OAEP in the tables, I have never heard of anybody
using these as signature algorithms.

4.  Why did you insert the OSCORE_options field into the aad_array before
the options field?  It would be cleaner to have it at the end to minimize
the differences between the structures.

5.  Just what is the type in section 9.2 for  EdDSA?

Jim

---

From: Marco Tiloca <[email-masked]>
Date: Wed, 10 Jul 2019 11:10:20 +0200

Hello Jim,

Thanks for your comments. Please, find some answers inline.

Best,
/Marco

> practice as if only one of them is supplied, it could be confused with the

<MT>
Ok, we will change the encoding of 'par_countersign' and
'par_countersign_key'.

We can use the same encoding of 'sign_parameters' and
'sign_key_parameters' in the 'sign_info_res' array of
https://tools.ietf.org/html/draft-ietf-ace-key-groupcomm-02#section-3.3
</MT>

> don't need to be distributed with the rest of the public key fields at a

<MT>
Yes, it's up to the Group Manager (KDC), when handling the joining of a
new group member and collecting its public key.

For instance, the joining process described in ace-key-groupcomm-oscore
takes care of this, see
https://tools.ietf.org/html/draft-ietf-ace-key-groupcomm-oscore-02#section-4.3

We will also clarify it in this document, and add a bullet point in
Section 7, i.e. the list of responsibilities of the Group Manager.

As to the second part of the comment, do you mean a minimal shortened
encoding of public keys? For instance, a COSE Key where some parameters
are not included, and default values are assumed instead?

If so, this should also mean having some more admitted ACE Public Key
Encoding values than the normal "COSE_Key", see Figure 2 in
https://tools.ietf.org/html/draft-ietf-ace-key-groupcomm-oscore-02#section-4.1
</MT>

> using these as signature algorithms.

<MT>
That was an oversight. We will remove the last three entries in the
registry.
</MT>

> the differences between the structures.

<MT>
Right, we will move the OSCORE option to the end, after the class I options.
</MT>

> 5.  Just what is the type in section 9.2 for  EdDSA?

<MT>
Do you mean the key type 'kty' ? It is 1 (OKP), as specified in the
"Description" column. What is missing?
</MT>

-- 
Marco Tiloca
Ph.D., Senior Researcher

RISE Research Institutes of Sweden
Division ICT
Isafjordsgatan 22 / Kistagången 16
SE-164 40 Kista (Sweden)

Phone: +46 (0)70 60 46 501
https://www.ri.se