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

Carl Wallace <carl@redhoundsoftware.com> Thu, 05 August 2021 13:36 UTC

Return-Path: <carl@redhoundsoftware.com>
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 859B93A120C for <spasm@ietfa.amsl.com>; Thu, 5 Aug 2021 06:36:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redhoundsoftware.com
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 Lv_2EC0Bv04P for <spasm@ietfa.amsl.com>; Thu, 5 Aug 2021 06:36:16 -0700 (PDT)
Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22F863A120B for <spasm@ietf.org>; Thu, 5 Aug 2021 06:36:12 -0700 (PDT)
Received: by mail-qt1-x832.google.com with SMTP id d2so3856702qto.6 for <spasm@ietf.org>; Thu, 05 Aug 2021 06:36:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhoundsoftware.com; s=google; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version; bh=nE5TeQo/J1je0MzYyxKlGkmF9olvfoDyhXFMnm7uy9c=; b=Jf/llEgaxbvtsylrFo3aTAl3KzVZEpak0Hp4iqz0EGLGL4msS4viCcFPEmNrVebAZB OGqKp89orjwwYeHIxT61TXfoHUi/AEEej1rHujC/9JeCpdqYBPnUMqcfUfHPDnG6xT7T SnEHQkKTZIyv7AdIX/25dJM/vQOPAnjEPAg3A=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version; bh=nE5TeQo/J1je0MzYyxKlGkmF9olvfoDyhXFMnm7uy9c=; b=aUznlMgDeXyrgFG0n8AxOdOrEdmEcJKdjoYugnw4pg5mcxtRO7BNDMRY3Z2Gc0A8pc PwNpkX5A1RPYgLM9m6Ge9EJWY55cbOdqylyDIf5SVqLCR/EAsR7s4jsV6YmYWvsCPIXK YBJBWQZcQK5sEf0UeqwFuB3T+UbXGql1WP++7znKqSWXi0JKDp1EMSQL2bxcGgORjtJU EoQAg98lQKL6rP8eB+kAap3cGYqkhGT3uoHqh2LJk0GY51sQXwEV59OBhWs47/gpnEck ABd2GrtRiRKy9GPSec0p37mrgNwQ1gK2X6cURpHTbz5EyR/0AKVJq9fRg90chn1lknkK aR5w==
X-Gm-Message-State: AOAM532m3CYDx4UCXFSKzvBgiym0eUf2TnadCzdgI0/KeLQM7tUlM6RQ /HTIGocTYXuk7GR5mlouWCWYbw==
X-Google-Smtp-Source: ABdhPJxT7fLRXjaMCrTw/w4WapOqMTVvtAv/0AfsTXhS3u03kBUgkCpQifz6t3aUY2TH3oYLv8zJHQ==
X-Received: by 2002:ac8:44a8:: with SMTP id a8mr4404688qto.238.1628170571112; Thu, 05 Aug 2021 06:36:11 -0700 (PDT)
Received: from [192.168.2.16] (pool-173-73-191-214.washdc.fios.verizon.net. [173.73.191.214]) by smtp.gmail.com with ESMTPSA id c68sm3174417qkf.48.2021.08.05.06.36.10 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Aug 2021 06:36:10 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/16.51.21071101
Date: Thu, 05 Aug 2021 09:36:10 -0400
From: Carl Wallace <carl@redhoundsoftware.com>
To: Dmitry Belyavsky <beldmit@gmail.com>
CC: Tomas Gustavsson <tomas.gustavsson=40primekey.com@dmarc.ietf.org>, Stephen Farrell <stephen.farrell@cs.tcd.ie>, Daniel Kahn Gillmor <dkg@fifthhorseman.net>, LAMPS WG <spasm@ietf.org>
Message-ID: <FDABD9C2-3BDE-4318-B8B1-578D90DC6C88@redhoundsoftware.com>
Thread-Topic: [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)]
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> <CADqLbz+oQRXXdayRVRc99D_BeweRJ_VQ--o7tzdncv5UBEhE8g@mail.gmail.com>
In-Reply-To: <CADqLbz+oQRXXdayRVRc99D_BeweRJ_VQ--o7tzdncv5UBEhE8g@mail.gmail.com>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3711000970_774363624"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/pHwgfHnOsEyFcuOjc_JsNZTT6Rs>
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 13:36:22 -0000

Of course. We have a potpourri of certificate enrollment protocols at our disposal. 

 

Dear Carl,

 

Even in this case you have to implement some sort of bootstrapping on the new device...

 

On Thu, Aug 5, 2021 at 2:52 PM Carl Wallace <carl@redhoundsoftware.com> wrote:

Given everyone has a hardware crypto module in their pocket these days and setting aside key escrow concerns, another way to get at this would be to encrypt for more than one key and forego exporting and sharing keys. That might not even require new protocol work but just better use of what we have now.

 

From: Spasm <spasm-bounces@ietf.org> on behalf of Tomas Gustavsson <tomas.gustavsson=40primekey.com@dmarc.ietf.org>
Date: Thursday, August 5, 2021 at 8:45 AM
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, Daniel Kahn Gillmor <dkg@fifthhorseman.net>, LAMPS WG <spasm@ietf.org>
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)]

 

I have dreamt for a long time that there would be an interoperable data exchange format for keys and certificates (think Token/HSM backup/restore). Something more efficient and user friendly than individual PKCS#8 and PEM files. I think it potentially could advance things that is imho held back by lack of interoperability and lock-in. Whether applications would adopt is a good question however. I don't represent a token vendor, just a user who think I see a benefit, so...

 

Cheers,

Tomas

From: Spasm <spasm-bounces@ietf.org> on behalf of Stephen Farrell <stephen.farrell@cs.tcd.ie>
Sent: Thursday, August 5, 2021 2:33 PM
To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>; LAMPS WG <spasm@ietf.org>
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)] 

 

CAUTION: External Sender - Be cautious when clicking links or opening attachments. Please email InfoSec@keyfactor.com with any questions.


Hiya,

On 05/08/2021 13:17, Daniel Kahn Gillmor wrote:
> I sympathize with the grumbling about it, but I'd hope that the experts
> in the IETF LAMPS WG can at least come to a consensus that there is
> value in standardizing interop for decryption-capable private keys.

We tried that before [1] but it might be worth
another shot. The previous attempt got wrapped
up in a then-fashionable transport that never
really took off and was also affected by now-
expired IPR.

That'd need to be a separate WG though. Not
sure if it'd be better scoped to mail or to be
more broad.

I think the critical question, then as now, is
whether or not applications would adopt.

Cheers,
S.

[1] https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fwg%2Fsacred%2F&amp;data=04%7C01%7Ctomas.gustavsson%40primekey.com%7C9f66bfa597fd4ceb346c08d9580d4501%7Cc9ed4b459f70418aaa58f04c80848ca9%7C0%7C0%7C637637636287867009%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=2D43V9LfLHXtkzRWZnAfF0HlLSOySFTWHKyldxE3moc%3D&amp;reserved=0

_______________________________________________ Spasm mailing list Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm 

_______________________________________________
Spasm mailing list
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm


 

-- 

SY, Dmitry Belyavsky