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
>> 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
