Uso de clave recomendado para un certificado de cliente

6

Mi programa tiene el siguiente flujo: un cliente envía una CSR al servidor, el servidor devuelve un certificado de cliente y, a continuación, el cliente se comunica con el servidor a una ruta que requiere un certificado firmado por el servidor (el certificado del cliente)

Mis preguntas son:

  1. He establecido el uso de la clave extendida de clientAuth en el certificado de cliente generado. ¿Debo agregar cualquier uso clave adicional? Tal vez "digitalSignature" KU?

  2. ¿Qué significa el uso de la clave "firma digital"? Lo he leído todo lo que puedo, pero aún no estoy seguro de si es aplicable a mí (la mejor fuente de información que pude encontrar hasta ahora fue this ).

  3. ¿Cuál es el significado práctico de agregar este uso clave? (¿Qué acciones se evitarán con los clientes / servidores SSL con buen comportamiento?) ¿A diferencia de no especificar ningún uso clave? (solo el EKU del cliente)

pregunta yair 28.09.2014 - 15:12
fuente

2 respuestas

7

TL-DR El certificado de cliente SSL no necesita KeyUsage, pero si está presente, debe ser digitalSignature, excepto por el caso de * DH.

Advertencia: etiquetó SSL, por lo que supongo que por "ruta que requiere un certificado" quiere decir SSL / TLS o algo sobre SSL / TLS (no necesariamente HTTP / S). Si quieres decir algo más como CMS o S / MIME, XML-sig o incluso PGP, la respuesta puede ser diferente.

Me sorprende que no encuentre otras referencias ya que los certificados X.509 son tan ampliamente utilizados. Mi primera página de Google X.509 extensión de uso de la clave da PKIX rfc5280 que es el Internet actualmente efectivo spec y (la forma de texto de) su predecesor rfc3280 ; El artículo de wikipedia no muy bueno; y enlace que tiene (posiblemente sobre-) específico Instrucciones para varios casos incluyendo cliente SSL. Citando la parte relevante de 5280 (que su sitio de IBM más o menos copias):

   Bits in the KeyUsage type are used as follows:

      The digitalSignature bit is asserted when the subject public key
      is used for verifying digital signatures, other than signatures on
      certificates (bit 5) and CRLs (bit 6), such as those used in an
      entity authentication service, a data origin authentication
      service, and/or an integrity service.

      The nonRepudiation bit is asserted when the subject public key is
      used to verify digital signatures, other than signatures on
      certificates (bit 5) and CRLs (bit 6), used to provide a non-
      repudiation service that protects against the signing entity
      falsely denying some action.  In the case of later conflict, a
      reliable third party may determine the authenticity of the signed
      data.  (Note that recent editions of X.509 have renamed the
      nonRepudiation bit to contentCommitment.)

      The keyEncipherment bit is asserted when the subject public key is
      used for enciphering private or secret keys, i.e., for key
      transport.  For example, this bit shall be set when an RSA public
      key is to be used for encrypting a symmetric content-decryption
      key or an asymmetric private key.

      The dataEncipherment bit is asserted when the subject public key
      is used for directly enciphering raw user data without the use of
      an intermediate symmetric cipher.  Note that the use of this bit
      is extremely uncommon; almost all applications use key transport
      or key agreement to establish a symmetric key.


      The keyAgreement bit is asserted when the subject public key is
      used for key agreement.  For example, when a Diffie-Hellman key is
      to be used for key management, then this bit is set.

      The keyCertSign bit is asserted when the subject public key is
      used for verifying signatures on public key certificates.  If the
      keyCertSign bit is asserted, then the cA bit in the basic
      constraints extension (Section 4.2.1.9) MUST also be asserted.

      The cRLSign bit is asserted when the subject public key is used
      for verifying signatures on certificate revocation lists (e.g.,
      CRLs, delta CRLs, or ARLs).

      The meaning of the encipherOnly bit is undefined in the absence of
      the keyAgreement bit.  When the encipherOnly bit is asserted and
      the keyAgreement bit is also set, the subject public key may be
      used only for enciphering data while performing key agreement.

      The meaning of the decipherOnly bit is undefined in the absence of
      the keyAgreement bit.  When the decipherOnly bit is asserted and
      the keyAgreement bit is also set, the subject public key may be
      used only for deciphering data while performing key agreement.

Esto es necesariamente algo general porque los certificados X.509 (y PKIX) fueron diseñados para ser utilizados para una variedad de cosas, no solo SSL / TLS, aunque ese es el único uso que la mayoría de la gente conoce. Distingue varios tipos de firma, cifrado y acuerdo de clave (que en la práctica se utiliza para el cifrado).

5280/3280 solo obliga a KeyUsage para certificados CA, implícitamente dejándolo opcional para certificados EE. No tengo X.509 real pero AFAIU dice que si KeyUsage no está presente, se trata como un conjunto de bits, ya que es compatible con v1 y v2 antes de que hubiera extensiones. CABforum baseline lo especifica explícitamente como se requiere para certificados CA pero opcional para certificados de "suscriptor" (es decir, EE).

TLSv1.2 (o sus predecesores) requiere un certificado de cliente "Permitir ... firma "excepto para los intercambios de claves fijo-DH y fijo-ECDH que nadie parece usar al menos en la red pública, y las secciones relacionadas explican cómo, excepto para fijo- * DH, la clave del cliente en realidad se usa solo para firmar los datos del protocolo de enlace Para demostrar la posesión por y así autenticar al cliente. Esto significa que si KeyUsage está presente para el cliente SSL, debe incluir digitalSignature, y dado que, en general, una clave criptográfica no debe usarse para múltiples propósitos sin una fuerte justificación, KeyUsage para el cliente SSL no debe incluir nada más. Si el certificado de cliente no tiene KeyUsage o tiene un KeyUsage no restrictivo, una implementación de SSL / TLS conforme seguirá utilizando esa clave y certificado solo de la manera especificada por el protocolo, que excepto el archivo * fijo como * señalado solo está firmando / Verificación de datos que no sean un certificado o CRL.

    
respondido por el dave_thompson_085 28.09.2014 - 21:48
fuente
5

Aquí una respuesta para libNSS:

Para libNSS utilizado por Mozilla Firefox, la respuesta está oculta dentro de ./certdb/certdb.c:

Cuando actualmente está comprobando el uso:

  case certUsageSSLClient:
    /* 
     * RFC 5280 lists digitalSignature and keyAgreement for
     * id-kp-clientAuth.  NSS does not support the *_fixed_dh and
     * *_fixed_ecdh client certificate types.
     */
    requiredKeyUsage = KU_DIGITAL_SIGNATURE;
    requiredCertType = NS_CERT_TYPE_SSL_CLIENT;

Si la extensión KeyUsage no está establecida, entonces se comporta como si estuviera completamente establecida:

/* if the extension is not present, then we allow all uses */
cert->keyUsage = KU_ALL;

si se establece entonces, bueno, está configurado

    if (keyUsage & PKIX_DIGITAL_SIGNATURE){
            nssKeyUsage = nssKeyUsage | KU_DIGITAL_SIGNATURE;
    }

El tipo de certificado NSS debería tener el conjunto NS_CERT_TYPE_SSL_CLIENT. CertType se deriva de EKU:

si no hay EKU, entonces NS_CERT_TYPE_SSL_CLIENT está establecido.

/* If no NS Cert Type extension and no EKU extension, then */
nsCertType = 0;
...
/* allow any ssl or email (no ca or object signing. */
nsCertType |= NS_CERT_TYPE_SSL_CLIENT | NS_CERT_TYPE_SSL_SERVER |
              NS_CERT_TYPE_EMAIL;

Si hay EKU, entonces NS_CERT_TYPE_SSL_CLIENT se establece SOLAMENTE si no es una CA.

if (findOIDinOIDSeqByTagNum(extKeyUsage,
                SEC_OID_EXT_KEY_USAGE_CLIENT_AUTH) ==
    SECSuccess){
    if (basicConstraintPresent == PR_TRUE &&
    (basicConstraint.isCA)) {
    nsCertType |= NS_CERT_TYPE_SSL_CA;
    } else {
    nsCertType |= NS_CERT_TYPE_SSL_CLIENT;
    }
}

Por lo tanto, en la práctica para libNSS (como se obtuvo en el repositorio mercurial enlace el 25 de octubre de 2015) como certificado de cliente válido, debe coincidir con una de esas afirmaciones:

  • EKU Y KU NO están configurados.
  • KU no está establecido Y EKU está establecido en clientAuth Y cert no es una CA.
  • KU contiene digitalSignature Y EKU NO está configurado
  • KU contiene digitalSignature AND EKU se establece en clientAuth Y cert no es una CA.
respondido por el philippe lhardy 21.10.2015 - 21:56
fuente

Lea otras preguntas en las etiquetas