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

From: Daniel Migault <[email-masked]>
Date: Thu, 9 Mar 2017 16:56:14 -0500

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

---

From: Russ Housley <[email-masked]>
Date: Fri, 10 Mar 2017 12:13:24 -0500

Daniel:

> 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.  

CMS supports signatures with and without signed attributes.  In most cases, signed attributes are present.  When signed attributes are present, the message-digest attribute MUST be one of the attributes.  It was signed to work like this:

      IF (signed attributes are absent)
      THEN md = Hash(content)
      ELSE message-digest attribute = Hash(content);
           md = Hash(DER(SignedAttributes))

      Sign(md)

> 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.  

Yes, HashEdDSA could be useful when signed attributes are present.  I was not including HashEdDSA in this document because curdle-pkix did not support that algorithm.  If that changes (as is being discussed on a separate thread), then it should be supported here as well.

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

We could RECOMMEND PureEdDSA when signed attributes are present, and we could RECOMMEND PureEdDSA when signed attributes are absent, but the content is not very large.

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

Since CMS allows multiple signatures on the content, the idea is to tell the implementation which hash functions are needed in a field that appears before the content that needs to be hashed.

> 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.   

This is the rationale for the earlier statement.

>  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.

These OIDs all come from the NIST website, but NIST does not publish an ASN.1 module that includes them.

Most of them appear in the ASN.1 module in the curdle-pkix document.  I should probably add a module to this document too.

> 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.  

      SignerInfo ::= SEQUENCE {
        version CMSVersion,
        sid SignerIdentifier,
        digestAlgorithm DigestAlgorithmIdentifier,
        signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL,
        signatureAlgorithm SignatureAlgorithmIdentifier,
        signature SignatureValue,
        unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL }

This text is talking about the SignatureAlgorithmIdentifier, which uses the same OID as the subject public key in the certificate that will be used to validate the signature.

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

This is a statement about what most implementation do.  S/MIME says that sending agents SHOULD include signed attributes, and I cannot think of any that don’t do so.

>  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.    

This is at odds with your comment on section 2.  I’m fine with making this a MUST.

Russ

---

From: Daniel Migault <[email-masked]>
Date: Fri, 10 Mar 2017 21:39:49 +0000

Thank you Russ for the responses. They were useful to me.

Yours, 
Daniel

-----Original Message-----
From: Russ Housley [mailto:[email-masked]] 
Sent: Friday, March 10, 2017 12:13 PM
To: Daniel Migault <[email-masked]>
Cc: curdle <[email-masked]>
Subject: Re: [Curdle] questions on draft-ietf-curdle-cms-eddsa-signatures-03.txt

      Sign(md)

Russ