From nobody Sat Jul 1 09:25:34 2017 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 762CF129482 for ; Sat, 1 Jul 2017 09:25:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0592g2Ii2Cz1 for ; Sat, 1 Jul 2017 09:25:31 -0700 (PDT) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) (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 46C231267BB for ; Sat, 1 Jul 2017 09:25:31 -0700 (PDT) Received: by mail-lf0-x234.google.com with SMTP id b207so84081921lfg.2 for ; Sat, 01 Jul 2017 09:25:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=oALwZAYZjeKv7F1c/oVN8c9htw5XW5XaMXJmHc7byoo=; b=LJzlE9WwxLRCh8uz9837tW5q+UBBUjjScLxaQyyyG1nJfs0eEbxWw73+L8Q4uLso2T 1jvdl7SAqNy/dwYUiw8crXfqqYvCtS1yUEfY2W+SEcl6h8Phb5MSBOro75wDc4R09EJH YPLaSW3o6X/a89C3x8QPs5aooU4+qtF1cvWUNMOix8S4fcgZp6s3RdKNXYmV5nhFMNtk h/A+7WXLZmE6YCcYZ58M/KOfvEhpXUrf6b3us+qdqlTjiOPyALbnED2x3v0sR2QerSAN voUb37MROrtiHytpqr5Td1lqGSrL33ge+tP3ZQBifMvARl6orWQElAgpNKFyuQ8gBBdZ f+Bg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=oALwZAYZjeKv7F1c/oVN8c9htw5XW5XaMXJmHc7byoo=; b=JcGd/tB8C8b9a3TCCosstgGEvrEza28RY4rthpVHWjlAqV1kxWzc0ANVZ+Z+oUChxb m2P1iXpfirswrS7I4STBzywSaqOQLD6evTIX+xVZz87plhzlgW+0rjBx+rGD+rpeQkvh 7haqfAQ3dEKXDPhGE/vfsTji5OBTLTwPGvhklk7cZtY+O4Oda4h9OVZ7M6CO5lnTN4gJ WT4H3wIopN8eTP/8a6GnvwtwKAPW/mPWV/F2idF5/nKQgNeCzN2fzLcCNGYQPwZgm9nW 59G7Rmk81p22k2INcwO51oSY9Gz+xbX7kJ5rLKR1Sixyt56iuV2D21lAtxQLmcQcI4tp hKjw== X-Gm-Message-State: AKS2vOzy7RzC8VWHMJNiLG7DQUnwIjQ+ZHKLtLo5wQ4uM2AN0ZzAkne2 vbj/yNE2Fb0FIFybG/vig6kSzZ5IOKnd X-Received: by 10.46.8.89 with SMTP id g25mr8335276ljd.18.1498926329447; Sat, 01 Jul 2017 09:25:29 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.25.181.214 with HTTP; Sat, 1 Jul 2017 09:25:28 -0700 (PDT) In-Reply-To: References: <6D0438F4-5C3B-4F28-A8FB-16B6CFA1C7CA@vigilsec.com> <7298935b-3b4d-4794-8f40-acb188690e87@cs.tcd.ie> From: Phillip Hallam-Baker Date: Sat, 1 Jul 2017 12:25:28 -0400 X-Google-Sender-Auth: Y2GVWm1v8CiyXoxIVntEYbz4QSY Message-ID: To: Ryan Sleevi Cc: LAMPS , Russ Housley , Stephen Farrell Content-Type: multipart/alternative; boundary="f403045f9f72694ac8055343fb01" Archived-At: Subject: Re: [lamps] Recharter Discussion X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 01 Jul 2017 16:25:33 -0000 --f403045f9f72694ac8055343fb01 Content-Type: text/plain; charset="UTF-8" I had already started a separated thread for discussion of the points Ryan raised. Since this is about rechartering, it does not seem the right place to discuss technology. As a matter of process, if he is going to trash talk about CAs, I am going to point out that those casting stones are not without sin. I see the First Issued extension as being useful in S/MIME and not just the Browser. Of course a Linked Notary Log is always going to give the most accurate source of truth, but only if you analyze it yourself. Otherwise you end up relying on a third party that is not a CA. Also, consulting external validation services has a cost, which is why browsers have been resistant to Hard Fail on OCSP. I see First Issued as an indicator that has the potential to be used for triage. While I would like browsers to check revocation information on every certificate, every time, that is not likely to happen soon. Offering the option of checking if the cert is less than 7 days old seems to be a control that would very likely be useful. If CAs get the indicator wrong, I am sure Rob's tool will point out the fact. That is how an accountability scheme works. The biggest problem with any security control in this space is whether it presents a real difficulty or if there is a simple countermeasure. Any change we make is inevitably an experiment. Of course we might end up implementing in CT. But that is a more complex proposition as all the rules for construction and validation are going to have to be worked out and fixed. A certificate extension is a simpler approach. Are people prepared to write drafts etc. explaining how to do this in CT and submit them to TRANS? If not, the possibility of doing the job a different way seems irrelevant. --f403045f9f72694ac8055343fb01 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I h= ad already started a separated thread for discussion of the points Ryan rai= sed. Since this is about rechartering, it does not seem the right place to = discuss technology.

As a = matter of process, if he is going to trash talk about CAs, I am going to po= int out that those casting stones are not without sin.=C2=A0


I see the First Issued extension as being useful = in S/MIME and not just the Browser.

Of course a Linked Notary Log is always going to give the most a= ccurate source of truth, but only if you analyze it yourself. Otherwise you= end up relying on a third party that is not a CA. Also, consulting externa= l validation services has a cost, which is why browsers have been resistant= to Hard Fail on OCSP.

I see First = Issued as an indicator that has the potential to be used for triage. While = I would like browsers to check revocation information on every certificate,= every time, that is not likely to happen soon. Offering the option of chec= king if the cert is less than 7 days old seems to be a control that would v= ery likely be useful.=C2=A0

If CAs get the indicator wrong, I am sure Rob's tool will point out = the fact. That is how an accountability scheme works.=C2=A0


The biggest problem with any security control in t= his space is whether it presents a real difficulty or if there is a simple = countermeasure. Any change we make is inevitably an experiment.

Of course we might end up impl= ementing in CT. But that is a more complex proposition as all the rules for= construction and validation are going to have to be worked out and fixed. = A certificate extension is a simpler approach.

Are people prepared to write drafts etc. explaining h= ow to do this in CT and submit them to TRANS? If not, the possibility of do= ing the job a different way seems irrelevant.=C2=A0
--f403045f9f72694ac8055343fb01-- From nobody Sat Jul 1 09:39:41 2017 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 61A3F129A96 for ; Sat, 1 Jul 2017 09:39:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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, RP_MATCHES_RCVD=-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=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 2N_uG5AU4i7p for ; Sat, 1 Jul 2017 09:39:37 -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 2737D1296CF for ; Sat, 1 Jul 2017 09:39:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 9BAD1BE58; Sat, 1 Jul 2017 17:39:34 +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 t1NVUZo_odJK; Sat, 1 Jul 2017 17:39:33 +0100 (IST) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 5235ABE56; Sat, 1 Jul 2017 17:39:32 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1498927173; bh=EUlGAHnHkKEDie8fNwH7uwaXKrJzrvO7u+ZNNCHtmf0=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=RBhOvzzpZjg7fNcPlf7nOBg3Po+r/8/kLy4V+ubS/gs4HV2hyZkXzGPmEwxCALcZU e+5DO5HBsNcWskxHj3vZWmLuqcDkUWiGVkJyWg4RalkdXmwSMmAGm+bF5v3UuLtWij r+w6x9FoIH7S4M22QWbB9ndr6cTwiEAifXwGWOfs= To: Phillip Hallam-Baker , Ryan Sleevi Cc: LAMPS , Russ Housley References: <6D0438F4-5C3B-4F28-A8FB-16B6CFA1C7CA@vigilsec.com> <7298935b-3b4d-4794-8f40-acb188690e87@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <517fd2fe-ccde-09f5-666f-25be27ef9087@cs.tcd.ie> Date: Sat, 1 Jul 2017 17:39:28 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="KBNPP5tkBCUnHQ2quCdi6ns0vR9bLrN6t" Archived-At: Subject: Re: [lamps] Recharter Discussion X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 01 Jul 2017 16:39:39 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --KBNPP5tkBCUnHQ2quCdi6ns0vR9bLrN6t Content-Type: multipart/mixed; boundary="AnNPNgjrkD8dcaiQPHMTNkAAPs4iFVeTS"; protected-headers="v1" From: Stephen Farrell To: Phillip Hallam-Baker , Ryan Sleevi Cc: LAMPS , Russ Housley Message-ID: <517fd2fe-ccde-09f5-666f-25be27ef9087@cs.tcd.ie> Subject: Re: [lamps] Recharter Discussion References: <6D0438F4-5C3B-4F28-A8FB-16B6CFA1C7CA@vigilsec.com> <7298935b-3b4d-4794-8f40-acb188690e87@cs.tcd.ie> In-Reply-To: --AnNPNgjrkD8dcaiQPHMTNkAAPs4iFVeTS Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable Hi Phill, On 01/07/17 17:25, Phillip Hallam-Baker wrote: > Of course we might end up implementing in CT. But that is a more comple= x > proposition as all the rules for construction and validation are going = to > have to be worked out and fixed. A certificate extension is a simpler > approach. I'm not clear what's missing given [1] - can you explain? Ta, S. [1] https://crt.sh/?q=3Ddown.dsg.cs.tcd.ie --AnNPNgjrkD8dcaiQPHMTNkAAPs4iFVeTS-- --KBNPP5tkBCUnHQ2quCdi6ns0vR9bLrN6t Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZV9BBAAoJEC88hzaAX42iGz0H/R+UFBfAC39toh6C2EwSb9it 4bqr/HnvS5TdgQMwyPSY5Q+dvWOxt++y9uZJD/3uq2GwHnuoEbQIQcx8Roy8y77F UP0crZNQFwwUsdyWdQ6AOP1TEBP3LIx4UcGeANEAva1XUpYvhFqeuVpJ4ienCFCw nZpIwsT+mJ6TCHrSLDOkZX6JAjU+sRjevA+yWblsmvHKu8O0WmNTqf/gC7SBBLqV AHvJ4eqUF1TG23sXFVaiQOyChTsBXsd/uHTMJCse/93KQIrh48SkATrO8L1sT9oQ G9hBsmvQzREUhGSfaJqi4dVnKWTWCJa7fgfV4CekQQpWsr5BI//Cno0PjHaBOX4= =AxYa -----END PGP SIGNATURE----- --KBNPP5tkBCUnHQ2quCdi6ns0vR9bLrN6t-- From nobody Sat Jul 1 09:55:11 2017 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 2AA6A1296CF for ; Sat, 1 Jul 2017 09:55:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 82sg3uL_SAWk for ; Sat, 1 Jul 2017 09:55:07 -0700 (PDT) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (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 76008129A96 for ; Sat, 1 Jul 2017 09:55:07 -0700 (PDT) Received: by mail-yw0-x22e.google.com with SMTP id 63so59210913ywr.0 for ; Sat, 01 Jul 2017 09:55:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=sK4QVc9+VbohyQ4Bc7nJuJGPc2k1d8QbQywQ+rgeXoY=; b=u1KnFlxCycfFwNWVJXTYYygFENKfAyyrDv53Va858y+robHvzSxV6e6znV7w9cSR1o fYbnHNESjH9WRRQ3TPvEEd9nkL0PLczPxpq7t+Wrmlt8bgl496cTyEtnpZJoL29ZBB70 +RpZ5kO+lfuMZb0Mp1nkDPqnW2Kehi7g3wr0WkDB4Vy6Djq/Q/avKogS9BR3LTHGq0lf fAEueZaL0ANjpdkyHyxpHxWq06GNceDWfWsnMqmvUzCoJ+UxaMfZz+Vx/zK9gHLrKTrY sYBBwGopd9fgVumiv+OnvQ9/y+CzurwIg6jmHIaVbLiwmuypOMFn+NI6O10OGyAnrdJY w7hA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=sK4QVc9+VbohyQ4Bc7nJuJGPc2k1d8QbQywQ+rgeXoY=; b=naiu4wP6c46mFIT6O9+RCaAY65ZnVuvxiSN21Bx6qxuCFlXpeYqbAqdfq7GaWylwIY LI72XyWJG5jzxlKt78z76d/Qimwxu0WEIwRKE/D1K4rM58CwHX06S25HGjFZ8SWiThE6 U+kLshGq7Aj65XnAahyZuiTxO8nugP8XLVqT3Nk8G+BGAAjag8OOE7gQVgkMT2eho4kw DcBXmIS8q5JyZvfgEAn2khDKhsWFdU+Ev8bH6JO1fR5ibCUf51ddUGwYZW9TK33HdxSv hRPEtf+IhB7McpcdG4X5UFQL+GKxj3ik4MEPC9LWbpp0jI21bq69n6+i6a/x+n0Ca1Cv NjFg== X-Gm-Message-State: AKS2vOxYE/Qt0TNVw57GKlSOVyfAJu4GuoReEuZ6VpFUtjlk3uIS0zPo uFC+qdqyFbhM2BFigvObXYSLTNVCMJmXwOE= X-Received: by 10.129.71.213 with SMTP id u204mr21290701ywa.270.1498928106544; Sat, 01 Jul 2017 09:55:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.215.9 with HTTP; Sat, 1 Jul 2017 09:54:26 -0700 (PDT) In-Reply-To: References: <6D0438F4-5C3B-4F28-A8FB-16B6CFA1C7CA@vigilsec.com> <7298935b-3b4d-4794-8f40-acb188690e87@cs.tcd.ie> From: Eric Rescorla Date: Sat, 1 Jul 2017 09:54:26 -0700 Message-ID: To: Phillip Hallam-Baker Cc: Ryan Sleevi , LAMPS , Russ Housley , Stephen Farrell Content-Type: multipart/alternative; boundary="001a114c6ec055ee8e055344650d" Archived-At: Subject: Re: [lamps] Recharter Discussion X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 01 Jul 2017 16:55:10 -0000 --001a114c6ec055ee8e055344650d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Jun 30, 2017 at 9:58 PM, Phillip Hallam-Baker wrote: > =E2=80=8BSince Comodo distributes a browser, at least one browser is inte= rested. > It seems like this indicator (and in fact any indicator which disfavors recently issued certificates) pushes in the opposite direction from design decisions we have made elsewhere which attempt to favor rapid certificate issuance. To take a concrete case, much of the structure of CT is designed around the premise that certificates need to be immediately usable. Were that not so, you could abandon SCTs entirely and simply have certificates contain inclusion proofs, which would obviously be simpler. So, having a system which was designed to make recently issued certificates not work seems to be opposed to the approach we have been taking so far. Speaking from the perspective of a Firefox implementor, I don't really see how we would make use of this information in our certificate trust decision. We're actually trying to get away from making fine discriminations between different types of certificates because it's so hard for the user to make informed decisions, which means that the only thing we'd really be able to do is refuse the certificate, which I doubt we would do. -Ekr Given that you seem entirely unconcerned by 16,000 fake paypal sites a > certain CA has issued certs for, it is not surprising that you see no > reason to make any changes. > > > > On Sat, Jul 1, 2017 at 12:14 AM, Ryan Sleevi wrote= : > >> >> On Fri, Jun 30, 2017 at 9:27 AM Phillip Hallam-Baker < >> phill@hallambaker.com> wrote: >> >>> On Fri, Jun 30, 2017 at 10:22 AM, Stephen Farrell < >>> stephen.farrell@cs.tcd.ie> wrote: >>> >>>> >>>> Hi Phill, >>>> >>>> On 29/06/17 17:54, Phillip Hallam-Baker wrote: >>>> > On Thu, Jun 29, 2017 at 12:47 PM, Stephen Farrell < >>>> stephen.farrell@cs.tcd.ie >>>> >> wrote: >>>> > >>>> >> >>>> >> >>>> >> On 29/06/17 16:21, Russ Housley wrote: >>>> >>> Do others have an opinion? >>>> >> >>>> >> The function sounds useful but perhaps better provided >>>> >> via an API to a CT log (not sure). The reason I'd wonder >>>> >> about that is that it's hard to see what code would >>>> >> read this new value and not want more information than >>>> >> that. A CT log API could provide more so might be more >>>> >> useful (e.g. if an RP could ask "show me your history of >>>> >> meta-data related to certs for example.com"). >>>> >> >>>> >> Probably not that relevant, but similar information would >>>> >> also exist in passive DNS DBs I guess. >>>> >> >>>> > >>>> > =E2=80=8BThere is always a cut off between the standardized parts an= d the >>>> rest. >>>> > >>>> > When I first proposed this, it was for human consumption. What I am >>>> > thinking about now is rather more of a hook for likely proprietary A= I >>>> > systems reading it.=E2=80=8B >>>> >>>> Right, that's why a CT API seems maybe more useful and (I think, >>>> but I may be wrong), might be easier to get deployed. >>>> >>>> > >>>> > =E2=80=8BSecurity is risk mitigation, not risk elimination. Right no= w we can >>>> > eliminate what? 95% of phishing sites with free DV certs by simply >>>> > rejecting any certs less than 5 days old. =E2=80=8B >>> >>> >> Who is we? >> >> Is this a statement of what you believe browsers should do, versus will? >> Have you heard of or can provide evidence for any expression of support, >> from any browser, for this philosophy? >> >> >>>> > >>>> > >>>> > =E2=80=8BWhat we do next with the =E2=80=8Bdata is going to be impor= tant. But not >>>> something >>>> > we are going to be able to really work on at all, let alone >>>> standardize >>>> > until after we have data. >>>> > >>>> > All I want to do right now is to instrument so we can start >>>> collecting data. >>>> > >>>> >>>> I'm not opposed to defining such a cert extension (which I >>>> assume would be the end result) if there's likely to be >>>> deployment. But I still think that given that CT logs will >>>> have this info already, (and more, and covering >1 issuer) >>>> a new CT API may be better than putting it in certs. >>>> >>> >>> =E2=80=8BI don't really want to push everything into CT. This is not in= formation >>> that is going to be immediately available, you would have to do a lot o= f >>> log crunching to validate. >>> >>> Given that some browsers won't do CRLs or OCSP, I can't see them using >>> CT for pro-active checking before they accept the connection. Where I s= ee >>> the value of First Issued is to allow browsers to winnow out certs that= are >>> most likely OK and concentrate checking on those that might be a bit do= dgy. >>> >> >> Are you aware of any browsers interested in this? This feels very much >> like LogoType - which was intended for browsers (among others) and >> rightfully not widely implemented. >> >> >>> At any rate, putting an extension into the cert is pretty simple while >>> changing the CT API to support short lived certs is likely to be a >>> performance. I think that this is an easy win to get much of the return= and >>> takes the pressure off the CT end of things. >>> >> >> CT already has to deal with this. It does seem you're conflating two >> unrelated things though, but perhaps I'm misunderstanding. >> >> Perhaps it could be useful if you could explain what you believe the >> browser security model to be, and how this supports what browsers are do= ing >> or have expressed support for. >> >> I do not see any value to this as an extension - and I can see >> undesirable (and unreliable) data being added by CAs - so I'm curious to >> understand why using CT is insufficient, especially for the proposed >> browser-run machine learning reputation determination. >> > > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm > > --001a114c6ec055ee8e055344650d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On F= ri, Jun 30, 2017 at 9:58 PM, Phillip Hallam-Baker <phill@hallambaker.c= om> wrote:
=E2=80=8BSince Comodo di= stributes a browser, at least one browser is interested.

It seems like this indicator (and in fact any ind= icator which disfavors recently issued
certificates) pushes i= n the opposite direction from design decisions we have made
elsew= here which attempt to favor rapid certificate issuance. To take a concrete = case,
much of the structure of CT is designed around the premise = that certificates need
to be immediately usable. Were that not so= , you could abandon SCTs entirely and
simply have certificates co= ntain inclusion proofs, which would obviously be simpler.
So, hav= ing a system which was designed to make recently issued certificates not
work seems to be opposed to the approach we have been taking so far= .

Speaking from the perspective of a Firefox imple= mentor, I don't really see how we would
make use of this info= rmation in our certificate trust decision. We're actually trying to
get away from making fine discriminations between different types of= certificates because
it's so hard for the user to make infor= med decisions, which means that the only thing
we'd really be= able to do is refuse the certificate, which I doubt we would do.

-Ekr





Given that you seem entire= ly unconcerned by 16,000 fake paypal sites a certain CA has issued certs fo= r, it is not surprising that you see no reason to make any changes.


<= /div>

On Sat, Jul 1, 2017 at 12:14 AM, Ryan Sleevi <ryan-iet= f@sleevi.com> wrote:

On Fri, Jun= 30, 2017 at 9:27 AM Phillip Hallam-Baker <phill@hallambaker.com> wrote:
On Fri, Jun 30, 2017 at 10:22 AM, Stephe= n Farrell <stephen.farrell@cs.tcd.ie> wrote:

Hi Phill,

On 29/06/17 17:54, Phillip Hallam-Baker wrote:
> On Thu, Jun 29, 2017 at 12:47 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie
>> wrote:
>
>>
>>
>> On 29/06/17 16:21, Russ Housley wrote:
>>> Do others have an opinion?
>>
>> The function sounds useful but perhaps better provided
>> via an API to a CT log (not sure). The reason I'd wonder
>> about that is that it's hard to see what code would
>> read this new value and not want more information than
>> that. A CT log API could provide more so might be more
>> useful (e.g. if an RP could ask "show me your history of
>> meta-data related to certs for example.com").
>>
>> Probably not that relevant, but similar information would
>> also exist in passive DNS DBs I guess.
>>
>
> =E2=80=8BThere is always a cut off between the standardized parts and = the rest.
>
> When I first proposed this, it was for human consumption. What I am > thinking about now is rather more of a hook for likely proprietary AI<= br> > systems reading it.=E2=80=8B

Right, that's why a CT API seems maybe more useful and (I think,=
but I may be wrong), might be easier to get deployed.

>
> =E2=80=8BSecurity is risk mitigation, not risk elimination. Right now = we can
> eliminate what? 95% of phishing sites with free DV certs by simply
> rejecting any certs less than 5 days old. =E2=80=8B

Who is we?

Is this a statement of what you believe browsers should do, versus will? = Have you heard of or can provide evidence for any expression of support, fr= om any browser, for this philosophy?


>
>
> =E2=80=8BWhat we do next with the =E2=80=8Bdata is going to be importa= nt. But not something
> we are going to be able to really work on at all, let alone standardiz= e
> until after we have data.
>
> All I want to do right now is to instrument so we can start collecting= data.
>

I'm not opposed to defining such a cert extension (which I
assume would be the end result) if there's likely to be
deployment. But I still think that given that CT logs will
have this info already, (and more, and covering >1 issuer)
a new CT API may be better than putting it in certs.
<= br>
=E2=80=8BI don't really = want to push everything into CT. This is not information that is going to b= e immediately available, you would have to do a lot of log crunching to val= idate.=C2=A0

Given that some browsers won't do CRLs or OCSP, I can= 9;t see them using CT for pro-active checking before they accept the connec= tion. Where I see the value of First Issued is to allow browsers to winnow = out certs that are most likely OK and concentrate checking on those that mi= ght be a bit dodgy.

Are you aware of any browsers inter= ested in this? This feels very much like LogoType - which was intended for = browsers (among others) and rightfully not widely implemented.
<= div dir=3D"auto">

At any rate, putting an extension into the cert is= pretty simple while changing the CT API to support short lived certs is li= kely to be a performance. I think that this is an easy win to get much of t= he return and takes the pressure off the CT end of things.=C2=A0

CT already has to deal with this. It does seem you're conflat= ing two unrelated things though, but perhaps I'm misunderstanding.

Perhaps it could be useful i= f you could explain what you believe the browser security model to be, and = how this supports what browsers are doing or have expressed support for.

I do not see a= ny value to this as an extension - and I can see undesirable (and unreliabl= e) data being added by CAs - so I'm curious to understand why using CT = is insufficient, especially for the proposed browser-run machine learning r= eputation determination.


_______________________________________________
Spasm mailing list
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm


--001a114c6ec055ee8e055344650d-- From nobody Sat Jul 1 11:08:16 2017 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 C93241201F8 for ; Sat, 1 Jul 2017 11:08:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=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=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XI2szn20gYWo for ; Sat, 1 Jul 2017 11:08:10 -0700 (PDT) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (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 36F571274D0 for ; Sat, 1 Jul 2017 11:08:10 -0700 (PDT) Received: by mail-lf0-x230.google.com with SMTP id b207so84703979lfg.2 for ; Sat, 01 Jul 2017 11:08:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=1r4rbbLh6vmqFMad8Mlw9DJogBtLLGNgSPKd6CjIrV4=; b=oF0eLnZcuHumYzmCn4c7qM/W3VRuA0TG6/m5L7/9M++lLYrpXqLcnodtczZTsVB710 CxlGARAfFDA1szuEeAaqgfqzgt3qfgS/TcBeDV51hvFA4aZAfnh0V6RqzSYPI7iQaSAT 5Jg3VD/iyTfy4FN5vTPe1kceWaOBtwbbaNy0PoY2tKsUFJmwu6POIc6jhjDNraYFgoqy XVw4b/Odu7y/MZ7vHmmSRbx6mCR8zRsc92xmtU/m4IS5CRG3f7E6uoCZZn9QYcvwZ6lX jCL6LtAqEXqxbOcLwWao8tZyL9E03c1ted9mvl+b4Q/KsfJK26Hwkq8MRECO+en698YD kN0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=1r4rbbLh6vmqFMad8Mlw9DJogBtLLGNgSPKd6CjIrV4=; b=He7XuFbeIg+9qQ4nFUDnrlNbWns985Xw6u8Ggw0TNPvDxVfDrUdbJ+V9+BAJA+85p1 HexFLuaT8RXiNuX6Xc6RPqzKWOamrGg2Vf9OXvVCYDZZW2/CDrfllaKNVWJVHzBNL2sW Xs+V331t7TcYwouXtNmBAXfNQhUc6w5dTFhTgCdXQrzE50LIAZvp4LgE8HMhdcaLlAIH EmzyY19gK3HIaeCCdjEBRgJryKOhOeVPoRkXxgvLb7BZHG97W2E5LbDDXvhu43LVFyYY uJ+1pBymNGnMbKEDgyIiM18N6G3VR9+a12OJlULhcB6MoBQF+mpzdFztgMV0wDwR6ENQ b+0g== X-Gm-Message-State: AKS2vOwVG07BQEMghSlrJktVUe5LQVekt2lRYkjbfN+nhJK6af9nKUp0 cvSc9Q3pB5HTb0YRR/ZgcqfVHSPK4g== X-Received: by 10.46.82.199 with SMTP id n68mr7026588lje.99.1498932488412; Sat, 01 Jul 2017 11:08:08 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.25.181.214 with HTTP; Sat, 1 Jul 2017 11:08:07 -0700 (PDT) In-Reply-To: References: <6D0438F4-5C3B-4F28-A8FB-16B6CFA1C7CA@vigilsec.com> <7298935b-3b4d-4794-8f40-acb188690e87@cs.tcd.ie> From: Phillip Hallam-Baker Date: Sat, 1 Jul 2017 14:08:07 -0400 X-Google-Sender-Auth: Lrtz4u5CzVXcvyxxbC2aJDdTr54 Message-ID: To: Eric Rescorla Cc: Ryan Sleevi , LAMPS , Russ Housley , Stephen Farrell Content-Type: multipart/alternative; boundary="001a113be37283a2f90553456ac6" Archived-At: Subject: Re: [lamps] Recharter Discussion X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 01 Jul 2017 18:08:14 -0000 --001a113be37283a2f90553456ac6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I agree it is a bad idea for the user to be making distinctions. What I am trying to do is to surface enough information for an AI to be able to make a reasonable decision. I also agree on the need for a rapid admin cycle, but that is not the same as getting a site into production rapidly and start accepting credit cards from the general public, do online banking, etc. The problem I see the SCT scheme in CT addressing is to prevent the delays in various parts of the system compounding so that 24 hours here, 48 hours there, etc. ends up adding up to months. The behavior I see right now is 1) Browser encounters certificate 2) Browser tells user that they are 'secure' 3) Browser performs validity checking via OCSP, CT, etc. to see if (2) was actually true. Now given that modern web pages are composite with content coming from dozens of sources, even for relatively simple cases, the overhead for doing validation is significant. And that is only going to get worse as the web moves to 100% encrypted. The problem is that encryption is not enough. Its like saying that the armored truck you just handed the cash box containing $50K is secure because it really properly armor plated, ignoring the fact that it is being driven by the bank robbers. Authentication also matters. What I am proposing as an option is: 1) Browser encounters certificate 2) Browser looks at First issued, other indications If certificate is recent, Browser performs validity checking via OCSP, CT, etc. *before* telling the user they are 'Secure'. Of course, not telling the user they are 'Secure' on the basis of a weakly validated certificate would be a another way to address the problem, maybe, Having the information inside the cert means that you have the option to use it for triage. On Sat, Jul 1, 2017 at 12:54 PM, Eric Rescorla wrote: > On Fri, Jun 30, 2017 at 9:58 PM, Phillip Hallam-Baker < > phill@hallambaker.com> wrote: > >> =E2=80=8BSince Comodo distributes a browser, at least one browser is int= erested. >> > > It seems like this indicator (and in fact any indicator which disfavors > recently issued > certificates) pushes in the opposite direction from design decisions we > have made > elsewhere which attempt to favor rapid certificate issuance. To take a > concrete case, > much of the structure of CT is designed around the premise that > certificates need > to be immediately usable. Were that not so, you could abandon SCTs > entirely and > simply have certificates contain inclusion proofs, which would obviously > be simpler. > So, having a system which was designed to make recently issued > certificates not > work seems to be opposed to the approach we have been taking so far. > > Speaking from the perspective of a Firefox implementor, I don't really se= e > how we would > make use of this information in our certificate trust decision. We're > actually trying to > get away from making fine discriminations between different types of > certificates because > it's so hard for the user to make informed decisions, which means that th= e > only thing > we'd really be able to do is refuse the certificate, which I doubt we > would do. > > -Ekr > > > > > > Given that you seem entirely unconcerned by 16,000 fake paypal sites a >> certain CA has issued certs for, it is not surprising that you see no >> reason to make any changes. >> >> >> >> On Sat, Jul 1, 2017 at 12:14 AM, Ryan Sleevi >> wrote: >> >>> >>> On Fri, Jun 30, 2017 at 9:27 AM Phillip Hallam-Baker < >>> phill@hallambaker.com> wrote: >>> >>>> On Fri, Jun 30, 2017 at 10:22 AM, Stephen Farrell < >>>> stephen.farrell@cs.tcd.ie> wrote: >>>> >>>>> >>>>> Hi Phill, >>>>> >>>>> On 29/06/17 17:54, Phillip Hallam-Baker wrote: >>>>> > On Thu, Jun 29, 2017 at 12:47 PM, Stephen Farrell < >>>>> stephen.farrell@cs.tcd.ie >>>>> >> wrote: >>>>> > >>>>> >> >>>>> >> >>>>> >> On 29/06/17 16:21, Russ Housley wrote: >>>>> >>> Do others have an opinion? >>>>> >> >>>>> >> The function sounds useful but perhaps better provided >>>>> >> via an API to a CT log (not sure). The reason I'd wonder >>>>> >> about that is that it's hard to see what code would >>>>> >> read this new value and not want more information than >>>>> >> that. A CT log API could provide more so might be more >>>>> >> useful (e.g. if an RP could ask "show me your history of >>>>> >> meta-data related to certs for example.com"). >>>>> >> >>>>> >> Probably not that relevant, but similar information would >>>>> >> also exist in passive DNS DBs I guess. >>>>> >> >>>>> > >>>>> > =E2=80=8BThere is always a cut off between the standardized parts a= nd the >>>>> rest. >>>>> > >>>>> > When I first proposed this, it was for human consumption. What I am >>>>> > thinking about now is rather more of a hook for likely proprietary = AI >>>>> > systems reading it.=E2=80=8B >>>>> >>>>> Right, that's why a CT API seems maybe more useful and (I think, >>>>> but I may be wrong), might be easier to get deployed. >>>>> >>>>> > >>>>> > =E2=80=8BSecurity is risk mitigation, not risk elimination. Right n= ow we can >>>>> > eliminate what? 95% of phishing sites with free DV certs by simply >>>>> > rejecting any certs less than 5 days old. =E2=80=8B >>>> >>>> >>> Who is we? >>> >>> Is this a statement of what you believe browsers should do, versus will= ? >>> Have you heard of or can provide evidence for any expression of support= , >>> from any browser, for this philosophy? >>> >>> >>>>> > >>>>> > >>>>> > =E2=80=8BWhat we do next with the =E2=80=8Bdata is going to be impo= rtant. But not >>>>> something >>>>> > we are going to be able to really work on at all, let alone >>>>> standardize >>>>> > until after we have data. >>>>> > >>>>> > All I want to do right now is to instrument so we can start >>>>> collecting data. >>>>> > >>>>> >>>>> I'm not opposed to defining such a cert extension (which I >>>>> assume would be the end result) if there's likely to be >>>>> deployment. But I still think that given that CT logs will >>>>> have this info already, (and more, and covering >1 issuer) >>>>> a new CT API may be better than putting it in certs. >>>>> >>>> >>>> =E2=80=8BI don't really want to push everything into CT. This is not >>>> information that is going to be immediately available, you would have = to do >>>> a lot of log crunching to validate. >>>> >>>> Given that some browsers won't do CRLs or OCSP, I can't see them using >>>> CT for pro-active checking before they accept the connection. Where I = see >>>> the value of First Issued is to allow browsers to winnow out certs tha= t are >>>> most likely OK and concentrate checking on those that might be a bit d= odgy. >>>> >>> >>> Are you aware of any browsers interested in this? This feels very much >>> like LogoType - which was intended for browsers (among others) and >>> rightfully not widely implemented. >>> >>> >>>> At any rate, putting an extension into the cert is pretty simple while >>>> changing the CT API to support short lived certs is likely to be a >>>> performance. I think that this is an easy win to get much of the retur= n and >>>> takes the pressure off the CT end of things. >>>> >>> >>> CT already has to deal with this. It does seem you're conflating two >>> unrelated things though, but perhaps I'm misunderstanding. >>> >>> Perhaps it could be useful if you could explain what you believe the >>> browser security model to be, and how this supports what browsers are d= oing >>> or have expressed support for. >>> >>> I do not see any value to this as an extension - and I can see >>> undesirable (and unreliable) data being added by CAs - so I'm curious t= o >>> understand why using CT is insufficient, especially for the proposed >>> browser-run machine learning reputation determination. >>> >> >> >> _______________________________________________ >> Spasm mailing list >> Spasm@ietf.org >> https://www.ietf.org/mailman/listinfo/spasm >> >> > --001a113be37283a2f90553456ac6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I a= gree it is a bad idea for the user to be making distinctions. What I am try= ing to do is to surface enough information for an AI to be able to make a r= easonable decision.=C2=A0

I also agree on the need for a rapid admin cycle, but that is not the same= as getting a site into production rapidly and start accepting credit cards= from the general public, do online banking, etc.

The problem I see the SCT scheme in CT addressing = is to prevent the delays in various parts of the system compounding so that= 24 hours here, 48 hours there, etc. ends up adding up to months.

The behavior I see right now is

1) Browser encounters certi= ficate
2) Brows= er tells user that they are 'secure'
3) Browser performs validity checking via OCS= P, CT, etc. to see if (2) was actually true.

Now given that modern web pages are composite with con= tent coming from dozens of sources, even for relatively simple cases, the o= verhead for doing validation is significant. And that is only going to get = worse as the web moves to 100% encrypted.

The problem is that encryption is not enough. Its like say= ing that the armored truck you just handed the cash box containing $50K is = secure because it really properly armor plated, ignoring the fact that it i= s being driven by the bank robbers. Authentication also matters.=C2=A0


What I am proposing as an option is:

1) Browser encounters certificate
2) Br= owser looks at First issued, other indications
=C2=A0 =C2=A0 If certificate is recent, Browser performs validity che= cking via OCSP, CT, etc. *before* telling the user they are 'Secure'= ;.

Of course, not telling the user they are 'Secure' on the basis of = a weakly validated certificate would be a another way to address the proble= m, maybe,

Having th= e information inside the cert means that you have the option to use it for = triage.


On Sat, = Jul 1, 2017 at 12:54 PM, Eric Rescorla <ekr@rtfm.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
<= div class=3D"gmail_quote">On Fri, Jun 30, 2017 at 9:58 PM,= Phillip Hallam-Baker <phill@hallambaker.com> wrote:
=
=E2=80=8BSince Comodo distributes a browser, at leas= t one browser is interested.

=
It seems like this indicator (and in fact any indicator which disfavor= s recently issued
certificates) pushes in the opposite direct= ion from design decisions we have made
elsewhere which attempt to= favor rapid certificate issuance. To take a concrete case,
much = of the structure of CT is designed around the premise that certificates nee= d
to be immediately usable. Were that not so, you could abandon S= CTs entirely and
simply have certificates contain inclusion proof= s, which would obviously be simpler.
So, having a system which wa= s designed to make recently issued certificates not
work seems to= be opposed to the approach we have been taking so far.

Speaking from the perspective of a Firefox implementor, I don't r= eally see how we would
make use of this information in our certif= icate trust decision. We're actually trying to
get away from = making fine discriminations between different types of certificates because=
it's so hard for the user to make informed decisions, which = means that the only thing
we'd really be able to do is refuse= the certificate, which I doubt we would do.

-Ekr<= /div>





<= /div>
Given that you seem enti= rely unconcerned by 16,000 fake paypal sites a certain CA has issued certs = for, it is not surprising that you see no reason to make any changes.
=


On Sat, Jul 1, 2= 017 at 12:14 AM, Ryan Sleevi <ryan-ietf@sleevi.com> wrote= :

On Fri, Jun 30, 2017 a= t 9:27 AM Phillip Hallam-Baker <phill@hallambaker.com> wrote:
On Fri, Jun 30, 2017 at 10:22 AM, Stephen Farrell <= span><ste= phen.farrell@cs.tcd.ie> wrote:

Hi Phill,

On 29/06/17 17:54, Phillip Hallam-Baker wrote:
> On Thu, Jun 29, 2017 at 12:47 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie
>> wrote:
>
>>
>>
>> On 29/06/17 16:21, Russ Housley wrote:
>>> Do others have an opinion?
>>
>> The function sounds useful but perhaps better provided
>> via an API to a CT log (not sure). The reason I'd wonder
>> about that is that it's hard to see what code would
>> read this new value and not want more information than
>> that. A CT log API could provide more so might be more
>> useful (e.g. if an RP could ask "show me your history of
>> meta-data related to certs for example.com").
>>
>> Probably not that relevant, but similar information would
>> also exist in passive DNS DBs I guess.
>>
>
> =E2=80=8BThere is always a cut off between the standardized parts and = the rest.
>
> When I first proposed this, it was for human consumption. What I am > thinking about now is rather more of a hook for likely proprietary AI<= br> > systems reading it.=E2=80=8B

Right, that's why a CT API seems maybe more useful and (I think,=
but I may be wrong), might be easier to get deployed.

>
> =E2=80=8BSecurity is risk mitigation, not risk elimination. Right now = we can
> eliminate what? 95% of phishing sites with free DV certs by simply
> rejecting any certs less than 5 days old. =E2=80=8B

Who is we?

Is this a statement of what you believe browsers should do, versus will? = Have you heard of or can provide evidence for any expression of support, fr= om any browser, for this philosophy?


>
>
> =E2=80=8BWhat we do next with the =E2=80=8Bdata is going to be importa= nt. But not something
> we are going to be able to really work on at all, let alone standardiz= e
> until after we have data.
>
> All I want to do right now is to instrument so we can start collecting= data.
>

I'm not opposed to defining such a cert extension (which I
assume would be the end result) if there's likely to be
deployment. But I still think that given that CT logs will
have this info already, (and more, and covering >1 issuer)
a new CT API may be better than putting it in certs.
<= br>
=E2=80=8BI don't really = want to push everything into CT. This is not information that is going to b= e immediately available, you would have to do a lot of log crunching to val= idate.=C2=A0

Given that some browsers won't do CRLs or OCSP, I can= 9;t see them using CT for pro-active checking before they accept the connec= tion. Where I see the value of First Issued is to allow browsers to winnow = out certs that are most likely OK and concentrate checking on those that mi= ght be a bit dodgy.

Are you aware of any browsers inter= ested in this? This feels very much like LogoType - which was intended for = browsers (among others) and rightfully not widely implemented.
<= div dir=3D"auto">

At any rate, putting an extension into the cert is= pretty simple while changing the CT API to support short lived certs is li= kely to be a performance. I think that this is an easy win to get much of t= he return and takes the pressure off the CT end of things.=C2=A0

CT already has to deal with this. It does seem you're conflat= ing two unrelated things though, but perhaps I'm misunderstanding.

Perhaps it could be useful i= f you could explain what you believe the browser security model to be, and = how this supports what browsers are doing or have expressed support for.

I do not see a= ny value to this as an extension - and I can see undesirable (and unreliabl= e) data being added by CAs - so I'm curious to understand why using CT = is insufficient, especially for the proposed browser-run machine learning r= eputation determination.


______________________________= _________________
Spasm mailing list
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm



--001a113be37283a2f90553456ac6-- From nobody Sat Jul 1 11:12:28 2017 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 04E69120454 for ; Sat, 1 Jul 2017 11:12:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=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=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7nF3Wuh2nutW for ; Sat, 1 Jul 2017 11:12:25 -0700 (PDT) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36A991201F8 for ; Sat, 1 Jul 2017 11:12:25 -0700 (PDT) Received: by mail-lf0-x236.google.com with SMTP id b207so84728712lfg.2 for ; Sat, 01 Jul 2017 11:12:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=RyY84JSEgF13yurEgHsdJSdBn7Hm1pB+rkFYMGqU8zM=; b=YwSlS8UxqOX8DdLNIuRU2J2wNh76r9fK5VoZwMToP0A+vUfj8+W3zHqRUtzvjdFPno wblIIo/46rMTV1ueHveIrTe8z4tKW3Jp2+YMZSCzIAydBGkgJf8ZMqHBgdlOh8xnasLE UcSnyQSM2/rsxAoeKEcePaxaAA7YEnn0hDqBbPq82B4bOl2IfFOxU8DdMdzaLOM8SWJy FGUzA2NTzKgYTSvQDPR2HPjNApqqay/PRNu8cNBL0/HCDR8ldD1NnoyNzo/hg+M1e4ik Lkg+BAdBfMhsn5oTtUh5QXz9grZfzvjbLDhbSgxODnZwQB0xqwHrKSMWYRjaASzluHcV U/jQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=RyY84JSEgF13yurEgHsdJSdBn7Hm1pB+rkFYMGqU8zM=; b=Kginr6xh5+cleNGsPE7QRb7xWAKHB3lLiiPe8xLPJUgBeKogdKH1n+kl1xQq/dYSVI BhCCNyzJqrjnPtsI0Msjln4nLBdPV+AQEx5Yf2QQB2A+hyBE9lYivqJ+ggb0ul4+NURd qVkNYxuYUX9eWFF8Wte+0IGbVcxdDybQaR3VeWtYr3iTpJEEixrDFYXBpqDhYKfASh+t IClBORvUJrv2CyH0mG2BVUNDDGfgUeiFXHTtlEx9hBMtJjRm9rZwA/3fN35gVFrLaZeA VUrWZgxUDsVMO+YUlpCbGJoEAUDTseZZ8KfoxZg6CiwGE/+Uxwq0PDR30a/3yhLZ5Rkk Z9UA== X-Gm-Message-State: AKS2vOwZOQMmZSAqC/mok5HltznaJrvMcK+bq24ITd05G0cgX5GswBQ+ XTG6XgP8NLf1Pn5X/VJYuobDwip1YQ== X-Received: by 10.25.221.206 with SMTP id w75mr8970316lfi.5.1498932743479; Sat, 01 Jul 2017 11:12:23 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.25.181.214 with HTTP; Sat, 1 Jul 2017 11:12:22 -0700 (PDT) In-Reply-To: <517fd2fe-ccde-09f5-666f-25be27ef9087@cs.tcd.ie> References: <6D0438F4-5C3B-4F28-A8FB-16B6CFA1C7CA@vigilsec.com> <7298935b-3b4d-4794-8f40-acb188690e87@cs.tcd.ie> <517fd2fe-ccde-09f5-666f-25be27ef9087@cs.tcd.ie> From: Phillip Hallam-Baker Date: Sat, 1 Jul 2017 14:12:22 -0400 X-Google-Sender-Auth: A5XXCVJgeo9nt5VPg_vFmR5kjkI Message-ID: To: Stephen Farrell Cc: Ryan Sleevi , LAMPS , Russ Housley Content-Type: multipart/alternative; boundary="f40304360a02b7a8c90553457956" Archived-At: Subject: Re: [lamps] Recharter Discussion X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 01 Jul 2017 18:12:27 -0000 --f40304360a02b7a8c90553457956 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Jul 1, 2017 at 12:39 PM, Stephen Farrell wrote: > > Hi Phill, > > On 01/07/17 17:25, Phillip Hallam-Baker wrote: > > Of course we might end up implementing in CT. But that is a more comple= x > > proposition as all the rules for construction and validation are going = to > > have to be worked out and fixed. A certificate extension is a simpler > > approach. > > I'm not clear what's missing given [1] - can you explain? > > Ta, > S. > > [1] https://crt.sh/?q=3Ddown.dsg.cs.tcd.ie 1) =E2=80=8BThe information exists in the certificate system if you know ho= w to look for it. That is not the same as the information being there in a form that a robot can look for. 2) The information is not in the place where the decision to accept the certificate as it is or to proceed without additional scrutiny is made. --f40304360a02b7a8c90553457956 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Sat, Ju= l 1, 2017 at 12:39 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie<= /a>> wrote:

Hi Phill,

On 01/07/17 17:25, Phillip Hallam-Baker wrote:
> Of course we might end up implementing in CT. But that is a more compl= ex
> proposition as all the rules for construction and validation are going= to
> have to be worked out and fixed. A certificate extension is a simpler<= br> > approach.

I'm not clear what's missing given [1] - can you explain?
Ta,
S.

[1] https://crt.sh/?q=3Ddown.dsg.cs.tcd.ie

1) =E2=80=8BThe information exists in the certificate system if you know = how to look for it. That is not the same as the information being there in = a form that a robot can look for.=C2=A0

2) The information is not in the place where the decision to= accept the certificate as it is or to proceed without additional scrutiny = is made.




= =C2=A0
--f40304360a02b7a8c90553457956-- From nobody Sat Jul 1 11:45:51 2017 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 B4C68120454 for ; Sat, 1 Jul 2017 11:45:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z1E9DsRowUNt for ; Sat, 1 Jul 2017 11:45:46 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (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 4287D1274D0 for ; Sat, 1 Jul 2017 11:45:46 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id l21so51058511ywb.1 for ; Sat, 01 Jul 2017 11:45:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=JMEcpuM713OPExl+hjudwCuTOpAdVTBDPRsYSJOGoJ8=; b=lrwwwsdx9S9TG3AG5pV7I1yIdK5SNtcmTzkjLVPh/ciBa7SG6xky+KamYUcIRkCRC3 iUFixxWTQhpV1O6IeS5nORfE4Rpq4drcHT9/QpfThaz3wmuvCGqjhR2ZQdg9oMy8+4VR OSq+eCXd6mG6hB269Gw773O718qbb5sxFZ1IXReXi34hDhan2V+llsNaAIKfRNJWxuaE XQZItYK0vmsPWTVRkgC9m+dAOfH0CrifGcWFBl+GkJbcSzjUK++QQFwbkzDSLD9HeAjg kpZIMT4RNqeH3k1kklVVUMUpVnX+EWbjPUZm5QOm9urfJtTlmpGHtm0dHWOd7v0//wRy RnXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=JMEcpuM713OPExl+hjudwCuTOpAdVTBDPRsYSJOGoJ8=; b=EawBy7Sc+S2L9sDOAp5kIKTPabQbGSsUMJz3RRVrgH+Uvg1fLqLpvpS1jAOJKWhO3V uxKPG397Y7NLUBw99jT1o5QRUBXWlC3XuYvQuUvL6giqGZLgVeBaMwUDpS/oDEbumF3N Cqf1IoYkgKd800bdqdimCMYlQJ1sPxmsyjMNlwZYCROZNM6qB5AhjMqZFXcVOzuCAzGC y3m4pDhTr9e5OO+CsxFX3ZqzJnBLzqpMQgiMzk5RwiOFWNPqTBF6ohL1NqjxlI74nvjN lXv36jvSBp2aJ52qCsKP8ncthp9i4iDrAC58ZryPdlOuP5nmShnsY4WqqBpQglZQn6Jy jlYA== X-Gm-Message-State: AIVw112ri8BdoaTl8jt8AaGuK7dQMhxbxjwX7VHjeqG3Ti/AGNlRVL2W 7otAdcJSkmHisGOvX4deMGUa0CXv3QVG X-Received: by 10.129.118.66 with SMTP id j2mr3868018ywk.85.1498934745464; Sat, 01 Jul 2017 11:45:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.215.9 with HTTP; Sat, 1 Jul 2017 11:45:04 -0700 (PDT) In-Reply-To: References: <6D0438F4-5C3B-4F28-A8FB-16B6CFA1C7CA@vigilsec.com> <7298935b-3b4d-4794-8f40-acb188690e87@cs.tcd.ie> From: Eric Rescorla Date: Sat, 1 Jul 2017 11:45:04 -0700 Message-ID: To: Phillip Hallam-Baker Cc: Ryan Sleevi , LAMPS , Russ Housley , Stephen Farrell Content-Type: multipart/alternative; boundary="f403045eed8a0bb337055345f1d7" Archived-At: Subject: Re: [lamps] Recharter Discussion X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 01 Jul 2017 18:45:50 -0000 --f403045eed8a0bb337055345f1d7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Jul 1, 2017 at 11:08 AM, Phillip Hallam-Baker wrote: > I agree it is a bad idea for the user to be making distinctions. What I a= m > trying to do is to surface enough information for an AI to be able to mak= e > a reasonable decision. > > I also agree on the need for a rapid admin cycle, but that is not the sam= e > as getting a site into production rapidly and start accepting credit card= s > from the general public, do online banking, etc. > > The problem I see the SCT scheme in CT addressing is to prevent the delay= s > in various parts of the system compounding so that 24 hours here, 48 hour= s > there, etc. ends up adding up to months. > In discussions we have had about CT, being able to have the site itself up in a matter of minutes has been cited as a high priority and thus a reason why people needed to have SCTs. A system in which certificates aren't acceptable for days -- or even have a high probability of not being acceptable for days -- seems quite problematic. The behavior I see right now is > > 1) Browser encounters certificate > 2) Browser tells user that they are 'secure' > 3) Browser performs validity checking via OCSP, CT, etc. to see if (2) wa= s > actually true. > Which browsers are you talking about? This isn't consistent with my understanding. - For CT checking, I believe everyone presently relies solely on information delivered by the server. - OSCP handling varies a bit: - Some browsers (e.g., Chrome) don't do OSCP checking for most certs - When browsers do OCSP checking, they do it in the critical path but with a short timeout and soft-fail for DV (EV is handled differently, but most sites are DV). 1) Browser encounters certificate > 2) Browser looks at First issued, other indications > If certificate is recent, Browser performs validity checking via OCSP= , > CT, etc. *before* telling the user they are 'Secure'. > I can't speak for other browsers, but I don't believe that we (Firefox) would alter our OCSP/CT behavior based on this indication, because OCSP/CT address other issues such as key loss and CA misbehaviior. -Ekr > Of course, not telling the user they are 'Secure' on the basis of a weakl= y > validated certificate would be a another way to address the problem, mayb= e, > > Having the information inside the cert means that you have the option to > use it for triage. > > > On Sat, Jul 1, 2017 at 12:54 PM, Eric Rescorla wrote: > >> On Fri, Jun 30, 2017 at 9:58 PM, Phillip Hallam-Baker < >> phill@hallambaker.com> wrote: >> >>> =E2=80=8BSince Comodo distributes a browser, at least one browser is in= terested. >>> >> >> It seems like this indicator (and in fact any indicator which disfavors >> recently issued >> certificates) pushes in the opposite direction from design decisions we >> have made >> elsewhere which attempt to favor rapid certificate issuance. To take a >> concrete case, >> much of the structure of CT is designed around the premise that >> certificates need >> to be immediately usable. Were that not so, you could abandon SCTs >> entirely and >> simply have certificates contain inclusion proofs, which would obviously >> be simpler. >> So, having a system which was designed to make recently issued >> certificates not >> work seems to be opposed to the approach we have been taking so far. >> >> Speaking from the perspective of a Firefox implementor, I don't really >> see how we would >> make use of this information in our certificate trust decision. We're >> actually trying to >> get away from making fine discriminations between different types of >> certificates because >> it's so hard for the user to make informed decisions, which means that >> the only thing >> we'd really be able to do is refuse the certificate, which I doubt we >> would do. >> >> -Ekr >> >> >> >> >> >> Given that you seem entirely unconcerned by 16,000 fake paypal sites a >>> certain CA has issued certs for, it is not surprising that you see no >>> reason to make any changes. >>> >>> >>> >>> On Sat, Jul 1, 2017 at 12:14 AM, Ryan Sleevi >>> wrote: >>> >>>> >>>> On Fri, Jun 30, 2017 at 9:27 AM Phillip Hallam-Baker < >>>> phill@hallambaker.com> wrote: >>>> >>>>> On Fri, Jun 30, 2017 at 10:22 AM, Stephen Farrell < >>>>> stephen.farrell@cs.tcd.ie> wrote: >>>>> >>>>>> >>>>>> Hi Phill, >>>>>> >>>>>> On 29/06/17 17:54, Phillip Hallam-Baker wrote: >>>>>> > On Thu, Jun 29, 2017 at 12:47 PM, Stephen Farrell < >>>>>> stephen.farrell@cs.tcd.ie >>>>>> >> wrote: >>>>>> > >>>>>> >> >>>>>> >> >>>>>> >> On 29/06/17 16:21, Russ Housley wrote: >>>>>> >>> Do others have an opinion? >>>>>> >> >>>>>> >> The function sounds useful but perhaps better provided >>>>>> >> via an API to a CT log (not sure). The reason I'd wonder >>>>>> >> about that is that it's hard to see what code would >>>>>> >> read this new value and not want more information than >>>>>> >> that. A CT log API could provide more so might be more >>>>>> >> useful (e.g. if an RP could ask "show me your history of >>>>>> >> meta-data related to certs for example.com"). >>>>>> >> >>>>>> >> Probably not that relevant, but similar information would >>>>>> >> also exist in passive DNS DBs I guess. >>>>>> >> >>>>>> > >>>>>> > =E2=80=8BThere is always a cut off between the standardized parts = and the >>>>>> rest. >>>>>> > >>>>>> > When I first proposed this, it was for human consumption. What I a= m >>>>>> > thinking about now is rather more of a hook for likely proprietary >>>>>> AI >>>>>> > systems reading it.=E2=80=8B >>>>>> >>>>>> Right, that's why a CT API seems maybe more useful and (I think, >>>>>> but I may be wrong), might be easier to get deployed. >>>>>> >>>>>> > >>>>>> > =E2=80=8BSecurity is risk mitigation, not risk elimination. Right = now we can >>>>>> > eliminate what? 95% of phishing sites with free DV certs by simply >>>>>> > rejecting any certs less than 5 days old. =E2=80=8B >>>>> >>>>> >>>> Who is we? >>>> >>>> Is this a statement of what you believe browsers should do, versus >>>> will? Have you heard of or can provide evidence for any expression of >>>> support, from any browser, for this philosophy? >>>> >>>> >>>>>> > >>>>>> > >>>>>> > =E2=80=8BWhat we do next with the =E2=80=8Bdata is going to be imp= ortant. But not >>>>>> something >>>>>> > we are going to be able to really work on at all, let alone >>>>>> standardize >>>>>> > until after we have data. >>>>>> > >>>>>> > All I want to do right now is to instrument so we can start >>>>>> collecting data. >>>>>> > >>>>>> >>>>>> I'm not opposed to defining such a cert extension (which I >>>>>> assume would be the end result) if there's likely to be >>>>>> deployment. But I still think that given that CT logs will >>>>>> have this info already, (and more, and covering >1 issuer) >>>>>> a new CT API may be better than putting it in certs. >>>>>> >>>>> >>>>> =E2=80=8BI don't really want to push everything into CT. This is not >>>>> information that is going to be immediately available, you would have= to do >>>>> a lot of log crunching to validate. >>>>> >>>>> Given that some browsers won't do CRLs or OCSP, I can't see them usin= g >>>>> CT for pro-active checking before they accept the connection. Where I= see >>>>> the value of First Issued is to allow browsers to winnow out certs th= at are >>>>> most likely OK and concentrate checking on those that might be a bit = dodgy. >>>>> >>>> >>>> Are you aware of any browsers interested in this? This feels very much >>>> like LogoType - which was intended for browsers (among others) and >>>> rightfully not widely implemented. >>>> >>>> >>>>> At any rate, putting an extension into the cert is pretty simple whil= e >>>>> changing the CT API to support short lived certs is likely to be a >>>>> performance. I think that this is an easy win to get much of the retu= rn and >>>>> takes the pressure off the CT end of things. >>>>> >>>> >>>> CT already has to deal with this. It does seem you're conflating two >>>> unrelated things though, but perhaps I'm misunderstanding. >>>> >>>> Perhaps it could be useful if you could explain what you believe the >>>> browser security model to be, and how this supports what browsers are = doing >>>> or have expressed support for. >>>> >>>> I do not see any value to this as an extension - and I can see >>>> undesirable (and unreliable) data being added by CAs - so I'm curious = to >>>> understand why using CT is insufficient, especially for the proposed >>>> browser-run machine learning reputation determination. >>>> >>> >>> >>> _______________________________________________ >>> Spasm mailing list >>> Spasm@ietf.org >>> https://www.ietf.org/mailman/listinfo/spasm >>> >>> >> > --f403045eed8a0bb337055345f1d7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sat, Jul 1, 2017 at 11:08 AM, Phillip Hallam-Baker <phill@halla= mbaker.com> wrote:
I agree it is a bad idea for the us= er to be making distinctions. What I am trying to do is to surface enough i= nformation for an AI to be able to make a reasonable decision.=C2=A0
<= div style=3D"font-size:small">
I al= so agree on the need for a rapid admin cycle, but that is not the same as g= etting a site into production rapidly and start accepting credit cards from= the general public, do online banking, etc.
The problem I see the SCT scheme in = CT addressing is to prevent the delays in various parts of the system compo= unding so that 24 hours here, 48 hours there, etc. ends up adding up to mon= ths.

In discussions we have had= about CT, being able to have the site itself up in a matter of minutes has= been cited as a high priority and thus a reason why people needed to have = SCTs. A system in which certificates aren't acceptable for days -- or e= ven have a high probability of not being acceptable for days -- seems quite= problematic.


The behavior I see rig= ht now is

1) Browser encounters certificate
2) Browser tells user that they are 'secure'
3) Browser performs validity checking via OCSP, CT, et= c. to see if (2) was actually true.

=
Which browsers are you talking about? This isn't consistent with m= y understanding.

- For CT checking, I believe ever= yone presently relies solely on information delivered by the server.
<= div>- OSCP handling varies a bit:
=C2=A0 - Some browsers (e.g., C= hrome) don't do OSCP checking for most certs
=C2=A0 - When br= owsers do OCSP checking, they do it in the critical path but with a short t= imeout and soft-fail for DV (EV is handled differently, but most sites are = DV).


1) Brow= ser encounters certificate
2) Browser looks at First issued, othe= r indications
=C2=A0 =C2=A0 If certificate is recent, Browser per= forms validity checking via OCSP, CT, etc. *before* telling the user they a= re 'Secure'.

I ca= n't speak for other browsers, but I don't believe that we (Firefox)= would alter our OCSP/CT behavior
based on this indication, becau= se OCSP/CT address other issues such as key loss and CA misbehaviior.
=

-Ekr

Of course, not telling the user they are 'Secure' on t= he basis of a weakly validated certificate would be a another way to addres= s the problem, maybe,

<= div style=3D"font-size:small">Having the information inside the cert means = that you have the option to use it for triage.


On Sat, Jul 1, 2017 at 12:54 PM, Eric Rescorla <ekr@rtfm.com&= gt; wrote:
On Fri, Jun 30, 2017 = at 9:58 PM, Phillip Hallam-Baker <phill@hallambaker.com>= wrote:
=E2=80=8BSince Comodo distributes a brows= er, at least one browser is interested.

It seems like this indicator (and in fact any indicator whi= ch disfavors recently issued
certificates) pushes in the oppo= site direction from design decisions we have made
elsewhere which= attempt to favor rapid certificate issuance. To take a concrete case,
much of the structure of CT is designed around the premise that certi= ficates need
to be immediately usable. Were that not so, you coul= d abandon SCTs entirely and
simply have certificates contain incl= usion proofs, which would obviously be simpler.
So, having a syst= em which was designed to make recently issued certificates not
wo= rk seems to be opposed to the approach we have been taking so far.

Speaking from the perspective of a Firefox implementor, I = don't really see how we would
make use of this information in= our certificate trust decision. We're actually trying to
get= away from making fine discriminations between different types of certifica= tes because
it's so hard for the user to make informed decisi= ons, which means that the only thing
we'd really be able to d= o is refuse the certificate, which I doubt we would do.

-Ekr





<= div style=3D"font-size:small">Given that you seem entirely unconcerned by 1= 6,000 fake paypal sites a certain CA has issued certs for, it is not surpri= sing that you see no reason to make any changes.



On Sat, Jul 1, 2017 at 12:= 14 AM, Ryan Sleevi <ryan-ietf@sleevi.com> wrote:

On Fri, Jun 30, 2017 at 9:27 AM Phillip Hallam-Baker <phill@hallambaker.com> wrote:
On Fri, Jun 30, 20= 17 at 10:22 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrot= e:

Hi Phill,

On 29/06/17 17:54, Phillip Hallam-Baker wrote:
> On Thu, Jun 29, 2017 at 12:47 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie
>> wrote:
>
>>
>>
>> On 29/06/17 16:21, Russ Housley wrote:
>>> Do others have an opinion?
>>
>> The function sounds useful but perhaps better provided
>> via an API to a CT log (not sure). The reason I'd wonder
>> about that is that it's hard to see what code would
>> read this new value and not want more information than
>> that. A CT log API could provide more so might be more
>> useful (e.g. if an RP could ask "show me your history of
>> meta-data related to certs for example.com").
>>
>> Probably not that relevant, but similar information would
>> also exist in passive DNS DBs I guess.
>>
>
> =E2=80=8BThere is always a cut off between the standardized parts and = the rest.
>
> When I first proposed this, it was for human consumption. What I am > thinking about now is rather more of a hook for likely proprietary AI<= br> > systems reading it.=E2=80=8B

Right, that's why a CT API seems maybe more useful and (I think,=
but I may be wrong), might be easier to get deployed.

>
> =E2=80=8BSecurity is risk mitigation, not risk elimination. Right now = we can
> eliminate what? 95% of phishing sites with free DV certs by simply
> rejecting any certs less than 5 days old. =E2=80=8B

Who is we?

Is this a statement of what you believe browsers should do, versus will? = Have you heard of or can provide evidence for any expression of support, fr= om any browser, for this philosophy?


>
>
> =E2=80=8BWhat we do next with the =E2=80=8Bdata is going to be importa= nt. But not something
> we are going to be able to really work on at all, let alone standardiz= e
> until after we have data.
>
> All I want to do right now is to instrument so we can start collecting= data.
>

I'm not opposed to defining such a cert extension (which I
assume would be the end result) if there's likely to be
deployment. But I still think that given that CT logs will
have this info already, (and more, and covering >1 issuer)
a new CT API may be better than putting it in certs.
<= br>
=E2=80=8BI don't really = want to push everything into CT. This is not information that is going to b= e immediately available, you would have to do a lot of log crunching to val= idate.=C2=A0

Given that some browsers won't do CRLs or OCSP, I can= 9;t see them using CT for pro-active checking before they accept the connec= tion. Where I see the value of First Issued is to allow browsers to winnow = out certs that are most likely OK and concentrate checking on those that mi= ght be a bit dodgy.

Are you aware of any browsers inter= ested in this? This feels very much like LogoType - which was intended for = browsers (among others) and rightfully not widely implemented.
<= div dir=3D"auto">

At any rate, putting an extension into the cert is= pretty simple while changing the CT API to support short lived certs is li= kely to be a performance. I think that this is an easy win to get much of t= he return and takes the pressure off the CT end of things.=C2=A0

CT already has to deal with this. It does seem you're conflat= ing two unrelated things though, but perhaps I'm misunderstanding.

Perhaps it could be useful i= f you could explain what you believe the browser security model to be, and = how this supports what browsers are doing or have expressed support for.

I do not see a= ny value to this as an extension - and I can see undesirable (and unreliabl= e) data being added by CAs - so I'm curious to understand why using CT = is insufficient, especially for the proposed browser-run machine learning r= eputation determination.


____________________________________= ___________
Spasm mailing list
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm




--f403045eed8a0bb337055345f1d7-- From nobody Sat Jul 1 12:14:11 2017 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 30DDC1201F8 for ; Sat, 1 Jul 2017 12:14:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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_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 Dt7ivCzvo0l0 for ; Sat, 1 Jul 2017 12:14:09 -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 1AA041200B9 for ; Sat, 1 Jul 2017 12:14:08 -0700 (PDT) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v61JCnku002311; Sat, 1 Jul 2017 20:14:02 +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-transfer-encoding : mime-version; s=jan2016.eng; bh=r+PMoiW5DG2Qdss/utVXdmY4bvNfFCEvQCjJcELXSDQ=; b=ZfI7OfmZhNUX+5cP3iuEd4R/55bXLdIoqnZyyIH37jUg6uLshxoq6kB9trwip5Mr5095 pQCdmMgia3SWi0cVkQf7nhD2ywB2R5eH9YqqZHZlsmzFaxvAmK5xNACbACZFdGHy6Fkk RgENdwFsWcm7nN8mliQUDOEhUTtgVm2tQlkR1DyJA45ge8Bx9WnBROcze7/JKjt0O7La hs89zSOkFct9muIgaC/mYH+Yy1nB5pHe6KyZxKNWIZGS6HUhThwkQOiR5P/WIYEQpiO3 glTdqkoCxF2Vi1onF1eBqwbZU4aKQQdkGMNIX1r2afzyTAG1QX+HXGK3FhwXGtEFa7iT BA== Received: from prod-mail-ppoint3 ([96.6.114.86]) by m0050095.ppops.net-00190b01. with ESMTP id 2be3942jsh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 01 Jul 2017 20:14:01 +0100 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v61JCBK1020843; Sat, 1 Jul 2017 15:14:00 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint3.akamai.com with ESMTP id 2be72usbq8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sat, 01 Jul 2017 15:14:00 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sat, 1 Jul 2017 12:13:59 -0700 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.1263.000; Sat, 1 Jul 2017 15:13:58 -0400 From: "Salz, Rich" To: Eric Rescorla , Phillip Hallam-Baker CC: Ryan Sleevi , LAMPS , Russ Housley , Stephen Farrell Thread-Topic: [lamps] Recharter Discussion Thread-Index: AQHS7c+piGadg7oTPkeKQkzDVeF7q6I8Nc4AgAAD4ACAAAMegIAAAXwAgAAYBQCAAAHSgIABZ9GAgAAjHQCAAMVlAIAADEOAgADIHgCAABSWgIAAClMA///EbnA= Date: Sat, 1 Jul 2017 19:13:58 +0000 Message-ID: <70ed065e5d3448fe9adae2766626e62a@usma1ex-dag1mb1.msg.corp.akamai.com> References: <6D0438F4-5C3B-4F28-A8FB-16B6CFA1C7CA@vigilsec.com> <7298935b-3b4d-4794-8f40-acb188690e87@cs.tcd.ie> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.40.71] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-01_16:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1707010333 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-01_16:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1707010334 Archived-At: Subject: Re: [lamps] Recharter Discussion X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 01 Jul 2017 19:14:10 -0000 VGhlcmUgaXMgbW9yZSB0byBQS0kgdGhhbiB0aGUgV2ViUEtJLg0KDQpJIHRoaW5rIHRoYXQgYSBD QSBiZWluZyBhYmxlIHRvIGlzc3VlIHNob3J0LXRlcm0gY2VydHMsIGJ1dCBzYXlpbmcgInRoaXMg c2FtZSBrZXlwYWlyIGhhcyBiZWVuIGJvdW5kIHRvIHRoaXMgRE4gZm9yIGZpdmUgeWVhcnMiIGlz IGludGVyZXN0aW5nIGFuZCB1c2VmdWwuICBJdCBjb3VsZCBhbHNvIGJyaW5nIG5ldyB1c2VmdWwg c2VtYW50aWNzIHRvIHZhbGlkYXRpbmcgc2lnbmVkIGRhdGEgdGhhdCBpcyBvbGQuDQoNCldlIGFs cmVhZHkgaGF2ZSBvbmUgQ0EgdGhhdCBoYXMgZXhwcmVzc2VkIGludGVyZXN0IGluIHRoaXMuDQoN Cg0K From nobody Sat Jul 1 12:28:12 2017 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 F2D9E128ACA for ; Sat, 1 Jul 2017 12:28: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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=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=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PnRMvHb-RSZr for ; Sat, 1 Jul 2017 12:28:09 -0700 (PDT) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36D8F127867 for ; Sat, 1 Jul 2017 12:28:09 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id 63so59810333ywr.0 for ; Sat, 01 Jul 2017 12:28:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=KFRR9aYcROcJKkAQKW//GR/35Jq6ngs+/S4BVm+6SO0=; b=0TOp5Tj66rxM6XSmWMi1Gk7Xc9C9+tZ3zaSGx7IGFMbf97Dw23WWyR9T9vBs+bRVN4 EIGmqHMLFcb7U2VFe/OGVmkvw+YULsnP5Dcd8yr0oERnELML1XSluwvqlWlF8YMx/sBD ft74rlaWVWeleJLi0UWXsoZMYL2dNtokzoRIskP5lIhaptahfpgxCMTV+fN22karrptW 7BO1B2t3ZeZ4Y4F3xtTQtXvLfLtYdkBO2OtPvdhpSv/hce0dgNyGfEG0DG5YFHIY2eWi FmjN4xhkuOHdkfNgke4TR/xP3sZq0ReKQq8zeA3z3M4cE9CgKFcoKRSd3NiMs6RLf9g8 XaMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=KFRR9aYcROcJKkAQKW//GR/35Jq6ngs+/S4BVm+6SO0=; b=Cun0rVUEN8aHYXhNv0khP1gjJ0k1UY/aUBYelpWVB0OcLoJXWAn1UNQVCvwXZd5Xzp T5GCW2ZuosAfRqNBqflwNAO40qsN7XbVXqJZke01XQvDvaJofP7pI4x8V6CYpfd4k8pP esmU1D4fCIocLw2EV8qbvDbFHYyc16Gm3VZeykP6IiakZ3evZgpFGGflRcaw4yA+/wRC VflCYmnNgG+IzXRtdr9VmM3fcIHgLPVdYdCtSxjDXmYOAkxIVI6i+jZekgjtFeA3iwab sLvi7REeHL4HP0o00kIyQROVYlz7q88WTPb1Qu+9QiqxI6aQFHqthSHnXgtX8rzn7jfl z7Hw== X-Gm-Message-State: AKS2vOzehmevUpHGY+pRLwv8Cm8WezwPQEgVCTVe1eLCxeQKgsQTUQSS BDYdnSJ1aMFea+tplqVy3JJnBQ/nZXwG X-Received: by 10.129.109.17 with SMTP id i17mr22316861ywc.3.1498937288459; Sat, 01 Jul 2017 12:28:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.215.9 with HTTP; Sat, 1 Jul 2017 12:27:27 -0700 (PDT) In-Reply-To: <70ed065e5d3448fe9adae2766626e62a@usma1ex-dag1mb1.msg.corp.akamai.com> References: <6D0438F4-5C3B-4F28-A8FB-16B6CFA1C7CA@vigilsec.com> <7298935b-3b4d-4794-8f40-acb188690e87@cs.tcd.ie> <70ed065e5d3448fe9adae2766626e62a@usma1ex-dag1mb1.msg.corp.akamai.com> From: Eric Rescorla Date: Sat, 1 Jul 2017 12:27:27 -0700 Message-ID: To: "Salz, Rich" Cc: Phillip Hallam-Baker , Ryan Sleevi , LAMPS , Russ Housley , Stephen Farrell Content-Type: multipart/alternative; boundary="001a114dd50e9ea11a05534688ff" Archived-At: Subject: Re: [lamps] Recharter Discussion X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 01 Jul 2017 19:28:11 -0000 --001a114dd50e9ea11a05534688ff Content-Type: text/plain; charset="UTF-8" On Sat, Jul 1, 2017 at 12:13 PM, Salz, Rich wrote: > There is more to PKI than the WebPKI. Of course, though PHB's message seems to be explicitly positioning this as for WebPKI ( https://www.ietf.org/mail-archive/web/spasm/current/msg00860.html). I think that a CA being able to issue short-term certs, but saying "this > same keypair has been bound to this DN for five years" is interesting and > useful. It could also bring new useful semantics to validating signed data > that is old. > > We already have one CA that has expressed interest in this > Is there any interest from relying parties other than Comodo? -Ekr --001a114dd50e9ea11a05534688ff Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On S= at, Jul 1, 2017 at 12:13 PM, Salz, Rich <rsalz@akamai.com> wr= ote:
There is more to = PKI than the WebPKI.

Of course, though PHB&= #39;s message seems to be explicitly positioning this as for WebPKI (htt= ps://www.ietf.org/mail-archive/web/spasm/current/msg00860.html).
<= div>

I think that a CA being able to issue short-term certs, but saying "th= is same keypair has been bound to this DN for five years" is interesti= ng and useful.=C2=A0 It could also bring new useful semantics to validating= signed data that is old.

We already have one CA that has expressed interest in this
=

Is there any interest from relying parties other than C= omodo?

-Ekr


--001a114dd50e9ea11a05534688ff-- From nobody Sat Jul 1 12:32:16 2017 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 D2A62128ACA for ; Sat, 1 Jul 2017 12:32:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 fm49DoihUpSp for ; Sat, 1 Jul 2017 12:32:13 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::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 63BFC127867 for ; Sat, 1 Jul 2017 12:32:13 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v61JW82T018930; Sat, 1 Jul 2017 20:32:08 +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-transfer-encoding : mime-version; s=jan2016.eng; bh=6vTopm5TuMGGk/BAb6wfkEdhxFgG2MCpgZ6rtxfKZgU=; b=cayUgEopgOS8PsNIz6+/I8pBIzeXTz3chVChd0YZHI8ORvcn+tr1a3uF3mooIcwPhb/C kxb5hlvfLVjb1toOq2lzBORXLAWPI/gj9GlmBVAz5yriN0EyISEETjEWfLZDfU8nyY+t V/flw0gTNM7hT0MTVdj2HJAuvEpNiuOUytfdbW4fw8wzPAIbGN80DNYR5qVlOq47Nbzy Ip/mrZWTCgMDaoIW+/VQ7hKxqVqOwBWmza0BT85M5YPow4Dt+iK8aU7aVZLl7gb+uspJ jkjlHbxiGNNiKRSas/RhNBEGxA6kBUWRQBvu6zYFzM4KxTKmfQ92MM4fWI8oNdDMw2T1 zQ== Received: from prod-mail-ppoint1 (a184-51-33-18.deploy.static.akamaitechnologies.com [184.51.33.18] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 2be0tak6ub-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 01 Jul 2017 20:32:08 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v61JVISa022586; Sat, 1 Jul 2017 15:32:07 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint1.akamai.com with ESMTP id 2be72u1149-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sat, 01 Jul 2017 15:32:07 -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.1263.5; Sat, 1 Jul 2017 15:32:06 -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.1263.000; Sat, 1 Jul 2017 15:32:06 -0400 From: "Salz, Rich" To: Eric Rescorla CC: Phillip Hallam-Baker , Ryan Sleevi , LAMPS , Russ Housley , Stephen Farrell Thread-Topic: [lamps] Recharter Discussion Thread-Index: AQHS7c+piGadg7oTPkeKQkzDVeF7q6I8Nc4AgAAD4ACAAAMegIAAAXwAgAAYBQCAAAHSgIABZ9GAgAAjHQCAAMVlAIAADEOAgADIHgCAABSWgIAAClMA///EbnCAAEdqgP//vZ/w Date: Sat, 1 Jul 2017 19:32:06 +0000 Message-ID: References: <6D0438F4-5C3B-4F28-A8FB-16B6CFA1C7CA@vigilsec.com> <7298935b-3b4d-4794-8f40-acb188690e87@cs.tcd.ie> <70ed065e5d3448fe9adae2766626e62a@usma1ex-dag1mb1.msg.corp.akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.40.71] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-01_16:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1707010339 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-01_16:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1707010339 Archived-At: Subject: Re: [lamps] Recharter Discussion X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 01 Jul 2017 19:32:15 -0000 Pj4gVGhlcmUgaXMgbW9yZSB0byBQS0kgdGhhbiB0aGUgV2ViUEtJLg0KDQo+IE9mIGNvdXJzZSwg dGhvdWdoIFBIQidzIG1lc3NhZ2Ugc2VlbXMgdG8gYmUgZXhwbGljaXRseSBwb3NpdGlvbmluZyB0 aGlzIGFzIGZvciBXZWJQS0kgDQoNCkkgZGlkbid0IHNlZSBpdCBhcyBsaW1pdGVkLCBidXQgbW9y ZSBhcyBhbiBleGFtcGxlLiAgU2hydWcuICBOb3cgd2UgaGF2ZSB0d28gdXNlLWNhc2VzIDopDQoN Cj4gSXMgdGhlcmUgYW55IGludGVyZXN0IGZyb20gcmVseWluZyBwYXJ0aWVzIG90aGVyIHRoYW4g Q29tb2RvPw0KDQpJcyB0aGVyZSBhIHF1b3RhIG9mIG1vcmUgdGhhbiBvbmU/ICBWZXJ5IHdlbGws IGlmIHRoaXMgZXh0ZW5zaW9uIHdlcmUgZGVmaW5lZCBpdCBpcyBxdWl0ZSBsaWtlbHkgdGhhdCB0 aGUgT3BlblNTTCBzaWduYXR1cmUtdmVyaWZ5IHRvb2wgd291bGQgaGF2ZSBhbiBvcHRpb24gdG8g cmVwb3J0IGl0IHdoZW4gdGhlIGNlcnQgaXMgZXhwaXJlZCBzaW5jZSB0aGUgZGF0YSB3YXMgc2ln bmVkLg0K From nobody Sat Jul 1 13:05:50 2017 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 DCF78126CC7 for ; Sat, 1 Jul 2017 13:05:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nomountain-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0JHtNNW_y7sT for ; Sat, 1 Jul 2017 13:05:47 -0700 (PDT) Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0307129AD3 for ; Sat, 1 Jul 2017 13:05:44 -0700 (PDT) Received: by mail-pf0-x229.google.com with SMTP id q86so82196648pfl.3 for ; Sat, 01 Jul 2017 13:05:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nomountain-net.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=P616kuB7/mqDxG+dzuSjRYZMAaMc+mvJYyL1NfXof/k=; b=Cz0EaShm2RK65ygp1ITV03qETj0J0fgqerC4iIjYe5jKkUgsxfjKaXkD/tIf6h0lLL wIXcbhY3qbAxFwfTk6ZtmGOWhwNY3ufLqANpX0Upt7QWsECRndS70f+NWG1NRbkbbVqv qFNqfcT9LfU9zCU1OIEg31voYEkZQX4+7VyCjVEHDBcKMVVPsCUFBnlkeHGHThYLP9Xz wxCUCYkO7kt2nD9t86bqyoplRFTYzC/rAaRhWA5YD7iJhSImhDEQM3UP1YNRaL0q157k 31yfgSpxkOL3hlNPq7vAa87ViUtDjHitPTpk4Zlae5m8e0MWJEzu0AnSHRlQYg/JnrRe msCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=P616kuB7/mqDxG+dzuSjRYZMAaMc+mvJYyL1NfXof/k=; b=GBO4I/wbU0Ara970TJYsmHNzU1iAiLwc4vdNRzJsPnaxtaiAOkqe2cTGBJ4KvJ0Di4 N93dqWhWQv/5Ew4wuiGf3dzO0dzow5Mj2e9Z0iGgliY2PD6azowi2X4JsBVE3TAuHq4K RxeG/0/fYbTJRFEdX6jvPDpE1tpLSD39DGB9jTmvYF8x5mXiUDhDwHWVaRmpixHHKdYz RokUmH8f2TvNLCzvcEjqpJlHjnMbYYq13U7AyJi//I5nGYW0Ugagh7njJA1/7vzRte6m lRjIXxycHLjgFkfgKANdiaT+FHBFqtfq/Oq5i78Jgd1b9son4cX1jVzx4DHLlwj9/3h2 AWwg== X-Gm-Message-State: AIVw113Qzwt2jyOMR70YyBm23TtZMv9/4fXSJI5gf5ii/UUD0iiVjdr6 yuu7vUfaR07RZcdAAPM= X-Received: by 10.84.198.35 with SMTP id o32mr2155567pld.194.1498939544059; Sat, 01 Jul 2017 13:05:44 -0700 (PDT) Received: from aspen.local (216-67-79-142-radius.dynamic.acsalaska.net. [216.67.79.142]) by smtp.gmail.com with ESMTPSA id o6sm21529369pgs.43.2017.07.01.13.05.42 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 01 Jul 2017 13:05:43 -0700 (PDT) To: spasm@ietf.org References: <6D0438F4-5C3B-4F28-A8FB-16B6CFA1C7CA@vigilsec.com> <7298935b-3b4d-4794-8f40-acb188690e87@cs.tcd.ie> <70ed065e5d3448fe9adae2766626e62a@usma1ex-dag1mb1.msg.corp.akamai.com> From: Melinda Shore Message-ID: <4e4937f5-b659-6123-6208-51babb8e58e8@nomountain.net> Date: Sat, 1 Jul 2017 12:05:22 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="jw7RaBe66odUwka6fA9HKBRHWwKNcAnBE" Archived-At: Subject: Re: [lamps] Recharter Discussion X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 01 Jul 2017 20:05:49 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --jw7RaBe66odUwka6fA9HKBRHWwKNcAnBE Content-Type: multipart/mixed; boundary="shNbM9v2BrFPlia3VtfAxEN1tCmW0f2Pk"; protected-headers="v1" From: Melinda Shore To: spasm@ietf.org Message-ID: <4e4937f5-b659-6123-6208-51babb8e58e8@nomountain.net> Subject: Re: [lamps] Recharter Discussion References: <6D0438F4-5C3B-4F28-A8FB-16B6CFA1C7CA@vigilsec.com> <7298935b-3b4d-4794-8f40-acb188690e87@cs.tcd.ie> <70ed065e5d3448fe9adae2766626e62a@usma1ex-dag1mb1.msg.corp.akamai.com> In-Reply-To: --shNbM9v2BrFPlia3VtfAxEN1tCmW0f2Pk Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Well, at any rate, an API is one of the pieces of work that's already under consideration in trans. I can see where having that info in the cert might be more efficient (staple all the things!) but I'm skeptical about the value of this given the responses so far from people who actually build browsers. If there's interest in this as a CT API use case, we'd definitely be interested in talking about it - write it up and let us know. Melinda --shNbM9v2BrFPlia3VtfAxEN1tCmW0f2Pk-- --jw7RaBe66odUwka6fA9HKBRHWwKNcAnBE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJZWACDAAoJELiGRpM6HoEuUWAQAMDk6VmXE4rE5z9gWnkLY+Qs FuVVIUATyI20gjH9OJbhDXeKukALweey2y2Lv19MGtJcqyjV8jhT9ZDSWUGt66Uz I5P0oJR2yC0N86EzzrFyzNUcQe5EXGCEA99xbGepm7Oz3odBC3AuwQETAWQL+KsN w6btDT1sbaergFZThjiprpnMggu0mi3HGwbd3MNvk50dF3mU4Q2Tblms5Ei0MxrT ZAoOJfzQF3TdzFG7qtdCzqIMkX3LqNaLmfHcrpGYAcPTS2j41lnTgX69jBukN4dE xclAxJB1rIgZDID7wlr3pm4kZLpT3//dw2n7iiskzW8rglvcnfOlH5ew0lv22ZVO Pu0pDHOyzqEGD/j3NcP6i33/NTIRsVz1S9U6CSTxyz8Qa8irWMrEUQTpdYcpaXWc GcLXykU2wiBJdRp9Y8K9Wxni+hHL/6AIo3o8rf2RFSQ/jUM/6YQPPPSXUTYE3JMe yHWGoMa61BIe9Ka1YNTCC/1ke/McHe3SG2ClZZEvkhGhIg/xl9cg08ZzcgShaGMT VRvQc+Gwtw6Tq8sN9TpizcRR7mJDrKdouHKAswVsl07+7L2YLQES+PGps5YDp3YZ SCuy0oZDeoG/6ulpm7JF6yR6RDKcMdg1YIJ403UMSoeOrmkNYmQZOZvlynjzgchd mf7h9CbxvccyE+rxSG78 =jLGi -----END PGP SIGNATURE----- --jw7RaBe66odUwka6fA9HKBRHWwKNcAnBE-- From nobody Sat Jul 1 13:16:56 2017 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 BED5F1275AB for ; Sat, 1 Jul 2017 13:16:55 -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, 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 orZ2DTp9fBdg for ; Sat, 1 Jul 2017 13:16:53 -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 6ACEE127078 for ; Sat, 1 Jul 2017 13:16:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id B6572300563 for ; Sat, 1 Jul 2017 16:16:52 -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 G1xK_SIuudh8 for ; Sat, 1 Jul 2017 16:16:51 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 2DCF2300463; Sat, 1 Jul 2017 16:16:51 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Russ Housley In-Reply-To: <70ed065e5d3448fe9adae2766626e62a@usma1ex-dag1mb1.msg.corp.akamai.com> Date: Sat, 1 Jul 2017 16:16:50 -0400 Cc: LAMPS Content-Transfer-Encoding: quoted-printable Message-Id: References: <6D0438F4-5C3B-4F28-A8FB-16B6CFA1C7CA@vigilsec.com> <7298935b-3b4d-4794-8f40-acb188690e87@cs.tcd.ie> <70ed065e5d3448fe9adae2766626e62a@usma1ex-dag1mb1.msg.corp.akamai.com> To: Rich Salz X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [lamps] Recharter Discussion X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 01 Jul 2017 20:16:56 -0000 Rich: You seem to be arguing that renewal is interesting, and that a rekey = would not maintain the same value for the first-issued extension. I'm = curious about your reasoning. (I would have expected you to say something like 'I think that a CA = being able to issue short-term certs, but saying "I've been issuing = certificates for this subject name for five years" is interesting and = useful.') Russ > On Jul 1, 2017, at 3:13 PM, Salz, Rich wrote: >=20 > There is more to PKI than the WebPKI. >=20 > I think that a CA being able to issue short-term certs, but saying = "this same keypair has been bound to this DN for five years" is = interesting and useful. It could also bring new useful semantics to = validating signed data that is old. >=20 > We already have one CA that has expressed interest in this. >=20 >=20 From nobody Sat Jul 1 14:22:15 2017 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 F3461129461 for ; Sat, 1 Jul 2017 14:22:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NVgUuevuT4pE for ; Sat, 1 Jul 2017 14:22:11 -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 D6630124D6C for ; Sat, 1 Jul 2017 14:22:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 4D743300562 for ; Sat, 1 Jul 2017 17:22:11 -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 0NdhbN0tb1Ie for ; Sat, 1 Jul 2017 17:22:10 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 42E7F300268 for ; Sat, 1 Jul 2017 17:22:10 -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 10.3 \(3273\)) Date: Sat, 1 Jul 2017 17:22:09 -0400 References: To: LAMPS In-Reply-To: Message-Id: <59B871BC-D252-4485-AE36-A14E130982CC@vigilsec.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [lamps] Recharter Discussion X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 01 Jul 2017 21:22:14 -0000 > 4b) Updates to CAA for RFC Erratum 4514 (Phill) >=20 > HUM: Consensus in the room to suggest this for a future LAMPS WG = charter. Please propose a paragraph for the charter. Please propose a paragraph for the charter on the mail list. I's also like to spend a few minutes in Prague getting the language = sorted. The more that is done on the mail list in advance, the easier = that will be in Prague. Russ From nobody Sat Jul 1 14:33:23 2017 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 12318124D6C for ; Sat, 1 Jul 2017 14:33:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nhz6GnBBBEH0 for ; Sat, 1 Jul 2017 14:33: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 B2C661200FC for ; Sat, 1 Jul 2017 14:33:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 1F6B5300558 for ; Sat, 1 Jul 2017 17:33: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 YuVjJLbCfY_9 for ; Sat, 1 Jul 2017 17:33:19 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 55960300268 for ; Sat, 1 Jul 2017 17:33:19 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: Date: Sat, 1 Jul 2017 17:33:18 -0400 To: LAMPS X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [lamps] DRAFT Agenda for IETF 99 in Prague X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 01 Jul 2017 21:33:22 -0000 Please suggest improvements. Russ = = = = = = = = DRAFT LAMPS WG Agenda 0) Minute Taker, Jabber Scribe, Bluesheets 1) Agenda Bash 2) Any issues from documents that have been sent to the IESG a) draft-ietf-lamps-rfc5280-i18n-update (Russ) b) draft-ietf-lamps-eai-addresses (Alexey and Wei) c) draft-ietf-lamps-rfc5750-bis (Jim) d) draft-ietf-lamps-rfc5751-bis (Jim) 3) Proposals for additional work items b) rfc6844bis (Phillip) c) Adding SHA3 to PKIX and S/MIME (Sean) x) An first-issued certificate extension (Phillip) 4) Wrap Up From nobody Sat Jul 1 14:35:02 2017 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 C5570126DED for ; Sat, 1 Jul 2017 14:35:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=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=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Les7HKu-tr36 for ; Sat, 1 Jul 2017 14:34:58 -0700 (PDT) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55FC41200FC for ; Sat, 1 Jul 2017 14:34:58 -0700 (PDT) Received: by mail-lf0-x22c.google.com with SMTP id h22so85805571lfk.3 for ; Sat, 01 Jul 2017 14:34:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=vb4Oj9eAvedNR3pFuSTzSmmdL8dMGQ0SQlQcdcSSsBY=; b=ERhPmaKADnzrrJyRgVtbf+7Hk4vs+og0GvPwiBuCYvdgwYYeYDAvQ5b97Sd7x+AaBK jGeQ0+LG/j4MWzl3XlVJHtYmS2yjnKpgXXnvJJa4ANlcfKIim+aRrBM2LSvsyYiHWS1t sDtzJWR5b4htzsxJODm9SXeE8dg53bohMWTbQ3FSwG5pJ+nJNxOeZ85kAKK+iGICSsFM 6xs3fij7FHqcaG51jrksMbNWh2e2n57PBdMivtm3Xq+7QY2mOkmAuJBlWoSsUtotrH12 /M4T2PmXerAjCt6JffdFlMTvAQx8mvwxlZdI3p7ZUXjLbjevIhA/Ur76b8EmsWDm7P2R Nbww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=vb4Oj9eAvedNR3pFuSTzSmmdL8dMGQ0SQlQcdcSSsBY=; b=iAwEr7sPLQ9ElJCYcUrWoMU0YGw6cQLck67PjK/SmKBnMqw9zvfvAihOsruxXQhKUz yaGTp5X4TNRsDMB6CZ6hTLJ1qstZLhnac+TWhIcijU6ekRs6nx/NtPcAv6AlSB3og5Le w+5IFtsQromhVpLrLgtLlBVSlxct8Y4y/aBP5YDuYArOLvSusJDiV6cMCi6jlTFUkZch WFqIRWPePfSLgXinW+8QUK4RSzjLBkZ1Lw9aSbu9K5twy5rIm0bZ6wMy2EiopQpi0poJ fsrowbAY9ixRdXe+hjAW7n8o8yZUaagPMsWuAh5UjmcJnU2fT6/0PePiBhbkfOSYPgko y2MA== X-Gm-Message-State: AKS2vOxqnfPb6gXxCc1Ygb2axqK9GO1L77WWbVtWnn1+2VvMR1mYCd3d xHBFGc8WclYCBDVfaMlGHuvda1pv5caA X-Received: by 10.46.33.165 with SMTP id h37mr9057857lji.15.1498944896604; Sat, 01 Jul 2017 14:34:56 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.25.181.214 with HTTP; Sat, 1 Jul 2017 14:34:55 -0700 (PDT) In-Reply-To: <59B871BC-D252-4485-AE36-A14E130982CC@vigilsec.com> References: <59B871BC-D252-4485-AE36-A14E130982CC@vigilsec.com> From: Phillip Hallam-Baker Date: Sat, 1 Jul 2017 17:34:55 -0400 X-Google-Sender-Auth: zXoiUx_s-rAFy04s3_8YpTcML6w Message-ID: To: Russ Housley Cc: LAMPS Content-Type: multipart/alternative; boundary="001a1142bbc0199dae0553484ee1" Archived-At: Subject: Re: [lamps] Recharter Discussion X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 01 Jul 2017 21:35:01 -0000 --001a1142bbc0199dae0553484ee1 Content-Type: text/plain; charset="UTF-8" I already proposed the following four days ago: X. Specify a discovery mechanism for CAA records to replace the one described in RFC 6844 On Sat, Jul 1, 2017 at 5:22 PM, Russ Housley wrote: > > 4b) Updates to CAA for RFC Erratum 4514 (Phill) > > > > HUM: Consensus in the room to suggest this for a future LAMPS WG > charter. Please propose a paragraph for the charter. > > Please propose a paragraph for the charter on the mail list. > > I's also like to spend a few minutes in Prague getting the language > sorted. The more that is done on the mail list in advance, the easier that > will be in Prague. > > Russ > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm > --001a1142bbc0199dae0553484ee1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I a= lready proposed the following four days ago:


X. Specify a discovery mechanism for CAA records to replace the = one described in RFC 6844

On Sat, Jul 1, 2017 at 5:22 PM, Russ Housley <housley= @vigilsec.com> wrote:
> 4b)=C2=A0 Updates to CAA for RFC = Erratum 4514 (Phill)
>
> HUM: Consensus in the room to suggest this for a future LAMPS WG chart= er.=C2=A0 Please propose a paragraph for the charter.

Please propose a paragraph for the charter on the mail list.

I's also like to spend a few minutes in Prague getting the language sor= ted.=C2=A0 The more that is done on the mail list in advance, the easier th= at will be in Prague.

Russ

_______________________________________________
Spasm mailing list
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm

--001a1142bbc0199dae0553484ee1-- From nobody Sat Jul 1 14:38:57 2017 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 2130B129ADD for ; Sat, 1 Jul 2017 14:38:56 -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, HTML_MESSAGE=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 UHfkGJ9jizfW for ; Sat, 1 Jul 2017 14:38:54 -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 3C5B81200FC for ; Sat, 1 Jul 2017 14:38:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 98718300558 for ; Sat, 1 Jul 2017 17:38:53 -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 m-WmDtzd4Jwx for ; Sat, 1 Jul 2017 17:38:52 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 12D4E300268; Sat, 1 Jul 2017 17:38:52 -0400 (EDT) From: Russ Housley Message-Id: <7478C479-270B-41A6-81F7-19D55F482B7A@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_4D62DC1E-D462-4B8A-9411-98A7F55DAE2F" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Sat, 1 Jul 2017 17:38:51 -0400 In-Reply-To: Cc: LAMPS To: Phillip Hallam-Baker References: <59B871BC-D252-4485-AE36-A14E130982CC@vigilsec.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [lamps] Recharter Discussion X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 01 Jul 2017 21:38:56 -0000 --Apple-Mail=_4D62DC1E-D462-4B8A-9411-98A7F55DAE2F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Yes, you did. I was expecting some words to provide an understanding of = the scope of the changes. It should not be more than a sentence or two. Russ > On Jul 1, 2017, at 5:34 PM, Phillip Hallam-Baker = wrote: >=20 > I already proposed the following four days ago: >=20 >=20 > X. Specify a discovery mechanism for CAA records to replace the one = described in RFC 6844 >=20 > On Sat, Jul 1, 2017 at 5:22 PM, Russ Housley > wrote: > > 4b) Updates to CAA for RFC Erratum 4514 (Phill) > > > > HUM: Consensus in the room to suggest this for a future LAMPS WG = charter. Please propose a paragraph for the charter. >=20 > Please propose a paragraph for the charter on the mail list. >=20 > I's also like to spend a few minutes in Prague getting the language = sorted. The more that is done on the mail list in advance, the easier = that will be in Prague. >=20 > Russ >=20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm = >=20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm --Apple-Mail=_4D62DC1E-D462-4B8A-9411-98A7F55DAE2F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Yes, you did.  I was expecting some words to provide an = understanding of the scope of the changes.  It should not be more = than a sentence or two.

Russ


On Jul 1, 2017, at 5:34 PM, Phillip Hallam-Baker <phill@hallambaker.com> wrote:

I = already proposed the following four days ago:


X. Specify a discovery = mechanism for CAA records to replace the one described in RFC 6844

On Sat, Jul 1, 2017 at 5:22 PM, Russ Housley <housley@vigilsec.com> = wrote:
> 4b)  = Updates to CAA for RFC Erratum 4514 (Phill)
>
> HUM: Consensus in the room to suggest this for a future LAMPS WG = charter.  Please propose a paragraph for the charter.

Please propose a paragraph for the charter on the mail list.

I's also like to spend a few minutes in Prague getting the language = sorted.  The more that is done on the mail list in advance, the = easier that will be in Prague.

Russ

_______________________________________________
Spasm mailing list
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm

_______________________________________________
Spasm = mailing list
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm

= --Apple-Mail=_4D62DC1E-D462-4B8A-9411-98A7F55DAE2F-- From nobody Sat Jul 1 17:55:13 2017 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 A33DE124234 for ; Sat, 1 Jul 2017 17:55:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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_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 fOSZY3m2PC5C for ; Sat, 1 Jul 2017 17:55:10 -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 E98A51205D3 for ; Sat, 1 Jul 2017 17:55:09 -0700 (PDT) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v620pi2p010351; Sun, 2 Jul 2017 01:55:08 +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-transfer-encoding : mime-version; s=jan2016.eng; bh=WSlLnugOj78OB/841YUgvsD1hZHy0nLVBx5PLVlX+BY=; b=ci+KOm6ps848Ax/pT16zy7ww9Hca2sRsv1Pe1SHWnCp6n+pP8HTQryDSeU4IEKxR96pJ qThFdwpuNQS5UQK1O0CF37osbY5LEwn+lyRbCkR6RFM9T7MD5TFo+jxPcR6uNbHuAgd4 /7/W3zKCtKuCXv01nc1+wVk8RrqPKn9tHNXngjJ4tst95H1BCjMi9PbCfBifoD8rwgo2 AkWWr0t4fMpeEE8srj5gijEo7HgjziC3G6iP1XTS/eYq3Nappd8Y9aGfYnjx0laBklRH IdJkDM4ay8cZiL9jfroyetFEEjlhwzx2UGhpHqzxEt9pe0ZX9EZvzO3T7kBlc6GOTTKA Cw== Received: from prod-mail-ppoint4 ([96.6.114.87]) by m0050095.ppops.net-00190b01. with ESMTP id 2be39438wt-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 02 Jul 2017 01:55:08 +0100 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v620oYel030410; Sat, 1 Jul 2017 20:55:07 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint4.akamai.com with ESMTP id 2be72v1x3n-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sat, 01 Jul 2017 20:55:07 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag3mb5.msg.corp.akamai.com (172.27.123.55) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sat, 1 Jul 2017 17:55:06 -0700 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sat, 1 Jul 2017 20:55:05 -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.1263.000; Sat, 1 Jul 2017 20:55:05 -0400 From: "Salz, Rich" To: Russ Housley CC: LAMPS Thread-Topic: [lamps] Recharter Discussion Thread-Index: AQHS7c+piGadg7oTPkeKQkzDVeF7q6I8Nc4AgAAD4ACAAAMegIAAAXwAgAAYBQCAAAHSgIABZ9GAgAAjHQCAAMVlAIAADEOAgADIHgCAABSWgIAAClMA///EbnCAAFU2AIAACdcw Date: Sun, 2 Jul 2017 00:55:05 +0000 Message-ID: <19f328b551644292b8d2091295cb48c7@usma1ex-dag1mb1.msg.corp.akamai.com> References: <6D0438F4-5C3B-4F28-A8FB-16B6CFA1C7CA@vigilsec.com> <7298935b-3b4d-4794-8f40-acb188690e87@cs.tcd.ie> <70ed065e5d3448fe9adae2766626e62a@usma1ex-dag1mb1.msg.corp.akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.40.71] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-01_18:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1707020013 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-01_18:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1707020013 Archived-At: Subject: Re: [lamps] Recharter Discussion X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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: Sun, 02 Jul 2017 00:55:12 -0000 > You seem to be arguing that renewal is interesting, and that a rekey woul= d > not maintain the same value for the first-issued extension. I'm curious = about > your reasoning. =20 I am thinking about signed data, not the WebPKI. Imagine I have a current = cert and data signed before that cert. Having an extension that said "this= same DN and key were first good 'n' years ago" seems like it could help he= re. > (I would have expected you to say something like 'I think that a CA being= able > to issue short-term certs, but saying "I've been issuing certificates for= this > subject name for five years" is interesting and useful.') Shrug, that doesn't interest me. The browser will do its own validation in = real-time. I don't see how or why the WebPKI would find this useful. But = maybe I'm wrong, looking forward to what PHB writes. From nobody Sat Jul 1 18:49:04 2017 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 1EE01126C25 for ; Sat, 1 Jul 2017 18:49:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gjN8DicrKUUV for ; Sat, 1 Jul 2017 18:49:00 -0700 (PDT) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (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 03645120726 for ; Sat, 1 Jul 2017 18:49:00 -0700 (PDT) Received: by mail-lf0-x22a.google.com with SMTP id b207so86846538lfg.2 for ; Sat, 01 Jul 2017 18:48:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=MWw3P+rRv6FVw0Mjr98+efmtWsYZSP3G/TXLzBVMdS0=; b=MvQ5Dn1iY0h65FNYGUBE6kcPaGYbdftQpYiYiUbwFiaOJvz6fMjl9/UuywwyYr+Flc R9egTdNxmyZhNc6mon/eBXkn9VdEB+KfMzIDoI9VusAyvthGwfpP1y6vxBUqjTfhwMzR kALxi0EMTKBzDdtLZXgoADBCJr++q7hbH0eJqPgnSChbxQKlqyCTfARTXtKrNGAyu2Ml R2ceNEL1pslGqqOLVEgXwGwF6qLKQnzA2swIiIKz2kNrHeRB9ecRIfyhIU3aetHCQfTV MdxdbXVWLP3TRQ8RzqwHLGTkfLWYJ7nd1GbCg0i/PwrR8msH/skHBoNkMeWZEDfkO1WW 8Epw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=MWw3P+rRv6FVw0Mjr98+efmtWsYZSP3G/TXLzBVMdS0=; b=oDTr1XFjbzs00TuXJ2E2/WkzbqpAPv+L4gCzu0RsW3byz3RxNWRlc2by2l2Xe3zcEj qFi8InLKo2OEcjZM/dsqDqsYR6lKU7tXN33w5IHB4CmUFR2tXbqHM5hp8DuQwRChgjnC uvC6bqN1xqlZ8XjySMg/tizKiH+3OL3pobEu9GFOHuk+F40JCr/KOMSS1Iz19f4FQ7n+ HwN1XlYxwPlagGWa/MmAyVb1nOUP13xG4Ctb2jC2/hOw8JPmlsBFfxLKm7Xfuzkce1NP 7W7x1F13zP9gM55sCxJfGGwSGnaRa/SY9H7vbQ9BJwzShc0xz/FzNE+Z3YQD7787KDfu IjyQ== X-Gm-Message-State: AKS2vOyKDPhTmr4tEMo5+teq2YKljYzYAvprwLuqYVvmG0Kx3O2GDQbO BlZtdYhV6dg3lK6d0nc57Mq1GS8Ue7O5 X-Received: by 10.46.84.1 with SMTP id i1mr7389767ljb.131.1498960138326; Sat, 01 Jul 2017 18:48:58 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.25.181.214 with HTTP; Sat, 1 Jul 2017 18:48:57 -0700 (PDT) In-Reply-To: <7478C479-270B-41A6-81F7-19D55F482B7A@vigilsec.com> References: <59B871BC-D252-4485-AE36-A14E130982CC@vigilsec.com> <7478C479-270B-41A6-81F7-19D55F482B7A@vigilsec.com> From: Phillip Hallam-Baker Date: Sat, 1 Jul 2017 21:48:57 -0400 X-Google-Sender-Auth: Ntu_awNtX9tCXoKvXkoaUoKqimo Message-ID: To: Russ Housley Cc: LAMPS Content-Type: multipart/alternative; boundary="f403045fbb0693dbd005534bda77" Archived-At: Subject: Re: [lamps] Recharter Discussion X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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: Sun, 02 Jul 2017 01:49:02 -0000 --f403045fbb0693dbd005534bda77 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Jul 1, 2017 at 5:38 PM, Russ Housley wrote: > Yes, you did. I was expecting some words to provide an understanding of > the scope of the changes. It should not be more than a sentence or two. > > Russ > =E2=80=8BI seem to recall some other people suggesting extensions to CAA to= enable their use in the issue process. But I can't remember who or where. I did ping the CABForum list to see if they posted there. I also have to post the final version of the errata, this has been checked by all the people who objected previously without comment. Unless additional work is proposed: =E2=80=8BX. Specify a discovery mechanism for CAA records to replace the on= e described in RFC 6844. RFC 6844 describes the mechanism by which CAA records relating to a domain are discovered. Implementation experience has demonstrated an ambiguity in the current processing of CNAME and DNAME records during discovery. Subsequent discussion has suggested that a different discovery approach would resolve limitations inherent in the current approach. I am trying to be concise here... Can always make it longer. --f403045fbb0693dbd005534bda77 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On = Sat, Jul 1, 2017 at 5:38 PM, Russ Housley <housley@vigilsec.com>= wrote:
Yes, you did.=C2=A0 I was expecting some words to provide an = understanding of the scope of the changes.=C2=A0 It should not be more than= a sentence or two.
Russ

=
=E2=80=8BI seem to r= ecall some other people suggesting extensions to CAA to enable their use in= the issue process. But I can't remember who or where. I did ping the C= ABForum list to see if they posted there. I also have to post the final ver= sion of the errata, this has been checked by all the people who objected pr= eviously without comment.=C2=A0


Unl= ess additional work is proposed:

=E2=80=8BX. Specify a discovery mechanism for CAA records to replac= e the one described in RFC 6844.

RFC 6844 describes the mechanism by which CAA records relating to a= domain are discovered. Implementation experience has demonstrated an ambig= uity in the current processing of CNAME and DNAME records during discovery.= Subsequent discussion has suggested that a different discovery approach wo= uld resolve limitations inherent in the current approach.


I am trying to be concise here... Can always make = it longer.
--f403045fbb0693dbd005534bda77-- From nobody Sun Jul 2 10:45:51 2017 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 BD257129789 for ; Sun, 2 Jul 2017 10:45:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.439 X-Spam-Level: X-Spam-Status: No, score=-2.439 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, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7wKHq8HJUcWh for ; Sun, 2 Jul 2017 10:45:47 -0700 (PDT) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A137E12778E for ; Sun, 2 Jul 2017 10:45:47 -0700 (PDT) Received: by mail-oi0-x22d.google.com with SMTP id 191so42317981oii.2 for ; Sun, 02 Jul 2017 10:45:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=o2ADGGw5I6wpDTVWsK/6NA07+7jdHoWu8QdAnRb/V7A=; b=Y/YQLMnejVmw1FJQO/CgrVS2eX07QYs4+wMgV0m6tojPscIyIm7XdqNzVd9M8U7Wem ltXW5fsCsBzxoi3/CWFZE7o9au1rRDOP6+7kBKOo83r/FUnRlpA/1EO+QI5JvKjwUEyq DWuVvRk+piZCCDL6zsIYxq+o36ENHqUooa6ccfGZ3G6J7uXYo3+Ssz0pT5pEXZMXGznv 8SQVZJVENKHs6DsDlIcknLGgleidZggUuLEy8Lfrskx1RJpagtAXkvLAll7IbuAMQfiy ZJSfASc7OkLmPN1IYN0Jtvpp9c6nxGRAcSC6IpBCeHKeEaJKbMvhQNFw1xj6jbingH0X pORw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=o2ADGGw5I6wpDTVWsK/6NA07+7jdHoWu8QdAnRb/V7A=; b=DP3IwDlpCD0GPHo3RIJLV6XfaEwFU+i0yaL/pMz3N2aukrjS9zsfieQrKQuzBBzNdz Way8LxVwmSR7zJh2QuupjA3Iqiqqk3ET0wGeseUTLx0kvloyQ4lGofzV3OZs0ZhPMydF ruV5uvYBD7AOEq+F+a8IklqUng6t2lwcWHUQUfpaE5dI9BNNTX4jb4JrHse20x9URhWI MdGBU+fqJPzGc7g6ohtyPbI6YMylu2HOxWTCA9UHU0S2mDP7EKxD/uM9ny1Ll/juJ0NS df+sUM5ukIokGpnLj3CiEAGlultelMqlQ2XpI1jcfl3PMVl2mMbnwGBoYQRXTYWvWWyJ TPRA== X-Gm-Message-State: AKS2vOxJ1h6qayydFquh3bgXCI0Gi/VodYLPs8SUBosssl62lCGZrS2f d6ia6olivqXYXDszT+4ZPFVlD4kBJLrs X-Received: by 10.202.242.68 with SMTP id q65mr19468087oih.162.1499017546950; Sun, 02 Jul 2017 10:45:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.237.18 with HTTP; Sun, 2 Jul 2017 10:45:46 -0700 (PDT) In-Reply-To: References: <149901692647.17218.7654069086751009731.idtracker@ietfa.amsl.com> From: Dmitry Belyavsky Date: Sun, 2 Jul 2017 20:45:46 +0300 Message-ID: To: spasm@ietf.org Content-Type: multipart/alternative; boundary="94eb2c09508465eddc05535938cc" Archived-At: Subject: [lamps] Fwd: New Version Notification for draft-belyavskiy-certificate-limitation-policy-02.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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: Sun, 02 Jul 2017 17:45:50 -0000 --94eb2c09508465eddc05535938cc Content-Type: text/plain; charset="UTF-8" Hello, I've uploaded a document decribing a proposal of changing the certificate validation process for application needs. It provides more flexible way of trust limitations than CRL does. Does the suggested document match a possible LAMPS rechartered profile? Thank you! ---------- Forwarded message ---------- From: Date: Sun, Jul 2, 2017 at 8:35 PM Subject: New Version Notification for draft-belyavskiy-certificate-l imitation-policy-02.txt To: Dmitry Belyavskiy A new version of I-D, draft-belyavskiy-certificate-limitation-policy-02.txt has been successfully submitted by Dmitry Belyavskiy and posted to the IETF repository. Name: draft-belyavskiy-certificate-limitation-policy Revision: 02 Title: Certificate Limitation Policy Document date: 2017-07-01 Group: Individual Submission Pages: 6 URL: https://www.ietf.org/internet-drafts/draft-belyavskiy-certif icate-limitation-policy-02.txt Status: https://datatracker.ietf.org/doc/draft-belyavskiy-certifica te-limitation-policy/ Htmlized: https://tools.ietf.org/html/draft-belyavskiy-certificate-li mitation-policy-02 Htmlized: https://datatracker.ietf.org/doc/html/draft-belyavskiy-cert ificate-limitation-policy-02 Diff: https://www.ietf.org/rfcdiff?url2=draft-belyavskiy-certific ate-limitation-policy-02 Abstract: The document provides a specification of the application-level trust model. Being provided at the application level, the limitations of trust can be distributed separately using cryptographically protected format instead of hardcoding the checks into the application itself. The IETF Secretariat -- SY, Dmitry Belyavsky -- SY, Dmitry Belyavsky --94eb2c09508465eddc05535938cc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,
I've uploaded a document decribing=C2=A0a proposal of changing the certificate validation process for= application needs.=C2=A0
It provides more flexible way of trust limitations than CRL does.

Does the suggested document match a possible LAMPS re= chartered profile?

Thank you!

---------- For= warded message ----------
From: <internet-drafts@ietf.org>
Date: Sun, Jul 2, 2017 at 8:= 35 PM
Subject: New Version Notification for draft-belyavskiy-certificate= -limitation-policy-02.txt
To: Dmitry Belyavskiy <beldmit@gmail.com>


A new version of I-D, draft-belyavskiy-certificate-limitation-policy-0= 2.txt
has been successfully submitted by Dmitry Belyavskiy and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-belyavskiy-certificate-= limitation-policy
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A002
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Certificate Limitation Policy
Document date:=C2=A0 2017-07-01
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 6
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-draf= ts/draft-belyavskiy-certificate-limitation-policy-02.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-belyavskiy= -certificate-limitation-policy/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-belyavskiy-certificate-= limitation-policy-02
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-bel= yavskiy-certificate-limitation-policy-02
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddra= ft-belyavskiy-certificate-limitation-policy-02

Abstract:
=C2=A0 =C2=A0The document provides a specification of the application-level= trust
=C2=A0 =C2=A0model.=C2=A0 Being provided at the application level, the limi= tations of
=C2=A0 =C2=A0trust can be distributed separately using cryptographically pr= otected
=C2=A0 =C2=A0format instead of hardcoding the checks into the application i= tself.



The IETF Secretariat




--
SY, Dmitry Belyavsky



--
SY, Dmitry Belyavsky
--94eb2c09508465eddc05535938cc-- From nobody Mon Jul 3 04:34:48 2017 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 8ED2C131582 for ; Mon, 3 Jul 2017 04:34:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mx6ev_PtNpuT for ; Mon, 3 Jul 2017 04:34:45 -0700 (PDT) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0096.outbound.protection.outlook.com [23.103.201.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 117EB13157D for ; Mon, 3 Jul 2017 04:34:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=g32YF9tX71CgQk+O4cNwyiPxiGyoZzb9RgztzPqja+Y=; b=EFRWlXIo1INNMy6dlCH8PrmQuDc8AGMmXXn3cnkk1rQMsAmcVq25EKOCiJmCCYHVRqLPIYECK95YUXS14eIAvnXGCiz3Nm9B3aH3JvCLVrCHKK1F5/vpdRkPSuG557NXUS33/iGOj5dzkDzQKXkmRCrTX12+eizqAbIl5Dz67LQ= Received: from DM5PR09MB1467.namprd09.prod.outlook.com (10.173.171.21) by DM5PR09MB1466.namprd09.prod.outlook.com (10.173.171.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1220.11; Mon, 3 Jul 2017 11:34:44 +0000 Received: from DM5PR09MB1467.namprd09.prod.outlook.com ([10.173.171.21]) by DM5PR09MB1467.namprd09.prod.outlook.com ([10.173.171.21]) with mapi id 15.01.1220.018; Mon, 3 Jul 2017 11:34:43 +0000 From: "Dang, Quynh (Fed)" To: Russ Housley , LAMPS Thread-Topic: [lamps] Recharter Discussion Thread-Index: AQHS7c+w+/1+zWpP/UquALFLepULLqJCAIiT Date: Mon, 3 Jul 2017 11:34:42 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: nist.gov; dkim=none (message not signed) header.d=none;nist.gov; dmarc=none action=none header.from=nist.gov; x-originating-ip: [129.6.105.150] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR09MB1466; 7:Oih2Z2aD8gOvacYbDYqIcgfp4ygKKRUItqC7wNKKlFoUCZgtacJy3fuxJKVQyrIyXNlvVJ+PE7z6fY2VmoM4Nb8CFjGFYXpqjpgwXeYmzWPSq9fftUULq1WV1oj5tSuOnlDQiK9h/fzwbXXRYcN8JV52eCEglLg/hOr+K8bOeEktUhcONTF1VZEDXWTYQxKafZc3LQn65I+/Zd8+aPPf5fohPEb5Rx9fgL/sCslp3Xdw2AZHk/ISuwpOqOstrPsU5/k4bNku0d8yORWVAyWU8Q/Qnx5LjpvvlBNm0Adpe5dAKKWp4fysdONUxBoP961kbGpIKYqG/6C31tRcqTQeF+K7wcnPt6lVo5dfksyHmsdkHJc/MkOA9ExjRRGH0e7DHvE3ZjB+TRCU4FqlZT2zM3AxRxxz+pjnyYaVefKjcy5bfVaacO2cd5ZtdUN7i9DaLTjutTwKmuIcbZTyhmFVQTTLSwf09977RyZt85qRTvoktAb0A6C3cC3LHHoBxCMg3UfzPvixGyqMq9rGqSIEhamFkRcot0vf0qlh865HtMAsbr7cdIL399NjqvyzgVhLwdqu2BCBrAUA6tJLd6L2euNADqrWpvCoKI426oe/Lcl+FdlipSuxOhaqtZ1G6fcC8pu6fIg5Yw0undKyCFLHEzPyqFTxayYeyTzovcdj1d8+D0fVi8S5RT/IgwQblxl9viMUcXlBIbU53/9jDRHKJMx6H8eqIhHVOJsBPEocOP9QhMGmpWbpuTmGyvZH2OvnQSaR+bXx0uLlZvgJuioeq3JBf3VOEugZEJ7RNPHW42g= x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10019020)(39850400002)(39410400002)(39860400002)(39400400002)(39840400002)(39450400003)(53754006)(377454003)(2950100002)(76176999)(54356999)(7736002)(50986999)(2906002)(189998001)(53546010)(6246003)(5660300001)(38730400002)(81166006)(14454004)(53936002)(2900100001)(19627405001)(33656002)(606006)(229853002)(6606003)(8936002)(99286003)(6306002)(54896002)(6512007)(9686003)(236005)(8676002)(6506006)(6436002)(77096006)(25786009)(3846002)(6116002)(102836003)(478600001)(6486002)(74316002)(966005)(86362001)(3280700002)(66066001)(3660700001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR09MB1466; H:DM5PR09MB1467.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-ms-office365-filtering-correlation-id: 42395004-8d3c-4053-e969-08d4c2077fc3 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(48565401081)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DM5PR09MB1466; x-ms-traffictypediagnostic: DM5PR09MB1466: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278178393323532)(133145235818549)(236129657087228)(192374486261705)(100405760836317)(148574349560750)(247924648384137); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(100000703101)(100105400095)(10201501046)(6055026)(6041248)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123560025)(20161123564025)(20161123562025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR09MB1466; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR09MB1466; x-forefront-prvs: 035748864E spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR09MB146489331A8A572ADC591125F3D60CY4PR09MB1464namp_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jul 2017 11:34:42.8937 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR09MB1466 Archived-At: Subject: Re: [lamps] Recharter Discussion X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 03 Jul 2017 11:34:48 -0000 --_000_CY4PR09MB146489331A8A572ADC591125F3D60CY4PR09MB1464namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, For item 4a: Keccak and SHA-3 functions (including all the FIPS 202 and SP 800-185 funct= ions) are the outcome of an open competition, unlike the previous hashing s= tandards. They have a clear design rationale and have been receiving a lot = of public cryptanalysis during and after the SHA-3 competition to today. Al= l of that gives great confidence that the SHA-3s are very secure. The SHA3s= also have much larger security margins than SHA-2s. In addition, since the= design of the SHA3s is very different from SHA-2s (and other ARX-based des= igns), they offer sane diversity for security. Therefore, the SHA-3s are ex= cellent alternatives for SHA2s. Regards, Quynh. ________________________________ From: Spasm on behalf of Russ Housley Sent: Sunday, June 25, 2017 12:25 PM To: LAMPS Subject: [lamps] Recharter Discussion We have almost finished the last document under the current charter. We wi= ll beed to deal with any concerns raised by the IESG, but we should starts = drafting the next version of the charter while that is happening. In Chica= go, we talked about several possible topics for the re-charter: 4c) OCSP response extension for revocation hint text (Rich) Rich withdrew his support for this one. Unless someone else wants to step = in, this one will be dropped. 4b) Updates to CAA for RFC Erratum 4514 (Phill) HUM: Consensus in the room to suggest this for a future LAMPS WG charter. = Please propose a paragraph for the charter. 4a) Adding SHA3 to PKIX and S/MIME (Sean) HUM: Many people in the room to suggest this as a topic for a future LAMPS WG charter; however, a significant number thought it should not be done. Many people thought that SHA-256, SHA-384, and SHA-512 filled this need. I= f you would like to see it move forward, please propose a paragraph for the= charter. Are there any other topics that someone would like to raise now? All three= of the above topics had at least one document to support them. So, new to= pics should come with an Internet-Draft or a promise of one before the I-D = cutoff for Prague. Russ _______________________________________________ Spasm mailing list Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm --_000_CY4PR09MB146489331A8A572ADC591125F3D60CY4PR09MB1464namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi all, 


For item 4a: 


Keccak and SHA-3 functions (including all the FIPS 202 and SP 800-185 = functions) are the outcome of an open competition, unlike the previous hash= ing standards. They have a clear design rationale and have been receiving a= lot of public cryptanalysis during and after the SHA-3 competition to today. All of that gives great confiden= ce that the SHA-3s are very secure. The SHA3s also have much larger securit= y margins than SHA-2s. In addition, since the design of the SHA3s is very d= ifferent from SHA-2s (and other ARX-based designs), they offer sane diversity for security. Therefore, the= SHA-3s are excellent alternatives for SHA2s. 

Regards,

Quynh. 


From: Spasm <spasm-bou= nces@ietf.org> on behalf of Russ Housley <housley@vigilsec.com> Sent: Sunday, June 25, 2017 12:25 PM
To: LAMPS
Subject: [lamps] Recharter Discussion
 
We have almost finished the last document under th= e current charter.  We will beed to deal with any concerns raised by t= he IESG, but we should starts drafting the next version of the charter whil= e that is happening.  In Chicago, we talked about several possible topics for the re-charter:


4c)  OCSP response extension for revocation hint text (Rich)

Rich withdrew his support for this one.  Unless someone else wants to = step in, this one will be dropped.


4b)  Updates to CAA for RFC Erratum 4514 (Phill)

HUM: Consensus in the room to suggest this for a future LAMPS WG charter.&n= bsp; Please propose a paragraph for the charter.


4a)  Adding SHA3 to PKIX and S/MIME (Sean)

HUM: Many people in the room to suggest this as a topic for a future
  LAMPS WG charter; however, a significant number thought it should no= t
  be done.

Many people thought that SHA-256, SHA-384, and SHA-512 filled this need.&nb= sp; If you would like to see it move forward, please propose a paragraph fo= r the charter.


Are there any other topics that someone would like to raise now?  All = three of the above topics had at least one document to support them.  = So, new topics should come with an Internet-Draft or a promise of one befor= e the I-D cutoff for Prague.

Russ

_______________________________________________
Spasm mailing list
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm
--_000_CY4PR09MB146489331A8A572ADC591125F3D60CY4PR09MB1464namp_-- From nobody Mon Jul 3 06:26:06 2017 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 6275C13161A for ; Mon, 3 Jul 2017 06:26:05 -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, HTML_MESSAGE=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 62x5F78f8Ge1 for ; Mon, 3 Jul 2017 06:26: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 A8BC912EAF7 for ; Mon, 3 Jul 2017 06:26:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id E1FDD300563 for ; Mon, 3 Jul 2017 09:26:01 -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 Qx-Hf_Z_YeaV for ; Mon, 3 Jul 2017 09:26:00 -0400 (EDT) Received: from [5.5.33.31] (vpn.snozzages.com [204.42.252.17]) by mail.smeinc.net (Postfix) with ESMTPSA id 7D78030043A; Mon, 3 Jul 2017 09:25:59 -0400 (EDT) From: Russ Housley Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_63EDFB60-FB3B-43BC-83C8-D4F12ED8C020" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 3 Jul 2017 09:25:57 -0400 In-Reply-To: Cc: LAMPS To: Dmitry Belyavsky References: <149901692647.17218.7654069086751009731.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [lamps] New Version Notification for draft-belyavskiy-certificate-limitation-policy-02.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 03 Jul 2017 13:26:05 -0000 --Apple-Mail=_63EDFB60-FB3B-43BC-83C8-D4F12ED8C020 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dmitry: This I-D is not complete enough for a working group to adopt it, but the = nugget of your idea does come through. A couple of things need clarification: Who would issue the CLP? What = set of applications pay attention to that issuer? The LAMPS WG has alway had criteria that implementers are interested in = deploying the work item. Can you share any news on support for this = approach? Russ > On Jul 2, 2017, at 1:45 PM, Dmitry Belyavsky = wrote: >=20 > Hello, >=20 > I've uploaded a document decribing a proposal of changing the = certificate validation process for application needs.=20 > It provides more flexible way of trust limitations than CRL does. >=20 > Does the suggested document match a possible LAMPS rechartered = profile? >=20 > Thank you! >=20 > ---------- Forwarded message ---------- > From: > > Date: Sun, Jul 2, 2017 at 8:35 PM > Subject: New Version Notification for = draft-belyavskiy-certificate-limitation-policy-02.txt > To: Dmitry Belyavskiy > >=20 >=20 >=20 > A new version of I-D, = draft-belyavskiy-certificate-limitation-policy-02.txt > has been successfully submitted by Dmitry Belyavskiy and posted to the > IETF repository. >=20 > Name: draft-belyavskiy-certificate-limitation-policy > Revision: 02 > Title: Certificate Limitation Policy > Document date: 2017-07-01 > Group: Individual Submission > Pages: 6 > URL: = https://www.ietf.org/internet-drafts/draft-belyavskiy-certificate-limitati= on-policy-02.txt = > Status: = https://datatracker.ietf.org/doc/draft-belyavskiy-certificate-limitation-p= olicy/ = > Htmlized: = https://tools.ietf.org/html/draft-belyavskiy-certificate-limitation-policy= -02 = > Htmlized: = https://datatracker.ietf.org/doc/html/draft-belyavskiy-certificate-limitat= ion-policy-02 = > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-belyavskiy-certificate-limitatio= n-policy-02 = >=20 > Abstract: > The document provides a specification of the application-level = trust > model. Being provided at the application level, the limitations of > trust can be distributed separately using cryptographically = protected > format instead of hardcoding the checks into the application = itself. >=20 >=20 >=20 > The IETF Secretariat >=20 >=20 >=20 >=20 > --=20 > SY, Dmitry Belyavsky >=20 >=20 >=20 > --=20 > SY, Dmitry Belyavsky > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm --Apple-Mail=_63EDFB60-FB3B-43BC-83C8-D4F12ED8C020 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Dmitry:

This I-D is not complete enough for a working group to adopt = it, but the nugget of your idea does come through.

A couple of things need = clarification: Who would issue the CLP?  What set of applications = pay attention to that issuer?

The LAMPS WG has alway had criteria = that implementers are interested in deploying the work item.  Can = you share any news on support for this approach?

Russ


On Jul 2, 2017, at 1:45 PM, = Dmitry Belyavsky <beldmit@gmail.com> wrote:

Hello,

I've= uploaded a document decribing a proposal of changing the certificate validation process for = application needs. 
It provides more flexible way of = trust limitations than CRL does.

Does the = suggested document match a possible LAMPS rechartered = profile?

Thank you!

---------- Forwarded message = ----------
From: <internet-drafts@ietf.org>
Date: Sun, Jul 2, 2017 at 8:35 PM
Subject: New = Version Notification for draft-belyavskiy-certificate-limitation-policy-02.txt
To: Dmitry Belyavskiy = <beldmit@gmail.com>



A new version of I-D, draft-belyavskiy-certificate-limitation-policy-02.txt
has been successfully submitted by Dmitry Belyavskiy and posted to = the
IETF repository.

Name:          =  draft-belyavskiy-certificate-limitation-policy
Revision:       02
Title:          Certificate Limitation = Policy
Document date:  2017-07-01
Group:          Individual Submission
Pages:          6
URL:            https://www.ietf.org/internet-drafts/draft-belyavskiy-certificate-limitation-policy-02.txt
Status:         https://datatracker.ietf.org/doc/draft-belyavskiy-certificate-limitation-policy/
Htmlized:       https://tools.ietf.org/html/draft-belyavskiy-certificate-limitation-policy-02
Htmlized:       https://datatracker.ietf.org/doc/html/draft-belyavskiy-certificate-limitation-policy-02
Diff:           https://www.ietf.org/rfcdiff?url2=3Ddraft-belyavskiy-certificate-limitation-policy-02

Abstract:
   The document provides a specification of the = application-level trust
   model.  Being provided at the application level, the = limitations of
   trust can be distributed separately using cryptographically = protected
   format instead of hardcoding the checks into the = application itself.



 The IETF Secretariat



--
SY, Dmitry Belyavsky



--
SY, Dmitry Belyavsky
_______________________________________________
Spasm = mailing list
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm

= --Apple-Mail=_63EDFB60-FB3B-43BC-83C8-D4F12ED8C020-- From nobody Mon Jul 3 06:39:56 2017 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 DDA9E13161F for ; Mon, 3 Jul 2017 06:39:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, HTML_MESSAGE=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=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iO9F5aAs9oXm for ; Mon, 3 Jul 2017 06:39:52 -0700 (PDT) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC8161201FA for ; Mon, 3 Jul 2017 06:39:52 -0700 (PDT) Received: by mail-oi0-x22c.google.com with SMTP id x187so23270106oig.3 for ; Mon, 03 Jul 2017 06:39:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=PYVdSXdEfjGG4POmu2sE1w3UTgfHHYbR9MXi/QQKm84=; b=R4gR2IAOXU9L+zgO66ByGf0bfDVZt38F6PrjiFiFBheVJpaYeDAP/HFyfo67KV3hFN w2gkBnSUTVMnWL1jW5N/bvp+TWaQchSbj0Mv0+vQBADsvcUolPM4ro0La/hSl9wGbVf1 aM9HlD3QzujPT6pys65rko9DYflK0eGZ7AaGNKrIe3poq96utSiJN8yEuhV777ksncO0 CZ0B2Sug04PrBi+KtkQ+Rh1efdIzppAWd8qJZlOTc1SJU+CEsmiztiLw3XsWsRRmUlzS t2uVXZGeZJ7kEIHm62+ddhP+xzhfTi+oiQDul0OOUkvOdcpQvehtA9lEj2ZT0aO4nFbK 20OA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=PYVdSXdEfjGG4POmu2sE1w3UTgfHHYbR9MXi/QQKm84=; b=NoCza0VwaGXAaj3SvnCh9OiiUhh58RelzzTQVs0N7ljDOejP38Qn/V5u6I3vvMhsO6 iDU15UnzMOBb4dF7+eALBF0PgIHBSg4Eq5b8G2/mbJbwZIyOITfTa6l8Bnpc7+fGw0Yn 8SqIdqN+qgEh9VLoVUOdecsNjYmVzKg9GF9gNzXUI+Z1GuFOvGvAEMWqx98qtPDCu+yg nPRypTNTBtDEYfOkK1RMPbTNHgRQoi5BEpjQElEU6ccvLWgz/hVHJ58eCDFHIxx/fmOd 62eeUC12CbHR9zPtM1kToD3/v+ePZL0uMg+ArDsgqYzGAgGVqsP4iaBQwbnSSrwO98G5 tU1Q== X-Gm-Message-State: AIVw112n+okQmuNC71+tLS7ubpcqFInI9E3dDpIkK/U52t1iRDM23s1x CEY7V9kQKCisjZLQ/p6rRdgAl/XgvOe2 X-Received: by 10.202.184.196 with SMTP id i187mr1208769oif.162.1499089192073; Mon, 03 Jul 2017 06:39:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.237.18 with HTTP; Mon, 3 Jul 2017 06:39:51 -0700 (PDT) In-Reply-To: References: <149901692647.17218.7654069086751009731.idtracker@ietfa.amsl.com> From: Dmitry Belyavsky Date: Mon, 3 Jul 2017 16:39:51 +0300 Message-ID: To: Russ Housley Cc: LAMPS Content-Type: multipart/alternative; boundary="001a113cdd32c7c788055369e664" Archived-At: Subject: Re: [lamps] New Version Notification for draft-belyavskiy-certificate-limitation-policy-02.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 03 Jul 2017 13:39:55 -0000 --001a113cdd32c7c788055369e664 Content-Type: text/plain; charset="UTF-8" Dear Russ, Thank you for your attention! On Mon, Jul 3, 2017 at 4:25 PM, Russ Housley wrote: > Dmitry: > > This I-D is not complete enough for a working group to adopt it, but the > nugget of your idea does come through. > > A couple of things need clarification: Who would issue the CLP? What set > of applications pay attention to that issuer? > Any application vendor can issue the CLP. I expect that each vendor will issue CLPs for the purpose of his applications, though I suspect that, for example, if Google starts to issue CLPs, they will be widely used. > > The LAMPS WG has alway had criteria that implementers are interested in > deploying the work item. Can you share any news on support for this > approach? > Unfortunately no. If the draft is accepted in this or that way, I'll do my best to make it implemented in OpenSSL. > > Russ > > > On Jul 2, 2017, at 1:45 PM, Dmitry Belyavsky wrote: > > Hello, > > I've uploaded a document decribing a proposal of changing the certificate > validation process for application needs. > It provides more flexible way of trust limitations than CRL does. > > Does the suggested document match a possible LAMPS rechartered profile? > > Thank you! > > ---------- Forwarded message ---------- > From: > Date: Sun, Jul 2, 2017 at 8:35 PM > Subject: New Version Notification for draft-belyavskiy-certificate-l > imitation-policy-02.txt > To: Dmitry Belyavskiy > > > > A new version of I-D, draft-belyavskiy-certificate-l > imitation-policy-02.txt > has been successfully submitted by Dmitry Belyavskiy and posted to the > IETF repository. > > Name: draft-belyavskiy-certificate-limitation-policy > Revision: 02 > Title: Certificate Limitation Policy > Document date: 2017-07-01 > Group: Individual Submission > Pages: 6 > URL: https://www.ietf.org/internet- > drafts/draft-belyavskiy-certificate-limitation-policy-02.txt > Status: https://datatracker.ietf.org/ > doc/draft-belyavskiy-certificate-limitation-policy/ > Htmlized: https://tools.ietf.org/html/d > raft-belyavskiy-certificate-limitation-policy-02 > Htmlized: https://datatracker.ietf.org/ > doc/html/draft-belyavskiy-certificate-limitation-policy-02 > Diff: https://www.ietf.org/rfcdiff? > url2=draft-belyavskiy-certificate-limitation-policy-02 > > Abstract: > The document provides a specification of the application-level trust > model. Being provided at the application level, the limitations of > trust can be distributed separately using cryptographically protected > format instead of hardcoding the checks into the application itself. > > > > The IETF Secretariat > > > > > -- > SY, Dmitry Belyavsky > > > > -- > SY, Dmitry Belyavsky > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm > > > -- SY, Dmitry Belyavsky --001a113cdd32c7c788055369e664 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Russ,=C2=A0

Thank you for your att= ention!

On Mon= , Jul 3, 2017 at 4:25 PM, Russ Housley <housley@vigilsec.com> wrote:
Dmitry:

This I-D is not complete enough for a wor= king group to adopt it, but the nugget of your idea does come through.

A couple of things need clarification: Who would issue= the CLP?=C2=A0 What set of applications pay attention to that issuer?

Any application vendor can issue the CLP. I ex= pect that each vendor will issue CLPs for the purpose of his applications, = though I suspect that, for example, if Google starts to issue CLPs, they wi= ll be widely used.
=C2=A0

The LAMPS WG has alway= had criteria that implementers are interested in deploying the work item.= =C2=A0 Can you share any news on support for this approach?

Unfortunately no. If the draft is accepted in = this or that way, I'll do my best to make it implemented in OpenSSL.
=C2=A0

Russ


On Jul 2, 2017, at 1:45 P= M, Dmitry Belyavsky <beldmit@gmail.com> wrote:

Hello,

=
I've uploaded a document decribing=C2=A0a proposal of changing the certificate validation process for applic= ation needs.=C2=A0
It pro= vides more flexible way of trust limitations than CRL does.

Does the suggested document match a possible LAMPS recharter= ed profile?

Thank you!
=
---------- Forwarded message ---= -------
From: <<= a href=3D"mailto:internet-drafts@ietf.org" target=3D"_blank">internet-draft= s@ietf.org>
Date: Sun, Jul 2, 2017 at 8:35 PM
Subject: = New Version Notification for draft-belyavskiy-certificate-limitation-p= olicy-02.txt
To: Dmitry Belyavskiy <beldmit@gmail.com>



A new version of I-D, draft-belyavskiy-certificate-limitation-policy-0= 2.txt
has been successfully submitted by Dmitry Belyavskiy and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-belyavskiy-certificate-= limitation-policy
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A002
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Certificate Limitation Policy
Document date:=C2=A0 2017-07-01
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 6
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-draf= ts/draft-belyavskiy-certificate-limitation-policy-02.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-belyavskiy= -certificate-limitation-policy/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-belyavskiy-certificate-= limitation-policy-02
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-bel= yavskiy-certificate-limitation-policy-02
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddra= ft-belyavskiy-certificate-limitation-policy-02

Abstract:
=C2=A0 =C2=A0The document provides a specification of the application-level= trust
=C2=A0 =C2=A0model.=C2=A0 Being provided at the application level, the limi= tations of
=C2=A0 =C2=A0trust can be distributed separately using cryptographically pr= otected
=C2=A0 =C2=A0format instead of hardcoding the checks into the application i= tself.



 The IETF Secretariat




--
SY, Dmitry Belyavsky



--
SY, Dmitry Be= lyavsky
_______________________________________________
Spasm mailing list<= br>Spasm@ietf.orghttps://www.ietf.org/mailman/listinfo/spasm




--
SY, Dmitry Belyavsky
--001a113cdd32c7c788055369e664-- From nobody Wed Jul 5 16:18:22 2017 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 72C54129482 for ; Wed, 5 Jul 2017 16:18:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 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_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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=eff.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 YAxQv7SucjeO for ; Wed, 5 Jul 2017 16:18:18 -0700 (PDT) Received: from mail2.eff.org (mail2.eff.org [173.239.79.204]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 080BC12EC4A for ; Wed, 5 Jul 2017 16:18:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:References:Cc:To:From:Subject; bh=aZcsKhvwv9PaT9jEaxiBx/r+JSe500+WiM4FoBwbzVg=; b=X/pg1DwS/hwdnIuK0Q6tvND3eWFkiTktJPaxTp/4edCHI2kAH4rrVS7iHgGrOf1pGqlTpLdTWeCeonww/VcunJNGHMBK2kgkrpMdr533l6WgF1w7QxMdW64jqc+aiJtnMhuNtBfK9qb+0i9aaXbfGKMGB37U95geTEKcUhgh0Q4=; Received: ; Wed, 05 Jul 2017 16:18:16 -0700 From: Jacob Hoffman-Andrews To: Phillip Hallam-Baker , "Salz, Rich" Cc: SPASM , Rob Stradling References: <3c0da781-2586-647e-7332-c7233dd9570d@eff.org> <021b346f-966e-377b-a242-73d3613921b0@eff.org> <81cfd21c-e46a-29a3-d667-6e1b4a4bbbca@eff.org> <817edd56793e454aaa9759ba6ba03809@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: Date: Wed, 5 Jul 2017 16:18:16 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------B02D5E5835330155952E5ECE" Content-Language: en-US Received-SPF: skipped for local relay Archived-At: Subject: Re: [lamps] [Spasm] Erratum 4988 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 05 Jul 2017 23:18:20 -0000 This is a multi-part message in MIME format. --------------B02D5E5835330155952E5ECE Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit No comments in the last couple weeks. Phillip, would you like to write up the current version in a new erratum? On 06/23/2017 05:15 PM, Jacob Hoffman-Andrews wrote: > This version looks good to me. Good catch to whoever pointed out > Unbound's hard limit. And thanks to Phillip for pushing this through > multiple revisions. Any other thoughts from the list? > > On 06/22/2017 12:52 PM, Phillip Hallam-Baker wrote: >> >> In response to comments by a non list subscriber: >> >> >> s/follow the CNAME record/follow the CNAME record chain >> >> s/ten or fewer/8 or fewer/ >> >> >> The first is just for clarity and the second is because it turns out >> that unbound has a hard limit of 8 CNAME records to follow in a chain >> which provides a justification for a number that was previously >> arbitrary. >> >> >> If there is a revision of RFC1035 to specify a limit it will >> certainly follow unbound unless there is another library in common >> use with a different limit. >> >> >> >> Corrected Text >> >> -------------- >> >> Let CAA(X) be the record set returned in response to performing a CAA >> >> record query on the label X, P(X) be the DNS label immediately above >> >> X in the DNS hierarchy, and A(X) be the target of a CNAME or DNAME >> >> alias record chain specified at the label X. >> >> >> >> o If CAA(X) is not empty, R(X) = CAA (X), otherwise >> >> >> >> o If A(X) is not null, and CAA(A(X)) is not empty, then R(X) = >> >> CAA(A(X)), otherwise >> >> >> >> o If X is not a top-level domain, then R(X) = R(P(X)), otherwise >> >> >> >> o R(X) is empty. >> >> >> >> Thus, when a search at node X returns a CNAME record, the CA will >> >> follow the CNAME record chain to its target. If the target label >> >> contains a_ _CAA record, it is returned. >> >> >> ​O​ >> therwise, the CA continues the search at >> >> the parent of node X. >> >> >> >> Note that the search does not include the parent of a target of a >> >> CNAME record (except when the CNAME points back to its own path). >> >> >> >> To prevent resource exhaustion attacks, CAs should limit the length of >> >> CNAME chains that are accepted. However CAs MUST process CNAME >> >> chains that contain 8 or fewer CNAME records. >> >> >> On Wed, Jun 14, 2017 at 7:11 PM, Phillip Hallam-Baker >> > wrote: >> >> The RFC Editor has deleted all three of the existing errata. I >> would like for the next errata to be the very last. >> >> >> >> Could people read, review and state if this works for them? >> >> ​ This text is the same as the one I posted to CABForum earlier >> with the one exception being that I capitalized Otherwise in the >> place it needed it.​ >> >> >> >> >> Original Text >> >> ------------- >> >> Let CAA(X) be the record set returned in response to >> performing a CAA >> >> record query on the label X, P(X) be the DNS label immediately >> above >> >> X in the DNS hierarchy, and A(X) be the target of a CNAME or DNAME >> >> alias record specified at the label X. >> >> >> >> o If CAA(X) is not empty, R(X) = CAA (X), otherwise >> >> >> >> o If A(X) is not null, and R(A(X)) is not empty, then R(X) = >> >> R(A(X)), otherwise >> >> >> >> o If X is not a top-level domain, then R(X) = R(P(X)), otherwise >> >> >> >> o R(X) is empty. >> >> >> >> >> >> Corrected Text >> >> -------------- >> >> Let CAA(X) be the record set returned in response to >> performing a CAA >> >> record query on the label X, P(X) be the DNS label immediately >> above >> >> X in the DNS hierarchy, and A(X) be the target of a CNAME or DNAME >> >> alias record chain specified at the label X. >> >> >> >> o If CAA(X) is not empty, R(X) = CAA (X), otherwise >> >> >> >> o If A(X) is not null, and CAA(A(X)) is not empty, then R(X) = >> >> CAA(A(X)), otherwise >> >> >> >> o If X is not a top-level domain, then R(X) = R(P(X)), otherwise >> >> >> >> o R(X) is empty. >> >> >> >> Thus, when a search at node X returns a CNAME record, the CA will >> >> follow the CNAME record to its target. If the target label >> contains a >> >> CAA record, it is returned. >> >> ​O​ >> therwise, the CA continues the search at >> >> the parent of node X. >> >> >> >> Note that the search does not include the parent of a target of a >> >> CNAME record (except when the CNAME points back to its own path). >> >> >> >> To prevent resource exhaustion attacks, CAs should limit the >> length of >> >> CNAME chains that are accepted. However CAs MUST process CNAME >> >> chains that contain ten or fewer CNAME records. >> >> >> >> Processing for DNAME is exactly the same as for CNAME. Note >> that since >> >> DNAME records are implemented by creating the corresponding CNAME >> >> records on the fly, it is only necessary for DNAME records to >> appear >> >> on the wire for purposes of DNSSEC. >> >> >> >> >> _______________________________________________ >> Spasm mailing list >> Spasm@ietf.org >> https://www.ietf.org/mailman/listinfo/spasm > > > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm --------------B02D5E5835330155952E5ECE Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit No comments in the last couple weeks. Phillip, would you like to write up the current version in a new erratum?

On 06/23/2017 05:15 PM, Jacob Hoffman-Andrews wrote:
This version looks good to me. Good catch to whoever pointed out Unbound's hard limit. And thanks to Phillip for pushing this through multiple revisions. Any other thoughts from the list?

On 06/22/2017 12:52 PM, Phillip Hallam-Baker wrote:

In response to comments by a non list subscriber:


s/follow the CNAME record/follow the CNAME record chain

s/ten or fewer/8 or fewer/


The first is just for clarity and the second is because it turns out that unbound has a hard limit of 8 CNAME records to follow in a chain which provides a justification for a number that was previously arbitrary.


If there is a revision of RFC1035 to specify a limit it will certainly follow unbound unless there is another library in common use with a different limit.



Corrected Text

--------------

   Let CAA(X) be the record set returned in response to performing a CAA

   record query on the label X, P(X) be the DNS label immediately above

   X in the DNS hierarchy, and A(X) be the target of a CNAME or DNAME

   alias record chain specified at the label X.

 

   o  If CAA(X) is not empty, R(X) = CAA (X), otherwise

 

   o  If A(X) is not null, and CAA(A(X)) is not empty, then R(X) =

      CAA(A(X)), otherwise

 

   o  If X is not a top-level domain, then R(X) = R(P(X)), otherwise

 

   o  R(X) is empty.

 

  Thus, when a search at node X returns a CNAME record, the CA will

  follow the CNAME record chain to its target. If the target label 

  contains a CAA record, it is returned.

​O​
therwise, the CA continues the search at

  the parent of node X.

 

  Note that the search does not include the parent of a target of a

  CNAME record (except when the CNAME points back to its own path).

 

 To prevent resource exhaustion attacks, CAs should limit the length of

  CNAME chains that are accepted. However CAs MUST process CNAME

  chains that contain 8 or fewer CNAME records.


On Wed, Jun 14, 2017 at 7:11 PM, Phillip Hallam-Baker <phill@hallambaker.com> wrote:

The RFC Editor has deleted all three of the existing errata. I would like for the next errata to be the very last.

 

Could people read, review and state if this works for them?

​ This text is the same as the one I posted to CABForum earlier with the one exception being that I capitalized Otherwise in the place it needed it.​


 

Original Text

-------------

   Let CAA(X) be the record set returned in response to performing a CAA

   record query on the label X, P(X) be the DNS label immediately above

   X in the DNS hierarchy, and A(X) be the target of a CNAME or DNAME

   alias record specified at the label X.

 

   o  If CAA(X) is not empty, R(X) = CAA (X), otherwise

 

   o  If A(X) is not null, and R(A(X)) is not empty, then R(X) =

      R(A(X)), otherwise

 

   o  If X is not a top-level domain, then R(X) = R(P(X)), otherwise

 

   o  R(X) is empty.

 

 

Corrected Text

--------------

   Let CAA(X) be the record set returned in response to performing a CAA

   record query on the label X, P(X) be the DNS label immediately above

   X in the DNS hierarchy, and A(X) be the target of a CNAME or DNAME

   alias record chain specified at the label X.

 

   o  If CAA(X) is not empty, R(X) = CAA (X), otherwise

 

   o  If A(X) is not null, and CAA(A(X)) is not empty, then R(X) =

      CAA(A(X)), otherwise

 

   o  If X is not a top-level domain, then R(X) = R(P(X)), otherwise

 

   o  R(X) is empty.

 

  Thus, when a search at node X returns a CNAME record, the CA will

  follow the CNAME record to its target. If the target label contains a

  CAA record, it is returned.

​O​
therwise, the CA continues the search at

  the parent of node X.

 

  Note that the search does not include the parent of a target of a

  CNAME record (except when the CNAME points back to its own path).

 

 To prevent resource exhaustion attacks, CAs should limit the length of

  CNAME chains that are accepted. However CAs MUST process CNAME

  chains that contain ten or fewer CNAME records.

 

  Processing for DNAME is exactly the same as for CNAME. Note that since

  DNAME records are implemented by creating the corresponding CNAME

  records on the fly, it is only necessary for DNAME records to appear

  on the wire for purposes of DNSSEC.




_______________________________________________
Spasm mailing list
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm




_______________________________________________
Spasm mailing list
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm

--------------B02D5E5835330155952E5ECE-- From nobody Sat Jul 8 10:24:41 2017 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 1558B12EB97 for ; Sat, 8 Jul 2017 10:24:39 -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, HTML_MESSAGE=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 8-BZRz93zb51 for ; Sat, 8 Jul 2017 10:24: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 53445126C83 for ; Sat, 8 Jul 2017 10:24:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id A24E43004D7 for ; Sat, 8 Jul 2017 13:24:36 -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 O7FMXDZ6XVvk for ; Sat, 8 Jul 2017 13:24:34 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 77D9830029C; Sat, 8 Jul 2017 13:24:34 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_3F7909F1-18D6-4DE5-B49E-7F9943E446DD" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Russ Housley X-Priority: 1 In-Reply-To: Date: Sat, 8 Jul 2017 13:24:33 -0400 Cc: LAMPS Message-Id: <049652E8-3E86-470B-A803-B08F840B33AC@vigilsec.com> References: To: Quynh Dang X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [lamps] Recharter Discussion X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 08 Jul 2017 17:24:39 -0000 --Apple-Mail=_3F7909F1-18D6-4DE5-B49E-7F9943E446DD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thanks. Can you prepare a few slides for Prague. Include the proposed text for = the re-charter in the slides along with proposed milestones for two = documents. Russ > On Jul 3, 2017, at 7:34 AM, Dang, Quynh (Fed) = wrote: >=20 > Hi all,=20 >=20 > For item 4a:=20 >=20 > Keccak and SHA-3 functions (including all the FIPS 202 and SP 800-185 = functions) are the outcome of an open competition, unlike the previous = hashing standards. They have a clear design rationale and have been = receiving a lot of public cryptanalysis during and after the SHA-3 = competition to today. All of that gives great confidence that the SHA-3s = are very secure. The SHA3s also have much larger security margins than = SHA-2s. In addition, since the design of the SHA3s is very different = from SHA-2s (and other ARX-based designs), they offer sane diversity for = security. Therefore, the SHA-3s are excellent alternatives for SHA2s.=20 >=20 > Regards, > Quynh.=20 >=20 > From: Spasm on behalf of Russ Housley = > Sent: Sunday, June 25, 2017 12:25 PM > To: LAMPS > Subject: [lamps] Recharter Discussion > =20 > We have almost finished the last document under the current charter. = We will beed to deal with any concerns raised by the IESG, but we should = starts drafting the next version of the charter while that is happening. = In Chicago, we talked about several possible topics for the re-charter: >=20 >=20 > 4c) OCSP response extension for revocation hint text (Rich) >=20 > Rich withdrew his support for this one. Unless someone else wants to = step in, this one will be dropped. >=20 >=20 > 4b) Updates to CAA for RFC Erratum 4514 (Phill) >=20 > HUM: Consensus in the room to suggest this for a future LAMPS WG = charter. Please propose a paragraph for the charter. >=20 >=20 > 4a) Adding SHA3 to PKIX and S/MIME (Sean) >=20 > HUM: Many people in the room to suggest this as a topic for a future > LAMPS WG charter; however, a significant number thought it should = not > be done. >=20 > Many people thought that SHA-256, SHA-384, and SHA-512 filled this = need. If you would like to see it move forward, please propose a = paragraph for the charter. >=20 >=20 > Are there any other topics that someone would like to raise now? All = three of the above topics had at least one document to support them. = So, new topics should come with an Internet-Draft or a promise of one = before the I-D cutoff for Prague. >=20 > Russ >=20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm = --Apple-Mail=_3F7909F1-18D6-4DE5-B49E-7F9943E446DD Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Thanks.

Can you prepare a few slides for Prague.  Include the proposed text for the re-charter in the slides along with proposed milestones for two documents.

Russ


On Jul 3, 2017, at 7:34 AM, Dang, Quynh (Fed) <quynh.dang@nist.gov> wrote:

Hi all, 


For item 4a: 


Keccak and SHA-3 functions (including all the FIPS 202 and SP 800-185 functions) are the outcome of an open competition, unlike the previous hashing standards. They have a clear design rationale and have been receiving a lot of public cryptanalysis during and after the SHA-3 competition to today. All of that gives great confidence that the SHA-3s are very secure. The SHA3s also have much larger security margins than SHA-2s. In addition, since the design of the SHA3s is very different from SHA-2s (and other ARX-based designs), they offer sane diversity for security. Therefore, the SHA-3s are excellent alternatives for SHA2s. 

Regards,

Quynh. 


From: Spasm <spasm-bounces@ietf.org> on behalf of Russ Housley <housley@vigilsec.com>
Sent: Sunday, June 25, 2017 12:25 PM
To: LAMPS
Subject: [lamps] Recharter Discussion
 
We have almost finished the last document under the current charter.  We will beed to deal with any concerns raised by the IESG, but we should starts drafting the next version of the charter while that is happening.  In Chicago, we talked about several possible topics for the re-charter:


4c)  OCSP response extension for revocation hint text (Rich)

Rich withdrew his support for this one.  Unless someone else wants to step in, this one will be dropped.


4b)  Updates to CAA for RFC Erratum 4514 (Phill)

HUM: Consensus in the room to suggest this for a future LAMPS WG charter.  Please propose a paragraph for the charter.


4a)  Adding SHA3 to PKIX and S/MIME (Sean)

HUM: Many people in the room to suggest this as a topic for a future
  LAMPS WG charter; however, a significant number thought it should not
  be done.

Many people thought that SHA-256, SHA-384, and SHA-512 filled this need.  If you would like to see it move forward, please propose a paragraph for the charter.


Are there any other topics that someone would like to raise now?  All three of the above topics had at least one document to support them.  So, new topics should come with an Internet-Draft or a promise of one before the I-D cutoff for Prague.

Russ

_______________________________________________
Spasm mailing list
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm

--Apple-Mail=_3F7909F1-18D6-4DE5-B49E-7F9943E446DD-- From nobody Sun Jul 9 14:24:44 2017 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 3FB61126C7A for ; Sun, 9 Jul 2017 14:24:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 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_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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=eff.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 MguuvPeisrNz for ; Sun, 9 Jul 2017 14:24:42 -0700 (PDT) Received: from mail2.eff.org (mail2.eff.org [173.239.79.204]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 100C41242F5 for ; Sun, 9 Jul 2017 14:24:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:References:Cc:To:From:Subject; bh=rTriACtlXmN3Rb0P4v0MhzcJ9fHrVekflzYuIgC0ro4=; b=PGZVX8AYUNgHrfjCiXeR/tXlRC7iawEXzkgZfxqjrtt1zTRUSYk3uNPq3htZ28njuZXsY8D0ckqa5Brx4Gtq0zxt0amKUqxPmixsEDtOJutcfuHQ+b4mSLR+zTY0NijHlMHTqbPxkAswS9zBKRmAWMAMCZxtawroMrzFqqOFmuY=; Received: ; Sun, 09 Jul 2017 14:24:39 -0700 From: Jacob Hoffman-Andrews To: Phillip Hallam-Baker , "Salz, Rich" Cc: SPASM , Rob Stradling References: <3c0da781-2586-647e-7332-c7233dd9570d@eff.org> <021b346f-966e-377b-a242-73d3613921b0@eff.org> <81cfd21c-e46a-29a3-d667-6e1b4a4bbbca@eff.org> <817edd56793e454aaa9759ba6ba03809@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <1fdb01e8-8232-944b-2323-709deccc9e11@eff.org> Date: Sun, 9 Jul 2017 14:24:34 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------8A77FF9EADB6B50E427E2245" Content-Language: en-US Archived-At: Subject: Re: [lamps] [Spasm] Erratum 4988 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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: Sun, 09 Jul 2017 21:24:44 -0000 This is a multi-part message in MIME format. --------------8A77FF9EADB6B50E427E2245 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Ping on this? On 06/23/2017 05:15 PM, Jacob Hoffman-Andrews wrote: > This version looks good to me. Good catch to whoever pointed out > Unbound's hard limit. And thanks to Phillip for pushing this through > multiple revisions. Any other thoughts from the list? > > On 06/22/2017 12:52 PM, Phillip Hallam-Baker wrote: >> >> In response to comments by a non list subscriber: >> >> >> s/follow the CNAME record/follow the CNAME record chain >> >> s/ten or fewer/8 or fewer/ >> >> >> The first is just for clarity and the second is because it turns out >> that unbound has a hard limit of 8 CNAME records to follow in a chain >> which provides a justification for a number that was previously >> arbitrary. >> >> >> If there is a revision of RFC1035 to specify a limit it will >> certainly follow unbound unless there is another library in common >> use with a different limit. >> >> >> >> Corrected Text >> >> -------------- >> >> Let CAA(X) be the record set returned in response to performing a CAA >> >> record query on the label X, P(X) be the DNS label immediately above >> >> X in the DNS hierarchy, and A(X) be the target of a CNAME or DNAME >> >> alias record chain specified at the label X. >> >> >> >> o If CAA(X) is not empty, R(X) = CAA (X), otherwise >> >> >> >> o If A(X) is not null, and CAA(A(X)) is not empty, then R(X) = >> >> CAA(A(X)), otherwise >> >> >> >> o If X is not a top-level domain, then R(X) = R(P(X)), otherwise >> >> >> >> o R(X) is empty. >> >> >> >> Thus, when a search at node X returns a CNAME record, the CA will >> >> follow the CNAME record chain to its target. If the target label >> >> contains a_ _CAA record, it is returned. >> >> >> ​O​ >> therwise, the CA continues the search at >> >> the parent of node X. >> >> >> >> Note that the search does not include the parent of a target of a >> >> CNAME record (except when the CNAME points back to its own path). >> >> >> >> To prevent resource exhaustion attacks, CAs should limit the length of >> >> CNAME chains that are accepted. However CAs MUST process CNAME >> >> chains that contain 8 or fewer CNAME records. >> >> >> On Wed, Jun 14, 2017 at 7:11 PM, Phillip Hallam-Baker >> > wrote: >> >> The RFC Editor has deleted all three of the existing errata. I >> would like for the next errata to be the very last. >> >> >> >> Could people read, review and state if this works for them? >> >> ​ This text is the same as the one I posted to CABForum earlier >> with the one exception being that I capitalized Otherwise in the >> place it needed it.​ >> >> >> >> >> Original Text >> >> ------------- >> >> Let CAA(X) be the record set returned in response to >> performing a CAA >> >> record query on the label X, P(X) be the DNS label immediately >> above >> >> X in the DNS hierarchy, and A(X) be the target of a CNAME or DNAME >> >> alias record specified at the label X. >> >> >> >> o If CAA(X) is not empty, R(X) = CAA (X), otherwise >> >> >> >> o If A(X) is not null, and R(A(X)) is not empty, then R(X) = >> >> R(A(X)), otherwise >> >> >> >> o If X is not a top-level domain, then R(X) = R(P(X)), otherwise >> >> >> >> o R(X) is empty. >> >> >> >> >> >> Corrected Text >> >> -------------- >> >> Let CAA(X) be the record set returned in response to >> performing a CAA >> >> record query on the label X, P(X) be the DNS label immediately >> above >> >> X in the DNS hierarchy, and A(X) be the target of a CNAME or DNAME >> >> alias record chain specified at the label X. >> >> >> >> o If CAA(X) is not empty, R(X) = CAA (X), otherwise >> >> >> >> o If A(X) is not null, and CAA(A(X)) is not empty, then R(X) = >> >> CAA(A(X)), otherwise >> >> >> >> o If X is not a top-level domain, then R(X) = R(P(X)), otherwise >> >> >> >> o R(X) is empty. >> >> >> >> Thus, when a search at node X returns a CNAME record, the CA will >> >> follow the CNAME record to its target. If the target label >> contains a >> >> CAA record, it is returned. >> >> ​O​ >> therwise, the CA continues the search at >> >> the parent of node X. >> >> >> >> Note that the search does not include the parent of a target of a >> >> CNAME record (except when the CNAME points back to its own path). >> >> >> >> To prevent resource exhaustion attacks, CAs should limit the >> length of >> >> CNAME chains that are accepted. However CAs MUST process CNAME >> >> chains that contain ten or fewer CNAME records. >> >> >> >> Processing for DNAME is exactly the same as for CNAME. Note >> that since >> >> DNAME records are implemented by creating the corresponding CNAME >> >> records on the fly, it is only necessary for DNAME records to >> appear >> >> on the wire for purposes of DNSSEC. >> >> >> >> >> _______________________________________________ >> Spasm mailing list >> Spasm@ietf.org >> https://www.ietf.org/mailman/listinfo/spasm > > > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm --------------8A77FF9EADB6B50E427E2245 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Ping on this?

On 06/23/2017 05:15 PM, Jacob Hoffman-Andrews wrote:
This version looks good to me. Good catch to whoever pointed out Unbound's hard limit. And thanks to Phillip for pushing this through multiple revisions. Any other thoughts from the list?

On 06/22/2017 12:52 PM, Phillip Hallam-Baker wrote:

In response to comments by a non list subscriber:


s/follow the CNAME record/follow the CNAME record chain

s/ten or fewer/8 or fewer/


The first is just for clarity and the second is because it turns out that unbound has a hard limit of 8 CNAME records to follow in a chain which provides a justification for a number that was previously arbitrary.


If there is a revision of RFC1035 to specify a limit it will certainly follow unbound unless there is another library in common use with a different limit.



Corrected Text

--------------

   Let CAA(X) be the record set returned in response to performing a CAA

   record query on the label X, P(X) be the DNS label immediately above

   X in the DNS hierarchy, and A(X) be the target of a CNAME or DNAME

   alias record chain specified at the label X.

 

   o  If CAA(X) is not empty, R(X) = CAA (X), otherwise

 

   o  If A(X) is not null, and CAA(A(X)) is not empty, then R(X) =

      CAA(A(X)), otherwise

 

   o  If X is not a top-level domain, then R(X) = R(P(X)), otherwise

 

   o  R(X) is empty.

 

  Thus, when a search at node X returns a CNAME record, the CA will

  follow the CNAME record chain to its target. If the target label 

  contains a CAA record, it is returned.

​O​
therwise, the CA continues the search at

  the parent of node X.

 

  Note that the search does not include the parent of a target of a

  CNAME record (except when the CNAME points back to its own path).

 

 To prevent resource exhaustion attacks, CAs should limit the length of

  CNAME chains that are accepted. However CAs MUST process CNAME

  chains that contain 8 or fewer CNAME records.


On Wed, Jun 14, 2017 at 7:11 PM, Phillip Hallam-Baker <phill@hallambaker.com> wrote:

The RFC Editor has deleted all three of the existing errata. I would like for the next errata to be the very last.

 

Could people read, review and state if this works for them?

​ This text is the same as the one I posted to CABForum earlier with the one exception being that I capitalized Otherwise in the place it needed it.​


 

Original Text

-------------

   Let CAA(X) be the record set returned in response to performing a CAA

   record query on the label X, P(X) be the DNS label immediately above

   X in the DNS hierarchy, and A(X) be the target of a CNAME or DNAME

   alias record specified at the label X.

 

   o  If CAA(X) is not empty, R(X) = CAA (X), otherwise

 

   o  If A(X) is not null, and R(A(X)) is not empty, then R(X) =

      R(A(X)), otherwise

 

   o  If X is not a top-level domain, then R(X) = R(P(X)), otherwise

 

   o  R(X) is empty.

 

 

Corrected Text

--------------

   Let CAA(X) be the record set returned in response to performing a CAA

   record query on the label X, P(X) be the DNS label immediately above

   X in the DNS hierarchy, and A(X) be the target of a CNAME or DNAME

   alias record chain specified at the label X.

 

   o  If CAA(X) is not empty, R(X) = CAA (X), otherwise

 

   o  If A(X) is not null, and CAA(A(X)) is not empty, then R(X) =

      CAA(A(X)), otherwise

 

   o  If X is not a top-level domain, then R(X) = R(P(X)), otherwise

 

   o  R(X) is empty.

 

  Thus, when a search at node X returns a CNAME record, the CA will

  follow the CNAME record to its target. If the target label contains a

  CAA record, it is returned.

​O​
therwise, the CA continues the search at

  the parent of node X.

 

  Note that the search does not include the parent of a target of a

  CNAME record (except when the CNAME points back to its own path).

 

 To prevent resource exhaustion attacks, CAs should limit the length of

  CNAME chains that are accepted. However CAs MUST process CNAME

  chains that contain ten or fewer CNAME records.

 

  Processing for DNAME is exactly the same as for CNAME. Note that since

  DNAME records are implemented by creating the corresponding CNAME

  records on the fly, it is only necessary for DNAME records to appear

  on the wire for purposes of DNSSEC.




_______________________________________________
Spasm mailing list
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm




_______________________________________________
Spasm mailing list
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm

--------------8A77FF9EADB6B50E427E2245-- From nobody Mon Jul 10 05:06:17 2017 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 A4AD7131703 for ; Mon, 10 Jul 2017 05:06:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cwNAVN9E2F-v for ; Mon, 10 Jul 2017 05:06:09 -0700 (PDT) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0090.outbound.protection.outlook.com [23.103.200.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58F881316FC for ; Mon, 10 Jul 2017 05:06:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=zzGQgZ4vgzYu5NNFg7EdWRPfWzfctwGRiyMOXNN/Uaw=; b=13DuekmYR+9WfRsVm/T1WV3eKTuHw4AAUBXOiGMN1feaggoBoYZw2AxkOGdcp54NiCQuZRsYiL0jQYSvXRVkm5k0SlrH7rkMGBCI3I5UA6WRgL5xSlrj/76dsA/YX7aQS7THiiLhpyNF4y/ri2KRCmg8L0KSPfuJ4qhQ5uE86p8= Received: from CY4PR09MB1464.namprd09.prod.outlook.com (10.173.191.22) by CY4PR09MB1461.namprd09.prod.outlook.com (10.173.191.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1240.13; Mon, 10 Jul 2017 12:06:08 +0000 Received: from CY4PR09MB1464.namprd09.prod.outlook.com ([10.173.191.22]) by CY4PR09MB1464.namprd09.prod.outlook.com ([10.173.191.22]) with mapi id 15.01.1240.020; Mon, 10 Jul 2017 12:06:07 +0000 From: "Dang, Quynh (Fed)" To: Russ Housley CC: LAMPS Thread-Topic: [lamps] Recharter Discussion Thread-Index: AQHS7c+w+/1+zWpP/UquALFLepULLqJCAIiTgAhB+YCAAsti4Q== Date: Mon, 10 Jul 2017 12:06:07 +0000 Message-ID: References: , <049652E8-3E86-470B-A803-B08F840B33AC@vigilsec.com> In-Reply-To: <049652E8-3E86-470B-A803-B08F840B33AC@vigilsec.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: vigilsec.com; dkim=none (message not signed) header.d=none;vigilsec.com; dmarc=none action=none header.from=nist.gov; x-originating-ip: [129.6.105.150] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR09MB1461; 7:0nDEx7MTP1Cu2FH39rSxPuPOZk+zpk04dZU3H+8Nxgm4FEd7IURi8V6soDCyCfv0XIfSacH6sKRnVeX+HcdFTooejuCWVwZ1BUUEaJ3N7fSmZikTjvxbu+SdsobkI6VqFpsDNrRYZTrC9VMYekN7CCbFfw1RoIqR3LgDaq44QuVNkrCSYQrOqDmzDlrIs0IvmzB6KBal0bZwX5vf3b+SRiSryqSTsjbxPIGYHfBgCWVi+wsvYUlrCNULUkYe2/MefaaGw3Bp3ahf68MqtadLBbrdhfxfFrT2SvMbcmqBjiJ05/aVBpnNKXtGrM98MJWsgadnspF/gzYtpgSk3A6rGTo2y/I6HUHYT6u8KKnngG14ZY0TBUKp8eYZoahzeJYohPK9lsgBAmDEX5sx4YYu+Y+PiCgUEsRvoVDaOXwPmEP0uIqhc3+mtGCiAkU63Q+094CIK4S1XL/lTut//GcpaCdUmspUKWucAquOYX72R0+CA/uxZ/fW1nnTBCVDE5zgJFDT2EtPjlslxsthv4pnl1gfvwWGbTgaEqeOi7jiVltUDyTUZICwz3WMvad3lq0rl4ksyuz2tKtYdlcOhe3f/TbkjlukEOWpu7E3ecu8y9MtkUcCj/EBqoiZaZt6GJE+OyA1feug/pcybGIZSuHSSjrvM37fz/EKSjAdR+Zc1CxDvqfjPcXUn5vzyGWAecqNPttskK9J7qO2uLhlwNrNScPFTHiw7keW4hDRzqe9C1uwrkkb6DJLUrIj/DNNSnf9m3TvzlGWiI1xVCS7DpsB+tMvQt6pcIML/o9O9/f/oDA= x-ms-office365-filtering-correlation-id: 16f2b312-aaee-454b-8289-08d4c78c0bf6 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(48565401081)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY4PR09MB1461; x-ms-traffictypediagnostic: CY4PR09MB1461: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278178393323532)(65766998875637)(133145235818549)(236129657087228)(192374486261705)(100405760836317)(148574349560750)(247924648384137); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(2017060910075)(93006095)(93001095)(10201501046)(3002001)(100000703101)(100105400095)(6055026)(6041248)(20161123562025)(20161123560025)(20161123555025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR09MB1461; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR09MB1461; x-forefront-prvs: 03648EFF89 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39450400003)(39840400002)(39410400002)(39400400002)(39850400002)(24454002)(53754006)(377454003)(86362001)(53936002)(77096006)(6246003)(2950100002)(2906002)(8936002)(9686003)(55016002)(19627405001)(2900100001)(74316002)(54896002)(6306002)(236005)(53546010)(99286003)(66066001)(3660700001)(3280700002)(606006)(6916009)(50986999)(76176999)(966005)(189998001)(38730400002)(54356999)(478600001)(6436002)(33656002)(3846002)(4326008)(5660300001)(102836003)(25786009)(7696004)(229853002)(7736002)(6506006)(81166006)(110136004)(8676002)(6116002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR09MB1461; H:CY4PR09MB1464.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR09MB14641BBF1BEABFF818435BB0F3A90CY4PR09MB1464namp_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jul 2017 12:06:07.4886 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR09MB1461 Archived-At: Subject: Re: [lamps] Recharter Discussion X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 10 Jul 2017 12:06:16 -0000 --_000_CY4PR09MB14641BBF1BEABFF818435BB0F3A90CY4PR09MB1464namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sure, I will make a few slides for the group to discuss at the meeting. Regards, Quynh. ________________________________ From: Russ Housley Sent: Saturday, July 8, 2017 1:24:33 PM To: Dang, Quynh (Fed) Cc: LAMPS Subject: Re: [lamps] Recharter Discussion Thanks. Can you prepare a few slides for Prague. Include the proposed text for the= re-charter in the slides along with proposed milestones for two documents. Russ On Jul 3, 2017, at 7:34 AM, Dang, Quynh (Fed) > wrote: Hi all, For item 4a: Keccak and SHA-3 functions (including all the FIPS 202 and SP 800-185 funct= ions) are the outcome of an open competition, unlike the previous hashing s= tandards. They have a clear design rationale and have been receiving a lot = of public cryptanalysis during and after the SHA-3 competition to today. Al= l of that gives great confidence that the SHA-3s are very secure. The SHA3s= also have much larger security margins than SHA-2s. In addition, since the= design of the SHA3s is very different from SHA-2s (and other ARX-based des= igns), they offer sane diversity for security. Therefore, the SHA-3s are ex= cellent alternatives for SHA2s. Regards, Quynh. ________________________________ From: Spasm > on beha= lf of Russ Housley > Sent: Sunday, June 25, 2017 12:25 PM To: LAMPS Subject: [lamps] Recharter Discussion We have almost finished the last document under the current charter. We wi= ll beed to deal with any concerns raised by the IESG, but we should starts = drafting the next version of the charter while that is happening. In Chica= go, we talked about several possible topics for the re-charter: 4c) OCSP response extension for revocation hint text (Rich) Rich withdrew his support for this one. Unless someone else wants to step = in, this one will be dropped. 4b) Updates to CAA for RFC Erratum 4514 (Phill) HUM: Consensus in the room to suggest this for a future LAMPS WG charter. = Please propose a paragraph for the charter. 4a) Adding SHA3 to PKIX and S/MIME (Sean) HUM: Many people in the room to suggest this as a topic for a future LAMPS WG charter; however, a significant number thought it should not be done. Many people thought that SHA-256, SHA-384, and SHA-512 filled this need. I= f you would like to see it move forward, please propose a paragraph for the= charter. Are there any other topics that someone would like to raise now? All three= of the above topics had at least one document to support them. So, new to= pics should come with an Internet-Draft or a promise of one before the I-D = cutoff for Prague. Russ _______________________________________________ Spasm mailing list Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm --_000_CY4PR09MB14641BBF1BEABFF818435BB0F3A90CY4PR09MB1464namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Sure,


I will make a few slides for the group to discuss at the meeting.


Regards,

Quynh. 

From: Russ Housley <hous= ley@vigilsec.com>
Sent: Saturday, July 8, 2017 1:24:33 PM
To: Dang, Quynh (Fed)
Cc: LAMPS
Subject: Re: [lamps] Recharter Discussion
 
Thanks.

Can you prepare a few slides for Prague.  Include the = proposed text for the re-charter in the slides along with proposed mileston= es for two documents.

Russ


On Jul 3, 2017, at 7:34 AM, Dang, Quynh (Fed) <quynh.dang@nist.gov> wrot= e:

Hi all, 


For item 4a: 


Keccak and SHA-3 functions (including all the FIPS 202 and = SP 800-185 functions) are the outcome of an open competition, unlike the pr= evious hashing standards. They have a clear design rationale and have been = receiving a lot of public cryptanalysis during and after the SHA-3 competition to today. All of that gives great c= onfidence that the SHA-3s are very secure. The SHA3s also have much larger = security margins than SHA-2s. In addition, since the design of the SHA3s is= very different from SHA-2s (and other ARX-based designs), they offer sane diversity for security. Therefor= e, the SHA-3s are excellent alternatives for SHA2s. 

Regards,

Quynh. 


From: Spas= m <spasm-bounces@ie= tf.org> on behalf of Russ Housley <housley@vigilsec.com>
Sent: Sunday, June 25, 2017 12:25 PM
To: LAMPS
Subject: [lamps] Recharter Discussion
 
We have almost finished the last document under th= e current charter.  We will beed to deal with any concerns raised by t= he IESG, but we should starts drafting the next version of the charter whil= e that is happening.  In Chicago, we talked about several possible topics for the re-charter:


4c)  OCSP response extension for revocation hint text (Rich)

Rich withdrew his support for this one.  Unless someone else wants to = step in, this one will be dropped.


4b)  Updates to CAA for RFC Erratum 4514 (Phill)

HUM: Consensus in the room to suggest this for a future LAMPS WG charter.&n= bsp; Please propose a paragraph for the charter.


4a)  Adding SHA3 to PKIX and S/MIME (Sean)

HUM: Many people in the room to suggest this as a topic for a future
  LAMPS WG charter; however, a significant number thought it should no= t
  be done.

Many people thought that SHA-256, SHA-384, and SHA-512 filled this need.&nb= sp; If you would like to see it move forward, please propose a paragraph fo= r the charter.


Are there any other topics that someone would like to raise now?  All = three of the above topics had at least one document to support them.  = So, new topics should come with an Internet-Draft or a promise of one befor= e the I-D cutoff for Prague.

Russ

_______________________________________________
Spasm mailing list
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/sp= asm

--_000_CY4PR09MB14641BBF1BEABFF818435BB0F3A90CY4PR09MB1464namp_-- From nobody Mon Jul 10 08:08:08 2017 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 0AC98127868 for ; Mon, 10 Jul 2017 08:08:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZgoZk3fzzI_k for ; Mon, 10 Jul 2017 08:08:00 -0700 (PDT) Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::232]) (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 0560C131535 for ; Mon, 10 Jul 2017 08:08:00 -0700 (PDT) Received: by mail-lf0-x232.google.com with SMTP id z78so64354607lff.0 for ; Mon, 10 Jul 2017 08:07:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=RSU5pQpdYgKXk6yIeJmTrWJWviXuDjHD2rA5lfdRIQs=; b=RXx2R/WQadxvxOXkvc0DYzPH0Eic7lECfLQCB12fXRy5RdnB1W4bJD99J6wN8Fy0YX gxP/oQzc1iNI3cmqTTaHEnS9vA1gEWYew1YEZiKje5rk3qwcXNaTeqyfClt9R5E/3AsB SMugxmU/F5Sw8fatDjYvyY2/hjHCTwkTd8XdaVnJa1odENdP+GBx2OmpcMzVJ5velUG3 MZxLt+xgY8hyS5reEpHDMowRwesUm4ZReYAFWiHGHjzZuKyWIfdE/A8VvRWaayi/o1xA vthiufbWR/5bOlUJrtzMQWab9Or41TJoaMkrLVMpofPrv9tSZSMkhrpeA3B7W9vwbW+B ljSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=RSU5pQpdYgKXk6yIeJmTrWJWviXuDjHD2rA5lfdRIQs=; b=FOYNvFimCDTJr2CwN/jAW/KIIi0Lsw3z6bwDXDW15mqUcKnI709CdU4kxpsqKXIaZy V4W/5vojHHLQq/tRsAGM15zZhbUKyIyxYy3pne28qep7Jxm+5X9uG1dG+Tl7QHY7dCwd rlWAcNMMp1HgAdem1X93i5yki4eRnZxh5FWI5hOkBWI39S1m5ZbaYsiLZCYKhdD/WnO0 lg6AcT+TWyjZTsPSe2HNtAHNCI7zovP9tNawGnIlIgwM66y07r+lZmarL5ItnfTHedan U4QP7QUScBRUgl4dbu3O8bNrv5GxnwI6fGDSjvzTXNbkKe2aQXWc9u7LgBOsI5acTzWZ MIMg== X-Gm-Message-State: AIVw110rw0r4WhM5x5MbX8GNqgAnha3GbK1kVX+Cx9xpT/66HH6YI8sK 7nA4QeFX9znuXRCVbI7tNSPyZBf9TQCe X-Received: by 10.25.207.85 with SMTP id f82mr1526836lfg.2.1499699278225; Mon, 10 Jul 2017 08:07:58 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.25.181.214 with HTTP; Mon, 10 Jul 2017 08:07:57 -0700 (PDT) In-Reply-To: <1fdb01e8-8232-944b-2323-709deccc9e11@eff.org> References: <3c0da781-2586-647e-7332-c7233dd9570d@eff.org> <021b346f-966e-377b-a242-73d3613921b0@eff.org> <81cfd21c-e46a-29a3-d667-6e1b4a4bbbca@eff.org> <817edd56793e454aaa9759ba6ba03809@usma1ex-dag1mb1.msg.corp.akamai.com> <1fdb01e8-8232-944b-2323-709deccc9e11@eff.org> From: Phillip Hallam-Baker Date: Mon, 10 Jul 2017 11:07:57 -0400 X-Google-Sender-Auth: IIagHVTwkqHdgP9AE4sL02WQA8I Message-ID: To: Jacob Hoffman-Andrews Cc: "Salz, Rich" , SPASM , Rob Stradling Content-Type: multipart/alternative; boundary="001a11411e2cbfa8840553f7f24c" Archived-At: Subject: Re: [lamps] [Spasm] Erratum 4988 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 10 Jul 2017 15:08:06 -0000 --001a11411e2cbfa8840553f7f24c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable https://www.rfc-editor.org/errata/eid5065 I did change the should to a SHOULD as the context was obviously normative. Not that it makes much difference.. I will talk to the RFC Editor staff in Prague and anyone else who might need to approve getting the status set to Held for Document Update On Sun, Jul 9, 2017 at 5:24 PM, Jacob Hoffman-Andrews wrote: > Ping on this? > > On 06/23/2017 05:15 PM, Jacob Hoffman-Andrews wrote: > > This version looks good to me. Good catch to whoever pointed out Unbound'= s > hard limit. And thanks to Phillip for pushing this through multiple > revisions. Any other thoughts from the list? > > On 06/22/2017 12:52 PM, Phillip Hallam-Baker wrote: > > In response to comments by a non list subscriber: > > > s/follow the CNAME record/follow the CNAME record chain > > s/ten or fewer/8 or fewer/ > > > The first is just for clarity and the second is because it turns out that > unbound has a hard limit of 8 CNAME records to follow in a chain which > provides a justification for a number that was previously arbitrary. > > > If there is a revision of RFC1035 to specify a limit it will certainly > follow unbound unless there is another library in common use with a > different limit. > > > > Corrected Text > > -------------- > > Let CAA(X) be the record set returned in response to performing a CAA > > record query on the label X, P(X) be the DNS label immediately above > > X in the DNS hierarchy, and A(X) be the target of a CNAME or DNAME > > alias record chain specified at the label X. > > > > o If CAA(X) is not empty, R(X) =3D CAA (X), otherwise > > > > o If A(X) is not null, and CAA(A(X)) is not empty, then R(X) =3D > > CAA(A(X)), otherwise > > > > o If X is not a top-level domain, then R(X) =3D R(P(X)), otherwise > > > > o R(X) is empty. > > > > Thus, when a search at node X returns a CNAME record, the CA will > > follow the CNAME record chain to its target. If the target label > > contains a CAA record, it is returned. > > =E2=80=8BO=E2=80=8B > therwise, the CA continues the search at > > the parent of node X. > > > > Note that the search does not include the parent of a target of a > > CNAME record (except when the CNAME points back to its own path). > > > > To prevent resource exhaustion attacks, CAs should limit the length of > > CNAME chains that are accepted. However CAs MUST process CNAME > > chains that contain 8 or fewer CNAME records. > > On Wed, Jun 14, 2017 at 7:11 PM, Phillip Hallam-Baker < > phill@hallambaker.com> wrote: > >> The RFC Editor has deleted all three of the existing errata. I would lik= e >> for the next errata to be the very last. >> >> >> >> Could people read, review and state if this works for them? >> =E2=80=8B This text is the same as the one I posted to CABForum earlier = with the >> one exception being that I capitalized Otherwise in the place it needed = it.=E2=80=8B >> >> >> >> >> Original Text >> >> ------------- >> >> Let CAA(X) be the record set returned in response to performing a CAA >> >> record query on the label X, P(X) be the DNS label immediately above >> >> X in the DNS hierarchy, and A(X) be the target of a CNAME or DNAME >> >> alias record specified at the label X. >> >> >> >> o If CAA(X) is not empty, R(X) =3D CAA (X), otherwise >> >> >> >> o If A(X) is not null, and R(A(X)) is not empty, then R(X) =3D >> >> R(A(X)), otherwise >> >> >> >> o If X is not a top-level domain, then R(X) =3D R(P(X)), otherwise >> >> >> >> o R(X) is empty. >> >> >> >> >> >> Corrected Text >> >> -------------- >> >> Let CAA(X) be the record set returned in response to performing a CAA >> >> record query on the label X, P(X) be the DNS label immediately above >> >> X in the DNS hierarchy, and A(X) be the target of a CNAME or DNAME >> >> alias record chain specified at the label X. >> >> >> >> o If CAA(X) is not empty, R(X) =3D CAA (X), otherwise >> >> >> >> o If A(X) is not null, and CAA(A(X)) is not empty, then R(X) =3D >> >> CAA(A(X)), otherwise >> >> >> >> o If X is not a top-level domain, then R(X) =3D R(P(X)), otherwise >> >> >> >> o R(X) is empty. >> >> >> >> Thus, when a search at node X returns a CNAME record, the CA will >> >> follow the CNAME record to its target. If the target label contains a >> >> CAA record, it is returned. >> =E2=80=8BO=E2=80=8B >> therwise, the CA continues the search at >> >> the parent of node X. >> >> >> >> Note that the search does not include the parent of a target of a >> >> CNAME record (except when the CNAME points back to its own path). >> >> >> >> To prevent resource exhaustion attacks, CAs should limit the length of >> >> CNAME chains that are accepted. However CAs MUST process CNAME >> >> chains that contain ten or fewer CNAME records. >> >> >> >> Processing for DNAME is exactly the same as for CNAME. Note that since >> >> DNAME records are implemented by creating the corresponding CNAME >> >> records on the fly, it is only necessary for DNAME records to appear >> >> on the wire for purposes of DNSSEC. >> > > > > _______________________________________________ > Spasm mailing listSpasm@ietf.orghttps://www.ietf.org/mailman/listinfo/spa= sm > > > > > _______________________________________________ > Spasm mailing listSpasm@ietf.orghttps://www.ietf.org/mailman/listinfo/spa= sm > > > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm > > --001a11411e2cbfa8840553f7f24c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
https://www.rfc-editor.org/errata/eid5065
<= /div>

I = did change the should to a SHOULD as the context was obviously normative. N= ot that it makes much difference..

I will talk to the RFC Editor staff in Pra= gue and anyone else who might need to approve getting the status set to=C2= =A0Held for Document Update


On Sun, Jul 9,= 2017 at 5:24 PM, Jacob Hoffman-Andrews <jsha@eff.org> wrote:
=
=20 =20 =20
Ping on this?

On 06/23/2017 05:15= PM, Jacob Hoffman-Andrews wrote:
=20 This version looks good to me. Good catch to whoever pointed out Unbound's hard limit. And thanks to Phillip for pushing this through multiple revisions. Any other thoughts from the list?

On 06/22/2017 12:= 52 PM, Phillip Hallam-Baker wrote:

In response to comments by a non list subscriber:


s/<= span style=3D"font-size:14.6667px;color:rgb(80,0,80)">follow the CNAME record/follow the CNAME record chain

s/ten or fewer/8 or fewer/


The first is just for clarity and the second is because it turns out that unbound has a hard limit of 8 CNAME records to follow in a chain which provides a justification for a number that was previously arbitrary.


If there is a revision of RFC1035 to specify a limit it will certainly follow unbound unless there is another library in common use with a different limit.



Corrected Text

--------------

=C2=A0=C2=A0 Let=C2=A0CAA<= /span>(X) be the record set returned in response to performing a=C2=A0CAA

=C2=A0=C2=A0 record query on the label X, P(X) be the DNS label immediately above

=C2=A0=C2=A0 X in the DNS hierarchy, and A(X) be the target of a CNAME or DNAME

=C2=A0=C2=A0 alias record chain specified at the label X.

=C2=A0

=C2=A0=C2=A0 o=C2=A0 If=C2=A0CAA(X) is not empty, R(X) =3D=C2=A0CAA=C2=A0(X), otherwise

=C2=A0

=C2=A0=C2=A0 o=C2=A0 If A(X) is not null, and=C2=A0CAA(A(X)) is not empty, then R(X) =3D

=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0CAA(A(X)), ot= herwise

=C2=A0

=C2=A0=C2=A0 o=C2=A0 If X is not a top-level domain, then R(X) =3D R(P(X= )), otherwise

=C2=A0

=C2=A0=C2=A0 o=C2=A0 R(X) is empty.

=C2=A0

=C2=A0 Thus, when a search at node X returns a CNAME record, the CA will

=C2=A0 follow the CNAME record chain to its target. If the target label=C2=A0

=C2=A0 contains a=C2=A0CAA=C2=A0record, it is returned.

=E2=80=8BO=E2=80=8B
therwise, the CA continues the search at

=C2=A0 the parent of node X.

=C2=A0

=C2=A0 Note that the search does not include the parent of a target of a

=C2=A0 CNAME record (except when the CNAME points back to its own path).

=C2=A0

=C2=A0To prevent resource exhaustion attacks, CAs should limit the length of

=C2=A0=C2=A0CNAME chains that are accepted. However CAs MUST process CNAME

=C2=A0=C2=A0chains that contain 8 or fewer CNAME records.


On Wed, Jun 14, 2017 at 7:11 PM, Phillip Hallam-Baker <phill@hallambaker.com> wrote:

Th= e RFC Editor has deleted all three of the existing errata. I would like for the next errata to be the very last.

=C2=A0

Could people read, review and state if this works for them?

=E2=80=8B This text is the same as the one I posted to CABForum earlier with the one exception being that I capitalized Otherwise in the place it needed it.=E2=80=8B


=C2=A0

Original Text

-------------

=C2=A0=C2=A0 Let CAA(X) be the record set returned in response to performing a CAA

=C2=A0=C2=A0 record query on the label X, P(X) be the DNS label immediately above

=C2=A0=C2=A0 X in the DNS hierarchy, and A(X) be the target of a CNAME or DNAME

=C2=A0=C2=A0 alias record specified at the label X.

=C2=A0

=C2=A0=C2=A0 o=C2=A0 If CAA(X) is not empty, R(X) =3D CAA (X), other= wise

=C2=A0

=C2=A0=C2=A0 o=C2=A0 If A(X) is not null, and R(A(X)) is not empty, then R(X) =3D

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 R(A(X)), otherwise

=C2=A0

=C2=A0=C2=A0 o=C2=A0 If X is not a top-level domain, then R(X) =3D R(P(X)), otherwise

=C2=A0

=C2=A0=C2=A0 o=C2=A0 R(X) is empty.

=C2=A0<= /p>

=C2=A0<= /p>

Corrected Text

--------------

=C2=A0=C2=A0 Let CAA(X) be the record set returned in response to performing a CAA

=C2=A0=C2=A0 record query on the label X, P(X) be the DNS label immediately above

=C2=A0=C2=A0 X in the DNS hierarchy, and A(X) be the target of a CNAME or DNAME

=C2=A0=C2=A0 alias record chain specified at the label X.

=C2=A0

=C2=A0=C2=A0 o=C2=A0 If CAA(X) is not empty, R(X) =3D CAA (X), other= wise

=C2=A0

=C2=A0=C2=A0 o=C2=A0 If A(X) is not null, and CAA(A(X)) is not empty= , then R(X) =3D

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 CAA(A(X)), otherwise

=C2=A0

=C2=A0=C2=A0 o=C2=A0 If X is not a top-level domain, then R(X) =3D R(P(X)), otherwise

=C2=A0

=C2=A0=C2=A0 o=C2=A0 R(X) is empty.

=C2=A0

=C2=A0 Thus, when a search at node X returns a CNAME record, the CA will

=C2=A0 follow the CNAME record to its target. If the target label contains a

=C2=A0 CAA record, it is returned.

=E2=80=8BO=E2=80=8B
therwise, the CA continues the search at

=C2=A0 the parent of node X.

=C2=A0

=C2=A0 Note that the search does not include the parent of a target of a

=C2=A0 CNAME record (except when the CNAME points back to its own path).

=C2=A0

=C2=A0To prevent resource exhaustion attacks, CAs should limit the length of

=C2=A0=C2=A0CNAME chains that are accepted. However CAs MUST process CNAME

=C2=A0=C2=A0chains that contain ten or fewer CNAME records.

=C2=A0

=C2=A0 Processing for DNAME is exactly the same as for CNAME. Note that since

=C2=A0 DNAME records are implemented by creating the corresponding CNAME

=C2=A0 records on the fly, it is only necessary for DNAME records to appear

=C2=A0 on the wire for purposes of DNSSEC.




_______________________________________________
Spasm mailing list
Spasm@ietf.org
https://www.ietf.org/ma=
ilman/listinfo/spasm




_______________________________________________
Spasm mailing list
Spasm@ietf.org
https://www.ietf.org/ma=
ilman/listinfo/spasm


_______________________________________________
Spasm mailing list
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm


--001a11411e2cbfa8840553f7f24c-- From nobody Mon Jul 10 18:58:02 2017 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 8C1DB129B4B for ; Mon, 10 Jul 2017 18:58:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.003 X-Spam-Level: X-Spam-Status: No, score=-7.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eff.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 q9rpOTxRTUtp for ; Mon, 10 Jul 2017 18:57:58 -0700 (PDT) Received: from mail2.eff.org (mail2.eff.org [173.239.79.204]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD34E127601 for ; Mon, 10 Jul 2017 18:57:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject; bh=q9dmiUSB1cm2vxM/VQsNX/bybTvG2X6wAtqa7RctQWw=; b=i4SfP80/ePx2dkh617tCp70FfE60SphXbGPlKT/R4uNpZ4u1/icUY+5trDoteshwKG3nMcHmvYSdi+b9J//ZUGquNIq3kPS1Q5NYv4xBKy6E6sUokDq0CLvHFlAlHurEjk0771RZLWB7FYLxSzOlqfD5MizE4oDX3opcmM+ez6M=; Received: ; Mon, 10 Jul 2017 18:57:56 -0700 To: Phillip Hallam-Baker Cc: SPASM , "Salz, Rich" , Rob Stradling References: <3c0da781-2586-647e-7332-c7233dd9570d@eff.org> <021b346f-966e-377b-a242-73d3613921b0@eff.org> <81cfd21c-e46a-29a3-d667-6e1b4a4bbbca@eff.org> <817edd56793e454aaa9759ba6ba03809@usma1ex-dag1mb1.msg.corp.akamai.com> <1fdb01e8-8232-944b-2323-709deccc9e11@eff.org> From: Jacob Hoffman-Andrews Message-ID: <891c33e4-f0a5-ab63-60a5-6cb8747c1b55@eff.org> Date: Mon, 10 Jul 2017 18:57:56 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US Received-SPF: skipped for local relay Archived-At: Subject: Re: [lamps] [Spasm] Erratum 4988 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 11 Jul 2017 01:58:00 -0000 On 07/10/2017 08:07 AM, Phillip Hallam-Baker wrote: > I will talk to the RFC Editor staff in Prague and anyone else who > might need to approve getting the status set to Held for Document Update Great, thanks. Would you be able to email them to get the ball rolling before Prague? The implementation date for the CA/Browser forum CAA enforcement is September, and it would be good to have this wrapped up and balloted before then. From nobody Tue Jul 11 07:18:22 2017 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 A46F9126C22; Tue, 11 Jul 2017 07:18:20 -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.55.3 Auto-Submitted: auto-generated Precedence: bulk CC: Phillip Hallam-Baker , ekr@rtfm.com, phill@hallambaker.com, Russ Housley , lamps-chairs@ietf.org, spasm@ietf.org, draft-ietf-lamps-rfc5280-i18n-update@ietf.org Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <149978270062.12469.9704619840100491837.idtracker@ietfa.amsl.com> Date: Tue, 11 Jul 2017 07:18:20 -0700 Archived-At: Subject: [lamps] Last Call: (Internationalization Updates to RFC 5280) to Proposed Standard X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 11 Jul 2017 14:18:20 -0000 The IESG has received a request from the Limited Additional Mechanisms for PKIX and SMIME WG (lamps) to consider the following document: - 'Internationalization Updates to RFC 5280' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2017-07-25. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract These updates to RFC 5280 provide clarity on the handling of Internationalized Domain Names (IDNs) and Internationalized Email Addresses in X.509 Certificates. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5280-i18n-update/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5280-i18n-update/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Thu Jul 13 19:12:08 2017 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 0059A1318A4; Thu, 13 Jul 2017 19:11:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Joel Halpern To: Cc: draft-ietf-lamps-rfc5280-i18n-update.all@ietf.org, spasm@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.56.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149999831392.16399.16155350544896318430@ietfa.amsl.com> Date: Thu, 13 Jul 2017 19:11:53 -0700 Archived-At: Subject: [lamps] Genart last call review of draft-ietf-lamps-rfc5280-i18n-update-02 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 14 Jul 2017 02:11:54 -0000 Reviewer: Joel Halpern 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 treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-lamps-rfc5280-i18n-update-?? Reviewer: Joel Halpern Review Date: 2017-07-13 IETF LC End Date: 2017-07-25 IESG Telechat date: Not scheduled for a telechat Summary: This document is ready for publication as a Proposed Standard Major issues: N/A Minor issues: N/A Nits/editorial comments: N/A From nobody Fri Jul 14 12:01:22 2017 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 4F111131822 for ; Fri, 14 Jul 2017 12:01:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qi16QpBYmXkC for ; Fri, 14 Jul 2017 12:01:19 -0700 (PDT) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 6F2C9131760 for ; Fri, 14 Jul 2017 12:00:54 -0700 (PDT) Received: from [10.32.60.55] ([88.128.80.240]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id v6EJ05GH002214 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 14 Jul 2017 12:00:08 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host [88.128.80.240] claimed to be [10.32.60.55] From: "Paul Hoffman" To: spasm@ietf.org Date: Fri, 14 Jul 2017 21:00:50 +0200 Message-ID: <4E9B2919-F612-4A6D-AC91-CB59A76BAEA1@vpnc.org> In-Reply-To: <149978270062.12469.9704619840100491837.idtracker@ietfa.amsl.com> References: <149978270062.12469.9704619840100491837.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5347) Archived-At: Subject: Re: [lamps] Last Call: (Internationalization Updates to RFC 5280) to Proposed Standard X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 14 Jul 2017 19:01:20 -0000 I have read this document in IETF Last call and think it is fine. The differences in text from RFC 5280 match what I would have expected. --Paul Hoffman From nobody Sun Jul 16 23:13:46 2017 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 508CA130154 for ; Sun, 16 Jul 2017 23:13:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kIE3jdJyJHdp for ; Sun, 16 Jul 2017 23:13:41 -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 8ABB012EC0D for ; Sun, 16 Jul 2017 23:13:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id DD6BD30050A for ; Mon, 17 Jul 2017 02:13:40 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id VIShNDnOZ1io for ; Mon, 17 Jul 2017 02:13:40 -0400 (EDT) Received: from [5.5.33.11] (vpn.snozzages.com [204.42.252.17]) by mail.smeinc.net (Postfix) with ESMTPSA id 98B6230042F for ; Mon, 17 Jul 2017 02:13:39 -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 10.3 \(3273\)) Message-Id: <01DBC1BD-574C-450C-BDFD-B5218DAB2A30@vigilsec.com> Date: Mon, 17 Jul 2017 02:13:42 -0400 To: LAMPS X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [lamps] Minute Takers, Jabber Scribes, and Slides request for LAMPS X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 17 Jul 2017 06:13:44 -0000 We need someone to take minutes at the LAMPS session this afternoon. We = need a Jabber Scribe as well. Please volunteer. Also, if you are presenting, please send you slides. Russ= From nobody Mon Jul 17 02:29:09 2017 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 AC96312EC30 for ; Mon, 17 Jul 2017 02:29:02 -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, 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 GdtEhzhpq4o5 for ; Mon, 17 Jul 2017 02:29:01 -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 225C412EC15 for ; Mon, 17 Jul 2017 02:29:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 832603004FE for ; Mon, 17 Jul 2017 05:29: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 wWuQtgS_VW3x for ; Mon, 17 Jul 2017 05:28:59 -0400 (EDT) Received: from [5.5.33.21] (vpn.snozzages.com [204.42.252.17]) by mail.smeinc.net (Postfix) with ESMTPSA id 55B1F300429 for ; Mon, 17 Jul 2017 05:28:59 -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 10.3 \(3273\)) Date: Mon, 17 Jul 2017 05:28:55 -0400 References: <01DBC1BD-574C-450C-BDFD-B5218DAB2A30@vigilsec.com> To: LAMPS In-Reply-To: Message-Id: <129D187B-DAB1-469A-98AC-EEB9082530D9@vigilsec.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [lamps] Minute Takers, Jabber Scribes, and Slides request for LAMPS X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 17 Jul 2017 09:29:03 -0000 Many thanks to the volunteers: - Yoav Nir: Minute Taker - Jim Schaad: Jabber Scribe Russ > On 17 Jul 2017, at 8:13, Russ Housley wrote: >=20 > We need someone to take minutes at the LAMPS session this afternoon. = We need a Jabber Scribe as well. Please volunteer. >=20 > Also, if you are presenting, please send you slides. >=20 > Russ From nobody Mon Jul 17 08:21:58 2017 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 B3836131B39 for ; Mon, 17 Jul 2017 08:21:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_HK_NAME_DR=0.01, 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 vIhWFBJzOixm for ; Mon, 17 Jul 2017 08:21:54 -0700 (PDT) Received: from mail.katezarealty.com (mail.katezarealty.com [104.168.158.213]) by ietfa.amsl.com (Postfix) with ESMTP id B1CCF131C58 for ; Mon, 17 Jul 2017 08:21:54 -0700 (PDT) Received: from dhcp-8e48.meeting.ietf.org (dhcp-8e48.meeting.ietf.org [31.133.142.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.katezarealty.com (Postfix) with ESMTPSA id 049803740F41 for ; Mon, 17 Jul 2017 11:21:53 -0400 (EDT) References: <467c8936-f6aa-0853-878c-24fc8803c599@openca.org> To: LAMPS From: "Dr. Pala" X-Forwarded-Message-Id: <467c8936-f6aa-0853-878c-24fc8803c599@openca.org> Message-ID: <9ce87dde-9a5b-2d30-81fa-e6aff010808e@openca.org> Date: Mon, 17 Jul 2017 17:21:52 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <467c8936-f6aa-0853-878c-24fc8803c599@openca.org> Content-Type: multipart/mixed; boundary="------------F3992D275CBE94EDC5A40AEE" Content-Language: en-US Archived-At: Subject: [lamps] Fwd: [pkix] Managing Long-Lived CA certs X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 17 Jul 2017 15:21:57 -0000 This is a multi-part message in MIME format. --------------F3992D275CBE94EDC5A40AEE Content-Type: multipart/alternative; boundary="------------59C6F05D165E7AE91AD78FD5" --------------59C6F05D165E7AE91AD78FD5 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi all, Would this be an item that the WG would be interested in working on ? It should be quite a simple I-D, IMHO. Cheers, Max -------- Forwarded Message -------- Subject: [pkix] Managing Long-Lived CA certs Date: Mon, 17 Jul 2017 16:19:44 +0200 From: Dr. Pala Organization: OpenCA Labs To: pkix@ietf.org Hi PKIX, I have a small question for the list regarding long-lived CA certificates. Especially in the context of device certificates, we often see the use of extra long-lived certificates for Root and Sub CAs (e.g., 35+ years) combined with limited key sizes (e.g., p256). Until we have a supported mechanism for reprovisioning devices (...), one possible solution for limiting the exposure of the private key would be to have a scoped certificate issuance period. What I am thinking about would be adding an extension that says: "This CA can issue certificates from up to 5 years from the validFrom, after this, just use it to provide revocation information". This might provide some protection in case the CA key is compromised after the initial 5 years of validity (e.g., certificates issued after that date shall be rejected). Does such extension exists today ? If not, could this be some work for LAMPS/SPASM WG ? Cheers, Max -- Best Regards, Massimiliano Pala, Ph.D. OpenCA Labs Director OpenCA Logo --------------59C6F05D165E7AE91AD78FD5 Content-Type: multipart/related; boundary="------------53730F4A1155C9B565B11529" --------------53730F4A1155C9B565B11529 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

Hi all,

Would this be an item that the WG would be interested in working on ? It should be quite a simple I-D, IMHO.

Cheers,
Max



-------- Forwarded Message --------
Subject: [pkix] Managing Long-Lived CA certs
Date: Mon, 17 Jul 2017 16:19:44 +0200
From: Dr. Pala <director@openca.org>
Organization: OpenCA Labs
To: pkix@ietf.org


Hi PKIX,

I have a small question for the list regarding long-lived CA certificates. Especially in the context of device certificates, we often see the use of extra long-lived certificates for Root and Sub CAs (e.g., 35+ years) combined with limited key sizes (e.g., p256).

Until we have a supported mechanism for reprovisioning devices (...), one possible solution for limiting the exposure of the private key would be to have a scoped certificate issuance period.

What I am thinking about would be adding an extension that says: "This CA can issue certificates from up to 5 years from the validFrom, after this, just use it to provide revocation information". This might provide some protection in case the CA key is compromised after the initial 5 years of validity (e.g., certificates issued after that date shall be rejected).

Does such extension exists today ? If not, could this be some work for LAMPS/SPASM WG ?

Cheers,
Max

--
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo
--------------53730F4A1155C9B565B11529 Content-Type: image/png; name="eibffaoijngmjaee.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="eibffaoijngmjaee.png" iVBORw0KGgoAAAANSUhEUgAAAGQAAAA2CAMAAAAGesyaAAADAFBMVEUsJiEAAQAKAwMABwoX BwESCQAqDgEkEQItFQESGykaGh0WGyE1FwE9GwJHHwElJiY4JBQmKDE1KCAfLUQ8KygoMEAq MjpXKgs/MilMMR0pOFEyOUo4OTo1OkRqMgpjOBlpNxUwQV1DPz48QExdOyM4QVV+OQRRQzo1 SGdDR0lDSFJfRDFASVyaPwF+RRpNT1I9UXlwSi8+UnNDUm6hQgCPRhBdUEZTUlBKVGlPVF27 PgCaSANtUT57VBerSQOMUgxHW4KMUiepTwmJVDh6WT6KVjGCWDpRYH21TwFiYF57YgJXYXae VR+lVRZrYld1ZiB7YEuSYQBgZW+8VAlkZWjBVQCfXiqqXwG1WhPLVgedYDazXiDZVgCWZEDV WQJ1blapYjbXWgDRXACMaU6WbgCiZjnIXw9mcIixZC6pZjJ/cUeLbFdycmZ4cGnnWwNwc3Wq aS6BcGeobwndXwzkXwLgYgDaYwyMeCq/bQHJaBi9ajDMagWVegvRZxzVaAvXaQDLainqZAuv cEPrZQDQaSyockrFbSvmZwnabQLvZwDpaQB0fpPkaxGld1d+f3/3aACfeV6RfG2JfnLebSF7 gYy2fQmugQCigxW8d0K3eEr1bQXaciTicRqKgnzNewHuchbUdzKYiDzrdwKah1erjAvOfEXl eSq5g1qYjGikiHO2kADigwC2hmSZjIGGj6aHkJzQiwCximixim/EkAORkZGVkYrOh0rPiVL5 giTvhDKkk4LMjF23mR+zmTrhikrviDzsi0TAlHDCnwvKlGqpnJLdlF2boKy+m324nImkoZ+e o6XKpgrloATwl1WypZPOn3zfqQjYrgLBrVDdo3nGq5mysa/SrI7dq4bqqXTOrpWttL+6s6uw tbe/t4rhvALetpjQuqnuwwe9v8LAv7vauqD3xA68w9XBw83rvJfRwbXFyMvbxbPNyMP8zgTc zMDr0mb91xLM1ODQ1NfS1c7p0sD70bPd19PX4qj83cje4+Xr4tv54NLp7/Hy9PHw9fj6/v3Y ktvJAAAAAXRSTlMAQObYZgAAAAFiS0dEAIgFHUgAAAjrSURBVFjDtVcNWFPXGT6E+l9BZ0EF sTKEIQaUAIrTZdYqxqG0I3UjIuiDM0ipoyO5l0rFh2PE472EoIJKL9hQV2OxqM+USgFL4r9g EaIoQxgqKBZBR+nGGhXYdwNro0Kfkcp3ntzce/7e8/2e70PoJVDl3bMlZyurUSsaKnqESrMp lYrByozCjUOEUZORodMRVsViTjJc8GbLUGCUUstLv1SyLCGch8DGRiDPe/kY5/2HCQQTxZEE y4fb2gDI8KjjLxsjfyyc3lZgM3KixwgeY4TEzk7+kjHODbeb6u0xAhiw8XgFMOxolpP6J75U jLZfp6dzHIcBYCQbIBB4sCxDOLK6eMAVT39it57+e09ysCnDUtnrJ0vS5ZMW0PBFWDbd40G/ 85sH2KeXvj94u/flX8/2J6kYQkhkHbzWbkdH0N0UDN8sURS8uMd9dMzPL7BxIIjOayuWLBIf 70RPUPjxLouBEgVhMaYuWXQlMjwsN+eFTR4cDZ4werRDYOoAIFkrptm/Ni0gthOt9Q4yWQxc AwyWTbacW0sTDGoJen4P002/2S7LjgV6BpY1N6OO5g5eeiZTY/P9b1FzRwfKWuk9p/72ct+N puKpq32qLVaexOCCJB91aezt5y6zt7fXILSdJZjlVr1w0mCR66x6FL3QOXiUQ2a0k/sFlDlq 1LzUMQ4uxxycjl0LWO1bBsY6yXR3wSTJGxqLhdsJHDsS9cwF47XlvcQGQiXhRbih/HkQv4XO cajZb6GDu7PTFEdPkVu0k4vQyd3Jc/SUwNnB+RJ/XsI9ptZDIxMly3dbLNwGnGBJF+Id3cZM 9ui8Gjq5P/TDiRCegbOFgSKRo5e7yNHV2dnPdVb0bHfHQCevNIV/rxqrX48oFQdYcpKMtYRb juxtfqRypNACK28+j3FsqcilAD0ADuIWCt0yRa7zRNEOY2YELhW5CV2dXVKixH8BC+s8GDN9 wWKxf94zpsRiJuWmBYjgndsKFmu5Bc+D3HQXCcu7QTFTMl3HF0SLxruLvGa4zUqdMGFWqqfX 3GSxN0y6NT154i+v75zvH2thXiWgY2YVElhwYl9NYxarlr0grlQn92DQt1vBUk+nUFeHGZme gUIvl1RXr1AnV/fx6zd4v3HptM/YaXbrzmYFePu2WpowYRlJo+2PGLb2d9WE5bw1L4DcnOco 9HIcH3o02HOecMqMJhQqdLPXpArHl2uEo+Na8qZPXxw0+bVx46bFzhw3eZylM2dgwkbWW3Iy Jp9lMDe9H2/raiqPCy5/fHSCu+M7mkffoQuzQhvRhWVlj1FcWTfq6dwdElJmarxedr/u3P6C Nn7Fk95ol8wRjIMsOLGJSwLm/OMGjlFHJ7hqelDuxdMlpbU16JvqlJTamivoBjrfUgNB69zf b6Fr1TWPKmtOw9xCdLayEFWvBlaSfmEBsk6LSdTMNnQaldTe7Qfj20yveddR2toVEevCi9/f fmntR7ErtvompmyICM9qyYpZsG3FhqwNYRH5KUtyW7eGRRxfH1OHDv0ZXH6ihbSyVYzSY3Fu BkVR9LaS2wPxUxyTFpu2eGverr+dezvi0ttpOy/tTKlL2ZkWs6p4VV1Kyq60nevS8iLyi1tW hfNWzMfhYT+ArAQ+5odRBENjlRW5F/vH6O7u7urpXtvR/bQbmX/dPd3w7Ok+2Ij4ry5o0N/d Y1p7qA21FodhFRc1ctjIsXZ2Y18VcwCixNgcWlgVbUiue3b3J33te7497vv/oT1Bj5/7br1R grYlfrReSqmwPDyK0GqOUHKWj/RwP0J0ZlmsK3o2HP+7Qt9HBr3BYH5aNL3FG/+ul8sjKcxH dRJFGJkhfKxgmM2rUoaSg5h4GAwXJsF00dRGq+/21k2EF7o50oNswrNfsYUQKRBIZWIFh3lu aLNe1F++bjXGyWyzZiGoYFYLx5Ys4v0R3GWRdBHNErBiSiqVRhHMyeaYrMQ4SENWCvEcfhCm GIzpqKlm27KTSWUcAX1goBw5oATctDb33aLTYV5SWoaXP5+gyqlFdnZ23nB+plcnREv0RWJC BVkrrBJ1BewMmlVpgRUQF7wpItMJTcsJ34GBRVaFdQZaqoqxFmSb3qDQgu1A2GI4YAnODkQY IOhklDKzo2C1IV2sijzdhjorqwefNdL6ihxzegU7SynexHgBMXy+xWFG8qvdf91D8WpRi41q KFl02YaswYNkULTeLC9CFFK4bDHDMmZbhnuXSOdAsnN1LxgfVu7ZvG8LpSJUlO/gnaWQFwYv JpZeKdUaSC8ApuhIShYQYp5yWQ0oPgVXPtkcHz/fx5rqqzosHSSlBYHIxKSolJcUsIIpnzkh mt4b7Z/tOzBRQWaA6uNCNdet0nxLkL8CgzeQKIlCXaHjXR9MlqQn9Y1fNd5RE0zF/ryKwVR/ JMnsI3S8Umcw6NRYxRuUKqk3lfnKeGcTySAx5hy+7WfgZOv4uLLl0w8wUah71QLBpJeXq/eM VVivV8jz6lB2ofWF6i1dEYRZfMJ4piE+ZweNeb7A2VVyKEx6vjt1z/ghMehVKiUpyt1VYBXC N6j0Q4Mazp7TvvndhIaGhqqvP1bwFk0YRYR5RoLR+PkWmlIpV/oEDQ6jB9Wc3Z6bm6zLTtLl gLC4LVWXz5Q1ffbV5oZ24wmsV/NeKTlirmg+u/q7w7/38PDdeKF8UBgXs2kV4WUC0YR/KOLv Pby3L5O30yvG9vY/6vX8JSbb2je96coXX5QPznqfokKKEPWBAwd20ApaTWsP7LnTfsd42at3 +B+H7+zRUfwZZMutN6baHCX5+Ou9Zy4f3nuiKr7KaHxoNDbsSwhp6htvfyg3Zw901G+ttVlT Ja34/E+fvrXmvY3713xy6tSZfadOJby7X1P/vwn/MeaYr0mF7IMEq690Gu95KwQq5L5K+f59 qGUtaZMSciHMKjdVbY6zFqRC/pv3LgxY5tcW0pjIpGGJ7+89kxBnbXZSmjuz7CeyihyG8fbd XXYdrWlqQg+sZWTdzPqBB68VEdnkzDY0lHSjSD9/GRpaMt3OWqLpQENOTf/PpP8CK9ZVVe2a 8XoAAAAASUVORK5CYII= --------------53730F4A1155C9B565B11529-- --------------59C6F05D165E7AE91AD78FD5-- --------------F3992D275CBE94EDC5A40AEE Content-Type: text/plain; charset=UTF-8; name="Attached Message Part" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Attached Message Part" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KcGtpeCBt YWlsaW5nIGxpc3QKcGtpeEBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3BraXgKCg== --------------F3992D275CBE94EDC5A40AEE-- From nobody Tue Jul 18 02:18:55 2017 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 34832131DD0 for ; Tue, 18 Jul 2017 02:18:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_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 eLUF-epK19-y for ; Tue, 18 Jul 2017 02:18:51 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (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 5C112131A93 for ; Tue, 18 Jul 2017 02:18:46 -0700 (PDT) Received: from [192.168.122.115] (unknown [174.65.80.226]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 277E922E1F3 for ; Tue, 18 Jul 2017 05:18:33 -0400 (EDT) From: Sean Leonard Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 18 Jul 2017 02:18:32 -0700 References: <1AE5876A-D3B4-4711-A701-03F64532F3B0@vigilsec.com> <678040CE-455A-41FB-B877-054652348D52@vigilsec.com> <20170630191851.GD5673@mournblade.imrryr.org> To: spasm@ietf.org In-Reply-To: <20170630191851.GD5673@mournblade.imrryr.org> Message-Id: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [lamps] WG Last Call for draft-ietf-lamps-eai-addresses-10 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 18 Jul 2017 09:18:53 -0000 > On Jun 30, 2017, at 12:18 PM, Viktor Dukhovni = wrote: >=20 > On Fri, Jun 30, 2017 at 12:28:48PM -0400, Russ Housley wrote: >=20 >> With the posting of draft-ietf-lamps-eai-addresses-12, I believe that = all >> WG Last Call comments have bee resolved. I will notify our Area = Director >> that the document is ready. >=20 > Indeed, grammar issues aside, which I expect will be addressed by > the RFC editor, looks largely done to me. It'll soon be time to > resume work to support the new name type in OpenSSL. This time > with rfc822Name name constraints applied to both rfc822Name and > SMTPUtf8Name subjectAltNames. >=20 > My only technical quibble is that I'd have preferred to also see > deprecation of support for email addresses in the subject DN, > subject altnames have been broadly supported for a long time. This > is a non-critical issue. If there's not broad support for doing > that at this time, I have no substantial issues with the -12 draft. Hi Viktor, EAI addresses need an LDAP attribute, since the current LDAP attributes = (mail and emailAddress (RFC 5280)) don=E2=80=99t support UTF-8. I = expressed interest in fixing this, but the LDAP maintainers have mostly = evaporated. :( Still interested in a draft for that, however. I agree with the direction of draft-ietf-lamps-eai-addresses that the = subject DN should not be checked and should not be used for address = matching. There is some risk that a UTF-8 e-mail address attribute that is not = checked, could pose a phishing risk if presented to the user. However, = that is no different from a CN or other displayed attribute that happens = to contain an e-mail address. I do not consider that risk to be = significant (in light of the alternatives). Sean From nobody Thu Jul 20 04:37:14 2017 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 65F7812969E for ; Thu, 20 Jul 2017 04:37:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_HK_NAME_DR=0.01] 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 KXaKOJa04mPZ for ; Thu, 20 Jul 2017 04:37:11 -0700 (PDT) Received: from mail.katezarealty.com (mail.katezarealty.com [104.168.158.213]) by ietfa.amsl.com (Postfix) with ESMTP id C90CF12EC30 for ; Thu, 20 Jul 2017 04:37:10 -0700 (PDT) Received: from dhcp-8e48.meeting.ietf.org (dhcp-8e48.meeting.ietf.org [31.133.142.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.katezarealty.com (Postfix) with ESMTPSA id D65053740FB2 for ; Thu, 20 Jul 2017 07:37:09 -0400 (EDT) From: "Dr. Pala" To: LAMPS Organization: OpenCA Labs Message-ID: <04e73e42-7c5b-912d-cc79-7959a710927e@openca.org> Date: Thu, 20 Jul 2017 13:37:08 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------34264417537514D063CD9EE1" Content-Language: en-US Archived-At: Subject: [lamps] Considerations about the need to resume PKIX work X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 20 Jul 2017 11:37:13 -0000 This is a multi-part message in MIME format. --------------34264417537514D063CD9EE1 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi all, I would like to draw the Sec Area attention on an issue that I think is becoming more relevant every day. It seems quite clear that today there is a lot of work around authentication and encryption that make use of PKIX certificates. However, there is no place in IETF, today, where problems related to PKIX can be effectively tackled. In the following paragraphs I try to summarize the issue and the proposed work and a call for discussion around the feasibility of resuming the work in two particular areas: revocation and discoverability. *The Problem *What I noticed in recent proposals in many working groups (when it comes to certificate management) is that more and more people turn towards the use of short-lived certificates to avoid checking revocation information. Sometimes this choice is motivated by real technical considerations, but in many cases the choice is "forced" because nobody is currently working on fixing the two main issues related to trust infrastructures: efficient revocation and discoverability of services. *The Revocation Situation* Most of the times, when interacting with PKIs, we are still stuck with CRLs, OCSP if we are lucky (including stapling - available in TLS connections if really really lucky), and in most cases even these mechanisms are criticized widely by people as being inadequate today. This resulted in applications to use proprietary methods for checking revocation (e.g., CRLSet) or to skip checking all together (or mandate for short-lived certificates only as in the case, for example, of STIR). Many people today ignore the fact that, when coupled with small devices, the generation of new keys require (a) a lot of resources, and (b) a good source of randomness. Requiring apps / devices to generate new keys might seem a good idea at first, but is this better than checking revocation ? What about the complexity of key management ? /Examples of possible work to address the issues are OCSP over DNS and some more efficient ways to verify the validity of a whole chain of certificates efficiently./ *The Discoverability Situation* As far as I know, there are no standardized mechanisms that would provide discoverability of services that would help users and applications to discover Public Key Services providers and associated services in a dynamic fashion. When I brought it up during the BoFs of possible working groups where the issue could be discussed.. well, the proposal was redirected to /dev/null (e.g., ACME, SPASM, and LAMPS). Isn't that curious that still today nobody is working on some sort of infrastructure that would facilitate interacting with PKIs ? After all, PKIs are the core Trust mechanism that enables reliable authentication and encryption over the Internet today. Such infrastructure could really improve the security of the Internet and make PKIs more usable from an application (and users) standpoint of view. /Examples of possible work to address the issue are a PKI Resource Query Protocol (PRQP) and/or the use of P2P systems as distribution mechanisms for Public Key related operations (e.g., EST, BRSKI, or ACME over P2P - 0-configuration support for PK)./ *Deployment Trends in the Real World* Today I am witnessing the deployment of arguably not-well-designed PKIs (or, in other terms, what I call Weak PKIs) that do not provide support for revocation and that are expected to use CAs and EE certificates with validity periods of 30, 35, or 50 years (yes, also EE - especially for devices). Besides the fact that it is a common assumption that the algorithms (e.g., P-256) used in these environments (e.g. IoT) are NOT going to pass the test of time, ignoring the revocation could really affect the privacy of millions of people - and we are currently not doing anything at the IETF to prevent this issue. /There is the need for simple revocation services, but arguably we do not have what's needed today (requires improvements)./ *IETF Specific Situation and Issues* Why are we so unprepared to face these issues ? I would say (still personal point of view - based on almost 20 yrs of participation in PKI discussions) that these might be some of the main reasons: * *There are NO venues where to discuss possible solutions to existing problems.* The PKIX working group has been closed down (very arbitrarily, I might say, since there is still a lot of work needed to be done around PKIX as highlighted above) * *The LAMPS, SPASM, and ACME WGs have/have had, on purpose, very narrow scoped Charters and only few items**(mostly quite marginal issues, IMO) are actually accepted as working items (w/ reference to SPASM and LAMPS in particular).* Solving revocation and discoverability issues should be the 1st item and the most important on the list (at least revocation) but they are not - actually when that was proposed to be included as part of the charter(s), the requests were not even acknowledged or rejected with no real technical reasons. * *The constant**nonsense of people saying that PKIs do not work as an excuse not to improve them while they (PKIs) are the reason we can deploy secure protocols and provide privacy. *It is evident that PKIs are here to stay, this is a fact. Their usage has increased exponentially in the past years and they have, so far, passed the test of time. IoT is one use-case. ANIMA is another. ACME is another. Just to cite few of them. Moreover, things are happening in environments outside IETF (WIFI 2.0 Alliance, OpenADR, CMI, etc.) and IETF un-willingness of working on these problems is really scary to me. The world moves forward, fast, and the IETF is standing still on this topic./*I really do not understand why.*/ *Final Considerations* In this message I try to summarize the reasons why I think there is the need to provide a venue where these problems are discussed and the need for key people to not actively block the possibility for people that are willing to work on this to have a venue where the work can be carried out. I think that this work is of the utter importance and I would like to understand what the position of the whole security area is around these points and the proposed work. /I hope that the discussion around this message can spark some interest and that work in the PKIX area can finally resume at the IETF - which was, in the past, thought of as the lighthouse where these issues could be addressed./ A small request, please, try to read this e-mail carefully and consider the implications of NOT taking on these tasks when replying and/or discussing the topic. Also, since I know this (PKIX) is a minefield for "political" reasons (which should not be a drive here), please keep the discussion on the positive / constructive side (thanks). /If you feel like a private response is better than on the mailing list, please just reply privately./ Looking forward to hear your opinions on this hoping that this e-mail can be the beginning of the end of PKIX still-standing issues :D Cheers, Max -- Best Regards, Massimiliano Pala, Ph.D. OpenCA Labs Director OpenCA Logo --------------34264417537514D063CD9EE1 Content-Type: multipart/related; boundary="------------6B3944540BEDFBD3702FFA05" --------------6B3944540BEDFBD3702FFA05 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

Hi all,

I would like to draw the Sec Area attention on an issue that I think is becoming more relevant every day.

It seems quite clear that today there is a lot of work around authentication and encryption that make use of PKIX certificates. However, there is no place in IETF, today, where problems related to PKIX can be effectively tackled. In the following paragraphs I try to summarize the issue and the proposed work and a call for discussion around the feasibility of resuming the work in two particular areas: revocation and discoverability.

The Problem

What I noticed in recent proposals in many working groups (when it comes to certificate management) is that more and more people turn towards the use of short-lived certificates to avoid checking revocation information. Sometimes this choice is motivated by real technical considerations, but in many cases the choice is "forced" because nobody is currently working on fixing the two main issues related to trust infrastructures: efficient revocation and discoverability of services.

The Revocation Situation

Most of the times, when interacting with PKIs, we are still stuck with CRLs, OCSP if we are lucky (including stapling - available in TLS connections if really really lucky), and in most cases even these mechanisms are criticized widely by people as being inadequate today. This resulted in applications to use proprietary methods for checking revocation (e.g., CRLSet) or to skip checking all together (or mandate for short-lived certificates only as in the case, for example, of STIR).

Many people today ignore the fact that, when coupled with small devices, the generation of new keys require (a) a lot of resources, and (b) a good source of randomness. Requiring apps / devices to generate new keys might seem a good idea at first, but is this better than checking revocation ? What about the complexity of key management ?

Examples of possible work to address the issues are OCSP over DNS and some more efficient ways to verify the validity of a whole chain of certificates efficiently.

The Discoverability Situation

As far as I know, there are no standardized mechanisms that would provide discoverability of services that would help users and applications to discover Public Key Services providers and associated services in a dynamic fashion. When I brought it up during the BoFs of possible working groups where the issue could be discussed.. well, the proposal was redirected to /dev/null (e.g., ACME, SPASM, and LAMPS).

Isn't that curious that still today nobody is working on some sort of infrastructure that would facilitate interacting with PKIs ? After all, PKIs are the core Trust mechanism that enables reliable authentication and encryption over the Internet today. Such infrastructure could really improve the security of the Internet and make PKIs more usable from an application (and users) standpoint of view.

Examples of possible work to address the issue are a PKI Resource Query Protocol (PRQP) and/or the use of P2P systems as distribution mechanisms for Public Key related operations (e.g., EST, BRSKI, or ACME over P2P - 0-configuration support for PK).

Deployment Trends in the Real World

Today I am witnessing the deployment of arguably not-well-designed PKIs (or, in other terms, what I call Weak PKIs) that do not provide support for revocation and that are expected to use CAs and EE certificates with validity periods of 30, 35, or 50 years (yes, also EE - especially for devices). Besides the fact that it is a common assumption that the algorithms (e.g., P-256) used in these environments (e.g. IoT) are NOT going to pass the test of time, ignoring the revocation could really affect the privacy of millions of people - and we are currently not doing anything at the IETF to prevent this issue.

There is the need for simple revocation services, but arguably we do not have what's needed today (requires improvements).

IETF Specific Situation and Issues

Why are we so unprepared to face these issues ? I would say (still personal point of view - based on almost 20 yrs of participation in PKI discussions) that these might be some of the main reasons:

  • There are NO venues where to discuss possible solutions to existing problems. The PKIX working group has been closed down (very arbitrarily, I might say, since there is still a lot of work needed to be done around PKIX as highlighted above)

  • The LAMPS, SPASM, and ACME WGs have/have had, on purpose, very narrow scoped Charters and only few items (mostly quite marginal issues, IMO) are actually accepted as working items (w/ reference to SPASM and LAMPS in particular). Solving revocation and discoverability issues should be the 1st item and the most important on the list (at least revocation) but they are not - actually when that was proposed to be included as part of the charter(s), the requests were not even acknowledged or rejected with no real technical reasons.

  • The constant nonsense of people saying that PKIs do not work as an excuse not to improve them while they (PKIs) are the reason we can deploy secure protocols and provide privacy. It is evident that PKIs are here to stay, this is a fact. Their usage has increased exponentially in the past years and they have, so far, passed the test of time. IoT is one use-case. ANIMA is another. ACME is another. Just to cite few of them.

Moreover, things are happening in environments outside IETF (WIFI 2.0 Alliance, OpenADR, CMI, etc.) and IETF un-willingness of working on these problems is really scary to me. The world moves forward, fast, and the IETF is standing still on this topic. I really do not understand why.

Final Considerations

In this message I try to summarize the reasons why I think there is the need to provide a venue where these problems are discussed and the need for key people to not actively block the possibility for people that are willing to work on this to have a venue where the work can be carried out.

I think that this work is of the utter importance and I would like to understand what the position of the whole security area is around these points and the proposed work.

I hope that the discussion around this message can spark some interest and that work in the PKIX area can finally resume at the IETF - which was, in the past, thought of as the lighthouse where these issues could be addressed.

A small request, please, try to read this e-mail carefully and consider the implications of NOT taking on these tasks when replying and/or discussing the topic. Also, since I know this (PKIX) is a minefield for "political" reasons (which should not be a drive here), please keep the discussion on the positive / constructive side (thanks).

If you feel like a private response is better than on the mailing list, please just reply privately.

Looking forward to hear your opinions on this hoping that this e-mail can be the beginning of the end of PKIX still-standing issues :D

Cheers,
Max

--
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo
--------------6B3944540BEDFBD3702FFA05 Content-Type: image/png; name="efhklhncoknghhph.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="efhklhncoknghhph.png" iVBORw0KGgoAAAANSUhEUgAAAGQAAAA2CAMAAAAGesyaAAADAFBMVEUsJiEAAQAKAwMABwoX BwESCQAqDgEkEQItFQESGykaGh0WGyE1FwE9GwJHHwElJiY4JBQmKDE1KCAfLUQ8KygoMEAq MjpXKgs/MilMMR0pOFEyOUo4OTo1OkRqMgpjOBlpNxUwQV1DPz48QExdOyM4QVV+OQRRQzo1 SGdDR0lDSFJfRDFASVyaPwF+RRpNT1I9UXlwSi8+UnNDUm6hQgCPRhBdUEZTUlBKVGlPVF27 PgCaSANtUT57VBerSQOMUgxHW4KMUiepTwmJVDh6WT6KVjGCWDpRYH21TwFiYF57YgJXYXae VR+lVRZrYld1ZiB7YEuSYQBgZW+8VAlkZWjBVQCfXiqqXwG1WhPLVgedYDazXiDZVgCWZEDV WQJ1blapYjbXWgDRXACMaU6WbgCiZjnIXw9mcIixZC6pZjJ/cUeLbFdycmZ4cGnnWwNwc3Wq aS6BcGeobwndXwzkXwLgYgDaYwyMeCq/bQHJaBi9ajDMagWVegvRZxzVaAvXaQDLainqZAuv cEPrZQDQaSyockrFbSvmZwnabQLvZwDpaQB0fpPkaxGld1d+f3/3aACfeV6RfG2JfnLebSF7 gYy2fQmugQCigxW8d0K3eEr1bQXaciTicRqKgnzNewHuchbUdzKYiDzrdwKah1erjAvOfEXl eSq5g1qYjGikiHO2kADigwC2hmSZjIGGj6aHkJzQiwCximixim/EkAORkZGVkYrOh0rPiVL5 giTvhDKkk4LMjF23mR+zmTrhikrviDzsi0TAlHDCnwvKlGqpnJLdlF2boKy+m324nImkoZ+e o6XKpgrloATwl1WypZPOn3zfqQjYrgLBrVDdo3nGq5mysa/SrI7dq4bqqXTOrpWttL+6s6uw tbe/t4rhvALetpjQuqnuwwe9v8LAv7vauqD3xA68w9XBw83rvJfRwbXFyMvbxbPNyMP8zgTc zMDr0mb91xLM1ODQ1NfS1c7p0sD70bPd19PX4qj83cje4+Xr4tv54NLp7/Hy9PHw9fj6/v3Y ktvJAAAAAXRSTlMAQObYZgAAAAFiS0dEAIgFHUgAAAjrSURBVFjDtVcNWFPXGT6E+l9BZ0EF sTKEIQaUAIrTZdYqxqG0I3UjIuiDM0ipoyO5l0rFh2PE472EoIJKL9hQV2OxqM+USgFL4r9g EaIoQxgqKBZBR+nGGhXYdwNro0Kfkcp3ntzce/7e8/2e70PoJVDl3bMlZyurUSsaKnqESrMp lYrByozCjUOEUZORodMRVsViTjJc8GbLUGCUUstLv1SyLCGch8DGRiDPe/kY5/2HCQQTxZEE y4fb2gDI8KjjLxsjfyyc3lZgM3KixwgeY4TEzk7+kjHODbeb6u0xAhiw8XgFMOxolpP6J75U jLZfp6dzHIcBYCQbIBB4sCxDOLK6eMAVT39it57+e09ysCnDUtnrJ0vS5ZMW0PBFWDbd40G/ 85sH2KeXvj94u/flX8/2J6kYQkhkHbzWbkdH0N0UDN8sURS8uMd9dMzPL7BxIIjOayuWLBIf 70RPUPjxLouBEgVhMaYuWXQlMjwsN+eFTR4cDZ4werRDYOoAIFkrptm/Ni0gthOt9Q4yWQxc AwyWTbacW0sTDGoJen4P002/2S7LjgV6BpY1N6OO5g5eeiZTY/P9b1FzRwfKWuk9p/72ct+N puKpq32qLVaexOCCJB91aezt5y6zt7fXILSdJZjlVr1w0mCR66x6FL3QOXiUQ2a0k/sFlDlq 1LzUMQ4uxxycjl0LWO1bBsY6yXR3wSTJGxqLhdsJHDsS9cwF47XlvcQGQiXhRbih/HkQv4XO cajZb6GDu7PTFEdPkVu0k4vQyd3Jc/SUwNnB+RJ/XsI9ptZDIxMly3dbLNwGnGBJF+Id3cZM 9ui8Gjq5P/TDiRCegbOFgSKRo5e7yNHV2dnPdVb0bHfHQCevNIV/rxqrX48oFQdYcpKMtYRb juxtfqRypNACK28+j3FsqcilAD0ADuIWCt0yRa7zRNEOY2YELhW5CV2dXVKixH8BC+s8GDN9 wWKxf94zpsRiJuWmBYjgndsKFmu5Bc+D3HQXCcu7QTFTMl3HF0SLxruLvGa4zUqdMGFWqqfX 3GSxN0y6NT154i+v75zvH2thXiWgY2YVElhwYl9NYxarlr0grlQn92DQt1vBUk+nUFeHGZme gUIvl1RXr1AnV/fx6zd4v3HptM/YaXbrzmYFePu2WpowYRlJo+2PGLb2d9WE5bw1L4DcnOco 9HIcH3o02HOecMqMJhQqdLPXpArHl2uEo+Na8qZPXxw0+bVx46bFzhw3eZylM2dgwkbWW3Iy Jp9lMDe9H2/raiqPCy5/fHSCu+M7mkffoQuzQhvRhWVlj1FcWTfq6dwdElJmarxedr/u3P6C Nn7Fk95ol8wRjIMsOLGJSwLm/OMGjlFHJ7hqelDuxdMlpbU16JvqlJTamivoBjrfUgNB69zf b6Fr1TWPKmtOw9xCdLayEFWvBlaSfmEBsk6LSdTMNnQaldTe7Qfj20yveddR2toVEevCi9/f fmntR7ErtvompmyICM9qyYpZsG3FhqwNYRH5KUtyW7eGRRxfH1OHDv0ZXH6ihbSyVYzSY3Fu BkVR9LaS2wPxUxyTFpu2eGverr+dezvi0ttpOy/tTKlL2ZkWs6p4VV1Kyq60nevS8iLyi1tW hfNWzMfhYT+ArAQ+5odRBENjlRW5F/vH6O7u7urpXtvR/bQbmX/dPd3w7Ok+2Ij4ry5o0N/d Y1p7qA21FodhFRc1ctjIsXZ2Y18VcwCixNgcWlgVbUiue3b3J33te7497vv/oT1Bj5/7br1R grYlfrReSqmwPDyK0GqOUHKWj/RwP0J0ZlmsK3o2HP+7Qt9HBr3BYH5aNL3FG/+ul8sjKcxH dRJFGJkhfKxgmM2rUoaSg5h4GAwXJsF00dRGq+/21k2EF7o50oNswrNfsYUQKRBIZWIFh3lu aLNe1F++bjXGyWyzZiGoYFYLx5Ys4v0R3GWRdBHNErBiSiqVRhHMyeaYrMQ4SENWCvEcfhCm GIzpqKlm27KTSWUcAX1goBw5oATctDb33aLTYV5SWoaXP5+gyqlFdnZ23nB+plcnREv0RWJC BVkrrBJ1BewMmlVpgRUQF7wpItMJTcsJ34GBRVaFdQZaqoqxFmSb3qDQgu1A2GI4YAnODkQY IOhklDKzo2C1IV2sijzdhjorqwefNdL6ihxzegU7SynexHgBMXy+xWFG8qvdf91D8WpRi41q KFl02YaswYNkULTeLC9CFFK4bDHDMmZbhnuXSOdAsnN1LxgfVu7ZvG8LpSJUlO/gnaWQFwYv JpZeKdUaSC8ApuhIShYQYp5yWQ0oPgVXPtkcHz/fx5rqqzosHSSlBYHIxKSolJcUsIIpnzkh mt4b7Z/tOzBRQWaA6uNCNdet0nxLkL8CgzeQKIlCXaHjXR9MlqQn9Y1fNd5RE0zF/ryKwVR/ JMnsI3S8Umcw6NRYxRuUKqk3lfnKeGcTySAx5hy+7WfgZOv4uLLl0w8wUah71QLBpJeXq/eM VVivV8jz6lB2ofWF6i1dEYRZfMJ4piE+ZweNeb7A2VVyKEx6vjt1z/ghMehVKiUpyt1VYBXC N6j0Q4Mazp7TvvndhIaGhqqvP1bwFk0YRYR5RoLR+PkWmlIpV/oEDQ6jB9Wc3Z6bm6zLTtLl gLC4LVWXz5Q1ffbV5oZ24wmsV/NeKTlirmg+u/q7w7/38PDdeKF8UBgXs2kV4WUC0YR/KOLv Pby3L5O30yvG9vY/6vX8JSbb2je96coXX5QPznqfokKKEPWBAwd20ApaTWsP7LnTfsd42at3 +B+H7+zRUfwZZMutN6baHCX5+Ou9Zy4f3nuiKr7KaHxoNDbsSwhp6htvfyg3Zw901G+ttVlT Ja34/E+fvrXmvY3713xy6tSZfadOJby7X1P/vwn/MeaYr0mF7IMEq690Gu95KwQq5L5K+f59 qGUtaZMSciHMKjdVbY6zFqRC/pv3LgxY5tcW0pjIpGGJ7+89kxBnbXZSmjuz7CeyihyG8fbd XXYdrWlqQg+sZWTdzPqBB68VEdnkzDY0lHSjSD9/GRpaMt3OWqLpQENOTf/PpP8CK9ZVVe2a 8XoAAAAASUVORK5CYII= --------------6B3944540BEDFBD3702FFA05-- --------------34264417537514D063CD9EE1-- From nobody Thu Jul 20 04:43:24 2017 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 1F88C12EA7C for ; Thu, 20 Jul 2017 04:43:22 -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, HTML_MESSAGE=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 5sgcpsANqgdL for ; Thu, 20 Jul 2017 04:43: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 44B2D12EC30 for ; Thu, 20 Jul 2017 04:43:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id A050730056B for ; Thu, 20 Jul 2017 07:43:18 -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 Ew8m63dEWgCo for ; Thu, 20 Jul 2017 07:43:15 -0400 (EDT) Received: from [5.5.33.149] (vpn.snozzages.com [204.42.252.17]) by mail.smeinc.net (Postfix) with ESMTPSA id 61913300278; Thu, 20 Jul 2017 07:43:14 -0400 (EDT) From: Russ Housley Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_B8F613D3-83BC-4509-87CB-C32278EF4994" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 20 Jul 2017 07:43:16 -0400 In-Reply-To: <04e73e42-7c5b-912d-cc79-7959a710927e@openca.org> Cc: LAMPS To: "Dr. Pala" References: <04e73e42-7c5b-912d-cc79-7959a710927e@openca.org> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [lamps] Considerations about the need to resume PKIX work X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 20 Jul 2017 11:43:22 -0000 --Apple-Mail=_B8F613D3-83BC-4509-87CB-C32278EF4994 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Max: If you can turn these into separate charter items with a description of = the deliverable and milestones, then we can discuss each idea on its = own. Of course, in this group we expect that there be a commitment that = it will be implemented. Russ > On Jul 20, 2017, at 7:37 AM, Dr. Pala wrote: >=20 > Hi all, >=20 > I would like to draw the Sec Area attention on an issue that I think = is becoming more relevant every day. > It seems quite clear that today there is a lot of work around = authentication and encryption that make use of PKIX certificates. = However, there is no place in IETF, today, where problems related to = PKIX can be effectively tackled. In the following paragraphs I try to = summarize the issue and the proposed work and a call for discussion = around the feasibility of resuming the work in two particular areas: = revocation and discoverability. >=20 > The Problem >=20 > What I noticed in recent proposals in many working groups (when it = comes to certificate management) is that more and more people turn = towards the use of short-lived certificates to avoid checking = revocation information. Sometimes this choice is motivated by real = technical considerations, but in many cases the choice is "forced" = because nobody is currently working on fixing the two main issues = related to trust infrastructures: efficient revocation and = discoverability of services. >=20 > The Revocation Situation > Most of the times, when interacting with PKIs, we are still stuck with = CRLs, OCSP if we are lucky (including stapling - available in TLS = connections if really really lucky), and in most cases even these = mechanisms are criticized widely by people as being inadequate today. = This resulted in applications to use proprietary methods for checking = revocation (e.g., CRLSet) or to skip checking all together (or mandate = for short-lived certificates only as in the case, for example, of STIR). >=20 > Many people today ignore the fact that, when coupled with small = devices, the generation of new keys require (a) a lot of resources, and = (b) a good source of randomness. Requiring apps / devices to generate = new keys might seem a good idea at first, but is this better than = checking revocation ? What about the complexity of key management ? > Examples of possible work to address the issues are OCSP over DNS and = some more efficient ways to verify the validity of a whole chain of = certificates efficiently. > The Discoverability Situation >=20 > As far as I know, there are no standardized mechanisms that would = provide discoverability of services that would help users and = applications to discover Public Key Services providers and associated = services in a dynamic fashion. When I brought it up during the BoFs of = possible working groups where the issue could be discussed.. well, the = proposal was redirected to /dev/null (e.g., ACME, SPASM, and LAMPS). > Isn't that curious that still today nobody is working on some sort of = infrastructure that would facilitate interacting with PKIs ? After all, = PKIs are the core Trust mechanism that enables reliable authentication = and encryption over the Internet today. Such infrastructure could really = improve the security of the Internet and make PKIs more usable from an = application (and users) standpoint of view. >=20 > Examples of possible work to address the issue are a PKI Resource = Query Protocol (PRQP) and/or the use of P2P systems as distribution = mechanisms for Public Key related operations (e.g., EST, BRSKI, or ACME = over P2P - 0-configuration support for PK). > Deployment Trends in the Real World > Today I am witnessing the deployment of arguably not-well-designed = PKIs (or, in other terms, what I call Weak PKIs) that do not provide = support for revocation and that are expected to use CAs and EE = certificates with validity periods of 30, 35, or 50 years (yes, also EE = - especially for devices). Besides the fact that it is a common = assumption that the algorithms (e.g., P-256) used in these environments = (e.g. IoT) are NOT going to pass the test of time, ignoring the = revocation could really affect the privacy of millions of people - and = we are currently not doing anything at the IETF to prevent this issue. >=20 > There is the need for simple revocation services, but arguably we do = not have what's needed today (requires improvements). > IETF Specific Situation and Issues > Why are we so unprepared to face these issues ? I would say (still = personal point of view - based on almost 20 yrs of participation in PKI = discussions) that these might be some of the main reasons: >=20 > There are NO venues where to discuss possible solutions to existing = problems. The PKIX working group has been closed down (very arbitrarily, = I might say, since there is still a lot of work needed to be done around = PKIX as highlighted above) >=20 > The LAMPS, SPASM, and ACME WGs have/have had, on purpose, very narrow = scoped Charters and only few items (mostly quite marginal issues, IMO) = are actually accepted as working items (w/ reference to SPASM and LAMPS = in particular). Solving revocation and discoverability issues should be = the 1st item and the most important on the list (at least revocation) = but they are not - actually when that was proposed to be included as = part of the charter(s), the requests were not even acknowledged or = rejected with no real technical reasons. >=20 > The constant nonsense of people saying that PKIs do not work as an = excuse not to improve them while they (PKIs) are the reason we can = deploy secure protocols and provide privacy. It is evident that PKIs are = here to stay, this is a fact. Their usage has increased exponentially in = the past years and they have, so far, passed the test of time. IoT is = one use-case. ANIMA is another. ACME is another. Just to cite few of = them. > Moreover, things are happening in environments outside IETF (WIFI 2.0 = Alliance, OpenADR, CMI, etc.) and IETF un-willingness of working on = these problems is really scary to me. The world moves forward, fast, and = the IETF is standing still on this topic. I really do not understand = why. >=20 > Final Considerations >=20 > In this message I try to summarize the reasons why I think there is = the need to provide a venue where these problems are discussed and the = need for key people to not actively block the possibility for people = that are willing to work on this to have a venue where the work can be = carried out. >=20 > I think that this work is of the utter importance and I would like to = understand what the position of the whole security area is around these = points and the proposed work. >=20 > I hope that the discussion around this message can spark some interest = and that work in the PKIX area can finally resume at the IETF - which = was, in the past, thought of as the lighthouse where these issues could = be addressed. >=20 > A small request, please, try to read this e-mail carefully and = consider the implications of NOT taking on these tasks when replying = and/or discussing the topic. Also, since I know this (PKIX) is a = minefield for "political" reasons (which should not be a drive here), = please keep the discussion on the positive / constructive side (thanks). >=20 > If you feel like a private response is better than on the mailing = list, please just reply privately. >=20 > Looking forward to hear your opinions on this hoping that this e-mail = can be the beginning of the end of PKIX still-standing issues :D >=20 > Cheers, > Max >=20 > --=20 > Best Regards, > Massimiliano Pala, Ph.D. > OpenCA Labs Director > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm --Apple-Mail=_B8F613D3-83BC-4509-87CB-C32278EF4994 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Max:

If you can turn these into separate charter items with a description of the deliverable and milestones, then we can discuss each idea on its own.  Of course, in this group we expect that there be a commitment that it will be implemented.

Russ


On Jul 20, 2017, at 7:37 AM, Dr. Pala <director@openca.org> wrote:

Hi all,

I would like to draw the Sec Area attention on an issue that I think is becoming more relevant every day.

It seems quite clear that today there is a lot of work around authentication and encryption that make use of PKIX certificates. However, there is no place in IETF, today, where problems related to PKIX can be effectively tackled. In the following paragraphs I try to summarize the issue and the proposed work and a call for discussion around the feasibility of resuming the work in two particular areas: revocation and discoverability.

The Problem

What I noticed in recent proposals in many working groups (when it comes to certificate management) is that more and more people turn towards the use of short-lived certificates to avoid checking revocation information. Sometimes this choice is motivated by real technical considerations, but in many cases the choice is "forced" because nobody is currently working on fixing the two main issues related to trust infrastructures: efficient revocation and discoverability of services.

The Revocation Situation

Most of the times, when interacting with PKIs, we are still stuck with CRLs, OCSP if we are lucky (including stapling - available in TLS connections if really really lucky), and in most cases even these mechanisms are criticized widely by people as being inadequate today. This resulted in applications to use proprietary methods for checking revocation (e.g., CRLSet) or to skip checking all together (or mandate for short-lived certificates only as in the case, for example, of STIR).

Many people today ignore the fact that, when coupled with small devices, the generation of new keys require (a) a lot of resources, and (b) a good source of randomness. Requiring apps / devices to generate new keys might seem a good idea at first, but is this better than checking revocation ? What about the complexity of key management ?

Examples of possible work to address the issues are OCSP over DNS and some more efficient ways to verify the validity of a whole chain of certificates efficiently.

The Discoverability Situation

As far as I know, there are no standardized mechanisms that would provide discoverability of services that would help users and applications to discover Public Key Services providers and associated services in a dynamic fashion. When I brought it up during the BoFs of possible working groups where the issue could be discussed.. well, the proposal was redirected to /dev/null (e.g., ACME, SPASM, and LAMPS).

Isn't that curious that still today nobody is working on some sort of infrastructure that would facilitate interacting with PKIs ? After all, PKIs are the core Trust mechanism that enables reliable authentication and encryption over the Internet today. Such infrastructure could really improve the security of the Internet and make PKIs more usable from an application (and users) standpoint of view.

Examples of possible work to address the issue are a PKI Resource Query Protocol (PRQP) and/or the use of P2P systems as distribution mechanisms for Public Key related operations (e.g., EST, BRSKI, or ACME over P2P - 0-configuration support for PK).

Deployment Trends in the Real World

Today I am witnessing the deployment of arguably not-well-designed PKIs (or, in other terms, what I call Weak PKIs) that do not provide support for revocation and that are expected to use CAs and EE certificates with validity periods of 30, 35, or 50 years (yes, also EE - especially for devices). Besides the fact that it is a common assumption that the algorithms (e.g., P-256) used in these environments (e.g. IoT) are NOT going to pass the test of time, ignoring the revocation could really affect the privacy of millions of people - and we are currently not doing anything at the IETF to prevent this issue.

There is the need for simple revocation services, but arguably we do not have what's needed today (requires improvements).

IETF Specific Situation and Issues

Why are we so unprepared to face these issues ? I would say (still personal point of view - based on almost 20 yrs of participation in PKI discussions) that these might be some of the main reasons:

  • There are NO venues where to discuss possible solutions to existing problems. The PKIX working group has been closed down (very arbitrarily, I might say, since there is still a lot of work needed to be done around PKIX as highlighted above)

  • The LAMPS, SPASM, and ACME WGs have/have had, on purpose, very narrow scoped Charters and only few items (mostly quite marginal issues, IMO) are actually accepted as working items (w/ reference to SPASM and LAMPS in particular). Solving revocation and discoverability issues should be the 1st item and the most important on the list (at least revocation) but they are not - actually when that was proposed to be included as part of the charter(s), the requests were not even acknowledged or rejected with no real technical reasons.

  • The constant nonsense of people saying that PKIs do not work as an excuse not to improve them while they (PKIs) are the reason we can deploy secure protocols and provide privacy. It is evident that PKIs are here to stay, this is a fact. Their usage has increased exponentially in the past years and they have, so far, passed the test of time. IoT is one use-case. ANIMA is another. ACME is another. Just to cite few of them.

Moreover, things are happening in environments outside IETF (WIFI 2.0 Alliance, OpenADR, CMI, etc.) and IETF un-willingness of working on these problems is really scary to me. The world moves forward, fast, and the IETF is standing still on this topic. I really do not understand why.

Final Considerations

In this message I try to summarize the reasons why I think there is the need to provide a venue where these problems are discussed and the need for key people to not actively block the possibility for people that are willing to work on this to have a venue where the work can be carried out.

I think that this work is of the utter importance and I would like to understand what the position of the whole security area is around these points and the proposed work.

I hope that the discussion around this message can spark some interest and that work in the PKIX area can finally resume at the IETF - which was, in the past, thought of as the lighthouse where these issues could be addressed.

A small request, please, try to read this e-mail carefully and consider the implications of NOT taking on these tasks when replying and/or discussing the topic. Also, since I know this (PKIX) is a minefield for "political" reasons (which should not be a drive here), please keep the discussion on the positive / constructive side (thanks).

If you feel like a private response is better than on the mailing list, please just reply privately.

Looking forward to hear your opinions on this hoping that this e-mail can be the beginning of the end of PKIX still-standing issues :D

Cheers,
Max

--
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
<efhklhncoknghhph.png>
_______________________________________________
Spasm mailing list
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm

--Apple-Mail=_B8F613D3-83BC-4509-87CB-C32278EF4994-- From nobody Thu Jul 20 04:53:36 2017 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 4C87912EC30 for ; Thu, 20 Jul 2017 04:53:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_HK_NAME_DR=0.01] 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 KggprZMobWeC for ; Thu, 20 Jul 2017 04:53:25 -0700 (PDT) Received: from mail.katezarealty.com (mail.katezarealty.com [104.168.158.213]) by ietfa.amsl.com (Postfix) with ESMTP id B06D812969E for ; Thu, 20 Jul 2017 04:53:25 -0700 (PDT) Received: from dhcp-8e48.meeting.ietf.org (dhcp-8e48.meeting.ietf.org [31.133.142.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.katezarealty.com (Postfix) with ESMTPSA id D1E923740FB2 for ; Thu, 20 Jul 2017 07:53:24 -0400 (EDT) To: spasm@ietf.org References: <04e73e42-7c5b-912d-cc79-7959a710927e@openca.org> From: "Dr. Pala" Message-ID: <0f6d2715-b50a-3d29-09e6-4b75e5fb808a@openca.org> Date: Thu, 20 Jul 2017 13:53:22 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------90BCD11938447DD17C7AE12C" Content-Language: en-US Archived-At: Subject: Re: [lamps] Considerations about the need to resume PKIX work X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 20 Jul 2017 11:53:29 -0000 This is a multi-part message in MIME format. --------------90BCD11938447DD17C7AE12C Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Thanks Russ, will do. On 7/20/17 1:43 PM, Russ Housley wrote: > Max: > > If you can turn these into separate charter items with a description > of the deliverable and milestones, then we can discuss each idea on > its own. Of course, in this group we expect that there be a > commitment that it will be implemented. > > Russ > > >> On Jul 20, 2017, at 7:37 AM, Dr. Pala > > wrote: >> >> Hi all, >> >> I would like to draw the Sec Area attention on an issue that I think >> is becoming more relevant every day. >> >> It seems quite clear that today there is a lot of work around >> authentication and encryption that make use of PKIX certificates. >> However, there is no place in IETF, today, where problems related to >> PKIX can be effectively tackled. In the following paragraphs I try to >> summarize the issue and the proposed work and a call for discussion >> around the feasibility of resuming the work in two particular areas: >> revocation and discoverability. >> >> *The Problem >> >> *What I noticed in recent proposals in many working groups (when it >> comes to certificate management) is that more and more people turn >> towards the use of short-lived certificates to avoid checking >> revocation information. Sometimes this choice is motivated by real >> technical considerations, but in many cases the choice is "forced" >> because nobody is currently working on fixing the two main issues >> related to trust infrastructures: efficient revocation and >> discoverability of services. >> >> *The Revocation Situation* >> >> Most of the times, when interacting with PKIs, we are still stuck >> with CRLs, OCSP if we are lucky (including stapling - available in >> TLS connections if really really lucky), and in most cases even these >> mechanisms are criticized widely by people as being inadequate today. >> This resulted in applications to use proprietary methods for checking >> revocation (e.g., CRLSet) or to skip checking all together (or >> mandate for short-lived certificates only as in the case, for >> example, of STIR). >> >> Many people today ignore the fact that, when coupled with small >> devices, the generation of new keys require (a) a lot of resources, >> and (b) a good source of randomness. Requiring apps / devices to >> generate new keys might seem a good idea at first, but is this better >> than checking revocation ? What about the complexity of key management ? >> >> /Examples of possible work to address the issues are OCSP over DNS >> and some more efficient ways to verify the validity of a whole chain >> of certificates efficiently./ >> >> *The Discoverability Situation* >> >> As far as I know, there are no standardized mechanisms that would >> provide discoverability of services that would help users and >> applications to discover Public Key Services providers and associated >> services in a dynamic fashion. When I brought it up during the BoFs >> of possible working groups where the issue could be discussed.. well, >> the proposal was redirected to /dev/null (e.g., ACME, SPASM, and LAMPS). >> >> Isn't that curious that still today nobody is working on some sort of >> infrastructure that would facilitate interacting with PKIs ? After >> all, PKIs are the core Trust mechanism that enables reliable >> authentication and encryption over the Internet today. Such >> infrastructure could really improve the security of the Internet and >> make PKIs more usable from an application (and users) standpoint of view. >> >> /Examples of possible work to address the issue are a PKI Resource >> Query Protocol (PRQP) and/or the use of P2P systems as distribution >> mechanisms for Public Key related operations (e.g., EST, BRSKI, or >> ACME over P2P - 0-configuration support for PK)./ >> >> *Deployment Trends in the Real World* >> >> Today I am witnessing the deployment of arguably not-well-designed >> PKIs (or, in other terms, what I call Weak PKIs) that do not provide >> support for revocation and that are expected to use CAs and EE >> certificates with validity periods of 30, 35, or 50 years (yes, also >> EE - especially for devices). Besides the fact that it is a common >> assumption that the algorithms (e.g., P-256) used in these >> environments (e.g. IoT) are NOT going to pass the test of time, >> ignoring the revocation could really affect the privacy of millions >> of people - and we are currently not doing anything at the IETF to >> prevent this issue. >> >> /There is the need for simple revocation services, but arguably we do >> not have what's needed today (requires improvements)./ >> >> *IETF Specific Situation and Issues* >> >> Why are we so unprepared to face these issues ? I would say (still >> personal point of view - based on almost 20 yrs of participation in >> PKI discussions) that these might be some of the main reasons: >> >> * *There are NO venues where to discuss possible solutions to >> existing problems.* The PKIX working group has been closed down >> (very arbitrarily, I might say, since there is still a lot of >> work needed to be done around PKIX as highlighted above) >> >> * *The LAMPS, SPASM, and ACME WGs have/have had, on purpose, very >> narrow scoped Charters and only few items**(mostly quite marginal >> issues, IMO) are actually accepted as working items (w/ reference >> to SPASM and LAMPS in particular).* Solving revocation and >> discoverability issues should be the 1st item and the most >> important on the list (at least revocation) but they are not - >> actually when that was proposed to be included as part of the >> charter(s), the requests were not even acknowledged or rejected >> with no real technical reasons. >> >> * *The constant**nonsense of people saying that PKIs do not work as >> an excuse not to improve them while they (PKIs) are the reason we >> can deploy secure protocols and provide privacy. *It is evident >> that PKIs are here to stay, this is a fact. Their usage has >> increased exponentially in the past years and they have, so far, >> passed the test of time. IoT is one use-case. ANIMA is another. >> ACME is another. Just to cite few of them. >> >> Moreover, things are happening in environments outside IETF (WIFI 2.0 >> Alliance, OpenADR, CMI, etc.) and IETF un-willingness of working on >> these problems is really scary to me. The world moves forward, fast, >> and the IETF is standing still on this topic./*I really do not >> understand why.*/ >> >> *Final Considerations* >> >> In this message I try to summarize the reasons why I think there is >> the need to provide a venue where these problems are discussed and >> the need for key people to not actively block the possibility for >> people that are willing to work on this to have a venue where the >> work can be carried out. >> >> I think that this work is of the utter importance and I would like to >> understand what the position of the whole security area is around >> these points and the proposed work. >> >> /I hope that the discussion around this message can spark some >> interest and that work in the PKIX area can finally resume at the >> IETF - which was, in the past, thought of as the lighthouse where >> these issues could be addressed./ >> >> A small request, please, try to read this e-mail carefully and >> consider the implications of NOT taking on these tasks when replying >> and/or discussing the topic. Also, since I know this (PKIX) is a >> minefield for "political" reasons (which should not be a drive here), >> please keep the discussion on the positive / constructive side (thanks). >> >> /If you feel like a private response is better than on the mailing >> list, please just reply privately./ >> >> Looking forward to hear your opinions on this hoping that this e-mail >> can be the beginning of the end of PKIX still-standing issues :D >> >> Cheers, >> Max >> >> -- >> Best Regards, >> Massimiliano Pala, Ph.D. >> OpenCA Labs Director >> >> _______________________________________________ >> Spasm mailing list >> Spasm@ietf.org >> https://www.ietf.org/mailman/listinfo/spasm > > > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm --------------90BCD11938447DD17C7AE12C Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Thanks Russ, will do.


On 7/20/17 1:43 PM, Russ Housley wrote:
Max:

If you can turn these into separate charter items with a description of the deliverable and milestones, then we can discuss each idea on its own.  Of course, in this group we expect that there be a commitment that it will be implemented.

Russ


On Jul 20, 2017, at 7:37 AM, Dr. Pala <director@openca.org> wrote:

Hi all,

I would like to draw the Sec Area attention on an issue that I think is becoming more relevant every day.

It seems quite clear that today there is a lot of work around authentication and encryption that make use of PKIX certificates. However, there is no place in IETF, today, where problems related to PKIX can be effectively tackled. In the following paragraphs I try to summarize the issue and the proposed work and a call for discussion around the feasibility of resuming the work in two particular areas: revocation and discoverability.

The Problem

What I noticed in recent proposals in many working groups (when it comes to certificate management) is that more and more people turn towards the use of short-lived certificates to avoid checking revocation information. Sometimes this choice is motivated by real technical considerations, but in many cases the choice is "forced" because nobody is currently working on fixing the two main issues related to trust infrastructures: efficient revocation and discoverability of services.

The Revocation Situation

Most of the times, when interacting with PKIs, we are still stuck with CRLs, OCSP if we are lucky (including stapling - available in TLS connections if really really lucky), and in most cases even these mechanisms are criticized widely by people as being inadequate today. This resulted in applications to use proprietary methods for checking revocation (e.g., CRLSet) or to skip checking all together (or mandate for short-lived certificates only as in the case, for example, of STIR).

Many people today ignore the fact that, when coupled with small devices, the generation of new keys require (a) a lot of resources, and (b) a good source of randomness. Requiring apps / devices to generate new keys might seem a good idea at first, but is this better than checking revocation ? What about the complexity of key management ?

Examples of possible work to address the issues are OCSP over DNS and some more efficient ways to verify the validity of a whole chain of certificates efficiently.

The Discoverability Situation

As far as I know, there are no standardized mechanisms that would provide discoverability of services that would help users and applications to discover Public Key Services providers and associated services in a dynamic fashion. When I brought it up during the BoFs of possible working groups where the issue could be discussed.. well, the proposal was redirected to /dev/null (e.g., ACME, SPASM, and LAMPS).

Isn't that curious that still today nobody is working on some sort of infrastructure that would facilitate interacting with PKIs ? After all, PKIs are the core Trust mechanism that enables reliable authentication and encryption over the Internet today. Such infrastructure could really improve the security of the Internet and make PKIs more usable from an application (and users) standpoint of view.

Examples of possible work to address the issue are a PKI Resource Query Protocol (PRQP) and/or the use of P2P systems as distribution mechanisms for Public Key related operations (e.g., EST, BRSKI, or ACME over P2P - 0-configuration support for PK).

Deployment Trends in the Real World

Today I am witnessing the deployment of arguably not-well-designed PKIs (or, in other terms, what I call Weak PKIs) that do not provide support for revocation and that are expected to use CAs and EE certificates with validity periods of 30, 35, or 50 years (yes, also EE - especially for devices). Besides the fact that it is a common assumption that the algorithms (e.g., P-256) used in these environments (e.g. IoT) are NOT going to pass the test of time, ignoring the revocation could really affect the privacy of millions of people - and we are currently not doing anything at the IETF to prevent this issue.

There is the need for simple revocation services, but arguably we do not have what's needed today (requires improvements).

IETF Specific Situation and Issues

Why are we so unprepared to face these issues ? I would say (still personal point of view - based on almost 20 yrs of participation in PKI discussions) that these might be some of the main reasons:

  • There are NO venues where to discuss possible solutions to existing problems. The PKIX working group has been closed down (very arbitrarily, I might say, since there is still a lot of work needed to be done around PKIX as highlighted above)

  • The LAMPS, SPASM, and ACME WGs have/have had, on purpose, very narrow scoped Charters and only few items (mostly quite marginal issues, IMO) are actually accepted as working items (w/ reference to SPASM and LAMPS in particular). Solving revocation and discoverability issues should be the 1st item and the most important on the list (at least revocation) but they are not - actually when that was proposed to be included as part of the charter(s), the requests were not even acknowledged or rejected with no real technical reasons.

  • The constant nonsense of people saying that PKIs do not work as an excuse not to improve them while they (PKIs) are the reason we can deploy secure protocols and provide privacy. It is evident that PKIs are here to stay, this is a fact. Their usage has increased exponentially in the past years and they have, so far, passed the test of time. IoT is one use-case. ANIMA is another. ACME is another. Just to cite few of them.

Moreover, things are happening in environments outside IETF (WIFI 2.0 Alliance, OpenADR, CMI, etc.) and IETF un-willingness of working on these problems is really scary to me. The world moves forward, fast, and the IETF is standing still on this topic. I really do not understand why.

Final Considerations

In this message I try to summarize the reasons why I think there is the need to provide a venue where these problems are discussed and the need for key people to not actively block the possibility for people that are willing to work on this to have a venue where the work can be carried out.

I think that this work is of the utter importance and I would like to understand what the position of the whole security area is around these points and the proposed work.

I hope that the discussion around this message can spark some interest and that work in the PKIX area can finally resume at the IETF - which was, in the past, thought of as the lighthouse where these issues could be addressed.

A small request, please, try to read this e-mail carefully and consider the implications of NOT taking on these tasks when replying and/or discussing the topic. Also, since I know this (PKIX) is a minefield for "political" reasons (which should not be a drive here), please keep the discussion on the positive / constructive side (thanks).

If you feel like a private response is better than on the mailing list, please just reply privately.

Looking forward to hear your opinions on this hoping that this e-mail can be the beginning of the end of PKIX still-standing issues :D

Cheers,
Max

--
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
<efhklhncoknghhph.png>
_______________________________________________
Spasm mailing list
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm



_______________________________________________
Spasm mailing list
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm

--------------90BCD11938447DD17C7AE12C-- From nobody Fri Jul 21 00:50:05 2017 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 9886C1316E2 for ; Fri, 21 Jul 2017 00:50:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.002 X-Spam-Level: X-Spam-Status: No, score=-7.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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=eff.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 Z2yEsLNsaE2d for ; Fri, 21 Jul 2017 00:50:02 -0700 (PDT) Received: from mail2.eff.org (mail2.eff.org [173.239.79.204]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3ED8012714F for ; Fri, 21 Jul 2017 00:50:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date:Message-ID:To:Subject:From; bh=PVbejKo8dWx/jDCq8dFOGTOiVo87W4tQ9kIfykrBmeA=; b=ZzbKwVD54NQ/Sg3NANlLrW0HC8q/HveCPxcirysuPRFeFLDq+4IuEwtRuK9/9Mhg6R6sIyIUkT7qxVuY2Xj9/q6yuPR8QSxqfMD1gOv7sNH5As/NGzn1+I/hKjp3rMcLmOZ8ODxLGko3HNybjEsN/6Ep7N3V8J3xwDlIuXRxPrg=; Received: ; Fri, 21 Jul 2017 00:50:00 -0700 From: Jacob Hoffman-Andrews To: SPASM Message-ID: <7c3d47dd-ddfe-7afe-3a63-f21fd1c614d6@eff.org> Date: Fri, 21 Jul 2017 00:50:01 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [lamps] CAA update status X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 21 Jul 2017 07:50:04 -0000 I missed dialing into the LAMPS session at IETF 99, but it sounds like erratum 5065 (https://www.rfc-editor.org/errata/eid5065) was discussed and there was general consensus on moving it forward. What still needs to happen in order for it to get moved to "Held for Document Update" status so the CA/Browser Forum can hold a ballot on it? From nobody Fri Jul 21 02:51:01 2017 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 0303D129B40 for ; Fri, 21 Jul 2017 02:51:00 -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, 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 jnqCwFzYZwDh for ; Fri, 21 Jul 2017 02:50:58 -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 E698712EE45 for ; Fri, 21 Jul 2017 02:50:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 317AA30050A for ; Fri, 21 Jul 2017 05:50:57 -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 xLphpKT2Kup2 for ; Fri, 21 Jul 2017 05:50:56 -0400 (EDT) Received: from [5.5.33.183] (vpn.snozzages.com [204.42.252.17]) by mail.smeinc.net (Postfix) with ESMTPSA id 88CD4300429; Fri, 21 Jul 2017 05:50:55 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Russ Housley In-Reply-To: <7c3d47dd-ddfe-7afe-3a63-f21fd1c614d6@eff.org> Date: Fri, 21 Jul 2017 05:51:02 -0400 Cc: SPASM Content-Transfer-Encoding: 7bit Message-Id: <70F123F5-4995-4631-99A6-D9145C86C7FD@vigilsec.com> References: <7c3d47dd-ddfe-7afe-3a63-f21fd1c614d6@eff.org> To: Jacob Hoffman-Andrews X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [lamps] CAA update status X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 21 Jul 2017 09:51:00 -0000 One of the Area Directors needs to take that action. Russ > On Jul 21, 2017, at 3:50 AM, Jacob Hoffman-Andrews wrote: > > I missed dialing into the LAMPS session at IETF 99, but it sounds like > erratum 5065 (https://www.rfc-editor.org/errata/eid5065) was discussed > and there was general consensus on moving it forward. What still needs > to happen in order for it to get moved to "Held for Document Update" > status so the CA/Browser Forum can hold a ballot on it? From nobody Sat Jul 22 08:39:08 2017 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 E2E66131A95; Thu, 20 Jul 2017 03:57:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_HK_NAME_DR=0.01] 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 o7qDoNj914-k; Thu, 20 Jul 2017 03:57:19 -0700 (PDT) Received: from mail.katezarealty.com (mail.katezarealty.com [104.168.158.213]) by ietfa.amsl.com (Postfix) with ESMTP id 886EB12F24E; Thu, 20 Jul 2017 03:57:19 -0700 (PDT) Received: from dhcp-8e48.meeting.ietf.org (dhcp-8e48.meeting.ietf.org [31.133.142.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.katezarealty.com (Postfix) with ESMTPSA id BF0D33740F3C; Thu, 20 Jul 2017 06:57:14 -0400 (EDT) To: "saag@ietf.org" , Kathleen Moriarty , Eric Rescorla , "Polk, Tim (Fed)" , Daniel Kahn Gillmor , Stephen Farrell , Stephen Kent , Paul Hoffman , Jim Schaad , Phillip Hallam-Baker , "Salz, Rich" , PKIX , LAMPS From: "Dr. Pala" Organization: OpenCA Labs Message-ID: <7c7eae56-a23d-0e57-bcc7-5a4b90f3852d@openca.org> Date: Thu, 20 Jul 2017 12:57:12 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------E4208EFAF51D177E0AC0D486" Content-Language: en-US Archived-At: X-Mailman-Approved-At: Sat, 22 Jul 2017 08:39:06 -0700 Subject: [lamps] Considerations about the need to resume PKIX work X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 20 Jul 2017 10:57:22 -0000 This is a multi-part message in MIME format. --------------E4208EFAF51D177E0AC0D486 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi all, I would like to draw the Sec Area attention on an issue that I think is becoming more relevant every day. It seems quite clear that today there is a lot of work around authentication and encryption that make use of PKIX certificates. However, there is no place in IETF, today, where problems related to PKIX can be effectively tackled. In the following paragraphs I try to summarize the issue and the proposed work and a call for discussion around the feasibility of resuming the work in two particular areas: revocation and discoverability. *The Problem *What I noticed in recent proposals in many working groups (when it comes to certificate management) is that more and more people turn towards the use of short-lived certificates to avoid checking revocation information. Sometimes this choice is motivated by real technical considerations, but in many cases the choice is "forced" because nobody is currently working on fixing the two main issues related to trust infrastructures: efficient revocation and discoverability of services. *The Revocation Situation* Most of the times, when interacting with PKIs, we are still stuck with CRLs, OCSP if we are lucky (including stapling - available in TLS connections if really really lucky), and in most cases even these mechanisms are criticized widely by people as being inadequate today. This resulted in applications to use proprietary methods for checking revocation (e.g., CRLSet) or to skip checking all together (or mandate for short-lived certificates only as in the case, for example, of STIR). Many people today ignore the fact that, when coupled with small devices, the generation of new keys require (a) a lot of resources, and (b) a good source of randomness. Requiring apps / devices to generate new keys might seem a good idea at first, but is this better than checking revocation ? What about the complexity of key management ? /Examples of possible work to address the issues are OCSP over DNS and some more efficient ways to verify the validity of a whole chain of certificates efficiently./ *The Discoverability Situation* As far as I know, there are no standardized mechanisms that would provide discoverability of services that would help users and applications to discover Public Key Services providers and associated services in a dynamic fashion. When I brought it up during the BoFs of possible working groups where the issue could be discussed.. well, the proposal was redirected to /dev/null (e.g., ACME, SPASM, and LAMPS). Isn't that curious that still today nobody is working on some sort of infrastructure that would facilitate interacting with PKIs ? After all, PKIs are the core Trust mechanism that enables reliable authentication and encryption over the Internet today. Such infrastructure could really improve the security of the Internet and make PKIs more usable from an application (and users) standpoint of view. /Examples of possible work to address the issue are a PKI Resource Query Protocol (PRQP) and/or the use of P2P systems as distribution mechanisms for Public Key related operations (e.g., EST, BRSKI, or ACME over P2P - 0-configuration support for PK)./ *Deployment Trends in the Real World* Today I am witnessing the deployment of arguably not-well-designed PKIs (or, in other terms, what I call Weak PKIs) that do not provide support for revocation and that are expected to use CAs and EE certificates with validity periods of 30, 35, or 50 years (yes, also EE - especially for devices). Besides the fact that it is a common assumption that the algorithms (e.g., P-256) used in these environments (e.g. IoT) are NOT going to pass the test of time, ignoring the revocation could really affect the privacy of millions of people - and we are currently not doing anything at the IETF to prevent this issue. /There is the need for simple revocation services, but arguably we do not have what's needed today (requires improvements)./ *IETF Specific Situation and Issues* Why are we so unprepared to face these issues ? I would say (still personal point of view - based on almost 20 yrs of participation in PKI discussions) that these might be some of the main reasons: * *There are NO venues where to discuss possible solutions to existing problems.* The PKIX working group has been closed down (very arbitrarily, I might say, since there is still a lot of work needed to be done around PKIX as highlighted above) * *The LAMPS, SPASM, and ACME WGs have/have had, on purpose, very narrow scoped Charters and only few items**(mostly quite marginal issues, IMO) are actually accepted as working items (w/ reference to SPASM and LAMPS in particular).* Solving revocation and discoverability issues should be the 1st item and the most important on the list (at least revocation) but they are not - actually when that was proposed to be included as part of the charter(s), the requests were not even acknowledged or rejected with no real technical reasons. * *The constant**nonsense of people saying that PKIs do not work as an excuse not to improve them while they (PKIs) are the reason we can deploy secure protocols and provide privacy. *It is evident that PKIs are here to stay, this is a fact. Their usage has increased exponentially in the past years and they have, so far, passed the test of time. IoT is one use-case. ANIMA is another. ACME is another. Just to cite few of them. Moreover, things are happening in environments outside IETF (WIFI 2.0 Alliance, OpenADR, CMI, etc.) and IETF un-willingness of working on these problems is really scary to me. The world moves forward, fast, and the IETF is standing still on this topic./*I really do not understand why.*/ *Final Considerations* In this message I try to summarize the reasons why I think there is the need to provide a venue where these problems are discussed and the need for key people to not actively block the possibility for people that are willing to work on this to have a venue where the work can be carried out. I think that this work is of the utter importance and I would like to understand what the position of the whole security area is around these points and the proposed work. /I hope that the discussion around this message can spark some interest and that work in the PKIX area can finally resume at the IETF - which was, in the past, thought of as the lighthouse where these issues could be addressed./ A small request, please, try to read this e-mail carefully and consider the implications of NOT taking on these tasks when replying and/or discussing the topic. Also, since I know this (PKIX) is a minefield for "political" reasons (which should not be a drive here), please keep the discussion on the positive / constructive side (thanks). /If you feel like a private response is better than on the mailing list, please just reply privately./ Looking forward to hear your opinions on this hoping that this e-mail can be the beginning of the end of PKIX still-standing issues :D Cheers, Max -- Best Regards, Massimiliano Pala, Ph.D. OpenCA Labs Director OpenCA Logo --------------E4208EFAF51D177E0AC0D486 Content-Type: multipart/related; boundary="------------69BB6B0D37D905F5BC3DC393" --------------69BB6B0D37D905F5BC3DC393 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

Hi all,

I would like to draw the Sec Area attention on an issue that I think is becoming more relevant every day.

It seems quite clear that today there is a lot of work around authentication and encryption that make use of PKIX certificates. However, there is no place in IETF, today, where problems related to PKIX can be effectively tackled. In the following paragraphs I try to summarize the issue and the proposed work and a call for discussion around the feasibility of resuming the work in two particular areas: revocation and discoverability.

The Problem

What I noticed in recent proposals in many working groups (when it comes to certificate management) is that more and more people turn towards the use of short-lived certificates to avoid checking revocation information. Sometimes this choice is motivated by real technical considerations, but in many cases the choice is "forced" because nobody is currently working on fixing the two main issues related to trust infrastructures: efficient revocation and discoverability of services.

The Revocation Situation

Most of the times, when interacting with PKIs, we are still stuck with CRLs, OCSP if we are lucky (including stapling - available in TLS connections if really really lucky), and in most cases even these mechanisms are criticized widely by people as being inadequate today. This resulted in applications to use proprietary methods for checking revocation (e.g., CRLSet) or to skip checking all together (or mandate for short-lived certificates only as in the case, for example, of STIR).

Many people today ignore the fact that, when coupled with small devices, the generation of new keys require (a) a lot of resources, and (b) a good source of randomness. Requiring apps / devices to generate new keys might seem a good idea at first, but is this better than checking revocation ? What about the complexity of key management ?

Examples of possible work to address the issues are OCSP over DNS and some more efficient ways to verify the validity of a whole chain of certificates efficiently.

The Discoverability Situation

As far as I know, there are no standardized mechanisms that would provide discoverability of services that would help users and applications to discover Public Key Services providers and associated services in a dynamic fashion. When I brought it up during the BoFs of possible working groups where the issue could be discussed.. well, the proposal was redirected to /dev/null (e.g., ACME, SPASM, and LAMPS).

Isn't that curious that still today nobody is working on some sort of infrastructure that would facilitate interacting with PKIs ? After all, PKIs are the core Trust mechanism that enables reliable authentication and encryption over the Internet today. Such infrastructure could really improve the security of the Internet and make PKIs more usable from an application (and users) standpoint of view.

Examples of possible work to address the issue are a PKI Resource Query Protocol (PRQP) and/or the use of P2P systems as distribution mechanisms for Public Key related operations (e.g., EST, BRSKI, or ACME over P2P - 0-configuration support for PK).

Deployment Trends in the Real World

Today I am witnessing the deployment of arguably not-well-designed PKIs (or, in other terms, what I call Weak PKIs) that do not provide support for revocation and that are expected to use CAs and EE certificates with validity periods of 30, 35, or 50 years (yes, also EE - especially for devices). Besides the fact that it is a common assumption that the algorithms (e.g., P-256) used in these environments (e.g. IoT) are NOT going to pass the test of time, ignoring the revocation could really affect the privacy of millions of people - and we are currently not doing anything at the IETF to prevent this issue.

There is the need for simple revocation services, but arguably we do not have what's needed today (requires improvements).

IETF Specific Situation and Issues

Why are we so unprepared to face these issues ? I would say (still personal point of view - based on almost 20 yrs of participation in PKI discussions) that these might be some of the main reasons:

  • There are NO venues where to discuss possible solutions to existing problems. The PKIX working group has been closed down (very arbitrarily, I might say, since there is still a lot of work needed to be done around PKIX as highlighted above)

  • The LAMPS, SPASM, and ACME WGs have/have had, on purpose, very narrow scoped Charters and only few items (mostly quite marginal issues, IMO) are actually accepted as working items (w/ reference to SPASM and LAMPS in particular). Solving revocation and discoverability issues should be the 1st item and the most important on the list (at least revocation) but they are not - actually when that was proposed to be included as part of the charter(s), the requests were not even acknowledged or rejected with no real technical reasons.

  • The constant nonsense of people saying that PKIs do not work as an excuse not to improve them while they (PKIs) are the reason we can deploy secure protocols and provide privacy. It is evident that PKIs are here to stay, this is a fact. Their usage has increased exponentially in the past years and they have, so far, passed the test of time. IoT is one use-case. ANIMA is another. ACME is another. Just to cite few of them.

Moreover, things are happening in environments outside IETF (WIFI 2.0 Alliance, OpenADR, CMI, etc.) and IETF un-willingness of working on these problems is really scary to me. The world moves forward, fast, and the IETF is standing still on this topic. I really do not understand why.

Final Considerations

In this message I try to summarize the reasons why I think there is the need to provide a venue where these problems are discussed and the need for key people to not actively block the possibility for people that are willing to work on this to have a venue where the work can be carried out.

I think that this work is of the utter importance and I would like to understand what the position of the whole security area is around these points and the proposed work.

I hope that the discussion around this message can spark some interest and that work in the PKIX area can finally resume at the IETF - which was, in the past, thought of as the lighthouse where these issues could be addressed.

A small request, please, try to read this e-mail carefully and consider the implications of NOT taking on these tasks when replying and/or discussing the topic. Also, since I know this (PKIX) is a minefield for "political" reasons (which should not be a drive here), please keep the discussion on the positive / constructive side (thanks).

If you feel like a private response is better than on the mailing list, please just reply privately.

Looking forward to hear your opinions on this hoping that this e-mail can be the beginning of the end of PKIX still-standing issues :D

Cheers,
Max

--
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo
--------------69BB6B0D37D905F5BC3DC393 Content-Type: image/png; name="efhklhncoknghhph.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="efhklhncoknghhph.png" iVBORw0KGgoAAAANSUhEUgAAAGQAAAA2CAMAAAAGesyaAAADAFBMVEUsJiEAAQAKAwMABwoX BwESCQAqDgEkEQItFQESGykaGh0WGyE1FwE9GwJHHwElJiY4JBQmKDE1KCAfLUQ8KygoMEAq MjpXKgs/MilMMR0pOFEyOUo4OTo1OkRqMgpjOBlpNxUwQV1DPz48QExdOyM4QVV+OQRRQzo1 SGdDR0lDSFJfRDFASVyaPwF+RRpNT1I9UXlwSi8+UnNDUm6hQgCPRhBdUEZTUlBKVGlPVF27 PgCaSANtUT57VBerSQOMUgxHW4KMUiepTwmJVDh6WT6KVjGCWDpRYH21TwFiYF57YgJXYXae VR+lVRZrYld1ZiB7YEuSYQBgZW+8VAlkZWjBVQCfXiqqXwG1WhPLVgedYDazXiDZVgCWZEDV WQJ1blapYjbXWgDRXACMaU6WbgCiZjnIXw9mcIixZC6pZjJ/cUeLbFdycmZ4cGnnWwNwc3Wq aS6BcGeobwndXwzkXwLgYgDaYwyMeCq/bQHJaBi9ajDMagWVegvRZxzVaAvXaQDLainqZAuv cEPrZQDQaSyockrFbSvmZwnabQLvZwDpaQB0fpPkaxGld1d+f3/3aACfeV6RfG2JfnLebSF7 gYy2fQmugQCigxW8d0K3eEr1bQXaciTicRqKgnzNewHuchbUdzKYiDzrdwKah1erjAvOfEXl eSq5g1qYjGikiHO2kADigwC2hmSZjIGGj6aHkJzQiwCximixim/EkAORkZGVkYrOh0rPiVL5 giTvhDKkk4LMjF23mR+zmTrhikrviDzsi0TAlHDCnwvKlGqpnJLdlF2boKy+m324nImkoZ+e o6XKpgrloATwl1WypZPOn3zfqQjYrgLBrVDdo3nGq5mysa/SrI7dq4bqqXTOrpWttL+6s6uw tbe/t4rhvALetpjQuqnuwwe9v8LAv7vauqD3xA68w9XBw83rvJfRwbXFyMvbxbPNyMP8zgTc zMDr0mb91xLM1ODQ1NfS1c7p0sD70bPd19PX4qj83cje4+Xr4tv54NLp7/Hy9PHw9fj6/v3Y ktvJAAAAAXRSTlMAQObYZgAAAAFiS0dEAIgFHUgAAAjrSURBVFjDtVcNWFPXGT6E+l9BZ0EF sTKEIQaUAIrTZdYqxqG0I3UjIuiDM0ipoyO5l0rFh2PE472EoIJKL9hQV2OxqM+USgFL4r9g EaIoQxgqKBZBR+nGGhXYdwNro0Kfkcp3ntzce/7e8/2e70PoJVDl3bMlZyurUSsaKnqESrMp lYrByozCjUOEUZORodMRVsViTjJc8GbLUGCUUstLv1SyLCGch8DGRiDPe/kY5/2HCQQTxZEE y4fb2gDI8KjjLxsjfyyc3lZgM3KixwgeY4TEzk7+kjHODbeb6u0xAhiw8XgFMOxolpP6J75U jLZfp6dzHIcBYCQbIBB4sCxDOLK6eMAVT39it57+e09ysCnDUtnrJ0vS5ZMW0PBFWDbd40G/ 85sH2KeXvj94u/flX8/2J6kYQkhkHbzWbkdH0N0UDN8sURS8uMd9dMzPL7BxIIjOayuWLBIf 70RPUPjxLouBEgVhMaYuWXQlMjwsN+eFTR4cDZ4werRDYOoAIFkrptm/Ni0gthOt9Q4yWQxc AwyWTbacW0sTDGoJen4P002/2S7LjgV6BpY1N6OO5g5eeiZTY/P9b1FzRwfKWuk9p/72ct+N puKpq32qLVaexOCCJB91aezt5y6zt7fXILSdJZjlVr1w0mCR66x6FL3QOXiUQ2a0k/sFlDlq 1LzUMQ4uxxycjl0LWO1bBsY6yXR3wSTJGxqLhdsJHDsS9cwF47XlvcQGQiXhRbih/HkQv4XO cajZb6GDu7PTFEdPkVu0k4vQyd3Jc/SUwNnB+RJ/XsI9ptZDIxMly3dbLNwGnGBJF+Id3cZM 9ui8Gjq5P/TDiRCegbOFgSKRo5e7yNHV2dnPdVb0bHfHQCevNIV/rxqrX48oFQdYcpKMtYRb juxtfqRypNACK28+j3FsqcilAD0ADuIWCt0yRa7zRNEOY2YELhW5CV2dXVKixH8BC+s8GDN9 wWKxf94zpsRiJuWmBYjgndsKFmu5Bc+D3HQXCcu7QTFTMl3HF0SLxruLvGa4zUqdMGFWqqfX 3GSxN0y6NT154i+v75zvH2thXiWgY2YVElhwYl9NYxarlr0grlQn92DQt1vBUk+nUFeHGZme gUIvl1RXr1AnV/fx6zd4v3HptM/YaXbrzmYFePu2WpowYRlJo+2PGLb2d9WE5bw1L4DcnOco 9HIcH3o02HOecMqMJhQqdLPXpArHl2uEo+Na8qZPXxw0+bVx46bFzhw3eZylM2dgwkbWW3Iy Jp9lMDe9H2/raiqPCy5/fHSCu+M7mkffoQuzQhvRhWVlj1FcWTfq6dwdElJmarxedr/u3P6C Nn7Fk95ol8wRjIMsOLGJSwLm/OMGjlFHJ7hqelDuxdMlpbU16JvqlJTamivoBjrfUgNB69zf b6Fr1TWPKmtOw9xCdLayEFWvBlaSfmEBsk6LSdTMNnQaldTe7Qfj20yveddR2toVEevCi9/f fmntR7ErtvompmyICM9qyYpZsG3FhqwNYRH5KUtyW7eGRRxfH1OHDv0ZXH6ihbSyVYzSY3Fu BkVR9LaS2wPxUxyTFpu2eGverr+dezvi0ttpOy/tTKlL2ZkWs6p4VV1Kyq60nevS8iLyi1tW hfNWzMfhYT+ArAQ+5odRBENjlRW5F/vH6O7u7urpXtvR/bQbmX/dPd3w7Ok+2Ij4ry5o0N/d Y1p7qA21FodhFRc1ctjIsXZ2Y18VcwCixNgcWlgVbUiue3b3J33te7497vv/oT1Bj5/7br1R grYlfrReSqmwPDyK0GqOUHKWj/RwP0J0ZlmsK3o2HP+7Qt9HBr3BYH5aNL3FG/+ul8sjKcxH dRJFGJkhfKxgmM2rUoaSg5h4GAwXJsF00dRGq+/21k2EF7o50oNswrNfsYUQKRBIZWIFh3lu aLNe1F++bjXGyWyzZiGoYFYLx5Ys4v0R3GWRdBHNErBiSiqVRhHMyeaYrMQ4SENWCvEcfhCm GIzpqKlm27KTSWUcAX1goBw5oATctDb33aLTYV5SWoaXP5+gyqlFdnZ23nB+plcnREv0RWJC BVkrrBJ1BewMmlVpgRUQF7wpItMJTcsJ34GBRVaFdQZaqoqxFmSb3qDQgu1A2GI4YAnODkQY IOhklDKzo2C1IV2sijzdhjorqwefNdL6ihxzegU7SynexHgBMXy+xWFG8qvdf91D8WpRi41q KFl02YaswYNkULTeLC9CFFK4bDHDMmZbhnuXSOdAsnN1LxgfVu7ZvG8LpSJUlO/gnaWQFwYv JpZeKdUaSC8ApuhIShYQYp5yWQ0oPgVXPtkcHz/fx5rqqzosHSSlBYHIxKSolJcUsIIpnzkh mt4b7Z/tOzBRQWaA6uNCNdet0nxLkL8CgzeQKIlCXaHjXR9MlqQn9Y1fNd5RE0zF/ryKwVR/ JMnsI3S8Umcw6NRYxRuUKqk3lfnKeGcTySAx5hy+7WfgZOv4uLLl0w8wUah71QLBpJeXq/eM VVivV8jz6lB2ofWF6i1dEYRZfMJ4piE+ZweNeb7A2VVyKEx6vjt1z/ghMehVKiUpyt1VYBXC N6j0Q4Mazp7TvvndhIaGhqqvP1bwFk0YRYR5RoLR+PkWmlIpV/oEDQ6jB9Wc3Z6bm6zLTtLl gLC4LVWXz5Q1ffbV5oZ24wmsV/NeKTlirmg+u/q7w7/38PDdeKF8UBgXs2kV4WUC0YR/KOLv Pby3L5O30yvG9vY/6vX8JSbb2je96coXX5QPznqfokKKEPWBAwd20ApaTWsP7LnTfsd42at3 +B+H7+zRUfwZZMutN6baHCX5+Ou9Zy4f3nuiKr7KaHxoNDbsSwhp6htvfyg3Zw901G+ttVlT Ja34/E+fvrXmvY3713xy6tSZfadOJby7X1P/vwn/MeaYr0mF7IMEq690Gu95KwQq5L5K+f59 qGUtaZMSciHMKjdVbY6zFqRC/pv3LgxY5tcW0pjIpGGJ7+89kxBnbXZSmjuz7CeyihyG8fbd XXYdrWlqQg+sZWTdzPqBB68VEdnkzDY0lHSjSD9/GRpaMt3OWqLpQENOTf/PpP8CK9ZVVe2a 8XoAAAAASUVORK5CYII= --------------69BB6B0D37D905F5BC3DC393-- --------------E4208EFAF51D177E0AC0D486-- From nobody Sat Jul 22 13:47:08 2017 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 D4668130019 for ; Sat, 22 Jul 2017 13:47:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.308 X-Spam-Level: X-Spam-Status: No, score=-0.308 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592] 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 u_Cfu0kkWVoP for ; Sat, 22 Jul 2017 13:47:04 -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 32FF0126C23 for ; Sat, 22 Jul 2017 13:47:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 7F90E3004FE for ; Sat, 22 Jul 2017 16:47:03 -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 sT-rr5jxQcVE for ; Sat, 22 Jul 2017 16:47:01 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id E2FC13004F7 for ; Sat, 22 Jul 2017 16:47:00 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: Date: Sat, 22 Jul 2017 13:26:47 -0400 To: SPASM X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [lamps] DRAFT Minutes for LAMPS Session at IETF 99 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 22 Jul 2017 20:47:06 -0000 Please review and comment. Russ = = = = = = = = LAMPS Session at IETF 99 17 July 2017 Executive Summary All of the deliverables in the current charter are with the IESG. Three potential work items have been suggested for a re-charter. There was a lot of interest in re-chartering to work on rfc6844bis and the addition of the SHAKE128/256 and SHAKE256/512 algorithms for PKIX and S/MIME. There was almost no interest in including the specification of a first-issued certificate extension in the re-charter. 0) Minute Taker, Jabber Scribe, Bluesheets Yoav Nir will take notes. Jim Schaad is Jabber Scribe. 1) Agenda Bash No agenda changes. 2) Any issues from documents that have been sent to the IESG a) draft-ietf-lamps-rfc5280-i18n-update b) draft-ietf-lamps-eai-addresses c) draft-ietf-lamps-rfc5750-bis d) draft-ietf-lamps-rfc5751-bis No comments have been received on any of these documents. 3) Proposals for additional work items All of the deliverables in the current charter are with the IESG. Three potential work items have been suggested for a re-charter. 3a) rfc6844bis Phillip Hallam-Baker suggests that the re-charter include a work item to update PKIX CAA document. The CA/Browser Forum will require mandatory CAA validation starting 8-Sep-2017. The original intent of the CNAME and DNAME resource records in the DNS is obsolete because of CDNs. They want to administer various CNAMEs as one unit, but CNAME cannot be used to distinguish between the two needed use cases. A prefixed SRV record seems like a better approach. An update to RFC 6844 is needed to address this situation. Proposed charter text: "Specify a discovery mechanism for CAA records to replace the one described in RFC 6844". Sean Turner: Yes, let's do it. HUM to include rfc6844bis in the proposed re-charter. Many for yes; silence for no. Phillip Hallam-Baker volunteered to be editor. 3b) Adding SHA3 to PKIX and S/MIME Quynh Dang (NIST) suggested that the SHAKE128/256 and SHAKE256/512 algorithms be specified for use with PKIX and S/MIME as a backup to SHA-256. There are no know concerns with SHA-256, but it is prudent to have an alternative available. The SHAKE algorithms offer better performance than other members of the SHA3 algorithm family. Jim Schaad: How exhaustive of a signature algorithm list are you proposing? Quynh: They are efficient functions. Russ Housley: Which set of signature algorithms would you like to use with the SHAKE functions? Quynh: They're good for them all. Quynh: Don't need the HMAC construction for use with the KECCAK. Jim: The problem is education. People don't know that you can use SHAKE without HMAC. Implementations would need to be changed to not do HMAC for AuthenticatedData. Everyone is used to using HMAC in this context. Sean Turner: I don't know we need to pick the actual curves for ECC signature algorithms right now. We thought about RSA-PSS and ECDSA, but we do not need to pick now. Eric Rescorla: Why? Isn't the SHA2 family good enough? Quynh: Just in case we find a problem with SHA2. Eric: We've been trending away from defining points without a clear advantage. Quynh: They are very secure. Eric: SHA2 has a wide margin. Quynh: SHA3 has an even greater margin. Eric: It's just another algorithm. Phillip Hallam-Baker: We need two algorithms for each primitive: One to use, another as a spare. And make them rather different. Sean Leonard (Jabber): Is agility a sufficient reason in and of itself? Jim: There is a reason to do the AuthenticatedData stuff with SHAKE. Since it is one-pass it is going to be faster. Eric: Where do you use MACs that is not replaced by AEAD? Russ: There are a few places where confidentiality is not needed. Bron Gondwana: Having a spare algorithm that is not routinely used is not enough. Phillip: Ed448 already includes SHA3. So, this would not really be adding code. Just adding code points. Quynh: If you have a code point, some people will use it. Eric: We have code points for SHA-512, but almost nobody uses SHA-512. Bron: Some implementations will support it wrong, but nobody will notice until you have to use it. It needs to be used all of the time to know that it works. Max Pala: I think the agility argument is sufficient. HUM to include the SHAKE functions in the proposed re-charter. Many for yes; silence for no. 3c) An first-issued certificate extension (Phillip) Phillip Hallam-Baker suggests that we specify a first-issued certificate extension. This is not a new idea; it was previously presented in Chicago, July 2007. The age of certificate is useful, because an old certificate is evidence of longevity. It is like "Member since" on a credit card. And now, short-lived certificates are coming back (see the ACME session this Friday). It offers user accessible safety information, like "established 1977". Some people object to this extension, saying that they do not want to deploy it. Other say that PKIX doesn't work. Others say the information is available in Certificate Transparency logs. However, Phillip says that the CT logs do not offer the information in a way that users can understand it. It requires more processing. Robin Wilton: From the user perspective: you get a warning about a recent certificate. Is this going to happen a lot? Phillip: Security UI is garbage. Robin: So how can we avoid the bad stuff. Most users would not see it at all. Paul Hoffman: First Issued by whom? Same CA? Another trusted CA? Phillip: There are ways of doing it. Sign the new CSR with the old key. Eric: Which relying parties will use this information? Phillip: Not in primary chrome, but while looking at the certificate by clicking the padlock. Eric: Which relying parties are interested? Phillip: We want to tell people how to be safe online, but we don't have a way to tell them how. This is one piece of information might help. Rich Salz: Useful in email. Sean Turner: Last time we said it was lock-in to one CA. Jeff Hodges: Don't understand how to link them. I can get owned at any time. Phillip: Bad sites are usually short-lived. Stefan Santesson: It's targeting the wrong end of the problem. The CA/Browser Forum should need to define it on the policy side. The extension is the easy part. Phillip: In ACME we're defining the validation criteria. Sean Leonard (Jabber): Is this actionable by an end-user? Paul: I don't want to build the chain and sign new certificate signing request (CSR) with production key. Let CAs do it. One CA could lie. Yoav Nir: Don't think it's a good signal to make decisions. Eric: Doesn't seem like it's useful on the web. Bron: Banks would send an email to all customers that the name/date is going to change. An attacker would do the same. Phillip: It can help users determine whether this is the good or bad part of the Internet. Rich Salz: You can't define (algorithmically) good vs bad areas on the Internet. How long you've been paying a CA is not a good indicator. Yet, it may be useful for email. HUM to include the first-issued extension in the proposed re-charter. Silence for yes; many for no. From nobody Mon Jul 24 12:16:57 2017 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 6AE1A131687 for ; Mon, 24 Jul 2017 12:16:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.439 X-Spam-Level: X-Spam-Status: No, score=-2.439 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, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lf_lPcjsOv2U for ; Mon, 24 Jul 2017 12:16:54 -0700 (PDT) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3504B131EED for ; Mon, 24 Jul 2017 12:16:54 -0700 (PDT) Received: by mail-oi0-x22f.google.com with SMTP id g131so34459810oic.3 for ; Mon, 24 Jul 2017 12:16:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=4qPJiBUJjxTYMO6JP4RQg0UQ6s42eJoUXlfmoUfsqH4=; b=Cfo6QEWTskQC/BSqWs/cypKKZm2gka9wwj0UfthS+FWADEEjkUoK3KI10531r51gV8 yXEMJkcwX69WFWsXtQBZ5zRj5uCb9TXvKJMuTnXPTGcJEwW4Dgsn6+Y74zicoOfrQl2p cPBX9RUkIbr7rpgxmi11I+Sah9LZiMVRsSzxWIHm8YBdVfNNNBKFz9l6h0buSu9uwAqj 5z02ERvXpx0nO5DKTTSLTGicWGRCT4SOMtbfbWlMuE8+fs+LUqnVtrjiPMTxkJ/ES7M6 YQIIVF5Jn+8mJZF63mUEBqe+J7BGHWsvl1bAVNtXJwwK2H6qpI9rgTjt2Y/rvjuqChOS sp9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=4qPJiBUJjxTYMO6JP4RQg0UQ6s42eJoUXlfmoUfsqH4=; b=fIUX60G8KqKzEUChSI+9YtfePtBUqLfYRL7S8rg52SKxmLH9cFHuMart+qz7Iq3Uq6 GxpACFjwG/EhfN6Xhd67FWCnM1T4hjNs9ejej2PtwfRi4Zjnc++9VCpalW15HxtcbdSb rWtfgFebXFTuOnq1RKBW+BbNJhPjkz/QsYNlMC+gpcgogjrOTaidgft7b5MYsCFxc3Kj ccN9gL9uXzVMvRMj/wEuO20gJpbWsnzDbQL+uvgrewmsNJDXXhh1aABYfWqIDTdFSu9P rjkzqq9g3dfX8TcNexT+01XFQpOHZwKH6DS9Wgd0cn6iL68hSVr90/aY2PHx02R6v2Jj PFdw== X-Gm-Message-State: AIVw112AlPw32Ki0GWotAKzubstqlLVSPcVdBhavO8TbHTO5rPe9KXgD 7Ksz+snZHddn26lGrtaUS6/qV+cLBgDp4SA= X-Received: by 10.202.44.19 with SMTP id s19mr6961156ois.243.1500923813403; Mon, 24 Jul 2017 12:16:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.237.18 with HTTP; Mon, 24 Jul 2017 12:16:52 -0700 (PDT) In-Reply-To: <150092332977.31997.13480610609578646985.idtracker@ietfa.amsl.com> References: <150092332977.31997.13480610609578646985.idtracker@ietfa.amsl.com> From: Dmitry Belyavsky Date: Mon, 24 Jul 2017 22:16:52 +0300 Message-ID: To: LAMPS Content-Type: multipart/alternative; boundary="001a1137baaebba28b0555150e96" Archived-At: Subject: [lamps] Fwd: New Version Notification for draft-belyavskiy-certificate-limitation-policy-03.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 24 Jul 2017 19:16:56 -0000 --001a1137baaebba28b0555150e96 Content-Type: text/plain; charset="UTF-8" Hello, I've uploaded the updated version of the draft-belyavskiy-certificate- limitation-policy. The new version contains some improvements motivated by discussion after my presentation on SAAG. I suppose that in case of rechartering the LAMPS WG my draft can become a potential work item. Thank you! ---------- Forwarded message ---------- From: Date: Mon, Jul 24, 2017 at 10:08 PM Subject: New Version Notification for draft-belyavskiy-certificate- limitation-policy-03.txt To: Dmitry Belyavskiy A new version of I-D, draft-belyavskiy-certificate-limitation-policy-03.txt has been successfully submitted by Dmitry Belyavskiy and posted to the IETF repository. Name: draft-belyavskiy-certificate-limitation-policy Revision: 03 Title: Certificate Limitation Policy Document date: 2017-07-23 Group: Individual Submission Pages: 6 URL: https://www.ietf.org/internet-drafts/draft-belyavskiy-certif icate-limitation-policy-03.txt Status: https://datatracker.ietf.org/doc/draft-belyavskiy-certifica te-limitation-policy/ Htmlized: https://tools.ietf.org/html/draft-belyavskiy-certificate-li mitation-policy-03 Htmlized: https://datatracker.ietf.org/doc/html/draft-belyavskiy-cert ificate-limitation-policy-03 Diff: https://www.ietf.org/rfcdiff?url2=draft-belyavskiy-certific ate-limitation-policy-03 Abstract: The document provides a specification of the application-level trust model. Being provided at the application level, the limitations of trust can be distributed separately using cryptographically protected format instead of hardcoding the checks into the application itself. 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 -- SY, Dmitry Belyavsky --001a1137baaebba28b0555150e96 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,=C2=A0

I've uploaded the upda= ted version of the draft-belyavskiy-certificate-limitation-policy.=C2= =A0
The new version contains some improvements motivated by discu= ssion after my presentation on SAAG.

I suppose tha= t in case of rechartering the LAMPS WG my draft can become a potential work item.

Thank= you!


= ---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Mon, Jul= 24, 2017 at 10:08 PM
Subject: New Version Notification for draft-belyav= skiy-certificate-limitation-policy-03.txt
To: Dmitry Belyavskiy <= ;beldmit@gmail.com>



A new version of I-D, draft-belyavskiy-certificate-limitation-policy-0= 3.txt
has been successfully submitted by Dmitry Belyavskiy and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-belyavskiy-certificate-= limitation-policy
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A003
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Certificate Limitation Policy
Document date:=C2=A0 2017-07-23
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 6
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-draf= ts/draft-belyavskiy-certificate-limitation-policy-03.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-belyavskiy= -certificate-limitation-policy/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-belyavskiy-certificate-= limitation-policy-03
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-bel= yavskiy-certificate-limitation-policy-03
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddra= ft-belyavskiy-certificate-limitation-policy-03

Abstract:
=C2=A0 =C2=A0The document provides a specification of the application-level= trust
=C2=A0 =C2=A0model.=C2=A0 Being provided at the application level, the limi= tations of
=C2=A0 =C2=A0trust can be distributed separately using cryptographically pr= otected
=C2=A0 =C2=A0format instead of hardcoding the checks into the application i= tself.




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

The IETF Secretariat




--
SY, Dmitry Belyavsky
--001a1137baaebba28b0555150e96-- From nobody Tue Jul 25 11:20:39 2017 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 1C88F12ECF0 for ; Tue, 25 Jul 2017 11:20:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PhQvsuipwdNt for ; Tue, 25 Jul 2017 11:20:33 -0700 (PDT) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0093.outbound.protection.outlook.com [23.103.200.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6671F131E88 for ; Tue, 25 Jul 2017 11:20:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ynsp+HEFE4RTb2ZeDY0qi8KaqkDjupXQ721DNopn9vk=; b=zUyg05F41eMq+iXI0rsM0qOLKQVCFl7CX945ALM7ZGZVUsN2KCLlG/u/CbjQqz1MtBjUupG63vQHLbmHxnnvfiYfudYghJOxgWZZZOXAQK9z+j2cYTgRrrRjiBGEZ8CG1hNgoF8yZdvBBKZXPUftAb1cUNuYnUoPjxCldTVfdsc= Received: from CY4PR09MB1464.namprd09.prod.outlook.com (10.173.191.22) by CY4PR09MB1464.namprd09.prod.outlook.com (10.173.191.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.10; Tue, 25 Jul 2017 18:20:30 +0000 Received: from CY4PR09MB1464.namprd09.prod.outlook.com ([10.173.191.22]) by CY4PR09MB1464.namprd09.prod.outlook.com ([10.173.191.22]) with mapi id 15.01.1282.020; Tue, 25 Jul 2017 18:20:30 +0000 From: "Dang, Quynh (Fed)" To: Russ Housley , "Dr. Pala" CC: LAMPS Thread-Topic: [lamps] Considerations about the need to resume PKIX work Thread-Index: AQHTAUyRJqD8Fgk8HkOtHcW6sHgBpqJcmCcAgAhKaLU= Date: Tue, 25 Jul 2017 18:20:30 +0000 Message-ID: References: <04e73e42-7c5b-912d-cc79-7959a710927e@openca.org>, 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=quynh.dang@nist.gov; x-originating-ip: [129.6.231.6] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR09MB1464; 7:SByP+rhUZtGa7h1RIEfTDy5BQUS5r1wVcXrMMPw/zULnG90MAHeUuzo+DCcZiiqwpR7gG8HgvGxn/RwtdkSJ4dNMFjc1DrLEf+Tbw0RTu+x1CQ2SIkc0S9t67n1MyAVUHCuzSrxTA2nRWN11N+BVyMGSKxyir/LvkTVW4D1iD2t3yLZrC7vHt9EDN1WUKmoSUSDcefrBHkPGCvOZDg+c2sXuD4cxz17Y3tYGABNLKH/sQeoz4kEnr0yf1+LkJV3RBQFq7kBQZlkTHgbv/fw6x5dg9Zvhcg6Ng4bnxmhLhgkbQ7SygBUpU1eY+4XG/R3odFjiMOzfLOn7ktrAArMfApQPzM7xdIQqMaIBBIM+xP+j42zEbvHGqhh5ifGOv4rNA9sk6hZxvFmB30JWR0AtgerEFoT1CQdwRmxhpqxO/VKir0cJ+ZTxPQhNPd/qwnQra8bUxEsQjKMfk5h4QxdjSVMKZUV3WJ49jktl8jPplwK3nzX8wIvJ3NVNW3Z1XumR1geMudSvJgqBc47/DhM4f8tMr+kTTGfqX51DSoP3r9Fl6EvRHNg2mawmYj5qiMMF92jEkhlEWyARx+TEuQwWs6XBuQJ5/xxNvmZASln8vquFWhM9DzO2N96Akg/1s2ju0lp2z9yOvpM/UCI/L/lXpCXSDS/64Qf3Ce4xnTTFb9yX6EQPN1kVcYWGSWuJt8GQKA5859CmMedPrs9d3+mDJZgtTwp/IqVjd1aBo81jMglm76TVsMM43dts7NXxCVTunDdds7DcG7YJpNGayC6/sG4xHmHbLWb7KMNMato+CC0= x-ms-office365-filtering-correlation-id: 354ed0b4-5a16-4631-57c7-08d4d389d520 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(48565401081)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY4PR09MB1464; x-ms-traffictypediagnostic: CY4PR09MB1464: x-exchange-antispam-report-test: UriScan:(278428928389397)(192374486261705); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(93006095)(93001095)(100000703101)(100105400095)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123562025)(20161123560025)(20161123555025)(20161123564025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR09MB1464; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR09MB1464; x-forefront-prvs: 03793408BA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39450400003)(39850400002)(39410400002)(39840400002)(39860400002)(39400400002)(53754006)(199003)(24454002)(377454003)(51444003)(189002)(25786009)(189998001)(81156014)(8936002)(4326008)(8676002)(33656002)(105586002)(6606003)(3280700002)(106356001)(53546010)(101416001)(966005)(3846002)(6116002)(74316002)(19627405001)(14454004)(7736002)(102836003)(81166006)(3660700001)(2906002)(561944003)(478600001)(86362001)(6506006)(77096006)(68736007)(229853002)(50986999)(54356999)(76176999)(5660300001)(66066001)(236005)(97736004)(2950100002)(6436002)(7696004)(2900100001)(99286003)(55016002)(6246003)(38730400002)(53936002)(54896002)(6306002)(9686003); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR09MB1464; H:CY4PR09MB1464.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR09MB1464D8F73E5F96E76ED62B6BF3B80CY4PR09MB1464namp_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jul 2017 18:20:30.4635 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR09MB1464 Archived-At: Subject: Re: [lamps] Considerations about the need to resume PKIX work X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 25 Jul 2017 18:20:37 -0000 --_000_CY4PR09MB1464D8F73E5F96E76ED62B6BF3B80CY4PR09MB1464namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable + 1. Quynh. ________________________________ From: Spasm on behalf of Russ Housley Sent: Thursday, July 20, 2017 7:43 AM To: Dr. Pala Cc: LAMPS Subject: Re: [lamps] Considerations about the need to resume PKIX work Max: If you can turn these into separate charter items with a description of the= deliverable and milestones, then we can discuss each idea on its own. Of = course, in this group we expect that there be a commitment that it will be = implemented. Russ On Jul 20, 2017, at 7:37 AM, Dr. Pala > wrote: Hi all, I would like to draw the Sec Area attention on an issue that I think is bec= oming more relevant every day. It seems quite clear that today there is a lot of work around authenticatio= n and encryption that make use of PKIX certificates. However, there is no p= lace in IETF, today, where problems related to PKIX can be effectively tack= led. In the following paragraphs I try to summarize the issue and the propo= sed work and a call for discussion around the feasibility of resuming the w= ork in two particular areas: revocation and discoverability. The Problem What I noticed in recent proposals in many working groups (when it comes to= certificate management) is that more and more people turn towards the use = of short-lived certificates to avoid checking revocation information. Somet= imes this choice is motivated by real technical considerations, but in many= cases the choice is "forced" because nobody is currently working on fixing= the two main issues related to trust infrastructures: efficient revocation= and discoverability of services. The Revocation Situation Most of the times, when interacting with PKIs, we are still stuck with CRLs= , OCSP if we are lucky (including stapling - available in TLS connections i= f really really lucky), and in most cases even these mechanisms are critici= zed widely by people as being inadequate today. This resulted in applicatio= ns to use proprietary methods for checking revocation (e.g., CRLSet) or to = skip checking all together (or mandate for short-lived certificates only as= in the case, for example, of STIR). Many people today ignore the fact that, when coupled with small devices, th= e generation of new keys require (a) a lot of resources, and (b) a good sou= rce of randomness. Requiring apps / devices to generate new keys might seem= a good idea at first, but is this better than checking revocation ? What a= bout the complexity of key management ? Examples of possible work to address the issues are OCSP over DNS and some = more efficient ways to verify the validity of a whole chain of certificates= efficiently. The Discoverability Situation As far as I know, there are no standardized mechanisms that would provide d= iscoverability of services that would help users and applications to discov= er Public Key Services providers and associated services in a dynamic fashi= on. When I brought it up during the BoFs of possible working groups where t= he issue could be discussed.. well, the proposal was redirected to /dev/nul= l (e.g., ACME, SPASM, and LAMPS). Isn't that curious that still today nobody is working on some sort of infra= structure that would facilitate interacting with PKIs ? After all, PKIs are= the core Trust mechanism that enables reliable authentication and encrypti= on over the Internet today. Such infrastructure could really improve the se= curity of the Internet and make PKIs more usable from an application (and u= sers) standpoint of view. Examples of possible work to address the issue are a PKI Resource Query Pro= tocol (PRQP) and/or the use of P2P systems as distribution mechanisms for P= ublic Key related operations (e.g., EST, BRSKI, or ACME over P2P - 0-config= uration support for PK). Deployment Trends in the Real World Today I am witnessing the deployment of arguably not-well-designed PKIs (or= , in other terms, what I call Weak PKIs) that do not provide support for re= vocation and that are expected to use CAs and EE certificates with validity= periods of 30, 35, or 50 years (yes, also EE - especially for devices). Be= sides the fact that it is a common assumption that the algorithms (e.g., P-= 256) used in these environments (e.g. IoT) are NOT going to pass the test o= f time, ignoring the revocation could really affect the privacy of millions= of people - and we are currently not doing anything at the IETF to prevent= this issue. There is the need for simple revocation services, but arguably we do not ha= ve what's needed today (requires improvements). IETF Specific Situation and Issues Why are we so unprepared to face these issues ? I would say (still personal= point of view - based on almost 20 yrs of participation in PKI discussions= ) that these might be some of the main reasons: * There are NO venues where to discuss possible solutions to existing p= roblems. The PKIX working group has been closed down (very arbitrarily, I m= ight say, since there is still a lot of work needed to be done around PKIX = as highlighted above) * The LAMPS, SPASM, and ACME WGs have/have had, on purpose, very narrow= scoped Charters and only few items (mostly quite marginal issues, IMO) are= actually accepted as working items (w/ reference to SPASM and LAMPS in par= ticular). Solving revocation and discoverability issues should be the 1st i= tem and the most important on the list (at least revocation) but they are n= ot - actually when that was proposed to be included as part of the charter(= s), the requests were not even acknowledged or rejected with no real techni= cal reasons. * The constant nonsense of people saying that PKIs do not work as an ex= cuse not to improve them while they (PKIs) are the reason we can deploy sec= ure protocols and provide privacy. It is evident that PKIs are here to stay= , this is a fact. Their usage has increased exponentially in the past years= and they have, so far, passed the test of time. IoT is one use-case. ANIMA= is another. ACME is another. Just to cite few of them. Moreover, things are happening in environments outside IETF (WIFI 2.0 Allia= nce, OpenADR, CMI, etc.) and IETF un-willingness of working on these proble= ms is really scary to me. The world moves forward, fast, and the IETF is st= anding still on this topic. I really do not understand why. Final Considerations In this message I try to summarize the reasons why I think there is the nee= d to provide a venue where these problems are discussed and the need for ke= y people to not actively block the possibility for people that are willing = to work on this to have a venue where the work can be carried out. I think that this work is of the utter importance and I would like to under= stand what the position of the whole security area is around these points a= nd the proposed work. I hope that the discussion around this message can spark some interest and = that work in the PKIX area can finally resume at the IETF - which was, in t= he past, thought of as the lighthouse where these issues could be addressed= . A small request, please, try to read this e-mail carefully and consider the= implications of NOT taking on these tasks when replying and/or discussing = the topic. Also, since I know this (PKIX) is a minefield for "political" re= asons (which should not be a drive here), please keep the discussion on the= positive / constructive side (thanks). If you feel like a private response is better than on the mailing list, ple= ase just reply privately. Looking forward to hear your opinions on this hoping that this e-mail can b= e the beginning of the end of PKIX still-standing issues :D Cheers, Max -- Best Regards, Massimiliano Pala, Ph.D. OpenCA Labs Director _______________________________________________ Spasm mailing list Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm --_000_CY4PR09MB1464D8F73E5F96E76ED62B6BF3B80CY4PR09MB1464namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

+ 1.


Quynh. 



From: Spasm <spasm-bounc= es@ietf.org> on behalf of Russ Housley <housley@vigilsec.com>
Sent: Thursday, July 20, 2017 7:43 AM
To: Dr. Pala
Cc: LAMPS
Subject: Re: [lamps] Considerations about the need to resume PKIX wo= rk
 
Max:

If you can turn these into separate charter items with a de= scription of the deliverable and milestones, then we can discuss each idea = on its own.  Of course, in this group we expect that there be a commit= ment that it will be implemented.

Russ


On Jul 20, 2017, at 7:37 AM, Dr. Pala <director@openca.org> wrote:

Hi all,

I would like to draw the Sec Area attention on an issue that = I think is becoming more relevant every day.

It seems quite clear that today there is a lot of work around authenticatio= n and encryption that make use of PKIX certificates. However, there is no p= lace in IETF, today, where problems related to PKIX can be effectively tack= led. In the following paragraphs I try to summarize the issue and the proposed work and a call for discussi= on around the feasibility of resuming the work in two particular areas: rev= ocation and discoverability.

The Problem

What I noticed in recent proposals in many working groups (when it come= s to certificate management) is that more and more people turn towards the = use of short-lived certificates to avoid checking revocation information. S= ometimes this choice is motivated by real technical considerations, but in many cases the choice is "fo= rced" because nobody is currently working on fixing the two main issue= s related to trust infrastructures: efficient revocation and discoverabilit= y of services.

The Revocation Situation

Most of the times, when interacting with PKIs, we are still s= tuck with CRLs, OCSP if we are lucky (including stapling - available in TLS= connections if really really lucky), and in most cases even these mechanis= ms are criticized widely by people as being inadequate today. This resulted in applications to use proprietar= y methods for checking revocation (e.g., CRLSet) or to skip checking all to= gether (or mandate for short-lived certificates only as in the case, for ex= ample, of STIR).

Many people today ignore the fact that, when coupled with sma= ll devices, the generation of new keys require (a) a lot of resources, and = (b) a good source of randomness. Requiring apps / devices to generate new k= eys might seem a good idea at first, but is this better than checking revocation ? What about the complexity of= key management ?

Examples of possible work to address the issues= are OCSP over DNS and some more efficient ways to verify the validity of a= whole chain of certificates efficiently.

The Discoverability Situation

As far as I know, there are no standardized mechanisms that w= ould provide discoverability of services that would help users and applicat= ions to discover Public Key Services providers and associated services in a= dynamic fashion. When I brought it up during the BoFs of possible working groups where the issue could be dis= cussed.. well, the proposal was redirected to /dev/null (e.g., ACME, SPASM,= and LAMPS).

Isn't that curious that still today nobody is working on some= sort of infrastructure that would facilitate interacting with PKIs ? After= all, PKIs are the core Trust mechanism that enables reliable authenticatio= n and encryption over the Internet today. Such infrastructure could really improve the security of the Intern= et and make PKIs more usable from an application (and users) standpoint of = view.

Examples of possible work to address the issue = are a PKI Resource Query Protocol (PRQP) and/or the use of P2P systems as d= istribution mechanisms for Public Key related operations (e.g., EST, BRSKI,= or ACME over P2P - 0-configuration support for PK).

Deployment Trends in the Real World

Today I am witnessing the deployment of arguably not-well-des= igned PKIs (or, in other terms, what I call Weak PKIs) that do not provide = support for revocation and that are expected to use CAs and EE certificates= with validity periods of 30, 35, or 50 years (yes, also EE - especially for devices). Besides the fact that= it is a common assumption that the algorithms (e.g., P-256) used in these = environments (e.g. IoT) are NOT going to pass the test of time, ignoring th= e revocation could really affect the privacy of millions of people - and we are currently not doing anythin= g at the IETF to prevent this issue.

There is the need for simple revocation service= s, but arguably we do not have what's needed today (requires improvements).=

IETF Specific Situation and Issues

Why are we so unprepared to face these issues ? I would say (= still personal point of view - based on almost 20 yrs of participation in P= KI discussions) that these might be some of the main reasons:

  • There are NO venues where to discuss possible = solutions to existing problems. The PKIX working group has been closed = down (very arbitrarily, I might say, since there is still a lot of work nee= ded to be done around PKIX as highlighted above)

  • The LAMPS, SPASM, and ACME WGs have/have = had, on purpose, very narrow scoped Charters and only few items (mostly quite marginal issues, IMO) are actually accepted as working= items (w/ reference to SPASM and LAMPS in particular). Solving revocation and discoverability issues should be t= he 1st item and the most important on the list (at least revocation) but th= ey are not - actually when that was proposed to be included as part of the = charter(s), the requests were not even acknowledged or rejected with no real technical reasons.

  • The constant nonsense o= f people saying that PKIs do not work as an excuse not to improve them whil= e they (PKIs) are the reason we can deploy secure protocols and provide pri= vacy. It is evident that PKIs are here to stay, this is a fact. Their usage h= as increased exponentially in the past years and they have, so far, passed = the test of time. IoT is one use-case. ANIMA is another. ACME is another. J= ust to cite few of them.

Moreover, things are happening in environments outside IETF (= WIFI 2.0 Alliance, OpenADR, CMI, etc.) and IETF un-willingness of working o= n these problems is really scary to me. The world moves forward, fast, and = the IETF is standing still on this topic. I really do not understand why.=

Final Considerations

In this message I try to summarize the reasons why I think th= ere is the need to provide a venue where these problems are discussed and t= he need for key people to not actively block the possibility for people tha= t are willing to work on this to have a venue where the work can be carried out.

I think that this work is of the utter importance and I would like to under= stand what the position of the whole security area is around these points a= nd the proposed work.

I hope that the discussion around this message can spark some= interest and that work in the PKIX area can finally resume at the IETF - w= hich was, in the past, thought of as the lighthouse where these issues coul= d be addressed.

A small request, please, try to read this e-mail carefully and consider the= implications of NOT taking on these tasks when replying and/or discussing = the topic. Also, since I know this (PKIX) is a minefield for "politica= l" reasons (which should not be a drive here), please keep the discussion on the positive / constructive side (tha= nks).

If you feel like a private response is better than on the mai= ling list, please just reply privately.

Looking forward to hear your opinions on this hoping that this e-mail can b= e the beginning of the end of PKIX still-standing issues :D

Cheers,
Max

--
Best Regards,
Massimiliano Pala= , Ph.D.
OpenCA Labs Director
<efhklhncoknghhph.pn= g>
_______________________________________________
Spasm mailing list
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm

--_000_CY4PR09MB1464D8F73E5F96E76ED62B6BF3B80CY4PR09MB1464namp_-- From nobody Mon Jul 31 09:27:44 2017 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 DA69C13264E for ; Mon, 31 Jul 2017 09:27:42 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 4vGloLTcBzAV for ; Mon, 31 Jul 2017 09:27:41 -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 B8C12129AAD for ; Mon, 31 Jul 2017 09:27:41 -0700 (PDT) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v6VGR6OR022931; Mon, 31 Jul 2017 17:27:40 +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=wIlnSFDMnt740g2K8FnG2UsXtEIC/HhyKQXlASLjQ+Y=; b=PtvAKECJneHvZMXyne7Rx5ZYu9zkpVjsSTsk0yJa9MVtJTWTeNEtRJhynLV0tBbwEqty HSCwuaAHRRg5r6bmxfKx/IbuID+ecbONt7xG2ZmuvV7YsfJMFOmOtO+sAoZQfSKEKiQK ZuxbJJnbbN0V/GBIRaPTS+VkZ0u+97oOHvVLRtdZFcEynoH+wA6rHI58WymV54LIAYkk rasVnJhi0p3GJVAKW/Zp+UUBpPh0XbmU94nTSFZWFqvl5pS3tcXmSTM7mgrHI3vwRMAj Ti9evGnl6DYW0EeUr9sYjVaQDr05Ig7V349gXlXkxPhgpbSRDjKG4xFsa7cnv0i0mqm7 IQ== Received: from prod-mail-ppoint3 ([96.6.114.86]) by m0050095.ppops.net-00190b01. with ESMTP id 2c0hwea3mq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 31 Jul 2017 17:27:40 +0100 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v6VGQ8pV023917; Mon, 31 Jul 2017 12:27:39 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint3.akamai.com with ESMTP id 2c0npvw3ak-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 31 Jul 2017 12:27:39 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 31 Jul 2017 09:27:37 -0700 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.1263.000; Mon, 31 Jul 2017 12:27:37 -0400 From: "Salz, Rich" To: "Dang, Quynh (Fed)" , Russ Housley , "Dr. Pala" CC: LAMPS Thread-Topic: [lamps] Considerations about the need to resume PKIX work Thread-Index: AQHTAUyY94hRJDBoU0q9vnCXZD5pTqJc2zUAgAhKpACACQsx0A== Date: Mon, 31 Jul 2017 16:27:36 +0000 Message-ID: <0a12992260ec44ebab8cff0426670cc8@usma1ex-dag1mb1.msg.corp.akamai.com> References: <04e73e42-7c5b-912d-cc79-7959a710927e@openca.org>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.34.207] Content-Type: multipart/alternative; boundary="_000_0a12992260ec44ebab8cff0426670cc8usma1exdag1mb1msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-31_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707310279 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-31_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707310279 Archived-At: Subject: Re: [lamps] Considerations about the need to resume PKIX work X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 31 Jul 2017 16:27:43 -0000 --_000_0a12992260ec44ebab8cff0426670cc8usma1exdag1mb1msgcorpak_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I am also curious to see what concrete things could be done to improve revo= cation. If the answer is =93nothing=94 that=92s okay, but if it=92s not, I= expect OpenSSL will have to write some code :) --_000_0a12992260ec44ebab8cff0426670cc8usma1exdag1mb1msgcorpak_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

I am also curious to see what concrete things could= be done to improve revocation.  If the answer is =93nothing=94 that= =92s okay, but if it=92s not, I expect OpenSSL will have to write some code J<= /span>

--_000_0a12992260ec44ebab8cff0426670cc8usma1exdag1mb1msgcorpak_-- From nobody Mon Jul 31 09:41:08 2017 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 BC8F2126E3A; Mon, 31 Jul 2017 09:41:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_HK_NAME_DR=0.01, 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 vJAU55H7B8KE; Mon, 31 Jul 2017 09:41:04 -0700 (PDT) Received: from mail.katezarealty.com (mail.katezarealty.com [104.168.158.213]) by ietfa.amsl.com (Postfix) with ESMTP id CA922131C04; Mon, 31 Jul 2017 09:41:03 -0700 (PDT) Received: from maxs-mbp.cablelabs.com (host64-111.cablelabs.com [192.160.73.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.katezarealty.com (Postfix) with ESMTPSA id 4D7083740CC5; Mon, 31 Jul 2017 12:41:03 -0400 (EDT) To: LAMPS , PKIX , "saag@ietf.org" References: <04e73e42-7c5b-912d-cc79-7959a710927e@openca.org> From: "Dr. Pala" Organization: OpenCA Labs Message-ID: <8129749b-f608-bc38-8a5f-546c6d360b63@openca.org> Date: Mon, 31 Jul 2017 10:41:02 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms060003020108090109000303" Archived-At: Subject: Re: [lamps] Considerations about the need to resume PKIX work X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 31 Jul 2017 16:41:07 -0000 This is a cryptographically signed message in MIME format. --------------ms060003020108090109000303 Content-Type: multipart/alternative; boundary="------------55C774AE3E7DB6AD8D34BB65" Content-Language: en-US This is a multi-part message in MIME format. --------------55C774AE3E7DB6AD8D34BB65 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable [ Cross Post: Saag, PKIX, and LAMPS ] I just wanted to thank everybody for entertaining the idea of resuming=20 the identified work for PKIX - it seems that we have overall support for = the work considering the replies across the three MLs, thanks for=20 expressing your opinions. The candidate working group for picking up the work items seems LAMPS=20 (thanks Russ for considering the work), so the discussion shall probably = continue there. I will send the tentative items for the charter and=20 milestones to the mailing list and see where this will take us. Thanks again and looking forward to work on these important topics :D Cheers, Max On 7/20/17 5:43 AM, Russ Housley wrote: > Max: > > If you can turn these into separate charter items with a description=20 > of the deliverable and milestones, then we can discuss each idea on=20 > its own. Of course, in this group we expect that there be a=20 > commitment that it will be implemented. > > Russ > > >> On Jul 20, 2017, at 7:37 AM, Dr. Pala > > wrote: >> >> Hi all, >> >> I would like to draw the Sec Area attention on an issue that I think=20 >> is becoming more relevant every day. >> >> It seems quite clear that today there is a lot of work around=20 >> authentication and encryption that make use of PKIX certificates.=20 >> However, there is no place in IETF, today, where problems related to=20 >> PKIX can be effectively tackled. In the following paragraphs I try to = >> summarize the issue and the proposed work and a call for discussion=20 >> around the feasibility of resuming the work in two particular areas:=20 >> revocation and discoverability. >> >> *The Problem >> >> *What I noticed in recent proposals in many working groups (when it=20 >> comes to certificate management) is that more and more people turn=20 >> towards the use of short-lived certificates to avoid checking=20 >> revocation information. Sometimes this choice is motivated by real=20 >> technical considerations, but in many cases the choice is "forced"=20 >> because nobody is currently working on fixing the two main issues=20 >> related to trust infrastructures: efficient revocation and=20 >> discoverability of services. >> >> *The Revocation Situation* >> >> Most of the times, when interacting with PKIs, we are still stuck=20 >> with CRLs, OCSP if we are lucky (including stapling - available in=20 >> TLS connections if really really lucky), and in most cases even these = >> mechanisms are criticized widely by people as being inadequate today. = >> This resulted in applications to use proprietary methods for checking = >> revocation (e.g., CRLSet) or to skip checking all together (or=20 >> mandate for short-lived certificates only as in the case, for=20 >> example, of STIR). >> >> Many people today ignore the fact that, when coupled with small=20 >> devices, the generation of new keys require (a) a lot of resources,=20 >> and (b) a good source of randomness. Requiring apps / devices to=20 >> generate new keys might seem a good idea at first, but is this better = >> than checking revocation ? What about the complexity of key management= ? >> >> /Examples of possible work to address the issues are OCSP over DNS=20 >> and some more efficient ways to verify the validity of a whole chain=20 >> of certificates efficiently./ >> >> *The Discoverability Situation* >> >> As far as I know, there are no standardized mechanisms that would=20 >> provide discoverability of services that would help users and=20 >> applications to discover Public Key Services providers and associated = >> services in a dynamic fashion. When I brought it up during the BoFs=20 >> of possible working groups where the issue could be discussed.. well, = >> the proposal was redirected to /dev/null (e.g., ACME, SPASM, and LAMPS= ). >> >> Isn't that curious that still today nobody is working on some sort of = >> infrastructure that would facilitate interacting with PKIs ? After=20 >> all, PKIs are the core Trust mechanism that enables reliable=20 >> authentication and encryption over the Internet today. Such=20 >> infrastructure could really improve the security of the Internet and=20 >> make PKIs more usable from an application (and users) standpoint of vi= ew. >> >> /Examples of possible work to address the issue are a PKI Resource=20 >> Query Protocol (PRQP) and/or the use of P2P systems as distribution=20 >> mechanisms for Public Key related operations (e.g., EST, BRSKI, or=20 >> ACME over P2P - 0-configuration support for PK)./ >> >> *Deployment Trends in the Real World* >> >> Today I am witnessing the deployment of arguably not-well-designed=20 >> PKIs (or, in other terms, what I call Weak PKIs) that do not provide=20 >> support for revocation and that are expected to use CAs and EE=20 >> certificates with validity periods of 30, 35, or 50 years (yes, also=20 >> EE - especially for devices). Besides the fact that it is a common=20 >> assumption that the algorithms (e.g., P-256) used in these=20 >> environments (e.g. IoT) are NOT going to pass the test of time,=20 >> ignoring the revocation could really affect the privacy of millions=20 >> of people - and we are currently not doing anything at the IETF to=20 >> prevent this issue. >> >> /There is the need for simple revocation services, but arguably we do = >> not have what's needed today (requires improvements)./ >> >> *IETF Specific Situation and Issues* >> >> Why are we so unprepared to face these issues ? I would say (still=20 >> personal point of view - based on almost 20 yrs of participation in=20 >> PKI discussions) that these might be some of the main reasons: >> >> * *There are NO venues where to discuss possible solutions to >> existing problems.* The PKIX working group has been closed down >> (very arbitrarily, I might say, since there is still a lot of >> work needed to be done around PKIX as highlighted above) >> >> * *The LAMPS, SPASM, and ACME WGs have/have had, on purpose, very >> narrow scoped Charters and only few items**(mostly quite marginal >> issues, IMO) are actually accepted as working items (w/ reference >> to SPASM and LAMPS in particular).* Solving revocation and >> discoverability issues should be the 1st item and the most >> important on the list (at least revocation) but they are not - >> actually when that was proposed to be included as part of the >> charter(s), the requests were not even acknowledged or rejected >> with no real technical reasons. >> >> * *The constant**nonsense of people saying that PKIs do not work as >> an excuse not to improve them while they (PKIs) are the reason we >> can deploy secure protocols and provide privacy. *It is evident >> that PKIs are here to stay, this is a fact. Their usage has >> increased exponentially in the past years and they have, so far, >> passed the test of time. IoT is one use-case. ANIMA is another. >> ACME is another. Just to cite few of them. >> >> Moreover, things are happening in environments outside IETF (WIFI 2.0 = >> Alliance, OpenADR, CMI, etc.) and IETF un-willingness of working on=20 >> these problems is really scary to me. The world moves forward, fast,=20 >> and the IETF is standing still on this topic./*I really do not=20 >> understand why.*/ >> >> *Final Considerations* >> >> In this message I try to summarize the reasons why I think there is=20 >> the need to provide a venue where these problems are discussed and=20 >> the need for key people to not actively block the possibility for=20 >> people that are willing to work on this to have a venue where the=20 >> work can be carried out. >> >> I think that this work is of the utter importance and I would like to = >> understand what the position of the whole security area is around=20 >> these points and the proposed work. >> >> /I hope that the discussion around this message can spark some=20 >> interest and that work in the PKIX area can finally resume at the=20 >> IETF - which was, in the past, thought of as the lighthouse where=20 >> these issues could be addressed./ >> >> A small request, please, try to read this e-mail carefully and=20 >> consider the implications of NOT taking on these tasks when replying=20 >> and/or discussing the topic. Also, since I know this (PKIX) is a=20 >> minefield for "political" reasons (which should not be a drive here), = >> please keep the discussion on the positive / constructive side (thanks= ). >> >> /If you feel like a private response is better than on the mailing=20 >> list, please just reply privately./ >> >> Looking forward to hear your opinions on this hoping that this e-mail = >> can be the beginning of the end of PKIX still-standing issues :D >> [...] > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm --=20 Best Regards, Massimiliano Pala, Ph.D. OpenCA Labs Director OpenCA Logo --------------55C774AE3E7DB6AD8D34BB65 Content-Type: multipart/related; boundary="------------DC6372BD571B6FE571CD48E6" --------------DC6372BD571B6FE571CD48E6 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

[ Cross Post: Saag, PKIX, and LAMPS ]

I just wanted to thank everybody for entertaining the idea of resuming the identified work for PKIX - it seems that we have overall support for the work considering the replies across the three MLs, thanks for expressing your opinions.

The candidate working group for picking up the work items seems LAMPS (thanks Russ for considering the work), so the discussion shall probably continue there. I will send the tentative items for the charter and milestones to the mailing list and see where this will take us.

Thanks again and looking forward to work on these important topics :D

Cheers,
Max


On 7/20/17 5:43 AM, Russ Housley wrote= :
Max:

If you can turn these into separate charter items with a description of the deliverable and milestones, then we can discuss each idea on its own. =A0Of course, in this group we expect that there be a commitment that it will be implemented.

Russ


On Jul 20, 2017, at 7:37 AM, Dr. Pala <director@openca.org> wrote:

Hi all,

I would like to draw the Sec Area attention= on an issue that I think is becoming more relevant every day.

It seems quite clear that today there is a lot of work around authentication and encryption that make use of PKIX certificates. However, there is no place in IETF, today, where problems related to PKIX can be effectively tackled. In the following paragraphs I try to summarize the issue and the proposed work and a call for discussion around the feasibility of resuming the work in two particular areas: revocation and discoverability.<= br class=3D"">
The Problem

What I noticed in recent proposals in many working groups (when it comes to certificate management) is that more and more people turn towards the use of short-lived certificates to avoid checking revocation information. Sometimes this choice is motivated by real technical considerations, but in many cases the choice is "forced" because nobody is currently working on fixing the two main issues related to trust infrastructures: efficient revocation and discoverability of services.

The Revocation Situation
=

Most of the times, when interacting with PKIs, we are still stuck with CRLs, OCSP if we are lucky (including stapling - available in TLS connections if really really lucky), and in most cases even these mechanisms are criticized widely by people as being inadequate today. This resulted in applications to use proprietary methods for checking revocation (e.g., CRLSet) or to skip checking all together (or mandate for short-lived certificates only as in the case, for example, of STIR).

Many people today ignore the fact that, whe= n coupled with small devices, the generation of new keys require (a) a lot of resources, and (b) a good source of randomness. Requiring apps / devices to generate new keys might seem a good idea at first, but is this better than checking revocation ? What about the complexity of key management ?

Examples of possible work to address the issues are OCSP over DNS and some more efficient ways to verify the validity of a whole chain of certificates efficiently.
=

The Discoverability Situation=

As far as I know, there are no standardized= mechanisms that would provide discoverability of services that would help users and applications to discover Public Key Services providers and associated services in a dynamic fashion. When I brought it up during the BoFs of possible working groups where the issue could be discussed.. well, the proposal was redirected to /dev/null (e.g., ACME, SPASM, and LAMPS).

Isn't that curious that still today nobody is working on some sort of infrastructure that would facilitate interacting with PKIs ? After all, PKIs are the core Trust mechanism that enables reliable authentication and encryption over the Internet today. Such infrastructure could really improve the security of the Internet and make PKIs more usable from an application (and users) standpoint of view.

Examples of possible work to address the issue are a PKI Resource Query Protocol (PRQP) and/or the use of P2P systems as distribution mechanisms for Public Key related operations (e.g., EST, BRSKI, or ACME over P2P - 0-configuration support for PK).

Deployment Trends in the Real= World

Today I am witnessing the deployment of arguably not-well-designed PKIs (or, in other terms, what I call Weak PKIs) that do not provide support for revocation and that are expected to use CAs and EE certificates with validity periods of 30, 35, or 50 years (yes, also EE - especially for devices). Besides the fact that it is a common assumption that the algorithms (e.g., P-256) used in these environments (e.g. IoT) are NOT going to pass the test of time, ignoring the revocation could really affect the privacy of millions of people - and we are currently not doing anything at the IETF to prevent this issue.

There is the need for simple revocation services, but arguably we do not have what's needed today (requires improvements).

IETF Specific Situation and Issues

Why are we so unprepared to face these issues ? I would say (still personal point of view - based on almost 20 yrs of participation in PKI discussions) that these might be some of the main reasons:

  • There are NO venues where = to discuss possible solutions to existing problems. The PKIX working group has been closed down (very arbitrarily, I might say, since there is still a lot of work needed to be done around PKIX as highlighted above)

  • The LAMPS, SPASM, and ACME= WGs have/have had, on purpose, very narrow scoped Charters and only few items (mostly quite marginal issues, IMO) are actually accepted as working items (w/ reference to SPASM and LAMPS in particular). Solving revocation and discoverability issues should be the 1st item and the most important on the list (at least revocation) but they are not - actually when that was proposed to be included as part of the charter(s), the requests were not even acknowledged or rejected with no real technical reasons.

  • The constant nonsense of people saying that PKIs do not work as an excuse not to improve them while they (PKIs) are the reason we can deploy secure protocols and provide privacy. It is evident that PKIs are here to stay, this is a fact. Their usage has increased exponentially in the past years and they have, so far, passed the test of time. IoT is one use-case. ANIMA is another. ACME is another. Just to cite few of them.

Moreover, things are happening in environments outside IETF (WIFI 2.0 Alliance, OpenADR, CMI, etc.) and IETF un-willingness of working on these problems is really scary to me. The world moves forward, fast, and the IETF is standing still on this topic. I really do not understand why.

Final Considerations

In this message I try to summarize the reasons why I think there is the need to provide a venue where these problems are discussed and the need for key people to not actively block the possibility for people that are willing to work on this to have a venue where the work can be carried out.

I think that this work is of the utter importance and I would like to understand what the position of the whole security area is around these points and the proposed work.

I hope that the discussion around this message can spark some interest and that work in the PKIX area can finally resume at the IETF - which was, in the past, thought of as the lighthouse where these issues could be addressed.

A small request, please, try to read this e-mail carefully and consider the implications of NOT taking on these tasks when replying and/or discussing the topic. Also, since I know this (PKIX) is a minefield for "political" reasons (which should not be a drive here), please keep the discussion on the positive / constructive side (thanks).

If you feel like a private response is better than on the mailing list, please just reply privately.

Looking forward to hear your opinions on this hoping that this e-mail can be the beginning of the end of PKIX still-standing issues :D
[...]
_______________________________________________
Spasm mailing list
Spas=
m@ietf.org
https://www.ietf.org/mailman/listinfo/spasm

--
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
3D"OpenCA
--------------DC6372BD571B6FE571CD48E6 Content-Type: image/png; name="bnnfcbolmdahhkai.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="bnnfcbolmdahhkai.png" iVBORw0KGgoAAAANSUhEUgAAAGQAAAA2CAMAAAAGesyaAAADAFBMVEUsJiEAAQAKAwMABwoX BwESCQAqDgEkEQItFQESGykaGh0WGyE1FwE9GwJHHwElJiY4JBQmKDE1KCAfLUQ8KygoMEAq MjpXKgs/MilMMR0pOFEyOUo4OTo1OkRqMgpjOBlpNxUwQV1DPz48QExdOyM4QVV+OQRRQzo1 SGdDR0lDSFJfRDFASVyaPwF+RRpNT1I9UXlwSi8+UnNDUm6hQgCPRhBdUEZTUlBKVGlPVF27 PgCaSANtUT57VBerSQOMUgxHW4KMUiepTwmJVDh6WT6KVjGCWDpRYH21TwFiYF57YgJXYXae VR+lVRZrYld1ZiB7YEuSYQBgZW+8VAlkZWjBVQCfXiqqXwG1WhPLVgedYDazXiDZVgCWZEDV WQJ1blapYjbXWgDRXACMaU6WbgCiZjnIXw9mcIixZC6pZjJ/cUeLbFdycmZ4cGnnWwNwc3Wq aS6BcGeobwndXwzkXwLgYgDaYwyMeCq/bQHJaBi9ajDMagWVegvRZxzVaAvXaQDLainqZAuv cEPrZQDQaSyockrFbSvmZwnabQLvZwDpaQB0fpPkaxGld1d+f3/3aACfeV6RfG2JfnLebSF7 gYy2fQmugQCigxW8d0K3eEr1bQXaciTicRqKgnzNewHuchbUdzKYiDzrdwKah1erjAvOfEXl eSq5g1qYjGikiHO2kADigwC2hmSZjIGGj6aHkJzQiwCximixim/EkAORkZGVkYrOh0rPiVL5 giTvhDKkk4LMjF23mR+zmTrhikrviDzsi0TAlHDCnwvKlGqpnJLdlF2boKy+m324nImkoZ+e o6XKpgrloATwl1WypZPOn3zfqQjYrgLBrVDdo3nGq5mysa/SrI7dq4bqqXTOrpWttL+6s6uw tbe/t4rhvALetpjQuqnuwwe9v8LAv7vauqD3xA68w9XBw83rvJfRwbXFyMvbxbPNyMP8zgTc zMDr0mb91xLM1ODQ1NfS1c7p0sD70bPd19PX4qj83cje4+Xr4tv54NLp7/Hy9PHw9fj6/v3Y ktvJAAAAAXRSTlMAQObYZgAAAAFiS0dEAIgFHUgAAAjrSURBVFjDtVcNWFPXGT6E+l9BZ0EF sTKEIQaUAIrTZdYqxqG0I3UjIuiDM0ipoyO5l0rFh2PE472EoIJKL9hQV2OxqM+USgFL4r9g EaIoQxgqKBZBR+nGGhXYdwNro0Kfkcp3ntzce/7e8/2e70PoJVDl3bMlZyurUSsaKnqESrMp lYrByozCjUOEUZORodMRVsViTjJc8GbLUGCUUstLv1SyLCGch8DGRiDPe/kY5/2HCQQTxZEE y4fb2gDI8KjjLxsjfyyc3lZgM3KixwgeY4TEzk7+kjHODbeb6u0xAhiw8XgFMOxolpP6J75U jLZfp6dzHIcBYCQbIBB4sCxDOLK6eMAVT39it57+e09ysCnDUtnrJ0vS5ZMW0PBFWDbd40G/ 85sH2KeXvj94u/flX8/2J6kYQkhkHbzWbkdH0N0UDN8sURS8uMd9dMzPL7BxIIjOayuWLBIf 70RPUPjxLouBEgVhMaYuWXQlMjwsN+eFTR4cDZ4werRDYOoAIFkrptm/Ni0gthOt9Q4yWQxc AwyWTbacW0sTDGoJen4P002/2S7LjgV6BpY1N6OO5g5eeiZTY/P9b1FzRwfKWuk9p/72ct+N puKpq32qLVaexOCCJB91aezt5y6zt7fXILSdJZjlVr1w0mCR66x6FL3QOXiUQ2a0k/sFlDlq 1LzUMQ4uxxycjl0LWO1bBsY6yXR3wSTJGxqLhdsJHDsS9cwF47XlvcQGQiXhRbih/HkQv4XO cajZb6GDu7PTFEdPkVu0k4vQyd3Jc/SUwNnB+RJ/XsI9ptZDIxMly3dbLNwGnGBJF+Id3cZM 9ui8Gjq5P/TDiRCegbOFgSKRo5e7yNHV2dnPdVb0bHfHQCevNIV/rxqrX48oFQdYcpKMtYRb juxtfqRypNACK28+j3FsqcilAD0ADuIWCt0yRa7zRNEOY2YELhW5CV2dXVKixH8BC+s8GDN9 wWKxf94zpsRiJuWmBYjgndsKFmu5Bc+D3HQXCcu7QTFTMl3HF0SLxruLvGa4zUqdMGFWqqfX 3GSxN0y6NT154i+v75zvH2thXiWgY2YVElhwYl9NYxarlr0grlQn92DQt1vBUk+nUFeHGZme gUIvl1RXr1AnV/fx6zd4v3HptM/YaXbrzmYFePu2WpowYRlJo+2PGLb2d9WE5bw1L4DcnOco 9HIcH3o02HOecMqMJhQqdLPXpArHl2uEo+Na8qZPXxw0+bVx46bFzhw3eZylM2dgwkbWW3Iy Jp9lMDe9H2/raiqPCy5/fHSCu+M7mkffoQuzQhvRhWVlj1FcWTfq6dwdElJmarxedr/u3P6C Nn7Fk95ol8wRjIMsOLGJSwLm/OMGjlFHJ7hqelDuxdMlpbU16JvqlJTamivoBjrfUgNB69zf b6Fr1TWPKmtOw9xCdLayEFWvBlaSfmEBsk6LSdTMNnQaldTe7Qfj20yveddR2toVEevCi9/f fmntR7ErtvompmyICM9qyYpZsG3FhqwNYRH5KUtyW7eGRRxfH1OHDv0ZXH6ihbSyVYzSY3Fu BkVR9LaS2wPxUxyTFpu2eGverr+dezvi0ttpOy/tTKlL2ZkWs6p4VV1Kyq60nevS8iLyi1tW hfNWzMfhYT+ArAQ+5odRBENjlRW5F/vH6O7u7urpXtvR/bQbmX/dPd3w7Ok+2Ij4ry5o0N/d Y1p7qA21FodhFRc1ctjIsXZ2Y18VcwCixNgcWlgVbUiue3b3J33te7497vv/oT1Bj5/7br1R grYlfrReSqmwPDyK0GqOUHKWj/RwP0J0ZlmsK3o2HP+7Qt9HBr3BYH5aNL3FG/+ul8sjKcxH dRJFGJkhfKxgmM2rUoaSg5h4GAwXJsF00dRGq+/21k2EF7o50oNswrNfsYUQKRBIZWIFh3lu aLNe1F++bjXGyWyzZiGoYFYLx5Ys4v0R3GWRdBHNErBiSiqVRhHMyeaYrMQ4SENWCvEcfhCm GIzpqKlm27KTSWUcAX1goBw5oATctDb33aLTYV5SWoaXP5+gyqlFdnZ23nB+plcnREv0RWJC BVkrrBJ1BewMmlVpgRUQF7wpItMJTcsJ34GBRVaFdQZaqoqxFmSb3qDQgu1A2GI4YAnODkQY IOhklDKzo2C1IV2sijzdhjorqwefNdL6ihxzegU7SynexHgBMXy+xWFG8qvdf91D8WpRi41q KFl02YaswYNkULTeLC9CFFK4bDHDMmZbhnuXSOdAsnN1LxgfVu7ZvG8LpSJUlO/gnaWQFwYv JpZeKdUaSC8ApuhIShYQYp5yWQ0oPgVXPtkcHz/fx5rqqzosHSSlBYHIxKSolJcUsIIpnzkh mt4b7Z/tOzBRQWaA6uNCNdet0nxLkL8CgzeQKIlCXaHjXR9MlqQn9Y1fNd5RE0zF/ryKwVR/ JMnsI3S8Umcw6NRYxRuUKqk3lfnKeGcTySAx5hy+7WfgZOv4uLLl0w8wUah71QLBpJeXq/eM VVivV8jz6lB2ofWF6i1dEYRZfMJ4piE+ZweNeb7A2VVyKEx6vjt1z/ghMehVKiUpyt1VYBXC N6j0Q4Mazp7TvvndhIaGhqqvP1bwFk0YRYR5RoLR+PkWmlIpV/oEDQ6jB9Wc3Z6bm6zLTtLl gLC4LVWXz5Q1ffbV5oZ24wmsV/NeKTlirmg+u/q7w7/38PDdeKF8UBgXs2kV4WUC0YR/KOLv Pby3L5O30yvG9vY/6vX8JSbb2je96coXX5QPznqfokKKEPWBAwd20ApaTWsP7LnTfsd42at3 +B+H7+zRUfwZZMutN6baHCX5+Ou9Zy4f3nuiKr7KaHxoNDbsSwhp6htvfyg3Zw901G+ttVlT Ja34/E+fvrXmvY3713xy6tSZfadOJby7X1P/vwn/MeaYr0mF7IMEq690Gu95KwQq5L5K+f59 qGUtaZMSciHMKjdVbY6zFqRC/pv3LgxY5tcW0pjIpGGJ7+89kxBnbXZSmjuz7CeyihyG8fbd XXYdrWlqQg+sZWTdzPqBB68VEdnkzDY0lHSjSD9/GRpaMt3OWqLpQENOTf/PpP8CK9ZVVe2a 8XoAAAAASUVORK5CYII= --------------DC6372BD571B6FE571CD48E6-- --------------55C774AE3E7DB6AD8D34BB65-- --------------ms060003020108090109000303 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CfUwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggU+MIIEJqADAgECAhEA/bu0LJsAKXVhEpPllE0lYzANBgkq hkiG9w0BAQsFADCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3Rl cjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVt YWlsIENBMB4XDTE2MTEzMDAwMDAwMFoXDTE3MTEzMDIzNTk1OVowJDEiMCAGCSqGSIb3DQEJ ARYTZGlyZWN0b3JAb3BlbmNhLm9yZzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AKnGg/GUuTjn0dKCEpRhVd+uiYbCjLQht+dbkvyRLm4aqlL7yHCe+21HQLIcU68ZCHT2ImpF CFFrxQMQh4KijAwkbLc8+xZZSwXeZt58qnPn5c4vcpYU5LFq1q9oDT8MXH33DhVUT/7/IDSi wRWM6FcgM6VrIjBmmvl9dW3gQaEd1bOAhO2X489fChRQYTaB6AEhqb8RSvWW7ZYzfNw8sPxV afMCzWBPpO5RmLqOciZBhAinAM9dXmP5ckg/HjJQYSjvTc7HDcg75mpr5wH8Tk/ChyIYk4CT zqONQV8HKCzZPTVmd2ZuMrliJwMFs3uEg0aBSzHjJTyAmZ89q5Mz3XsCAwEAAaOCAfEwggHt MB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBTGgh9JWBvcrak1 PhAWBLGrECNAjzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYM KwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQv Q1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NI QTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUF BwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9T SEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUF BzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wHgYDVR0RBBcwFYETZGlyZWN0b3JAb3Bl bmNhLm9yZzANBgkqhkiG9w0BAQsFAAOCAQEAdIqtPcvA+g6VTYUpEo0I9Vtnrf9PiZ3OpkRL O7U78EaeUfvOotThqj74XyrIl6eYlg+EdGIIUVB1CI05wPMRlZN3/R/Tj28vWkwckLRIbpL4 A5ZQyKgA9vK15/EEBVFIpCtAI6xJX0zx6TySlIgjcca05L0JgO7nzLGD2MY/dVWEE+QBuNI+ NBci+c+9q6YDPoXOpo0Wwbe0Bq95jNNWmZwhGzc+N5rhOGZmQT4P7TnpzvMik8ugbkqWyyHa DQbLKYzM1RKS/mwcvFqjJCQgORnaCilSbfClwdWGI7vwcTR8eAzduvwG61u46Cgb57K5sMck RicpWRvEYxCCVTwnozGCBEQwggRAAgEBMIGxMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMS R3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8g Q0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0 aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQD9u7QsmwApdWESk+WUTSVjMA0GCWCGSAFlAwQC AQUAoIICYzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzA3 MzExNjQxMDJaMC8GCSqGSIb3DQEJBDEiBCAYhqq3MUv6uof29UauLhpxmoK5C/1/DUlgEIIg 4k5eKzBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3 DQMCAgEoMIHCBgkrBgEEAYI3EAQxgbQwgbEwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRp b24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAP27tCybACl1YRKT5ZRNJWMwgcQGCyqGSIb3DQEJ EAILMYG0oIGxMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0ECEQD9u7QsmwApdWESk+WUTSVjMA0GCSqGSIb3DQEBAQUABIIBAAmAmP6sozczX0Sv KagIjfhWqaSlrF2f5+E1VayKzKxOJm8epa6yXSeQ5CtSRqJYT3rDBDP+glVMhOUgRxFjsbZm 3IgW0RinDC9PMu67eRR+VAaOlHLM40cdRmujRBW1Vq1Pj01sXqNcJA5yGz1dQupyqN+NePob MVBwgtoTjQD0IEZH0m5Lbq2Q0johy34U1e6ZFiRMtQtzdELTkDEjE8UxVVCJ0vShAaqS7lWY 3JDVGk4WyVZwI8NPcyTU3oxEw3Ip6ZOdY/rDwAAPSd1AuPzDfluUOUgC++B+j5ofXjv+9RO9 Ab1PqxKlnTQfWBZ40ZPZTIZyQKYj1AZ03fbhM8cAAAAAAAA= --------------ms060003020108090109000303--