[Dance] [saag] Best practices for applications using X.509 client certificates (fwd) David Woodhouse: [saag] Best practices for applications using X.509 client certificates

Michael Richardson <mcr@sandelman.ca> Fri, 09 June 2023 16:04 UTC

Return-Path: <mcr@sandelman.ca>
X-Original-To: dance@ietfa.amsl.com
Delivered-To: dance@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D3D8C1524AA for <dance@ietfa.amsl.com>; Fri, 9 Jun 2023 09:04:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Du3ZjnkAtLuB for <dance@ietfa.amsl.com>; Fri, 9 Jun 2023 09:04:20 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00:e000:2bb::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49B6EC14CEE3 for <dance@ietf.org>; Fri, 9 Jun 2023 09:03:46 -0700 (PDT)
Received: from dyas.sandelman.ca (unknown [75.98.19.151]) by relay.sandelman.ca (Postfix) with ESMTPS id 9731E1F45A for <dance@ietf.org>; Fri, 9 Jun 2023 16:03:43 +0000 (UTC)
Received: by dyas.sandelman.ca (Postfix, from userid 1000) id AD078A0536; Fri, 9 Jun 2023 12:03:41 -0400 (EDT)
Received: from dyas (localhost [127.0.0.1]) by dyas.sandelman.ca (Postfix) with ESMTP id AAB30A0516 for <dance@ietf.org>; Fri, 9 Jun 2023 12:03:41 -0400 (EDT)
From: Michael Richardson <mcr@sandelman.ca>
To: dance@ietf.org
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.3
MIME-Version: 1.0
Content-Type: message/rfc822
Content-Disposition: inline; filename="105"
Content-Description: forwarded message
Date: Fri, 09 Jun 2023 12:03:41 -0400
Message-ID: <198798.1686326621@dyas>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dance/x4_BqVuMp7gZ-vUOCxBa-lbwRd8>
Subject: [Dance] [saag] Best practices for applications using X.509 client certificates (fwd) David Woodhouse: [saag] Best practices for applications using X.509 client certificates
X-BeenThere: dance@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: DANE Authentication for Network Clients Everywhere <dance.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dance>, <mailto:dance-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dance/>
List-Post: <mailto:dance@ietf.org>
List-Help: <mailto:dance-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dance>, <mailto:dance-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Jun 2023 16:04:27 -0000

--- Begin Message ---
I raised $SUBJECT on this list in 2016, lamenting that all applications
which can use a certificate for SSL client authentication seem to hate
their users:
https://mailarchive.ietf.org/arch/msg/saag/4F82uK-CJdXmS42cC4-bn62pojU/

In response to that discussion, I created this draft to describe what I
consider "best practice" for a client application:
http://david.woodhou.se/draft-woodhouse-cert-best-practice.html

The gist of it is, "this stuff should Just Work". Whatever form I get
my cert+key in from the baroque outdated corporate infrastructure that
issues them — as long as it's not *completely* unreasonably insane — I
should just be able to give that to *any* application and expect it to
work.

That goes for files containing PKCS#1, PKCS#8, PKCS#12 or even TPM-
wrapped keys. And in place of a filename I should be able to pass a
reference like a RFC7512 PKCS#11 URI (or similar URIs for system key
stores or TPM internal storage) and *that* should just work too.

We've had a little bit of success over the years in making life better
for users. It's now more common for applications to automatically
accept a PKCS#11 URI in place of a filename, for example, and we've
defined a standard file format for TPMv2.0 key storage which is
interoperable between the two OpenSSL provider/engines and GnuTLS
implementations.

I've just updated the above draft to reference the TPMv2 support, and
I'd like work out what it would take to submit it as an actual I-D. As
noted by Ted Lemon last time, the challenge would be socializing it to
the people who need to read it. Publishing it through the IETF as an
informational RFC would certainly be better than sticking it on my own
web page in draft form.

There's plenty of technical heckling to be done on the content, for
sure, but also a process question there.

Any input would be much appreciated; thanks!



_______________________________________________
saag mailing list
saag@ietf.org
https://www.ietf.org/mailman/listinfo/saag
--- End Message ---