¿Qué riesgos existirían al transmitir un PKCS12 encriptado a través de Https?

En lugar de generar un primer par de claves en su cliente (que parece descartar después de este procedimiento) y generar otro par de claves en el servidor para producir el certificado, podría:

• generar un solo par de claves en el cliente,
• convertir su clave pública en una solicitud de certificación,
• envíelo a través de HTTPS con la información de registro al servicio de su emisor,
• haga que el servicio emita el certificado y lo devuelva,
• el cliente asocia el certificado con la clave privada.

Todo esto se puede hacer directamente dentro de un navegador, por ejemplo, pero también lo pueden hacer otros clientes, como su cliente personalizado basado en SOAP. Tiene la ventaja de que la clave privada nunca abandona la parte destinada a retenerla: el cliente ni siquiera necesita confiar en que el servicio del emisor no haya guardado una copia.

Siempre que confíe en la conexión HTTPS para asegurarse de que la información de registro se envió con esta solicitud de certificación en particular, su mecanismo de verificación inicial estará bien.

EDIT:

Después de los comentarios, parece que no desea que sus claves privadas se guarden en depósito en su servidor emisor de todos modos. En este caso, no tiene sentido correr el riesgo de transmitir la clave privada. No está ganando nada generando el par de claves de certificado en el servidor; en todo caso, está aumentando el riesgo (aunque limitado por el hecho de que está transmitiendo esa clave privada a través de HTTPS de todos modos).

Cuando emite un certificado, el punto que realmente importa es el enlace entre la información del solicitante y la clave pública que terminará en el certificado, precisamente porque la parte emisora es firmar la aserción de ese enlace al formar un certificado .

De lo que realmente quiere asegurarse es que la clave pública utilizada para el certificado y la clave de registro compartida fuera de las bandas pertenezcan a la misma persona. Desde ese punto de vista, si le dan su clave pública, o si la genera y se la devuelve (con la clave privada) es lo mismo. Transmitir la clave privada de una forma u otra en este esquema es simplemente innecesario.

Todo lo que necesita hacer es obtener la clave pública de la solicitud / solicitud (en el sentido de que el usuario solicita / solicita el certificado), verifique que venga con el secreto de registro correcto y emita el certificado. Puede obtener esta clave pública de una CSR o simplemente como una clave pública simple si lo desea. (Los detalles de lo que el solicitante pudo haber puesto en el CSR son apenas relevantes, cualquier buena CA debe descartarlo y solo poner lo que ha verificado de las bandas en el certificado de todos modos).

Si el cliente ha verificado que la conexión HTTPS a su servidor está configurada correctamente: conjuntos de cifrado suficientemente sólidos, desactivando la compresión TLS , y la correcta verificación del certificado, debe tener la garantía de que la información de registro secreta y la clave pública se unieron.

Este es un método aceptado. Por ejemplo, SecureWorks emite certificados de cliente sobre SSL después de un proceso de registro. El perfil de riesgos es principalmente el siguiente:

1. Asegurar que el registro no pueda ser realizado por otra persona que no sea la parte deseada; esto es genérico con otros procesos de registro y puede ser el mayor riesgo a tratar.
2. La transferencia de la clave a través de HTTPS no es particularmente arriesgada.
3. Confiar en que el usuario maneje correctamente su clave una vez que la obtenga. No puede hacer nada al respecto, sin importar cómo obtenga la clave para ellos.
4. Asegurar la protección de las claves de cliente en su extremo. ¿Vas a depositarlas para que las personas puedan volver a descargarlas? ¿O borrarlos tan pronto como el cliente los tenga y generar uno nuevo en el futuro según sea necesario? La preferencia tradicional de "generar clave en el cliente" tiene que ver en gran medida con la desconfianza bien fundada de la capacidad de otros sistemas para olvidar las claves si alguna vez las conocían.

El procedimiento parece correcto, pero tiene que decidir un formato para el cifrado del archivo PKCS # 12 con la clave asimétrica que se generó en el paso 4. Esto no es tan fácil como parece y es mejor que se limite a un formato estándar.

En ese momento, observe que PKCS # 12 tiene una capacidad inherente para realizar el cifrado simétrico, normalmente con una "contraseña", pero la contraseña puede ser larga y aleatoria. Su procedimiento puede simplificarse si utiliza la "clave de registro" como contraseña para cifrar el archivo PKCS # 12. Esto evitaría tener que generar un par de claves en memoria en el lado del cliente.

En realidad, dado que el par de claves en memoria generado por el cliente solo se autentica en virtud de ser enviado en el túnel HTTPS junto con el código de registro, ya está asumiendo que HTTPS ofrece suficiente seguridad e impide que un atacante pueda sustituir su propio par de claves en ese punto. También puede ir al final de esa lógica y simplemente confiar en el túnel HTTPS: simplemente envíe el certificado y la clave privada tal como están. Empaquetarlos como un archivo PKCS # 12, encriptado con el código de registro (ya que se supone que ese código es suficientemente secreto), puede facilitar la integración (por ejemplo, el usuario puede obtener el PKCS # 12 como un archivo e importarlo en su sistema operativo). "manualmente").