Re: restricting the scope of CA certificates
On Friday 03 June 2016 15:14:23 Tomas Mraz wrote: > On Pá, 2016-06-03 at 15:06 +0200, Nikos Mavrogiannopoulos wrote: > > On Fri, 2016-06-03 at 14:30 +0200, Tomas Mraz wrote: > > > > Sorry, I didn't realize that my question was worded ambiguously. > > > > > > > > Let me rephrase it: Is it possible to express that only the Red > > > > Hat > > > > internal CA may issue certificates under *.corp.redhat.com, and > > > > no > > > > other > > > > CAs may issue certificates for this subtree? > > > > > > Not in the terms of stapled extensions - as the extensions would > > > have > > > to be stapled onto some concrete certificates. You would have to > > > basically create stapled extensions for every CA in your trusted > > > list > > > except for the Red Hat internal CA. And if any additional CA is > > > added > > > to the trusted list, it would have to get this stapled extension > > > too. > > > > Well you could do that by stapling every other certificate than Red > > Hat's with corp.redhat.com being on the excluded subtrees. > > Yes, that's what I wrote above however that would not be very > practical as you would have to monitor the trusted list for additions > and staple them too once they are added. well, if it is really needed, I don't see why we couldn't create some kind of /etc/p11-kit.d directory that houses scripts that will do such transform on certificates on package upgrade/downgrade/reinstall -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic signature.asc Description: This is a digitally signed message part. -- security mailing list security@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/security@lists.fedoraproject.org
Re: restricting the scope of CA certificates
On Fri, 2016-06-03 at 15:14 +0200, Tomas Mraz wrote: > > > Not in the terms of stapled extensions - as the extensions would > > > have > > > to be stapled onto some concrete certificates. You would have to > > > basically create stapled extensions for every CA in your trusted > > > list > > > except for the Red Hat internal CA. And if any additional CA is > > > added > > > to the trusted list, it would have to get this stapled extension > > > too. > > Well you could do that by stapling every other certificate than Red > > Hat's with corp.redhat.com being on the excluded subtrees. > Yes, that's what I wrote above however that would not be very > practical > as you would have to monitor the trusted list for additions and > staple > them too once they are added. Ah, correct. Indeed if ca-certificates is updated an adds new CAs these will not be stapled. I have no idea whether p11-kit has some way to say staple all certificates except that one. regards, Nikos -- security mailing list security@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/security@lists.fedoraproject.org
Re: restricting the scope of CA certificates
On Pá, 2016-06-03 at 13:54 +0200, Florian Weimer wrote: > On 06/03/2016 01:52 PM, Nikos Mavrogiannopoulos wrote: > > > > On Fri, 2016-06-03 at 10:24 +0200, Florian Weimer wrote: > > > > > > On 06/03/2016 09:13 AM, Nikos Mavrogiannopoulos wrote: > > > > > > > > > > > > If you are of the types who like tinkering, here is a way to > > > > restrict > > > > CA certificates in your Fedora on specific domains. Currently > > > > limited > > > > to gnutls applications. > > > > > > > > http://nmav.gnutls.org/2016/06/restricting-scope-of-ca-certific > > > > ates > > > > .html > > > Is there also a way to do the opposite, that is, list which CAs > > > are > > > permitted to issue certificates for certain parts of the DNS > > > tree? > > If your question is whether it is doable, then the answer is yes. > > One > > would need to traverse all existing certificates in the trust > > module > > and use the name constraints extension. In terms of gnutls API > > you'd > > probably like to use call gnutls_x509_crt_import_url() with > > the GNUTLS_PKCS11_OBJ_FLAG_OVERWRITE_TRUSTMOD_EXT flag on all the > > certificate objects in the trust module, and sort their name > > constraints. There is no tool for that though. > Sorry, I didn't realize that my question was worded ambiguously. > > Let me rephrase it: Is it possible to express that only the Red Hat > internal CA may issue certificates under *.corp.redhat.com, and no > other > CAs may issue certificates for this subtree? Not in the terms of stapled extensions - as the extensions would have to be stapled onto some concrete certificates. You would have to basically create stapled extensions for every CA in your trusted list except for the Red Hat internal CA. And if any additional CA is added to the trusted list, it would have to get this stapled extension too. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb (You'll never know whether the road is wrong though.) -- security mailing list security@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/security@lists.fedoraproject.org
Re: restricting the scope of CA certificates
On Fri, 2016-06-03 at 10:24 +0200, Florian Weimer wrote: > On 06/03/2016 09:13 AM, Nikos Mavrogiannopoulos wrote: > > > > If you are of the types who like tinkering, here is a way to > > restrict > > CA certificates in your Fedora on specific domains. Currently > > limited > > to gnutls applications. > > > > http://nmav.gnutls.org/2016/06/restricting-scope-of-ca-certificates > > .html > Is there also a way to do the opposite, that is, list which CAs are > permitted to issue certificates for certain parts of the DNS tree? If your question is whether it is doable, then the answer is yes. One would need to traverse all existing certificates in the trust module and use the name constraints extension. In terms of gnutls API you'd probably like to use call gnutls_x509_crt_import_url() with the GNUTLS_PKCS11_OBJ_FLAG_OVERWRITE_TRUSTMOD_EXT flag on all the certificate objects in the trust module, and sort their name constraints. There is no tool for that though. However, I'd bet that most CAs in that list have no constraints. regards, Nikos -- security mailing list security@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/security@lists.fedoraproject.org
