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

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

Reply via email to