Middleware is used to perform the steps that you mention. For
example, the fetch-crl utility written by David Groep and available at
http://www.eugridpma.org/distribution/util/fetch-crl
will take as input the crl_url files, which themselves can be
produced by various means including extracting them from the *.info
files that are included also in the IGTF distributions, but are part
of those distributions anyway, and produce the .r0 files by
downloading them from the indicated URL's. The Grid Certificate
Profile says that the crlDistributionPoint *should* be included in
the CA certificate and so could in principle be extracted from there,
so the availability of these .info and .crl_url files is basically
"good practice" and a convenience. They are included for all CAs in
the IGTF distributions.
Note that some CAs based on certain authentication profiles do *not*
require CRLs (for example, those based on the Short-Lived Credential
Service profile, SLCS), and so the .info file for these will not
contain a crl_url, and a *.crl_url file will not be present in these
cases, so no download is needed. Again, this depends in detail on
the authentication profile being used.
Since you say this is for Teragrid - it is worth noting that an
attempt to get all TG CA's either accredited or moved to an alternate
profile that would allow them to become accredited according to other
criteria is in progress. If accredited against any IGTF profile,
subject to the above caveat, the .crl_url files will be present.
Hope this helps,
Alan
On Aug 13, 2007, at 8:47 PM, Keith Thompson wrote:
On Mon 07-08-13 20:19, Alan Sill wrote:
Too-short answer: See RFC 3280.
Probably long-enough answer: It is built into OpenSSL, and thus
inherited into Globus, but the details for fetching and enforcing the
CRLs depend on your grid middleware.
Maybe too long an answer, since you are probably not asking about
trust fabric issues:
The effect of the CRLs is to provide a revocation list against which
subject DNs can be checked. If you use these, you should be sure to
keep the CRLs up to date. Many grid middleware distributions, such
as the VDT, GLite, CaGrid, etc., used by large-scale grid projects
include tools to fetch the CRLs for the CAs trusted in the context of
their organizations.
[snip]
Hope this helps.
I've taken a very brief look at RFC 3280, and I don't *think* it
answers the question I was asking.
I think the question I asked was narrower than the one you answered.
Suppose I want to recognize a CA with hash 12345678. So, I install
the
certificate (12345678.0) and signing policy (12345678.signing_policy)
files in /etc/grid-security/certificates, but I also want to reject
any attempt to use a certificate that's been revoked.
The usual way to do this is to install the CRL, 12345678.r0, in
/etc/grid-security/certificates; this requires some process to update
it periodically, ideally whenever the CA updates it.
If I install just 12345678.crl_url *instead of* 12345678.r0, does
Globus pay any attention to the 12345678.crl_url file, or is it just
as if I had installed only 12345678.0 and 12345678.signing_policy?
I'm fairly sure that Globus will just ignore the 12345678.crl_url
file,
but I want to be certain on this point.
A separate question: Do some third-party tools outside of Globus
use *.crl_url files? If so, which ones? You mentioned VDT, GLite,
and CaGrid; do they use *.crl_url files or some other method.
(My own gx-map package includes a tool called gx-ca-update which
automatically downloads, verifies, and updates CRLs, but it's driven
by a description file for each CA, not by *.crl_url files. It's used
on TeraGrid.)
--
Keith Thompson <[EMAIL PROTECTED]> San Diego Supercomputer Center
<http://users.sdsc.edu/~kst/> 858-822-0853
"We must do something. This is something. Therefore, we must do
this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Alan Sill, Ph.D
TIGRE Senior Scientist, High Performance Computing Center
Adjunct Professor of Physics
TTU
====================================================================
: Alan Sill, Texas Tech University Office: Admin 233, MS 4-1167 :
: e-mail: [EMAIL PROTECTED] ph. 806-742-4350 fax 806-742-4358 :
====================================================================
