> On 25 Feb 2017, at 21:18, Oliver Welter <[email protected]> wrote: > >> What steps can I take to limit the access of the public instance to secrets >> in this scenario? I'm thinking about ca-generated private keys in particular >> (not sure what else is there to protect). I don't know yet whether I want >> those downloadable from the public instance at all. > > I dont get this - if your users upload CSRs, you wont have user keys in the > system at all and if you generate keys on the CA, you must bring them to the > users.
Ideally, everything should come in as a CSR with private key generated somewhere else. In practice 1) People will want to generate server certificates including private keys on the CA out of convenience. It's easier to just input all DN attributes into a web form than it is to fire up openssl req... (I guess I could disallow this on the RA and force people to obey :-] ) 2) Some private keys should be escrowed, in particular Key Management keys for encryption. I don't _have_ to do that, but I should. Those old certificates and corresponding private keys should be available after generation, even if they expire in case something needs decrypting. To be honest I don't like having two certificates, one for signature and the other for encryption, but it looks like I don't have a choice if I want to use PIV smartcards (at least with macOS). In practice it works well so far in my testing, and it's best practice, so... > >> If an attacker gains complete access to the public instance, what can he do? >> Looks to me he'll be able to access all the ca-generated private keys and >> then it comes to how good password was used when creating the request. Is >> that it? >> >> I haven't fully understood what "datasafe" protects, just that it uses both >> asymmetric and symmetric key (it probably isn't easily possible to only >> encrypt on the public instance and decrypt on the internal one?) >> I don't know what leaving that on the public instance would mean. > > The datasafe token is used to encrypt data written to the "datapool" table - > its the classic "sandwich" with asymmetric encryption, we generate a > symmetric key to encrypt the payload and encrypt the key with the asymetric > token. So datapool contains raw private keys if I generate them on the CA? I found finished downloads (PKCS12 etc.) in workflow_context table (presumably encrypted with the user-supplied password and ready to download), but I wondered where the keys initially were stored. Looks like prime candidate to not have accessible on the RA. I guess this comes to policy of where/who/what should be able to do, so I'll have to think about this some more. > If you keep the datasafe key only on the CA box, you can encrypt data from RA > to CA but not decrypt it on RA. Cool! I'll play some more with it, show it to my colleagues, hope they'll like it. Thanks Jan ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ OpenXPKI-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openxpki-users
