Reglas comunes a todos los certificados (sección 6.1.1)

La especificación técnica establece:

Algoritmo hash para usar antes de firmar el certificado: se admitirá SHA-256, se debe admitir SHA-384, no se admitirán MD5, MD2 ni SHA-1.

Pregunta: ¿EJBCA utiliza los algoritmos MD5, MD2 y SHA-1, y es posible limitar/seleccionar qué algoritmos hash utilizar?

Respuesta: La sección 6.1.1 trata sobre los certificados emitidos. En EJBCA, esto es un problema de configuración. Si configura sus CA correctamente, cumplirán con la sección 6.1.1. MD2 y MD5 no son compatibles con la emisión de certificados en EJBCA. SHA-1 es compatible por razones heredadas, pero solo si la CA está configurada para usar SHA-1. Una configuración predeterminada de una CA no usará SHA-1.

Requisitos generales (sección 9.5.1)

La especificación técnica establece:

Los algoritmos hash utilizados antes de generar firmas en el campo de protección de PKIMessage y para la prueba de posesión serán los mismos que los algoritmos hash especificados en la subcláusula 6.1.1.

Pregunta: ¿Es posible seleccionar los algoritmos hash que se permiten para la prueba de posesión? ¿Permitirá EJBCA el uso de alguno de los algoritmos no permitidos de la versión 33.310? Por ejemplo, MD5, MD2 y SHA-1.

Respuesta: En relación con el mensaje de respuesta que envía EJBCA a una solicitud, el algoritmo predeterminado es SHA256. SHA1 es compatible si lo solicita el cliente que envía la solicitud. MD2 y MD5 no son compatibles. Dado que EJBCA exige estrictamente la inscripción única de certificados de proveedor para las solicitudes iniciales de nuevos clientes (estaciones base), es imposible que una estación base comprometida debilite la seguridad general del sistema.

Perfil del PKIMessage (sección 9.5.2)

La especificación técnica establece:

Este perfil requiere el soporte y uso del campo de protección opcional de tipo PKIProtection.

Pregunta: ¿EJBCA ya requiere este campo? Dado que es opcional en CMP, ¿existe alguna configuración para que sea obligatorio para cumplir con ciertos perfiles de CMP, como 3GPP?

Respuesta: Sí, cuando se utiliza CMP en modo de certificado de proveedor, se requiere el uso de PKIProtection y extraCerts como se define en 9.5.2 en la solicitud CMP enviada por el cliente.

La especificación técnica establece:

Todos los mensajes CMPv2 utilizados dentro de este perfil deberán constar exactamente de un PKIMessage.

Pregunta: ¿Existe alguna forma en EJBCA de especificar que un mensaje solo puede contener un PKIMessage? ¿Permitirá EJBCA varios objetos PKIMessage en un mismo mensaje?

Respuesta: EJBCA no permite múltiples objetos PKIMessage de forma predeterminada. Es posible usar una secuencia de PKIMessages al usar el tipo de mensaje específico NestedMessageContent (RFC4210, sección 5.1.3.4). EJBCA admite NestedMessageContent, pero requiere una configuración específica para ello. Sin esta configuración (no predeterminada), la verificación de NestedMessageContent siempre fallará.

La especificación técnica establece:

Este perfil requiere la compatibilidad con el campo opcional extraCerts. Los certificados incluidos en este campo pueden ordenarse en cualquier orden.

Pregunta: ¿Permitirá EJBCA que los certificados del campo adicional estén en cualquier orden? Por ejemplo, si se trata de una cadena de certificados, ¿deben agregarse en un orden específico? ¿O EJBCA permite que se ordenen en cualquier orden?

Respuesta: EJBCA acepta extraCerts en cualquier orden.

Perfil del campo PKIHeader (sección 9.5.3)

La especificación técnica establece:

Los campos de remitente y destinatario deben contener las identidades de la estación base y de la RA/CA. Estas identidades deben ser idénticas al nombre del sujeto presente en el certificado.

Pregunta: ¿EJBCA a) ya requiere esto o b) puede requerir que PKIMessage.header.sender coincida con el nombre del sujeto del certificado de la clave utilizada para firmar PKIMessage y que PKIMessage.header.recipient coincida con el nombre del sujeto del certificado de la CA?

Respuesta: Sí, es obligatorio. El sujeto se compara con la entidad final prerregistrada en EJBCA, según el campo de nombre del sujeto. Si el DN prerregistrado (que se incluirá en el certificado emitido) no coincide, no se encontrará la entidad final y no se podrá emitir el certificado. El campo "destinatario" se utiliza para seleccionar la CA utilizada; por lo tanto, si este no coincide con el certificado de la CA, no se encontrará la CA que firmará el certificado.

La especificación técnica establece:

El campo “protectionAlg” de PKIHeader es obligatorio.

Pregunta: ¿EJBCA ya requiere este campo o puede hacerlo obligatorio en una configuración? ¿ Es posible limitar el tipo de algoritmo permitido para este campo?

Respuesta: Sí, se requiere protectionAlg para verificar la protección, lo cual es obligatorio. No es posible limitar el algoritmo permitido en este campo (más allá de lo disponible o no). El cliente decide qué algoritmo utilizar.

La especificación técnica establece:

El algoritmo de firma se basará en el algoritmo contenido en el campo de algoritmo del campo SubjectPublicKeyInfo del certificado del firmante.

Pregunta: ¿EJBCA ya lo requiere? De no ser así, ¿es posible configurar que el algoritmo de firma utilizado para calcular PKIMessage.protection coincida con el campo SubjectPublicKeyInfo.algorithm del certificado de la clave de firma?

Respuesta: Sí, el algoritmo y la clave deben coincidir. Dado que la firma se verifica, la verificación fallará si no coincide. La estación base tampoco podrá crear la firma si el algoritmo no coincide con la clave.

La especificación técnica establece:

El uso del campo transactionID es obligatorio

Pregunta: ¿EJBCA lo exige? De no ser así, ¿se puede exigir mediante una configuración?

Respuesta: A partir de RFC 4210, un cliente PUEDE completar el campo transactionID de la solicitud. EJBCA lo admite y lo gestionará correctamente si el cliente lo envía. Sin embargo, no es obligatorio su uso.

La especificación técnica establece:

El uso de los campos senderNonce y recipNonce es obligatorio

Pregunta: ¿EJBCA rellena el senderNonce y requiere/valida el recipNonce? Si se usa HSM, ¿se puede generar el senderNonce en el HSM o el HSM puede generar el número aleatorio? Y si se genera, ¿se puede obtener una nueva semilla después de X uso?

Respuesta: El cliente, es decir, la estación base, rellena el senderNonce. EJBCA admite senderNonce y rellena el recipNonce con el mismo valor que senderNonce (RFC4210 sección 5.1.1). Dado que el remitente (cliente/estación base) crea el senderNonce, el HSM utilizado por EJBCA no es relevante.

La especificación técnica establece:

El recipNonce en el primer mensaje de la transacción debe ser establecido en 0 por el remitente y debe ser ignorado por el destinatario del mensaje.

Pregunta: ¿EJBCA ignorará el recipNonce en el primer mensaje?

Respuesta: Sí, se ignora.

Perfil del campo PKIBody: solicitud de inicialización (sección 9.5.4.2)

La especificación técnica establece:

La solicitud de inicialización según se especifica en IETF RFC 4210 [4] debe contener exactamente un CertReqMessages

Pregunta: ¿EJBCA hace cumplir este requisito?

Respuesta: EJBCA solo admite un mensaje de solicitud. Si un PKIbody contiene varios CertReqMsg, solo se utiliza el primero.

La especificación técnica establece:

El campo publicKey del CertTemplate será obligatorio y contendrá la clave pública de la estación base que será certificada por la RA/CA.

¿EJBCA requiere que PKIMessage.body.ir[0].certReq.certTemplate.publicKey esté presente y que contenga un valor de tipo SubjectPublicKeyInfo (como se define en RFC 5280)?

Respuesta: Sí.

La especificación técnica establece:

El CertReqMessage deberá contener un campo POP de tipo ProofOfPossession

Pregunta: ¿EJBCA exige que PKIMessage.body.ir[0].popo esté presente y contenga un elemento de firma?

Respuesta: Sí, se aplica. A menos que se configure "RA Verificar Prueba de Posesión" en el alias de CMP en EJBCA, lo cual no es posible al usar el modo 3GPP (Proveedor/Cliente).

La especificación técnica establece:

Si se utiliza el campo poposkInput del tipo POPOSigningKeyInput dentro del campo POPOSigningKey, el campo del remitente dentro de POPOSigningKeyInput será obligatorio y contendrá la identidad de la estación base.

Pregunta: ¿EJBCA cumple con este requisito?

Respuesta: Sí, si es POPOSigningKeyInput el remitente debe ser el mismo que el remitente en la solicitud, que debe ser el mismo que la identidad de la estación base.

La especificación técnica establece:

El campo extraCerts del mensaje PKI que contiene la solicitud de inicialización será obligatorio y contendrá el certificado de la estación base proporcionado por el proveedor. Si el certificado de la estación base no está firmado por la CA raíz del proveedor, también se incluirán en el campo extraCerts los certificados intermedios de la cadena hasta el certificado raíz del proveedor.

Pregunta: No parece requerir que se incluya la CA raíz del proveedor, ¿EJBCA aceptará solicitudes que no tengan la CA raíz incluida en los certificados adicionales?

Respuesta: Sí, EJBCA acepta solicitudes con y sin el certificado de la CA raíz incluido en extraCerts. En nuestra opinión, el certificado de la CA raíz no debería incluirse en extraCerts, ya que debe ser confiable fuera de banda, pero lo aceptamos y verificamos en ambos casos.

Perfil del campo PKIBody: Respuesta de inicialización (sección 9.5.4.3)

La especificación técnica establece:

La respuesta de inicialización como se especifica en [4] contendrá exactamente un certificado de estación base generado

Pregunta: ¿EJBCA alguna vez enviará más de una estructura CertResponse?

Respuesta: EJBCA solo puede enviar una estructura CertResponse.

La especificación técnica establece:

El certificado generado se transferirá a la estación base en el campo certifiedKeyPair del campo CertResponse

Pregunta: ¿EJBCA coloca el certificado generado en el campo certifiedKeyPair?

Respuesta: Sí.

La especificación técnica establece:

La transferencia no deberá ser cifrada (es decir, el campo de certificado en CertorEncCert deberá ser obligatorio).

Pregunta: ¿EJBCA cifrará alguna vez el certificado o la transferencia? ¿EJBCA admite el cifrado?

Respuesta: EJBCA no cifrará el CertifiedKeyPair al usar la configuración 3GPP. El CertifiedKeyPair solo se cifra cuando se solicitan claves generadas por el servidor y la clave privada se devuelve en el mensaje. Las claves generadas por el servidor solo se generan como respuesta a dichas solicitudes, según el Apéndice D.4 de RFC4210, y solo cuando la opción "Permitir claves generadas por el servidor" está habilitada en la configuración del alias de CMP, que no es la configuración predeterminada.

Perfil del campo PKIBody: solicitud de actualización de clave y respuesta de actualización de clave (sección 9.5.4.4)

La especificación técnica establece:

El campo extraCertsField es obligatorio y debe contener el certificado de la estación base correspondiente a la clave privada utilizada para firmar el mensaje PKI. También se deben incluir los certificados de CA intermedia si el certificado de la estación base no está firmado directamente por una CA raíz.

Pregunta: ¿EJBCA ya hace cumplir esto?

Respuesta: Sí. EJBCA admite que el certificado de CA intermedia no se incluya en la solicitud, ya que hemos visto este comportamiento (no compatible) en los equipos de producción de algunos proveedores, sin embargo, esto requiere que el certificado de CA intermedia esté habilitado como una "CA de proveedor" confiable en la configuración de alias de CMP.

Pregunta: El RFC 4210 establece que un certificado recién emitido cuya recepción no esté confirmada será revocado. En la página de documentación de EJBCA se indica que EJBCA no cumple con este requisito del RFC 4210. ¿Se planea al menos incluir esta configuración en futuras versiones? EJBCA no debería decidir por el usuario si esta es una característica positiva del estándar. Esto me preocupa, ya que revocar certificados no confirmados es un requisito.

Respuesta: No tenemos planes de este tipo por el momento. Cada vez es más común usar la función ImplicitConfirm de la RFC 4210, sección 5.3.19.10.

Perfil del campo PKIBody: solicitud de confirmación de certificado y respuesta de confirmación (sección 9.5.4.5)

La especificación técnica establece:

Se omitirá el campo extraCerts del PKIMessage que contiene la solicitud de confirmación del certificado y la respuesta de confirmación.

Pregunta: ¿EJBCA se adhiere a esto?

Respuesta: Sí, no se incluye ningún campo extraCerts en el mensaje de respuesta de Confirmación.