That's what I'm not sure about either. I think the general knowledge about CRL
is low among developers and administrators, considering mine and googled
knowledge. I looked at verisign's Class 1 Public Primary Certification
Authority crl and it has validity from 2011-03-22 until 2011-07-01. Quite long
for such large organisation (http://crl.verisign.com/pca1.crl).
Some quotations from RFC 5280:
* The meaning of "suitably recent" may vary with local policy, but it usually
means the most recently issued CRL. [i.e. not any, that's still valid]
* Conforming applications are not required to support processing of (...)
indirect CRLs
* The next CRL could be issued before the indicated date, but it will not be
issued any later than the indicated date.
But there are also references, that CRL is considered valid until the next
update date. We will use this method and re-download CRL every 60 minutes,
without regard to the nextUpdate field.
Viliam
On 4.5.2011 12:32, Erwann ABALEA wrote:
Hodie IV Non. Mai. MMXI, Viliam Ďurina scripsit:
Thanks very much for the hints. Finally, I decided to generate CRL for three
years and replace it, when something needs to be revoked, if ever. I think the
support is not good. We will have to distribute the CRL issuer certificate to
partner applications to be able to verify the CRL signature. And generally, the
support and knowledge about indirect crl is low among developers...
That could lead to a problem with crypto toolkits that try to fetch a
new CRL only when the actual has expired (it was a common behaviour
some years ago, I don't know how this evolved).
You could also pre-generate several CRLs, with a 1 month validity
period, and "disclose" a new one regularly.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
