Re: [Freeipa-devel] User Certificates in 4.2 - design and questions

2015-05-05 Thread Fraser Tweedale
On Tue, May 05, 2015 at 08:38:28AM +0200, Martin Kosek wrote:
 On 05/04/2015 09:23 PM, Simo Sorce wrote:
  On Mon, 2015-05-04 at 16:41 +0200, Martin Kosek wrote:
  On 05/04/2015 03:01 PM, Fraser Tweedale wrote:
  On Mon, May 04, 2015 at 10:50:15AM +0200, Martin Kosek wrote:
  Hello,
 
  Please let me promote the design for one of the major FreeIPA 4.2 
  features, the
  (user) certificates and Smart Card integration:
 
  http://www.freeipa.org/page/V4/User_Certificates
 
  The design went through couple interim discussions between developers 
  outside
  of this list, so there should not be too many objections. But still, 
  please
  free to comment or improve the design yourself.
 
  For FreeIPA 4.2, I think this resolves in following, quite limited, 
  scope of work:
  * Adding eq, pres indices for userCertificate
  * Applying new policy of storing certificate in userCertificate 
  attribute,
  based on upcoming Certificate Profile feature by Fraser.
  * Making sure that multiple certificates can be added to userCertificate
  attribute manually by CLI and UI
 
  The Certificate Identity Mapping part will probably be moved to 4.3+, 
  unless
  there is extra pool of development resources.
 
  There is still something to be resolved - how should the certificates be
  revoked in object-del or object-disable actions? Currently, certificate 
  is
  always stored in userCertificate and it's serial is used for revoke 
  operation
  in Dogtag. But that will not be true in 4.2+ since some certificates 
  will not
  be stored in accounts.
 
  Do we only want to revoke those that have policy to be stored in the
  userCertificate attribute? Does not sound right to me. Or do we need a 
  Dogtag
  API that would allow us to query (or even revoke directly) all 
  certificates
  generated for a user/service/host and revoke them, regardless whether 
  they are
  stored in userCertificate attribute or not?
 
  If the DN or other searchable attributes bear a principal name,
  existing APIs should be sufficient (if a little awkward).  But
  Dogtag does not know about principals, it only knows what is on the
  cert (and a few other things, like the profile that was used).
 
  Kerberos principal SAN is added when the certificate is requested via
  Certmonger, but we do not add it when requested via cert-request command 
  (yet).
  So we cannot depend on it.
 
  Later, when we implement GSSAPI and ACL enforcement in Dogtag
  (https://fedorahosted.org/freeipa/ticket/5011) we can also store the
  principal that issued the certificate for a concrete association in
  Dogtag, which can be used to locate certificates for a principal.
 
  Right, sounds as something we should do. I commented in the ticket.
 
  Considering known use cases in which one would not want to store the
  issued cert in IPA, some of these have short lived certs so
  revocation is not an issue.  With that in mind I think it would be
  OK, for 4.2 at least, to not provide a way in IPA to revoke a cert
  that was issued via IPA but not stored; it can still be revoked
  using Dogtag directly, and we could provide pointers to Dogtag
  documentation.  The important thing is to manage the user
  expectations for 4.2.
 
  Hm, maybe - Simo, if you disagree, please shout. In this case, we would 
  need to
  make sure this side effect of the userCertificate policy is very well 
  documented.
  
  I do not disagree, in most cases when a user (or computer object) is
  deleted, there is really no need to actually revoke the cert.
  Keep in mind that revocation list growth is also a concern.
 
 Right. IIRC some of our users had problems with CRL list size also, making us
 to create ticket
 
 https://fedorahosted.org/freeipa/ticket/4048
 
  So I am fine *not* revoking certs automatically and instead documenting
  best practices for certs lifecycle management (ie deleting certs when
  not useful) and how to manually/explicitly revoke certs only when
  actually compromised (for hosts), or when needed (user leaves
  organization and may retain a copy of the private key, unlikly when the
  cert was in a Smart Card which has been returned and wiped).
 
 Well, makes sense to me. I added a section to the design:
 http://www.freeipa.org/page/V4/User_Certificates#Revocation_of_the_Certificates
 
 We just need to be cautious here because this would be a change in behavior
 compared to FreeIPA 4.1 and older. Should this be another global/per-profile
 policy setting that administrator could set up?

Since the design no longer includes storing certificate metadata
(this includes the profile used) it cannot be a per-profile setting.
It could be a global config and/or an option to cert-del.

Also, we are already changing some of the behaviour about
revocation - cert-request will no longer revoke previous
certificate(s).  If other changes are needed, now is a good time.

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] User Certificates in 4.2 - design and questions

2015-05-05 Thread Martin Kosek
On 05/04/2015 09:23 PM, Simo Sorce wrote:
 On Mon, 2015-05-04 at 16:41 +0200, Martin Kosek wrote:
 On 05/04/2015 03:01 PM, Fraser Tweedale wrote:
 On Mon, May 04, 2015 at 10:50:15AM +0200, Martin Kosek wrote:
 Hello,

 Please let me promote the design for one of the major FreeIPA 4.2 
 features, the
 (user) certificates and Smart Card integration:

 http://www.freeipa.org/page/V4/User_Certificates

 The design went through couple interim discussions between developers 
 outside
 of this list, so there should not be too many objections. But still, please
 free to comment or improve the design yourself.

 For FreeIPA 4.2, I think this resolves in following, quite limited, scope 
 of work:
 * Adding eq, pres indices for userCertificate
 * Applying new policy of storing certificate in userCertificate attribute,
 based on upcoming Certificate Profile feature by Fraser.
 * Making sure that multiple certificates can be added to userCertificate
 attribute manually by CLI and UI

 The Certificate Identity Mapping part will probably be moved to 4.3+, 
 unless
 there is extra pool of development resources.

 There is still something to be resolved - how should the certificates be
 revoked in object-del or object-disable actions? Currently, certificate is
 always stored in userCertificate and it's serial is used for revoke 
 operation
 in Dogtag. But that will not be true in 4.2+ since some certificates will 
 not
 be stored in accounts.

 Do we only want to revoke those that have policy to be stored in the
 userCertificate attribute? Does not sound right to me. Or do we need a 
 Dogtag
 API that would allow us to query (or even revoke directly) all certificates
 generated for a user/service/host and revoke them, regardless whether they 
 are
 stored in userCertificate attribute or not?

 If the DN or other searchable attributes bear a principal name,
 existing APIs should be sufficient (if a little awkward).  But
 Dogtag does not know about principals, it only knows what is on the
 cert (and a few other things, like the profile that was used).

 Kerberos principal SAN is added when the certificate is requested via
 Certmonger, but we do not add it when requested via cert-request command 
 (yet).
 So we cannot depend on it.

 Later, when we implement GSSAPI and ACL enforcement in Dogtag
 (https://fedorahosted.org/freeipa/ticket/5011) we can also store the
 principal that issued the certificate for a concrete association in
 Dogtag, which can be used to locate certificates for a principal.

 Right, sounds as something we should do. I commented in the ticket.

 Considering known use cases in which one would not want to store the
 issued cert in IPA, some of these have short lived certs so
 revocation is not an issue.  With that in mind I think it would be
 OK, for 4.2 at least, to not provide a way in IPA to revoke a cert
 that was issued via IPA but not stored; it can still be revoked
 using Dogtag directly, and we could provide pointers to Dogtag
 documentation.  The important thing is to manage the user
 expectations for 4.2.

 Hm, maybe - Simo, if you disagree, please shout. In this case, we would need 
 to
 make sure this side effect of the userCertificate policy is very well 
 documented.
 
 I do not disagree, in most cases when a user (or computer object) is
 deleted, there is really no need to actually revoke the cert.
 Keep in mind that revocation list growth is also a concern.

Right. IIRC some of our users had problems with CRL list size also, making us
to create ticket

https://fedorahosted.org/freeipa/ticket/4048

 So I am fine *not* revoking certs automatically and instead documenting
 best practices for certs lifecycle management (ie deleting certs when
 not useful) and how to manually/explicitly revoke certs only when
 actually compromised (for hosts), or when needed (user leaves
 organization and may retain a copy of the private key, unlikly when the
 cert was in a Smart Card which has been returned and wiped).

Well, makes sense to me. I added a section to the design:
http://www.freeipa.org/page/V4/User_Certificates#Revocation_of_the_Certificates

We just need to be cautious here because this would be a change in behavior
compared to FreeIPA 4.1 and older. Should this be another global/per-profile
policy setting that administrator could set up?

-- 
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] User Certificates in 4.2 - design and questions

2015-05-04 Thread Fraser Tweedale
On Mon, May 04, 2015 at 10:50:15AM +0200, Martin Kosek wrote:
 Hello,
 
 Please let me promote the design for one of the major FreeIPA 4.2 features, 
 the
 (user) certificates and Smart Card integration:
 
 http://www.freeipa.org/page/V4/User_Certificates
 
 The design went through couple interim discussions between developers outside
 of this list, so there should not be too many objections. But still, please
 free to comment or improve the design yourself.
 
 For FreeIPA 4.2, I think this resolves in following, quite limited, scope of 
 work:
 * Adding eq, pres indices for userCertificate
 * Applying new policy of storing certificate in userCertificate attribute,
 based on upcoming Certificate Profile feature by Fraser.
 * Making sure that multiple certificates can be added to userCertificate
 attribute manually by CLI and UI
 
 The Certificate Identity Mapping part will probably be moved to 4.3+, unless
 there is extra pool of development resources.
 
 There is still something to be resolved - how should the certificates be
 revoked in object-del or object-disable actions? Currently, certificate is
 always stored in userCertificate and it's serial is used for revoke operation
 in Dogtag. But that will not be true in 4.2+ since some certificates will not
 be stored in accounts.
 
 Do we only want to revoke those that have policy to be stored in the
 userCertificate attribute? Does not sound right to me. Or do we need a Dogtag
 API that would allow us to query (or even revoke directly) all certificates
 generated for a user/service/host and revoke them, regardless whether they are
 stored in userCertificate attribute or not?
 
If the DN or other searchable attributes bear a principal name,
existing APIs should be sufficient (if a little awkward).  But
Dogtag does not know about principals, it only knows what is on the
cert (and a few other things, like the profile that was used).

Later, when we implement GSSAPI and ACL enforcement in Dogtag
(https://fedorahosted.org/freeipa/ticket/5011) we can also store the
principal that issued the certificate for a concrete association in
Dogtag, which can be used to locate certificates for a principal.

Considering known use cases in which one would not want to store the
issued cert in IPA, some of these have short lived certs so
revocation is not an issue.  With that in mind I think it would be
OK, for 4.2 at least, to not provide a way in IPA to revoke a cert
that was issued via IPA but not stored; it can still be revoked
using Dogtag directly, and we could provide pointers to Dogtag
documentation.  The important thing is to manage the user
expectations for 4.2.

 Thanks.
 
 -- 
 Martin Kosek mko...@redhat.com
 Supervisor, Software Engineering - Identity Management Team
 Red Hat Inc.

-- 
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] User Certificates in 4.2 - design and questions

2015-05-04 Thread Simo Sorce
On Mon, 2015-05-04 at 16:41 +0200, Martin Kosek wrote:
 On 05/04/2015 03:01 PM, Fraser Tweedale wrote:
  On Mon, May 04, 2015 at 10:50:15AM +0200, Martin Kosek wrote:
  Hello,
 
  Please let me promote the design for one of the major FreeIPA 4.2 
  features, the
  (user) certificates and Smart Card integration:
 
  http://www.freeipa.org/page/V4/User_Certificates
 
  The design went through couple interim discussions between developers 
  outside
  of this list, so there should not be too many objections. But still, please
  free to comment or improve the design yourself.
 
  For FreeIPA 4.2, I think this resolves in following, quite limited, scope 
  of work:
  * Adding eq, pres indices for userCertificate
  * Applying new policy of storing certificate in userCertificate attribute,
  based on upcoming Certificate Profile feature by Fraser.
  * Making sure that multiple certificates can be added to userCertificate
  attribute manually by CLI and UI
 
  The Certificate Identity Mapping part will probably be moved to 4.3+, 
  unless
  there is extra pool of development resources.
 
  There is still something to be resolved - how should the certificates be
  revoked in object-del or object-disable actions? Currently, certificate is
  always stored in userCertificate and it's serial is used for revoke 
  operation
  in Dogtag. But that will not be true in 4.2+ since some certificates will 
  not
  be stored in accounts.
 
  Do we only want to revoke those that have policy to be stored in the
  userCertificate attribute? Does not sound right to me. Or do we need a 
  Dogtag
  API that would allow us to query (or even revoke directly) all certificates
  generated for a user/service/host and revoke them, regardless whether they 
  are
  stored in userCertificate attribute or not?
 
  If the DN or other searchable attributes bear a principal name,
  existing APIs should be sufficient (if a little awkward).  But
  Dogtag does not know about principals, it only knows what is on the
  cert (and a few other things, like the profile that was used).
 
 Kerberos principal SAN is added when the certificate is requested via
 Certmonger, but we do not add it when requested via cert-request command 
 (yet).
 So we cannot depend on it.
 
  Later, when we implement GSSAPI and ACL enforcement in Dogtag
  (https://fedorahosted.org/freeipa/ticket/5011) we can also store the
  principal that issued the certificate for a concrete association in
  Dogtag, which can be used to locate certificates for a principal.
 
 Right, sounds as something we should do. I commented in the ticket.
 
  Considering known use cases in which one would not want to store the
  issued cert in IPA, some of these have short lived certs so
  revocation is not an issue.  With that in mind I think it would be
  OK, for 4.2 at least, to not provide a way in IPA to revoke a cert
  that was issued via IPA but not stored; it can still be revoked
  using Dogtag directly, and we could provide pointers to Dogtag
  documentation.  The important thing is to manage the user
  expectations for 4.2.
 
 Hm, maybe - Simo, if you disagree, please shout. In this case, we would need 
 to
 make sure this side effect of the userCertificate policy is very well 
 documented.

I do not disagree, in most cases when a user (or computer object) is
deleted, there is really no need to actually revoke the cert.
Keep in mind that revocation list growth is also a concern.
So I am fine *not* revoking certs automatically and instead documenting
best practices for certs lifecycle management (ie deleting certs when
not useful) and how to manually/explicitly revoke certs only when
actually compromised (for hosts), or when needed (user leaves
organization and may retain a copy of the private key, unlikly when the
cert was in a Smart Card which has been returned and wiped).

Simo.

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