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
Attachment:
signature.asc
Description: This is a digitally signed message part.
-- security mailing list security@xxxxxxxxxxxxxxxxxxxxxxx https://lists.fedoraproject.org/admin/lists/security@xxxxxxxxxxxxxxxxxxxxxxx
