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

From: Daniel Migault <[email-masked]>
Date: Fri, 7 Apr 2017 14:15:07 -0400

Hi,

The nit tool reports the following warnings/errors:

  Checking nits according to http://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

  ** The document seems to lack an IANA Considerations section.  (See Section
     2.2 of http://www.ietf.org/id-info/checklist for how to handle the case
     when there are no actions for IANA.)

  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  == The "Author's Address" (or "Authors' Addresses") section title is
     misspelled.

Just for clarification, IANA registries do not register IODs outside
their arc. Am I correct ?

[1] https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#security-smime-9

On Fri, Mar 10, 2017 at 4:39 PM, Daniel Migault <[email-masked]
> wrote:

> 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
>
> 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.
>
> 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.
>
>
> > 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.
>
> 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.
>
> >    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.
>
> This is the rationale for the earlier statement.
>
> >    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.
>
> 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.
>
>
> >  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.
>
>       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.
>
>
> > 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.
>
> 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.
>
>
> > 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.
>
> This is at odds with your comment on section 2.  I’m fine with making this
> a MUST.
>
> Russ
>
> _______________________________________________
> Curdle mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/curdle
>

---

From: Russ Housley <[email-masked]>
Date: Fri, 7 Apr 2017 16:20:20 -0400

Daniel:

IANA maintains registration in two object identifier arcs:

1. with a prefix of 1.3.6.1

https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml <https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml>

2.  with a prefix of 1.2.840.113549.1.9.16

https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#security-smime <https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#security-smime>

Russ

> On Apr 7, 2017, at 2:15 PM, Daniel Migault <[email-masked]> wrote:
> 
> Hi, 
> 
>   Checking nits according to http://www.ietf.org/id-info/checklist <http://www.ietf.org/id-info/checklist> :
>      2.2 of http://www.ietf.org/id-info/checklist <http://www.ietf.org/id-info/checklist> for how to handle the case
> Just for clarification, IANA registries do not register IODs outside their arc. Am I correct ? 
> 
> [1] https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#security-smime-9 <https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#security-smime-9>
>  
> 
> On Fri, Mar 10, 2017 at 4:39 PM, Daniel Migault <[email-masked] <mailto:[email-masked]>> wrote:
> From: Russ Housley [mailto:[email-masked] <mailto:[email-masked]>]
> To: Daniel Migault <[email-masked] <mailto:[email-masked]>>
> Cc: curdle <[email-masked] <mailto:[email-masked]>>
> Subject: Re: [Curdle] questions on draft-ietf-curdle-cms-eddsa-signatures-03.txt
> 
> 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:
> 
> > 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.
> 
> 
> 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.
> 
> >  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.
> 
> 
> >  2.4.  EdDSA Signatures
> >
> > 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.
> 
> 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
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/curdle <https://www.ietf.org/mailman/listinfo/curdle>
>

---

From: Russ Housley <[email-masked]>
Date: Mon, 10 Apr 2017 12:16:27 -0400

Daniel:

I will post -04 in a few minutes.

>   Checking nits according to http://www.ietf.org/id-info/checklist <http://www.ietf.org/id-info/checklist> :
I added a section to explicitly state that no IANA actions are needed.

>   Miscellaneous warnings:
Fixed.
> Just for clarification, IANA registries do not register IODs outside their arc. Am I correct ? 
No new object identifiers need to be assigned.

Russ