Re: [Asrg] Consent Proposal

"C. Wegrzyn" <wegrzyn@garbagedump.com> Wed, 02 July 2003 17:14 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02458 for <asrg-archive@odin.ietf.org>; Wed, 2 Jul 2003 13:14:47 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XlBT-0000RW-5k for asrg-archive@odin.ietf.org; Wed, 02 Jul 2003 13:14:19 -0400
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h62HEJEl001696 for asrg-archive@odin.ietf.org; Wed, 2 Jul 2003 13:14:19 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XlBT-0000RH-1o for asrg-web-archive@optimus.ietf.org; Wed, 02 Jul 2003 13:14:19 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02408; Wed, 2 Jul 2003 13:14:16 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XlBR-0004NA-00; Wed, 02 Jul 2003 13:14:17 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19XlBQ-0004N7-00; Wed, 02 Jul 2003 13:14:16 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XlBC-0000D3-Hl; Wed, 02 Jul 2003 13:14:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XlAb-0000Bv-0E for asrg@optimus.ietf.org; Wed, 02 Jul 2003 13:13:25 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02342 for <asrg@ietf.org>; Wed, 2 Jul 2003 13:13:22 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XlAZ-0004LZ-00 for asrg@ietf.org; Wed, 02 Jul 2003 13:13:23 -0400
Received: from mxsmta01.inithost.com ([209.235.30.103] helo=mxsmta01.dellhost.com) by ietf-mx with esmtp (Exim 4.12) id 19XlAY-0004LW-00 for asrg@ietf.org; Wed, 02 Jul 2003 13:13:22 -0400
Received: from garbagedump.com ([24.128.102.183]) by mxsmta01.dellhost.com (InterMail vM.5.01.03.06 201-253-122-118-106-20010523) with ESMTP id <20030702171514.FJPO6624.mxsmta01.dellhost.com@garbagedump.com>; Wed, 2 Jul 2003 13:15:14 -0400
Message-ID: <3F0312B9.7080502@garbagedump.com>
From: "C. Wegrzyn" <wegrzyn@garbagedump.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4a; MultiZilla v1.4.0.4A) Gecko/20030612
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Markus Stumpf <maex-lists-spam-ietf-asrg@Space.Net>
CC: asrg@ietf.org
Subject: Re: [Asrg] Consent Proposal
References: <HKEFKPNPJLANNFPFMDKJIEJOIIAA.danny@apache.org> <5.2.0.9.2.20030701172458.00bd1de0@std5.imagineis.com> <HKEFKPNPJLANNFPFMDKJIEJOIIAA.danny@apache.org> <20030702015753.F74353@Space.Net> <5.2.0.9.2.20030701201028.00babd58@std5.imagineis.com> <20030702190713.C82235@Space.Net>
In-Reply-To: <20030702190713.C82235@Space.Net>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: asrg-admin@ietf.org
Errors-To: asrg-admin@ietf.org
X-BeenThere: asrg@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/asrg>, <mailto:asrg-request@ietf.org?subject=unsubscribe>
List-Id: Anti-Spam Research Group - IRTF <asrg.ietf.org>
List-Post: <mailto:asrg@ietf.org>
List-Help: <mailto:asrg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/asrg>, <mailto:asrg-request@ietf.org?subject=subscribe>
List-Archive: <https://www1.ietf.org/pipermail/asrg/>
Date: Wed, 02 Jul 2003 13:13:29 -0400
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

If  certs were to ever become a widespread reality I would rather have 
them come from my bank - I have a relationship with them - and not from 
some other 3rd party.

Chuck Wegrzyn


Markus Stumpf wrote:

>On Tue, Jul 01, 2003 at 08:12:17PM -0400, Yakov Shafranovich wrote:
>  
>
>>What about a central CA issuing certificates to other CAs, controlled by 
>>IANA or ICANN-type of organization?
>>    
>>
>
>You mean to set the cat among the pigeons ;-)
>What you would need is a mechanism that creates and equal level of trust.
>As soon as I get a cert from CA-1 for 5 bucks and all that is needed is
>a working email address and CA-2 requires payment of 100 bucks and you
>have to send in legal papers and stuff you will create different levels
>of trust. That's what we have now. We have DNSBLs: some use them some
>not (no trust). Some block dialin IPs some not (diffferent levels of
>trust). What if in a country some of the legal documents required by
>CA-2 simply don't exist? In the US (I believe) there is something
>called social insurance number (or the like). Maybe in Dubai (I don't
>know) such a thing does not exist and nothing similar. But this would be
>required by a CA to identify e.g. a person. Would it mean people from Dubai
>can't get signed keys?
>
>And there is a social/commercial problem:
>What if in our country the two biggest emails providers with a share of
>say 30% don't stick to that system? What would I tell my customers?
>While private customers might understand it corporate customers will
>not understand why they can't talk to business partners any longer.
>
>And: you can't add pressure, as some of the smaller ISPs will say: "as
>our customer you can still receive mail from them. Leave your current
>ISP and join us". Big deal :(
>
>  
>
>>There are mechanisms in place to check 
>>verifications of certificates in real-time, and that can be implemented as 
>>well.
>>    
>>
>
>Hmmm ... take e.g. Verisign. I'd guess they have issued the most certs.
>What do you think would be needed as infrastructure so that every
>browser accessing a SSL site can verify the cert (e.g. if revoked) in
>real-time?
>certs work, because the producer of the browser added the CA keys
>of CAs to the browser and users depend on the producers of the browser
>and these depend on the CA to "do the right thing". If a key is signed
>by a "trusted" CA it's also trusted "per definitionem". We don't have
>working revocation mechanisms.
>
>To make it clear:
>I'd be more than glad if those methods would exist. There are patches
>for nearly all Mailservers to support SSL connections (STARTTLS) but I'd
>guess the percentage of mailservers using it has a lot of 0s after the
>decimal point and in front of the 1.
>
>	\Maex
>
>  
>



_______________________________________________
Asrg mailing list
Asrg@ietf.org
https://www1.ietf.org/mailman/listinfo/asrg