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

Bernie Hoeneisen <bernie@ietf.hoeneisen.ch> Thu, 05 August 2021 16:27 UTC

Return-Path: <bernie@ietf.hoeneisen.ch>
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 99A393A1892 for <spasm@ietfa.amsl.com>; Thu, 5 Aug 2021 09:27:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 3ZTLOVive-mN for <spasm@ietfa.amsl.com>; Thu, 5 Aug 2021 09:27:22 -0700 (PDT)
Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [IPv6:2a01:4f8:c0c:15fc::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6271F3A1875 for <spasm@ietf.org>; Thu, 5 Aug 2021 09:27:22 -0700 (PDT)
Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from <bernie@ietf.hoeneisen.ch>) id 1mBgDI-002vgT-0S for spasm@ietf.org; Thu, 05 Aug 2021 18:27:20 +0200
Date: Thu, 05 Aug 2021 18:27:18 +0200
From: Bernie Hoeneisen <bernie@ietf.hoeneisen.ch>
X-X-Sender: bhoeneis@softronics.hoeneisen.ch
To: LAMPS WG <spasm@ietf.org>
In-Reply-To: <877dh03x35.fsf@fifthhorseman.net>
Message-ID: <alpine.DEB.2.22.394.2108051809190.697777@softronics.hoeneisen.ch>
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>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="US-ASCII"
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Mail-From: bernie@ietf.hoeneisen.ch
X-SA-Exim-Scanned: No (on softronics.hoeneisen.ch); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/AMJXliBhSNVrsp9yw5MiA9Wc1MA>
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:30 -0000

Hi,

On Thu, 5 Aug 2021, Daniel Kahn Gillmor wrote:

> However, i don't understand how interoperation for private keys is
> nonsense.
>
> Many people with e-mail accounts use multiple mail user agents to access 
> the same account (e.g. one MUA on their phone, another on a laptop). 
> If those accounts are supposed to be able to use end-to-end secure 
> communication then at least one of them needs to be able to export its 
> private key material and the other needs to be able to import it. [...] 
> if we want to ensure that end-to-end cryptographic protections are 
> usable and secure for actual e-mail users, then we need to figure out 
> the interop issues for private key material. [...]

For those interested in private key exchange technology: For the use case 
mentioned above, there are already several implementations (pEp KeySync) 
[1], which is working in an e2e manner; however these implementations are 
currenty PGP based (i.e. S/MIME is not yet suported).

We documented the pEp KeySync protocol in:

   https://datatracker.ietf.org/doc/html/draft-pep-keysync

cheers,
  Bernie


[1] https://pep.foundation/pep-software/index.html (last section)