On Tue, May 26, 2015 at 07:49:10AM +0200, Martin Kosek wrote:
> 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-*"?
>
I think a global option is sensible starting point.
We should also consider an option to use revocation reason
"certificateHold" for obj-disable and revive the certificates if the
object is re-enabled via obj-enable. (I'm not sure whether Dogtag
makes this easy but I am pretty sure it's currently possible; and
it's a bit more work for IPA to do this, of course).
I'm currently removing the revocation behaviour out of
{host,certificate}-{add,mod} as part of the multi-cert support, but
will leave the -del/-disable behaviour largely unchanged for now
(only to make these commands revoke all the certificates, not just
one certificate).
Cheers,
Fraser
> 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
