Certificate Limitation Profile

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Certificate Limitation Profile

Dmitry Belyavsky-3
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:

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
Reply | Threaded
Open this post in threaded view
|

Re: 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
Reply | Threaded
Open this post in threaded view
|

Re: Certificate Limitation Profile

Dmitry Belyavsky-3
Dear Kurt,

On Tue, Nov 28, 2017 at 3:25 PM, Kurt Roeckx <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

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


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

smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Certificate Limitation Profile

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

--
        Viktor.
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Certificate Limitation Profile

Dmitry Belyavsky-3
Dear Victor,

On Tue, Nov 28, 2017 at 11:14 PM, Viktor Dukhovni <[hidden email]> 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: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: 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