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
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
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
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
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
> 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
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
certificates) instead of running an intermediate CA him-/herself
instead. This