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
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
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 intentional.
>
>
> And misguided. It violates t
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 nextUpdate fi
> 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
https://www
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
> OCSP in the BRs (another example: https://
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 hav
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
> > > added some text for that introducing an (arbi
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 much
> > a baseline feature.
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 going to be sadness all aro
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 T
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:
https://cabforum.org/pipermail/public/20
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:
> > >
> > > > Do you have an
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
> > > to being not that
On Fri, Apr 21, 2017 at 10:52 AM, Nikos Mavrogiannopoulos
wrote:
> 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 i
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.
> https://tlswg.github.io/tls13-spec/#hello-retry-reque
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.
> >
> > https://tlswg.github.io
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 not
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 implemen
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 identity
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: Com
22 matches
Mail list logo
