Thank you Falko and Ilari, and apologies for taking so long to reply. My first comment is on the novelty or relevance of the contents. [...] Such > a splitting of these operations in an implementation is neither new nor > does it necessarily require an explicit specification. [...]
Indeed, these ideas are not new. I did not think the abstract and introduction presented them as such, using words like "defines" rather than "introduces", but perhaps we need to do more. Would it help to change, for example "This can be useful when communication with the party holding the signing private key [...]" to something like "This is common in protocols where the party holding the signing private key [...]", and perhaps mention OpenPGP, PIV and/or PKCS#11 as applicable (I don't know by heart which of these apply this technique)? [...] Otherwise such a separation seems to be an implementation detail that > typically has no relevance for interoperability. > Only later in the document it becomes apparent that also interoperability > is addressed: COSE Signing Arguments are introduced for the communication > between the digester and the signer. [...] Typically, the interface between > the digester and the signer would be given by an existing cryptographic > interface definition such as the PKCS#11 API. Currently, I understand that > the whole justification of the draft is the declaration of these new COSE > specifications. Indeed, the point of the proposal is to enable using COSE algorithm identifiers in cryptographic interface definitions: specifically this proposed WebAuthn "sign" extension: https://github.com/w3c/webauthn/pull/2078. Since WebAuthn already uses COSE algorithm identifiers for algorithm negotiation between RP (server/JavaScript) and authenticator (security key/OS keyring), it would be most natural to use COSE algorithm identifiers in this extension too. But since this extension is meant for signing arbitrary data, unlike normal WebAuthn signatures which are over relatively short transaction data, we want to open up for the possibility to sign large objects without having to transfer the entire object to the security key. Another motivation we haven't mentioned in the draft is one specific to ECDSA: to enable tricks like Split-ECDSA (https://eprint.iacr.org/2021/910). This is an ECDSA key blinding technique, which requires multiplying the message hash with a "blinding factor" before proceeding with the signature. The technique is very similar to "external mu" for ML-DSA, and cannot be done if the *signer* performs the hash internally, unless one introduces a separate algorithm identifier with additional algorithm inputs. ...but our specific use case for Split-ECDSA isn't relevant anymore, so I won't actually maintain that motivation. The remaining motivation is just the practicality of transmitting the entire message when application-level pre-hashing is not an option (see below). In any case, the abstract and the introduction should mention this purpose > as the central novelty introduced by the draft. Thank you, I agree. Security-wise, I would like to point out that it is necessary that with the > introduction of the split signing algorithms no ambiguity is created as to > whether a specific signature algorithm is applied to the message directly > or the message digest. If that was the case, then an attacker could > potentially exchange the directly signed message with a hash of the message > without invalidating the signature. The entire point of this is to *keep* that ambiguity, though, and intentionally *not* invalidate the signature: we want to generate, for example, ESP256 signatures that can be successfully verified by an existing ESP256 verifier that is not (and indeed should not be) aware of ESP256-split. As you mentioned in your first paragraph: [...] Otherwise such a separation seems to be an implementation detail that > typically has no relevance for interoperability. and that is the goal here: from the verifier's perspective, the path from message to signature is all implementation detail. The separation here is all inside that block of implementation detail: how the signer goes about constructing the signature. It is *already* true, even before defining ESP256-split, that any ESP256 signature could have been generated by a single party performing the whole procedure from hashing the message to computing the signature values with the private key, or the same signature could have been generated by two cooperating parties, like an OpenPGP client that hashed the message and an OpenPGP smart card that computed the signature on the hash (see page 63 of https://www.gnupg.org/ftp/specs/OpenPGP-smart-card-application-3.4.pdf). The only way to know either way is, as you also mentioned earlier, via some form of certification delivered alongside the signature (for example if the private key is attested to be held in a hardware component that is known to always compute the hash internally). Could you please clarify what you mean by "attacker" in this scenario? It would indeed be a bad idea to use these split algorithms with an untrusted *digester*, but our use cases consider both *digester* and *signer* as trusted (being a decomposition of the overall "signer" role as seen from the verifier's perspective). Perhaps we need to point that out more explicitly in the draft. With respect to PureEdDSA, [...] I think the draft already describes what you are suggesting we change it to. The signature produced by Ed25519ph-split, for example, is a HashEdDSA signature that can be verified by the Ed25519ph verification procedure but would fail the Ed25519 verification procedure. The fact that "The signer executes the PureEdDSA signing procedure" is an implementation detail of HashEdDSA that is exposed in the split between *digester* and *signer* - the overall result is still that the message is first hashed (by the *digester*) and then signed using PureEdDSA (by the *signer*), just as specified for Ed25519ph, while Ed25519 applies PureEdDSA directly to the input without hashing it first. Note that Section 3.3 from RFC 8032 that is quoted in the draft is > misleading as it omits the domain separation of the concrete instantiations > of Ed25519<…>. I definitely want to address what's misleading, but I don't understand what you mean is. Could you please elaborate? So, as I summary, I suggest: > > - Check if the draft is needed at all, which in my view depends on > whether the COSE structures for the interface between the digester and > signer are needed for interoperability between these two entities. > > I think it is, motivated by the WebAuthn "sign" extension proposal mentioned above. Without these algorithm identifiers, the WebAuthn authenticator (security key) would have to assume both the *digester* and *signer* roles, and the entire message to be signed must be transmitted to the authenticator. With these identifiers, the JavaScript application invoking the WebAuthn API can assume the *digester* role when needed, for example if the data to be signed is large and it is not feasible to pre-hash it on the application level (for instance to interoperate with existing verifiers that expect the signed data to not be pre-hashed). > > - Introduce Ed25519ph and Ed448ph properly, i.e., according to the > definitions in RFC 8032. Specifically, there should be no redundant > definition of the algorithms in the draft but they should be referenced in > RFC 8032. > > > - Make sure that > > > - Ed25519 and Ed448 are only used to sign messages directly and > > > - Ed25519ph and Ed448ph are used when pre-hashing of the message is > performed. > > > - Use only the variants Ed25519ph and Ed448ph in the split signing > algorithms, not the variants without the appendix “ph”. > > I believe we already do all of this, by the nature of EdDSA: PureEdDSA requires knowledge of the private key, so Ed25519 and Ed448 cannot be split between *digester* and *signer*, but Ed25519ph and Ed448ph can. But indeed the references for Ed25519ph and Ed448ph are speculative since those definitions don't currently exist. Ilari: Furthermore, I think the approach presented in the draft is not a good > one to solve the underlying issue (dealing with large payloads). I think much better approach would be to hash the payload (perhaps with > salting) before signing. I would agree, but the signer doesn't always have that choice. We want to enable the WebAuthn "sign" extension to be a general-purpose signing operation, a drop-in replacement that can interoperate with as many existing cryptographic protocols and applications as possible, so we cannot assume that those support pre-hashed signatures. Thank you Falko and Ilari both for your reviews and comments! I will update the draft (editor's copy for now) to: - Emphasize that splitting algorithms like this is not novel, rather the novelty is that there is a use case for COSE algorithm identifiers for split algorithms. - Clarify that both *digester* and *signer* need to be trusted roles. I hope my responses above address your other comments. Please let me know if not, or if you have additional concerns. Cheers! Emil Lundberg Staff Engineer | Yubico <http://www.yubico.com/> Den tis 29 juli 2025 kl 16:51 skrev Ilari Liusvaara < [email protected]>: > On Tue, Jul 29, 2025 at 02:07:04PM +0200, Falko Strenzke wrote: > > I made a review of draft-lundberg-cose-two-party-signing-algs-02 < > https://www.ietf.org/archive/id/draft-lundberg-cose-two-party-signing-algs-02.html > > > > > > My first comment is on the novelty or relevance of the contents. In the > > abstract, the text says that the document introduces “split signing > > algorithms”. This term is meant to refer to splitting the hashing of the > > message, resulting in the message digest, and the signature operation > > performed on the message digest among two so called “entities”, the > digester > > and the signer. Such a splitting of these operations in an > implementation is > > neither new nor does it necessarily require an explicit specification. > > Rather, whether of not the hashing and signature operation can be > conducted > > in separate cryptographic modules would be addressed by a possible > > certification scheme that an implementation has to adhere to. Otherwise > such > > a separation seems to be an implementation detail that typically has no > > relevance for interoperability. > > Furthermore, I think the approach presented in the draft is not a good > one to solve the underlying issue (dealing with large payloads). > > I think much better approach would be to hash the payload (perhaps with > salting) before signing. Note that this is subtly different from what > hash-envelope does (which is to replace the payload with hash of it). > > > > Security-wise, I would like to point out that it is necessary that with > the > > introduction of the split signing algorithms no ambiguity is created as > to > > whether a specific signature algorithm is applied to the message > directly or > > the message digest. If that was the case, then an attacker could > potentially > > exchange the directly signed message with a hash of the message without > > invalidating the signature. > > > > With respect to PureEdDSA, it is not clear to me whether or not such a > > problem is introduced by the draft. Specifically it says: > > > > “The signer executes the PureEdDSA signing procedure, where the value > > denoted M in the PureEdDSA signing procedure takes the value denoted > PH(M) > > in the EdDSA signing procedure.” > > > > The newly defined COSE algorithm identifier Ed25519ph (where Ed25519ph > would > > still have to be registered (?) together with Ed25519ph-split) defined in > > this draft would conflict in this sense with EdDSA as it is already > defined > > in COSE: Both these algorithm IDs internally use PureEdDSA, and thus the > > said ambiguity would arise. > > > > This problem was solved if COSE signatures would include the signature > > algorithm ID as meta data. But I can’t read that such a field exists in > > COSE. > > If the signature algorithm ID is included at all (instead of left > implicit), then it is included in metadata (since alg MUST be protected > if possible, and it is always possible with signatures). > > However, that does not protect against mechanisms that bypass COSE > entirely. > > > > > -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]
