Announcing httpsy://, a YURL scheme

[Bill Frantz]

At 8:26 AM -0700 7/16/03, Perry E. Metzger wrote:
>Ian Grigg <iang at systemics.com> writes:
>> Michael_Heyman at 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.
>2) It leads to situations in which you have no way to know what sort
>   of trust relationship you have for the documents you're looking at.
>3) It is impossible for people to determine that a "YURL" actually is
>   what it claims it is, given that most people can't actually
>   remember one hash, let alone large numbers of them, etc.
>
>Those are just some of the more obvious issues.

It seems to me that we are just pushing around the problem that, in the
end, we must trust at least one key to be:

* Not compromised

* Follows a trustworthy key usage policy


In the YURL case, we are trusting the key used by the target.  In the
classic X.509 case, we are trusting the CA key.  Following Trevor Perrin's
<trevp at trevp.net> suggestion, we are trusting a key trusted by the target.
Lets look more carefully at these three systems.

YURL:

+ Bob knows that the Carol he connected to is the same Carol that Alice
meant because the key hash matches.

+ Stealing a key affects only a limited number of YURLs

- We depend on a key which is in constant use, and therefore more
vulnerable to theft.

- Carol can't revoke her key without invalidating all the YURLs that
mention it.


X.509

+ We depend on a key which is highly protected, and probably less
vulnerable to theft.

+ A new key, with a new cert can be rolled into use easily.

- We must ensure that all the CA keys we trust agree about who the name
Carol designates.

- A CA key is a big, fat target.  Compromise will affect a lot of URLs


Trevor Perrin's Suggestion

(I am going to assume for the moment that Carol acts as her own CA, and
protects her CA key by keeping it offline and/or splitting it into
distributed shares.)

+ Bob knows that the Carol he connected to is the same Carol that Alice
meant because the CA key hash matches and has issued a current cert for the
temporary key.  (The connection protocol delivers the public CA key, the
public temporary key, and the cert from Carol to Bob.)  There is no
confusion about who Carol is.

+ A new key, with a new cert can be rolled into use easily.  (Even easier
than dealing with Verisign.)

+ Stealing Carol's CA key only affects her site YURLs.

+ We depend on a key which is highly protected, and probably less
vulnerable to theft.


What am I missing?

Cheers - Bill



-------------------------------------------------------------------------
Bill Frantz           | "A Jobless Recovery is | Periwinkle -- Consulting
(408)356-8506         | like a Breadless Sand- | 16345 Englewood Ave.
frantz at pwpconsult.com | wich." -- Steve Schear | Los Gatos, CA 95032, USA



---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com