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. 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). Simo. -- 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