[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 ---
- [Dance] [saag] Best practices for applications us… Michael Richardson