Re: [MLS] Improving client authentication

Benjamin Kaduk <> Mon, 14 December 2020 04:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3C00E3A0E7E; Sun, 13 Dec 2020 20:21:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.003
X-Spam-Status: No, score=0.003 tagged_above=-999 required=5 tests=[RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wad0e0eeB9SO; Sun, 13 Dec 2020 20:21:26 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 987EB3A0E7B; Sun, 13 Dec 2020 20:21:25 -0800 (PST)
Received: from ([]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by (8.14.7/8.12.4) with ESMTP id 0BE4LIU0010096 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 13 Dec 2020 23:21:23 -0500
Date: Sun, 13 Dec 2020 20:21:18 -0800
From: Benjamin Kaduk <>
To: Benjamin Beurdouche <>
Cc: Raphael Robert <>, ML Messaging Layer Security <>
Message-ID: <>
References: <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <>
Archived-At: <>
Subject: Re: [MLS] Improving client authentication
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Messaging Layer Security <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 14 Dec 2020 04:21:27 -0000

Hi Ben,

Taking a bit of a tangent...

On Wed, Dec 09, 2020 at 10:23:59AM +0100, Benjamin Beurdouche wrote:
> > On 29 Nov 2020, at 18:13, Raphael Robert <> wrote:
> Something less relevant to this discussion but I want to mention it
> here...  This raises an issue that I have seen a lot over the last few
> years: we need something which performs a similar role to the WebPKI but
> doesn’t have the complexity of X.509.  Note that half of the attacks
> against TLS implementations are actually attacks against ASN1/X.509
> parsers, and we don’t really need this complexity for MLS.
> We should probably use X.509 in many cases because it is well supported
> by HSMs but in the long run, I think we should create WG and start
> thinking of a replacement to X.509 for places (not the Web) that don’t
> need the complexity.

This isn't quite what you're hoping for, but there's some work in the COSE
WG to subset X.509 certificates and produce a more compact encoding for
them; the same machinery will be naturally usable for making "CBOR native"
certificates (that use COSE for the signatures instead of operating on the
ASN.1 DER) that don't allow the full complexity of X.509.  The doc is
draft-mattsson-cose-cbor-cert-compress (we'll be rechartering in order to
pick it up as a WG item).