Re: [TLS] Drafts for batch signing and PKCS#1 v1.5

Thom Wiggers <> Wed, 31 July 2019 07:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D4EBC120098 for <>; Wed, 31 Jul 2019 00:42:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FmwZSCviEcQy for <>; Wed, 31 Jul 2019 00:42:23 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::42b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 30616120048 for <>; Wed, 31 Jul 2019 00:42:23 -0700 (PDT)
Received: by with SMTP id z1so68471462wru.13 for <>; Wed, 31 Jul 2019 00:42:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=yOl8VSqXVlyQnuBGh1x2bibnhsHVe4Jfs84zpRSwiBM=; b=PAbbdZCBEmy1Qnigdw4JAzpean3UTzYRYilsFlbqUtNlQrge2U3vSbAdUBCkvlRd5d HxaQ+UDuHU5W/H79VitANd7t8NHm2JJ+xEUGF2Xow5eu9S7bwJqkaJIGzzO3Y5JQDtYn XN+d4hI6MQ6OomZiX+6sqxr7FdFyzy9eEhT6Y=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=yOl8VSqXVlyQnuBGh1x2bibnhsHVe4Jfs84zpRSwiBM=; b=BKx9qyqM5jiK1s/fhbsOt1qZbXrWfN3fwQWM6CqoWjGnkUghFz7ZT65UaXea8glrV4 sAIkm7YTC1tnpssLFuqdv5UIXrCP+y5VB17Xm5Iu/YQgHYJMMUtxFOPraVQ6AE0Wj5Mr M/fGtHqF2nGzMFbC9XsyUJuh0xdZ9mhpjTYFoXK2Hir/Kx7vBSNE4g4xpAgD4ivsXZ1Y R/AphQqhBnjaXrmk8IF/1y1UtpvM60FcLuS1etNh7T9avy0YukV4ecFyRYpXSbLgsvDm dp7B5PGwOfGFPdDKGrHi0BjQaZqbkkBfNCPTj7ZkOY+03dvFh7Fk067oddJiIUWhDTsv 1mug==
X-Gm-Message-State: APjAAAXI2kMJKDUT8x51ylFAZzNPp5QovIopcLSfMUTqZ2WLzbYapi/N SFrHvhR0KuhtLxn7NY+kiOJk8aHW3JeKIOtQQ4w=
X-Google-Smtp-Source: APXvYqz8hDIlIN98xVx185iK3/+FnTW45a6i5tToklVVrEVEW/UNUD1ma07IIPhfPgW2uzfIyFc9ruV2+2po1TzGEeI=
X-Received: by 2002:adf:ec0c:: with SMTP id x12mr56691710wrn.342.1564558941331; Wed, 31 Jul 2019 00:42:21 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Thom Wiggers <>
Date: Wed, 31 Jul 2019 09:42:09 +0200
Message-ID: <>
To: David Benjamin <>
Cc: "<>" <>
Content-Type: multipart/alternative; boundary="000000000000edbd5d058ef54383"
Archived-At: <>
Subject: Re: [TLS] Drafts for batch signing and PKCS#1 v1.5
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 31 Jul 2019 07:42:26 -0000

Hi David,

I've found some small textual issues (I'm looking at the PDF version):

In section 3.1 in step 1 (on PDF page 4):

"element 2*i+1 to a random byte of string of Hash.length bytes."

This sentence is slightly puzzling. A random bytestring?

Section 4.2, first paragraph, last sentence:

"so batch signing inherits preserves separation"

This sentence contains two verbs.

It looks like an interesting proposition, which could also be interesting
in the context of some of the post-quantum signing algorithms.



Op di 30 jul. 2019 om 02:16 schreef David Benjamin <>rg>:

> Hi all,
> I’ve just uploaded a pair of drafts relating to signatures in TLS 1.3.
> The first introduces optional legacy codepoints for PKCS#1 v1.5 signatures
> with client certificates. This is unfortunate, but I think we should do it.
> On the Chrome side, we’ve encountered some headaches with the TLS 1.3 PSS
> requirement which are unique to client certificates. The document describes
> the motivations in detail.
> The second describes a batch signing mechanism for TLS using Merkle trees.
> It allows TLS clients and servers to better handle signing load. I think it
> could be beneficial for a number of DoS and remote key scenarios.
> Thoughts?
> David
> _______________________________________________
> TLS mailing list