Draft: draft-ietf-core-object-security

Commentary: as suggested in 
 I do not understand what " kid context " mean , and the new text is does not align with how 6tisch is using the context hint . This parameter is used to find the correct context , not just kid or key . I do n't this think can be commited as is . 
 My intention with " kid context " was that it was a context to search for a kid in . I would be willing to use a different term , but am not sure what is better . As far as I am concerned " Group ID " would be fine even when not used as an actual group but I wanted to stay closer to what was there originally . 
 I am fine with " kid context " , with you explanation that maps well to how multicast OSCORE uses the parameter . 6tisch uses the parameter in a different way . In 6tisch , the client uses the parameter to send the EUI-64 and the server uses that as Master Salt . 
 As I understand the relation between the OSCORE message and COSE , I think that the Context Hint should get an assigned COSE parameter name in the " COSE Header Parameters " registry . All other data that goes into or comes from the serialization passes through a COSE_Encrypt0 message , and I do n't see why the Context Hint should be an exception . Cc'ing who should have an expert opinion on this :-) 
 I would agree to that . My first assumption was that it was the same thing as the group identifier but that may not be correct . 
  hint can be used a group identifier in the multicast setting , this is done so in Group OSCORE . In 6tisch Minimal security Context hint is used to transport EUI-64 , which is the identifier used to find the pre - shared secret . Yes , it is a correct remark that it probably should be defined for the uncompressed COSE . 
 If there 's a fitting header that already exists in COSE ( like the group identifier ) , that 's fine with me too . 
 We did n't find a suitable header , and , as mentioned , it is more generic than group identifier . So we should probably request a new entry in the " COSE Header Parameters " registry . Any objections to " Context Hint " ? 
 The use you are positing for 6tish seems to be more of a kid type usage , are you expecting to have both a kid and a EUI-64 identifier in the same message ? There is not currently a context hint , I would want to see a tighter definition on what it would be , but as I am not one of the Experts on that registry that is only a personal and not an expert opinion . 
 Previously 6tisch used EUI-64 concatenated with 0x00 or 0x01 as kid , in the latest version kid is just 0x00 or 0x01 . As I see it , in both group OSCORE and 6tisch this parameter is used as an extension to kid - as a means to find the kid in the relevant context ; hence the term context hint . In these cases it need neither be unique ( one reason for not calling it context identifier ) nor be included in the external_aad . I believe there is a commonality here . In other use cases there may be other data serving the same purpose .
Paragraph (version A):
To enable retrieval of the right Recipient Context, the Recipient ID
SHOULD be unique in the sets of all Recipient Contexts used by an
endpoint.  The Client MAY provide a Context Hint context-hint to help
the Server find the right context.
Paragraph (version B):
To enable retrieval of the right Recipient Context, the Recipient ID
SHOULD be unique in the sets of all Recipient Contexts used by an
endpoint.  The Client MAY provide a "kid context" parameter context-
hint to help the Server find the right context.
Paragraph (version B):
Optionally, a "kid context" parameter as defined in context-
hint.  This parameter MAY be present in requests and SHALL NOT
be present in responses.
Paragraph (version B):
For certain use cases, e.g. deployments where the same "kid" is used
with multiple contexts, it is necessary or favorable for the sender
to provide an additional identifier of the security material to use,
in order for the receiver to retrieve or establish the correct key.
The "kid context" parameter is used to provide such additional input.
The "kid context" is implicitly integrity protected, as manipulation
that leads to the wrong key (or no key) being retrieved which results
in an error, as described in ver-req.
Paragraph (version B):
A summary of the COSE header parameter "kid context" defined above
can be found in tab-1.
Paragraph (version B):
If the client has an identifier in some other namespace which can
be used by the server to retrieve or establish the security
context, then that identifier can be used as kid context.
Paragraph (version B):
In case of a group communication scenario I-D.tiloca-core-
multicast-oscoap, if the server belongs to multiple groups, then a
group identifier can be used as kid context to enable the server
to find the right security context.
Paragraph (version A):
The fifth least significant bit is the Context Hint flag, h: it
is set to 1 if the compressed COSE object contains a Context
Hint, see context-hint.
Paragraph (version B):
The fifth least significant bit is the kid context flag, h: it
is set to 1 if the compressed COSE object contains a kid
context, see context-hint.
Paragraph (version A):
The following 1 byte encode the length of the Context Hint
(context-hint) s, if the Context Hint flag is set (h = 1).
Paragraph (version A):
The following s bytes encode the Context Hint, if the Context Hint
flag is set (h = 1).
Paragraph (version B):
The following 1 byte encode the length of the kid context
(context-hint) s, if the kid context flag is set (h = 1).
Paragraph (version B):
The following s bytes encode the kid context, if the kid context
flag is set (h = 1).
Paragraph (version A):
For certain use cases, e.g. deployments where the same Recipient ID
is used with multiple contexts, it is necessary or favorable for the
client to provide a Context Hint in order for the server to retrieve
the Recipient Context.  The Context Hint is implicitly integrity
protected, as manipulation leads to the wrong or no context being
retrieved resulting in a verification error, as described in ver-req.
This parameter MAY be present in requests and SHALL NOT be present in
responses.
Paragraph (version A):
If the client has an identifier in some other namespace which can
be used by the server to retrieve or establish the security
context, then that identifier can be used as Context Hint.
Paragraph (version A):
In case of a group communication scenario I-D.tiloca-core-
multicast-oscoap, if the server belongs to multiple groups, then a
group identifier can be used as Context Hint to enable the server
to find the right security context.