Re: 15 reasons for using URLs/HTTP

On Thu, Feb 12, 2004 at 04:40:52PM -0800, Mark Baugher wrote:
> 
> Well, this statement isn't too hard to disprove.  Let's see, the last thing 
> I read today...
> http://josefsson.org/thesis/josefsson_simon_master_thesis.pdf
> has 31 occurrences of the word "trust."



Well, depends on your quality standards of "disprove".

This guy is talking about "trust", "trusted third party",
"trusted root", without ever defining that term. 

That's poor and should not have happened in a master 
thesis. If one is using such a word 31 times in a scientific
thesis, without ever giving any definition, then the
thesis is very questionable. He and the examinors should 
have known better.

And, If you had read the thesis instead of just calling the 
search function of your PDF viewer, you would have seen that
he is indeed using it very close to my explanation:

- He does not defined it well,
- He uses it to describe that you rely on someone else is 
  behaving well, like in "Trusted third party".

  In cryptography you have some hard problems which can't be
  solved technically. E.g. you can prove that it is impossible
  to get a cryptographical receipt that someone has received
  a message without revealing the message before generation 
  of the receipt. The receipt has to be generate either 
  before or after the other party has received the message. 
  In such a case, either workarounds like probabilistic
  schemes or "trusted third parties" are used: You ask
  a notary to forward the message and to make the receipt.

  Whenever you have a problem that is not cryptographically
  solved, then you need to "trust", which is outside the
  cryptography and therefore not cryptographically designed.

  If the trusted third party is a notary, then you have to 
  rely on the fact that he is not generating a wrong 
  deed or certificate.

  If the trusted third party is a different CA, then you 
  have to rely on the fact, that it is not generating 
  wrong digital certificates. You can verify with 
  cryptographical methods that a foreign certificate was
  generated by this CA, but you have to rely on the 
  fact that this CA will not generate false certificates.
  You cannot prove it. "Trust" is always the gap in 
  the technical security chain, which means that this
  gap is to be filled with non-technical measures, 
  e.g. human trust.


  This thesis does not contradict my statement, it 
  confirms it. And it does not make use of "trust"
  as a security mechanism. Even in this thesis, 
  "trust" begins where technical security ends.












> 
> My favorite reference lately is the Handbook of Applied Cryptography, 
> http://www.cacr.math.uwaterloo.ca/hac/ , which has several chapters about 
> the T word, such as "13.6.1 Trust between two domains"


I own the book from when it was first published, but 
I'm in my apartment in Dresden, while the book is in my
other apartment in Karlsruhe. So I currently can not reply
without having to visit a library.






> 
> I like to use the word myself in security contexts, 
> http://www.ietf.org/rfc/rfc3547 , 
> http://www.ietf.org/internet-drafts/draft-ietf-avt-srtp-09.txt - odd that 
> no one in the IESG security area coached us to avoid the word trust.



So may I cite yourself:

  "GDOI ultimately establishes keys among members of a
  group, which MUST be trusted to use those keys in an authorized
  manner according to group policy."


Exactly the same. You don't have a security mechanism to 
ensure or prove that sameone else is behaving properly.
That's why you need to fill the gap with "trust", which
is _outside_ technical security.











> Yes, but at least I'm well read on the topic of security.

Becoming abusive is not a good argument. 

And using just the search function of your PDF browser is 
not "reading". You need to understand the text.


For your information: I was working and researching on security and
cryptography at the European Institute for System Security (E.I.S.S.) 
in 1992-1998 and own a large collection of books about cryptography.
See RFC 1824.

Are you better read on the topic?


Hadmut