Hi Scott! Thank you for your review, and apologies for taking so long to reply.
> > - I see that, in section 2.1, you asked for COSE identifiers for > "ESP256-Split, ESP384-Split, ESP512-Split". However, these signing > algorithms are fully compatible with the standard algorithm, and so > splitting up the algorithm is essentially an implementation detail - why > would the COSE protocol care about that? Shouldn't they use the standard > algorithm identifiers, because the verifier will perform exactly the same > operations? > > I covered this in my reply to Falko's and Ilari's comments <https://mailarchive.ietf.org/arch/msg/cose/dcKllFw3s_wxzeh5tlI7UiP87_g/>, but I'll re-summarize. Indeed these identifiers are irrelevant to verifiers and should not be used to tag signature objects. Rather, they are relevant for using COSE algorithm identifiers for algorithm negotiation in a signature generation protocol - our motivating use case is this proposed WebAuthn "sign" extension: https://github.com/w3c/webauthn/pull/2078. Since WebAuthn already uses COSE algorithm identifiers for algorithm negotiation, it would be most natural to use COSE algorithm identifiers in this extension too. Here it would be useful if the application invoking WebAuthn could negotiate with the authenticator (for example an USB or NFC security key) whether the hashing is done by the application or the authenticator, for example to avoid having to transmit the entire message to be signed if the message is large. > - Oh and a minor nit (which also applies to > draft-ietf-jose-fully-specified-algorithm): shouldn't it be ESP521? > Doesn't the number refer to the curve, rather than the hash function used? > > No, the "512" in ES512 [RFC 9053 <https://www.rfc-editor.org/rfc/rfc9053.html#name-ecdsa>], ESP512 etc. refers to the hash function. > - I feel that this document should talk about postquantum algorithms; > at least ML-DSA, because there's a cose draft for it. Of course, what you > suggest may change (to keep in sync with other working groups), but (IMHO) > it ought to be addressed: > > We did in draft -01. :) More as a case study for what this could look like for ML-DSA than for any concrete use case: https://www.ietf.org/archive/id/draft-lundberg-cose-two-party-signing-algs-01.html#name-hashml-dsa The main reason we dropped this was that it seemed still under debate whether HashML-DSA or "external-mu" was going to be the preferred option, and we didn't want to distract from the main topic of the draft which is orthogonal to that discussion and would work equally well with either option (or both!) (but not with "pure", non-"external-mu" ML-DSA). But I'm happy to re-introduce ML-DSA (hash, external-mu, or both) if people want it. > > - For SLH-DSA (and FN-DSA), the "external mu" interface won't be > available (such an interface could be used by a malicious hasher to > collect > enough information to generate a large number of forgeries - far more > than > the number of hashes submitted to the signer), and so prehashing would > be > your only option. On the other hand, you might not want to address > those > algorithms, or at least, not until the nonsplit drafts have been > submitted. > > Yeah, I don't have a concrete use case for them (nor for ML-DSA at the moment, to be honest) so I'm happy to wait with these. Thank you for your review and comments! I do not see any concrete action points at the moment, except potentially this one: - Potentially re-introduce ML-DSA? Investigate whether HashML-DSA or "external-mu" is preferred by other working groups. Cheers! Emil Lundberg Staff Engineer | Yubico <http://www.yubico.com/> Den tors 31 juli 2025 kl 17:07 skrev Scott Fluhrer (sfluhrer) <sfluhrer= [email protected]>: > I've reviewed the draft, and have these comments: > > > - I see that, in section 2.1, you asked for COSE identifiers for > "ESP256-Split, ESP384-Split, ESP512-Split". However, these signing > algorithms are fully compatible with the standard algorithm, and so > splitting up the algorithm is essentially an implementation detail - why > would the COSE protocol care about that? Shouldn't they use the standard > algorithm identifiers, because the verifier will perform exactly the same > operations? > - Oh and a minor nit (which also applies to > draft-ietf-jose-fully-specified-algorithm): shouldn't it be ESP521? > Doesn't the number refer to the curve, rather than the hash function used? > - I feel that this document should talk about postquantum algorithms; > at least ML-DSA, because there's a cose draft for it. Of course, what you > suggest may change (to keep in sync with other working groups), but (IMHO) > it ought to be addressed: > - For ML-DSA, you have two obvious options (and I feel you should > tentatively pick one): > - Depending on the 'external-mu' interface, which is widely, but > not universally, supported, and which would allow you to generate > identical > signatures to the plain ML-DSA draft (similar to the P256 case) > - Alternatively, you can use HashML-DSA (the prehashed version), > similar to the Ed25519 case. > - For SLH-DSA (and FN-DSA), the "external mu" interface won't be > available (such an interface could be used by a malicious hasher to > collect > enough information to generate a large number of forgeries - far more > than > the number of hashes submitted to the signer), and so prehashing would > be > your only option. On the other hand, you might not want to address > those > algorithms, or at least, not until the nonsplit drafts have been > submitted. > > _______________________________________________ > 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]
