On Mon, Nov 27, 2000 at 10:58:23AM -0800, Lynn.Wheeler@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