[Curdle] questions on draft-ietf-curdle-cms-eddsa-signatures-03.txt

[Daniel Migault <[e-mail]>]

Hi,

I read draft-ietf-curdle-cms-eddsa-signatures-03.txt and have a few
questions. Please find my questions/comments inline.

Yours,
Daniel

   Use of EdDSA Signatures in the Cryptographic Message Syntax (CMS)
            <draft-ietf-curdle-cms-eddsa-signatures-03.txt>

2.  EdDSA Signature Algorithm

   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.

MGLT: My understanding of the two latest sentences is that, in most cases
the CMS when used with signed attributes may specify the hash of the
content. As prehashing is performed by CMS, there is no need to have a pre
hash variant version.

>From the two sentences it may appear that without signed attributes, they
might be some advantages of having HashEdDSA over PureEdDSA. If that is the
case, maybe we should provide them and then motivate our choice.

What is unclear to me is why signed attributed make it different ? My
understanding is that in any case digestAlgorithm is used to compute the
digest of the eContent and when defined additional signed attributes.


I am also wondering if we were using the prehash variant a combination of
digestAlgorithm with the prehash function would not be problematic. At
least, the signing operation would not be performed on the same content
this might add unnecessary overhead. If that is the case, it would provide
a generic motivation to only consider PureHash with CMS.

My understanding of EdDSA is that when PureEdDSA is possible, it is always
recommended over HashEdDSA. I assume this is also recommended for CMS.


2.3.  Message Digest Algorithm Identifiers

   When the signer includes signed attributes, a message digest
   algorithm is used to compute the message digest on the eContent
   value.  When signing with Ed25519, the message digest algorithm MUST
   be SHA-512 [RFC4634].  When signing with Ed448, the message digest
   algorithm MUST be SHAKE256 [FIPS202] with a 512-bit output value.

MGLT: I am wondering why the digestAlgorithm cannot be the identity.

   Signing with Ed25519 uses SHA-512 as part of the signing operation,
   and signing with Ed448 uses SHAKE256 as part of the signing
   operation.

MGLT: I am wondering if the text above wants to specify that the digest
algorithm specified are already part of the signature and as such no
additional hash functions really need to be added or if there is another
motivation for this text.

   For convenience, the object identifiers and parameter syntax for
   these algorithms are repeated here:

 MGLT: IOD are repeated, maybe we could add a reference where these have
been defined. -- Note that the ref becomes clearer on the next page.

2.4.  EdDSA Signatures

   The id-Ed25519 and id-Ed448 object identifiers are also used for
   signature values.  When used to identify signature algorithms, the
   AlgorithmIdentifier parameters field MUST be absent.

MGLT: I do not understand why id-Ed25519 and id-Ed448 are used for the
signature value. My understanding is that the Signer Info carries the
signature algorithm, which defines the signature.

3.  Signed-data Conventions

   The processing depends on whether the signer includes signed
   attributes.

   The inclusion of signed attributes is preferred, but the conventions
   for signed-data without signed attributes are provided for
   completeness.

MGLT: Maybe we could briefly explain or provide a reference why signed
attributes are preferred.

3.1.  Signed-data Conventions With Signed Attributes

   The SignedData digestAlgorithms field includes the identifiers of the
   message digest algorithms used by one or more signer.  There MAY be
   any number of elements in the collection, including zero.  When
   signing with Ed25519, the digestAlgorithm SHOULD include id-sha512,
   and if present, the algorithm parameters field MUST be absent.  When

   signing with Ed448, the digestAlgorithm SHOULD include
   id-shake256-len, and if present, the algorithm parameters field MUST
   also be present, and the parameter MUST contain 512, encoded as a
   positive integer value.

 MGLT: For which reason do we have a SHOULD and not a MUST, as the hash
function specified have a MUST status in te message digest identifier.


3.2.  Signed-data Conventions Without Signed Attributes