Hi Christian,Yes, the second form is a correct example while the first form is not compatible with EDHOC, which does not admit "naked" COSE Keys as authentication credentials.
In general, the CWT confirmation method (i.e., the 'cnf' type) has to be consistent with an authentication credential type admitted in EDHOC.
If you already have in mind good clarifying text to propose for a particular section of the document, please do so :-)
Thanks, /Marco On 2024-12-12 11:45, Christian Amsüss wrote:
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
-- Marco Tiloca Ph.D., Senior Researcher Phone: +46 (0)70 60 46 501 RISE Research Institutes of Sweden AB Box 1263 164 29 Kista (Sweden) Division: Digital Systems Department: Computer Science Unit: Cybersecurity https://www.ri.se
OpenPGP_0xEE2664B40E58DA43.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ Ace mailing list -- ace@ietf.org To unsubscribe send an email to ace-le...@ietf.org
