Protocolo sencillo de inscripción de certificados

El Protocolo Simple de Inscripción de Certificados (SCEP) se describe en el RFC informativo 8894. Las versiones anteriores de este protocolo se convirtieron en un estándar industrial de facto para el aprovisionamiento práctico de certificados digitales, principalmente para equipos de red. 

El protocolo se ha diseñado para que la solicitud y emisión de certificados digitales sea lo más sencilla posible para cualquier usuario de red estándar. Estos procesos suelen requerir una gran intervención por parte de los administradores de red , por lo que no han sido adecuados para implementaciones a gran escala.

El Protocolo Simple de Inscripción de Certificados (SCEP) sigue siendo el protocolo de inscripción de certificados más popular y ampliamente disponible, utilizado por numerosos fabricantes de equipos y software de red que desarrollan métodos simplificados para gestionar certificados y facilitar su implementación a gran escala para usuarios cotidianos. Por ejemplo, el Sistema Operativo de Interconexión de Redes (IOS) de Cisco lo utiliza, aunque Cisco promueve la Inscripción sobre Transporte Seguro (EST), con funciones adicionales, y los iPhones ( iOS ) para inscribirse en la infraestructura de clave pública (PKI) empresarial. ^{[ 1 ]} La mayoría del software PKI (específicamente las implementaciones RA) lo admite, incluyendo el Servicio de Inscripción de Dispositivos de Red (NDES) del Servicio de Certificados de Active Directory e Intune . ^{[ 2 ]}

• Las versiones antiguas de SCEP, que todavía se utilizan en la gran mayoría de las implementaciones, se limitan a registrar certificados únicamente para claves RSA.
• Debido al uso del formato autofirmado PKCS#10 para las solicitudes de firma de certificados (CSR), los certificados solo se pueden registrar para claves que admitan (alguna forma de) firma. Esta limitación la comparten otros protocolos de registro basados ​​en CSR PKCS#10, como EST y ACME , e incluso el flujo de trabajo de registro web de la mayoría del software PKI, donde el solicitante comienza generando un par de claves y una CSR en formato PKCS#10. Por ejemplo, ACME , que también utiliza PKCS#10, emite certificados TLS que, por definición, deben ser capaces de firmar para el protocolo de enlace TLS. Sin embargo, esta distinción es, hasta ahora, principalmente teórica, ya que en la práctica todos los algoritmos comúnmente utilizados con certificados admiten la firma. Esto podría cambiar con la criptografía postcuántica, donde algunas claves solo admiten KEM . El formato CRMF, utilizado por el Protocolo de Gestión de Certificados (CMP) y CMS, es más flexible en este sentido, ya que también admite claves que solo se pueden usar para cifrado.
• Si bien la verificación del origen de las solicitudes de registro de certificados, es decir, la autenticación del solicitante, es el requisito de seguridad más crítico, por razones prácticas, su compatibilidad no es estrictamente necesaria en SCEP. La autenticación de cliente basada en firmas mediante un certificado ya existente sería el mecanismo preferido, pero en muchos casos no es posible o no es compatible con las implementaciones actuales. Como alternativa, SCEP simplemente proporciona el uso de una clave secreta compartida, que debe ser específica para cada cliente y usarse solo una vez.
• La confidencialidad de la clave secreta compartida, que se utiliza opcionalmente para la autenticación de origen, es frágil, ya que debe incluirse en el campo «challengePassword» del CSR, el cual, a su vez, está protegido por un cifrado externo. Habría sido más seguro utilizar un algoritmo MAC basado en contraseña, como HMAC.
• El cifrado de toda la estructura PKCS#10 para proteger el campo 'challengePassword' (que se utiliza para la autenticación de origen autónoma) presenta un inconveniente adicional: la solicitud de firma de certificado (CSR) completa se vuelve ilegible para todas las partes, excepto para el receptor final previsto (la CA), aunque la mayor parte de su contenido no sea confidencial. Por lo tanto, la estructura PKCS#10 no puede ser verificada por agentes intermedios como una autoridad de registro (RA).

SCEP fue diseñado por Verisign para Cisco ^{[ 3 ]} como una alternativa ligera a Certificate Management over CMS (CMC) y al muy potente pero también bastante voluminoso Certificate Management Protocol (CMP). Recibió apoyo de Microsoft desde el principio con su continua inclusión en Windows a partir de Windows 2000. ^{[ 4 ]} Alrededor de 2010, Cisco suspendió el trabajo en SCEP y desarrolló EST en su lugar. En 2015, Peter Gutmann revivió el borrador de Internet debido al uso generalizado de SCEP en la industria y en otros estándares. ^{[ 5 ]} Actualizó el borrador con algoritmos más modernos y corrigió numerosos problemas en la especificación original. En septiembre de 2020, el borrador se publicó como RFC 8894 informativo , más de veinte años después del inicio del esfuerzo de estandarización. ^{[ 6 ]} La nueva versión también admite el registro de certificados que no son RSA (por ejemplo, para claves públicas ECC ). 

• Protocolo de gestión de certificados (CMP)
• Gestión de certificados a través de CMS (CMC)
• Inscripción a través de transporte seguro (EST)
• Entorno automatizado de gestión de certificados (ACME)

• Presentación de diapositivas que describe SCEP: pkix-3.pdf