Resumen

  • El nombre Onion v3 contiene la clave pública de identidad del servicio; no nace de una delegación DNS y requiere una prueba de control adecuada a esa raíz.
  • onion-csr-01 vincula una CSR especial a un nonce de la CA y otro del solicitante, la firma con la clave Onion y la mantiene separada de la CSR final.
  • La política CAA puede verificarse en el descriptor cifrado o en un conjunto firmado y caduco enviado durante la finalización, pero el resultado del certificado no revela qué ruta usó la CA.

El relevo donde suele perderse la autoridad

La emisión automatizada es una cadena de relevos. El titular del nombre entrega control demostrable al cliente; el cliente lo presenta dentro de una cuenta ACME; la CA valida una autorización; CAA limita qué emisor puede continuar; la CSR final entrega la clave del certificado. Si un equipo solo conserva el resultado final, todos los testigos intermedios desaparecen.

En .onion, el primer relevo no es DNS. RFC 7686 excluye el sufijo de la resolución ordinaria y el formato v3 de Tor codifica la clave pública Ed25519 de identidad, una suma de comprobación y la versión en la propia dirección. RFC 9799 mantiene el identificador ACME de tipo dns para reutilizar el protocolo, pero la autoridad material sigue siendo la clave Onion.

Por eso dns-01 está prohibido. http-01 y tls-alpn-01 pueden emplearse con las modificaciones del RFC, incluida la conexión propia de la CA a través de Tor y la prohibición de delegarla en Tor2Web. Esas pruebas permiten observar control de un punto de servicio, pero no admiten comodines y no obligan a la clave de identidad a firmar.

El nuevo desafío onion-csr-01 sí lo hace. La CA entrega un nonce con un mínimo de 64 bits de entropía. Si han pasado más de treinta días desde que lo generó, debe rechazar cualquier respuesta basada en él. El solicitante construye una CSR de validación con ese nonce en bruto, bajo caSigningNonce, y añade su propio applicantSigningNonce, también de al menos 64 bits. Después firma la estructura con la clave privada Onion.

La CA no valida el subject de esa CSR. Comprueba su formato PKCS#10, que la clave pública corresponde al nombre, que la firma es válida, que el nonce de la CA coincide exactamente y que el nonce del solicitante está presente y tiene entropía suficiente. La clave pública debe ser distinta de la incluida en la CSR final.

Así quedan definidos tres mandatos. La clave de cuenta autentica mensajes ACME. La clave Onion prueba control de la identidad. La clave final recibe el certificado. El desafío tampoco necesita el key authorization común de ACME: la CSR de validación ya viaja dentro de una solicitud firmada por la cuenta.

La CA necesita permiso para mirar dentro

La descubribilidad restringida de Tor cifra el descriptor para clientes autorizados. Alcanzar la aplicación no concede automáticamente la capacidad de leer el segundo nivel, donde también puede residir CAA. El campo opcional authKey anuncia la clave pública Ed25519 que usará la CA para ese acceso.

La misma clave no puede reutilizarse entre servicios Onion diferentes. La regla evita que el mecanismo de autorización se convierta de forma predeterminada en una etiqueta de correlación. La CA calcula su CLIENT-ID y busca una línea auth-client coincidente. Si no existe, debe asumir que el servicio no exige autenticación de cliente.

Cuando la clave es nueva, el operador modifica, firma y vuelve a publicar el descriptor. La propagación es indeterminada: el RFC espera pocos minutos, sin prometerlos, y recomienda que el desafío sobreviva al menos treinta minutos. La respuesta de autorización indica que la CA ya puede intentar la lectura; no demuestra que todos los directorios hayan entregado la revisión correcta.

Un expediente operativo debe registrar la clave anunciada, la revisión, el instante de publicación, el identificador calculado y el primer descifrado correcto. Sin ellos, un fallo de CAA puede confundirse con rechazo del operador cuando solo hubo propagación incompleta.

CAA conserva su pregunta y cambia de transporte

Los registros CAA mantienen el formato canónico de RFC 8659, pero se alojan en la segunda capa del descriptor. No hay búsqueda ascendente por DNS ni consulta del supuesto TLD .onion. Todos los subdominios bajo la misma dirección base comparten el conjunto.

Para servicios restringidos existe caa-critical en la primera capa. Informa a una CA que hay una política oculta y le impide emitir hasta descifrarla y analizarla. El indicador permite fallar de forma segura sin revelar los valores. No es, sin embargo, un recibo de que la CA completó la comprobación.

La segunda opción es onionCAA en la finalización ACME. El objeto aporta para cada nombre el texto CAA o null, una caducidad Unix —que no debería superar ocho horas— y una firma Ed25519 de la clave Onion. La entrada firmada concatena onion-caa|, la caducidad decimal sin ceros iniciales, otro separador y el texto; para null, el último fragmento queda vacío.

La CA puede aceptar ese conjunto válido como única fuente, ignorarlo y leer el descriptor, o consultar ambos. Cuando no sabe obtener CAA del descriptor y falta el objeto, responde onionCAARequired; el metadato inBandOnionCAARequired permite anunciar la exigencia. El control no termina con “firma correcta”: debe declarar qué fuente gobernó la decisión.

Ambas rutas dependen de la misma autoridad criptográfica. Los directorios Tor no son de confianza; la integridad del descriptor y la firma in-band se verifican con la identidad Onion. El lugar donde aparecieron los bytes no decide quién los autorizó.

La emisión también escribe un registro de exposición

La CA debe conectar por Tor al servicio sin intermediarios. El cliente debería hacer lo mismo con ACME y preferir el endpoint Onion de la CA. De otro modo, el acceso directo a una infraestructura de CA reconocible puede revelar que el host solicitante opera un servicio oculto.

Una redirección http-01 hacia un dominio público puede mostrar la IP de destino o su relación con el servicio. La CA, a su vez, no debe usar una salida Tor para validar el dominio público, pues abriría el riesgo de secuestro de salida.

La transparencia de certificados es aún más definitiva. Un certificado WebPKI público lleva el nombre Onion a registros públicos de CT. Puede ser un intercambio aceptable por confianza de navegador, pero no es neutro. El RFC invita a considerar confianza privada o autofirmada cuando la publicidad no sea necesaria, a minimizar datos de suscriptor y a usar cuentas ACME distintas para servicios que la CA no deba relacionar.

El certificado final prueba un resultado de emisión. No prueba el camino de CAA, la privacidad de la conexión, la ausencia de redirección, la separación de cuentas ni la conveniencia de hacer público el nombre. RFC 9799 permite conservar esos límites si el operador decide registrar cada relevo en lugar de celebrar solamente la meta.

Fuentes