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).
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. 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. > Thanks. > > -- > Martin Kosek <mko...@redhat.com> > Supervisor, Software Engineering - Identity Management Team > Red Hat Inc. -- 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