From nobody Thu Nov 9 08:06:43 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B65E4126557 for ; Thu, 9 Nov 2017 08:06:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 t4xnpRnkkRbB for ; Thu, 9 Nov 2017 08:06:41 -0800 (PST) Received: from mail-ot0-x232.google.com (mail-ot0-x232.google.com [IPv6:2607:f8b0:4003:c0f::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 2035B1286AB for ; Thu, 9 Nov 2017 08:06:36 -0800 (PST) Received: by mail-ot0-x232.google.com with SMTP id 15so5704583otj.7 for ; Thu, 09 Nov 2017 08:06:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to; bh=GsUESwac3/0mY5nfWMfwZdzaIJK8WnNxNkCXtDVokak=; b=QRt7hQOYFfi1Fq/GLUOQWHRyzzGFNCOsJJcN0/yV40FbGLDyLSpJC1wXZKbrg5thLd RgTDmViz/UD60wYjyLjBMxLNielyAo1s68igb8Zth7Wxz01T6513rIy71DeZEQ6Ydzu5 zyzWlLeoPnKSe14xVIQTi5twCOl87RauQC4C2KMO1ViKWyrWSA/TVask1JF0xAo5unDA cimROVHtlKdEKDYgRCnZTEPhahm5Azp8H3ySZ0dDqySOzLmPYQqtATx+QLvcTIbCrW05 i9gW5JdS9Zzd4ut/P9FSSHiG0bGWRsvdYYn+g4eSoNJS8lnBcdakIiVkP8ZTN6UqcyG/ p+zA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=GsUESwac3/0mY5nfWMfwZdzaIJK8WnNxNkCXtDVokak=; b=ez1Z+2aPj+tRB+C6mhaI2zp2Q5/2m0ml8iZydAuZi3b/8oIMlyekQ/Daqkt+E/zyVj Qo/qcEoBhQ3PkZ5lGNUpijrZ6VLvxkLYpZciwjw7/hz2LryFddvp4UdQS/hM+j3V4IQF tWbi/mqE/Wufy2Nogy5CfCjLRIW1ASMdlzAb2AUt+vmOWYf1/fO2UxrVFCw1ctV1O2+x WJ+HbRGS250yWwzeE610ryP1Bodx4PcuQVCtVz8210RYoQw2jPlScocNuG3MS4RALWe+ jRNcA2oHjCwwDISOs3ZJ4YZap2uij3nsdQcVyf3MC8O9kSIJOfVOdmeJBzfyN5BIabX4 qHwg== X-Gm-Message-State: AJaThX7VPMN5UtDtFgA3m/xJjHQCUqrpG9tdaUJNQfIO451lTzOBgbtA eWt8Kg8wRBpuLKB0QwH4MkOeIDADElq1ysrpoFqaEA== X-Google-Smtp-Source: AGs4zMYoi8PHYkKj5PFGM2p/lYA/qoF3+g8Xdl+9p1qCT9psPi+PmSRtN8/VabTpcmhaOt4aopicvxAg16EEDYy4JeI= X-Received: by 10.157.61.226 with SMTP id l89mr652873otc.269.1510243595046; Thu, 09 Nov 2017 08:06:35 -0800 (PST) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.157.42.230 with HTTP; Thu, 9 Nov 2017 08:06:34 -0800 (PST) From: Phillip Hallam-Baker Date: Thu, 9 Nov 2017 11:06:34 -0500 X-Google-Sender-Auth: PqiV7f9qShHx5EALTwA4vhYIHSU Message-ID: To: SPASM , Olafur Gudmundsson Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [lamps] DNS DNAME pain. X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Nov 2017 16:06:42 -0000 I am trying to work out whether the restrictions in RFC6672 make use of prefix records impossible. Specifically, a DNAME is not allowed to have any records below it and worse, section 2.4 states: "A server MAY refuse to load a zone that has data at a subdomain of a domain name owning a DNAME RR. If the server does load the zone, those names below the DNAME RR will be occluded as described in RFC 2136 [RFC2136], Section 7.18." This is called making things hard. DNAME was originally developed to help manage reverse DNS during IP address space renumbering, a problem we solved by abandoning the reverse DNS. It is really not suited for the task it is used for (as we have discovered when trying to use it for forward DNS, What this means is that we can't have RRs like the following: example.net DNAME example.com _prefix.example.net CAA foo It is not clear to me how the following is required to be interpreted: example.net DNAME example.com example.net CAA foo The situation is of course very different depending on what forms of DNS zone validation are performed in deployed systems and indeed whether the restrictions on DNAME mean that it is either not used at all or if the existing uses already violate parts of RFC6672. It might well be that the way to solve the DNAME problem is to specify a new zone mapping record that does the job in a way that meets DNS admins needs. That is currently a possibility because use of DNSSEC is mostly limited to signing. The only folk verifying are folk who either really know what they are doing or whose systems are always breaking anyway. That window is likely to close at some point. From nobody Thu Nov 9 08:30:08 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA1AA126557 for ; Thu, 9 Nov 2017 08:30:07 -0800 (PST) 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, 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 yypt_zWi06ai for ; Thu, 9 Nov 2017 08:30:05 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 35A4D1201F2 for ; Thu, 9 Nov 2017 08:30:05 -0800 (PST) Received: (qmail 15881 invoked from network); 9 Nov 2017 16:30:04 -0000 Received: from unknown (64.57.183.53) by gal.iecc.com with QMQP; 9 Nov 2017 16:30:04 -0000 Date: 9 Nov 2017 16:29:41 -0000 Message-ID: <20171109162941.3670.qmail@ary.lan> From: "John Levine" To: spasm@ietf.org Cc: phill@hallambaker.com In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [lamps] DNS DNAME pain. X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Nov 2017 16:30:08 -0000 In article you write: >reverse DNS. It is really not suited for the task it is used for (as >we have discovered when trying to use it for forward DNS, No argument there. >What this means is that we can't have RRs like the following: > >example.net DNAME example.com >_prefix.example.net CAA foo Right. >It is not clear to me how the following is required to be interpreted: > >example.net DNAME example.com >example.net CAA foo DNAME only maps names below it, so the CAA is fine. >It might well be that the way to solve the DNAME problem is to specify >a new zone mapping record that does the job in a way that meets DNS >admins needs. ... There's a BNAME proposal kicking around that is sort of a combined CNAME and DNAME, mapping everything at and below the name. Or do you mean something else like a translucent DNAME that only maps if there's nothing at the actual name? R's, John From nobody Thu Nov 9 08:48:09 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DA99124C27 for ; Thu, 9 Nov 2017 08:48:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 n5LXrI_mXgr6 for ; Thu, 9 Nov 2017 08:48:01 -0800 (PST) Received: from mail-ot0-x230.google.com (mail-ot0-x230.google.com [IPv6:2607:f8b0:4003:c0f::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 0E4FB12025C for ; Thu, 9 Nov 2017 08:48:01 -0800 (PST) Received: by mail-ot0-x230.google.com with SMTP id b49so2488705otj.5 for ; Thu, 09 Nov 2017 08:48:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=WJsRP3tJeSALwM8T60lBEdmSI12Ww6Fp7Kj6tASv6Ro=; b=cezx0ejS7TjgrpYtkAlTtHke9GONjKGWdvWUgU1/XHCzVZSBMCFuRFQgPwdSo7ND4q 3CfvOR8mcbD1bUxJPE2JQZgs1+x4GGC5IDjG6g1Vbh1yJQIlzqIjPZ912PdMzL9bKhR3 W0x0Dyzdcl9B6ag+CpTPYD7aSrG00AjG03WIp17Gl4YlFMVMzg2EhcUYZtwf9C/LhgG6 4+nG6rPPnLRGDGeUV/fE45Bh+OZq+C4MurhWW9CCp64I4FkbNgTOPXgdlY4UDGsgo63C e0THp8kcwE53Mbvg3dV4UEfbbmBQN6J0NaOaQ3PfwYOebtthQrZ9Vg2TdkL6Rq6Np2Bo askQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=WJsRP3tJeSALwM8T60lBEdmSI12Ww6Fp7Kj6tASv6Ro=; b=c0zQ2bsIaq54Hv46ozW0oOSXb/IsLFY74TDXx6HH67SAulf8b6qJjSitjtR4U0vSop 2XcU8QjYeyHQojFnhwln+wu8gkPpVpnaOnG4Y6I2pzcfHG0D5Zp9jx56UZNC5hL4cxZg ts6R+dnriVrwefk1+NZJ+19nt2F3euWw8OD/ZESdqMBDRlHPKCdjwWCkwxap6zeWvKiK WVsUMtHYCL+yQCKP9ePSOJ95rN2xB6PA3Jht7xccUDyLSuXu2sYBYQy7gweyevTJwS6H 7yBx48oGTyuqLc2buOVbI8xUr/VSa8zOHKgSR031F5dOtoswrb8pOAZapgWBLOPBx/sQ +31w== X-Gm-Message-State: AJaThX49THruoQCthXUl6idRWGitP7nSE/uHHABhwC74vM9LVBRtIen0 Z7mM5Tx2R0zuj6UOar+c7/XDqXVutDV0V7gMiEo= X-Google-Smtp-Source: AGs4zMbtrulnUtJ4Uyg6sH1xIvOcGjo23X8FYtsX/6L7nFcbUwT33Tuzt9og992QeB3eC/e94ricjwTbkRvOstDbw6s= X-Received: by 10.157.34.163 with SMTP id y32mr672354ota.373.1510246080414; Thu, 09 Nov 2017 08:48:00 -0800 (PST) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.157.42.230 with HTTP; Thu, 9 Nov 2017 08:47:59 -0800 (PST) In-Reply-To: <20171109162941.3670.qmail@ary.lan> References: <20171109162941.3670.qmail@ary.lan> From: Phillip Hallam-Baker Date: Thu, 9 Nov 2017 11:47:59 -0500 X-Google-Sender-Auth: NqSypONTGVv0ajdHn1fcLLbRT9s Message-ID: To: John Levine Cc: SPASM Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [lamps] DNS DNAME pain. X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Nov 2017 16:48:07 -0000 On Thu, Nov 9, 2017 at 11:29 AM, John Levine wrote: > In article you write: >>It is not clear to me how the following is required to be interpreted: >> >>example.net DNAME example.com >>example.net CAA foo > > DNAME only maps names below it, so the CAA is fine. That is my understanding from the text, the example suggests otherwise. I would like to check that the old behavior of not matching the root is still valid. >>It might well be that the way to solve the DNAME problem is to specify >>a new zone mapping record that does the job in a way that meets DNS >>admins needs. ... > > There's a BNAME proposal kicking around that is sort of a combined > CNAME and DNAME, mapping everything at and below the name. Or do you > mean something else like a translucent DNAME that only maps if there's > nothing at the actual name? I am aware that there have been proposals circulating, I have not been tracking them directly. They seem to always be about to happen in a year or two. For anything of this sort, I would like the approach to be 'aggressively seek out all the requirements and solve them'. Requirement discovery through deployment is a bad approach. We should address requirements discovered through deployment but we should not make that the only way of discovering them. We don't have to do that here. From nobody Thu Nov 9 08:53:45 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C25A127775 for ; Thu, 9 Nov 2017 08:53:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, URIBL_BLOCKED=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=PpRBbpML; dkim=pass (1536-bit key) header.d=taugh.com header.b=Cx4GVw9l Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gN7dzVb5aEBW for ; Thu, 9 Nov 2017 08:53:42 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 683E7124C27 for ; Thu, 9 Nov 2017 08:53:42 -0800 (PST) Received: (qmail 22600 invoked from network); 9 Nov 2017 16:53:41 -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=5846.5a048815.k1711; bh=b6fp9pVmAR0sU2n7bNogfU6aMrPmCM82yxqSB5dD4tk=; b=PpRBbpMLqKfAwFtVGWjjyzROa+EV4siTOvn7T264Csmo8J8qiB6zIMAyqSL2mg+KAKS7gol+ZUVzvyeNTrJl85NZQQ7sxbgFnvjpUwz23bmvTxCqP54bkIaIQntzKtY/FmCZNHQs2QTvop9RuJNOXxgChj9Q7Y3KAtLep9AGl0MLf5S+Lo/lBJPfo4/Y03D39l6de2/JMhEzQ4HG25hqxa1hDKGyx5YfbaK45HGKM57UPoGPwjvtU23ZND5CdfwR 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=5846.5a048815.k1711; bh=b6fp9pVmAR0sU2n7bNogfU6aMrPmCM82yxqSB5dD4tk=; b=Cx4GVw9lbZTSBj+khAApyh6OTDL4d4O3lFmaRPkhBLpntIpc+cj92AnKCSp/mUwQS/2HI1FYnKyoj6sheJL7LbytDgYN5j8bS2xa8okjOARYafqYSViVHPV+VT8LfY4Tgg4mdNc+d1+IOXNSVw9TNAzbGUj9uiZBN8ZJ+hWpTKvMbHKClyDB+oDy+UEvncgkS564iR1phWdCGDOjnEWGdRI3ZNhMRYOxE8u9Iic4Z3QV/3EFLVM9hkDVL1vpx73v 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.2/X.509/AEAD) via TCP6; 09 Nov 2017 16:53:41 -0000 Date: 9 Nov 2017 11:53:40 -0500 Message-ID: From: "John R Levine" To: "Phillip Hallam-Baker" Cc: "SPASM" In-Reply-To: References: <20171109162941.3670.qmail@ary.lan> User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [lamps] DNS DNAME pain. X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Nov 2017 16:53:44 -0000 On Thu, 9 Nov 2017, Phillip Hallam-Baker wrote: >> DNAME only maps names below it, so the CAA is fine. > > That is my understanding from the text, the example suggests > otherwise. I would like to check that the old behavior of not matching > the root is still valid. It hasn't changed. For a long time the .CAT domain made a poor attempt to map ASCII and accented versions of names using DNAME, and I found out all about DNAME+other stuff. >> There's a BNAME proposal kicking around that is sort of a combined >> CNAME and DNAME, mapping everything at and below the name. Or do you >> mean something else like a translucent DNAME that only maps if there's >> nothing at the actual name? > > I am aware that there have been proposals circulating, I have not been > tracking them directly. They seem to always be about to happen in a > year or two. BNAME is going nowhere because it doesn't solve the problem it's supposed to solve, mapping variant names together. If you want, say, a pair of traditional and simplified Chinese names to act the same, you have far more work provisioning web and mail servers than the DNS. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Thu Nov 9 09:49:36 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C9E31276AF for ; Thu, 9 Nov 2017 09:49:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g8KHO9jKKqX7 for ; Thu, 9 Nov 2017 09:49:33 -0800 (PST) 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 A37C31287A3 for ; Thu, 9 Nov 2017 09:49:32 -0800 (PST) Received: by mail-oi0-x231.google.com with SMTP id v9so4977280oif.13 for ; Thu, 09 Nov 2017 09:49:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=RL0IDv9T+MTdF4Ud3rhuJpgO5Y94/UP0uz+zW8+jjBw=; b=moqUGJGJV/mKpAVJ0tFvgzRMh4wTykXIXUYw9cgX/Z0yAy591tg5OglQxbrQdiOKYe 7tjwhEpOavOLo0EYSW1O7lNQixUXnpYu/LT79nRdDuA1XzGGUFCPSA3Kk6sLuSzJ2263 Yxrm/maceX7clE8gLUAYRKEL1nc786HlLyHW34jmOgw9VucMrwa0cvnmrbpTdWenlHBi J66tVwbLLiNN+wmJPcoOPaCb+guv20DQtppTsmdt9vyLbqOUBtAvfCda4WN+EYOQ7C0g exfIYwF91AYI2dsYxvHh+G+y+PkHqqkNORTqgMSMzA6qu5dfBSBjDVuTW6PvCLtkibqe 6Uxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=RL0IDv9T+MTdF4Ud3rhuJpgO5Y94/UP0uz+zW8+jjBw=; b=lal+ldgKPMWly8DkQBKQKHayxX3q5PI6eSwX19O4WjEf5YYfaaMp94OcyZv+KqKKPv HFrYdF6xUOmQiN4RHkbOI9spYEyLOdpfXVM4XpyaofjOv43ngxRu846S7u8ovklvRMwb g/6u+gErZZP+eDMWo2+5wIW6tC7S6b3aFm/hxYN3cl7sB0IMR5MWsruVV4CpM54TbCoP /67g4DhQcOGPpsrxMnxoDofA9Rfs3pOAtzfQ7hVZteC3xgCbCUHKPPlQIyR6NGgS17Dq LvKdrXhl6+ilcErzrJ8BJK7vYnd4gjFvBEF1yu9umX1xMmo6d/tJl3bCGWj/z7nNbMAN 5t/g== X-Gm-Message-State: AJaThX4dXEqmkCKMMiSYIvEFhU+85exB0x2XyuH+08EdVxG1UkMgny0B Vs7V9k2Zky2m7XB6U7Wes1+S00DEF9jmEfOPYOQ= X-Google-Smtp-Source: AGs4zMYJSN1+fD79/HiBn9pfwgSICCuDCyIxNnFwfmwv1Nno8VRethC8TkT3x7BdMrqDtfROD/G1GtdY70+EhFRTXRM= X-Received: by 10.202.244.151 with SMTP id s145mr784326oih.220.1510249771921; Thu, 09 Nov 2017 09:49:31 -0800 (PST) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.157.42.230 with HTTP; Thu, 9 Nov 2017 09:49:31 -0800 (PST) In-Reply-To: References: <20171109162941.3670.qmail@ary.lan> From: Phillip Hallam-Baker Date: Thu, 9 Nov 2017 12:49:31 -0500 X-Google-Sender-Auth: F4FQ8ZaWisnbz5YjPW8dh5WYKAo Message-ID: To: John R Levine Cc: SPASM Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [lamps] DNS DNAME pain. X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Nov 2017 17:49:35 -0000 On Thu, Nov 9, 2017 at 11:53 AM, John R Levine wrote: > On Thu, 9 Nov 2017, Phillip Hallam-Baker wrote: >>> >>> DNAME only maps names below it, so the CAA is fine. >> >> >> That is my understanding from the text, the example suggests >> otherwise. I would like to check that the old behavior of not matching >> the root is still valid. > > > It hasn't changed. For a long time the .CAT domain made a poor attempt to > map ASCII and accented versions of names using DNAME, and I found out all > about DNAME+other stuff. > >>> There's a BNAME proposal kicking around that is sort of a combined >>> CNAME and DNAME, mapping everything at and below the name. Or do you >>> mean something else like a translucent DNAME that only maps if there's >>> nothing at the actual name? >> >> >> I am aware that there have been proposals circulating, I have not been >> tracking them directly. They seem to always be about to happen in a >> year or two. > > > BNAME is going nowhere because it doesn't solve the problem it's supposed to > solve, mapping variant names together. If you want, say, a pair of > traditional and simplified Chinese names to act the same, you have far more > work provisioning web and mail servers than the DNS. Like many other DNS proposals, the only way that can work is if the services are getting their configuration data from the same source of truth as the authoritative DNS server That is something I have been building for my own use. When a Docker container pops up, it should register itself in the DNS as one of the handlers for that service. When it dies, it should be unregistered. From nobody Thu Nov 9 10:18:59 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5474129435 for ; Thu, 9 Nov 2017 10:18:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, URIBL_BLOCKED=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=ImWSg8m5; dkim=pass (1536-bit key) header.d=taugh.com header.b=iDOsOqdp Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BtjaKvEePBzC for ; Thu, 9 Nov 2017 10:18:56 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 E234B129406 for ; Thu, 9 Nov 2017 10:18:43 -0800 (PST) Received: (qmail 47631 invoked from network); 9 Nov 2017 18:18:42 -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=ba0c.5a049c02.k1711; bh=2aW/i0h++UHruhWRbULHPLeydO3kLDxwQCqEnQRzry4=; b=ImWSg8m5v5ZEsCWQIBNwIZG1qCE4525HzDbu51ta17GxeOLIzLK3n/iJ/8qh8xJMLI+SvfSFeoFZ182w+UEaUO6yVSWpVm8cBEQVt2iPBSSDULUe60Nt8vpYlXhlbk02asnwMFEUeTQZgxl2RK7HEmtVF/2A42gt6yW2UyNAcZVEStirkI1kbHy8RHq+aHbErouXL0TLEsOUO3dm9HCpe+p4M9EJ+lbjRM/ohvKDvv+yXvHfHJD/ywvMQh7IpbBN 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=ba0c.5a049c02.k1711; bh=2aW/i0h++UHruhWRbULHPLeydO3kLDxwQCqEnQRzry4=; b=iDOsOqdp5DIoscQHhWSUiYa2+HOWEsmAOFAI9eZHXkGwd+PRu67zxoe2MSXS1EIA927vFo02+WlKdix7pN5jPPlHxzFQkCjQZU5iypWz2P4PISzmwdWWVLqcuHK3g9gSiLj/25GVTAGUAly5qNmZKi9wEtb3zhFvzFVy7VIyFZMc15RILaCflApa1JV/WHHHTBLclkLhqsc9M2fPNMMUYhDxIPnyTZjYtMOAU6j3Ms3WIDYuugGwPsV5iISli3ZN 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.2/X.509/AEAD) via TCP6; 09 Nov 2017 18:18:42 -0000 Date: 9 Nov 2017 13:18:42 -0500 Message-ID: From: "John R Levine" To: "Phillip Hallam-Baker" Cc: "SPASM" In-Reply-To: References: <20171109162941.3670.qmail@ary.lan> User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [lamps] DNS DNAME pain. X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Nov 2017 18:18:58 -0000 >> BNAME is going nowhere because it doesn't solve the problem it's supposed to >> solve, mapping variant names together. If you want, say, a pair of >> traditional and simplified Chinese names to act the same, you have far more >> work provisioning web and mail servers than the DNS. > > Like many other DNS proposals, the only way that can work is if the > services are getting their configuration data from the same source of > truth as the authoritative DNS server That helps, but the meaning of "the same" when applied to web servers is pretty vague. If you have names in different character sets or different languages, should the web content match the character set or language of the name you use? It's a swamp. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Thu Nov 9 10:46:41 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5884412944B for ; Thu, 9 Nov 2017 10:46:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 Wmmaw4Bh3yjw for ; Thu, 9 Nov 2017 10:46:38 -0800 (PST) Received: from mail-ot0-x22d.google.com (mail-ot0-x22d.google.com [IPv6:2607:f8b0:4003:c0f::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 EF98F1294A4 for ; Thu, 9 Nov 2017 10:46:37 -0800 (PST) Received: by mail-ot0-x22d.google.com with SMTP id s88so6172884ota.4 for ; Thu, 09 Nov 2017 10:46:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=yDrXETctKfYqvMvppLxFeBXrEIoYubqw/6ZaMjebS/E=; b=dESe/tOpt3U5Xua2b0uNp0OYI5vK6AcKoydIk6YYks08O7gDx/nASfHr+FfGwMU5VR Uo9bp0GwQ6gqPk/2/t7XT6d+DlkZx+Jaywb2NuqdRTmGOMHO4JU9/jXLwYkiPg+biOrl 9j6B7OnhoaS06UmiYhf3gPso+geR1VIk/altJu3tWbl3ImomdADxLN8hbHwYbAsaEY1t DPjoRvAtZr/72XeajI+EKKgCUG0bO1imi4clyRifkB9mpH2EmR6D1pWx5pacQbZyQaRH jUB7UdybaCcw5bK3piaE4JZIOw+4w5ezEMLkMKenrNgXHjUcZL6T2JI5sJoCLPtobs35 2ASQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=yDrXETctKfYqvMvppLxFeBXrEIoYubqw/6ZaMjebS/E=; b=pmO/vMDL9MDYSz+FQZVvLYqous/Un5CANAiBoKBpDwJ1xf8UDIMgsmh2NeSASqMOEo 7262lMlsCjCosZTCTbNpCks/wkdzRKV/Bi608NpbLAZheoJa5xCmI4hl9PNwjT8A4bWd jYw7EgeGqQQ5YbNgS25lg1UqneYx7zT+8j5igUCDUp5JZ646JygjLtaCc6y39a3OJAeH v26n5DLH4iZrQzTue4sxHBEjcdN6crUvTK6fbYPJURj1AAxGdL1kifZlm4jdndGW753l QGeBPQjevtmYREhbGQy4H50U5j+Ky9r9G9u1GRzRE+OlZc+oe6kv96YdVSnSxJWhZRIO doTQ== X-Gm-Message-State: AJaThX4EcVQwSHIs70gXb5tuXROIQitk5NBO/GpbaVBvcFNrOxsxLMxc SNPMHSct99q4u1lf4apZSJjYDAZkkncpQzABHfk= X-Google-Smtp-Source: AGs4zMaSXtzSiHUssJT4gDOgVO25pM8FnVGulVCFuDFbCxN+Hw701JpZrVGTZ+bfl9/rrI41eLTj6ptDGhpDbPCt9P8= X-Received: by 10.157.61.226 with SMTP id l89mr961978otc.269.1510253197140; Thu, 09 Nov 2017 10:46:37 -0800 (PST) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.157.42.230 with HTTP; Thu, 9 Nov 2017 10:46:36 -0800 (PST) In-Reply-To: References: <20171109162941.3670.qmail@ary.lan> From: Phillip Hallam-Baker Date: Thu, 9 Nov 2017 13:46:36 -0500 X-Google-Sender-Auth: 6JZLmkcUslP_nCq_E3FxBVK3A58 Message-ID: To: John R Levine Cc: SPASM Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [lamps] DNS DNAME pain. X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Nov 2017 18:46:39 -0000 On Thu, Nov 9, 2017 at 1:18 PM, John R Levine wrote: >>> BNAME is going nowhere because it doesn't solve the problem it's supposed >>> to >>> solve, mapping variant names together. If you want, say, a pair of >>> traditional and simplified Chinese names to act the same, you have far >>> more >>> work provisioning web and mail servers than the DNS. >> >> >> Like many other DNS proposals, the only way that can work is if the >> services are getting their configuration data from the same source of >> truth as the authoritative DNS server > > > That helps, but the meaning of "the same" when applied to web servers is > pretty vague. If you have names in different character sets or different > languages, should the web content match the character set or language of the > name you use? It's a swamp. That is not what I am talking about. I am talking about the source of truth for the machine configuration being something like this [Note this is nothing to do with DNS configs or aliases] Global service file: MyCompany Domain Canonical canonicalsite.com Alias: mysite.com Alias: xn--anothersite.com I start a mail server container and tell it to register to service MyCompany. It connects to the provisioning service Host: "I support SMTP, POP3 and IMAP for MyCompany " Provisioning to Host: "Your names are canonicalsite.com, mysite.com, xn--anothersite.com" "Your priority is 10, you are 1 of 1 services" Host: "Service is online and waiting" Provisioning to DNS: Provisioning to Host: "You are online" Host: "CPU at 90%" At this point the provisioning service can bring up another host to service that domain. The Web/mail/whatever service knows exactly what is being said on its behalf and can react accordingly In this model, DNS administration is strictly an output of the provisioning service. It is not a thing in its own right. DNS records can now be produced for whatever information clients might require BEFORE they connect to the service. This is the only model in which I see features like DANE or encryption of the initial TLS negotiation being practical because it is the only model in which the DNS information is likely to be useful. Any system that relies on Bob to configure two separate systems without inconsistency is broken. Bob will get them in sync the first time at best. Then a change to the config will be made to one and not the other. From nobody Sun Nov 12 22:22:27 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D5DE12946F for ; Sun, 12 Nov 2017 22:22:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.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 9jUCcWctTE6r for ; Sun, 12 Nov 2017 22:22:24 -0800 (PST) Received: from mail4.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 873A2129353 for ; Sun, 12 Nov 2017 22:22:24 -0800 (PST) Content-Type: multipart/alternative; boundary="----=_NextPart_000_02FB_01D35C8A.CF911370" Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1510554137; h=from:subject:to:date:message-id; bh=uQ3dT6vLw2InXG/0B6pQYnRG+IlWI+t9DxalQAJKaOs=; b=e2jaVEhHbOj4QMU+1++ffSejYD4rhfqK2SEyMGq/CVeBcj0uqamqdWrmpfekgA2lYNRYxVvyZ5h zyF7LJNwA2xX6FhT4K2EXRPMPJ89hWSHBvb2kYBLCN+q9md0+YnNXbHJXNKxRdV8kbtyv0z47CXZm 99SwpDqxVKBEQwcAXNScPgyjl7q6U5PSbLq1LnY9OTGnGF8azC5Mdgp04c+vzyNzy/LiOpy8vouUH sIpez9mG9bc354tAjw1qS6+++v+SfW5i+eraWfP0bPgy/rdLvMDx2mS+1p2O+jkXeJyoV+HEAyDYj OstzWekEFvMtdKNa3/I3Z/mgCxfJ+GpU6WLg== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sun, 12 Nov 2017 22:22:17 -0800 Received: from Jude (31.130.238.222) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sun, 12 Nov 2017 22:21:13 -0800 From: To: 'SPASM' Date: Mon, 13 Nov 2017 14:22:14 +0800 Message-ID: <02fa01d35c47$c16cc200$44464600$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdNcR3X6wGQ/dqH5TgGLIzMN1PjErQ== X-Originating-IP: [31.130.238.222] Archived-At: Subject: [lamps] Minutes are posted. X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 06:22:26 -0000 ------=_NextPart_000_02FB_01D35C8A.CF911370 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Preliminary minutes have been posted at https://datatracker.ietf.org/meeting/100/materials/minutes-100-lamps/ if you have any comments or issues please let me know. Jim ------=_NextPart_000_02FB_01D35C8A.CF911370 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Preliminary minutes have been posted at https://datatracker.ietf.org/meeting/100/materials/minutes-100-lamp= s/  if you have any comments or issues please let me = know.

 

Jim

 

------=_NextPart_000_02FB_01D35C8A.CF911370-- From nobody Mon Nov 13 07:16:11 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42438129421 for ; Mon, 13 Nov 2017 07:16:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hgP9Shl4eX5o for ; Mon, 13 Nov 2017 07:15:54 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06FBA129AD1 for ; Mon, 13 Nov 2017 07:15:42 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 5F3FD3005A4 for ; Mon, 13 Nov 2017 10:15:41 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id U2nlKhyaK3J7 for ; Mon, 13 Nov 2017 10:15:38 -0500 (EST) Received: from [10.5.245.234] (wsip-98-172-24-238.dc.dc.cox.net [98.172.24.238]) by mail.smeinc.net (Postfix) with ESMTPSA id BEDC8300590 for ; Mon, 13 Nov 2017 10:15:38 -0500 (EST) From: Russ Housley Content-Type: multipart/alternative; boundary="Apple-Mail=_39E36E50-732F-4190-A1A2-055642B6E601" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <1FB8E6DC-4EB2-4812-AA10-3415396EC984@vigilsec.com> References: <151058607297.580.10143889052435378840.idtracker@ietfa.amsl.com> To: SPASM Date: Mon, 13 Nov 2017 10:15:40 -0500 X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [lamps] Fwd: New Version Notification for draft-housley-cms-mix-with-psk-00.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 15:16:02 -0000 --Apple-Mail=_39E36E50-732F-4190-A1A2-055642B6E601 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii People on this list may find this new I-D interesting, Russ > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-housley-cms-mix-with-psk-00.txt > Date: November 13, 2017 at 10:14:32 AM EST > To: "Russell Housley" , "Russ Housley" = >=20 >=20 > A new version of I-D, draft-housley-cms-mix-with-psk-00.txt > has been successfully submitted by Russell Housley and posted to the > IETF repository. >=20 > Name: draft-housley-cms-mix-with-psk > Revision: 00 > Title: Using Pre-Shared Key (PSK) in the Cryptographic = Message Syntax (CMS) > Document date: 2017-11-13 > Group: Individual Submission > Pages: 11 > URL: = https://www.ietf.org/internet-drafts/draft-housley-cms-mix-with-psk-00.txt= > Status: = https://datatracker.ietf.org/doc/draft-housley-cms-mix-with-psk/ > Htmlized: = https://tools.ietf.org/html/draft-housley-cms-mix-with-psk-00 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-housley-cms-mix-with-psk-00 >=20 >=20 > Abstract: > The invention of a large-scale quantum computer would pose a serious > challenge for the cryptographic algorithms that are widely deployed > today. The Cryptographic Message Syntax (CMS) supports key = transport > and key agreement algorithms that could be broken by the invention = of > such a quantum computer. By storing communications that are > protected with the CMS today, someone could decrypt them in the > future when a large-scale quantum computer becomes available. Once > quantum-secure key management algorithms are available, the CMS will > be extended to support them, if current syntax the does not > accommodated them. In the near-term, this document describes a > mechanism to protect today's communication from the future invention > of a large-scale quantum computer by mixing the output of key > transport and key agreement algorithms with a pre-shared key. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 --Apple-Mail=_39E36E50-732F-4190-A1A2-055642B6E601 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii People on this list may find this new I-D interesting,

Russ


From: = internet-drafts@ietf.org
Subject: = New Version = Notification for draft-housley-cms-mix-with-psk-00.txt
Date: = November 13, 2017 at 10:14:32 = AM EST
To: = "Russell Housley" <housley@vigilsec.com>, "Russ Housley" <housley@vigilsec.com>


A new version = of I-D, draft-housley-cms-mix-with-psk-00.txt
has been = successfully submitted by Russell Housley and posted to the
IETF repository.

Name: = draft-housley-cms-mix-with-psk
Revision: 00
Title:= = Using Pre-Shared Key (PSK) in the Cryptographic Message Syntax = (CMS)
Document date: 2017-11-13
Group:= = Individual Submission
Pages: 11
URL: =            https://www.ietf.org/internet-drafts/draft-housley-cms-mix-with= -psk-00.txt
Status: =         https://datatracker.ietf.org/doc/draft-housley-cms-mix-with-psk= /
Htmlized:       https://tools.ietf.org/html/draft-housley-cms-mix-with-psk-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-housley-cms-mix-wit= h-psk-00


Abstract:
  The invention of a large-scale quantum computer = would pose a serious
  challenge for the = cryptographic algorithms that are widely deployed
=   today.  The Cryptographic Message Syntax (CMS) supports = key transport
  and key agreement algorithms = that could be broken by the invention of
  such = a quantum computer.  By storing communications that are
  protected with the CMS today, someone could = decrypt them in the
  future when a large-scale = quantum computer becomes available.  Once
=   quantum-secure key management algorithms are available, the = CMS will
  be extended to support them, if = current syntax the does not
  accommodated = them.  In the near-term, this document describes a
=   mechanism to protect today's communication from the future = invention
  of a large-scale quantum computer = by mixing the output of key
  transport and key = agreement algorithms with a pre-shared key.




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

The IETF Secretariat


= --Apple-Mail=_39E36E50-732F-4190-A1A2-055642B6E601-- From nobody Mon Nov 13 13:53:49 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AB7C126C2F for ; Mon, 13 Nov 2017 13:53:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.519 X-Spam-Level: X-Spam-Status: No, score=-14.519 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SymOCSUdJvq4 for ; Mon, 13 Nov 2017 13:53:46 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7390120724 for ; Mon, 13 Nov 2017 13:53:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11897; q=dns/txt; s=iport; t=1510610025; x=1511819625; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=2HnikNgIY/GuJ1cQR39nCl/w78ZXlxPZLe+7OO4BQPM=; b=lXNDM1qdqm9VllTAMaDSLz6ve25mw7GTt1A1OT+0+B3aWhMwBBOyEPbJ /yMnfseJhRxt6FFSjbGea6tMa49STYvxHm9RBq3qTy/Qx771Cds/4169N JhN65JlZEI2Hf2HhBvm9GRTPyrpzGAu7WovWs57yjmM7sgEtfovmWrbYh A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CfAAAGEwpa/4kNJK1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJEQy5kbicHhX2IGY8vgX2RCIVIEIIBCiWDOIFeAoRlPxgBAQE?= =?us-ascii?q?BAQEBAQFrKIUeAQEBAQMtShICAQgRAwEBASgHMhQJCAIEARIIE4kjZBCtdIsOA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEBHYM0gQ55gVWBaYMqhFtcFoVCBZFokEICh2m?= =?us-ascii?q?NEIIeX4UpiyWMaIkPAhEZAYE4AQ8QOIFyehUfKoJkCYMIgU53AYYZK4EIgREBA?= =?us-ascii?q?QE?= X-IronPort-AV: E=Sophos;i="5.44,389,1505779200"; d="scan'208,217";a="102234696" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 Nov 2017 21:53:44 +0000 Received: from XCH-ALN-007.cisco.com (xch-aln-007.cisco.com [173.36.7.17]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id vADLriss014839 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 13 Nov 2017 21:53:44 GMT Received: from xch-aln-010.cisco.com (173.36.7.20) by XCH-ALN-007.cisco.com (173.36.7.17) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 13 Nov 2017 15:53:44 -0600 Received: from xch-aln-010.cisco.com ([173.36.7.20]) by XCH-ALN-010.cisco.com ([173.36.7.20]) with mapi id 15.00.1320.000; Mon, 13 Nov 2017 15:53:44 -0600 From: "Panos Kampanakis (pkampana)" To: Russ Housley , SPASM Thread-Topic: [lamps] Fwd: New Version Notification for draft-housley-cms-mix-with-psk-00.txt Thread-Index: AQHTXJJnvtwF0ibx70yqT6Xv0DHsVKMS2Tmw Date: Mon, 13 Nov 2017 21:53:44 +0000 Message-ID: <0eb2dd1b4c9b477e8a7f032f98266ce2@XCH-ALN-010.cisco.com> References: <151058607297.580.10143889052435378840.idtracker@ietfa.amsl.com> <1FB8E6DC-4EB2-4812-AA10-3415396EC984@vigilsec.com> In-Reply-To: <1FB8E6DC-4EB2-4812-AA10-3415396EC984@vigilsec.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.108.4] Content-Type: multipart/alternative; boundary="_000_0eb2dd1b4c9b477e8a7f032f98266ce2XCHALN010ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [lamps] Fwd: New Version Notification for draft-housley-cms-mix-with-psk-00.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 21:53:48 -0000 --_000_0eb2dd1b4c9b477e8a7f032f98266ce2XCHALN010ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Russ, This is a useful doc. It resembles the IPSECME work for IKEv2 as a temporar= y solution until NIST comes up with new public key crypto algos. I would su= ggest to be more prescriptive on the KDFs, the entropy and the key sizes so= they are long enough (at least 256-bits as you are suggesting with AES-256= ) to be resistant against a quantum computer. Panos From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Russ Housley Sent: Monday, November 13, 2017 10:16 AM To: SPASM Subject: [lamps] Fwd: New Version Notification for draft-housley-cms-mix-wi= th-psk-00.txt People on this list may find this new I-D interesting, Russ From: internet-drafts@ietf.org Subject: New Version Notification for draft-housley-cms-mix-with-psk-00.txt Date: November 13, 2017 at 10:14:32 AM EST To: "Russell Housley" >, = "Russ Housley" > A new version of I-D, draft-housley-cms-mix-with-psk-00.txt has been successfully submitted by Russell Housley and posted to the IETF repository. Name: draft-housley-cms-mix-with-psk Revision: 00 Title: Using Pre-Shared Key (PSK) in the Cryptographic Messag= e Syntax (CMS) Document date: 2017-11-13 Group: Individual Submission Pages: 11 URL: https://www.ietf.org/internet-drafts/draft-housley-cms-mix-= with-psk-00.txt Status: https://datatracker.ietf.org/doc/draft-housley-cms-mix-with= -psk/ Htmlized: https://tools.ietf.org/html/draft-housley-cms-mix-with-psk-= 00 Htmlized: https://datatracker.ietf.org/doc/html/draft-housley-cms-mix= -with-psk-00 Abstract: The invention of a large-scale quantum computer would pose a serious challenge for the cryptographic algorithms that are widely deployed today. The Cryptographic Message Syntax (CMS) supports key transport and key agreement algorithms that could be broken by the invention of such a quantum computer. By storing communications that are protected with the CMS today, someone could decrypt them in the future when a large-scale quantum computer becomes available. Once quantum-secure key management algorithms are available, the CMS will be extended to support them, if current syntax the does not accommodated them. In the near-term, this document describes a mechanism to protect today's communication from the future invention of a large-scale quantum computer by mixing the output of key transport and key agreement algorithms with a pre-shared key. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --_000_0eb2dd1b4c9b477e8a7f032f98266ce2XCHALN010ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Russ,

This is a useful doc. It resembles th= e IPSECME work for IKEv2 as a temporary solution until NIST comes up with n= ew public key crypto algos. I would suggest to be more prescriptive on the KDFs, the entropy and the key sizes so they ar= e long enough (at least 256-bits as you are suggesting with AES-256) to be = resistant against a quantum computer.

Panos

 

 

From: Spasm [mailto:spasm-bounces@ie= tf.org] On Behalf Of Russ Housley
Sent: Monday, November 13, 2017 10:16 AM
To: SPASM <spasm@ietf.org>
Subject: [lamps] Fwd: New Version Notification for draft-housley-cms= -mix-with-psk-00.txt

 

People on this list may find this new I-D interestin= g,

 

Russ

 



From: internet-drafts@ietf.org<= /o:p>

Subject: New Version Notification for draft-housley-cms-mix-wit= h-psk-00.txt

Date: November 1= 3, 2017 at 10:14:32 AM EST

To: "Russ= ell Housley" <housley@vigil= sec.com>, "Russ Housley" <housley@vigilsec.com>

 


A new version of I-D, draft-housley-cms-mix-with-psk-00.txt
has been successfully submitted by Russell Housley and posted to the
IETF repository.

Name:      &nb= sp;      draft-housley-cms-mix-with-psk
Revision:      = ;  00
Title:      &n= bsp;        Using Pre-Shared Key = (PSK) in the Cryptographic Message Syntax (CMS)
Document date:     =      2017-11-13
Group:      &n= bsp;      Individual Submission
Pages:      &n= bsp;      11
URL:            https://www.ietf.org/internet-drafts/draft-housley-cms-mix-with-psk= -00.txt
Status:         https://datatrack= er.ietf.org/doc/draft-housley-cms-mix-with-psk/
Htmlized:       https://tools.ietf.org/html/dr= aft-housley-cms-mix-with-psk-00
Htmlized:       https://datatracker.= ietf.org/doc/html/draft-housley-cms-mix-with-psk-00


Abstract:
  The invention of a large-scale quantum computer would pose a se= rious
  challenge for the cryptographic algorithms that are widely depl= oyed
  today.  The Cryptographic Message Syntax (CMS) supports ke= y transport
  and key agreement algorithms that could be broken by the invent= ion of
  such a quantum computer.  By storing communications that a= re
  protected with the CMS today, someone could decrypt them in the=
  future when a large-scale quantum computer becomes available. &= nbsp;Once
  quantum-secure key management algorithms are available, the CMS= will
  be extended to support them, if current syntax the does not
  accommodated them.  In the near-term, this document descri= bes a
  mechanism to protect today's communication from the future inve= ntion
  of a large-scale quantum computer by mixing the output of key   transport and key agreement algorithms with a pre-shared key.



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

The IETF Secretariat

 

--_000_0eb2dd1b4c9b477e8a7f032f98266ce2XCHALN010ciscocom_-- From nobody Fri Nov 17 12:41:06 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 809FC120454 for ; Fri, 17 Nov 2017 12:41:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eff.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a8wi5o8_to-1 for ; Fri, 17 Nov 2017 12:41:04 -0800 (PST) Received: from mail2.eff.org (mail2.eff.org [173.239.79.204]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 078591200B9 for ; Fri, 17 Nov 2017 12:41:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date:Message-ID:Subject:From:To; bh=Gfwtyupm4NVLq1nB0K4+8Mfm6DmRnsblLaBBnap6Blg=; b=r/5w1I8igQ2JmqBTF6jW5C8WAGCUGVwfG5NmlSBYVWFSny9aXYU3VHnK/Plq6FpJOpU8exAcCVXHFXomv3aiM7dSI9/2FQE9UBJOE9W4Jv0qfW/8A4Lsr7dEGsdOIwBqG9sESmqxtom0Mlfwb5ncRqNlVmsbo50V/ixDkFGC1Rs=; Received: ; Fri, 17 Nov 2017 12:40:59 -0800 To: Russ Housley , SPASM From: Jacob Hoffman-Andrews Message-ID: <84e6d5a2-4a51-8993-00ef-56be4e1c04be@eff.org> Date: Fri, 17 Nov 2017 12:41:02 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [lamps] Moving caa-simplification to a WG document? X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2017 20:41:05 -0000 At the WG session at IETF100 we took a hum on standardizing the CAA implementation that's current in production, i.e. the contents of https://www.ietf.org/id/draft-hoffman-andrews-caa-simplification-02.txt. Currently that's published as an individual draft. What steps do we need to take to turn that into a WG document so we can make progress towards an RFC? Thanks, Jacob From nobody Fri Nov 17 15:16:54 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96E81126B7F for ; Fri, 17 Nov 2017 15:16:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.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 Ad4D5b4Yws62 for ; Fri, 17 Nov 2017 15:16:51 -0800 (PST) Received: from mail4.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7420F120724 for ; Fri, 17 Nov 2017 15:16:51 -0800 (PST) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1510960609; h=from:subject:to:date:message-id; bh=96T56NhxegsU069h3ZiiZ/bleQ4mQAUiZiwBoaEYEBM=; b=Rlgikvug8iPlzVW/j/phNh4ex3PnzVN4RiNS/gJ6OwtJpNd1Y7QGNRlRAmt64/iM/Xx63npEmNb ewcWf6dnhxYginH7x1vQFyeZOxmfBR3lhVHcglg8pqcvGBmQq1n3nCr9nHOx3kbh7zHCrWyqmpD34 RmpRJvfgYPx3NkTMcKbD+nvv0/v/ErS64OyQLC3uQCgC5q8eAJ5V9gNXmy+EWG9VSw4CbsmyHo5Ua lVnIF+WKAuKPOI6eogB9RVnerzstGuLmSBq7rvub5sXFIbIdXxRWAWQuwwSXzSx5aHcwRKrHUqds2 nUxwrB9PViD+qSDtUjDq4B9hz85DNh51EHjQ== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 17 Nov 2017 15:16:49 -0800 Received: from Jude (101.127.234.130) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 17 Nov 2017 15:15:40 -0800 From: Jim Schaad To: 'Jacob Hoffman-Andrews' , 'Russ Housley' , 'SPASM' References: <84e6d5a2-4a51-8993-00ef-56be4e1c04be@eff.org> In-Reply-To: <84e6d5a2-4a51-8993-00ef-56be4e1c04be@eff.org> Date: Sat, 18 Nov 2017 07:16:41 +0800 Message-ID: <05df01d35ffa$2286d200$67947600$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQIKT1ORQjHotxRnkqBk8qQ7D2TY+aKrVJWg X-Originating-IP: [101.127.234.130] Archived-At: Subject: Re: [lamps] Moving caa-simplification to a WG document? X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2017 23:16:53 -0000 There are three steps that need to be taken: 1. We need to publish one of our current documents - this is now down 2. We need to do a charter update - this is not necessarily a gating factor on adoption but needs to get done. 3. We need to do a formal WG adoption call. This has been done informally and my understanding is that this would be a pro-forma step as there is support to do this. All that however is not needed to make progress on the document in terms of having discussions and getting the document published as a document that the working group is looking at. This would only be blocking when we get to the point of wanting to do the final steps to get it published. Unless you think the document is ready now to publish none of this is currently blocking progress. Jim -----Original Message----- From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Jacob Hoffman-Andrews Sent: Saturday, November 18, 2017 4:41 AM To: Russ Housley ; SPASM Subject: [lamps] Moving caa-simplification to a WG document? At the WG session at IETF100 we took a hum on standardizing the CAA implementation that's current in production, i.e. the contents of https://www.ietf.org/id/draft-hoffman-andrews-caa-simplification-02.txt. Currently that's published as an individual draft. What steps do we need to take to turn that into a WG document so we can make progress towards an RFC? Thanks, Jacob _______________________________________________ Spasm mailing list Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm From nobody Wed Nov 22 15:50:31 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 772AF1200F1 for ; Wed, 22 Nov 2017 15:50:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id va5Ro-UCwwqj for ; Wed, 22 Nov 2017 15:50:18 -0800 (PST) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30BDF126B6E for ; Wed, 22 Nov 2017 15:50:17 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.net.in.tum.de (Postfix) with ESMTPSA id 9; Thu, 23 Nov 2017 00:50:04 +0100 (CET) From: Quirin Scheitle Content-Type: multipart/signed; boundary="Apple-Mail=_9DEDBBCA-9669-43E6-BEF6-76FF13CD941E"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 23 Nov 2017 00:50:04 +0100 Cc: public@cabforum.org, spasm@ietf.org To: mozilla-dev-security-policy@lists.mozilla.org Message-Id: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [lamps] Anomalous Certificate Issuances based on historic CAA records X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Nov 2017 23:50:25 -0000 --Apple-Mail=_9DEDBBCA-9669-43E6-BEF6-76FF13CD941E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 /* posting for primary discussion at Mozilla Dev Security Policy, = copying CAB Public ML and SPASM@IETF */ Hi all, the CAA RFC includes an =E2=80=9Cevaluator=E2=80=9D role, a third party = than can use public DNS records and public certificates to surface anomalies in the issuance process. We have taken this role and analysed a set of certificates for a number = of domains for which we happen to have measured CAA records *at issuance time*. We would like to share our results here for public discussion. We believe that this might help to further shape said =E2=80=9Cevaluator = role=E2=80=9D. (In which context and format should findings be shared? What level of = detail and assurance is expected?). Furthermore, our results have surfaced some anomalies that might hint at = underlying issues with CAA validation. We believe that uncovering and discussing unclear = cases will help to sharpen our understanding as a community on how certain cases should = be handled. In that light, I want to share the details of our scan below. We have found 18 anomalous certificates that can be assigned to 4 groups = of possible root causes: 1) Mix of wildcard and non-wildcard DNS names in SAN Batch: https://misissued.com/batch/32/ Description: best confer = https://groups.google.com/d/msg/mozilla.dev.security.policy/O9HZPMvHMY8/Ht= XR8S-1AAAJ 2) Cloudflare FreeSSL certificates issued by Comodo Batch: https://misissued.com/batch/30/ Description: We are not aware that Cloudflare and Comodo are = affiliated, or that Comodo runs the DNS infrastructure of Cloudflare customers =E2=80=94 = so these certificates should be checked like any other? 3) Comodo not checking CAA records until Sep 12 = [https://bugzilla.mozilla.org/show_bug.cgi?id=3D1398545] Batch: https://misissued.com/batch/29/ Description: Comodo did not validate CAA records in the early = days, and the certificates in this batch might have been issued due to this anomaly. 4) Apparent non-evaluation of CAA records Batch: https://misissued.com/batch/33/ Description: These cases appear as pretty straight-forward that = they should not have been issued, but there might be good explanations Please note that these categories may overlap. Please find the details = below. To proceed with this as a community, I guess answers to the the = following questions from the affected CAs [1] would be of interest: a) Was CAA checking bypassed for this issuance? If so, why? b) If CAA lookups were conducted, what response did you receive? = Why did it permit issuance? [1] Thawte, Comodo, Certum,Camerfirma, GlobalSign I am also happy to file BugZilla bugs if desired. Kind regards Quirin =3D=3D=3D=3D=3D=3D=3D=3D Certificate 1 - Group 1 =3D=3D=3D=3D=3D=3D=3D=3D https://crt.sh/?id=3D215028491 X509v3 Subject Alternative Name: DNS:*.netservicesgroup.com DNS:netservicesgroup.com Issuer COMODO CA Limited DNS history (Certificate issued on Sep 20): 2017-09-18:netservicesgroup.com. 86400 IN CAA 0 = issuewild "comodoca.com" 2017-09-18:netservicesgroup.com. 86400 IN CAA 0 issue = ";" 2017-09-19:netservicesgroup.com. 86400 IN CAA 0 = issuewild "comodoca.com" 2017-09-19:netservicesgroup.com. 86400 IN CAA 0 issue = ";" 2017-09-20:netservicesgroup.com. 86400 IN CAA 0 = issuewild "comodoca.com" 2017-09-20:netservicesgroup.com. 86400 IN CAA 0 issue = =E2=80=9C;" 2017-09-21:netservicesgroup.com. 86400 IN CAA 0 = issuewild "comodoca.com" 2017-09-21:netservicesgroup.com. 86400 IN CAA 0 issue = ";" 2017-09-23:netservicesgroup.com. 86400 IN CAA 0 = issuewild =E2=80=9Ccomodoca.com" 2017-09-23:netservicesgroup.com. 86400 IN CAA 0 issue = =E2=80=9C;" =3D=3D=3D=3D=3D=3D=3D=3D Certificate 2 - Group 1 =3D=3D=3D=3D=3D=3D=3D https://crt.sh/?id=3D211113116 X509v3 Subject Alternative Name: DNS:*.trnava-vuc.sk DNS:trnava-vuc.sk Issuer: thawte, Inc. DNS history (Certificate issued on Sep 13) 2017-09-11:trnava-vuc.sk. 86400 IN CAA 0 issuewild = "symantec.com" 2017-09-11:trnava-vuc.sk. 86400 IN CAA 0 issue ";" 2017-09-12:trnava-vuc.sk. 86400 IN CAA 0 issuewild = "thawte.com" 2017-09-12:trnava-vuc.sk. 86400 IN CAA 0 issue ";" 2017-09-13:trnava-vuc.sk. 86400 IN CAA 0 issuewild = "thawte.com" 2017-09-13:trnava-vuc.sk. 86400 IN CAA 0 issue ";" 2017-09-14:trnava-vuc.sk. 86360 IN CAA 0 issuewild = "thawte.com" 2017-09-14:trnava-vuc.sk. 86360 IN CAA 0 issue ";" 2017-09-15:trnava-vuc.sk. 86400 IN CAA 0 issuewild = "thawte.com" 2017-09-15:trnava-vuc.sk. 86400 IN CAA 0 issue ";" 2017-09-16:trnava-vuc.sk. 86400 IN CAA 0 issuewild = "thawte.com" 2017-09-16:trnava-vuc.sk. 86400 IN CAA 0 issue ";" 2017-09-17:trnava-vuc.sk. 86400 IN CAA 0 issuewild = "thawte.com" 2017-09-17:trnava-vuc.sk. 86400 IN CAA 0 issue ";" =3D=3D=3D=3D=3D=3D=3D=3D Certificate 3 - Group 1 =3D=3D=3D=3D=3D=3D=3D=3D https://crt.sh/?id=3D226175601 X509v3 Subject Alternative Name: DNS:*.drillisch-online.de DNS:drillisch-online.de Issuer: COMODO CA Limited DNS history (Certificate issued on Sep 29): 2017-09-28:drillisch-online.de. 3600 IN CAA 0 = issuewild "globalsign.com" 2017-09-28:drillisch-online.de. 3600 IN CAA 0 = issuewild "comodoca.com" 2017-09-28:drillisch-online.de. 3600 IN CAA 0 issue = ";" 2017-09-29:drillisch-online.de. 3600 IN CAA 0 = issuewild "comodoca.com" 2017-09-29:drillisch-online.de. 3600 IN CAA 0 issue = ";" 2017-09-30:drillisch-online.de. 3600 IN CAA 0 = issuewild "comodoca.com" 2017-09-30:drillisch-online.de. 3600 IN CAA 0 issue = ";" =3D=3D=3D=3D=3D=3D=3D Certificate 4 - Group 1 =3D=3D=3D=3D=3D=3D=3D https://crt.sh/?id=3D221763552 X509v3 Subject Alternative Name: DNS:*.uhlhosting.ch DNS:uhlhosting.ch Issuer: Comodo DNS history (Certificate issued on Sep 29): 2017-09-27: uhlhosting.ch. 14400 IN CAA 0 issuewild = =E2=80=9Ccomodoca.com" 2017-09-27: uhlhosting.ch. 14400 IN CAA 0 issue =E2=80=9C= ;=E2=80=9D 2017-09-28: uhlhosting.ch. 14400 IN CAA 0 issuewild = =E2=80=9Ccomodoca.com=E2=80=9D 2017-09-28: uhlhosting.ch. 14400 IN CAA 0 issue =E2=80=9C= ;=E2=80=9D 2017-09-29: uhlhosting.ch. 14400 IN CAA 0 issuewild = =E2=80=9Ccomodoca.com=E2=80=9D 2017-09-29: uhlhosting.ch. 14400 IN CAA 0 issue =E2=80=9C= ;=E2=80=9D 2017-09-30: uhlhosting.ch. 14400 IN CAA 0 issuewild = =E2=80=9Ccomodoca.com" 2017-09-30: uhlhosting.ch. 14400 IN CAA 0 issue =E2=80=9C= ;=E2=80=9D =3D=3D=3D=3D=3D=3D=3D=3D Certificate 5 - Group 1 =3D=3D=3D=3D=3D=3D=3D=3D https://crt.sh/?id=3D211729608 X509v3 Subject Alternative Name: DNS:*.provida.net DNS:provida.net Issuer: COMODO CA Limited DNS history (Certificate issued on Sep 15): 2017-09-13:provida.net. 600 IN CAA 0 issuewild = "comodo.com" 2017-09-13:provida.net. 600 IN CAA 0 issuewild = "symantec.com" 2017-09-13:provida.net. 600 IN CAA 0 issue ";" 2017-09-14:provida.net. 600 IN CAA 0 issuewild = "comodo.com" 2017-09-14:provida.net. 600 IN CAA 0 issuewild = =E2=80=9Csymantec.com" 2017-09-14:provida.net. 600 IN CAA 0 issue =E2=80=9C;"= 2017-09-15:provida.net. 600 IN CAA 0 issuewild = "comodo.com" 2017-09-15:provida.net. 600 IN CAA 0 issuewild = "symantec.com" 2017-09-15:provida.net. 600 IN CAA 0 issue ";" 2017-09-16:provida.net. 600 IN CAA 0 issuewild = "comodo.com" 2017-09-16:provida.net. 600 IN CAA 0 issuewild = =E2=80=9Csymantec.com" 2017-09-16:provida.net. 600 IN CAA 0 issue =E2=80=9C;"= 2017-09-17:provida.net. 600 IN CAA 0 issuewild = "comodo.com" 2017-09-17:provida.net. 600 IN CAA 0 issuewild = "symantec.com" 2017-09-17:provida.net. 600 IN CAA 0 issue =E2=80=9C;=E2= =80=9D =3D=3D=3D=3D=3D=3D=3D Certificate 6 - Group 1 =3D=3D=3D=3D=3D=3D=3D https://crt.sh/?id=3D223356078 X509v3 Subject Alternative Name: DNS:*.cyberbajt.pl DNS:cyberbajt.pl Issuer: Unizeto Technologies S.A. (-> Certum) DNS history (Certificate issued on Oct 1): 2017-09-27:cyberbajt.pl. 86400 IN CAA 0 issue ";" 2017-09-27:cyberbajt.pl. 86400 IN CAA 0 issuewild = "certum.pl" 2017-09-28:cyberbajt.pl. 86400 IN CAA 0 issue ";" 2017-09-28:cyberbajt.pl. 86400 IN CAA 0 issuewild = "certum.pl" 2017-09-29:cyberbajt.pl. 86400 IN CAA 0 issue ";" 2017-09-29:cyberbajt.pl. 86400 IN CAA 0 issuewild = "certum.pl" 2017-09-30:cyberbajt.pl. 86400 IN CAA 0 issue ";" 2017-09-30:cyberbajt.pl. 86400 IN CAA 0 issuewild = "certum.pl" 2017-10-01:cyberbajt.pl. 86400 IN CAA 0 issue ";" 2017-10-01:cyberbajt.pl. 86400 IN CAA 0 issuewild = "certum.pl" 2017-10-02:cyberbajt.pl. 86400 IN CAA 0 issue ";" 2017-10-02:cyberbajt.pl. 86400 IN CAA 0 issuewild = "certum.pl" 2017-10-03:cyberbajt.pl. 86400 IN CAA 0 issue ";" 2017-10-03:cyberbajt.pl. 86400 IN CAA 0 issuewild = "certum.pl" 2017-10-04:cyberbajt.pl. 86400 IN CAA 0 issue ";" 2017-10-04:cyberbajt.pl. 86400 IN CAA 0 issuewild = "certum.pl" =3D=3D=3D=3D=3D=3D=3D Certificate 7 - Group 1 =3D=3D=3D=3D=3D=3D https://crt.sh/?id=3D250171539 X509v3 Subject Alternative Name: DNS:*.s5.nl DNS:s5.nl Issuer: Comodo DNS history (Issued Nov 06): 2017-11-03:s5.nl. 3600 IN CAA 0 issue "letsencrypt.org" 2017-11-03:s5.nl. 3600 IN CAA 0 issuewild = "comodoca.com" 2017-11-04:s5.nl. 3600 IN CAA 0 issue "letsencrypt.org" 2017-11-04:s5.nl. 3600 IN CAA 0 issuewild = "comodoca.com" 2017-11-05:s5.nl. 3600 IN CAA 0 issuewild = "comodoca.com" 2017-11-05:s5.nl. 3600 IN CAA 0 issue "letsencrypt.org" 2017-11-06:s5.nl. 3600 IN CAA 0 issuewild = "comodoca.com" 2017-11-06:s5.nl. 3600 IN CAA 0 issue "letsencrypt.org" 2017-11-07:s5.nl. 3600 IN CAA 0 issuewild = "comodoca.com" 2017-11-07:s5.nl. 3600 IN CAA 0 issue "letsencrypt.org" 2017-11-08:s5.nl. 3600 IN CAA 0 issue "letsencrypt.org" 2017-11-08:s5.nl. 3600 IN CAA 0 issuewild = "comodoca.com" 2017-11-09:s5.nl. 3600 IN CAA 0 issue "letsencrypt.org" 2017-11-09:s5.nl. 3600 IN CAA 0 issuewild = "comodoca.com" =3D=3D=3D=3D=3D=3D=3D Certificate 8 - Group 1 =3D=3D=3D=3D=3D=3D https://crt.sh/?id=3D254174871 X509v3 Subject Alternative Name: DNS:*.invinsec.com DNS:invinsec.com Issuer: GlobalSign (AlphaSSL) DNS history (Issued Nov 12 00:57): 2017-11-10:invinsec.com. 300 IN CAA 0 issue = "digicert.com" 2017-11-10:invinsec.com. 300 IN CAA 0 issue = "letsencrypt.org" 2017-11-10:invinsec.com. 300 IN CAA 0 issuewild ";" 2017-11-11:invinsec.com. 300 IN CAA 0 issue = "digicert.com" 2017-11-11:invinsec.com. 300 IN CAA 0 issue = "letsencrypt.org" 2017-11-11:invinsec.com. 300 IN CAA 0 issuewild = "globalsign.com" 2017-11-12:invinsec.com. 300 IN CAA 0 issue = "digicert.com" 2017-11-12:invinsec.com. 300 IN CAA 0 issue = "letsencrypt.org" 2017-11-12:invinsec.com. 300 IN CAA 0 issuewild = "globalsign.com" 2017-11-13:invinsec.com. 300 IN CAA 0 issue = "digicert.com" 2017-11-13:invinsec.com. 300 IN CAA 0 issue = "letsencrypt.org" 2017-11-13:invinsec.com. 300 IN CAA 0 issuewild = "globalsign.com" 2017-11-14:invinsec.com. 300 IN CAA 0 issue = "digicert.com" 2017-11-14:invinsec.com. 300 IN CAA 0 issue = "letsencrypt.org" 2017-11-14:invinsec.com. 300 IN CAA 0 issuewild = =E2=80=9Cglobalsign.com" =3D=3D=3D=3D=3D=3D=3D Certificate 9 - Group 1 =3D=3D=3D=3D=3D=3D https://crt.sh/?id=3D261922875 X509v3 Subject Alternative Name: DNS:*.imagindata.com DNS:imagindata.com Issuer: Comodo DNS history (Issued Oct 14): 2017-10-12:imagindata.com. 300 IN CAA 0 issue =E2=80=9C= ;" 2017-10-12:imagindata.com. 300 IN CAA 0 issuewild = =E2=80=9Ccomodoca.com 2017-10-13:imagindata.com. 300 IN CAA 0 issue =E2=80=9C= ;" 2017-10-13:imagindata.com. 300 IN CAA 0 issuewild = =E2=80=9Ccomodoca.com 2017-10-14:imagindata.com. 300 IN CAA 0 issue =E2=80=9C= ;" 2017-10-14:imagindata.com. 300 IN CAA 0 issuewild = =E2=80=9Ccomodoca.com 2017-10-15:imagindata.com. 300 IN CAA 0 issue =E2=80=9C= ;" 2017-10-15:imagindata.com. 300 IN CAA 0 issuewild = =E2=80=9Ccomodoca.com 2017-10-16:imagindata.com. 300 IN CAA 0 issue =E2=80=9C= ;" 2017-10-16:imagindata.com. 300 IN CAA 0 issuewild = =E2=80=9Ccomodoca.com =3D=3D=3D=3D=3D=3D Certificate 10 - Group 1 =3D=3D=3D=3D=3D=3D=3D=3D=3D https://crt.sh/?id=3D235359928 X509v3 Subject Alternative Name: DNS:*.gbase.com DNS:gbase.com Issuer: Comodo DNS history (Issued Oct 17): 2017-10-15:gbase.com. 432000 IN CAA 0 issue ";" 2017-10-15:gbase.com. 432000 IN CAA 0 issuewild = "comodoca.com" 2017-10-16:gbase.com. 432000 IN CAA 0 issue ";" 2017-10-16:gbase.com. 432000 IN CAA 0 issuewild = =E2=80=9Ccomodoca.com" 2017-10-17:gbase.com. 432000 IN CAA 0 issue ";" 2017-10-17:gbase.com. 432000 IN CAA 0 issuewild = =E2=80=9Ccomodoca.com" 2017-10-18:gbase.com. 432000 IN CAA 0 issue ";" 2017-10-18:gbase.com. 432000 IN CAA 0 issuewild = =E2=80=9Ccomodoca.com" 2017-10-19:gbase.com. 432000 IN CAA 0 issue ";" 2017-10-19:gbase.com. 432000 IN CAA 0 issuewild = =E2=80=9Ccomodoca.com=E2=80=9D =3D=3D=3D=3D=3D=3D=3D Certificate 11 - Group 2, Group 3 =3D=3D=3D=3D=3D=3D= =3D https://crt.sh/?id=3D206166802 X509v3 Subject Alternative Name: DNS:sni242586.cloudflaressl.com =E2=80=A6 (way more DNS names...) DNS:reed.systems DNS:*.reed.systems =E2=80=A6 (way more DNS names=E2=80=A6) Issuer: Comodo DNS history (Certificate issued on Sep 8): 2017-09-03:reed.systems. 300 IN CAA 0 issue = "letsencrypt.org" 2017-09-04:reed.systems. 300 IN CAA 0 issue = "letsencrypt.org" 2017-09-05:reed.systems. 300 IN CAA 0 issue = "letsencrypt.org" 2017-09-06:reed.systems. 300 IN CAA 0 issue = "letsencrypt.org" 2017-09-07:reed.systems. 300 IN CAA 0 issue = "letsencrypt.org" 2017-09-08:reed.systems. 300 IN CAA 0 issue = "letsencrypt.org" 2017-09-09:reed.systems. 300 IN CAA 0 issue = "letsencrypt.org" 2017-09-10:reed.systems. 300 IN CAA 0 issue = "letsencrypt.org" 2017-09-11:reed.systems. 300 IN CAA 0 issue = "letsencrypt.org" 2017-09-12:reed.systems. 300 IN CAA 0 issue = "letsencrypt.org" 2017-09-13:reed.systems. 300 IN CAA 0 issue = "letsencrypt.org" 2017-09-14:reed.systems. 300 IN CAA 0 issue = "letsencrypt.org" 2017-09-15:reed.systems. 300 IN CAA 0 issue = "letsencrypt.org" =3D=3D=3D=3D=3D=3D=3D Certificate 12, Group 2, Group 3 =3D=3D=3D=3D=3D=3D https://crt.sh/?id=3D207953208 X509v3 Subject Alternative Name: DNS:sni89771.cloudflaressl.com =E2=80=A6 (way more DNS names=E2=80=A6) DNS:*.ficud.international DNS:ficud.international DNS:*ficud.academy DNS:ficud.academy DNS:*ficud.info DNS:ficud.info =E2=80=A6 (way more DNS names=E2=80=A6) Issuer: Comodo DNS history (Certificate issued on Sep 12): 2017-09-06:ficud.international. 300 IN CAA 0 issue = "letsencrypt.org" 2017-09-06:ficud.international. 300 IN CAA 0 issue = "symantec.com" 2017-09-07:ficud.international. 300 IN CAA 0 issue = "letsencrypt.org" 2017-09-07:ficud.international. 300 IN CAA 0 issue = "symantec.com" 2017-09-08:ficud.international. 300 IN CAA 0 issue = "letsencrypt.org" 2017-09-08:ficud.international. 300 IN CAA 0 issue = "symantec.com" 2017-09-09:ficud.international. 300 IN CAA 0 issue = "letsencrypt.org" 2017-09-09:ficud.international. 300 IN CAA 0 issue = "symantec.com" 2017-09-10:ficud.international. 300 IN CAA 0 issue = "letsencrypt.org" 2017-09-10:ficud.international. 300 IN CAA 0 issue = "symantec.com" 2017-09-11:ficud.international. 300 IN CAA 0 issue = "letsencrypt.org" 2017-09-11:ficud.international. 300 IN CAA 0 issue = "symantec.com" 2017-09-12:ficud.international. 300 IN CAA 0 issue = "letsencrypt.org" 2017-09-12:ficud.international. 300 IN CAA 0 issue = "symantec.com" 2017-09-13:ficud.international. 300 IN CAA 0 issue = "letsencrypt.org" 2017-09-13:ficud.international. 300 IN CAA 0 issue = "symantec.com" 2017-09-14:ficud.international. 300 IN CAA 0 issue = "letsencrypt.org" 2017-09-14:ficud.international. 300 IN CAA 0 issue = "symantec.com" 2017-09-15:ficud.international. 300 IN CAA 0 issue = "letsencrypt.org" 2017-09-15:ficud.international. 300 IN CAA 0 issue = "symantec.com" 2017-09-16:ficud.international. 300 IN CAA 0 issue = "letsencrypt.org" 2017-09-16:ficud.international. 300 IN CAA 0 issue = "symantec.com" ficud.academy and ficud.info have the same DNS history. =3D=3D=3D=3D=3D=3D=3D Certificate 13 - Group 3 =3D=3D=3D=3D=3D=3D=3D=3D https://crt.sh/?id=3D246909989 X509v3 Subject Alternative Name: DNS:southcentralcompany-rewards.com =E2=80=A6 Issuer: cPanel (-> Comodo) DNS history (Certificate issued on Sep 10): 2017-09-05:southcentralcompany-rewards.com. 60 IN CAA 0 = issue "symantec.com" 2017-09-06:southcentralcompany-rewards.com. 60 IN CAA 0 = issue "symantec.com" 2017-09-07:southcentralcompany-rewards.com. 60 IN CAA 0 = issue "symantec.com" 2017-09-08:southcentralcompany-rewards.com. 60 IN CAA 0 = issue "symantec.com" 2017-09-09:southcentralcompany-rewards.com. 60 IN CAA 0 = issue "symantec.com" 2017-09-10:southcentralcompany-rewards.com. 60 IN CAA 0 = issue "symantec.com" 2017-09-11:southcentralcompany-rewards.com. 60 IN CAA 0 = issue "symantec.com" 2017-09-12:southcentralcompany-rewards.com. 60 IN CAA 0 = issue "symantec.com" 2017-09-13:southcentralcompany-rewards.com. 60 IN CAA 0 = issue "symantec.com" 2017-09-14:southcentralcompany-rewards.com. 60 IN CAA 0 = issue "symantec.com" 2017-09-15:southcentralcompany-rewards.com. 60 IN CAA 0 = issue "symantec.com" =3D=3D=3D=3D=3D=3D=3D=3D Certificate 14 - Group 3 =3D=3D=3D=3D=3D=3D=3D https://crt.sh/?id=3D261112312 X509v3 Subject Alternative Name: DNS:southcentralcompany-rewards.com ... Issuer: cPanel (-> Comodo) DNS history (Certificate issued on Sep 10): 2017-09-05:homeinsteadrewards.com. 60 IN CAA 0 issue = "symantec.com" 2017-09-06:homeinsteadrewards.com. 60 IN CAA 0 issue = "symantec.com" 2017-09-07:homeinsteadrewards.com. 60 IN CAA 0 issue = "symantec.com" 2017-09-08:homeinsteadrewards.com. 60 IN CAA 0 issue = "symantec.com" 2017-09-09:homeinsteadrewards.com. 60 IN CAA 0 issue = "symantec.com" 2017-09-10:homeinsteadrewards.com. 60 IN CAA 0 issue = "symantec.com" 2017-09-11:homeinsteadrewards.com. 59 IN CAA 0 issue = "symantec.com" 2017-09-12:homeinsteadrewards.com. 60 IN CAA 0 issue = "symantec.com" 2017-09-13:homeinsteadrewards.com. 60 IN CAA 0 issue = "symantec.com" 2017-09-14:homeinsteadrewards.com. 60 IN CAA 0 issue = "symantec.com" 2017-09-15:homeinsteadrewards.com. 60 IN CAA 0 issue = "symantec.com" =3D=3D=3D=3D=3D=3D Certificate 15 - Group 3 =3D=3D=3D=3D=3D=3D (Please note this was issued past Sep 12) https://crt.sh/?id=3D211648524 X509v3 Subject Alternative Name: DNS:www.panphuree.com DNS:panphuree.com Issuer: Comodo DNS history (Certificate issued on Sep 14): 2017-09-12:panphuree.com. 14400 IN CAA 0 issue ";" 2017-09-13:panphuree.com. 14400 IN CAA 0 issue ";" 2017-09-14:panphuree.com. 14400 IN CAA 0 issue ";" 2017-09-15:panphuree.com. 14368 IN CAA 0 issue ";" 2017-09-16:panphuree.com. 14400 IN CAA 0 issue ";" 2017-09-17:panphuree.com. 14400 IN CAA 0 issue ";" 2017-09-18:panphuree.com. 14400 IN CAA 0 issue ";" =3D=3D=3D=3D=3D=3D=3D Certificate 16 - Group 4 =3D=3D=3D=3D=3D=3D=3D https://crt.sh/?id=3D257856701 X509v3 Subject Alternative Name: ... DNS:am-hosting.de DNS:www.am-hosting.de DNS:*.am-hosting.de =E2=80=A6 Issuer: AC CAMERFIRMA DNS history (Issued: Nov 16 14:28 GMT) 2017-11-12:am-hosting.de. 43200 IN CAA 0 issue = "letsencrypt.org" 2017-11-13:am-hosting.de. 43200 IN CAA 0 issue = "letsencrypt.org" 2017-11-14:am-hosting.de. 43200 IN CAA 0 issue = "letsencrypt.org" 2017-11-15:am-hosting.de. 43200 IN CAA 0 issue = "letsencrypt.org" 2017-11-16:am-hosting.de. 43200 IN CAA 0 issue = "letsencrypt.org" 2017-11-17:am-hosting.de. 43200 IN CAA 0 issue = "letsencrypt.org" 2017-11-18:am-hosting.de. 43200 IN CAA 0 issue = =E2=80=9Cletsencrypt.org=E2=80=9D Zoomed (UTC timestamps) 2017-11-15-18:00:am-hosting.de. 43200 IN CAA 0 issue = =E2=80=9Cletsencrypt.org=E2=80=9D 2017-11-15-22:00:am-hosting.de. 43200 IN CAA 0 issue = =E2=80=9Cletsencrypt.org=E2=80=9D 2017-11-15-02:00:am-hosting.de. 43200 IN CAA 0 issue = =E2=80=9Cletsencrypt.org=E2=80=9D 2017-11-16-06:00:am-hosting.de. 43200 IN CAA 0 issue = =E2=80=9Cletsencrypt.org=E2=80=9D 2017-11-16-10:00:am-hosting.de. 43200 IN CAA 0 issue = =E2=80=9Cletsencrypt.org=E2=80=9D 2017-11-16-14:00:am-hosting.de. 43200 IN CAA 0 issue = =E2=80=9Cletsencrypt.org=E2=80=9D Issued: Nov 16 14:28 GMT 2017-11-16-18:00:am-hosting.de. 43200 IN CAA 0 issue = =E2=80=9Cletsencrypt.org=E2=80=9D 2017-11-16-22:00:am-hosting.de. 43200 IN CAA 0 issue = =E2=80=9Cletsencrypt.org=E2=80=9D 2017-11-17-02:00:am-hosting.de. 43200 IN CAA 0 issue = =E2=80=9Cletsencrypt.org=E2=80=9D 2017-11-17-06:00:am-hosting.de. 43200 IN CAA 0 issue = =E2=80=9Cletsencrypt.org=E2=80=9D =3D=3D=3D=3D=3D=3D=3D Certificate 17 - Group 4 =3D=3D=3D=3D=3D=3D=3D https://crt.sh/?id=3D255113449 X509v3 Subject Alternative Name: DNS:*.bankvrn.ru DNS:bankvrn.ru Issuer: Comodo DNS history(Issued Sep 28) 2017-09-27:bankvrn.ru. 3600 IN CAA 0 issue "geotrust.com" 2017-09-27:bankvrn.ru. 3600 IN CAA 0 issue "letsencrypt.org" 2017-09-27:bankvrn.ru. 3600 IN CAA 0 issue "thawte.com" 2017-09-27:bankvrn.ru. 3600 IN CAA 0 issue "wosign.com" 2017-09-27:bankvrn.ru. 3600 IN CAA 0 issuewild =E2=80=9C;" 2017-09-28:bankvrn.ru. 3600 IN CAA 0 issue "letsencrypt.org" 2017-09-28:bankvrn.ru. 3600 IN CAA 0 issue "wosign.com" 2017-09-28:bankvrn.ru. 3600 IN CAA 0 issue "thawte.com" 2017-09-28:bankvrn.ru. 3600 IN CAA 0 issue =E2=80=9Cgeotrust.c= om" 2017-09-28:bankvrn.ru. 3600 IN CAA 0 issuewild ";" 2017-09-29:bankvrn.ru. 3600 IN CAA 0 issue "thawte.com" 2017-09-29:bankvrn.ru. 3600 IN CAA 0 issue "letsencrypt.org" 2017-09-29:bankvrn.ru. 3600 IN CAA 0 issue "geotrust.com" 2017-09-29:bankvrn.ru. 3600 IN CAA 0 issue "wosign.com" 2017-09-29:bankvrn.ru. 3600 IN CAA 0 issuewild ";" =3D=3D=3D=3D=3D=3D=3D=3D Certificate 18 - Group 4 =3D=3D=3D=3D=3D=3D=3D https://crt.sh/?id=3D252132456 X509v3 Subject Alternative Name: DNS:mc21colombia.com DNS:www.mc21colombia.com Issuer: cPanel (-> Comodo) DNS history (Issued Oct 17): 2017-10-14:mc21colombia.com. 3600 IN CAA 0 issuewild = "digicert.com" 2017-10-15:mc21colombia.com. 3600 IN CAA 0 issuewild = "digicert.com" 2017-10-17:mc21colombia.com. 3600 IN CAA 0 issuewild = "digicert.com" 2017-10-18:mc21colombia.com. 300 IN CAA 0 issuewild = "digicert.com" 2017-10-18:mc21colombia.com. 300 IN CAA 0 issue = "digicert.com" 2017-10-19:mc21colombia.com. 300 IN CAA 0 issue = "digicert.com" 2017-10-19:mc21colombia.com. 300 IN CAA 0 issuewild = "digicert.com" 2017-10-20:mc21colombia.com. 300 IN CAA 0 issue = "digicert.com" 2017-10-20:mc21colombia.com. 300 IN CAA 0 issuewild = "digicert.com" 2017-10-21:mc21colombia.com. 300 IN CAA 0 issuewild = "digicert.com" 2017-10-21:mc21colombia.com. 300 IN CAA 0 issue = "digicert.com" 2017-10-22:mc21colombia.com. 300 IN CAA 0 issuewild = "digicert.com" 2017-10-22:mc21colombia.com. 300 IN CAA 0 issue = =E2=80=9Cdigicert.com" =E2=80=94 Quirin Scheitle Web: = https://www.net.in.tum.de/~scheitle/ Technische Universit=C3=A4t M=C3=BCnchen Room: 03.05.037 Department of Computer Science Tel: +49.89.289.18012 Network Architectures and Services --Apple-Mail=_9DEDBBCA-9669-43E6-BEF6-76FF13CD941E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIzBAEBCAAdFiEE1oteY9EBD2dnw300wlghlDYAVBAFAloWDSwACgkQwlghlDYA VBBOZw/+O+lJnqDUkwZT7eb1KLdsy7xAUTjGTJpHoEQrb7h7nLLTH+YjG4jUEtaa mEbJdRGMjjieRSkAxrz9H5FA5XI+yDbgzYleD6S0lVv5odsEl1ECPieEX7DZnDW6 IYFznwS5KmiFvjfx+BxedI32JgAmqdTrjJCv21Rpfjt/zSVFHLBWmb3gVRL5se2w F0b7hlPn87gWMZqXIFpLKNzZ6AKrbi9Sw/rJCx0cU7SumjPGU20QQPK0BilSYFNc wERcfd6KvuyRWs8vkBTkqhvTUqGaUGgJrTga97cfkTZz0Z1gR/73tryRO+puULWm Gj3v/mKkr1buqTLAtE91KnC0fzrF+XISGweNtIRE7lo8oF/kE5NQmfvzk+aoh5QG BJdv6C0hscg6IgnynnNHuKA1WTfUSZ8Q1C2sL3/ecqgWlT1GFGicAWRFtRY4uXuA rDBRZ+ypE88GMYZvtyX1J/5ra//stno7+DmlqDU0mGIJ9k424F3K2GRSkcbIfqNB e1MgGGPEHgj9jRPeZac2yy88QoGzQHUbMYm09bRMSaW69OEX6SocjbWyFFG1OX2S PoP1iuezDRRUaYarfqsA0YdMGafFp1MgNq5lsYFsLccWKjpl74atAp4Jriz3zkak G8dr0/mtxDpHIntbNuXiQU6e6h0+HrnTsoO0dyvZbH6EUevt63o= =OB1n -----END PGP SIGNATURE----- --Apple-Mail=_9DEDBBCA-9669-43E6-BEF6-76FF13CD941E-- From nobody Sun Nov 26 09:03:30 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 808B7129438; Sun, 26 Nov 2017 09:03:17 -0800 (PST) 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 398qCYvwOlXs; Sun, 26 Nov 2017 09:03:15 -0800 (PST) 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 E4C23129435; Sun, 26 Nov 2017 09:03:14 -0800 (PST) Received: by mail-wm0-x232.google.com with SMTP id g130so25622602wme.0; Sun, 26 Nov 2017 09:03:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=K4ZDXmQoM3Wrnz8yK/0H2AuMdpO7FbP6e4RqjITTa/0=; b=qtzINDQXr/e0THMwLVh9arnyQkUulDB6EqJ+o4VDNjoWNuRhrgunsICa66Sa/pLbw8 UeJKKFxc0cbMUk/rkOsE4YPZqpPwJMBFMAQD6ptOQiapX4mR6wvFpSXNQ8lUDfVbh5aG HK2yPt+8roFf4Cl8PwOsyDHCF4oBBxXygdWFPIhGFhEMzMHmEXcvsMgN68V64SGZnDEX Qts6axmTzKYhMm19DZ/TV03T3gwDFl8vZnRfPHGrGfN6ZLXMdIhZGIj4ecImfXG6Qjx1 B7SoKFklZ5w4f+v4vYOOkzIi/jxuhmHSaTZYxsay+K1mXRwzduWTBJedfSfdfjilYhau Deag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=K4ZDXmQoM3Wrnz8yK/0H2AuMdpO7FbP6e4RqjITTa/0=; b=e6aN0tu8IiW5c7O6XstLnl8FWeboM6oLmR4EqK2fR4ekUbETNyMirVvyw2gjmyTTZZ tJz8lfj+IgPqAjqZODDLwgeSbH2ZR/WiK9HMKeFAaxrR+FpnA9iCru/Teaps9JbaCBdK Bhh6RxQiibnCzX5dMBz0mYIDtzSDiXtR9gxcR7VkYeO5uPqUNIUxbbUn4okz1ZVg4CHz lMuWWjIi2dy/l4+hnIcwRpKpu7x43B02ihJHBvIgoDK6va3YzgHudFj6vilY0xlQAt1y 8fgYV9kWm43yqlxmMeiLWJ4xVmtD2rV4UrBpuF3cAZ/o8+lOQDCnUyDN8+6pLmf8W1Nx pRgg== X-Gm-Message-State: AJaThX4jGbOJ8gfeFjyVQLN1WW5xuKMIo4cKzlsswnHyWJxFcmWTs9Jz NvLsEozVRmfycZR6vSHgvJPuZRTiU6sHb3zg8lhv2VHc X-Google-Smtp-Source: AGs4zMYw9Q3OolGqjb8J1vPyeJ93+//toS9Zm+MWQKk4c418E9vBRzdm+clvFAUM+LwHIlpze9ZqizuOhMhn59A03Uk= X-Received: by 10.80.208.195 with SMTP id g3mr48518595edf.246.1511715793362; Sun, 26 Nov 2017 09:03:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.139.216 with HTTP; Sun, 26 Nov 2017 09:03:12 -0800 (PST) In-Reply-To: References: <150522092693.4724.2532571098567577114.idtracker@ietfa.amsl.com> From: Dmitry Belyavsky Date: Sun, 26 Nov 2017 20:03:12 +0300 Message-ID: To: Nikos Mavrogiannopoulos Cc: LAMPS , pkix@ietf.org, dev-security-policy@lists.mozilla.org, "saag@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c1cd2fadd64dc055ee5c28b" Archived-At: Subject: Re: [lamps] [saag] Fwd: New Version Notification for draft-belyavskiy-certificate-limitation-policy-04.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Nov 2017 17:03:17 -0000 --94eb2c1cd2fadd64dc055ee5c28b Content-Type: text/plain; charset="UTF-8" Hello, I've just uploaded the new version of my draft. The main difference from the previous one is more or less described syntax of specific limitations mentioned in text. The answers on the question raised by Nikos are below. ================= A new version of I-D, draft-belyavskiy-certificate-limitation-policy-05.txt has been successfully submitted by Dmitry Belyavskiy and posted to the IETF repository. Name: draft-belyavskiy-certificate-limitation-policy Revision: 05 Title: Certificate Limitation Policy Document date: 2017-11-25 Group: Individual Submission Pages: 9 URL: https://www.ietf.org/internet-drafts/draft-belyavskiy- certificate-limitation-policy-05.txt Status: https://datatracker.ietf.org/doc/draft-belyavskiy- certificate-limitation-policy/ Htmlized: https://tools.ietf.org/html/draft-belyavskiy-certificate- limitation-policy-05 Htmlized: https://datatracker.ietf.org/doc/html/draft-belyavskiy- certificate-limitation-policy-05 Diff: https://www.ietf.org/rfcdiff?url2=draft-belyavskiy- certificate-limitation-policy-05 Abstract: The document provides a specification of the application-level trust model. Being provided at the application level, the limitations of trust can be distributed separately using cryptographically protected format instead of hardcoding the checks into the application itself. ================== On Thu, Oct 12, 2017 at 3:03 PM, Nikos Mavrogiannopoulos via dev-security-policy wrote: > On Sat, Oct 7, 2017 at 8:37 PM, Dmitry Belyavsky > wrote: > > Dear Nicos, > > > > Sorry for the delay with my response. > > > > On Fri, Sep 22, 2017 at 11:06 AM, Nikos Mavrogiannopoulos < > nmav@gnutls.org> > > wrote: > >> > >> On Wed, Sep 20, 2017 at 3:21 PM, Dmitry Belyavsky > >> wrote: > >> > > > > Well, the specification I suggest should allow applying CLPs issued by > major > > vendors (Mozilla etc). > > For this purposes the CLPs should be validable => signed. > > Hi, > If mozilla or any other organization is willing to deploy such PKI, > that would be great. However for the majority of software, I'd expect > that such files are distributed using the same channel as software, > and thus using the same authentication mechanism for it rather than a > new PKI. For a software distributor to use that optional signing could > work. > I got your point. I'll think about allowing local CLPs to be unsigned. > > >> One problem with that is the fact that the existing CRL extensions are > >> about extending attributes of the CRL, rather than adding/removing > >> attributes to the certificate in question. > > For this purposes I implied that the limitations are provided not by > > extensions, > > but as SEQUENCE of limitations related to the certificates. > > > > Was I wrong in the ASN1 scheme in the current version of my draft? > > I do not think that the presented ASN.1 description is valid. > The "limitations SEQUENCE," doesn't define anything in ASN.1 > (i..e, it is a sequence of what?). > I (hopefully) clarified the ASN.1 description in the new version. > > >> > >> To bring the stapled extensions to your proposal, you'd need the > >> Extensions and Extension fields from RFC5280, and > >> add into limitedCertificates structure (I'll split it on the example > >> below for clarity) the following field. > >> > >> LimitedCertificates ::= SEQUENCE OF LimitedCertificate > >> > >> LimitedCertificate ::= SEQUENCE { > >> userCertificate CertificateSerialNumber, > >> certificateIssuer Name, > >> limitationDate Time, > >> limitationPropagation Enum, > >> fingerprint SEQUENCE { > >> fingerprintAlgorithm AlgorithmIdentifier, > >> fingerprintValue OCTET STRING > >> } OPTIONAL, > >> limitations SEQUENCE, > >> } OPTIONAL, > >> }; > >> > >> > >> stapledExtensions Extensions; <----- NEW > >> } > > > > > > Sorry, I do not get the difference between the purposes of the field > > 'limitations' > > and 'stapledExtensions'. > > I cannot answer this as I cannot see the syntax of the limitations > field. I thought it was a field intended to spark discussion rather > than anything specific. > Now, when the syntax is provided, I hope it's specific enough to continue the discussion. -- SY, Dmitry Belyavsky --94eb2c1cd2fadd64dc055ee5c28b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

I've just uploaded the new v= ersion of my draft.

The main difference from the p= revious one is more or less described syntax of=C2=A0
specific li= mitations mentioned in text.=C2=A0

The answers= on the question raised by Nikos are below.

=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
A new version of I-D, draft-belyavskiy-certificate-limitation-po= licy-05.txt
has been successfully submitted by Dmitry Belyavskiy and posted to t= he
IE= TF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0draft-belyavskiy-certificate-limitation-policy
Revision:=C2=A0 =C2=A0 = =C2=A0 =C2=A005
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Certificate Limitation = Policy
Document date:=C2=A0 2017-11-25
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Indiv= idual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 9
URL:=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0=C2=A0https://www.ietf.org/inte= rnet-drafts/draft-belyavskiy-certificate-limitation-policy-0= 5.txt
St= atus:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ie= tf.org/doc/draft-belyavskiy-certificate-limitation-policy/Htmlized:=C2= =A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-b= elyavskiy-certificate-limitation-policy-05
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2= =A0https://datatracker.ietf.org/doc/html/draft-be= lyavskiy-certificate-limitation-policy-05
Diff:=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2= =3Ddraft-belyavskiy-certificate-limitation-policy-05

Abstract:
=C2=A0 =C2=A0The document provides a specification of the a= pplication-level trust
=C2=A0 =C2=A0model.=C2=A0 Being provided at the applicati= on level, the limitations of
=C2=A0 =C2=A0trust can be distributed separately us= ing cryptographically protected
=C2=A0 =C2=A0format instead of hardcoding the ch= ecks into the application itself.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<= /div>

On Thu, Oct 12, 2017 at 3:03 PM, Nik= os Mavrogiannopoulos via dev-security-policy <dev-sec= urity-policy@lists.mozilla.org> wrote:
On Sat, Oct 7, 2017 at 8:37 PM, Dmitry Belyavsky <beldmit@gmail.com> wrote:
> Dear Nicos,
>
> Sorry for the delay with my response.
>
> On Fri, Sep 22, 2017 at 11:06 AM, Nikos Mavrogiannopoulos <nmav@gnutls.org>
> wrote:
>>
>> On Wed, Sep 20, 2017 at 3:21 PM, Dmitry Belyavsky <beldmit@gmail.com>
>> wrote:
>>
>
> Well, the specification I suggest should allow applying CLPs issued by= major
> vendors (Mozilla etc).
> For this purposes the CLPs should be validable =3D> signed.

Hi,
=C2=A0If mozilla or any other organization is willing to deploy such PKI, that would be great. However for the majority of software, I'd expect that such files are distributed using the same channel as software,
and thus using the same authentication mechanism for it rather than a
new PKI. For a software distributor to use that optional signing could
work.

I got your point. I'll think = about allowing local CLPs to be unsigned.
=C2=A0

>> One problem with that is the fact that the existing CRL extensions= are
>> about extending attributes of the CRL, rather than adding/removing=
>> attributes to the certificate in question.
> For this purposes I implied that the limitations are provided not by > extensions,
> but as SEQUENCE of limitations related to the certificates.
>
> Was I wrong in the ASN1 scheme in the current version of my draft?

I do not think that the presented ASN.1 description is valid.
The "limitations=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 SEQUENCE," doe= sn't define anything in ASN.1
(i..e, it is a sequence of what?).

I (h= opefully) clarified the ASN.1 description in the new version.
=C2= =A0

>>
>> To bring the stapled extensions to your proposal, you'd need t= he
>> Extensions and Extension fields from RFC5280, and
>> add into limitedCertificates structure (I'll split it on the e= xample
>> below for clarity) the following field.
>>
>> LimitedCertificates=C2=A0 ::=3D=C2=A0 =C2=A0SEQUENCE OF LimitedCer= tificate
>>
>> LimitedCertificate ::=3D SEQUENCE {
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0userC= ertificate=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0CertificateSerialNumber,
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0certi= ficateIssuer=C2=A0 =C2=A0 =C2=A0 =C2=A0Name,
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0limit= ationDate=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Time,
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0limit= ationPropagation=C2=A0 =C2=A0Enum,
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0finge= rprint SEQUENCE {
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0fingerprintAlgorithm AlgorithmIdentifier,
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0fingerprintValue=C2=A0 =C2=A0 =C2=A0OCTET STRING
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 } OPTION= AL,
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0limit= ations=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 SEQUENCE,
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 } OPTIONAL,
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 };
>>
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0stapl= edExtensions Extensions; <----- NEW
>> }
>
>
> Sorry, I do not get the difference between the purposes of the field > 'limitations'
> and 'stapledExtensions'.

I cannot answer this as I cannot see the syntax of the limitations field. I thought it was a field intended to spark discussion rather
than anything specific.

Now, when the s= yntax is provided, I hope it's specific enough to continue the discussi= on.

--=C2=A0
SY, Dmitry Belyavsky
--94eb2c1cd2fadd64dc055ee5c28b-- From nobody Tue Nov 28 08:17:12 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 126A5128B27 for ; Tue, 28 Nov 2017 08:17:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ixkzubo6Iq1i for ; Tue, 28 Nov 2017 08:17:04 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DA57127517 for ; Tue, 28 Nov 2017 08:17:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 95EEF300581 for ; Tue, 28 Nov 2017 11:17:03 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id JWcvZJl7y22X for ; Tue, 28 Nov 2017 11:16:58 -0500 (EST) Received: from new-host-8.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id CB7D0300431; Tue, 28 Nov 2017 11:16:58 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Russ Housley In-Reply-To: <84e6d5a2-4a51-8993-00ef-56be4e1c04be@eff.org> Date: Tue, 28 Nov 2017 11:17:57 -0500 Cc: SPASM Content-Transfer-Encoding: quoted-printable Message-Id: <680EB976-D9D9-4BF8-A93D-C6146BE9DCB4@vigilsec.com> References: <84e6d5a2-4a51-8993-00ef-56be4e1c04be@eff.org> To: Jacob Hoffman-Andrews X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [lamps] Moving caa-simplification to a WG document? X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Nov 2017 16:17:09 -0000 Our Area Director needs to complete the recharter before the document = can be formally adopted. Russ > On Nov 17, 2017, at 3:41 PM, Jacob Hoffman-Andrews = wrote: >=20 > At the WG session at IETF100 we took a hum on standardizing the CAA > implementation that's current in production, i.e. the contents of > = https://www.ietf.org/id/draft-hoffman-andrews-caa-simplification-02.txt. > Currently that's published as an individual draft. What steps do we = need > to take to turn that into a WG document so we can make progress = towards > an RFC? >=20 > Thanks, > Jacob