Hi authors, using the EDHOC profile has shown that there's some temptation to return a token like this:
{
e'scope': b'...',
e'cnf': {
e'COSE_Key/1': {
e'kty': ...
}
}
}
and the draft has not nudged that developer towards what is a practical
requirement, being that there is a KCCS (or any other thing that is a
valid CRED_x) in there:
{
e'scope': b'...',
e'cnf': {
/ maybe a subject claim /
e'kccs/14': {
e'cnf': {
e'COSE_Key/1': {
e'kty/1': 1,
}
}
}
}
}
The "maybe a subject claim" is critical here: If a COSE_Key were used
raw, the recipient would have no way of knowing whether or not a subject
key, let alone with which value, should be in the KCCS that gets used as
EDHOC input.
I have enough overview of the document to suggest a concrete place where
to highlight the practical constraints on the cnf types.
Can you confirm that the 2nd form is what token contents should look
like, and that the 1st form is not directly usable for EDHOC?
BR
c
--
To use raw power is to make yourself infinitely vulnerable to greater powers.
-- Bene Gesserit axiom
signature.asc
Description: PGP signature
_______________________________________________ Ace mailing list -- [email protected] To unsubscribe send an email to [email protected]
