Re: [openssl-dev] Certificate Limitation Profile

[Viktor Dukhovni]

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 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).

Perhaps a sensible way to handle nextUpdate is to refuse to import
a purportedly fresh CLP whose nextUpdate has expired or is older
than what you have.  If an application is failing to get updates,
then it can continue to run with what it has.

The idea is to prevent "rollback" attacks, more than fail closed
on expired CLPs when nothing fresh is available.

-- 
Viktor.
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Certificate Limitation Profile

[Dmitry Belyavsky]

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 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: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Certificate Limitation Profile

[Viktor Dukhovni]

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 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.

-- 
Viktor.
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Certificate Limitation Profile

[Blumenthal, Uri - 0553 - MITLL]

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.

But it seems to me that if CLP is signed by the certificate that can be 

verified using standard chain of trust, it has some advantages. 

 

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.



smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Certificate Limitation Profile

[Dmitry Belyavsky]

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 think that policy will be distributed and
> why it needs signed. I expect that there will always be some way
> of authenticating the document if you download it without requiring
> that the document is signed itself. 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.
But it seems to me that if CLP is signed by the certificate that can be
verified using standard chain of trust, it has some advantages.


> If it's signed, who will be signing it, and how does the
> application know which key to use to verify the signature?
>

I think that if the CLP is native for the application, the key/cert
should be hard coded in the app itself.

If we use an external one (e.g. issued by Mozilla or Chrome), we can
specify the certificate in app's config and verify the certificate after
constructing the chain of trust from the roots.


>
> I can also imagine that users might wish to modify that file,
> for instance add an internal CA or certificate, not trust some
> CA, ... They could of course generate their own key, and tell the
> software to use that key.
>

Yes, it's a possible mode of operation. But if we allow unsigned CLPs,
the own key can become unnecessary.
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Certificate Limitation Profile

[Kurt Roeckx]

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 always be some way
of authenticating the document if you download it without requiring
that the document is signed itself. 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.

If it's signed, who will be signing it, and how does the
application know which key to use to verify the signature?

I can also imagine that users might wish to modify that file,
for instance add an internal CA or certificate, not trust some
CA, ... They could of course generate their own key, and tell the
software to use that key.


Kurt

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] Certificate Limitation Profile

[Dmitry Belyavsky]

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 app-level
limitations,
as browser vendors (Google, Mozilla) already do.

Currently such limitations are hard coded into the particular software.
Being standardized, it will be possible to reuse such limitations across
various applications and avoid hard-coding.

Here is the link to the draft:
https://datatracker.ietf.org/doc/draft-belyavskiy-certificate-limitation-policy/

The current version of the draft (hopefully) describes necessary ASN.1
structures
that are enough for the most practical cases. I have middle-term plans to
provide a support of the draft in OpenSSL, if the idea seems interesting
enough.

Any feedback is welcome.

Thank you!

-- 
SY, Dmitry Belyavsky
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev