[openssl-dev] Certificate Limitation Profile

Dmitry Belyavsky beldmit at gmail.com
Tue Nov 28 19:11:43 UTC 2017


Dear Kurt,

On Tue, Nov 28, 2017 at 3:25 PM, Kurt Roeckx <kurt at roeckx.be> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20171128/dd99ab79/attachment.html>


More information about the openssl-dev mailing list