Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id CAA03279 for ; Mon, 20 Jul 2015 15:14:04 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ig0-f180.google.com (mail-ig0-f180.google.com [209.85.213.180]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 43FACF1 for ; Mon, 20 Jul 2015 15:14:04 +0000 (UTC) Received: by igr7 with SMTP id 7so16001396igr.0 for ; Mon, 20 Jul 2015 08:14:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vinumeris.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LwAG2swWxdRSioewxPStcAGurt6g6216lFZUtyD4n08=; b=Q8UGq9a0/EqfhKjrcLMi1y1m4Fw2BhJ7JcxulTyBxCYPd6ICdc7dob58gHWxU49reS RZ3YcpVWIoLLiRG9lkHuIUPMl+21z6W5AgP7HDh3wHvc9kHHcLTAgDdjxYLgKIulKDr8 26o+7qizVF4yDYNnWD9v593oMeUwgUi5mMlQg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=LwAG2swWxdRSioewxPStcAGurt6g6216lFZUtyD4n08=; b=QEFu33DW4cTk7yMljbFdjJu90VqHB/6ig600c4OHg6LeEXNFDYIXY/8ElnfwCenLbZ ymxvLHZo6absi2jpOpPm3/XwySeEV+ZebqOvdg2racnwYnCddInSv3FIYTfIlje8MBN0 9jdBsLGfQMtGOHt0EozUyUuc0mFCVSojUDgIz/hZNYMQOSYIdZuJ3CcKO8GFL+l8hbG+ qhIPzQghyAQF2GdPTLT+oieDovfyubXcuBezw2uC/GT5POPnJAyUSMrz/4yaXlXf9wcR QMU/CTv39enUR8cwsJlpJEwdcHLhoq7KKeVVXcM4N1rS9JvSZ/q225IdelJsa7QpjvkX QUPw== X-Gm-Message-State: ALoCoQkI9aEYyOmVtpLlc+eh8KIiJn7+4uzox9PphWvAhh6+8WFgKdlHxRx/8D18pVJUMVq5T27M MIME-Version: 1.0 X-Received: by 10.107.129.215 with SMTP id l84mr20489248ioi.78.1437405243725; Mon, 20 Jul 2015 08:14:03 -0700 (PDT) Received: by 10.50.108.111 with HTTP; Mon, 20 Jul 2015 08:14:03 -0700 (PDT) In-Reply-To: <55AD0B43.4010207@electrum.org> References: <55A4AF62.4090607@electrum.org> <55AB8785.4080201@electrum.org> <55AD0669.4040002@electrum.org> <55AD0B43.4010207@electrum.org> Date: Mon, 20 Jul 2015 17:14:03 +0200 Message-ID: From: Mike Hearn To: Thomas Voegtlin Content-Type: multipart/alternative; boundary=001a113ec6acf37729051b4ffcbb X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: bitcoin-dev@lists.linuxfoundation.org Subject: Re: [bitcoin-dev] Proposal: extend bip70 with OpenAlias X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 15:14:04 -0000 --001a113ec6acf37729051b4ffcbb Content-Type: text/plain; charset=UTF-8 > > The final signature is a signature of the payment request, it is not > part of DNSSEC. So, yes, that signature can be EC. > Right, got it. I think we've been talking about two related but separate issues (DNSSEC vs squeezing payment requests into URIs/qrcodes somehow). So: DNSSEC attests via an RSA chain to some EC key stored in the wallet which is then used to sign the payment request or URI, which also contains a domain name. > The payment requests I am currently playing with have the following values: > > pki_type = "dnssec+btc" (btc means that the signature is checked against > a Bitcoin address stored in DNS) > pki_data = the user's alias (DNS key) By "alias" you mean domain name? I'm not sure what DNS key means in this context. I'm still not really convinced that a domain name under some new roots is an identity people will want to use, but yes, I guess your approach would work for those who do want it. It still may be worth exploring the compact cert+optimized BIP70 (no DNSSEC) in a qrcode if making a network that stores small bits of data really is beyond us :( --001a113ec6acf37729051b4ffcbb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The final signature is a signature of the paymen= t request, it is not
part of DNSSEC. So, yes, that signature can be EC.
Right, got it. I think we've been talking about two related= but separate issues (DNSSEC vs squeezing payment requests into URIs/qrcode= s somehow). So: DNSSEC attests via an RSA chain to some EC key stored in th= e wallet which is then used to sign the payment request or URI, which also = contains a domain name.
=C2=A0