Re: [Freeipa-devel] Yet another user certificates/Smart Card thread
Fraser Tweedale wrote: On Tue, May 26, 2015 at 07:49:10AM +0200, Martin Kosek wrote: 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). It is already supported. If you revoke with a reason of 6 then you can remove the hold using the cert-remove-hold command. rob -- 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
Re: [Freeipa-devel] Yet another user certificates/Smart Card thread
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
> .
>
> >>
> >>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/obj
Re: [Freeipa-devel] Yet another user certificates/Smart Card thread
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 .
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-*"?
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
Re: [Freeipa-devel] Yet another user certificates/Smart Card thread
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 .
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=MIIDYTCCAkmgAwIBAgIJAIz9FKFUvzv0MA0GCSqGSIb3DQEBCwUAMEcxCzAJBgNVBAYTAkNaMQ0wCwYDVQQHDARCcm5vMRAwDgYDVQQKDAdSZWQgSGF0MRcwFQYDVQQDDA50ZXN0Lmhvc3QudGVzdDAeFw0xNTA1MjUxMzQwMTVaFw0xNTA2MjQxMzQwMTVaMEcxCzAJBgNVBAYTAkNaMQ0wCwYDVQQHDARCcm5vMRAwDgYDVQQKDAdSZWQgSGF0MRcwFQYDVQQDDA50ZXN0Lmhvc3QudGVzdDCCASIwDQYJKoZIhvcNAQEB
Re: [Freeipa-devel] Yet another user certificates/Smart Card thread
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 .
> >
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=MIIDYTCCAkmgAwIBAgIJAIz9FKFUvzv0MA0GCSqGSIb3DQEBCwUAMEcxCzAJBgNVBAYTAkNaMQ0wCwYDVQQHDARCcm5vMRAwDgYDVQQKDAdSZWQgSGF0MRcwFQYDVQQDDA50ZXN0Lmhvc3QudGVzdDAeFw0xNTA1MjUxMzQwMTVaFw0xNTA2MjQxMzQwMTVaMEcxCzAJBgNVBAYTAkNaMQ0wCwYDVQQHDARCcm5vMRAwDgYDVQQKDAdSZWQgSGF0MRcwFQYDVQQDDA50ZXN0Lmhvc3QudGVzdDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB
Re: [Freeipa-devel] Yet another user certificates/Smart Card thread
On 05/25/2015 04:19 PM, Martin Babinsky wrote:
> On 05/25/2015 03:56 PM, 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.
>>
> I probably got confused during re-reading threads on 'ipa-samba-team-list'.
>
> So the only thing we require (for now) is the ability to search and store full
> user certificates in the user entry? Did I get it right?
If you read freeipa-devel more closely, you would see I already sent proposal
for this feature almost a month ago :-)
http://www.redhat.com/archives/freeipa-devel/2015-May/msg1.html
HTH,
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
Re: [Freeipa-devel] Yet another user certificates/Smart Card thread
On 05/25/2015 03:56 PM, 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.
I probably got confused during re-reading threads on 'ipa-samba-team-list'.
So the only thing we require (for now) is the ability to search and
store full user certificates in the user entry? Did I get it right?
--
Martin^3 Babinsky
--
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
Re: [Freeipa-devel] Yet another user certificates/Smart Card thread
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 .
>
>>
>> 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+Csn5cIndOzHVrf!
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 subscriptio
Re: [Freeipa-devel] Yet another user certificates/Smart Card thread
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.
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 .
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.
If I forgot something or got it wrong, please correct me.
Whew, this mail got out of hand quickly. Anyway let the discussion begin!
Honza
--
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
