Hi all, Just landed a big update to the lightweight sub-CAs design proposal: http://pki.fedoraproject.org/wiki/Lightweight_sub-CAs. I plan to start the implementing next week. Aside from general design review, specific things I need input on are: 1) How to propagate newly-generated sub-CA private keys to clones in an automated way, and how to store them.

2) REST API; whether to have a separate resource for sub-CAs, e.g. ``/ca/ee/ca/subca1/...``, or whether to use explicit parameters to indicate a sub-CAs.

2a) Similarly, for OCSP - whether to use a single OCSP responder for all the CAs in an instance or whether to have separate responders for different [sub-]CAs. 3) The other main change in the design (I'm open to reconsidering but the more I thought about it, the more it made sense) is that there will be one CertificateAuthority object for the sub-CA (as well as the primary CA), and likewise one CertificateRepository object for each CA. The certificate repositories will be hierarchical OUs in LDAP so that it will be straightforward to search all certificates, or just those that were issued by a particular [sub-]CA. Details are in the document.

Look forward to your feedback, Fraser _______________________________________________ Pki-devel mailing list Pki-devel(a)redhat.com https://www.redhat.com/mailman/listinfo/pki-devel

On Wed, 2014-10-15 at 01:15 -0400, Ade Lee wrote: > On Fri, 2014-10-03 at 17:54 +1000, Fraser Tweedale wrote: > > Hi all, > > > > Just landed a big update to the lightweight sub-CAs design proposal: > > http://pki.fedoraproject.org/wiki/Lightweight_sub-CAs. > > > > I plan to start the implementing next week. Aside from general > > design review, specific things I need input on are: > > > > 1) > > > > How to propagate newly-generated sub-CA private keys to clones in > > an automated way, and how to store them. > > > I'll comment about that in the IPA thread. I had thought that the > keys etc. would reside in the primary CA certdb. > Actually, I'll respond here because the IPA thread has moved slightly away from this. In the IPA thread, there is discussion of storing the keys in ldap encrypted by some master key - which presumably would be stored in the certdb. Decrypting the signing key and keeping it in memory is absolutely a no-no. The CA signing key material should only be present in the HSM/softoken - and should never be exposed unencryted outside the token. All crypto operations must be done there. That most likely means storing the data in the NSS certdb.

Now, it might be possible to store the subca signing cert temporarily in ldap (encrypted by a master key) when a subca is created. If the replica detects that a new change has occurred in the DB (in the relevant ou), it reads the data and stores the subca signing key. Once all replica's have been updated, the entry is deleted. New replica's need to get a pkcs12 file from an updated master in any case. > > 2) > > > > REST API; whether to have a separate resource for sub-CAs, e.g. > > ``/ca/ee/ca/subca1/...``, or whether to use explicit parameters to > > indicate a sub-CAs. > > > Endi just added a ticket that I think is really overdue. > https://fedorahosted.org/pki/ticket/1183 > > This more closely treats the different subsystems as different webapps > within a single tomcat instance. It will make it possible to > deploy/undeploy subsystems simply by removing the context.xml file. > > Does it make sense to treat the subCA's as separate webapps, and > therefore deploy or undeploy them simply by creating or removing a > context.xml file? This would imply /ca/ee/ca/subca1/... etc. > > > 2a) > > > > Similarly, for OCSP - whether to use a single OCSP responder for all > > the CAs in an instance or whether to have separate responders for > > different [sub-]CAs. > > > > 3) > > > > The other main change in the design (I'm open to reconsidering but > > the more I thought about it, the more it made sense) is that there > > will be one CertificateAuthority object for the sub-CA (as well as > > the primary CA), and likewise one CertificateRepository object for > > each CA. The certificate repositories will be hierarchical OUs in > > LDAP so that it will be straightforward to search all certificates, > > or just those that were issued by a particular [sub-]CA. Details > > are in the document. > > > > Each CertificateAuthority object owns a number of associated objects > that are constructed when the CertificateAuthority object is constructed > - a sample of them is below. Do you plan to have a separate CS.cfg > config files? separate log files? separate serial number generators? > > protected ISubsystem mOwner = null; > protected IConfigStore mConfig = null; > protected ILogger mLogger = CMS.getLogger(); > protected Hashtable<String, ICRLIssuingPoint> mCRLIssuePoints = new Hashtable<String, ICRLIssuingPoint>(); > protected CRLIssuingPoint mMasterCRLIssuePoint = null; // the complete crl. > protected SigningUnit mSigningUnit; > protected SigningUnit mOCSPSigningUnit; > protected SigningUnit mCRLSigningUnit; > protected CertificateRepository mCertRepot = null; > protected CRLRepository mCRLRepot = null; > protected ReplicaIDRepository mReplicaRepot = null; > > protected CertificateChain mCACertChain = null; > protected CertificateChain mOCSPCertChain = null; > > protected PublisherProcessor mPublisherProcessor = null; > protected IRequestQueue mRequestQueue = null; > protected CAPolicy mPolicy = null; > protected CAService mService = null; > protected IRequestNotifier mNotify = null; > protected IRequestNotifier mPNotify = null; > > public IRequestListener mCertIssuedListener = null; > public IRequestListener mCertRevokedListener = null; > public IRequestListener mReqInQListener = null; > > protected Hashtable<String, ListenerPlugin> mListenerPlugins = null; > > Once you instantiate all of this, you start to wonder just how > "lightweight" this solution is. Yes, the separation is potentially > cleaner - but its not really any better than deploying a bunch of full > blown CA webapps within the same tomcat instance. > > I'm imagining a situation where - in openstack, different projects might > want to issue certs from their own subCA's. This is potentially a large > number of subCAs. > > Is the reason for multiple CertificateRepository directories so that you > could separate certs (and presumably requests too) into different repos? > Can/should the subCAs have different serial number generators (and > therefore most likely collisions)? > Ultimately, I think the simpler approach will be to use a single > CertificateRepository - albeit with changes to account for sub-ou's for > each subca. > > > > > > Look forward to your feedback, > > > > Fraser > > > > _______________________________________________ > > Pki-devel mailing list > > Pki-devel(a)redhat.com > > https://www.redhat.com/mailman/listinfo/pki-devel >

On Wed, 15 Oct 2014 17:48:35 +1000 Fraser Tweedale <ftweedal(a)redhat.com&gt; wrote: > On Wed, Oct 15, 2014 at 01:38:09AM -0400, Ade Lee wrote: >> On Wed, 2014-10-15 at 01:15 -0400, Ade Lee wrote: >>> On Fri, 2014-10-03 at 17:54 +1000, Fraser Tweedale wrote: >>>> Hi all, >>>> >>>> Just landed a big update to the lightweight sub-CAs design >>>> proposal: http://pki.fedoraproject.org/wiki/Lightweight_sub-CAs. >>>> >>>> I plan to start the implementing next week. Aside from general >>>> design review, specific things I need input on are: >>>> >>>> 1) >>>> >>>> How to propagate newly-generated sub-CA private keys to clones >>>> in an automated way, and how to store them. >>>> >>> I'll comment about that in the IPA thread. I had thought that the >>> keys etc. would reside in the primary CA certdb. >>> >> Actually, I'll respond here because the IPA thread has moved >> slightly away from this. In the IPA thread, there is discussion of >> storing the keys in ldap encrypted by some master key - which >> presumably would be stored in the certdb. >> >> Decrypting the signing key and keeping it in memory is absolutely a >> no-no. The CA signing key material should only be present in the >> HSM/softoken - and should never be exposed unencryted outside the >> token. All crypto operations must be done there. That most likely >> means storing the data in the NSS certdb. >> > The design of key distribution could follow the DNSSEC design; see > Petr Spacek's comments in this thread: > https://www.redhat.com/archives/freeipa-devel/2014-October/msg00080.html > Presumably this design for key distribution has received some > thorough attention. Perhaps some of the assumption for DNSSEC do > not hold for Dogtag. I have copied Petr and Simo for their input. We use a softHSM for the DNSSEC stuff (in theory can be replaced by a hw HSM too), and keys are handed within it only.

On Wed, Oct 15, 2014 at 03:58:51PM +0200, Petr Spacek wrote: > On 15.10.2014 14:48, Simo Sorce wrote: >> On Wed, 15 Oct 2014 17:48:35 +1000 >> Fraser Tweedale <ftweedal(a)redhat.com&gt; wrote: >> >>> On Wed, Oct 15, 2014 at 01:38:09AM -0400, Ade Lee wrote: >>>> On Wed, 2014-10-15 at 01:15 -0400, Ade Lee wrote: >>>>> On Fri, 2014-10-03 at 17:54 +1000, Fraser Tweedale wrote: >>>>>> Hi all, >>>>>> >>>>>> Just landed a big update to the lightweight sub-CAs design >>>>>> proposal: http://pki.fedoraproject.org/wiki/Lightweight_sub-CAs. >>>>>> >>>>>> I plan to start the implementing next week. Aside from general >>>>>> design review, specific things I need input on are: >>>>>> >>>>>> 1) >>>>>> >>>>>> How to propagate newly-generated sub-CA private keys to clones >>>>>> in an automated way, and how to store them. >>>>>> >>>>> I'll comment about that in the IPA thread. I had thought that the >>>>> keys etc. would reside in the primary CA certdb. >>>>> >>>> Actually, I'll respond here because the IPA thread has moved >>>> slightly away from this. In the IPA thread, there is discussion of >>>> storing the keys in ldap encrypted by some master key - which >>>> presumably would be stored in the certdb. >>>> >>>> Decrypting the signing key and keeping it in memory is absolutely a >>>> no-no. The CA signing key material should only be present in the >>>> HSM/softoken - and should never be exposed unencryted outside the >>>> token. All crypto operations must be done there. That most likely >>>> means storing the data in the NSS certdb. >>>> >>> The design of key distribution could follow the DNSSEC design; see >>> Petr Spacek's comments in this thread: >>> https://www.redhat.com/archives/freeipa-devel/2014-October/msg00080.html >>> Presumably this design for key distribution has received some >>> thorough attention. Perhaps some of the assumption for DNSSEC do >>> not hold for Dogtag. I have copied Petr and Simo for their input. >> We use a softHSM for the DNSSEC stuff (in theory can be replaced by a >> hw HSM too), and keys are handed within it only. > We are finishing DNSSEC right so I don't have time to study sub-CA design > right now. For this reason I'm replying only with general statements: > > - SoftHSM can be used as generic purpose token with PKCS#11 interface. > - It supports multiple "PKCS#11 slots" in single SoftHSM installation so > data can be separated as necessary: Each "slot" stores data in separate > directory (with potentially different filesystem permissions, PINs etc.) > - Upstream is responsive and accepts patches with new features (i.e. > unimplemented pieces of PKCS#11 standard) without problems. > - SoftHSM v2 code could use some cleanup but it has clear design and > structure and I don't see extensibility problems. > - Storage & crypto backends have clearly defined API so it should be > possible to implement own back-ends (LDAP & NSS, if necessary). > > Generally I don't see a reason why it couldn't not be used for as key > storage mechanism for replicas (sub-CA keys, KDC master key, etc.) or even > for clients (GNOME keyring backed with SSSD-SoftHSM tandem). > > -- > Petr^2 Spacek Thanks Simo and Petr for your input. After some more investigation it looks like all the crypto in Dogtag, including for KRA etc, is performed within the ``CryptoManager`` facility. With that in mind, I've got a more concrete implementation proposal that also uses ``CryptoManager``. If it proves insufficient I will embark on a more detailed analysis of feasibility/implications of bringing SoftHSM as a Dogtag dependency (and remain open to other key distribution ideas). One difference between the DNSSEC/SoftHSM design is that the master key has to be unwrapped each time a sub-CA key needs to be installed. This was because I couldn't see a way to store and retrieve a specific SymmetricKey in CryptoManager/CryptoToken. If there's a way to do this and I've just overlooked it, let me know. But I don't think the security of the scheme is impacted ; it just means that there's a bit of repeated work when we import sub-CA keys from the database. Direct link to key distribution implementation detail in the design proposal: http://pki.fedoraproject.org/wiki/Lightweight_sub-CAs#CryptoManager_based... Cheers, Fraser _______________________________________________ Pki-devel mailing list Pki-devel(a)redhat.com https://www.redhat.com/mailman/listinfo/pki-devel

sorry I missed a few folks in my reply ... On 10/17/2014 10:01 AM, Christina Fu wrote: > Hi Fraser, > > This response is for the "Key generation and storage" part of the > design. > > First of all, Dogtag does provide symkey retrieval via a JNI > package which provides interface to NSS called "symkey". There had > been talks of merging symkey functionalities into JSS (which is > also a JNI package that provides interface to NSS) in the future. > > In fact, for years, Dogtag has been doing what's similar to what > Petr^2 Spacek described with DNSSEC, the wrapping/unwrapping of > keys on both NSS softtoken as well as supported HSMs for > distribution without ever disclosing any private keys in memory. > This is the most basic requirement for Common Criteria for RHCS. > This is just to assure you that whatever you need, it's most likely > already there and more. > > BTW, I'm not familiar with "SoftHSM". The name itself sounds like > an oxymoron, but we don't have to get into that ;-). > > As far as HSMs go, once keys are generated, you are not going to be > able to export any private keys out of it unless they are temporary > and non-sensitive keys, which should not be the case for CA signing > keys. In practice, since HSMs are expensive, people use net HSM so > servers can share the same hardware unit as long as they are within > the same secured network, which means that you don't have to try to > distribute the certs and keys, as long as you have the right > permission/privileges and enough info to access such network shared > HSM. In cases when sharing of an HSM is not possible, HSM vendors > provide assistance to "copy" keys from one HSM to another. When > our customers run into that, we ask our customers to contact their > vendor(s). In some situations, process can be taken to generate > keys on soft token in a secure and isolated location and manually > import to individual HSMs. > What you do not want to do, is to put your CA signing keys anywhere > other than an isolated backup facility or in the token itself, no > matter how many times you wrap it. Ciphers get cracked every few > years, and when your CA private keys are compromised, the > consequences are insurmountable. > You might ask, why then KRA keeps the wrapped user private keys on > the ldap server for archival/recovery? The answer is very simple. > Those are user keys. It would be bad if they are compromised, but > not as bad or widespread. Also, those user private keys are > wrapped with individual session keys (every key is different), > unlike what DNSSEC is doing with one single "master key", if I read > it correctly (I apologize I did not have time to look into DNSSEC > at all). Anyway, Dogtag has a long history of serving facilities > that require high security, so that's why it is what it is today.

On Fri, Oct 17, 2014 at 10:04:32AM -0700, Christina Fu wrote: > sorry I missed a few folks in my reply ... > > On 10/17/2014 10:01 AM, Christina Fu wrote: >> Hi Fraser, >> >> This response is for the "Key generation and storage" part of the design. >> >> First of all, Dogtag does provide symkey retrieval via a JNI package which >> provides interface to NSS called "symkey". There had been talks of >> merging symkey functionalities into JSS (which is also a JNI package that >> provides interface to NSS) in the future. >> >> In fact, for years, Dogtag has been doing what's similar to what Petr^2 >> Spacek described with DNSSEC, the wrapping/unwrapping of keys on both NSS >> softtoken as well as supported HSMs for distribution without ever >> disclosing any private keys in memory. >> This is the most basic requirement for Common Criteria for RHCS. >> This is just to assure you that whatever you need, it's most likely >> already there and more. >> >> BTW, I'm not familiar with "SoftHSM". The name itself sounds like an >> oxymoron, but we don't have to get into that ;-). >> >> As far as HSMs go, once keys are generated, you are not going to be able >> to export any private keys out of it unless they are temporary and >> non-sensitive keys, which should not be the case for CA signing keys. >> In practice, since HSMs are expensive, people use net HSM so servers can >> share the same hardware unit as long as they are within the same secured >> network, which means that you don't have to try to distribute the certs >> and keys, as long as you have the right permission/privileges and enough >> info to access such network shared HSM. >> In cases when sharing of an HSM is not possible, HSM vendors provide >> assistance to "copy" keys from one HSM to another. When our customers run >> into that, we ask our customers to contact their vendor(s). >> In some situations, process can be taken to generate keys on soft token in >> a secure and isolated location and manually import to individual HSMs. >> What you do not want to do, is to put your CA signing keys anywhere other >> than an isolated backup facility or in the token itself, no matter how >> many times you wrap it. Ciphers get cracked every few years, and when >> your CA private keys are compromised, the consequences are insurmountable. >> You might ask, why then KRA keeps the wrapped user private keys on the >> ldap server for archival/recovery? The answer is very simple. Those are >> user keys. It would be bad if they are compromised, but not as bad or >> widespread. Also, those user private keys are wrapped with individual >> session keys (every key is different), unlike what DNSSEC is doing with >> one single "master key", if I read it correctly (I apologize I did not >> have time to look into DNSSEC at all). >> Anyway, Dogtag has a long history of serving facilities that require high >> security, so that's why it is what it is today. >> >> Hope this helps. >> Christina >> >> Christina, thanks for your detailed reply. OK, so if wrapped private keys in LDAP is unacceptable, what are the other options. I will just enumerate some ideas below; we can start discussion of these alternatives or maybe they will spark other ideas. - Push private keys directly to clones. The database contains the list of clones (cn=<host>,cn=CAList,ou=Security Domain,<basedn>) and their SecureAdminPort. Could we have an API for sending the private keys to each clone, where the keys would only be present on the wire in a secure channel, once for each clone? Drawbacks: additional logic needed to handle situations where a clone is offline at sub-CA creation time. - Pull private keys directly from generating clone to other clones. In a way, this is the dual of the previous suggestion. Clones can notice when a new sub-CA has been created in the database. The entry can contain a reference to the clone that created it, and other clones can contact that clone and request the private key over a secure channel. Drawbacks: additional logic needed to handle situations where the generating clone is offline; additional failure modes (e.g. if no clone with keys is online). - Do not automatically distribute private keys to clones. Focus effort on a good UX for administrators to distribute keys to clones. Drawbacks: seems to violate an important requirements - namely, that sub-CAs be ready to use across clones automatically (no administrator action required). I have ignored the HSM dimension above because it seems that customers using HSM are in one of two situations: 1) customer has a net-HSM used by all clones, so the key distribution problem doesn't exist, or 2) we cannot get the keys out therefore cannot distribute them. I'm not sure where pki-symkey fits into all of this. I had a quick look at the code but couldn't make much sense of it. Where should I look for examples of its intended use and capabilities, or to whom should I talk? Thanks all for your time and ongoing patience as I work out the design for this important feature.

Fraser >> On 10/16/2014 12:05 AM, Fraser Tweedale wrote: >>> On Wed, Oct 15, 2014 at 03:58:51PM +0200, Petr Spacek wrote: >>>> On 15.10.2014 14:48, Simo Sorce wrote: >>>>> On Wed, 15 Oct 2014 17:48:35 +1000 >>>>> Fraser Tweedale <ftweedal(a)redhat.com&gt; wrote: >>>>> >>>>>> On Wed, Oct 15, 2014 at 01:38:09AM -0400, Ade Lee wrote: >>>>>>> On Wed, 2014-10-15 at 01:15 -0400, Ade Lee wrote: >>>>>>>> On Fri, 2014-10-03 at 17:54 +1000, Fraser Tweedale wrote: >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> Just landed a big update to the lightweight sub-CAs design >>>>>>>>> proposal: http://pki.fedoraproject.org/wiki/Lightweight_sub-CAs. >>>>>>>>> >>>>>>>>> I plan to start the implementing next week. Aside from general >>>>>>>>> design review, specific things I need input on are: >>>>>>>>> >>>>>>>>> 1) >>>>>>>>> >>>>>>>>> How to propagate newly-generated sub-CA private keys to clones >>>>>>>>> in an automated way, and how to store them. >>>>>>>>> >>>>>>>> I'll comment about that in the IPA thread. I had thought that the >>>>>>>> keys etc. would reside in the primary CA certdb. >>>>>>>> >>>>>>> Actually, I'll respond here because the IPA thread has moved >>>>>>> slightly away from this. In the IPA thread, there is discussion of >>>>>>> storing the keys in ldap encrypted by some master key - which >>>>>>> presumably would be stored in the certdb. >>>>>>> >>>>>>> Decrypting the signing key and keeping it in memory is absolutely a >>>>>>> no-no. The CA signing key material should only be present in the >>>>>>> HSM/softoken - and should never be exposed unencryted outside the >>>>>>> token. All crypto operations must be done there. That most likely >>>>>>> means storing the data in the NSS certdb. >>>>>>> >>>>>> The design of key distribution could follow the DNSSEC design; see >>>>>> Petr Spacek's comments in this thread: >>>>>> https://www.redhat.com/archives/freeipa-devel/2014-October/msg00080.html >>>>>> >>>>>> Presumably this design for key distribution has received some >>>>>> thorough attention. Perhaps some of the assumption for DNSSEC do >>>>>> not hold for Dogtag. I have copied Petr and Simo for their input. >>>>> We use a softHSM for the DNSSEC stuff (in theory can be replaced by a >>>>> hw HSM too), and keys are handed within it only. >>>> We are finishing DNSSEC right so I don't have time to study sub-CA >>>> design >>>> right now. For this reason I'm replying only with general statements: >>>> >>>> - SoftHSM can be used as generic purpose token with PKCS#11 interface. >>>> - It supports multiple "PKCS#11 slots" in single SoftHSM installation >>>> so >>>> data can be separated as necessary: Each "slot" stores data in separate >>>> directory (with potentially different filesystem permissions, PINs >>>> etc.) >>>> - Upstream is responsive and accepts patches with new features (i.e. >>>> unimplemented pieces of PKCS#11 standard) without problems. >>>> - SoftHSM v2 code could use some cleanup but it has clear design and >>>> structure and I don't see extensibility problems. >>>> - Storage & crypto backends have clearly defined API so it should be >>>> possible to implement own back-ends (LDAP & NSS, if necessary). >>>> >>>> Generally I don't see a reason why it couldn't not be used for as key >>>> storage mechanism for replicas (sub-CA keys, KDC master key, etc.) or >>>> even >>>> for clients (GNOME keyring backed with SSSD-SoftHSM tandem). >>>> >>>> -- >>>> Petr^2 Spacek >>> Thanks Simo and Petr for your input. >>> >>> After some more investigation it looks like all the crypto in >>> Dogtag, including for KRA etc, is performed within the >>> ``CryptoManager`` facility. With that in mind, I've got a more >>> concrete implementation proposal that also uses ``CryptoManager``. >>> If it proves insufficient I will embark on a more detailed analysis >>> of feasibility/implications of bringing SoftHSM as a Dogtag >>> dependency (and remain open to other key distribution ideas). >>> >>> One difference between the DNSSEC/SoftHSM design is that the master >>> key has to be unwrapped each time a sub-CA key needs to be >>> installed. This was because I couldn't see a way to store and >>> retrieve a specific SymmetricKey in CryptoManager/CryptoToken. If >>> there's a way to do this and I've just overlooked it, let me know. >>> But I don't think the security of the scheme is impacted ; it just >>> means that there's a bit of repeated work when we import sub-CA keys >> >from the database. >>> Direct link to key distribution implementation detail in the design >>> proposal: >>> http://pki.fedoraproject.org/wiki/Lightweight_sub-CAs#CryptoManager_based... >>> >>> >>> Cheers, >>> >>> Fraser >>> >>> _______________________________________________ >>> Pki-devel mailing list >>> Pki-devel(a)redhat.com >>> https://www.redhat.com/mailman/listinfo/pki-devel >> _______________________________________________ >> Pki-devel mailing list >> Pki-devel(a)redhat.com >> https://www.redhat.com/mailman/listinfo/pki-devel > _______________________________________________ > Pki-devel mailing list > Pki-devel(a)redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel _______________________________________________ Pki-devel mailing list Pki-devel(a)redhat.com https://www.redhat.com/mailman/listinfo/pki-devel

On Mon, 2014-10-20 at 08:01 -0400, Dmitri Pal wrote: > On 10/20/2014 12:18 AM, Fraser Tweedale wrote: >> On Fri, Oct 17, 2014 at 10:04:32AM -0700, Christina Fu wrote: >>> sorry I missed a few folks in my reply ... >>> >>> On 10/17/2014 10:01 AM, Christina Fu wrote: >>>> Hi Fraser, >>>> >>>> This response is for the "Key generation and storage" part of the design. >>>> >>>> First of all, Dogtag does provide symkey retrieval via a JNI package which >>>> provides interface to NSS called "symkey". There had been talks of >>>> merging symkey functionalities into JSS (which is also a JNI package that >>>> provides interface to NSS) in the future. >>>> >>>> In fact, for years, Dogtag has been doing what's similar to what Petr^2 >>>> Spacek described with DNSSEC, the wrapping/unwrapping of keys on both NSS >>>> softtoken as well as supported HSMs for distribution without ever >>>> disclosing any private keys in memory. >>>> This is the most basic requirement for Common Criteria for RHCS. >>>> This is just to assure you that whatever you need, it's most likely >>>> already there and more. >>>> >>>> BTW, I'm not familiar with "SoftHSM". The name itself sounds like an >>>> oxymoron, but we don't have to get into that ;-). >>>> >>>> As far as HSMs go, once keys are generated, you are not going to be able >>>> to export any private keys out of it unless they are temporary and >>>> non-sensitive keys, which should not be the case for CA signing keys. >>>> In practice, since HSMs are expensive, people use net HSM so servers can >>>> share the same hardware unit as long as they are within the same secured >>>> network, which means that you don't have to try to distribute the certs >>>> and keys, as long as you have the right permission/privileges and enough >>>> info to access such network shared HSM. >>>> In cases when sharing of an HSM is not possible, HSM vendors provide >>>> assistance to "copy" keys from one HSM to another. When our customers run >>>> into that, we ask our customers to contact their vendor(s). >>>> In some situations, process can be taken to generate keys on soft token in >>>> a secure and isolated location and manually import to individual HSMs. >>>> What you do not want to do, is to put your CA signing keys anywhere other >>>> than an isolated backup facility or in the token itself, no matter how >>>> many times you wrap it. Ciphers get cracked every few years, and when >>>> your CA private keys are compromised, the consequences are insurmountable. >>>> You might ask, why then KRA keeps the wrapped user private keys on the >>>> ldap server for archival/recovery? The answer is very simple. Those are >>>> user keys. It would be bad if they are compromised, but not as bad or >>>> widespread. Also, those user private keys are wrapped with individual >>>> session keys (every key is different), unlike what DNSSEC is doing with >>>> one single "master key", if I read it correctly (I apologize I did not >>>> have time to look into DNSSEC at all). >>>> Anyway, Dogtag has a long history of serving facilities that require high >>>> security, so that's why it is what it is today. >>>> >>>> Hope this helps. >>>> Christina >>>> >>>> >> Christina, thanks for your detailed reply. OK, so if wrapped >> private keys in LDAP is unacceptable, what are the other options. I >> will just enumerate some ideas below; we can start discussion of >> these alternatives or maybe they will spark other ideas. >> >> - Push private keys directly to clones. The database contains the >> list of clones (cn=<host>,cn=CAList,ou=Security Domain,<basedn>) >> and their SecureAdminPort. Could we have an API for sending the >> private keys to each clone, where the keys would only be present >> on the wire in a secure channel, once for each clone? >> >> Drawbacks: additional logic needed to handle situations where a >> clone is offline at sub-CA creation time. >> >> - Pull private keys directly from generating clone to other clones. >> In a way, this is the dual of the previous suggestion. Clones can >> notice when a new sub-CA has been created in the database. The >> entry can contain a reference to the clone that created it, and >> other clones can contact that clone and request the private key >> over a secure channel. >> >> Drawbacks: additional logic needed to handle situations where the >> generating clone is offline; additional failure modes (e.g. if no >> clone with keys is online). >> >> - Do not automatically distribute private keys to clones. Focus >> effort on a good UX for administrators to distribute keys to >> clones. >> >> Drawbacks: seems to violate an important requirements - namely, >> that sub-CAs be ready to use across clones automatically (no >> administrator action required). >> >> >> I have ignored the HSM dimension above because it seems that >> customers using HSM are in one of two situations: 1) customer has a >> net-HSM used by all clones, so the key distribution problem doesn't >> exist, or 2) we cannot get the keys out therefore cannot distribute >> them. >> >> I'm not sure where pki-symkey fits into all of this. I had a quick >> look at the code but couldn't make much sense of it. Where should I >> look for examples of its intended use and capabilities, or to whom >> should I talk? >> >> Thanks all for your time and ongoing patience as I work out the >> design for this important feature. The feature that Christina is probably referring to was a mechanism I put in place a little while back to distribute a shared symmetric key from the TKS to the TPS during installation. I am also wary about storing wrapped CA signing keys in LDAP. These aren't just the keys for a user, but rather CA signing keys -- literally the keys to the kingdom (or at least little fiefdom). Now, I still think though that it is possible to possible to transport the subCA keys between clones safely. Here is one suggestion: 1. We create a new service on the CA for the distribution of subCA signing keys. This service may be disabled by a configuration setting on the CA. Whether it should be disabled by default is open to debate. 2. SubCA detects (through ldap) that a subCA has been added. It sends a request for the CA signing key, including the identifier for the subCA and half of a session key (wrapped with the subsystem public key). Recall that the subsystem key is shared between clones and is the key used to inter-communicate between dogtag subsystems. 3. The service on the master CA generates the other half of a session key and wraps that with the subsystem public key. It also sends back the subCA signing key wrapped with the complete session key. There are lots of variations of the above, but they all rely on the fact that the master and clones share the same subsystem cert - which was originally transported to the clone manually via p12 file. The subsystem certificate is stored in the same cert DB as the signing cert, so if it is compromised, most likely the CA signing cert is compromised too. > I think the best would be to have manual distribution of the keys > assumed by default but have a way for admin to specify that he is OK > with replicating keys via LDAP in a wrapped blob. > Not all environments are the same. In many cases wrapped keys in LDAP > would be good enough but in some they would not so to fail safe the > manual option should be default. > Given that these are CA signing keys - even if the subdomain is smaller - I'd rather err on the side of caution and use a mechanism similar to the above. > 2c. > >> Fraser >> >> >>>> On 10/16/2014 12:05 AM, Fraser Tweedale wrote: >>>>> On Wed, Oct 15, 2014 at 03:58:51PM +0200, Petr Spacek wrote: >>>>>> On 15.10.2014 14:48, Simo Sorce wrote: >>>>>>> On Wed, 15 Oct 2014 17:48:35 +1000 >>>>>>> Fraser Tweedale&lt;ftweedal(a)redhat.com&gt; wrote: >>>>>>> >>>>>>>> On Wed, Oct 15, 2014 at 01:38:09AM -0400, Ade Lee wrote: >>>>>>>>> On Wed, 2014-10-15 at 01:15 -0400, Ade Lee wrote: >>>>>>>>>> On Fri, 2014-10-03 at 17:54 +1000, Fraser Tweedale wrote: >>>>>>>>>>> Hi all, >>>>>>>>>>> >>>>>>>>>>> Just landed a big update to the lightweight sub-CAs design >>>>>>>>>>> proposal:http://pki.fedoraproject.org/wiki/Lightweight_sub-CAs. >>>>>>>>>>> >>>>>>>>>>> I plan to start the implementing next week. Aside from general >>>>>>>>>>> design review, specific things I need input on are: >>>>>>>>>>> >>>>>>>>>>> 1) >>>>>>>>>>> >>>>>>>>>>> How to propagate newly-generated sub-CA private keys to clones >>>>>>>>>>> in an automated way, and how to store them. >>>>>>>>>>> >>>>>>>>>> I'll comment about that in the IPA thread. I had thought that the >>>>>>>>>> keys etc. would reside in the primary CA certdb. >>>>>>>>>> >>>>>>>>> Actually, I'll respond here because the IPA thread has moved >>>>>>>>> slightly away from this. In the IPA thread, there is discussion of >>>>>>>>> storing the keys in ldap encrypted by some master key - which >>>>>>>>> presumably would be stored in the certdb. >>>>>>>>> >>>>>>>>> Decrypting the signing key and keeping it in memory is absolutely a >>>>>>>>> no-no. The CA signing key material should only be present in the >>>>>>>>> HSM/softoken - and should never be exposed unencryted outside the >>>>>>>>> token. All crypto operations must be done there. That most likely >>>>>>>>> means storing the data in the NSS certdb. >>>>>>>>> >>>>>>>> The design of key distribution could follow the DNSSEC design; see >>>>>>>> Petr Spacek's comments in this thread: >>>>>>>> https://www.redhat.com/archives/freeipa-devel/2014-October/msg00080.html >>>>>>>> >>>>>>>> Presumably this design for key distribution has received some >>>>>>>> thorough attention. Perhaps some of the assumption for DNSSEC do >>>>>>>> not hold for Dogtag. I have copied Petr and Simo for their input. >>>>>>> We use a softHSM for the DNSSEC stuff (in theory can be replaced by a >>>>>>> hw HSM too), and keys are handed within it only. >>>>>> We are finishing DNSSEC right so I don't have time to study sub-CA >>>>>> design >>>>>> right now. For this reason I'm replying only with general statements: >>>>>> >>>>>> - SoftHSM can be used as generic purpose token with PKCS#11 interface. >>>>>> - It supports multiple "PKCS#11 slots" in single SoftHSM installation >>>>>> so >>>>>> data can be separated as necessary: Each "slot" stores data in separate >>>>>> directory (with potentially different filesystem permissions, PINs >>>>>> etc.) >>>>>> - Upstream is responsive and accepts patches with new features (i.e. >>>>>> unimplemented pieces of PKCS#11 standard) without problems. >>>>>> - SoftHSM v2 code could use some cleanup but it has clear design and >>>>>> structure and I don't see extensibility problems. >>>>>> - Storage & crypto backends have clearly defined API so it should be >>>>>> possible to implement own back-ends (LDAP & NSS, if necessary). >>>>>> >>>>>> Generally I don't see a reason why it couldn't not be used for as key >>>>>> storage mechanism for replicas (sub-CA keys, KDC master key, etc.) or >>>>>> even >>>>>> for clients (GNOME keyring backed with SSSD-SoftHSM tandem). >>>>>> >>>>>> -- >>>>>> Petr^2 Spacek >>>>> Thanks Simo and Petr for your input. >>>>> >>>>> After some more investigation it looks like all the crypto in >>>>> Dogtag, including for KRA etc, is performed within the >>>>> ``CryptoManager`` facility. With that in mind, I've got a more >>>>> concrete implementation proposal that also uses ``CryptoManager``. >>>>> If it proves insufficient I will embark on a more detailed analysis >>>>> of feasibility/implications of bringing SoftHSM as a Dogtag >>>>> dependency (and remain open to other key distribution ideas). >>>>> >>>>> One difference between the DNSSEC/SoftHSM design is that the master >>>>> key has to be unwrapped each time a sub-CA key needs to be >>>>> installed. This was because I couldn't see a way to store and >>>>> retrieve a specific SymmetricKey in CryptoManager/CryptoToken. If >>>>> there's a way to do this and I've just overlooked it, let me know. >>>>> But I don't think the security of the scheme is impacted ; it just >>>>> means that there's a bit of repeated work when we import sub-CA keys >>>> >from the database. >>>>> Direct link to key distribution implementation detail in the design >>>>> proposal: >>>>> http://pki.fedoraproject.org/wiki/Lightweight_sub-CAs#CryptoManager_based... >>>>> >>>>> >>>>> Cheers, >>>>> >>>>> Fraser >>>>> >>>>> _______________________________________________ >>>>> Pki-devel mailing list >>>>> Pki-devel(a)redhat.com >>>>> https://www.redhat.com/mailman/listinfo/pki-devel >>>> _______________________________________________ >>>> Pki-devel mailing list >>>> Pki-devel(a)redhat.com >>>> https://www.redhat.com/mailman/listinfo/pki-devel >>> _______________________________________________ >>> Pki-devel mailing list >>> Pki-devel(a)redhat.com >>> https://www.redhat.com/mailman/listinfo/pki-devel >> _______________________________________________ >> Pki-devel mailing list >> Pki-devel(a)redhat.com >> https://www.redhat.com/mailman/listinfo/pki-devel _______________________________________________ Pki-devel mailing list Pki-devel(a)redhat.com https://www.redhat.com/mailman/listinfo/pki-devel

On Tue, 2014-10-21 at 16:49 -0700, Christina Fu wrote: > The following response is only for soft tokens for obvious reasons I > stated earlier. > > First of all, it is okay to make exceptions for the duration of > installation. This is to give people a choice of doing things in > secured/isolated environment for installation purpose. So, yes, it is > much better than having a design where sensitive data is placed and kept > on ldap in normal operation. > > Here I'm just throwing out some questions/ideas for you to think about. > > About transmission of keys. A couple questions for Ade's design in the > email thread: > a. If you split the key (or generate 1/2 a key separately...same thing) > and use the exact same key to wrap the shares then I am not sure I see > the benefit (apology if I am not reading it right... I'm spread very > thin at this point). I will talk about key splitting in the later part > of this email... > b. I might have missed something, but if you take the effort to manually > transport the p12 of subsystem keys/certs, why not do the CA as well? What you are missing, Christina, is that this operation can be done during normal operation. The feature that is being developed here is a lightweight subCA. This is a subCA that exists in the same webapp as a "primary" CA, and that will be subordinate to it. It will share config files, profiles, logs, audit signing, server and subsystem certs and certdb. It will have different signing and ocsp signing certs - which will be stored in the certdb. It will also share the same DB instance, although likely under some different DNs.

The subCA will probably be created through a REST API call, likely invoked through the pki CLI tool (as an enterprise admin). There may be many subCAs, but they will all be created after the primary CA is operational. I could imagine the following flow: 1. Admin installs primary CA (CA0) 2. Admin uses CLI to install subCA1 in CA0. 3. Admin clones CA0 to CA1. Any system certs in the certdb are transported using the p12 mechanism - including the subsystem cert and the signing certs for CA0 and subCA1. The result is a clone that contains a clone of CA0 and subCA1. 4. Admin uses CLI to install subCA2 on CA0. 5. At this point, the clone CA1 detects that a new subCA has been created (through watching LDAP modifications) and needs to automatically make any required configuration changes and get the new signing keys for subCA2. The key point is that operation (5) needs to be done automatically with no operator intervention. That means that there are no credentials to get an installation token from the security domain.

But because we are in a working clone, we already have the credentials we need. Both clones already have the same subsystem cert/keys - and this should be true only for clones. We can therefore use the subsystem cert to both authenticate and wrap the subCA2 signing private key for transport. Now, as I recall, you can't wrap an asymmetric key (the signing private key) with another asymmetric key (the subsystem public key) directly, so you need to do it using a symmetric key. The mechanism I proposed is very similar to the mechanism used to set up SSL, and the splitting of transport key is crucial to prevent forgery. Let me propose a similar but slightly more complicated mechanism using passphrases. This mechanism is probably more similar to SSL setup, and is more secure because parts of the transport key are not sent over. 1. clone generates half of a passphrase and wraps that with the subsystem public key. 2. master generates the other half of the passphrase, combines the two and derives a symmetric key. The master sends back a) the other half of the passphrase wrapped with the subsystem public key b) the subCA signing private key wrapped with the symmetric key. 3. clone decrypts the other half of the passphrase, combines its half with the master half and derives the same symmetric key. Then uses the symmetric key to unwrap the subCA signing private key.

> Also, why do you need to manually transport the p12 of the subsystem > keys/certs? Each clone could very well get a different "transport" cert > (maybe double as ssl client cert -- what we call the subsystem cert) > from the orig CA to kickstart. They can just generate CSR locally, send > request, and get issuance, and then publish their public key then they > can start wrapping and transmitting secrets with each other, isn't it? > To save time, I'm leaving out details such as initial authentication > (the current token/session key mechanism should do) in the discussion. > Also, these transport certs need to belong to a special "agent" group or > some privileged group on the CA to be allowed to get wrapped keys,etc. > So, potentially it can go like (I'm only roughly laying this out...you > need to fill in the detail for design): > 1. a clone is created, talks to orig CA to get started (session key, etc). > 2. clone generates csr for transport certs. sends csr to orig CA to approve > 3. orig CA authenticated the above request, and issues the cert, sends > the cert back to clone; meanwhile, orig CA keeps record of these > transport certs for later look up (maybe using session keys as look up > keys). > 4. clone sends orig CA request to retrieve CA signing key > 5. orig CA looks up and finds the clone's transport cert, generates a > cryptographically equal or better strength'd session (sym) key to wrap > it's own priv key, wrap the sym key with the transport public key (and > maybe a few other things), then sends them back to the requesting clone. > (that means the transport certs need to be of same or higher strength) > 6. clone unwraps the session (sym) key, unwraps the Ca priv key and > injects into its own soft token. > I wrote all of the above and then reread this -- and I really like this mechanism. This will allow us to avoid the whole p12 creation and transport business altogether.

What you described here will work for setting up the clone initially. In that case, the authentication will be via login to a security domain and obtaining an installation token. We need to decide however, whether the installation token is sufficient protection for this operation. We will need another type of authentication for a subCA being created post-install ie. scenario (5) I mentioned above. This could be the subsystem cert which would need to point to a user on the master CA - that would be set up when the clone is initially set up.

> Also, remind me again, why do all subsystem certs of the clones have to > be the same? Its the way things are implemented now. We manually copy over all pk12 certs (except the ssl server cert). Remember also that the subsystem cert is issued by the security domain CA. > About key splitting. The benefit of splitting a key includes > 1. takes more effort to crack > 2. no single entity (e.g. person) can have access to the whole private > key (this is very important to prevent forgery) > > If key splitting is desired (note: I am not saying I encourage this, as > in most cases, this might be a bit much. I am just throwing out info), > you might want to consider looking into the following. In fact, RHCS > code might still have the Bloom/Shamir m of n secret-sharing code from > the older implementation of KRA lying around (not sure if still in > current Dogtag source). > Of course I'm not sure how much of these is automatable. > Also I'm sure the crypto used in the old code could use some update > (code is at least 17 years old)... but the logic is there. > Oh, and there was also a RecoverPinKey tool that can be converted to use > on the clone side to do reconstruction. > > Finally, one word of caution, please make sure the wrapping key is at > least as strong cryptographically as the CA private key. > > hope I wasn't verging on rambling... > Christina > > On 10/20/2014 06:28 AM, Ade Lee wrote: >> On Mon, 2014-10-20 at 08:01 -0400, Dmitri Pal wrote: >>> On 10/20/2014 12:18 AM, Fraser Tweedale wrote: >>>> On Fri, Oct 17, 2014 at 10:04:32AM -0700, Christina Fu wrote: >>>>> sorry I missed a few folks in my reply ... >>>>> >>>>> On 10/17/2014 10:01 AM, Christina Fu wrote: >>>>>> Hi Fraser, >>>>>> >>>>>> This response is for the "Key generation and storage" part of the design. >>>>>> >>>>>> First of all, Dogtag does provide symkey retrieval via a JNI package which >>>>>> provides interface to NSS called "symkey". There had been talks of >>>>>> merging symkey functionalities into JSS (which is also a JNI package that >>>>>> provides interface to NSS) in the future. >>>>>> >>>>>> In fact, for years, Dogtag has been doing what's similar to what Petr^2 >>>>>> Spacek described with DNSSEC, the wrapping/unwrapping of keys on both NSS >>>>>> softtoken as well as supported HSMs for distribution without ever >>>>>> disclosing any private keys in memory. >>>>>> This is the most basic requirement for Common Criteria for RHCS. >>>>>> This is just to assure you that whatever you need, it's most likely >>>>>> already there and more. >>>>>> >>>>>> BTW, I'm not familiar with "SoftHSM". The name itself sounds like an >>>>>> oxymoron, but we don't have to get into that ;-). >>>>>> >>>>>> As far as HSMs go, once keys are generated, you are not going to be able >>>>>> to export any private keys out of it unless they are temporary and >>>>>> non-sensitive keys, which should not be the case for CA signing keys. >>>>>> In practice, since HSMs are expensive, people use net HSM so servers can >>>>>> share the same hardware unit as long as they are within the same secured >>>>>> network, which means that you don't have to try to distribute the certs >>>>>> and keys, as long as you have the right permission/privileges and enough >>>>>> info to access such network shared HSM. >>>>>> In cases when sharing of an HSM is not possible, HSM vendors provide >>>>>> assistance to "copy" keys from one HSM to another. When our customers run >>>>>> into that, we ask our customers to contact their vendor(s). >>>>>> In some situations, process can be taken to generate keys on soft token in >>>>>> a secure and isolated location and manually import to individual HSMs. >>>>>> What you do not want to do, is to put your CA signing keys anywhere other >>>>>> than an isolated backup facility or in the token itself, no matter how >>>>>> many times you wrap it. Ciphers get cracked every few years, and when >>>>>> your CA private keys are compromised, the consequences are insurmountable. >>>>>> You might ask, why then KRA keeps the wrapped user private keys on the >>>>>> ldap server for archival/recovery? The answer is very simple. Those are >>>>>> user keys. It would be bad if they are compromised, but not as bad or >>>>>> widespread. Also, those user private keys are wrapped with individual >>>>>> session keys (every key is different), unlike what DNSSEC is doing with >>>>>> one single "master key", if I read it correctly (I apologize I did not >>>>>> have time to look into DNSSEC at all). >>>>>> Anyway, Dogtag has a long history of serving facilities that require high >>>>>> security, so that's why it is what it is today. >>>>>> >>>>>> Hope this helps. >>>>>> Christina >>>>>> >>>>>> >>>> Christina, thanks for your detailed reply. OK, so if wrapped >>>> private keys in LDAP is unacceptable, what are the other options. I >>>> will just enumerate some ideas below; we can start discussion of >>>> these alternatives or maybe they will spark other ideas. >>>> >>>> - Push private keys directly to clones. The database contains the >>>> list of clones (cn=<host>,cn=CAList,ou=Security Domain,<basedn>) >>>> and their SecureAdminPort. Could we have an API for sending the >>>> private keys to each clone, where the keys would only be present >>>> on the wire in a secure channel, once for each clone? >>>> >>>> Drawbacks: additional logic needed to handle situations where a >>>> clone is offline at sub-CA creation time. >>>> >>>> - Pull private keys directly from generating clone to other clones. >>>> In a way, this is the dual of the previous suggestion. Clones can >>>> notice when a new sub-CA has been created in the database. The >>>> entry can contain a reference to the clone that created it, and >>>> other clones can contact that clone and request the private key >>>> over a secure channel. >>>> >>>> Drawbacks: additional logic needed to handle situations where the >>>> generating clone is offline; additional failure modes (e.g. if no >>>> clone with keys is online). >>>> >>>> - Do not automatically distribute private keys to clones. Focus >>>> effort on a good UX for administrators to distribute keys to >>>> clones. >>>> >>>> Drawbacks: seems to violate an important requirements - namely, >>>> that sub-CAs be ready to use across clones automatically (no >>>> administrator action required). >>>> >>>> >>>> I have ignored the HSM dimension above because it seems that >>>> customers using HSM are in one of two situations: 1) customer has a >>>> net-HSM used by all clones, so the key distribution problem doesn't >>>> exist, or 2) we cannot get the keys out therefore cannot distribute >>>> them. >>>> >>>> I'm not sure where pki-symkey fits into all of this. I had a quick >>>> look at the code but couldn't make much sense of it. Where should I >>>> look for examples of its intended use and capabilities, or to whom >>>> should I talk? >>>> >>>> Thanks all for your time and ongoing patience as I work out the >>>> design for this important feature. >> The feature that Christina is probably referring to was a mechanism I >> put in place a little while back to distribute a shared symmetric key >> from the TKS to the TPS during installation. >> >> I am also wary about storing wrapped CA signing keys in LDAP. These >> aren't just the keys for a user, but rather CA signing keys -- literally >> the keys to the kingdom (or at least little fiefdom). >> >> Now, I still think though that it is possible to possible to transport >> the subCA keys between clones safely. Here is one suggestion: >> >> 1. We create a new service on the CA for the distribution of subCA >> signing keys. This service may be disabled by a configuration setting >> on the CA. Whether it should be disabled by default is open to debate. >> >> 2. SubCA detects (through ldap) that a subCA has been added. It sends a >> request for the CA signing key, including the identifier for the subCA >> and half of a session key (wrapped with the subsystem public key). >> Recall that the subsystem key is shared between clones and is the key >> used to inter-communicate between dogtag subsystems. >> >> 3. The service on the master CA generates the other half of a session >> key and wraps that with the subsystem public key. It also sends back >> the subCA signing key wrapped with the complete session key. >> >> There are lots of variations of the above, but they all rely on the fact >> that the master and clones share the same subsystem cert - which was >> originally transported to the clone manually via p12 file. >> >> The subsystem certificate is stored in the same cert DB as the signing >> cert, so if it is compromised, most likely the CA signing cert is >> compromised too. >> >>> I think the best would be to have manual distribution of the keys >>> assumed by default but have a way for admin to specify that he is OK >>> with replicating keys via LDAP in a wrapped blob. >>> Not all environments are the same. In many cases wrapped keys in LDAP >>> would be good enough but in some they would not so to fail safe the >>> manual option should be default. >>> >> Given that these are CA signing keys - even if the subdomain is smaller >> - I'd rather err on the side of caution and use a mechanism similar to >> the above. >> >>> 2c. >>> >>>> Fraser >>>> >>>> >>>>>> On 10/16/2014 12:05 AM, Fraser Tweedale wrote: >>>>>>> On Wed, Oct 15, 2014 at 03:58:51PM +0200, Petr Spacek wrote: >>>>>>>> On 15.10.2014 14:48, Simo Sorce wrote: >>>>>>>>> On Wed, 15 Oct 2014 17:48:35 +1000 >>>>>>>>> Fraser Tweedale&lt;ftweedal(a)redhat.com&gt; wrote: >>>>>>>>> >>>>>>>>>> On Wed, Oct 15, 2014 at 01:38:09AM -0400, Ade Lee wrote: >>>>>>>>>>> On Wed, 2014-10-15 at 01:15 -0400, Ade Lee wrote: >>>>>>>>>>>> On Fri, 2014-10-03 at 17:54 +1000, Fraser Tweedale wrote: >>>>>>>>>>>>> Hi all, >>>>>>>>>>>>> >>>>>>>>>>>>> Just landed a big update to the lightweight sub-CAs design >>>>>>>>>>>>> proposal:http://pki.fedoraproject.org/wiki/Lightweight_sub-CAs. >>>>>>>>>>>>> >>>>>>>>>>>>> I plan to start the implementing next week. Aside from general >>>>>>>>>>>>> design review, specific things I need input on are: >>>>>>>>>>>>> >>>>>>>>>>>>> 1) >>>>>>>>>>>>> >>>>>>>>>>>>> How to propagate newly-generated sub-CA private keys to clones >>>>>>>>>>>>> in an automated way, and how to store them. >>>>>>>>>>>>> >>>>>>>>>>>> I'll comment about that in the IPA thread. I had thought that the >>>>>>>>>>>> keys etc. would reside in the primary CA certdb. >>>>>>>>>>>> >>>>>>>>>>> Actually, I'll respond here because the IPA thread has moved >>>>>>>>>>> slightly away from this. In the IPA thread, there is discussion of >>>>>>>>>>> storing the keys in ldap encrypted by some master key - which >>>>>>>>>>> presumably would be stored in the certdb. >>>>>>>>>>> >>>>>>>>>>> Decrypting the signing key and keeping it in memory is absolutely a >>>>>>>>>>> no-no. The CA signing key material should only be present in the >>>>>>>>>>> HSM/softoken - and should never be exposed unencryted outside the >>>>>>>>>>> token. All crypto operations must be done there. That most likely >>>>>>>>>>> means storing the data in the NSS certdb. >>>>>>>>>>> >>>>>>>>>> The design of key distribution could follow the DNSSEC design; see >>>>>>>>>> Petr Spacek's comments in this thread: >>>>>>>>>> https://www.redhat.com/archives/freeipa-devel/2014-October/msg00080.html >>>>>>>>>> >>>>>>>>>> Presumably this design for key distribution has received some >>>>>>>>>> thorough attention. Perhaps some of the assumption for DNSSEC do >>>>>>>>>> not hold for Dogtag. I have copied Petr and Simo for their input. >>>>>>>>> We use a softHSM for the DNSSEC stuff (in theory can be replaced by a >>>>>>>>> hw HSM too), and keys are handed within it only. >>>>>>>> We are finishing DNSSEC right so I don't have time to study sub-CA >>>>>>>> design >>>>>>>> right now. For this reason I'm replying only with general statements: >>>>>>>> >>>>>>>> - SoftHSM can be used as generic purpose token with PKCS#11 interface. >>>>>>>> - It supports multiple "PKCS#11 slots" in single SoftHSM installation >>>>>>>> so >>>>>>>> data can be separated as necessary: Each "slot" stores data in separate >>>>>>>> directory (with potentially different filesystem permissions, PINs >>>>>>>> etc.) >>>>>>>> - Upstream is responsive and accepts patches with new features (i.e. >>>>>>>> unimplemented pieces of PKCS#11 standard) without problems. >>>>>>>> - SoftHSM v2 code could use some cleanup but it has clear design and >>>>>>>> structure and I don't see extensibility problems. >>>>>>>> - Storage & crypto backends have clearly defined API so it should be >>>>>>>> possible to implement own back-ends (LDAP & NSS, if necessary). >>>>>>>> >>>>>>>> Generally I don't see a reason why it couldn't not be used for as key >>>>>>>> storage mechanism for replicas (sub-CA keys, KDC master key, etc.) or >>>>>>>> even >>>>>>>> for clients (GNOME keyring backed with SSSD-SoftHSM tandem). >>>>>>>> >>>>>>>> -- >>>>>>>> Petr^2 Spacek >>>>>>> Thanks Simo and Petr for your input. >>>>>>> >>>>>>> After some more investigation it looks like all the crypto in >>>>>>> Dogtag, including for KRA etc, is performed within the >>>>>>> ``CryptoManager`` facility. With that in mind, I've got a more >>>>>>> concrete implementation proposal that also uses ``CryptoManager``. >>>>>>> If it proves insufficient I will embark on a more detailed analysis >>>>>>> of feasibility/implications of bringing SoftHSM as a Dogtag >>>>>>> dependency (and remain open to other key distribution ideas). >>>>>>> >>>>>>> One difference between the DNSSEC/SoftHSM design is that the master >>>>>>> key has to be unwrapped each time a sub-CA key needs to be >>>>>>> installed. This was because I couldn't see a way to store and >>>>>>> retrieve a specific SymmetricKey in CryptoManager/CryptoToken. If >>>>>>> there's a way to do this and I've just overlooked it, let me know. >>>>>>> But I don't think the security of the scheme is impacted ; it just >>>>>>> means that there's a bit of repeated work when we import sub-CA keys >>>>>> >from the database. >>>>>>> Direct link to key distribution implementation detail in the design >>>>>>> proposal: >>>>>>> http://pki.fedoraproject.org/wiki/Lightweight_sub-CAs#CryptoManager_based... >>>>>>> >>>>>>> >>>>>>> Cheers, >>>>>>> >>>>>>> Fraser >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Pki-devel mailing list >>>>>>> Pki-devel(a)redhat.com >>>>>>> https://www.redhat.com/mailman/listinfo/pki-devel >>>>>> _______________________________________________ >>>>>> Pki-devel mailing list >>>>>> Pki-devel(a)redhat.com >>>>>> https://www.redhat.com/mailman/listinfo/pki-devel >>>>> _______________________________________________ >>>>> Pki-devel mailing list >>>>> Pki-devel(a)redhat.com >>>>> https://www.redhat.com/mailman/listinfo/pki-devel >>>> _______________________________________________ >>>> Pki-devel mailing list >>>> Pki-devel(a)redhat.com >>>> https://www.redhat.com/mailman/listinfo/pki-devel >> _______________________________________________ >> Pki-devel mailing list >> Pki-devel(a)redhat.com >> https://www.redhat.com/mailman/listinfo/pki-devel

On Fri, 2014-10-03 at 17:54 +1000, Fraser Tweedale wrote: > Hi all, > > Just landed a big update to the lightweight sub-CAs design proposal: > http://pki.fedoraproject.org/wiki/Lightweight_sub-CAs. > > I plan to start the implementing next week. Aside from general > design review, specific things I need input on are: > > 1) > > How to propagate newly-generated sub-CA private keys to clones in > an automated way, and how to store them. > I'll comment about that in the IPA thread. I had thought that the keys etc. would reside in the primary CA certdb. > 2) > > REST API; whether to have a separate resource for sub-CAs, e.g. > ``/ca/ee/ca/subca1/...``, or whether to use explicit parameters to > indicate a sub-CAs. > Endi just added a ticket that I think is really overdue. https://fedorahosted.org/pki/ticket/1183 This more closely treats the different subsystems as different webapps within a single tomcat instance. It will make it possible to deploy/undeploy subsystems simply by removing the context.xml file. Does it make sense to treat the subCA's as separate webapps, and therefore deploy or undeploy them simply by creating or removing a context.xml file? This would imply /ca/ee/ca/subca1/... etc.

> 2a) > > Similarly, for OCSP - whether to use a single OCSP responder for all > the CAs in an instance or whether to have separate responders for > different [sub-]CAs. > > 3) > > The other main change in the design (I'm open to reconsidering but > the more I thought about it, the more it made sense) is that there > will be one CertificateAuthority object for the sub-CA (as well as > the primary CA), and likewise one CertificateRepository object for > each CA. The certificate repositories will be hierarchical OUs in > LDAP so that it will be straightforward to search all certificates, > or just those that were issued by a particular [sub-]CA. Details > are in the document. > Each CertificateAuthority object owns a number of associated objects that are constructed when the CertificateAuthority object is constructed - a sample of them is below. Do you plan to have a separate CS.cfg config files? separate log files? separate serial number generators? protected ISubsystem mOwner = null; protected IConfigStore mConfig = null; protected ILogger mLogger = CMS.getLogger(); protected Hashtable<String, ICRLIssuingPoint> mCRLIssuePoints = new Hashtable<String, ICRLIssuingPoint>(); protected CRLIssuingPoint mMasterCRLIssuePoint = null; // the complete crl. protected SigningUnit mSigningUnit; protected SigningUnit mOCSPSigningUnit; protected SigningUnit mCRLSigningUnit; protected CertificateRepository mCertRepot = null; protected CRLRepository mCRLRepot = null; protected ReplicaIDRepository mReplicaRepot = null; protected CertificateChain mCACertChain = null; protected CertificateChain mOCSPCertChain = null; protected PublisherProcessor mPublisherProcessor = null; protected IRequestQueue mRequestQueue = null; protected CAPolicy mPolicy = null; protected CAService mService = null; protected IRequestNotifier mNotify = null; protected IRequestNotifier mPNotify = null; public IRequestListener mCertIssuedListener = null; public IRequestListener mCertRevokedListener = null; public IRequestListener mReqInQListener = null; protected Hashtable<String, ListenerPlugin> mListenerPlugins = null; Once you instantiate all of this, you start to wonder just how "lightweight" this solution is. Yes, the separation is potentially cleaner - but its not really any better than deploying a bunch of full blown CA webapps within the same tomcat instance. I'm imagining a situation where - in openstack, different projects might want to issue certs from their own subCA's. This is potentially a large number of subCAs.

Is the reason for multiple CertificateRepository directories so that you could separate certs (and presumably requests too) into different repos? Can/should the subCAs have different serial number generators (and therefore most likely collisions)? Ultimately, I think the simpler approach will be to use a single CertificateRepository - albeit with changes to account for sub-ou's for each subca.

> > Look forward to your feedback, > > Fraser > > _______________________________________________ > Pki-devel mailing list > Pki-devel(a)redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel

On Wed, 2014-10-15 at 17:36 +1000, Fraser Tweedale wrote: > On Wed, Oct 15, 2014 at 01:15:28AM -0400, Ade Lee wrote: >> On Fri, 2014-10-03 at 17:54 +1000, Fraser Tweedale wrote: >>> Hi all, >>> >>> Just landed a big update to the lightweight sub-CAs design proposal: >>> http://pki.fedoraproject.org/wiki/Lightweight_sub-CAs. >>> >>> I plan to start the implementing next week. Aside from general >>> design review, specific things I need input on are: >>> >>> 1) >>> >>> How to propagate newly-generated sub-CA private keys to clones in >>> an automated way, and how to store them. >>> >> I'll comment about that in the IPA thread. I had thought that the >> keys etc. would reside in the primary CA certdb. >> >>> 2) >>> >>> REST API; whether to have a separate resource for sub-CAs, e.g. >>> ``/ca/ee/ca/subca1/...``, or whether to use explicit parameters to >>> indicate a sub-CAs. >>> >> Endi just added a ticket that I think is really overdue. >> https://fedorahosted.org/pki/ticket/1183 >> >> This more closely treats the different subsystems as different webapps >> within a single tomcat instance. It will make it possible to >> deploy/undeploy subsystems simply by removing the context.xml file. >> >> Does it make sense to treat the subCA's as separate webapps, and >> therefore deploy or undeploy them simply by creating or removing a >> context.xml file? This would imply /ca/ee/ca/subca1/... etc. >> > The current design has them as part of the same web app, with > path or query parameters to distinguish between CAs. > > To my intuition, this should be a simpler and - with the current > deployment situation - less disruptive option than separate webapps. > A downside to this approach is somewhat more complicated routing, > more parameters to process and mechanism needed to select the > correct SigningUnit. There may be critical downsides that were > overlooked - let me know. OK - lets go with that approach for now and see where we end up. >>> 2a) >>> >>> Similarly, for OCSP - whether to use a single OCSP responder for all >>> the CAs in an instance or whether to have separate responders for >>> different [sub-]CAs.

>>> 3) >>> >>> The other main change in the design (I'm open to reconsidering but >>> the more I thought about it, the more it made sense) is that there >>> will be one CertificateAuthority object for the sub-CA (as well as >>> the primary CA), and likewise one CertificateRepository object for >>> each CA. The certificate repositories will be hierarchical OUs in >>> LDAP so that it will be straightforward to search all certificates, >>> or just those that were issued by a particular [sub-]CA. Details >>> are in the document. >>> >> Each CertificateAuthority object owns a number of associated objects >> that are constructed when the CertificateAuthority object is constructed >> - a sample of them is below. Do you plan to have a separate CS.cfg >> config files? separate log files? separate serial number generators? >> >> protected ISubsystem mOwner = null; >> protected IConfigStore mConfig = null; >> protected ILogger mLogger = CMS.getLogger(); >> protected Hashtable<String, ICRLIssuingPoint> mCRLIssuePoints = new Hashtable<String, ICRLIssuingPoint>(); >> protected CRLIssuingPoint mMasterCRLIssuePoint = null; // the complete crl. >> protected SigningUnit mSigningUnit; >> protected SigningUnit mOCSPSigningUnit; >> protected SigningUnit mCRLSigningUnit; >> protected CertificateRepository mCertRepot = null; >> protected CRLRepository mCRLRepot = null; >> protected ReplicaIDRepository mReplicaRepot = null; >> >> protected CertificateChain mCACertChain = null; >> protected CertificateChain mOCSPCertChain = null; >> >> protected PublisherProcessor mPublisherProcessor = null; >> protected IRequestQueue mRequestQueue = null; >> protected CAPolicy mPolicy = null; >> protected CAService mService = null; >> protected IRequestNotifier mNotify = null; >> protected IRequestNotifier mPNotify = null; >> >> public IRequestListener mCertIssuedListener = null; >> public IRequestListener mCertRevokedListener = null; >> public IRequestListener mReqInQListener = null; >> >> protected Hashtable<String, ListenerPlugin> mListenerPlugins = null; >> >> Once you instantiate all of this, you start to wonder just how >> "lightweight" this solution is. Yes, the separation is potentially >> cleaner - but its not really any better than deploying a bunch of full >> blown CA webapps within the same tomcat instance. >> >> I'm imagining a situation where - in openstack, different projects might >> want to issue certs from their own subCA's. This is potentially a large >> number of subCAs. >> > Indeed. I think should be able to share request queues and > listeners easily enough. The CA SigningUnit will probably need to > be separate for each subCA. Shared-vs-independent CRL and OCSP > SigningUnits need more investigation.

> > CertificateChain objects will probably be different for each sub-CAs > despite sub-CAs obviously sharing most of the chain with siblings. > Too bad they didn't use a plain old cons list :) > > Voicing of concerns about lightweight sub-CAs not being so > lightweight are appreciated. Are there any specific concers about > performance, or just general wariness? > I have a general wariness about sharing resources like listeners, publishers etc. between multiple CA objects when they were probably not designed to be used in that manner. That could lead to hard to diagnose synchronization issues. If we plan to share almost all the resources - including config files, log files, most system certs -- and treat the subcas as part of the primary CA webapp, then the subCA's really are a different animal than the primary CA - and should be represented accordingly. It may make sense to create a CA instance as : CA { Shared_Stuff HashTable (Non_Shared_Stuff for subCA's) NonSharedObject getNonSharedObject(sub_ca_id) { if (sub_ca_id == Null) return NonSharedObject(default) else return NonSharedObject(sub_ca_id) } } I think it makes sense to identify the things that need to be different for subCA's and focus on making sure the correct objects are loaded there. Separating into completely separate CA instances might ultimately be cleaner, but it wouldn't be my first cut. > The use case is really API-driven sub-CA creation (and use) in an > existing instance, so maybe the feature needs a re-brand? > "Low-overhead sub-CAs" or "Shared-instance sub-CAs" or something? > The name is fine, as most resources are shared. Its the synchronization of objects that worries me. >> Is the reason for multiple CertificateRepository directories so that you >> could separate certs (and presumably requests too) into different repos? >> Can/should the subCAs have different serial number generators (and >> therefore most likely collisions)? >> Ultimately, I think the simpler approach will be to use a single >> CertificateRepository - albeit with changes to account for sub-ou's for >> each subca. >> > Ok, so we agree on hierarchical OUs for the cert repo schema. I > will examine the needed changes to CertificateRepository to support > this, and we can compare. It might just be some new optional > parameters for specifying a subCA. > > (The reason for multiple CertificateRepository objects was that it > would mean few changes - just instantiate for each OU. So, not an > important reason.) > > Cheers, > > Fraser > >>> Look forward to your feedback, >>> >>> Fraser >>> >>> _______________________________________________ >>> Pki-devel mailing list >>> Pki-devel(a)redhat.com >>> https://www.redhat.com/mailman/listinfo/pki-devel >> _______________________________________________ Pki-devel mailing list Pki-devel(a)redhat.com https://www.redhat.com/mailman/listinfo/pki-devel

On Wed, Oct 15, 2014 at 05:37:17PM -0700, Christina Fu wrote: > First, I have a question regarding the design History for "rejected design: > sub-CA subsystem (Solution) 1". > I'm not sure I understand the stated disadvantage regarding having to keep > separate admin certs and need to find out which cert to authenticate. Isn't > that the same thing with the other co-existing subsystems such as KRA as > well? How is the sub-CA making it any more different? maybe I missed > something, but I actually am not convinced that this is enough reason to > make drastic changes in the code that could weaken the stability of the > product. > You are right - on it's own, it is not enough reason. But the main reason for rejection (I will update the earlier list to include it) is stated in the ``Reasons for rejection'' section: The challenge of spawning sub-CA subsystems on multiple clones is likely to introduce a lot of complexity and may be brittle. The alternative solution of storing sub-CA configuration in the database, thus allowing easy replication, was preferred. > Now for the design... > please see my comments in-line below. > > Christina > > On 10/15/2014 07:37 AM, Ade Lee wrote: > >On Wed, 2014-10-15 at 17:36 +1000, Fraser Tweedale wrote: > >>On Wed, Oct 15, 2014 at 01:15:28AM -0400, Ade Lee wrote: > >>>On Fri, 2014-10-03 at 17:54 +1000, Fraser Tweedale wrote: > >>>>Hi all, > >>>> > >>>>Just landed a big update to the lightweight sub-CAs design proposal: > >>>>http://pki.fedoraproject.org/wiki/Lightweight_sub-CAs. > >>>> > >>>>I plan to start the implementing next week. Aside from general > >>>>design review, specific things I need input on are: > >>>> > >>>>1) > >>>> > >>>>How to propagate newly-generated sub-CA private keys to clones in > >>>>an automated way, and how to store them. > >>>> > >>>I'll comment about that in the IPA thread. I had thought that the > >>>keys etc. would reside in the primary CA certdb. > >>> > >>>>2) > >>>> > >>>>REST API; whether to have a separate resource for sub-CAs, e.g. > >>>>``/ca/ee/ca/subca1/...``, or whether to use explicit parameters to > >>>>indicate a sub-CAs. > >>>> > >>>Endi just added a ticket that I think is really overdue. > >>>https://fedorahosted.org/pki/ticket/1183 > >>> > >>>This more closely treats the different subsystems as different webapps > >>>within a single tomcat instance. It will make it possible to > >>>deploy/undeploy subsystems simply by removing the context.xml file. > >>> > >>>Does it make sense to treat the subCA's as separate webapps, and > >>>therefore deploy or undeploy them simply by creating or removing a > >>>context.xml file? This would imply /ca/ee/ca/subca1/... etc. > >>> > >>The current design has them as part of the same web app, with > >>path or query parameters to distinguish between CAs. > >> > >>To my intuition, this should be a simpler and - with the current > >>deployment situation - less disruptive option than separate webapps. > >>A downside to this approach is somewhat more complicated routing, > >>more parameters to process and mechanism needed to select the > >>correct SigningUnit. There may be critical downsides that were > >>overlooked - let me know. > >OK - lets go with that approach for now and see where we end up. > >>>>2a) > >>>> > >>>>Similarly, for OCSP - whether to use a single OCSP responder for all > >>>>the CAs in an instance or whether to have separate responders for > >>>>different [sub-]CAs. > > For CRL's, Each CA needs to sign its own CRL or delegate to its CRL issuer. > a CRL issuer is a cert that contains the crlSign key extension which is > signed by the CA itself, the same CA that issues the certs. > The OCSP responses have to be signed by the the OCSP signer that has the > ocspSigning extended key usage extension which is signed by the CA itself, > the same CA that issues the certs asking for validation. > when handling multiple crls from different ca's, iff you have one single > ocsp instance, each time a request comes in, you will need to make sure you > sign the responses with the right corresponding ocsp signing cert or the > validation will fail. > > I filed a ticket recently: https://fedorahosted.org/pki/ticket/1179 > I'll be happy if you take care of that while you are at it ;-). > I need to understand OCSP properly, but according to your preceding comments it does seem that each sub-CAs will have a corresponding OCSP signing cert. So the ticket certainly appears to be in scope for this feature.

> >>>>3) > >>>> > >>>>The other main change in the design (I'm open to reconsidering but > >>>>the more I thought about it, the more it made sense) is that there > >>>>will be one CertificateAuthority object for the sub-CA (as well as > >>>>the primary CA), and likewise one CertificateRepository object for > >>>>each CA. The certificate repositories will be hierarchical OUs in > >>>>LDAP so that it will be straightforward to search all certificates, > >>>>or just those that were issued by a particular [sub-]CA. Details > >>>>are in the document. > >>>> > >>>Each CertificateAuthority object owns a number of associated objects > >>>that are constructed when the CertificateAuthority object is constructed > >>>- a sample of them is below. Do you plan to have a separate CS.cfg > >>>config files? separate log files? separate serial number generators? > >>> > >>> protected ISubsystem mOwner = null; > >>> protected IConfigStore mConfig = null; > >>> protected ILogger mLogger = CMS.getLogger(); > >>> protected Hashtable<String, ICRLIssuingPoint> mCRLIssuePoints = new Hashtable<String, ICRLIssuingPoint>(); > >>> protected CRLIssuingPoint mMasterCRLIssuePoint = null; // the complete crl. > >>> protected SigningUnit mSigningUnit; > >>> protected SigningUnit mOCSPSigningUnit; > >>> protected SigningUnit mCRLSigningUnit; > >>> protected CertificateRepository mCertRepot = null; > >>> protected CRLRepository mCRLRepot = null; > >>> protected ReplicaIDRepository mReplicaRepot = null; > >>> > >>> protected CertificateChain mCACertChain = null; > >>> protected CertificateChain mOCSPCertChain = null; > >>> protected PublisherProcessor mPublisherProcessor = null; > >>> protected IRequestQueue mRequestQueue = null; > >>> protected CAPolicy mPolicy = null; > >>> protected CAService mService = null; > >>> protected IRequestNotifier mNotify = null; > >>> protected IRequestNotifier mPNotify = null; > >>> > >>> public IRequestListener mCertIssuedListener = null; > >>> public IRequestListener mCertRevokedListener = null; > >>> public IRequestListener mReqInQListener = null; > >>> > >>> protected Hashtable<String, ListenerPlugin> mListenerPlugins = null; > >>> > >>>Once you instantiate all of this, you start to wonder just how > >>>"lightweight" this solution is. Yes, the separation is potentially > >>>cleaner - but its not really any better than deploying a bunch of full > >>>blown CA webapps within the same tomcat instance. > >>> > >>>I'm imagining a situation where - in openstack, different projects might > >>>want to issue certs from their own subCA's. This is potentially a large > >>>number of subCAs. > >>> > >>Indeed. I think should be able to share request queues and > >>listeners easily enough. The CA SigningUnit will probably need to > >>be separate for each subCA. Shared-vs-independent CRL and OCSP > >>SigningUnits need more investigation. > > Yes that was my thought as well.. having separate SigningUnit's. > I'm not sure you want separate CA's to share the same config and profiles as > that seems to defeat the purpose of calling it out as a separate CA. > yes, I just saw Ade's suggestion about defining shared and non-shared. I > agree that you should think it through. > I disagree that it defeats the purpose - the driving use case is easily created (at any time) security subdomains within a Dogtag instance. I think we will always want sub-CAs to support multiple profiles (even though this may be a limited number). This means that there must be a way to specify a profile. So my thoughts are to support all profiles for now, at least for the first cut of this feature. The changes to restrict which profiles a sub-CA can use can come later as the use cases are clarified. I will add a section to the design proposal for exploring issues related to profiles. Fraser > > >> > >>CertificateChain objects will probably be different for each sub-CAs > >>despite sub-CAs obviously sharing most of the chain with siblings. > >>Too bad they didn't use a plain old cons list :) > >> > >>Voicing of concerns about lightweight sub-CAs not being so > >>lightweight are appreciated. Are there any specific concers about > >>performance, or just general wariness? > >> > >I have a general wariness about sharing resources like listeners, > >publishers etc. between multiple CA objects when they were probably not > >designed to be used in that manner. That could lead to hard to diagnose > >synchronization issues. > > > >If we plan to share almost all the resources - including config files, > >log files, most system certs -- and treat the subcas as part of the > >primary CA webapp, then the subCA's really are a different animal than > >the primary CA - and should be represented accordingly. > > > >It may make sense to create a CA instance as : > > > >CA { > > Shared_Stuff > > HashTable (Non_Shared_Stuff for subCA's) > > > > NonSharedObject getNonSharedObject(sub_ca_id) { > > if (sub_ca_id == Null) > > return NonSharedObject(default) > > else > > return NonSharedObject(sub_ca_id) > > } > >} > > > >I think it makes sense to identify the things that need to be different > >for subCA's and focus on making sure the correct objects are loaded > >there. > > > >Separating into completely separate CA instances might ultimately be > >cleaner, but it wouldn't be my first cut. > > > >>The use case is really API-driven sub-CA creation (and use) in an > >>existing instance, so maybe the feature needs a re-brand? > >>"Low-overhead sub-CAs" or "Shared-instance sub-CAs" or something? > >> > >The name is fine, as most resources are shared. Its the synchronization > >of objects that worries me. > > > >>>Is the reason for multiple CertificateRepository directories so that you > >>>could separate certs (and presumably requests too) into different repos? > >>>Can/should the subCAs have different serial number generators (and > >>>therefore most likely collisions)? > >>>Ultimately, I think the simpler approach will be to use a single > >>>CertificateRepository - albeit with changes to account for sub-ou's for > >>>each subca. > >>> > >>Ok, so we agree on hierarchical OUs for the cert repo schema. I > >>will examine the needed changes to CertificateRepository to support > >>this, and we can compare. It might just be some new optional > >>parameters for specifying a subCA. > >> > >>(The reason for multiple CertificateRepository objects was that it > >>would mean few changes - just instantiate for each OU. So, not an > >>important reason.) > >> > >>Cheers, > >> > >>Fraser > >> > >>>>Look forward to your feedback, > >>>> > >>>>Fraser > >>>> > >>>>_______________________________________________ > >>>>Pki-devel mailing list > &gt;&gt;&gt;&gt;Pki-devel(a)redhat.com > >>>>https://www.redhat.com/mailman/listinfo/pki-devel > >>> > > > >_______________________________________________ > >Pki-devel mailing list > &gt;Pki-devel(a)redhat.com > >https://www.redhat.com/mailman/listinfo/pki-devel > > _______________________________________________ > Pki-devel mailing list > Pki-devel(a)redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel _______________________________________________ Pki-devel mailing list Pki-devel(a)redhat.com https://www.redhat.com/mailman/listinfo/pki-devel