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

Phillip Hallam-Baker <> Tue, 01 February 2011 04:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A18813A6907 for <>; Mon, 31 Jan 2011 20:21:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.857
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0InrpKJlFLGr for <>; Mon, 31 Jan 2011 20:21:50 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 2E2AF3A6833 for <>; Mon, 31 Jan 2011 20:21:50 -0800 (PST)
Received: by gxk27 with SMTP id 27so2665863gxk.31 for <>; Mon, 31 Jan 2011 20:25:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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 with SMTP id 9mr4536200anh.120.1296534304499; Mon, 31 Jan 2011 20:25:04 -0800 (PST)
Received: by with HTTP; Mon, 31 Jan 2011 20:25:04 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <>
Date: Mon, 31 Jan 2011 23:25:04 -0500
Message-ID: <>
From: Phillip Hallam-Baker <>
To: Paul Hoffman <>
Content-Type: multipart/alternative; boundary=0016e6441dd8a8a809049b30ea63
Subject: Re: [dnsext] draft-jabley-dnsop-validator-bootstrap-00
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS Extensions working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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 <> 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