Dear Victor,

On Tue, Nov 28, 2017 at 11:14 PM, Viktor Dukhovni <> wrote:

> On Tue, Nov 28, 2017 at 07:18:48PM +0000, 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 it then becomes
> difficult to ascertain freshness.  How do you know that you're not
> usign a much too stale version of the CLP, that fails to include a
> recently deprecated trust anchor.
> Therefore, one needs to be careful to not rely *solely* on the
> signature of the CLP payload.  It is still important to get a fresh
> copy from a trusted source sufficiently often.

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 update mechanism allows fresh enough CLP.

On the other hand enforcing freshness can cause difficulties in situation
when an application becomes unsupported on a specific version of platform
(e.g. stale version of Android/iOS).

SY, Dmitry Belyavsky
openssl-dev mailing list
To unsubscribe:

Reply via email to