CDR: Re: Public Key Infrastructure: An Artifact...

Eric Murray ericm at lne.com
Mon Nov 27 10:36:37 PST 2000


On Mon, Nov 27, 2000 at 10:58:23AM -0800, Lynn.Wheeler at firstdata.com wrote:


Hi Lynn!
 
> problem is that consumer don't normally  know that they want to check on a
> particular merchant's CRL entry until they realize that they want to go to that
> merchant site. in general, the consumer's aren't going to want  keep a local
> (usenet) database of all CRL entries (however they are distributed) ... so it is
> more likely the ISP would have to keep all the entries ... pushed into a
> database ... and let the consumer do an online database lookup of the CRL
> entries (effectively the local ISP is keeping cached copy of all entries ... and
> uses usenet as the distribution infrastructure).
> 
> sometimes, usenet can take several hrs to a day to propogate ... so the person
> may still want to do an online transaction against the agency that issued a
> certificate
> 
> In which case, the local ISP would be considered a "stand-in" ... maintaining a
> negative file ... and returning positive answers if there isn't a match in the
> negative file for the online transaction ... in which case the consumer may
> still want to do another online transactions against the master file (located
> somewhere in the internet).
> 
> Given that online transactions are being performed ... then it may even be more
> straightforward to use domain name infrastructure to manage distribution and
> management of cached entries. It has a somewhat better online transaction
> semantics than usenet (already). However, since this is turning into  online
> transaction infrastructure  ... it is then possible to eliminate both the
> certificates and CRLs totally and just use the straight-foward domain name
> infrastructure.


However, caching the revocation data (which DNS would do nicely) means
that there needs to be some way for the relying parties to authenticate
the cached revocation data.  They could authenticate the DNS cache, but
that means trusting all those DNS servers.  More practically
the DNS cache servers could authenticate the data as coming from a trusted
DNS server (which is how DNSSEC works now I beleive).  But that forces
the relying parties to trust that the DNS server that they're getting
the revocation data from has done the authentication.  And it
still doesn't address the issue of Mallet operating an evil DNS-CRL
cache which sends out bogus revocation data.  It also requires
the DNS caches to do the public-key crypto.

But, there's a solution- if the DNS servers and caches are sending out
revocation data which is signed by the real authority for revocation data
(whoever that may be for the application), and the relying parties
do the verification, then there's no security problem with the intermediate
DNS servers/caches.

So, IMHO, signed CRLs serve a purpose.

I agree that a cache system like DNS would be nice for CRL distribution
but I think that a usenet-type system would be good enough in practice.

I don't think that propagation delays are that big a problem in practical
use for TLS sites.  A CRL would only be issued if a merchant has shown
some amount of bad behaviour, or if there's been a key compromise.
For bad behaviour, there would likely be some sort of process
involved in issuing the CRL- one single report of merchant fraud would
not cause an issuer to revoke a cert instantly.  So if a merchant
goes "bad", there's likely to be quite a delay before they're revoked-
notices, appeals, etc.  A few hours taken in the distribution of the CRL
once the issuer's completed the process isn't going to make the problem
noticeably worse.

It'd be nice to have instant CRL distribution for key compromise, but
most sites will have been running with the compromised key for some time
before it's detected.  If a site really cares about security after
a key compromise, it could just go get a new cert and use that (after
fixing the problem that caused the compromise of course).





-- 
  Eric Murray           Consulting Security Architect         SecureDesign LLC
  http://www.securedesignllc.com                            PGP keyid:E03F65E5





More information about the cypherpunks-legacy mailing list