Hi Brendan,
please find my comments inline. > The thumbprint for symmetric key is useful for two scenarios in constrained > nodes: > It allows us to verify that the correct key is present on a device in order > to verify a COSE_MAC0 or COSE_MAC. This is important because rotation of > symmetric keys could cause multiple keys to exist with the same identifier. > This allows more granular detection of the source of an authentication > failure. [Hannes] I think you are referring to the same use case as Ken. It might make sense to talk about the importance of key naming in the SUIT firmware encryption draft. I think it is worthwhile to discuss the topic of symmetric key identification (for key roll-over and for identification of the key in general) in the draft. I am not convinced that the hash of the symmetric key is the solution nor that we should mandate a specific approach because this is largely deployment dependent. > It allows us to verify that a decryption key is correct before performing > decryption. This is important in a streaming decryption scenario where the > result of decryption will be directly written to NVM, where retry costs are > high. It is better to detect a key anomaly early. In short, I believe it > could be used for the key check value that we originally had in the > suit-firmware-encryption draft. [Hannes] This “cek-verification” functionality was a feature in an earlier version of the SUIT firmware encryption draft, which we removed due to the changed design. For those who do not have the context, here is the text: https://datatracker.ietf.org/doc/html/draft-ietf-suit-firmware-encryption-12#name-cek-verification Ciao Hannes
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
