Re: [Freeipa-devel] Dogtag lightweight sub-CAs; updated design
On Tue, Oct 07, 2014 at 09:40:12AM -0400, Simo Sorce wrote: > On Tue, 07 Oct 2014 09:29:33 -0400 > Rob Crittenden wrote: > > > Simo Sorce wrote: > > > On Tue, 07 Oct 2014 13:47:05 +0200 > > > Martin Kosek wrote: > > > > > >> On 10/07/2014 05:31 AM, Fraser Tweedale wrote: > > >>> Hi all, > > >>> > > >>> The Dogtag lightweight sub-CAs design has undergone major revision > > >>> and expansion ahead of beginning the implementation (I plan to > > >>> begin later this week). This feature will provide an API for > > >>> admins to create sub-CAs for separate security domains and > > >>> augment the existing API so that certificates requests can be > > >>> directed to a particular sub-CA. > > >>> > > >>> This feature will be used in FreeIPA for issuing user or service > > >>> certificates for particular purposes (that will be rejected when > > >>> use for other purposes). > > >>> > > >>> Please review the document and provide feedback. > > >>> > > >>> http://pki.fedoraproject.org/wiki/Lightweight_sub-CAs > > >>> > > >>> Feedback/suggestions for the REST API (that FreeIPA will use) and > > >>> ACI considerations (e.g. is it appropriate to use the existing > > >>> "agent" credential or should a separate credential or more > > >>> fine-grained ACIs be used) are particularly encouraged. > > >>> > > >>> Cheers, > > >>> > > >>> Fraser > > >> > > >> Thanks for sharing the design! Couple initial comments: > > >> > > >>> Creating sub-CAs > > >>> > > >>> Creation of sub-CAs at any time after the initial spawning of an > > >>> CA instance is a requirement. Preferably, restart would not be > > >>> needed, however, if needed, it must be able to be performed > > >>> without manual intervention. > > >> > > >> I am all for having the operation in effect without requiring > > >> restart, especially given the change is in replicated tree. What > > >> do you mean by "restart without manual operation"? That Dogtag > > >> would restart itself when it detects that subCA would be added? > > >> > > >>> Key generation and storage > > >> > > >> Are we referring to > > >> http://www.freeipa.org/page/V4/PKCS11_in_LDAP > > >> http://www.freeipa.org/page/V4/PKCS11_in_LDAP/Schema > > >> ? Contact people: Jan Cholasta, Petr Spacek > > >> > > >> > > >>> ACI considerations > > >> > > >> Agent credential is used by FreeIPA web interface, all > > >> authorization is then done on python framework level. We can add > > >> more agents and then switch the used certificate, but I wonder how > > >> to use it in authorization decisions. Apache service will need to > > >> to have access to all these agents anyway. > > > > > > We really need to move to a separate service for agent access, the > > > framework is supposed to not have any more power than the user that > > > connects to it. By giving the framework direct access to > > > credentials we fundamentally change the proposition and erode the > > > security properties of the separation. > > > > > > We have discussed before a proxy process that pass in commands as > > > they come from the framework but assumes agent identity only after > > > checking how the framework authenticated to it (via GSSAPI). > > > > > >> First we need to think how fine grained authorization we want to > > >> do. > > > > > > We need to associate a user to an agent credential via a group, so > > > that we can assign the rights via roles. > > > > > >> I think we will want to be able to for example say that user Foo > > >> can generate certificates in specified subCA. I am not sure it is > > >> a good way to go, it would also make such private key distribution > > >> on IPA replicas + renewal a challenge. > > > > > > I do not think we need to start with very fine grained permissions > > > initially. > > > > > >> Right now, we only have "Virtual Operations" concept to authorize > > >> different operations with Dogtag CA, but it does not distinguish > > >> between different CAs. We could add a new Virtual Operation for > > >> every subCA, but it looks clumsy. But the ACI-based mechanism and > > >> our permission system would still be the easiest way to go, IMHO, > > >> compared to utilizing PKI agents. > > > > > > We need to have a different agent certificate per role, and then in > > > the proxy process associate the right agent certificate based on > > > what the framework asks and internal checking that the user is > > > indeed allowed to do so. > > > > > > The framework will select the 'role' to use based on the operation > > > to be performed. > > > > I totally agree in principle but this will add significant complexity > > to replication and renewal. > > We already have this issue with DNSSEC, so I think we can solve it the > same way (storing keys in LDAP encrypted with a master key). > > > Each agent cert will need to be tracked by certmonger and renewed > > automatically. The basic framework for that is in place and IIRC > > fairly generalized so this should be relatively simple, but we've had > > a few b
Re: [Freeipa-devel] Dogtag lightweight sub-CAs; updated design
On Tue, Oct 07, 2014 at 01:47:05PM +0200, Martin Kosek wrote: > On 10/07/2014 05:31 AM, Fraser Tweedale wrote: > > Hi all, > > > > The Dogtag lightweight sub-CAs design has undergone major revision > > and expansion ahead of beginning the implementation (I plan to begin > > later this week). This feature will provide an API for admins to > > create sub-CAs for separate security domains and augment the > > existing API so that certificates requests can be directed to a > > particular sub-CA. > > > > This feature will be used in FreeIPA for issuing user or service > > certificates for particular purposes (that will be rejected when use > > for other purposes). > > > > Please review the document and provide feedback. > > > > http://pki.fedoraproject.org/wiki/Lightweight_sub-CAs > > > > Feedback/suggestions for the REST API (that FreeIPA will use) and > > ACI considerations (e.g. is it appropriate to use the existing > > "agent" credential or should a separate credential or more > > fine-grained ACIs be used) are particularly encouraged. > > > > Cheers, > > > > Fraser > > Thanks for sharing the design! Couple initial comments: > > > Creating sub-CAs > > > > Creation of sub-CAs at any time after the initial spawning of an CA instance > > is a requirement. Preferably, restart would not be needed, however, if > > needed, > > it must be able to be performed without manual intervention. > > I am all for having the operation in effect without requiring restart, > especially given the change is in replicated tree. What do you mean by > "restart > without manual operation"? That Dogtag would restart itself when it detects > that subCA would be added? > This is an artifact of earlier discussions. The requirement was that if a restart was required to complete the addition of a sub-CA, it could be triggered automatically. But I think it is now clear that it should be possible to do it without a restart. > > Key generation and storage > > Are we referring to > http://www.freeipa.org/page/V4/PKCS11_in_LDAP > http://www.freeipa.org/page/V4/PKCS11_in_LDAP/Schema > ? Contact people: Jan Cholasta, Petr Spacek > (Probably clear from the subsequent discussion, but for the sake of a direct answer...) No, not specifically referring to the above. The requirement is to generate sub-CA signing keys and propagate them to clones, securely; this is for a Dogtag CA subsystem feature, so it should be possible to do it without a KRA subsystem, SSSD, etc. > > > ACI considerations > > Agent credential is used by FreeIPA web interface, all authorization is then > done on python framework level. We can add more agents and then switch the > used > certificate, but I wonder how to use it in authorization decisions. Apache > service will need to to have access to all these agents anyway. > > First we need to think how fine grained authorization we want to do. I think > we > will want to be able to for example say that user Foo can generate > certificates > in specified subCA. I am not sure it is a good way to go, it would also make > such private key distribution on IPA replicas + renewal a challenge. > > Right now, we only have "Virtual Operations" concept to authorize different > operations with Dogtag CA, but it does not distinguish between different CAs. > We could add a new Virtual Operation for every subCA, but it looks clumsy. But > the ACI-based mechanism and our permission system would still be the easiest > way to go, IMHO, compared to utilizing PKI agents. > > Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Dogtag lightweight sub-CAs; updated design
On Tue, 07 Oct 2014 16:32:24 +0200 Petr Spacek wrote: > Naturally this forces applications to use PKCS#11 for all crypto so > the raw key never leaves HSM. Luckily DNSSEC software is built around > PKCS#11 so it was a natural choice for us. > > Personally, I would say that this is the way to go. I think this should be a goal indeed. However I'd be content if the proxy process I described would use SoftHSM to retrieve the secrets to hand them out (or proxy the calls by using them to authenticate) for now. But yes the idea is that we store them encrypted in LDAP and the only thing we do is to add ipa servers public keys to LDAP as a way to distribute access to master keys. The CA stuff is slightly different though. We really have only 2 ways here: 1. keep using certificates and build a proxy service that uses GSSAPI for authenticating received requests, then turn around and fetch a corresponding cert only the proxy has access to and reply the same command to the CA using this cert for auth. 2. Teach dogtag to use GSSAPI for authenticating these requests and then just tell it which principals (or groups of principals) are allowed to perform operations instead of using certs. Of course 2 would be much simpler. Fraser, how hard do you think it would be to add #2 ? Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Dogtag lightweight sub-CAs; updated design
On 7.10.2014 15:40, Simo Sorce wrote: On Tue, 07 Oct 2014 09:29:33 -0400 Rob Crittenden wrote: Simo Sorce wrote: On Tue, 07 Oct 2014 13:47:05 +0200 Martin Kosek wrote: On 10/07/2014 05:31 AM, Fraser Tweedale wrote: Hi all, The Dogtag lightweight sub-CAs design has undergone major revision and expansion ahead of beginning the implementation (I plan to begin later this week). This feature will provide an API for admins to create sub-CAs for separate security domains and augment the existing API so that certificates requests can be directed to a particular sub-CA. This feature will be used in FreeIPA for issuing user or service certificates for particular purposes (that will be rejected when use for other purposes). Please review the document and provide feedback. http://pki.fedoraproject.org/wiki/Lightweight_sub-CAs Feedback/suggestions for the REST API (that FreeIPA will use) and ACI considerations (e.g. is it appropriate to use the existing "agent" credential or should a separate credential or more fine-grained ACIs be used) are particularly encouraged. Cheers, Fraser Thanks for sharing the design! Couple initial comments: Creating sub-CAs Creation of sub-CAs at any time after the initial spawning of an CA instance is a requirement. Preferably, restart would not be needed, however, if needed, it must be able to be performed without manual intervention. I am all for having the operation in effect without requiring restart, especially given the change is in replicated tree. What do you mean by "restart without manual operation"? That Dogtag would restart itself when it detects that subCA would be added? Key generation and storage Are we referring to http://www.freeipa.org/page/V4/PKCS11_in_LDAP http://www.freeipa.org/page/V4/PKCS11_in_LDAP/Schema ? Contact people: Jan Cholasta, Petr Spacek ACI considerations Agent credential is used by FreeIPA web interface, all authorization is then done on python framework level. We can add more agents and then switch the used certificate, but I wonder how to use it in authorization decisions. Apache service will need to to have access to all these agents anyway. We really need to move to a separate service for agent access, the framework is supposed to not have any more power than the user that connects to it. By giving the framework direct access to credentials we fundamentally change the proposition and erode the security properties of the separation. We have discussed before a proxy process that pass in commands as they come from the framework but assumes agent identity only after checking how the framework authenticated to it (via GSSAPI). First we need to think how fine grained authorization we want to do. We need to associate a user to an agent credential via a group, so that we can assign the rights via roles. I think we will want to be able to for example say that user Foo can generate certificates in specified subCA. I am not sure it is a good way to go, it would also make such private key distribution on IPA replicas + renewal a challenge. I do not think we need to start with very fine grained permissions initially. Right now, we only have "Virtual Operations" concept to authorize different operations with Dogtag CA, but it does not distinguish between different CAs. We could add a new Virtual Operation for every subCA, but it looks clumsy. But the ACI-based mechanism and our permission system would still be the easiest way to go, IMHO, compared to utilizing PKI agents. We need to have a different agent certificate per role, and then in the proxy process associate the right agent certificate based on what the framework asks and internal checking that the user is indeed allowed to do so. The framework will select the 'role' to use based on the operation to be performed. I totally agree in principle but this will add significant complexity to replication and renewal. We already have this issue with DNSSEC, so I think we can solve it the same way (storing keys in LDAP encrypted with a master key). Maybe it is worth mentioning some implementation details from DNSSEC support: - *Every replica has own HSM* with standard PKCS#11 interface. -- By default we install SoftHSM. -- In theory it can be replaced with real HSM because the interface should be the same. This allows users to "easily" get FIPS 140 level 4 certified crypto instead of SoftHSM if they are willing to pay for it. - Every replica has own private-public key pair stored in this HSM. -- Key pair is generated inside HSM. -- Private part will never leave local HSM. -- Public part is stored in LDAP so all replicas can see it. - *All* crypto operations are done inside HSM, no keys ever leave HSM in plain text. - LDAP stores wrapped keys in this was: -- DNS zone keys are wrapped with DNS master key. -- DNS master key is wrapped with replica key. Scenario: If replica 1 wants to use "key2" stored in LDAP by replica 2: - Replica 1 downloads wrap
Re: [Freeipa-devel] Dogtag lightweight sub-CAs; updated design
On Tue, 07 Oct 2014 09:29:33 -0400 Rob Crittenden wrote: > Simo Sorce wrote: > > On Tue, 07 Oct 2014 13:47:05 +0200 > > Martin Kosek wrote: > > > >> On 10/07/2014 05:31 AM, Fraser Tweedale wrote: > >>> Hi all, > >>> > >>> The Dogtag lightweight sub-CAs design has undergone major revision > >>> and expansion ahead of beginning the implementation (I plan to > >>> begin later this week). This feature will provide an API for > >>> admins to create sub-CAs for separate security domains and > >>> augment the existing API so that certificates requests can be > >>> directed to a particular sub-CA. > >>> > >>> This feature will be used in FreeIPA for issuing user or service > >>> certificates for particular purposes (that will be rejected when > >>> use for other purposes). > >>> > >>> Please review the document and provide feedback. > >>> > >>> http://pki.fedoraproject.org/wiki/Lightweight_sub-CAs > >>> > >>> Feedback/suggestions for the REST API (that FreeIPA will use) and > >>> ACI considerations (e.g. is it appropriate to use the existing > >>> "agent" credential or should a separate credential or more > >>> fine-grained ACIs be used) are particularly encouraged. > >>> > >>> Cheers, > >>> > >>> Fraser > >> > >> Thanks for sharing the design! Couple initial comments: > >> > >>> Creating sub-CAs > >>> > >>> Creation of sub-CAs at any time after the initial spawning of an > >>> CA instance is a requirement. Preferably, restart would not be > >>> needed, however, if needed, it must be able to be performed > >>> without manual intervention. > >> > >> I am all for having the operation in effect without requiring > >> restart, especially given the change is in replicated tree. What > >> do you mean by "restart without manual operation"? That Dogtag > >> would restart itself when it detects that subCA would be added? > >> > >>> Key generation and storage > >> > >> Are we referring to > >> http://www.freeipa.org/page/V4/PKCS11_in_LDAP > >> http://www.freeipa.org/page/V4/PKCS11_in_LDAP/Schema > >> ? Contact people: Jan Cholasta, Petr Spacek > >> > >> > >>> ACI considerations > >> > >> Agent credential is used by FreeIPA web interface, all > >> authorization is then done on python framework level. We can add > >> more agents and then switch the used certificate, but I wonder how > >> to use it in authorization decisions. Apache service will need to > >> to have access to all these agents anyway. > > > > We really need to move to a separate service for agent access, the > > framework is supposed to not have any more power than the user that > > connects to it. By giving the framework direct access to > > credentials we fundamentally change the proposition and erode the > > security properties of the separation. > > > > We have discussed before a proxy process that pass in commands as > > they come from the framework but assumes agent identity only after > > checking how the framework authenticated to it (via GSSAPI). > > > >> First we need to think how fine grained authorization we want to > >> do. > > > > We need to associate a user to an agent credential via a group, so > > that we can assign the rights via roles. > > > >> I think we will want to be able to for example say that user Foo > >> can generate certificates in specified subCA. I am not sure it is > >> a good way to go, it would also make such private key distribution > >> on IPA replicas + renewal a challenge. > > > > I do not think we need to start with very fine grained permissions > > initially. > > > >> Right now, we only have "Virtual Operations" concept to authorize > >> different operations with Dogtag CA, but it does not distinguish > >> between different CAs. We could add a new Virtual Operation for > >> every subCA, but it looks clumsy. But the ACI-based mechanism and > >> our permission system would still be the easiest way to go, IMHO, > >> compared to utilizing PKI agents. > > > > We need to have a different agent certificate per role, and then in > > the proxy process associate the right agent certificate based on > > what the framework asks and internal checking that the user is > > indeed allowed to do so. > > > > The framework will select the 'role' to use based on the operation > > to be performed. > > I totally agree in principle but this will add significant complexity > to replication and renewal. We already have this issue with DNSSEC, so I think we can solve it the same way (storing keys in LDAP encrypted with a master key). > Each agent cert will need to be tracked by certmonger and renewed > automatically. The basic framework for that is in place and IIRC > fairly generalized so this should be relatively simple, but we've had > a few bumps in the road to renewal. Alternatively I think we can avoid this by having the proxy process store the certs in LDAP (encrypted with the current main agent cert) and renew them by calling out to certmonger if the certs are close to expiration. We can make it simpler than it is now
Re: [Freeipa-devel] Dogtag lightweight sub-CAs; updated design
Simo Sorce wrote: > On Tue, 07 Oct 2014 13:47:05 +0200 > Martin Kosek wrote: > >> On 10/07/2014 05:31 AM, Fraser Tweedale wrote: >>> Hi all, >>> >>> The Dogtag lightweight sub-CAs design has undergone major revision >>> and expansion ahead of beginning the implementation (I plan to begin >>> later this week). This feature will provide an API for admins to >>> create sub-CAs for separate security domains and augment the >>> existing API so that certificates requests can be directed to a >>> particular sub-CA. >>> >>> This feature will be used in FreeIPA for issuing user or service >>> certificates for particular purposes (that will be rejected when use >>> for other purposes). >>> >>> Please review the document and provide feedback. >>> >>> http://pki.fedoraproject.org/wiki/Lightweight_sub-CAs >>> >>> Feedback/suggestions for the REST API (that FreeIPA will use) and >>> ACI considerations (e.g. is it appropriate to use the existing >>> "agent" credential or should a separate credential or more >>> fine-grained ACIs be used) are particularly encouraged. >>> >>> Cheers, >>> >>> Fraser >> >> Thanks for sharing the design! Couple initial comments: >> >>> Creating sub-CAs >>> >>> Creation of sub-CAs at any time after the initial spawning of an CA >>> instance is a requirement. Preferably, restart would not be needed, >>> however, if needed, it must be able to be performed without manual >>> intervention. >> >> I am all for having the operation in effect without requiring restart, >> especially given the change is in replicated tree. What do you mean >> by "restart without manual operation"? That Dogtag would restart >> itself when it detects that subCA would be added? >> >>> Key generation and storage >> >> Are we referring to >> http://www.freeipa.org/page/V4/PKCS11_in_LDAP >> http://www.freeipa.org/page/V4/PKCS11_in_LDAP/Schema >> ? Contact people: Jan Cholasta, Petr Spacek >> >> >>> ACI considerations >> >> Agent credential is used by FreeIPA web interface, all authorization >> is then done on python framework level. We can add more agents and >> then switch the used certificate, but I wonder how to use it in >> authorization decisions. Apache service will need to to have access >> to all these agents anyway. > > We really need to move to a separate service for agent access, the > framework is supposed to not have any more power than the user that > connects to it. By giving the framework direct access to credentials we > fundamentally change the proposition and erode the security properties > of the separation. > > We have discussed before a proxy process that pass in commands as they > come from the framework but assumes agent identity only after checking > how the framework authenticated to it (via GSSAPI). > >> First we need to think how fine grained authorization we want to do. > > We need to associate a user to an agent credential via a group, so that > we can assign the rights via roles. > >> I think we will want to be able to for example say that user Foo can >> generate certificates in specified subCA. I am not sure it is a good >> way to go, it would also make such private key distribution on IPA >> replicas + renewal a challenge. > > I do not think we need to start with very fine grained permissions > initially. > >> Right now, we only have "Virtual Operations" concept to authorize >> different operations with Dogtag CA, but it does not distinguish >> between different CAs. We could add a new Virtual Operation for every >> subCA, but it looks clumsy. But the ACI-based mechanism and our >> permission system would still be the easiest way to go, IMHO, >> compared to utilizing PKI agents. > > We need to have a different agent certificate per role, and then in the > proxy process associate the right agent certificate based on what the > framework asks and internal checking that the user is indeed allowed to > do so. > > The framework will select the 'role' to use based on the operation to > be performed. I totally agree in principle but this will add significant complexity to replication and renewal. Each agent cert will need to be tracked by certmonger and renewed automatically. The basic framework for that is in place and IIRC fairly generalized so this should be relatively simple, but we've had a few bumps in the road to renewal. What I think will be more challenging is dealing with distribution of additional agent certs to other masters. We handle it now via ipa-replica-manage. Given that it is a requirement to be able to generate sub-CAs post-install there needs to be some mechanism to share this certificate amongst the other IPA masters. On the bright side Fraser has already considered some of this, at least for sub-CA key distribution, but there are no no details fleshed out yet. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Dogtag lightweight sub-CAs; updated design
On Tue, 07 Oct 2014 13:47:05 +0200 Martin Kosek wrote: > On 10/07/2014 05:31 AM, Fraser Tweedale wrote: > > Hi all, > > > > The Dogtag lightweight sub-CAs design has undergone major revision > > and expansion ahead of beginning the implementation (I plan to begin > > later this week). This feature will provide an API for admins to > > create sub-CAs for separate security domains and augment the > > existing API so that certificates requests can be directed to a > > particular sub-CA. > > > > This feature will be used in FreeIPA for issuing user or service > > certificates for particular purposes (that will be rejected when use > > for other purposes). > > > > Please review the document and provide feedback. > > > > http://pki.fedoraproject.org/wiki/Lightweight_sub-CAs > > > > Feedback/suggestions for the REST API (that FreeIPA will use) and > > ACI considerations (e.g. is it appropriate to use the existing > > "agent" credential or should a separate credential or more > > fine-grained ACIs be used) are particularly encouraged. > > > > Cheers, > > > > Fraser > > Thanks for sharing the design! Couple initial comments: > > > Creating sub-CAs > > > > Creation of sub-CAs at any time after the initial spawning of an CA > > instance is a requirement. Preferably, restart would not be needed, > > however, if needed, it must be able to be performed without manual > > intervention. > > I am all for having the operation in effect without requiring restart, > especially given the change is in replicated tree. What do you mean > by "restart without manual operation"? That Dogtag would restart > itself when it detects that subCA would be added? > > > Key generation and storage > > Are we referring to > http://www.freeipa.org/page/V4/PKCS11_in_LDAP > http://www.freeipa.org/page/V4/PKCS11_in_LDAP/Schema > ? Contact people: Jan Cholasta, Petr Spacek > > > > ACI considerations > > Agent credential is used by FreeIPA web interface, all authorization > is then done on python framework level. We can add more agents and > then switch the used certificate, but I wonder how to use it in > authorization decisions. Apache service will need to to have access > to all these agents anyway. We really need to move to a separate service for agent access, the framework is supposed to not have any more power than the user that connects to it. By giving the framework direct access to credentials we fundamentally change the proposition and erode the security properties of the separation. We have discussed before a proxy process that pass in commands as they come from the framework but assumes agent identity only after checking how the framework authenticated to it (via GSSAPI). > First we need to think how fine grained authorization we want to do. We need to associate a user to an agent credential via a group, so that we can assign the rights via roles. > I think we will want to be able to for example say that user Foo can > generate certificates in specified subCA. I am not sure it is a good > way to go, it would also make such private key distribution on IPA > replicas + renewal a challenge. I do not think we need to start with very fine grained permissions initially. > Right now, we only have "Virtual Operations" concept to authorize > different operations with Dogtag CA, but it does not distinguish > between different CAs. We could add a new Virtual Operation for every > subCA, but it looks clumsy. But the ACI-based mechanism and our > permission system would still be the easiest way to go, IMHO, > compared to utilizing PKI agents. We need to have a different agent certificate per role, and then in the proxy process associate the right agent certificate based on what the framework asks and internal checking that the user is indeed allowed to do so. The framework will select the 'role' to use based on the operation to be performed. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Dogtag lightweight sub-CAs; updated design
On 10/07/2014 05:31 AM, Fraser Tweedale wrote: > Hi all, > > The Dogtag lightweight sub-CAs design has undergone major revision > and expansion ahead of beginning the implementation (I plan to begin > later this week). This feature will provide an API for admins to > create sub-CAs for separate security domains and augment the > existing API so that certificates requests can be directed to a > particular sub-CA. > > This feature will be used in FreeIPA for issuing user or service > certificates for particular purposes (that will be rejected when use > for other purposes). > > Please review the document and provide feedback. > > http://pki.fedoraproject.org/wiki/Lightweight_sub-CAs > > Feedback/suggestions for the REST API (that FreeIPA will use) and > ACI considerations (e.g. is it appropriate to use the existing > "agent" credential or should a separate credential or more > fine-grained ACIs be used) are particularly encouraged. > > Cheers, > > Fraser Thanks for sharing the design! Couple initial comments: > Creating sub-CAs > > Creation of sub-CAs at any time after the initial spawning of an CA instance > is a requirement. Preferably, restart would not be needed, however, if needed, > it must be able to be performed without manual intervention. I am all for having the operation in effect without requiring restart, especially given the change is in replicated tree. What do you mean by "restart without manual operation"? That Dogtag would restart itself when it detects that subCA would be added? > Key generation and storage Are we referring to http://www.freeipa.org/page/V4/PKCS11_in_LDAP http://www.freeipa.org/page/V4/PKCS11_in_LDAP/Schema ? Contact people: Jan Cholasta, Petr Spacek > ACI considerations Agent credential is used by FreeIPA web interface, all authorization is then done on python framework level. We can add more agents and then switch the used certificate, but I wonder how to use it in authorization decisions. Apache service will need to to have access to all these agents anyway. First we need to think how fine grained authorization we want to do. I think we will want to be able to for example say that user Foo can generate certificates in specified subCA. I am not sure it is a good way to go, it would also make such private key distribution on IPA replicas + renewal a challenge. Right now, we only have "Virtual Operations" concept to authorize different operations with Dogtag CA, but it does not distinguish between different CAs. We could add a new Virtual Operation for every subCA, but it looks clumsy. But the ACI-based mechanism and our permission system would still be the easiest way to go, IMHO, compared to utilizing PKI agents. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
