From nobody Fri Aug 2 23:55:36 2019 Return-Path: X-Original-To: spasm@ietf.org Delivered-To: spasm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 03509120111; Fri, 2 Aug 2019 23:55:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alexey Melnikov via Datatracker To: "The IESG" Cc: draft-ietf-lamps-cms-shakes@ietf.org, Russ Housley , lamps-chairs@ietf.org, housley@vigilsec.com, spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.99.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Alexey Melnikov Message-ID: <156481532800.6108.1633834009578124669.idtracker@ietfa.amsl.com> Date: Fri, 02 Aug 2019 23:55:28 -0700 Archived-At: Subject: [lamps] Alexey Melnikov's Discuss on draft-ietf-lamps-cms-shakes-15: (with DISCUSS) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Aug 2019 06:55:28 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-lamps-cms-shakes-15: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-shakes/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- This is a fine document, but I have one quick question: Values TBD1..TBD4 are not listed in the IANA Considerations section. Should they be? From nobody Mon Aug 5 04:58:24 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E5511201C3 for ; Mon, 5 Aug 2019 04:58:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 NdRXWpdzwGi4 for ; Mon, 5 Aug 2019 04:58:10 -0700 (PDT) Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) (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 1FD2B1201E3 for ; Mon, 5 Aug 2019 04:58:10 -0700 (PDT) Received: by mail-qt1-x82a.google.com with SMTP id z4so80643424qtc.3 for ; Mon, 05 Aug 2019 04:58:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=inGbZysOqpzbU59EnMZIGs10GpDXeE3UXpNHmOdujis=; b=f2k0axW2wrjMLGpCE8imsQtalRr3aatX6RvjZx0GoPXb0m+vZeHEY3wncMT1VLwPDL /boV5yNTuuoJl0ocBOMEAgnDDXbEXjpCOnHIN2B2dY2kh+oXPNDe31knekyAvyX2KYdY cr6FZt+dpwLpzYnBKekVi4YceyK8dCG4LoeBM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=inGbZysOqpzbU59EnMZIGs10GpDXeE3UXpNHmOdujis=; b=oax98QyCqzcGzK/gjInn7fA2VCSYIBiWZ2xpf5bYjd+QwyE4DcBlt4FcRpZEXYoYpw bi3lxrFxspuwLp0NAN7zQsdI5bAIDlhYoYuVz7hR+kQz2xKUWppheQ8XvNEazC1Qg3ml vi5VLEPDLK/3twJHlHy+9pp0zIdalcpSuHsu7SDhjGVJa2TALYIo++6LlpCuzZD+XmvW 5p3Ix9H9G/ZfBt5Xo4qi+Nb0t5cfuAda9T7pTrKlUtu/S4z/RugW6LkDBmC0UpItRevE 16YLQCkf823HL3hcIocw3lhaFLOxLWp3mFbC0YmZCVi/1c2xTXIOWG6zgiKTm6avlCAm fyAw== X-Gm-Message-State: APjAAAUQ+DjNfy3yDW2NdjEdHmMS6gFNSDmlSwxodlelDbGeTictkYi0 rMSHEX/DjF2LoJuGPZssVXg= X-Google-Smtp-Source: APXvYqwsQMn/Y3Lti3WV+rz79LUpTujw+YPSeqqHZWH4EN+Fh/DljFZRUDfXUqBCEnYoaRXt3sCjzQ== X-Received: by 2002:ac8:2a99:: with SMTP id b25mr107329156qta.223.1565006289229; Mon, 05 Aug 2019 04:58:09 -0700 (PDT) Received: from sn3rd.lan ([75.102.131.36]) by smtp.gmail.com with ESMTPSA id l8sm301990qtr.38.2019.08.05.04.58.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 05 Aug 2019 04:58:08 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Sean Turner In-Reply-To: <14050.1564606087@localhost> Date: Mon, 5 Aug 2019 07:58:07 -0400 Cc: Benjamin Kaduk , LAMPS WG , Russ Housley Content-Transfer-Encoding: quoted-printable Message-Id: <0455CEB5-65EF-498C-A5E9-133C6D4226CE@sn3rd.com> References: <21504.1564174053@dooku.sandelman.ca> <9CE09410-5F6B-407F-B239-888E3136F24A@vigilsec.com> <547B521B-A93B-4E33-96A9-8B2DEE216748@vigilsec.com> <20190731194117.GG1006@kduck.mit.edu> <14050.1564606087@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [lamps] rfc7030-est clarifications and LAMPS charter X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2019 11:58:22 -0000 I think you have two choices: 1) Fix the text 2) Fix the text and include a module In either case fixing the text is* : * This is basically what Russ suggested, but I do not think the name of = the set should imply that the only attributes that can be used are = defined in 7030. Any attribute can be included so I changed = =E2=80=9CAttributesDefinedInRFC7030=E2=80=9D to =E2=80=9CCsrAttrSet=E2=80=9D= . OLD: CsrAttrs ::=3D SEQUENCE SIZE (0..MAX) OF AttrOrOID AttrOrOID ::=3D CHOICE (oid OBJECT IDENTIFIER, attribute Attribute } Attribute { ATTRIBUTE:IOSet } ::=3D SEQUENCE { type ATTRIBUTE.&id({IOSet}), values SET SIZE(1..MAX) OF ATTRIBUTE.&Type({IOSet}{@type}) } NEW: CsrAttrs ::=3D SEQUENCE SIZE (0..MAX) OF AttrOrOID AttrOrOID ::=3D CHOICE { oid OBJECT IDENTIFIER, attribute Attribute {{AttrSet}} } Attribute { ATTRIBUTE:IOSet } ::=3D SEQUENCE { type ATTRIBUTE.&id({IOSet}), values SET SIZE(1..MAX) OF ATTRIBUTE.&Type({IOSet}{@type}) } AttrSet ATTRIBUTE ::=3D { CsrAttrSet } CsrAttrSet ATTRIBUTE ::=3D { aa-asymmDecryptKeyID, -- see Section 4.4.1.2. =E2=80=A6 } spt > On Jul 31, 2019, at 16:48, Michael Richardson = wrote: >=20 > Signed PGP part >=20 > Benjamin Kaduk wrote: >>> Thinking about this some more, I think that the best way to resolve >>> this errata is to provide an appendix with an ASN.1 module. Here is >>> my suggestion: >=20 >> That feels somewhat heavyweight for an erratum. What are the = pros/cons >> of errata vs. small updating RFC? >=20 > The intention is to have a small updating RFC. >=20 > --=20 > ] Never tell me the odds! | ipv6 mesh = networks [ > ] Michael Richardson, Sandelman Software Works | IoT = architect [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on = rails [ >=20 >=20 >=20 From nobody Mon Aug 5 07:02:06 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5E99120222 for ; Mon, 5 Aug 2019 07:02:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 H9gKtvZLh0tn for ; Mon, 5 Aug 2019 07:02:02 -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 A3E9912018A for ; Mon, 5 Aug 2019 07:02:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id A8C03300AAF for ; Mon, 5 Aug 2019 09:42:44 -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 ByBiFZ_xfr12 for ; Mon, 5 Aug 2019 09:42:42 -0400 (EDT) Received: from [172.26.55.168] (unknown [104.129.196.116]) by mail.smeinc.net (Postfix) with ESMTPSA id 4001B3004D8; Mon, 5 Aug 2019 09:42:41 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Russ Housley In-Reply-To: <0455CEB5-65EF-498C-A5E9-133C6D4226CE@sn3rd.com> Date: Mon, 5 Aug 2019 10:01:59 -0400 Cc: Michael Richardson , LAMPS WG , Ben Kaduk Content-Transfer-Encoding: quoted-printable Message-Id: <3DF77ED0-C4EC-479E-84E9-C882CAFE076D@vigilsec.com> References: <21504.1564174053@dooku.sandelman.ca> <9CE09410-5F6B-407F-B239-888E3136F24A@vigilsec.com> <547B521B-A93B-4E33-96A9-8B2DEE216748@vigilsec.com> <20190731194117.GG1006@kduck.mit.edu> <14050.1564606087@localhost> <0455CEB5-65EF-498C-A5E9-133C6D4226CE@sn3rd.com> To: Sean Turner X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [lamps] rfc7030-est clarifications and LAMPS charter X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2019 14:02:05 -0000 Sure. That name change works for me. I think adding the module can = only improve interoperability. Russ > On Aug 5, 2019, at 7:58 AM, Sean Turner wrote: >=20 > I think you have two choices: >=20 > 1) Fix the text > 2) Fix the text and include a module >=20 > In either case fixing the text is* : >=20 > * This is basically what Russ suggested, but I do not think the name = of the set should imply that the only attributes that can be used are = defined in 7030. Any attribute can be included so I changed = =E2=80=9CAttributesDefinedInRFC7030=E2=80=9D to =E2=80=9CCsrAttrSet=E2=80=9D= . >=20 > OLD: >=20 > CsrAttrs ::=3D SEQUENCE SIZE (0..MAX) OF AttrOrOID >=20 > AttrOrOID ::=3D CHOICE (oid OBJECT IDENTIFIER, attribute Attribute } >=20 > Attribute { ATTRIBUTE:IOSet } ::=3D SEQUENCE { > type ATTRIBUTE.&id({IOSet}), > values SET SIZE(1..MAX) OF ATTRIBUTE.&Type({IOSet}{@type}) } >=20 > NEW: >=20 > CsrAttrs ::=3D SEQUENCE SIZE (0..MAX) OF AttrOrOID >=20 > AttrOrOID ::=3D CHOICE { > oid OBJECT IDENTIFIER, > attribute Attribute {{AttrSet}} } >=20 > Attribute { ATTRIBUTE:IOSet } ::=3D SEQUENCE { > type ATTRIBUTE.&id({IOSet}), > values SET SIZE(1..MAX) OF ATTRIBUTE.&Type({IOSet}{@type}) } >=20 > AttrSet ATTRIBUTE ::=3D { CsrAttrSet } >=20 > CsrAttrSet ATTRIBUTE ::=3D { > aa-asymmDecryptKeyID, -- see Section 4.4.1.2. > =E2=80=A6 } >=20 > spt >=20 >=20 >> On Jul 31, 2019, at 16:48, Michael Richardson = wrote: >>=20 >> Signed PGP part >>=20 >> Benjamin Kaduk wrote: >>>> Thinking about this some more, I think that the best way to resolve >>>> this errata is to provide an appendix with an ASN.1 module. Here = is >>>> my suggestion: >>=20 >>> That feels somewhat heavyweight for an erratum. What are the = pros/cons >>> of errata vs. small updating RFC? >>=20 >> The intention is to have a small updating RFC. >>=20 >> --=20 >> ] Never tell me the odds! | ipv6 mesh = networks [ >> ] Michael Richardson, Sandelman Software Works | IoT = architect [ >> ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on = rails [ >>=20 >>=20 >>=20 >=20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm From nobody Mon Aug 5 07:28:40 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE6CC12022C for ; Mon, 5 Aug 2019 07:28:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 PBIQxss1AQ6V for ; Mon, 5 Aug 2019 07:28:36 -0700 (PDT) Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) (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 4240612022E for ; Mon, 5 Aug 2019 07:28:36 -0700 (PDT) Received: by mail-qt1-x82f.google.com with SMTP id h21so81050526qtn.13 for ; Mon, 05 Aug 2019 07:28:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=T5Aa1cVnO5UP5rn8TCpykqO6hLGHkA13P9SdJhjyXes=; b=WJMPm+TPaNYiKGT6Imxzo+jJ9IdAC6QDZCz0IY0HEUq3UoTGLaBOZUmfduLISq9SXv PRP3Z39ZP1SofXBTMFUuP2H2yZDnevSIB6uonTNswTw83pR+wj4xJDEeLVtM5Q1rCZDd cVRrmQ2POHYZAEv0t1Z2Bhi527rdhZ1Bjbij8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=T5Aa1cVnO5UP5rn8TCpykqO6hLGHkA13P9SdJhjyXes=; b=Tvizwr7+D+yFzX7tZI+NFug4jXN8d68eOBmei36OV1Jx/dPn4CDfmP/GdYdnADYoSd o61qttxdpVM8wXck/hwh3BtjKA3CHyOmo+O7keyqI8j6Rxq2NyWufRl8KtB3pvannQVF yY1dMVxu1x7z4CaMxJ9BAC/HLvNAKUtI54w7cljQaQN3IDuIgjCAvSYlljbwrcGjFfdS N2CyBvX2Vi7U84iEduDHXjLS9g9e/+4G3ph5D6h3A0hi3eW1uhT38KJmvnfYiZqHYxHC yjWMcqSNLIlW8B1uSck5tlzY+ow7t3M9lbaWzCdekWZVSEY8IX0dugB7vRLsNODRv+6o 6esQ== X-Gm-Message-State: APjAAAUflHGNb1FpEHmSdEnwufTnImHGi4muPXwXCcG7nwZfa693sZNd i+xSyCNPAcG255P8b+mEv5k= X-Google-Smtp-Source: APXvYqyWkRD+UJCf+ugzGA6NOAXu5uCDXpAkTH4CMspF2Yumt+0GfB64OlTv4rHAe7BlSNrR17rVbw== X-Received: by 2002:a0c:8695:: with SMTP id 21mr111718127qvf.166.1565015315383; Mon, 05 Aug 2019 07:28:35 -0700 (PDT) Received: from sn3rd.lan ([75.102.131.36]) by smtp.gmail.com with ESMTPSA id n184sm34119110qkc.114.2019.08.05.07.28.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 05 Aug 2019 07:28:34 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Sean Turner In-Reply-To: <3DF77ED0-C4EC-479E-84E9-C882CAFE076D@vigilsec.com> Date: Mon, 5 Aug 2019 10:28:33 -0400 Cc: Michael Richardson , LAMPS WG , Benjamin Kaduk Content-Transfer-Encoding: quoted-printable Message-Id: References: <21504.1564174053@dooku.sandelman.ca> <9CE09410-5F6B-407F-B239-888E3136F24A@vigilsec.com> <547B521B-A93B-4E33-96A9-8B2DEE216748@vigilsec.com> <20190731194117.GG1006@kduck.mit.edu> <14050.1564606087@localhost> <0455CEB5-65EF-498C-A5E9-133C6D4226CE@sn3rd.com> <3DF77ED0-C4EC-479E-84E9-C882CAFE076D@vigilsec.com> To: Russ Housley X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [lamps] rfc7030-est clarifications and LAMPS charter X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2019 14:28:39 -0000 It sure couldn=E2=80=99t hurt.=20 spt > On Aug 5, 2019, at 10:01, Russ Housley wrote: >=20 > Sure. That name change works for me. I think adding the module can = only improve interoperability. >=20 > Russ >=20 >=20 >> On Aug 5, 2019, at 7:58 AM, Sean Turner wrote: >>=20 >> I think you have two choices: >>=20 >> 1) Fix the text >> 2) Fix the text and include a module >>=20 >> In either case fixing the text is* : >>=20 >> * This is basically what Russ suggested, but I do not think the name = of the set should imply that the only attributes that can be used are = defined in 7030. Any attribute can be included so I changed = =E2=80=9CAttributesDefinedInRFC7030=E2=80=9D to =E2=80=9CCsrAttrSet=E2=80=9D= . >>=20 >> OLD: >>=20 >> CsrAttrs ::=3D SEQUENCE SIZE (0..MAX) OF AttrOrOID >>=20 >> AttrOrOID ::=3D CHOICE (oid OBJECT IDENTIFIER, attribute Attribute } >>=20 >> Attribute { ATTRIBUTE:IOSet } ::=3D SEQUENCE { >> type ATTRIBUTE.&id({IOSet}), >> values SET SIZE(1..MAX) OF ATTRIBUTE.&Type({IOSet}{@type}) } >>=20 >> NEW: >>=20 >> CsrAttrs ::=3D SEQUENCE SIZE (0..MAX) OF AttrOrOID >>=20 >> AttrOrOID ::=3D CHOICE { >> oid OBJECT IDENTIFIER, >> attribute Attribute {{AttrSet}} } >>=20 >> Attribute { ATTRIBUTE:IOSet } ::=3D SEQUENCE { >> type ATTRIBUTE.&id({IOSet}), >> values SET SIZE(1..MAX) OF ATTRIBUTE.&Type({IOSet}{@type}) } >>=20 >> AttrSet ATTRIBUTE ::=3D { CsrAttrSet } >>=20 >> CsrAttrSet ATTRIBUTE ::=3D { >> aa-asymmDecryptKeyID, -- see Section 4.4.1.2. >> =E2=80=A6 } >>=20 >> spt >>=20 >>=20 >>> On Jul 31, 2019, at 16:48, Michael Richardson = wrote: >>>=20 >>> Signed PGP part >>>=20 >>> Benjamin Kaduk wrote: >>>>> Thinking about this some more, I think that the best way to = resolve >>>>> this errata is to provide an appendix with an ASN.1 module. Here = is >>>>> my suggestion: >>>=20 >>>> That feels somewhat heavyweight for an erratum. What are the = pros/cons >>>> of errata vs. small updating RFC? >>>=20 >>> The intention is to have a small updating RFC. >>>=20 >>> --=20 >>> ] Never tell me the odds! | ipv6 mesh = networks [ >>> ] Michael Richardson, Sandelman Software Works | IoT = architect [ >>> ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on = rails [ >>>=20 >>>=20 >>>=20 >>=20 >> _______________________________________________ >> Spasm mailing list >> Spasm@ietf.org >> https://www.ietf.org/mailman/listinfo/spasm >=20 From nobody Mon Aug 5 08:03:11 2019 Return-Path: X-Original-To: spasm@ietf.org Delivered-To: spasm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 26D31120232; Mon, 5 Aug 2019 08:03:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?=C3=89ric_Vyncke_via_Datatracker?= To: "The IESG" Cc: draft-ietf-lamps-cms-shakes@ietf.org, Russ Housley , lamps-chairs@ietf.org, housley@vigilsec.com, spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.99.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?=C3=89ric_Vyncke?= Message-ID: <156501738314.24515.1427171792378435809.idtracker@ietfa.amsl.com> Date: Mon, 05 Aug 2019 08:03:03 -0700 Archived-At: Subject: [lamps] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-iet?= =?utf-8?q?f-lamps-cms-shakes-15=3A_=28with_COMMENT=29?= X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2019 15:03:04 -0000 Éric Vyncke has entered the following ballot position for draft-ietf-lamps-cms-shakes-15: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-shakes/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for the work put into this document. I second Alexey's DISCUSS that is easy to fix. Regards, -éric == COMMENTS == -- Section 4.1 -- Can you check whether the begin and the end of this section are consistent ? I.e. "id-shake128 and id-shake256 OIDs" vs. "output length of SHA256 or SHAKE256" ? I must admit that my knowledge of crypto is not paramount but I find this weird. -- Section 4.2.1 -- Is there any reason why length are measured in bytes while in other sections it is in bits? Readers can do the math of course but why making the text more complex to parse? == NITS == -- Section 3 -- Why are some object identifier are fully in lowercase and some are a mix of lower and uppercase characters? From nobody Mon Aug 5 11:53:39 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66FC112022D; Mon, 5 Aug 2019 11:53:23 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=cnJPwKDY; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=UhEK6h/C 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 E7Dl1-1C-ACg; Mon, 5 Aug 2019 11:53:21 -0700 (PDT) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5640B1200A3; Mon, 5 Aug 2019 11:53:18 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id 72DDD3C1; Mon, 5 Aug 2019 14:53:17 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Mon, 05 Aug 2019 14:53:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm3; bh=b XhEbqlg6pkbEp0/DDDU0xk+n+D6VFKUCLrrLpEN524=; b=cnJPwKDYUlnLw16Zn VxRn3d4FiuUfhIloh1Q2CzI6onB00GV8xDvBVi8398jUWuep2QIJcT8VcQdfa9pW jtFutcEMVGQ8Rlo+QgLEtEA0tsb26ldv/cveAt284VZRkIIfvmGbXSv1nZo6l+pO yvK5yi+48H6NZqCFXqMjpV03CZjlGji1sqKWhiMUExwU9PAQFB2apjNbTWxKAgVg uubt05FKOYESR4QBsxm0CDPnpTGSJ+IgZ+SvrSc4zoQYtdmtbLwm/ZPExXehFHIP rOOFgG8fCzIddNjEEMQ9rERrJzDldSxz0K5vg203kMdTua/rSNKjhYmjAt8kQrG0 kFbpg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=bXhEbqlg6pkbEp0/DDDU0xk+n+D6VFKUCLrrLpEN5 24=; b=UhEK6h/CC2v2/7dVDQNnw+uTOf/QX/Q+9Ck+pX5g2I7Kt0ALCnejNEzAd 4PQnVRDPYKNaaPsiA7emn7dgIysKq3sP+tP1e/WiVZibPSmlF7jSstJZJBNwVRX5 SVa4yyjqQxDl2LOGPOxL7Ld+yrU6N/3Sf6XMLfPBU1SCHjipap048qmQBUa7hR6X jyf5kX82/fSsfV0lbnOVjqbduQSLHDT1bqejBIhPg1Rhs2LQPv/OFS419gxYNDNs ktLFkHcZT5gIAG5lUECIWDzvn9/xD9mrGF5Mn3QAV5O4H9GzfhRAl5dqdBt6pZ81 goKpssGSVTV7cIADsDxUxGw1svshQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddruddtjedgudeftdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtddvnecuhfhrohhmpeetlhhi shhsrgcuvehoohhpvghruceorghlihhsshgrsegtohhophgvrhifrdhinheqnecuffhomh grihhnpehivghtfhdrohhrghenucfkphepudejfedrfeekrdduudejrdektdenucfrrghr rghmpehmrghilhhfrhhomheprghlihhsshgrsegtohhophgvrhifrdhinhenucevlhhush htvghrufhiiigvpedt X-ME-Proxy: Received: from rtp-alcoop-nitro2.cisco.com (unknown [173.38.117.80]) by mail.messagingengine.com (Postfix) with ESMTPA id 56028380083; Mon, 5 Aug 2019 14:53:16 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Alissa Cooper In-Reply-To: <156113105092.16969.17846588336503024855@ietfa.amsl.com> Date: Mon, 5 Aug 2019 14:53:14 -0400 Cc: Gen art , spasm@ietf.org, draft-ietf-lamps-cms-shakes.all@ietf.org, ietf@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <156113105092.16969.17846588336503024855@ietfa.amsl.com> To: Vijay Gurbani X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lamps] [Gen-art] Genart last call review of draft-ietf-lamps-cms-shakes-11 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2019 18:53:24 -0000 Vijay, thanks for your review. I entered a No Objection ballot. Alissa > On Jun 21, 2019, at 11:30 AM, Vijay Gurbani via Datatracker = wrote: >=20 > Reviewer: Vijay Gurbani > Review result: Ready >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-lamps-cms-shakes-?? > Reviewer: Vijay K. Gurbani > Review Date: 2019-06-21 > IETF LC End Date: 2019-07-03 > IESG Telechat date: Not scheduled for a telechat >=20 > Summary: This draft is ready for publication as a standards track = document. >=20 > Major issues: 0 >=20 > Minor issues: 0 >=20 > Nits/editorial comments: 0 >=20 >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Tue Aug 6 13:59:22 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E928512007A for ; Tue, 6 Aug 2019 13:59:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 wuZZ72QGk4nn for ; Tue, 6 Aug 2019 13:59:19 -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 D09C712006A for ; Tue, 6 Aug 2019 13:59:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id BFA8A300AE2 for ; Tue, 6 Aug 2019 16:40:00 -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 ZJHJMBAtTpm8 for ; Tue, 6 Aug 2019 16:39:58 -0400 (EDT) Received: from a860b60074bd.fios-router.home (unknown [138.88.156.37]) by mail.smeinc.net (Postfix) with ESMTPSA id 354D330065E; Tue, 6 Aug 2019 16:39:58 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Russ Housley In-Reply-To: <156450924572.14301.5205142476827606126@ietfa.amsl.com> Date: Tue, 6 Aug 2019 16:59:15 -0400 Cc: IETF Gen-ART , LAMPS WG , IETF Content-Transfer-Encoding: quoted-printable Message-Id: <3FB53255-8CAD-4A76-B264-78AA447EFD0B@vigilsec.com> References: <156450924572.14301.5205142476827606126@ietfa.amsl.com> To: Robert Sparks X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [lamps] Genart last call review of draft-ietf-lamps-cms-mix-with-psk-05 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2019 20:59:21 -0000 Robert: > Reviewer: Robert Sparks > Review result: Ready with Issues >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-lamps-cms-mix-with-psk-05 > Reviewer: Robert Sparks > Review Date: 2019-07-30 > IETF LC End Date: 2019-08-06 > IESG Telechat date: Not scheduled for a telechat >=20 > Summary: Essentially ready for publication as a Proposed Standard, but = with an > issue to address before publication. >=20 > Issue: The instructions for IANA are unclear. IANA has to infer what = to add to > the registries. I think they _can_ infer what to do for the IANA-MOD = registry. > It's harder (though still possible) to guess what to do for = IANA-SMIME. They > also have to infer the structure of the new registry this document = intends to > create. Explicit would be better. Also, the document anticipates the = currently > non-existing anchor to the new registry in the references = (security-smime-13). > That generally should also be a tbd to be filled by IANA when the = anchor is > actually created. Based on the summary of actions that IANA produced during Last Call, = they understood the current text. That said, I will try to be more = clear. One object identifier for the ASN.1 module in the Section 5 was assigned in the SMI Security for S/MIME Module Identifiers (1.2.840.113549.1.9.16.0) [IANA-MOD] registry: id-mod-cms-ori-psk-2019 OBJECT IDENTIFIER ::=3D { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) mod(0) TBD0 } One new registry was created for Other Recipient Info Identifiers within the SMI Security for S/MIME Mail Security (1.2.840.113549.1.9.16) [IANA-SMIME] registry: id-ori OBJECT IDENTIFIER ::=3D { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) TBD1 } Two assignments were made in the new SMI Security for Other Recipient Info Identifiers (1.2.840.113549.1.9.16.TBD1) [IANA-ORI] registry with references to this document: id-ori-keyTransPSK OBJECT IDENTIFIER ::=3D { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-ori(TBD1) 1 } id-ori-keyAgreePSK OBJECT IDENTIFIER ::=3D { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-ori(TBD1) 2 } I have changed the reference to #security-smime-TBD1, which matches the = to-be-assigned value in the IANA Considerations. > Nits/editorial comments: >=20 > Section 5, 1st paragraph, last sentence: "make use fo" should be = "makes use of" Yes. That was caught by another review. Already corrected. > Section 9, 1st sentence : "in the Section 5" should be "in Section 6". = (That's > two changes - the removal of a word, and a correction to the section = number). Good catch. Fixed. > Micronit: In the introduction, you say "can be invulnerable to an = attacker". > "invulnerable" is maybe stronger than you mean? Roman thought that was too strong as well, I suggest: ... In this way, today's CMS-protected communication can be resistant to an attacker with a large-scale quantum computer. Thanks for the vaery careful reading, Russ From nobody Tue Aug 6 14:04:28 2019 Return-Path: X-Original-To: spasm@ietf.org Delivered-To: spasm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E8F1712006A; Tue, 6 Aug 2019 14:04:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spasm@ietf.org Message-ID: <156512546587.27392.1823143220913300105@ietfa.amsl.com> Date: Tue, 06 Aug 2019 14:04:25 -0700 Archived-At: Subject: [lamps] I-D Action: draft-ietf-lamps-cms-mix-with-psk-06.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2019 21:04:26 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Limited Additional Mechanisms for PKIX and SMIME WG of the IETF. Title : Using Pre-Shared Key (PSK) in the Cryptographic Message Syntax (CMS) Author : Russ Housley Filename : draft-ietf-lamps-cms-mix-with-psk-06.txt Pages : 30 Date : 2019-08-06 Abstract: The invention of a large-scale quantum computer would pose a serious challenge for the cryptographic algorithms that are widely deployed today. The Cryptographic Message Syntax (CMS) supports key transport and key agreement algorithms that could be broken by the invention of such a quantum computer. By storing communications that are protected with the CMS today, someone could decrypt them in the future when a large-scale quantum computer becomes available. Once quantum-secure key management algorithms are available, the CMS will be extended to support the new algorithms, if the existing syntax does not accommodate them. In the near-term, this document describes a mechanism to protect today's communication from the future invention of a large-scale quantum computer by mixing the output of key transport and key agreement algorithms with a pre-shared key. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-mix-with-psk/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lamps-cms-mix-with-psk-06 https://datatracker.ietf.org/doc/html/draft-ietf-lamps-cms-mix-with-psk-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-cms-mix-with-psk-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Aug 6 14:12:23 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9350F12006A for ; Tue, 6 Aug 2019 14:12:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 4XaFt8mio84s for ; Tue, 6 Aug 2019 14:12:20 -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 E0B7A120033 for ; Tue, 6 Aug 2019 14:12:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 097CE300AAF for ; Tue, 6 Aug 2019 16:53:02 -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 eiMJbOhzHa_Q for ; Tue, 6 Aug 2019 16:53:00 -0400 (EDT) Received: from a860b60074bd.fios-router.home (unknown [138.88.156.37]) by mail.smeinc.net (Postfix) with ESMTPSA id 9F26130065E for ; Tue, 6 Aug 2019 16:53:00 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 6 Aug 2019 17:12:17 -0400 References: <156512546616.27392.11574912416324243112.idtracker@ietfa.amsl.com> To: LAMPS WG In-Reply-To: <156512546616.27392.11574912416324243112.idtracker@ietfa.amsl.com> Message-Id: <064E2F31-FFF1-44C1-BC87-CC70FDA48FC2@vigilsec.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [lamps] New Version Notification for draft-ietf-lamps-cms-mix-with-psk-06.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2019 21:12:22 -0000 This revision addresses the AD review comments and the IETF Last Call = comments. If you are implementing, please note the correction in the ASN.1 module. = Thanks for catching that Jim. Russ > On Aug 6, 2019, at 5:04 PM, internet-drafts@ietf.org wrote: >=20 >=20 > A new version of I-D, draft-ietf-lamps-cms-mix-with-psk-06.txt > has been successfully submitted by Russ Housley and posted to the > IETF repository. >=20 > Name: draft-ietf-lamps-cms-mix-with-psk > Revision: 06 > Title: Using Pre-Shared Key (PSK) in the Cryptographic = Message Syntax (CMS) > Document date: 2019-08-06 > Group: lamps > Pages: 30 > URL: = https://www.ietf.org/internet-drafts/draft-ietf-lamps-cms-mix-with-psk-06.= txt > Status: = https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-mix-with-psk/ > Htmlized: = https://tools.ietf.org/html/draft-ietf-lamps-cms-mix-with-psk-06 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-ietf-lamps-cms-mix-with-psk > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lamps-cms-mix-with-psk-06 >=20 > Abstract: > The invention of a large-scale quantum computer would pose a serious > challenge for the cryptographic algorithms that are widely deployed > today. The Cryptographic Message Syntax (CMS) supports key = transport > and key agreement algorithms that could be broken by the invention = of > such a quantum computer. By storing communications that are > protected with the CMS today, someone could decrypt them in the > future when a large-scale quantum computer becomes available. Once > quantum-secure key management algorithms are available, the CMS will > be extended to support the new algorithms, if the existing syntax > does not accommodate them. In the near-term, this document = describes > a mechanism to protect today's communication from the future > invention of a large-scale quantum computer by mixing the output of > key transport and key agreement algorithms with a pre-shared key. From nobody Wed Aug 7 13:51:29 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55A15120116; Wed, 7 Aug 2019 13:51:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=V4HMdMGZ; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=WyX4nj49 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 ZH8seyFiY0nu; Wed, 7 Aug 2019 13:51:10 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4ADBF120059; Wed, 7 Aug 2019 13:51:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4750; q=dns/txt; s=iport; t=1565211070; x=1566420670; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=451r10wqkjFhOl0q3R0VElzp1EDh7OEv809kwrdU+JU=; b=V4HMdMGZrHXWVHBHPFdL6qnWW04ljTxNwUE9Pv960YXLghkuE6KQryKy heiqh8+grtiq5jXOhXitI8X5ZE/YKOjecMkR80Lm2xtegQ7xhrutqMFvo z+PxATfYSOozDSYHV22kiX3XCe4LPjz2zqILlv/HVm1g67AdcAbTMezzM k=; IronPort-PHdr: =?us-ascii?q?9a23=3AZQFRuxUQ6Cqe8DvGVr5sB5gfNQvV8LGuZFwc94?= =?us-ascii?q?YnhrRSc6+q45XlOgnF6O5wiEPSA9yJ8OpK3uzRta2oGXcN55qMqjgjSNRNTF?= =?us-ascii?q?dE7KdehAk8GIiAAEz/IuTtankiH81HTFZj9lmwMFNeH4D1YFiB6nA=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AIAADeOEtd/4kNJK1mGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUwUBAQEBCwGBRFADbVUgBAsqhB6DRwOEUoZggluXXYEuFIE?= =?us-ascii?q?QA1QJAQEBDAEBGAsKAgEBhD8CF4I7IzQJDgEEAQEEAQEDAQpthScMhUoBAQE?= =?us-ascii?q?BAwEBEBERDAEBLAsBCwQCAQgRBAEBAwImAgICJQsVBQMIAgQBDQUIGoMBgWo?= =?us-ascii?q?DHQECDKBIAoE4iGBxgTKCegEBBYFHQYMLGIIUAwaBDCgBhHKFLoFDF4FAP4E?= =?us-ascii?q?RRoJMPoJhAQEBAgGBKgESASEVgnQygiaMNYJWnCUJAoIchl2NYYIwhy6OVIM?= =?us-ascii?q?riiKBNIYmkBoCBAIEBQIOAQEFgVA4Z1gRCHAVO4JsgkIJAxcUgzqFFIU/cgG?= =?us-ascii?q?BKIs1gkMBAQ?= X-IronPort-AV: E=Sophos;i="5.64,358,1559520000"; d="scan'208";a="615968958" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 07 Aug 2019 20:51:09 +0000 Received: from XCH-ALN-019.cisco.com (xch-aln-019.cisco.com [173.36.7.29]) by alln-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id x77Kp9nA032097 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 7 Aug 2019 20:51:09 GMT Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-ALN-019.cisco.com (173.36.7.29) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 7 Aug 2019 15:51:08 -0500 Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 7 Aug 2019 15:51:08 -0500 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 7 Aug 2019 16:51:08 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Tz/ui5WUjqTCrAhT3sCZx540zxC4CnUIRiUaWhC5nkkA5Y5n7OJLMr3Wo05S0avSb0MWCdCoGhl0vCSxDtv7TG/ggsGeS3ZT1dHPsylZMtdTZFp3/11bM0gEWzbeg2EVT0wzUPicfh/+phct30pMqovOhVWn80ryKED4SSugty2DpbO1Dc0uv0iQLFLLt0KVZBQ7HlzymSVQyAGJAnc98m/188ri6mYemrKOfG6j+0MGXeHtubIzYbw1pDYiUZbwsboTo8DEPVB7VtMVQAin3k7HAzbDCLK/8GHQ4OND6brr+DjqiO4hMUT3SsVQp6qknPT3oRZs+IRWBBWmWC2D6g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=451r10wqkjFhOl0q3R0VElzp1EDh7OEv809kwrdU+JU=; b=IY0ks8+O8eUPXgqX0lk22cxUYfwysintCMFi7jBJ+BCCmO7NMGixHAvhA4wzgr0/H58SngK46790qpL2MCEBzBFNeJlO3qAqJjlzD+561B2Y8BCIMXdhy5aLc+9APbA7oiaZ9qRNMaC3ebf+8zC+DdQWKfFU/IkNQqXESguI8T4XWhZtJJ5VltJ5ZsgLila1WldcwNzPf6IYS+MY7jEPMCbwOQ5ZuezTNnkkU0CBEE/EET7Ou0Tk4aX5jkpTtE8v8ukq038Q6FW8liSs/DeQbLeNLRvemquv+nByZs6z0Te3rQ5deVr/rMbps5xiA4fyzWBOrI4TbRMym+xvFObVvQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=451r10wqkjFhOl0q3R0VElzp1EDh7OEv809kwrdU+JU=; b=WyX4nj49LG0r9n7SrpvRSyXf7Q2gRfTBY7vmYDxy/5cnRbLsKZ5KSR7vsuPc4MKD4+wUJHR5Wbi5ejweK7FqNS2lZeEcM1MjhwIkPS9khbPX07uCMq+yRJps+Uyl76X/bMQ/0l3429w8zCECge4Li2H1d4XS2+wAhswYVYZHdc8= Received: from BN7PR11MB2547.namprd11.prod.outlook.com (52.135.255.146) by BN7PR11MB2865.namprd11.prod.outlook.com (52.135.254.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2157.15; Wed, 7 Aug 2019 20:51:06 +0000 Received: from BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::a4d7:5299:601e:53cd]) by BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::a4d7:5299:601e:53cd%7]) with mapi id 15.20.2157.015; Wed, 7 Aug 2019 20:51:06 +0000 From: "Panos Kampanakis (pkampana)" To: "Eric Vyncke (evyncke)" , The IESG CC: "draft-ietf-lamps-cms-shakes@ietf.org" , "lamps-chairs@ietf.org" , "spasm@ietf.org" , "housley@vigilsec.com" Thread-Topic: =?utf-8?B?W2xhbXBzXSDDiXJpYyBWeW5ja2UncyBObyBPYmplY3Rpb24gb24gZHJhZnQt?= =?utf-8?Q?ietf-lamps-cms-shakes-15:_(with_COMMENT)?= Thread-Index: AQHVS570bQ+RBkMFBkCVe5Konr6UH6bwFsLA Date: Wed, 7 Aug 2019 20:51:06 +0000 Message-ID: References: <156501738314.24515.1427171792378435809.idtracker@ietfa.amsl.com> In-Reply-To: <156501738314.24515.1427171792378435809.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pkampana@cisco.com; x-originating-ip: [2001:420:c0c4:1001::73] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4320ac1b-73d3-4974-5c39-08d71b78f81f x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BN7PR11MB2865; x-ms-traffictypediagnostic: BN7PR11MB2865: x-ms-exchange-purlcount: 3 x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 01221E3973 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(376002)(366004)(346002)(136003)(396003)(189003)(13464003)(199004)(305945005)(224303003)(7736002)(74316002)(71200400001)(71190400001)(86362001)(66574012)(14454004)(966005)(478600001)(110136005)(6116002)(486006)(2906002)(5660300002)(76116006)(66946007)(66556008)(64756008)(66446008)(99286004)(53546011)(6506007)(52536014)(11346002)(446003)(25786009)(316002)(54906003)(102836004)(76176011)(476003)(7696005)(6436002)(6246003)(229853002)(55016002)(6306002)(53936002)(81156014)(81166006)(4326008)(33656002)(186003)(8936002)(14444005)(256004)(46003)(9686003)(66476007); DIR:OUT; SFP:1101; SCL:1; SRVR:BN7PR11MB2865; H:BN7PR11MB2547.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: l7PXwc2gYd/5cRGiGCI3LvtCvpqJuM/a9LhtPGfAowv5p/8QBU8Z9twcrTj0hmQu6i0wJse2E5B3miMMEwcE1QMCKqMVftBRNMunNlhFHyRlX0oEw6zd9bVqephYXmwulzy68ZD0w9am8qMNOw+XyRcLnwPoS9G6B3+mPnv8zJTfXHr5VWRxGy7DWFlFpPgB7675IyNeM7aqtRJtqftlIcmbYPchcd+/SdHn638AzHzecUdsbrlL/FwdW2v+0xrziUdlzEU98xOsYUnPI8fUnFFWVik0TJkMhzbjnD6OxVvy+4SF9fDw+mibD6NpjGuj4CDDeSOJ6d4jB2IfElc5jO/w8VZ4WV1IuYmBBI3G4IIaVRU4wse3TDH5aTMDAlD0WPdna4mFg5DTTp29y57Lf5BgxBOqxl3RxfRF6TvSpOI= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 4320ac1b-73d3-4974-5c39-08d71b78f81f X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Aug 2019 20:51:06.7985 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: HdJd9j3d34S48asBIc5H2jIFFXE9O+zWjNIhuMFieefZ0R0cjjo+tGbqQr3jX3eB7S3GsSX5du2jk+u5nXjQ7g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2865 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.29, xch-aln-019.cisco.com X-Outbound-Node: alln-core-4.cisco.com Archived-At: Subject: Re: [lamps] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-iet?= =?utf-8?q?f-lamps-cms-shakes-15=3A_=28with_COMMENT=29?= X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2019 20:51:13 -0000 SGVsbG8gRXJpYywgQWxleGV5LCANCg0KVG8gdHJ5IHRvIGFkZHJlc3MgdGhlIHF1ZXN0aW9ucw0K DQo+IC0tIFNlY3Rpb24gNC4xIC0tDQo+IENhbiB5b3UgY2hlY2sgd2hldGhlciB0aGUgYmVnaW4g YW5kIHRoZSBlbmQgb2YgdGhpcyBzZWN0aW9uIGFyZSBjb25zaXN0ZW50ID8NCj4gSS5lLiAiaWQt c2hha2UxMjggYW5kIGlkLXNoYWtlMjU2IE9JRHMiIHZzLiAib3V0cHV0IGxlbmd0aCBvZiBTSEEy NTYgb3IgU0hBS0UyNTYiID8gSSBtdXN0IGFkbWl0IHRoYXQgbXkga25vd2xlZGdlIG9mIGNyeXB0 byBpcyBub3QgcGFyYW1vdW50IGJ1dCBJIGZpbmQgdGhpcyB3ZWlyZC4NCg0KR29vZCBjYXRjaC4g VGhpcyB3YXMgYSBuaXQuIEl0IG5vdyByZWFkcyAibGVuZ3RoIG9mIFNIQUtFMTI4IG9yIFNIQUtF MjU2Li4uIg0KDQo+IC0tIFNlY3Rpb24gNC4yLjEgLS0NCj4gSXMgdGhlcmUgYW55IHJlYXNvbiB3 aHkgbGVuZ3RoIGFyZSBtZWFzdXJlZCBpbiBieXRlcyB3aGlsZSBpbiBvdGhlciBzZWN0aW9ucyBp dCBpcyBpbiBiaXRzPyBSZWFkZXJzIGNhbiBkbyB0aGUgbWF0aCBvZiBjb3Vyc2UgYnV0IHdoeSBt YWtpbmcgdGhlIHRleHQgbW9yZSBjb21wbGV4IHRvIHBhcnNlPw0KDQpXaGVuIHdlIGFyZSBkZWFs aW5nIHdpdGggUlNBIGFuZCBLTUFDcyB3ZSBoYWQgdG8ga2VlcCBvdXRwdXQgbGVuZ3RoIGluIGJp dHMgYmVjYXVzZSB0aGF0IGlzIGhvdyB0aGV5IGFyZSBkZWZpbmVkIGluIHRoZXNlIHN0YW5kYXJk cywgc28gaXQgd291bGQgYmUgY29uZnVzaW5nIGZvciBpbXBsZW1lbnRlcnMgdG8gY29udmVydCB0 aGUgb3V0cHV0IHNpemVzIGZvciB0aGVzZSBhbGdvcml0aG1zLiBIYXZpbmcgc2FpZCB0aGF0IEkg Zm91bmQgMyBwbGFjZXMgd2hlcmUgSSBjaGFuZ2VkIGZyb20gYml0cyB0byBieXRlcyB3aGVuIHRh bGtpbmcgYWJvdXQgU0hBS0Ugb3V0cHV0IGxlbmd0aHMgZm9yIGNvbnNpc3RlbmN5LiANCg0KPiAt LSBTZWN0aW9uIDMgLS0NCj4gV2h5IGFyZSBzb21lIG9iamVjdCBpZGVudGlmaWVyIGFyZSBmdWxs eSBpbiBsb3dlcmNhc2UgYW5kIHNvbWUgYXJlIGEgbWl4IG9mIGxvd2VyIGFuZCB1cHBlcmNhc2Ug Y2hhcmFjdGVycz8NCg0KVGhlIFJTQVNTQS1QU1MgT0lEcyBrZXB0IFNIQUtFIGluIGNhcGl0YWxz IGJlY2F1c2UgaXQgc2VlbWVkIHVubmF0dXJhbCB0byBwdXQgaXQgbG93ZXJjYXNlIGFmdGVyIHRo ZSBjYXBpdGFscyBvZiBSU0FTU0EtUFNTLiBGb3IgZWNkc2Egd2Uga2VwdCBpdCBsb3dlcmNhc2Ug YmVjYXVzZSB0aGF0IGlzIGhvdyB0aGUgT0lEcyBsb29rZWQgaW4gdGhlIHBhc3QgZm9yIGVjZHNh LXNoYTIgT0lEcy4gSXQgaXMgYSBsaXR0bGUgYXJiaXRyYXJ5LCBidXQgdGhhdCBpcyB3aHkgd2Ug bWFkZSB0aGVtIGxvb2sgbGlrZSB0aGF0Lg0KDQpJIHdpbGwgdXBkYXRlIHRoZSBjaGFuZ2VzIHRv IHRoZXNlIG1pbm9yIGlzc3VlIHByZXR0eSBzb29uLiANCg0KVGhhbmtzLA0KUGFub3MgDQoNCg0K DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogU3Bhc20gPHNwYXNtLWJvdW5jZXNA aWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiDDiXJpYyBWeW5ja2UgdmlhIERhdGF0cmFja2VyDQpTZW50 OiBNb25kYXksIEF1Z3VzdCAwNSwgMjAxOSAxMTowMyBBTQ0KVG86IFRoZSBJRVNHIDxpZXNnQGll dGYub3JnPg0KQ2M6IGRyYWZ0LWlldGYtbGFtcHMtY21zLXNoYWtlc0BpZXRmLm9yZzsgbGFtcHMt Y2hhaXJzQGlldGYub3JnOyBzcGFzbUBpZXRmLm9yZzsgaG91c2xleUB2aWdpbHNlYy5jb20NClN1 YmplY3Q6IFtsYW1wc10gw4lyaWMgVnluY2tlJ3MgTm8gT2JqZWN0aW9uIG9uIGRyYWZ0LWlldGYt bGFtcHMtY21zLXNoYWtlcy0xNTogKHdpdGggQ09NTUVOVCkNCg0Kw4lyaWMgVnluY2tlIGhhcyBl bnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcg0KZHJhZnQtaWV0Zi1sYW1w cy1jbXMtc2hha2VzLTE1OiBObyBPYmplY3Rpb24NCg0KV2hlbiByZXNwb25kaW5nLCBwbGVhc2Ug a2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFjdCBhbmQgcmVwbHkgdG8gYWxsIGVtYWlsIGFkZHJl c3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlIHRvIGN1dCB0 aGlzIGludHJvZHVjdG9yeSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0KDQoNClBsZWFzZSByZWZlciB0 byBodHRwczovL3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9kaXNjdXNzLWNyaXRlcmlhLmh0 bWwNCmZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IElFU0cgRElTQ1VTUyBhbmQgQ09NTUVOVCBw b3NpdGlvbnMuDQoNCg0KVGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBwb3Np dGlvbnMsIGNhbiBiZSBmb3VuZCBoZXJlOg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtaWV0Zi1sYW1wcy1jbXMtc2hha2VzLw0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KQ09N TUVOVDoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KDQpUaGFuayB5b3UgZm9yIHRoZSB3b3JrIHB1dCBpbnRv IHRoaXMgZG9jdW1lbnQuIEkgc2Vjb25kIEFsZXhleSdzIERJU0NVU1MgdGhhdCBpcyBlYXN5IHRv IGZpeC4NCg0KUmVnYXJkcywNCg0KLcOpcmljDQoNCj09IENPTU1FTlRTID09DQoNCi0tIFNlY3Rp b24gNC4xIC0tDQoNCkNhbiB5b3UgY2hlY2sgd2hldGhlciB0aGUgYmVnaW4gYW5kIHRoZSBlbmQg b2YgdGhpcyBzZWN0aW9uIGFyZSBjb25zaXN0ZW50ID8NCkkuZS4gImlkLXNoYWtlMTI4IGFuZCBp ZC1zaGFrZTI1NiBPSURzIiB2cy4gIm91dHB1dCBsZW5ndGggb2YgU0hBMjU2IG9yIFNIQUtFMjU2 IiA/IEkgbXVzdCBhZG1pdCB0aGF0IG15IGtub3dsZWRnZSBvZiBjcnlwdG8gaXMgbm90IHBhcmFt b3VudCBidXQgSSBmaW5kIHRoaXMgd2VpcmQuDQoNCi0tIFNlY3Rpb24gNC4yLjEgLS0NCg0KSXMg dGhlcmUgYW55IHJlYXNvbiB3aHkgbGVuZ3RoIGFyZSBtZWFzdXJlZCBpbiBieXRlcyB3aGlsZSBp biBvdGhlciBzZWN0aW9ucyBpdCBpcyBpbiBiaXRzPyBSZWFkZXJzIGNhbiBkbyB0aGUgbWF0aCBv ZiBjb3Vyc2UgYnV0IHdoeSBtYWtpbmcgdGhlIHRleHQgbW9yZSBjb21wbGV4IHRvIHBhcnNlPw0K DQo9PSBOSVRTID09DQoNCi0tIFNlY3Rpb24gMyAtLQ0KDQpXaHkgYXJlIHNvbWUgb2JqZWN0IGlk ZW50aWZpZXIgYXJlIGZ1bGx5IGluIGxvd2VyY2FzZSBhbmQgc29tZSBhcmUgYSBtaXggb2YgbG93 ZXIgYW5kIHVwcGVyY2FzZSBjaGFyYWN0ZXJzPw0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQpTcGFzbSBtYWlsaW5nIGxpc3QNClNwYXNtQGlldGYu b3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwYXNtDQo= From nobody Wed Aug 7 20:23:40 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87549120094 for ; Wed, 7 Aug 2019 20:23:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ZFa6JKdEPsKz for ; Wed, 7 Aug 2019 20:23:36 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72601120033 for ; Wed, 7 Aug 2019 20:23:36 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 7 Aug 2019 20:22:51 -0700 From: Jim Schaad To: 'Michael Richardson' , 'Russ Housley' CC: 'LAMPS WG' References: <13908.1564606053@localhost> <32761.1564622701@localhost> In-Reply-To: <32761.1564622701@localhost> Date: Wed, 7 Aug 2019 20:22:48 -0700 Message-ID: <005b01d54d98$8fcd93c0$af68bb40$@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: AQKOYeaY1WZie7uRfI3wjvv1nDlyRgHXGrlUAe6BCe+lYEAnIA== Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [lamps] rfc7030-est clarifications of ASN.1 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2019 03:23:38 -0000 Michael, If you tried to learn it back that far, I don't think that it was even part of the language at that point in time. Just a quick note on the module that Russ provided. The import for the CMS module is incorrect. It should be: FROM CryptographicMessageSyntax-2010 -- [RFC6268] { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) id-mod-cms-2009(58) } jim -----Original Message----- From: Spasm On Behalf Of Michael Richardson Sent: Wednesday, July 31, 2019 6:25 PM To: Russ Housley Cc: LAMPS WG Subject: Re: [lamps] rfc7030-est clarifications of ASN.1 Russ Housley wrote: >> I think this is not real ASN.1 syntax, but rather an indication for me >> to insert more stuff? Or is this something real that I don't >> understand. > No, this is real ASN.1 syntax. okay. It's something I once tried to learn, back in 1995, and I got as far as the trivial stuff, but that was all. I will incorporate your module into the clarifications document. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- From nobody Wed Aug 7 21:03:15 2019 Return-Path: X-Original-To: spasm@ietf.org Delivered-To: spasm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D00CA12000E; Wed, 7 Aug 2019 21:03:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spasm@ietf.org Message-ID: <156523699377.8450.9646748217461098848@ietfa.amsl.com> Date: Wed, 07 Aug 2019 21:03:13 -0700 Archived-At: Subject: [lamps] I-D Action: draft-ietf-lamps-cms-shakes-16.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2019 04:03:14 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Limited Additional Mechanisms for PKIX and SMIME WG of the IETF. Title : Use of the SHAKE One-way Hash Functions in the Cryptographic Message Syntax (CMS) Authors : Panos Kampanakis Quynh Dang Filename : draft-ietf-lamps-cms-shakes-16.txt Pages : 18 Date : 2019-08-07 Abstract: This document updates the "Cryptographic Message Syntax Algorithms" (RFC3370) and describes the conventions for using the SHAKE family of hash functions in the Cryptographic Message Syntax as one-way hash functions with the RSA Probabilistic signature and ECDSA signature algorithms. The conventions for the associated signer public keys in CMS are also described. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-shakes/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lamps-cms-shakes-16 https://datatracker.ietf.org/doc/html/draft-ietf-lamps-cms-shakes-16 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-cms-shakes-16 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Aug 7 21:50:50 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A21491206EC; Wed, 7 Aug 2019 21:50:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.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 ux_SVYNdKBwI; Wed, 7 Aug 2019 21:50:41 -0700 (PDT) Received: from taper.sei.cmu.edu (taper.sei.cmu.edu [147.72.252.16]) (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 7F5671200BA; Wed, 7 Aug 2019 21:50:41 -0700 (PDT) Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x784objl030517; Thu, 8 Aug 2019 00:50:37 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu x784objl030517 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1565239837; bh=kyCT1c22d7uVLTyTxPEwPUdGs9cY9hSL3oZhxo5Wzik=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=LpBFK8JeH8TESTC+NKGJUzaXrY6treLsnYUeXVbFqfy3xK4ifu1NPLFCYuASOg9GR Tq/nDI46ux3N9wxolqwrn/ltV4dW2O4vlYirVqv+E8xIW954uIBONo+tMbV+HZeZVN tzIoStrHFui1a/+H2EWyes1i5KJokTrmQnYorN30= Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x784oYlo029218; Thu, 8 Aug 2019 00:50:34 -0400 Received: from MARCHAND.ad.sei.cmu.edu ([10.64.28.251]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.03.0439.000; Thu, 8 Aug 2019 00:50:34 -0400 From: Roman Danyliw To: Alexey Melnikov , The IESG CC: "draft-ietf-lamps-cms-shakes@ietf.org" , "lamps-chairs@ietf.org" , "spasm@ietf.org" , "housley@vigilsec.com" Thread-Topic: Alexey Melnikov's Discuss on draft-ietf-lamps-cms-shakes-15: (with DISCUSS) Thread-Index: AQHVSchz8oL0fspzZEem3qSCsBcW26bws2CA Date: Thu, 8 Aug 2019 04:50:33 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC01B3400EB1@marchand> References: <156481532800.6108.1633834009578124669.idtracker@ietfa.amsl.com> In-Reply-To: <156481532800.6108.1633834009578124669.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [lamps] Alexey Melnikov's Discuss on draft-ietf-lamps-cms-shakes-15: (with DISCUSS) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2019 04:50:48 -0000 DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogaWVzZyBbbWFpbHRvOmll c2ctYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFsZXhleSBNZWxuaWtvdiB2aWENCj4g RGF0YXRyYWNrZXINCj4gU2VudDogU2F0dXJkYXksIEF1Z3VzdCAzLCAyMDE5IDI6NTUgQU0NCj4g VG86IFRoZSBJRVNHIDxpZXNnQGlldGYub3JnPg0KPiBDYzogZHJhZnQtaWV0Zi1sYW1wcy1jbXMt c2hha2VzQGlldGYub3JnOyBsYW1wcy1jaGFpcnNAaWV0Zi5vcmc7DQo+IHNwYXNtQGlldGYub3Jn OyBob3VzbGV5QHZpZ2lsc2VjLmNvbQ0KPiBTdWJqZWN0OiBBbGV4ZXkgTWVsbmlrb3YncyBEaXNj dXNzIG9uIGRyYWZ0LWlldGYtbGFtcHMtY21zLXNoYWtlcy0xNTogKHdpdGgNCj4gRElTQ1VTUykN Cj4gDQo+IEFsZXhleSBNZWxuaWtvdiBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBw b3NpdGlvbiBmb3INCj4gZHJhZnQtaWV0Zi1sYW1wcy1jbXMtc2hha2VzLTE1OiBEaXNjdXNzDQo+ IA0KPiBXaGVuIHJlc3BvbmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUgaW50YWN0 IGFuZCByZXBseSB0byBhbGwgZW1haWwNCj4gYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBh bmQgQ0MgbGluZXMuIChGZWVsIGZyZWUgdG8gY3V0IHRoaXMgaW50cm9kdWN0b3J5DQo+IHBhcmFn cmFwaCwgaG93ZXZlci4pDQo+IA0KPiANCj4gUGxlYXNlIHJlZmVyIHRvIGh0dHBzOi8vd3d3Lmll dGYub3JnL2llc2cvc3RhdGVtZW50L2Rpc2N1c3MtY3JpdGVyaWEuaHRtbA0KPiBmb3IgbW9yZSBp bmZvcm1hdGlvbiBhYm91dCBJRVNHIERJU0NVU1MgYW5kIENPTU1FTlQgcG9zaXRpb25zLg0KPiAN Cj4gDQo+IFRoZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBj YW4gYmUgZm91bmQgaGVyZToNCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtaWV0Zi1sYW1wcy1jbXMtc2hha2VzLw0KPiANCj4gDQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ IERJU0NVU1M6DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gDQo+IFRoaXMgaXMgYSBmaW5lIGRvY3VtZW50 LCBidXQgSSBoYXZlIG9uZSBxdWljayBxdWVzdGlvbjoNCj4gDQo+IFZhbHVlcyBUQkQxLi5UQkQ0 IGFyZSBub3QgbGlzdGVkIGluIHRoZSBJQU5BIENvbnNpZGVyYXRpb25zIHNlY3Rpb24uIFNob3Vs ZA0KPiB0aGV5IGJlPw0KDQpJIGRvbid0IHRoaW5rIHNvLiAgVGhpcyBkb2N1bWVudCBhbmQgZHJh ZnQtaWV0Zi1sYW1wcy1wa2l4LXNoYWtlcyBib3RoIG5lZWQgdGhlIHNhbWUgT0lEcyAoYnV0IGhh dmUgbm8gb3RoZXIgZGVwZW5kZW5jZSkuICBUaGlzIGxhdHRlciBkcmFmdCBpcyB3aXRoIHRoZSBS RkMgRWRpdG9yIGFuZCBkb2VzIHJlZ2lzdGVyIHRoZXNlIE9JRHMuICBUaGUgY3VycmVudCB0ZXh0 LCAiW0ktRC5pZXRmLWxhbXBzLXBraXgtc2hha2VdIFsgRUROT1RFOiBVcGRhdGUgcmVmZXJlbmNl IHdpdGggdGhlIFJGQyB3aGVuIGl0IGlzIHJlYWR5IF0iLCB3YXMgaW50ZW5kZWQgdG8gZ3VpZGUg dGhlIGVkaXRvciB0byByZXBsYWNlIFRCRDEtNCB0aGUgT0lEcyB3aGVuIGlldGYtbGFtcHMtcGtp eC1zaGFrZSBnb3QgcHVibGlzaGVkLiAgSG93ZXZlciwgaW4gcmUtcmVhZGluZyB0aGUgdGV4dCBu b3csIHRoZSBFRE5PVEUgc2hvdWxkIGFjdHVhbGx5IHJlYWQgIlVwZGF0ZWQgdGhlIFRCRDEtMiBy ZWZlcmVuY2Ugd2hlbiB0aGUgUkZDIGlzIHB1Ymxpc2hlZCIuDQoNCk1ha2Ugc2Vuc2U/DQoNClJv bWFuDQogDQoNCg== From nobody Thu Aug 8 05:31:19 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AECB1202E2; Thu, 8 Aug 2019 05:31:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=mCD0SoA2; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Bq8WMaXv 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 T1oN6It75UF5; Thu, 8 Aug 2019 05:31:02 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30B071202AD; Thu, 8 Aug 2019 05:31:02 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 2C7FB21FBA; Thu, 8 Aug 2019 08:31:01 -0400 (EDT) Received: from imap1 ([10.202.2.51]) by compute7.internal (MEProxy); Thu, 08 Aug 2019 08:31:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= mime-version:message-id:in-reply-to:references:date:from:to:cc :subject:content-type; s=fm3; bh=PguwD1S98I2PiOAcXdFoAWzSzAM/EJk elJs/tAutZdU=; b=mCD0SoA2dF+Ovn6AsrAJSqKGkDi4iCKqILaTQXuIFwr6emN ueC0ryQtEcYAVs/2Ee3R89I4RC8lvc5zg/9s3+PmFKzIwQcGdtu/A8kTE84p3fTl MZnWfd0FGyZm7PRJkGXtgNfxbiJpIUS3E132eqiMTSO2IFVWLm8+E5D4Z3zy5yME DhDM5V5qO34vw2/sO9MaBRBG1okP0Gm0w/p/ICwLq/gfUkV6Aqsl7qP4ztlrzjk+ 4CejlgTIbdFSk3jirjPflGSHDDweTfoCijNcAijJiA6J92qLIO3eJBY/21OTkyRC bvls0nJ4YCKoBHxe9tnu3bB91qivEF3GIZuQ+Wg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=PguwD1 S98I2PiOAcXdFoAWzSzAM/EJkelJs/tAutZdU=; b=Bq8WMaXvvVAI7exiaArqT4 xCoKDWlU9wAefR4W6qQIxQSgIaCEAyTelF0naT5aECAA4hGnId+8SqO39S5syoWC 2mBC5adEr3monW5uSMGL6qdGmY9JrxojJj+yADGQDbp0UostezsqCvHGxSW5jYma AKD0xElDsDdP1bbfevgaZtFIyT4hRbjTr++W74XLq/ENOuPmDW0RToNRokI+jWm9 ZeASMOU0YX+ixAU85xGD29yvqzCnwRZME4dwQenCc+fSBgqIsppUCmM2aobWgRwn mjTZo/7roEMAdY9x4yIPkxRWQiFf+VpGBuBxwIiM1Gg+U12FBLryMMP51YDeF06Q == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrudduhedgheegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreerjeenucfhrhhomhepfdetlhgv gigvhicuofgvlhhnihhkohhvfdcuoegrrghmvghlnhhikhhovhesfhgrshhtmhgrihhlrd hfmheqnecuffhomhgrihhnpehivghtfhdrohhrghenucfrrghrrghmpehmrghilhhfrhho mheprggrmhgvlhhnihhkohhvsehfrghsthhmrghilhdrfhhmnecuvehluhhsthgvrhfuih iivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 87000C200A4; Thu, 8 Aug 2019 08:30:59 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-808-g930a1a1-fmstable-20190805v2 Mime-Version: 1.0 Message-Id: In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC01B3400EB1@marchand> References: <156481532800.6108.1633834009578124669.idtracker@ietfa.amsl.com> <359EC4B99E040048A7131E0F4E113AFC01B3400EB1@marchand> Date: Thu, 08 Aug 2019 13:30:34 +0100 From: "Alexey Melnikov" To: "Roman D. Danyliw" , "The IESG" Cc: "draft-ietf-lamps-cms-shakes@ietf.org" , "lamps-chairs@ietf.org" , SPASM , "Russ Housley" Content-Type: text/plain Archived-At: Subject: Re: [lamps] =?utf-8?q?Alexey_Melnikov=27s_Discuss_on_draft-ietf-lamp?= =?utf-8?q?s-cms-shakes-15=3A_=28with_DISCUSS=29?= X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2019 12:31:18 -0000 Hi Roman, On Thu, Aug 8, 2019, at 5:50 AM, Roman Danyliw wrote: > > > -----Original Message----- > > From: iesg [mailto:iesg-bounces@ietf.org] On Behalf Of Alexey Melnikov via > > Datatracker > > Sent: Saturday, August 3, 2019 2:55 AM > > To: The IESG > > Cc: draft-ietf-lamps-cms-shakes@ietf.org; lamps-chairs@ietf.org; > > spasm@ietf.org; housley@vigilsec.com > > Subject: Alexey Melnikov's Discuss on draft-ietf-lamps-cms-shakes-15: (with > > DISCUSS) > > > > Alexey Melnikov has entered the following ballot position for > > draft-ietf-lamps-cms-shakes-15: Discuss > > > > When responding, please keep the subject line intact and reply to all email > > addresses included in the To and CC lines. (Feel free to cut this introductory > > paragraph, however.) > > > > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-shakes/ > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > This is a fine document, but I have one quick question: > > > > Values TBD1..TBD4 are not listed in the IANA Considerations section. Should > > they be? > > I don't think so. This document and draft-ietf-lamps-pkix-shakes both > need the same OIDs (but have no other dependence). This latter draft > is with the RFC Editor and does register these OIDs. Ok, I understand now. > The current text, > "[I-D.ietf-lamps-pkix-shake] [ EDNOTE: Update reference with the RFC > when it is ready ]", was intended to guide the editor to replace TBD1-4 > the OIDs when ietf-lamps-pkix-shake got published. However, in > re-reading the text now, the EDNOTE should actually read "Updated the > TBD1-2 reference when the RFC is published". There are 2 places TBD1-2 and TBD3-4. But yes, something like that. I read the current text as just an instruction to change the draft name to the corresponding RFC number, so clarifying it would be great. > > Make sense? Best Regards, Alexey From nobody Thu Aug 8 05:37:04 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1003E120020; Thu, 8 Aug 2019 05:36:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.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 GYkTkY02mpw2; Thu, 8 Aug 2019 05:36:53 -0700 (PDT) Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (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 EF848120046; Thu, 8 Aug 2019 05:36:52 -0700 (PDT) Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x78Camtn035041; Thu, 8 Aug 2019 08:36:48 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu x78Camtn035041 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1565267809; bh=i0rpauXYFqT9TUlUMTl/SsAXcen3K6vlvA2q9D5VBRQ=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=OlSCvqN/sdyU9Hd2xP27t7OHdRkenaEJsp4J2dlhNVCQNugt+R8tBSXnNXyEMFlet HOfAzTkXABhGr7vlZ4KEkF8xX3E8xlTv+2y47qGedTqspc1hxLGvRHyKUm0y72OqLx yryGaQA68ceQsF1omRCflznv1xj59mZoZPSc0VBE= Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x78CajS8039227; Thu, 8 Aug 2019 08:36:45 -0400 Received: from MARCHAND.ad.sei.cmu.edu ([10.64.28.251]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.03.0439.000; Thu, 8 Aug 2019 08:36:45 -0400 From: Roman Danyliw To: Alexey Melnikov , The IESG CC: "draft-ietf-lamps-cms-shakes@ietf.org" , "lamps-chairs@ietf.org" , SPASM , Russ Housley Thread-Topic: Alexey Melnikov's Discuss on draft-ietf-lamps-cms-shakes-15: (with DISCUSS) Thread-Index: AQHVSchz8oL0fspzZEem3qSCsBcW26bws2CAgADGQwD//74A0A== Date: Thu, 8 Aug 2019 12:36:44 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC01B340168E@marchand> References: <156481532800.6108.1633834009578124669.idtracker@ietfa.amsl.com> <359EC4B99E040048A7131E0F4E113AFC01B3400EB1@marchand> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [lamps] Alexey Melnikov's Discuss on draft-ietf-lamps-cms-shakes-15: (with DISCUSS) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2019 12:36:55 -0000 Hi! > -----Original Message----- > From: Alexey Melnikov [mailto:aamelnikov@fastmail.fm] > Sent: Thursday, August 8, 2019 8:31 AM > To: Roman Danyliw ; The IESG > Cc: draft-ietf-lamps-cms-shakes@ietf.org; lamps-chairs@ietf.org; SPASM > ; Russ Housley > Subject: Re: Alexey Melnikov's Discuss on draft-ietf-lamps-cms-shakes-15: > (with DISCUSS) >=20 > Hi Roman, >=20 > On Thu, Aug 8, 2019, at 5:50 AM, Roman Danyliw wrote: > > > > > -----Original Message----- > > > From: iesg [mailto:iesg-bounces@ietf.org] On Behalf Of Alexey > > > Melnikov via Datatracker > > > Sent: Saturday, August 3, 2019 2:55 AM > > > To: The IESG > > > Cc: draft-ietf-lamps-cms-shakes@ietf.org; lamps-chairs@ietf.org; > > > spasm@ietf.org; housley@vigilsec.com > > > Subject: Alexey Melnikov's Discuss on > > > draft-ietf-lamps-cms-shakes-15: (with > > > DISCUSS) > > > > > > Alexey Melnikov has entered the following ballot position for > > > draft-ietf-lamps-cms-shakes-15: Discuss > > > > > > When responding, please keep the subject line intact and reply to > > > all email addresses included in the To and CC lines. (Feel free to > > > cut this introductory paragraph, however.) > > > > > > > > > Please refer to > > > https://www.ietf.org/iesg/statement/discuss-criteria.html > > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > > > > The document, along with other ballot positions, can be found here: > > > https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-shakes/ > > > > > > > > > > > > -------------------------------------------------------------------- > > > -- > > > DISCUSS: > > > -------------------------------------------------------------------- > > > -- > > > > > > This is a fine document, but I have one quick question: > > > > > > Values TBD1..TBD4 are not listed in the IANA Considerations section. > > > Should they be? > > > > I don't think so. This document and draft-ietf-lamps-pkix-shakes both > > need the same OIDs (but have no other dependence). This latter draft > > is with the RFC Editor and does register these OIDs. >=20 > Ok, I understand now. >=20 > > The current text, > > "[I-D.ietf-lamps-pkix-shake] [ EDNOTE: Update reference with the RFC > > when it is ready ]", was intended to guide the editor to replace > > TBD1-4 the OIDs when ietf-lamps-pkix-shake got published. However, in > > re-reading the text now, the EDNOTE should actually read "Updated the > > TBD1-2 reference when the RFC is published". >=20 > There are 2 places TBD1-2 and TBD3-4. But yes, something like that. > > I read the current text as just an instruction to change the draft name t= o the > corresponding RFC number, so clarifying it would be great. Exactly. There are two places where this update needs to be made. Thanks, Roman > > > > Make sense? >=20 > Best Regards, > Alexey From nobody Thu Aug 8 07:28:43 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02CDC12006D for ; Thu, 8 Aug 2019 07:28:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 2uIW0T9_K1Bj for ; Thu, 8 Aug 2019 07:28:39 -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 ECF5212004E for ; Thu, 8 Aug 2019 07:28:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id C6519300AF6 for ; Thu, 8 Aug 2019 10:09:20 -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 sam6Wr2EnghB for ; Thu, 8 Aug 2019 10:09:19 -0400 (EDT) Received: from a860b60074bd.fios-router.home (unknown [138.88.156.37]) by mail.smeinc.net (Postfix) with ESMTPSA id 0F288300A51; Thu, 8 Aug 2019 10:09:19 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Russ Housley In-Reply-To: <005b01d54d98$8fcd93c0$af68bb40$@augustcellars.com> Date: Thu, 8 Aug 2019 10:28:35 -0400 Cc: LAMPS WG Content-Transfer-Encoding: 7bit Message-Id: References: <13908.1564606053@localhost> <32761.1564622701@localhost> <005b01d54d98$8fcd93c0$af68bb40$@augustcellars.com> To: Jim Schaad , Michael Richardson X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [lamps] rfc7030-est clarifications of ASN.1 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2019 14:28:41 -0000 Tanks Jim. Yes, RFC 6268 obsoletes the module that I referenced. Russ > On Aug 7, 2019, at 11:22 PM, Jim Schaad wrote: > > > Michael, > > If you tried to learn it back that far, I don't think that it was even part > of the language at that point in time. > > Just a quick note on the module that Russ provided. The import for the CMS > module is incorrect. It should be: > > FROM CryptographicMessageSyntax-2010 -- [RFC6268] > { iso(1) member-body(2) us(840) rsadsi(113549) > pkcs(1) pkcs-9(9) smime(16) modules(0) > id-mod-cms-2009(58) } > > jim > > > -----Original Message----- > From: Spasm On Behalf Of Michael Richardson > Sent: Wednesday, July 31, 2019 6:25 PM > To: Russ Housley > Cc: LAMPS WG > Subject: Re: [lamps] rfc7030-est clarifications of ASN.1 > > > Russ Housley wrote: >>> I think this is not real ASN.1 syntax, but rather an indication for > me >>> to insert more stuff? Or is this something real that I don't >>> understand. > >> No, this is real ASN.1 syntax. > > okay. > It's something I once tried to learn, back in 1995, and I got as far as the > trivial stuff, but that was all. > > I will incorporate your module into the clarifications document. > > -- > Michael Richardson , Sandelman Software Works -= > IPv6 IoT consulting =- > > > > From nobody Thu Aug 8 07:57:02 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18A9812014B; Thu, 8 Aug 2019 07:57:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=D/n7r6RY; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=R3Cv7p9x 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 d7HGJ6OHBAfe; Thu, 8 Aug 2019 07:56:58 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 107EE12018C; Thu, 8 Aug 2019 07:56:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3405; q=dns/txt; s=iport; t=1565276212; x=1566485812; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=2c4j4YZeGNeuz+28mHBL+r8r5eV43dfgyRlAYrG6XcQ=; b=D/n7r6RYMPS6qSOVsteAZ3rKK9PX0obvHTXUD9yTqg4lRJ2FiMHBcHID uiZ3KUVWNBd+9KRp7+fRBvSOfStj6JOI/ctqojNvtcHSayAnv7RPPvMxh SQvscYciHbXjLWwWKYFMat7Yxw1XM/Qqz+K1kbVofENgdinjz8G77Whza Q=; IronPort-PHdr: =?us-ascii?q?9a23=3AQ5oqNhaNFnKwii6IHtCxYaD/LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el20gabRp3VvvRDjeee87vtX2AN+96giDgDa9QNMn?= =?us-ascii?q?1NksAKh0olCc+BB1f8KavybCU/BM1EXXdu/mqwNg5eH8OtL1A=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AIAABnN0xd/5hdJa1mGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUwUBAQEBCwGBRCknA21VIAQLKgqHWwOEUoZhgluXYIEuFIE?= =?us-ascii?q?QA1QJAQEBDAEBGAsKAgEBhD8CglYjNAkOAQQBAQQBAQQBCm2FJwyFSgEBAQE?= =?us-ascii?q?CAQEBECgGAQEsCwEEBwQCAQgOAwQBAQEeCQcnCxQJCAIEAQ0FCBqDAYFqAw4?= =?us-ascii?q?PAQIMoGsCgTiIYIIjgnoBAQWBR0GDDRiCFAMGgTQBi2MXgUA/gRFGgU5+PoJ?= =?us-ascii?q?hAQEBAgGBKgESASEwgwuCJow5iAGXBAkCgh2GX41lgjCHL4MDgRGKQ41QgTW?= =?us-ascii?q?GKJAcAgQCBAUCDgEBBYFQOGdYEQhwFTuCbIJCN28BCIJChRSFP3IBgSiJLYE?= =?us-ascii?q?iAYEgAQE?= X-IronPort-AV: E=Sophos;i="5.64,361,1559520000"; d="scan'208";a="526393582" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 08 Aug 2019 14:56:50 +0000 Received: from XCH-ALN-020.cisco.com (xch-aln-020.cisco.com [173.36.7.30]) by rcdn-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id x78Euont021238 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 8 Aug 2019 14:56:50 GMT Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-ALN-020.cisco.com (173.36.7.30) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 8 Aug 2019 09:56:50 -0500 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 8 Aug 2019 09:56:48 -0500 Received: from NAM04-CO1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 8 Aug 2019 10:56:48 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=aTkaZbctWFU9zLFWLkPtBQ3P5UVNxVlTfpaQV3KKBSt7ADsm5AQxkhfL54SDu/bXr1O7kwa8U6Mf630m2HMXlUlLI1A8WjhF7yiVquOYYFgaP43L1kPg4vauTKT2vHT+sJQXF0xvUnfnPVXdoHOD5IBhgaWbuLqpFkbyw4h38L0tFg19ovbg5Tq9DFAEdNM9cMIYBrPB4xlQG7lSUp4X3XjMMmXfmFoa570WWmnbsjfDQuFg8PHGzRc5jHgjV04yQwBGEqjIq7rgOntx+5dIAbJhF7EsdlWadTi39XQn2Fq5nClvp3cLQhCoES6gYesDzaXF5WqIp6hRA778aYSJjQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oaJ+a8PoE/VAcJ7NkUNV/6VuPB5LNZlkjucQAp+H8OM=; b=bsD2SsAoc+rRoWcMyYMLH2RBJ2SXPojRMBuIJV5q0roDIZrsQ6IQ+yWENBgJgApN8uRFdIflfXm4akO05WGUogAK7hhPIlCCSj4wyqK9zT9Sy4NwJJIYeEVgeBZHL159uhhjZIofAqEfSQAdG1h3gsRfQwkv0xMu7D8QhlVU0oXJaDJqfOTL5JGLZdBRxtizG2oz6nP/ZlMeAdj6E4bI7ljW9sySQMasuoXr+YtZspzGjxQhkLYUnUmlXznHTWCOYbffcywKGSLhSQObXg07u/fLhfkRKzUcQqiNjXjyt55/QNpJ+lMoCQSsLzNteCsDk4HHMqU7lah59ANPR2/rRg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oaJ+a8PoE/VAcJ7NkUNV/6VuPB5LNZlkjucQAp+H8OM=; b=R3Cv7p9xRCkI2CA5c7Z9IGKdvMgYfgt/PXcZ/11e0K1NHkkMM5fN6YfDGCo8K6BBeZe+8uMkoOMcFQ8XzgDe8XkhVxKj/8ywZl2Y5pjc9Js9nEnr6e71lZxPV9g5IVHHBD4zwo04Ql/DxWUZTE4saSgRukx3t4MBFgz3VWsL4nU= Received: from BN7PR11MB2547.namprd11.prod.outlook.com (52.135.255.146) by BN7PR11MB2612.namprd11.prod.outlook.com (52.135.246.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2157.14; Thu, 8 Aug 2019 14:56:46 +0000 Received: from BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::a4d7:5299:601e:53cd]) by BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::a4d7:5299:601e:53cd%7]) with mapi id 15.20.2157.015; Thu, 8 Aug 2019 14:56:46 +0000 From: "Panos Kampanakis (pkampana)" To: Alexey Melnikov , "Roman D. Danyliw" , The IESG CC: "draft-ietf-lamps-cms-shakes@ietf.org" , "lamps-chairs@ietf.org" , SPASM , Russ Housley Thread-Topic: [lamps] Alexey Melnikov's Discuss on draft-ietf-lamps-cms-shakes-15: (with DISCUSS) Thread-Index: AQHVTaT350PDJoD3Hk2GjdX7NPuc2qbxLtwAgAAg2uA= Date: Thu, 8 Aug 2019 14:56:46 +0000 Message-ID: References: <156481532800.6108.1633834009578124669.idtracker@ietfa.amsl.com> <359EC4B99E040048A7131E0F4E113AFC01B3400EB1@marchand> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pkampana@cisco.com; x-originating-ip: [173.38.117.75] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 43a750f1-d769-420a-98c0-08d71c10a28e x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BN7PR11MB2612; x-ms-traffictypediagnostic: BN7PR11MB2612: x-ms-exchange-purlcount: 3 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 012349AD1C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(346002)(39860400002)(366004)(396003)(376002)(189003)(13464003)(199004)(66066001)(305945005)(64756008)(316002)(66446008)(229853002)(66556008)(2906002)(25786009)(66946007)(11346002)(6246003)(53936002)(71190400001)(4326008)(476003)(76116006)(54906003)(486006)(33656002)(71200400001)(966005)(6116002)(53546011)(81156014)(6306002)(74316002)(9686003)(6506007)(7736002)(256004)(55016002)(6436002)(99286004)(446003)(66476007)(110136005)(102836004)(81166006)(5660300002)(7696005)(186003)(478600001)(52536014)(8936002)(8676002)(86362001)(14454004)(26005)(14444005)(76176011)(3846002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN7PR11MB2612; H:BN7PR11MB2547.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 7xn9vhqNLsUC+AQFgCBHI/IL8DnohiipTMCLkwiUe9r8AHYJUBWkM6pERK2c3I8u9sH4ZfPdODFcIxQVr+Lz0GF7l6NgoNaTwRFlVkQ4bisoKSvqguMcOTCw4W5tsOz3taGcOT8TGLkIj7OrOyDn1ZVGP4+UearN+bPKR33hZmQ/WZZ6Ir0H15kj44fwzsvZjwpglakbwIus9OSTqIIbUQR8+zX2iTrrxMQhkkC9V1B+aSla2VUykVohqImBBKs5rByNCwLhKxgqlMuiHnfktmuMdpfTlmnzNrCgKPbHKbf+Uti+y4NRXIARoxPeDuahprDzKPk1+kPL/DDFXLgDxRqIMz4Wi6RiC7phJGndp6/VJXI1crQtgEo3PzNQS5Yw0UAgj7BEizswGy2SCNlXfnCJ18Cs9nXD40wHAKz/xQc= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 43a750f1-d769-420a-98c0-08d71c10a28e X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Aug 2019 14:56:46.6684 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: uciTc047zJcigHAkU2U1FZZAiAkQBvF0qxZ6GmDe1147lIoNQRNFEJ/NmvH4aFF5yYhnXzOLMOIogIf4DQmG8A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2612 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.30, xch-aln-020.cisco.com X-Outbound-Node: rcdn-core-1.cisco.com Archived-At: Subject: Re: [lamps] Alexey Melnikov's Discuss on draft-ietf-lamps-cms-shakes-15: (with DISCUSS) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2019 14:57:01 -0000 Hi Alexey, > I read the current text as just an instruction to change the draft name t= o the corresponding RFC number, so clarifying it would be great. ACK. I will update the endnote to say "Update the TBD1-2 reference when the= RFC is published" with any comments that come next. The EDNOTE serves as a= reminder and since Roman will make sure the PKIX-SHAKEs RFC gets published= first we will be all right.=20 Panos -----Original Message----- From: Spasm On Behalf Of Alexey Melnikov Sent: Thursday, August 08, 2019 8:31 AM To: Roman D. Danyliw ; The IESG Cc: draft-ietf-lamps-cms-shakes@ietf.org; lamps-chairs@ietf.org; SPASM ; Russ Housley Subject: Re: [lamps] Alexey Melnikov's Discuss on draft-ietf-lamps-cms-shak= es-15: (with DISCUSS) Hi Roman, On Thu, Aug 8, 2019, at 5:50 AM, Roman Danyliw wrote: >=20 > > -----Original Message----- > > From: iesg [mailto:iesg-bounces@ietf.org] On Behalf Of Alexey=20 > > Melnikov via Datatracker > > Sent: Saturday, August 3, 2019 2:55 AM > > To: The IESG > > Cc: draft-ietf-lamps-cms-shakes@ietf.org; lamps-chairs@ietf.org;=20 > > spasm@ietf.org; housley@vigilsec.com > > Subject: Alexey Melnikov's Discuss on=20 > > draft-ietf-lamps-cms-shakes-15: (with > > DISCUSS) > >=20 > > Alexey Melnikov has entered the following ballot position for > > draft-ietf-lamps-cms-shakes-15: Discuss > >=20 > > When responding, please keep the subject line intact and reply to=20 > > all email addresses included in the To and CC lines. (Feel free to=20 > > cut this introductory paragraph, however.) > >=20 > >=20 > > Please refer to=20 > > https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > >=20 > >=20 > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-shakes/ > >=20 > >=20 > >=20 > > -------------------------------------------------------------------- > > -- > > DISCUSS: > > -------------------------------------------------------------------- > > -- > >=20 > > This is a fine document, but I have one quick question: > >=20 > > Values TBD1..TBD4 are not listed in the IANA Considerations section.=20 > > Should they be? >=20 > I don't think so. This document and draft-ietf-lamps-pkix-shakes both=20 > need the same OIDs (but have no other dependence). This latter draft=20 > is with the RFC Editor and does register these OIDs. Ok, I understand now. > The current text, > "[I-D.ietf-lamps-pkix-shake] [ EDNOTE: Update reference with the RFC=20 > when it is ready ]", was intended to guide the editor to replace=20 > TBD1-4 the OIDs when ietf-lamps-pkix-shake got published. However, in=20 > re-reading the text now, the EDNOTE should actually read "Updated the > TBD1-2 reference when the RFC is published". There are 2 places TBD1-2 and TBD3-4. But yes, something like that. I read the current text as just an instruction to change the draft name to = the corresponding RFC number, so clarifying it would be great. >=20 > Make sense? Best Regards, Alexey _______________________________________________ Spasm mailing list Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm From nobody Thu Aug 8 11:26:09 2019 Return-Path: X-Original-To: spasm@ietf.org Delivered-To: spasm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8550012002F; Thu, 8 Aug 2019 11:25:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spasm@ietf.org Message-ID: <156528875950.7542.13414022632205417198@ietfa.amsl.com> Date: Thu, 08 Aug 2019 11:25:59 -0700 Archived-At: Subject: [lamps] I-D Action: draft-ietf-lamps-cms-shakes-17.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2019 18:26:00 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Limited Additional Mechanisms for PKIX and SMIME WG of the IETF. Title : Use of the SHAKE One-way Hash Functions in the Cryptographic Message Syntax (CMS) Authors : Panos Kampanakis Quynh Dang Filename : draft-ietf-lamps-cms-shakes-17.txt Pages : 18 Date : 2019-08-08 Abstract: This document updates the "Cryptographic Message Syntax Algorithms" (RFC3370) and describes the conventions for using the SHAKE family of hash functions in the Cryptographic Message Syntax as one-way hash functions with the RSA Probabilistic signature and ECDSA signature algorithms. The conventions for the associated signer public keys in CMS are also described. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-shakes/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lamps-cms-shakes-17 https://datatracker.ietf.org/doc/html/draft-ietf-lamps-cms-shakes-17 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-cms-shakes-17 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Aug 10 09:35:49 2019 Return-Path: X-Original-To: spasm@ietf.org Delivered-To: spasm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 78AC0120046; Sat, 10 Aug 2019 09:35:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spasm@ietf.org Message-ID: <156545494140.3628.9700331107326595979@ietfa.amsl.com> Date: Sat, 10 Aug 2019 09:35:41 -0700 Archived-At: Subject: [lamps] I-D Action: draft-ietf-lamps-cms-hash-sig-09.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Aug 2019 16:35:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Limited Additional Mechanisms for PKIX and SMIME WG of the IETF. Title : Use of the HSS/LMS Hash-based Signature Algorithm in the Cryptographic Message Syntax (CMS) Author : Russ Housley Filename : draft-ietf-lamps-cms-hash-sig-09.txt Pages : 14 Date : 2019-08-10 Abstract: This document specifies the conventions for using the Hierarchical Signature System (HSS) / Leighton-Micali Signature (LMS) hash-based signature algorithm with the Cryptographic Message Syntax (CMS). In addition, the algorithm identifier and public key syntax are provided. The HSS/LMS algorithm is one form of hash-based digital signature; it is described in RFC 8554. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-hash-sig/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lamps-cms-hash-sig-09 https://datatracker.ietf.org/doc/html/draft-ietf-lamps-cms-hash-sig-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-cms-hash-sig-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Aug 10 09:36:59 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15A42120090 for ; Sat, 10 Aug 2019 09:36:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 RBkVI3ZId934 for ; Sat, 10 Aug 2019 09:36:55 -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 79F21120046 for ; Sat, 10 Aug 2019 09:36:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 82D40300AFB for ; Sat, 10 Aug 2019 12:17:37 -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 ALX2ToznggeO for ; Sat, 10 Aug 2019 12:17:36 -0400 (EDT) Received: from a860b60074bd.fios-router.home (unknown [138.88.156.37]) by mail.smeinc.net (Postfix) with ESMTPSA id 6F2D13004A7 for ; Sat, 10 Aug 2019 12:17:36 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Sat, 10 Aug 2019 12:36:53 -0400 References: <156545494170.3628.12742397909002689396.idtracker@ietfa.amsl.com> To: LAMPS WG In-Reply-To: <156545494170.3628.12742397909002689396.idtracker@ietfa.amsl.com> Message-Id: X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [lamps] New Version Notification for draft-ietf-lamps-cms-hash-sig-09.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Aug 2019 16:36:57 -0000 The minor changes were made to address IETF Last Call comments. Russ > On Aug 10, 2019, at 12:35 PM, internet-drafts@ietf.org wrote: >=20 >=20 > A new version of I-D, draft-ietf-lamps-cms-hash-sig-09.txt > has been successfully submitted by Russ Housley and posted to the > IETF repository. >=20 > Name: draft-ietf-lamps-cms-hash-sig > Revision: 09 > Title: Use of the HSS/LMS Hash-based Signature = Algorithm in the Cryptographic Message Syntax (CMS) > Document date: 2019-08-10 > Group: lamps > Pages: 14 > URL: = https://www.ietf.org/internet-drafts/draft-ietf-lamps-cms-hash-sig-09.txt > Status: = https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-hash-sig/ > Htmlized: = https://tools.ietf.org/html/draft-ietf-lamps-cms-hash-sig-09 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-ietf-lamps-cms-hash-sig > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lamps-cms-hash-sig-09 >=20 > Abstract: > This document specifies the conventions for using the Hierarchical > Signature System (HSS) / Leighton-Micali Signature (LMS) hash-based > signature algorithm with the Cryptographic Message Syntax (CMS). In > addition, the algorithm identifier and public key syntax are > provided. The HSS/LMS algorithm is one form of hash-based digital > signature; it is described in RFC 8554. >=20 From nobody Sat Aug 10 10:31:46 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3FDF12011C for ; Sat, 10 Aug 2019 10:31:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 mMZ5rI7eyw1B for ; Sat, 10 Aug 2019 10:31:43 -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 83A06120075 for ; Sat, 10 Aug 2019 10:31:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 9AB09300B00 for ; Sat, 10 Aug 2019 13:12:25 -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 BYs5XJYBIBi1 for ; Sat, 10 Aug 2019 13:12:24 -0400 (EDT) Received: from a860b60074bd.fios-router.home (unknown [138.88.156.37]) by mail.smeinc.net (Postfix) with ESMTPSA id 9243E3005DB for ; Sat, 10 Aug 2019 13:12:24 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: Date: Sat, 10 Aug 2019 13:31:41 -0400 To: LAMPS WG X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [lamps] Header Protection Backward Compatibility Requirements X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Aug 2019 17:31:45 -0000 h= ttps://datatracker.ietf.org/doc/draft-ietf-lamps-header-protection-require= ments/ We started a discussion at IETF 105. The people in the room felt that = further maillist discussion is needed to determine the backward = compatibility requirements. Please continue that discussion. Russ From nobody Sat Aug 10 10:51:46 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BFA212011C for ; Sat, 10 Aug 2019 10:51:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 5MKsWqC9XfZs for ; Sat, 10 Aug 2019 10:51:43 -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 2101A1200F6 for ; Sat, 10 Aug 2019 10:51:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id F191E300A30 for ; Sat, 10 Aug 2019 13:32:24 -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 jcCNDDEFiraf for ; Sat, 10 Aug 2019 13:32:24 -0400 (EDT) Received: from a860b60074bd.fios-router.home (unknown [138.88.156.37]) by mail.smeinc.net (Postfix) with ESMTPSA id DDA2D3005DB for ; Sat, 10 Aug 2019 13:32:23 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: Date: Sat, 10 Aug 2019 13:51:40 -0400 To: LAMPS WG X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [lamps] IETF 105 Minutes X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Aug 2019 17:51:45 -0000 https://datatracker.ietf.org/meeting/105/materials/minutes-105-lamps-00 Please send corrections to the mail list. Russ From nobody Tue Aug 13 18:36:52 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0657412025D for ; Tue, 13 Aug 2019 18:36:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 QSZobz-NR5Lr for ; Tue, 13 Aug 2019 18:36:38 -0700 (PDT) Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (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 3E4DC120255 for ; Tue, 13 Aug 2019 18:36:38 -0700 (PDT) Received: by mail-qt1-x831.google.com with SMTP id e8so7982732qtp.7 for ; Tue, 13 Aug 2019 18:36:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:mime-version:subject:message-id:references:to:date; bh=aH3nWqvF3LKEqeTmWONsesRQrWHuTodsHV6tkIGNhjQ=; b=cRq5R1v0MmKlt4xaJA9QHJZPn90u88yyoGBVmzCZCE7aMwd0r2s0NCyMCklldaqvfd AtHIXGYgpg+iRvAmyVWExYolIsKdtC1seIMpTkK9IzifUrhzRiAcTYv863hSCPsibegu J9sSremY7/DxXX5cm0bZT2FIsgUXqWwqybSnw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:references :to:date; bh=aH3nWqvF3LKEqeTmWONsesRQrWHuTodsHV6tkIGNhjQ=; b=MWluPw1kYM1MmnM7axWvnb+pM0nEfVMZmnBD1IOSqFP/P2qhhfgMEw1BulMyp0CChd OaNdwPY6Ih+07/mfWGAJawJp356W4A+Om/+noRXuyvQoqQCjTTvjh/Hp28oPyglp2xa8 fUEY6Z/53IiJPN1eWqU/F/GkVB1iz0vZ7RBBja/Doc3AqLgRuG0LLS7yLkJonuW5hptQ 6Y3YeV64VB12KW6Whfw4CVnkiMF/xyU3DRCrUyKMoC6aTtOKhX+2pp1AwLl8vjhmfHir ECsOhuMdUjtFm8J7wqVtqn7fFiWRqz6DxcvdTGloSzb0BobaZl/9Ja5sjA5QYkg0jRv5 0Klg== X-Gm-Message-State: APjAAAVmS97244COnCNAfSpTwD5wl3nsmVtTp7vAWPmKfdFseHoMQsP3 lYsad/Nmq2DhBJMT84ygk9imKZph9Vs= X-Google-Smtp-Source: APXvYqyUN+2dneutZHmbC7cCQUznne1TFf/yvUwXiCz2EqoZKJtFMW5axZOvMN+Q+Ff7W3WChfbUQQ== X-Received: by 2002:a0c:b59c:: with SMTP id g28mr868547qve.244.1565746597101; Tue, 13 Aug 2019 18:36:37 -0700 (PDT) Received: from sn3rd.lan ([75.102.131.36]) by smtp.gmail.com with ESMTPSA id y194sm51145701qkb.111.2019.08.13.18.36.36 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Aug 2019 18:36:36 -0700 (PDT) From: Sean Turner Content-Type: multipart/alternative; boundary="Apple-Mail=_04DE79BC-632A-498A-A68A-107524120C5B" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: References: <156574655345.24099.16147834520977401455.idtracker@ietfa.amsl.com> To: LAMPS WG Date: Tue, 13 Aug 2019 21:36:35 -0400 X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [lamps] Fwd: New Version Notification for draft-turner-5480-ku-clarifications-01.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2019 01:36:52 -0000 --Apple-Mail=_04DE79BC-632A-498A-A68A-107524120C5B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi! This version incorporates the comment about the intro from Russ. spt > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-turner-5480-ku-clarifications-01.txt > Date: August 13, 2019 at 21:35:53 EDT > To: "Tadahiko Ito" , "Sean Turner" = >=20 >=20 > A new version of I-D, draft-turner-5480-ku-clarifications-01.txt > has been successfully submitted by Sean Turner and posted to the > IETF repository. >=20 > Name: draft-turner-5480-ku-clarifications > Revision: 01 > Title: Clarifications for Elliptic Curve Cryptogtaphy = Subject Public Key Information > Document date: 2019-08-13 > Group: Individual Submission > Pages: 3 > URL: = https://www.ietf.org/internet-drafts/draft-turner-5480-ku-clarifications-0= 1.txt > Status: = https://datatracker.ietf.org/doc/draft-turner-5480-ku-clarifications/ > Htmlized: = https://tools.ietf.org/html/draft-turner-5480-ku-clarifications-01 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-turner-5480-ku-clarifications > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-turner-5480-ku-clarifications-01= >=20 > Abstract: > This document updates RFC 5480 to specify semantics for the > keyEncipherment and dataEncipherment key usage bits when used in > certificates that support Elliptic Curve Cryptography. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 --Apple-Mail=_04DE79BC-632A-498A-A68A-107524120C5B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi! = This version incorporates the comment about the intro from Russ.

spt
Begin = forwarded message:

From: = internet-drafts@ietf.org
Subject: = New Version = Notification for draft-turner-5480-ku-clarifications-01.txt
Date: = August 13, 2019 at 21:35:53 = EDT
To: = "Tadahiko Ito" <tadahiko.ito.public@gmail.com>, "Sean Turner" <sean@sn3rd.com>

A new version of I-D, = draft-turner-5480-ku-clarifications-01.txt
has been = successfully submitted by Sean Turner and posted to the
IETF= repository.

Name: = draft-turner-5480-ku-clarifications
Revision: 01
Title:= = Clarifications for Elliptic Curve Cryptogtaphy Subject Public Key = Information
Document date: 2019-08-13
Group:= = Individual Submission
Pages: 3
URL: =            https://www.ietf.org/internet-drafts/draft-turner-5480-ku-clari= fications-01.txt
Status: =         https://datatracker.ietf.org/doc/draft-turner-5480-ku-clarifica= tions/
Htmlized: =       https://tools.ietf.org/html/draft-turner-5480-ku-clarifications= -01
Htmlized:       https://datatracker.ietf.org/doc/html/draft-turner-5480-ku-clar= ifications
Diff: =           https://www.ietf.org/rfcdiff?url2=3Ddraft-turner-5480-ku-clarif= ications-01

Abstract:
=   This document updates RFC 5480 to specify semantics for = the
  keyEncipherment and dataEncipherment key = usage bits when used in
  certificates that = support Elliptic Curve Cryptography.




Please note that it may take a = couple of minutes from the time of submission
until the = htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


= --Apple-Mail=_04DE79BC-632A-498A-A68A-107524120C5B-- From nobody Wed Aug 14 08:59:24 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D92701209F3 for ; Wed, 14 Aug 2019 08:59:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=digicert.com header.b=jkcHc5jq; dkim=pass (1024-bit key) header.d=digicert.com header.b=LCTPM/d/ 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 Oybd8Aem3jHY for ; Wed, 14 Aug 2019 08:59:16 -0700 (PDT) Received: from us-smtp-delivery-173.mimecast.com (us-smtp-delivery-173.mimecast.com [63.128.21.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 011851209EE for ; Wed, 14 Aug 2019 08:59:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digicert.com; s=mimecast20190124; t=1565798354; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=KyEBjgwQLZO7sNjP+9LlWS96xA+ALWxMkedyY+v0Cao=; b=jkcHc5jqZ70dbypieAvlZbS+JaU1Wulszg4idBf+rol5fHrKZrcGvR3zg3QeAK3h3Yrzge Vtfj2PNsB8f4klliAGNgI1J1ORteaCeCcmo+CSF7bRDURApYOuKSAgKZ/mcdW3f317pGxc 1pdBJk+HHqybj8cwKWidqWSvsYEXafM= Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01lp2053.outbound.protection.outlook.com [104.47.34.53]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-196-TPlEUAtKM0CpU-yMzoBdQg-1; Wed, 14 Aug 2019 11:59:13 -0400 X-MC-Unique: TPlEUAtKM0CpU-yMzoBdQg-1 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UJUriZzGeRKR0WxVvabGqaOMY5LT7lBgINqW7+vet5jF+3QPNU90UtiYYVedcWxBBomaVdmeoz0T13zzwEIYu7JuVHJWDmK0e6KV/OK/mlI7GrYALLGA/lPT0gB8DDcCaO9xL+JKEgYvYesPCizDUtRkARy/olvX6B4uye4XD20qiXx6ROJIq3FGUbJkXzbBdToZgAH1XS5+lVXTcxNav8f+HyXsp/TjdawC4iR30Jm7UJNYe0XI9SyPySbLScb7qwXEgPeLjFCBRXLwcX1kPd+igTbnTxMTpSadWa1xwtThkWvaxqC5CeSGCoGxO19kHOM8ch2DuMR+Jvt2TyIE4g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KyEBjgwQLZO7sNjP+9LlWS96xA+ALWxMkedyY+v0Cao=; b=K9yQy+743WhOmsfUIfvuE3eh2pOh7BEfTweQPfV98CrI+c5JmyaM0iQhjg/bFqMlaDgI/00ZzHXgAXcPZt4ujLvh6YhFuHmhFuZjQz+REVTYP/BCKKttYmXrfXgVDJ2DAJZuTHsDhuS8c7X27HLgpzpkBI4ihAdLe7wfnKtSaKINmHNthRDFPhVJB8e1udMO78yAeoqtTWo4PnAkWta1obfusDXEpwm08nD32VSFRt0V5fnOjyhB6Fn2Od+gKQCVjufd30qPJ/TWZqrAmmjhIuDcvhF0Tjsok/jJJglFQWEZbbbuw+tH/6Ic8SGziUgJWuOuj8Z4utGGcgwbBT7pkQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=digicert.com; dmarc=pass action=none header.from=digicert.com; dkim=pass header.d=digicert.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digicert.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KyEBjgwQLZO7sNjP+9LlWS96xA+ALWxMkedyY+v0Cao=; b=LCTPM/d/QiyjhLTnlR9WHW8/Jo0MTT1j73WfzalhPU0PDH5IMxCptpsYPmKuhk6Qw52L2OFrT45MEQVYRlcUyr3RrF0xf4K9pSBezjR8jqvKtcvtOVgRS+JNqcNGDoInw0B046gytVqpsD9QcP/Ej8R2sM/ojvj7ytK55BmPG/s= Received: from BL0PR14MB3523.namprd14.prod.outlook.com (52.135.47.139) by BL0PR14MB2466.namprd14.prod.outlook.com (20.177.240.213) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2157.20; Wed, 14 Aug 2019 15:59:10 +0000 Received: from BL0PR14MB3523.namprd14.prod.outlook.com ([fe80::c1a:3580:15c1:553a]) by BL0PR14MB3523.namprd14.prod.outlook.com ([fe80::c1a:3580:15c1:553a%2]) with mapi id 15.20.2157.022; Wed, 14 Aug 2019 15:59:10 +0000 From: Tim Hollebeek To: Ryan Sleevi , Stephen Farrell CC: LAMPS WG , Russ Housley Thread-Topic: [lamps] Proposed charter update regarding clarifications Thread-Index: AQHVRHAUqF6kWvQSfUS0oT1mKfG/HabeoKqAgAAEtQCAHEP2oA== Date: Wed, 14 Aug 2019 15:59:10 +0000 Message-ID: References: <3DB1B550-26FA-4F93-8CFA-434C1F8811D1@vigilsec.com> <46773340-6bba-6c54-7049-c6ec30488174@cs.tcd.ie> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tim.hollebeek@digicert.com; x-originating-ip: [98.111.253.32] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d2b26393-d552-4beb-83a9-08d720d0587c x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(49563074)(7193020); SRVR:BL0PR14MB2466; x-ms-traffictypediagnostic: BL0PR14MB2466: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 01294F875B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(396003)(39860400002)(136003)(366004)(346002)(199004)(189003)(256004)(446003)(6506007)(316002)(186003)(790700001)(66556008)(66946007)(66616009)(6116002)(14444005)(76116006)(3846002)(14454004)(2420400007)(53546011)(8936002)(478600001)(66446008)(64756008)(66476007)(54906003)(25786009)(11346002)(54896002)(6306002)(966005)(476003)(9686003)(44832011)(26005)(102836004)(486006)(99286004)(71190400001)(110136005)(33656002)(2906002)(606006)(71200400001)(15650500001)(55016002)(7696005)(6246003)(7110500001)(6436002)(4326008)(21615005)(7736002)(74316002)(66066001)(229853002)(5660300002)(99936001)(76176011)(53936002)(86362001)(236005)(52536014)(8676002)(81156014)(81166006); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR14MB2466; H:BL0PR14MB3523.namprd14.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: digicert.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 8fMZKyJGk4b0YxJYCNMQ3lU4SR6OGcGxxGf+4E12cSgOUIyyMSskcEc4ERv4R//wEH1D5685AtmiBMpE9I57LWs7PwtEascLL5fwN/OJ7qEgrlEgCLfUG18HLVPVEySZefIAsPG71VyR0yMg7a/DvnerkPGCZ9gg5bs6H7cEDNcHlz0vgQBYRIQnGe3HU2AnZzn+HR+WxO5BrR7ev1H9T3zt6R9ApnFk74LNZdQXLiRwc9Jq6Y4t8q7RBGUXXWG8960wSH8tMz1MWUWb14VN1/oujNPNZrAAXjcTVSsS8rFycN6Czv3dDKtxSsP6nWFGyf2vf93vCfPAuIK8qpv7YmdzYBl8P0uEISuyNp2wDv0YhPSTdP2wDP9KbkGw8Iumvz70ImD5u+NgKlPyBLqlAj0ZbpXR1gLkXK+LCoFAkrY= x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_0158_01D55297.AE5A23E0" MIME-Version: 1.0 X-OriginatorOrg: digicert.com X-MS-Exchange-CrossTenant-Network-Message-Id: d2b26393-d552-4beb-83a9-08d720d0587c X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Aug 2019 15:59:10.4785 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf813fa1-bde5-4e75-9479-f6aaa8b1f284 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: JQdTHOYak+9335PUL9fAFwsfbpYEqHhC5aJIuKBOvUTwZQCzwNyTXAWhrEunVJlPu9yP6GgrOj8ZX8Ptt6EnfTActP1D0ecP6T7Xx8MYzxs= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR14MB2466 Archived-At: Subject: Re: [lamps] Proposed charter update regarding clarifications X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2019 15:59:21 -0000 ------=_NextPart_000_0158_01D55297.AE5A23E0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0159_01D55297.AE5A23E0" ------=_NextPart_001_0159_01D55297.AE5A23E0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I=E2=80=99m not in favor of having to bother the AD for a re-charter for = every minor clarification. It is not a productive use of = anyone=E2=80=99s time. =20 -Tim =20 From: Spasm On Behalf Of Ryan Sleevi Sent: Saturday, July 27, 2019 12:20 PM To: Stephen Farrell Cc: LAMPS WG ; Russ Housley Subject: Re: [lamps] Proposed charter update regarding clarifications =20 =20 =20 On Sat, Jul 27, 2019 at 12:03 PM Stephen Farrell = > wrote: On 27/07/2019 12:40, Russ Housley wrote: > At the meeting in Montreal, we suggested a charter update to allow = clarifications. I suggest: >=20 > OLD: >=20 > In addition, the LAMPS WG may investigate other updates to documents > produced by the PKIX and S/MIME WGs, but the LAMPS WG shall not adopt > any of these potential work items without rechartering. >=20 > NEW: >=20 > In addition, the LAMPS WG may investigate other updates to documents > produced by the PKIX and S/MIME WG. The LAMPS WG may produce > clarifications where needed, but the LAMPS WG shall not adopt > anything beyond clarifications without rechartering. >=20 > Thoughts? Seems like another step on the road to re-creating PKIX which at the end produced pointless paper. IMO nothing should be done in this WG unless there's evidence the work will be implemented and deployed. S. =20 While I share the general sentiment, there is at least one clarification = which has clear signs of deployment if there is IETF consensus on the = text -=20 https://tools.ietf.org/id/draft-turner-5480-ku-clarifications-00.html =20 For example,=20 https://github.com/zmap/zlint/pull/293 is used by the majority of the = publicly trusted CAs, directly or indirectly, and would actively enforce = such text. =20 I too appreciate a narrowed scope, and wouldn=E2=80=99t be too miffed if = any/every clarification was a matter for rechartering, and the WG only = looked at chartering with this in scope. ------=_NextPart_001_0159_01D55297.AE5A23E0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

I=E2=80=99m not in favor of having to bother the AD = for a re-charter for every minor clarification.=C2=A0 It is not a = productive use of anyone=E2=80=99s time.

 

-Tim

 

From: Spasm = <spasm-bounces@ietf.org> On Behalf Of Ryan = Sleevi
Sent: Saturday, July 27, 2019 12:20 PM
To: = Stephen Farrell <stephen.farrell@cs.tcd.ie>
Cc: LAMPS WG = <spasm@ietf.org>; Russ Housley = <housley@vigilsec.com>
Subject: Re: [lamps] Proposed = charter update regarding clarifications

 

 

 

On = Sat, Jul 27, 2019 at 12:03 PM Stephen Farrell <stephen.farrell@cs.tcd.ie&g= t; wrote:



On 27/07/2019 12:40, Russ Housley = wrote:
> At the meeting in Montreal, we suggested a charter update = to allow clarifications.  I suggest:
>
> OLD:
> =
> In addition, the LAMPS WG may investigate other updates to = documents
> produced by the PKIX and S/MIME WGs, but the LAMPS WG = shall not adopt
> any of these potential work items without = rechartering.
>
> NEW:
>
> In addition, the = LAMPS WG may investigate other updates to documents
> produced by = the PKIX and S/MIME WG. The LAMPS WG may produce
> clarifications = where needed, but the LAMPS WG shall not adopt
> anything beyond = clarifications without rechartering.
>
> = Thoughts?

Seems like another step on the road to re-creating = PKIX
which at the end produced pointless paper. IMO nothing
should = be done in this WG unless there's evidence the
work will be = implemented and deployed.

S.

 

While I share the general sentiment, there is at least = one clarification which has clear signs of deployment if there is IETF = consensus on the text - 

 

For example, 

https://github.com/zmap/z= lint/pull/293 is used by the majority of the publicly trusted CAs, = directly or indirectly, and would actively enforce such = text.

 

I = too appreciate a narrowed scope, and wouldn=E2=80=99t be too miffed if = any/every clarification was a matter for rechartering, and the WG only = looked at chartering with this in = scope.

------=_NextPart_001_0159_01D55297.AE5A23E0-- ------=_NextPart_000_0158_01D55297.AE5A23E0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCD0sw ggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAwMDAwMDBaFw0zMTEx MTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7kQ4BcsYfzt2D5cRKlrtwmlIiq9M71 IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrneVNcMYQq9g+YMjZ2zN7dPKii72r7IfJS Yd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9SwOD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+ WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyChz+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh 5vqk2dUXMXWuhX0irj8BRob2KHnIsdrkVxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Y d08CAwEAAaNjMGEwDgYDVR0PAQH/BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXr oq/0ksuCMS1Ri6enIZ3zbcgPMB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqG SIb3DQEBBQUAA4IBAQCiDrzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwS TFjk0z2DSUVYlzVpGqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJ s13rsgkq6ybteL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLx vlBnt2y98/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76 jRslbWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMIIFOjCCBCKgAwIBAgIQ Di7WjgxCjxTrYbReNHesEzANBgkqhkiG9w0BAQsFADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMM RGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2Vy dCBTSEEyIEFzc3VyZWQgSUQgQ0EwHhcNMTcxMTI4MDAwMDAwWhcNMjIwMjI1MTIwMDAwWjBWMQsw CQYDVQQGEwJVUzENMAsGA1UECBMEVXRhaDENMAsGA1UEBxMETGVoaTERMA8GA1UEChMIRGlnaUNl cnQxFjAUBgNVBAMTDVRpbSBIb2xsZWJlZWswggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDKUTIS9F3d7CfkCjsf4my28pYoZJDkEAiXVqGP4jzbFkszUQNfW3PYpFUo1GnKQykl/tM0qnzw 05bfVLo1+ce0e9fyAwYfulr+HaAVCPqx+PZw9CDY6c0NYd7Fc7S0scONxKekNF4q1mUucfGuGapW sEsyix0CuR0NMuJ4I+w8qMn9MzjzI7bvduG+uVLmZIi0p6D8+2R5BOQFy0tVeQ/aLfS91fG1DTYF YkPF+a/6JlFxzywPzCth8KW2Po4w8JqQWtam/ADKrgMaOnEJs9csefTW/FWRDeGQk5t3rnyS19FP QfpyPPau4ChB5xokfRcg3VEwqfOoIIexjUhZY5X9AgMBAAGjggHzMIIB7zAfBgNVHSMEGDAWgBTn AiOAAE/Y17yUC9k/dDlJMjyKeTAdBgNVHQ4EFgQUjqBhf3GcBV6YGYSmp2iS4Wi/3N4wDAYDVR0T AQH/BAIwADAlBgNVHREEHjAcgRp0aW0uaG9sbGViZWVrQGRpZ2ljZXJ0LmNvbTAOBgNVHQ8BAf8E BAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYKYIZIAYb9 bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMIGIBgNVHR8E gYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJ RENBLWcyLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFz c3VyZWRJRENBLWcyLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw LmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0Rp Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG9w0BAQsFAAOCAQEAmOLw9+cVMHn8tJ0k 76baCfFZwkvfvxSAlCXo+Fcsv55/og0V065Rpb4HvVTi0e0qKCMbBxc71NWxhMvKJHt+sfSmVatX mAOPNDRvtVvJBkcd0bvzMut/r3npQqs1wezHLtAq+MlQZDjgiJB+DkNblnnphzEQSp7q/4K9oMoP KViRxBv+/kseA8GOfhHU6EVmeu9xQrBqexH1DPUrUSGpNGDyvtUaU+bBy8Kz2hQfOu6f/73wLqUx e583C9y2Gqn1xCB77yPxXqRSLLRC6FbrToJbKiFYQJ4znZZyhPYJHL0SOpWyXfVKp4PEO54A/xr5 oVyPhEQhOtasoIRCLtHZrzCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcN AQELBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEz MTEwNTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hB MiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/A J3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr+Lp+ yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQelAfJUXo 8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK3OnZ9ZEXjsYh rTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uCig1xGOSm4IksG/Oy czzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNV HQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdp Y2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdp Q2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9E aWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwME MIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6 Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMA ZQAgAG8AZgAgAHQAaABpAHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0 AHUAdABlAHMAIABhAGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMA ZQByAHQAIABDAFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABh AHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkA YQBiAGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP 2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrgYhmZ pgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg4/mgVgxI EM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmwXZG0k4f5lpaB VUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1YEhEybr1DDE0023vG QtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIxggO/MIIDuwIBATB5MGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5j b20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQDi7WjgxCjxTrYbReNHes EzANBglghkgBZQMEAgEFAKCCAhcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMTkwODE0MTU1OTA5WjAvBgkqhkiG9w0BCQQxIgQgJCVViyYAFZqVrb1TltRidJZZzj6A WNfJ/i8bxfs+1L8wgYgGCSsGAQQBgjcQBDF7MHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERp Z2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOthtF40d6wTMIGKBgsqhkiG9w0BCRACCzF7oHkw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOth tF40d6wTMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggq hkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAsGCWCG SAFlAwQCATALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAcGBSsOAwIaMA0GCSqGSIb3DQEBAQUA BIIBAHvFlvfkMJvdV/GN+yIkzhLO/T7r01dhfVE93Ba652K4lhO0CsSHSKdKb0pOkm8bnSjoZ97s pMgsic1WQjyLIEXZRoJB254hmyu5w8Lg1gytRvuVG8RuNGnP3KEUJ0iGcqeFvphidcfSpj4HVGwv aHD0F9O1kyRlmyfoPIVLPVhrC9/CmuvmijDvS7QIhvzsL9PChCPyWUHdO8vgpOkhSgp5tKlIDfuV HdqBtbrk/A9sOHOsq+gLnwljyHY+a/yaZFKlmpQqFqoasBLBF0CcGRt2qvLQAcBV18p3Nkz1uMZY QI1oMr5aZcHdCjuAI/URLsv0mFd/26NSM4OKRiakgYUAAAAAAAA= ------=_NextPart_000_0158_01D55297.AE5A23E0-- From nobody Wed Aug 14 09:03:34 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A67212082B for ; Wed, 14 Aug 2019 09:03:33 -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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=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=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 UaaUvz8W4fIc for ; Wed, 14 Aug 2019 09:03:31 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 6FBD112026E for ; Wed, 14 Aug 2019 09:03:31 -0700 (PDT) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id x7EFvg8r008255; Wed, 14 Aug 2019 17:03:23 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=4D+xhyHyNUGOIKp53EgmEi//52zTBx12RBjbKtGv6lE=; b=G2bTiZeNGgQILzpwmAB/8rOZ80/NNZJZ5E+TDzNjqi1uvRcc60Wa9LLHGT8mYu9Sav2y uy+FNVIbg4TJifCnYZuMff7RiOaOEhHab5o8BrBM/8XWsCjnrjxnCJAK7YmRoQJ+6yyu IXuAHPa1J7iqjW4RIRrO9+WVBBAy8ziKa6J9jics5XmAQf5dlZhe0pK4oqtA+F20K2b0 Ub/tDghCh+NOp28Znip+TPgpX4DA7H25UrYwn8yyyS+flOB+1abvZkVzdXOdDp5sKLBJ SW+vKM7VTg8AYkV3B+DASDOlJtxrut47sYjEw1OohTyvNp45QbzqKIoZRSyAD8TM+E8I 5Q== Received: from prod-mail-ppoint4 (prod-mail-ppoint4.akamai.com [96.6.114.87] (may be forged)) by m0050093.ppops.net-00190b01. with ESMTP id 2ubf8n9myg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 14 Aug 2019 17:03:23 +0100 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x7EG35nf014217; Wed, 14 Aug 2019 12:03:22 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.53]) by prod-mail-ppoint4.akamai.com with ESMTP id 2u9s91stkk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 14 Aug 2019 12:03:22 -0400 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.1473.3; Wed, 14 Aug 2019 12:03:15 -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.1473.005; Wed, 14 Aug 2019 12:03:15 -0400 From: "Salz, Rich" To: Tim Hollebeek , Ryan Sleevi , Stephen Farrell CC: LAMPS WG , Russ Housley Thread-Topic: [lamps] Proposed charter update regarding clarifications Thread-Index: AQHVRHASgHWOyDxjrUu01gmCUVZJrKbe47iAgAAEtQCAHEQsAP//vhUA Date: Wed, 14 Aug 2019 16:03:15 +0000 Message-ID: <762673AF-FADB-458B-B79A-E3E483BD3DDD@akamai.com> References: <3DB1B550-26FA-4F93-8CFA-434C1F8811D1@vigilsec.com> <46773340-6bba-6c54-7049-c6ec30488174@cs.tcd.ie> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1c.0.190812 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.37.20] Content-Type: multipart/alternative; boundary="_000_762673AFFADB458BB79AE3E483BD3DDDakamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-08-14_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=940 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1908140155 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:5.22.84,1.0.8 definitions=2019-08-14_06:2019-08-14,2019-08-14 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 mlxlogscore=921 phishscore=0 suspectscore=0 spamscore=0 mlxscore=0 clxscore=1011 bulkscore=0 lowpriorityscore=0 malwarescore=0 impostorscore=0 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1906280000 definitions=main-1908140155 Archived-At: Subject: Re: [lamps] Proposed charter update regarding clarifications X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2019 16:03:33 -0000 --_000_762673AFFADB458BB79AE3E483BD3DDDakamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PknigJltIG5vdCBpbiBmYXZvciBvZiBoYXZpbmcgdG8gYm90aGVyIHRoZSBBRCBmb3IgYSByZS1j aGFydGVyIGZvciBldmVyeSBtaW5vciBjbGFyaWZpY2F0aW9uLiAgSXQgaXMgbm90IGEgcHJvZHVj dGl2ZSB1c2Ugb2YgYW55b25l4oCZcyB0aW1lLg0KDQpJIHVuZGVyc3RhbmQgdGhlIG1vdGl2YXRp b24g4oCTIG5vYm9keSB3YW50cyBhIHpvbWJpZSBXRyB0aGF0IHNoYW1ibGVzIGFsb25nIGZvcmV2 ZXIgd2l0aG91dCBkeWluZyDigJMgYnV0IEkgdGhpbmsgdGhlIGNvbmNlcm4gaXMgbm8gbG9uZ2Vy IHdhcnJhbnRlZDsgd2XigJlyZSBub3Qgc2NhcmVkIG9mIFBLSVgtUmVkdXggYW55IG1vcmUuDQo= --_000_762673AFFADB458BB79AE3E483BD3DDDakamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5F bWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUx OQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29y ZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBp biAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwv c3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPiZndDs8L3NwYW4+PC9iPknigJltIG5v dCBpbiBmYXZvciBvZiBoYXZpbmcgdG8gYm90aGVyIHRoZSBBRCBmb3IgYSByZS1jaGFydGVyIGZv ciBldmVyeSBtaW5vciBjbGFyaWZpY2F0aW9uLiZuYnNwOyBJdCBpcyBub3QgYSBwcm9kdWN0aXZl IHVzZSBvZiBhbnlvbmXigJlzIHRpbWUuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgdW5kZXJz dGFuZCB0aGUgbW90aXZhdGlvbiDigJMgbm9ib2R5IHdhbnRzIGEgem9tYmllIFdHIHRoYXQgc2hh bWJsZXMgYWxvbmcgZm9yZXZlciB3aXRob3V0IGR5aW5nIOKAkyBidXQgSSB0aGluayB0aGUgY29u Y2VybiBpcyBubyBsb25nZXIgd2FycmFudGVkOyB3ZeKAmXJlIG5vdCBzY2FyZWQgb2YgUEtJWC1S ZWR1eCBhbnkgbW9yZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_762673AFFADB458BB79AE3E483BD3DDDakamaicom_-- From nobody Wed Aug 14 09:46:58 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0A37120B71 for ; Wed, 14 Aug 2019 09:46:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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_MED=-2.3, SPF_HELO_NONE=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=cs.tcd.ie 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 wSe7t7vibaZX for ; Wed, 14 Aug 2019 09:46:55 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED6E0120B74 for ; Wed, 14 Aug 2019 09:46:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id AF36CBE5D; Wed, 14 Aug 2019 17:46:52 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G6eknTJkDkYZ; Wed, 14 Aug 2019 17:46:52 +0100 (IST) Received: from [134.226.36.93] (unknown [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 4C865BE5B; Wed, 14 Aug 2019 17:46:52 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1565801212; bh=3crozSo3p6wUeQH7wEwQSUXL6MvuVcKL9GOv71fJ6Ks=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=CKShmhKVqCX4m8rfOh2P6Lfuz+coyvm7u0YzqkqiZVijbyxjuUsi0dDD6B2JBbYjX XZ0AkY2Ipps/myBgaUOpQwpoVsIcGvk3p+tadNouedqFLLAK8286mSCypUtpGXs7cq FKi+vhHH//XMwVlNJN807orVsL5AKd7SCnlSzZPw= To: "Salz, Rich" , Tim Hollebeek , Ryan Sleevi Cc: LAMPS WG , Russ Housley References: <3DB1B550-26FA-4F93-8CFA-434C1F8811D1@vigilsec.com> <46773340-6bba-6c54-7049-c6ec30488174@cs.tcd.ie> <762673AF-FADB-458B-B79A-E3E483BD3DDD@akamai.com> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: Date: Wed, 14 Aug 2019 17:46:52 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <762673AF-FADB-458B-B79A-E3E483BD3DDD@akamai.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="lVvwzZxbZpNfm7bsnEjOqueFB0pRJ7IbB" Archived-At: Subject: Re: [lamps] Proposed charter update regarding clarifications X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2019 16:46:57 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --lVvwzZxbZpNfm7bsnEjOqueFB0pRJ7IbB Content-Type: multipart/mixed; boundary="oApom7Shjc69cfOBj0Bk0woRA4p3BHy4r"; protected-headers="v1" From: Stephen Farrell To: "Salz, Rich" , Tim Hollebeek , Ryan Sleevi Cc: LAMPS WG , Russ Housley Message-ID: Subject: Re: [lamps] Proposed charter update regarding clarifications References: <3DB1B550-26FA-4F93-8CFA-434C1F8811D1@vigilsec.com> <46773340-6bba-6c54-7049-c6ec30488174@cs.tcd.ie> <762673AF-FADB-458B-B79A-E3E483BD3DDD@akamai.com> In-Reply-To: <762673AF-FADB-458B-B79A-E3E483BD3DDD@akamai.com> --oApom7Shjc69cfOBj0Bk0woRA4p3BHy4r Content-Type: multipart/mixed; boundary="------------C3597C2CA3BD7BCA79D02852" Content-Language: en-GB This is a multi-part message in MIME format. --------------C3597C2CA3BD7BCA79D02852 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 14/08/2019 17:03, Salz, Rich wrote: > we=E2=80=99re not scared of PKIX-Redux any more. At least one of us is. (Meaning me:-) I do think the "who's gonna really implement and will it get deployed" questions are still needed in this space. I say that as someone who has sinned in the past in exactly the way I'd like to see us avoid repeating. Cheers, S --------------C3597C2CA3BD7BCA79D02852 Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------C3597C2CA3BD7BCA79D02852-- --oApom7Shjc69cfOBj0Bk0woRA4p3BHy4r-- --lVvwzZxbZpNfm7bsnEjOqueFB0pRJ7IbB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl1UOvwACgkQWrL68XsX K+o/ShAAgYaMnk1kkiZmZK3HIM4DeZDZ+qhfDzuI4X1TAaIJmEemIrMP8Pv5TowZ iebaWj/2Wcrf3a4uNVSeS+vB3uzPLNEdUhGG+UQMpxWSUpagMUOVfl+UHLZ1jDjV /qgc4d1uUPyZhvguK+5L8yFB2eWerO5T7sjV15Trlk5K0tCxlObt9i0aFsfFu/Gu DzhXWxreG9icRF+rLov57IjXagKN9YibwZn5IPNyxSYADwikjztzHID2GJhLS3h7 9c1tuysJYAp89suBSLuZiUklgJcVTEbOPj27fkzyCJuIWVOCybyR4MAhWua81To9 fmne74HZVCPLdCzp8LMASXmg+OyLAiUZXSQSh4bfZrdVqTCGulbBpdGoeYZbA/WJ o4o8OqLOHyLwABe469l0L1oKA5iED4Ep+FLYzkMygy2qFPcpOAczAvTqHbRQkLxw TIN3lzm9ZWxMipNkkQpiSTnRZkq71Q+20/YsI+XU/ScElsNfutJ2rYoLRSBNPrPN dzZchuicI3a/guIo48Y49T/DZwCMSYQaJngERwQckSo4hyKZK6cALkZz6IivQ9cr YoCfoy85cXhOV27LdvCM7JqMresLo1jnehynUIfYj7aIscgFMzzaZeUWOeVGgYNF fEup1w0HWD5g4awrKZfo1Sb6Nngox4WYNzr9KW8jYYQS9psp9/w= =5dN4 -----END PGP SIGNATURE----- --lVvwzZxbZpNfm7bsnEjOqueFB0pRJ7IbB-- From nobody Thu Aug 15 12:10:25 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D5EE120142; Thu, 15 Aug 2019 12:10:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 bp-FKJGTs5gG; Thu, 15 Aug 2019 12:10:17 -0700 (PDT) Received: from mail-oi1-f182.google.com (mail-oi1-f182.google.com [209.85.167.182]) (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 77CEB120147; Thu, 15 Aug 2019 12:10:12 -0700 (PDT) Received: by mail-oi1-f182.google.com with SMTP id p124so3032789oig.5; Thu, 15 Aug 2019 12:10:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=llFFtfqY9Rg6kVr5D1wfrBpp+BQ0fsYGOtSKCENjvnQ=; b=Zyb23zqginfBi0TMkhsuedMm4lTTMTvl3Xj23Tidck7yX08CD1i1jW/8zEL8XQvaPn +Bfb0yTJSQplXuTLlJABBsu3cAbDvF3M+i++S/p0qUghXLfjqXurDWgeYswR/8Kz1xlo Y3sqkI9lLPcgfrHB3ETGCF9/mxSMilb0/xMwd5XyW6j079i/PMnHs0YrGOwN4ZHCUw7b 6ObqPk78b0qGdh4dco4b12GjQLm0p1Z1XZksdS1AMmQz1qa36L1MkLEQRNNbFQUeUziz /9uKOx2dTCtCjX3Gh7EDMrGaIk1ggCSWEg4y0nzmX1EI9sQDiuwHl5yRrwNbxDF/MwsG JHBw== X-Gm-Message-State: APjAAAX7l4j7m0HIQnOMSNCfXnMR4o/Vom6mlnEqElfihCo551mtTGA5 zZoJIpAWhdaRtehNqHa6dZrGpXmhwGtq+AVL6ofjZaB0 X-Google-Smtp-Source: APXvYqz3argZa1CGAVNw+vcXGbQ6D5T3earWKeNZlkoPgA/lZ9Go+MhT69cXPnLxj9YakC6Fk9R5TAJ6us0zNOaTvhs= X-Received: by 2002:aca:ea45:: with SMTP id i66mr2676398oih.17.1565896211235; Thu, 15 Aug 2019 12:10:11 -0700 (PDT) MIME-Version: 1.0 From: Phillip Hallam-Baker Date: Thu, 15 Aug 2019 15:10:01 -0400 Message-ID: To: SPASM , mathmesh@ietf.org Content-Type: multipart/alternative; boundary="0000000000006d0d8005902c9f89" Archived-At: Subject: [lamps] pkix-keyinfo content type X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2019 19:10:19 -0000 --0000000000006d0d8005902c9f89 Content-Type: text/plain; charset="UTF-8" I just applied for a provisional IANA media type 'pkix-keyinfo' for use in computing UDF values and it occurs to me that I should make LAMPS aware of the proposed use. The spec is available here: https://tools.ietf.org/html/draft-hallambaker-mesh-udf-05 http://mathmesh.com/Documents/draft-hallambaker-mesh-udf.html#n-pkix-certificates-and-keys I strongly recommend using the second version as it uses the new HTML RFC format to rended superscripts and subscripts etc. In brief, the idea is to allow a single fingerprint format to be used to encode any content type without semantic substitution attacks. So to take the digest of a public key, we first generate the PKIX SubjectPublicKeyInfo : SubjectPublicKeyInfo ::= SEQUENCE { algorithm AlgorithmIdentifier, subjectPublicKey BIT STRING } Then we take this octet stream and calculate: H ( "application/pkix-keyinfo:" + H() ) Where + is concatenation. The reason the new content type is required is that there has not been an application that would make use of a SubjectPublicKeyInfo fragment in isolation before. --0000000000006d0d8005902c9f89 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I j= ust applied for a provisional IANA media type 'pkix-keyinfo' for us= e in computing UDF values and it occurs to me that I should make LAMPS awar= e of the proposed use.

Th= e spec is available here:

http= s://tools.ietf.org/html/draft-hallambaker-mesh-udf-05=C2=A0
http://mathmesh.com/Documents/draft-hallambaker-mesh-udf.html#n-pkix-= certificates-and-keys=C2=A0=C2=A0

I strongly recommend using the second version as it uses t= he new HTML RFC format to rended superscripts and subscripts etc.

In brief, the idea is to allow a s= ingle fingerprint format to be used to encode any content type without sema= ntic substitution attacks. So to take the digest of a public key, we first = generate the PKIX=C2=A0SubjectPublicKeyInfo=C2=A0:
=C2=A0=
=C2=A0 SubjectPublicKeyInfo=C2=A0 ::=3D=C2=A0 =
SEQUENCE=C2=A0 {
=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 algorithm=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 AlgorithmIdentifier,
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 subjectPublicKey=C2=A0=C2=A0=C2=A0=C2=A0 BIT STRING=C2=A0 }
Then= we take this octet stream <SubjectPublicKeyInfo> and calculate:
=

H ( "application/pkix-key= info:"=C2=A0+ H(<SubjectPublicKeyInfo>) )

Where=C2=A0+ is concatenation.

The reason the new content type is requi= red is that there has not been an application that would make use of a SubjectPubli= cKeyInfo fragment in isolation before.
--0000000000006d0d8005902c9f89-- From nobody Thu Aug 15 17:24:19 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E708F120103; Thu, 15 Aug 2019 17:24:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 oDHDAWoQK-cz; Thu, 15 Aug 2019 17:24:07 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 509B41200F3; Thu, 15 Aug 2019 17:24:06 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id E2E563818C; Thu, 15 Aug 2019 20:23:14 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 8C852788; Thu, 15 Aug 2019 20:24:04 -0400 (EDT) From: Michael Richardson To: Phillip Hallam-Baker cc: SPASM , mathmesh@ietf.org In-Reply-To: References: X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [lamps] [Mathmesh] pkix-keyinfo content type X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2019 00:24:10 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Phillip Hallam-Baker wrote: > In brief, the idea is to allow a single fingerprint format to be used > to encode any content type without semantic substitution attacks. So = to > take the digest of a public key, we first generate the PKIX > SubjectPublicKeyInfo : > SubjectPublicKeyInfo ::=3D SEQUENCE { > algorithm AlgorithmIdentifier, > subjectPublicKey BIT STRING } > Then we take this octet stream and calculate: > H ( "application/pkix-keyinfo:" + H() ) > Where + is concatenation. This is not consistent with rfc5280 suggestion on how to create SubjectKeyI= dentifier. I've just been through how to specify a non-SHA-1 bound version of that, and RFC7469 section 2.4 has suggestions. As SubjectKeyIdentifier can be calculated by any suitable way and used if it is present, it's only for the case that it is not present that is a problem. Typically only CA:TRUE certificates are supposed to have it present. I'd like it to be present for all certificates. So your construction would be: H ( "application/pkix-keyinfo:" + SubjectKeyIdentifier ) and I think that is fine, as long as it does not cause confusion. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [ ] Michael Richardson, Sandelman Software Works | IoT architect = [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl1V96QACgkQgItw+93Q 3WWonAgAhiDoEvKsQsqad13iAJLljqDCZrlbUtKvh6c/Nq4fhWd3zfNGgg9LjUeW 9jWzBEHYARFtQUsSziADExDVRV4mUvHg6g9d6/FXE9Peg8DbxSM60UhMm4WIrmxn AW51I+K81HlQpS+u8olNKBsaK6F3haDhpDzejLyReaXHeaJjzj6bhM/8XCAaPAtN abCqj07UA+BK9QDAwaF8P+R7/b/t26KErX3VPlYDiJC+4XnJ6y/tnIpb5aRG4aVL tZSIkaAQ98c1DVGIiyGFMmZaypOBfzMPVwXN7L6ePRe2t6KQ7O8GY2abe84Kxwv9 2HoYZ6/HQxr3VNuYshoAuIC8OPtNKw== =eTpn -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Aug 16 07:21:58 2019 Return-Path: X-Original-To: spasm@ietf.org Delivered-To: spasm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D1301207FC; Fri, 16 Aug 2019 07:21:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Robert Sparks via Datatracker To: Cc: spasm@ietf.org, draft-ietf-lamps-cms-mix-with-psk.all@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Robert Sparks Message-ID: <156596530298.31942.9549106338899451672@ietfa.amsl.com> Date: Fri, 16 Aug 2019 07:21:43 -0700 Archived-At: Subject: [lamps] Genart telechat review of draft-ietf-lamps-cms-mix-with-psk-06 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2019 14:21:43 -0000 Reviewer: Robert Sparks Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at . Document: draft-ietf-lamps-cms-mix-with-psk-06 Reviewer: Robert Sparks Review Date: 2019-08-16 IETF LC End Date: None IESG Telechat date: 2019-08-22 Summary: Ready for publication as a Proposed Standard RFC From nobody Fri Aug 16 10:22:08 2019 Return-Path: X-Original-To: spasm@ietf.org Delivered-To: spasm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E552B12008D; Fri, 16 Aug 2019 10:21:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-lamps-cms-mix-with-psk@ietf.org, Tim Hollebeek , lamps-chairs@ietf.org, tim.hollebeek@digicert.com, spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <156597611893.31967.2500700648100356711.idtracker@ietfa.amsl.com> Date: Fri, 16 Aug 2019 10:21:58 -0700 Archived-At: Subject: [lamps] Benjamin Kaduk's Discuss on draft-ietf-lamps-cms-mix-with-psk-06: (with DISCUSS and COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2019 17:21:59 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-lamps-cms-mix-with-psk-06: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-mix-with-psk/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I think we need to have a discussion about the abstract API for a KEY-DERIVATION instance and how that relates to what we need for a key combination operation. In Section 5 we assume that we can use the HKDF terminology, but that doesn't seem to hold universally for KEY-DERIVATION; for example, while HKDF has IKM, salt, and info, PBKDF2 (from RFC 3211 that AFAICT introduces keyDerivationalgorithm for CMS) is specified by RFC 2898 as taking just the input secret (password) and a salt, with no separate 'info' (and of course the different iteration count and PRF parameters needed for its construction). I note (with chagrin, as sponsoring AD) that RFC 8619 says "PARAMS ARE absent" for the HKDF-based KEY-DERIVATION instances but is silent about how one is supposed to know what to pass for salt/info (the IKM we can perhaps assume will be obvious). In short, should we be seeking to define a distinct key combination operation like KRB-FX-CF2 (RFC6113) rather than trying to repurpose key derivation? Some KDFs support this fairly well, but it's not clear to me that it is a universal property. For example, the proof in [H2019] seems to be assuming HKDF but this draft does not (as is clearly seen from the use of the X9.63 KDF in one of the examples). ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Do we need to document the risk of "algorithm mismatch" that is present because we use separate algorithm identifiers for KDF, key-encryption, key-agreement, etc. (vs. a "cipher-suite"-like approach that bundles together a known-good combination)? In particular, I see we talk about the key length for content- and key-encryption algorithms, but are there other constraints that should be applied? Section 2 The PSK MUST be distributed to the sender and all of the recipients by some out-of-band means that does not make it vulnerable to the future invention of a large-scale quantum computer, and an identifier MUST be assigned to the PSK. What are the uniqueness/scope requirements for that identifier? Section 3 ktris contains one KeyTransRecipientInfo type for each recipient; it uses a key transport algorithm to establish the key-derivation key. KeyTransRecipientInfo is described in Section 6.2.1 of [RFC5652]. I think we need to be more clear that the 'encryptedKey' member of KeyTransRecipientInfo contains not the "result of encrypting the content-encryption key for this recipient" per RFC 5652, but rather the "result of encrypting the key-derivation key for this recipient". That is, to call out how we are deviating from RFC 5652. Section 5 Many key derivation functions (KDFs) internally employ a one-way hash function. When this is the case, the hash function that is used is identified by the KeyDerivationAlgorithmIdentifier. HKDF [RFC5869] (editorial?) This reads as if the KeyDerivationAlgorithmIdentifier is going to be (e.g.) 2.16.840.1.101.3.4.2.1 for regular SHA-256, which is presumably not the case. It sounds more like "indicated by" or "indicated as part of the semantics of the" would be more appropriate. (side note) Is there a story behind using 5 and 10 for the ENUMERATED values? CMSORIforPSKOtherInfo ::= SEQUENCE { psk OCTET STRING, keyMgmtAlgType ENUMERATED { keyTrans (5), keyAgree (10) }, keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, pskLength INTEGER (1..MAX), kdkLength INTEGER (1..MAX) } If psk is encoded as an OCTET STRING (i.e., including its length), why do we need a separate pskLength field? Section 7 material. Compromise of the key-encryption key may result in the disclosure of all content-encryption keys or content-authenticated- encryption keys that were protected with that keying material, which in turn may result in the disclosure of the content. a nit, but for the key-agreement variant we have two things that we call "key-encryption key"s, so use of the definite article here is potentially ambiguous. This specification does not require that PSK is known only by the sender and recipients. The PSK may be known to a group. Since confidentiality depends on the key transport or key agreement algorithm, knowledge of the PSK by other parties does not enable eavesdropping. However, group members can record the traffic of Would it be appropriate to add either "inherently" (enable eavesdropping) or "with currently available technology"? Implementers should be aware that cryptographic algorithms become weaker with time. As new cryptoanalysis techniques are developed and nit: "cryptanalysis" Section 8 With respect to "not really making privacy worse", this does seem to risk exposing that a group of (identified) recipients/participants share access to a single PSK (identity), which could potentially correlate them for other sorts of surveillance/attack. Section 10.2 Don't RFCs 5911, 5912, and 6268 need to be normative since we import from them in the ASN.1 module? Section A.1 [I did not attempt to validate the examples.] The pre-shared key known to Alice and Bob: c244cdd11a0d1f39d9b61282770244fb0f6befb91ab7f96cb05213365cf95b15 (Should we say it's in hex? Similarly for other non-ASCII-armored fields, especially the PSK identifier which looks like it is more of a string than a hex-encoded binary blob) From nobody Fri Aug 16 11:09:19 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 078331200F4 for ; Fri, 16 Aug 2019 11:09:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] 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 ORbRjAlDuKBx for ; Fri, 16 Aug 2019 11:09:07 -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 3061E1200CD for ; Fri, 16 Aug 2019 11:09:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 213B4300B05 for ; Fri, 16 Aug 2019 13:49:49 -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 uT6r92WUJFlK for ; Fri, 16 Aug 2019 13:49:47 -0400 (EDT) Received: from a860b60074bd.fios-router.home (unknown [138.88.156.37]) by mail.smeinc.net (Postfix) with ESMTPSA id 1FF42300ADA; Fri, 16 Aug 2019 13:49:47 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Russ Housley In-Reply-To: <156597611893.31967.2500700648100356711.idtracker@ietfa.amsl.com> Date: Fri, 16 Aug 2019 14:09:03 -0400 Cc: IESG , LAMPS WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <156597611893.31967.2500700648100356711.idtracker@ietfa.amsl.com> To: Ben Kaduk X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [lamps] Benjamin Kaduk's Discuss on draft-ietf-lamps-cms-mix-with-psk-06: (with DISCUSS and COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2019 18:09:10 -0000 Ben: Thanks for doing all of the reading necessary to raise this question. I want to respond to the DISCUSS in this note. I'll tackle the = non-blocking comments is a separate message. > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > I think we need to have a discussion about the abstract API for a > KEY-DERIVATION instance and how that relates to what we need for a key > combination operation. In Section 5 we assume that we can use the > HKDF terminology, but that doesn't seem to hold universally for > KEY-DERIVATION; for example, while HKDF has IKM, salt, and info, = PBKDF2 > (from RFC 3211 that AFAICT introduces keyDerivationalgorithm for CMS) = is > specified by RFC 2898 as taking just the input secret (password) and a > salt, with no separate 'info' (and of course the different iteration > count and PRF parameters needed for its construction). I note (with > chagrin, as sponsoring AD) that RFC 8619 says "PARAMS ARE absent" for > the HKDF-based KEY-DERIVATION instances but is silent about how one is > supposed to know what to pass for salt/info (the IKM we can perhaps > assume will be obvious). >=20 > In short, should we be seeking to define a distinct key combination > operation like KRB-FX-CF2 (RFC6113) rather than trying to repurpose = key > derivation? Some KDFs support this fairly well, but it's not clear to > me that it is a universal property. For example, the proof in [H2019] > seems to be assuming HKDF but this draft does not (as is clearly seen > from the use of the X9.63 KDF in one of the examples). NIST SP 800-56 Revision 1 offers this high-level interface to the KDF: KDF(Z, OtherInput) - Z: a byte string that represents the shared secret. This ic called = IKM in the HKDF terminology. - OtherInput includes: -- salt - a non-null (secret or non-secret) byte string. =20 -- L - a positive integer that indicates the length (in bits) = of the secret keying material to be derived. -- FixedInfo - a bit string of context-specific data that is = appropriate for the relying key-establishment scheme. I do not think that this very high level of API really solves your = concern, but it did guide my thinking in writing the document. The KDF algorithm identifier has this structure: AlgorithmIdentifier ::=3D SEQUENCE { algorithm OBJECT IDENTIFIER, parameters ANY DEFINED BY algorithm OPTIONAL } The algorithm part lets us name many different KDFs. As you point out, = the examples in Appendix A and Appendix B use HKDF and X9.63 KDF. Recent discussions in the LAMPS WG show a big bias against complex = parameter strictures. Instead, people have voiced a strong preference = for an object identifier that names all of the options. This leads to = more object identifier assignments, but clear understanding of all = options when one is chosen or negotiated. The one exception is an = initialization vector, where a fresh value is expected each time the = algorithm is invoked. So, in this document, I have defined a structure of the OtherInput = portion of the NIST API. If a particular KDF needs to use a value from = that structure in a particular way, is can do so. The document uses = HKDF terminology. If a KDF requires a salt, then it should be provided as a parameter. I = can certainly add that to the document. I believe that KMAC128 and = KMAC256 are algorithms that require a salt. Russ From nobody Tue Aug 20 11:26:58 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBFFC12082A for ; Tue, 20 Aug 2019 11:26:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 VXVqu7q9Q8ex for ; Tue, 20 Aug 2019 11:26:55 -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 494CD12011C for ; Tue, 20 Aug 2019 11:26:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 4C8C4300AB1 for ; Tue, 20 Aug 2019 14:07:37 -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 7Lngd2a9B6xI for ; Tue, 20 Aug 2019 14:07:36 -0400 (EDT) Received: from a860b60074bd.fios-router.home (unknown [138.88.156.37]) by mail.smeinc.net (Postfix) with ESMTPSA id 08017300250 for ; Tue, 20 Aug 2019 14:07:35 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 20 Aug 2019 14:26:52 -0400 References: <3DB1B550-26FA-4F93-8CFA-434C1F8811D1@vigilsec.com> To: LAMPS WG In-Reply-To: <3DB1B550-26FA-4F93-8CFA-434C1F8811D1@vigilsec.com> Message-Id: <944A9935-0A08-45E2-BD97-C21BF9EE18CF@vigilsec.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [lamps] Proposed charter update regarding clarifications X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2019 18:26:57 -0000 No many people have spoken. I am assuming that is because many people = take time off in August. Right now roughly as many people support this = addition as oppose it. Please speak your mind. Russ > On Jul 27, 2019, at 7:40 AM, Russ Housley = wrote: >=20 > At the meeting in Montreal, we suggested a charter update to allow = clarifications. I suggest: >=20 > OLD: >=20 > In addition, the LAMPS WG may investigate other updates to documents > produced by the PKIX and S/MIME WGs, but the LAMPS WG shall not adopt > any of these potential work items without rechartering. >=20 > NEW: >=20 > In addition, the LAMPS WG may investigate other updates to documents > produced by the PKIX and S/MIME WG. The LAMPS WG may produce > clarifications where needed, but the LAMPS WG shall not adopt > anything beyond clarifications without rechartering. >=20 > Thoughts? >=20 > Russ From nobody Tue Aug 20 11:49:41 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3E58120145 for ; Tue, 20 Aug 2019 11:49:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=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=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 0ZcV_BZKH8nL for ; Tue, 20 Aug 2019 11:49:38 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 DB8DB120099 for ; Tue, 20 Aug 2019 11:49:38 -0700 (PDT) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id x7KIb4iX021080; Tue, 20 Aug 2019 19:49:34 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=P03T5dCtzbecWJm342EMJSkTWNgBlOW8ZmryRB8Uk00=; b=gFORUb4oLWExpTA5H1fH9qrf1J6U+eWEc+nkI9z4PL+E/1S68XlMZfKeKZO23baH6blc yX8WOpiwB9b7X9HeBbKTEPyl3S/jP4Cd/JY2/vSCWY2XTR+fH4yZYaxvnC7qlZGx5B1l RIPuyxFlWqdF0YJxZzg8BuC8GHwh9PUvrD+TVN3wQqRHjvThAqWz1EDR/McUPoZlsmJn sYWvpvNKKqMsXhVuQ6RWPk9TvE3DASRRxvFsv37ziSovSjGKMdSsHT9qr4lIVACGw5Gu zjU+4vVGTwABvmf3YplCocpKHU6Z6zgZWOwiD0cU6CejZp6d3MTPmiEm+SYDw1+/VPvS 2g== Received: from prod-mail-ppoint6 (prod-mail-ppoint6.akamai.com [184.51.33.61] (may be forged)) by m0050095.ppops.net-00190b01. with ESMTP id 2ue943ffs2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 20 Aug 2019 19:49:34 +0100 Received: from pps.filterd (prod-mail-ppoint6.akamai.com [127.0.0.1]) by prod-mail-ppoint6.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x7KIW9ce014375; Tue, 20 Aug 2019 14:49:32 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint6.akamai.com with ESMTP id 2uecww5vxa-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 20 Aug 2019 14:49:32 -0400 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.1473.3; Tue, 20 Aug 2019 14:49:32 -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.1473.005; Tue, 20 Aug 2019 14:49:32 -0400 From: "Salz, Rich" To: Russ Housley , LAMPS WG Thread-Topic: [lamps] Proposed charter update regarding clarifications Thread-Index: AQHVV4TgMbw/A96Z8UaEk4p2ObIvkKcEYPaA Date: Tue, 20 Aug 2019 18:49:31 +0000 Message-ID: <71CCE747-EE0F-4C33-982E-42E12C16C2F1@akamai.com> References: <3DB1B550-26FA-4F93-8CFA-434C1F8811D1@vigilsec.com> <944A9935-0A08-45E2-BD97-C21BF9EE18CF@vigilsec.com> In-Reply-To: <944A9935-0A08-45E2-BD97-C21BF9EE18CF@vigilsec.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1c.0.190812 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.35.102] Content-Type: text/plain; charset="utf-8" Content-ID: <4435C6388E07E34EB54246EE08BDD465@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-08-20_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=817 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1908200166 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:5.22.84,1.0.8 definitions=2019-08-20_08:2019-08-19,2019-08-20 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 clxscore=1015 lowpriorityscore=0 suspectscore=0 mlxscore=0 mlxlogscore=831 malwarescore=0 spamscore=0 adultscore=0 impostorscore=0 phishscore=0 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1906280000 definitions=main-1908200167 Archived-At: Subject: Re: [lamps] Proposed charter update regarding clarifications X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2019 18:49:40 -0000 SSBhbSBva2F5IHdpdGggdGhlIE5FVyB0ZXh0LiAgSSBhbSBhbHNvIG5vdCBib3RoZXJlZCB0b28g bXVjaCBieSB0aGUgT0xEIHRleHQuDQoNCg0K From nobody Tue Aug 20 12:37:21 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1232120874 for ; Tue, 20 Aug 2019 12:37:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 HhKxyTWZ3oGR for ; Tue, 20 Aug 2019 12:37:18 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3069A120857 for ; Tue, 20 Aug 2019 12:37:17 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 7AB8D380BE; Tue, 20 Aug 2019 15:36:19 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 8550CE82; Tue, 20 Aug 2019 15:37:16 -0400 (EDT) From: Michael Richardson To: Russ Housley cc: LAMPS WG In-Reply-To: <944A9935-0A08-45E2-BD97-C21BF9EE18CF@vigilsec.com> References: <3DB1B550-26FA-4F93-8CFA-434C1F8811D1@vigilsec.com> <944A9935-0A08-45E2-BD97-C21BF9EE18CF@vigilsec.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Date: Tue, 20 Aug 2019 15:37:16 -0400 Message-ID: <6531.1566329836@localhost> Archived-At: Subject: Re: [lamps] Proposed charter update regarding clarifications X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2019 19:37:20 -0000 Russ Housley wrote: > No many people have spoken. I am assuming that is because many people > take time off in August. Right now roughly as many people support this > addition as oppose it. Please speak your mind. I'm in favour. From nobody Tue Aug 20 13:19:27 2019 Return-Path: X-Original-To: spasm@ietf.org Delivered-To: spasm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 31EC5120086; Tue, 20 Aug 2019 13:19:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Phillip Hallam-Baker via Datatracker To: Cc: spasm@ietf.org, draft-ietf-lamps-cms-mix-with-psk.all@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Phillip Hallam-Baker Message-ID: <156633236010.354.17330616899278153955@ietfa.amsl.com> Date: Tue, 20 Aug 2019 13:19:20 -0700 Archived-At: Subject: [lamps] Secdir telechat review of draft-ietf-lamps-cms-mix-with-psk-06 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2019 20:19:20 -0000 Reviewer: Phillip Hallam-Baker Review result: Ready We need the capability, the text is readable and there is a formal proof. What more could we ask for? The document provides a mechanism for protecting encrypted data by constructing a symmetric key from the combination of a key agreement value constructed in the normal fashion and a shared secret. This construction provides protection against quantum cryptanalysis. Application of the scheme is outside the scope of the document and is likely to be challenging as the scheme has to rely on the shared secret not being exposed in any form vulnerable to quantum cryptanalysis. From nobody Wed Aug 21 13:03:08 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ED0112098F for ; Wed, 21 Aug 2019 13:03:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] 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 O45x-rLedJbs for ; Wed, 21 Aug 2019 13:02:57 -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 3CDD3120805 for ; Wed, 21 Aug 2019 13:02:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 2C0C0300B01 for ; Wed, 21 Aug 2019 15:43:39 -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 izrLduJj2cle for ; Wed, 21 Aug 2019 15:43:35 -0400 (EDT) Received: from a860b60074bd.fios-router.home (unknown [138.88.156.37]) by mail.smeinc.net (Postfix) with ESMTPSA id 380A0300512; Wed, 21 Aug 2019 15:43:35 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Russ Housley In-Reply-To: <156597611893.31967.2500700648100356711.idtracker@ietfa.amsl.com> Date: Wed, 21 Aug 2019 16:02:51 -0400 Cc: IESG , Tim Hollebeek , LAMPS WG Content-Transfer-Encoding: quoted-printable Message-Id: <61350500-BFA4-4B7C-82DE-6CB52F943C26@vigilsec.com> References: <156597611893.31967.2500700648100356711.idtracker@ietfa.amsl.com> To: Ben Kaduk X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [lamps] Benjamin Kaduk's Discuss on draft-ietf-lamps-cms-mix-with-psk-06: (with DISCUSS and COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2019 20:03:00 -0000 Ben: I responded to the DISCUSS part of this ballot position last week. This = note responds to the very thoughtful non-blocking COMMENT portion of = your ballot position. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Do we need to document the risk of "algorithm mismatch" that is = present > because we use separate algorithm identifiers for KDF, key-encryption, > key-agreement, etc. (vs. a "cipher-suite"-like approach that bundles > together a known-good combination)? In particular, I see we talk = about > the key length for content- and key-encryption algorithms, but are = there > other constraints that should be applied? Some of this is covered in [RFC5652] and [RFC5083]. So, I suggest: The security considerations in related to the CMS enveloped-data content type in [RFC5652] and the security considerations related to the CMS authenticated-enveloped-data content type in [RFC5083] continue to apply. As you indicate, some more of this is already covered by existing text: When using a PSK with a key transport or a key agreement algorithm, a key-encryption key is produced to encrypt the content-encryption key or content-authenticated-encryption key. If the key-encryption algorithm is different than the algorithm used to protect the content, then the effective security is determined by the weaker of the two algorithms. If, for example, content is encrypted with 256-bit AES, and the key is wrapped with 128-bit AES, then at most 128 bits of protection is provided. Implementers must ensure that the key-encryption algorithm is as strong or stronger than the content-encryption algorithm or content-authenticated-encryption algorithm. I suggest we also add some advice about KDF algorithms: The selection of the key-derivation function imposes an upper bound on the strength of the resulting key-encryption key. The strength of the selected key-derivation function should be at least as strong as the key-encryption algorithm that is selected. NIST SP 800-56C Revision 1 [NIST2018] offers advice on the security strength of several popular key-derivation functions. > Section 2 >=20 > The PSK MUST be distributed to the > sender and all of the recipients by some out-of-band means that does > not make it vulnerable to the future invention of a large-scale > quantum computer, and an identifier MUST be assigned to the PSK. >=20 > What are the uniqueness/scope requirements for that identifier? It is best if each PSK has a unique identifier; however, if a recipient = has more than one PSK with the same identifier, the recipient can try = each of them in turn. I will add that to the end of that paragraph. > Section 3 >=20 > ktris contains one KeyTransRecipientInfo type for each recipient; > it uses a key transport algorithm to establish the key-derivation > key. KeyTransRecipientInfo is described in Section 6.2.1 of > [RFC5652]. >=20 > I think we need to be more clear that the 'encryptedKey' member of > KeyTransRecipientInfo contains not the "result of encrypting the > content-encryption key for this recipient" per RFC 5652, but rather = the > "result of encrypting the key-derivation key for this recipient". = That > is, to call out how we are deviating from RFC 5652. Okay. I suggest: ktris contains one KeyTransRecipientInfo type for each recipient; it uses a key transport algorithm to establish the key-derivation key. That is, the encryptedKey field of KeyTransRecipientInfo contains the key-derivation key instead of the content-encryption key. KeyTransRecipientInfo is described in Section 6.2.1 of [RFC5652]. > Section 5 >=20 > Many key derivation functions (KDFs) internally employ a one-way = hash > function. When this is the case, the hash function that is used is > identified by the KeyDerivationAlgorithmIdentifier. HKDF [RFC5869] >=20 > (editorial?) This reads as if the KeyDerivationAlgorithmIdentifier is > going to be (e.g.) 2.16.840.1.101.3.4.2.1 for regular SHA-256, which = is > presumably not the case. It sounds more like "indicated by" or > "indicated as part of the semantics of the" would be more appropriate. This applies to KDFs that are built on encryption algorithms too. I = suggest: Many key derivation functions (KDFs) internally employ a one-way hash function. When this is the case, the hash function that is used is indirectly indicated by the KeyDerivationAlgorithmIdentifier. HKDF [RFC5869] is one example of a KDF that makes use of a hash function. Other KDFs internally employ an encryption algorithm. When this is the case, the encryption that is used is indirectly indicated by the KeyDerivationAlgorithmIdentifier. For example, AES-128-CMAC can be used for randomness extraction in a KDF as described in [NIST2018]. > (side note) Is there a story behind using 5 and 10 for the ENUMERATED > values? >=20 > CMSORIforPSKOtherInfo ::=3D SEQUENCE { > psk OCTET STRING, > keyMgmtAlgType ENUMERATED { > keyTrans (5), > keyAgree (10) }, > keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, > pskLength INTEGER (1..MAX), > kdkLength INTEGER (1..MAX) } 5 =3D b'0101' 10 =3D b'1010' Just so more bits change on the input to the KDF. > If psk is encoded as an OCTET STRING (i.e., including its length), why > do we need a separate pskLength field? Yes, this is redundant. The length is input as part of the OCTET STRING = encoding and as an INTEGER. Joim Schaad pointed this out a long time = ago. It is an artifact of a change that was made between -00 and -01 of = this document. > Section 7 >=20 > material. Compromise of the key-encryption key may result in the > disclosure of all content-encryption keys or content-authenticated- > encryption keys that were protected with that keying material, which > in turn may result in the disclosure of the content. >=20 > a nit, but for the key-agreement variant we have two things that we = call > "key-encryption key"s, so use of the definite article here is > potentially ambiguous. I suggest that the key-encryption key and the KDF be moved to their own = paragraph: Implementations of the key derivation function must compute the entire result, which in this specification is a key-encryption key, before outputting any portion of the result. The resulting key- encryption key must be protected. Compromise of the key-encryption key may result in the disclosure of all content-encryption keys or content-authenticated-encryption keys that were protected with that keying material, which in turn may result in the disclosure of the content. Note that there are two key-encryption keys when a PSK with a key agreement algorithm is used, with similar consequence for the compromise of either one of these keys. > This specification does not require that PSK is known only by the > sender and recipients. The PSK may be known to a group. Since > confidentiality depends on the key transport or key agreement > algorithm, knowledge of the PSK by other parties does not enable > eavesdropping. However, group members can record the traffic of >=20 > Would it be appropriate to add either "inherently" (enable > eavesdropping) or "with currently available technology"? Sure. I'll add "inherently". > Implementers should be aware that cryptographic algorithms become > weaker with time. As new cryptoanalysis techniques are developed = and >=20 > nit: "cryptanalysis" Good catch. I read past that many, many times. > Section 8 >=20 > With respect to "not really making privacy worse", this does seem to > risk exposing that a group of (identified) recipients/participants = share > access to a single PSK (identity), which could potentially correlate > them for other sorts of surveillance/attack. I think that the correlation of key transport public identifiers and key = agreement public keys would have similar consequences. > Section 10.2 >=20 > Don't RFCs 5911, 5912, and 6268 need to be normative since we import > from them in the ASN.1 module? RFC 5911 is not needed. RFC 5912 and RFC 6268 are both in the downref registry, so no further = process is needed to normatively reference them. > Section A.1 >=20 > [I did not attempt to validate the examples.] >=20 > The pre-shared key known to Alice and Bob: > c244cdd11a0d1f39d9b61282770244fb0f6befb91ab7f96cb05213365cf95b15 >=20 > (Should we say it's in hex? Similarly for other non-ASCII-armored > fields, especially the PSK identifier which looks like it is more of a > string than a hex-encoded binary blob) I suggest: The pre-shared key known to Alice and Bob, in hexadecimal: Russ From nobody Wed Aug 21 13:29:22 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69A92120098; Wed, 21 Aug 2019 13:29:20 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=dpG1s4ST; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=qWoCnjKL 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 euYg2rLnQ0r6; Wed, 21 Aug 2019 13:29:18 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90F6F1200EB; Wed, 21 Aug 2019 13:29:18 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id E377B2211E; Wed, 21 Aug 2019 16:29:17 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Wed, 21 Aug 2019 16:29:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm3; bh=p ZLA+g65wFT+gioGx6SzLhR87sXYd3kQPgwsi0FwkAQ=; b=dpG1s4STp2kg3kpsB mI3Eo1BLelz6LbiF74Lsd5KntJiGB4uOLKzrrCwsLenyDg5lP4G3dvh/0Lq47Mdc 0sb8WuhE3OSRVhvnFs2IeTCyANw31Jwebsj/WkSzGSPDtTIiv5auNktBhdrE1srj 8GqhDfrn0SGnHJB6v7C1MF3N5fiGcaBIX5wFHf9bsGA49LXK/gjllKhk2hk+KaEo UQav3PTdkE3a6TF7NBXw0SFHeoZcaseRw1K1IW4ajr/A+rJigSmzneapFfC0uzA1 Af2Y7LM789l3OfQkT28qu9pnNoeNgziG0tB8VQ6o0tjG3dt5tOSgzmgySB7RiRlg DT71A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=pZLA+g65wFT+gioGx6SzLhR87sXYd3kQPgwsi0Fwk AQ=; b=qWoCnjKLmDejli2ef5lhF9KXaaLgJuesjf1rxDrugdFGnKTr7yNnM/u7G LZgUf+eM2P1EfsC6ZuMPiOHuNlxOf9Nbcu2R00TSZpu0M+LhLNkdju8/bGY1TIbp rH9el+XCI8Ty0nF+OdcTragNg/k2CZZHCGyjdwCg+KYnT4ehPjJfiyA8VR52/RQY LvNlPmBpVt9OVNDbxh5y2N0iMa30kDBJRgX65SzyrRDTzdbWOaZLI1HL16WtIMkh CxZAzPJZ48mg++1GbFfMNLmWCIQvdBKIlxMUqhvbd9katGuq1vWem77W/niuZSOK 8L7jxAoaw5JnymiY82sxPG0/ulkmA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrudegfedgudehvdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtdejnecuhfhrohhmpeetlhhi shhsrgcuvehoohhpvghruceorghlihhsshgrsegtohhophgvrhifrdhinheqnecuffhomh grihhnpehivghtfhdrohhrghenucfkphepudejfedrfeekrdduudejrdelvdenucfrrghr rghmpehmrghilhhfrhhomheprghlihhsshgrsegtohhophgvrhifrdhinhenucevlhhush htvghrufhiiigvpedt X-ME-Proxy: Received: from rtp-alcoop-nitro2.cisco.com (unknown [173.38.117.92]) by mail.messagingengine.com (Postfix) with ESMTPA id 55263D6005F; Wed, 21 Aug 2019 16:29:17 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Alissa Cooper In-Reply-To: <156596530298.31942.9549106338899451672@ietfa.amsl.com> Date: Wed, 21 Aug 2019 16:29:16 -0400 Cc: gen-art@ietf.org, spasm@ietf.org, draft-ietf-lamps-cms-mix-with-psk.all@ietf.org, ietf@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <45039B93-1B7F-4DAA-B7C9-D85CC5C028BC@cooperw.in> References: <156596530298.31942.9549106338899451672@ietfa.amsl.com> To: Robert Sparks X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lamps] [Gen-art] Genart telechat review of draft-ietf-lamps-cms-mix-with-psk-06 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2019 20:29:20 -0000 Robert, thanks for your reviews of this document. Russ, thanks for = addressing Robert=E2=80=99s comments. I entered a No Objection ballot. Alissa > On Aug 16, 2019, at 10:21 AM, Robert Sparks via Datatracker = wrote: >=20 > Reviewer: Robert Sparks > Review result: Ready >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please wait for direction from your > document shepherd or AD before posting a new version of the draft. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-lamps-cms-mix-with-psk-06 > Reviewer: Robert Sparks > Review Date: 2019-08-16 > IETF LC End Date: None > IESG Telechat date: 2019-08-22 >=20 > Summary: Ready for publication as a Proposed Standard RFC >=20 >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Wed Aug 21 13:57:42 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5825612007C for ; Wed, 21 Aug 2019 13:57:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] 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 BtPmM7CPhPy4 for ; Wed, 21 Aug 2019 13:57:32 -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 16CB312006A for ; Wed, 21 Aug 2019 13:57:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 2714C300AFB for ; Wed, 21 Aug 2019 16:38:14 -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 ZJ6grzxigFLE for ; Wed, 21 Aug 2019 16:38:13 -0400 (EDT) Received: from a860b60074bd.fios-router.home (unknown [138.88.156.37]) by mail.smeinc.net (Postfix) with ESMTPSA id E0E73300250; Wed, 21 Aug 2019 16:38:12 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: <38527132-0951-49CF-A043-A39B206BB0B7@vigilsec.com> Date: Wed, 21 Aug 2019 16:57:29 -0400 Cc: IESG , LAMPS WG To: Adam Roach X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [lamps] Adam Roach's Comment on draft-ietf-lamps-cms-mix-with-psk-06 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2019 20:57:34 -0000 Adam: I was looking for something else and I stumbled across your COMMENT on = draft-ietf-lamps-cms-mix-with-psk-06. > Thanks for the work on this document. It seems like a useful tool > to add to the crypto toolkit, and it does a good job of explaining > exactly how to apply the described technique. I have one minor > comment. >=20 > =C2=A77: >=20 > I don't generally have a deep understanding of the math behind > encryption, and I didn't take the time to really align the technique > in this document with the bit of crypto that I do understand, so > forgive me if this is a naive observation: I was somewhat surprised > to see no text in here regarding the advisability (or lack thereof) > regarding re-use of PSKs across different sessions. I suggest this additional sentence to Section 2 to address your comment: A PSK is expected to be used with many messages, with a lifetime of weeks or months. Russ= From nobody Wed Aug 21 14:32:04 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E73B12001E; Wed, 21 Aug 2019 14:32:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.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 O3o6X1TwzVdY; Wed, 21 Aug 2019 14:31:58 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 6F8DB120098; Wed, 21 Aug 2019 14:31:58 -0700 (PDT) Received: from MacBook-Pro.roach.at (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x7LLVttx002962 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 21 Aug 2019 16:31:57 -0500 (CDT) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1566423118; bh=zh8pScHkB5i0fpdxbA5KZ7id/Fh7aVZbgvfpcaaDPVc=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=KaVYVkRUVTj72g/YGESwnv7f1Ap1tCMZj+0QT5DDTM0XVXQZsfJmgrIxO/8g3q49g KsDS0Upb9WmrL0e/etiYZ2x6L/Sa91uelL9/YnjZBudO59+D751wttLc21bvb4HAi6 JDe+MUhOH+nf3zlfviwVhGogNwaQyHrAOeomhXXo= X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be MacBook-Pro.roach.at To: Russ Housley Cc: IESG , LAMPS WG References: <38527132-0951-49CF-A043-A39B206BB0B7@vigilsec.com> From: Adam Roach Message-ID: <9fadacdf-0b0b-5a52-a335-9287743ede59@nostrum.com> Date: Wed, 21 Aug 2019 16:31:50 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <38527132-0951-49CF-A043-A39B206BB0B7@vigilsec.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [lamps] Adam Roach's Comment on draft-ietf-lamps-cms-mix-with-psk-06 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2019 21:32:02 -0000 On 8/21/19 3:57 PM, Russ Housley wrote: > Adam: > > I was looking for something else and I stumbled across your COMMENT on draft-ietf-lamps-cms-mix-with-psk-06. > >> Thanks for the work on this document. It seems like a useful tool >> to add to the crypto toolkit, and it does a good job of explaining >> exactly how to apply the described technique. I have one minor >> comment. >> >> §7: >> >> I don't generally have a deep understanding of the math behind >> encryption, and I didn't take the time to really align the technique >> in this document with the bit of crypto that I do understand, so >> forgive me if this is a naive observation: I was somewhat surprised >> to see no text in here regarding the advisability (or lack thereof) >> regarding re-use of PSKs across different sessions. > > I suggest this additional sentence to Section 2 to address your comment: > > A PSK is expected to be used with many messages, with a > lifetime of weeks or months. Yep, that sounds good to me. Thanks! /a From nobody Wed Aug 21 15:43:44 2019 Return-Path: X-Original-To: spasm@ietf.org Delivered-To: spasm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F4C412011C; Wed, 21 Aug 2019 15:43:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: spasm@ietf.org, lamps-chairs@ietf.org, housley@vigilsec.com, rdd@cert.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <156642742241.25748.7049622796613582736.idtracker@ietfa.amsl.com> Date: Wed, 21 Aug 2019 15:43:42 -0700 Archived-At: Subject: [lamps] lamps - New Meeting Session Request for IETF 106 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2019 22:43:42 -0000 A new meeting session request has just been submitted by Russ Housley, a Chair of the lamps working group. --------------------------------------------------------- Working Group Name: Limited Additional Mechanisms for PKIX and SMIME Area Name: Security Area Session Requester: Russ Housley Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 45 Conflicts to Avoid: Chair Conflict: ipwave lamps suit Technology Overlap: acme cfrg ace Key Participant Conflict: oauth secdispatch saag sipbrandy tls mls teep People who must be present: Russ Housley Rich Salz Sean Turner Alexey Melnikov Roman Danyliw Richard Barnes Bernie Hoeneisen Jim Schaad Tim Hollebeek Hendrik Brockhaus Resources Requested: Special Requests: --------------------------------------------------------- From nobody Thu Aug 22 19:00:22 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B80E120227; Thu, 22 Aug 2019 19:00:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=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 6FTTsMa-Q01a; Thu, 22 Aug 2019 19:00:13 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 3490B12011B; Thu, 22 Aug 2019 19:00:12 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x7N208fw019145 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 22 Aug 2019 22:00:11 -0400 Date: Thu, 22 Aug 2019 21:00:08 -0500 From: Benjamin Kaduk To: Russ Housley Cc: IESG , LAMPS WG Message-ID: <20190823020007.GZ60855@kduck.mit.edu> References: <156597611893.31967.2500700648100356711.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [lamps] Benjamin Kaduk's Discuss on draft-ietf-lamps-cms-mix-with-psk-06: (with DISCUSS and COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2019 02:00:16 -0000 Hi Russ, On Fri, Aug 16, 2019 at 02:09:03PM -0400, Russ Housley wrote: > Ben: > > Thanks for doing all of the reading necessary to raise this question. > > I want to respond to the DISCUSS in this note. I'll tackle the non-blocking comments is a separate message. Sorry that I did not more effectively make use of the extra lead time you gave me. > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > I think we need to have a discussion about the abstract API for a > > KEY-DERIVATION instance and how that relates to what we need for a key > > combination operation. In Section 5 we assume that we can use the > > HKDF terminology, but that doesn't seem to hold universally for > > KEY-DERIVATION; for example, while HKDF has IKM, salt, and info, PBKDF2 > > (from RFC 3211 that AFAICT introduces keyDerivationalgorithm for CMS) is > > specified by RFC 2898 as taking just the input secret (password) and a > > salt, with no separate 'info' (and of course the different iteration > > count and PRF parameters needed for its construction). I note (with > > chagrin, as sponsoring AD) that RFC 8619 says "PARAMS ARE absent" for > > the HKDF-based KEY-DERIVATION instances but is silent about how one is > > supposed to know what to pass for salt/info (the IKM we can perhaps > > assume will be obvious). > > > > In short, should we be seeking to define a distinct key combination > > operation like KRB-FX-CF2 (RFC6113) rather than trying to repurpose key > > derivation? Some KDFs support this fairly well, but it's not clear to > > me that it is a universal property. For example, the proof in [H2019] > > seems to be assuming HKDF but this draft does not (as is clearly seen > > from the use of the X9.63 KDF in one of the examples). > > NIST SP 800-56 Revision 1 offers this high-level interface to the KDF: > > KDF(Z, OtherInput) > > - Z: a byte string that represents the shared secret. This ic called IKM in the HKDF terminology. > > - OtherInput includes: > > -- salt - a non-null (secret or non-secret) byte string. > > -- L - a positive integer that indicates the length (in bits) of the secret keying material to be derived. > > -- FixedInfo - a bit string of context-specific data that is appropriate for the relying key-establishment scheme. > > I do not think that this very high level of API really solves your concern, but it did guide my thinking in writing the document. It is helpful to see this and understand the origin of what's in the document. (Also that the salt is listed as "secret or non-secret" here, as in at least one other place I looked at during my background reading I saw it listed as "not-secret", which would be problematic when we want to put a secret key in it!) > The KDF algorithm identifier has this structure: > > AlgorithmIdentifier ::= SEQUENCE { > algorithm OBJECT IDENTIFIER, > parameters ANY DEFINED BY algorithm OPTIONAL } > > The algorithm part lets us name many different KDFs. As you point out, the examples in Appendix A and Appendix B use HKDF and X9.63 KDF. > > Recent discussions in the LAMPS WG show a big bias against complex parameter strictures. Instead, people have voiced a strong preference for an object identifier that names all of the options. This leads to more object identifier assignments, but clear understanding of all options when one is chosen or negotiated. The one exception is an initialization vector, where a fresh value is expected each time the algorithm is invoked. Agreed. > So, in this document, I have defined a structure of the OtherInput portion of the NIST API. If a particular KDF needs to use a value from that structure in a particular way, is can do so. The document uses HKDF terminology. > > If a KDF requires a salt, then it should be provided as a parameter. I can certainly add that to the document. I believe that KMAC128 and KMAC256 are algorithms that require a salt. Okay, but I'm not sure we've really gotten onto the same page. I think my main question is whether we're comfortable using a KDF abstraction like the above (KDF(secret, otherInput)) in a fully general sense, and asking for this mix-with-psk to work properly for all possible KDFs. For example, would you be comfortable using the construction in this document with PBKDF1 as the KDF? I don't even see where we could slot in the PSK from this document into PBKDF1 -- the API just doesn't seem to be flexible enough. PBKDF2 allows a more-than-8-octet salt, but is that going to provide the kind of mixing that we need? I just don't know if all KDFs are going to guarantee the contributory behavior from the otherInput that we need in order for this scheme to work. -Ben From nobody Thu Aug 22 20:07:35 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9430C120091; Thu, 22 Aug 2019 20:07:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 M9N32wCQhptq; Thu, 22 Aug 2019 20:07:24 -0700 (PDT) Received: from mail-ot1-f48.google.com (mail-ot1-f48.google.com [209.85.210.48]) (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 3D409120019; Thu, 22 Aug 2019 20:07:24 -0700 (PDT) Received: by mail-ot1-f48.google.com with SMTP id o101so7459188ota.8; Thu, 22 Aug 2019 20:07:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JUVCpDlom9keIL3wBhp7e1MFoNkV3bIWYkaIgxCQ0tI=; b=DuGA1aqTGUrUkKv3ahPz3/3mEUd/dQIRachVsESGV5lout/BC/arOt2e+59pWQol8f mAemsuolBx2/8OwCoMvqXHqvK6lyvtpZ67POCwME5q6Rut0LvCL1D0/fHgXh8rPUg1SZ WXWXtyH22MboIhgNwP19Wuf5YSJYgQbH3DZF8PS5cfIycjsqUekKkvj1GkyG92+qMhra MKCU+OuExY2WZZw4ecfqTLZ0W/UPsxyG8FCFpVCR0Sn4Rmy+8JvRTQepmtKLjoAeGXLF qNP4KyXcV8IU9BS8hNTS+rmZ22QFOCcD/wqNO1TN6CQ2pgGOWv+8X12WeCp/huH9XQ0G tz3g== X-Gm-Message-State: APjAAAUU5HFIDDa8hqjQe0JqMyq1K/J4LqEBMKwpsu3NsVswZEK4l1cl VKWiwWxaXqcH2P43slnSIRYeFzpZqV537XM0K8o= X-Google-Smtp-Source: APXvYqyIgJJFwK7PtQ86oegF+wXG26VxBUplM+8+6pQpAA2jXkQ2ghU894nMqs2LubrSipIaiyCVnz+N7sttsdaW45Q= X-Received: by 2002:a9d:4a3:: with SMTP id 32mr2352993otm.37.1566529643476; Thu, 22 Aug 2019 20:07:23 -0700 (PDT) MIME-Version: 1.0 References: <156597611893.31967.2500700648100356711.idtracker@ietfa.amsl.com> <20190823020007.GZ60855@kduck.mit.edu> In-Reply-To: <20190823020007.GZ60855@kduck.mit.edu> From: Phillip Hallam-Baker Date: Thu, 22 Aug 2019 23:07:12 -0400 Message-ID: To: Benjamin Kaduk Cc: Russ Housley , LAMPS WG , IESG Content-Type: multipart/alternative; boundary="000000000000edfa2c0590c01a62" Archived-At: Subject: Re: [lamps] Benjamin Kaduk's Discuss on draft-ietf-lamps-cms-mix-with-psk-06: (with DISCUSS and COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2019 03:07:27 -0000 --000000000000edfa2c0590c01a62 Content-Type: text/plain; charset="UTF-8" On Thu, Aug 22, 2019 at 10:00 PM Benjamin Kaduk wrote: > Hi Russ, > > On Fri, Aug 16, 2019 at 02:09:03PM -0400, Russ Housley wrote: > > Ben: > > > > Thanks for doing all of the reading necessary to raise this question. > > > > I want to respond to the DISCUSS in this note. I'll tackle the > non-blocking comments is a separate message. > > Sorry that I did not more effectively make use of the extra lead time you > gave me. > > > > ---------------------------------------------------------------------- > > > DISCUSS: > > > ---------------------------------------------------------------------- > > > > > > I think we need to have a discussion about the abstract API for a > > > KEY-DERIVATION instance and how that relates to what we need for a key > > > combination operation. In Section 5 we assume that we can use the > > > HKDF terminology, but that doesn't seem to hold universally for > > > KEY-DERIVATION; for example, while HKDF has IKM, salt, and info, PBKDF2 > > > (from RFC 3211 that AFAICT introduces keyDerivationalgorithm for CMS) > is > > > specified by RFC 2898 as taking just the input secret (password) and a > > > salt, with no separate 'info' (and of course the different iteration > > > count and PRF parameters needed for its construction). I note (with > > > chagrin, as sponsoring AD) that RFC 8619 says "PARAMS ARE absent" for > > > the HKDF-based KEY-DERIVATION instances but is silent about how one is > > > supposed to know what to pass for salt/info (the IKM we can perhaps > > > assume will be obvious). > > > > > > In short, should we be seeking to define a distinct key combination > > > operation like KRB-FX-CF2 (RFC6113) rather than trying to repurpose key > > > derivation? Some KDFs support this fairly well, but it's not clear to > > > me that it is a universal property. For example, the proof in [H2019] > > > seems to be assuming HKDF but this draft does not (as is clearly seen > > > from the use of the X9.63 KDF in one of the examples). > > > > NIST SP 800-56 Revision 1 offers this high-level interface to the KDF: > > > > KDF(Z, OtherInput) > > > > - Z: a byte string that represents the shared secret. This ic called > IKM in the HKDF terminology. > > > > - OtherInput includes: > > > > -- salt - a non-null (secret or non-secret) byte string. > > > > -- L - a positive integer that indicates the length (in > bits) of the secret keying material to be derived. > > > > -- FixedInfo - a bit string of context-specific data that is > appropriate for the relying key-establishment scheme. > > > > I do not think that this very high level of API really solves your > concern, but it did guide my thinking in writing the document. > > It is helpful to see this and understand the origin of what's in the > document. (Also that the salt is listed as "secret or non-secret" here, as > in at least one other place I looked at during my background reading I saw > it listed as "not-secret", which would be problematic when we want to put a > secret key in it!) > > > The KDF algorithm identifier has this structure: > > > > AlgorithmIdentifier ::= SEQUENCE { > > algorithm OBJECT IDENTIFIER, > > parameters ANY DEFINED BY algorithm OPTIONAL } > > > > The algorithm part lets us name many different KDFs. As you point out, > the examples in Appendix A and Appendix B use HKDF and X9.63 KDF. > > > > Recent discussions in the LAMPS WG show a big bias against complex > parameter strictures. Instead, people have voiced a strong preference for > an object identifier that names all of the options. This leads to more > object identifier assignments, but clear understanding of all options when > one is chosen or negotiated. The one exception is an initialization > vector, where a fresh value is expected each time the algorithm is invoked. > > Agreed. > > > So, in this document, I have defined a structure of the OtherInput > portion of the NIST API. If a particular KDF needs to use a value from > that structure in a particular way, is can do so. The document uses HKDF > terminology. > > > > If a KDF requires a salt, then it should be provided as a parameter. I > can certainly add that to the document. I believe that KMAC128 and KMAC256 > are algorithms that require a salt. > > Okay, but I'm not sure we've really gotten onto the same page. > > I think my main question is whether we're comfortable using a KDF > abstraction like the above (KDF(secret, otherInput)) in a fully general > sense, and asking for this mix-with-psk to work properly for all possible > KDFs. For example, would you be comfortable using the construction in this > document with PBKDF1 as the KDF? I don't even see where we could slot in > the PSK from this document into PBKDF1 -- the API just doesn't seem to be > flexible enough. PBKDF2 allows a more-than-8-octet salt, but is that going > to provide the kind of mixing that we need? > > I just don't know if all KDFs are going to guarantee the contributory > behavior from the otherInput that we need in order for this scheme to work. > The ability to change algorithm is a good thing. But proliferation of mechanisms is not. I really dislike the fact that we have three dozen SASL mechanisms that do the same thing. The ability to use a KDF keyed by a different hash function seems like it is useful agility. I really cannot imagine a situation in which we discovered an urgent need to move away from HKDF that didn't require us to think really hard about the replacement algorithm as well. --000000000000edfa2c0590c01a62 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Aug 22, 2019 at 10:00 PM Benjamin Kaduk <= ;kaduk@mit.edu> wrote:
Hi Russ,

On Fri, Aug 16, 2019 at 02:09:03PM -0400, Russ Housley wrote:
> Ben:
>
> Thanks for doing all of the reading necessary to raise this question.<= br> >
> I want to respond to the DISCUSS in this note.=C2=A0 I'll tackle t= he non-blocking comments is a separate message.

Sorry that I did not more effectively make use of the extra lead time you gave me.

> > -----------------------------------------------------------------= -----
> > DISCUSS:
> > -----------------------------------------------------------------= -----
> >
> > I think we need to have a discussion about the abstract API for a=
> > KEY-DERIVATION instance and how that relates to what we need for = a key
> > combination operation.=C2=A0 In Section 5 we assume that we can u= se the
> > HKDF terminology, but that doesn't seem to hold universally f= or
> > KEY-DERIVATION; for example, while HKDF has IKM, salt, and info, = PBKDF2
> > (from RFC 3211 that AFAICT introduces keyDerivationalgorithm for = CMS) is
> > specified by RFC 2898 as taking just the input secret (password) = and a
> > salt, with no separate 'info' (and of course the differen= t iteration
> > count and PRF parameters needed for its construction).=C2=A0 I no= te (with
> > chagrin, as sponsoring AD) that RFC 8619 says "PARAMS ARE ab= sent" for
> > the HKDF-based KEY-DERIVATION instances but is silent about how o= ne is
> > supposed to know what to pass for salt/info (the IKM we can perha= ps
> > assume will be obvious).
> >
> > In short, should we be seeking to define a distinct key combinati= on
> > operation like KRB-FX-CF2 (RFC6113) rather than trying to repurpo= se key
> > derivation?=C2=A0 Some KDFs support this fairly well, but it'= s not clear to
> > me that it is a universal property.=C2=A0 For example, the proof = in [H2019]
> > seems to be assuming HKDF but this draft does not (as is clearly = seen
> > from the use of the X9.63 KDF in one of the examples).
>
> NIST SP 800-56 Revision 1 offers this high-level interface to the KDF:=
>
>=C2=A0 =C2=A0 KDF(Z, OtherInput)
>
>=C2=A0 =C2=A0- Z: a byte string that represents the shared secret.=C2= =A0 This ic called IKM in the HKDF terminology.
>
>=C2=A0 =C2=A0- OtherInput includes:
>
>=C2=A0 =C2=A0 -- salt - a non-null (secret=C2=A0 or non-secret) byte st= ring.
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 -- L - a=C2=A0 positive=C2=A0 integer=C2=A0 that=C2=A0 in= dicates=C2=A0 the=C2=A0 length=C2=A0 (in=C2=A0 bits)=C2=A0 of=C2=A0 the=C2= =A0 secret=C2=A0 keying=C2=A0 material to be derived.
>
>=C2=A0 =C2=A0 -- FixedInfo - a bit string of context-specific data that= is appropriate for the relying key-establishment scheme.
>
> I do not think that this very high level of API really solves your con= cern, but it did guide my thinking in writing the document.

It is helpful to see this and understand the origin of what's in the document.=C2=A0 (Also that the salt is listed as "secret or non-secret= " here, as
in at least one other place I looked at during my background reading I saw<= br> it listed as "not-secret", which would be problematic when we wan= t to put a
secret key in it!)

> The KDF algorithm identifier has this structure:
>
>=C2=A0 =C2=A0 AlgorithmIdentifier=C2=A0 ::=3D=C2=A0 SEQUENCE=C2=A0 { >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0algorithm=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0OBJECT IDENTIFIER,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0parameters=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 ANY DEFINED BY algorithm OPTIONAL=C2=A0 }
>
> The algorithm part lets us name many different KDFs.=C2=A0 As you poin= t out, the examples in Appendix A and Appendix B use HKDF and X9.63 KDF. >
> Recent discussions in the LAMPS WG show a big bias against complex par= ameter strictures.=C2=A0 Instead, people have voiced a strong preference fo= r an object identifier that names all of the options.=C2=A0 This leads to m= ore object identifier assignments, but clear understanding of all options w= hen one is chosen or negotiated.=C2=A0 The one exception is an initializati= on vector, where a fresh value is expected each time the algorithm is invok= ed.

Agreed.

> So, in this document, I have defined a structure of the OtherInput por= tion of the NIST API.=C2=A0 If a particular KDF needs to use a value from t= hat structure in a particular way, is can do so.=C2=A0 The document uses HK= DF terminology.
>
> If a KDF requires a salt, then it should be provided as a parameter.= =C2=A0 I can certainly add that to the document.=C2=A0 I believe that KMAC1= 28 and KMAC256 are algorithms that require a salt.

Okay, but I'm not sure we've really gotten onto the same page.

I think my main question is whether we're comfortable using a KDF
abstraction like the above (KDF(secret, otherInput)) in a fully general
sense, and asking for this mix-with-psk to work properly for all possible KDFs.=C2=A0 For example, would you be comfortable using the construction in= this
document with PBKDF1 as the KDF?=C2=A0 I don't even see where we could slot in
the PSK from this document into PBKDF1 -- the API just doesn't seem to = be
flexible enough.=C2=A0 PBKDF2 allows a more-than-8-octet salt, but is that = going
to provide the kind of mixing that we need?

I just don't know if all KDFs are going to guarantee the contributory behavior from the otherInput that we need in order for this scheme to work.=

The ability to change algorithm is a good thing. But proliferat= ion of mechanisms is not. I really dislike the fact that we have three doze= n SASL mechanisms that do the same thing.

The ability to use a KDF keyed by a different hash functio= n seems like it is useful agility.=C2=A0

I really cannot imagine a situation in which we discovered = an urgent need to move away from HKDF that didn't require us to think r= eally hard about the replacement algorithm as well.

--000000000000edfa2c0590c01a62-- From nobody Fri Aug 23 09:57:20 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BD651200F5; Fri, 23 Aug 2019 09:57:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=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 HAzTxL0S5HK5; Fri, 23 Aug 2019 09:57:16 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 E293D120020; Fri, 23 Aug 2019 09:57:15 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x7NGv9Y5012909 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 23 Aug 2019 12:57:11 -0400 Date: Fri, 23 Aug 2019 11:57:08 -0500 From: Benjamin Kaduk To: Russ Housley Cc: IESG , Tim Hollebeek , LAMPS WG Message-ID: <20190823165708.GA60855@kduck.mit.edu> References: <156597611893.31967.2500700648100356711.idtracker@ietfa.amsl.com> <61350500-BFA4-4B7C-82DE-6CB52F943C26@vigilsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <61350500-BFA4-4B7C-82DE-6CB52F943C26@vigilsec.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [lamps] Benjamin Kaduk's Discuss on draft-ietf-lamps-cms-mix-with-psk-06: (with DISCUSS and COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2019 16:57:19 -0000 On Wed, Aug 21, 2019 at 04:02:51PM -0400, Russ Housley wrote: > Ben: > > I responded to the DISCUSS part of this ballot position last week. This note responds to the very thoughtful non-blocking COMMENT portion of your ballot position. > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Do we need to document the risk of "algorithm mismatch" that is present > > because we use separate algorithm identifiers for KDF, key-encryption, > > key-agreement, etc. (vs. a "cipher-suite"-like approach that bundles > > together a known-good combination)? In particular, I see we talk about > > the key length for content- and key-encryption algorithms, but are there > > other constraints that should be applied? > > Some of this is covered in [RFC5652] and [RFC5083]. So, I suggest: > > The security considerations in related to the CMS enveloped-data > content type in [RFC5652] and the security considerations related to > the CMS authenticated-enveloped-data content type in [RFC5083] > continue to apply. > > As you indicate, some more of this is already covered by existing text: > > When using a PSK with a key transport or a key agreement algorithm, a > key-encryption key is produced to encrypt the content-encryption key > or content-authenticated-encryption key. If the key-encryption > algorithm is different than the algorithm used to protect the > content, then the effective security is determined by the weaker of > the two algorithms. If, for example, content is encrypted with > 256-bit AES, and the key is wrapped with 128-bit AES, then at most > 128 bits of protection is provided. Implementers must ensure that > the key-encryption algorithm is as strong or stronger than the > content-encryption algorithm or content-authenticated-encryption > algorithm. > > I suggest we also add some advice about KDF algorithms: > > The selection of the key-derivation function imposes an upper bound > on the strength of the resulting key-encryption key. The strength of > the selected key-derivation function should be at least as strong as > the key-encryption algorithm that is selected. NIST SP 800-56C > Revision 1 [NIST2018] offers advice on the security strength of > several popular key-derivation functions. That all sounds good; thanks. > > Section 2 > > > > The PSK MUST be distributed to the > > sender and all of the recipients by some out-of-band means that does > > not make it vulnerable to the future invention of a large-scale > > quantum computer, and an identifier MUST be assigned to the PSK. > > > > What are the uniqueness/scope requirements for that identifier? > > It is best if each PSK has a unique identifier; however, if a recipient has more than one PSK with the same identifier, the recipient can try each of them in turn. I will add that to the end of that paragraph. > > > Section 3 > > > > ktris contains one KeyTransRecipientInfo type for each recipient; > > it uses a key transport algorithm to establish the key-derivation > > key. KeyTransRecipientInfo is described in Section 6.2.1 of > > [RFC5652]. > > > > I think we need to be more clear that the 'encryptedKey' member of > > KeyTransRecipientInfo contains not the "result of encrypting the > > content-encryption key for this recipient" per RFC 5652, but rather the > > "result of encrypting the key-derivation key for this recipient". That > > is, to call out how we are deviating from RFC 5652. > > Okay. I suggest: > > ktris contains one KeyTransRecipientInfo type for each recipient; > it uses a key transport algorithm to establish the key-derivation > key. That is, the encryptedKey field of KeyTransRecipientInfo > contains the key-derivation key instead of the content-encryption > key. KeyTransRecipientInfo is described in Section 6.2.1 of > [RFC5652]. Works for me. > > Section 5 > > > > Many key derivation functions (KDFs) internally employ a one-way hash > > function. When this is the case, the hash function that is used is > > identified by the KeyDerivationAlgorithmIdentifier. HKDF [RFC5869] > > > > (editorial?) This reads as if the KeyDerivationAlgorithmIdentifier is > > going to be (e.g.) 2.16.840.1.101.3.4.2.1 for regular SHA-256, which is > > presumably not the case. It sounds more like "indicated by" or > > "indicated as part of the semantics of the" would be more appropriate. > > This applies to KDFs that are built on encryption algorithms too. I suggest: > > Many key derivation functions (KDFs) internally employ a one-way hash > function. When this is the case, the hash function that is used is > indirectly indicated by the KeyDerivationAlgorithmIdentifier. HKDF > [RFC5869] is one example of a KDF that makes use of a hash function. > > Other KDFs internally employ an encryption algorithm. When this is > the case, the encryption that is used is indirectly indicated by the > KeyDerivationAlgorithmIdentifier. For example, AES-128-CMAC can be > used for randomness extraction in a KDF as described in [NIST2018]. Sure. > > (side note) Is there a story behind using 5 and 10 for the ENUMERATED > > values? > > > > CMSORIforPSKOtherInfo ::= SEQUENCE { > > psk OCTET STRING, > > keyMgmtAlgType ENUMERATED { > > keyTrans (5), > > keyAgree (10) }, > > keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, > > pskLength INTEGER (1..MAX), > > kdkLength INTEGER (1..MAX) } > > 5 = b'0101' > 10 = b'1010' > > Just so more bits change on the input to the KDF. :) > > If psk is encoded as an OCTET STRING (i.e., including its length), why > > do we need a separate pskLength field? > > Yes, this is redundant. The length is input as part of the OCTET STRING encoding and as an INTEGER. Joim Schaad pointed this out a long time ago. It is an artifact of a change that was made between -00 and -01 of this document. Okay. > > Section 7 > > > > material. Compromise of the key-encryption key may result in the > > disclosure of all content-encryption keys or content-authenticated- > > encryption keys that were protected with that keying material, which > > in turn may result in the disclosure of the content. > > > > a nit, but for the key-agreement variant we have two things that we call > > "key-encryption key"s, so use of the definite article here is > > potentially ambiguous. > > I suggest that the key-encryption key and the KDF be moved to their own paragraph: > > Implementations of the key derivation function must compute the > entire result, which in this specification is a key-encryption key, > before outputting any portion of the result. The resulting key- > encryption key must be protected. Compromise of the key-encryption > key may result in the disclosure of all content-encryption keys or > content-authenticated-encryption keys that were protected with that > keying material, which in turn may result in the disclosure of the > content. Note that there are two key-encryption keys when a PSK with > a key agreement algorithm is used, with similar consequence for the > compromise of either one of these keys. Thanks. > > This specification does not require that PSK is known only by the > > sender and recipients. The PSK may be known to a group. Since > > confidentiality depends on the key transport or key agreement > > algorithm, knowledge of the PSK by other parties does not enable > > eavesdropping. However, group members can record the traffic of > > > > Would it be appropriate to add either "inherently" (enable > > eavesdropping) or "with currently available technology"? > > Sure. I'll add "inherently". > > > Implementers should be aware that cryptographic algorithms become > > weaker with time. As new cryptoanalysis techniques are developed and > > > > nit: "cryptanalysis" > > Good catch. I read past that many, many times. > > > Section 8 > > > > With respect to "not really making privacy worse", this does seem to > > risk exposing that a group of (identified) recipients/participants share > > access to a single PSK (identity), which could potentially correlate > > them for other sorts of surveillance/attack. > > I think that the correlation of key transport public identifiers and key agreement public keys would have similar consequences. Thanks for thinking about it; that's reasonable. > > Section 10.2 > > > > Don't RFCs 5911, 5912, and 6268 need to be normative since we import > > from them in the ASN.1 module? > > RFC 5911 is not needed. > > RFC 5912 and RFC 6268 are both in the downref registry, so no further process is needed to normatively reference them. > > > Section A.1 > > > > [I did not attempt to validate the examples.] > > > > The pre-shared key known to Alice and Bob: > > c244cdd11a0d1f39d9b61282770244fb0f6befb91ab7f96cb05213365cf95b15 > > > > (Should we say it's in hex? Similarly for other non-ASCII-armored > > fields, especially the PSK identifier which looks like it is more of a > > string than a hex-encoded binary blob) > > I suggest: > > The pre-shared key known to Alice and Bob, in hexadecimal: Thanks! -Ben From nobody Fri Aug 23 09:59:00 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9C8012000F; Fri, 23 Aug 2019 09:58:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=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 PSc4fc2mOjMx; Fri, 23 Aug 2019 09:58:51 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 CF106120020; Fri, 23 Aug 2019 09:58:50 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x7NGwhPV013658 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 23 Aug 2019 12:58:45 -0400 Date: Fri, 23 Aug 2019 11:58:42 -0500 From: Benjamin Kaduk To: Phillip Hallam-Baker Cc: Russ Housley , LAMPS WG , IESG Message-ID: <20190823165842.GB60855@kduck.mit.edu> References: <156597611893.31967.2500700648100356711.idtracker@ietfa.amsl.com> <20190823020007.GZ60855@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [lamps] Benjamin Kaduk's Discuss on draft-ietf-lamps-cms-mix-with-psk-06: (with DISCUSS and COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2019 16:58:53 -0000 Hi Phill, On Thu, Aug 22, 2019 at 11:07:12PM -0400, Phillip Hallam-Baker wrote: > On Thu, Aug 22, 2019 at 10:00 PM Benjamin Kaduk wrote: > > > Hi Russ, > > > > I think my main question is whether we're comfortable using a KDF > > abstraction like the above (KDF(secret, otherInput)) in a fully general > > sense, and asking for this mix-with-psk to work properly for all possible > > KDFs. For example, would you be comfortable using the construction in this > > document with PBKDF1 as the KDF? I don't even see where we could slot in > > the PSK from this document into PBKDF1 -- the API just doesn't seem to be > > flexible enough. PBKDF2 allows a more-than-8-octet salt, but is that going > > to provide the kind of mixing that we need? > > > > I just don't know if all KDFs are going to guarantee the contributory > > behavior from the otherInput that we need in order for this scheme to work. > > > > The ability to change algorithm is a good thing. But proliferation of > mechanisms is not. I really dislike the fact that we have three dozen SASL > mechanisms that do the same thing. > > The ability to use a KDF keyed by a different hash function seems like it > is useful agility. > > I really cannot imagine a situation in which we discovered an urgent need > to move away from HKDF that didn't require us to think really hard about > the replacement algorithm as well. While I agree with you, I'm not entirely sure what you see as the consequences for this document. Are you proposing that we just restrict its usage to HKDF-based KDFs for now? Thanks, Ben From nobody Fri Aug 23 11:10:34 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C54B120044; Fri, 23 Aug 2019 11:10:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 YBANUMwBJHeW; Fri, 23 Aug 2019 11:10:24 -0700 (PDT) Received: from mail-oi1-f193.google.com (mail-oi1-f193.google.com [209.85.167.193]) (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 7CA9012006A; Fri, 23 Aug 2019 11:10:24 -0700 (PDT) Received: by mail-oi1-f193.google.com with SMTP id n1so7686473oic.3; Fri, 23 Aug 2019 11:10:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=EcYZPdQOwY+Dcx8QW/TTeeOwE4fhgTMcF/r2zeBHSbw=; b=GU0m9fK2MS6C3StW9Dt2tifdSM6lUUkX6aMEmUn74/PfU40vMoFcmZzOFdqSArRiRh qDq1eWCnC4isPFSGo4giKd+OXq5YNH5e6fGLXnZT4j4sQnUDFXpdF/jotbmN7tEucwe7 dIuYCQ1qYq6WwmigtzflZWBazkD7/13Tcoo43MpTsYPi0YombzjV910EMSrSmR/+I0Jl NyIi8njfYUFFEEmIs6NOcnqTo6WJVNDxIK53KiC4xXWUTKxebwIJbu/Q6xKklCbsiVsF FAIspKcZEtmZZjJXAVJNWzjkCCluABjvum/zKIsvwi3+Hip5E0R3FXm9boyPxqr4oHUG OvxQ== X-Gm-Message-State: APjAAAX6emrivW3vHK2zly9HMDQD+axThHCadxKQ+M/ScpYRHOOkCT3T fZ15aI7kbpu3xpaZlcfIK+6e34GRCa18TuMMOww= X-Google-Smtp-Source: APXvYqx+IaAZh+5FkkDOOanpZRfavItnpETIrHda1TnHKpklmiHSi9Mg4ur5mAPDPSSezoacD++pwtL6Dcc3/O1Oklw= X-Received: by 2002:aca:bfd4:: with SMTP id p203mr4146196oif.95.1566583823736; Fri, 23 Aug 2019 11:10:23 -0700 (PDT) MIME-Version: 1.0 References: <156597611893.31967.2500700648100356711.idtracker@ietfa.amsl.com> <20190823020007.GZ60855@kduck.mit.edu> <20190823165842.GB60855@kduck.mit.edu> In-Reply-To: <20190823165842.GB60855@kduck.mit.edu> From: Phillip Hallam-Baker Date: Fri, 23 Aug 2019 14:10:11 -0400 Message-ID: To: Benjamin Kaduk Cc: Russ Housley , LAMPS WG , IESG Content-Type: multipart/alternative; boundary="000000000000532a0e0590ccb883" Archived-At: Subject: Re: [lamps] Benjamin Kaduk's Discuss on draft-ietf-lamps-cms-mix-with-psk-06: (with DISCUSS and COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2019 18:10:26 -0000 --000000000000532a0e0590ccb883 Content-Type: text/plain; charset="UTF-8" On Fri, Aug 23, 2019 at 12:58 PM Benjamin Kaduk wrote: > Hi Phill, > > On Thu, Aug 22, 2019 at 11:07:12PM -0400, Phillip Hallam-Baker wrote: > > On Thu, Aug 22, 2019 at 10:00 PM Benjamin Kaduk wrote: > > > > > Hi Russ, > > > > > > I think my main question is whether we're comfortable using a KDF > > > abstraction like the above (KDF(secret, otherInput)) in a fully general > > > sense, and asking for this mix-with-psk to work properly for all > possible > > > KDFs. For example, would you be comfortable using the construction in > this > > > document with PBKDF1 as the KDF? I don't even see where we could slot > in > > > the PSK from this document into PBKDF1 -- the API just doesn't seem to > be > > > flexible enough. PBKDF2 allows a more-than-8-octet salt, but is that > going > > > to provide the kind of mixing that we need? > > > > > > I just don't know if all KDFs are going to guarantee the contributory > > > behavior from the otherInput that we need in order for this scheme to > work. > > > > > > > The ability to change algorithm is a good thing. But proliferation of > > mechanisms is not. I really dislike the fact that we have three dozen > SASL > > mechanisms that do the same thing. > > > > The ability to use a KDF keyed by a different hash function seems like it > > is useful agility. > > > > I really cannot imagine a situation in which we discovered an urgent need > > to move away from HKDF that didn't require us to think really hard about > > the replacement algorithm as well. > > While I agree with you, I'm not entirely sure what you see as the > consequences for this document. Are you proposing that we just restrict > its usage to HKDF-based KDFs for now? > Given your comments, I think that works better than trying to abstract out an API and then map other KDFs onto it. Since we build KDFs on a hash function, the API pretty much defines the KDF structure. There are design choices in a KDF but I really hope they are not security concerns because that would suggest HMAC is broken or we don't know how to use a MAC. I see the choice of KDF as being a part of the CMS specification that just happens to be available for re-use in other specifications. While there may be good reason to add to the number of KDFs supported, I don't think we need to anticipate or plan for that. --000000000000532a0e0590ccb883 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Aug 23, 2019 at 12:58 PM Benjamin Kaduk <= ;kaduk@mit.edu> wrote:
Hi Phill,

On Thu, Aug 22, 2019 at 11:07:12PM -0400, Phillip Hallam-Baker wrote:
> On Thu, Aug 22, 2019 at 10:00 PM Benjamin Kaduk <kaduk@mit.edu> wrote:
>
> > Hi Russ,
> >
> > I think my main question is whether we're comfortable using a= KDF
> > abstraction like the above (KDF(secret, otherInput)) in a fully g= eneral
> > sense, and asking for this mix-with-psk to work properly for all = possible
> > KDFs.=C2=A0 For example, would you be comfortable using the const= ruction in this
> > document with PBKDF1 as the KDF?=C2=A0 I don't even see where= we could slot in
> > the PSK from this document into PBKDF1 -- the API just doesn'= t seem to be
> > flexible enough.=C2=A0 PBKDF2 allows a more-than-8-octet salt, bu= t is that going
> > to provide the kind of mixing that we need?
> >
> > I just don't know if all KDFs are going to guarantee the cont= ributory
> > behavior from the otherInput that we need in order for this schem= e to work.
> >
>
> The ability to change algorithm is a good thing. But proliferation of<= br> > mechanisms is not. I really dislike the fact that we have three dozen = SASL
> mechanisms that do the same thing.
>
> The ability to use a KDF keyed by a different hash function seems like= it
> is useful agility.
>
> I really cannot imagine a situation in which we discovered an urgent n= eed
> to move away from HKDF that didn't require us to think really hard= about
> the replacement algorithm as well.

While I agree with you, I'm not entirely sure what you see as the
consequences for this document.=C2=A0 Are you proposing that we just restri= ct
its usage to HKDF-based KDFs for now?

Given your comments, I thi= nk that works better than trying to abstract out an API and then map other = KDFs onto it.
<= br>
Since we bu= ild KDFs on a hash function, the API pretty much defines the KDF structure.= There are design choices in a KDF but I really hope they are not security = concerns because that would suggest HMAC is broken or we don't know how= to use a MAC.
=
I see the = choice of KDF as being a part of the CMS specification that just happens to= be available for re-use in other specifications. While there may be good r= eason to add to the number of KDFs supported, I don't think we need to = anticipate or plan for that.
--000000000000532a0e0590ccb883-- From nobody Fri Aug 23 11:23:32 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF19612086D for ; Fri, 23 Aug 2019 11:23:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 u2jnMCYd8PVt for ; Fri, 23 Aug 2019 11:23:21 -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 4051512087E for ; Fri, 23 Aug 2019 11:23:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id EB814300A55 for ; Fri, 23 Aug 2019 14:04:02 -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 JX0WPIHPjISv for ; Fri, 23 Aug 2019 14:03:59 -0400 (EDT) Received: from a860b60074bd.fios-router.home (unknown [138.88.156.37]) by mail.smeinc.net (Postfix) with ESMTPSA id 6F9D9300A51; Fri, 23 Aug 2019 14:03:59 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Russ Housley In-Reply-To: <20190823020007.GZ60855@kduck.mit.edu> Date: Fri, 23 Aug 2019 14:23:14 -0400 Cc: IESG , LAMPS WG Content-Transfer-Encoding: quoted-printable Message-Id: <83F03FA0-4AB4-417D-BABA-69C3424474D0@vigilsec.com> References: <156597611893.31967.2500700648100356711.idtracker@ietfa.amsl.com> <20190823020007.GZ60855@kduck.mit.edu> To: Ben Kaduk X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [lamps] Benjamin Kaduk's Discuss on draft-ietf-lamps-cms-mix-with-psk-06: (with DISCUSS and COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2019 18:23:24 -0000 >>> = ---------------------------------------------------------------------- >>> DISCUSS: >>> = ---------------------------------------------------------------------- >>>=20 >>> I think we need to have a discussion about the abstract API for a >>> KEY-DERIVATION instance and how that relates to what we need for a = key >>> combination operation. In Section 5 we assume that we can use the >>> HKDF terminology, but that doesn't seem to hold universally for >>> KEY-DERIVATION; for example, while HKDF has IKM, salt, and info, = PBKDF2 >>> (from RFC 3211 that AFAICT introduces keyDerivationalgorithm for = CMS) is >>> specified by RFC 2898 as taking just the input secret (password) and = a >>> salt, with no separate 'info' (and of course the different iteration >>> count and PRF parameters needed for its construction). I note (with >>> chagrin, as sponsoring AD) that RFC 8619 says "PARAMS ARE absent" = for >>> the HKDF-based KEY-DERIVATION instances but is silent about how one = is >>> supposed to know what to pass for salt/info (the IKM we can perhaps >>> assume will be obvious). >>>=20 >>> In short, should we be seeking to define a distinct key combination >>> operation like KRB-FX-CF2 (RFC6113) rather than trying to repurpose = key >>> derivation? Some KDFs support this fairly well, but it's not clear = to >>> me that it is a universal property. For example, the proof in = [H2019] >>> seems to be assuming HKDF but this draft does not (as is clearly = seen >>> from the use of the X9.63 KDF in one of the examples). >>=20 >> NIST SP 800-56 Revision 1 offers this high-level interface to the = KDF: >>=20 >> KDF(Z, OtherInput) >>=20 >> - Z: a byte string that represents the shared secret. This ic = called IKM in the HKDF terminology. >>=20 >> - OtherInput includes: >>=20 >> -- salt - a non-null (secret or non-secret) byte string. >>=20 >> -- L - a positive integer that indicates the length (in = bits) of the secret keying material to be derived. >>=20 >> -- FixedInfo - a bit string of context-specific data that is = appropriate for the relying key-establishment scheme. >>=20 >> I do not think that this very high level of API really solves your = concern, but it did guide my thinking in writing the document. >=20 > It is helpful to see this and understand the origin of what's in the > document. (Also that the salt is listed as "secret or non-secret" = here, as > in at least one other place I looked at during my background reading I = saw > it listed as "not-secret", which would be problematic when we want to = put a > secret key in it!) In thins case, I do not see a need for a secret salt, but the NIST SP = 800-56C API allows for it. >> The KDF algorithm identifier has this structure: >>=20 >> AlgorithmIdentifier ::=3D SEQUENCE { >> algorithm OBJECT IDENTIFIER, >> parameters ANY DEFINED BY algorithm OPTIONAL } >>=20 >> The algorithm part lets us name many different KDFs. As you point = out, the examples in Appendix A and Appendix B use HKDF and X9.63 KDF. >>=20 >> Recent discussions in the LAMPS WG show a big bias against complex = parameter strictures. Instead, people have voiced a strong preference = for an object identifier that names all of the options. This leads to = more object identifier assignments, but clear understanding of all = options when one is chosen or negotiated. The one exception is an = initialization vector, where a fresh value is expected each time the = algorithm is invoked. >=20 > Agreed. >=20 >> So, in this document, I have defined a structure of the OtherInput = portion of the NIST API. If a particular KDF needs to use a value from = that structure in a particular way, is can do so. The document uses = HKDF terminology. >>=20 >> If a KDF requires a salt, then it should be provided as a parameter. = I can certainly add that to the document. I believe that KMAC128 and = KMAC256 are algorithms that require a salt. >=20 > Okay, but I'm not sure we've really gotten onto the same page. No, we were not on the same page. The paragraph below really helps me = understand your point. I few things regarding RFC 2631, RFC 3211, RFC 5912, and RFC 5990 just = to make sure we are totally on the same page. RFC 2631 (Diffie-Hellman Key Agreement Method) and X9.42 use a KDF to = compute a KEK from a Diffie-Hellman shared secret and an OtherInfo = structure. RFC 2631 does not call it a KDF, but X9.42 does so. The API = looks a lot like the one for HKDF, except there is no salt. In fact, = the X9.42 KDF could work just fine in with this document. RFC 3211 (Password-based Encryption for CMS) introduced the = KeyDerivationAlgorithmIdentifer, but it does not really offer an API. = It just says that the algorithm is "used to convert the password into a = KEK." It makes PBKDF2, which is specified in RFC 2898, the mandatory to = implement algorithm, but I do not think it would be straightforward to = specify the use of HKDF for this purpose. (I am not sure there is a = need to do this; PBKDF2 works just fine with modern hash functions.) RFC 5912 (New ASN.1 Modules for the Public Key Infrastructure Using = X.509 (PKIX)) introduced the KEY-DERIVATION class. It does not nail = down an API. It couples the object identifier to a parameter structure = for the KeyDerivationAlgorithmIdentifer. RFC5912 uses PBKDF2 as an = example, so there is no doubt that it was intended to support RFC 321. = I do not see anything to prevent the use of the = KeyDerivationAlgorithmIdentifer with HDDF, X9.63, and many others. RFC 5990 (Use of the RSA-KEM Key Transport Algorithm in the = Cryptographic Message Syntax (CMS)) uses the ALGORITHM class, which is = very similar to the KEY-DERIVATION class, for two KDFs, whch are defined = in X9.44: KeyDerivationFunction ::=3D AlgorithmIdentifier {{KDFAlgorithms}} Both of these KDFs would seem to fit well with this document. > I think my main question is whether we're comfortable using a KDF > abstraction like the above (KDF(secret, otherInput)) in a fully = general > sense, and asking for this mix-with-psk to work properly for all = possible > KDFs. For example, would you be comfortable using the construction in = this > document with PBKDF1 as the KDF? No. > I don't even see where we could slot in > the PSK from this document into PBKDF1 -- the API just doesn't seem to = be > flexible enough. =20 Correct. There is no place to input the CMSORIforPSKOtherInfo to be = input. > PBKDF2 allows a more-than-8-octet salt, but is that going > to provide the kind of mixing that we need? Yes, I think it would, but conventions would need to be specified for = mapping the IKM and info inputs into the password input. Simple = concatenation would be okay I suspect. (Again, I am not sure there is a = need to do this.) > I just don't know if all KDFs are going to guarantee the contributory > behavior from the otherInput that we need in order for this scheme to = work. So, would text in Section 6 that says an acceptable KDF MUST accept IKM, = L, and info inputs, and it MAY also accept salt and other inputs. Russ From nobody Fri Aug 23 12:54:08 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 377D31200F5; Fri, 23 Aug 2019 12:54:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=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 dDbnBrUjDYj9; Fri, 23 Aug 2019 12:54:03 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 460CA120047; Fri, 23 Aug 2019 12:54:03 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x7NJrwjN011029 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 23 Aug 2019 15:54:01 -0400 Date: Fri, 23 Aug 2019 14:53:58 -0500 From: Benjamin Kaduk To: Russ Housley Cc: IESG , LAMPS WG Message-ID: <20190823195357.GE60855@kduck.mit.edu> References: <156597611893.31967.2500700648100356711.idtracker@ietfa.amsl.com> <20190823020007.GZ60855@kduck.mit.edu> <83F03FA0-4AB4-417D-BABA-69C3424474D0@vigilsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <83F03FA0-4AB4-417D-BABA-69C3424474D0@vigilsec.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [lamps] Benjamin Kaduk's Discuss on draft-ietf-lamps-cms-mix-with-psk-06: (with DISCUSS and COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2019 19:54:06 -0000 On Fri, Aug 23, 2019 at 02:23:14PM -0400, Russ Housley wrote: > > >>> ---------------------------------------------------------------------- > >>> DISCUSS: > >>> ---------------------------------------------------------------------- > >>> > >>> I think we need to have a discussion about the abstract API for a > >>> KEY-DERIVATION instance and how that relates to what we need for a key > >>> combination operation. In Section 5 we assume that we can use the > >>> HKDF terminology, but that doesn't seem to hold universally for > >>> KEY-DERIVATION; for example, while HKDF has IKM, salt, and info, PBKDF2 > >>> (from RFC 3211 that AFAICT introduces keyDerivationalgorithm for CMS) is > >>> specified by RFC 2898 as taking just the input secret (password) and a > >>> salt, with no separate 'info' (and of course the different iteration > >>> count and PRF parameters needed for its construction). I note (with > >>> chagrin, as sponsoring AD) that RFC 8619 says "PARAMS ARE absent" for > >>> the HKDF-based KEY-DERIVATION instances but is silent about how one is > >>> supposed to know what to pass for salt/info (the IKM we can perhaps > >>> assume will be obvious). > >>> > >>> In short, should we be seeking to define a distinct key combination > >>> operation like KRB-FX-CF2 (RFC6113) rather than trying to repurpose key > >>> derivation? Some KDFs support this fairly well, but it's not clear to > >>> me that it is a universal property. For example, the proof in [H2019] > >>> seems to be assuming HKDF but this draft does not (as is clearly seen > >>> from the use of the X9.63 KDF in one of the examples). > >> > >> NIST SP 800-56 Revision 1 offers this high-level interface to the KDF: > >> > >> KDF(Z, OtherInput) > >> > >> - Z: a byte string that represents the shared secret. This ic called IKM in the HKDF terminology. > >> > >> - OtherInput includes: > >> > >> -- salt - a non-null (secret or non-secret) byte string. > >> > >> -- L - a positive integer that indicates the length (in bits) of the secret keying material to be derived. > >> > >> -- FixedInfo - a bit string of context-specific data that is appropriate for the relying key-establishment scheme. > >> > >> I do not think that this very high level of API really solves your concern, but it did guide my thinking in writing the document. > > > > It is helpful to see this and understand the origin of what's in the > > document. (Also that the salt is listed as "secret or non-secret" here, as > > in at least one other place I looked at during my background reading I saw > > it listed as "not-secret", which would be problematic when we want to put a > > secret key in it!) > > In thins case, I do not see a need for a secret salt, but the NIST SP 800-56C API allows for it. > > >> The KDF algorithm identifier has this structure: > >> > >> AlgorithmIdentifier ::= SEQUENCE { > >> algorithm OBJECT IDENTIFIER, > >> parameters ANY DEFINED BY algorithm OPTIONAL } > >> > >> The algorithm part lets us name many different KDFs. As you point out, the examples in Appendix A and Appendix B use HKDF and X9.63 KDF. > >> > >> Recent discussions in the LAMPS WG show a big bias against complex parameter strictures. Instead, people have voiced a strong preference for an object identifier that names all of the options. This leads to more object identifier assignments, but clear understanding of all options when one is chosen or negotiated. The one exception is an initialization vector, where a fresh value is expected each time the algorithm is invoked. > > > > Agreed. > > > >> So, in this document, I have defined a structure of the OtherInput portion of the NIST API. If a particular KDF needs to use a value from that structure in a particular way, is can do so. The document uses HKDF terminology. > >> > >> If a KDF requires a salt, then it should be provided as a parameter. I can certainly add that to the document. I believe that KMAC128 and KMAC256 are algorithms that require a salt. > > > > Okay, but I'm not sure we've really gotten onto the same page. > > No, we were not on the same page. The paragraph below really helps me understand your point. > > I few things regarding RFC 2631, RFC 3211, RFC 5912, and RFC 5990 just to make sure we are totally on the same page. > > RFC 2631 (Diffie-Hellman Key Agreement Method) and X9.42 use a KDF to compute a KEK from a Diffie-Hellman shared secret and an OtherInfo structure. RFC 2631 does not call it a KDF, but X9.42 does so. The API looks a lot like the one for HKDF, except there is no salt. In fact, the X9.42 KDF could work just fine in with this document. > > RFC 3211 (Password-based Encryption for CMS) introduced the KeyDerivationAlgorithmIdentifer, but it does not really offer an API. It just says that the algorithm is "used to convert the password into a KEK." It makes PBKDF2, which is specified in RFC 2898, the mandatory to implement algorithm, but I do not think it would be straightforward to specify the use of HKDF for this purpose. (I am not sure there is a need to do this; PBKDF2 works just fine with modern hash functions.) > > RFC 5912 (New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)) introduced the KEY-DERIVATION class. It does not nail down an API. It couples the object identifier to a parameter structure for the KeyDerivationAlgorithmIdentifer. RFC5912 uses PBKDF2 as an example, so there is no doubt that it was intended to support RFC 321. I do not see anything to prevent the use of the KeyDerivationAlgorithmIdentifer with HDDF, X9.63, and many others. > > RFC 5990 (Use of the RSA-KEM Key Transport Algorithm in the Cryptographic Message Syntax (CMS)) uses the ALGORITHM class, which is very similar to the KEY-DERIVATION class, for two KDFs, whch are defined in X9.44: > > KeyDerivationFunction ::= AlgorithmIdentifier {{KDFAlgorithms}} > > Both of these KDFs would seem to fit well with this document. Thanks for laying these out -- I was looking at RFCs 3211 and 5912 when doing my review, and agree with your conclusions about 2631 and 5990 as well. > > I think my main question is whether we're comfortable using a KDF > > abstraction like the above (KDF(secret, otherInput)) in a fully general > > sense, and asking for this mix-with-psk to work properly for all possible > > KDFs. For example, would you be comfortable using the construction in this > > document with PBKDF1 as the KDF? > > No. > > > I don't even see where we could slot in > > the PSK from this document into PBKDF1 -- the API just doesn't seem to be > > flexible enough. > > Correct. There is no place to input the CMSORIforPSKOtherInfo to be input. > > > PBKDF2 allows a more-than-8-octet salt, but is that going > > to provide the kind of mixing that we need? > > Yes, I think it would, but conventions would need to be specified for mapping the IKM and info inputs into the password input. Simple concatenation would be okay I suspect. (Again, I am not sure there is a need to do this.) (I'm not sure there's a need, either.) > > I just don't know if all KDFs are going to guarantee the contributory > > behavior from the otherInput that we need in order for this scheme to work. > > So, would text in Section 6 that says an acceptable KDF MUST accept IKM, L, and info inputs, and it MAY also accept salt and other inputs. I think that addresses the core of my concern, yes, and would be enough to resolve the Discuss. (Technically it doesn't really require that the info input gets fully mixed in, but if anyone defines a KDF that does that, they probably deserve what they get.) Thanks, Ben > From nobody Fri Aug 23 13:02:38 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9D7F1200C3 for ; Fri, 23 Aug 2019 13:02:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] 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 MTyoRNpmNBuS for ; Fri, 23 Aug 2019 13:02:25 -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 501C112011D for ; Fri, 23 Aug 2019 13:02:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 47E3D3002C1 for ; Fri, 23 Aug 2019 15:43:07 -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 98UXmgsY8AmO for ; Fri, 23 Aug 2019 15:43:04 -0400 (EDT) Received: from a860b60074bd.fios-router.home (unknown [138.88.156.37]) by mail.smeinc.net (Postfix) with ESMTPSA id BE54B300AF4; Fri, 23 Aug 2019 15:43:03 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Russ Housley In-Reply-To: <20190823195357.GE60855@kduck.mit.edu> Date: Fri, 23 Aug 2019 16:02:20 -0400 Cc: IESG , LAMPS WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <156597611893.31967.2500700648100356711.idtracker@ietfa.amsl.com> <20190823020007.GZ60855@kduck.mit.edu> <83F03FA0-4AB4-417D-BABA-69C3424474D0@vigilsec.com> <20190823195357.GE60855@kduck.mit.edu> To: Ben Kaduk X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [lamps] Benjamin Kaduk's Discuss on draft-ietf-lamps-cms-mix-with-psk-06: (with DISCUSS and COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2019 20:02:28 -0000 Ben: > On Fri, Aug 23, 2019 at 02:23:14PM -0400, Russ Housley wrote: >>=20 >>>>> = ---------------------------------------------------------------------- >>>>> DISCUSS: >>>>> = ---------------------------------------------------------------------- >>>>>=20 >>>>> I think we need to have a discussion about the abstract API for a >>>>> KEY-DERIVATION instance and how that relates to what we need for a = key >>>>> combination operation. In Section 5 we assume that we can use the >>>>> HKDF terminology, but that doesn't seem to hold universally for >>>>> KEY-DERIVATION; for example, while HKDF has IKM, salt, and info, = PBKDF2 >>>>> (from RFC 3211 that AFAICT introduces keyDerivationalgorithm for = CMS) is >>>>> specified by RFC 2898 as taking just the input secret (password) = and a >>>>> salt, with no separate 'info' (and of course the different = iteration >>>>> count and PRF parameters needed for its construction). I note = (with >>>>> chagrin, as sponsoring AD) that RFC 8619 says "PARAMS ARE absent" = for >>>>> the HKDF-based KEY-DERIVATION instances but is silent about how = one is >>>>> supposed to know what to pass for salt/info (the IKM we can = perhaps >>>>> assume will be obvious). >>>>>=20 >>>>> In short, should we be seeking to define a distinct key = combination >>>>> operation like KRB-FX-CF2 (RFC6113) rather than trying to = repurpose key >>>>> derivation? Some KDFs support this fairly well, but it's not = clear to >>>>> me that it is a universal property. For example, the proof in = [H2019] >>>>> seems to be assuming HKDF but this draft does not (as is clearly = seen >>>>> from the use of the X9.63 KDF in one of the examples). >>>>=20 >>>> NIST SP 800-56 Revision 1 offers this high-level interface to the = KDF: >>>>=20 >>>> KDF(Z, OtherInput) >>>>=20 >>>> - Z: a byte string that represents the shared secret. This ic = called IKM in the HKDF terminology. >>>>=20 >>>> - OtherInput includes: >>>>=20 >>>> -- salt - a non-null (secret or non-secret) byte string. >>>>=20 >>>> -- L - a positive integer that indicates the length (in = bits) of the secret keying material to be derived. >>>>=20 >>>> -- FixedInfo - a bit string of context-specific data that is = appropriate for the relying key-establishment scheme. >>>>=20 >>>> I do not think that this very high level of API really solves your = concern, but it did guide my thinking in writing the document. >>>=20 >>> It is helpful to see this and understand the origin of what's in the >>> document. (Also that the salt is listed as "secret or non-secret" = here, as >>> in at least one other place I looked at during my background reading = I saw >>> it listed as "not-secret", which would be problematic when we want = to put a >>> secret key in it!) >>=20 >> In thins case, I do not see a need for a secret salt, but the NIST SP = 800-56C API allows for it. >>=20 >>>> The KDF algorithm identifier has this structure: >>>>=20 >>>> AlgorithmIdentifier ::=3D SEQUENCE { >>>> algorithm OBJECT IDENTIFIER, >>>> parameters ANY DEFINED BY algorithm OPTIONAL } >>>>=20 >>>> The algorithm part lets us name many different KDFs. As you point = out, the examples in Appendix A and Appendix B use HKDF and X9.63 KDF. >>>>=20 >>>> Recent discussions in the LAMPS WG show a big bias against complex = parameter strictures. Instead, people have voiced a strong preference = for an object identifier that names all of the options. This leads to = more object identifier assignments, but clear understanding of all = options when one is chosen or negotiated. The one exception is an = initialization vector, where a fresh value is expected each time the = algorithm is invoked. >>>=20 >>> Agreed. >>>=20 >>>> So, in this document, I have defined a structure of the OtherInput = portion of the NIST API. If a particular KDF needs to use a value from = that structure in a particular way, is can do so. The document uses = HKDF terminology. >>>>=20 >>>> If a KDF requires a salt, then it should be provided as a = parameter. I can certainly add that to the document. I believe that = KMAC128 and KMAC256 are algorithms that require a salt. >>>=20 >>> Okay, but I'm not sure we've really gotten onto the same page. >>=20 >> No, we were not on the same page. The paragraph below really helps = me understand your point. >>=20 >> I few things regarding RFC 2631, RFC 3211, RFC 5912, and RFC 5990 = just to make sure we are totally on the same page. >>=20 >> RFC 2631 (Diffie-Hellman Key Agreement Method) and X9.42 use a KDF to = compute a KEK from a Diffie-Hellman shared secret and an OtherInfo = structure. RFC 2631 does not call it a KDF, but X9.42 does so. The API = looks a lot like the one for HKDF, except there is no salt. In fact, = the X9.42 KDF could work just fine in with this document. >>=20 >> RFC 3211 (Password-based Encryption for CMS) introduced the = KeyDerivationAlgorithmIdentifer, but it does not really offer an API. = It just says that the algorithm is "used to convert the password into a = KEK." It makes PBKDF2, which is specified in RFC 2898, the mandatory to = implement algorithm, but I do not think it would be straightforward to = specify the use of HKDF for this purpose. (I am not sure there is a = need to do this; PBKDF2 works just fine with modern hash functions.) >>=20 >> RFC 5912 (New ASN.1 Modules for the Public Key Infrastructure Using = X.509 (PKIX)) introduced the KEY-DERIVATION class. It does not nail = down an API. It couples the object identifier to a parameter structure = for the KeyDerivationAlgorithmIdentifer. RFC5912 uses PBKDF2 as an = example, so there is no doubt that it was intended to support RFC 321. = I do not see anything to prevent the use of the = KeyDerivationAlgorithmIdentifer with HDDF, X9.63, and many others. >>=20 >> RFC 5990 (Use of the RSA-KEM Key Transport Algorithm in the = Cryptographic Message Syntax (CMS)) uses the ALGORITHM class, which is = very similar to the KEY-DERIVATION class, for two KDFs, whch are defined = in X9.44: >>=20 >> KeyDerivationFunction ::=3D AlgorithmIdentifier {{KDFAlgorithms}} >>=20 >> Both of these KDFs would seem to fit well with this document. >=20 > Thanks for laying these out -- I was looking at RFCs 3211 and 5912 = when > doing my review, and agree with your conclusions about 2631 and 5990 = as > well. >=20 >>> I think my main question is whether we're comfortable using a KDF >>> abstraction like the above (KDF(secret, otherInput)) in a fully = general >>> sense, and asking for this mix-with-psk to work properly for all = possible >>> KDFs. For example, would you be comfortable using the construction = in this >>> document with PBKDF1 as the KDF? >>=20 >> No. >>=20 >>> I don't even see where we could slot in >>> the PSK from this document into PBKDF1 -- the API just doesn't seem = to be >>> flexible enough. =20 >>=20 >> Correct. There is no place to input the CMSORIforPSKOtherInfo to be = input. >>=20 >>> PBKDF2 allows a more-than-8-octet salt, but is that going >>> to provide the kind of mixing that we need? >>=20 >> Yes, I think it would, but conventions would need to be specified for = mapping the IKM and info inputs into the password input. Simple = concatenation would be okay I suspect. (Again, I am not sure there is a = need to do this.) >=20 > (I'm not sure there's a need, either.) >=20 >>> I just don't know if all KDFs are going to guarantee the = contributory >>> behavior from the otherInput that we need in order for this scheme = to work. >>=20 >> So, would text in Section 6 that says an acceptable KDF MUST accept = IKM, L, and info inputs, and it MAY also accept salt and other inputs. >=20 > I think that addresses the core of my concern, yes, and would be = enough to > resolve the Discuss. (Technically it doesn't really require that the = info > input gets fully mixed in, but if anyone defines a KDF that does that, = they > probably deserve what they get.) I will add a sentence that all of the inputs MUST influence the output = of the KDF. I do not want to turn this into a how-to for KDF design... Russ From nobody Fri Aug 23 13:13:48 2019 Return-Path: X-Original-To: spasm@ietf.org Delivered-To: spasm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A380712018B; Fri, 23 Aug 2019 13:13:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spasm@ietf.org Message-ID: <156659122560.25070.13847937461699067185@ietfa.amsl.com> Date: Fri, 23 Aug 2019 13:13:45 -0700 Archived-At: Subject: [lamps] I-D Action: draft-ietf-lamps-cms-mix-with-psk-07.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2019 20:13:46 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Limited Additional Mechanisms for PKIX and SMIME WG of the IETF. Title : Using Pre-Shared Key (PSK) in the Cryptographic Message Syntax (CMS) Author : Russ Housley Filename : draft-ietf-lamps-cms-mix-with-psk-07.txt Pages : 31 Date : 2019-08-23 Abstract: The invention of a large-scale quantum computer would pose a serious challenge for the cryptographic algorithms that are widely deployed today. The Cryptographic Message Syntax (CMS) supports key transport and key agreement algorithms that could be broken by the invention of such a quantum computer. By storing communications that are protected with the CMS today, someone could decrypt them in the future when a large-scale quantum computer becomes available. Once quantum-secure key management algorithms are available, the CMS will be extended to support the new algorithms, if the existing syntax does not accommodate them. In the near-term, this document describes a mechanism to protect today's communication from the future invention of a large-scale quantum computer by mixing the output of key transport and key agreement algorithms with a pre-shared key. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-mix-with-psk/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lamps-cms-mix-with-psk-07 https://datatracker.ietf.org/doc/html/draft-ietf-lamps-cms-mix-with-psk-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-cms-mix-with-psk-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Aug 23 13:16:05 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 443B9120122 for ; Fri, 23 Aug 2019 13:15:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] 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 ApKGXl7CL_tC for ; Fri, 23 Aug 2019 13:15:44 -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 E431012018B for ; Fri, 23 Aug 2019 13:15:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id F3678300AF3 for ; Fri, 23 Aug 2019 15:56:25 -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 XnwVVlxF1BiO for ; Fri, 23 Aug 2019 15:56:24 -0400 (EDT) Received: from a860b60074bd.fios-router.home (unknown [138.88.156.37]) by mail.smeinc.net (Postfix) with ESMTPSA id 690C13002C1; Fri, 23 Aug 2019 15:56:24 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Russ Housley In-Reply-To: <156659122560.25070.13847937461699067185@ietfa.amsl.com> Date: Fri, 23 Aug 2019 16:15:41 -0400 Cc: IESG Content-Transfer-Encoding: quoted-printable Message-Id: References: <156659122560.25070.13847937461699067185@ietfa.amsl.com> To: LAMPS WG X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [lamps] I-D Action: draft-ietf-lamps-cms-mix-with-psk-07.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2019 20:15:46 -0000 This update resolves the comments that were raised during IESG = Evaluation. Russ > On Aug 23, 2019, at 4:13 PM, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Limited Additional Mechanisms for = PKIX and SMIME WG of the IETF. >=20 > Title : Using Pre-Shared Key (PSK) in the = Cryptographic Message Syntax (CMS) > Author : Russ Housley > Filename : draft-ietf-lamps-cms-mix-with-psk-07.txt > Pages : 31 > Date : 2019-08-23 >=20 > Abstract: > The invention of a large-scale quantum computer would pose a serious > challenge for the cryptographic algorithms that are widely deployed > today. The Cryptographic Message Syntax (CMS) supports key = transport > and key agreement algorithms that could be broken by the invention = of > such a quantum computer. By storing communications that are > protected with the CMS today, someone could decrypt them in the > future when a large-scale quantum computer becomes available. Once > quantum-secure key management algorithms are available, the CMS will > be extended to support the new algorithms, if the existing syntax > does not accommodate them. In the near-term, this document = describes > a mechanism to protect today's communication from the future > invention of a large-scale quantum computer by mixing the output of > key transport and key agreement algorithms with a pre-shared key. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-mix-with-psk/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-lamps-cms-mix-with-psk-07 > = https://datatracker.ietf.org/doc/html/draft-ietf-lamps-cms-mix-with-psk-07= >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lamps-cms-mix-with-psk-07= >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Aug 23 15:29:12 2019 Return-Path: X-Original-To: spasm@ietf.org Delivered-To: spasm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DA5412000F; Fri, 23 Aug 2019 15:29:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-lamps-cms-mix-with-psk@ietf.org, Tim Hollebeek , lamps-chairs@ietf.org, tim.hollebeek@digicert.com, spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <156659934424.25026.15688403505897420278.idtracker@ietfa.amsl.com> Date: Fri, 23 Aug 2019 15:29:04 -0700 Archived-At: Subject: [lamps] Benjamin Kaduk's No Objection on draft-ietf-lamps-cms-mix-with-psk-07: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2019 22:29:04 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-lamps-cms-mix-with-psk-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-mix-with-psk/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for addressing my Discuss point! From nobody Sat Aug 24 06:49:17 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6F0B12001A for ; Sat, 24 Aug 2019 06:49: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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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 WFNsUe98Szaf for ; Sat, 24 Aug 2019 06:49:13 -0700 (PDT) Received: from mx1.entrustdatacard.com (mx1.entrustdatacard.com [204.124.80.220]) (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 8A94012001B for ; Sat, 24 Aug 2019 06:49:13 -0700 (PDT) IronPort-SDR: 6+Yd3AFd5BEXJBAfsRvvK5V30zVj5inHOJFPqP0SyEeLbTxENMIYRVVbuQqsLB0FFvOWoxE2zj 4ZLDWi6j8z6A== X-IronPort-AV: E=Sophos;i="5.64,425,1559538000"; d="scan'208";a="55465807" Received: from pmspex01.corporate.datacard.com (HELO owa.entrustdatacard.com) ([192.168.211.29]) by pmspesa03inside.corporate.datacard.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA384; 24 Aug 2019 08:49:12 -0500 Received: from PMSPEX05.corporate.datacard.com (192.168.211.52) by pmspex01.corporate.datacard.com (192.168.211.29) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sat, 24 Aug 2019 08:49:12 -0500 Received: from PMSPEX05.corporate.datacard.com ([fe80::8084:293e:7f03:4ab2]) by PMSPEX05.corporate.datacard.com ([fe80::8084:293e:7f03:4ab2%12]) with mapi id 15.00.1497.000; Sat, 24 Aug 2019 08:49:12 -0500 From: Mike Ounsworth To: "spasm@ietf.org" Thread-Topic: Re-charter text for LAMPS to work on Post-Quantum, and PQ problem statement Thread-Index: AdVagooKGrRjGm0KRwu26mtcjpHrXA== Date: Sat, 24 Aug 2019 13:49:12 +0000 Message-ID: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.1.43.131] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [lamps] Re-charter text for LAMPS to work on Post-Quantum, and PQ problem statement X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Aug 2019 13:49:16 -0000 Hi LAMPS, After the discussion at 105, I'm going to take a step back from my "composi= te crypto" draft and propose: A) LAMPS re-charter so that post-quantum is guaranteed time on future agend= as. B) As a group, we define the post-quantum certificates problem that we're t= rying to solve, and examine the whole space of possible solutions. --- A) Proposed re-charter text: > Quantum computers and the emerging post-quantum cryptographic algorithms = present a unique agility challenge in that legacy algorithms may become com= promised before we have full trust in, or adoption of, the replacement algo= rithms. The prevailing opinion in the crypto community is to address this u= ncertainty by layering all crypto operations with legacy and post-quantum a= lgorithms during the transition period. LAMPS is tasked with specifying app= ropriate mechanism(s) by which PKIX and relying protocols can leverage publ= ic keys from two or more algorithms in the same cryptographically-protected= transaction. Proposed mechanisms should address combining new and conventi= onal algorithms, backwards compatibility, and increased certificate size. B= oth negotiated and non-negotiated protocols need to be considered. The first discussion question is: what is appropriate for LAMPS adoption he= re? If it doesn't get adopted by LAMPS, maybe we need a specific PQ WG? May= be we should run a BoF session at 106? --- B) Problem statement and solutions overview; I put up a draft here: https://datatracker.ietf.org/doc/draft-pq-pkix-problem-statement/ Let the discussions begin! - - - Mike Ounsworth | Software Security Architect Entrust Datacard From nobody Sat Aug 24 07:01:56 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02B4E120026 for ; Sat, 24 Aug 2019 07:01:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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_MED=-2.3, SPF_HELO_NONE=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=cs.tcd.ie 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 tmEbO4jsDw4H for ; Sat, 24 Aug 2019 07:01:51 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 938BA12001A for ; Sat, 24 Aug 2019 07:01:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 0E0ACBE2C; Sat, 24 Aug 2019 15:01:49 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bV2JqByiGDfk; Sat, 24 Aug 2019 15:01:47 +0100 (IST) Received: from [10.244.2.138] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 81B73BE2F; Sat, 24 Aug 2019 15:01:47 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1566655307; bh=I4y4IxtLQomrUI8Xck6DnpuNVfTcbq7bMzW3rclsCos=; h=Subject:To:References:From:Date:In-Reply-To:From; b=NpNqh99HriftVRgmRJnZga1r5/GhdzmSNx69hbRO3OKM4N65n05O2DaK+QHHqPKKK 3a+xS8GIoIRNgFx79s5POHqpSIgPiVcMVFnemeCgRCbAPAEJcG0KjZj3jfXAgeD1w/ 0Jwu3rYO/mQxYNyf/p/Lf+fHwPaUCGyMSBW5VyQw= To: Mike Ounsworth , "spasm@ietf.org" References: From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: <692ac76d-2501-40f1-0ea6-93309a1f2822@cs.tcd.ie> Date: Sat, 24 Aug 2019 15:01:46 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="broNRvIQZYQYhAQAUH6I8AVsYYmshUlMS" Archived-At: Subject: Re: [lamps] Re-charter text for LAMPS to work on Post-Quantum, and PQ problem statement X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Aug 2019 14:01:54 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --broNRvIQZYQYhAQAUH6I8AVsYYmshUlMS Content-Type: multipart/mixed; boundary="XFgOnDMCyANdNbYWBbtMtbOVUs1RuRdxH"; protected-headers="v1" From: Stephen Farrell To: Mike Ounsworth , "spasm@ietf.org" Message-ID: <692ac76d-2501-40f1-0ea6-93309a1f2822@cs.tcd.ie> Subject: Re: [lamps] Re-charter text for LAMPS to work on Post-Quantum, and PQ problem statement References: In-Reply-To: --XFgOnDMCyANdNbYWBbtMtbOVUs1RuRdxH Content-Type: multipart/mixed; boundary="------------06DD03EE3987DDF93EC01901" Content-Language: en-GB This is a multi-part message in MIME format. --------------06DD03EE3987DDF93EC01901 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Sorry to be negative but... On 24/08/2019 14:49, Mike Ounsworth wrote: > A) LAMPS re-charter so that post-quantum is guaranteed time on future a= gendas. To me, that's close to the antithesis of what LAMPS was setup to do. If current PKI is going to be challenged by quantum computers then IMO we ought re-think x.509-based PKI and not just consider all that an issue to tackle via algorithm agility and whatever other ad-hoc hacks we stumble upon. x.509 is >30 years old as a container technology for public keys. Pretty much everyone hates it or just about puts up with it. IMO we ought not continue to use x.509 across such a classic/post-quantum boundary - if we get anywhere near wanting multiple keys bound to an identifier (and have >1 of those used for a single key establishment) then I can't see how the costs of re-using x.509 would be worthwhile compared to the costs of ditching x.509. Such a re-think is definitely not a limited additional mechanism for PKIX or S/MIME. S. --------------06DD03EE3987DDF93EC01901 Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------06DD03EE3987DDF93EC01901-- --XFgOnDMCyANdNbYWBbtMtbOVUs1RuRdxH-- --broNRvIQZYQYhAQAUH6I8AVsYYmshUlMS Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl1hQ0oACgkQWrL68XsX K+q0BQ//cpHva8N5N2dl/IizlhJf91nzYvTuVayAZRpDfSA2AabLp68pMOjTWvDf wXiUgd+SCPAdost/ZhOoMtIH/Q7XZVpi9ridFiudYWxb+O0v9q8600sQcwkIwI1G nsKwnZ7EIP6vP8LipNPGXsl+1c94ciu4agNbrwTC2Gtz3D2P9ZlYb8mVpBGJXv0J 8J/yGMxUhsCYDdm3/uEhPUDq+ALst6pvCZf6TEDxZcQhqvp6QV9Bn3p7v5DOV4dN Ft8BuYhGZIWWrWl8W3touomix9bcqtm2Su1iMesNxuSRIwqnb7qEXKJO4XafOZqE zWk8lXt1s6/PBel+3SMvFQgNdtMwRpQMZufYxAXF3CDfMt+A8M3Uwn3Wa0cWG28q CsGznc5D1O3DdyzNYN4e4/+Ge6Riku8dHZlNwiu3kxpmiij/qoSvum4F14I0thNl oaKxGNxd+7BirfpX6AoS+mmZcc5SUge177CYQS5qtLDYme12/dNqvauqdWdvZI+p Bzr/KIQuegDtw9za8aNj4qkWPof2B+k1zIn3NlL2NU5iXbLooMdBv24nWeB9Z1B6 tsAZ8UapKh3bnm70yrkA2uY2cS8nrWWwmwLBqsxHWCsCB+nGhA3ztWyDHt8zZ3oM wO27XRg8exWToI6bZT7dSOfyNtJ1pPhV7VBrImi36bGzRM1A7+Y= =G5Wg -----END PGP SIGNATURE----- --broNRvIQZYQYhAQAUH6I8AVsYYmshUlMS-- From nobody Mon Aug 26 12:05:11 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA18E120D0A; Mon, 26 Aug 2019 12:04:56 -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, RCVD_IN_DNSWL_MED=-2.3, 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 L0Dm_1B8FfDR; Mon, 26 Aug 2019 12:04:54 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D113120D09; Mon, 26 Aug 2019 12:04:54 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 632A5B80BC1; Mon, 26 Aug 2019 12:04:40 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, spasm@ietf.org Content-type: text/plain; charset=UTF-8 Message-Id: <20190826190440.632A5B80BC1@rfc-editor.org> Date: Mon, 26 Aug 2019 12:04:40 -0700 (PDT) Archived-At: Subject: [lamps] =?utf-8?q?RFC_8649_on_Hash_Of_Root_Key_Certificate_Exten?= =?utf-8?q?sion?= X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2019 19:05:03 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8649 Title: Hash Of Root Key Certificate Extension Author: R. Housley Status: Informational Stream: IETF Date: August 2019 Mailbox: housley@vigilsec.com Pages: 10 Characters: 22410 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-lamps-hash-of-root-key-cert-extn-07.txt URL: https://www.rfc-editor.org/info/rfc8649 DOI: 10.17487/RFC8649 This document specifies the Hash Of Root Key certificate extension. This certificate extension is carried in the self-signed certificate for a trust anchor, which is often called a Root Certification Authority (CA) certificate. This certificate extension unambiguously identifies the next public key that will be used at some point in the future as the next Root CA certificate, eventually replacing the current one. This document is a product of the Limited Additional Mechanisms for PKIX and SMIME Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Mon Aug 26 14:58:39 2019 Return-Path: X-Original-To: spasm@ietf.org Delivered-To: spasm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2527C120838; Mon, 26 Aug 2019 14:58:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Cc: rdd@cert.org, lamps-chairs@ietf.org, draft-ietf-lamps-cms-mix-with-psk@ietf.org, spasm@ietf.org, Tim Hollebeek , tim.hollebeek@digicert.com, The IESG , rfc-editor@rfc-editor.org Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Message-ID: <156685670514.2617.5794670746049151044.idtracker@ietfa.amsl.com> Date: Mon, 26 Aug 2019 14:58:25 -0700 Archived-At: Subject: [lamps] Protocol Action: 'Using Pre-Shared Key (PSK) in the Cryptographic Message Syntax (CMS)' to Proposed Standard (draft-ietf-lamps-cms-mix-with-psk-07.txt) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2019 21:58:25 -0000 The IESG has approved the following document: - 'Using Pre-Shared Key (PSK) in the Cryptographic Message Syntax (CMS)' (draft-ietf-lamps-cms-mix-with-psk-07.txt) as Proposed Standard This document is the product of the Limited Additional Mechanisms for PKIX and SMIME Working Group. The IESG contact persons are Benjamin Kaduk and Roman Danyliw. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-mix-with-psk/ Technical Summary This document specifies a way of mixing a pre-shared key into the output of key transport and key agreement algorithms used as part of messages encoding using Cryptographic Message Syntax (CMS). This is a mechanism that can be used today that will protect against message decryption by future adversaries once cryptographically relevant quantum computers become available. This bridges the gap until quantum-safe key transport and key agreement algorithms are available. Working Group Summary Was there anything in the WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? Document Quality There is consensus for this document in the LAMPS WG. The document shepherd, other LAMPS WG participants and GENART reviewed the document during WG/IETF Last Call. All issues raised have been resolved. Personnel Tim Hollebeek is the document shepherd. Roman Danyliw is the responsible area director. From nobody Tue Aug 27 12:28:24 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B4F8120089 for ; Tue, 27 Aug 2019 12:28:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 iIxJTGV3K4Wp for ; Tue, 27 Aug 2019 12:28:21 -0700 (PDT) Received: from mx1.entrustdatacard.com (mx1.entrustdatacard.com [204.124.80.220]) (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 17AF0120236 for ; Tue, 27 Aug 2019 12:28:20 -0700 (PDT) IronPort-SDR: uknV5KlhIrvt+JEtG0IhNr7K2P8izEaZskMtzW83EwBGDVQOCJGdusLu0+HS7V80H/QwsLG7aX RGJzK7LKprKQ== X-IronPort-AV: E=Sophos;i="5.64,438,1559538000"; d="scan'208";a="55651274" Received: from pmspex03.corporate.datacard.com (HELO owa.entrustdatacard.com) ([192.168.211.50]) by pmspesa03inside.corporate.datacard.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA384; 27 Aug 2019 14:28:20 -0500 Received: from PMSPEX05.corporate.datacard.com (192.168.211.52) by PMSPEX03.corporate.datacard.com (192.168.211.50) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 27 Aug 2019 14:28:19 -0500 Received: from PMSPEX05.corporate.datacard.com ([fe80::8084:293e:7f03:4ab2]) by PMSPEX05.corporate.datacard.com ([fe80::8084:293e:7f03:4ab2%12]) with mapi id 15.00.1497.000; Tue, 27 Aug 2019 14:28:19 -0500 From: Mike Ounsworth To: Stephen Farrell , "spasm@ietf.org" Thread-Topic: [EXTERNAL]Re: [lamps] Re-charter text for LAMPS to work on Post-Quantum, and PQ problem statement Thread-Index: AdVagooKGrRjGm0KRwu26mtcjpHrXAAK9YIAAAQpmeA= Date: Tue, 27 Aug 2019 19:28:19 +0000 Message-ID: References: <692ac76d-2501-40f1-0ea6-93309a1f2822@cs.tcd.ie> In-Reply-To: <692ac76d-2501-40f1-0ea6-93309a1f2822@cs.tcd.ie> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.4.210.57] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [lamps] [EXTERNAL]Re: Re-charter text for LAMPS to work on Post-Quantum, and PQ problem statement X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2019 19:28:23 -0000 VGhhbmtzIGZvciB0aGUgZmVlZGJhY2sgU3RlcGhlbiwNCg0KSSBzZWUgeW91ciBwb2ludCB0aGF0 IHN1Y2ggYSByZS10aGluayAvIHJlcGxhY2VtZW50IG9mIFguNTA5IGlzIHdlbGwgb3V0c2lkZSB0 aGUgc2NvcGUgb2YgTEFNUFMuDQoNCg0KSSBiZWxpZXZlIHRoYXQgdGhlcmUgYXJlIHRocmVlIGNh dGVnb3JpZXMgb2Ygc21hbGwgbW9kaWZpY2F0aW9ucyB0byBleGlzdGluZyBYLjUwOS1iYXNlZCBQ S0lzIHRoYXQgd2lsbCBhY2NvbXBsaXNoIHRoZSBnb2FsIChhcyBvdXRsaW5lZCBpbiBteSAiUHJv YmxlbSBTdGF0dW1lbnQiIGRyYWZ0IGJlbG93KQ0KDQpUaGUgcXVlc3Rpb24gSSdtIGFza2luZyBp cyB3aGljaCBYLjUwOSB0d2VhayBzb2x1dGlvbihzKSBhcmUgd29ydGggcHVyc3Vpbmc/IEFuZCBo b3cgLyB3aGVyZT8NCg0KLSAtIC0NCk1pa2UgT3Vuc3dvcnRoIHwgT2ZmaWNlOiArMSAoNjEzKSAy NzAtMjg3Mw0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPiANClNlbnQ6IFNhdHVyZGF5LCBBdWd1c3Qg MjQsIDIwMTkgNzowMiBBTQ0KVG86IE1pa2UgT3Vuc3dvcnRoIDxNaWtlLk91bnN3b3J0aEBlbnRy dXN0ZGF0YWNhcmQuY29tPjsgc3Bhc21AaWV0Zi5vcmcNClN1YmplY3Q6IFtFWFRFUk5BTF1SZTog W2xhbXBzXSBSZS1jaGFydGVyIHRleHQgZm9yIExBTVBTIHRvIHdvcmsgb24gUG9zdC1RdWFudHVt LCBhbmQgUFEgcHJvYmxlbSBzdGF0ZW1lbnQNCg0KDQpTb3JyeSB0byBiZSBuZWdhdGl2ZSBidXQu Li4NCg0KT24gMjQvMDgvMjAxOSAxNDo0OSwgTWlrZSBPdW5zd29ydGggd3JvdGU6DQo+IEEpIExB TVBTIHJlLWNoYXJ0ZXIgc28gdGhhdCBwb3N0LXF1YW50dW0gaXMgZ3VhcmFudGVlZCB0aW1lIG9u IGZ1dHVyZSBhZ2VuZGFzLg0KDQpUbyBtZSwgdGhhdCdzIGNsb3NlIHRvIHRoZSBhbnRpdGhlc2lz IG9mIHdoYXQgTEFNUFMgd2FzIHNldHVwIHRvIGRvLg0KDQpJZiBjdXJyZW50IFBLSSBpcyBnb2lu ZyB0byBiZSBjaGFsbGVuZ2VkIGJ5IHF1YW50dW0gY29tcHV0ZXJzIHRoZW4gSU1PIHdlIG91Z2h0 IHJlLXRoaW5rIHguNTA5LWJhc2VkIFBLSSBhbmQgbm90IGp1c3QgY29uc2lkZXIgYWxsIHRoYXQg YW4gaXNzdWUgdG8gdGFja2xlIHZpYSBhbGdvcml0aG0gYWdpbGl0eSBhbmQgd2hhdGV2ZXIgb3Ro ZXIgYWQtaG9jIGhhY2tzIHdlIHN0dW1ibGUgdXBvbi4NCg0KeC41MDkgaXMgPjMwIHllYXJzIG9s ZCBhcyBhIGNvbnRhaW5lciB0ZWNobm9sb2d5IGZvciBwdWJsaWMga2V5cy4gUHJldHR5IG11Y2gg ZXZlcnlvbmUgaGF0ZXMgaXQgb3IganVzdCBhYm91dCBwdXRzIHVwIHdpdGggaXQuIElNTyB3ZSBv dWdodCBub3QgY29udGludWUgdG8gdXNlIHguNTA5IGFjcm9zcyBzdWNoIGEgY2xhc3NpYy9wb3N0 LXF1YW50dW0gYm91bmRhcnkgLSBpZiB3ZSBnZXQgYW55d2hlcmUgbmVhciB3YW50aW5nIG11bHRp cGxlIGtleXMgYm91bmQgdG8gYW4gaWRlbnRpZmllciAoYW5kIGhhdmUgPjEgb2YgdGhvc2UgdXNl ZCBmb3IgYSBzaW5nbGUga2V5IGVzdGFibGlzaG1lbnQpIHRoZW4gSSBjYW4ndCBzZWUgaG93IHRo ZSBjb3N0cyBvZiByZS11c2luZyB4LjUwOSB3b3VsZCBiZSB3b3J0aHdoaWxlIGNvbXBhcmVkIHRv IHRoZSBjb3N0cyBvZiBkaXRjaGluZyB4LjUwOS4NCg0KU3VjaCBhIHJlLXRoaW5rIGlzIGRlZmlu aXRlbHkgbm90IGEgbGltaXRlZCBhZGRpdGlvbmFsIG1lY2hhbmlzbSBmb3IgUEtJWCBvciBTL01J TUUuDQoNClMuDQo= From nobody Tue Aug 27 13:38:21 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DD90120288 for ; Tue, 27 Aug 2019 13:37:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.965 X-Spam-Level: X-Spam-Status: No, score=-0.965 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_MED=-2.3, RCVD_IN_SBL_CSS=3.335, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 MsmhhmU-w6ZI for ; Tue, 27 Aug 2019 13:37:58 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A885412013B for ; Tue, 27 Aug 2019 13:37:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 2F6C7BE55; Tue, 27 Aug 2019 21:37:54 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D9mx9rrdZ_sC; Tue, 27 Aug 2019 21:37:52 +0100 (IST) Received: from [10.244.2.138] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id A6A66BE47; Tue, 27 Aug 2019 21:37:52 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1566938272; bh=sr0iPo44y5rBR1qYylMcOlucsMbzI+ec0Th/Hha3G0U=; h=Subject:To:References:From:Date:In-Reply-To:From; b=lxL1CyVR3K3QWDRVzXJTCzx7E7Nd4K3KO3xxMuUNL/o6p47YXaNxUUom5GvIvubW4 FkdSnOgH6olzz4bVRfD1JGQErxeLSKK+TAo5xcYk1vFvuR/m3OHECWSU9+4m39ifm0 +3d76LQAWBrtVtCBJvnfMydKiu5hyRfOxM8FC7Yc= To: Mike Ounsworth , "spasm@ietf.org" References: <692ac76d-2501-40f1-0ea6-93309a1f2822@cs.tcd.ie> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: <4251c30a-8ef2-d0c5-95e7-7787aedd22d0@cs.tcd.ie> Date: Tue, 27 Aug 2019 21:37:52 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="jacEuael7lBRrrxQzbz98gxWzTMyWcckQ" Archived-At: Subject: Re: [lamps] [EXTERNAL]Re: Re-charter text for LAMPS to work on Post-Quantum, and PQ problem statement X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2019 20:38:02 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --jacEuael7lBRrrxQzbz98gxWzTMyWcckQ Content-Type: multipart/mixed; boundary="IaKSYw87J9vEWPNcyqi7XIVJfd6ZJmFCg"; protected-headers="v1" From: Stephen Farrell To: Mike Ounsworth , "spasm@ietf.org" Message-ID: <4251c30a-8ef2-d0c5-95e7-7787aedd22d0@cs.tcd.ie> Subject: Re: [EXTERNAL]Re: [lamps] Re-charter text for LAMPS to work on Post-Quantum, and PQ problem statement References: <692ac76d-2501-40f1-0ea6-93309a1f2822@cs.tcd.ie> In-Reply-To: --IaKSYw87J9vEWPNcyqi7XIVJfd6ZJmFCg Content-Type: multipart/mixed; boundary="------------4C19D9E489B1CA1717F98817" Content-Language: en-GB This is a multi-part message in MIME format. --------------4C19D9E489B1CA1717F98817 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 27/08/2019 20:28, Mike Ounsworth wrote: > I believe that there are three categories of small modifications to > existing X.509-based PKIs that will accomplish the goal (as outlined > in my "Problem Statument" draft below) I agree we're espousing different approaches to thinking about what to do with PKI in a possible PQ crypto world. Even if the correct approach to authentication in a PQ world were to tweak X.509 (which I don't accept, esp if alternatives have not been explored) I would still argue that that's too big a thing to be considered a "Limited additional mechanism" as it involves entirely new cryptographic algorithms with as-yet not well understood protocol and API impacts. It's just kind of laughable to claim that's anything like a reasonable use of the term limited. This is a fine example of why we really ought not allow this WG to become a zombie PKIX that ingests and regurgitates anything even vaguely related to PKI. That didn't serve us well when we did it before. At that point (maybe from 2004ish on?) I was one of the regurgitators, so I fully understand why this may seem attractive, but it's just a bad plan IMO that's highly likely to lead to wasted effort and worse interop. Again, sorry to be so negative. To be positive, I would support a non-WG forming BoF or mailing list on the topic of "what to do about PKI in a PQ world and when to start doing anything at all." Cheers, S. --------------4C19D9E489B1CA1717F98817 Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------4C19D9E489B1CA1717F98817-- --IaKSYw87J9vEWPNcyqi7XIVJfd6ZJmFCg-- --jacEuael7lBRrrxQzbz98gxWzTMyWcckQ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl1llKAACgkQWrL68XsX K+q9/xAAwtbEL4Lidn4zsX5G4qWOsBWF9Bf94cX+VJhuCMmpocR0KMAa0Qj3hWFk c0OJLSojd7tw3E+4BltBg1qy4URrgZt61I+XN9WcyvElLQ9FAwf1xGhWm43X3VLe 2gtMF9/WXe/kG/5T8dK31PDpAHTMUIR3qN7cGjO9S2PkDatKlDfgvKq3xN6UoxLl avrc5ui7jwvYh/LsrNAZ1CgiyGQU1jMx7eSp5oKiuOGIwYlOMYzUEYwjntuy2RXt O5+3esUdqsQd7M1TJZ57CIvdWBK+6T0C4gjFzd0w5vQgp7fycC2dfqouPKEq1cf6 5FpAa9Je/x57roOD8+fqHsurtgT/LLESzPQyOQytTZ37BBvpx+fYBqrh8lpWWOwb gFQbzv+aFNJtxpiXsqjI1eoZ3wM9JoNMz3M4utvK1RWjeOwaWWD7DO7I0Hv3eJkd so50Rs+D5zYpIgnns50ot2XAZNBSw7kbFxrLC8tn3DPsoZmmUSQ7mongqYC3S8SR nhbINjpST2vDws2uqo6N5UJMAojChhcn3q2vN+5kO6Y87qQ8elQ6GcWA2Mr+uifD HWX0TvnmgXRODeq+MEa9K2kehg6MsA6IF8iYQn6vYPVoP1OwBB2xIkK+p4StU/UO YfwXox/skANZfjDQi1Q21+U0WrdphhrKVL4hkyMZIc8u+7LVAu4= =Y+Zd -----END PGP SIGNATURE----- --jacEuael7lBRrrxQzbz98gxWzTMyWcckQ-- From nobody Wed Aug 28 11:36:41 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD2D912001B for ; Wed, 28 Aug 2019 11:36:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 En-JH-o4Z3zC for ; Wed, 28 Aug 2019 11:36:37 -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 A70FF120059 for ; Wed, 28 Aug 2019 11:36:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 9EB7C300AAB for ; Wed, 28 Aug 2019 14:17:19 -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 JguDzg4q7zFn for ; Wed, 28 Aug 2019 14:17:17 -0400 (EDT) Received: from a860b60074bd.fios-router.home (unknown [138.88.156.37]) by mail.smeinc.net (Postfix) with ESMTPSA id 96569300A49; Wed, 28 Aug 2019 14:17:17 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Russ Housley In-Reply-To: Date: Wed, 28 Aug 2019 14:36:34 -0400 Cc: Stephen Farrell , "spasm@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <30E31703-8C7F-49C8-ABB4-5FA061C67D97@vigilsec.com> References: <692ac76d-2501-40f1-0ea6-93309a1f2822@cs.tcd.ie> To: Mike Ounsworth X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [lamps] [EXTERNAL]Re: Re-charter text for LAMPS to work on Post-Quantum, and PQ problem statement X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2019 18:36:40 -0000 Mike: I think that you should take your draft to the SECDISPATCH mail list and = see if they want to put you on their agenda or go straight to a BoF. Russ > On Aug 27, 2019, at 3:28 PM, Mike Ounsworth = wrote: >=20 > Thanks for the feedback Stephen, >=20 > I see your point that such a re-think / replacement of X.509 is well = outside the scope of LAMPS. >=20 >=20 > I believe that there are three categories of small modifications to = existing X.509-based PKIs that will accomplish the goal (as outlined in = my "Problem Statument" draft below) >=20 > The question I'm asking is which X.509 tweak solution(s) are worth = pursuing? And how / where? >=20 > - - - > Mike Ounsworth | Office: +1 (613) 270-2873 >=20 > -----Original Message----- > From: Stephen Farrell =20 > Sent: Saturday, August 24, 2019 7:02 AM > To: Mike Ounsworth ; = spasm@ietf.org > Subject: [EXTERNAL]Re: [lamps] Re-charter text for LAMPS to work on = Post-Quantum, and PQ problem statement >=20 >=20 > Sorry to be negative but... >=20 > On 24/08/2019 14:49, Mike Ounsworth wrote: >> A) LAMPS re-charter so that post-quantum is guaranteed time on future = agendas. >=20 > To me, that's close to the antithesis of what LAMPS was setup to do. >=20 > If current PKI is going to be challenged by quantum computers then IMO = we ought re-think x.509-based PKI and not just consider all that an = issue to tackle via algorithm agility and whatever other ad-hoc hacks we = stumble upon. >=20 > x.509 is >30 years old as a container technology for public keys. = Pretty much everyone hates it or just about puts up with it. IMO we = ought not continue to use x.509 across such a classic/post-quantum = boundary - if we get anywhere near wanting multiple keys bound to an = identifier (and have >1 of those used for a single key establishment) = then I can't see how the costs of re-using x.509 would be worthwhile = compared to the costs of ditching x.509. >=20 > Such a re-think is definitely not a limited additional mechanism for = PKIX or S/MIME. >=20 > S. > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm From nobody Wed Aug 28 11:39:16 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C9AF120836 for ; Wed, 28 Aug 2019 11:39:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=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=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 8jlao5l01iK3 for ; Wed, 28 Aug 2019 11:39:06 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 1AB2D120091 for ; Wed, 28 Aug 2019 11:39:06 -0700 (PDT) Received: from pps.filterd (m0122333.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id x7SIbWaM024380; Wed, 28 Aug 2019 19:39:00 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=bzOi7IU+9EIaXewQlMCnGqCb+7uQ9UNJuhP8wyPnpU0=; b=KuVtkJ2g/OuOsLNGIvI0/m9dx8rZh3n/AoixPArm2SXiFtBg7L20c5phnyIaskWxnrCZ cmpE1I3ovRUubhBgDG1j/qx72F/YzDZTKwF1sHzOhYNCHN0s/OZ8sGQd8406HqSDcLU0 36EMwvIIpOA9O1Id0DbzU6GMn6rYP3c0rojWJ6hZE/InnmTwncfwK79vG0pxyE3XwkUV nZqOxogzwNRdncKaTY9sZRvV3fERAdnO+yogExfNqM3J5Di1Yo4/QpqJUOo57ohlZtm0 zuGWktjx6u8ue5NWgENjrz6/tTrJJlBFxJK5JaXkHhXJbRp9YIEByvBpbhZOvP8QXi/B dA== Received: from prod-mail-ppoint7 (prod-mail-ppoint7.akamai.com [96.6.114.121] (may be forged)) by mx0a-00190b01.pphosted.com with ESMTP id 2ujwcd907e-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 28 Aug 2019 19:39:00 +0100 Received: from pps.filterd (prod-mail-ppoint7.akamai.com [127.0.0.1]) by prod-mail-ppoint7.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x7SIWwvI012531; Wed, 28 Aug 2019 14:38:59 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint7.akamai.com with ESMTP id 2uk0jwmnyj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 28 Aug 2019 14:38:59 -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 Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 28 Aug 2019 14:38:57 -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.1473.005; Wed, 28 Aug 2019 14:38:57 -0400 From: "Salz, Rich" To: Russ Housley , Mike Ounsworth CC: "spasm@ietf.org" , Stephen Farrell Thread-Topic: [lamps] [EXTERNAL]Re: Re-charter text for LAMPS to work on Post-Quantum, and PQ problem statement Thread-Index: AQHVXQ2cBVJGrWPrg0GttrrFcdoACacRJ/sA//+9nYA= Date: Wed, 28 Aug 2019 18:38:57 +0000 Message-ID: References: <692ac76d-2501-40f1-0ea6-93309a1f2822@cs.tcd.ie> <30E31703-8C7F-49C8-ABB4-5FA061C67D97@vigilsec.com> In-Reply-To: <30E31703-8C7F-49C8-ABB4-5FA061C67D97@vigilsec.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1c.0.190812 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.32.203] Content-Type: text/plain; charset="utf-8" Content-ID: <6DBCAC5C554EFA4B8261036EE2594E0A@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-08-28_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=839 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1908280180 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.70,1.0.8 definitions=2019-08-28_09:2019-08-28,2019-08-28 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 adultscore=0 clxscore=1011 mlxlogscore=823 priorityscore=1501 bulkscore=0 suspectscore=0 malwarescore=0 spamscore=0 impostorscore=0 phishscore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1906280000 definitions=main-1908280181 Archived-At: Subject: Re: [lamps] [EXTERNAL]Re: Re-charter text for LAMPS to work on Post-Quantum, and PQ problem statement X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2019 18:39:15 -0000 PiAgICBJIHRoaW5rIHRoYXQgeW91IHNob3VsZCB0YWtlIHlvdXIgZHJhZnQgdG8gdGhlIFNFQ0RJ U1BBVENIIG1haWwgbGlzdCBhbmQgc2VlIGlmIHRoZXkgd2FudCB0byBwdXQgeW91IG9uIHRoZWly IGFnZW5kYSBvciBnbyBzdHJhaWdodCB0byBhIEJvRi4NCiAgDQorMQ0KDQoNCg== From nobody Thu Aug 29 07:48:35 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BBF41200C3 for ; Thu, 29 Aug 2019 07:48:33 -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, SPF_HELO_NONE=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 C09Ziyf1Jbgv for ; Thu, 29 Aug 2019 07:48:30 -0700 (PDT) Received: from mx1.entrustdatacard.com (mx1.entrustdatacard.com [204.124.80.220]) (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 46A3712010E for ; Thu, 29 Aug 2019 07:48:30 -0700 (PDT) IronPort-SDR: wqshACa2WtBk1vXnbJc8TftkSDM7U86scX/jPBBeQ2yXoE4xMkm89BN1jcG/ERTYu56gfz+Ra+ 0ysCNnJxS3QQ== X-IronPort-AV: E=Sophos;i="5.64,443,1559538000"; d="scan'208";a="55803287" Received: from pmspex03.corporate.datacard.com (HELO owa.entrustdatacard.com) ([192.168.211.50]) by pmspesa03inside.corporate.datacard.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA384; 29 Aug 2019 09:48:29 -0500 Received: from PMSPEX05.corporate.datacard.com (192.168.211.52) by PMSPEX03.corporate.datacard.com (192.168.211.50) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 29 Aug 2019 09:48:29 -0500 Received: from PMSPEX05.corporate.datacard.com ([fe80::8084:293e:7f03:4ab2]) by PMSPEX05.corporate.datacard.com ([fe80::8084:293e:7f03:4ab2%12]) with mapi id 15.00.1497.000; Thu, 29 Aug 2019 09:48:29 -0500 From: Mike Ounsworth To: "Salz, Rich" , Russ Housley CC: "spasm@ietf.org" , Stephen Farrell Thread-Topic: [lamps] [EXTERNAL]Re: Re-charter text for LAMPS to work on Post-Quantum, and PQ problem statement Thread-Index: AQHVXc+HyXmcSNn4DUOIES+1PCoiMacRN+aAgAD9+fA= Date: Thu, 29 Aug 2019 14:48:29 +0000 Message-ID: References: <692ac76d-2501-40f1-0ea6-93309a1f2822@cs.tcd.ie> <30E31703-8C7F-49C8-ABB4-5FA061C67D97@vigilsec.com> In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.4.210.25] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [lamps] [EXTERNAL]Re: Re-charter text for LAMPS to work on Post-Quantum, and PQ problem statement X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2019 14:48:33 -0000 VGhhbmtzLiBXZSB3aWxsIGJ1YmJsZSB0aGlzIG92ZXIgdG8gU0VDRElTUEFUQ0guIEkgYXBwcmVj aWF0ZSB0aGUgZ3VpZGFuY2UhDQoNCi0gLSAtDQpNaWtlIE91bnN3b3J0aCB8IE9mZmljZTogKzEg KDYxMykgMjcwLTI4NzMNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFNhbHos IFJpY2ggPHJzYWx6QGFrYW1haS5jb20+IA0KU2VudDogV2VkbmVzZGF5LCBBdWd1c3QgMjgsIDIw MTkgMjozOSBQTQ0KVG86IFJ1c3MgSG91c2xleSA8aG91c2xleUB2aWdpbHNlYy5jb20+OyBNaWtl IE91bnN3b3J0aCA8TWlrZS5PdW5zd29ydGhAZW50cnVzdGRhdGFjYXJkLmNvbT4NCkNjOiBzcGFz bUBpZXRmLm9yZzsgU3RlcGhlbiBGYXJyZWxsIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPg0K U3ViamVjdDogUmU6IFtsYW1wc10gW0VYVEVSTkFMXVJlOiBSZS1jaGFydGVyIHRleHQgZm9yIExB TVBTIHRvIHdvcmsgb24gUG9zdC1RdWFudHVtLCBhbmQgUFEgcHJvYmxlbSBzdGF0ZW1lbnQNCg0K PiAgICBJIHRoaW5rIHRoYXQgeW91IHNob3VsZCB0YWtlIHlvdXIgZHJhZnQgdG8gdGhlIFNFQ0RJ U1BBVENIIG1haWwgbGlzdCBhbmQgc2VlIGlmIHRoZXkgd2FudCB0byBwdXQgeW91IG9uIHRoZWly IGFnZW5kYSBvciBnbyBzdHJhaWdodCB0byBhIEJvRi4NCiAgDQorMQ0KDQoNCg==