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

Daniel Kahn Gillmor <dkg@fifthhorseman.net> Tue, 10 August 2021 13:13 UTC

Return-Path: <dkg@fifthhorseman.net>
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 A37AB3A097B for <spasm@ietfa.amsl.com>; Tue, 10 Aug 2021 06:13:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=KEWCLnYE; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=TGwThfFE
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 ojCdjk4Q8tGs for <spasm@ietfa.amsl.com>; Tue, 10 Aug 2021 06:13:35 -0700 (PDT)
Received: from che.mayfirst.org (che.mayfirst.org [IPv6:2001:470:1:116::7]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB84F3A0971 for <spasm@ietf.org>; Tue, 10 Aug 2021 06:13:34 -0700 (PDT)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1628601211; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=1lCb4GGeV7T6zt7H2optBV10m66PvODi7IC531dbfPE=; b=KEWCLnYEf7n9jxVf6eN1+pIevXIcPx6FyjlG88qZgfWfQ9CxIu8X6cYBPbWGjGbDYaBV/ oreb1tNj+M2MlXpDA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1628601211; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=1lCb4GGeV7T6zt7H2optBV10m66PvODi7IC531dbfPE=; b=TGwThfFE8RejCq4Sf68y4GvWAGIxHHcl2aSVi01BVDZOl+0XEKMNr4BxFMgcZnmrxZbeq LzNiP5rQP5PphCSNqQbhanHYS4obT9qc7LHTh4CqGOqE9SPcXlcGB+Nco11F8HU8IIt4vHn dKIDeHFflJqgxus2LBfHYaP7I3YM3PVEOxrGMshTyE0Mlo11+WaPEYp79JG2fxjF3hVAq5r eqIcxwlKeTwaNs1KADAm7vbXtTPnXPDtw4txLGmPNhMhdcRVw4g4eRIrtwCERUuphjdYyyU 0VG4eq7eSaz590Ct0PSe364tVXRaG8MqD5lOsaRTaeWOsYpGMWm04WXmp+yQ==
Received: from fifthhorseman.net (lair.fifthhorseman.net [108.58.6.98]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 7393AF9A7 for <spasm@ietf.org>; Tue, 10 Aug 2021 09:13:31 -0400 (EDT)
Received: by fifthhorseman.net (Postfix, from userid 1000) id 12ADA203AB; Mon, 9 Aug 2021 12:57:29 -0400 (EDT)
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: LAMPS WG <spasm@ietf.org>
In-Reply-To: <115D31F8-A088-413B-A526-9C48D579C122@vigilsec.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> <87zgtv3jf9.fsf@fifthhorseman.net> <115D31F8-A088-413B-A526-9C48D579C122@vigilsec.com>
Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEX+i03xYJKwYBBAHaRw8BAQdACA4xvL/xI5dHedcnkfViyq84doe8zFRid9jW7CC9XBiI0QQf FgoAgwWCX+i03wWJBZ+mAAMLCQcJEOCS6zpcoQ26RxQAAAAAAB4AIHNhbHRAbm90YXRpb25zLnNl cXVvaWEtcGdwLm9yZ/tr8E9NA10HvcAVlSxnox6z62KXCInWjZaiBIlgX6O5AxUKCAKbAQIeARYh BMKfigwB81402BaqXOCS6zpcoQ26AADZHQD/Zx9nc3N2kj13AUsKMr/7zekBtgfSIGB3hRCU74Su G44A/34Yp6IAkndewLxb1WdRSokycnaCVyrk0nb4imeAYyoPtBc8ZGtnQGZpZnRoaG9yc2VtYW4u bmV0PojRBBMWCgCDBYJf6LTfBYkFn6YAAwsJBwkQ4JLrOlyhDbpHFAAAAAAAHgAgc2FsdEBub3Rh dGlvbnMuc2VxdW9pYS1wZ3Aub3JnL0Gwxvypz2tu1IPG+yu1zPjkiZwpscsitwrVvzN3bbADFQoI ApsBAh4BFiEEwp+KDAHzXjTYFqpc4JLrOlyhDboAAPkXAP0Z29z7jW+YzLzPTQML4EQLMbkHOfU4 +s+ki81Czt0WqgD/SJ8RyrqDCtEP8+E4ZSR01ysKqh+MUAsTaJlzZjehiQ24MwRf6LTfFgkrBgEE AdpHDwEBB0DkKHOW2kmqfAK461+acQ49gc2Z6VoXMChRqobGP0ubb4kBiAQYFgoBOgWCX+i03wWJ BZ+mAAkQ4JLrOlyhDbpHFAAAAAAAHgAgc2FsdEBub3RhdGlvbnMuc2VxdW9pYS1wZ3Aub3Jnfvo+ nHoxDwaLaJD8XZuXiaqBNZtIGXIypF1udBBRoc0CmwICHgG+oAQZFgoAbwWCX+i03wkQPp1xc3He VlxHFAAAAAAAHgAgc2FsdEBub3RhdGlvbnMuc2VxdW9pYS1wZ3Aub3JnaheiqE7Pfi3Atb3GGTw+ jFcBGOaobgzEJrhEuFpXREEWIQQttUkcnfDcj0MoY88+nXFzcd5WXAAAvrsBAIJ5sBg8Udocv25N stN/zWOiYpnjjvOjVMLH4fV3pWE1AP9T6hzHz7hRnAA8d01vqoxOlQ3O6cb/kFYAjqx3oMXSBhYh BMKfigwB81402BaqXOCS6zpcoQ26AADX7gD/b83VObe14xrNP8xcltRrBZF5OE1rQSPkMNy+eWpk eCwA/1hxiS8ZxL5/elNjXiWuHXEvUGnRoVj745Vl48sZPVYMuDgEX+i03xIKKwYBBAGXVQEFAQEH QIGex1WZbH6xhUBve5mblScGYU+Y8QJOomXH+rr5tMsMAwEICYjJBBgWCgB7BYJf6LTfBYkFn6YA CRDgkus6XKENukcUAAAAAAAeACBzYWx0QG5vdGF0aW9ucy5zZXF1b2lhLXBncC5vcmcEAx9vTD3b J0SXkhvcRcCr6uIDJwic3KFKxkH1m4QW0QKbDAIeARYhBMKfigwB81402BaqXOCS6zpcoQ26AAAX mwD8CWmukxwskU82RZLMk5fm1wCgMB5z8dA50KLw3rgsCykBAKg1w/Y7XpBS3SlXEegIg1K1e6dR fRxL7Z37WZXoH8AH
Date: Mon, 09 Aug 2021 12:57:28 -0400
Message-ID: <877dgu369z.fsf@fifthhorseman.net>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/DG0TU525hkk-3QNJvYEf7fNiIMU>
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: Tue, 10 Aug 2021 13:13:41 -0000

On Sat 2021-08-07 11:52:07 -0400, Russ Housley wrote:
>> On Aug 5, 2021, at 1:12 PM, Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote:
>> 
>> - formally deprecate PKCS#12 (e.g. move 7292 from informational to
>>   historical) and encourage some other standard (a PKZIP file full of
>>   independent PKCS#8 objects and certificate objects?  that seems
>>   morally equivalent to PKCS#12 to me, but a much longer lead time to
>>   get any sort of adoption)
>
> RFC 5208 is the PKCS#8 v1.2 specification.
>
> RFC 5985 is an enhancement to PKCS#8 that allows the certificate to be carried along with the private key.  In addition, RFC 5985 provides a content type for PKCS#8.
>
> RFC 4073 defines a way to carry a collection of contents, each with their own type:
>
>       ContentCollection ::= SEQUENCE SIZE (1..MAX) OF ContentInfo
>
> These seem to be the building blocks that are needed to carrya a collection of PKCS#8-protected private keys along with the associated certificate.

Thanks, Russ!  I appreciate this collection of pointers, but i am not
convinced they belong in draft-ietf-lamps-samples today given that i
don't know of any tooling that is capable of ingesting them.

If someone in the WG wants to assemble such an object from the keys and
certs already in the draft, and other folks in the WG can independently
confirm that it appears to be correct, then i'd be fine with including
it alongside the PKCS#12 objects that the draft currently publishes.
I'd be even more strongly convinced if someone can point to an
implementation that is capable of processing them.

Including such an object in the spec might be a helpful spur for
adoption!  But without other people stepping forward to assemble and
test the pieces and point to implemententations, i'm inclined to leave
this as future work so we can get draft-ietf-lamps-samples out the door.

     --dkg

v2.23.0 | Report a Bug | By Email