Draft: draft-ietf-ace-key-groupcomm

Commentary: There are a couple of TODOs but I m good leaving those in for now . 
 I 'm done with it and ready to submit !
Retrieving keying material as a current group member (sec-
expiration and sec-key-retrieval).
Retrieving keying material as a current group member (sec-new-
update-keys and sec-key-retrieval).
'grant_type', with value "client_credentials".
As in I-D.ietf-ace-oauth-authz, these parameters are included in the
payload, which is formatted as a CBOR map.  The Content-Format
"application/ace+cbor" defined in Section 8.14 of I-D.ietf-ace-oauth-
authz is used.
As in I-D.ietf-ace-oauth-authz, these parameters are included in the
payload, which is formatted as a CBOR map.  The Content-Format
"application/ace+cbor" is used.
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).
The payload of the 2.01 response is a CBOR map, which MUST include
the parameter 'rsnonce' defined in Section rsnonce, specifying a
dedicated nonce N_S 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).
The 'pub_key_enc' parameter MUST be present if the POST request
included the 'pub_key_enc' parameter with value Null.  If present,
the 'pub_key_enc' parameter of the 2.01 (Created) response is a CBOR
integer, indicating the encoding of public keys used in the group.
The values of this field are registered in the "ACE Public Key
Encoding" Registry, defined in ssec-iana-pub-key-enc.  It is required
of the application profiles to define specific values to use for this
parameter.
The 'pub_key_enc' parameter MUST be present if the POST request
included the 'pub_key_enc' parameter with value Null.  If present,
the 'pub_key_enc' parameter of the 2.01 (Created) response is a CBOR
integer, indicating the encoding of public keys used in the group.
It is required of the application profiles to define specific values
to use for this parameter.
In this specification and in application profiles building on it,
this parameter is used to ask and retrieve from the KDC information
about the signature algorithm and related parameters used in the
group.
This section defines how the keying material used for group
communication is distributed from the KDC to the Client, when joining
the group as a new member.
If not previously established, the Client and the KDC MUST first
establish a pairwise secure communication channel using ACE.  The
exchange of Key Distribution Request-Response MUST occur over that
secure channel.  The Client and the KDC MAY use that same secure
channel to protect further pairwise communications, that MUST be
secured.
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.
fig-key-distr-join gives an overview of the exchange described above.
The Client wishes to (re-)get the current keying material, for
cases such as expiration, loss or suspected mismatch, due to e.g.
reboot or missed group rekeying.  This is further discussed in
sec-expiration.
The Client wishes to (re-)get the public keys of other group
members, e.g. if it is aware of new nodes joining the group after
itself.  This is further discussed in sec-key-retrieval.
Additionally, the format of the payload of the Key Distribution
Response (ssec-key-distribution-response) can be reused for messages
sent by the KDC to distribute updated group keying material, in case
of a new node joining the group or of a current member leaving the
group.  The key management scheme used to send such messages could
rely on, e.g., multicast in case of a new node joining or unicast in
case of a node leaving the group.
Note that proof-of-possession to bind the access token to the Client
is performed by using the proof-of-possession key bound to the access
token for establishing secure communication between the Client and
the KDC.
If the application requires backward security, the KDC SHALL generate
new group keying material and securely distribute it to all the
current group members, using the message format defined in this
section.  Application profiles may define alternative message
formats.
'type', encoded as a CBOR int, with value 1 ("key distribution").
In this specification and in application profiles building on it,
this parameter is used to ask and retrieve from the KDC information
about the encoding of public keys used in the group.
The 'rsnonce' parameter is an OPTIONAL parameter of the AS Request
Creation Hints message defined in Section 5.1.2. of I-D.ietf-ace-
oauth-authz.  This parameter contains a nonce generated by the RS and
provided to the Client.  Its exact usage is application specific.
This parameter MUST NOT be used as a replacement for the 'cnonce'
parameter defined in Section 5.1.2 of I-D.ietf-ace-oauth-authz.
In this specification and in application profiles building on it,
this parameter is used to provide a nonce that the Client may use to
prove possession of its own private key in the Key Distribution
Request (see ssec-key-distribution-request).
This section defines the operations available at the KDC for a Client
as (candidate) group member, and especially how the keying material
used for group communication is distributed from the KDC to the
Client.
During the first exchange ("joining"), the Client sends a request to
the KDC, 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
other members of the group (see ssec-key-distribution-response).
Whenever used, the Content-Format in messages containing a payload is
set to application/cbor.
The Client can (re-)get the current keying material, for cases
such as expiration, loss or suspected mismatch, due to e.g. reboot
or missed group rekeying.  This is further discussed in sec-new-
update-keys.
The Client can get a new individual key, or new input material to
derive it.  This is further discussed in sec-new-update-keys.
The Client can (re-)get the public keys of other group members,
e.g. if it is aware of new nodes joining the group after itself.
This is further discussed in sec-key-retrieval.
The Client can (re-)get the policies currently enforced in the
group.  This is further discussed in policies.
The Client can (re-)get the version number of the keying material
currently used in the group.  This is further discussed in key-
version.
The Client can request to leave the group.  This is further
discussed in ssec-group-leaving.
Additionally, the format of the payload of the Key Distribution
Response (see ssec-key-distribution-response) can be reused for
messages sent by the KDC to distribute updated keying material to the
group, in case of a new node joining the group or of a current member
leaving the group.  The key management scheme used to send such
messages could rely on, e.g., multicast in case of a new node joining
or unicast in case of a node leaving the group.
Upon receiving a request from a Client, the KDC MUST check that it is
storing a valid access token from that Client for the group
identifier assiciated to the endpoint.  If that is not the case, i.e.
the KDC does not store a valid access token or this is not valid for
that Client for the group identifier at hand, the KDC MUST respond to
the Client with a 4.01 (Unauthorized) error message.
TODO: verify that this section is ok.
The details for the handlers of each resource are given in the
following sections.  These endpoints are used to perform the
operations introduced in key-distr.
No handlers are implemented for this resource.
GET: the GET handler returns the symmetric group keying material
for the group identified by "gid".  The payload of the response is
formatted as a CBOR Map, whose possible elements are "kty", "key",
"profile", "exp" and "mgt_key_material", with CBOR labels defined
in TBD.
POST: the POST handler expects a request with payload formatted as
a CBOR Map, whose possible elements are "scope", "get_pub_keys",
"client_cred", "c_nonce", "client_cred_verify" and
"pub_key_repos", with CBOR labels defined in TBD.  The handler
adds the public key indicated in "client_cred" to the list of
public keys stored for the group identified by "gid".  With
reference to the group identified by "gid", the handler returns,
the symmetric group keying material, the group policies and all
the public keys of the current members of the group, if the KDC
manages those and the Client requested so in the previous request.
The payload of the response is formatted as a CBOR Map, whose
possible elements are "kty", "key", "profile", "exp", "pub_keys",
"group_policies" and "mgt_key_material", with CBOR labels defined
in TBD.
GET: the GET handler returns the list of public keys of all the
current group members, for the group identified by "gid".  The
payload of the response is formatted as a CBOR byte string, which
encodes the list of public keys of all the group members paired
with the respective member identifiers.  If the KDC does not store
any public key associated with the specified member identifiers,
the handler returns a response with payload formatted as a CBOR
byte string of zero length.
POST: the POST handler expects a request with payload formatted as
a CBOR Array.  Each element of the array is the identifier of a
group member.  With reference to the group identified by "gid",
the handler identifies the public keys of the current group
members for which the identifier matches with one of those
indicated in the request.  Then, the handler returns a response
with payload formatted as a CBOR byte string, which encodes the
list of public keys of all the group members paired with the
respective member identifiers.  If the KDC does not store any
public key associated with the specified member identifiers, the
handler returns a response with payload formatted as a CBOR byte
string of zero length.
GET: the GET handler returns the list of policies for the group
identified by "gid".  The payload of the response is formatted as
a CBOR Map, where each pair specifies a particular management
aspect.
The specific format and meaning of group policies MUST be specified
in the application profile (REQ4).
This resource implements a GET handler.
GET: the GET handler returns an integer that represents the epoch
of the symmetric group keying material.  This number is
incremented on the KDC every time the KDC updates the symmetric
group keying material.  The payload of the response is formatted
as a CBOR integer.
GET: the GET handler returns newly-generated individual keying
material for the Client, or information enabling the Client to
derive it.
POST: the POST handler expects a request with empty payload.  The
handler removes the node from the group.
The specific format and content of the payload of the Group Leaving
request is specified by the application profile (REQ5).
The specific format of newly-generated individual keying material for
group members, or of the information to derive it, MUST be specified
in the application profile (REQ6).
fig-key-distr-join gives an overview of the Key Distribution Request/
Response exchange between Client and KDC, when the Client first joins
a group.
If not previously established, the Client and the KDC MUST first
establish a pairwise secure communication channel.  This can be
achieved, for instance, by using a transport profile of ACE.  The
exchange of Key Distribution Request-Response MUST occur over that
secure channel.  The Client and the KDC MAY use that same secure
channel to protect further pairwise communications that must be
secured.  The secure communication protocol is REQUIRED to establish
the secure channel by using the proof-of-possession key bound to the
access token.
As a result, the proof-of-possession to bind the access token to the
Client is performed by using the proof-of-possession key bound to the
access token for establishing secure communication between the Client
and the KDC.
If the application requires backward security, the KDC MUST generate
new group keying material and securely distribute it to all the
current group members, upon a new node's joining the group.  To this
end, the KDC uses the message format of the Key Distribution Response
(see ssec-key-distribution-response).  Application profiles may
define alternative message formats.
'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.
'cnonce', as defined in Section 5.1.2 of I-D.ietf-ace-oauth-authz,
and including a dedicated nonce N_C generated by the Client.  This
parameter MUST be present if the 'client_cred' parameter is
present.
'client_cred_verify', encoded as a CBOR byte string.  This
parameter MUST be present if the 'client_cred' parameter is
present.  This parameter contains a signature computed by the
Client over N_S concatenated with N_C, where N_S is the nonce
received from the KDC in the 'rsnonce' parameter of the 2.01
(Created) response to the token POST request (see token-post),
while N_C is the nonce generated by the Client and specified in
the 'cnonce' parameter above.  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.
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.
The KDC verifies that the group identifier of the /ace-group/gid
endpoint 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.
unknown fields present), the KDC MUST respond with 4.00 (Bad Request)
error message.
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.
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 defined
in iana-key, including its name, type and application profile to be
used with.
This section describes at a high level how a node can be removed from
the group.
If the application requires forward security, the KDC SHALL generate
new group keying material and securely distribute it to all the
current group members but the leaving node, using the message format
defined in ssec-key-distribution-response.  Application profiles may
define alternative message formats.
A node can actively request to leave the group.  In this case, the
Client can send a request formatted as follows to the KDC, to abandon
the group.  The client MUST use the protected channel established
with ACE, mentioned in key-distr.
'type', encoded as a CBOR int, with value 2 ("leave").
'scope', with value the specific resource that the Client is
authorized to access (i.e. group or topic identifier) and wants to
leave, encoded as in ssec-authorization-request.  The 'role' field
is omitted.
Note that the 'role' field is omitted since such a request should
only be used to leave a group altogether.  If the leaving node wants
to be part of a group with fewer roles, it does not need to
communicate that to the KDC, and can simply stop acting according to
such roles.
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.  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 one triggers
the KDC to produce new keying material for that node, while the
second one 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.
A node stops using the group keying material upon its expiration,
according to what indicated by the KDC with the 'exp' parameter of a
Key (Re-)Distribution Response, or to a pre-configured value.  Then,
if it wants to continue participating in the group communication, the
node has to request new updated keying material from the KDC.
The Client may need to request the latest group keying material 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.  To this end, the client performs a Key Re-Distribution
Request/Response exchange with the KDC, as defined in ssec-key-
redistribution-request and ssec-key-redistribution-response.
Note that policies can be set up so that the Client sends a Key Re-
Distribution 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 Key Re-Distribution Request could also be sent by the Client
without being triggered by a failed decryption of a message, if the
Client wants to be sure 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 already has in memory.
fig-key-redistr-req-resp gives an overview of the exchange described
above.
Beside possible expiration and depending on what part of the keying
material is no longer eligible to be used, 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.  To this end, the client performs a Key Renewal Request/
Response exchange with the KDC, as defined in ssec-key-renewal-
request and ssec-key-renewal-response.
fig-renewal-req-resp gives an overview of the exchange described
above.
Note that the difference between the Key Re-Distribution Request and
the Key Renewal Request is that the first one only triggers
distribution (the renewal might have happened independently, because
of expiration), while the second one triggers the KDC to produce new
keying material for the requesting node.  Once a node receives new
individual keying material, other group members may need to use the
Keying Material Update Request to retrieve it.
Can send unicast requests to each Client over a secure channel,
with the Key Re-Distribution Response as payload.
Can send unicast requests to each Client over a secure channel,
with the same payload as the Key Re-Distribution Response.
'type', encoded as a CBOR int, with value 3 ("update key") if the
request is intended to retrieve updated group keying material, and
4 ("new") if the request is intended for the KDC to produce and
provide new individual keying material for the Client.
The KDC receiving a Key Re-Distribution Request MUST check that it is
storing a valid access token from that client for that scope.
If that is not the case, i.e. it does not store the token or the
token is not valid for that client for the scope requested, the KDC
MUST respond with a 4.01 (Unauthorized) error message.  Analogously
to ssec-key-distribution-response, if the Key Re-Distribution 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 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.
To request a re-distribution of keying material, the Client sends a
CoAP GET request to the /ace-group/gid endpoint at the KDC.
The KDC replies to the Client with a Key Re-Distribution Response,
whose payload is a CBOR map which MUST include the parameters 'kty'
and 'key' specified in ssec-key-distribution-response.  The payload
of the Key Re-Distribution Response MAY also include the parameters
'profile', 'exp' and 'mgt_key_material' parameters specified in ssec-
key-distribution-response.
To request the renewal of individual keying material used in the
group, the Client sends a CoAP GET request to the /ace-group/gid/node
endpoint at the KDC, where gid is the group identifier.
The KDC replies to the Client with a Key Renewal Response, whose
payload is a CBOR byte string encoding newly-generated individual
keying material for the Client, or information enabling the Client to
derive it.
fig-public-key-req-resp gives an overview of the exchange described
above.
Note that these messages can be combined with the Key Re-Distribution
messages in sec-expiration, to request at the same time the keying
material and the public keys.  In this case, either a new endpoint at
the KDC may be used, or additional information needs to be sent in
the request payload, to distinguish these combined messages from the
Public Key messages described below, since they would be identical
otherwise.
'type', encoded as a CBOR int, with value 5 ("pub keys").
N elements, each of which is the identifier of a group member
encoded as a CBOR byte string, in order to request the public
key of the specified nodes.
the public keys of the group members with the identifiers
specified in the 'get_pub_keys' parameter of the Public Key
request.
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.
fig-public-key-req-resp gives an overview of the exchange described
above, with the Client using the GET method.
To request the public keys of all the current group members, the
Client sends a CoAP GET request to the /ace-group/gid/pub-key
endpoint at the KDC, where gid is the group identifier.
'get_pub_keys', which has as value a CBOR array.  Each element of
the array is the identifier of a group member, so requesting the
public key of that group member.  The specific format of public
keys as well as identifiers of group members is specified by the
application profile.
If the Public Key Request is a POST request and the 'get_pub_keys'
parameter is an empty CBOR Array, the KDC MUST treat the request as
malformed and respond with a 4.00 (Bad Request) error message.
Otherwise, the KDC replies to the Client with a Public Key Response,
whose paylaod is a CBOR map including only the parameter 'pub_keys'
defined for the Key Distribution Response in ssec-key-distribution-
response.
In particular, 'pub_keys' contains the public keys either of all the
group members (if the Public Key Request was a GET request), or only
those associated to the group members indicated by the Client with
the 'get_pub_keys' parameter (if the Public Key Request was a POST
request).  The specific format of public keys as well as identifiers
of group members is specified by the application profile.
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 POST request but are not associated to
any current group member.
This specification defines a number of types of requests.  The table
below summarizes them.
When a Client receives a message from a sender for the first time, it
needs to have a mechanism in place to avoid replay, e.g.
Appendix B.2 of I-D.ietf-core-object-security.
A node in the group can contact the KDC to retrieve the current group
policies, by using the messages defined below.  How the policies are
set up at the KDC is out of the scope of this specification.
fig-policies gives an overview of the exchange described above.
To request the current group policies, the Client sends a CoAP GET
request to the /ace-group/gid/policies endpoint at the KDC, where gid
is the group identifier.
The KDC replies to the Client with a Policies Response, whose payload
is a CBOR Map including only the parameter 'group_policies' defined
for the Key Distribution Response in ssec-key-distribution-response
and specifying the current policies in the group.  The specific
format and meaning of policies is specified by the application
profile.
A node in the group can contact the KDC to request information about
the version number of the symmetric group keying material.  In
particular, the version is incremented by the KDC every time the
group keying material is renewed.  The initial version MUST be set to
0 at the KDC.
fig-version gives an overview of the exchange described above.
To request the keying material version number, the Client sends a
CoAP GET request to the /ace-group/gid/ctx-num endpoint at the KDC,
where gid is the group identifier.
The KDC replies to the Client with a Version Response, whose payload
payload contains the group keying material version number, encoded as
a CBOR integer.
A node can actively request to leave the group.  In this case, the
Client MUST send a CoAP POST request to the endpoint /ace-group/gid/
node at the KDC (where gid is the group identifier) using the
protected channel established with ACE, mentioned in key-distr.  The
specific format and content of the payload of the Group Leaving
request is specified by the application profile.
If the Leave Request is such that the KDC cannot extract all the
necessary information to understand and process it correctly (e.g.
unrecognized endpoint), 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.
Alternatively, a node may be removed by the KDC, without having
explicitly asked for it.  This is further discussed in sec-node-
removal.
This section describes the different scenarios according to which a
node ends up being removed from the group.
If the application requires forward security, the KDC MUST generate
new group keying material and securely distribute it to all the
current group members but the leaving node, using the message format
of the Key Distribution Response (see ssec-key-distribution-
response).  Application profiles may define alternative message
formats.
A node may be evicted from the group in the following cases.
The node explicitly asks to leave the group, as defined in ssec-
group-leaving.
The node has been found compromised or is suspected so.
When a Client receives a message from a sender for the first time, it
needs to have a mechanism in place to avoid replay, e.g.
Appendix B.2 of RFC8613.
This specification establishes the "ACE Public Key Encoding" 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.
Value: The value to be used to identify this public key encoding.
This value MUST be unique.  The value can be a positive or a
negative integer.  Integer values between 0 and 255 are designated
as Standards Track Document required.  Integer values from 256 to
65535 are designated as Specification Required.  Integer values of
greater than 65535 are designated as expert review.  Integer
values less than -65536 are marked as private use.
Description: This field contains a brief description for this
public key encoding.
Reference: This field contains a pointer to the public
specification providing the public key encoding, if one exists.
The value 0 is to be marked as "Reserved".
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.
Reference: This contains a pointer to the public specification for
the format of the item, if one exists.
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 Registry has been initially populated by the values in params.
The Reference column for all of these entries refers to sections of
this document .