Re: Multiple CRL with same issuer
PS a écrit : Hi All, I was under the impression that openssl allows loading multiple CRLs for the same issuer. But, this does not seem to be the case as is proved by using openssl verify. $ ls -l ./ca/ total 24 lrwxrwxrwx 1 pshah users 10 Jan 28 21:56 ba4bb3b6.0 - cacert.pem - the CA cert lrwxrwxrwx 1 pshah users 14 Jan 28 21:56 ba4bb3b6.r0 - revoked_48.pem revokes only cert48.pem lrwxrwxrwx 1 pshah users 14 Jan 28 21:56 ba4bb3b6.r1 - revoked_49.pem - revokes only cert49.pem -rw-r--r-- 1 pshah users 1233 Jan 28 17:09 cacert.pem -rw-r--r-- 1 pshah users 560 Jan 28 17:10 revoked_48.pem -rw-r--r-- 1 pshah users 560 Jan 28 17:10 revoked_49.pem $ openssl verify -CApath ./ca/ -crl_check -verbose cert49.pem cert49.pem: OK $ openssl verify -CApath ./ca/ -crl_check -verbose cert48.pem cert48.pem: /C=--/ST=California/L=San Francisco/O=Riverbed Technology, Inc./OU=Steelhead/CN=hw1-sh18/emailaddress=fakeem...@example.com mailto:fakeem...@example.com error 23 at 0 depth lookup:certificate revoked 29615:error:0B07D065:x509 certificate routines:X509_STORE_add_crl:cert already in hash table:x509_lu.c:418: A CRL ( Certificat revocation list) is the list of ALL the revoked certificates at the time it is issued So if at time t1 a certificate 48 is revoked then all the subsequent CRLs MUST indicate that the certificate 48 as revoked If later at time t2 the certificate 49 is revoked hen all the subsequent CRLs MUST indicate that both certificate 48 and certificate 49 arte revoked Thus only the lasT CRL has to considered . Since the delivery times of the CRLs are close together it is not easy to check into the example which is ithe last CRL So, as seen above, the second CRL is not loaded (and I have confirmed this with gdb.). A second related question is that even if openssl allowed loading multiple CRL for the same issuer, it looks as if openssl will only use the first unexpired CRL from the list. There might be cases where you would have a fresher unexpired CRL which might not get picked and result in wrong verification result. If a CRL is expired this means that a new CRL should have been delivered and you have not received it. To avoid dangerous forbidden access every access should be forbidden. To take into account unexpected urgent problem a new CRL may be issued even when the previous one is not expired. I hope this help. Dominique LOHEZ A third question is that what if I had two valid CRLs from the same issuer (CRL1 revoked cert 1 and CRL2 revokes cert 2), then when cert 2 is to be verified, it would wrongly be considered unrevoked. Thanks, Paras -- Dr Dominique LOHEZ ISEN 41, Bd Vauban F59046 LILLE France Phone : +33 (0)3 20 30 40 71 Email: dominique.lo...@isen.fr __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Multiple CRL with same issuer
I was under the impression that openssl allows loading multiple CRLs for the same issuer. But, this does not seem to be the case as is proved by using openssl verify. $ ls -l ./ca/ total 24 lrwxrwxrwx 1 pshah users 10 Jan 28 21:56 ba4bb3b6.0 - cacert.pem - the CA cert lrwxrwxrwx 1 pshah users 14 Jan 28 21:56 ba4bb3b6.r0 - revoked_48.pem revokes only cert48.pem lrwxrwxrwx 1 pshah users 14 Jan 28 21:56 ba4bb3b6.r1 - revoked_49.pem - revokes only cert49.pem -rw-r--r-- 1 pshah users 1233 Jan 28 17:09 cacert.pem -rw-r--r-- 1 pshah users 560 Jan 28 17:10 revoked_48.pem -rw-r--r-- 1 pshah users 560 Jan 28 17:10 revoked_49.pem $ openssl verify -CApath ./ca/ -crl_check -verbose cert49.pem cert49.pem: OK $ openssl verify -CApath ./ca/ -crl_check -verbose cert48.pem cert48.pem: /C=--/ST=California/L=San Francisco/O=Riverbed Technology, Inc./OU=Steelhead/CN=hw1-sh18/emailaddress=fakeem...@example.com mailto:fakeem...@example.com error 23 at 0 depth lookup:certificate revoked 29615:error:0B07D065:x509 certificate routines:X509_STORE_add_crl:cert already in hash table:x509_lu.c:418: A CRL ( Certificat revocation list) is the list of ALL the revoked certificates at the time it is issued So if at time t1 a certificate 48 is revoked then all the subsequent CRLs MUST indicate that the certificate 48 as revoked If later at time t2 the certificate 49 is revoked hen all the subsequent CRLs MUST indicate that both certificate 48 and certificate 49 arte revoked Thus only the lasT CRL has to considered . Since the delivery times of the CRLs are close together it is not easy to check into the example which is ithe last CRL i think you misunderstood the question. the issue at hand is not about older and latest copies of a particular (certificate revocation) list, but it is about two *distinct* simultaneously valid and active (certificate revocation) lists that are issued/maintained by the same issuer. http://tools.ietf.org/html/rfc5280#section-5 Each CRL has a particular scope. The CRL scope is the set of certificates that could appear on a given CRL. For example, the scope could be all certificates issued by CA X, all CA certificates issued by CA X, all certificates issued by CA X that have been revoked for reasons of key compromise and CA compromise, or a set of certificates based on arbitrary local information, such as all certificates issued to the NIST employees located in Boulder. _ Hotmail® goes where you go. On a PC, on the Web, on your phone. http://www.windowslive-hotmail.com/learnmore/versatility.aspx#mobile?ocid=TXT_TAGHM_WL_HM_versatility_121208
Re: Multiple CRL with same issuer
I think you're trying to assume something that cannot be assumed: you assume that ALL unexpired CRLs are considered. This is not the case. As Dominiqué said, only the CRL that has the latest signature time is considered. This is evident in the name of the file type: Certificate Revocation *List*. It is legal to issue a CRL that revokes a certificate (possibly with an type of onhold, for V3 CRLs) with an expiration time of 2 years in the future, and the next hour the to remove the revocation status. If all simultaneously-valid CRLs are considered, then the intended consequence of unrevoking the certificate would be impossible. This is why the CRL must contain the *complete* list of *all* revoked certificates which have not yet expired. There is a PKIX extension, delta CRLs, which defines for V3 CRLs a way to allow for adding to the list of the most-recently-issued full CRL. In order to support unrevocation, there is a special status type (called remove_from_crl) for the delta CRL which is to be interpreted as removing the certificate from the revocation list; however, in a full V3 CRL, that status type is illegal. And in V2 CRLs (the default, since many implementations do not handle V3 CRLs) there is no means of specifying the extension that contains a status type regardless. This is specified in PKIX (currently RFC 5280); in order to maintain standards-conformance OpenSSL cannot change this behavior. (Nor can it even offer an option to change it, since its job is to maintain security-system interoperability, not capriciously make it less secure.) -Kyle H 2009/1/29 Giang Nguyen cau...@hotmail.com: I was under the impression that openssl allows loading multiple CRLs for the same issuer. But, this does not seem to be the case as is proved by using openssl verify. $ ls -l ./ca/ total 24 lrwxrwxrwx 1 pshah users 10 Jan 28 21:56 ba4bb3b6.0 - cacert.pem - the CA cert lrwxrwxrwx 1 pshah users 14 Jan 28 21:56 ba4bb3b6.r0 - revoked_48.pem revokes only cert48.pem lrwxrwxrwx 1 pshah users 14 Jan 28 21:56 ba4bb3b6.r1 - revoked_49.pem - revokes only cert49.pem -rw-r--r-- 1 pshah users 1233 Jan 28 17:09 cacert.pem -rw-r--r-- 1 pshah users 560 Jan 28 17:10 revoked_48.pem -rw-r--r-- 1 pshah users 560 Jan 28 17:10 revoked_49.pem $ openssl verify -CApath ./ca/ -crl_check -verbose cert49.pem cert49.pem: OK $ openssl verify -CApath ./ca/ -crl_check -verbose cert48.pem cert48.pem: /C=--/ST=California/L=San Francisco/O=Riverbed Technology, Inc./OU=Steelhead/CN=hw1-sh18/emailaddress=fakeem...@example.com mailto:fakeem...@example.com error 23 at 0 depth lookup:certificate revoked 29615:error:0B07D065:x509 certificate routines:X509_STORE_add_crl:cert already in hash table:x509_lu.c:418: A CRL ( Certificat revocation list) is the list of ALL the revoked certificates at the time it is issued So if at time t1 a certificate 48 is revoked then all the subsequent CRLs MUST indicate that the certificate 48 as revoked If later at time t2 the certificate 49 is revoked hen all the subsequent CRLs MUST indicate that both certificate 48 and certificate 49 arte revoked Thus only the lasT CRL has to considered . Since the delivery times of the CRLs are close together it is not easy to check into the example which is ithe last CRL i think you misunderstood the question. the issue at hand is not about older and latest copies of a particular (certificate revocation) list, but it is about two *distinct* simultaneously valid and active (certificate revocation) lists that are issued/maintained by the same issuer. http://tools.ietf.org/html/rfc5280#section-5 Each CRL has a particular scope. The CRL scope is the set of certificates that could appear on a given CRL. For example, the scope could be all certificates issued by CA X, all CA certificates issued by CA X, all certificates issued by CA X that have been revoked for reasons of key compromise and CA compromise, or a set of certificates based on arbitrary local information, such as all certificates issued to the NIST employees located in Boulder. Hotmail(R) goes where you go. On a PC, on the Web, on your phone. See how. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Multiple CRL with same issuer
(First: I'm sorry. I misunderstood something I read in the OpenSSL documentation. CRLs are always V2 according to RFC5280.) I have not heard of the ability to specify or process multiple scopes in OpenSSL; however, have you verified that the CRL Extension Issuing Distribution Point is different between the two CRLs? This is where different scopes are specified (section 5.2.5 of RFC 5280). -Kyle H 2009/1/29 Kyle Hamilton aerow...@gmail.com: I think you're trying to assume something that cannot be assumed: you assume that ALL unexpired CRLs are considered. This is not the case. As Dominiqué said, only the CRL that has the latest signature time is considered. This is evident in the name of the file type: Certificate Revocation *List*. It is legal to issue a CRL that revokes a certificate (possibly with an type of onhold, for V3 CRLs) with an expiration time of 2 years in the future, and the next hour the to remove the revocation status. If all simultaneously-valid CRLs are considered, then the intended consequence of unrevoking the certificate would be impossible. This is why the CRL must contain the *complete* list of *all* revoked certificates which have not yet expired. There is a PKIX extension, delta CRLs, which defines for V3 CRLs a way to allow for adding to the list of the most-recently-issued full CRL. In order to support unrevocation, there is a special status type (called remove_from_crl) for the delta CRL which is to be interpreted as removing the certificate from the revocation list; however, in a full V3 CRL, that status type is illegal. And in V2 CRLs (the default, since many implementations do not handle V3 CRLs) there is no means of specifying the extension that contains a status type regardless. This is specified in PKIX (currently RFC 5280); in order to maintain standards-conformance OpenSSL cannot change this behavior. (Nor can it even offer an option to change it, since its job is to maintain security-system interoperability, not capriciously make it less secure.) -Kyle H 2009/1/29 Giang Nguyen cau...@hotmail.com: I was under the impression that openssl allows loading multiple CRLs for the same issuer. But, this does not seem to be the case as is proved by using openssl verify. $ ls -l ./ca/ total 24 lrwxrwxrwx 1 pshah users 10 Jan 28 21:56 ba4bb3b6.0 - cacert.pem - the CA cert lrwxrwxrwx 1 pshah users 14 Jan 28 21:56 ba4bb3b6.r0 - revoked_48.pem revokes only cert48.pem lrwxrwxrwx 1 pshah users 14 Jan 28 21:56 ba4bb3b6.r1 - revoked_49.pem - revokes only cert49.pem -rw-r--r-- 1 pshah users 1233 Jan 28 17:09 cacert.pem -rw-r--r-- 1 pshah users 560 Jan 28 17:10 revoked_48.pem -rw-r--r-- 1 pshah users 560 Jan 28 17:10 revoked_49.pem $ openssl verify -CApath ./ca/ -crl_check -verbose cert49.pem cert49.pem: OK $ openssl verify -CApath ./ca/ -crl_check -verbose cert48.pem cert48.pem: /C=--/ST=California/L=San Francisco/O=Riverbed Technology, Inc./OU=Steelhead/CN=hw1-sh18/emailaddress=fakeem...@example.com mailto:fakeem...@example.com error 23 at 0 depth lookup:certificate revoked 29615:error:0B07D065:x509 certificate routines:X509_STORE_add_crl:cert already in hash table:x509_lu.c:418: A CRL ( Certificat revocation list) is the list of ALL the revoked certificates at the time it is issued So if at time t1 a certificate 48 is revoked then all the subsequent CRLs MUST indicate that the certificate 48 as revoked If later at time t2 the certificate 49 is revoked hen all the subsequent CRLs MUST indicate that both certificate 48 and certificate 49 arte revoked Thus only the lasT CRL has to considered . Since the delivery times of the CRLs are close together it is not easy to check into the example which is ithe last CRL i think you misunderstood the question. the issue at hand is not about older and latest copies of a particular (certificate revocation) list, but it is about two *distinct* simultaneously valid and active (certificate revocation) lists that are issued/maintained by the same issuer. http://tools.ietf.org/html/rfc5280#section-5 Each CRL has a particular scope. The CRL scope is the set of certificates that could appear on a given CRL. For example, the scope could be all certificates issued by CA X, all CA certificates issued by CA X, all certificates issued by CA X that have been revoked for reasons of key compromise and CA compromise, or a set of certificates based on arbitrary local information, such as all certificates issued to the NIST employees located in Boulder. Hotmail(R) goes where you go. On a PC, on the Web, on your phone. See how. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager
Re: Multiple CRL with same issuer
On Wed, Jan 28, 2009, PS wrote: Hi All, I was under the impression that openssl allows loading multiple CRLs for the same issuer. But, this does not seem to be the case as is proved by using openssl verify. $ ls -l ./ca/ total 24 lrwxrwxrwx 1 pshah users 10 Jan 28 21:56 ba4bb3b6.0 - cacert.pem - the CA cert lrwxrwxrwx 1 pshah users 14 Jan 28 21:56 ba4bb3b6.r0 - revoked_48.pem revokes only cert48.pem lrwxrwxrwx 1 pshah users 14 Jan 28 21:56 ba4bb3b6.r1 - revoked_49.pem - revokes only cert49.pem -rw-r--r-- 1 pshah users 1233 Jan 28 17:09 cacert.pem -rw-r--r-- 1 pshah users 560 Jan 28 17:10 revoked_48.pem -rw-r--r-- 1 pshah users 560 Jan 28 17:10 revoked_49.pem $ openssl verify -CApath ./ca/ -crl_check -verbose cert49.pem cert49.pem: OK $ openssl verify -CApath ./ca/ -crl_check -verbose cert48.pem cert48.pem: /C=--/ST=California/L=San Francisco/O=Riverbed Technology, Inc./OU=Steelhead/CN=hw1-sh18/emailaddress=fakeem...@example.com error 23 at 0 depth lookup:certificate revoked 29615:error:0B07D065:x509 certificate routines:X509_STORE_add_crl:cert already in hash table:x509_lu.c:418: So, as seen above, the second CRL is not loaded (and I have confirmed this with gdb.). OpenSSL 0.9.9-dev has additional CRL support not found in 0.9.8. It includes support for loading multiple CRLs with the same issuer name. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Multiple CRL with same issuer
thanks, kyle, for pointing that out about the issuing distribution point. http://tools.ietf.org/html/rfc5280#section-5.2.5 so if i read that section correctly, the issuing distribution point extension is THE way to specify scope as you mentioned. so two distinct CRLs from the same issuer can be simultaneously valid/active (as long as they have different issuing distribution point extensions). that's what you were saying right? so no, in our case, the two CRLs do NOT have the issuing distribution point extensions. i notice they also happen to be v1. any way, dr henson has said 0.9.9-dev includes support for loading multiple CRLs with the same issuer name. thanks. Date: Thu, 29 Jan 2009 02:12:29 -0800 Subject: Re: Multiple CRL with same issuer From: aerow...@gmail.com To: openssl-users@openssl.org (First: I'm sorry. I misunderstood something I read in the OpenSSL documentation. CRLs are always V2 according to RFC5280.) I have not heard of the ability to specify or process multiple scopes in OpenSSL; however, have you verified that the CRL Extension Issuing Distribution Point is different between the two CRLs? This is where different scopes are specified (section 5.2.5 of RFC 5280). -Kyle H 2009/1/29 Kyle Hamilton : I think you're trying to assume something that cannot be assumed: you assume that ALL unexpired CRLs are considered. This is not the case. As Dominiqué said, only the CRL that has the latest signature time is considered. This is evident in the name of the file type: Certificate Revocation *List*. It is legal to issue a CRL that revokes a certificate (possibly with an type of onhold, for V3 CRLs) with an expiration time of 2 years in the future, and the next hour the to remove the revocation status. If all simultaneously-valid CRLs are considered, then the intended consequence of unrevoking the certificate would be impossible. This is why the CRL must contain the *complete* list of *all* revoked certificates which have not yet expired. There is a PKIX extension, delta CRLs, which defines for V3 CRLs a way to allow for adding to the list of the most-recently-issued full CRL. In order to support unrevocation, there is a special status type (called remove_from_crl) for the delta CRL which is to be interpreted as removing the certificate from the revocation list; however, in a full V3 CRL, that status type is illegal. And in V2 CRLs (the default, since many implementations do not handle V3 CRLs) there is no means of specifying the extension that contains a status type regardless. This is specified in PKIX (currently RFC 5280); in order to maintain standards-conformance OpenSSL cannot change this behavior. (Nor can it even offer an option to change it, since its job is to maintain security-system interoperability, not capriciously make it less secure.) -Kyle H 2009/1/29 Giang Nguyen : I was under the impression that openssl allows loading multiple CRLs for the same issuer. But, this does not seem to be the case as is proved by using openssl verify. $ ls -l ./ca/ total 24 lrwxrwxrwx 1 pshah users 10 Jan 28 21:56 ba4bb3b6.0 - cacert.pem - the CA cert lrwxrwxrwx 1 pshah users 14 Jan 28 21:56 ba4bb3b6.r0 - revoked_48.pem revokes only cert48.pem lrwxrwxrwx 1 pshah users 14 Jan 28 21:56 ba4bb3b6.r1 - revoked_49.pem - revokes only cert49.pem -rw-r--r-- 1 pshah users 1233 Jan 28 17:09 cacert.pem -rw-r--r-- 1 pshah users 560 Jan 28 17:10 revoked_48.pem -rw-r--r-- 1 pshah users 560 Jan 28 17:10 revoked_49.pem $ openssl verify -CApath ./ca/ -crl_check -verbose cert49.pem cert49.pem: OK $ openssl verify -CApath ./ca/ -crl_check -verbose cert48.pem cert48.pem: /C=--/ST=California/L=San Francisco/O=Riverbed Technology, Inc./OU=Steelhead/CN=hw1-sh18/emailaddress=fakeem...@example.com error 23 at 0 depth lookup:certificate revoked 29615:error:0B07D065:x509 certificate routines:X509_STORE_add_crl:cert already in hash table:x509_lu.c:418: A CRL ( Certificat revocation list) is the list of ALL the revoked certificates at the time it is issued So if at time t1 a certificate 48 is revoked then all the subsequent CRLs MUST indicate that the certificate 48 as revoked If later at time t2 the certificate 49 is revoked hen all the subsequent CRLs MUST indicate that both certificate 48 and certificate 49 arte revoked Thus only the lasT CRL has to considered . Since the delivery times of the CRLs are close together it is not easy to check into the example which is ithe last CRL i think you misunderstood the question. the issue at hand is not about older and latest copies of a particular (certificate revocation) list, but it is about two *distinct* simultaneously valid and active (certificate revocation) lists that are issued/maintained by the same issuer. http://tools.ietf.org/html/rfc5280#section-5 Each CRL has a particular scope. The CRL scope is the set
