Draft: draft-ietf-ace-key-groupcomm

Commentary: AP42 : sketch some considerations about Blockwise and old / new keys 
 AP40 : add considerations ( see https://core- ) about keeping old security context for a while . 
 AP27 : membership change rekeying . If you have 30 joins in the course of a minute , you might want to delay the rekey messages slightly or make the presumption that there is not traffic that needs to be protected on a backwards basis to the first join . Similar issues will arise for leaves . 
 AP24 : In Section 7.2 , mention a possible policy at the KDC for keeping public keys of group members for a given amount of time after their leaving , before discarding them . it would also solve the issue if you decided that this is totally reasonable as A should not expect its message to be processed after it has left the group . 
 AP34 : Section 4.2 - add text : the type of profile is CBOR int 
 AP33 : clarify in the text the difference between “ transfer profiles ” ( such as DTLS profile , OSCORE profile ) and “ application profiles ” ( such as ace - key - groupcomm - oscore or ace - coap - pubsub ) 
 AP32 : section 4.2 : ‘ scope ’ received in the Key Distribution Request is < sthe same as</sa subset of the ‘ scope ’ stored in the access token associated to this client . 
 AP31 : describe the following : sign the key distribution request together with a nonce that was sent from the KDC ( for the sake of freshness ) , using the private key paired to the public key sent in ‘ client_cred ’ . 
 AP30 : Section 3.2 - The string “ can simply replay with ” is what messed me up . Better would be “ the AS replies with an Authorization Response with a new access token . ” The use of “ can ” is not the same as “ will ” . 
 AP28 : We propose to implement this mechanism as follow : We will define the format of ‘ grouppolicies ’ as CBOR map . We will define a new registry for ‘ grouppolicies ’ . In this registry , we will define a new parameter that contains the time as you describe . If you have ideas about the name , that would be very helpful . And since we define the registry , we can add the “ sync seq number ” parameter in it as well , which is listed as an example right now . 
 AP26 : Add a new section describing all the items that a profile must cover in order to be used . 
 AP25 : In Section 9.1 , add some text about allowing several profiles in the ' profile ' column . 
 AP22 : The proposal is to add a “ Type ” field to requests , as we have enough types to motivate that ( key distribution request , leave request , update key request , new key request ) . We will register the different types in a new IANA registry . The two new types are intended for current group members and are the following : “ update ” : the node can send it to get updated keying material ( might get back the same , if it did n't change ) . “ new ” : the node can send it to retrieve a new key i d , if it needs new keying material ( e.g. seq numbers have wrapped around , expiration , etc ) . We will also remove the “ leave ” field as that is not needed anymore . 
 AP21 : In Section 6 , clarify that group rekeying is not about one single multicast message containing the new key . The point is exactly about using secure rekeying schemes that , by sending also multicast messages , are able to lock out the leaving node and effectively exclude it . + Add a reference to such a scheme 
 AP20 : In Section 6 , clarify that is it application dependent and pertaining to the particular message exchange ( e.g. Group OSCORE ) for a client to to keep decryption failures messages so that they can be decrypted after getting new key material , rather that just considering it a loss of message right away . 
 AP18 : In Section 6 , in the second paragraph it says that the problem is not being able to decrypt a message ; clarify that the correct condition is not being able to find key material . A corruption in the message should not require the entity to looking for a rekey event to be checked . This is a bad DOS vector otherwise . 
 AP17 : In Section 6.2 , change the ' exp ' parameter as one that MUST be included in the Key Distribution Response . 
 AP16 : In Section 5.2 , rephrase so that " not formatted correctly " means that the KDC can not figure out what it is asked to do . 
 AP15 : Remove ' client_cred ' from the leave request in Section 5.2 . 
 AP13 : Move the last paragraph of Section 4.2 to the end of Section 4 . 
 AP11 : ' group_policies ' in Section 4.2 data format as CBOR map 
 AP9 : In Section 4.2 , specify that ' exp ' indicates a UNIX time , same as ' exp ' defined in RFC7519 . 
 AP8 : ' pubkeysrepos ' , as a CBOR array of tstr containing URIs . 
 AP7 : CBOR bstr as data structure for ' clientcred ' . That is the most general format . If for example COSEKeys are used , they can be wrapped in a bstr . 
 AP5 : In Section 2 , remove " further " from the last paragraph . 
 AP4 : Replace references to RFC 7390 with references to RFC7390 and draft - dijk - core - groupcomm - bis . 
 AP3 : Create a new registry for parameters used , and re - use the same number as ACE as much as possible ( for parameters that appear in both , such as ‘ profile ’ , ‘ exp ’ ) . 
 AP2 : Clarify that where  is used ( 3 first messages ) , the content - format used is the one defined in ACE ( application / ace+cbor and possibly application / cwt ) . In the last 2 messages ( Key distribution  and Response ) the content - format is supposed to be application / cbor , as that is the type of the payload . 
 AP1 : add some note to say that using  is possible ( conversion specified in Sections 4.1 and 4.2 of RFC 7049 )
This document expands the ACE framework I-D.ietf-ace-oauth-authz to
define the format of messages used to request, distribute and renew
the keying material in a group communication scenario, e.g. based on
multicast RFC7390 or on publishing-subscribing I-D.ietf-core-coap-
pubsub.
Profiles that use group communication can build on this document to
specify the selection of the message parameters defined in this
document to use and their values.  Known applications that can
benefit from this document would be, for example, profiles addressing
group communication based on multicast RFC7390 or publishing/
subscribing I-D.ietf-core-coap-pubsub in ACE.
This document expands the ACE framework I-D.ietf-ace-oauth-authz to
define the format of messages used to request, distribute and renew
the keying material in a group communication scenario, e.g. based on
multicast I-D.dijk-core-groupcomm-bis or on publishing-subscribing I-
D.ietf-core-coap-pubsub.  The ACE framework is based on CBOR RFC7049,
so CBOR is the format used in this specification.  However, using
JSON RFC7159 instead of CBOR is possible, using the conversion method
specified in Sections 4.1 and 4.2 of RFC7049.
Profiles that use group communication can build on this document to
specify the selection of the message parameters defined in this
document to use and their values.  Known applications that can
benefit from this document would be, for example, those addressing
group communication based on multicast I-D.dijk-core-groupcomm-bis or
publishing/subscribing I-D.ietf-core-coap-pubsub in ACE.
Transport profile, to indicate a profile of ACE as per
Section 5.6.4.3 of I-D.ietf-ace-oauth-authz.  That is, a transport
profile specifies the communication protocol and communication
security protocol between an ACE Client and Resource Server, as
well as proof-of-possession methods, if it supports proof-of-
possession access tokens.  Tranport profiles of ACE include, for
instance, I-D.ietf-ace-oscore-profile, I-D.ietf-ace-dtls-authorize
and I-D.ietf-ace-mqtt-tls-profile.
Application profile, to indicate a profile of ACE that defines how
applications enforce and use supporting security services they
require.  These services include, for instance, provisioning,
revocation and (re-)distribution of keying material.  An
application profile may define specific procedures and message
formats.
The exchange of Authorization Request and Authorization Response
between Client and AS MUST be secured, as specified by the ACE
profile used between Client and KDC.
The exchange of Key Distribution Request and Key Distribution
Response between Client and KDC MUST be secured, as a result of the
ACE profile used between Client and KDC.
All further communications between a Client and the other group
members MUST be secured using the keying material provided in key-
distr.
The exchange of Authorization Request and Authorization Response
between Client and AS MUST be secured, as specified by the transport
profile of ACE used between Client and KDC.
The exchange of Key Distribution Request and Key Distribution
Response between Client and KDC MUST be secured, as a result of the
transport profile of ACE used between Client and KDC.
All communications between a Client and the other group members MUST
be secured using the keying material provided in key-distr.
As defined in I-D.ietf-ace-oauth-authz, the Client requests from the
AS an authorization to join the group through the KDC (see ssec-
authorization-request).  If the request is approved and authorization
is granted, the AS provides the Client with a proof-of-possession
access token and parameters to securely communicate with the KDC (see
ssec-authorization-response).  Communications between the Client and
the AS MUST be secured, and depends on the profile of ACE used.
As defined in I-D.ietf-ace-oauth-authz, the Client requests from the
AS an authorization to join the group through the KDC (see ssec-
authorization-request).  If the request is approved and authorization
is granted, the AS provides the Client with a proof-of-possession
access token and parameters to securely communicate with the KDC (see
ssec-authorization-response).  Communications between the Client and
the AS MUST be secured, according to the transport profile of ACE
used.  The Content-Format used in the messages is the one specified
by the used transport profile of ACE (e.g. application/ace+cbor for
the first two messages and application/cwt for the third message,
depending on the format of the access token).
The access token MUST contain all the parameters defined above
(including the same 'scope' as in this message, if present, or the
'scope' of the Authorization Request otherwise), and additionally
other optional parameters the profile requires.
When receiving an Authorization Request from a Client that was
previously authorized, and which still owns a valid non expired
access token, the AS can simply reply with an Authorization Response
including a new access token.
The Client sends a CoAP POST request including the access token to
the KDC, as specified in section 5.8.1 of I-D.ietf-ace-oauth-authz.
If the specific ACE profile defines it, the Client MAY use a
different endpoint than /authz-info at the KDC to post the access
token to.  After successful verification, the Client is authorized to
receive the group keying material from the KDC and join the group.
The access token MUST contain all the parameters defined above
(including the same 'scope' as in this message, if present, or the
'scope' of the Authorization Request otherwise), and additionally
other optional parameters that the transport profile of ACE requires.
When receiving an Authorization Request from a Client that was
previously authorized, and which still owns a valid non expired
access token, the AS replies with an Authorization Response with a
new access token.
The Client sends a CoAP POST request including the access token to
the KDC, as specified in section 5.8.1 of I-D.ietf-ace-oauth-authz.
If the specific transport profile of ACE defines it, the Client MAY
use a different endpoint than /authz-info at the KDC to post the
access token to.
After successful verification, the Client is authorized to receive
the group keying material from the KDC and join the group.  In
particular, the KDC replies to the Client with a 2.01 (Created)
response, using Content-Format "application/ace+cbor" defined in
Section 8.14 of I-D.ietf-ace-oauth-authz.  The payload of the 2.01
response is a CBOR map, which MUST include a nonce N generated by the
KDC.  The Client may use this nonce for proving the possession of its
own private key (see the 'client_cred_verify' parameter in key-
distr).
During this exchange, the Client sends a request to the AS,
specifying the group it wishes to join (see ssec-key-distribution-
request).  Then, the KDC verifies the access token and that the
Client is authorized to join that group; if so, it provides the
Client with the keying material to securely communicate with the
member of the group (see ssec-key-distribution-response).
During this exchange, the Client sends a request to the AS,
specifying the group it wishes to join (see ssec-key-distribution-
request).  Then, the KDC verifies the access token and that the
Client is authorized to join that group; if so, it provides the
Client with the keying material to securely communicate with the
member of the group (see ssec-key-distribution-response).  The
Content-Format used in the messages is set to application/cbor.
'type', encoded as a CBOR int, with value TBD1.
'client_cred', with value the public key or certificate of the
Client.  If the KDC is managing (collecting from/distributing to
the Client) the public keys of the group members, this field
contains the public key of the Client.
'pub_keys_repos', can be present if a certificate is present in
the 'client_cred' field, with value a list of public key
repositories storing the certificate of the Client.
The KDC verifies the 'scope' received in the Key Distribution
Request, if present, against the 'scope' stored in the access token
associated to this client.  If verification fails, the KDC MUST
respond with a 4.01 (Unauthorized) error message.  If the Key
Distribution Request is not formatted correctly (e.g. no 'scope'
field present while expected, or unknown fields present), the KDC
MUST respond with 4.00 (Bad Request) error message.
'client_cred', with value the public key or certificate of the
Client, encoded as a CBOR byte string.  If the KDC is managing
(collecting from/distributing to the Client) the public keys of
the group members, this field contains the public key of the
Client.  The default encoding for public keys is COSE Keys.
Alternative specific encodings of this parameter MAY be defined in
applications of this specification.
'client_cred_verify', encoded as a CBOR byte string.  This
parameter contains a signature computed by the Client over the
nonce N received from the KDC in the 2.01 (Created) response to
the token POST request (see token-post).  The Client computes the
signature by using its own private key, whose corresponding public
key is either directly specified in the 'client_cred' parameter or
included in the certificate specified in the 'client_cred'
parameter.  This parameter MUST be present if the 'client_cred'
parameter is present.
'pub_keys_repos', can be present if a certificate is present in
the 'client_cred' field, with value a list of public key
repositories storing the certificate of the Client.  This
parameter is encoded as a CBOR array of CBOR text strings, each of
which specifies the URI of a key repository.
The KDC verifies that the 'scope' received in the Key Distribution
Request, if present, is a subset of the 'scope' stored in the access
token associated to this client.  If verification fails, the KDC MUST
respond with a 4.01 (Unauthorized) error message.
If the Key Distribution Request is not formatted correctly (e.g. no
'scope' field present while expected, or unknown fields present), the
KDC MUST respond with 4.00 (Bad Request) error message.
'kty', identifying the key type of the 'key' parameter.  The set
of values can be found in the "Key Type" column of the "ACE
Groupcomm Key" Registry.  Implementations MUST verify that the key
type matches the profile being used, if present, as registered in
the "ACE Groupcomm Key" registry.
'kty', identifying the key type of the 'key' parameter.  The set
of values can be found in the "Key Type" column of the "ACE
Groupcomm Key" Registry.  Implementations MUST verify that the key
type matches the application profile being used, if present, as
registered in the "ACE Groupcomm Key" registry.
The exact format of the 'key' value MUST be defined in applications
of this specification.  Additionally, documents specifying the key
format MUST register it in the "ACE Groupcomm Key" registry,
including its name, type and profile to be used with, as defined in
the "ACE Groupcomm Key" registry, defined in iana-key.
'profile', with value an identifier that MUST be used to uniquely
identify itself.  The identifier MUST be registered in the "ACE
Groupcomm Profile" Registry.
'exp', with value the expiration time of the keying material for
the group communication, encoded as a CBOR unsigned integer or
floating-point number.
'pub_keys', may only be present if 'get_pub_keys' was present in
the Key Distribution Request.  This parameter is a CBOR Byte
String, which encodes the public keys of all the group members
paired with the respective member identifiers.  In case public
keys in the group are represented as COSE Keys, the CBOR Byte
String encodes a COSE_KeySet (see RFC8152), which contains the
public keys of all the members of the group.  In particular, each
COSE Key in the COSE_KeySet includes the identifier of the
corresponding group member as value of its 'kid' key parameter.
Alternative specific encodings of this parameter MUST be defined
in applications of this specification.
'group_policies', with value a list of parameters indicating how
the group handles specific management aspects.  This includes, for
instance, approaches to achieve synchronization of sequence
numbers among group members.  The exact format of this parameter
is specific to the profile.
'mgt_key_material', with value the administrative keying material
to participate in the group rekeying performed by the KDC.  The
exact format and content depend on the specific rekeying scheme
used in the group, which may be specified in the profile.
Specific profiles need to specify how exactly the keying material is
used to protect the group communication.
The exact format of the 'key' value MUST be defined in applications
of this specification.  Additionally, documents specifying the key
format MUST register it in the "ACE Groupcomm Key" registry,
including its name, type and application profile to be used with, as
defined in the "ACE Groupcomm Key" registry, defined in iana-key.
'profile', with value a CBOR integer that MUST be used to uniquely
identify the application profile for group communication.  The
value MUST be registered in the "ACE Groupcomm Profile" Registry.
'exp', with value the expiration time of the keying material for
the group communication, encoded as a CBOR unsigned integer or
floating-point number.  This field contains a numeric value
representing the number of seconds from 1970-01-01T00:00:00Z UTC
until the specified UTC date/time, ignoring leap seconds,
analogous to what specified in Section 2 of RFC7519.
'pub_keys', may only be present if 'get_pub_keys' was present in
the Key Distribution Request.  This parameter is a CBOR byte
string, which encodes the public keys of all the group members
paired with the respective member identifiers.  The default
encoding for public keys is COSE Keys, so the default encoding for
'pub_keys' is a CBOR byte string wrapping a COSE_KeySet (see
RFC8152), which contains the public keys of all the members of the
group.  In particular, each COSE Key in the COSE_KeySet includes
the identifier of the corresponding group member as value of its
'kid' key parameter.  Alternative specific encodings of this
parameter MAY be defined in applications of this specification.
'group_policies', with value a CBOR map, whose entries specify how
the group handles specific management aspects.  These include, for
instance, approaches to achieve synchronization of sequence
numbers among group members.  The elements of this field are
registered in the "ACE Groupcomm Policy" Registry.  This
specification defines the two elements "Sequence Number
Synchronization Method" and "Key Update Check Interval", which are
summarized in fig-ACE-Groupcomm-Policies.  Application profiles
that build on this document MUST specify the exact content format
of included map entries.
'mgt_key_material', encoded as a CBOR byte string and containing
the administrative keying material to participate in the group
rekeying performed by the KDC.  The exact format and content
depend on the specific rekeying scheme used in the group, which
may be specified in the application profile.
Specific application profiles that build on this document need to
specify how exactly the keying material is used to protect the group
communication.
'leave', with value an empty CBOR array.
'client_cred', with value the identifier of the public key or
certificate of the Client.  This field is used if the KDC is
managing (collecting from/distributing to the Client) the public
keys of the group members.
If the Leave Request is not formatted correctly (e.g. no 'scope'
field present, or unknown fields present), the KDC MUST respond with
a 4.00 (Bad Request) error message.  Otherwise, the KDC MUST remove
the leaving node from the list of group members, if the KDC keeps
track of that.
'type', encoded as a CBOR ints, with value TBD2.
If the Leave Request is such that the KDC cannot extract all the
necessary information to understand and process it correctly (e.g. no
'scope' field present), the KDC MUST respond with a 4.00 (Bad
Request) error message.  Otherwise, the KDC MUST remove the leaving
node from the list of group members, if the KDC keeps track of that.
A node stops using the group keying material upon its expiration,
according to the 'exp' parameter specified in the retained COSE Key.
Then, if it wants to continue participating in the group
communication, the node has to request new updated keying material to
the KDC.
The Client may perform the same request to the KDC also upon
receiving messages from other group members without being able to
correctly decrypt them.  This may be due to a previous update of the
group keying material (rekeying) triggered by the KDC, that the
Client was not able to receive or decrypt.
Note that policies can be set up so that the Client sends a request
to the KDC only after a given number of unsuccessfully decrypted
incoming messages.
A node stops using the group keying material upon its expiration,
according to the 'exp' parameter specified in the retained COSE Key.
Then, if it wants to continue participating in the group
communication, the node has to request new updated keying material to
the KDC.  In this case, and depending on what part of the keying
material is expired, the client may need to communicate to the KDC
its need for that part to be renewed: for example, if the Client uses
an individual key to protect outgoing traffic and has to renew it,
the node may request a new one, or new input material to derive it,
without renewing the whole group keying material.
The Client may perform the same request to the KDC also upon
receiving messages from other group members without being able to
retrieve the material to correctly decrypt them.  This may be due to
a previous update of the group keying material (rekeying) triggered
by the KDC, that the Client was not able to receive or decrypt.
Note that policies can be set up so that the Client sends a request
to the KDC only after a given number of unsuccessfully decrypted
incoming messages.  It is application dependent and pertaining to the
particular message exchange (e.g.  I-D.ietf-core-oscore-groupcomm) to
set up policies that instruct clients to retain unsuccessfully
decrypted messages and for how long, so that they can be decrypted
after getting updated keying material, rather than just considered
non valid messages to discard right away.
The same request could also be sent by the client without being
triggered by a failed decryption of a message, if the client wants to
confirm that it has the latest group keying material.  If that is the
case, the client will receive from the KDC the same group keying
material it has in memory.
Note that the difference between the keying material renewal request
and the keying material update request is that the first triggers the
KDC to produce new keying material for that node, while the second
only triggers distribution (the renewal might have happened
independently, because of expiration).  Once a node receives new
individual keying material, other group members may need to use the
update keying material request to retrieve it.
Can send the payload of the Key Re-Distribution Response in a
multicast request to the members of the group.
Can send the payload of the Key Re-Distribution Response as one or
multiple multicast requests to the members of the group, using
secure rekeying schemes such as RFC2627.
'type', encoded as a CBOR int, with value TBD3 if the request is
intended to retrieve updated group keying material, and TBD4 if
the request is intended for the KDC to produce and provide new
individual keying material for the Client.
Otherwise, the KDC replies to the Client with a Key Distribution
Response, which MUST include the 'kty' and 'key' parameters specified
in ssec-key-distribution-response.  The Key Distribution Response MAY
also include the 'profile', 'exp', 'group_policies' and
'mgt_key_material' parameters specified in ssec-key-distribution-
response.
Otherwise, the KDC replies to the Client with a Key Distribution
Response, which MUST include the 'kty', 'key' and 'exp' parameters
specified in ssec-key-distribution-response.  The Key Distribution
Response MAY also include the 'profile', 'group_policies' and
'mgt_key_material' parameters specified in ssec-key-distribution-
response.
'type', encoded as a CBOR int, with value TBD5.
The KDC ignores possible identifiers included in the 'get_pub_keys'
parameter of the Public Key request if they are not associated to any
current group member.
This specification establishes the IANA "ACE Groupcomm Key" Registry.
The Registry has been created to use the "Expert Review Required"
registration procedure RFC8126.  Expert review guidelines are
provided in review.
The KDC may enforce one of the following policies, in order to handle
possible identifiers that are included in the 'get_pub_keys'
parameter of the Public Key request but are not associated to any
current group member.
The KDC silently ignores those identifiers.
The KDC retains public keys of group members for a given amount of
time after their leaving, before discarding them.  As long as such
public keys are retained, the KDC provides them to a requesting
Client.
Either case, a node that has left the group should not expect any of
its outgoing messages to be successfully processed, if received after
its leaving, due to a possible group rekeying occurred before the
message reception.
This specification defines a number of fields used during the message
exchange.  The table below summarizes them, and specifies the CBOR
key to use instead of the full descriptive name.
This specification defines a number of types of requests.  The table
below summarizes them.
The KDC may enforce a rekeying policy that takes into account the
overall time required to rekey the group, taking into account the
expected rate of changes in the group membership.
That is, the KDC may not rekey the group at every membership change,
for instance if members' joining and leaving occur frequently and
performing a group rekeying takes too long.  Instead, the KDC may
rekey the group after a minum number of group members have joined or
left within a given time interval, or during predictable network
inactivity periods.
However, this would result in the KDC not constantly preserving
backward and forward security.  In fact, newly joining group members
could be able to access the keying material used before their
joining, and thus could access past group communications.  Also,
until the KDC performs a group rekeying, the newly leaving nodes
would still be able to access upcoming group communications that are
protected with the keying material that has not yet been updated.
A group member can receive a message shortly after the group has been
rekeyed, and new keying material has been distributed by the KDC.  In
the following two cases, this may result in misaligned keying
material between the group members.
In the first case, the sender protects a message using the old keying
material.  However, the recipient receives the message after having
received the new keying material, hence not being able to correctly
process it.  A possible way to ameliorate this issue is to preserve
the old, recent, keying material for a maximum amount of time defined
by the application.  By doing so, the recipient can still try to
process the received message using the old retained keying material
as second attempt.  Note that a former (compromised) group member can
take advantage of this by sending messages protected with the old
retained keying material.  Therefore, a conservative application
policy should not admit the storage of old keying material.
In the second case, the sender protects a message using the new
keying material, but the recipient receives that request before
having received the new keying material.  Therefore, the recipient
would not be able to correctly process the request and hence discards
it.  If the recipient receives the new keying material shortly after
that and the sender endpoint uses CoAP retransmissions, the former
will still be able to receive and correctly process the message.  In
any case, the recipient should actively ask the KDC for an updated
keying material according to an application-defined policy, for
instance after a given number of unsuccessfully decrypted incoming
messages.
If the block-wise options RFC7959 are used, and the keying material
is updated in the middle of a block-wise transfer, the sender of the
blocks just changes the keying material to the updated one and
continues the transfer.  As long as both sides get the new keying
material, updating the keying material in the middle of a transfer
will not cause any issue.  Otherwise, the sender will have to
transmit the message again, when receiving an error message from the
recipient.
Compared to a scenario where the transfer does not use block-wise,
depending on how fast the keying material is changed, the nodes might
consume a larger amount of the network resending the blocks again and
again, which might be problematic.
This specification establishes the "ACE Groupcomm Parameters" IANA
Registry.  The Registry has been created to use the "Expert Review
Required" registration procedure RFC8126.  Expert review guidelines
are provided in review.
CBOR Key: This is the value used as CBOR key of the item.  These
values MUST be unique.  The value can be a positive integer, a
negative integer, or a string.
CBOR Type: This contains the CBOR type of the item, or a pointer
to the registry that defines its type, when that depends on
another item.
This Registry has been initially populated by the values in params.
The specification column for all of these entries will be this
document.
This specification establishes the "ACE Groupcomm Request Type" IANA
Registry.  The Registry has been created to use the "Expert Review
Required" registration procedure RFC8126.  Expert review guidelines
are provided in review.
Value: This is the value used to identify the request.  These
values MUST be unique.  The value must be a positive integer.
This Registry has been initially populated by the values in type-
param.  The reference column for all of these entries will be this
document.  The value 0 is to be marked as "Reserved".
This specification establishes the "ACE Groupcomm Key" IANA Registry.
The Registry has been created to use the "Expert Review Required"
registration procedure RFC8126.  Expert review guidelines are
provided in review.
Profile: This field may contain a descriptive string of a profile
to be used with this item.  This should be a value that is in the
Name column of the "ACE Groupcomm Profile" Registry.
Profile: This field may contain one or more descriptive strings of
application profiles to be used with this item.  The values should
be taken from the Name column of the "ACE Groupcomm Profile"
Registry.
This specification establishes the IANA "ACE Groupcomm Profile"
Registry.  The Registry has been created to use the "Expert Review
Required" registration procedure RFC8126.  Expert review guidelines
are provided in review.  It should be noted that, in addition to the
expert review, some portions of the Registry require a specification,
potentially a Standards Track RFC, be supplied as well.
This specification establishes the "ACE Groupcomm Profile" IANA
Registry.  The Registry has been created to use the "Expert Review
Required" registration procedure RFC8126.  Expert review guidelines
are provided in review.  It should be noted that, in addition to the
expert review, some portions of the Registry require a specification,
potentially a Standards Track RFC, be supplied as well.
Name: The name of the profile, to be used as value of the profile
attribute.
Description: Text giving an overview of the profile and the
context it is developed for.
CBOR Value: CBOR abbreviation for this profile name.  Different
ranges of values use different registration policies RFC8126.
Integer values from -256 to 255 are designated as Standards
Action.  Integer values from -65536 to -257 and from 256 to 65535
are designated as Specification Required.  Integer values greater
than 65535 are designated as Expert Review.  Integer values less
than -65536 are marked as Private Use.
Reference: This contains a pointer to the public specification of
the profile abbreviation, if one exists.
Name: The name of the application profile, to be used as value of
the profile attribute.
Description: Text giving an overview of the application profile
and the context it is developed for.
CBOR Value: CBOR abbreviation for the name of this application
profile.  Different ranges of values use different registration
policies RFC8126.  Integer values from -256 to 255 are designated
as Standards Action.  Integer values from -65536 to -257 and from
256 to 65535 are designated as Specification Required.  Integer
values greater than 65535 are designated as Expert Review.
Integer values less than -65536 are marked as Private Use.
Reference: This contains a pointer to the public specification of
the abbreviation for this application profile, if one exists.
This specification establishes the "ACE Groupcomm Policy" IANA
Registry.  The Registry has been created to use the "Expert Review
Required" registration procedure RFC8126.  Expert review guidelines
are provided in review.  It should be noted that, in addition to the
expert review, some portions of the Registry require a specification,
potentially a Standards Track RFC, be supplied as well.
Name: The name of the group communication policy.
CBOR label: The value to be used to identify this group
communication policy.  Key map labels MUST be unique.  The label
can be a positive integer, a negative integer or a string.
Integer values between 0 and 255 and strings of length 1 are
designated as Standards Track Document required.  Integer values
from 256 to 65535 and strings of length 2 are designated as
Specification Required.  Integer values of greater than 65535 and
strings of length greater than 2 are designated as expert review.
Integer values less than -65536 are marked as private use.
CBOR type: the CBOR type used to encode the value of this group
communication policy.
Description: This field contains a brief description for this
group communication policy.
Reference: This field contains a pointer to the public
specification providing the format of the group communication
policy, if one exists.
This registry will be initially populated by the values in fig-ACE-
Groupcomm-Policies.
This specification establishes the "Sequence Number Syncrhonization
Method" IANA Registry.  The Registry has been created to use the
"Expert Review Required" registration procedure RFC8126.  Expert
review guidelines are provided in review.  It should be noted that,
in addition to the expert review, some portions of the Registry
require a specification, potentially a Standards Track RFC, be
supplied as well.
Name: The name of the sequence number synchronization method.
Value: The value to be used to identify this sequence number
synchronization method.
Description: This field contains a brief description for this
sequence number synchronization method.
Reference: This field contains a pointer to the public
specification describing the sequence number synchronization
method.