Subject: [Curdle] AD Review: draft-ietf-curdle-cms-eddsa-signatures-05.txt

From: Eric Rescorla <[email-masked]>
Date: Fri, 5 May 2017 13:13:26 -0700

TECHNICAL
S 3.1 and 3.2.
- The text here I think means "you can provide this hash and
  if you do the parameters field of the hash MUST be absent".
  Is that correct?

- Is there some reason to not prescribe exactly one form here?
  I.e., require id-sha512 (etc.) or require it not be there?

- Also, TLS has converged on talking about an "identity" hash
  for the PureEd forms. Was this discussed and rejected?

EDITORIAL
RFC 7748 uses "curveXXX" not "CurveXXX"

S 2.1
   Each algorithms are identified by an object identifier, and the
   algorithm identifier may contain parameters if needed.

Each algorithm is

S 2.4.
Please note that || means "concatenation"

---

From: Russ Housley <[email-masked]>
Date: Mon, 8 May 2017 13:32:27 -0400

>   for the PureEd forms. Was this discussed and rejected?

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.  Eric is suggesting that the “identity” hash could be used with Ed25519 and Ed448 when there are no attributes to hash.  Using ED25519 as an example, we get:

   IF (signed attributes are absent)
   THEN
	signedData.digestAlgorithms includes id-hashIdentity
        signedData.signerInfo.digestAlgorithm = id-hashIdentity
        signedData.signerInfo.signature = Ed25519(content)
   ELSE
	signedData.digestAlgorithms includes id-sha512
        signedData.signerInfo.digestAlgorithm = id-sha512
	signedData.signerInfo.signedAttrs includes message-digest = SHA512(content)
        signedData.signerInfo.signature = Ed25519(DER(signedData.signerInfo.signedAttrs))

Do others think the use of an algorithm identifier for the “identity” hash is better?  The current document include id-sha512 as a warning that Ed25519 uses that hash algorithm internally.

Russ

---

From: Russ Housley <[email-masked]>
Date: Mon, 8 May 2017 13:09:16 -0400

>   if you do the parameters field of the hash MUST be absent".

I’m not sure what part of these sections you are asking about.  The answer is different for Ed25519 and Ed448.

When signing with Ed25519, the digestAlgorithm SHOULD include id-sha512, and when the digestAlgorithm is provided, the algorithm parameters field MUST be absent.

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

>   I.e., require id-sha512 (etc.) or require it not be there?

CMS provides the digestAlgorithm to facilitate stream process, but CMS does not require that is be provided.  This just follows past convention.

>   for the PureEd forms. Was this discussed and rejected?

Where “identity” means pass the whole to-be-hased input, I assume.  That approach would work for signed-data without signed attributes, but I do not recall anyone suggesting it in this context.

> EDITORIAL
> RFC 7748 uses "curveXXX" not “CurveXXX"

Fixed.

>    algorithm identifier may contain parameters if needed.

Fixed.

> S 2.4.
> Please note that || means “concatenation"

Fixed.

Russ

---

From: Jim Schaad <[email-masked]>
Date: Mon, 8 May 2017 14:17:54 -0700

-----Original Message-----
From: Curdle [mailto:[email-masked]] On Behalf Of Russ Housley
Sent: Monday, May 8, 2017 10:32 AM
To: curdle <[email-masked]>
Cc: Eric Rescorla <[email-masked]>
Subject: Re: [Curdle] AD Review: draft-ietf-curdle-cms-eddsa-signatures-05.txt

[JLS]  Creation of an identity hash function would certainly be a good way to give the hint that the entirety of the content is going to be needed or the signature algorithm.  As such it sounds like a good idea.  My worry would be about potential misuse of this as a hash function in other contexts.  For example, what happens if you used the identity hash unction when signed attributes are present?  Does this mean that you end up with two copies of the content in the resulting SignedMessage object?  Where would it get abused that might be problematic. 

On the balance however, I think this is a better idea than not having the indicator.  It is just going to need some caveats around it.  I still think I just prefer saying that you must have the attributes present, but that ship is probably never going to sail.

Jim

Russ
_______________________________________________
Curdle mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/curdle

---

From: Russ Housley <[email-masked]>
Date: Wed, 10 May 2017 11:41:08 -0400

> Do others think the use of an algorithm identifier for the “identity” hash is better?  The current document include id-sha512 as a warning that Ed25519 uses that hash algorithm internally.

I would like to hear from others about this suggestion from Eric Rescorla’s review.  Jim pointed out one possible downside.  Others have been silent.

Russ

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 10 May 2017 16:04:04 +0000

> I would like to hear from others about this suggestion from Eric Rescorla’s
> review.  Jim pointed out one possible downside.  Others have been silent.

As an individual, I agree with Jim; do it, but add some text.

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Tue, 30 May 2017 13:31:24 +0200

On Mon, 2017-05-08 at 13:32 -0400, Russ Housley wrote:
> 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.  Eric is suggesting that the “identity” hash could be
> used with Ed25519 and Ed448 when there are no attributes to
> hash.  Using ED25519 as an example, we get:
> 
>         signedData.signerInfo.signature =
> Ed25519(DER(signedData.signerInfo.signedAttrs))
> 
> Do others think the use of an algorithm identifier for the “identity”
> hash is better?  The current document include id-sha512 as a warning
> that Ed25519 uses that hash algorithm internally.

I miss the benefit of that change. Given that the flag 'signed
attributes are absent' is sufficient to determine the action to be
done, adding the identity hash identifier, can only create confusion.
The confusion can be because now we have multiple additional states
which provide no additional information.

E.g. the following are simply invalid:
'signed attributes are absent' and digestAlgorithm != id-hashIdentity
'signed attributes are present' and digestAlgorithm = id-hashIdentity

I prefer the original approach due to its simplicity.

regards,
Nikos

---

From: Russ Housley <[email-masked]>
Date: Tue, 30 May 2017 11:38:13 -0400

My assessment is that people are fine with the approach in the document.

Russ

> On May 30, 2017, at 7:31 AM, Nikos Mavrogiannopoulos <[email-masked]> wrote:
>