Re: [TLS] [pkix] Cert Enumeration and Key Assurance With DNSSEC
"Jeffrey A. Williams" <jwkckid1@ix.netcom.com> Tue, 05 October 2010 17:48 UTC
Return-Path: <jwkckid1@ix.netcom.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 689233A6FE3 for <tls@core3.amsl.com>; Tue, 5 Oct 2010 10:48:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.661
X-Spam-Level:
X-Spam-Status: No, score=-1.661 tagged_above=-999 required=5 tests=[AWL=0.938, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oWjpJW9NHD3g for <tls@core3.amsl.com>; Tue, 5 Oct 2010 10:48:25 -0700 (PDT)
Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id 3F9E43A7079 for <tls@ietf.org>; Tue, 5 Oct 2010 10:48:22 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=G0kNXgrhYiJ6k29OoB2nzu8/y1Ji72s9Cvy76gCS2ohsgUmgOfEkOs21P2x392vo; h=Message-ID:Date:From:Reply-To:To:Subject:Cc:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP;
Received: from [209.86.224.41] (helo=elwamui-mouette.atl.sa.earthlink.net) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from <jwkckid1@ix.netcom.com>) id 1P3Bdf-0004wp-Ou; Tue, 05 Oct 2010 13:49:19 -0400
Received: from 99.93.224.206 by webmail.earthlink.net with HTTP; Tue, 5 Oct 2010 13:49:19 -0400
Message-ID: <14162174.1286300959783.JavaMail.root@elwamui-mouette.atl.sa.earthlink.net>
Date: Tue, 05 Oct 2010 12:49:19 -0500
From: "Jeffrey A. Williams" <jwkckid1@ix.netcom.com>
To: Ralph Holz <ralph-tls-tum@ralphholz.de>
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Mailer: EarthLink Zoo Mail 1.0
X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e519606889d15d047211d52525bc5cf0c0f317739350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 209.86.224.41
Cc: tls@ietf.org
Subject: Re: [TLS] [pkix] Cert Enumeration and Key Assurance With DNSSEC
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: "Jeffrey A. Williams" <jwkckid1@ix.netcom.com>
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Oct 2010 17:48:28 -0000
Ralph and all, -----Original Message----- >From: Ralph Holz <ralph-tls-tum@ralphholz.de> >Sent: Oct 5, 2010 11:48 AM >To: >Cc: tls@ietf.org >Subject: Re: [TLS] [pkix] Cert Enumeration and Key Assurance With DNSSEC > >Hi, > >> I am guessing here that you are in favor of pinning certs? >> If my guess is correct, can you tell us all why you are? > >I am not sure I am in favour. The practical argument for it would be >that a changed certificate should be reason for a user to stop for a >moment and think. OK for now, maybe. However, many certs have life-times >of 1 year or 2. Given that one day we may visit many more https-secured >sites, we would likely see more false alerts again soon, too - precisely >the thing that Firefox has been criticised for when it introduced its >new warning dialogue. > >On a more theoretical basis, I am also not sure if the 1:1 binding of >"one entity/identity - one key" is desirable. We agree here. > >Still, given the current PKI trust model and the current state of PKI as >such, I would probably vote with those in favour of pinning for the moment. Ok I understand your point I think. The bigger problem is, or seems to be the trust model itself, which I have concerns about and made those very clear on more than one occasion. > >> I am not as there are instances where a perfictly valid cert >> is used but that the issuing CA has had their Cert database >> hacked or corrupted and a secondary Cert becomes necessary >> or at least preferrable as a temporary fix. Of course such >> a cert would need to be issued by a different CA. > >Well... listening to CAs and their EV statements, such things should not >happen too often anyway. It should not be a argument against pinning. Maybe not, but given the state of CA's and now Trust anchors to a degree, I don't see how logically and positively one can pin any Cert without some possibility of miss-pinning same depending on of course what the method one is pinning the Cert too exactly for assurance reasons. I can think and/or know of a few Trust Anchors I would NEVER try to pin any cert too, and I can also think of several issuing and USG certified CA's I would not, and do not trust regardless of which Anchor they may be accurately/effectively pinned too. > >-- >Best regards, >Ralph >_______________________________________________ >TLS mailing list >TLS@ietf.org >https://www.ietf.org/mailman/listinfo/tls Regards, Jeffrey A. Williams "Obedience of the law is the greatest freedom" - Abraham Lincoln "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.com Phone: 214-244-4827
- [TLS] Cert Enumeration and Key Assurance With DNS… Phillip Hallam-Baker
- Re: [TLS] Cert Enumeration and Key Assurance With… Ben Laurie
- Re: [TLS] Cert Enumeration and Key Assurance With… Phillip Hallam-Baker
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Matt McCutchen
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Phillip Hallam-Baker
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Ben Laurie
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Marsh Ray
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Phillip Hallam-Baker
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Peter Gutmann
- Re: [TLS] [DNSOP] [pkix] Cert Enumeration and Key… Phillip Hallam-Baker
- Re: [TLS] [DNSOP] [pkix] Cert Enumeration and Key… Tony Finch
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Michael StJohns
- Re: [TLS] [DNSOP] [pkix] Cert Enumeration and Key… Tony Finch
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Martin Rex
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Marsh Ray
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Ralph Holz
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Stephen Farrell
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Geoffrey Keating
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Martin Rex
- Re: [TLS] Cert Enumeration and Key Assurance With… Ondřej Surý
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Jeffrey A. Williams
- Re: [TLS] Cert Enumeration and Key Assurance With… Phillip Hallam-Baker
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Martin Rex
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Phillip Hallam-Baker
- Re: [TLS] [DNSOP] [pkix] Cert Enumeration and Key… Jakob Schlyter
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Michael StJohns
- Re: [TLS] [DNSOP] [pkix] Cert Enumeration and Key… Andrew Sullivan
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Jeffrey A. Williams
- [TLS] OtherCerts & pinning (Was: Re: [pkix] Cert … Stephen Farrell
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Martin Rex
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Kemp, David P.
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Ralph Holz
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Ondřej Surý
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Phillip Hallam-Baker
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Jeffrey A. Williams
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Seth David Schoen
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Marsh Ray
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Stephen Kent
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Paul Hoffman
- Re: [TLS] Cert Enumeration and Key Assurance With… Nicolas Williams
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Martin Rex
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Marsh Ray
- Re: [TLS] [saag] [pkix] Cert Enumeration and Key … Peter Gutmann
- Re: [TLS] [saag] [pkix] Cert Enumeration and Key … Yaron Sheffer
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Henry B. Hotz
- Re: [TLS] [saag] [pkix] Cert Enumeration and Key … der Mouse
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Carl Wallace
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Jeffrey A. Williams
- Re: [TLS] [DNSOP] [saag] [pkix] Cert Enumeration … Doug Barton
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Bruno Harbulot
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Phillip Hallam-Baker
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Martin Rex
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Jeffrey A. Williams
- Re: [TLS] [DNSOP] [pkix] Cert Enumeration and Key… Paul Wouters