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]
