Re: [secdir] secdir review of draft-moonesamy-sshfp-ed25519-01

Dick Franks <rwfranks@acm.org> Sat, 31 May 2014 01:28 UTC

Return-Path: <rwfranks@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B43EC1A06CC; Fri, 30 May 2014 18:28:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level:
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
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 RwhFBOviXKkW; Fri, 30 May 2014 18:28:41 -0700 (PDT)
Received: from mail-yh0-x22d.google.com (mail-yh0-x22d.google.com [IPv6:2607:f8b0:4002:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A6CD1A043C; Fri, 30 May 2014 18:28:41 -0700 (PDT)
Received: by mail-yh0-f45.google.com with SMTP id b6so2240895yha.32 for <multiple recipients>; Fri, 30 May 2014 18:28:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=aRCb01XuyhkZExgBJkKMWSfwE4yQraAgu8kT+s91Cw4=; b=ls8k9jGdvs8xtoiBx6JIQMqqIQ532VLSEHDUgIjnBTt35sUT8iPkWjua48ywD7i4fV v7ahYTj+UcDavcVTF3TDFxw2XbJTGT0otqVd70v7IOVuH9N+jd61KYwWqmvrjp/kjG0F teVeUknzQGHmhw0hdpp9kJ8iasjjC0ITHwQFEG9vtfFLVjyjysL3akb6Q7PB+lhGSGEo i45T2j9h0QL6zJ5O9HUchKMJMPM0vKuNJv1P6YxV9mXqjlZr3bYHtLhtwHCUhQI22Rwv dGvWDuk0KSksjHmQHwIibae7Ed0X6K9n50yfUEFTmtxV4g5fvYprp0lQBt4Hiz+v6ttc 7RJg==
X-Received: by 10.236.124.237 with SMTP id x73mr26051618yhh.137.1401499716550; Fri, 30 May 2014 18:28:36 -0700 (PDT)
MIME-Version: 1.0
Sender: rwfranks@gmail.com
Received: by 10.170.197.193 with HTTP; Fri, 30 May 2014 18:27:56 -0700 (PDT)
In-Reply-To: <6.2.5.6.2.20140530154830.0c7a8d38@elandnews.com>
References: <2ACBFFE4-BCEB-4F6D-A2D3-861BADF543DE@cisco.com> <6.2.5.6.2.20140530040300.0bb93070@elandnews.com> <D1342262-144C-4939-B005-5E042CAF7394@cisco.com> <20140530141618.kgnw4u9b4gw80o4s@webmail.mit.edu> <6.2.5.6.2.20140530114625.0c0d1aa8@elandnews.com> <868A3427-6B46-4110-8D4B-45857D260C1D@cisco.com> <6.2.5.6.2.20140530135131.0c7bdba0@elandnews.com> <53890957.3090407@tolerantnetworks.com> <6.2.5.6.2.20140530154830.0c7a8d38@elandnews.com>
From: Dick Franks <rwfranks@acm.org>
Date: Sat, 31 May 2014 02:27:56 +0100
X-Google-Sender-Auth: d7ZoBlr9G2TZLsTnYn-agqZahDo
Message-ID: <CAKW6Ri4AJxVjaQJMAOgkO-OfU8KgzauNZz2z+yg=L2RmoNdnbA@mail.gmail.com>
To: S Moonesamy <sm+ietf@elandsys.com>
Content-Type: multipart/alternative; boundary=20cf303a332bc204fa04faa81498
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/lLdi1ALu5MTr-VVxwHbRUbFVbBQ
X-Mailman-Approved-At: Sat, 31 May 2014 06:23:53 -0700
Cc: Stephen Farrell <stephen@tolerantnetworks.com>, IETF Discussion <ietf@ietf.org>, secdir@ietf.org, draft-moonesamy-sshfp-ed25519.all@tools.ietf.org, iesg@ietf.org
Subject: Re: [secdir] secdir review of draft-moonesamy-sshfp-ed25519-01
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 31 May 2014 01:28:44 -0000

On 31 May 2014 01:18, S Moonesamy <sm+ietf@elandsys.com> wrote:

> Hi Stephen,
> At 15:42 30-05-2014, Stephen Farrell wrote:
>
>> Why? Why not just look at the code and write down what that does
>> in terms of formatting the input.
>>
>> If >1 implementation interoperates it can't be that hard.
>>
>
> I had some private discussions about what the source code does to see how
> to turn that into a specification.  The conclusion was that it would be
> non-trivial to write down something acceptable to the IETF.


If it is non-trivial to extract the data format from the code, it is
essential that it be included here or incorporated by reference to a freely
available public document.


 If it was not that hard everybody would be able to do it. :-)


:-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(
:-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(
:-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(
:-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(
:-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(
:-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(
:-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(
:-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(
:-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(
:-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(
:-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(
:-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(