RE: Revocation with a renewed/rekeyed Root CA
> > - U1, U2, U3 are end-user certificates, issued by CA1 > > - U1 is revoked, and the CRL is published (lets call it CRLg1) > > The problem here is that you can't trust a CRL when its > signature key is compromised. I think that this is not the reason. If a signature key is compromised but used to revoke "itself": it can be a genuine authentic revocation (e.g. as reaction to the compromise) and it should be accepted as revocation, -- or -- it can be a forged revocation by a malicious entity made possible because of a compromise and in case of a proven compromise, permanent revocation seems very reasonable, doesn't it? oki, Steffen End of message. -- About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] RE: Revocation with a renewed/rekeyed Root CA
Le 17/10/2011 16:09, Jakob Bohm a écrit : On 10/17/2011 3:47 PM, Erwann Abalea wrote: Le 17/10/2011 14:34, Eisenacher, Patrick a écrit : Hi Erwann, -Original Message- From: Erwann Abalea Bonjour, While testing Apache-trunk (which will become apache 2.3.15), including the patch to use OpenSSL CRL validation, I've come to disagree with what OpenSSL does. My scheme is: - CA1 is a root (trust anchor), which is now in its first generation (lets call it CA1g1) - U1, U2, U3 are end-user certificates, issued by CA1 - U1 is revoked, and the CRL is published (lets call it CRLg1) you can't revoke a root CA by the means of a CRL. This works only out-of-band, i.e. you have to declare that the root CA in question is revoked and spread the news to all your customers. [OT note, please discuss in separate thread] I have seen CAs that declare an additional CRL for potentially revoking the CA itself. Yes, and that was supported by mod_ssl, even for non self-signed CAs, before the switch to OpenSSL CRL mechanism. That's not standard, of course. That CRL is initially empty, but might one day be replaced by one that revokes the (self-)issued CA cert, thus invalidating itself. A recipient of such a "suicide CRL" has two reasonable options: A) Accept it and revoke its own trust in that CA. B) Declare a logic error thus preventing use of that CA until the compromising entity issues a new empty CRL. I know that I can't revoke a root, and I didn't try to do that. Maybe my phrasing wasn't clear enough? The problem here is that you can't trust a CRL when its signature key is compromised. The X.509 2008 edition category b) concept that you cite is new to me and according to my understanding of PKI this doesn't make sense, because there is no trust relationship between any self signed keys, so I can't trust that key 2 has any relationship to key 1, specially not to issue its CRLs. In fact, the same paragraph exists in the 2005 edition of X.509. This paragraph was shorter in the 2000 edition. The idea here is that a CA is a name, not a key. You have the same principle for intermediate CAs, i.e. when you renew an intermediate CA, the CRL produced by the new private key encloses all the certificates: the ones generated before the renewal as long as the ones generated after the renewal. Just to clarify: Does the "renewed" CA have the same public/private key but different attributes/expiry or does it have different public/private key and different attributes/expiry? (I understand that they have the same distinguished name). As I said, I renewed and rekeyed it. So that's a new key pair, for the same CA (same name), and of course different validity dates. -- Erwann ABALEA - apyrolacustre: pouvant attendre __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] RE: Revocation with a renewed/rekeyed Root CA
On 10/17/2011 3:47 PM, Erwann Abalea wrote: Le 17/10/2011 14:34, Eisenacher, Patrick a écrit : Hi Erwann, -Original Message- From: Erwann Abalea Bonjour, While testing Apache-trunk (which will become apache 2.3.15), including the patch to use OpenSSL CRL validation, I've come to disagree with what OpenSSL does. My scheme is: - CA1 is a root (trust anchor), which is now in its first generation (lets call it CA1g1) - U1, U2, U3 are end-user certificates, issued by CA1 - U1 is revoked, and the CRL is published (lets call it CRLg1) you can't revoke a root CA by the means of a CRL. This works only out-of-band, i.e. you have to declare that the root CA in question is revoked and spread the news to all your customers. [OT note, please discuss in separate thread] I have seen CAs that declare an additional CRL for potentially revoking the CA itself. That CRL is initially empty, but might one day be replaced by one that revokes the (self-)issued CA cert, thus invalidating itself. A recipient of such a "suicide CRL" has two reasonable options: A) Accept it and revoke its own trust in that CA. B) Declare a logic error thus preventing use of that CA until the compromising entity issues a new empty CRL. I know that I can't revoke a root, and I didn't try to do that. Maybe my phrasing wasn't clear enough? The problem here is that you can't trust a CRL when its signature key is compromised. The X.509 2008 edition category b) concept that you cite is new to me and according to my understanding of PKI this doesn't make sense, because there is no trust relationship between any self signed keys, so I can't trust that key 2 has any relationship to key 1, specially not to issue its CRLs. In fact, the same paragraph exists in the 2005 edition of X.509. This paragraph was shorter in the 2000 edition. The idea here is that a CA is a name, not a key. You have the same principle for intermediate CAs, i.e. when you renew an intermediate CA, the CRL produced by the new private key encloses all the certificates: the ones generated before the renewal as long as the ones generated after the renewal. Just to clarify: Does the "renewed" CA have the same public/private key but different attributes/expiry or does it have different public/private key and different attributes/expiry? (I understand that they have the same distinguished name). __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] RE: Revocation with a renewed/rekeyed Root CA
Le 17/10/2011 14:34, Eisenacher, Patrick a écrit : Hi Erwann, -Original Message- From: Erwann Abalea Bonjour, While testing Apache-trunk (which will become apache 2.3.15), including the patch to use OpenSSL CRL validation, I've come to disagree with what OpenSSL does. My scheme is: - CA1 is a root (trust anchor), which is now in its first generation (lets call it CA1g1) - U1, U2, U3 are end-user certificates, issued by CA1 - U1 is revoked, and the CRL is published (lets call it CRLg1) you can't revoke a root CA by the means of a CRL. This works only out-of-band, i.e. you have to declare that the root CA in question is revoked and spread the news to all your customers. I know that I can't revoke a root, and I didn't try to do that. Maybe my phrasing wasn't clear enough? The problem here is that you can't trust a CRL when its signature key is compromised. The X.509 2008 edition category b) concept that you cite is new to me and according to my understanding of PKI this doesn't make sense, because there is no trust relationship between any self signed keys, so I can't trust that key 2 has any relationship to key 1, specially not to issue its CRLs. In fact, the same paragraph exists in the 2005 edition of X.509. This paragraph was shorter in the 2000 edition. The idea here is that a CA is a name, not a key. You have the same principle for intermediate CAs, i.e. when you renew an intermediate CA, the CRL produced by the new private key encloses all the certificates: the ones generated before the renewal as long as the ones generated after the renewal. -- Erwann ABALEA - j'ai entendu dire qu'une société allait commercialiser des logiciels permettant de ne pas télécharger les pubs et je vous trouvre cela inadmissible. Les sites seront mis tout nu et cela ridiculisera le site. -+- BL in: Guide du Neuneu d'Usenet - A poil, tout le monde a poil -+- __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Revocation with a renewed/rekeyed Root CA
Hi Erwann, > -Original Message- > From: Erwann Abalea > > Bonjour, > > While testing Apache-trunk (which will become apache 2.3.15), > including > the patch to use OpenSSL CRL validation, I've come to > disagree with what > OpenSSL does. > > My scheme is: > - CA1 is a root (trust anchor), which is now in its first > generation > (lets call it CA1g1) > - U1, U2, U3 are end-user certificates, issued by CA1 > - U1 is revoked, and the CRL is published (lets call it CRLg1) you can't revoke a root CA by the means of a CRL. This works only out-of-band, i.e. you have to declare that the root CA in question is revoked and spread the news to all your customers. The problem here is that you can't trust a CRL when its signature key is compromised. The X.509 2008 edition category b) concept that you cite is new to me and according to my understanding of PKI this doesn't make sense, because there is no trust relationship between any self signed keys, so I can't trust that key 2 has any relationship to key 1, specially not to issue its CRLs. Patrick Eisenacher __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
