IETF Logo Mail Archive

Re: [lamps] On the need for standardization of software-based interoperable private keys [was: Re: draft-ietf-lamps-samples: PKCS12 expertise needed (including objects for comparison)]

Michael Richardson <mcr+ietf@sandelman.ca> Thu, 05 August 2021 17:14 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D0AC3A1A26 for <spasm@ietfa.amsl.com>; Thu, 5 Aug 2021 10:14:45 -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 JjFhK8EsqeCu for <spasm@ietfa.amsl.com>; Thu, 5 Aug 2021 10:14:40 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53B6C3A195F for <spasm@ietf.org>; Thu, 5 Aug 2021 10:14:40 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 9A463389B3; Thu, 5 Aug 2021 13:18:58 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id SWZMfjPbbIxi; Thu, 5 Aug 2021 13:18:55 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 169F1389B0; Thu, 5 Aug 2021 13:18:55 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 5A85A963; Thu, 5 Aug 2021 13:14:35 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Ryan Sleevi <ryan-ietf@sleevi.com>, Carl Wallace <carl@redhoundsoftware.com>, SPASM <spasm@ietf.org>
In-Reply-To: <CAErg=HFgA6DA0CKfjOOY8JhmxaTuVNUfvxWZSzTp-1tRu8NN9w@mail.gmail.com>
References: <87czr0ww0d.fsf@fifthhorseman.net> <FF939B28-528B-47F9-9C0C-6585D1B02FBE@vigilsec.com> <87mtq3ukk0.fsf@fifthhorseman.net> <CAErg=HHQMZ1jk+bVxA=MzVvW+9ucie7bu-N6O8Asnp0V8Rf9Bg@mail.gmail.com> <30546.1627850836@localhost> <CAErg=HHKL-E5yT0UnPKcLfMQU41iDg7GGgjsSXs3eRg8daJRkg@mail.gmail.com> <87wnp347iu.fsf@fifthhorseman.net> <1388.1627996026@localhost> <87pmuu42hf.fsf@fifthhorseman.net> <20862.1628113377@localhost> <656985A5-BED4-4BA8-9233-B3C93966016C@ll.mit.edu> <877dh03x35.fsf@fifthhorseman.net> <722a1f15-8ac8-54f2-3c7a-14c7ed92c6ef@cs.tcd.ie> <SA2PR22MB2537BB784F2327052238317FE8F29@SA2PR22MB2537.namprd22.prod.outlook.com> <FAEBE63D-1CCC-4F76-B064-BD2DD4F02357@redhoundsoftware.com> <f0ac754b-18c4-8fdb-fff3-4d8675a9cefb@sandelman.ca> <156EE38A-6688-435C-9191-8D577EDCA251@redhoundsoftware.com> <9843.1628180697@localhost> <2213A8F8-D7DA-458A-96A8-1EC9A43FE900@redhoundsoftware.com> <CAErg=HFgA6DA0CKfjOOY8JhmxaTuVNUfvxWZSzTp-1tRu8NN9w@mail.gmail.com>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.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-sha512"; protocol="application/pgp-signature"
Date: Thu, 05 Aug 2021 13:14:35 -0400
Message-ID: <23882.1628183675@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/NnccYGrHR0KV_wnE_g6pTUnQxlk>
Subject: Re: [lamps] On the need for standardization of software-based interoperable private keys [was: Re: draft-ietf-lamps-samples: PKCS12 expertise needed (including objects for comparison)]
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." <spasm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spasm>, <mailto:spasm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spasm/>
List-Post: <mailto:spasm@ietf.org>
List-Help: <mailto:spasm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spasm>, <mailto:spasm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Aug 2021 17:14:45 -0000

Ryan Sleevi <ryan-ietf@sleevi.com> wrote:
    > specification side, and doesn't really address the implementation problem
    > of needing to support, for better or worse, existing keys. That is, it
    > seems we'll still have legacy producing bad-legacy, and then we'll have new
    > producing new-good, but implementations will end up needing to support both
    > paths, because in order for folks to adopt new-good, they'll want to bring
    > things in from old-legacy.

But, bad-legacy -> new-good could be done by a separate executable/tool.

With a very small attack surface, such that it would be less concerned about
tracking latest code.
It could be statically linked against libraries that were specifically "broken"

(Sadly, not something we'd want as a web service...  So really must be
provided by OS vendor to be ubiquitous enough)

--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

v2.23.0 | Report a Bug | By Email