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]
