[Ace] draft-ietf-ace-key-groupcomm-oscore

[Jim Schaad <[e-mail]>]

I was wandering through the document with a view to implementing and have
the following questions:

1.  Abstract: From the first paragraph I am not sure if the group
communications or the communications to the KDC are secured with OSCORE.

2.  Section 3.1 - "requester" seems to be an odd name for "sender" or
"publisher"

3. Section 3.1 - I am trying to figure out why a Gid would be a reasonable
value for the scope.  This means that the AS is going to be the one to
assign the Gid value in many cases as it needs to check the scope value
there.  Is that going to be a common case?  I.e. Are Gids going to be
assigned by administrators?

4. Section 3.1 - Is the form in Appendix C of the Gid in some respect
mandatory?  If it is not, then how does a receiver of a message distinguish
between two different groups that are using the same multicast address?  Is
that going to be a non-supported case?  The most common case of this would
be having two different groups on the default CoAP multicast address talking
to RDs with different permissions at the RD to see things.

5. Section 4.1 - I can understand things relative to the key_info blob that
is being returned.  I am not sure that I think that this is being defined
correctly however.  It makes more sense to me to have the following:
key_info = [ sign_alg: COSE_Algorithm, ?sign_parameters : map,
?key_parameters: map ] where the two maps are filled in from the required
fixed parameters from the two COSE registries.  This would end up with
something like the following as a potential value   [ sign_alg: ECDSA,
key_parameters: {'kty':'EC2', 'crv': 'P256'}]

6. Section 4.1.1 - why is the key info parameter format application
specific?  I would have assumed that it was the same as in the previous
section.

7.  Section 4.2 - for 'client_cred', I am unsure what the client is supposed
to do if the joining node does not know the countersignature algorithm.  Can
the include public key not be in a consistent format?  What does consistent
format even mean?

8. Section 4.3 - I don't understand why the GM is accepting the join request
if the client_cred passed in was not in the correct format.  Is this a typo?

9.  Section 6 - I don't know that the third bullet is in the list of cases
where the client_cred parameter is not required.

10.  Section 6 - What is the POP method for the fourth bullet method?

11. Section 6 - What happens if any of first three bullets is true, but the
cached key does not match the required key parameters for the signing
algorithm.  In some of these cases there is no check that any signature
algorithm parameters that might exist are going to be checked and enforced.

12.  Section 7 - This text implies to me that all users of a group key need
to be able to act as servers and have a fixed port number which was supplied
some how to the GM so that it can be notified.   This could be done by
keeping up the DTLS session, but that is still a little bit tricky and would
not work for OSCORE based messages.  This text might want to point to the
section in the ietf-ace-key-groupcomm that deals with this and require that
the query or subscribe methods be supported.  Although both of those suffer
from the lack of hard break on the part of publishers.

Jim