Re: [cryptography] Request - PKI/CA History Lesson - the definition of trust

2014-05-05 Thread Jeffrey Goldberg
On 2014-05-05, at 1:12 PM, pjklau...@gmail.com pjklau...@gmail.com wrote:

 -Original Message-
 From: Jeffrey Goldberg [mailto:jeff...@goldmark.org] 

 Just because you are talking to the right IP address doesn't mean
 you are talking the right host.
 
 You're right yes ( I did forget :), but if a DNS can somehow guarantee a
 correct hostname-IPAddress mapping, then it can also guarantee a correct
 hostname-public key ( or self signed certificate) mapping.

Ah. OK. Thanks for spelling that out for me. Now it makes sense.

Cheers,

-j


___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography


Re: [cryptography] Request - PKI/CA History Lesson - the definition of trust

2014-05-04 Thread Jeffrey Goldberg
On 2014-05-03, at 3:22 AM, pjklau...@gmail.com pjklau...@gmail.com wrote:

 Frankly, if we could trust in DNS, we would not need to trust in
 web-PKIX [2] - since the one is just the bandaid for the other.

Have you forgotten that routing can be subverted?

Just because you are talking to the right IP address doesn’t mean
you are talking the right host.

Cheers,

-j

___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography


Re: [cryptography] Request - PKI/CA History Lesson - the definition of trust

2014-05-04 Thread Greg
On May 4, 2014, at 6:39 PM, Jeffrey Goldberg jeff...@goldmark.org wrote:

 On 2014-05-03, at 3:22 AM, pjklau...@gmail.com pjklau...@gmail.com wrote:
 
 Frankly, if we could trust in DNS, we would not need to trust in
 web-PKIX [2] - since the one is just the bandaid for the other.
 
 Have you forgotten that routing can be subverted?
 
 Just because you are talking to the right IP address doesn’t mean
 you are talking the right host.

That is why signatures exist. With DNSChain and DNSCrypt, for example, you will 
know whether you're talking to the right host, and no IP-based routing or 
filtering can affect that.

Cheers,
Greg

--
Please do not email me anything that you are not comfortable also sharing with 
the NSA.



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography


Re: [cryptography] Request - PKI/CA History Lesson - the definition of trust

2014-05-04 Thread John Levine
In article eb40b06c-907f-42ee-be88-45361561e...@goldmark.org you write:
On 2014-05-03, at 3:22 AM, pjklau...@gmail.com pjklau...@gmail.com wrote:

 Frankly, if we could trust in DNS, we would not need to trust in
 web-PKIX [2] - since the one is just the bandaid for the other.

Have you forgotten that routing can be subverted?

Just because you are talking to the right IP address doesn�t mean
you are talking the right host.

Sure, but if the cert it presents has the hash in the DNSSEC signed
DANE record, it does.

R's,
John
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography


Re: [cryptography] Request - PKI/CA History Lesson - the definition of trust

2014-05-03 Thread pjklauser

Since we're on the subject of X509 history, I found Dr. Ed Gercks
Definition of Trust at [1] very helpful in really figuring out what
trust can mean. This work was done fairly early on the X509 timeline.

Frankly, if we could trust in DNS, we would not need to trust in
web-PKIX [2] - since the one is just the bandaid for the other. Therefore I
support any alternative DNS mechanisms (Namecoin?) which could eventually
make it into the mainstream.

quoting Gerck...
The provided trust definition leads to several consequences...

1) trust depends on the observer -- or, there is no absolute trust. What
you may know can differ from what I may know.

2) trust only exists as self-trust. This means that only self-trust has
zero information content, so trust on others always have information content
(surprises or, unexpected behavior, either good or bad).

3) two different observers cannot equally trust any received information.
Direct consequence of (1) and (2).

4) a self-declaration cannot convey trust to another entity when using one
and the same communication channel. Direct consequence of the abstract
definition.


[1] http://mcwg.org/mcg-mirror/trustdef.htm 
[2]
http://pjklauser.wordpress.com/2013/12/03/pkix-for-webserver-ssl-certificate
s-will-eventually-die/



---
This email is free from viruses and malware because avast! Antivirus protection 
is active.
http://www.avast.com

___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography


Re: [cryptography] Request - PKI/CA History Lesson - the definition of trust

2014-05-03 Thread Greg
On May 3, 2014, at 3:22 AM, pjklau...@gmail.com wrote:

 Frankly, if we could trust in DNS, we would not need to trust in
 web-PKIX [2] - since the one is just the bandaid for the other. Therefore I
 support any alternative DNS mechanisms (Namecoin?) which could eventually
 make it into the mainstream.

That is precisely what we're working on with DNSChain, a project that combines 
DNS with the blockchain (any blockchain, and Namecoin specifically is 
supported):

https://github.com/okTurtles/dnschain

Yesterday we released 0.2.0, our 5th/6th release (0.2.1 is the same thing, just 
forgot to bump the NPM version string).

This project represents as close to a practical form of self-trust as I'm 
aware of. It represents a flat P2P network topology, as opposed to a 
hierarchical one (like canonical DNS), that's based on the blockchain.

Its last remaining problem is a solid solution to the 51% problem. The Ethereum 
project has proposed some interesting ones. There's also interesting discussion 
going on within the BitShares community.

Cheers,
Greg

--
Please do not email me anything that you are not comfortable also sharing with 
the NSA.



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography