[Freeipa-devel] Re: Certificate enrollment, principal names

[Jason Gerard DeRose]

On Wed, 2009-11-04 at 21:44 -0800, Andrew Wnuk wrote:
> On 11/04/2009 05:31 PM, Dmitri Pal wrote: 
> > Andrew Wnuk wrote:
> >   
> > > On 11/04/09 16:16, Nalin Dahyabhai wrote:
> > >     
> > > > On Wed, Nov 04, 2009 at 04:39:40PM -0500, Rob Crittenden wrote:
> > > >   
> > > >       
> > > > > Alternatively you can specify which host(s) can request a
> > > > > certificate for a given service. Use the service-add-member command
> > > > > to add hosts that can request certs for it.
> > > > >      
> > > > >         
> > > > That sounds reasonable.  Is this new post-1.9.0?  I can add members to
> > > > various groups, but there's no service-add-member command yet.
> > > > 
> > > >   
> > > >       
> > > > > A couple of tidbits:
> > > > > 
> > > > > - In 1.9.0 we'll issue a certificate for any subject requested.
> > > > > dogtag has a fix that we will be able to use once it's released that
> > > > > will let us pull the CN from the request and use just that with the
> > > > > subject and use a fixed value for the rest.
> > > > >      
> > > > >         
> > > > That sounds good -- the default request subject is just 'CN=hostname'
> > > > unless it's told different.
> > > > 
> > > >   
> > > >       
> > > > > - The management framework doesn't do anything to the CSR right now,
> > > > > it literally just passes it onto the CA for processing.
> > > > > - The whole ugly client IP thing has been ripped out post 1.9.0.
> > > > > - I still compare the hostname in the subject with the hostname of
> > > > > the service. This is unfortunately currently broken in python
> > > > > 2.4-based systems.
> > > > >      
> > > > >         
> > > > If we're requiring that every certificate has an associated principal
> > > > name, then ensuring it agrees with the hostname in the subject field
> > > > makes a lot of sense.  I'd kind of like to see both a dnsName and a
> > > > Kerberos principal name added to the subjectAltName fields in the issued
> > > > certificate, but that's as much because we can as anything else.
> > > > 
> > > >   
> > > >       
> > > > > - I'm not opposed to including more "stuff" into the CSR itself we
> > > > > just need to be sure the average admin who doesn't want to use
> > > > > certmonger can still make a request too.
> > > > >      
> > > > >         
> > > > NSS's certutil can trivially add dns and email subjectAltName (SAN)
> > > > values and extendedKeyUsage (EKU) values.  I don't see a flag for adding
> > > > a Kerberos principal name.  OpenSSL's req command doesn't do most of
> > > > that by default, but the configuration file can be used to tell it to do
> > > > any of that.  It could be scripted, for sure.
> > > > 
> > > >   
> > > >       
> > > > > Right now the bar is pretty
> > > > > low to understanding what is required IMHO with the exception of
> > > > > pasting in the ugly one-line CSR :-(
> > > > >      
> > > > >         
> > > > Yeah, it took me a while to figure out that that was how we were
> > > > supposed to pass it in.
> > > >    
> > > >       
> > > Passing entire CSR as a parameter to ipa command could avoided if
> > > XML-RPC framework would provide pre and post processing callbacks on
> > > the client side. Parameters could be used to describe CSR (instead of
> > > passing entire CSR), pre-processing callback could generate CSR based
> > > on provided description, then XML-RPC call could submit generated CSR
> > > and finally post-processing callback could properly place obtained
> > > certificate.
> > > 
> > >     
> > I though we talked about these callbacks a year ago and planned to do them.
> > Was this work ever finished?
> > 
> >   
> Jason, are there any dedicated pre and post processing callbacks
> available on the client side without using get_default for
> pre-processing and and display callback for post-processing?

Sorry, I didn't read the thread in order...

I swore we added a post-process hook that took the same signature as
output_for_cli(), but I don't see it now.

Anyway, there are several ways you can approach this depending on your
exact needs, and we can add explicit hooks once the use case is well
defined.

First of all, why will using a create_default callback for the csr not
work?  I vaguely remember you explaining this before, but I've forgotten
the details.

As far as generalized pre/post hooks, there are 4 places they could make
sense: at the start and end of __call__(), and at the start and end of
run(), like this sort of thing:

    def __call__(self, *args, **options):
        self.pre_call()
        self.run(*args, **options)
        self.post_call()

    def run(self, *args, **options):
        self.pre_run()
        super(Foo, self).run(*args, **options)
        self.post_run()

You have to decide whether your pre hook should happen before or after
the normalization/conversion/validation round or after it.  We are
adding return value validation also, so the same thing needs to be
decided for the post hook.  Also, does the post hook need to change the
return value, or just take some action based on it?