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

[Scott Kitterman <[e-mail]>]

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