[Freeipa-devel] my remaining 4.2 tickets

[Fraser Tweedale]

On Fri, Jul 03, 2015 at 08:23:45AM +0200, Martin Kosek wrote:
> On 07/02/2015 05:58 PM, Jan Cholasta wrote:
> >Hi,
> >
> >Dne 2.7.2015 v 17:18 Fraser Tweedale napsal(a):
> >>On Tue, Jun 30, 2015 at 03:46:08PM +0200, Martin Kosek wrote:
> >>>On 06/30/2015 03:03 PM, Fraser Tweedale wrote:
> >>>>#2915 ipa-getcert does not allow setting specific EKU on
> >>>>certificates
> >>>>
> >>>>     Involves certmonger so I will need to do a bit more
> >>>>     investigation.
> >>>>
> >>>>     If non-trivial to accomplish this with the default profile, now
> >>>>     that we have support for multiple profiles it could be done with
> >>>>     a separate profile, as long as certmonger passes the profile
> >>>>     propertly with `-T' argument.  I will follow up on this tomorrow
> >>>>     and let you know what I find out.
> >>>
> >>>Ok. I was not involved when the ticket was filed, but it does not seem to me as
> >>>something that should get much priority and your time at this stage.
> >>>
> >>I haven't looked at this yet.
> >
> >FYI getcert supports setting EKU in the CSR using the -U option for a long
> >time. It also correctly passes the profile to IPA since 0.78.
> >
> >>
> >>>>#4970   Server certificate profile should always include a Subject
> >>>>Alternate name for the host
> >>>>
> >>>>     If a subjectAltName request extension is in CSR, it is checked
> >>>>     by `cert-request', and copied onto the final certificate by
> >>>>     Dogtag.  In the default profile there is currently no other way
> >>>>     to specify the SAN.
> >>>>
> >>>>     A possible approach to resolve this with the default profile is
> >>>>     to update it to include a separate, optional subjectAltName
> >>>>     request input, which could be filled in if explicit SAN is not
> >>>>     provided in CSR.  There are related lines of investigation.
> >>>>     Will provide update tomorrow.
> >>>
> >>>Ok.
> >>>
> >>I investigated this.  My comments are on the ticket:
> >>https://fedorahosted.org/freeipa/ticket/4970#comment:7 but in brief:
> >>the way our current SAN support is implemented makes this a
> >>non-trivial ticket.
> >
> >On a related note, I think we should also always include kerberos principal
> >name SAN.
> 
> That would be nice, how difficult is to enable this with certificates
> FreeIPA issues? It would also let us make easier principal-based queries for
> Dogtag certificates. Right?
> 
We could do it with a new ProfileInput class in Dogtag, possibly
(probably) also requiring a new ProfileDefault class, and of course
and update of the included profile(s) where we want this behaviour.

I have a bolder vision for the future of Dogtag/IPA integration.  I
have had a some thoughts brewing in my mind for a while, ready to
unleash after rhel72 crunch, but oh well, now you are making me
reveal my ideas, hopefully not too prematurely :)

    In the medium-term we want to connect Dogtag (components
    thereof) to the IPA directory to read and enforce caacls.  We
    also wish to use s4u2proxy to avoid all-powerful RA Agent cert
    and have Dogtag act with authenticated principal's authority.

    Since we will be talking to the IPA directory, we can create new
    profile components that read information directly out of the IPA
    directory.  This will make it much simpler to pull fancy
    extension data or other information into certificates issued by
    Dogtag, all defined by profiles.

    These components can even be shipped as part of FreeIPA, as only
    FreeIPA-provided profiles would use them, and I believe it is
    fairly straightforward to tell Dogtag about "3rd-party" classes.
    This gives us agility to include support for pulling data from
    IPA directory into certificates without depending on Dogtag
    release cycle.

    This sort of regime may also make it easier to tackle the
    desired "profile builder" feature.

    Finally, since it is JVM .class files we will be shipping we can
    write it using FP in Scala ^_^

Cheers,
Fraser