Open bwesterb opened 1 month ago
I did some explorative coding on using nontrivial context for TLS 1.3 signatures (which have further contextualization of their own) and discovered that version-specific or even TLS specific context would cause issues with delegated credentials (and other similar things). So context should be assigned to the construct as whole, not to its use in TLS 1.3 or even to its use in TLS (the further contextualization will separate those if needed).
:-1: from me for using non-empty context string
I don't think it's necessary, the "message" signed already makes it plainly obvious that we're signing TLS 1.3 handshake hash, and the libraries will need to support context string for the hybrid schemes, so requiring its use for TLS won't change much and may just delay deployability of this draft
There is an argument to be made to set the context string to a fixed constant like "TLS1.3" to nudge cryptographic libraries to support context parameters more widely.