2008/10/20 Erwann ABALEA [EMAIL PROTECTED]:
What is the decision criteria to reload a CRL? expiration of the
notAfter date? An application based period would be better.
s/notAfter/nextUpdate/
--
Erwann.
2008/10/15 Dr Stephen Henson [EMAIL PROTECTED]:
Erwann ABALEA wrote:
2008/10/15 Dr Stephen Henson [EMAIL PROTECTED]:
Dirk-Willem van Gulik wrote:
On Aug 28, 2008, at 9:41 PM, Nicob wrote:
[...]
This issue does have some security implications. For example a revoked
client certificate could
Dirk-Willem van Gulik wrote:
On Aug 28, 2008, at 9:41 PM, Nicob wrote:
Hello,
I'm actually trying to setup a SSL reverse-proxy based on Apache 2.x and
mod_ssl and it seems there's a bug in the verification of the CRL.
If a CA changes its keys before expiration, the CRL is now signed by
Erwann ABALEA wrote:
Hello Mr Henson,
2008/10/15 Dr Stephen Henson [EMAIL PROTECTED]:
Dirk-Willem van Gulik wrote:
On Aug 28, 2008, at 9:41 PM, Nicob wrote:
[...]
While I haven't reviewed this specific patch I have a general comment.
There is currently some questionable behaviour in
Dr Stephen Henson wrote:
...
CRL refresh has some performance issues particularly in multi-process
servers. For example a CRL might be 500K or more and be reloaded on each
new connection. OpenSSL 0.9.9 does have some reload support though. If
CRL processing was delegated to OpenSSL it would
Le samedi 30 août 2008 à 14:50 +0200, Nicob a écrit :
It implements the matching on the Authority DN (vs. Authority
Key ID actually) during client certificate verification against a CRL
*and* a required test during CRL validation, as described in paragraph
6.3.3 of RFC 3280
So, do you think
But this is a bit too obscure for me to dare to commit it directly.
Could someone else with a good x509 understanding look at it ?
I'm not a x509 expert but I studied the patch and it seems to implement
precisely what is described in RFC 3280 Internet X.509 Public Key
Infrastructure
On Aug 28, 2008, at 9:41 PM, Nicob wrote:
Hello,
I'm actually trying to setup a SSL reverse-proxy based on Apache 2.x
and
mod_ssl and it seems there's a bug in the verification of the CRL.
If a CA changes its keys before expiration, the CRL is now signed by
the
new key and include
