On Mon, Jun 05, 2023 at 03:35:17PM -0400, David Benjamin wrote:
> Thanks for such detailed feedback! Responses inline.
>
> On Wed, Mar 22, 2023 at 12:49 PM Ilari Liusvaara
> wrote:
>
> > Some quick comments / ideas:
> >
> > - I think it would be easier for subscribers to get inclusion proofs
> >
> > Thanks! That’s indeed inconsistent, we’ll fix it.
> > https://github.com/davidben/merkle-tree-certs/issues/32
>
> Hmm... Looking at that construct, why is the pad there?
We pad to the hash block size. When computing the full Merkle tree, or
verifying an authentication path, the values before
On Tue, Jun 06, 2023 at 01:28:17PM +0200, Bas Westerbaan wrote:
> > > Thanks! That’s indeed inconsistent, we’ll fix it.
> > > https://github.com/davidben/merkle-tree-certs/issues/32
> >
> > Hmm... Looking at that construct, why is the pad there?
>
>
> We pad to the hash block size. When computing
On Mon, Jun 5, 2023 at 12:42 PM David Benjamin
wrote:
>
> It’s true that this would require code changes in more components. But
> TLS, ACME, etc., are deployed many more times than they are implemented.
>
... [snip] ...
>
> To ACME specifically, we definitely don’t want it to be painful for A
The following errata report has been submitted for RFC5054,
"Using the Secure Remote Password (SRP) Protocol for TLS Authentication".
--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7538
--
Typ
