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.
>
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
I'm reading there as being no consensus to make this change, so I plan not
to absent chair directive.
-Ekr
On Mon, Apr 24, 2017 at 6:26 AM, Ryan Sleevi
wrote:
>
>
> On Mon, Apr 24, 2017 at 3:58 AM, Nikos Mavrogiannopoulos
> wrote:
>
>>
>> That's
On Mon, Apr 24, 2017 at 3:58 AM, Nikos Mavrogiannopoulos
wrote:
>
> That's intentional.
And misguided. It violates the layering.
> Not every application is firefox or chrome and thus
> application writers cannot be expected to set sane defaults for OCSP
> validity time _when
> The TLS 1.3 specification isn't the right place to specify what to do with
> OCSP responses that do not have a nextUpdate field.
When phrased like this, it seems completely obvious to me that this correct.
___
TLS mailing list
TLS@ietf.org
Ryan Sleevi wrote:
> On Sat, Apr 22, 2017 at 5:42 PM, Kurt Roeckx wrote:
>>
>> So for OCSP of a subordinate CAs there doesn't seem to be any
>> requirement for a nextUpdate.
>>
>
> Correct. This is part of the many asynchronicities related to CRLs and
>
On Sun, 2017-04-23 at 12:01 -0400, Ryan Sleevi wrote:
> >
> > As for what the TLS library I have written does if OCSP staple
> > lacks
> > NextUpdate, it outright causes handshake failure and fatal alert.
>
> So far, the preference on our end has been for a TLS library that
> doesn't have to
Ilari Liusvaara writes:
> > On Fri, Apr 21, 2017 at 10:52 AM, Nikos Mavrogiannopoulos
> > wrote:
> >
> > > My issue with OCSP when used under TLS was how to determine the
> > > validity of the response when the nextUpdate field is missing. I've
> > >
On Sun, Apr 23, 2017 at 12:01:08PM -0400, Ryan Sleevi wrote:
> > And the 12 month update interval for intermediates is IMO just crazy,
> > and won't work properly in TLS 1.3, now that multistaple is pretty much
> > a baseline feature.
> >
>
> I have no desire to support multistaple within Chrome.
On Sun, Apr 23, 2017 at 12:01:08PM -0400, Ryan Sleevi wrote:
> On Sun, Apr 23, 2017 at 6:34 AM, Ilari Liusvaara
> wrote:
>
> > And the 12 month update interval for intermediates is IMO just crazy,
> > and won't work properly in TLS 1.3, now that multistaple is pretty
On Sun, Apr 23, 2017 at 6:34 AM, Ilari Liusvaara
wrote:
>
> I meant if anyone has seen a OCSP response from "public" CA lately that
> lacks NextUpdate.
>
Why would it matter? Are you suggesting we determine what should be part of
TLS based on what CAs are doing? That's
On Sat, Apr 22, 2017 at 11:42:06PM +0200, Kurt Roeckx wrote:
> On Sat, Apr 22, 2017 at 03:00:17PM +0300, Ilari Liusvaara wrote:
> > On Sat, Apr 22, 2017 at 07:53:50AM -0400, Eric Rescorla wrote:
> > > On Fri, Apr 21, 2017 at 10:52 AM, Nikos Mavrogiannopoulos
> > >
> > > wrote:
>
On Sat, Apr 22, 2017 at 5:42 PM, Kurt Roeckx wrote:
>
> So for OCSP of a subordinate CAs there doesn't seem to be any
> requirement for a nextUpdate.
>
Correct. This is part of the many asynchronicities related to CRLs and OCSP
in the BRs (another example:
On Sat, Apr 22, 2017 at 03:00:17PM +0300, Ilari Liusvaara wrote:
> On Sat, Apr 22, 2017 at 07:53:50AM -0400, Eric Rescorla wrote:
> > On Fri, Apr 21, 2017 at 10:52 AM, Nikos Mavrogiannopoulos
> > wrote:
> >
> > > On Tue, 2017-04-11 at 13:47 -0700, Eric Rescorla wrote:
> > >
> >
On Sat, Apr 22, 2017 at 07:53:50AM -0400, Eric Rescorla wrote:
> On Fri, Apr 21, 2017 at 10:52 AM, Nikos Mavrogiannopoulos
> wrote:
>
> > On Tue, 2017-04-11 at 13:47 -0700, Eric Rescorla wrote:
> >
> > > Do you have any thoughts on what text we should insert here? I admit
> > >
On Tue, 2017-04-11 at 13:47 -0700, Eric Rescorla wrote:
> > 4.1.1. HelloRetryRequest how many times can it be re-sent by the
> > server? I assume only a single one, but it maybe good to make it
> > explicit.
>
> This is forbidden in S 4.1.4.
>
On Tue, Apr 11, 2017 at 2:25 PM, Ilari Liusvaara
wrote:
> On Tue, Apr 11, 2017 at 01:47:08PM -0700, Eric Rescorla wrote:
> > Thanks for your comments.
> >
> > > 4.1.2. It is not defined what a server should do if encountered with a
> > > ProtocolVersion of TLS 1.3.
> >
On Tue, Apr 11, 2017 at 01:47:08PM -0700, Eric Rescorla wrote:
> Thanks for your comments.
>
> > 4.1.2. It is not defined what a server should do if encountered with a
> > ProtocolVersion of TLS 1.3.
>
> https://tlswg.github.io/tls13-spec/#supported-versions says:
>
>If this extension is
Thanks for your comments.
> 1.2. Major Differences from TLS 1.2
> It is very hard to make use of this section as is. It is organized on
> per-draft, while it would be expected to have the changes of the
> document since TLS 1.2. It contains phrases like "Remove spurious
> requirement to
On Wed, 2017-03-29 at 16:28 +0200, Nikos Mavrogiannopoulos wrote:
> A more general note on the section/document, is that although the
> PKIX
> identity (certificate) is protected from passive adversaries, the PSK
> identity is not. This is a discrepancy in terms of protecting the
> user's
Hi,
In this mail I summarize my comments for draft-ietf-tls-tls13-19
(which I have read but not implemented). They include both editorial
comments and content comments. Overall this is a very good document,
congratulations to everyone involved.
On the following text, I use the format Section
21 matches
Mail list logo