Hi Hannes,
On 24/04/2017 16:39, "Hannes Tschofenig" wrote:
> On 04/21/2017 12:48 PM, Ilari Liusvaara wrote:
> > Regarding clients, I think the draft specifies LURK as backup plan
> > for clients that don't support subcerts (which causes some extra
> > latency if triggered).
> I didn't got that im
On Mon, Apr 24, 2017 at 05:39:39PM +0200, Hannes Tschofenig wrote:
> Hi Ilari,
>
> thanks for your response. A few remarks inline:
>
> On 04/21/2017 12:48 PM, Ilari Liusvaara wrote:
> > On Fri, Apr 21, 2017 at 10:37:21AM +0200, Hannes Tschofenig wrote:
> >> I read through draft-rescorla-tls-subce
> included in browser trust stores, etc.). We haven't had a good delegation
> story since, like, ever, but now there's a somewhat compelling use case
> (CDNs) that needs attention and will benefit from a solution.
Emphasis on the somewhat.
___
TLS ma
On 4/24/17 7:39 AM, Hannes Tschofenig wrote:
>> There is enormous amount of red tape obtaining intermediates, even
>> technically constrained ones. And as consequence, it is enormously
>> expensive (through not nearly as expensive as public CA).
> In essence you are doing this through the extension
Hi Ilari,
thanks for your response. A few remarks inline:
On 04/21/2017 12:48 PM, Ilari Liusvaara wrote:
> On Fri, Apr 21, 2017 at 10:37:21AM +0200, Hannes Tschofenig wrote:
>> I read through draft-rescorla-tls-subcerts-01 and I ran into some basic
>> questions.
>>
>> I have been wondering why th
On 21/04/2017 16:50, "Salz, Rich" wrote:
> > Speaking as one of the co-authors of [1]: it is not completely clear to me
> > what is the limitation in CT that would prevent it to cope with the
> > pervasive use of short-term certificates. Can anyone shed a light on this?
>
> I believe the concern
> Speaking as one of the co-authors of [1]: it is not completely clear to me
> what
> is the limitation in CT that would prevent it to cope with the pervasive use
> of
> short-term certificates. Can anyone shed a light on this?
I believe the concerns are scaling log servers and perhaps needing
On 21/04/2017 11:48, "TLS on behalf of Ilari Liusvaara" wrote:
On Fri, Apr 21, 2017 at 10:37:21AM +0200, Hannes Tschofenig wrote:
> > What is also not clear to my why some of the certificate management
> > protocols, which provide the necessary level of automation, cannot be
> > used with CAs to r
On Fri, Apr 21, 2017 at 10:37:21AM +0200, Hannes Tschofenig wrote:
> I read through draft-rescorla-tls-subcerts-01 and I ran into some basic
> questions.
>
> I have been wondering why the TLS server operator obtains an end-entity
> certificate from a CA (which cannot be used to sign further
> cert
On Fri, Jul 15, 2016 at 05:34:40PM +, Andrei Popov wrote:
> > The I-D actually covers this.
> Understood; the I-D lists a few cons, but arguably none of them are
> blocking issues. It seems unnecessary to create a new TLS-specific
> mechanism that duplicates existing PKI semantics.
IMO, the dr
On 07/15/2016 12:34 PM, Andrei Popov wrote:
>> The I-D actually covers this.
> Understood; the I-D lists a few cons, but arguably none of them are blocking
> issues. It seems unnecessary to create a new TLS-specific mechanism that
> duplicates existing PKI semantics.
>
I think the main justifica
ES/KS
> split, sometimes short-lived certs would be more useful.
Possibly so.
Cheers,
Andrei
-Original Message-
From: ilariliusva...@welho.com [mailto:ilariliusva...@welho.com]
Sent: Friday, July 15, 2016 2:14 AM
To: Andrei Popov
Cc: Eric Rescorla ; tls@ietf.org
Subject: Re: [TLS] draft
On Fri, Jul 15, 2016 at 12:28:18AM +, Andrei Popov wrote:
> Naïve question: why not simply get a constrained CA certificate and
> issue short-validity end entity certs? Unless I’m missing something,
> this would work with existing TLS implementations, no extensions
> required.
The I-D actually
> Naïve question: why not simply get a constrained CA certificate and issue
> short-validity end entity certs?
Wouldn't you need one for every potential user? And the nameConstraints then
becomes a union of all SAN fields?
> Short-lived credential approach seems more viable than
> draft-mglt-l
Naïve question: why not simply get a constrained CA certificate and issue
short-validity end entity certs? Unless I’m missing something, this would work
with existing TLS implementations, no extensions required.
Short-lived credential approach seems more viable than
draft-mglt-lurk-tls-requirem
On Thu, Jul 7, 2016 at 7:29 PM Watson Ladd wrote:
> I don't think we can use name constraints here. Yes, they are opt-in
> and clients can indicate support, but it may well be that a TLS
> implementation doesn't know if its X509 validation code will support
> them as it hands the certificate to a
On Fri, Jul 8, 2016 at 6:09 AM, Ilari Liusvaara
wrote:
>
> There is validity start time in there, the relative end time would
> be relative to that.
>
> That is, instead of saying "this is valid from t1 to t2", saying "this
> is valid from t to t+dt".
>
> No real perference either way, it was jus
On Thu, Jul 07, 2016 at 07:29:08PM -0700, Watson Ladd wrote:
> On Jul 7, 2016 12:29 PM, "Eric Rescorla" wrote:
>
> How about limit to ECDSA certificates? This eliminates the
> Bleichenbacher issues. We can also make this opt in via an extension
> to the EE certificate: since the certificate is no
On Thu, Jul 07, 2016 at 08:08:11PM -0400, Kyle Rose wrote:
> On Thu, Jul 7, 2016 at 6:13 PM, Ilari Liusvaara
> wrote:
>
> >
> > I also checked if one could do some funky stuff with credential lifetime
> > notation to limit the lifetime. Nothing came up (apart for using 16-bit
> > count in decasec
Eric:
I have not had a chance to look at the draft yet, but based on your cover note
you seem to have several requirements in common with RFC 3820.
Russ
On Jul 7, 2016, at 3:28 PM, Eric Rescorla wrote:
> We've talked several times about designing some sort of TLS delegation
> mechanism. A fe
Eric Rescorla writes:
>We've talked several times about designing some sort of TLS delegation
>mechanism. A few of us got together and put together some initial thoughts
>about the options at:
>https://www.ietf.org/id/draft-rescorla-tls-subcerts-00.txt
That's going to be a tricky one. The PKIX
On Jul 7, 2016 12:29 PM, "Eric Rescorla" wrote:
>
> We've talked several times about designing some sort of TLS delegation
> mechanism. A few of us got together and put together some initial thoughts
> about the options at:
> https://www.ietf.org/id/draft-rescorla-tls-subcerts-00.txt
>
> The gener
On Thu, Jul 7, 2016 at 6:13 PM, Ilari Liusvaara
wrote:
>
> I also checked if one could do some funky stuff with credential lifetime
> notation to limit the lifetime. Nothing came up (apart for using 16-bit
> count in decaseconds (das) only allowing presenting lifetimes up to 7
> days, 14 hours, 2
On Thu, Jul 7, 2016 at 3:13 PM, Ilari Liusvaara
wrote:
> On Thu, Jul 07, 2016 at 12:28:33PM -0700, Eric Rescorla wrote:
> > We've talked several times about designing some sort of TLS delegation
> > mechanism. A few of us got together and put together some initial
> thoughts
> > about the options
On Thu, Jul 07, 2016 at 12:28:33PM -0700, Eric Rescorla wrote:
> We've talked several times about designing some sort of TLS delegation
> mechanism. A few of us got together and put together some initial thoughts
> about the options at:
> https://www.ietf.org/id/draft-rescorla-tls-subcerts-00.txt
>
25 matches
Mail list logo
