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. -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code