> On Mar 24, 2017, at 1:08 AM, Martin Thomson wrote:
>
>> I've never seen
>> a TLS server that has multiple chains to choose from for the same
>> server identity.
Both chains of course use SHA256.
Sorry I meant to say multiple digest algorithms for otherwise
On 24 March 2017 at 12:29, Viktor Dukhovni wrote:
> I've never seen
> a TLS server that has multiple chains to choose from for the same
> server identity.
I didn't have to look far. www.cloudflare.com will switch hit and
pick RSA or ECDSA on demand:
$ ./tstclnt -h
> On Mar 23, 2017, at 9:00 PM, Peter Gutmann wrote:
>
> See several previous discussions on the rationale behind
> this (hmm, if you can find them :-).
See, for example, the thread that contains:
https://www.ietf.org/mail-archive/web/tls/current/msg17977.html
I
Fries, Steffen writes:
>I looked through the mailing list but did not find an immediate answer to my
>question, but I guess, it must have been discussed already.
It's been discussed several times, but I'm not sure which search terms you'd
have to apply to find the
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security of the IETF.
Title : Elliptic Curve Cryptography (ECC) Cipher Suites for
Transport Layer Security (TLS) Versions 1.2 and Earlier
On Thu, Mar 23, 2017 at 10:24 AM, Martin Rex wrote:
> Eric Rescorla wrote:
> >>
> >> based on your reply my conclusion is that
> >>
> >> - there is no (standard compliant) way for a server to use a
> >> SHA256 based certificate for server side authentication in cases where
On Thu, Mar 23, 2017 at 10:11 AM, Andrei Popov
wrote:
> Ø Note that any client which in fact supports
>
> Ø SHA-256 with TLS 1.2 but doesn't send signature_algorithms containing
> it,
>
> Ø is noncomformant. It's not clear to me how many such clients in fact
>
Eric Rescorla wrote:
>>
>> based on your reply my conclusion is that
>>
>> - there is no (standard compliant) way for a server to use a
>> SHA256 based certificate for server side authentication in cases where the
>> client does not provide the signature_algorithm extension
>
> Not quite.
Ø Note that any client which in fact supports
Ø SHA-256 with TLS 1.2 but doesn't send signature_algorithms containing it,
Ø is noncomformant. It's not clear to me how many such clients in fact exist.
We saw enough TLS 1.2 clients that are non-compliant in this way that I made
the
On Thu, Mar 23, 2017 at 9:44 AM, Martin Rex wrote:
> Fries, Steffen wrote:
> >
> > based on your reply my conclusion is that
> >
> > - there is no (standard compliant) way for a server to use a SHA256
> > based certificate for server side authentication in cases where the
> >
On 3/23/17 9:38 AM, Yoav Nir wrote:
>
>> On 21 Mar 2017, at 11:04, Stephen Farrell wrote:
>>
>>
>> Thanks Yoav,
>>
>> On 21/03/17 07:44, Yoav Nir wrote:
>>> Some that are not addressed, I’ve answered below. Let me know if you
>>> want me to merge and submit.
>>
>> I'd
On Thu, Mar 23, 2017 at 8:37 AM, Fries, Steffen
wrote:
> Hi Erik,
>
>
>
> based on your reply my conclusion is that
>
> - there is no (standard compliant) way for a server to use a
> SHA256 based certificate for server side authentication in cases where the
>
Hi Steffen,
You’re stepping on a sore point for this WG☺. Based on the strict
interpretation of the TLS 1.2 RFC, your conclusions are correct.
If a TLS1.2 client does not send the signature algorithms extension (or the
extension does not include SHA256), a compliant TLS 1.2 server with a SHA256
Fries, Steffen wrote:
>
> based on your reply my conclusion is that
>
> - there is no (standard compliant) way for a server to use a SHA256
> based certificate for server side authentication in cases where the
> client does not provide the signature_algorithm extension
The statement quoted by
> On 21 Mar 2017, at 11:04, Stephen Farrell wrote:
>
>
> Thanks Yoav,
>
> On 21/03/17 07:44, Yoav Nir wrote:
>> Some that are not addressed, I’ve answered below. Let me know if you
>> want me to merge and submit.
>
> I'd say give it a chance for one round of
> On Mar 23, 2017, at 11:53 AM, Melinda Shore
> wrote:
>
> Thanks for the thorough review, Viktor. I'll get the straightforward
> bits into the draft over the weekend and plan on discussing the ones
> proposing changes to the extension or to chain construction
Thanks for the thorough review, Viktor. I'll get the straightforward
bits into the draft over the weekend and plan on discussing the ones
proposing changes to the extension or to chain construction and
processing in the working group session.
Melinda
signature.asc
Description: OpenPGP digital
Hi Erik,
based on your reply my conclusion is that
- there is no (standard compliant) way for a server to use a SHA256
based certificate for server side authentication in cases where the client does
not provide the signature_algorithm extension
- clients should always use
Hi Viktor,
thanks for the response, I replied inline.
> According to TLS 1.2 section 7.4.1.4.1. a client may use the
> signature_algorithm extension to signal any combinations the client
> supports, listed in the order of preferences.
The signature algorithm is primarily about signatures made
On Thu, Mar 23, 2017 at 7:39 AM, Viktor Dukhovni
wrote:
>
> > On Mar 23, 2017, at 10:31 AM, Fries, Steffen
> wrote:
> >
> > According to TLS 1.2 section 7.4.1.4.1. a client may use the
> > signature_algorithm extension to signal any
> On Mar 23, 2017, at 10:31 AM, Fries, Steffen
> wrote:
>
> According to TLS 1.2 section 7.4.1.4.1. a client may use the
> signature_algorithm extension to signal any combinations the
> client supports, listed in the order of preferences.
The signature algorithm
Hi all,
according to TLS 1.2 section 7.4.1.4.1. a client may use the
signature_algorithm extension to signal any combinations the client supports,
listed in the order of preferences. If the client does not use this extension,
the server must use the signature algorithm in combination with
22 matches
Mail list logo