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.
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. Due to my lack of knowledge of the COSE application context, I cannot judge whether this is really required. 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. In any case, the abstract and the introduction should mention this purpose as the central novelty introduced by the draft.
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.
In any case I don’t think it is a good idea to define the COSE ID Ed25519ph as using Ed25519 from RFC 8032 internally. The former name is already defined by RFC 8032 in a different way. It would make much more sense to define the COSE ID Ed25519ph as Ed25519ph from RFC 8032. This would also mitigate the potential ambiguity of whether signing the hash or the message, since Ed25519 and Ed25519ph are domain separated as becomes clear from Section 5.1.6 of RFC 8032 <https://www.rfc-editor.org/rfc/rfc8032#section-5.1.6>. 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<…>.^1 <#fn1>
The exact same considerations apply to Ed448 and Ed448ph.
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.
* 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
o Ed25519 and Ed448 are only used to sign messages directly and
o 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”.
Regards,
Falko
------------------------------------------------------------------------
1.
Note that Section 3 of RFC 8032 states about itself: “Therefore, a
precise explanation of the generic EdDSA is thus not particularly
useful for implementers. For background and completeness, a succinct
description of the generic EdDSA algorithm is given here.”↩︎ <#fnref1>
--
*MTG AG*
Dr. Falko Strenzke
Phone: +49 6151 8000 24
E-Mail: [email protected]
Web: mtg.de <https://www.mtg.de>
------------------------------------------------------------------------
MTG AG - Dolivostr. 11 - 64293 Darmstadt, Germany
Commercial register: HRB 8901
Register Court: Amtsgericht Darmstadt
Management Board: Jürgen Ruf (CEO), Tamer Kemeröz
Chairman of the Supervisory Board: Dr. Thomas Milde
This email may contain confidential and/or privileged information. If
you are not the correct recipient or have received this email in error,
please inform the sender immediately and delete this email.Unauthorised
copying or distribution of this email is not permitted.
Data protection information: Privacy policy <https://www.mtg.de/en/privacy-policy>
smime.p7s
Description: Kryptografische S/MIME-Signatur
_______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
