Thank you Lucas and Ilari both for your reviews! I have now adjusted the editor's copy <https://yubicolabs.github.io/cose-two-party-signing-algs-rfc/draft-lundberg-cose-two-party-signing-algs.html> to address your comments:
- Clarified in section "2. Split Signing Algorithms" that non-"-split" alg IDs defined here may be exposed to verifiers, and that transport of the digest is out of scope but expected to take the place of the "data to be signed" input. - Added section "4.3. Incorrect Use of Split Signing Algorithm Identifiers" with guidance on what verifiers should do if they encounter split alg IDs. - Added section "5.1. Using Non-Split Signing Algorithm Identifiers in a Split Signing Protocol" with guidance on what signers should do if non-split alg IDs are used in a split signing protocol. - Added section "2.3. Defining Split Signing Algorithms" expanding on the statements in section "2. Split Signing Algorithms" about handling of domain separation tags. Does this adequately address your comments? Emil Lundberg Staff Engineer | Yubico <http://www.yubico.com/> Den ons 17 dec. 2025 kl 15:22 skrev Ilari Liusvaara < [email protected]>: > On Wed, Dec 17, 2025 at 12:25:39PM +0000, Lucas Prabel wrote: > > Hello, > > > > I volunteered during IETF 124 to review > draft-lundberg-cose-two-party-signing-algs-04 > > (draft-lundberg-cose-two-party-signing-algs-04 - Split signing > > algorithms for COSE > > < > https://datatracker.ietf.org/doc/draft-lundberg-cose-two-party-signing-algs/04/ > >). > > > > Section 2 > > > > - I think I would've appreciated some words on how the digest is > > supposed to be transmitted from digester to signer, either by saying > > it is out of scope for this specification or if the draft intends to > > provide guidance on how the digest should be transported. > > I presume the thing would be transported in a new structure. Which might > or might not have some sort of compatibleness with an existing > structure. > > The COSE_Sign_Args seems to be missing slot for hash, which should not > be a parameter as it is always-required thing. Depending on the > compatibility requirements, it might make sense to also make alg be > a field and not a parameter. > > For exact parameters used, my understanding is that those are too > application-specific to specify exactly. E.g., ARKG versus classical > key. > > Might make sense to have some sort of parameter to transmit public > key hash for classical keys. > > If there are no compatibility requirements, one could use something > like the following (competely unchecked syntax): > > COSE_Sign_Split = [ > alg: int/tstr, > hash: bstr, > params: { > * label => values > } > ] > > > > - You write: "For signing algorithms that format the message to insert > > domain separation tags, [...] this message formatting is also > > performed by the signer." But if a piece of contextual data (like a > > domain separation tag, a randomizer, ...) must be incorporated into > > the message digest calculation, the digester must be the party > > responsible for handling and including this data before generating > > the digest. > > The algorithms actually differ here. Some (e.g., Ed25519ph/Ed448ph) > have context inserted by signer, and some (e.g., ML-DSA signmu) have > context inserted by digester. > > However, none of those algorithms actually uses context in COSE. > > The ML-DSA signmu requires digester to know the public key hash tho. > > I do not offhand recall any signatures that have built-in randomizers. > > > > Section 4 > > - It might be useful to add a sentence to the Security Considerations > > regarding what a verifier should do if they do encounter some split > > signing algorithm identifiers in a final COSE structure? > > I think the verifier needs to treat it as either unknown or invalid > algorithm (like A256KW). > > (Any invalid algorithm causes the entire message to be instantly > rejected as malformed, while unknown algorithms permit fallback to > others if available.) > > The algorithms are special-purpose, so should be flagged as Prohibited > in the registry. > > And presumably the algorithm identifers are not size-sensitive, so > should be allocated from Expert Review range. > > > > - Similarly, what should the signer do if it receives a non-split alg > > identifier (for example Ed25519ph instead of Ed25519ph-split?) in > > the internal protocol? > > It should be treated as unsupported (as it is not valid algorithm in > context it appears in). > > > > > -Ilari > > _______________________________________________ > COSE mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
