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

[Russ Housley <[e-mail]>]

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

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.

> - Is there some reason to not prescribe exactly one form here?
>   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.

> - Also, TLS has converged on talking about an "identity" hash
>   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.

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

Fixed.

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

Fixed.

Russ