Re: [Secdispatch] Deterministic generation of public key pairs

Michael Richardson <mcr+ietf@sandelman.ca> Wed, 11 March 2020 17:16 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: secdispatch@ietfa.amsl.com
Delivered-To: secdispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 771093A0E8C for <secdispatch@ietfa.amsl.com>; Wed, 11 Mar 2020 10:16:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 zFk6TynqrF3c for <secdispatch@ietfa.amsl.com>; Wed, 11 Mar 2020 10:16:08 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15CF63A0E8A for <secdispatch@ietf.org>; Wed, 11 Mar 2020 10:16:06 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id D0DD038986; Wed, 11 Mar 2020 13:14:48 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 9FDCEAE8; Wed, 11 Mar 2020 13:16:01 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Phillip Hallam-Baker <phill@hallambaker.com>
cc: IETF SecDispatch <secdispatch@ietf.org>
In-Reply-To: <CAMm+LwgVoRW7fcYxjhZS3jXBwgTX0Dgk5E1oGKdwrnNHVwU=1Q@mail.gmail.com>
References: <CAMm+LwhDvpN93TeQYcH07Sgi7xU18MLq8vrb7Azesrc6kvnxXg@mail.gmail.com> <13723.1583861278@localhost> <CAMm+LwgVoRW7fcYxjhZS3jXBwgTX0Dgk5E1oGKdwrnNHVwU=1Q@mail.gmail.com>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 25.1.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature"
Date: Wed, 11 Mar 2020 13:16:01 -0400
Message-ID: <30287.1583946961@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdispatch/f4qvW6B2oxqAXrMEqBRhNqx9DR8>
Subject: Re: [Secdispatch] Deterministic generation of public key pairs
X-BeenThere: secdispatch@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Dispatch <secdispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdispatch>, <mailto:secdispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdispatch/>
List-Post: <mailto:secdispatch@ietf.org>
List-Help: <mailto:secdispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdispatch>, <mailto:secdispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Mar 2020 17:16:14 -0000

Phillip Hallam-Baker <phill@hallambaker.com> wrote:
    >> Phillip Hallam-Baker <phill@hallambaker.com> wrote: > udf config
    >> ssh-agent ZAAA-FFQA-3LE5-SAHG-E6K6-HOTN-TVLB-K4A
    >>
    >> > This is a seed that can be written down and can be used to generate
    >> a > private keypair using any of the commonly used public key
    >> algorithms. So > you can use it for any application where you would
    >> use traditional key > escrow.
    >>
    >> > One thing I use this for is to move S/MIME and PGP keys about. Can
    >> also use > it to keep a paper back up of whole disk encryption keys
    >> etc.
    >>
    >> > The spec (but not the tool yet) also supports Shamir Secret Sharing.
    >> I need > to rejig that to match the developments in the threshold
    >> spec.
    >>
    >>
    >> > So is this something we should do and if so where? This is separable
    >> from > the Mesh and does have some functionality overlap. But it also
    >> makes a lot > of common sysadmin config much easier.
    >>
    >> I think AD sponsorship for the entire UDF document.  (Not just the
    >> deterministic key generation part. or was that part of your goal?)
    >>

    > I would like to do the whole doc can drop Secure Internet Names which
    > are a bit on the edge. The digest function parts could be bikeshedded
    > of course but probably not usefully.

okay, we agree that the whole document should go as a single thing.

    >> A better name is needed, as there has been snakeoil created that had a
    >> similar name.

    > I am OK with the IETF calling it anything people like except for Fred.

    > If isn't really a fingerprint format at this point either.

It was specifically the Deterministic Generation of Public Key Pairs that I
think matches some decade-old snake oil.  I will google a bit to see if I can
find that.
Some variation on "Portable Privacy" might be the right direction.

I think that this Beauty Contest is the only important thing left to do with
the document :-), which I guess says something how mature I think it is.

I've had an offline 1024-bit RSA key root@sandelman.ca in a secure place
six different generations of media for 25 years.
Clearly, it's now too weak to bother with.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [


--
Michael Richardson <mcr+IETF@sandelman.ca>ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-