Re: the introduction problem, was Email and reputation (was Re: Service outages planned for April 25)

Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Tue, 03 May 2022 13:30 UTC

Return-Path: <mohta@necom830.hpcl.titech.ac.jp>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4F74C157B32 for <ietf@ietfa.amsl.com>; Tue, 3 May 2022 06:30:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.753
X-Spam-Level:
X-Spam-Status: No, score=-3.753 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-1.857, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ipw14lbusBW7 for <ietf@ietfa.amsl.com>; Tue, 3 May 2022 06:30:13 -0700 (PDT)
Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietfa.amsl.com (Postfix) with SMTP id DA578C14F725 for <ietf@ietf.org>; Tue, 3 May 2022 06:30:11 -0700 (PDT)
Received: (qmail 34630 invoked from network); 3 May 2022 13:25:34 -0000
Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 3 May 2022 13:25:34 -0000
Message-ID: <99d535b1-4e47-eac2-93e0-1b9073f6c3a8@necom830.hpcl.titech.ac.jp>
Date: Tue, 03 May 2022 22:30:06 +0900
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1
Subject: Re: the introduction problem, was Email and reputation (was Re: Service outages planned for April 25)
Content-Language: en-US
To: ietf@ietf.org
References: <dcc27c29-51f8-c2a4-8ce4-ee1a3c6cb017@nostrum.com> <AAE3C51B-0150-483C-8244-3D60BC31B19A@tzi.org> <2c5df733-0f86-d319-b886-81882328caa9@network-heretics.com> <1870005490.14504.1651151102962@appsuite-gw1.open-xchange.com> <t4f3j1$1mpc$1@gal.iecc.com> <626060406.28268.1651487745123@appsuite-gw1.open-xchange.com> <2480fd36-c16a-6d98-ddac-15d02259ffbe@taugh.com> <837df6ce-a771-ff2f-515b-1021cc242c23@network-heretics.com>
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
In-Reply-To: <837df6ce-a771-ff2f-515b-1021cc242c23@network-heretics.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/eTBQuso1Fa61rS5KaSZuFvZELls>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.34
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 May 2022 13:30:14 -0000

Keith Moore wrote:

> I'm not convinced that that's the (only or even most important) reason, 
> or that it's even true.   From my perspective there have been several 
> barriers to adopting S/MIME and/or PGPMIME, e.g. lack of MUA support, 
> lack of email domain CAs and support for them among root CAs, lack of a 
> well known and trusted set of root CAs such as exist for the web (it's 
> not clear that they should should be the same set), lack of a standard 
> key discovery mechanism, and (mostly I suspect) lack of mindshare.

As PKI is not cryptographically secure depending on wrong assumptions
that untrustworthy TTPs of CAs could be trusted, you are wrong.

Though CAs always claim that they are providing enough security,
as they don't know required security, which is known by the
first and the second but not the third parties, they can not
be really secure enough, which was demonstrated by diginotar.

Cryptographic security can be available only by sharing security
key directly between the fist and the second party without
involving untrustworthy TTPs.

						Masataka Ohta