Re: [Trans] Write-up of the "Strict CT" variant
Watson Ladd <watsonbladd@gmail.com> Mon, 12 June 2017 01:22 UTC
Return-Path: <watsonbladd@gmail.com>
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57B581279E5 for <trans@ietfa.amsl.com>; Sun, 11 Jun 2017 18:22:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RSGZYUJdYjdz for <trans@ietfa.amsl.com>; Sun, 11 Jun 2017 18:22:57 -0700 (PDT)
Received: from mail-pg0-x236.google.com (mail-pg0-x236.google.com [IPv6:2607:f8b0:400e:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B0111200C1 for <trans@ietf.org>; Sun, 11 Jun 2017 18:22:57 -0700 (PDT)
Received: by mail-pg0-x236.google.com with SMTP id a70so40088206pge.3 for <trans@ietf.org>; Sun, 11 Jun 2017 18:22:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ra4RLphNgXq3CwMWSlZCOhf0nPL/nXDK/3XIWU6K4w0=; b=sI5Wm/I3eeWkEqxmvfFr6mBuxSNeI2aVoGaQtpu8j00Yi8zJ2KyGMimIwGem1fG07E ZxH7+mcvhFULEpDQ8A9r+TCPvYcMFtpiOqi40BvjK9aQ2ai3N56mCApiFkwIx1Ssf0fI C565yWrqLj3YVmMH/CU0I1ht9ic6ksIDrM71hlSLnu3WSb5XXtvZVPavNwC7kQlGsZGZ u7DQ1XzFNqFNqMAA91om7b0znVIHXh6piSBTU7OULRiEaB+UTSc4jxyAPRVIyEpHq9ld pSgSJR3coSRvDSqBvXSTWSFbQvD4eNbIT3ZvCyzBkanJXnwUkcbXxoHh8VfU8498Mgpk 2Cxw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ra4RLphNgXq3CwMWSlZCOhf0nPL/nXDK/3XIWU6K4w0=; b=RipfQs/mZFKAfqirsVV1fezdZHmsefXLERb5LmYKWP7czwXtYsfECZSolBCLYE2fDT GZJMxwCvx6WMAgbRdIok8ftvjqVbrYo0j40p82UzCwOmIL4jDW0MGud/RG+OzMrigrhz b6Z9+wRZGHZBgk55KgODgwzi6dhGBiEudHK98DUZmFtti04Zci8Fr/XQQr5JqZN/MduN kVuI+CI1/5XLDg2AQfYLJWgw1U8qaSmemjpp5tqgYNok763qZ8OM7NlaX0Ffi98ZdAXK ThBczqcPy3Lnssw/UTgNcvRzJlb7HUWrKWHp+KEIcOMWyM4wAVp6Qn8HmbsI2f0qmwg8 PR7A==
X-Gm-Message-State: AODbwcDUYzTYQVusR9GbQdMJSh42c0MgsHEBQJ/vfVjZvlsfRZNh9zLv JeqLbAYfILPRv7cTwqOdjeguYsxNJg==
X-Received: by 10.98.158.138 with SMTP id f10mr42968568pfk.177.1497230576794; Sun, 11 Jun 2017 18:22:56 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.186.225 with HTTP; Sun, 11 Jun 2017 18:22:56 -0700 (PDT)
In-Reply-To: <CAMm+Lwi8gq7pUyvrX5BDndwcZDPYc+PDX9dQfeCWa2dvLyqbEQ@mail.gmail.com>
References: <CALzYgEeUCmj4BgY7uKdMnsvTcbvfAunquuqHxD7FxuzZxY1=Fg@mail.gmail.com> <0dd84938-9625-c6c8-5f31-d5d0d0683c5c@eff.org> <D1C7ADE2-DA28-4F29-A0AB-482435CD2B15@kth.se> <CAErg=HGxU7dnd1kifeCph8jTR6eLJn2GZ9=KehiyLpLgwTne=g@mail.gmail.com> <CAMm+Lwi8gq7pUyvrX5BDndwcZDPYc+PDX9dQfeCWa2dvLyqbEQ@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
Date: Sun, 11 Jun 2017 18:22:56 -0700
Message-ID: <CACsn0cnfPq3-uxeWyy8J1ndocivbKRzne1wmZ7xMB4irxrfAeA@mail.gmail.com>
To: Phillip Hallam-Baker <ietf@hallambaker.com>
Cc: Ryan Sleevi <ryan-ietf@sleevi.com>, Eran Messeri <eranm@google.com>, Jacob Hoffman-Andrews <jsha@eff.org>, "trans@ietf.org" <trans@ietf.org>, Magnus Ahltorp <map@kth.se>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/trans/S-gI9Q8pXoazLBi80ADcOJ64sXY>
Subject: Re: [Trans] Write-up of the "Strict CT" variant
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Public Notary Transparency working group discussion list <trans.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trans>, <mailto:trans-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/trans/>
List-Post: <mailto:trans@ietf.org>
List-Help: <mailto:trans-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trans>, <mailto:trans-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Jun 2017 01:22:59 -0000
On Jun 7, 2017 8:45 AM, "Phillip Hallam-Baker" <ietf@hallambaker.com> wrote: On Wed, Jun 7, 2017 at 9:08 AM, Ryan Sleevi <ryan-ietf@sleevi.com> wrote: > > > > On Wed, Jun 7, 2017 at 8:51 AM, Magnus Ahltorp <map@kth.se> wrote: >> >> Well, that depends on the assurance level, doesn't it? For domain-validated certificates, sure, but those are next to worthless anyway. It would be hard to hold a CA responsible for issuing them, so the need for logging them is really small. > > > Let's not introduce CAs' marketing distinction into the technical discussion. Marketing is sometimes based on facts. In this case inconvenient facts for people proposing to trash the WebPKI trust model. If you want to spread disinformation, then I am going to respond to correct. https://www.scmagazineuk.com/updated-97-of-malicious-mobile-malware-targets-android/article/535410/ The press have stopped writing articles about 97% of malware targeting Android because it is no longer news. Apple do have some advantages in their structure besides enforcing what amounts to EV validation of developers. But it is the validation of every developer before they get developer credentials that makes the rest of their model feasible. > > Domain validated certificates - the basis for the Web PKI - are the only security level that matter. The holder of such a certificate can impersonate any site named in the certificate - whether from example.com to google.com. Domain Validation is not the 'basis' for the WebPKI. It did not even exist until late in the dotCom boom. The WebPKI was originally designed to establish accountability. It is the bridge between the online and offline accountability infrastructure. So I get to sue Verisign if they issue a cert incorrectly? Oh wait, that isn't actually the case: CAs disclaim all responsibility for what you say they they are supposed to do. Was it ever the case that this was possible?
- [Trans] Write-up of the "Strict CT" variant Eran Messeri
- Re: [Trans] Write-up of the "Strict CT" variant Ryan Sleevi
- Re: [Trans] Write-up of the "Strict CT" variant Ryan Sleevi
- Re: [Trans] Write-up of the "Strict CT" variant Eran Messeri
- Re: [Trans] Write-up of the "Strict CT" variant Eran Messeri
- Re: [Trans] Write-up of the "Strict CT" variant Ryan Sleevi
- Re: [Trans] Write-up of the "Strict CT" variant Andrew Ayer
- Re: [Trans] Write-up of the "Strict CT" variant Andrew Ayer
- Re: [Trans] Write-up of the "Strict CT" variant Magnus Ahltorp
- Re: [Trans] Write-up of the "Strict CT" variant Tom Ritter
- Re: [Trans] Write-up of the "Strict CT" variant Filippo Valsorda
- Re: [Trans] Write-up of the "Strict CT" variant Jacob Hoffman-Andrews
- Re: [Trans] Write-up of the "Strict CT" variant Magnus Ahltorp
- Re: [Trans] Write-up of the "Strict CT" variant Ryan Sleevi
- Re: [Trans] Write-up of the "Strict CT" variant Magnus Ahltorp
- Re: [Trans] Write-up of the "Strict CT" variant Ryan Sleevi
- Re: [Trans] Write-up of the "Strict CT" variant Magnus Ahltorp
- Re: [Trans] Write-up of the "Strict CT" variant Ryan Sleevi
- Re: [Trans] Write-up of the "Strict CT" variant Phillip Hallam-Baker
- Re: [Trans] Write-up of the "Strict CT" variant Watson Ladd