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

[Marco Tiloca <[e-mail]>]

Hello Jim,

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

Best,
/Marco

On 7/8/19 6:07 AM, Jim Schaad wrote:
> 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.

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

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

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

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

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


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

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

>
> Jim
>  
>
>

-- 
Marco Tiloca
Ph.D., Senior Researcher

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

Phone: [phone]
https://www.ri.se