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

Mon May 25 14:40:06 UTC 2015

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.

>
> Cheers,
> Fraser
>
>>>>
>>>> In the case that the user cert is stored in a separate location and not
>>>> available to FreeIPA, how will we get the required attributes (see point
>>>> 2) to the user entry in LDAP tree?
>>>>
>>>> How much of this work should actually be done in 4.2 timeframe? I guess
>>>> all work related to point 1 will be done, but what about other features?
>>>
>>> We need an API to modify the userCertificate attribute of users/hosts/services.
>>> Should be easy to do.
>>
>> What API would you propose? Just using the current "--certificate" option we
>> have for hosts/services, but extending it so that it can also store other,
>> non-IPA certificates?
>>
>> Right now, I can do only this:
>>
>> # ipa host-mod test.host.test
>> --certificate=MIIDYTCCAkmgAwIBAgIJAIz9FKFUvzv0MA0GCSqGSIb3DQEBCwUAMEcxCzAJBgNVBAYTAkNaMQ0wCwYDVQQHDARCcm5vMRAwDgYDVQQKDAdSZWQgSGF0MRcwFQYDVQQDDA50ZXN0Lmhvc3QudGVzdDAeFw0xNTA1MjUxMzQwMTVaFw0xNTA2MjQxMzQwMTVaMEcxCzAJBgNVBAYTAkNaMQ0wCwYDVQQHDARCcm5vMRAwDgYDVQQKDAdSZWQgSGF0MRcwFQYDVQQDDA50ZXN0Lmhvc3QudGVzdDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOi4goei6KU8dU2VVqzu9OA+6RJEAdpawp3KvCbTnGPJJx7SzgguDPj5L3+tx9kjyYKD1L7eAWZHv6QSNuCe4kixIg/iamyY8OOt7wkGHzSzDGm4gVheD6OCuQ2OmwcDebysfINUugQIvUCgxAxRV6fZhQzvtMnao4N+sclrnfi+Njz1Otf0/UqVG0Le0tHSTFRA7A8ECOCMpY7TLSr8VViRp0A2pX/dr3tgvQO+EsZUwKVKSQcBGJQ3MW/Cn9NPLj03zESG8305Q6YLpQVyFHTCJJi/ZLEJjiK8emmq+6K4X7/5x6zlmJZ5llY3x3b0cJ44u5sXqUqvuhHDMbyxiKMCAwEAAaNQME4wHQYDVR0OBBYEFE+42oRjb/cmPRAU+tejUwkvzIubMB8GA1UdIwQYMBaAFE+42oRjb/cmPRAU+tejUwkvzIubMAwGA1UdEwQFMAMBAf8wDQYJKoZIhvcNAQELBQADggEBAHqUTsVcr9h9/rjPTLQ2GWMmYjAKR0SpN+EnXT4cMLTyF8ZmN6ZlrNnUJXC4uqhTTwribxkNfp2sTABa9i3CrsWNGKM2RZj5Fz2H03p+ZMFm0JpDjpu1sKQ064pvliHaiA/w2ejDH9kgNMU6+Csn5cIndOzH!
 Vrf!
>>   2NtMgTishM
>> IkUKGJGhPV4lL+WKjkFVKlhKNAYcmsELkIJqISL/W6TEzPOxFSSrGi4QNP4ekaL+hhAACBP+ecRYel7kRcBPddwvtzOt+MusHPEeHdZpmyubs0UXI2OGcDT21SC4ydjOADnv/gTxdZFarJKWAQlyTEj9X1EzBrv6uQuprwGQjpOE2w=
>> ipa: ERROR: Certificate operation cannot be completed: Issuer
>> "CN=test.host.test,O=Red Hat,L=Brno,C=CZ" does not match the expected issuer
>>
>> Martin

-- 
Jan Cholasta