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
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
Hello,
I'm working on an internet draft describing application-level analog of
CRLs.
I named the proposed file format Certificate Limitation Profile.
I think that current model of trust when only CAs can revoke the
certificates
issued by them does not fit current situation, and we also need