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 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. 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+Csn5cIndOzHV! rf! > 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 -- 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
