Extensiones de certificado - restricciones específicas

0

Tengo preguntas sobre las extensiones de certificado y qué extensión específica debo usar en mi situación.

El problema es el siguiente: tengo una CA y quiero que la CA emita un certificado solo para un tipo específico de servicio. Por ejemplo, imagine una aplicación que puede hacer 4 tipos diferentes de acciones (digamos acción A, acción B, C y D). Para cada acción la aplicación tiene que autenticarse. Supongamos ahora que algunas aplicaciones solo desean realizar las acciones A y C. Quiero emitir un certificado para esta aplicación que especifique solo estos dos tipos de acciones y la aplicación no puede utilizar este certificado para autenticarse para realizar la acción D.

Y no solo tiene aplicaciones. Puedes obtener imágenes de los usuarios aquí.

Me doy cuenta de que puedo resolver esto con 4 tipos diferentes de CA para cada tipo de servicio, pero esto parece ser torpe. Estudié extensiones de certificados pero no encontré algunos que se ajusten a mis necesidades. Y también leí acerca de los certificados atribuidos que podrían resolver estas situaciones, pero también escuché que no son tan comunes, así que no estoy seguro de ellos.

¿Tengo que usar certificados atribuidos o me olvido de alguna solución simple?

¡Gracias!

    
pregunta Mumbar 04.04.2014 - 16:53
fuente

1 respuesta

1

Hay principalmente dos formas principales, una de las cuales utiliza extensiones de certificado y una de las cuales es una mala idea. Estos dos son los mismos ...

En un certificado , puede codificar "usos" como parte de la Extensión Extended Key Usage . En su terminología, definiría algunos OID para las acciones A, B, C y D, y solo colocaría OID para A y C en el certificado.

Lo que es malo al respecto es que está combinando autenticación y autorización en un certificado, y los certificados no son buenos para la autorización. Para ser claros:

  • Autenticación se trata de asegurarse de quién llama. Para eso están los certificados: unen una identidad a una clave pública , y el protocolo de transporte (por ejemplo, SSL) se asegura de que la persona que llama controle la clave privada correspondiente a ese público clave.

  • Autorización se trata de decidir qué se le debe permitir a una persona determinada. Normalmente se lleva a cabo después de la autenticación.

Los certificados no son buenos para las tareas de autorización, por diversas razones, en particular porque el único mecanismo que puede "cancelar" un certificado es revocation , que es asíncrono (puede llevar varias horas o incluso días para que una revocación se propague a través de CRL) y todo o nada (no puede revocar un certificado parcialmente). En su situación, esto significaría que si desea bloquear una aplicación específica, el bloqueo tomará horas para ser efectivo; y no puede eliminar el derecho a realizar la acción C sin eliminar el derecho a realizar la acción A. Del mismo modo, si desea otorgar un nuevo derecho de acceso a un cliente, debe emitir un nuevo certificado y enviarlo al cliente; Si el cliente almacena sus certificados en un dispositivo (por ejemplo, una tarjeta inteligente), esto puede generar problemas de uso (una PC básica puede utilizar tarjetas inteligentes de forma inmediata, pero escribir en la tarjeta inteligente requiere algún software específico).

Por estas razones, realmente debería usar certificados solo para autenticación. En un contexto de cliente / servidor, el cliente utiliza el certificado para demostrar su identidad al servidor, pero la autorización es una decisión que es puramente del lado del servidor. No es necesario que los datos de autorización se produzcan en el lado del cliente.

En un mundo de Microsoft / Active Directory, la autorización sería incorporada por ACL y membresías grupales en los servidores de AD. Los certificados se utilizan para asignar el solicitante a una cuenta, pero los derechos otorgados a esa cuenta se mantienen en el servidor AD, no en el certificado.

    
respondido por el Tom Leek 04.04.2014 - 17:09
fuente

Lea otras preguntas en las etiquetas