[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Query on draft-ietf-ipsec-pki-req-03.txt
Brian,
Actually I agree with you and prefer avoiding a mandate that CRLs be
distributed in-band. CRLs may grow too huge. On the other hand, the IPSec
PKI requirements document now mandates certificate revocation verification.
It is not clear how this is supposed to work when the CRL distribution point
and the remote access IPSec host are separated by the security gateway with
which the remote host is negotiating. I think we must adopt one of the
following:
i. the verification requirement is somehow relaxed (e.g., making
verification mandatory whenever it is possible to acquire the CRL), or
ii. remote access IPSec hosts are forbidden from using certificates (except
when they already have the latest CRL through possibly another source), or
iii. the spec mandates a certificate revocation validation technique on
which even remote access IPSec hosts can always count.
I can't imagine anyone advocating the second choice. If the choice is
instead the last of the three, then it would be desirable to specify which
technique will be the interoperable one, so everyone doesn't have to
implement 8 (or whatever the number really turns out to be) different ones.
But the first of the three is the most practical of the alternatives, even
though everyone knows it is not the most secure.
-- Jesse
-----Original Message-----
From: Brian Korver [mailto:briank@Network-Alchemy.COM]
Sent: Monday, October 25, 1999 4:10 PM
To: jesse.walker@intel.com
Cc: ipsec@lists.tislabs.com
Subject: Re: Query on draft-ietf-ipsec-pki-req-03.txt
Walker, Jesse writes:
> Greg,
>
> Yes, I know; a lot of implementations do forward CRLs as part of their
> negotiations. The question is whether this must be required. If the draft
> requires all implementations do certificate validation, then I don't see
how
> conformance is possible unless the draft also requires implementations to
> pass CRLs.
>
> -- Jesse
Jesse,
I'm not sure that in-band CRL distribution should be a MUST. First,
some environments may prefer to leave CRLs as optional. For instance,
perhaps other mechanisms are available (OCSP, etc.). Second, we don't
yet know what the market will decide regarding distribution of revocation
information. Currently, the answer is probably "none of the above",
although one could envision such things as OCSP, CRLDistributionPoints,
or something else becoming "the answer". Since in-band distribution
of CRLs is probably the only choice we currently have, I think it
should receive a SHOULD.
I'd prefer text along the lines of
Unless configured to do otherwise, implementations SHOULD return CRLs
in response to CRL CERTREQ messages.
A warning about possible interoperability problems probably wouldn't
hurt either.
brian
briank@network-alchemy.com