[Freeipa-devel] Revoking user/service/host certificates

[Martin Kosek]

On 05/18/2015 03:36 PM, Fraser Tweedale wrote:
> On Mon, May 18, 2015 at 11:51:41AM +0200, Martin Kosek wrote:
>> Hi Fraser (and list),
>>
>> Recently, we have proposed 2 new policies for treating user/host/service
>> certificates based on the per-profile policy:
>>
>> a) If certificate is stored in userCertificate attribute
>> b) If the certificate is stored and object deleted/disabled, if the certificate
>> should be also revoked
>>
>> Details in:
>> http://www.freeipa.org/page/V4/User_Certificates#Configuration
>>
>> a) is straightforward. However, I was not thinking more about case b). When
>> object is deleted/disabled, how will framework tell what is the profile to
>> check the policy?
>>
>> Will it ask Dogtag via some API call? Or will the profile me stored in the
>> certificate itself, just like MS CA does for some certificates?
>>
> That information is stored in Dogtag, but I don't think there's
> currently a straightforward way to get at it.  Having it stored in
> Dogtag (only) would necessitate first contacting Dogtag and looking
> up the profile for each certificate to find out whether we should
> revoke or not.
> 
> I do not think we should implement anything that relies on the MS
> "certificate template" extension (in case it is not wanted, or even
> causes problems for some application).

I see.

> But let us take a step back - is there a situation where for one
> profile (for which ipaCertProfileStoreIssued == True) we would want
> to automatically revoke when principal deleted, and for another
> profile not revoke?  Or would it be better as a global setting or a
> {user,host,service}-del option?

An option would definitely be a good start, if we do not go with the
per-profile setting. Simo/Rob/others, what is your opinion here, given there is
a big difficulty in implementing per-profile policy for revoking the
certificate? Should we instead have a global configuration that would say

A) Revoke all certificates in userCertificate attribute (i.e. long term
certificates)
B) Do not revoke them

and have the option to force a change to the behavior?

> We would also need to work out a revocationReason; we could use
> "unspecified" to start with, but can we / should be provide
> something richer?

Right now, when service or host is disabled/deleted, we use revocation reason

    * 4 - superseded

Martin

> 
> Cheers,
> Fraser
> 
>> Thanks.
>>
>> -- 
>> Martin Kosek <mkosek at redhat.com>
>> Supervisor, Software Engineering - Identity Management Team
>> Red Hat Inc.