From: Andreas Steffen (andreas.steffen_at_strongsec.net)
Date: Tue Aug 06 2002 - 12:37:45 CEST
Francis,
yes you are right, there were some other features which had higher
priority than the CRL fetching. But at last I intend to start
implementation next week. I think it would be a good thing to
discuss and establish the requirements together. Since you
are planning to use the CRL feature in the immediate future,
you certainly have some concrete ideas on how you'd like the CRL
updates to work. To start the discussion I try to list the desired
properties:
- CRL fetching shall be implemented asynchronously using pthreads.
This means that new updates will be prefetched some time before
the actual expiry. I suggest to start looking for a new CRL
when 90% of the time between thisUpdate and nextUpdate has
passed.
- CRL fetching will be based on URIs. I suggest to implement
http:, ldap:, and file: URIs.
- URIs can either be extracted from the crlDistributionPoints
X.509v3 certificate extension field or they can be predefined
on a per connection basis using a [left|right]crluri
parameter. Examples:
rightcrluri=http://www.strongsec.com/ca/cert.crl
rightcrluri=ldap://ldap.strongsec.com/C=CH, ...
rightcrluri=file://etc/ipsec.d/crls/crl.pem
rightcrluri=%cert # extraction from X.509v3 extension
rightcrluri=%none # no use of CRLs
- If we support file: URIs then it might not be necessary
anymore to fetch by default all CRLs in /etc/ipsec.d/crls
during Pluto startup.
- The existing chained list of CRLs will be augmented with
a field for each CRL pointing to a list of URIs.
This URI list structure has already been implemented
by the generalName_t struct used by the crlDistributionPoints
field in the x509cert_t struct.
- When Pluto starts up the CRL thread will be created. Based
on the statically defined URIs the thread will try to prefetch
these CRLs. After that the thread goes to sleep. It will
then be wakened during every IKE Main Mode negotiation
either by main_inI3_outR3() or main_inR3() in ipsec_doi.c.
This has the advantage that when a certificate is received
for the first time and the crlDistributionPoint is defined
through the extension field in the certificate, the CRL
will be fetched immediately, so that the connection
will come up for the first time with little delay.
- The CRL thread and the main Pluto process will be loosely
coupled. Bidirectional communication will go via the
chained list of CRLs with the access controlled by a mutex
variable.
What do you think about my proposal? Do you have some other
suggestions?
Kind regards
Andreas
Francis GASCHET wrote:
> Hello Andreas,
>
> A couple of months ago I asked you if it'd be useful if we write some
> patch to enable "automatic CRL fetching" based on the "CRL Distribution
> Points" of the certificate. You answered me that you were going to code
> that.
>
> As far as I know, this feature is not yet integrated to your patch.
> I understand that certificate transmission and chain verification were
> of higher priority !
>
> But now, we plan to spread out a big VPN for a customer and this feature
> would be helpful !
> Do you think we have better to do it or do you plan to code it for a
> more or less near future ?
>
> Best regards,
======================================================================
Andreas Steffen e-mail: andreas.steffen_at_strongsec.com
strongSec GmbH phone: +41 76 340 25 56
Alter Zürichweg 20 home: http://www.strongsec.com
CH-8952 Schlieren (Switzerland)
==========================================[strong internet security]==
_______________________________________________
Users mailing list
Users_at_lists.freeswan.org
http://lists.freeswan.org/mailman/listinfo/users
This archive was generated by hypermail 2.1.4 : Tue Aug 06 2002 - 14:19:33 CEST