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.

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


Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Reply via email to