Resumen

  • El grupo de trabajo ACME envió draft-ietf-acme-profiles-02 al IESG el 21 de septiembre de 2026. «Publication Requested» describe una solicitud, no la aprobación del IESG ni un RFC publicado.
  • El servidor puede anunciar perfiles, aceptar de forma excepcional uno no anunciado, comprobar la elegibilidad de la cuenta y rechazarlo en finalize. Por eso, el nombre organiza la orden sin prometer su resultado.

Una consola puede mostrar hoy un perfil, ocultarlo mañana y seguir aceptándolo para una cuenta con un acuerdo privado. También puede aceptar la orden y rechazar la finalización si la CA deja de emitir con ese perfil. El borrador no elimina esas diferencias: les da una forma protocolaria.

La consecuencia para un equipo de certificados es inmediata. Guardar únicamente la cadena elegida resulta tan incompleto como guardar únicamente el CSR. Hay que saber qué anunció el servidor, qué descripción leyó el operador, qué cuenta hizo la solicitud, qué devolvió la orden y qué certificado apareció al final.

El expediente está en Publication Requested

El historial del IETF registra que el 21 de septiembre la revisión 02 pasó de Working Group Last Call a «Submitted to IESG for Publication». El estado del IESG figura como «Publication Requested», con Deb Cooley como Area Director responsable y sin fecha de telechat. Mike Ounsworth presentó la solicitud en nombre del grupo después de declarar superada la última llamada.

No equivale a una aprobación. El destino propuesto es Proposed Standard, pero el texto sigue siendo un Internet-Draft. El informe del shepherd caracteriza el consenso como débil porque la propuesta se consideró sencilla y hubo pocas respuestas firmemente favorables; no registra controversia ni apelación. Las implementaciones enumeradas y la experiencia de Let’s Encrypt acreditan trabajo real, no una adopción universal.

La política entra en newOrder

El RFC 8555 separa la creación de una orden de la entrega posterior del CSR en finalize. La extensión añade a Directory un objeto opcional profiles: cada clave es un identificador breve y cada valor apunta a una descripción legible, que incluso puede viajar en una data URL.

El cliente puede incluir el nombre en newOrder.profile. Si el servidor lo acepta, lo repite en el objeto Order. La selección de características queda así fijada antes del CSR, mientras el CSR conserva la clave pública y subjectAltName. El borrador sostiene que esta distribución puede reducir el análisis y la copia de ASN.1 en la lógica de políticas de la CA.

Nada de ello sustituye la gestión de cuentas o la validación de identificadores. Tampoco existe un registro mundial de nombres. El ámbito real es un Directory concreto, en un momento concreto, acompañado por una descripción controlada por ese operador.

Cinco momentos, cinco significados

Primero está el anuncio. Dice que el servidor ofrece públicamente un selector, pero no que cualquier cuenta tenga derecho a usarlo. Si el perfil no admite los identificadores solicitados o la cuenta no supera una allowlist, el servidor debe responder invalidProfile.

Segundo está la excepción. El cliente no debería pedir un nombre ausente del Directory y el servidor debería rechazarlo; aun así, puede aceptarlo en situaciones excepcionales. El borrador menciona un perfil privado acordado fuera del protocolo o la sustitución de un certificado antiguo tras una revocación masiva.

Tercero está la omisión. Cuando el cliente no envía el campo, se recomienda al servidor que elija y asocie un perfil. La ausencia en la petición no demuestra que la orden carezca de perfil: hay que leer la respuesta.

Cuarto está la elegibilidad, que puede depender de la cuenta y de la combinación de identificadores. Un nombre reconocido no elimina ese juicio.

Quinto está la finalización. Si la CA deja de estar dispuesta a emitir con el perfil asociado, debe devolver invalidProfile en finalize. El texto aconseja dejar caducar las órdenes ya abiertas antes de suspender un perfil, pero conserva la regla de error para el caso en que la disponibilidad cambie.

La experiencia de Let’s Encrypt marca el límite de la etiqueta

La documentación de Let’s Encrypt identifica el Directory actual como lista canónica y advierte que no todos los perfiles aparecen en todos los entornos; algunos pueden estar limitados a cuentas autorizadas. classic, tlsserver y shortlived difieren en ventanas de autorización, vida de la orden, duración del certificado, identificadores y campos emitidos.

La oferta tampoco es inmutable. tlsclient dejó de estar disponible el 8 de julio de 2026. tlsserver pasó a una vigencia de 45 días el 13 de mayo, y existe una hoja de ruta para reducir más adelante la duración de classic.

Estos cambios son pruebas sobre Let’s Encrypt, no sobre todas las CA. Enseñan que un nombre adquiere significado dentro del endpoint, la documentación y la fecha que lo acompañan.

De la etiqueta al rastro comprobable

El rastro mínimo empieza con los bytes del Directory y su hora de obtención. Debe añadir la URL de descripción y el hash del contenido consultado. Después registra endpoint, cuenta, identificadores, nombre solicitado, decisión de elegibilidad y objeto Order con el nombre devuelto.

La fase finalize conserva el hash del CSR, el resultado y el tipo de problema ACME. Si hay emisión, la huella y las propiedades analizadas del certificado documentan el producto firmado. Si interesa la instalación, una observación del servicio con hora, punto de vista y huella demuestra el despliegue.

Ninguna pieza sustituye a la siguiente. El Directory no concede un derecho; el Order no es un certificado; el certificado no demuestra que un servicio lo presente. Mantenerlas separadas permite aprovechar el nuevo campo sin atribuirle una promesa que nunca hizo.

Fuentes

  1. Estado actual de ACME Profiles
  2. Historial del documento
  3. Texto de draft-ietf-acme-profiles-02
  4. Solicitud de publicación
  5. Informe del document shepherd
  6. RFC 8555
  7. Documentación de perfiles de Let’s Encrypt
  8. Anuncio de ACME Profiles
  9. Hoja de ruta de duración de certificados
  10. Anuncio de la última llamada del grupo
  11. Cierre de la última llamada
  12. Seguimiento de implementación de Boulder
  13. Actas de ACME en IETF 126