Inscripción Iluminada: El Libro de los Cinco Protocolos de Inscripción de Certificados

En esta entrada de blog, Mike Agrenius Kushner, en su calidad de arquitecto de productos, va a presentar una guía para profanos sobre la inscripción de PKI a través de API y cinco de los protocolos admitidos actualmente por EJBCA. 

Recuerda, si estuviste allí, tu primer día de universidad. El primer acto era acercarse a un pupitre y señalar tu nombre en un libro de contabilidad, tras lo cual te entregaban un endeble trozo de papel con un nombre de usuario (basado en una contracción probablemente embarazosa de las letras de tu nombre) y una contraseña autogenerada (que se te permitía cambiar en algún momento después de aprobar la asignatura de Transformadas Diferenciales en tercer curso). Todo este proceso se llamaba inscripción.

Esto se parece mucho a la primera etapa del ciclo de vida de un certificado, cuando el portador de una clave se presenta a sí mismo y sus credenciales a una Autoridad de Certificación, que entonces otorga a esa entidad un certificado que le permite salir adelante y ser excelente. Todos hemos realizado la inscripción mediante solicitudes de firma de certificado (CSR) y su envío manual a diversas herramientas y aplicaciones a través de líneas command , secuencias de comandos o incluso una interfaz de usuario. La verdadera magia se produce cuando el dispositivo se inscribe por sí solo. Si tienes mucha suerte, ni siquiera sabrás que ha ocurrido.

En esta entrada de blog vamos a examinar cinco de los protocolos de inscripción compatibles con EJBCA: ACME, SCEP, CMP, EST y nuestra propia API REST . Vamos a ver la historia de cada protocolo, sus pros y sus contras y dónde es probable que se apliquen. En este blog, trataremos la autoinscripción de Microsoft como un caso de uso completamente distinto.

El Protocolo de Gestión de Certificados (CMP) es el más antiguo de los protocolos soportados por EJBCA, redactado por primera vez en los ya lejanos días de 1996, alcanzando el estatus de RFC con RFC 2510 en 1999 y llegando a su estado actual con CMPv2 con RFC 4210 en 2005.

Como protocolo, CMP ciertamente muestra su edad, tanto en términos de diseño como de complejidad injustificada, en parte debido al estado incipiente de la PKI cuando fue diseñado. La complejidad (y, en algunos casos, la ambigüedad) de la RFC hace que varias implementaciones de servidores y clientes puedan desviarse, y de hecho lo hacen, en lo que respecta a los detalles.

La principal fortaleza de CMP es también su principal debilidad: es uno de los protocolos que más operaciones y permutaciones ofrece. Esto también da lugar a que los clientes con pretensiones justas de soportar todo el RFC 4210 sean pocos y distantes entre sí.

Esta antigüedad y resistencia también significa que CMP como protocolo no depende de muchas pilas tecnológicas. Puede enviarse a través de HTTP, TCP o una paloma mensajera.

Uno de los principales aspectos que mantienen la relevancia de CMP en la actualidad es el marco 3GPP LTE, desarrollado originalmente por y para el sector de las telecomunicaciones, que añade a CMP soporte para certificados de proveedores. Esto permite a un fabricante dotar a un dispositivo de un certificado firmado por su propia CA. Este certificado puede ser ofrecido por el usuario final del dispositivo para que se inscriba en su PKI. Otro ejemplo son las redes ferroviarias, donde CMP se define como protocolo estándar para los sistemas ERTMS.

Si quieres empezar a jugar con EJBCA y CMP, te recomiendo esta sección del vídeo PKI at the Edge para la comunidad Keyfactor .

+ Si necesita un protocolo con un conjunto completo de operaciones

+ Usted es un fabricante de telecomunicaciones o alguien en una industria que depende de 3GPP

- No está preparado para mantener un cliente complejo que pueda necesitar tener en cuenta diferentes versiones de la RFC de diferentes proveedores de CA.

Casi tan antiguo como el CMP, el Protocolo Simple de Inscripción de Certificados (SCEP ) vio la luz en 2000. A diferencia de CMP, SCEP se diseñó para ser lo más ligero y sencillo posible, basándose en un protocolo propietario desarrollado originalmente para Cisco, que también presentó el primer borrador de SCEP.

Comparado con CMP, el conjunto de operaciones de SCEP es mucho más limitado, con unos pocos comandos para inscribir y recuperar certificados y CRLs, con versiones posteriores del borrador con alguna capacidad ligeramente oblicua para realizar también renovaciones. SCEP quedó atrapado en el infierno de los borradores entre la publicación de la versión 23 del borrador original en 2011 y la publicación final del RFC 8894 en 2020, lo que significa que la versión 23 del borrador sigue siendo la versión de facto soportada por la mayoría de las CA software, incluida EJBCA.

Debido a su legado y uso generalizado, SCEP sigue siendo a día de hoy un protocolo de inscripción popular, especialmente para aplicaciones ligeras como la inscripción de dispositivos. La elección de Microsoft de ampliar SCEP en la definición de su servicio Intune para inscribir dispositivos en la nube Azure ha consolidado a SCEP como un protocolo compatible durante muchos años.

Debido al enfoque en ser ligero, SCEP carece de soporte para varias características que podrían considerarse esenciales, incluyendo la revocación y la renovación explícita (que existe en la RFC, pero no en el borrador 23). El cifrado de la carga útil de SCEP es también uno de sus principales inconvenientes, ya que el método de cifrado se basa en la clave pública de la CA. Esto significa que SCEP sólo admite claves RSA y es muy poco probable que tenga alguna utilidad en un futuro post-cuántico. Podría decirse que el propio proceso de cifrado es lo suficientemente complejo como para anular la "S" de SCEP.

+ Al ser un protocolo heredado sigue teniendo un uso y apoyo generalizados

+ Un hecho si su caso de uso implica Microsoft Intune

- La adopción aún limitada de la RFC frente al borrador puede dar lugar a problemas de compatibilidad en el futuro

- El conjunto de operaciones no incluye el ciclo de vida completo del certificado

- Sin soporte para curvas elípticas y agilidad criptográfica limitada

- La propia Cisco recomienda EST para las nuevas aplicaciones

En muchos sentidos el sucesor espiritual de SCEP, el protocolo Enrollment over Secure Transport (EST) fue escrito por elementos de Cisco y Aruba Networks como un protocolo de inscripción ligero con TLS en mente, así como la incorporación de las lecciones aprendidas en el momento de su publicación en 2013. Al igual que con SCEP, EST carece de un tipo de mensaje para la revocación, pero soporta la renovación fuera de la caja. EST se describe en el RFC 7030.

Uno de los principios de EST es, concretamente, su dependencia de TLS, que permite que las cargas útiles se transmitan a través de un canal cifrado y evita así la necesidad de cifrarlas utilizando un secreto compartido. Esto, a su vez, permite a EST manejar claves basadas en curvas elípticas, a diferencia de SCEP.

Al igual que con SCEP, EST puede utilizar un secreto compartido (contraseña) para la autenticación del cliente, pero también puede hacer uso de un certificado de cliente emitido por un tercero de confianza.

Confiar en la pila HTTPS conduce a consultas más simples (EST puede ser llamado con curl), lo que permite implementaciones de cliente ligeras. Además, EST puede utilizarse para que las claves se generen en el servidor. Estos detalles hacen de EST la elección natural para IoT y otros casos de uso de PKI ligera.

+ Si necesita un protocolo con un conjunto completo de operaciones

+ Usted es un fabricante de telecomunicaciones o alguien en una industria que depende de 3GPP

- No está preparado para mantener un cliente complejo que pueda necesitar tener en cuenta diferentes versiones de la RFC de diferentes proveedores de CA.

ACME es uno de los pocos protocolos desarrollados con un propósito muy singular en mente: fue desarrollado por una corporación de beneficio público conocida como Internet Security Research Group (ISRG) como parte de un esfuerzo concertado para hacer que TLS esté ampliamente disponible y se utilice en Internet. Los otros elementos de este esfuerzo son la autoridad de certificación Let's Encrypt y el cliente de certificados CertBot.

Lo que diferencia a ACME de otros protocolos de inscripción es que se centra totalmente en la automatización, a lo largo de todo el ciclo de vida del certificado y, especialmente, en permitir al cliente aportar una prueba de identidad (propiedad de un nombre DNS específico) sin necesidad de interacción o verificación manual por parte de la CA.

Para ello, ACME proporciona un marco de retos que permite a la CA especificar una serie de formas para que el cliente demuestre la propiedad sobre cualquier recurso que se vaya a especificar como identidad de ese certificado, ya sea un nombre de DNS o una dirección de correo electrónico para un certificado S/MIME. En teoría, se supone que un cliente que ejecute ACME debe ser "fuego y olvido", inscribiendo y renovando continuamente el certificado mientras se siga controlando la identidad dada.

Aunque esto parece una cornucopia de bondades de PKI, conviene tener en cuenta que ACME se ha escrito pensando principalmente en el caso de uso de certificados TLS . Aunque los redactores del RFC 8555 permitieron hábilmente extensiones del RFC para definir tipos de desafío adicionales (y existen varios como RFC o borradores), el protocolo ACME sigue dependiendo de que se realice esta interacción; de hecho, omitirla anula por completo el caso de uso de ACME.

La complejidad de esta interacción también hace recaer la responsabilidad sobre el soporte del cliente, ya que cualquier desafío extendido o variación de la RFC alojada por el servidor no tiene sentido a menos que los clientes (de los cuales CertBot es uno, pero hay una plétora) decidan respetarlo. Así que ten en cuenta que cualquier caso de uso que diverja del modelo general de interacción CA/cliente necesita ser soportado tanto por el lado del servidor como del cliente.

+ Mejor protocolo para la emisión de certificados TLS

+ Proporciona un conjunto completo de operaciones y automatización integrada para la inscripción

+ La renovación automática fomenta el uso de certificados de corta duración, lo que a su vez proporciona agilidad criptográfica.

+ Una RFC fácilmente ampliable ofrece amplias posibilidades de encontrar más casos de uso

- Vanilla RFC está optimizado para los certificados de TLS , mientras que otros casos de uso necesitan asegurarse de que existe compatibilidad con clientes de^terceros.

- Independientemente del caso de uso, ACME depende de que se procese una impugnación como parte del flujo de trabajo. Si su caso de uso no implica permitir que la CA verifique el control de un recurso, entonces ACME puede no ser el mejor protocolo para usted.

Por último, vamos a hablar de nuestra API REST propia, complementada por nuestra API WebService heredada. Esta API es, naturalmente, tan capaz como todas las demás, pero además proporciona capacidades de comprensión y gestión, permitiendo flujos de trabajo complejos como trabajar con el sistema de aprobación de EJBCA, gestionar entidades finales, tokens criptográficos y CAs.

Al igual que EST, la API REST de EJBCAse basa en TLS para la seguridad e integridad de los mensajes, pero también se puede proporcionar autenticación mediante OAuth, así como un certificado de cliente. Naturalmente, nuestra API REST está en constante desarrollo, por lo que a medida que surgen nuevos flujos de trabajo, se pueden implementar y desplegar mucho más rápidamente que esperar a que pase una actualización de RFC.

La desventaja de confiar en nuestra API REST es, por supuesto, que te bloqueas en EJBCA como un único proveedor, como ocurre con cualquier API propietaria. Este es naturalmente el caso de toda la industria, ya que no ha habido ningún intento exitoso de crear una API REST estandarizada entre los proveedores de PKI.

+ Infinitamente ampliable, tanto a petición de Keyfactor como de cualquiera con acceso al código fuente.

+ Proporciona flujos de trabajo de inscripción y emisión más granulares en comparación con otros protocolos.

+ Puede utilizarse con los flujos de trabajo más complejos de EJBCA, como las aprobaciones.

+ También puede utilizarse para gestionar aspectos de EJBCA , como cripto-tokens, entidades finales y CAs.

- Al tratarse de un protocolo propietario, la compatibilidad de la API REST de EJBCAcon clientes de terceros es limitada.

Para que pueda cubrir todos sus casos de uso de PKI hoy y en el futuro, es probable que necesite flexibilidad para elegir los protocolos pertinentes. EJBCA admite estos y otros protocolos, una amplia variedad de casos de uso de infraestructura de clave pública (PKI), escenarios e integraciones en otros ecosistemas de aplicaciones, y está probado en grandes despliegues en todo el mundo. Y como está disponible en open source y en versiones de prueba gratuitas en la nube, puede seguir adelante y probarlo ya hoy mismo.

¿Quiere probarlo usted mismo?

• Vea la segunda parte de la formación PKI at the Edge para aprender a generar certificados y CRL utilizando EJBCA y Bouncy Castle con CMP, así como la API REST.
• Para una especificación detallada, consulte EJBCA Interoperabilidad y certificaciones.
• Si necesita asistencia para otros protocolos o casos de uso, póngase en contacto con nosotros.