IETF Logo Mail Archive

Re: [Secdispatch] Best practices for applications using X.509 client certificates

David Woodhouse <dwmw2@infradead.org> Tue, 20 June 2023 18:57 UTC

Return-Path: <BATV+288f744f4c934e53f325+7240+infradead.org+dwmw2@casper.srs.infradead.org>
X-Original-To: secdispatch@ietfa.amsl.com
Delivered-To: secdispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ED56C1516E3 for <secdispatch@ietfa.amsl.com>; Tue, 20 Jun 2023 11:57:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.095
X-Spam-Level:
X-Spam-Status: No, score=-7.095 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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=infradead.org
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 R9IH44kjIVfy for <secdispatch@ietfa.amsl.com>; Tue, 20 Jun 2023 11:57:38 -0700 (PDT)
Received: from casper.infradead.org (casper.infradead.org [IPv6:2001:8b0:10b:1236::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 548BEC14CE42 for <secdispatch@ietf.org>; Tue, 20 Jun 2023 11:57:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=MIME-Version:Content-Type:References: In-Reply-To:Date:To:From:Subject:Message-ID:Sender:Reply-To:Cc: Content-Transfer-Encoding:Content-ID:Content-Description; bh=GS3GSc5nrFwNZj5u+Cmh9B11FMb7cW2avdPQuC0bwfg=; b=QeSGEV0wqpqtl+TLYrnSg4uARr pCkNnTrobd9ddZZ1re4+kAE29Udp3Wn29/G/ifkhtIfVKy2c+C6zA+yp1mmBu+i/SZxipAXY/RREF u+ZJSar4EUYrtNzPrEM6q7Yt0uVGTMLx4RB4jDq+DT3BsPHMRbk+hkyTHVY/77KujD9pLlGHWlpPk 3JgGqqWjRTG2xlROOa657g6GGUgGpk3Ppj712WN8rSOQT0IKujVs+V1D4UnbAKITHh0HrngunOqWq aRjXrpBjU2Zq2jSX5uq3joUC6TDGDZvCXWTlLcHtwLRu+ES/hyzKkVPzYcZ16ktEOwiennOaBsnwn IBLcRIpg==;
Received: from [2001:8b0:10b:5:f26b:798c:7de3:5106] (helo=u3832b3a9db3152.ant.amazon.com) by casper.infradead.org with esmtpsa (Exim 4.94.2 #2 (Red Hat Linux)) id 1qBgXk-00DQRG-PM; Tue, 20 Jun 2023 18:57:32 +0000
Message-ID: <15f1c3d34c0e0edee609f8ba38520f9bec7d132c.camel@infradead.org>
From: David Woodhouse <dwmw2@infradead.org>
To: Michael Richardson <mcr+ietf@sandelman.ca>, secdispatch@ietf.org, Nikos Mavrogiannopoulos <n.mavrogiannopoulos@gmail.com>
Date: Tue, 20 Jun 2023 19:57:31 +0100
In-Reply-To: <692743.1687285806@dyas>
References: <2887d285ffe450fd89dfb78d89b97c503d98091e.camel@infradead.org> <413256.1686841915@dyas> <11f8d5929828fe2d1a5eba4311d1cc71105a8480.camel@infradead.org> <692743.1687285806@dyas>
Content-Type: multipart/signed; micalg="sha-256"; protocol="application/pkcs7-signature"; boundary="=-UzPafd8eZJ2KEDH5ebRd"
User-Agent: Evolution 3.44.4-0ubuntu1
MIME-Version: 1.0
X-SRS-Rewrite: SMTP reverse-path rewritten from <dwmw2@infradead.org> by casper.infradead.org. See http://www.infradead.org/rpr.html
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdispatch/FM1a256fXH9uqD9HGBHbWlODM4U>
Subject: Re: [Secdispatch] Best practices for applications using X.509 client certificates
X-BeenThere: secdispatch@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Security Dispatch <secdispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdispatch>, <mailto:secdispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdispatch/>
List-Post: <mailto:secdispatch@ietf.org>
List-Help: <mailto:secdispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdispatch>, <mailto:secdispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 Jun 2023 18:57:43 -0000

On Tue, 2023-06-20 at 14:30 -0400, Michael Richardson wrote:
> 
> David Woodhouse <dwmw2@infradead.org> wrote:
>     > On Thu, 2023-06-15 at 11:11 -0400, Michael Richardson wrote:
>     >>
>     >> David Woodhouse <dwmw2@infradead.org> wrote:
>     >>     > There is a distinct lack of consistency across applications which use
>     >>     > client certificates for authentication. It confuses users and hurts
>     >>     > adoption of more secure methods of key storage, especially TPMs and
>     >>     > hardware/software tokens accessed via PKCS#11.
>     >>
>     >>     > Following a discussion on the SAAG list in 2016, I drafted a document
>     >>     > describing "best practices" for applications:
>     >>
>     >>     > http://david.woodhou.se/draft-woodhouse-cert-best-practice.html
>     >>
>     >> Will you submit your XML to the datatracker?
> 
>     > Is that something I should be doing already, before gaining any
>     > consensus? If so, sure. I'll do it as soon as I manage to recover my
>     > datatracker account and work out how :)
> 
> Yes.  You submit an individual draft so that everyone can see the same
> document.  And it winds up in the database, and can be easily put on an
> agenda, or passed around to other WGs.  It also means you've gone through the NoteWell.

Ack, thanks.

https://datatracker.ietf.org/doc/draft-woodhouse-cert-best-practice/


>     >> Do we need a standard for which URI scheme to use?
>     >> You write:
> 
>     > To a certain extent — although this proposal is about being liberal in
>     > what we *accept* from the user, not prescriptive about what the user
>     > shall provide.
> 
> My thoughts is that program (A), perhaps run by IT person, is emitting URIs
> which are being pasted into emails, put into QR codes, etc.  and we should be
> more prescriptive about that.

Yeah, that makes sense. Although some of it is implicit... if the
*applications* take their input in a coherent standard form, like the
PKCS#11 URI, then the IT person doing the provision is naturally going
to want to provide that to the users/tooling.

I'm still slightly wary of feature creep.

v2.31.3 | Report a Bug | By Email | System Status