Dear Kurt, On Tue, Nov 28, 2017 at 3:25 PM, Kurt Roeckx <k...@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.
-- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev