Michael StJohns wrote:
> Martin Rex wrote:
>> oops, typo:
>>
>> Martin Rex wrote:
>>> Actually, looking at the DigiCert issued ECC cert for www.cloudflare.com
>>> I'm a little confused.
>>>
>>> This is the cert chain (as visualized by Microsoft CryptoAPI):
>>>
>>>server-cert:
On Fri, Mar 24, 2017 at 1:10 PM, Martin Rex wrote:
> If Chrome really does AIA-fetching (*shudder*), how can it be disabled?
>
I can understand and appreciate your viewpoint, although we disagree. I'll
save the rest of the list from rehashing that discussion, since the topic
at
On Fri, Mar 24, 2017 at 1:23 AM, Viktor Dukhovni
wrote:
>
> > 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
oops, typo:
Martin Rex wrote:
>
> Actually, looking at the DigiCert issued ECC cert for www.cloudflare.com
> I'm a little confused.
>
> This is the cert chain (as visualized by Microsoft CryptoAPI):
>
> server-cert: CN=cloudflare.com, ...
> contains ECDSA P-256 public key
>
Viktor Dukhovni wrote:
>
> > 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.
>
[ https://www.cloudflare.com/ ]
>
> Both chains of course
Viktor Dukhovni wrote:
>
> The net effect is that in practice you simply ignore the signature
> algorithms when it comes to the certificate chain.
Essentially correct. This is the only reasonable, highly backwards
compatible and perfectly secure choice.
>
> I've never seen a TLS server that
On Thu, Mar 23, 2017 at 10:23 PM, Viktor Dukhovni
wrote:
>
> > 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
> Sorry I meant to say multiple digest algorithms for otherwise identical chains
> (same public key algorithm and server name).
We used to have to do this, during the MD5-deprecation days.
___
TLS mailing list
TLS@ietf.org
Peter Gutmann [pgut...@cs.auckland.ac.nz] writes
Andrei Popov writes:
>Unfortunately, in practice there are TLS 1.2 clients that support
>SHA256, but don't advertise it via the signature algorithms extension.
It's actually pretty safe to just automatically assume
> 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
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
Of *Eric Rescorla
> *Sent:* Thursday, March 23, 2017 9:58 AM
> *To:* Fries, Steffen <steffen.fr...@siemens.com>
> *Cc:* TLS WG <tls@ietf.org>
> *Subject:* Re: [TLS] Enforcing stronger server side signature/hash
> combinations in TLS 1.2
>
>
&
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.
Rescorla
Sent: Thursday, March 23, 2017 9:58 AM
To: Fries, Steffen <steffen.fr...@siemens.com>
Cc: TLS WG <tls@ietf.org>
Subject: Re: [TLS] Enforcing stronger server side signature/hash combinations
in TLS 1.2
On Thu, Mar 23, 2017 at 8:37 AM, Fries, Steffen
<steffen.fr
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 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
>
: Thursday, March 23, 2017 8:37 AM
To: TLS WG <tls@ietf.org>
Subject: Re: [TLS] Enforcing stronger server side signature/hash combinations
in TLS 1.2
Hi Erik,
based on your reply my conclusion is that
- there is no (standard compliant) way for a server to use a SHA256
based certi
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
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
26 matches
Mail list logo