Subject: [Dcrup] Explicit key fingerprint algorithm?

From: Federico Santandrea <[email-masked]>
Date: Wed, 10 May 2017 11:05:20 +0200

From draft-ietf-dcrup-dkim-crypto-00:

> The DNS record contains a sha-256 hash of the public key, stored in
> base64 in the p= tag. The key type tag MUST be present and contains
> k=rsafp or k=ecdhfp.

Could it be more future-proof to just say "contains a hash" and let
the registered values be "k=rsafp-sha256" and "k=ecdhfp-sha256"? I am
not saying that we need more algorithms right now, SHA-256 is fine; but
should the need arise to add others in the future, we would end up with
a mix of implicit and explicit fingerprint algorithm designations.

On the other hand, at the moment this would be just a waste of precious
characters in the DNS record compared to just having an agreed, sensible
algorithm.

(One could also add another tag to the same end, but that sounds like
an unnecessary complication to me.)

-- 
Federico

---

From: "John Levine" <[email-masked]>
Date: 10 May 2017 15:47:36 -0000

In article <[email-masked]> you write:
>the registered values be "k=rsafp-sha256" and "k=ecdhfp-sha256"?

I suppose.  The goal here is to add the smallest number of new
algorithms and representations that will keep DKIM reasonably secure
for the forseeable future.  The more we add, the more chances there
are for implementations not to interoperate.  So I don't care where
the reference to SHA-256 is, so long as we agree that what we
actually add today is SHA-256 only.

R's,
John

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 10 May 2017 16:03:04 +0000

> >Could it be more future-proof to just say "contains a hash" and let the
> >registered values be "k=rsafp-sha256" and "k=ecdhfp-sha256"?
> 
> I suppose.  The goal here is to add the smallest number of new algorithms
> and representations that will keep DKIM reasonably secure for the
> forseeable future. 

A related discussion is happening in the curdle group, where some want the hash specified (as an "identity" hash) for Ed448 and others don't (as SHA512 is implied).

I suggest that this group look closely at draft-ietf-curdle-cms-eddsa-signatures for its signature algorithms.   The digest isn't required as a parameter, and it's SHA512.