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

[Russ Housley <[e-mail]>]

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 <[e-mail]> wrote:
> 
> Hi, 
> 
> The nit tool reports the following warnings/errors:
> 
>   Checking nits according to http://www.ietf.org/id-info/checklist <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 <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 <https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#security-smime-9>
>  
> 
> On Fri, Mar 10, 2017 at 4:39 PM, Daniel Migault <[e-mail] <mailto:[e-mail]>> wrote:
> Thank you Russ for the responses. They were useful to me.
> 
> Yours,
> Daniel
> 
> -----Original Message-----
> From: Russ Housley [mailto:[e-mail] <mailto:[e-mail]>]
> Sent: Friday, March 10, 2017 12:13 PM
> To: Daniel Migault <[e-mail] <mailto:[e-mail]>>
> Cc: curdle <[e-mail] <mailto:[e-mail]>>
> 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
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/curdle <https://www.ietf.org/mailman/listinfo/curdle>
> 
> _______________________________________________
> Curdle mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/curdle