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

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
> Dcrup@ietf.org
> https://www.ietf.org/mailman/listinfo/dcrup