From nobody Sun May 1 08:53:51 2016 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 4990512D0C6 for ; Sun, 1 May 2016 08:53:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P4DWz8mOZSXA for ; Sun, 1 May 2016 08:53:47 -0700 (PDT) Received: from mail.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id C18D112B011 for ; Sun, 1 May 2016 08:53:47 -0700 (PDT) Received: from localhost (ronin.smetech.net [209.135.209.5]) by mail.smetech.net (Postfix) with ESMTP id 938DCF2401F; Sun, 1 May 2016 11:53:47 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from mail.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id Amf3oYThrHRD; Sun, 1 May 2016 11:37:27 -0400 (EDT) Received: from russellsleysmbp.home (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.smetech.net (Postfix) with ESMTP id B5772F24013; Sun, 1 May 2016 11:53:36 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: <0afb01d1a355$d064a720$712df560$@augustcellars.com> Date: Sun, 1 May 2016 11:53:35 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <1B417FAF-53F0-47AC-BA78-0F2FC0B33AAE@vigilsec.com> References: <0afb01d1a355$d064a720$712df560$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: spasm@ietf.org, Laetitia Baudoin Subject: Re: [Spasm] Suggestions for draft-schaad-rfc5751-bis-00.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 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, 01 May 2016 15:53:50 -0000 I think we need to explain this situation in the security = considerations, at least to the level that an implementer knows what = services they are getting and not getting. Russ On Apr 30, 2016, at 11:01 PM, Jim Schaad wrote: >=20 >=20 > -----Original Message----- > From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Laetitia = Baudoin > Sent: Friday, April 29, 2016 12:44 PM > To: spasm@ietf.org > Subject: [Spasm] Suggestions for draft-schaad-rfc5751-bis-00.txt >=20 > Hi, >=20 > Could we update the text in section 3.4 [Creating an Authenticated > Enveloped-Only Message]? >=20 > Currently it states: > ----- >=20 > This section describes the format for enveloping a MIME entity > without signing it. It is important to note that sending > authenticated enveloped but not signed messages does not provide for > authentication or non-repudiation. It is possible to replace > ciphertext in such a way that the processed message will still be > valid, but the meaning can be altered. >=20 > ----- >=20 > Which is incorrect: alterations to the encrypted part of the message = would > be detected. > The problem is that authenticated encryption alone does not prove = anything > about the sender. >=20 > [JLS] It is not totally incorrect, but I would agree that it is = misleading. > The odds of being able change the message are approximately 1 in 2^128 > (assuming a 128-bit authentication tag). This is much better than the = CBC > world where the odds would be roughly 1 in 256. >=20 > An alternative to the last sentence could be something like "It is = possible > to change the sender without altering the validity of the processed > message". >=20 > [JLS] I find this to be a very misleading statement. I find that the = term > authenticated encryption to be very misleading. An AE algorithm only = gives > authentication about the sender under some very specific conditions, = and > those conditions are not generally found for many S/MIME messages. If = it > had been up to me, I would have called this class of algorithms = integrity > protected encryption rather than authenticated encryption. >=20 > Just to be clear, the following conditions would be required to have = an > authenticated encryption in terms of knowing who the sender is. 1) = You > would need to use an authenticated encryption algorithm, 2) One would = need > to have exactly one recipient information structure (otherwise any = other > recipient can change the message or forge a future message), and 3) = the CEK > would need to be a key directly derived from information about both = the > sender and the recipient. This would require the use of static-static = DH > which is not generally considered to be an option for S/MIME. >=20 > Given these conditions, I believe that it would be very unwise to say = that > one is going to get authentication from an S/MIME message. One will = get > integrity protection but that is a different service. >=20 > Jim >=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 From nobody Mon May 2 08:07:38 2016 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 8BCBB12D559 for ; Mon, 2 May 2016 08:07:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.697 X-Spam-Level: X-Spam-Status: No, score=-3.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 CSuSPAACIz7s for ; Mon, 2 May 2016 08:07:35 -0700 (PDT) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::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 860D112D103 for ; Mon, 2 May 2016 08:07:35 -0700 (PDT) Received: by mail-qk0-x22f.google.com with SMTP id x7so75250313qkd.3 for ; Mon, 02 May 2016 08:07:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-transfer-encoding; bh=w9Q1DJQlfMKvUz8IzYxmJTeUTdomNsqUGyHyCsY27Ak=; b=ghpjmyJuFo9hnpu0gZdsqK89CfUQPPDtMG6GzNITGAjcmd/SJkgzDENoY/NztMsF+z s2MGlcm7qjIZdRQ0gDulLSjKoVdRuPAyY01zeJIacIu1g25U+QJhzHlN4BrgbDsxjPhl GKJTYdh0QaK0kwmF1mciOXHyzXNCSlB14E0OV7Cylhq7w8ayp3AnRQ4Hptie5FdPwA3S szJiOHNlg0ueQJuEB5G/uI/sl8vsyylsBgg+43VKt64kUR2vVrWPyieNGa7IP2XJsV90 KDsSq/X0qPFkWRe+MgRmu9PUAXM+OadKEcKBfrZmdn5dBYZEvDZQ/bF7i6yN7+dMFVay l0/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=w9Q1DJQlfMKvUz8IzYxmJTeUTdomNsqUGyHyCsY27Ak=; b=d/2hupNZjxXst9abxQa0DtIJiCvmwr2PXy823ueIVaHlw/WLIqS4ijVeJJmQeyJOn6 TfdpCGQCRPqn2KDTiMJ+pcIXM4AqNDyS+aPVWO7B0gD1iqQG+Yc/7bPNS62jmXlAScAM Ft9GZpoti16N1P2mMvI2GWUUR99JsxwItH92sh7k/JM8hROLndSWjOZUwcP0x0u0AoFp WOkYy4PtTqpyFZmjBWppqsl7ZTPiXCOxbhuPsT+Ixyumc55I3CKt/y/OAiXRK26bQE/Z FbZqp73S5vqKdoFwVvKqXX7N6mJklKeaioTvy5LGHvU074HIBgUT7DcSyv+1A5JOunei n+Fg== X-Gm-Message-State: AOPr4FX6fEpdD63JNN08BE/fUjecRFoySIvtWE2gIZDWbU7tba522XKm5qoqfp+GLlOyZsiB6OVS+cQcMvhRa7DY MIME-Version: 1.0 X-Received: by 10.176.1.79 with SMTP id 73mr20254371uak.123.1462201654374; Mon, 02 May 2016 08:07:34 -0700 (PDT) Received: by 10.31.108.84 with HTTP; Mon, 2 May 2016 08:07:34 -0700 (PDT) In-Reply-To: <0afb01d1a355$d064a720$712df560$@augustcellars.com> References: <0afb01d1a355$d064a720$712df560$@augustcellars.com> Date: Mon, 2 May 2016 08:07:34 -0700 Message-ID: From: Laetitia Baudoin To: Jim Schaad Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: spasm@ietf.org Subject: Re: [Spasm] Suggestions for draft-schaad-rfc5751-bis-00.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 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, 02 May 2016 15:07:37 -0000 On Sat, Apr 30, 2016 at 8:01 PM, Jim Schaad wrote: > > > -----Original Message----- > From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Laetitia Baudoin > Sent: Friday, April 29, 2016 12:44 PM > To: spasm@ietf.org > Subject: [Spasm] Suggestions for draft-schaad-rfc5751-bis-00.txt > > Hi, > > Could we update the text in section 3.4 [Creating an Authenticated > Enveloped-Only Message]? > > Currently it states: > ----- > > This section describes the format for enveloping a MIME entity > without signing it. It is important to note that sending > authenticated enveloped but not signed messages does not provide for > authentication or non-repudiation. It is possible to replace > ciphertext in such a way that the processed message will still be > valid, but the meaning can be altered. > > ----- > > Which is incorrect: alterations to the encrypted part of the message would > be detected. > The problem is that authenticated encryption alone does not prove anything > about the sender. > > [JLS] It is not totally incorrect, but I would agree that it is misleading. > The odds of being able change the message are approximately 1 in 2^128 > (assuming a 128-bit authentication tag). This is much better than the CBC > world where the odds would be roughly 1 in 256. > > An alternative to the last sentence could be something like "It is possible > to change the sender without altering the validity of the processed > message". > > [JLS] I find this to be a very misleading statement. I find that the term > authenticated encryption to be very misleading. An AE algorithm only gives > authentication about the sender under some very specific conditions, and > those conditions are not generally found for many S/MIME messages. If it > had been up to me, I would have called this class of algorithms integrity > protected encryption rather than authenticated encryption. > > Just to be clear, the following conditions would be required to have an > authenticated encryption in terms of knowing who the sender is. 1) You > would need to use an authenticated encryption algorithm, 2) One would need > to have exactly one recipient information structure (otherwise any other > recipient can change the message or forge a future message), and 3) the CEK > would need to be a key directly derived from information about both the > sender and the recipient. This would require the use of static-static DH > which is not generally considered to be an option for S/MIME. > > Given these conditions, I believe that it would be very unwise to say that > one is going to get authentication from an S/MIME message. One will get > integrity protection but that is a different service. Jim, we agree that authenticated encryption doesn't provide authentication. My point was that the reason given in the draft is misleading. > > Jim > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm > From nobody Mon May 2 11:18:26 2016 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 19E0512D5B6 for ; Mon, 2 May 2016 11:18:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MuY8HpCyK_8j for ; Mon, 2 May 2016 11:18:24 -0700 (PDT) Received: from mail.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id D88C012D14E for ; Mon, 2 May 2016 11:18:24 -0700 (PDT) Received: from localhost (ronin.smetech.net [209.135.209.5]) by mail.smetech.net (Postfix) with ESMTP id 5579AF24035; Mon, 2 May 2016 14:18:24 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from mail.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id Z+YPkMjlLlqW; Mon, 2 May 2016 14:02:10 -0400 (EDT) Received: from [5.5.33.72] (vpn.snozzages.com [204.42.252.17]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.smetech.net (Postfix) with ESMTP id 64DE5F2402E; Mon, 2 May 2016 14:18:23 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: Date: Mon, 2 May 2016 14:18:17 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0afb01d1a355$d064a720$712df560$@augustcellars.com> To: Laetitia Baudoin X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: spasm@ietf.org Subject: Re: [Spasm] Suggestions for draft-schaad-rfc5751-bis-00.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 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, 02 May 2016 18:18:26 -0000 Laetitia: > Jim, we agree that authenticated encryption doesn't provide > authentication. My point was that the reason given in the draft is > misleading. Isn=92t this as simple as saying that confidentiality and integrity are = provided when auth-enveloped-data is employed? Russ From nobody Mon May 2 11:44:36 2016 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 5BD0612D10C for ; Mon, 2 May 2016 11:44:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.697 X-Spam-Level: X-Spam-Status: No, score=-3.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 mL-OvOK9YO0S for ; Mon, 2 May 2016 11:44:26 -0700 (PDT) Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::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 DE6E912D5B6 for ; Mon, 2 May 2016 11:44:25 -0700 (PDT) Received: by mail-vk0-x22a.google.com with SMTP id b189so6307718vkh.2 for ; Mon, 02 May 2016 11:44:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-transfer-encoding; bh=ey8TtkeO2ZeKvtxem19PN5Zme5H6sUdH9xXKFF7nOvo=; b=mL4e/4D1stLSNVcOS4bmVLxb1WHiyPpyPUadDzEXkrwC1IeYUJUig30rdowNYGA1S7 0bXTyquDmpW7sh5FLAOmbvWB15OY1JZp5Tx7eIG8d+/FAmE226GX291EQWNGEW9+SoUs tIxqbsjQwj3vDxf9ObzsOUmolQmBFcQ0I/kQLsRFeO3Xah/IEkcjKBs/1LMQc7Tr6W+t GABnFTXMuIKnQb1ceY1GtReewQO2SdsXL93IYFZIxNJMwqN9TIt3LBmAPI/LAIgmWr7G uuMF5MDxXWQbZnaS0HaF51hUiBhucoVZk87l7WgxhTVHiATRh9TlYjRG4mR00XRCD1t2 tuNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=ey8TtkeO2ZeKvtxem19PN5Zme5H6sUdH9xXKFF7nOvo=; b=buJQY26E+DmcYccDoBzzbt57UrtpzbTbRc3SlvMfiGJkOuVMf362XKmDQzixcxeHRz z+YtpAu90RziRRD5ck4Ng9FeBfYx5VzQ8QXNvHyaI94fVKoYl5oBEHgD13VUT9INM7LY TZ45wrFkEy9e0N5eXGHQ5eZ13N3HrYaVcbHdCNS0LcBdhr9g4O8RWlwq5azQpdhC+SWp geE9iO30qhW8qstr8bfGX7SEIY/0e5iCk76s6mVpoRd80N9dcYAZQc/Ff9uHwaKp9gsP M1cQWNkzVoZSMVarlbQom8hvOYYiya3Ij77mYaaQRq0ymKVjD3bArw7H+X8eJZdKPquy yeFg== X-Gm-Message-State: AOPr4FUuLePCEs7CK2nps0P09YJTED0AEq/eolSEOdYQ0sxxU/uOU5tRCc7G4fuYVwArS0vbiVmG7PNXbAbmEMuy MIME-Version: 1.0 X-Received: by 10.176.1.79 with SMTP id 73mr20878839uak.123.1462214664923; Mon, 02 May 2016 11:44:24 -0700 (PDT) Received: by 10.31.108.84 with HTTP; Mon, 2 May 2016 11:44:24 -0700 (PDT) In-Reply-To: References: <0afb01d1a355$d064a720$712df560$@augustcellars.com> Date: Mon, 2 May 2016 11:44:24 -0700 Message-ID: From: Laetitia Baudoin To: Russ Housley Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: spasm@ietf.org Subject: Re: [Spasm] Suggestions for draft-schaad-rfc5751-bis-00.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 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, 02 May 2016 18:44:29 -0000 On Mon, May 2, 2016 at 11:18 AM, Russ Housley wrote: > Laetitia: > >> Jim, we agree that authenticated encryption doesn't provide >> authentication. My point was that the reason given in the draft is >> misleading. > > Isn’t this as simple as saying that confidentiality and integrity are provided when auth-enveloped-data is employed? Agreed, it would be a better wording. > > Russ > From nobody Mon May 2 12:04:34 2016 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 12E8512D617 for ; Mon, 2 May 2016 12:04:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.696 X-Spam-Level: X-Spam-Status: No, score=-3.696 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, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 1bCXttpzC_Zm for ; Mon, 2 May 2016 12:04:18 -0700 (PDT) Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::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 C002B12D607 for ; Mon, 2 May 2016 12:04:17 -0700 (PDT) Received: by mail-ob0-x22e.google.com with SMTP id dm5so23220586obc.1 for ; Mon, 02 May 2016 12:04:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=OMD9uEzeysPWSJROGppdJiTV2pF/PZygm6a8MpgnyE4=; b=bvI0X302bgOWtxdS4nJIR89oJntpsJRZ2hQsLWg1pW6Rd4kdWL/EvNzDxPR2dZIXQG SAcP4r5ToIDRu2wCt5XTinuRrYJGpAbBw1u7JuCD/2b8a5o7umTLjvTfmYqjgg0HXUXH SwaoOtdwOFTX/zs4SI7CKGRA77nYJRAGyPiiM2zoJ6MdOVuzLGvoYTGKf+7AQPhbfQRZ qZKStjeMCTvRtz5ORHL5/oV11AHQrX25U586UvvOa4NeWTh1X5tIagE+2pCEb4S88gy/ 7pzZt5Pza64C18cAF+KgX/N5hrwjDnl0NMRR/Erdi3iYucZK/q5MBZvmCnx4OOWNbMsG x5YA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=OMD9uEzeysPWSJROGppdJiTV2pF/PZygm6a8MpgnyE4=; b=EsZi0SfD8iF0JRqWYBGZTObsr2kjyS9DFoC3xJ02NTvxhadLlT5vNbGMqKcF3bDwTi Th7NLscD+sZRT4MHx7WypdSv4EhYuHAFL/nlzFR1dPkVNzwPyNJ2qw+tMXeUyWOoJ+4h Jq21LKovBK9cCqOa3DE4czsnZs5J+K/7UiP6F6aphSpGCYN40IMFT+KZsEksU0WCnX45 WuCHRFSqzLwWO6ZCInz0QXHemdcBB5F82tcuO4bypQSLpXMt0TWUXN+ATwYlG8iabXEv GFDzzgVHxnX//J2FdUS5KhPz9MawnFO69zXeW2C2HS5Wy5qhSOWyR4+S2LBxhvUyGIL6 a9xg== X-Gm-Message-State: AOPr4FVFwyLmIpgQWExCbYpX2YmSmmtoOA9DVYHwMFfNq2YtaXtJm8IhXR6YEXf3BL9p/b5KUMJhD5GBGcJMvW1O MIME-Version: 1.0 X-Received: by 10.182.18.208 with SMTP id y16mr1376689obd.32.1462215856997; Mon, 02 May 2016 12:04:16 -0700 (PDT) Received: by 10.157.35.36 with HTTP; Mon, 2 May 2016 12:04:16 -0700 (PDT) In-Reply-To: <0afc01d1a35a$667346f0$3359d4d0$@augustcellars.com> References: <0afc01d1a35a$667346f0$3359d4d0$@augustcellars.com> Date: Mon, 2 May 2016 12:04:16 -0700 Message-ID: From: Wei Chuang To: Jim Schaad Content-Type: multipart/alternative; boundary=f46d043be138be437a0531e0a891 Archived-At: Cc: spasm@ietf.org, Laetitia Baudoin Subject: Re: [Spasm] Suggestions for draft-schaad-rfc5751-bis-00.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 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, 02 May 2016 19:04:33 -0000 --f46d043be138be437a0531e0a891 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On Sat, Apr 30, 2016 at 8:34 PM, Jim Schaad wrote: > Wei, > > > > See below. > > > > *From:* Spasm [mailto:spasm-bounces@ietf.org] *On Behalf Of *Wei Chuang > *Sent:* Friday, April 29, 2016 1:52 PM > *To:* Laetitia Baudoin > *Cc:* spasm@ietf.org > *Subject:* Re: [Spasm] Suggestions for draft-schaad-rfc5751-bis-00.txt > > > > First thanks goes to the authors of draft-schaad-rfc5751-bis-00 for doing > the update. > > > > On Fri, Apr 29, 2016 at 12:44 PM, Laetitia Baudoin > wrote: > > Hi, > > Could we update the text in section 3.4 [Creating an Authenticated > Enveloped-Only Message]? > > > Currently it states: > ----- > > This section describes the format for enveloping a MIME entity > without signing it. It is important to note that sending > authenticated enveloped but not signed messages does not provide for > authentication or non-repudiation. It is possible to replace > ciphertext in such a way that the processed message will still be > valid, but the meaning can be altered. > > ----- > > Which is incorrect: alterations to the encrypted part of the message > would be detected. > The problem is that authenticated encryption alone does not prove > anything about the sender. > > > An alternative to the last sentence could be something like "It is > possible to change the sender without altering the validity of the > processed message". > > > > > +1 Also I'm bothered by the second sentence as too alarming as potential > uses would presumably find a means to authenticate. > > > > [JLS] See my comments to Laetitia on why I don’t think authentication is > a viable option here. > > > > As this update also adds AES-GCM, can draft-housley-cms-chacha20-poly1305-00 > be considered too? That would help authenticated encryption algorithm > diversity. > > > > [JLS] As Russ said in his mail, the actual draft is not going through > this proposed working group. I would be open to having both AES-GCM and > ChaCha/Pol1305 as being listed as AEAD algorithms to be supported by the > message specification. I added in AES-GCM only because I needed to place > some algorithm in the draft to motivate the reason for adding the CMS > authenticated encryption algorithm. > > > > Also does this means that updating algorithms in general will be covered > in this pass? If so, can keysize and algorithm deprecation occur e.g. drop > md5? > > > > [JLS] Sean is unhappy, but I do believe that since the draft is open all > of these issues are open as well. I am not really sure what I want to say > about MD5 the current draft says it is supported so you can talk to (and > potentially read old message from) S/MIME v2 implementations. Are we > really sure that we want to shut off this option given that S/MIME v2 was > only made historical by RFC 5751 in 2010. I think we need to be careful > about how we make recommendations on MD5, but potentially doing a verify > but don’t send makes sense. > I understand backwards compatibility is going to be a thorny issue, but at the same time (and I'm sure this is preaching to choir) the overall security depends upon the weakest link. And for md5 and weak 512b RSA key sizes have (well) known attacks (e.g Flame, and DKIM email hack to Larry Page hack just as examples). It'll be much harder to trust a security protocol that already at the specification level allows vulnerable messages as authentic and private. How about a different approach. What about allowing support for historic keysizes and algorithms (of which I think md5 belongs) so archived messages can be read. However no assertion about the authenticity, integrity or privacy of messages using historic key sizes and algorithm be made, and supporting UI's must not provide assurances as such. And only messages using updated v3.5 S/MIME key sizes and algorithm are allowed to be considered authentic and private. > > > We need to have a strawman to discuss on key sizes, but this is normally a > very controversial topic. > > > > For possible work much farther down the road, I would suggest that section > 3.1 and details of wrapping messages in "message/rfc822" be clarified. > > > > [JLS] What are the things you want to be able to do that is not covered? > This was heavily discussed at the time the original RFC was done and it was > not possible to get any consensus about how to make this clearer than what > it is. > Indeed I was wondering as such. Hopefully things may be easier this time as there was strong interest in header privacy recently (certainly at IETF-94). Perhaps it might be possible to limit the scope to make it more feasible? The most useful header will be finding a specification for allowing "Subject:" to be hidden in the message/rfc822 part, and for it to be restored upon decryption. Followed by "Date:". Ideally the sender and recipient headers could be protected as well but there's the issues that you point out. > Indeed, there were tons of problems with deciding how to address what > fields are to be duplicated, what fields can be hidden, how to > show/highlight what happens in the event of a conflict between the fields. > Think about the situation of sending a signed message to the spasm mailing > list. In that event you get a new header added called sender that changes > how Outlook displays who the message is coming from. (Consider a case > where sender privacy is enforced by the mailing list.) The headers which > are authenticated by DKIM are no longer the same as the ones in the > message. > Would it help to start a separate discussion thread about this? Perhaps break out the scenarios for the different headers of interest? -Wei > There are lots of problems that need to be dealt with if we are going to > “clarify” this language. > > > > Jim > > > > > Thanks, > > -Wei > > > > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm > > > --f46d043be138be437a0531e0a891 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit


On Sat, Apr 30, 2016 at 8:34 PM, Jim Schaad <ietf@augustcellars.com> wrote:

Wei,

 

See below.

 

From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Wei Chuang
Sent: Friday, April 29, 2016 1:52 PM
To: Laetitia Baudoin <lbaudoin@google.com>
Cc: spasm@ietf.org
Subject: Re: [Spasm] Suggestions for draft-schaad-rfc5751-bis-00.txt

 

First thanks goes to the authors of draft-schaad-rfc5751-bis-00 for doing the update.

 

On Fri, Apr 29, 2016 at 12:44 PM, Laetitia Baudoin <lbaudoin@google.com> wrote:

Hi,

Could we update the text in section 3.4 [Creating an Authenticated
Enveloped-Only Message]?


Currently it states:
-----

This section describes the format for enveloping a MIME entity
   without signing it.  It is important to note that sending
   authenticated enveloped but not signed messages does not provide for
   authentication or non-repudiation.  It is possible to replace
   ciphertext in such a way that the processed message will still be
   valid, but the meaning can be altered.

-----

Which is incorrect: alterations to the encrypted part of the message
would be detected.
The problem is that authenticated encryption alone does not prove
anything about the sender.


An alternative to the last sentence could be something like "It is
possible to change the sender without altering the validity of the
processed message".

 


+1   Also I'm bothered by the second sentence as too alarming as potential uses would presumably find a means to authenticate.

 

[JLS] See my comments to Laetitia on why I don’t think authentication is a viable option here.

 

As this update also adds AES-GCM, can draft-housley-cms-chacha20-poly1305-00 be considered too?  That would help authenticated encryption algorithm diversity.

 

[JLS]  As Russ said in his mail, the actual draft is not going through this proposed working group.  I would be open to having both AES-GCM and ChaCha/Pol1305 as being listed as AEAD algorithms to be supported by the message specification.  I added in AES-GCM only because I needed to place some algorithm in the draft to motivate the reason for adding the CMS authenticated encryption algorithm. 

 

Also does this means that updating algorithms in general will be covered in this pass?  If so, can keysize and algorithm deprecation occur e.g. drop md5?

 

[JLS] Sean is unhappy, but I do believe that since the draft is open all of these issues are open as well.  I am not really sure what I want to say about MD5 the current draft says it is supported so you can talk to (and potentially read old message from) S/MIME v2 implementations.  Are we really sure that we want to shut off this option given that S/MIME v2 was only made historical by RFC 5751 in 2010.  I think we need to be careful about how we make recommendations on MD5, but potentially doing a verify but don’t send makes sense.


I understand backwards compatibility is going to be a thorny issue, but at the same time (and I'm sure this is preaching to choir) the overall security depends upon the weakest link.  And for md5 and weak 512b RSA key sizes have (well) known attacks (e.g Flame, and DKIM email hack to Larry Page hack just as examples).  It'll be much harder to trust a security protocol that already at the specification level  allows vulnerable messages as authentic and private.

How about a different approach.  What about allowing support for historic keysizes and algorithms (of which I think md5 belongs) so archived messages can be read.  However no assertion about the authenticity, integrity or privacy of messages using historic key sizes and algorithm be made, and supporting UI's must not provide assurances as such.  And only messages using updated v3.5 S/MIME key sizes and algorithm are allowed to be considered authentic and private.  
 

 

We need to have a strawman to discuss on key sizes, but this is normally a very controversial topic.

 

For possible work much farther down the road, I would suggest that section 3.1 and details of wrapping messages in "message/rfc822" be clarified.

 

[JLS] What are the things you want to be able to do that is not covered?  This was heavily discussed at the time the original RFC was done and it was not possible to get any consensus about how to make this clearer than what it is. 


Indeed I was wondering as such.  Hopefully things may be easier this time as there was strong interest in header privacy recently (certainly at IETF-94).  

Perhaps it might be possible to limit the scope to make it more feasible?  The most useful header will be finding a specification for allowing "Subject:" to be hidden in the message/rfc822 part, and for it to be restored upon decryption.  Followed by "Date:".  Ideally the sender and recipient headers could be protected as well but there's the issues that you point out. 
 

Indeed, there were tons of problems with deciding how to address what fields are to be duplicated, what fields can be hidden, how to show/highlight what happens in the event of a conflict between the fields.  Think about the situation of sending a signed message to the spasm mailing list.  In that event you get a new header added called sender that changes how Outlook displays who the message is coming from.  (Consider a case where sender privacy is enforced by the mailing list.)   The headers which are authenticated by DKIM are no longer the same as the ones in the message. 


Would it help to start a separate discussion thread about this?  Perhaps break out the scenarios for the different headers of interest?

-Wei
 

There are lots of problems that need to be dealt with if we are going to “clarify” this language.

 

Jim

 


Thanks, 

-Wei

 


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

 


--f46d043be138be437a0531e0a891-- From nobody Mon May 2 13:33:19 2016 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 4A58312D62A for ; Mon, 2 May 2016 13:33:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.696 X-Spam-Level: X-Spam-Status: No, score=-3.696 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, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 bQ2RFVHRE62S for ; Mon, 2 May 2016 13:33:14 -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 95C8F12D637 for ; Mon, 2 May 2016 13:33:13 -0700 (PDT) Received: by mail-oi0-x22f.google.com with SMTP id x19so205698344oix.2 for ; Mon, 02 May 2016 13:33:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=gIO9efmTNJ4ILRsRNsp5ayc6/CsowOWORk6mgOLKP/k=; b=U2nTdALJuAc3vrLeqAizVOUZS8EDqaokni1X1Jq91CU7FzloEqEd4thpV9cvkTlYKM K1rVApPJeg0y4PG0M4NJKjjXPQztwhrM2ZDUBmXPNR5ohp7JrLfdwU0bBZwjLLVsBb+G SAu/krYSNW1gHTWCLjdCGCl+bgwE7iobrnoE4Xtuwrv8ABqPNUJ1HQ0KuGbMohPFCm+w ktSn3U/GFl0V/5NM85N+OxsKUCyOi90cFtqqd0HG+Fn/PP5HnSGycgf/B0auj05TBqIP wO6NJs6TlYpxRUfOwVjMb2YSVeJ5khmqk4j5Sr2n6En7QcHnj2W6ES+rL7K8LdFbmTpd yZ3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=gIO9efmTNJ4ILRsRNsp5ayc6/CsowOWORk6mgOLKP/k=; b=lk23xASrEeu3QSG1xSKQ1kGgAZWuN3Icgr1N5qkDwWDQM2VAxhWM8tXzKwQoGoR/xm W36Xhc7C0jfUTW+wEFTgJ8TAYIq9+qCrKkQl2BlWjPvxhRKw+V/yXaLorppwDQKGqcWw hV4ENHCQAWy0lQpVTN8FIOHxukrHl4VyI9WyCrZqyQ46Kjq0+W6TK7LG6hD8fx6slmyC FqPSX+vuCr2KH7SLcLZirWNFEXTkEyxf+BnqhomFiSfcotDH4R7cGl4PBAGQTrThoSfl jtasQiuoB2+5AUNffLhbVFbl2vedpepvg+3JJgDGN3LZItx3u34CIIT5lNCgPZwVdXse Qx5Q== X-Gm-Message-State: AOPr4FUXJfI25tEd0M6eZu6Ouy7XowUHfBoh9OGAr/G0yyhG8043udqincsKoh6jdW6iTb/gedLo3Su7T/7Bf/aZ MIME-Version: 1.0 X-Received: by 10.202.202.143 with SMTP id a137mr14268475oig.128.1462221190010; Mon, 02 May 2016 13:33:10 -0700 (PDT) Received: by 10.157.35.36 with HTTP; Mon, 2 May 2016 13:33:09 -0700 (PDT) In-Reply-To: References: <0afc01d1a35a$667346f0$3359d4d0$@augustcellars.com> Date: Mon, 2 May 2016 13:33:09 -0700 Message-ID: From: Wei Chuang To: Jim Schaad Content-Type: multipart/alternative; boundary=001a1134faf29d63c90531e1e6c0 Archived-At: Cc: spasm@ietf.org, Laetitia Baudoin Subject: Re: [Spasm] Suggestions for draft-schaad-rfc5751-bis-00.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 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, 02 May 2016 20:33:17 -0000 --001a1134faf29d63c90531e1e6c0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On Mon, May 2, 2016 at 12:04 PM, Wei Chuang wrote: > > > On Sat, Apr 30, 2016 at 8:34 PM, Jim Schaad > wrote: > >> Wei, >> >> >> >> See below. >> >> >> >> *From:* Spasm [mailto:spasm-bounces@ietf.org] *On Behalf Of *Wei Chuang >> *Sent:* Friday, April 29, 2016 1:52 PM >> *To:* Laetitia Baudoin >> *Cc:* spasm@ietf.org >> *Subject:* Re: [Spasm] Suggestions for draft-schaad-rfc5751-bis-00.txt >> >> >> >> First thanks goes to the authors of draft-schaad-rfc5751-bis-00 for >> doing the update. >> >> >> >> On Fri, Apr 29, 2016 at 12:44 PM, Laetitia Baudoin >> wrote: >> >> Hi, >> >> Could we update the text in section 3.4 [Creating an Authenticated >> Enveloped-Only Message]? >> >> >> Currently it states: >> ----- >> >> This section describes the format for enveloping a MIME entity >> without signing it. It is important to note that sending >> authenticated enveloped but not signed messages does not provide for >> authentication or non-repudiation. It is possible to replace >> ciphertext in such a way that the processed message will still be >> valid, but the meaning can be altered. >> >> ----- >> >> Which is incorrect: alterations to the encrypted part of the message >> would be detected. >> The problem is that authenticated encryption alone does not prove >> anything about the sender. >> >> >> An alternative to the last sentence could be something like "It is >> possible to change the sender without altering the validity of the >> processed message". >> >> >> >> >> +1 Also I'm bothered by the second sentence as too alarming as >> potential uses would presumably find a means to authenticate. >> >> >> >> [JLS] See my comments to Laetitia on why I don’t think authentication is >> a viable option here. >> >> >> >> As this update also adds AES-GCM, can draft-housley-cms-chacha20-poly1305-00 >> be considered too? That would help authenticated encryption algorithm >> diversity. >> >> >> >> [JLS] As Russ said in his mail, the actual draft is not going through >> this proposed working group. I would be open to having both AES-GCM and >> ChaCha/Pol1305 as being listed as AEAD algorithms to be supported by the >> message specification. I added in AES-GCM only because I needed to place >> some algorithm in the draft to motivate the reason for adding the CMS >> authenticated encryption algorithm. >> >> >> >> Also does this means that updating algorithms in general will be covered >> in this pass? If so, can keysize and algorithm deprecation occur e.g. drop >> md5? >> >> >> >> [JLS] Sean is unhappy, but I do believe that since the draft is open all >> of these issues are open as well. I am not really sure what I want to say >> about MD5 the current draft says it is supported so you can talk to (and >> potentially read old message from) S/MIME v2 implementations. Are we >> really sure that we want to shut off this option given that S/MIME v2 was >> only made historical by RFC 5751 in 2010. I think we need to be careful >> about how we make recommendations on MD5, but potentially doing a verify >> but don’t send makes sense. >> > > I understand backwards compatibility is going to be a thorny issue, but at > the same time (and I'm sure this is preaching to choir) the overall > security depends upon the weakest link. And for md5 and weak 512b RSA key > sizes have (well) known attacks (e.g Flame, and DKIM email hack to Larry > Page hack just as examples). It'll be much harder to trust a security > protocol that already at the specification level allows vulnerable > messages as authentic and private. > I just saw mention of warning for key sizes less 1024 in 6. Security Considerations. Can the same be done for md5 digest, and generalized so that future obsolete algorithm and key sizes can be treated similarly? -Wei > > How about a different approach. What about allowing support for historic > keysizes and algorithms (of which I think md5 belongs) so archived messages > can be read. However no assertion about the authenticity, integrity or > privacy of messages using historic key sizes and algorithm be made, and > supporting UI's must not provide assurances as such. And only messages > using updated v3.5 S/MIME key sizes and algorithm are allowed to be > considered authentic and private. > > >> >> >> We need to have a strawman to discuss on key sizes, but this is normally >> a very controversial topic. >> >> >> >> For possible work much farther down the road, I would suggest that >> section 3.1 and details of wrapping messages in "message/rfc822" be >> clarified. >> >> >> >> [JLS] What are the things you want to be able to do that is not covered? >> This was heavily discussed at the time the original RFC was done and it was >> not possible to get any consensus about how to make this clearer than what >> it is. >> > > Indeed I was wondering as such. Hopefully things may be easier this time > as there was strong interest in header privacy recently (certainly at > IETF-94). > > Perhaps it might be possible to limit the scope to make it more feasible? > The most useful header will be finding a specification for allowing > "Subject:" to be hidden in the message/rfc822 part, and for it to be > restored upon decryption. Followed by "Date:". Ideally the sender and > recipient headers could be protected as well but there's the issues that > you point out. > > >> Indeed, there were tons of problems with deciding how to address what >> fields are to be duplicated, what fields can be hidden, how to >> show/highlight what happens in the event of a conflict between the fields. >> Think about the situation of sending a signed message to the spasm mailing >> list. In that event you get a new header added called sender that changes >> how Outlook displays who the message is coming from. (Consider a case >> where sender privacy is enforced by the mailing list.) The headers which >> are authenticated by DKIM are no longer the same as the ones in the >> message. >> > > Would it help to start a separate discussion thread about this? Perhaps > break out the scenarios for the different headers of interest? > > -Wei > > >> There are lots of problems that need to be dealt with if we are going to >> “clarify” this language. >> >> >> >> Jim >> >> >> >> >> Thanks, >> >> -Wei >> >> >> >> >> _______________________________________________ >> Spasm mailing list >> Spasm@ietf.org >> https://www.ietf.org/mailman/listinfo/spasm >> >> >> > > --001a1134faf29d63c90531e1e6c0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit


On Mon, May 2, 2016 at 12:04 PM, Wei Chuang <weihaw@google.com> wrote:


On Sat, Apr 30, 2016 at 8:34 PM, Jim Schaad <ietf@augustcellars.com> wrote:

Wei,

 

See below.

 

From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Wei Chuang
Sent: Friday, April 29, 2016 1:52 PM
To: Laetitia Baudoin <lbaudoin@google.com>
Cc: spasm@ietf.org
Subject: Re: [Spasm] Suggestions for draft-schaad-rfc5751-bis-00.txt

 

First thanks goes to the authors of draft-schaad-rfc5751-bis-00 for doing the update.

 

On Fri, Apr 29, 2016 at 12:44 PM, Laetitia Baudoin <lbaudoin@google.com> wrote:

Hi,

Could we update the text in section 3.4 [Creating an Authenticated
Enveloped-Only Message]?


Currently it states:
-----

This section describes the format for enveloping a MIME entity
   without signing it.  It is important to note that sending
   authenticated enveloped but not signed messages does not provide for
   authentication or non-repudiation.  It is possible to replace
   ciphertext in such a way that the processed message will still be
   valid, but the meaning can be altered.

-----

Which is incorrect: alterations to the encrypted part of the message
would be detected.
The problem is that authenticated encryption alone does not prove
anything about the sender.


An alternative to the last sentence could be something like "It is
possible to change the sender without altering the validity of the
processed message".

 


+1   Also I'm bothered by the second sentence as too alarming as potential uses would presumably find a means to authenticate.

 

[JLS] See my comments to Laetitia on why I don’t think authentication is a viable option here.

 

As this update also adds AES-GCM, can draft-housley-cms-chacha20-poly1305-00 be considered too?  That would help authenticated encryption algorithm diversity.

 

[JLS]  As Russ said in his mail, the actual draft is not going through this proposed working group.  I would be open to having both AES-GCM and ChaCha/Pol1305 as being listed as AEAD algorithms to be supported by the message specification.  I added in AES-GCM only because I needed to place some algorithm in the draft to motivate the reason for adding the CMS authenticated encryption algorithm. 

 

Also does this means that updating algorithms in general will be covered in this pass?  If so, can keysize and algorithm deprecation occur e.g. drop md5?

 

[JLS] Sean is unhappy, but I do believe that since the draft is open all of these issues are open as well.  I am not really sure what I want to say about MD5 the current draft says it is supported so you can talk to (and potentially read old message from) S/MIME v2 implementations.  Are we really sure that we want to shut off this option given that S/MIME v2 was only made historical by RFC 5751 in 2010.  I think we need to be careful about how we make recommendations on MD5, but potentially doing a verify but don’t send makes sense.


I understand backwards compatibility is going to be a thorny issue, but at the same time (and I'm sure this is preaching to choir) the overall security depends upon the weakest link.  And for md5 and weak 512b RSA key sizes have (well) known attacks (e.g Flame, and DKIM email hack to Larry Page hack just as examples).  It'll be much harder to trust a security protocol that already at the specification level  allows vulnerable messages as authentic and private.

I just saw mention of warning for key sizes less 1024 in 6. Security Considerations.  Can the same be done for md5 digest, and generalized so that future obsolete algorithm and key sizes can be treated similarly? 

-Wei
 

How about a different approach.  What about allowing support for historic keysizes and algorithms (of which I think md5 belongs) so archived messages can be read.  However no assertion about the authenticity, integrity or privacy of messages using historic key sizes and algorithm be made, and supporting UI's must not provide assurances as such.  And only messages using updated v3.5 S/MIME key sizes and algorithm are allowed to be considered authentic and private.  
 

 

We need to have a strawman to discuss on key sizes, but this is normally a very controversial topic.

 

For possible work much farther down the road, I would suggest that section 3.1 and details of wrapping messages in "message/rfc822" be clarified.

 

[JLS] What are the things you want to be able to do that is not covered?  This was heavily discussed at the time the original RFC was done and it was not possible to get any consensus about how to make this clearer than what it is. 


Indeed I was wondering as such.  Hopefully things may be easier this time as there was strong interest in header privacy recently (certainly at IETF-94).  

Perhaps it might be possible to limit the scope to make it more feasible?  The most useful header will be finding a specification for allowing "Subject:" to be hidden in the message/rfc822 part, and for it to be restored upon decryption.  Followed by "Date:".  Ideally the sender and recipient headers could be protected as well but there's the issues that you point out. 
 

Indeed, there were tons of problems with deciding how to address what fields are to be duplicated, what fields can be hidden, how to show/highlight what happens in the event of a conflict between the fields.  Think about the situation of sending a signed message to the spasm mailing list.  In that event you get a new header added called sender that changes how Outlook displays who the message is coming from.  (Consider a case where sender privacy is enforced by the mailing list.)   The headers which are authenticated by DKIM are no longer the same as the ones in the message. 


Would it help to start a separate discussion thread about this?  Perhaps break out the scenarios for the different headers of interest?

-Wei
 

There are lots of problems that need to be dealt with if we are going to “clarify” this language.

 

Jim

 


Thanks, 

-Wei

 


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

 



--001a1134faf29d63c90531e1e6c0-- From nobody Thu May 5 16:57:36 2016 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 69F6112D0AE for ; Thu, 5 May 2016 16:57:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.696 X-Spam-Level: X-Spam-Status: No, score=-3.696 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, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 ugVyipxgm9Pl for ; Thu, 5 May 2016 16:57:32 -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 9E3CA12B00F for ; Thu, 5 May 2016 16:57:32 -0700 (PDT) Received: by mail-oi0-x22c.google.com with SMTP id x201so121616266oif.3 for ; Thu, 05 May 2016 16:57:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=YDUjws2TQv07ymzZuKOHhR38qSNxiQ3nZk6nRB1tqxs=; b=UuUMYSv02GRJQAsrQqzOzfjExhACQ8sbO9+E9mahPjv4rm5UobomkMm8NJc/gvQ18V saFb2v+3Eb0dVm7q46f5vs7jRFET3dzBtaFMmYadDPjWj8NlUkVVJYnA6rPtjzX5kaTA mqLuzjoNyzwB5x0JvcXBv8LVVUq5NkPc9qbEl8DI7LBWOyXZcWDejkp6zDUgCTGIXTd5 lQDJ9U4Smn6WfURUeP1kz3XhJdpVYNcJLXs00lTPuTiHU1L0USPikBH5KjoN1jPeczjW kFoc9SNrDnVLJHKzCWp/HuY3/2l6XjVK9fGFziVecCzsYaCCvdNHiTrDmpIj3x2IN0Ca S0RA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=YDUjws2TQv07ymzZuKOHhR38qSNxiQ3nZk6nRB1tqxs=; b=OuBukm9pnP/GWDEkf38LwwOFv4EOBr+kbFHjDS2kkUsEk1ItjN4K86J2kqpRdFwqo1 Gt7+KrxA5U7LWMQUniCW14ICzePffpgJzA2DcyOU4oIc+gtHuUyWlWxh3ac5DNoK7uWt V7OFTJSYXlvBYlZk9tYGB/kwVdAzAicnUjK/cIYhe+356xyD5ewFt42OsFZB7TrVEWFy MFHV9/xGaEKBikL2rBI1/w8X0hHAICP3901N8L1dvlOLEpf0QEirnxcQvhr8zHZ+u2fX Ok7TsWBEe06y0boYwc65wj09vzxm3WJqHvjGrsqB5B6BbyQCovBRCpyu9JDmeNINeuPI /dDQ== X-Gm-Message-State: AOPr4FX1FD1oQFeNYcItLHtBtx7JONfSZKccrzeHX/FUqp/prR5e8M7FJWRtlwOmjtC63tZWtxH0BdMzPmIPVFqz X-Received: by 10.157.15.69 with SMTP id 63mr9015903ott.26.1462492651926; Thu, 05 May 2016 16:57:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.35.36 with HTTP; Thu, 5 May 2016 16:57:31 -0700 (PDT) From: Wei Chuang Date: Thu, 5 May 2016 16:57:31 -0700 Message-ID: To: spasm@ietf.org Content-Type: multipart/alternative; boundary=94eb2c033886018a030532211b5d Archived-At: Subject: [Spasm] Consideration for MD5 as untrusted in RFC5751bis? (and related doc) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 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, 05 May 2016 23:57:34 -0000 --94eb2c033886018a030532211b5d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi everyone, I wanted to bring more eyes to the proposal which is to treat MD5 digest as untrusted in updates to draft-schaad-rfc5751-bis-00. Its been long documented in RFC6151 which is from 2011 that "MD5 is no longer acceptable where collision resistance is required such as digital signatures". And since then there have been real world examples where MD5 has been exploited e.g. search for "Flame MD5". Note when the exploit was posted, and consider that compute power has substantially improved increasing the accessibility of the exploit. Consequently as we update RFC5751 we should deprecate MD5 from the list of trusted algorithms. We should similarly do this for RFC5750 i.e. consider a RFC5750bis and deprecate MD5 there as well. Now understandably there is the issue of backwards compatibility. There already is support in both documents for this as it specifies warning users when RSA and DSA with keysize < 1024 is used. It also differentiates treatment of archived messages from newly received messages. We should do the same for MD5, and formalize this process for other future deprecations of keylength and algorithms. I further propose that language be adjusted so sending agents must not use these deprecated algorithm or keysize. Please provide your opinion / feedback as community opinion is very important for this issue. thanks very much, -Wei --94eb2c033886018a030532211b5d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Hi everyone,

I wanted to bring more eyes to the proposal which is to treat MD5 digest as untrusted in updates to  draft-schaad-rfc5751-bis-00.  Its been long documented in RFC6151 which is from 2011 that "MD5 is no longer acceptable where collision resistance is required such as digital signatures".  And since then there have been real world examples where MD5 has been exploited e.g. search for "Flame MD5".  Note when the exploit was posted, and consider that compute power has substantially improved increasing the accessibility of the exploit.  Consequently as we update RFC5751 we should deprecate MD5 from the list of trusted algorithms.  We should similarly do this for RFC5750 i.e. consider a RFC5750bis and deprecate MD5 there as well.

Now understandably there is the issue of backwards compatibility.  There already is support in both documents for this as it specifies warning users when RSA and DSA with keysize < 1024 is used.   It also differentiates treatment of archived messages from newly received messages.   We should do the same for MD5, and formalize this process for other future deprecations of keylength and algorithms.  I further propose that language be adjusted so sending agents must not use these deprecated algorithm or keysize.

Please provide your opinion / feedback as community opinion is very important for this issue.

thanks very much,
-Wei
--94eb2c033886018a030532211b5d-- From nobody Wed May 11 11:21:21 2016 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 02D5F12D183 for ; Wed, 11 May 2016 11:21:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.297 X-Spam-Level: X-Spam-Status: No, score=-5.297 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.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vu6IZwJnhxTz for ; Wed, 11 May 2016 11:21:18 -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 31D2112D54C for ; Wed, 11 May 2016 11:21:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id CD50FBE2D for ; Wed, 11 May 2016 19:21:06 +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 TEdg4UmKiDat for ; Wed, 11 May 2016 19:21:05 +0100 (IST) Received: from [172.20.10.8] (unknown [172.56.3.38]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id C56B3BE29 for ; Wed, 11 May 2016 19:21:04 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1462990865; bh=6slnQLcs99QQqVU6yXpKjfTAHU7cuguGpUb8lNzFLMc=; h=Subject:To:References:From:Date:In-Reply-To:From; b=hznoI6QdgXrKiaHCTDmPPXMIBZunLYQ9GNe5hqpijecP2sLsfIboanYCeclCu4GtQ ybpVbhxut2/0ACPfs7N8sxZwqs2xZxV4hRtuuafbUdz41VG5fI83bz2yXT/XcefDC0 6+WXHeNHhOfimha0cct8nWyd1SMNgyQiTz2iREa8= To: spasm@ietf.org References: <571795E5.6080008@cisco.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <5733780E.6010209@cs.tcd.ie> Date: Wed, 11 May 2016 19:21:02 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <571795E5.6080008@cisco.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="FLpS45CdRg2PubaaDf5L1XxuEDLxNMNVQ" Archived-At: Subject: Re: [Spasm] proposed work item X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 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, 11 May 2016 18:21:21 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --FLpS45CdRg2PubaaDf5L1XxuEDLxNMNVQ Content-Type: multipart/mixed; boundary="b1CTCW2GcOEo5MN6eUku1OxwGOvXHCtkR" From: Stephen Farrell To: spasm@ietf.org Message-ID: <5733780E.6010209@cs.tcd.ie> Subject: Re: [Spasm] proposed work item References: <571795E5.6080008@cisco.com> In-Reply-To: <571795E5.6080008@cisco.com> --b1CTCW2GcOEo5MN6eUku1OxwGOvXHCtkR Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, On 20/04/16 15:44, Eliot Lear wrote: > Hi everyone, >=20 > At least for the moment, I'd like to propose a work item that was liste= d > in Stephen's original note, I believe, which is > draft-lear-ietf-pkix-mud-extension. I say, =E2=80=9Cat least for the m= oment=E2=80=9D > because we may want to consolidate MUD work elsewhere later. I think > the ADs will want to talk about that at some point. Does anyone else support pursuing the relevant part of MUD in the proposed spasm wg? Thanks, S. >=20 > Eliot >=20 >=20 >=20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm >=20 --b1CTCW2GcOEo5MN6eUku1OxwGOvXHCtkR-- --FLpS45CdRg2PubaaDf5L1XxuEDLxNMNVQ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJXM3gOAAoJEC88hzaAX42iO9QIAI8a+FbxXdqc4LfOQZpFcNd0 XCxxBRBa1Yx74lqjfvwqQVK3YMKwK7WXyXRB8+lM/wyuIm311mDbEQjDyrfSkrgq CLIp+2iXXg18bxxBlqvJkGEg/h493xPdy8OH1SNbeWo1RhyGN35MQvVO2ZVIBpKO +KokLlbHqhbTMAG6Dw9GKizVR5Ycays8AplHxWoV+cS8rqxqI0bxB15lJ2YCfBBk DdNYSQxGIDSpDhA5nNV0E60EEIIegu3ybIS6fKLffkHnPo44HLEDJCs1C2tKpRGb rowipAdg0zV10LiYGxUTgLDX6Ih02oPUmHZiR5+1g43Lic2Gu2/ZyBj0iJ6VMuw= =OSyC -----END PGP SIGNATURE----- --FLpS45CdRg2PubaaDf5L1XxuEDLxNMNVQ-- From nobody Wed May 11 11:29:27 2016 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 3450B12D724 for ; Wed, 11 May 2016 11:29:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.297 X-Spam-Level: X-Spam-Status: No, score=-5.297 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.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id knHyofDlfFVN for ; Wed, 11 May 2016 11:29:24 -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 A53E312D720 for ; Wed, 11 May 2016 11:29:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 77676BE2D for ; Wed, 11 May 2016 19:29:17 +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 fr7KaAAluZvW for ; Wed, 11 May 2016 19:29:16 +0100 (IST) Received: from [172.20.10.8] (unknown [172.56.3.38]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 5F7A4BE29 for ; Wed, 11 May 2016 19:29:15 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1462991356; bh=HW7LP+E7GXFjzpFCk6sddKO2RPH2519YmTc4jczmhQE=; h=Subject:To:References:From:Date:In-Reply-To:From; b=xplMu4scFfqNxW0e06rTvLg3VqPAd12w/XE7kdjI7cXBk4r/ZYEiKh9NvgB8CgtBt Z15NfDZ5ieHmcDL5TkkfVgeXNdaL2FpxRIhnO0uOu0uhMCYyGrjNI5GIKis+WLeQIC HlU2w0eSA9NhaovzQrMHlvi1RCidnm3SsoOmz5xo= To: spasm@ietf.org References: <20160421141229.21655.qmail@ary.lan> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <573379F9.9000105@cs.tcd.ie> Date: Wed, 11 May 2016 19:29:13 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <20160421141229.21655.qmail@ary.lan> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms070706020009040301010400" Archived-At: Subject: Re: [Spasm] DRAFT charter text X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 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, 11 May 2016 18:29:26 -0000 This is a cryptographically signed message in MIME format. --------------ms070706020009040301010400 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 21/04/16 15:12, John Levine wrote: >> Now, we are discussing the draft charter >=20 > If there's room, I'd like to work on S/MIME and PGP key distribution > as in draft-bhjl-x509-srv-00. I realize the desire to keep the list > of drafts short, but this one is pretty simple, little more than a > profile of RFC 4387. Does anyone else support pursuing work on this draft in the proposed spasm wg? Cheers, S. >=20 > R's, > John >=20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm >=20 --------------ms070706020009040301010400 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 CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA1MTEx ODI5MTNaMC8GCSqGSIb3DQEJBDEiBCDjHTmksnIuHk89DFkgw9wQIKcyTphc1huKc4w3H5o8 czBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQCr0Q6l2J/6T4qdJPnVWIO1QZG1TAJemY0tmxLpSKe3/mAgPkW0URo+ DCSFETYGHPWDmUr6C6d/FXWV3gSNtJxlj6pAhTIQHRQ3Jo1BrxGLvlweoHvrhIT9mAg6d6tX OBSfUjhs1GmNiP8voHGTSuQ223m8vui/a+Qr1cxvGgjURdX1uHIQ6Z7SUy2swY9t7kxy0iIo HnH7hd6kzxNWI43CotiJ0WfZmF5FXxwcOnNA94kYLZoSB90kyjrEd8mrCRFmfFr+hcLr/95v NSG1oHTATtEgkptTXxENNF0oPBvy4JC5uZ82vxis/Y5aebHkdiRmiC31ij+B/lkgA/ev+x+8 AAAAAAAA --------------ms070706020009040301010400-- From nobody Wed May 11 11:34:35 2016 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 2E57712D73D for ; Wed, 11 May 2016 11:34:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.696 X-Spam-Level: X-Spam-Status: No, score=-3.696 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, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 bBQHGlRMwuFF for ; Wed, 11 May 2016 11:34:31 -0700 (PDT) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::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 3E0F312D730 for ; Wed, 11 May 2016 11:34:30 -0700 (PDT) Received: by mail-oi0-x236.google.com with SMTP id x201so82359114oif.3 for ; Wed, 11 May 2016 11:34:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=eWGEuzAQ96o++FWmkc0M/eZmHwkdo28OLHKpDjWrqyk=; b=OpV+8iMonC/CrQv7uhygxrzDo32RyEMdy2RoCd1QbHy09hv0t9Qg5Dp/OhsMTyT0Hu Zhjiv4p41gv8fst2cB8IIAPTzJ0M0iidKjZBdX6MawMryQye5mCnCpZdsSbEfJ03LCiA UELTKEpkwC5SvPmY4jmZqlA2sIA3321s1lc0ZsDrlncuoW11V70UrcBVLO9jnd/BuWhm 6gbCnPHMQhevrFMtZLbBObvH+oFzExBmwh53OsKsOCP1bwp7vxMBtib51h1UdGEQMX9g nfCq1Owub+nt0ozlPH/H+DSzA3MT/vKTGiVDQYXJ6oXSNb2z6QKPlJbjERRMpOOYk5gl WAKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=eWGEuzAQ96o++FWmkc0M/eZmHwkdo28OLHKpDjWrqyk=; b=MV/5CPEfZ9Las/cmyCRpqTz6+yLWbBZgbWtl7Fs8qi0FdLj17qgvIEbEIk9fRyenvW K6tKTNF1YFR16LvLZHXyZy/ECqmIxiY4WGKZ5MyV4CrDD8LuxB0WnMqTxLTDRImUzh3F OXsnAz/5IM0TNiBAJJepEMVVpS/trx8DbYuqq2L9x2PYgu9s8pkqfYFtDW/u9S8z8atI Qx9aKRSrrawu2GNpQ+3484EizY0kDlbhJ7Ff5zSCnmUx363Gvjc4Qn2iSb/pqa+wee5S SFJYBDcbiLI/XWjLY526vHspSc2l08sNOMs9DtAfgJhwepbRJbf0xAyRUfb8onitLbKZ U+lg== X-Gm-Message-State: AOPr4FX424FRm9CZ2g0CP8kbP1Tvcoc3UlIxoKD3rBohYgtiSOnCkmhYFrn0piXh78YuZu3sUhxVS0v0M0WR3izm X-Received: by 10.202.234.212 with SMTP id i203mr2368537oih.80.1462991669547; Wed, 11 May 2016 11:34:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.35.36 with HTTP; Wed, 11 May 2016 11:34:28 -0700 (PDT) In-Reply-To: <573379F9.9000105@cs.tcd.ie> References: <20160421141229.21655.qmail@ary.lan> <573379F9.9000105@cs.tcd.ie> From: Wei Chuang Date: Wed, 11 May 2016 11:34:28 -0700 Message-ID: To: Stephen Farrell Content-Type: multipart/alternative; boundary=001a113c26f4c64f9b0532954ae3 Archived-At: Cc: spasm@ietf.org Subject: Re: [Spasm] DRAFT charter text X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 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, 11 May 2016 18:34:34 -0000 --001a113c26f4c64f9b0532954ae3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit I think bhjl-x509-srv-00 is useful, and believe spasm is the right place to work on it. -Wei On Wed, May 11, 2016 at 11:29 AM, Stephen Farrell wrote: > > > On 21/04/16 15:12, John Levine wrote: > >> Now, we are discussing the draft charter > > > > If there's room, I'd like to work on S/MIME and PGP key distribution > > as in draft-bhjl-x509-srv-00. I realize the desire to keep the list > > of drafts short, but this one is pretty simple, little more than a > > profile of RFC 4387. > > Does anyone else support pursuing work on this draft in the > proposed spasm wg? > > Cheers, > S. > > > > > R's, > > John > > > > _______________________________________________ > > 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 > > --001a113c26f4c64f9b0532954ae3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
I think bhjl-x509-srv-00 is useful, and believe spasm is the right place to work on it.  

-Wei

On Wed, May 11, 2016 at 11:29 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:


On 21/04/16 15:12, John Levine wrote:
>> Now, we are discussing the draft charter
>
> If there's room, I'd like to work on S/MIME and PGP key distribution
> as in draft-bhjl-x509-srv-00.  I realize the desire to keep the list
> of drafts short, but this one is pretty simple, little more than a
> profile of RFC 4387.

Does anyone else support pursuing work on this draft in the
proposed spasm wg?

Cheers,
S.

>
> R's,
> John
>
> _______________________________________________
> 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


--001a113c26f4c64f9b0532954ae3-- From nobody Wed May 11 11:36:50 2016 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 E323412D73E for ; Wed, 11 May 2016 11:36:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 HsIUsMQ2KqSq for ; Wed, 11 May 2016 11:36:45 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE83A12D738 for ; Wed, 11 May 2016 11:36:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4864; q=dns/txt; s=iport; t=1462991784; x=1464201384; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=HMRu0jC4YzhrcK7KFcU219iahKjd2msj6muFCPpzQV8=; b=IE3aogP2I+UDmXNrJRTwHFVWZF0bJsUszzWUNzwfJD3zq/CGmVq1tNLa ilZD+NpT0YHlaXxVKFhzewOdhYFSJ7TqBiQp5UdnRyUiCSnNeUVcE1JCL PKg/XC8El2DZ63yvUWevi29yOMp8WvzJw0l/jAq0cCoarfOlng/ibf7id g=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AYAwCaejNX/xbLJq1ehA19tDmEdw6Bd?= =?us-ascii?q?hcBCoVyAoF1FAEBAQEBAQFlJ4RDAQEEAQEBIEsKEQsEFAkWCwICCQMCAQIBFTA?= =?us-ascii?q?GAQwGAgEBiCsOqXyQaQEBAQEBAQEBAQEBAQEBAQEBAQEPBASKbIc/glkBBJgng?= =?us-ascii?q?ymBaIkNiT+FWo9BHgFDg206MokKAQEB?= X-IronPort-AV: E=Sophos;i="5.24,608,1454976000"; d="asc'?scan'208,217";a="634577349" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 May 2016 18:36:22 +0000 Received: from [10.61.97.31] (dhcp-10-61-97-31.cisco.com [10.61.97.31]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u4BIaM6d024795; Wed, 11 May 2016 18:36:22 GMT To: Stephen Farrell , spasm@ietf.org References: <571795E5.6080008@cisco.com> <5733780E.6010209@cs.tcd.ie> From: Eliot Lear Message-ID: <57337BA5.8050801@cisco.com> Date: Wed, 11 May 2016 20:36:21 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <5733780E.6010209@cs.tcd.ie> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="CreFeiwJcWpcm3hKtrV4v7hOowhSo5mMo" Archived-At: Subject: Re: [Spasm] proposed work item X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 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, 11 May 2016 18:36:49 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --CreFeiwJcWpcm3hKtrV4v7hOowhSo5mMo Content-Type: multipart/mixed; boundary="riCD7XiRNFvoPDOV6u9msoxcbGfAAR1sx" From: Eliot Lear To: Stephen Farrell , spasm@ietf.org Message-ID: <57337BA5.8050801@cisco.com> Subject: Re: [Spasm] proposed work item References: <571795E5.6080008@cisco.com> <5733780E.6010209@cs.tcd.ie> In-Reply-To: <5733780E.6010209@cs.tcd.ie> --riCD7XiRNFvoPDOV6u9msoxcbGfAAR1sx Content-Type: multipart/alternative; boundary="------------070000040606000806070801" This is a multi-part message in MIME format. --------------070000040606000806070801 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Stephen, I'm withdrawing the suggestion. I'll be consolidating the drafts a bit and expect the work to continue elsewhere. Eliot On 5/11/16 8:21 PM, Stephen Farrell wrote: > Hi all, > > On 20/04/16 15:44, Eliot Lear wrote: >> Hi everyone, >> >> At least for the moment, I'd like to propose a work item that was list= ed >> in Stephen's original note, I believe, which is >> draft-lear-ietf-pkix-mud-extension. I say, =E2=80=9Cat least for the = moment=E2=80=9D >> because we may want to consolidate MUD work elsewhere later. I think >> the ADs will want to talk about that at some point. > Does anyone else support pursuing the relevant part of MUD in the > proposed spasm wg? > > Thanks, > S. > >> Eliot >> >> >> >> _______________________________________________ >> 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 --------------070000040606000806070801 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Stephen,

I'm withdrawing the suggestion.=C2=A0 I'll be consolidating the draft= s a bit and expect the work to continue elsewhere.

Eliot

On 5/11/16 8:21 PM, Stephen Farrell wrote:
Hi all,

On 20/04/16 15:44, Eliot Lear wrote:

Hi everyone,

At least for the moment, I'd like to propose a work item that was listed
in Stephen's original note, I believe, which is
draft-lear-ietf-pkix-mud-extension.  I say, =E2=80=9Cat least for the mom=
ent=E2=80=9D
because we may want to consolidate MUD work elsewhere later.  I think
the ADs will want to talk about that at some point.

Does anyone else support pursuing the relevant part of MUD in the
proposed spasm wg?

Thanks,
S.


Eliot



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



      

      

      

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


    

    

  


--------------070000040606000806070801--

--riCD7XiRNFvoPDOV6u9msoxcbGfAAR1sx--

--CreFeiwJcWpcm3hKtrV4v7hOowhSo5mMo
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2

iQEcBAEBCAAGBQJXM3umAAoJEIe2a0bZ0nozuJAH/06WSFWkBLWw4gKAA9X2Vd2U
R6OcZBThmJfi5oB/SeFiHbBm+Dmjr2Rrj0jP+aeRF5Q2gV5H/Oh8d7cm7rLHAWiY
Q0S8cvQnJbjBlV6WoV2GlheWM2cwlODJlDsJZWFPp3etUWCq9GHL1Ej+rHRt9X9i
qMAi9wd2rPJ/LtZjM/INPDMFMXMhpOvylZI1YuTS6RoFtrtwzYYY9M09+02S5LJk
/wKB/uaJl2UfeOLoiD3APPv/9UKaECWV08EwGPEHRPLH/ykEnfZZgeIkTBPrDDR/
5adTNetOjChAud12lSa8TA6/enCR9ZXzoghQ82pti0bMAXkET5NGec6cL8wUUpE=
=apLd
-----END PGP SIGNATURE-----

--CreFeiwJcWpcm3hKtrV4v7hOowhSo5mMo--


From nobody Wed May 11 11:38:43 2016
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 8624912D735 for ; Wed, 11 May 2016 11:38:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.297
X-Spam-Level: 
X-Spam-Status: No, score=-5.297 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.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uiNPBFjfTF4r for ; Wed, 11 May 2016 11:38:35 -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 2BDB112D71B for ; Wed, 11 May 2016 11:38:32 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id ED9DEBE33; Wed, 11 May 2016 19:38:30 +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 uXGnRr4O6zJ6; Wed, 11 May 2016 19:38:29 +0100 (IST)
Received: from [172.20.10.8] (unknown [172.56.3.38]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 8B6A3BE2D; Wed, 11 May 2016 19:38:28 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1462991909; bh=nkvV6ABxUE7TerYyo76M0qctkCaw2Yc8+CXa7+msEd8=; h=Subject:To:References:From:Date:In-Reply-To:From; b=YGiaxNaypcjdnQLqV5pUg6lwPzL2YD0f6/HnBJAf1jLIibIApGkf8k0IwXXhwL4cF YqFvJjajSq8jVcNobH0qEi1va1qfSWfVgbYL8ts5/y3yYTYFirJ58IwZC6MVZDbFtM lbpKAt8iS7UGiM5ReEJw6OFcbylDGAiDoeaw7tS8=
To: Eliot Lear , spasm@ietf.org
References: <571795E5.6080008@cisco.com> <5733780E.6010209@cs.tcd.ie> <57337BA5.8050801@cisco.com>
From: Stephen Farrell 
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <57337C22.70307@cs.tcd.ie>
Date: Wed, 11 May 2016 19:38:26 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <57337BA5.8050801@cisco.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="T9FRufwrjm9BbeObj0Lujg9A8scmO2wXq"
Archived-At: 
Subject: Re: [Spasm] proposed work item
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 11 May 2016 18:38:41 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--T9FRufwrjm9BbeObj0Lujg9A8scmO2wXq
Content-Type: multipart/mixed; boundary="hn4jsFATGjrE00Wjk4p8dbnBPUR5OHO3P"
From: Stephen Farrell 
To: Eliot Lear , spasm@ietf.org
Message-ID: <57337C22.70307@cs.tcd.ie>
Subject: Re: [Spasm] proposed work item
References: <571795E5.6080008@cisco.com> <5733780E.6010209@cs.tcd.ie>
 <57337BA5.8050801@cisco.com>
In-Reply-To: <57337BA5.8050801@cisco.com>

--hn4jsFATGjrE00Wjk4p8dbnBPUR5OHO3P
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



On 11/05/16 19:36, Eliot Lear wrote:
> Hi Stephen,
>=20
> I'm withdrawing the suggestion.  I'll be consolidating the drafts a bit=

> and expect the work to continue elsewhere.

Fair enough and thanks, that probably makes sense.
S.

>=20
> Eliot
>=20
> On 5/11/16 8:21 PM, Stephen Farrell wrote:
>> Hi all,
>>
>> On 20/04/16 15:44, Eliot Lear wrote:
>>> Hi everyone,
>>>
>>> At least for the moment, I'd like to propose a work item that was lis=
ted
>>> in Stephen's original note, I believe, which is
>>> draft-lear-ietf-pkix-mud-extension.  I say, =E2=80=9Cat least for the=
 moment=E2=80=9D
>>> because we may want to consolidate MUD work elsewhere later.  I think=

>>> the ADs will want to talk about that at some point.
>> Does anyone else support pursuing the relevant part of MUD in the
>> proposed spasm wg?
>>
>> Thanks,
>> S.
>>
>>> Eliot
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>=20
>=20


--hn4jsFATGjrE00Wjk4p8dbnBPUR5OHO3P--

--T9FRufwrjm9BbeObj0Lujg9A8scmO2wXq
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJXM3wiAAoJEC88hzaAX42iXrcH/Apx7F1B02Bc6Ovz9LsdcBun
5JYDO0KXlKGTx8FCBFwu5SpVZlPxQZMDY3b8ze0UYNDCmxH8fx6IIUTLy7PR7sVs
qaFb6vWp1NyceZLl/4Ago46ddVjkOfls64UONzplPyJR8AV7sxxrRp1Ne6G3tOv8
AOjT8+yuHR8cZ3vrzEXWLFWFCDpjSM9pU1RWhQx24HBE0yBmaoW6wUUlCtTZQ25v
EHRlZTtV5ir6uUT9yuRgxsoeaxlJpoYLc7nDxM5oc91H+j5WHla3yfg9YjH3uaTp
LmpYG6Ccj0mAto1Iu/xmoVnbFjk4+5Vdq0EcZTJLnksOWEW0w4zofYrv3WPqlBk=
=H34l
-----END PGP SIGNATURE-----

--T9FRufwrjm9BbeObj0Lujg9A8scmO2wXq--


From nobody Wed May 11 13:06:55 2016
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 5252512D808 for ; Wed, 11 May 2016 13:06:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.297
X-Spam-Level: 
X-Spam-Status: No, score=-5.297 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.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id de_DZOHCOKop for ; Wed, 11 May 2016 13:06:50 -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 C00E212D800 for ; Wed, 11 May 2016 13:06:50 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 0C113BE33; Wed, 11 May 2016 21:06:49 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p8ZUwpi0NcRY; Wed, 11 May 2016 21:06:47 +0100 (IST)
Received: from [172.20.10.8] (unknown [172.56.3.38]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 9E754BE2D; Wed, 11 May 2016 21:06:46 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1462997207; bh=dNikIH2phTge2qvDjXyaQHVB0MC734fiFgTfDBfanLQ=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=0moQFcr5LeN3VFey4XWifdxK95ASiTDziWZNWEzOIZWWrWs2NB745K1+YUsUx36d9 jfz5gNyPYSwNMPo1G7OTi8sYfSTPCeIXFDzCOHfGUMhYFWJyUpWgxGYfUf1WAn8wtW JaWgdZRDI1ApLcX8LN9tom+BiA+SI4w+m3BhywGE=
To: Wei Chuang 
References: <20160421141229.21655.qmail@ary.lan> <573379F9.9000105@cs.tcd.ie> 
From: Stephen Farrell 
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <573390D4.5030809@cs.tcd.ie>
Date: Wed, 11 May 2016 21:06:44 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms080709080900070503040106"
Archived-At: 
Cc: spasm@ietf.org
Subject: Re: [Spasm] DRAFT charter text
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 11 May 2016 20:06:53 -0000

This is a cryptographically signed message in MIME format.

--------------ms080709080900070503040106
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



On 11/05/16 19:34, Wei Chuang wrote:
> I think bhjl-x509-srv-00 is useful, and believe spasm is the right plac=
e to
> work on it.

Thanks. So as a follow on - can anyone say that they'd
implement and deploy a non-toy example of this proposed
service? (I mean the ultimate RFC if the WG processed it,
which could look quite different from the -00.)

Cheers,
S.

>=20
> -Wei
>=20
> On Wed, May 11, 2016 at 11:29 AM, Stephen Farrell > wrote:
>=20
>>
>>
>> On 21/04/16 15:12, John Levine wrote:
>>>> Now, we are discussing the draft charter
>>>
>>> If there's room, I'd like to work on S/MIME and PGP key distribution
>>> as in draft-bhjl-x509-srv-00.  I realize the desire to keep the list
>>> of drafts short, but this one is pretty simple, little more than a
>>> profile of RFC 4387.
>>
>> Does anyone else support pursuing work on this draft in the
>> proposed spasm wg?
>>
>> Cheers,
>> S.
>>
>>>
>>> R's,
>>> John
>>>
>>> _______________________________________________
>>> 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
>>
>>
>=20
>=20
>=20
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm
>=20


--------------ms080709080900070503040106
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
CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ
BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD
ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll
bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw
aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA
Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra
C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3
rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5
R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r
dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt
3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw
MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ
QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv
BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5
BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu
Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll
bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc
MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE
MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG
9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD
C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9
U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM
aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai
9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC
BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE
BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs
IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g
QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC
SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC
ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv
mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm
VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4
D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI
dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu
N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE
FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp
MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE
WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG
JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+
SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g
BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv
bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY
0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF
NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9
uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p
6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv
Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu
mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7
RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO
/ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN
JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM
MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG
A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0
Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA
oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA1MTEy
MDA2NDRaMC8GCSqGSIb3DQEJBDEiBCB3xUUG9RxS/rAfVw6k+GdCwwt9vqIjtCmg5vchrCmT
+jBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN
AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC
AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw
IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB
nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD
VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq
hkiG9w0BAQEFAASCAQCXXEIEIwqedDMIJUrdAeJU+CxGfpy8PjoNeBIjOYxqv1UJm1RBo6Uy
7D+w8DR4mpta3nASeHst0fkzozZegYx+uy9NF9bzp1YlwvM/rN4LPut5m3c14XiA41gNazc2
g6OlVoDGIbH9NdXgYhyFkb7DhS26UA9eQRWDkzqqb0hU8lUiCmKSegrmlcYgcODkOifvShGq
9l6XBSynAwLrbsfNdRSgOZ01yZmh1QsCrhyaslFu6evLlKH4vI0+MZo1Q+rS3xo2c1aftWEc
Lo45FXUefIBHRZ/+UTa47UdoDLfbCWl/S6otsku8sgbTvWKOcP8W+iriNHsuFHVfAkI7xIc1
AAAAAAAA
--------------ms080709080900070503040106--


From nobody Wed May 11 13:14:51 2016
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 D281812D5C4 for ; Wed, 11 May 2016 13:14:49 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1KiUBf1D1le5 for ; Wed, 11 May 2016 13:14:48 -0700 (PDT)
Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD7FA12D57F for ; Wed, 11 May 2016 13:14:47 -0700 (PDT)
Received: (qmail 98819 invoked from network); 11 May 2016 20:14:48 -0000
Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 11 May 2016 20:14:48 -0000
Date: 11 May 2016 20:14:24 -0000
Message-ID: <20160511201424.17927.qmail@ary.lan>
From: "John Levine" 
To: spasm@ietf.org
In-Reply-To: <573390D4.5030809@cs.tcd.ie>
Organization: 
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 8bit
Archived-At: 
Cc: stephen.farrell@cs.tcd.ie
Subject: Re: [Spasm] DRAFT charter text
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 11 May 2016 20:14:51 -0000

>> I think bhjl-x509-srv-00 is useful, and believe spasm is the right place to
>> work on it.
>
>Thanks. So as a follow on - can anyone say that they'd
>implement and deploy a non-toy example of this proposed
>service? (I mean the ultimate RFC if the WG processed it,
>which could look quite different from the -00.)

How big does non-toy have to be?

R's,
John

PS: I'm not snarking, I'm trying to figure out who I'd have to recruit.


From nobody Wed May 11 13:28:58 2016
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 4DEDA12B04B for ; Wed, 11 May 2016 13:28:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.297
X-Spam-Level: 
X-Spam-Status: No, score=-5.297 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.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hte2sYcPB7oD for ; Wed, 11 May 2016 13:28:55 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED35912D7FA for ; Wed, 11 May 2016 13:28:54 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id B8B8ABE3E; Wed, 11 May 2016 21:28:53 +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 3EEqz8WeOLFL; Wed, 11 May 2016 21:28:52 +0100 (IST)
Received: from [172.20.10.8] (unknown [172.56.3.38]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 2E609BE38; Wed, 11 May 2016 21:28:50 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1462998532; bh=85NZCAg4tO0eEK0Ptofwt4hHxyLfSKNGbVs68VCFhGo=; h=Subject:To:References:From:Date:In-Reply-To:From; b=Pz7ljagph5ehnftE7CU33LcXszibtQRi7DwKA8Un0VakM5oYw/KVBKT/4qrRQwPQc LoTJECx3Md89isUQ76S9kziJhLhUY+pZVGWVU8QMAhf7qkpXXk5rPnJTIUEYTV1JyX fb7J0J2VMFz5HgYBuqcVW50s94VU9EaEUCJ5cfAM=
To: John Levine , spasm@ietf.org
References: <20160511201424.17927.qmail@ary.lan>
From: Stephen Farrell 
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <57339601.1070209@cs.tcd.ie>
Date: Wed, 11 May 2016 21:28:49 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <20160511201424.17927.qmail@ary.lan>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms060008020909080201060900"
Archived-At: 
Subject: Re: [Spasm] DRAFT charter text
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 11 May 2016 20:28:57 -0000

This is a cryptographically signed message in MIME format.

--------------ms060008020909080201060900
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



On 11/05/16 21:14, John Levine wrote:
>>> I think bhjl-x509-srv-00 is useful, and believe spasm is the right pl=
ace to
>>> work on it.
>>
>> Thanks. So as a follow on - can anyone say that they'd
>> implement and deploy a non-toy example of this proposed
>> service? (I mean the ultimate RFC if the WG processed it,
>> which could look quite different from the -00.)
>=20
> How big does non-toy have to be?

Good and fair question without a very good answer I guess.

Would it be fair to say that a non-toy service would be
one that could scale to a reasonable subset of the set of
folks who use smime or pgp? I'm very open to a better
characterisation of that.

(To be clear - I'm mostly interested in trying to ensure
we don't spend folks' time defining stuff that'll not get
used.)

Cheers,
S.


>=20
> R's,
> John
>=20
> PS: I'm not snarking, I'm trying to figure out who I'd have to recruit.=

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


--------------ms060008020909080201060900
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
CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ
BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD
ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll
bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw
aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA
Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra
C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3
rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5
R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r
dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt
3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw
MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ
QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv
BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5
BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu
Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll
bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc
MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE
MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG
9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD
C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9
U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM
aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai
9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC
BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE
BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs
IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g
QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC
SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC
ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv
mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm
VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4
D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI
dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu
N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE
FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp
MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE
WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG
JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+
SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g
BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv
bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY
0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF
NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9
uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p
6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv
Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu
mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7
RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO
/ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN
JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM
MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG
A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0
Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA
oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA1MTEy
MDI4NDlaMC8GCSqGSIb3DQEJBDEiBCBRwnnwTV69pwwIVIF3qciSae1vPJGeulqO3+Gkli30
pDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN
AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC
AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw
IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB
nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD
VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq
hkiG9w0BAQEFAASCAQBzbtYtyWcWAMPR8mfqG4a/zVwd6/WKgEJVTN2ivE+khTNS04MYjvi7
LU4c3sIa3Mpc8w8gi592q+4qYp29im+wVHiC7s/hrgl9nGJ3ULx/N9PvD/lnk36g2J2CaxoO
sEeXxtHifrwiKLr7CVPz3UdCrGINUUKZyK9tutxPC7GOStlB9XA8yEQLpEnJgivqY7yyAUlt
0K+lCXtpWhEy4pY/2L8zhtywvPCa7oeCitTNRutxNE65xNGkTmKGYvBehccbDV4y9rYKDj2n
VBnxs/k7b7LVEp3T+wNPnymigrA93CHH4THs8oljL0jgIq+qs37aRV3kvpbkn1CO/KB9KETj
AAAAAAAA
--------------ms060008020909080201060900--


From nobody Wed May 11 13:37:37 2016
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 2821F12D824 for ; Wed, 11 May 2016 13:37:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.62
X-Spam-Level: 
X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-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 lFtfSGV8MBKY for ; Wed, 11 May 2016 13:37:34 -0700 (PDT)
Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99E9412D5F5 for ; Wed, 11 May 2016 13:37:11 -0700 (PDT)
Received: from hebrews (c-24-21-96-37.hsd1.or.comcast.net [24.21.96.37]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id C16B92CA22 for ; Wed, 11 May 2016 13:37:10 -0700 (PDT)
From: "Jim Schaad" 
To: 
References: <571795E5.6080008@cisco.com> <5733780E.6010209@cs.tcd.ie>
In-Reply-To: <5733780E.6010209@cs.tcd.ie>
Date: Wed, 11 May 2016 13:37:09 -0700
Message-ID: <02a001d1abc4$e4a8c320$adfa4960$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQFMLJsKNpnsQTU0Ff96nrU+G9vdwAGiuYe4oLIarZA=
Content-Language: en-us
Archived-At: 
Subject: Re: [Spasm] proposed work item
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 11 May 2016 20:37:36 -0000

At the moment it seems both harmless and not very interesting.

Jim


-----Original Message-----
From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Stephen Farrell
Sent: Wednesday, May 11, 2016 11:21 AM
To: spasm@ietf.org
Subject: Re: [Spasm] proposed work item


Hi all,

On 20/04/16 15:44, Eliot Lear wrote:
> Hi everyone,
>=20
> At least for the moment, I'd like to propose a work item that was=20
> listed in Stephen's original note, I believe, which is=20
> draft-lear-ietf-pkix-mud-extension.  I say, =E2=80=9Cat least for the =
moment=E2=80=9D
> because we may want to consolidate MUD work elsewhere later.  I think=20
> the ADs will want to talk about that at some point.

Does anyone else support pursuing the relevant part of MUD in the =
proposed spasm wg?

Thanks,
S.

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



From nobody Wed May 11 13:44:33 2016
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 E75F212D5EF for ; Wed, 11 May 2016 13:44:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5DsLunoBG_hD for ; Wed, 11 May 2016 13:44:30 -0700 (PDT)
Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B04812D7FE for ; Wed, 11 May 2016 13:44:30 -0700 (PDT)
Received: from hebrews (c-24-21-96-37.hsd1.or.comcast.net [24.21.96.37]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id E244438F33; Wed, 11 May 2016 13:44:29 -0700 (PDT)
From: "Jim Schaad" 
To: "'Stephen Farrell'" , 
References: <20160421141229.21655.qmail@ary.lan> <573379F9.9000105@cs.tcd.ie>
In-Reply-To: <573379F9.9000105@cs.tcd.ie>
Date: Wed, 11 May 2016 13:44:29 -0700
Message-ID: <02a101d1abc5$ea73a710$bf5af530$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQH6F8LRQuiNcEcNiBqKOhtCyrP57AGzkT73n1W/QLA=
Content-Language: en-us
Archived-At: 
Subject: Re: [Spasm] DRAFT charter text
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 11 May 2016 20:44:32 -0000

I worry that this is an end-run around the work being done in the DANE =
group.

Personally, I like this approach much better than the one being pursued =
by the DANE group.  There are details that I do  not like, but that is =
what WG eyes are for.

I would be more than willing to do this as an experimental document.  I =
would not be willing to do this as a standards track document.

Jim


-----Original Message-----
From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Stephen Farrell
Sent: Wednesday, May 11, 2016 11:29 AM
To: spasm@ietf.org
Subject: Re: [Spasm] DRAFT charter text



On 21/04/16 15:12, John Levine wrote:
>> Now, we are discussing the draft charter
>=20
> If there's room, I'd like to work on S/MIME and PGP key distribution=20
> as in draft-bhjl-x509-srv-00.  I realize the desire to keep the list=20
> of drafts short, but this one is pretty simple, little more than a=20
> profile of RFC 4387.

Does anyone else support pursuing work on this draft in the proposed =
spasm wg?

Cheers,
S.

>=20
> R's,
> John
>=20
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm
>=20



From nobody Wed May 11 13:55:34 2016
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 A690812D5B2 for ; Wed, 11 May 2016 13:55:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.297
X-Spam-Level: 
X-Spam-Status: No, score=-5.297 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.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hGqnZbaZNQ5g for ; Wed, 11 May 2016 13:55:31 -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 CE5BA12D50B for ; Wed, 11 May 2016 13:55:29 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 1CF51BE33; Wed, 11 May 2016 21:55:28 +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 VDokEkc-7kSp; Wed, 11 May 2016 21:55:26 +0100 (IST)
Received: from [172.20.10.8] (unknown [172.56.3.38]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 0C2BCBE2D; Wed, 11 May 2016 21:55:24 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1463000126; bh=EdWZ80XkdNW7IopBHXszXyv5CNnA2No0Sr1w+cSFClI=; h=Subject:To:References:From:Date:In-Reply-To:From; b=BC9L5RY/SKwusnEqluR47FJWJa+vNcQNEuQi5oLHFwuX9AWmbejt+AHNjMBEaoayA wVfP2f9oFrml1vuFpRSwxSzsFfHE1hfsYVnlY0pFqXyjwU1L/SdmQ/TJnjoRY6Gmbo 3XnVDERb1JwRko6s9RAubndUUgbclwpox3bjNHss=
To: Jim Schaad , spasm@ietf.org
References: <20160421141229.21655.qmail@ary.lan> <573379F9.9000105@cs.tcd.ie> <02a101d1abc5$ea73a710$bf5af530$@augustcellars.com>
From: Stephen Farrell 
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <57339C3A.1020908@cs.tcd.ie>
Date: Wed, 11 May 2016 21:55:22 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <02a101d1abc5$ea73a710$bf5af530$@augustcellars.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000806080007070301050106"
Archived-At: 
Subject: Re: [Spasm] DRAFT charter text
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 11 May 2016 20:55:34 -0000

This is a cryptographically signed message in MIME format.

--------------ms000806080007070301050106
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



On 11/05/16 21:44, Jim Schaad wrote:
> I worry that this is an end-run around the work being done in the
> DANE group.

end-run seems overstated to me.

>=20
> Personally, I like this approach much better than the one being
> pursued by the DANE group.  There are details that I do  not like,
> but that is what WG eyes are for.
>=20
> I would be more than willing to do this as an experimental document.
> I would not be willing to do this as a standards track document.

I tend to agree that'd be a very reasonable approach and matches
what we did in DANE.

S

>=20
> Jim
>=20
>=20
> -----Original Message----- From: Spasm
> [mailto:spasm-bounces@ietf.org] On Behalf Of Stephen Farrell Sent:
> Wednesday, May 11, 2016 11:29 AM To: spasm@ietf.org Subject: Re:
> [Spasm] DRAFT charter text
>=20
>=20
>=20
> On 21/04/16 15:12, John Levine wrote:
>>> Now, we are discussing the draft charter
>>=20
>> If there's room, I'd like to work on S/MIME and PGP key
>> distribution as in draft-bhjl-x509-srv-00.  I realize the desire to
>> keep the list of drafts short, but this one is pretty simple,
>> little more than a profile of RFC 4387.
>=20
> Does anyone else support pursuing work on this draft in the proposed
> spasm wg?
>=20
> Cheers, S.
>=20
>>=20
>> R's, John
>>=20
>> _______________________________________________ Spasm mailing list=20
>> Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm
>>=20
>=20
>=20
> _______________________________________________ Spasm mailing list=20
> Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm
>=20


--------------ms000806080007070301050106
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
CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ
BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD
ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll
bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw
aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA
Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra
C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3
rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5
R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r
dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt
3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw
MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ
QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv
BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5
BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu
Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll
bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc
MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE
MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG
9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD
C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9
U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM
aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai
9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC
BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE
BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs
IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g
QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC
SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC
ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv
mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm
VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4
D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI
dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu
N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE
FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp
MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE
WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG
JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+
SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g
BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv
bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY
0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF
NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9
uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p
6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv
Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu
mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7
RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO
/ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN
JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM
MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG
A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0
Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA
oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA1MTEy
MDU1MjJaMC8GCSqGSIb3DQEJBDEiBCDHbDmTbx8TLfKGHYsvo52SN4SNYNF1sLIrheR3JLSn
ZDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN
AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC
AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw
IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB
nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD
VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq
hkiG9w0BAQEFAASCAQA0jBtX+BcO/WmrgqU0ZuPUSLZZB3y1m1fY3jeDhG2oHEq1DTXOAUek
/5T/kv46pYsgYcCCZmQIyf8ySrD4a7aQ9aS+LOXp7Wk32muyiZw2ifYNLZ1jhYQQuV5l/WR5
25f7tV/DwxfsXn7MH+LcCc7Uw5kZf3xeV1yLO7myaWYjoofK28R8UZOVB7B4SNcWLvrF1g6c
RZCmsRDJqdd0fdXZLudnyZqhpAolw7Z6xedVSnYqs3lpjjlLtN5WGexC1s64QiJ4oPQRAtSa
YVgyu4EPsvJwRbkl9OlNdufc39qvw/v9zZl5IlJXXrZRyNDe+Yf2uN+phXS0X3WkZZPlq59a
AAAAAAAA
--------------ms000806080007070301050106--


From nobody Wed May 11 14:20:50 2016
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 22AD512D141 for ; Wed, 11 May 2016 14:20:49 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AAeo2abmHI72 for ; Wed, 11 May 2016 14:20:47 -0700 (PDT)
Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57F5912B03C for ; Wed, 11 May 2016 14:20:47 -0700 (PDT)
Received: (qmail 21861 invoked from network); 11 May 2016 21:20:47 -0000
Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 11 May 2016 21:20:47 -0000
Date: 11 May 2016 21:20:24 -0000
Message-ID: <20160511212024.18121.qmail@ary.lan>
From: "John Levine" 
To: spasm@ietf.org
In-Reply-To: <02a101d1abc5$ea73a710$bf5af530$@augustcellars.com>
Organization: 
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 8bit
Archived-At: 
Cc: ietf@augustcellars.com
Subject: Re: [Spasm] DRAFT charter text
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 11 May 2016 21:20:49 -0000

In article <02a101d1abc5$ea73a710$bf5af530$@augustcellars.com> you write:
>I worry that this is an end-run around the work being done in the DANE group.

I'd say it's more an exasperated response than an end-run.  The
openpgpkey draft is experimental, and I think it is fair to say that
it has very little support from the SMTP mail community.

>I would be more than willing to do this as an experimental document.  I would not be willing to do this as a standards
>track document.

About 95% of it is from RFC 4387 which has been on the standards track
for a decade.  I tried to make it clear that this is just a key
distribution scheme, not a way to assert that these are "real" keys
unless a domain uses DANE to explicitly publish its S/MIME signing key.

I don't understand what the experiment would be.

R's,
JOhn



From nobody Wed May 11 14:41:18 2016
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 D5DB912D5CD for ; Wed, 11 May 2016 14:41:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.897
X-Spam-Level: 
X-Spam-Status: No, score=-2.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LTrOIAiNRTI9 for ; Wed, 11 May 2016 14:41:14 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A10E112D1B3 for ; Wed, 11 May 2016 14:41:14 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 4FA2A200A5; Wed, 11 May 2016 17:46:48 -0400 (EDT)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id C9CFA63755; Wed, 11 May 2016 17:41:13 -0400 (EDT)
From: Michael Richardson 
To: "John Levine" 
In-Reply-To: <20160511201424.17927.qmail@ary.lan>
References: <20160511201424.17927.qmail@ary.lan>
X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.4.2
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m
Archived-At: 
Cc: spasm@ietf.org, stephen.farrell@cs.tcd.ie
Subject: Re: [Spasm] DRAFT charter text
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 11 May 2016 21:41:17 -0000

--=-=-=
Content-Type: text/plain


John Levine  wrote:
    >>> I think bhjl-x509-srv-00 is useful, and believe spasm is the right place to
    >>> work on it.
    >>
    >> Thanks. So as a follow on - can anyone say that they'd
    >> implement and deploy a non-toy example of this proposed
    >> service? (I mean the ultimate RFC if the WG processed it,
    >> which could look quite different from the -00.)

    > How big does non-toy have to be?

    > R's,
    > John

    > PS: I'm not snarking, I'm trying to figure out who I'd have to recruit.

On the side of doing this in MUAs, one of:
   gmail, thunderbird, outlook

On the side of doing this in MTAs (encrypting to destination, not signing,
I'm unclear if that is in scope), one of:
   sendmail.org,
   postfix.org,
   MS-Exchange
   Zimbra
   Might interest: https://www.roaringpenguin.com/products/canit-secure-messaging




--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-




--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEVAwUBVzOm94CLcPvd0N1lAQJO+gf+LQYIYtegxwN4jkBft4lpefSacMdyLQKN
8eX3OWgvqHgMBbBSOB6i5YWwpHwHvzVrWGuSeVpokbkx3d7kFOBDENbryX/HyjLC
vou/m+K0oyfJwg/DNHjVpL2IWR8SLXUp9SikXRwQIVifRh63/ObGsAt0lwvlItMA
kq8VEOY2sy0x5JbBUGNKT7LBVnAT5ih9WJJqnpdUld7MvGjbgeAQHgin5i3JCOKZ
eCNf8H1+3a1dMkp4kmBeU9w4kthAmlPpL3da0itCuNoP8yZT2MKdYlFAgk8OyIvV
FFPDd6wierBNvcF+oGYqIPn9CF5IPPQG9iBLuJQBo0+VrEs4zW30mg==
=iRDC
-----END PGP SIGNATURE-----
--=-=-=--


From nobody Wed May 11 15:04:14 2016
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 2231C12D716 for ; Wed, 11 May 2016 15:04:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WTXouBPODeWb for ; Wed, 11 May 2016 15:04:03 -0700 (PDT)
Received: from mail-wm0-x241.google.com (mail-wm0-x241.google.com [IPv6:2a00:1450:400c:c09::241]) (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 25ECB12D807 for ; Wed, 11 May 2016 15:04:03 -0700 (PDT)
Received: by mail-wm0-x241.google.com with SMTP id e201so12118720wme.2 for ; Wed, 11 May 2016 15:04:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=WntTqvg9rXknC5Pu0RQNXUWrJ3Lz6uQOPkCsU/JnS0o=; b=AdIkrvVx/h53dtCSNIWeUPg38TEFtKaFc7L5ZJ2d7NrhKkZtCzi6lcezM9Fms6rTZ1 poosI9wHEqT5Yb3k3E2e/0ShYJeNvEFpYyhl4nYzh+Yy581q9llvZuJ/gxqw1VesEUWn ECVXCgxFl1HwyyrdButiw3uFJsGANDvLDF8sLDbqgZCJ0hPUNb/FC0qxPKwMfah9mpRY GiIvElpZGNV3hKahf51NBnrONax45l2BrwBjXGv3JYNgDbLwakowWX34YQrg+tD1GJ+b 2CgMj99kvV2oemu4158tzPFLz9k74pU0NSsDwh0TQJZHMYjdHc9kzA70TndDuJk8O6rw WrNA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=WntTqvg9rXknC5Pu0RQNXUWrJ3Lz6uQOPkCsU/JnS0o=; b=M5yTGErdg21ZSgnM2kiDta5Od7QJZfv1EyJ+v4qM0RnioxlfV/ChYYYN5Vpx7cbJoM u0GQCH7K9Zb64jlG1VQERwHeoyyNKiNFQRDbJAtNoELqHlLGqj7WJoiNWLpBI3aSofj/ hucPe/SreTRxE8kT4efec3vYiysE4vjl6CO55VMjMFg9ZwMaA4oPFIRlMdQ5DmqM/URT WcfIKPdcNZ4mNOAPBAt2IpMu6xaqg1GJB92bUMSgBoO6+kz90UONngf8mn2rRgi5Hb8z FwyYXm9QtZbxnTkDJUjLEXcxLR0HcVZpmcf0MA2TVgAUD8YeV3auor3xZdmnWfYeF+tI Gv7A==
X-Gm-Message-State: AOPr4FUd0yKeRTNP5Pj8Z7HjJiweuc4xc58GQOj3p5uzDxguVbOinjPDf6PbFGnsJYen0g==
X-Received: by 10.194.104.228 with SMTP id gh4mr5948825wjb.134.1463004241610;  Wed, 11 May 2016 15:04:01 -0700 (PDT)
Received: from [192.168.1.12] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id c16sm10488007wme.16.2016.05.11.15.03.59 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 11 May 2016 15:04:00 -0700 (PDT)
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: multipart/signed; boundary="Apple-Mail=_C39DECE8-56EE-43FB-A676-130B9A44D32C"; protocol="application/pgp-signature"; micalg=pgp-sha256
X-Pgp-Agent: GPGMail 2.6b2
From: Yoav Nir 
In-Reply-To: <13009.1463002873@obiwan.sandelman.ca>
Date: Thu, 12 May 2016 01:03:56 +0300
Message-Id: 
References: <20160511201424.17927.qmail@ary.lan> <13009.1463002873@obiwan.sandelman.ca>
To: Michael Richardson 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: spasm@ietf.org, John Levine , stephen.farrell@cs.tcd.ie
Subject: Re: [Spasm] DRAFT charter text
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 11 May 2016 22:04:12 -0000

--Apple-Mail=_C39DECE8-56EE-43FB-A676-130B9A44D32C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi, Michael

> On 12 May 2016, at 12:41 AM, Michael Richardson =
 wrote:
>=20
>=20
>=20
>> How big does non-toy have to be?
>=20
>> R's,
>> John
>=20
>> PS: I'm not snarking, I'm trying to figure out who I'd have to =
recruit.
>=20
> On the side of doing this in MUAs, one of:
>   gmail, thunderbird, outlook
>=20
> On the side of doing this in MTAs (encrypting to destination, not =
signing,
> I'm unclear if that is in scope), one of:
>   sendmail.org,
>   postfix.org,
>   MS-Exchange
>   Zimbra
>   Might interest: =
https://www.roaringpenguin.com/products/canit-secure-messaging

Not saying I=E2=80=99m against this, but this looks like rather a high =
bar.

--Apple-Mail=_C39DECE8-56EE-43FB-A676-130B9A44D32C
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----

iQEcBAEBCAAGBQJXM6xNAAoJECXR4BOacZZUWsgH/2sRuydPYgb3G5dnKOWLE/Em
BKUdNNgrDRS/Ddf9aVM87KBPx1Lnoh+Bb03PIkPv/RJikcOAoqNSPVkxiRtPbBDY
aBvtN31PtpgtPdx7jZahR8oaVMZTNr5zelAZYtWl+wWsxdUEGZ5Pzq5ANmYXWa+T
sT2Jm6OlzAfmvxUV9JOlD0wXmhXjhbzXKMOrALBnaZrhBIo0kTBHL0gXGHYTWrAr
mfBjMPrmhKHHtq4drKV8plRniil+TdVGgjOALvNkPZVl0oUHNIZtysZYWdvLyKNc
hueIR2LD5tThcSZm7f5vGhX7CJ3q9cS/s28STF9ohDCvyMj7n+6egvcLu+GtG5Y=
=cNmI
-----END PGP SIGNATURE-----

--Apple-Mail=_C39DECE8-56EE-43FB-A676-130B9A44D32C--


From nobody Wed May 11 15:33:42 2016
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 E398C12D18B for ; Wed, 11 May 2016 15:33:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KJhWjO27uT5S for ; Wed, 11 May 2016 15:33:38 -0700 (PDT)
Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E6E912B049 for ; Wed, 11 May 2016 15:33:37 -0700 (PDT)
Received: from hebrews (c-24-21-96-37.hsd1.or.comcast.net [24.21.96.37]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 123D42CA2C; Wed, 11 May 2016 15:33:37 -0700 (PDT)
From: "Jim Schaad" 
To: "'John Levine'" , 
References: <02a101d1abc5$ea73a710$bf5af530$@augustcellars.com> <20160511212024.18121.qmail@ary.lan>
In-Reply-To: <20160511212024.18121.qmail@ary.lan>
Date: Wed, 11 May 2016 15:33:34 -0700
Message-ID: <02c601d1abd5$28d31180$7a793480$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQIQ3FrDcLMAqFWDRWYPzNRgiTju+Z817rrg
Content-Language: en-us
Archived-At: 
Subject: Re: [Spasm] DRAFT charter text
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 11 May 2016 22:33:41 -0000

I think that the experiment is can you get some major mail clients to
implement and can you get some major companies to provide the service.  

I know of clients that implement ldap lookup and it is used internally in
companies, but companies do not expose their ldap servers to the world for a
number of valid reasons.  This is a more restricted query than ldap but it
is still a question of are people going to allow for exposure of the
interface or not.

I would not want to see it advance from experimental to standards track
without some show of adoption.

Jim



-----Original Message-----
From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of John Levine
Sent: Wednesday, May 11, 2016 2:20 PM
To: spasm@ietf.org
Cc: ietf@augustcellars.com
Subject: Re: [Spasm] DRAFT charter text

In article <02a101d1abc5$ea73a710$bf5af530$@augustcellars.com> you write:
>I worry that this is an end-run around the work being done in the DANE
group.

I'd say it's more an exasperated response than an end-run.  The openpgpkey
draft is experimental, and I think it is fair to say that it has very little
support from the SMTP mail community.

>I would be more than willing to do this as an experimental document.  I 
>would not be willing to do this as a standards track document.

About 95% of it is from RFC 4387 which has been on the standards track for a
decade.  I tried to make it clear that this is just a key distribution
scheme, not a way to assert that these are "real" keys unless a domain uses
DANE to explicitly publish its S/MIME signing key.

I don't understand what the experiment would be.

R's,
JOhn


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


From nobody Wed May 11 16:28:54 2016
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 65D6612D1A7 for ; Wed, 11 May 2016 16:28:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.897
X-Spam-Level: 
X-Spam-Status: No, score=-2.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fS9taZVMmQR5 for ; Wed, 11 May 2016 16:28:51 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4948312D141 for ; Wed, 11 May 2016 16:28:50 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id A0718200A5 for ; Wed, 11 May 2016 19:34:24 -0400 (EDT)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id CF5EF63755 for ; Wed, 11 May 2016 19:28:49 -0400 (EDT)
From: Michael Richardson 
To: spasm@ietf.org
In-Reply-To: 
References: <20160511201424.17927.qmail@ary.lan> <13009.1463002873@obiwan.sandelman.ca> 
X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.4.2
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m
Archived-At: 
Subject: Re: [Spasm] DRAFT charter text
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 11 May 2016 23:28:53 -0000

--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


Yoav Nir  wrote:
    > Hi, Michael

    >> On the side of doing this in MUAs, one of:
    >> gmail, thunderbird, outlook
    >>
    >> On the side of doing this in MTAs (encrypting to destination, not si=
gning,
    >> I'm unclear if that is in scope), one of:
    >> sendmail.org,
    >> postfix.org,
    >> MS-Exchange
    >> Zimbra
    >> Might interest: https://www.roaringpenguin.com/products/canit-secure=
-messaging

    > Not saying I=E2=80=99m against this, but this looks like rather a hig=
h bar.

And thus the reason encrypted email continues to fail to take off...

=2D-
Michael Richardson , Sandelman Software Works
 -=3D IPv6 IoT consulting =3D-




--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEVAwUBVzPALoCLcPvd0N1lAQKhCggAn4ySXtUnZUJbHWQEFI0zgkTQ8h7/jt2e
VTnfMs3/VwVXd4qHii6IbVIJJPfQUR+nCJ2kzHI1HPk+u79/M8bWthyPWX73LViW
i/Gm1ZVTw3oA8FFdnbRWYW+lFERyVBSXWuFqid68vxzFJlYBskicqECWXk7c51p+
zDW5zWoh73jKEbpmvRsyn7dby982S5IuCmf7kNPoNpJtLnfJE+XpFwdsjGuaDykR
yG330HjV3KsL3N52vvmPLER453iMUZeodb7s/hJ9ma+MSiD4/QEe+EdBmmZl3KNP
k6eDekqSMcWDoXkasXTXSBZwgZFTmPGyZNNcn7Tv5u+ltJjq8oHsCg==
=3ZGn
-----END PGP SIGNATURE-----
--=-=-=--


From nobody Wed May 11 19:48:27 2016
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 CB44712D842 for ; Wed, 11 May 2016 19:48:25 -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 (1536-bit key) header.d=iecc.com header.b=pnvAOsY/; dkim=pass (1536-bit key) header.d=taugh.com header.b=elMwUEr0
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 ZuQ_s7uhMEO2 for ; Wed, 11 May 2016 19:48:24 -0700 (PDT)
Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B354912D177 for ; Wed, 11 May 2016 19:48:23 -0700 (PDT)
Received: (qmail 98301 invoked from network); 12 May 2016 02:48:24 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=17ffc.5733eef8.k1605; bh=Fu28Ez73ntN7YIW4xRxaCEflWx2uDMXmsPSCIOgeNN4=; b=pnvAOsY//a6HbNEHfccgplw6R2E1CXrGMCcSDYK1Ss1O8sGmr/PDMGn4Og9DBM+TURqCKw1KOfhVa21nHA4a10C+aB2YJc4lE87Q1roHXCTQHRdip/aXxehOPV7mvUFQ9MWuI3nQ8WGoKM1kYDMsONnaf0019gH90u78n3aD+zlHV6lbJlPsADUXRwuq8+k6+QOHsegfObeu2zD8VneG7aFVzCAgpZm1Cr/BqC3LZtfPHDlVD8FMxKu9OunyzmQj
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=17ffc.5733eef8.k1605; bh=Fu28Ez73ntN7YIW4xRxaCEflWx2uDMXmsPSCIOgeNN4=; b=elMwUEr0okY+wT1Qtx7pCiDYKfdOl9Bglaqlvmj2RYPI+XhoI9rgI8ljlOJQOXXBPSJd8oxQfPeEYaMdlt5/EULhnnE/kUpubhDFoGtd6Hmzm+BH8AOnohsuttdurvE1NUKBVk1RIP7+cdx6fp8wSkyprIUUFzVDFwQiyB+eroGQjqC2eTWQDifeTpOOT9So2DzuReggI+/BbdWEm0bzgjPWc9v2O+shGLBX8f3bEaqTB9dvxvHfu6G/A2SVnu3H
Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 12 May 2016 02:48:24 -0000
Date: 11 May 2016 22:48:21 -0400
Message-ID: 
From: "John R Levine" 
To: "Jim Schaad" 
In-Reply-To: <02c601d1abd5$28d31180$7a793480$@augustcellars.com>
References: <02a101d1abc5$ea73a710$bf5af530$@augustcellars.com> <20160511212024.18121.qmail@ary.lan> <02c601d1abd5$28d31180$7a793480$@augustcellars.com>
User-Agent: Alpine 2.11 (OSX 23 2013-08-11)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Archived-At: 
Cc: spasm@ietf.org
Subject: Re: [Spasm] DRAFT charter text
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 12 May 2016 02:48:26 -0000

> I think that the experiment is can you get some major mail clients to
> implement and can you get some major companies to provide the service.

As far as I can tell, that's never been a bar for proposed standard 
before, but I agree it'd be interesting to find out.

I'll be talking to people from a lot of large mail operators at MAAWG next 
month, will see if anyone is interested.

Regards,
John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.


From nobody Thu May 12 15:37:58 2016
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 61CA612D0D9 for ; Thu, 12 May 2016 15:37:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.897
X-Spam-Level: 
X-Spam-Status: No, score=-2.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7idhYHjp8qEP for ; Thu, 12 May 2016 15:37:55 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E090A12B03C for ; Thu, 12 May 2016 15:37:54 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 446A3200A5; Thu, 12 May 2016 18:43:32 -0400 (EDT)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 17D6B638BD; Thu, 12 May 2016 18:37:54 -0400 (EDT)
From: Michael Richardson 
To: "John R Levine" 
In-Reply-To: 
References: <02a101d1abc5$ea73a710$bf5af530$@augustcellars.com> <20160511212024.18121.qmail@ary.lan> <02c601d1abd5$28d31180$7a793480$@augustcellars.com> 
X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.4.2
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m
Archived-At: 
Cc: spasm@ietf.org, Jim Schaad 
Subject: Re: [Spasm] DRAFT charter text
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 12 May 2016 22:37:56 -0000

--=-=-=
Content-Type: text/plain


John R Levine  wrote:
    >> I think that the experiment is can you get some major mail clients to
    >> implement and can you get some major companies to provide the service.

    > As far as I can tell, that's never been a bar for proposed standard before,
    > but I agree it'd be interesting to find out.

True.  The point is more of the: why produce another specification that
nobody will implement?

    > Please consider the environment before reading this e-mail.

Please consider the environment before implementing a new spec.
:-) :-)


--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-




--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEVAwUBVzUFv4CLcPvd0N1lAQJh5QgApoc69OK6NpKWLTG4McFYYRTsJ/HtNh1w
qy5ZHUaWPWo3ECbFRYq5u5b35mkhwxhJSTTHlC+xE79ZKJ4KAC8vFa3CtAxjBlMU
CqPhbOknDpB7n8l4SFwOY2RzhMMcOSbjifFgZzKBwa59iRWNfNEioJnK9H4YmtJ5
iGmZQeIev/+ehKUvV12iTszhG31JVehJb8iSB5lhEKZg6YbTFjrYSSQ6tBXb568/
oes4TK/LTaD4rsc8VKXWF6oeb6Xj3djo47FwY90m/Syx+LRH0RTaiq6OPPptxNJ6
vj04GJnH9xmrXkFLZFNzH2r7F7NROKa0k8F9FzLvrkOyPeapueUqjA==
=COiJ
-----END PGP SIGNATURE-----
--=-=-=--


From nobody Thu May 12 15:52:35 2016
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 9742B12D12A for ; Thu, 12 May 2016 15:52:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Level: 
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t5MfZ6oWO953 for ; Thu, 12 May 2016 15:52:33 -0700 (PDT)
Received: from mail.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 81CB212B020 for ; Thu, 12 May 2016 15:52:33 -0700 (PDT)
Received: from localhost (ronin.smetech.net [209.135.209.5]) by mail.smetech.net (Postfix) with ESMTP id A2137F24013; Thu, 12 May 2016 18:52:33 -0400 (EDT)
X-Virus-Scanned: amavisd-new at smetech.net
Received: from mail.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id ZTs7zR-cPgdW; Thu, 12 May 2016 18:35:29 -0400 (EDT)
Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.smetech.net (Postfix) with ESMTP id 359F6F2402A; Thu, 12 May 2016 18:52:22 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Russ Housley 
In-Reply-To: 
Date: Thu, 12 May 2016 18:52:25 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <52C7FB30-F1D8-4B8D-BE94-3E1EACCB7E86@vigilsec.com>
References: <02a101d1abc5$ea73a710$bf5af530$@augustcellars.com> <20160511212024.18121.qmail@ary.lan> <02c601d1abd5$28d31180$7a793480$@augustcellars.com> 
To: John Levine 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: 
Cc: spasm@ietf.org
Subject: Re: [Spasm] DRAFT charter text
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 12 May 2016 22:52:34 -0000

>> I think that the experiment is can you get some major mail clients to
>> implement and can you get some major companies to provide the =
service.
>=20
> As far as I can tell, that's never been a bar for proposed standard =
before, but I agree it'd be interesting to find out.
>=20
> I'll be talking to people from a lot of large mail operators at MAAWG =
next month, will see if anyone is interested.

Stephen is trying to charter updates to the PKIX and S/MIME =
specifications that will be implemented in this working group.  Stephen =
did not say that other paths to proposed standard would be blocked for =
ideas that could not clear that bar.

Russ


From nobody Fri May 13 12:09:09 2016
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 1239912D1EC for ; Fri, 13 May 2016 12:09:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.696
X-Spam-Level: 
X-Spam-Status: No, score=-3.696 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, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 9YENKPS0lF0b for ; Fri, 13 May 2016 12:09:05 -0700 (PDT)
Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::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 CA65212B04A for ; Fri, 13 May 2016 12:09:04 -0700 (PDT)
Received: by mail-oi0-x22e.google.com with SMTP id k142so185553009oib.1 for ; Fri, 13 May 2016 12:09:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vfsXPxT6K7XSdfQhE23DuMeX6iN9v6ONdbbkSYQQpdQ=; b=mgb9XQDAhLBqVRurim1y3fLuOQLzl95jXO+3PEpPawWgynYFYd6uGgeiDHt5G11Fsx rSGQawrT1IxkVMUSpH4NZjh1XjYeWd50z382u9XXuwtmdpskSWbvMPkXTDtti2dI7aeA NmN5D5/qGPW/s67xXudlJBYywZCFfxYLYBhq0Xf2qTjEIgR+sPTeTZfN2AZ1CQNSVu5r hvGkWfykq+Js7OVmqFNZltB3iqrCRqPUgTjZGFDw4JZ2RpK8EBgtDHtqtHpoTaF5/SK/ X5m7cajOOPJpqD0JiIa/Ze3WlzbCqWAH4hNcyNmM3UUMgxf7x66ddtfBkVYDuexoSt97 C0PA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vfsXPxT6K7XSdfQhE23DuMeX6iN9v6ONdbbkSYQQpdQ=; b=bAwTtIh8D5ghRtM2x9kEZlS86DLaR5C2EeNQmWdMyy8UDuo+P3XVk82L/IG99d9p0r xvSpemzR8iXCcIKxpxKVZJVRIO/lfD9xrcPcvfOtmS5O2TsUv+Swyy5ZhpNwRljh/rqo ikxWpTtkKnSoV9l0txmw1FsZ5KmRDRWT21G99PktTU1xXhyX2fyRwVvSS6KliMpzJkkg ckrjO9xK8GuAI0dyLo6pQMLhTJ7se4XtwofUt6ncQ0IgD/VeuIpqysMJBNghlI/z0tUX Il7+LgEU7Row74ZW5xDh6wy4O79W+sicQMBd1UszlkASxw04z5GFewReu/nXBN0R1dh+ cBvg==
X-Gm-Message-State: AOPr4FW48PIhINhq1cuFzV1/oOuqFeSLdjABRNbbxRlehm0TwEMauUKuFqaDkmRRvsPKmaNzliJ36qlj8drso+5+
X-Received: by 10.202.203.139 with SMTP id b133mr10162053oig.166.1463166543957;  Fri, 13 May 2016 12:09:03 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.157.32.202 with HTTP; Fri, 13 May 2016 12:09:02 -0700 (PDT)
In-Reply-To: <3851E218-C5F4-4BB3-B9DB-B8679361A2B9@seantek.com>
References:      <028101d18f60$dd6262e0$982728a0$@augustcellars.com>  <3851E218-C5F4-4BB3-B9DB-B8679361A2B9@seantek.com>
From: Wei Chuang 
Date: Fri, 13 May 2016 12:09:02 -0700
Message-ID: 
To: Sean Leonard 
Content-Type: multipart/alternative; boundary=001a113501f619f9f50532be024d
Archived-At: 
Cc: spasm@ietf.org, Alexey Melnikov , Jim Schaad , Russ Housley 
Subject: Re: [Spasm] [pkix] [smime] Support for email address internationalization in RFC5280 certificates
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 13 May 2016 19:09:08 -0000

--001a113501f619f9f50532be024d
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

[Restarting and moving this thread to spasm]

Hi all,

I think there's general interest in using draft-ietf-pkix-eai-addresses-00
 to document
supporting EAI local part i.e. to use a new GeneralNames otherNames type
with UTF8 email address local part.  That said, there are some remaining
issues from the previous thread:

On Wed, Apr 6, 2016 at 3:48 PM, Sean Leonard  wrote:

> To be clear, the otherName form (draft-ietf-pkix-eai-addresses-00) is a
> sensible path forward. That is how GeneralName was designed to be extended
> all along.
>
> Russ corrected me offline and pointed out that GeneralName is “owned”
> (well, created originally anyway) by ITU-T X.509. It is not an
> IETF-originated extension.
>

In order to add a new otherName type in GeneralName which appears to be
"owned" by ITU-T, does this then requires coordination with ITU-T?


>
> Any EAI mechanism will have consider the impact of Name Constraints, the
> functionality of which needs to be preserved.
>
> Additionally, the EAI document should say something about whether A-labels
> (i.e., Punycode) or U-labels ought to be used on the domain side. I believe
> that U-labels should be used on the domain side when in the otherName
> UTF8String. There are three solid reasons:
>

The draft very clearly matches RFC5280 pattern of using A-labels (ACE) for
the domain names.  While understandably its more convenient to process the
domain part in UTF8 display format, for validation purposes it would seem
to me to make sense to keep domain name validation consistent with the rest
of the RFC5280 handling to reduce the likelihood of implementation
differences.

I wonder if an update to this draft should say something about mitigating
homograph attacks in the security section?  I think this is an ideal time
to mitigate some of the likely security attacks.   In another thread it was
mentioned that using PRECIS (RFC7564) could help, and following that up the
RFC points  at
Unicode Security Mechanism.  Some ideas are to restrict obsolete or
specialized character set and to restrict the local part to a single script
type e.g. Russian Cyrillic only or ASCII only.

-Wei


> #1 Since it’s UTF8String, it’s simply “more correct” to use U-labels
> instead of A-labels. The requirements of RFC 5280 regarding IDN don’t
> really apply because those are about stuffing U-labels into ASCII protocol
> slots (i.e., by making them A-labels).
> #2 When displayed to a user, U-labels are going to make sense; A-labels
> will not. (Note: there are homograph attacks. But that is not a problem
> specific to this choice, and IDNA procedures are supposed to mitigate that.)
> #3 U-labels are supposed to be compared “AS-IS” (RFC 5891), but A-labels
> are case-insensitive. Since the local-part is case-sensitive, this opens
> the possibility that e-mail address strings in certificates can (under the
> proper circumstances) be compared using a binary comparison operation
> (i.e., exact equality).
>
> Back to the alternatives: I am not withdrawing my suggestion but merely
> proposing it as an alternative that should be empirically examined before
> being dismissed, especially since CHOICE { IA5String, UTF8String } is (or
> was?) on the table at the time.
>
> Best regards,
>
> Sean
>
> On Apr 5, 2016, at 5:05 PM, Wei Chuang  wrote:
>
>
> On Tue, Apr 5, 2016 at 10:30 AM, Jim Schaad 
> wrote:
>
>>
>> *From:* pkix [mailto:pkix-bounces@ietf.org] *On Behalf Of *Russ Housley
>> *Sent:* Tuesday, April 05, 2016 9:18 AM
>> *Cc:* IETF PKIX ; IETF SMIME 
>> *Subject:* Re: [pkix] [smime] Support for email address
>> internationalization in RFC5280 certificates
>>
>>
>>
>> On Apr 4, 2016, at 6:20 PM:
>>
>>
>>
>>
>>
>> On Feb 7, 2016, at 12:15 PM, Wei Chuang  wrote:
>>
>>
>>
>> On Fri, Feb 5, 2016 at 4:46 PM, Peter Bowen  wrote:
>>
>> On Thu, Feb 4, 2016 at 11:05 AM, Wei Chuang  wrote:
>> > PKIX community,
>> >
>> > We've observed a limitation for specifying internationalized email
>> addresses
>> > as the local part which is restricted to essentially ASCII.  That is
>> subject
>> > or issuer email addresses which should be stored as subject-alt-name or
>> > issuer-alt-name rfc822Name and are encoded as IA5String.  This is
>> despite
>> > the internationalization in email usage as specified by
>> internationalization
>> > of email headers in RFC6532 allowing Unicode in To, From, etc fields and
>> > becoming fairly commonplace.  RFC5280 already specifies
>> internationalization
>> > of the domain but lacks any specification for the local-part.
>>
>>
>>
>> Up until now, I have tried to lay low on this topic. However, having
>> reviewed the relevant standards and implementations in the field, I have my
>> 22¢:
>>
>>
>>
>> The proposed methods are to create an otherName form and assign a new
>> object identifier for it (A. Melnikov, ed., draft-ietf-pkix-eai-addresses-00),
>> and to encode the local part in base64 with “:” as an escape signal (L.
>> Baudoin, et. al., draft-lbaudoin-iemax-02). There is also a counterproposal
>> on the agenda, which I will label as #3, to make rfc822Name a CHOICE
>> {IA5String, UTF8String}. There are two other methods that deserve
>> serious consideration. My 0.2¢ is on #4 and my 21.8¢ is on #5:
>>
>>
>>
>> *#4* Extend GeneralName with a new name type:
>>
>>
>>
>> GeneralName ::= CHOICE {
>>
>>   otherName [0] INSTANCE OF OTHER-NAME,
>>
>>   rfc822Name [1] IA5String,
>>
>>   dNSName [2] IA5String,
>>
>>   x400Address [3] ORAddress,
>>
>>   directoryName [4] Name,
>>
>>   ediPartyName [5] EDIPartyName,
>>
>>   uniformResourceIdentifier [6] IA5String,
>>
>>   iPAddress [7] OCTET STRING,
>>
>>   registeredID [8] OBJECT IDENTIFIER,
>>
>>   *eaiName [9] UTF8String*
>>
>>   ... }
>>
>>
>>
>> The advantage of this approach is that it conforms to X.509:2012, which
>> uses … syntax to show that the CHOICE is extensible. However, the IETF
>> invented GeneralName (RFC 2459), and the latest ASN.1 (RFC 5912) does not
>> use … syntax for extensibility. (Basically I think most implementations
>> would barf on this CHOICE, and would cause the overall ASN.1 decoding op to
>> fail, meaning all places where GeneralName is directly encoded, would cause
>> implementations to barf.)
>>
>>
>>
>> *#5* Change GeneralName so that rfc822Name is actually just UTF8String:
>>
>>
>>
>>    GeneralName ::= CHOICE {
>>
>>         otherName                   [0]  INSTANCE OF OTHER-NAME,
>>
>>         rfc822Name                  [1]  *UTF8String*,
>>
>>         dNSName                     [2]  IA5String,
>>
>>         x400Address                 [3]  ORAddress,
>>
>>         directoryName               [4]  Name,
>>
>>         ediPartyName                [5]  EDIPartyName,
>>
>>         uniformResourceIdentifier   [6]  IA5String,
>>
>>         iPAddress                   [7]  OCTET STRING,
>>
>>         registeredID                [8]  OBJECT IDENTIFIER
>>
>>    }
>>
>>
>>
>> GeneralName is in the IMPLICIT TAGS part of PKIX. That means that on the
>> wire, a GeneralName will (almost always) just be serialized as the
>>
>> application tag in the choice, followed by the length and the data. The
>> counterproposal of a CHOICE {IA5String, UTF8String} is flawed in that it
>> will force ALL rfc822Names to include an additional tag UNIVERSAL 22 in the
>> case of IA5String, because the choice is ambiguous without the tag (so a
>> proper ASN.1 compiler will force the serialization and de-serialization of
>> the tag). Note: UTF8String (in a CHOICE) would force serialization of the
>> tag UNIVERSAL 12.
>>
>>
>>
>> With this proposal #5, UTF8String is just a superset of IA5String.
>> Therefore, new implementations will “just work” with virtually no further
>> coding. The high-octet data in UTF8String will violate expectations for
>> older implementations that are looking for IA5String. But enforcement of
>> octets 00-7F is almost never done in the decoding step, or if it is done,
>> it does not cause the entire ASN.1 decoding op to fail. (Note: this would
>> be an “ASN.1 value constraint violation.”) If most implementations will
>> continue to decode the ASN.1 and simply skip over what it perceives to be
>> “invalid ASCII” (or simply rejects that particular alternative when doing
>> name comparisons), we are good to go. This basically mirrors the way that
>> EAI itself works in RFCs 6530-6532.
>>
>>
>>
>> To test this, one would want to construct a signed certificate with
>> “invalid” IA5String data that actually contains valid Unicode octets, and
>> see what happens with various implementations.
>>
>>
>>
>> I am not saying that this is the “right” approach, but I do think that it
>> deserves serious consideration when evaluating alternatives. An example of
>> an advantage is that it should preserve name constraints with no additional
>> coding.
>>
>>
>

--001a113501f619f9f50532be024d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


[Restarting and moving this thread to spasm]

Hi all,

I think there's general interest in using draft-ietf-pkix-eai-addresses-00 to document supporting EAI local part i.e. to use a new GeneralNames otherNames type with UTF8 email address local part.  That said, there are some remaining issues from the previous thread:

On Wed, Apr 6, 2016 at 3:48 PM, Sean Leonard <dev+ietf@seantek.com> wrote:
To be clear, the otherName form (draft-ietf-pkix-eai-addresses-00) is a sensible path forward. That is how GeneralName was designed to be extended all along.

Russ corrected me offline and pointed out that GeneralName is “owned” (well, created originally anyway) by ITU-T X.509. It is not an IETF-originated extension.

In order to add a new otherName type in GeneralName which appears to be "owned" by ITU-T, does this then requires coordination with ITU-T?
 

Any EAI mechanism will have consider the impact of Name Constraints, the functionality of which needs to be preserved.

Additionally, the EAI document should say something about whether A-labels (i.e., Punycode) or U-labels ought to be used on the domain side. I believe that U-labels should be used on the domain side when in the otherName UTF8String. There are three solid reasons:

The draft very clearly matches RFC5280 pattern of using A-labels (ACE) for the domain names.  While understandably its more convenient to process the domain part in UTF8 display format, for validation purposes it would seem to me to make sense to keep domain name validation consistent with the rest of the RFC5280 handling to reduce the likelihood of implementation differences.  
 
I wonder if an update to this draft should say something about mitigating homograph attacks in the security section?  I think this is an ideal time to mitigate some of the likely security attacks.   In another thread it was mentioned that using PRECIS (RFC7564) could help, and following that up the RFC points at Unicode Security Mechanism.  Some ideas are to restrict obsolete or specialized character set and to restrict the local part to a single script type e.g. Russian Cyrillic only or ASCII only.  

-Wei 
 
#1 Since it’s UTF8String, it’s simply “more correct” to use U-labels instead of A-labels. The requirements of RFC 5280 regarding IDN don’t really apply because those are about stuffing U-labels into ASCII protocol slots (i.e., by making them A-labels).
#2 When displayed to a user, U-labels are going to make sense; A-labels will not. (Note: there are homograph attacks. But that is not a problem specific to this choice, and IDNA procedures are supposed to mitigate that.)
#3 U-labels are supposed to be compared “AS-IS” (RFC 5891), but A-labels are case-insensitive. Since the local-part is case-sensitive, this opens the possibility that e-mail address strings in certificates can (under the proper circumstances) be compared using a binary comparison operation (i.e., exact equality).

Back to the alternatives: I am not withdrawing my suggestion but merely proposing it as an alternative that should be empirically examined before being dismissed, especially since CHOICE { IA5String, UTF8String } is (or was?) on the table at the time.

Best regards,

Sean

On Apr 5, 2016, at 5:05 PM, Wei Chuang <weihaw@google.com> wrote:


On Tue, Apr 5, 2016 at 10:30 AM, Jim Schaad <ietf@augustcellars.com> wrote:



From: pkix [mailto:pkix-bounces@ietf.org] On Behalf Of Russ Housley
Sent: Tuesday, April 05, 2016 9:18 AM
Cc: IETF PKIX <pkix@ietf.org>; IETF SMIME <smime@ietf.org>
Subject: Re: [pkix] [smime] Support for email address internationalization in RFC5280 certificates
 
On Apr 4, 2016, at 6:20 PM:


 
On Feb 7, 2016, at 12:15 PM, Wei Chuang <weihaw@google.com> wrote:
 
On Fri, Feb 5, 2016 at 4:46 PM, Peter Bowen <pzbowen@gmail.com> wrote:
On Thu, Feb 4, 2016 at 11:05 AM, Wei Chuang <weihaw@google.com> wrote:
> PKIX community,
>
> We've observed a limitation for specifying internationalized email addresses
> as the local part which is restricted to essentially ASCII.  That is subject
> or issuer email addresses which should be stored as subject-alt-name or
> issuer-alt-name rfc822Name and are encoded as IA5String.  This is despite
> the internationalization in email usage as specified by internationalization
> of email headers in RFC6532 allowing Unicode in To, From, etc fields and
> becoming fairly commonplace.  RFC5280 already specifies internationalization
> of the domain but lacks any specification for the local-part.
 
Up until now, I have tried to lay low on this topic. However, having reviewed the relevant standards and implementations in the field, I have my 22¢:
 
The proposed methods are to create an otherName form and assign a new object identifier for it (A. Melnikov, ed., draft-ietf-pkix-eai-addresses-00), and to encode the local part in base64 with “:” as an escape signal (L. Baudoin, et. al., draft-lbaudoin-iemax-02). There is also a counterproposal on the agenda, which I will label as #3, to make rfc822Name a CHOICE {IA5String, UTF8String}. There are two other methods that deserve serious consideration. My 0.2¢ is on #4 and my 21.8¢ is on #5:
 
#4 Extend GeneralName with a new name type:
 
GeneralName ::= CHOICE {
  otherName [0] INSTANCE OF OTHER-NAME,
  rfc822Name [1] IA5String,
  dNSName [2] IA5String,
  x400Address [3] ORAddress,
  directoryName [4] Name,
  ediPartyName [5] EDIPartyName,
  uniformResourceIdentifier [6] IA5String,
  iPAddress [7] OCTET STRING,
  registeredID [8] OBJECT IDENTIFIER,
  eaiName [9] UTF8String
  ... }
 
The advantage of this approach is that it conforms to X.509:2012, which uses … syntax to show that the CHOICE is extensible. However, the IETF invented GeneralName (RFC 2459), and the latest ASN.1 (RFC 5912) does not use … syntax for extensibility. (Basically I think most implementations would barf on this CHOICE, and would cause the overall ASN.1 decoding op to fail, meaning all places where GeneralName is directly encoded, would cause implementations to barf.)
 
#5 Change GeneralName so that rfc822Name is actually just UTF8String:
 
   GeneralName ::= CHOICE {
        otherName                   [0]  INSTANCE OF OTHER-NAME,
        rfc822Name                  [1]  UTF8String,
        dNSName                     [2]  IA5String,
        x400Address                 [3]  ORAddress,
        directoryName               [4]  Name,
        ediPartyName                [5]  EDIPartyName,
        uniformResourceIdentifier   [6]  IA5String,
        iPAddress                   [7]  OCTET STRING,
        registeredID                [8]  OBJECT IDENTIFIER
   }
 
GeneralName is in the IMPLICIT TAGS part of PKIX. That means that on the wire, a GeneralName will (almost always) just be serialized as the
application tag in the choice, followed by the length and the data. The counterproposal of a CHOICE {IA5String, UTF8String} is flawed in that it will force ALL rfc822Names to include an additional tag UNIVERSAL 22 in the case of IA5String, because the choice is ambiguous without the tag (so a proper ASN.1 compiler will force the serialization and de-serialization of the tag). Note: UTF8String (in a CHOICE) would force serialization of the tag UNIVERSAL 12.
 
With this proposal #5, UTF8String is just a superset of IA5String. Therefore, new implementations will “just work” with virtually no further coding. The high-octet data in UTF8String will violate expectations for older implementations that are looking for IA5String. But enforcement of octets 00-7F is almost never done in the decoding step, or if it is done, it does not cause the entire ASN.1 decoding op to fail. (Note: this would be an “ASN.1 value constraint violation.”) If most implementations will continue to decode the ASN.1 and simply skip over what it perceives to be “invalid ASCII” (or simply rejects that particular alternative when doing name comparisons), we are good to go. This basically mirrors the way that EAI itself works in RFCs 6530-6532.
 
To test this, one would want to construct a signed certificate with “invalid” IA5String data that actually contains valid Unicode octets, and see what happens with various implementations.
 
I am not saying that this is the “right” approach, but I do think that it deserves serious consideration when evaluating alternatives. An example of an advantage is that it should preserve name constraints with no additional coding.




--001a113501f619f9f50532be024d--


From nobody Fri May 13 13:09:44 2016
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 325BD12B065 for ; Fri, 13 May 2016 13:09:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.899
X-Spam-Level: 
X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S7qqKQuI5vUY for ; Fri, 13 May 2016 13:09:40 -0700 (PDT)
Received: from mail.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id B8C9E12B039 for ; Fri, 13 May 2016 13:09:39 -0700 (PDT)
Received: from localhost (ronin.smetech.net [209.135.209.5]) by mail.smetech.net (Postfix) with ESMTP id 8135BF2402E; Fri, 13 May 2016 16:09:39 -0400 (EDT)
X-Virus-Scanned: amavisd-new at smetech.net
Received: from mail.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id QCsbg6BPepkn; Fri, 13 May 2016 15:52:42 -0400 (EDT)
Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.smetech.net (Postfix) with ESMTP id DBFCAF2402A; Fri, 13 May 2016 16:09:38 -0400 (EDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_619C6D1E-8CA2-496D-BF87-3585050CE554"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Russ Housley 
In-Reply-To: 
Date: Fri, 13 May 2016 16:09:47 -0400
Message-Id: <1727F1F7-0CC0-4F46-8744-E190F5741498@vigilsec.com>
References:      <028101d18f60$dd6262e0$982728a0$@augustcellars.com>  <3851E218-C5F4-4BB3-B9DB-B8679361A2B9@seantek.com> 
To: Wei Chuang 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: 
Cc: spasm@ietf.org
Subject: Re: [Spasm] Support for email address internationalization in RFC5280 certificates
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 13 May 2016 20:09:42 -0000

--Apple-Mail=_619C6D1E-8CA2-496D-BF87-3585050CE554
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Wei:

> In order to add a new otherName type in GeneralName which appears to =
be "owned" by ITU-T, does this then requires coordination with ITU-T?

No.

The syntax for General name (from page 128 of RRC5280):

   GeneralName ::=3D CHOICE {
        otherName                 [0]  AnotherName,
        rfc822Name                [1]  IA5String,
        dNSName                   [2]  IA5String,
        x400Address               [3]  ORAddress,
        directoryName             [4]  Name,
        ediPartyName              [5]  EDIPartyName,
        uniformResourceIdentifier [6]  IA5String,
        iPAddress                 [7]  OCTET STRING,
        registeredID              [8]  OBJECT IDENTIFIER }

   -- AnotherName replaces OTHER-NAME ::=3D TYPE-IDENTIFIER, as
   -- TYPE-IDENTIFIER is not supported in the '88 ASN.1 syntax

   AnotherName ::=3D SEQUENCE {
        type-id    OBJECT IDENTIFIER,
        value      [0] EXPLICIT ANY DEFINED BY type-id }

So, anyone can assign an object identifier and the syntax that goes with =
it.

In fact, the PKIX WG has already established an IANA registry for the =
assignment of object identifiers for otherNames.  They have this prefix:

   id-pkix OBJECT IDENTIFIER ::=3D { iso(1) identified-organization(3)=20=

               dod(6) internet(1) security(5) mechanisms(5) pkix(7) }

   id-on   OBJECT IDENTIFIER ::=3D { id-pkix 8 }    -- other name forms

The registry is here:

   =
http://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbers-=
1.3.6.1.5.5.7.8

In my view, we just need to add a new object identifiers to this =
registry ...

Have a great weekend,
  Russ


--Apple-Mail=_619C6D1E-8CA2-496D-BF87-3585050CE554
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

Wei:

In order to add a new otherName type in GeneralName which =
appears to be "owned" by ITU-T, does this then requires coordination =
with =
ITU-T?

No.

The =
syntax for General name (from page 128 of =
RRC5280):

   GeneralName ::=3D =
CHOICE {
        otherName     =
            [0] =
 AnotherName,
        rfc822Name =
               [1] =
 IA5String,
        dNSName   =
                [2] =
 IA5String,
        x400Address =
              [3] =
 ORAddress,
        directoryName =
            [4] =
 Name,
        ediPartyName   =
           [5] =
 EDIPartyName,
        =
uniformResourceIdentifier [6]  IA5String,
    =
    iPAddress               =
  [7]  OCTET STRING,
        =
registeredID              [8] =
 OBJECT IDENTIFIER }

   -- =
AnotherName replaces OTHER-NAME ::=3D TYPE-IDENTIFIER, =
as
   -- TYPE-IDENTIFIER is not supported in the '88 =
ASN.1 syntax

   AnotherName ::=3D =
SEQUENCE {
        type-id   =
 OBJECT IDENTIFIER,
        value =
     [0] EXPLICIT ANY DEFINED BY type-id =
}

So, anyone can assign an object =
identifier and the syntax that goes with it.

In =
fact, the PKIX WG has already established an IANA registry for the =
assignment of object identifiers for otherNames.  They have this =
prefix:

   id-pkix OBJECT =
IDENTIFIER ::=3D { iso(1) =
identified-organization(3) 
        =
       dod(6) internet(1) security(5) mechanisms(5) =
pkix(7) }

   id-on   =
OBJECT IDENTIFIER ::=3D { id-pkix 8 }    -- other name =
forms

The registry is =
here:


In =
my view, we just need to add a new object identifiers to this registry =
...

Have a great weekend,
  =
Russ

=

--Apple-Mail=_619C6D1E-8CA2-496D-BF87-3585050CE554--


From nobody Fri May 13 16:09:05 2016
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 086D312D620 for ; Fri, 13 May 2016 16:09:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.696
X-Spam-Level: 
X-Spam-Status: No, score=-3.696 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, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 qNFV8bnjWAwl for ; Fri, 13 May 2016 16:09:01 -0700 (PDT)
Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::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 9D1A012D608 for ; Fri, 13 May 2016 16:09:01 -0700 (PDT)
Received: by mail-oi0-x236.google.com with SMTP id k142so193671626oib.1 for ; Fri, 13 May 2016 16:09:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=7ci1TPR8LOP9L5Rj8uhLE6Chf05zlobvaJdQ/PF5fi0=; b=hv4I4vraTUGEkM0SVhBFUUY+K3HQ2WeSM6phBDHIRj1Plna1wcORE3Fr7C3tby7xNQ tJS11Uoh/2+mOD/6BoB94xaYdtqj1XPMDeA5bYkzbUcZu/gPYBo5N3PGF6qpkpUrq80F DXBV2qvq8ZI+AMaKnsRMHFVUP3MD2ijqX+hp5q+215eTvJlRGj+R/jMp4r4CL4sAc7ge xY8YS3eWSCbvnLWCc3vOrb1NLy2aFhlruC9kS+SV7QZoL02TqQNY+g4kxaiHYyuvdnLU 9xwrADJ5/zy57ey4IzjEAeWo+D2NBzqXPtO3W4yhmtO/vEw7vG0zL689HfS1UjNlXoSU sBuQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=7ci1TPR8LOP9L5Rj8uhLE6Chf05zlobvaJdQ/PF5fi0=; b=Bo0FljwQeR8VTwVrCnsLnuKqEk8Kl5YfNN7Q/GDRwAgYUygCt91hKqThZ62WUpSvm4 pAKWStre9eYLYrNs4MXhkdZwDpyOYkO9Gzj9vDqLCbsf6SeGLMuASusc9SND9g+WGN8/ 74R8iiWGJENR55clKy5zvw1yA7oDa44o6Xfv0neFWLscl3//zxr2KcqlGNkU1vI6FKE6 1EuemKP3Kb/BMn90nZq1/6d4wYlZKHsDtAwSKjuw1/7+WM9bT5ueLmaaQLBN1bSIpIMf y5Hr9t+Aj/+AwuqzQjWVyG64vhej5+f7APr+ZyRlQBxXldORqoyrC4Qf7v0BSYSH+qoX BHVQ==
X-Gm-Message-State: AOPr4FWY236Tsm4AJWIiAIbVRxHx+I2eUqnniYC7K7zfUVQ/jVGLmVgD+t2b/K5fDbAxdlTQKBRHf5KkeVu0tSYX
X-Received: by 10.202.252.135 with SMTP id a129mr9222018oii.128.1463180940808;  Fri, 13 May 2016 16:09:00 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.157.32.202 with HTTP; Fri, 13 May 2016 16:09:00 -0700 (PDT)
From: Wei Chuang 
Date: Fri, 13 May 2016 16:09:00 -0700
Message-ID: 
To: spasm@ietf.org
Content-Type: multipart/alternative; boundary=001a113df28038684e0532c15c3d
Archived-At: 
Subject: [Spasm] Updating S/MIME handling of message/rfc822?
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 13 May 2016 23:09:04 -0000

--001a113df28038684e0532c15c3d
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Hi,

I would like to propose that draft-schaad-rfc5751-bis-00 further specify
handling message/rfc822 processing and specify how to merge message headers
from
decrypted/decoded non message/rfc822 types mime parts.  If we can clarify
header
processing this could provide significant improvement in privacy as
revealing
headers like subject can reveal a great deal about the content of the
message
and even metadata like date can be used with traffic analysis to reveal
hidden
recipients (Bcc).

There already exists "Securing Header Fields" as experimental RFC7508.  This
proposes that certain message header fields are signed and verified, and
optionally can replace or delete the field.  This provides a high degree of
flexibility and one approach would be to standard track this.  But this RFC
requires a fairly significant change to S/MIME / CMS processing steps, and
there
would be a deployed base that would find it difficult to interoperate with.
Another more feasibile approach is to clarify RFC5751 message/rfc822
language.
Likely this can get most of the header hiding benefit with a smaller change
to
CMS processing.

This proposes that if it is desirable to protect header integrity and
privacy
that message/rfc822 be used as specifed in RFC5280.  However this instead of
presenting both the outer header (original) and the inner header
(message/rfc822) part to the recipient, this proposes that when the CMS
processing is done, the inner headers in message/rfc822 update the outer
ones.
If there is a conflict between the inner and outer, then the inner header
replaces the outer ones.  Body content in message/rfc822 part replaces that
of
the parent as well.  Further there should a signed attribute that tells the
recipient to protect header integrity and privacy upon reply or forwarding
of
the message.  There also should be a capability specified as well.  Before
sending the message implementations would move these headers to the
message/rfc822 part, leaving those header fields unspecified in the sent
outer message header.

Compliant implementations should protect at least these message headers:
  Subject
  Date
  References
  Message-ID
  Keywords
  Original-XXX
This list is not meant to be exhaustive.  A complete list generated
from (http://www.iana.org/assignments/message-headers/message-headers.xhtml)
can
be done at a later time.  This list also makes no attempt to hide transport
artifacts like the trace headers as these are outside of the control of the
sender and recipient, or the sender and recipient headers as these are
needed by
transport.  (Other much more heavy weight approaches are better suited to
handle
hiding those headers)

thanks,
-Wei

--001a113df28038684e0532c15c3d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


Hi, 

I would like to propose that draft-schaad-rfc5751-bis-00 further specify
handling message/rfc822 processing and specify how to merge message headers from
decrypted/decoded non message/rfc822 types mime parts.  If we can clarify header
processing this could provide significant improvement in privacy as revealing
headers like subject can reveal a great deal about the content of the message
and even metadata like date can be used with traffic analysis to reveal hidden
recipients (Bcc).

There already exists "Securing Header Fields" as experimental RFC7508.  This
proposes that certain message header fields are signed and verified, and
optionally can replace or delete the field.  This provides a high degree of
flexibility and one approach would be to standard track this.  But this RFC
requires a fairly significant change to S/MIME / CMS processing steps, and there
would be a deployed base that would find it difficult to interoperate with.
Another more feasibile approach is to clarify RFC5751 message/rfc822 language.
Likely this can get most of the header hiding benefit with a smaller change to
CMS processing.

This proposes that if it is desirable to protect header integrity and privacy
that message/rfc822 be used as specifed in RFC5280.  However this instead of
presenting both the outer header (original) and the inner header
(message/rfc822) part to the recipient, this proposes that when the CMS
processing is done, the inner headers in message/rfc822 update the outer ones.
If there is a conflict between the inner and outer, then the inner header
replaces the outer ones.  Body content in message/rfc822 part replaces that of
the parent as well.  Further there should a signed attribute that tells the
recipient to protect header integrity and privacy upon reply or forwarding of
the message.  There also should be a capability specified as well.  Before
sending the message implementations would move these headers to the
message/rfc822 part, leaving those header fields unspecified in the sent
outer message header.

Compliant implementations should protect at least these message headers:
  Subject
  Date
  References
  Message-ID
  Keywords
  Original-XXX
This list is not meant to be exhaustive.  A complete list generated
be done at a later time.  This list also makes no attempt to hide transport
artifacts like the trace headers as these are outside of the control of the
sender and recipient, or the sender and recipient headers as these are needed by
transport.  (Other much more heavy weight approaches are better suited to handle
hiding those headers)

thanks,
-Wei


--001a113df28038684e0532c15c3d--


From nobody Fri May 13 16:17:33 2016
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 B0D6F12D6B7 for ; Fri, 13 May 2016 16:17:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Level: 
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lo1RIXhR7Rjd for ; Fri, 13 May 2016 16:17:29 -0700 (PDT)
Received: from mail.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id A78C312D6AF for ; Fri, 13 May 2016 16:17:29 -0700 (PDT)
Received: from localhost (ronin.smetech.net [209.135.209.5]) by mail.smetech.net (Postfix) with ESMTP id 13656F2402E for ; Fri, 13 May 2016 19:17:29 -0400 (EDT)
X-Virus-Scanned: amavisd-new at smetech.net
Received: from mail.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id MQ4eQtbRzk3V for ; Fri, 13 May 2016 19:00:31 -0400 (EDT)
Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.smetech.net (Postfix) with ESMTP id A94A0F2402A for ; Fri, 13 May 2016 19:17:28 -0400 (EDT)
From: Russ Housley 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: <316ECF88-612A-4131-8A96-E5F76671929A@vigilsec.com>
Date: Fri, 13 May 2016 19:17:37 -0400
To: spasm@ietf.org
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
X-Mailer: Apple Mail (2.1878.6)
Archived-At: 
Subject: [Spasm] My take on handling EKU constraints
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 13 May 2016 23:17:32 -0000

Review and comment are most welcome.

Russ

=3D =3D =3D =3D =3D =3D =3D =3D =3D =3D

A new version of I-D, draft-housley-spasm-eku-constraints-00.txt
has been successfully submitted by Russell Housley and posted to the
IETF repository.

Name:		draft-housley-spasm-eku-constraints
Revision:	00
Title:		Extended Key Usage Constraints
Document date:	2016-05-13
Group:		Individual Submission
Pages:		5
URL:            =
https://www.ietf.org/internet-drafts/draft-housley-spasm-eku-constraints-0=
0.txt
Status:         =
https://datatracker.ietf.org/doc/draft-housley-spasm-eku-constraints/
Htmlized:       =
https://tools.ietf.org/html/draft-housley-spasm-eku-constraints-00


Abstract:
  This document specifies the extended key usage constraints
  certificate extension, which is used to place restrictions on the key
  purpose identifiers that are authorized to appear in subsequent
  certificates in a certification path.  Restrictions apply to the
  extended key usage certificate extension, which is described in RFC
  5280.


From nobody Fri May 13 22:14:28 2016
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 63A5512B048; Fri, 13 May 2016 22:14:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7WPAlrLDaDC8; Fri, 13 May 2016 22:14:26 -0700 (PDT)
Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 143DA1200A0; Fri, 13 May 2016 22:14:22 -0700 (PDT)
Received: from hebrews (c-24-21-96-37.hsd1.or.comcast.net [24.21.96.37]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 5A67338F00; Fri, 13 May 2016 22:14:22 -0700 (PDT)
From: "Jim Schaad" 
To: 
Date: Fri, 13 May 2016 22:14:21 -0700
Message-ID: <064101d1ad9f$798f3a10$6cadae30$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AdGtmoH4s17Yxci0RjOBfMUhT6qsrg==
Content-Language: en-us
Archived-At: 
Cc: spasm@ietf.org
Subject: [Spasm] Comments on draft-housley-spasm-eku-constraints-00
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 14 May 2016 05:14:27 -0000

Russ,

I have a few comments on your draft.

1. I believe that doing the restriction to just CA certificates is
incorrect.  I believe that this is just as useful for an AA certificate.  I
would request that this restriction be relaxed and potentially removed.

2.  I believe that in section 3.1 an application should be able to require
that an EKU be permitted.  This seems to be a logical location to specified
that.  This is commonly done for Microsoft in saying that this root may be
used for specific key usages but not for others.

3.  I believe that step (p) (1) is missing a step, although it could
potentially go into step (h) in section 3.5
	(2) if excludedKeyPurposesIds is present in the certificate, set the
excluded_key_purpose_ids state varble to..   Set the permittedKeyPurposeIds
to the intersection of the result from step (1) and the inverse of the
excludedKeyPurposesIds.

	(3) if the excludedKeyPurposesId is the empty set, then fail the
validation procedure

	The certificate should be considered invalid regardless of the
presence of the EKU extension in the EE certificate.

4.  I recognize that this is the method that you feel is correct.  However,
justification text about why the current method used by Msft et al is not
correct is probably required.  At a minimum a recognition that this has been
the Msft behavior since day 1 is needed.

Jim








From nobody Fri May 13 22:25:40 2016
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 9ABDC12B048 for ; Fri, 13 May 2016 22:25:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aDjmUYHvw0Ax for ; Fri, 13 May 2016 22:25:37 -0700 (PDT)
Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AB111200A0 for ; Fri, 13 May 2016 22:25:37 -0700 (PDT)
Received: from hebrews (c-24-21-96-37.hsd1.or.comcast.net [24.21.96.37]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id 8FECA38EF0; Fri, 13 May 2016 22:25:36 -0700 (PDT)
From: "Jim Schaad" 
To: 
Date: Fri, 13 May 2016 22:25:35 -0700
Message-ID: <064201d1ada1$0b94dc20$22be9460$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AdGtn8qyvA1LlkeNS22To8vGYb8Lkg==
Content-Language: en-us
Archived-At: 
Cc: spasm@ietf.org
Subject: [Spasm] comments on draft-ietf-pkix-eai-addresses-01
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 14 May 2016 05:25:38 -0000

1.  This document has been expired for some time and thus should be
republished if we are planning to use it as a starting point.  (If this is
done the name would also need to be adjusted.)

2.  The text about the format of an eaiMailbox name seems to be strange.
Specifically, the text about what it does not have deals with display
formats of an eaiMailbox and not it's format.

3.  A section on name constraints is needed in this document similar to the
text in section 4.2.1.10 in rfc 5280

Jim



From nobody Sat May 14 06:13:45 2016
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 205EA12D1AB for ; Sat, 14 May 2016 06:13:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.297
X-Spam-Level: 
X-Spam-Status: No, score=-5.297 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.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0IWEQu7hotrV for ; Sat, 14 May 2016 06:13:41 -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 C0B4412D1B6 for ; Sat, 14 May 2016 06:13:39 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id D0A00BE33 for ; Sat, 14 May 2016 14:13:37 +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 2eVnWEUTWlRH for ; Sat, 14 May 2016 14:13:34 +0100 (IST)
Received: from [10.87.48.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 64F96BE25 for ; Sat, 14 May 2016 14:13:34 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1463231614; bh=Z4pFpl9L8zqFsyFCvfiCEIWHrhrIkn8HraOgA7ccogM=; h=To:From:Subject:Date:From; b=1xaNh5Qx33Yej4YiCm+clv5Y02dC61Y9fkD3BcdI05CFANdaPBFsAGpzcQpjSEVwq MHVnyIs8PCTvia6SJPJTOzt1u9qwEh5LtDZnvEL/WjPqCuru3C/cwyhQ9sLpLxblN5 8WyKuLP/uLVtf/B9Y/mu+1jVGt1dyNkHS1gcRK6A=
To: spasm@ietf.org
From: Stephen Farrell 
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <5737247E.9050309@cs.tcd.ie>
Date: Sat, 14 May 2016 14:13:34 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms070407000004050004020703"
Archived-At: 
Subject: [Spasm] formal chartering started...
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 14 May 2016 13:13:44 -0000

This is a cryptographically signed message in MIME format.

--------------ms070407000004050004020703
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


Hiya,

Thanks all for submitting drafts and discussing the technical
issues, both good things to see. I've started the formal bit
of chartering - see the current text at [1]. I modified that
a little from the last one sent to the list, changes were mostly
editorial I think other than adding the proposal from John to
try out another certificate retrieval thing. (I'd be fine with
that being something that is adopted or not depending on whether
we figure there's a chance of real deployment, so e.g. if John
comes away from the M3AAWG meeting with a few email providers
who say they'd try that, then the WG could include it, but if
not, it could be dropped. I'm fine that we don't block on finding
out about that so long as a decision is made soonish, based on
whether or not we think real deployments or experiments would
be done.)

Anyway, please comment on the text at [1] in the next week (with
OLD/NEW text please) and after that I'll push it into IESG informal
evaluation for June 2nd. From then, all going well, the WG might
end up being formally created about June 16th.

If you think the text at [1] is good enough as-is (and it does
not need to be perfect:-) then a few folks saying so in response
to this is useful, particularly if you are not the author of any
of the drafts mentioned in the charter as possible starting
points. So if you've just been watching or hope to get this WG
to charter some other work later, you might wanna +1 this if
that's what you think.

Cheers,
S.

[1] https://datatracker.ietf.org/doc/charter-ietf-spasm/


--------------ms070407000004050004020703
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
CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ
BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD
ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll
bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw
aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA
Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra
C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3
rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5
R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r
dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt
3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw
MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ
QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv
BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5
BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu
Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll
bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc
MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE
MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG
9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD
C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9
U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM
aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai
9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC
BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE
BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs
IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g
QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC
SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC
ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv
mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm
VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4
D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI
dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu
N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE
FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp
MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE
WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG
JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+
SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g
BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv
bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY
0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF
NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9
uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p
6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv
Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu
mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7
RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO
/ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN
JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM
MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG
A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0
Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA
oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA1MTQx
MzEzMzRaMC8GCSqGSIb3DQEJBDEiBCCqQ4IWnbAwgyxGnYo8D6qwMLe/lmtfL3RuzuOIv0Nm
XjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN
AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC
AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw
IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB
nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD
VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq
hkiG9w0BAQEFAASCAQBIHAwY7tx5DHZdxqxNC0hNPj3pJiSjnarSF+Qw+CpHBMzJHT3L/fUi
pQflb9hrUnsMO5bs/MKLQJ9yxrtIRLoqtiPbjDF1N6vIN7MLyDwBeMNUN84fqNxw5qHKaWi3
3WpTINytgNuy/jmRRN4r77hU8vVCiCoy3VT1Mc2FmNly3qJ8qMMBmS9hl5Xpo/knx+shGzxd
D7olrEaqs31+aJNbc4dhqw+lAKx+/iE263je86h9pyTT7HTW1jaFSch4cKNLbT3f8GyaIEJU
QoKggrH3ktMjuu/nzdKXompQJ012523z/PP1UukrFUh8P1kzGKqcRSd+K3J8O1h+lMb/TkbL
AAAAAAAA
--------------ms070407000004050004020703--


From nobody Sat May 14 10:22:43 2016
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 D23BC12D180 for ; Sat, 14 May 2016 10:22:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.445
X-Spam-Level: 
X-Spam-Status: No, score=-6.445 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3kj94k5nEMLO for ; Sat, 14 May 2016 10:22:40 -0700 (PDT)
Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.152]) (using TLSv1.2 with cipher CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5FEF12D129 for ; Sat, 14 May 2016 10:22:38 -0700 (PDT)
Received: from localhost by e34.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for  from ; Sat, 14 May 2016 11:22:38 -0600
Received: from d03dlp01.boulder.ibm.com (9.17.202.177) by e34.co.us.ibm.com (192.168.1.134) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted;  Sat, 14 May 2016 11:22:37 -0600
X-IBM-Helo: d03dlp01.boulder.ibm.com
X-IBM-MailFrom: tgindin@us.ibm.com
X-IBM-RcptTo: spasm@ietf.org
Received: from b03cxnp08026.gho.boulder.ibm.com (b03cxnp08026.gho.boulder.ibm.com [9.17.130.18]) by d03dlp01.boulder.ibm.com (Postfix) with ESMTP id 785771FF0023 for ; Sat, 14 May 2016 11:22:21 -0600 (MDT)
Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by b03cxnp08026.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id u4EHMaSq47251668 for ; Sat, 14 May 2016 10:22:36 -0700
Received: from d03av03.boulder.ibm.com (localhost [127.0.0.1]) by d03av03.boulder.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id u4EHMahk000474 for ; Sat, 14 May 2016 11:22:36 -0600
Received: from d50lp33.co.us.ibm.com (d50lp33.boulder.ibm.com [9.17.249.38]) by d03av03.boulder.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id u4EHMaua000470 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sat, 14 May 2016 11:22:36 -0600
Message-Id: <201605141722.u4EHMaua000470@d03av03.boulder.ibm.com>
Received: from localhost by d50lp33.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for  from ; Sat, 14 May 2016 11:22:36 -0600
Received: from smtp.notes.na.collabserv.com (192.155.248.81) by d50lp33.co.us.ibm.com (192.168.2.144) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted;  (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256/256) Sat, 14 May 2016 11:22:34 -0600
X-IBM-Helo: smtp.notes.na.collabserv.com
X-IBM-MailFrom: tgindin@us.ibm.com
X-IBM-RcptTo: spasm@ietf.org
Received: from /spool/local by smtp.notes.na.collabserv.com with smtp.notes.na.collabserv.com ESMTP for  from ; Sat, 14 May 2016 17:22:33 -0000
Received: from us1a3-smtp04.a3.dal06.isc4sb.com (10.106.154.237) by smtp.notes.na.collabserv.com (10.106.227.88) with smtp.notes.na.collabserv.com ESMTP; Sat, 14 May 2016 17:22:32 -0000
Received: from us1a3-mail59.a3.dal09.isc4sb.com ([10.142.3.90]) by us1a3-smtp04.a3.dal06.isc4sb.com with ESMTP id 2016051417223141-123284 ; Sat, 14 May 2016 17:22:31 +0000 
In-Reply-To: <064101d1ad9f$798f3a10$6cadae30$@augustcellars.com>
To: "Jim Schaad" 
From: "Tom Gindin" 
Date: Sat, 14 May 2016 13:22:31 -0400
References: <064101d1ad9f$798f3a10$6cadae30$@augustcellars.com>
MIME-Version: 1.0
X-KeepSent: E5F7F50D:BBBEFC83-85257FB3:004E1F4E; type=4; name=$KeepSent
X-Mailer: IBM Notes Release 9.0.1FP5 Octobe4, 2013
X-LLNOutbound: False
X-Disclaimed: 59131
X-TNEFEvaluated: 1
Content-Type: multipart/alternative; boundary="=_alternative 005F716E85257FB3_="
x-cbid: 16051417-0017-0000-0000-00002B4D1AAE
X-IBM-ISS-SpamDetectors: Score=0.4332; BY=0; FL=0; FP=0; FZ=0; HX=0; KW=0; PH=0; SC=0.4332; ST=0; TS=0; UL=0; ISC=
X-IBM-ISS-DetailInfo: BY=3.00005282; HX=3.00000240; KW=3.00000007; PH=3.00000004; SC=3.00000166; SDB=6.00702084; UDB=6.00325167; UTC=2016-05-14 17:22:33
x-cbparentid: 16051417-4536-0000-0000-000007B658F6
X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused
X-TM-AS-MML: disable
X-Content-Scanned: Fidelis XPS MAILER
X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused
Archived-At: 
Cc: spasm@ietf.org, draft-housley-spasm-eku-constraints@ietf.org
Subject: Re: [Spasm] Comments on draft-housley-spasm-eku-constraints-00
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 14 May 2016 17:22:42 -0000

--=_alternative 005F716E85257FB3_=
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="US-ASCII"

        Jim:

        On point 1, do AC's actually contain EKU extensions?  Your points=20
2 and 3 appear to need another initialization variable to replace Russ'=20
proposal in 3.2 (L).  That variable would be (J)=20
initial-permitted-key-purpose-ids replacing the null in Russ' 3.1, and=20
would be "a set of key purpose ID's permitted in extendedKeyUsage=20
extensions appearing within the certification path".  The initial value in =

Russ' proposal should probably be anyExtendedKeyUsage (already defined in=20
5280), and that would be the suggested default for this variable as well.
        My own justification text for point 4 would be something like=20
"This extension is defined as separate from the extendedKeyUsage extension =

in order to avoid conflicts between the natural interpretation of that=20
extension as constraining the behavior of the certificate subject and use=20
as a path constraint.  Some current software uses the extendedKeyUsage=20
extension within any issuer certificate as a path constraint, while RFC=20
5280 4.2.1.12 states that in general it appears only in EE certificates."

Tom Gindin
P.S.    The above suggestions are mine, and not necessarily those of my=20
employer.



From:   "Jim Schaad" 
To:     
Cc:     spasm@ietf.org
Date:   05/14/2016 01:14 AM
Subject:        [Spasm] Comments on draft-housley-spasm-eku-constraints-00
Sent by:        "Spasm" 



Russ,

I have a few comments on your draft.

1. I believe that doing the restriction to just CA certificates is
incorrect.  I believe that this is just as useful for an AA certificate. I
would request that this restriction be relaxed and potentially removed.

2.  I believe that in section 3.1 an application should be able to require
that an EKU be permitted.  This seems to be a logical location to=20
specified
that.  This is commonly done for Microsoft in saying that this root may be
used for specific key usages but not for others.

3.  I believe that step (p) (1) is missing a step, although it could
potentially go into step (h) in section 3.5
                 (2) if excludedKeyPurposesIds is present in the=20
certificate, set the
excluded=5Fkey=5Fpurpose=5Fids state varble to..   Set the=20
permittedKeyPurposeIds
to the intersection of the result from step (1) and the inverse of the
excludedKeyPurposesIds.

                 (3) if the excludedKeyPurposesId is the empty set, then=20
fail the
validation procedure

                 The certificate should be considered invalid regardless=20
of the
presence of the EKU extension in the EE certificate.

4.  I recognize that this is the method that you feel is correct. However,
justification text about why the current method used by Msft et al is not
correct is probably required.  At a minimum a recognition that this has=20
been
the Msft behavior since day 1 is needed.

Jim







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






--=_alternative 005F716E85257FB3_=
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset="US-ASCII"

        Jim:

=
        On point 1, do
AC's actually contain EKU extensions?  Your points 2 and 3 appear
to need another initialization variable to replace Russ' proposal in 3.2
(L).  That variable would be (J) initial-permitted-key-purpose-ids
replacing the null in Russ' 3.1, and would be "a set of key purpose
ID's permitted in extendedKeyUsage extensions appearing within the certific=
ation
path".  The initial value in Russ' proposal should probably be
anyExtendedKeyUsage (already defined in 5280), and that would be the sugges=
ted
default for this variable as well.
 =
       My own justification
text for point 4 would be something like "This extension is defined
as separate from the extendedKeyUsage extension in order to avoid conflicts
between the natural interpretation of that extension as constraining the
behavior of the certificate subject and use as a path constraint.  Some
current software uses the extendedKeyUsage extension within any issuer
certificate as a path constraint, while RFC 5280 4.2.1.12 states that in
general it appears only in EE certificates."

Tom Gindin
P.S.=
        The above suggestions are mine,
and not necessarily those of my employer.



From:      
 "Jim Schaad"
<ietf@augustcellars.com>
To:      
 <draft-housley-spasm-eku=
-constraints@ietf.org>
Cc:      
 spasm@ietf.org
Date:      
 05/14/2016 01:14 AM<=
br>Subject:    
   [Spasm] Comments
on draft-housley-spasm-eku-constraints-00
Sent by:    
   "Spasm"
<spasm-bounces@ietf.org>



Russ,

I have a few comments on your draft.

1. I beli=
eve that doing the restriction to just CA certificates is
incorrect. &nb=
sp;I believe that this is just as useful for an AA certificate.
 I
would request that this restriction be relaxed and potentially r=
emoved.

2.  I believe that in section 3.1 an application should=
 be able to
require
that an EKU be permitted.  This seems to be a logical locat=
ion to
specified
that.  This is commonly done for Microsoft in saying that=
 this root
may be
used for specific key usages but not for others.

3.  =
I believe that step (p) (1) is missing a step, although it could
potenti=
ally go into step (h) in section 3.5
          =
      
(2) if excludedKeyPurposesIds is present in the certificate, set the
exc=
luded=5Fkey=5Fpurpose=5Fids state varble to..   Set the permittedKeyPu=
rposeIds
to the intersection of the result from step (1) and the inverse=
 of the
excludedKeyPurposesIds.

         &nbs=
p;      
(3) if the excludedKeyPurposesId is the empty set, then fail the
validat=
ion procedure

               &nbs=
p;
The certificate should be considered invalid regardless of the
presence =
of the EKU extension in the EE certificate.

4.  I recognize tha=
t this is the method that you feel is correct.
 However,
justification text about why the current method used by M=
sft et al is not
correct is probably required.  At a minimum a reco=
gnition that this
has been
the Msft behavior since day 1 is needed.

Jim


=





=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F
Spasm mailing list
Spasm@ietf.org
https://w=
ww.ietf.org/mailman/listinfo/spasm




--=_alternative 005F716E85257FB3_=--


From nobody Sat May 14 12:04:41 2016
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 3BFB012D1C0; Sat, 14 May 2016 12:04:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.699
X-Spam-Level: 
X-Spam-Status: No, score=-0.699 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08w8XjwYkpUh; Sat, 14 May 2016 12:04:36 -0700 (PDT)
Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAE5712D0C3; Sat, 14 May 2016 12:04:36 -0700 (PDT)
Received: from hebrews (c-24-21-96-37.hsd1.or.comcast.net [24.21.96.37]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id D623C2C9F8; Sat, 14 May 2016 12:04:35 -0700 (PDT)
From: "Jim Schaad" 
To: "'Tom Gindin'" 
References: <064101d1ad9f$798f3a10$6cadae30$@augustcellars.com> <201605141722.u4EHMaua000470@d03av03.boulder.ibm.com>
In-Reply-To: <201605141722.u4EHMaua000470@d03av03.boulder.ibm.com>
Date: Sat, 14 May 2016 12:04:34 -0700
Message-ID: <06a801d1ae13$747d37b0$5d77a710$@augustcellars.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_06A9_01D1ADD8.C8203470"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQFraw2R3jw97XtuB4EqadgIDOvUfAHNFASNoHbmivA=
Content-Language: en-us
Archived-At: 
Cc: spasm@ietf.org, draft-housley-spasm-eku-constraints@ietf.org
Subject: Re: [Spasm] Comments on draft-housley-spasm-eku-constraints-00
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 14 May 2016 19:04:40 -0000

This is a multipart message in MIME format.

------=_NextPart_000_06A9_01D1ADD8.C8203470
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

While the EKU extension is not listed as being an AA cert extension in RFC
5755, I can easily envision cases where one would put an EKU extension in an
AA certificate to restrict the permitted usages of that AA certificate.

 

I would not want to rule it out from future usage.

 

Yes, I would expect that the justification text would be along those lines.
I would like to see something along the lines of you cannot do X if you use
the old method and you can with the new method as well.  After all, this
document is changing the existing behavior in a significant number of places
and thus needs some solid reasons to do so other than "We think this is a
better idea".

 

Jim

 

 

From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Tom Gindin
Sent: Saturday, May 14, 2016 10:23 AM
To: Jim Schaad 
Cc: spasm@ietf.org; draft-housley-spasm-eku-constraints@ietf.org
Subject: Re: [Spasm] Comments on draft-housley-spasm-eku-constraints-00

 

        Jim:

        On point 1, do AC's actually contain EKU extensions?  Your points 2
and 3 appear to need another initialization variable to replace Russ'
proposal in 3.2 (L).  That variable would be (J)
initial-permitted-key-purpose-ids replacing the null in Russ' 3.1, and would
be "a set of key purpose ID's permitted in extendedKeyUsage extensions
appearing within the certification path".  The initial value in Russ'
proposal should probably be anyExtendedKeyUsage (already defined in 5280),
and that would be the suggested default for this variable as well.
        My own justification text for point 4 would be something like "This
extension is defined as separate from the extendedKeyUsage extension in
order to avoid conflicts between the natural interpretation of that
extension as constraining the behavior of the certificate subject and use as
a path constraint.  Some current software uses the extendedKeyUsage
extension within any issuer certificate as a path constraint, while RFC 5280
4.2.1.12 states that in general it appears only in EE certificates."

Tom Gindin
P.S.        The above suggestions are mine, and not necessarily those of my
employer.



From:        "Jim Schaad"  >
To:         >
Cc:        spasm@ietf.org  
Date:        05/14/2016 01:14 AM
Subject:        [Spasm] Comments on draft-housley-spasm-eku-constraints-00
Sent by:        "Spasm"  >

  _____  




Russ,

I have a few comments on your draft.

1. I believe that doing the restriction to just CA certificates is
incorrect.  I believe that this is just as useful for an AA certificate.  I
would request that this restriction be relaxed and potentially removed.

2.  I believe that in section 3.1 an application should be able to require
that an EKU be permitted.  This seems to be a logical location to specified
that.  This is commonly done for Microsoft in saying that this root may be
used for specific key usages but not for others.

3.  I believe that step (p) (1) is missing a step, although it could
potentially go into step (h) in section 3.5
                (2) if excludedKeyPurposesIds is present in the certificate,
set the
excluded_key_purpose_ids state varble to..   Set the permittedKeyPurposeIds
to the intersection of the result from step (1) and the inverse of the
excludedKeyPurposesIds.

                (3) if the excludedKeyPurposesId is the empty set, then fail
the
validation procedure

                The certificate should be considered invalid regardless of
the
presence of the EKU extension in the EE certificate.

4.  I recognize that this is the method that you feel is correct.  However,
justification text about why the current method used by Msft et al is not
correct is probably required.  At a minimum a recognition that this has been
the Msft behavior since day 1 is needed.

Jim







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






------=_NextPart_000_06A9_01D1ADD8.C8203470
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


While the =
EKU extension is not listed as being an AA cert extension in RFC 5755, I =
can easily envision cases where one would put an EKU extension in an AA =
certificate to restrict the permitted usages of that AA =
certificate.
 
I would not =
want to rule it out from future usage.
 
Yes, I would =
expect that the justification text would be along those lines.  I =
would like to see something along the lines of you cannot do X if you =
use the old method and you can with the new method as well.  After =
all, this document is changing the existing behavior in a significant =
number of places and thus needs some solid reasons to do so other than =
“We think this is a better idea”.
 
Jim
 
 
From:<=
/b> =
Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Tom =
Gindin
Sent: Saturday, May 14, 2016 10:23 AM
To: Jim =
Schaad <ietf@augustcellars.com>
Cc: spasm@ietf.org; =
draft-housley-spasm-eku-constraints@ietf.org
Subject: Re: =
[Spasm] Comments on =
draft-housley-spasm-eku-constraints-00
 
        =
Jim:

  =
      On point 1, do AC's actually contain EKU =
extensions?  Your points 2 and 3 appear to need another =
initialization variable to replace Russ' proposal in 3.2 (L).  That =
variable would be (J) initial-permitted-key-purpose-ids replacing the =
null in Russ' 3.1, and would be "a set of key purpose ID's =
permitted in extendedKeyUsage extensions appearing within the =
certification path".  The initial value in Russ' proposal =
should probably be anyExtendedKeyUsage (already defined in 5280), and =
that would be the suggested default for this variable as =
well.
    =
    My own justification text for point 4 would be something =
like "This extension is defined as separate from the =
extendedKeyUsage extension in order to avoid conflicts between the =
natural interpretation of that extension as constraining the behavior of =
the certificate subject and use as a path constraint.  Some current =
software uses the extendedKeyUsage extension within any issuer =
certificate as a path constraint, while RFC 5280 4.2.1.12 states that in =
general it appears only in EE certificates."

Tom =
Gindin
P.S.        The above suggestions =
are mine, and not necessarily those of my =
employer.



Fr=
om:        "Jim =
Schaad" <ietf@augustcellars.com>
To=
:        <draft-housle=
y-spasm-eku-constraints@ietf.org>
Cc=
:        spasm@ietf.org
Da=
te:        05/14/2016 =
01:14 AM
Su=
bject:        [Spasm] =
Comments on draft-housley-spasm-eku-constraints-00
Se=
nt by:        "Spasm"=
; <spasm-bounces@ietf.org>



Russ,

I have =
a few comments on your draft.

1. I believe that doing =
the restriction to just CA certificates is
incorrect. =
 I believe that this is just as useful for an AA certificate. =
 I
would request that this restriction be relaxed and =
potentially removed.

2.  I believe that in section =
3.1 an application should be able to require
that an EKU be =
permitted.  This seems to be a logical location to =
specified
that.  This is commonly done for Microsoft in =
saying that this root may be
used for specific key usages =
but not for others.

3.  I believe that step (p) (1) =
is missing a step, although it could
potentially go into =
step (h) in section 3.5
          =
      (2) if excludedKeyPurposesIds is present in the =
certificate, set the
excluded_key_purpose_ids state varble =
to..   Set the permittedKeyPurposeIds
to the =
intersection of the result from step (1) and the inverse of =
the
excludedKeyPurposesIds.

    =
            (3) if the =
excludedKeyPurposesId is the empty set, then fail =
the
validation procedure

    =
            The certificate should be =
considered invalid regardless of the
presence of the EKU =
extension in the EE certificate.

4.  I recognize =
that this is the method that you feel is correct. =
 However,
justification text about why the current =
method used by Msft et al is not
correct is probably =
required.  At a minimum a recognition that this has =
been
the Msft behavior since day 1 is =
needed.

Jim







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




------=_NextPart_000_06A9_01D1ADD8.C8203470--


From nobody Sun May 15 01:41:28 2016
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 46F0A12D148 for ; Sun, 15 May 2016 01:41:27 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, 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 shcczWaG0OOa for ; Sun, 15 May 2016 01:41:25 -0700 (PDT)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (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 AC50412D101 for ; Sun, 15 May 2016 01:41:25 -0700 (PDT)
Received: from [192.168.123.151] (unknown [75.83.2.34]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id C71B0509B5; Sun, 15 May 2016 04:41:23 -0400 (EDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_FC317969-9E4B-4791-A7BE-4AF5EC3E467D"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Sean Leonard 
In-Reply-To: 
Date: Sun, 15 May 2016 01:41:22 -0700
Message-Id: <525695C6-FFFD-475A-B434-7E673362AA3F@seantek.com>
References:      <028101d18f60$dd6262e0$982728a0$@augustcellars.com>  <3851E218-C5F4-4BB3-B9DB-B8679361A2B9@seantek.com> 
To: Wei Chuang 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: spasm@ietf.org, Alexey Melnikov , Jim Schaad , Russ Housley 
Subject: Re: [Spasm] [pkix] [smime] Support for email address internationalization in RFC5280 certificates
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 15 May 2016 08:41:27 -0000

--Apple-Mail=_FC317969-9E4B-4791-A7BE-4AF5EC3E467D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


> On May 13, 2016, at 12:09 PM, Wei Chuang  wrote:
>=20
> [Restarting and moving this thread to spasm]
>=20
> Hi all,
>=20
> I think there's general interest in using =
draft-ietf-pkix-eai-addresses-00 =
 to =
document supporting EAI local part i.e. to use a new GeneralNames =
otherNames type with UTF8 email address local part.  That said, there =
are some remaining issues from the previous thread:
>=20
> On Wed, Apr 6, 2016 at 3:48 PM, Sean Leonard > wrote:
> To be clear, the otherName form (draft-ietf-pkix-eai-addresses-00) is =
a sensible path forward. That is how GeneralName was designed to be =
extended all along.
>=20
> Russ corrected me offline and pointed out that GeneralName is =
=E2=80=9Cowned=E2=80=9D (well, created originally anyway) by ITU-T =
X.509. It is not an IETF-originated extension.
>=20
> In order to add a new otherName type in GeneralName which appears to =
be "owned" by ITU-T, does this then requires coordination with ITU-T?

No, it does not.

However, once some EAI mechanism is finalized, the ITU-T should be =
informed because X.509 directs people to encode e-mail addresses in =
rfc822Name.

(See also Russ Housley=E2=80=99s response.)

Sean


--Apple-Mail=_FC317969-9E4B-4791-A7BE-4AF5EC3E467D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


On May 13, 2016, at 12:09 PM, Wei Chuang <weihaw@google.com> =
wrote:

[Restarting and moving this thread to spasm]

Hi all,

I think there's general =
interest in using draft-ietf-pkix-eai-addresses-00 to document supporting =
EAI local part i.e. to use a new GeneralNames otherNames type with UTF8 =
email address local part.  That said, there are some remaining =
issues from the previous thread:

On Wed, Apr 6, 2016 at 3:48 PM, =
Sean Leonard <dev+ietf@seantek.com> wrote:
To be clear, the otherName form (draft-ietf-pkix-eai-addresses-00) is a sensible path forward. That is how GeneralName was designed to be =
extended all along.

Russ corrected me offline and pointed out that GeneralName is =
=E2=80=9Cowned=E2=80=9D (well, created originally anyway) by ITU-T =
X.509. It is not an IETF-originated extension.

In order to add a new otherName type in =
GeneralName which appears to be "owned" by ITU-T, does this then =
requires coordination with =
ITU-T?

No, it does not.

However, once some EAI mechanism is finalized, the =
ITU-T should be informed because X.509 directs people to encode e-mail =
addresses in rfc822Name.

(See also =
Russ Housley=E2=80=99s response.)

Sean

=

--Apple-Mail=_FC317969-9E4B-4791-A7BE-4AF5EC3E467D--


From nobody Sun May 15 03:36:24 2016
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 4E1ED12B068 for ; Sun, 15 May 2016 03:36:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hERSvOVeyWW4 for ; Sun, 15 May 2016 03:36:21 -0700 (PDT)
Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::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 25A6912B059 for ; Sun, 15 May 2016 03:36:21 -0700 (PDT)
Received: by mail-wm0-x232.google.com with SMTP id a17so93968623wme.0 for ; Sun, 15 May 2016 03:36:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=bSfjzwys8P8NT1Ylf0QUNN06heY8H4WHPjz8ZY9St2U=; b=GU0w4pNGkQdJaNRejFiN4UotFCo0KyPRpi57MYzzv9njwS0wDMc6Urbyw7TeD5ge4z gVULQDLZ1+0uJVZrz/1pw4Kv4qK8B/IyPv/PX2TTYgLCulA9bWcgpgfdTb14nNqsmAGV BJZc/SNpiEUFasx6GO275erQSDwcmNAVyxqmO7P7Q0c+dlTYZBx16ICO9u5O+lVXjDSN y0kvupGom+s5LzehIvYHlR5cNqK5AN7d57himqqBituukOoCtRMBy0bTVvzpRo/MekMv sAeZYeYnLGXUTEZAQrbHX48EOK0ggQBNy7eugIYRFNfnsQZBhWdyyAQARKNC9wpiP/Wl 88Tg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=bSfjzwys8P8NT1Ylf0QUNN06heY8H4WHPjz8ZY9St2U=; b=eweFupV3tpLCS1kwRLK/LoP80Jdew3kwKkjac9RiFEmoC5C28A3m5sPvUkuRtq6YmP Fjl1F/O9VgI/kLPfBEc74On4XK8W1hcRQChGjK7na4SCr9IsZff5MlNIKIMnN+zMzLep 0PiKvatyZMeU8xFieuQGhBmCL4hyI/IyZjdj/FiTyO8Z4jzlIoxYweGFq6B4A1xRf9MR 9DCRk8u0I9AjQV+hsMKD8Q0/V8Mm1bT5eTSxB1U/yLPrm1BLbj8u2DQ43BMVwiRj9TKB wJR4RLTKtrHRGdy2nNRqSIhmjbQHXTq6SrJJ4BTVzhS3UWrbtVrLqkH2jiCoPvcXZZx1 HbUQ==
X-Gm-Message-State: AOPr4FWOEiIqklGlMvpBu5K/S9QaYjyDzABuKQOj8D4FvClhoggqIoRTHPBAiRwQcPOzSw==
X-Received: by 10.28.158.79 with SMTP id h76mr11807176wme.79.1463308579586; Sun, 15 May 2016 03:36:19 -0700 (PDT)
Received: from [172.24.249.66] (dyn32-131.checkpoint.com. [194.29.32.131]) by smtp.gmail.com with ESMTPSA id n66sm12661842wmn.7.2016.05.15.03.36.18 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 15 May 2016 03:36:18 -0700 (PDT)
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: multipart/signed; boundary="Apple-Mail=_40C9C70B-9FBF-49CD-845E-A18E0D707DE9"; protocol="application/pgp-signature"; micalg=pgp-sha256
X-Pgp-Agent: GPGMail 2.6b2
From: Yoav Nir 
In-Reply-To: <5737247E.9050309@cs.tcd.ie>
Date: Sun, 15 May 2016 13:36:16 +0300
Message-Id: <7DC616B5-B30C-4FEB-AFF7-1E84FF070D20@gmail.com>
References: <5737247E.9050309@cs.tcd.ie>
To: Stephen Farrell 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: spasm@ietf.org
Subject: Re: [Spasm] formal chartering started...
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 15 May 2016 10:36:23 -0000

--Apple-Mail=_40C9C70B-9FBF-49CD-845E-A18E0D707DE9
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

The proposed charter seems good to me.

One question: For each of items 2, 3, and 4 there is exactly one =
candidate draft, and I don=E2=80=99t know if Alexey wishes to pursue his =
5-year-old draft for #1.

Wouldn=E2=80=99t it be better to say in the charter text =E2=80=9Cdraft-xx=
x is the starting point for the WG document=E2=80=9D rather than =
=E2=80=9Cdraft-xxx is a proposal in this space=E2=80=9D ? I mean we are =
still before all charter bikeshedding, so if someone doesn=E2=80=99t =
like one of these drafts as a starting point, they can speak up now. =
Otherwise the working group would need to have another round of =E2=80=9Cd=
o we want to adopt this as a starting point, or does someone want to =
submit their own version?=E2=80=9D

Yoav

> On 14 May 2016, at 4:13 PM, Stephen Farrell =
 wrote:
>=20
>=20
> Hiya,
>=20
> Thanks all for submitting drafts and discussing the technical
> issues, both good things to see. I've started the formal bit
> of chartering - see the current text at [1]. I modified that
> a little from the last one sent to the list, changes were mostly
> editorial I think other than adding the proposal from John to
> try out another certificate retrieval thing. (I'd be fine with
> that being something that is adopted or not depending on whether
> we figure there's a chance of real deployment, so e.g. if John
> comes away from the M3AAWG meeting with a few email providers
> who say they'd try that, then the WG could include it, but if
> not, it could be dropped. I'm fine that we don't block on finding
> out about that so long as a decision is made soonish, based on
> whether or not we think real deployments or experiments would
> be done.)
>=20
> Anyway, please comment on the text at [1] in the next week (with
> OLD/NEW text please) and after that I'll push it into IESG informal
> evaluation for June 2nd. =46rom then, all going well, the WG might
> end up being formally created about June 16th.
>=20
> If you think the text at [1] is good enough as-is (and it does
> not need to be perfect:-) then a few folks saying so in response
> to this is useful, particularly if you are not the author of any
> of the drafts mentioned in the charter as possible starting
> points. So if you've just been watching or hope to get this WG
> to charter some other work later, you might wanna +1 this if
> that's what you think.
>=20
> Cheers,
> S.
>=20
> [1] https://datatracker.ietf.org/doc/charter-ietf-spasm/
>=20
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm


--Apple-Mail=_40C9C70B-9FBF-49CD-845E-A18E0D707DE9
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----

iQEcBAEBCAAGBQJXOFEgAAoJECXR4BOacZZUstIIAOSbX5fiGTJZZmlMgj35B5r9
72o1hUiYxsqJCRsC+McvANed9yu2ytgNkYW6PvneBlBWDGewqASvtSy+sUuufZ0T
MMyvm8GhUYMj4mMerBXWrOGRb5ecyppqqCXeTBTDy4QT8eH3BSSefgO5PEKj7EKS
LWdkM0Q3A+vnRFXLwAXhmUA/YM8WL5cPojRvyKz/bwQjDZNVO/WwuRzS/l2vDqSh
TjNYJBPwhROYAQRrU7AunlwZGi2iJNTw3B+9XFrqgC4rnocry6W5hVDkeuLlSON2
ry8lKie85QFoxi9wBGjlETyo3tGzehmQYgmrGBTaQCOG6u8RqueOjz/wvVZqfLI=
=JHSs
-----END PGP SIGNATURE-----

--Apple-Mail=_40C9C70B-9FBF-49CD-845E-A18E0D707DE9--


From nobody Sun May 15 05:14:50 2016
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 AB13712D169 for ; Sun, 15 May 2016 05:14:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.727
X-Spam-Level: 
X-Spam-Status: No, score=-5.727 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=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 ec5RFlG7JOzQ for ; Sun, 15 May 2016 05:14:46 -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 4428912B037 for ; Sun, 15 May 2016 05:14:45 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 61D10BE33; Sun, 15 May 2016 13:14:43 +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 shBaY9DT5fEe; Sun, 15 May 2016 13:14:41 +0100 (IST)
Received: from [10.87.48.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 7D801BE2F; Sun, 15 May 2016 13:14:41 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1463314481; bh=JEuIUQ5HZDdQ2FJ4U8xS6PoW1mYpSAMwsNVc2A/eQBQ=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=3TnoAxQPLmJVB8rrjLuO3VEitnk1O7U9I9bsFaV+Fdt5NWox/+/JbZ6/w0jFlnwTx JQmqWkKwGpT180NbJejStAzPcJvKjOr6yP0v6odezqtPkwJ8vGxNFzJ+/NvV8EuR2m KqEtr7eDC++ViBGjSBU0ByTxWI1Sezlu1ljUS9WA=
To: Yoav Nir 
References: <5737247E.9050309@cs.tcd.ie> <7DC616B5-B30C-4FEB-AFF7-1E84FF070D20@gmail.com>
From: Stephen Farrell 
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <57386830.1020303@cs.tcd.ie>
Date: Sun, 15 May 2016 13:14:40 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <7DC616B5-B30C-4FEB-AFF7-1E84FF070D20@gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="84g0qntH6qH31JMIgkKoTWrHv5JbbnxC5"
Archived-At: 
Cc: spasm@ietf.org
Subject: Re: [Spasm] formal chartering started...
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 15 May 2016 12:14:49 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--84g0qntH6qH31JMIgkKoTWrHv5JbbnxC5
Content-Type: multipart/mixed; boundary="s9wNHMR1nRRaPTWmwmfqPIqBFIOOrWqqU"
From: Stephen Farrell 
To: Yoav Nir 
Cc: spasm@ietf.org
Message-ID: <57386830.1020303@cs.tcd.ie>
Subject: Re: [Spasm] formal chartering started...
References: <5737247E.9050309@cs.tcd.ie>
 <7DC616B5-B30C-4FEB-AFF7-1E84FF070D20@gmail.com>
In-Reply-To: <7DC616B5-B30C-4FEB-AFF7-1E84FF070D20@gmail.com>

--s9wNHMR1nRRaPTWmwmfqPIqBFIOOrWqqU
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



On 15/05/16 11:36, Yoav Nir wrote:
> The proposed charter seems good to me.

Great.

>=20
> One question: For each of items 2, 3, and 4 there is exactly one
> candidate draft, and I don=E2=80=99t know if Alexey wishes to pursue hi=
s
> 5-year-old draft for #1.
>=20
> Wouldn=E2=80=99t it be better to say in the charter text =E2=80=9Cdraft=
-xxx is the
> starting point for the WG document=E2=80=9D rather than =E2=80=9Cdraft-=
xxx is a
> proposal in this space=E2=80=9D ? I mean we are still before all charte=
r
> bikeshedding, so if someone doesn=E2=80=99t like one of these drafts as=
 a
> starting point, they can speak up now. Otherwise the working group
> would need to have another round of =E2=80=9Cdo we want to adopt this a=
s a
> starting point, or does someone want to submit their own version?=E2=80=
=9D

In this case, I think that last question would be a good one to
ask after WG formation. But if there's a groundswell of support now
for exactly those drafts as starting points for the WG, then I'd be
ok with that too. I just didn't want to presume that was the case.

Cheers,
S.

>=20
> Yoav
>=20
>> On 14 May 2016, at 4:13 PM, Stephen Farrell
>>  wrote:
>>=20
>>=20
>> Hiya,
>>=20
>> Thanks all for submitting drafts and discussing the technical=20
>> issues, both good things to see. I've started the formal bit of
>> chartering - see the current text at [1]. I modified that a little
>> from the last one sent to the list, changes were mostly editorial I
>> think other than adding the proposal from John to try out another
>> certificate retrieval thing. (I'd be fine with that being something
>> that is adopted or not depending on whether we figure there's a
>> chance of real deployment, so e.g. if John comes away from the
>> M3AAWG meeting with a few email providers who say they'd try that,
>> then the WG could include it, but if not, it could be dropped. I'm
>> fine that we don't block on finding out about that so long as a
>> decision is made soonish, based on whether or not we think real
>> deployments or experiments would be done.)
>>=20
>> Anyway, please comment on the text at [1] in the next week (with=20
>> OLD/NEW text please) and after that I'll push it into IESG
>> informal evaluation for June 2nd. From then, all going well, the WG
>> might end up being formally created about June 16th.
>>=20
>> If you think the text at [1] is good enough as-is (and it does not
>> need to be perfect:-) then a few folks saying so in response to
>> this is useful, particularly if you are not the author of any of
>> the drafts mentioned in the charter as possible starting points. So
>> if you've just been watching or hope to get this WG to charter some
>> other work later, you might wanna +1 this if that's what you
>> think.
>>=20
>> Cheers, S.
>>=20
>> [1] https://datatracker.ietf.org/doc/charter-ietf-spasm/
>>=20
>> _______________________________________________ Spasm mailing list=20
>> Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm
>=20
>=20
>=20
> _______________________________________________ Spasm mailing list=20
> Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm
>=20


--s9wNHMR1nRRaPTWmwmfqPIqBFIOOrWqqU--

--84g0qntH6qH31JMIgkKoTWrHv5JbbnxC5
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJXOGgxAAoJEC88hzaAX42ibrIH/2Og7Q7J2Ujw5VF7d2aTUAAV
w8nj5GTvoUrS5+vLdjxmGnEap4Vt3Z26346GMOLPUciqsUjUwkASRfHZQgKs7BBx
0U5/kiylLG2EcBTcwW7T8SPrrCHX3y3YHyXW9iXOrIAaLkaF43vqwbVft9DTyHYt
ShNhYnqzPSa1ohh1pOkztwB/FUdZoX0GGfmXVKIfH8ltPHQcKrswK/2Q4xhg5hB/
hGUfh7+TSFfOvPI1OabFrGup8BvDu9AufUQTMkUymT1upAUCh0W/OfdDGtAAci7r
bug5rC2Dx87HjlDMcjZ9ErMG86BwHSOmeRhs2orlZYu6Zp9TIH4g19XNDCwvmdE=
=bFSM
-----END PGP SIGNATURE-----

--84g0qntH6qH31JMIgkKoTWrHv5JbbnxC5--


From nobody Sun May 15 10:15:53 2016
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 D127612D1E4 for ; Sun, 15 May 2016 10:15:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.126
X-Spam-Level: 
X-Spam-Status: No, score=-4.126 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, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 TVeFL-fpILSA for ; Sun, 15 May 2016 10:15:49 -0700 (PDT)
Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::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 5B07112D1DA for ; Sun, 15 May 2016 10:15:49 -0700 (PDT)
Received: by mail-oi0-x22a.google.com with SMTP id k142so238813529oib.1 for ; Sun, 15 May 2016 10:15:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=aiM8YP9TP+WfCvnHitdKGQjM44dIWqSkFDHTDS48Iok=; b=eWIHEmZ/yVc+46AX9FghDS62eK6KTaaDgKWAAXKkTide6At2ZdnE/BwYfc405AH6c4 LRU6XyObsn9JxyQztokEdi9is7OfuepiTq/te0q8YOH1JTSkHNmhQTZaSuQGtJ1msDxr AV4FI5pe/y4KmNurqiXKrBWE6h4kQvJPb8AymbdLeo5ODRECliwpeApe68b0wNiqpGoN YIqUsoWeMj4dnGyiWuZ0DRp/Hw4GUhf08Se/kKzDbr2IeAjg6NajsodCkSElCBIeT1QM fQ+BFaNdu5BbOeYsJkkvRLDNwtOL0ZIH/9ioQRsAGWLCa8kl2xaci4DYb+r70DGKx1OA ep9w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=aiM8YP9TP+WfCvnHitdKGQjM44dIWqSkFDHTDS48Iok=; b=KGwlDcbaTQwqdROHUqsxVxeaRg8X3v8RQqhw36MFGKR9EiGEaBiQzUf5DkMoaUMrmX 2zrxeSIwTuViafk59rEqHhJ1fxnI4+APckTpICtQDOrUSsXOf8kAD+qeODEPaDOM5bDi J+jZlv/PCD2nRapiOGYlOQkP46LNBU1CRPCW5l2LijaBtG/KNGkmyYZar/52Qz1n5Whn //qj7uS5ocANnZEAC/IG7aiCdlCiHbuwdAEVu3xKKJhImS5ZXU8JQXIszxfj2pSX3qBs wAaGfQnb01U+13cqvd03Q+N8zHkKzy51ueIRZvSda4Y7tUcIGdIjDsxyyQgbA6E7t0np n18A==
X-Gm-Message-State: AOPr4FWwUqhkml6GpPpQxPECW+Tejxe5nbID+bHYkzsj4lp+qs7n3gCFF49jk9eENexdr1nVwsEFIDsOPqZsRspq
X-Received: by 10.157.43.29 with SMTP id o29mr3172516otb.94.1463332548593; Sun, 15 May 2016 10:15:48 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.157.32.202 with HTTP; Sun, 15 May 2016 10:15:47 -0700 (PDT)
In-Reply-To: <7DC616B5-B30C-4FEB-AFF7-1E84FF070D20@gmail.com>
References: <5737247E.9050309@cs.tcd.ie> <7DC616B5-B30C-4FEB-AFF7-1E84FF070D20@gmail.com>
From: Wei Chuang 
Date: Sun, 15 May 2016 10:15:47 -0700
Message-ID: 
To: Yoav Nir 
Content-Type: multipart/alternative; boundary=001a1141da40bf88d20532e4a84f
Archived-At: 
Cc: spasm@ietf.org, Stephen Farrell 
Subject: Re: [Spasm] formal chartering started...
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 15 May 2016 17:15:52 -0000

--001a1141da40bf88d20532e4a84f
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On Sun, May 15, 2016 at 3:36 AM, Yoav Nir  wrote:

> The proposed charter seems good to me.
>
> One question: For each of items 2, 3, and 4 there is exactly one candidate
> draft, and I don’t know if Alexey wishes to pursue his 5-year-old draft for
> #1.
>

I ping'ed Alexey, and he says he should be able to update the draft.

-Wei


>
> Wouldn’t it be better to say in the charter text “draft-xxx is the
> starting point for the WG document” rather than “draft-xxx is a proposal in
> this space” ? I mean we are still before all charter bikeshedding, so if
> someone doesn’t like one of these drafts as a starting point, they can
> speak up now. Otherwise the working group would need to have another round
> of “do we want to adopt this as a starting point, or does someone want to
> submit their own version?”
>
> Yoav
>
> > On 14 May 2016, at 4:13 PM, Stephen Farrell 
> wrote:
> >
> >
> > Hiya,
> >
> > Thanks all for submitting drafts and discussing the technical
> > issues, both good things to see. I've started the formal bit
> > of chartering - see the current text at [1]. I modified that
> > a little from the last one sent to the list, changes were mostly
> > editorial I think other than adding the proposal from John to
> > try out another certificate retrieval thing. (I'd be fine with
> > that being something that is adopted or not depending on whether
> > we figure there's a chance of real deployment, so e.g. if John
> > comes away from the M3AAWG meeting with a few email providers
> > who say they'd try that, then the WG could include it, but if
> > not, it could be dropped. I'm fine that we don't block on finding
> > out about that so long as a decision is made soonish, based on
> > whether or not we think real deployments or experiments would
> > be done.)
> >
> > Anyway, please comment on the text at [1] in the next week (with
> > OLD/NEW text please) and after that I'll push it into IESG informal
> > evaluation for June 2nd. From then, all going well, the WG might
> > end up being formally created about June 16th.
> >
> > If you think the text at [1] is good enough as-is (and it does
> > not need to be perfect:-) then a few folks saying so in response
> > to this is useful, particularly if you are not the author of any
> > of the drafts mentioned in the charter as possible starting
> > points. So if you've just been watching or hope to get this WG
> > to charter some other work later, you might wanna +1 this if
> > that's what you think.
> >
> > Cheers,
> > S.
> >
> > [1] https://datatracker.ietf.org/doc/charter-ietf-spasm/
> >
> > _______________________________________________
> > 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
>
>

--001a1141da40bf88d20532e4a84f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit




On Sun, May 15, 2016 at 3:36 AM, Yoav Nir <ynir.ietf@gmail.com> wrote:
The proposed charter seems good to me.



One question: For each of items 2, 3, and 4 there is exactly one candidate draft, and I don’t know if Alexey wishes to pursue his 5-year-old draft for #1.

I ping'ed Alexey, and he says he should be able to update the draft.

-Wei
 



Wouldn’t it be better to say in the charter text “draft-xxx is the starting point for the WG document” rather than “draft-xxx is a proposal in this space” ? I mean we are still before all charter bikeshedding, so if someone doesn’t like one of these drafts as a starting point, they can speak up now. Otherwise the working group would need to have another round of “do we want to adopt this as a starting point, or does someone want to submit their own version?”



Yoav




> On 14 May 2016, at 4:13 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:

>

>

> Hiya,

>

> Thanks all for submitting drafts and discussing the technical

> issues, both good things to see. I've started the formal bit

> of chartering - see the current text at [1]. I modified that

> a little from the last one sent to the list, changes were mostly

> editorial I think other than adding the proposal from John to

> try out another certificate retrieval thing. (I'd be fine with

> that being something that is adopted or not depending on whether

> we figure there's a chance of real deployment, so e.g. if John

> comes away from the M3AAWG meeting with a few email providers

> who say they'd try that, then the WG could include it, but if

> not, it could be dropped. I'm fine that we don't block on finding

> out about that so long as a decision is made soonish, based on

> whether or not we think real deployments or experiments would

> be done.)

>

> Anyway, please comment on the text at [1] in the next week (with

> OLD/NEW text please) and after that I'll push it into IESG informal

> evaluation for June 2nd. From then, all going well, the WG might

> end up being formally created about June 16th.

>

> If you think the text at [1] is good enough as-is (and it does

> not need to be perfect:-) then a few folks saying so in response

> to this is useful, particularly if you are not the author of any

> of the drafts mentioned in the charter as possible starting

> points. So if you've just been watching or hope to get this WG

> to charter some other work later, you might wanna +1 this if

> that's what you think.

>

> Cheers,

> S.

>

> [1] https://datatracker.ietf.org/doc/charter-ietf-spasm/

>


> _______________________________________________

> 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





--001a1141da40bf88d20532e4a84f--


From nobody Sun May 15 11:22:40 2016
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 882A112D0AF for ; Sun, 15 May 2016 11:22:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 1Fzg_P9mY26l for ; Sun, 15 May 2016 11:22:37 -0700 (PDT)
Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::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 2E0FA12D51F for ; Sun, 15 May 2016 11:22:37 -0700 (PDT)
Received: by mail-wm0-x22f.google.com with SMTP id g17so104506736wme.1 for ; Sun, 15 May 2016 11:22:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=jPvu1t07Qa+vBuWFGxOqo18aJ6fsN7y7f2GhewKHmsc=; b=Vb+hMcenH9NnH7TH5YcrWGtXqnc5ffQfPjuNgf1gvUn4uOYblHysdz7mCT25E4zttF hEJKXFHss7+aJzZZDAtfnV6ppGzcE73q7uejKI1TIS0JVR2nWiBsk9Q0fNm082aHLZ+z 1Q0P3RLtFyyfOjcAdc03f+setGtTyzUmK2/nTt02IoG5azX6X0tXFsFW6hg4XJA0onlZ PxlHiMvl9zXXAE2DnaP0eyh3VEYC7IzOA6LwUAyo6FNHGk6+2xbchzoGNd+Yw7dYz+8B 4lbfU0U5BcvihV6//i7Ii2LqYHbTKdk/5DTchMvzzoEyWZQSnPpqiphm5AdvfIA+JBVz yeSg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=jPvu1t07Qa+vBuWFGxOqo18aJ6fsN7y7f2GhewKHmsc=; b=md6SKasKxqGsgUAG2zdEAzl5V8sGfSw1sEF0ynf4gUC2PIIeHHW3TVm4YUv4LDKCa6 YGH2rddn7ZWRsAisdVt/woRAnBMffDx1rEphHdsfe+2vthtfO19n8p8L5AJSilOfW9qP Fw+LSC2G+KvgjXiIp5A37MioP7woFxgF7hZHwZx28kBj6iOtW1nz7FlSihlhdhB7f/zN qB9ZwAVwF0PAtJIywWzJmSz7fzvM4TES5gN9pKVoGRHqRR6zBaxNUPp9FOejmDtDBST5 id6KvVnUCq7OORPSctBDxE1gC05Xsp5FN9wPDJ/A4fVlYQso7BGTCF2i/b1RQRRlQ+NP 0wMA==
X-Gm-Message-State: AOPr4FWPf/CewHtLrUldbxROrJmUnXdhQ293MdY6HdR8fBVwwyLVxMWtiO4UMG+VTGe+tw==
X-Received: by 10.28.194.69 with SMTP id s66mr14490905wmf.88.1463336555769; Sun, 15 May 2016 11:22:35 -0700 (PDT)
Received: from [192.168.1.12] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id f8sm29683226wjm.13.2016.05.15.11.22.34 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 15 May 2016 11:22:35 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_3B349BF9-6B95-4685-A28D-FA0AD2E0B67B"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Yoav Nir 
In-Reply-To: 
Date: Sun, 15 May 2016 21:22:33 +0300
Message-Id: 
References: <5737247E.9050309@cs.tcd.ie> <7DC616B5-B30C-4FEB-AFF7-1E84FF070D20@gmail.com> 
To: Wei Chuang 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: spasm@ietf.org, Stephen Farrell 
Subject: Re: [Spasm] formal chartering started...
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 15 May 2016 18:22:38 -0000

--Apple-Mail=_3B349BF9-6B95-4685-A28D-FA0AD2E0B67B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


> On 15 May 2016, at 8:15 PM, Wei Chuang  wrote:
>=20
>=20
>=20
> On Sun, May 15, 2016 at 3:36 AM, Yoav Nir > wrote:
> The proposed charter seems good to me.
>=20
> One question: For each of items 2, 3, and 4 there is exactly one =
candidate draft, and I don=E2=80=99t know if Alexey wishes to pursue his =
5-year-old draft for #1.
>=20
> I ping'ed Alexey, and he says he should be able to update the draft.

I=E2=80=99m sure he can, but do we need two drafts?

Yoav


--Apple-Mail=_3B349BF9-6B95-4685-A28D-FA0AD2E0B67B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


On 15 May 2016, at 8:15 PM, Wei Chuang <weihaw@google.com> =
wrote:



On =
Sun, May 15, 2016 at 3:36 AM, Yoav Nir <ynir.ietf@gmail.com> wrote:
The proposed charter =
seems good to me.

One question: For each of =
items 2, 3, and 4 there is exactly one candidate draft, and I don=E2=80=99=
t know if Alexey wishes to pursue his 5-year-old draft for #1.

I ping'ed Alexey, and he says he should be able to update the =
draft.

I=E2=80=
=99m sure he can, but do we need two drafts?

Yoav

=

--Apple-Mail=_3B349BF9-6B95-4685-A28D-FA0AD2E0B67B--


From nobody Sun May 15 17:42:56 2016
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 6692612D57A for ; Sun, 15 May 2016 17:42:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.126
X-Spam-Level: 
X-Spam-Status: No, score=-4.126 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, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 SLhuuxySp2mu for ; Sun, 15 May 2016 17:42:53 -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 2D0AC12D571 for ; Sun, 15 May 2016 17:42:53 -0700 (PDT)
Received: by mail-oi0-x22c.google.com with SMTP id x201so246928106oif.3 for ; Sun, 15 May 2016 17:42:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=iWz077e0fl+cLu531upRdRmS81LUrqokpx70ZQ+V01o=; b=cXcAuwSFwo6k3JAg4pWTDHjLw+dqH65FkZtD8szQ/S8uh/7fTA0ZqquqlM+DfVWCc2 a7WECs8dQqfqMaSQXlqysQkNtf4safNl4eQuv2brF2lcSChJenU7gxSo2D8Vzby1cEgx p8d2SegpRwiuYrSObxg7RI8L7RxrVoR4l0i+jz0kkLUGnkdIVbKbz6QXiKSs55kfs5PR LP8Fhx7+EHNrvyoXpahsuhF13P7PcuZfFyBHsGwwEXkSeGSzpCmTxxdBkVzC6JWuFb6C SLMd7+snAIjp7R3msrl4XRZ5LLCNui70gIUeqwEDEKIhhT8iUDlnQWnG4lStfIKA/AbS aLfg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=iWz077e0fl+cLu531upRdRmS81LUrqokpx70ZQ+V01o=; b=g9AweSsfMg+XnzgJmbTWgA6M3ky/8jzs0jnqI7yixzT9EYtbgexFK6DRc8lPA4zP0s qM3VIYW6SJBHpRnSKWc2W4cnspqOxOovnKj75L9m3Whgo4COAXnLspXjMQX+EQ6uHeBU ShKXy9dauZyeWhvNw3WmRaKU/4Uet2O1Nui/yAmfQTNDSnxg75rbjv+40a5cwrlz5vKp XwWOcHAk7gp4lb1UGmmmQ9doi68qVUzoRSNUFZTrW/kubj75D1YCtY9wqTGZ8IUWCcU1 vyr1R3XIbj8wKoWLYR6pVQNOai1x37JKveJHaM69e6biWath3QeMfgbL8ZkYGYS9+bAn S9+w==
X-Gm-Message-State: AOPr4FUtcQhJmy8JuBg5uJ5CpiM4Jhs1ngaC7MOMRW0z5prSV/VSZiSN0VoWNVKupTVcnFVVRfpM1+YqXBZPZQzZ
X-Received: by 10.157.36.110 with SMTP id p101mr14691252ota.29.1463359372417;  Sun, 15 May 2016 17:42:52 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.157.32.202 with HTTP; Sun, 15 May 2016 17:42:51 -0700 (PDT)
In-Reply-To: 
References: <5737247E.9050309@cs.tcd.ie> <7DC616B5-B30C-4FEB-AFF7-1E84FF070D20@gmail.com>  
From: Wei Chuang 
Date: Sun, 15 May 2016 17:42:51 -0700
Message-ID: 
To: Yoav Nir 
Content-Type: multipart/alternative; boundary=001a113b0c34929feb0532eae784
Archived-At: 
Cc: spasm@ietf.org, Stephen Farrell 
Subject: Re: [Spasm] formal chartering started...
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 16 May 2016 00:42:54 -0000

--001a113b0c34929feb0532eae784
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On Sun, May 15, 2016 at 11:22 AM, Yoav Nir  wrote:

>
> On 15 May 2016, at 8:15 PM, Wei Chuang  wrote:
>
>
>
> On Sun, May 15, 2016 at 3:36 AM, Yoav Nir  wrote:
>
>> The proposed charter seems good to me.
>>
>> One question: For each of items 2, 3, and 4 there is exactly one
>> candidate draft, and I don’t know if Alexey wishes to pursue his 5-year-old
>> draft for #1.
>>
>
> I ping'ed Alexey, and he says he should be able to update the draft.
>
>
> I’m sure he can, but do we need two drafts?
>

One draft is fine.  The community preference is for
draft-ietf-pkix-eai-addresses over draft-lbaudoin-iemax, and so the charter
should specify the former over the latter.  (I'm one of the authors of the
latter)

-Wei


> Yoav
>
>

--001a113b0c34929feb0532eae784
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit




On Sun, May 15, 2016 at 11:22 AM, Yoav Nir <ynir.ietf@gmail.com> wrote:

On 15 May 2016, at 8:15 PM, Wei Chuang <weihaw@google.com> wrote:



On Sun, May 15, 2016 at 3:36 AM, Yoav Nir <ynir.ietf@gmail.com> wrote:
The proposed charter seems good to me.

One question: For each of items 2, 3, and 4 there is exactly one candidate draft, and I don’t know if Alexey wishes to pursue his 5-year-old draft for #1.

I ping'ed Alexey, and he says he should be able to update the draft.

I’m sure he can, but do we need two drafts?

One draft is fine.  The community preference is for draft-ietf-pkix-eai-addresses over draft-lbaudoin-iemax, and so the charter should specify the former over the latter.  (I'm one of the authors of the latter)

-Wei


Yoav




--001a113b0c34929feb0532eae784--


From nobody Sun May 15 18:13:06 2016
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 470C512B026 for ; Sun, 15 May 2016 18:13:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5xdMhsBAaCsP for ; Sun, 15 May 2016 18:13:02 -0700 (PDT)
Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::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 15DF912B01F for ; Sun, 15 May 2016 18:13:02 -0700 (PDT)
Received: by mail-qk0-x234.google.com with SMTP id x7so88003146qkd.3 for ; Sun, 15 May 2016 18:13:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=COrfFdUwDHwkP575ADz81zAwGI7nzGZPbZjrsItFHKc=; b=kwkjPS/ZspSGd2K/kPLmhheFXoAJo57Mhe1s//jxerPbi2aagXqpQguJ1C4vd3O6X8 ezWqZ36hGCpe0/ndcRFztVcTNdH/oYqsCXRzjXrZNHjSQX1qoXqaVdBanAeSIeEfZ5X+ 40UwCNQD3IXv9YP3KBQDOWJaFdqNgp7XYwJo1Ws54NMYM+hNjxzeFcu+VA/Z4Of5QdP4 n07SLFFlKJixUZpZXhWv2GtAqRxWSAZmtFsk9muvutoaiLo8cqyixT6Ngbqc66fl8YTt tGaJTfKIMbne6Ie828/UXcSVvFI/apLYJgUCHhJNtC2zC8Jh6EFElB064G8oTuCGDuEN io1g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=COrfFdUwDHwkP575ADz81zAwGI7nzGZPbZjrsItFHKc=; b=F4g7r2K8Up7XH7Kv39fvI/RNT7tbFZdGpuLbQntQJ2iZ8cmu8Bown6WMzGlHurS3Qe J/5PfWzGPwpGil28j666BzW/x3Xwbs/blSMBja4Le1Nhsw2oJ12DFVsPEV3lLy+Xa758 DqE+axqPYzc26/HRDjFPkW9C2+BN0gfcG92ahww2md5RvfVFSVuXIAQO9j0310JsVhAJ 5rK+LmjSeMMvLc3cl9YMWc72u71KJRqgcDcadvc5bN4glGrr2NV9F3bF9H/TSK+lDXVn Of/QjBMRle2H0cit7VxSy58QOCFFH0EDHwkpGw2MOP/31s61aBGObB2MA1B/C8EqYg/A CXVQ==
X-Gm-Message-State: AOPr4FVyzeQ+JvjQtH71F7LT0C0lHfdiB7fJPbBvxtoplGlq3h8CfU04xwlFXq4A2oogqw==
X-Received: by 10.55.192.71 with SMTP id o68mr10530229qki.27.1463361181246; Sun, 15 May 2016 18:13:01 -0700 (PDT)
Received: from SantoshBrain (pool-108-31-66-4.washdc.fios.verizon.net. [108.31.66.4]) by smtp.gmail.com with ESMTPSA id g52sm13782971qgf.32.2016.05.15.18.13.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 15 May 2016 18:13:00 -0700 (PDT)
From: "Santosh Chokhani" 
To: "'Russ Housley'" , 
References: <316ECF88-612A-4131-8A96-E5F76671929A@vigilsec.com>
In-Reply-To: <316ECF88-612A-4131-8A96-E5F76671929A@vigilsec.com>
Date: Sun, 15 May 2016 21:12:57 -0400
Message-ID: <044a01d1af10$1548b8c0$3fda2a40$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQG9AVJW+Y7xpWAUdsUf0IIYfjAqNJ/kGBKQ
Content-Language: en-us
Archived-At: 
Subject: Re: [Spasm] My take on handling EKU constraints
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 16 May 2016 01:13:05 -0000

Hi Russ,

Thanks for doing this.

Here are my comments on the draft.

1.  You are requiring the extension to be critical.  This may cause denial
of service during the transition stage while the application implement the
processing logic.  May be start with RECOMMENDED to be critical and then
transition to SHALL be critical when there is wider support for the
extension.

2.  The language at the end of Section 2 regarding extension processing and
tying it to criticality does not seem right to me.  Criticality of extension
should not impact its processing  It also relates to my concerns regarding
wrap up procedure in Section 3.  I would like the criticality part removed.

3.  Now to the wrap up procedure in Section 3, I would recommend taking an
intersection of permitted EKU Constraint State and EKU in the end
certificate and then deleting the EKUs in the result that are in the
excluded EKU Constraint State.  Now, the resulting EKU set should be
returned to the application for enforcement.  It is quite possible that some
applications do not care about EKUs at all.  I could live with if the group
decides if the resulting EKU set is null, it is a path validation failure.
But, my preference is for the application to enforce it.

I will let you respond to Jim Schaad, but I do not either understand his
comments or I do not agree with him.

On 1, to my knowledge the AA certificate is the end certificate in PKI
certification path and hence I do not see how EKU constraints in that
certificate is applicable.

On 2, I have some empathy, but that can also be enforced by the application
per what I suggest above.  I do not have any objection to Jim's approach
either.

I do not get his 3.  I see the path validation engine and associated state
variables accurate.

-----Original Message-----
From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Russ Housley
Sent: Friday, May 13, 2016 7:18 PM
To: spasm@ietf.org
Subject: [Spasm] My take on handling EKU constraints

Review and comment are most welcome.

Russ

= = = = = = = = = =

A new version of I-D, draft-housley-spasm-eku-constraints-00.txt
has been successfully submitted by Russell Housley and posted to the IETF
repository.

Name:		draft-housley-spasm-eku-constraints
Revision:	00
Title:		Extended Key Usage Constraints
Document date:	2016-05-13
Group:		Individual Submission
Pages:		5
URL:
https://www.ietf.org/internet-drafts/draft-housley-spasm-eku-constraints-00.
txt
Status:
https://datatracker.ietf.org/doc/draft-housley-spasm-eku-constraints/
Htmlized:
https://tools.ietf.org/html/draft-housley-spasm-eku-constraints-00


Abstract:
  This document specifies the extended key usage constraints
  certificate extension, which is used to place restrictions on the key
  purpose identifiers that are authorized to appear in subsequent
  certificates in a certification path.  Restrictions apply to the
  extended key usage certificate extension, which is described in RFC
  5280.

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


From nobody Sun May 15 18:35:08 2016
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 B6D7C12D56D for ; Sun, 15 May 2016 18:35:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ImuUKQ3nm3hK for ; Sun, 15 May 2016 18:35:05 -0700 (PDT)
Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::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 CD82812B071 for ; Sun, 15 May 2016 18:35:04 -0700 (PDT)
Received: by mail-qk0-x22b.google.com with SMTP id n63so88188367qkf.0 for ; Sun, 15 May 2016 18:35:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=Iwt9/sFS5t3p7KNdORbc/uyKCDOAgI6kz8nH2YX6NCk=; b=0aDxAY6vJO7btoqtAc/bpPd1ZOPCcT4gjY78I5bwTnOQMdDMix6xErGoF9htriSmGs GPQTNXJB6F5rraik2rOY7YAfffyKWXvBuNRZ5B6BNTKMvfSLPlqiyu54yNbnS0n0pBf6 SCx4qWUVK51+5Ydn6lPgLRqnoGk/g/x1e2UFsPHflw3UpS75mcjPONcvgUJLHZN2Xzye s2/UXYaSn10i6ILt3xapiJIaLHReHuPXZPySnl/YKsJU7qF79LD0L+BydVC4GnO3W8Wu hfeXrW+2txD/TBCnSEeGR07/bTuLWbHQC1eBAdeWujUSDOX3xU5rvY5qnU2km4usgQtc JtoQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=Iwt9/sFS5t3p7KNdORbc/uyKCDOAgI6kz8nH2YX6NCk=; b=P+pmUqKmi8Om2ch/O7Gjl4SjFs139kY44p+aCO7w0d62nl6xkdtZ96Wp1uYcbkQf5G diX3uQDF3DCnfp1lBPUMcKjoJyjBj5ynK49e02XLU9NArXLbSvc9xlrNr+OvNmpNlXzu sby1MuUY0Ct73gQFURhu6s4tewmrmecq0lRNnIIx8hZe9PYq1UjX1QOsAx1rdrajFvWu 8lBSsWRs8UN1dwRPV4ov+e1rp+WgUxDnwuqnZ++eZVmofwVCfM3WEkGjVQbLkAuF5b33 FerVSObhhIqpNCuIK8WfMg3RHt4U9ILeou6pXZr+5sNNWCrRf+ywhJQPcdnimysFUR5/ qrXA==
X-Gm-Message-State: AOPr4FX0xVtpvvBIrChijHA/6HtK9Le5E0Ivx1ENg3xQSI2fDJtqEnhS8UuWSepAPIWxDA==
X-Received: by 10.55.53.79 with SMTP id c76mr29224194qka.54.1463362503953; Sun, 15 May 2016 18:35:03 -0700 (PDT)
Received: from SantoshBrain (pool-108-31-66-4.washdc.fios.verizon.net. [108.31.66.4]) by smtp.gmail.com with ESMTPSA id a6sm13745116qhd.33.2016.05.15.18.35.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 15 May 2016 18:35:03 -0700 (PDT)
From: "Santosh Chokhani" 
To: "'Russ Housley'" , 
References: <316ECF88-612A-4131-8A96-E5F76671929A@vigilsec.com> <044a01d1af10$1548b8c0$3fda2a40$@gmail.com>
In-Reply-To: <044a01d1af10$1548b8c0$3fda2a40$@gmail.com>
Date: Sun, 15 May 2016 21:34:57 -0400
Message-ID: <045901d1af13$29d85d60$7d891820$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQG9AVJW+Y7xpWAUdsUf0IIYfjAqNAGVztXGn9dzOXA=
Content-Language: en-us
Archived-At: 
Subject: Re: [Spasm] My take on handling EKU constraints
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 16 May 2016 01:35:07 -0000

One more comment.

The I-D should address anyExtendedKeyUsage.  Either it should be prohibited
from the permitted or excluded or the path validation engine should treat
this value in either field as the UNIVERSAL set.

Ideally path validation engine will address it for both fields and the I-D
would discourage its assertion in either field.  I could see some value in
its assertion in excluded field, though.

-----Original Message-----
From: Santosh Chokhani [mailto:santosh.chokhani@gmail.com] 
Sent: Sunday, May 15, 2016 9:13 PM
To: 'Russ Housley' ; spasm@ietf.org
Subject: RE: [Spasm] My take on handling EKU constraints

Hi Russ,

Thanks for doing this.

Here are my comments on the draft.

1.  You are requiring the extension to be critical.  This may cause denial
of service during the transition stage while the application implement the
processing logic.  May be start with RECOMMENDED to be critical and then
transition to SHALL be critical when there is wider support for the
extension.

2.  The language at the end of Section 2 regarding extension processing and
tying it to criticality does not seem right to me.  Criticality of extension
should not impact its processing  It also relates to my concerns regarding
wrap up procedure in Section 3.  I would like the criticality part removed.

3.  Now to the wrap up procedure in Section 3, I would recommend taking an
intersection of permitted EKU Constraint State and EKU in the end
certificate and then deleting the EKUs in the result that are in the
excluded EKU Constraint State.  Now, the resulting EKU set should be
returned to the application for enforcement.  It is quite possible that some
applications do not care about EKUs at all.  I could live with if the group
decides if the resulting EKU set is null, it is a path validation failure.
But, my preference is for the application to enforce it.

I will let you respond to Jim Schaad, but I do not either understand his
comments or I do not agree with him.

On 1, to my knowledge the AA certificate is the end certificate in PKI
certification path and hence I do not see how EKU constraints in that
certificate is applicable.

On 2, I have some empathy, but that can also be enforced by the application
per what I suggest above.  I do not have any objection to Jim's approach
either.

I do not get his 3.  I see the path validation engine and associated state
variables accurate.

-----Original Message-----
From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Russ Housley
Sent: Friday, May 13, 2016 7:18 PM
To: spasm@ietf.org
Subject: [Spasm] My take on handling EKU constraints

Review and comment are most welcome.

Russ

= = = = = = = = = =

A new version of I-D, draft-housley-spasm-eku-constraints-00.txt
has been successfully submitted by Russell Housley and posted to the IETF
repository.

Name:		draft-housley-spasm-eku-constraints
Revision:	00
Title:		Extended Key Usage Constraints
Document date:	2016-05-13
Group:		Individual Submission
Pages:		5
URL:
https://www.ietf.org/internet-drafts/draft-housley-spasm-eku-constraints-00.
txt
Status:
https://datatracker.ietf.org/doc/draft-housley-spasm-eku-constraints/
Htmlized:
https://tools.ietf.org/html/draft-housley-spasm-eku-constraints-00


Abstract:
  This document specifies the extended key usage constraints
  certificate extension, which is used to place restrictions on the key
  purpose identifiers that are authorized to appear in subsequent
  certificates in a certification path.  Restrictions apply to the
  extended key usage certificate extension, which is described in RFC
  5280.

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



From nobody Sun May 15 18:45:05 2016
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 F06FD12D585 for ; Sun, 15 May 2016 18:45:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eoM_Pek5CzyT for ; Sun, 15 May 2016 18:45:02 -0700 (PDT)
Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD17F12D09D for ; Sun, 15 May 2016 18:45:01 -0700 (PDT)
Received: by mail-qg0-x231.google.com with SMTP id 90so83545976qgz.1 for ; Sun, 15 May 2016 18:45:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=lMh7C9XBagimDsUZOfAB3gvDKpwksbu071uMbpSaun4=; b=FNsCyL25Bxh5hbcA4OzNwQwuueRR10sf6uxxW5G59RStpce+O9PL1gbQ8cx+cxjrRB Q6iLV8ZatGtmGmddfnxBsJ1kLZSLz83LInOyMs64JGyA9RQtNcbYtdaVoTqTMBtELKeL wo+sxCLIoARhYblstrwwq/vENcohl9uM1l2MuO7XCZr3ggVP437wxePKV4oThw1szet2 7/VZ2uYgVuiTu6UQiFucsQs8GAqo/NOiTHK6WX2Agw9t21skyCO6JkczL2n4gUUNiWLv Zmrd5NsX3OPYacQLj2lyWl3mfJxrE6PLK4Nwu/+Zvv0ZWPsErHMQfAtWyzGv92VsTPmn oLWQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=lMh7C9XBagimDsUZOfAB3gvDKpwksbu071uMbpSaun4=; b=gatXCvW6MNcME7zBzgDVvJM+uDkXURpbxGsGUCKz3Kodbk7Ln4WN2nfP6Mj3NIzPS/ 6mS4uN4KzKW95Y+jh2laS+THxftxi3/uCgKvfuZbIsuxmIooGXlbzatPGc4Nvt5I9Byv eKs1lNFtM+0fX4KjFenh86RfzZ30ZgqbCwIGPHMz9MeBIHAIbnbBf7hi8gyS+ku+Wjgi 3/YQWR4kGgz26b6QxArAet1FnUIl4vO5HKNqUhsWtQMcmCkm7hE/lTOgaHriwwiL+QmR BkthJc8L4F8Z3tuXnwnUsYGu4QJfnyh/gBP8XXc7vkvrtlKQERaNEA0bNNKaclwPTeJL yUAg==
X-Gm-Message-State: AOPr4FXm1qJ69da5R+3OM4Cmn+UsJj+bKPTSxqCW/fCyJUf4Rnwtvv3zCSuXc6Ym6RY8dw==
X-Received: by 10.141.47.66 with SMTP id y63mr28420730qhe.74.1463363100827; Sun, 15 May 2016 18:45:00 -0700 (PDT)
Received: from SantoshBrain (pool-108-31-66-4.washdc.fios.verizon.net. [108.31.66.4]) by smtp.gmail.com with ESMTPSA id a5sm4502161qhb.26.2016.05.15.18.45.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 15 May 2016 18:45:00 -0700 (PDT)
From: "Santosh Chokhani" 
To: "'Russ Housley'" , 
References: <316ECF88-612A-4131-8A96-E5F76671929A@vigilsec.com> <044a01d1af10$1548b8c0$3fda2a40$@gmail.com> <045901d1af13$29d85d60$7d891820$@gmail.com>
In-Reply-To: <045901d1af13$29d85d60$7d891820$@gmail.com>
Date: Sun, 15 May 2016 21:44:57 -0400
Message-ID: <045a01d1af14$8db12aa0$a9137fe0$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQG9AVJW+Y7xpWAUdsUf0IIYfjAqNAGVztXGAdsLs7efyJ2k0A==
Content-Language: en-us
Archived-At: 
Subject: Re: [Spasm] My take on handling EKU constraints
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 16 May 2016 01:45:04 -0000

Sorry for not thinking of one more item:

Some discussion of OCSPSigning EKU in permitted field to accommodate
Delegated OCSP trust model will be useful.  May be in Security
Considerations Section.

-----Original Message-----
From: Santosh Chokhani [mailto:santosh.chokhani@gmail.com] 
Sent: Sunday, May 15, 2016 9:35 PM
To: 'Russ Housley' ; spasm@ietf.org
Subject: RE: [Spasm] My take on handling EKU constraints

One more comment.

The I-D should address anyExtendedKeyUsage.  Either it should be prohibited
from the permitted or excluded or the path validation engine should treat
this value in either field as the UNIVERSAL set.

Ideally path validation engine will address it for both fields and the I-D
would discourage its assertion in either field.  I could see some value in
its assertion in excluded field, though.

-----Original Message-----
From: Santosh Chokhani [mailto:santosh.chokhani@gmail.com]
Sent: Sunday, May 15, 2016 9:13 PM
To: 'Russ Housley' ; spasm@ietf.org
Subject: RE: [Spasm] My take on handling EKU constraints

Hi Russ,

Thanks for doing this.

Here are my comments on the draft.

1.  You are requiring the extension to be critical.  This may cause denial
of service during the transition stage while the application implement the
processing logic.  May be start with RECOMMENDED to be critical and then
transition to SHALL be critical when there is wider support for the
extension.

2.  The language at the end of Section 2 regarding extension processing and
tying it to criticality does not seem right to me.  Criticality of extension
should not impact its processing  It also relates to my concerns regarding
wrap up procedure in Section 3.  I would like the criticality part removed.

3.  Now to the wrap up procedure in Section 3, I would recommend taking an
intersection of permitted EKU Constraint State and EKU in the end
certificate and then deleting the EKUs in the result that are in the
excluded EKU Constraint State.  Now, the resulting EKU set should be
returned to the application for enforcement.  It is quite possible that some
applications do not care about EKUs at all.  I could live with if the group
decides if the resulting EKU set is null, it is a path validation failure.
But, my preference is for the application to enforce it.

I will let you respond to Jim Schaad, but I do not either understand his
comments or I do not agree with him.

On 1, to my knowledge the AA certificate is the end certificate in PKI
certification path and hence I do not see how EKU constraints in that
certificate is applicable.

On 2, I have some empathy, but that can also be enforced by the application
per what I suggest above.  I do not have any objection to Jim's approach
either.

I do not get his 3.  I see the path validation engine and associated state
variables accurate.

-----Original Message-----
From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Russ Housley
Sent: Friday, May 13, 2016 7:18 PM
To: spasm@ietf.org
Subject: [Spasm] My take on handling EKU constraints

Review and comment are most welcome.

Russ

= = = = = = = = = =

A new version of I-D, draft-housley-spasm-eku-constraints-00.txt
has been successfully submitted by Russell Housley and posted to the IETF
repository.

Name:		draft-housley-spasm-eku-constraints
Revision:	00
Title:		Extended Key Usage Constraints
Document date:	2016-05-13
Group:		Individual Submission
Pages:		5
URL:
https://www.ietf.org/internet-drafts/draft-housley-spasm-eku-constraints-00.
txt
Status:
https://datatracker.ietf.org/doc/draft-housley-spasm-eku-constraints/
Htmlized:
https://tools.ietf.org/html/draft-housley-spasm-eku-constraints-00


Abstract:
  This document specifies the extended key usage constraints
  certificate extension, which is used to place restrictions on the key
  purpose identifiers that are authorized to appear in subsequent
  certificates in a certification path.  Restrictions apply to the
  extended key usage certificate extension, which is described in RFC
  5280.

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




From nobody Sun May 15 21:38:03 2016
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 2BA6512B02F for ; Sun, 15 May 2016 21:38:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 SNjPNF73Y5IO for ; Sun, 15 May 2016 21:37:58 -0700 (PDT)
Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::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 B944912D12A for ; Sun, 15 May 2016 21:37:57 -0700 (PDT)
Received: by mail-wm0-x22a.google.com with SMTP id e201so86111076wme.0 for ; Sun, 15 May 2016 21:37:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=I85xlAWKrUUzb22AaqTpehA+u3Tr15ig5pBCCEppge8=; b=XgNjrku65VEGhmHx1nlZgCPsF54MjRkjmpwNqfGZMHOnNuXOjaANWzFcH7TINjJIw1 cXCBYfsL+lnekWHZnEaWszZbgNB/oGP87/hmAS/AVfHEtNxTgdX4FC6gDRd3QKwtgy9q B51+/LPmNR/WJH9R+I7Sm5542PeZ+HtHH27pbpsoSisaUYKIizyp2lpdxCaDtoo7aNNs gLNSsNUNalE+mxYJ8YFp2p6KM+9IERooF1AKe1SqKyPHpsZsF7k9GBt61npM1mABZTwp URWS1rb12GRnNS8F3ldU1wsjR/GXMbIAGIIMETNMsGzyaT0v8KwDuiPNnBOYYYwBPK8/ O4xg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=I85xlAWKrUUzb22AaqTpehA+u3Tr15ig5pBCCEppge8=; b=UrYzT7hKmORmafrRnZ0bkjks07z31XQFgc56zae92iJ54hycmxSdv9kdTgww8ebalE w/sfa/vdiJ0rz4tX0RNWU6FJSCYTnytO8c24ee6vM23gNfz4HauqS2Tbr6MjFT6AoCPH pvj8EgkT+9HgoUtXTavxBvGyqG0qxsabWWDXOv3qjZtTHLD00UlNLj8DYkyNc4X2k17E ElP9AF7C1EXkwwzcd6KRVRNYcCfySbGwfWtcaao9kiPVxmSS632LCta/W72AgJzoeNVa CUHv+YBMVtYSt0bAZaGY1rwuGJUSy2olvoGkvH0j4azGE4jmkSdqE0YP7xNeCsZHsfaP kmNg==
X-Gm-Message-State: AOPr4FUl2ehow9giFRYosWLssVevgVD5kkXLHwAOoG0xC+kxb/b3cg4DZAxK29Uzq9Dudw==
X-Received: by 10.194.64.35 with SMTP id l3mr26593820wjs.180.1463373476067; Sun, 15 May 2016 21:37:56 -0700 (PDT)
Received: from [192.168.1.12] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id l74sm16225111wmb.15.2016.05.15.21.37.54 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 15 May 2016 21:37:55 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_A20EFF98-3E46-4C1B-AAC3-8BBF52E05215"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Yoav Nir 
In-Reply-To: 
Date: Mon, 16 May 2016 07:37:52 +0300
Message-Id: 
References: <5737247E.9050309@cs.tcd.ie> <7DC616B5-B30C-4FEB-AFF7-1E84FF070D20@gmail.com>   
To: Wei Chuang 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: spasm@ietf.org, Stephen Farrell 
Subject: Re: [Spasm] formal chartering started...
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 16 May 2016 04:38:01 -0000

--Apple-Mail=_A20EFF98-3E46-4C1B-AAC3-8BBF52E05215
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


> On 16 May 2016, at 3:42 AM, Wei Chuang  wrote:
>=20
>=20
>=20
> On Sun, May 15, 2016 at 11:22 AM, Yoav Nir > wrote:
>=20
>> On 15 May 2016, at 8:15 PM, Wei Chuang > wrote:
>>=20
>>=20
>>=20
>> On Sun, May 15, 2016 at 3:36 AM, Yoav Nir > wrote:
>> The proposed charter seems good to me.
>>=20
>> One question: For each of items 2, 3, and 4 there is exactly one =
candidate draft, and I don=E2=80=99t know if Alexey wishes to pursue his =
5-year-old draft for #1.
>>=20
>> I ping'ed Alexey, and he says he should be able to update the draft.
>=20
> I=E2=80=99m sure he can, but do we need two drafts?
>=20
> One draft is fine.  The community preference is for =
draft-ietf-pkix-eai-addresses over draft-lbaudoin-iemax, and so the =
charter should specify the former over the latter.  (I'm one of the =
authors of the latter)

Great!

Yoav


--Apple-Mail=_A20EFF98-3E46-4C1B-AAC3-8BBF52E05215
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


On 16 May 2016, at 3:42 AM, Wei Chuang <weihaw@google.com> =
wrote:



On Sun, May 15, 2016 at 11:22 AM, =
Yoav Nir <ynir.ietf@gmail.com> wrote:

On 15 =
May 2016, at 8:15 PM, Wei Chuang <weihaw@google.com> wrote:



On Sun, May 15, 2016 at =
3:36 AM, Yoav Nir <ynir.ietf@gmail.com> wr=
ote:
The proposed charter seems good to me.

One question: For each of items 2, 3, and 4 =
there is exactly one candidate draft, and I don=E2=80=99t know if Alexey =
wishes to pursue his 5-year-old draft for #1.

I ping'ed Alexey, and he says he should be able to update the =
draft.

I=E2=80=99m sure he can, but do we need =
two drafts?

One draft is fine.  The community preference is for =
draft-ietf-pkix-eai-addresses over draft-lbaudoin-iemax, and so =
the charter should specify the former over the latter.  (I'm =
one of the authors of the =
latter)

Great!

Yoav

=

--Apple-Mail=_A20EFF98-3E46-4C1B-AAC3-8BBF52E05215--


From nobody Sun May 15 22:11:12 2016
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 7699012D0B4 for ; Sun, 15 May 2016 22:11:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vHBKPOkkfcQw for ; Sun, 15 May 2016 22:11:08 -0700 (PDT)
Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BC3212D09F for ; Sun, 15 May 2016 22:11:08 -0700 (PDT)
Received: from hebrews (static-50-39-83-102.bvtn.or.frontiernet.net [50.39.83.102]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 7902238F56; Sun, 15 May 2016 22:11:06 -0700 (PDT)
From: "Jim Schaad" 
To: "'Santosh Chokhani'" , "'Russ Housley'" , 
References: <316ECF88-612A-4131-8A96-E5F76671929A@vigilsec.com> <044a01d1af10$1548b8c0$3fda2a40$@gmail.com>
In-Reply-To: <044a01d1af10$1548b8c0$3fda2a40$@gmail.com>
Date: Sun, 15 May 2016 22:11:05 -0700
Message-ID: <000f01d1af31$5a760f80$0f622e80$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQG9AVJW+Y7xpWAUdsUf0IIYfjAqNAGVztXGn9ewjkA=
Content-Language: en-us
Archived-At: 
Subject: Re: [Spasm] My take on handling EKU constraints
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 16 May 2016 05:11:10 -0000

-----Original Message-----
From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Santosh Chokhani
Sent: Sunday, May 15, 2016 6:13 PM
To: 'Russ Housley' ; spasm@ietf.org
Subject: Re: [Spasm] My take on handling EKU constraints

Hi Russ,

Thanks for doing this.

Here are my comments on the draft.

1.  You are requiring the extension to be critical.  This may cause denial
of service during the transition stage while the application implement the
processing logic.  May be start with RECOMMENDED to be critical and then
transition to SHALL be critical when there is wider support for the
extension.

2.  The language at the end of Section 2 regarding extension processing and
tying it to criticality does not seem right to me.  Criticality of extension
should not impact its processing  It also relates to my concerns regarding
wrap up procedure in Section 3.  I would like the criticality part removed.

3.  Now to the wrap up procedure in Section 3, I would recommend taking an
intersection of permitted EKU Constraint State and EKU in the end
certificate and then deleting the EKUs in the result that are in the
excluded EKU Constraint State.  Now, the resulting EKU set should be
returned to the application for enforcement.  It is quite possible that some
applications do not care about EKUs at all.  I could live with if the group
decides if the resulting EKU set is null, it is a path validation failure.
But, my preference is for the application to enforce it.

I will let you respond to Jim Schaad, but I do not either understand his
comments or I do not agree with him.

On 1, to my knowledge the AA certificate is the end certificate in PKI
certification path and hence I do not see how EKU constraints in that
certificate is applicable.

[JLS] The current text states that that the AA certificate could not have an
EKU constraint extension to restrict how the AA certificates that it issues
can be used.  I believe that might be a useful case.

On 2, I have some empathy, but that can also be enforced by the application
per what I suggest above.  I do not have any objection to Jim's approach
either.

I do not get his 3.  I see the path validation engine and associated state
variables accurate.
[JLS] This does two things.  First if the empty permitted set is created,
then you can stop validation immediately and secondly, the EKU constraints
should be enforced even if there is not EKU in the leaf certificate being
validated. 

Jim


-----Original Message-----
From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Russ Housley
Sent: Friday, May 13, 2016 7:18 PM
To: spasm@ietf.org
Subject: [Spasm] My take on handling EKU constraints

Review and comment are most welcome.

Russ

= = = = = = = = = =

A new version of I-D, draft-housley-spasm-eku-constraints-00.txt
has been successfully submitted by Russell Housley and posted to the IETF
repository.

Name:		draft-housley-spasm-eku-constraints
Revision:	00
Title:		Extended Key Usage Constraints
Document date:	2016-05-13
Group:		Individual Submission
Pages:		5
URL:
https://www.ietf.org/internet-drafts/draft-housley-spasm-eku-constraints-00.
txt
Status:
https://datatracker.ietf.org/doc/draft-housley-spasm-eku-constraints/
Htmlized:
https://tools.ietf.org/html/draft-housley-spasm-eku-constraints-00


Abstract:
  This document specifies the extended key usage constraints
  certificate extension, which is used to place restrictions on the key
  purpose identifiers that are authorized to appear in subsequent
  certificates in a certification path.  Restrictions apply to the
  extended key usage certificate extension, which is described in RFC
  5280.

_______________________________________________
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


From nobody Sun May 15 23:17:18 2016
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 4CAA612D09C for ; Sun, 15 May 2016 23:17:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level: 
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, 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 2I9n2cQBK3LE for ; Sun, 15 May 2016 23:17:13 -0700 (PDT)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (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 E4E1B12B03F for ; Sun, 15 May 2016 23:17:12 -0700 (PDT)
Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id CF072509B5 for ; Mon, 16 May 2016 02:17:11 -0400 (EDT)
To: spasm@ietf.org
References: <316ECF88-612A-4131-8A96-E5F76671929A@vigilsec.com>
From: Sean Leonard 
Message-ID: <1b87369d-9812-b5c0-9631-ba9e638fd6d4@seantek.com>
Date: Sun, 15 May 2016 23:16:18 -0700
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0
MIME-Version: 1.0
In-Reply-To: <316ECF88-612A-4131-8A96-E5F76671929A@vigilsec.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [Spasm] My take on handling EKU constraints
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 16 May 2016 06:17:15 -0000

Hello:

In the ASN.1 module (to be written), it's important to specify whether=20
this extension uses IMPLICIT, EXPLICIT, or AUTOMATIC tagging. I am=20
guessing folks don't want to use AUTOMATIC tagging, even though it's=20
recommended by the latest ASN.1 standards because it's "easy". My=20
personal preference is for EXPLICIT tagging. However, the extended key=20
usage extension is defined in the IMPLICIT module in RFC 5280, so it's=20
IMPLICIT...this means that if you want symmetry with the EKU extension,=20
you should say it's IMPLICIT.

Is there a way, using the latest ASN.1 syntax, to specify=20
"either-or-or-both", i.e., the EKUConstraints SEQUENCE must have at=20
least one element, possibly two, but not zero?

As I understand it, "permitted" takes greater precedence over=20
"excluded". I.e., if the extension has both permitted AND excluded, then =

really, only "permitted" is going to have meaningful effect.
1. That is because if a given EKU is on the permitted list but is also=20
on the excluded list, it behaves as if it's not on the permitted list in =

the first place: effectively removing it from permitted.
2. If a given EKU is on the permitted list but NOT on the excluded list, =

then it's permitted: no additional effect.
3. If a given EKU is NOT on the permitted list but IS on the excluded=20
list, then it's excluded, but this is the same as if it were not on the=20
permitted list: no additional effect.
4. If a given EKU is on NEITHER the permitted list NOR the excluded=20
list, this is the same as if it were not on the permitted list: no=20
additional effect.

I could show fancy set theory math but am lazy. ;-)

Given the lazy-proof above, EKUConstraints does not need to be a=20
SEQUENCE. It just needs to be a CHOICE between permittedKeyPurposeIDs=20
and excludedKeyPurposeIDs. When it's tagged [0] on the wire, it means=20
"permitted". When it's tagged [1] on the wire, it means "excluded". QED.

(Note: Instead of expressing EKUConstraints as a CHOICE, we could=20
specify two extensions, identified by id-ce-permittedEKUConstraints and=20
id-ce-excludedEKUConstraints. However I believe that the CHOICE is=20
better because the CHOICE prevents an implementation from stuffing both=20
extensions into a certificate.)

The appropriate ASN.1 standard and version should be referenced. Usually =

we use the 1988 syntax around these parts; however, that standard has=20
been long superseded. Figure out what works for you...it appears that=20
RFC 5280 references X.680 (2002), while 5280 was published in May 2008.

Sean

On 5/13/2016 4:17 PM, Russ Housley wrote:
> Review and comment are most welcome.
>
> Russ
>
> =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D
>
> A new version of I-D, draft-housley-spasm-eku-constraints-00.txt
> has been successfully submitted by Russell Housley and posted to the
> IETF repository.
>
> Name:		draft-housley-spasm-eku-constraints
> Revision:	00
> Title:		Extended Key Usage Constraints
> Document date:	2016-05-13
> Group:		Individual Submission
> Pages:		5
> URL:            https://www.ietf.org/internet-drafts/draft-housley-spas=
m-eku-constraints-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-housley-spasm-ek=
u-constraints/
> Htmlized:       https://tools.ietf.org/html/draft-housley-spasm-eku-con=
straints-00
>
>
> Abstract:
>    This document specifies the extended key usage constraints
>    certificate extension, which is used to place restrictions on the ke=
y
>    purpose identifiers that are authorized to appear in subsequent
>    certificates in a certification path.  Restrictions apply to the
>    extended key usage certificate extension, which is described in RFC
>    5280.
>
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm




From nobody Mon May 16 06:13:46 2016
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 DA75A12D671 for ; Mon, 16 May 2016 06:13:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.327
X-Spam-Level: 
X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r0MWj3KdCClF for ; Mon, 16 May 2016 06:13:43 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 587C612D635 for ; Mon, 16 May 2016 06:13:43 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 76FA1200A3; Mon, 16 May 2016 09:19:32 -0400 (EDT)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id D8637638BE; Mon, 16 May 2016 09:13:41 -0400 (EDT)
From: Michael Richardson 
To: Russ Housley 
In-Reply-To: <316ECF88-612A-4131-8A96-E5F76671929A@vigilsec.com>
References: <316ECF88-612A-4131-8A96-E5F76671929A@vigilsec.com>
X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.4.2
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m
Archived-At: 
Cc: spasm@ietf.org
Subject: Re: [Spasm] My take on handling EKU constraints
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 16 May 2016 13:13:45 -0000

--=-=-=
Content-Type: text/plain


Initial read had me confused by:

  Conforming CAs MUST mark this extension as critical, and conforming
  CAs MUST NOT issue certificates where this extension is an empty
  sequence.  That is, either the permittedKeyPurposeIds field or the
  excludedKeyPurposeIds field MUST be present.

vs:
  If the set is empty, then the
  certification path will be considered invalid if the end-entity
  certificate includes an extended key usage extension

I suggest initial paragraph be changed to:
  Conforming CAs MUST mark this extension as critical, and conforming
  CAs MUST NOT issue certificates where this extension is an empty
  sequence.  That is, either the permittedKeyPurposeIds field or the
  excludedKeyPurposeIds field MUST be present, but the field MAY contain
  an empty set.

typo:
  The initial value is a is the empty set.
  => The initial value is the empty set.

I see the AND/OR operation on permitted/excluded as the chain is walked.
Clearly an intermediate CA may issue an EKU that includes things that the
parent/root CA did not want to include, and that this is an anomaly, but not
an error.

With the SHA1->SHA256 roll I found it interesting that many root CAs
generated new SHA256 keys which they used to sign the intermediate CAs again,
and so one "upgrades" the chain not by replacing the entire chain, but by
just updating the root.  The same thing could be used here, with a root CA
signing an intermediate and providing different EKUs--- depending upon which
chain the validating end has, they could come to different conclusions.

I wonder if some discussion of this is meritted?  Is this a bug or a feature?


--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-




--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEVAwUBVznHg4CLcPvd0N1lAQIXhAf+Lu/XyE9/32zkBkVcHd9gHeaKVRJ56+Ce
5VtRrRADW351Yo56mnqtZ6EWUodj3WUCLHY7OWSYFBq5i/ruF/FZj3xV2Bq8mrm5
gXWMGffFEsIIAQSkuB2JnNkZ+YE0nTEW5peD0WioNoRrI+naG8niMB3IT4YEi6Fb
mPeJpY2TLVNuDBIq6LdfnsE6upyWcBJfk4IqThnMt6VRPmR2TBglr7kB5sFLAIEW
X0OmpZeyu4pxs6hxINXGaITCSI2LiPP5CFKRhiwpv7W1dJ2J3s+jOxu71l9k/1yu
16X6+REmqXqj8B39HxaZu7tSfGqjZgKY0uzDXkBWUaQ0TRym93hiTA==
=YBEj
-----END PGP SIGNATURE-----
--=-=-=--


From nobody Mon May 16 06:18:24 2016
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 9C18712D635; Mon, 16 May 2016 06:18:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.327
X-Spam-Level: 
X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yugr4CgkM-C7; Mon, 16 May 2016 06:18:21 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DD6E12B063; Mon, 16 May 2016 06:18:21 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 03840200A3; Mon, 16 May 2016 09:24:11 -0400 (EDT)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 6D113638BE; Mon, 16 May 2016 09:18:20 -0400 (EDT)
From: Michael Richardson 
To: "Jim Schaad" 
In-Reply-To: <064101d1ad9f$798f3a10$6cadae30$@augustcellars.com>
References: <064101d1ad9f$798f3a10$6cadae30$@augustcellars.com>
X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.4.2
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m
Archived-At: 
Cc: spasm@ietf.org, draft-housley-spasm-eku-constraints@ietf.org
Subject: Re: [Spasm] Comments on draft-housley-spasm-eku-constraints-00
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 16 May 2016 13:18:22 -0000

--=-=-=
Content-Type: text/plain


Jim Schaad  wrote:
    > 2.  I believe that in section 3.1 an application should be able to
    > require that an EKU be permitted.  This seems to be a logical location
    > to specified that.  This is commonly done for Microsoft in saying that
    > this root may be used for specific key usages but not for others.

So, I think you are saying that the application has an EKU list "above" the
CA. (in essence, in the trust store), and that this EKU list would restrict
which roots can even be picked for validation, regardless of what the root's
EKU list says.
I.e. my application trusts VendorFOO for Web anchors, but not javascript signing.

--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-




--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEVAwUBVznImYCLcPvd0N1lAQIIQggArUkCOcGnSykxz4uhVODmMndhBGQXKT5H
Y6ueu6r4vTyiTRl+qtRwcLBF8rvFTmznIbcStTPGOpDrQle+QI3HBJlRXmguvZys
YcwgPWyQDosQdfZhTgeKNmMDJsaIPedmelbvG9BvJ/xi0WBPovqJSPa/ODG+i8vH
rADonWFQuPnWssLDgkwGykIcidcPRjIt/EbHlqSlDsYqTtljnNendSgFdSTaHI90
wNcFrRxuwyneivmlOviAVR+Lr3HBR99C7mm7/NBxEVENcmIb+XaFOJ6rSxc4TfPT
ht5H0EgXG2NAyGwvCviQVkHkfRZx4wGeeZdDMxMOWR+7ndq8dQcYXQ==
=LvkF
-----END PGP SIGNATURE-----
--=-=-=--


From nobody Mon May 16 06:42:59 2016
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 36B7C12D68D for ; Mon, 16 May 2016 06:42:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BOSMi36-8aPo for ; Mon, 16 May 2016 06:42:56 -0700 (PDT)
Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D12312D67F for ; Mon, 16 May 2016 06:42:56 -0700 (PDT)
Received: by mail-qk0-x233.google.com with SMTP id x7so96367876qkd.3 for ; Mon, 16 May 2016 06:42:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=qquzv8WUNB4CLVc23ToY6kO1hhw1+9SlYOVgsuEQI5g=; b=LswBWf85vHO07lbGXWYgljW3LvqUB7Cor5nHIC0fYTq2f9FTIVAeSoQhk8nu7COH/B tYH0x0r7HD8Y+LJRxALc+kdpesmbarnNqnwW3ygHZcvpuokqx2t2MUTROzORecL5eTfI AwNWItLX5o2Hv/u3Km9+XyeivLSYcfwoqTs4ceagi4Rhw9kpCXdKBTp6WUgWkBYI6XoZ c4joFf04awDBbb0nkL1ryviW69QAtelFf/td5cZnZeqyWQSbx6VKp8eOZGDkKCp9TJyC irstiFGc79sJphHf00ioeqi5lf6DWGybIjW/9L8WJuYNXT30/aHxzcD1b6JD/yWsyn5R eW/w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=qquzv8WUNB4CLVc23ToY6kO1hhw1+9SlYOVgsuEQI5g=; b=jj5zWXfVwRlnFReHcB/dnjp7TjBZF5GZtPaGfhzTMJvEZoownA93Wdvi/QwX6KyThl F20LwX0e/I03JgCpVUYl7xVz1kQTu7Wf+HnLaIv3SpPGoixUDozuweHm74MdydADPhG2 UCsC5L6TsEPg7hOLi6EUyO4UaIQ3TI9OX6oS7KPAio/VLJgJp+a9k6Vj1yCU5vmRae1n zGy4Dp02yE01tEMdmvLJ5SJCDkHIsWJMDkuhMkhs1E5aVGWRKBpoK4Y4kdzCaOy0aKHn 9bZePsaO3ydPLS1rKgTAckd+HxAF4iO28grMduHjnrcLUEGsLNXmCBmNuP6fgmOzEu10 rNTA==
X-Gm-Message-State: AOPr4FX5tv8fIgCAktLCJwLR8ZEr4y5G7F7cF3jKA/QtJH4kmq9hd19HHYphL7Vr6fmGxw==
X-Received: by 10.55.40.38 with SMTP id o38mr28671968qkh.156.1463406175125; Mon, 16 May 2016 06:42:55 -0700 (PDT)
Received: from SantoshBrain (pool-108-31-66-4.washdc.fios.verizon.net. [108.31.66.4]) by smtp.gmail.com with ESMTPSA id 77sm14842633qgn.29.2016.05.16.06.42.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 May 2016 06:42:54 -0700 (PDT)
From: "Santosh Chokhani" 
To: "'Jim Schaad'" , "'Russ Housley'" , 
References: <316ECF88-612A-4131-8A96-E5F76671929A@vigilsec.com> <044a01d1af10$1548b8c0$3fda2a40$@gmail.com> <000f01d1af31$5a760f80$0f622e80$@augustcellars.com>
In-Reply-To: <000f01d1af31$5a760f80$0f622e80$@augustcellars.com>
Date: Mon, 16 May 2016 09:42:51 -0400
Message-ID: <054b01d1af78$d79e09d0$86da1d70$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQG9AVJW+Y7xpWAUdsUf0IIYfjAqNAGVztXGAf86bnqfyEOpEA==
Content-Language: en-us
Archived-At: 
Subject: Re: [Spasm] My take on handling EKU constraints
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 16 May 2016 13:42:58 -0000

HI Jim,

See in-line below.

-----Original Message-----
From: Jim Schaad [mailto:ietf@augustcellars.com] 
Sent: Monday, May 16, 2016 1:11 AM
To: 'Santosh Chokhani' ; 'Russ Housley'
; spasm@ietf.org
Subject: RE: [Spasm] My take on handling EKU constraints



-----Original Message-----
From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Santosh Chokhani
Sent: Sunday, May 15, 2016 6:13 PM
To: 'Russ Housley' ; spasm@ietf.org
Subject: Re: [Spasm] My take on handling EKU constraints

Hi Russ,

Thanks for doing this.

Here are my comments on the draft.

1.  You are requiring the extension to be critical.  This may cause denial
of service during the transition stage while the application implement the
processing logic.  May be start with RECOMMENDED to be critical and then
transition to SHALL be critical when there is wider support for the
extension.

2.  The language at the end of Section 2 regarding extension processing and
tying it to criticality does not seem right to me.  Criticality of extension
should not impact its processing  It also relates to my concerns regarding
wrap up procedure in Section 3.  I would like the criticality part removed.

3.  Now to the wrap up procedure in Section 3, I would recommend taking an
intersection of permitted EKU Constraint State and EKU in the end
certificate and then deleting the EKUs in the result that are in the
excluded EKU Constraint State.  Now, the resulting EKU set should be
returned to the application for enforcement.  It is quite possible that some
applications do not care about EKUs at all.  I could live with if the group
decides if the resulting EKU set is null, it is a path validation failure.
But, my preference is for the application to enforce it.

I will let you respond to Jim Schaad, but I do not either understand his
comments or I do not agree with him.

On 1, to my knowledge the AA certificate is the end certificate in PKI
certification path and hence I do not see how EKU constraints in that
certificate is applicable.

[JLS] The current text states that that the AA certificate could not have an
EKU constraint extension to restrict how the AA certificates that it issues
can be used.  I believe that might be a useful case.
[Santosh] I get that.  But, since EKU is part of PKI and not PMI, it would
be better to restrict the end entity.  I have no objection  to plain EKU in
AA certificate.  AA should only constrain the attributes and EKU is not one
of the attributes unless it wanted to do so via defining this as an
attribute in attribute certificate. 

On 2, I have some empathy, but that can also be enforced by the application
per what I suggest above.  I do not have any objection to Jim's approach
either.

I do not get his 3.  I see the path validation engine and associated state
variables accurate.
[JLS] This does two things.  First if the empty permitted set is created,
then you can stop validation immediately and secondly, the EKU constraints
should be enforced even if there is not EKU in the leaf certificate being
validated. 
[Santosh] I am not in favor of causing path validation failure due to empty
EKU.  Some applications do not care.  EKU should be enforced by the
application just like KU.  See my suggestion 3 above for wrap up.  I think
the path validation engine should output EKUs and let the application do the
enforcement.  We do the same for certificate policy unless require explicit
policy state variable gets set by the state machine.  I do not think we want
this added state variable for EKU and initial value and added value in the
extension.  It is better to let the application make its own decision.

Jim


-----Original Message-----
From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Russ Housley
Sent: Friday, May 13, 2016 7:18 PM
To: spasm@ietf.org
Subject: [Spasm] My take on handling EKU constraints

Review and comment are most welcome.

Russ

= = = = = = = = = =

A new version of I-D, draft-housley-spasm-eku-constraints-00.txt
has been successfully submitted by Russell Housley and posted to the IETF
repository.

Name:		draft-housley-spasm-eku-constraints
Revision:	00
Title:		Extended Key Usage Constraints
Document date:	2016-05-13
Group:		Individual Submission
Pages:		5
URL:
https://www.ietf.org/internet-drafts/draft-housley-spasm-eku-constraints-00.
txt
Status:
https://datatracker.ietf.org/doc/draft-housley-spasm-eku-constraints/
Htmlized:
https://tools.ietf.org/html/draft-housley-spasm-eku-constraints-00


Abstract:
  This document specifies the extended key usage constraints
  certificate extension, which is used to place restrictions on the key
  purpose identifiers that are authorized to appear in subsequent
  certificates in a certification path.  Restrictions apply to the
  extended key usage certificate extension, which is described in RFC
  5280.

_______________________________________________
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



From nobody Mon May 16 06:48:12 2016
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 1525812D6BF for ; Mon, 16 May 2016 06:48:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MTy1LoXfVVIE for ; Mon, 16 May 2016 06:48:09 -0700 (PDT)
Received: from mail-qg0-x22e.google.com (mail-qg0-x22e.google.com [IPv6:2607:f8b0:400d:c04::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 F112412D6BD for ; Mon, 16 May 2016 06:48:02 -0700 (PDT)
Received: by mail-qg0-x22e.google.com with SMTP id f92so88703349qgf.0 for ; Mon, 16 May 2016 06:48:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=F4Kt9ypdcuJa8dYk3k+I5RRrG3mrqeNGFyttakaKR9k=; b=euMN5y3fyoB5GyuLw8e358Hd6L6G9jZN4YJVwj95d2napQSLQaYCFPZeZkrGGHE9KW HZnbijsCR2CvW728/b3wPKFa3rxYu3DbzWXcZYjoAvPetDXtkVmMZHHamZO2rG8OWljk rL4aYVXdOWGvSeJBAQI0+wVxFSuGDx5YqDynZSGyaQZbv+ay1P9m5E5oQaXL5WKonZwA ZH1LytZtWWi2rm8HSRoAM3Fl/uVXlUiUxJ6j62hYz+JEN9lyCNvossdzElmPV9MeMDLm gDa7tBMf9LUpT6eUEPezYUoFNJejCLqMuM+s+YX0aHtpe3wFT3Ph0LSPjrmKuMAifbCY mhuw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=F4Kt9ypdcuJa8dYk3k+I5RRrG3mrqeNGFyttakaKR9k=; b=DtKbhmjeif8iT6WlXqs3MKCr2j1Yt37V+SNvDpmPTj7oxRjCoPE6UCQzfx7ZaeZDyB J1WO3qtsmydRPf/yTt4KWZ2nmjIH8i0i6ijOAVKZ/ot0Hcjx2gKIH5jKp4iRZ7dMJcdo kLe8KfBVA5NyG5ZqOAy2RK+6vaNO8FcfBltO6pV8VUx5yqb+am0T50AH8aa4lFc9Vd0p 3InN1LWyrifGUWfW5ZLTGdtva7VBzXy9+9ehOdzNGrbC9IRCNyQ8CFsEPSGqumIgg9ID 5zGek2h7upLqPzcqUzz/Frm4aZdq4LY8VgZ6GxmziAONIlVdH9BE2zbVzWKjuk65cKpF Nqwg==
X-Gm-Message-State: AOPr4FXwZJy6XlreH9xcRsrDDzUZq6qGiZE1FIGYIfpdgEmP8bt0ABuXIKXTiucmCN6wxw==
X-Received: by 10.140.130.77 with SMTP id 74mr30524237qhc.27.1463406482041; Mon, 16 May 2016 06:48:02 -0700 (PDT)
Received: from SantoshBrain (pool-108-31-66-4.washdc.fios.verizon.net. [108.31.66.4]) by smtp.gmail.com with ESMTPSA id 141sm14977993qke.18.2016.05.16.06.48.01 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 May 2016 06:48:01 -0700 (PDT)
From: "Santosh Chokhani" 
To: 
References: <316ECF88-612A-4131-8A96-E5F76671929A@vigilsec.com> <1b87369d-9812-b5c0-9631-ba9e638fd6d4@seantek.com>
In-Reply-To: <1b87369d-9812-b5c0-9631-ba9e638fd6d4@seantek.com>
Date: Mon, 16 May 2016 09:47:57 -0400
Message-ID: <054c01d1af79$8ea69340$abf3b9c0$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQG9AVJW+Y7xpWAUdsUf0IIYfjAqNAJIj4Ren9KpqaA=
Content-Language: en-us
Archived-At: 
Subject: Re: [Spasm] My take on handling EKU constraints
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 16 May 2016 13:48:11 -0000

Hi Sean,

It is more complicated and more flexible than what you say due to the path.

As you go through the path, the permitted can remain the same or only shrink
and excluded can stay the same and grow and at the end you remove from the
end certificate EKU which are not in the permitted state variable and are in
the excluded state variable.

So, what is being proposed here is flexible and secure.

-----Original Message-----
From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Sean Leonard
Sent: Monday, May 16, 2016 2:16 AM
To: spasm@ietf.org
Subject: Re: [Spasm] My take on handling EKU constraints

Hello:

In the ASN.1 module (to be written), it's important to specify whether this
extension uses IMPLICIT, EXPLICIT, or AUTOMATIC tagging. I am guessing folks
don't want to use AUTOMATIC tagging, even though it's recommended by the
latest ASN.1 standards because it's "easy". My personal preference is for
EXPLICIT tagging. However, the extended key usage extension is defined in
the IMPLICIT module in RFC 5280, so it's IMPLICIT...this means that if you
want symmetry with the EKU extension, you should say it's IMPLICIT.

Is there a way, using the latest ASN.1 syntax, to specify
"either-or-or-both", i.e., the EKUConstraints SEQUENCE must have at least
one element, possibly two, but not zero?

As I understand it, "permitted" takes greater precedence over "excluded".
I.e., if the extension has both permitted AND excluded, then really, only
"permitted" is going to have meaningful effect.
1. That is because if a given EKU is on the permitted list but is also on
the excluded list, it behaves as if it's not on the permitted list in the
first place: effectively removing it from permitted.
2. If a given EKU is on the permitted list but NOT on the excluded list,
then it's permitted: no additional effect.
3. If a given EKU is NOT on the permitted list but IS on the excluded list,
then it's excluded, but this is the same as if it were not on the permitted
list: no additional effect.
4. If a given EKU is on NEITHER the permitted list NOR the excluded list,
this is the same as if it were not on the permitted list: no additional
effect.

I could show fancy set theory math but am lazy. ;-)

Given the lazy-proof above, EKUConstraints does not need to be a SEQUENCE.
It just needs to be a CHOICE between permittedKeyPurposeIDs and
excludedKeyPurposeIDs. When it's tagged [0] on the wire, it means
"permitted". When it's tagged [1] on the wire, it means "excluded". QED.

(Note: Instead of expressing EKUConstraints as a CHOICE, we could specify
two extensions, identified by id-ce-permittedEKUConstraints and
id-ce-excludedEKUConstraints. However I believe that the CHOICE is better
because the CHOICE prevents an implementation from stuffing both extensions
into a certificate.)

The appropriate ASN.1 standard and version should be referenced. Usually we
use the 1988 syntax around these parts; however, that standard has been long
superseded. Figure out what works for you...it appears that RFC 5280
references X.680 (2002), while 5280 was published in May 2008.

Sean

On 5/13/2016 4:17 PM, Russ Housley wrote:
> Review and comment are most welcome.
>
> Russ
>
> = = = = = = = = = =
>
> A new version of I-D, draft-housley-spasm-eku-constraints-00.txt
> has been successfully submitted by Russell Housley and posted to the 
> IETF repository.
>
> Name:		draft-housley-spasm-eku-constraints
> Revision:	00
> Title:		Extended Key Usage Constraints
> Document date:	2016-05-13
> Group:		Individual Submission
> Pages:		5
> URL:
https://www.ietf.org/internet-drafts/draft-housley-spasm-eku-constraints-00.
txt
> Status:
https://datatracker.ietf.org/doc/draft-housley-spasm-eku-constraints/
> Htmlized:
https://tools.ietf.org/html/draft-housley-spasm-eku-constraints-00
>
>
> Abstract:
>    This document specifies the extended key usage constraints
>    certificate extension, which is used to place restrictions on the key
>    purpose identifiers that are authorized to appear in subsequent
>    certificates in a certification path.  Restrictions apply to the
>    extended key usage certificate extension, which is described in RFC
>    5280.
>
> _______________________________________________
> 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


From nobody Mon May 16 07:02:11 2016
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 0A75312D177 for ; Mon, 16 May 2016 07:02:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.727
X-Spam-Level: 
X-Spam-Status: No, score=-5.727 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=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 evVgSGFaG1Cp for ; Mon, 16 May 2016 07:02:00 -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 D921212D16E for ; Mon, 16 May 2016 07:01:59 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 4860ABE29; Mon, 16 May 2016 15:01:58 +0100 (IST)
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NTa_qejTwF7K; Mon, 16 May 2016 15:01:58 +0100 (IST)
Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id A47ECBDF9; Mon, 16 May 2016 15:01:57 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1463407318; bh=DP8IcJh51nY/M/BAu4HKSBy6c7+14LRsrYWFN4GRUpk=; h=Subject:To:References:From:Date:In-Reply-To:From; b=RzQsLZRuMbTz5SrXAkXnNIxy8SzrGhlUJw/qwArY+cL3LzPzisspXeU3jDORv3M6A UsklHtqktplhHJRPkqsGgsRhPaPyvA057V/jxHyXYeLQ9O47ciUB3kimtvAOD3kshH FKNfHHJTSlhYrQraMNgEfeZkH1Bd9WMiQMhpNu8g=
To: Santosh Chokhani , 'Jim Schaad' , 'Russ Housley' , spasm@ietf.org
References: <316ECF88-612A-4131-8A96-E5F76671929A@vigilsec.com> <044a01d1af10$1548b8c0$3fda2a40$@gmail.com> <000f01d1af31$5a760f80$0f622e80$@augustcellars.com> <054b01d1af78$d79e09d0$86da1d70$@gmail.com>
From: Stephen Farrell 
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <5739D2D5.8020809@cs.tcd.ie>
Date: Mon, 16 May 2016 15:01:57 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <054b01d1af78$d79e09d0$86da1d70$@gmail.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms020509070906040002080903"
Archived-At: 
Subject: Re: [Spasm] My take on handling EKU constraints
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 16 May 2016 14:02:10 -0000

This is a cryptographically signed message in MIME format.

--------------ms020509070906040002080903
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


Hi Santosh,

A sort of meta comment below...

On 16/05/16 14:42, Santosh Chokhani wrote:
> [Santosh] I am not in favor of causing path validation failure due to e=
mpty
> EKU.  Some applications do not care.  EKU should be enforced by the
> application just like KU.  See my suggestion 3 above for wrap up.  I th=
ink
> the path validation engine should output EKUs and let the application d=
o the
> enforcement.  We do the same for certificate policy unless require expl=
icit
> policy state variable gets set by the state machine.  I do not think we=
 want
> this added state variable for EKU and initial value and added value in =
the
> extension.  It is better to let the application make its own decision.

I hope we all agree that this kind of thing ought be mostly
driven by what those implementing or deploying certificate
validation and applications want and are willing to do and
what they think makes sense in terms of APIs etc. For example,
I wondered which application(s) you are involved in developing
you meant in the above.

One thing I think we need to be quite careful about with all
of this planned work is to not repeat mistakes we (incl. me)
made in the past where we designed a bunch of PKI machinery
that didn't get used, or that made it harder to use PKI, or
that made PKI less useful. There is really no point in us
repeating such mistakes, and again, I hope we all agree on
that.

So I'd much prefer that we see arguments on this that look
more like "In my application/library , I'd prefer we do
it  way, because..."

Cheers,
S.


--------------ms020509070906040002080903
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
CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ
BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD
ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll
bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw
aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA
Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra
C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3
rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5
R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r
dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt
3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw
MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ
QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv
BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5
BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu
Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll
bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc
MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE
MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG
9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD
C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9
U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM
aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai
9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC
BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE
BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs
IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g
QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC
SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC
ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv
mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm
VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4
D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI
dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu
N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE
FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp
MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE
WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG
JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+
SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g
BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv
bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY
0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF
NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9
uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p
6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv
Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu
mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7
RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO
/ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN
JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM
MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG
A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0
Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA
oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA1MTYx
NDAxNTdaMC8GCSqGSIb3DQEJBDEiBCA/EAP5mzkaMcHceaqxP2QBzBOPdVnNbW7ukwST7Zt4
XTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN
AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC
AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw
IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB
nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD
VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq
hkiG9w0BAQEFAASCAQAI1LBoNqiuWjJ74qcWFq0/pwkVndAAv2ZdIix1ciwGshbSjVC7sn/C
X0ot05LL8ypRjEcGjg50pla83wggSCAMqjpcDyf0GtkexqLtXoxGPG+fF3wFLuQvFp3LXu+O
TmT8Kya2LPHeOCoPDui4ZGnbrqg1boqpyeXtD07yDWlOdaRHewVIlnKPXbfKl7+tOQb5oRlB
/QBD67jmQ72OOKzp2LVGTyCOohxzepr8UCy0Wlyaoa4suDMTJF+RfHhsZH+DCJnumWhC96BI
Nm4l5jRlAM5QVCuWbN0QWBeib4zB4Z5kLvnvXBKT6x5KMg9N2PrHltbP5lF1UeLH81/hijU5
AAAAAAAA
--------------ms020509070906040002080903--


From nobody Mon May 16 07:33:08 2016
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 7D81C12B04E; Mon, 16 May 2016 07:33:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.727
X-Spam-Level: 
X-Spam-Status: No, score=-5.727 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=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 BM3ZC0Wo48ZD; Mon, 16 May 2016 07:33:04 -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 258B912D0FC; Mon, 16 May 2016 07:33:04 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 086F2BE29; Mon, 16 May 2016 15:33:03 +0100 (IST)
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yu9IOUeiENNC; Mon, 16 May 2016 15:33:02 +0100 (IST)
Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 82D88BDCF; Mon, 16 May 2016 15:33:02 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1463409182; bh=QKAPuzyyxdbsL+qnrDWBl/HuKTRgCmA19ewkQL788mw=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=N5FiCbhA0F9FwlG4b4dBfVH53ki+loHLT4cMBvZn4wzDB8R2IU97wYY6Ixn/tL52X nMYmuUxYGNZNGoc40zBPDE+idMLIKbIxFrGwSvAR4CKfbCKadANrrHmrNWy2MsjbcF 8EokS5HoqsZqSte5g5AZ/KC52hdU2q00SJs8RvWs=
To: Jim Schaad , draft-housley-spasm-eku-constraints@ietf.org
References: <064101d1ad9f$798f3a10$6cadae30$@augustcellars.com>
From: Stephen Farrell 
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <5739DA1E.2000202@cs.tcd.ie>
Date: Mon, 16 May 2016 15:33:02 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <064101d1ad9f$798f3a10$6cadae30$@augustcellars.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms030804060005090701050907"
Archived-At: 
Cc: spasm@ietf.org
Subject: Re: [Spasm] Comments on draft-housley-spasm-eku-constraints-00
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 16 May 2016 14:33:06 -0000

This is a cryptographically signed message in MIME format.

--------------ms030804060005090701050907
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


Hi Jim,

(In the same spirit as my mail to Santosh a minute ago...)

On 14/05/16 06:14, Jim Schaad wrote:
> 1. I believe that doing the restriction to just CA certificates is
> incorrect.  I believe that this is just as useful for an AA certificate=
=2E  I
> would request that this restriction be relaxed and potentially removed.=


Who operates an AA and wants to use this? If nobody, (as
I suspect), then I'd argue that it'd be better to be
entirely silent about AA's and ACs. If there niches of
networks where ACs are in use, then I don't think this
proposed WG is the place to argue about those, esp as
the folks who might be using that technology aren't
afaik likely to engage here. And if at some point someone
does want to re-use an extension in AA certs, then they
could update the relevant RFC or use another OID. In
the meantime, I would argue that this list does not need
to argue about ACs at all, as doing so would just be
likely wasted effort and distracting. And absent any
real usage, anyone writing code is also better off not
considering ACs at all as such code would for almost
all implementations just be dead code that's likely to
have more bugs than code that gets exercised.

S.


--------------ms030804060005090701050907
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
CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ
BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD
ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll
bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw
aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA
Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra
C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3
rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5
R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r
dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt
3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw
MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ
QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv
BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5
BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu
Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll
bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc
MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE
MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG
9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD
C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9
U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM
aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai
9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC
BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE
BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs
IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g
QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC
SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC
ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv
mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm
VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4
D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI
dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu
N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE
FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp
MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE
WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG
JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+
SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g
BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv
bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY
0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF
NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9
uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p
6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv
Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu
mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7
RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO
/ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN
JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM
MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG
A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0
Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA
oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA1MTYx
NDMzMDJaMC8GCSqGSIb3DQEJBDEiBCBR6WhKsMMSwHrOmmtTE5yQZYQ2ylJe3euxjsowBMG6
9jBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN
AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC
AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw
IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB
nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD
VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq
hkiG9w0BAQEFAASCAQCV0C5SK9qTMKKQxzwbw5JpEFLVia5SyigrLdjW8fYgyJ5XtQkBdL9N
CTavUd7jF5kUz8d96rBDp6JUHA79adr1MxK99d4hA/R5246w48fjSTSqCPn27R/RnEzXziyA
mafI3ivNbcHy4vLkeHpSCZWQ6XnkFNx3GGluyavnOZoGVBe2EP+hYwmnV9gLDBw8hODl41Vu
ebGxRuIE+cMOaHS4xs755+DEK39+dlyVZz/Jam4K7/u73YKkyuETWTUqd/Th3isTLhoFk90P
/4SAXWbLCUDAZ8oIfdvnNQkeqLLPbzBbyKNy5vY8k40bqEcnrvOXLfcr+ze2SldaRdlbVjWj
AAAAAAAA
--------------ms030804060005090701050907--


From nobody Mon May 16 07:43:40 2016
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 A2D1A12D188 for ; Mon, 16 May 2016 07:43:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Level: 
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RU9NgRv6v8yP for ; Mon, 16 May 2016 07:43:37 -0700 (PDT)
Received: from mail.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 590EF12B04E for ; Mon, 16 May 2016 07:43:37 -0700 (PDT)
Received: from localhost (ronin.smetech.net [209.135.209.5]) by mail.smetech.net (Postfix) with ESMTP id 9D55AF24045; Mon, 16 May 2016 10:43:36 -0400 (EDT)
X-Virus-Scanned: amavisd-new at smetech.net
Received: from mail.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id TP9yAUGl2f08; Mon, 16 May 2016 10:26:29 -0400 (EDT)
Received: from [172.26.10.187] (unknown [104.129.194.81]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.smetech.net (Postfix) with ESMTP id 10FBEF24035; Mon, 16 May 2016 10:43:35 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Russ Housley 
In-Reply-To: <064201d1ada1$0b94dc20$22be9460$@augustcellars.com>
Date: Mon, 16 May 2016 10:42:42 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <064201d1ada1$0b94dc20$22be9460$@augustcellars.com>
To: Jim Schaad 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: 
Cc: spasm@ietf.org, draft-ietf-pkix-eai-addresses@ietf.org
Subject: Re: [Spasm] comments on draft-ietf-pkix-eai-addresses-01
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 16 May 2016 14:43:39 -0000

> 3.  A section on name constraints is needed in this document similar =
to the
> text in section 4.2.1.10 in rfc 5280

Yes, indeed.  I think it is pretty clear what needs to be there, but it =
does need to be added.

Russ


From nobody Mon May 16 08:23:26 2016
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 2821912D678 for ; Mon, 16 May 2016 08:23:25 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, 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 qMk0QVmtHkLb for ; Mon, 16 May 2016 08:23:22 -0700 (PDT)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (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 46B3812D1A5 for ; Mon, 16 May 2016 08:23:22 -0700 (PDT)
Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 250E250A87 for ; Mon, 16 May 2016 11:23:20 -0400 (EDT)
To: spasm@ietf.org
References: <316ECF88-612A-4131-8A96-E5F76671929A@vigilsec.com> <1b87369d-9812-b5c0-9631-ba9e638fd6d4@seantek.com> <054c01d1af79$8ea69340$abf3b9c0$@gmail.com>
From: Sean Leonard 
Message-ID: <13faee9b-0571-ce73-d9e3-cd616393e531@seantek.com>
Date: Mon, 16 May 2016 08:22:28 -0700
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0
MIME-Version: 1.0
In-Reply-To: <054c01d1af79$8ea69340$abf3b9c0$@gmail.com>
Content-Type: multipart/alternative; boundary="------------44E3747C11E8E613A1320747"
Archived-At: 
Subject: Re: [Spasm] My take on handling EKU constraints
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 16 May 2016 15:23:25 -0000

This is a multi-part message in MIME format.
--------------44E3747C11E8E613A1320747
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

Hi Santosh,

With respect to the permitted/excluded issue: I read through the draft 
again, and disagree with the assertion that "it is more complicated and 
more flexible than what you say due to the path".

Sure the algorithm is more complicated in draft-00 than what I'm saying, 
but it is not more flexible. The result is the same. The draft says:
Section 3.5:

         (1)  If permitted_key_purpose_ids state variable is not special
              value that represents the universal set, then confirm that
              all of the key purpose identifiers/[in the EKU extension////of the end-entity certificate]/
              are present in the set.
              If any are missing, then returning a failure indication and
              an appropriate reason.


That is the same result. So the structures and algorithms proposed in 
draft-00 are needlessly complicated. (Specifically the structures, and 
enforcement of the structures, are needlessly complicated. I am not sure 
if the algorithm state variables can be reduced; need to think about it 
more. Offhand, I think that it could be shown that you need the same 
state variables as the structure, i.e., one boolean indicating whether 
we are in permitted vs. excluded mode, and one set of key purpose IDs. 
Once the algorithm encounters a "permitted" extension, it should flip 
the boolean from excluded to permitted, and do the difference of the 
excluded IDs to the permitted IDs.)

I request a counter-proof.

Sean

On 5/16/2016 6:47 AM, Santosh Chokhani wrote:
> Hi Sean,
>
> It is more complicated and more flexible than what you say due to the path.
>
> As you go through the path, the permitted can remain the same or only shrink
> and excluded can stay the same and grow and at the end you remove from the
> end certificate EKU which are not in the permitted state variable and are in
> the excluded state variable.
>
> So, what is being proposed here is flexible and secure.
>
> -----Original Message-----
> From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Sean Leonard
> Sent: Monday, May 16, 2016 2:16 AM
> To: spasm@ietf.org
> Subject: Re: [Spasm] My take on handling EKU constraints
>
> Hello:
>
> In the ASN.1 module (to be written), it's important to specify whether this
> extension uses IMPLICIT, EXPLICIT, or AUTOMATIC tagging. I am guessing folks
> don't want to use AUTOMATIC tagging, even though it's recommended by the
> latest ASN.1 standards because it's "easy". My personal preference is for
> EXPLICIT tagging. However, the extended key usage extension is defined in
> the IMPLICIT module in RFC 5280, so it's IMPLICIT...this means that if you
> want symmetry with the EKU extension, you should say it's IMPLICIT.
>
> Is there a way, using the latest ASN.1 syntax, to specify
> "either-or-or-both", i.e., the EKUConstraints SEQUENCE must have at least
> one element, possibly two, but not zero?
>
> As I understand it, "permitted" takes greater precedence over "excluded".
> I.e., if the extension has both permitted AND excluded, then really, only
> "permitted" is going to have meaningful effect.
> 1. That is because if a given EKU is on the permitted list but is also on
> the excluded list, it behaves as if it's not on the permitted list in the
> first place: effectively removing it from permitted.
> 2. If a given EKU is on the permitted list but NOT on the excluded list,
> then it's permitted: no additional effect.
> 3. If a given EKU is NOT on the permitted list but IS on the excluded list,
> then it's excluded, but this is the same as if it were not on the permitted
> list: no additional effect.
> 4. If a given EKU is on NEITHER the permitted list NOR the excluded list,
> this is the same as if it were not on the permitted list: no additional
> effect.
>
> I could show fancy set theory math but am lazy. ;-)
>
> Given the lazy-proof above, EKUConstraints does not need to be a SEQUENCE.
> It just needs to be a CHOICE between permittedKeyPurposeIDs and
> excludedKeyPurposeIDs. When it's tagged [0] on the wire, it means
> "permitted". When it's tagged [1] on the wire, it means "excluded". QED.
>
> (Note: Instead of expressing EKUConstraints as a CHOICE, we could specify
> two extensions, identified by id-ce-permittedEKUConstraints and
> id-ce-excludedEKUConstraints. However I believe that the CHOICE is better
> because the CHOICE prevents an implementation from stuffing both extensions
> into a certificate.)
>
> The appropriate ASN.1 standard and version should be referenced. Usually we
> use the 1988 syntax around these parts; however, that standard has been long
> superseded. Figure out what works for you...it appears that RFC 5280
> references X.680 (2002), while 5280 was published in May 2008.
>
> Sean
>
> On 5/13/2016 4:17 PM, Russ Housley wrote:
>> Review and comment are most welcome.
>>
>> Russ
>>
>> = = = = = = = = = =
>>
>> A new version of I-D, draft-housley-spasm-eku-constraints-00.txt
>> has been successfully submitted by Russell Housley and posted to the
>> IETF repository.
>>
>> Name:		draft-housley-spasm-eku-constraints
>> Revision:	00
>> Title:		Extended Key Usage Constraints
>> Document date:	2016-05-13
>> Group:		Individual Submission
>> Pages:		5
>> URL:
> https://www.ietf.org/internet-drafts/draft-housley-spasm-eku-constraints-00.
> txt
>> Status:
> https://datatracker.ietf.org/doc/draft-housley-spasm-eku-constraints/
>> Htmlized:
> https://tools.ietf.org/html/draft-housley-spasm-eku-constraints-00
>>
>> Abstract:
>>     This document specifies the extended key usage constraints
>>     certificate extension, which is used to place restrictions on the key
>>     purpose identifiers that are authorized to appear in subsequent
>>     certificates in a certification path.  Restrictions apply to the
>>     extended key usage certificate extension, which is described in RFC
>>     5280.
>>
>> _______________________________________________
>> 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
>
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm



--------------44E3747C11E8E613A1320747
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 7bit


  
    
  
  
    
Hi Santosh,

      

      With respect to the permitted/excluded issue: I read through the
      draft again, and disagree with the assertion that "it is more
      complicated and more flexible than what you say due to the path".

      

      Sure the algorithm is more complicated in draft-00 than what I'm
      saying, but it is not more flexible. The result is the same. The
      draft says:

      Section 3.5:

      
        (1)  If permitted_key_purpose_ids state variable is not special
             value that represents the universal set, then confirm that
             all of the key purpose identifiers [in the EKU extension
             of the end-entity certificate]
             are present in the set.
             If any are missing, then returning a failure indication and
             an appropriate reason.

      

      That is the same result. So the structures and algorithms proposed
      in draft-00 are needlessly complicated. (Specifically the
      structures, and enforcement of the structures, are needlessly
      complicated. I am not sure if the algorithm state variables can be
      reduced; need to think about it more. Offhand, I think that it
      could be shown that you need the same state variables as the
      structure, i.e., one boolean indicating whether we are in
      permitted vs. excluded mode, and one set of key purpose IDs. Once
      the algorithm encounters a "permitted" extension, it should flip
      the boolean from excluded to permitted, and do the difference of
      the excluded IDs to the permitted IDs.)

      

      I request a counter-proof.

      

      Sean

      

      On 5/16/2016 6:47 AM, Santosh Chokhani wrote:

    

    

      
Hi Sean,

It is more complicated and more flexible than what you say due to the path.

As you go through the path, the permitted can remain the same or only shrink
and excluded can stay the same and grow and at the end you remove from the
end certificate EKU which are not in the permitted state variable and are in
the excluded state variable.

So, what is being proposed here is flexible and secure.

-----Original Message-----
From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Sean Leonard
Sent: Monday, May 16, 2016 2:16 AM
To: spasm@ietf.org
Subject: Re: [Spasm] My take on handling EKU constraints

Hello:

In the ASN.1 module (to be written), it's important to specify whether this
extension uses IMPLICIT, EXPLICIT, or AUTOMATIC tagging. I am guessing folks
don't want to use AUTOMATIC tagging, even though it's recommended by the
latest ASN.1 standards because it's "easy". My personal preference is for
EXPLICIT tagging. However, the extended key usage extension is defined in
the IMPLICIT module in RFC 5280, so it's IMPLICIT...this means that if you
want symmetry with the EKU extension, you should say it's IMPLICIT.

Is there a way, using the latest ASN.1 syntax, to specify
"either-or-or-both", i.e., the EKUConstraints SEQUENCE must have at least
one element, possibly two, but not zero?

As I understand it, "permitted" takes greater precedence over "excluded".
I.e., if the extension has both permitted AND excluded, then really, only
"permitted" is going to have meaningful effect.
1. That is because if a given EKU is on the permitted list but is also on
the excluded list, it behaves as if it's not on the permitted list in the
first place: effectively removing it from permitted.
2. If a given EKU is on the permitted list but NOT on the excluded list,
then it's permitted: no additional effect.
3. If a given EKU is NOT on the permitted list but IS on the excluded list,
then it's excluded, but this is the same as if it were not on the permitted
list: no additional effect.
4. If a given EKU is on NEITHER the permitted list NOR the excluded list,
this is the same as if it were not on the permitted list: no additional
effect.

I could show fancy set theory math but am lazy. ;-)

Given the lazy-proof above, EKUConstraints does not need to be a SEQUENCE.
It just needs to be a CHOICE between permittedKeyPurposeIDs and
excludedKeyPurposeIDs. When it's tagged [0] on the wire, it means
"permitted". When it's tagged [1] on the wire, it means "excluded". QED.

(Note: Instead of expressing EKUConstraints as a CHOICE, we could specify
two extensions, identified by id-ce-permittedEKUConstraints and
id-ce-excludedEKUConstraints. However I believe that the CHOICE is better
because the CHOICE prevents an implementation from stuffing both extensions
into a certificate.)

The appropriate ASN.1 standard and version should be referenced. Usually we
use the 1988 syntax around these parts; however, that standard has been long
superseded. Figure out what works for you...it appears that RFC 5280
references X.680 (2002), while 5280 was published in May 2008.

Sean

On 5/13/2016 4:17 PM, Russ Housley wrote:


      

        
Review and comment are most welcome.

Russ

= = = = = = = = = =

A new version of I-D, draft-housley-spasm-eku-constraints-00.txt
has been successfully submitted by Russell Housley and posted to the 
IETF repository.

Name:		draft-housley-spasm-eku-constraints
Revision:	00
Title:		Extended Key Usage Constraints
Document date:	2016-05-13
Group:		Individual Submission
Pages:		5
URL:


      

      
https://www.ietf.org/internet-drafts/draft-housley-spasm-eku-constraints-00.
txt


      

        
Status:


      

      
https://datatracker.ietf.org/doc/draft-housley-spasm-eku-constraints/


      

        
Htmlized:


      

      
https://tools.ietf.org/html/draft-housley-spasm-eku-constraints-00


      

        

Abstract:
   This document specifies the extended key usage constraints
   certificate extension, which is used to place restrictions on the key
   purpose identifiers that are authorized to appear in subsequent
   certificates in a certification path.  Restrictions apply to the
   extended key usage certificate extension, which is described in RFC
   5280.

_______________________________________________
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

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


    

    


    

  


--------------44E3747C11E8E613A1320747--


From nobody Mon May 16 08:29:56 2016
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 7B9C112D66A for ; Mon, 16 May 2016 08:29:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Level: 
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NJ6eE4OCyrAb for ; Mon, 16 May 2016 08:29:54 -0700 (PDT)
Received: from mail.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id D302C12D117 for ; Mon, 16 May 2016 08:29:53 -0700 (PDT)
Received: from localhost (ronin.smetech.net [209.135.209.5]) by mail.smetech.net (Postfix) with ESMTP id 7EAC1F24041; Mon, 16 May 2016 11:29:53 -0400 (EDT)
X-Virus-Scanned: amavisd-new at smetech.net
Received: from mail.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id uZnBYc-XDbqQ; Mon, 16 May 2016 11:12:45 -0400 (EDT)
Received: from [172.26.10.187] (unknown [104.129.194.81]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.smetech.net (Postfix) with ESMTP id B96B5F24013; Mon, 16 May 2016 11:29:52 -0400 (EDT)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Russ Housley 
In-Reply-To: <064101d1ad9f$798f3a10$6cadae30$@augustcellars.com>
Date: Mon, 16 May 2016 11:29:52 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <122A4A08-690F-4071-87D2-C9E0684B6899@vigilsec.com>
References: <064101d1ad9f$798f3a10$6cadae30$@augustcellars.com>
To: Jim Schaad 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: 
Cc: spasm@ietf.org
Subject: Re: [Spasm] Comments on draft-housley-spasm-eku-constraints-00
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 16 May 2016 15:29:55 -0000

Jim:

> 1. I believe that doing the restriction to just CA certificates is
> incorrect.  I believe that this is just as useful for an AA =
certificate.  I
> would request that this restriction be relaxed and potentially =
removed.

Section 4.5 of RFC 3281 says that an AA cannot also be a CA, and the =
attribute certificate issued by the AA will not contain an EKU extension =
since the attribute certificate does not contain a public key.

The certification path for the AA certificate could include this =
certificate extension.

So, I am not seeing the benefit.  Please share the use case that you =
envision.


> 2.  I believe that in section 3.1 an application should be able to =
require
> that an EKU be permitted.  This seems to be a logical location to =
specified
> that.  This is commonly done for Microsoft in saying that this root =
may be
> used for specific key usages but not for others.

That could be done.  That would seem to have a greater impact on the =
APIs for path processing libraries.  And, it is not needed to fulfill =
the issue that was originally raised here:
https://mailarchive.ietf.org/arch/msg/pkix/MHwcSWuuzezj4qHuzSmbYeGUbdI

If we add a required-key-purpose-id input parameter, then it needs to =
have an empty set as the default.  I need to hear from others if it is =
needed.


> 3.  I believe that step (p) (1) is missing a step, although it could
> potentially go into step (h) in section 3.5
> 	(2) if excludedKeyPurposesIds is present in the certificate, set =
the
> excluded_key_purpose_ids state varble to..   Set the =
permittedKeyPurposeIds
> to the intersection of the result from step (1) and the inverse of the
> excludedKeyPurposesIds.

I do not think this is needed.  The corrected logic below in the wrap-up =
step should be enough.

>=20
> 	(3) if the excludedKeyPurposesId is the empty set, then fail the
> validation procedure
>=20
> 	The certificate should be considered invalid regardless of the
> presence of the EKU extension in the EE certificate.

Swapping the order probably make things more clear:

   (h)  If the EKU extension is included in the end-entity certificate,
        then confirm that the values meet the restrictions in the
        permitted_key_purpose_ids and excluded_key_purpose_ids state
        variables as follows:

        (1)  If excluded_key_purpose_ids state variable is empty, then
             return a failure indication and an appropriate reason.

        (2)  If excluded_key_purpose_ids state variable is not empty,
             then confirm that none of the key purpose identifiers are
             present in the set.  If any are present, then return a
             failure indication and an appropriate reason.

        (3)  If permitted_key_purpose_ids state variable is not special
             value that represents the universal set, then confirm that
             all of the key purpose identifiers are present in the set.
             If any are missing, then returning a failure indication and
             an appropriate reason.


> 4.  I recognize that this is the method that you feel is correct.  =
However,
> justification text about why the current method used by Msft et al is =
not
> correct is probably required.  At a minimum a recognition that this =
has been
> the Msft behavior since day 1 is needed.

We may need to develop some background text.  I=92m willing to work on =
that text if there is support for this approach going forward.

Russ=


From nobody Mon May 16 08:46:11 2016
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 8492F12D6FA for ; Mon, 16 May 2016 08:46:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tmk5XtPHm8wd for ; Mon, 16 May 2016 08:46:00 -0700 (PDT)
Received: from mail-qg0-x243.google.com (mail-qg0-x243.google.com [IPv6:2607:f8b0:400d:c04::243]) (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 D113D12D6F7 for ; Mon, 16 May 2016 08:45:59 -0700 (PDT)
Received: by mail-qg0-x243.google.com with SMTP id f74so13988329qge.3 for ; Mon, 16 May 2016 08:45:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=9XmJ5fJj4SmHqehl3PypGon/PsfNM6CLpl/UDDbQICY=; b=ZZe3zSaY+EJxY3WdrNu1U5JPDzRM0T/tUs7jBj1luup9akQ5h+N4pGFrbQFr/OqJnW LLcsnYbtufV00besTtAko5GCVh9TGZBoGOe6f2d0KfKHHaB9DdwGNRy5+q+az2HyvwKX BsSxx9d7Ds8KLSE1/0cfnGdt71BlmYEgoZomSWE0y4Yw8moT17Y2Gur32ARYSiCiJK/w pSov1bcEphEzEavHjhvTL+wVlBRf+Rdv1iw99ck8gTHMJnIv/TBYb5ih4VDUG6IA6Dhn GJ52XnDgS1/CYvJ1SIY70U24d4ZSLE8wO1nA3pjPNuPsKOIusupfwLmcRWJXSRZWpKwX s5Ow==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=9XmJ5fJj4SmHqehl3PypGon/PsfNM6CLpl/UDDbQICY=; b=j+xcE7m47zhdSeY0aQSbFkUxlQPePbk6pbJ2BZ/JuuM2xoaiJrNJvVkQZdjQlH6x1X nUiOU1qDlX3Mu/J8Ijwpd2iEjubG6VvG7IZhWugHmOAc4Vh7DARVY9hvnkzp0g4tDm4h YPkAkqoUi4ijvFjhXwTq+ZSLC3z1xM7HR8GqTMC9oujnV+oT7la26Z3V+4zEyxrFAcZb WQUTYlzO3kxDfp/A5dfvEfcp48Bk4w293HxFOIA7tr+dVABgWhls7DlAjPATworrAo02 COqsyeRWV2Xv/XFKRg8NC44xDXLMBU+AE3yXsgegaACycFzYFc/y32kb0hhPlLNBtYs4 uCHA==
X-Gm-Message-State: AOPr4FXSTjT91luAX1OKn2Rx0sCH29YwGCcKCD3zgcR4B5zliVfe/rNOL2YSlrpqZAykdQ==
X-Received: by 10.140.36.167 with SMTP id p36mr27546712qgp.38.1463413558878; Mon, 16 May 2016 08:45:58 -0700 (PDT)
Received: from SantoshBrain (pool-108-31-66-4.washdc.fios.verizon.net. [108.31.66.4]) by smtp.gmail.com with ESMTPSA id z127sm14988699qhz.8.2016.05.16.08.45.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 May 2016 08:45:57 -0700 (PDT)
From: "Santosh Chokhani" 
To: "'Stephen Farrell'" , 
References: <316ECF88-612A-4131-8A96-E5F76671929A@vigilsec.com> <044a01d1af10$1548b8c0$3fda2a40$@gmail.com> <000f01d1af31$5a760f80$0f622e80$@augustcellars.com> <054b01d1af78$d79e09d0$86da1d70$@gmail.com> <5739D2D5.8020809@cs.tcd.ie>
In-Reply-To: <5739D2D5.8020809@cs.tcd.ie>
Date: Mon, 16 May 2016 11:45:54 -0400
Message-ID: <05d401d1af8a$08493c60$18dbb520$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQG9AVJW+Y7xpWAUdsUf0IIYfjAqNAGVztXGAf86bnoCUnYraAGgcfkvn6jP1kA=
Content-Language: en-us
Archived-At: 
Subject: Re: [Spasm] My take on handling EKU constraints
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 16 May 2016 15:46:09 -0000

Hi Steve,

I have been dealing with EKU dilemma based on how Microsoft treats absence
of 
EKU and how it can cause certificates to be treated as code signer.

I have been advising several customers on how to mitigate this problem and 
what kind of interoperability and standard compliance problem it causes for 
the various platforms and applications when you use EKU in intermediate 
certificates or use Application Policies extension which is a private 
Microsoft extension, has the same semantics, but different syntax and has
been 
deprecated lately to the best my knowledge.

The specific text you cite below is a natural outcome when you think that
the 
EKU should be enforced at the application layer and not at the path
validation 
layer.

-----Original Message-----
From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie]
Sent: Monday, May 16, 2016 10:02 AM
To: Santosh Chokhani ; 'Jim Schaad' 
; 'Russ Housley' ; 
spasm@ietf.org
Subject: Re: [Spasm] My take on handling EKU constraints


Hi Santosh,

A sort of meta comment below...

On 16/05/16 14:42, Santosh Chokhani wrote:
> [Santosh] I am not in favor of causing path validation failure due to
empty
> EKU.  Some applications do not care.  EKU should be enforced by the
> application just like KU.  See my suggestion 3 above for wrap up.  I think
> the path validation engine should output EKUs and let the application do
the
> enforcement.  We do the same for certificate policy unless require
explicit
> policy state variable gets set by the state machine.  I do not think we
want
> this added state variable for EKU and initial value and added value in the
> extension.  It is better to let the application make its own decision.

I hope we all agree that this kind of thing ought be mostly
driven by what those implementing or deploying certificate
validation and applications want and are willing to do and
what they think makes sense in terms of APIs etc. For example,
I wondered which application(s) you are involved in developing
you meant in the above.

One thing I think we need to be quite careful about with all
of this planned work is to not repeat mistakes we (incl. me)
made in the past where we designed a bunch of PKI machinery
that didn't get used, or that made it harder to use PKI, or
that made PKI less useful. There is really no point in us
repeating such mistakes, and again, I hope we all agree on
that.

So I'd much prefer that we see arguments on this that look
more like "In my application/library , I'd prefer we do
it  way, because..."

Cheers,
S.



From nobody Mon May 16 09:06:12 2016
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 9B5E812D114 for ; Mon, 16 May 2016 09:06:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.689
X-Spam-Level: 
X-Spam-Status: No, score=-2.689 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, T_KAM_HTML_FONT_INVALID=0.01] 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 vZIcT2dZFDw8 for ; Mon, 16 May 2016 09:06:08 -0700 (PDT)
Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F3F812D70C for ; Mon, 16 May 2016 09:06:08 -0700 (PDT)
Received: by mail-qk0-x233.google.com with SMTP id x7so99055672qkd.3 for ; Mon, 16 May 2016 09:06:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=from:to:references:in-reply-to:subject:date:message-id:mime-version :thread-index:content-language; bh=RAOEhsto8JwiZUO8OP6FsdrFfo2p4UQJDrkmFxQjmZg=; b=H1K9pFSRbdnTvYEbNPKWybPgMU0RC62q91QpyaaOJCYGQIXhY4CKI8ss5bheu+NyF4 5A7JySNvq5Il4bGA7B4YP8zCJi/XbVOHuNy4H5914oojcf9ff3G2Siz6g2yoL337JntM YVh0jMcVUliUQ0EQfnFDJkxLCb7km2uI2HL/so/0CoKwovuQXhLz31aExLOxizjuqSQ1 zI3o75y1Xnx86cH3ARBY/33quQ0t2D4tEr4TmDzK2AAYboBzTSvCJVER7RsKU6l07cQN tFH8JxOsUYoCJKo2dJ2SFuQNW8ETfbbY0LwgdRJZti8Rd2TE748b7DXLlmhEhH7fbrjf 5L1A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:thread-index:content-language; bh=RAOEhsto8JwiZUO8OP6FsdrFfo2p4UQJDrkmFxQjmZg=; b=fm0/36rMDPWSgV3C7VlnzmRUUAJyJY3esgbF+tLy7lj63L1fjfoA/SCFZHp+CKFiEm b+fr5ftkcEdAuOE4hXl/C/JwzRG14hLbshlcl+njyx3rzK4s+Fe0CGGWz0dkALrtxJoB aj20djHJHaEI6JA3F86T21VY57//k5DNpaQ43H2dBGHNBgKhbpzrdPfabGSv9gJ/vt2q VsYnyRV6kagiDfJ3VqYfjMe4oGcPi8oCRPD+whuZJU+Pbu0VDODi00h3M4ASuLVNWQq/ KefdSRO9Efn4QjT41k1gpbxY8lcaC/iuJXJmrI7hY/E+nkYoxWqRSwuyoZS3TI+lrbQU Hiow==
X-Gm-Message-State: AOPr4FVyr2MEsXek2nMDT1+eBaGVuWTWvzzw8eCJnyywQsLS6wf6GUPu9Ys7yhFLNbbzkw==
X-Received: by 10.55.43.87 with SMTP id r84mr31738794qkh.143.1463414767365; Mon, 16 May 2016 09:06:07 -0700 (PDT)
Received: from SantoshBrain (pool-108-31-66-4.washdc.fios.verizon.net. [108.31.66.4]) by smtp.gmail.com with ESMTPSA id a142sm14995687qha.12.2016.05.16.09.06.05 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 May 2016 09:06:06 -0700 (PDT)
From: "Santosh Chokhani" 
To: 
References: <316ECF88-612A-4131-8A96-E5F76671929A@vigilsec.com> <1b87369d-9812-b5c0-9631-ba9e638fd6d4@seantek.com> <054c01d1af79$8ea69340$abf3b9c0$@gmail.com> <13faee9b-0571-ce73-d9e3-cd616393e531@seantek.com>
In-Reply-To: <13faee9b-0571-ce73-d9e3-cd616393e531@seantek.com>
Date: Mon, 16 May 2016 12:06:03 -0400
Message-ID: <05fa01d1af8c$d8e12110$8aa36330$@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_05FB_01D1AF6B.51D17CE0"
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQG9AVJW+Y7xpWAUdsUf0IIYfjAqNAJIj4ReAzOKHpQB8Iw/S5+prq+Q
Content-Language: en-us
Archived-At: 
Subject: Re: [Spasm] My take on handling EKU constraints
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 16 May 2016 16:06:10 -0000

This is a multipart message in MIME format.

------=_NextPart_000_05FB_01D1AF6B.51D17CE0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi Sean,

 

If you mean that each CA certificate needs to have only one or the other
permitted or excluded and the validation engine needs only one state
variable, I agree.

 

Say, you can keep a list of permitted only as state variable and delete
excluded ones when they appear and take the intersection with permitted one
when it appears.  There will be an edge case if excluded has
anyExtendedKeyUsage and in that case permitted set becomes NULL.

 

I still think this new logic should not cause failure and wrap up should
take intersection of the permitted state variable and EKU in the end
certificate with absence of extension being treated as UNIVERSAL set.

 

Does that work and do I get you now?

 

From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Sean Leonard
Sent: Monday, May 16, 2016 11:22 AM
To: spasm@ietf.org
Subject: Re: [Spasm] My take on handling EKU constraints

 

Hi Santosh,

With respect to the permitted/excluded issue: I read through the draft
again, and disagree with the assertion that "it is more complicated and more
flexible than what you say due to the path".

Sure the algorithm is more complicated in draft-00 than what I'm saying, but
it is not more flexible. The result is the same. The draft says:
Section 3.5:



        (1)  If permitted_key_purpose_ids state variable is not special
             value that represents the universal set, then confirm that
             all of the key purpose identifiers [in the EKU extension
             of the end-entity certificate]
             are present in the set.
             If any are missing, then returning a failure indication and
             an appropriate reason.


That is the same result. So the structures and algorithms proposed in
draft-00 are needlessly complicated. (Specifically the structures, and
enforcement of the structures, are needlessly complicated. I am not sure if
the algorithm state variables can be reduced; need to think about it more.
Offhand, I think that it could be shown that you need the same state
variables as the structure, i.e., one boolean indicating whether we are in
permitted vs. excluded mode, and one set of key purpose IDs. Once the
algorithm encounters a "permitted" extension, it should flip the boolean
from excluded to permitted, and do the difference of the excluded IDs to the
permitted IDs.)

I request a counter-proof.

Sean

On 5/16/2016 6:47 AM, Santosh Chokhani wrote:

Hi Sean,
 
It is more complicated and more flexible than what you say due to the path.
 
As you go through the path, the permitted can remain the same or only shrink
and excluded can stay the same and grow and at the end you remove from the
end certificate EKU which are not in the permitted state variable and are in
the excluded state variable.
 
So, what is being proposed here is flexible and secure.
 
-----Original Message-----
From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Sean Leonard
Sent: Monday, May 16, 2016 2:16 AM
To: spasm@ietf.org  
Subject: Re: [Spasm] My take on handling EKU constraints
 
Hello:
 
In the ASN.1 module (to be written), it's important to specify whether this
extension uses IMPLICIT, EXPLICIT, or AUTOMATIC tagging. I am guessing folks
don't want to use AUTOMATIC tagging, even though it's recommended by the
latest ASN.1 standards because it's "easy". My personal preference is for
EXPLICIT tagging. However, the extended key usage extension is defined in
the IMPLICIT module in RFC 5280, so it's IMPLICIT...this means that if you
want symmetry with the EKU extension, you should say it's IMPLICIT.
 
Is there a way, using the latest ASN.1 syntax, to specify
"either-or-or-both", i.e., the EKUConstraints SEQUENCE must have at least
one element, possibly two, but not zero?
 
As I understand it, "permitted" takes greater precedence over "excluded".
I.e., if the extension has both permitted AND excluded, then really, only
"permitted" is going to have meaningful effect.
1. That is because if a given EKU is on the permitted list but is also on
the excluded list, it behaves as if it's not on the permitted list in the
first place: effectively removing it from permitted.
2. If a given EKU is on the permitted list but NOT on the excluded list,
then it's permitted: no additional effect.
3. If a given EKU is NOT on the permitted list but IS on the excluded list,
then it's excluded, but this is the same as if it were not on the permitted
list: no additional effect.
4. If a given EKU is on NEITHER the permitted list NOR the excluded list,
this is the same as if it were not on the permitted list: no additional
effect.
 
I could show fancy set theory math but am lazy. ;-)
 
Given the lazy-proof above, EKUConstraints does not need to be a SEQUENCE.
It just needs to be a CHOICE between permittedKeyPurposeIDs and
excludedKeyPurposeIDs. When it's tagged [0] on the wire, it means
"permitted". When it's tagged [1] on the wire, it means "excluded". QED.
 
(Note: Instead of expressing EKUConstraints as a CHOICE, we could specify
two extensions, identified by id-ce-permittedEKUConstraints and
id-ce-excludedEKUConstraints. However I believe that the CHOICE is better
because the CHOICE prevents an implementation from stuffing both extensions
into a certificate.)
 
The appropriate ASN.1 standard and version should be referenced. Usually we
use the 1988 syntax around these parts; however, that standard has been long
superseded. Figure out what works for you...it appears that RFC 5280
references X.680 (2002), while 5280 was published in May 2008.
 
Sean
 
On 5/13/2016 4:17 PM, Russ Housley wrote:

Review and comment are most welcome.
 
Russ
 
= = = = = = = = = =
 
A new version of I-D, draft-housley-spasm-eku-constraints-00.txt
has been successfully submitted by Russell Housley and posted to the 
IETF repository.
 
Name:              draft-housley-spasm-eku-constraints
Revision:  00
Title:             Extended Key Usage Constraints
Document date:     2016-05-13
Group:             Individual Submission
Pages:             5
URL:

https://www.ietf.org/internet-drafts/draft-housley-spasm-eku-constraints-00.
txt

Status:

https://datatracker.ietf.org/doc/draft-housley-spasm-eku-constraints/

Htmlized:

https://tools.ietf.org/html/draft-housley-spasm-eku-constraints-00

 
 
Abstract:
   This document specifies the extended key usage constraints
   certificate extension, which is used to place restrictions on the key
   purpose identifiers that are authorized to appear in subsequent
   certificates in a certification path.  Restrictions apply to the
   extended key usage certificate extension, which is described in RFC
   5280.
 
_______________________________________________
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
 
_______________________________________________
Spasm mailing list
Spasm@ietf.org  
https://www.ietf.org/mailman/listinfo/spasm

 


------=_NextPart_000_05FB_01D1AF6B.51D17CE0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Hi Sean,
 
If you mean that each CA certificate needs to have only one or the =
other permitted or excluded and the validation engine needs only one =
state variable, I agree.
 
Say, you can keep a list of permitted only as state variable and delete =
excluded ones when they appear and take the intersection with permitted =
one when it appears.  There will be an edge case if excluded has =
anyExtendedKeyUsage and in that case permitted set becomes =
NULL.
 
I still think this new logic should not cause failure and wrap up =
should  take intersection of the permitted state variable and EKU =
in the end certificate with absence of extension being treated as =
UNIVERSAL set.
 
Does that work and do I get you now?
 
From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Sean =
Leonard
Sent: Monday, May 16, 2016 11:22 AM
To: =
spasm@ietf.org
Subject: Re: [Spasm] My take on handling EKU =
constraints
 
Hi =
Santosh,

With respect to the permitted/excluded issue: I read =
through the draft again, and disagree with the assertion that "it =
is more complicated and more flexible than what you say due to the =
path".

Sure the algorithm is more complicated in draft-00 =
than what I'm saying, but it is not more flexible. The result is the =
same. The draft says:
Section 3.5:

      &n=
bsp; (1)  If permitted_key_purpose_ids state variable is not =
special
      &n=
bsp;      value that represents the universal =
set, then confirm that
      &n=
bsp;      all of the key purpose identifiers =
[in the EKU extension
      =
;       of the end-entity =
certificate]
      &n=
bsp;      are present in the =
set.
      &n=
bsp;      If any are missing, then returning a =
failure indication and
      &n=
bsp;      an appropriate =
reason.

That is the same =
result. So the structures and algorithms proposed in draft-00 are =
needlessly complicated. (Specifically the structures, and enforcement of =
the structures, are needlessly complicated. I am not sure if the =
algorithm state variables can be reduced; need to think about it more. =
Offhand, I think that it could be shown that you need the same state =
variables as the structure, i.e., one boolean indicating whether we are =
in permitted vs. excluded mode, and one set of key purpose IDs. Once the =
algorithm encounters a "permitted" extension, it should flip =
the boolean from excluded to permitted, and do the difference of the =
excluded IDs to the permitted IDs.)

I request a =
counter-proof.

Sean

On 5/16/2016 6:47 AM, Santosh Chokhani =
wrote:
Hi =
Sean,
 
It is more =
complicated and more flexible than what you say due to the =
path.
 
As you go through =
the path, the permitted can remain the same or only =
shrink
and excluded can stay the same and grow and =
at the end you remove from the
end certificate EKU =
which are not in the permitted state variable and are =
in
the excluded state =
variable.
 
So, what is =
being proposed here is flexible and =
secure.
 
-----Original =
Message-----
From: Spasm [mailto:spasm-bounces@ietf.org]=
 On Behalf Of Sean Leonard
Sent: Monday, May 16, =
2016 2:16 AM
To: spasm@ietf.org
Su=
bject: Re: [Spasm] My take on handling EKU =
constraints
 
Hello:<=
/o:p>
 
In the ASN.1 module (to be =
written), it's important to specify whether =
this
extension uses IMPLICIT, EXPLICIT, or =
AUTOMATIC tagging. I am guessing folks
don't want =
to use AUTOMATIC tagging, even though it's recommended by =
the
latest ASN.1 standards because it's =
"easy". My personal preference is =
for
EXPLICIT tagging. However, the extended key =
usage extension is defined in
the IMPLICIT module =
in RFC 5280, so it's IMPLICIT...this means that if =
you
want symmetry with the EKU extension, you =
should say it's =
IMPLICIT.
 
Is there a =
way, using the latest ASN.1 syntax, to =
specify
"either-or-or-both", i.e., the =
EKUConstraints SEQUENCE must have at least
one =
element, possibly two, but not =
zero?
 
As I understand =
it, "permitted" takes greater precedence over =
"excluded".
I.e., if the extension has =
both permitted AND excluded, then really, =
only
"permitted" is going to have =
meaningful effect.
1. That is because if a given =
EKU is on the permitted list but is also on
the =
excluded list, it behaves as if it's not on the permitted list in =
the
first place: effectively removing it from =
permitted.
2. If a given EKU is on the permitted =
list but NOT on the excluded list,
then it's =
permitted: no additional effect.
3. If a given EKU =
is NOT on the permitted list but IS on the excluded =
list,
then it's excluded, but this is the same as =
if it were not on the permitted
list: no additional =
effect.
4. If a given EKU is on NEITHER the =
permitted list NOR the excluded list,
this is the =
same as if it were not on the permitted list: no =
additional
effect.
 <=
/o:p>
I could show fancy set theory math but am lazy. =
;-)
 
Given the =
lazy-proof above, EKUConstraints does not need to be a =
SEQUENCE.
It just needs to be a CHOICE between =
permittedKeyPurposeIDs and
excludedKeyPurposeIDs. =
When it's tagged [0] on the wire, it =
means
"permitted". When it's tagged [1] =
on the wire, it means "excluded". =
QED.
 
(Note: Instead of =
expressing EKUConstraints as a CHOICE, we could =
specify
two extensions, identified by =
id-ce-permittedEKUConstraints =
and
id-ce-excludedEKUConstraints. However I believe =
that the CHOICE is better
because the CHOICE =
prevents an implementation from stuffing both =
extensions
into a =
certificate.)
 
The =
appropriate ASN.1 standard and version should be referenced. Usually =
we
use the 1988 syntax around these parts; however, =
that standard has been long
superseded. Figure out =
what works for you...it appears that RFC =
5280
references X.680 (2002), while 5280 was =
published in May =
2008.
 
Sean
 
On 5/13/2016 4:17 PM, Russ Housley =
wrote:
Review and comment =
are most =
welcome.
 
Russ=

 
=3D =3D =3D =3D =3D =3D =3D =3D =
=3D =3D
 
A new version =
of I-D, =
draft-housley-spasm-eku-constraints-00.txt
has been =
successfully submitted by Russell Housley and posted to the =

IETF =
repository.
 
Name: &=
nbsp;            =
draft-housley-spasm-eku-constraints
Revision:  =
00
Title:       &=
nbsp;     Extended Key Usage =
Constraints
Document date:     =
2016-05-13
Group:      =
;       Individual =
Submission
Pages:      =
;       =
5
URL:
https://www.ietf.org/internet-drafts/draft-housley-spasm-eku-=
constraints-00.
txt
Status:
https://datatracker.ietf.org/doc/draft-housley-spasm-eku-constraint=
s/
Htmlized:<=
/pre>
https://tools.ietf.org/html/draft-housley-spasm-eku-constraints-00=

 
 
Abstract:
 &=
nbsp; This document specifies the extended key usage =
constraints
   certificate extension, =
which is used to place restrictions on the =
key
   purpose identifiers that are =
authorized to appear in subsequent
   =
certificates in a certification path.  Restrictions apply to =
the
   extended key usage certificate =
extension, which is described in RFC
   =
5280.
 
__________________=
_____________________________
Spasm mailing =
list
Spasm@ietf.org
https://www.ietf.org=
/mailman/listinfo/spasm
 =

 
 
=
_______________________________________________
Spas=
m mailing list
Spasm@ietf.org
https://www.ietf.org=
/mailman/listinfo/spasm
 
<=
pre>_______________________________________________
=
Spasm mailing list
Spasm@ietf.org
https://www.ietf.org=
/mailman/listinfo/spasm
 

------=_NextPart_000_05FB_01D1AF6B.51D17CE0--


From nobody Mon May 16 11:11:49 2016
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 5D5BC12D8D5 for ; Mon, 16 May 2016 11:11:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 953ZphFuVtk7 for ; Mon, 16 May 2016 11:11:45 -0700 (PDT)
Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4098612D17C for ; Mon, 16 May 2016 11:11:44 -0700 (PDT)
Received: from hebrews (c-24-21-96-37.hsd1.or.comcast.net [24.21.96.37]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 2AA2B2CA36; Mon, 16 May 2016 11:11:42 -0700 (PDT)
From: "Jim Schaad" 
To: "'Russ Housley'" 
References: <064101d1ad9f$798f3a10$6cadae30$@augustcellars.com> <122A4A08-690F-4071-87D2-C9E0684B6899@vigilsec.com>
In-Reply-To: <122A4A08-690F-4071-87D2-C9E0684B6899@vigilsec.com>
Date: Mon, 16 May 2016 11:11:41 -0700
Message-ID: <00ca01d1af9e$6621f4d0$3265de70$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQFraw2R3jw97XtuB4EqadgIDOvUfAJvx3EVoHTnUBA=
Content-Language: en-us
Archived-At: 
Cc: spasm@ietf.org
Subject: Re: [Spasm] Comments on draft-housley-spasm-eku-constraints-00
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 16 May 2016 18:11:47 -0000

Russ,

-----Original Message-----
From: Russ Housley [mailto:housley@vigilsec.com] 
Sent: Monday, May 16, 2016 8:30 AM
To: Jim Schaad 
Cc: spasm@ietf.org
Subject: Re: Comments on draft-housley-spasm-eku-constraints-00 

Jim:

> 1. I believe that doing the restriction to just CA certificates is 
> incorrect.  I believe that this is just as useful for an AA 
> certificate.  I would request that this restriction be relaxed and
potentially removed.

Section 4.5 of RFC 3281 says that an AA cannot also be a CA, and the
attribute certificate issued by the AA will not contain an EKU extension
since the attribute certificate does not contain a public key.

The certification path for the AA certificate could include this certificate
extension.

So, I am not seeing the benefit.  Please share the use case that you
envision.

[JLS] I don't have a specific idea in mind at the moment.  I was just
running on a feeling.


> 2.  I believe that in section 3.1 an application should be able to 
> require that an EKU be permitted.  This seems to be a logical location 
> to specified that.  This is commonly done for Microsoft in saying that 
> this root may be used for specific key usages but not for others.

That could be done.  That would seem to have a greater impact on the APIs
for path processing libraries.  And, it is not needed to fulfill the issue
that was originally raised here:
https://mailarchive.ietf.org/arch/msg/pkix/MHwcSWuuzezj4qHuzSmbYeGUbdI

If we add a required-key-purpose-id input parameter, then it needs to have
an empty set as the default.  I need to hear from others if it is needed.

[JLS] I would need to look at how the algorithm was specified to use this.
However, I would have thought that the default would be any key usage in the
permitted set rather than the empty set.  

> 3.  I believe that step (p) (1) is missing a step, although it could 
> potentially go into step (h) in section 3.5
> 	(2) if excludedKeyPurposesIds is present in the certificate, set the
> excluded_key_purpose_ids state varble to..   Set the
permittedKeyPurposeIds
> to the intersection of the result from step (1) and the inverse of the 
> excludedKeyPurposesIds.

I do not think this is needed.  The corrected logic below in the wrap-up
step should be enough.

> 
> 	(3) if the excludedKeyPurposesId is the empty set, then fail the 
> validation procedure
> 
> 	The certificate should be considered invalid regardless of the 
> presence of the EKU extension in the EE certificate.

Swapping the order probably make things more clear:

   (h)  If the EKU extension is included in the end-entity certificate,
        then confirm that the values meet the restrictions in the
        permitted_key_purpose_ids and excluded_key_purpose_ids state
        variables as follows:

        (1)  If excluded_key_purpose_ids state variable is empty, then
             return a failure indication and an appropriate reason.
[JLS] I think this is not a correct test - I would look at the permitted set
being empty not the excluded set.

        (2)  If excluded_key_purpose_ids state variable is not empty,
             then confirm that none of the key purpose identifiers are
             present in the set.  If any are present, then return a
             failure indication and an appropriate reason.

        (3)  If permitted_key_purpose_ids state variable is not special
             value that represents the universal set, then confirm that
             all of the key purpose identifiers are present in the set.
             If any are missing, then returning a failure indication and
             an appropriate reason.

[JLS] And if the EKU extension is not included in the end-entity certificate
what happens if the permitted_key_usage_purpose_ids state variable is the
empty set?

> 4.  I recognize that this is the method that you feel is correct.  
> However, justification text about why the current method used by Msft 
> et al is not correct is probably required.  At a minimum a recognition 
> that this has been the Msft behavior since day 1 is needed.

We may need to develop some background text.  I'm willing to work on that
text if there is support for this approach going forward.

Russ


From nobody Mon May 16 13:41:45 2016
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 C3E6612D561; Mon, 16 May 2016 13:41:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.327
X-Spam-Level: 
X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o5ss-_7-qPtz; Mon, 16 May 2016 13:41:42 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49AAC12D1E0; Mon, 16 May 2016 13:41:42 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 7F39A200A3; Mon, 16 May 2016 16:47:32 -0400 (EDT)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id D3F7E638BE; Mon, 16 May 2016 16:41:40 -0400 (EDT)
From: Michael Richardson 
To: Stephen Farrell 
In-Reply-To: <5739DA1E.2000202@cs.tcd.ie>
References: <064101d1ad9f$798f3a10$6cadae30$@augustcellars.com> <5739DA1E.2000202@cs.tcd.ie>
X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.4.2
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m
Archived-At: 
Cc: spasm@ietf.org, Jim Schaad , draft-housley-spasm-eku-constraints@ietf.org
Subject: Re: [Spasm] Comments on draft-housley-spasm-eku-constraints-00
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 16 May 2016 20:41:44 -0000

--=-=-=
Content-Type: text/plain


Stephen Farrell  wrote:
    > Who operates an AA and wants to use this? If nobody, (as I suspect),
    > then I'd argue that it'd be better to be entirely silent about AA's and

Aren't SIDR objects AAs?

--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-




--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEVAwUBVzowgYCLcPvd0N1lAQIXhQf+Ov5VKu67oHvei3S3gmynB6Lt+ncr8+88
gb5n9lfjQnQv5WH0ewyoCQ1pKtNKYvBKBBpi+ei0dEXJkpbTocC1mlRchCtfCC+h
EFsQE8Xkc2kYZ7c1ZlejClNeBLtsxH44QbSrhENjFBjqVQRy74KC6dqNQQg5SC9n
0c2VSWb0VVqq5LENNZAe3p5X6OOZQUyjz8PW1uO+U6nyzZyNMzvbvcRwV3/AavTr
bj/3AAuHDdgdqKIcX56hTcWBq9DOq6Y6Zmxql/sLSj93XuzTK4t1FbcdjLChGLoR
rNFQZz9E4EP2dN1r8ums/CKVZE9uZZeoH9F0rP0FKg+uRGHUQAOv2Q==
=hqah
-----END PGP SIGNATURE-----
--=-=-=--


From nobody Mon May 16 13:59:30 2016
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 52B4612DA66 for ; Mon, 16 May 2016 13:59:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.899
X-Spam-Level: 
X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e4kNHIuA7sEM for ; Mon, 16 May 2016 13:59:27 -0700 (PDT)
Received: from mail.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 60DD112DA68 for ; Mon, 16 May 2016 13:59:27 -0700 (PDT)
Received: from localhost (ronin.smetech.net [209.135.209.5]) by mail.smetech.net (Postfix) with ESMTP id 26C42F2404B; Mon, 16 May 2016 16:59:27 -0400 (EDT)
X-Virus-Scanned: amavisd-new at smetech.net
Received: from mail.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id 5mSkoT2-B2FA; Mon, 16 May 2016 16:42:07 -0400 (EDT)
Received: from [192.168.7.153] (70-91-193-41-BusName-NewEngland.hfc.comcastbusiness.net [70.91.193.41]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.smetech.net (Postfix) with ESMTP id 8F972F24013; Mon, 16 May 2016 16:59:15 -0400 (EDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_FF44D2E8-3F68-4C68-BA68-A7ECA3FF7898"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Russ Housley 
In-Reply-To: <06a801d1ae13$747d37b0$5d77a710$@augustcellars.com>
Date: Mon, 16 May 2016 16:59:14 -0400
Message-Id: <65D003C1-1A44-47D2-83B2-70D1022A1FD3@vigilsec.com>
References: <064101d1ad9f$798f3a10$6cadae30$@augustcellars.com> <201605141722.u4EHMaua000470@d03av03.boulder.ibm.com> <06a801d1ae13$747d37b0$5d77a710$@augustcellars.com>
To: Jim Schaad 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: 
Cc: spasm@ietf.org
Subject: Re: [Spasm] Comments on draft-housley-spasm-eku-constraints-00
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 16 May 2016 20:59:28 -0000

--Apple-Mail=_FF44D2E8-3F68-4C68-BA68-A7ECA3FF7898
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Jim:

> While the EKU extension is not listed as being an AA cert extension in =
RFC 5755, I can easily envision cases where one would put an EKU =
extension in an AA certificate to restrict the permitted usages of that =
AA certificate.

I do not see it.  There is not a key in an attribute certificate, so =
there cannot be a key usage or extended key usage.

Russ


--Apple-Mail=_FF44D2E8-3F68-4C68-BA68-A7ECA3FF7898
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

Jim:

While the =
EKU extension is not listed as being an AA cert extension in RFC 5755, I =
can easily envision cases where one would put an EKU extension in an AA =
certificate to restrict the permitted usages of that AA =
certificate.

I do =
not see it.  There is not a key in an attribute certificate, so =
there cannot be a key usage or extended key =
usage.

Russ

=

--Apple-Mail=_FF44D2E8-3F68-4C68-BA68-A7ECA3FF7898--


From nobody Mon May 16 14:12:41 2016
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 189B012D52C for ; Mon, 16 May 2016 14:12:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Level: 
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tVlzblre5s4u for ; Mon, 16 May 2016 14:12:39 -0700 (PDT)
Received: from mail.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id EE5E212D1E7 for ; Mon, 16 May 2016 14:12:38 -0700 (PDT)
Received: from localhost (ronin.smetech.net [209.135.209.5]) by mail.smetech.net (Postfix) with ESMTP id B985EF2402E; Mon, 16 May 2016 17:12:38 -0400 (EDT)
X-Virus-Scanned: amavisd-new at smetech.net
Received: from mail.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id htoDhIswH8Cd; Mon, 16 May 2016 16:55:20 -0400 (EDT)
Received: from [192.168.7.153] (70-91-193-41-BusName-NewEngland.hfc.comcastbusiness.net [70.91.193.41]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.smetech.net (Postfix) with ESMTP id 20770F24013; Mon, 16 May 2016 17:12:28 -0400 (EDT)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Russ Housley 
In-Reply-To: <044a01d1af10$1548b8c0$3fda2a40$@gmail.com>
Date: Mon, 16 May 2016 17:12:26 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <316ECF88-612A-4131-8A96-E5F76671929A@vigilsec.com> <044a01d1af10$1548b8c0$3fda2a40$@gmail.com>
To: Santosh Chokhani 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: 
Cc: spasm@ietf.org
Subject: Re: [Spasm] My take on handling EKU constraints
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 16 May 2016 21:12:40 -0000

On May 15, 2016, at 9:12 PM, Santosh Chokhani =
 wrote:

> Hi Russ,
>=20
> Thanks for doing this.
>=20
> Here are my comments on the draft.
>=20
> 1.  You are requiring the extension to be critical.  This may cause =
denial
> of service during the transition stage while the application implement =
the
> processing logic.  May be start with RECOMMENDED to be critical and =
then
> transition to SHALL be critical when there is wider support for the
> extension.

I thought about this.  The logic that was used in the past was that the =
constraints can be ignored if they are not critical.  I=92m not sure =
which is worse.

> 2.  The language at the end of Section 2 regarding extension =
processing and
> tying it to criticality does not seem right to me.  Criticality of =
extension
> should not impact its processing  It also relates to my concerns =
regarding
> wrap up procedure in Section 3.  I would like the criticality part =
removed.

This seems like the same as comment 1.

> 3.  Now to the wrap up procedure in Section 3, I would recommend =
taking an
> intersection of permitted EKU Constraint State and EKU in the end
> certificate and then deleting the EKUs in the result that are in the
> excluded EKU Constraint State.  Now, the resulting EKU set should be
> returned to the application for enforcement.  It is quite possible =
that some
> applications do not care about EKUs at all.  I could live with if the =
group
> decides if the resulting EKU set is null, it is a path validation =
failure.
> But, my preference is for the application to enforce it.

As I said in my response to Jim, I was trying to not impact the API to =
the certification path validation library.  This would be a significant =
change.  It would trim the set if key purpose ids in the end-entity =
certificate to those that meet the restrictions.  It is easy to add to =
the specification, but it is harder to get deployed in applications.

What do others think?

Russ


From nobody Mon May 16 14:14:03 2016
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 C02E412DAA8 for ; Mon, 16 May 2016 14:14:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Level: 
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eWI6vRaIw4oF for ; Mon, 16 May 2016 14:14:01 -0700 (PDT)
Received: from mail.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id EDA5112DAA6 for ; Mon, 16 May 2016 14:14:00 -0700 (PDT)
Received: from localhost (ronin.smetech.net [209.135.209.5]) by mail.smetech.net (Postfix) with ESMTP id AC33EF24041; Mon, 16 May 2016 17:14:00 -0400 (EDT)
X-Virus-Scanned: amavisd-new at smetech.net
Received: from mail.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id POJP8Gx6xHsa; Mon, 16 May 2016 16:56:42 -0400 (EDT)
Received: from [192.168.7.153] (70-91-193-41-BusName-NewEngland.hfc.comcastbusiness.net [70.91.193.41]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.smetech.net (Postfix) with ESMTP id 1ACDEF24013; Mon, 16 May 2016 17:13:50 -0400 (EDT)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Russ Housley 
In-Reply-To: <045901d1af13$29d85d60$7d891820$@gmail.com>
Date: Mon, 16 May 2016 17:13:49 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <316ECF88-612A-4131-8A96-E5F76671929A@vigilsec.com> <044a01d1af10$1548b8c0$3fda2a40$@gmail.com> <045901d1af13$29d85d60$7d891820$@gmail.com>
To: Santosh Chokhani 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: 
Cc: spasm@ietf.org
Subject: Re: [Spasm] My take on handling EKU constraints
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 16 May 2016 21:14:02 -0000

Santosh:

> The I-D should address anyExtendedKeyUsage.  Either it should be =
prohibited
> from the permitted or excluded or the path validation engine should =
treat
> this value in either field as the UNIVERSAL set.

I=92d prefer to treat anyPurpose just like every other OID as far as the =
constraints are concerned.

	If it is in the excluded set, then is cannot appear.
	If it is in the permitted set, then it can appear.

What do others think?

Russ


From nobody Mon May 16 14:16:55 2016
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 805EB12B04D for ; Mon, 16 May 2016 14:16:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Level: 
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2kzR8cstrpd2 for ; Mon, 16 May 2016 14:16:53 -0700 (PDT)
Received: from mail.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 944EF12B008 for ; Mon, 16 May 2016 14:16:53 -0700 (PDT)
Received: from localhost (ronin.smetech.net [209.135.209.5]) by mail.smetech.net (Postfix) with ESMTP id 381B7F24041; Mon, 16 May 2016 17:16:53 -0400 (EDT)
X-Virus-Scanned: amavisd-new at smetech.net
Received: from mail.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id j-iNIKCa2Inw; Mon, 16 May 2016 16:59:35 -0400 (EDT)
Received: from [192.168.7.153] (70-91-193-41-BusName-NewEngland.hfc.comcastbusiness.net [70.91.193.41]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.smetech.net (Postfix) with ESMTP id 9E1DCF24013; Mon, 16 May 2016 17:16:42 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Russ Housley 
In-Reply-To: <045a01d1af14$8db12aa0$a9137fe0$@gmail.com>
Date: Mon, 16 May 2016 17:16:41 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <316ECF88-612A-4131-8A96-E5F76671929A@vigilsec.com> <044a01d1af10$1548b8c0$3fda2a40$@gmail.com> <045901d1af13$29d85d60$7d891820$@gmail.com> <045a01d1af14$8db12aa0$a9137fe0$@gmail.com>
To: Santosh Chokhani 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: 
Cc: spasm@ietf.org
Subject: Re: [Spasm] My take on handling EKU constraints
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 16 May 2016 21:16:54 -0000

Santosh:

> Some discussion of OCSPSigning EKU in permitted field to accommodate
> Delegated OCSP trust model will be useful.  May be in Security
> Considerations Section.

We could add a discussion about the consequences of a particular EKU in =
the end-entity certificate, but I cannot see why that is needed here.  =
You seem to be thinking about some specific concern, please say more.

Russ


From nobody Mon May 16 14:22:09 2016
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 1E98412DACB for ; Mon, 16 May 2016 14:22:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Level: 
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fhag0YImYSAX for ; Mon, 16 May 2016 14:22:06 -0700 (PDT)
Received: from mail.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 3C06512DAC9 for ; Mon, 16 May 2016 14:22:06 -0700 (PDT)
Received: from localhost (ronin.smetech.net [209.135.209.5]) by mail.smetech.net (Postfix) with ESMTP id B9AB1F2402E; Mon, 16 May 2016 17:22:05 -0400 (EDT)
X-Virus-Scanned: amavisd-new at smetech.net
Received: from mail.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id zdUgTGYw+KwH; Mon, 16 May 2016 17:04:57 -0400 (EDT)
Received: from [192.168.7.153] (70-91-193-41-BusName-NewEngland.hfc.comcastbusiness.net [70.91.193.41]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.smetech.net (Postfix) with ESMTP id 2A5AEF24013; Mon, 16 May 2016 17:22:05 -0400 (EDT)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Russ Housley 
In-Reply-To: <1b87369d-9812-b5c0-9631-ba9e638fd6d4@seantek.com>
Date: Mon, 16 May 2016 17:22:04 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <14315127-9A40-4F56-874E-3725D9EF08A6@vigilsec.com>
References: <316ECF88-612A-4131-8A96-E5F76671929A@vigilsec.com> <1b87369d-9812-b5c0-9631-ba9e638fd6d4@seantek.com>
To: Sean Leonard 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: 
Cc: spasm@ietf.org
Subject: Re: [Spasm] My take on handling EKU constraints
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 16 May 2016 21:22:07 -0000

On May 16, 2016, at 2:16 AM, Sean Leonard  wrote:

> Hello:
>=20
> In the ASN.1 module (to be written), it's important to specify whether =
this extension uses IMPLICIT, EXPLICIT, or AUTOMATIC tagging. I am =
guessing folks don't want to use AUTOMATIC tagging, even though it's =
recommended by the latest ASN.1 standards because it's "easy". My =
personal preference is for EXPLICIT tagging. However, the extended key =
usage extension is defined in the IMPLICIT module in RFC 5280, so it's =
IMPLICIT...this means that if you want symmetry with the EKU extension, =
you should say it's IMPLICIT.

I was assuming that IMPLICIT would be used.

> Is there a way, using the latest ASN.1 syntax, to specify =
"either-or-or-both", i.e., the EKUConstraints SEQUENCE must have at =
least one element, possibly two, but not zero?

The text already says that.

> As I understand it, "permitted" takes greater precedence over =
"excluded". I.e., if the extension has both permitted AND excluded, then =
really, only "permitted" is going to have meaningful effect.

No, the text says that if the key purpose is the the excluded set, then =
it is excluded.

To resolve Jim=92s comments I suggested:

   (h)  If the EKU extension is included in the end-entity certificate,
        then confirm that the values meet the restrictions in the
        permitted_key_purpose_ids and excluded_key_purpose_ids state
        variables as follows:

        (1)  If excluded_key_purpose_ids state variable is empty, then
             return a failure indication and an appropriate reason.

        (2)  If excluded_key_purpose_ids state variable is not empty,
             then confirm that none of the key purpose identifiers are
             present in the set.  If any are present, then return a
             failure indication and an appropriate reason.

        (3)  If permitted_key_purpose_ids state variable is not special
             value that represents the universal set, then confirm that
             all of the key purpose identifiers are present in the set.
             If any are missing, then returning a failure indication and
             an appropriate reason.

Russ


From nobody Mon May 16 14:28:05 2016
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 0931312D129 for ; Mon, 16 May 2016 14:28:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Level: 
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XVZaavWD2mnU for ; Mon, 16 May 2016 14:28:03 -0700 (PDT)
Received: from mail.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 3A34A12B043 for ; Mon, 16 May 2016 14:28:03 -0700 (PDT)
Received: from localhost (ronin.smetech.net [209.135.209.5]) by mail.smetech.net (Postfix) with ESMTP id F35E4F24041; Mon, 16 May 2016 17:28:02 -0400 (EDT)
X-Virus-Scanned: amavisd-new at smetech.net
Received: from mail.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id XLmigFobN5Ht; Mon, 16 May 2016 17:10:44 -0400 (EDT)
Received: from [192.168.7.153] (70-91-193-41-BusName-NewEngland.hfc.comcastbusiness.net [70.91.193.41]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.smetech.net (Postfix) with ESMTP id 5BC89F24013; Mon, 16 May 2016 17:27:52 -0400 (EDT)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Russ Housley 
In-Reply-To: <18251.1463404421@obiwan.sandelman.ca>
Date: Mon, 16 May 2016 17:27:51 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <316ECF88-612A-4131-8A96-E5F76671929A@vigilsec.com> <18251.1463404421@obiwan.sandelman.ca>
To: Michael Richardson 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: 
Cc: spasm@ietf.org
Subject: Re: [Spasm] My take on handling EKU constraints
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 16 May 2016 21:28:04 -0000

On May 16, 2016, at 9:13 AM, Michael Richardson  =
wrote:

>=20
> Initial read had me confused by:
>=20
>  Conforming CAs MUST mark this extension as critical, and conforming
>  CAs MUST NOT issue certificates where this extension is an empty
>  sequence.  That is, either the permittedKeyPurposeIds field or the
>  excludedKeyPurposeIds field MUST be present.
>=20
> vs:
>  If the set is empty, then the
>  certification path will be considered invalid if the end-entity
>  certificate includes an extended key usage extension
>=20
> I suggest initial paragraph be changed to:
>  Conforming CAs MUST mark this extension as critical, and conforming
>  CAs MUST NOT issue certificates where this extension is an empty
>  sequence.  That is, either the permittedKeyPurposeIds field or the
>  excludedKeyPurposeIds field MUST be present, but the field MAY =
contain
>  an empty set.

That is not what I=92m trying to say.

    EKUConstraints ::=3D SEQUENCE {
       permittedKeyPurposeIds   [0] KeyPurposeIds OPTIONAL,
       excludedKeyPurposeIds    [1] KeyPurposeIds OPTIONAL }

The SEQUNCE has two optional things.  One or the other or both must be =
present.


> typo:
>  The initial value is a is the empty set.
>  =3D> The initial value is the empty set.

Fixed.


> I see the AND/OR operation on permitted/excluded as the chain is =
walked.
> Clearly an intermediate CA may issue an EKU that includes things that =
the
> parent/root CA did not want to include, and that this is an anomaly, =
but not
> an error.
>=20
> With the SHA1->SHA256 roll I found it interesting that many root CAs
> generated new SHA256 keys which they used to sign the intermediate CAs =
again,
> and so one "upgrades" the chain not by replacing the entire chain, but =
by
> just updating the root.  The same thing could be used here, with a =
root CA
> signing an intermediate and providing different EKUs--- depending upon =
which
> chain the validating end has, they could come to different =
conclusions.
>=20
> I wonder if some discussion of this is meritted?  Is this a bug or a =
feature?

I do not think this is different than the situation with name =
constraints or policy constraints in RFC 5280.

I do not know if it needs highlighted.

Russ


From nobody Mon May 16 14:40:08 2016
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 9CBDE12DACF for ; Mon, 16 May 2016 14:40:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Level: 
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U0U0J2_Mv6QJ for ; Mon, 16 May 2016 14:40:06 -0700 (PDT)
Received: from mail.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id B5F2412D162 for ; Mon, 16 May 2016 14:40:06 -0700 (PDT)
Received: from localhost (ronin.smetech.net [209.135.209.5]) by mail.smetech.net (Postfix) with ESMTP id 76BA8F2402E; Mon, 16 May 2016 17:40:06 -0400 (EDT)
X-Virus-Scanned: amavisd-new at smetech.net
Received: from mail.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id cw5nejXc5Hxx; Mon, 16 May 2016 17:22:57 -0400 (EDT)
Received: from [192.168.7.153] (70-91-193-41-BusName-NewEngland.hfc.comcastbusiness.net [70.91.193.41]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.smetech.net (Postfix) with ESMTP id 4152AF24013; Mon, 16 May 2016 17:40:05 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Russ Housley 
In-Reply-To: <00ca01d1af9e$6621f4d0$3265de70$@augustcellars.com>
Date: Mon, 16 May 2016 17:40:04 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <064101d1ad9f$798f3a10$6cadae30$@augustcellars.com> <122A4A08-690F-4071-87D2-C9E0684B6899@vigilsec.com> <00ca01d1af9e$6621f4d0$3265de70$@augustcellars.com>
To: Jim Schaad 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: 
Cc: spasm@ietf.org
Subject: Re: [Spasm] Comments on draft-housley-spasm-eku-constraints-00
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 16 May 2016 21:40:07 -0000

>=20
>> 3.  I believe that step (p) (1) is missing a step, although it could=20=

>> potentially go into step (h) in section 3.5
>> 	(2) if excludedKeyPurposesIds is present in the certificate, set =
the
>> excluded_key_purpose_ids state varble to..   Set the =
permittedKeyPurposeIds
>> to the intersection of the result from step (1) and the inverse of =
the=20
>> excludedKeyPurposesIds.
>=20
> I do not think this is needed.  The corrected logic below in the =
wrap-up
> step should be enough.
>=20
>>=20
>> 	(3) if the excludedKeyPurposesId is the empty set, then fail the=20=

>> validation procedure
>>=20
>> 	The certificate should be considered invalid regardless of the=20=

>> presence of the EKU extension in the EE certificate.
>=20
> Swapping the order probably make things more clear:
>=20
>   (h)  If the EKU extension is included in the end-entity certificate,
>        then confirm that the values meet the restrictions in the
>        permitted_key_purpose_ids and excluded_key_purpose_ids state
>        variables as follows:
>=20
>        (1)  If excluded_key_purpose_ids state variable is empty, then
>             return a failure indication and an appropriate reason.
> [JLS] I think this is not a correct test - I would look at the =
permitted set
> being empty not the excluded set.

Indeed.  Cut-and-paste error.

>=20
>        (2)  If excluded_key_purpose_ids state variable is not empty,
>             then confirm that none of the key purpose identifiers are
>             present in the set.  If any are present, then return a
>             failure indication and an appropriate reason.
>=20
>        (3)  If permitted_key_purpose_ids state variable is not special
>             value that represents the universal set, then confirm that
>             all of the key purpose identifiers are present in the set.
>             If any are missing, then returning a failure indication =
and
>             an appropriate reason.
>=20
> [JLS] And if the EKU extension is not included in the end-entity =
certificate
> what happens if the permitted_key_usage_purpose_ids state variable is =
the
> empty set?

Then the validation is successful because the constraints are not =
violated.

Russ


From nobody Mon May 16 20:57:04 2016
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 48A2312D135 for ; Mon, 16 May 2016 20:57:02 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, 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 v9iujcDFcoWr for ; Mon, 16 May 2016 20:57:00 -0700 (PDT)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (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 8867C12D0AF for ; Mon, 16 May 2016 20:57:00 -0700 (PDT)
Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 55B10509B6 for ; Mon, 16 May 2016 23:56:59 -0400 (EDT)
To: spasm@ietf.org
References: <316ECF88-612A-4131-8A96-E5F76671929A@vigilsec.com> <1b87369d-9812-b5c0-9631-ba9e638fd6d4@seantek.com> <14315127-9A40-4F56-874E-3725D9EF08A6@vigilsec.com>
From: Sean Leonard 
Message-ID: <405ff968-9d4b-42a8-2234-1209820a02b9@seantek.com>
Date: Mon, 16 May 2016 20:56:06 -0700
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0
MIME-Version: 1.0
In-Reply-To: <14315127-9A40-4F56-874E-3725D9EF08A6@vigilsec.com>
Content-Type: multipart/alternative; boundary="------------1918CB92EDA25C15BF3E20AE"
Archived-At: 
Subject: Re: [Spasm] My take on handling EKU constraints
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 17 May 2016 03:57:02 -0000

This is a multi-part message in MIME format.
--------------1918CB92EDA25C15BF3E20AE
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

On 5/16/2016 2:22 PM, Russ Housley wrote:
> On May 16, 2016, at 2:16 AM, Sean Leonard  wrote:
>
>> Hello:
>>
>> In the ASN.1 module (to be written), it's important to specify whether this extension uses IMPLICIT, EXPLICIT, or AUTOMATIC tagging. I am guessing folks don't want to use AUTOMATIC tagging, even though it's recommended by the latest ASN.1 standards because it's "easy". My personal preference is for EXPLICIT tagging. However, the extended key usage extension is defined in the IMPLICIT module in RFC 5280, so it's IMPLICIT...this means that if you want symmetry with the EKU extension, you should say it's IMPLICIT.
> I was assuming that IMPLICIT would be used.

Ok; IMPLICIT needs to be in the next draft then.

>
>> Is there a way, using the latest ASN.1 syntax, to specify "either-or-or-both", i.e., the EKUConstraints SEQUENCE must have at least one element, possibly two, but not zero?
> The text already says that.

The text does, but not the ASN.1. I.e., an ASN.1 compiler can't enforce 
the constraint as written in the text. I see that as a flaw.

>
>> As I understand it, "permitted" takes greater precedence over "excluded". I.e., if the extension has both permitted AND excluded, then really, only "permitted" is going to have meaningful effect.
> No, the text says that if the key purpose is the the excluded set, then it is excluded.

I see how what I wrote could be misinterpreted; sorry about that. Of 
course if the key purpose is in the excluded set, then it is excluded. 
In that sense, an excluded OID takes precedence over the same OID being 
in the permitted set.

The point is that putting an OID on both lists is pointless and 
needlessly complicated. If an OID is on the permitted list AND the 
excluded list, then, why is it on either list at all?

Section 3.5 (h) (i) says:

         (1)  If permitted_key_purpose_ids state variable is not special
              value that represents the universal set, then confirm that
              all of the key purpose identifiers are present in the set.
              If any are missing, then returning a failure indication and
              an appropriate reason.



The permitted set of OIDs can, apparently, be: "infinity" (unbounded), 
"nonzero" (finite: bounded to only those listed), or "none" (zero). The 
moment ANY certificate in the path mentions a permitted set, you are 
forever thrown out of "infinity". It is now finite. Possibly zero. So 
the effect of having further excluded sets (after introducing the first 
permitted set), is only to whittle away at the finite permitted set of 
OIDs. You may as well either repeat the list of permitted EKUs, or 
whittle it down in the next certificate in the chain. Mentioning 
excluded sets only makes sense at the top of the chain, before the first 
"permitted set" is introduced.

Example: consider a single CA cert in the chain that mentions both 
permitted and excluded:
{
permitted:
1.1.1.1
1.1.1.2

excluded:
1.1.1.2
1.1.1.3
1.1.1.4
}

If only 1.1.1.1 and 1.1.1.2 are permitted, then mentioning 1.1.1.3 and 
1.1.1.4 as "excluded" serves no purpose. You may as well drop 1.1.1.3 
and 1.1.1.4. Furthermore, since 1.1.1.2 is excluded, why bother 
mentioning it in "permitted"? That likewise serves no purpose. You may 
as well have said:

{
permitted:
1.1.1.1
}

and have been done with it.

Mentioning the excluded set at all, only makes sense when there is no 
defined permitted set (i.e., the permitted set is the "special value 
that represents the universal set"). In that way, excluding those OIDs 
basically means we have the universal set ("infinity") MINUS a few 
mentioned OIDs.

That is why I am (increasingly) harping on making this extension a 
CHOICE, rather than a SEQUENCE that can permit both.

Sean


--------------1918CB92EDA25C15BF3E20AE
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 7bit


  
    
  
  
    
On 5/16/2016 2:22 PM, Russ Housley
      wrote:

    

    

      
On May 16, 2016, at 2:16 AM, Sean Leonard <dev+ietf@seantek.com> wrote:



      

        
Hello:

In the ASN.1 module (to be written), it's important to specify whether this extension uses IMPLICIT, EXPLICIT, or AUTOMATIC tagging. I am guessing folks don't want to use AUTOMATIC tagging, even though it's recommended by the latest ASN.1 standards because it's "easy". My personal preference is for EXPLICIT tagging. However, the extended key usage extension is defined in the IMPLICIT module in RFC 5280, so it's IMPLICIT...this means that if you want symmetry with the EKU extension, you should say it's IMPLICIT.


      

      
I was assuming that IMPLICIT would be used.

    

    

    Ok; IMPLICIT needs to be in the next draft then.

    

    

      



      

        
Is there a way, using the latest ASN.1 syntax, to specify "either-or-or-both", i.e., the EKUConstraints SEQUENCE must have at least one element, possibly two, but not zero?


      

      
The text already says that.

    

    

    The text does, but not the ASN.1. I.e., an ASN.1 compiler can't
    enforce the constraint as written in the text. I see that as a flaw.

    

    

      



      

        
As I understand it, "permitted" takes greater precedence over "excluded". I.e., if the extension has both permitted AND excluded, then really, only "permitted" is going to have meaningful effect.


      

      
No, the text says that if the key purpose is the the excluded set, then it is excluded.

    

    

    I see how what I wrote could be misinterpreted; sorry about that. Of
    course if the key purpose is in the excluded set, then it is
    excluded. In that sense, an excluded OID takes precedence over the
    same OID being in the permitted set.

    

    The point is that putting an OID on both lists is pointless and
    needlessly complicated. If an OID is on the permitted list AND the
    excluded list, then, why is it on either list at all?

    

    Section 3.5 (h) (i) says:

    
        (1)  If permitted_key_purpose_ids state variable is not special
             value that represents the universal set, then confirm that
             all of the key purpose identifiers are present in the set.
             If any are missing, then returning a failure indication and
             an appropriate reason.


    

    

    The permitted set of OIDs can, apparently, be: "infinity"
    (unbounded), "nonzero" (finite: bounded to only those listed), or
    "none" (zero). The moment ANY certificate in the path mentions a
    permitted set, you are forever thrown out of "infinity". It is now
    finite. Possibly zero. So the effect of having further excluded sets
    (after introducing the first permitted set), is only to whittle away
    at the finite permitted set of OIDs. You may as well either repeat
    the list of permitted EKUs, or whittle it down in the next
    certificate in the chain. Mentioning excluded sets only makes sense
    at the top of the chain, before the first "permitted set" is
    introduced.

    

    Example: consider a single CA cert in the chain that mentions both
    permitted and excluded:

    {

    permitted:

    1.1.1.1

    1.1.1.2

    

    excluded:

    1.1.1.2

    1.1.1.3

    1.1.1.4

    }

    

    If only 1.1.1.1 and 1.1.1.2 are permitted, then mentioning 1.1.1.3
    and 1.1.1.4 as "excluded" serves no purpose. You may as well drop
    1.1.1.3 and 1.1.1.4. Furthermore, since 1.1.1.2 is excluded, why
    bother mentioning it in "permitted"? That likewise serves no
    purpose. You may as well have said:

    

    {

    permitted:

    1.1.1.1

    }

    

    and have been done with it.

    

    Mentioning the excluded set at all, only makes sense when there is
    no defined permitted set (i.e., the permitted set is the "special
    value that represents the universal set"). In that way, excluding
    those OIDs basically means we have the universal set ("infinity")
    MINUS a few mentioned OIDs.

    

    That is why I am (increasingly) harping on making this extension a
    CHOICE, rather than a SEQUENCE that can permit both.

    

    Sean

    

  


--------------1918CB92EDA25C15BF3E20AE--


From nobody Mon May 16 21:22:56 2016
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 1172612B04D for ; Mon, 16 May 2016 21:22:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level: 
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, 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 D87WVslqUCmr for ; Mon, 16 May 2016 21:22:53 -0700 (PDT)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (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 7579712B028 for ; Mon, 16 May 2016 21:22:53 -0700 (PDT)
Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 8D09350A73 for ; Tue, 17 May 2016 00:22:52 -0400 (EDT)
To: spasm@ietf.org
References: <316ECF88-612A-4131-8A96-E5F76671929A@vigilsec.com> <044a01d1af10$1548b8c0$3fda2a40$@gmail.com> <000f01d1af31$5a760f80$0f622e80$@augustcellars.com> <054b01d1af78$d79e09d0$86da1d70$@gmail.com> <5739D2D5.8020809@cs.tcd.ie>
From: Sean Leonard 
Message-ID: <4e32597d-e1a1-d5b3-ca37-453b9a7e1c25@seantek.com>
Date: Mon, 16 May 2016 21:21:59 -0700
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0
MIME-Version: 1.0
In-Reply-To: <5739D2D5.8020809@cs.tcd.ie>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: [Spasm] Maybe just do permitted constraints only Re: My take on handling EKU constraints
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 17 May 2016 04:22:55 -0000

On 5/16/2016 7:01 AM, Stephen Farrell wrote:
> [...]
> I hope we all agree that this kind of thing ought be mostly
> driven by what those implementing or deploying certificate
> validation and applications want and are willing to do and
> what they think makes sense in terms of APIs etc. For example,
> I wondered which application(s) you are involved in developing
> you meant in the above.
>
> One thing I think we need to be quite careful about with all
> of this planned work is to not repeat mistakes we (incl. me)
> made in the past where we designed a bunch of PKI machinery
> that didn't get used, or that made it harder to use PKI, or
> that made PKI less useful.
I really want to channel Stephen here on this point about avoiding=20
making algorithms too complicated, that people won't use.

Sure it is possible to write algorithms that do all this=20
"intersectionality" and "differential" stuff with permitted and excluded =

items. But maybe it doesn't make real-world sense (as we have seen with=20
lackluster support for Name Constraints).

Taking a step back, I question the need for the excluded set. By=20
default, a trust anchor that is defined purely by a certificate (i.e., a =

self-signed, self-issued one, one under the control of the trust anchor=20
party) will naturally "want" universal capabilities: it is more=20
economically valuable. Of course if I create a CA for my own purposes, I =

will imbue it with universal trust. I wouldn't exclude myself from=20
issuing certs for specific applications.

The situation changes when the trust point delegates its authority to=20
the next guy down the line (aka, issues a certificate). I want to be=20
sure that the next guy doesn't abuse my universal authority, so I want=20
to constrain him/her/it. Therefore, I say: "you can do these enumerated=20
things, but I'm not giving you a blank check". Specifying an excluded=20
set is tantamount to writing an /almost/ blank check: "you can put any=20
number in the amount field, just as long as it's not one million, or=20
four billion". Not a good situation. Principle of least privilege, folks.=


Now it is possible (in fact, quite likely) that a certificate-using=20
application will want to exclude purposes entirely from the path. Maybe=20
the user (or sysadmins) "trust" some CA for what it contractually claims =

to limit itself to issue, but no matter what, the user is never going to =

"trust" that CA for "Kernel Mode Signing". That exclusion is perfectly=20
valid (and perhaps can be specified in the path processing algorithm,=20
especially at the "top"), but is not part of the artifacts in the=20
certification path itself.

The way that I understand how the Microsoft EKU implementation works, is =

that it's a funnel of permitted usages only. At the topmost level, the=20
user/application says exactly what EKUs it will allow the trust anchor=20
to promulgate: everything ("Enable all purposes for this certificate"),=20
nothing ("Disable all purposes for this certificate"), or exactly a=20
finite list of specific things ("Enable only the following purposes:=20
[OIDs]"). At each step in the certification path, the cert can contract=20
the set of usages, but cannot expand them. What is effective at the=20
end-entity certificate is just the intersection of all permitted usages. =

The dialog box says: "Note: you may only edit the certificate purposes=20
that are allowed by the certification path."

We can make things a lot simpler if we make this EKU Constraints=20
extension just be a list of permittedKeyPurposeIds, in which case, it=20
would be syntactically identical to ExtKeyUsageSyntax.

I would also posit that Name Constraints would be a lot easier to=20
implement, and a lot more useful, if they were defined as "permitted"=20
only, for analogous reasons.

(I have no comment or insight on certificate policies, other than, a lot =

of people find them awfully complicated.)

Sean


From nobody Tue May 17 06:26:30 2016
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 C9E8112D5BA for ; Tue, 17 May 2016 06:26:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WyCkWALmgNs8 for ; Tue, 17 May 2016 06:26:27 -0700 (PDT)
Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CD4E12D5B9 for ; Tue, 17 May 2016 06:26:27 -0700 (PDT)
Received: by mail-qg0-x231.google.com with SMTP id f92so7743380qgf.0 for ; Tue, 17 May 2016 06:26:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=xHiQaikNwaC5ywHb8CcUE764sMeq/iN/IQxzRq0xH10=; b=qlrBExH2AE6KBNX3WEshiojgvrsm8xVAnP7nhLC+9oDzucag8XNCfQ+BQWi7hmFFhd ezCChXLIBczfC76mfmLq4Pox7CRB6OZTgOnWFbuY60BSN/+GzITgoGDZINlYFRbQyvSB uDVkPnaCXYfTHsMIGICKVMnrx/DSwiNJT2tFhZXrKrYWwNd3xmx7j8+83dWJ/tXa3sxl 9zfW3zVJI9SxZm44YUg+WhsRZMwNK3q3EvoSpX0Ztjta41GEAN1JrhRcsqC0Ywe8Mi38 36H0G1t0HHU21wxsHsUzuNSXovMdpiW7nXWajG+YH/6Rwgoc9EeYoavHiQKOjXomKFuD pc5g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=xHiQaikNwaC5ywHb8CcUE764sMeq/iN/IQxzRq0xH10=; b=gRWohw0eCIG0UHuZM9n380Y6OHcx8WSzKf2Y9nOcCwCeSDdNIzRRwtD6VFiGHnNGX/ pA8WzMwAQIkSfuZpBftOLo5fkXPm5+EfsCK+0ebivp5xPAsdRUJMc0H7VuQrX+vuE2Ij LR6eWeifQsNa6d2odt9k3z0o1MsyUGNTu92I9z9oPam9fGth02AJRtqr+59dd2JRaHes j1CIr6PMX8nWSHbjlrSW+82BGfHoZVEh62kwaFvPKMoXZXt/o6R3wfTD1xOYxoyyh/p4 iEVKsMMnsJTEAK9S7xPKkaNrRbu7MYjfobCgZfNArvWlLXq9loacR6dN+pO+ieHNWQkE VYBQ==
X-Gm-Message-State: AOPr4FWsJC/xsRKjV78U3mPijIClgTpahSSmx47m/j0WKj70WCFbhnyt/IYunnfVjVCuKw==
X-Received: by 10.140.28.8 with SMTP id 8mr1327199qgy.91.1463491586302; Tue, 17 May 2016 06:26:26 -0700 (PDT)
Received: from SantoshBrain (pool-108-31-66-4.washdc.fios.verizon.net. [108.31.66.4]) by smtp.gmail.com with ESMTPSA id 141sm1258476qke.18.2016.05.17.06.26.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 May 2016 06:26:25 -0700 (PDT)
From: "Santosh Chokhani" 
To: "'Russ Housley'" 
References: <316ECF88-612A-4131-8A96-E5F76671929A@vigilsec.com> <044a01d1af10$1548b8c0$3fda2a40$@gmail.com> 
In-Reply-To: 
Date: Tue, 17 May 2016 09:26:21 -0400
Message-ID: <023a01d1b03f$b444c8d0$1cce5a70$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQG9AVJW+Y7xpWAUdsUf0IIYfjAqNAGVztXGAdP+cJKfyyeDsA==
Content-Language: en-us
Archived-At: 
Cc: spasm@ietf.org
Subject: Re: [Spasm] My take on handling EKU constraints
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 17 May 2016 13:26:29 -0000

Hi Russ,

See below in-line.

-----Original Message-----
From: Russ Housley [mailto:housley@vigilsec.com] 
Sent: Monday, May 16, 2016 5:12 PM
To: Santosh Chokhani 
Cc: spasm@ietf.org
Subject: Re: [Spasm] My take on handling EKU constraints


On May 15, 2016, at 9:12 PM, Santosh Chokhani 
wrote:

> Hi Russ,
> 
> Thanks for doing this.
> 
> Here are my comments on the draft.
> 
> 1.  You are requiring the extension to be critical.  This may cause 
> denial of service during the transition stage while the application 
> implement the processing logic.  May be start with RECOMMENDED to be 
> critical and then transition to SHALL be critical when there is wider 
> support for the extension.

I thought about this.  The logic that was used in the past was that the
constraints can be ignored if they are not critical.  I'm not sure which is
worse.

> 2.  The language at the end of Section 2 regarding extension 
> processing and tying it to criticality does not seem right to me.  
> Criticality of extension should not impact its processing  It also 
> relates to my concerns regarding wrap up procedure in Section 3.  I would
like the criticality part removed.

This seems like the same as comment 1.
[Santosh] It is a bit different.  The I-D says "Conforming applications MUST
be able to process this extension.  If
   any CA certificate in the certification path includes an EKU constraints
extension that is marked as critical, and the end-entity
   certificate includes an extended key usage certificate extension,
   then the application MUST either process the EKU constraint or reject
   the certificate."  I would say even if the extension is marked
non-critical and end-entity certificate includes EKU, it needs to be
processed.  We do not generally change the processing semantics of an
extension due to criticality.  If what you are saying is that if the end
certificate does not include EKU and the application does not understand the
EKU constraints extension, it can be ignored.  But, that is dangerous since
the application will think the certificate is good for all key purposes and
the path is not.  Also, this will be impacted by the decision on whether you
choose input as Jim Schaad has suggested.  In that scenario, the extension
does need to be processed even if the end certificate does not have EKU.

> 3.  Now to the wrap up procedure in Section 3, I would recommend 
> taking an intersection of permitted EKU Constraint State and EKU in 
> the end certificate and then deleting the EKUs in the result that are 
> in the excluded EKU Constraint State.  Now, the resulting EKU set 
> should be returned to the application for enforcement.  It is quite 
> possible that some applications do not care about EKUs at all.  I 
> could live with if the group decides if the resulting EKU set is null, it
is a path validation failure.
> But, my preference is for the application to enforce it.

As I said in my response to Jim, I was trying to not impact the API to the
certification path validation library.  This would be a significant change.
It would trim the set if key purpose ids in the end-entity certificate to
those that meet the restrictions.  It is easy to add to the specification,
but it is harder to get deployed in applications.
[Santosh] The way the current logic is, if the path is not good for all the
EKUs in the end certificate, the path is invalid.  That may be ok for
Enterprise PKI and does reject mis-issued certificates assuming the
Enterprise PKI designer has done static analysis on EKU constraint required
at each stage.  But, this does not help the cross-certified environment.
Say one PKI wants to trust another for client authentication and S/MIME, but
not for Smart Card Logon.  The proposed approach will not work unless the
end certificate are issued for single key purpose.

[Santosh] The input approach suggested is less complicated that the approach
I suggest.  Under my approach, there is a possibility that you will need to
output a flag with the EKUs whether the list is excluded or not since there
is an edge case where only excluded get accumulated.

What do others think?
[Santosh] I have spoken as someone who designs lots of PKI stuff.  It would
be nice to hear from those who implement path validation libraries and
develop PK enabled applications as to what they prefer.  The proposed
approach of hard failure of a perfectly valid certificate which is good for
the key purpose the application desires is wrong.

Russ



From nobody Tue May 17 06:29:29 2016
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 B6ABF12D5BE for ; Tue, 17 May 2016 06:29:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6FeUC_GoXPaD for ; Tue, 17 May 2016 06:29:27 -0700 (PDT)
Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::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 60F0312D51F for ; Tue, 17 May 2016 06:29:27 -0700 (PDT)
Received: by mail-qk0-x229.google.com with SMTP id n63so8205357qkf.0 for ; Tue, 17 May 2016 06:29:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=Gc/lu1q8sStJNP++zUSEF2KU4dhtZt+B/tH6seEnTaM=; b=daOKnhoofQf5T8ioHI1rqcrF9Bl5gmkN6K31HAG+ddhw0ShaJWKnT3ajlb4M5voUwR 57CyhWfXTmhJTqvYNYv6hvJ++I5tEa+oYgBvqY0gXREGF3Dx5NX2jXIwWHTXrjEUvjW8 YnmRn9uFByUncAyJz3F9OmDjRYiJw/cphBD+7iCXVxStCSNg4KqciuD2QONFcCcpvIZd sKTUKJ7MjHO1l+R0DQMbHD1onAAs4BTpKlvilT3vLO+ZzeaZLtbFe0uWAPtDP26BSPpQ mcJvkN1Y9O/KW/XCuMrIXiz1mlgPwZWIEaAWmoa2I6l8sO1M5ni2R0I4zTZienMHShLq bPrA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=Gc/lu1q8sStJNP++zUSEF2KU4dhtZt+B/tH6seEnTaM=; b=moYTct1VMbTH8tj6Hxo+7YYQ1bkNMdfZd0WVQZdhCRL1iVfnebgOqsdT5j+0Es5SZp 1Y4OfdbouqkJ79PeoqRi1tJxkpGqtgejovpDhCcp8wG8ZKxxqfYCbNRYPtbIDbzkhjKU O+Y08DM9KR1LeIU3ad2lOMMLu2sRfmrM0p6JDMlNRwkK6cL7/KuSpqYG+1A7ikrAIRaV D7IBikZOgOdgqtNO7asvVohiCtjddI4oIMW8ve16Tm7SU4epTF6VA+ivUBbP0nMFhnSR wzZxZgYWs4SUAu/AwF1z6tV4OyfUXxiUFGSKU3Wp8CCNPJI18VtMY0TCAIx6FWV3UiXn KNjQ==
X-Gm-Message-State: AOPr4FWKqsFwdVy4N1Bj7xXTFgBTX4Csz9Xn/wxSLdjZDCSud8gBqmB7yqqQch43U+ajtA==
X-Received: by 10.55.165.69 with SMTP id o66mr1442631qke.191.1463491766565; Tue, 17 May 2016 06:29:26 -0700 (PDT)
Received: from SantoshBrain (pool-108-31-66-4.washdc.fios.verizon.net. [108.31.66.4]) by smtp.gmail.com with ESMTPSA id v5sm1251283qhv.21.2016.05.17.06.29.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 May 2016 06:29:25 -0700 (PDT)
From: "Santosh Chokhani" 
To: "'Russ Housley'" 
References: <316ECF88-612A-4131-8A96-E5F76671929A@vigilsec.com> <044a01d1af10$1548b8c0$3fda2a40$@gmail.com> <045901d1af13$29d85d60$7d891820$@gmail.com> 
In-Reply-To: 
Date: Tue, 17 May 2016 09:29:21 -0400
Message-ID: <024a01d1b040$1fd17030$5f745090$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQG9AVJW+Y7xpWAUdsUf0IIYfjAqNAGVztXGAdsLs7cB0QyFI5+8bFOg
Content-Language: en-us
Archived-At: 
Cc: spasm@ietf.org
Subject: Re: [Spasm] My take on handling EKU constraints
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 17 May 2016 13:29:29 -0000

Hi Russ,

Regardless, the path validation logic needs to handle anyExtendedKeyUsage.

anyExtendedKeyUsage appearing in permitted does not make sense since the
field can be simply omitted.

anyExtendedKeyUsag appearing in excluded may make sense if you want the path
to be not valid for any specific EKU.

-----Original Message-----
From: Russ Housley [mailto:housley@vigilsec.com] 
Sent: Monday, May 16, 2016 5:14 PM
To: Santosh Chokhani 
Cc: spasm@ietf.org
Subject: Re: [Spasm] My take on handling EKU constraints

Santosh:

> The I-D should address anyExtendedKeyUsage.  Either it should be 
> prohibited from the permitted or excluded or the path validation 
> engine should treat this value in either field as the UNIVERSAL set.

I'd prefer to treat anyPurpose just like every other OID as far as the
constraints are concerned.

	If it is in the excluded set, then is cannot appear.
	If it is in the permitted set, then it can appear.

What do others think?

Russ



From nobody Tue May 17 06:32:31 2016
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 1174D12D152 for ; Tue, 17 May 2016 06:32:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nMZBTNmF0s6d for ; Tue, 17 May 2016 06:32:27 -0700 (PDT)
Received: from mail-qg0-x22d.google.com (mail-qg0-x22d.google.com [IPv6:2607:f8b0:400d:c04::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 84E7C12D5BF for ; Tue, 17 May 2016 06:32:27 -0700 (PDT)
Received: by mail-qg0-x22d.google.com with SMTP id f92so7854151qgf.0 for ; Tue, 17 May 2016 06:32:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=sMv+qzfsdjIBC2xGQI8BKFbcR2Gm9oWO1AS57SjsDP0=; b=Si8snCt2CNe2JjKCnlVVeewYt1NCLVRZ7idMBjthoQnxG4eSt/ramrwosJc+WlE8ab HG9t6oJ78Y61ZwnLYAyce0oCP5YGlcidMpdo75RXAJU2csAQuB6lZ6ekvh4TRV4pZj7b zmhzs0jzn5cMeLE80fSx0r3TPq2J9yuP1eF0THePj6zKVQU3JNeTcTQBKKrflA/uRcLm yY5cWdSWyvyVxEg7/aZ+zIuTZ1t/1QU4olIr/hPYxOEyInshULxsL69fNhjIC7Fgc/LR 6f0GuwA9ae8E4GE8dP+iTtxwExcK9z/dJ2KmlekuC5UDcmYoG4sz5ED5SUwujzefYG7M RfxQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=sMv+qzfsdjIBC2xGQI8BKFbcR2Gm9oWO1AS57SjsDP0=; b=BVDFoqC4nvWAOqcfvmUnRs1+JAXQmzNHZ012IgtkzImMG0cpxJ3pfdXLkmmU1+HFep MnVfhkmA9S9CV7Bfp++WF1FQ8fa5wXFXUw+PgUu9Tb0YboM54CwA9hP/LDLnXKUZO8Mu S37VyvsH5DD76OzILviPegSB3KBDBJ+jdVEJllzIXyhJcZOtvuKP3esPVO4ndy10Ingl qHTiYcPIv4+BabNl0lHWMRlJPCF771zMOCwHq4/MEwSaZa1Ami/7wffU89Mp+fhDrddO CnG3vgKDOdKINky1aSnIpmr9PLVUO/RvPA8wIQdXi3/3sjmJn4unhSHC2gdVxnrjGyDQ +5Xg==
X-Gm-Message-State: AOPr4FW/96R4MxvOUakrHDVwB6FFTrC6Z+AiBLvRMqAWTf4xpd9JGdA5h621ffNIOJZOjQ==
X-Received: by 10.140.246.68 with SMTP id r65mr1485133qhc.80.1463491946719; Tue, 17 May 2016 06:32:26 -0700 (PDT)
Received: from SantoshBrain (pool-108-31-66-4.washdc.fios.verizon.net. [108.31.66.4]) by smtp.gmail.com with ESMTPSA id 134sm1279155qkh.10.2016.05.17.06.32.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 May 2016 06:32:25 -0700 (PDT)
From: "Santosh Chokhani" 
To: "'Russ Housley'" 
References: <316ECF88-612A-4131-8A96-E5F76671929A@vigilsec.com> <044a01d1af10$1548b8c0$3fda2a40$@gmail.com> <045901d1af13$29d85d60$7d891820$@gmail.com> <045a01d1af14$8db12aa0$a9137fe0$@gmail.com> 
In-Reply-To: 
Date: Tue, 17 May 2016 09:32:22 -0400
Message-ID: <024b01d1b040$8b35a800$a1a0f800$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQG9AVJW+Y7xpWAUdsUf0IIYfjAqNAGVztXGAdsLs7cCOQ7GXgJE2Q36n6cGQjA=
Content-Language: en-us
Archived-At: 
Cc: spasm@ietf.org
Subject: Re: [Spasm] My take on handling EKU constraints
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 17 May 2016 13:32:29 -0000

Hi Russ,

I would add something to the effect "CAs asserting this extension SHOULD
consider including  OCSPSigning in permitted EKUs if the downstream CAs may
issue delegated OCSP Responder certificates"

-----Original Message-----
From: Russ Housley [mailto:housley@vigilsec.com] 
Sent: Monday, May 16, 2016 5:17 PM
To: Santosh Chokhani 
Cc: spasm@ietf.org
Subject: Re: [Spasm] My take on handling EKU constraints

Santosh:

> Some discussion of OCSPSigning EKU in permitted field to accommodate 
> Delegated OCSP trust model will be useful.  May be in Security 
> Considerations Section.

We could add a discussion about the consequences of a particular EKU in the
end-entity certificate, but I cannot see why that is needed here.  You seem
to be thinking about some specific concern, please say more.

Russ



From nobody Tue May 17 06:34:32 2016
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 5D29212D146 for ; Tue, 17 May 2016 06:34:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.689
X-Spam-Level: 
X-Spam-Status: No, score=-2.689 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, T_KAM_HTML_FONT_INVALID=0.01] 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 qyTC0iDaSZYq for ; Tue, 17 May 2016 06:34:29 -0700 (PDT)
Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::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 0319912D5C3 for ; Tue, 17 May 2016 06:34:29 -0700 (PDT)
Received: by mail-qg0-x230.google.com with SMTP id f74so7868483qge.2 for ; Tue, 17 May 2016 06:34:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=from:to:references:in-reply-to:subject:date:message-id:mime-version :thread-index:content-language; bh=P3YcTF9uD5YfifS0+l1EPK7lzhTQnUKS3G9nNem9EDc=; b=P00jcoI99KXR+0NCa93A8N3nBnmF8m0kQsK0HLpy1GxXPFQYzvZfkyUQUzMckL91eU +rsVoox955rz1XzbwWLQjSOCCwU5HRk5TduYOaervTpeNSMFFHffcF2h69d7ouid25pe HX+1IEMC3GYqGabRkEVGTcAqfGUyuXmMkSgaZNlJKQUGJiB+Lcgh+r0rLlqUydN2vrux xs7HLHOeOUzGeuiiHOeXQMNUSdf9THlOVEOmG1m9plFn3TFNMGAJyChu11WiCXrDHizL oOy3/3ATBq4k23ETzDmP26a8APuvaUZkq68vRzvk4szs0p9uWL3w4qfRhJwDO0U7KD+m i3Tg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:thread-index:content-language; bh=P3YcTF9uD5YfifS0+l1EPK7lzhTQnUKS3G9nNem9EDc=; b=ZqjsyArW7s9MXc0oXzLVwdFOX/xXQKmdByVzIkduhOtv8AKwpjECQNJjBqVGcNYErf b63JInLK2lC1woS0Gbi5Px0SlqxTbn1/d07Kf/t6ijqrc4ftNo5r5F9V+rWFSl4GOGbP ma5X1KwH7DsKlWAqm0ud911NsWJEZ6BLLLiLGIgjouN4kfo24sbzt/EhV9YsK8ZThnlJ 0oScabmpcssHVf0fTKXCXKsfH6YdTTHCq08zcITELeUVqFrIQlmewvpghFxgCggNPU5F wsnlaH8WDps9IWgEEMS7VWv/JlscVGCE1Kzk9QvvPx7BX9bueZnCLx3yV87HtyV4Wy9K q5hA==
X-Gm-Message-State: AOPr4FW7oyX+GFjdEa2vIWPikccF5Rps7ug7x66LsjjELJIrXY8/wwbzYih/8jkL3oWjDg==
X-Received: by 10.141.41.71 with SMTP id s68mr1485974qhe.102.1463492068156; Tue, 17 May 2016 06:34:28 -0700 (PDT)
Received: from SantoshBrain (pool-108-31-66-4.washdc.fios.verizon.net. [108.31.66.4]) by smtp.gmail.com with ESMTPSA id h75sm1259774qge.30.2016.05.17.06.34.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 May 2016 06:34:26 -0700 (PDT)
From: "Santosh Chokhani" 
To: "'Sean Leonard'" , 
References: <316ECF88-612A-4131-8A96-E5F76671929A@vigilsec.com> <1b87369d-9812-b5c0-9631-ba9e638fd6d4@seantek.com> <14315127-9A40-4F56-874E-3725D9EF08A6@vigilsec.com> <405ff968-9d4b-42a8-2234-1209820a02b9@seantek.com>
In-Reply-To: <405ff968-9d4b-42a8-2234-1209820a02b9@seantek.com>
Date: Tue, 17 May 2016 09:34:23 -0400
Message-ID: <025301d1b040$d35518a0$79ff49e0$@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0254_01D1B01F.4C452650"
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQG9AVJW+Y7xpWAUdsUf0IIYfjAqNAJIj4ReAPhuVbECBgKSvp+8RNQg
Content-Language: en-us
Archived-At: 
Subject: Re: [Spasm] My take on handling EKU constraints
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 17 May 2016 13:34:31 -0000

This is a multipart message in MIME format.

------=_NextPart_000_0254_01D1B01F.4C452650
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Sean,

 

I support your idea of making this a CHOICE.

 

Separately, upon further reflection and thought, having two state variables
in path processing logic may be simpler.  When I started working it in my
head, there are more edge cases if you tried only one variable leading to
more software complexity.

 

From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Sean Leonard
Sent: Monday, May 16, 2016 11:56 PM
To: spasm@ietf.org
Subject: Re: [Spasm] My take on handling EKU constraints

 

On 5/16/2016 2:22 PM, Russ Housley wrote:

 
On May 16, 2016, at 2:16 AM, Sean Leonard  
 wrote:
 

Hello:
 
In the ASN.1 module (to be written), it's important to specify whether this
extension uses IMPLICIT, EXPLICIT, or AUTOMATIC tagging. I am guessing folks
don't want to use AUTOMATIC tagging, even though it's recommended by the
latest ASN.1 standards because it's "easy". My personal preference is for
EXPLICIT tagging. However, the extended key usage extension is defined in
the IMPLICIT module in RFC 5280, so it's IMPLICIT...this means that if you
want symmetry with the EKU extension, you should say it's IMPLICIT.

 
I was assuming that IMPLICIT would be used.


Ok; IMPLICIT needs to be in the next draft then.



 
 

Is there a way, using the latest ASN.1 syntax, to specify
"either-or-or-both", i.e., the EKUConstraints SEQUENCE must have at least
one element, possibly two, but not zero?

 
The text already says that.


The text does, but not the ASN.1. I.e., an ASN.1 compiler can't enforce the
constraint as written in the text. I see that as a flaw.



 
 

As I understand it, "permitted" takes greater precedence over "excluded".
I.e., if the extension has both permitted AND excluded, then really, only
"permitted" is going to have meaningful effect.

 
No, the text says that if the key purpose is the the excluded set, then it
is excluded.


I see how what I wrote could be misinterpreted; sorry about that. Of course
if the key purpose is in the excluded set, then it is excluded. In that
sense, an excluded OID takes precedence over the same OID being in the
permitted set.

The point is that putting an OID on both lists is pointless and needlessly
complicated. If an OID is on the permitted list AND the excluded list, then,
why is it on either list at all?

Section 3.5 (h) (i) says:

        (1)  If permitted_key_purpose_ids state variable is not special
             value that represents the universal set, then confirm that
             all of the key purpose identifiers are present in the set.
             If any are missing, then returning a failure indication and
             an appropriate reason.



The permitted set of OIDs can, apparently, be: "infinity" (unbounded),
"nonzero" (finite: bounded to only those listed), or "none" (zero). The
moment ANY certificate in the path mentions a permitted set, you are forever
thrown out of "infinity". It is now finite. Possibly zero. So the effect of
having further excluded sets (after introducing the first permitted set), is
only to whittle away at the finite permitted set of OIDs. You may as well
either repeat the list of permitted EKUs, or whittle it down in the next
certificate in the chain. Mentioning excluded sets only makes sense at the
top of the chain, before the first "permitted set" is introduced.

Example: consider a single CA cert in the chain that mentions both permitted
and excluded:
{
permitted:
1.1.1.1
1.1.1.2

excluded:
1.1.1.2
1.1.1.3
1.1.1.4
}

If only 1.1.1.1 and 1.1.1.2 are permitted, then mentioning 1.1.1.3 and
1.1.1.4 as "excluded" serves no purpose. You may as well drop 1.1.1.3 and
1.1.1.4. Furthermore, since 1.1.1.2 is excluded, why bother mentioning it in
"permitted"? That likewise serves no purpose. You may as well have said:

{
permitted:
1.1.1.1
}

and have been done with it.

Mentioning the excluded set at all, only makes sense when there is no
defined permitted set (i.e., the permitted set is the "special value that
represents the universal set"). In that way, excluding those OIDs basically
means we have the universal set ("infinity") MINUS a few mentioned OIDs.

That is why I am (increasingly) harping on making this extension a CHOICE,
rather than a SEQUENCE that can permit both.

Sean


------=_NextPart_000_0254_01D1B01F.4C452650
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Sean,
 
I support your idea of making this a CHOICE.
 
Separately, upon further reflection and thought, having two state =
variables in path processing logic may be simpler.  When I started =
working it in my head, there are more edge cases if you tried only one =
variable leading to more software complexity.
 
From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Sean =
Leonard
Sent: Monday, May 16, 2016 11:56 PM
To: =
spasm@ietf.org
Subject: Re: [Spasm] My take on handling EKU =
constraints
 
On =
5/16/2016 2:22 PM, Russ Housley wrote:
 
On May 16, 2016, at 2:16 AM, Sean Leonard <dev+ietf@seantek.com> =
wrote:
 
Hello:
 
In the ASN.1 module (to be written), =
it's important to specify whether this extension uses IMPLICIT, =
EXPLICIT, or AUTOMATIC tagging. I am guessing folks don't want to use =
AUTOMATIC tagging, even though it's recommended by the latest ASN.1 =
standards because it's "easy". My personal preference is for =
EXPLICIT tagging. However, the extended key usage extension is defined =
in the IMPLICIT module in RFC 5280, so it's IMPLICIT...this means that =
if you want symmetry with the EKU extension, you should say it's =
IMPLICIT.
 
I=
 was assuming that IMPLICIT would be =
used.

Ok; IMPLICIT needs to be in the next =
draft then.

 
 
Is there a way, =
using the latest ASN.1 syntax, to specify "either-or-or-both", =
i.e., the EKUConstraints SEQUENCE must have at least one element, =
possibly two, but not =
zero?
 
The =
text already says that.

The text does, but =
not the ASN.1. I.e., an ASN.1 compiler can't enforce the constraint as =
written in the text. I see that as a =
flaw.

 
 
As I understand it, =
"permitted" takes greater precedence over =
"excluded". I.e., if the extension has both permitted AND =
excluded, then really, only "permitted" is going to have =
meaningful =
effect.
 
No,=
 the text says that if the key purpose is the the excluded set, then it =
is excluded.

I see how what I wrote could be =
misinterpreted; sorry about that. Of course if the key purpose is in the =
excluded set, then it is excluded. In that sense, an excluded OID takes =
precedence over the same OID being in the permitted set.

The =
point is that putting an OID on both lists is pointless and needlessly =
complicated. If an OID is on the permitted list AND the excluded list, =
then, why is it on either list at all?

Section 3.5 (h) (i) =
says:
      &n=
bsp; (1)  If permitted_key_purpose_ids state variable is not =
special
      &n=
bsp;      value that represents the universal =
set, then confirm that
      &n=
bsp;      all of the key purpose identifiers =
are present in the set.
      &n=
bsp;      If any are missing, then returning a =
failure indication and
      &n=
bsp;      an appropriate =
reason.


The permitted set of OIDs can, =
apparently, be: "infinity" (unbounded), "nonzero" =
(finite: bounded to only those listed), or "none" (zero). The =
moment ANY certificate in the path mentions a permitted set, you are =
forever thrown out of "infinity". It is now finite. Possibly =
zero. So the effect of having further excluded sets (after introducing =
the first permitted set), is only to whittle away at the finite =
permitted set of OIDs. You may as well either repeat the list of =
permitted EKUs, or whittle it down in the next certificate in the chain. =
Mentioning excluded sets only makes sense at the top of the chain, =
before the first "permitted set" is =
introduced.

Example: consider a single CA cert in the chain that =
mentions both permitted and =
excluded:
{
permitted:
1.1.1.1
1.1.1.2

excluded:
1.=
1.1.2
1.1.1.3
1.1.1.4
}

If only 1.1.1.1 and 1.1.1.2 are =
permitted, then mentioning 1.1.1.3 and 1.1.1.4 as "excluded" =
serves no purpose. You may as well drop 1.1.1.3 and 1.1.1.4. =
Furthermore, since 1.1.1.2 is excluded, why bother mentioning it in =
"permitted"? That likewise serves no purpose. You may as well =
have said:

{
permitted:
1.1.1.1
}

and have been =
done with it.

Mentioning the excluded set at all, only makes =
sense when there is no defined permitted set (i.e., the permitted set is =
the "special value that represents the universal set"). In =
that way, excluding those OIDs basically means we have the universal set =
("infinity") MINUS a few mentioned OIDs.

That is why I =
am (increasingly) harping on making this extension a CHOICE, rather than =
a SEQUENCE that can permit =
both.

Sean

------=_NextPart_000_0254_01D1B01F.4C452650--


From nobody Tue May 17 06:38:07 2016
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 BDCD412D5AE for ; Tue, 17 May 2016 06:38:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3bWiPoD5axMX for ; Tue, 17 May 2016 06:38:04 -0700 (PDT)
Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::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 78EC512D5C3 for ; Tue, 17 May 2016 06:38:04 -0700 (PDT)
Received: by mail-qg0-x230.google.com with SMTP id f92so7955156qgf.0 for ; Tue, 17 May 2016 06:38:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=wZI4o3WL8EHiu2lgbBZSE0VlGLljTz665L6cxLzHJxo=; b=KNiHRgPvCxoK5Bp3ofCYnkUD2DbD/SKdxRJtecNT4VitN80wjhCev7Q/3yOdgA4JE4 Jw855pCmwUMK8xnjVUQ6z6rfWPX0daFZsOlTQW629n9kS5aIgyVqoJYUITJOjkgwy5Jh RmgqZHXyRss+GmUfqTQwmpz/iNED5z/895+k8Uo9nNGP3XHp5NmiXqltuLHhujwE4DC6 sYJuPP8HRQpaWGa8pchwq7h2T+BEeUYSbgfSXXQOoVbsTdgEfr9Wd5cXvKkJUeOafkCT eeT3vKOSCKA3MIKxTt470m7ZH12u5AfvcfeUaGuOae2vUuWsXQopHkW9wDjxhbhezbPz hLOA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=wZI4o3WL8EHiu2lgbBZSE0VlGLljTz665L6cxLzHJxo=; b=QTonCznTpSQVphdKiTkjwNIidgZVWUEoY3WgU+vFKGHNE7uW17LtJ10qH+Hdueamr8 sEjqhDYr8j8qfgIT7Wml1E7OuzHakqLGKhCp1dl9OY4M45GPx/1HIMwFXHH+iyj3Idmb kAclWIXp5oZp5qMVLWULT0Xgxvvw/Zr5ITbrab6k0zfNgT/K3Oxe16YF6v9PCCV/mw4V jt8IQ9DNDmexKn6jALJC/3lH1RbcbZhbHDoZ5zPJ3Z56x8bwP36ULrvfCMaydAAvPo0w l8R7IEaXjXt1AG7JS4swnxbHHcCvZMAJx+EU4pdpkKrEZ7KHTSXjdKUBA0SVMjEzqIYG jKNw==
X-Gm-Message-State: AOPr4FW1JMyCd9JmCtTOltnBrnQ4BusW/BDQCdOH1RdE4Hdo7nBmPsjdGE0PKsuIyodmJw==
X-Received: by 10.140.100.178 with SMTP id s47mr1413997qge.76.1463492283550; Tue, 17 May 2016 06:38:03 -0700 (PDT)
Received: from SantoshBrain (pool-108-31-66-4.washdc.fios.verizon.net. [108.31.66.4]) by smtp.gmail.com with ESMTPSA id d31sm1253539qgd.44.2016.05.17.06.38.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 May 2016 06:38:02 -0700 (PDT)
From: "Santosh Chokhani" 
To: "'Sean Leonard'" , 
References: <316ECF88-612A-4131-8A96-E5F76671929A@vigilsec.com> <044a01d1af10$1548b8c0$3fda2a40$@gmail.com> <000f01d1af31$5a760f80$0f622e80$@augustcellars.com> <054b01d1af78$d79e09d0$86da1d70$@gmail.com> <5739D2D5.8020809@cs.tcd.ie> <4e32597d-e1a1-d5b3-ca37-453b9a7e1c25@seantek.com>
In-Reply-To: <4e32597d-e1a1-d5b3-ca37-453b9a7e1c25@seantek.com>
Date: Tue, 17 May 2016 09:37:58 -0400
Message-ID: <026501d1b041$53f5de40$fbe19ac0$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQG9AVJW+Y7xpWAUdsUf0IIYfjAqNAGVztXGAf86bnoCUnYraAGgcfkvAl4aYfifl005gA==
Content-Language: en-us
Archived-At: 
Subject: Re: [Spasm] Maybe just do permitted constraints only Re: My take on handling EKU constraints
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 17 May 2016 13:38:07 -0000

Sean,

I think I know how Microsoft handles EKU.  But, can you confirm if CAPI
rejects  an end certificate if it does not have all the EKUs from the funnel
up to that point.

My experience is NO, but I have not tested it.

Unless I read the I-D and proposed changes discussed on this thread, the
proposal seems to be that if the end certificate does not have all the
permitted and does not have any of the excluded, the certificate is
rejected.  That seems quite harsh and unnecessary.

-----Original Message-----
From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Sean Leonard
Sent: Tuesday, May 17, 2016 12:22 AM
To: spasm@ietf.org
Subject: [Spasm] Maybe just do permitted constraints only Re: My take on
handling EKU constraints

On 5/16/2016 7:01 AM, Stephen Farrell wrote:
> [...]
> I hope we all agree that this kind of thing ought be mostly driven by 
> what those implementing or deploying certificate validation and 
> applications want and are willing to do and what they think makes 
> sense in terms of APIs etc. For example, I wondered which 
> application(s) you are involved in developing you meant in the above.
>
> One thing I think we need to be quite careful about with all of this 
> planned work is to not repeat mistakes we (incl. me) made in the past 
> where we designed a bunch of PKI machinery that didn't get used, or 
> that made it harder to use PKI, or that made PKI less useful.
I really want to channel Stephen here on this point about avoiding making
algorithms too complicated, that people won't use.

Sure it is possible to write algorithms that do all this "intersectionality"
and "differential" stuff with permitted and excluded items. But maybe it
doesn't make real-world sense (as we have seen with lackluster support for
Name Constraints).

Taking a step back, I question the need for the excluded set. By default, a
trust anchor that is defined purely by a certificate (i.e., a self-signed,
self-issued one, one under the control of the trust anchor
party) will naturally "want" universal capabilities: it is more economically
valuable. Of course if I create a CA for my own purposes, I will imbue it
with universal trust. I wouldn't exclude myself from issuing certs for
specific applications.

The situation changes when the trust point delegates its authority to the
next guy down the line (aka, issues a certificate). I want to be sure that
the next guy doesn't abuse my universal authority, so I want to constrain
him/her/it. Therefore, I say: "you can do these enumerated things, but I'm
not giving you a blank check". Specifying an excluded set is tantamount to
writing an /almost/ blank check: "you can put any number in the amount
field, just as long as it's not one million, or four billion". Not a good
situation. Principle of least privilege, folks.

Now it is possible (in fact, quite likely) that a certificate-using
application will want to exclude purposes entirely from the path. Maybe the
user (or sysadmins) "trust" some CA for what it contractually claims to
limit itself to issue, but no matter what, the user is never going to
"trust" that CA for "Kernel Mode Signing". That exclusion is perfectly valid
(and perhaps can be specified in the path processing algorithm, especially
at the "top"), but is not part of the artifacts in the certification path
itself.

The way that I understand how the Microsoft EKU implementation works, is
that it's a funnel of permitted usages only. At the topmost level, the
user/application says exactly what EKUs it will allow the trust anchor to
promulgate: everything ("Enable all purposes for this certificate"), nothing
("Disable all purposes for this certificate"), or exactly a finite list of
specific things ("Enable only the following purposes: 
[OIDs]"). At each step in the certification path, the cert can contract the
set of usages, but cannot expand them. What is effective at the end-entity
certificate is just the intersection of all permitted usages. 
The dialog box says: "Note: you may only edit the certificate purposes that
are allowed by the certification path."

We can make things a lot simpler if we make this EKU Constraints extension
just be a list of permittedKeyPurposeIds, in which case, it would be
syntactically identical to ExtKeyUsageSyntax.

I would also posit that Name Constraints would be a lot easier to implement,
and a lot more useful, if they were defined as "permitted" 
only, for analogous reasons.

(I have no comment or insight on certificate policies, other than, a lot of
people find them awfully complicated.)

Sean

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


From nobody Tue May 17 06:48:43 2016
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 EA8E512D5F3 for ; Tue, 17 May 2016 06:48:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.727
X-Spam-Level: 
X-Spam-Status: No, score=-5.727 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=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 C-UdB04gihFq for ; Tue, 17 May 2016 06:48:25 -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 D638812D5F2 for ; Tue, 17 May 2016 06:48:12 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 75B6CBE2F for ; Tue, 17 May 2016 14:48:11 +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 lGR3VDm8bFdL for ; Tue, 17 May 2016 14:48:10 +0100 (IST)
Received: from [10.87.48.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 A93E8BE2D for ; Tue, 17 May 2016 14:48:09 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1463492890; bh=6O/XbK6OBkhTkXC4BdrmBMv7h3mqfN+7hHZ0c5ihxPw=; h=Subject:References:To:From:Date:In-Reply-To:From; b=IFJyqtQKNMREanVOBftWry7lm/3v4W//JBoxTrL8Yd4Zxk/VcQKgLMgw0mGNzNArX HpxP4fhuYofCqbzETx8ysGJunkDDJGJDLH9B+qYd2QEooIL25YwNkbbGnzAhW++vkE dcExAhFGWg+uU2l7yyjTolyqyWLWWh8tsbYTdgZw=
References: <316ECF88-612A-4131-8A96-E5F76671929A@vigilsec.com> <044a01d1af10$1548b8c0$3fda2a40$@gmail.com>  <023a01d1b03f$b444c8d0$1cce5a70$@gmail.com>
To: spasm@ietf.org
From: Stephen Farrell 
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <573B2119.3060800@cs.tcd.ie>
Date: Tue, 17 May 2016 14:48:09 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <023a01d1b03f$b444c8d0$1cce5a70$@gmail.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms090209050707050209010707"
Archived-At: 
Subject: [Spasm] more scoping is needed (was: Re: My take on handling EKU constraints)
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 17 May 2016 13:48:35 -0000

This is a cryptographically signed message in MIME format.

--------------ms090209050707050209010707
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


Question for the list:

On 17/05/16 14:26, Santosh Chokhani wrote:
>  But, this does not help the cross-certified environment.

Is that environment of interest? Should we de-scope it in the
proposed charter? Or if not, should it be limited to consideration
for only the smime email application?

=46rom what I've heard so far, the only folks who seem to be
planning implementations are interested in the WebPKI and
in enterprise smime. Is that correct?

If in fact we have implementers who are planning to write code
for something else, those implementers should say so before
we're done with the charter.

We may save ourselves some extended debates if we can craft
charter text to reflect the scope of the real work that folks
want to do.



In any case, this mail thread has convinced me that we
do need some more scoping text in the charter, perhaps to
name a primary use-case for each of the work items and to
say that wider (abstract, near theoretical) considerations
of (the consequences of) the same work items are to be
discouraged as we know from history that those discussions
move glacially, are terribly distracting and have lead to
worse outcomes in the past. Text suggestions welcome.

And to be clear, I will not be pushing the next button in
the formal chartering process until we've tackled this
issue, either adding text such as the above or convincing
me that it's not needed. (And I fully admit to possibly
having an overly-sensitive ocean-boiling-ahead detector
here;-)



Cheers,
S.


--------------ms090209050707050209010707
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
CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ
BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD
ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll
bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw
aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA
Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra
C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3
rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5
R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r
dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt
3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw
MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ
QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv
BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5
BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu
Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll
bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc
MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE
MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG
9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD
C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9
U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM
aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai
9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC
BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE
BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs
IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g
QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC
SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC
ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv
mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm
VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4
D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI
dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu
N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE
FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp
MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE
WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG
JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+
SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g
BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv
bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY
0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF
NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9
uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p
6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv
Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu
mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7
RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO
/ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN
JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM
MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG
A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0
Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA
oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA1MTcx
MzQ4MDlaMC8GCSqGSIb3DQEJBDEiBCBH609SDtFhtpYA1SpVepN8d3sNFe8FgBCOLiLQ9rnK
7TBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN
AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC
AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw
IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB
nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD
VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq
hkiG9w0BAQEFAASCAQBN8rE9Y93YRfoK1lAN56y6Qa1dq02jrPqaNajDv/Rak2iEMHld/9lj
Kn1f/IshqJ83BQgvAMIWBGWNsT+5/m9ee8C+5j0K3PFormA/OumGfMfmAMCOo/aNVecfBnC/
ei+BMscFCTReNgNWMPUfeoOzG01knBWWggHxfzEFRL6vOwuj0rzU8aEQ4iC43ODXJmldYJ7a
HYo6rXMIExGZZafBLIwUWEO5VRZcyeMXO5sEpzpWhi+ykNL50MuvCjivHM0Wf+JX8vqpPtqM
bczJJSPjxmE1oJN2vHPH7XLvncUtX68qL8TNOpsGVGoVg/tgfAtNZtTTdtSq119Z9fgmVgk0
AAAAAAAA
--------------ms090209050707050209010707--


From nobody Tue May 17 08:24:50 2016
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 E365712D9A0 for ; Tue, 17 May 2016 08:24:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.899
X-Spam-Level: 
X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GamkeFgo1ePI for ; Tue, 17 May 2016 08:24:48 -0700 (PDT)
Received: from mail.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id C1B1912D99F for ; Tue, 17 May 2016 08:24:48 -0700 (PDT)
Received: from localhost (ronin.smetech.net [209.135.209.5]) by mail.smetech.net (Postfix) with ESMTP id 72F9BF24062 for ; Tue, 17 May 2016 11:24:48 -0400 (EDT)
X-Virus-Scanned: amavisd-new at smetech.net
Received: from mail.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id 23MINQMcq4zA for ; Tue, 17 May 2016 11:07:37 -0400 (EDT)
Received: from [10.189.52.232] (unknown [192.54.222.12]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.smetech.net (Postfix) with ESMTP id 184BCF24013 for ; Tue, 17 May 2016 11:24:48 -0400 (EDT)
From: Russ Housley 
Content-Type: multipart/alternative; boundary="Apple-Mail=_A011178B-C54C-42CF-913A-66439A8E62A2"
Message-Id: <3AE31EE3-08D8-4F0C-A3F6-BC8E42E769E7@vigilsec.com>
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Date: Tue, 17 May 2016 11:24:25 -0400
References: <316ECF88-612A-4131-8A96-E5F76671929A@vigilsec.com> <1b87369d-9812-b5c0-9631-ba9e638fd6d4@seantek.com> <14315127-9A40-4F56-874E-3725D9EF08A6@vigilsec.com> <405ff968-9d4b-42a8-2234-1209820a02b9@seantek.com>
To: spasm@ietf.org
In-Reply-To: <405ff968-9d4b-42a8-2234-1209820a02b9@seantek.com>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: 
Subject: Re: [Spasm] My take on handling EKU constraints
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 17 May 2016 15:24:50 -0000

--Apple-Mail=_A011178B-C54C-42CF-913A-66439A8E62A2
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252


> That is why I am (increasingly) harping on making this extension a =
CHOICE, rather than a SEQUENCE that can permit both.

What do others think?

Russ


--Apple-Mail=_A011178B-C54C-42CF-913A-66439A8E62A2
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252



That is why I am =
(increasingly) harping on making this extension a CHOICE, rather than a =
SEQUENCE that can permit both.

What do =
others =
think?

Russ

=

--Apple-Mail=_A011178B-C54C-42CF-913A-66439A8E62A2--


From nobody Tue May 17 08:57:08 2016
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 5D80C12D197 for ; Tue, 17 May 2016 08:57:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.589
X-Spam-Level: 
X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_KAM_HTML_FONT_INVALID=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 MYCPapB3nTju for ; Tue, 17 May 2016 08:57:04 -0700 (PDT)
Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBE1212D18F for ; Tue, 17 May 2016 08:57:04 -0700 (PDT)
Received: from hebrews (c-24-21-96-37.hsd1.or.comcast.net [24.21.96.37]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 378D72CA10; Tue, 17 May 2016 08:57:04 -0700 (PDT)
From: "Jim Schaad" 
To: "'Sean Leonard'" , 
References: <316ECF88-612A-4131-8A96-E5F76671929A@vigilsec.com> <1b87369d-9812-b5c0-9631-ba9e638fd6d4@seantek.com> <14315127-9A40-4F56-874E-3725D9EF08A6@vigilsec.com> <405ff968-9d4b-42a8-2234-1209820a02b9@seantek.com>
In-Reply-To: <405ff968-9d4b-42a8-2234-1209820a02b9@seantek.com>
Date: Tue, 17 May 2016 08:57:03 -0700
Message-ID: <026001d1b054$c1a4a7b0$44edf710$@augustcellars.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0261_01D1B01A.154B9C10"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQG9AVJW+Y7xpWAUdsUf0IIYfjAqNAJIj4ReAPhuVbECBgKSvp+8bkBw
Content-Language: en-us
Archived-At: 
Subject: Re: [Spasm] My take on handling EKU constraints
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 17 May 2016 15:57:07 -0000

This is a multipart message in MIME format.

------=_NextPart_000_0261_01D1B01A.154B9C10
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

The ASN.1 you are looking for is

 

   NameConstraints ::= SEQUENCE {

        permittedSubtrees       [0] GeneralSubtrees OPTIONAL,

        excludedSubtrees        [1] GeneralSubtrees OPTIONAL

   }

   (WITH COMPONENTS { ..., permittedSubtrees PRESENT} |

    WITH COMPONENTS { ..., excludedSubtrees PRESENT }}

 

Which formally requires one of the elements to be present.

 

Jim

 

 

From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Sean Leonard
Sent: Monday, May 16, 2016 8:56 PM
To: spasm@ietf.org
Subject: Re: [Spasm] My take on handling EKU constraints

 

On 5/16/2016 2:22 PM, Russ Housley wrote:

 
On May 16, 2016, at 2:16 AM, Sean Leonard  
 wrote:
 

Hello:
 
In the ASN.1 module (to be written), it's important to specify whether this
extension uses IMPLICIT, EXPLICIT, or AUTOMATIC tagging. I am guessing folks
don't want to use AUTOMATIC tagging, even though it's recommended by the
latest ASN.1 standards because it's "easy". My personal preference is for
EXPLICIT tagging. However, the extended key usage extension is defined in
the IMPLICIT module in RFC 5280, so it's IMPLICIT...this means that if you
want symmetry with the EKU extension, you should say it's IMPLICIT.

 
I was assuming that IMPLICIT would be used.


Ok; IMPLICIT needs to be in the next draft then.




 
 

Is there a way, using the latest ASN.1 syntax, to specify
"either-or-or-both", i.e., the EKUConstraints SEQUENCE must have at least
one element, possibly two, but not zero?

 
The text already says that.


The text does, but not the ASN.1. I.e., an ASN.1 compiler can't enforce the
constraint as written in the text. I see that as a flaw.




 
 

As I understand it, "permitted" takes greater precedence over "excluded".
I.e., if the extension has both permitted AND excluded, then really, only
"permitted" is going to have meaningful effect.

 
No, the text says that if the key purpose is the the excluded set, then it
is excluded.


I see how what I wrote could be misinterpreted; sorry about that. Of course
if the key purpose is in the excluded set, then it is excluded. In that
sense, an excluded OID takes precedence over the same OID being in the
permitted set.

The point is that putting an OID on both lists is pointless and needlessly
complicated. If an OID is on the permitted list AND the excluded list, then,
why is it on either list at all?

Section 3.5 (h) (i) says:



        (1)  If permitted_key_purpose_ids state variable is not special
             value that represents the universal set, then confirm that
             all of the key purpose identifiers are present in the set.
             If any are missing, then returning a failure indication and
             an appropriate reason.



The permitted set of OIDs can, apparently, be: "infinity" (unbounded),
"nonzero" (finite: bounded to only those listed), or "none" (zero). The
moment ANY certificate in the path mentions a permitted set, you are forever
thrown out of "infinity". It is now finite. Possibly zero. So the effect of
having further excluded sets (after introducing the first permitted set), is
only to whittle away at the finite permitted set of OIDs. You may as well
either repeat the list of permitted EKUs, or whittle it down in the next
certificate in the chain. Mentioning excluded sets only makes sense at the
top of the chain, before the first "permitted set" is introduced.

Example: consider a single CA cert in the chain that mentions both permitted
and excluded:
{
permitted:
1.1.1.1
1.1.1.2

excluded:
1.1.1.2
1.1.1.3
1.1.1.4
}

If only 1.1.1.1 and 1.1.1.2 are permitted, then mentioning 1.1.1.3 and
1.1.1.4 as "excluded" serves no purpose. You may as well drop 1.1.1.3 and
1.1.1.4. Furthermore, since 1.1.1.2 is excluded, why bother mentioning it in
"permitted"? That likewise serves no purpose. You may as well have said:

{
permitted:
1.1.1.1
}

and have been done with it.

Mentioning the excluded set at all, only makes sense when there is no
defined permitted set (i.e., the permitted set is the "special value that
represents the universal set"). In that way, excluding those OIDs basically
means we have the universal set ("infinity") MINUS a few mentioned OIDs.

That is why I am (increasingly) harping on making this extension a CHOICE,
rather than a SEQUENCE that can permit both.

Sean


------=_NextPart_000_0261_01D1B01A.154B9C10
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


The ASN.1 you are looking for is
 
   NameConstraints ::=3D SEQUENCE =
{
        =
permittedSubtrees       [0] =
GeneralSubtrees OPTIONAL,
        =
excludedSubtrees        [1] =
GeneralSubtrees OPTIONAL
   }
   (WITH COMPONENTS { ..., permittedSubtrees PRESENT} =
|
    WITH COMPONENTS { ..., excludedSubtrees PRESENT =
}}
 
Which formally requires one of the elements to be =
present.
 
Jim
 
 
From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Sean =
Leonard
Sent: Monday, May 16, 2016 8:56 PM
To: =
spasm@ietf.org
Subject: Re: [Spasm] My take on handling EKU =
constraints
 
On 5/16/2016 2:22 PM, Russ =
Housley wrote:
 
On May 16, 2016, at 2:16 AM, Sean Leonard <dev+ietf@seantek.com> =
wrote:
 
Hello:
 
In the ASN.1 module (to be written), it's =
important to specify whether this extension uses IMPLICIT, EXPLICIT, or =
AUTOMATIC tagging. I am guessing folks don't want to use AUTOMATIC =
tagging, even though it's recommended by the latest ASN.1 standards =
because it's "easy". My personal preference is for EXPLICIT =
tagging. However, the extended key usage extension is defined in the =
IMPLICIT module in RFC 5280, so it's IMPLICIT...this means that if you =
want symmetry with the EKU extension, you should say it's =
IMPLICIT.
 
I was assuming that IMPLICIT would be =
used.

Ok; IMPLICIT needs to be in the next =
draft then.


 
 
Is there a way, using the latest ASN.1 =
syntax, to specify "either-or-or-both", i.e., the =
EKUConstraints SEQUENCE must have at least one element, possibly two, =
but not zero?
 
The text already says =
that.

The text does, but not the ASN.1. I.e., =
an ASN.1 compiler can't enforce the constraint as written in the text. I =
see that as a flaw.


 
 
As I understand it, "permitted" =
takes greater precedence over "excluded". I.e., if the =
extension has both permitted AND excluded, then really, only =
"permitted" is going to have meaningful =
effect.
 
No, the text says that if the key purpose is =
the the excluded set, then it is =
excluded.

I see how what I wrote could be =
misinterpreted; sorry about that. Of course if the key purpose is in the =
excluded set, then it is excluded. In that sense, an excluded OID takes =
precedence over the same OID being in the permitted set.

The =
point is that putting an OID on both lists is pointless and needlessly =
complicated. If an OID is on the permitted list AND the excluded list, =
then, why is it on either list at all?

Section 3.5 (h) (i) =
says:

   &nb=
sp;    (1)  If permitted_key_purpose_ids state =
variable is not special
   &nb=
sp;         value that =
represents the universal set, then confirm that
   &nb=
sp;         all of the key =
purpose identifiers are present in the set.
   &nb=
sp;         If any are missing, =
then returning a failure indication and
   &nb=
sp;         an appropriate =
reason.


The permitted set of OIDs can, apparently, be: =
"infinity" (unbounded), "nonzero" (finite: bounded =
to only those listed), or "none" (zero). The moment ANY =
certificate in the path mentions a permitted set, you are forever thrown =
out of "infinity". It is now finite. Possibly zero. So the =
effect of having further excluded sets (after introducing the first =
permitted set), is only to whittle away at the finite permitted set of =
OIDs. You may as well either repeat the list of permitted EKUs, or =
whittle it down in the next certificate in the chain. Mentioning =
excluded sets only makes sense at the top of the chain, before the first =
"permitted set" is introduced.

Example: consider a =
single CA cert in the chain that mentions both permitted and =
excluded:
{
permitted:
1.1.1.1
1.1.1.2

excluded:
1.=
1.1.2
1.1.1.3
1.1.1.4
}

If only 1.1.1.1 and 1.1.1.2 are =
permitted, then mentioning 1.1.1.3 and 1.1.1.4 as "excluded" =
serves no purpose. You may as well drop 1.1.1.3 and 1.1.1.4. =
Furthermore, since 1.1.1.2 is excluded, why bother mentioning it in =
"permitted"? That likewise serves no purpose. You may as well =
have said:

{
permitted:
1.1.1.1
}

and have been =
done with it.

Mentioning the excluded set at all, only makes =
sense when there is no defined permitted set (i.e., the permitted set is =
the "special value that represents the universal set"). In =
that way, excluding those OIDs basically means we have the universal set =
("infinity") MINUS a few mentioned OIDs.

That is why I =
am (increasingly) harping on making this extension a CHOICE, rather than =
a SEQUENCE that can permit =
both.

Sean

------=_NextPart_000_0261_01D1B01A.154B9C10--


From nobody Tue May 17 09:04:39 2016
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 EE0EC12DA54 for ; Tue, 17 May 2016 09:04:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Level: 
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MG7CcJG6XXy7 for ; Tue, 17 May 2016 09:04:36 -0700 (PDT)
Received: from mail.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 7DE5B12DA51 for ; Tue, 17 May 2016 09:04:36 -0700 (PDT)
Received: from localhost (ronin.smetech.net [209.135.209.5]) by mail.smetech.net (Postfix) with ESMTP id 4E4E8F24013; Tue, 17 May 2016 12:04:36 -0400 (EDT)
X-Virus-Scanned: amavisd-new at smetech.net
Received: from mail.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id BXhR6BSHtNot; Tue, 17 May 2016 11:47:24 -0400 (EDT)
Received: from [10.189.52.232] (unknown [192.54.222.12]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.smetech.net (Postfix) with ESMTP id DE34DF24061; Tue, 17 May 2016 12:04:33 -0400 (EDT)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Russ Housley 
In-Reply-To: <14315127-9A40-4F56-874E-3725D9EF08A6@vigilsec.com>
Date: Tue, 17 May 2016 12:02:45 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <4341C99A-8166-460D-9615-2D18949971A2@vigilsec.com>
References: <316ECF88-612A-4131-8A96-E5F76671929A@vigilsec.com> <1b87369d-9812-b5c0-9631-ba9e638fd6d4@seantek.com> <14315127-9A40-4F56-874E-3725D9EF08A6@vigilsec.com>
To: Sean Leonard 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: 
Cc: spasm@ietf.org
Subject: Re: [Spasm] My take on handling EKU constraints
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 17 May 2016 16:04:38 -0000

Sean:

>> In the ASN.1 module (to be written), it's important to specify =
whether this extension uses IMPLICIT, EXPLICIT, or AUTOMATIC tagging. I =
am guessing folks don't want to use AUTOMATIC tagging, even though it's =
recommended by the latest ASN.1 standards because it's "easy". My =
personal preference is for EXPLICIT tagging. However, the extended key =
usage extension is defined in the IMPLICIT module in RFC 5280, so it's =
IMPLICIT...this means that if you want symmetry with the EKU extension, =
you should say it's IMPLICIT.
>=20
> I was assuming that IMPLICIT would be used.
>=20
>> Is there a way, using the latest ASN.1 syntax, to specify =
"either-or-or-both", i.e., the EKUConstraints SEQUENCE must have at =
least one element, possibly two, but not zero?
>=20
> The text already says that.

I think that we can use some modern ASN.1 features to say that one, the =
other, or both must be present.

EKUConstraints ::=3D SEQUENCE {
  permittedKeyPurposeIds   [0] KeyPurposeIds OPTIONAL,
  excludedKeyPurposeIds    [1] KeyPurposeIds OPTIONAL }
  ( WITH COMPONENTS { ...,
      permittedKeyPurposeIds   PRESENT,
      excludedKeyPurposeIds    PRESENT } |
    WITH COMPONENTS { ...,
      permittedKeyPurposeIds   PRESENT,
      excludedKeyPurposeIds    ABSENT } |
    WITH COMPONENTS { ...,
      permittedKeyPurposeIds   ABSENT,
      excludedKeyPurposeIds    PRESENT } )

I have not double checked this with a compiler yet, but I=92, pretty =
sure that this provides the capability you were talking about.

Russ


From nobody Tue May 17 09:19:25 2016
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 AF9F512DA86 for ; Tue, 17 May 2016 09:19:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=roberthalf.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 IY_tw2CboIQg for ; Tue, 17 May 2016 09:19:21 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0637.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:637]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DB6412DA90 for ; Tue, 17 May 2016 09:19:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=roberthalf.onmicrosoft.com; s=selector1-protiviti-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=gXUQotWyonPNEsFWCRMrVj65ywAYM9eJwmE3A4TSxlk=; b=jIEf9K9xtVwFy5vV306F5JMKXlh/X8sFgPfdxT1gCQmax/H5bP0pmvYsS65/HvM6ReA/AnjbL1mkDe0EO5l+wfzihWd0JXgek6TCZXLhsyFelJNnrHMNh4KhizACfM6AQdFV6RDGaZbkYMY/KDhkAa3w7cVIbi4y4tyVu+VQJkY=
Received: from BY2PR03CA062.namprd03.prod.outlook.com (10.141.249.35) by SN2PR03MB013.namprd03.prod.outlook.com (10.255.175.35) with Microsoft SMTP Server (TLS) id 15.1.485.9; Tue, 17 May 2016 16:19:04 +0000
Received: from BN1BFFO11FD023.protection.gbl (2a01:111:f400:7c10::1:116) by BY2PR03CA062.outlook.office365.com (2a01:111:e400:2c5d::35) with Microsoft SMTP Server (TLS) id 15.1.497.12 via Frontend Transport; Tue, 17 May 2016 16:19:03 +0000
Authentication-Results: spf=pass (sender IP is 204.75.127.192) smtp.mailfrom=protiviti.com; cs.tcd.ie; dkim=none (message not signed) header.d=none;cs.tcd.ie; dmarc=bestguesspass action=none header.from=protiviti.com;
Received-SPF: Pass (protection.outlook.com: domain of protiviti.com designates 204.75.127.192 as permitted sender) receiver=protection.outlook.com;  client-ip=204.75.127.192; helo=N1-1EXC-CAS05.na.msds.rhi.com;
Received: from N1-1EXC-CAS05.na.msds.rhi.com (204.75.127.192) by BN1BFFO11FD023.mail.protection.outlook.com (10.58.144.86) with Microsoft SMTP Server id 15.1.492.8 via Frontend Transport; Tue, 17 May 2016 16:19:02 +0000
Received: from N1-1EXC-MBX02N2.na.msds.rhi.com ([fe80::a1dc:d8a5:84af:3220]) by N1-1EXC-CAS05.na.msds.rhi.com ([fe80::ddd7:fb67:d20d:ae5d%10]) with mapi id 14.03.0224.002; Tue, 17 May 2016 09:18:27 -0700
From: "Brown, Wendy (10421)" 
To: Stephen Farrell , "spasm@ietf.org" 
Thread-Topic: [Spasm] more scoping is needed (was: Re: My take on handling EKU constraints)
Thread-Index: AQHRsFTJg+ao/uXux0qokb1NzyhP/5+9TZSw
Date: Tue, 17 May 2016 16:18:26 +0000
Message-ID: 
References: <316ECF88-612A-4131-8A96-E5F76671929A@vigilsec.com> <044a01d1af10$1548b8c0$3fda2a40$@gmail.com>  <023a01d1b03f$b444c8d0$1cce5a70$@gmail.com> <573B2119.3060800@cs.tcd.ie>
In-Reply-To: <573B2119.3060800@cs.tcd.ie>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.249.18.106]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Proxied
X-EOPAttributedMessage: 0
X-Forefront-Antispam-Report: CIP:204.75.127.192; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10009020)(6009001)(2980300002)(438002)(13464003)(24454002)(199003)(377454003)(189002)(5003600100002)(8676002)(3846002)(102836003)(6116002)(19580405001)(19580395003)(93886004)(5890100001)(5250100002)(107886002)(189998001)(5001770100001)(2501003)(5004730100002)(106116001)(8936002)(92566002)(106466001)(50986999)(87936001)(50466002)(54356999)(2950100001)(9686002)(76176999)(1220700001)(2906002)(2900100001)(2920100001)(33656002)(104016004)(86362001)(23676002)(55846006)(47776003)(586003)(5008740100001); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR03MB013; H:N1-1EXC-CAS05.na.msds.rhi.com;  FPR:; SPF:Pass; MLV:sfv; A:1; MX:1; LANG:en; 
X-Microsoft-Exchange-Diagnostics: 1; BN1BFFO11FD023; 1:7ADOvZuhBBkMjqBY+okLrvx6sfXiOVOjUsToZhJtl+bRQU2J6x+2TVHuWwLuds4QA/u39ySl7krtoUYsnYTgLvShPmkTggt6HEQOjAJmxddmSQHE12m3EBVfgyWLrS5cp4sPr5uQ4t5KDadmyl4cdpK6GdiJILG7wqc3yBhAksOGdkB0Rv8xA4oCqh+KF8oKtVfdaJ3G0yGfZhrojhtrPlK5vui502bC+N6zz6DnySzypoeoSRFbpvIhl6W8yU/DPlNsIGkHXKGC5Hm9ZVOFObEz1ieVJs6+V5zPatubmD4EnByCQHwwSZzFCi44QX8AlkJXu3SGQ6NEPyGkmBRq7uwfmlHGwD/oSE/1+neFj5gI2ln0/OxW9CSBoMZa0GRS6CzG86IXh8+tX+A8pd9aNAw4lGlYsNAvZbN68O1NJmPujlTW8oj3BuS7d4nd8ySaj338gS2aP20v7jHn0yJa2IT0X/+TOPHFVTSXh/WWrpgpViYS6vmS8ULexxgZy8hL
X-MS-Office365-Filtering-Correlation-Id: f0505a17-0697-4c1e-7aad-08d37e6ef62f
X-Microsoft-Exchange-Diagnostics: 1; SN2PR03MB013; 2:kY271eY6B+QxoV51m0OaPFje4+Zh0TRQi1rl3Bnd7FI2H25gJ0mys7HnoUl3aBSADnC2bqOfN9tiz19bD5m460QID2FoI7lqJTBcBb432P85qwduMcqcKNZ7y3NoRsnTobMAULzZSufmZH7FORtqoj9+3U0lnrjvLSZmUsargmcFPqBXSnLI4xx2bVNitNB6; 3:vUJOUhMZCZ/+CIGgSjwQQ2/pJllPpwWdrNlBCkC+A/1cIAU5Dpk40XtgqbbJzjz17NCdmhEaSFOt+LqmdJqAGoDMeA3jfucQoNz2H61INNi00pQYeZQz9Vd2gf9b0cS64mmthWL47VnxPkp6Eg2k3QGWWpRsym4ICM4VMI/7d5WGuD1dFlG+X+KWC5koJCHRQj4UeFUnUk8V1SqczsLsPDV8L+kplxSqkbvms5U/hnL88vsuv2ow1A6yr675aY8VyPowVhZJyGD/oRmTmAfR9g==
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(8251501002); SRVR:SN2PR03MB013; 
X-Microsoft-Exchange-Diagnostics: 1; SN2PR03MB013; 25:hmr0/GNwAZIaNMUa+6xpxPppHpv+59vc+RUhyIuS+ivV3gk+ejIE6m35rnooz7Ru3dhIkSAUizJHF1LtgCq1LUajk/mQe9PeHWjjEqI1z7P+90OdpE8jGp1LO6cbzf5DRWFsmpr5odCRow6EnrPUlOQgj9oPDbt442KREpcJ0cbZkiuVLxoW+/bWkEpIPnU59UrvKHSAkPU3jx4UoHXDVQDTI7OZaKNFT6QIrtPMbT185eI0DqoQmF6kkkiiCUscMoWoh/FKgtV/stydQhygdRSTA1f381rEU/Vd4xKI1WIRWpgpsaOfZ4LABAiTXbm7idCJfwWHfmi47EPcEr0/uMjJkA3a3bptrc5Ucrf0cHWC8ISfINdJ9Xh4oRxDB/eXYbq2KxxkC2N7aPSlaiyxsopKk2DyMGEwk+XTS41Xl6xX/kzAGSs+9UYHLZtlyFBEPun22zIt4UyTCuG/Q3I7R8ZLPVUFT48zfivzTkRjYqhCgwaMTxlQlqScpMPQkkJApz5ARWnAZxA6T/XT1vzYhEp1aAYmb8dZbmbvSkaBh8f/Ih0T1yDpCi/BvPhWOkPXO+c2HfCPPHOMiEzHySJQ7dm2X8yXXzqWFmXdEMBrhGdVForrX/w/e1uk8EuFfpWH2fBRTxLPKYjYQdAKIRUFhQ6xAJ2eoObfbaTIR0JRg7Y8x9KuxbQYav30rSAtVJq6tSjWeph3uIHq8/9qelLpkHsztWaZjWIl/vKTRlAZ6RE=
X-Microsoft-Exchange-Diagnostics: 1; SN2PR03MB013; 20:A0kfrrlkp4/T5qUnehQ0KTyag428Ya8KfAib/ySC18ee5uyzRUdi7l4+N9ppgkYlE/g84d2+57oY80QXYndpHDQbKLuD7MfiKfDGdBvEcQiRWwbLTfSqUxxae91FeLyQHfMk+cMZVzGDXal6tzf87gM6HES8OMkO+28trrnoKc17qgw9ouxTLoNQEjgsukrbT/QVknIeaRMtJLiOjxM6pp35lT9DDgL8susoRFliSVsnxpEOLZj4yXIy07CFR8ExkybnYvs7xLJStTYR8xc8AYITDgGWR10qMoZ0Nj8sEtHFpjg1kVNdx419u0bGzne96psad4A9qJasTFaD3xITqty5qIO7/Yw+tnuspbu0Ro6flt361/fh5PHMDES3ke2PQA5rn3MKokcKP1kbOWdG6ahdUs0No3fN+D91k/CZCVL89YM0sUSyFh/ILLfj8QQ7VUbSf36+AqkQ2usS2ksJO6C9aUUt/6ddzTtR3WKhfVDjTUUxqYCRxrwrJLg6s7LV
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:;
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(13016025)(5005006)(8121501046)(13018025)(13023025)(13024025)(10201501046)(3002001)(6055026); SRVR:SN2PR03MB013; BCL:0; PCL:0; RULEID:; SRVR:SN2PR03MB013; 
X-Microsoft-Exchange-Diagnostics: 1; SN2PR03MB013; 4:lYvGeLv8AyFvmFbDU0nFQix9Ry6mGDPPPhzO4OWKbiAsosvU3vq0NVst4d37hOlCPTxX/lkmwFUn0ZOe71pPHMjX3ZIXgHxGZyPSifeFGBUz4yCxLSUHSoXw3f83GZHcWsg3dkydvhJAR+tiN8YogUqepC931sKDySpurTev58/GqqGl7bNbTvrA8U6HUxfRTRSwgjFskZ1OM6yb6k3kSGFQmiYdRtxUMtgyResA5HEHtShZi11A7hKxJcv0OZQ1mbZTcAj/hVmIWovFZ8zsKkfAg6gQkTEvJOg+vOC/jV36OSv1og1NjMgW44pEBjUEKNgskuAgWGQICX+9pz7G1LCZYxEBy3PRXUrsawydswQo/7YG3KZ/PzZy3XauRg967QbXpzGLKIg4mve2ggI1qcyVpYKumLrCqELenDqLy6mQ2OeIMbGfyqfCcs+6Qi2+NoYpZ1yv+CEUSPiPJjTllw==
X-Forefront-PRVS: 0945B0CC72
X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtTTjJQUjAzTUIwMTM7MjM6SGZzNVFUTnlMSGJ5OTFxVVJZZy9sOTl2bWY2?= =?utf-8?B?Q0tZRTZmS3BBVktCMkdQQTZBbzY1ME9QaXFwTTA1c2tvZmJVaG1hSWxkTFJj?= =?utf-8?B?aWszY0RuWXlBSlA1R1BiMGE1cUgvV3RKbzgzUTRpYXhNQSt3ZkcwQW1IRG85?= =?utf-8?B?VTltcFZ2cEZrN0JJM2ZnTnRoNXI0MTdTc29tdEFDZWFTbkFINmh4b3Ara2xH?= =?utf-8?B?Vi9iWmpuMy95MHVuTjdSM2NIRTVHbUdGNDg5VTVNbXBSV1QzU1lIUS9lU2RZ?= =?utf-8?B?d1lLenlGTm5HdmVDVTZ6aVBkUXpScEdwcjl1Nnl6MDlEK0wrbE53YnpMN2xn?= =?utf-8?B?Wk12aVlxKzdFdmw0QUJsdkFQanVtN09uUlNIVFk1SzAvZ0tzeDBieTlOdW5L?= =?utf-8?B?cWh0blpBWGo4b0E2UU1qeU5FaUhNVzRhd2ZNM2tSM0FmUmZITTFyZ25RRllh?= =?utf-8?B?MHJldEFNSjkyeGEwcDUyUzBBVWxMRG1EcE5mbzBSWnJVSnVWa2xwOXRVSjkw?= =?utf-8?B?Q25PMFpWVlFVYUFMOEgvcWpsOFdzZHFCWjQzK2YxMlNqbjhtTG5GOWlQQ1oy?= =?utf-8?B?dVFscGM0UG0rTUF6ZVlwQnlLaHlqcEVXZDNselhyMXdManVPTDd1Zzl3WDYz?= =?utf-8?B?cmh5QzlrRUE2Q0pvMFhWUSttQ1VMRDF3eDdPVXNDYXhLVE1BVTZydTJlcTcx?= =?utf-8?B?ZDZNTERrRTZ4Vmh5UXlDOXFFdUxzbTh3bWpaazZ2RWtqWWE0QlExbUVYRG5N?= =?utf-8?B?d0tPeVBzdkloaSsvVDNwT2llaFAxMzRKYXhFMU1RK1E4VzVuU2syYUdaY3R2?= =?utf-8?B?MzRRR1BlckN6cHlGOTc2bDhDMFZPU010T0VOY1RPc25UcjFNa2Z3cy9JQWwv?= =?utf-8?B?b2pHK2t2cytJcHJqY1RMM2VHaVBLbUQzaTFvUHpVS09iVGpmRTU2bFNZY1Qz?= =?utf-8?B?M0lMc2w3elQzeU5hSmFvZmRNM3RKaHhCSkwycVRtRVpmOUNONUJFaEpOZXJ6?= =?utf-8?B?ejNvK2RkTUkwbGNQakQ2Q0N0VUZmdTBmeWEvQ1M4MUFkQ0thS1dwZkphRk44?= =?utf-8?B?cWlaeU5LS1VBT1Vvc1pkZllTOVU4TEVwUklTT0lSYzAyTGFrUGYxVG8ycWpY?= =?utf-8?B?Q1FaK0xWbkhYM01sbDV2dEJScXBtRkVJb3hXQTRCbnA1WDk5MFhib012a1V5?= =?utf-8?B?SHB1NURoazZ0L01MY1ljajB0MUZxTExpUVRGbEFpYTlnbEdXbmlKTXBlSUow?= =?utf-8?B?TjAvam4rSVoxZ1dnVjJOcTl0U1NicWUvVkUxOWpYZ3VNKzNXK2VUdUx3RzlR?= =?utf-8?B?Z3pFU3VHb0t6L0luYzVoUTJuZTVDeFY1M09LNzZ1T2N0eDFMcXVET25JcXdl?= =?utf-8?B?b2VlbWVPOTd6WjZmd2xyN3RqNnZRZ1lJeEhWNkRaMWtMUTFKeTdyY1ZwL0VP?= =?utf-8?B?dGQwWkc3WVViT0RrNi9VcUVaR2Fubk1kcUpQRjFvVGg1WDJjZE9LT01MdzBB?= =?utf-8?B?QlRZVEdCZS9nc3VoV2dSVEhqUlpXRkZKUGlKcFR3bW5ySXZjRm1CcG5ady9D?= =?utf-8?B?akhod05Pbm5SbFNrRDBkVlBjbTYvaXF1ZTk0MFhBQ29oYlpuVnQ3QkNFSzJX?= =?utf-8?Q?V7kYWIuIJB5B3VcVm2z?=
X-Microsoft-Exchange-Diagnostics: 1; SN2PR03MB013; 5:ezJfrOrMpbPcWJhFolWaQ7lBeuOi8gzGbzgsAeWyzlXwolAZe1VbNiURbi0EWZxAfmn15emVNJiD+Tii4tbpqv81ZKEi9LVOCfYJdFiFX7EQ8B3J2enAmqcmujnZH92/nAiMY+VPMbjLONevZ9BFAA==; 24:1yaxqYHRJ8K6HVl18INh0K0HqcfrWMUvhzYA5xxJDFII8YY762ePh1VwCHOn3Gk2Zu7tVL/sSxcUAz973LFf6wvGr/C25uQlXIpFxrdhzYs=; 7:TqfQ+IFlj0qn06x9tbqr+aNxArOJmRE9in+FAAQSzQ+/Tpa/vgSE2WdgYeK6lx09WxiqrX/So1KF+jzpKXLB1L6WiYNld2i0Vf9CJuwa0NREJ/EZ7X8OgvU3ZFJuttb41kVS9JrsBp6m2mwVV8DUjCfRJvd/R2fojadz65LQF0OoqdsWmY2rpYBUySHbtbMx; 20:xYIh9vCVESFtr3XB/s3Ni2IYAnejK9K3v4nGMcGicQLP1z/ZLlymHmqJe1zu3trE1gxFtdqcYvRnDeHqavx2hk5W/CtnSsXXCAy7vgBGqHOHxtg9ZATqpjKvMqFi2YZ14mWYnXJLbu8p86frKuHIbwqqy/52KlZXNSxZhRhHI/Y=
SpamDiagnosticOutput: 1:23
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: protiviti.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 May 2016 16:19:02.7280 (UTC)
X-MS-Exchange-CrossTenant-Id: 16532572-d567-4d67-8727-f12f7bb6aed3
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=16532572-d567-4d67-8727-f12f7bb6aed3; Ip=[204.75.127.192];  Helo=[N1-1EXC-CAS05.na.msds.rhi.com]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR03MB013
Archived-At: 
Subject: Re: [Spasm] more scoping is needed (was: Re: My take on handling EKU constraints)
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 17 May 2016 16:19:24 -0000

UGxlYXNlIGRvIE5PVCBkZS1zY29wZSB0aGUgY3Jvc3MtY2VydGlmaWVkIGVudmlyb25tZW50Lg0K
UHJvcG9zZWQgY2hhbmdlcyBvZiB0aGlzIHR5cGUgbWF5IGhhdmUgYSBncmVhdCBpbXBhY3Qgb24g
dGhlIFVTIEZlZGVyYWwgUEtJIHdoaWNoIGlzIGEgbGFyZ2UgY3Jvc3MtY2VydGlmaWVkIGVudmly
b25tZW50Lg0KDQpUaGFua3MsDQpXZW5keSBCcm93bg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut
LS0tLQ0KRnJvbTogU3RlcGhlbiBGYXJyZWxsIFttYWlsdG86c3RlcGhlbi5mYXJyZWxsQGNzLnRj
ZC5pZV0NClNlbnQ6IFR1ZXNkYXksIE1heSAxNywgMjAxNiA5OjQ4IEFNDQpUbzogc3Bhc21AaWV0
Zi5vcmcNClN1YmplY3Q6IFtTcGFzbV0gbW9yZSBzY29waW5nIGlzIG5lZWRlZCAod2FzOiBSZTog
TXkgdGFrZSBvbiBoYW5kbGluZyBFS1UgY29uc3RyYWludHMpDQoNCg0KUXVlc3Rpb24gZm9yIHRo
ZSBsaXN0Og0KDQpPbiAxNy8wNS8xNiAxNDoyNiwgU2FudG9zaCBDaG9raGFuaSB3cm90ZToNCj4g
IEJ1dCwgdGhpcyBkb2VzIG5vdCBoZWxwIHRoZSBjcm9zcy1jZXJ0aWZpZWQgZW52aXJvbm1lbnQu
DQoNCklzIHRoYXQgZW52aXJvbm1lbnQgb2YgaW50ZXJlc3Q/IFNob3VsZCB3ZSBkZS1zY29wZSBp
dCBpbiB0aGUNCnByb3Bvc2VkIGNoYXJ0ZXI/IE9yIGlmIG5vdCwgc2hvdWxkIGl0IGJlIGxpbWl0
ZWQgdG8gY29uc2lkZXJhdGlvbg0KZm9yIG9ubHkgdGhlIHNtaW1lIGVtYWlsIGFwcGxpY2F0aW9u
Pw0KDQpGcm9tIHdoYXQgSSd2ZSBoZWFyZCBzbyBmYXIsIHRoZSBvbmx5IGZvbGtzIHdobyBzZWVt
IHRvIGJlDQpwbGFubmluZyBpbXBsZW1lbnRhdGlvbnMgYXJlIGludGVyZXN0ZWQgaW4gdGhlIFdl
YlBLSSBhbmQNCmluIGVudGVycHJpc2Ugc21pbWUuIElzIHRoYXQgY29ycmVjdD8NCg0KSWYgaW4g
ZmFjdCB3ZSBoYXZlIGltcGxlbWVudGVycyB3aG8gYXJlIHBsYW5uaW5nIHRvIHdyaXRlIGNvZGUN
CmZvciBzb21ldGhpbmcgZWxzZSwgdGhvc2UgaW1wbGVtZW50ZXJzIHNob3VsZCBzYXkgc28gYmVm
b3JlDQp3ZSdyZSBkb25lIHdpdGggdGhlIGNoYXJ0ZXIuDQoNCldlIG1heSBzYXZlIG91cnNlbHZl
cyBzb21lIGV4dGVuZGVkIGRlYmF0ZXMgaWYgd2UgY2FuIGNyYWZ0DQpjaGFydGVyIHRleHQgdG8g
cmVmbGVjdCB0aGUgc2NvcGUgb2YgdGhlIHJlYWwgd29yayB0aGF0IGZvbGtzDQp3YW50IHRvIGRv
Lg0KDQo8U3BvbnNvcmluZ0FESGF0T24+DQoNCkluIGFueSBjYXNlLCB0aGlzIG1haWwgdGhyZWFk
IGhhcyBjb252aW5jZWQgbWUgdGhhdCB3ZQ0KZG8gbmVlZCBzb21lIG1vcmUgc2NvcGluZyB0ZXh0
IGluIHRoZSBjaGFydGVyLCBwZXJoYXBzIHRvDQpuYW1lIGEgcHJpbWFyeSB1c2UtY2FzZSBmb3Ig
ZWFjaCBvZiB0aGUgd29yayBpdGVtcyBhbmQgdG8NCnNheSB0aGF0IHdpZGVyIChhYnN0cmFjdCwg
bmVhciB0aGVvcmV0aWNhbCkgY29uc2lkZXJhdGlvbnMNCm9mICh0aGUgY29uc2VxdWVuY2VzIG9m
KSB0aGUgc2FtZSB3b3JrIGl0ZW1zIGFyZSB0byBiZQ0KZGlzY291cmFnZWQgYXMgd2Uga25vdyBm
cm9tIGhpc3RvcnkgdGhhdCB0aG9zZSBkaXNjdXNzaW9ucw0KbW92ZSBnbGFjaWFsbHksIGFyZSB0
ZXJyaWJseSBkaXN0cmFjdGluZyBhbmQgaGF2ZSBsZWFkIHRvDQp3b3JzZSBvdXRjb21lcyBpbiB0
aGUgcGFzdC4gVGV4dCBzdWdnZXN0aW9ucyB3ZWxjb21lLg0KDQpBbmQgdG8gYmUgY2xlYXIsIEkg
d2lsbCBub3QgYmUgcHVzaGluZyB0aGUgbmV4dCBidXR0b24gaW4NCnRoZSBmb3JtYWwgY2hhcnRl
cmluZyBwcm9jZXNzIHVudGlsIHdlJ3ZlIHRhY2tsZWQgdGhpcw0KaXNzdWUsIGVpdGhlciBhZGRp
bmcgdGV4dCBzdWNoIGFzIHRoZSBhYm92ZSBvciBjb252aW5jaW5nDQptZSB0aGF0IGl0J3Mgbm90
IG5lZWRlZC4gKEFuZCBJIGZ1bGx5IGFkbWl0IHRvIHBvc3NpYmx5DQpoYXZpbmcgYW4gb3Zlcmx5
LXNlbnNpdGl2ZSBvY2Vhbi1ib2lsaW5nLWFoZWFkIGRldGVjdG9yDQpoZXJlOy0pDQoNCjwvU3Bv
bnNvcmluZ0FESGF0T24+DQoNCkNoZWVycywNClMuDQoNCk5PVElDRTogUHJvdGl2aXRpIGlzIGEg
Z2xvYmFsIGNvbnN1bHRpbmcgYW5kIGludGVybmFsIGF1ZGl0IGZpcm0gY29tcG9zZWQgb2YgZXhw
ZXJ0cyBzcGVjaWFsaXppbmcgaW4gcmlzayBhbmQgYWR2aXNvcnkgc2VydmljZXMuIFByb3Rpdml0
aSBpcyBub3QgbGljZW5zZWQgb3IgcmVnaXN0ZXJlZCBhcyBhIHB1YmxpYyBhY2NvdW50aW5nIGZp
cm0gYW5kIGRvZXMgbm90IGlzc3VlIG9waW5pb25zIG9uIGZpbmFuY2lhbCBzdGF0ZW1lbnRzIG9y
IG9mZmVyIGF0dGVzdGF0aW9uIHNlcnZpY2VzLiBUaGlzIGVsZWN0cm9uaWMgbWFpbCBtZXNzYWdl
IGlzIGludGVuZGVkIGV4Y2x1c2l2ZWx5IGZvciB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8g
d2hpY2ggaXQgaXMgYWRkcmVzc2VkLiBUaGlzIG1lc3NhZ2UsIHRvZ2V0aGVyIHdpdGggYW55IGF0
dGFjaG1lbnQsIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBhbmQgcHJpdmlsZWdlZCBpbmZvcm1h
dGlvbi4gQW55IHZpZXdzLCBvcGluaW9ucyBvciBjb25jbHVzaW9ucyBleHByZXNzZWQgaW4gdGhp
cyBtZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUgaW5kaXZpZHVhbCBzZW5kZXIgYW5kIGRvIG5vdCBu
ZWNlc3NhcmlseSByZWZsZWN0IHRoZSB2aWV3cyBvZiBQcm90aXZpdGkgSW5jLiBvciBpdHMgYWZm
aWxpYXRlcy4gQW55IHVuYXV0aG9yaXplZCByZXZpZXcsIHVzZSwgcHJpbnRpbmcsIGNvcHlpbmcs
IHJldGVudGlvbiwgZGlzY2xvc3VyZSBvciBkaXN0cmlidXRpb24gaXMgc3RyaWN0bHkgcHJvaGli
aXRlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBtZXNzYWdlIGluIGVycm9yLCBwbGVhc2Ug
aW1tZWRpYXRlbHkgYWR2aXNlIHRoZSBzZW5kZXIgYnkgcmVwbHkgZW1haWwgbWVzc2FnZSB0byB0
aGUgc2VuZGVyIGFuZCBkZWxldGUgYWxsIGNvcGllcyBvZiB0aGlzIG1lc3NhZ2UuIFRoYW5rIHlv
dS4NCg==


From nobody Tue May 17 09:28:20 2016
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 C3B6312D704 for ; Tue, 17 May 2016 09:28:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.727
X-Spam-Level: 
X-Spam-Status: No, score=-5.727 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=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 3M-A407ZkvvL for ; Tue, 17 May 2016 09:28:17 -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 1C29612DAB7 for ; Tue, 17 May 2016 09:28:17 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 03337BDF9; Tue, 17 May 2016 17:28:16 +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 fuVl3k4Bnzgo; Tue, 17 May 2016 17:28:14 +0100 (IST)
Received: from [10.87.48.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 E18EFBE2C; Tue, 17 May 2016 17:28:13 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1463502494; bh=xSL4/zc0xRSyD4O1vx56/2ofheyDrecQHUPerRgogbE=; h=Subject:To:References:From:Date:In-Reply-To:From; b=m4FTKk9rt+XkdLM3Ailyl/7FyDEMR4ztvcZ+d17DF+EZR/sQ4UCFNz445SkFdHyx7 +ehcGrltbzj3fd1BSnPxWkMNCJ9PJJSDUTL1USAU30DHWGdjM7A+I2MDd+Nymr/zud I4VnNrwjhKWxxkgKPTfTh9q71jDIKzyGVO0BMXwI=
To: "Brown, Wendy (10421)" , "spasm@ietf.org" 
References: <316ECF88-612A-4131-8A96-E5F76671929A@vigilsec.com> <044a01d1af10$1548b8c0$3fda2a40$@gmail.com>  <023a01d1b03f$b444c8d0$1cce5a70$@gmail.com> <573B2119.3060800@cs.tcd.ie> 
From: Stephen Farrell 
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <573B469D.7020603@cs.tcd.ie>
Date: Tue, 17 May 2016 17:28:13 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms050406060107000903010806"
Archived-At: 
Subject: Re: [Spasm] more scoping is needed
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 17 May 2016 16:28:19 -0000

This is a cryptographically signed message in MIME format.

--------------ms050406060107000903010806
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


Hiya,

On 17/05/16 17:18, Brown, Wendy (10421) wrote:
> Please do NOT de-scope the cross-certified environment. Proposed
> changes of this type may have a great impact on the US Federal PKI
> which is a large cross-certified environment.

So I get that concern. Mine however is that we have a
history of the complexity inherent in that particular
PKI causing unnecessary complexity elsewhere, e.g. for
the WebPKI, where things like policy mappings are of
no use whatsoever.

To be entirely clear: I have no interest in sponsoring
anything where there's a reasonable chance of it turning
into another 19 year long odyssey involving many debates
about PKI-angels on the heads of PKI-pins.

Having to consider all the complexity of the US Federal
PKI when any other change is suggested sounds to me to
be perilously close to the above, so I would welcome
folks' suggested charter text on how we can handle that
conundrum.

S.

>=20
> Thanks, Wendy Brown
>=20
> -----Original Message----- From: Stephen Farrell
> [mailto:stephen.farrell@cs.tcd.ie] Sent: Tuesday, May 17, 2016 9:48
> AM To: spasm@ietf.org Subject: [Spasm] more scoping is needed (was:
> Re: My take on handling EKU constraints)
>=20
>=20
> Question for the list:
>=20
> On 17/05/16 14:26, Santosh Chokhani wrote:
>> But, this does not help the cross-certified environment.
>=20
> Is that environment of interest? Should we de-scope it in the=20
> proposed charter? Or if not, should it be limited to consideration=20
> for only the smime email application?
>=20
>> From what I've heard so far, the only folks who seem to be
> planning implementations are interested in the WebPKI and in
> enterprise smime. Is that correct?
>=20
> If in fact we have implementers who are planning to write code for
> something else, those implementers should say so before we're done
> with the charter.
>=20
> We may save ourselves some extended debates if we can craft charter
> text to reflect the scope of the real work that folks want to do.
>=20
> 
>=20
> In any case, this mail thread has convinced me that we do need some
> more scoping text in the charter, perhaps to name a primary use-case
> for each of the work items and to say that wider (abstract, near
> theoretical) considerations of (the consequences of) the same work
> items are to be discouraged as we know from history that those
> discussions move glacially, are terribly distracting and have lead
> to worse outcomes in the past. Text suggestions welcome.
>=20
> And to be clear, I will not be pushing the next button in the formal
> chartering process until we've tackled this issue, either adding text
> such as the above or convincing me that it's not needed. (And I fully
> admit to possibly having an overly-sensitive ocean-boiling-ahead
> detector here;-)
>=20
> 
>=20
> Cheers, S.
>=20
> NOTICE: Protiviti is a global consulting and internal audit firm
> composed of experts specializing in risk and advisory services.
> Protiviti is not licensed or registered as a public accounting firm
> and does not issue opinions on financial statements or offer
> attestation services. This electronic mail message is intended
> exclusively for the individual or entity to which it is addressed.
> This message, together with any attachment, may contain confidential
> and privileged information. Any views, opinions or conclusions
> expressed in this message are those of the individual sender and do
> not necessarily reflect the views of Protiviti Inc. or its
> affiliates. Any unauthorized review, use, printing, copying,
> retention, disclosure or distribution is strictly prohibited. If you
> have received this message in error, please immediately advise the
> sender by reply email message to the sender and delete all copies of
> this message. Thank you.=20
> _______________________________________________ Spasm mailing list=20
> Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm
>=20


--------------ms050406060107000903010806
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
CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ
BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD
ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll
bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw
aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA
Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra
C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3
rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5
R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r
dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt
3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw
MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ
QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv
BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5
BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu
Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll
bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc
MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE
MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG
9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD
C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9
U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM
aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai
9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC
BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE
BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs
IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g
QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC
SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC
ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv
mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm
VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4
D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI
dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu
N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE
FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp
MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE
WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG
JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+
SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g
BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv
bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY
0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF
NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9
uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p
6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv
Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu
mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7
RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO
/ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN
JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM
MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG
A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0
Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA
oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA1MTcx
NjI4MTNaMC8GCSqGSIb3DQEJBDEiBCAD/sNQ8Vydeb473Wk6KoPa6CZdyrw1vdRltbaguKj9
ZTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN
AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC
AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw
IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB
nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD
VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq
hkiG9w0BAQEFAASCAQBsfPEYeA3FIu0OruNW2HNf5yPSKLMGRnC3OwLPH150kDssRTpU2Cv+
SkmrIyxC6QDSuDGhSZIApGQj5qDlXDK4edPzUYaiO4elufV1DliUjFLbloGa/KJxvA+eEkln
TDRGWsKsTklGN5oyw6I7DhidRriKbzfyIF7TAIDuCyy/V4XCTbyLtaoO1djjFP7C3VqJthbX
Gh2YOSIfph5thS0qVLr0jzD2UUNp3evec2NqasyroizfA2REY8qgGL6/Qmw0lH2n+EWtW/0g
9ZNcf7JSDCqVZn1ebhAoY3Ap7PftpH+2bvdM90MhEtdlzpxGfcplpwAGb+PYD+9ZGR4L7LBW
AAAAAAAA
--------------ms050406060107000903010806--


From nobody Tue May 17 09:31:09 2016
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 DDA1412DAEE for ; Tue, 17 May 2016 09:31:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.127
X-Spam-Level: 
X-Spam-Status: No, score=-4.127 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ow3Zrj6hshc2 for ; Tue, 17 May 2016 09:31:05 -0700 (PDT)
Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 3499412DACC for ; Tue, 17 May 2016 09:31:04 -0700 (PDT)
Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 4E39143347D; Tue, 17 May 2016 16:31:03 +0000 (GMT)
Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 29158433451; Tue, 17 May 2016 16:31:03 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1463502663; bh=RfX1nIxLUTUN8xCs3iX/M5we1j1gp/De5Hrc4CCzFks=; l=514; h=From:To:Date:References:In-Reply-To:From; b=UVlkZzS9OzAfVolwN6XyNb7TV1oIDTKBWHOFVQGYrlnx0RRacTV+OgxIL+KLfqAj9 y2mcBfI2Jwg7CwFjlYlSJXgNgWWuq/h8eBFAse/sL3jhZb23kY9bhwY7UblVUGnr8h Yaj+n0aAcs0CRvbutvy22qaLxws0ndGGqcYm86E0=
Received: from email.msg.corp.akamai.com (usma1ex-cas1.msg.corp.akamai.com [172.27.123.30]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 08E451FC8C; Tue, 17 May 2016 16:31:03 +0000 (GMT)
Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Tue, 17 May 2016 12:31:02 -0400
Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1130.005; Tue, 17 May 2016 12:31:02 -0400
From: "Salz, Rich" 
To: Stephen Farrell , "Brown, Wendy (10421)" , "spasm@ietf.org" 
Thread-Topic: [Spasm] more scoping is needed
Thread-Index: AQHRsFlFGK3wsolvtE2wB8LpN2KI0Z+9Uhgw
Date: Tue, 17 May 2016 16:31:01 +0000
Message-ID: <6eeeb40b90bf4b51868fc4edeef81bfa@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <316ECF88-612A-4131-8A96-E5F76671929A@vigilsec.com> <044a01d1af10$1548b8c0$3fda2a40$@gmail.com>  <023a01d1b03f$b444c8d0$1cce5a70$@gmail.com> <573B2119.3060800@cs.tcd.ie>  <573B469D.7020603@cs.tcd.ie>
In-Reply-To: <573B469D.7020603@cs.tcd.ie>
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.38.124]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [Spasm] more scoping is needed
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 17 May 2016 16:31:08 -0000

DQo+IEhhdmluZyB0byBjb25zaWRlciBhbGwgdGhlIGNvbXBsZXhpdHkgb2YgdGhlIFVTIEZlZGVy
YWwgUEtJIHdoZW4gYW55IG90aGVyDQo+IGNoYW5nZSBpcyBzdWdnZXN0ZWQgc291bmRzIHRvIG1l
IHRvIGJlIHBlcmlsb3VzbHkgY2xvc2UgdG8gdGhlIGFib3ZlLCBzbyBJDQo+IHdvdWxkIHdlbGNv
bWUgZm9sa3MnIHN1Z2dlc3RlZCBjaGFydGVyIHRleHQgb24gaG93IHdlIGNhbiBoYW5kbGUgdGhh
dA0KPiBjb251bmRydW0uDQoNCkkgdGhpbmsgdGhlIEZlZFBLSSBjYW4gZmluZCBhIFdHIHdpdGhp
biB0aGVpciBvcmcgdG8gcHJvZmlsZSB0aGUgSUVURiBzdHVmZi4NCg0KRmVkZXJhdGVkIFBLSSdz
IHNob3VsZCBiZSBvdXQgb2Ygc2NvcGUgaGVyZS4NCg==


From nobody Tue May 17 10:07:47 2016
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 1AD1A12DBD7 for ; Tue, 17 May 2016 10:07:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G5wuhV0G4VRC for ; Tue, 17 May 2016 10:07:44 -0700 (PDT)
Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4607B12DBD6 for ; Tue, 17 May 2016 10:07:44 -0700 (PDT)
Received: from hebrews (c-24-21-96-37.hsd1.or.comcast.net [24.21.96.37]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id A455238F66; Tue, 17 May 2016 10:07:43 -0700 (PDT)
From: "Jim Schaad" 
To: "'Stephen Farrell'" , 
References: <316ECF88-612A-4131-8A96-E5F76671929A@vigilsec.com> <044a01d1af10$1548b8c0$3fda2a40$@gmail.com>  <023a01d1b03f$b444c8d0$1cce5a70$@gmail.com> <573B2119.3060800@cs.tcd.ie>  <573B469D.7020603@cs.tcd.ie>
In-Reply-To: <573B469D.7020603@cs.tcd.ie>
Date: Tue, 17 May 2016 10:07:43 -0700
Message-ID: <029301d1b05e$a0992320$e1cb6960$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQG9AVJW+Y7xpWAUdsUf0IIYfjAqNAGVztXGAdP+cJIB7kRbugGQAKc8ANsY8pcCStRoy5+WShMg
Content-Language: en-us
Archived-At: 
Subject: Re: [Spasm] more scoping is needed
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 17 May 2016 17:07:46 -0000

I can see two different types of statements coming from this:

1.  We are not going to pick up any work which is not specific to =
environments other than WebPKI and S/MIME.  (For some value of WebPKI), =
and

2. We are going to ignore any implications of our work which are not in =
those two environments.

I am assuming you mean the first statement not the second in terms of =
doing scoping.

Jim


-----Original Message-----
From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Stephen Farrell
Sent: Tuesday, May 17, 2016 9:28 AM
To: Brown, Wendy (10421) ; spasm@ietf.org
Subject: Re: [Spasm] more scoping is needed


Hiya,

On 17/05/16 17:18, Brown, Wendy (10421) wrote:
> Please do NOT de-scope the cross-certified environment. Proposed=20
> changes of this type may have a great impact on the US Federal PKI=20
> which is a large cross-certified environment.

So I get that concern. Mine however is that we have a history of the =
complexity inherent in that particular PKI causing unnecessary =
complexity elsewhere, e.g. for the WebPKI, where things like policy =
mappings are of no use whatsoever.

To be entirely clear: I have no interest in sponsoring anything where =
there's a reasonable chance of it turning into another 19 year long =
odyssey involving many debates about PKI-angels on the heads of =
PKI-pins.

Having to consider all the complexity of the US Federal PKI when any =
other change is suggested sounds to me to be perilously close to the =
above, so I would welcome folks' suggested charter text on how we can =
handle that conundrum.

S.

>=20
> Thanks, Wendy Brown
>=20
> -----Original Message----- From: Stephen Farrell=20
> [mailto:stephen.farrell@cs.tcd.ie] Sent: Tuesday, May 17, 2016 9:48 AM =

> To: spasm@ietf.org Subject: [Spasm] more scoping is needed (was:
> Re: My take on handling EKU constraints)
>=20
>=20
> Question for the list:
>=20
> On 17/05/16 14:26, Santosh Chokhani wrote:
>> But, this does not help the cross-certified environment.
>=20
> Is that environment of interest? Should we de-scope it in the proposed =

> charter? Or if not, should it be limited to consideration for only the =

> smime email application?
>=20
>> From what I've heard so far, the only folks who seem to be
> planning implementations are interested in the WebPKI and in=20
> enterprise smime. Is that correct?
>=20
> If in fact we have implementers who are planning to write code for=20
> something else, those implementers should say so before we're done=20
> with the charter.
>=20
> We may save ourselves some extended debates if we can craft charter=20
> text to reflect the scope of the real work that folks want to do.
>=20
> 
>=20
> In any case, this mail thread has convinced me that we do need some=20
> more scoping text in the charter, perhaps to name a primary use-case=20
> for each of the work items and to say that wider (abstract, near
> theoretical) considerations of (the consequences of) the same work=20
> items are to be discouraged as we know from history that those=20
> discussions move glacially, are terribly distracting and have lead to=20
> worse outcomes in the past. Text suggestions welcome.
>=20
> And to be clear, I will not be pushing the next button in the formal=20
> chartering process until we've tackled this issue, either adding text=20
> such as the above or convincing me that it's not needed. (And I fully=20
> admit to possibly having an overly-sensitive ocean-boiling-ahead=20
> detector here;-)
>=20
> 
>=20
> Cheers, S.
>=20
> NOTICE: Protiviti is a global consulting and internal audit firm=20
> composed of experts specializing in risk and advisory services.
> Protiviti is not licensed or registered as a public accounting firm=20
> and does not issue opinions on financial statements or offer=20
> attestation services. This electronic mail message is intended=20
> exclusively for the individual or entity to which it is addressed.
> This message, together with any attachment, may contain confidential=20
> and privileged information. Any views, opinions or conclusions=20
> expressed in this message are those of the individual sender and do=20
> not necessarily reflect the views of Protiviti Inc. or its affiliates. =

> Any unauthorized review, use, printing, copying, retention, disclosure =

> or distribution is strictly prohibited. If you have received this=20
> message in error, please immediately advise the sender by reply email=20
> message to the sender and delete all copies of this message. Thank=20
> you.
> _______________________________________________ Spasm mailing list=20
> Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm
>=20



From nobody Tue May 17 11:44:47 2016
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 02BAA12D8E7 for ; Tue, 17 May 2016 11:44:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.727
X-Spam-Level: 
X-Spam-Status: No, score=-5.727 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=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 WqJRQWDl4w11 for ; Tue, 17 May 2016 11:44:44 -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 B1DDE12DD0F for ; Tue, 17 May 2016 11:44:43 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 8B117BE2C; Tue, 17 May 2016 19:44:42 +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 QHoJj7Ac0d_c; Tue, 17 May 2016 19:44:39 +0100 (IST)
Received: from [10.87.48.75] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 85D78BDF9; Tue, 17 May 2016 19:44:38 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1463510679; bh=GG+polz2vp/aXsOMot/a9JjFjcBrvl2f0+3auTEmIu4=; h=Subject:To:References:From:Date:In-Reply-To:From; b=Yjet3vcxsQSwkVd8qpc17C25XPTGq75zz0KX4GVfFCEHsXGWJkcoLA+s1pzRoqMhg qUOD03dJuLJcGUHIoA8VqBZ+IKdSST2+a7mPmnMOITe49kUje122k1Qmu4aez3DCLx eNh20c/bKEyHuwySv69hFb1hq4UZCIQEAaU9FW9Q=
To: Jim Schaad , spasm@ietf.org
References: <316ECF88-612A-4131-8A96-E5F76671929A@vigilsec.com> <044a01d1af10$1548b8c0$3fda2a40$@gmail.com>  <023a01d1b03f$b444c8d0$1cce5a70$@gmail.com> <573B2119.3060800@cs.tcd.ie>  <573B469D.7020603@cs.tcd.ie> <029301d1b05e$a0992320$e1cb6960$@augustcellars.com>
From: Stephen Farrell 
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <573B6696.30806@cs.tcd.ie>
Date: Tue, 17 May 2016 19:44:38 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <029301d1b05e$a0992320$e1cb6960$@augustcellars.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms020500010502040507050601"
Archived-At: 
Subject: Re: [Spasm] more scoping is needed
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 17 May 2016 18:44:46 -0000

This is a cryptographically signed message in MIME format.

--------------ms020500010502040507050601
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



On 17/05/16 18:07, Jim Schaad wrote:
> I can see two different types of statements coming from this:
>=20
> 1.  We are not going to pick up any work which is not specific to
> environments other than WebPKI and S/MIME.  (For some value of
> WebPKI), and
>=20
> 2. We are going to ignore any implications of our work which are not
> in those two environments.
>=20
> I am assuming you mean the first statement not the second in terms of
> doing scoping.

Not quite.

I do sort of agree with #1. Or at least the work items identified so
far seem to fit that description. (Hence my suggestion to tie any
more precise scoping to the specific work items.)

Wrt #2 with s/ignore any/not endlessly debate and get side-tracked by
the/ then I'd agree. I'd love something in the charter that allows
the chairs to beat away such debate, given that it's probably quite
likely folks will want to engage in such. And I base that on having
been involved and watched us (incl. me) do that back since the start
of PKIX in 1995;-)

S.


>=20
> Jim
>=20
>=20
> -----Original Message----- From: Spasm
> [mailto:spasm-bounces@ietf.org] On Behalf Of Stephen Farrell Sent:
> Tuesday, May 17, 2016 9:28 AM To: Brown, Wendy (10421)
> ; spasm@ietf.org Subject: Re: [Spasm] more
> scoping is needed
>=20
>=20
> Hiya,
>=20
> On 17/05/16 17:18, Brown, Wendy (10421) wrote:
>> Please do NOT de-scope the cross-certified environment. Proposed=20
>> changes of this type may have a great impact on the US Federal PKI
>>  which is a large cross-certified environment.
>=20
> So I get that concern. Mine however is that we have a history of the
> complexity inherent in that particular PKI causing unnecessary
> complexity elsewhere, e.g. for the WebPKI, where things like policy
> mappings are of no use whatsoever.
>=20
> To be entirely clear: I have no interest in sponsoring anything where
> there's a reasonable chance of it turning into another 19 year long
> odyssey involving many debates about PKI-angels on the heads of
> PKI-pins.
>=20
> Having to consider all the complexity of the US Federal PKI when any
> other change is suggested sounds to me to be perilously close to the
> above, so I would welcome folks' suggested charter text on how we can
> handle that conundrum.
>=20
> S.
>=20
>>=20
>> Thanks, Wendy Brown
>>=20
>> -----Original Message----- From: Stephen Farrell=20
>> [mailto:stephen.farrell@cs.tcd.ie] Sent: Tuesday, May 17, 2016 9:48
>> AM To: spasm@ietf.org Subject: [Spasm] more scoping is needed
>> (was: Re: My take on handling EKU constraints)
>>=20
>>=20
>> Question for the list:
>>=20
>> On 17/05/16 14:26, Santosh Chokhani wrote:
>>> But, this does not help the cross-certified environment.
>>=20
>> Is that environment of interest? Should we de-scope it in the
>> proposed charter? Or if not, should it be limited to consideration
>> for only the smime email application?
>>=20
>>> From what I've heard so far, the only folks who seem to be
>> planning implementations are interested in the WebPKI and in=20
>> enterprise smime. Is that correct?
>>=20
>> If in fact we have implementers who are planning to write code for
>>  something else, those implementers should say so before we're done
>>  with the charter.
>>=20
>> We may save ourselves some extended debates if we can craft charter
>>  text to reflect the scope of the real work that folks want to do.
>>=20
>> 
>>=20
>> In any case, this mail thread has convinced me that we do need some
>>  more scoping text in the charter, perhaps to name a primary
>> use-case for each of the work items and to say that wider
>> (abstract, near theoretical) considerations of (the consequences
>> of) the same work items are to be discouraged as we know from
>> history that those discussions move glacially, are terribly
>> distracting and have lead to worse outcomes in the past. Text
>> suggestions welcome.
>>=20
>> And to be clear, I will not be pushing the next button in the
>> formal chartering process until we've tackled this issue, either
>> adding text such as the above or convincing me that it's not
>> needed. (And I fully admit to possibly having an overly-sensitive
>> ocean-boiling-ahead detector here;-)
>>=20
>> 
>>=20
>> Cheers, S.
>>=20
>> NOTICE: Protiviti is a global consulting and internal audit firm=20
>> composed of experts specializing in risk and advisory services.=20
>> Protiviti is not licensed or registered as a public accounting firm
>>  and does not issue opinions on financial statements or offer=20
>> attestation services. This electronic mail message is intended=20
>> exclusively for the individual or entity to which it is addressed.=20
>> This message, together with any attachment, may contain
>> confidential and privileged information. Any views, opinions or
>> conclusions expressed in this message are those of the individual
>> sender and do not necessarily reflect the views of Protiviti Inc.
>> or its affiliates. Any unauthorized review, use, printing, copying,
>> retention, disclosure or distribution is strictly prohibited. If
>> you have received this message in error, please immediately advise
>> the sender by reply email message to the sender and delete all
>> copies of this message. Thank you.=20
>> _______________________________________________ Spasm mailing list
>>  Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm
>>=20
>=20
>=20
> _______________________________________________ Spasm mailing list=20
> Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm
>=20


--------------ms020500010502040507050601
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
CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ
BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD
ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll
bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw
aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA
Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra
C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3
rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5
R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r
dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt
3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw
MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ
QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv
BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5
BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu
Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll
bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc
MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE
MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG
9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD
C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9
U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM
aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai
9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC
BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE
BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs
IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g
QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC
SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC
ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv
mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm
VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4
D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI
dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu
N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE
FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp
MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE
WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG
JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+
SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g
BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv
bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY
0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF
NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9
uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p
6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv
Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu
mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7
RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO
/ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN
JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM
MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG
A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0
Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA
oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA1MTcx
ODQ0MzhaMC8GCSqGSIb3DQEJBDEiBCDKxOAgpSZWW3umHAZZCtKjAojCkXAa0qPN45XaL4cz
jTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN
AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC
AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw
IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB
nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD
VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq
hkiG9w0BAQEFAASCAQBIGVv5obhBrDhCfCacKza/0IzpbTFbdxZ6n240QxNHT9q6vSK6pcci
J16Kmnr/6z9Lk8KZCkQ5mncTpda50wJrzHjtinH16NHPMnV0zxMNfnlkwE01ZqlSDuZ9CzjC
gaaX0B/qbw8bOa0H4cGcSxXkhQ+nkeKw6+KJpABidzDDzdBKkYn5H3bmJ9eOxLce3Y/S47C0
0zOBU7+fOgQYnHbOXZ9hctuQ74vh/i9TrK8YXDVlaHK/rwyNPvM4BQYJ70Nrg9y1Qv5fATVe
3ykWQLRVyZxQuPDlc3TSCMCKeo0NPxknjwTdubumtcqkJsq434Xy0WIcLOD+GytLfOdng1UB
AAAAAAAA
--------------ms020500010502040507050601--


From nobody Tue May 17 11:46:00 2016
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 80D1712D8D4 for ; Tue, 17 May 2016 11:45:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Level: 
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nKmM2tWTjWTp for ; Tue, 17 May 2016 11:45:58 -0700 (PDT)
Received: from mail.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 0459F12D72B for ; Tue, 17 May 2016 11:45:58 -0700 (PDT)
Received: from localhost (ronin.smetech.net [209.135.209.5]) by mail.smetech.net (Postfix) with ESMTP id A085DF2405B; Tue, 17 May 2016 14:45:57 -0400 (EDT)
X-Virus-Scanned: amavisd-new at smetech.net
Received: from mail.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id 9JHKslz7slKW; Tue, 17 May 2016 14:28:45 -0400 (EDT)
Received: from [10.189.67.136] (unknown [192.54.222.20]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.smetech.net (Postfix) with ESMTP id 3E116F24013; Tue, 17 May 2016 14:45:35 -0400 (EDT)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Russ Housley 
In-Reply-To: <023a01d1b03f$b444c8d0$1cce5a70$@gmail.com>
Date: Tue, 17 May 2016 14:30:51 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <6A59D772-815F-45A0-BB28-BE42149C44BD@vigilsec.com>
References: <316ECF88-612A-4131-8A96-E5F76671929A@vigilsec.com> <044a01d1af10$1548b8c0$3fda2a40$@gmail.com>  <023a01d1b03f$b444c8d0$1cce5a70$@gmail.com>
To: Santosh Chokhani 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: 
Cc: spasm@ietf.org
Subject: [Spasm] Criticality of EKU constraints
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 17 May 2016 18:45:59 -0000

Santosh:

Breaking into two responses, each with a different subject line.

>> 2.  The language at the end of Section 2 regarding extension=20
>> processing and tying it to criticality does not seem right to me. =20
>> Criticality of extension should not impact its processing  It also=20
>> relates to my concerns regarding wrap up procedure in Section 3.  I =
would
> like the criticality part removed.
>=20
> This seems like the same as comment 1.
> [Santosh] It is a bit different.  The I-D says "Conforming =
applications MUST
> be able to process this extension.  If
>   any CA certificate in the certification path includes an EKU =
constraints
> extension that is marked as critical, and the end-entity
>   certificate includes an extended key usage certificate extension,
>   then the application MUST either process the EKU constraint or =
reject
>   the certificate."  I would say even if the extension is marked
> non-critical and end-entity certificate includes EKU, it needs to be
> processed.  We do not generally change the processing semantics of an
> extension due to criticality.  If what you are saying is that if the =
end
> certificate does not include EKU and the application does not =
understand the
> EKU constraints extension, it can be ignored.  But, that is dangerous =
since
> the application will think the certificate is good for all key =
purposes and
> the path is not.  Also, this will be impacted by the decision on =
whether you
> choose input as Jim Schaad has suggested.  In that scenario, the =
extension
> does need to be processed even if the end certificate does not have =
EKU.

We have had this discussion over and over on the PKIX mail list.

RFC 5280 has set the precedent on criticality for an extension in a CA =
certificate that impose restrictions on things that can appear in =
subsequent certificates in the path:

   4.2.1.10.  Name Constraints

     Conforming CAs MUST mark this extension as critical =85

   4.2.1.11.  Policy Constraints

      Conforming CAs MUST mark this extension as critical.

Russ


From nobody Tue May 17 12:18:45 2016
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 C320712D975 for ; Tue, 17 May 2016 12:18:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Level: 
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XgFY6ijKCXdt for ; Tue, 17 May 2016 12:18:41 -0700 (PDT)
Received: from mail.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 661CF12D9BA for ; Tue, 17 May 2016 12:18:40 -0700 (PDT)
Received: from localhost (ronin.smetech.net [209.135.209.5]) by mail.smetech.net (Postfix) with ESMTP id 9D798F2402A; Tue, 17 May 2016 15:18:39 -0400 (EDT)
X-Virus-Scanned: amavisd-new at smetech.net
Received: from mail.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id jBZKfq22jTMG; Tue, 17 May 2016 15:01:17 -0400 (EDT)
Received: from [10.189.67.136] (unknown [192.54.222.20]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.smetech.net (Postfix) with ESMTP id C54AFF24013; Tue, 17 May 2016 15:18:28 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Russ Housley 
In-Reply-To: <023a01d1b03f$b444c8d0$1cce5a70$@gmail.com>
Date: Tue, 17 May 2016 15:18:04 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <63601411-2A87-43DD-8221-C22192E8F57D@vigilsec.com>
References: <316ECF88-612A-4131-8A96-E5F76671929A@vigilsec.com> <044a01d1af10$1548b8c0$3fda2a40$@gmail.com>  <023a01d1b03f$b444c8d0$1cce5a70$@gmail.com>
To: Santosh Chokhani 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: 
Cc: spasm@ietf.org
Subject: [Spasm] Output from EKU constraints
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 17 May 2016 19:18:43 -0000

Santosh:

Breaking into two responses, each with a different subject line.

>> 3.  Now to the wrap up procedure in Section 3, I would recommend=20
>> taking an intersection of permitted EKU Constraint State and EKU in=20=

>> the end certificate and then deleting the EKUs in the result that are=20=

>> in the excluded EKU Constraint State.  Now, the resulting EKU set=20
>> should be returned to the application for enforcement.  It is quite=20=

>> possible that some applications do not care about EKUs at all.  I=20
>> could live with if the group decides if the resulting EKU set is =
null, it
> is a path validation failure.
>> But, my preference is for the application to enforce it.
>=20
> As I said in my response to Jim, I was trying to not impact the API to =
the
> certification path validation library.  This would be a significant =
change.
> It would trim the set if key purpose ids in the end-entity certificate =
to
> those that meet the restrictions.  It is easy to add to the =
specification,
> but it is harder to get deployed in applications.
> [Santosh] The way the current logic is, if the path is not good for =
all the
> EKUs in the end certificate, the path is invalid.  That may be ok for
> Enterprise PKI and does reject mis-issued certificates assuming the
> Enterprise PKI designer has done static analysis on EKU constraint =
required
> at each stage.  But, this does not help the cross-certified =
environment.
> Say one PKI wants to trust another for client authentication and =
S/MIME, but
> not for Smart Card Logon.  The proposed approach will not work unless =
the
> end certificate are issued for single key purpose.
>=20
> [Santosh] The input approach suggested is less complicated that the =
approach
> I suggest.  Under my approach, there is a possibility that you will =
need to
> output a flag with the EKUs whether the list is excluded or not since =
there
> is an edge case where only excluded get accumulated.

Jim has suggested that it would be good to change Section 3.1 to provide =
an input that gives a set of key purpose identifiers that are desired.

You suggested that it would be good to change Section 3.6 to provide an =
output that provides a trimmed set of key purpose identifiers that are =
authorized.

I understand the reason that these are desired.  My concern with these =
ideas is that the API to the certification path library is impacted.  It =
seems to me that we can meet the CAB Forum need without these.  I do not =
want to add a hurdle to the deployment.


> What do others think?
> [Santosh] I have spoken as someone who designs lots of PKI stuff.  It =
would
> be nice to hear from those who implement path validation libraries and
> develop PK enabled applications as to what they prefer.  The proposed
> approach of hard failure of a perfectly valid certificate which is =
good for
> the key purpose the application desires is wrong.

Indeed.  Changing the API had a significant impact to both.

Russ

[1]=


From nobody Tue May 17 12:29:10 2016
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 52E3212DD59 for ; Tue, 17 May 2016 12:29:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Level: 
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qnp9Dy9ep-rr for ; Tue, 17 May 2016 12:29:07 -0700 (PDT)
Received: from mail.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id B4AE112DD55 for ; Tue, 17 May 2016 12:29:07 -0700 (PDT)
Received: from localhost (ronin.smetech.net [209.135.209.5]) by mail.smetech.net (Postfix) with ESMTP id 78DE6F24013; Tue, 17 May 2016 15:29:07 -0400 (EDT)
X-Virus-Scanned: amavisd-new at smetech.net
Received: from mail.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id ap1WvVJxeJ5x; Tue, 17 May 2016 15:11:45 -0400 (EDT)
Received: from [10.189.52.232] (unknown [192.54.222.12]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.smetech.net (Postfix) with ESMTP id D04C8F2405B; Tue, 17 May 2016 15:28:56 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Russ Housley 
In-Reply-To: <024a01d1b040$1fd17030$5f745090$@gmail.com>
Date: Tue, 17 May 2016 15:28:33 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <8702CEF5-F033-4D27-90BF-5D8446EE6BA8@vigilsec.com>
References: <316ECF88-612A-4131-8A96-E5F76671929A@vigilsec.com> <044a01d1af10$1548b8c0$3fda2a40$@gmail.com> <045901d1af13$29d85d60$7d891820$@gmail.com>  <024a01d1b040$1fd17030$5f745090$@gmail.com>
To: Santosh Chokhani 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: 
Cc: spasm@ietf.org
Subject: Re: [Spasm] My take on handling EKU constraints
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 17 May 2016 19:29:09 -0000

Regarding anyExtendedKeyUsage, RFC 5280 says:

   If a CA includes extended key usages to satisfy such applications,
   but does not wish to restrict usages of the key, the CA can include
   the special KeyPurposeId anyExtendedKeyUsage in addition to the
   particular key purposes required by the applications.  Conforming CAs
   SHOULD NOT mark this extension as critical if the anyExtendedKeyUsage
   KeyPurposeId is present.  Applications that require the presence of a
   particular purpose MAY reject certificates that include the
   anyExtendedKeyUsage OID but not the particular OID expected for the
   application.

So, I propose:

   The special key purpose identifier anyExtendedKeyUsage is not treated
   differently than any other key purpose identifier in processing the
   constraints.  If the anyExtendedKeyUsage key purpose identifier
   matches an entry in the excludedKeyPurposeIds field, then the
   anyExtendedKeyUsage key purpose identifier MUST NOT appear in the
   extended key usage extension of the end-entity certificate.  If the
   anyExtendedKeyUsage key purpose identifier appears in the extended
   key usage extension of the end-entity certificate, then the
   anyExtendedKeyUsage key purpose identifier MUST in the
   permittedKeyPurposeIds field.

Russ

On May 17, 2016, at 9:29 AM, Santosh Chokhani =
 wrote:

> Hi Russ,
>=20
> Regardless, the path validation logic needs to handle =
anyExtendedKeyUsage.
>=20
> anyExtendedKeyUsage appearing in permitted does not make sense since =
the
> field can be simply omitted.
>=20
> anyExtendedKeyUsag appearing in excluded may make sense if you want =
the path
> to be not valid for any specific EKU.
>=20
> -----Original Message-----
> From: Russ Housley [mailto:housley@vigilsec.com]=20
> Sent: Monday, May 16, 2016 5:14 PM
> To: Santosh Chokhani 
> Cc: spasm@ietf.org
> Subject: Re: [Spasm] My take on handling EKU constraints
>=20
> Santosh:
>=20
>> The I-D should address anyExtendedKeyUsage.  Either it should be=20
>> prohibited from the permitted or excluded or the path validation=20
>> engine should treat this value in either field as the UNIVERSAL set.
>=20
> I'd prefer to treat anyPurpose just like every other OID as far as the
> constraints are concerned.
>=20
> 	If it is in the excluded set, then is cannot appear.
> 	If it is in the permitted set, then it can appear.
>=20
> What do others think?
>=20
> Russ
>=20
>=20
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm


From nobody Tue May 17 12:34:55 2016
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 9029A12DD51 for ; Tue, 17 May 2016 12:34:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Level: 
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RuxkKkHzPvPD for ; Tue, 17 May 2016 12:34:52 -0700 (PDT)
Received: from mail.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 0754212D92D for ; Tue, 17 May 2016 12:34:52 -0700 (PDT)
Received: from localhost (ronin.smetech.net [209.135.209.5]) by mail.smetech.net (Postfix) with ESMTP id C2CF1F2402A; Tue, 17 May 2016 15:34:51 -0400 (EDT)
X-Virus-Scanned: amavisd-new at smetech.net
Received: from mail.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id mUguMJZs4j6Q; Tue, 17 May 2016 15:17:39 -0400 (EDT)
Received: from [10.189.52.232] (unknown [192.54.222.12]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.smetech.net (Postfix) with ESMTP id 196EAF24013; Tue, 17 May 2016 15:34:50 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Russ Housley 
In-Reply-To: <024b01d1b040$8b35a800$a1a0f800$@gmail.com>
Date: Tue, 17 May 2016 15:34:27 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <3F2EEF9D-55D9-40E9-ABC4-7704270B67A5@vigilsec.com>
References: <316ECF88-612A-4131-8A96-E5F76671929A@vigilsec.com> <044a01d1af10$1548b8c0$3fda2a40$@gmail.com> <045901d1af13$29d85d60$7d891820$@gmail.com> <045a01d1af14$8db12aa0$a9137fe0$@gmail.com>  <024b01d1b040$8b35a800$a1a0f800$@gmail.com>
To: Santosh Chokhani 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: 
Cc: spasm@ietf.org
Subject: Re: [Spasm] My take on handling EKU constraints
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 17 May 2016 19:34:54 -0000

Santosh:

Okay.  I suggest:

   5.  Security Considerations

   When a CA includes the extended key usage constraints certificate
   extension for a subordinate CA, the OCSPSigning key purpose
   identifier SHOULD be included in the permittedKeyPurposeIds field to
   enable the issuance of delegated OCSP Responder certificates.

Russ


On May 17, 2016, at 9:32 AM, Santosh Chokhani =
 wrote:

> Hi Russ,
>=20
> I would add something to the effect "CAs asserting this extension =
SHOULD
> consider including  OCSPSigning in permitted EKUs if the downstream =
CAs may
> issue delegated OCSP Responder certificates"
>=20
> -----Original Message-----
> From: Russ Housley [mailto:housley@vigilsec.com]=20
> Sent: Monday, May 16, 2016 5:17 PM
> To: Santosh Chokhani 
> Cc: spasm@ietf.org
> Subject: Re: [Spasm] My take on handling EKU constraints
>=20
> Santosh:
>=20
>> Some discussion of OCSPSigning EKU in permitted field to accommodate=20=

>> Delegated OCSP trust model will be useful.  May be in Security=20
>> Considerations Section.
>=20
> We could add a discussion about the consequences of a particular EKU =
in the
> end-entity certificate, but I cannot see why that is needed here.  You =
seem
> to be thinking about some specific concern, please say more.
>=20
> Russ
>=20
>=20


From nobody Tue May 17 12:51:44 2016
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 4F97B12DD7F for ; Tue, 17 May 2016 12:51:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.889
X-Spam-Level: 
X-Spam-Status: No, score=-101.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_KAM_HTML_FONT_INVALID=0.01, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7H2JbFjJc2zE for ; Tue, 17 May 2016 12:51:42 -0700 (PDT)
Received: from mail.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id A7C8712D98A for ; Tue, 17 May 2016 12:51:42 -0700 (PDT)
Received: from localhost (ronin.smetech.net [209.135.209.5]) by mail.smetech.net (Postfix) with ESMTP id EB7DDF2402A; Tue, 17 May 2016 15:51:41 -0400 (EDT)
X-Virus-Scanned: amavisd-new at smetech.net
Received: from mail.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id kuCta82kVMLE; Tue, 17 May 2016 15:34:29 -0400 (EDT)
Received: from [10.189.52.232] (unknown [192.54.222.12]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.smetech.net (Postfix) with ESMTP id 64870F24013; Tue, 17 May 2016 15:51:40 -0400 (EDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_6F4A39DA-42F5-43A4-9997-5782AC500740"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Russ Housley 
In-Reply-To: <025301d1b040$d35518a0$79ff49e0$@gmail.com>
Date: Tue, 17 May 2016 15:51:16 -0400
Message-Id: <92182DDF-8854-4B92-B779-E3F7DAB04C8D@vigilsec.com>
References: <316ECF88-612A-4131-8A96-E5F76671929A@vigilsec.com> <1b87369d-9812-b5c0-9631-ba9e638fd6d4@seantek.com> <14315127-9A40-4F56-874E-3725D9EF08A6@vigilsec.com> <405ff968-9d4b-42a8-2234-1209820a02b9@seantek.com> <025301d1b040$d35518a0$79ff49e0$@gmail.com>
To: Santosh Chokhani , Sean Leonard 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: 
Cc: spasm@ietf.org
Subject: Re: [Spasm] My take on handling EKU constraints
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 17 May 2016 19:51:44 -0000

--Apple-Mail=_6F4A39DA-42F5-43A4-9997-5782AC500740
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Santosh and Sean are speaking for CHOICE instead of SEQUENCE.

The resulting ASN.1 would be:

   ext-ExtKeyUsageConstraints EXTENSION ::=3D {
       SYNTAX EKUConstraints
       IDENTIFIED BY id-ce-ekuConstraints }

   id-ce-ekuConstraints OBJECT IDENTIFIER ::=3D  { id-pe TBD }

   EKUConstraints ::=3D CHOICE {
       permittedKeyPurposeIds   [0] KeyPurposeIds,
       excludedKeyPurposeIds    [1] KeyPurposeIds }

   KeyPurposeIds ::=3D SEQUENCE SIZE (1..MAX) OF KeyPurposeId


Does anyone think that this is the wrong thing to do?

Can you think of a case where a CA might want to use a combination of =
the two in the same certificate?

Russ


On May 17, 2016, at 9:34 AM, Santosh Chokhani =
 wrote:

> Sean,
> =20
> I support your idea of making this a CHOICE.
> =20
> Separately, upon further reflection and thought, having two state =
variables in path processing logic may be simpler.  When I started =
working it in my head, there are more edge cases if you tried only one =
variable leading to more software complexity.
> =20
> From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Sean Leonard
> Sent: Monday, May 16, 2016 11:56 PM
> To: spasm@ietf.org
> Subject: Re: [Spasm] My take on handling EKU constraints
> =20
> [SNIP]
> That is why I am (increasingly) harping on making this extension a =
CHOICE, rather than a SEQUENCE that can permit both.
>=20
> Sean
>=20


--Apple-Mail=_6F4A39DA-42F5-43A4-9997-5782AC500740
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

Santosh and Sean are speaking for CHOICE instead of =
SEQUENCE.

The resulting ASN.1 would =
be:

  =
 ext-ExtKeyUsageConstraints EXTENSION ::=3D {
  =
     SYNTAX EKUConstraints
      =
 IDENTIFIED BY id-ce-ekuConstraints =
}

   id-ce-ekuConstraints OBJECT =
IDENTIFIER ::=3D  { id-pe TBD }

  =
 EKUConstraints ::=3D CHOICE {
      =
 permittedKeyPurposeIds   [0] KeyPurposeIds,
  =
     excludedKeyPurposeIds    [1] KeyPurposeIds =
}

   KeyPurposeIds ::=3D SEQUENCE =
SIZE (1..MAX) OF =
KeyPurposeId


Does anyone think =
that this is the wrong thing to do?

Can you =
think of a case where a CA might want to use a combination of the two in =
the same =
certificate?

Russ


On May 17, 2016, at 9:34 AM, Santosh Chokhani <santosh.chokhani@gmail.com&=
gt; wrote:

Sean,
 
I support your idea of =
making this a CHOICE.
 
Separately, upon further =
reflection and thought, having two state variables in path processing =
logic may be simpler.  When I started working it in my head, there =
are more edge cases if you tried only one variable leading to more =
software complexity.
 
From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Sean =
Leonard
Sent: Monday, May 16, 2016 11:56 =
PM
To: spasm@ietf.org
Subject: Re: [Spasm] My take on =
handling EKU constraints
 
[SNIP]
That =
is why I am (increasingly) harping on making this extension a CHOICE, =
rather than a SEQUENCE that can permit =
both.

Sean

<=
/div>=

--Apple-Mail=_6F4A39DA-42F5-43A4-9997-5782AC500740--


From nobody Tue May 17 13:00:23 2016
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 E3E3712DDA3 for ; Tue, 17 May 2016 13:00:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.889
X-Spam-Level: 
X-Spam-Status: No, score=-101.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_KAM_HTML_FONT_INVALID=0.01, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hJAg4J8EVii5 for ; Tue, 17 May 2016 13:00:16 -0700 (PDT)
Received: from mail.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 6613512DD90 for ; Tue, 17 May 2016 13:00:16 -0700 (PDT)
Received: from localhost (ronin.smetech.net [209.135.209.5]) by mail.smetech.net (Postfix) with ESMTP id 28260F2402A; Tue, 17 May 2016 16:00:16 -0400 (EDT)
X-Virus-Scanned: amavisd-new at smetech.net
Received: from mail.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id ohz07DkrSG+S; Tue, 17 May 2016 15:42:53 -0400 (EDT)
Received: from [10.189.52.232] (unknown [192.54.222.12]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.smetech.net (Postfix) with ESMTP id C0122F24013; Tue, 17 May 2016 16:00:03 -0400 (EDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_9ACFCCC2-2F1F-40E0-B344-ADC3574AC5A7"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Russ Housley 
In-Reply-To: <026001d1b054$c1a4a7b0$44edf710$@augustcellars.com>
Date: Tue, 17 May 2016 15:59:40 -0400
Message-Id: <83ABC2C4-8534-48E6-A5FA-4946A5F95761@vigilsec.com>
References: <316ECF88-612A-4131-8A96-E5F76671929A@vigilsec.com> <1b87369d-9812-b5c0-9631-ba9e638fd6d4@seantek.com> <14315127-9A40-4F56-874E-3725D9EF08A6@vigilsec.com> <405ff968-9d4b-42a8-2234-1209820a02b9@seantek.com> <026001d1b054$c1a4a7b0$44edf710$@augustcellars.com>
To: Sean Leonard , Jim Schaad 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: 
Cc: spasm@ietf.org
Subject: Re: [Spasm] My take on handling EKU constraints
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 17 May 2016 20:00:20 -0000

--Apple-Mail=_9ACFCCC2-2F1F-40E0-B344-ADC3574AC5A7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

This is a better way to do it than the way that I posted =85.

It is not needed if we change the SEQUENCE to a CHOICE.

Russ


On May 17, 2016, at 11:57 AM, Jim Schaad  wrote:

> The ASN.1 you are looking for is
> =20
>    NameConstraints ::=3D SEQUENCE {
>         permittedSubtrees       [0] GeneralSubtrees OPTIONAL,
>         excludedSubtrees        [1] GeneralSubtrees OPTIONAL
>    }
>    (WITH COMPONENTS { ..., permittedSubtrees PRESENT} |
>     WITH COMPONENTS { ..., excludedSubtrees PRESENT }}
> =20
> Which formally requires one of the elements to be present.
> =20
> Jim
> =20
> =20
> From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Sean Leonard
> Sent: Monday, May 16, 2016 8:56 PM
> To: spasm@ietf.org
> Subject: Re: [Spasm] My take on handling EKU constraints
> =20
> On 5/16/2016 2:22 PM, Russ Housley wrote:
> =20
> On May 16, 2016, at 2:16 AM, Sean Leonard  =
wrote:
> =20
> Hello:
> =20
> In the ASN.1 module (to be written), it's important to specify whether =
this extension uses IMPLICIT, EXPLICIT, or AUTOMATIC tagging. I am =
guessing folks don't want to use AUTOMATIC tagging, even though it's =
recommended by the latest ASN.1 standards because it's "easy". My =
personal preference is for EXPLICIT tagging. However, the extended key =
usage extension is defined in the IMPLICIT module in RFC 5280, so it's =
IMPLICIT...this means that if you want symmetry with the EKU extension, =
you should say it's IMPLICIT.
> =20
> I was assuming that IMPLICIT would be used.
>=20
> Ok; IMPLICIT needs to be in the next draft then.
>=20
>=20
> =20
> =20
> Is there a way, using the latest ASN.1 syntax, to specify =
"either-or-or-both", i.e., the EKUConstraints SEQUENCE must have at =
least one element, possibly two, but not zero?
> =20
> The text already says that.
>=20
> The text does, but not the ASN.1. I.e., an ASN.1 compiler can't =
enforce the constraint as written in the text. I see that as a flaw.
>=20
>=20
> =20
> =20
> As I understand it, "permitted" takes greater precedence over =
"excluded". I.e., if the extension has both permitted AND excluded, then =
really, only "permitted" is going to have meaningful effect.
> =20
> No, the text says that if the key purpose is the the excluded set, =
then it is excluded.
>=20
> I see how what I wrote could be misinterpreted; sorry about that. Of =
course if the key purpose is in the excluded set, then it is excluded. =
In that sense, an excluded OID takes precedence over the same OID being =
in the permitted set.
>=20
> The point is that putting an OID on both lists is pointless and =
needlessly complicated. If an OID is on the permitted list AND the =
excluded list, then, why is it on either list at all?
>=20
> Section 3.5 (h) (i) says:
>=20
>         (1)  If permitted_key_purpose_ids state variable is not =
special
>              value that represents the universal set, then confirm =
that
>              all of the key purpose identifiers are present in the =
set.
>              If any are missing, then returning a failure indication =
and
>              an appropriate reason.
>=20
>=20
> The permitted set of OIDs can, apparently, be: "infinity" (unbounded), =
"nonzero" (finite: bounded to only those listed), or "none" (zero). The =
moment ANY certificate in the path mentions a permitted set, you are =
forever thrown out of "infinity". It is now finite. Possibly zero. So =
the effect of having further excluded sets (after introducing the first =
permitted set), is only to whittle away at the finite permitted set of =
OIDs. You may as well either repeat the list of permitted EKUs, or =
whittle it down in the next certificate in the chain. Mentioning =
excluded sets only makes sense at the top of the chain, before the first =
"permitted set" is introduced.
>=20
> Example: consider a single CA cert in the chain that mentions both =
permitted and excluded:
> {
> permitted:
> 1.1.1.1
> 1.1.1.2
>=20
> excluded:
> 1.1.1.2
> 1.1.1.3
> 1.1.1.4
> }
>=20
> If only 1.1.1.1 and 1.1.1.2 are permitted, then mentioning 1.1.1.3 and =
1.1.1.4 as "excluded" serves no purpose. You may as well drop 1.1.1.3 =
and 1.1.1.4. Furthermore, since 1.1.1.2 is excluded, why bother =
mentioning it in "permitted"? That likewise serves no purpose. You may =
as well have said:
>=20
> {
> permitted:
> 1.1.1.1
> }
>=20
> and have been done with it.
>=20
> Mentioning the excluded set at all, only makes sense when there is no =
defined permitted set (i.e., the permitted set is the "special value =
that represents the universal set"). In that way, excluding those OIDs =
basically means we have the universal set ("infinity") MINUS a few =
mentioned OIDs.
>=20
> That is why I am (increasingly) harping on making this extension a =
CHOICE, rather than a SEQUENCE that can permit both.
>=20
> Sean
>=20
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm


--Apple-Mail=_9ACFCCC2-2F1F-40E0-B344-ADC3574AC5A7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

This =
is a better way to do it than the way that I posted =
=85.

It is not needed if we change the SEQUENCE to a =
CHOICE.

Russ


On May 17, 2016, at 11:57 AM, Jim Schaad <ietf@augustcellars.com> =
wrote:

The ASN.1 you are looking for =
is
 
   NameConstraints ::=3D SEQUENCE =
{
        =
permittedSubtrees       [0] =
GeneralSubtrees OPTIONAL,
        =
excludedSubtrees        [1] =
GeneralSubtrees OPTIONAL
   =
}
   (WITH COMPONENTS { ..., permittedSubtrees =
PRESENT} |
    WITH COMPONENTS { ..., excludedSubtrees =
PRESENT }}
 
Which formally requires one of the elements to be =
present.
 
Jim
 
 
From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Sean =
Leonard
Sent: Monday, May 16, 2016 8:56 =
PM
To: spasm@ietf.org
Subject: Re: [Spasm] My take on =
handling EKU constraints
 
On 5/16/2016 2:22 PM, Russ Housley =
wrote:
 
On May 16, 2016, at =
2:16 AM, Sean Leonard <dev+ietf@seantek.com> wrote:
 
Hello:
 
In the ASN.1 module =
(to be written), it's important to specify whether this extension uses =
IMPLICIT, EXPLICIT, or AUTOMATIC tagging. I am guessing folks don't want =
to use AUTOMATIC tagging, even though it's recommended by the latest =
ASN.1 standards because it's "easy". My personal preference is for =
EXPLICIT tagging. However, the extended key usage extension is defined =
in the IMPLICIT module in RFC 5280, so it's IMPLICIT...this means that =
if you want symmetry with the EKU extension, you should say it's =
IMPLICIT.
 
I was assuming that =
IMPLICIT would be used.

Ok; IMPLICIT needs to be in the next draft =
then.


 
 
Is there a way, using the =
latest ASN.1 syntax, to specify "either-or-or-both", i.e., the =
EKUConstraints SEQUENCE must have at least one element, possibly two, =
but not zero?
 
The text already =
says that.

The text does, but not the ASN.1. I.e., an ASN.1 compiler =
can't enforce the constraint as written in the text. I see that as a =
flaw.


 
 
As I understand it, =
"permitted" takes greater precedence over "excluded". I.e., if the =
extension has both permitted AND excluded, then really, only "permitted" =
is going to have meaningful effect.
 
No, the =
text says that if the key purpose is the the excluded set, then it is =
excluded.

I see how what I wrote could be misinterpreted; sorry about =
that. Of course if the key purpose is in the excluded set, then it is =
excluded. In that sense, an excluded OID takes precedence over the same =
OID being in the permitted set.

The point is that putting an OID =
on both lists is pointless and needlessly complicated. If an OID is on =
the permitted list AND the excluded list, then, why is it on either list =
at all?

Section 3.5 (h) (i) says:

        (1)  If =
permitted_key_purpose_ids state variable is not =
special
           =
;  value that represents the universal set, then confirm =
that
           =
;  all of the key purpose identifiers are present in the =
set.
           =
;  If any are missing, then returning a failure indication =
and
           =
;  an appropriate reason.


The permitted set of OIDs can, =
apparently, be: "infinity" (unbounded), "nonzero" (finite: bounded to =
only those listed), or "none" (zero). The moment ANY certificate in the =
path mentions a permitted set, you are forever thrown out of "infinity". =
It is now finite. Possibly zero. So the effect of having further =
excluded sets (after introducing the first permitted set), is only to =
whittle away at the finite permitted set of OIDs. You may as well either =
repeat the list of permitted EKUs, or whittle it down in the next =
certificate in the chain. Mentioning excluded sets only makes sense at =
the top of the chain, before the first "permitted set" is =
introduced.

Example: consider a single CA cert in the chain that =
mentions both permitted and =
excluded:
{
permitted:
1.1.1.1
1.1.1.2

excluded:
1.1=
.1.2
1.1.1.3
1.1.1.4
}

If only 1.1.1.1 and 1.1.1.2 are =
permitted, then mentioning 1.1.1.3 and 1.1.1.4 as "excluded" serves no =
purpose. You may as well drop 1.1.1.3 and 1.1.1.4. Furthermore, since =
1.1.1.2 is excluded, why bother mentioning it in "permitted"? That =
likewise serves no purpose. You may as well have =
said:

{
permitted:
1.1.1.1
}

and have been done =
with it.

Mentioning the excluded set at all, only makes sense =
when there is no defined permitted set (i.e., the permitted set is the =
"special value that represents the universal set"). In that way, =
excluding those OIDs basically means we have the universal set =
("infinity") MINUS a few mentioned OIDs.

That is why I am =
(increasingly) harping on making this extension a CHOICE, rather than a =
SEQUENCE that can permit =
both.

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

=

--Apple-Mail=_9ACFCCC2-2F1F-40E0-B344-ADC3574AC5A7--


From nobody Tue May 17 13:22:48 2016
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 0267312D9AF for ; Tue, 17 May 2016 13:22:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R-G4LvU1VUKp for ; Tue, 17 May 2016 13:22:44 -0700 (PDT)
Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAF6012D9AE for ; Tue, 17 May 2016 13:22:44 -0700 (PDT)
Received: from hebrews (173-8-216-38-Oregon.hfc.comcastbusiness.net [173.8.216.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 10A5B2CA16; Tue, 17 May 2016 13:22:42 -0700 (PDT)
From: "Jim Schaad" 
To: "'Russ Housley'" , "'Santosh Chokhani'" , "'Sean Leonard'" 
References: <316ECF88-612A-4131-8A96-E5F76671929A@vigilsec.com> <1b87369d-9812-b5c0-9631-ba9e638fd6d4@seantek.com> <14315127-9A40-4F56-874E-3725D9EF08A6@vigilsec.com> <405ff968-9d4b-42a8-2234-1209820a02b9@seantek.com> <025301d1b040$d35518a0$79ff49e0$@gmail.com> <92182DDF-8854-4B92-B779-E3F7DAB04C8D@vigilsec.com>
In-Reply-To: <92182DDF-8854-4B92-B779-E3F7DAB04C8D@vigilsec.com>
Date: Tue, 17 May 2016 13:22:42 -0700
Message-ID: <02ed01d1b079$ddd2dbd0$99789370$@augustcellars.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_02EE_01D1B03F.31764DC0"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQG9AVJW+Y7xpWAUdsUf0IIYfjAqNAJIj4ReAPhuVbECBgKSvgFVFHTTAsBcYtqfnA0psA==
Content-Language: en-us
Archived-At: 
Cc: spasm@ietf.org
Subject: Re: [Spasm] My take on handling EKU constraints
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 17 May 2016 20:22:46 -0000

This is a multipart message in MIME format.

------=_NextPart_000_02EE_01D1B03F.31764DC0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Given the recent suggested change, I think that one might wish to say

  Permit = S/MIME,

  Exclude = anyKeyUsage

 

One would need to remove the any usage if one really wants to restrict to a
specific usage.

 

Jim

 

 

From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Russ Housley
Sent: Tuesday, May 17, 2016 12:51 PM
To: Santosh Chokhani ; Sean Leonard

Cc: spasm@ietf.org
Subject: Re: [Spasm] My take on handling EKU constraints

 

Santosh and Sean are speaking for CHOICE instead of SEQUENCE.

 

The resulting ASN.1 would be:

 

   ext-ExtKeyUsageConstraints EXTENSION ::= {

       SYNTAX EKUConstraints

       IDENTIFIED BY id-ce-ekuConstraints }

 

   id-ce-ekuConstraints OBJECT IDENTIFIER ::=  { id-pe TBD }

 

   EKUConstraints ::= CHOICE {

       permittedKeyPurposeIds   [0] KeyPurposeIds,

       excludedKeyPurposeIds    [1] KeyPurposeIds }

 

   KeyPurposeIds ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId

 

 

Does anyone think that this is the wrong thing to do?

 

Can you think of a case where a CA might want to use a combination of the
two in the same certificate?

 

Russ

 

 

On May 17, 2016, at 9:34 AM, Santosh Chokhani  > wrote:





Sean,

 

I support your idea of making this a CHOICE.

 

Separately, upon further reflection and thought, having two state variables
in path processing logic may be simpler.  When I started working it in my
head, there are more edge cases if you tried only one variable leading to
more software complexity.

 

From: Spasm [  mailto:spasm-bounces@ietf.org]
On Behalf Of Sean Leonard
Sent: Monday, May 16, 2016 11:56 PM
To:   spasm@ietf.org
Subject: Re: [Spasm] My take on handling EKU constraints

 

[SNIP]

That is why I am (increasingly) harping on making this extension a CHOICE,
rather than a SEQUENCE that can permit both.

Sean

 


------=_NextPart_000_02EE_01D1B03F.31764DC0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Given the =
recent suggested change, I think that one might wish to =
say
  =
Permit =3D S/MIME,
  =
Exclude =3D anyKeyUsage
 
One would =
need to remove the any usage if one really wants to restrict to a =
specific usage.
 
Jim
 
 
From:<=
/b> =
Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Russ =
Housley
Sent: Tuesday, May 17, 2016 12:51 PM
To: =
Santosh Chokhani <santosh.chokhani@gmail.com>; Sean Leonard =
<dev+ietf@seantek.com>
Cc: =
spasm@ietf.org
Subject: Re: [Spasm] My take on handling EKU =
constraints
 
Santosh and =
Sean are speaking for CHOICE instead of SEQUENCE.
 
The resulting ASN.1 would =
be:
 
   ext-ExtKeyUsageConstraints EXTENSION =
::=3D {
    =
   SYNTAX EKUConstraints
       IDENTIFIED BY =
id-ce-ekuConstraints }
 
   id-ce-ekuConstraints OBJECT IDENTIFIER =
::=3D  { id-pe TBD }
 
   EKUConstraints ::=3D CHOICE =
{
      =
 permittedKeyPurposeIds   [0] =
KeyPurposeIds,
  =
     excludedKeyPurposeIds    [1] KeyPurposeIds =
}
 
   KeyPurposeIds ::=3D SEQUENCE SIZE =
(1..MAX) OF KeyPurposeId
 
 
Does anyone think that this is the wrong thing to =
do?
 
Can you think of a case where a CA might want to use a =
combination of the two in the same =
certificate?
 
Russ
 
 
On =
May 17, 2016, at 9:34 AM, Santosh Chokhani <santosh.chokhani@gmail.com=
> wrote:


Sean,
 
I support your idea of making this a =
CHOICE.
 
Separately, upon further reflection and thought, having two state =
variables in path processing logic may be simpler.  When I started =
working it in my head, there are more edge cases if you tried only one =
variable leading to more software =
complexity.
 
From:<=
/b> =
Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Sean =
Leonard
Sent: Monday, May 16, 2016 11:56 =
PM
To: spasm@ietf.org
Subject: Re: [Spasm] My take on =
handling EKU constraints
 
[SNIP]
That is why I am (increasingly) harping =
on making this extension a CHOICE, rather than a SEQUENCE that can =
permit both.

Sean
 

------=_NextPart_000_02EE_01D1B03F.31764DC0--


From nobody Tue May 17 13:25:00 2016
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 B3AB612D9B7 for ; Tue, 17 May 2016 13:24:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level: 
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VFvneT7CWbfV for ; Tue, 17 May 2016 13:24:57 -0700 (PDT)
Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D13012D9B4 for ; Tue, 17 May 2016 13:24:57 -0700 (PDT)
Received: by mail-qg0-x231.google.com with SMTP id f92so14967526qgf.0 for ; Tue, 17 May 2016 13:24:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=mabS8TDOW9txj/NupV08AYIPAO7CWGmvnCEK1JN3Ihw=; b=WxYM8ts5OtKCuh1ggmv+/71xiAzkYdD5S1nHVvlQ5+7YH98FqB+0tH+CGY9vMP+wCm V+gu+/DmwwjGs1bvV1zq/MSYOJ0KMR7YySoM2TQ/jmfCL+LpJUEzh/Xtl62HomiwJXdh 70oYkEUWBqfW0PtW4jrGTxx7796ZDASTVw668=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=mabS8TDOW9txj/NupV08AYIPAO7CWGmvnCEK1JN3Ihw=; b=BRZUzUj+CP1CjwcjXF7yCx+aABQudd6es6Oty6whNaZP6UExC/hzsl157LV8PLcqMa Gk+vNNFoKfttA6aPeCC6xkQZA2zCMUthQaENebHMPUydL2ufemH1d3rp/+t4bqLMVCt5 axdQPqXPWtayLIdAz0MNUi1dy9+KHiW0g/xaeZJ2ofllGTgfJfWRNKCbZi96EwUR9k2I 45J7ZIvYDqBYanEZfzUqX1BqKowoiXP5vbmS7oAjRYQJhtJLh9+EjQNd/FqBhApC0lVu +gZJrb6uk7/WFyNJ9OUS5YosjZzvyuRyo8ObVkyavSKhaPxGCOWKk8wjra///BU/0wsZ if5Q==
X-Gm-Message-State: AOPr4FXhOcKTQgJMwirNIjAOR4pk2Lkz4dfeQ3WVfZVjkbwMBbjWkupZr0qL43NIRZ7+HQ==
X-Received: by 10.140.222.210 with SMTP id s201mr3851584qhb.67.1463516696750;  Tue, 17 May 2016 13:24:56 -0700 (PDT)
Received: from [172.16.0.112] ([96.231.218.80]) by smtp.gmail.com with ESMTPSA id v6sm2257746qhc.34.2016.05.17.13.24.55 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 17 May 2016 13:24:56 -0700 (PDT)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Sean Turner 
In-Reply-To: <3AE31EE3-08D8-4F0C-A3F6-BC8E42E769E7@vigilsec.com>
Date: Tue, 17 May 2016 16:24:54 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <316ECF88-612A-4131-8A96-E5F76671929A@vigilsec.com> <1b87369d-9812-b5c0-9631-ba9e638fd6d4@seantek.com> <14315127-9A40-4F56-874E-3725D9EF08A6@vigilsec.com> <405ff968-9d4b-42a8-2234-1209820a02b9@seantek.com> <3AE31EE3-08D8-4F0C-A3F6-BC8E42E769E7@vigilsec.com>
To: Russ Housley 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: spasm@ietf.org
Subject: Re: [Spasm] My take on handling EKU constraints
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 17 May 2016 20:24:59 -0000

On May 17, 2016, at 11:24, Russ Housley  wrote:
>=20
>=20
>> That is why I am (increasingly) harping on making this extension a =
CHOICE, rather than a SEQUENCE that can permit both.
>=20
> What do others think?
>=20

I tend to lean towards SEQUENCE.

spt


From nobody Tue May 17 16:19:07 2016
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 A5FE512DA5B for ; Tue, 17 May 2016 16:19:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level: 
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, 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 40sBNiiiqzX6 for ; Tue, 17 May 2016 16:19:03 -0700 (PDT)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (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 C738412DAD8 for ; Tue, 17 May 2016 16:19:01 -0700 (PDT)
Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id B4A9D509B6 for ; Tue, 17 May 2016 19:19:00 -0400 (EDT)
To: spasm@ietf.org
From: Sean Leonard 
Message-ID: 
Date: Tue, 17 May 2016 16:18:07 -0700
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: [Spasm] Technical & Editorial Quality Control in this WG: some ASN.1 points
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 17 May 2016 23:19:05 -0000

I would like to propose a few ASN.1 points for this spasm WG to follow, 
to maintain a high level of Technical & Editorial Quality Control.

These proposed points should be effective for final publications from 
this WG:

Pick an ASN.1 standard to use as the normative reference. The current 
ITU-T standard in force is X.680: August 2015. We are no longer in the 
mid-90s, and there are at least a few widely-available, high-quality, 
open-source ASN.1 compiler tools that support the "new" syntax (new 
meaning, the syntax after 1988). If folks want or need 1988 syntax, then 
the 1988 syntax can be given in an informative (*not* normative) appendix.

Pick one of IMPLICIT, EXPLICIT, or AUTOMATIC for all WG output. (X.680 
recommends AUTOMATIC, but I am guessing there is an inherent bias 
towards IMPLICIT around these parts).

For character strings, UTF8String should always be used, unless 
backwards compatibility is a requirement (e.g., 
DirectoryString/distinguished names).

BOOLEAN is for an element with two alternatives.

If an element can take on one of a finite, enumerated set of values 
(more than two), ENUMERATED should be used. (I.e., not named INTEGERs.)

BITSTRING should be avoided, unless backwards compatibility is a 
requirement (e.g., SignatureValue) or the circumstances truly call for 
data in a non-integral number of octets.

Embedded ASN.1 (BER/DER) should not be stuffed into OCTET STRING.

For time, we have a lot of different time types to pick from. I really 
have no idea why time has to be so complicated...there are UTCTime, 
GeneralizedTime, BinaryTime [RFC6019], and the "new" TIME (X.680 Clause 
38). I am sure that people have stuffed time into other inappropriate 
types as well. It's time...for an overhaul! ha ha. X.680 recommends the 
"new" TIME. But, I suspect that this WG will settle upon 
GeneralizedTime, strictly limited to UTC (zero-offset) and no fractions 
of a second.

If the publication includes a text specification, the specification 
shall use ABNF normatively.

Each publication should have a normative ASN.1 module (if it uses ASN.1 
at all), which is submitted and maintained as a separate file with 
network (CRLF) line endings. The SHA-256 hash of the file should be 
included in the published RFC.

Before publication, each ASN.1 module (along with all of its 
dependencies) must be successfully compiled and verified by two 
independent ASN.1 compiler implementations.

Comments, etc. welcome.

Regards,

Sean


From nobody Tue May 17 17:27:06 2016
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 392C112D734 for ; Tue, 17 May 2016 17:27:05 -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 (1024-bit key) header.d=sn3rd.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wba5w8FiQQ11 for ; Tue, 17 May 2016 17:27:03 -0700 (PDT)
Received: from mail-qg0-x229.google.com (mail-qg0-x229.google.com [IPv6:2607:f8b0:400d:c04::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 B72E812B032 for ; Tue, 17 May 2016 17:27:03 -0700 (PDT)
Received: by mail-qg0-x229.google.com with SMTP id 90so17766669qgz.1 for ; Tue, 17 May 2016 17:27:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=IzP/zI0JxRv1jEPIpUE8+/kl92FOYf2DgJQhykCQ1ns=; b=mPG/wi6Gt583Rc23W4FNEtpzf/9/2ipIiFINx5vrrFjk2bFWKMFYVzJWYuJi3eYijn i72dax3hh53XpBpAxwnIXXrVNUZEKXgPZnwPUAybGlImwxC8dC/StVbvDQ7CnZj3nqq4 QD8XBgjb6T1vIz1+4Jcn4z/RuD77spHnB45EQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=IzP/zI0JxRv1jEPIpUE8+/kl92FOYf2DgJQhykCQ1ns=; b=JnHBtezHVraZPd38j5c3eLSrqL7SefyJIb6WyKCithwvFx0wwN0WKnv1UmDu3ldQ9j RHBbhDKAv+pj8NRgAaV/Rv/dYxP/z94kCkR062yIBFoZ9BrfK7RXqhCUuBuvXgDlkZba OhKnisiIVXWnWU5hTxsNdK32Wop5RPJQclIQBA24xszq4nBblSoUbTp9PlnXye9lb7Wc emYC+WsWCooNwEarE9y3uwSMBbRJE2qKj5ouB+epkJ8fuUPDKd1POQXC02HYAQJiKiEe lPJaTLhUfv48Vhxue9cBCt9PfK7VORjC6KrafkiXT1ZgjUrlrcBq58jGIUqK9m8laxEb 5TvQ==
X-Gm-Message-State: AOPr4FXrC3EdhtBGukyAmif8yYKeA7Fn0+0pkeqpt8MRyJOEJX/DPw/oQKCKOh4sjArmLA==
X-Received: by 10.140.251.195 with SMTP id w186mr5005707qhc.57.1463531222853;  Tue, 17 May 2016 17:27:02 -0700 (PDT)
Received: from [172.16.0.112] ([96.231.218.80]) by smtp.gmail.com with ESMTPSA id 137sm2778399qhq.24.2016.05.17.17.27.02 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 17 May 2016 17:27:02 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Sean Turner 
In-Reply-To: 
Date: Tue, 17 May 2016 20:27:00 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <57E568BE-5FE4-4666-817B-696DE95883D0@sn3rd.com>
References: 
To: Sean Leonard 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: spasm@ietf.org
Subject: Re: [Spasm] Technical & Editorial Quality Control in this WG: some ASN.1 points
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 18 May 2016 00:27:05 -0000

On May 17, 2016, at 19:18, Sean Leonard  wrote:
>=20
> Pick an ASN.1 standard to use as the normative reference. The current =
ITU-T standard in force is X.680: August 2015.

We=E2=80=99ve been down this road before :/

RFC 5280 is =E2=80=9988 so we=E2=80=99re kinda stuck with that as the =
normative module.

We published =E2=80=9802 ASN.1 for PKIX in RFC 5912.  Some updates were =
also published in RFC 6268 and that used the =E2=80=9908 syntax profiled =
back to the =E2=80=9902 version.  I hope we can just do what we did for =
RFC 6268 for the alternate module.

spt=


From nobody Wed May 18 05:36:38 2016
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 C13AD12D141 for ; Wed, 18 May 2016 05:36:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tyllsJ0jACeA for ; Wed, 18 May 2016 05:36:31 -0700 (PDT)
Received: from mail-qg0-x235.google.com (mail-qg0-x235.google.com [IPv6:2607:f8b0:400d:c04::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7594A12D13C for ; Wed, 18 May 2016 05:36:30 -0700 (PDT)
Received: by mail-qg0-x235.google.com with SMTP id f92so24496610qgf.0 for ; Wed, 18 May 2016 05:36:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=Y4Du36EVIgql12Dc2br/koBXIfv11y+xRwUKrqQXYM4=; b=X7ltH0O7uuYwv2m0ien+xN9bxD601zobPb2g+nlP3eTLbBft1ePUBhmvABO94WjQFl JNFKzsXQUQp/LV6L6eWDSK4AKUUNornKV0IwN2smt8sDc2fsBpgXdalZVpMaLoZ1lomo 7wazOjROLpLc4zmSivwzd6BYgFBP8YL+WtaH5W7IrxW58NuBv+8GXYa/lZL/Y84E3yGn vbnl8ywC1wlpsb0a/JcRYF2rzJp+o0+XDL9bwVH+UrSp1RVD9qfwqdvG5wxP5oJ7QwB7 tAr8rOm0uYay5rvJ2vviGDKhdeHbnHk3WgFlypXmXFKXichVj5EQfyEV5t+2EACQCYWE UhCw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=Y4Du36EVIgql12Dc2br/koBXIfv11y+xRwUKrqQXYM4=; b=RkVflzob8kej7OJlMc02orHzSf+cSgTBxf0m0dC0CodaUgdafgCYfZ+TImgPcM/wwD /I86U29CXN6pP9VS/U9XYivrpGx+TeR9fdsuijKHJXOuC8mTUaY0jqCz4g9mhXV3cFQR 8fY46AhuGvNOvD+cYs0Pkw9YxxPArspCAXTsmc/uUBgjXFts6YOL31LtDLrEjjoMKpev UHFyPsVqWhLEz/xPzDPhwx8tia4pi9W7JXcFPLLMKJHuLqzdQArjbW+dgw1rHdWKQmwc tz6zs/WjDGo1EMT3vTyv6WnfM1A2wFBpxzWAVMF23TnJPjMjddMWOt7cblGdHqOlp0ju e47A==
X-Gm-Message-State: AOPr4FW1fYYwhHLNy3hhQs2Dat4HoCA0kE0xiRswiSZUJaxElt5xLY9ZNa2J/iCoy05dyA==
X-Received: by 10.140.233.140 with SMTP id e134mr7545314qhc.38.1463574989682;  Wed, 18 May 2016 05:36:29 -0700 (PDT)
Received: from SantoshBrain (pool-108-31-66-4.washdc.fios.verizon.net. [108.31.66.4]) by smtp.gmail.com with ESMTPSA id w5sm4020650qhc.15.2016.05.18.05.36.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 18 May 2016 05:36:28 -0700 (PDT)
From: "Santosh Chokhani" 
To: "'Stephen Farrell'" , 
References: <316ECF88-612A-4131-8A96-E5F76671929A@vigilsec.com> <044a01d1af10$1548b8c0$3fda2a40$@gmail.com>  <023a01d1b03f$b444c8d0$1cce5a70$@gmail.com> <573B2119.3060800@cs.tcd.ie>
In-Reply-To: <573B2119.3060800@cs.tcd.ie>
Date: Wed, 18 May 2016 08:36:27 -0400
Message-ID: <05ad01d1b101$e60a8db0$b21fa910$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQG9AVJW+Y7xpWAUdsUf0IIYfjAqNAGVztXGAdP+cJIB7kRbugGQAKc8n7C+kVA=
Content-Language: en-us
Archived-At: 
Subject: Re: [Spasm] more scoping is needed (was: Re: My take on handling EKU constraints)
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 18 May 2016 12:36:37 -0000

Hi Steve,

It would be nice if the I-D addressed the purpose of the extension and =
limitations on its scope and the problem being solved by the path =
validation logic.

Then we can either debate the scope or make the I-D accurate with =
respect to agreed on scope.

-----Original Message-----
From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Stephen Farrell
Sent: Tuesday, May 17, 2016 9:48 AM
To: spasm@ietf.org
Subject: [Spasm] more scoping is needed (was: Re: My take on handling =
EKU constraints)


Question for the list:

On 17/05/16 14:26, Santosh Chokhani wrote:
>  But, this does not help the cross-certified environment.

Is that environment of interest? Should we de-scope it in the proposed =
charter? Or if not, should it be limited to consideration for only the =
smime email application?

>From what I've heard so far, the only folks who seem to be planning =
implementations are interested in the WebPKI and in enterprise smime. Is =
that correct?

If in fact we have implementers who are planning to write code for =
something else, those implementers should say so before we're done with =
the charter.

We may save ourselves some extended debates if we can craft charter text =
to reflect the scope of the real work that folks want to do.



In any case, this mail thread has convinced me that we do need some more =
scoping text in the charter, perhaps to name a primary use-case for each =
of the work items and to say that wider (abstract, near theoretical) =
considerations of (the consequences of) the same work items are to be =
discouraged as we know from history that those discussions move =
glacially, are terribly distracting and have lead to worse outcomes in =
the past. Text suggestions welcome.

And to be clear, I will not be pushing the next button in the formal =
chartering process until we've tackled this issue, either adding text =
such as the above or convincing me that it's not needed. (And I fully =
admit to possibly having an overly-sensitive ocean-boiling-ahead =
detector
here;-)



Cheers,
S.



From nobody Wed May 18 05:38:04 2016
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 277C012D13D for ; Wed, 18 May 2016 05:38:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.127
X-Spam-Level: 
X-Spam-Status: No, score=-4.127 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OJaGyyFpGGLA for ; Wed, 18 May 2016 05:38:02 -0700 (PDT)
Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id 7215012D123 for ; Wed, 18 May 2016 05:38:01 -0700 (PDT)
Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id E68CA496C23; Wed, 18 May 2016 12:38:00 +0000 (GMT)
Received: from prod-mail-relay09.akamai.com (prod-mail-relay09.akamai.com [172.27.22.68]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id D0801496C1C; Wed, 18 May 2016 12:38:00 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1463575080; bh=9M4f0uRL6w2sMHrre2LJ/1qTYYBI+M7E2TjAfnQemcI=; l=343; h=From:To:Date:References:In-Reply-To:From; b=hmtqAmMmJe9FsNK6Krb0IYtKNGbywQQTgffpskfLrWUgkV8CVTQMiYo8mfpnccGtH svGwt3AI8IGTdkeKoMMuJZSGJjtp0XAA8iPIlzWstVIiR1slxrXz/WL00HkUkPGet6 PjnA5c6vn3sdvdkQ5l2qqtsS3kXGd2j0cI15K8xk=
Received: from email.msg.corp.akamai.com (usma1ex-cas3.msg.corp.akamai.com [172.27.123.32]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id B5C3F1E07C; Wed, 18 May 2016 12:38:00 +0000 (GMT)
Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Wed, 18 May 2016 08:38:00 -0400
Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1130.005; Wed, 18 May 2016 08:37:59 -0400
From: "Salz, Rich" 
To: Sean Leonard , "spasm@ietf.org" 
Thread-Topic: [Spasm] Technical & Editorial Quality Control in this WG: some ASN.1 points
Thread-Index: AQHRsJKDtQRzoZ/S0ka198WmxnAhpJ++okyA
Date: Wed, 18 May 2016 12:37:59 +0000
Message-ID: <0c4788ddd38340878b6b5dc2e669a3b1@usma1ex-dag1mb1.msg.corp.akamai.com>
References: 
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.41.43]
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: Re: [Spasm] Technical & Editorial Quality Control in this WG: some ASN.1 points
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 18 May 2016 12:38:03 -0000

Interesting thoughts.  Most seem reasonable -- but have we ever had an "off=
icial" source for *any* ASN.1?  And have we seen PKIX or SNMP interop error=
s because we didn't have one?

But I completely agree with Sean about the way forward on ASN.1

-- =20
Senior Architect, Akamai Technologies
IM: richsalz@jabber.at Twitter: RichSalz



From nobody Wed May 18 06:03:59 2016
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 7517E12D1E5 for ; Wed, 18 May 2016 06:03:57 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=redhoundsoftware-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 yFp3lkd2dhYR for ; Wed, 18 May 2016 06:03:56 -0700 (PDT)
Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EB5212D1E9 for ; Wed, 18 May 2016 06:03:23 -0700 (PDT)
Received: by mail-io0-x22f.google.com with SMTP id 190so63567555iow.1 for ; Wed, 18 May 2016 06:03:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhoundsoftware-com.20150623.gappssmtp.com; s=20150623; h=user-agent:date:subject:from:to:message-id:thread-topic:references :in-reply-to:mime-version:content-transfer-encoding; bh=gljvinzKPshupMOY90BqKVc/z7F6oVKxRtp5qkWwFG0=; b=0ISnG5wp8V7E6mQABgewKZYlWfhRaxmi6yp9Cx9hrVt3k9iQ8ocW7Op4B0LQejkA5h pIHoMJAoboVsLC8jWM0/mmrsOvme1/EKPoHd3fSrDjWwRlqLv1AEsWZ/EdSO/iCbTWf0 H2K9HWeEMvBOBOdsFXz728xPp5pv8PyXeaskzSlX0+pPaPk/wjH1nzLR9IY2uEx/Bbkt 8ARtjBpSKn0ZL2UWNrX32OCrlzg0Qef/9fVrp5u0f+3fmTEWKv1JLC5CVMhqv1TpZrzY pLfjE3GPEnOc0Ib9N4OBzRdh9UoB4obgw3coIW4XalwQ75CyTzU0sg81gjFKBVlgUujC zqmQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:user-agent:date:subject:from:to:message-id :thread-topic:references:in-reply-to:mime-version :content-transfer-encoding; bh=gljvinzKPshupMOY90BqKVc/z7F6oVKxRtp5qkWwFG0=; b=U8E8nx/vlfKTLXfa+OkGdmNam++DhtIL2jqpdC55wBtAyvXCv+JPulOXauohJg+/bO ch9ghqJ7cevLn+H3IMFbfpdopeSwwQ0atsaqsnLVtNiDB+YdCKu2MHSH+14G35+YWwo+ 0CSp9xOnF72XmLE4GhgSH6PsVLQ5ercFC088gyni+pt5kc7EAX8yjSc+4kMjUO9iruvV T/jBMClNTZaklIig1iKaNFj9WIoM4OK5XClN9hosNDkLPPoDK648qp38WHkqExQyok5C ShpDD+lon+tFk4RNn3PzUAJmteJYzD3m4m1NZPeN332jeZ/RtalVeRUM/aqKypB7pSD4 ISPA==
X-Gm-Message-State: AOPr4FX7504jxlZ5YURKUstYrirg3sYeelmGHM/N15lVjE5Tiw6tx3vAddVTj1g+toavbQ==
X-Received: by 10.36.110.205 with SMTP id w196mr5494172itc.47.1463576602578; Wed, 18 May 2016 06:03:22 -0700 (PDT)
Received: from [10.247.170.171] ([97.65.242.177]) by smtp.gmail.com with ESMTPSA id h204sm2511921ioh.13.2016.05.18.06.03.19 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 18 May 2016 06:03:21 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/14.5.8.151023
Date: Wed, 18 May 2016 09:03:14 -0400
From: Carl Wallace 
To: Stephen Farrell , Jim Schaad , 
Message-ID: 
Thread-Topic: [Spasm] more scoping is needed
References: <316ECF88-612A-4131-8A96-E5F76671929A@vigilsec.com> <044a01d1af10$1548b8c0$3fda2a40$@gmail.com>  <023a01d1b03f$b444c8d0$1cce5a70$@gmail.com> <573B2119.3060800@cs.tcd.ie>  <573B469D.7020603@cs.tcd.ie> <029301d1b05e$a0992320$e1cb6960$@augustcellars.com> <573B6696.30806@cs.tcd.ie>
In-Reply-To: <573B6696.30806@cs.tcd.ie>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: 7bit
Archived-At: 
Subject: Re: [Spasm] more scoping is needed
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 18 May 2016 13:03:57 -0000

On 5/17/16, 2:44 PM, "Spasm on behalf of Stephen Farrell"
 wrote:

>
>
>On 17/05/16 18:07, Jim Schaad wrote:
>> I can see two different types of statements coming from this:
>> 
>> 1.  We are not going to pick up any work which is not specific to
>> environments other than WebPKI and S/MIME.  (For some value of
>> WebPKI), and
>> 
>> 2. We are going to ignore any implications of our work which are not
>> in those two environments.
>> 
>> I am assuming you mean the first statement not the second in terms of
>> doing scoping.
>
>Not quite.
>
>I do sort of agree with #1. Or at least the work items identified so
>far seem to fit that description. (Hence my suggestion to tie any
>more precise scoping to the specific work items.)

If doing S/MIME, aren't some of the constraints pruned off for the WebPKI
applicable (i.e., some of what is used in the US Fed PKI)? There are a
fair number of certs issued to people hanging off the "WebPKI" too.
Perhaps at a minimum we need a means of disallowing that practice entirely
if concerns related to S/MIME, etc. certs are to be shunted off elsewhere.





From nobody Wed May 18 06:09:08 2016
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 F3EF812D1C8 for ; Wed, 18 May 2016 06:09:05 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=redhoundsoftware-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 Aniqt-AJ5m1c for ; Wed, 18 May 2016 06:09:03 -0700 (PDT)
Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::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 C340D12D148 for ; Wed, 18 May 2016 06:09:02 -0700 (PDT)
Received: by mail-io0-x236.google.com with SMTP id d62so63811360iof.2 for ; Wed, 18 May 2016 06:09:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhoundsoftware-com.20150623.gappssmtp.com; s=20150623; h=user-agent:date:subject:from:to:message-id:thread-topic:references :in-reply-to:mime-version:content-transfer-encoding; bh=kIHjhTI3fvYIC3k1llCXUgAlvqpsJfCLudMfQH4jXUo=; b=QIhTfcuU1m4W11cJgOzGGYbF2PcLoRktXjO+kZyuGpKX1733hjMRiHBWG3Ia2QQqJ5 7lGyNW6EM3wc7Y1nBBARC0MiRMeCOt7roXBLRmNMMG7i+nif+YoOu76CxrnjpbHk/YIw dWebtWwqzO4gnlXlfxSy6uqNLL5LHjCcYLyqOAmWDDw+a7zhD9MFeWjmGRAOzVL022q2 VlrzCfek0P8ALEDauURbiCdNUeV3uo9Iq5Ab8fkfEdz8XcL6ppz0jm+/31o9joh6HYLt oHCYxVSkVZ0gfFnpNG2cdcpySx2EgdBrjqCNyHsuZKOTsr+amN+P1ggOuYTdnpq43ZpP /yIA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:user-agent:date:subject:from:to:message-id :thread-topic:references:in-reply-to:mime-version :content-transfer-encoding; bh=kIHjhTI3fvYIC3k1llCXUgAlvqpsJfCLudMfQH4jXUo=; b=TLEUzAbWAF382neT1QYPun0UVwH2ESxDWObq0Mb4JazPCzaVNLGbH5kRNs8BJit19C BKGdF+6DQUBKFPopTO6MBZulfK6Yug6tBOecKCfDp/QKeLoULd5F2RcT0P+QjzQ66+H9 VF1CF2rB2T+yDVfevPeN0pdR3Kl8I1NlowbAqbEnSzOPOawpb+ePpio/l0un19qagBXa Fq2M2zzQtju11sh4SnnwfquRD1fyBzVJVUP+JPm8BDXOMwEVHR599qGI+kZXaqXXVTOD DVvX7QmQehJoicz/hzovJxyw/r4QU8pwm8gD3e9b22QDzT/KeTcC2w/PKGaVP9XfmbXb 3x9Q==
X-Gm-Message-State: AOPr4FUwotStaqAvkNg8Oh0eaMIjJ6wVdaOIFOQw+3HwgZHfZrxz6reH7nBh+1AcLi2tGw==
X-Received: by 10.36.20.206 with SMTP id 197mr4958678itg.24.1463576931991; Wed, 18 May 2016 06:08:51 -0700 (PDT)
Received: from [10.247.170.171] ([97.65.242.177]) by smtp.gmail.com with ESMTPSA id e6sm8805219ith.11.2016.05.18.06.08.47 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 18 May 2016 06:08:51 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/14.5.8.151023
Date: Wed, 18 May 2016 09:08:40 -0400
From: Carl Wallace 
To: Sean Leonard , 
Message-ID: 
Thread-Topic: [Spasm] Maybe just do permitted constraints only Re: My take on handling EKU constraints
References: <316ECF88-612A-4131-8A96-E5F76671929A@vigilsec.com> <044a01d1af10$1548b8c0$3fda2a40$@gmail.com> <000f01d1af31$5a760f80$0f622e80$@augustcellars.com> <054b01d1af78$d79e09d0$86da1d70$@gmail.com> <5739D2D5.8020809@cs.tcd.ie> <4e32597d-e1a1-d5b3-ca37-453b9a7e1c25@seantek.com>
In-Reply-To: <4e32597d-e1a1-d5b3-ca37-453b9a7e1c25@seantek.com>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: 7bit
Archived-At: 
Subject: Re: [Spasm] Maybe just do permitted constraints only Re: My take on handling EKU constraints
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 18 May 2016 13:09:06 -0000

On 5/17/16, 12:21 AM, "Spasm on behalf of Sean Leonard"
 wrote:

>On 5/16/2016 7:01 AM, Stephen Farrell wrote:
>> [...]
>> I hope we all agree that this kind of thing ought be mostly
>> driven by what those implementing or deploying certificate
>> validation and applications want and are willing to do and
>> what they think makes sense in terms of APIs etc. For example,
>> I wondered which application(s) you are involved in developing
>> you meant in the above.
>>
>> One thing I think we need to be quite careful about with all
>> of this planned work is to not repeat mistakes we (incl. me)
>> made in the past where we designed a bunch of PKI machinery
>> that didn't get used, or that made it harder to use PKI, or
>> that made PKI less useful.
>I really want to channel Stephen here on this point about avoiding
>making algorithms too complicated, that people won't use.

I thought part of the problem being addressed was aligning with how
implementers used EKU in ways different than 5280 defined. Are those
practices documented anywhere and do they align well with this I-D? If we
are defining a new EKU mechanism that does not align with the practices we
aren't much better off unless there is commitment by the implementers who
diverged from 5280 to adopt the new spec.

Sorry if this is a repeat question. This thread has many parts I've not
yet read.





From nobody Wed May 18 06:23:08 2016
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 9D89712B006 for ; Wed, 18 May 2016 06:23:06 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=redhoundsoftware-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 YVfzGJialyFP for ; Wed, 18 May 2016 06:23:04 -0700 (PDT)
Received: from mail-ig0-x242.google.com (mail-ig0-x242.google.com [IPv6:2607:f8b0:4001:c05::242]) (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 B8D5712D0BC for ; Wed, 18 May 2016 06:23:04 -0700 (PDT)
Received: by mail-ig0-x242.google.com with SMTP id c3so4590584igl.3 for ; Wed, 18 May 2016 06:23:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhoundsoftware-com.20150623.gappssmtp.com; s=20150623; h=user-agent:date:subject:from:to:message-id:thread-topic:references :in-reply-to:mime-version:content-transfer-encoding; bh=BPRLsSR1icVkJeY6QJuA/RYyfrDBybTXisD38ftl7ys=; b=gU67gGl1YsDiN8z8OuYiD08rdg/7/IUAwb3uBhi5e3fdYfSVbCkj0lIvZ7j1vszTHL 1/a2jDO/QWWNsg1+1SMTza0zH2bRbfyElok6OUlpJlzf8lz91ghI02dQs4505J29yKWM 9CRXD4WeDLW9AzJ8VO1wEzzboP/eOqsfzg1UJP+hOFphW3IcVOdi1x/VqGiYjErwkRMR xDDyB5q6lmCPQUT4Dni9Jx78YnvuCW1mzNhYxZUmAZ58/yL+JZFW9nJR35D0kVC0oTtV V7gVmfu6WttbXKIg2DopVJj3rSf72j4Tb4p27u0wrBW8NOSmYfZSaGOiS0pooc4lwXEt DEpw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:user-agent:date:subject:from:to:message-id :thread-topic:references:in-reply-to:mime-version :content-transfer-encoding; bh=BPRLsSR1icVkJeY6QJuA/RYyfrDBybTXisD38ftl7ys=; b=ARTJRvCaCzMuUekzzFjnWT6WjIPKUnfkPupuy5dp7pIzwcp50OsM4ftEIfE1d5D0UP ZQdpeNboq3CU1BUCWQG4F3MthX/rlLXZGmMdlN7id5Q6dOJDBRCXe++3C1hNh61LYQtP M5/SLTXqR3iiQXyMx6fZpcefPuuQFWk2ysFuOmaz6CKXAgSM8DYwAHFox0kimg19IXJf 1xb9QmcoL0vmvxDrbr2ag8RldYqvhfAqPi1sE89YjK5nDxs2TBWGJO/LL1RYEI2hs4hP XBkooA6YqykWvfGD9v1nMt0Jenfr9z3tdIbtyP7jgTW2R0+/79XAwn6bkFEvLzGYWiCL HxLw==
X-Gm-Message-State: AOPr4FXAJ1V2hQorf/eq0dufr8/pJIR6DtXDSbJ940XNCTlALIUcH1RL80zQZG2MYaUEWA==
X-Received: by 10.50.67.113 with SMTP id m17mr17704348igt.62.1463577783990; Wed, 18 May 2016 06:23:03 -0700 (PDT)
Received: from [10.247.170.171] ([97.65.242.177]) by smtp.gmail.com with ESMTPSA id k8sm2703325igv.10.2016.05.18.06.23.02 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 18 May 2016 06:23:03 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/14.5.8.151023
Date: Wed, 18 May 2016 09:22:59 -0400
From: Carl Wallace 
To: Sean Leonard , 
Message-ID: 
Thread-Topic: [Spasm] Technical & Editorial Quality Control in this WG: some ASN.1 points
References: 
In-Reply-To: 
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: 7bit
Archived-At: 
Subject: Re: [Spasm] Technical & Editorial Quality Control in this WG: some ASN.1 points
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 18 May 2016 13:23:06 -0000

On 5/17/16, 7:18 PM, "Spasm on behalf of Sean Leonard"
 wrote:

>I would like to propose a few ASN.1 points for this spasm WG to follow,
>to maintain a high level of Technical & Editorial Quality Control.

This seems like a good place to try something like this out. The utility
of it may not be great given the amount of legacy ASN.1 addressed here.

>
>These proposed points should be effective for final publications from
>this WG:
>
>Pick an ASN.1 standard to use as the normative reference. The current
>ITU-T standard in force is X.680: August 2015. We are no longer in the
>mid-90s, and there are at least a few widely-available, high-quality,
>open-source ASN.1 compiler tools that support the "new" syntax (new
>meaning, the syntax after 1988). If folks want or need 1988 syntax, then
>the 1988 syntax can be given in an informative (*not* normative) appendix.

This makes sense to me. There is an RFC to help with back porting to '88
anyway even if not included in the spec.

>
>Pick one of IMPLICIT, EXPLICIT, or AUTOMATIC for all WG output. (X.680
>recommends AUTOMATIC, but I am guessing there is an inherent bias
>towards IMPLICIT around these parts).

This is the only item here I disagree with slightly. I'd favor EXPLICIT
where tagging objects that are usually handled independently, I.e., tagged
certificates, CMS messages, etc.

>
>
>
>Each publication should have a normative ASN.1 module (if it uses ASN.1
>at all), which is submitted and maintained as a separate file with
>network (CRLF) line endings. The SHA-256 hash of the file should be
>included in the published RFC.

This could be handy for dependencies as well.

>
>Before publication, each ASN.1 module (along with all of its
>dependencies) must be successfully compiled and verified by two
>independent ASN.1 compiler implementations.

What does verified mean here? Successful interop via compilation is one
thing, successful interop via exchanging encoded values is another (and
more work to confirm).

>
>Comments, etc. welcome.

One addition might be requiring the inclusion of base64 encoded samples of
structures defined in the module. This might help avoid some boundary
issues where constraints or tagging are used.

>
>Regards,
>
>Sean
>
>_______________________________________________
>Spasm mailing list
>Spasm@ietf.org
>https://www.ietf.org/mailman/listinfo/spasm



From nobody Wed May 18 06:27:27 2016
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 EDD3112D11E for ; Wed, 18 May 2016 06:27:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gp0SSiwRjapE for ; Wed, 18 May 2016 06:27:24 -0700 (PDT)
Received: from mail-qg0-x232.google.com (mail-qg0-x232.google.com [IPv6:2607:f8b0:400d:c04::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 A763612B050 for ; Wed, 18 May 2016 06:27:24 -0700 (PDT)
Received: by mail-qg0-x232.google.com with SMTP id f74so25345653qge.2 for ; Wed, 18 May 2016 06:27:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=hBTz1178zNBRAseLfPVJtVzwcJ4naENJIWbe6x9OfzM=; b=WE9f02YVN5HIvQe9PXv+EM2i++RAJXOVpzcbs/PCWB8/UagMYTHiynhaSReeaa2lvy 60krAnlfGnNuy2g5Eep2ecayLnlVMRwBRunFzQ+1mNsKxWf9So17qH0fPjzfa3DRTO7E dvqhSwmfU1aWQIab1BpGnq1v7LhQYaBgq6huJGqqrGM6X7h/+907ELKARa7ZZ6PvsPky XUCDtCb/zDOiWo0zKbT3LJ1uYpTeUVdhLb1GdR6ONS0MQm3zKrrZYR3Z9ixqKdFIk4/F II0GwWucSe49Xg3Ud6RGiZ2t8O/qFNJD1BuHGoDBtkjnfio2BvXBp+BxhalcZU8PBZk5 Ws4A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=hBTz1178zNBRAseLfPVJtVzwcJ4naENJIWbe6x9OfzM=; b=cWGy3yDQM9VIy5MePsxyqzFt3qqCiJiirGGcyY3/Z4pF1iD6WbyzW/DXmg4KGNdiBU DPKAbkpZE8VrY72iSXLTWPy/Rii74Q3srmLuK23Dtkv2A4rSzMZ6quPGaMSWD4jOkXzj 1veMlX3pIrC2hmUPw6z95xO5qS3oxRtw07JcYNB4YpQoPLU/OlaLefP6PzEHWOG4Sc2c Yt0TtnbJlwe1Wh8Q2+oNDqbY+AWFgeotXxHeUlBxnktMEPv8NpY/X7g+NrlQQ04hxXe/ CkVGoiaxkbItvvtOkdmFW/GHWqIiwYQvwlYybMI+7n1z03s2c4W7l40v+SaefPCpAMw1 4L4g==
X-Gm-Message-State: AOPr4FVsuTysmuliJZ5PqLXgm/hDnkoD41+kUdZrdqI/PUfU7ay6cWGc4PGN9AvTIuNZCQ==
X-Received: by 10.140.93.164 with SMTP id d33mr7269607qge.13.1463578043823; Wed, 18 May 2016 06:27:23 -0700 (PDT)
Received: from SantoshBrain (pool-108-31-66-4.washdc.fios.verizon.net. [108.31.66.4]) by smtp.gmail.com with ESMTPSA id v66sm4160274qka.14.2016.05.18.06.27.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 18 May 2016 06:27:22 -0700 (PDT)
From: "Santosh Chokhani" 
To: "'Russ Housley'" 
References: <316ECF88-612A-4131-8A96-E5F76671929A@vigilsec.com> <044a01d1af10$1548b8c0$3fda2a40$@gmail.com>  <023a01d1b03f$b444c8d0$1cce5a70$@gmail.com> <6A59D772-815F-45A0-BB28-BE42149C44BD@vigilsec.com>
In-Reply-To: <6A59D772-815F-45A0-BB28-BE42149C44BD@vigilsec.com>
Date: Wed, 18 May 2016 09:27:21 -0400
Message-ID: <05d701d1b109$0252fc30$06f8f490$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQG9AVJW+Y7xpWAUdsUf0IIYfjAqNAGVztXGAdP+cJIB7kRbugJWSDvZn6qZb8A=
Content-Language: en-us
Archived-At: 
Cc: spasm@ietf.org
Subject: Re: [Spasm] Criticality of EKU constraints
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 18 May 2016 13:27:26 -0000

Hi Russ,

Your response related to criticality assertion.  My question is related to
processing and the quoted text in the I-D "Conforming applications MUST be
able to process this extension.  If
any CA certificate in the certification path includes an EKU constraints
extension that is marked as critical, and the end-entity certificate
includes an extended key usage certificate extension, then the application
MUST either process the EKU constraint or reject  the certificate."  

I wonder if this could be misconstrued what to do when the extension is not
marked critical since application that recognizes the extension MUST process
it regardless of criticality.  

-----Original Message-----
From: Russ Housley [mailto:housley@vigilsec.com] 
Sent: Tuesday, May 17, 2016 2:31 PM
To: Santosh Chokhani 
Cc: spasm@ietf.org
Subject: Criticality of EKU constraints

Santosh:

Breaking into two responses, each with a different subject line.

>> 2.  The language at the end of Section 2 regarding extension 
>> processing and tying it to criticality does not seem right to me.
>> Criticality of extension should not impact its processing  It also 
>> relates to my concerns regarding wrap up procedure in Section 3.  I 
>> would
> like the criticality part removed.
> 
> This seems like the same as comment 1.
> [Santosh] It is a bit different.  The I-D says "Conforming 
> applications MUST be able to process this extension.  If
>   any CA certificate in the certification path includes an EKU 
> constraints extension that is marked as critical, and the end-entity
>   certificate includes an extended key usage certificate extension,
>   then the application MUST either process the EKU constraint or reject
>   the certificate."  I would say even if the extension is marked 
> non-critical and end-entity certificate includes EKU, it needs to be 
> processed.  We do not generally change the processing semantics of an 
> extension due to criticality.  If what you are saying is that if the 
> end certificate does not include EKU and the application does not 
> understand the EKU constraints extension, it can be ignored.  But, 
> that is dangerous since the application will think the certificate is 
> good for all key purposes and the path is not.  Also, this will be 
> impacted by the decision on whether you choose input as Jim Schaad has 
> suggested.  In that scenario, the extension does need to be processed even
if the end certificate does not have EKU.

We have had this discussion over and over on the PKIX mail list.

RFC 5280 has set the precedent on criticality for an extension in a CA
certificate that impose restrictions on things that can appear in subsequent
certificates in the path:

   4.2.1.10.  Name Constraints

     Conforming CAs MUST mark this extension as critical .

   4.2.1.11.  Policy Constraints

      Conforming CAs MUST mark this extension as critical.

Russ



From nobody Wed May 18 06:38:26 2016
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 6F8A212D17C for ; Wed, 18 May 2016 06:38:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7BjdvkPHNFRQ for ; Wed, 18 May 2016 06:38:24 -0700 (PDT)
Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::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 09AAF12D174 for ; Wed, 18 May 2016 06:38:24 -0700 (PDT)
Received: by mail-qk0-x22e.google.com with SMTP id r184so26882531qkc.1 for ; Wed, 18 May 2016 06:38:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=6SGeH5/OOaowurs8RB6e7oJX36U1Hy5wF1DjOQIju2g=; b=AcqxNSh01dVAwgJ0/Mf5yrGOjCdvFMbBVDTad+s064HlVxWNJnuPhNultuEa0SqlFZ 5mbrV22aioIGz1oRfVl1pI0T6ZPRSGztXlUUZGLswZQvgWBsxTpJI7Z+SLnfgxM6tkeW zVzD1XSmT312lG/aRpsPhAfl4Niz2GDwlj5JqDAEVZqnpxZRLI+AnnXlHAM0aQ1AdQwL x9xqGScxfkRGfXBdaK2vfkVeHHfmuLZs+y8uVUX7va/gOFfcnxFD7z+CZpckcGKjx5LE hK1suNthTR7TS28hop/BwCDNUMd+qS2AOXithkbvs+ewkTB93uXcSXtfqixqR8F+EN7c wG+w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=6SGeH5/OOaowurs8RB6e7oJX36U1Hy5wF1DjOQIju2g=; b=W+ofXjBWFgRcxC3uSIk78H8U0ji3trZ0rAvsl7J/MfPMxV3JXz/FZKljNxLv4H95tq 9imE8PWDQrAyQ13rbHybIaOLKwNsd+CuVs5WHEMwJy+BlCXGju45uQxHe3P9NiH0x3Sr oQo4a3zL+bMUGdkA6riaNebOxsqrqiTUxNwnln5gWI9oAolIA8MRb/+bug0Y4Ve1LpVj o5bYrM5KgLG/A2ATRWJMcu/92iWWQjMPnq4oGcoATs9ZJyEA7B+coPKH2FSEpI6y9B2m petvIHWEnRXujCt13H8ydHPPlR6GzONlBsDYGuDK5LKfqIpimQix/lIwEwvGxXJUeV65 Oh/Q==
X-Gm-Message-State: AOPr4FXX8SIiI90IicwPKnsbJRfFOGdVRNxhnpG1MSsui1nHgaIxWxs/Hr5eRAclZ4zaOA==
X-Received: by 10.55.26.230 with SMTP id l99mr7015045qkh.187.1463578703086; Wed, 18 May 2016 06:38:23 -0700 (PDT)
Received: from SantoshBrain (pool-108-31-66-4.washdc.fios.verizon.net. [108.31.66.4]) by smtp.gmail.com with ESMTPSA id p143sm4178957qke.38.2016.05.18.06.38.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 18 May 2016 06:38:22 -0700 (PDT)
From: "Santosh Chokhani" 
To: "'Russ Housley'" 
References: <316ECF88-612A-4131-8A96-E5F76671929A@vigilsec.com> <044a01d1af10$1548b8c0$3fda2a40$@gmail.com>  <023a01d1b03f$b444c8d0$1cce5a70$@gmail.com> <63601411-2A87-43DD-8221-C22192E8F57D@vigilsec.com>
In-Reply-To: <63601411-2A87-43DD-8221-C22192E8F57D@vigilsec.com>
Date: Wed, 18 May 2016 09:38:21 -0400
Message-ID: <05e801d1b10a$8b993d00$a2cbb700$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQG9AVJW+Y7xpWAUdsUf0IIYfjAqNAGVztXGAdP+cJIB7kRbugFOme5On7Lal7A=
Content-Language: en-us
Archived-At: 
Cc: spasm@ietf.org
Subject: Re: [Spasm] Output from EKU constraints
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 18 May 2016 13:38:25 -0000

Hi Russ,

As I said to Steve in another thread, once the I-D identifies the objective
for path validation engine, we can determine if the proposed logic meets the
objective.

So I would like to know the objective/purpose.

In the meantime, can you confirm that I am reading and processing the I-D
correctly.  And that is, there is hard path validation failure if the any of
the EKU in the end certificate appears on the excluded end state and does
not appear on the permitted end state.

-----Original Message-----
From: Russ Housley [mailto:housley@vigilsec.com] 
Sent: Tuesday, May 17, 2016 3:18 PM
To: Santosh Chokhani 
Cc: spasm@ietf.org
Subject: Output from EKU constraints

Santosh:

Breaking into two responses, each with a different subject line.

>> 3.  Now to the wrap up procedure in Section 3, I would recommend 
>> taking an intersection of permitted EKU Constraint State and EKU in 
>> the end certificate and then deleting the EKUs in the result that are 
>> in the excluded EKU Constraint State.  Now, the resulting EKU set 
>> should be returned to the application for enforcement.  It is quite 
>> possible that some applications do not care about EKUs at all.  I 
>> could live with if the group decides if the resulting EKU set is 
>> null, it
> is a path validation failure.
>> But, my preference is for the application to enforce it.
> 
> As I said in my response to Jim, I was trying to not impact the API to 
> the certification path validation library.  This would be a significant
change.
> It would trim the set if key purpose ids in the end-entity certificate 
> to those that meet the restrictions.  It is easy to add to the 
> specification, but it is harder to get deployed in applications.
> [Santosh] The way the current logic is, if the path is not good for 
> all the EKUs in the end certificate, the path is invalid.  That may be 
> ok for Enterprise PKI and does reject mis-issued certificates assuming 
> the Enterprise PKI designer has done static analysis on EKU constraint 
> required at each stage.  But, this does not help the cross-certified
environment.
> Say one PKI wants to trust another for client authentication and 
> S/MIME, but not for Smart Card Logon.  The proposed approach will not 
> work unless the end certificate are issued for single key purpose.
> 
> [Santosh] The input approach suggested is less complicated that the 
> approach I suggest.  Under my approach, there is a possibility that 
> you will need to output a flag with the EKUs whether the list is 
> excluded or not since there is an edge case where only excluded get
accumulated.

Jim has suggested that it would be good to change Section 3.1 to provide an
input that gives a set of key purpose identifiers that are desired.

You suggested that it would be good to change Section 3.6 to provide an
output that provides a trimmed set of key purpose identifiers that are
authorized.

I understand the reason that these are desired.  My concern with these ideas
is that the API to the certification path library is impacted.  It seems to
me that we can meet the CAB Forum need without these.  I do not want to add
a hurdle to the deployment.


> What do others think?
> [Santosh] I have spoken as someone who designs lots of PKI stuff.  It 
> would be nice to hear from those who implement path validation 
> libraries and develop PK enabled applications as to what they prefer.  
> The proposed approach of hard failure of a perfectly valid certificate 
> which is good for the key purpose the application desires is wrong.

Indeed.  Changing the API had a significant impact to both.

Russ

[1]


From nobody Wed May 18 06:47:49 2016
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 1F45B12D0BC for ; Wed, 18 May 2016 06:47:47 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=redhoundsoftware-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 ezlZVN9N06jF for ; Wed, 18 May 2016 06:47:45 -0700 (PDT)
Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A050812B050 for ; Wed, 18 May 2016 06:47:45 -0700 (PDT)
Received: by mail-io0-x231.google.com with SMTP id i75so65392686ioa.3 for ; Wed, 18 May 2016 06:47:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhoundsoftware-com.20150623.gappssmtp.com; s=20150623; h=user-agent:date:subject:from:to:message-id:thread-topic:references :in-reply-to:mime-version:content-transfer-encoding; bh=nehVertaHq2ht65Kyws73eKUez+xeBXWbjZO3ZVSyp4=; b=xOp36IuJYTRUj7BeJKovYjF+vB6GWEcOExhsV7EIWHYLJ1klR3P0NAcRqm9BPBwOTU UWvFQFQSjffjLMV5ryoL4Ow0Vh7ADjTjDDUzoePerabE5DvuXHKsjNkKzKaPy8qVUhG/ pi45vj+PDCqqvERcXUdVhOM6CHahMOkjr70xhH4U/1ahe24z2lPg43VeCzoZIXp40cXw 0oCbGwc7X9YhRFFqbOFsYI16bnkN9CDudelJt6jO6nUHLNQGodMPjSFrA49dmz9SvL+d 9IhtXVotyCmW6JbvzAlG6Tvjrddsd19A/t9/TErSE+NMb/nf8pJ56rXl+FxR8Q2qMPe+ EdoA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:user-agent:date:subject:from:to:message-id :thread-topic:references:in-reply-to:mime-version :content-transfer-encoding; bh=nehVertaHq2ht65Kyws73eKUez+xeBXWbjZO3ZVSyp4=; b=Nmn8X0XpO+AAiJ2I6v9qudK2L1vdXFhgUbkhaXA2U6yrp/upQN6VOHGoUI+xc+aPAV /b4PGR338qMHYe4T17JDKwEkafYQ/OJxeSOnynHtEVRAYm7+HLhTo7rmuxdU6ypCTHK3 6F+udNay3V6ENwnlGDND5GsiHhWRxCHroB9lTugST4C9jpJ9DvsnJbtyN78iKtRih8eJ C+Q+Jb5tBRyfalEKMC0K3vKi7SayQwYBHHYw3GOhbQi9lcWSO/bGZmdYqO6kx4O/Pf5/ PAUKXgM+myL5Hh9DLOTK0TVf/dQmGMEUA44kC+dtj1vrfwOzxfD7womCCd4hH49Yt2ZJ HmpQ==
X-Gm-Message-State: AOPr4FUjujfCZBIiXH2mYHQzRqG7ccTOBbm817jsX/6ftjPOz60RMSQYuekOPnQOzaAETw==
X-Received: by 10.36.20.136 with SMTP id 130mr18409780itg.66.1463579264776; Wed, 18 May 2016 06:47:44 -0700 (PDT)
Received: from [10.247.170.171] ([97.65.242.177]) by smtp.gmail.com with ESMTPSA id ft7sm6524355igc.10.2016.05.18.06.47.29 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 18 May 2016 06:47:43 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/14.5.8.151023
Date: Wed, 18 May 2016 09:47:17 -0400
From: Carl Wallace 
To: "Salz, Rich" , Stephen Farrell , "Brown, Wendy (10421)" , "spasm@ietf.org" 
Message-ID: 
Thread-Topic: [Spasm] more scoping is needed
References: <316ECF88-612A-4131-8A96-E5F76671929A@vigilsec.com> <044a01d1af10$1548b8c0$3fda2a40$@gmail.com>  <023a01d1b03f$b444c8d0$1cce5a70$@gmail.com> <573B2119.3060800@cs.tcd.ie>  <573B469D.7020603@cs.tcd.ie> <6eeeb40b90bf4b51868fc4edeef81bfa@usma1ex-dag1mb1.msg.corp.akamai.com>
In-Reply-To: <6eeeb40b90bf4b51868fc4edeef81bfa@usma1ex-dag1mb1.msg.corp.akamai.com>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: 7bit
Archived-At: 
Subject: Re: [Spasm] more scoping is needed
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 18 May 2016 13:47:47 -0000

On 5/17/16, 12:31 PM, "Spasm on behalf of Salz, Rich"
 wrote:

>
>> Having to consider all the complexity of the US Federal PKI when any
>>other
>> change is suggested sounds to me to be perilously close to the above,
>>so I
>> would welcome folks' suggested charter text on how we can handle that
>> conundrum.

A good deal of that complexity is working around implementer decisions and
difficulties applying constraints in the right places. The root problem is
poor constraint mechanisms.

>
>I think the FedPKI can find a WG within their org to profile the IETF
>stuff.

The "FedPKI" is also part of the "WebPKI". I suppose looking the other way
at the problems in that segment is one approach.

In any case, is it really a Fed PKI problem, or a user certificate
problem? If the latter, it's still an issue here for S/MIME. To cleanly
prune this off would require means of constraining Web PKI CAs to validate
web server certs only. Maybe the emerging EKU spec could constrain trust
anchors associated with web server certificate validation. We can't really
saw off one piece without constraining the other.

>
>Federated PKI's should be out of scope here.

"Federated" and "cross-certified" are ambiguous. It'd be better if the
extensions that you do not wish to support were simply listed.

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



From nobody Wed May 18 06:51:04 2016
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 2043312D167 for ; Wed, 18 May 2016 06:51:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oJldQocr2l4R for ; Wed, 18 May 2016 06:50:59 -0700 (PDT)
Received: from mail-qg0-x22f.google.com (mail-qg0-x22f.google.com [IPv6:2607:f8b0:400d:c04::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 EDBAE12D0BC for ; Wed, 18 May 2016 06:50:57 -0700 (PDT)
Received: by mail-qg0-x22f.google.com with SMTP id 90so25778169qgz.1 for ; Wed, 18 May 2016 06:50:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=pQ8uzMQ/IxV4p0GT5encLS/3XaVSsKUZV7icGURJcT4=; b=gWqoHy4h6KbBXpVA6+2j2S1irE704Y7lgpVB6AvCEb2yvhbOVUnq/GPjFHA5DQHSVk qzZB4kmUzqfdZnF6qMqOSgqxMGEivh2ZWtyhwHdcxiab8y3/2cMgGAhL88XWPQuYDl8L CMwdFYgDz/iJFVUBhE8ioFDhlqA6OunPhnoxXd7/aVe1n3Zq5pCNG2QQORm7y/vJorlM cRLwnBBM7aaHbgR/2ZZTD4bOJ7OVsYWkZDUTGbHgmbPqi64T7GgZa3c0a54d55VtbI8K OaJIjS1POUtJA9MH+HvxnMeRu8/ZawUXKwecO8mX5pvI+OYriA62gAKJ8jxeWbDkV39G eeew==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=pQ8uzMQ/IxV4p0GT5encLS/3XaVSsKUZV7icGURJcT4=; b=QhRsN595L9XjmwRB0FlVasSLPXGzLiv5qf7qGw/vsOraZHur9EyBsVpDnFwfACdOHe asrstBZlwn5YcwoCDWtMXMe0/O9x3tTG30TjqVDqLBS7bLORzGDe7AQhAKlf0mcQNn7J fECiLVlHu7plvgL1vOxaXvC2lfVVnb4WL28SrZC20PnNVpdaxNzb9BBIJI3occdQVcrD GVH4/kBKy+o2ROmPXK5LYjYGsGq23ccDoqEKUoLehu0rtAcMZ36GxJeE9c0SBpcUTzi2 ojrPh1i81hktseK2/l3aw4seLlY6m4rg1YZdd8VeAdsG3veLjNqISgwYYhc2r7vj0i0d h12g==
X-Gm-Message-State: AOPr4FUv8JR9HfPxg2FW3DsSSAJvxhlYqCK1hEhZ8In5V+kqjZkiKSo1hCJsW9PI+BJBCQ==
X-Received: by 10.140.18.197 with SMTP id 63mr7510920qgf.18.1463579457126; Wed, 18 May 2016 06:50:57 -0700 (PDT)
Received: from SantoshBrain (pool-108-31-66-4.washdc.fios.verizon.net. [108.31.66.4]) by smtp.gmail.com with ESMTPSA id e127sm4165667qkb.34.2016.05.18.06.50.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 18 May 2016 06:50:56 -0700 (PDT)
From: "Santosh Chokhani" 
To: "'Russ Housley'" 
References: <316ECF88-612A-4131-8A96-E5F76671929A@vigilsec.com> <044a01d1af10$1548b8c0$3fda2a40$@gmail.com> <045901d1af13$29d85d60$7d891820$@gmail.com> <045a01d1af14$8db12aa0$a9137fe0$@gmail.com>  <024b01d1b040$8b35a800$a1a0f800$@gmail.com> <3F2EEF9D-55D9-40E9-ABC4-7704270B67A5@vigilsec.com>
In-Reply-To: <3F2EEF9D-55D9-40E9-ABC4-7704270B67A5@vigilsec.com>
Date: Wed, 18 May 2016 09:50:55 -0400
Message-ID: <05e901d1b10c$4d00d880$e7028980$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQG9AVJW+Y7xpWAUdsUf0IIYfjAqNAGVztXGAdsLs7cCOQ7GXgJE2Q36Al7IphcB1Gda7p+HBLPQ
Content-Language: en-us
Archived-At: 
Cc: spasm@ietf.org
Subject: Re: [Spasm] My take on handling EKU constraints
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 18 May 2016 13:51:02 -0000

Hi Russ,

Thanks.  This incorporates my suggestion.

-----Original Message-----
From: Russ Housley [mailto:housley@vigilsec.com] 
Sent: Tuesday, May 17, 2016 3:34 PM
To: Santosh Chokhani 
Cc: spasm@ietf.org
Subject: Re: [Spasm] My take on handling EKU constraints

Santosh:

Okay.  I suggest:

   5.  Security Considerations

   When a CA includes the extended key usage constraints certificate
   extension for a subordinate CA, the OCSPSigning key purpose
   identifier SHOULD be included in the permittedKeyPurposeIds field to
   enable the issuance of delegated OCSP Responder certificates.

Russ


On May 17, 2016, at 9:32 AM, Santosh Chokhani 
wrote:

> Hi Russ,
> 
> I would add something to the effect "CAs asserting this extension 
> SHOULD consider including  OCSPSigning in permitted EKUs if the 
> downstream CAs may issue delegated OCSP Responder certificates"
> 
> -----Original Message-----
> From: Russ Housley [mailto:housley@vigilsec.com]
> Sent: Monday, May 16, 2016 5:17 PM
> To: Santosh Chokhani 
> Cc: spasm@ietf.org
> Subject: Re: [Spasm] My take on handling EKU constraints
> 
> Santosh:
> 
>> Some discussion of OCSPSigning EKU in permitted field to accommodate 
>> Delegated OCSP trust model will be useful.  May be in Security 
>> Considerations Section.
> 
> We could add a discussion about the consequences of a particular EKU 
> in the end-entity certificate, but I cannot see why that is needed 
> here.  You seem to be thinking about some specific concern, please say
more.
> 
> Russ
> 
> 



From nobody Wed May 18 06:51:13 2016
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 DA04C12D12B for ; Wed, 18 May 2016 06:51:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TCsT8dXDQupM for ; Wed, 18 May 2016 06:51:02 -0700 (PDT)
Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::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 D79F012D168 for ; Wed, 18 May 2016 06:50:58 -0700 (PDT)
Received: by mail-qk0-x22a.google.com with SMTP id r184so27115316qkc.1 for ; Wed, 18 May 2016 06:50:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=YaeQ0yy17iACBWJc5z1hzTCC6da7LhYmN5jmu6rIYB8=; b=E5HqmM2ocfcQkPgddJPeT5utSqAHU1cOuN7dQYIpa6uc97bFLoN6VhSXozfCtVdGXZ pGbZQSQh+8jnZOUz666T+H8WYa6meOV6DmJrj0QnegtnNHt3L1C3FAsgF57RP73ltiiF 7LID4oeK01e510DOBXrbJKX1jwwW0WnMR2ff3bt32cJxINBOy7YgiX5rICrlhRx8GgFo OmRoWb9fZEIASjx3bU8jFU1T9hfuQOgGgo7Jan0lOqnqrytmNJf4tAg87I6dFoqdtSp/ Pc1knD5U7SitwxvdD+4fUPG72wxvZiN1zaDvTbEt5BycM95Twhr2dj7wClVcU0lmr/9S K/8Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=YaeQ0yy17iACBWJc5z1hzTCC6da7LhYmN5jmu6rIYB8=; b=HR/gou+OgKGK/oxT2wt5ZNB1zWTr8QA5qRka/vODzZ25u42qsPQyYosmTmgAk9TrQj z8FxE7Kf4FEEO6MvHZ83inWSXdEBvC6NcOC2NVQx+CkJWWjhbqiVowN6Y/k9xu9acPJh KR/uvsRQzOuGtleZ7Y4Mv6E2ZaPO6QX2OzoUE5evVlWt4SnxZLvFfvMuX/zfAxKiua9C Vr9ylEruP8dVWbu5ak7QnmEuqrVL/wdNRagd311ZeHLVeUI8wgm4XoRNe0tdqymsjioq wovy2PRkmYHs5cGabNnkMVh3wPTjVxep/gXj7PsslB3mZVKhtDl15L9L6foYF0nvTZDq fSxA==
X-Gm-Message-State: AOPr4FWRaibcchcKaM44Tx6onbcdltklrtO5gZ0nom3aNI6u6dYb7pJmBIc7bzZlIXTTaA==
X-Received: by 10.55.158.18 with SMTP id h18mr7972450qke.58.1463579457962; Wed, 18 May 2016 06:50:57 -0700 (PDT)
Received: from SantoshBrain (pool-108-31-66-4.washdc.fios.verizon.net. [108.31.66.4]) by smtp.gmail.com with ESMTPSA id e127sm4165667qkb.34.2016.05.18.06.50.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 18 May 2016 06:50:57 -0700 (PDT)
From: "Santosh Chokhani" 
To: "'Russ Housley'" 
References: <316ECF88-612A-4131-8A96-E5F76671929A@vigilsec.com> <044a01d1af10$1548b8c0$3fda2a40$@gmail.com> <045901d1af13$29d85d60$7d891820$@gmail.com>  <024a01d1b040$1fd17030$5f745090$@gmail.com> <8702CEF5-F033-4D27-90BF-5D8446EE6BA8@vigilsec.com>
In-Reply-To: <8702CEF5-F033-4D27-90BF-5D8446EE6BA8@vigilsec.com>
Date: Wed, 18 May 2016 09:50:55 -0400
Message-ID: <05ea01d1b10c$4d952940$e8bf7bc0$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQG9AVJW+Y7xpWAUdsUf0IIYfjAqNAGVztXGAdsLs7cB0QyFIwFX/vYsAXb4rTufp4tr0A==
Content-Language: en-us
Archived-At: 
Cc: spasm@ietf.org
Subject: Re: [Spasm] My take on handling EKU constraints
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 18 May 2016 13:51:04 -0000

Hi Russ,

Thanks.  Adding this language satisfies my concern.

I suggest you revise the last sentence as follows to fix the grammar and
ensure that it appears in all the fields in the path.  " If the
   anyExtendedKeyUsage key purpose identifier appears in the extended
   key usage extension of the end-entity certificate, then the
   anyExtendedKeyUsage key purpose identifier MUST appear in all the
   permittedKeyPurposeIds fields of the CA certificates in the path."

-----Original Message-----
From: Russ Housley [mailto:housley@vigilsec.com] 
Sent: Tuesday, May 17, 2016 3:29 PM
To: Santosh Chokhani 
Cc: spasm@ietf.org
Subject: Re: [Spasm] My take on handling EKU constraints

Regarding anyExtendedKeyUsage, RFC 5280 says:

   If a CA includes extended key usages to satisfy such applications,
   but does not wish to restrict usages of the key, the CA can include
   the special KeyPurposeId anyExtendedKeyUsage in addition to the
   particular key purposes required by the applications.  Conforming CAs
   SHOULD NOT mark this extension as critical if the anyExtendedKeyUsage
   KeyPurposeId is present.  Applications that require the presence of a
   particular purpose MAY reject certificates that include the
   anyExtendedKeyUsage OID but not the particular OID expected for the
   application.

So, I propose:

   The special key purpose identifier anyExtendedKeyUsage is not treated
   differently than any other key purpose identifier in processing the
   constraints.  If the anyExtendedKeyUsage key purpose identifier
   matches an entry in the excludedKeyPurposeIds field, then the
   anyExtendedKeyUsage key purpose identifier MUST NOT appear in the
   extended key usage extension of the end-entity certificate.  If the
   anyExtendedKeyUsage key purpose identifier appears in the extended
   key usage extension of the end-entity certificate, then the
   anyExtendedKeyUsage key purpose identifier MUST in the
   permittedKeyPurposeIds field.

Russ

On May 17, 2016, at 9:29 AM, Santosh Chokhani 
wrote:

> Hi Russ,
> 
> Regardless, the path validation logic needs to handle anyExtendedKeyUsage.
> 
> anyExtendedKeyUsage appearing in permitted does not make sense since 
> the field can be simply omitted.
> 
> anyExtendedKeyUsag appearing in excluded may make sense if you want 
> the path to be not valid for any specific EKU.
> 
> -----Original Message-----
> From: Russ Housley [mailto:housley@vigilsec.com]
> Sent: Monday, May 16, 2016 5:14 PM
> To: Santosh Chokhani 
> Cc: spasm@ietf.org
> Subject: Re: [Spasm] My take on handling EKU constraints
> 
> Santosh:
> 
>> The I-D should address anyExtendedKeyUsage.  Either it should be 
>> prohibited from the permitted or excluded or the path validation 
>> engine should treat this value in either field as the UNIVERSAL set.
> 
> I'd prefer to treat anyPurpose just like every other OID as far as the 
> constraints are concerned.
> 
> 	If it is in the excluded set, then is cannot appear.
> 	If it is in the permitted set, then it can appear.
> 
> What do others think?
> 
> Russ
> 
> 
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm



From nobody Wed May 18 07:16:33 2016
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 7658512D50D for ; Wed, 18 May 2016 07:16:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.727
X-Spam-Level: 
X-Spam-Status: No, score=-5.727 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=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 HgUERLzu1WgL for ; Wed, 18 May 2016 07:15:58 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C79712D103 for ; Wed, 18 May 2016 07:15:58 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 10ECFBDF9; Wed, 18 May 2016 15:15:56 +0100 (IST)
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I_0T9Tb3lzcm; Wed, 18 May 2016 15:15:55 +0100 (IST)
Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 87F52BDCC; Wed, 18 May 2016 15:15:55 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1463580955; bh=vo7znTuHNlej0eon9yRJ/fDkyFc15VdU93+fUnkngT0=; h=Subject:To:References:From:Date:In-Reply-To:From; b=UQhv0W6PEku7KWaN/iSVC3L8macE5GN8F4f5qwB07Fi481ufRA+sg50OCgTzjc6T6 FRNjQXqduMmrBEIveSWq9TWjAZEmwJHMqa86rowYqs2oWrTYeRLNbGmQ6fDRcZT0pI 9cYr1hfleWHI6OrrHqO+LjeP9fR0D6v3uvlj8QIk=
To: Carl Wallace , "Salz, Rich" , "Brown, Wendy (10421)" , "spasm@ietf.org" 
References: <316ECF88-612A-4131-8A96-E5F76671929A@vigilsec.com> <044a01d1af10$1548b8c0$3fda2a40$@gmail.com>  <023a01d1b03f$b444c8d0$1cce5a70$@gmail.com> <573B2119.3060800@cs.tcd.ie>  <573B469D.7020603@cs.tcd.ie> <6eeeb40b90bf4b51868fc4edeef81bfa@usma1ex-dag1mb1.msg.corp.akamai.com> 
From: Stephen Farrell 
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <573C7919.7070909@cs.tcd.ie>
Date: Wed, 18 May 2016 15:15:53 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms030706000508050908000501"
Archived-At: 
Subject: Re: [Spasm] more scoping is needed
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 18 May 2016 14:16:01 -0000
X-List-Received-Date: Wed, 18 May 2016 14:16:01 -0000

This is a cryptographically signed message in MIME format.

--------------ms030706000508050908000501
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


Hi Carl,

On 18/05/16 14:47, Carl Wallace wrote:
>=20
>=20
> On 5/17/16, 12:31 PM, "Spasm on behalf of Salz, Rich"
>  wrote:
>=20
>>
>>> Having to consider all the complexity of the US Federal PKI when any
>>> other
>>> change is suggested sounds to me to be perilously close to the above,=

>>> so I
>>> would welcome folks' suggested charter text on how we can handle that=

>>> conundrum.
>=20
> A good deal of that complexity is working around implementer decisions =
and
> difficulties applying constraints in the right places. The root problem=
 is
> poor constraint mechanisms.

I have to say that the above is not helping me feel more
confident that this proposed working group will keep to a
limited scope with tightly focused discussions.

If people on this list prefer a broadly scoped working
group to consider many potential issues with PKI then
that's fine, but is not something that I'm interested in
sponsoring. If people prefer to get some specific and
concrete bits of work done in a tightly scoped WG then
I am interested in sponsoring that.

I think I've made my concerns sufficiently clear at this
point so I'll be looking forward to seeing proposed OLD/NEW
changes to the charter text [1] that aims to help us tighten
up the scope of the proposed WG and that the chairs can use
to keep discussions out of the weeds.

It seems that (particularly) item #2 in the proposed
charter text [1] is what's tripping us up in that respect
so possible changes might be a) delete that item or b) add
a sentence about the intended scope for that work. But if
someone has other scope-tightening things to suggest please
do so.

Cheers,
S.

PS: I'm not sure if its visible to others, but as an AD I see
a big red button labelled "Abandon charter" at [1] and I'm
just fine with hitting that if we can't resolve this issue.

[1] https://datatracker.ietf.org/doc/charter-ietf-spasm/

>=20
>>
>> I think the FedPKI can find a WG within their org to profile the IETF
>> stuff.
>=20
> The "FedPKI" is also part of the "WebPKI". I suppose looking the other =
way
> at the problems in that segment is one approach.
>=20
> In any case, is it really a Fed PKI problem, or a user certificate
> problem? If the latter, it's still an issue here for S/MIME. To cleanly=

> prune this off would require means of constraining Web PKI CAs to valid=
ate
> web server certs only. Maybe the emerging EKU spec could constrain trus=
t
> anchors associated with web server certificate validation. We can't rea=
lly
> saw off one piece without constraining the other.
>=20
>>
>> Federated PKI's should be out of scope here.
>=20
> "Federated" and "cross-certified" are ambiguous. It'd be better if the
> extensions that you do not wish to support were simply listed.
>=20
>> _______________________________________________
>> Spasm mailing list
>> Spasm@ietf.org
>> https://www.ietf.org/mailman/listinfo/spasm
>=20
>=20
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm
>=20


--------------ms030706000508050908000501
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
CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ
BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD
ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll
bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw
aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA
Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra
C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3
rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5
R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r
dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt
3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw
MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ
QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv
BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5
BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu
Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll
bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc
MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE
MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG
9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD
C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9
U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM
aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai
9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC
BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE
BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs
IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g
QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC
SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC
ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv
mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm
VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4
D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI
dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu
N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE
FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp
MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE
WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG
JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+
SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g
BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv
bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY
0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF
NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9
uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p
6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv
Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu
mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7
RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO
/ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN
JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM
MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG
A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0
Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA
oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA1MTgx
NDE1NTNaMC8GCSqGSIb3DQEJBDEiBCDZN+l5DZuQD4hfbn9531o8TpxZHxHS7OHTk1+BsQV3
ejBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN
AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC
AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw
IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB
nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD
VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq
hkiG9w0BAQEFAASCAQA4FyE0WclBN94CPlPIBBIWYcJcYj4KWt3MDg6elmApm2XayKG3+LB/
FSZkyKiPQ3UrLQCf9jUnoB4o64Iifl2CQotcfwgYyYkYaIPq1XnTrJbVP3AuQzq2dETEs0NL
Ukui6EmWqYYcTLRRPJy4h8nhN7YpQkRUMM8GpGGDc+re+4Nka1BUh5q291LKrdMaNQ0CirpI
QOrrOrc4cI/MKNvQJfr92kmNPgy1TJsQOsbzNZ6bhzl6Fdnvdi6KWOm/9ZyU7WmbO8QdFhEZ
sjkYhlzBsxjvsfGvtWV7Vni13SGmryTVPhKPojnzr8X+quRqNAuYZ5xTXWSgP9ks8wt2BTzw
AAAAAAAA
--------------ms030706000508050908000501--


From nobody Wed May 18 07:20:10 2016
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 C8B1712D4FD for ; Wed, 18 May 2016 07:20:09 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=redhoundsoftware-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 428vZH_WI12s for ; Wed, 18 May 2016 07:20:06 -0700 (PDT)
Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::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 E954A12D120 for ; Wed, 18 May 2016 07:20:05 -0700 (PDT)
Received: by mail-io0-x22a.google.com with SMTP id 190so66668105iow.1 for ; Wed, 18 May 2016 07:20:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhoundsoftware-com.20150623.gappssmtp.com; s=20150623; h=user-agent:date:subject:from:to:message-id:thread-topic:references :in-reply-to:mime-version; bh=hyVRYpZdqjRPZsKFWSYUJ3+0MhEkEBXpC32hb4yEaYE=; b=K/g9JN20MdhGeFDHI8gtu9chgauaUfAzWh0EKP2amAV1qif+b6WRakz+gMqRd4tI5o eTYai/A/fQ8/7NEBh3ok0irnsXHAf85BcS8cEcgIH+LOF0Btsn4CvkPDizGQ1NU1L0eR RounEbZiNra9jfYvRZAx8mM1lYFFXNHi2XgrzyR+Tb48c0vI6Y3eIFE8uQ83xkaRSQSe OtUfJa3p/Xt7GdsXTbEPM/ygNQkQgwO2mzFS/MCMbOnfKU8e5UBPn4woB0HwlM3tzNj8 gkiTRciyOTdbhFLvZzl0t0PRCfXVZQg2/hxOGLwyQmTmZv3nSxsm9l+0Jqr8R7sdRNyS 06wQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:user-agent:date:subject:from:to:message-id :thread-topic:references:in-reply-to:mime-version; bh=hyVRYpZdqjRPZsKFWSYUJ3+0MhEkEBXpC32hb4yEaYE=; b=WR+g0DRy3aG0MjDA1KvfkeXafc70lXOSuGxB6wXcjFKBOY8eKgbtRf5CUs2vCJuTWz hMklopK48c46GIH6Yi1O5kkwlfE5HiLyaAL8362WdZ8E4jaFLy9lixltSy30SXyOkb0c p+I8JdrhB9FS/3Qtzw4O9st9n2SUc2Os+tQYH01ikju7aTpT1545KI3Cu6V/SUVQVaK2 VAb9yREWx0mX/LXfG+01udFb1jZA4yDfmgxwBfg2bk1S2S06WhGXnNRuTExipNNZO9Er icAEOA0tuRl2t419kcnVgisxW0ff7htlr1EsrPOUBJmixpyQEKQH7JABDbIAvXU51qsx GJqQ==
X-Gm-Message-State: AOPr4FUby+bRrWkvJkdF98GmzmujgIP87NGxtxV/k7UoZ7Mt8UbjEFDyiS9n2z2Y0FJdrA==
X-Received: by 10.36.73.22 with SMTP id z22mr695100ita.88.1463581205221; Wed, 18 May 2016 07:20:05 -0700 (PDT)
Received: from [10.247.170.171] ([97.65.242.177]) by smtp.gmail.com with ESMTPSA id c200sm8905288itb.4.2016.05.18.07.20.01 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 18 May 2016 07:20:04 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/14.5.8.151023
Date: Wed, 18 May 2016 10:19:56 -0400
From: Carl Wallace 
To: Stephen Farrell , "Salz, Rich" , "Brown, Wendy (10421)" , "spasm@ietf.org" 
Message-ID: 
Thread-Topic: [Spasm] more scoping is needed
References: <316ECF88-612A-4131-8A96-E5F76671929A@vigilsec.com> <044a01d1af10$1548b8c0$3fda2a40$@gmail.com>  <023a01d1b03f$b444c8d0$1cce5a70$@gmail.com> <573B2119.3060800@cs.tcd.ie>  <573B469D.7020603@cs.tcd.ie> <6eeeb40b90bf4b51868fc4edeef81bfa@usma1ex-dag1mb1.msg.corp.akamai.com>  <573C7919.7070909@cs.tcd.ie>
In-Reply-To: <573C7919.7070909@cs.tcd.ie>
Mime-version: 1.0
Content-type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3546411596_2747607"
Archived-At: 
Subject: Re: [Spasm] more scoping is needed
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 18 May 2016 14:20:10 -0000

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3546411596_2747607
Content-type: text/plain;
	charset="UTF-8"
Content-transfer-encoding: 7bit



On 5/18/16, 10:15 AM, "Stephen Farrell"  wrote:

>
>Hi Carl,
>
>On 18/05/16 14:47, Carl Wallace wrote:
>> 
>> 
>> On 5/17/16, 12:31 PM, "Spasm on behalf of Salz, Rich"
>>  wrote:
>> 
>>>
>>>> Having to consider all the complexity of the US Federal PKI when any
>>>> other
>>>> change is suggested sounds to me to be perilously close to the above,
>>>> so I
>>>> would welcome folks' suggested charter text on how we can handle that
>>>> conundrum.
>> 
>> A good deal of that complexity is working around implementer decisions
>>and
>> difficulties applying constraints in the right places. The root problem
>>is
>> poor constraint mechanisms.
>
>I have to say that the above is not helping me feel more
>confident that this proposed working group will keep to a
>limited scope with tightly focused discussions.
>
>If people on this list prefer a broadly scoped working
>group to consider many potential issues with PKI then
>that's fine, but is not something that I'm interested in
>sponsoring. If people prefer to get some specific and
>concrete bits of work done in a tightly scoped WG then
>I am interested in sponsoring that.

Note, I am not suggesting a "broadly scoped working group", rather I am
suggesting that setting the user certificate problem aside should be done
with a mechanism that enforces this exclusion. 

--B_3546411596_2747607
Content-type: application/pkcs7-signature; name="smime.p7s"
Content-transfer-encoding: base64
Content-disposition: attachment;
	filename="smime.p7s"

MIIVBwYJKoZIhvcNAQcCoIIU+DCCFPQCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
Er8wggUIMIID8KADAgECAhBtxSMSIBneO0dgQwrDyYu+MA0GCSqGSIb3DQEBCwUAMHUxCzAJ
BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD
ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll
bnQgQ0EwHhcNMTYwMTA1MTE0NTMzWhcNMTcwMTA1MTE0NTMzWjBOMSIwIAYDVQQDDBljYXJs
QHJlZGhvdW5kc29mdHdhcmUuY29tMSgwJgYJKoZIhvcNAQkBFhljYXJsQHJlZGhvdW5kc29m
dHdhcmUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwleNXB8i3ajdsM+h
DgCkUb5d+YIj8m0nIQdG9YgenN7eBCba7jbrh9QZhJsoGuzDhRyScLT9hMHx28Zf7LgPX1+7
a/L8wlAnqKTBLysesgU7G6qF/PkXVkxZHzIKYmH8gNXBaYMAqaNAhP9ylDqVtyQOCZK1WqoR
tHDY3iy3daGG6h7U8IW9OY/GWHgV7gKyrhB615bBIOfXQI7C/L2DXeQ0+DnCDl7diMW8N1kQ
0iI0Zn8li5URYRjy7FkThOKakJohguAFa94688eLupTRvG/VYLaxZ2/Fcm4+JhI8Pev2fz5a
HvzBKwI//qdbl9Z73ZH/7xpsHfduxyTVggfoQwIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw
MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBT1
scZxfuKY+l6j5omP0Rud7rAuWjAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv
BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5
BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu
Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll
bnQxLmNybDAkBgNVHREEHTAbgRljYXJsQHJlZGhvdW5kc29mdHdhcmUuY29tMCMGA1UdEgQc
MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE
MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG
9w0BAQsFAAOCAQEAafQU72/jwGR0vjJqCPl9mnUOu4WyAB930Czhynwo+GQNSEGg2sEPMFEM
DnYQhcfZw2NFmA/vyDq8e5fBO26HFRQgb66gmhS4ldbj90XqtGIvwfTCXSyIdZ+TlxwEs2m1
YlMd6pj6zFtKUe5fIxAgGF7jFKYBJWbSJrfxSHaPMT6j68c1yvQScZLfHVlBR/VBD+wIHq14
9VdzZNuvW11QKK7Rnl0BhY+hyHxLeHLvN/MyqVF41McgqVIJj7/VDkQu16OPpwjP5NAiHwlv
NySIfS46Lze/DaFjLCoIfqm7hP+lWCedDKI/j8ytOL7H9MakuCPZ4CtNDlo8x4PY4Y7xZTCC
BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE
BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs
IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g
QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC
SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC
ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv
mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm
VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4
D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI
dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu
N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE
FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp
MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE
WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG
JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+
SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g
BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv
bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY
0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF
NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9
uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p
6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv
Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu
mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7
RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO
/ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN
JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MwggfJ
MIIFsaADAgECAgEBMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNjA5
MTcxOTQ2MzZaFw0zNjA5MTcxOTQ2MzZaMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy
dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5n
MSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTCCAiIwDQYJKoZI
hvcNAQEBBQADggIPADCCAgoCggIBAMGI2wm8bEZ8eJ+Ve7UzkPJyYtbBNiAiJF7O6XfyQwqi
BmSkzI42+DjmI/BubbE83XKjhRyh0z20MyvTL6/+6rBBWWe2xAZ9Cp50hdZ5TIA3et85BVJZ
9/QbRkOk0oWF0sNx83ViNLosin8ej+7tNNARx5bNUj26M9bdTd4LO0pLn8ImL/q1FhxyNXfK
PF3myuEmixo2dlwB23QUJf7ttaCID914yi0fB5cwAS1yefpG1hMqqLmmq4NJHeXy793kAY4Y
Co9jUxaFYqkOGTrMtWamwmt0B+Qr4XY+tG3Y9kThc2IfO8S+oFNWJWxRCfeqq8q/dv1tm/Od
2789ZrwMVqqvmEiVOkvfp1hQ2Th1qVvqQwwC/5nr6GxNcFspZZzdql3MrwEx7Azr0o3o6px7
5m73J2YMGkjXbkLjP94hPnvhDXD7Y6qobBpUtFwlesmiyYsWprssfhdeBU1YbhIdAe4SEA3G
Mn8Y//z0+s1ukeg2Sb4aSGmLwpZNGhKyaRfBCpDW+nkiSL+6e2n4cMf6ejfY2A3Sdk9X/5C3
45HS3e/CYLdnOt3+qpzw1It/ciLOxp+XtviviqAQqNn7GMa2tVxSPIm2GSpzAQoPA7MSYPJ6
L4Hbo27/JjCX9YvdiVe2rT2zryvFt3YC8KXWK5qGFCpy9uMzjF0JSxPfu4x0E1JLAgMBAAGj
ggJSMIICTjAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBrjAdBgNVHQ4EFgQUTgvvGqRAW6UX
aYcwyjRoQ9BBrvIwZAYDVR0fBF0wWzAsoCqgKIYmaHR0cDovL2NlcnQuc3RhcnRjb20ub3Jn
L3Nmc2NhLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRjb20ub3JnL3Nmc2NhLWNy
bC5jcmwwggFdBgNVHSAEggFUMIIBUDCCAUwGCysGAQQBgbU3AQEBMIIBOzAvBggrBgEFBQcC
ARYjaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0
dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9pbnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCB
wzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFydENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBM
aWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUg
U3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBo
dHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjARBglghkgBhvhCAQEEBAMCAAcw
OAYJYIZIAYb4QgENBCsWKVN0YXJ0Q29tIEZyZWUgU1NMIENlcnRpZmljYXRpb24gQXV0aG9y
aXR5MA0GCSqGSIb3DQEBBQUAA4ICAQAWbJn0Zgw09dCFXn0K7NoQTjgcXt+mJQVLkTLB6Dvx
Pd1ECVsHSYopy2YCt7Ga9yWYCTyOG+HdNocrS7to0zlmPaAmx/I5kR1Rq4J7ftXOWuTiA1dw
aZcI+V5YpgrfjAaaRRYWOApeV/Zix3oCBea8HrXynvSpKYP4shTjbiiHRMOQGt44qTysQ01k
Rc7dKKlc8nN7BPgX6Kux8y5cZG5zMToSuLyzEeR9j4FRmjuNifRNk2Z7PAPt05odmvNlUPWg
0HWfL6/w6oJDmPhpnIl5xEOORnLjZDYSr/clHjiJkHd+w2tqucPLREuseJCL58csHksRRMg0
UifNCl2fhcGJ1Rp48pUQUzLdgIRmddm1aCj7YS6+hKg4wJkShqUeZ2StBi4vqXCFx5YPfIll
9Y5DVA6r3aWAOZRgwDTJlnAsoxL1H0h7vRx+a7edkPQiO674/CrK+oJSoO+vS1WT68G18CKL
rDROJiIEoYcsdUq35X0T17gMZMA20skvhhKMIwnBG4I7c0mjaleHlOXWeMWZQ2PjTeB3LeFl
mXJpBBpHCeYPAVYk+x+/DnmpWC65xAkBfpW6bQAGPrLqShA52NAr9b/sdb+XAsUJGwjcVTfi
gfs3hENiIMrnVktl6v5swSSTJKE06wX/miKum30/8WVRCqYwarP0iByADfxyiuiDXjGCAhAw
ggIMAgEBMIGJMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYD
VQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRD
b20gQ2xhc3MgMSBDbGllbnQgQ0ECEG3FIxIgGd47R2BDCsPJi74wCQYFKw4DAhoFAKBdMCMG
CSqGSIb3DQEJBDEWBBToaEgrHowHuoj+jhFMYUj56QuTcTAYBgkqhkiG9w0BCQMxCwYJKoZI
hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA1MTgxNDE5NTZaMA0GCSqGSIb3DQEBAQUABIIB
ALbZvGeROWOM4IHwUYEx50y5uYq3J+SfcznV33pHV/QA6/bKMIC/sSVM6VmYLPvOujbmjGoG
Uwm8OI0ePfoF0y4pa2ASzD+ymCTMwzt6p9eEA/rsfScLIH49BahiHHBtZmxGNUc6hL022CeJ
mtb4tv2gBoJEnD2WetiYYe9ugo63MGyz122yLU+kOIE8fBYUG14Ya8LHKJ6ablB5EIM//RvY
wPngwyEuUHHXHammzL2PEH+lLHRB4BLqOEQP8odnqzvqPiiawAEB7ZBABwqEPYLZw0WPfAN2
peWiIGgKEdsqBQODoLIotrm1Fq1k5ddynCMxOpq1zZvLPPka8uxYwCw=

--B_3546411596_2747607--



From nobody Wed May 18 07:26:05 2016
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 3786312D509 for ; Wed, 18 May 2016 07:26:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Level: 
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2a7oPdbABvpa for ; Wed, 18 May 2016 07:26:02 -0700 (PDT)
Received: from mail.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id DC8DF12D506 for ; Wed, 18 May 2016 07:26:01 -0700 (PDT)
Received: from localhost (ronin.smetech.net [209.135.209.5]) by mail.smetech.net (Postfix) with ESMTP id 3B415F24035; Wed, 18 May 2016 10:26:01 -0400 (EDT)
X-Virus-Scanned: amavisd-new at smetech.net
Received: from mail.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id WS-n-pu5yicP; Wed, 18 May 2016 10:08:46 -0400 (EDT)
Received: from [10.189.68.248] (unknown [192.54.222.20]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.smetech.net (Postfix) with ESMTP id 258D7F2401F; Wed, 18 May 2016 10:23:55 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Russ Housley 
In-Reply-To: <05d701d1b109$0252fc30$06f8f490$@gmail.com>
Date: Wed, 18 May 2016 10:22:46 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <316ECF88-612A-4131-8A96-E5F76671929A@vigilsec.com> <044a01d1af10$1548b8c0$3fda2a40$@gmail.com>  <023a01d1b03f$b444c8d0$1cce5a70$@gmail.com> <6A59D772-815F-45A0-BB28-BE42149C44BD@vigilsec.com> <05d701d1b109$0252fc30$06f8f490$@gmail.com>
To: Santosh Chokhani 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: 
Cc: spasm@ietf.org
Subject: Re: [Spasm] Criticality of EKU constraints
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 18 May 2016 14:26:04 -0000

Santosh:

Does this resolve your concern?

   Conforming CAs MUST mark this extension as critical, and conforming
   CAs MUST NOT issue certificates where this extension is an empty
   sequence.  That is, at least one of the permittedKeyPurposeIds field
   or the excludedKeyPurposeIds field MUST be present.

   Conforming applications MUST be able to process this extension.  If
   any CA certificate in the certification path includes an extended key
   usage constraints extension and the end-entity certificate includes
   an extended key usage certificate extension, then the application
   MUST either process the extended key usage extension constraint or
   reject the certificate.

Russ


On May 18, 2016, at 9:27 AM, Santosh Chokhani =
 wrote:

> Hi Russ,
>=20
> Your response related to criticality assertion.  My question is =
related to
> processing and the quoted text in the I-D "Conforming applications =
MUST be
> able to process this extension.  If
> any CA certificate in the certification path includes an EKU =
constraints
> extension that is marked as critical, and the end-entity certificate
> includes an extended key usage certificate extension, then the =
application
> MUST either process the EKU constraint or reject  the certificate." =20=

>=20
> I wonder if this could be misconstrued what to do when the extension =
is not
> marked critical since application that recognizes the extension MUST =
process
> it regardless of criticality. =20
>=20
> -----Original Message-----
> From: Russ Housley [mailto:housley@vigilsec.com]=20
> Sent: Tuesday, May 17, 2016 2:31 PM
> To: Santosh Chokhani 
> Cc: spasm@ietf.org
> Subject: Criticality of EKU constraints
>=20
> Santosh:
>=20
> Breaking into two responses, each with a different subject line.
>=20
>>> 2.  The language at the end of Section 2 regarding extension=20
>>> processing and tying it to criticality does not seem right to me.
>>> Criticality of extension should not impact its processing  It also=20=

>>> relates to my concerns regarding wrap up procedure in Section 3.  I=20=

>>> would
>> like the criticality part removed.
>>=20
>> This seems like the same as comment 1.
>> [Santosh] It is a bit different.  The I-D says "Conforming=20
>> applications MUST be able to process this extension.  If
>>  any CA certificate in the certification path includes an EKU=20
>> constraints extension that is marked as critical, and the end-entity
>>  certificate includes an extended key usage certificate extension,
>>  then the application MUST either process the EKU constraint or =
reject
>>  the certificate."  I would say even if the extension is marked=20
>> non-critical and end-entity certificate includes EKU, it needs to be=20=

>> processed.  We do not generally change the processing semantics of an=20=

>> extension due to criticality.  If what you are saying is that if the=20=

>> end certificate does not include EKU and the application does not=20
>> understand the EKU constraints extension, it can be ignored.  But,=20
>> that is dangerous since the application will think the certificate is=20=

>> good for all key purposes and the path is not.  Also, this will be=20
>> impacted by the decision on whether you choose input as Jim Schaad =
has=20
>> suggested.  In that scenario, the extension does need to be processed =
even
> if the end certificate does not have EKU.
>=20
> We have had this discussion over and over on the PKIX mail list.
>=20
> RFC 5280 has set the precedent on criticality for an extension in a CA
> certificate that impose restrictions on things that can appear in =
subsequent
> certificates in the path:
>=20
>   4.2.1.10.  Name Constraints
>=20
>     Conforming CAs MUST mark this extension as critical .
>=20
>   4.2.1.11.  Policy Constraints
>=20
>      Conforming CAs MUST mark this extension as critical.
>=20
> Russ
>=20
>=20
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm


From nobody Wed May 18 07:34:58 2016
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 BA88E12D530 for ; Wed, 18 May 2016 07:34:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Level: 
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EkYJ-q6_3K-E for ; Wed, 18 May 2016 07:34:56 -0700 (PDT)
Received: from mail.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 0BF0F12D520 for ; Wed, 18 May 2016 07:34:56 -0700 (PDT)
Received: from localhost (ronin.smetech.net [209.135.209.5]) by mail.smetech.net (Postfix) with ESMTP id CDE5EF2401F; Wed, 18 May 2016 10:34:55 -0400 (EDT)
X-Virus-Scanned: amavisd-new at smetech.net
Received: from mail.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id i+G02ItONWdm; Wed, 18 May 2016 10:17:40 -0400 (EDT)
Received: from [10.189.52.232] (unknown [192.54.222.12]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.smetech.net (Postfix) with ESMTP id E5EA2F2402A; Wed, 18 May 2016 10:34:54 -0400 (EDT)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Russ Housley 
In-Reply-To: <05e801d1b10a$8b993d00$a2cbb700$@gmail.com>
Date: Wed, 18 May 2016 10:31:09 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <1CA94094-144C-42B7-879A-D9213C36214C@vigilsec.com>
References: <316ECF88-612A-4131-8A96-E5F76671929A@vigilsec.com> <044a01d1af10$1548b8c0$3fda2a40$@gmail.com>  <023a01d1b03f$b444c8d0$1cce5a70$@gmail.com> <63601411-2A87-43DD-8221-C22192E8F57D@vigilsec.com> <05e801d1b10a$8b993d00$a2cbb700$@gmail.com>
To: Santosh Chokhani 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: 
Cc: spasm@ietf.org
Subject: Re: [Spasm] Output from EKU constraints
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 18 May 2016 14:34:57 -0000

Santosh:

Please see this message in the PKIX mail list archive:
https://mailarchive.ietf.org/arch/msg/pkix/MHwcSWuuzezj4qHuzSmbYeGUbdI

In my view, the technical solution that puts the EKU certificate =
extension in the intermediate CA certificate was not the best technical =
solution.  I=92m proposing an alternative technical solution to the =
situation.

Russ



> Hi Russ,
>=20
> As I said to Steve in another thread, once the I-D identifies the =
objective
> for path validation engine, we can determine if the proposed logic =
meets the
> objective.
>=20
> So I would like to know the objective/purpose.
>=20
> In the meantime, can you confirm that I am reading and processing the =
I-D
> correctly.  And that is, there is hard path validation failure if the =
any of
> the EKU in the end certificate appears on the excluded end state and =
does
> not appear on the permitted end state.
>=20
> -----Original Message-----
> From: Russ Housley [mailto:housley@vigilsec.com]=20
> Sent: Tuesday, May 17, 2016 3:18 PM
> To: Santosh Chokhani 
> Cc: spasm@ietf.org
> Subject: Output from EKU constraints
>=20
> Santosh:
>=20
> Breaking into two responses, each with a different subject line.
>=20
>>> 3.  Now to the wrap up procedure in Section 3, I would recommend=20
>>> taking an intersection of permitted EKU Constraint State and EKU in=20=

>>> the end certificate and then deleting the EKUs in the result that =
are=20
>>> in the excluded EKU Constraint State.  Now, the resulting EKU set=20
>>> should be returned to the application for enforcement.  It is quite=20=

>>> possible that some applications do not care about EKUs at all.  I=20
>>> could live with if the group decides if the resulting EKU set is=20
>>> null, it
>> is a path validation failure.
>>> But, my preference is for the application to enforce it.
>>=20
>> As I said in my response to Jim, I was trying to not impact the API =
to=20
>> the certification path validation library.  This would be a =
significant
> change.
>> It would trim the set if key purpose ids in the end-entity =
certificate=20
>> to those that meet the restrictions.  It is easy to add to the=20
>> specification, but it is harder to get deployed in applications.
>> [Santosh] The way the current logic is, if the path is not good for=20=

>> all the EKUs in the end certificate, the path is invalid.  That may =
be=20
>> ok for Enterprise PKI and does reject mis-issued certificates =
assuming=20
>> the Enterprise PKI designer has done static analysis on EKU =
constraint=20
>> required at each stage.  But, this does not help the cross-certified
> environment.
>> Say one PKI wants to trust another for client authentication and=20
>> S/MIME, but not for Smart Card Logon.  The proposed approach will not=20=

>> work unless the end certificate are issued for single key purpose.
>>=20
>> [Santosh] The input approach suggested is less complicated that the=20=

>> approach I suggest.  Under my approach, there is a possibility that=20=

>> you will need to output a flag with the EKUs whether the list is=20
>> excluded or not since there is an edge case where only excluded get
> accumulated.
>=20
> Jim has suggested that it would be good to change Section 3.1 to =
provide an
> input that gives a set of key purpose identifiers that are desired.
>=20
> You suggested that it would be good to change Section 3.6 to provide =
an
> output that provides a trimmed set of key purpose identifiers that are
> authorized.
>=20
> I understand the reason that these are desired.  My concern with these =
ideas
> is that the API to the certification path library is impacted.  It =
seems to
> me that we can meet the CAB Forum need without these.  I do not want =
to add
> a hurdle to the deployment.
>=20
>=20
>> What do others think?
>> [Santosh] I have spoken as someone who designs lots of PKI stuff.  It=20=

>> would be nice to hear from those who implement path validation=20
>> libraries and develop PK enabled applications as to what they prefer. =
=20
>> The proposed approach of hard failure of a perfectly valid =
certificate=20
>> which is good for the key purpose the application desires is wrong.
>=20
> Indeed.  Changing the API had a significant impact to both.
>=20
> Russ
>=20
> [1]
>=20
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm


From nobody Wed May 18 08:15:21 2016
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 46A8912D59F for ; Wed, 18 May 2016 08:15:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Level: 
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6M_qheLJdl4x for ; Wed, 18 May 2016 08:15:19 -0700 (PDT)
Received: from mail.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 0267912D59C for ; Wed, 18 May 2016 08:15:19 -0700 (PDT)
Received: from localhost (ronin.smetech.net [209.135.209.5]) by mail.smetech.net (Postfix) with ESMTP id 8EC81F24035; Wed, 18 May 2016 11:15:18 -0400 (EDT)
X-Virus-Scanned: amavisd-new at smetech.net
Received: from mail.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id nvpVzoWM8UkD; Wed, 18 May 2016 10:57:53 -0400 (EDT)
Received: from [10.189.52.232] (unknown [192.54.222.12]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.smetech.net (Postfix) with ESMTP id BD4C7F2401F; Wed, 18 May 2016 11:15:07 -0400 (EDT)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Russ Housley 
In-Reply-To: <05ea01d1b10c$4d952940$e8bf7bc0$@gmail.com>
Date: Wed, 18 May 2016 11:14:44 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <7EB8B5C6-45F1-4687-8262-279FC8C0A20E@vigilsec.com>
References: <316ECF88-612A-4131-8A96-E5F76671929A@vigilsec.com> <044a01d1af10$1548b8c0$3fda2a40$@gmail.com> <045901d1af13$29d85d60$7d891820$@gmail.com>  <024a01d1b040$1fd17030$5f745090$@gmail.com> <8702CEF5-F033-4D27-90BF-5D8446EE6BA8@vigilsec.com> <05ea01d1b10c$4d952940$e8bf7bc0$@gmail.com>
To: Santosh Chokhani 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: 
Cc: spasm@ietf.org
Subject: Re: [Spasm] My take on handling EKU constraints
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 18 May 2016 15:15:20 -0000

Santosh:

> Thanks.  Adding this language satisfies my concern.
>=20
> I suggest you revise the last sentence as follows to fix the grammar =
and
> ensure that it appears in all the fields in the path.  " If the
>   anyExtendedKeyUsage key purpose identifier appears in the extended
>   key usage extension of the end-entity certificate, then the
>   anyExtendedKeyUsage key purpose identifier MUST appear in all the
>   permittedKeyPurposeIds fields of the CA certificates in the path."

I=92ll check the grammar, but your proposed text is not correct.  Upon =
reflection, the text I proposed is not right either.

The permitted_key_purpose_ids state variable starts with the universal =
set.  Then, as each certificate in the path is processed, the =
permittedKeyPurposeIds, when it is present, reduces the entries in the =
permitted_key_purpose_ids state variable.  It is assigned the =
intersection.  So, when the permittedKeyPurposeIds field is absent, the =
set is not reduced.  In fact, if the permittedKeyPurposeIds field never =
appears, it remains the universal set.

I suggest a re-write of several paragraphs in Section 2:

   Restrictions are defined in terms of permitted or excluded key
   purpose identifiers.

   The permitted key purpose identifiers begins with the universal set.
   Then, as each certificate in the certification path is processed, the
   permitted key purpose identifiers are reduced to the intersection of
   the previous set and the ones listed in the permittedKeyPurposeIds
   field.  Finally, each key purpose identifier in the extended key
   usage extension of the end-entity certificate MUST appear in the
   permitted key purpose identifiers set.

   The excluded key purpose identifiers begins with the empty set.
   Then, as each certificate in the certification path is processed, the
   excluded key purpose identifiers are increased to the union of the
   previous set and the ones listed in the excludedKeyPurposeIds field.
   Finally, each key purpose identifier in the extended key usage
   extension of the end-entity certificate MUST NOT appear in the
   excluded key purpose identifiers set.

   The special key purpose identifier anyExtendedKeyUsage is not treated
   differently than any other key purpose identifier in processing the
   constraints.  If the anyExtendedKeyUsage key purpose identifier
   appears in the extended key usage extension of the end-entity
   certificate, then the anyExtendedKeyUsage key purpose identifier MUST
   appear in the permitted key purpose identifiers set and the
   anyExtendedKeyUsage key purpose identifier MUST NOT appear in the
   excluded key purpose identifiers set.

Russ


From nobody Wed May 18 10:23:24 2016
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 2AE7D12D5FD for ; Wed, 18 May 2016 10:23:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Level: 
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sLKSzsrQU5ZF for ; Wed, 18 May 2016 10:23:21 -0700 (PDT)
Received: from mail.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 7068512D5F8 for ; Wed, 18 May 2016 10:23:21 -0700 (PDT)
Received: from localhost (ronin.smetech.net [209.135.209.5]) by mail.smetech.net (Postfix) with ESMTP id C5870F24041 for ; Wed, 18 May 2016 13:23:20 -0400 (EDT)
X-Virus-Scanned: amavisd-new at smetech.net
Received: from mail.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id jQIbCms2nt7E for ; Wed, 18 May 2016 13:06:05 -0400 (EDT)
Received: from [10.189.52.232] (unknown [192.54.222.12]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.smetech.net (Postfix) with ESMTP id 6404CF2401F for ; Wed, 18 May 2016 13:23:20 -0400 (EDT)
From: Russ Housley 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Wed, 18 May 2016 13:22:57 -0400
References: <20160518171802.14749.72841.idtracker@ietfa.amsl.com>
To: spasm@ietf.org
Message-Id: 
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
X-Mailer: Apple Mail (2.1878.6)
Archived-At: 
Subject: [Spasm] draft-housley-spasm-eku-constraints-01.txt
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 18 May 2016 17:23:23 -0000

There have been many changes discussed over the past few days.  There =
have not been any comments for a few hours, so I have collected them =
into -01.

> Name:		draft-housley-spasm-eku-constraints
> Revision:	01
> Title:		Extended Key Usage Constraints
> Document date:	2016-05-17
> Group:		Individual Submission
> Pages:		8
> URL:            =
https://www.ietf.org/internet-drafts/draft-housley-spasm-eku-constraints-0=
1.txt
> Status:         =
https://datatracker.ietf.org/doc/draft-housley-spasm-eku-constraints/
> Htmlized:       =
https://tools.ietf.org/html/draft-housley-spasm-eku-constraints-01
> Diff:           =
https://www.ietf.org/rfcdiff?url2=3Ddraft-housley-spasm-eku-constraints-01=

>=20
> Abstract:
>   This document specifies the extended key usage constraints
>   certificate extension, which is used to place restrictions on the =
key
>   purpose identifiers that are authorized to appear in the end-entity
>   certificate in a certification path.  Restrictions apply to the
>   extended key usage certificate extension, which is described in
>   RFC 5280.

As always, review and comments are most welcome.

Russ


From nobody Wed May 18 10:25:05 2016
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 91FA712D605 for ; Wed, 18 May 2016 10:25:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.386
X-Spam-Level: 
X-Spam-Status: No, score=-100.386 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_RHS_DOB=1.514, USER_IN_WHITELIST=-100] 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 S7Ke4NLPMQ7R for ; Wed, 18 May 2016 10:25:02 -0700 (PDT)
Received: from mail.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id C8DF112D604 for ; Wed, 18 May 2016 10:25:02 -0700 (PDT)
Received: from localhost (ronin.smetech.net [209.135.209.5]) by mail.smetech.net (Postfix) with ESMTP id 91222F2404B; Wed, 18 May 2016 13:25:02 -0400 (EDT)
X-Virus-Scanned: amavisd-new at smetech.net
Received: from mail.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id poRKavu1o+iM; Wed, 18 May 2016 13:07:47 -0400 (EDT)
Received: from [10.189.52.232] (unknown [192.54.222.12]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.smetech.net (Postfix) with ESMTP id 1A36FF2401F; Wed, 18 May 2016 13:25:02 -0400 (EDT)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Russ Housley 
In-Reply-To: <57E568BE-5FE4-4666-817B-696DE95883D0@sn3rd.com>
Date: Wed, 18 May 2016 13:24:39 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <7E03CCDB-CB14-4C5A-B905-3D805B50D155@vigilsec.com>
References:  <57E568BE-5FE4-4666-817B-696DE95883D0@sn3rd.com>
To: Sean Turner 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: 
Cc: spasm@ietf.org
Subject: Re: [Spasm] Technical & Editorial Quality Control in this WG: some ASN.1 points
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 18 May 2016 17:25:03 -0000

I included an ASN.1 module in the -01 version.  It uses the newer =
syntax.

Russ


On May 17, 2016, at 8:27 PM, Sean Turner  wrote:

> On May 17, 2016, at 19:18, Sean Leonard  wrote:
>>=20
>> Pick an ASN.1 standard to use as the normative reference. The current =
ITU-T standard in force is X.680: August 2015.
>=20
> We=92ve been down this road before :/
>=20
> RFC 5280 is =9288 so we=92re kinda stuck with that as the normative =
module.
>=20
> We published =9102 ASN.1 for PKIX in RFC 5912.  Some updates were also =
published in RFC 6268 and that used the =9208 syntax profiled back to =
the =9202 version.  I hope we can just do what we did for RFC 6268 for =
the alternate module.
>=20
> spt


From nobody Wed May 18 14:11:02 2016
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 C056212D6A8 for ; Wed, 18 May 2016 14:11:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-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 a5WqNWllrCIa for ; Wed, 18 May 2016 14:10:59 -0700 (PDT)
Received: from smtp.outgoing.loopia.se (smtp.outgoing.loopia.se [194.9.95.112]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2190712D746 for ; Wed, 18 May 2016 14:10:58 -0700 (PDT)
Received: from s554.loopia.se (localhost [127.0.0.1]) by s554.loopia.se (Postfix) with ESMTP id 6F3E017A60F8 for ; Wed, 18 May 2016 23:10:56 +0200 (CEST)
X-Loopia-Auth: user
X-Loopia-Originating-IP: 90.229.17.25
X-Loopia-User: stefan@fiddler.nu
Received: from s498.loopia.se (unknown [172.21.200.96]) by s554.loopia.se (Postfix) with ESMTP id 39F3E95DDAA; Wed, 18 May 2016 23:10:56 +0200 (CEST)
Received: from s405.loopia.se (unknown [172.21.200.105]) by s498.loopia.se (Postfix) with ESMTP id 3697E45E745; Wed, 18 May 2016 23:10:56 +0200 (CEST)
X-Virus-Scanned: amavisd-new at amavis.loopia.se
Received: from s498.loopia.se ([172.21.200.105]) by s405.loopia.se (s405.loopia.se [172.21.200.135]) (amavisd-new, port 10024) with LMTP id KHyRz9fIJ9UF; Wed, 18 May 2016 23:10:55 +0200 (CEST)
Received: from [10.0.1.51] (unknown [90.229.17.25]) (Authenticated sender: stefan@fiddler.nu) by s498.loopia.se (Postfix) with ESMTPSA id 13E7B45E722; Wed, 18 May 2016 23:10:55 +0200 (CEST)
User-Agent: Microsoft-MacOutlook/f.16.0.160506
Date: Wed, 18 May 2016 23:10:54 +0200
From: Stefan Santesson 
To: Russ Housley , 
Message-Id: <4A0C6BB6-D5F8-47A0-B392-AEBC0859C1FC@aaa-sec.com>
Thread-Topic: [Spasm] draft-housley-spasm-eku-constraints-01.txt
References: <20160518171802.14749.72841.idtracker@ietfa.amsl.com> 
In-Reply-To: 
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [Spasm] draft-housley-spasm-eku-constraints-01.txt
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 18 May 2016 21:11:02 -0000

Russ,

Reading 01 my reflections are:

1) I don=E2=80=99t like that this extension MUST be critical. It=E2=80=99s a deployment=
 killer. Who can include it before all validation engines support it, and wh=
o will bother to support it when no one includes it?
2) This is too complex for my taste.

I know that everything in the draft makes sense, but it may just be a bit t=
oo complex to get implemented and used correctly.
Have anyone made a study on where this is needed, and in what situations?

I know from my Microsoft days that Microsoft had an internal processing of =
EKU in CA certs in order to limit which certs that could be used under which=
 root. Mainly for constraining code signing usage.
Microsoft attempted to solve the same type of issue at one stage by introdu=
cing application policies with exclude and include logic. It never got used.

Perhaps we just need an extension that has 1 bit in it. If set to 1 it mean=
s that EKUs in this CA certificate are constraining the allowed EKU:s in the=
 path.

I actually think that would do what I suspect is needed and would cause the=
 least impact on existing path validation engines.

/Stefan

On 18/05/16 19:22, "Spasm on behalf of Russ Housley"  wrote:

>There have been many changes discussed over the past few days.  There have=
 not been any comments for a few hours, so I have collected them into -01.
>
>> Name:		draft-housley-spasm-eku-constraints
>> Revision:	01
>> Title:		Extended Key Usage Constraints
>> Document date:	2016-05-17
>> Group:		Individual Submission
>> Pages:		8
>> URL:            https://www.ietf.org/internet-drafts/draft-housley-spasm=
-eku-constraints-01.txt
>> Status:         https://datatracker.ietf.org/doc/draft-housley-spasm-eku=
-constraints/
>> Htmlized:       https://tools.ietf.org/html/draft-housley-spasm-eku-cons=
traints-01
>> Diff:           https://www.ietf.org/rfcdiff?url2=3Ddraft-housley-spasm-ek=
u-constraints-01
>>=20
>> Abstract:
>>   This document specifies the extended key usage constraints
>>   certificate extension, which is used to place restrictions on the key
>>   purpose identifiers that are authorized to appear in the end-entity
>>   certificate in a certification path.  Restrictions apply to the
>>   extended key usage certificate extension, which is described in
>>   RFC 5280.
>
>As always, review and comments are most welcome.
>
>Russ
>
>_______________________________________________
>Spasm mailing list
>Spasm@ietf.org
>https://www.ietf.org/mailman/listinfo/spasm



From nobody Wed May 18 14:30:00 2016
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 185CC12D76C for ; Wed, 18 May 2016 14:29:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level: 
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, 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 p7Z8sPQghGLy for ; Wed, 18 May 2016 14:29:56 -0700 (PDT)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (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 7370712D764 for ; Wed, 18 May 2016 14:29:56 -0700 (PDT)
Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 3B7BD509B5; Wed, 18 May 2016 17:29:54 -0400 (EDT)
To: Carl Wallace , spasm@ietf.org
References:  
From: Sean Leonard 
Message-ID: 
Date: Wed, 18 May 2016 14:29:02 -0700
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [Spasm] Technical & Editorial Quality Control in this WG: some ASN.1 points
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 18 May 2016 21:29:59 -0000

Just a few points; mostly in agreement:

On 5/18/2016 6:22 AM, Carl Wallace wrote:
>
> On 5/17/16, 7:18 PM, "Spasm on behalf of Sean Leonard"
>  wrote:
>
>> I would like to propose a few ASN.1 points for this spasm WG to follow=
,
>> to maintain a high level of Technical & Editorial Quality Control.
> This seems like a good place to try something like this out. The utilit=
y
> of it may not be great given the amount of legacy ASN.1 addressed here.=

>
>> These proposed points should be effective for final publications from
>> this WG:
>>
>> Pick an ASN.1 standard to use as the normative reference. The current
>> ITU-T standard in force is X.680: August 2015. We are no longer in the=

>> mid-90s, and there are at least a few widely-available, high-quality,
>> open-source ASN.1 compiler tools that support the "new" syntax (new
>> meaning, the syntax after 1988). If folks want or need 1988 syntax, th=
en
>> the 1988 syntax can be given in an informative (*not* normative) appen=
dix.
> This makes sense to me. There is an RFC to help with back porting to '8=
8
> anyway even if not included in the spec.

What's that RFC that you're referring to?

>
>> Pick one of IMPLICIT, EXPLICIT, or AUTOMATIC for all WG output. (X.680=

>> recommends AUTOMATIC, but I am guessing there is an inherent bias
>> towards IMPLICIT around these parts).
> This is the only item here I disagree with slightly. I'd favor EXPLICIT=

> where tagging objects that are usually handled independently, I.e., tag=
ged
> certificates, CMS messages, etc.

My take is that AUTOMATIC--though recommended--makes it "non-obvious"=20
what actually the tags are going to be on-the-wire unless you really=20
know the ASN.1 rules in your head.

As for EXPLICIT vs. IMPLICIT: it's kind of a stylistic choice between=20
being verbose and being concise, by a few bytes per instance (an extra=20
tag, which is usually one byte, and an extra length specifier, which is=20
probably going to be the same number of bytes as the length tag for the=20
inner item--depends on the encased structure).

The thing however is that PKIX/CMS uses IMPLICIT quite a bit--for PKIX=20
it's literally like half/half, and for CMS, the whole thing is in an=20
IMPLICIT module (with a few EXPLICIT items as exceptions). Therefore,=20
the coders "have to support" IMPLICIT, and for developing and debugging, =

it's basically the same amount of cognitive overhead for engineers.

My take is that since IMPLICIT is necessary, we may as well stick with=20
it as the default. The better solution, however, would be to create=20
structures where the IMPLICIT/EXPLICIT distinction does not result in=20
significant divergence on the wire (this specifically applies to=20
primitive types, i.e., things that are not SET or SEQUENCE). What I mean =

is that, if confronted with a CHOICE of two strings and an integer, it=20
would be better to say: CHOICE { PrintableString, UTF8String, INTEGER }=20
than: CHOICE { [0] UTF8String, [1] UTF8String, [2] UTF8String }. (I.e.,=20
the types are naturally disambiguated with their "natural" tags.)=20
Alternatively, the underlying data could be expressed as SEQUENCE {=20
ENUMERATED, UTF8String } where the ENUMERATED says what kind of data is=20
in the UTF8String. It depends on the underlying data. In contrast,=20
CHOICE { [0] SEQUENCE {...}, [1] SEQUENCE {...}, [2] SEQUENCE OF INTEGER =

} is "all right" because SEQUENCE is always a constructed type.

>
>> 
>>
>> Each publication should have a normative ASN.1 module (if it uses ASN.=
1
>> at all), which is submitted and maintained as a separate file with
>> network (CRLF) line endings. The SHA-256 hash of the file should be
>> included in the published RFC.
> This could be handy for dependencies as well.
>
>> Before publication, each ASN.1 module (along with all of its
>> dependencies) must be successfully compiled and verified by two
>> independent ASN.1 compiler implementations.
> What does verified mean here? Successful interop via compilation is one=

> thing, successful interop via exchanging encoded values is another (and=

> more work to confirm).

When I wrote that, I was referring to successful compilation. I suppose=20
that exchanging encoded values would be nice/a "level 2" of=20
verification, but it was not my intent to go there when I wrote that.=20
Others are free to disagree.

>
>> Comments, etc. welcome.
> One addition might be requiring the inclusion of base64 encoded samples=
 of
> structures defined in the module. This might help avoid some boundary
> issues where constraints or tagging are used.

I agree with this. Since you wrote "samples" as plural, I suggest at=20
least one sample that is in the normal & expected range, and one sample=20
that is pathological but still technically in range. For example, if it=20
were a date-time, "normal" would be 2016-05-18; pathological would be=20
9999-12-31 (assuming that the spec, or the spec on which the spec=20
relies, says that 4-digit years up to 9999 are acceptable). If the spec=20
says nothing and the underlying spec says nothing, an appropriate=20
pathological case would be one that tests the boundaries further, such=20
as 3999999-12-31.

By the way: extreme examples of valid OIDs are in the 2.25. arc because=20
those represent 128-bit UUIDs. (See Kaminsky et. al., PKI Layer Cake,=20
2009 .)

Sean



From nobody Wed May 18 16:14:34 2016
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 9CF7F12D7B5 for ; Wed, 18 May 2016 16:14:33 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=redhoundsoftware-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 DFSez60KyGnZ for ; Wed, 18 May 2016 16:14:32 -0700 (PDT)
Received: from mail-qg0-x229.google.com (mail-qg0-x229.google.com [IPv6:2607:f8b0:400d:c04::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 EC32812D7B4 for ; Wed, 18 May 2016 16:14:31 -0700 (PDT)
Received: by mail-qg0-x229.google.com with SMTP id f92so34748069qgf.0 for ; Wed, 18 May 2016 16:14:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhoundsoftware-com.20150623.gappssmtp.com; s=20150623; h=user-agent:date:subject:from:to:message-id:thread-topic:references :in-reply-to:mime-version:content-transfer-encoding; bh=u5S6NDGwlOV00RjTnAffPrY4qLQ9Wd3J2AfTavRQQ68=; b=ACTIRbdbFwlM5vE3AIjppN68Mnmk2MGlYlDv9fUYHaoeSlfhF0pxWDAX/DyRChi1LS lOkpxmo8ecx7A7vyB+SdQsdJhOqJpzjmHrw1HVVSAuOKE3ET75SC9jeuskDL9v8PqgP9 f8IPKBnInCleYMr3xDBqOtTHufonHxEu/Ix7636ZHmKhZCQYnphMkLdPUV6OJW5dUSHu tEUxmT+s0qXo69w/j43VGwgsT6NjFgBPu6AmfXljIb3D8FAkLCGCeerDLEvaVCWFzWG/ ILTTSXQuHDhNVoOaOti1Yzss+jG6hUnOvEjiJ/9rLoHG0JJIaoD60d7aSM9EP1cG8Ihf fBVA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:user-agent:date:subject:from:to:message-id :thread-topic:references:in-reply-to:mime-version :content-transfer-encoding; bh=u5S6NDGwlOV00RjTnAffPrY4qLQ9Wd3J2AfTavRQQ68=; b=Ogb3iJaUZjDmMOUFCnsGtlZDtSOBrGNKdKWix1/r9MIZ/KXSQT2xNe5iKH5Bt2+3jb IXiG5nSp1A6/MMT2S4XEUSW2y1o4iDr0jwRwt5o7AwT37gVl6Ikp6u7FETMDx4Revbmj +Emy4yH1Yu2ydFGgE2uFbTlFK/qwVCtqY6EU5WAqCpA+s/iyTDRCjmkq1X8lIxogtbaJ XSOFGtBmqjCPdJ9c/lv/S/a2WJ0DL7CF7/KQ/kxJ6srOfKoP0a7D3GIrdFsULuKhEBFh QfZ0g5HDTJoXcXalW/oHJzNmS7s4revBLtiOSaTXAsDgeqhdXVGMytoBo+QP1Upz2vDb jYYA==
X-Gm-Message-State: AOPr4FUmoZ2+gNs2oO/MPOVghRQ3ZAgD6AmMOiHtusFFKmXRwtCKrIrfQrcnySUltPeV4w==
X-Received: by 10.140.232.137 with SMTP id d131mr11129800qhc.87.1463613271068;  Wed, 18 May 2016 16:14:31 -0700 (PDT)
Received: from [192.168.2.246] (pool-96-255-23-4.washdc.fios.verizon.net. [96.255.23.4]) by smtp.gmail.com with ESMTPSA id j88sm5344858qgf.7.2016.05.18.16.14.27 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 18 May 2016 16:14:30 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/14.5.8.151023
Date: Wed, 18 May 2016 19:14:20 -0400
From: Carl Wallace 
To: Sean Leonard , 
Message-ID: 
Thread-Topic: [Spasm] Technical & Editorial Quality Control in this WG: some ASN.1 points
References:   
In-Reply-To: 
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: 7bit
Archived-At: 
Subject: Re: [Spasm] Technical & Editorial Quality Control in this WG: some ASN.1 points
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 18 May 2016 23:14:33 -0000

>>>
>>>
>>>Pick an ASN.1 standard to use as the normative reference. The current
>>> ITU-T standard in force is X.680: August 2015. We are no longer in the
>>> mid-90s, and there are at least a few widely-available, high-quality,
>>> open-source ASN.1 compiler tools that support the "new" syntax (new
>>> meaning, the syntax after 1988). If folks want or need 1988 syntax,
>>>then
>>> the 1988 syntax can be given in an informative (*not* normative)
>>>appendix.
>> This makes sense to me. There is an RFC to help with back porting to '88
>> anyway even if not included in the spec.
>
>What's that RFC that you're referring to?

6025



From nobody Thu May 19 05:35:14 2016
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 52D7812DA36 for ; Thu, 19 May 2016 05:35:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Level: 
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HUjJDMflQ1zU for ; Thu, 19 May 2016 05:35:06 -0700 (PDT)
Received: from mail.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 0D69D12DA23 for ; Thu, 19 May 2016 05:35:06 -0700 (PDT)
Received: from localhost (ronin.smetech.net [209.135.209.5]) by mail.smetech.net (Postfix) with ESMTP id 5F807F24041 for ; Thu, 19 May 2016 08:35:05 -0400 (EDT)
X-Virus-Scanned: amavisd-new at smetech.net
Received: from mail.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id bAmGko2owJTY for ; Thu, 19 May 2016 08:17:36 -0400 (EDT)
Received: from [5.5.33.101] (vpn.snozzages.com [204.42.252.17]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.smetech.net (Postfix) with ESMTP id A946DF2401F for ; Thu, 19 May 2016 08:34:54 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Russ Housley 
In-Reply-To: 
Date: Thu, 19 May 2016 08:34:52 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <3E9BECC8-1668-42E8-B333-006A4DF45E76@vigilsec.com>
References: <20160518171802.14749.72841.idtracker@ietfa.amsl.com>   <743EBDC5-B406-40A4-921E-230F185EB5F5@vigilsec.com> 
To: spasm@ietf.org
X-Mailer: Apple Mail (2.1878.6)
Archived-At: 
Subject: Re: [Spasm] draft-housley-spasm-eku-constraints-01.txt
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 19 May 2016 12:35:13 -0000

In an off-list discussion, Santosh has suggested that Section 3.5 needs =
a additional check to deal with end-entity certificates that do not =
include an EKU extension.

He has suggested this text:

   (i)  If the EKU extension is absent from the end-entity certificate
        then confirm that the permitted_key_purpose_ids state variable
        is the universal set and the excluded_key_purpose_ids state
        variable is the empty set.  Otherwise, return a failure =
indication
       and an appropriate reason.

Thoughts?

Russ



From nobody Thu May 19 10:59:05 2016
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 B06AC12DB76 for ; Thu, 19 May 2016 10:59:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.126
X-Spam-Level: 
X-Spam-Status: No, score=-4.126 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, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 ThaTyGwIhcGm for ; Thu, 19 May 2016 10:59:02 -0700 (PDT)
Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::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 77AC612DB73 for ; Thu, 19 May 2016 10:59:02 -0700 (PDT)
Received: by mail-oi0-x230.google.com with SMTP id x19so141462983oix.2 for ; Thu, 19 May 2016 10:59:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=USsBMdF3wNegSRkCfzpXOHpPub4h/B5IOilE4WQMGz8=; b=do6/NvFVgVUEPCXE2/LVDtc+1IV/pJgWhAR9ff6AYNN593LJg+sGZoY6x5IontmP5w BehvYhTDiBuaMBOHiUSJZmg9wb4uAV9eaXVH1rCRMu8H4pjI3oKeqnG9j9N6fsg3HkR+ v6we2MQoAfaVEkDfkh+InyaDzTRrfKKzdJ6HZhT9Hcs1y7DcjVFj/kSpumcxM5xm7Ob8 +GciPiIlwrM8I82KWtkQtPnHa3TviDgqSYR+nAeAC250gN7LUVvoAou0MXZ+qyQvI/xg o7kbBjbh9dQpKL5r8sLbMdtHS5CvBL8+OKEBR6ZzPy/eegfoIuya9PLKDTKdSDpuWxPM Zq0Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=USsBMdF3wNegSRkCfzpXOHpPub4h/B5IOilE4WQMGz8=; b=Rce6CRmpzTY5lT3sjFEATGR72niJhoeugcAVYXRwKaha4trj7YC/JoXkyWuiAcxrDM SSuKqZ/6mX/dC29oIuzukox5qQ/Lsz97j+qaP6xVud11caKPrvLwYTaJ8FJru9pmQMl7 Q0eoBoxSOk/VvtbEnj+WOmKELx5IwaWMeP69WzyB8j2LqMCmICHuwZyWvYLx3JOWyJXy vLuWNQRIuOtzrrKP3nmWeT+ViN+8RvWsUhpI3zu++XbBVtCTML3S6RXT4f2JYoPqBCTn uQZonN3kIX7066rPh+XC4NL5PZBihgVR3U4mSqS4r2af5xjASmh7CrVoyqMCLw/rBUf/ lX7g==
X-Gm-Message-State: AOPr4FUcKh+EJj9jk8rEERTvJ4BwgtvEzUS7J5evB8nczRyMhwUqOJ+ydcK3pnq70h0j2EufUJUAC0cNGnvxge0E
X-Received: by 10.157.31.36 with SMTP id x33mr9655643otd.26.1463680741686; Thu, 19 May 2016 10:59:01 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.157.32.202 with HTTP; Thu, 19 May 2016 10:59:00 -0700 (PDT)
In-Reply-To: 
References: 
From: Wei Chuang 
Date: Thu, 19 May 2016 10:59:00 -0700
Message-ID: 
To: spasm@ietf.org
Content-Type: multipart/alternative; boundary=001a113e5896ac97ea053335ba5d
Archived-At: 
Subject: Re: [Spasm] Updating S/MIME handling of message/rfc822?
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 19 May 2016 17:59:05 -0000

--001a113e5896ac97ea053335ba5d
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

In case anyone is interested in this topic, I found this draft that
provides a better direction than what I had proposed.

https://tools.ietf.org/html/draft-melnikov-smime-header-signing-01

-Wei

On Fri, May 13, 2016 at 4:09 PM, Wei Chuang  wrote:

> Hi,
>
> I would like to propose that draft-schaad-rfc5751-bis-00 further specify
> handling message/rfc822 processing and specify how to merge message
> headers from
> decrypted/decoded non message/rfc822 types mime parts.  If we can clarify
> header
> processing this could provide significant improvement in privacy as
> revealing
> headers like subject can reveal a great deal about the content of the
> message
> and even metadata like date can be used with traffic analysis to reveal
> hidden
> recipients (Bcc).
>
> There already exists "Securing Header Fields" as experimental RFC7508.
> This
> proposes that certain message header fields are signed and verified, and
> optionally can replace or delete the field.  This provides a high degree of
> flexibility and one approach would be to standard track this.  But this RFC
> requires a fairly significant change to S/MIME / CMS processing steps, and
> there
> would be a deployed base that would find it difficult to interoperate with.
> Another more feasibile approach is to clarify RFC5751 message/rfc822
> language.
> Likely this can get most of the header hiding benefit with a smaller
> change to
> CMS processing.
>
> This proposes that if it is desirable to protect header integrity and
> privacy
> that message/rfc822 be used as specifed in RFC5280.  However this instead
> of
> presenting both the outer header (original) and the inner header
> (message/rfc822) part to the recipient, this proposes that when the CMS
> processing is done, the inner headers in message/rfc822 update the outer
> ones.
> If there is a conflict between the inner and outer, then the inner header
> replaces the outer ones.  Body content in message/rfc822 part replaces
> that of
> the parent as well.  Further there should a signed attribute that tells the
> recipient to protect header integrity and privacy upon reply or forwarding
> of
> the message.  There also should be a capability specified as well.  Before
> sending the message implementations would move these headers to the
> message/rfc822 part, leaving those header fields unspecified in the sent
> outer message header.
>
> Compliant implementations should protect at least these message headers:
>   Subject
>   Date
>   References
>   Message-ID
>   Keywords
>   Original-XXX
> This list is not meant to be exhaustive.  A complete list generated
> from (http://www.iana.org/assignments/message-headers/
> message-headers.xhtml) can
> be done at a later time.  This list also makes no attempt to hide transport
> artifacts like the trace headers as these are outside of the control of the
> sender and recipient, or the sender and recipient headers as these are
> needed by
> transport.  (Other much more heavy weight approaches are better suited to
> handle
> hiding those headers)
>
> thanks,
> -Wei
>

--001a113e5896ac97ea053335ba5d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


In case anyone is interested in this topic, I found this draft that provides a better direction than what I had proposed.

-Wei

On Fri, May 13, 2016 at 4:09 PM, Wei Chuang <weihaw@google.com> wrote:
Hi, 

I would like to propose that draft-schaad-rfc5751-bis-00 further specify
handling message/rfc822 processing and specify how to merge message headers from
decrypted/decoded non message/rfc822 types mime parts.  If we can clarify header
processing this could provide significant improvement in privacy as revealing
headers like subject can reveal a great deal about the content of the message
and even metadata like date can be used with traffic analysis to reveal hidden
recipients (Bcc).

There already exists "Securing Header Fields" as experimental RFC7508.  This
proposes that certain message header fields are signed and verified, and
optionally can replace or delete the field.  This provides a high degree of
flexibility and one approach would be to standard track this.  But this RFC
requires a fairly significant change to S/MIME / CMS processing steps, and there
would be a deployed base that would find it difficult to interoperate with.
Another more feasibile approach is to clarify RFC5751 message/rfc822 language.
Likely this can get most of the header hiding benefit with a smaller change to
CMS processing.

This proposes that if it is desirable to protect header integrity and privacy
that message/rfc822 be used as specifed in RFC5280.  However this instead of
presenting both the outer header (original) and the inner header
(message/rfc822) part to the recipient, this proposes that when the CMS
processing is done, the inner headers in message/rfc822 update the outer ones.
If there is a conflict between the inner and outer, then the inner header
replaces the outer ones.  Body content in message/rfc822 part replaces that of
the parent as well.  Further there should a signed attribute that tells the
recipient to protect header integrity and privacy upon reply or forwarding of
the message.  There also should be a capability specified as well.  Before
sending the message implementations would move these headers to the
message/rfc822 part, leaving those header fields unspecified in the sent
outer message header.

Compliant implementations should protect at least these message headers:
  Subject
  Date
  References
  Message-ID
  Keywords
  Original-XXX
This list is not meant to be exhaustive.  A complete list generated
be done at a later time.  This list also makes no attempt to hide transport
artifacts like the trace headers as these are outside of the control of the
sender and recipient, or the sender and recipient headers as these are needed by
transport.  (Other much more heavy weight approaches are better suited to handle
hiding those headers)

thanks,
-Wei





--001a113e5896ac97ea053335ba5d--


From nobody Thu May 19 11:20:35 2016
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 62C9A12DB98 for ; Thu, 19 May 2016 11:20:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.126
X-Spam-Level: 
X-Spam-Status: No, score=-4.126 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, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 fFiln2fH6aYN for ; Thu, 19 May 2016 11:20:32 -0700 (PDT)
Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BE6012DBCF for ; Thu, 19 May 2016 11:18:41 -0700 (PDT)
Received: by mail-oi0-x231.google.com with SMTP id v145so142138207oie.0 for ; Thu, 19 May 2016 11:18:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=WpGR+itwSshkvX8J6eNS0XlZAIytnez711O2Tc9zKAM=; b=csiA4ridOVtviH9+FZ3zNGNfahiEoU9zbkcC+Pv80X57zJzTwmnzf83HTXNACPQQu+ Yx639SsDAPchGO5g5fTwGNQlnOOGoLrVN1ZhkSkDT6mXoz1OtPgTJUL4q9nX1VM86TXQ P8ZpbnbQXJ28D5NwFz16L/bE+bGUjSh2gkX7WTmyVpknHYEVu6ChwFP5IpZk2FuRMQ77 fYl4jzGsz6LIsYH23b+W39SgCvzcevW1Bm+LOXS9IqJtqd9UCDBHFuyU07Ocq9ok2qfT dADwH/VZ4d1kEXFwhb8xF0OyHWE/9RcfDVYb9M/jISTX+rB17Pso6adSkdEkvNwBd47M kk+g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=WpGR+itwSshkvX8J6eNS0XlZAIytnez711O2Tc9zKAM=; b=AmBkaiJyNdZlUrDms7VPLLYs/jmLP32Ysdkg4ocqk6AWFOYaYNoDLq3JHT/QpEHfI1 Yzk5R8ajVEyKE9RgvYZfUasvXdxUqE9WYiQubfo5bkJ6qepNlNCTlagnW7rgDzKn8/JK +Kx7dRH5A1ZiAhsRlOJmHCR4RTMWJlJO80RyqbDsLpbgZ7aylacQoP2aTaaqPkZPxWCI HRtkJ+FKW6HVa9ND5XtpNyRTOInnU5opzQcn3wgWaqGjdkAL4rLbT15KLLPk2TSjofom 84tkV12MPasj1gWcG1vsp1JiNQc5XovS/y1BUSmZ2yCxHwl4XwGPipTsI0MevhyJNRc6 uGUQ==
X-Gm-Message-State: AOPr4FWza9cCRiQUYLMTkEimp+a4ZtMrxN4MVhPSauy5OIScWdpwnwkTxHBz7Qr4Np04WSzK5y72cmtn2Iq+S/7p
X-Received: by 10.202.244.66 with SMTP id s63mr9384249oih.166.1463681919701; Thu, 19 May 2016 11:18:39 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.157.32.202 with HTTP; Thu, 19 May 2016 11:18:38 -0700 (PDT)
In-Reply-To: <573B2119.3060800@cs.tcd.ie>
References: <316ECF88-612A-4131-8A96-E5F76671929A@vigilsec.com> <044a01d1af10$1548b8c0$3fda2a40$@gmail.com>  <023a01d1b03f$b444c8d0$1cce5a70$@gmail.com> <573B2119.3060800@cs.tcd.ie>
From: Wei Chuang 
Date: Thu, 19 May 2016 11:18:38 -0700
Message-ID: 
To: Stephen Farrell 
Content-Type: multipart/alternative; boundary=001a11c02da6e3cff80533360042
Archived-At: 
Cc: spasm@ietf.org
Subject: Re: [Spasm] more scoping is needed (was: Re: My take on handling EKU constraints)
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 19 May 2016 18:20:34 -0000

--001a11c02da6e3cff80533360042
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On Tue, May 17, 2016 at 6:48 AM, Stephen Farrell 
wrote:

>
> Question for the list:
>
> On 17/05/16 14:26, Santosh Chokhani wrote:
> >  But, this does not help the cross-certified environment.
>
> Is that environment of interest? Should we de-scope it in the
> proposed charter? Or if not, should it be limited to consideration
> for only the smime email application?
>
> From what I've heard so far, the only folks who seem to be
> planning implementations are interested in the WebPKI and
> in enterprise smime. Is that correct?
>
> If in fact we have implementers who are planning to write code
> for something else, those implementers should say so before
> we're done with the charter.
>
> We may save ourselves some extended debates if we can craft
> charter text to reflect the scope of the real work that folks
> want to do.
>
> 
>
> In any case, this mail thread has convinced me that we
> do need some more scoping text in the charter, perhaps to
> name a primary use-case for each of the work items and to
> say that wider (abstract, near theoretical) considerations
> of (the consequences of) the same work items are to be
> discouraged as we know from history that those discussions
> move glacially, are terribly distracting and have lead to
> worse outcomes in the past. Text suggestions welcome.
>

The current charter draft is thankfully brief, and it would be ideal to
keep that.  One thing that might help i.e. cover the issues you are
raising, is to add a statement about work items having a realistic path to
deployment.  Such a plan could be disclosed during the draft discussion.

-Wei


>
> And to be clear, I will not be pushing the next button in
> the formal chartering process until we've tackled this
> issue, either adding text such as the above or convincing
> me that it's not needed. (And I fully admit to possibly
> having an overly-sensitive ocean-boiling-ahead detector
> here;-)
>
> 
>
> Cheers,
> S.
>
>
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm
>
>

--001a11c02da6e3cff80533360042
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit




On Tue, May 17, 2016 at 6:48 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:


Question for the list:



On 17/05/16 14:26, Santosh Chokhani wrote:

>  But, this does not help the cross-certified environment.



Is that environment of interest? Should we de-scope it in the

proposed charter? Or if not, should it be limited to consideration

for only the smime email application?



>From what I've heard so far, the only folks who seem to be

planning implementations are interested in the WebPKI and

in enterprise smime. Is that correct?



If in fact we have implementers who are planning to write code

for something else, those implementers should say so before

we're done with the charter.



We may save ourselves some extended debates if we can craft

charter text to reflect the scope of the real work that folks

want to do.



<SponsoringADHatOn>



In any case, this mail thread has convinced me that we

do need some more scoping text in the charter, perhaps to

name a primary use-case for each of the work items and to

say that wider (abstract, near theoretical) considerations

of (the consequences of) the same work items are to be

discouraged as we know from history that those discussions

move glacially, are terribly distracting and have lead to

worse outcomes in the past. Text suggestions welcome.

The current charter draft is thankfully brief, and it would be ideal to keep that.  One thing that might help i.e. cover the issues you are raising, is to add a statement about work items having a realistic path to deployment.  Such a plan could be disclosed during the draft discussion.

-Wei
 



And to be clear, I will not be pushing the next button in

the formal chartering process until we've tackled this

issue, either adding text such as the above or convincing

me that it's not needed. (And I fully admit to possibly

having an overly-sensitive ocean-boiling-ahead detector

here;-)



</SponsoringADHatOn>



Cheers,

S.




_______________________________________________

Spasm mailing list

Spasm@ietf.org

https://www.ietf.org/mailman/listinfo/spasm





--001a11c02da6e3cff80533360042--


From nobody Fri May 20 01:49:26 2016
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 0182A12D55D for ; Fri, 20 May 2016 01:49:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.425
X-Spam-Level: 
X-Spam-Status: No, score=-3.425 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.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 BJcrNCRxN0uV for ; Fri, 20 May 2016 01:49:23 -0700 (PDT)
Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 2E1F512D0B0 for ; Fri, 20 May 2016 01:49:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1463734162; d=isode.com; s=selector; i=@isode.com; bh=HW3iknwG+Iu/uUqA8Z8qkejNRtdhnxIh8NRYCDzUcwM=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=bIzPRa7EfcrAzBFHFZsTmoseovlf0QagLK/rxEaZaFWr8qyCIkrKPAT3kLPjPxCH3GIzDE GY2YgrzgOgL/n6Ys4hbBQhu1FajABcNqCBJJvNTu+QcVPfqJ0rdd3vAtD1KRpSIHLbnN+6 QDPUhRxmOkvM7ukcwkrBR+tgxELlHu4=;
Received: from [192.168.0.6] (cpc5-nmal20-2-0-cust24.19-2.cable.virginm.net [92.234.84.25])  by waldorf.isode.com (submission channel) via TCP with ESMTPSA  id ; Fri, 20 May 2016 09:49:22 +0100
X-SMTP-Protocol-Errors: PIPELINING
From: Alexey Melnikov 
X-Mailer: iPad Mail (13E238)
In-Reply-To: 
Date: Fri, 20 May 2016 09:57:42 +0100
Message-Id: <30C73B49-D0EF-4E8B-8268-0FDFCB2BDE13@isode.com>
References:  
To: Wei Chuang 
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary=Apple-Mail-EACBF82A-35D1-4B57-9E7C-A175B783654F
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: spasm@ietf.org
Subject: Re: [Spasm] Updating S/MIME handling of message/rfc822?
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 20 May 2016 08:49:25 -0000

--Apple-Mail-EACBF82A-35D1-4B57-9E7C-A175B783654F
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable

Hi,

> On 19 May 2016, at 18:59, Wei Chuang  wrote:
>=20
> In case anyone is interested in this topic, I found this draft that provid=
es a better direction than what I had proposed.
>=20
> https://tools.ietf.org/html/draft-melnikov-smime-header-signing-01

Feel free to borrow text and fold it into other documents.

> -Wei
>=20
>> On Fri, May 13, 2016 at 4:09 PM, Wei Chuang  wrote:
>> Hi,=20
>>=20
>> I would like to propose that draft-schaad-rfc5751-bis-00 further specify
>> handling message/rfc822 processing and specify how to merge message heade=
rs from
>> decrypted/decoded non message/rfc822 types mime parts.  If we can clarify=
 header
>> processing this could provide significant improvement in privacy as revea=
ling
>> headers like subject can reveal a great deal about the content of the mes=
sage
>> and even metadata like date can be used with traffic analysis to reveal h=
idden
>> recipients (Bcc).
>>=20
>> There already exists "Securing Header Fields" as experimental RFC7508.  T=
his
>> proposes that certain message header fields are signed and verified, and
>> optionally can replace or delete the field.  This provides a high degree o=
f
>> flexibility and one approach would be to standard track this.  But this R=
FC
>> requires a fairly significant change to S/MIME / CMS processing steps, an=
d there
>> would be a deployed base that would find it difficult to interoperate wit=
h.
>> Another more feasibile approach is to clarify RFC5751 message/rfc822 lang=
uage.
>> Likely this can get most of the header hiding benefit with a smaller chan=
ge to
>> CMS processing.
>>=20
>> This proposes that if it is desirable to protect header integrity and pri=
vacy
>> that message/rfc822 be used as specifed in RFC5280.  However this instead=
 of
>> presenting both the outer header (original) and the inner header
>> (message/rfc822) part to the recipient, this proposes that when the CMS
>> processing is done, the inner headers in message/rfc822 update the outer o=
nes.
>> If there is a conflict between the inner and outer, then the inner header=

>> replaces the outer ones.  Body content in message/rfc822 part replaces th=
at of
>> the parent as well.  Further there should a signed attribute that tells t=
he
>> recipient to protect header integrity and privacy upon reply or forwardin=
g of
>> the message.  There also should be a capability specified as well.  Befor=
e
>> sending the message implementations would move these headers to the
>> message/rfc822 part, leaving those header fields unspecified in the sent
>> outer message header.
>>=20
>> Compliant implementations should protect at least these message headers:
>>   Subject
>>   Date
>>   References
>>   Message-ID
>>   Keywords
>>   Original-XXX
>> This list is not meant to be exhaustive.  A complete list generated
>> from (http://www.iana.org/assignments/message-headers/message-headers.xht=
ml) can
>> be done at a later time.  This list also makes no attempt to hide transpo=
rt
>> artifacts like the trace headers as these are outside of the control of t=
he
>> sender and recipient, or the sender and recipient headers as these are ne=
eded by
>> transport.  (Other much more heavy weight approaches are better suited to=
 handle
>> hiding those headers)
>>=20
>> thanks,
>> -Wei
>=20
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm

--Apple-Mail-EACBF82A-35D1-4B57-9E7C-A175B783654F
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


Hi,

On 19 May 2016, at 18:59, Wei Chuang <weihaw@google.com> wrote:

In case anyone is interested in this to=
pic, I found this draft that provides a better direction than what I had pro=
posed.

Fee=
l free to borrow text and fold it into other documents.

-Wei

On Fri, May 13, 2016 at 4:09 PM, Wei C=
huang <weihaw@google.com> wrote:
Hi, 

I would like to=
 propose that draft-schaad-rfc5751-bis-00 further specify
handling=
 message/rfc822 processing and specify how to merge message headers from
decrypted/decoded non message/rfc822 types mime parts.  If we can clarify header
processing this could provide signific=
ant improvement in privacy as revealing
headers like subject can r=
eveal a great deal about the content of the message
and even metad=
ata like date can be used with traffic analysis to reveal hidden
r=
ecipients (Bcc).

There already exists "Securing Hea=
der Fields" as experimental RFC7508.  This
proposes that cert=
ain message header fields are signed and verified, and
optionally c=
an replace or delete the field.  This provides a high degree of
flexibility and one approach would be to standard track this.  But t=
his RFC
requires a fairly significant change to S/MIME / CMS proce=
ssing steps, and there
would be a deployed base that would find it=
 difficult to interoperate with.
Another more feasibile approach i=
s to clarify RFC5751 message/rfc822 language.
Likely this can get most of the header hiding benefi=
t with a smaller change to
CMS processing.

This proposes that if it is desirable to protect header integrity and priv=
acy
that message/rfc822 be used as specifed in RFC5280.  Howe=
ver this instead of
presenting both the outer header (original) an=
d the inner header
(message/rfc822) part to the recipient, this pr=
oposes that when the CMS
processing is done, the inner headers in m=
essage/rfc822 update the outer ones.
If there is a conflict betwee=
n the inner and outer, then the inner header
replaces the outer on=
es.  Body content in message/rfc822 part replaces that of
the=
 parent as well.  Further there should a signed attribute that tells th=
e
recipient to protect header integrity and privacy upon reply or f=
orwarding of
the message.  There also should be a capability specified as well.  Before
sen=
ding the message implementations would move these headers to the
m=
essage/rfc822 part, leaving those header fields unspecified in the sent
outer message header.

Compliant implementatio=
ns should protect at least these message headers:
  Subject
  Date
  References
  Message-ID=

  Keywords
  Original-XXX
This list=
 is not meant to be exhaustive.  A complete list generated
be done at a later time.&=
nbsp; This list also makes no attempt to hide transport
artifacts l=
ike the trace headers as these are outside of the control of the
sender and recipient, or the sender and recipient headers as these a=
re needed by
transport.  (Other much more heavy weight approa=
ches are better suited to handle
hiding those headers)
<=
br>
thanks,
-Wei





____________________=
___________________________
Spasm mailing list
Spasm@ietf.org
https://www.ietf.org/mai=
lman/listinfo/spasm
=

--Apple-Mail-EACBF82A-35D1-4B57-9E7C-A175B783654F--


From nobody Sat May 21 13:51:54 2016
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 F2AF612B013 for ; Sat, 21 May 2016 13:51:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.427
X-Spam-Level: 
X-Spam-Status: No, score=-3.427 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.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 LLi92FUJMV2U for ; Sat, 21 May 2016 13:51:50 -0700 (PDT)
Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id C44B712B007 for ; Sat, 21 May 2016 13:51:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1463863909; d=isode.com; s=selector; i=@isode.com; bh=lkdDhxHDu3xzsOxqmqK5Ubz1jWmpeNXV+xw4LReu9Ks=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=hvdyLVMGBbJGoDQSxnAEGcfi+2uUFde2Wmi5uV8UTYyxgEQw50TxEikh9S4XCUwwg7EEM5 8kLNtVJIIzojJl3RLu63EfSjELx/rfwpoK/jlJC+6BTCa2MQ1w+D/wembFqrkKt76SzANh SAitnchTpGEBukCJox3zuiIFozLWv3o=;
Received: from [192.168.0.2] (cpc5-nmal20-2-0-cust24.19-2.cable.virginm.net [92.234.84.25])  by statler.isode.com (submission channel) via TCP with ESMTPSA  id ; Sat, 21 May 2016 21:51:49 +0100
To: Jim Schaad 
References: <064201d1ada1$0b94dc20$22be9460$@augustcellars.com>
From: Alexey Melnikov 
Message-ID: <5740CA5D.9000900@isode.com>
Date: Sat, 21 May 2016 21:51:41 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0
In-Reply-To: <064201d1ada1$0b94dc20$22be9460$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=windows-1252
Content-transfer-encoding: quoted-printable
Archived-At: 
Cc: spasm@ietf.org
Subject: Re: [Spasm] comments on draft-ietf-pkix-eai-addresses-01
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 21 May 2016 20:51:52 -0000

Hi Jim,

On 14/05/2016 06:25, Jim Schaad wrote:
> 1.  This document has been expired for some time and thus should be
> republished if we are planning to use it as a starting point.  (If this is
> done the name would also need to be adjusted.)

Yes, I will post draft-melnikov-spasm-...-00.


> 2.  The text about the format of an eaiMailbox name seems to be strange.
> Specifically, the text about what it does not have deals with display
> formats of an eaiMailbox and not it's format.

This is trying to make the point that the syntax is as used in SMTP
protocol and not as used in similar slots in From/To/Cc/Bcc header
fields. Suggestions how to make this clear are welcome.

If you think just deleting extra text is Ok, I can do that.

> 3.  A section on name constraints is needed in this document similar to th=
e
> text in section 4.2.1.10 in rfc 5280

So are you suggesting something like the following:

   A name constraint for Internationalized Email addresses MAY specify a
   particular mailbox, all addresses at a particular host, or all
   mailboxes in a domain.  To indicate a particular mailbox, the
   constraint is the complete mail address.  For example,
   "root@example.com" indicates the root mailbox on the host
   "example.com".  To indicate all Internationalized Email addresses on
   a particular host, the constraint is specified as the host name.  For
   example, the constraint "example.com" is satisfied by any mail
   address at the host "example.com".  To specify any address within a
   domain, the constraint is specified with a leading period (as with
   URIs).  For example, ".example.com" indicates all the
   Internationalized Email addresses in the domain "example.com",
   but not Internationalized Email addresses on the host "example.com".

Or is it possible to just say that name constrainst for Internet Email
addresses just apply to Internationalized Email addresses?

Or do you think the document needs more text (or different text)?

Best Regards,
Alexey


From nobody Sun May 22 09:12:01 2016
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 DDC7712D110 for ; Sun, 22 May 2016 09:11:59 -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 U-ihBFTRKxfz for ; Sun, 22 May 2016 09:11:58 -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 6FC6612D10E for ; Sun, 22 May 2016 09:11:58 -0700 (PDT)
Received: from [10.9.77.94] (unknown [198.11.221.137]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 4FD4922E1FA; Sun, 22 May 2016 12:11:51 -0400 (EDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Sean Leonard 
In-Reply-To: <5740CA5D.9000900@isode.com>
Date: Sun, 22 May 2016 09:11:50 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <02FC8CC1-C470-436D-8065-117808CA131A@seantek.com>
References: <064201d1ada1$0b94dc20$22be9460$@augustcellars.com> <5740CA5D.9000900@isode.com>
To: spasm@ietf.org
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: Alexey Melnikov 
Subject: Re: [Spasm] comments on draft-ietf-pkix-eai-addresses-01
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 22 May 2016 16:12:00 -0000

> On May 21, 2016, at 1:51 PM, Alexey Melnikov =
 wrote:
>=20
> Hi Jim,
>=20
> On 14/05/2016 06:25, Jim Schaad wrote:
>> 1.  This document has been expired for some time and thus should be
>> republished if we are planning to use it as a starting point.  (If =
this is
>> done the name would also need to be adjusted.)
>=20
> Yes, I will post draft-melnikov-spasm-...-00.
>=20
>=20
>> 2.  The text about the format of an eaiMailbox name seems to be =
strange.
>> Specifically, the text about what it does not have deals with display
>> formats of an eaiMailbox and not it's format.
>=20
> This is trying to make the point that the syntax is as used in SMTP
> protocol and not as used in similar slots in From/To/Cc/Bcc header
> fields. Suggestions how to make this clear are welcome.
>=20
> If you think just deleting extra text is Ok, I can do that.

Actually (as the author of the new draft-seantek-mail-regexen-00) I =
disagree (fairly strongly) with this change.

rfc822Name is defined in terms of RCC 822 etc., not RFC 821 etc.

RFC 5321 imposes several restrictions on e-mail addresses, such as no C0 =
control characters (among other things), that are not present in RFC =
5322 etc. The difference is that there are =E2=80=9Ce-mail addresses=E2=80=
=9D and there are =E2=80=9Cdeliverable e-mail addresses=E2=80=9D. =
=E2=80=9CDeliverable=E2=80=9D in my definition means those that strictly =
conform to RFC 5321 etc., i.e., the =E2=80=9Cmodern SMTP =
infrastructure=E2=80=9D. But e-mail addresses as a class of identifiers, =
can include any character, including U+0000 NULL.

Actually however, a mail server *can* accept e-mail addresses outside =
the range of DEAs, as can systems that consume e-mail address =
identifiers for non-SMTP-mailing purposes (username identifiers, X.400 =
systems, etc.). In some cases it may be desirable to certify/use =
non-deliverable e-mail addresses for other purposes (compare, for =
example, with a PGP key with an e-mail address that an organization or =
individual uses =E2=80=9Cinternally=E2=80=9D, without any intent to =
receive e-mail at that address).

It is reasonable for a certificate to include the full range of e-mail =
addresses, not just =E2=80=9CDEAs=E2=80=9D. This is exactly analogous to =
the IP address fields in GeneralName: you can specify 0.0.0.0 or =
255.255.255.255, even though those addresses are not =E2=80=9Cdeliverable=E2=
=80=9D (i.e., deliverable to a specific endpoint on the network). E-mail =
addresses that do not conform to RFC 5321, but do conform to RFC 5322, =
really should therefore be allowed.

I do agree with a restriction that says that e-mail addresses should be =
in simplified form, namely, have no extraneous whitespace and no =
comments. (RFC 5322 allows these but RFC 5321 does not; they do not add =
to the semantics of the identifier.)

Sean=


From nobody Sun May 22 20:34:12 2016
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 5EC7112D61F for ; Sun, 22 May 2016 20:34:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nJLrCFVUIWJo for ; Sun, 22 May 2016 20:34:08 -0700 (PDT)
Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 945D012D610 for ; Sun, 22 May 2016 20:34:08 -0700 (PDT)
Received: from hebrews (ip-64-134-138-117.public.wayport.net [64.134.138.117]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id A6DB338F64; Sun, 22 May 2016 20:34:07 -0700 (PDT)
From: "Jim Schaad" 
To: "'Sean Leonard'" , 
References: <064201d1ada1$0b94dc20$22be9460$@augustcellars.com> <5740CA5D.9000900@isode.com> <02FC8CC1-C470-436D-8065-117808CA131A@seantek.com>
In-Reply-To: <02FC8CC1-C470-436D-8065-117808CA131A@seantek.com>
Date: Sun, 22 May 2016 20:33:48 -0700
Message-ID: <000001d1b4a3$f6ace550$e406aff0$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQGKZnjtH2+4jtNhP837mF1TA1TL1wGQkjeNAlkgZ4SgNSt4UA==
Content-Language: en-us
Archived-At: 
Cc: 'Alexey Melnikov' 
Subject: Re: [Spasm] comments on draft-ietf-pkix-eai-addresses-01
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 23 May 2016 03:34:10 -0000

> -----Original Message-----
> From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Sean Leonard
> Sent: Sunday, May 22, 2016 9:12 AM
> To: spasm@ietf.org
> Cc: Alexey Melnikov 
> Subject: Re: [Spasm] comments on draft-ietf-pkix-eai-addresses-01
>=20
>=20
> > On May 21, 2016, at 1:51 PM, Alexey Melnikov =

> wrote:
> >
> > Hi Jim,
> >
> > On 14/05/2016 06:25, Jim Schaad wrote:
> >> 1.  This document has been expired for some time and thus should be
> >> republished if we are planning to use it as a starting point.  (If
> >> this is done the name would also need to be adjusted.)
> >
> > Yes, I will post draft-melnikov-spasm-...-00.
> >
> >
> >> 2.  The text about the format of an eaiMailbox name seems to be =
strange.
> >> Specifically, the text about what it does not have deals with =
display
> >> formats of an eaiMailbox and not it's format.
> >
> > This is trying to make the point that the syntax is as used in SMTP
> > protocol and not as used in similar slots in From/To/Cc/Bcc header
> > fields. Suggestions how to make this clear are welcome.
> >
> > If you think just deleting extra text is Ok, I can do that.
>=20
> Actually (as the author of the new draft-seantek-mail-regexen-00) I =
disagree
> (fairly strongly) with this change.
>=20
> rfc822Name is defined in terms of RCC 822 etc., not RFC 821 etc.
>=20
> RFC 5321 imposes several restrictions on e-mail addresses, such as no =
C0 control
> characters (among other things), that are not present in RFC 5322 etc. =
The
> difference is that there are =E2=80=9Ce-mail addresses=E2=80=9D and =
there are =E2=80=9Cdeliverable e-mail
> addresses=E2=80=9D. =E2=80=9CDeliverable=E2=80=9D in my definition =
means those that strictly conform to
> RFC 5321 etc., i.e., the =E2=80=9Cmodern SMTP infrastructure=E2=80=9D. =
But e-mail addresses as a
> class of identifiers, can include any character, including U+0000 =
NULL.
>=20
> Actually however, a mail server *can* accept e-mail addresses outside =
the range
> of DEAs, as can systems that consume e-mail address identifiers for =
non-SMTP-
> mailing purposes (username identifiers, X.400 systems, etc.). In some =
cases it
> may be desirable to certify/use non-deliverable e-mail addresses for =
other
> purposes (compare, for example, with a PGP key with an e-mail address =
that an
> organization or individual uses =E2=80=9Cinternally=E2=80=9D, without =
any intent to receive e-mail
> at that address).
>=20
> It is reasonable for a certificate to include the full range of e-mail =
addresses, not
> just =E2=80=9CDEAs=E2=80=9D. This is exactly analogous to the IP =
address fields in GeneralName:
> you can specify 0.0.0.0 or 255.255.255.255, even though those =
addresses are
> not =E2=80=9Cdeliverable=E2=80=9D (i.e., deliverable to a specific =
endpoint on the network). E-mail
> addresses that do not conform to RFC 5321, but do conform to RFC 5322, =
really
> should therefore be allowed.
>=20
> I do agree with a restriction that says that e-mail addresses should =
be in
> simplified form, namely, have no extraneous whitespace and no =
comments.
> (RFC 5322 allows these but RFC 5321 does not; they do not add to the =
semantics
> of the identifier.)

I am not sure what you are saying is going to be covered by the removal =
of the text and what is not covered by the removal of the text.  I am =
worried that you are starting to move from the world of email addresses =
to NAI forms that are used by systems such as RADIUS, but we are =
labeling this as being an email address form.

I am not sure that I understand the reason that you are distinguishing =
between deliverable and non-deliverable addresses in this field.  Do you =
have an application in mind where non-deliverable addresses are needed?

Jim

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


From nobody Sun May 22 20:34:24 2016
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 C747912D610 for ; Sun, 22 May 2016 20:34:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LOBJAMylOqNr for ; Sun, 22 May 2016 20:34:10 -0700 (PDT)
Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B067512D61C for ; Sun, 22 May 2016 20:34:08 -0700 (PDT)
Received: from hebrews (ip-64-134-138-117.public.wayport.net [64.134.138.117]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id 1077C38F65; Sun, 22 May 2016 20:34:07 -0700 (PDT)
From: "Jim Schaad" 
To: "'Alexey Melnikov'" 
References: <064201d1ada1$0b94dc20$22be9460$@augustcellars.com> <5740CA5D.9000900@isode.com>
In-Reply-To: <5740CA5D.9000900@isode.com>
Date: Sun, 22 May 2016 20:33:48 -0700
Message-ID: <000301d1b4a3$f6fdc470$e4f94d50$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQGKZnjtH2+4jtNhP837mF1TA1TL1wGQkjeNoEfzJVA=
Content-Language: en-us
Archived-At: 
Cc: spasm@ietf.org
Subject: Re: [Spasm] comments on draft-ietf-pkix-eai-addresses-01
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 23 May 2016 03:34:12 -0000

> -----Original Message-----
> From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Alexey Melnikov
> Sent: Saturday, May 21, 2016 1:52 PM
> To: Jim Schaad 
> Cc: spasm@ietf.org
> Subject: Re: [Spasm] comments on draft-ietf-pkix-eai-addresses-01
> 
> Hi Jim,
> 
> On 14/05/2016 06:25, Jim Schaad wrote:
> > 1.  This document has been expired for some time and thus should be
> > republished if we are planning to use it as a starting point.  (If
> > this is done the name would also need to be adjusted.)
> 
> Yes, I will post draft-melnikov-spasm-...-00.
> 
> 
> > 2.  The text about the format of an eaiMailbox name seems to be strange.
> > Specifically, the text about what it does not have deals with display
> > formats of an eaiMailbox and not it's format.
> 
> This is trying to make the point that the syntax is as used in SMTP
protocol and
> not as used in similar slots in From/To/Cc/Bcc header fields. Suggestions
how to
> make this clear are welcome.
> 
> If you think just deleting extra text is Ok, I can do that.

My preference would be to delete the text; I don't think that it adds
anything to the text.  I do however thing that you might want to remove the
brackets from the token name in the text as that is part of the definition
of email addresses in some places.

I am worried about the following case and I think that text needs to be
added for it.  One can encode the address as joe@example.com or
"joe"@example.com .  Both of these addresses are legal, but if you do a byte
comparison between them they will not compare.  


> 
> > 3.  A section on name constraints is needed in this document similar
> > to the text in section 4.2.1.10 in rfc 5280
> 
> So are you suggesting something like the following:
> 
>    A name constraint for Internationalized Email addresses MAY specify a
>    particular mailbox, all addresses at a particular host, or all
>    mailboxes in a domain.  To indicate a particular mailbox, the
>    constraint is the complete mail address.  For example,
>    "root@example.com" indicates the root mailbox on the host
>    "example.com".  To indicate all Internationalized Email addresses on
>    a particular host, the constraint is specified as the host name.  For
>    example, the constraint "example.com" is satisfied by any mail
>    address at the host "example.com".  To specify any address within a
>    domain, the constraint is specified with a leading period (as with
>    URIs).  For example, ".example.com" indicates all the
>    Internationalized Email addresses in the domain "example.com",
>    but not Internationalized Email addresses on the host "example.com".
> 
> Or is it possible to just say that name constrainst for Internet Email
addresses
> just apply to Internationalized Email addresses?

I don't think you can just punt this because of the difference in the
encoded name.  While I think that the rules are going to be the same, the
actual structure defined in general name is going to be different.

Jim

> 
> Or do you think the document needs more text (or different text)?
> 
> Best Regards,
> Alexey
> 
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm


From nobody Mon May 23 10:29:20 2016
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 4F0BE12D11A for ; Mon, 23 May 2016 10:29:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Level: 
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l9N6L75XqjkM for ; Mon, 23 May 2016 10:29:17 -0700 (PDT)
Received: from mail.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 181FC12D7E8 for ; Mon, 23 May 2016 10:29:17 -0700 (PDT)
Received: from localhost (ronin.smetech.net [209.135.209.5]) by mail.smetech.net (Postfix) with ESMTP id BBEFBF240AA; Mon, 23 May 2016 13:29:16 -0400 (EDT)
X-Virus-Scanned: amavisd-new at smetech.net
Received: from mail.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id KAmzh6Yi1Weq; Mon, 23 May 2016 13:11:42 -0400 (EDT)
Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.smetech.net (Postfix) with ESMTP id 484A0F24013; Mon, 23 May 2016 13:29:16 -0400 (EDT)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Russ Housley 
In-Reply-To: <4A0C6BB6-D5F8-47A0-B392-AEBC0859C1FC@aaa-sec.com>
Date: Mon, 23 May 2016 13:29:22 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20160518171802.14749.72841.idtracker@ietfa.amsl.com>  <4A0C6BB6-D5F8-47A0-B392-AEBC0859C1FC@aaa-sec.com>
To: Stefan Santesson 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: 
Cc: spasm@ietf.org
Subject: Re: [Spasm] draft-housley-spasm-eku-constraints-01.txt
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 23 May 2016 17:29:18 -0000

Stefan:

> 1) I don=92t like that this extension MUST be critical. It=92s a =
deployment killer. Who can include it before all validation engines =
support it, and who will bother to support it when no one includes it?

We have had this same debate with other must-be-critical extensions.  =
RFC 5280 has set the precedent on criticality for an extension in a CA =
certificate that impose restrictions on things that can appear in =
subsequent certificates in the path:

  4.2.1.10.  Name Constraints

    Conforming CAs MUST mark this extension as critical =85

  4.2.1.11.  Policy Constraints

     Conforming CAs MUST mark this extension as critical.


> 2) This is too complex for my taste.
>=20
> I know that everything in the draft makes sense, but it may just be a =
bit too complex to get implemented and used correctly.
> Have anyone made a study on where this is needed, and in what =
situations?
>=20
> I know from my Microsoft days that Microsoft had an internal =
processing of EKU in CA certs in order to limit which certs that could =
be used under which root. Mainly for constraining code signing usage.
> Microsoft attempted to solve the same type of issue at one stage by =
introducing application policies with exclude and include logic. It =
never got used.

Maybe it was not used while you were at Microsoft, but the message to =
the PKIX list that started this discussion shows that the current EKU is =
being used in the same manner as permittedKeyPurposeIds in my proposal.  =
Your example about constraining code signing is exactly the reason that =
I included excludedKeyPurposeIds in my proposal.

Russ


From nobody Mon May 23 14:09:42 2016
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 CCB8D12DBC8 for ; Mon, 23 May 2016 14:09:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-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 lTCq89Ayez5l for ; Mon, 23 May 2016 14:09:40 -0700 (PDT)
Received: from smtp.outgoing.loopia.se (smtp.outgoing.loopia.se [194.9.95.112]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AD0512DBC6 for ; Mon, 23 May 2016 14:09:38 -0700 (PDT)
Received: from s554.loopia.se (localhost [127.0.0.1]) by s554.loopia.se (Postfix) with ESMTP id 5E39B17A7B29 for ; Mon, 23 May 2016 23:09:36 +0200 (CEST)
X-Loopia-Auth: user
X-Loopia-Originating-IP: 90.229.17.25
X-Loopia-User: stefan@fiddler.nu
Received: from s498.loopia.se (unknown [172.21.200.96]) by s554.loopia.se (Postfix) with ESMTP id 41989988933; Mon, 23 May 2016 23:09:36 +0200 (CEST)
Received: from s406.loopia.se (unknown [172.21.200.105]) by s498.loopia.se (Postfix) with ESMTP id 3F06045E719; Mon, 23 May 2016 23:09:36 +0200 (CEST)
X-Virus-Scanned: amavisd-new at amavis.loopia.se
Received: from s498.loopia.se ([172.21.200.105]) by s406.loopia.se (s406.loopia.se [172.21.200.136]) (amavisd-new, port 10024) with LMTP id JO8l2hwRY02g; Mon, 23 May 2016 23:09:35 +0200 (CEST)
Received: from [10.0.1.51] (unknown [90.229.17.25]) (Authenticated sender: stefan@fiddler.nu) by s498.loopia.se (Postfix) with ESMTPSA id B8F6945E70E; Mon, 23 May 2016 23:09:35 +0200 (CEST)
User-Agent: Microsoft-MacOutlook/f.16.0.160506
Date: Mon, 23 May 2016 23:09:34 +0200
From: Stefan Santesson 
To: Russ Housley 
Message-Id: <939935CA-2161-49B8-92D3-FB296CDF4ADE@aaa-sec.com>
Thread-Topic: [Spasm] draft-housley-spasm-eku-constraints-01.txt
References: <20160518171802.14749.72841.idtracker@ietfa.amsl.com>  <4A0C6BB6-D5F8-47A0-B392-AEBC0859C1FC@aaa-sec.com> 
In-Reply-To: 
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: spasm@ietf.org
Subject: Re: [Spasm] draft-housley-spasm-eku-constraints-01.txt
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 23 May 2016 21:09:42 -0000

Russ,

In line;

On 23/05/16 19:29, "Spasm on behalf of Russ Housley"  wrote:

>Stefan:
>
>> 1) I don=E2=80=99t like that this extension MUST be critical. It=E2=80=99s a deploym=
ent killer. Who can include it before all validation engines support it, and=
 who will bother to support it when no one includes it?
>
>We have had this same debate with other must-be-critical extensions.  RFC =
5280 has set the precedent on criticality for an extension in a CA certifica=
te that impose restrictions on things that can appear in subsequent certific=
ates in the path:
>
>  4.2.1.10.  Name Constraints
>
>    Conforming CAs MUST mark this extension as critical =E2=80=A6
>
>  4.2.1.11.  Policy Constraints
>
>     Conforming CAs MUST mark this extension as critical.
>

Those where other times. That was extensions already known to the market. A=
nd we where more na=C3=AFve at the time than we are today.
We overestimated the value of the features and we underestimated the intero=
p challenges.
You are of course absolutely right. The only problem is that it may not wor=
k because it=E2=80=99s a deployment blocker. Who will include an extension that gu=
arantees that the certificate will be rejected in all major implementations?

I=E2=80=99d make it a CA choice. They can decide whether they can live with the r=
isk of clients not getting the extension constraint over the drawback of hav=
ing the certificate rejected in most current clients.
This is no worse than it is today. Issuers putting in EKU in CA certificate=
s for the purpose of constraining have no guarantee that everyone will get i=
t, and obviously they can live with that.

>Maybe it was not used while you were at Microsoft, but the message to the =
PKIX list that started this discussion shows that the current EKU is being u=
sed in the same manner as permittedKeyPurposeIds in my proposal.  Your examp=
le about constraining code signing is exactly the reason that I included exc=
ludedKeyPurposeIds in my proposal.
>

The logic used for code signing only needs the permitted logic. Everything =
not in the permitted group is not permitted.
If I need to choose between 2 evils, I=E2=80=99d rather have a simple extension m=
aking it legal what is already out there, than a new fancy extension that is=
 more capable.

/Stefan



From nobody Tue May 24 13:14:14 2016
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 3293512D517 for ; Tue, 24 May 2016 13:13:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Level: 
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XzG5CUmQnWbh for ; Tue, 24 May 2016 13:13:09 -0700 (PDT)
Received: from mail.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id EE98412D1A8 for ; Tue, 24 May 2016 13:11:39 -0700 (PDT)
Received: from localhost (ronin.smetech.net [209.135.209.5]) by mail.smetech.net (Postfix) with ESMTP id 1ABC2F240C6; Tue, 24 May 2016 16:11:40 -0400 (EDT)
X-Virus-Scanned: amavisd-new at smetech.net
Received: from mail.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id KxWwEMYlY1dt; Tue, 24 May 2016 15:54:00 -0400 (EDT)
Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.smetech.net (Postfix) with ESMTP id 81E30F240C2; Tue, 24 May 2016 16:11:39 -0400 (EDT)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Russ Housley 
In-Reply-To: <939935CA-2161-49B8-92D3-FB296CDF4ADE@aaa-sec.com>
Date: Tue, 24 May 2016 16:11:38 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <7888389D-73C8-49AD-B788-E3886AB9410E@vigilsec.com>
References: <20160518171802.14749.72841.idtracker@ietfa.amsl.com>  <4A0C6BB6-D5F8-47A0-B392-AEBC0859C1FC@aaa-sec.com>  <939935CA-2161-49B8-92D3-FB296CDF4ADE@aaa-sec.com>
To: Stefan Santesson 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: 
Cc: spasm@ietf.org
Subject: Re: [Spasm] draft-housley-spasm-eku-constraints-01.txt
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 24 May 2016 20:13:20 -0000
X-List-Received-Date: Tue, 24 May 2016 20:13:20 -0000

Stefan:

>>> 1) I don=92t like that this extension MUST be critical. It=92s a =
deployment killer. Who can include it before all validation engines =
support it, and who will bother to support it when no one includes it?
>>=20
>> We have had this same debate with other must-be-critical extensions.  =
RFC 5280 has set the precedent on criticality for an extension in a CA =
certificate that impose restrictions on things that can appear in =
subsequent certificates in the path:
>>=20
>> 4.2.1.10.  Name Constraints
>>=20
>>   Conforming CAs MUST mark this extension as critical =85
>>=20
>> 4.2.1.11.  Policy Constraints
>>=20
>>    Conforming CAs MUST mark this extension as critical.
>>=20
>=20
> Those where other times. That was extensions already known to the =
market. And we where more na=EFve at the time than we are today.
> We overestimated the value of the features and we underestimated the =
interop challenges.
> You are of course absolutely right. The only problem is that it may =
not work because it=92s a deployment blocker. Who will include an =
extension that guarantees that the certificate will be rejected in all =
major implementations?

Indeed, there are challenges to deploying a critical extension.  A =
significant population of relying parties would need to support it =
before a CA would make use of it.

> I=92d make it a CA choice. They can decide whether they can live with =
the risk of clients not getting the extension constraint over the =
drawback of having the certificate rejected in most current clients.
> This is no worse than it is today. Issuers putting in EKU in CA =
certificates for the purpose of constraining have no guarantee that =
everyone will get it, and obviously they can live with that.

I think you are suggesting:

   This extension MAY, at the option of the certificate issuer, be
   either critical or non-critical.

If this is the approach supported by otters, then I will make the =
change.  It would require a bit of text in the Security Considerations =
about non-critical EKU constraints being ignored by relying parties that =
do not support this extension.

>=20
>> Maybe it was not used while you were at Microsoft, but the message to =
the PKIX list that started this discussion shows that the current EKU is =
being used in the same manner as permittedKeyPurposeIds in my proposal.  =
Your example about constraining code signing is exactly the reason that =
I included excludedKeyPurposeIds in my proposal.
>=20
> The logic used for code signing only needs the permitted logic. =
Everything not in the permitted group is not permitted.
> If I need to choose between 2 evils, I=92d rather have a simple =
extension making it legal what is already out there, than a new fancy =
extension that is more capable.

I=92ve shared my thought process.  What do others think?

Russ


From nobody Tue May 24 13:39:32 2016
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 855BF12D54B for ; Tue, 24 May 2016 13:39:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GkdU0tcMzYk8 for ; Tue, 24 May 2016 13:39:28 -0700 (PDT)
Received: from mail-qg0-x22a.google.com (mail-qg0-x22a.google.com [IPv6:2607:f8b0:400d:c04::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 254A912D187 for ; Tue, 24 May 2016 13:39:28 -0700 (PDT)
Received: by mail-qg0-x22a.google.com with SMTP id q32so13154691qgq.3 for ; Tue, 24 May 2016 13:39:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=jEJcu3OY52kVNBwoR+41JYfuHaOD8BgAPg2W1m9Nzqc=; b=Adl5oOyJpIkFZO3ivQ1BJ4lLCyPE2VwSPjl39hs5yVdVSDOEgtSxB/KOmtmMpoUh0F XeS5VmIjy0KPJPz8CotDCNyOwtzsv6RnJOlGRq71se5CBJxzoONQMKhxHTIuZ8qGsdz9 p+gSznMMNgbE7pPltX4VXIS/tVKEspl0pNBqmz7oyVK4CePKXMGA5JICGK+BbHu0y7/m XeZpAqGUoH+r3dI2y60ZNURA/DrybxnNffQkFqcXVkCt8A6QfTFhfi0f0QnWmjj12EeU 6n0MVcxDomUIT6GAMt7mHjvQonfCgp+KQw0C3uyqgGZmF3+qnWHhVxdyvLdVUhlv6W7T UgFw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=jEJcu3OY52kVNBwoR+41JYfuHaOD8BgAPg2W1m9Nzqc=; b=RVOySBhEpM8ECe8cwkFRHBOe76X144jqzy09tJbrkA4zC45v3vsulyP11G6+jByrdo DA43NP/40zOEsbU9+lsTXesgyJWC18N9h3ClSi/xRoCH7QGRhMNuqcKsmiRrG4Im71ju rr9MG5hg+UjPdTlgmpPMakTKz03/0Y7lxpyQywRBBYT3QBjq8hME5zlHhaUBfhEk8VZV ZcHfegwo/Nk1FK87egYH49HccN2jlYt3ET0BzGOhYX33iV5M6FyDOLysyI2mZXzY+BDL MW9XQ093a6OkJLPebpVKU8v/TQUprXaUObgxlfBfaVbY29Uazn9Lv+dhacn2LiTRwlm3 emhw==
X-Gm-Message-State: ALyK8tJMlU6C/79LkjFfuii0fKNftDc+4ye5nYImihMWpOh9haq6/5Dz/VSqDRdKfW98yQ==
X-Received: by 10.140.102.117 with SMTP id v108mr97180qge.103.1464122367164; Tue, 24 May 2016 13:39:27 -0700 (PDT)
Received: from SantoshBrain (pool-173-73-188-109.washdc.fios.verizon.net. [173.73.188.109]) by smtp.gmail.com with ESMTPSA id b6sm1369294qte.1.2016.05.24.13.39.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 24 May 2016 13:39:26 -0700 (PDT)
From: "Santosh Chokhani" 
To: "'Russ Housley'" , "'Stefan Santesson'" 
References: <20160518171802.14749.72841.idtracker@ietfa.amsl.com>  <4A0C6BB6-D5F8-47A0-B392-AEBC0859C1FC@aaa-sec.com>  <939935CA-2161-49B8-92D3-FB296CDF4ADE@aaa-sec.com> <7888389D-73C8-49AD-B788-E3886AB9410E@vigilsec.com>
In-Reply-To: <7888389D-73C8-49AD-B788-E3886AB9410E@vigilsec.com>
Date: Tue, 24 May 2016 16:39:27 -0400
Message-ID: <129801d1b5fc$5dc23610$1946a230$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQHDo4XPDN1PvR3BbtYWL1i1O+mXkgFmMK4rAQNGVaEBdMUUxwK85q+YAUJN0ACfpcNOQA==
Content-Language: en-us
Archived-At: 
Cc: spasm@ietf.org
Subject: Re: [Spasm] draft-housley-spasm-eku-constraints-01.txt
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 24 May 2016 20:39:30 -0000

If we are going to have the new extension and the application developers
will process it, it is better to have both permitted and excluded, =
albeit a
CHOICE.

The reason both is good is that way a CA can deny some and permit the =
rest
without having to spell all the permitted ones out.

The reason it should be a CHOICE is once a CA decides on permitted,
everything else is excluded.

Thus you will never need both.

Unlike name constraints (which is a continuous space and you may wish to
create holes in it using both), key purposes are independent, discreet
values and thus do not need both permitted and excluded.

-----Original Message-----
From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Russ Housley
Sent: Tuesday, May 24, 2016 4:12 PM
To: Stefan Santesson 
Cc: spasm@ietf.org
Subject: Re: [Spasm] draft-housley-spasm-eku-constraints-01.txt

Stefan:

>>> 1) I don=92t like that this extension MUST be critical. It=92s a =
deployment
killer. Who can include it before all validation engines support it, and =
who
will bother to support it when no one includes it?
>>=20
>> We have had this same debate with other must-be-critical extensions.  =
RFC
5280 has set the precedent on criticality for an extension in a CA
certificate that impose restrictions on things that can appear in =
subsequent
certificates in the path:
>>=20
>> 4.2.1.10.  Name Constraints
>>=20
>>   Conforming CAs MUST mark this extension as critical =85
>>=20
>> 4.2.1.11.  Policy Constraints
>>=20
>>    Conforming CAs MUST mark this extension as critical.
>>=20
>=20
> Those where other times. That was extensions already known to the =
market.
And we where more na=EFve at the time than we are today.
> We overestimated the value of the features and we underestimated the
interop challenges.
> You are of course absolutely right. The only problem is that it may =
not
work because it=92s a deployment blocker. Who will include an extension =
that
guarantees that the certificate will be rejected in all major
implementations?

Indeed, there are challenges to deploying a critical extension.  A
significant population of relying parties would need to support it =
before a
CA would make use of it.

> I=92d make it a CA choice. They can decide whether they can live with =
the
risk of clients not getting the extension constraint over the drawback =
of
having the certificate rejected in most current clients.
> This is no worse than it is today. Issuers putting in EKU in CA
certificates for the purpose of constraining have no guarantee that =
everyone
will get it, and obviously they can live with that.

I think you are suggesting:

   This extension MAY, at the option of the certificate issuer, be
   either critical or non-critical.

If this is the approach supported by otters, then I will make the =
change.
It would require a bit of text in the Security Considerations about
non-critical EKU constraints being ignored by relying parties that do =
not
support this extension.

>=20
>> Maybe it was not used while you were at Microsoft, but the message to =
the
PKIX list that started this discussion shows that the current EKU is =
being
used in the same manner as permittedKeyPurposeIds in my proposal.  Your
example about constraining code signing is exactly the reason that I
included excludedKeyPurposeIds in my proposal.
>=20
> The logic used for code signing only needs the permitted logic. =
Everything
not in the permitted group is not permitted.
> If I need to choose between 2 evils, I=92d rather have a simple =
extension
making it legal what is already out there, than a new fancy extension =
that
is more capable.

I=92ve shared my thought process.  What do others think?

Russ

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


From nobody Wed May 25 01:30:15 2016
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 6C07612D603 for ; Wed, 25 May 2016 01:30:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-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 3NgT3cryjQxK for ; Wed, 25 May 2016 01:30:12 -0700 (PDT)
Received: from smtp.outgoing.loopia.se (smtp.outgoing.loopia.se [194.9.95.112]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23DCC12D5FD for ; Wed, 25 May 2016 01:30:11 -0700 (PDT)
Received: from s554.loopia.se (localhost [127.0.0.1]) by s554.loopia.se (Postfix) with ESMTP id 6DF0017CB757 for ; Wed, 25 May 2016 10:30:09 +0200 (CEST)
X-Loopia-Auth: user
X-Loopia-Originating-IP: 90.229.17.25
X-Loopia-User: stefan@fiddler.nu
Received: from s499.loopia.se (unknown [172.21.200.97]) by s554.loopia.se (Postfix) with ESMTP id 5269D953601; Wed, 25 May 2016 10:30:09 +0200 (CEST)
Received: from s549.loopia.se (unknown [172.21.200.105]) by s499.loopia.se (Postfix) with ESMTP id 4DD36136278B; Wed, 25 May 2016 10:30:09 +0200 (CEST)
X-Virus-Scanned: amavisd-new at amavis.loopia.se
Received: from s499.loopia.se ([172.21.200.105]) by s549.loopia.se (s549.loopia.se [172.21.200.137]) (amavisd-new, port 10024) with LMTP id NMOOSHJBtyUc; Wed, 25 May 2016 10:30:09 +0200 (CEST)
Received: from [10.0.1.51] (unknown [90.229.17.25]) (Authenticated sender: stefan@fiddler.nu) by s499.loopia.se (Postfix) with ESMTPSA id E7067136265E; Wed, 25 May 2016 10:30:08 +0200 (CEST)
User-Agent: Microsoft-MacOutlook/f.16.0.160506
Date: Wed, 25 May 2016 10:30:07 +0200
From: Stefan Santesson 
To: Russ Housley 
Message-Id: 
Thread-Topic: [Spasm] draft-housley-spasm-eku-constraints-01.txt
References: <20160518171802.14749.72841.idtracker@ietfa.amsl.com>  <4A0C6BB6-D5F8-47A0-B392-AEBC0859C1FC@aaa-sec.com>  <939935CA-2161-49B8-92D3-FB296CDF4ADE@aaa-sec.com> <7888389D-73C8-49AD-B788-E3886AB9410E@vigilsec.com>
In-Reply-To: <7888389D-73C8-49AD-B788-E3886AB9410E@vigilsec.com>
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="B_3547017008_1273479828"
Archived-At: 
Cc: spasm@ietf.org
Subject: Re: [Spasm] draft-housley-spasm-eku-constraints-01.txt
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 25 May 2016 08:30:14 -0000

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3547017008_1273479828
Content-type: text/plain;
	charset="UTF-8"
Content-transfer-encoding: quoted-printable

>I think you are suggesting:

>=20

>=C2=A0=C2=A0 This extension MAY, at the option of the certificate issuer, be

>=C2=A0=C2=A0 either critical or non-critical.

>=20

>If this is the approach supported by otters, then I will make the change.=C2=
=A0 It would require a bit of text in the Security Considerations about non-cr=
itical EKU constraints being ignored by relying parties that do not support =
this extension.

>=20

=20

Yes, that is what I would suggest.

=20

=20

>>=20

>>> Maybe it was not used while you were at Microsoft, but the message to t=
he PKIX list that started this discussion shows that the current EKU is bein=
g used in the same manner as permittedKeyPurposeIds in my proposal.=C2=A0 Your e=
xample about constraining code signing is exactly the reason that I included=
 excludedKeyPurposeIds in my proposal.

>>=20

>> The logic used for code signing only needs the permitted logic. Everythi=
ng not in the permitted group is not permitted.

>> If I need to choose between 2 evils, I=E2=80=99d rather have a simple extensio=
n making it legal what is already out there, than a new fancy extension that=
 is more capable.

>=20

>I=E2=80=99ve shared my thought process.=C2=A0 What do others think?

>=20

=20

I think it=E2=80=99s a matter of preference, not right or wrong.

I=E2=80=99d like to hear what those who will implement and use this think about i=
t.

Unfortunately X.509 is over engineered and therefore many features are brok=
en in practice.

Even if certificate using systems gets it right, certificate issuers don=E2=80=99=
t. So certificate using systems creates exceptions to the standards to handl=
e non conformant certs.

Certificate policy in path processing is an excellent example.

=20

I=E2=80=99d therefore rather give the market something I believe they can handle.

=20

/Stefan


--B_3547017008_1273479828
Content-type: text/html;
	charset="UTF-8"
Content-transfer-encoding: quoted-printable


>I think you are sugge=
sting:
> 
>=C2=A0=C2=A0 This extension MAY, at the option of the certificate =
issuer, be
>=C2=A0=C2=A0 either critical or n=
on-critical.
> 
>If this is the approach supported by otters, then I =
will make the change.=C2=A0 It would require a bit of text in the Security Consi=
derations about non-critical EKU constraints being ignored by relying partie=
s that do not support this extension.
&g=
t; 
 
Yes, that is what I would suggest.
 
 
>> 
>>> =
Maybe it was not used while you were at Microsoft, but the message to the PK=
IX list that started this discussion shows that the current EKU is being use=
d in the same manner as permittedKeyPurposeIds in my proposal.=C2=A0 Your exampl=
e about constraining code signing is exactly the reason that I included excl=
udedKeyPurposeIds in my proposal.
>&g=
t; 
>> The logic used for code sig=
ning only needs the permitted logic. Everything not in the permitted group i=
s not permitted.
>> If I need to c=
hoose between 2 evils, I’d rather have a simple extension making it le=
gal what is already out there, than a new fancy extension that is more capab=
le.
> 
>I’ve shared my thought process.=C2=A0 What do others think?=

> 
 
I think it’s a matt=
er of preference, not right or wrong.
I&=
#8217;d like to hear what those who will implement and use this think about =
it.
Unfortunately X.509 is over engineer=
ed and therefore many features are broken in practice.
Even if certificate using systems gets it right, certificate =
issuers don’t. So certificate using systems creates exceptions to the =
standards to handle non conformant certs.
Certificate policy in path processing is an excellent example.<=
/p>
 
I’=
d therefore rather give the market something I believe they can handle.=

 
/=
Stefan


--B_3547017008_1273479828--



From nobody Wed May 25 08:33:49 2016
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 08A5F12D0BE for ; Wed, 25 May 2016 08:33:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Level: 
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ElvFdEJTIC68 for ; Wed, 25 May 2016 08:33:45 -0700 (PDT)
Received: from mail.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 650CE12D7D0 for ; Wed, 25 May 2016 08:31:56 -0700 (PDT)
Received: from localhost (ronin.smetech.net [209.135.209.5]) by mail.smetech.net (Postfix) with ESMTP id D7B07F24045 for ; Wed, 25 May 2016 11:31:55 -0400 (EDT)
X-Virus-Scanned: amavisd-new at smetech.net
Received: from mail.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id IzR09huOwKPx for ; Wed, 25 May 2016 11:14:13 -0400 (EDT)
Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.smetech.net (Postfix) with ESMTP id 7FF76F2402A for ; Wed, 25 May 2016 11:31:55 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Russ Housley 
In-Reply-To: <20160525151646.18361.48904.idtracker@ietfa.amsl.com>
Date: Wed, 25 May 2016 11:32:01 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <3DB53E2C-24FD-4E9C-BAFA-11154501A90C@vigilsec.com>
References: <20160525151646.18361.48904.idtracker@ietfa.amsl.com>
To: spasm@ietf.org
X-Mailer: Apple Mail (2.1878.6)
Archived-At: 
Subject: [Spasm] New Version Notification for draft-housley-spasm-eku-constraints-02.txt
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 25 May 2016 15:33:47 -0000

I made many little changes, and I made three bigger ones based on the =
discussion on this list:

1) The extension may be critical or non-critical.

2) The extension syntax is changed to a CHOICE:

      EKUConstraints ::=3D CHOICE {
          permittedKeyPurposeIds   [0] KeyPurposeIds OPTIONAL,
          excludedKeyPurposeIds    [1] KeyPurposeIds OPTIONAL }

3) A end entity-certificate does not include an EKU extension is allowed =
to be used with any key purpose identifier, so a check in the path =
processing was added to handle this.

Russ


On May 25, 2016, at 11:16 AM, internet-drafts@ietf.org wrote:

> A new version of I-D, draft-housley-spasm-eku-constraints-02.txt
> has been successfully submitted by Russell Housley and posted to the
> IETF repository.
>=20
> Name:		draft-housley-spasm-eku-constraints
> Revision:	02
> Title:		Extended Key Usage Constraints
> Document date:	2016-05-25
> Group:		Individual Submission
> Pages:		9
> URL:            =
https://www.ietf.org/internet-drafts/draft-housley-spasm-eku-constraints-0=
2.txt
> Status:         =
https://datatracker.ietf.org/doc/draft-housley-spasm-eku-constraints/
> Htmlized:       =
https://tools.ietf.org/html/draft-housley-spasm-eku-constraints-02
> Diff:           =
https://www.ietf.org/rfcdiff?url2=3Ddraft-housley-spasm-eku-constraints-02=

>=20
> Abstract:
>   This document specifies the extended key usage constraints
>   certificate extension, which is used to place restrictions on the =
key
>   purpose identifiers that are authorized to appear in the end-entity
>   certificate in a certification path.  Restrictions apply to the
>   extended key usage certificate extension, which is described in
>   RFC 5280.


From nobody Wed May 25 10:43:27 2016
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 13BD312D8A0 for ; Wed, 25 May 2016 10:43:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.426
X-Spam-Level: 
X-Spam-Status: No, score=-3.426 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, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 133-3A14q_LH for ; Wed, 25 May 2016 10:43:23 -0700 (PDT)
Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::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 82DA312D887 for ; Wed, 25 May 2016 10:43:23 -0700 (PDT)
Received: by mail-oi0-x229.google.com with SMTP id w184so83664107oiw.2 for ; Wed, 25 May 2016 10:43:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zLDUfuFyJEPdXWVpIXhLQcG7Avymb9LOcEWTpNTWsA0=; b=a2oXH8RDSrvex6kVP7fDQBJxv96NL0LgduTRsGuH9++1l9z0TuMs4ZNsMHc8mGRIiv 78dTznOHXzxcf8fHWdwRrsL6BQwi+pLmi6BKDh7EOFbCUT3oHxdOXqJRV9f6PxNMimal b4P2oxpuXAfOnzxf667vkjLI9hBnMsfVl7SENSHItjVJlaNXwz7yQaODSazM1JhHwOfJ N4zSz/dTq/O5IeeFObxVygDGOrLnT6X4qJfg+emfV9Un32mbN+MlT6HrQAewa24FRUwW XFWDOXvUubHBAos1h2HA1NyeQebqqiQ2e5pfyViAU8jqJeBCiPjDQaq7zcpTqY1W2nro 2ZvA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=zLDUfuFyJEPdXWVpIXhLQcG7Avymb9LOcEWTpNTWsA0=; b=JhCqA6QtXgp74BS3kEMgW0WpMxVaV/4BNUK0Kj1BRfdxZ0hA/kmMZEqZVj7gjVwB9s 6M4wSMJ1GMmXFV96GGbNOOv5+Fjx54/uXwayetMJJT3BdrexDHaptvYNiq3DGqkx16Js vDxhklFHLymzzAYMP31nUuqluhM4CWuGhVSrpW0HQCsqA9pYKZ+PK7pgbmPfX3D91URw WCcK0rbl1unCw0Lt3ABKNrUCIzTrvYMiDZAoSwTtibyyJZYzqiXj+EmW5ODjMllR58uX qa51z3ghPI1e8lT3d2xg0OVDQB5U/k7HvKr0lRubbHpbf+MEzarGcryBaVo6O6PgciFx ZA8w==
X-Gm-Message-State: ALyK8tJzvINXjjZe7fbd8GBp8cDNoxuo30KsCTQ+KYM3FEqB76QvfzocDSafOw4bbtEu+mVRpuEpC3c4YC/hi7rt
X-Received: by 10.202.65.133 with SMTP id o127mr3167234oia.43.1464198202665; Wed, 25 May 2016 10:43:22 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.157.1.67 with HTTP; Wed, 25 May 2016 10:43:21 -0700 (PDT)
In-Reply-To: <7888389D-73C8-49AD-B788-E3886AB9410E@vigilsec.com>
References: <20160518171802.14749.72841.idtracker@ietfa.amsl.com>  <4A0C6BB6-D5F8-47A0-B392-AEBC0859C1FC@aaa-sec.com>  <939935CA-2161-49B8-92D3-FB296CDF4ADE@aaa-sec.com> <7888389D-73C8-49AD-B788-E3886AB9410E@vigilsec.com>
From: Wei Chuang 
Date: Wed, 25 May 2016 10:43:21 -0700
Message-ID: 
To: Russ Housley 
Content-Type: multipart/alternative; boundary=001a113dc862c0bad20533ae352c
Archived-At: 
Cc: spasm@ietf.org, Stefan Santesson 
Subject: Re: [Spasm] draft-housley-spasm-eku-constraints-01.txt
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 25 May 2016 17:43:25 -0000

--001a113dc862c0bad20533ae352c
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On Tue, May 24, 2016 at 1:11 PM, Russ Housley  wrote:

> Stefan:
> ...
> >
> > Those where other times. That was extensions already known to the
> market. And we where more naïve at the time than we are today.
> > We overestimated the value of the features and we underestimated the
> interop challenges.
> > You are of course absolutely right. The only problem is that it may not
> work because it’s a deployment blocker. Who will include an extension that
> guarantees that the certificate will be rejected in all major
> implementations?
>
> Indeed, there are challenges to deploying a critical extension.  A
> significant population of relying parties would need to support it before a
> CA would make use of it.
>
> > I’d make it a CA choice. They can decide whether they can live with the
> risk of clients not getting the extension constraint over the drawback of
> having the certificate rejected in most current clients.
> > This is no worse than it is today. Issuers putting in EKU in CA
> certificates for the purpose of constraining have no guarantee that
> everyone will get it, and obviously they can live with that.
>
> I think you are suggesting:
>
>    This extension MAY, at the option of the certificate issuer, be
>    either critical or non-critical.
>
> If this is the approach supported by otters, then I will make the change.
> It would require a bit of text in the Security Considerations about
> non-critical EKU constraints being ignored by relying parties that do not
> support this extension.
>

I agree allowing for non-critical is a good approach to resolve the
deployment problems that Stefan has pointed out.  Non-critical would assist
bridging a transition.  Also at some future point, its would be possible to
revise again to make this extension critical once a significant population
uses it.


>
> >
> >> Maybe it was not used while you were at Microsoft, but the message to
> the PKIX list that started this discussion shows that the current EKU is
> being used in the same manner as permittedKeyPurposeIds in my proposal.
> Your example about constraining code signing is exactly the reason that I
> included excludedKeyPurposeIds in my proposal.
> >
> > The logic used for code signing only needs the permitted logic.
> Everything not in the permitted group is not permitted.
> > If I need to choose between 2 evils, I’d rather have a simple extension
> making it legal what is already out there, than a new fancy extension that
> is more capable.
>
> I’ve shared my thought process.  What do others think?
>

I think Stefan's simplification would be better for deployment.  There are
already many existing server certificates with intermediate CA EKU
constraints in their path.

-Wei

--001a113dc862c0bad20533ae352c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit




On Tue, May 24, 2016 at 1:11 PM, Russ Housley <housley@vigilsec.com> wrote:
Stefan:
...

>

> Those where other times. That was extensions already known to the market. And we where more naïve at the time than we are today.

> We overestimated the value of the features and we underestimated the interop challenges.

> You are of course absolutely right. The only problem is that it may not work because it’s a deployment blocker. Who will include an extension that guarantees that the certificate will be rejected in all major implementations?



Indeed, there are challenges to deploying a critical extension.  A significant population of relying parties would need to support it before a CA would make use of it.



> I’d make it a CA choice. They can decide whether they can live with the risk of clients not getting the extension constraint over the drawback of having the certificate rejected in most current clients.

> This is no worse than it is today. Issuers putting in EKU in CA certificates for the purpose of constraining have no guarantee that everyone will get it, and obviously they can live with that.



I think you are suggesting:



   This extension MAY, at the option of the certificate issuer, be

   either critical or non-critical.



If this is the approach supported by otters, then I will make the change.  It would require a bit of text in the Security Considerations about non-critical EKU constraints being ignored by relying parties that do not support this extension.

I agree allowing for non-critical is a good approach to resolve the deployment problems that Stefan has pointed out.  Non-critical would assist bridging a transition.  Also at some future point, its would be possible to revise again to make this extension critical once a significant population uses it.
 



>

>> Maybe it was not used while you were at Microsoft, but the message to the PKIX list that started this discussion shows that the current EKU is being used in the same manner as permittedKeyPurposeIds in my proposal.  Your example about constraining code signing is exactly the reason that I included excludedKeyPurposeIds in my proposal.

>

> The logic used for code signing only needs the permitted logic. Everything not in the permitted group is not permitted.

> If I need to choose between 2 evils, I’d rather have a simple extension making it legal what is already out there, than a new fancy extension that is more capable.



I’ve shared my thought process.  What do others think?

I think Stefan's simplification would be better for deployment.  There are already many existing server certificates with intermediate CA EKU constraints in their path.
 
-Wei



--001a113dc862c0bad20533ae352c--


From nobody Wed May 25 11:08:05 2016
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 2CEE012D0AA for ; Wed, 25 May 2016 11:08:03 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, 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 Tw2xVYzdGs6T for ; Wed, 25 May 2016 11:08:01 -0700 (PDT)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (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 450B912D096 for ; Wed, 25 May 2016 11:08:01 -0700 (PDT)
Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 3B941509B6 for ; Wed, 25 May 2016 14:07:59 -0400 (EDT)
To: spasm@ietf.org
References: <20160518171802.14749.72841.idtracker@ietfa.amsl.com>  <4A0C6BB6-D5F8-47A0-B392-AEBC0859C1FC@aaa-sec.com>  <939935CA-2161-49B8-92D3-FB296CDF4ADE@aaa-sec.com> <7888389D-73C8-49AD-B788-E3886AB9410E@vigilsec.com> 
From: Sean Leonard 
Message-ID: 
Date: Wed, 25 May 2016 11:06:45 -0700
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------629BD5874839A0DE746AFFA4"
Archived-At: 
Subject: Re: [Spasm] draft-housley-spasm-eku-constraints-01.txt
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 25 May 2016 18:08:03 -0000

This is a multi-part message in MIME format.
--------------629BD5874839A0DE746AFFA4
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

On 5/25/2016 10:43 AM, Wei Chuang wrote:
>
>
> On Tue, May 24, 2016 at 1:11 PM, Russ Housley  > wrote:
>
>     Stefan:
>     ...
>     >
>     > Those where other times. That was extensions already known to
>     the market. And we where more nave at the time than we are today.
>     > We overestimated the value of the features and we underestimated
>     the interop challenges.
>     > You are of course absolutely right. The only problem is that it
>     may not work because its a deployment blocker. Who will include
>     an extension that guarantees that the certificate will be rejected
>     in all major implementations?
>
>     Indeed, there are challenges to deploying a critical extension.  A
>     significant population of relying parties would need to support it
>     before a CA would make use of it.
>
>     > Id make it a CA choice. They can decide whether they can live
>     with the risk of clients not getting the extension constraint over
>     the drawback of having the certificate rejected in most current
>     clients.
>     > This is no worse than it is today. Issuers putting in EKU in CA
>     certificates for the purpose of constraining have no guarantee
>     that everyone will get it, and obviously they can live with that.
>
>     I think you are suggesting:
>
>        This extension MAY, at the option of the certificate issuer, be
>        either critical or non-critical.
>
>     If this is the approach supported by otters, then I will make the
>     change.  It would require a bit of text in the Security
>     Considerations about non-critical EKU constraints being ignored by
>     relying parties that do not support this extension.
>
>
> I agree allowing for non-critical is a good approach to resolve the 
> deployment problems that Stefan has pointed out.  Non-critical would 
> assist bridging a transition. Also at some future point, its would be 
> possible to revise again to make this extension critical once a 
> significant population uses it.

I support a transitional period baked into the draft, namely, that the 
extension MAY be critical now; SHOULD be critical after time X (2018?), 
and MUST be critical after time Y (2020?).

Perhaps the time should be tied to the certificate issuance artifact, 
namely, where the notBefore date is prior to X, then MAY; if notBefore 
is prior to Y, then SHOULD; if notBefore is after Y, then MUST.

Sean

--------------629BD5874839A0DE746AFFA4
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    
On 5/25/2016 10:43 AM, Wei Chuang
      wrote:

    

    

      


        


          
On Tue, May 24, 2016 at 1:11 PM, Russ
            Housley <housley@vigilsec.com>
            wrote:

            
Stefan:

                ...

                >

                > Those where other times. That was extensions
                already known to the market. And we where more nave at
                the time than we are today.

                > We overestimated the value of the features and we
                underestimated the interop challenges.

                > You are of course absolutely right. The only
                problem is that it may not work because its a
                deployment blocker. Who will include an extension that
                guarantees that the certificate will be rejected in all
                major implementations?

                

              Indeed, there are challenges to deploying a
              critical extension. A significant population of relying
              parties would need to support it before a CA would make
              use of it.

              

                > Id make it a CA choice. They can decide whether
                they can live with the risk of clients not getting the
                extension constraint over the drawback of having the
                certificate rejected in most current clients.

                > This is no worse than it is today. Issuers putting
                in EKU in CA certificates for the purpose of
                constraining have no guarantee that everyone will get
                it, and obviously they can live with that.

                

              I think you are suggesting:

              

               This extension MAY, at the option of the certificate
              issuer, be

               either critical or non-critical.

              

              If this is the approach supported by otters, then I will
              make the change. It would require a bit of text in the
              Security Considerations about non-critical EKU constraints
              being ignored by relying parties that do not support this
              extension.

            

            


            

            
I agree allowing for non-critical is a good approach to
              resolve the deployment problems that Stefan has pointed
              out. Non-critical would assist bridging a transition.
              Also at some future point, its would be possible to revise
              again to make this extension critical once a significant
              population uses it.

          

        

      

    

    

    I support a transitional period baked into the draft, namely, that
    the extension MAY be critical now; SHOULD be critical after time X
    (2018?), and MUST be critical after time Y (2020?).

    

    Perhaps the time should be tied to the certificate issuance
    artifact, namely, where the notBefore date is prior to X, then MAY;
    if notBefore is prior to Y, then SHOULD; if notBefore is after Y,
    then MUST.

    

    Sean
  


--------------629BD5874839A0DE746AFFA4--


From nobody Wed May 25 11:26:10 2016
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 357EA12D8B8 for ; Wed, 25 May 2016 11:26:08 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, 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 afm_oOPoPNoE for ; Wed, 25 May 2016 11:26:05 -0700 (PDT)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (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 5723512D110 for ; Wed, 25 May 2016 11:26:05 -0700 (PDT)
Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 5571B50AA4 for ; Wed, 25 May 2016 14:26:04 -0400 (EDT)
To: spasm@ietf.org
References: <20160525151646.18361.48904.idtracker@ietfa.amsl.com> <3DB53E2C-24FD-4E9C-BAFA-11154501A90C@vigilsec.com>
From: Sean Leonard 
Message-ID: 
Date: Wed, 25 May 2016 11:24:49 -0700
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0
MIME-Version: 1.0
In-Reply-To: <3DB53E2C-24FD-4E9C-BAFA-11154501A90C@vigilsec.com>
Content-Type: multipart/alternative; boundary="------------3B0E5424FBB4E45266F22E99"
Archived-At: 
Subject: Re: [Spasm] New Version Notification for draft-housley-spasm-eku-constraints-02.txt
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 25 May 2016 18:26:08 -0000

This is a multi-part message in MIME format.
--------------3B0E5424FBB4E45266F22E99
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: quoted-printable

Making good progress!

I read the draft.

On 5/25/2016 8:32 AM, Russ Housley wrote:
> 2) The extension syntax is changed to a CHOICE:
>
>        EKUConstraints ::=3D CHOICE {
>            permittedKeyPurposeIds   [0] KeyPurposeIds OPTIONAL,
>            excludedKeyPurposeIds    [1] KeyPurposeIds OPTIONAL }

OPTIONAL is not compatible with CHOICE. It should be:

       EKUConstraints ::=3D CHOICE {
           permittedKeyPurposeIds   [0] KeyPurposeIds,
           excludedKeyPurposeIds    [1] KeyPurposeIds }


This is also a good time to raise the SET vs. SEQUENCE issue.

I believe (firmly, but not going to die over it) that KeyPurposeIDs=20
should be a SET SIZE (1..MAX) OF KeyPurposeId, not SEQUENCE.

A SEQUENCE is ordered. A SET is unordered. In DER, SET gets canonically=20
ordered by the octet representation on the wire. Because we are talking=20
about OBJECT IDENTIFIER, octet representation ordering has the=20
convenient property of being identical to abstract OID ordering. E.g.:

0.0.1
0.0.1.1111
0.0.0.1112
2.14.2
2.14.22222
2.14.22222.333333
2.14.22223

etc.

A long time ago, Peter Gutmann published his X.509 Style Guide=20
. Among other =

things, I recall that it recommends using SEQUENCE instead of SET where=20
possible because of the DER ordering issue.

However, that advice is old. Computers are now much more powerful, and=20
memory is more plentiful. Most importantly, we are talking about a SET=20
OF OIDs, which are fixed and determinable (in both BER and DER=20
encodings). Furthermore, since the algorithm here calls for intersecting =

and union-ing, you can save an ordering/comparison pass for every=20
certificate in the path by ensuring that they are ordered on the wire.=20
Essentially each step with SET requires O(n) instead of SEQUENCE, which=20
requires O(n log n) or in the worst case O(n=B2).

The pile of OIDs is not ordered; neither should be its representation on =

the wire. A compliant parser should reject (i.e., "MUST NOT accept")=20
invalid DER for this extension, because a CA should go to the trouble to =

order it properly with 2016 technology.

I don't know if there is a new ASN.1 constraint that enforces=20
uniqueness. As I understand it, it's possible in theory to put duplicate =

OIDs in the SET OF or SEQUENCE OF. While it is harmless to do so, I=20
would like a constraint expressed in the ASN.1 that makes it a true set, =

not a multiset. (I.e., no duplicates.)


>
> 3) A end entity-certificate does not include an EKU extension is allowe=
d to be used with any key purpose identifier, so a check in the path proc=
essing was added to handle this.

Follow-up question: permittedKeyPurposeIDs can't be 0-length. What if a=20
CA wants to restrict end-entity certificates so that no EKUs can be=20
asserted whatsoever? Is that a valid use case, or not, and why?

(Note: I would propose a different algorithm description but I will=20
leave it for now.)

Sean

>
> Russ
>
>
> On May 25, 2016, at 11:16 AM, internet-drafts@ietf.org wrote:
>
>> A new version of I-D, draft-housley-spasm-eku-constraints-02.txt
>> has been successfully submitted by Russell Housley and posted to the
>> IETF repository.
>>
>> Name:		draft-housley-spasm-eku-constraints
>> Revision:	02
>> Title:		Extended Key Usage Constraints
>> Document date:	2016-05-25
>> Group:		Individual Submission
>> Pages:		9
>> URL:            https://www.ietf.org/internet-drafts/draft-housley-spa=
sm-eku-constraints-02.txt
>> Status:         https://datatracker.ietf.org/doc/draft-housley-spasm-e=
ku-constraints/
>> Htmlized:       https://tools.ietf.org/html/draft-housley-spasm-eku-co=
nstraints-02
>> Diff:           https://www.ietf.org/rfcdiff?url2=3Ddraft-housley-spas=
m-eku-constraints-02
>>
>> Abstract:
>>    This document specifies the extended key usage constraints
>>    certificate extension, which is used to place restrictions on the k=
ey
>>    purpose identifiers that are authorized to appear in the end-entity=

>>    certificate in a certification path.  Restrictions apply to the
>>    extended key usage certificate extension, which is described in
>>    RFC 5280.
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm



--------------3B0E5424FBB4E45266F22E99
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Making good progress!

      

      I read the draft.

      

      On 5/25/2016 8:32 AM, Russ Housley wrote:

    

    

      
2) The extension syntax is changed to a CHOICE:

      EKUConstraints ::= CHOICE {
          permittedKeyPurposeIds   [0] KeyPurposeIds OPTIONAL,
          excludedKeyPurposeIds    [1] KeyPurposeIds OPTIONAL }

    

    

    OPTIONAL is not compatible with CHOICE. It should be:

    

    
      EKUConstraints ::= CHOICE {
          permittedKeyPurposeIds   [0] KeyPurposeIds,
          excludedKeyPurposeIds    [1] KeyPurposeIds }


    

    This is also a good time to raise the SET vs. SEQUENCE issue.

    

    I believe (firmly, but not going to die over it) that KeyPurposeIDs
    should be a SET SIZE (1..MAX) OF KeyPurposeId, not SEQUENCE.

    

    A SEQUENCE is ordered. A SET is unordered. In DER, SET gets
    canonically ordered by the octet representation on the wire. Because
    we are talking about OBJECT IDENTIFIER, octet representation
    ordering has the convenient property of being identical to abstract
    OID ordering. E.g.:

    

    0.0.1

    0.0.1.1111

    0.0.0.1112

    2.14.2

    2.14.22222

    2.14.22222.333333

    2.14.22223

    

    etc.

    

    A long time ago, Peter Gutmann published his X.509 Style Guide
    <https://www.cs.auckland.ac.nz/~pgut001/pubs/x509guide.txt>.
    Among other things, I recall that it recommends using SEQUENCE
    instead of SET where possible because of the DER ordering issue.

    

    However, that advice is old. Computers are now much more powerful,
    and memory is more plentiful. Most importantly, we are talking about
    a SET OF OIDs, which are fixed and determinable (in both BER and DER
    encodings). Furthermore, since the algorithm here calls for
    intersecting and union-ing, you can save an ordering/comparison pass
    for every certificate in the path by ensuring that they are ordered
    on the wire. Essentially each step with SET requires O(n) instead of
    SEQUENCE, which requires O(n log n) or in the worst case O(n).

    

    The pile of OIDs is not ordered; neither should be its
    representation on the wire. A compliant parser should reject (i.e.,
    "MUST NOT accept") invalid DER for this extension, because a CA
    should go to the trouble to order it properly with 2016 technology.

    

    I don't know if there is a new ASN.1 constraint that enforces
    uniqueness. As I understand it, it's possible in theory to put
    duplicate OIDs in the SET OF or SEQUENCE OF. While it is harmless to
    do so, I would like a constraint expressed in the ASN.1 that makes
    it a true set, not a multiset. (I.e., no duplicates.)

    

    

    

      

3) A end entity-certificate does not include an EKU extension is allowed to be used with any key purpose identifier, so a check in the path processing was added to handle this.

    

    

    Follow-up question: permittedKeyPurposeIDs can't be 0-length. What
    if a CA wants to restrict end-entity certificates so that no EKUs
    can be asserted whatsoever? Is that a valid use case, or not, and
    why?

    

    (Note: I would propose a different algorithm description but I will
    leave it for now.)

    

    Sean

    

    

      

Russ


On May 25, 2016, at 11:16 AM, internet-drafts@ietf.org wrote:



      

        
A new version of I-D, draft-housley-spasm-eku-constraints-02.txt
has been successfully submitted by Russell Housley and posted to the
IETF repository.

Name:		draft-housley-spasm-eku-constraints
Revision:	02
Title:		Extended Key Usage Constraints
Document date:	2016-05-25
Group:		Individual Submission
Pages:		9
URL:            https://www.ietf.org/internet-drafts/draft-housley-spasm-eku-constraints-02.txt
Status:         https://datatracker.ietf.org/doc/draft-housley-spasm-eku-constraints/
Htmlized:       https://tools.ietf.org/html/draft-housley-spasm-eku-constraints-02
Diff:           https://www.ietf.org/rfcdiff?url2=draft-housley-spasm-eku-constraints-02

Abstract:
  This document specifies the extended key usage constraints
  certificate extension, which is used to place restrictions on the key
  purpose identifiers that are authorized to appear in the end-entity
  certificate in a certification path.  Restrictions apply to the
  extended key usage certificate extension, which is described in
  RFC 5280.


      

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


    

    


    

  


--------------3B0E5424FBB4E45266F22E99--


From nobody Wed May 25 12:05:47 2016
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 C200C12D0DE for ; Wed, 25 May 2016 12:05:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.899
X-Spam-Level: 
X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VTbn6ITPDwoy for ; Wed, 25 May 2016 12:05:44 -0700 (PDT)
Received: from mail.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 9AD5812D934 for ; Wed, 25 May 2016 12:05:40 -0700 (PDT)
Received: from localhost (ronin.smetech.net [209.135.209.5]) by mail.smetech.net (Postfix) with ESMTP id 6D9CAF240DB; Wed, 25 May 2016 15:05:40 -0400 (EDT)
X-Virus-Scanned: amavisd-new at smetech.net
Received: from mail.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id p9vEVTA24hAC; Wed, 25 May 2016 14:47:57 -0400 (EDT)
Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.smetech.net (Postfix) with ESMTP id 6FB91F240D5; Wed, 25 May 2016 15:05:39 -0400 (EDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_AA9E6053-A1FA-4346-9306-9CE6702CEF96"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Russ Housley 
In-Reply-To: 
Date: Wed, 25 May 2016 15:05:45 -0400
Message-Id: <2975B016-82D3-442E-B569-DE6C93662AAC@vigilsec.com>
References: <20160525151646.18361.48904.idtracker@ietfa.amsl.com> <3DB53E2C-24FD-4E9C-BAFA-11154501A90C@vigilsec.com> 
To: Sean Leonard 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: 
Cc: spasm@ietf.org
Subject: Re: [Spasm] New Version Notification for draft-housley-spasm-eku-constraints-02.txt
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 25 May 2016 19:05:47 -0000

--Apple-Mail=_AA9E6053-A1FA-4346-9306-9CE6702CEF96
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252


On May 25, 2016, at 2:24 PM, Sean Leonard  wrote:

> Making good progress!
>=20
> I read the draft.
>=20
> On 5/25/2016 8:32 AM, Russ Housley wrote:
>> 2) The extension syntax is changed to a CHOICE:
>>=20
>>       EKUConstraints ::=3D CHOICE {
>>           permittedKeyPurposeIds   [0] KeyPurposeIds OPTIONAL,
>>           excludedKeyPurposeIds    [1] KeyPurposeIds OPTIONAL }
>=20
> OPTIONAL is not compatible with CHOICE. It should be:
>=20
>       EKUConstraints ::=3D CHOICE {
>           permittedKeyPurposeIds   [0] KeyPurposeIds,
>           excludedKeyPurposeIds    [1] KeyPurposeIds }

You are correct.  I went too fast in editing.

>=20
> This is also a good time to raise the SET vs. SEQUENCE issue.
>=20
> I believe (firmly, but not going to die over it) that KeyPurposeIDs =
should be a SET SIZE (1..MAX) OF KeyPurposeId, not SEQUENCE.
>=20
> A SEQUENCE is ordered. A SET is unordered. In DER, SET gets =
canonically ordered by the octet representation on the wire. Because we =
are talking about OBJECT IDENTIFIER, octet representation ordering has =
the convenient property of being identical to abstract OID ordering. =
E.g.:
>=20
> 0.0.1
> 0.0.1.1111
> 0.0.0.1112
> 2.14.2
> 2.14.22222
> 2.14.22222.333333
> 2.14.22223
>=20
> etc.

The EKU extension is:

   ExtKeyUsageSyntax ::=3D SEQUENCE SIZE (1..MAX) OF KeyPurposeId

This syntax was used to avoid the sort associated with SET.

I think we want to continue to avoid the sort at encode time, but we =
could certainly ask the CA to populate the sequence in a sorted order.

>=20
> A long time ago, Peter Gutmann published his X.509 Style Guide =
. Among other =
things, I recall that it recommends using SEQUENCE instead of SET where =
possible because of the DER ordering issue.
>=20
> However, that advice is old. Computers are now much more powerful, and =
memory is more plentiful. Most importantly, we are talking about a SET =
OF OIDs, which are fixed and determinable (in both BER and DER =
encodings). Furthermore, since the algorithm here calls for intersecting =
and union-ing, you can save an ordering/comparison pass for every =
certificate in the path by ensuring that they are ordered on the wire. =
Essentially each step with SET requires O(n) instead of SEQUENCE, which =
requires O(n log n) or in the worst case O(n=B2).
>=20
> The pile of OIDs is not ordered; neither should be its representation =
on the wire. A compliant parser should reject (i.e., "MUST NOT accept") =
invalid DER for this extension, because a CA should go to the trouble to =
order it properly with 2016 technology.
>=20
> I don't know if there is a new ASN.1 constraint that enforces =
uniqueness. As I understand it, it's possible in theory to put duplicate =
OIDs in the SET OF or SEQUENCE OF. While it is harmless to do so, I =
would like a constraint expressed in the ASN.1 that makes it a true set, =
not a multiset. (I.e., no duplicates.)

Again, I think we want to continue to avoid the sort at encode time, but =
we could certainly ask the CA to populate the sequence in a sorted =
order.

>=20
>> 3) A end entity-certificate does not include an EKU extension is =
allowed to be used with any key purpose identifier, so a check in the =
path processing was added to handle this.
>=20
> Follow-up question: permittedKeyPurposeIDs can't be 0-length. What if =
a CA wants to restrict end-entity certificates so that no EKUs can be =
asserted whatsoever? Is that a valid use case, or not, and why?

Agree.  The syntax says:

   KeyPurposeIds ::=3D SEQUENCE SIZE (1..MAX) OF KeyPurposeId

So, there must be at least one OID in the sequence.

I=92ll add a sentence to make that clear.

Russ


--Apple-Mail=_AA9E6053-A1FA-4346-9306-9CE6702CEF96
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252


On May 25, 2016, at 2:24 PM, Sean =
Leonard <dev+ietf@seantek.com> =
wrote:


 =20
    
 =20
  

    
Making good progress!

      

      I read the draft.

      

      On 5/25/2016 8:32 AM, Russ Housley wrote:

    

    

      
2) The extension syntax is changed to a CHOICE:

      EKUConstraints ::=3D CHOICE {
          permittedKeyPurposeIds   [0] KeyPurposeIds OPTIONAL,
          excludedKeyPurposeIds    [1] KeyPurposeIds OPTIONAL }

    

    

    OPTIONAL is not compatible with CHOICE. It should be:

    

    
      EKUConstraints ::=3D CHOICE {
          permittedKeyPurposeIds   [0] KeyPurposeIds,
          excludedKeyPurposeIds    [1] KeyPurposeIds }


You are correct.  I went =
too fast in editing.


    

    This is also a good time to raise the SET vs. SEQUENCE issue.

    

    I believe (firmly, but not going to die over it) that KeyPurposeIDs
    should be a SET SIZE (1..MAX) OF KeyPurposeId, not SEQUENCE.

    

    A SEQUENCE is ordered. A SET is unordered. In DER, SET gets
    canonically ordered by the octet representation on the wire. Because
    we are talking about OBJECT IDENTIFIER, octet representation
    ordering has the convenient property of being identical to abstract
    OID ordering. E.g.:

    

    0.0.1

    0.0.1.1111

    0.0.0.1112

    2.14.2

    2.14.22222

    2.14.22222.333333

    2.14.22223

    

    etc.

The EKU extension =
is:

   ExtKeyUsageSyntax ::=3D =
SEQUENCE SIZE (1..MAX) OF KeyPurposeId

This =
syntax was used to avoid the sort associated with =
SET.

I think we want to continue to avoid the =
sort at encode time, but we could certainly ask the CA to populate the =
sequence in a sorted order.


    

    A long time ago, Peter Gutmann published his X.509 Style Guide
    <htt=
ps://www.cs.auckland.ac.nz/~pgut001/pubs/x509guide.txt>.
    Among other things, I recall that it recommends using SEQUENCE
    instead of SET where possible because of the DER ordering issue.

    

    However, that advice is old. Computers are now much more powerful,
    and memory is more plentiful. Most importantly, we are talking about
    a SET OF OIDs, which are fixed and determinable (in both BER and DER
    encodings). Furthermore, since the algorithm here calls for
    intersecting and union-ing, you can save an ordering/comparison pass
    for every certificate in the path by ensuring that they are ordered
    on the wire. Essentially each step with SET requires O(n) instead of
    SEQUENCE, which requires O(n log n) or in the worst case O(n=B2).

    

    The pile of OIDs is not ordered; neither should be its
    representation on the wire. A compliant parser should reject (i.e.,
    "MUST NOT accept") invalid DER for this extension, because a CA
    should go to the trouble to order it properly with 2016 =
technology.

    

    I don't know if there is a new ASN.1 constraint that enforces
    uniqueness. As I understand it, it's possible in theory to put
    duplicate OIDs in the SET OF or SEQUENCE OF. While it is harmless to
    do so, I would like a constraint expressed in the ASN.1 that makes
    it a true set, not a multiset. (I.e., no =
duplicates.)

Again, I think we =
want to continue to avoid the sort at encode time, but we could =
certainly ask the CA to populate the sequence in a sorted =
order.


3) A end entity-certificate does not =
include an EKU extension is allowed to be used with any key purpose =
identifier, so a check in the path processing was added to handle =
this.

    

    

    Follow-up question: permittedKeyPurposeIDs can't be 0-length. What
    if a CA wants to restrict end-entity certificates so that no EKUs
    can be asserted whatsoever? Is that a valid use case, or not, and
    why?

Agree.  The syntax =
says:

   KeyPurposeIds ::=3D =
SEQUENCE SIZE (1..MAX) OF KeyPurposeId

So, =
there must be at least one OID in the =
sequence.

I=92ll add a sentence to make that =
clear.

Russ

=

--Apple-Mail=_AA9E6053-A1FA-4346-9306-9CE6702CEF96--


From nobody Wed May 25 12:16:27 2016
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 50EA312D9AA for ; Wed, 25 May 2016 12:16:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.097
X-Spam-Level: 
X-Spam-Status: No, score=0.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=roberthalf.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 y0UJJKGQkxJt for ; Wed, 25 May 2016 12:16:17 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0089.outbound.protection.outlook.com [207.46.100.89]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6947D12D919 for ; Wed, 25 May 2016 12:16:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=roberthalf.onmicrosoft.com; s=selector1-protiviti-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=9eUtVpvX0iWFTYxe8nieo772XEjXaNuSwV5C8nUzej8=; b=e1mQ2B0ivkNgJ0tHNQYNkKuWhp19Kg++dd1SAzEIeUMBBVGTLZtfPR2JW7GVS3yYYX+LEX66/Kk/WIpc7WMsCIFY/lZzEke4+YraxyLfhp4HVUqSq5r4O0BffqRbvb5p1jewNtTOnNbAB7PfbktturXufEEcsvIivjKn1TBtJwI=
Received: from DM2PR03CA0025.namprd03.prod.outlook.com (10.141.96.24) by BLUPR03MB018.namprd03.prod.outlook.com (10.255.208.40) with Microsoft SMTP Server (TLS) id 15.1.485.9; Wed, 25 May 2016 19:16:14 +0000
Received: from BY2FFO11FD031.protection.gbl (2a01:111:f400:7c0c::190) by DM2PR03CA0025.outlook.office365.com (2a01:111:e400:2428::24) with Microsoft SMTP Server (TLS) id 15.1.501.7 via Frontend Transport; Wed, 25 May 2016 19:16:13 +0000
Authentication-Results: spf=pass (sender IP is 204.75.127.192) smtp.mailfrom=protiviti.com; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=protiviti.com;
Received-SPF: Pass (protection.outlook.com: domain of protiviti.com designates 204.75.127.192 as permitted sender) receiver=protection.outlook.com;  client-ip=204.75.127.192; helo=N1-1EXC-CAS05.na.msds.rhi.com;
Received: from N1-1EXC-CAS05.na.msds.rhi.com (204.75.127.192) by BY2FFO11FD031.mail.protection.outlook.com (10.1.14.196) with Microsoft SMTP Server id 15.1.497.8 via Frontend Transport; Wed, 25 May 2016 19:16:13 +0000
Received: from n1-1exc-cas04.na.msds.rhi.com (10.249.18.24) by N1-1EXC-CAS05.na.msds.rhi.com (10.249.18.72) with Microsoft SMTP Server (TLS) id 14.3.224.2; Wed, 25 May 2016 12:15:35 -0700
Received: from N1-1EXC-MBX02N2.na.msds.rhi.com ([fe80::a1dc:d8a5:84af:3220]) by N1-1EXC-CAS04.na.msds.rhi.com ([fe80::d52:88a9:de4f:7ace%16]) with mapi id 14.03.0224.002; Wed, 25 May 2016 12:15:35 -0700
From: "Brown, Wendy (10421)" 
To: Sean Leonard , "spasm@ietf.org" 
Thread-Topic: [Spasm] New Version Notification for draft-housley-spasm-eku-constraints-02.txt
Thread-Index: AQHRtretNCSqXP3V90Cn9hvAs4mLUJ/KBTmw
Date: Wed, 25 May 2016 19:15:34 +0000
Message-ID: 
References: <20160525151646.18361.48904.idtracker@ietfa.amsl.com> <3DB53E2C-24FD-4E9C-BAFA-11154501A90C@vigilsec.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.249.18.106]
Content-Type: multipart/alternative; boundary="_000_CA2302D370FA394FB7FFCA89421CF613DA2F2F5DN11EXCMBX02N2na_"
MIME-Version: 1.0
X-CFilter-Loop: Proxied
X-EOPAttributedMessage: 0
X-Forefront-Antispam-Report: CIP:204.75.127.192; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10009020)(2980300002)(438002)(189002)(377454003)(199003)(377424004)(24454002)(5004730100002)(11100500001)(5003600100002)(2900100001)(5250100002)(5001770100001)(9686002)(2950100001)(19625215002)(19580405001)(16236675004)(54356999)(55846006)(5008740100001)(50986999)(15650500001)(2906002)(19580395003)(76176999)(33656002)(2501003)(512934002)(2920100001)(5890100001)(15975445007)(87936001)(84326002)(8676002)(230783001)(189998001)(106116001)(16796002)(106466001)(3846002)(575784001)(790700001)(6116002)(586003)(107886002)(8936002)(1220700001)(92566002)(19617315012)(102836003); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR03MB018; H:N1-1EXC-CAS05.na.msds.rhi.com;  FPR:; SPF:Pass; MLV:sfv; MX:1; A:1; LANG:en; 
X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11FD031; 1:D3i96NLOCm0dd+UIgjMrYGLhCQ7tQ7B0vobimIYx77BhYPvwTftaIgFFJXPmsVvAZ1aISMIbLKL7AFtC3JqUeudiINjizwXS154sHN2jckauu0rvHthYMGBdbrXH/CGVA/h7VVvU0gGuCm7Bl8WW5q+Vd7ooj7BuQs8FokkbOcGDd/SDIc7n62HuqFsYkvWzUZdTVzK5d5QOBeOjby77IGhJUQ+bUvxuGWOLb0zMJLdgHb8CgNaqBWg9wDG40icrA3nphhzxGuYDEF+bgeShJbK4UvqIG4/DNsBzBJkFlr2WF+/5g1cZ4bEF9PAwjCEtfpgiSTSxmwMJaXtLa6qc3l6AHOy9Y9QUOT25phUERHeQcbgAylSX9FZhwYqo1wv4ryJpohk7RVdoQcP8B7x/67C4iBLfkvLT6MtqySlWeHNetVAKilfFaqsqHchNMkY+X4UEwI51/IDLWlcW2Zn00u/s7DmVg0+p8WvOZxaZTTg5XmP7Qlih4gaKCLdl1uSm
X-MS-Office365-Filtering-Correlation-Id: e05bf7f0-1715-42b4-038c-08d384d109af
X-Microsoft-Exchange-Diagnostics: 1; BLUPR03MB018; 2:etvem3quwP0VyNgKF3Tfyc0WrtD8ljhzblm/nhzh3B5Bm7PlvF3V7x0xaI6B03hVZejP4kunzsoStaz8l0W1JIB7m98vuWqjlRoKeXXP5uPyQHtjdfEO2jXbC3aaagl9MTAWSU+fSdCvLsv7/l0BGL9PN2dEK0HNoDEXfYBcHpa7xw5i77BwG1/eLIvIEM4z; 3:5cZXOEsk73htdsYEaOVaEsoJb60YaFifCX2zF6G3hzYvfvsifOVbP1K41Z97SRCmUoZdqsGhmRYJmBC/7M+zfOwfwJKE/hmbw1JLsj4wKIjfA3/Fong7ZZRnhFppGVfOZzhUuT5vGmKsU8XPEjJ1CxWFkSENOB1dwEaGOkHtQuYzf+KbEyVTSnzka7P24DjrBvcZCzZktAj+3MJ/sNYBZOjltjkqCjOQqbShTfNuAqINnWAt05UUdFlf/o+K1c9zNmr/O+PeKT6y+hR5GBdt0w==; 25:rbSd8dLNhCT9RebudchU8QmZ2plcKHaj0LKoo74zkM6wJxYvUIDXQZuIZZRYOIRZ/JYNtjMq0t+8Lm0SBVmX7M3+g36xs98T2KZEQsVQL6+FyZazr0hazTDLGhTpNvdyLlx8oNGjDTpdAiL3wJKW8JtBrmjQqOOiA03R7CtUU8Pq5SkL+HrdzUVh/ZYQWtTMcKITeNZF3XDf7jQYeUfNcBL8MZjCueNfoLWyUEiUepw1+5MS3M6a+ydioxEzCSHQ3lA9XvaYrHc0CtO8qPFEG7t7JUdmjJZEBuDd1lqBYfnpk8CF8rJCN6JBNiKnWDfVi0Q06EioUfxkj5A0D/lD2n9rZSAUFehoH+24euCytqfSDllgk4ELS6ZZgi3zv+KcWJbIDQIv7MjYu9mX/KrZbfNbUou0V6oBTi7d4gV6lFw=
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(8251501002); SRVR:BLUPR03MB018; 
X-Microsoft-Exchange-Diagnostics: 1; BLUPR03MB018; 20:b/fId1Id8P9sng5Fwb2/UA0VLg44WIKd71906dFyG31Wcyzq3tlaXaEEJUKJOLhwXq7v3ohjHUHS+iQbtCO5Y9aQOzhgDEgyJyimANdh5VBi3mGwwZa0hTEbTG3I/R61xROMCyNqcPs8iG/I3D+Nh5x6/vOxlT3BtEJGmk1LWI8n2UlowZtdiw/Il4cpqyX1CSECQBGUI9nATGD/j6ixPAdTyHeVI3ra1lPy1Y09+0j9o9bI5AO7mHTYRkNqsJJNFz130FPye8YKfbCpq3FJUwHERN0vepcde35Z04rlGp0EYxAsSaMOAuv09OSW6m5Clyl6Hv4KczdrKkdNLkvY84WBNGXz3wyB+xgHv4T6dZzG04Y+6meY0p5PPAKIQTu1lSgv34nnO+s85qrvPFG7mpKiGoUv+LMLY3/FDPVCGk9nsoGxMLW+FZJerFG2ufbVK132WHopxVQ+Ra7KzH9/Lg3sRUcHogPgcmHp1qmScWHNAIwycKAgBugPfdgvafW8
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:;
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(13023025)(5005006)(13024025)(13016025)(13018025)(8121501046)(3002001)(10201501046)(6055026); SRVR:BLUPR03MB018; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB018; 
X-Microsoft-Exchange-Diagnostics: 1; BLUPR03MB018; 4:tHk/1D060Jb5xSXELI0n07Kgfq0qpTgt09Q+j6lpFf+idxCY20JOuIeFHBEyEGzhB6zOWKhr64mX05Bgmy1DlH8S/OuuI7NmVPZAwLfsLpoPuaLfKe8NFfiJN+YnH7kn0QXw6vEkFo0dH0JThiLaHkqxFIfXzUdqUePxQJPSXk4wdVIr7m+WF1kpFG1KnpE3bkVbB1uSbG8VKvf71Ep0mr6lq+7tbdZyZvvZ73uC6q8FecFkPrI52D/exomcFyoUeFHFJime/xmVDBPgpCxY2SU/aMbCYyCPWbvZDWmjMdG0na76tA+oKjwKv9Hc0T0vyug+R614cqTK5/xe658RBT7k8WwiL42vdG4wI+IOgDiLgl6eVYzeZEaJRT8an5CF8oocgfgBJGNQTt2rhL5nYjSFiJ0/b0VP95AND24zEXuUpRU+qcX+9OP/Q8HCVX3NsF3Q0rUDo1eaVituWHPutw==
X-Forefront-PRVS: 09538D3531
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BLUPR03MB018; 23:HOSVyrU+5S07rUyE4CjueY44Mdud/SeNGZeAR7TJzQ?= =?us-ascii?Q?t0LuPk1zqLsNiUQsJ1lpPp6iNfKk5Jt6y3iMaee/eZn0UMFzNpdMo785gHeS?= =?us-ascii?Q?5TyXqIRGKkj8wzvEpH1J5U3M37BXVM2G89SpUd+nysNdvK7ofiPq9NjGftLy?= =?us-ascii?Q?o6boM3AH1cwe9uEqrrKTClF4SZZLc6JwtMMrJP/bx19iZlNwMQ3mCGRzqMA9?= =?us-ascii?Q?ZU/X+h5FZwt+m4yi8vL2p1gXwHOZy6N5rc1fSOJO6hyRuR4Z9hFqHnxUOspN?= =?us-ascii?Q?q4mGoXktRJqFKZXXTXgc4apesi+YnsBPiogL17xAQJEDORtQZhhLcDsYTReB?= =?us-ascii?Q?r8MTDu2q07ytsJDBrG2iXdm0GcqoI3+edtukxg1N1xH8FiVGWb7t79R6RVxN?= =?us-ascii?Q?DV29YtSXeDrHdCaTCZGBvYjFHaWk5SPThxU5GAWzncnqEbIEXFUcb7XVuzT4?= =?us-ascii?Q?R75zDQP6iJ0eiFdNZtcMwNckH2MkFEAn3KqsBEbuODwcfLRI66vqKEoWQ9hX?= =?us-ascii?Q?25np43Mm3fpds02sRydmFsJmG7frsKWe12mcZpllU7+UaxI+JYZprbzKfGv5?= =?us-ascii?Q?yporsrTJJfpvbSZghPPphcdbrP9ayJuhUNjD20HNDoIvhb6FCBwJjpcUl3Iy?= =?us-ascii?Q?OXDZEYAUHZXJw+VYeHghOMZAMtjwziYQUKwrLf1PGpq3GTJBMA1bhbbP7elf?= =?us-ascii?Q?JezGgyaYS4gnnie/Q3UMa7hFA1WnlhyNd4ZSm5YRXyM0mQe6RakuAlM31KW5?= =?us-ascii?Q?sMT6OjkHlChzdhEv2rFN4WXfKJ6Y9V6a3v1fso3wrD8JAvJrKXpMz4fOPYQv?= =?us-ascii?Q?oBCf40/RF6UafmFiMI8GrlpYY7ERPAcvxKq6Gzj03ZZNxkJ49/c9gzRaCwNh?= =?us-ascii?Q?YHQaiJBd25z0dngkQEG/6mlL0MOqA9ZtO7X0i4DvJl8elXt4xisG9SQRu9mC?= =?us-ascii?Q?h8kFsun2bGYjAtWgrFX6qmi7LlY6jLb8/kous10fQuOSo0L4WRz8DJWVvfoW?= =?us-ascii?Q?64PdcG2syQlSI9cXrjVj2fAioN33akSVeOSAsHekNjFS/miEDLRFI6EfbB0b?= =?us-ascii?Q?qpOWx6rFYdQBTp7Lcsdrqap0J849oBVGzfoXDCpkMRUrKFVQvhfHl1XVdjp2?= =?us-ascii?Q?t0lUpIyjfiYgOwn7rUc5r/gur/RFlN0fiaFsuS9hG2zJOm0Vt9xSRNVYu17r?= =?us-ascii?Q?XZlJ0yHSUDyqCQy81z+ai0txBMtgQZ1DNfzMrpUkAe1cDSNzVL+jIWJGpufK?= =?us-ascii?Q?LUWx5rDZBwKe1VmSrVf87kqfRgZDKp9FtkX+vUWlTMg652WASoJmq1dfc86O?= =?us-ascii?Q?bdYJhJF8Y+PQj2m7fEoeBJPEi6wFuM2KkzAB7a9izhliDN/RwXbzuMbuSy7T?= =?us-ascii?Q?ZLFQ=3D=3D?=
X-Microsoft-Exchange-Diagnostics: 1; BLUPR03MB018; 5:ZePEm4XnJDxAfVVypeJHamNnQDFFpdMnNYgeIs//NuHfHwgaM/C9Ner2CEijFRrH/aZEpbUQ5UuxIIjLuY26xvatnJPTT9GK0CQG9dKvpMPOSie3a1qf6TjsDLLQdCPCwRjgtn4wPX4FBRXSwAkZzw==; 24:100Q2ESciO62BNFW+GR09SwfU/7aGX9s3imURKYnfVM+WaOymmwRPrRw3kBvF6T+bKmHtVAyUStcB4xzC0gQ+IoL1laWOIqtACqCQ7ISvVM=; 7:otO4supRQJqU+yUq04vEe3iND7RYCiJCgWywEO8XlJtRYnt5WFZ+ftgKtigbNbdtFk64ImytQQQp35mIBgtxfm4LhGGM85nIT5zXxxEAhThb6Pggb+ZwuAJt1h8npwOqs943ezetFnm0lqExbA1Zj/rMsIaOYz4ONH3n2YCsCFbgq8ci+NoWjECAinTXb8Yg; 20:n4P4xM1E8v5HqFiwWgFmiAxn+32+u3r2bzuGwfn5ygGItbNKm0XutTdsWZWPgxrOcYoKDRg6+r/nZbgNlaPPe0zZG4aPTDbvRunsc7tfhj2A2NA3v4ydoJg0wrSQPeMGqRm2juILIeie3fb8aIeGJZXtdzc1WKSOVgZTsxMS4ZY=
SpamDiagnosticOutput: 1:23
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: protiviti.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 May 2016 19:16:13.3307 (UTC)
X-MS-Exchange-CrossTenant-Id: 16532572-d567-4d67-8727-f12f7bb6aed3
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=16532572-d567-4d67-8727-f12f7bb6aed3; Ip=[204.75.127.192];  Helo=[N1-1EXC-CAS05.na.msds.rhi.com]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB018
Archived-At: 
Subject: Re: [Spasm] New Version Notification for draft-housley-spasm-eku-constraints-02.txt
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 25 May 2016 19:16:22 -0000

--_000_CA2302D370FA394FB7FFCA89421CF613DA2F2F5DN11EXCMBX02N2na_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Just a question -
if Optional is not compatible with CHOICE does that mean if CHOICE is speci=
fied you cannot include both choices?

And I do agree that the KeyPurposeIds should be a SET rather than a SEQUENC=
E.

From: Sean Leonard [mailto:dev+ietf@seantek.com]
Sent: Wednesday, May 25, 2016 2:25 PM
To: spasm@ietf.org
Subject: Re: [Spasm] New Version Notification for draft-housley-spasm-eku-c=
onstraints-02.txt

Making good progress!

I read the draft.

On 5/25/2016 8:32 AM, Russ Housley wrote:

2) The extension syntax is changed to a CHOICE:



      EKUConstraints ::=3D CHOICE {

          permittedKeyPurposeIds   [0] KeyPurposeIds OPTIONAL,

          excludedKeyPurposeIds    [1] KeyPurposeIds OPTIONAL }

OPTIONAL is not compatible with CHOICE. It should be:



      EKUConstraints ::=3D CHOICE {

          permittedKeyPurposeIds   [0] KeyPurposeIds,

          excludedKeyPurposeIds    [1] KeyPurposeIds }

This is also a good time to raise the SET vs. SEQUENCE issue.

I believe (firmly, but not going to die over it) that KeyPurposeIDs should =
be a SET SIZE (1..MAX) OF KeyPurposeId, not SEQUENCE.

A SEQUENCE is ordered. A SET is unordered. In DER, SET gets canonically ord=
ered by the octet representation on the wire. Because we are talking about =
OBJECT IDENTIFIER, octet representation ordering has the convenient propert=
y of being identical to abstract OID ordering. E.g.:

0.0.1
0.0.1.1111
0.0.0.1112
2.14.2
2.14.22222
2.14.22222.333333
2.14.22223

etc.

A long time ago, Peter Gutmann published his X.509 Style Guide . Among othe=
r things, I recall that it recommends using SEQUENCE instead of SET where p=
ossible because of the DER ordering issue.

However, that advice is old. Computers are now much more powerful, and memo=
ry is more plentiful. Most importantly, we are talking about a SET OF OIDs,=
 which are fixed and determinable (in both BER and DER encodings). Furtherm=
ore, since the algorithm here calls for intersecting and union-ing, you can=
 save an ordering/comparison pass for every certificate in the path by ensu=
ring that they are ordered on the wire. Essentially each step with SET requ=
ires O(n) instead of SEQUENCE, which requires O(n log n) or in the worst ca=
se O(n=B2).

The pile of OIDs is not ordered; neither should be its representation on th=
e wire. A compliant parser should reject (i.e., "MUST NOT accept") invalid =
DER for this extension, because a CA should go to the trouble to order it p=
roperly with 2016 technology.

I don't know if there is a new ASN.1 constraint that enforces uniqueness. A=
s I understand it, it's possible in theory to put duplicate OIDs in the SET=
 OF or SEQUENCE OF. While it is harmless to do so, I would like a constrain=
t expressed in the ASN.1 that makes it a true set, not a multiset. (I.e., n=
o duplicates.)








3) A end entity-certificate does not include an EKU extension is allowed to=
 be used with any key purpose identifier, so a check in the path processing=
 was added to handle this.

Follow-up question: permittedKeyPurposeIDs can't be 0-length. What if a CA =
wants to restrict end-entity certificates so that no EKUs can be asserted w=
hatsoever? Is that a valid use case, or not, and why?

(Note: I would propose a different algorithm description but I will leave i=
t for now.)

Sean







Russ





On May 25, 2016, at 11:16 AM, internet-drafts@ietf.org wrote:



A new version of I-D, draft-housley-spasm-eku-constraints-02.txt

has been successfully submitted by Russell Housley and posted to the

IETF repository.



Name:              draft-housley-spasm-eku-constraints

Revision:  02

Title:             Extended Key Usage Constraints

Document date:     2016-05-25

Group:             Individual Submission

Pages:             9

URL:            https://www.ietf.org/internet-drafts/draft-housley-spasm-ek=
u-constraints-02.txt

Status:         https://datatracker.ietf.org/doc/draft-housley-spasm-eku-co=
nstraints/

Htmlized:       https://tools.ietf.org/html/draft-housley-spasm-eku-constra=
ints-02

Diff:           https://www.ietf.org/rfcdiff?url2=3Ddraft-housley-spasm-eku=
-constraints-02



Abstract:

  This document specifies the extended key usage constraints

  certificate extension, which is used to place restrictions on the key

  purpose identifiers that are authorized to appear in the end-entity

  certificate in a certification path.  Restrictions apply to the

  extended key usage certificate extension, which is described in

  RFC 5280.



_______________________________________________

Spasm mailing list

Spasm@ietf.org

https://www.ietf.org/mailman/listinfo/spasm



NOTICE: Protiviti is a global consulting and internal audit firm composed o=
f experts specializing in risk and advisory services. Protiviti is not lice=
nsed or registered as a public accounting firm and does not issue opinions =
on financial statements or offer attestation services. This electronic mail=
 message is intended exclusively for the individual or entity to which it i=
s addressed. This message, together with any attachment, may contain confid=
ential and privileged information. Any views, opinions or conclusions expre=
ssed in this message are those of the individual sender and do not necessar=
ily reflect the views of Protiviti Inc. or its affiliates. Any unauthorized=
 review, use, printing, copying, retention, disclosure or distribution is s=
trictly prohibited. If you have received this message in error, please imme=
diately advise the sender by reply email message to the sender and delete a=
ll copies of this message. Thank you.

--_000_CA2302D370FA394FB7FFCA89421CF613DA2F2F5DN11EXCMBX02N2na_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Just a question –



if Optional is not compatible with CH=
OICE does that mean if CHOICE is specified you cannot include both choices?=



 


And I do agree that the KeyPurposeIds=
 should be a SET rather than a SEQUENCE.


&nbs=
p;






From: Sean Leonard [mailto:dev+ietf@seantek.com]


Sent: Wednesday, May 25, 2016 2:25 PM

To: spasm@ietf.org

Subject: Re: [Spasm] New Version Notification for draft-housley-spas=
m-eku-constraints-02.txt






 




Making good progress!



I read the draft.



On 5/25/2016 8:32 AM, Russ Housley wrote:






2) The extension syntax is changed to a CHOICE:


 


      EKUConstraints ::=3D CHOICE {


          permittedKeyPur=
poseIds   [0] KeyPurposeIds OPTIONAL,


          excludedKeyPurp=
oseIds    [1] KeyPurposeIds OPTIONAL }






OPTIONAL is not compatible with CHOICE. It should be:








      EKUC=
onstraints ::=3D CHOICE {


      =
;    permittedKeyPurposeIds   [0] KeyPurposeIds,


      =
;    excludedKeyPurposeIds    [1] KeyPurposeI=
ds }




This is also a good time to raise the SET vs. SEQUENCE issue.



I believe (firmly, but not going to die over it) that KeyPurposeIDs should =
be a SET SIZE (1..MAX) OF KeyPurposeId, not SEQUENCE.



A SEQUENCE is ordered. A SET is unordered. In DER, SET gets canonically ord=
ered by the octet representation on the wire. Because we are talking about =
OBJECT IDENTIFIER, octet representation ordering has the convenient propert=
y of being identical to abstract
 OID ordering. E.g.:



0.0.1

0.0.1.1111

0.0.0.1112

2.14.2

2.14.22222

2.14.22222.333333

2.14.22223



etc.



A long time ago, Peter Gutmann published his X.509 Style Guide 
<https://www.cs.auckland.ac.nz/~pgut001/pubs/x509guide.txt>. Amon=
g other things, I recall that it recommends using SEQUENCE instead of SET w=
here possible because of the DER ordering issue.



However, that advice is old. Computers are now much more powerful, and memo=
ry is more plentiful. Most importantly, we are talking about a SET OF OIDs,=
 which are fixed and determinable (in both BER and DER encodings). Furtherm=
ore, since the algorithm here calls
 for intersecting and union-ing, you can save an ordering/comparison pass f=
or every certificate in the path by ensuring that they are ordered on the w=
ire. Essentially each step with SET requires O(n) instead of SEQUENCE, whic=
h requires O(n log n) or in the
 worst case O(n=B2).



The pile of OIDs is not ordered; neither should be its representation on th=
e wire. A compliant parser should reject (i.e., "MUST NOT accept"=
) invalid DER for this extension, because a CA should go to the trouble to =
order it properly with 2016 technology.



I don't know if there is a new ASN.1 constraint that enforces uniqueness. A=
s I understand it, it's possible in theory to put duplicate OIDs in the SET=
 OF or SEQUENCE OF. While it is harmless to do so, I would like a constrain=
t expressed in the ASN.1 that makes
 it a true set, not a multiset. (I.e., no duplicates.)












 


 


3) A end entity-certificate does not include an EKU extension is allow=
ed to be used with any key purpose identifier, so a check in the path proce=
ssing was added to handle this.






Follow-up question: permittedKeyPurposeIDs can't be 0-length. What if a CA =
wants to restrict end-entity certificates so that no EKUs can be asserted w=
hatsoever? Is that a valid use case, or not, and why?



(Note: I would propose a different algorithm description but I will leave i=
t for now.)



Sean










 


 


Russ


 


 


On May 25, 2016, at 11:16 AM, internet-drafts@ietf.org wrote:


 




A new version of I-D, draft-housley-spasm-eku-constraints-02.txt<=
/o:p>


has been successfully submitted by Russell Housley and posted to the


IETF repository.


 


Name:           =
;   draft-housley-spasm-eku-constraints


Revision:  02


Title:          &nbs=
p;  Extended Key Usage Constraints


Document date:     2016-05-25


Group:          &nbs=
p;  Individual Submission


Pages:          &nbs=
p;  9


URL:           =
 https://www.ietf.org/internet-drafts/draft-housley-spasm-eku-con=
straints-02.txt


Status:         https://datatracke=
r.ietf.org/doc/draft-housley-spasm-eku-constraints/


Htmlized:       https://tools.ietf.org/html/dra=
ft-housley-spasm-eku-constraints-02


Diff:           h=
ttps://www.ietf.org/rfcdiff?url2=3Ddraft-housley-spasm-eku-constraints-02


 


Abstract:


  This document specifies the extended key usage constraints=



  certificate extension, which is used to place restrictions on t=
he key


  purpose identifiers that are authorized to appear in the end-en=
tity


  certificate in a certification path.  Restrictions apply t=
o the


  extended key usage certificate extension, which is described in=



  RFC 5280.




 


_______________________________________________


Spasm mailing list


Spasm@ietf.org


https://www.ietf.org/mailman/listin=
fo/spasm




 



NOTICE: Protiviti is a global consulting and internal audit firm composed o=
f experts specializing in risk and advisory services. Protiviti is not lice=
nsed or registered as a public accounting firm and does not issue opinions =
on financial statements or offer
 attestation services. This electronic mail message is intended exclusively=
 for the individual or entity to which it is addressed. This message, toget=
her with any attachment, may contain confidential and privileged informatio=
n. Any views, opinions or conclusions
 expressed in this message are those of the individual sender and do not ne=
cessarily reflect the views of Protiviti Inc. or its affiliates. Any unauth=
orized review, use, printing, copying, retention, disclosure or distributio=
n is strictly prohibited. If you
 have received this message in error, please immediately advise the sender =
by reply email message to the sender and delete all copies of this message.=
 Thank you.



--_000_CA2302D370FA394FB7FFCA89421CF613DA2F2F5DN11EXCMBX02N2na_--


From nobody Wed May 25 12:22:01 2016
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 9071D12D992 for ; Wed, 25 May 2016 12:22:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.9
X-Spam-Level: 
X-Spam-Status: No, score=-99.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, T_KAM_HTML_FONT_INVALID=0.01, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MBDSnDqrhdTz for ; Wed, 25 May 2016 12:21:58 -0700 (PDT)
Received: from mail.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 68A6112D14A for ; Wed, 25 May 2016 12:21:58 -0700 (PDT)
Received: from localhost (ronin.smetech.net [209.135.209.5]) by mail.smetech.net (Postfix) with ESMTP id 5FECDF240C8; Wed, 25 May 2016 15:21:58 -0400 (EDT)
X-Virus-Scanned: amavisd-new at smetech.net
Received: from mail.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id Mog2f36-v96h; Wed, 25 May 2016 15:04:14 -0400 (EDT)
Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.smetech.net (Postfix) with ESMTP id E75E0F2406E; Wed, 25 May 2016 15:21:56 -0400 (EDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_47EA0DD3-D96E-4292-937F-BF6A2394E45A"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Russ Housley 
In-Reply-To: 
Date: Wed, 25 May 2016 15:22:03 -0400
Message-Id: 
References: <20160525151646.18361.48904.idtracker@ietfa.amsl.com> <3DB53E2C-24FD-4E9C-BAFA-11154501A90C@vigilsec.com>  
To: "Brown, Wendy (10421)" 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: 
Cc: "spasm@ietf.org" 
Subject: Re: [Spasm] New Version Notification for draft-housley-spasm-eku-constraints-02.txt
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 25 May 2016 19:22:00 -0000

--Apple-Mail=_47EA0DD3-D96E-4292-937F-BF6A2394E45A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

The syntax that I proposed in -01 allowed both to be specified.  Several =
people commented that a CA would only need one or the other, so I =
changed it to a CHOICE.  If you see a case where a CA would need both, =
please say so.

Russ


On May 25, 2016, at 3:15 PM, Brown, Wendy (10421) =
 wrote:

> Just a question =96
> if Optional is not compatible with CHOICE does that mean if CHOICE is =
specified you cannot include both choices?
> =20
> And I do agree that the KeyPurposeIds should be a SET rather than a =
SEQUENCE.
> =20
> From: Sean Leonard [mailto:dev+ietf@seantek.com]=20
> Sent: Wednesday, May 25, 2016 2:25 PM
> To: spasm@ietf.org
> Subject: Re: [Spasm] New Version Notification for =
draft-housley-spasm-eku-constraints-02.txt
> =20
> Making good progress!
>=20
> I read the draft.
>=20
> On 5/25/2016 8:32 AM, Russ Housley wrote:
> 2) The extension syntax is changed to a CHOICE:
> =20
>       EKUConstraints ::=3D CHOICE {
>           permittedKeyPurposeIds   [0] KeyPurposeIds OPTIONAL,
>           excludedKeyPurposeIds    [1] KeyPurposeIds OPTIONAL }
>=20
> OPTIONAL is not compatible with CHOICE. It should be:
>=20
>=20
>       EKUConstraints ::=3D CHOICE {
>           permittedKeyPurposeIds   [0] KeyPurposeIds,
>           excludedKeyPurposeIds    [1] KeyPurposeIds }
>=20
> This is also a good time to raise the SET vs. SEQUENCE issue.
>=20
> I believe (firmly, but not going to die over it) that KeyPurposeIDs =
should be a SET SIZE (1..MAX) OF KeyPurposeId, not SEQUENCE.
>=20
> A SEQUENCE is ordered. A SET is unordered. In DER, SET gets =
canonically ordered by the octet representation on the wire. Because we =
are talking about OBJECT IDENTIFIER, octet representation ordering has =
the convenient property of being identical to abstract OID ordering. =
E.g.:
>=20
> 0.0.1
> 0.0.1.1111
> 0.0.0.1112
> 2.14.2
> 2.14.22222
> 2.14.22222.333333
> 2.14.22223
>=20
> etc.
>=20
> A long time ago, Peter Gutmann published his X.509 Style Guide =
. Among other =
things, I recall that it recommends using SEQUENCE instead of SET where =
possible because of the DER ordering issue.
>=20
> However, that advice is old. Computers are now much more powerful, and =
memory is more plentiful. Most importantly, we are talking about a SET =
OF OIDs, which are fixed and determinable (in both BER and DER =
encodings). Furthermore, since the algorithm here calls for intersecting =
and union-ing, you can save an ordering/comparison pass for every =
certificate in the path by ensuring that they are ordered on the wire. =
Essentially each step with SET requires O(n) instead of SEQUENCE, which =
requires O(n log n) or in the worst case O(n=B2).
>=20
> The pile of OIDs is not ordered; neither should be its representation =
on the wire. A compliant parser should reject (i.e., "MUST NOT accept") =
invalid DER for this extension, because a CA should go to the trouble to =
order it properly with 2016 technology.
>=20
> I don't know if there is a new ASN.1 constraint that enforces =
uniqueness. As I understand it, it's possible in theory to put duplicate =
OIDs in the SET OF or SEQUENCE OF. While it is harmless to do so, I =
would like a constraint expressed in the ASN.1 that makes it a true set, =
not a multiset. (I.e., no duplicates.)
>=20
>=20
>=20
> =20
> =20
> 3) A end entity-certificate does not include an EKU extension is =
allowed to be used with any key purpose identifier, so a check in the =
path processing was added to handle this.
>=20
> Follow-up question: permittedKeyPurposeIDs can't be 0-length. What if =
a CA wants to restrict end-entity certificates so that no EKUs can be =
asserted whatsoever? Is that a valid use case, or not, and why?
>=20
> (Note: I would propose a different algorithm description but I will =
leave it for now.)
>=20
> Sean
>=20
>=20
> =20
> =20
> Russ
> =20
> =20
> On May 25, 2016, at 11:16 AM, internet-drafts@ietf.org wrote:
> =20
> A new version of I-D, draft-housley-spasm-eku-constraints-02.txt
> has been successfully submitted by Russell Housley and posted to the
> IETF repository.
> =20
> Name:              draft-housley-spasm-eku-constraints
> Revision:  02
> Title:             Extended Key Usage Constraints
> Document date:     2016-05-25
> Group:             Individual Submission
> Pages:             9
> URL:            =
https://www.ietf.org/internet-drafts/draft-housley-spasm-eku-constraints-0=
2.txt
> Status:         =
https://datatracker.ietf.org/doc/draft-housley-spasm-eku-constraints/
> Htmlized:       =
https://tools.ietf.org/html/draft-housley-spasm-eku-constraints-02
> Diff:           =
https://www.ietf.org/rfcdiff?url2=3Ddraft-housley-spasm-eku-constraints-02=

> =20
> Abstract:
>   This document specifies the extended key usage constraints
>   certificate extension, which is used to place restrictions on the =
key
>   purpose identifiers that are authorized to appear in the end-entity
>   certificate in a certification path.  Restrictions apply to the
>   extended key usage certificate extension, which is described in
>   RFC 5280.
> =20
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm
> =20
>=20
> NOTICE: Protiviti is a global consulting and internal audit firm =
composed of experts specializing in risk and advisory services. =
Protiviti is not licensed or registered as a public accounting firm and =
does not issue opinions on financial statements or offer attestation =
services. This electronic mail message is intended exclusively for the =
individual or entity to which it is addressed. This message, together =
with any attachment, may contain confidential and privileged =
information. Any views, opinions or conclusions expressed in this =
message are those of the individual sender and do not necessarily =
reflect the views of Protiviti Inc. or its affiliates. Any unauthorized =
review, use, printing, copying, retention, disclosure or distribution is =
strictly prohibited. If you have received this message in error, please =
immediately advise the sender by reply email message to the sender and =
delete all copies of this message. Thank you. =
_______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm


--Apple-Mail=_47EA0DD3-D96E-4292-937F-BF6A2394E45A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

The =
syntax that I proposed in -01 allowed both to be specified. =
 Several people commented that a CA would only need one or the =
other, so I changed it to a CHOICE.  If you see a case where a CA =
would need both, please say =
so.

Russ


On =
May 25, 2016, at 3:15 PM, Brown, Wendy (10421) <wendy.brown@protiviti.com>=
; wrote:

Just a question =
=96
if Optional is not compatible with CHOICE does that =
mean if CHOICE is specified you cannot include both =
choices?
 
And I do agree that the KeyPurposeIds should be a SET =
rather than a SEQUENCE.
From: Sean Leonard [mailto:dev+ietf@seantek.com] 
Sent: Wednesday, May 25, 2016 =
2:25 PM
To: spasm@ietf.org
Subject: Re: [Spasm] New Version =
Notification for =
draft-housley-spasm-eku-constraints-02.txt
 
Making good progress!

I read the =
draft.

On 5/25/2016 8:32 AM, Russ Housley =
wrote:
2) The extension syntax is changed to =
a CHOICE:
 
      EKUConstraints ::=3D CHOICE =
{
          =
permittedKeyPurposeIds   [0] KeyPurposeIds =
OPTIONAL,
          =
excludedKeyPurposeIds    [1] KeyPurposeIds OPTIONAL =
}

OPTIONAL is =
not compatible with CHOICE. It should =
be:


      EKUConstraints ::=3D CHOICE =
{
          =
permittedKeyPurposeIds   [0] =
KeyPurposeIds,
          =
excludedKeyPurposeIds    [1] KeyPurposeIds =
}

This is also a good =
time to raise the SET vs. SEQUENCE issue.

I believe (firmly, but =
not going to die over it) that KeyPurposeIDs should be a SET SIZE =
(1..MAX) OF KeyPurposeId, not SEQUENCE.

A SEQUENCE is ordered. A =
SET is unordered. In DER, SET gets canonically ordered by the octet =
representation on the wire. Because we are talking about OBJECT =
IDENTIFIER, octet representation ordering has the convenient property of =
being identical to abstract OID ordering. =
E.g.:

0.0.1
0.0.1.1111
0.0.0.1112
2.14.2
2.14.22222
=
2.14.22222.333333
2.14.22223

etc.

A long time ago, =
Peter Gutmann published his X.509 Style Guide <https://www.cs.auckland.ac.nz/~pgut001/pubs/x509guide.txt&=
gt;. Among other things, I recall that it recommends using SEQUENCE =
instead of SET where possible because of the DER ordering =
issue.

However, that advice is old. Computers are now much more =
powerful, and memory is more plentiful. Most importantly, we are talking =
about a SET OF OIDs, which are fixed and determinable (in both BER and =
DER encodings). Furthermore, since the algorithm here calls for =
intersecting and union-ing, you can save an ordering/comparison pass for =
every certificate in the path by ensuring that they are ordered on the =
wire. Essentially each step with SET requires O(n) instead of SEQUENCE, =
which requires O(n log n) or in the worst case O(n=B2).

The pile =
of OIDs is not ordered; neither should be its representation on the =
wire. A compliant parser should reject (i.e., "MUST NOT accept") invalid =
DER for this extension, because a CA should go to the trouble to order =
it properly with 2016 technology.

I don't know if there is a new =
ASN.1 constraint that enforces uniqueness. As I understand it, it's =
possible in theory to put duplicate OIDs in the SET OF or SEQUENCE OF. =
While it is harmless to do so, I would like a constraint expressed in =
the ASN.1 that makes it a true set, not a multiset. (I.e., no =
duplicates.)



 
 
3) A end =
entity-certificate does not include an EKU extension is allowed to be =
used with any key purpose identifier, so a check in the path processing =
was added to handle this.

Follow-up question: permittedKeyPurposeIDs can't =
be 0-length. What if a CA wants to restrict end-entity certificates so =
that no EKUs can be asserted whatsoever? Is that a valid use case, or =
not, and why?

(Note: I would propose a different algorithm =
description but I will leave it for =
now.)

Sean


 
 
Russ
 
 
On May 25, 2016, at 11:16 =
AM, internet-drafts@ietf.org =
wrote:
 
A new version of I-D, =
draft-housley-spasm-eku-constraints-02.txt
has been successfully submitted by Russell Housley and =
posted to the
IETF =
repository.
 
Name:          &n=
bsp;   =
draft-housley-spasm-eku-constraints
Revision:  02
Title:          &=
nbsp;  Extended Key Usage Constraints
Document date:     =
2016-05-25
Group:          &=
nbsp;  Individual Submission
Pages:          &=
nbsp;  9
URL:          &nb=
sp; https://www.ietf.org/internet-drafts/draft-housley-spasm-eku-c=
onstraints-02.txt
Status:         https://datatracker.ietf.org/doc/draft-housley-spasm-eku-const=
raints/
Htmlized:       https://tools.ietf.org/html/draft-housley-spasm-eku-constraint=
s-02
Diff:           =
https://www.ietf.org/rfcdiff?url2=3Ddraft-housley-spasm-eku-co=
nstraints-02
 
Abstract:
  This document =
specifies the extended key usage constraints
  certificate extension, which is used to place =
restrictions on the key
  purpose =
identifiers that are authorized to appear in the =
end-entity
  certificate in a =
certification path.  Restrictions apply to the
  extended key usage certificate extension, which =
is described in
  RFC =
5280.
 
_______________________________________________
Spasm mailing list
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm
 
NOTICE: Protiviti is a global =
consulting and internal audit firm composed of experts specializing in =
risk and advisory services. Protiviti is not licensed or registered as a =
public accounting firm and does not issue opinions on financial =
statements or offer attestation services. This electronic mail message =
is intended exclusively for the individual or entity to which it is =
addressed. This message, together with any attachment, may contain =
confidential and privileged information. Any views, opinions or =
conclusions expressed in this message are those of the individual sender =
and do not necessarily reflect the views of Protiviti Inc. or its =
affiliates. Any unauthorized review, use, printing, copying, retention, =
disclosure or distribution is strictly prohibited. If you have received =
this message in error, please immediately advise the sender by reply =
email message to the sender and delete all copies of this message. Thank =
you. _______________________________________________
Spasm mailing =
list
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm

=

--Apple-Mail=_47EA0DD3-D96E-4292-937F-BF6A2394E45A--


From nobody Wed May 25 14:00:41 2016
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 036D112D094 for ; Wed, 25 May 2016 14:00:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-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 joLb9h-Uke0E for ; Wed, 25 May 2016 14:00:37 -0700 (PDT)
Received: from smtp.outgoing.loopia.se (smtp.outgoing.loopia.se [194.9.95.112]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC05112D11F for ; Wed, 25 May 2016 14:00:36 -0700 (PDT)
Received: from s554.loopia.se (localhost [127.0.0.1]) by s554.loopia.se (Postfix) with ESMTP id 7D38217E294B for ; Wed, 25 May 2016 23:00:13 +0200 (CEST)
X-Loopia-Auth: user
X-Loopia-Originating-IP: 90.229.17.25
X-Loopia-User: stefan@fiddler.nu
Received: from s500.loopia.se (unknown [172.21.200.98]) by s554.loopia.se (Postfix) with ESMTP id 47E999835CF; Wed, 25 May 2016 23:00:13 +0200 (CEST)
Received: from s405.loopia.se (unknown [172.21.200.105]) by s500.loopia.se (Postfix) with ESMTP id 44564A9A3F7; Wed, 25 May 2016 23:00:13 +0200 (CEST)
X-Virus-Scanned: amavisd-new at amavis.loopia.se
Received: from s500.loopia.se ([172.21.200.105]) by s405.loopia.se (s405.loopia.se [172.21.200.135]) (amavisd-new, port 10024) with LMTP id AQv8NX8qsEwA; Wed, 25 May 2016 23:00:12 +0200 (CEST)
Received: from [10.0.1.51] (unknown [90.229.17.25]) (Authenticated sender: stefan@fiddler.nu) by s500.loopia.se (Postfix) with ESMTPSA id C7D33A9A38F; Wed, 25 May 2016 23:00:09 +0200 (CEST)
User-Agent: Microsoft-MacOutlook/f.16.0.160506
Date: Wed, 25 May 2016 22:59:49 +0200
From: Stefan Santesson 
To: Sean Leonard , 
Message-Id: <52B3B881-537E-4A34-9B4C-4B056B7B9A9F@aaa-sec.com>
Thread-Topic: [Spasm] draft-housley-spasm-eku-constraints-01.txt
References: <20160518171802.14749.72841.idtracker@ietfa.amsl.com>  <4A0C6BB6-D5F8-47A0-B392-AEBC0859C1FC@aaa-sec.com>  <939935CA-2161-49B8-92D3-FB296CDF4ADE@aaa-sec.com> <7888389D-73C8-49AD-B788-E3886AB9410E@vigilsec.com>  
In-Reply-To: 
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="B_3547062009_450950939"
Archived-At: 
Subject: Re: [Spasm] draft-housley-spasm-eku-constraints-01.txt
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 25 May 2016 21:00:40 -0000

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3547062009_450950939
Content-type: text/plain;
	charset="UTF-8"
Content-transfer-encoding: quoted-printable

I don=E2=80=99t like transition periods. They assume things we do not know anythi=
ng about.

Most importantly they assume that this extension gets deployed widely.

=20

What if that doesn=E2=80=99t happen but some still use it successfully with non-c=
riticality?

We don=E2=80=99t know if the conditions of today will go away tomorrow.

=20

/Stefan

=20

=20

From: Spasm  on behalf of Sean Leonard 
Date: Wednesday 25 May 2016 at 20:06
To: 
Subject: Re: [Spasm] draft-housley-spasm-eku-constraints-01.txt

=20

On 5/25/2016 10:43 AM, Wei Chuang wrote:

=20

=20

On Tue, May 24, 2016 at 1:11 PM, Russ Housley  wrote:

Stefan:
...
>
> Those where other times. That was extensions already known to the market.=
 And we where more na=C3=AFve at the time than we are today.
> We overestimated the value of the features and we underestimated the inte=
rop challenges.
> You are of course absolutely right. The only problem is that it may not w=
ork because it=E2=80=99s a deployment blocker. Who will include an extension that =
guarantees that the certificate will be rejected in all major implementation=
s?

Indeed, there are challenges to deploying a critical extension.  A signific=
ant population of relying parties would need to support it before a CA would=
 make use of it.

> I=E2=80=99d make it a CA choice. They can decide whether they can live with the=
 risk of clients not getting the extension constraint over the drawback of h=
aving the certificate rejected in most current clients.
> This is no worse than it is today. Issuers putting in EKU in CA certifica=
tes for the purpose of constraining have no guarantee that everyone will get=
 it, and obviously they can live with that.

I think you are suggesting:

   This extension MAY, at the option of the certificate issuer, be
   either critical or non-critical.

If this is the approach supported by otters, then I will make the change.  =
It would require a bit of text in the Security Considerations about non-crit=
ical EKU constraints being ignored by relying parties that do not support th=
is extension.

=20

I agree allowing for non-critical is a good approach to resolve the deploym=
ent problems that Stefan has pointed out.  Non-critical would assist bridgin=
g a transition.  Also at some future point, its would be possible to revise =
again to make this extension critical once a significant population uses it.


I support a transitional period baked into the draft, namely, that the exte=
nsion MAY be critical now; SHOULD be critical after time X (2018?), and MUST=
 be critical after time Y (2020?).

Perhaps the time should be tied to the certificate issuance artifact, namel=
y, where the notBefore date is prior to X, then MAY; if notBefore is prior t=
o Y, then SHOULD; if notBefore is after Y, then MUST.

Sean=20

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


--B_3547062009_450950939
Content-type: text/html;
	charset="UTF-8"
Content-transfer-encoding: quoted-printable


I don’t like transition periods. They assume things we =
do not know anything about.
Most importantly they assume that=
 this extension gets deployed widely.
 
W=
hat if that doesn’t happen but some still use it successfully with non=
-criticality?
We don’t know if the conditions of today =
will go away tomorrow.
 
/Stefan
 
 
From: Spasm <spasm-bounces@ietf.org&g=
t; on behalf of Sean Leonard <dev+ietf@seantek.com>
Date: We=
dnesday 25 May 2016 at 20:06
To: <spasm@ietf.org>
Subj=
ect: Re: [Spasm] draft-housley-spasm-eku-constraints-01.txt
 
On 5/25/2016 10:43 AM, Wei Chuang wrot=
e:
 
 
On Tue, May 24, 2016 at 1:11 PM, R=
uss Housley <housley@vigilsec.com> wrote:
Stefan:
=
...
>
> Thos=
e where other times. That was extensions already known to the market. And we=
 where more na=C3=AFve at the time than we are today.
> We overestimated the value of the features and we underestimated the=
 interop challenges.
> You are of course abs=
olutely right. The only problem is that it may not work because it’s a=
 deployment blocker. Who will include an extension that guarantees that the =
certificate will be rejected in all major implementations?

Ind=
eed, there are challenges to deploying a critical extension.  A signifi=
cant population of relying parties would need to support it before a CA woul=
d make use of it.

> I’d make it a CA choi=
ce. They can decide whether they can live with the risk of clients not getti=
ng the extension constraint over the drawback of having the certificate reje=
cted in most current clients.
> This is no w=
orse than it is today. Issuers putting in EKU in CA certificates for the pur=
pose of constraining have no guarantee that everyone will get it, and obviou=
sly they can live with that.

I think you are suggesting:
   This extension MAY, at the option of the certificate issuer, =
be
   either critical or non-critical.

If this is the ap=
proach supported by otters, then I will make the change.  It would requ=
ire a bit of text in the Security Considerations about non-critical EKU cons=
traints being ignored by relying parties that do not support this extension.=

<=
/blockquote>

I support a transitional period baked int=
o the draft, namely, that the extension MAY be critical now; SHOULD be criti=
cal after time X (2018?), and MUST be critical after time Y (2020?).

=
Perhaps the time should be tied to the certificate issuance artifact, namely=
, where the notBefore date is prior to X, then MAY; if notBefore is prior to=
 Y, then SHOULD; if notBefore is after Y, then MUST.

Sean =

_________________________________________=
______ Spasm mailing list Spasm@ietf.org https://www.ietf.org/mailman/listin=
fo/spasm 


--B_3547062009_450950939--



From nobody Wed May 25 14:16:08 2016
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 2409D12D109 for ; Wed, 25 May 2016 14:16:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-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 kD-uqBgkXYdp for ; Wed, 25 May 2016 14:16:05 -0700 (PDT)
Received: from smtp.outgoing.loopia.se (smtp.outgoing.loopia.se [194.9.95.112]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79FFD12D1ED for ; Wed, 25 May 2016 14:16:05 -0700 (PDT)
Received: from s554.loopia.se (localhost [127.0.0.1]) by s554.loopia.se (Postfix) with ESMTP id A39B417EEF98 for ; Wed, 25 May 2016 23:16:02 +0200 (CEST)
X-Loopia-Auth: user
X-Loopia-Originating-IP: 90.229.17.25
X-Loopia-User: stefan@fiddler.nu
Received: from s500.loopia.se (unknown [172.21.200.98]) by s554.loopia.se (Postfix) with ESMTP id 8602E983CAD; Wed, 25 May 2016 23:16:02 +0200 (CEST)
Received: from s404.loopia.se (unknown [172.21.200.105]) by s500.loopia.se (Postfix) with ESMTP id 819ECA9A41A; Wed, 25 May 2016 23:16:02 +0200 (CEST)
X-Virus-Scanned: amavisd-new at amavis.loopia.se
Received: from s500.loopia.se ([172.21.200.105]) by s404.loopia.se (s404.loopia.se [172.21.200.134]) (amavisd-new, port 10024) with LMTP id oAzWTY1M4JKx; Wed, 25 May 2016 23:16:01 +0200 (CEST)
Received: from [10.0.1.51] (unknown [90.229.17.25]) (Authenticated sender: stefan@fiddler.nu) by s500.loopia.se (Postfix) with ESMTPSA id B084FA9A41C; Wed, 25 May 2016 23:15:59 +0200 (CEST)
User-Agent: Microsoft-MacOutlook/f.16.0.160506
Date: Wed, 25 May 2016 23:15:55 +0200
From: Stefan Santesson 
To: Wei Chuang , Russ Housley 
Message-Id: <965E18B6-5CB4-4D27-B90D-6AF29C60CA1B@aaa-sec.com>
Thread-Topic: [Spasm] draft-housley-spasm-eku-constraints-01.txt
References: <20160518171802.14749.72841.idtracker@ietfa.amsl.com>  <4A0C6BB6-D5F8-47A0-B392-AEBC0859C1FC@aaa-sec.com>  <939935CA-2161-49B8-92D3-FB296CDF4ADE@aaa-sec.com> <7888389D-73C8-49AD-B788-E3886AB9410E@vigilsec.com> 
In-Reply-To: 
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="B_3547062960_1918479435"
Archived-At: 
Cc: spasm@ietf.org
Subject: Re: [Spasm] draft-housley-spasm-eku-constraints-01.txt
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 25 May 2016 21:16:07 -0000

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3547062960_1918479435
Content-type: text/plain;
	charset="UTF-8"
Content-transfer-encoding: quoted-printable

There is one more argument for the alternative solution to just set a binar=
y value that declares that EKU in CA certs have a constraining property. (co=
mpatible with many current CA certs)

=20

The advantage with this is that this bit could also be added as an input pa=
rameter to path processing, when the certs in use don=E2=80=99t have them yet.

That would make it legal do do this constraining processing on existing cer=
ts that do not yet have this new extension included.

=20

We all know how hard and costly it can be to re-issue CA certificates.

We will therefore have to live with old non-compliant certificates for a lo=
ng time (some of these certificates are very long lived).

=20

Microsoft have/had property settings for trusted certificates in cert store=
s, which are passed as input parameters to path processing.

If the extension we define is just a binary value that endorses the current=
 intended constraining effect of EKUs in CA certificates, then that would be=
 more compatible with passing the same logic through property parameters in =
cert stores as backup for certificates that don=E2=80=99t have this extension yet.

=20

It is not so clear to me what the comparable situation would be with the ne=
w extension.

The risk is that there will be a mess with different ways to constrain in t=
he same path.=20

=20

-          Property parameter in the cert store suggest some EKU constraini=
ng

-          Some CA certs in the path constrain through EKU extenson

-          Some CA certs in the path contstain through the new extension.

=20

The risk is that two implementers will do this with incompatible results.

=20

/Stefan

=20

=20

=20

=20

From: Spasm  on behalf of Wei Chuang 
Date: Wednesday 25 May 2016 at 19:43
To: Russ Housley 
Cc: , Stefan Santesson 
Subject: Re: [Spasm] draft-housley-spasm-eku-constraints-01.txt

=20

I think Stefan's simplification would be better for deployment.  There are =
already many existing server certificates with intermediate CA EKU constrain=
ts in their path.

=20


--B_3547062960_1918479435
Content-type: text/html;
	charset="UTF-8"
Content-transfer-encoding: quoted-printable



--B_3547062960_1918479435--



From nobody Thu May 26 12:34:23 2016
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 92EE112DADA for ; Thu, 26 May 2016 12:34:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Level: 
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0JM9PWKZzbX6 for ; Thu, 26 May 2016 12:34:20 -0700 (PDT)
Received: from mail.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id D487F12D905 for ; Thu, 26 May 2016 12:34:17 -0700 (PDT)
Received: from localhost (ronin.smetech.net [209.135.209.5]) by mail.smetech.net (Postfix) with ESMTP id 3A8D4F24036; Thu, 26 May 2016 15:34:17 -0400 (EDT)
X-Virus-Scanned: amavisd-new at smetech.net
Received: from mail.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id j8fNAQ89-oWt; Thu, 26 May 2016 15:16:30 -0400 (EDT)
Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.smetech.net (Postfix) with ESMTP id BC7E9F24013; Thu, 26 May 2016 15:34:16 -0400 (EDT)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Russ Housley 
In-Reply-To: <939935CA-2161-49B8-92D3-FB296CDF4ADE@aaa-sec.com>
Date: Thu, 26 May 2016 15:34:21 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <4BBCF312-16C1-42E7-B0B2-19229A38101B@vigilsec.com>
References: <20160518171802.14749.72841.idtracker@ietfa.amsl.com>  <4A0C6BB6-D5F8-47A0-B392-AEBC0859C1FC@aaa-sec.com>  <939935CA-2161-49B8-92D3-FB296CDF4ADE@aaa-sec.com>
To: Stefan Santesson 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: 
Cc: spasm@ietf.org
Subject: Re: [Spasm] draft-housley-spasm-eku-constraints-01.txt
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 26 May 2016 19:34:21 -0000

Stefan:

>> Maybe it was not used while you were at Microsoft, but the message to =
the PKIX list that started this discussion shows that the current EKU is =
being used in the same manner as permittedKeyPurposeIds in my proposal.  =
Your example about constraining code signing is exactly the reason that =
I included excludedKeyPurposeIds in my proposal.
>=20
> The logic used for code signing only needs the permitted logic. =
Everything not in the permitted group is not permitted.
> If I need to choose between 2 evils, I=92d rather have a simple =
extension making it legal what is already out there, than a new fancy =
extension that is more capable.

The use case that is motivating the excludedKeyPurposeIds field is the =
isolation of very special capabilities like code signing.  The current =
approach dies not do that well.  Let=92s look at a way to do it with the =
extension as it is defined in the current draft. Starting with an =
unconstrained root, two Intermediate CA certs are issued.  The first one =
will be exclusively for code signing certificates, and the second one =
for everything else.

	ICA1 will have a EKU constraint that has permitted key purpose =
for code signing and OCSP signing.

	ICA2 will have a EKU constraint that has excluded key purpose =
for code signing.

The approach used today does not provide this clean separation, and the =
allocation of new key purpose identifiers can lead to new certificates =
being issues to enable them.

Russ


From nobody Thu May 26 12:39:00 2016
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 13E6E12D92E for ; Thu, 26 May 2016 12:38:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.727
X-Spam-Level: 
X-Spam-Status: No, score=-5.727 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=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 9C1MFliDQcgR for ; Thu, 26 May 2016 12:38:57 -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 0B8CB12D926 for ; Thu, 26 May 2016 12:38:57 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 2F6B9BE88; Thu, 26 May 2016 20:38:55 +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 JG78o6PXzrp5; Thu, 26 May 2016 20:38:54 +0100 (IST)
Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id BE883BE7B; Thu, 26 May 2016 20:38:49 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1464291530; bh=VQaG5LJXs0+s9d/er+uVTyGEKBzeY+qGBrq4/onnULw=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=LxQRepJmmz+hxuQIdYjA0m3fFkepkU/784L9DB+5Ysjtix/ARjG583Hvdu8vb56Rx uvr9sqTZ6z0rH1u1vh/+JaZT7dtaLjT98VqLsh+cnmq+uS0kXAijtbBQg7UHHE+qkM 5KZN8R/7m22DiWQa9eMwOTVQR5V/IdAEo7aXu+mQ=
To: Russ Housley , Stefan Santesson 
References: <20160518171802.14749.72841.idtracker@ietfa.amsl.com>  <4A0C6BB6-D5F8-47A0-B392-AEBC0859C1FC@aaa-sec.com>  <939935CA-2161-49B8-92D3-FB296CDF4ADE@aaa-sec.com> <4BBCF312-16C1-42E7-B0B2-19229A38101B@vigilsec.com>
From: Stephen Farrell 
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <574750C9.7090801@cs.tcd.ie>
Date: Thu, 26 May 2016 20:38:49 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0
MIME-Version: 1.0
In-Reply-To: <4BBCF312-16C1-42E7-B0B2-19229A38101B@vigilsec.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000405040607050202000806"
Archived-At: 
Cc: spasm@ietf.org
Subject: Re: [Spasm] draft-housley-spasm-eku-constraints-01.txt
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 26 May 2016 19:38:59 -0000

This is a cryptographically signed message in MIME format.

--------------ms000405040607050202000806
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


Hi Russ,

On 26/05/16 20:34, Russ Housley wrote:
> The use case that is motivating the excludedKeyPurposeIds field is
> the isolation of very special capabilities like code signing.  The
> current approach dies not do that well.

Would it be good to put something along those lines in the charter
text?

Say "There is a need to isolate some special capabilities enabled
via PKI from more "normal" end-entity authentication, with the main
use case here being separation of code-signing from web-server
authentication so that relying parties are not as easily confused
between the two."

I'm sure the wording needs improving (I'd welcome better from anyone
on the list) but adding something like that is what I was asking about
in the scoping thread.

Cheers,
S.


--------------ms000405040607050202000806
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
CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ
BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD
ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll
bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw
aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA
Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra
C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3
rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5
R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r
dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt
3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw
MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ
QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv
BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5
BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu
Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll
bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc
MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE
MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG
9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD
C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9
U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM
aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai
9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC
BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE
BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs
IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g
QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC
SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC
ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv
mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm
VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4
D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI
dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu
N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE
FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp
MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE
WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG
JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+
SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g
BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv
bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY
0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF
NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9
uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p
6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv
Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu
mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7
RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO
/ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN
JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM
MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG
A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0
Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA
oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA1MjYx
OTM4NDlaMC8GCSqGSIb3DQEJBDEiBCCYrTTlyLOtSXz6HneYOqM5XCRLt0DUF2IPN/VD7bVr
qzBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN
AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC
AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw
IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB
nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD
VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq
hkiG9w0BAQEFAASCAQBeN0NeideT57M5wtm/e7MI3q4eGrOf8CI7X2S7ffR2RBy6RdLXeRZF
LBueU/A8ni5QEronMZ7q7hlxYtlzN3rpFavLH6DoW1RGB2Z+noM8pSGDekgb0NXh+hYC+z1B
gNshwRNHgx/Dk0ksFg6OQuCHN+LX8Bt+pphH32Eu/+z98EtgMpIxdXV1bcdsFVQX/oSMRDVp
UDc06h8XveWZ6SUFYNGf+zG2QJWbG4oP0Yx2F7Jw8b7Kke47RWv/McXsL96sUk0UofMbOpbG
iEP7hyP//uxpLO+JVYVQxm5Kda1v8biNfzQCVQKgbsnWVz5j7YTnRpDEPcw36uKrIG3ykZKe
AAAAAAAA
--------------ms000405040607050202000806--


From nobody Thu May 26 13:04:53 2016
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 69C1812D5C2 for ; Thu, 26 May 2016 13:04:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 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] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.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 HD_fFaanKhid for ; Thu, 26 May 2016 13:04:46 -0700 (PDT)
Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::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 9B43912B069 for ; Thu, 26 May 2016 13:04:46 -0700 (PDT)
Received: by mail-vk0-x22f.google.com with SMTP id f66so117078590vkh.2 for ; Thu, 26 May 2016 13:04:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:date:message-id:subject:from:to; bh=Ofa/3vsGdYiDouofaOaDwYt4WvXuw/+KhQRVfpGoybM=; b=F3nCyvXWbid/MYkRYQX0RPc1e9O6b0auzgbbwTPA+WR9eLRrJz8PK/qezzACeUOc7a AqXZzCnRa1hUdW+3AgicWhozp3OrWIvPvgrb46tXc5hzKr4X6Bmx7PNNQVHjQjFgD2wC pvRKnqblfWEOrt4CTaykckJ4qUgcswn8tjedBPJkPT5MT6R3rtAnMOcu130/It8zfn3W mbxnlYAzVNmjnoDWeushlcWal9z0DEbC1CbkRnboEbmo5SRrukf7QxsNbsx2sZUF38oU gDm2/EjavGMFxYUcDF3+t0RwBFZvLx05gE7WB6BFqmJrCD9emA9X/x3+zGo9YXH98Yw0 pnZw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=Ofa/3vsGdYiDouofaOaDwYt4WvXuw/+KhQRVfpGoybM=; b=JnIWzkkUyUlIA/Fh71rteetEK16gjPZu9RqiAh1UtIanpazlxUU/11DOJ98hla28TJ cU1i8xvwu0bAIgB+xCVwS7ybAryv+bxGPnZLsmPw4XXBcxTKEUv5RUduU5OWdjD5xnsw 3S0T2DMhpNKqj0/+SfGnaYrfU42Xs8q9IdH3DlfbhYYAhqEJMN9YfXmp3dLaIR148+gn TVB91PlXJRF5fIplwtCECMIkhh8R5kUJXPHa4p+QeDdoqnwl4xD+c+oguOhbIsgdVcZk RaQG99L7cCMYzCfqA8wYeMMiEno3J4SX2jXS96jGvPNeK43vB1sWKTSDNCsttELgfnPf 3t9A==
X-Gm-Message-State: ALyK8tKl2hLCNHbVFdwICOzEC/4vQDprsHA51pScf6fMnvgxKxQuQXMp8/W0UioM7OsKsqT5ZTebuJ3ZaQ0R8A==
MIME-Version: 1.0
X-Received: by 10.176.7.70 with SMTP id h64mr6447228uah.97.1464293085536; Thu, 26 May 2016 13:04:45 -0700 (PDT)
Received: by 10.31.48.71 with HTTP; Thu, 26 May 2016 13:04:45 -0700 (PDT)
Date: Thu, 26 May 2016 16:04:45 -0400
Message-ID: 
From: Richard Barnes 
To: spasm@ietf.org
Content-Type: multipart/alternative; boundary=94eb2c12339a3608540533c44d14
Archived-At: 
Subject: [Spasm] Let's focus
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 26 May 2016 20:04:52 -0000

--94eb2c12339a3608540533c44d14
Content-Type: text/plain; charset=UTF-8

Hey all,

I'm concerned that the proposed scope [1] for this WG is (1) too broad, and
(2) inconsistent with the participation so far.

The breadth concern is evident in the ambiguity of the name "Some?"  This
group should identify some concrete, practical problems in the Internet
they need to solve, describe them, and demonstrate that they have the right
set of stakeholders to develop, implement, and deploy a solution.

I'm personally most concerned about the "fix the EKUs" milestone, at least
as it's realized in [2].  From the perspective of someone who works a lot
in the Web PKI, this sounds like a request for a feature that has negative
value.  The incremental value of the proposed feature would be to allow
"everything but X" CAs.  Recent experience in the Web PKI has driven home
how harmful it can be to have divergent sets of RPs relying on the same
PKI, so allowing CAs to be more unconstrained is moving in the wrong
direction.  I'm not dogmatic on this, but in order to be persuaded, I would
need to see active interest from some real CAs, and from the logs of this
list, I'm not seeing anyone who's a current participant in the Web PKI
(apologies if I've failed to recognize someone).

I'm also concerned about the "SRV for cert stores" milestone, though I
admit I'm not as deep in this space.  Looking at the proposed doc, it seems
like the SRV adds any value over just looking stuff up at a well-known URI,
e.g., adding a "x5c" attribute to a WebFinger resource.  Anything that
requires special DNS magic (and SRV counts) is going to face significant
deployment barriers.  So I would be happier if this were a "define a simple
cert discovery mechanism for S/MIME" milestone, rather than being bound to
a specific mechanism.

Overall, it seems like this group should focus on moving the ball forward
with regard to making S/MIME deployable in today's Internet -- fixing
papercuts around AEAD, i18n, and cert discovery.  The PKIX stuff is
unrelated and addresses an entirely different constituency.

--Richard


[1] https://datatracker.ietf.org/doc/charter-ietf-spasm/
[2] https://tools.ietf.org/html/draft-housley-spasm-eku-constraints-01
[3] https://tools.ietf.org/html/draft-bhjl-x509-srv-00

--94eb2c12339a3608540533c44d14
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hey all,

I'm concerned that the=
 proposed scope [1] for this WG is (1) too broad, and (2) inconsistent with=
 the participation so far.

The breadth concern is evident=
 in the ambiguity of the name "Some?"=C2=A0 This group should ide=
ntify some concrete, practical problems in the Internet they need to solve,=
 describe them, and demonstrate that they have the right set of stakeholder=
s to develop, implement, and deploy a solution.

I'm p=
ersonally most concerned about the "fix the EKUs" milestone, at l=
east as it's realized in [2].=C2=A0 From the perspective of someone who=
 works a lot in the Web PKI, this sounds like a request for a feature that =
has negative value.=C2=A0 The incremental value of the proposed feature wou=
ld be to allow "everything but X" CAs.=C2=A0 Recent experience in=
 the Web PKI has driven home how harmful it can be to have divergent sets o=
f RPs relying on the same PKI, so allowing CAs to be more unconstrained is =
moving in the wrong direction.=C2=A0 I'm not dogmatic on this, but in o=
rder to be persuaded, I would need to see active interest from some real CA=
s, and from the logs of this list, I'm not seeing anyone who's a cu=
rrent participant in the Web PKI (apologies if I've failed to recognize=
 someone).

I'm also concerned about the &q=
uot;SRV for cert stores" milestone, though I admit I'm not as deep=
 in this space.=C2=A0 Looking at the proposed doc, it seems like the SRV ad=
ds any value over just looking stuff up at a well-known URI, e.g., adding a=
 "x5c" attribute to a WebFinger resource.=C2=A0 Anything that req=
uires special DNS magic (and SRV counts) is going to face significant deplo=
yment barriers.=C2=A0 So I would be happier if this were a "define a s=
imple cert discovery mechanism for S/MIME" milestone, rather than bein=
g bound to a specific mechanism.

Overall, it seems like t=
his group should focus on moving the ball forward with regard to making S/M=
IME deployable in today's Internet -- fixing papercuts around AEAD, i18=
n, and cert discovery.=C2=A0 The PKIX stuff is unrelated and addresses an e=
ntirely different constituency.

--Richard
<=
br>

[1] https://datatracker.ietf.org/doc/charter-ietf-spasm/
[2] =
https://tools.ietf.org/html/draft-housley-spasm-eku-constraints-01
[=
3] https://t=
ools.ietf.org/html/draft-bhjl-x509-srv-00


--94eb2c12339a3608540533c44d14--


From nobody Thu May 26 13:11:17 2016
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 17BF412D7EE for ; Thu, 26 May 2016 13:11:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.126
X-Spam-Level: 
X-Spam-Status: No, score=-4.126 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, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 u9D3M_DEOZ3c for ; Thu, 26 May 2016 13:11:14 -0700 (PDT)
Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::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 28DE412D893 for ; Thu, 26 May 2016 13:11:14 -0700 (PDT)
Received: by mail-oi0-x22b.google.com with SMTP id w184so135274538oiw.2 for ; Thu, 26 May 2016 13:11:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=QbqcBU0EbCIMjcgcw7mgSUMoHu3qfNzKjl+XyKSp4OI=; b=TM4tMOXQNpDCP3S44WQCbHCFEJ8NSSs9+t2btT5aOlhdQOg3JqpGgrqIbiF8v0J90x RdY2zuxFREJQomDuG44jJa40BMiMJl5cGN2sexrAmtgDsvDIri6vfv12tT3/imWr92b5 Hy5EwGcainDWG7q7d9jbDv2D/T9E7AlBlxYnRr6EVJ+1U5K3dqHlb9UqAYfjt7sQeZPw VfF9rGEvWIif4Cb+s/dDuhxIgZHLzdzor0oi+P9mxJ7nCK9nYtN+4ZC8Bmmmoi+NxrBP J5CU2VwBMzA3Fv/z7GgZQw/LYQ6qoOQI9EFGkLl5h4vizTsJVZFVEoRenLZxy559DCC9 WMXQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=QbqcBU0EbCIMjcgcw7mgSUMoHu3qfNzKjl+XyKSp4OI=; b=J2rQ39A3CjN7JRYmKQ7NwBF8D+QcccIs7R5++WF8V+g6XDv/CxbZ2ERzNijznL1LiX uaEBSGAly6OvhRALPZxV1tmTkWsvha/n1NhMec0FeyI10NarvsniWHEW2UESwiO8W/Gr wgpNP1pXZozihoOSNTZm6uaQxxC7OQGSoRZh1cSaWSR3sOFEIudiJlX8uPVDUwnlt7Mq SAOVLJBCACwucG3Cyp0GPdNhFT22kwR+m7KhDkQKbDx5ztUCkNbMOs5weqsucN1YWkfA NHUbhyFzIc6UYO9fubxgsZY/rhPsIXAoFC2GkmYhQpOjT0pBCCwnDOwJEkDpQc3p4EXm WG/A==
X-Gm-Message-State: ALyK8tLrwTxSW6YOM9Y9YwfI5FN2K+Js8diJ0pxILXv3RYonDy6ovu3PC0WjAuizIbJ6Q/nQw6sX44chy3ueJ9yc
X-Received: by 10.157.31.36 with SMTP id x33mr7784862otd.26.1464293473143; Thu, 26 May 2016 13:11:13 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.157.1.67 with HTTP; Thu, 26 May 2016 13:11:12 -0700 (PDT)
In-Reply-To: 
References: 
From: Wei Chuang 
Date: Thu, 26 May 2016 13:11:12 -0700
Message-ID: 
To: Richard Barnes 
Content-Type: multipart/alternative; boundary=001a113e58965092420533c4645a
Archived-At: 
Cc: spasm@ietf.org
Subject: Re: [Spasm] Let's focus
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 26 May 2016 20:11:16 -0000

--001a113e58965092420533c4645a
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On Thu, May 26, 2016 at 1:04 PM, Richard Barnes  wrote:

> Hey all,
>
> I'm concerned that the proposed scope [1] for this WG is (1) too broad,
> and (2) inconsistent with the participation so far.
>
> The breadth concern is evident in the ambiguity of the name "Some?"  This
> group should identify some concrete, practical problems in the Internet
> they need to solve, describe them, and demonstrate that they have the right
> set of stakeholders to develop, implement, and deploy a solution.
>
> I'm personally most concerned about the "fix the EKUs" milestone, at least
> as it's realized in [2].  From the perspective of someone who works a lot
> in the Web PKI, this sounds like a request for a feature that has negative
> value.  The incremental value of the proposed feature would be to allow
> "everything but X" CAs.  Recent experience in the Web PKI has driven home
> how harmful it can be to have divergent sets of RPs relying on the same
> PKI, so allowing CAs to be more unconstrained is moving in the wrong
> direction.  I'm not dogmatic on this, but in order to be persuaded, I would
> need to see active interest from some real CAs, and from the logs of this
> list, I'm not seeing anyone who's a current participant in the Web PKI
> (apologies if I've failed to recognize someone).
>
> I'm also concerned about the "SRV for cert stores" milestone, though I
> admit I'm not as deep in this space.  Looking at the proposed doc, it seems
> like the SRV adds any value over just looking stuff up at a well-known URI,
> e.g., adding a "x5c" attribute to a WebFinger resource.  Anything that
> requires special DNS magic (and SRV counts) is going to face significant
> deployment barriers.  So I would be happier if this were a "define a simple
> cert discovery mechanism for S/MIME" milestone, rather than being bound to
> a specific mechanism.
>
> Overall, it seems like this group should focus on moving the ball forward
> with regard to making S/MIME deployable in today's Internet -- fixing
> papercuts around AEAD, i18n, and cert discovery.  The PKIX stuff is
> unrelated and addresses an entirely different constituency.
>

The certificate i18n email address draft is actively being worked on.
Probably a next rev posted next week or sooner.

-Wei


>
> --Richard
>
>
> [1] https://datatracker.ietf.org/doc/charter-ietf-spasm/
> [2] https://tools.ietf.org/html/draft-housley-spasm-eku-constraints-01
> [3] https://tools.ietf.org/html/draft-bhjl-x509-srv-00
>
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm
>
>

--001a113e58965092420533c4645a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit




On Thu, May 26, 2016 at 1:04 PM, Richard Barnes <rlb@ipv.sx> wrote:
Hey all,

I'm concerned that the proposed scope [1] for this WG is (1) too broad, and (2) inconsistent with the participation so far.

The breadth concern is evident in the ambiguity of the name "Some?"  This group should identify some concrete, practical problems in the Internet they need to solve, describe them, and demonstrate that they have the right set of stakeholders to develop, implement, and deploy a solution.

I'm personally most concerned about the "fix the EKUs" milestone, at least as it's realized in [2].  From the perspective of someone who works a lot in the Web PKI, this sounds like a request for a feature that has negative value.  The incremental value of the proposed feature would be to allow "everything but X" CAs.  Recent experience in the Web PKI has driven home how harmful it can be to have divergent sets of RPs relying on the same PKI, so allowing CAs to be more unconstrained is moving in the wrong direction.  I'm not dogmatic on this, but in order to be persuaded, I would need to see active interest from some real CAs, and from the logs of this list, I'm not seeing anyone who's a current participant in the Web PKI (apologies if I've failed to recognize someone).

I'm also concerned about the "SRV for cert stores" milestone, though I admit I'm not as deep in this space.  Looking at the proposed doc, it seems like the SRV adds any value over just looking stuff up at a well-known URI, e.g., adding a "x5c" attribute to a WebFinger resource.  Anything that requires special DNS magic (and SRV counts) is going to face significant deployment barriers.  So I would be happier if this were a "define a simple cert discovery mechanism for S/MIME" milestone, rather than being bound to a specific mechanism.

Overall, it seems like this group should focus on moving the ball forward with regard to making S/MIME deployable in today's Internet -- fixing papercuts around AEAD, i18n, and cert discovery.  The PKIX stuff is unrelated and addresses an entirely different constituency.

The certificate i18n email address draft is actively being worked on.  Probably a next rev posted next week or sooner.

-Wei
 


_______________________________________________

Spasm mailing list

Spasm@ietf.org

https://www.ietf.org/mailman/listinfo/spasm





--001a113e58965092420533c4645a--


From nobody Thu May 26 13:25:40 2016
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 D777612DB1A for ; Thu, 26 May 2016 13:25:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.727
X-Spam-Level: 
X-Spam-Status: No, score=-5.727 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=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 paoDGuQIel5l for ; Thu, 26 May 2016 13:25: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 5E7B612DB26 for ; Thu, 26 May 2016 13:23:19 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 1D500BE7B; Thu, 26 May 2016 21:23:18 +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 1noQkHCfOVCm; Thu, 26 May 2016 21:23:16 +0100 (IST)
Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 2F9F5BE75; Thu, 26 May 2016 21:23:16 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1464294196; bh=FV3SeAQzoqHK4F0gSkJt5P5ozsGcq0izEV2zd0ixErQ=; h=Subject:To:References:From:Date:In-Reply-To:From; b=heBZgpGFmtOU1Xp3FoBofDmCMU1GH4eZiy+dgnf9f4pPYfgtUK5IsWj4gr4nDCJCj bqTtcg1HCST87fQFQ3dEkRkdU/YZODmAEwuhIj27esT0viYUY8QOjjvAl9FPCZWSw6 KQcay59flSbZMIitU03MSRw1pjC4FdHO84S6Urm0=
To: Richard Barnes , spasm@ietf.org
References: 
From: Stephen Farrell 
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <57475B33.3070201@cs.tcd.ie>
Date: Thu, 26 May 2016 21:23:15 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms020908060607070306010607"
Archived-At: 
Subject: Re: [Spasm] Let's focus
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 26 May 2016 20:25:39 -0000

This is a cryptographically signed message in MIME format.

--------------ms020908060607070306010607
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


Hiya,

On 26/05/16 21:04, Richard Barnes wrote:
> Hey all,
>=20
> I'm concerned that the proposed scope [1] for this WG is (1) too broad,=
 and
> (2) inconsistent with the participation so far.
>=20
> The breadth concern is evident in the ambiguity of the name "Some?"  Th=
is
> group should identify some concrete, practical problems in the Internet=

> they need to solve, describe them, and demonstrate that they have the r=
ight
> set of stakeholders to develop, implement, and deploy a solution.

Well we can bikeshed names for sure but moving on...

>=20
> I'm personally most concerned about the "fix the EKUs" milestone, at le=
ast
> as it's realized in [2].=20

Yeah, me too. The discussion around that has been eerily reminiscent of
some of the less productive things from the "late" PKIX period.

> From the perspective of someone who works a lot
> in the Web PKI, this sounds like a request for a feature that has negat=
ive
> value.  The incremental value of the proposed feature would be to allow=

> "everything but X" CAs.  Recent experience in the Web PKI has driven ho=
me
> how harmful it can be to have divergent sets of RPs relying on the same=

> PKI, so allowing CAs to be more unconstrained is moving in the wrong
> direction.=20

Fair point. If the WG is chartered I think it'd have to decide if
that's ok or not. (Stefan's 1-bit counter-proposal didn't have the
same property though or am I wrong?)

> I'm not dogmatic on this, but in order to be persuaded, I would
> need to see active interest from some real CAs, and from the logs of th=
is
> list, I'm not seeing anyone who's a current participant in the Web PKI
> (apologies if I've failed to recognize someone).

It'd be good to see that kind of interest in the EKU work yes. Absent
that, I would guess deployment won't happen.

>=20
> I'm also concerned about the "SRV for cert stores" milestone, though I
> admit I'm not as deep in this space.  Looking at the proposed doc, it s=
eems
> like the SRV adds any value over just looking stuff up at a well-known =
URI,
> e.g., adding a "x5c" attribute to a WebFinger resource.  Anything that
> requires special DNS magic (and SRV counts) is going to face significan=
t
> deployment barriers.  So I would be happier if this were a "define a si=
mple
> cert discovery mechanism for S/MIME" milestone, rather than being bound=
 to
> a specific mechanism.

=46rom my POV, that's yet another experiment in the public-key-retrieval-=

to-support-e2e-messaging-security set of experiments that included the
openpgp-dane one recently approved. (And I'd be fine with more of those
experiments too for reasons stated during the IETF LC of the dane work.)

>=20
> Overall, it seems like this group should focus on moving the ball forwa=
rd
> with regard to making S/MIME deployable in today's Internet -- fixing
> papercuts around AEAD, i18n, and cert discovery.  The PKIX stuff is
> unrelated and addresses an entirely different constituency.

I'm personally if the work here isn't all one effort but a small set of
sorta-diverse efforts. So long as they're likely to be deployed that is.
If that's not likely, then I'd be for dropping them from the charter.

Cheers,
S.

>=20
> --Richard
>=20
>=20
> [1] https://datatracker.ietf.org/doc/charter-ietf-spasm/
> [2] https://tools.ietf.org/html/draft-housley-spasm-eku-constraints-01
> [3] https://tools.ietf.org/html/draft-bhjl-x509-srv-00
>=20
>=20
>=20
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm
>=20


--------------ms020908060607070306010607
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
CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ
BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD
ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll
bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw
aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA
Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra
C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3
rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5
R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r
dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt
3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw
MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ
QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv
BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5
BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu
Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll
bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc
MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE
MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG
9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD
C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9
U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM
aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai
9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC
BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE
BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs
IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g
QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC
SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC
ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv
mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm
VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4
D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI
dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu
N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE
FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp
MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE
WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG
JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+
SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g
BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv
bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY
0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF
NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9
uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p
6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv
Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu
mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7
RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO
/ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN
JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM
MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG
A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0
Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA
oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA1MjYy
MDIzMTVaMC8GCSqGSIb3DQEJBDEiBCAi1DYQFY/hLBvpAWzJBiupffew6HHxQcG+AHo814i3
vjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN
AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC
AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw
IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB
nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD
VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq
hkiG9w0BAQEFAASCAQBtDWoI1KOuL24RveJRDjT56I0d9tYcaha2sT9/ST1iWWi3IQps+xsi
aKJDHiPTUMWgZ29zOD4PZOFQoc47LFe/IG0QaJG2cnv88OBcPz9ppBo7xXbSwk8DWMlmY/Az
JHe2Vuj+M1jenHCqBGFMC9j69LOnawyOzR9tT/nc8XIvgwIPa1IRYl8ED2I+hY6qgBCyQ/TU
FKNc9Mq5U0P3d7+XqE7mq247mLKJQhhoiOTgAK8e/2Iao+Z71mz7uuaw0fWMHvEf951AbO1S
+G7Cy1mElzxOa5Hp3RMPbSC6yVK74Uomf4553005pzvHaIzBHq/bT7zOxQoE+6hFbIT15GOp
AAAAAAAA
--------------ms020908060607070306010607--


From nobody Thu May 26 13:33:49 2016
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 D46CB12D9D6 for ; Thu, 26 May 2016 13:33:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Level: 
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4mAikaUsznUB for ; Thu, 26 May 2016 13:33:47 -0700 (PDT)
Received: from mail.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 1507012D998 for ; Thu, 26 May 2016 13:33:40 -0700 (PDT)
Received: from localhost (ronin.smetech.net [209.135.209.5]) by mail.smetech.net (Postfix) with ESMTP id C40B6F2403B; Thu, 26 May 2016 16:33:39 -0400 (EDT)
X-Virus-Scanned: amavisd-new at smetech.net
Received: from mail.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id oju1fXs+WD7p; Thu, 26 May 2016 16:15:41 -0400 (EDT)
Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.smetech.net (Postfix) with ESMTP id 2F686F24036; Thu, 26 May 2016 16:33:28 -0400 (EDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_F0483BBB-3DE6-4840-B630-4850F3287121"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Russ Housley 
In-Reply-To: <574750C9.7090801@cs.tcd.ie>
Date: Thu, 26 May 2016 16:33:31 -0400
Message-Id: <5BE320B5-320C-41F4-ABF6-F3B99E80E01D@vigilsec.com>
References: <20160518171802.14749.72841.idtracker@ietfa.amsl.com>  <4A0C6BB6-D5F8-47A0-B392-AEBC0859C1FC@aaa-sec.com>  <939935CA-2161-49B8-92D3-FB296CDF4ADE@aaa-sec.com> <4BBCF312-16C1-42E7-B0B2-19229A38101B@vigilsec.com> <574750C9.7090801@cs.tcd.ie>
To: Stephen Farrell 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: 
Cc: spasm@ietf.org
Subject: Re: [Spasm] draft-housley-spasm-eku-constraints-01.txt
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 26 May 2016 20:33:49 -0000

--Apple-Mail=_F0483BBB-3DE6-4840-B630-4850F3287121
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Stephen:

>=20
>> The use case that is motivating the excludedKeyPurposeIds field is
>> the isolation of very special capabilities like code signing.  The
>> current approach dies not do that well.
>=20
> Would it be good to put something along those lines in the charter
> text?
>=20
> Say "There is a need to isolate some special capabilities enabled
> via PKI from more "normal" end-entity authentication, with the main
> use case here being separation of code-signing from web-server
> authentication so that relying parties are not as easily confused
> between the two."
>=20
> I'm sure the wording needs improving (I'd welcome better from anyone
> on the list) but adding something like that is what I was asking about
> in the scoping thread.

I guess I'm hoping to hear whether any CA believes in this use case.  =
The answer to that will tell us whether this meets your deployability =
requirement.

Russ


--Apple-Mail=_F0483BBB-3DE6-4840-B630-4850F3287121
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ9zCCBK8w
ggOXoAMCAQICEQDgI8sVEoNTia1hbnpUZ2shMA0GCSqGSIb3DQEBCwUAMG8xCzAJBgNVBAYTAlNF
MRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5l
dHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMTQxMjIyMDAwMDAw
WhcNMjAwNTMwMTA0ODM4WjCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl
c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV
BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls
IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAibEN2npTGU5wUh28VqYGJre4SeCW
51Gr8fBaE0kVo7SMG2C8elFCp3mMpCLfF2FOkdV2IwoU00oCf7YdCYBupQQ92bq7Fv6hh6kuQ1JD
FnyvMlDIpk9a6QjYz5MlnHuI6DBk5qT4VoD9KiQUMxeZrETlaYujRgZLwjPU6UCfBrCxrJNAubUI
kzqcKlOjENs9IGE8VQOO2U52JQIhKfqjfHF2T+7hX4Hp+1SA28N7NVK3hN4iPSwwLTF/Wb1SN7Az
aS1D6/rWpfGXd2dRjNnuJ+u8pQc4doykqTj/34z1A6xJvsr3c5k6DzKrnJU6Ez0ORjpXdGFQvsZA
P8vk4p+iIQIDAQABo4IBFzCCARMwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYD
VR0OBBYEFJJha4LhoqCqT+xn8cKj97SAAMHsMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAG
AQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAw
RAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJu
YWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNl
cnRydXN0LmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAGypurFXBOquIxdjtzVXzqmthK8AJECOZD8Vm
am+x9bS1d14PAmEA330F/hKzpICAAPz7HVtqcgIKQbwFusFY1SbC6tVNhPv+gpjPWBvjImOcUvi7
BTarfVil3qs7Y+Xa1XPv7OD7e+Kj//BCI5zKto1NPuRLGAOyqC3U2LtCS5BphRDbpjc06HvgARCl
nMo6x59PiDRuimXQGoq7qdzKyjbR9PzCZCk1r9axp3ER0gNDsY8+muyeMlP0dpLKhjQHuSzK5hxK
2JkNwYbikJL7WkJqIyEQ6WXH9dW7fuqMhSACYurROgcsWcWZM/I4ieW26RZ6H3kU9koQGib6fIr7
mzCCBUAwggQooAMCAQICEQCzIsUuKpsHVq2Oiy2wXwvCMA0GCSqGSIb3DQEBCwUAMIGbMQswCQYD
VQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRow
GAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50
IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTYwMzMxMDAwMDAwWhcNMTcw
MzMxMjM1OTU5WjAlMSMwIQYJKoZIhvcNAQkBFhRob3VzbGV5QHZpZ2lsc2VjLmNvbTCCASIwDQYJ
KoZIhvcNAQEBBQADggEPADCCAQoCggEBAOQwBbNVXhmLbyClWrRBX0GdNQFhVHEpbzM4tr5pdd0q
rPp8i+6qqNa4dAbJT6kodJ/LgsBi5EN3li4MJOIlf3rCsK1/VXepRwqUoc1cZfLRGdEj/4zgwrNZ
ULvOFiDIvYkAYDWRlYnEXulWr3KriOApHpfzbQvHStU1YsV762AIHVbZUW5tlTC9LfI8r+PIBFzv
Y5ujoUnSAgKgeE8gDK9yAxemrQ6wzDpwaf5PxEVnw0gOC2jtDojdzhoQfz57MFrL9pA1QyMbnItV
zCYfc5J7EfeCGupcFqwXytbJHSYPfLfM1/3omGgCGD/DZk4z4SUVC19k02iGxAIVDsWJ5oMCAwEA
AaOCAfIwggHuMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBTrsV85
Y7qY6oVPF5xRd+wqIu3VJTAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAX
BggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYM
KwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BT
MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNs
aWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUFBwEBBIGDMIGA
MFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9TSEEyNTZDbGllbnRB
dXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2Nz
cC5jb21vZG9jYS5jb20wHwYDVR0RBBgwFoEUaG91c2xleUB2aWdpbHNlYy5jb20wDQYJKoZIhvcN
AQELBQADggEBACgHw+/VeC7LgLJs19KZ6Ds2cW+jLSPjA3AIqSxiQ+uyDFwe6FujBUqRCXfla0qg
MzbhJ+1uSxcaktsS5idpB5Dfp8SVEGLcjtSJwWVlEofjaRrx6pi2mzazQwfKklY/epvsgnCoY8KW
FeSGkpbQXu5WrIL18EFqMCHqDiu5/P49PcZnJRv2xHTi5CkIsI7XgOw4FazS3xuJMVQ5TVtIUeMW
OqRlNJaeTiBsOVauS3FE/zRejsAYhHp3EV1PZFhV6hdcK/8qKrqRBtZtsEIm2FNWNsk8p/3RmUQl
4n4qN/NvapmXyYqfHZiuxf2g8H/WHF8IlVDzljLy90Uy0X7Qp0gxggPGMIIDwgIBATCBsTCBmzEL
MAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y
ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENs
aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAsyLFLiqbB1atjostsF8L
wjAJBgUrDgMCGgUAoIIB6TAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0xNjA1MjYyMDMzMzNaMCMGCSqGSIb3DQEJBDEWBBRBGFSuk3xw3g/Ji5EUcPD+7LQLFTCBwgYJ
KwYBBAGCNxAEMYG0MIGxMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz
dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE
AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg
Q0ECEQCzIsUuKpsHVq2Oiy2wXwvCMIHEBgsqhkiG9w0BCRACCzGBtKCBsTCBmzELMAkGA1UEBhMC
R0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE
ChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRo
ZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAsyLFLiqbB1atjostsF8LwjANBgkqhkiG
9w0BAQEFAASCAQA4uaIRElgaZQiHDmvjMDkCvvZFLeOn6rqGNMMtsEL2DLVP+J0tjG3MrltG5vtP
AcduDPrT7guj0PLR2ZYqiaNm5R8fAq2mhbXIW/A0Z2WBdjl6GRXkIMzxBl71V4qwn9kG/Sq1yUBV
YD6PJnbphzgK9fGcLhcd+bAsaliGZ7JM1CYEr/hfGEAovv88V3LoOKZ2HxkBNQv1Xz6+85wc0lwu
bpGS3MIuP/9u59rIqSLm2D1vegaTm8k7jskzP52L0Na/Xu1wJXG7jFdE+UPmq+W158q8fIZhyORC
dWwSQ6YxyyXThr1wcAwjcc9B44dcUj4zpJmaz9KsMV3nAg1IxRDrAAAAAAAA

--Apple-Mail=_F0483BBB-3DE6-4840-B630-4850F3287121--


From nobody Thu May 26 13:35:57 2016
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 5FCAD12D9B1 for ; Thu, 26 May 2016 13:35:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.727
X-Spam-Level: 
X-Spam-Status: No, score=-5.727 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=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 aICTpVzFZHAr for ; Thu, 26 May 2016 13:35:54 -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 BBC9C12D9BC for ; Thu, 26 May 2016 13:35:50 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 15A45BE75; Thu, 26 May 2016 21:35:49 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6EVo-j7JKv4W; Thu, 26 May 2016 21:35:47 +0100 (IST)
Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 2BF51BE7B; Thu, 26 May 2016 21:35:47 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1464294947; bh=kjJT4qwcuUVJ2pF7m82wfI2Y+7iIwYcsvMgOneOpII8=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=k55zkG36e82Ttlst8V9eLsuqsgJuqrtu5hYmxdBNDixl/hbmJpme3wtDoPaBbSYnQ cwbrMnqJcLY8IttBXr8CNk3xRccCzFWXyYMCF1o3Pemo67P6Lg6FyCt605f6c5x9tW ZCbQoEvrgkKdYjeYmgDTkOFEiudop7pH4vxxTTMY=
To: Russ Housley 
References: <20160518171802.14749.72841.idtracker@ietfa.amsl.com>  <4A0C6BB6-D5F8-47A0-B392-AEBC0859C1FC@aaa-sec.com>  <939935CA-2161-49B8-92D3-FB296CDF4ADE@aaa-sec.com> <4BBCF312-16C1-42E7-B0B2-19229A38101B@vigilsec.com> <574750C9.7090801@cs.tcd.ie> <5BE320B5-320C-41F4-ABF6-F3B99E80E01D@vigilsec.com>
From: Stephen Farrell 
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <57475E22.3090302@cs.tcd.ie>
Date: Thu, 26 May 2016 21:35:46 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0
MIME-Version: 1.0
In-Reply-To: <5BE320B5-320C-41F4-ABF6-F3B99E80E01D@vigilsec.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms080002050707090407040402"
Archived-At: 
Cc: spasm@ietf.org
Subject: Re: [Spasm] draft-housley-spasm-eku-constraints-01.txt
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 26 May 2016 20:35:55 -0000

This is a cryptographically signed message in MIME format.

--------------ms080002050707090407040402
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



On 26/05/16 21:33, Russ Housley wrote:
> Stephen:
>=20
>>=20
>>> The use case that is motivating the excludedKeyPurposeIds field
>>> is the isolation of very special capabilities like code signing.
>>> The current approach dies not do that well.
>>=20
>> Would it be good to put something along those lines in the charter=20
>> text?
>>=20
>> Say "There is a need to isolate some special capabilities enabled=20
>> via PKI from more "normal" end-entity authentication, with the
>> main use case here being separation of code-signing from
>> web-server authentication so that relying parties are not as easily
>> confused between the two."
>>=20
>> I'm sure the wording needs improving (I'd welcome better from
>> anyone on the list) but adding something like that is what I was
>> asking about in the scoping thread.
>=20
> I guess I'm hoping to hear whether any CA believes in this use case.
> The answer to that will tell us whether this meets your deployability
> requirement.

Yes, that'd be good to know. That's a similar point to Richard's
too I guess. I assume we have some folks on here who could ask
the CABForum folks if they'd want this, or maybe there are other
CAs on here who'd be willing to say they'd be interested in
updating their stuff for this.

Cheers,
S.


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


--------------ms080002050707090407040402
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
CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ
BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD
ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll
bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw
aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA
Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra
C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3
rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5
R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r
dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt
3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw
MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ
QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv
BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5
BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu
Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll
bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc
MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE
MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG
9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD
C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9
U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM
aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai
9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC
BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE
BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs
IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g
QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC
SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC
ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv
mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm
VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4
D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI
dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu
N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE
FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp
MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE
WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG
JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+
SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g
BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv
bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY
0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF
NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9
uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p
6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv
Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu
mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7
RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO
/ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN
JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM
MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG
A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0
Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA
oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA1MjYy
MDM1NDZaMC8GCSqGSIb3DQEJBDEiBCDZ+VNIFM0KS5Eq3cpynAqKAWmu1Z5Mfz3lGGG9vNdP
tjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN
AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC
AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw
IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB
nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD
VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq
hkiG9w0BAQEFAASCAQBa4UD9h05S7w9Bc8kF5Lr9kDUwo7DMPu3nWHrGl+eFku4wtTBcTGDD
/KeUMol5tVOun94TI6RiozASpNPjH5MjPgPO+dARPW+w5gGGlkvuo8MQ9/jMcqjTrE0q65O6
V2OJn19YYWouPWNhIMcHAwHZdL1LtJDXxzLc7Y6cp2NhXjRsrzvzjV9WIJtzBZ0iSal87lGZ
bGXncf+AwGVriMrgrULeRPHJSMkKa7h0+9Q+s823YO5FfqComcAPgN+z2NfbU+kzO3ysiQst
KCDwsdgs2BiPPb8SpX/7go1/7ZGRiHNWJuOdD0G+m9EiB16WCvHemV8fvqRrQHeVCNAGAEGN
AAAAAAAA
--------------ms080002050707090407040402--


From nobody Thu May 26 13:48:57 2016
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 F27FB12D9D4 for ; Thu, 26 May 2016 13:48:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.126
X-Spam-Level: 
X-Spam-Status: No, score=-4.126 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, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 xBE1QdxwCY6U for ; Thu, 26 May 2016 13:48:54 -0700 (PDT)
Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::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 886BA12D9E1 for ; Thu, 26 May 2016 13:48:50 -0700 (PDT)
Received: by mail-vk0-x22a.google.com with SMTP id k1so62971595vka.3 for ; Thu, 26 May 2016 13:48:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5ZNn9AZ2c44b7m/cajtX673K3tzt76nJoaUnoRRTHiA=; b=OXS60dwjphM3V8PVkj0/Yo5Id4usI2L+cVH55v6wCIjqMcoaHZ8fwV5fbygrVESXfJ bdih6rvyknCvdcAPRIC3WYcHkQ4XL2KQaIUprKiDDEnzZe+cFRjdZylzjFLTHS1MgA4l jbiobVVXycTWlW2qiSAidS5zCRF2sUFfyTDXqVT3mN06nCotewQnIUAmWQar/3Ii3tql SLTuqTWgs59iz5fVVAs+8QfJNeDt1zDvo3L2tdHkT8GCk2GYHjUvRroaIVB3FtL+mWOX xlfJI9fN3uR2DtLLAdXDyPPbI7by7Jdgnop+3gvtKRi3mXhXBd++L2uI1da1SEIZbC9Z 1oNg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5ZNn9AZ2c44b7m/cajtX673K3tzt76nJoaUnoRRTHiA=; b=CP9M1EqEAWQnQd8krjyuU6imrnY5icW5z/iR95BDLCwV/mlXEt1YVHJaxWkJllstCV eJHFEafa/NUCsY6Fb/WfKWKKKo6InmbZwHwedkk0T7ncCCwFv8XfX23l8bVM5/Cq7Lus BdF2mP3dmHAZ9I8W30S1QBtVtxem6c6wdP3vyn9xa3SsKk+F3sMvbtOpgjIL8Yg2uiSU gvzCObhjeGxeSpgaifG1ysp4k6tUHuDDUGNDbTS37xsfJHuIsS+X3Hcn2Q53rDBwXRtJ dS+4Vqbq1SaILAcGasD85bP33iBCbdYQbxxbBKfQLVe1bPErxwAusTdZz9c9ewGdxAFE b5vw==
X-Gm-Message-State: ALyK8tKleqBgPQy6JV0UG51Wj0QC3xbMb4W739//rp0xHNIMwfLVP01/VNvf/xSlYzj+5xndz8shX7wyOkwpwA7F
X-Received: by 10.31.109.197 with SMTP id i188mr6535735vkc.157.1464295729554;  Thu, 26 May 2016 13:48:49 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.31.67.146 with HTTP; Thu, 26 May 2016 13:48:48 -0700 (PDT)
In-Reply-To: <57475E22.3090302@cs.tcd.ie>
References: <20160518171802.14749.72841.idtracker@ietfa.amsl.com>  <4A0C6BB6-D5F8-47A0-B392-AEBC0859C1FC@aaa-sec.com>  <939935CA-2161-49B8-92D3-FB296CDF4ADE@aaa-sec.com> <4BBCF312-16C1-42E7-B0B2-19229A38101B@vigilsec.com> <574750C9.7090801@cs.tcd.ie> <5BE320B5-320C-41F4-ABF6-F3B99E80E01D@vigilsec.com> <57475E22.3090302@cs.tcd.ie>
From: Laetitia Baudoin 
Date: Thu, 26 May 2016 13:48:48 -0700
Message-ID: 
To: Stephen Farrell 
Content-Type: multipart/alternative; boundary=94eb2c095ec8ceb94c0533c4eaab
Archived-At: 
Cc: spasm@ietf.org, Russ Housley 
Subject: Re: [Spasm] draft-housley-spasm-eku-constraints-01.txt
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 26 May 2016 20:48:56 -0000

--94eb2c095ec8ceb94c0533c4eaab
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On Thu, May 26, 2016 at 1:35 PM, Stephen Farrell 
wrote:

>
>
> On 26/05/16 21:33, Russ Housley wrote:
> > Stephen:
> >
> >>
> >>> The use case that is motivating the excludedKeyPurposeIds field
> >>> is the isolation of very special capabilities like code signing.
> >>> The current approach dies not do that well.
> >>
> >> Would it be good to put something along those lines in the charter
> >> text?
> >>
> >> Say "There is a need to isolate some special capabilities enabled
> >> via PKI from more "normal" end-entity authentication, with the
> >> main use case here being separation of code-signing from
> >> web-server authentication so that relying parties are not as easily
> >> confused between the two."
> >>
> >> I'm sure the wording needs improving (I'd welcome better from
> >> anyone on the list) but adding something like that is what I was
> >> asking about in the scoping thread.
> >
> > I guess I'm hoping to hear whether any CA believes in this use case.
> > The answer to that will tell us whether this meets your deployability
> > requirement.
>
> Yes, that'd be good to know. That's a similar point to Richard's
> too I guess. I assume we have some folks on here who could ask
> the CABForum folks if they'd want this, or maybe there are other
> CAs on here who'd be willing to say they'd be interested in
> updating their stuff for this.
>
> Cheers,
> S.
>

Hasn't the CABForum already settled on using the EKU extensions in
intermediate CA certificates as a way to constrain the uses?
For example:
---
In https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.3.4.pdf
For a Subordinate CA Certificate to be considered Technically Constrained,
the certificate MUST include an Extended Key Usage (EKU) extension
specifying all extended key usages that the Subordinate CA Certificate is
authorized to issue certificates for. The anyExtendedKeyUsage KeyPurposeId
MUST NOT appear within this extension.
---



>
>
> >
> > 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
>
>

--94eb2c095ec8ceb94c0533c4eaab
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


On Thu, May 26, 2016 at 1:35 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:




On 26/05/16 21:33, Russ Housley wrote:

> Stephen:

>

>>

>>> The use case that is motivating the excludedKeyPurposeIds field

>>> is the isolation of very special capabilities like code signing.

>>> The current approach dies not do that well.

>>

>> Would it be good to put something along those lines in the charter

>> text?

>>

>> Say "There is a need to isolate some special capabilities enabled

>> via PKI from more "normal" end-entity authentication, with the

>> main use case here being separation of code-signing from

>> web-server authentication so that relying parties are not as easily

>> confused between the two."

>>

>> I'm sure the wording needs improving (I'd welcome better from

>> anyone on the list) but adding something like that is what I was

>> asking about in the scoping thread.

>

> I guess I'm hoping to hear whether any CA believes in this use case.

> The answer to that will tell us whether this meets your deployability

> requirement.



Yes, that'd be good to know. That's a similar point to Richard's

too I guess. I assume we have some folks on here who could ask

the CABForum folks if they'd want this, or maybe there are other

CAs on here who'd be willing to say they'd be interested in

updating their stuff for this.



Cheers,

S.

Hasn't the CABForum already settled on using the EKU extensions in intermediate CA certificates as a way to constrain the uses?
For example:
---
For	a	Subordinate	CA	Certificate	to	be	considered	Technically	Constrained,	the	certificate	MUST	include	an	
Extended	Key	Usage	(EKU)	extension	specifying	all	extended	key	usages	that	the	Subordinate	CA	Certificate	is	
authorized	to	issue	certificates	for.	The	anyExtendedKeyUsage	KeyPurposeId	MUST	NOT	appear	within	this	
extension.  
---

 






>

> 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





--94eb2c095ec8ceb94c0533c4eaab--


From nobody Thu May 26 13:52:50 2016
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 063AE12D9E6 for ; Thu, 26 May 2016 13:52:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Level: 
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fo_vbtkZAzOG for ; Thu, 26 May 2016 13:52:48 -0700 (PDT)
Received: from mail.smetech.net (mail.smetech.net [209.135.209.4]) by ietfa.amsl.com (Postfix) with ESMTP id 4264812D9B5 for ; Thu, 26 May 2016 13:52:48 -0700 (PDT)
Received: from localhost (ronin.smetech.net [209.135.209.5]) by mail.smetech.net (Postfix) with ESMTP id E14F6F24062 for ; Thu, 26 May 2016 16:52:47 -0400 (EDT)
X-Virus-Scanned: amavisd-new at smetech.net
Received: from mail.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id Z+HEgh125FT5 for ; Thu, 26 May 2016 16:34:48 -0400 (EDT)
Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.smetech.net (Postfix) with ESMTP id 6A0B4F24036 for ; Thu, 26 May 2016 16:52:35 -0400 (EDT)
From: Russ Housley 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Thu, 26 May 2016 16:52:41 -0400
References: <20160526205132.14543.2539.idtracker@ietfa.amsl.com>
To: spasm@ietf.org
Message-Id: <31E7F5CC-927E-4239-87E6-3003557011A4@vigilsec.com>
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
X-Mailer: Apple Mail (2.1878.6)
Archived-At: 
Subject: [Spasm] draft-housley-spasm-eku-constraints-03.txt
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 26 May 2016 20:52:50 -0000

This just fixes the ASN.1 mistake in the version that was posted =
yesterday.

Russ


> From: internet-drafts@ietf.org
> Subject: New Version Notification for =
draft-housley-spasm-eku-constraints-03.txt
> Date: May 26, 2016 at 4:51:32 PM EDT
> To: "Russ Housley" , "Russell Housley" =

>=20
>=20
> A new version of I-D, draft-housley-spasm-eku-constraints-03.txt
> has been successfully submitted by Russell Housley and posted to the
> IETF repository.
>=20
> Name:		draft-housley-spasm-eku-constraints
> Revision:	03
> Title:		Extended Key Usage Constraints
> Document date:	2016-05-26
> Group:		Individual Submission
> Pages:		9
> URL:            =
https://www.ietf.org/internet-drafts/draft-housley-spasm-eku-constraints-0=
3.txt
> Status:         =
https://datatracker.ietf.org/doc/draft-housley-spasm-eku-constraints/
> Htmlized:       =
https://tools.ietf.org/html/draft-housley-spasm-eku-constraints-03
> Diff:           =
https://www.ietf.org/rfcdiff?url2=3Ddraft-housley-spasm-eku-constraints-03=

>=20
> Abstract:
>   This document specifies the extended key usage constraints
>   certificate extension, which is used to place restrictions on the =
key
>   purpose identifiers that are authorized to appear in the end-entity
>   certificate in a certification path.  Restrictions apply to the
>   extended key usage certificate extension, which is described in
>   RFC 5280.


From nobody Thu May 26 15:01:33 2016
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 56FAE12D71A for ; Thu, 26 May 2016 15:01:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eke8Ngy1qGZe for ; Thu, 26 May 2016 15:01:30 -0700 (PDT)
Received: from mail-qg0-x235.google.com (mail-qg0-x235.google.com [IPv6:2607:f8b0:400d:c04::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1587412D1BB for ; Thu, 26 May 2016 15:01:30 -0700 (PDT)
Received: by mail-qg0-x235.google.com with SMTP id q32so43427085qgq.3 for ; Thu, 26 May 2016 15:01:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=F8mTjpTqnjoH0LwIlGb7U9TdfgOy7UG/tTwO+3dDy0g=; b=PdOTt6WuZnHFH0h8Mwidcme80eiN07r12dYZBKdHGpaM8Y6uVeomiyGEgGrVEnlTFD /VSiTTB4MFAlblcNdgHTZ5JyVFu3EGv8kpO9ieDsk9e8J325I4+9NrHPGTIvkX/BarXw f+SVmZn5BOVLJRCqQDPVy8VX1gjWzQf7kA2Jij76rn/pHHJM+Suy+Rh3jXoU7HJIfNR8 DMXtHL/ta+pYIf/7UUYlJswuscsbWVwhbmPe6mqBjqU6g5438pt+8VybN7Grom5Eog8a /n6RR0tHJQKHF0iEFwPkbm4fPkF5LMUSEtU/yQjg4FkqjeXNx0Awo/VnLitTOapZaILN nFAw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=F8mTjpTqnjoH0LwIlGb7U9TdfgOy7UG/tTwO+3dDy0g=; b=W48FltcG88VgZ7ioUWCAKYdFLsPYy58c0sBfa9pSsAryvukxdRqt5gDqnFcisG7pi7 YiPadrpwOuvO4lzDcsJd4cFSkb8+TSda1m3cy7RyXQw3o6EKCT2HU3yBduXAmVzLZngY HIOM37GxUF8NPS97diE/vP46rX1fhkFbFEkIHz1lUXatkn7vIKJ0iGCcHUR/6PmXpoRr GzfSGR8xA91PnU7ssSEKipCfMCEB/k3sNoYT/kQ7CbF/NzLEPgY14OctNU4ecFnEkIM5 NcfLrfQObCoyfICX9lxPCHDaKWdJeQak683/UBaJalnrow59mW9iEWmHmQv6vgTnwQVi wCbA==
X-Gm-Message-State: ALyK8tLnDhkAOzBZnky2jb3wopoXIvAF9wye8S+xKTrQbesOY1m/fD8VNcBZzC8tos5ugg==
X-Received: by 10.140.104.52 with SMTP id z49mr10733469qge.23.1464300089194; Thu, 26 May 2016 15:01:29 -0700 (PDT)
Received: from SantoshBrain (pool-173-73-188-109.washdc.fios.verizon.net. [173.73.188.109]) by smtp.gmail.com with ESMTPSA id m184sm4342212qhm.3.2016.05.26.15.01.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 May 2016 15:01:28 -0700 (PDT)
From: "Santosh Chokhani" 
To: "'Russ Housley'" , 
References: <20160526205132.14543.2539.idtracker@ietfa.amsl.com> <31E7F5CC-927E-4239-87E6-3003557011A4@vigilsec.com>
In-Reply-To: <31E7F5CC-927E-4239-87E6-3003557011A4@vigilsec.com>
Date: Thu, 26 May 2016 18:01:30 -0400
Message-ID: <023401d1b79a$28d6d6f0$7a8484d0$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQIcOgvBQ4AO4fDJuptZE3GFvvismALn5PA5nx9+oaA=
Content-Language: en-us
Archived-At: 
Subject: Re: [Spasm] draft-housley-spasm-eku-constraints-03.txt
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 26 May 2016 22:01:32 -0000

Hi Russ,

Section 2 states "  Conforming applications MUST be able to process this
extension.  If
   any CA certificate in the certification path includes an extended key
   usage constraints extension and the end-entity certificate includes
   an extended key usage certificate extension, then the application
   MUST either process the extended key usage extension constraint or
   reject the certificate."

Since the path validation logic checks constraints even if EKU is absent in
the end-entity certificate, the above text should be revised to state:

"  Conforming applications MUST be able to process this extension.  If
   any CA certificate in the certification path includes an extended key
   usage constraints extension, then the application
   MUST either process the extended key usage extension constraint or
   reject the certificate."

Another option is to delete this text altogether since an application must
process an extension if it understands it regardless of criticality and must
reject the certificate if it does not understand a critical extension.

-----Original Message-----
From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Russ Housley
Sent: Thursday, May 26, 2016 4:53 PM
To: spasm@ietf.org
Subject: [Spasm] draft-housley-spasm-eku-constraints-03.txt

This just fixes the ASN.1 mistake in the version that was posted yesterday.

Russ


> From: internet-drafts@ietf.org
> Subject: New Version Notification for 
> draft-housley-spasm-eku-constraints-03.txt
> Date: May 26, 2016 at 4:51:32 PM EDT
> To: "Russ Housley" , "Russell Housley" 
> 
> 
> 
> A new version of I-D, draft-housley-spasm-eku-constraints-03.txt
> has been successfully submitted by Russell Housley and posted to the 
> IETF repository.
> 
> Name:		draft-housley-spasm-eku-constraints
> Revision:	03
> Title:		Extended Key Usage Constraints
> Document date:	2016-05-26
> Group:		Individual Submission
> Pages:		9
> URL:
https://www.ietf.org/internet-drafts/draft-housley-spasm-eku-constraints-03.
txt
> Status:
https://datatracker.ietf.org/doc/draft-housley-spasm-eku-constraints/
> Htmlized:
https://tools.ietf.org/html/draft-housley-spasm-eku-constraints-03
> Diff:
https://www.ietf.org/rfcdiff?url2=draft-housley-spasm-eku-constraints-03
> 
> Abstract:
>   This document specifies the extended key usage constraints
>   certificate extension, which is used to place restrictions on the key
>   purpose identifiers that are authorized to appear in the end-entity
>   certificate in a certification path.  Restrictions apply to the
>   extended key usage certificate extension, which is described in
>   RFC 5280.

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


From nobody Thu May 26 15:12:08 2016
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 6642E12D507 for ; Thu, 26 May 2016 15:12:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Level: 
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tht94fBe4nTI for ; Thu, 26 May 2016 15:12:04 -0700 (PDT)
Received: from mail.smetech.net (mail.smetech.net [209.135.209.4]) by ietfa.amsl.com (Postfix) with ESMTP id 9185112D1B6 for ; Thu, 26 May 2016 15:12:04 -0700 (PDT)
Received: from localhost (ronin.smetech.net [209.135.209.5]) by mail.smetech.net (Postfix) with ESMTP id 0DBE2F2402A; Thu, 26 May 2016 18:12:04 -0400 (EDT)
X-Virus-Scanned: amavisd-new at smetech.net
Received: from mail.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id Z2i6lv5aiebk; Thu, 26 May 2016 17:54:16 -0400 (EDT)
Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.smetech.net (Postfix) with ESMTP id 6647BF24013; Thu, 26 May 2016 18:12:03 -0400 (EDT)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Russ Housley 
In-Reply-To: <023401d1b79a$28d6d6f0$7a8484d0$@gmail.com>
Date: Thu, 26 May 2016 18:12:07 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20160526205132.14543.2539.idtracker@ietfa.amsl.com> <31E7F5CC-927E-4239-87E6-3003557011A4@vigilsec.com> <023401d1b79a$28d6d6f0$7a8484d0$@gmail.com>
To: Santosh Chokhani 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: 
Cc: spasm@ietf.org
Subject: Re: [Spasm] draft-housley-spasm-eku-constraints-03.txt
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 26 May 2016 22:12:06 -0000

You are correct.  I=92ll make the change in the next version.

Russ


On May 26, 2016, at 6:01 PM, Santosh Chokhani =
 wrote:

> Hi Russ,
>=20
> Section 2 states "  Conforming applications MUST be able to process =
this
> extension.  If
>   any CA certificate in the certification path includes an extended =
key
>   usage constraints extension and the end-entity certificate includes
>   an extended key usage certificate extension, then the application
>   MUST either process the extended key usage extension constraint or
>   reject the certificate."
>=20
> Since the path validation logic checks constraints even if EKU is =
absent in
> the end-entity certificate, the above text should be revised to state:
>=20
> "  Conforming applications MUST be able to process this extension.  If
>   any CA certificate in the certification path includes an extended =
key
>   usage constraints extension, then the application
>   MUST either process the extended key usage extension constraint or
>   reject the certificate."
>=20
> Another option is to delete this text altogether since an application =
must
> process an extension if it understands it regardless of criticality =
and must
> reject the certificate if it does not understand a critical extension.
>=20
> -----Original Message-----
> From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Russ Housley
> Sent: Thursday, May 26, 2016 4:53 PM
> To: spasm@ietf.org
> Subject: [Spasm] draft-housley-spasm-eku-constraints-03.txt
>=20
> This just fixes the ASN.1 mistake in the version that was posted =
yesterday.
>=20
> Russ
>=20
>=20
>> From: internet-drafts@ietf.org
>> Subject: New Version Notification for=20
>> draft-housley-spasm-eku-constraints-03.txt
>> Date: May 26, 2016 at 4:51:32 PM EDT
>> To: "Russ Housley" , "Russell Housley"=20
>> 
>>=20
>>=20
>> A new version of I-D, draft-housley-spasm-eku-constraints-03.txt
>> has been successfully submitted by Russell Housley and posted to the=20=

>> IETF repository.
>>=20
>> Name:		draft-housley-spasm-eku-constraints
>> Revision:	03
>> Title:		Extended Key Usage Constraints
>> Document date:	2016-05-26
>> Group:		Individual Submission
>> Pages:		9
>> URL:
> =
https://www.ietf.org/internet-drafts/draft-housley-spasm-eku-constraints-0=
3.
> txt
>> Status:
> https://datatracker.ietf.org/doc/draft-housley-spasm-eku-constraints/
>> Htmlized:
> https://tools.ietf.org/html/draft-housley-spasm-eku-constraints-03
>> Diff:
> =
https://www.ietf.org/rfcdiff?url2=3Ddraft-housley-spasm-eku-constraints-03=

>>=20
>> Abstract:
>>  This document specifies the extended key usage constraints
>>  certificate extension, which is used to place restrictions on the =
key
>>  purpose identifiers that are authorized to appear in the end-entity
>>  certificate in a certification path.  Restrictions apply to the
>>  extended key usage certificate extension, which is described in
>>  RFC 5280.
>=20
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm
>=20


From nobody Fri May 27 06:04:53 2016
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 44B2412D166 for ; Fri, 27 May 2016 06:04:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 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] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.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 lZBcCfyM5MbI for ; Fri, 27 May 2016 06:04:49 -0700 (PDT)
Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::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 6B6CD12B064 for ; Fri, 27 May 2016 06:04:49 -0700 (PDT)
Received: by mail-vk0-x22a.google.com with SMTP id f66so142583855vkh.2 for ; Fri, 27 May 2016 06:04:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=uBwkMS7YKJCyqkxexoRXS1U8apmoUqI1FJUOq8+r05k=; b=p2RA7QXy6aEdVwQkwimWW8KzCqG2zXcDBQyj1e3yGx3pv3MwYEQNq/LlUzoM4oym4S tmMl29ULEwT7gDCJdkE4P1FjhXTWopgAywVnMaw604ieM5iOY8gJHLdNb0+kA3OK8CMn wnkY+RshOkBcaIIhzhkCk2lBoHxTAXRKWujly8EHJsCSEbb8ANdwUjT2e4z4lfmj2eMJ sf7658TzHK0yIkm7SurgO/HiWhHkaxYZU55SPYr5ree6+V3Bum1Wh8g8BThUsEvtsKm5 7VBXrf2S6lBy8N+pdSF67q4VCJiCHTGAUaR9Jmz6K0tu/kHexwRNI2Arlz8IxxlMyHyq ea8w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=uBwkMS7YKJCyqkxexoRXS1U8apmoUqI1FJUOq8+r05k=; b=ZNJIIBHJzsl9dVV/C9Zlnunr8wZFuj+DmWYKo33uFboxDsECPhgNYTvYRFNrgtg4JE 54Ua9wRzhgCTPbcSLCD5i6o18xWsH/96AO1n/0GQU2exfDwy9mXREvcUYB/p/ml5agL1 fEE6ieZBTjy1Y5bCsDHhwu4PnCKXb+ZEV1jNx015DcHHnEkdMFF1/Uc6a7vYSqOVDDKZ Zn8p7Qa6c+5oIEVQAtEqR1Jj8I5so0Pg7wrpalwh0UfvP/YQUrTD1aA04C311CpsOkI2 3pn9hLJzelUibZytqLbiStffH5brf/jLpSrRNn8mEyRRqJ9svfTNvJAt628N5PvNDUVl BSTw==
X-Gm-Message-State: ALyK8tICy7tlwMwbgS2UOnM/NbZvoJBuoyK8dPqgqEmxv5iuX9MzeW4lxvevl5VINDNw2UoRXON8cIMWen9Ngw==
MIME-Version: 1.0
X-Received: by 10.159.34.206 with SMTP id 72mr7256427uan.79.1464354288339; Fri, 27 May 2016 06:04:48 -0700 (PDT)
Received: by 10.31.48.71 with HTTP; Fri, 27 May 2016 06:04:48 -0700 (PDT)
In-Reply-To: <57475B33.3070201@cs.tcd.ie>
References:  <57475B33.3070201@cs.tcd.ie>
Date: Fri, 27 May 2016 09:04:48 -0400
Message-ID: 
From: Richard Barnes 
To: Stephen Farrell 
Content-Type: multipart/alternative; boundary=94eb2c04ca8c2edb180533d28d6d
Archived-At: 
Cc: spasm@ietf.org
Subject: Re: [Spasm] Let's focus
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 27 May 2016 13:04:52 -0000

--94eb2c04ca8c2edb180533d28d6d
Content-Type: text/plain; charset=UTF-8

On Thu, May 26, 2016 at 4:23 PM, Stephen Farrell 
wrote:

>
> Hiya,
>
> On 26/05/16 21:04, Richard Barnes wrote:
> > Hey all,
> >
> > I'm concerned that the proposed scope [1] for this WG is (1) too broad,
> and
> > (2) inconsistent with the participation so far.
> >
> > The breadth concern is evident in the ambiguity of the name "Some?"  This
> > group should identify some concrete, practical problems in the Internet
> > they need to solve, describe them, and demonstrate that they have the
> right
> > set of stakeholders to develop, implement, and deploy a solution.
>
> Well we can bikeshed names for sure but moving on...
>
> >
> > I'm personally most concerned about the "fix the EKUs" milestone, at
> least
> > as it's realized in [2].
>
> Yeah, me too. The discussion around that has been eerily reminiscent of
> some of the less productive things from the "late" PKIX period.
>
> > From the perspective of someone who works a lot
> > in the Web PKI, this sounds like a request for a feature that has
> negative
> > value.  The incremental value of the proposed feature would be to allow
> > "everything but X" CAs.  Recent experience in the Web PKI has driven home
> > how harmful it can be to have divergent sets of RPs relying on the same
> > PKI, so allowing CAs to be more unconstrained is moving in the wrong
> > direction.
>
> Fair point. If the WG is chartered I think it'd have to decide if
> that's ok or not.


You've kinda got the cart before the horse here.  If this use case isn't
good, then there's no point to having the milestone.



> (Stefan's 1-bit counter-proposal didn't have the
> same property though or am I wrong?)
>
> > I'm not dogmatic on this, but in order to be persuaded, I would
> > need to see active interest from some real CAs, and from the logs of this
> > list, I'm not seeing anyone who's a current participant in the Web PKI
> > (apologies if I've failed to recognize someone).
>
> It'd be good to see that kind of interest in the EKU work yes. Absent
> that, I would guess deployment won't happen.
>

Again, I think demonstrating interest from the relevant community is needed
*before* chartering.  The underlying principal of BoFs, etc., is that spec
here get developed by the people that are going to use them / be affected
by them.  If those people aren't here, we shouldn't charter work.

--Richard


> >
> > I'm also concerned about the "SRV for cert stores" milestone, though I
> > admit I'm not as deep in this space.  Looking at the proposed doc, it
> seems
> > like the SRV adds any value over just looking stuff up at a well-known
> URI,
> > e.g., adding a "x5c" attribute to a WebFinger resource.  Anything that
> > requires special DNS magic (and SRV counts) is going to face significant
> > deployment barriers.  So I would be happier if this were a "define a
> simple
> > cert discovery mechanism for S/MIME" milestone, rather than being bound
> to
> > a specific mechanism.
>
> From my POV, that's yet another experiment in the public-key-retrieval-
> to-support-e2e-messaging-security set of experiments that included the
> openpgp-dane one recently approved. (And I'd be fine with more of those
> experiments too for reasons stated during the IETF LC of the dane work.)
>
> >
> > Overall, it seems like this group should focus on moving the ball forward
> > with regard to making S/MIME deployable in today's Internet -- fixing
> > papercuts around AEAD, i18n, and cert discovery.  The PKIX stuff is
> > unrelated and addresses an entirely different constituency.
>
> I'm personally if the work here isn't all one effort but a small set of
> sorta-diverse efforts. So long as they're likely to be deployed that is.
> If that's not likely, then I'd be for dropping them from the charter.
>
> Cheers,
> S.
>
> >
> > --Richard
> >
> >
> > [1] https://datatracker.ietf.org/doc/charter-ietf-spasm/
> > [2] https://tools.ietf.org/html/draft-housley-spasm-eku-constraints-01
> > [3] https://tools.ietf.org/html/draft-bhjl-x509-srv-00
> >
> >
> >
> > _______________________________________________
> > Spasm mailing list
> > Spasm@ietf.org
> > https://www.ietf.org/mailman/listinfo/spasm
> >
>
>

--94eb2c04ca8c2edb180533d28d6d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Thu, May 26, 2016 at 4:23 PM, Stephen Farrell <=
stephen.farr=
ell@cs.tcd.ie> wrote:


Hiya,



On 26/05/16 21:04, Richard Barnes wrote:

> Hey all,

>

> I'm concerned that the proposed scope [1] for this WG is (1) too b=
road, and

> (2) inconsistent with the participation so far.

>

> The breadth concern is evident in the ambiguity of the name "Some=
?"=C2=A0 This

> group should identify some concrete, practical problems in the Interne=
t

> they need to solve, describe them, and demonstrate that they have the =
right

> set of stakeholders to develop, implement, and deploy a solution.



Well we can bikeshed names for sure but moving on...



>

> I'm personally most concerned about the "fix the EKUs" m=
ilestone, at least

> as it's realized in [2].



Yeah, me too. The discussion around that has been eerily reminiscent=
 of

some of the less productive things from the "late" PKIX period.


> From the perspective of someone who works a lot

> in the Web PKI, this sounds like a request for a feature that has nega=
tive

> value.=C2=A0 The incremental value of the proposed feature would be to=
 allow

> "everything but X" CAs.=C2=A0 Recent experience in the Web P=
KI has driven home

> how harmful it can be to have divergent sets of RPs relying on the sam=
e

> PKI, so allowing CAs to be more unconstrained is moving in the wrong
> direction.



Fair point. If the WG is chartered I think it'd have to decide i=
f

that's ok or not. 

You've kinda got=
 the cart before the horse here.=C2=A0 If this use case isn't good, the=
n there's no point to having the milestone.

=C2=A0
(Stefan's 1-bit counter-proposal didn=
't have the

same property though or am I wrong?)



> I'm not dogmatic on this, but in order to be persuaded, I would
> need to see active interest from some real CAs, and from the logs of t=
his

> list, I'm not seeing anyone who's a current participant in the=
 Web PKI

> (apologies if I've failed to recognize someone).



It'd be good to see that kind of interest in the EKU work yes. A=
bsent

that, I would guess deployment won't happen.

Again, I think demonstrating interest fro=
m the relevant community is needed *before* chartering.=C2=A0 The underlyin=
g principal of BoFs, etc., is that spec here get developed by the people th=
at are going to use them / be affected by them.=C2=A0 If those people aren&=
#39;t here, we shouldn't charter work.

--R=
ichard
=C2=A0

>

> I'm also concerned about the "SRV for cert stores" miles=
tone, though I

> admit I'm not as deep in this space.=C2=A0 Looking at the proposed=
 doc, it seems

> like the SRV adds any value over just looking stuff up at a well-known=
 URI,

> e.g., adding a "x5c" attribute to a WebFinger resource.=C2=
=A0 Anything that

> requires special DNS magic (and SRV counts) is going to face significa=
nt

> deployment barriers.=C2=A0 So I would be happier if this were a "=
define a simple

> cert discovery mechanism for S/MIME" milestone, rather than being=
 bound to

> a specific mechanism.



From my POV, that's yet another experiment in the public-key-ret=
rieval-

to-support-e2e-messaging-security set of experiments that included the

openpgp-dane one recently approved. (And I'd be fine with more of those=


experiments too for reasons stated during the IETF LC of the dane work.)


>

> Overall, it seems like this group should focus on moving the ball forw=
ard

> with regard to making S/MIME deployable in today's Internet -- fix=
ing

> papercuts around AEAD, i18n, and cert discovery.=C2=A0 The PKIX stuff =
is

> unrelated and addresses an entirely different constituency.



I'm personally if the work here isn't all one effort but a s=
mall set of

sorta-diverse efforts. So long as they're likely to be deployed that is=
.

If that's not likely, then I'd be for dropping them from the charte=
r.



Cheers,

S.



>

> --Richard

>

>

> [1] https://datatracker.ietf.org/doc/charte=
r-ietf-spasm/

> [2] https://tools.ietf.org/ht=
ml/draft-housley-spasm-eku-constraints-01

> [3] https://tools.ietf.org/html/draft-bhjl-x5=
09-srv-00

>

>

>


> _______________________=
________________________

> Spasm mailing list

> Spasm@ietf.org

> https://www.ietf.org/mailman/listinfo/spasm

>







--94eb2c04ca8c2edb180533d28d6d--


From nobody Fri May 27 06:44:05 2016
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 A845112DAAE for ; Fri, 27 May 2016 06:44:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.727
X-Spam-Level: 
X-Spam-Status: No, score=-5.727 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=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 ODTE1vMHNnWn for ; Fri, 27 May 2016 06:44:01 -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 F04F212D672 for ; Fri, 27 May 2016 06:44:00 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id B84B1BE7B; Fri, 27 May 2016 14:43:59 +0100 (IST)
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X4jnmG0QDayD; Fri, 27 May 2016 14:43:59 +0100 (IST)
Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 2471ABE4D; Fri, 27 May 2016 14:43:59 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1464356639; bh=+138F34doig9TAvbN5XuIQIM1GHOqOVRoChi8UcbrZc=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=kw6vzKdMFjGEhPH95qLVCuNSWYMO3WodiYp9CH7lCYbPCG+ovv89mwH+XROzdBuF5 V1q3quJDD9QMDgGcS+JIVqbFsxZhu8BIdWgARt9cBmtyI3des53I6Y6QhTcv47QJP5 kOw4CcRSQvgSK1LtRtHm4s4gOFp6WMbk+riDYF+s=
To: Richard Barnes 
References:  <57475B33.3070201@cs.tcd.ie> 
From: Stephen Farrell 
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <57484F1F.3030809@cs.tcd.ie>
Date: Fri, 27 May 2016 14:43:59 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms010903000906040700090205"
Archived-At: 
Cc: spasm@ietf.org
Subject: Re: [Spasm] Let's focus
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 27 May 2016 13:44:03 -0000

This is a cryptographically signed message in MIME format.

--------------ms010903000906040700090205
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


Hiya,

On 27/05/16 14:04, Richard Barnes wrote:
> On Thu, May 26, 2016 at 4:23 PM, Stephen Farrell 
> wrote:
>=20
>>
>> Hiya,
>>
>> On 26/05/16 21:04, Richard Barnes wrote:
>>> Hey all,
>>>
>>> I'm concerned that the proposed scope [1] for this WG is (1) too broa=
d,
>> and
>>> (2) inconsistent with the participation so far.
>>>
>>> The breadth concern is evident in the ambiguity of the name "Some?"  =
This
>>> group should identify some concrete, practical problems in the Intern=
et
>>> they need to solve, describe them, and demonstrate that they have the=

>> right
>>> set of stakeholders to develop, implement, and deploy a solution.
>>
>> Well we can bikeshed names for sure but moving on...
>>
>>>
>>> I'm personally most concerned about the "fix the EKUs" milestone, at
>> least
>>> as it's realized in [2].
>>
>> Yeah, me too. The discussion around that has been eerily reminiscent o=
f
>> some of the less productive things from the "late" PKIX period.
>>
>>> From the perspective of someone who works a lot
>>> in the Web PKI, this sounds like a request for a feature that has
>> negative
>>> value.  The incremental value of the proposed feature would be to all=
ow
>>> "everything but X" CAs.  Recent experience in the Web PKI has driven =
home
>>> how harmful it can be to have divergent sets of RPs relying on the sa=
me
>>> PKI, so allowing CAs to be more unconstrained is moving in the wrong
>>> direction.
>>
>> Fair point. If the WG is chartered I think it'd have to decide if
>> that's ok or not.
>=20
>=20
> You've kinda got the cart before the horse here.  If this use case isn'=
t
> good, then there's no point to having the milestone.

Sorry, I wasn't clear. What I meant was that if this use-case is
included in a charter, then the WG will need to figure out if
"everything but X" CAs is a good/bad idea to support when trying
to solve for the use case.

>=20
>=20
>=20
>> (Stefan's 1-bit counter-proposal didn't have the
>> same property though or am I wrong?)
>>
>>> I'm not dogmatic on this, but in order to be persuaded, I would
>>> need to see active interest from some real CAs, and from the logs of =
this
>>> list, I'm not seeing anyone who's a current participant in the Web PK=
I
>>> (apologies if I've failed to recognize someone).
>>
>> It'd be good to see that kind of interest in the EKU work yes. Absent
>> that, I would guess deployment won't happen.
>>
>=20
> Again, I think demonstrating interest from the relevant community is ne=
eded
> *before* chartering.  The underlying principal of BoFs, etc., is that s=
pec
> here get developed by the people that are going to use them / be affect=
ed
> by them.  If those people aren't here, we shouldn't charter work.

Fully agree.

Earlier though we did say on this list that we only want to charter work
where we do think it'll likely be implemented and likely deployed. If
there's a proposed work item in the current charter text where we do not
think that applies, then it ought be deleted. (Which is what I think
Russ was saying in his mail too.)

So for item#2 in the current draft charter, can people say if they think
the results of that work is/is-not likely to be deployed?

Cheers,
S.


>=20
> --Richard
>=20
>=20
>>>
>>> I'm also concerned about the "SRV for cert stores" milestone, though =
I
>>> admit I'm not as deep in this space.  Looking at the proposed doc, it=

>> seems
>>> like the SRV adds any value over just looking stuff up at a well-know=
n
>> URI,
>>> e.g., adding a "x5c" attribute to a WebFinger resource.  Anything tha=
t
>>> requires special DNS magic (and SRV counts) is going to face signific=
ant
>>> deployment barriers.  So I would be happier if this were a "define a
>> simple
>>> cert discovery mechanism for S/MIME" milestone, rather than being bou=
nd
>> to
>>> a specific mechanism.
>>
>> From my POV, that's yet another experiment in the public-key-retrieval=
-
>> to-support-e2e-messaging-security set of experiments that included the=

>> openpgp-dane one recently approved. (And I'd be fine with more of thos=
e
>> experiments too for reasons stated during the IETF LC of the dane work=
=2E)
>>
>>>
>>> Overall, it seems like this group should focus on moving the ball for=
ward
>>> with regard to making S/MIME deployable in today's Internet -- fixing=

>>> papercuts around AEAD, i18n, and cert discovery.  The PKIX stuff is
>>> unrelated and addresses an entirely different constituency.
>>
>> I'm personally if the work here isn't all one effort but a small set o=
f
>> sorta-diverse efforts. So long as they're likely to be deployed that i=
s.
>> If that's not likely, then I'd be for dropping them from the charter.
>>
>> Cheers,
>> S.
>>
>>>
>>> --Richard
>>>
>>>
>>> [1] https://datatracker.ietf.org/doc/charter-ietf-spasm/
>>> [2] https://tools.ietf.org/html/draft-housley-spasm-eku-constraints-0=
1
>>> [3] https://tools.ietf.org/html/draft-bhjl-x509-srv-00
>>>
>>>
>>>
>>> _______________________________________________
>>> Spasm mailing list
>>> Spasm@ietf.org
>>> https://www.ietf.org/mailman/listinfo/spasm
>>>
>>
>>
>=20
>=20
>=20
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm
>=20


--------------ms010903000906040700090205
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
CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ
BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD
ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll
bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw
aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA
Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra
C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3
rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5
R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r
dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt
3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw
MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ
QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv
BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5
BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu
Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll
bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc
MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE
MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG
9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD
C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9
U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM
aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai
9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC
BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE
BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs
IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g
QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC
SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC
ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv
mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm
VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4
D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI
dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu
N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE
FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp
MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE
WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG
JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+
SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g
BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv
bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY
0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF
NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9
uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p
6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv
Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu
mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7
RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO
/ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN
JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM
MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG
A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0
Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA
oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA1Mjcx
MzQzNTlaMC8GCSqGSIb3DQEJBDEiBCDeE9iSQtbTLtTldcOR/ZWkUvGgMSbO3tmU5j7K5lAv
RjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN
AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC
AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw
IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB
nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD
VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq
hkiG9w0BAQEFAASCAQCSSbG9wOgtwovWm24u0ITZ/SQK01hduBfSgPEngaOejyOQtuR/JW7N
zcAmVXbpoEFnn4d/Rkei4G5kSAFI8oqb+IR+YpgMEt7dtKhfwEtYukpTy4ruFsu2RKudUMCD
jkrbU9fykiqwC9oysLn3MwIF6vmNBaadf+CzUhoyHB2AYBWKCsOp4/gL8ZAwZSdPOtaw/nqY
JHbgeq+nHxMOS8KZvQqCj0xlhOqg1MyP4BOBu9oVQIjdFkQrlSjw7qo+gW/vZHydAcsl36wO
H8pt0gfY0uPc9dcKkEaJG+DAMjAEEWUBYxETu1uGOEvtNJuGKJh7h1uxupEvXin6c/LqGUYQ
AAAAAAAA
--------------ms010903000906040700090205--


From nobody Fri May 27 06:48:06 2016
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 7E26412D975 for ; Fri, 27 May 2016 06:48:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 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] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.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 KQk9y3Ex_214 for ; Fri, 27 May 2016 06:48:03 -0700 (PDT)
Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::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 E57CC12D10D for ; Fri, 27 May 2016 06:48:02 -0700 (PDT)
Received: by mail-vk0-x22a.google.com with SMTP id k1so88580111vka.3 for ; Fri, 27 May 2016 06:48:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=XtzJ6CelwZDCUu3VN4D5CQa8wEDrqTCDxkDYCFtUDT0=; b=XMm31D27EBThM/v8DUGob/EBASI8BH1iZE98dEyc1GtIXyRLGlbCO8J4myVV/EpYZt hcWYFprtDce8MIF3tQbLtDAyiRP1XGXdliHY0ZhIYdddfO3sJcOfXQ+IufIAXXA9r7L/ lIZhtoahiAJSGdwzgEh2/sQE4A5X/mDCNPszqa1+ZlM7c4LuMXFC/6OIh1K+HxdnNZz3 ZHn8gWwDB4AmYTvv12jja5n059K0vuBKpiYe8KVOudyzuBpVyNe6GKqgbazV0ssYKEo6 Ek5iROGZW8gxRRebiIGt1jwIOLNe8PME4aNM67QL4dLrjrX5pu1zexc6J9AziINZu8Pu pPKA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=XtzJ6CelwZDCUu3VN4D5CQa8wEDrqTCDxkDYCFtUDT0=; b=G1MIrlCDL8J1YDLsOWuxyOXDfaoPUBCFZXyzFZ33fpAu+w5u3wZ0bZZVe7jcEqkk9m OFBjN10L4t6bn6/qTFrW/9PcsgKALX6TUPLsjug/1I1V16CYeExSZdpTUfrLIeiZ8q99 yrCCvyysTgKyYPbxWXSbdcE0S6X+zTZHdCnhae2QLReywjRGB5XtubiaPPFI81i3Wk/Y D0FdbUB1Fi6POad2tgfmquGzC9gnPwUsDubyFlM60stpLo9vbEeU8e1TwPMHhMDt8mMM ZeOb7zEd+ZGgtsM9jJvLHj+bN6T0bZa1wiTl0OvrHZ/58+3uLqzUjoSlgsVN8ddrZ6mQ JRMg==
X-Gm-Message-State: ALyK8tJrdDdckFO6gs7IfMK2X5hPw910Xh0VS4In5DC4s1a8eAiPH2tLfShfV7CV4amJ/7VtfZhC/dqeytYETg==
MIME-Version: 1.0
X-Received: by 10.31.84.2 with SMTP id i2mr8444687vkb.132.1464356881892; Fri, 27 May 2016 06:48:01 -0700 (PDT)
Received: by 10.31.48.71 with HTTP; Fri, 27 May 2016 06:48:01 -0700 (PDT)
In-Reply-To: <57484F1F.3030809@cs.tcd.ie>
References:  <57475B33.3070201@cs.tcd.ie>  <57484F1F.3030809@cs.tcd.ie>
Date: Fri, 27 May 2016 09:48:01 -0400
Message-ID: 
From: Richard Barnes 
To: Stephen Farrell 
Content-Type: multipart/alternative; boundary=001a114e60e4c5334c0533d327c9
Archived-At: 
Cc: spasm@ietf.org
Subject: Re: [Spasm] Let's focus
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 27 May 2016 13:48:05 -0000

--001a114e60e4c5334c0533d327c9
Content-Type: text/plain; charset=UTF-8

On Fri, May 27, 2016 at 9:43 AM, Stephen Farrell 
wrote:

>
> Hiya,
>
> On 27/05/16 14:04, Richard Barnes wrote:
> > On Thu, May 26, 2016 at 4:23 PM, Stephen Farrell <
> stephen.farrell@cs.tcd.ie>
> > wrote:
> >
> >>
> >> Hiya,
> >>
> >> On 26/05/16 21:04, Richard Barnes wrote:
> >>> Hey all,
> >>>
> >>> I'm concerned that the proposed scope [1] for this WG is (1) too broad,
> >> and
> >>> (2) inconsistent with the participation so far.
> >>>
> >>> The breadth concern is evident in the ambiguity of the name "Some?"
> This
> >>> group should identify some concrete, practical problems in the Internet
> >>> they need to solve, describe them, and demonstrate that they have the
> >> right
> >>> set of stakeholders to develop, implement, and deploy a solution.
> >>
> >> Well we can bikeshed names for sure but moving on...
> >>
> >>>
> >>> I'm personally most concerned about the "fix the EKUs" milestone, at
> >> least
> >>> as it's realized in [2].
> >>
> >> Yeah, me too. The discussion around that has been eerily reminiscent of
> >> some of the less productive things from the "late" PKIX period.
> >>
> >>> From the perspective of someone who works a lot
> >>> in the Web PKI, this sounds like a request for a feature that has
> >> negative
> >>> value.  The incremental value of the proposed feature would be to allow
> >>> "everything but X" CAs.  Recent experience in the Web PKI has driven
> home
> >>> how harmful it can be to have divergent sets of RPs relying on the same
> >>> PKI, so allowing CAs to be more unconstrained is moving in the wrong
> >>> direction.
> >>
> >> Fair point. If the WG is chartered I think it'd have to decide if
> >> that's ok or not.
> >
> >
> > You've kinda got the cart before the horse here.  If this use case isn't
> > good, then there's no point to having the milestone.
>
> Sorry, I wasn't clear. What I meant was that if this use-case is
> included in a charter, then the WG will need to figure out if
> "everything but X" CAs is a good/bad idea to support when trying
> to solve for the use case.
>
> >
> >
> >
> >> (Stefan's 1-bit counter-proposal didn't have the
> >> same property though or am I wrong?)
> >>
> >>> I'm not dogmatic on this, but in order to be persuaded, I would
> >>> need to see active interest from some real CAs, and from the logs of
> this
> >>> list, I'm not seeing anyone who's a current participant in the Web PKI
> >>> (apologies if I've failed to recognize someone).
> >>
> >> It'd be good to see that kind of interest in the EKU work yes. Absent
> >> that, I would guess deployment won't happen.
> >>
> >
> > Again, I think demonstrating interest from the relevant community is
> needed
> > *before* chartering.  The underlying principal of BoFs, etc., is that
> spec
> > here get developed by the people that are going to use them / be affected
> > by them.  If those people aren't here, we shouldn't charter work.
>
> Fully agree.
>
> Earlier though we did say on this list that we only want to charter work
> where we do think it'll likely be implemented and likely deployed. If
> there's a proposed work item in the current charter text where we do not
> think that applies, then it ought be deleted. (Which is what I think
> Russ was saying in his mail too.)
>
> So for item#2 in the current draft charter, can people say if they think
> the results of that work is/is-not likely to be deployed?
>

On this particular point: I haven't talked to anyone else about this, but
my personal view is that this is very unlikely to get deployed.  In
addition to changes to CA and RP code, it would require substantial
rewriting of the BRs, the related audit standards, and root program
policies.  So it would need to have some significant benefit to offset that
significant cost, and I'm just not seeing that.

--Richard




>
> Cheers,
> S.
>
>
> >
> > --Richard
> >
> >
> >>>
> >>> I'm also concerned about the "SRV for cert stores" milestone, though I
> >>> admit I'm not as deep in this space.  Looking at the proposed doc, it
> >> seems
> >>> like the SRV adds any value over just looking stuff up at a well-known
> >> URI,
> >>> e.g., adding a "x5c" attribute to a WebFinger resource.  Anything that
> >>> requires special DNS magic (and SRV counts) is going to face
> significant
> >>> deployment barriers.  So I would be happier if this were a "define a
> >> simple
> >>> cert discovery mechanism for S/MIME" milestone, rather than being bound
> >> to
> >>> a specific mechanism.
> >>
> >> From my POV, that's yet another experiment in the public-key-retrieval-
> >> to-support-e2e-messaging-security set of experiments that included the
> >> openpgp-dane one recently approved. (And I'd be fine with more of those
> >> experiments too for reasons stated during the IETF LC of the dane work.)
> >>
> >>>
> >>> Overall, it seems like this group should focus on moving the ball
> forward
> >>> with regard to making S/MIME deployable in today's Internet -- fixing
> >>> papercuts around AEAD, i18n, and cert discovery.  The PKIX stuff is
> >>> unrelated and addresses an entirely different constituency.
> >>
> >> I'm personally if the work here isn't all one effort but a small set of
> >> sorta-diverse efforts. So long as they're likely to be deployed that is.
> >> If that's not likely, then I'd be for dropping them from the charter.
> >>
> >> Cheers,
> >> S.
> >>
> >>>
> >>> --Richard
> >>>
> >>>
> >>> [1] https://datatracker.ietf.org/doc/charter-ietf-spasm/
> >>> [2] https://tools.ietf.org/html/draft-housley-spasm-eku-constraints-01
> >>> [3] https://tools.ietf.org/html/draft-bhjl-x509-srv-00
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> 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
> >
>
>

--001a114e60e4c5334c0533d327c9
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Fri, May 27, 2016 at 9:43 AM, Stephen Farrell <=
stephen.farr=
ell@cs.tcd.ie> wrote:


Hiya,




On 27/05/16 14:04, Richard Barnes wrote:

> On Thu, May 26, 2016 at 4:23 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie>

> wrote:

>

>>

>> Hiya,

>>

>> On 26/05/16 21:04, Richard Barnes wrote:

>>> Hey all,

>>>

>>> I'm concerned that the proposed scope [1] for this WG is (=
1) too broad,

>> and

>>> (2) inconsistent with the participation so far.

>>>

>>> The breadth concern is evident in the ambiguity of the name &q=
uot;Some?"=C2=A0 This

>>> group should identify some concrete, practical problems in the=
 Internet

>>> they need to solve, describe them, and demonstrate that they h=
ave the

>> right

>>> set of stakeholders to develop, implement, and deploy a soluti=
on.

>>

>> Well we can bikeshed names for sure but moving on...

>>

>>>

>>> I'm personally most concerned about the "fix the EKUs=
" milestone, at

>> least

>>> as it's realized in [2].

>>

>> Yeah, me too. The discussion around that has been eerily reminisce=
nt of

>> some of the less productive things from the "late" PKIX =
period.

>>

>>> From the perspective of someone who works a lot

>>> in the Web PKI, this sounds like a request for a feature that =
has

>> negative

>>> value.=C2=A0 The incremental value of the proposed feature wou=
ld be to allow

>>> "everything but X" CAs.=C2=A0 Recent experience in t=
he Web PKI has driven home

>>> how harmful it can be to have divergent sets of RPs relying on=
 the same

>>> PKI, so allowing CAs to be more unconstrained is moving in the=
 wrong

>>> direction.

>>

>> Fair point. If the WG is chartered I think it'd have to decide=
 if

>> that's ok or not.

>

>

> You've kinda got the cart before the horse here.=C2=A0 If this use=
 case isn't

> good, then there's no point to having the milestone.




Sorry, I wasn't clear. What I meant was that if this use-ca=
se is

included in a charter, then the WG will need to figure out if

"everything but X" CAs is a good/bad idea to support when trying<=
br>
to solve for the use case.



>

>

>

>> (Stefan's 1-bit counter-proposal didn't have the

>> same property though or am I wrong?)

>>

>>> I'm not dogmatic on this, but in order to be persuaded, I =
would

>>> need to see active interest from some real CAs, and from the l=
ogs of this

>>> list, I'm not seeing anyone who's a current participan=
t in the Web PKI

>>> (apologies if I've failed to recognize someone).

>>

>> It'd be good to see that kind of interest in the EKU work yes.=
 Absent

>> that, I would guess deployment won't happen.

>>

>

> Again, I think demonstrating interest from the relevant community is n=
eeded

> *before* chartering.=C2=A0 The underlying principal of BoFs, etc., is =
that spec

> here get developed by the people that are going to use them / be affec=
ted

> by them.=C2=A0 If those people aren't here, we shouldn't chart=
er work.



Fully agree.



Earlier though we did say on this list that we only want to charter work
where we do think it'll likely be implemented and likely deployed. If
there's a proposed work item in the current charter text where we do no=
t

think that applies, then it ought be deleted. (Which is what I think

Russ was saying in his mail too.)



So for item#2 in the current draft charter, can people say if they think
the results of that work is/is-not likely to be deployed?
<=
div>
On this particular point: I haven't talked to anyone=
 else about this, but my personal view is that this is very unlikely to get=
 deployed.=C2=A0 In addition to changes to CA and RP code, it would require=
 substantial rewriting of the BRs, the related audit standards, and root pr=
ogram policies.=C2=A0 So it would need to have some significant benefit to =
offset that significant cost, and I'm just not seeing that.

--Richard


=C2=A0



Cheers,

S.






>

> --Richard

>

>

>>>

>>> I'm also concerned about the "SRV for cert stores&quo=
t; milestone, though I

>>> admit I'm not as deep in this space.=C2=A0 Looking at the =
proposed doc, it

>> seems

>>> like the SRV adds any value over just looking stuff up at a we=
ll-known

>> URI,

>>> e.g., adding a "x5c" attribute to a WebFinger resour=
ce.=C2=A0 Anything that

>>> requires special DNS magic (and SRV counts) is going to face s=
ignificant

>>> deployment barriers.=C2=A0 So I would be happier if this were =
a "define a

>> simple

>>> cert discovery mechanism for S/MIME" milestone, rather th=
an being bound

>> to

>>> a specific mechanism.

>>

>> From my POV, that's yet another experiment in the public-key-r=
etrieval-

>> to-support-e2e-messaging-security set of experiments that included=
 the

>> openpgp-dane one recently approved. (And I'd be fine with more=
 of those

>> experiments too for reasons stated during the IETF LC of the dane =
work.)

>>

>>>

>>> Overall, it seems like this group should focus on moving the b=
all forward

>>> with regard to making S/MIME deployable in today's Interne=
t -- fixing

>>> papercuts around AEAD, i18n, and cert discovery.=C2=A0 The PKI=
X stuff is

>>> unrelated and addresses an entirely different constituency.
>>

>> I'm personally if the work here isn't all one effort but a=
 small set of

>> sorta-diverse efforts. So long as they're likely to be deploye=
d that is.

>> If that's not likely, then I'd be for dropping them from t=
he charter.

>>

>> Cheers,

>> S.

>>

>>>

>>> --Richard

>>>

>>>

>>> [1] https://datatracker.ietf.org/do=
c/charter-ietf-spasm/

>>> [2] https://tools.iet=
f.org/html/draft-housley-spasm-eku-constraints-01

>>> [3] https://tools.ietf.org/html/draft=
-bhjl-x509-srv-00

>>>

>>>

>>>

>>> _______________________________________________

>>> Spasm mailing list

>>> Spasm@ietf.org

>>> https://www.ietf.org/mailman/listinfo/spasm<=
/a>

>>>

>>

>>

>

>

>

> _______________________________________________

> Spasm mailing list

> Spasm@ietf.org

> https://www.ietf.org/mailman/listinfo/spasm

>







--001a114e60e4c5334c0533d327c9--


From nobody Fri May 27 06:56:57 2016
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 2ABB612D60D for ; Fri, 27 May 2016 06:56:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 d_7J7XiNl111 for ; Fri, 27 May 2016 06:56:54 -0700 (PDT)
Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::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 02F6A12D1A7 for ; Fri, 27 May 2016 06:56:54 -0700 (PDT)
Received: by mail-qk0-x22d.google.com with SMTP id n63so79890159qkf.0 for ; Fri, 27 May 2016 06:56:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:thread-index:content-language; bh=wXYfL8XWMWeb2w42BmfpuEOzgefj7UeSEkGFlbxcFaA=; b=Ae1ajAnnafEXME0Xr7l+3UJ97eGrUIEonrjAnE0z83mhsHvtO7puVeHEkqLnsUvel2 Pew7v0FPWpEDsHZpbZqN9qVCBFkS/Ei2kBmmvROI78bvr4b3xowk3A9iqR/tP09cORju ndj1KUV0lpD7S1ITvqYlrz9lXDpzxvLbF44FN0oQuDh0EDyhhbEqXzu2U8j6ImrlaD/9 4wtbQvpKAamcj3RDxjJP3OgfpuCHgl4bzDQseyzCN642Byr4SAOFs1hI4EIx1F1IODGG e7FbDvRFXLnl502aMFSzaODS5uZz+AhvPyIggYlzR1VjI1mCbGpqKwTcjhFiUtoQWWbm kkrQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:thread-index:content-language; bh=wXYfL8XWMWeb2w42BmfpuEOzgefj7UeSEkGFlbxcFaA=; b=Y2JU53nWS0jtHqBzjWbBf7O1gOa2VkYB3YZqt3O9VxLquRAV83tW6BnDzISw+zjTBN j05ajv1/6fU80w4teAbkmrKtIVmwrIN/1Kvv/tb2xcsba1JmJFjDZxCM0PANIvSFTdU1 q53YHQPF2Jl5I3CvP7gVEgSXPxxKq8ueqtiEn4cs87Qr0856kqyAselzPgX11as3kWcc aEAeYmDZmPoob+Mz4Wy3it4Tz9VqDE3mcNGbRodMMW1Sl0g6/gImbSI9RrKFNa5yzmDl Rh571nL8LNjgak1aaGzuF8YNshX65h4FNHh7/rm+ezmFhPUBxE5N8sj4Ut8/UdAbMyxU r+kA==
X-Gm-Message-State: ALyK8tJtM35FwwkOcIGky1BlXKDtZC29gLMRdif1eOO4TsVU6y6b0Cx0s8uycDAchfeT4w==
X-Received: by 10.55.101.20 with SMTP id z20mr14215010qkb.80.1464357413021; Fri, 27 May 2016 06:56:53 -0700 (PDT)
Received: from SantoshBrain (pool-173-73-188-109.washdc.fios.verizon.net. [173.73.188.109]) by smtp.gmail.com with ESMTPSA id e11sm5254389qkb.39.2016.05.27.06.56.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 27 May 2016 06:56:51 -0700 (PDT)
From: "Santosh Chokhani" 
To: "'Richard Barnes'" , "'Stephen Farrell'" 
References:  <57475B33.3070201@cs.tcd.ie>  <57484F1F.3030809@cs.tcd.ie> 
In-Reply-To: 
Date: Fri, 27 May 2016 09:56:53 -0400
Message-ID: <030101d1b81f$a08edff0$e1ac9fd0$@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0302_01D1B7FE.197EC690"
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQDODWyiGJGQh2nyjMQW+dQYE3niDwHb4s9lAqjaALoC/xLmHwHmhWhxoYjPlWA=
Content-Language: en-us
Archived-At: 
Cc: spasm@ietf.org
Subject: Re: [Spasm] Let's focus
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 27 May 2016 13:56:57 -0000

This is a multipart message in MIME format.

------=_NextPart_000_0302_01D1B7FE.197EC690
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

I agree.  This is unlikely to be deployed.

=20

It would be better for us to see how MSFT and NSS handles EKU in =
intermediate certificates and bite the bullet and document it and may be =
work around the edges if there are security holes and implementers wish =
to close them.

=20

From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Richard Barnes
Sent: Friday, May 27, 2016 9:48 AM
To: Stephen Farrell 
Cc: spasm@ietf.org
Subject: Re: [Spasm] Let's focus

=20

=20

=20

On Fri, May 27, 2016 at 9:43 AM, Stephen Farrell =
 > wrote:


Hiya,


On 27/05/16 14:04, Richard Barnes wrote:
> On Thu, May 26, 2016 at 4:23 PM, Stephen Farrell =
 >
> wrote:
>
>>
>> Hiya,
>>
>> On 26/05/16 21:04, Richard Barnes wrote:
>>> Hey all,
>>>
>>> I'm concerned that the proposed scope [1] for this WG is (1) too =
broad,
>> and
>>> (2) inconsistent with the participation so far.
>>>
>>> The breadth concern is evident in the ambiguity of the name "Some?"  =
This
>>> group should identify some concrete, practical problems in the =
Internet
>>> they need to solve, describe them, and demonstrate that they have =
the
>> right
>>> set of stakeholders to develop, implement, and deploy a solution.
>>
>> Well we can bikeshed names for sure but moving on...
>>
>>>
>>> I'm personally most concerned about the "fix the EKUs" milestone, at
>> least
>>> as it's realized in [2].
>>
>> Yeah, me too. The discussion around that has been eerily reminiscent =
of
>> some of the less productive things from the "late" PKIX period.
>>
>>> From the perspective of someone who works a lot
>>> in the Web PKI, this sounds like a request for a feature that has
>> negative
>>> value.  The incremental value of the proposed feature would be to =
allow
>>> "everything but X" CAs.  Recent experience in the Web PKI has driven =
home
>>> how harmful it can be to have divergent sets of RPs relying on the =
same
>>> PKI, so allowing CAs to be more unconstrained is moving in the wrong
>>> direction.
>>
>> Fair point. If the WG is chartered I think it'd have to decide if
>> that's ok or not.
>
>
> You've kinda got the cart before the horse here.  If this use case =
isn't
> good, then there's no point to having the milestone.

Sorry, I wasn't clear. What I meant was that if this use-case is
included in a charter, then the WG will need to figure out if
"everything but X" CAs is a good/bad idea to support when trying
to solve for the use case.

>
>
>
>> (Stefan's 1-bit counter-proposal didn't have the
>> same property though or am I wrong?)
>>
>>> I'm not dogmatic on this, but in order to be persuaded, I would
>>> need to see active interest from some real CAs, and from the logs of =
this
>>> list, I'm not seeing anyone who's a current participant in the Web =
PKI
>>> (apologies if I've failed to recognize someone).
>>
>> It'd be good to see that kind of interest in the EKU work yes. Absent
>> that, I would guess deployment won't happen.
>>
>
> Again, I think demonstrating interest from the relevant community is =
needed
> *before* chartering.  The underlying principal of BoFs, etc., is that =
spec
> here get developed by the people that are going to use them / be =
affected
> by them.  If those people aren't here, we shouldn't charter work.

Fully agree.

Earlier though we did say on this list that we only want to charter work
where we do think it'll likely be implemented and likely deployed. If
there's a proposed work item in the current charter text where we do not
think that applies, then it ought be deleted. (Which is what I think
Russ was saying in his mail too.)

So for item#2 in the current draft charter, can people say if they think
the results of that work is/is-not likely to be deployed?

=20

On this particular point: I haven't talked to anyone else about this, =
but my personal view is that this is very unlikely to get deployed.  In =
addition to changes to CA and RP code, it would require substantial =
rewriting of the BRs, the related audit standards, and root program =
policies.  So it would need to have some significant benefit to offset =
that significant cost, and I'm just not seeing that.

--Richard



=20


Cheers,
S.



>
> --Richard
>
>
>>>
>>> I'm also concerned about the "SRV for cert stores" milestone, though =
I
>>> admit I'm not as deep in this space.  Looking at the proposed doc, =
it
>> seems
>>> like the SRV adds any value over just looking stuff up at a =
well-known
>> URI,
>>> e.g., adding a "x5c" attribute to a WebFinger resource.  Anything =
that
>>> requires special DNS magic (and SRV counts) is going to face =
significant
>>> deployment barriers.  So I would be happier if this were a "define a
>> simple
>>> cert discovery mechanism for S/MIME" milestone, rather than being =
bound
>> to
>>> a specific mechanism.
>>
>> From my POV, that's yet another experiment in the =
public-key-retrieval-
>> to-support-e2e-messaging-security set of experiments that included =
the
>> openpgp-dane one recently approved. (And I'd be fine with more of =
those
>> experiments too for reasons stated during the IETF LC of the dane =
work.)
>>
>>>
>>> Overall, it seems like this group should focus on moving the ball =
forward
>>> with regard to making S/MIME deployable in today's Internet -- =
fixing
>>> papercuts around AEAD, i18n, and cert discovery.  The PKIX stuff is
>>> unrelated and addresses an entirely different constituency.
>>
>> I'm personally if the work here isn't all one effort but a small set =
of
>> sorta-diverse efforts. So long as they're likely to be deployed that =
is.
>> If that's not likely, then I'd be for dropping them from the charter.
>>
>> Cheers,
>> S.
>>
>>>
>>> --Richard
>>>
>>>
>>> [1] https://datatracker.ietf.org/doc/charter-ietf-spasm/
>>> [2] =
https://tools.ietf.org/html/draft-housley-spasm-eku-constraints-01
>>> [3] https://tools.ietf.org/html/draft-bhjl-x509-srv-00
>>>
>>>
>>>
>>> _______________________________________________
>>> Spasm mailing list
>>> Spasm@ietf.org =20
>>> https://www.ietf.org/mailman/listinfo/spasm
>>>
>>
>>
>
>
>
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org =20
> https://www.ietf.org/mailman/listinfo/spasm
>

=20


------=_NextPart_000_0302_01D1B7FE.197EC690
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable


I agree.=C2=A0 This is unlikely to be deployed.
 
It would be better for us to see how MSFT and NSS handles EKU in =
intermediate certificates and bite the bullet and document it and may be =
work around the edges if there are security holes and implementers wish =
to close them.
 
From:<=
/b> =
Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Richard =
Barnes
Sent: Friday, May 27, 2016 9:48 AM
To: =
Stephen Farrell <stephen.farrell@cs.tcd.ie>
Cc: =
spasm@ietf.org
Subject: Re: [Spasm] Let's =
focus
 
 
 
On Fri, =
May 27, 2016 at 9:43 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie> =
wrote:

Hiya,

On 27/05/16 14:04, Richard Barnes =
wrote:
> On Thu, May 26, 2016 at 4:23 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie&g=
t;
> wrote:
>
>>
>> =
Hiya,
>>
>> On 26/05/16 21:04, Richard Barnes =
wrote:
>>> Hey all,
>>>
>>> I'm =
concerned that the proposed scope [1] for this WG is (1) too =
broad,
>> and
>>> (2) inconsistent with the =
participation so far.
>>>
>>> The breadth =
concern is evident in the ambiguity of the name "Some?"  =
This
>>> group should identify some concrete, practical =
problems in the Internet
>>> they need to solve, describe =
them, and demonstrate that they have the
>> =
right
>>> set of stakeholders to develop, implement, and =
deploy a solution.
>>
>> Well we can bikeshed names =
for sure but moving on...
>>
>>>
>>> =
I'm personally most concerned about the "fix the EKUs" =
milestone, at
>> least
>>> as it's realized in =
[2].
>>
>> Yeah, me too. The discussion around that =
has been eerily reminiscent of
>> some of the less productive =
things from the "late" PKIX =
period.
>>
>>> From the perspective of someone who =
works a lot
>>> in the Web PKI, this sounds like a request =
for a feature that has
>> negative
>>> value.  =
The incremental value of the proposed feature would be to =
allow
>>> "everything but X" CAs.  Recent =
experience in the Web PKI has driven home
>>> how harmful it =
can be to have divergent sets of RPs relying on the same
>>> =
PKI, so allowing CAs to be more unconstrained is moving in the =
wrong
>>> direction.
>>
>> Fair point. If =
the WG is chartered I think it'd have to decide if
>> that's ok =
or not.
>
>
> You've kinda got the cart before the =
horse here.  If this use case isn't
> good, then there's no =
point to having the milestone.
Sorry, I wasn't clear. What I meant was that if this =
use-case is
included in a charter, then the WG will need to figure =
out if
"everything but X" CAs is a good/bad idea to support =
when trying
to solve for the use =
case.

>
>
>
>> (Stefan's 1-bit =
counter-proposal didn't have the
>> same property though or am =
I wrong?)
>>
>>> I'm not dogmatic on this, but in =
order to be persuaded, I would
>>> need to see active =
interest from some real CAs, and from the logs of this
>>> =
list, I'm not seeing anyone who's a current participant in the Web =
PKI
>>> (apologies if I've failed to recognize =
someone).
>>
>> It'd be good to see that kind of =
interest in the EKU work yes. Absent
>> that, I would guess =
deployment won't happen.
>>
>
> Again, I think =
demonstrating interest from the relevant community is needed
> =
*before* chartering.  The underlying principal of BoFs, etc., is =
that spec
> here get developed by the people that are going to use =
them / be affected
> by them.  If those people aren't here, =
we shouldn't charter work.

Fully agree.

Earlier though we =
did say on this list that we only want to charter work
where we do =
think it'll likely be implemented and likely deployed. If
there's a =
proposed work item in the current charter text where we do not
think =
that applies, then it ought be deleted. (Which is what I think
Russ =
was saying in his mail too.)

So for item#2 in the current draft =
charter, can people say if they think
the results of that work =
is/is-not likely to be deployed?
 
On this particular point: I haven't =
talked to anyone else about this, but my personal view is that this is =
very unlikely to get deployed.  In addition to changes to CA and RP =
code, it would require substantial rewriting of the BRs, the related =
audit standards, and root program policies.  So it would need to =
have some significant benefit to offset that significant cost, and I'm =
just not seeing that.
--Richard


 

Cheers,
S.


>
> =
--Richard
>
>
>>>
>>> I'm also =
concerned about the "SRV for cert stores" milestone, though =
I
>>> admit I'm not as deep in this space.  Looking at =
the proposed doc, it
>> seems
>>> like the SRV adds =
any value over just looking stuff up at a well-known
>> =
URI,
>>> e.g., adding a "x5c" attribute to a =
WebFinger resource.  Anything that
>>> requires special =
DNS magic (and SRV counts) is going to face significant
>>> =
deployment barriers.  So I would be happier if this were a =
"define a
>> simple
>>> cert discovery =
mechanism for S/MIME" milestone, rather than being =
bound
>> to
>>> a specific =
mechanism.
>>
>> From my POV, that's yet another =
experiment in the public-key-retrieval-
>> =
to-support-e2e-messaging-security set of experiments that included =
the
>> openpgp-dane one recently approved. (And I'd be fine =
with more of those
>> experiments too for reasons stated during =
the IETF LC of the dane =
work.)
>>
>>>
>>> Overall, it seems =
like this group should focus on moving the ball forward
>>> =
with regard to making S/MIME deployable in today's Internet -- =
fixing
>>> papercuts around AEAD, i18n, and cert =
discovery.  The PKIX stuff is
>>> unrelated and =
addresses an entirely different constituency.
>>
>> =
I'm personally if the work here isn't all one effort but a small set =
of
>> sorta-diverse efforts. So long as they're likely to be =
deployed that is.
>> If that's not likely, then I'd be for =
dropping them from the charter.
>>
>> =
Cheers,
>> S.
>>
>>>
>>> =
--Richard
>>>
>>>
>>> [1] https://datatracker.ietf.org/doc/charter-ietf-spasm/
>>> [2] https://tools.ietf.org/html/draft-housley-spasm-eku-con=
straints-01
>>> [3] https://tools.ietf.org/html/draft-bhjl-x509-srv-00<=
br>>>>
>>>
>>>
>>> =
_______________________________________________
>>> 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
>=

 

------=_NextPart_000_0302_01D1B7FE.197EC690--


From nobody Fri May 27 07:43:18 2016
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 98E4B12D682 for ; Fri, 27 May 2016 07:43:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 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] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.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 RS8ytvL8zq5A for ; Fri, 27 May 2016 07:43:14 -0700 (PDT)
Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c: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 488E712DABD for ; Fri, 27 May 2016 07:43:13 -0700 (PDT)
Received: by mail-vk0-x229.google.com with SMTP id r140so146270614vkf.0 for ; Fri, 27 May 2016 07:43:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=jn+gCwosRYZYIUu3WyXfMIW4dJMMEZa07U35hz9CKKw=; b=QkZICcb9nSbMKBPn9A0mT0SD9kjmCOiRBc+skUK5qUjK93/Om7XHi1qH92LkDHjRGg ysmmN2qFv4V2CSlHeenVVgJuFeUbea/06DcWC0mBpfWvqZxtWRWxOBkInhkY9lo2OVL0 23qrT17Sk4i3xeQ2aWESwB+aXtkyD+mgt9n83scqMrDxEdfrXtsGRJbvUJQCkDfdfbiS /hSH3bs2DvABha/3eBynUAGel1HE99BKoztYy3bv/MeMEMEZ/YJ9hZ7xUbCyW5fcqVdW +fAWMdE0EGj/IwiKfrGpurA64kmyqChhIBqRzCNKAT26e0upWV5jQw0MxebUiA7ClKb8 8B4Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=jn+gCwosRYZYIUu3WyXfMIW4dJMMEZa07U35hz9CKKw=; b=A4RlJs9Rsgo8GfzjaRDPvpdhZ/EBXLx2O+XQbrJxHPlqBiPvve9JIqUxcPj4XlVcmo maEAy1j+JTjwY0O4WcPNM+hfJvXkxmaU0c/C0ZJ2pW7JAhoYRZcBiFfHAG89cz8jCJqc KRiZnb44HfmuoDjLBA7cOK1WNg3dhtisiryk/bEpq/pyJ5AiXG6otwur6LzTSbCB8w6e yYEX9uY9XNXEesBDTnWYII9p+a0UHGAkA2jBgPFuNFp/o+mUb7mobFLtusfY/d7L+YyS vTxyytP/TYsov+JD9teInq4D19yWNAuZflF5f0IkZbJrOJzeFonypUeRcze7bj6XUWij mhHQ==
X-Gm-Message-State: ALyK8tKGaxH+gB6Glepf/ytR97w/nwgBmGgQ6gKxSjumgc1M8xcX7bf85ivY+CJgwMyjpkUfQaRtxcCcLuSKJg==
MIME-Version: 1.0
X-Received: by 10.176.4.102 with SMTP id 93mr8664954uav.125.1464360192151; Fri, 27 May 2016 07:43:12 -0700 (PDT)
Received: by 10.31.48.71 with HTTP; Fri, 27 May 2016 07:43:12 -0700 (PDT)
In-Reply-To: <030101d1b81f$a08edff0$e1ac9fd0$@gmail.com>
References:  <57475B33.3070201@cs.tcd.ie>  <57484F1F.3030809@cs.tcd.ie>  <030101d1b81f$a08edff0$e1ac9fd0$@gmail.com>
Date: Fri, 27 May 2016 10:43:12 -0400
Message-ID: 
From: Richard Barnes 
To: Santosh Chokhani 
Content-Type: multipart/alternative; boundary=94eb2c000bec139c710533d3ed97
Archived-At: 
Cc: spasm@ietf.org, Stephen Farrell 
Subject: Re: [Spasm] Let's focus
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 27 May 2016 14:43:16 -0000

--94eb2c000bec139c710533d3ed97
Content-Type: text/plain; charset=UTF-8

On Fri, May 27, 2016 at 9:56 AM, Santosh Chokhani <
santosh.chokhani@gmail.com> wrote:

> I agree.  This is unlikely to be deployed.
>
>
>
> It would be better for us to see how MSFT and NSS handles EKU in
> intermediate certificates and bite the bullet and document it and may be
> work around the edges if there are security holes and implementers wish to
> close them.
>

To be clear, if you want to cover the browser/OS space, you basically have
the following major RP stacks:
- Microsoft
- Apple
- mozilla::pkix
- NSS
- OpenSSL / BoringSSL

Speaking for the mozilla::pkix and NSS side of things, we would be unlikely
to implement anything without a pretty significant security benefit.

--Richard


> *From:* Spasm [mailto:spasm-bounces@ietf.org] *On Behalf Of *Richard
> Barnes
> *Sent:* Friday, May 27, 2016 9:48 AM
> *To:* Stephen Farrell 
> *Cc:* spasm@ietf.org
> *Subject:* Re: [Spasm] Let's focus
>
>
>
>
>
>
>
> On Fri, May 27, 2016 at 9:43 AM, Stephen Farrell <
> stephen.farrell@cs.tcd.ie> wrote:
>
>
> Hiya,
>
>
> On 27/05/16 14:04, Richard Barnes wrote:
> > On Thu, May 26, 2016 at 4:23 PM, Stephen Farrell <
> stephen.farrell@cs.tcd.ie>
> > wrote:
> >
> >>
> >> Hiya,
> >>
> >> On 26/05/16 21:04, Richard Barnes wrote:
> >>> Hey all,
> >>>
> >>> I'm concerned that the proposed scope [1] for this WG is (1) too broad,
> >> and
> >>> (2) inconsistent with the participation so far.
> >>>
> >>> The breadth concern is evident in the ambiguity of the name "Some?"
> This
> >>> group should identify some concrete, practical problems in the Internet
> >>> they need to solve, describe them, and demonstrate that they have the
> >> right
> >>> set of stakeholders to develop, implement, and deploy a solution.
> >>
> >> Well we can bikeshed names for sure but moving on...
> >>
> >>>
> >>> I'm personally most concerned about the "fix the EKUs" milestone, at
> >> least
> >>> as it's realized in [2].
> >>
> >> Yeah, me too. The discussion around that has been eerily reminiscent of
> >> some of the less productive things from the "late" PKIX period.
> >>
> >>> From the perspective of someone who works a lot
> >>> in the Web PKI, this sounds like a request for a feature that has
> >> negative
> >>> value.  The incremental value of the proposed feature would be to allow
> >>> "everything but X" CAs.  Recent experience in the Web PKI has driven
> home
> >>> how harmful it can be to have divergent sets of RPs relying on the same
> >>> PKI, so allowing CAs to be more unconstrained is moving in the wrong
> >>> direction.
> >>
> >> Fair point. If the WG is chartered I think it'd have to decide if
> >> that's ok or not.
> >
> >
> > You've kinda got the cart before the horse here.  If this use case isn't
> > good, then there's no point to having the milestone.
>
> Sorry, I wasn't clear. What I meant was that if this use-case is
> included in a charter, then the WG will need to figure out if
> "everything but X" CAs is a good/bad idea to support when trying
> to solve for the use case.
>
> >
> >
> >
> >> (Stefan's 1-bit counter-proposal didn't have the
> >> same property though or am I wrong?)
> >>
> >>> I'm not dogmatic on this, but in order to be persuaded, I would
> >>> need to see active interest from some real CAs, and from the logs of
> this
> >>> list, I'm not seeing anyone who's a current participant in the Web PKI
> >>> (apologies if I've failed to recognize someone).
> >>
> >> It'd be good to see that kind of interest in the EKU work yes. Absent
> >> that, I would guess deployment won't happen.
> >>
> >
> > Again, I think demonstrating interest from the relevant community is
> needed
> > *before* chartering.  The underlying principal of BoFs, etc., is that
> spec
> > here get developed by the people that are going to use them / be affected
> > by them.  If those people aren't here, we shouldn't charter work.
>
> Fully agree.
>
> Earlier though we did say on this list that we only want to charter work
> where we do think it'll likely be implemented and likely deployed. If
> there's a proposed work item in the current charter text where we do not
> think that applies, then it ought be deleted. (Which is what I think
> Russ was saying in his mail too.)
>
> So for item#2 in the current draft charter, can people say if they think
> the results of that work is/is-not likely to be deployed?
>
>
>
> On this particular point: I haven't talked to anyone else about this, but
> my personal view is that this is very unlikely to get deployed.  In
> addition to changes to CA and RP code, it would require substantial
> rewriting of the BRs, the related audit standards, and root program
> policies.  So it would need to have some significant benefit to offset that
> significant cost, and I'm just not seeing that.
>
> --Richard
>
>
>
>
>
>
> Cheers,
> S.
>
>
>
> >
> > --Richard
> >
> >
> >>>
> >>> I'm also concerned about the "SRV for cert stores" milestone, though I
> >>> admit I'm not as deep in this space.  Looking at the proposed doc, it
> >> seems
> >>> like the SRV adds any value over just looking stuff up at a well-known
> >> URI,
> >>> e.g., adding a "x5c" attribute to a WebFinger resource.  Anything that
> >>> requires special DNS magic (and SRV counts) is going to face
> significant
> >>> deployment barriers.  So I would be happier if this were a "define a
> >> simple
> >>> cert discovery mechanism for S/MIME" milestone, rather than being bound
> >> to
> >>> a specific mechanism.
> >>
> >> From my POV, that's yet another experiment in the public-key-retrieval-
> >> to-support-e2e-messaging-security set of experiments that included the
> >> openpgp-dane one recently approved. (And I'd be fine with more of those
> >> experiments too for reasons stated during the IETF LC of the dane work.)
> >>
> >>>
> >>> Overall, it seems like this group should focus on moving the ball
> forward
> >>> with regard to making S/MIME deployable in today's Internet -- fixing
> >>> papercuts around AEAD, i18n, and cert discovery.  The PKIX stuff is
> >>> unrelated and addresses an entirely different constituency.
> >>
> >> I'm personally if the work here isn't all one effort but a small set of
> >> sorta-diverse efforts. So long as they're likely to be deployed that is.
> >> If that's not likely, then I'd be for dropping them from the charter.
> >>
> >> Cheers,
> >> S.
> >>
> >>>
> >>> --Richard
> >>>
> >>>
> >>> [1] https://datatracker.ietf.org/doc/charter-ietf-spasm/
> >>> [2] https://tools.ietf.org/html/draft-housley-spasm-eku-constraints-01
> >>> [3] https://tools.ietf.org/html/draft-bhjl-x509-srv-00
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> 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
> >
>
>
>

--94eb2c000bec139c710533d3ed97
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Fri, May 27, 2016 at 9:56 AM, Santosh Chokhani <=
;santosh.ch=
okhani@gmail.com> wrote:
I agree.=C2=A0 This is unlikely to be deployed.<=
/u>
=C2=A0
It would be better for us to =
see how MSFT and NSS handles EKU in intermediate certificates and bite the =
bullet and document it and may be work around the edges if there are securi=
ty holes and implementers wish to close them.

To be clear, if you want to cover the browser/OS =
space, you basically have the following major RP stacks:
- Mi=
crosoft
- Apple
- mozilla::pkix
-=
 NSS
- OpenSSL / BoringSSL

Speak=
ing for the mozilla::pkix and NSS side of things, we would be unlikely to i=
mplement anything without a pretty significant security benefit.

--Richard
=C2=A0
=

From=
: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Richard Barnes=

Sent: Friday, May 27, 2016 9:48 AM
To: Stephen Farrell=
 <stephen=
.farrell@cs.tcd.ie>
Cc: spasm@ietf.org
Subject: Re: [Spasm] Let'=
;s focus
=C2=A0
=C2=A0
=C2=A0
On Fri, May 27, 2016 at 9:43 AM, Stephen Farrell <stephen.farrell@cs.tcd.i=
e> wrote:

Hiya,

On 27/05/16 14:04, Ri=
chard Barnes wrote:
> On Thu, May 26, 2016 at 4:23 PM, Stephen Farrel=
l <stephe=
n.farrell@cs.tcd.ie>
> wrote:
>
>>
>> =
Hiya,
>>
>> On 26/05/16 21:04, Richard Barnes wrote:
&=
gt;>> Hey all,
>>>
>>> I'm concerned that=
 the proposed scope [1] for this WG is (1) too broad,
>> and
&g=
t;>> (2) inconsistent with the participation so far.
>>><=
br>>>> The breadth concern is evident in the ambiguity of the name=
 "Some?"=C2=A0 This
>>> group should identify some co=
ncrete, practical problems in the Internet
>>> they need to sol=
ve, describe them, and demonstrate that they have the
>> right
=
>>> set of stakeholders to develop, implement, and deploy a soluti=
on.
>>
>> Well we can bikeshed names for sure but moving =
on...
>>
>>>
>>> I'm personally most c=
oncerned about the "fix the EKUs" milestone, at
>> least=

>>> as it's realized in [2].
>>
>> Yeah,=
 me too. The discussion around that has been eerily reminiscent of
>&=
gt; some of the less productive things from the "late" PKIX perio=
d.
>>
>>> From the perspective of someone who works a =
lot
>>> in the Web PKI, this sounds like a request for a featur=
e that has
>> negative
>>> value.=C2=A0 The incrementa=
l value of the proposed feature would be to allow
>>> "eve=
rything but X" CAs.=C2=A0 Recent experience in the Web PKI has driven =
home
>>> how harmful it can be to have divergent sets of RPs re=
lying on the same
>>> PKI, so allowing CAs to be more unconstra=
ined is moving in the wrong
>>> direction.
>>
>&=
gt; Fair point. If the WG is chartered I think it'd have to decide if>> that's ok or not.
>
>
> You've kinda g=
ot the cart before the horse here.=C2=A0 If this use case isn't
>=
 good, then there's no point to having the milestone.
=

Sorry, I wasn't clear. What I meant =
was that if this use-case is
included in a charter, then the WG will nee=
d to figure out if
"everything but X" CAs is a good/bad idea t=
o support when trying
to solve for the use case.

>
>
=
>
>> (Stefan's 1-bit counter-proposal didn't have the>> same property though or am I wrong?)
>>
>>>=
 I'm not dogmatic on this, but in order to be persuaded, I would
>=
;>> need to see active interest from some real CAs, and from the logs=
 of this
>>> list, I'm not seeing anyone who's a curren=
t participant in the Web PKI
>>> (apologies if I've failed =
to recognize someone).
>>
>> It'd be good to see that=
 kind of interest in the EKU work yes. Absent
>> that, I would gue=
ss deployment won't happen.
>>
>
> Again, I think =
demonstrating interest from the relevant community is needed
> *befor=
e* chartering.=C2=A0 The underlying principal of BoFs, etc., is that spec> here get developed by the people that are going to use them / be aff=
ected
> by them.=C2=A0 If those people aren't here, we shouldn=
9;t charter work.

Fully agree.

Earlier though we did say on t=
his list that we only want to charter work
where we do think it'll l=
ikely be implemented and likely deployed. If
there's a proposed work=
 item in the current charter text where we do not
think that applies, th=
en it ought be deleted. (Which is what I think
Russ was saying in his ma=
il too.)

So for item#2 in the current draft charter, can people say =
if they think
the results of that work is/is-not likely to be deployed?<=
u>
=C2=A0<=
/u>
On =
this particular point: I haven't talked to anyone else about this, but =
my personal view is that this is very unlikely to get deployed.=C2=A0 In ad=
dition to changes to CA and RP code, it would require substantial rewriting=
 of the BRs, the related audit standards, and root program policies.=C2=A0 =
So it would need to have some significant benefit to offset that significan=
t cost, and I'm just not seeing that.
--Richard


=C2=A0

Cheers,
S.


&=
gt;
> --Richard
>
>
>>>
>>> I'=
;m also concerned about the "SRV for cert stores" milestone, thou=
gh I
>>> admit I'm not as deep in this space.=C2=A0 Looking=
 at the proposed doc, it
>> seems
>>> like the SRV add=
s any value over just looking stuff up at a well-known
>> URI,
=
>>> e.g., adding a "x5c" attribute to a WebFinger resour=
ce.=C2=A0 Anything that
>>> requires special DNS magic (and SRV=
 counts) is going to face significant
>>> deployment barriers.=
=C2=A0 So I would be happier if this were a "define a
>> simp=
le
>>> cert discovery mechanism for S/MIME" milestone, rat=
her than being bound
>> to
>>> a specific mechanism.>>
>> From my POV, that's yet another experiment in th=
e public-key-retrieval-
>> to-support-e2e-messaging-security set o=
f experiments that included the
>> openpgp-dane one recently appro=
ved. (And I'd be fine with more of those
>> experiments too fo=
r reasons stated during the IETF LC of the dane work.)
>>
>&=
gt;>
>>> Overall, it seems like this group should focus on m=
oving the ball forward
>>> with regard to making S/MIME deploya=
ble in today's Internet -- fixing
>>> papercuts around AEAD=
, i18n, and cert discovery.=C2=A0 The PKIX stuff is
>>> unrelat=
ed and addresses an entirely different constituency.
>>
>>=
; I'm personally if the work here isn't all one effort but a small =
set of
>> sorta-diverse efforts. So long as they're likely to =
be deployed that is.
>> If that's not likely, then I'd be =
for dropping them from the charter.
>>
>> Cheers,
>=
> S.
>>
>>>
>>> --Richard
>>&g=
t;
>>>
>>> [1] https://datatracker.ietf.org=
/doc/charter-ietf-spasm/
>>> [2] http=
s://tools.ietf.org/html/draft-housley-spasm-eku-constraints-01
>&=
gt;> [3] https://tools.ietf.org/html/draft-bhjl-x509-srv-00>>>
>>>
>>>
>>> _____________=
__________________________________
>>> Spasm mailing list
&g=
t;>> Spasm@ietf.o=
rg
>>> https://www.ietf.org/mailman/listinfo/spasm
&g=
t;>>
>>
>>
>
>
>
> ________=
_______________________________________
> Spasm mailing list
> =
Spasm@ietf.org
&=
gt; https://www.ietf.org/mailman/listinfo/spasm
>
=C2=A0=




--94eb2c000bec139c710533d3ed97--


From nobody Fri May 27 10:27:21 2016
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 59CE012D792 for ; Fri, 27 May 2016 10:27:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.116
X-Spam-Level: 
X-Spam-Status: No, score=-4.116 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, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 xhFyEzh4pozi for ; Fri, 27 May 2016 10:27:16 -0700 (PDT)
Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::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 619B212D768 for ; Fri, 27 May 2016 10:27:14 -0700 (PDT)
Received: by mail-oi0-x22e.google.com with SMTP id k23so184305067oih.0 for ; Fri, 27 May 2016 10:27:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=BbhEf9tPPBcA5qgdKggSNPKW8EysNiGBbgJ+4l664q0=; b=OCUGerjkmRzpddPjHMxMpC4ehvqu5T8fpSRN2yC8R6FPYEqewP+g69FI0LTGM23hzr QFr8CP1eIhGx0wphzYIm+aDmzPnpGMF+EnvgBs7Uz+O2TGN3PZwTkJmmBdaN5x4Hn5Lj dzk0YhM+egnz4IopfoIDJ1b0XrrETe75EtXwfzmvHlG+Uu58HpS+NeIUDtLdRFFQVZP/ PEYEeA+SsUfao4VIymE/X/3LODwwMWinY5HwsNN1qerjy7N1Qn+q3FBNML+76NcGHVsZ XxWmbDM8X6N5PYgKmk0gxpAWZ84CF8WGyXjnh+xyYAEYQTKoOZsF+Ugn19huQvccze4D V2WQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=BbhEf9tPPBcA5qgdKggSNPKW8EysNiGBbgJ+4l664q0=; b=FgnxfZB+3HLKJaFQk9g/0QRW9gzbmjJzdYzeevs58/DmTwq2yCVFuG6zoA0udlgl5q gzDSN0VKXaYQI4yL4WNLS01N5p+SwKSs9DVLqX2U+gkHA+ccB/jPt++vRjXw8Q2njsKI wwxIG9XrPyLhKsetee5pla3tz9oW+Ixrbn439MIRKp3tewLbDGbUPfz94IDmrVH/CGoG eSaggE/DmjstOBOpRMEgPhGwzl6l+ooT9j4UtnsZ4tjiGTD7cq+lgED4Q0cYsKBQC0sf qjioQbafMNKQ1uS9Z1r17Dd23M/FNeLDV3EcPHZawXLhiiWY9tySfnT8J5ftnmakmHWr cAkQ==
X-Gm-Message-State: ALyK8tIyzZGR2u/eIXi1+oatxzeuj30D1vEs+wQ6oOqT7kCW/vEKTrMc8tCiO6z25Ax1CuMzOpn/Q8li8IVg+o6e
X-Received: by 10.202.106.78 with SMTP id f75mr9359964oic.80.1464370033630; Fri, 27 May 2016 10:27:13 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.157.1.67 with HTTP; Fri, 27 May 2016 10:27:13 -0700 (PDT)
From: Wei Chuang 
Date: Fri, 27 May 2016 10:27:13 -0700
Message-ID: 
To: spasm@ietf.org
Content-Type: multipart/alternative; boundary=001a11407722ad09cc0533d6374f
Archived-At: 
Subject: [Spasm] New Version for draft-melnikov-spasm-eai-addresses-01: Comments welcome
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 27 May 2016 17:27:19 -0000

--001a11407722ad09cc0533d6374f
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Hi all,

Your comments from the earlier draft-ietf-pkix-eai-addresses-01 draft have
been incorporated in draft-melnikov-spasm-eai-addresses-01.  Feedback very
much welcome.

thanks
-Wei

---------- Forwarded message ----------
From: 
Date: Fri, May 27, 2016 at 3:56 AM
Subject: New Version Notification for
draft-melnikov-spasm-eai-addresses-01.txt
To: Alexey Melnikov , Weihaw Chuang <
weihaw@google.com>, Alexey Melnikov 



A new version of I-D, draft-melnikov-spasm-eai-addresses-01.txt
has been successfully submitted by Weihaw Chuang and posted to the
IETF repository.

Name:           draft-melnikov-spasm-eai-addresses
Revision:       01
Title:          Internationalized Email Addresses in X.509 certificates
Document date:  2016-05-26
Group:          Individual Submission
Pages:          5
URL:            https://www.ietf.org/internet-drafts/draft-melnikov-spasm-
eai-addresses-01.txt
Status:         https://datatracker.ietf.org/doc/draft-melnikov-spasm-eai-
addresses/
Htmlized:       https://tools.ietf.org/html/draft-melnikov-spasm-eai-
addresses-01
Diff:           https://www.ietf.org/rfcdiff?url2=draft-melnikov-spasm-eai-
addresses-01

Abstract:
   This document defines a new name form for inclusion in the otherName
   field of an X.509 Subject Alternative Name extension that allows a
   certificate subject to be associated with an Internationalized Email
   Address.




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

--001a11407722ad09cc0533d6374f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


Hi all,

Your comments from the earlier draft-ietf-pkix-eai-addresses-01 draft have been incorporated in draft-melnikov-spasm-eai-addresses-01.  Feedback very much welcome.

thanks
-Wei

---------- Forwarded message ----------
From:  <internet-drafts@ietf.org>
Date: Fri, May 27, 2016 at 3:56 AM
Subject: New Version Notification for draft-melnikov-spasm-eai-addresses-01.txt
To: Alexey Melnikov <alexey.melnikov@isode.com>, Weihaw Chuang <weihaw@google.com>, Alexey Melnikov <Alexey.Melnikov@isode.com>




A new version of I-D, draft-melnikov-spasm-eai-addresses-01.txt

has been successfully submitted by Weihaw Chuang and posted to the

IETF repository.



Name:           draft-melnikov-spasm-eai-addresses

Revision:       01

Title:          Internationalized Email Addresses in X.509 certificates

Document date:  2016-05-26

Group:          Individual Submission

Pages:          5

URL:            https://www.ietf.org/internet-drafts/draft-melnikov-spasm-eai-addresses-01.txt

Status:         https://datatracker.ietf.org/doc/draft-melnikov-spasm-eai-addresses/

Htmlized:       https://tools.ietf.org/html/draft-melnikov-spasm-eai-addresses-01

Diff:           https://www.ietf.org/rfcdiff?url2=draft-melnikov-spasm-eai-addresses-01



Abstract:

   This document defines a new name form for inclusion in the otherName

   field of an X.509 Subject Alternative Name extension that allows a

   certificate subject to be associated with an Internationalized Email

   Address.









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







--001a11407722ad09cc0533d6374f--


From nobody Fri May 27 11:00:08 2016
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 A371F12DB24 for ; Fri, 27 May 2016 11:00:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.126
X-Spam-Level: 
X-Spam-Status: No, score=-4.126 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, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 z_Z9_hOMueWR for ; Fri, 27 May 2016 11:00:06 -0700 (PDT)
Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::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 0723012DB41 for ; Fri, 27 May 2016 10:59:58 -0700 (PDT)
Received: by mail-oi0-x230.google.com with SMTP id k23so185615943oih.0 for ; Fri, 27 May 2016 10:59:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=mqtpL+o5w7tkc3OIT8qTk+cgYngHRWJFsYXo0v1yTE4=; b=mk2jXZxdbwWvaTamtmr0FNBZL3+/Mff82Crcr8d6xROEM774ST4C8f3LZL1cMBjixi QYMp6G5J2iOVJWw2G5qowt0ijha9lgqrBgckyf4U9Zw44Vx73YmRAAXvXBw4HseTQ48K dmlWwPyV3ouya8yUlsmbyj6x7S8YPAMauxMiylfOpKW6AmD7EE+bGn9a4ntB1FTdv1IY NHfm5RtdFC5OJyb34MPp0PX9N0MZlc6arMruF2ZOzUT2qE95Vsn51FS/1aOTUdvLeWei dDH5sY2ubZJw76SqA5S6JPJbzgZnckbzpe6JRc/9w0b7MvS2FLgZ5tGBYhidjUZ1q25c 7D8A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=mqtpL+o5w7tkc3OIT8qTk+cgYngHRWJFsYXo0v1yTE4=; b=b2GDj7RkRKH7hO6Vw4iAOaypORfLYzaVYwi8XtuASwfyCqx9WlDsMKmuwFu18CcsdN PqWWzJm5tYIPwEhXBi716BBpJQ7t149fhokoG8ok5OQnfZzT8jxqVMq/vGZAzqgKa1CN AhfZ2v1OLSpL3UM/0gRCKbmcuc7rhPIZGz97/Vqq0lA8p+XR1EsWVlzPQDW8xLXOSoah eiy7HTybVDu83f1tegvnxHopoyWzT6IWIQCpQIyEzcvgqdh9f01L7tJI40+tQ13tK6Cp h8p3Eh5WitRdI3fzYMIwu8hNvDzTBLYBuRJTahqYvTTfcHaNmDFt4M9313viOM3NPhub eZHw==
X-Gm-Message-State: ALyK8tLzqp9q24ILGGQX0cbxciLtp/PTAlGSFwCwX6OPl4oB7/vo6tdLwv1F7fxvHWC8vbRqmv6GnLKHwiRsNw7k
X-Received: by 10.157.11.103 with SMTP id p36mr11021676otd.21.1464371997285; Fri, 27 May 2016 10:59:57 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.157.1.67 with HTTP; Fri, 27 May 2016 10:59:56 -0700 (PDT)
From: Wei Chuang 
Date: Fri, 27 May 2016 10:59:56 -0700
Message-ID: 
To: spasm@ietf.org
Content-Type: multipart/alternative; boundary=001a1135d108b7ff3f0533d6ac21
Archived-At: 
Subject: [Spasm] Spasm work for mail header security?
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
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, 27 May 2016 18:00:07 -0000

--001a1135d108b7ff3f0533d6ac21
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Hi folks,

Header privacy and security with S/MIME (and PGP) has long been an
important topic.  One just has to look in the S/MIME archive to see that it
has been discussed at least four times with mention of significant
discussions at IETF meetings.  While mechanisms are well described in RFC
5751 (header wrapping in message/rfc822) and alternatively in RFC 7508
(Secured Headers as signed attributes), when to use it and what headers
should be secured are both open issues and should be standardized.  The
latter I'm told is hard issue but if progress can be made standardizing
just the behavior for "Subject" much progress will be made.

So I'm asking if Spasm is interested in working on this?  The work could be
incorporated into draft-schaad-rfc5751-bis-00 or as a new draft.  I'm
willing to work on an implementation for this.

thanks,
-Wei

--001a1135d108b7ff3f0533d6ac21
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


Hi folks,

Header privacy and security with S/MIME (and PGP) has long been an important topic.  One just has to look in the S/MIME archive to see that it has been discussed at least four times with mention of significant discussions at IETF meetings.  While mechanisms are well described in RFC 5751 (header wrapping in message/rfc822) and alternatively in RFC 7508 (Secured Headers as signed attributes), when to use it and what headers should be secured are both open issues and should be standardized.  The latter I'm told is hard issue but if progress can be made standardizing just the behavior for "Subject" much progress will be made.  

So I'm asking if Spasm is interested in working on this?  The work could be incorporated into draft-schaad-rfc5751-bis-00 or as a new draft.  I'm willing to work on an implementation for this.

thanks,
-Wei


--001a1135d108b7ff3f0533d6ac21--


There is one more argument for the alternative soluti=
on to just set a binary value that declares that EKU in CA certs have a cons=
training property. (compatible with many current CA certs)=

 
The advantage with this is that this bit could also be a=
dded as an input parameter to path processing, when the certs in use donR=
17;t have them yet.
That would make it legal do do this const=
raining processing on existing certs that do not yet have this new extension=
 included.
 
We all know how hard and cos=
tly it can be to re-issue CA certificates.
We will therefore =
have to live with old non-compliant certificates for a long time (some of th=
ese certificates are very long lived).
 
=
Microsoft have/had property settings for trusted certificates in cert stores=
, which are passed as input parameters to path processing.=

If=
 the extension we define is just a binary value that endorses the current in=
tended constraining effect of EKUs in CA certificates, then that would be mo=
re compatible with passing the same logic through property parameters in cer=
t stores as backup for certificates that don’t have this extension yet=
.
 
It is not so clear to me what the com=
parable situation would be with the new extension.
The risk i=
s that there will be a mess with different ways to constrain in the same pat=
h. 
 
-=
     &nb=
sp;    Property parameter in the cert store suggest som=
e EKU constraining
-      &nbs=
p;   Some CA certs in the path constrain through EKU extenso=
n
-          Some CA certs in the path contstain through the new extension.
 
The risk is that two implementers will do this w=
ith incompatible results.
 
/Stefan<=
/o:p>
 
 
 
=
 
From: Spasm <spasm-bounces@ietf.org> on behalf of Wei Chuang &l=
t;weihaw@google.com>
Date: Wednesday 25 May 2016 at 19:43
To: Russ Housley <housley@vigilsec.com>
Cc: <spasm@i=
etf.org>, Stefan Santesson <stefan@aaa-sec.com>
Subject: =
Re: [Spasm] draft-housley-spasm-eku-constraints-01.txt
=

 
I think Stefan's simplification would be better for depl=
oyment.  There are already many existing server certificates with inter=
mediate CA EKU constraints in their path.