Compartir a través de

Semántica de la lista de revocación de certificados (CRL) de Crypt32

  • Artículo

Crypt32 admite la semántica de la lista de revocación de certificados (CRL) para la comprobación de revocación en línea. En este artículo se proporciona información sobre cómo Crypt32 usa CRL para la comprobación de revocación en línea y cómo se puede usar la captura previa y la creación de particiones de CRL para mejorar el rendimiento.

Introducción

Cuando se llama a la API CertGetCertificateChain de Crypt32 con la revocación en línea habilitada, intentará recuperar una respuesta OCSP válida de hora o CRL de la siguiente manera:

  • Compruebe si se incluyó una respuesta OCSP de tiempo válida en el protocolo de enlace.
  • Compruebe si tenemos una respuesta OCSP o CRL válida en la caché de direcciones URL de Cryptnet del usuario.
  • Compruebe si tenemos una CRL válida de tiempo en un almacén del sistema, como HKLM\CA.
  • En el caso de la dirección URL de OCSP en la extensión AIA del certificado del firmante, intente descargar la respuesta OCSP del servidor OCSP.
    • Para que se complete correctamente, agregue la respuesta OCSP a la caché de direcciones URL de Cryptnet del usuario.
  • Para la extensión CDP de CRL en el certificado del firmante, intente descargar la CRL del servidor CRL de la entidad de certificación (CA).
    • Para que se complete correctamente, agregue la CRL a la caché de direcciones URL de Cryptnet del usuario.

Para una CRL agregada a la caché de direcciones URL de Cryptnet, la siguiente CRL se recuperará antes de que expire si la CRL tiene la siguiente extensión: "1.3.6.1.4.1.311.21.4" (Siguiente publicación crL). Al agregar esta extensión, solo se realizará la descarga de CRL inicial durante la validación del certificado. Consulte la sección Captura previa de CRL para obtener más información sobre cómo Crypt32 usa esta extensión para capturar previamente la siguiente CRL.

Si una ENTIDAD de certificación emite un gran volumen de certificados, el número de entradas revocadas en una CRL también podría ser grande, aumentando el tamaño de la CRL. Para mantener el tamaño de la CRL en la comprobación, Microsoft recomienda y admite la creación de particiones CRL a través de la extensión "2.5.29.28" (Punto de distribución emisora) agregada a la CRL descargada. Consulte la sección Creación de particiones de CRL para obtener más información sobre cómo Crypt32 admite la creación de particiones CRL a través de esta extensión.

Ca está considerando quitar la compatibilidad con OCSP y solo es necesario tener en cuenta el impacto que esto tendrá en las aplicaciones que llaman a certGetCertificateChain API con la revocación en línea habilitada:

  • En la primera validación, la aplicación que realiza la llamada realizará una descarga crL a petición y impedirá que la API se complete hasta que se descargue la CRL.
    • En el caso de los servidores TLS de gran volumen, habrá descargas de gran volumen correspondientes desde el servidor CRL de la ENTIDAD de certificación.
    • Si la CRL se vuelve grande, tendrá un impacto directo en el servidor que puede controlar un gran volumen de descargas.
      • El tamaño de la CRL puede limitarse admitiendo las CRL con particiones.
  • Las validaciones posteriores usarán la CRL almacenada en caché hasta que expire la CRL. Cuando expire la CRL, se repetirá lo anterior para la siguiente validación.
    • Esta descarga de CRL a petición se puede evitar agregando la extensión Next CRL Publish.

En las secciones siguientes se proporciona información sobre la captura previa de CRL y la creación de particiones para mejorar el rendimiento de la revocación en línea donde solo se usan las CRL.

Captura previa de CRL

Una CRL codificada tiene los dos campos siguientes que indican cuándo se publicó la CRL y cuánto tiempo puede almacenar en caché el cliente antes de necesitar recuperar la siguiente CRL publicada.

ThisUpdate    GeneralizedTime,
NextUpdate    GeneralizedTime OPTIONAL,

Si falta NextUpdate , esta es la última CRL que se publicará y nunca expirará.

Una CRL puede contener la extensión "1.3.6.1.4.1.311.21.4" (Siguiente publicación crL), que también se codifica como GeneralizedTime. Cuando esta extensión está presente, Crypt32 intentará capturar previamente la siguiente CRL publicada después de publishTime y antes de NextUpdate como se indica a continuación:

Dado, PublishPeriod = NextUpdate – PublishTime. Los tres parámetros de configuración siguientes se usan para determinar el inicio y el final de PreFetchPeriod:

  • AfterPublishPreFetchDivisor
    • El inicio de PreFetchPeriod se retrasa después de PublishTime dividiendo publishPeriod por este divisor.
    • Valor predeterminado de 10
  • BeforeNextUpdatePreFetchDivisor
    • El final de PreFetchPeriod se produce antes de NextUpdate dividiendo publishPeriod por este divisor.
    • Valor predeterminado de 20
  • MinPreFetchPeriod
    • Dado, PreFetchPeriod = PreFetchPeriodFinishTime – PreFetchPeriodStartTime. La captura previa solo está habilitada si PreFetchPeriod supera este mínimo.
    • Valor predeterminado de 1 hora

Dado el prefetchPeriod calculado anterior, se selecciona una hora aleatoria dentro de este PreFetchPeriod para cada cliente para capturar previamente y descargar la CRL publicada desde el servidor.

Algunas veces de ejemplo y preFetchPeriod correspondientes con los valores de configuración predeterminados.

CRL es válido durante dos días y se publica cada día:

ThisUpdate:  Nov 05 08:00 
NextUpdate:  Nov 07 08:00 
PublishTime: Nov 06 08:00 

PublishPeriod = 24 hours 
PreFetchPeriodStartTime  = PublishTime + 24/10 (2.4 hours) 
PreFetchPeriodFinishTime = NextUpdate – 24/20 (1.2 hours) 

PreFetchPeriod = Nov 06 10:24 .. Nov 07 06:48 = 20:24  

Clients would randomly pre-fetch in the above PreFetchPeriod.

CRL es válido durante ocho días y se publica cada cuatro días:

ThisUpdate:  Nov 03 08:00 
NextUpdate:  Nov 11 08:00 
PublishTime: Nov 07 08:00 

PublishPeriod = 96 hours 
PreFetchPeriodStartTime  = PublishTime + 96/10 (9.6 hours) 
PreFetchPeriodFinishTime = NextUpdate – 96/20 (4.8 hours) 

PreFetchPeriod = Nov 07 17:36 .. Nov 11 03:12 = 81:36 

Clients would randomly pre-fetch in the above PreFetchPeriod

Nota:

Si el cliente no usa la CRL capturada previamente, la captura previa anterior se detendrá hasta que el cliente inicie una nueva descarga a petición para esta CRL.

Creación de particiones crL

En esta sección se proporciona información sobre cómo Crypt32 admite la creación de particiones CRL.

Ejemplo

A continuación se muestra un ejemplo de una extensión CDP y proveedor de identidades (IDP) con formato común que se usa para la creación de particiones CRL.

Para la primera partición de certificados emitidos desde la ENTIDAD de certificación:

Cert CDP:
[1]CRL Distribution Point
     Distribution Point Name:
          Full Name:
               URL=http://crl.godaddy.com/first.crl

CRL IDP:
Distribution Point Name:
     Full Name:
               URL=http://crl.godaddy.com/first.crl
Only Contains User Certs=No
Only Contains CA Certs=No
Indirect CRL=No

Para la segunda partición de certificados emitidos desde la ENTIDAD de certificación, apunta a una CRL diferente en el CDP e IDP:

Cert CDP:
[1]CRL Distribution Point
     Distribution Point Name:
          Full Name:
               URL=http://crl.godaddy.com/second.crl

CRL IDP:
Distribution Point Name:
     Full Name:
               URL=http://crl.godaddy.com/second.crl
Only Contains User Certs=No
Only Contains CA Certs=No
Indirect CRL=No

Como puede ver, se usa la misma dirección URL DE CRL http única en el CDP e IDP. Además, las CRL con particiones están firmadas directamente por la ENTIDAD de certificación y son aplicables tanto a ENTIDADES de certificación como a certificados de usuario final.

En la sección siguiente se proporcionan detalles sobre la codificación ASN.1 de las extensiones IDP y CDP y lo que es compatible con Crypt32.

Detalles

Este es el ASN.1 para la extensión punto de distribución emisor (IDP) ("2.5.29.28"):

--------------------------------------------
-- CRL Issuing Distribution Point Extension
--------------------------------------------
IssuingDistributionPoint ::= SEQUENCE {
    issuingDistributionPoint    [0] EXPLICIT DistributionPointName OPTIONAL,
    onlyContainsUserCerts       [1] IMPLICIT BOOLEAN DEFAULT FALSE,
    onlyContainsCACerts         [2] IMPLICIT BOOLEAN DEFAULT FALSE,
    onlySomeReasons             [3] IMPLICIT ReasonFlags OPTIONAL,
    indirectCRL                 [4] IMPLICIT BOOLEAN DEFAULT FALSE
} --#public—

DistributionPointName ::= CHOICE {
    fullName                [0] IMPLICIT GeneralNames,
    nameRelativeToCRLIssuer [1] IMPLICIT RelativeDistinguishedName
}

GeneralNames ::= SEQUENCE OF GeneralName

GeneralName ::= CHOICE {
    otherName               [0] IMPLICIT OtherName,
    rfc822Name              [1] IMPLICIT IA5STRING,
    dNSName                 [2] IMPLICIT IA5STRING,
    x400Address             [3] IMPLICIT SeqOfAny,
    directoryName           [4] EXPLICIT NOCOPYANY,    -- really Name
    ediPartyName            [5] IMPLICIT SeqOfAny,
    uniformResourceLocator  [6] IMPLICIT IA5STRING,
    iPAddress               [7] IMPLICIT OCTETSTRING,
    registeredID            [8] IMPLICIT EncodedObjectID
}

Si una CRL tiene un IDP, el cliente de Windows continuará de la siguiente manera:

  • Ignore los IDP que tienen:
    • onlySomeReasons
    • indirectCRL
  • Solo admite IDP con la opción fullName .
    • El CDP de CRL también debe tener la opción fullName.
  • Si onlyContainsUserCerts o onlyContainsCACerts:
    • Use la extensión de restricciones básicas del certificado para determinar si el IDP es aplicable al certificado.

Este es el ASN.1 para la extensión CDP en un certificado:

--------------------------------------------
-- CRL Distribution Points Extension
--------------------------------------------
CRLDistributionPoints ::= SEQUENCE OF DistributionPoint

DistributionPoint ::= SEQUENCE {
    distributionPoint       [0] EXPLICIT DistributionPointName OPTIONAL,
    reasons                 [1] IMPLICIT ReasonFlags OPTIONAL,
    cRLIssuer               [2] IMPLICIT GeneralNames OPTIONAL
}

DistributionPointName see above

Un cliente de Windows hará lo siguiente:

  • Recorra en iteración la secuencia del IDP de GeneralNames hasta que coincida con un nombre de CDP:
    • Recorrer en iteración la secuencia de puntos de distribución de CDP:
      • Omita el punto de distribución de CDP que tiene:
        • Razones
        • cRLIssuer
      • Omita CDP DistributionPoint si no tiene una opción fullName para DistributionPointName.
      • Recorrer en iteración la secuencia de GeneralNames del CDP:
        • Compruebe si IDP y CDP GeneralName coinciden
          • Si IsSameGeneralName(), tenemos una coincidencia y la CRL se puede usar para el certificado de sujeto.

IsSameGeneralName(IDP_GeneralName, CDP_GeneralName)

El IDP y CDP deben tener la misma opción GeneralName . Para la misma elección, compare el nombre de IDP y CDP según la elección:

  • rfc822Name
    • Comparación de cadenas que no distingue mayúsculas de minúsculas. No hay normalización de caracteres %.
  • dNSName
    • Comparación de cadenas que no distingue mayúsculas de minúsculas. No hay normalización de caracteres %.
  • uniformResourceLocator (URL)
    • Comparación de cadenas que no distingue mayúsculas de minúsculas. No hay normalización de caracteres %.
  • otherName
    • Se comparan el valor binario específico de OID y OID.
  • registeredID
    • Se comparan los OID.
  • directoryName
    • Se comparan los bytes de nombre codificados.
  • iPAddress
    • Se comparan los bytes OCTET codificados.
  • x400Address
    • No admitida.
  • ediPartyName
    • No admitida.

La expectativa es que se usará la opción uniformResourceLocator GeneralName .

Contenido relacionado

CertGetCertificateChain

CertGetCRLContextProperty

Funciones de criptografía