[Freeipa-devel] User Certificates in 4.2 - design and questions

[Fraser Tweedale]

On Tue, May 05, 2015 at 08:38:28AM +0200, Martin Kosek wrote:
> On 05/04/2015 09:23 PM, Simo Sorce wrote:
> > On Mon, 2015-05-04 at 16:41 +0200, Martin Kosek wrote:
> >> On 05/04/2015 03:01 PM, Fraser Tweedale wrote:
> >>> On Mon, May 04, 2015 at 10:50:15AM +0200, Martin Kosek wrote:
> >>>> Hello,
> >>>>
> >>>> Please let me promote the design for one of the major FreeIPA 4.2 features, the
> >>>> (user) certificates and Smart Card integration:
> >>>>
> >>>> http://www.freeipa.org/page/V4/User_Certificates
> >>>>
> >>>> The design went through couple interim discussions between developers outside
> >>>> of this list, so there should not be too many objections. But still, please
> >>>> free to comment or improve the design yourself.
> >>>>
> >>>> For FreeIPA 4.2, I think this resolves in following, quite limited, scope of work:
> >>>> * Adding eq, pres indices for userCertificate
> >>>> * Applying new policy of storing certificate in userCertificate attribute,
> >>>> based on upcoming Certificate Profile feature by Fraser.
> >>>> * Making sure that multiple certificates can be added to userCertificate
> >>>> attribute manually by CLI and UI
> >>>>
> >>>> The "Certificate Identity Mapping" part will probably be moved to 4.3+, unless
> >>>> there is extra pool of development resources.
> >>>>
> >>>> There is still something to be resolved - how should the certificates be
> >>>> revoked in object-del or object-disable actions? Currently, certificate is
> >>>> always stored in userCertificate and it's serial is used for revoke operation
> >>>> in Dogtag. But that will not be true in 4.2+ since some certificates will not
> >>>> be stored in accounts.
> >>>>
> >>>> Do we only want to revoke those that have policy to be stored in the
> >>>> userCertificate attribute? Does not sound right to me. Or do we need a Dogtag
> >>>> API that would allow us to query (or even revoke directly) all certificates
> >>>> generated for a user/service/host and revoke them, regardless whether they are
> >>>> stored in userCertificate attribute or not?
> >>>>
> >>> If the DN or other searchable attributes bear a principal name,
> >>> existing APIs should be sufficient (if a little awkward).  But
> >>> Dogtag does not know about principals, it only knows what is on the
> >>> cert (and a few other things, like the profile that was used).
> >>
> >> Kerberos principal SAN is added when the certificate is requested via
> >> Certmonger, but we do not add it when requested via cert-request command (yet).
> >> So we cannot depend on it.
> >>
> >>> Later, when we implement GSSAPI and ACL enforcement in Dogtag
> >>> (https://fedorahosted.org/freeipa/ticket/5011) we can also store the
> >>> principal that issued the certificate for a concrete association in
> >>> Dogtag, which can be used to locate certificates for a principal.
> >>
> >> Right, sounds as something we should do. I commented in the ticket.
> >>
> >>> Considering known use cases in which one would not want to store the
> >>> issued cert in IPA, some of these have short lived certs so
> >>> revocation is not an issue.  With that in mind I think it would be
> >>> OK, for 4.2 at least, to not provide a way in IPA to revoke a cert
> >>> that was issued via IPA but not stored; it can still be revoked
> >>> using Dogtag directly, and we could provide pointers to Dogtag
> >>> documentation.  The important thing is to manage the user
> >>> expectations for 4.2.
> >>
> >> Hm, maybe - Simo, if you disagree, please shout. In this case, we would need to
> >> make sure this side effect of the userCertificate policy is very well documented.
> > 
> > I do not disagree, in most cases when a user (or computer object) is
> > deleted, there is really no need to actually revoke the cert.
> > Keep in mind that revocation list growth is also a concern.
> 
> Right. IIRC some of our users had problems with CRL list size also, making us
> to create ticket
> 
> https://fedorahosted.org/freeipa/ticket/4048
> 
> > So I am fine *not* revoking certs automatically and instead documenting
> > best practices for certs lifecycle management (ie deleting certs when
> > not useful) and how to manually/explicitly revoke certs only when
> > actually compromised (for hosts), or when needed (user leaves
> > organization and may retain a copy of the private key, unlikly when the
> > cert was in a Smart Card which has been returned and wiped).
> 
> Well, makes sense to me. I added a section to the design:
> http://www.freeipa.org/page/V4/User_Certificates#Revocation_of_the_Certificates
> 
> We just need to be cautious here because this would be a change in behavior
> compared to FreeIPA 4.1 and older. Should this be another global/per-profile
> policy setting that administrator could set up?

Since the design no longer includes storing certificate metadata
(this includes the profile used) it cannot be a per-profile setting.
It could be a global config and/or an option to cert-del.

Also, we are already changing some of the behaviour about
revocation - cert-request will no longer revoke previous
certificate(s).  If other changes are needed, now is a good time.