Hi Emil, Mike, - In its current form, I don't support this idea for two related reasons:
- You say "Consumers of the cryptographic data structures thus cooperatively produced do not use these algorithm identifiers; " - but I think people will likely ignore this sentence and the algorithm identifiers will "leak" into consumers, i.e. verifiers. And then this would lead to added complexity on the consumer side, and potentially security issues.
- You are basically standardizing an internal interface within the COSE signature generator. Formally, I don’t think this is in scope for the COSE working group. And practically, how do we ensure that people actually need this proposal and are going to implement it? Should it be defined in conjunction with other protocols on the same interface (e.g. PKCS#11, KMIP)?
- How do you ensure that these values are not leaked to consumers? One option is to use the (currently unused) Capability field in the IANA registration, see Sec. 8 of RFC9053. Or maybe have a value other than Yes for "Recommended". If you look at lANA registry, Recommended apparently can be Yes or No, but other values are also used.
- Terminology: I think everybody agrees that "two party" is not a good name. Let me suggest "decoupled signatures".
- Editorial nit: apparently the toolchain you're using does not support "_italics_" and these underscores appear verbatim in the text version of the draft.
Thanks, Yaron |
_______________________________________________
COSE mailing list -- [email protected]
To unsubscribe send an email to [email protected]
