busca la clave pública de una CA

Como un caso general, no, CA no permite que las personas busquen certificados por clave pública. De hecho, no permiten que las personas busquen certificados en absoluto , porque el objetivo de los certificados es precisamente evitar cualquier tipo de búsqueda. La CA ha sido diseñada para ser, posiblemente, completamente fuera de línea, por lo que nadie puede acceder a ella.

Cuando los espectadores verifican una firma, usan la clave pública y luego obtienen la confianza de que el propietario de la clave privada correspondiente firmó el mensaje. ¿Quién es ese dueño? Ese es el trabajo del certificado para decir eso. El certificado es una afirmación verificable de que un nombre y una clave pública viven juntos.

En su caso, desde el punto de vista de los clientes, no hay firma, no hash, nada; solo hay su servidor que dice "esto es bueno" o "esto no es bueno" en un elemento de datos que también proporciona su servidor. Cómo manejar las cosas internamente es completamente opaco. En ese sentido, mientras usted quiera que las cosas sean así, entonces las firmas son completamente inútiles. Las firmas solo tienen sentido si puede, al menos potencialmente, mostrarlas a terceros (por ejemplo, a un juez en caso de litigio). Y como una firma solo prueba las cosas con respecto a la clave pública, no a ninguna otra cosa, necesita mantener los certificados a su alrededor, porque los certificados vinculan las claves públicas con el concepto útil de identities (cuando presenta una demanda, demandas a alguien , no a una clave pública).

Además, en su descripción, su servidor parece ser el que firma, no el propietario real del certificado. Por lo tanto, incluso si mantiene una firma, sería su , no la del usuario inicial que escribió los datos en el paso 1.

El concepto importante aquí es que cuando su servidor autentica un cliente "con un certificado", esto es solo autenticación . No le demuestra a a terceros que dicho cliente realmente escribió los datos que usted almacena. De hecho, incluso si mantiene una copia completa de todos los paquetes IP involucrados, esto prueba solo que en alguna fecha pasada no especificada, ese cliente se conectó una vez a su servidor, pero no dice nada sobre los datos que se enviaron a través de esa conexión. La autenticación es solo una prueba de quién está realizando la autenticación, es decir, el servidor, pero no es verificable posteriormente. Si ese punto no te parece claro, entonces debes leerlo de nuevo, y otra vez, hasta que lo comprendas; no puede hacer ningún trabajo útil con certificados si esto no le parece obvio.

Creo que perdió un paso, en el paso número 3 necesita que el usuario firme el hash con su clave privada. Y creo que esta es una tarea que un usuario debe hacer solo (o utilizando javascript o algo similar para que su clave privada no termine en su plataforma (o en cualquier otra).

Si haces esto, entonces, es más fácil hacer que el usuario pegue su parte de clave pública dentro de un formulario en su perfil de usuario para que puedas usarlo fácilmente (hay servicios como bitbucket o github, por ejemplo, que hacer esto).

No puede generar la firma o cualquier parte de ella, como el resumen. Para hacerlo, debe tener la clave privada del usuario, lo que invalidaría su privacidad.

El usuario que envía los datos debe generar la firma digital que contiene el resumen utilizando su clave privada. La firma contendrá la parte pública verificable del certificado del usuario.

Cualquier persona que vea los datos puede autenticarse con dos pasos: 1) descifrar el resumen en la firma usando la clave pública también contenida en la firma y comparar ese resultado con un resumen de los datos creados por el espectador; 2) Verifique que el certificado contenga la clave pública que fue emitida por la CA identificada a la entidad que reclama la autoría. Varios detalles adicionales se pueden incluir en una firma. Las firmas más sólidas contienen una marca de tiempo que confirma que la firma se creó en una fecha y hora determinadas cuando el certificado fue confirmado como válido por el servidor de sello de hora.

La anterior es la descripción estándar de cómo usar PKI para divulgar datos autenticados.

En su caso, recomendaría que se solicite al usuario que envíe un archivo firmado digitalmente y que su solicitud valide la firma. Al intentar capturar la firma en un proceso separado como parte de su aplicación, está asumiendo un trabajo innecesario y divergiendo de las normas ampliamente admitidas. Además, está fuera del ámbito de las soluciones estándar. HTML y JavaScript, por ejemplo, no proporcionan asistencia. Creo que es posible crear una aplicación Java del lado del cliente para aceptar los datos del usuario y luego solicitar que el certificado realice la operación de firma antes de cargar el documento firmado en su servidor. Aunque nunca he visto tal implementación, OWASP proporciona un código relevante para utilizar el Java Cryptographic Architecture . Esto es posible, pero no es el enfoque que recomendaría.

La firma digital de documentos con x.509 certificados PKI es compatible con muchas aplicaciones, incluyendo Microsoft Office . En muchos casos de uso, exigir que el usuario primero firme digitalmente un documento no es una gran carga.

Algunos terceros ofrecen soluciones que podrían ser útiles para usted. Es posible que desee consultar las soluciones que ofrece Adobe o Arx .

Esto se parece mucho a los servicios de directorio LDAP VeriSign (ahora Symantec) opera para sus productos de identificación de clientes, donde puede recuperar los certificados dada la dirección de correo electrónico u otros atributos para buscar (en ldap: //directory.verisign.com ). Para reducir el riesgo de que un hombre en el medio del ataque modifique las respuestas de LDAP, usaría una conexión segura TLS, asegurándose de que el certificado de servidor LDAP proporcionado sea el esperado.