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

[Martin Kosek]

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.