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 16:27 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 0BB293A1865 for <spasm@ietfa.amsl.com>; Thu, 5 Aug 2021 09:27:19 -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 dy1ficH4eOO3 for <spasm@ietfa.amsl.com>; Thu, 5 Aug 2021 09:27:14 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 116FD3A185E for <spasm@ietf.org>; Thu, 5 Aug 2021 09:27:14 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 869A4389C4; Thu, 5 Aug 2021 12:31:31 -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 3fHV6uvX9QOV; Thu, 5 Aug 2021 12:31:28 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 27F3D389C3; Thu, 5 Aug 2021 12:31:28 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 88B84963; Thu, 5 Aug 2021 12:27:08 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: "Salz, Rich" <rsalz=40akamai.com@dmarc.ietf.org>, "spasm@ietf.org" <spasm@ietf.org>
In-Reply-To: <05F066A5-3977-4A92-A92D-16CB241CFD49@akamai.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> <69d8d53b-d55f-bbe4-076b-3c9db12a9ba9@sandelman.ca> <05F066A5-3977-4A92-A92D-16CB241CFD49@akamai.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 12:27:08 -0400
Message-ID: <10375.1628180828@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/puyG9qwhxAQRBGbh8WIFxSZuPDQ>
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 16:27:19 -0000

Salz, Rich <rsalz=40akamai.com@dmarc.ietf.org> wrote:
    > There are legacy implementations with PKCS12 that are broken in strange
    > and wonderful ways, and cause cryptographic libraries to perform
    > unnatural acts to use algorithms that are no longer secure.

Agreed.

    > Updating PKCS12 to specify modern algorithms seems easy and
    > in-charter. Updating the RFC to clarify some ambiguities might be
    > harder, but should be considered as well.

    > The legacy implementations will muddle along. Browsers, maintained
    > crypto libraries and current software that uses them will benefit.

This is my point: the legacy stuff is there, we already muddle along and have
built interoperability with the broken stuff.  Yes, using 3DES, etc.

If we can get the legacy guys to open up their code, why fix PKCS12 if they
could just move to PKCS8? (or PKCS1 or...?)




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