[Curdle] Comments on draft-housley-cms-eddsa-signatures

[Russ Housley <[e-mail]>]

Jim Schaad sent me some comments on this document.  Since I have asked this
working group to adopt this draft, I have gotten Jim’s permission to respond to
the comments on list.

> 1.  I am not sure that I see a great deal of benefits for doing both the
> pre-hash version and pure version of EdDSA.   Specifically, the use of the
> pre-hash version really only seems to make sense if one does not use signed
> attributes.  However, I think that this is a case which would never occur
> for this signature algorithm.

Right.  Since signed attributes are the most common use with CMS, it is
probably better to just make use of PureEdDSA.

I suggest adding this text to Section 2 of the document:

   One of the parameters of the EdDSA algorithm is the "prehash"
   function.  This may be the identity function, resulting in an
   algorithm called PureEdDSA, or a collision-resistant hash function,
   resulting in an algorithm called HashEdDSA.  In most situations the
   CMS SignedData includes signed attributes, including the message
   digest of the content.  Since HashEdDSA offers no benefit when signed
   attributes are present, only PureEdDSA is used with the CMS.

And, then change Section 2.1 like this:

   When the id-EdDSAPublicKey onject identifier is used, the
   AlgorithmIdentifier parameters field MUST contain EdDSAParameters to
   specify a particular set of EdDSA parameters:

      EdDSAParameters ::= ENUMERATED {
        ed25519   (1),    -- PureEdDSA
        ed25519ph (2),    -- HashEdDSA; not used in the CMS
        ed448     (3),    -- PureEdDSA
        ed448ph   (4) }   -- HashEdDSA; not used in the CMS


> 2.  We need to get a definition of how to use SHAKE256 from someplace if we
> are going to say use the same hash algorithm throughout as that is what
> Ed448 uses.  It would be worthwhile to specify what hash algorithms should
> be used with each of the different signature algorithms given that it is not
> clear from the name of the algorithm identifier.

This document references draft-irtf-cfrg-eddsa-05, and that document
includes this reference for SHAKE256:

   [FIPS202]  National Institute of Standards and Technology, U.S.
              Department of Commerce, "SHA-3 Standard: Permutation-Based
              Hash and Extendable-Output Functions", FIPS 202, August
              2015.

I’m not sure what more you think is needed.


> 3.  In section 3 para 2: This sentence does not necessarily make sense for
> the pure version of EdDSA.  In some sense there is no hash function which is
> used on the signedAttribute value.  I don't know that it needs to be fixed,
> but it might be somewhat confusing.

You are talking about this paragraph:

   The same one-way hash function SHOULD be used for computing the
   message digest on both the eContent and the signedAttributes value if
   signedAttributes are present.

I think the principle is correct.  I’m not sure how to address your comment.


> 4.  In section 4, the problem with EdDSA is worse for the use of different
> algorithms than what you are stating.  It is possible to do some interesting
> forgeries if you cross between the pre-hash and not pre-hash versions with
> the Ed25519 curve since there is no context difference between them.  This
> has to be forbidden not just strongly suggested.

Does the removal of HashEdDSA resolve this one?

Russ