[Freeipa-devel] Yet another user certificates/Smart Card thread

[Martin Kosek]

On 05/25/2015 04:40 PM, Jan Cholasta wrote:
> Dne 25.5.2015 v 16:26 Fraser Tweedale napsal(a):
>> On Mon, May 25, 2015 at 03:56:46PM +0200, Martin Kosek wrote:
>>> On 05/25/2015 03:13 PM, Jan Cholasta wrote:
>>>> Hi,
>>>>
>>>> Dne 25.5.2015 v 14:55 Martin Babinsky napsal(a):
>>>>> Hello all, long post ahead!
>>>>>
>>>>> I became a proud owner of https://fedorahosted.org/freeipa/ticket/4238,
>>>>> and while Martin's design page
>>>>> (http://www.freeipa.org/page/V4/User_Certificates) brings a
>>>>> comprehensive overview of what should be done, there are still some gray
>>>>> areas we should address both in the design page and the actual
>>>>> implementation.
>>>>>
>>>>> These are the things that were agreed upon in previous thread(s):
>>>>>
>>>>> 1.) If the whole user certificates are available, the should be stored
>>>>> directly in the user entry as an attribute of the following format:
>>>>>
>>>>>       "userCertificate;binary;$id",
>>>>>
>>>>> where "id" should be an unique identifier. IIRC we agreed that the
>>>>> first/last 4 bytes of cert's SHA512 hash should fill the 'id' role
>>>>> nicely. During user authentication the whole binary blob would be
>>>>> matched (pspacek pointed out that the cost of this operation is
>>>>> acceptable).
>>>>>
>>>>> 2.) In addition, or when the user certs are stored externally, we should
>>>>> store the certificate metadata in the user entry. These metadata should
>>>>> be represented by "userCertAttrs;$id;$attr" attributes, where $attr
>>>>> subtype corresponds to the type of metadata (issuer, serial no., profile
>>>>> id, certificate hash etc.). The authentication/lookup would require some
>>>>> custom matching rule to fetch the correct cert.
>>>>>
>>>>> Point 1. seems clear to me, we need to implement an index for
>>>>> userCertificate attribute in DS and modify 'user-add/mod' commands to
>>>>> allow for direct enrollment through API ("--usercertificate" option).
>>>>>
>>>>> Point 2. requires more work: we need to add a new attribute
>>>>> "userCertAttrs" to the schema and create DS index/custom matching rule
>>>>> for searching. I'm also not quite sure how to approach the task of
>>>>> getting these metadata from external storage and putting them to the
>>>>> user entry.
>>>>
>>>> Both points are obsolete. See the design page you linked for the current plan.
>>>
>>> Huh, where that came from Martin? Did you have some cached old version of the
>>> design page? I am just wondering what went wrong, as this is something I
>>> deleted from that page month ago.
>>>
>> +1 ; we will just store the certificate(s) in the userCertificate
>> attribute.
>>
>>>>
>>>>>
>>>>> These are the questions that should be addressed in a broader discussion:
>>>>>
>>>>> What is the relation to Fraser's work (cert profiles/sub-CAs)? I have
>>>>> seen that the recent iteration of Fraser's patches (0010-3 and 0011-3)
>>>>> add some ACIs and attributes/requests related to user certificates. I
>>>>> suppose that the only way the user certs are related to cert profile
>>>>> will be that there will be a profile ID stored either in cert itself, or
>>>>> as a separate userCertAttr;$id;profileId attribute in user entry.
>>>>>
>> For the avoidance of doubt, there well be no way to query which
>> profile was used to issue a certificate in the near term.  Dogtag
>> does store this information, but at the moment we are not planning
>> to use it or expose it in IPA.
>>
>>>>> What to do with user certs when the entry is deleted? Should we revoke
>>>>> them or let them expire?
>>>>
>>>> See <https://www.redhat.com/archives/freeipa-devel/2015-May/msg00198.html>.
>>>>
>>
>> There was not really any conclusion to that discussion.  I am in
>> favour of a ``{user,host,service}-{del,mod} --[no-]revoke[=$REASON]``
>> argument that says what to do when we delete a certificate, and
>> allows specifying the revocation reason.
>
> I don't think we should add such option, for the same reasons why we did not
> add the option to override the "store certificate in entry" policy in
> cert-request.
>
>>
>> I don't have a strong opinion on whether the default should be to
>> revoke or not revoke, but I do think that the default revocation
>> reason should be unspecified(0).  superseded(4) is no longer
>> appropriate.
>
> I would rather wait for Dogtag to implement the profile querying interface
> before doing anything and just not revoke certificates for now.

Well, whatever we do, it should not be a regression. So, we can change the 
global default (or make it different for upgraded/new installations as with 
some ACIs for PermissionsV2) but we should still have some possibility for a 
user to configure the behavior. FreeIPA should be still able to revoke certs 
stored in user/service/host entry during object-del/object-disable.

What should we do in this case? Option for "ipa config-*"?

Martin