IETF Logo Mail Archive

Re: [lamps] draft-ietf-lamps-samples: PKCS12 expertise needed (including objects for comparison)

Michael Richardson <mcr+ietf@sandelman.ca> Wed, 04 August 2021 21:43 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 865A93A0CBB for <spasm@ietfa.amsl.com>; Wed, 4 Aug 2021 14:43:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 aweul75yzkrD for <spasm@ietfa.amsl.com>; Wed, 4 Aug 2021 14:43:04 -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 97F7C3A0CB7 for <spasm@ietf.org>; Wed, 4 Aug 2021 14:43:04 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 0ACE738996; Wed, 4 Aug 2021 17:47:18 -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 o8x361uNkD92; Wed, 4 Aug 2021 17:47:14 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 5EBFB38995; Wed, 4 Aug 2021 17:47:14 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id A45337F; Wed, 4 Aug 2021 17:42:57 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>, LAMPS WG <spasm@ietf.org>
In-Reply-To: <87pmuu42hf.fsf@fifthhorseman.net>
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>
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: Wed, 04 Aug 2021 17:42:57 -0400
Message-ID: <20862.1628113377@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/V5CfaxsGKZ40NDZvoLiuS9SfI0o>
Subject: Re: [lamps] 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: Wed, 04 Aug 2021 21:43:10 -0000

Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote:
    > On Tue 2021-08-03 09:07:06 -0400, Michael Richardson wrote:
    >> Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote:
    >> > c) Adjust the creation of the PKCS#12 objects so that they have the
    >> > double OCTET STRING wrapper (one for RFC 5652 and one for RFC 7972),
    >> > without moving them into the indefinite encoding.  (maybe also warn
    >> > against PKCS#12 use here?)
    >>
    >> Does this possible changes in code in existing systems?
    >> I don't think that they will change.

    > I've been using GnuTLS to generate the objects in the draft thus far,
    > and they've been open to code changes that i've suggested in the past
    > based on input from this WG.

okay, but my point is that it's not the flexible systems that are the
problem, it's the inflexible systems that are keeping us from changing.

====

Now, if rather than fix PKCS12, the IETF were to mark it HISTORICAL with
clear advice on what to use.  Remembering that we have PKCS1 and PKCS8
(RFC5208).
RFC5915/RFC5958.
This contributes to confusion and bits of lack of interoperation.

(Why do we need interoperation for private keys?  Often we don't need that
much, until someone is debugging something, or provisioning keys into an
embedded system via JTAG...)

I would be happy if pkcs12 just died.

--
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