Re: [Curdle] Review of draft-ietf-curdle-cms-eddsa-signatures-03

[Russ Housley <[e-mail]>]

Jim:

Sorry, I flagged this message in my inbox, and then I missed it when I made the update earlier today.

> Section 3.1 - I would like to have a brief discussion on the integer value
> that is being used with the id-shake256-len OID when it is being used as a
> digest algorithm.  The value of 512 means that the signature security is
> going to be the same as is currently setup for Ed25519.  To have the same
> dynamic as Ed25519 does, this should be 448*2 so that after birthday attacks
> the same size of value would be provided.

RFC 8032 uses SHAKE256(x, 114) every place that SHAKE256 is used.  Reading a bit more carefully, I see that the output is 114 octets or 912 bits.

I suggest that we align with these values.  That is:

   When signing with Ed448, the message digest
   algorithm MUST be SHAKE256 [FIPS202] with a 912-bit output value.

and

   When using the id-shake256-len algorithm identifier, the parameters
   MUST be present, and the parameter MUST contain 912, encoded as a
   positive integer value.

> Section 4 - I thing that it should also be highlighted that this is a
> greater problem for when using the Signed-data without signed attributes as
> the value signed is more constrained in the other case.

I suggest:

4.  Implementation Considerations

   The EdDSA specification [EDDSA] includes the following warning.  It
   deserves highlighting, especially when signed-data is used without
   signed attributes and the content to be signed might be quite large:

      PureEdDSA requires two passes over the input.  Many existing APIs,
      protocols, and environments assume digital signature algorithms
      only need one pass over the input, and may have API or bandwidth
      concerns supporting anything else.

Russ