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, 5 Oct 2010 12:49:19 -0500 (GMT-05:00)
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