From nobody Fri Jun 3 08:15:04 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7B7D12D0B9 for ; Fri, 3 Jun 2016 08:15:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.127 X-Spam-Level: X-Spam-Status: No, score=-4.127 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OXSolazkS6NA for ; Fri, 3 Jun 2016 08:15:01 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id A8A4B12D1C7 for ; Fri, 3 Jun 2016 08:14:53 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id CF08B4237FC for ; Fri, 3 Jun 2016 15:14:52 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id AA4154237FB for ; Fri, 3 Jun 2016 15:14:52 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1464966892; bh=tGk07/6pVgiOZzHkkYh1E+7Dis02i0WuS7MzdDYjt3k=; l=611; h=From:To:Date:From; b=NI6GKyrl26KFbOHbPrUFg5h4rh+p7iiSWzLd1wmIBDPgEMvIiNheFDbOkM7E0WjXK seyrjyfl6UEESTHENQFJSuI8lcsBdBfjI0boQ5tTki3rmQRzeidf/udOb6jOD2fkg0 SmU7ObIYPtQK+pvaoLnzNgOpNzEjiOWJ2chu2u5o= Received: from email.msg.corp.akamai.com (ecp.msg.corp.akamai.com [172.27.123.34]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id A76CF1FC86 for ; Fri, 3 Jun 2016 15:14:52 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Fri, 3 Jun 2016 11:14:52 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1130.005; Fri, 3 Jun 2016 11:14:52 -0400 From: "Salz, Rich" To: "curdle@ietf.org" Thread-Topic: Should we meet in Berlin? Thread-Index: AdG9qpxMbwoVwVYWS3aL1Di+C6rOTg== Date: Fri, 3 Jun 2016 15:14:51 +0000 Message-ID: <1398fd6401e24d5a848ca8380db47e3b@usma1ex-dag1mb1.msg.corp.akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.37.164] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Curdle] Should we meet in Berlin? X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 15:15:03 -0000 We are trying to decide if it makes sense to meet at the next IETF in Berli= n. There are several threads on the mailing list, and if a good set of them wi= ll be present, we can perhaps come to some good initial consensus (to be ve= rified, as always, on the mailing list afterwards) The threads we see incl= ude: Eddsa-signatures draft David Benjamin's "simplification" proposal The deadline for scheduling is next Friday, so please speak up *now* if you= think we should ask for a one-hour slot. -- =20 Senior Architect, Akamai Technologies IM: richsalz@jabber.at Twitter: RichSalz From nobody Fri Jun 3 19:46:12 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE94F12D50F for ; Fri, 3 Jun 2016 19:46:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cbQDC0hlkJri for ; Fri, 3 Jun 2016 19:46:09 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E19D612D0CE for ; Fri, 3 Jun 2016 19:46:09 -0700 (PDT) Received: from hebrews (c-24-21-96-37.hsd1.or.comcast.net [24.21.96.37]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 29EC12CA9D; Fri, 3 Jun 2016 19:46:09 -0700 (PDT) From: "Jim Schaad" To: "'Salz, Rich'" , References: <1398fd6401e24d5a848ca8380db47e3b@usma1ex-dag1mb1.msg.corp.akamai.com> In-Reply-To: <1398fd6401e24d5a848ca8380db47e3b@usma1ex-dag1mb1.msg.corp.akamai.com> Date: Fri, 3 Jun 2016 19:46:08 -0700 Message-ID: <010201d1be0b$3f921130$beb63390$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQINZ1N6Ny+esemMd8e5uO3ehBKCf59hRrqQ Content-Language: en-us Archived-At: Subject: Re: [Curdle] Should we meet in Berlin? X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jun 2016 02:46:12 -0000 Do we expect to see authors? I believe that I am currently waiting for comments on the pkix eddsa draft, the cms eddsa draft is stuck on this one. I would really like to discuss how the ECDH and EdDSA algorithms are being identified in PKIX, in part because I want it to match what is being done in other groups. So I would appreciate a meeting. Jim > -----Original Message----- > From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Salz, Rich > Sent: Friday, June 03, 2016 8:15 AM > To: curdle@ietf.org > Subject: [Curdle] Should we meet in Berlin? > > We are trying to decide if it makes sense to meet at the next IETF in Berlin. > > There are several threads on the mailing list, and if a good set of them will be > present, we can perhaps come to some good initial consensus (to be verified, as > always, on the mailing list afterwards) The threads we see include: > Eddsa-signatures draft > David Benjamin's "simplification" proposal > > The deadline for scheduling is next Friday, so please speak up *now* if you think > we should ask for a one-hour slot. > > > > -- > Senior Architect, Akamai Technologies > IM: richsalz@jabber.at Twitter: RichSalz > > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle From nobody Fri Jun 3 21:15:12 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 824B212D1CC for ; Fri, 3 Jun 2016 21:15:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.125 X-Spam-Level: X-Spam-Status: No, score=-4.125 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WfkOAXWS8Vka for ; Fri, 3 Jun 2016 21:15:08 -0700 (PDT) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E21312D13C for ; Fri, 3 Jun 2016 21:15:08 -0700 (PDT) Received: by mail-io0-x233.google.com with SMTP id k19so85009809ioi.3 for ; Fri, 03 Jun 2016 21:15:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=w+sa/G5k7mWSrT3u/IiNjmoWObjDb+ZqgTtsthiXgnU=; b=Nss8vOkSxOin4UHV6VO7xDcaCo+OXKK21IboTU02EWJfqvu0s+sMtm4QrKPOeGkP+7 wdbexZ999LtIbRxrbm3cWyntxXvQY4UDg5ZkzVMMCSv7tox9wnBIkjAMkAEoDEhX/QEV 1hVkC5CEfc5cEHQ4LuxWOX3qRgxe2psXtExdc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=w+sa/G5k7mWSrT3u/IiNjmoWObjDb+ZqgTtsthiXgnU=; b=fJFt72CIEKD4CXDQlE/eJRY8jvwFocG36mjB2r3927FLfhN05YSONsPzZbsvz2GLW/ 7rNstSOTbSwTbMHSL4wGMscbePfCxUCCji/axAQwjvo6i5uYTZNm8rG+R4JZv/zBiHLt uMaZgaSOWRf0fe0QjP0x/GlcSFI5QADiom/cU9K2sRfz9DNNjQ77n4XBn4JN6MaL2kS+ Z1a7F1hTvOLLGslCbzMNJDXv5YiBZQRav0X+jnGrWZs3rg0gYkDix2oQiNYlNHZdqEO9 hgD17w1dzppxf+4pO4I4uJaHjTvbcJhpooEctePtYg/OxwE+gnvpK4AuwylpuF1M/lTF HjUA== X-Gm-Message-State: ALyK8tJWom/BDN1N5ocYzZYDDaPN4G8gcW/m7/4V76Oh6YIctljMaZHJZt37xErzVfyiqeEE3AVqyCJA69yczR+l X-Received: by 10.107.9.10 with SMTP id j10mr10321000ioi.97.1465013707537; Fri, 03 Jun 2016 21:15:07 -0700 (PDT) MIME-Version: 1.0 References: <1398fd6401e24d5a848ca8380db47e3b@usma1ex-dag1mb1.msg.corp.akamai.com> <010201d1be0b$3f921130$beb63390$@augustcellars.com> In-Reply-To: <010201d1be0b$3f921130$beb63390$@augustcellars.com> From: David Benjamin Date: Sat, 04 Jun 2016 04:14:57 +0000 Message-ID: To: Jim Schaad , "Salz, Rich" , curdle@ietf.org Content-Type: multipart/alternative; boundary=001a113f9b6aa1577905346c1567 Archived-At: Subject: Re: [Curdle] Should we meet in Berlin? X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jun 2016 04:15:10 -0000 --001a113f9b6aa1577905346c1567 Content-Type: text/plain; charset=UTF-8 I'm not a draft author, but I plan to be at Berlin and am happy to talk about my proposal there if that would be useful. David On Fri, Jun 3, 2016 at 10:46 PM Jim Schaad wrote: > Do we expect to see authors? I believe that I am currently waiting for > comments on the pkix eddsa draft, the cms eddsa draft is stuck on this one. > > I would really like to discuss how the ECDH and EdDSA algorithms are being > identified in PKIX, in part because I want it to match what is being done > in > other groups. So I would appreciate a meeting. > > Jim > > > > -----Original Message----- > > From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Salz, Rich > > Sent: Friday, June 03, 2016 8:15 AM > > To: curdle@ietf.org > > Subject: [Curdle] Should we meet in Berlin? > > > > We are trying to decide if it makes sense to meet at the next IETF in > Berlin. > > > > There are several threads on the mailing list, and if a good set of them > will be > > present, we can perhaps come to some good initial consensus (to be > verified, as > > always, on the mailing list afterwards) The threads we see include: > > Eddsa-signatures draft > > David Benjamin's "simplification" proposal > > > > The deadline for scheduling is next Friday, so please speak up *now* if > you think > > we should ask for a one-hour slot. > > > > > > > > -- > > Senior Architect, Akamai Technologies > > IM: richsalz@jabber.at Twitter: RichSalz > > > > > > _______________________________________________ > > Curdle mailing list > > Curdle@ietf.org > > https://www.ietf.org/mailman/listinfo/curdle > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > --001a113f9b6aa1577905346c1567 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm not a draft author, but I plan to be at Berlin and= am happy to talk about my proposal there if that would be useful.

=
David

On Fri, Jun 3, 2016 at 1= 0:46 PM Jim Schaad <ietf@augustcellars.com> wrote:
Do we expect to see authors?=C2=A0 I believe that I am currently= waiting for
comments on the pkix eddsa draft, the cms eddsa draft is stuck on this one.=

I would really like to discuss how the ECDH and EdDSA algorithms are being<= br> identified in PKIX, in part because I want it to match what is being done i= n
other groups.=C2=A0 So I would appreciate a meeting.

Jim


> -----Original Message-----
> From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Salz, Rich
> Sent: Friday, June 03, 2016 8:15 AM
> To: curdle@ietf.o= rg
> Subject: [Curdle] Should we meet in Berlin?
>
> We are trying to decide if it makes sense to meet at the next IETF in<= br> Berlin.
>
> There are several threads on the mailing list, and if a good set of th= em
will be
> present, we can perhaps come to some good initial consensus (to be
verified, as
> always, on the mailing list afterwards)=C2=A0 The threads we see inclu= de:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Eddsa-sig= natures draft
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0David Ben= jamin's "simplification" proposal
>
> The deadline for scheduling is next Friday, so please speak up *now* i= f
you think
> we should ask for a one-hour slot.
>
>
>
> --
> Senior Architect, Akamai Technologies
> IM: richsalz@j= abber.at Twitter: RichSalz
>
>
> _______________________________________________
> Curdle mailing list
> Curdle@ietf.org
> https://www.ietf.org/mailman/listinfo/curdle
_______________________________________________
Curdle mailing list
Curdle@ietf.org https://www.ietf.org/mailman/listinfo/curdle
--001a113f9b6aa1577905346c1567-- From nobody Sat Jun 4 13:03:44 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84EB612B00E for ; Sat, 4 Jun 2016 13:03:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.727 X-Spam-Level: X-Spam-Status: No, score=-2.727 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EwTXGznJOU2U for ; Sat, 4 Jun 2016 13:03:40 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id 9736C12B022 for ; Sat, 4 Jun 2016 13:03:40 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 560F03F401E; Sat, 4 Jun 2016 20:03:39 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id 38F843F4001; Sat, 4 Jun 2016 20:03:39 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1465070619; bh=V1AAD7KTIgf8fJJo4CPl+7kS9fPjRH5JRImtfP6sF7I=; l=611; h=From:To:Date:References:In-Reply-To:From; b=GTptcephqd5iMCdyLdF8+Y5KSF4YMHq/1sa4OxsRPiFKVzAWDgVhnVSnFQRGArHxr xfQpwH0qs7/2yd4OmUzzPyezKRwx9yeUCrzfg5D8Wt1yN7zXIDILOsSmHaTD7OAkIN DBdnwxWOHD+KbSuoTdqxRGQPsPO/S5e2/VMJ+vew= Received: from email.msg.corp.akamai.com (usma1ex-cas2.msg.corp.akamai.com [172.27.123.31]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 35D1E1FC8D; Sat, 4 Jun 2016 20:03:39 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Sat, 4 Jun 2016 16:03:38 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1130.005; Sat, 4 Jun 2016 16:03:38 -0400 From: "Salz, Rich" To: Jim Schaad , "curdle@ietf.org" Thread-Topic: [Curdle] Should we meet in Berlin? Thread-Index: AdG9qpxMbwoVwVYWS3aL1Di+C6rOTgAgimwAABvQoSA= Date: Sat, 4 Jun 2016 20:03:37 +0000 Message-ID: References: <1398fd6401e24d5a848ca8380db47e3b@usma1ex-dag1mb1.msg.corp.akamai.com> <010201d1be0b$3f921130$beb63390$@augustcellars.com> In-Reply-To: <010201d1be0b$3f921130$beb63390$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.32.184] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Curdle] Should we meet in Berlin? X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jun 2016 20:03:42 -0000 > Do we expect to see authors? I believe that I am currently waiting for > comments on the pkix eddsa draft, the cms eddsa draft is stuck on this on= e. Any draft authors know they will be coming? =20 > I would really like to discuss how the ECDH and EdDSA algorithms are bein= g > identified in PKIX, in part because I want it to match what is being done= in > other groups. So I would appreciate a meeting. Being able to sync-up with other groups is an important part of meeting, of= course. It might be compelling enough by itself, or not. How many WG members will be going to Berlin? From nobody Mon Jun 6 02:40:33 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68B6F12B013 for ; Mon, 6 Jun 2016 02:40:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.426 X-Spam-Level: X-Spam-Status: No, score=-8.426 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id khFTwi2oxiwg for ; Mon, 6 Jun 2016 02:40:30 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A0F612B009 for ; Mon, 6 Jun 2016 02:40:30 -0700 (PDT) Received: from zimbra.rfc1925.org (calcifer.labs.nic.cz [217.31.192.138]) by mail.nic.cz (Postfix) with ESMTP id 0A04060ADC; Mon, 6 Jun 2016 11:40:28 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1465206028; bh=R4urZzwkvyQlbx4PrCbgdaoHMdL698Ltt7iWhoMQ1yU=; h=Date:From:To; b=W/ifIbPVou24qSZN312ZOYNXLAYy+kjr3sxlbG7F0aCWWigGlqtG+5e+O3BkqBYGD 9r/tFL7L/uNTcapo4jeAoywH2kI/JUoHkkTOalPzZfqXBZSzhMqEyyEA1AojORYDhG 2E/wusHEft2X6jqcnrzWo8/4NmStkAaWmCsLVqFU= Date: Mon, 6 Jun 2016 11:40:27 +0200 (CEST) From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= To: "Salz, Rich" Message-ID: <1396097222.5194.1465206027989.JavaMail.zimbra@nic.cz> In-Reply-To: References: <1398fd6401e24d5a848ca8380db47e3b@usma1ex-dag1mb1.msg.corp.akamai.com> <010201d1be0b$3f921130$beb63390$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [217.31.192.138] X-Mailer: Zimbra 8.6.0_GA_1178 (ZimbraWebClient - GC50 (Linux)/8.6.0_GA_1178) Thread-Topic: [Curdle] Should we meet in Berlin? Thread-Index: AdG9qpxMbwoVwVYWS3aL1Di+C6rOTgAgimwAABvQoSCvvoiQHw== X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: Jim Schaad , curdle@ietf.org Subject: Re: [Curdle] Should we meet in Berlin? X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2016 09:40:32 -0000 I will be in Berlin and I still want to know what the WG thinks about addin= g Contexts to the draft. O. -- Ond=C5=99ej Sur=C3=BD -- Technical Fellow -------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Milesovska 5, 130 00 Praha 3, Czech Republic mailto:ondrej.sury@nic.cz https://nic.cz/ -------------------------------------------- ----- Original Message ----- > From: "Salz, Rich" > To: "Jim Schaad" , curdle@ietf.org > Sent: Saturday, June 4, 2016 10:03:37 PM > Subject: Re: [Curdle] Should we meet in Berlin? >> Do we expect to see authors? I believe that I am currently waiting for >> comments on the pkix eddsa draft, the cms eddsa draft is stuck on this o= ne. >=20 > Any draft authors know they will be coming? >=20 >> I would really like to discuss how the ECDH and EdDSA algorithms are bei= ng >> identified in PKIX, in part because I want it to match what is being don= e in >> other groups. So I would appreciate a meeting. >=20 > Being able to sync-up with other groups is an important part of meeting, = of > course. It might be compelling enough by itself, or not. >=20 > How many WG members will be going to Berlin? >=20 > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle From nobody Mon Jun 6 08:28:20 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F4D212D802 for ; Mon, 6 Jun 2016 08:28:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GvgK2RsJ831k for ; Mon, 6 Jun 2016 08:28:17 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5698E12D800 for ; Mon, 6 Jun 2016 08:28:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 300E23002BA for ; Mon, 6 Jun 2016 11:28:15 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id zlhWsn1nPI6u for ; Mon, 6 Jun 2016 11:28:14 -0400 (EDT) Received: from [5.5.33.184] (vpn.snozzages.com [204.42.252.17]) by mail.smeinc.net (Postfix) with ESMTPSA id C13B7300055 for ; Mon, 6 Jun 2016 11:28:13 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: <010201d1be0b$3f921130$beb63390$@augustcellars.com> Date: Mon, 6 Jun 2016 11:28:14 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1398fd6401e24d5a848ca8380db47e3b@usma1ex-dag1mb1.msg.corp.akamai.com> <010201d1be0b$3f921130$beb63390$@augustcellars.com> To: "curdle@ietf.org" X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: Re: [Curdle] Should we meet in Berlin? X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2016 15:28:18 -0000 > I would really like to discuss how the ECDH and EdDSA algorithms are = being > identified in PKIX, in part because I want it to match what is being = done in > other groups. So I would appreciate a meeting. This needs to get sorted out. It has an impact on the CMS-related = drafts too. That said, we might be able to sort it out on the mail list before = Berlin. Russ From nobody Tue Jun 7 13:42:33 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B655012D7CE; Tue, 7 Jun 2016 13:42:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zy_rDrLELHXs; Tue, 7 Jun 2016 13:42:29 -0700 (PDT) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E045712D500; Tue, 7 Jun 2016 13:42:28 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id m124so130225499wme.1; Tue, 07 Jun 2016 13:42:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=+bra3JEvMnhB/sgtyAyZubDV8EvzhJUpWSFd7LVXIkU=; b=Wd6KFPF5hkKhW5WOQ8FOvQf8/GsBnTMffC/SgLMmfepNJYVp1dNCClJ3Diu8XuqIR5 6MDTWdG/VDc/2+4iCPU6n5/vjigIZ225ATB0zOwOAJHRnNgzwZDfzrOLGA+/INg3QeDq eAQInVJ3F3jPvJSrzYUYEDFoIYFuHqayaHD2bOr6EIVTyE62Zva7/hQe4BirG0oAwD2h enK4Ga7vK58hCZTohQsWjLgP1L3td/65rJSfZt3GqvPYa0xCqCt9Dr5r/sqkk1gWLQP9 yB4+jbWn003lyPurJqZaRsbP80aYDGzcp885FTSMnuhOqe4r3mWrvRjQZodNGiKNRJOX jrUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=+bra3JEvMnhB/sgtyAyZubDV8EvzhJUpWSFd7LVXIkU=; b=QMBvUVhWMs98q+H2z6oRPf1pkqzfqEif4z8n5hMT9KEx29ZfmKo804HuVpPmMNR+6O J0+J8tOykufGSc+AZiQiR/9ySR3C0mpRmlWVsR2xQp1Nj8yy09A+8nFlENbyM6Jshsv5 yvFO4aI/NK2Ki5B7+2Hy5uiFmBX/iqK1ZhyLedJioPyH9yKy85BoqXFkcMAGo5TnkXxH q3T50Je+qUM33SLMH9hlaGBY6iviUftojY4r8/3t9psf4ULi6+vkTaL2wdOctk4Brl58 rKXy8tluYw/if6d12CJmgK6OjqRntIr+vQp3w1ZOqG3gULmEfGV7DjY01+usKO3sJAKU sHyw== X-Gm-Message-State: ALyK8tJKt+wbDU/ekXrMWsDDuLCzv0kj8ptRID2S5hhSmZ1qZdHl3aC3dMDpvrGfu/CTa2UoW5jEAQ7093AFKg== X-Received: by 10.28.46.206 with SMTP id u197mr4304642wmu.70.1465332147312; Tue, 07 Jun 2016 13:42:27 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.194.86.42 with HTTP; Tue, 7 Jun 2016 13:42:26 -0700 (PDT) In-Reply-To: <103e01d1a6f6$f648b220$e2da1660$@augustcellars.com> References: <103e01d1a6f6$f648b220$e2da1660$@augustcellars.com> From: Daniel Migault Date: Tue, 7 Jun 2016 16:42:26 -0400 X-Google-Sender-Auth: yUdek2cDxKUMD5xshbOZRnb_UYg Message-ID: To: Jim Schaad Content-Type: multipart/alternative; boundary=001a114236981e5da40534b63a06 Archived-At: Cc: curdle@ietf.org, curdle-chairs Subject: Re: [Curdle] Call for adoption of draft-housley-cms-eddsa-signatures X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 20:42:30 -0000 --001a114236981e5da40534b63a06 Content-Type: text/plain; charset=UTF-8 Hi, The draft draft-housley-cms-eddsa-signature has been adopted as WG document. BR, Rich and Daniel On Thu, May 5, 2016 at 1:52 PM, Jim Schaad wrote: > I support adoption of this draft, I have reviewed it and will continue to > do so while it progresses. > > > > Jim > > > > > > *From:* Curdle [mailto:curdle-bounces@ietf.org] *On Behalf Of *Daniel > Migault > *Sent:* Thursday, May 05, 2016 7:36 AM > *To:* curdle@ietf.org > *Cc:* curdle-chairs > *Subject:* [Curdle] Call for adoption of > draft-housley-cms-eddsa-signatures > > > > Hi, > > This starts a Call for Adoption for "Use of EdDSA Signatures in the > Cryptographic Message Syntax (CMS)" > > The document is available here: > > https://www.ietf.org/id/draft-housley-cms-eddsa-signatures-00.txt > > Please review this draft to see if you think it is suitable for adoption > by CURLDE, and comment to the list, clearly stating your view. *Speak Up* > if you have strong opposition to this work. > > This call for adoption ends on May 20. > > BR, > Rich and Daniel > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > > --001a114236981e5da40534b63a06 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

The draft draft-housley-cms-eddsa-si= gnature has been adopted as WG document.


BR,
Ric= h and Daniel

On Thu, May 5, 2016 at 1:52 PM, Jim Schaad <ietf@augustcellars.com= > wrote:

I support ado= ption of this draft, I have reviewed it and will continue to do so while it= progresses.

=C2=A0<= u>

Jim

=C2=A0

=C2=A0

From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Daniel Migault
Sent: Thursday, May 05, 2016 7:36 AM
To: curdle@ietf.org<= br>Cc: curdle-chairs <curdle-chairs@ietf.org>
Subject: [Curdle]= Call for adoption of draft-housley-cms-eddsa-signatures

=C2=A0

Hi,

This starts a Call for Adoption for "Use of EdDSA Signatures in th= e Cryptographic Message Syntax (CMS)"

The document is available here:

https://www.ietf.org/id/draft-housley-cms-eddsa-signatures-00.txt<= u>

Please r= eview this draft to see if you think it is suitable for adoption by CURLDE,= and comment to the list, clearly stating your view.=C2=A0 *Speak Up* if yo= u have strong opposition to this work.

This call for adoption ends o= n May 20.

BR,
Rich and Daniel

=

_______________________________________________
Curdle mailing list
Curdle@ietf.org
https://www.ietf.org/mailman/listinfo/curdle


--001a114236981e5da40534b63a06-- From nobody Tue Jun 7 13:58:34 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DE0712D568 for ; Tue, 7 Jun 2016 13:58:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bs258cVPutOA for ; Tue, 7 Jun 2016 13:58:30 -0700 (PDT) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28A3B12D18A for ; Tue, 7 Jun 2016 13:58:30 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id v199so36493373wmv.0 for ; Tue, 07 Jun 2016 13:58:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=xY5t/JbOisPmcxzVb0KJ4WQU0P1Ogox7qcq2zFYV1Fk=; b=H/+asDF6uTuzqNsLI0x3qAG8XvIeszG+ezhfoTxtihJCTnUyL9Q1f5HdiFbaRC+RSB 7MH/AzOEKiEz+FCSafPSGQJn4MEOGkDS/29IlAOZMRSxjCqS9cdpBtNfHxoUvFDiI6vi c9HD05Aukg7d4Jwpza9K2lU2quPl4icOc9MiCEz8olGtcujhuQuBPJfG5okIjgFghHMm nq0i34AWATPytxReO4hrGFlhgDa5ITX87dfdutJh5Gf5RmdXaEfihQm1GN4tp4f2rnYq 6wivrr+1ponVSW90c8qHWA8GLC36VuHpeoodHYdMSC+iGKXxRAk6NWKRpIOQXf9QAJGR KWjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=xY5t/JbOisPmcxzVb0KJ4WQU0P1Ogox7qcq2zFYV1Fk=; b=lQVFVFCE5B9ZzbLfyfzz5Rko9fToHAWfg70/6b6nMelfaZpeGhrrlR7RibXgFqxlRy ZfI0gVPBWSi3x0FHxwgmPLcVSgkjBHQ63Ju541/rt7mggon8qLJQljNgDJpGE/xrn6zg OSfRY5clHlqZ9XkLWxTjmU9El0NQlSgR6MBkMVp3riq/p8rCiNIH9MmWcKx8c5kYiMqn Ios54jo+jNx+sN8GFVBZijn7QI/oG9xyYhnTzLZA2O3AGlE2vgaC+LYN+RjaVEbA7cQ8 nkrKlX6rLqicgfc3fn3WrbLpxdjSQIzNfPO0A3t+y2h6GxNYg6anJnsW4MW+maqMc2Jy q8HA== X-Gm-Message-State: ALyK8tJb+oEoolhaS99hcs5CoorkhP5f5zha7Ji89sYyyEbRBLuu0tp+Gq/RnN3R7uEPY2Xc+/xpniINcDS5Rw== X-Received: by 10.28.93.142 with SMTP id r136mr1379074wmb.70.1465333108678; Tue, 07 Jun 2016 13:58:28 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.194.86.42 with HTTP; Tue, 7 Jun 2016 13:58:28 -0700 (PDT) In-Reply-To: References: <1463470661.2914.4.camel@redhat.com> <1463647224.3558.14.camel@redhat.com> From: Daniel Migault Date: Tue, 7 Jun 2016 16:58:28 -0400 X-Google-Sender-Auth: -1XfS4IFlS2CAe665hx_i2ykZWE Message-ID: To: "curdle@ietf.org" Content-Type: multipart/alternative; boundary=001a114719346ba51b0534b673d1 Archived-At: Cc: Nikos Mavrogiannopoulos , David Benjamin Subject: Re: [Curdle] draft-ietf-curdle-pkix-00: a simplification proposal X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 20:58:32 -0000 --001a114719346ba51b0534b673d1 Content-Type: text/plain; charset=UTF-8 Hi, Do we have some consensus that having top-level OID would be better ? Please provide your opinion and let the WG know your thoughts so the document can be moved forward. BR, Daniel On Thu, May 19, 2016 at 10:41 AM, David Benjamin wrote: > On Thu, May 19, 2016 at 4:40 AM Nikos Mavrogiannopoulos > wrote: > >> On Tue, 2016-05-17 at 14:20 +0000, David Benjamin wrote: >> > I would actually advocate a different change. I sent this message >> > earlier: >> > https://www.ietf.org/mail-archive/web/curdle/current/msg00203.html >> > >> > Rather than use parameters, allocate new algorithm OIDs for >> > everything. I don't think we actually gain anything by exposing the >> > relations and parameterizations between these algorithms. When >> > implementing, they are great for sharing code. But when consuming, >> > exposing it makes parsing more complex, and it increases the risk of >> > reusing keys between related algorithms. We can get the best of both >> > worlds by separating entry-points and sharing internals. >> >> On your referenced message I am confused on the issue you raise on >> section 3. As I read section 3, I do not see anything that allows >> having id-ecPublicKey as an algorithm identifier for these keys. >> > > It's certainly possible I'm misunderstanding what section 3 was for. I was > kind of confused why there were two encodings. I was getting id-ecPublicKey > from: > > """ > Section 2.3.5 of [RFC3279] > describe ECDSA/ECDH public keys, specifying the id-ecPublicKey OID. > This OID has the associated EcpkParameters parameters structure, > which contains the namedCurve CHOICE. Here we introduce two [I think > this should be four] new OIDs > for use in the namedCurve field. > """ > > Anyway, if we go with top-level OIDs for everything, this is all moot. > > David > > >> Other than this part, you raise a very good point. It may be much >> simpler to use a common OID and move it up. Unlike the NIST curves the >> constructions we have under the eddsa OID umbrella are quite distinct. >> >> I was concerned about future extensibility and the fact that pureEdDSA >> and PrehashedEdDSA could be with separate algorithm OIDs, but after >> thinking it further, I think what you suggest is much neater, as having >> a single OID to identify scheme+curve will also restrict private keys >> to a single purpose which is a good thing. >> >> +1 >> >> regards, >> Nikos >> >> > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > > --001a114719346ba51b0534b673d1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Do we have some consensus= that having top-level OID would be better ? Please provide your opinion an= d let the WG know your thoughts so the document can be moved forward.
<= br>
BR,
Daniel

On Thu, May 19, 2016 at 10:41 AM, David Benjamin <davidben@chromium.org> wrote:
On Thu, May 19, 2016 at 4:40 AM Nikos Mavrogiannopoulos <nmav@redhat.com> wrot= e:
On Tue, 2016-05-17 at 14:20 +000= 0, David Benjamin wrote:
> I would actually advocate a different change. I sent this message
> earlier:
> https://www.ietf.org/mail-arc= hive/web/curdle/current/msg00203.html
>
> Rather than use parameters, allocate new algorithm OIDs for
> everything. I don't think we actually gain anything by exposing th= e
> relations and parameterizations between these algorithms. When
> implementing, they are great for sharing code. But when consuming,
> exposing it makes parsing more complex, and it increases the risk of > reusing keys between related algorithms. We can get the best of both > worlds by separating entry-points and sharing internals.

On your referenced message I am confused on the issue you raise on
section 3. As I read section 3, I do not see anything that allows
having=C2=A0id-ecPublicKey as an algorithm identifier for these keys.

It's certainly possible I'm m= isunderstanding what section 3 was for. I was kind of confused why there we= re two encodings. I was getting=C2=A0id-ecPublicKey from:

"""
=C2=A0 =C2=A0Section 2.3.5 of [RF= C3279]
=C2=A0 =C2=A0describe ECDSA/ECDH public keys, specifying t= he id-ecPublicKey OID.
=C2=A0 =C2=A0This OID has the associated E= cpkParameters parameters structure,
=C2=A0 =C2=A0which contains t= he namedCurve CHOICE.=C2=A0 Here we introduce two [I think this should be f= our] new OIDs
=C2=A0 =C2=A0for use in the namedCurve field.
&q= uot;""

Anyway, if we go with top-level OIDs for everything= , this is all moot.

David
=C2= =A0
Other than this part, you raise a very good point. It may be much
simpler to use a common OID and move it up. Unlike the NIST curves the
constructions we have under the eddsa OID umbrella are quite distinct.

I was concerned about future extensibility and the fact that pureEdDSA
and PrehashedEdDSA could be with separate algorithm OIDs, but after
thinking it further, I think what you suggest is much neater, as having
a single OID to identify scheme+curve will also restrict private keys
to a single purpose which is a good thing.

+1

regards,
Nikos


_______________________________________________
Curdle mailing list
Curdle@ietf.org
https://www.ietf.org/mailman/listinfo/curdle


--001a114719346ba51b0534b673d1-- From nobody Tue Jun 7 14:47:43 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEFCA12D5D6 for ; Tue, 7 Jun 2016 14:47:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=briansmith-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dRLJ4SINHNWv for ; Tue, 7 Jun 2016 14:47:41 -0700 (PDT) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD73512D5B4 for ; Tue, 7 Jun 2016 14:47:40 -0700 (PDT) Received: by mail-it0-x236.google.com with SMTP id z189so109585825itg.0 for ; Tue, 07 Jun 2016 14:47:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=briansmith-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=1g9WrkIOtIe+vBxYoelMUGTprdm1MvhIsDILSsdKEvg=; b=o0/ihXOOWoucIZiv51wkCwyfVsLDTyZuXoam1sHfia/0w7i+MQRJo2rD/O85SMqeFa B/g/MUg1QugL/N9UDe0vaTd2O/uHewT0XYVphJrcHU4u2nQIEJpd0xvS2XbU2isag/6q Lw/PYSMOYjSlIoMXyhQz0HkycWr7w8wi4+6MAXL6iE3v/UhhD1MDcrnv0+RGTCKxqDhB sKh642/WLlE0vNYLLhZPCslUNGM5rRPAAd2cxlpDFmhmcQC+8jLjL5TcQVm13LbLdW1Z NRFAQg+cT9hB3m9qSbZqBHnVR7/k/sC5aHcn8C4RtjJ9JqPvJq9pAwNQ8HROn/7isS+B iEXw== 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; bh=1g9WrkIOtIe+vBxYoelMUGTprdm1MvhIsDILSsdKEvg=; b=edUr0XGfNiXnQe3P+goeY07iN/Sp/pQd/T8YC4lspe0pdEzTV9pwRDF4h6ZqpU9Rbv eYn9EbEZl9GHP5f+lsoYX5ztvJmJCu9odtw1H9zboGk78eNZ+sl/3irLSjKwUhWBm6u3 TBeyZCNIvBru3g5wl8wrVl4a5SCxrFR5L1c2DMePfwDwqzbqGmWJI9oYK3+0vx5OuvpD Tu8upr0XWYwGqvtpVgbJkFTtAiFeQvuKKNAUNquubQZwT2DEUAgfkLA9cBfPIZzpy9BV dYxfStfjh505ScrjelVLv+HhdR+jqfMN0GznSIp845WKZQP6WldBnBlYuUH19Xm43V38 G5hA== X-Gm-Message-State: ALyK8tK3P2KFa+3hSThYjam1kPMnajc8WpDZCC1x1m5RqgxZpbLOTSLCvJcy0SrHa2dl8GNRf19YlGglXbYOkg== MIME-Version: 1.0 X-Received: by 10.107.10.206 with SMTP id 75mr3144032iok.51.1465336060246; Tue, 07 Jun 2016 14:47:40 -0700 (PDT) Received: by 10.36.137.87 with HTTP; Tue, 7 Jun 2016 14:47:40 -0700 (PDT) In-Reply-To: References: <1463470661.2914.4.camel@redhat.com> <1463647224.3558.14.camel@redhat.com> Date: Tue, 7 Jun 2016 11:47:40 -1000 Message-ID: From: Brian Smith To: Daniel Migault Content-Type: multipart/alternative; boundary=001a113f89b45913ad0534b7234f Archived-At: Cc: Nikos Mavrogiannopoulos , "curdle@ietf.org" , David Benjamin Subject: Re: [Curdle] draft-ietf-curdle-pkix-00: a simplification proposal X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 21:47:42 -0000 --001a113f89b45913ad0534b7234f Content-Type: text/plain; charset=UTF-8 Daniel Migault wrote: > Do we have some consensus that having top-level OID would be better ? > Please provide your opinion and let the WG know your thoughts so the > document can be moved forward. > I assume you are referring to this proposal from David Benjamin: > I'd suggest four separate parameter-less algorithm OIDs for ed25519, > ed25519ph, ed448, and ed448ph. (Of course, specify whether the parameters > are omitted or NULL.) Likewise, if anyone wants X25519 or X448 > certificates, allocate those too. I very much support this proposal. It's best to keep things simply by not using parameters. The spec. should say that the parameters are omitted, because encoding a NULL is just wasting two bytes for no reason. I would love to see a new draft with this proposal incorporated. Also, I would like to see some test vectors for Ed25519 (non-prehash). As soon as I get those test vectors then I will add support for Ed25519 to my implementation, webpki [1] so that others can use it for interop testing. [1] https://github.com/briansmith/webpki Cheers, Brian --001a113f89b45913ad0534b7234f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dani= el Migault <daniel.migault@ericsson.com> wrote:
Do we have some consensus= that having top-level OID would be better ? Please provide your opinion an= d let the WG know your thoughts so the document can be moved forward.=C2=A0=

I assume you are r= eferring to this proposal from David Benjamin:

> =C2=A0I'd suggest fo= ur separate parameter-less algorithm OIDs for ed25519,
> ed25519ph, ed448, and ed448ph. (Of course, s= pecify whether the parameters
> are omitted or NULL.)=C2=A0Likewise, if anyone wa= nts X25519 or X448
> certificates, allocat= e those too.

I very much support this proposal. It's best to keep things simp= ly by not using parameters. The spec. should say that the parameters are om= itted, because encoding a NULL is just wasting two bytes for no reason.

I would love = to see a new draft with this proposal incorporated.

Also, I would like to see some te= st vectors for Ed25519 (non-prehash). As soon as I get those test vectors t= hen I will add support for Ed25519 to my implementation, webpki [1] so that= others can use it for interop testing.

<= /span>
Cheers,
List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 22:05:52 -0000 --001a11400eaa4096180534b764f2 Content-Type: text/plain; charset=UTF-8 I proposal that the spec be updated to say that certificates with basicConstraints.cA = TRUE MUST NOT use Ed25519ph or Ed448ph public keys. The non-prehash variants are more misuse-resistant than the prehash variants, which is a particularly important property for CA certificates. More generally, in practice it seems likely that Ed25519 (non-prehash) will be much more ubiquitous than the prehash variants, as the non-prehash variants are already being used in (non-IETF) protocols that are deployed. I have seen very little support for the prehash variants, and also very little need to support for prehash variants. So, for example, my implementation doesn't support the prehash variants at all. Cheers, Brian -- https://briansmith.org/ --001a11400eaa4096180534b764f2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I proposal that the spec be updated to say that certificat= es with basicConstraints.cA =3D TRUE MUST NOT use Ed25519ph or Ed448ph publ= ic keys.

The non-prehash variants are more misuse-resist= ant than the prehash variants, which is a particularly important property f= or CA certificates.

More generally, in practice it= seems likely that Ed25519 (non-prehash) will be much more ubiquitous than = the prehash variants, as the non-prehash variants are already being used in= (non-IETF) protocols that are deployed. I have seen very little support fo= r the prehash variants, and also very little need to support for prehash va= riants. So, for example, my implementation doesn't support the prehash = variants at all.

Cheers,
--001a11400eaa4096180534b764f2-- From nobody Tue Jun 7 15:28:17 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E06912D849 for ; Tue, 7 Jun 2016 15:28:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.425 X-Spam-Level: X-Spam-Status: No, score=-3.425 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19zBz5L0FnIc for ; Tue, 7 Jun 2016 15:28:13 -0700 (PDT) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C37412D83D for ; Tue, 7 Jun 2016 15:28:13 -0700 (PDT) Received: by mail-it0-x229.google.com with SMTP id n126so21227641itd.1 for ; Tue, 07 Jun 2016 15:28:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4pLUbI3c2bEW0Gq7WbWjwqFvUHYJBfkrCNgU1U1+bPw=; b=eie5CtZe+CHF6Ps12WCiNmXyQC1s+PhiFblV0p25V1fMlKSQq998GTPwAfg8axmNgr Wr7tjyjNAttaAP/JXYuP8nGgj5CN+Vnty0tIv1VQ57V/k/kt3PkA/NtBNe6ZcyElJXyU mr/CPpJl2xTcMzbsbXuUsrX5ZTIxcrEAhuDp0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4pLUbI3c2bEW0Gq7WbWjwqFvUHYJBfkrCNgU1U1+bPw=; b=fKxJ27HrOJmJHO93PeukHAcemKGxA6tCrShfYyQiiPofTg+lm+r/EQduOqp/+Zb1CK WihdsAHZgXVmSYb8BnqxteR/YeHjhRN8cgjadWPVgb1apjEfquOyuGvCCd060x6phRxR rDINwBgbI3Ayh8JQqa3fR5BRPbJURmIM6E81hllY7UYpXfZkjrlTDjE0/2VqsZHB95Zf vhZi2Nc6rT85zzSj2I9MtJEWUjdl6WW89s7IN6IMK18jX7JqjIoVRLTrti7vv+VKeVkQ I/OzpRk6SsZRhhQUThp/WP1ssjsUZPcv879m5ynoHapTBo5hsNOSiOGmKti4Xk+J2F58 HNFw== X-Gm-Message-State: ALyK8tKCWLxzBqXR9IcInNqmGQQuXJHfm4omJKOA/MJoLq17crd/GXLvjEElNRzeJAHB6/634rFqbyEyhzD7qQML X-Received: by 10.36.227.131 with SMTP id d125mr3684771ith.18.1465338492655; Tue, 07 Jun 2016 15:28:12 -0700 (PDT) MIME-Version: 1.0 References: <1463470661.2914.4.camel@redhat.com> <1463647224.3558.14.camel@redhat.com> In-Reply-To: From: David Benjamin Date: Tue, 07 Jun 2016 22:28:02 +0000 Message-ID: To: Brian Smith , Daniel Migault Content-Type: multipart/alternative; boundary=94eb2c111620551c6c0534b7b498 Archived-At: Cc: Nikos Mavrogiannopoulos , "curdle@ietf.org" Subject: Re: [Curdle] draft-ietf-curdle-pkix-00: a simplification proposal X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 22:28:15 -0000 --94eb2c111620551c6c0534b7b498 Content-Type: text/plain; charset=UTF-8 On Tue, Jun 7, 2016 at 5:47 PM Brian Smith wrote: > Daniel Migault wrote: > >> Do we have some consensus that having top-level OID would be better ? >> Please provide your opinion and let the WG know your thoughts so the >> document can be moved forward. >> > > I assume you are referring to this proposal from David Benjamin: > > > I'd suggest four separate parameter-less algorithm OIDs for ed25519, > > ed25519ph, ed448, and ed448ph. (Of course, specify whether the parameters > > are omitted or NULL.) Likewise, if anyone wants X25519 or X448 > > certificates, allocate those too. > > I very much support this proposal. It's best to keep things simply by not > using parameters. The spec. should say that the parameters are omitted, > because encoding a NULL is just wasting two bytes for no reason. > Omitting sounds good to me. I doubt matching RSA in including a NULL would actually result in code savings for anyone, which is the only argument I can see for it. Unless we somehow end up losing id-ecPublicKey and id-RSASSA-PSS before id-rsaEncryption. If this proposal does end up being the consensus, I would suggest afterwards there should be an even stronger document to deprecate the parameters field in AlgorithmIdentifier altogether for new things. I've never seen a use that, in my opinion, didn't turn out to be a mistake. > I would love to see a new draft with this proposal incorporated. > Another question is what to do with the signature algorithms. I could imagine doing: a) id-EdDSASignature as in the draft b) Use the same OIDs as the keys c) Define a parallel set of OIDs I don't like (a) for the same reasons I don't like the keys sharing OIDs. It's also nice to be able to determine the signature algorithm used without the issuer on hand. (I've more than once had difficulties looking through ECDSA certs in the CT log because of this.) I don't really care between (b) and (c). RSA-PSS uses the same OID for both, which suggests (b). I suppose (c) avoids a "type mismatch" in OIDs, but I'm not sure that matters. > Also, I would like to see some test vectors for Ed25519 (non-prehash). As > soon as I get those test vectors then I will add support for Ed25519 to my > implementation, webpki [1] so that others can use it for interop testing. > > [1] https://github.com/briansmith/webpki > > Cheers, > Brian > --94eb2c111620551c6c0534b7b498 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Jun 7,= 2016 at 5:47 PM Brian Smith <brian@briansmith.org> wrote:
Daniel Migault <daniel.migault@ericsson.com>= wrote:
Do we ha= ve some consensus that having top-level OID would be better ? Please provid= e your opinion and let the WG know your thoughts so the document can be mov= ed forward.=C2=A0

=
I assume you are referring to this proposal from David Benjami= n:

> =C2=A0I'd suggest four separate parameter-less algorithm OIDs fo= r ed25519,
> ed25519ph, ed= 448, and ed448ph. (Of course, specify whether the parameters
> are omitted or NULL.)=C2=A0Likewise, if anyone wants X25519 or X448
> certificates, allocate those too.

I very much support this proposal. It= 's best to keep things simply by not using parameters. The spec. should= say that the parameters are omitted, because encoding a NULL is just wasti= ng two bytes for no reason.

Omitting = sounds good to me. I doubt matching RSA in including a NULL would actually = result in code savings for anyone, which is the only argument I can see for= it. Unless we somehow end up losing id-ecPublicKey and id-RSASSA-PSS befor= e id-rsaEncryption.

If this proposal does end up b= eing the consensus, I would suggest afterwards there should be an even stro= nger document to deprecate the parameters field in AlgorithmIdentifier alto= gether for new things. I've never seen a use that, in my opinion, didn&= #39;t turn out to be a mistake.
=C2=A0
I would love to see a new draft with this proposal incorporated.

Another question is what to do wit= h the signature algorithms. I could imagine doing:
a)=C2=A0id-EdD= SASignature as in the draft
b) Use the same OIDs as the keys
c) Define a parallel set of OIDs

I don't= like (a) for the same reasons I don't like the keys sharing OIDs. It&#= 39;s also nice to be able to determine the signature algorithm used without= the issuer on hand. (I've more than once had difficulties looking thro= ugh ECDSA certs in the CT log because of this.)

I = don't really care between (b) and (c). RSA-PSS uses the same OID for bo= th, which suggests (b). I suppose (c) avoids a "type mismatch" in= OIDs, but I'm not sure that matters.
=C2=A0
Also, I would lik= e to see some test vectors for Ed25519 (non-prehash). As soon as I get thos= e test vectors then I will add support for Ed25519 to my implementation, we= bpki [1] so that others can use it for interop testing.


Che= ers,
Brian
--94eb2c111620551c6c0534b7b498-- From nobody Tue Jun 7 15:37:59 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B62E212D8BF for ; Tue, 7 Jun 2016 15:37:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=briansmith-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N0sxsRDTbwXa for ; Tue, 7 Jun 2016 15:37:56 -0700 (PDT) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8170A12D8BB for ; Tue, 7 Jun 2016 15:37:56 -0700 (PDT) Received: by mail-it0-x231.google.com with SMTP id h190so35680067ith.1 for ; Tue, 07 Jun 2016 15:37:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=briansmith-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=8h2KKrCy29bmk/Rm+msZR3bNYePg+L2jShh3JBXALYw=; b=lfV/f2Y0M4HLCw1NdkyQrX9yOc1o88vHeOcvaiiv55Dudlo0yc2ddhF7/SMBPJv6qm qxLXf0coSM5+kaUTd1HUigDoeURZ050SYkU5X0OVjHnGoPbiElECZunaEFUSRmNwVoxZ 2Dmt1byOZwsBPDAYB4jmRn1JPbbT0t8lGNhTMfpc1HhCH1m9FtVuURgxJrR6Eyycmg06 PR/WVx1DKsPqSCINJUkWp3/yTRGmz7IKc7GIWixvG9KYsOpT4hvxOObEr0JOsvsLOgfO CYTXHMSilr4UiUXeg68GVQodM0YVcASsdib96pMjgAErCz20B51QkDsc8wDIIsOvx16L /+gg== 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; bh=8h2KKrCy29bmk/Rm+msZR3bNYePg+L2jShh3JBXALYw=; b=SnzwbyQUuv3k03l3ika15jOLSpBJKSbZA1XSca/X+PZsL3+P5ndipPvcRyuGfmBmf1 bL/YRgskvM2jIqYR9hJccJZOWV3zcbPorfcbSbKRJ0sybjwGUc7yRCGwQnSBy3k/2VRN IXEVan5qMrvLWDwBaGMr7wc11fCmrDy6Qts1Y37G+tct0EYqVKyKqy98KZYh9XraGF5A Wj+VCxcLBW0r3ovVk5nbGhcs/DWYCQkwuIA+0ZCuUpYGKeMuLe1mFyaonYM5PSxGc/Kn ZRM3Qt7U0dZDDKLSMivaUi+Ur9ghMyHoU9WTFM2SRKoT9+wHHuhlchwEwCzFLbKx7EY8 /KWg== X-Gm-Message-State: ALyK8tJiD36UTQNOr/MT9fLNX8zUhhe0CqeO2vXc2DPUrGwiFDvkdYvc/ysGmW106Om+uXbb7ZRT549xMHDr+w== MIME-Version: 1.0 X-Received: by 10.107.34.213 with SMTP id i204mr3279337ioi.39.1465339075828; Tue, 07 Jun 2016 15:37:55 -0700 (PDT) Received: by 10.36.137.87 with HTTP; Tue, 7 Jun 2016 15:37:55 -0700 (PDT) In-Reply-To: References: <1463470661.2914.4.camel@redhat.com> <1463647224.3558.14.camel@redhat.com> Date: Tue, 7 Jun 2016 12:37:55 -1000 Message-ID: From: Brian Smith To: David Benjamin Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Nikos Mavrogiannopoulos , Daniel Migault , "curdle@ietf.org" Subject: Re: [Curdle] draft-ietf-curdle-pkix-00: a simplification proposal X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 22:37:58 -0000 David Benjamin wrote: > Brian Smith wrote: > >> I would love to see a new draft with this proposal incorporated. > > Another question is what to do with the signature algorithms. I could > imagine doing: > a) id-EdDSASignature as in the draft > b) Use the same OIDs as the keys > c) Define a parallel set of OIDs > I don't really care between (b) and (c). RSA-PSS uses the same OID for both, > which suggests (b). I suppose (c) avoids a "type mismatch" in OIDs, but I'm > not sure that matters. I suggest using the same OID for both, as RSA-PSS does. Besides being consistent with RSS-PSS and simpler, it would also improve compression when compressing certificate chains (using algorithms like Brotli). Cheers, Brian From nobody Tue Jun 7 15:40:25 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B3E412D618 for ; Tue, 7 Jun 2016 15:40:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.899 X-Spam-Level: X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bkty8S1125pp for ; Tue, 7 Jun 2016 15:40:22 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3859812D62E for ; Tue, 7 Jun 2016 15:33:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 181F43002B2 for ; Tue, 7 Jun 2016 18:32:59 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id sDTyL7OXy2IC for ; Tue, 7 Jun 2016 18:32:57 -0400 (EDT) Received: from [172.16.1.2] (unknown [209.94.245.211]) by mail.smeinc.net (Postfix) with ESMTPSA id 34232300229; Tue, 7 Jun 2016 18:32:57 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_F767FA25-BBFB-4915-B0CA-C225188BDE60" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: Date: Tue, 7 Jun 2016 18:00:38 -0400 Message-Id: References: <1463470661.2914.4.camel@redhat.com> <1463647224.3558.14.camel@redhat.com> To: Daniel Migault X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: "curdle@ietf.org" Subject: Re: [Curdle] draft-ietf-curdle-pkix-00: a simplification proposal X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 22:40:24 -0000 --Apple-Mail=_F767FA25-BBFB-4915-B0CA-C225188BDE60 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I think we have two choices, neither of them is in draft-curdle-pkix-00. Either we define eight object identifiers for the named curves for use = with id-ecPublicKey: id-Curve25519 id-Curve448 id-Curve25519ph id-Curve448ph id-ed25519 id-ed25519ph id-ed448 id-ed448ph or we define eight object identifiers that are used as algorithm = identifiers: id-ecPublicKeyCurve25519 id-ecPublicKeyCurve448 id-ecPublicKeyCurve25519ph id-ecPublicKeyCurve448ph id-ecPublicKeyED25519 id-ecPublicKeyED25519ph id-ecPublicKeyED448 id-ecPublicKeyED448ph I can live with either one, but I would like to see us choose soon. Russ On Jun 7, 2016, at 4:58 PM, Daniel Migault = wrote: > Hi,=20 >=20 > Do we have some consensus that having top-level OID would be better ? = Please provide your opinion and let the WG know your thoughts so the = document can be moved forward.=20 >=20 > BR,=20 > Daniel >=20 > On Thu, May 19, 2016 at 10:41 AM, David Benjamin = wrote: > On Thu, May 19, 2016 at 4:40 AM Nikos Mavrogiannopoulos = wrote: > On Tue, 2016-05-17 at 14:20 +0000, David Benjamin wrote: > > I would actually advocate a different change. I sent this message > > earlier: > > https://www.ietf.org/mail-archive/web/curdle/current/msg00203.html > > > > Rather than use parameters, allocate new algorithm OIDs for > > everything. I don't think we actually gain anything by exposing the > > relations and parameterizations between these algorithms. When > > implementing, they are great for sharing code. But when consuming, > > exposing it makes parsing more complex, and it increases the risk of > > reusing keys between related algorithms. We can get the best of both > > worlds by separating entry-points and sharing internals. >=20 > On your referenced message I am confused on the issue you raise on > section 3. As I read section 3, I do not see anything that allows > having id-ecPublicKey as an algorithm identifier for these keys. >=20 > It's certainly possible I'm misunderstanding what section 3 was for. I = was kind of confused why there were two encodings. I was getting = id-ecPublicKey from: >=20 > """ > Section 2.3.5 of [RFC3279] > describe ECDSA/ECDH public keys, specifying the id-ecPublicKey OID. > This OID has the associated EcpkParameters parameters structure, > which contains the namedCurve CHOICE. Here we introduce two [I = think this should be four] new OIDs > for use in the namedCurve field. > """ >=20 > Anyway, if we go with top-level OIDs for everything, this is all moot. >=20 > David > =20 > Other than this part, you raise a very good point. It may be much > simpler to use a common OID and move it up. Unlike the NIST curves the > constructions we have under the eddsa OID umbrella are quite distinct. >=20 > I was concerned about future extensibility and the fact that pureEdDSA > and PrehashedEdDSA could be with separate algorithm OIDs, but after > thinking it further, I think what you suggest is much neater, as = having > a single OID to identify scheme+curve will also restrict private keys > to a single purpose which is a good thing. >=20 > +1 >=20 > regards, > Nikos >=20 >=20 > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle >=20 >=20 > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle --Apple-Mail=_F767FA25-BBFB-4915-B0CA-C225188BDE60 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
I = think we have two choices, neither of them is in = draft-curdle-pkix-00.

Either we define eight = object identifiers for the named curves for use with = id-ecPublicKey:

      =  id-Curve25519
      =  id-Curve448
      =  id-Curve25519ph
      =  id-Curve448ph
      =  id-ed25519
      =  id-ed25519ph
      =  id-ed448
      =  id-ed448ph

or we define eight object = identifiers that are used as algorithm = identifiers:

      =  id-ecPublicKeyCurve25519
      =  id-ecPublicKeyCurve448
      =  id-ecPublicKeyCurve25519ph
      =  id-ecPublicKeyCurve448ph
      =  id-ecPublicKeyED25519
      =  id-ecPublicKeyED25519ph
      =  id-ecPublicKeyED448
      =  id-ecPublicKeyED448ph

I can live = with either one, but I would like to see us choose = soon.

Russ



On Jun 7, 2016, at 4:58 PM, Daniel Migault <daniel.migault@ericsson.com> wrote:

Hi,

Do we = have some consensus that having top-level OID would be better ? Please = provide your opinion and let the WG know your thoughts so the document = can be moved forward.

BR,
Daniel

On Thu, May 19, = 2016 at 10:41 AM, David Benjamin <davidben@chromium.org> = wrote:
On Thu, May 19, = 2016 at 4:40 AM Nikos Mavrogiannopoulos <nmav@redhat.com> = wrote:
On Tue, 2016-05-17 at = 14:20 +0000, David Benjamin wrote:
> I would actually advocate a different change. I sent this = message
> earlier:
> https://www.ietf.org/mail-archive/web/curdle/current/msg= 00203.html
>
> Rather than use parameters, allocate new algorithm OIDs for
> everything. I don't think we actually gain anything by exposing = the
> relations and parameterizations between these algorithms. When
> implementing, they are great for sharing code. But when = consuming,
> exposing it makes parsing more complex, and it increases the risk = of
> reusing keys between related algorithms. We can get the best of = both
> worlds by separating entry-points and sharing internals.

On your referenced message I am confused on the issue you raise on
section 3. As I read section 3, I do not see anything that allows
having id-ecPublicKey as an algorithm identifier for these = keys.

It's certainly possible = I'm misunderstanding what section 3 was for. I was kind of confused why = there were two encodings. I was getting id-ecPublicKey = from:

"""
   Section = 2.3.5 of [RFC3279]
   describe ECDSA/ECDH public = keys, specifying the id-ecPublicKey OID.
   This OID = has the associated EcpkParameters parameters structure,
  =  which contains the namedCurve CHOICE.  Here we introduce two = [I think this should be four] new OIDs
   for use in = the namedCurve field.
"""

Anyway, if we go with top-level OIDs = for everything, this is all moot.

David
 
Other than this part, you raise a very good point. It may be much
simpler to use a common OID and move it up. Unlike the NIST curves = the
constructions we have under the eddsa OID umbrella are quite = distinct.

I was concerned about future extensibility and the fact that = pureEdDSA
and PrehashedEdDSA could be with separate algorithm OIDs, but after
thinking it further, I think what you suggest is much neater, as = having
a single OID to identify scheme+curve will also restrict private = keys
to a single purpose which is a good thing.

+1

regards,
Nikos


_______________________________________________
Curdle mailing list
Curdle@ietf.org
https://www.ietf.org/mailman/listinfo/curdle


_______________________________________________
Curdle mailing = list
Curdle@ietf.org
https://www.ietf.or= g/mailman/listinfo/curdle

= --Apple-Mail=_F767FA25-BBFB-4915-B0CA-C225188BDE60-- From nobody Tue Jun 7 15:52:25 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 157C112D62E for ; Tue, 7 Jun 2016 15:52:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.425 X-Spam-Level: X-Spam-Status: No, score=-3.425 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uIYIQ7UEgUmt for ; Tue, 7 Jun 2016 15:52:22 -0700 (PDT) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1C1912D51D for ; Tue, 7 Jun 2016 15:52:22 -0700 (PDT) Received: by mail-it0-x22d.google.com with SMTP id h190so36139234ith.1 for ; Tue, 07 Jun 2016 15:52:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZOjKx9He/k4D2eRcVNI1DwS5eDzrKYjxLhu+UPkMd3s=; b=O21hvedTEbd7R7EppkYdDL9wfCKvKx5oOIYjrjhe71ivfd6SJKQtr+yV3LrvLrHdAc FZ9VnQS36KmPGm0LlB7CEm1SFhU4SQ/Zmuny9gzJhKd3V1wu5rJW1Y20RotAlJX8PF7z /cVHCugvn5ZJrB4Y4jvtb/joaLOIMDoOR00Nc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ZOjKx9He/k4D2eRcVNI1DwS5eDzrKYjxLhu+UPkMd3s=; b=Joqqhy9lcmq/oJW7EJwv6gvrjIyrAh8YPop3LWNUunzrcJP8flWL5ggT/KxD+OQJO9 rLMYhvWaUGmmpbAfe3di9gVWxWqFKDwzbyoY9iqla9DZYXnGoX6zeRyyf4Wg78e0MvtQ VL5FvIVWYhmCrCVHcwutAYc+/tbvGIx5Qkwu1w22B4a2nAtfHrKx2RqGyjg6YIqGYhlY eBjFNoqBnTNqFqdlqXyvLjX+ghXHUKJM05UsguzOjS7yszaS2Ypts/11hcYFVp1CEcTJ t7ZWNtEKWsDgzbCOOyVSo4FqyYLmyXYNz2WVzKXzYtC9/QClKdU1DMULNHELPT+wwYGF rxaQ== X-Gm-Message-State: ALyK8tLezmOlOeI4QT+nkgJS0Ay0ulCDKgJZFuIvRI8uoaQtw0wPqwHskAGp/UBnTfqlBeknClsRfbbmCDG7QnEP X-Received: by 10.36.101.74 with SMTP id u71mr3714441itb.92.1465339941803; Tue, 07 Jun 2016 15:52:21 -0700 (PDT) MIME-Version: 1.0 References: <1463470661.2914.4.camel@redhat.com> <1463647224.3558.14.camel@redhat.com> In-Reply-To: From: David Benjamin Date: Tue, 07 Jun 2016 22:52:11 +0000 Message-ID: To: Russ Housley , Daniel Migault Content-Type: multipart/alternative; boundary=001a1145bcf2b5276f0534b80aa7 Archived-At: Cc: "curdle@ietf.org" Subject: Re: [Curdle] draft-ietf-curdle-pkix-00: a simplification proposal X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 22:52:25 -0000 --001a1145bcf2b5276f0534b80aa7 Content-Type: text/plain; charset=UTF-8 On Tue, Jun 7, 2016 at 6:40 PM Russ Housley wrote: > I think we have two choices, neither of them is in draft-curdle-pkix-00. > > Either we define eight object identifiers for the named curves for use > with id-ecPublicKey: > > id-Curve25519 > id-Curve448 > id-Curve25519ph > id-Curve448ph > Were you thinking that id-Curve25519 refer to anything using the curve or specifically the Diffie-Hellman primitive? If the latter, I would suggest X25519 (for consistency with RFC 7748) and dropping the "ph" ones since those are only in EdDSA. If the former, it seems redundant with the EdDSA OIDs below. id-ed25519 > id-ed25519ph > id-ed448 > id-ed448ph > > or we define eight object identifiers that are used as algorithm > identifiers: > > id-ecPublicKeyCurve25519 > id-ecPublicKeyCurve448 > id-ecPublicKeyCurve25519ph > id-ecPublicKeyCurve448ph > id-ecPublicKeyED25519 > id-ecPublicKeyED25519ph > id-ecPublicKeyED448 > id-ecPublicKeyED448ph > Nit: I would suggest dropping the ecPublicKey prefix and s/ED/Ed/ to be consistent with the usual styling. Also the same "X" vs "Curve" and "ph" comments above. So: id-X25519 id-X448 id-Ed25519 id-Ed25519ph id-Ed448 id-Ed448ph (Or maybe all lowercase? Between id-rsaEncryption and id-RSASSA-PSS, I'm unclear on whether OIDs are supposed to be lowercase. Anyway...) > I can live with either one, but I would like to see us choose soon. > (I obviously have a preference, but I've argued for it elsewhere. :-) ) > Russ > > > > On Jun 7, 2016, at 4:58 PM, Daniel Migault > wrote: > > Hi, > > Do we have some consensus that having top-level OID would be better ? > Please provide your opinion and let the WG know your thoughts so the > document can be moved forward. > > BR, > Daniel > > On Thu, May 19, 2016 at 10:41 AM, David Benjamin > wrote: > >> On Thu, May 19, 2016 at 4:40 AM Nikos Mavrogiannopoulos >> wrote: >> >>> On Tue, 2016-05-17 at 14:20 +0000, David Benjamin wrote: >>> > I would actually advocate a different change. I sent this message >>> > earlier: >>> > https://www.ietf.org/mail-archive/web/curdle/current/msg00203.html >>> > >>> > Rather than use parameters, allocate new algorithm OIDs for >>> > everything. I don't think we actually gain anything by exposing the >>> > relations and parameterizations between these algorithms. When >>> > implementing, they are great for sharing code. But when consuming, >>> > exposing it makes parsing more complex, and it increases the risk of >>> > reusing keys between related algorithms. We can get the best of both >>> > worlds by separating entry-points and sharing internals. >>> >>> On your referenced message I am confused on the issue you raise on >>> section 3. As I read section 3, I do not see anything that allows >>> having id-ecPublicKey as an algorithm identifier for these keys. >>> >> >> It's certainly possible I'm misunderstanding what section 3 was for. I >> was kind of confused why there were two encodings. I was >> getting id-ecPublicKey from: >> >> """ >> Section 2.3.5 of [RFC3279] >> describe ECDSA/ECDH public keys, specifying the id-ecPublicKey OID. >> This OID has the associated EcpkParameters parameters structure, >> which contains the namedCurve CHOICE. Here we introduce two [I think >> this should be four] new OIDs >> for use in the namedCurve field. >> """ >> >> Anyway, if we go with top-level OIDs for everything, this is all moot. >> >> David >> >> >>> Other than this part, you raise a very good point. It may be much >>> simpler to use a common OID and move it up. Unlike the NIST curves the >>> constructions we have under the eddsa OID umbrella are quite distinct. >>> >>> I was concerned about future extensibility and the fact that pureEdDSA >>> and PrehashedEdDSA could be with separate algorithm OIDs, but after >>> thinking it further, I think what you suggest is much neater, as having >>> a single OID to identify scheme+curve will also restrict private keys >>> to a single purpose which is a good thing. >>> >>> +1 >>> >>> regards, >>> Nikos >>> >>> >> _______________________________________________ >> Curdle mailing list >> Curdle@ietf.org >> https://www.ietf.org/mailman/listinfo/curdle >> >> > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > --001a1145bcf2b5276f0534b80aa7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Jun 7,= 2016 at 6:40 PM Russ Housley <h= ousley@vigilsec.com> wrote:
=
I think we have two choices, neith= er of them is in draft-curdle-pkix-00.

Either we d= efine eight object identifiers for the named curves for use with id-ecPubli= cKey:

=C2=A0 =C2=A0 =C2=A0 =C2=A0id-Curve2551= 9
=C2=A0 =C2=A0 =C2=A0 =C2=A0id-Curve448
=C2=A0 =C2=A0 = =C2=A0 =C2=A0id-Curve25519ph
=C2=A0 =C2=A0 =C2=A0 =C2=A0id-Curve4= 48ph

Were you thinking th= at id-Curve25519 refer to anything using the curve or specifically the Diff= ie-Hellman primitive? If the latter, I would suggest X25519 (for consistenc= y with RFC 7748) and dropping the "ph" ones since those are only = in EdDSA. If the former, it seems redundant with the EdDSA OIDs below.

=C2=A0 =C2=A0 =C2=A0 =C2=A0id-ed25519
=C2=A0 = =C2=A0 =C2=A0 =C2=A0id-ed25519ph
=C2=A0 =C2=A0 =C2=A0 =C2=A0id-ed= 448
=C2=A0 =C2=A0 =C2=A0 =C2=A0id-ed448ph

or we define eight object identifiers that are used as algorithm identifi= ers:

=C2=A0 =C2=A0 =C2=A0 =C2=A0id-ecPublicKe= yCurve25519
=C2=A0 =C2=A0 =C2=A0 =C2=A0id-ecPublicKeyCurve448
=C2=A0 =C2=A0 =C2=A0 =C2=A0id-ecPublicKeyCurve25519ph
=C2= =A0 =C2=A0 =C2=A0 =C2=A0id-ecPublicKeyCurve448ph
=C2=A0 =C2=A0 = =C2=A0 =C2=A0id-ecPublicKeyED25519
=C2=A0 =C2=A0 =C2=A0 =C2=A0id-= ecPublicKeyED25519ph
=C2=A0 =C2=A0 =C2=A0 =C2=A0id-ecPublicKeyED4= 48
=C2=A0 =C2=A0 =C2=A0 =C2=A0id-ecPublicKeyED448ph

Nit: I would suggest dropping th= e ecPublicKey prefix and s/ED/Ed/ to be consistent with the usual styling. = Also the same "X" vs "Curve" and "ph" comment= s above. So:

id-X25519
id-X448
id-Ed25519
id-Ed25519ph
id-Ed448
id-Ed448ph<= br>
(Or maybe all lowercase? Between id-rsaEncryption and id-RSASSA-PSS,= I'm unclear on whether OIDs are supposed to be lowercase. Anyway...)
=C2=A0
I can live with either one, but I would like to see = us choose soon.

(I obviou= sly have a preference, but I've argued for it elsewhere. :-) )
=C2=A0
Russ
<= div>


On Jun 7, 2016, at 4:58 PM,= Daniel Migault <daniel.migault@ericsson.com> wrote:

Hi,

Do we have= some consensus that having top-level OID would be better ? Please provide = your opinion and let the WG know your thoughts so the document can be moved= forward.

BR,
Daniel

On Thu, May 19, 2016 at 10:41 AM, Davi= d Benjamin <davidben@chromium.org> wrote:
On Thu, May 19, 2016 at 4:40 AM Nikos Mavrogiannopoulos <nmav@redhat.com> w= rote:
On Tue, 2016-05-17 at 14:20 += 0000, David Benjamin wrote:
> I would actually advocate a different change. I sent this message
> earlier:
> https://www.ietf.org/mail-arc= hive/web/curdle/current/msg00203.html
>
> Rather than use parameters, allocate new algorithm OIDs for
> everything. I don't think we actually gain anything by exposing th= e
> relations and parameterizations between these algorithms. When
> implementing, they are great for sharing code. But when consuming,
> exposing it makes parsing more complex, and it increases the risk of > reusing keys between related algorithms. We can get the best of both > worlds by separating entry-points and sharing internals.

On your referenced message I am confused on the issue you raise on
section 3. As I read section 3, I do not see anything that allows
having=C2=A0id-ecPublicKey as an algorithm identifier for these keys.

It's certainly possible I'm m= isunderstanding what section 3 was for. I was kind of confused why there we= re two encodings. I was getting=C2=A0id-ecPublicKey from:

"""
=C2=A0 =C2=A0Section 2.3.5 of [RF= C3279]
=C2=A0 =C2=A0describe ECDSA/ECDH public keys, specifying t= he id-ecPublicKey OID.
=C2=A0 =C2=A0This OID has the associated E= cpkParameters parameters structure,
=C2=A0 =C2=A0which contains t= he namedCurve CHOICE.=C2=A0 Here we introduce two [I think this should be f= our] new OIDs
=C2=A0 =C2=A0for use in the namedCurve field.
&q= uot;""

Anyway, if we go with top-level OIDs for everything= , this is all moot.

David
=C2=A0
Other than this part, you raise a very good point. It may be much
simpler to use a common OID and move it up. Unlike the NIST curves the
constructions we have under the eddsa OID umbrella are quite distinct.

I was concerned about future extensibility and the fact that pureEdDSA
and PrehashedEdDSA could be with separate algorithm OIDs, but after
thinking it further, I think what you suggest is much neater, as having
a single OID to identify scheme+curve will also restrict private keys
to a single purpose which is a good thing.

+1

regards,
Nikos


_______________________________________________
Curdle mailing list
Curdle@ietf.org https://www.ietf.org/mailman/listinfo/curdle


_______________________________________________
Curdle mailing list
<= a href=3D"mailto:Curdle@ietf.org" target=3D"_blank">Curdle@ietf.org
= = https://www.ietf.org/mailman/listinfo/curdle

=
_______________________________________________
Curdle mailing list
Curdle@ietf.org https://www.ietf.org/mailman/listinfo/curdle
--001a1145bcf2b5276f0534b80aa7-- From nobody Tue Jun 7 16:22:25 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B7E012D8D8 for ; Tue, 7 Jun 2016 16:21:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.899 X-Spam-Level: X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 86xRuFOXumzg for ; Tue, 7 Jun 2016 16:21:50 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E0B112D641 for ; Tue, 7 Jun 2016 16:19:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 1293B3002C6 for ; Tue, 7 Jun 2016 19:19:34 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id YEDq-v9dyrLt for ; Tue, 7 Jun 2016 19:19:32 -0400 (EDT) Received: from [5.5.33.191] (vpn.snozzages.com [204.42.252.17]) by mail.smeinc.net (Postfix) with ESMTPSA id 01995300093; Tue, 7 Jun 2016 19:19:31 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_F767FA25-BBFB-4915-B0CA-C225188BDE60" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: Date: Tue, 7 Jun 2016 18:00:38 -0400 Message-Id: References: <1463470661.2914.4.camel@redhat.com> <1463647224.3558.14.camel@redhat.com> To: Daniel Migault X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: "curdle@ietf.org" Subject: Re: [Curdle] draft-ietf-curdle-pkix-00: a simplification proposal X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 23:21:58 -0000 --Apple-Mail=_F767FA25-BBFB-4915-B0CA-C225188BDE60 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I think we have two choices, neither of them is in draft-curdle-pkix-00. Either we define eight object identifiers for the named curves for use = with id-ecPublicKey: id-Curve25519 id-Curve448 id-Curve25519ph id-Curve448ph id-ed25519 id-ed25519ph id-ed448 id-ed448ph or we define eight object identifiers that are used as algorithm = identifiers: id-ecPublicKeyCurve25519 id-ecPublicKeyCurve448 id-ecPublicKeyCurve25519ph id-ecPublicKeyCurve448ph id-ecPublicKeyED25519 id-ecPublicKeyED25519ph id-ecPublicKeyED448 id-ecPublicKeyED448ph I can live with either one, but I would like to see us choose soon. Russ On Jun 7, 2016, at 4:58 PM, Daniel Migault = wrote: > Hi,=20 >=20 > Do we have some consensus that having top-level OID would be better ? = Please provide your opinion and let the WG know your thoughts so the = document can be moved forward.=20 >=20 > BR,=20 > Daniel >=20 > On Thu, May 19, 2016 at 10:41 AM, David Benjamin = wrote: > On Thu, May 19, 2016 at 4:40 AM Nikos Mavrogiannopoulos = wrote: > On Tue, 2016-05-17 at 14:20 +0000, David Benjamin wrote: > > I would actually advocate a different change. I sent this message > > earlier: > > https://www.ietf.org/mail-archive/web/curdle/current/msg00203.html > > > > Rather than use parameters, allocate new algorithm OIDs for > > everything. I don't think we actually gain anything by exposing the > > relations and parameterizations between these algorithms. When > > implementing, they are great for sharing code. But when consuming, > > exposing it makes parsing more complex, and it increases the risk of > > reusing keys between related algorithms. We can get the best of both > > worlds by separating entry-points and sharing internals. >=20 > On your referenced message I am confused on the issue you raise on > section 3. As I read section 3, I do not see anything that allows > having id-ecPublicKey as an algorithm identifier for these keys. >=20 > It's certainly possible I'm misunderstanding what section 3 was for. I = was kind of confused why there were two encodings. I was getting = id-ecPublicKey from: >=20 > """ > Section 2.3.5 of [RFC3279] > describe ECDSA/ECDH public keys, specifying the id-ecPublicKey OID. > This OID has the associated EcpkParameters parameters structure, > which contains the namedCurve CHOICE. Here we introduce two [I = think this should be four] new OIDs > for use in the namedCurve field. > """ >=20 > Anyway, if we go with top-level OIDs for everything, this is all moot. >=20 > David > =20 > Other than this part, you raise a very good point. It may be much > simpler to use a common OID and move it up. Unlike the NIST curves the > constructions we have under the eddsa OID umbrella are quite distinct. >=20 > I was concerned about future extensibility and the fact that pureEdDSA > and PrehashedEdDSA could be with separate algorithm OIDs, but after > thinking it further, I think what you suggest is much neater, as = having > a single OID to identify scheme+curve will also restrict private keys > to a single purpose which is a good thing. >=20 > +1 >=20 > regards, > Nikos >=20 >=20 > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle >=20 >=20 > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle --Apple-Mail=_F767FA25-BBFB-4915-B0CA-C225188BDE60 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
I = think we have two choices, neither of them is in = draft-curdle-pkix-00.

Either we define eight = object identifiers for the named curves for use with = id-ecPublicKey:

      =  id-Curve25519
      =  id-Curve448
      =  id-Curve25519ph
      =  id-Curve448ph
      =  id-ed25519
      =  id-ed25519ph
      =  id-ed448
      =  id-ed448ph

or we define eight object = identifiers that are used as algorithm = identifiers:

      =  id-ecPublicKeyCurve25519
      =  id-ecPublicKeyCurve448
      =  id-ecPublicKeyCurve25519ph
      =  id-ecPublicKeyCurve448ph
      =  id-ecPublicKeyED25519
      =  id-ecPublicKeyED25519ph
      =  id-ecPublicKeyED448
      =  id-ecPublicKeyED448ph

I can live = with either one, but I would like to see us choose = soon.

Russ



On Jun 7, 2016, at 4:58 PM, Daniel Migault <daniel.migault@ericsson.com> wrote:

Hi,

Do we = have some consensus that having top-level OID would be better ? Please = provide your opinion and let the WG know your thoughts so the document = can be moved forward.

BR,
Daniel

On Thu, May 19, = 2016 at 10:41 AM, David Benjamin <davidben@chromium.org> = wrote:
On Thu, May 19, = 2016 at 4:40 AM Nikos Mavrogiannopoulos <nmav@redhat.com> = wrote:
On Tue, 2016-05-17 at = 14:20 +0000, David Benjamin wrote:
> I would actually advocate a different change. I sent this = message
> earlier:
> https://www.ietf.org/mail-archive/web/curdle/current/msg= 00203.html
>
> Rather than use parameters, allocate new algorithm OIDs for
> everything. I don't think we actually gain anything by exposing = the
> relations and parameterizations between these algorithms. When
> implementing, they are great for sharing code. But when = consuming,
> exposing it makes parsing more complex, and it increases the risk = of
> reusing keys between related algorithms. We can get the best of = both
> worlds by separating entry-points and sharing internals.

On your referenced message I am confused on the issue you raise on
section 3. As I read section 3, I do not see anything that allows
having id-ecPublicKey as an algorithm identifier for these = keys.

It's certainly possible = I'm misunderstanding what section 3 was for. I was kind of confused why = there were two encodings. I was getting id-ecPublicKey = from:

"""
   Section = 2.3.5 of [RFC3279]
   describe ECDSA/ECDH public = keys, specifying the id-ecPublicKey OID.
   This OID = has the associated EcpkParameters parameters structure,
  =  which contains the namedCurve CHOICE.  Here we introduce two = [I think this should be four] new OIDs
   for use in = the namedCurve field.
"""

Anyway, if we go with top-level OIDs = for everything, this is all moot.

David
 
Other than this part, you raise a very good point. It may be much
simpler to use a common OID and move it up. Unlike the NIST curves = the
constructions we have under the eddsa OID umbrella are quite = distinct.

I was concerned about future extensibility and the fact that = pureEdDSA
and PrehashedEdDSA could be with separate algorithm OIDs, but after
thinking it further, I think what you suggest is much neater, as = having
a single OID to identify scheme+curve will also restrict private = keys
to a single purpose which is a good thing.

+1

regards,
Nikos


_______________________________________________
Curdle mailing list
Curdle@ietf.org
https://www.ietf.org/mailman/listinfo/curdle


_______________________________________________
Curdle mailing = list
Curdle@ietf.org
https://www.ietf.or= g/mailman/listinfo/curdle

= --Apple-Mail=_F767FA25-BBFB-4915-B0CA-C225188BDE60-- From nobody Tue Jun 7 16:22:50 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D606712D0DB for ; Tue, 7 Jun 2016 16:22:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.899 X-Spam-Level: X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UFQzn3I8KjVy for ; Tue, 7 Jun 2016 16:22:29 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DA3C12D1DC for ; Tue, 7 Jun 2016 16:20:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 0DE483002C6 for ; Tue, 7 Jun 2016 19:20:04 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id JtHIujuL3xRV for ; Tue, 7 Jun 2016 19:20:02 -0400 (EDT) Received: from [5.5.33.191] (vpn.snozzages.com [204.42.252.17]) by mail.smeinc.net (Postfix) with ESMTPSA id ECC52300093; Tue, 7 Jun 2016 19:20:01 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_45EBC763-8937-4FAA-BF08-8DDCB1262743" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: Date: Tue, 7 Jun 2016 19:20:05 -0400 Message-Id: <2E47369A-E51A-433B-AFA5-6C3FDEBD0F1E@vigilsec.com> References: <1463470661.2914.4.camel@redhat.com> <1463647224.3558.14.camel@redhat.com> To: Daniel Migault X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: "curdle@ietf.org" Subject: Re: [Curdle] draft-ietf-curdle-pkix-00: a simplification proposal X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 23:22:41 -0000 --Apple-Mail=_45EBC763-8937-4FAA-BF08-8DDCB1262743 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I think we have two choices, neither of them is in draft-curdle-pkix-00. Either we define eight object identifiers for the named curves for use = with id-ecPublicKey: id-Curve25519 id-Curve448 id-Curve25519ph id-Curve448ph id-ed25519 id-ed25519ph id-ed448 id-ed448ph or we define eight object identifiers that are used as algorithm = identifiers: id-ecPublicKeyCurve25519 id-ecPublicKeyCurve448 id-ecPublicKeyCurve25519ph id-ecPublicKeyCurve448ph id-ecPublicKeyED25519 id-ecPublicKeyED25519ph id-ecPublicKeyED448 id-ecPublicKeyED448ph I can live with either one, but I would like to see us choose soon. Russ On Jun 7, 2016, at 4:58 PM, Daniel Migault = wrote: > Hi,=20 >=20 > Do we have some consensus that having top-level OID would be better ? = Please provide your opinion and let the WG know your thoughts so the = document can be moved forward.=20 >=20 > BR,=20 > Daniel >=20 > On Thu, May 19, 2016 at 10:41 AM, David Benjamin = wrote: > On Thu, May 19, 2016 at 4:40 AM Nikos Mavrogiannopoulos = wrote: > On Tue, 2016-05-17 at 14:20 +0000, David Benjamin wrote: > > I would actually advocate a different change. I sent this message > > earlier: > > https://www.ietf.org/mail-archive/web/curdle/current/msg00203.html > > > > Rather than use parameters, allocate new algorithm OIDs for > > everything. I don't think we actually gain anything by exposing the > > relations and parameterizations between these algorithms. When > > implementing, they are great for sharing code. But when consuming, > > exposing it makes parsing more complex, and it increases the risk of > > reusing keys between related algorithms. We can get the best of both > > worlds by separating entry-points and sharing internals. >=20 > On your referenced message I am confused on the issue you raise on > section 3. As I read section 3, I do not see anything that allows > having id-ecPublicKey as an algorithm identifier for these keys. >=20 > It's certainly possible I'm misunderstanding what section 3 was for. I = was kind of confused why there were two encodings. I was getting = id-ecPublicKey from: >=20 > """ > Section 2.3.5 of [RFC3279] > describe ECDSA/ECDH public keys, specifying the id-ecPublicKey OID. > This OID has the associated EcpkParameters parameters structure, > which contains the namedCurve CHOICE. Here we introduce two [I = think this should be four] new OIDs > for use in the namedCurve field. > """ >=20 > Anyway, if we go with top-level OIDs for everything, this is all moot. >=20 > David > =20 > Other than this part, you raise a very good point. It may be much > simpler to use a common OID and move it up. Unlike the NIST curves the > constructions we have under the eddsa OID umbrella are quite distinct. >=20 > I was concerned about future extensibility and the fact that pureEdDSA > and PrehashedEdDSA could be with separate algorithm OIDs, but after > thinking it further, I think what you suggest is much neater, as = having > a single OID to identify scheme+curve will also restrict private keys > to a single purpose which is a good thing. >=20 > +1 >=20 > regards, > Nikos >=20 >=20 > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle >=20 >=20 > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle --Apple-Mail=_45EBC763-8937-4FAA-BF08-8DDCB1262743 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
I = think we have two choices, neither of them is in = draft-curdle-pkix-00.

Either we define eight = object identifiers for the named curves for use with = id-ecPublicKey:

      =  id-Curve25519
      =  id-Curve448
      =  id-Curve25519ph
      =  id-Curve448ph
      =  id-ed25519
      =  id-ed25519ph
      =  id-ed448
      =  id-ed448ph

or we define eight object = identifiers that are used as algorithm = identifiers:

      =  id-ecPublicKeyCurve25519
      =  id-ecPublicKeyCurve448
      =  id-ecPublicKeyCurve25519ph
      =  id-ecPublicKeyCurve448ph
      =  id-ecPublicKeyED25519
      =  id-ecPublicKeyED25519ph
      =  id-ecPublicKeyED448
      =  id-ecPublicKeyED448ph

I can live = with either one, but I would like to see us choose = soon.

Russ



On Jun 7, 2016, at 4:58 PM, Daniel Migault <daniel.migault@ericsson.com> wrote:

Hi,

Do we = have some consensus that having top-level OID would be better ? Please = provide your opinion and let the WG know your thoughts so the document = can be moved forward.

BR,
Daniel

On Thu, May 19, = 2016 at 10:41 AM, David Benjamin <davidben@chromium.org> = wrote:
On Thu, May 19, = 2016 at 4:40 AM Nikos Mavrogiannopoulos <nmav@redhat.com> = wrote:
On Tue, 2016-05-17 at = 14:20 +0000, David Benjamin wrote:
> I would actually advocate a different change. I sent this = message
> earlier:
> https://www.ietf.org/mail-archive/web/curdle/current/msg= 00203.html
>
> Rather than use parameters, allocate new algorithm OIDs for
> everything. I don't think we actually gain anything by exposing = the
> relations and parameterizations between these algorithms. When
> implementing, they are great for sharing code. But when = consuming,
> exposing it makes parsing more complex, and it increases the risk = of
> reusing keys between related algorithms. We can get the best of = both
> worlds by separating entry-points and sharing internals.

On your referenced message I am confused on the issue you raise on
section 3. As I read section 3, I do not see anything that allows
having id-ecPublicKey as an algorithm identifier for these = keys.

It's certainly possible = I'm misunderstanding what section 3 was for. I was kind of confused why = there were two encodings. I was getting id-ecPublicKey = from:

"""
   Section = 2.3.5 of [RFC3279]
   describe ECDSA/ECDH public = keys, specifying the id-ecPublicKey OID.
   This OID = has the associated EcpkParameters parameters structure,
  =  which contains the namedCurve CHOICE.  Here we introduce two = [I think this should be four] new OIDs
   for use in = the namedCurve field.
"""

Anyway, if we go with top-level OIDs = for everything, this is all moot.

David
 
Other than this part, you raise a very good point. It may be much
simpler to use a common OID and move it up. Unlike the NIST curves = the
constructions we have under the eddsa OID umbrella are quite = distinct.

I was concerned about future extensibility and the fact that = pureEdDSA
and PrehashedEdDSA could be with separate algorithm OIDs, but after
thinking it further, I think what you suggest is much neater, as = having
a single OID to identify scheme+curve will also restrict private = keys
to a single purpose which is a good thing.

+1

regards,
Nikos


_______________________________________________
Curdle mailing list
Curdle@ietf.org
https://www.ietf.org/mailman/listinfo/curdle


_______________________________________________
Curdle mailing = list
Curdle@ietf.org
https://www.ietf.org= /mailman/listinfo/curdle

= --Apple-Mail=_45EBC763-8937-4FAA-BF08-8DDCB1262743-- From nobody Wed Jun 8 06:58:03 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC31212B077 for ; Wed, 8 Jun 2016 06:58:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.899 X-Spam-Level: X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XfRRGqlLVvfn for ; Wed, 8 Jun 2016 06:58:00 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 821B312D8CD for ; Wed, 8 Jun 2016 06:57:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 1305C30025E for ; Wed, 8 Jun 2016 09:57:40 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id w7YTHbtZ4x_S for ; Wed, 8 Jun 2016 09:57:34 -0400 (EDT) Received: from [5.5.33.194] (vpn.snozzages.com [204.42.252.17]) by mail.smeinc.net (Postfix) with ESMTPSA id 0BAFE300257; Wed, 8 Jun 2016 09:57:33 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_8DABFD70-170F-4207-957B-52DC2EA778BC" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: Date: Wed, 8 Jun 2016 09:57:37 -0400 Message-Id: References: <1463470661.2914.4.camel@redhat.com> <1463647224.3558.14.camel@redhat.com> To: David Benjamin X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: Daniel Migault , "curdle@ietf.org" Subject: Re: [Curdle] draft-ietf-curdle-pkix-00: a simplification proposal X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 13:58:03 -0000 --Apple-Mail=_8DABFD70-170F-4207-957B-52DC2EA778BC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii All good suggestions. Thanks. Russ On Jun 7, 2016, at 6:52 PM, David Benjamin = wrote: > On Tue, Jun 7, 2016 at 6:40 PM Russ Housley = wrote: > I think we have two choices, neither of them is in = draft-curdle-pkix-00. >=20 > Either we define eight object identifiers for the named curves for use = with id-ecPublicKey: >=20 > id-Curve25519 > id-Curve448 > id-Curve25519ph > id-Curve448ph >=20 > Were you thinking that id-Curve25519 refer to anything using the curve = or specifically the Diffie-Hellman primitive? If the latter, I would = suggest X25519 (for consistency with RFC 7748) and dropping the "ph" = ones since those are only in EdDSA. If the former, it seems redundant = with the EdDSA OIDs below. >=20 > id-ed25519 > id-ed25519ph > id-ed448 > id-ed448ph >=20 > or we define eight object identifiers that are used as algorithm = identifiers: >=20 > id-ecPublicKeyCurve25519 > id-ecPublicKeyCurve448 > id-ecPublicKeyCurve25519ph > id-ecPublicKeyCurve448ph > id-ecPublicKeyED25519 > id-ecPublicKeyED25519ph > id-ecPublicKeyED448 > id-ecPublicKeyED448ph >=20 > Nit: I would suggest dropping the ecPublicKey prefix and s/ED/Ed/ to = be consistent with the usual styling. Also the same "X" vs "Curve" and = "ph" comments above. So: >=20 > id-X25519 > id-X448 > id-Ed25519 > id-Ed25519ph > id-Ed448 > id-Ed448ph >=20 > (Or maybe all lowercase? Between id-rsaEncryption and id-RSASSA-PSS, = I'm unclear on whether OIDs are supposed to be lowercase. Anyway...) > =20 > I can live with either one, but I would like to see us choose soon. >=20 > (I obviously have a preference, but I've argued for it elsewhere. :-) = ) > =20 > Russ >=20 >=20 >=20 > On Jun 7, 2016, at 4:58 PM, Daniel Migault = wrote: >=20 >> Hi,=20 >>=20 >> Do we have some consensus that having top-level OID would be better ? = Please provide your opinion and let the WG know your thoughts so the = document can be moved forward.=20 >>=20 >> BR,=20 >> Daniel >>=20 >> On Thu, May 19, 2016 at 10:41 AM, David Benjamin = wrote: >> On Thu, May 19, 2016 at 4:40 AM Nikos Mavrogiannopoulos = wrote: >> On Tue, 2016-05-17 at 14:20 +0000, David Benjamin wrote: >> > I would actually advocate a different change. I sent this message >> > earlier: >> > https://www.ietf.org/mail-archive/web/curdle/current/msg00203.html >> > >> > Rather than use parameters, allocate new algorithm OIDs for >> > everything. I don't think we actually gain anything by exposing the >> > relations and parameterizations between these algorithms. When >> > implementing, they are great for sharing code. But when consuming, >> > exposing it makes parsing more complex, and it increases the risk = of >> > reusing keys between related algorithms. We can get the best of = both >> > worlds by separating entry-points and sharing internals. >>=20 >> On your referenced message I am confused on the issue you raise on >> section 3. As I read section 3, I do not see anything that allows >> having id-ecPublicKey as an algorithm identifier for these keys. >>=20 >> It's certainly possible I'm misunderstanding what section 3 was for. = I was kind of confused why there were two encodings. I was getting = id-ecPublicKey from: >>=20 >> """ >> Section 2.3.5 of [RFC3279] >> describe ECDSA/ECDH public keys, specifying the id-ecPublicKey = OID. >> This OID has the associated EcpkParameters parameters structure, >> which contains the namedCurve CHOICE. Here we introduce two [I = think this should be four] new OIDs >> for use in the namedCurve field. >> """ >>=20 >> Anyway, if we go with top-level OIDs for everything, this is all = moot. >>=20 >> David >> =20 >> Other than this part, you raise a very good point. It may be much >> simpler to use a common OID and move it up. Unlike the NIST curves = the >> constructions we have under the eddsa OID umbrella are quite = distinct. >>=20 >> I was concerned about future extensibility and the fact that = pureEdDSA >> and PrehashedEdDSA could be with separate algorithm OIDs, but after >> thinking it further, I think what you suggest is much neater, as = having >> a single OID to identify scheme+curve will also restrict private keys >> to a single purpose which is a good thing. >>=20 >> +1 >>=20 >> regards, >> Nikos >>=20 >>=20 >> _______________________________________________ >> Curdle mailing list >> Curdle@ietf.org >> https://www.ietf.org/mailman/listinfo/curdle >>=20 >>=20 >> _______________________________________________ >> Curdle mailing list >> Curdle@ietf.org >> https://www.ietf.org/mailman/listinfo/curdle >=20 > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle --Apple-Mail=_8DABFD70-170F-4207-957B-52DC2EA778BC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii All = good suggestions. =  Thanks.

Russ


On Jun 7, 2016, at 6:52 PM, David Benjamin <davidben@chromium.org> = wrote:

On Tue, Jun 7, 2016 at 6:40 PM Russ Housley <housley@vigilsec.com> = wrote:
I think we have two choices, neither = of them is in draft-curdle-pkix-00.

Either we = define eight object identifiers for the named curves for use with = id-ecPublicKey:

      =  id-Curve25519
      =  id-Curve448
      =  id-Curve25519ph
      =  id-Curve448ph

Were= you thinking that id-Curve25519 refer to anything using the curve or = specifically the Diffie-Hellman primitive? If the latter, I would = suggest X25519 (for consistency with RFC 7748) and dropping the "ph" = ones since those are only in EdDSA. If the former, it seems redundant = with the EdDSA OIDs below.

  =      id-ed25519
      =  id-ed25519ph
      =  id-ed448
      =  id-ed448ph

or we define eight object = identifiers that are used as algorithm = identifiers:

      =  id-ecPublicKeyCurve25519
      =  id-ecPublicKeyCurve448
      =  id-ecPublicKeyCurve25519ph
      =  id-ecPublicKeyCurve448ph
      =  id-ecPublicKeyED25519
      =  id-ecPublicKeyED25519ph
      =  id-ecPublicKeyED448
      =  id-ecPublicKeyED448ph

<= div>Nit: I would suggest dropping the ecPublicKey prefix and s/ED/Ed/ to = be consistent with the usual styling. Also the same "X" vs "Curve" and = "ph" comments above. = So:

id-X25519
id-X448
id-Ed25= 519
id-Ed25519ph
id-Ed448
id-Ed448ph

= (Or maybe all lowercase? Between id-rsaEncryption and id-RSASSA-PSS, I'm = unclear on whether OIDs are supposed to be lowercase. = Anyway...)
 
I can live = with either one, but I would like to see us choose = soon.

(I obviously have a = preference, but I've argued for it elsewhere. :-) = )
 
Russ



On Jun 7, 2016, at 4:58 PM, Daniel Migault <daniel.migault@ericsson.com> = wrote:

Hi,

Do we have some consensus = that having top-level OID would be better ? Please provide your opinion = and let the WG know your thoughts so the document can be moved forward. =

BR,
Daniel

On Thu, May 19, = 2016 at 10:41 AM, David Benjamin <davidben@chromium.org> = wrote:
On Thu, May 19, 2016 at = 4:40 AM Nikos Mavrogiannopoulos <nmav@redhat.com> wrote:
On Tue, 2016-05-17 at 14:20 +0000, David = Benjamin wrote:
> I would actually advocate a different change. I sent this = message
> earlier:
> https://www.ietf.org/mail-archive/web/curdle/current/msg= 00203.html
>
> Rather than use parameters, allocate new algorithm OIDs for
> everything. I don't think we actually gain anything by exposing = the
> relations and parameterizations between these algorithms. When
> implementing, they are great for sharing code. But when = consuming,
> exposing it makes parsing more complex, and it increases the risk = of
> reusing keys between related algorithms. We can get the best of = both
> worlds by separating entry-points and sharing internals.

On your referenced message I am confused on the issue you raise on
section 3. As I read section 3, I do not see anything that allows
having id-ecPublicKey as an algorithm identifier for these = keys.

It's certainly possible = I'm misunderstanding what section 3 was for. I was kind of confused why = there were two encodings. I was getting id-ecPublicKey = from:

"""
   Section = 2.3.5 of [RFC3279]
   describe ECDSA/ECDH public = keys, specifying the id-ecPublicKey OID.
   This OID = has the associated EcpkParameters parameters structure,
  =  which contains the namedCurve CHOICE.  Here we introduce two = [I think this should be four] new OIDs
   for use in = the namedCurve field.
"""

Anyway, if we go with top-level OIDs = for everything, this is all moot.

David
=  
Other than this part, you raise a very good point. It may be much
simpler to use a common OID and move it up. Unlike the NIST curves = the
constructions we have under the eddsa OID umbrella are quite = distinct.

I was concerned about future extensibility and the fact that = pureEdDSA
and PrehashedEdDSA could be with separate algorithm OIDs, but after
thinking it further, I think what you suggest is much neater, as = having
a single OID to identify scheme+curve will also restrict private = keys
to a single purpose which is a good thing.

+1

regards,
Nikos


_______________________________________________
Curdle mailing list
Curdle@ietf.org
https://www.ietf.org/mailman/listinfo/curdle


_______________________________________________
Curdle mailing = list
Curdle@ietf.org
https://www.ietf.org/mailman/listinfo/curdle

___________________________________________= ____
Curdle mailing list
Curdle@ietf.org
https://www.ietf.org/mailman/listinfo/curdle

= --Apple-Mail=_8DABFD70-170F-4207-957B-52DC2EA778BC-- From nobody Wed Jun 8 12:34:41 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47FBC12D69E for ; Wed, 8 Jun 2016 12:34:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XMijqe_bRIZw for ; Wed, 8 Jun 2016 12:34:37 -0700 (PDT) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EDB412D106 for ; Wed, 8 Jun 2016 12:34:37 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id n184so195851772wmn.1 for ; Wed, 08 Jun 2016 12:34:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=WXfv/+i7mU8w/GospAhrwZs6fOBqtvcpK5K5wFif07s=; b=AD4QUFDwoch7eSn0fv2XpKnllRYSHdaAN9X+jSih/E+yinrpXILPo+pPpx1jKsc5Eh TJ1SPod9h8iib0EJXLB2APjwaLiJDqzZXlo1YImiaGNSBCrvgCadVVPCT4R4gumgse6C jpX0Cx0d1DwzI6if6tSUdi+SeEUPVOpc3sPre8YkS2W+c0LdT+8bGhLNpdjZZ6RIjRAY cMnuTBggHjReQ9DqgW9JMhTfAo+jD7Gak6PJpcZpiWjSfUUSlIx+j1NFxFtAtZIdo9o2 sYdHSMWBMFSxB2GAMs4rtUQmJ+IRuJTfjG/hz0lFXrxo4LLiO6Xe6YvkO4i4jTqJFt7Q kP4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=WXfv/+i7mU8w/GospAhrwZs6fOBqtvcpK5K5wFif07s=; b=U7ktaHzuDFuVEKpY2rC2xYbH/Lst9ZiTth0UdITdpkfeDLwlsyF4zvTUVc5fPPMSVa h20PiVBGNgN0UzGPgI0ZwtrXJk/z2jRPuXEfjIP4DgH5Ubcgvehd9YVub2PPFwVYnFYJ lsnLJ5SR9D/cHVIOWz54S2jVP8lWOfGwk586EMRuhqxAELdiCxqGe4b0TKwjcxwpegwu QxTyN8mrFzfT4CK6o8UPk2QwzlWYlVa5N+aDiIkGcmXfFBmAE8mbVQv05gbS4FVNtEso k3doRTpu3ElE1JzUqDyK6pDnAczfB/sJrj5q2DdLyyoZ9pdTJG0FCcttV0zqSmkypZyQ 3ajA== X-Gm-Message-State: ALyK8tI+f0H2AFtu7SfoFZGroSwP0Xmy4fljIWF7w2hare9ZQkDmHpZ3ebntK+yyBQKjlBlJEP4lCi9SEFlhDg== X-Received: by 10.28.46.206 with SMTP id u197mr9223761wmu.70.1465414475568; Wed, 08 Jun 2016 12:34:35 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.194.86.42 with HTTP; Wed, 8 Jun 2016 12:34:34 -0700 (PDT) In-Reply-To: References: <1463470661.2914.4.camel@redhat.com> <1463647224.3558.14.camel@redhat.com> From: Daniel Migault Date: Wed, 8 Jun 2016 15:34:34 -0400 X-Google-Sender-Auth: la4hZbXMrH7GT_t_9u3OfPv9qdc Message-ID: To: Russ Housley Content-Type: multipart/alternative; boundary=001a1142369843dae20534c9654e Archived-At: Cc: "curdle@ietf.org" , David Benjamin Subject: Re: [Curdle] draft-ietf-curdle-pkix-00: a simplification proposal X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 19:34:40 -0000 --001a1142369843dae20534c9654e Content-Type: text/plain; charset=UTF-8 Hi, Thank you Russ and David for the feed backs and clarifications. So my understanding from this thread is that their is a need for IODs to qualify the key and the signature, that is defining how to use the key or check/generate the signature. In other words, the usage of the key. Curves do not seem sufficient as the same curve may be used in different ways. As a result, my understanding is that defining the usage which includes the curve is preferable. The usage is defined by the algorithm and the following IODs: id-X25519 id-X448 id-Ed25519 id-Ed25519ph id-Ed448 id-Ed448ph If I am not correct, please correct me. Otherwise, I would like to see by the end of the week: A) if anyone has a better alternative than using the following OIDs to define the algorithms. B) if anyone is fine with this alternative C) if anyone is opposed with this alternative D) if anyone has better names. BR, Daniel On Wed, Jun 8, 2016 at 9:57 AM, Russ Housley wrote: > All good suggestions. Thanks. > > Russ > > > On Jun 7, 2016, at 6:52 PM, David Benjamin wrote: > > On Tue, Jun 7, 2016 at 6:40 PM Russ Housley wrote: > >> I think we have two choices, neither of them is in draft-curdle-pkix-00. >> >> Either we define eight object identifiers for the named curves for use >> with id-ecPublicKey: >> >> id-Curve25519 >> id-Curve448 >> id-Curve25519ph >> id-Curve448ph >> > > Were you thinking that id-Curve25519 refer to anything using the curve or > specifically the Diffie-Hellman primitive? If the latter, I would suggest > X25519 (for consistency with RFC 7748) and dropping the "ph" ones since > those are only in EdDSA. If the former, it seems redundant with the EdDSA > OIDs below. > > id-ed25519 >> id-ed25519ph >> id-ed448 >> id-ed448ph >> >> or we define eight object identifiers that are used as algorithm >> identifiers: >> >> id-ecPublicKeyCurve25519 >> id-ecPublicKeyCurve448 >> id-ecPublicKeyCurve25519ph >> id-ecPublicKeyCurve448ph >> id-ecPublicKeyED25519 >> id-ecPublicKeyED25519ph >> id-ecPublicKeyED448 >> id-ecPublicKeyED448ph >> > > Nit: I would suggest dropping the ecPublicKey prefix and s/ED/Ed/ to be > consistent with the usual styling. Also the same "X" vs "Curve" and "ph" > comments above. So: > > id-X25519 > id-X448 > id-Ed25519 > id-Ed25519ph > id-Ed448 > id-Ed448ph > > (Or maybe all lowercase? Between id-rsaEncryption and id-RSASSA-PSS, I'm > unclear on whether OIDs are supposed to be lowercase. Anyway...) > > >> I can live with either one, but I would like to see us choose soon. >> > > (I obviously have a preference, but I've argued for it elsewhere. :-) ) > > >> Russ >> >> >> >> On Jun 7, 2016, at 4:58 PM, Daniel Migault >> wrote: >> >> Hi, >> >> Do we have some consensus that having top-level OID would be better ? >> Please provide your opinion and let the WG know your thoughts so the >> document can be moved forward. >> >> BR, >> Daniel >> >> On Thu, May 19, 2016 at 10:41 AM, David Benjamin >> wrote: >> >>> On Thu, May 19, 2016 at 4:40 AM Nikos Mavrogiannopoulos >>> wrote: >>> >>>> On Tue, 2016-05-17 at 14:20 +0000, David Benjamin wrote: >>>> > I would actually advocate a different change. I sent this message >>>> > earlier: >>>> > https://www.ietf.org/mail-archive/web/curdle/current/msg00203.html >>>> > >>>> > Rather than use parameters, allocate new algorithm OIDs for >>>> > everything. I don't think we actually gain anything by exposing the >>>> > relations and parameterizations between these algorithms. When >>>> > implementing, they are great for sharing code. But when consuming, >>>> > exposing it makes parsing more complex, and it increases the risk of >>>> > reusing keys between related algorithms. We can get the best of both >>>> > worlds by separating entry-points and sharing internals. >>>> >>>> On your referenced message I am confused on the issue you raise on >>>> section 3. As I read section 3, I do not see anything that allows >>>> having id-ecPublicKey as an algorithm identifier for these keys. >>>> >>> >>> It's certainly possible I'm misunderstanding what section 3 was for. I >>> was kind of confused why there were two encodings. I was >>> getting id-ecPublicKey from: >>> >>> """ >>> Section 2.3.5 of [RFC3279] >>> describe ECDSA/ECDH public keys, specifying the id-ecPublicKey OID. >>> This OID has the associated EcpkParameters parameters structure, >>> which contains the namedCurve CHOICE. Here we introduce two [I think >>> this should be four] new OIDs >>> for use in the namedCurve field. >>> """ >>> >>> Anyway, if we go with top-level OIDs for everything, this is all moot. >>> >>> David >>> >>> >>>> Other than this part, you raise a very good point. It may be much >>>> simpler to use a common OID and move it up. Unlike the NIST curves the >>>> constructions we have under the eddsa OID umbrella are quite distinct. >>>> >>>> I was concerned about future extensibility and the fact that pureEdDSA >>>> and PrehashedEdDSA could be with separate algorithm OIDs, but after >>>> thinking it further, I think what you suggest is much neater, as having >>>> a single OID to identify scheme+curve will also restrict private keys >>>> to a single purpose which is a good thing. >>>> >>>> +1 >>>> >>>> regards, >>>> Nikos >>>> >>>> >>> _______________________________________________ >>> Curdle mailing list >>> Curdle@ietf.org >>> https://www.ietf.org/mailman/listinfo/curdle >>> >>> >> _______________________________________________ >> Curdle mailing list >> Curdle@ietf.org >> https://www.ietf.org/mailman/listinfo/curdle >> >> >> _______________________________________________ >> Curdle mailing list >> Curdle@ietf.org >> https://www.ietf.org/mailman/listinfo/curdle >> > > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > > --001a1142369843dae20534c9654e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Thank you Russ and David for the feed bac= ks and clarifications. So my understanding from this thread is that their i= s a need for IODs to qualify the key and the signature, that is defining ho= w to use the key or check/generate the signature. In other words, the usage= of the key. Curves do not seem sufficient as the same curve may be used in= different ways. As a result, my understanding is that defining the usage w= hich includes the curve is preferable. The usage is defined by the algorith= m and the following IODs:
=C2=A0
id-X25519
id-X448
id-Ed25519id-Ed25519ph
id-Ed448
id-Ed448ph

If I am not corr= ect, please correct me. Otherwise, I would like to see by the end of the we= ek:
=C2=A0A) if anyone has a better alternative than using the following= OIDs to define the algorithms.
=C2=A0B) if anyone is fine w= ith this alternative
=C2=A0C) if anyone is opposed with this alternative=
=C2=A0D) if anyone has better names.

BR, <= br>
Daniel





On Wed, Jun 8, 2016 at 9:57 AM, Russ Housley <hous= ley@vigilsec.com> wrote:
All good suggestions.=C2=A0 Thanks.

Russ


On Jun 7= , 2016, at 6:52 PM, David Benjamin <davidben@chromium.org> wrote:

On Tue, Jun 7, 2016 at 6:40 PM Russ Housley <housley@vigilsec.com> wrote:
<= div>I think we have two choices, neither of them is in draft-curdle-pkix-00= .

Either we define eight object identifiers for th= e named curves for use with id-ecPublicKey:

= =C2=A0 =C2=A0 =C2=A0 =C2=A0id-Curve25519
=C2=A0 =C2=A0 =C2=A0 =C2= =A0id-Curve448
=C2=A0 =C2=A0 =C2=A0 =C2=A0id-Curve25519ph
=C2=A0 =C2=A0 =C2=A0 =C2=A0id-Curve448ph
<= div>
Were you thinking that id-Curve25519 refer to anything u= sing the curve or specifically the Diffie-Hellman primitive? If the latter,= I would suggest X25519 (for consistency with RFC 7748) and dropping the &q= uot;ph" ones since those are only in EdDSA. If the former, it seems re= dundant with the EdDSA OIDs below.

=C2=A0 =C2=A0 =C2=A0 = =C2=A0id-ed25519
=C2=A0 =C2=A0 =C2=A0 =C2=A0id-ed25519ph
=C2=A0 =C2=A0 =C2=A0 =C2=A0id-ed448
=C2=A0 =C2=A0 =C2=A0 =C2=A0= id-ed448ph

or we define eight object identifiers t= hat are used as algorithm identifiers:

=C2=A0= =C2=A0 =C2=A0 =C2=A0id-ecPublicKeyCurve25519
=C2=A0 =C2=A0 =C2= =A0 =C2=A0id-ecPublicKeyCurve448
=C2=A0 =C2=A0 =C2=A0 =C2=A0id-ec= PublicKeyCurve25519ph
=C2=A0 =C2=A0 =C2=A0 =C2=A0id-ecPublicKeyCu= rve448ph
=C2=A0 =C2=A0 =C2=A0 =C2=A0id-ecPublicKeyED25519
=C2=A0 =C2=A0 =C2=A0 =C2=A0id-ecPublicKeyED25519ph
=C2=A0 =C2= =A0 =C2=A0 =C2=A0id-ecPublicKeyED448
=C2=A0 =C2=A0 =C2=A0 =C2=A0i= d-ecPublicKeyED448ph

Nit:= I would suggest dropping the ecPublicKey prefix and s/ED/Ed/ to be consist= ent with the usual styling. Also the same "X" vs "Curve"= ; and "ph" comments above. So:

id-X25519=
id-X448
id-Ed25519
id-Ed25519ph
id= -Ed448
id-Ed448ph

(Or maybe all lowercase? Between id-rsaE= ncryption and id-RSASSA-PSS, I'm unclear on whether OIDs are supposed t= o be lowercase. Anyway...)
=C2=A0
I can live with either one, but I = would like to see us choose soon.

(I = obviously have a preference, but I've argued for it elsewhere. :-) )
=C2=A0
Russ



On Jun 7, 2016, at 4:58 PM, Daniel Migault = <daniel= .migault@ericsson.com> wrote:

Hi,

Do we have some consensus th= at having top-level OID would be better ? Please provide your opinion and l= et the WG know your thoughts so the document can be moved forward.

=
BR,
Daniel

On Thu, May 19, 2016 at 10:41 AM, David Benjamin <d= avidben@chromium.org> wrote:
On Thu= , May 19, 2016 at 4:40 AM Nikos Mavrogiannopoulos <nmav@redhat.com> wrote:
On Tue, 2016-05-17 at 14:20 +0000, David Benjam= in wrote:
> I would actually advocate a different change. I sent this message
> earlier:
> https://www.ietf.org/mail-arc= hive/web/curdle/current/msg00203.html
>
> Rather than use parameters, allocate new algorithm OIDs for
> everything. I don't think we actually gain anything by exposing th= e
> relations and parameterizations between these algorithms. When
> implementing, they are great for sharing code. But when consuming,
> exposing it makes parsing more complex, and it increases the risk of > reusing keys between related algorithms. We can get the best of both > worlds by separating entry-points and sharing internals.

On your referenced message I am confused on the issue you raise on
section 3. As I read section 3, I do not see anything that allows
having=C2=A0id-ecPublicKey as an algorithm identifier for these keys.

It's certainly possible I'm m= isunderstanding what section 3 was for. I was kind of confused why there we= re two encodings. I was getting=C2=A0id-ecPublicKey from:

"""
=C2=A0 =C2=A0Section 2.3.5 of [RF= C3279]
=C2=A0 =C2=A0describe ECDSA/ECDH public keys, specifying t= he id-ecPublicKey OID.
=C2=A0 =C2=A0This OID has the associated E= cpkParameters parameters structure,
=C2=A0 =C2=A0which contains t= he namedCurve CHOICE.=C2=A0 Here we introduce two [I think this should be f= our] new OIDs
=C2=A0 =C2=A0for use in the namedCurve field.
&q= uot;""

Anyway, if we go with top-level OIDs for everything= , this is all moot.

David
=C2=A0
Other than this part, you raise a very good point. It may be much
simpler to use a common OID and move it up. Unlike the NIST curves the
constructions we have under the eddsa OID umbrella are quite distinct.

I was concerned about future extensibility and the fact that pureEdDSA
and PrehashedEdDSA could be with separate algorithm OIDs, but after
thinking it further, I think what you suggest is much neater, as having
a single OID to identify scheme+curve will also restrict private keys
to a single purpose which is a good thing.

+1

regards,
Nikos


_______________________________________________
Curdle mailing list
Curdle@ietf.org https://www.ietf.org/mailman/listinfo/curdle


_______________________________________________
Curdle mailing list
<= a href=3D"mailto:Curdle@ietf.org" target=3D"_blank">Curdle@ietf.org
= = https://www.ietf.org/mailman/listinfo/curdle

= _______________________________________________
Curdle mailing list
Curdle@ietf.org https://www.ietf.org/mailman/listinfo/curdle


________________________= _______________________
Curdle mailing list
Curdle@ietf.org
https://www.ietf.org/mailman/listinfo/curdle


--001a1142369843dae20534c9654e-- From nobody Wed Jun 8 13:56:04 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7887E12D580 for ; Wed, 8 Jun 2016 13:56:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.125 X-Spam-Level: X-Spam-Status: No, score=-4.125 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XNabjNNbzNOI for ; Wed, 8 Jun 2016 13:56:01 -0700 (PDT) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5DBC12D1CA for ; Wed, 8 Jun 2016 13:56:00 -0700 (PDT) Received: by mail-io0-x22f.google.com with SMTP id 5so20681195ioy.1 for ; Wed, 08 Jun 2016 13:56:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=4bfR1XPtWOCC9KnwxjdYbhZE067beVTWDo8/eGAQTCg=; b=V/Bg7CLzPPpOQx/64u/cbwJTnih0bL+6d53VKmAcNk7fMTCsFhA5kIr3ysVOTLIrFd hFbbRAU7ry3KMxwHFYyvynA4rvHlqGULOw8xoCaZjP2IYX5JovmqOzqKB9C5HNxTMnGL TGsTPKvZgmZsBp/gRG37Z5/O09eJo9sV4OlSo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=4bfR1XPtWOCC9KnwxjdYbhZE067beVTWDo8/eGAQTCg=; b=NnPCLuPwWfkoYDyO4IhuYxN1QupGFT2t2m7rTi3+8NIj4NxrC0Z7Lgz6/ktWhFzNyk EANrUQo+tdcp8othejmclpTuz513HSa7XIPHbS9sV0cnAUd9B9Q02a7mDgZDHKL3owAm mWgqoiIO8WjGwcY4s+TdwDjLY1VchX+3x/PNykRBfXcPAVi4PC33MqgrW/2LIYCa7tUO 1oEY3F0md90M5rmCh2WRJ++rLLDqjg6mGZdH/Nl/ng4F2FS4MDsyoKkFvZqw/icWRKiQ vHq0Bx0Wx/K6WBrNRJ/zQ4QgBdjAzqXdLJ47xyt/birK0bP30ijhKaurIcGoIyX6aBxj 5Nkg== X-Gm-Message-State: ALyK8tLQAwOk8bsdRO/hiT8Ix79O1nO4jFTpARMT6zQyObqV1h2/m4j22cTf930HDhOHl4mTFA2dddr1Tl70oX08 X-Received: by 10.107.29.80 with SMTP id d77mr12605752iod.97.1465419359894; Wed, 08 Jun 2016 13:55:59 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: David Benjamin Date: Wed, 08 Jun 2016 20:55:50 +0000 Message-ID: To: Brian Smith , curdle@ietf.org Content-Type: multipart/alternative; boundary=001a11408bf265379e0534ca8825 Archived-At: Subject: Re: [Curdle] Proposal: Disallow Ed25519ph/Ed448ph for CA certificates X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 20:56:02 -0000 --001a11408bf265379e0534ca8825 Content-Type: text/plain; charset=UTF-8 I think this is a good idea. No need to add unnecessary knobs for modes that won't (or shouldn't) be used. It would be a shame if we ended up in a world where everyone had to implement the pre-hash algorithms because half of certs used Ed25519ph and half used Ed25519. (In comparison, TLS 1.3 does not currently define a use for them and only uses PureEdDSA.) We could just not bother defining X.509 signature mappings for Ed25519ph and Ed448ph, but it'd be good to explicitly call out that Ed{25519,448}ph + basicConstraints.cA = TRUE is not okay. (Especially if we just use the same OIDs for SPKI and signature algorithms, folks might interpolate.) David On Tue, Jun 7, 2016 at 6:05 PM Brian Smith wrote: > I proposal that the spec be updated to say that certificates with > basicConstraints.cA = TRUE MUST NOT use Ed25519ph or Ed448ph public keys. > > The non-prehash variants are more misuse-resistant than the prehash > variants, which is a particularly important property for CA certificates. > > More generally, in practice it seems likely that Ed25519 (non-prehash) > will be much more ubiquitous than the prehash variants, as the non-prehash > variants are already being used in (non-IETF) protocols that are deployed. > I have seen very little support for the prehash variants, and also very > little need to support for prehash variants. So, for example, my > implementation doesn't support the prehash variants at all. > > Cheers, > Brian > -- > https://briansmith.org/ > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > --001a11408bf265379e0534ca8825 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think this is a good idea. No need to add unnecessary kn= obs for modes that won't (or shouldn't) be used. It would be a sham= e if we ended up in a world where everyone had to implement the pre-hash al= gorithms because half of certs used Ed25519ph and half used Ed25519.

(In comparison, TLS 1.3 does not currently define a use f= or them and only uses PureEdDSA.)

We could just no= t bother defining X.509 signature mappings for Ed25519ph and Ed448ph, but i= t'd be good to explicitly call out that Ed{25519,448}ph=C2=A0+ basicCon= straints.cA =3D TRUE is not okay. (Especially if we just use the same OIDs = for SPKI and signature algorithms, folks might interpolate.)
<= br>
David

On T= ue, Jun 7, 2016 at 6:05 PM Brian Smith <brian@briansmith.org> wrote:
I proposal that the spec be updated to say that c= ertificates with basicConstraints.cA =3D TRUE MUST NOT use Ed25519ph or Ed4= 48ph public keys.

The non-prehash variants are more misu= se-resistant than the prehash variants, which is a particularly important p= roperty for CA certificates.

More generally, in pr= actice it seems likely that Ed25519 (non-prehash) will be much more ubiquit= ous than the prehash variants, as the non-prehash variants are already bein= g used in (non-IETF) protocols that are deployed. I have seen very little s= upport for the prehash variants, and also very little need to support for p= rehash variants. So, for example, my implementation doesn't support the= prehash variants at all.

Cheers,
Brian<= br>--
_______________________________________________
Curdle mailing list
Curdle@ietf.org https://www.ietf.org/mailman/listinfo/curdle
--001a11408bf265379e0534ca8825-- From nobody Fri Jun 10 00:16:45 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10AD312DAC4 for ; Fri, 10 Jun 2016 00:16:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.648 X-Spam-Level: X-Spam-Status: No, score=-5.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oV0X4qVPyIJZ for ; Fri, 10 Jun 2016 00:16:42 -0700 (PDT) Received: from mx5-phx2.redhat.com (mx5-phx2.redhat.com [209.132.183.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4886912DAB5 for ; Fri, 10 Jun 2016 00:16:42 -0700 (PDT) Received: from zmail22.collab.prod.int.phx2.redhat.com (zmail22.collab.prod.int.phx2.redhat.com [10.5.83.26]) by mx5-phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u5A7GcYO059097; Fri, 10 Jun 2016 03:16:38 -0400 Date: Fri, 10 Jun 2016 03:16:38 -0400 (EDT) From: Nikos Mavrogiannopoulos To: Daniel Migault Message-ID: <1553247361.41476124.1465542998520.JavaMail.zimbra@redhat.com> In-Reply-To: References: <1463470661.2914.4.camel@redhat.com> <1463647224.3558.14.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.10.61.108] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF45 (Linux)/8.0.6_GA_5922) Thread-Topic: draft-ietf-curdle-pkix-00: a simplification proposal Thread-Index: niLESm7ARCNcIR6MeC+3bYArKn20rA== Archived-At: Cc: curdle@ietf.org Subject: Re: [Curdle] draft-ietf-curdle-pkix-00: a simplification proposal X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 07:16:44 -0000 I support this. ----- Original Message ----- Hi, Do we have some consensus that having top-level OID would be better ? Please provide your opinion and let the WG know your thoughts so the document can be moved forward. BR, Daniel On Thu, May 19, 2016 at 10:41 AM, David Benjamin wrote: > On Thu, May 19, 2016 at 4:40 AM Nikos Mavrogiannopoulos > wrote: > >> On Tue, 2016-05-17 at 14:20 +0000, David Benjamin wrote: >> > I would actually advocate a different change. I sent this message >> > earlier: >> > https://www.ietf.org/mail-archive/web/curdle/current/msg00203.html >> > >> > Rather than use parameters, allocate new algorithm OIDs for >> > everything. I don't think we actually gain anything by exposing the >> > relations and parameterizations between these algorithms. When >> > implementing, they are great for sharing code. But when consuming, >> > exposing it makes parsing more complex, and it increases the risk of >> > reusing keys between related algorithms. We can get the best of both >> > worlds by separating entry-points and sharing internals. >> >> On your referenced message I am confused on the issue you raise on >> section 3. As I read section 3, I do not see anything that allows >> having id-ecPublicKey as an algorithm identifier for these keys. >> > > It's certainly possible I'm misunderstanding what section 3 was for. I was > kind of confused why there were two encodings. I was getting id-ecPublicKey > from: > > """ > Section 2.3.5 of [RFC3279] > describe ECDSA/ECDH public keys, specifying the id-ecPublicKey OID. > This OID has the associated EcpkParameters parameters structure, > which contains the namedCurve CHOICE. Here we introduce two [I think > this should be four] new OIDs > for use in the namedCurve field. > """ > > Anyway, if we go with top-level OIDs for everything, this is all moot. > > David > > >> Other than this part, you raise a very good point. It may be much >> simpler to use a common OID and move it up. Unlike the NIST curves the >> constructions we have under the eddsa OID umbrella are quite distinct. >> >> I was concerned about future extensibility and the fact that pureEdDSA >> and PrehashedEdDSA could be with separate algorithm OIDs, but after >> thinking it further, I think what you suggest is much neater, as having >> a single OID to identify scheme+curve will also restrict private keys >> to a single purpose which is a good thing. >> >> +1 >> >> regards, >> Nikos >> >> > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > > From nobody Fri Jun 10 02:18:47 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2BB512D0DF for ; Fri, 10 Jun 2016 02:18:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.348 X-Spam-Level: X-Spam-Status: No, score=-8.348 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kaNH5LiwhZfm for ; Fri, 10 Jun 2016 02:18:44 -0700 (PDT) Received: from mx3-phx2.redhat.com (mx3-phx2.redhat.com [209.132.183.24]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3190112D924 for ; Fri, 10 Jun 2016 02:18:42 -0700 (PDT) Received: from zmail22.collab.prod.int.phx2.redhat.com (zmail22.collab.prod.int.phx2.redhat.com [10.5.83.26]) by mx3-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id u5A9IeiV028082; Fri, 10 Jun 2016 05:18:40 -0400 Date: Fri, 10 Jun 2016 05:18:40 -0400 (EDT) From: Nikos Mavrogiannopoulos To: Brian Smith Message-ID: <966179343.41495845.1465550320727.JavaMail.zimbra@redhat.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.10.61.108] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF45 (Linux)/8.0.6_GA_5922) Thread-Topic: Proposal: Disallow Ed25519ph/Ed448ph for CA certificates Thread-Index: a/wC8Tlg79cK18vKFEu3TIICq+4Dog== Archived-At: Cc: curdle@ietf.org Subject: Re: [Curdle] Proposal: Disallow Ed25519ph/Ed448ph for CA certificates X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 09:18:46 -0000 Don't underestimate the value of the prehash variant. How would you hash a 1GB file using an 8-bit smart card? Today you simply pass the hash and get back and RSA or ECDSA signature, but with the ed25519 plain variant you have to pipe the whole file through the card. I'm not really happy with the variants available as we end up with situations where two implementations will implement the draft and still be incompatible between them (in fact your implementation will be incompatible with mine as I've gone for the prehashed variants only). regards, Nikos ----- Original Message ----- I proposal that the spec be updated to say that certificates with basicConstraints.cA = TRUE MUST NOT use Ed25519ph or Ed448ph public keys. The non-prehash variants are more misuse-resistant than the prehash variants, which is a particularly important property for CA certificates. More generally, in practice it seems likely that Ed25519 (non-prehash) will be much more ubiquitous than the prehash variants, as the non-prehash variants are already being used in (non-IETF) protocols that are deployed. I have seen very little support for the prehash variants, and also very little need to support for prehash variants. So, for example, my implementation doesn't support the prehash variants at all. Cheers, Brian -- https://briansmith.org/ _______________________________________________ Curdle mailing list Curdle@ietf.org https://www.ietf.org/mailman/listinfo/curdle From nobody Fri Jun 10 07:26:16 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B77612D666 for ; Fri, 10 Jun 2016 07:26:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cD-q26zNaA-x for ; Fri, 10 Jun 2016 07:26:14 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) by ietfa.amsl.com (Postfix) with ESMTP id 78AC212D0E9 for ; Fri, 10 Jun 2016 07:26:14 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 34336F98B; Fri, 10 Jun 2016 10:26:13 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id D50F7203D8; Fri, 10 Jun 2016 10:26:12 -0400 (EDT) From: Daniel Kahn Gillmor To: Nikos Mavrogiannopoulos , Brian Smith In-Reply-To: <966179343.41495845.1465550320727.JavaMail.zimbra@redhat.com> References: <966179343.41495845.1465550320727.JavaMail.zimbra@redhat.com> User-Agent: Notmuch/0.22+47~g4441900 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Fri, 10 Jun 2016 10:26:12 -0400 Message-ID: <87h9d1aznf.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: curdle@ietf.org Subject: Re: [Curdle] Proposal: Disallow Ed25519ph/Ed448ph for CA certificates X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 14:26:15 -0000 On Fri 2016-06-10 05:18:40 -0400, Nikos Mavrogiannopoulos wrote: > Don't underestimate the value of the prehash variant. How would you hash > a 1GB file using an 8-bit smart card? Today you simply pass the hash and > get back and RSA or ECDSA signature, but with the ed25519 plain variant > you have to pipe the whole file through the card. This proposal was just for CA certificates, though. What CA needs to sign a 1GB file? --dkg From nobody Fri Jun 10 20:44:38 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 567AE12D681 for ; Fri, 10 Jun 2016 20:44:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.428 X-Spam-Level: X-Spam-Status: No, score=-3.428 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=usaa.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LK8OmmvJ5hVZ for ; Fri, 10 Jun 2016 20:44:35 -0700 (PDT) Received: from prodomx102l.usaa.com (prodomx102l.usaa.com [167.24.25.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1A2812D1AC for ; Fri, 10 Jun 2016 20:44:33 -0700 (PDT) Received: from pps.filterd (prodomx102l.usaa.com [127.0.0.1]) by prodomx102l.usaa.com (8.15.0.59/8.15.0.59) with SMTP id u5B3iGUR006940; Fri, 10 Jun 2016 22:44:31 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=usaa.com; h=from : to : cc : subject : date : message-id : content-type : content-transfer-encoding : mime-version; s=201408; bh=Af/cWymL+ObEVCrHrGye/9spIfr/O++jJ7rt7Cqefjs=; b=tLI4w150lFj7tk5Iutxgj6/RG/LRsMujdEeyfEiJIGlXo5QbvV3JWpHMJJ8sKnM2dcEz KJkvnx0XcuRYwJJnNFI1TBAx9eNXwgTo9m0ej+DLe47QmNGDYMTT2+ypZPmzjGzgoJWh HzFtm3ESaUaJwI2uFf+sTJZgG31yDoSMo2Hk+/9EtIBbrWY3ET7TvrO4ohGaydTbfEhT w1NVGvmmASFsZOT0N566Q+YPh7YoLg+FtJ/yXIpgRGA8m+R0fx/yGrrtJTeKYp1FaTLh 2Cuku9ZV7FWFRSdUms9YIOCk1aHj8h7WVRzzIFz8jY2NgbW7NYDcm3kDSUA2cSuf6Is8 RQ== Received: from pps.reinject (localhost [127.0.0.1]) by prodomx102l.usaa.com with ESMTP id 23e37qbcns-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 10 Jun 2016 22:44:31 -0500 Received: from prodomx102l.usaa.com (prodomx102l.usaa.com [127.0.0.1]) by pps.reinject (8.15.0.59/8.15.0.59) with SMTP id u5B3iUSN007393; Fri, 10 Jun 2016 22:44:30 -0500 Received: from prodexch04w.eagle.usaa.com (prodexch04w.usaa.com [10.170.40.30]) by prodomx102l.usaa.com with ESMTP id 23e37qbcnq-1; Fri, 10 Jun 2016 22:44:30 -0500 Received: from PRODEXMB01W.eagle.usaa.com ([169.254.1.183]) by PRODEXCH04W.eagle.usaa.com ([10.170.40.30]) with mapi id 14.03.0210.002; Fri, 10 Jun 2016 22:44:30 -0500 From: "Mehner, Carl" To: Daniel Kahn Gillmor , Nikos Mavrogiannopoulos , Brian Smith Thread-Topic: [Curdle] Proposal: Disallow Ed25519ph/Ed448ph for CA certificates Thread-Index: AdHDkcAVHsmWyRoITBKHfA37K5jdGA== Date: Sat, 11 Jun 2016 03:44:29 +0000 Message-ID: <19075EB00EA7FE49AFF87E5818D673D4138D60C7@PRODEXMB01W.eagle.usaa.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-c2processedorg: b8bcc573-fb52-4e08-924e-ca559c360d81 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "curdle@ietf.org" Subject: Re: [Curdle] Proposal: Disallow Ed25519ph/Ed448ph for CA certificates X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2016 03:44:37 -0000 Sometimes I just need to have a certificate "including a 1 gigabit MPEG mov= ie of me playing with my cat"[1] [1] https://www.cs.auckland.ac.nz/~pgut001/pubs/x509guide.txt > -----Original Message----- > From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Daniel Kahn > Gillmor > Sent: Friday, June 10, 2016 9:26 AM > To: Nikos Mavrogiannopoulos ; Brian Smith > > Cc: curdle@ietf.org > Subject: EXTERNAL: Re: [Curdle] Proposal: Disallow Ed25519ph/Ed448ph for > CA certificates >=20 > On Fri 2016-06-10 05:18:40 -0400, Nikos Mavrogiannopoulos wrote: > > Don't underestimate the value of the prehash variant. How would you has= h > > a 1GB file using an 8-bit smart card? Today you simply pass the hash an= d > > get back and RSA or ECDSA signature, but with the ed25519 plain variant > > you have to pipe the whole file through the card. >=20 > This proposal was just for CA certificates, though. What CA needs to > sign a 1GB file? >=20 > --dkg >=20 > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle From nobody Mon Jun 13 01:02:50 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFFAF12B010 for ; Mon, 13 Jun 2016 01:02:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.348 X-Spam-Level: X-Spam-Status: No, score=-8.348 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zvtb5Po_xyIH for ; Mon, 13 Jun 2016 01:02:47 -0700 (PDT) Received: from mx3-phx2.redhat.com (mx3-phx2.redhat.com [209.132.183.24]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98CD712D0DD for ; Mon, 13 Jun 2016 01:02:47 -0700 (PDT) Received: from zmail22.collab.prod.int.phx2.redhat.com (zmail22.collab.prod.int.phx2.redhat.com [10.5.83.26]) by mx3-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id u5D82hIW003680; Mon, 13 Jun 2016 04:02:44 -0400 Date: Mon, 13 Jun 2016 04:02:42 -0400 (EDT) From: Nikos Mavrogiannopoulos To: Daniel Kahn Gillmor Message-ID: <1567944430.41904732.1465804962129.JavaMail.zimbra@redhat.com> In-Reply-To: <87h9d1aznf.fsf@alice.fifthhorseman.net> References: <966179343.41495845.1465550320727.JavaMail.zimbra@redhat.com> <87h9d1aznf.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.10.61.167] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF45 (Linux)/8.0.6_GA_5922) Thread-Topic: Proposal: Disallow Ed25519ph/Ed448ph for CA certificates Thread-Index: W1P9bfy0KH6JjnQNebYsj3K+4xJP1A== Archived-At: Cc: curdle@ietf.org, Brian Smith Subject: Re: [Curdle] Proposal: Disallow Ed25519ph/Ed448ph for CA certificates X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2016 08:02:48 -0000 I believe my answer was targeted to the second part of the mail which mentioned that Brian's implementation will not support the ed25519ph variant. About the first part if I can add is that it is indifferent to me whether this restriction is added or not. The CAs that require that kind of security can always use that algorithm even if IETF doesn't mandate it. On the other hand I don't like this type of restrictions because they only complicate things (if for example I have an application which handles only ed25519ph why should I not be able to use it to make a local CA?) regards, Nikos ----- Original Message ----- On Fri 2016-06-10 05:18:40 -0400, Nikos Mavrogiannopoulos wrote: > Don't underestimate the value of the prehash variant. How would you hash > a 1GB file using an 8-bit smart card? Today you simply pass the hash and > get back and RSA or ECDSA signature, but with the ed25519 plain variant > you have to pipe the whole file through the card. This proposal was just for CA certificates, though. What CA needs to sign a 1GB file? --dkg From nobody Mon Jun 13 03:13:02 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07C3812D10B for ; Mon, 13 Jun 2016 03:13:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D8FAWFAyc2Ce for ; Mon, 13 Jun 2016 03:12:58 -0700 (PDT) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0104.outbound.protection.outlook.com [23.103.201.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 916C912B00F for ; Mon, 13 Jun 2016 03:12:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=/mBDNsb7BeEJmOdrmTPb1FYFtyq4k0Hea4gQleX10vs=; b=x5dNUqHsDNmnACqlVte0Sy7uwa15TxAYaZGSe8U9UF8yjf0k/7eiurOVSxSOzAcM/rum2WhEBqDX8Hni4YiVCuBC9bcgsCWmhe1DOII2cPdQOhnAudEKFhcG4/izgMelLK5cXgWjnWQM4Z3nXKqIcNXRmIec/PhH9ZlWbaPEZyA= Received: from BN1PR09MB124.namprd09.prod.outlook.com (10.255.200.27) by BN1PR09MB124.namprd09.prod.outlook.com (10.255.200.27) with Microsoft SMTP Server (TLS) id 15.1.501.7; Mon, 13 Jun 2016 10:12:55 +0000 Received: from BN1PR09MB124.namprd09.prod.outlook.com ([10.255.200.27]) by BN1PR09MB124.namprd09.prod.outlook.com ([10.255.200.27]) with mapi id 15.01.0501.012; Mon, 13 Jun 2016 10:12:55 +0000 From: "Dang, Quynh (Fed)" To: "Mehner, Carl" , Daniel Kahn Gillmor , Nikos Mavrogiannopoulos , "Brian Smith" Thread-Topic: [Curdle] Proposal: Disallow Ed25519ph/Ed448ph for CA certificates Thread-Index: AQHRxVwngjz3ROyj6EeEA3FZ6CwF+g== Date: Mon, 13 Jun 2016 10:12:55 +0000 Message-ID: References: <19075EB00EA7FE49AFF87E5818D673D4138D60C7@PRODEXMB01W.eagle.usaa.com> In-Reply-To: <19075EB00EA7FE49AFF87E5818D673D4138D60C7@PRODEXMB01W.eagle.usaa.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 authentication-results: spf=none (sender IP is ) smtp.mailfrom=quynh.dang@nist.gov; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [129.6.220.241] x-ms-office365-filtering-correlation-id: e5d1bf44-f0c8-4f09-8117-08d3937349e7 x-microsoft-exchange-diagnostics: 1; BN1PR09MB124; 5:kyNguCbJhctwgbJ5AAtf7RGTI+31uVC7DKOPvJRYyAT6Ahm191KACs81aSqlKsawR/9Reh3GSccDVtwqa2Vg5zeib2yTTaaN/9C/7GuSWMcEAbtHH33o120RbKDwo4enrtNEjcNnFnYul07OQMcsfQ==; 24:qDiWWK9jiSlI+GL8Qyttvd+2NkXAKUZiZITNyXDyEVe8SKSh7psxvHZI96FgKC2djKVpwyfrLYP/uuqCdBeFdg3QZthnz82dL1rRvAogJ4w=; 7:yXTZqLzyWMcS+0KJDJDfBeqn2kG8LSAYNI4bBXg87+eH8Y7s8Hh/qE8yWeB7uKSl3d+ZHgO8xUk/dce52TE3ypXxIt43PkElsIMvy9e7yFSt7sxES5ff0uMfAG8WgBQuIVc9nlL1FmwDunReCrydPbcIxPAj89RfLTSAZpm57LfmmpMx5us/KQWV5Lc6tTDuqkTIh0ySZSIKpEzwERjKQg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR09MB124; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026); SRVR:BN1PR09MB124; BCL:0; PCL:0; RULEID:; SRVR:BN1PR09MB124; x-forefront-prvs: 0972DEC1D9 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(24454002)(189002)(13464003)(377424004)(53754006)(377454003)(199003)(66066001)(6116002)(106356001)(77096005)(8936002)(586003)(5008740100001)(36756003)(19580405001)(54356999)(81166006)(8676002)(86362001)(92566002)(189998001)(10400500002)(50986999)(4326007)(105586002)(11100500001)(561944003)(2900100001)(2906002)(2950100001)(5001770100001)(99286002)(4001350100001)(97736004)(87936001)(83506001)(3280700002)(5004730100002)(3660700001)(122556002)(76176999)(102836003)(68736007)(5002640100001)(106116001)(101416001)(15975445007)(3846002)(19580395003)(81156014); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR09MB124; H:BN1PR09MB124.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-ID: <5CE7CB16F7BD39499DBB208DE25B5328@namprd09.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jun 2016 10:12:55.6521 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR09MB124 Archived-At: Cc: "curdle@ietf.org" Subject: Re: [Curdle] Proposal: Disallow Ed25519ph/Ed448ph for CA certificates X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2016 10:13:01 -0000 Hi all, Prehash or non-prehash, choosing the one which works well for all uses (not just signing certs) is the right thing to do. I don=B9t know how much the non-prehash version is actually used right now (different from how much it is supported in libraries). Regards, Quynh.=20 On 6/10/16, 11:44 PM, "Curdle on behalf of Mehner, Carl" wrote: >Sometimes I just need to have a certificate "including a 1 gigabit MPEG >movie of me playing with my cat"[1] > > >[1] https://www.cs.auckland.ac.nz/~pgut001/pubs/x509guide.txt > >> -----Original Message----- >> From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Daniel Kahn >> Gillmor >> Sent: Friday, June 10, 2016 9:26 AM >> To: Nikos Mavrogiannopoulos ; Brian Smith >> >> Cc: curdle@ietf.org >> Subject: EXTERNAL: Re: [Curdle] Proposal: Disallow Ed25519ph/Ed448ph for >> CA certificates >>=20 >> On Fri 2016-06-10 05:18:40 -0400, Nikos Mavrogiannopoulos wrote: >> > Don't underestimate the value of the prehash variant. How would you >>hash >> > a 1GB file using an 8-bit smart card? Today you simply pass the hash >>and >> > get back and RSA or ECDSA signature, but with the ed25519 plain >>variant >> > you have to pipe the whole file through the card. >>=20 >> This proposal was just for CA certificates, though. What CA needs to >> sign a 1GB file? >>=20 >> --dkg >>=20 >> _______________________________________________ >> Curdle mailing list >> Curdle@ietf.org >> https://www.ietf.org/mailman/listinfo/curdle > >_______________________________________________ >Curdle mailing list >Curdle@ietf.org >https://www.ietf.org/mailman/listinfo/curdle From nobody Mon Jun 13 23:48:29 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DBC512D8FF for ; Mon, 13 Jun 2016 23:48:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Y4Q86RYy8tv for ; Mon, 13 Jun 2016 23:48:27 -0700 (PDT) Received: from mail-qg0-x235.google.com (mail-qg0-x235.google.com [IPv6:2607:f8b0:400d:c04::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7E7612B018 for ; Mon, 13 Jun 2016 23:48:25 -0700 (PDT) Received: by mail-qg0-x235.google.com with SMTP id v76so48210264qgv.3 for ; Mon, 13 Jun 2016 23:48:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=CQiPEzYoWnyLbOYXvM9KXNHn4JGGqoEL4bDjaCY/HBM=; b=a/aVfa9LZZ4FfQn4EIfvspHDPefl6db5aC9lphCIzRC3ANT2ShGBvYxaahDHiOjOFJ Nv9nmzvs33VbMPpKHsq1AKvUEbbWEmdkkQq6te4AM8HkBz6kjVmGHF+MkfJ9UHAZIw44 45SBc7ISr3TgYqORPyOVKo3LSQnT1I3hd4n5CH9MkoKenu/TFKAQcUX53BkPsJaoSFCA gTRhdnFlnvX2/NwQloyk3A+6c+m0Q2WndRlRcQ7vBUNLXbcBxeF8k3WP392YrrPHNvIL MeCzvKaluBFGkCKtbjn+OS0bHa3/ZM60UsW7XDvJsf86DVqagAatPpdQb+6VQsdaQ6nK 1AhA== 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:from:date :message-id:subject:to:cc; bh=CQiPEzYoWnyLbOYXvM9KXNHn4JGGqoEL4bDjaCY/HBM=; b=KSF1hp+BxJrQ6rTcT210bmQy5RMvO5fZHLWHhVD40lpqPFLprj2FkF6O0XrgLgUbi8 g7vFZNt1628pW0B9AnZjASuuMOTThNevr5sDL4pNpJvog4vKQx4bofKXlUfSpBoD1Yms f6q0AuH6kveWGc9cWvkxxsalpkxTSQ0WBAipZz6C2s71boLQPwlHJb9QROJoR5QeBefe tUhzyo9RckSIqw0z7hrrR7scNs4crrCED+ljJZsilO8J4/ac5xiMqlPfz9qt8FgX3arG jHJFh0AKFa8OYqqhAhfglSN41ePq8wfS1jQDe8+5jdDecGTKu6lVb5taRi3zaZGbvXIB p5ig== X-Gm-Message-State: ALyK8tLdB+8zX7Ov+kASMac+Y+ibYe7Z9vp9DXkiPE81J8JDeuh25NYOF4cMWoWrPm6VintUk4NmvIEWc9qkng== X-Received: by 10.140.163.193 with SMTP id j184mr18362343qhj.40.1465886904934; Mon, 13 Jun 2016 23:48:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.104.37 with HTTP; Mon, 13 Jun 2016 23:48:24 -0700 (PDT) In-Reply-To: <1567944430.41904732.1465804962129.JavaMail.zimbra@redhat.com> References: <966179343.41495845.1465550320727.JavaMail.zimbra@redhat.com> <87h9d1aznf.fsf@alice.fifthhorseman.net> <1567944430.41904732.1465804962129.JavaMail.zimbra@redhat.com> From: Martin Thomson Date: Tue, 14 Jun 2016 07:48:24 +0100 Message-ID: To: Nikos Mavrogiannopoulos Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: curdle@ietf.org, Brian Smith , Daniel Kahn Gillmor Subject: Re: [Curdle] Proposal: Disallow Ed25519ph/Ed448ph for CA certificates X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2016 06:48:28 -0000 On 13 June 2016 at 09:02, Nikos Mavrogiannopoulos wrote: > (if for example I have an application > which handles only ed25519ph why should I not be able to use it to make > a local CA?) That's an easy question to answer. Ask the same question with a completely different signature algorithm. For instance, DSA. If you choose to implement an algorithm that isn't used by other people, you lose. There is a distinct benefit to having a very narrow set of signature algorithms supported by the PKI. In this case, ed25519 (pure) is the right choice for all the aforementioned reasons. From nobody Tue Jun 14 01:10:12 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 441DF12D0B2 for ; Tue, 14 Jun 2016 01:10:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.348 X-Spam-Level: X-Spam-Status: No, score=-8.348 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OmA9ADjSi4vA for ; Tue, 14 Jun 2016 01:10:10 -0700 (PDT) Received: from mx3-phx2.redhat.com (mx3-phx2.redhat.com [209.132.183.24]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E684F127078 for ; Tue, 14 Jun 2016 01:10:09 -0700 (PDT) Received: from zmail22.collab.prod.int.phx2.redhat.com (zmail22.collab.prod.int.phx2.redhat.com [10.5.83.26]) by mx3-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id u5E8A5ws020039; Tue, 14 Jun 2016 04:10:05 -0400 Date: Tue, 14 Jun 2016 04:10:04 -0400 (EDT) From: Nikos Mavrogiannopoulos To: Martin Thomson Message-ID: <71518266.42114946.1465891804431.JavaMail.zimbra@redhat.com> In-Reply-To: References: <966179343.41495845.1465550320727.JavaMail.zimbra@redhat.com> <87h9d1aznf.fsf@alice.fifthhorseman.net> <1567944430.41904732.1465804962129.JavaMail.zimbra@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.10.48.157] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF45 (Linux)/8.0.6_GA_5922) Thread-Topic: Proposal: Disallow Ed25519ph/Ed448ph for CA certificates Thread-Index: a9tkg9cQruJtgHORWOqKCNGoGPdmug== Archived-At: Cc: curdle@ietf.org, Brian Smith , Daniel Kahn Gillmor Subject: Re: [Curdle] Proposal: Disallow Ed25519ph/Ed448ph for CA certificates X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2016 08:10:12 -0000 If you believe so then push for making that the only option rather than creating a complex situation for everyone. ----- Original Message ----- On 13 June 2016 at 09:02, Nikos Mavrogiannopoulos wrote: > (if for example I have an application > which handles only ed25519ph why should I not be able to use it to make > a local CA?) That's an easy question to answer. Ask the same question with a completely different signature algorithm. For instance, DSA. If you choose to implement an algorithm that isn't used by other people, you lose. There is a distinct benefit to having a very narrow set of signature algorithms supported by the PKI. In this case, ed25519 (pure) is the right choice for all the aforementioned reasons. _______________________________________________ Curdle mailing list Curdle@ietf.org https://www.ietf.org/mailman/listinfo/curdle From nobody Tue Jun 14 03:45:42 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E416712D7C1 for ; Tue, 14 Jun 2016 03:45:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AFcXzJ-PyEAQ for ; Tue, 14 Jun 2016 03:45:38 -0700 (PDT) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0116.outbound.protection.outlook.com [23.103.201.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5172712D7BC for ; Tue, 14 Jun 2016 03:45:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=8XJ7YYzxx1bZyctL6AfswfojdZxNU1p3NCFbBhWRLAg=; b=0hBdo0wLS5y1NVGZUDRTXmD9QdjSBzQNteBifgnBp1gde5xv1acksGTyP6Y8m3oMldT5M14TnOVrRv9GYdGRo7dn5k5eQKEBSMmIuWeXMraDcE7Cvb9T4TuxdcCNARgQyN5oXqUsdTTV6nfBfgY+VSybZ4JiksaNeXd2c7KDJDA= Received: from BN1PR09MB124.namprd09.prod.outlook.com (10.255.200.27) by BN1PR09MB123.namprd09.prod.outlook.com (10.255.200.25) with Microsoft SMTP Server (TLS) id 15.1.501.7; Tue, 14 Jun 2016 10:45:36 +0000 Received: from BN1PR09MB124.namprd09.prod.outlook.com ([10.255.200.27]) by BN1PR09MB124.namprd09.prod.outlook.com ([10.255.200.27]) with mapi id 15.01.0501.012; Tue, 14 Jun 2016 10:45:36 +0000 From: "Dang, Quynh (Fed)" To: Martin Thomson , Nikos Mavrogiannopoulos Thread-Topic: [Curdle] Proposal: Disallow Ed25519ph/Ed448ph for CA certificates Thread-Index: AQHRxiniq1lEvBTTnEOedyW6Lb0dXw== Date: Tue, 14 Jun 2016 10:45:36 +0000 Message-ID: References: <966179343.41495845.1465550320727.JavaMail.zimbra@redhat.com> <87h9d1aznf.fsf@alice.fifthhorseman.net> <1567944430.41904732.1465804962129.JavaMail.zimbra@redhat.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 authentication-results: spf=none (sender IP is ) smtp.mailfrom=quynh.dang@nist.gov; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [129.6.105.150] x-ms-office365-filtering-correlation-id: 6c970c61-5ca2-4447-8a90-08d3944104dc x-microsoft-exchange-diagnostics: 1; BN1PR09MB123; 5:dEv/JZ11lS+A6XLZi5Svt7V9EB4HTjgOtMu8DLGPyawHCJem4zUv+pS4V21DWR93dmVFyQz9RBr4VJwknEwO4SGBt3hn9TKQ+/9U55njQH+3H7udugB5QYXBglGGnhP6pfG7Yq6BgCGlwl76HftTXg==; 24:F2KX+rzKPqjVlWEWlSaJP45CcTwhjI1uGkwr46tHfqXky8f2Kg1YzbHqGrhgykPQgjo4oLC87PDREvlZslyK1MvC2quINGfXtCEL/HFv2F0=; 7:Iko9hwl7ArJrvpXNglOB2TVMxP9UD3KNM50M8E3EDvpMQtYXi8tZ7DF7d7ISOHPSLRdQLMV72+M2NIYYMN1w2mdESaLZJUdaNlT38FqMlWVu0z0v8WPYpN92K5t6mvxhetH2Ymeq0JZ+ZLgiAEZtm7Hokd7wwf87gx3vDw4EFHP3gvKd0J4pK9FhSezTNrUJnwbT3b3U72z6dYXmIKwccg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR09MB123; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026); SRVR:BN1PR09MB123; BCL:0; PCL:0; RULEID:; SRVR:BN1PR09MB123; x-forefront-prvs: 09730BD177 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(24454002)(377454003)(199003)(189002)(122556002)(86362001)(4326007)(66066001)(99286002)(106116001)(2906002)(106356001)(105586002)(586003)(3846002)(11100500001)(102836003)(6116002)(83506001)(10400500002)(8936002)(19580405001)(5004730100002)(77096005)(36756003)(5002640100001)(19580395003)(76176999)(54356999)(2950100001)(189998001)(2900100001)(87936001)(15975445007)(3280700002)(93886004)(101416001)(5008740100001)(92566002)(81166006)(81156014)(8676002)(50986999)(97736004)(3660700001)(68736007)(5001770100001)(4001350100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR09MB123; H:BN1PR09MB124.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-ID: <396AEC6FCF4D7A4CBF34A01B80721AE2@namprd09.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jun 2016 10:45:36.0657 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR09MB123 Archived-At: Cc: "curdle@ietf.org" , Brian Smith , Daniel Kahn Gillmor Subject: Re: [Curdle] Proposal: Disallow Ed25519ph/Ed448ph for CA certificates X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2016 10:45:41 -0000 Hi Martin, EdDsa is the most recommended signature algorithm by SAAG/IETF now. This signature algorithm will be much used in the future until practical quantum computers become available. This period of time could be 10, 20 or more years. I believe we are in an early stage of using EdDSA and pureEdDSA is not widely used yet. In addition, I believe that adding support for Eddsa_ph is not too costly because the hash function is already available in the code for pureEddsa already. One signature algorithm works well for all uses would be a win win for the IETF and everyone else in the security world. Regards, Quynh.=20 On 6/14/16, 2:48 AM, "Curdle on behalf of Martin Thomson" wrote: >On 13 June 2016 at 09:02, Nikos Mavrogiannopoulos wrote: >> (if for example I have an application >> which handles only ed25519ph why should I not be able to use it to make >> a local CA?) > >That's an easy question to answer. Ask the same question with a >completely different signature algorithm. For instance, DSA. If you >choose to implement an algorithm that isn't used by other people, you >lose. There is a distinct benefit to having a very narrow set of >signature algorithms supported by the PKI. In this case, ed25519 >(pure) is the right choice for all the aforementioned reasons. > >_______________________________________________ >Curdle mailing list >Curdle@ietf.org >https://www.ietf.org/mailman/listinfo/curdle From nobody Tue Jun 14 07:25:29 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F99D12DBA4 for ; Tue, 14 Jun 2016 07:25:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cnQNUb9_yVZR for ; Tue, 14 Jun 2016 07:25:07 -0700 (PDT) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id 51FE312DBB8 for ; Tue, 14 Jun 2016 07:25:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 8C95E3B47; Tue, 14 Jun 2016 17:25:05 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id tN61L2EDdyQv; Tue, 14 Jun 2016 17:25:05 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-224-2.bb.dnainternet.fi [87.100.224.2]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 4821821C; Tue, 14 Jun 2016 17:25:05 +0300 (EEST) Date: Tue, 14 Jun 2016 17:25:02 +0300 From: Ilari Liusvaara To: "Dang, Quynh (Fed)" Message-ID: <20160614142502.GA8706@LK-Perkele-V2.elisa-laajakaista.fi> References: <966179343.41495845.1465550320727.JavaMail.zimbra@redhat.com> <87h9d1aznf.fsf@alice.fifthhorseman.net> <1567944430.41904732.1465804962129.JavaMail.zimbra@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Sender: ilariliusvaara@welho.com Archived-At: Cc: "curdle@ietf.org" Subject: Re: [Curdle] Proposal: Disallow Ed25519ph/Ed448ph for CA certificates X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2016 14:25:15 -0000 On Tue, Jun 14, 2016 at 10:45:36AM +0000, Dang, Quynh (Fed) wrote: > I believe we are in an early stage of using EdDSA and pureEdDSA is not > widely used yet. In addition, I believe that adding support for Eddsa_ph > is not too costly because the hash function is already available in the > code for pureEddsa already. Eeh... I thought almost all use of EdDSA was Ed25519 (with possibly ad-hoc prehashing depending on application), and use of Ed25519ph is almost nonexistent. Also, remember that use of the same key as Ed25519 and Ed25519ph key must not be allowed (due to well-known problems). -Ilari From nobody Tue Jun 14 08:21:19 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75BB412D7D2 for ; Tue, 14 Jun 2016 08:21:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cg4K3-m1Gj9L for ; Tue, 14 Jun 2016 08:21:16 -0700 (PDT) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0127.outbound.protection.outlook.com [23.103.201.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A63A212D759 for ; Tue, 14 Jun 2016 08:21:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Qqbn74O113uGPRyQgmXUaasGY6XiZg9c2O02k2EwXNw=; b=YtL9MfA+q1UFG+DupWaKMFZ0bRkR8oV8SkcaVU+bm0c1w7oH4P+YD2lDp0FnuJc1K/10zlyrEDZ3c0vsUoBaoNBbvq/GZEvDLd2q716urLAcNFH9Znz9ux1SxfH0NtbgA1DR9+3V5lDV7Geu9A878c2nF/iHcrG8x1V3q2CA0D8= Received: from BN1PR09MB124.namprd09.prod.outlook.com (10.255.200.27) by BN1PR09MB124.namprd09.prod.outlook.com (10.255.200.27) with Microsoft SMTP Server (TLS) id 15.1.501.7; Tue, 14 Jun 2016 15:21:15 +0000 Received: from BN1PR09MB124.namprd09.prod.outlook.com ([10.255.200.27]) by BN1PR09MB124.namprd09.prod.outlook.com ([10.255.200.27]) with mapi id 15.01.0501.012; Tue, 14 Jun 2016 15:21:15 +0000 From: "Dang, Quynh (Fed)" To: Ilari Liusvaara , "Dang, Quynh (Fed)" Thread-Topic: [Curdle] Proposal: Disallow Ed25519ph/Ed448ph for CA certificates Thread-Index: AQHRxiniq1lEvBTTnEOedyW6Lb0dX5/pBL8A///MowA= Date: Tue, 14 Jun 2016 15:21:14 +0000 Message-ID: References: <966179343.41495845.1465550320727.JavaMail.zimbra@redhat.com> <87h9d1aznf.fsf@alice.fifthhorseman.net> <1567944430.41904732.1465804962129.JavaMail.zimbra@redhat.com> <20160614142502.GA8706@LK-Perkele-V2.elisa-laajakaista.fi> In-Reply-To: <20160614142502.GA8706@LK-Perkele-V2.elisa-laajakaista.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 authentication-results: spf=none (sender IP is ) smtp.mailfrom=quynh.dang@nist.gov; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [129.6.109.185] x-ms-office365-filtering-correlation-id: a3bcfcbc-fe12-42f4-3376-08d3946786ab x-microsoft-exchange-diagnostics: 1; BN1PR09MB124; 5:LSOwt4WTjYkn8Mwi/8RjzIC87RIjzxiwbIflllAuie5V//kFOTgf8rCITzEmDQe+BgOqafhPeTWaWloqpOq39rYG9dvB9pg+Cn9YpfLkWDIQfMFSmJ12lI13g6ix8/pqRFr5H0TfSQVfWTI4MK2+7w==; 24:kLjvu8Ltp3sWkD4oDru2zlQOk2/FCBlRqlg6bLVJTpNsJctA2tYwXAV7gey1pv2D23YGXUVQp5egqhVA1ER5T8x44mhPg19Nuj5hJo9lQ3U=; 7:rhgAedthWs0Xh1IaoDu23OW3+mDdUHUlsT97JgEbjfF1dPn9po7l9NBbCAqCx7KZt0X0JG4KJZ7ipGLrbbpLQiC39StGJwftkk64WzUuCwrY1uGiCRCD3E+6qhHQyuTcvHAll2nHW9qWTLWT75c9kPK6GKoWFlvTXnmPTMZHmNkL3tIEGLxr595BtyT9ynUbVS37azxrUT4ZsU6BGlyy4A== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR09MB124; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:BN1PR09MB124; BCL:0; PCL:0; RULEID:; SRVR:BN1PR09MB124; x-forefront-prvs: 09730BD177 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(24454002)(377454003)(199003)(189002)(122556002)(86362001)(4326007)(66066001)(99286002)(106116001)(2906002)(106356001)(105586002)(586003)(3846002)(11100500001)(102836003)(6116002)(83506001)(10400500002)(8936002)(4001450100002)(19580405001)(5004730100002)(77096005)(36756003)(5002640100001)(19580395003)(76176999)(54356999)(2950100001)(189998001)(2900100001)(87936001)(3280700002)(93886004)(101416001)(5008740100001)(92566002)(81166006)(81156014)(8676002)(50986999)(97736004)(3660700001)(68736007)(5001770100001)(4001350100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR09MB124; H:BN1PR09MB124.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-ID: <37851AD2B2DD10499EAA7CF9E34E901E@namprd09.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jun 2016 15:21:14.5343 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR09MB124 Archived-At: Cc: "curdle@ietf.org" Subject: Re: [Curdle] Proposal: Disallow Ed25519ph/Ed448ph for CA certificates X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2016 15:21:18 -0000 On 6/14/16, 10:25 AM, "ilariliusvaara@welho.com on behalf of Ilari Liusvaara" wrote: >On Tue, Jun 14, 2016 at 10:45:36AM +0000, Dang, Quynh (Fed) wrote: > >> I believe we are in an early stage of using EdDSA and pureEdDSA is not >> widely used yet. In addition, I believe that adding support for Eddsa_ph >> is not too costly because the hash function is already available in the >> code for pureEddsa already. > >Eeh... I thought almost all use of EdDSA was Ed25519 (with possibly >ad-hoc prehashing depending on application), and use of Ed25519ph is >almost nonexistent. The points were that 1) I believe the use of Ed25519 is still not large yet and 2) It would be great to use one algorithm which works well for all uses for a long time in the future. > >Also, remember that use of the same key as Ed25519 and Ed25519ph >key must not be allowed (due to well-known problems). I Never recommended using the same key for both. > > >-Ilari Regards, Quynh.=20 > From nobody Tue Jun 14 08:40:19 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E41E412D7C8 for ; Tue, 14 Jun 2016 08:40:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mIK_Ogc9Na9A for ; Tue, 14 Jun 2016 08:40:16 -0700 (PDT) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id 37C8812D7D5 for ; Tue, 14 Jun 2016 08:40:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 696A28724; Tue, 14 Jun 2016 18:40:13 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id J-q_NAFCmpHM; Tue, 14 Jun 2016 18:40:13 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-224-2.bb.dnainternet.fi [87.100.224.2]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 238CF21C; Tue, 14 Jun 2016 18:40:13 +0300 (EEST) Date: Tue, 14 Jun 2016 18:40:11 +0300 From: Ilari Liusvaara To: "Dang, Quynh (Fed)" Message-ID: <20160614154011.GA9331@LK-Perkele-V2.elisa-laajakaista.fi> References: <966179343.41495845.1465550320727.JavaMail.zimbra@redhat.com> <87h9d1aznf.fsf@alice.fifthhorseman.net> <1567944430.41904732.1465804962129.JavaMail.zimbra@redhat.com> <20160614142502.GA8706@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Sender: ilariliusvaara@welho.com Archived-At: Cc: "curdle@ietf.org" Subject: Re: [Curdle] Proposal: Disallow Ed25519ph/Ed448ph for CA certificates X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2016 15:40:18 -0000 On Tue, Jun 14, 2016 at 03:21:14PM +0000, Dang, Quynh (Fed) wrote: > > > On 6/14/16, 10:25 AM, "ilariliusvaara@welho.com on behalf of Ilari > Liusvaara" wrote: > > >On Tue, Jun 14, 2016 at 10:45:36AM +0000, Dang, Quynh (Fed) wrote: > > > >Eeh... I thought almost all use of EdDSA was Ed25519 (with possibly > >ad-hoc prehashing depending on application), and use of Ed25519ph is > >almost nonexistent. > > The points were that 1) I believe the use of Ed25519 is still not large > yet and 2) It would be great to use one algorithm which works well for all > uses for a long time in the future. My recommendation regarding Ed25519ph and Ed448ph: Do not use. Basically, if you have an application where Ed25519 is bad fit, Ed25519ph is going to fit it pretty badly too (and the right way would be to do application-specific preprocessing before signing). And similarly for Ed448/Ed448ph. -Ilari From nobody Tue Jun 14 09:48:26 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CD2612D850 for ; Tue, 14 Jun 2016 09:48:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yXT1iiNxEc-s for ; Tue, 14 Jun 2016 09:48:23 -0700 (PDT) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0105.outbound.protection.outlook.com [23.103.201.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C61012D7B4 for ; Tue, 14 Jun 2016 09:48:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=WHMCU8yc8WKYQagkWWWfRdE9QzemZtpCdf6h+V7VtMo=; b=Ke34waD+cb8jrClPn4g7Q0wug0HHuWYkCMkc+7I/xD2MRBB50tNWLBmWUxibpkFjSvTCcHhNIyju2nk3NYKc+m4zzb6SWj/TgeFSKVcDnunfjN267JePSgZbs4xdwJ9eNJauwQCtWB9gB12Pd70FFyVEzmUCgErHj8VQk8iYo3I= Received: from BN1PR09MB124.namprd09.prod.outlook.com (10.255.200.27) by BN1PR09MB123.namprd09.prod.outlook.com (10.255.200.25) with Microsoft SMTP Server (TLS) id 15.1.501.7; Tue, 14 Jun 2016 16:48:21 +0000 Received: from BN1PR09MB124.namprd09.prod.outlook.com ([10.255.200.27]) by BN1PR09MB124.namprd09.prod.outlook.com ([10.255.200.27]) with mapi id 15.01.0501.012; Tue, 14 Jun 2016 16:48:21 +0000 From: "Dang, Quynh (Fed)" To: Ilari Liusvaara , "Dang, Quynh (Fed)" Thread-Topic: [Curdle] Proposal: Disallow Ed25519ph/Ed448ph for CA certificates Thread-Index: AQHRxiniq1lEvBTTnEOedyW6Lb0dX5/pBL8A///MowCAAEhcgP//z/oA Date: Tue, 14 Jun 2016 16:48:20 +0000 Message-ID: References: <966179343.41495845.1465550320727.JavaMail.zimbra@redhat.com> <87h9d1aznf.fsf@alice.fifthhorseman.net> <1567944430.41904732.1465804962129.JavaMail.zimbra@redhat.com> <20160614142502.GA8706@LK-Perkele-V2.elisa-laajakaista.fi> <20160614154011.GA9331@LK-Perkele-V2.elisa-laajakaista.fi> In-Reply-To: <20160614154011.GA9331@LK-Perkele-V2.elisa-laajakaista.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 authentication-results: spf=none (sender IP is ) smtp.mailfrom=quynh.dang@nist.gov; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [129.6.105.150] x-ms-office365-filtering-correlation-id: f55680c4-d256-4913-61c1-08d39473b19a x-microsoft-exchange-diagnostics: 1; BN1PR09MB123; 5:J76gkjb3WmZUKMBQMyxQ4odl/RSvzuO2wbV3Sbmi1HxOEzWjLwM5g8PdBpW5B4iM4p87yHx+Uo/+fx2t0Hv+3PqW+27/aZ/nGWtexI+CroXV1GEtHEvUjYvyDLzd4OV0/acvsUhQmGwQvuaM75cegw==; 24:ClARdVpxw6fVMUfYnDm+N4YE5hmL4BiakDWXHdhBV9RqhVCe3jMkP5XbNFA5Of/BFFcKbH0R3IeJK94GhzX713BZtMguI4QXwpb4OC4kUzg=; 7:Ukd23zBpINY2EIbIl0wlF58Ronb2WaMKN+9i8ku9MsqedCKDLPImjA5V1G7XAxWt2GOzf0f0Zy2HZTp97iwyV3xP2cmWX7H8NeAB0Em5pknYGlhPJOowx5/Ylk7vvSQM32E3Qj97u86zI6Ezsc59D38at2WQS0PRVoaXr36tbD15D+RrndP1DIvnPw21g/pVaHRe+TUDdfYlR6TCgTDgKQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR09MB123; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026); SRVR:BN1PR09MB123; BCL:0; PCL:0; RULEID:; SRVR:BN1PR09MB123; x-forefront-prvs: 09730BD177 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(24454002)(377454003)(199003)(189002)(122556002)(86362001)(4326007)(66066001)(99286002)(106116001)(2906002)(106356001)(105586002)(586003)(3846002)(11100500001)(102836003)(6116002)(83506001)(10400500002)(8936002)(4001450100002)(19580405001)(5004730100002)(77096005)(36756003)(5002640100001)(19580395003)(76176999)(54356999)(2950100001)(189998001)(2900100001)(87936001)(3280700002)(93886004)(101416001)(5008740100001)(92566002)(81166006)(81156014)(8676002)(50986999)(97736004)(3660700001)(68736007)(5001770100001)(4001350100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR09MB123; H:BN1PR09MB124.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-ID: <23702F56DCFC3048BC71EAC65005F7D6@namprd09.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jun 2016 16:48:20.6363 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR09MB123 Archived-At: Cc: "curdle@ietf.org" Subject: Re: [Curdle] Proposal: Disallow Ed25519ph/Ed448ph for CA certificates X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2016 16:48:25 -0000 On 6/14/16, 11:40 AM, "ilariliusvaara@welho.com on behalf of Ilari Liusvaara" wrote: >On Tue, Jun 14, 2016 at 03:21:14PM +0000, Dang, Quynh (Fed) wrote: >>=20 >>=20 >> On 6/14/16, 10:25 AM, "ilariliusvaara@welho.com on behalf of Ilari >> Liusvaara" wrote: >>=20 >> >On Tue, Jun 14, 2016 at 10:45:36AM +0000, Dang, Quynh (Fed) wrote: >> > >> >Eeh... I thought almost all use of EdDSA was Ed25519 (with possibly >> >ad-hoc prehashing depending on application), and use of Ed25519ph is >> >almost nonexistent. >>=20 >> The points were that 1) I believe the use of Ed25519 is still not large >> yet and 2) It would be great to use one algorithm which works well for >>all >> uses for a long time in the future. > >My recommendation regarding Ed25519ph and Ed448ph: Do not use. Why? > >Basically, if you have an application where Ed25519 is bad fit, Ed25519ph >is going to fit it pretty badly too Not true. If you need to sign big messages, prehash helps here. > (and the right way would be to do >application-specific preprocessing before signing). Prehash? Or something else? >And similarly for >Ed448/Ed448ph. Every where, an Eddsa works well, then the Eddsa_prehash version also works well, but not the other way around. > > >-Ilari It would be best if one signature algorithm is used in all protocols instead of 2. I believe the use of ed25519 is still not big and adding support for the prehash is not too costly. Quynh.=20 > From nobody Fri Jun 17 12:50:14 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1115E12D0AE; Fri, 17 Jun 2016 12:50:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a-KeLLo3Cnce; Fri, 17 Jun 2016 12:50:10 -0700 (PDT) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24A6912DA60; Fri, 17 Jun 2016 12:50:10 -0700 (PDT) X-AuditID: c6180641-f796f6d000000e1e-f6-576454351179 Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id 3E.C0.03614.53454675; Fri, 17 Jun 2016 21:49:09 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.03.0294.000; Fri, 17 Jun 2016 15:50:08 -0400 From: Daniel Migault To: "curdle@ietf.org" Thread-Topic: CANCELING CURDLE meeting in Berlin Thread-Index: AdHI0OO4TvFaHcQGS9209QUei4bbJw== Date: Fri, 17 Jun 2016 19:50:08 +0000 Message-ID: <2DD56D786E600F45AC6BDE7DA4E8A8C117F1A14D@eusaamb107.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: multipart/related; boundary="_005_2DD56D786E600F45AC6BDE7DA4E8A8C117F1A14Deusaamb107erics_"; type="multipart/alternative" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupileLIzCtJLcpLzFFi42KZXLonUNc0JCXcYMNmRYuZPRuYLbYunMXs wOSxZMlPpgDGKC6blNSczLLUIn27BK6Mp+2X2QsONDFX3Lh+lqWBcfUnpi5GTg4JAROJn3M6 mSFsMYkL99azdTFycQgJHGWUOLhvBQuEs5xR4vbT42wgVWwCRhJth/rZQWwRAXWJE4d2sILY zAJaEq83HWEBsYUFtCVWrH3KDFFjIPF/wXM2CFtP4s+2nYwgNouAqkTjjbVgNbwCvhKN616C 9TICXfH91BomiJniEreezIe6VETi4cXTbBC2qMTLx/9YIWxFiX3909kh6ruBDj2TBjFTUOLk zCcsExiFZyEZNQtJ2SwkZRDxfIkbD2YwQtg6Egt2f2KDsLUlli18zQxjnznwmAlTXEdi86Wd UHMUJdo6ZwPVcAHZSxkltnXNZ4Epavr6hAmmaEr3Q3aY+NK2aUDLOMDiXXfKIHqXMUosPA1z hI7E6Y67LMh6FzAKrWLkKC0uyMlNNzLcxAhMFcck2Bx3MO7t9TzEKMDBqMTDm6CYHC7EmlhW XJl7iFEFqPXRhtUXGKVY8vLzUpVEeM2DU8KFeFMSK6tSi/Lji0pzUosPMUpzsCiJ8+q/VAwX EkhPLEnNTk0tSC2CyTJxcEo1MHKuPPPx4ie3++d2u3LsOfhxU7/Sl5iX+xlv5/jocoluXLdt +cIzCg8aX65VbLwVfIxBc+f8fZNKszUYn0QUMEjKF99XzH0kfCCsW5BH0Wg1U6mcsnJ0tpuH x0PVPWelFi4rSJ9/6v0WLtOvDyNXTNpfbhMjUHuRZcOl9lPHGB12vBU06xexPKvEUpyRaKjF XFScCABcKMU3HQMAAA== Archived-At: Cc: curdle-chairs Subject: [Curdle] CANCELING CURDLE meeting in Berlin X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 19:50:12 -0000 --_005_2DD56D786E600F45AC6BDE7DA4E8A8C117F1A14Deusaamb107erics_ Content-Type: multipart/alternative; boundary="_000_2DD56D786E600F45AC6BDE7DA4E8A8C117F1A14Deusaamb107erics_" --_000_2DD56D786E600F45AC6BDE7DA4E8A8C117F1A14Deusaamb107erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Due to some conflicts with QUIC we have two possibilities: canceling the me= eting or find a new slot. The current raised issues planned to be discussed in Berlin were: - the IDs used to represent the signatures / keys. Part of the discussi= on has been done on the mailing list, the next update of draft-ietf-curdle-= pkix is expected to reflect the discussion and we should solve this before = the meeting in Berlin. If additional discussion is needed, we suggest they = take place in SPASM. - The insertion of context in the signature could be initiated on the ma= iling list. As issues can be solved on the mailing list, we are planning to cancel the = meeting. Anyone opposed, please let us know, so we check for another slot i= n the agenda ? BR, Daniel and Rich [Ericsson] DANIEL MIGAULT Researcher Research Ericsson 8500 Boulevard Decarie H4P 2N2 Montreal, Canada Phone +1 514 345 7900 46628 Mobile +1 514 452 2160 daniel.migault@ericsson.com www.ericsson.com [http://www.ericsson.com/current_campaign] Legal entity: Ericsson Canada Inc., registered office in Montreal. This Com= munication is Confidential. We only send and receive email on the basis of = the terms set out at www.ericsson.com/email_disclaimer --_000_2DD56D786E600F45AC6BDE7DA4E8A8C117F1A14Deusaamb107erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Due to some conflicts with QUIC we have two possibil= ities: canceling the meeting or find a new slot.

 

The current raised issues planned to be discussed in= Berlin were:

    - the IDs used to represent the s= ignatures / keys. Part of the discussion has been done on the mailing list,= the next update of draft-ietf-curdle-pkix is expected to reflect the discu= ssion and we should solve this before the meeting in Berlin. If additional discussion is needed, we suggest they take place = in SPASM.

   - The insertion of context in the signa= ture could be initiated on the mailing list.

 

As issues can be solved on the mailing list, we are = planning to cancel the meeting. Anyone opposed, please let us know, so we c= heck for another slot in the agenda ?

 

BR,

Daniel and Rich  

 

 

 

 

=

DANIEL MIGAULT
Researcher
Research


Ericsson
8500 Boulevard Decarie
H4P 2N2 Montreal, Canada
Phone +1 514 345 7900 46628
Mobile +1 514 452 2160
daniel.migault@ericsson.com
www.ericsson.com



3D"http://www.ericsson.com/current_campaign"

 

Legal entity: Ericsson Canad= a Inc., registered office in Montreal. This Communication is Confidential. = We only send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer

--_000_2DD56D786E600F45AC6BDE7DA4E8A8C117F1A14Deusaamb107erics_-- --_005_2DD56D786E600F45AC6BDE7DA4E8A8C117F1A14Deusaamb107erics_ Content-Type: image/gif; name="image001.gif" Content-Description: image001.gif Content-Disposition: inline; filename="image001.gif"; size=2367; creation-date="Fri, 17 Jun 2016 19:50:07 GMT"; modification-date="Fri, 17 Jun 2016 19:50:07 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhRAA8APcAAAIVTgAWUwAWVAQWTwUWUAcXUQkYUgAbUwAbVAoZUwAcVQEdVgMeVwQeWAYf WQAhWQAiWgggWgAjWwAjXAAkXQAlXgEmXwInYAAoYAQnYQApYQAqYQArYgArYwAsZAAuZg0sYA4t YRAtYREuYgQyZAUyZRMvYwczZhQwZAk0ZxYxZQs1aA42ahE3axI4bBQ5bQY9cBU6bgk+cRc7bxg8 cBo9cRo/bRw/bh1Abx5BcB9CcSFDciJEcyNFdCRGdSVHdiZHdylJeStLeyxMfC1NfS5Ofi9Pfy5Q ejBQgC9RezBSfDhQfDFTfTJUfjNUfzRVgDVWgTZXgjdYgzlZhDpahTtbhjxchz1diD5eiT9fikVe hUZfhkFhjEdgh0hhiEljiUtki0xljE1mjU5njk9oj1BpkFFqkVJrklNsk1VulVZvlk9xl1dwl1hx mF1xlFdzlFh0lV9zlll1lmB0l1p2l2F1mGJ2mV56m2V5nF97nGB8nWF9nmJ+n2N/oGSAoWWBomaC o2eDpGyDoG6CpmiEpW2EoW6Fom+Go3aFo3CHpHGIpXKJpnOKp3SMqHWNqXePrHiQrXmRrnqSr3uT sHyUsX6Ws3+XtISYr4easoibs4mctIqdtYueto2guI6huY+iupCjvJKlvZOmvpSnwJmou5WpwZqp vJuqvZyrvp2sv56twJ+uwaCvwqGww6KxxaOyxqS0x6W1yKa2yai4y6m5zKu6zay7zq28z7C8yq69 0bG9y6++0rK+zLO/zbTAzrXBz7bC0LjD0bnE0rrG07vH1bzI1r3J177K2L/L2cDM2sHN28PP3cfP 18TQ3sjQ2MbS4MrS28fT4cvT3MzV3c3W3s7X38/Y4NDZ4dLa4tPb5NTc5dXd5tbe59fg6Nni6trj 69vk7N/k5t3l7uDl6OHm6eLn6uPo6+Tp7OXq7ebs7uft7+nu8Orv8uvw8+zx9O3y9e7z9u/19/D2 +PL3+fP4+/T5/PX6/fb7/vn7+Pz6/vr8+ff9//v9+vn+//z/+/7//CH+EUNyZWF0ZWQgd2l0aCBH SU1QACwAAAAARAA8AAAI/gD/CRxIsKDBgwgN8tOnb1/ChxAjSjR4792vMyAaBLllb6LHjxDtvau2 SMYBCRYsSHAwSx/IlyD5ufMWCkqDBihTppQghB3MnxDhgbPVhsNJnUhTHigHtCnBeuCMKcpRAGfS qxLMOW1qTpmmKQ+OXr16oIu7rS/fPSOlhsQBB2OxPmiAwxg/tB6xtfLTo4HYuDolHOBQZI4xvBPf XYpiNCfgnQ0e5FDDyRniifUuSbD6OKWDAyPAVArW7rJHcSMcAxYcwUkjW99Mf9xnrMDjzQVw8JGF jR5BcrFMKZP90BmBuBEKcCCTSprPgfhs6VFCw8UOQfCIH0SX4wFSwQ2Y/lxqppWgNEdOaHCQwB7l Jd/aCe7D1fhBgheBjJWDL5AdqCo1iMBeUhLIoE58Bd3TjB9VuCELOfEUpEsaNJCgEmAFMIVgQfPA I49LA1mDSA4krNeZBBycs+FD7ISCxAgcdIbUAXRkt2JB9ghjhoUyJuWAEN7cONA+2zByg2o9pkSE J+/849CN6tDhAJKdZcCBDH5UIyRB8exxQJIpgeACGLR0tCVB3nh3ogQeuLBEJuQQdI+ZQvIzjG1x sZeBC0EEMtxA/LCjVyjGPHejNF8SyF4KQLARC53/vIONLGp8UMABB7wxjpDvQCHWSh70EEYnQQ5k Tze9HLLDAZxZMIAi/vPcyE8yRGxw0g1bOIJMQeQIcwkVglEpwQjobIlNJHksQstZA7mDzCdosFDA lBhqeCZB/FBTyh1A3EQlgSykc+1A5LQSyBMctHrbAZLwJ2Q9vjSiRQsOUHuiAwWQ8EexW5pjSRg7 WKDuaic5QckvTW5JDRMj2HuiXzQAYss29Vz7DhYD53nABmawgg2z41rTgIybHZDEJtio8+S4//Aj TKIasyAIM+tUzHJB3IyMFU5j0MKOuzcT9M4aMKv04ybl2HNX0AmZ4wVOErTQxzT5MD3RPWsFI4/V XHft9ddghy322GSX7dEywQijtjDBxDlN2mofwy87vhyjokDY0GLK/iq9lOPQpHsHc6A+zrRSCivI xPqPOr2ggoovB0aaTDDBiPvP29XwM0YOO8hQgwwvrPKPHTjkUEMNQZiRzD/HvOBELf+0s8kUKTwg QQqb/GPKFCVE1kMw9GxSRGNRxKYMG0dKcMMbu2KTBQ41bFIxHTfwYY8QDYiQRRVURGHLP1oc0AIX UWz2xD++DMACK/9cwgEBOdThhxOVYEMvEIoYQscww3DgQBSM4MMdypEOKEwpDnBYyRTQQY0c+GUH 0vhHFQ4ghnoYwQFGqAc60GGOefDDCwcAAzbScYSU/OMXBXCBLKghgwJQIRjskNQ5VpEBC/xBIOpg hycEMAJR/OMe/kzJBAcisAh1nCMRBxCBJrbhgwgIZhL/6IIDyGDBCMhAE5SQhCa48Q8QXoF/MpAA E05YgBe04hVfCkVBlIGSHNhhFaVhBQEyIIRA3EIgX9iABO7mDfaYoRs94MALOHADcnxhihZ0TNRg 5wUHiEAGNLAAEbpBxhekAhQDeEEuCqIPQfglaleYRjrQgKkNvKAN9mCCBFjwJHfAoAFYwEYg8xAF AnwCChGgohGixgc7zAEQ0+jiA1RghBiNQEUoNGMqBAACWRjkHccgxAxs54Z/rMMWcuhdA4YBhZSY yR0ecAAXACmBVFRCAjt4gQR0+YAx3uMeDtkHCKngDVGs5xJk/lRh/xrABkMRxB7heIEDoECQVdCA AKawAwgcsMl/7GIwg+jGDspJjiRIIAPrTKQLAKEHPcBBGF08QBbaUQ8VWAAI+WyFPNxgGydcYhWH +MQ3xtAJW1BCJWrABhlKYYs0cGAAtaBGCSQAg1UYVAIzkAY2JjqKf0ACBBLIZT2w1x4JFIAT/8gC Aaqwjn+kQQIbUEYw1Ce6bogBJ1ZyAB6SwYG2YvQG1ODFANq6gQR8IU6mWE9bh3WKfzijO2osRxFu UsFWcKITiO3EJYLJikasIlbSmMQkhvENRmRCS/+wxzAKcQYy+MEY6thEHMighkyo6BuRaMMY4rAK kHXDEWY4FUMkKPkPc3giEtEQyC4o4YhX3CMgAAA7 --_005_2DD56D786E600F45AC6BDE7DA4E8A8C117F1A14Deusaamb107erics_ Content-Type: image/gif; name="image002.gif" Content-Description: image002.gif Content-Disposition: inline; filename="image002.gif"; size=26723; creation-date="Fri, 17 Jun 2016 19:50:07 GMT"; modification-date="Fri, 17 Jun 2016 19:50:07 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlh9AFQAPcAANzd4m1obXh0fTsrDHFueIJ7hXl4hktERkQ7Lby9wnRyfHh2gZ2Xo5ySnU9F MEEyEm1pcWNaVoF+i3FsdX18iqKbo3Fka8jHyXx6hnZ0gXRweWNcYQIBATs1N4KBjjMkCH14gm1q dSghG1BJS3Z0fuHh5NfV03l4go2KkislIW1mbWlkafX19XJweWpmbNzb3Ly6vmtjVuzs621laXBq caupturt9ltVWTMkBnJwfGliZIqFjnFscRoWEyIdF25seFNNUG9qbaGWo6alrHx1a7SytFlSVX18 hoaBipCHjjksEW5sdZaOlq2irXBqdHyClYuHkM3N0aeknqGbqoSDkP///1lZZJaNmoaDjXt4fnRw dpKJkmhiaKCWnltTRIB5b5mPmvb3+jYoCpWSmqKgpo6FjoqBinx6iYyGfHNudkQ9QD4xGGxmcDAr JlZPUl5YXWVfZXdyeYaFj5SRlZaLlXh2ha2rrmZhaKmfqTQ4RIKBijgxK7Cus9ji9IyJjrGsq3dk a3t2fpKHkba1uefn6I6DjpKNlnpycsHL5+ry+ztBUpuWj3h0etbW2nhyfJmNl5KLlIqDjId+icC/ w5uZnkZKVm5scaecpoSBh5WJk+Df4Xx2gZGOkRcTD3p6h3Z0eZidt35+i5CtzJ6hrHNsYVRUW4mF i1JskiQoMj4uDLSxrIGNqVtgciAiKcC9upmRmM/NzXNucYiDhKyxw6qnoxgZII2Mm42Ci356god8 hi8hCNHQ0+Pi33FjZ21hZ3lucI+JgWpob8XDwGJaTHx1ebi3vPH7/9nY2paOkdjX02xxh3Z2g314 dTUnBpCUp42Hi2xoaA0LC5+akwoKDDYmCfn+/2RneDIvMCowPnp8inJqctvZ2YOFjhEPETgoCHxy eHp8hhERFyEfIvn5+eDf34eDi/Dv8fn3+Whiaunp6nZygfn7/zYmBnhmbGxianJqdE5PXIN+jkJe gXtyfXR4i+Pr9HVmbff393yGotPRzYiKl7i2saq83I2bvZGPoGx0kSH/C1hNUCBEYXRhWE1QPD94 cGFja2V0IGJlZ2luPSLvu78iIGlkPSJXNU0wTXBDZWhpSHpyZVN6TlRjemtjOWQiPz4gPHg6eG1w bWV0YSB4bWxuczp4PSJhZG9iZTpuczptZXRhLyIgeDp4bXB0az0iQWRvYmUgWE1QIENvcmUgNS42 LWMxMTEgNzkuMTU4MzI1LCAyMDE1LzA5LzEwLTAxOjEwOjIwICAgICAgICAiPiA8cmRmOlJERiB4 bWxuczpyZGY9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkvMDIvMjItcmRmLXN5bnRheC1ucyMiPiA8 cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0iIiB4bWxuczp4bXBNTT0iaHR0cDovL25zLmFkb2Jl LmNvbS94YXAvMS4wL21tLyIgeG1sbnM6c3RSZWY9Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEu MC9zVHlwZS9SZXNvdXJjZVJlZiMiIHhtbG5zOnhtcD0iaHR0cDovL25zLmFkb2JlLmNvbS94YXAv MS4wLyIgeG1wTU06T3JpZ2luYWxEb2N1bWVudElEPSJ4bXAuZGlkOmE4YWU0MjY1LWM5MGItNDZm My1hZDI4LWZiODE4YmVhZjcyYiIgeG1wTU06RG9jdW1lbnRJRD0ieG1wLmRpZDpCNkUwN0M3QTJB NTkxMUU2OTRCMkFBMDIzMEVDN0M3NSIgeG1wTU06SW5zdGFuY2VJRD0ieG1wLmlpZDpCNkUwN0M3 OTJBNTkxMUU2OTRCMkFBMDIzMEVDN0M3NSIgeG1wOkNyZWF0b3JUb29sPSJBZG9iZSBQaG90b3No b3AgQ0MgMjAxNSAoTWFjaW50b3NoKSI+IDx4bXBNTTpEZXJpdmVkRnJvbSBzdFJlZjppbnN0YW5j ZUlEPSJ4bXAuaWlkOmQ5MDI3ZTBjLWRlNGItNGMzZC04ZjRiLTc1MDJhMmM0NTNjNCIgc3RSZWY6 ZG9jdW1lbnRJRD0iYWRvYmU6ZG9jaWQ6cGhvdG9zaG9wOjFhNTdiMTBlLTE2MDQtMTE3OS1hNjk3 LTlkNDcwNzU4ZWEwNiIvPiA8L3JkZjpEZXNjcmlwdGlvbj4gPC9yZGY6UkRGPiA8L3g6eG1wbWV0 YT4gPD94cGFja2V0IGVuZD0iciI/PgH//v38+/r5+Pf29fTz8vHw7+7t7Ovq6ejn5uXk4+Lh4N/e 3dzb2tnY19bV1NPS0dDPzs3My8rJyMfGxcTDwsHAv769vLu6ubi3trW0s7KxsK+urayrqqmop6al pKOioaCfnp2cm5qZmJeWlZSTkpGQj46NjIuKiYiHhoWEg4KBgH9+fXx7enl4d3Z1dHNycXBvbm1s a2ppaGdmZWRjYmFgX15dXFtaWVhXVlVUU1JRUE9OTUxLSklIR0ZFRENCQUA/Pj08Ozo5ODc2NTQz MjEwLy4tLCsqKSgnJiUkIyIhIB8eHRwbGhkYFxYVFBMSERAPDg0MCwoJCAcGBQQDAgEAACH5BAAA AAAALAAAAAD0AVAAAAj/AD1QwHCGQqiDoQyG8rDQg0OHVCLKkRiRihxuciZa3BjRQ8eHID1IGCkh 3siEoSRQWFngyBEML4/gwoALxMyaIHKCyJJl506eWQKB2CQ0KM9ACwIFEqAU6QIBTBdIFbCAhFSn UrNKPbF1wQkDdU6IPRF27FgDBr4a8IShrVtPZwrGPYMBHDhPeFdiyMa2bltPa9Fi+Do26zKpJBIr WMx4cY4WjzVoaKGFgOUWmDGnIbCZgGQNCj45ggo1ENATOWe6PEKhJSY9eiRgwkK7thwopqDogwIF Re/eKPygGE6cuHDhxZMn582cuR/mO3jvmC5nR3VT1aFMZ45ihyUgHdqk/xBBvryP8uVTqF/fZsQ8 MFMYxJc/pX79UVPo5UFVaxqH/wAGKOCABA7on4A9jEBMAUMZtRRUcTDySRwUVkihFlrEkkYaEzgx QRoQwFHJNeL44EMPKKaIYic9sLjiiyp6QFBcKymUkgQNPdRRRVRww6NEGnFERUhEkmRkQiTViAsF q7nkFi4z6eQTUD1tYlQWm2QZlGlZUMUUUyeQ5mVWpGm1QAZmosmVVwugtYxZddThVR0GYICWYHW+ dQZbLs0F057gyEUXn4CxhdZZZqVJQgYZkNCYAqBNBmlmGlhm6RIEtLChpWlI1oJknyRGWhYL9JSa TE3KpiptSNimXUa8+f/2m3K0Lodccdw1px1u0eVW3XSmmDJdOdT9Gh0UktyhhnjoNZveeuypMcEV QjBgLX32ZYvHFNag0kp//03j34EFlmuggeK8YVNNWTYVCCPwWhiHFvNiiOGGPFhiCQ38akMDOvB0 UOKJKraYIoudJJywwZ3o8RKTNSI0EpEQQYRFRhMF+WNFFINk0pEUjOQSk046iQEIbaGMcls9AWXa TidQeYKWVh7VVGlQPSWmzgJYJRWaaC6awWFVaSVnVlzFeRada9npyVcY4BXXX6zpSQFdL70FGAhp HTrWMkTLOXRiZD86aWZpYGbpBEt09iGmH272qQZxhApvl6aVmtMJuLj/1NIREhSACSYe6NEqFtjt UA7GzQ0HXK3EPT6ccM5VDh2w111XTrDBluN5bdshwYMbe4znbLOmQ5uCGnAUUm0D1lYrRLa0T+EP PKiI0x+55vYeLgfjjstBNx3M0JJOpJL6ICN1V0ivBvZmOAEBsehrCQQ0BEGDNmmUkkcbJ4ZfMMIt LqxwDwLRuNJBRxwkAUMgDenRkBFhYdHFG3McEhYPvX8kQoDzG5OwVpPVnCxlIIjZlDbhkxMoBShZ 2om7lPKlnmXAS2IiDZqqYpWgJcZMXhHLVtZEp7KgJU516tpb2rKnFUptUHU5AjhYGLWu3alrZ5HK MhqlAMU0JgdAzIym/ywzvQkY8YgdWsISjLgh6EmGQqO5Ck9U1re+uWQkg5PN4RZnCs/BCgq3iZVx /MA54UACBbaQFW/8wEYoPEdXzZnODoKFhc/VsY7lQMLhLoaFHSBBCzcIj+lOJ4LxpG49HYhALhrA SNhdSz7YyhYD/LGDHFSCP+EQF4CE9zvgFUh44gqlf6IhDiAQQwJHoEuDkMIUeAngE7CMA93mJZl7 xeKI/MpeALBHA3dsoBRquMY1RGCigjFMYcjUA13aEjH3HcQhetDR/DwyPx/xaH4a6ZhIjoRKkgAO YiRzyUxo4omcnGxvyLPSUIjisqBoyTQUdCBTHpTBnpWJUYsS2ga1gv+msEhFTgIQiz8Jc6g7ASZq CJVaW1JJENa8hC1wmWHUAHMntZwAMAIVIQcX4yjG5EABLchUpiqzNiMq0QkoZZslJkADDmlhM08M DWm4lAW+0QRKLUmJ4F4Tj9og7mK3iU5wyiELZhCBFDFI6jCGkVRSMEMWKBiDIXgVR+kcy1eJ66Ic 7kibPGIBCYZDQjlo84kILEs9hCykIdWqnj0AIRBXaCQjGeBIBlSrArRjACSOEAxgtiIc3QhsNAYL SgEd6LCeFOU0orHYWqghAILTC5TylhRGCABesKRXhaCXhntxyAk8yGUQtBeAAIy2l3C4A3hSYCKC HQyZCtMDCwV1EIX/vK9wIaFf/nYrPyLBhiH/G4lBHDqQtvQNgeY8J2oalMAsbSJmWxLLBJESCAea RkwkwK6oyJaYRomqUY1CjFbWpJU3hTAtYglM0+YCl74QBCZwoYDU3NsW9ZolUeT1bkchBRrMVIpT cJsAD1C6BBpcz8CWcIISJxALzmhKMo4YTWmAcpO+FYBkmFAVEjywRcb5oahI9YIXHOAABJjYxA8o MYljQARkkGEKtsBNboClHWBZR1jYMQWr9MhjsBrOc1nYwAGYlVZDqi4F7eHBFsDAZDA00q6xq08k GQCFZcDhANioRTgYOw3BCpaxiU0sKEM52Gh4OQU3KIAkUNmStjwX/56XveyEaEkve3X2lvnKJb9I a9oAWCAI9gi0Pdxxg2CK72Dli+1EU8kaiSEkFNEkkm65wQ2P0KbS9KMmxfxnJBwpBJwGPG6UVCal nwxlARLcxFWQorwHUhCD9ZSwABxhWctChbu4torPzJRdM2VULAm8YZ3wMiM7RW1PcWHL1OiLUPWi 9wTmLRqaepgBs2XmMkskQIecAIEEQ+DbQdhXt1MKWm139omjwRtPUIOqI/wNE4KTAGy+ClYsuBEN RBjGiBHwgH77+98AT3EM0CCNCoxhq2DUMY5zHCw5dO6rX8VEq5AgbyTgYgUHKF1aC8lx1bVBDSso wyOYcIW4Opmudf+dXbXqIwRnQEEdVshDK3rQjVBu0sxfZiyXxbXzxQb2590YrAgO4IsFYSIUbcaA qpcCr6Yzr27Rs6WA85w9CAQBAqUNQmlnEAAV2MMCFgi0BTYwAoG59kUKk1FfavRpHC0kRzqy3/x4 K02Q3JYkznw0+1byknG+V0pAaaBSSlXdLSUlKdOtZwZtzQhHZBdeZLt1R72LT6tQBWj7RJoI05te vAjm2Ad1C7KzBhenIbS+aHmaWgyQlQ5W24cKCOK1NzM9BXO729fDutXB/W0IEDhundKArecJ7Ju0 22+xeY0e5cAJYOSbxP9OhRJSQf3qS/8BSnjAGtbwgFSkmBTAmAP/LoghC9yMdXMX62IXPedVJAxu cEgoQDBGoPGNo5Wt6unABnJBh/6T/ApgMAZPBmUrB0kMoA8wlwfiAFia5EkA0g09UAtA93NlNoGA FXTjEg0+cA0jsAGHUAAFEAo4AQKs5HQWAj2elQYaMnXiVlpWt0ulVVp/9nVgZw+AYA/t4AtGoAYp IA7jkzAyInpXYyM4Aj/axFsf4QH8QyQLgXe1lRIhoxKrgTVZ8ySk1iAzU13sRCryZF2DtxRgWBo8 AxXEQBqWlRiwlF2O5yhsyF0C4F0/k3kLcDT3dSh2knoQhRf0dRdwsSeep4cT1RcFBRZcAW2I0UP7 BRqPoTaW8QMm/xUC+vJtIYB1weCCMNh7vndEwRcHoQGGXGIT4tQ3oQA4I6EHoYAJKIAMXzAM0Odv SvCKAzAAShCLtCiLtCh9uPgACBADX6ADw0AEUMB+Dec567dj75dhseAGgjRIRaY6e+AGgbAFdJAJ kFByAMhkc9UAsgNJUqYPGRBzC8hlDrhJPdAGJLIiE1hmPDeOABINPXANB7ABcQCCUJITN0MhTydL snQvH8JgPCBge6Y9WBeDKkADAWAPfhZ2YGcBgMCQgAAIbzACJFJMKSJbbkEQbOc+JCFpEPERQ2JN vQVNIXF3J4ESCcF3MGFAbnECyFUTQpFAM1NTNYN4nugUpfFq1P9FGrImeT2DiCTwCRyFhoxReYxC ebuWFWVhUTd0h2tBUbgQek1DbHrYXsR2hydDiHJyGN21X40RUiGlbQSgRErUe2wAAWxQWmygAmfp Al3ngjSQUpyhBRrwCWJSeAaQGjBRAH0Db/AmB5QADKTQiv0GiwMgBrVomLWYmLMoi97nAEvlADGw A7WhY+x3frTxGligB59wAwggHszYjNBSPGUgCIIgjZBAByXnZANYLfIxO/HhD2fACjK3ZbwzIO8o SOIwMCfSCbX5SdNQjvH4DTVRE0FBGhGyWVH3Uhzyj5YQBDygdTEYg0GgAjK4kNYJdg+Znb6gjOBT kXuSJzTSaAb/sZEdsyPyI3eR9hDRlCOd5nYqwXYkE04IZRMYUFM5IZNisXRf+BTuQipJIQDzMFM5 o3ikQZc9GZSNkV1l80FnUnmLkhWZV4dhkXo11BcQRRcseZHKVqFfQVFnATb5xJUfJUQihUS313sB wAZsEAwuwKIB4AIwypZu+ZZMBBoRYlle8RM1NRN6WQCodARzIAVowIoO0G/SR4uGmaRiYJjegJje MABPmpi22G8ktososFVbNVZgNXFKiARBdlb3Z3/494zzQJqluQXSiJol1wCqOVey45oM8AQuoAh/ BWa9GS7leA1oNUgncqefBJxwIJw6wXTyUmcbsiEaEgs8sKjZ/0MD2BOdfeZnKnCdC/mQvZCdD9kO EHkAE6lMfUEjepcSJuEQcJdbmRY/IBFNscFpJ+F2EeNQMdF3F4kaJ7NcqMEmS4ElOuOJN2lZ9BRr EqaGtcaJPWQ21eaTZANelPczDZp56PWsgpFAxqaHTdk0pweIdpKUhBEn3VUVj9JfmfKVSbQEljCJ 35aWaukCbBCjK8CWLqAC6rpL3+YhBIAhs2RZyUNFFoYqFWAHq1ik/bYGSNqkS0qwYvCkB5uwSBqL SRqL2YcADrAGw1AAW+VjETdvBYBxpfOZhGRkSLYHaqADtyAIo3mmmWAIV4Ca2DhXdiU7UzAKo+AP ynBJmeSn5P9ojj04HuIgAiXSAzZrWBzgjhyoA4xAnIS6WZ21IRiSqFPnBLkEg5AqgwlpAb2wkJfK kJeKqe2wtb4AHhJQlXNxBid5IyLxduUZktr0W532hFB4BqvRGsVlXAg0GKixbjGzdIfHnxVUTw8y GmeYXYsXIT3jCHVjNlwpNPrkoEOjrEOTlRXlNWJBtymEen+4ofNVKGnhFc+mFWXDGJ9ybZahRNZz rmapAvDKriuQujEKozH4lisVfPfKFC1zKkcAAkcwBKrwBfvWb0i6pL7ru81QsN4wvAdLvIVZmA0b i96HAB/gALJAG7CxYRJ3BJZAf9CyceShOh1gBIcAAoVQBuD/W5ql2X9XQHIr60hCkL5TMAQ1AApP wApZZnPm0g3icA3Mwqd96juG5QMd4AYqMA8SJGfOo5waooIqaETPyS+6FwDQkHXRSZ0zEMHX2QsU jKmAoKkX/JAS8BcsNITro5HvkyOlqmmpGhKmGGl6x3dwyxpuGxMXmRNpwTUJlEBHgXiIRxW/GlC/ CriAe2v2lF1xMBr7RQKRAhpmwxhtqAD6hbiJO4dM87gYhUOG4nmnd5EG8J0VJVALYF5iU23HqgBa ALrTc1JO+20BwKIu0K4xig5pnLpurMYy2m1LwANKCxokkG5ThDK4cAJHUANF8K9GOou/O8iDTLzC O7zIW7C+/9ukSrB9uhADfkBvhlMAydiZa9WxHbceezACsWAGhfDJ31uyaHqa/9emjOSyeDAL/AAK /6AIWvaz/+GOKXANqFBIO6ubNKe/m7RY4oAARkAD81CcjqAAA6y0t4QvANmoAxm1Mmi6M2C1VEu1 DWnB2bm17bDBxvYnBTG2N3JbI6yEJJy23ex2FzZcsJqSVegWdznDgzHD/XnDrMQzU0GgtGaGopKg iyEAjBEpRxyUueaTRQk0AZU0aTGhhNF5XlMohhIYdpJed1IHbyIWYBOHr7fPXnkpIaBEIQCDwYDG adzGK4AOqcsFJP3GMKqW2kMDwEc3tcYlKXMGfDAJwMCK/P8mfYRMDWKA04usyAk7vIZcsM2A081A sI3cyKQABRdDAkHAmUR2Oh7rcQdgPIVgBmZwC58cvqVJjWraZE8mO3jAD4iACP3ACqhQs74TDbWA sztLHj4wMCgSDbq8SeGwOm8QC8X5Sp/hWVpgRLcEkPlydVo3kCrAdQ38zIM9wdJctZZazRl8zYOR J8wUMeMpqkaIWxWjntq0TXj3wazBd1mTzuoswzBZU1n4hQ8SCD1MGr0Wa5KnoJ2LxCIKKYthxIyh DkGJT8j6oOL1T5zX2zbk0E0jbDeEUdFGXluM24l4GWGpbU6Qe2a8uiEt0iNN0tTNBSbdot+GYGEs lwowUzT/fAJ8EAWUEAMllgqJ7Ls6ndPUsN45Xbw+/d4+Dbw9TbCy+AEIQARZgAlLYL0cm71HFi06 AAJmIAmSQNW3YNVYLQhaTQfY2KbpWy38YA7r0Aer4MoNaC5d5gOzrLM8S0xtfSJwHdfA85tDGwdH W0vKmQaLKmB4ZmBXx8zUWVqT+swzULUUfOOKTc2Zes2fh1AZmXfdvE2omtma3c21FZ8P0ydLcpFu AcMwI5OshMM4wwgXhF0EChUy9ZO3BpSwt8+x91FG/FGLcaxtqBhbqU8/swx0OFBqTogVVbl/YUNd o63/hBgh2lHgOhliuQTN/W0dHaMq0K5uXNJ3UN3Wbd1u/wyjWEcD/3huCiDEpnECCjAEfVAMRFBi D3Dev8ve1PABQe0NQ+3TOI3TxAvfh5ywv+sARuAFscCD/Y1/HtcBb0AMBZ4LBF7gBx7KpJkJmdB/ DH6+2pi+NWADVVAN9XAKZQ3L4dINPtAKKdAKHX4eHw7iym5YpLS9QWBZE8JfnLUZiipgU+fiy9zA Mch1XefMVQt2FEy16a7jmtoOsvWHHWwQttVpQs5hRI5bKQEbIOxpKgwTEAMTTU6rtRozBi8W/vmf sPaGVy4mEqLloTLMQfkZXv7lYi7mjeHF6mDblFeUi0I0ITQnrDeIZwGtg/hsmwdCds5dXSkZocvn 5UqJqP8r3StA3Xdw81yA8zhv0i5oCW3TWZzYa1kQB85QD33gByOW6Te93p2+3h/A9Dkd6sOr06IO 6qVODaHe3mLwAWvgAHvgAB3Acc7y323lBmlg67dO4AYOyqO5BbxOvtfYSA8+BY1QBXbfB/KQSbrc ZT3Q1h1eIsTk4T0Q4iIetJ3QBvEYB1kwIbWkAYeaBnOsDaC1ZyjKzOcODRYwA5Oq7tAszTfY2Jn6 tXdZXxiZShHjniEcGyZMMZGGI+3pTRAD2gdUXzBZ+2ZBXU8hz6m98KrNCInhCEA5zPfMGJxIrLOt AZHxKUAERI+yKGOuALbNXR4/NOOlrejlFRGdQr/9bGD/wXp1TjQ7FKLVlgNFHFI/ILq9V4kqysY1 b904rwOpBQfyP/87b92sa1or5RmgQWsLABBxsACoMisGgjVKBohhKIbaQ2ofIFJjN5FdRW8ZNW70 1oyjxmbUxHz4ICZhCiUidIlgKSKFS5cpZLZJsWdEkAK5CuSU1LOnGTO3hCYRJChTJjp0rlwBA6aB kAZPhcxaV6WKsX6owk2bxsHrV7Bgu/Xo4cOHOB8t0fqo1aNbWLhxOUyL5qODmyCMGMXRoEVLGsBp Yk3gMYHGYSeHA0AI0Nix4xkqJM+wQNnCZQu9LmsGBMhC53btAIWWYOAEBgyeMJxZTeEMBQqhJISS rUe2/wfaHvR44N1bN28JEoDLDl48FAUJsI8sX47hCGroIDCAAHGiOggDmxZsyrJAwALvAsQLYDQ+ w3f0AkiQEO9IPXv1cUgooE/iE30N9BXkV9AihwYAAWxBgxxy0O/AAzNYb771MlCQhAzAO+EE8Oqo 4wQL6zDNtAUMMOAMDz2c8ATTMKwDPBTBgxA8ByF0UAEDNWiBgAmWsBECHNnQ0QUX0FmBCyDvEJIL OIo08sgigeRiBRdUCCAICCyZII384rhPgwuqICQLB9Z4oCGIJIroAxyowSEkiCp6qBk2GfLIGzHg fPMjMdgk6QMlGHpJhLRkiimmmdTQAYSdCs0lF5+AEv+qjDKKEmQLpJZqKqqohBBiikasqqIeeWrp Si646BqLLLNKNYusTj4FFdRowknhADgOiYOvvv6aYDDCJpjAEh5oCAJKCIII5rEAXAhABWgsCKAy C1TIrBd3NtOsF0B6EQ200Y7w0BMSoXPuiNhoE7e44OIRzrdQ0NXDNg9mm0022cCVgLnnKPAWNU+q y2I606o7IYtAAgYvEBbTG+/g88ZzZK/yxIOPvvsO5G/iAgPMwT/6CsxYvwwQhHBBBxVc4MSRUbTQ RA5F1HBDERcgkcQUSVhGxQUhVGA+iQkgwMYlaMiRDR5dWGEFdLgY8g4kkdzgyDuAZNLYKC0BLD9G lhj/papZvEBACa4ZimhMksCu6IOLJgqpmTg/yihtkDLCgSRdvKZGJbpfkunuNhB4Y56dcDH0UJ8k ucWMQgoRhCijkHqEKaegeoqBJurRVBRstlJ1Va+m6aaTTsjqoRYfykI1mssxD0tzu4zIiy+/ANNV 18IMOwxKn4cdNoDbG1PWWWcvs0xazDqzx57RQgslxA1Tcw62cMUlDrhzebutXeiFC07cI2xjnoIj XuPe23ypm25EfQOhkMJAviPBu4TFO09BR9iDjz1H6hdPgTje02++FvDbb78AaYAAOSCAfwp0QP/B KAfqONB8HtQiFoFnZibC0Ihe1iGWTSiDGFpAhFDE/54F1Gw9CmAggQS4syVYAkcQYEOxhoaOogkJ DkYr0tJsWMMbGmlJT1sMBJYwpQF5ghBVsMEnEPCAhYBJIncKGxPLVJGLsANNzWAHR+rEtrVlxE66 uFNE9sQSu93tLmkoAC7M6Le/IaonQikEo4pylKQwjlJSYUANEmGVRJyiFuEwHVyiEQ3Odc5zPehE OEjXR7nQpRPXGIEvZtWXFrhuMIXhQSUP47PFOAYauCOWCijTu99hJnjEK15o2lGalXkIOsuJTfOu x4cSxFKWu4BB9CQQhVrqQQLmut5xYHABcAXzOc7BwAWKgQEDUAc7htiFOayiiUkg4QQBI5h6IiSe C/8MYjwS2EUUJLCeOCxMPQqgRCMKQAJHKCCd6bSDJtz5Tni6swgFvBgMhliFe0RhDP3TGAIV0Ih4 BrQResgAJY7hgWVYyGUmG8QFUISFXQTUnSVAwQKW4UEVjSGiAb1Af2ZEoyXwgRxWMQcsKOEjJSHN SBvgwQVe8FKYwhQXG4jFLp7RtKFBLUpzMOcQZGAVGWwjGSYgalEXQY1FqKKLXxuTKo5qJge4oqhF VcUXPgKMqWZVCk2cG93AWJMRBCALuMgCdc5YqAIETlGMalTiksKESVHKUlPpgzGMIYo8eGouiPyK qDqxuUB245B8jYvmRKAGmvKFAIFJA2Es8VhLPrb/McFiTCeP5STKzECzvsuMKC9DSlO2IxQUQt5q VOMa2NCmeePQVGurkI4ppMsDVSjBuYwDrxJUgXmsbA4GqqAJ6ORrElYhxDE04UxzUEI8KDqYAH57 HkbA4Jn1oy4j1pOAKpABnPiLgwLs4FrwVuECAxyDM+/hznteoEAGNNB/7hleq9wDBRnALhlONDMD hBA8mqjCQocL33uQYWYedNEu4EuIFiR4RnMY4j3IYQKCVGESRFPpSuFQBPjicw4bmEMVBgGHpqEj aBBwgnQpwYcMa0qpJqgCE5sokSqYQE1SyLAJHACnjLAgwxd48RdncgBflDULQx7yWXMCOEmYQXC3 /yhco+CoFDA8wilPkUoFaoAIRPDjFFopHV/p8kfB/rHLhO1rNHrQAdXFoXWNJYwTnFDJwviMBk/K JLEeo1lPZtYyobQA8YZnj9AeL5UGMK0nzsDKcIWLtuQKhT6Gm47i0LZdxnFXKHIbCmHe67eo8VCW 0mEIf51guPeAxHKrOZ7nCsAR2B1iAsbzCfEwor7p7G4CD8Tf/Kw3wWO4RxhgoLMCQYG/UUDgxQyE IDJUIQEjXE8H63sihaaIv+tbxnDJMKEUdXBmIWxQhKbdogMlOA0t2ME9qgADCAQDaJgY4iRoqLRB VGHDG6D3GzZgb3p3+MMg5oKIXcAGCJgYxdVIgP8X1sBiJZKExXd6W9jMFGOKUIPGXxAJjr2gCvHi 2Bsx/gg7XDySD7RBCSnI2wbGOuRADJk7IDDyoRClqELcgihHgeMjbC5XqUyhBrMQBT4UodcxI7Ir 0ZhL0MmcuR60YQQzABCbC9PYXkXWEr7CUTBuN2fIEOuTnPXsZ/pMPFNKgETbQg1rVpON1DYvFIsu Dm48MNxaSoDtxBFXbC6tnGFCh7bKHIKWquOy7gQi3rtATyA8qOrfjge7djCHfGG9HkfEob7zEYB+ 9pKx/+BagQfkbwUI+PkBdv6ABEQQfZKdgBd1DDzPLlm2p7367F4o2y5i0cdIMO0FhbuABBjpEEL/ 0Jhg8CgOQywAiGsIB3pjeMP2fkPzmc9hDy8NxD5iQzACnt3cJuIIXUK4SMC2cCZ6nCLsiLHH2THx h3iDGhrJkhcGkBGOb8QhYCtJntQAhwOMIA65IGvKGZGFTVg5NDoyNYI5N6K5TLA5KZuyubqUKQCF VWAFbPAUozs6C2SVbngVOEgDW2EzGkiMxOiVw7AEKHEMxqgsOwuAreOzz7oMQPgzUzoClxk7A1CN 1TiDQ2Me1Vq7EqANcpEAfaiCXRAO2iIO5Kg7S6uC5CAmTdME6cCAY6gCQxgybBOAQGCEiOog84CP xIu8+kq2Y4if+JmV+voE+fifA+G8KjggnSGA/zGoAmIDPQIiADmogkYwoAEaPRhRgNPjGAURgPrC KIxagNdbAGvroBSJEAUJmZrhr9LzqF2DQxzhJCZZAT+4hzFYKXpLPnljvua7N+frsCKgtyJpGh4J BukqgmpQNiNACIQDuTsBP4YTP2qIMYk4vyr4gpDgCGCoAilIm/iLEzRxsQ9YAwTwAg/whCw4Alyg joCxQhAgsgF0uZ8Iils4QKSggwWcskrpAiFgAH/Ah3+oBFQAugs8xz6iCx9ArFgIDNjRBsIQQRro FRQ8wcfYJMfIszzjrN7BDHv4OlOyB20hrRCxwdZQjuYpQnLRJbkrAd5gu3dxHgrIrUzLO98CLv8S eS0QmEEKWQCBSQ9uc5jEu5kyzBI7UID4IIH60oB0esSM4a8B0TXpGoM2nEOd+YFMmZE5PCD/SLA+ pI8Woa/sChkPOpEM4K8MqAOhJIOi7KAIcRGiXA9HvJlw+yjpGgIUVIEXEhKV2sRNVD7nC8tQrIJR JEU4gCFjKQY4rIJECIUuUQIWewgXk0WSwIGLIJvyo4iJmxON+AJf1Ij4Wxu5dDElQIBhSA5mNKPu KI+AGTKzKhRJeDnBaaO2qjmb40ZvnCswoAJlsII8aAXLQUfRXBWuqIUOuAFt+AsCoCRL+sDE8BlL 6CF7nCzHCAJiqQwnWZau+7rhaYfhCYUT6Zb/4PKEeuGeRKMAiHwXD3hDb+JBd5kN5TgOigQX1nCN M1AN2kImSpAw65gml9GO5bLCg1mQ34K8+lIACWg8CcAf/KmvWgu3NMQ1BSMg/qrJNmxD6aoAYBsg elqvZIMBoKRKlRxKFEkop0TKCAlEolRERrS928uuKHCm3yoCBSOATFmCENARNtDKH6kw5Ku3e1O+ G3C+GyjRNxhRTiBLfCtFGFIBtcytBBgGhIDLKqA/hWsxhiMbHNjR8quIiauijFg/b1iEKgAGwDQB b3g/wYSbOzEJB8AEcMAFDCCrIWOE9Em5smI5Q6lGJisDxMnGy8TMBrQFA2CFSsAG0OSK0VzT/8Lq hD1wA2jQAgF6B9a8pMOIGhwpwclCwU5ylk+yB90UpT8b1HY4AgpZGenwBINEyO0pwnGhDQMbgtlY NOc5DnCZyCr4lnvBTk1Ipr6bBPTxSFFtrlhTtb34LXUaUDKgj+9KgFmhD+la1f/JtfyIyRyoT51J MALA1Tb8AQLwVQLIzx/IgWGtyQIhgP/UmJvpmPqiBDJ4Vmh91nSogpDRgwRw1mh9VkpQgAfh1hHi L+JyJ6uIgnFrAf5agknkERhCh670SueThV2YgRKdV3q9gRQtAucjxTtgknizgXrghhE4ogGgy1jE URfbURyAOL3MRTbZCC+4BxZwgLQBhi+oWP+LrVgiQAAmEgMlWIMskADF/JcsGA9q2gRCIRQkA4qY 89KZU4oFnKPMhIpI+AErUARUSFM2zVmw0Jw2AIIZsJUJcIIJoFM7hQAaUKFJnM0U7CRm6R0V+Eeo HdThOYI6WIZNEJEa9JbXwIDd4kEoGAKwHYJiyK1jgBdH9cFggo3c0tR7ucgJ+VQUIRjjeqcLcI/3 II/4+a2WPE/6KAIyQIH80ICVlJiJCRCY/Cid4S9g/dUfaFxfNTHHtc9fzYH/VKADWbwU6y8XAdfw GoOO6ZgRUoAEMIcEOIL+UIAjyJR52tUqCAEUJIMXAACYegZ3Dcsh0DHw4oUSvdfmswJ9XZL/eCOE WYCGt6TRF7vRupSIHZUi8jOBs6ExV5AC6TVSUtAxI51Y3AWvC/iaD2iGhOgFCZjSaBwy8bjSsgqE NFKyoGijmVOcm6OULohZMCgAM82Dm90Knc1fDsjAEdCBv2isJXAzxLDTOSNBE1xa28xHyVCWFvRH ewgCqdUWl2EZb3kOT4CN16AN2soS17oAfbge2kqtI0iO3cots+ue6eC037KOZJuEhfJIgHInZyID h6kZ59KEyhPd7JqYRriHIwCQwYURADkgAkkwXLuYNlRcX21cxtUZYY3cm1xiMqgGGOjJy82uBMhi LdZiZ1oQDDuGLd5ibh1jBkKQGCmgI7gH/0IoIP5SDKAhA3KAqSp4gXoTyxQNqhfYhpfahm2Agd0l yxFdUX5Ty0bABC/oklSg0TEZExxYuIYjibv8AIXFRdcihy/IB6vSuHRgAent5E6OgYdoCK7xAkyw jvFdgP+zwpSjjgIglGq0RpY1iqS4zAZwivhtwEfYhJpF01bohgrUXzKjCxE4AP/VFaE92kt6rNkx WtpM4MbAusdwktz0JEHtM94c1COYoAvZFkX1Fu45guPgQTKYBHKehGIYAx+c1BKIjeSwVNc4AhM+ NG9JJgNY4Sw4vQmRvVKdvPV4j/UoT3Xi2+76rkbYj1jVj/+QkYpZr/pEXNZl4iWOXMiFYv/GbdwK ODc9pI/JY8SbkcoqWJD6KmOPIQGR1g/+gMQZwVX+WqFgcIcekaE5rmMSxTBOuAEjMAKbvumbtldA HlHfXRohka5JiIFDToiBNVgmAj8zeRs1qUUTGD8akwKLdYWMY4iN4Lj3ez+HCJuG4FglcIAC4BYh 8w69aMxoJJQjSzKhuMYvneVHgNnMrAAhuAIBgAf7FYdaeItfBmYvG2Y4wJWhvdOomTqqAxY9pbNJ fObG2KRkkQzdsYAgYGAL0IaoFch8ViVVwsFV8h5wPlu6q9QQDufgME4KyBI5eA6zU5463IURWWGX OTXxmLz6YYT7IGlUDejsSqBMIQPB3WH/If6P0TMgmIziHzDtyD3uKMjUim7cJWBiArjoX7sYhdZh pvwYbn0QR5wPvm0gkt4f/WAg6a5QAiAEc6ARE1uC4FNXmKZjsSxRms5pnXYDN7hpHTg3ExXkDcgS ShiGos4Tumw4jEMARrZLj0OAKnCFspm4jcgSKeCIAYgxJdXqD+CiUBYJrkEAZniOLCVrKw0YlkOj XJAASUACNkqCtkoKOgCDV4iK+M3MS3hxOsgBeMAGvMZfvmbTaBhmmjLmxIgSoyXgOUu3xrDNxBaW OmuMGdBNZ1mW3vkzyB5UCagQelYl1bhOYkJIz0ZCH8zyS+UetTym4MIOA4i3QfCXIdID//BoLhIw MExQtfoh6XRCVTXb7vmQgHswhwKIVQL57SEekMStgvvUmb6DgeZ2XMfFADX+gQkw9B8o9Mbdzl8D tgPaaAHVj6lUh8mrD/pgoJI2YxnJ1eeGQ13pO2HIUKEhGiLBBQkLS3qlaZ2+afmWbyNwAxmQARMd UVLcAHNgAVLwgv4Wg/8mCSJdhLo8k7IZ9h2VuFwECQcYqUxO0gdHUiXNCF3QhYmghq5RgkM4An0B GPLo8ED48J0owKBglPbVRhWH35i9hLnOgTPdI9LZ6xtPx2HWgcHoGTmzU2X2maQl8sfgU9vMzcj4 pGUp+Mt42gD4MwowSgvZFkLDF9a4VP9wCe3UOg7mUefY6HLegoI7lwMQQSbUOAE+IAQs0I4FGLzv 0K/10IPzUg/1iDwGigO9bU/fnpjvuoBYZa+ELuI5JIg2LHQCaDw5aNxFL3RhqAI+aPRCd3THhe4l ztUWOGgSmnqq5C+N2W4hxpk9lJgEI5ACaoE5MDdT0JklaDxOcKEYgoN4W74TPVGbdvVYl28giHUj QLEiwOlA3sQSgIUYcIC+Twhgr1En+gAEYAEZQACPuxOPQwNyQPyFffaMiAGI9QJo3zhpt2rurRO0 EYMBUAJdgAZDvY6R1QsrLTIQ/4lbiAQvfSM6YAIpU/e5enEheAR3L0dflvd5xxxhJub/SXICS3AC o913H0/apP132uykGYCGyWDgrUv4PgsCqnWQDtEQbnn41CBtrqWtbAhn7qENcNHgdW6l3bIXDHg0 OYAOA8CCY5iEUNOOKNyFghEAWxgi7epnRogf+rjt3ubtmwEIDQo0aGhUxSAZggQVtNDQokWOiDk0 VSFg8QeBHz8oVSE0RqNGAjCqaFqi0SRIlCY5wsAYEuNIMgpyKJhZk4QCijYTVJGpQF3NHC2CRnQo kQDEHATGRKlSpciEHxNCzKlyD5KLFejQcRlU5cWGN2JvkDViRFUVTm7cAGG7dm3bOzKqDLkh9s0G Oy/moPHiJYaDNUrEmKhC7QMOHB8+/xyWUoUXAhyH2SG4IGXxB3bUHH8R4+3zZ2BVyDkY4G1AFROn P4vBTE0MtddiZuuKcQTEiRMgAgmIw4hRluC4cBUoIAkJEjO3ypRJImhLJjqPHoEB06BBly5Ctl/q /kgBPGy1ok2bxuE8+vTq17Nv7/59+mgpRvhKM8GJExo0IECwBGG/JZbsx18AwRgYAIIBQIBgMAkG oAKEM0A44QwWqFChChZoGIAF9hyxzDIn1FGHAbkZAIInZ5yBwRFHUECBi1WUQEEoNIZy44s4VjFO CT362CMfR2CAwQU77jLJJLuMU8UkICywwAlPIkGRORfoYYdBVQziCJdcxvGTAnGQpP8QTwkNJJAG WhRwj1NkEKCQBkIhZZFFFGGUEQFLmMQHm40MAYIw5pB0Qgg/LBECooWmtARLhoaUUUwSSRQURTQp wBMhmmi6qSaNQCEpAUK10MimbJI0x0l6QsBnamTEMclchECwQVhvkHWDWXxU4QdbQPjqq1u+YjIX L0UYS0gV5nDyhQMOxICAEgMQVgVm1S6GFguuSCGFKyxUcVliOLDDGTWsgeaYKqtVwYIJ7brbrhTl eiObGLoMc0SUuWUhwCcCMBJIcMUVkIsExynXnHOQ0CEddddlt50Q3XUHhgGl5NFKN+bBtzHHHbvX TRsjzBDLffpBEMJ//wVB4H4NLrj/oIMKBuBCghdOaMEMLqjwIIYZamiPBQEckUEGTy5gQIknDInB ihh44gmMGKRzQY02hiJBiy9SMIlTXXt9gZBOD1GC15oMESWUCwhg9CDIDkLRMWMI0FscjtR0kwKE XBAnAXbcAwWccBZxjyYENWS4nHTmIAwheIJk6BKmRHFPI1URwscPTiQawqGIGsr5EljcMwSiUREw wRJD/C2qUkddQIhEUAjqtddDPHR7CwRAYao5AFwwh56G4jcgJrDcY04DVcgwCBy0jlWWWZSwEEuv v1r/qw6sOnVPEQEwQ0qzDiAgmBiqkMMYZoph9kVhXZvwxWLh4oAGC17E5g07zXij/78rqp3mGO26 Rg7PNGM2rbEXvvQVCEd8ghECCEQgQECc4khCEmYwxQ4K0ZxMRIcJ1LEOdrRzCe50pwHxYIUiUFEe jXmshS50Tyf24IYA2GcJ/LkhBFbmnxs6aEHBoFmDEuQCmulsBkY84hEvZEQOZQhCFsBA0Yq2gGVA 6QRIS1HTzkCBFblIa12E0RFu1KIxjnFIR1ARBkBggKUNgQyeSFrSjEYCEmRgjgIg2tzmWDcF2E0A dzuTULQQuEEeTgNIMWScIkKANNCJTiDBE0oeBzmNgK5zm9NTovQUST1ZJAcYUQpEQvmQiAwlIgxp iKRyNyfF4ckillAJom7IhgCsQP8rXIADLjdghefhyixv+dUIflW9trTFCFrgxCfucgjAIMABD1CC EmJzGGtR8wNfIEK4MMMO9bFDM/ljx/5AAxrTkNMzsWFMuQroDQMiMDcL4M1v5gZBCQqsgmYwA3OS kATo0IEJ1bkOdiAmsUvgoQtQsEYlsBEOFr6woQ7tQQduoI1Y4AeHBOKhgmZZoAIdSGdDFKIKhjhE JJJUQkbEGYc+JEUDPMmKVxwSFzEAxi2+KGsvwhqNsJa1FplxaZ4AwdIwkBsrbmIBRX1S0UjwpLXN TQECIAGX/hgHmgzyTYErpEMW6ZBCJkUpjbSISRzpKEkqinMhcAIlN5fJx3FurHf/CpUqvSqpuQol kYbs5CobqcmofO5Q+8loLblwhzvksla3MosR4DLM6wGrmGYhi1hiAZgHjC8V0pJmNaeJmPglJn2S 2WYzMqMZacprnOR8zTTvJxtpfcBeFDhBFpY6NwcCLAvDMY49I5HPLfDzgw7TDgkJigchXCEH8MjD QjnAUIcyd2PT8IEaIqCNCVgUoyuDGYMM9MMCseGjNJuZzlYgUvEa0QUzWEESncihM2RgGURbxogM 4IncLE1IWGxR1XYKIy/CqABb5KknwoaLNS5NN0NN25PsqDY8zvEmfrRbTRZyJjgdzqoKoYlWG1LI xKkyI5w8ySQLtclCnfUHmbyk/yU997nHwbWVoVLkXEOFFFJ2mE4tuNMEPKxJG3LuZD7MygoES1ha 7dJW0EssXHwVTMYK0w1GKIUR7PKGGUwWAc+czWE0OxnNLkYziOlsZ7vsmixLU53jhM05PyBOA8JG FxHA15N4Q4JP+Ka2E8SEwXTbnC0oDBlMeAVAHzZQPBD6Eg3wxHFrsdzmMto98jmADu4TIAIpqEHB eJkQXfDDIYZ00+Ad7xBrKWodnPeIRYzQDIZGtCex9GgmCqpMz8BTLc60plqTaY3ICGsMnGhIBnZn HYy2gDmqbY5zZESDa/KluwmElDkgyCG1qpBQIbKRipyxIzMyyeCphJImPtShNP+n1hSDTsWG0vZX 3+pIofzg2l9t5KPupMmTqBUCl2bDpoNM2MLeBXq/tN6SgRBwYSb2VngB3wMeYFksYzYzi8myZ78s v2o+nLTmMhfEqaE/A6K2tTHAwNreeYI5z0049TQDEnYAhT1voZ8eBOHDIhax7uChCcONhxXyoOho KLfRPmdPN/YABGikQT8oozQbNIogkY5300x/uqijzgX0irqkFUp1HYkdpWC7lNdKY9oYZb1frcFI AjTSoovOGDanNU2NQ1IjCEIk7Lkt1dhPxQkfmR1hxNnVwtNOA0Sq/RCk1Ngl2gYJ6kCM1rKa2MRq ffxaJwm5HJ/7IncyPFhRcpH/d+fpdCpZguY06eOjE6i7XBFsYWtlZF8mGZgCfz3s27KWx9olBl5Y wxoeIC3YVFx91VSf/HCgC/kNv+KaIaA4QVMtja+TNbNpLTSOoLYTBEJtD4wgPQuACSSUIxI7KAMU BAEJhf0ZhAHtwiUqQHNCN6EJQoACK3SesUX/3OfQjUAQUDcgSmf66f7PCtOJF5BNnagRYKmV1M4E wdDQkdFQkRXxmnzBFBe5iNi9iNh9EQX0VAbu2tKs0VAdWPUZzR3lkbHhxCcw20IEjoVlWFYd0uDh lUW0QI6dDp7M4EuYRCStFSY93smsVVtJ0qNYHrplW6q00uUdoZ5EBQ5mkp44/4GP3VAwdJe+4RK/ GVkvtZ7rjYAWKlmTOVmUkQUpxEDuDQZsNEOaScaXxQ9nEZ8utOHwJYYuVJw0JR9opFk67Y9nrFO9 KMEheEJs6QsJ1BY9SQBydJ/KJQEU8JnLvQLMaUcXqN/6tZ/NXcEPyN8K1R8mRkMbHAAc8MB94FBH idSngVqoCaB4maLURV0tHeARcQiCQFEdvRerxdfTLE1Mhc1+pd2taVFP7Zp8eYLXncAmRMkmBBtS rVrWNViyOYLhXNizNUQapEFWRaNFMFI0qhLgfZUqqdIEUJ5eoU4kLZ7mOB7kPV7wAKFLLAG6vdUS dOPwdGM7diM4Np7kiZhZ8f9YLJEeBHTXEHHFYOWSFaiev7kFWwSTQW7hwMmek/WSDpACAqQCx53h 7wWfxLkhRXbTaGEkaIyWZjVDM2hGOM0LNegCAjDDUGVBGi1AFujGcEjA9mEBBqmcIKDA+DGBPwHa bz3ioNmcJApBHVRCLYQDeWAiJnbCNdAHBDghFDodpz3I/wEZKtZSqHEBVU4dOqiiVOZMAEBDgiwg A4IIlNSBS0Ug0wCjTMGUTeVi1tjikPyUTwWjO7WUsCnVsCUbVKFgnAySIXUYI+UYNeYOI71bjdFg N54OiNVj4wVPPpajouDgI53ERYTVndgHD/BAEGylEUEDVyJIEFhCZZJbudX/mz6ijIHwowtwwVak nkD2EpIB00FqoUHG3uwh1jAQAbTsXhmq4UQqxsQJX/EhxjaJi7h8UzfpT8Ppgkd6ZDg9X2s5QCiU CNzBltLgQosQIhbIwSEmAU0qjCH8GU5mh3ZAonBJYvsJgQRYASoEJXnQH1G+UA+EjA64wP4tiM4U iEcFIJAB4FNmxVVSZWCp4nlBw3dp5mXCYiwKG9JcEXQKSTH8SAkUQ02xyAVQQk2tnU+dyAOWSBwJ 27AN2wg2WAJsShEMhB9EwTkkCwxAGyJxSiNUQCwQgCYE5psEZu7MoIxqhDCMgeZphBKSmI8iCugx 5rxpEgEIgz8g3hJoAkYU/5IWxEIQ9MIM6IAUREAEvEAExEAE6MAGxIAO6ABX0sAEpMEOJopFHd3R JR2+kYMLbAU67NsG8MAcbEA5uIIV/tvrwSaeChwZSIH1zGZigc8aDMAAkJa1+J7E8WbwdVY3hcs2 EedHfiQ1gJPvddP+eKQBYUYMSIDTKA1u4AYusIhLIsF1QkH4bScddCcYvMJ3ApfEEBr7td8fXEIZ xJ841ELGtKfPdcImRgAbTMAO2Zt9BgOEBKAAhtr/meJV1hJXAOgK7EyCLEgQBIGBSlFLLYMaJajS AGOSDAG3DsEYwIjYTYEcZKDWNE1bKk2CqtEmDGO+yJH12dFPaAIMkAEZoP+AAvhBGMBAAbQAGRBC ig5eDlRBBVBCBQzODhBARVTjIn1VN8poGvyAJlDCRfAV5CimOS4moqDVWFlexLpVReRAHMRBk5IC NGDpMCDDNvhFFfgFyw7DMETAls5AEHgi4P1AD/YgypipLBlIFQwRVbrpIBTBBgQAEqweklXPa8Km wPEBH2whMTmZkw3D7ZEhmhWqoTocosqPZgwnDnhkN02GGWrcR25THEZq883GZxwGDqzBIWzgrrVI AegB96kcqW4BTRqCIfSTqv4WxIjnq0oiHqAAK6gBKtQqz7EnrnZMN6TAAbxB/tkQf1yaCmgXzYSU sfofKhqrVmxukImaeX3/F2dGa7QeAR0RzaoZzVBBoFBhAJKY0REAYzHwQQlMQjEYAgUwwC7M7orI bgnwAdLwru+egCHsgiZMAhYsAL2G6C7ogTqUYBX8kQJEQYo6hAaMASwoEuBVQWGmwQXAAMJOQAVU AEbsAFSkAQxoQhQMQQWcTmFGLAEUgSFEATnAAOrMAanAQKKY2Kp0CiVwDgzYLzkMgUYMAalEAQbA KAw0gp9YRBUIADGQQTKQwx/EgMv6hTDIgBQ4QBWgASzAwiI0CzDAwjbQwpXOADTwQBqQQSOQAx8E gwAUQywNASesCgCYACUMURWwQQHYwT8OQha8wF4EAi3YyhBswy7wihvw/wEu5MMxvAKe4ukf2IHT AsEG8ME2XEAs+AUR9M8FkII3LAIamIAULEIM9M9lbNYHLMIX9E8MAIMJuIIDSMYimMAFfEFiLIIU vA8C5LEreEEzbDERPBw47U9pxYYuOICLsAhPMQ0GFMARhCp2kmoi3u0VlJ/DBJQQ+O3fth8e6AMK tYI4iMOtJm5DTUM0dALjRgANOKFSLkjSDdGmMeV+4ucAEmCxblQAXKboBgENeCWxUauJIM3Xse4k mOuQlEA6cGsJDIEcjMMkDEE6TMIYhAEf2ME44O09MO042ILoTAIZHEMJCEACmEMC9OsuKECDkYE5 CIomFIACmAPgQGNDVP8jI1WEPErvO2gvDHgvAVSAJkwADBACJYyE9+YY6pBDBUyAJhACt3LPEpgD DFDC5XhOCAR0Q1PCDxzEQFeBHFTA6FRAI0QBjIZBEagOGZBAFRDDItyDKiwCL6iCFzQLAriCDEjD AzzGF9DCyhLBPUgDGry0F5QwMnBPBRBCMQSDOejBPpoDJhQDQ/MJJbBBzzbAC/xjFeACEM/BHLzA GxQBL1DCELCAWlQBLPiBrgQBnh6AFkZxnu5CWfNJBJACC9DCF0hBOhAGOVyTCWgCGtDPIshPu6CB FMjABWyxK4wLOaDBIrCAHVeBKwCDF1xAHUvBPSDAB4SxCaABOOmP/nz/hhkiRgR4ADiAkRmtCAUU ACGWQznQLQrYrcJUcqry7SNqMnlyMiRYQx7Uqq2WBym/0DR0w3tG1wxQpQvgED921yjO8lNiJQDG TILs8gLGIjAfTYl4XYlwTe1gQO+uyDIXwy6wyBwMASWYAx8IryeMd3kbwgIMwi60lDmgQAK0NwmQ gSagM1DYASFIwKU0ghZUgeFUwD4nQO7I4ARUwT7DQBSYAy4UOEDTbz8DgCWYww50o/TS4Om4rybw QVTs8xJkMwhggVqZA4ivShRktByooyZUQEffWBFoAowWgVCwNy5UARHAwh9ILSnIgJUlHBokQ8JV wTAkXDKssU0/QAzI/4AD+MUw2DgPxILsQIAwTAIEDAEhIDUmdBcfwIIL9CwlVDVhVcEGBO0GbPUb yAAj4IoUXAAQVAEPaOE2PMMTj8AB8MEf4CkPyACwWEYMSIGVDUMVEAYaHIYJLMJibMs2Mcaga0YV xDH7UEM62A81LMJhVwECsIMXyABGugKht5YXmI8XiEFnr9Nh6IISMEMogEMXCckZvQgmECIGSTIK zCQkGEIlrypwhW+r1lxt48EVEIAiiEMPCCXi9nZ7RMMp+0AbIMAIINYbrEDpAevMLJ1yL/cpPl3M 7LLoQpE6mK7pcih0CpUnIEktKs0RLPMxD0HrBtUFjMM47IIcEMk5nP/DLmDBJCSA0WgCGSRAAswR fd/EJ6iDhD1vFRzBQwD4SFRjjhn4PhfBgjP4Pt+HP3/v6ezzDhw4xCZ0x1Z0S/CBoDSCIWwO7ZBD Rt8JAFQAOEQBspiDi5e8AoDAEPACM1QBKbwA7SRcwrHPj9v8kLdP1yRckm8D7bSAIZgDG0RBMUi1 C3QXJQDAlq9Al1s1HIg5mVdBWXDCNrhBFSjZMcA5bKr1CESx14/AM9AOH3R6MijPn7/Pa7wPY2xL l7HD+3RTFWgG+4iBYcRGo1fBR34B7ZwxAiwCOcDx/rADmzWnHkhAKIRR2oGqBEgAFsAk3UIBCmxn JV/B3oZQJuN6JNb/thAIQiyMQCsI+7ATu3qYMnD7QApcAwJ0QAeowQjcgA5wFARo2oEgiEY9ZXLr p1R+lINYAmdawi5jAE5w+6qJCJRAZ9Kku9Oce4At8yRcwIp4QjFggCF4Ah9EMwgYggHYQTQnwAUY jTlQgr6vDX1/QoMVAQoQRAGEQUEUgQZQYxokbKgsgfbKozzqs4NTwj/fAwgAxJIJwmDsgHGQgCZK S8hRIuDk4A8sTuY0MhECY4h7IEIsAXHiRxUCBHJoqhAlypgcFTT90GTHAKYi275UiZFvkYMHD2Ls 3Pkl2YNUVVLtNPEFFjCfw3wigCVtWIwZsmJNIETpHiYI9xixYcPH/4SLKi4avOACB06VDYOKbJjz 4g0LFzduDMnnpgqQESO2PRtxYG9gO3b2As7Cay8QHkCk8FqEYE2VAUfFUDv6gZoUKR/YUbP8xXMV z19MUGPhoPOiC95EN4uhiV1sLx8QqJIhxYE3Md54ixkgRsyHD7GoSAh1hMIRDEeOSCigB4keLHLk QLGOApKh7GDGgGnQoEsDBhWEVKhw6RIe9XiatG/SoMw8OAda9eg2jUN+/fv59/f/H8D88Jtmmmii 6cGHBEVIIQUR2ujgACM2CAACCAIIJpgANFRBBRcudAHEEEUEMZgRQ9SQwgCCgCCIFnl4MQgeMMhA HQVIyADHDBbYcf/HEwzAwIAgJ5kEAww8KRKDEoYoUskx7llykhKKSQcLA46ZZBBCqFjmSkPOIWOB ScwRIIEEbCRDk08UWDOBRgqQIIoL0nCSDA1GgkGkFiaYYAmRnJjACR72FAkGTU4AQRNNnIAlignG CAOGCQjY0wmFllDIiSUOKuceQ0KAoZGMQkDp0EZgIECkkUwyNQcoCGlJk3TmoCSdP0ipwgtpyOlJ ChOEKuoLclIZatgHkvlC12FSoSUon6ThhRQv9nkhRhgIaSQYNqKARQBMCOFDrBVQuKcAOCZRa5BJ 3ILrggtWOKQEKfDSa4RjTAnsAMAOsOOPfP8aQQbCeJDBDz7yiYH/FFeqUIIyMY6iphnNIPbsqGao EY0a0thxxRUHvCBnkYshZicdKdjxIp0vYsiJt952A04JMXRxAJNQjEsOuSOOkwA6D7DYobrrtjDE kCuueOWVMcBjoAshyjsvvfXcEwKLJawYoYMUfOgmmgE5wC/AsMXuD+wCo+lEBBES9AFBBVPY4wA3 NlgBxQszDMBDF0osUUMMTTSxbg1ZtKTFGHmIJYhYcFnzxhx57PEEH+s4AYNzq7i8Ck2OUJLJITzh w5wqSqAEgwsu3yVy06tAfQE7QleIhDIZUQDNNRXQQAPVozgC9yHMefUekyadwJIJROIz0yWcqGIC EBqpwhwYyHnH/3noTd0Te5MYquDPg5zg457My3ECgo5AiOLyKHDRoAoFSNKEjDFCN+cCc5YpoZFx xnGFlBiq0IkWLKhCMkhRrFQ4QAYyIJZQjrIsAZqggD55QACrsA006GAqVeCDV0gAiyrcoxggqgI6 VjCJe9zDDlWAwyvucYG3vCEApmMBH4yAl8DYawRVyNcO/4C5KhzjAMw4RhVmOIINDPEe+2DBMBp2 mYhJwTMU+4LFMEYaajhAYSyA4sU6Q40YmICIUtAFZtjRspYNYABKGIBwgiAHm0mAAgVQDnLe1LNy AG0H18EO0a7Ane+IpwvjMQ96oqaeJlQACj+ARweu0QZx+KATXP/7WtfANjZLBgg/0ehGJ3zwIEY+ sm1u24MaRhABLqTobhb6UN1IhDe8jeiVgQsADYJAOBe96HC4IMGackQCEvDIR8GMnAFAECQjIemY RToSkoJUzB8dykfAXACOFiAAX17TRrZbE+4UkAPc4a4FBJhDBUwxEuQJCntLUJ4T2EmpCfwAUNoY Agj4FAU+DG9P60QeO2nATnYuASPqXAI8CdACbxpUAQbNwUIZqgAD6MMZlOAEGogwDAcgwCfDKopG OcrRX2lUKCHdqE88FhUdUKhCGGJDiUK0Ai68lAt3uAMcNlDTmr7hDXQxQg3dAAR6FeYvOxTqUAET mBEAwQEx8ML/Gh6gRuA8dWJRlGoUoUqN2HSGHc3wRjO6SA3hjJEawPHGAMbqGzQqQQkzK0c8jOMc nIWijkiITjmwYIod+MEPKNhCdpjQR6WBpwtdIM8g0bMePAhhBwQoRR7akLa12acbkY0sgS5ZWQEJ iECcfBApgXCANiAolD5YUBsQMIIbwEFwFlIlhdiAtwxhyLWu1RtLg6HaFdWyljygJeJwiQHG+RJH v9xRHRYQuclFzkfE/BEymbvMjwgTucWVrjUzIIBqZuBGvtym7bj5zRaEMw3hHQkBBPInJ9BAne1s J6D+makJWAsGUdgI9vYEzz2FwJ/5TV5HJPWDkSxUAwC23ULX/5QDA9hiFEOogB9U5gCdZLSjEf6V SD1alJ1YeCcIcMAwIoDBCnllpSNCx0vRIVO02BSnOb3BTt3QU6MWhqgx3uGLvXDRpqrxN2IFTljF 0IzKSHXHFtNqV5vB1SgKBzNiHetY0ZjGmCkhC8WRwJSPUIDkTJlnEsCEXOuaRxRgJztF++vSmkZY QuKhAmCQRDBKoQZHqk20bWhkK9qAilqE4z5es2zYBpTJHjwobm946WIfuba1pQ3QEpoBGyqUIhSp FkUsdaUrYWuhwhHOErjUdCxicYIMKKBGjNtRBpbBoyAZALkYoBxzlekJTxQTAyCINXKj+7hpLuCa u7xRNru5zf9verOg3kzDntIwqYEqr7zr9CcP3nHeCfSTnfI8CAjWy172nvefyhYIfyUV7NuBesA1 WugynDGLBMyiAmhQqgQNGGF3V/ijIMXwAxzshQ7PAAIrZYOJVoAOf790pjR9wwZwqtMa+vSn+pKx jP+1F49BZg1oTePLKrNjz/x4qp7Rqo8x7pmvCocaZlyyk9EqhgjIoa0UOE4cmYOJ5mgZCXQ1hR73 aAgmjOEV3wlk0552CahVgAm4WAEQ8tAgOHeyAyMoxQ7z0IpwhIOyldwzf8rGAU2K4xpqcMMbVkCD OCxhA4pIQWgN7aBRAmED6HB0au92Nw3N1kOUphANBmeJTGv/+kWcVlyvf6ujx6H6uMtFtTJR/SMD ONeYz0WuAYjLI+GSwJq5HrA3b/dNOxV0vAJ5x/DgqV5s+xPa+qUUDdyJPfPqt53KbicBfqBQbaoD m9rNgDMQ0QdEJKALRPACRiH8bt9XWN4bxbCG7e1hu6kUROhwwQpcGtMT31TFK26xT4268AOo4fr5 wr5Q8WXjiKPxqeHv+MSy2hmLeSPjHv8AWEO+m96cVQlrEIMDsKAHLMORyhSQQHOOgAlJyLUc7Mo6 IGGPruDmkgaQmEaQoEYIMiEQ4ABrGATOREAc4GYDiEEB9i3s7GyypM6yvKbPCqQHUiDpYCgWtCAO 5oEA4KAS/7TG0F5wQfagtCLgDlJEtRqtbiwkQ0AkcCokCGhAt/JOUGLhcA6H00CA77Iru2ztBCDn UIhJ1QpP1ookSJILubLAuHbEunCtmnINu7TJmzSg8gyqoIptvCTlT65tvfwJAtgJv0QP9dbrHfbE EsrL9PYEAgRiT0aiBcTQduJAu3Jtl/ChD4xhHWxgEvzAonrv9xox+ORNgujNYzoMpfJNBbwCRJiv +c6CpqAvp1jMxaovxrCPFK9v+4bqL2psDZgqZnIMODBDqoQMM4oMyNxP/daPjCDmZX7jrFJBCRAg C7Dg/nTGrZgDF15Oy7AgEnYgj6AAzIhmDG6uAf6KaSpAsP98jgG2IA6s4AAaybHUJm32wAh+QRCu ABLKAAQgAAiwQRzwjJI8kM8uKwQ7AesiRAe0gBHy0REcgQBcAB6uoRWO7gUV5BoQIELgQAVoQCFT S3A25EJkCQJoKSIVkgcyrSpiwRKIUO9OgO8+Dbtu5NaKK5hEMtaUC9V8pCRR8rk2IQt5xLqsK/Yc YZe+LaECbKG+67vGa9gmZXjWaZ2grQ35Kb/eEPT8SfWEcr300J+whwDSwHZmRwEEQCYdQQCq69Oe ABGqoRqqIAwSQAse7MIcUSzhDRJ3wsE4bAUqJN8CoLVYavncwaUCDvroQvpCEcaEqhTVQC/3shS5 L18cbBX/I86pXjGKuggHPAMHykjjuqgzkMwxr8plmiz+VpEHsAATpkyO9q/KjBEX5KgAtgwJfkaP hkY7bq47/iiwxqM8GmAHtOAG1KCRGkS00mZBOuAGmKEB0KMC4CMO3kANUKEd33E/pA4Ev8Y4CaRA usEHsm4E3oAGGCEQAiEfGYEfXYAbr0E2B/LQAA3t8I3uWKTRLCTu6iZDVMvuaMDu8E4j9a7TcqCb 3JOXGqfURJLWmqnwThKaUhLVekS6Hqe6BJHXaJKh7CQHvstO6Kt49qm8QK+fFDIE2nAiQS8iz4sH jJJS4hCe5jCdJgChfsuXBCDyYHIZZmErLycRRmH3Mire/8bSESls3ujNC4ZhA1RALdeyQ0JkBuJy puZSp3oq4YgqL/fSFIUUFUfAwSBu4l7xA3CgGWBRq6Sq/BjTq7xqjGDx4nbRyVZRB4RxyuDqCI4R F8K0Mz2TZ7iMGaHAD6Bgr4iGCQ4w5wBLsITgFcyAB9oMO2mTNlOgDfZgBGbgFoTAsBqwANhgsews HAwEOY8TBEMQOc8G6SLEF7QgOidVABghDjQAAu7gDYjO6LRTlEiJ625rRRpSlh7NQixBIQ0nCNWT 0ziSwGwHu6bJ7x5nmIgp1VRtmJxpmJqQV0PyIz80QLUpoRYq2JqSD/HpKJWnn5SnQtgpKNuwn0Ig 9D5vKf8v9Nokhb6GJw360EZgD0RvBEStKwtIYBXqwYdK4BN4z0VZtBHjjcKaoqR04AfzzUJaC0RU YAXgkhNRTMUOjl4UTvv4UmAHNvv80kgh7snC6gOaAQccc2IWtsgOc0q9ymGjCP2A46wCMwLKYf/k iDO/VEwLoDP7TxK27I6sI6/2KjsMcA7GrAEoIbDAAAkgwAhg0+jyVE87AAhmIBdeoZDwwOfAoBDm AR3cADbF4c64pkCWFjkbNTk7oRZEIOsO4AZ0IBYCIQuyIDrnoVLj4FK1QBtWYAOAADYpUDvhTE9L ywhOipZKVUOgIXB+UG5TVVWLEJdiwQAaKtRAclaBybj/DEAkofDUgKSZau1xIk/ybCfUukkD+rBA MQ9yzcnY9unzJrRCGjQimzW/oI1zSc/zAAV0mVJSio2bSMARqitcq2kLrYkfSvRyZgEs10D42LWj VtTdRIqkJnEGvhMHVWAGVMAd9PX5CK5fDw5fhooUB1Z5iXSHHMBIHWAVS87iKBZirDSrQA7JqhTI eIMaeHEy1yAGLrMAPNMYyzdMv/RNPjPmymEZdyAJ9CrMbA7nxowBGoAJJMAFyLYNJBBnHwQI7MEM uiBqCEk3u4AOzEAA0GHpGKkVaqEWegDPJEuyOiEceqAWUuAaIMS03GECiAEEPphSGeETvPZS08AJ XAAO/5buTgVStNZGT+FGbmYgCHIQRWZgPDWkcFqEIuvWCDXyBF61RjzSlxaAuJrQb5NL8YLpPukz cnbkl74VXK9JAIS1QB23iseLJ/Hp9H4A9conc5tVIc9LISeUfPILUOaw2ejrHdZ4D8OL8uZhH1N3 C+tgE0D0CfrAddMBGtTVdmkX+ITvo3A3wyYRDqBBIWkARTgEeN3hpYa34HbKX+8y+5aXLztAYE1x qI70AaLXFSvDSjOOjHAxOKiqx3QjY9cAAbY0FI5RAsLUY+VoZF25/woACTABC9i3Gd8XEnbZ5kzz jxqADgpg6BiJf9OGQdpADYwgCG5BgAmYkMyDPF6BDv+QgBjeIYVHQA06gJFQIQVaoZsZ5BoyGPtM a0IOIQvCFASyYBMCYRPmQTo/wRHiQAvmWQsmgA1S+ACyRhxY+NBikJRMyW19F0XgVkVqCVV/EO80 LXF+mKFqZCZthJr8romRq5hAYHIUD3CLida4kAQCoQt/CfK0Swy/yz0b105wB4vpi3KXdXPJRy1d 2qUbVBtaOg5n2vT+ZA7DKw20gJviQB24VirreBMWIDrXuR8SAXOqYRTAso/9WMLebcLgtfho6Ttb i0P0dV95lMWoL6i0b5IpOZuVt2CbFwEgA62ktzKKDBbXmkpB7uJ47KnOehUdgBQkocpcbjPJd3xH tsr/xtc5AHAHlhFNv2yXIcEA2/RNtwAX7gAIOmB/8ZRB3iaZfyEJmlk3dROahYBpwoMOykAS5uEd ZgAO3sAIuPoAKuGogOAG3gAh04AYOhMX0jlro7NSHcFSv3aew2sCIAAOrKCxG8uxzvZt1PakBlpD ZuBtA4CgZ4lF6BbvYsRwsoCh3BM+FSBHHIc/IUdXn6tITuC4+rMJQxS4tCubGpcAvglywwmLJ8W+ kA1VMVdanVW1DhkCtIHu7juMy9iMo828JsCmdTq8NCAO4jhcA0EANmGoTyA6j2AWkDp9hkFdH9Gp b1fCR2qQY3QDoEFuZ5hDcnQFdEAuiTf6pu9fvRqs/y05rFOcYHdIwzAqegfTkxeWYrMX5HZM/MQA rQLTC7TAOTaTOZpjfPNaZGFZjvzPZAMwj/IqCXiZDtqUCcAADKDgAbFmf40usiX7Bn6BmdFDCHwu sytgs8Pjj16BCQShDMygADbhGzRAG9gSeJFbG34hDgKhAHJhfEU2nbdWOm3ba+kZwNOAByCACzbV ZsHRU3M2QjZAhl8JbuMOuSEAbkW1uXUYoaGbBxi6ocDNRhpHuKSpCT/CVgvvuE5gqF0SpAXxobmr cR83ckfCv37gB45Sv7+YDciHd9VyjA+5c5ft9JzApieAjYdNpwWcOqlyHhYAwdc52TfhCWahHsLA GP8AgBtsLCwnnHZtV6opcSE3xAIY2Rd0oBO1eqd+qquTV2BR3JLTXcUvOV/K+qIC86yhyjG/ShfY 70orDscn0wEiIAvy2t+H/JWr7BjHV3xBMwBnzhl1eQs4oZeZYAcEYAPyucoXJLL3lGopO06tEZrj NJCWpgGQBgxeAQzalA7oYAvO3AzMIBfsvM4xIRckoc73Okxn28D3kYS/dqfTIBbCqyogQGzdoBsb ZJ/LTkH8eet8ARri7kQGmqBVqUUKOodtiaE7VB2CuHGmqdOjyYjp89S+eyRxjdOlONULrIrNO5y6 jb5iXb8yollvEDxBjNEyF9oeFPQERSGvTUOBPaf/dZqnNQBEbdu6inrZMcAW+KERbG8UFvHCmtra g29FlcAX428n1sB5vWADeoHuUMQCZoCRdQDc+bV47TKolhfd012b1V3d9bJgsRmVA1MwYybG6132 qxQHGhYWYWYyEcALeACWhRzIB16vz/fO79pk2xdNU3avOIEJDCESelPi+bfi4SYCMD6wmqYLYLb6 A2vMkYbMH4EJSn6Xt2ALoKAMoGAHbiESzEAS1t85RDa2cSFrtZYRurbPNQDAd34CcEkhRXuBAaKN OBEifBg8aFBEmz0IRtzQMSPiChcUZ7hQAS2Axo1BAgT5CO2jyCAncuRo0cKkgpUKSJDIAJPEggXL /2baPHFiQZ2cC04sw3nTZgaXRImyVKDBpMkWBJo2XQKVwAQnTn5MdQKBKoQQWZ2wgRAAAlg2XsOG /SqWhlgIamk4cftWG4+3PCZMtZtmQpq9aeJocCRgnoAFAgJtOrwJBIgzY2bxS2CHmQMEDyqnepAq s+bNnDt7/jxgQGYlA5RsXvMAgQMvEXwFoaFRRUR3XHTogLMhd4Q3N24Y+e0GCJARB4gfOK4mufIO CNR0cP68g3TpzpVbP04cwR4l3JWI+f5Bl/jxusKH14Wj/IcPYrivWTMCGq4CIHDZPzK/wJECBfLj n2+fffzpJ0kBmCCBRDnlRLIDFFAk4ccWnBgCCf8SsVhxwB5tpECQCCl8uNABEfySRANdnIhiil00 wOIrDbwCBhMyQkIHHZlssUUSSZSxQySRICiJJJgM2B8uimURSCDEMBKHIxr4pYUWadRllzZO8MAD DVoG4AIcN4yQx4Y+FIQQmT6k0EYHBxixwQwTreCmRS7MkJELGmWUUQDQ7OnRntAssFRKRymgjgJD ZTCTTDLNxFMddfS0gAE86XToTIgOZdRROWjQAqcEoOTUBD9IBRVVS4RwKldarQUBWmy8yoZZa8Wa FlttaUmVE1fZxYOVePGlxZNNAjbPJoYleVgWmxTgzBA14OFHDA5Uhhlmn12LbWekhSZaaaGZZtr/ ew844EAEcASgTUcRubnCbbht8Ea8vfnmRnAj3HvcAdYl11x00/0LMHT7YnevGgi04V0KYpSXAnnr reewekrs4YU7WRQZoID54bLfxh1vzN+QQyIhiYIM7rADhChA4gcmE9yghoYceghiiCOWYeKKLJ7I IouUwPhK0DLSYQgdOOKYhCBQ7FCGKWaYQbKQ/AWYGJKBBBZH1lkHK+WUdk2QJQ1ZigSbl0CocU0K AyXE9pgK7VFcBHCyS5ELE3FJkZ8b6e0noDl8qlQOLcVE1FALuGTT4UAxOqmlMMF0OAktSX5USpsy 5ZRVS4g6QalQhQD6EluBLtZXpo/1qlgBvBoW/1usaukWrtrINdU72uAVC7DCOuKIYIZtguRhiulh CAOUcEKEF5NRm5m12WbbbSrcdvstt+CadlllCBzgRZsdqSDbDO7owAUc78LLmxH0AuHGvcYhZ110 1QFMP3XPKZfvCMIBcRwC/u/xHu+I4WEDPI94RLCGA9xAG1mwT33qEyD87Oc/GuNYxjYmAf7kQhII UlCPdvAMP6DgGQWwRCnQtiEOfQhNNvtGGVzUM529qGdBA8MrhlYjSOAIBTrSUY8iAbUgBWlA9kES kgRAjHkwghG8gxJfJvCOt8BOS0GwhCW2FIA7bIB/aesQQsbkthTsQQ0OgcMK4ITGieRtTnSChv8L /ATHPxHgb4FTgOBWgqmXEM5wQmlcohLlEgFgylCDsuNJUMKUURHgB1BZwiI79wNTOYErayFd6VK3 uq9kUpNpUctaYqcNsd1uLlC83QRypzu/OOIbAihMsn6nGEyggBPP+IK0KGMZ5z0PNNPr5bdSgT3P VGsNqmGNazRiATf5ojbnk9cbfmOEeg0HX/CLH3Tqh035JUdfxdEf+6LJP4MBsA0FNM8HGraHEUQg AIzIgjvfiYsGBqg/U6snBjB2QQGFLBeYCFI5TOEjEO4AF8EwAgpVuMI2pElELnxE0GYYtIiCwYZg mIOMmFA0HEFCR4Iog0dRFkQh1rOIxkqSYJj/5BcNRGkvp7zLa7TkuiCABSwBUMEKNmCEA3RAIF40 U0E8tAc1sckX7DrjGd8YpzjNCRoR6VsOfkDHO97RUEWBnAAWlbisJu4lgHRJSzTVqU59yilPaYpd nLCESE4yV1hhAyVhBVdYbQRWrWpdWKZIAyvNDlcTMOXX+KIBYcVhHr47jGFAoKz5yEIWXyDFMMjF vGp1Rped8aVld9m87I1LnTqIjQos4I4V+AIOOsjNBnbjm/UJh5rI0Zdy+pXN2F6HYMJxgxF4MwLt IIxDHxCBLggihgPw4BBLXGIg3ulOxOYTZEWiJwUBlJ8hCYmDZvinKcpxAhecLW0zS+hCb/YI/xtG dLwxApqMDEEhHW5BEDz86A4KAUQEkWxIRGyg1Uy6xKypVKV54ZVbXgoBmXpkIwReARxKMYIOdJEg XzzI2w7ghgjo4IwTfiNEjIrGOa2AqWecwQLm2JSkCC4pK/GqSx5HlMFo1XGJysBVizIolBxSA2M1 ayPtwsitsIWSrDJdXDMJARUEQwWxOgtazgKWKVJFLrPTxjve0VK9vGMvfhlWYI512CxAEBdfIEIM lEcty2A2M730hmVFM+bMPmAN5DKXBYKwrtDexrTw6o36wDlN1u7LX9dUcAeC6uf6zfYAlbjXN+f1 hgzNrEMi+EAbgHCIWGghawJgBDGU5c54av/6gvTM58egO6BcSKCfmPBgObKwAiDs9EM0q1kH1PmN WyDjojIq7xxeYVGMMgEZRIPEjZAGBR6hrBBm+JEZhligqRnJnVdTYn4Du9K8YGkCQZgLFWnQkZkS WCPB6NIbtjszMJZpTGIko4Rtg2GjohuNdLKNmwLBlL+J2JAZIGRR7t3KrKpYKDBp5YmPImKTNAVz ZE0rVBgZOtDxOARFjmtcXfCqixC5VXJtna3U4oRQNnl2UP7rXlbapMEWJhDFCoRiEgMCZhDBseSa lph3yS0xDMAbZvalMDN7mWtpzwHD2IAKAhDn0Y4WffICTnBWmy9u7qvP2LyGn50esG3Stl7/89Ku hsz0W4J0gAe/iEXWnD2P4yY3Y/rpz3PJDmr/DKifCfoRqkuxaoSCKKjqPEQSHkHri+Kd1sgoGiT+ rkNBCL4Mz/hhJMoBNSBhIhdENBJik1RclAaWL9IGW9ioKJaO2HXbXOKCFbi4IS82eExtaMgNNjBh LqS7XRiesG2goYMPK7KOU4VJiSdHAkEeLnKIShymECU5yrEkcH8bOFmr8oPkf07hlmT4q4IRDIdH HOIPZ8PPNULTl75UbG/J+OzAhrs0BGtYcWBEYAJjRC1ngRiHIMWXwcw80EivzAOQec25pXNrUdYz xHSAESJgAUAnPr4wZ7rxBhFgZ9FkL+6T/3TWRD9B5XQRGGjSAXX3I3XdVFul0BvB4AY75VsO9lt7 EAS5M2nlxwjIomVbJiD4QU/4pDHKVk8jEyRIkAuMkGpqkEIE4V2vtgHfkASZUCM1smuGwARBmENA aCNIIwhJUwZL4yNQA4VClEEj9U6FoUTlFweT1jWVhyV5BVMChn0bMWSvogIUoQJcsAGlcABhEm6j RxAL5Qaot3rtwgWqZxsX1i6yl3xRtRR2JHyFk0dcpUfAd2IxMSgasBKHtBQFt0jIZ3DMxxVvBSvd RmTUR33gY301ZX0RR2QbwRYBgFfXBhe9wgN5gUpp4CSOUH5KlCRGVDXt51jKszw55xlndv9maXYt wZQKxdQa60KAo3U+COgbwLFaDFhNyeEv9COB1xCBzFiB04E/2FFb6vMQcMchX0QQewANqFSCxDBy Jmdf8ySOaddpzRVq0lUgWgAHlYCDrNZqCkVGPVgGmXAjf0cH9rhrQViP6pUjPfQMZVBsAfk0UZML jKdsRWQ1SuQITAQlXRMLWBJKU5RtdbVtFIE3cuICpfUledBFo+dg5QYE5oJhqqd6rLduZyQAZDVH xHcUlFOIuXcogFgp9wZwgXU5BJc5yaeTaKVwkwQ60rdJFwErEEeURGl94FNTP1dkEKAN9iA7sJNx eWVKsaAX4vckC2mCSYIsJsd+7vdYkPXAcpthi71EZs+jS/uHZsCUCu/hACFJJzOgA8tkPrgRAag1 jNJkjK21HEwnHRCoYMz4l1D3jNWhBvmjP7alPm/gBm3AYAnRIXuwArcTJVnDCKwodiqYMVvWaRU0 T0RiICCQBhuQYDm4QizUEBEQa+slCEezBepFj6ypmj20Ix51C8VGbE8jRJJgkAdZUkpSafmVhdGW Bg/phbAjU7BRUxthJ3XDnHWzAuVzA+DWmB4pRg1hBKR1RiRZh+RTkhO2AgEBADs= --_005_2DD56D786E600F45AC6BDE7DA4E8A8C117F1A14Deusaamb107erics_-- From nobody Sun Jun 19 21:11:27 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C766C12D950 for ; Sun, 19 Jun 2016 21:11:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k3zuXwu71bN4 for ; Sun, 19 Jun 2016 21:11:24 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA23C12D94C for ; Sun, 19 Jun 2016 21:11:23 -0700 (PDT) Received: from hebrews (c-24-21-96-37.hsd1.or.comcast.net [24.21.96.37]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 21C3738EF3; Sun, 19 Jun 2016 21:11:23 -0700 (PDT) From: "Jim Schaad" To: "'Daniel Migault'" References: <1463470661.2914.4.camel@redhat.com> <1463647224.3558.14.camel@redhat.com> <1553247361.41476124.1465542998520.JavaMail.zimbra@redhat.com> In-Reply-To: <1553247361.41476124.1465542998520.JavaMail.zimbra@redhat.com> Date: Sun, 19 Jun 2016 21:11:22 -0700 Message-ID: <015201d1caa9$ce55ac60$6b010520$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQITJ8Sxjp9/WLppEaK8fwzXNAvZmwJFvxUtAXSzPBgBfRR6BgEUWw54AplvstefJ9bTMA== Content-Language: en-us Archived-At: Cc: curdle@ietf.org Subject: Re: [Curdle] draft-ietf-curdle-pkix-00: a simplification proposal X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2016 04:11:26 -0000 The one downside that this approach has is that it makes negotiation either much easier or a lot harder depending on what you are trying to negotiate. It makes it easier to agree on a curve, as the curve is part of the system and now does not need to be negotiated separately. On the other hand, one cannot say that one is willing to take any curve that is supported for either ECDH, EdDSA or EdDSAph depending on what type of algorithm is desired. This is going to be complicated for ECDH given that one is going to potentially need to negotiate the new curves and the old curves at the same time in different methods. I am not really in favor of using top level OIDs for all of the different combinations of keys and algorithms. Jim > -----Original Message----- > From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Nikos > Mavrogiannopoulos > Sent: Friday, June 10, 2016 12:17 AM > To: Daniel Migault > Cc: curdle@ietf.org > Subject: Re: [Curdle] draft-ietf-curdle-pkix-00: a simplification proposal > > I support this. > > ----- Original Message ----- > Hi, > > Do we have some consensus that having top-level OID would be better ? > Please provide your opinion and let the WG know your thoughts so the > document can be moved forward. > > BR, > Daniel > > On Thu, May 19, 2016 at 10:41 AM, David Benjamin > wrote: > > > On Thu, May 19, 2016 at 4:40 AM Nikos Mavrogiannopoulos > > > > wrote: > > > >> On Tue, 2016-05-17 at 14:20 +0000, David Benjamin wrote: > >> > I would actually advocate a different change. I sent this message > >> > earlier: > >> > https://www.ietf.org/mail-archive/web/curdle/current/msg00203.html > >> > > >> > Rather than use parameters, allocate new algorithm OIDs for > >> > everything. I don't think we actually gain anything by exposing the > >> > relations and parameterizations between these algorithms. When > >> > implementing, they are great for sharing code. But when consuming, > >> > exposing it makes parsing more complex, and it increases the risk > >> > of reusing keys between related algorithms. We can get the best of > >> > both worlds by separating entry-points and sharing internals. > >> > >> On your referenced message I am confused on the issue you raise on > >> section 3. As I read section 3, I do not see anything that allows > >> having id-ecPublicKey as an algorithm identifier for these keys. > >> > > > > It's certainly possible I'm misunderstanding what section 3 was for. I > > was kind of confused why there were two encodings. I was getting > > id-ecPublicKey > > from: > > > > """ > > Section 2.3.5 of [RFC3279] > > describe ECDSA/ECDH public keys, specifying the id-ecPublicKey OID. > > This OID has the associated EcpkParameters parameters structure, > > which contains the namedCurve CHOICE. Here we introduce two [I > > think this should be four] new OIDs > > for use in the namedCurve field. > > """ > > > > Anyway, if we go with top-level OIDs for everything, this is all moot. > > > > David > > > > > >> Other than this part, you raise a very good point. It may be much > >> simpler to use a common OID and move it up. Unlike the NIST curves > >> the constructions we have under the eddsa OID umbrella are quite distinct. > >> > >> I was concerned about future extensibility and the fact that > >> pureEdDSA and PrehashedEdDSA could be with separate algorithm OIDs, > >> but after thinking it further, I think what you suggest is much > >> neater, as having a single OID to identify scheme+curve will also > >> restrict private keys to a single purpose which is a good thing. > >> > >> +1 > >> > >> regards, > >> Nikos > >> > >> > > _______________________________________________ > > Curdle mailing list > > Curdle@ietf.org > > https://www.ietf.org/mailman/listinfo/curdle > > > > > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle From nobody Mon Jun 20 15:02:15 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74CF012DA8F for ; Mon, 20 Jun 2016 15:02:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.125 X-Spam-Level: X-Spam-Status: No, score=-4.125 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F-9M2LvgAsDp for ; Mon, 20 Jun 2016 15:02:11 -0700 (PDT) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0E1512DA7B for ; Mon, 20 Jun 2016 15:02:10 -0700 (PDT) Received: by mail-it0-x233.google.com with SMTP id g127so4116773ith.0 for ; Mon, 20 Jun 2016 15:02:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HoloqX0O9dzHcAM/NYis9cToA5MsnYgFkOezVScJ/Zk=; b=UCpyQTU4j44RC9aHCoV1LwUopNu/c5x4jgXfxoIMylnpIdP76RGk/gOdKp4BMA18wG DAWOc7TPAR+ggntaAI+rwENi4H6i9FThwOcMJoYmvNJRUjB/cOb+5kCVoYCXZShzmFOj bobeeXNekZGZ8pmneOIykAScGeJWq+FzjIP+0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HoloqX0O9dzHcAM/NYis9cToA5MsnYgFkOezVScJ/Zk=; b=m+pPsiKM2mp2qfrHVlP6mItodZFCPFeYYjJ9L1DXUrdMmNAV9jWZnhjlv+Q8Wvg4xJ CJbmD6bYj764XOY6TYZFIGITJqEYen2LWi3KRmYsCENcU8toUxIDlkyQFC2+U4bY00hc /J0jk3Sfhi415XXk8RMbjQpDGftzF5c1TPDOULxJZv29Z0W1rboCPxUMEnhY0n1nvNB+ Z7TZ4sXqhpDfS2GV91di9cvWHLM9eYfkNtDSQKPwN82wd3T4++3HEFSwUVFj/yO6Wkpj iOMX38LqqctAqjFeaC9sRvjPaGBbG/coEwaFal+Mgl2uKOrsHD8dGRnxvNYnTzcrrqLu Rj1g== X-Gm-Message-State: ALyK8tLcadRF3UnMiU2mhKnGb1io7S4nX8VrwgFJWu6Mmv75J+drESZNegg5eSDnbShI6RUxPmyhiFynszgnxY1q X-Received: by 10.36.227.67 with SMTP id d64mr407206ith.18.1466460130016; Mon, 20 Jun 2016 15:02:10 -0700 (PDT) MIME-Version: 1.0 References: <1463470661.2914.4.camel@redhat.com> <1463647224.3558.14.camel@redhat.com> <1553247361.41476124.1465542998520.JavaMail.zimbra@redhat.com> <015201d1caa9$ce55ac60$6b010520$@augustcellars.com> In-Reply-To: <015201d1caa9$ce55ac60$6b010520$@augustcellars.com> From: David Benjamin Date: Mon, 20 Jun 2016 22:02:00 +0000 Message-ID: To: Jim Schaad , Daniel Migault Content-Type: multipart/alternative; boundary=94eb2c111ada20cad00535bcdbd1 Archived-At: Cc: curdle@ietf.org Subject: Re: [Curdle] draft-ietf-curdle-pkix-00: a simplification proposal X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2016 22:02:13 -0000 --94eb2c111ada20cad00535bcdbd1 Content-Type: text/plain; charset=UTF-8 On Mon, Jun 20, 2016 at 12:11 AM Jim Schaad wrote: > The one downside that this approach has is that it makes negotiation either > much easier or a lot harder depending on what you are trying to negotiate. > > It makes it easier to agree on a curve, as the curve is part of the system > and now does not need to be negotiated separately. On the other hand, one > cannot say that one is willing to take any curve that is supported for > either ECDH, EdDSA or EdDSAph depending on what type of algorithm is > desired. > When were you thinking one would wish to do that? My claim is this is not a thing that makes sense to advertise. What does it mean to advertise EdDSA in your algorithms list and P-256 (because you're willing to do P-256 + ECDH) and Curve25519 in your curves list? EdDSA for P-256 isn't defined. EdDSA also isn't parameterized on curve alone. It has a hash function we pair with it. That second choice being implicit is odd. (And problematic if, say, someone defines Ed25519-SHA3 := EdDSA(curve25519, SHA3-512) or so.) This is the same problem TLS 1.3 had. TLS 1.2 negotiated curves and algorithms separately, and we switched it to a scheme much closer to the proposal. The old curve list is used for key exchange alone, and the signature algorithms list recast to specify only unparameterized algorithms like rsa_pss_sha256, ecdsa_p256_sha256, and ed25519. Forcing X25519, Ed25519, and Ed25519ph into the same "curve" also means SPKIs don't say which algorithm they're for. If you're thinking id-ecPublicKey, we'd use the key usage. But X25519 and Ed25519's public key formats aren't even compatible. Ed25519's curve is equivalent to X25519's, but it's not the same. Ed25519 and Ed25519ph are more comparable, but key reuse between the two breaks the algorithms. (A signature for M in Ed25519ph will forge a signature for SHA-512(M) in Ed25519 if keys are mixed.) They also do not have the same type signature. Ed25519 is a single-shot function while Ed25519ph is an Init/Update/Final triple. This is going to be complicated for ECDH given that one is going to > potentially need to negotiate the new curves and the old curves at the same > time in different methods. > I could imagine we do id-ecPublicKey with separate x25519/ed25519/ed25519ph namedCurve values which would avoid this concern, but it's nothing like id-ecPublicKey. The three named "curves" are nothing like existing curves. Existing curves are usable with ECDH or ECDSA with any hash. They come with the X9.62 serialization and multiple point format business. They decide on algorithm via key usage extension. These new ones are straight-forward functions on byte strings that do just one algorithm, as the rest of things should have been designed. Yes, it is a break from the old world, but I think one that is warranted. I would rather we make the clean break and avoid these historical mistakes now rather than perpetuate them further. One already must account for future algorithms that don't have "elliptic curve" in the name anyway. > I am not really in favor of using top level OIDs for all of the different > combinations of keys and algorithms. > > Jim > > > -----Original Message----- > > From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Nikos > > Mavrogiannopoulos > > Sent: Friday, June 10, 2016 12:17 AM > > To: Daniel Migault > > Cc: curdle@ietf.org > > Subject: Re: [Curdle] draft-ietf-curdle-pkix-00: a simplification > proposal > > > > I support this. > > > > ----- Original Message ----- > > Hi, > > > > Do we have some consensus that having top-level OID would be better ? > > Please provide your opinion and let the WG know your thoughts so the > > document can be moved forward. > > > > BR, > > Daniel > > > > On Thu, May 19, 2016 at 10:41 AM, David Benjamin > > wrote: > > > > > On Thu, May 19, 2016 at 4:40 AM Nikos Mavrogiannopoulos > > > > > > wrote: > > > > > >> On Tue, 2016-05-17 at 14:20 +0000, David Benjamin wrote: > > >> > I would actually advocate a different change. I sent this message > > >> > earlier: > > >> > https://www.ietf.org/mail-archive/web/curdle/current/msg00203.html > > >> > > > >> > Rather than use parameters, allocate new algorithm OIDs for > > >> > everything. I don't think we actually gain anything by exposing the > > >> > relations and parameterizations between these algorithms. When > > >> > implementing, they are great for sharing code. But when consuming, > > >> > exposing it makes parsing more complex, and it increases the risk > > >> > of reusing keys between related algorithms. We can get the best of > > >> > both worlds by separating entry-points and sharing internals. > > >> > > >> On your referenced message I am confused on the issue you raise on > > >> section 3. As I read section 3, I do not see anything that allows > > >> having id-ecPublicKey as an algorithm identifier for these keys. > > >> > > > > > > It's certainly possible I'm misunderstanding what section 3 was for. I > > > was kind of confused why there were two encodings. I was getting > > > id-ecPublicKey > > > from: > > > > > > """ > > > Section 2.3.5 of [RFC3279] > > > describe ECDSA/ECDH public keys, specifying the id-ecPublicKey OID. > > > This OID has the associated EcpkParameters parameters structure, > > > which contains the namedCurve CHOICE. Here we introduce two [I > > > think this should be four] new OIDs > > > for use in the namedCurve field. > > > """ > > > > > > Anyway, if we go with top-level OIDs for everything, this is all moot. > > > > > > David > > > > > > > > >> Other than this part, you raise a very good point. It may be much > > >> simpler to use a common OID and move it up. Unlike the NIST curves > > >> the constructions we have under the eddsa OID umbrella are quite > distinct. > > >> > > >> I was concerned about future extensibility and the fact that > > >> pureEdDSA and PrehashedEdDSA could be with separate algorithm OIDs, > > >> but after thinking it further, I think what you suggest is much > > >> neater, as having a single OID to identify scheme+curve will also > > >> restrict private keys to a single purpose which is a good thing. > > >> > > >> +1 > > >> > > >> regards, > > >> Nikos > > >> > > >> > > > _______________________________________________ > > > Curdle mailing list > > > Curdle@ietf.org > > > https://www.ietf.org/mailman/listinfo/curdle > > > > > > > > > > _______________________________________________ > > Curdle mailing list > > Curdle@ietf.org > > https://www.ietf.org/mailman/listinfo/curdle > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > --94eb2c111ada20cad00535bcdbd1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Jun 20= , 2016 at 12:11 AM Jim Schaad <ietf@augustcellars.com> wrote:
The one downside that this approach has is that it ma= kes negotiation either
much easier or a lot harder depending on what you are trying to negotiate.<= br>
It makes it easier to agree on a curve, as the curve is part of the system<= br> and now does not need to be negotiated separately.=C2=A0 On the other hand,= one
cannot say that one is willing to take any curve that is supported for
either ECDH, EdDSA or EdDSAph depending on what type of algorithm is
desired.

When were you thinking one wou= ld wish to do that? My claim is this is not a thing that makes sense to adv= ertise.

What does it mean to advertise EdDSA in your algorithms list and P-= 256 (because you're willing to do P-256 + ECDH)=C2=A0and Curve25519 in = your curves list?=C2=A0EdDSA for P-256 isn&= #39;t defined. EdDSA also isn't parameterized on curve alone. It has a = hash function we pair with it. That second choice being implicit is odd. (A= nd problematic if, say, someone defines Ed25519-SHA3 :=3D EdDSA(curve25519,= SHA3-512) or so.)

This is the same problem TLS= 1.3 had. TLS 1.2 negotiated curves and algorithms separately, and we switc= hed it to a scheme much closer to the proposal. The old curve list is used = for key exchange alone, and the signature algorithms list recast to specify= only unparameterized algorithms like rsa_pss_sha256, ecdsa_p256_sha256, an= d ed25519.

Forcing X25519, Ed25519, and Ed25519ph into the same "curve&quo= t; also means SPKIs don't say which algorithm they're for. If you&#= 39;re thinking id-ecPublicKey, we'd use the key usage. But X25519 and E= d25519's public key formats aren't even compatible. Ed25519's c= urve is equivalent to X25519's, but it's not the same.
Ed25519 and Ed25519ph are more comparable, but key reuse betwe= en the two breaks the algorithms. (A signature for M in Ed25519ph will forg= e a signature for SHA-512(M) in Ed25519 if keys are mixed.) They also do no= t have the same type signature. Ed25519 is a single-shot function while Ed2= 5519ph is an Init/Update/Final triple.

=C2=A0This is going to be complicated for ECDH = given that one is going to
potentially need to negotiate the new curves and the old curves at the same=
time in different methods.

I could imag= ine we do id-ecPublicKey with separate x25519/ed25519/ed25519ph namedCurve = values which would avoid this concern, but it's nothing like id-ecPubli= cKey. The three named "curves" are nothing like existing curves. = Existing curves are usable with ECDH or ECDSA with any hash. They come with= the X9.62 serialization and multiple point format business. They decide on= algorithm via key usage extension. These new ones are straight-forward fun= ctions on byte strings that do just one algorithm, as the rest of things sh= ould have been designed.

Yes, it is a break fr= om the old world, but I think one that is warranted. I would rather we make= the clean break and avoid these historical mistakes now rather than perpet= uate them further. One already must account for future algorithms that don&= #39;t have "elliptic curve" in the name anyway.
=
=C2=A0
curdle-bounces@ietf.org] On Behalf Of Nikos
> Mavrogiannopoulos
> Sent: Friday, June 10, 2016 12:17 AM
> To: Daniel Migault <daniel.migault@ericsson.com>
> Cc: curdle@ietf.o= rg
> Subject: Re: [Curdle] draft-ietf-curdle-pkix-00: a simplification prop= osal
>
> I support this.
>
> ----- Original Message -----
> Hi,
>
> Do we have some consensus that having top-level OID would be better ?<= br> > Please provide your opinion and let the WG know your thoughts so the > document can be moved forward.
>
> BR,
> Daniel
>
> On Thu, May 19, 2016 at 10:41 AM, David Benjamin <davidben@chromium.org>
> wrote:
>
> > On Thu, May 19, 2016 at 4:40 AM Nikos Mavrogiannopoulos
> > <nmav@red= hat.com>
> > wrote:
> >
> >> On Tue, 2016-05-17 at 14:20 +0000, David Benjamin wrote:
> >> > I would actually advocate a different change. I sent thi= s message
> >> > earlier:
> >> > https://www.iet= f.org/mail-archive/web/curdle/current/msg00203.html
> >> >
> >> > Rather than use parameters, allocate new algorithm OIDs = for
> >> > everything. I don't think we actually gain anything = by exposing the
> >> > relations and parameterizations between these algorithms= . When
> >> > implementing, they are great for sharing code. But when = consuming,
> >> > exposing it makes parsing more complex, and it increases= the risk
> >> > of reusing keys between related algorithms. We can get t= he best of
> >> > both worlds by separating entry-points and sharing inter= nals.
> >>
> >> On your referenced message I am confused on the issue you rai= se on
> >> section 3. As I read section 3, I do not see anything that al= lows
> >> having id-ecPublicKey as an algorithm identifier for these ke= ys.
> >>
> >
> > It's certainly possible I'm misunderstanding what section= 3 was for. I
> > was kind of confused why there were two encodings. I was getting<= br> > > id-ecPublicKey
> > from:
> >
> > """
> >=C2=A0 =C2=A0 Section 2.3.5 of [RFC3279]
> >=C2=A0 =C2=A0 describe ECDSA/ECDH public keys, specifying the id-e= cPublicKey OID.
> >=C2=A0 =C2=A0 This OID has the associated EcpkParameters parameter= s structure,
> >=C2=A0 =C2=A0 which contains the namedCurve CHOICE.=C2=A0 Here we = introduce two [I
> > think this should be four] new OIDs
> >=C2=A0 =C2=A0 for use in the namedCurve field.
> > """
> >
> > Anyway, if we go with top-level OIDs for everything, this is all = moot.
> >
> > David
> >
> >
> >> Other than this part, you raise a very good point. It may be = much
> >> simpler to use a common OID and move it up. Unlike the NIST c= urves
> >> the constructions we have under the eddsa OID umbrella are qu= ite
distinct.
> >>
> >> I was concerned about future extensibility and the fact that<= br> > >> pureEdDSA and PrehashedEdDSA could be with separate algorithm= OIDs,
> >> but after thinking it further, I think what you suggest is mu= ch
> >> neater, as having a single OID to identify scheme+curve will = also
> >> restrict private keys to a single purpose which is a good thi= ng.
> >>
> >> +1
> >>
> >> regards,
> >> Nikos
> >>
> >>
> > _______________________________________________
> > Curdle mailing list
> > Curdle@ietf.= org
> > https://www.ietf.org/mailman/listinfo/curdle
> >
> >
>
> _______________________________________________
> Curdle mailing list
> Curdle@ietf.org
> https://www.ietf.org/mailman/listinfo/curdle
_______________________________________________
Curdle mailing list
Curdle@ietf.org https://www.ietf.org/mailman/listinfo/curdle
--94eb2c111ada20cad00535bcdbd1-- From nobody Thu Jun 23 10:21:18 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D89012D52B for ; Thu, 23 Jun 2016 10:21:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8vB9OfwBsLOL for ; Thu, 23 Jun 2016 10:21:13 -0700 (PDT) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC29712D529 for ; Thu, 23 Jun 2016 10:21:12 -0700 (PDT) X-AuditID: c6180641-f796f6d000000e1e-d6-576c1a4ab3b7 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id 1F.35.03614.A4A1C675; Thu, 23 Jun 2016 19:20:10 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0294.000; Thu, 23 Jun 2016 13:21:10 -0400 From: Daniel Migault To: David Benjamin , Jim Schaad Thread-Topic: [Curdle] draft-ietf-curdle-pkix-00: a simplification proposal Thread-Index: AQHRsA8Giv0lxkrmV0e65YHooWWEuJ+9cX2AgALFngCAAGTiAIAeRaEAgAPRYACAD4ONAIABKyIAgAQkbvA= Date: Thu, 23 Jun 2016 17:21:08 +0000 Message-ID: <2DD56D786E600F45AC6BDE7DA4E8A8C117F26424@eusaamb107.ericsson.se> References: <1463470661.2914.4.camel@redhat.com> <1463647224.3558.14.camel@redhat.com> <1553247361.41476124.1465542998520.JavaMail.zimbra@redhat.com> <015201d1caa9$ce55ac60$6b010520$@augustcellars.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: multipart/alternative; boundary="_000_2DD56D786E600F45AC6BDE7DA4E8A8C117F26424eusaamb107erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprHIsWRmVeSWpSXmKPExsUyuXRPuK6XVE64QcdEPYutC2cxW+z+amqx evp3Ngdmj41zprN5zG64yOKxZMlPpgDmKC6blNSczLLUIn27BK6MQzs+sRbceMxY8aL/L1MD 4427jF2MnBwSAiYS16dtZYOwxSQu3FsPZHNxCAkcZZTofPiOBcJZziix4MVrFpAqNgEjibZD /ewgtohAoMSPzV/AbGYBdYlvPR3MILawgJfEn/7lUDXeEidPLWCDsJMk9lyYC7aZRUBVYlXD CjCbV8BXon33GrAaIYHXzBL/TmqA2JxA85+2rGQFsRmBrvt+ag0TxC5xiVtP5jNBXC0gsWTP eWYIW1Ti5eN/rBC2ksSkpedYIerzJWYunckEsUtQ4uTMJywTGEVnIRk1C0nZLCRlsxg5gOKa Eut36UOUKEpM6X7IDmFrSLTOmcuOLL6AkX0VI0dpcUFObrqR4SZGYKwdk2Bz3MG4t9fzEKMA B6MSD6/CpaxwIdbEsuLK3EOMEhzMSiK8ZyRywoV4UxIrq1KL8uOLSnNSiw8xSnOwKInz6r9U DBcSSE8sSc1OTS1ILYLJMnFwSjUw+qsFm23lbH77etqm+Nkv5C2NO4I/xzi23FDN++o4mU31 1ORVK5oDpR2y7/K/iZ8VniLxbI9otvUmU/6u/axxXa/uX/hU93fedIvdV7VfPW5qFa0P4EqL 9vsn9vaLRpj9u8s5K4z4YvfpyIm9T5Gcm6j4j08m5ltecLZvthTbLdmX+55u7LiixFKckWio xVxUnAgAKRjr1bECAAA= Archived-At: Cc: "curdle@ietf.org" Subject: Re: [Curdle] draft-ietf-curdle-pkix-00: a simplification proposal X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2016 17:21:16 -0000 --_000_2DD56D786E600F45AC6BDE7DA4E8A8C117F26424eusaamb107erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpXZSBjdXJyZW50bHkgZG8gbm90IGhhdmUgY29uc2Vuc3VzIHdoZXRoZXIgd2Ug c2hvdWxkIGJlIHVzaW5nIHRvcCBsZXZlbCBPSUQgb3Igbm90LiBUaGlzIGlzIGFuIGltcG9ydGFu dCBpc3N1ZSwgYW5kIHdlIHdvdWxkIGxpa2UgdG8gZmluZCBhIGNvbnNlbnN1cyBhcyBzb29uIGFz IHBvc3NpYmxlLCBzbyBwbGVhc2UgcHJvdmlkZSB5b3VyIG9waW5pb24gYnkgbmV4dCB3ZWVrLg0K DQpCUiwNCkRhbmllbA0KDQpGcm9tOiBEYXZpZCBCZW5qYW1pbiBbbWFpbHRvOmRhdmlkYmVuQGNo cm9taXVtLm9yZ10NClNlbnQ6IE1vbmRheSwgSnVuZSAyMCwgMjAxNiA2OjAyIFBNDQpUbzogSmlt IFNjaGFhZDsgRGFuaWVsIE1pZ2F1bHQNCkNjOiBjdXJkbGVAaWV0Zi5vcmcNClN1YmplY3Q6IFJl OiBbQ3VyZGxlXSBkcmFmdC1pZXRmLWN1cmRsZS1wa2l4LTAwOiBhIHNpbXBsaWZpY2F0aW9uIHBy b3Bvc2FsDQoNCk9uIE1vbiwgSnVuIDIwLCAyMDE2IGF0IDEyOjExIEFNIEppbSBTY2hhYWQgPGll dGZAYXVndXN0Y2VsbGFycy5jb208bWFpbHRvOmlldGZAYXVndXN0Y2VsbGFycy5jb20+PiB3cm90 ZToNClRoZSBvbmUgZG93bnNpZGUgdGhhdCB0aGlzIGFwcHJvYWNoIGhhcyBpcyB0aGF0IGl0IG1h a2VzIG5lZ290aWF0aW9uIGVpdGhlcg0KbXVjaCBlYXNpZXIgb3IgYSBsb3QgaGFyZGVyIGRlcGVu ZGluZyBvbiB3aGF0IHlvdSBhcmUgdHJ5aW5nIHRvIG5lZ290aWF0ZS4NCg0KSXQgbWFrZXMgaXQg ZWFzaWVyIHRvIGFncmVlIG9uIGEgY3VydmUsIGFzIHRoZSBjdXJ2ZSBpcyBwYXJ0IG9mIHRoZSBz eXN0ZW0NCmFuZCBub3cgZG9lcyBub3QgbmVlZCB0byBiZSBuZWdvdGlhdGVkIHNlcGFyYXRlbHku ICBPbiB0aGUgb3RoZXIgaGFuZCwgb25lDQpjYW5ub3Qgc2F5IHRoYXQgb25lIGlzIHdpbGxpbmcg dG8gdGFrZSBhbnkgY3VydmUgdGhhdCBpcyBzdXBwb3J0ZWQgZm9yDQplaXRoZXIgRUNESCwgRWRE U0Egb3IgRWREU0FwaCBkZXBlbmRpbmcgb24gd2hhdCB0eXBlIG9mIGFsZ29yaXRobSBpcw0KZGVz aXJlZC4NCg0KV2hlbiB3ZXJlIHlvdSB0aGlua2luZyBvbmUgd291bGQgd2lzaCB0byBkbyB0aGF0 PyBNeSBjbGFpbSBpcyB0aGlzIGlzIG5vdCBhIHRoaW5nIHRoYXQgbWFrZXMgc2Vuc2UgdG8gYWR2 ZXJ0aXNlLg0KDQpXaGF0IGRvZXMgaXQgbWVhbiB0byBhZHZlcnRpc2UgRWREU0EgaW4geW91ciBh bGdvcml0aG1zIGxpc3QgYW5kIFAtMjU2IChiZWNhdXNlIHlvdSdyZSB3aWxsaW5nIHRvIGRvIFAt MjU2ICsgRUNESCkgYW5kIEN1cnZlMjU1MTkgaW4geW91ciBjdXJ2ZXMgbGlzdD8gRWREU0EgZm9y IFAtMjU2IGlzbid0IGRlZmluZWQuIEVkRFNBIGFsc28gaXNuJ3QgcGFyYW1ldGVyaXplZCBvbiBj dXJ2ZSBhbG9uZS4gSXQgaGFzIGEgaGFzaCBmdW5jdGlvbiB3ZSBwYWlyIHdpdGggaXQuIFRoYXQg c2Vjb25kIGNob2ljZSBiZWluZyBpbXBsaWNpdCBpcyBvZGQuIChBbmQgcHJvYmxlbWF0aWMgaWYs IHNheSwgc29tZW9uZSBkZWZpbmVzIEVkMjU1MTktU0hBMyA6PSBFZERTQShjdXJ2ZTI1NTE5LCBT SEEzLTUxMikgb3Igc28uKQ0KDQpUaGlzIGlzIHRoZSBzYW1lIHByb2JsZW0gVExTIDEuMyBoYWQu IFRMUyAxLjIgbmVnb3RpYXRlZCBjdXJ2ZXMgYW5kIGFsZ29yaXRobXMgc2VwYXJhdGVseSwgYW5k IHdlIHN3aXRjaGVkIGl0IHRvIGEgc2NoZW1lIG11Y2ggY2xvc2VyIHRvIHRoZSBwcm9wb3NhbC4g VGhlIG9sZCBjdXJ2ZSBsaXN0IGlzIHVzZWQgZm9yIGtleSBleGNoYW5nZSBhbG9uZSwgYW5kIHRo ZSBzaWduYXR1cmUgYWxnb3JpdGhtcyBsaXN0IHJlY2FzdCB0byBzcGVjaWZ5IG9ubHkgdW5wYXJh bWV0ZXJpemVkIGFsZ29yaXRobXMgbGlrZSByc2FfcHNzX3NoYTI1NiwgZWNkc2FfcDI1Nl9zaGEy NTYsIGFuZCBlZDI1NTE5Lg0KDQpGb3JjaW5nIFgyNTUxOSwgRWQyNTUxOSwgYW5kIEVkMjU1MTlw aCBpbnRvIHRoZSBzYW1lICJjdXJ2ZSIgYWxzbyBtZWFucyBTUEtJcyBkb24ndCBzYXkgd2hpY2gg YWxnb3JpdGhtIHRoZXkncmUgZm9yLiBJZiB5b3UncmUgdGhpbmtpbmcgaWQtZWNQdWJsaWNLZXks IHdlJ2QgdXNlIHRoZSBrZXkgdXNhZ2UuIEJ1dCBYMjU1MTkgYW5kIEVkMjU1MTkncyBwdWJsaWMg a2V5IGZvcm1hdHMgYXJlbid0IGV2ZW4gY29tcGF0aWJsZS4gRWQyNTUxOSdzIGN1cnZlIGlzIGVx dWl2YWxlbnQgdG8gWDI1NTE5J3MsIGJ1dCBpdCdzIG5vdCB0aGUgc2FtZS4NCg0KRWQyNTUxOSBh bmQgRWQyNTUxOXBoIGFyZSBtb3JlIGNvbXBhcmFibGUsIGJ1dCBrZXkgcmV1c2UgYmV0d2VlbiB0 aGUgdHdvIGJyZWFrcyB0aGUgYWxnb3JpdGhtcy4gKEEgc2lnbmF0dXJlIGZvciBNIGluIEVkMjU1 MTlwaCB3aWxsIGZvcmdlIGEgc2lnbmF0dXJlIGZvciBTSEEtNTEyKE0pIGluIEVkMjU1MTkgaWYg a2V5cyBhcmUgbWl4ZWQuKSBUaGV5IGFsc28gZG8gbm90IGhhdmUgdGhlIHNhbWUgdHlwZSBzaWdu YXR1cmUuIEVkMjU1MTkgaXMgYSBzaW5nbGUtc2hvdCBmdW5jdGlvbiB3aGlsZSBFZDI1NTE5cGgg aXMgYW4gSW5pdC9VcGRhdGUvRmluYWwgdHJpcGxlLg0KDQogVGhpcyBpcyBnb2luZyB0byBiZSBj b21wbGljYXRlZCBmb3IgRUNESCBnaXZlbiB0aGF0IG9uZSBpcyBnb2luZyB0bw0KcG90ZW50aWFs bHkgbmVlZCB0byBuZWdvdGlhdGUgdGhlIG5ldyBjdXJ2ZXMgYW5kIHRoZSBvbGQgY3VydmVzIGF0 IHRoZSBzYW1lDQp0aW1lIGluIGRpZmZlcmVudCBtZXRob2RzLg0KDQpJIGNvdWxkIGltYWdpbmUg d2UgZG8gaWQtZWNQdWJsaWNLZXkgd2l0aCBzZXBhcmF0ZSB4MjU1MTkvZWQyNTUxOS9lZDI1NTE5 cGggbmFtZWRDdXJ2ZSB2YWx1ZXMgd2hpY2ggd291bGQgYXZvaWQgdGhpcyBjb25jZXJuLCBidXQg aXQncyBub3RoaW5nIGxpa2UgaWQtZWNQdWJsaWNLZXkuIFRoZSB0aHJlZSBuYW1lZCAiY3VydmVz IiBhcmUgbm90aGluZyBsaWtlIGV4aXN0aW5nIGN1cnZlcy4gRXhpc3RpbmcgY3VydmVzIGFyZSB1 c2FibGUgd2l0aCBFQ0RIIG9yIEVDRFNBIHdpdGggYW55IGhhc2guIFRoZXkgY29tZSB3aXRoIHRo ZSBYOS42MiBzZXJpYWxpemF0aW9uIGFuZCBtdWx0aXBsZSBwb2ludCBmb3JtYXQgYnVzaW5lc3Mu IFRoZXkgZGVjaWRlIG9uIGFsZ29yaXRobSB2aWEga2V5IHVzYWdlIGV4dGVuc2lvbi4gVGhlc2Ug bmV3IG9uZXMgYXJlIHN0cmFpZ2h0LWZvcndhcmQgZnVuY3Rpb25zIG9uIGJ5dGUgc3RyaW5ncyB0 aGF0IGRvIGp1c3Qgb25lIGFsZ29yaXRobSwgYXMgdGhlIHJlc3Qgb2YgdGhpbmdzIHNob3VsZCBo YXZlIGJlZW4gZGVzaWduZWQuDQoNClllcywgaXQgaXMgYSBicmVhayBmcm9tIHRoZSBvbGQgd29y bGQsIGJ1dCBJIHRoaW5rIG9uZSB0aGF0IGlzIHdhcnJhbnRlZC4gSSB3b3VsZCByYXRoZXIgd2Ug bWFrZSB0aGUgY2xlYW4gYnJlYWsgYW5kIGF2b2lkIHRoZXNlIGhpc3RvcmljYWwgbWlzdGFrZXMg bm93IHJhdGhlciB0aGFuIHBlcnBldHVhdGUgdGhlbSBmdXJ0aGVyLiBPbmUgYWxyZWFkeSBtdXN0 IGFjY291bnQgZm9yIGZ1dHVyZSBhbGdvcml0aG1zIHRoYXQgZG9uJ3QgaGF2ZSAiZWxsaXB0aWMg Y3VydmUiIGluIHRoZSBuYW1lIGFueXdheS4NCg0KSSBhbSBub3QgcmVhbGx5IGluIGZhdm9yIG9m IHVzaW5nIHRvcCBsZXZlbCBPSURzIGZvciBhbGwgb2YgdGhlIGRpZmZlcmVudA0KY29tYmluYXRp b25zIG9mIGtleXMgYW5kIGFsZ29yaXRobXMuDQoNCkppbQ0KDQo+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+IEZyb206IEN1cmRsZSBbbWFpbHRvOmN1cmRsZS1ib3VuY2VzQGlldGYub3Jn PG1haWx0bzpjdXJkbGUtYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBOaWtvcw0KPiBN YXZyb2dpYW5ub3BvdWxvcw0KPiBTZW50OiBGcmlkYXksIEp1bmUgMTAsIDIwMTYgMTI6MTcgQU0N Cj4gVG86IERhbmllbCBNaWdhdWx0IDxkYW5pZWwubWlnYXVsdEBlcmljc3Nvbi5jb208bWFpbHRv OmRhbmllbC5taWdhdWx0QGVyaWNzc29uLmNvbT4+DQo+IENjOiBjdXJkbGVAaWV0Zi5vcmc8bWFp bHRvOmN1cmRsZUBpZXRmLm9yZz4NCj4gU3ViamVjdDogUmU6IFtDdXJkbGVdIGRyYWZ0LWlldGYt Y3VyZGxlLXBraXgtMDA6IGEgc2ltcGxpZmljYXRpb24gcHJvcG9zYWwNCj4NCj4gSSBzdXBwb3J0 IHRoaXMuDQo+DQo+IC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCj4gSGksDQo+DQo+IERv IHdlIGhhdmUgc29tZSBjb25zZW5zdXMgdGhhdCBoYXZpbmcgdG9wLWxldmVsIE9JRCB3b3VsZCBi ZSBiZXR0ZXIgPw0KPiBQbGVhc2UgcHJvdmlkZSB5b3VyIG9waW5pb24gYW5kIGxldCB0aGUgV0cg a25vdyB5b3VyIHRob3VnaHRzIHNvIHRoZQ0KPiBkb2N1bWVudCBjYW4gYmUgbW92ZWQgZm9yd2Fy ZC4NCj4NCj4gQlIsDQo+IERhbmllbA0KPg0KPiBPbiBUaHUsIE1heSAxOSwgMjAxNiBhdCAxMDo0 MSBBTSwgRGF2aWQgQmVuamFtaW4gPGRhdmlkYmVuQGNocm9taXVtLm9yZzxtYWlsdG86ZGF2aWRi ZW5AY2hyb21pdW0ub3JnPj4NCj4gd3JvdGU6DQo+DQo+ID4gT24gVGh1LCBNYXkgMTksIDIwMTYg YXQgNDo0MCBBTSBOaWtvcyBNYXZyb2dpYW5ub3BvdWxvcw0KPiA+IDxubWF2QHJlZGhhdC5jb208 bWFpbHRvOm5tYXZAcmVkaGF0LmNvbT4+DQo+ID4gd3JvdGU6DQo+ID4NCj4gPj4gT24gVHVlLCAy MDE2LTA1LTE3IGF0IDE0OjIwICswMDAwLCBEYXZpZCBCZW5qYW1pbiB3cm90ZToNCj4gPj4gPiBJ IHdvdWxkIGFjdHVhbGx5IGFkdm9jYXRlIGEgZGlmZmVyZW50IGNoYW5nZS4gSSBzZW50IHRoaXMg bWVzc2FnZQ0KPiA+PiA+IGVhcmxpZXI6DQo+ID4+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bC1hcmNoaXZlL3dlYi9jdXJkbGUvY3VycmVudC9tc2cwMDIwMy5odG1sDQo+ID4+ID4NCj4gPj4g PiBSYXRoZXIgdGhhbiB1c2UgcGFyYW1ldGVycywgYWxsb2NhdGUgbmV3IGFsZ29yaXRobSBPSURz IGZvcg0KPiA+PiA+IGV2ZXJ5dGhpbmcuIEkgZG9uJ3QgdGhpbmsgd2UgYWN0dWFsbHkgZ2FpbiBh bnl0aGluZyBieSBleHBvc2luZyB0aGUNCj4gPj4gPiByZWxhdGlvbnMgYW5kIHBhcmFtZXRlcml6 YXRpb25zIGJldHdlZW4gdGhlc2UgYWxnb3JpdGhtcy4gV2hlbg0KPiA+PiA+IGltcGxlbWVudGlu ZywgdGhleSBhcmUgZ3JlYXQgZm9yIHNoYXJpbmcgY29kZS4gQnV0IHdoZW4gY29uc3VtaW5nLA0K PiA+PiA+IGV4cG9zaW5nIGl0IG1ha2VzIHBhcnNpbmcgbW9yZSBjb21wbGV4LCBhbmQgaXQgaW5j cmVhc2VzIHRoZSByaXNrDQo+ID4+ID4gb2YgcmV1c2luZyBrZXlzIGJldHdlZW4gcmVsYXRlZCBh bGdvcml0aG1zLiBXZSBjYW4gZ2V0IHRoZSBiZXN0IG9mDQo+ID4+ID4gYm90aCB3b3JsZHMgYnkg c2VwYXJhdGluZyBlbnRyeS1wb2ludHMgYW5kIHNoYXJpbmcgaW50ZXJuYWxzLg0KPiA+Pg0KPiA+ PiBPbiB5b3VyIHJlZmVyZW5jZWQgbWVzc2FnZSBJIGFtIGNvbmZ1c2VkIG9uIHRoZSBpc3N1ZSB5 b3UgcmFpc2Ugb24NCj4gPj4gc2VjdGlvbiAzLiBBcyBJIHJlYWQgc2VjdGlvbiAzLCBJIGRvIG5v dCBzZWUgYW55dGhpbmcgdGhhdCBhbGxvd3MNCj4gPj4gaGF2aW5nIGlkLWVjUHVibGljS2V5IGFz IGFuIGFsZ29yaXRobSBpZGVudGlmaWVyIGZvciB0aGVzZSBrZXlzLg0KPiA+Pg0KPiA+DQo+ID4g SXQncyBjZXJ0YWlubHkgcG9zc2libGUgSSdtIG1pc3VuZGVyc3RhbmRpbmcgd2hhdCBzZWN0aW9u IDMgd2FzIGZvci4gSQ0KPiA+IHdhcyBraW5kIG9mIGNvbmZ1c2VkIHdoeSB0aGVyZSB3ZXJlIHR3 byBlbmNvZGluZ3MuIEkgd2FzIGdldHRpbmcNCj4gPiBpZC1lY1B1YmxpY0tleQ0KPiA+IGZyb206 DQo+ID4NCj4gPiAiIiINCj4gPiAgICBTZWN0aW9uIDIuMy41IG9mIFtSRkMzMjc5XQ0KPiA+ICAg IGRlc2NyaWJlIEVDRFNBL0VDREggcHVibGljIGtleXMsIHNwZWNpZnlpbmcgdGhlIGlkLWVjUHVi bGljS2V5IE9JRC4NCj4gPiAgICBUaGlzIE9JRCBoYXMgdGhlIGFzc29jaWF0ZWQgRWNwa1BhcmFt ZXRlcnMgcGFyYW1ldGVycyBzdHJ1Y3R1cmUsDQo+ID4gICAgd2hpY2ggY29udGFpbnMgdGhlIG5h bWVkQ3VydmUgQ0hPSUNFLiAgSGVyZSB3ZSBpbnRyb2R1Y2UgdHdvIFtJDQo+ID4gdGhpbmsgdGhp cyBzaG91bGQgYmUgZm91cl0gbmV3IE9JRHMNCj4gPiAgICBmb3IgdXNlIGluIHRoZSBuYW1lZEN1 cnZlIGZpZWxkLg0KPiA+ICIiIg0KPiA+DQo+ID4gQW55d2F5LCBpZiB3ZSBnbyB3aXRoIHRvcC1s ZXZlbCBPSURzIGZvciBldmVyeXRoaW5nLCB0aGlzIGlzIGFsbCBtb290Lg0KPiA+DQo+ID4gRGF2 aWQNCj4gPg0KPiA+DQo+ID4+IE90aGVyIHRoYW4gdGhpcyBwYXJ0LCB5b3UgcmFpc2UgYSB2ZXJ5 IGdvb2QgcG9pbnQuIEl0IG1heSBiZSBtdWNoDQo+ID4+IHNpbXBsZXIgdG8gdXNlIGEgY29tbW9u IE9JRCBhbmQgbW92ZSBpdCB1cC4gVW5saWtlIHRoZSBOSVNUIGN1cnZlcw0KPiA+PiB0aGUgY29u c3RydWN0aW9ucyB3ZSBoYXZlIHVuZGVyIHRoZSBlZGRzYSBPSUQgdW1icmVsbGEgYXJlIHF1aXRl DQpkaXN0aW5jdC4NCj4gPj4NCj4gPj4gSSB3YXMgY29uY2VybmVkIGFib3V0IGZ1dHVyZSBleHRl bnNpYmlsaXR5IGFuZCB0aGUgZmFjdCB0aGF0DQo+ID4+IHB1cmVFZERTQSBhbmQgUHJlaGFzaGVk RWREU0EgY291bGQgYmUgd2l0aCBzZXBhcmF0ZSBhbGdvcml0aG0gT0lEcywNCj4gPj4gYnV0IGFm dGVyIHRoaW5raW5nIGl0IGZ1cnRoZXIsIEkgdGhpbmsgd2hhdCB5b3Ugc3VnZ2VzdCBpcyBtdWNo DQo+ID4+IG5lYXRlciwgYXMgaGF2aW5nIGEgc2luZ2xlIE9JRCB0byBpZGVudGlmeSBzY2hlbWUr Y3VydmUgd2lsbCBhbHNvDQo+ID4+IHJlc3RyaWN0IHByaXZhdGUga2V5cyB0byBhIHNpbmdsZSBw dXJwb3NlIHdoaWNoIGlzIGEgZ29vZCB0aGluZy4NCj4gPj4NCj4gPj4gKzENCj4gPj4NCj4gPj4g cmVnYXJkcywNCj4gPj4gTmlrb3MNCj4gPj4NCj4gPj4NCj4gPiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IEN1cmRsZSBtYWlsaW5nIGxpc3QNCj4g PiBDdXJkbGVAaWV0Zi5vcmc8bWFpbHRvOkN1cmRsZUBpZXRmLm9yZz4NCj4gPiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2N1cmRsZQ0KPiA+DQo+ID4NCj4NCj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gQ3VyZGxlIG1haWxp bmcgbGlzdA0KPiBDdXJkbGVAaWV0Zi5vcmc8bWFpbHRvOkN1cmRsZUBpZXRmLm9yZz4NCj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jdXJkbGUNCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkN1cmRsZSBtYWlsaW5nIGxpc3QN CkN1cmRsZUBpZXRmLm9yZzxtYWlsdG86Q3VyZGxlQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jdXJkbGUNCg== --_000_2DD56D786E600F45AC6BDE7DA4E8A8C117F26424eusaamb107erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkgYWxsLA0KPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5XZSBjdXJyZW50bHkgZG8gbm90IGhhdmUgY29uc2Vuc3VzIHdoZXRoZXIgd2Ugc2hvdWxk IGJlIHVzaW5nIHRvcCBsZXZlbCBPSUQgb3Igbm90LiBUaGlzIGlzIGFuIGltcG9ydGFudCBpc3N1 ZSwgYW5kIHdlIHdvdWxkIGxpa2UgdG8gZmluZCBhIGNvbnNlbnN1cyBhcyBzb29uDQogYXMgcG9z c2libGUsIHNvIHBsZWFzZSBwcm92aWRlIHlvdXIgb3BpbmlvbiBieSBuZXh0IHdlZWsuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5CUiwNCjxicj4NCkRhbmllbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij4gRGF2aWQgQmVuamFtaW4gW21haWx0bzpkYXZpZGJlbkBjaHJvbWl1bS5vcmddDQo8 YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBKdW5lIDIwLCAyMDE2IDY6MDIgUE08YnI+DQo8Yj5U bzo8L2I+IEppbSBTY2hhYWQ7IERhbmllbCBNaWdhdWx0PGJyPg0KPGI+Q2M6PC9iPiBjdXJkbGVA aWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtDdXJkbGVdIGRyYWZ0LWlldGYtY3Vy ZGxlLXBraXgtMDA6IGEgc2ltcGxpZmljYXRpb24gcHJvcG9zYWw8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE1vbiwgSnVuIDIwLCAyMDE2IGF0 IDEyOjExIEFNIEppbSBTY2hhYWQgJmx0OzxhIGhyZWY9Im1haWx0bzppZXRmQGF1Z3VzdGNlbGxh cnMuY29tIiB0YXJnZXQ9Il9ibGFuayI+aWV0ZkBhdWd1c3RjZWxsYXJzLmNvbTwvYT4mZ3Q7IHdy b3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYu MHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+VGhlIG9uZSBkb3duc2lkZSB0aGF0IHRoaXMgYXBwcm9hY2ggaGFzIGlzIHRoYXQgaXQg bWFrZXMgbmVnb3RpYXRpb24gZWl0aGVyPGJyPg0KbXVjaCBlYXNpZXIgb3IgYSBsb3QgaGFyZGVy IGRlcGVuZGluZyBvbiB3aGF0IHlvdSBhcmUgdHJ5aW5nIHRvIG5lZ290aWF0ZS48YnI+DQo8YnI+ DQpJdCBtYWtlcyBpdCBlYXNpZXIgdG8gYWdyZWUgb24gYSBjdXJ2ZSwgYXMgdGhlIGN1cnZlIGlz IHBhcnQgb2YgdGhlIHN5c3RlbTxicj4NCmFuZCBub3cgZG9lcyBub3QgbmVlZCB0byBiZSBuZWdv dGlhdGVkIHNlcGFyYXRlbHkuJm5ic3A7IE9uIHRoZSBvdGhlciBoYW5kLCBvbmU8YnI+DQpjYW5u b3Qgc2F5IHRoYXQgb25lIGlzIHdpbGxpbmcgdG8gdGFrZSBhbnkgY3VydmUgdGhhdCBpcyBzdXBw b3J0ZWQgZm9yPGJyPg0KZWl0aGVyIEVDREgsIEVkRFNBIG9yIEVkRFNBcGggZGVwZW5kaW5nIG9u IHdoYXQgdHlwZSBvZiBhbGdvcml0aG0gaXM8YnI+DQpkZXNpcmVkLjxvOnA+PC9vOnA+PC9wPg0K PC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2hlbiB3ZXJlIHlv dSB0aGlua2luZyBvbmUgd291bGQgd2lzaCB0byBkbyB0aGF0PyBNeSBjbGFpbSBpcyB0aGlzIGlz IG5vdCBhIHRoaW5nIHRoYXQgbWFrZXMgc2Vuc2UgdG8gYWR2ZXJ0aXNlLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+V2hhdCBkb2VzIGl0IG1lYW4gdG8gYWR2ZXJ0aXNlIEVkRFNBIGluIHlvdXIgYWxnb3Jp dGhtcyBsaXN0IGFuZCBQLTI1NiAoYmVjYXVzZSB5b3UncmUgd2lsbGluZyB0byBkbyBQLTI1NiAm IzQzOyBFQ0RIKSZuYnNwO2FuZCBDdXJ2ZTI1NTE5IGluIHlvdXIgY3VydmVzIGxpc3Q/Jm5ic3A7 RWREU0EgZm9yIFAtMjU2IGlzbid0IGRlZmluZWQuIEVkRFNBIGFsc28gaXNuJ3QgcGFyYW1ldGVy aXplZCBvbiBjdXJ2ZSBhbG9uZS4gSXQgaGFzDQogYSBoYXNoIGZ1bmN0aW9uIHdlIHBhaXIgd2l0 aCBpdC4gVGhhdCBzZWNvbmQgY2hvaWNlIGJlaW5nIGltcGxpY2l0IGlzIG9kZC4gKEFuZCBwcm9i bGVtYXRpYyBpZiwgc2F5LCBzb21lb25lIGRlZmluZXMgRWQyNTUxOS1TSEEzIDo9IEVkRFNBKGN1 cnZlMjU1MTksIFNIQTMtNTEyKSBvciBzby4pPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgaXMgdGhlIHNhbWUgcHJvYmxlbSBUTFMgMS4z IGhhZC4gVExTIDEuMiBuZWdvdGlhdGVkIGN1cnZlcyBhbmQgYWxnb3JpdGhtcyBzZXBhcmF0ZWx5 LCBhbmQgd2Ugc3dpdGNoZWQgaXQgdG8gYSBzY2hlbWUgbXVjaCBjbG9zZXIgdG8gdGhlIHByb3Bv c2FsLiBUaGUgb2xkIGN1cnZlIGxpc3QgaXMgdXNlZCBmb3Iga2V5IGV4Y2hhbmdlIGFsb25lLCBh bmQgdGhlIHNpZ25hdHVyZSBhbGdvcml0aG1zIGxpc3QNCiByZWNhc3QgdG8gc3BlY2lmeSBvbmx5 IHVucGFyYW1ldGVyaXplZCBhbGdvcml0aG1zIGxpa2UgcnNhX3Bzc19zaGEyNTYsIGVjZHNhX3Ay NTZfc2hhMjU2LCBhbmQgZWQyNTUxOS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Rm9yY2luZyBYMjU1MTksIEVkMjU1MTksIGFuZCBFZDI1NTE5 cGggaW50byB0aGUgc2FtZSAmcXVvdDtjdXJ2ZSZxdW90OyBhbHNvIG1lYW5zIFNQS0lzIGRvbid0 IHNheSB3aGljaCBhbGdvcml0aG0gdGhleSdyZSBmb3IuIElmIHlvdSdyZSB0aGlua2luZyBpZC1l Y1B1YmxpY0tleSwgd2UnZCB1c2UgdGhlIGtleSB1c2FnZS4gQnV0IFgyNTUxOSBhbmQgRWQyNTUx OSdzIHB1YmxpYyBrZXkgZm9ybWF0cyBhcmVuJ3QgZXZlbiBjb21wYXRpYmxlLg0KIEVkMjU1MTkn cyBjdXJ2ZSBpcyBlcXVpdmFsZW50IHRvIFgyNTUxOSdzLCBidXQgaXQncyBub3QgdGhlIHNhbWUu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkVk MjU1MTkgYW5kIEVkMjU1MTlwaCBhcmUgbW9yZSBjb21wYXJhYmxlLCBidXQga2V5IHJldXNlIGJl dHdlZW4gdGhlIHR3byBicmVha3MgdGhlIGFsZ29yaXRobXMuIChBIHNpZ25hdHVyZSBmb3IgTSBp biBFZDI1NTE5cGggd2lsbCBmb3JnZSBhIHNpZ25hdHVyZSBmb3IgU0hBLTUxMihNKSBpbiBFZDI1 NTE5IGlmIGtleXMgYXJlIG1peGVkLikgVGhleSBhbHNvIGRvIG5vdCBoYXZlIHRoZSBzYW1lIHR5 cGUgc2lnbmF0dXJlLg0KIEVkMjU1MTkgaXMgYSBzaW5nbGUtc2hvdCBmdW5jdGlvbiB3aGlsZSBF ZDI1NTE5cGggaXMgYW4gSW5pdC9VcGRhdGUvRmluYWwgdHJpcGxlLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDtUaGlzIGlzIGdvaW5n IHRvIGJlIGNvbXBsaWNhdGVkIGZvciBFQ0RIIGdpdmVuIHRoYXQgb25lIGlzIGdvaW5nIHRvPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0 O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0 OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5wb3RlbnRpYWxseSBuZWVkIHRvIG5lZ290aWF0 ZSB0aGUgbmV3IGN1cnZlcyBhbmQgdGhlIG9sZCBjdXJ2ZXMgYXQgdGhlIHNhbWU8YnI+DQp0aW1l IGluIGRpZmZlcmVudCBtZXRob2RzLjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBjb3VsZCBpbWFnaW5lIHdlIGRvIGlkLWVjUHVi bGljS2V5IHdpdGggc2VwYXJhdGUgeDI1NTE5L2VkMjU1MTkvZWQyNTUxOXBoIG5hbWVkQ3VydmUg dmFsdWVzIHdoaWNoIHdvdWxkIGF2b2lkIHRoaXMgY29uY2VybiwgYnV0IGl0J3Mgbm90aGluZyBs aWtlIGlkLWVjUHVibGljS2V5LiBUaGUgdGhyZWUgbmFtZWQgJnF1b3Q7Y3VydmVzJnF1b3Q7IGFy ZSBub3RoaW5nIGxpa2UgZXhpc3RpbmcgY3VydmVzLiBFeGlzdGluZyBjdXJ2ZXMNCiBhcmUgdXNh YmxlIHdpdGggRUNESCBvciBFQ0RTQSB3aXRoIGFueSBoYXNoLiBUaGV5IGNvbWUgd2l0aCB0aGUg WDkuNjIgc2VyaWFsaXphdGlvbiBhbmQgbXVsdGlwbGUgcG9pbnQgZm9ybWF0IGJ1c2luZXNzLiBU aGV5IGRlY2lkZSBvbiBhbGdvcml0aG0gdmlhIGtleSB1c2FnZSBleHRlbnNpb24uIFRoZXNlIG5l dyBvbmVzIGFyZSBzdHJhaWdodC1mb3J3YXJkIGZ1bmN0aW9ucyBvbiBieXRlIHN0cmluZ3MgdGhh dCBkbyBqdXN0IG9uZSBhbGdvcml0aG0sDQogYXMgdGhlIHJlc3Qgb2YgdGhpbmdzIHNob3VsZCBo YXZlIGJlZW4gZGVzaWduZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlllcywgaXQgaXMgYSBicmVhayBmcm9tIHRoZSBvbGQgd29ybGQsIGJ1 dCBJIHRoaW5rIG9uZSB0aGF0IGlzIHdhcnJhbnRlZC4gSSB3b3VsZCByYXRoZXIgd2UgbWFrZSB0 aGUgY2xlYW4gYnJlYWsgYW5kIGF2b2lkIHRoZXNlIGhpc3RvcmljYWwgbWlzdGFrZXMgbm93IHJh dGhlciB0aGFuIHBlcnBldHVhdGUgdGhlbSBmdXJ0aGVyLiBPbmUgYWxyZWFkeSBtdXN0IGFjY291 bnQgZm9yIGZ1dHVyZSBhbGdvcml0aG1zDQogdGhhdCBkb24ndCBoYXZlICZxdW90O2VsbGlwdGlj IGN1cnZlJnF1b3Q7IGluIHRoZSBuYW1lIGFueXdheS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0ND Q0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21h cmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBhbSBub3QgcmVhbGx5IGlu IGZhdm9yIG9mIHVzaW5nIHRvcCBsZXZlbCBPSURzIGZvciBhbGwgb2YgdGhlIGRpZmZlcmVudDxi cj4NCmNvbWJpbmF0aW9ucyBvZiBrZXlzIGFuZCBhbGdvcml0aG1zLjxicj4NCjxicj4NCkppbTxi cj4NCjxicj4NCiZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7IEZyb206 IEN1cmRsZSBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpjdXJkbGUtYm91bmNlc0BpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPmN1cmRsZS1ib3VuY2VzQGlldGYub3JnPC9hPl0gT24gQmVoYWxmIE9m IE5pa29zPGJyPg0KJmd0OyBNYXZyb2dpYW5ub3BvdWxvczxicj4NCiZndDsgU2VudDogRnJpZGF5 LCBKdW5lIDEwLCAyMDE2IDEyOjE3IEFNPGJyPg0KJmd0OyBUbzogRGFuaWVsIE1pZ2F1bHQgJmx0 OzxhIGhyZWY9Im1haWx0bzpkYW5pZWwubWlnYXVsdEBlcmljc3Nvbi5jb20iIHRhcmdldD0iX2Js YW5rIj5kYW5pZWwubWlnYXVsdEBlcmljc3Nvbi5jb208L2E+Jmd0Ozxicj4NCiZndDsgQ2M6IDxh IGhyZWY9Im1haWx0bzpjdXJkbGVAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5jdXJkbGVAaWV0 Zi5vcmc8L2E+PGJyPg0KJmd0OyBTdWJqZWN0OiBSZTogW0N1cmRsZV0gZHJhZnQtaWV0Zi1jdXJk bGUtcGtpeC0wMDogYSBzaW1wbGlmaWNhdGlvbiBwcm9wb3NhbDxicj4NCiZndDs8YnI+DQomZ3Q7 IEkgc3VwcG9ydCB0aGlzLjxicj4NCiZndDs8YnI+DQomZ3Q7IC0tLS0tIE9yaWdpbmFsIE1lc3Nh Z2UgLS0tLS08YnI+DQomZ3Q7IEhpLDxicj4NCiZndDs8YnI+DQomZ3Q7IERvIHdlIGhhdmUgc29t ZSBjb25zZW5zdXMgdGhhdCBoYXZpbmcgdG9wLWxldmVsIE9JRCB3b3VsZCBiZSBiZXR0ZXIgPzxi cj4NCiZndDsgUGxlYXNlIHByb3ZpZGUgeW91ciBvcGluaW9uIGFuZCBsZXQgdGhlIFdHIGtub3cg eW91ciB0aG91Z2h0cyBzbyB0aGU8YnI+DQomZ3Q7IGRvY3VtZW50IGNhbiBiZSBtb3ZlZCBmb3J3 YXJkLjxicj4NCiZndDs8YnI+DQomZ3Q7IEJSLDxicj4NCiZndDsgRGFuaWVsPGJyPg0KJmd0Ozxi cj4NCiZndDsgT24gVGh1LCBNYXkgMTksIDIwMTYgYXQgMTA6NDEgQU0sIERhdmlkIEJlbmphbWlu ICZsdDs8YSBocmVmPSJtYWlsdG86ZGF2aWRiZW5AY2hyb21pdW0ub3JnIiB0YXJnZXQ9Il9ibGFu ayI+ZGF2aWRiZW5AY2hyb21pdW0ub3JnPC9hPiZndDs8YnI+DQomZ3Q7IHdyb3RlOjxicj4NCiZn dDs8YnI+DQomZ3Q7ICZndDsgT24gVGh1LCBNYXkgMTksIDIwMTYgYXQgNDo0MCBBTSBOaWtvcyBN YXZyb2dpYW5ub3BvdWxvczxicj4NCiZndDsgJmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5tYXZA cmVkaGF0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm5tYXZAcmVkaGF0LmNvbTwvYT4mZ3Q7PGJyPg0K Jmd0OyAmZ3Q7IHdyb3RlOjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyZndDsgT24gVHVl LCAyMDE2LTA1LTE3IGF0IDE0OjIwICYjNDM7MDAwMCwgRGF2aWQgQmVuamFtaW4gd3JvdGU6PGJy Pg0KJmd0OyAmZ3Q7Jmd0OyAmZ3Q7IEkgd291bGQgYWN0dWFsbHkgYWR2b2NhdGUgYSBkaWZmZXJl bnQgY2hhbmdlLiBJIHNlbnQgdGhpcyBtZXNzYWdlPGJyPg0KJmd0OyAmZ3Q7Jmd0OyAmZ3Q7IGVh cmxpZXI6PGJyPg0KJmd0OyAmZ3Q7Jmd0OyAmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYu b3JnL21haWwtYXJjaGl2ZS93ZWIvY3VyZGxlL2N1cnJlbnQvbXNnMDAyMDMuaHRtbCIgdGFyZ2V0 PSJfYmxhbmsiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9jdXJkbGUv Y3VycmVudC9tc2cwMDIwMy5odG1sPC9hPjxicj4NCiZndDsgJmd0OyZndDsgJmd0Ozxicj4NCiZn dDsgJmd0OyZndDsgJmd0OyBSYXRoZXIgdGhhbiB1c2UgcGFyYW1ldGVycywgYWxsb2NhdGUgbmV3 IGFsZ29yaXRobSBPSURzIGZvcjxicj4NCiZndDsgJmd0OyZndDsgJmd0OyBldmVyeXRoaW5nLiBJ IGRvbid0IHRoaW5rIHdlIGFjdHVhbGx5IGdhaW4gYW55dGhpbmcgYnkgZXhwb3NpbmcgdGhlPGJy Pg0KJmd0OyAmZ3Q7Jmd0OyAmZ3Q7IHJlbGF0aW9ucyBhbmQgcGFyYW1ldGVyaXphdGlvbnMgYmV0 d2VlbiB0aGVzZSBhbGdvcml0aG1zLiBXaGVuPGJyPg0KJmd0OyAmZ3Q7Jmd0OyAmZ3Q7IGltcGxl bWVudGluZywgdGhleSBhcmUgZ3JlYXQgZm9yIHNoYXJpbmcgY29kZS4gQnV0IHdoZW4gY29uc3Vt aW5nLDxicj4NCiZndDsgJmd0OyZndDsgJmd0OyBleHBvc2luZyBpdCBtYWtlcyBwYXJzaW5nIG1v cmUgY29tcGxleCwgYW5kIGl0IGluY3JlYXNlcyB0aGUgcmlzazxicj4NCiZndDsgJmd0OyZndDsg Jmd0OyBvZiByZXVzaW5nIGtleXMgYmV0d2VlbiByZWxhdGVkIGFsZ29yaXRobXMuIFdlIGNhbiBn ZXQgdGhlIGJlc3Qgb2Y8YnI+DQomZ3Q7ICZndDsmZ3Q7ICZndDsgYm90aCB3b3JsZHMgYnkgc2Vw YXJhdGluZyBlbnRyeS1wb2ludHMgYW5kIHNoYXJpbmcgaW50ZXJuYWxzLjxicj4NCiZndDsgJmd0 OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7IE9uIHlvdXIgcmVmZXJlbmNlZCBtZXNzYWdlIEkgYW0g Y29uZnVzZWQgb24gdGhlIGlzc3VlIHlvdSByYWlzZSBvbjxicj4NCiZndDsgJmd0OyZndDsgc2Vj dGlvbiAzLiBBcyBJIHJlYWQgc2VjdGlvbiAzLCBJIGRvIG5vdCBzZWUgYW55dGhpbmcgdGhhdCBh bGxvd3M8YnI+DQomZ3Q7ICZndDsmZ3Q7IGhhdmluZyBpZC1lY1B1YmxpY0tleSBhcyBhbiBhbGdv cml0aG0gaWRlbnRpZmllciBmb3IgdGhlc2Uga2V5cy48YnI+DQomZ3Q7ICZndDsmZ3Q7PGJyPg0K Jmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IEl0J3MgY2VydGFpbmx5IHBvc3NpYmxlIEknbSBtaXN1 bmRlcnN0YW5kaW5nIHdoYXQgc2VjdGlvbiAzIHdhcyBmb3IuIEk8YnI+DQomZ3Q7ICZndDsgd2Fz IGtpbmQgb2YgY29uZnVzZWQgd2h5IHRoZXJlIHdlcmUgdHdvIGVuY29kaW5ncy4gSSB3YXMgZ2V0 dGluZzxicj4NCiZndDsgJmd0OyBpZC1lY1B1YmxpY0tleTxicj4NCiZndDsgJmd0OyBmcm9tOjxi cj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmcXVvdDsmcXVvdDsmcXVvdDs8YnI+DQomZ3Q7 ICZndDsmbmJzcDsgJm5ic3A7IFNlY3Rpb24gMi4zLjUgb2YgW1JGQzMyNzldPGJyPg0KJmd0OyAm Z3Q7Jm5ic3A7ICZuYnNwOyBkZXNjcmliZSBFQ0RTQS9FQ0RIIHB1YmxpYyBrZXlzLCBzcGVjaWZ5 aW5nIHRoZSBpZC1lY1B1YmxpY0tleSBPSUQuPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyBU aGlzIE9JRCBoYXMgdGhlIGFzc29jaWF0ZWQgRWNwa1BhcmFtZXRlcnMgcGFyYW1ldGVycyBzdHJ1 Y3R1cmUsPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyB3aGljaCBjb250YWlucyB0aGUgbmFt ZWRDdXJ2ZSBDSE9JQ0UuJm5ic3A7IEhlcmUgd2UgaW50cm9kdWNlIHR3byBbSTxicj4NCiZndDsg Jmd0OyB0aGluayB0aGlzIHNob3VsZCBiZSBmb3VyXSBuZXcgT0lEczxicj4NCiZndDsgJmd0OyZu YnNwOyAmbmJzcDsgZm9yIHVzZSBpbiB0aGUgbmFtZWRDdXJ2ZSBmaWVsZC48YnI+DQomZ3Q7ICZn dDsgJnF1b3Q7JnF1b3Q7JnF1b3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IEFueXdh eSwgaWYgd2UgZ28gd2l0aCB0b3AtbGV2ZWwgT0lEcyBmb3IgZXZlcnl0aGluZywgdGhpcyBpcyBh bGwgbW9vdC48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgRGF2aWQ8YnI+DQomZ3Q7ICZn dDs8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7IE90aGVyIHRoYW4gdGhpcyBwYXJ0 LCB5b3UgcmFpc2UgYSB2ZXJ5IGdvb2QgcG9pbnQuIEl0IG1heSBiZSBtdWNoPGJyPg0KJmd0OyAm Z3Q7Jmd0OyBzaW1wbGVyIHRvIHVzZSBhIGNvbW1vbiBPSUQgYW5kIG1vdmUgaXQgdXAuIFVubGlr ZSB0aGUgTklTVCBjdXJ2ZXM8YnI+DQomZ3Q7ICZndDsmZ3Q7IHRoZSBjb25zdHJ1Y3Rpb25zIHdl IGhhdmUgdW5kZXIgdGhlIGVkZHNhIE9JRCB1bWJyZWxsYSBhcmUgcXVpdGU8YnI+DQpkaXN0aW5j dC48YnI+DQomZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBJIHdhcyBjb25jZXJuZWQg YWJvdXQgZnV0dXJlIGV4dGVuc2liaWxpdHkgYW5kIHRoZSBmYWN0IHRoYXQ8YnI+DQomZ3Q7ICZn dDsmZ3Q7IHB1cmVFZERTQSBhbmQgUHJlaGFzaGVkRWREU0EgY291bGQgYmUgd2l0aCBzZXBhcmF0 ZSBhbGdvcml0aG0gT0lEcyw8YnI+DQomZ3Q7ICZndDsmZ3Q7IGJ1dCBhZnRlciB0aGlua2luZyBp dCBmdXJ0aGVyLCBJIHRoaW5rIHdoYXQgeW91IHN1Z2dlc3QgaXMgbXVjaDxicj4NCiZndDsgJmd0 OyZndDsgbmVhdGVyLCBhcyBoYXZpbmcgYSBzaW5nbGUgT0lEIHRvIGlkZW50aWZ5IHNjaGVtZSYj NDM7Y3VydmUgd2lsbCBhbHNvPGJyPg0KJmd0OyAmZ3Q7Jmd0OyByZXN0cmljdCBwcml2YXRlIGtl eXMgdG8gYSBzaW5nbGUgcHVycG9zZSB3aGljaCBpcyBhIGdvb2QgdGhpbmcuPGJyPg0KJmd0OyAm Z3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsgJiM0MzsxPGJyPg0KJmd0OyAmZ3Q7Jmd0Ozxicj4N CiZndDsgJmd0OyZndDsgcmVnYXJkcyw8YnI+DQomZ3Q7ICZndDsmZ3Q7IE5pa29zPGJyPg0KJmd0 OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZndDsgX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7ICZndDsgQ3VyZGxl IG1haWxpbmcgbGlzdDxicj4NCiZndDsgJmd0OyA8YSBocmVmPSJtYWlsdG86Q3VyZGxlQGlldGYu b3JnIiB0YXJnZXQ9Il9ibGFuayI+Q3VyZGxlQGlldGYub3JnPC9hPjxicj4NCiZndDsgJmd0OyA8 YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2N1cmRsZSIgdGFy Z2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY3VyZGxl PC9hPjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyBD dXJkbGUgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyA8YSBocmVmPSJtYWlsdG86Q3VyZGxlQGlldGYu b3JnIiB0YXJnZXQ9Il9ibGFuayI+Q3VyZGxlQGlldGYub3JnPC9hPjxicj4NCiZndDsgPGEgaHJl Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jdXJkbGUiIHRhcmdldD0i X2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2N1cmRsZTwvYT48 YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xzxicj4NCkN1cmRsZSBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86Q3VyZGxlQGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+Q3VyZGxlQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9 Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY3VyZGxlIiB0YXJnZXQ9Il9i bGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jdXJkbGU8L2E+PG86 cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_2DD56D786E600F45AC6BDE7DA4E8A8C117F26424eusaamb107erics_-- From nobody Fri Jun 24 09:02:11 2016 Return-Path: X-Original-To: curdle@ietf.org Delivered-To: curdle@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9834912DC43; Fri, 24 Jun 2016 09:00:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.24.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160624160040.10933.71611.idtracker@ietfa.amsl.com> Date: Fri, 24 Jun 2016 09:00:40 -0700 Archived-At: Cc: curdle@ietf.org, stephen.farrell@cs.tcd.ie Subject: [Curdle] curdle - Requested session has been scheduled for IETF 96 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 16:00:41 -0000 Dear Daniel Migault, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. curdle Session 1 (1:00:00) Friday, Afternoon Session I 1220-1320 Room Name: Charlottenburg I size: 80 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: CURves, Deprecating and a Little more Encryption Area Name: Security Area Session Requester: Daniel Migault Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 20 Conflicts to Avoid: First Priority: cfrg 6lo saag ipsecme tls Second Priority: sacm tcpinc i2nsf trans Special Requests: --------------------------------------------------------- From nobody Fri Jun 24 11:49:38 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5380112D556 for ; Fri, 24 Jun 2016 11:49:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rnQ0OE2Z37YJ for ; Fri, 24 Jun 2016 11:49:35 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8AFB12B027 for ; Fri, 24 Jun 2016 11:49:34 -0700 (PDT) Received: from hebrews (c-24-21-96-37.hsd1.or.comcast.net [24.21.96.37]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 2F9DF38F22 for ; Fri, 24 Jun 2016 11:49:34 -0700 (PDT) From: "Jim Schaad" To: References: <20160624160040.10933.71611.idtracker@ietfa.amsl.com> In-Reply-To: <20160624160040.10933.71611.idtracker@ietfa.amsl.com> Date: Fri, 24 Jun 2016 11:49:33 -0700 Message-ID: <073c01d1ce49$265bf430$7313dc90$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQGNgENbAv7OXuejpLcWp3IbROZWyqCBkbAw Content-Language: en-us Archived-At: Subject: [Curdle] FW: curdle - Requested session has been scheduled for IETF 96 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 18:49:37 -0000 Does this mean that the session has been uncanceled? > -----Original Message----- > From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of "IETF Secretariat" > Sent: Friday, June 24, 2016 9:01 AM > To: daniel.migault@ericsson.com; curdle-chairs@ietf.org > Cc: curdle@ietf.org; stephen.farrell@cs.tcd.ie > Subject: [Curdle] curdle - Requested session has been scheduled for IETF 96 > > Dear Daniel Migault, > > The session(s) that you have requested have been scheduled. > Below is the scheduled session information followed by the original request. > > curdle Session 1 (1:00:00) > Friday, Afternoon Session I 1220-1320 > Room Name: Charlottenburg I size: 80 > --------------------------------------------- > > > > Request Information: > > > --------------------------------------------------------- > Working Group Name: CURves, Deprecating and a Little more Encryption Area > Name: Security Area Session Requester: Daniel Migault > > Number of Sessions: 1 > Length of Session(s): 1 Hour > Number of Attendees: 20 > Conflicts to Avoid: > First Priority: cfrg 6lo saag ipsecme tls Second Priority: sacm tcpinc i2nsf trans > > > > Special Requests: > > --------------------------------------------------------- > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle From nobody Sat Jun 25 20:49:34 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DB0A127078 for ; Sat, 25 Jun 2016 20:49:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SlFFDpxd0SSV for ; Sat, 25 Jun 2016 20:49:31 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89EB912B007 for ; Sat, 25 Jun 2016 20:49:31 -0700 (PDT) X-AuditID: 1209190d-cb3ff700000053a3-04-576f50c93757 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 21.C3.21411.9C05F675; Sat, 25 Jun 2016 23:49:30 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id u5Q3nT6k022232; Sat, 25 Jun 2016 23:49:29 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u5Q3nPt0015928 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 25 Jun 2016 23:49:28 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id u5Q3nPwP013846; Sat, 25 Jun 2016 23:49:25 -0400 (EDT) Date: Sat, 25 Jun 2016 23:49:25 -0400 (EDT) From: Benjamin Kaduk To: Daniel Migault In-Reply-To: <2DD56D786E600F45AC6BDE7DA4E8A8C117F26424@eusaamb107.ericsson.se> Message-ID: References: <1463470661.2914.4.camel@redhat.com> <1463647224.3558.14.camel@redhat.com> <1553247361.41476124.1465542998520.JavaMail.zimbra@redhat.com> <015201d1caa9$ce55ac60$6b010520$@augustcellars.com> <2DD56D786E600F45AC6BDE7DA4E8A8C117F26424@eusaamb107.ericsson.se> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrEIsWRmVeSWpSXmKPExsUixCmqrHsqID/c4MdTBYutC2cxW0yZvofN gcnj19erbB5LlvxkCmCK4rJJSc3JLEst0rdL4Mr43tPJVjDVrqJ9/UH2BsZ2oy5GDg4JAROJ ZYfsuxi5OIQE2pgkpjxdzgzhbGSUmLD2OQuEc4hJ4vzGY0wQTgOjRPeBP0AOJweLgLZE66K9 rCA2m4CKxMw3G9lAbBEBA4mXE3aC2cwC6hId81tYQGxhAS+Jxj/HwHo5Bfwkvi06zgxi8wo4 Sqx4toYRYsFiFomO++1gzaICOhKr909hgSgSlDg58wkLxFAtieXTt7FMYBSYhSQ1C0lqASPT KkbZlNwq3dzEzJzi1GTd4uTEvLzUIl0jvdzMEr3UlNJNjOCglOTdwfjvrtchRgEORiUe3hUS +eFCrIllxZW5hxglOZiURHm3PcoNF+JLyk+pzEgszogvKs1JLT7EKMHBrCTCy+0NVM6bklhZ lVqUD5OS5mBREueNuXk0TEggPbEkNTs1tSC1CCYrw8GhJMGr4A/UKFiUmp5akZaZU4KQZuLg BBnOAzT8vB/I8OKCxNzizHSI/ClGRSlx3j0gCQGQREZpHlwvOGnsZlJ9xSgO9IowbxvICh5g woHrfgU0mAlo8N3+bJDBJYkIKakGxvLdHIUXzO2/i87c+8tyn1z+65zV71ov/zDc8iwk1ORN YCqzZlyw4/v/L+al/50h3XyfbdGisFbewtA5cXuunlpZu+iicU219b8jhzKj5T6ofzgQ0LPR 34B3UdSrUAHm86VFGycde3q8/cmFd+s3/Px6Qjp2i0SzX5vHHct9bLYmpjeEnpRmfFdiKc5I NNRiLipOBAAXcr5n9QIAAA== Archived-At: Cc: "curdle@ietf.org" Subject: Re: [Curdle] draft-ietf-curdle-pkix-00: a simplification proposal X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jun 2016 03:49:33 -0000 David has basically convinced me of the superiority of the "one joint and keep it well-oiled" philosophy (i.e., top-level OID) -- it's just too easy for implementations to end up doing bad things when there are separate parameters involved. -Ben On Thu, 23 Jun 2016, Daniel Migault wrote: > Hi all, > > We currently do not have consensus whether we should be using top level OID or not. This is an important issue, and we would like to find a consensus as soon as possible, so please provide your opinion by next week. > > BR, > Daniel > > From: David Benjamin [mailto:davidben@chromium.org] > Sent: Monday, June 20, 2016 6:02 PM > To: Jim Schaad; Daniel Migault > Cc: curdle@ietf.org > Subject: Re: [Curdle] draft-ietf-curdle-pkix-00: a simplification proposal > > On Mon, Jun 20, 2016 at 12:11 AM Jim Schaad > wrote: > The one downside that this approach has is that it makes negotiation either > much easier or a lot harder depending on what you are trying to negotiate. > > It makes it easier to agree on a curve, as the curve is part of the system > and now does not need to be negotiated separately. On the other hand, one > cannot say that one is willing to take any curve that is supported for > either ECDH, EdDSA or EdDSAph depending on what type of algorithm is > desired. > > When were you thinking one would wish to do that? My claim is this is not a thing that makes sense to advertise. > > What does it mean to advertise EdDSA in your algorithms list and P-256 (because you're willing to do P-256 + ECDH) and Curve25519 in your curves list? EdDSA for P-256 isn't defined. EdDSA also isn't parameterized on curve alone. It has a hash function we pair with it. That second choice being implicit is odd. (And problematic if, say, someone defines Ed25519-SHA3 := EdDSA(curve25519, SHA3-512) or so.) > > This is the same problem TLS 1.3 had. TLS 1.2 negotiated curves and algorithms separately, and we switched it to a scheme much closer to the proposal. The old curve list is used for key exchange alone, and the signature algorithms list recast to specify only unparameterized algorithms like rsa_pss_sha256, ecdsa_p256_sha256, and ed25519. > > Forcing X25519, Ed25519, and Ed25519ph into the same "curve" also means SPKIs don't say which algorithm they're for. If you're thinking id-ecPublicKey, we'd use the key usage. But X25519 and Ed25519's public key formats aren't even compatible. Ed25519's curve is equivalent to X25519's, but it's not the same. > > Ed25519 and Ed25519ph are more comparable, but key reuse between the two breaks the algorithms. (A signature for M in Ed25519ph will forge a signature for SHA-512(M) in Ed25519 if keys are mixed.) They also do not have the same type signature. Ed25519 is a single-shot function while Ed25519ph is an Init/Update/Final triple. > > This is going to be complicated for ECDH given that one is going to > potentially need to negotiate the new curves and the old curves at the same > time in different methods. > > I could imagine we do id-ecPublicKey with separate x25519/ed25519/ed25519ph namedCurve values which would avoid this concern, but it's nothing like id-ecPublicKey. The three named "curves" are nothing like existing curves. Existing curves are usable with ECDH or ECDSA with any hash. They come with the X9.62 serialization and multiple point format business. They decide on algorithm via key usage extension. These new ones are straight-forward functions on byte strings that do just one algorithm, as the rest of things should have been designed. > > Yes, it is a break from the old world, but I think one that is warranted. I would rather we make the clean break and avoid these historical mistakes now rather than perpetuate them further. One already must account for future algorithms that don't have "elliptic curve" in the name anyway. > > I am not really in favor of using top level OIDs for all of the different > combinations of keys and algorithms. > > Jim > > > -----Original Message----- > > From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Nikos > > Mavrogiannopoulos > > Sent: Friday, June 10, 2016 12:17 AM > > To: Daniel Migault > > > Cc: curdle@ietf.org > > Subject: Re: [Curdle] draft-ietf-curdle-pkix-00: a simplification proposal > > > > I support this. > > > > ----- Original Message ----- > > Hi, > > > > Do we have some consensus that having top-level OID would be better ? > > Please provide your opinion and let the WG know your thoughts so the > > document can be moved forward. > > > > BR, > > Daniel > > > > On Thu, May 19, 2016 at 10:41 AM, David Benjamin > > > wrote: > > > > > On Thu, May 19, 2016 at 4:40 AM Nikos Mavrogiannopoulos > > > > > > > wrote: > > > > > >> On Tue, 2016-05-17 at 14:20 +0000, David Benjamin wrote: > > >> > I would actually advocate a different change. I sent this message > > >> > earlier: > > >> > https://www.ietf.org/mail-archive/web/curdle/current/msg00203.html > > >> > > > >> > Rather than use parameters, allocate new algorithm OIDs for > > >> > everything. I don't think we actually gain anything by exposing the > > >> > relations and parameterizations between these algorithms. When > > >> > implementing, they are great for sharing code. But when consuming, > > >> > exposing it makes parsing more complex, and it increases the risk > > >> > of reusing keys between related algorithms. We can get the best of > > >> > both worlds by separating entry-points and sharing internals. > > >> > > >> On your referenced message I am confused on the issue you raise on > > >> section 3. As I read section 3, I do not see anything that allows > > >> having id-ecPublicKey as an algorithm identifier for these keys. > > >> > > > > > > It's certainly possible I'm misunderstanding what section 3 was for. I > > > was kind of confused why there were two encodings. I was getting > > > id-ecPublicKey > > > from: > > > > > > """ > > > Section 2.3.5 of [RFC3279] > > > describe ECDSA/ECDH public keys, specifying the id-ecPublicKey OID. > > > This OID has the associated EcpkParameters parameters structure, > > > which contains the namedCurve CHOICE. Here we introduce two [I > > > think this should be four] new OIDs > > > for use in the namedCurve field. > > > """ > > > > > > Anyway, if we go with top-level OIDs for everything, this is all moot. > > > > > > David > > > > > > > > >> Other than this part, you raise a very good point. It may be much > > >> simpler to use a common OID and move it up. Unlike the NIST curves > > >> the constructions we have under the eddsa OID umbrella are quite > distinct. > > >> > > >> I was concerned about future extensibility and the fact that > > >> pureEdDSA and PrehashedEdDSA could be with separate algorithm OIDs, > > >> but after thinking it further, I think what you suggest is much > > >> neater, as having a single OID to identify scheme+curve will also > > >> restrict private keys to a single purpose which is a good thing. > > >> > > >> +1 > > >> > > >> regards, > > >> Nikos > > >> > > >> > > > _______________________________________________ > > > Curdle mailing list > > > Curdle@ietf.org > > > https://www.ietf.org/mailman/listinfo/curdle > > > > > > > > > > _______________________________________________ > > Curdle mailing list > > Curdle@ietf.org > > https://www.ietf.org/mailman/listinfo/curdle > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle >