Hi,
Thanks for this clear (but long) document. I think overal it is in very
good shape. Most of my comments are minor.
The one thing I did want to highlight is that the use of the REQxx and
OPTxx values seem to be missing some entries,
possibly due to rewrites and getting lost.
Section 1
In the CBOR diagnostic notation used in this document, constructs
of the form e'SOME_NAME' are replaced by the value assigned to
SOME_NAME in the CDDL model shown in Figure 12 of Appendix C. For
example, {e'gp_enc_alg': 10, e'sign_alg': -8} stands for {9:
10, 10: -8}.
Note to RFC Editor: Please delete the paragraph immediately
preceding this note. Also, in the CBOR diagnostic notation used
in this document, please replace the constructs of the form
e'SOME_NAME' with the value assigned to SOME_NAME in the CDDL
model shown in Figure 12 of Appendix C. Finally, please delete
this note.
Why not leave the curent syntac in the document for readability?
Section 2.
All communications between the involved entities MUST be secured.
In particular, communications between the Client and the Group
Manager leverage protocol-specific transport profiles of ACE
to achieve [...]
The first sentence is a bit confusing. How about merging these sentence to:
Communications between the Client and the Group Manager MUST
leverage protocol-specific transport profiles of ACE
to achieve [...]
Section 3
Furthermore, this document define
I would remove "Furthermore,"
I would remove "Furthermore,"
In particular, the following holds for each scope entry:
I would say:
For each scope entry:
More specifically, the following applies when, as defined in
this document, a scope entry includes as set of permissions the
set of roles to take in an OSCORE group.
I would rewrte this as:
If the set of roles to take in an OSCORE group is included as
a set of permissions in the scope entry:
Section 4
As also discussed in
I would remove "also".
If the joining node still provides an authentication credential
in the 'client_cred' parameter of the Join Request (see Section
6.1), the Group Manager silently ignores that parameter and the
related parameter 'client_cred_verify'.
The question here is whether the Postel Principle is useful here or not.
With
a new deployment, wouldn't it be better to fail to avoid these kind of bad
implementations from ever gaining market share?
* The joining node is currently a group member, and it is
re-joining the group not exclusively as monitor.
In this case, the joining node MAY choose to omit the
'client_cred' parameter and the 'client_cred_verify' parameter in
the Join Request, if it intends to use the same authentication
credential that it is currently using in the group (see Section
4.3.1.1 of [RFC9594]).
I'm a little confused here. The re-join presumbly is to change its role?
But if it previously joined as Monitor, no credentials were given (or
ignored
if given). So re-joining it as not exclusively a Monitor , surely it MUST
include
a credential?
In the other cases, it must have presented a credential already, so why the
MAY
choose to omit instead of MUST omit? (again the same Postel Principle
question here)
Section 5
The following considers a joining node [...]
"following" is not very specific whether it means, subsection, section or
multiple
sections. Why not (as Section 6 does):
This Section considers a joining node [...]
for which this document defines the entries in Table 1
This modifier makes it confusing what to do when another document adds
entries
to the Group OSCORE Roles registry that are not in Table 1. I would remove
this
text.
The AS MUST include the 'expires_in' parameter. Other means for
the AS to specify the lifetime of access tokens are out of the
scope of this document.
Are these in scope for other documents? If so, would those documents undo
this
MUST entry? Or can those documents only add an _additional" lifetime
method. If
there are multiple kinds of lifetimes, what does one do? Pick the shortest
of the
set?
id' MUST NOT refer to OSCORE groups that are [pairwise |
signature-only ]
What action should be taken if the wrong kind of groups are refered to?
Should just
these groups be ignored and others still processed? Or should the entire
request be
dropped?
Similar, what to do for violating the MUST in cred_fmt ? (this might be
obvious to
implementers so this might not require new text, Section 6 does give
specific advise
on what to do on errors)
[ As to C509 certificates, the COSE Header Parameters
'c5b' and 'c5c' are under pending registration requested by
draft-ietf-cose-cbor-encoded-cert. ]
To me the [ square brackets ] makes this look like a note to the RFC
editor, and
not to the reader. I think the [] are better omited. This same applies to
this
same entry in Section 6.
Section 6
it is RECOMMENDED to use an 8-byte long random nonce.
Can 8 zero bytes be used? I assume not? So perhaps this needs to
say a little bit more? Or perhaps this RECOMMENDED is a MUST ?
The response MUST have Content-Format set to
"application/concise-problem-
details+cbor" [RFC9290] and is formatted as defined in
Can we ensure with the RFC Editor that the header does not wrap, so
people don't get confused whether "-" is a line wrap or part of the
media type name? (there are more cases that wrap in this section)
In order to prevent the acceptance of Ed25519 and Ed448
public keys that cannot be successfully converted to
Montgomery coordinates, and thus cannot be used for
the derivation of pairwise keys (see Section 2.5.1 of
[I-D.ietf-core-oscore-groupcomm]), the Group Manager MAY reply
with a 4.00 (Bad Request) error response in case all the following
conditions hold:
Why is this a MAY and not a MUST ?
The 'cnonce' parameter MUST include a new dedicated nonce N_C
generated by the joining node.
Is the Group Manager supposed to track this to enforce? If so, perhaps
explicit text for that should be added or else implementers won't enforce
this.
If the application requires backward security, the Group
Manager MUST generate updated security parameters and group
keying material, and provide it to the current group members,
upon the new node's joining (see Section 11).
Is this not a race condition? I find the timing is unclearly specified by
the word "upon". Wouldn't the new member we able to read a sporadic message
from the group? (and every logged historic message?)
Section 9.9
Upon learning from a 2.05 (Content) Group Status Response that
the group is currently inactive, the group member SHOULD stop
taking part in communications within the group, until the group
becomes active again.
How can it know if a group becomes active again, unless it is listening to
the group? And if it is listening, isn't it "taking part in communications"?
Can it ignore/prevent group activity and only listen to the Group Manager's
message that a group becomes active again?
What if a member ignores this SHOULD, what should other members do? ignore
or
act on such messages?
Section 10
The Group Manager frees the OSCORE [...]
[...]
The Group Manager deletes the authentication credential [...]
Is there a difference between "freeing" and "deleting" ?
Once completed the group rekeying process
Maybe more clear:
Once the group rekeying process has completed
There is also some use of "they" to refer to clients, which is better
changed to "the client" or "member", etc, depending on context.
Appendix.A
My understanding is that this appendix is the summary of requirements,
so I would expect all REQxx entries in this list to have an entry in
the main document.
But this is not true for: REQ2, REQ9, REQ16, REQ17, REQ18, REQ19, REQ20
REQ22, REQ23, REQ24, REQ27
And: OPT1, OPT4, OP5, OPT6, OPT8, OPT11, OPT12, OPT13
Paul
_______________________________________________
Ace mailing list -- [email protected]
To unsubscribe send an email to [email protected]
