Re: [dnsext] draft-jabley-dnsop-validator-bootstrap-00

Phillip Hallam-Baker <hallam@gmail.com> Tue, 01 February 2011 04:21 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: dnsext@core3.amsl.com
Delivered-To: dnsext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A18813A6907 for <dnsext@core3.amsl.com>; Mon, 31 Jan 2011 20:21:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.857
X-Spam-Level:
X-Spam-Status: No, score=-2.857 tagged_above=-999 required=5 tests=[AWL=-0.499, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24]
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 0InrpKJlFLGr for <dnsext@core3.amsl.com>; Mon, 31 Jan 2011 20:21:50 -0800 (PST)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id 2E2AF3A6833 for <dnsext@ietf.org>; Mon, 31 Jan 2011 20:21:50 -0800 (PST)
Received: by gxk27 with SMTP id 27so2665863gxk.31 for <dnsext@ietf.org>; Mon, 31 Jan 2011 20:25:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=sJSs6GchoZuQe0Tv7OSTKzLt9u/20wSvX4douHe+xWE=; b=E/qfjoh3whBHbpMMC1D91c6SFE2b70B0F8hvx+pv7RWY94as4hpctfj86Pnn2Kohxb mGX5Uv5jk2QmtFVgGZHkIkeSi5oLB9Q96zP/Xo+H+kvK/tHUfpWgjDQQMvgV6NZdUewB NG2VzqOGR1qc7tzQ2b4RcJqrVJnFqQDTZvn6g=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=sYYgtgTe2MEAWgQ7JFToRiUwXVIYohnXxOKQWcsRuvKzyS3tzqxKx9/WTnY8tXkr8y Rsoa5d5rPBgLQBCf+Ogk+oOINcAWhUknOxilq/WfDurl93oYQ+DdJQ55eqY9Frg+EEck +C0HZAL6HRxhJbE6WW4SKlOAJbIf4vWnavTV8=
MIME-Version: 1.0
Received: by 10.100.8.9 with SMTP id 9mr4536200anh.120.1296534304499; Mon, 31 Jan 2011 20:25:04 -0800 (PST)
Received: by 10.100.109.16 with HTTP; Mon, 31 Jan 2011 20:25:04 -0800 (PST)
In-Reply-To: <4D476699.5060105@vpnc.org>
References: <3E0BC533-AFF7-4E5E-A52E-BD7814FC4060@hopcount.ca> <4D472D2C.9090108@cisco.com> <6819D144-A148-41AB-BF38-A888E0950D7E@hopcount.ca> <AANLkTikx-cc47UFjK6=DxwxJVraMv89L-ebBmhHPn7ZE@mail.gmail.com> <4D476699.5060105@vpnc.org>
Date: Mon, 31 Jan 2011 23:25:04 -0500
Message-ID: <AANLkTimcfz6sQMHQFgR2gpiBfGCndTZqbKGDugfjrPpi@mail.gmail.com>
From: Phillip Hallam-Baker <hallam@gmail.com>
To: Paul Hoffman <paul.hoffman@vpnc.org>
Content-Type: multipart/alternative; boundary=0016e6441dd8a8a809049b30ea63
Cc: dnsext@ietf.org
Subject: Re: [dnsext] draft-jabley-dnsop-validator-bootstrap-00
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsext>
List-Post: <mailto:dnsext@ietf.org>
List-Help: <mailto:dnsext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Feb 2011 04:21:51 -0000

I was going to reply to this post, then I read it and saw that you cannot
converse in a civil fashion.



On Mon, Jan 31, 2011 at 8:49 PM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:

> On 1/31/11 4:40 PM, Phillip Hallam-Baker wrote:
>
>> To be precise here, there is no difference in the likelihood that the
>> keys will be compromised.
>>
>
> Quite right.
>
>
>  The difference is that the X.509 protocol is designed to support keys
>> that are persistent over long periods (decades) and DNSSEC is not.
>>
>
> Poppycock. Both PKIX and DNSSEC are agnostic on how long the keys are meant
> to last. Pretending that PKIX has some advantage here is nonsense.
>
>
>  In particular an X.509 self-signed certificate is an assertion that the
>> key holder will maintain and use the associated private key in
>> accordance with the specified practices for the specified length of time.
>>
>
> Bosh. If you are talking about the "notAfter" field, it is defined as the
> end of "the time interval during which the CA warrants that it will maintain
> information about the status of the certificate"; that is quite different
> than "maintain and use". If you are speaking of something else, please quote
> from the PKIX spec.
>
>
>  You can easily find out how long Comodo or Symantec or whoever is going
>> to maintain their SSL CA roots, the information is right there in the
>> cert store and is irrevocable in that the CA can extend the time period
>> (through recertification) but cannot reduce it.
>>
>
> Balderdash. When I look in Comodo's certificate in my "cert store", I don't
> see anything about how long you are going to maintain your SSL CA root. I
> see something that says you will maintain *information about the status* of
> the certificate; note the difference. As for "irrevocable", that's just
> silly: Comodo can revoke it at any time. There is no contract here.
>
>
>  My advice to Cisco would be to use their existing root to sign the
>> published CSR for the DNS root KSK in the short term at least.
>>
>
> Signing is the easy part: making their systems use that signed key is much
> more difficult. That difficulty is what started this thread; handwaving it
> away won't help Cisco or anyone.
>
>
>  In the longer term we are going to have to have a look at the problem at
>> a higher level and work out how we are going to solve it in a scalable
>> way across all the platforms that involve a root key.
>>
>> We are starting to make quite a little collection of industry forums
>> that are doing this root key management as a sideline.
>>
>
> Now everyone can rest assured: industry forums to the rescue!
>
> _______________________________________________
> dnsext mailing list
> dnsext@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsext
>



-- 
Website: http://hallambaker.com/