Hi folks,
This is a proposal for revising SignatureAlgorithm/HashAlgorithm. In TLS
1.2, signature algorithms are spread across the handshake. We have
SignatureAlgorithm, NamedGroup/Curve (for ECDSA), and HashAlgorithm, all in
independent registries. NamedGroup is sent in one list, also used for
(E
David Benjamin wrote:
> 4. Deprecate ecdsa_sha256, etc., in favor of new
> ecdsa_{p256,p384,p521}_{sha256,sha384,sha512} allocations. The old ecdsa_*
> values are for TLS 1.2 compatibility but ignored in TLS 1.3. Although this
> introduces new premultiplications, it’s only 9 values with the prune
We discussed this topic briefly at IETF94 and in more detail
at the Marnew workshop. There seemed to be at least enough
interest for a list so...
Cheers,
S.
PS: I'd say best to wait 'till next Wednesday or so to start
list discussion so that folks have time to join the list.
Forwarded
On Friday, January 15, 2016 03:45:34 pm David Benjamin wrote:
> This is a proposal for revising SignatureAlgorithm/HashAlgorithm. In TLS
> 1.2, signature algorithms are spread across the handshake.
[...]
> I propose we fold the negotiable parameters under one name.
[...]
> 2. Remove HashAlgorithm,
On Fri, Jan 15, 2016 at 7:08 PM Brian Smith wrote:
> David Benjamin wrote:
>
>> 4. Deprecate ecdsa_sha256, etc., in favor of new
>> ecdsa_{p256,p384,p521}_{sha256,sha384,sha512} allocations. The old ecdsa_*
>> values are for TLS 1.2 compatibility but ignored in TLS 1.3. Although this
>> introduc
On Fri, Jan 15, 2016 at 8:07 PM Dave Garrett wrote:
> On Friday, January 15, 2016 03:45:34 pm David Benjamin wrote:
> > This is a proposal for revising SignatureAlgorithm/HashAlgorithm. In TLS
> > 1.2, signature algorithms are spread across the handshake.
> [...]
> > I propose we fold the negotia
On Fri, Jan 15, 2016 at 5:19 PM, David Benjamin
wrote:
> On Fri, Jan 15, 2016 at 8:07 PM Dave Garrett
> wrote:
>
>> On Friday, January 15, 2016 03:45:34 pm David Benjamin wrote:
>> > This is a proposal for revising SignatureAlgorithm/HashAlgorithm. In TLS
>> > 1.2, signature algorithms are sprea
On Fri, Jan 15, 2016 at 8:10 PM David Benjamin
wrote:
> If changing the existing meaning is a nuisance, another option is to
> continue to allocate new values but only define ecdsa_p256_sha256,
> ecdsa_p384_sha384, and ecdsa_p521_sha512 (or whatever your favorite subset
> is) for TLS 1.3 and late
David Benjamin wrote:
> (Whether such certificates exist on the web is probably answerable via CT
> logs, but I haven't checked.)
>
Me neither, and I think that's the key thing that would need to be checked
to see if my suggestion is viable.
3. You get better interoperability with TLS 1.2's NSA
On Sat, Jan 16, 2016 at 01:10:06AM +, David Benjamin wrote:
> On Fri, Jan 15, 2016 at 7:08 PM Brian Smith wrote:
>
> Hrm. That hadn't occurred to me, no. Fewer values sounds good, if we can
> lose them. I just wrote out all 9 without thinking about it much. Apart
> from "please don't cause me
10 matches
Mail list logo
