5 ms·

There is a way to "offer" a client cert bundle to a browser, where the browser would simply ask the user whether they want to accept the personal cert into thei

There is a way to "offer" a client cert bundle to a browser, where the browser would simply ask the user whether they want to accept the personal cert into their trust store. Pretty smooth process. As for downsides, yes, no exporting: users have to go through the enrollment process with each new device.

GordonS 9y ago
> Pretty smooth process You wouldn't say that if you'd had to support our users! At least when we created the system, the method of private key generation differed from browser to browser. Then we had to sign their CSR in our offline PKI system and email them a password-protected PKCS#12 certificate bundle, and send them the password out-of-band. Finally, they had to import the bundle into their browser. It could have been simpler, but "big corporation" :(
- tialaramex 9y ago
  Either this description is wrong, or this process is crazy, or both. The whole _point_ of a CSR is that you don't need any secrets. The CSR proves that its creator has some private key in their possession and wants a certificate. You need to verify that whoever presented the CSR is really who they said they are (this is hard, hence ACME for the Web PKI, but it's out of scope for the Public Key Crypto problem) and then you issue a Certificate, which isn't secret. Emailing PKCS#12 bundles (which have a key inside them) is asking for trouble but more importantly here: if the user already has a perfectly nice key, why are you sending them a new one ?
slrz 9y ago
Why wouldn't you be able to export the key? Is this something that is "enforced" by the user interface of some browsers?
- parliament32 9y ago
  There's a flag that can be set (I don't remember if it's in the cert itself or during the import process) that makes the key un-exportable. The idea is each cert identifies a device. There's no reason to not just issue one cert per device, especially if you make the enrollment process fairly painless. If a user loses their phone, it's very nice to not have to revoke their one global cert -- just revoke the one that was used on the phone and be on your way.

GordonS 9y ago

> Pretty smooth process You wouldn't say that if you'd had to support our users! At least when we created the system, the method of private key generation differed from browser to browser. Then we had to sign their CSR in our offline PKI system and email them a password-protected PKCS#12 certificate bundle, and send them the password out-of-band. Finally, they had to import the bundle into their browser. It could have been simpler, but "big corporation" :(

tialaramex 9y ago
Either this description is wrong, or this process is crazy, or both. The whole _point_ of a CSR is that you don't need any secrets. The CSR proves that its creator has some private key in their possession and wants a certificate. You need to verify that whoever presented the CSR is really who they said they are (this is hard, hence ACME for the Web PKI, but it's out of scope for the Public Key Crypto problem) and then you issue a Certificate, which isn't secret. Emailing PKCS#12 bundles (which have a key inside them) is asking for trouble but more importantly here: if the user already has a perfectly nice key, why are you sending them a new one ?

slrz 9y ago

Why wouldn't you be able to export the key? Is this something that is "enforced" by the user interface of some browsers?

parliament32 9y ago
There's a flag that can be set (I don't remember if it's in the cert itself or during the import process) that makes the key un-exportable. The idea is each cert identifies a device. There's no reason to not just issue one cert per device, especially if you make the enrollment process fairly painless. If a user loses their phone, it's very nice to not have to revoke their one global cert -- just revoke the one that was used on the phone and be on your way.