So, I'll admit, OpenPGP is not something I have much more than a superficial knowledge of. I always end up back in the docs when I have to explain something - it's just not a useful technology for most of what I do (web app development in the cloud).
Go/No-Go Decision
Mileage will vary, somewhat, depending on your key type. The CA will have a specific set of key types (encryption algorithm + key size) that it will accept. That's non-negotiable. If the OpenPGP key that you have is not of an acceptable type, then you won't get far with this procedure.
Getting the Key
Next, I would expect that you need some way to transform the OpenPGP key into a format that can be used to sign the CSR... unless it's already stored in a vialbe format.
I haven't tested it, but this looks like a reasonable procedure:
https://community.progress.com/s/article/How-to-export-a-private-OpenPGP-key-1307565960821
What I can't tell is what format this will export the key into. Ideally, it'll have a nice clear file extension (.der, .pem, .p12 or .pkcs12 are all common formats that would fit with the notes in the next section).
Making the CSR
For Open SSL CSR generation, the command is nicely discussed here:
https://stackoverflow.com/questions/9471380/create-csr-using-existing-private-key
The core of it being:
openssl req -new -key key.pem -out req.pem
"key.pem" being your pre-existing key. The PEM describes a way that a private key can be encoded. DER and PKCS12 are also common formats, and converting between formats is described here:
https://www.digicert.com/kb/ssl-support/openssl-quick-reference-guide.htm
Open SSL being what it is, I would expect you could also use any of these 3 formats directly in CSR gen, though you may have to give some argument to specify which format.
... But should you
As I was writing this, the angel on my shoulder had some things to say. It's one thing to be able to do this. It's a different question of whether you SHOULD. Private keys are the essence of security in asymmetric cryptography and handling them in a less secure way can compromise the protection.
I think this may be a case where you are better off doing this the easier way and generating a new private key for your CSR instead of trying to reuse your PGP key. I don't have all the context, so I can't say for sure. Instead, here's some things to think about:
Non-repudiation - the concern mentioned in the question about having a "truly private key" speaks to the idea that you want to have only your 1 system in control of the key. In the sketch of the procedure above - you are making a copy of the key in exporting it from PGP. You may also have a second copy in converting it's format for OpenSSL. At the very least, be sure to clean up any extraneous copies. But you'll likely end up needing 2 copies - one for the OpenPGP use and one for the purposes for which you are signing a certificate.
Limiting exposure risk - if you use the same key for two purposes and it's exposed, it compromises BOTH purposes. That doubles the risk of exposure of cryptographic content. If you had 2 keys and only 1 was exposed, the risk would be smaller. For this reason, often different key is used for different purposes.
Ease of renewal - key expires. Being able to rotate key easily (automatically!!!) minimizes the risk that you'll loose connectivity when the certificates that represent the key expire. By connecting the Open PGP and the Certificate's private key - you make your rotation process more difficult, as you have (1) generate new key, (2) re-authorized the PGP side, (3) cut a new CSR, (4) get a new certificate. That means you are almost certainly scripting something to do this, instead of telling each side to auto-renew on it's own.
I would argue that having 2 keys for these two separate mechanisms on the 1 system is not less secure. Either way, the key is sitting on your hard drive, and could even be sitting in the same key storage system/drive location and thus afforded all of the OS level, hard drive level protections available on your computer.
Reasons that you would want to keep the key the same:
- Trust distribution challenges - I have seen systems that would accept the authority of the PGP system or PKI hierarchies, and thus, your application must distribute a marker for it's key pair - and that single form of identity is how your system is authenticated. I can't really think of why you would have such a situation that requires both PGP and X509 credential creation... but never say never. If you are working in a system that imposes this restriction, then you're stuck trying to do what you're asking to do.
- Suitable key generation is deemed a serious risk and as such, is very difficult. The case that comes to mind is if you are hardware protecting your key, then getting access to the device that creates and keeps your key (not on your hard drive!) - can be difficult. Doing it twice can be twice as difficult. I've worked on a fair number of high level FIPS devices like this, and I'd still probably be inclined to make 2 different keys on that device, and use them for the 2 purposes... but mileage could definitely vary.
That's probably not a final list of either pros or cons. But I'm hoping that it gets across that 1 key for all purposes is not necessarily more secure.
