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

Colleagues,

WGLC has completed and this is sadly the only feedback we received.  I will
do a chair's review today, but it would be really helpful to have some more
reviewers to comment on this before we send it to Alexey.

Simultaneously: John, your comments in reply to this?

-MSK

On Fri, Dec 1, 2017 at 3:57 PM, Scott Kitterman <sklist@kitterman.com>
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
> Dcrup@ietf.org
> https://www.ietf.org/mailman/listinfo/dcrup
>