|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |
X-Original-To: cryptography@metzdowd.com X-Original-To: cryptography@metzdowd.com Date: Wed, 16 Jul 2003 10:37:01 -0700 To: iang@systemics.com From: Trevor Perrin <trevp@trevp.net> Cc: Michael_Heyman@NAI.com, cryptography@metzdowd.com In-Reply-To: <87fzl6xzl7.fsf@snark.piermont.com> At 11:26 AM 7/16/2003 -0400, Perry E. Metzger wrote: >Ian Grigg <iang@systemics.com> writes: > > Michael_Heyman@NAI.com wrote: > > > > > A YURL aware search engine may find multiple independent references to a > > > YURL, thus giving you parallel reporting channels, and increasing trust. > > > Of course, this method differs from the YURL method for trust. The > > > parallel channel method assigns a trust value to a site by querying the > > > YURL aware search engine. > > > > That's an extraordinarily good idea! It reminds > >It seems to me to be more "a bad idea, fully realized". > >I'll repeat: > >1) The "YURL" makes key management and replacement effectively > impossible. One approach: instead of putting the end-entity key's fingerprint in the URL, place the CA key's fingerprint. CryptoURLs have an x509_root_sha1 datatype for this purpose. Then ensure that the HTTPS server returns the CA's self-signed cert. The client hashes this to see if the fingerprint matches the cryptoURL, then validates the chain in the usual way. Now a compromise of the EE's key can be recovered from like normal. For example, the CA can issue short-lived certs, or the EE cert can have a CDP extension where CRLs are found. Compromise of the CA key is still a catastrophe, but it always was. The neat thing here is the EE can choose his own "CA", based on the sole critieria that he believes it will remain secure, and will be rigorous in authenticating him. For example, I could choose my mom as my "CA", since she's highly security-conscious and unlikely to certify anyone else as me. Or I could be my own CA, but split the CA key up into threshold shares and stow them in various safes and hiding places, and proactivize them periodically. The negative, security-wise, is that now you're relying on two trusted introducers: wherever the cryptoURL came from, and the CA. But for that price, you've purchased some resilience to EE key compromise. Trevor --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |