Re: [Dcrup] Working Group Last Call for draft-ietf-dcrup-dkim-crypto

[Scott Kitterman <[e-mail]>]

In addition to my remaining last call comments (particularly #1 below), I have 
an additional change to suggest.

Currently the draft has:

> 3.  Ed25519-SHA256 Signing Algorithm
> 
>    The ed25519-sha256 signing algorithm computes a message hash as
>    defined in section 3 of [RFC6376], and signs it with the Hash variant
>    of Ed25519, as defined in in RFC 8032 section 5.1 [RFC8032].  The
>    signing algorithm is HashEdDSA.

I think this needs to be reworded for clarity (based on our current 
confusion).    I would suggest this (combining my previous LC comment and 
trying to clarify the current issue):

> The Ed25519-SHA256 Signing Algorithm computes a message hash as described
> in Section 3.7  of [RFC6376] using SHA-256 [FIPS-180-3-2008] as the
> hash-alg and signs it with Ed25519, as defined in in RFC 8032 section 5.1
> [RFC8032].  Example keys and signatures below are based on RFC 8032
> section 7.1.

It's unfortunate that the term Ed25519 is overloaded in RFC 8032, so it's not 
easy to specify.  By specifying when example set we used for our example keys, 
it'll make it clear which the draft means.

Scott K

On Monday, January 22, 2018 11:38:38 PM Scott Kitterman wrote:
> I know the last call was a long time ago and so it'd be easy to have
> forgotten, but I think points 1 and 2 are still germane.  It would also
> still be nice to see a sample signature included.
> 
> Scott K
> 
> On Friday, December 01, 2017 06:57:31 PM Scott Kitterman wrote:
> > On Friday, December 01, 2017 11:45:50 AM Murray S. Kucherawy wrote:
> > > Colleagues,
> > > 
> > > We hereby begin Working Group Last Call for
> > > draft-ietf-dcrup-dkim-crypto,
> > > to end December 15th.  Please review the document and post the
> > > (preferably
> > > at least somewhat detailed) results of your reviews to the list or to
> > > the
> > > chairs and author by end of that day.  Assuming no major revisions or
> > > discussion are needed, we hope to have this shipped to Alexey by the
> > > beginning of the December holidays.
> > 
> > I've reviewed the document (and started working on implementation).  I
> > think it is generally ready to go, but I have four comments:
> > 
> > 1.  The existing RFC 6376 signature algorithms specify what to use for
> > hash- alg.  That's missing from the Ed25519-SHA256 definition in section
> > 3.  As implied by the name (and discussed on the list), the hash-alg
> > should be SHA256.  Recommend replacing the leading sentence phrase in
> > section 3 with:
> > 
> > The Ed25519-SHA256 Signing Algorithm computes a message hash as described
> > in Section 3.7  of [RFC6376] using SHA-256 [FIPS-180-3-2008] as the
> > hash-alg, ...
> > 
> > This matches the way other signing algorithms are described in RFC 6376.
> > 
> > 2.  For clarity, per some of the IETF LC feedback on
> > draft-ietf-dcrup-dkim-
> > usage, recommend adding after the main body of section 3 and before the
> > note:
> > 
> > This is an additional DKIM signature algorithm added to Section 3.3 of
> > [RFC6376] as envisioned in Section 3.3.4 of [RFC6376].
> > 
> > 3.  Private key storage format
> > 
> > Unlike RSA, Ed25519 does not appear to have a standardized textual format.
> > I think it might make sense to specify that for DKIM Ed25519 purposes the
> > private key is stored as the base64 encoded output of the RFC 8032 Section
> > 5.1.5 private key generation processes.  This would provide a (slightly)
> > human readable private key representation that could be used by different
> > implementations so that operators can safely switch implementations
> > without
> > regenerating keys and that are more understandable for trouble shooting
> > purposes.
> > 
> > 4.  Examples
> > 
> > It would be nice to have at least one signing example for implementers to
> > use to verify correctness.  I currently have either a signing bug or a
> > verification bug in my work and I'm not sure which.  If I had a known
> > correct example to bounce my signing results against, that would help a
> > lot.
> > 
> > Scott K
> > 
> > _______________________________________________
> > Dcrup mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/dcrup
> 
> _______________________________________________
> Dcrup mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dcrup