Re: [Secdispatch] draft-leggett-spkac: Signed Public Key and Challenge

Graham Leggett <minfrin@sharp.fm> Wed, 09 November 2022 14:05 UTC

Return-Path: <minfrin@sharp.fm>
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 44900C1522D7 for <secdispatch@ietfa.amsl.com>; Wed, 9 Nov 2022 06:05:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 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_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=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 (1024-bit key) header.d=sharp.fm
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 Ii_8dRW5XVIa for <secdispatch@ietfa.amsl.com>; Wed, 9 Nov 2022 06:05:15 -0800 (PST)
Received: from chandler.sharp.fm (chandler.sharp.fm [78.33.206.219]) by ietfa.amsl.com (Postfix) with ESMTP id 1CBCDC1522B3 for <secdispatch@ietf.org>; Wed, 9 Nov 2022 06:05:14 -0800 (PST)
Received: from smtpclient.apple (unknown [IPv6:2001:4d48:ad5d:6301:8138:9b6d:aa93:27a9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: minfrin@sharp.fm) by chandler.sharp.fm (Postfix) with ESMTPSA id E41C119020D; Wed, 9 Nov 2022 14:05:12 +0000 (GMT)
Authentication-Results: chandler.sharp.fm; arc=none smtp.client-ip=2001:4d48:ad5d:6301:8138:9b6d:aa93:27a9
ARC-Seal: i=1; a=rsa-sha256; d=sharp.fm; s=default; t=1668002713; cv=none; b=s8Ba8ZWMYdIPjXM7gG6GBLNaYwM6cE4QiPiWgdd/DBI3gfL8t2uREIy0ZcA//T6IGSFFwm29oyWmbYcNqtOLSRlpp1oGz7FpLoT6A+iveuWRZD+37zVStj6dJhpQP5jMiioZ1Cl9lX/aSFp0cPCB8FPaGp3bpHrrxPqq8yn68VE=
ARC-Message-Signature: i=1; a=rsa-sha256; d=sharp.fm; s=default; t=1668002713; c=relaxed/simple; bh=blzp3qwMGWNzn9lwjtE6kIEvcd1ytYZZDThA5/lVTYo=; h=DKIM-Filter:DKIM-Signature:Content-Type:Mime-Version:Subject:From: In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id: References:To:X-Mailer; b=X6wmFJTfbN74RzJQCDGa2WpegqeniPBiiyqNKAFTp1IQLqcoKyH8QFdrZzhbhaZFgZ/EsZlQrixo8qBmCJxopDofBRlHR6ekHekpYAJKlf6omv7wRUUYjIE7UpR8SZVrbY9DAqRFJ7G9ZAy6bMF5D8PD/cb3EAj9/CAQrN8MsSM=
ARC-Authentication-Results: i=1; chandler.sharp.fm; arc=none smtp.client-ip=2001:4d48:ad5d:6301:8138:9b6d:aa93:27a9
DKIM-Filter: OpenDKIM Filter v2.11.0 chandler.sharp.fm E41C119020D
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sharp.fm; s=default; t=1668002713; bh=ZyWn05cF2wi7+sffFpeSblZmrlL04kzRuhUiX34jBZ8=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=ocsLgNOYP+TRHLYAI21FsdzbIi1GUeu5gunIlHW2zfo8kvlROfZD65/xTAbFDn6m/ IiDlLoKSClJgZ1rPgw5JvryjD8R5uBU/V6vGfYLsEfL+oQisAQHUeXdrgfnasChgv1 51zgebMaBaXmGOnhWLfMqO6oEAg8c4DP13jgQZS4=
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
From: Graham Leggett <minfrin@sharp.fm>
In-Reply-To: <171941.1667844726@dyas>
Date: Wed, 09 Nov 2022 16:05:12 +0200
Cc: Graham Leggett <minfrin=40sharp.fm@dmarc.ietf.org>, secdispatch@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <FC5C3A5D-27A2-4E87-9148-282A7CB8E192@sharp.fm>
References: <77101A6A-7D9C-4817-B16D-70505FA10C6D@sharp.fm> <CADNypP8VhSkWX-gjLAs5mTV2YzUc0LRHsNNPdeqE7DiTHjR=3g@mail.gmail.com> <171941.1667844726@dyas>
To: Michael Richardson <mcr+ietf@sandelman.ca>
X-Mailer: Apple Mail (2.3696.120.41.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdispatch/isIQGp8jAxqtfSXA5qW2jR5pDGo>
Subject: Re: [Secdispatch] draft-leggett-spkac: Signed Public Key and Challenge
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: Wed, 09 Nov 2022 14:05:20 -0000

On 07 Nov 2022, at 20:12, Michael Richardson <mcr+ietf@sandelman.ca> wrote:

> Hi, I read your document.

Thanks for this.

> I didn't know that SPKAC was never standardized.
> 
> It would be great to know if there are browser implementers are willing to
> implement this specification.  Was removal from chrome due to lack of a
> specification?
> 
> Or, to put it less kindly... is there a point in doing the work?
> 
> In the CSR/RFC7030 space, there is an open question of what to do with some key
> types that do not support signing.
> 
> It seems like this should be dispatched to LAMPS.

There is nothing browser specific in the SPKAC specification, it’s just a mechanism / message format that you can use to prove you possess a private key. As a result it has general purpose use, either as originally intended (keygen in browsers), or as something else over HTTP (eg a rest client chatting to a rest server), or something else entirely (SPKAC over avian carrier using extruded wood extension).

Keygen was part of HTML5, but was removed because a) there was no standard for SPKAC, and b) there was a hard coded use of MD5 in the HTML5 spec (but not the SPKAC spec - SPKAC can use any modern digest algorithm as expected).

Right now code exists to implement SPKAC that is widely deployed in libraries (eg openssl for many platforms, bouncycastle, etc). I submitted a fix for openssl to allow the specification of the digest (prior to the fix, MD5 hardcoded). It would be great to finish the standardisation job rather than throw the code out.

I care because I wrote this: https://redwax.eu/rs/docs/latest/mod/mod_spkac.html, which is an implementation of the server side of keygen. I also care because it made distributing certs hard that had private keys generated by the end user of the certificate. The vast majority of certificate distribution these days is done by “here is your cert, also here is your key that we generated for you and is therefore by definition not private, and therefore we can’t trust anything you signed with this”.

I would like to revive the standard in HTML5, but that is a moot point until the (very valid) SPKAC-has-no-definition problem is addressed.

Regards,
Graham
—