Thanks! I've applied those fixes to my local copy. They fixes will be in the -01 revision.
On Wed, Jul 31, 2019 at 3:42 AM Thom Wiggers <[email protected]> wrote: > 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. > I also apparently never finished that sentence. Oops. :-) In my local copy, this paragraph now reads: Signatures made by the same key in different contexts should be separated to avoid potential cross-protocol attacks. Inputs to the batch signing algorithm include any existing context strings, such as TLS 1.3's distinct client and server labels or new labels that may be allocated by future versions of TLS.. By signing over those labels, batch signing preserves separation between those inputs. > It looks like an interesting proposition, which could also be interesting > in the context of some of the post-quantum signing algorithms. > > Cheers, > > Thom > > Op di 30 jul. 2019 om 02:16 schreef David Benjamin <[email protected] > >: > >> Hi all, >> >> I’ve just uploaded a pair of drafts relating to signatures in TLS 1.3. >> https://tools.ietf.org/html/draft-davidben-tls13-pkcs1-00 >> https://tools.ietf.org/html/draft-davidben-tls-batch-signing-00 >> >> 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/tls >> >
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
