On Tue, Nov 28, 2017 at 11:37:35PM +0300, Dmitry Belyavsky wrote:
> Thank you. It seems reasonable to add nextUpdate field to
> the header of CLP to avoid problems related to using stale CLP.
>
> I expect that fresh CLPs in most cases are delivered via update procedures
> of applications, and
Dear Victor,
On Tue, Nov 28, 2017 at 11:14 PM, Viktor Dukhovni <
openssl-us...@dukhovni.org> wrote:
> On Tue, Nov 28, 2017 at 07:18:48PM +, Blumenthal, Uri - 0553 - MITLL
> wrote:
>
> > I think it makes perfect sense to sign CLP, because it allows you to
> > separate trust in the server
On Tue, Nov 28, 2017 at 07:18:48PM +, Blumenthal, Uri - 0553 - MITLL wrote:
> I think it makes perfect sense to sign CLP, because it allows you to
> separate trust in the server you�re downloading the content from and the
> content itself.
The problem with "data at rest" signatures is that
I'm wondering how you think that policy will be distributed and
why it needs signed. …
For instance it might come as part of some software distribution (like a
browser), and either
you trust all the files in that distribution or you don't.
I agree that an unsigned variant of CLP makes sense.
Dear Kurt,
On Tue, Nov 28, 2017 at 3:25 PM, Kurt Roeckx wrote:
> On Mon, Nov 27, 2017 at 07:56:00PM +0300, Dmitry Belyavsky wrote:
> > Here is the link to the draft:
> > https://datatracker.ietf.org/doc/draft-belyavskiy-
> certificate-limitation-policy/
>
> I'm wondering how you
> I don't know if anyone has ever created any metrics on how far it
> can be scaled. I've certainly not seen it if they have. But there
> are no knownlimitations on this approach (this is the intended
> way to do things).
Our Delphi OpenSSL implementation on Windows mostly uses a single
thread
On Mon, Nov 27, 2017 at 07:56:00PM +0300, Dmitry Belyavsky wrote:
> Here is the link to the draft:
> https://datatracker.ietf.org/doc/draft-belyavskiy-certificate-limitation-policy/
I'm wondering how you think that policy will be distributed and
why it needs signed. I expect that there will