On Mon, 2014-01-20 at 11:07 +0100, Jan Cholasta wrote: > On 17.1.2014 11:39, Jan Cholasta wrote: > > On 10.1.2014 13:34, Martin Kosek wrote: > >> On 01/09/2014 04:49 PM, Simo Sorce wrote: > >>> On Thu, 2014-01-09 at 10:44 -0500, Rob Crittenden wrote: > >>>> Martin Kosek wrote: > >>>>> On 01/09/2014 03:12 PM, Simo Sorce wrote: > >>> > >>>>>>> Also maybe we should allow admins to bypass the need to have an > >>>>>>> actual > >>>>>>> object to represent the alt name ? > >>>> > >>>> I'd rather not. This would allow a rogue admin to create a cert for > >>>> www.google.com. Sure, they could also create a host for that but > >>>> forcing > >>>> them to add more entries increases the chances of them getting caught > >>>> doing it. > >>> > >>> They can remove the host right after they create a cert, I honestly do > >>> not think this is a valid concern. If your admin is rouge he can already > >>> take full ownership of your infrastructure in many ways, preventing > >>> setting a name in a cert doesn't really make a difference IMO. > >>> > >>> However I would be ok to limit this to some new "Security Admin/CA > >>> Admin" role that is not assigned by default. > >>> > >>> Simo. > >>> > >> > >> Ok, let's reach some conclusion here. I would really like to not defer > >> this > >> feature for too long, it is quite wanted. Would creating new virtual > >> operation > >> "Request certificate with SAN" make the situation better? It would not > >> be so > >> difficult to do, the check_access function can already access virtual > >> operation > >> name as a parameter, we just need to call it. > > > > Why don't we treat SAN hostnames the same way as the subject hostname? > > The way I see it, with SAN the only difference is that there is a set of > > hostnames instead of just a single hostname, so maybe we should support > > requesting a certificate for a set of hosts/services instead of just a > > single host/service. > > > > As far as authorization is concerned, currently you can request a > > certificate for a single host/service, if you have the "Request > > certificate" permission and write access to the host/service entry. With > > multiple hosts/services, you would be able to request a certificate if > > you have the "Request certificate" permission and write access to *all* > > of the host/certificate entries you are requesting the certificate for. > > > > Effectively this means that cert-request would accept multiple > > principals instead of single principal and the automatic revocation code > > in cert-request, host-del and service-del would take into account that a > > single certificate might be assigned to multiple entities. > > > > See attachment for patch which implements the above design.
Hi Jan, I am a bit too far removed from the code to fully understand the change just from the diff. Could you please add a short explanation in the commit message, a bout what the code does now differently than it did before. For example although I understand the checks you do on subjectname +subjectaltname I do not know where the principals come from or why you have a comment that says principals must all be of the same service type. Simo. -- Simo Sorce * Red Hat, Inc * New York _______________________________________________ Freeipa-devel mailing list [email protected] https://www.redhat.com/mailman/listinfo/freeipa-devel
