From nobody Fri Dec 1 08:19:27 2017 Return-Path: X-Original-To: dcrup@ietf.org Delivered-To: dcrup@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DFF2E126C2F; Fri, 1 Dec 2017 08:19:24 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dcrup@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.66.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151214516486.1291.13097907887882547592@ietfa.amsl.com> Date: Fri, 01 Dec 2017 08:19:24 -0800 Archived-At: Subject: [Dcrup] I-D Action: draft-ietf-dcrup-dkim-crypto-07.txt X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Dec 2017 16:19:25 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DKIM Crypto Update WG of the IETF. Title : A new cryptographic signature method for DKIM Author : John Levine Filename : draft-ietf-dcrup-dkim-crypto-07.txt Pages : 5 Date : 2017-12-01 Abstract: DKIM was designed to allow new cryptographic algorithms to be added. This document adds a new signing algorithm. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dcrup-dkim-crypto/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dcrup-dkim-crypto-07 https://datatracker.ietf.org/doc/html/draft-ietf-dcrup-dkim-crypto-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dcrup-dkim-crypto-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Dec 1 11:45:56 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E726127444 for ; Fri, 1 Dec 2017 11:45:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wZeR1uV4uiJy for ; Fri, 1 Dec 2017 11:45:52 -0800 (PST) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3320A124D85 for ; Fri, 1 Dec 2017 11:45:52 -0800 (PST) Received: by mail-qk0-x22c.google.com with SMTP id c13so14638582qke.2 for ; Fri, 01 Dec 2017 11:45:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=k2Y6frieA854s9n7QsfApPks21ZkN7Mvpb2F40EI9uY=; b=pEJjLdlvGJxrXUHuxi3NmrTC3/DIzdyPZvN1dbZvM76Usny4G1PWPaZmlprMoMb4BK 6kphOSaFSVvrIqo4N4Rr+LhiSNOH0v1Ck6rpauidq9KXvS8NCvcKRheRlvhiV0SmcAGE 58uuOa3vJGUsXjn4PMepLOnWq3pLwPdhGLxVGLkxI59QqnnBGls9x+VUIrN7gwu3pdcL Gnt+m0x9G4LS18Dg8omXYgRl7lsINhZZCkgKMvOqc62stnGcSAw1KSDHxfB7Y4UvcdP5 u7UPL7Vbi++PU62cpj7ND4OctOf/XZkwzogCTgzHOtz9hRSymVizXrYodTFDT5VPMQVq j+Vw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=k2Y6frieA854s9n7QsfApPks21ZkN7Mvpb2F40EI9uY=; b=BEJh5ugmf8sQwGjQraygHaKFL7LfTeYSTKhcxITUy5vGZO0qku9/8YrAO+pl/AQImd rwdnNZ0W4MdoNUbqjOPEdUND/EQ7lbz5O5AmOPRJra+hwjJ7zTb+zmTS0coVRK3brmr9 KNw5Vs6hMV35wseSBw8OMfIlbskgc8/myfidFSRJtX5cWRjFNmHiHG7hoTBMCLYcavtD l5Xl6skvvP1sultOvK/YmmBuEHqxKLZOTLHB6wcZtqjXQt6OCWYZftw4RQSrxRLWJhwg eR6cuRpP6IQCKjWvohIdwNj1AiS1INWjKbkLlmlCfqLpLK67rNG4A2LwnM/1euEm1vr+ cpCw== X-Gm-Message-State: AJaThX6cFU2CJ0HKVlImBHSMYufRIPp6DNPpgaHZeytIcdFGK5mCJ4Q1 58qld/bpK0fFyW/Wj0sH4fMdDeOwzlLtW+3oan19A9tt X-Google-Smtp-Source: AGs4zMYJS0U19u+i2SoM4A4OkaYDGgQboeAnxGaRCqEudc+9vAWuni0ln887FoFFCtGWku3n1VPta1YnwgOjHQiS0pY= X-Received: by 10.55.73.87 with SMTP id w84mr9687138qka.215.1512157551016; Fri, 01 Dec 2017 11:45:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.237.50.196 with HTTP; Fri, 1 Dec 2017 11:45:50 -0800 (PST) From: "Murray S. Kucherawy" Date: Fri, 1 Dec 2017 11:45:50 -0800 Message-ID: To: dcrup@ietf.org Content-Type: multipart/alternative; boundary="001a114a7394ac3f0a055f4c9df2" Archived-At: Subject: [Dcrup] Working Group Last Call for draft-ietf-dcrup-dkim-crypto X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Dec 2017 19:45:54 -0000 --001a114a7394ac3f0a055f4c9df2 Content-Type: text/plain; charset="UTF-8" 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. Of note here: OpenSSL has begun the work of developing the API functions that will be needed to add this to various implementations of DKIM. For details, see https://github.com/openssl/openssl/pull/4829. -MSK, DCRUP co-chair --001a114a7394ac3f0a055f4c9df2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Colleagues,

We hereby begin Working= Group Last Call for draft-ietf-dcrup-dkim-crypto, to end December 15th.=C2= =A0 Please review the document and post the (preferably at least somewhat d= etailed) results of your reviews to the list or to the chairs and author by= end of that day.=C2=A0 Assuming no major revisions or discussion are neede= d, we hope to have this shipped to Alexey by the beginning of the December = holidays.

Of note here: OpenSSL has begun the work of dev= eloping the API functions that will be needed to add this to various implem= entations of DKIM.=C2=A0 For details, see https://github.com/openssl/openssl/pull/4829.

-MSK, DCRUP co-chair
--001a114a7394ac3f0a055f4c9df2-- From nobody Fri Dec 1 15:57:36 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A868E126E64 for ; Fri, 1 Dec 2017 15:57:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=kitterman.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id McArdSzgE6wx for ; Fri, 1 Dec 2017 15:57:34 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 269A9124234 for ; Fri, 1 Dec 2017 15:57:34 -0800 (PST) Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 3DA8AC401BB for ; Fri, 1 Dec 2017 17:57:32 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1512172652; bh=9vs0Bjx6imMDK5Vi07Mj+G/uItvmoTib3Noisvub7Xs=; h=From:To:Subject:Date:In-Reply-To:References:From; b=mDZP8d1xjCBtUsKF687WJ/0jz/mMjAY8Qp5LTc60PIi1jXzo5wIkcbkMW6xeddD+5 vrqtc4/uRLAvtcP+J4Eag3tr/1JGLCKMDbDmeGjbprfGV20sknH6QOjkMZ+ssYlc2H mNhCzmcnVlzB9aRPLvLa4AfRgG/MK673uU3PScFM= From: Scott Kitterman To: dcrup@ietf.org Date: Fri, 01 Dec 2017 18:57:31 -0500 Message-ID: <2005843.OrHkAfkQ5T@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-133-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [Dcrup] Working Group Last Call for draft-ietf-dcrup-dkim-crypto X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Dec 2017 23:57:36 -0000 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 From nobody Mon Dec 18 09:42:45 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 798F6124B18 for ; Mon, 18 Dec 2017 09:42:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6CcnrVDrG8tB for ; Mon, 18 Dec 2017 09:42:42 -0800 (PST) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D9951200F1 for ; Mon, 18 Dec 2017 09:42:42 -0800 (PST) Received: by mail-qt0-x235.google.com with SMTP id a16so21015300qtj.3 for ; Mon, 18 Dec 2017 09:42:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=GRjNwzj8c9uSbvg29kSsAwlMLgl73e1cisHPN9FKgTg=; b=DdHHdnLHnkP2S41ErQji7sePX0E7PTJ52PBmgs8MMIjrDfndl87kRcvbc3MsBuUuzr 1GbRMzLDyHovz77KL0CJVyYqqQsArxNIiFDDjdPHG3gx3SqHicOjehJ+r+1aPJBoonjr hkj1bjqUyrt0eO8Zjnyiu1dmA9GB0dsQtwDxZtNqzvshDVSV2XQmb9lBHycg0C/YyGWO PHhiRj6j9EDrcru2THXqu7bR8RIVDZwPNtWi2oiR2ht9GQzFLeQOAWKQxAjKQUkVZZyX CDKw5aWiIMNP7dAePfxlhvTKI7X/DpGVZ3jnZe5XNe1+cqfdI/maqOupGUtuRjplbd75 lyKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=GRjNwzj8c9uSbvg29kSsAwlMLgl73e1cisHPN9FKgTg=; b=UxEDyPOvmtEvkVRpa+B09KgjtBF5+8XZdIbclZBpRi0r1BkkgsGfEgoTtFoDCSgLCd 11K+kCQR9CZY2JwJdNoMFm7IvgsJ0rt1vDz4QmgE3EOmq366yyzaFqqUHIf6lgXwHRgU KJLgIF7pmotjJlRtTgw9i5/cv0gylokrpV4OAXAZfSQE/QLRZ+Up6qdVGh7fazjv1F7S OJKfAC3HUa5VPbtC4ZKL5n3n3g+rk5QfieEXR+hDc3klGCd6TYMTkuJgiCfjv4xXlfdI qMv2arcKjBxnhxcCL5Wtw62BDGOpu/CG8PhEmT7k604WOzt9S0toWRsf1i/PFNkOY4B8 t1/A== X-Gm-Message-State: AKGB3mKFiPn8PsL88PMclg4qojpZXCF669Q9iunOFT3G8YpbJvK92KKm zGTO4FsVPj91jkyV7KVQF9QhqA7fBt6oO3LcnG1Q4g== X-Google-Smtp-Source: ACJfBots482ihHh8M5xSF0eNs17j91Wtx7FY2NjkvoQZCzAUHfAV8fWRw5a8n46/oWQPmNfkaFFqUur0uWHoSm0FkPs= X-Received: by 10.237.53.172 with SMTP id c41mr629487qte.191.1513618961463; Mon, 18 Dec 2017 09:42:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.237.33.1 with HTTP; Mon, 18 Dec 2017 09:42:40 -0800 (PST) In-Reply-To: <2005843.OrHkAfkQ5T@kitterma-e6430> References: <2005843.OrHkAfkQ5T@kitterma-e6430> From: "Murray S. Kucherawy" Date: Mon, 18 Dec 2017 09:42:40 -0800 Message-ID: To: Scott Kitterman Cc: dcrup@ietf.org Content-Type: multipart/alternative; boundary="001a1130c10285ffff0560a0e048" Archived-At: Subject: Re: [Dcrup] Working Group Last Call for draft-ietf-dcrup-dkim-crypto X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Dec 2017 17:42:44 -0000 --001a1130c10285ffff0560a0e048 Content-Type: text/plain; charset="UTF-8" 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 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 > --001a1130c10285ffff0560a0e048 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Colleagues,

WGLC has completed= and this is sadly the only feedback we received.=C2=A0 I will do a chair&#= 39;s review today, but it would be really helpful to have some more reviewe= rs to comment on this before we send it to Alexey.

Simultaneou= sly: John, your comments in reply to this?

-MSK


On Fri, Dec 1, 2017 at 3:57 PM, Scott Kitterman <sklist@kitterman.com<= /a>> 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-cryp= to,
> to end December 15th.=C2=A0 Please review the document and post the (p= referably
> at least somewhat detailed) results of your reviews to the list or to = the
> chairs and author by end of that day.=C2=A0 Assuming no major revision= s 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 implementatio= n).=C2=A0 I think
it is generally ready to go, but I have four comments:

1.=C2=A0 The existing RFC 6376 signature algorithms specify what to use for= hash-
alg.=C2=A0 That's missing from the Ed25519-SHA256 definition in section= 3.=C2=A0 As
implied by the name (and discussed on the list), the hash-alg should be
SHA256.=C2=A0 Recommend replacing the leading sentence phrase in section 3 = with:

The Ed25519-SHA256 Signing Algorithm computes a message hash as described i= n
Section 3.7=C2=A0 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.=C2=A0 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 not= e:

This is an additional DKIM signature algorithm added to Section 3.3 of
[RFC6376] as envisioned in Section 3.3.4 of [RFC6376].

3.=C2=A0 Private key storage format

Unlike RSA, Ed25519 does not appear to have a standardized textual format.= =C2=A0 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<= br> 5.1.5 private key generation processes.=C2=A0 This would provide a (slightl= y) 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.=C2=A0 Examples

It would be nice to have at least one signing example for implementers to u= se
to verify correctness.=C2=A0 I currently have either a signing bug or a
verification bug in my work and I'm not sure which.=C2=A0 If I had a kn= own 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

--001a1130c10285ffff0560a0e048-- From nobody Mon Dec 18 11:30:28 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20F75120454 for ; Mon, 18 Dec 2017 11:30:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.8 X-Spam-Level: X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id plI07bIgykB6 for ; Mon, 18 Dec 2017 11:30:25 -0800 (PST) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C09EC126CF6 for ; Mon, 18 Dec 2017 11:30:24 -0800 (PST) Received: by mail-qk0-x235.google.com with SMTP id r184so12071632qke.8 for ; Mon, 18 Dec 2017 11:30:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=rILWHGOx767NZuql/HQ47L35r/1E52Wwzbc57LEz/tc=; b=ZLXCspM+luh0QftE0c9Wxboqdx/4iKa13ilKn2Gjaz4EQk7Wyjfk3Oj0c2ri+JiDRU yFc6eTJWIj3h2H0BC8IMAJhFt+MKJCuzjY/7ol4CHPNS8swzMCM8YHqv4BzGbgtNqYKV ddGxdRFNF1Ju11qzB08QxF7uzp0R6VEfeSf16WvfSQBjhL/W8EwJcHwYHJr0LfNRfkCt DlKyhJtDaVeiiWjh+ktUVf/TebCTgOjkn9Ru70BUFn1zVDlvqsvkkK2/RFqIuIhmO6Jr /9ScY1ZP9mieMvEXWSJmEOYMZoLHT1WSfBMrJHFiZ8g0X/mWj2JuVoRa+nWehEpAqW0l 1S6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=rILWHGOx767NZuql/HQ47L35r/1E52Wwzbc57LEz/tc=; b=EeRUxQv9Q/cbDTNuNxKOX/hsKmlNSMfpzYngqJg7ny+2eZOjUMcTP+xytFeVq8ZZox XCM8/GMrhUL2WXvPJQkMzgWX4puTJELe5Vks3C3aSwtLQ4LmC/e/0maKfRRx6E/73NzT 0uBdgN8IEoqVdhO7adaIiz06uRfCLgR+OOs9lqrc4D9jjwFGmSPFFrWo80JYLabw32lb AXYxtRIrG9Q0N1RRng+w0C5ryQooijpjyOJFCYl1erQWaAWL21yWGKApwajeqbUY5wNg q/ZYh0cUxv4J4uadq69WTdipAIahgDKDRERz8H9/jckpdvFLoAFtsrMVrrxR74Dvw+04 0klw== X-Gm-Message-State: AKGB3mK9a7oNfgpgLyutfEuTk94AmqCf9FKFXXKf6OyOAslxGnGI3CEf 0ndePyeSGrmw2xnSaRCx8hoh606sI/xZ/UiupbWOqhJql7c= X-Google-Smtp-Source: ACJfBotvmUVYuxsVwv7dfMwCPsDvKtqEpCvPdJ+j72kW4XYLttsJyM3hV/CGvkxTccglVplFmHFbbSi+d5RY//kUkfo= X-Received: by 10.55.142.3 with SMTP id q3mr1285579qkd.276.1513625423587; Mon, 18 Dec 2017 11:30:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.45.16 with HTTP; Mon, 18 Dec 2017 11:30:03 -0800 (PST) In-Reply-To: References: <2005843.OrHkAfkQ5T@kitterma-e6430> From: Seth Blank Date: Mon, 18 Dec 2017 11:30:03 -0800 Message-ID: To: dcrup@ietf.org Content-Type: multipart/alternative; boundary="94eb2c0853fab240b70560a26126" Archived-At: Subject: Re: [Dcrup] Working Group Last Call for draft-ietf-dcrup-dkim-crypto X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Dec 2017 19:30:27 -0000 --94eb2c0853fab240b70560a26126 Content-Type: text/plain; charset="UTF-8" On Mon, Dec 18, 2017 at 9:42 AM, Murray S. Kucherawy wrote: > 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. > The document is sound to me, and I have only one tiny nit related to the final paragraphs in sections 4.1 and 4.2: 4.1: DKIM signatures identified as having been signed with historic algorithms (currently rsa-sha1) have permanently failed evaluation as discussed in [RFC6376] Section 3.9. 4.2: DKIM signatures with insufficient key sizes (currently rsa-sha256 with less than 1024 bits) have permanently failed evaluation as discussed in [RFC6376] Section 3.9. For "permanently failed evaluation" should it be explicitly mentioned that this requires a PERMFAIL response? As I said, a tiny nit... Seth -- [image: logo for sig file.png] Bringing Trust to Email Seth Blank | Director of Industry Initiatives seth@valimail.com +1-415-894-2724 <415-894-2724> --94eb2c0853fab240b70560a26126 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Dec 18, 2017 at 9:42 AM, Murray S. Kucherawy = <superuser@gmail.com> wrote:
WGLC has completed and this is s= adly the only feedback we received.=C2=A0 I will do a chair's review to= day, but it would be really helpful to have some more reviewers to comment = on this before we send it to Alexey.

The document is sound to me, a= nd I have only one tiny nit related to the final paragraphs in sections 4.1= and 4.2:

=C2=A0 =C2=A04.1:
=C2=A0 =C2=A0DKIM signatures identified as having been signed wi= th historic
=C2=A0 =C2=A0algorithms (curren= tly rsa-sha1) have permanently failed evaluation as
=C2=A0 =C2=A0discussed in [RFC6376] Section 3.9.

=C2=A0 =C2=A04.2:=
=C2=A0 =C2=A0DK= IM signatures with insufficient key sizes (currently rsa-sha256
=C2=A0 =C2=A0with less than 1024 bits) have permanentl= y failed evaluation as
=C2=A0 =C2=A0discuss= ed in [RFC6376] Section 3.9.

For "permanently failed evaluation" should it be explicitl= y mentioned that this requires a PERMFAIL response? As I said, a tiny nit..= .

Seth=

--

3D"logo<= /p>

Bringing Trust to Email

Seth Blank | Director of= Industry Initiatives

seth@valimail.com
+1-415-89= 4-2724
--94eb2c0853fab240b70560a26126-- From nobody Mon Dec 18 12:14:28 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36D6812D874 for ; Mon, 18 Dec 2017 12:14:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=kitterman.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gBSiM6SaSxKL for ; Mon, 18 Dec 2017 12:14:21 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8FAF124319 for ; Mon, 18 Dec 2017 12:14:21 -0800 (PST) Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id A351BC401CA for ; Mon, 18 Dec 2017 14:14:19 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1513628059; bh=98qw/uMx2AV7rC3pR74Ijo2tN5vijVSzQJwHSi5MiBk=; h=From:To:Subject:Date:In-Reply-To:References:From; b=jTZHTR+EjvWu01a+1VhCBmx0G92TA+wtquEyVtgSjfDDQtPddvV7Z/EZDmmau3vSn kWbw+xZ+8yTeG11RjGgD3sBcAb8QhVCi6e7N2VMWumfT241oXW5cctqSn3bVuOczAJ OyLb/ApwyVfRrPulb1tZxv303zymh5SZe+n8HNRM= From: Scott Kitterman To: dcrup@ietf.org Date: Mon, 18 Dec 2017 15:14:20 -0500 Message-ID: <2270822.kPNmBh82Ph@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-133-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [Dcrup] Working Group Last Call for draft-ietf-dcrup-dkim-crypto X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Dec 2017 20:14:26 -0000 On Monday, December 18, 2017 11:30:03 AM Seth Blank wrote: > On Mon, Dec 18, 2017 at 9:42 AM, Murray S. Kucherawy > > wrote: > > 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. > > The document is sound to me, and I have only one tiny nit related to the > final paragraphs in sections 4.1 and 4.2: > > 4.1: > DKIM signatures identified as having been signed with historic > algorithms (currently rsa-sha1) have permanently failed evaluation as > discussed in [RFC6376] Section 3.9. > > 4.2: > DKIM signatures with insufficient key sizes (currently rsa-sha256 > with less than 1024 bits) have permanently failed evaluation as > discussed in [RFC6376] Section 3.9. > > For "permanently failed evaluation" should it be explicitly mentioned that > this requires a PERMFAIL response? As I said, a tiny nit... > > Seth That's what the reference to RFC6376] Section 3.9 does. Scott K From nobody Mon Dec 18 12:29:03 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 974F412D86B for ; Mon, 18 Dec 2017 12:29:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.064 X-Spam-Level: X-Spam-Status: No, score=-0.064 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_28=0.726, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EKR-lrZ-tVOL for ; Mon, 18 Dec 2017 12:29:00 -0800 (PST) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 098D412D853 for ; Mon, 18 Dec 2017 12:28:58 -0800 (PST) Received: by mail-qk0-x230.google.com with SMTP id u184so19949941qkd.6 for ; Mon, 18 Dec 2017 12:28:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=y/xkLsCf8lSnnCw4ObxQIF7RewICuYLXaQVAeTDcu84=; b=Hh/fDwNX+Bxuqn49b2fbYTs19pCFthHP5dT9HfT4yiJSWHw/BVmtly1M3CTtZEzaBQ MG6J4kCVicTBu6GAAbNY1PHJONH4nCV+gkVnr67S14znSC6sG1CT/+PECb5TAlEiHEyP v1BJrgiWUe7ew9Lw/cbrRHbiM0ZYY4cXxdIOGxO9h059pNzQeTkelK0xzGu3zfMFNlAs E4k099/Yba15RZPBoRrZN+d6vJ/GcNJSKxqi1aAnz1ju+X0cBLpkYQmbNw6uba2DjFnM YGwOSebDQOSGS6NGFMzvbgDsr5IsRRtXSPiUz6RqujgS/TYTc57X25TL+4basLE2JD7z 9bag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=y/xkLsCf8lSnnCw4ObxQIF7RewICuYLXaQVAeTDcu84=; b=dSgeay2/1cBjTNKHALTiIjVmVEGhgGnW3YOYCc1y6wDMdN5D5fXG09Iuh7fOlYNUZx p9YNEjWiriF+t0S1SRMBA9+j43b6UaUt4XP9KJ+qcMLgnnJyIShKnEmHtSjLSMdx3rOt exlp2noARmBB3dsXUgZeUdyOn5CZp9ux4alkOVBiBCfx6dRNF2ajNbKxMHas6OtkrBe7 z8zH6h+EkbNu8yBk7PecNcC2PMKkoTzY5MqlmlO0Jb+Fm1ervII9jaq757Wy01r05DEA F8gCK42/aXL5bPD0fv8YK25KqyJMWTFUyDZIz+6zMeLlkvVDzHiRuMjfoVL9jatjzKnN L2ug== X-Gm-Message-State: AKGB3mIKMEHVuxN/RX7dyenV10vYUH2rjL7VFKNAVyPAIFTrGsXLUwgD zuJj6liC6HGDCxK7xfYyOLtTBy4Vdz7lRu7XBQ/nZgHl X-Google-Smtp-Source: ACJfBovlfAgAvUdUA5xEpGkMIRyZJ0I/STf5k7q9+cES77hIjai/uqLQ+VqndVJsf4p/cplDo+DntWt/FUV6CHNy4Uc= X-Received: by 10.55.19.73 with SMTP id d70mr964669qkh.180.1513628936715; Mon, 18 Dec 2017 12:28:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.45.16 with HTTP; Mon, 18 Dec 2017 12:28:36 -0800 (PST) In-Reply-To: <2270822.kPNmBh82Ph@kitterma-e6430> References: <2270822.kPNmBh82Ph@kitterma-e6430> From: Seth Blank Date: Mon, 18 Dec 2017 12:28:36 -0800 Message-ID: To: dcrup@ietf.org Content-Type: multipart/alternative; boundary="001a11400e761858ff0560a33352" Archived-At: Subject: Re: [Dcrup] Working Group Last Call for draft-ietf-dcrup-dkim-crypto X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Dec 2017 20:29:01 -0000 --001a11400e761858ff0560a33352 Content-Type: text/plain; charset="UTF-8" On Mon, Dec 18, 2017 at 12:14 PM, Scott Kitterman wrote: > That's what the reference to RFC6376] Section 3.9 does. Yes, that was what my nit was about. Right now, following the reference you still need to infer that PERMFAIL is the appropriate response, and the question was if it needs to be explicitly stated in conjunction with the reference. "No" is a perfectly acceptable response. -- [image: logo for sig file.png] Bringing Trust to Email Seth Blank | Director of Industry Initiatives seth@valimail.com +1-415-894-2724 <415-894-2724> --001a11400e761858ff0560a33352 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On M= on, Dec 18, 2017 at 12:14 PM, Scott Kitterman <sklist@kitterman.com= > wrote:
That's what the re= ference to RFC6376] Section 3.9 does.

Yes, that was what my nit was = about. Right now, following the reference you still need to infer that PERM= FAIL is the appropriate response, and the question was if it needs to be ex= plicitly stated in conjunction with the reference. "No" is a perf= ectly acceptable response.


--

=3D"logo

Bringing Tr= ust to Email

Seth Blank | Director of Industry Initiat= ives

seth@valimail.com
+1-415-894-2724=
--001a11400e761858ff0560a33352-- From nobody Mon Dec 18 12:58:00 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BCCE120713 for ; Mon, 18 Dec 2017 12:57:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=kitterman.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K87yuGLPmZkp for ; Mon, 18 Dec 2017 12:57:57 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 256AA1200FC for ; Mon, 18 Dec 2017 12:57:57 -0800 (PST) Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 1275EC4025F for ; Mon, 18 Dec 2017 14:57:56 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1513630676; bh=WlDvhCk1FOlb9rUGvWL1bqaJ4IYMYgTvejmeURxG87s=; h=From:To:Subject:Date:In-Reply-To:References:From; b=pFZ2LVFi4Qp1ZLkzAWiYr4KypWp5v0akLEckz9qwuhbxl8EPVPhGVdDrmoD4YvjDg 51F8vFvBR+0iEPTU28lhzomI1wU04v82+wd/Q4eU5Ht//NLYq63xaLFir2bh3Gyd8O qlzzSz/EBiwYnzAqz8NTAV2aQS6IG+I3aHGD4/aU= From: Scott Kitterman To: dcrup@ietf.org Date: Mon, 18 Dec 2017 15:57:56 -0500 Message-ID: <5898513.HCQYKTO1iX@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-133-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: References: <2270822.kPNmBh82Ph@kitterma-e6430> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [Dcrup] Working Group Last Call for draft-ietf-dcrup-dkim-crypto X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Dec 2017 20:57:58 -0000 On Monday, December 18, 2017 12:28:36 PM Seth Blank wrote: > On Mon, Dec 18, 2017 at 12:14 PM, Scott Kitterman > > wrote: > > That's what the reference to RFC6376] Section 3.9 does. > > Yes, that was what my nit was about. Right now, following the reference you > still need to infer that PERMFAIL is the appropriate response, and the > question was if it needs to be explicitly stated in conjunction with the > reference. "No" is a perfectly acceptable response. OK. That's copy/pasted from the -update draft that's been through IETF last call/IESG approval already, so I'd go with "No" then. Scott K From nobody Mon Dec 18 16:27:01 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FDB2126E3A for ; Mon, 18 Dec 2017 16:26:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UtJ3JLIoHlot for ; Mon, 18 Dec 2017 16:26:56 -0800 (PST) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1139127010 for ; Mon, 18 Dec 2017 16:26:56 -0800 (PST) Received: by mail-qt0-x22b.google.com with SMTP id w10so22245359qtb.10 for ; Mon, 18 Dec 2017 16:26:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Hgz6hexXy+yF/knfPyv0N5erXvskJbnKirQ0TtSDBRE=; b=BLhDeiYxQrQtgi7UmV3WFI766lr1FDnlki1L4JE0funVc9EkjkLN6ZvJjW/LEgylay bzNp3nGlTdAs5zLnOicLWZDIuowbzp1ZI1hKpbe/1k5kzRHyVJNAZMGZOQ34zYz/hY31 sXnTwcSGwat/KTr9dVovG81KNIkVVq4uNVwYaQ09PbQ3/PLp5DfYsq2K8NtLUrsl33D7 ijsnG7A1FCn6M0880p9Yz2MrRzTn4bcfpq10DmaeYun5q9kg7VYn/5Kaex59RoTRqOhv kpO70VaaDfEHhz8Oxmmg3zIDMoAULmFiDlu20WUMAVlk7R8oqCeAAEiDYaU9ZD5nVXI8 6lHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Hgz6hexXy+yF/knfPyv0N5erXvskJbnKirQ0TtSDBRE=; b=UfhOWSlJl41gm+QWVRFohoE++tWi2PWtwFe8J3DtZbWDCLtubf4pJzkS0tyMWdLABp LfUIxA46H8TjSz0OE2S9U+lMhk2Ypaqr0IIwCIWCUzSR6xwL6G1ciGpDAora/54X6Tu+ +g0yv5grnQiDg2F0fiVrf3PP9RR4q/j72PYmDT6euo8ZJ7Gwa9SyaaxY9lDIufsUAgtp 9YDHmEHWITO1k+ElClZ36euocYQKRVE/s8+F8bHAaTtBWodNzJmxaBa0HG/wtx6V8auI XOpOTEJ8PfdfoIc6VWdoeh8V2JJBb/Ccu/VBiv9/fvOWd1Y6h2cSsSz7vrwmyf8GV5hS Tajg== X-Gm-Message-State: AKGB3mKurfVFL5L5myMb11lvh/IiOCHKlBvcqeRT2V6YpkYNd5lPVKhr C8bS4HVgOn9CR6dr5Qwi8X0wPVanaY2qnvFJX+hOSA== X-Google-Smtp-Source: ACJfBovC1JaiqeCkRLHz9XrsG4o9MyPouKea/28NCVkYIxCiBPEgnurj04tbUvrN5f2ZKqK+E5rJWR1zl5TJhulTKZU= X-Received: by 10.200.37.3 with SMTP id 3mr2272992qtm.21.1513643215636; Mon, 18 Dec 2017 16:26:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.237.33.1 with HTTP; Mon, 18 Dec 2017 16:26:55 -0800 (PST) In-Reply-To: <5898513.HCQYKTO1iX@kitterma-e6430> References: <2270822.kPNmBh82Ph@kitterma-e6430> <5898513.HCQYKTO1iX@kitterma-e6430> From: "Murray S. Kucherawy" Date: Mon, 18 Dec 2017 16:26:55 -0800 Message-ID: To: Scott Kitterman Cc: dcrup@ietf.org Content-Type: multipart/alternative; boundary="001a1140333e2f4d9a0560a686a8" Archived-At: Subject: Re: [Dcrup] Working Group Last Call for draft-ietf-dcrup-dkim-crypto X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Dec 2017 00:26:59 -0000 --001a1140333e2f4d9a0560a686a8 Content-Type: text/plain; charset="UTF-8" On Mon, Dec 18, 2017 at 12:57 PM, Scott Kitterman wrote: > On Monday, December 18, 2017 12:28:36 PM Seth Blank wrote: > > On Mon, Dec 18, 2017 at 12:14 PM, Scott Kitterman > > > > wrote: > > > That's what the reference to RFC6376] Section 3.9 does. > > > > Yes, that was what my nit was about. Right now, following the reference > you > > still need to infer that PERMFAIL is the appropriate response, and the > > question was if it needs to be explicitly stated in conjunction with the > > reference. "No" is a perfectly acceptable response. > > OK. That's copy/pasted from the -update draft that's been through IETF > last > call/IESG approval already, so I'd go with "No" then. > This document has been through neither of those processes yet. Are you thinking of the usage document? -MSK --001a1140333e2f4d9a0560a686a8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Dec 18, 2017 at 12:57 PM, Scott Kitterman <skl= ist@kitterman.com> wrote:
On Mo= nday, December 18, 2017 12:28:36 PM Seth Blank wrote:
> On Mon, Dec 18, 2017 at 12:14 PM, Scott Kitterman <sklist@kitterman.com>
>
> wrote:
> > That's what the reference to RFC6376] Section 3.9 does.
>
> Yes, that was what my nit was about. Right now, following the referenc= e you
> still need to infer that PERMFAIL is the appropriate response, and the=
> question was if it needs to be explicitly stated in conjunction with t= he
> reference. "No" is a perfectly acceptable response.

OK.=C2=A0 That's copy/pasted from the -update draft that's b= een through IETF last
call/IESG approval already, so I'd go with "No" then.

This document has been through neither of thos= e processes yet.=C2=A0 Are you thinking of the usage document?

-MSK
--001a1140333e2f4d9a0560a686a8-- From nobody Mon Dec 18 17:09:21 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82DC31267BB for ; Mon, 18 Dec 2017 17:09:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=kitterman.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09Zd3f006F55 for ; Mon, 18 Dec 2017 17:09:19 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16099124F57 for ; Mon, 18 Dec 2017 17:09:19 -0800 (PST) Received: from [192.168.1.115] (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id D59D8C4025F; Mon, 18 Dec 2017 19:09:17 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1513645757; bh=5bZtx32qODcCvnoSzv/ZlCLDnBDUATGqbLNlaUHL9DM=; h=Date:In-Reply-To:References:Subject:To:From:From; b=dxt+Md0R6wC8M5jUGl9xAy3to+1HeNu9ogJTCxSgHAfcgedUSbz74TsNZhtfzBqcn odmRX8+sqm/bokVkaUVM6YweuwyCoJRKFEi3+seu9leQeK0nvGQpMgkr5Xh0js5/E5 nCDcPtRwLwsXDtByFprXhpT3Xcc2OR6+cpOMqPWs= Date: Tue, 19 Dec 2017 01:08:06 +0000 In-Reply-To: References: <2270822.kPNmBh82Ph@kitterma-e6430> <5898513.HCQYKTO1iX@kitterma-e6430> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: dcrup@ietf.org From: Scott Kitterman Message-ID: Archived-At: Subject: Re: [Dcrup] Working Group Last Call for draft-ietf-dcrup-dkim-crypto X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Dec 2017 01:09:20 -0000 On December 18, 2017 7:26:55 PM EST, "Murray S=2E Kucherawy" wrote: >On Mon, Dec 18, 2017 at 12:57 PM, Scott Kitterman > >wrote: > >> On Monday, December 18, 2017 12:28:36 PM Seth Blank wrote: >> > On Mon, Dec 18, 2017 at 12:14 PM, Scott Kitterman > >> > >> > wrote: >> > > That's what the reference to RFC6376] Section 3=2E9 does=2E >> > >> > Yes, that was what my nit was about=2E Right now, following the >reference >> you >> > still need to infer that PERMFAIL is the appropriate response, and >the >> > question was if it needs to be explicitly stated in conjunction >with the >> > reference=2E "No" is a perfectly acceptable response=2E >> >> OK=2E That's copy/pasted from the -update draft that's been through >IETF >> last >> call/IESG approval already, so I'd go with "No" then=2E >> > >This document has been through neither of those processes yet=2E Are you >thinking of the usage document? > >-MSK Sort of=2E The language is identical to how we did it in the usage docume= nt (which has made it through those hurdles), so I think this document shou= ld stay consistent with it=2E Scott K From nobody Mon Dec 18 17:43:29 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 790FA12D95C for ; Mon, 18 Dec 2017 17:43:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.76 X-Spam-Level: X-Spam-Status: No, score=-1.76 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=wknMbPaD; dkim=pass (1536-bit key) header.d=taugh.com header.b=LasfPGWu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uMspyB1D1TiH for ; Mon, 18 Dec 2017 17:43:25 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5D0E12D88A for ; Mon, 18 Dec 2017 17:43:24 -0800 (PST) Received: (qmail 24756 invoked from network); 19 Dec 2017 01:43:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=60b2.5a386ebb.k1712; bh=jqAJIlEoZlUO1M/l5qWlGWDSgvTxTmRw1lfkeXGoc4A=; b=wknMbPaDa7PFYhAxNpN5Dx/sUh8dizJKhdMaz9JsTZPkrCtUW875VlYm9Bb9Q/aDJiWacuvYPmqixDi0kYe9xrMfkw4qD/id9q5nlSdNv5q+K1JVA+/DykYsyvMpE+u+DFziPcBED9WharoZ4WfGSmveYnr/BUz/g4CR4mIjE/Nk6XzbipttzxSvNC+q+YdFJQoVgskb+g8ljGcl2eUJv1Mcy1+ZDGeYTw68v4o+VvgPYWUH1BqvsbQYkxWLxURO DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=60b2.5a386ebb.k1712; bh=jqAJIlEoZlUO1M/l5qWlGWDSgvTxTmRw1lfkeXGoc4A=; b=LasfPGWuuWQ7N1qg87zY2tQdcEKUWiVoxDffOA8jHNhjbkodDg8fABLI+QXnimmYL8YNADq9FQEQczfS1w4c4k2AFFxhilcGuhg4t6AOC+N39v4dCNR/nSCXUBfIg64TR3P3wy64BLQEXIrxy4RILiIjafea1zl/8SMvkZ/FQxXeWw4NQnTdsWfB1I6408YB0m4eKDgsYgn0ysllyg2wxFbYXTpwPIy1lnzhcEHG1Z+zbLSYqXlSm4GzI54XYFUp Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 19 Dec 2017 01:43:23 -0000 Received: by ary.qy (Postfix, from userid 501) id 32C181823BFF; Mon, 18 Dec 2017 20:43:22 -0500 (EST) Date: 18 Dec 2017 20:43:22 -0500 Message-Id: <20171219014323.32C181823BFF@ary.qy> From: "John Levine" To: dcrup@ietf.org Cc: superuser@gmail.com In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Dcrup] Working Group Last Call for draft-ietf-dcrup-dkim-crypto X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Dec 2017 01:43:26 -0000 >Simultaneously: John, your comments in reply to this? >> 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, That's fine. >> 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]. Also fine. >> 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. OK by me but I'm no crypto expert. Perhaps we could ask the openssl folks what key format they'll be using. >> 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. A reasonable albeit somewhat painful request. What ed25519 library are you using? R's, John -- Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly From nobody Mon Dec 18 17:54:41 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3BBB12D95C for ; Mon, 18 Dec 2017 17:54:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=kitterman.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0yzf__8js1r7 for ; Mon, 18 Dec 2017 17:54:34 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 833F11201FA for ; Mon, 18 Dec 2017 17:54:34 -0800 (PST) Received: from [192.168.1.115] (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 2EF79C401CA; Mon, 18 Dec 2017 19:54:33 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1513648473; bh=vmGcx7FdElZNSwZKGAkKQiCMCBC1IQxnpb2onb4Atek=; h=Date:In-Reply-To:References:Subject:To:From:From; b=dROu4QKPZ26pYrIK6soDSCkinCT0dmnw13+TtLsZhMf36hDzHMVuvoZCBrwbCdYtE sr9b6iHhh3U12bqzbITXdKiq+0rkFG7UTe+W6esBxUOcHqib+//QrZ4fIA/gull3vz kdWYoYDm+V17SaPp+uESPwam/o+8aLo6mxGkvIVI= Date: Tue, 19 Dec 2017 01:54:18 +0000 In-Reply-To: <20171219014323.32C181823BFF@ary.qy> References: <20171219014323.32C181823BFF@ary.qy> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: dcrup@ietf.org From: Scott Kitterman Message-ID: <699233B0-E777-45F5-A8B3-4805029B21FB@kitterman.com> Archived-At: Subject: Re: [Dcrup] Working Group Last Call for draft-ietf-dcrup-dkim-crypto X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Dec 2017 01:54:40 -0000 On December 18, 2017 8:43:22 PM EST, John Levine wrote= : >>Simultaneously: John, your comments in reply to this? > >>> 1=2E The existing RFC 6376 signature algorithms specify what to use >for >>> hash- >>> alg=2E That's missing from the Ed25519-SHA256 definition in section >3=2E As >>> implied by the name (and discussed on the list), the hash-alg should >be >>> SHA256=2E Recommend replacing the leading sentence phrase in section >3 with: >>> >>> The Ed25519-SHA256 Signing Algorithm computes a message hash as >described >>> in >>> Section 3=2E7 of [RFC6376] using SHA-256 [FIPS-180-3-2008] as the >hash-alg, > >That's fine=2E > >>> 2=2E 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=2E3 >of >>> [RFC6376] as envisioned in Section 3=2E3=2E4 of [RFC6376]=2E > >Also fine=2E > >>> 3=2E Private key storage format >>> >>> Unlike RSA, Ed25519 does not appear to have a standardized textual >>> format=2E 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=2E1=2E5 private key generation processes=2E 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=2E > >OK by me but I'm no crypto expert=2E Perhaps we could ask the openssl >folks what >key format they'll be using=2E > >>> 4=2E Examples >>> >>> It would be nice to have at least one signing example for >implementers to >>> use to verify correctness=2E I currently have either a signing bug or >a >>> verification bug in my work and I'm not sure which=2E If I had a >known >>> correct example to bounce my signing results against, that would >help a lot=2E > >A reasonable albeit somewhat painful request=2E What ed25519 library are >you using? I'm using python-nacl, which wraps libsodium=2E https://pynacl=2Ereadthedocs=2Eio/en/stable/ https://download=2Elibsodium=2Eorg/doc/ Scott K