RE: [openssl-users] How does openSSL handle the pathlen constraint?
-Original Message- From: Erwann Abalea Bonjour, Le 21/05/2012 14:10, Serge Emantayev a écrit : Hello openSSL gurus, I faced an issue of pathlen constraint checking by openSSL when verifying the client certificate. I did few studies for how openSSL does that and I appreciate your assistance on clarifying the issue. 1. The certificate chain with a pathlen constraint defined in a root CA: Root CA, pathlen:1 \ policy CA, pathlen:none \ issuer CA, pathlen:none \ client certificate In the first case openSSL does not verify the certificate correctly (i.e. the verification succeeds). It ignores the pathlen constraint defined in the root CA. This is conformant with X.509. The basicConstraints extension is not taken in consideration if present in a trust anchor (a root certificate is a trust anchor). Download X.509 recommendation, see chapter 10 (from memory), the validation algorithm is described. Actually, I find this hard to believe. The verifying party can deem any certificate as trusted and thereby making it its trust anchor. Nevertheless the verification process needs to take into account the extensions of the trust anchor and I don't see any reason to exclude basicConstraints. Can you please cite the relevant part of the validation algorithm that you reference? Patrick Eisenacher __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] How does openSSL handle the pathlen constraint?
Le 22/05/2012 10:57, Eisenacher, Patrick a écrit : -Original Message- From: Erwann Abalea Bonjour, Le 21/05/2012 14:10, Serge Emantayev a écrit : Hello openSSL gurus, I faced an issue of pathlen constraint checking by openSSL when verifying the client certificate. I did few studies for how openSSL does that and I appreciate your assistance on clarifying the issue. 1. The certificate chain with a pathlen constraint defined in a root CA: Root CA, pathlen:1 \ policy CA, pathlen:none \ issuer CA, pathlen:none \ client certificate In the first case openSSL does not verify the certificate correctly (i.e. the verification succeeds). It ignores the pathlen constraint defined in the root CA. This is conformant with X.509. The basicConstraints extension is not taken in consideration if present in a trust anchor (a root certificate is a trust anchor). Download X.509 recommendation, see chapter 10 (from memory), the validation algorithm is described. Actually, I find this hard to believe. The verifying party can deem any certificate as trusted and thereby making it its trust anchor. Nevertheless the verification process needs to take into account the extensions of the trust anchor and I don't see any reason to exclude basicConstraints. Can you please cite the relevant part of the validation algorithm that you reference? Taken from X.509, 2008/11 edition. But IIRC, the algorithm is the same since the 2000 edition, at least. - 10.5 Certificate processing Each certificate is then processed in turn, starting with the certificate signed using the input trusted public key. The last certificate is considered to be the end certificate; any other certificates are considered to be intermediate certificates. - Note that the first certificate taken into consideration is signed by the trust anchor, and not the trust anchor itself. - 10.5.1 Basic certificate checks The following checks are applied to a certificate. Self-signed certificates, if encountered in the path, are ignored. a) Check that the signature verifies, that dates are valid, that the certificate subject and certificate issuer names chain correctly, and that the certificate has not been revoked. b) For an intermediate version 3 certificate, check that basicConstraints is present and that the cA component in the basicConstraints extension is TRUE. If the pathLenConstraint component is present, check that the current certification path does not violate that constraint (ignoring intermediate self-issued certificates) [...other basic steps...] - The same logic applies for other constraints extensions. Basically, from the trust anchor, you only take the public key, name, and validity dates. No extension at all. That's because a trust anchor doesn't need to be a certificate at all. -- Erwann ABALEA - OF C'est quoi godwin ? un jeu ? une personne ? Une sorte de station-service : on accumule les points et on peut gagnerune gamelle. -+- PE in Guide du Neuneu d'Usenet - Le point sur les godwins -+- __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: [openssl-users] How does openSSL handle the pathlen constraint?
-Original Message- From: Erwann Abalea Le 22/05/2012 10:57, Eisenacher, Patrick a écrit : -Original Message- From: Erwann Abalea Bonjour, Le 21/05/2012 14:10, Serge Emantayev a écrit : Hello openSSL gurus, I faced an issue of pathlen constraint checking by openSSL when verifying the client certificate. I did few studies for how openSSL does that and I appreciate your assistance on clarifying the issue. 1. The certificate chain with a pathlen constraint defined in a root CA: Root CA, pathlen:1 \ policy CA, pathlen:none \ issuer CA, pathlen:none \ client certificate In the first case openSSL does not verify the certificate correctly (i.e. the verification succeeds). It ignores the pathlen constraint defined in the root CA. This is conformant with X.509. The basicConstraints extension is not taken in consideration if present in a trust anchor (a root certificate is a trust anchor). Download X.509 recommendation, see chapter 10 (from memory), the validation algorithm is described. Actually, I find this hard to believe. The verifying party can deem any certificate as trusted and thereby making it its trust anchor. Nevertheless the verification process needs to take into account the extensions of the trust anchor and I don't see any reason to exclude basicConstraints. Can you please cite the relevant part of the validation algorithm that you reference? Taken from X.509, 2008/11 edition. But IIRC, the algorithm is the same since the 2000 edition, at least. - 10.5 Certificate processing Each certificate is then processed in turn, starting with the certificate signed using the input trusted public key. The last certificate is considered to be the end certificate; any other certificates are considered to be intermediate certificates. - Note that the first certificate taken into consideration is signed by the trust anchor, and not the trust anchor itself. - 10.5.1 Basic certificate checks The following checks are applied to a certificate. Self-signed certificates, if encountered in the path, are ignored. a) Check that the signature verifies, that dates are valid, that the certificate subject and certificate issuer names chain correctly, and that the certificate has not been revoked. b) For an intermediate version 3 certificate, check that basicConstraints is present and that the cA component in the basicConstraints extension is TRUE. If the pathLenConstraint component is present, check that the current certification path does not violate that constraint (ignoring intermediate self-issued certificates) [...other basic steps...] - The same logic applies for other constraints extensions. Basically, from the trust anchor, you only take the public key, name, and validity dates. No extension at all. That's because a trust anchor doesn't need to be a certificate at all. Hi Erwann, I guess it's time to re-read in-depth the lengthy chapter on certification path validation of RFC 5280 and pay special attention to trust anchors in form of self signed and non-self signed certificates :o) Thanks for clarification, Patrick Eisenacher __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
How does openSSL handle the pathlen constraint?
Hello openSSL gurus, I faced an issue of pathlen constraint checking by openSSL when verifying the client certificate. I did few studies for how openSSL does that and I appreciate your assistance on clarifying the issue. 1. The certificate chain with a pathlen constraint defined in a root CA: Root CA, pathlen:1 \ policy CA, pathlen:none \ issuer CA, pathlen:none \ client certificate In the first case openSSL does not verify the certificate correctly (i.e. the verification succeeds). It ignores the pathlen constraint defined in the root CA. 2. The certificate chain with a pathlen constraint defined in an intermediate CA: Root CA, pathlen:none \ policy CA, pathlen:0 \ issuer CA, pathlen:0 \ client certificate In the last case openSSL does correct verification (i.e. fails the client certificate) only when I define the intermediate CAs as untrusted. Is that supposed way the pathlen constraint works? Is it allowed to define the pathlen constraint in the root CA? I'm using openSSL 0.9.8r. Many thanks, Sergey Emantayev __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] How does openSSL handle the pathlen constraint?
Bonjour, Le 21/05/2012 14:10, Serge Emantayev a écrit : Hello openSSL gurus, I faced an issue of pathlen constraint checking by openSSL when verifying the client certificate. I did few studies for how openSSL does that and I appreciate your assistance on clarifying the issue. 1. The certificate chain with a pathlen constraint defined in a root CA: Root CA, pathlen:1 \ policy CA, pathlen:none \ issuer CA, pathlen:none \ client certificate In the first case openSSL does not verify the certificate correctly (i.e. the verification succeeds). It ignores the pathlen constraint defined in the root CA. This is conformant with X.509. The basicConstraints extension is not taken in consideration if present in a trust anchor (a root certificate is a trust anchor). Download X.509 recommendation, see chapter 10 (from memory), the validation algorithm is described. -- Erwann ABALEA - Ce ne sont que des propositions. Je ne veux pas les faire passer en force. Je pense que si mes idées doivent être reprises, elles ne doivent pas passer au vote, pour plusieurs raison : -+- BC in : http://neuneu.ctw.cc - Neuneu sans vote et sans forcer -+- __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
