On Mon, 2017-04-24 at 09:26 -0400, Ryan Sleevi wrote:
>
>
> On Mon, Apr 24, 2017 at 3:58 AM, Nikos Mavrogiannopoulos .com> wrote:
> > That's intentional.
>
> And misguided. It violates the layering.
That's a respectable opinion. I disagree.
> > The reason they
> > cannot be expected to do th
On 18/02/2017 02:31, Dr Stephen Henson wrote:
>
> Does this apply to RSASSA-PSS (RSA-PSS signing only) keys in end entity
> certificates too?
>
> For example could a TLS 1.2 server legally present a certificate containing an
> RSASSA-PSS key for an appropriate ciphersuite? Similarly could a clien
On 04/25/2017 07:08 AM, Dr Stephen Henson wrote:
> On 18/02/2017 02:31, Dr Stephen Henson wrote:
>> Does this apply to RSASSA-PSS (RSA-PSS signing only) keys in end entity
>> certificates too?
>>
>> For example could a TLS 1.2 server legally present a certificate containing
>> an
>> RSASSA-PSS key
On 25/04/2017 15:36, Benjamin Kaduk wrote:
> On 04/25/2017 07:08 AM, Dr Stephen Henson wrote:
>> On 18/02/2017 02:31, Dr Stephen Henson wrote:
>>> Does this apply to RSASSA-PSS (RSA-PSS signing only) keys in end entity
>>> certificates too?
>>>
>>> For example could a TLS 1.2 server legally present
On Tue, Apr 25, 2017 at 5:50 AM, Nikos Mavrogiannopoulos
wrote:
>
> So you point is that as long as you don't use OCSP responses there is
> no interoperability issue. That's very interesting point. More
> interestingly you delegate that definition to an application profile.
> Could you refer to s
I have reviewed the draft and I support adoption of this draft. Agree that both
the short-lived certificate and subcerts are addressing a similar issue and
perhaps tradeoffs can be considered.
Thanks
Sanjay
-Original Message-
From: Lurk [mailto:lurk-boun...@ietf.org] On Behalf Of Sean
PR here:
https://github.com/tlswg/tls13-spec/pull/977
On Mon, Apr 24, 2017 at 8:12 PM, Eric Rescorla wrote:
>
>
> On Mon, Apr 24, 2017 at 6:08 PM, Dave Garrett
> wrote:
>
>> On Monday, April 24, 2017 07:21:13 pm Eric Rescorla wrote:
>> > Hence, the following proposal for the complete label, whe
During interop testing with an open-source stack I ran into the following:
CH >
< SH,{EE,Cert,CV,Fin}
alert >
The alert was due to a decode error on CV, and the stack in question sent the
alert in a plaintext record.
The current draft specification has the following text in section 6
On 04/25/2017 10:01 PM, Roelof Du Toit wrote:
>
> During interop testing with an open-source stack I ran into the following:
>
> CH >
>
> < SH,{EE,Cert,CV,Fin}
>
> alert >
>
>
>
> The alert was due to a decode error on *CV*, and the stack in question
> sent the alert in a *plaintext*
On Wed, Apr 26, 2017 at 03:01:40AM +, Roelof Du Toit wrote:
> During interop testing with an open-source stack I ran into the following:
> CH >
> < SH,{EE,Cert,CV,Fin}
> alert >
>
> The alert was due to a decode error on CV, and the stack in question
> sent the alert in a plaintext
You are allowed to out NSS. We know that it's not ideal.
I wrote that code and it's unencrypted for what I think is a good
reason (others very much disagree). In part, it has to do with 0-RTT.
In 0-RTT, we want to ensure that the client is able to continue
sending 0-RTT until the entire server
Unsurprisingly, this was easy to implement. If anyone else is
tracking this closely, I can share a version of NSS that includes this
change (and pretends to be an implementation of -20).
On 26 April 2017 at 07:50, Eric Rescorla wrote:
> PR here:
> https://github.com/tlswg/tls13-spec/pull/977
>
>
12 matches
Mail list logo
