Hi Phillip,
I'm not able to figure out the merits of your proposal, but I see one major
obstacle: Google have a de-facto monopoly (80%) on browser technology and your
proposal seems to require a rather substantial upgrade.
That is, unless Google buys into whatever you propose, it simply put get
On 2020-10-07 19:47, Mohit Sethi M wrote:
A strong +1 on the security issues of decode -> extract -> re-encode ->
verify signature flow. The lack of canonical encoding can also mean that
the resulting bytes can be different in different encoder/decoder
implementations.
It would have been nice to
esent an hurdle for innovation and adoption of new
technology.
thanx,
Anders Rundgren
On 2019-08-18 10:09, Kepeng Li wrote:
Can you point to specific drafts where **normative** references are only
available for paying a fee? I guess that there are some, but I don’t know of
any.
This i
Using the YEAR as Version was created to make sure that users having old
versions
of products that are constantly upgraded would feel the pressure to upgrade.
This idea doesn't seem equally suitable for security protocols.
TLS 4 would IMO be a logical choice since it is numerically higher than
On 2016-11-19 07:35, Victor Vasiliev wrote:
On Fri, Nov 18, 2016 at 9:30 PM, Kazuho Oku mailto:kazuho...@gmail.com>> wrote:
I oppose to going to TLS 4, due to the following reasons:
* it might give people false notion that SSL 2.0, 3.0 is superior to TLS
1.0-1.2
* if name the new
On 2016-09-06 16:15, Peter Gutmann wrote:
David Benjamin writes:
Either way I imagine our stack will just keep on ignoring it, so I don't feel
about this all too strongly. But the topic came up so I thought I'd suggest
this.
I ignore it too. Client certs are so rare, and so painful to deplo