Subject: Re: [Dcrup] WGLC final issues draft-ietf-dcrup-dkim-crypto

From: "Salz, Rich" <[email-masked]>
Date: Thu, 1 Feb 2018 17:36:09 +0000

I don't think missing to specify hash-alg is editorial.  I agree the second is editorial.

As your note points out, SHA256 is obviously implied by the name of the definition :)  But we did have consensus to use SHA256 for this mechanism.

Mr. Author, please update and resubmit the doc to account for those first two issues from https://www.ietf.org/mail-archive/web/dcrup/current/msg00619.html

---

From: "John Levine" <[email-masked]>
Date: 1 Feb 2018 14:14:20 -0500

In article <[email-masked]> you write:
>Scott has asked that his WGLC call issues from December be addressed.  I believe this is the message he
>means is this:
>   https://www.ietf.org/mail-archive/web/dcrup/current/msg00619.html
>and that only the first two points remain. They seem like editorial clarifications to me; John can you make
>those changes or something similar?

Done, an updated draft is sitting here waiting for ...

>There has also been discussion about including samples in the document.  Where are we with that?

I think a lot of us are twiddling our thumbs waiting for the OpenSSL
version it is that will include ed25519 signatures since we'd rather
not rewrite our RSA code to call some library that already has ed25519
and we don't want to call two different crypto libraries from our DKIM
code.

I see 1.1.0g in the freebsd packages which looks like it's got
ed25519, so now I just have to figure out how to use the fricking
thing.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 1 Feb 2018 18:15:25 -0500

In article <[email-masked]> you write:
>Scott has asked that his WGLC call issues from December be addressed.  I believe this is the message he means is this:
>and that only the first two points remain. They seem like editorial clarifications to me; John can you make those changes or something similar?

I have the changes in a copy here waiting to be sent in ...

>There has also been discussion about including samples in the document.  Where are we with that?

 ... once we deal with this.

I use the perl DKIM library and as far as I can tell there is not yet
any perl library support for OpenSSL ed25519 signatures, even though the
underlying OpenSSL has had it for a while.

There are other perl crypto libraries but I only see one that does
ed25519 and it uses underlying code from it's not clear where.

R's,
John

---

From: Jeremy Harris <[email-masked]>
Date: Thu, 1 Feb 2018 23:18:51 +0000

> ed25519, so now I just have to figure out how to use the fricking

My build of 1.1.0g spits out:

error:0608F096:digital envelope routines:EVP_PKEY_verify_init:operation
not supported for this keytype

with my attempted use for DKIM with a=ed25519-sha256.

Current master ditto.
-- 
Jeremy

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 2 Feb 2018 01:15:35 +0000

➢ There are other perl crypto libraries but I only see one that does
    ed25519 and it uses underlying code from it's not clear where.
    
Can you try it and post the results?  IF someone else can verify the signature then we can publish it, even if it’s not the code you would want to use in production.

---

From: "John R Levine" <[email-masked]>
Date: 1 Feb 2018 20:27:50 -0500

> Can you try it and post the results?  IF someone else can verify the signature then we can publish it, even if it’s not the code you would want to use in production.

I'll take a look.  The existing code is pretty tied to openssl.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 2 Feb 2018 01:33:16 +0000

Can anyone else generate or verify a signature?  So we have something to put into the draft??

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 02 Feb 2018 02:10:45 +0000

I think I'm close.  There's a good chance I'll have something this weekend.

Scott K

On February 2, 2018 1:33:16 AM UTC, "Salz, Rich" <[email-masked]> wrote:
>_______________________________________________
>Dcrup mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/dcrup

---

From: Jeremy Harris <[email-masked]>
Date: Fri, 2 Feb 2018 09:19:27 +0000

On 02/02/18 01:33, Salz, Rich wrote:
> Can anyone else generate or verify a signature?

I can, but...

> So we have something to put into the draft??

... having no independent verification, I don't trust it.
I'm hoping Scott will give me that assurance.

-- 
Jeremy

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 3 Feb 2018 21:26:23 -0800

> I'm hoping Scott will give me that assurance.

I can try in the next few days to test it against OpenDKIM.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 04 Feb 2018 05:42:32 +0000

>I can try in the next few days to test it against OpenDKIM.

We've had some off list exchange of data and we each learned something.  My implementation is still incomplete, but I'm working on it.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 05 Feb 2018 03:57:39 -0500

On Sunday, February 04, 2018 05:42:32 AM Scott Kitterman wrote:
> We've had some off list exchange of data and we each learned something.  My
> implementation is still incomplete, but I'm working on it.
> 
> Scott K

I can now sign and verify messages I signed.  Before we put anything in the 
draft as an example though, I think we ought to get two implementations to 
agree.  Jeremy and I both have working, internally consistent implementations.  
Now we need to exchange some data.  Hopefully we can get OpenDKIM in the mix 
too.

My python code is published in the usual location:
https://code.launchpad.net/~dkimpy-hackers/dkimpy/trunk

Scott K

---

From: Jeremy Harris <[email-masked]>
Date: Mon, 5 Feb 2018 17:23:24 +0000

On 05/02/18 08:57, Scott Kitterman wrote:
> Now we need to exchange some data.

Looking good; I can verify a sample message signed by Scott.
-- 
Jeremy

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 05 Feb 2018 13:15:34 -0500

On Monday, February 05, 2018 05:23:24 PM Jeremy Harris wrote:
> > agree.  Jeremy and I both have working, internally consistent
> > implementations. Now we need to exchange some data.
> 

And I can do the same for a sample message from Jeremy.

If someone would provide the text of the example message you want signed for 
the draft, I can provide the signature.  I recommend we use the keys from 
Section 7.1, Test 1 of RFC 8032.

Scott K

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 5 Feb 2018 18:20:03 +0000

➢ > Looking good; I can verify a sample message signed by Scott.
    
>    And I can do the same for a sample message from Jeremy.
    
➢     If someone would provide the text of the example message you want signed for 
    the draft, I can provide the signature.  I recommend we use the keys from 
    Section 7.1, Test 1 of RFC 8032.
    
This is great news.  Your recommendation makes sense to me.

---

From: "John Levine" <[email-masked]>
Date: 5 Feb 2018 14:34:09 -0500

>https://code.launchpad.net/~dkimpy-hackers/dkimpy/trunk

This may be a dumb question, but are you sure you're doing ed25519ph rather than ed25519?

When I look at your code, I see it calling <key>.sign() which I am reasonably sure is ed25519.

In the libsodium library, crypto_sign() does ed25519, while
crypto_sign_init() and crypto_sign_update() and
crypto_sign_final_verify() do ed25519ph.  They're different, and the
signatures they create are different.  

A straightforward way to check is to pull out your signing code and
feed it the test vector in RFC 8032 section 7.2 and make sure it
creates the right signature.  It took me a while to realize that
ed25519(sha512(foo)) is not the same as ed25519ph(foo).

Having said that, and also having wasted much of the weekend looking
at perl crypto libraries, I found a lot of bindings to ed25519() and
none for ed25519ph().  A cursory look at the python library suggests
the same thing.

So perhaps all the people who told us that libraries would only do the
prehash version were misinformed and I should change the draft to
use the regular not prehash version.

R's,
John

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 05 Feb 2018 14:56:33 -0500

On Monday, February 05, 2018 02:34:09 PM John Levine wrote:
> >implementations. Now we need to exchange some data.  Hopefully we can get
> >OpenDKIM in the mix too.
> >

Sigh.  I misread the draft, and apparently I'm not the only one.

I checked myself against TEST 1 of Section 7.1, since that's the one I thought 
we were doing.  No need to feed it the other test vector.  I already know it's 
wrong.

Since Jeremy and I are interoperable using ed25519 and support for ed25519ph 
is limited (in addition to your findings, it's not supported by the Python 
bindings for libsodium that I'm using) I'd say switch the draft.  ~All the 
running code uses ed25519 and it'll be easier for others to implement as well.  
It also lets you get rid of the note about hashing something that's already 
hashed (right? - I stayed up depressingly late last night finishing this, so 
I'm likely not firing on all cylinders at the moment).

Scott K

---

From: "denis bider \(Bitvise\)" <[email-masked]>
Date: Mon, 5 Feb 2018 14:44:39 -0600

> Since Jeremy and I are interoperable using ed25519 and
> support for ed25519ph is limited (in addition to your findings,
> it's not supported by the Python bindings for libsodium that I'm
> using) I'd say switch the draft.  

I believe this has already been discussed and agreed on (to use Ed25519, and not Ed25519-prehash). The reasons were along the lines you mention.

It sounds as though your implementation reflects the last agreement I am aware of. If the draft says differently, it likely needs to be updated.

denis

From: Scott Kitterman 
Sent: Monday, February 5, 2018 13:56
To: [email-masked] 
Subject: Re: [Dcrup] WGLC final issues draft-ietf-dcrup-dkim-crypto

Scott K

---

From: "John Levine" <[email-masked]>
Date: 5 Feb 2018 16:50:00 -0500

>    Section 7.1, Test 1 of RFC 8032.

Hey, wait a minute.  Those keys are for ed25519, but the draft says
ed25519ph.  The test vectors for ed25519ph are in section 7.3.

For months people have been telling me that nobody will implement
plain ed25519, only prehashed ed25519ph.  But when I looked at Scott's
code it was pretty clear he's using plain ed25519, and now you're
saying to use the test vectors for ed25519.  FYI, I wasted a fair
amount of time over the weekend looking at perl wrappers for crypto
libraries, where I found lots of wrappers for ed25519 and none for
ed25519ph.

Needless to say I'm not going to ship a draft where the examples don't
match the spec.  Should I conclude that all that stuff about
prehashing was wrong and take it out of the spec?

R's,
John

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 05 Feb 2018 17:07:48 -0500

On Monday, February 05, 2018 04:50:00 PM John Levine wrote:
> >➢     If someone would provide the text of the example message you want
> >signed for>

I think it was wrong.  Jeremy was able to get things working with GNU TLS 
using ed25519.  Given you found ed25519 in perl, I think it's fair to say it's 
common.

I said use the test vectors for the crypto type I implemented.  I confess to 
being confused about ed25519 versus ed25519ph.  In the python bindings I was 
using, I had one choice, so I used it.

Given the only reason we picked ed25519 pre-hash, was presumably superior 
library availability, I think we ought to change the draft.  Clearly "people" 
were wrong.

I, for one, am glad we waited for running code before shipping the document.

Scott K

---

From: "John R. Levine" <[email-masked]>
Date: 5 Feb 2018 17:17:10 -0500

> using, I had one choice, so I used it.

If they're the test vectors in section 7.1, that's definitely the regular 
not prehashed flavor.

> library availability, I think we ought to change the draft.  Clearly "people"

OK with me.  Oh, Mr. WG Chair ... ?

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 05 Feb 2018 17:25:12 -0500

On Monday, February 05, 2018 05:17:10 PM John R. Levine wrote:
> > I said use the test vectors for the crypto type I implemented.  I confess
> > to being confused about ed25519 versus ed25519ph.  In the python bindings
> > I was using, I had one choice, so I used it.
> 

I retrospect, that's perfectly clear.  I made the mistake of believing that 
since "everyone" was saying only the prehash was going to be implemented, that 
must be the one I had.  Sorry for the confusion.

Scott K

---

From: "John R. Levine" <[email-masked]>
Date: 5 Feb 2018 17:30:01 -0500

> I believe this has already been discussed and agreed on (to use Ed25519, and not Ed25519-prehash). The reasons were along the lines you mention.

I went back and looked at the list archives and I see that Rich said 
OpenSSL has "no plans to do prehash", which I somehow misread as "only 
plans to do prehash."

I think we're all in agreement so I'll take out the extra hash.  Since 
there's some other stuff I really should be doing, I might even hack 
ed25519 into the perl code instead.

Regards,

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 5 Feb 2018 23:52:02 +0000

> library availability, I think we ought to change the draft.  Clearly "people"
    
➢     OK with me.  Oh, Mr. WG Chair ... ?
    
Apparently I am people.

I was wrong.  Sorry for the misdirection.  Let’s change it.

---

From: Jeremy Harris <[email-masked]>
Date: Tue, 6 Feb 2018 00:16:56 +0000

On 05/02/18 22:30, John R. Levine wrote:
>> I believe this has already been discussed and agreed on (to use
>> Ed25519, and not Ed25519-prehash). The reasons were along the lines
>> you mention.
> 

I'm now re-confused.

As far as I'm aware, my code (which interops with Scotts) is

a) doing a sha256
b) feeding the result of (a) to a gnutls routine which does
   c.1) a sha512
   c.2) an ed25519 signing, or verification

That sounds like an "extra hash" to me.  I'm unclear whether you're
calling it "use Ed25519" or "use Ed25519-prehash".  I'm unclear why
you'll be taking out "the extra hash".  I'm unclear whether the
operation you're calling "ed25519ph()" is called that because it
expects a pre-hashed lump of data (and is only doing a pure signing
operation of a small amount of data) or whether it is called that
because it first hashes a (probably large) amount of data and then
signs it.

-- 
Jeremy

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 05 Feb 2018 19:27:30 -0500

> because it first hashes a (probably large) amount of data and then

I think we got caught up in terminology.  I believe you and I have implemented 
what we want in the draft, so we just need to wait for the draft.

Scott K

---

From: denis bider <[email-masked]>
Date: Mon, 5 Feb 2018 19:37:57 -0600

I believe a confusion of terminology has occurred in the draft.

My understanding is same as Jeremy's: Ed25519 performs the extra hash,
Ed25519ph is different in that it doesn't (it doesn't DO a pre-hash; it
EXPECTS pre-hashed input).

My understanding of implementation availability is that Ed25519 (with the
extra hash) is available universally, Ed25519ph isn't.

My understanding of the agreement reached on the list is that we do what's
universally available (Ed25519), and we do not do what isn't (Ed25519ph).

It looks like the concepts were accidentally reversed when writing the
draft, which is understandable since it's confusing what the "ph" in
"Ed25519ph" stands for.

denis

---

From: denis bider <[email-masked]>
Date: Mon, 5 Feb 2018 20:03:54 -0600

Bah, it's actually the opposite:

https://tools.ietf.org/html/rfc8032#section-4

Ed25519 is PureEdDSA, and uses SHA-512 internally.

Ed25519ph is HashEdDSA, and is identical to Ed25519(prehash(M)). It uses
two hashes, both the prehash and the SHA-512 hash internal to Ed25519.

What we actually want to do is this:

Ed25519(sha256(M)) - this involves two hashes of the message, one DKIM
SHA-256 hash because that's how hashes are done in DKIM, then sign that
using Ed25519, which applies another SHA-512 hash that's internal to
Ed25519.

The confusion comes from that this is equivalent to:

Ed25519ph-sha256(M)

What the draft currently specifies is:

Ed25519ph-sha256(sha256(M))

As specified, this inadvertently involves a triple hash.

So yeah, the draft needs to say we're hashing first using sha256 as usual
in DKIM, and then we're signing the result using PureEdDSA. Which just
happens to be equivalent to Ed25519ph-sha256 when viewing both steps
together.

---

From: "John Levine" <[email-masked]>
Date: 6 Feb 2018 04:06:06 -0000

In article <[email-masked]>,
>I'm now re-confused.

Me too.

>As far as I'm aware, my code (which interops with Scotts) is

So far so good.

>   c.2) an ed25519 signing, or verification

That would be a rather odd thing for it to do.  The ed25519ph algorithm
is *not* the same as hash and then sign with ed25519.  

How about pulling out your signing code and feeding it the test
vectors in RFC 8032 section 7.1 and see what result you get.  If you
get the same answers they do, you're not doing the sha512. If you
don't get the same answers they do, I am at a loss to guess how you
could interoperate witn Scott.

R's,
John

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 05 Feb 2018 23:35:40 -0500

> could interoperate witn Scott.

I'm definitely doing ed25519 (not ed25519ph) based on the RFC examples.  
Running the attached script yields:

$ python3 typetest.py
7.1-1 signatures match
7.1-1 nacl pubkey and RFC match
7.1-2 signatures match
7.1-2 nacl pubkey and RFC match
7.3 signatures don't match
b'\xc9Dl\x82\xf4#P\x87a3d\xb1\xe2\xc3\x1a\xed\n\xe9\xf1\x1ai\x82\x85\x99\x14\xbd\xd8V^\x11\x9d&\xcdGB<&\xc2\xa4\x9d_`\xd8G\xf7Q 
\xf4\xba\xda\x1a\x01\x06:\xaf\xef\x8f\xec\xb9\xa0~2\xe7\x07'
7.3 nacl pubkey and RFC match

That means PyNaCl is producing signatures that match ed25519's and not 
ed25519ph, which is what I thought I was doing to start with.

Scott K

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 6 Feb 2018 10:46:55 +0100

> As far as I'm aware, my code (which interops with Scotts) is

I proposed that for messages shorter than, say, 4k, (a) be skipped.  But doing
that extra hash seems to require less code changes.

With respect to Section 4 of rfc8032, I recommend that the draft say we opt for
"(2) a single-pass interface for creating signatures."  Draft readers ought not
to be so confused as we are...

> That sounds like an "extra hash" to me.
The disadvantage is that (b) would have provided a collision-safe signature
even if sha512 had collisions.  We lower that to sha256's health.  I don't
think this is going to be a problem, but we have to state it.

Ale

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 6 Feb 2018 13:35:04 +0000

➢ I proposed that for messages shorter than, say, 4k, (a) be skipped.  But doing
    that extra hash seems to require less code changes.
    
I think that would be a very very bad idea.  It makes the code more complex -- it doubles the number of algorithms that must be implemented.  Optimizing to remove an “extra” hash is not worth it. Most of the time this will be running on servers with hardware assist and/or optimized hand-tuned assembler

---

From: "John Levine" <[email-masked]>
Date: 6 Feb 2018 12:09:38 -0500

>Ed25519 is PureEdDSA, and uses SHA-512 internally.

Yup.

>Ed25519ph is HashEdDSA, and is identical to Ed25519(prehash(M)).

Nope.

Look for the the definition of dom2() on page 5 and for the context at
the top of page 10 in RFC 8032, and also note that the last test in
section 7.1. which does ed25519(SHA("abc")) has a different answer
from the test in section 7.3 which does ed26619ph("abc")

>The confusion comes from that this is equivalent to:

Again, nope.

>Ed25519ph-sha256(sha256(M))

That's fixed in the next version.

R's,
John

---

From: denis bider <[email-masked]>
Date: Tue, 6 Feb 2018 23:07:00 -0600

Aye - I missed the dom2 stratagem in the Ed25519ph construction. Sigh. I
understand the reasoning, but on the other hand, I think I can see why no
one supports this. :)

Thanks for the correction!

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 07 Feb 2018 01:50:49 -0500

On Tuesday, February 06, 2018 11:07:00 PM denis bider wrote:
> > In article <CADPMZDAsLEy0kbsh9rs0Bi=WWdkQdhY-XW_75Ynm4nY+2szwRA@mail.
> > 
> > gmail.com> you write:

Thanks.  I went ahead and released dkimpy 0.7.0 based on this assumption.  As 
far as I know it does everything this draft intends to solve.  Hopefully that 
will get more people to notice and maybe there will be additional feedback.  
If I'm wrong, version numbers are cheap.

In the mean time, I believe we are closing in on it.

Scott K

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 7 Feb 2018 09:39:22 +0100

On Tue 06/Feb/2018 14:35:04 +0100 Salz, Rich wrote:
> I think that would be a very very bad idea.  It makes the code more complex

That's ok, I didn't mean to re-discuss it.  However, mentioning that
possibility, for example when introducing the Ed25519-SHA256 Signing Algorithm
in Section 3, could clarify to casual readers what is being done.  For example:

   Since we use Ed25519, we could have opted to pass the cleartext to be signed
   directly.  Instead, we opted to pass a sha256 digest, which provides for a
   single-pass interface, more easily attainable stemming from legacy RSA-only
   implementations of DKIM.

jm2c

Ale

---

From: "John Levine" <[email-masked]>
Date: 7 Feb 2018 12:12:04 -0500

>think this is going to be a problem, but we have to state it.

Definitely not.  This adds more overall complexity for no practical benefit.

We have running code, two implementations that interoperate.  So I
really really hope as soon as we get the examples to splice into the
draft, we're done.

R's,
John

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 07 Feb 2018 23:43:42 -0500

On Wednesday, February 07, 2018 12:12:04 PM John Levine wrote:
> >I proposed that for messages shorter than, say, 4k, (a) be skipped.  But
> >doing that extra hash seems to require less code changes.
> >
> >With respect to Section 4 of rfc8032, I recommend that the draft say we opt
> >for "(2) a single-pass interface for creating signatures."  Draft readers
> >ought not to be so confused as we are...
> >

Here are four signatures (different canonicalizations) of the attached message 
(take from the RFC 6376 examples) using the RFC 8032 section 7.1 keys.

DKIM-Signature: v=1; a=ed25519-sha256; c=simple/simple; d=example.com;
 i=@example.com; q=dns/txt; s=test; t=1518064698; h=from :
 to : subject : date : message-id : from : subject : date;
 bh=4bLNXImK9drULnmePzZNEBleUanJCX5PIsDIFoH4KTQ=;
 b=Mj7y77UZsr6byb6fk1BIMpiyHZxcowFkqvJ6F4eY4njHotFIOjTFdgHr
 XLDMt0jmh825Cz9vB6D5qOY1dUuECw==

DKIM-Signature: v=1; a=ed25519-sha256; c=simple/relaxed; d=example.com;
 i=@example.com; q=dns/txt; s=test; t=1518064698; h=from :
 to : subject : date : message-id : from : subject : date;
 bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
 b=M1Vb4fEK0ArpknLL7NDIuTxDk2lHaSo1IBAzvcQLQJRcWHTNalHYIRU1
 pCDDil/QPUE43jbbxpsSYFRpimciCQ==

DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=example.com;
 i=@example.com; q=dns/txt; s=test; t=1518064698; h=from :
 to : subject : date : message-id : from : subject : date;
 bh=4bLNXImK9drULnmePzZNEBleUanJCX5PIsDIFoH4KTQ=;
 b=IBZHsUwdU/NsqUAJ2mdNGbf/YIkDWc77wIMBXxRa+JJCfvTUW9eLylxq
 HqYi8SKwZ3u5JDnalh1YhJ8xbNVfAg==

DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=example.com;
 i=@example.com; q=dns/txt; s=test; t=1518064698; h=from :
 to : subject : date : message-id : from : subject : date;
 bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
 b=y+8dPwTZtEcxLGqb/3uVXEwp7Kd2ndscOKEkr5uowppsP5T5ptKdkFuM
 0iI0gU9TtGI8oO8JzbF91tR2w0kCDQ==

If someone can double check that one or more of those verify, then I think 
that'll work for examples.

Scott K

Hi.

We lost the game.  Are you hungry yet?

Joe.

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 11 Feb 2018 19:29:10 -0500

On Wednesday, February 07, 2018 11:43:42 PM Scott Kitterman wrote:
> Here are four signatures (different canonicalizations) of the attached
> message (take from the RFC 6376 examples) using the RFC 8032 section 7.1
> keys.
>
...
> that'll work for examples.

FYI, you can ignore these.  I generated them with the wrong key.  I'll send a 
correction once Jeremy can verify I didn't mess it up this time.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 25 Feb 2018 01:43:09 -0800

Scott or Jeremy,

Do you happen to have the sample key and message you used to generate these
in a file I can easily grab for testing an OpenDKIM revision that supports
the new key type?

-MSK

On Wed, Feb 7, 2018 at 8:43 PM, Scott Kitterman <[email-masked]>
wrote:

> message