From nobody Mon Sep 4 11:19:02 2017 Return-Path: X-Original-To: spasm@ietf.org Delivered-To: spasm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DF868124207; Mon, 4 Sep 2017 11:18:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.59.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150454913486.508.11678305114450077442@ietfa.amsl.com> Date: Mon, 04 Sep 2017 11:18:54 -0700 Archived-At: Subject: [lamps] I-D Action: draft-ietf-lamps-eai-addresses-14.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Sep 2017 18:18:55 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Limited Additional Mechanisms for PKIX and SMIME WG of the IETF. Title : Internationalized Email Addresses in X.509 certificates Authors : Alexey Melnikov Weihaw Chuang Filename : draft-ietf-lamps-eai-addresses-14.txt Pages : 11 Date : 2017-09-04 Abstract: This document defines a new name form for inclusion in the otherName field of an X.509 Subject Alternative Name and Issuer Alternative Name extension that allows a certificate subject to be associated with an Internationalized Email Address. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lamps-eai-addresses/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lamps-eai-addresses-14 https://datatracker.ietf.org/doc/html/draft-ietf-lamps-eai-addresses-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-eai-addresses-14 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Sep 4 12:27:36 2017 Return-Path: X-Original-To: spasm@ietf.org Delivered-To: spasm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DA5812421A; Mon, 4 Sep 2017 12:27:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.59.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150455324909.583.12479591544488867184@ietfa.amsl.com> Date: Mon, 04 Sep 2017 12:27:29 -0700 Archived-At: Subject: [lamps] I-D Action: draft-ietf-lamps-rfc5280-i18n-update-03.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Sep 2017 19:27:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Limited Additional Mechanisms for PKIX and SMIME WG of the IETF. Title : Internationalization Updates to RFC 5280 Author : Russ Housley Filename : draft-ietf-lamps-rfc5280-i18n-update-03.txt Pages : 8 Date : 2017-09-04 Abstract: These updates to RFC 5280 provide clarity on the handling of Internationalized Domain Names (IDNs) and Internationalized Email Addresses in X.509 Certificates. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5280-i18n-update/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lamps-rfc5280-i18n-update-03 https://datatracker.ietf.org/doc/html/draft-ietf-lamps-rfc5280-i18n-update-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-rfc5280-i18n-update-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Sep 4 12:30:16 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2B5F1270AB for ; Mon, 4 Sep 2017 12:30:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KI5G7Oeahxnx for ; Mon, 4 Sep 2017 12:30:09 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9350E126E7A for ; Mon, 4 Sep 2017 12:30:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 8C6DA30058F for ; Mon, 4 Sep 2017 15:30:08 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id aQJlakW0QCCx for ; Mon, 4 Sep 2017 15:30:03 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id CFB313002AE for ; Mon, 4 Sep 2017 15:30:02 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 4 Sep 2017 15:30:06 -0400 References: <150455324909.583.12479591544488867184@ietfa.amsl.com> To: spasm@ietf.org In-Reply-To: <150455324909.583.12479591544488867184@ietfa.amsl.com> Message-Id: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [lamps] I-D Action: draft-ietf-lamps-rfc5280-i18n-update-03.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Sep 2017 19:30:15 -0000 This version was posted to align with = draft-ietf-lamps-eai-addresses-14.txt that was posted yesterday. Russ =20 > On Sep 4, 2017, at 3:27 PM, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Limited Additional Mechanisms for = PKIX and SMIME WG of the IETF. >=20 > Title : Internationalization Updates to RFC 5280 > Author : Russ Housley > Filename : draft-ietf-lamps-rfc5280-i18n-update-03.txt > Pages : 8 > Date : 2017-09-04 >=20 > Abstract: > These updates to RFC 5280 provide clarity on the handling of > Internationalized Domain Names (IDNs) and Internationalized Email > Addresses in X.509 Certificates. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5280-i18n-update/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-lamps-rfc5280-i18n-update-03 > = https://datatracker.ietf.org/doc/html/draft-ietf-lamps-rfc5280-i18n-update= -03 >=20 > A diff from the previous version is available at: > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lamps-rfc5280-i18n-update-0= 3 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Sep 11 17:06: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 75B2313202D for ; Mon, 11 Sep 2017 17:06:57 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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=letsencrypt.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 KfzT1JFK001G for ; Mon, 11 Sep 2017 17:06:55 -0700 (PDT) Received: from mail-pg0-x235.google.com (mail-pg0-x235.google.com [IPv6:2607:f8b0:400e:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 395D3129C41 for ; Mon, 11 Sep 2017 17:06:55 -0700 (PDT) Received: by mail-pg0-x235.google.com with SMTP id j16so7906253pga.1 for ; Mon, 11 Sep 2017 17:06:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=letsencrypt.org; s=google; h=subject:references:to:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=VB0HszD67XTLRef14n882Uemwp+LsK466dFkqk4iw3s=; b=cEtDyHESRlKR0HEeAz/yPxsOYld/oULyOrs6eb3yM1/e1RU+AiLFk5KZQONgX1Df4l w66ecDy1s470c7yrWXWfP/ghAMn67LtfotkDxS8n4z8fMS/EclvtfSMzgeAv50g9EkN4 uoLkB0Z+q+Kf4jj3rOfQnOcRK1Hz6PdFt/BtA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:references:to:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=VB0HszD67XTLRef14n882Uemwp+LsK466dFkqk4iw3s=; b=dRTIplPiozfvAj2EQ3NO3ldTkPS3eyx9VcuKaYtiz7HAkP3t/GpH7RWnckf/l4yrgS ZfrsgCU+4U1ByF2A0CblB7zsxV/Yl65Q0OeyKesI5LHSjSmyEbxemv1qiyrGfY10REQU PLn/ut+fxS4mSOoBnEV54TuB2v6dZSfE48SfMmD9QnuDEJpz2i5hOTDSXsBHHVkbtfEe OqQKnuZvGSD72UQMFCiCromoFdhoa0hrYp14ctpnpLddVKGLSNYnOTp82bHSBvm+RTyE EAUzCbAH7ktXzCd70ew7yv/1Qu9IBo4wG+SFrtWSCNU7nvKMTggK8etaLweGMCgn/dMB UB+Q== X-Gm-Message-State: AHPjjUgwFGgEfUPoTS+91P0dlD2Z5G6OdJBqofiPxtVojjOlJFO+eXzV XyiO3gdrNESgQYaVl3N9KA== X-Google-Smtp-Source: ADKCNb4ITRumQ6m4k1wQc8RKoMpwxFLIgDWUH2LnEoSLucQ4Ry/g6gi2VYphpTSGb6VLjYYsclNKUg== X-Received: by 10.84.210.73 with SMTP id z67mr15482770plh.306.1505174814456; Mon, 11 Sep 2017 17:06:54 -0700 (PDT) Received: from [10.120.0.195] (eff.static.monkeybrains.net. [208.90.213.162]) by smtp.gmail.com with ESMTPSA id c2sm17723260pgq.61.2017.09.11.17.06.53 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 Sep 2017 17:06:53 -0700 (PDT) References: <150517397019.4116.4492139524663168926.idtracker@ietfa.amsl.com> To: spasm@ietf.org From: Roland Shoemaker X-Forwarded-Message-Id: <150517397019.4116.4492139524663168926.idtracker@ietfa.amsl.com> Message-ID: <95e2ac38-9d9c-f362-cb18-f6fe005e37c1@letsencrypt.org> Date: Mon, 11 Sep 2017 17:06:53 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <150517397019.4116.4492139524663168926.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [lamps] Fwd: New Version Notification for draft-shoemaker-caa-ip-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: Tue, 12 Sep 2017 00:06:57 -0000 Recent work in the ACME WG on implementing validation mechanisms for IP addresses (draft-ietf-acme-ip) brought up the issue that there is currently no way for owners of IP addresses to programmatically restrict issuance of certificates for those identifiers. CAA seems like the most obvious mechanism but the algorithm defined in RFC 6844 is only applicable to DNS names. This draft defines a basic lookup mechanism for CAA records for IP addresses. I'd be very interested in the WG's thoughts on this document and opinions on if LAMPS would be the right place for it to be worked on. Thanks, Roland -------- Forwarded Message -------- Subject: New Version Notification for draft-shoemaker-caa-ip-00.txt Date: Mon, 11 Sep 2017 16:52:50 -0700 From: internet-drafts@ietf.org To: Roland Bracewell Shoemaker , Roland Shoemaker A new version of I-D, draft-shoemaker-caa-ip-00.txt has been successfully submitted by Roland Bracewell Shoemaker and posted to the IETF repository. Name: draft-shoemaker-caa-ip Revision: 00 Title: Certification Authority Authorization (CAA) Validation for IP Addresses Document date: 2017-09-11 Group: Individual Submission Pages: 4 URL: https://www.ietf.org/internet-drafts/draft-shoemaker-caa-ip-00.txt Status: https://datatracker.ietf.org/doc/draft-shoemaker-caa-ip/ Htmlized: https://tools.ietf.org/html/draft-shoemaker-caa-ip-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-shoemaker-caa-ip-00 Abstract: The Certification Authority Authorization (CAA) RFC specifies a method for users to restrict which Certificate Authorities (CAs) are authorized to issue certificates for their DNS domain names. This document extends that specification to provide a method for holders of IP addresses to do the same. 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 From nobody Tue Sep 12 05:59: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 CDFD1132153; Tue, 12 Sep 2017 05:59:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.439 X-Spam-Level: X-Spam-Status: No, score=-2.439 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pylyV2xLCTCX; Tue, 12 Sep 2017 05:59:35 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7066213208E; Tue, 12 Sep 2017 05:59:35 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id i189so57825539wmf.1; Tue, 12 Sep 2017 05:59:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=nAXHDDrCBkCZJr1EdCcWq9bISIFxJiOWhBzU5tTVZJI=; b=f8eXI7yrwtGR+HS1g+XrVBejmhc8UMLFqciKUnipNnWmil7ZZa+NCTD0uSE6cecWoh fnD4DsO7mnwIEu62X/p86WIraC1LfBA/Uh45yJqpbzvR6G7EVoq23S4bnQKR2Rt3mjsd bEbBbEF30kUzR5aIIu86sCL7e9/S9hmmR/i4mVioAwds+falG3tcsdhesHKjoKlzMqjF XgaaUtl/7ICVHe87P617n/l6egiipTNiYMqmcz5SI8amSTdXsp1IbarHYVsY9604Xd30 jlYaelD7dBt83RvujsGxiDP7BELi8D2K+tkP6ZydvdzdVqI97r0xe5iiQYNfemPb5qYa Fsrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=nAXHDDrCBkCZJr1EdCcWq9bISIFxJiOWhBzU5tTVZJI=; b=AEbQ3qwEAw7RtRBxRxmCx3re824l4HPtDhfwBoe90H82MznictzP9lsOxZLOSv0GEh Uo5tgmvUKDukf5OGd9rqOipBBflwmUeQw5vptnXjn/j2B4qjmyqznJACIGibuNtjfcrb 0de9KnnMeIxURSb2TnPuzpjTOIJVc4aKqQkpuhAwjqP0eAe7vQwsgKRGRPbLZFoE9+mH hEfJAaG1KJ/Ke+bS+gGD9gaqAnimrwqBPcJ7yGBimvTnyD4UKisQerxh5VFLvD9xHXVS ACFk4DMo5HlHZAUswj+AWB7abmymtpz5M5bSA82wI4Yq69X3mr/5bZg8TKb9wpZTTIO2 QNfA== X-Gm-Message-State: AHPjjUhUy8XPYkxJQY/MhfYpJU+i0w0YqAzz4H7ru9MKRLoe/o0lYe+J JcuB5qVfYpnRS7P6ztBcoGJ6meWe1Q== X-Google-Smtp-Source: ADKCNb6fMlIldlbwuSvGQp4jsdUyAEF74D8OS3iHJIBnMHpcRiiCJZ+InzHtcDwatjuIVK2h+ylKu1o2pYCeCxPAiLg= X-Received: by 10.80.128.133 with SMTP id 5mr6467465edb.149.1505221173801; Tue, 12 Sep 2017 05:59:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.186.44 with HTTP; Tue, 12 Sep 2017 05:59:33 -0700 (PDT) In-Reply-To: <150522092693.4724.2532571098567577114.idtracker@ietfa.amsl.com> References: <150522092693.4724.2532571098567577114.idtracker@ietfa.amsl.com> From: Dmitry Belyavsky Date: Tue, 12 Sep 2017 15:59:33 +0300 Message-ID: To: "saag@ietf.org" , LAMPS , dev-security-policy@lists.mozilla.org, pkix@ietf.org Content-Type: multipart/alternative; boundary="94eb2c067f745f77590558fd9d32" Archived-At: Subject: [lamps] 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: Tue, 12 Sep 2017 12:59:38 -0000 --94eb2c067f745f77590558fd9d32 Content-Type: text/plain; charset="UTF-8" Hello, Here is the new version of the draft updated according to the discussion on mozilla-dev-security list. ---------- Forwarded message ---------- From: Date: Tue, Sep 12, 2017 at 3:55 PM Subject: New Version Notification for draft-belyavskiy-certificate-l imitation-policy-04.txt To: Dmitry Belyavskiy A new version of I-D, draft-belyavskiy-certificate-limitation-policy-04.txt has been successfully submitted by Dmitry Belyavskiy and posted to the IETF repository. Name: draft-belyavskiy-certificate-limitation-policy Revision: 04 Title: Certificate Limitation Policy Document date: 2017-09-11 Group: Individual Submission Pages: 7 URL: https://www.ietf.org/internet-drafts/draft-belyavskiy-certif icate-limitation-policy-04.txt Status: https://datatracker.ietf.org/doc/draft-belyavskiy-certifica te-limitation-policy/ Htmlized: https://tools.ietf.org/html/draft-belyavskiy-certificate-li mitation-policy-04 Htmlized: https://datatracker.ietf.org/doc/html/draft-belyavskiy-cert ificate-limitation-policy-04 Diff: https://www.ietf.org/rfcdiff?url2=draft-belyavskiy-certific ate-limitation-policy-04 Abstract: The document provides a specification of the application-level trust model. Being provided at the application level, the limitations of trust can be distributed separately using cryptographically protected format instead of hardcoding the checks into the application itself. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat -- SY, Dmitry Belyavsky --94eb2c067f745f77590558fd9d32 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

Here is the new version of the d= raft updated according to the discussion on mozilla-dev-security list.

---------- Forwarded message ---------= -
From: <internet-drafts@ietf= .org>
Date: Tue, Sep 12, 2017 at 3:55 PM
Subject: New V= ersion Notification for draft-belyavskiy-certificate-limitation-policy= -04.txt
To: Dmitry Belyavskiy <beldmit@gmail.com>



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

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

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




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

The IETF Secretariat




--
SY, Dmitry Belyavsky
--94eb2c067f745f77590558fd9d32-- From nobody Tue Sep 12 08:16:18 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 8951C13304F for ; Tue, 12 Sep 2017 08:16:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.63 X-Spam-Level: X-Spam-Status: No, score=-1.63 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, SPF_PASS=-0.001, T_HK_NAME_DR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YyVpQfMHzPjC for ; Tue, 12 Sep 2017 08:16:14 -0700 (PDT) Received: from mail.katezarealty.com (mail.katezarealty.com [104.168.158.213]) by ietfa.amsl.com (Postfix) with ESMTP id 7E4F813302A for ; Tue, 12 Sep 2017 08:16:14 -0700 (PDT) Received: from maxs-mbp.cablelabs.com (host64-111.cablelabs.com [192.160.73.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.katezarealty.com (Postfix) with ESMTPSA id 167D637404C1 for ; Tue, 12 Sep 2017 11:16:14 -0400 (EDT) To: spasm@ietf.org References: <150522092693.4724.2532571098567577114.idtracker@ietfa.amsl.com> From: "Dr. Pala" Message-ID: Date: Tue, 12 Sep 2017 09:16:14 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------70CB07465012FF8D6A064047" Content-Language: en-US Archived-At: Subject: Re: [lamps] [pkix] 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: Tue, 12 Sep 2017 15:16:16 -0000 This is a multi-part message in MIME format. --------------70CB07465012FF8D6A064047 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Dmitry, could you please summarize the discussion that happened in the mozilla-dev-security? Cheers, Max On 9/12/17 6:59 AM, Dmitry Belyavsky wrote: > Hello, > > Here is the new version of the draft updated according to the > discussion on mozilla-dev-security list. > > ---------- Forwarded message ---------- > From: > > Date: Tue, Sep 12, 2017 at 3:55 PM > Subject: New Version Notification for > draft-belyavskiy-certificate-limitation-policy-04.txt > To: Dmitry Belyavskiy > > > > > A new version of I-D, > draft-belyavskiy-certificate-limitation-policy-04.txt > has been successfully submitted by Dmitry Belyavskiy and posted to the > IETF repository. > > Name:           draft-belyavskiy-certificate-limitation-policy > Revision:       04 > Title:          Certificate Limitation Policy > Document date:  2017-09-11 > Group:          Individual Submission > Pages:          7 > URL: > https://www.ietf.org/internet-drafts/draft-belyavskiy-certificate-limitation-policy-04.txt > > Status: > https://datatracker.ietf.org/doc/draft-belyavskiy-certificate-limitation-policy/ > > Htmlized: > https://tools.ietf.org/html/draft-belyavskiy-certificate-limitation-policy-04 > > Htmlized: > https://datatracker.ietf.org/doc/html/draft-belyavskiy-certificate-limitation-policy-04 > > Diff: > https://www.ietf.org/rfcdiff?url2=draft-belyavskiy-certificate-limitation-policy-04 > > > Abstract: >    The document provides a specification of the application-level trust >    model.  Being provided at the application level, the limitations of >    trust can be distributed separately using cryptographically protected >    format instead of hardcoding the checks into the application itself. > > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org > . > > The IETF Secretariat > > > > > -- > SY, Dmitry Belyavsky > > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm --------------70CB07465012FF8D6A064047 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi Dmitry,

could you please summarize the discussion that happened in the mozilla-dev-security?

Cheers,
Max


On 9/12/17 6:59 AM, Dmitry Belyavsky wrote:
Hello,

Here is the new version of the draft updated according to the discussion on mozilla-dev-security list.

---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Tue, Sep 12, 2017 at 3:55 PM
Subject: New Version Notification for draft-belyavskiy-certificate-limitation-policy-04.txt
To: Dmitry Belyavskiy <beldmit@gmail.com>



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

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

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




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

The IETF Secretariat




--
SY, Dmitry Belyavsky


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

--------------70CB07465012FF8D6A064047-- From nobody Tue Sep 12 11:22:34 2017 Return-Path: X-Original-To: spasm@ietf.org Delivered-To: spasm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CA36132ED1; Tue, 12 Sep 2017 11:22:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.61.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150524055309.18011.6603266773592828841@ietfa.amsl.com> Date: Tue, 12 Sep 2017 11:22:33 -0700 Archived-At: Subject: [lamps] I-D Action: draft-ietf-lamps-eai-addresses-15.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Sep 2017 18:22:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Limited Additional Mechanisms for PKIX and SMIME WG of the IETF. Title : Internationalized Email Addresses in X.509 certificates Authors : Alexey Melnikov Weihaw Chuang Filename : draft-ietf-lamps-eai-addresses-15.txt Pages : 11 Date : 2017-09-12 Abstract: This document defines a new name form for inclusion in the otherName field of an X.509 Subject Alternative Name and Issuer Alternative Name extension that allows a certificate subject to be associated with an Internationalized Email Address. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lamps-eai-addresses/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lamps-eai-addresses-15 https://datatracker.ietf.org/doc/html/draft-ietf-lamps-eai-addresses-15 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-eai-addresses-15 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Sep 12 12:54:18 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 649FA132EFB for ; Tue, 12 Sep 2017 12:54:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PT7-J-UjdyWU for ; Tue, 12 Sep 2017 12:54:14 -0700 (PDT) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CDAB132697 for ; Tue, 12 Sep 2017 12:54:14 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id f199so3004755wme.0 for ; Tue, 12 Sep 2017 12:54:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=gA9nTUdxl+efUOe+W/i5nVGboHEM6ryS/D4dwDdJb2A=; b=Gs6PHfvAvl8GFoBEdGz54Fltxps6LPQyTJrEBWr6FZTdGYo3ZrDw/hEPXOnrtE/SWs KO8r8gfTVONbgrvX7bI7CnzDdHE/YKc2Wd57wiBzm71BCPYQ+AoriyFjcQaujHQHFXef xDDCFXhuR4MPMVFpEF6qQP90b7tND2r/gsTQfQ5mmalng8v3BeI/e/6jT9MzNM6CI7v7 cD/8G2NgBw4qEV2ti/5l076T9tla1kzrCYJRiVF8jfSz473W6mWbxI1HioZqfWV004X3 LfnjnhcQTVEjE91VpQ1wD193AMpWvNoPmorpL/Xxz5w/uibK8OmiZ4QCjKKi+s7mdC3Z Pf5A== 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=gA9nTUdxl+efUOe+W/i5nVGboHEM6ryS/D4dwDdJb2A=; b=cmnGiDvGgMpR2vLsXvmhhSH/dbXwz5NH8Nz1bFjsWgJRDYoDfW8/b+YZmpNhrDRI8n /RBawusIHIIPsnPHR4cI8AClo1Owwz/VmyZsTOXfteYb9fZOqM6UkQF+CC2ITIPccWVH c57S2od26Qyyx5LhNKee331SVpaYkZADIjg1OcLn8jBKgLCz6YUA2/BEkPuPVRLfadaF ljpZdO7HyRGGldmuImEgeKv29GBmbF3/j2Jlql697U+l1+85X68UA7Y4Phle6/NuXQqO OJrJnofu9L2Qg2o+CJPHMRU0SIZQkH0alei6leENXoi7gdoXogCpqKS5rtf2DRKOGVyo HVrA== X-Gm-Message-State: AHPjjUjVuTXYsOimayxy5kwm3Xiz4C7y3MI0nWupfOwdrMnstwa0ZXZH fALdarZAwFxy9mUDeLhIjUQQA7WmbSPnLvEAbDlFow== X-Google-Smtp-Source: AOwi7QC9JGNeSdDfr2L9oqN5qzC3eroIB5mshtucvLq7s39Cy9Wp+ZTmwz5k/snfDMl2ClGPkIe5TtnuiYBFI4StCEk= X-Received: by 10.80.180.187 with SMTP id w56mr2064716edd.15.1505246052621; Tue, 12 Sep 2017 12:54:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.186.44 with HTTP; Tue, 12 Sep 2017 12:54:12 -0700 (PDT) In-Reply-To: References: <150522092693.4724.2532571098567577114.idtracker@ietfa.amsl.com> From: Dmitry Belyavsky Date: Tue, 12 Sep 2017 22:54:12 +0300 Message-ID: To: "Dr. Pala" Cc: LAMPS Content-Type: multipart/alternative; boundary="94eb2c0edebc4422a10559036812" Archived-At: Subject: Re: [lamps] [pkix] 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: Tue, 12 Sep 2017 19:54:16 -0000 --94eb2c0edebc4422a10559036812 Content-Type: text/plain; charset="UTF-8" Dear Max, The letter that seems the most significant for me is here: https://groups.google.com/d/msg/mozilla.dev.security.policy/--aa6dYHhrc/xbozEdS2BgAJ This letter enumerates the lion's share of limitations currently applied by Mozilla, if I am correct. On Tue, Sep 12, 2017 at 6:16 PM, Dr. Pala wrote: > Hi Dmitry, > > could you please summarize the discussion that happened in the > mozilla-dev-security? > > Cheers, > Max > > On 9/12/17 6:59 AM, Dmitry Belyavsky wrote: > > Hello, > > Here is the new version of the draft updated according to the discussion > on mozilla-dev-security list. > > ---------- Forwarded message ---------- > From: > Date: Tue, Sep 12, 2017 at 3:55 PM > Subject: New Version Notification for draft-belyavskiy-certificate-l > imitation-policy-04.txt > To: Dmitry Belyavskiy > > > > A new version of I-D, draft-belyavskiy-certificate-l > imitation-policy-04.txt > has been successfully submitted by Dmitry Belyavskiy and posted to the > IETF repository. > > Name: draft-belyavskiy-certificate-limitation-policy > Revision: 04 > Title: Certificate Limitation Policy > Document date: 2017-09-11 > Group: Individual Submission > Pages: 7 > URL: https://www.ietf.org/internet- > drafts/draft-belyavskiy-certificate-limitation-policy-04.txt > Status: https://datatracker.ietf.org/ > doc/draft-belyavskiy-certificate-limitation-policy/ > Htmlized: https://tools.ietf.org/html/d > raft-belyavskiy-certificate-limitation-policy-04 > Htmlized: https://datatracker.ietf.org/ > doc/html/draft-belyavskiy-certificate-limitation-policy-04 > Diff: https://www.ietf.org/rfcdiff? > url2=draft-belyavskiy-certificate-limitation-policy-04 > > Abstract: > The document provides a specification of the application-level trust > model. Being provided at the application level, the limitations of > trust can be distributed separately using cryptographically protected > format instead of hardcoding the checks into the application itself. > > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > > > -- > SY, Dmitry Belyavsky > > > _______________________________________________ > Spasm mailing listSpasm@ietf.orghttps://www.ietf.org/mailman/listinfo/spasm > > > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm > > -- SY, Dmitry Belyavsky --94eb2c0edebc4422a10559036812 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Max,

The letter that seems the mos= t significant for me is here:

This letter enumerates the lion's share o= f limitations currently applied by Mozilla, if I am correct.

On Tue, Sep 12, 2017= at 6:16 PM, Dr. Pala <madwolf@openca.org> wrote:
=20 =20 =20

Hi Dmitry,

could you please summarize the discussion that happened in the mozilla-dev-security?

Cheers,
Max


On 9/12/17 6:59 AM,= Dmitry Belyavsky wrote:
Hello,

Here is the new version of the draft updated according to the discussion on mozilla-dev-security list.

---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Tue, Sep 12, 2017 at 3:55 PM
Subject: New Version Notification for draft-belyavskiy-certificate-limitation-policy-04.txt
To: Dmitry Belyavskiy <beldmit@gmail.com>



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

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-belyavskiy-= certificate-limitation-policy
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A004
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Certificate Limitation= Policy
Document date:=C2=A0 2017-09-11
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission<= br> Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 7
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/intern= et-drafts/draft-belyavskiy-certificate-limitation-policy-04.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/dra= ft-belyavskiy-certificate-limitation-policy/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-belyavskiy-= certificate-limitation-policy-04
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/ht= ml/draft-belyavskiy-certificate-limitation-policy-04
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-belyavskiy-certificate-limitation-policy-04

Abstract:
=C2=A0 =C2=A0The document provides a specification of the application-level trust
=C2=A0 =C2=A0model.=C2=A0 Being provided at the application lev= el, the limitations of
=C2=A0 =C2=A0trust can be distributed separately using cryptographically protected
=C2=A0 =C2=A0format instead of hardcoding the checks into the application itself.




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

The IETF Secretariat




--
SY, Dmitry Belyavsky


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


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




--
SY, Dmitry Belyav= sky
--94eb2c0edebc4422a10559036812-- From nobody Tue Sep 12 17:24:02 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 306A213318A for ; Tue, 12 Sep 2017 17:24:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eff.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v6W3nq4G0L7f for ; Tue, 12 Sep 2017 17:23:58 -0700 (PDT) Received: from mail2.eff.org (mail2.eff.org [173.239.79.204]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15EDC132707 for ; Tue, 12 Sep 2017 17:23:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date:Message-ID:Subject:From:To; bh=f7zKrZe4+aqd3YdNC+euMhQuJsJnrAydsJAE2uK4Sfc=; b=jrS5qrNFWDWttA2OlDlzPvUyil5ZvON7g8w0kO+UYMWXSVzWX0dCzbQywbrERVFNdOUTkPum3vS0L95pbEIDrh5ty3HxwvRgpT+3if6Qu9jO2YX2eHOhUjWvQlGDQEUsXX6c8VCqFcDtxTpV0rvtznHpsI03G6w2QwjqHUZnd94=; Received: ; Tue, 12 Sep 2017 17:23:55 -0700 To: SPASM From: Jacob Hoffman-Andrews Message-ID: <02d4e149-b777-5b5c-1cd0-a2c2aae49311@eff.org> Date: Tue, 12 Sep 2017 17:23:51 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [lamps] CAA Simplification draft 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, 13 Sep 2017 00:24:00 -0000 Hi all, This is a revision to RFC6844 as discussed previously on the list and at IETF 99. In particular, RFC6844 specifies that CAs should implement "tree climbing" not only on the original FQDN, but also on any intermediate CNAMEs discovered during primary lookup. As discussed on-list, this disallows certain deployment scenarios, and can produce surprising results in common CNAME-based hosting scenarios. Additionally, because RFC6844 re-specified parts of CNAME lookup, some details were ambiguous. This draft updates RFC6844 to eliminate tree climbing on CNAME targets, and to reference RFC 1034 for the standard DNS lookup algorithm, including CNAME resolution. Because all of this draft is the same as RFC6884 except for the "Certification Authority Processing" section, I've retained the original two authors and added my own name. Please let me know if IETF etiquette indicates a different approach. I'd like to propose this draft for adoption by the WG. https://www.ietf.org/id/draft-hoffman-andrews-caa-simplification-00.txt Thanks, Jacob From nobody Tue Sep 12 18:29:05 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08404133205 for ; Tue, 12 Sep 2017 18:29:04 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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=letsencrypt.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 IJfQUh-UUo4e for ; Tue, 12 Sep 2017 18:29:02 -0700 (PDT) Received: from mail-pf0-x22b.google.com (mail-pf0-x22b.google.com [IPv6:2607:f8b0:400e:c00::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5109132F2E for ; Tue, 12 Sep 2017 18:29:01 -0700 (PDT) Received: by mail-pf0-x22b.google.com with SMTP id y29so20490218pff.0 for ; Tue, 12 Sep 2017 18:29:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=letsencrypt.org; s=google; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=0ICAfzF08ZFWYaWM35e7sipoMqILtJLxgQBiBAieyKc=; b=IlFEVv+UnEm1WwP7VhYxTvP5qpiWU2c/hGbpMMprVquifhuU4R+56h44X9IzqW6xno ToChbo8vHrs2CSLzBKNN073bsvv2aEIgNEnm7bn6eSXNiPvQPrhiSlk2ZbO9+pl1sgNv rIgxhLz2GVhNlRbBOcuXrfX5KwXa3lqgsZmjA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=0ICAfzF08ZFWYaWM35e7sipoMqILtJLxgQBiBAieyKc=; b=fzrcR9OtwPvIneF7Gi1caWVVdWOcpaRZkoZADv/ENbFaQQozlD6p1YtpHpCcmsfoLi Bwy3KBE+R4F1R43v4cBAbOAoWJ1ZpcMBBg3tRIctWmy4O0yvrPWXFtfZPC2uQqb+L+gu K45hMsBgUTiezci6smkZL4jaK81TiaeDX+G91jE0/e75NCXLlsMSZDlUvawyz1e4tn5P RhvUA3NPxOTkAdxMvILeb0NQanCI4LpQgC1fZ3de53wb6pRuwNsF53nZZnD4u6HZzECp NggfIZQnyP+3wBLAXn28pMVrfGg6+5WtVNH4wcOvvLhK6Ro+T3v9rEM0MH8gM8ByUfZU nuyA== X-Gm-Message-State: AHPjjUgauMaox5Zk+btKWZ7AwN2HjD0trtmoGNXDY3gAvyz899HkBx0C hgpC67sCBZpCWi7oQ/L0WQ== X-Google-Smtp-Source: ADKCNb7J9rRIEWBxMb2v74pPkBp88bFOdASOTCtUIayBVZVkG2+YyIT9g5JtcJSESC8qjVrQN48DAA== X-Received: by 10.98.86.73 with SMTP id k70mr16278368pfb.345.1505266141156; Tue, 12 Sep 2017 18:29:01 -0700 (PDT) Received: from [192.168.42.99] ([50.1.57.72]) by smtp.gmail.com with ESMTPSA id v31sm20114386pgn.43.2017.09.12.18.29.00 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 Sep 2017 18:29:00 -0700 (PDT) To: spasm@ietf.org References: <02d4e149-b777-5b5c-1cd0-a2c2aae49311@eff.org> From: Roland Bracewell Shoemaker Message-ID: <91ee5ecc-9b4f-1e7c-c9eb-e7248426e63f@letsencrypt.org> Date: Tue, 12 Sep 2017 18:28:59 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <02d4e149-b777-5b5c-1cd0-a2c2aae49311@eff.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [lamps] CAA Simplification draft 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, 13 Sep 2017 01:29:04 -0000 While this removes the ambiguities with regard to CNAME and DNAME alias handling I think the definition of the algorithm is still unnecessarily hard to read. Also references to 'CNAME' should be replaced with 'aliases' since 1034 section 4.3.2 as updated by 6672 also handles DNAMEs (although to be honest I think any references to specific 1034 4.3.2 behavior can just be removed since they are incorporated simply by referencing that algorithm). I'd suggest that Section 4 paragraphs 3-9 be replaced with the following cleaned up definition using pseudocode and a better explanation of the steps the algorithm uses in the example: https://github.com/jsha/caa-simplification/compare/master...rolandshoemaker:alg-cleanup?expand=1 I'd also recommend this RFC be paired down to only section 4 since that is all that is being changed and make it a 'Updates' instead of 'Obsoletes' style RFC that just redefines the lookup algorithm. Thanks for doing the work on this! I think taking this approach, of simplifying the algorithm definition, is better as completely re-designing the algorithm and using a different record style, especially given this is what CABF has already adopted, without a well defined reason is just asking for more problems down the line. On 09/12/2017 05:23 PM, Jacob Hoffman-Andrews wrote: > Hi all, > > This is a revision to RFC6844 as discussed previously on the list and at > IETF 99. In particular, RFC6844 specifies that CAs should implement > "tree climbing" not only on the original FQDN, but also on any > intermediate CNAMEs discovered during primary lookup. As discussed > on-list, this disallows certain deployment scenarios, and can produce > surprising results in common CNAME-based hosting scenarios. > > Additionally, because RFC6844 re-specified parts of CNAME lookup, some > details were ambiguous. This draft updates RFC6844 to eliminate tree > climbing on CNAME targets, and to reference RFC 1034 for the standard > DNS lookup algorithm, including CNAME resolution. > > Because all of this draft is the same as RFC6884 except for the > "Certification Authority Processing" section, I've retained the original > two authors and added my own name. Please let me know if IETF etiquette > indicates a different approach. > > I'd like to propose this draft for adoption by the WG. > > https://www.ietf.org/id/draft-hoffman-andrews-caa-simplification-00.txt > > Thanks, > Jacob > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm > From nobody Tue Sep 12 22:28: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 0E6F0132031 for ; Tue, 12 Sep 2017 22:28:34 -0700 (PDT) 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 xJk6-E3ZwB6D for ; Tue, 12 Sep 2017 22:28:32 -0700 (PDT) Received: from mail2.eff.org (mail2.eff.org [173.239.79.204]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADFB1133077 for ; Tue, 12 Sep 2017 22:28:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject; bh=KHfxPg0AxO5uFxQeFbad4sV3d+N/hBGAv6ih53e2z2k=; b=ywimDOtWwJ/JZZUrv24+LiayWEWgK8FyvPb0NkfLeG3pQt+bQ8JyDVJgVOvJHOrEGnqSUFIfgG8DJt3hUp4YGzQkZdD2tq1NEVwZyQF+EEJ5aD5ne7jdVGzNBS59JAxz0QzZAjj4Wt/RJIB2c5efjZU081qDUxex6APdDEN14wk=; Received: ; Tue, 12 Sep 2017 22:28:29 -0700 To: Roland Bracewell Shoemaker , spasm@ietf.org References: <02d4e149-b777-5b5c-1cd0-a2c2aae49311@eff.org> <91ee5ecc-9b4f-1e7c-c9eb-e7248426e63f@letsencrypt.org> From: Jacob Hoffman-Andrews Message-ID: <08389c8a-b9f4-c950-4c3a-2df118a1c638@eff.org> Date: Tue, 12 Sep 2017 22:28:30 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <91ee5ecc-9b4f-1e7c-c9eb-e7248426e63f@letsencrypt.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US Received-SPF: skipped for local relay Archived-At: Subject: Re: [lamps] CAA Simplification draft 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, 13 Sep 2017 05:28:34 -0000 Thanks Roland! I've incorporated this feedback into a new draft: https://www.ietf.org/id/draft-hoffman-andrews-caa-simplification-01.txt. If anyone else would like to propose edits or make PRs, I have a copy available on GitHub: https://github.com/jsha/caa-simplification. On 09/12/2017 06:28 PM, Roland Bracewell Shoemaker wrote: > While this removes the ambiguities with regard to CNAME and DNAME alias > handling I think the definition of the algorithm is still unnecessarily > hard to read. Also references to 'CNAME' should be replaced with > 'aliases' since 1034 section 4.3.2 as updated by 6672 also handles > DNAMEs (although to be honest I think any references to specific 1034 > 4.3.2 behavior can just be removed since they are incorporated simply by > referencing that algorithm). > > I'd suggest that Section 4 paragraphs 3-9 be replaced with the following > cleaned up definition using pseudocode and a better explanation of the > steps the algorithm uses in the example: > > https://github.com/jsha/caa-simplification/compare/master...rolandshoemaker:alg-cleanup?expand=1 > > I'd also recommend this RFC be paired down to only section 4 since that > is all that is being changed and make it a 'Updates' instead of > 'Obsoletes' style RFC that just redefines the lookup algorithm. > > Thanks for doing the work on this! I think taking this approach, of > simplifying the algorithm definition, is better as completely > re-designing the algorithm and using a different record style, > especially given this is what CABF has already adopted, without a well > defined reason is just asking for more problems down the line. > > On 09/12/2017 05:23 PM, Jacob Hoffman-Andrews wrote: >> Hi all, >> >> This is a revision to RFC6844 as discussed previously on the list and at >> IETF 99. In particular, RFC6844 specifies that CAs should implement >> "tree climbing" not only on the original FQDN, but also on any >> intermediate CNAMEs discovered during primary lookup. As discussed >> on-list, this disallows certain deployment scenarios, and can produce >> surprising results in common CNAME-based hosting scenarios. >> >> Additionally, because RFC6844 re-specified parts of CNAME lookup, some >> details were ambiguous. This draft updates RFC6844 to eliminate tree >> climbing on CNAME targets, and to reference RFC 1034 for the standard >> DNS lookup algorithm, including CNAME resolution. >> >> Because all of this draft is the same as RFC6884 except for the >> "Certification Authority Processing" section, I've retained the original >> two authors and added my own name. Please let me know if IETF etiquette >> indicates a different approach. >> >> I'd like to propose this draft for adoption by the WG. >> >> https://www.ietf.org/id/draft-hoffman-andrews-caa-simplification-00.txt >> >> Thanks, >> Jacob >> >> _______________________________________________ >> Spasm mailing list >> Spasm@ietf.org >> https://www.ietf.org/mailman/listinfo/spasm >> > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm > From nobody Tue Sep 12 22:56:18 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 E6F23132026 for ; Tue, 12 Sep 2017 22:56:16 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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=letsencrypt.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 a9P6BfszWSNC for ; Tue, 12 Sep 2017 22:56:14 -0700 (PDT) Received: from mail-pf0-x231.google.com (mail-pf0-x231.google.com [IPv6:2607:f8b0:400e:c00::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 635AB1321D8 for ; Tue, 12 Sep 2017 22:56:14 -0700 (PDT) Received: by mail-pf0-x231.google.com with SMTP id e199so22039438pfh.3 for ; Tue, 12 Sep 2017 22:56:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=letsencrypt.org; s=google; h=subject:from:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=FxMhnmx2Zar5BQkEkzU+Z31ksQGCqliWKKHLg/PGnS0=; b=BzOLh9Z0o2PYaIMLWmJfNVMZFlzRIdKAGpIU5ICdxMY6AfVq0CE0kXT0L+badd4C/l ty2qSJ2+XWgVpuE12z+7g8+K2AMiMetLPsKbSn4fYmuc/54sm0/EqXhB60xng9pzvNDq 5FTsaHZrVtPazj+hYen5sgKF0219zs0VhMXec= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=FxMhnmx2Zar5BQkEkzU+Z31ksQGCqliWKKHLg/PGnS0=; b=NIihEb3epYq0Ph+PDk+m4tEGgP+efVoNDvKwddUF9hFJG3uOvAkdtFWwxM2O9oc+Kc YuixUYCMLYyUt8mPsObXbmzpTdSEyDimZWprzhTEmWlpVTaeTH7TADR434SC2tGD5G1p T0xw1yNoo+IBO4htADiJUMdJaRawFKuO7p8M4zYAkydcPekI6K7Hi+9ucJrFPLHLgWG/ 2cq3FiWXbeTyVfZoZf3ruF7oR+Vq56eah4Vs4XMhWNh22KC3gM0sanHzl4ig5Gaeoqbz MqHRcAeYwcBm6/3NwLHAK2W7ggi2h0X0qXDL5LnPkIUI+vZRt+vpLwPvYybtWuJRATzh h/aw== X-Gm-Message-State: AHPjjUiXAKuDiwanxPQ1i4wCIHL60HtfPPYeanChwg+Zi7mHc83ID9N5 ejUEtZC4dKexUkZzt/KlLw== X-Google-Smtp-Source: ADKCNb64wOOqATqKmezSd+sgiGjAaEYX7gt0+oZCp8C7+6DUESEWSaUb/oU5j4tQygDSOoz9X7WwWg== X-Received: by 10.98.15.208 with SMTP id 77mr17135032pfp.318.1505282173601; Tue, 12 Sep 2017 22:56:13 -0700 (PDT) Received: from [192.168.42.99] ([50.1.57.72]) by smtp.gmail.com with ESMTPSA id x9sm23938762pfk.40.2017.09.12.22.56.12 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 Sep 2017 22:56:12 -0700 (PDT) From: Roland Bracewell Shoemaker To: spasm@ietf.org References: <02d4e149-b777-5b5c-1cd0-a2c2aae49311@eff.org> <91ee5ecc-9b4f-1e7c-c9eb-e7248426e63f@letsencrypt.org> Message-ID: <54f6a03b-17cd-de4f-de3c-5a3cf8c14afa@letsencrypt.org> Date: Tue, 12 Sep 2017 22:56:11 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <91ee5ecc-9b4f-1e7c-c9eb-e7248426e63f@letsencrypt.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [lamps] CAA Simplification draft 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, 13 Sep 2017 05:56:17 -0000 On 09/12/2017 06:28 PM, Roland Bracewell Shoemaker wrote: > While this removes the ambiguities with regard to CNAME and DNAME alias > handling I think the definition of the algorithm is still unnecessarily > hard to read. Also references to 'CNAME' should be replaced with > 'aliases' since 1034 section 4.3.2 as updated by 6672 also handles > DNAMEs (although to be honest I think any references to specific 1034 > 4.3.2 behavior can just be removed since they are incorporated simply by > referencing that algorithm). > > I'd suggest that Section 4 paragraphs 3-9 be replaced with the following > cleaned up definition using pseudocode and a better explanation of the > steps the algorithm uses in the example: > > https://github.com/jsha/caa-simplification/compare/master...rolandshoemaker:alg-cleanup?expand=1 > > I'd also recommend this RFC be paired down to only section 4 since that > is all that is being changed and make it a 'Updates' instead of > 'Obsoletes' style RFC that just redefines the lookup algorithm. I'll actually retract this after reading through RFC 2223 and 7322, since this is a breaking change from the algorithm in 6844 this should probably be a 'Obsoletes' and therefore contain all of the existing content that isn't being changed. > > Thanks for doing the work on this! I think taking this approach, of > simplifying the algorithm definition, is better as completely > re-designing the algorithm and using a different record style, > especially given this is what CABF has already adopted, without a well > defined reason is just asking for more problems down the line. > > On 09/12/2017 05:23 PM, Jacob Hoffman-Andrews wrote: >> Hi all, >> >> This is a revision to RFC6844 as discussed previously on the list and at >> IETF 99. In particular, RFC6844 specifies that CAs should implement >> "tree climbing" not only on the original FQDN, but also on any >> intermediate CNAMEs discovered during primary lookup. As discussed >> on-list, this disallows certain deployment scenarios, and can produce >> surprising results in common CNAME-based hosting scenarios. >> >> Additionally, because RFC6844 re-specified parts of CNAME lookup, some >> details were ambiguous. This draft updates RFC6844 to eliminate tree >> climbing on CNAME targets, and to reference RFC 1034 for the standard >> DNS lookup algorithm, including CNAME resolution. >> >> Because all of this draft is the same as RFC6884 except for the >> "Certification Authority Processing" section, I've retained the original >> two authors and added my own name. Please let me know if IETF etiquette >> indicates a different approach. >> >> I'd like to propose this draft for adoption by the WG. >> >> https://www.ietf.org/id/draft-hoffman-andrews-caa-simplification-00.txt >> >> Thanks, >> Jacob >> >> _______________________________________________ >> Spasm mailing list >> Spasm@ietf.org >> https://www.ietf.org/mailman/listinfo/spasm >> From nobody Tue Sep 12 23:40:19 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 D419F133077; Tue, 12 Sep 2017 23:40:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, 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 hBDY8916-zKd; Tue, 12 Sep 2017 23:40:03 -0700 (PDT) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF5A11321A2; Tue, 12 Sep 2017 23:40:02 -0700 (PDT) Received: by mail-qk0-x234.google.com with SMTP id j5so436746qkd.0; Tue, 12 Sep 2017 23:40:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=vmuhzgs6kGH2SyWUAWp1fH4uDVExcR8PV10GSAitkBA=; b=hEcNF2ljPvaE2LH0bR0nHVDYgdAJdkAwrg9xELatxGhio/tPuu9TpKDpxNxAFHgiOs u1Bcbf7ML4Pkee0RyFoLTFWKXBnbEQXNHPr2CQjar015WYyrA0FWadGQGnJbd26VGOa6 8lQtnidV6oDSG+wzM6730PHSfbvQBCod+nhNg0LEz57S/5wcJ/32gPM/b4BAzVLcsj49 cKvQGxLrS/hQA3Ge+p5pLTHgqBOeFrwGpWi6ohEqmm/RRwXdTsXy4l99HEx1kj+nmBzp BNpfvxP+YRRQCF9ugP77E/+OJYE0i8iBDGDcEeSyz7mxSu3dTRs0acDyVI0BxRBtRbEk Zp8w== 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=vmuhzgs6kGH2SyWUAWp1fH4uDVExcR8PV10GSAitkBA=; b=IS698P0Zuq43foVotrbueWfFTlNv3FYTsVBF42ZN4m7CkTQccQdpIA5k/PiQWeoz6b ho6ddjcOkKHmwdKm+RIsxR9d1MM9gKoXnYH4sZD14L+rdq2MW6WS7gNpz+XKCidW6fmI 9Aj0XyYYUa9S6yM3vX+tDlc0hj6ZAqP6Pzj/tRjW1LvSDSOzBL7lIGJH7LL+iFEVU3sj Zxy05XPuH+48AOO+Yl7QEI0vDP6a2OfCq/uqgLrupZ2XH7AHc4pTNlT3AVf6NtslfwbR u9Z9n+tgq5jnE2efOzC6rIF80yoQmqMpTGAiPMFfB3UXrJynO5F3/Qugnw9I66IKQ24U qoiQ== X-Gm-Message-State: AHPjjUjj0iYljAohQAVnBOGTTDDO1z51plr1W8DJOcs2J5gr1qg3tEAJ sQyfd0DF2zedc0jKKthC0Vy8ueI4dGzNSzi6Kx68tDFH X-Google-Smtp-Source: AOwi7QCbGWPjaFGNCtozIjRcuIi3D3N/nMHO0wWFI+mTbm8bjx5zZJl0FWaWOMjWhgAXuEjReYYx6bF4nWm+Gsrrz+Y= X-Received: by 10.55.181.129 with SMTP id e123mr24767138qkf.128.1505284801569; Tue, 12 Sep 2017 23:40:01 -0700 (PDT) MIME-Version: 1.0 Sender: n.mavrogiannopoulos@gmail.com Received: by 10.12.175.136 with HTTP; Tue, 12 Sep 2017 23:39:21 -0700 (PDT) In-Reply-To: References: <150522092693.4724.2532571098567577114.idtracker@ietfa.amsl.com> From: Nikos Mavrogiannopoulos Date: Wed, 13 Sep 2017 08:39:21 +0200 X-Google-Sender-Auth: zTfCaHN7zsUhKnKDKgjEoQ4OiQE Message-ID: To: Dmitry Belyavsky Cc: "saag@ietf.org" , LAMPS , dev-security-policy@lists.mozilla.org, pkix@ietf.org Content-Type: text/plain; charset="UTF-8" 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: Wed, 13 Sep 2017 06:40:05 -0000 On Tue, Sep 12, 2017 at 2:59 PM, Dmitry Belyavsky wrote: > Hello, > > Here is the new version of the draft updated according to the discussion on > mozilla-dev-security list. Hi, It seems that most of the details of the underlying format are missing. As far as I understand it is mostly an intentions document at this point right? I have few comments: 1. requiredX509extensions: What's the reasoning behind this? If these extensions are required and not present why keep the root certificate in the trust store? 2. What is the difference between issuedNotAfter and trustNotAfter? The description text is unclear to me. 3. applicationNameConstraints: very useful, however it is unclear from the ASN.1 description how are these stored. 4. How do you handle extensions to this format? Overall, why not use X.509 extensions to store such additional constraints? We already (in the p11-kit trust store in Fedora/RHEL systems) use the notion of stapled extensions to limit certificates [0, 1] and seems quite a flexible approach. Have you considered that path? regards, Nikos [0]. https://p11-glue.freedesktop.org/doc/storing-trust-policy/storing-trust-model.html [1]. http://nmav.gnutls.org/2016/06/restricting-scope-of-ca-certificates.html From nobody Wed Sep 13 04:22:39 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C22B120720; Wed, 13 Sep 2017 04:22:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yYZMWCV4kSiC; Wed, 13 Sep 2017 04:22:19 -0700 (PDT) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8DC2133341; Wed, 13 Sep 2017 04:22:18 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id a137so7247058wma.0; Wed, 13 Sep 2017 04:22:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=bfjVObCiCgnNgXq38MobIKw1e0SFCac2liIqS1vO1EQ=; b=qPn40AcB0ypgZ6N15g2mIs38pQ5qUBsq1Ti3tsyKsIKMUtCYkDWdNyYH0GIr2dsZMV UqWBS96T5U7X8X84Wlk9DLDJhO8cd1sQG6Q+OIcvtoNRJjSVNCc+3mi9xp8sYG0Aw3SM EQGta+wIyrVLnsdVY8zk96QDxOAuOcxht/gTfmB+bfFLyAYSwbJ7gG7mBnHB0YkCciIT dZGIuG7VBBeoTxw3XJtjeSFg5dH0GwgtS7NlecdORF2WH87cwuR8WALjdh6Mm9g2bNbX vTDHqwBWUn2sguXy8mLRjOAFcPMTRL7v4jjTUerTzQ9xuk/VGyX6GJ86tNlzU2P1xk/V pVEA== 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=bfjVObCiCgnNgXq38MobIKw1e0SFCac2liIqS1vO1EQ=; b=amexFCdou+dc4Dyj3JJZo8dIkxgqPmxKIjpMJKmUKz+b1An4x4/BbCo/7TkWOsO39k W6c1VYifXs+z2HGGwQSOAUeNMmDof7Jtn1IXisQoY+1KyYXlm58sxrB/VE4PwyR4frUW NeXoO/F9drcd1o1SkUe2vaRxqZyF9rx3fk9Ol4/XE21w4Bw1rJSfPc34ZaEMabxsP8pg oRyCXFERniqPLQoIlwO9drYUo+bbOA4HkNy3XQ8HiNyhh8Xi3m5hDgYzIURmAYzzLY2b HszJAJZkW0zGHl7Sz6Db5oXXNHIG/m7IfgR5tr+ndGZaN7Xio0tw8jPirokwEsTypcQ+ Rr9w== X-Gm-Message-State: AHPjjUh3srZQkaxoZoTT1Y+MW+w+qEtbUUBfrz2tIrFyaUqGZzCoU1ko wrMc4yPE5yl8CgBhvePVvPoGoL8ypvqheJq5+Eg= X-Google-Smtp-Source: ADKCNb4+k0R1/F7EKBZjgrBrrqWMxalFHtiaNjd5UoRLLZhdy3TYv7IECGLZZVC3/c1NwdoOek9pZ6RuyMFvb7B/fec= X-Received: by 10.80.153.98 with SMTP id l31mr13607104edb.69.1505301737412; Wed, 13 Sep 2017 04:22:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.186.44 with HTTP; Wed, 13 Sep 2017 04:22:16 -0700 (PDT) In-Reply-To: References: <150522092693.4724.2532571098567577114.idtracker@ietfa.amsl.com> From: Dmitry Belyavsky Date: Wed, 13 Sep 2017 14:22:16 +0300 Message-ID: To: Nikos Mavrogiannopoulos Cc: "saag@ietf.org" , LAMPS , dev-security-policy@lists.mozilla.org, pkix@ietf.org Content-Type: multipart/alternative; boundary="94eb2c0de59c569dc00559105f15" 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: Wed, 13 Sep 2017 11:22:26 -0000 --94eb2c0de59c569dc00559105f15 Content-Type: text/plain; charset="UTF-8" Dear Nikos, On Wed, Sep 13, 2017 at 9:39 AM, Nikos Mavrogiannopoulos wrote: > On Tue, Sep 12, 2017 at 2:59 PM, Dmitry Belyavsky > wrote: > > Hello, > > > > Here is the new version of the draft updated according to the discussion > on > > mozilla-dev-security list. > > Hi, > It seems that most of the details of the underlying format are > missing. As far as I understand it is mostly an intentions document at > this point right? I have few comments: > The format will be CRL-like. > > 1. requiredX509extensions: What's the reasoning behind this? If these > extensions are required and not present why keep the root certificate > in the trust store? > The main intended case is "require Certificate Transparency". Currently using the CT is not mandatory for all CAs. > > 2. What is the difference between issuedNotAfter and trustNotAfter? > The description text is unclear to me. > issuedNotAfter - we do not trust to the certificates issued after the date. trustNotAfter - we do not trust certificates after the date XXX, if they have notAfter > XXX > > 3. applicationNameConstraints: very useful, however it is unclear from > the ASN.1 description how are these stored. > I'm not so familiar with ASN1 format. I think that syntax from RFC5280 will fit here. > > 4. How do you handle extensions to this format? > > Simillary to CRL. Do you have ideas of the extensions? > Overall, why not use X.509 extensions to store such additional > constraints? We already (in the p11-kit trust store in Fedora/RHEL > systems) use the notion of stapled extensions to limit certificates > [0, 1] and seems quite a flexible approach. Have you considered that > path? > > regards, > Nikos > > [0]. https://p11-glue.freedesktop.org/doc/storing-trust-policy/ > storing-trust-model.html > [1]. http://nmav.gnutls.org/2016/06/restricting-scope-of-ca- > certificates.html > Thank you very much, I'll look at it. -- SY, Dmitry Belyavsky --94eb2c0de59c569dc00559105f15 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Nikos,

On Wed, Sep 13, 2017 at 9:39 AM, Nikos Mavrogiannopoulos <nmav@gn= utls.org> wrote:
On Tue, Sep 12, 2017 at 2:59 PM, Dmitry Belyavsky <beldmit@gmail.com> wrote:
> Hello,
>
> Here is the new version of the draft updated according to the discussi= on on
> mozilla-dev-security list.

Hi,
=C2=A0It seems that most of the details of the underlying format are
missing. As far as I understand it is mostly an intentions document at
this point right? I have few comments:

= The format will be CRL-like. =C2=A0

1. requiredX509extensions: What's the reasoning behind this? If these extensions are required and not present why keep the root certificate
in the trust store?

The main intended c= ase is "require Certificate Transparency".=C2=A0
Curren= tly using the CT is not mandatory for all CAs.
=C2=A0

2. What is the difference between issuedNotAfter and trustNotAfter?
The description text is unclear to me.

= issuedNotAfter - we do not trust to the certificates issued after the date.=
trustNotAfter - we do not trust certificates after the date XXX,= if they have notAfter > XXX
=C2=A0

3. applicationNameConstraints: very useful, however it is unclear from
the ASN.1 description how are these stored.

=
I'm not so familiar with ASN1 format. I think that syntax from RFC= 5280 will fit here.=C2=A0

4. How do you handle extensions to this format?

Simillary to CRL. Do you have ideas of the extensions= ?
=C2=A0
Overall, why not use X.509 extensions to store such additional
constraints? We already (in the p11-kit trust store in Fedora/RHEL
systems) use the notion of stapled extensions to limit certificates
[0, 1] and seems quite a flexible approach. Have you considered that
path?

regards,
Nikos

[0]. https://p11-g= lue.freedesktop.org/doc/storing-trust-policy/storing-trust-model.= html
[1]. http://nmav.gnutls.org/= 2016/06/restricting-scope-of-ca-certificates.html

Thank you very much, I'll look at it.=C2=A0

--
SY, Dmitry Belyavsky
--94eb2c0de59c569dc00559105f15-- From nobody Fri Sep 15 12:43:13 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCA5D133207 for ; Fri, 15 Sep 2017 12:43:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 N50zkIrtNe8w for ; Fri, 15 Sep 2017 12:43:10 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87528133074 for ; Fri, 15 Sep 2017 12:43:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id DF812300582 for ; Fri, 15 Sep 2017 15:43:06 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id M0qtm2ed5YP0 for ; Fri, 15 Sep 2017 15:43:06 -0400 (EDT) Received: from [5.5.33.163] (vpn.snozzages.com [204.42.252.17]) by mail.smeinc.net (Postfix) with ESMTPSA id D2BD1300265 for ; Fri, 15 Sep 2017 15:43:05 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: Date: Fri, 15 Sep 2017 15:43:01 -0400 To: spasm@ietf.org X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [lamps] Starting work to CAA and SHAKE 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, 15 Sep 2017 19:43:11 -0000 I have been discussing the recharter with EKR, and he agrees that we = should get started on this work even though the LAMPS re-charter is = blocked on a bit of process. Having completed the S/MIME 4.0 specifications and updates to support = i18n email addresses in PKIX certificates, the LAMPS WG is now ready to = work on two additional topics: 1. Specify a discovery mechanism for CAA records to replace the one = described in RFC 6844. 2. Specify the use of SHAKE128/256 and SHAKE256/512 for PKIX and S/MIME. Other topics can be considered when these two are progressing. CAA RFC 6844 describes the mechanism by which CAA records relating to a = domain are discovered. Implementation experience has demonstrated an = ambiguity in the current processing of CNAME and DNAME records during = discovery. Subsequent discussion has suggested that a different = discovery approach would resolve limitations inherent in the current = approach. We have seen at least two individual drafts on this topic. I = would like to have the WG adopt a rfc6844bis as a starting point. SHAKE Unlike the previous hashing standards, the SHA-3 functions are the = outcome of an open competition. They have a clear design rationale and = have received a lot of public analysis, resulting in great confidence = that the SHA-3 family of functions are very secure. Also, since the = design of the SHA-3 functions use a very different construction from the = SHA-2 functions, they offer an excellent alternative to the SHA-2 family of functions. In particular, SHAKE128/256 and SHAKE256/512 offer = security and performance benefits. We have not seen any individual = drafts on this yet. It seems to me that one draft is needed for PKIX = and another draft is needed for CMS and S/MIME. Is anyone willing to = work on them? Russ= From nobody Sat Sep 16 05:57:22 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD698132D42 for ; Sat, 16 Sep 2017 05:57:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9xBFTwWNaj7Q for ; Sat, 16 Sep 2017 05:57:19 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A261D132981 for ; Sat, 16 Sep 2017 05:57:19 -0700 (PDT) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v8GCvEA9021730; Sat, 16 Sep 2017 13:57:17 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=lap90pvYmf/rpJOCgY5GdlzlkBnZbGQZdYYxdJ4LYBQ=; b=TR+udxu9TDNweMRx+RQlj9niPxSH2oYS0tBZ4VQB3dN10H+5gYQbuvUUnRCo4V8YZIBe IyhTu9rijEuH2tlMAV42h52Q5WPbAGkmK4eH/vin5tVg1rIWBw3Di1G345SKv1sRMncq sNK6rwpZZr1dSZ5EnKoAsqgnrBllQJMm412GTjCgj0sh/KJLbNVu+mPIKmzKft9GMRsw /s7Il587AotoZXVzbJV0m4DgxHQPSZITyGnkITceY84+v9SQorm6QLoYRbiSYrX8fFIe Y/isiUf+7UZfBkM7xgDVCZrtq3oY4F0P7cG6FDn9loWZVO6N3UDOJrGMcFNc82FpXPVv 4Q== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by m0050093.ppops.net-00190b01. with ESMTP id 2d0u7kmmdh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 16 Sep 2017 13:57:17 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.21/8.16.0.21) with SMTP id v8GCtZu8003270; Sat, 16 Sep 2017 08:57:16 -0400 Received: from email.msg.corp.akamai.com ([172.27.25.32]) by prod-mail-ppoint2.akamai.com with ESMTP id 2d0y9tgmxs-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sat, 16 Sep 2017 08:57:16 -0400 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb1.msg.corp.akamai.com (172.27.27.101) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sat, 16 Sep 2017 07:57:14 -0500 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.6.131]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.6.131]) with mapi id 15.00.1263.000; Sat, 16 Sep 2017 07:57:14 -0500 From: "Salz, Rich" To: Russ Housley , "spasm@ietf.org" Thread-Topic: [lamps] Starting work to CAA and SHAKE Thread-Index: AQHTLlrpDPNZR/Fq8kCMJIlIzYP+6qK3irAA Date: Sat, 16 Sep 2017 12:57:14 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.21.0.170409 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.47.151] Content-Type: text/plain; charset="utf-8" Content-ID: <7DF3D3F511A8334DBB90C280ECE1F892@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-09-16_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1709160194 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-09-16_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1709160195 Archived-At: Subject: Re: [lamps] Starting work to CAA and SHAKE X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Sep 2017 12:57:21 -0000 VGhhdCBsb29rcyBmaW5lIHRvIG1lLiAgV2hlcmUgeW91IGFza2luZyB0aGUgV0cgZm9yIGlucHV0 IG9yIHNvbWV0aGluZz8NCg0K From nobody Sat Sep 16 12:40:33 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 0AB84132397 for ; Sat, 16 Sep 2017 12:40:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.891 X-Spam-Level: X-Spam-Status: No, score=-1.891 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_HK_NAME_DR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R7O5NXfgvTFq for ; Sat, 16 Sep 2017 12:40:30 -0700 (PDT) Received: from mail.katezarealty.com (mail.katezarealty.com [104.168.158.213]) by ietfa.amsl.com (Postfix) with ESMTP id 6AAA412EC30 for ; Sat, 16 Sep 2017 12:40:30 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mail.katezarealty.com (Postfix) with ESMTP id 1EDC63740E3A for ; Sat, 16 Sep 2017 19:40:30 +0000 (UTC) X-Virus-Scanned: amavisd-new at katezarealty.com Received: from mail.katezarealty.com ([127.0.0.1]) by localhost (mail.katezarealty.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Ihk3S2-G5ONN for ; Sat, 16 Sep 2017 15:40:29 -0400 (EDT) Received: from Maxs-MBP.hsd1.co.comcast.net (c-24-8-35-103.hsd1.co.comcast.net [24.8.35.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.katezarealty.com (Postfix) with ESMTPSA id 4730F3740CA2 for ; Sat, 16 Sep 2017 15:40:29 -0400 (EDT) To: spasm@ietf.org References: From: "Dr. Pala" Message-ID: Date: Sat, 16 Sep 2017 13:40:28 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [lamps] Starting work to CAA and SHAKE X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Sep 2017 19:40:32 -0000 Hi Russ, all, does this mean that the other two items that were proposed will not be worked on until the two items listed here? Have you considered also the other proposals for the charter that were sent sometime ago? I was under the impression that there was interest in both items... Cheers, Max On 9/15/17 1:43 PM, Russ Housley wrote: > I have been discussing the recharter with EKR, and he agrees that we should get started on this work even though the LAMPS re-charter is blocked on a bit of process. > > Having completed the S/MIME 4.0 specifications and updates to support i18n email addresses in PKIX certificates, the LAMPS WG is now ready to work on two additional topics: > > 1. Specify a discovery mechanism for CAA records to replace the one described in RFC 6844. > > 2. Specify the use of SHAKE128/256 and SHAKE256/512 for PKIX and S/MIME. > > Other topics can be considered when these two are progressing. > > > CAA > > RFC 6844 describes the mechanism by which CAA records relating to a domain are discovered. Implementation experience has demonstrated an ambiguity in the current processing of CNAME and DNAME records during discovery. Subsequent discussion has suggested that a different discovery approach would resolve limitations inherent in the current approach. We have seen at least two individual drafts on this topic. I would like to have the WG adopt a rfc6844bis as a starting point. > > > SHAKE > > Unlike the previous hashing standards, the SHA-3 functions are the outcome of an open competition. They have a clear design rationale and have received a lot of public analysis, resulting in great confidence that the SHA-3 family of functions are very secure. Also, since the design of the SHA-3 functions use a very different construction from the SHA-2 functions, they offer an excellent alternative to the SHA-2 family > of functions. In particular, SHAKE128/256 and SHAKE256/512 offer security and performance benefits. We have not seen any individual drafts on this yet. It seems to me that one draft is needed for PKIX and another draft is needed for CMS and S/MIME. Is anyone willing to work on them? > > Russ > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm From nobody Sun Sep 17 09:08:58 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54AE413307F for ; Sun, 17 Sep 2017 09:08:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vEJPtNE4MAOQ for ; Sun, 17 Sep 2017 09:08:55 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11BF7133079 for ; Sun, 17 Sep 2017 09:08:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 5804030057F for ; Sun, 17 Sep 2017 12:08:54 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id PYSBwT47IhGf for ; Sun, 17 Sep 2017 12:08:53 -0400 (EDT) Received: from [5.5.33.186] (vpn.snozzages.com [204.42.252.17]) by mail.smeinc.net (Postfix) with ESMTPSA id 43037300277; Sun, 17 Sep 2017 12:08:53 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Russ Housley In-Reply-To: Date: Sun, 17 Sep 2017 12:08:52 -0400 Cc: spasm@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Dr. Pala" X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [lamps] Starting work to CAA and SHAKE 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, 17 Sep 2017 16:08:56 -0000 Max: As I said:=20 >> Other topics can be considered when these two are progressing. There was clear interest in this two, but it is not clear that the = others have the same level of interest. When we work on the charter = text, people will have an opportunity to advocate for others topics to = be included. Russ From nobody Sun Sep 17 09:17: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 912E3133079 for ; Sun, 17 Sep 2017 09:17:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3gsk5WUJbzIq for ; Sun, 17 Sep 2017 09:17:04 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CB26133073 for ; Sun, 17 Sep 2017 09:17:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 950E930057F for ; Sun, 17 Sep 2017 12:17:03 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id NYLCPa31f2RC for ; Sun, 17 Sep 2017 12:16:58 -0400 (EDT) Received: from [5.5.33.186] (vpn.snozzages.com [204.42.252.17]) by mail.smeinc.net (Postfix) with ESMTPSA id D1F22300277; Sun, 17 Sep 2017 12:16:57 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Russ Housley In-Reply-To: Date: Sun, 17 Sep 2017 12:16:56 -0400 Cc: "spasm@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <80086CAE-8B03-4E3B-8715-07DDD1B00A0D@vigilsec.com> References: To: Rich Salz X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [lamps] Starting work to CAA and SHAKE 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, 17 Sep 2017 16:17:08 -0000 > That looks fine to me. Where you asking the WG for input or = something? We have two documents on CAA: - https://www.rfc-editor.org/errata/eid5065 - = https://www.ietf.org/id/draft-hoffman-andrews-caa-simplification-01.txt How does the mail list want to proceed? My note got one person to raise their hand to work on the SHAKE = document. Once that is posted as an individual draft, we can see if the = mail list wants to adopt it. Russ From nobody Sun Sep 17 11:17:14 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8007C1332D7 for ; Sun, 17 Sep 2017 11:17:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p_0D-W1AsQGJ for ; Sun, 17 Sep 2017 11:17:08 -0700 (PDT) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B74121330AE for ; Sun, 17 Sep 2017 11:17:08 -0700 (PDT) Received: by mail-io0-x22c.google.com with SMTP id v36so14244891ioi.1 for ; Sun, 17 Sep 2017 11:17:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=1BGNoEzRqKyL8X+TpeBthuk4DEbDIuiojGj7MRpxCPs=; b=YRo8QJ/UwEsWkW/ei6udHdKfH/6DYkJubSKRJCppk4rxR4H2dgiVK3IytXNo/QrIjA I1hdX1u5ITVw39jFreQxzKUMAv9jr4algqeFI5DKTfWwe48H4XpaqvxX9ZSfgqioHP9X 7Q/dU1iUaMj8A9+xLzRQ7ZIrj/h+7jfE+9yfGp91y7w7A8pMi0MN+qaMmlGNrbWJod9U WTckUV7TL6CXyZReEg6x8ng8PoorSVOPXE2oddvPemOPiCenmBT6yuzJRIPQXexPyDMJ IJ0YMbodqpwFH0gk2aw3tqddc14qpwvi456upvDE0Un8Dbzte/Rq0n4zjU2c+3O79DI8 GYEw== 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=1BGNoEzRqKyL8X+TpeBthuk4DEbDIuiojGj7MRpxCPs=; b=GzUwK4W12IkN/8wVL23NEpTg5O7QdIrigtIF4/IXesQmAtDgK5v7vGemhT9jQN2sjH Flp/iZz2uHf9pPfNFL8CkUVB4nlGeP1pbIbtxKpFkkOdzDHg8x6DhXGnyk8Veu4SZ76U /aAB5XH5mqkzfsPt7q/dAOAaQrN6IGwLL+Pg2uLFzlqdrD+MOaiioYQpm2kA5Wv5xm9b SQ25YAlef2wJIy2xluJuiB9ZISLjglY9eNUF7RkamY0wyErwWj6oekQfiupXoDYdRarb 6bGGyjSX1tnoT7deMvjIQ5NBnwh/nwil2NUHP2uQGWcXKKqBZ1AcFnz5TicTkMbzejZ8 K72w== X-Gm-Message-State: AHPjjUiF8kQQpuCQtiavd0LBpbY6OS8H2o1dbe9URQNhpbv8IVrY0N+0 Tg4gFitkZmBPLOHoQJQXL0yhMSaewFXeBJ0IubY= X-Google-Smtp-Source: AOwi7QCGAOw8H3+S6C4SzbMLMEwXGDBgUO9Wt9/XhULuMZfs93ALp9ZTYZxb/5O/gwjT6xT5Z0ynm6HezTgIn+ULzRY= X-Received: by 10.202.220.133 with SMTP id t127mr17883309oig.130.1505672227850; Sun, 17 Sep 2017 11:17:07 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.157.46.177 with HTTP; Sun, 17 Sep 2017 11:17:07 -0700 (PDT) In-Reply-To: <80086CAE-8B03-4E3B-8715-07DDD1B00A0D@vigilsec.com> References: <80086CAE-8B03-4E3B-8715-07DDD1B00A0D@vigilsec.com> From: Phillip Hallam-Baker Date: Sun, 17 Sep 2017 14:17:07 -0400 X-Google-Sender-Auth: QcDmD4UofCGdujPi3NoIcRay_o8 Message-ID: To: Russ Housley Cc: Rich Salz , "spasm@ietf.org" Content-Type: multipart/alternative; boundary="001a113d59764a11bd055966a2c7" Archived-At: Subject: Re: [lamps] Starting work to CAA and SHAKE 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, 17 Sep 2017 18:17:13 -0000 --001a113d59764a11bd055966a2c7 Content-Type: text/plain; charset="UTF-8" I am willing to edit the CAA document. I think the main thing there is to decide what we actually want to do with the DNS discovery scheme. So the first thing is to capture the issues from deployment last week. On Sun, Sep 17, 2017 at 12:16 PM, Russ Housley wrote: > > > That looks fine to me. Where you asking the WG for input or something? > > We have two documents on CAA: > - https://www.rfc-editor.org/errata/eid5065 > - https://www.ietf.org/id/draft-hoffman-andrews-caa- > simplification-01.txt > > How does the mail list want to proceed? > > My note got one person to raise their hand to work on the SHAKE document. > Once that is posted as an individual draft, we can see if the mail list > wants to adopt it. > > Russ > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm > --001a113d59764a11bd055966a2c7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I a= m willing to edit the CAA document.=C2=A0

I think the main thing there is to decide what we actually= want to do with the DNS discovery scheme.

So the first thing is to capture the issues from deployme= nt last week.
<= br>

On= Sun, Sep 17, 2017 at 12:16 PM, Russ Housley <housley@vigilsec.com= > wrote:

> That looks fine to me.=C2=A0 Where you asking the WG for input or some= thing?

We have two documents on CAA:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 - https://www.rfc-editor.org/errata/eid5065
=C2=A0 =C2=A0 =C2=A0 =C2=A0 - https://www.ietf.org/id/draft-hoffman-andrews-caa-simplification= -01.txt

How does the mail list want to proceed?

My note got one person to raise their hand to work on the SHAKE document.= =C2=A0 Once that is posted as an individual draft, we can see if the mail l= ist wants to adopt it.

Russ

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

--001a113d59764a11bd055966a2c7-- From nobody Sun Sep 17 14:57:35 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 DEB14132981 for ; Sun, 17 Sep 2017 14:57:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6EhQYw00a3oL for ; Sun, 17 Sep 2017 14:57:33 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [67.231.157.127]) (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 CF27A126E64 for ; Sun, 17 Sep 2017 14:57:33 -0700 (PDT) Received: from pps.filterd (m0122330.ppops.net [127.0.0.1]) by m0122330.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v8HLusRs030258; Sun, 17 Sep 2017 22:57:29 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=QFfkcq8N694gCDTPmxylb1WKro5g3I604FvpZLdWz9I=; b=H4IWGAJK2D6RoG8in9nidJBiIxAhlQbxoVJHQQPS05lYMSDh0booQ1g2Ws8XQEgxJDRP yn3g1YH2EETEZNM4m6UvC9yw+16ClGDHE9A9Pu7AAHPBjYCJhE8rrVbwrEZr5ZiXxMqQ Lb7hpPwjSbXVzxuxr8qN1PtIO1i4MCwA6yNKaRpJigKlVfTgW9bTFVb2P1LPHgiNaL0p pXvgAIYkXNl1JvbxcJ7OBIpRDHFe1bAefLRA8lml/GkeONVa5550Vi2ycNjNtyrjRVVo QWOKSJvupFeu7kDvxJgZXJh3ushn+R0E9nLkmIUiz45cPXqFPHF7xiy4R2zWWnjUWKTa zA== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by mx0b-00190b01.pphosted.com with ESMTP id 2d0ukt3dax-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 17 Sep 2017 22:57:29 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.21/8.16.0.21) with SMTP id v8HLuQAM031187; Sun, 17 Sep 2017 17:57:28 -0400 Received: from email.msg.corp.akamai.com ([172.27.25.31]) by prod-mail-ppoint2.akamai.com with ESMTP id 2d0y9tmbb6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sun, 17 Sep 2017 17:57:28 -0400 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb6.msg.corp.akamai.com (172.27.27.107) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sun, 17 Sep 2017 14:57:25 -0700 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.6.131]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.6.131]) with mapi id 15.00.1263.000; Sun, 17 Sep 2017 16:57:25 -0500 From: "Salz, Rich" To: Phillip Hallam-Baker , Russ Housley CC: "spasm@ietf.org" Thread-Topic: [lamps] Starting work to CAA and SHAKE Thread-Index: AQHTLlrpDPNZR/Fq8kCMJIlIzYP+6qK3irAAgAINLgCAACGVgP//+n0A Date: Sun, 17 Sep 2017 21:57:25 +0000 Message-ID: <71E706DD-F33D-4689-B1E4-65B4ED579027@akamai.com> References: <80086CAE-8B03-4E3B-8715-07DDD1B00A0D@vigilsec.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.21.0.170409 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.237.160] Content-Type: multipart/alternative; boundary="_000_71E706DDF33D4689B1E465B4ED579027akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-09-17_14:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1709170320 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-09-17_14:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1709170320 Archived-At: Subject: Re: [lamps] Starting work to CAA and SHAKE 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, 17 Sep 2017 21:57:35 -0000 --_000_71E706DDF33D4689B1E465B4ED579027akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SeKAmW0gd2lsbCBnZXQgRE5TIGZvbGtzIHRvIGhlbHAgd2l0aCB3aGF0ZXZlciB3ZSBkbyBvbiBD QUEuICBJIHRoaW5rIGEgYnJhbmQgbmV3IGRvYyBtaWdodCBiZSBiZXR0ZXIgdGhhbiBzdGlsbCB3 b3JraW5nIHRoZSBlcnJhdGEuICBQaGlsbCB3b3VsZCBiZSBhIGZpbmUgZWRpdG9yLg0KDQo= --_000_71E706DDF33D4689B1E465B4ED579027akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <7E73F2A701DA9841B2A4B6E5C71A8598@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MCAw IDAgMCAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpzcGFuLmhvZW56Yg0KCXttc28tc3R5bGUtbmFtZTpob2VuemI7fQ0Kc3Bhbi5FbWFpbFN0eWxl MTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6Q2FsaWJy aTsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBlOmV4 cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1uYW1lOiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7DQoJY29sb3I6dGVhbDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBv cnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl OjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2Lldv cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0K PGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5J4oCZbSB3 aWxsIGdldCBETlMgZm9sa3MgdG8gaGVscCB3aXRoIHdoYXRldmVyIHdlIGRvIG9uIENBQS4mbmJz cDsgSSB0aGluayBhIGJyYW5kIG5ldyBkb2MgbWlnaHQgYmUgYmV0dGVyIHRoYW4gc3RpbGwgd29y a2luZyB0aGUgZXJyYXRhLiZuYnNwOyBQaGlsbCB3b3VsZCBiZSBhIGZpbmUgZWRpdG9yLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_71E706DDF33D4689B1E465B4ED579027akamaicom_-- From nobody Sun Sep 17 15:26:28 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 781E41330B2 for ; Sun, 17 Sep 2017 15:26:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id feI3EooB70i0 for ; Sun, 17 Sep 2017 15:26:22 -0700 (PDT) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5597A13304D for ; Sun, 17 Sep 2017 15:26:22 -0700 (PDT) Received: by mail-io0-x22d.google.com with SMTP id e189so14904869ioa.4 for ; Sun, 17 Sep 2017 15:26:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=mJRezggiT5KjMWLld1Ec6+lI63cd1q8RUmE0Vme/dI0=; b=GzXd9J43sWR52GM2RKKjG9VO2Ry1YvnMaWYTKZRX6VDUBMZVDbzuxQKjUJqm29Fs3P e7OwQgBipctxx2QEGZB51evWpew76J+VSdKJ2+epQ6/WMF8zYwELpo4NPRlrjYgq8dn0 XbUNLifExS8ZnpVzNMGXTlKjC9TkUHQ1/ErJWfFCrfl93vlvZq/waqIiy7U8GBuCD+kT hVjZjpyvzxvbwsgZq2GmkQcEi1qTsvKEqiTEEKThHZ/exaOfFYH2l8Sn9ZkQw/VxMBqr JDjTaAo7PrkGGwxrPllz5u8Ce3LqpkzheHVY+pEa30WVZofTOOh8eRX9yNfq60bhokt2 Ik7A== 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=mJRezggiT5KjMWLld1Ec6+lI63cd1q8RUmE0Vme/dI0=; b=alqo0du7tGTohEv5/Ifw8KMxCEI3UMfK2ZLyiRJ1Svpmsp5djyvnazrIcsZ0qHnu+0 HUpnNn+Lfse52bdnk9tv5LEDKwInPIe0je5Oo1BbcrjmN3KGNvrht4KecgewCgcMyfWt c24M5ATlZId75Ahxa1KTcFO6n/rZmxt674NH7ejRL1m217IYlc5AdSucw9QiZZLcjDi+ KN86iguAHxITZMT8aSwPB/kJ1BGE73FB1EbP/IxNvsZmjwIR+qiN+Wkl2jKeqcOBibnT Ynptls1kHi7CnXPt3gZbg2FJKREEsvl3f6DfLRDa3sWb8GhpPnWk2tYv9YE0SFdyEco+ 63mQ== X-Gm-Message-State: AHPjjUiuFZfaWZjVEAm/Hcm3JiyEZmZ3KMOX7rP7Ofcjww3KeOHRgyK6 4jHoVVN/hx79dW/e3XMwYKCyeDipBUbQXdQlHNs= X-Google-Smtp-Source: AOwi7QDMebbwoAYGHdd85g3gIYemBdn/Eri+J8/o01AdJJVXA9i3UFWMdLrazkKg3ufMwyPG3I3g0WeW+SmlFLROhvE= X-Received: by 10.202.79.68 with SMTP id d65mr36311124oib.246.1505687181514; Sun, 17 Sep 2017 15:26:21 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.157.46.177 with HTTP; Sun, 17 Sep 2017 15:26:20 -0700 (PDT) In-Reply-To: <71E706DD-F33D-4689-B1E4-65B4ED579027@akamai.com> References: <80086CAE-8B03-4E3B-8715-07DDD1B00A0D@vigilsec.com> <71E706DD-F33D-4689-B1E4-65B4ED579027@akamai.com> From: Phillip Hallam-Baker Date: Sun, 17 Sep 2017 18:26:20 -0400 X-Google-Sender-Auth: yp7-XrVpQY74oFxjsGeVyVNO5Fc Message-ID: To: "Salz, Rich" Cc: Russ Housley , "spasm@ietf.org" Content-Type: multipart/alternative; boundary="001a113d707698dc7e05596a1dcd" Archived-At: Subject: Re: [lamps] Starting work to CAA and SHAKE 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, 17 Sep 2017 22:26:26 -0000 --001a113d707698dc7e05596a1dcd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thinking about the issue a bit more. What I think we probably need is a substantial appendix or a separate section setting out all the curlicues and complications of the discovery algorithm. It is not just the CNAME issue that is causing problems, it is also the DNSSEC part. And in particular it is the fact that DNSSEC causes DNAMEs to appear on the wire as CNAMEs. On Sun, Sep 17, 2017 at 5:57 PM, Salz, Rich wrote: > I=E2=80=99m will get DNS folks to help with whatever we do on CAA. I thi= nk a > brand new doc might be better than still working the errata. Phill would > be a fine editor. > > > --001a113d707698dc7e05596a1dcd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thi= nking about the issue a bit more. What I think we probably need is a substa= ntial appendix or a separate section setting out all the curlicues and comp= lications of the discovery algorithm.

It is not just the CNAME issue that is causing problems, it is= also the DNSSEC part. And in particular it is the fact that DNSSEC causes = DNAMEs to appear on the wire as CNAMEs.




On Sun, Sep 17, 2017 at 5:57 PM, Salz, Rich <rsalz@akamai.com> wrote:

I=E2=80=99m will get DNS folks to help with whatever we do on CAA.=C2=A0 I= think a brand new doc might be better than still working the errata.=C2=A0= Phill would be a fine editor.

=C2=A0


--001a113d707698dc7e05596a1dcd-- From nobody Mon Sep 18 04:04: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 6894D13422C for ; Mon, 18 Sep 2017 04:04:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DWE8hEE4XrRt for ; Mon, 18 Sep 2017 04:04:37 -0700 (PDT) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0134.outbound.protection.outlook.com [23.103.200.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5AF6134229 for ; Mon, 18 Sep 2017 04:04:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=9Wx19Ug9jgNTpr0sxbdy/xjm+euw5U4f8+oCWIF8w5w=; b=zz0lEE7QWeODOM9zGX/gQmRcC8AFW6k/qndrZbZRpEZ+hxHMi/0kIWdNMkziVX+OvdyjPjZQSFHyPYA3NEu2fTEww4fcoYLWAia916ujEf8uB3gPQqHV8iGyKy3p6z2bMqxvJvpb5uABFIuvRA1BbkA77QvSdoZ1TUvD5eLHE8w= Received: from CY4PR09MB1464.namprd09.prod.outlook.com (10.173.191.22) by CY4PR09MB1462.namprd09.prod.outlook.com (10.173.191.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.56.11; Mon, 18 Sep 2017 11:04:36 +0000 Received: from CY4PR09MB1464.namprd09.prod.outlook.com ([10.173.191.22]) by CY4PR09MB1464.namprd09.prod.outlook.com ([10.173.191.22]) with mapi id 15.20.0056.016; Mon, 18 Sep 2017 11:04:36 +0000 From: "Dang, Quynh (Fed)" To: Russ Housley , "spasm@ietf.org" Thread-Topic: [lamps] Starting work to CAA and SHAKE Thread-Index: AQHTLlrmk8u4eMAlE0ysIsDxJmGJV6K6fqOw Date: Mon, 18 Sep 2017 11:04:36 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=quynh.dang@nist.gov; x-originating-ip: [129.6.105.150] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR09MB1462; 6:HHTACakYtfZzt6f8wD9G5IZgHcq9s5agFETuUjDFXTrxVXKsXQVFACAhxrhSqJ3e3CffFtMXhDzysTH0JcxyCpFfkubCYl3KuVJQGibzzQf9GnAG6h1KaJPN1VeHRC52A5KjiGmGSisBPykJpJH/b5YKlUa5TqiJ9w93AGDWQ6tmMDPUirX/Hp6A1Y/OQ8S9JeG6UjsXRi/CJM/sjg3+RMt9PfLnoOw53RNwkdPHCwPs9NNcs1e8Jo77GkOLM6XjATwzRCVa29Y690OvULW3FR3xHPEW114gh5eW/rpkz4ge4sTaOlkf1GOyLZuiBM31GVKOPxi38AdeQtiEuPZRxw==; 5:rE10CV5qR9rPDmC9wNFwdBJHJbzALdz/LR3H0AaHkw7XD0hsr+SMSHS/xIJ3mkLrrLH9uxZ2dD/psswYEsLXydob22k/CerPehnZF4xAToHkhdQC3EC4RGuN5NMnhfuadjdrV+EZtEdfVYyzVfUZkQ==; 24:L9qTbjvw6lcvOmd7ahWntjsh0BXh6vQ+7VcEsHM4vHXKNgUVqBtvqj4BKMFdJzsBHrZxhBpB1ZMhzchjo6WvA6PhCfbqpgJhREWrZjZ+wgg=; 7:bwODohN4bi88APd4TGAlIHp/Y+fazQeOtLRYXcvp5i+HXUQJ0/eWdPoVFWb/Ld6siZ/WUmAj59SsU6Q/IPt+7n0lkF6KU2QJDD2qumqeAwl87nFTKrd5QA6qBbfqneVqv3msNGAbR8USrmVPAEU3yEjaKRmVyycZ91EtJUSuhLn0T0sIPtLrS6/T5U7sLiXLoN+CIu2HbkvWW5RV6krULfMGuHTNd34dT3CTUcWhOB4= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 2e15ff23-9a88-4ac3-c313-08d4fe850cb3 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY4PR09MB1462; x-ms-traffictypediagnostic: CY4PR09MB1462: x-exchange-antispam-report-test: UriScan:(158342451672863)(192374486261705)(788757137089); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(3002001)(6055026)(6041248)(20161123555025)(20161123560025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR09MB1462; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR09MB1462; x-forefront-prvs: 04347F8039 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(376002)(199003)(189002)(377454003)(78114003)(189998001)(86362001)(2501003)(77096006)(7736002)(76176999)(33656002)(54356999)(50986999)(2950100002)(2900100001)(14454004)(101416001)(25786009)(606006)(53546010)(97736004)(105586002)(81156014)(81166006)(8676002)(229853002)(74316002)(8936002)(6506006)(106356001)(6436002)(54896002)(6306002)(9686003)(236005)(6246003)(478600001)(5660300001)(316002)(53936002)(7696004)(68736007)(3280700002)(3660700001)(966005)(99286003)(102836003)(6116002)(3846002)(2906002)(66066001)(55016002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR09MB1462; H:CY4PR09MB1464.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR09MB1464DDE2B16AE0E869D93866F3630CY4PR09MB1464namp_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Sep 2017 11:04:36.2045 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR09MB1462 Archived-At: Subject: Re: [lamps] Starting work to CAA and SHAKE 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, 18 Sep 2017 11:04:40 -0000 --_000_CY4PR09MB1464DDE2B16AE0E869D93866F3630CY4PR09MB1464namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Russ and all, Yes, I am willing to work on the item 2. Regards, Quynh. ________________________________ From: Spasm on behalf of Russ Housley Sent: Friday, September 15, 2017 3:43:01 PM To: spasm@ietf.org Subject: [lamps] Starting work to CAA and SHAKE I have been discussing the recharter with EKR, and he agrees that we should= get started on this work even though the LAMPS re-charter is blocked on a = bit of process. Having completed the S/MIME 4.0 specifications and updates to support i18n = email addresses in PKIX certificates, the LAMPS WG is now ready to work on = two additional topics: 1. Specify a discovery mechanism for CAA records to replace the one describ= ed in RFC 6844. 2. Specify the use of SHAKE128/256 and SHAKE256/512 for PKIX and S/MIME. Other topics can be considered when these two are progressing. CAA RFC 6844 describes the mechanism by which CAA records relating to a domain = are discovered. Implementation experience has demonstrated an ambiguity in= the current processing of CNAME and DNAME records during discovery. Subse= quent discussion has suggested that a different discovery approach would re= solve limitations inherent in the current approach. We have seen at least = two individual drafts on this topic. I would like to have the WG adopt a r= fc6844bis as a starting point. SHAKE Unlike the previous hashing standards, the SHA-3 functions are the outcome = of an open competition. They have a clear design rationale and have receiv= ed a lot of public analysis, resulting in great confidence that the SHA-3 f= amily of functions are very secure. Also, since the design of the SHA-3 fu= nctions use a very different construction from the SHA-2 functions, they of= fer an excellent alternative to the SHA-2 family of functions. In particular, SHAKE128/256 and SHAKE256/512 offer security = and performance benefits. We have not seen any individual drafts on this y= et. It seems to me that one draft is needed for PKIX and another draft is = needed for CMS and S/MIME. Is anyone willing to work on them? Russ _______________________________________________ Spasm mailing list Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm --_000_CY4PR09MB1464DDE2B16AE0E869D93866F3630CY4PR09MB1464namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Russ and all,


Yes, I am willing to work on the item 2.


Regards,

Quynh. 

From: Spasm <spasm-bou= nces@ietf.org> on behalf of Russ Housley <housley@vigilsec.com> Sent: Friday, September 15, 2017 3:43:01 PM
To: spasm@ietf.org
Subject: [lamps] Starting work to CAA and SHAKE
 
I have been discussing the recharter with EKR, and= he agrees that we should get started on this work even though the LAMPS re= -charter is blocked on a bit of process.

Having completed the S/MIME 4.0 specifications and updates to support i18n = email addresses in PKIX certificates, the LAMPS WG is now ready to work on = two additional topics:

1. Specify a discovery mechanism for CAA records to replace the one describ= ed in RFC 6844.

2. Specify the use of SHAKE128/256 and SHAKE256/512 for PKIX and S/MIME.
Other topics can be considered when these two are progressing.


CAA

RFC 6844 describes the mechanism by which CAA records relating to a domain = are discovered.  Implementation experience has demonstrated an ambigui= ty in the current processing of CNAME and DNAME records during discovery.&n= bsp; Subsequent discussion has suggested that a different discovery approach would resolve limitations inherent in the c= urrent approach.  We have seen at least two individual drafts on this = topic.  I would like to have the WG adopt a rfc6844bis as a starting p= oint.


SHAKE

Unlike the previous hashing standards, the SHA-3 functions are the outcome = of an open competition.  They have a clear design rationale and have r= eceived a lot of public analysis, resulting in great confidence that the SH= A-3 family of functions are very secure.  Also, since the design of the SHA-3 functions use a very different constru= ction from the SHA-2 functions, they offer an excellent alternative to the = SHA-2 family
of functions.  In particular, SHAKE128/256 and SHAKE256/512 offer secu= rity and performance benefits.  We have not seen any individual drafts= on this yet.  It seems to me that one draft is needed for PKIX and an= other draft is needed for CMS and S/MIME.  Is anyone willing to work on them?

Russ
_______________________________________________
Spasm mailing list
Spasm@ietf.org
https://www.ietf.or= g/mailman/listinfo/spasm
 --_000_CY4PR09MB1464DDE2B16AE0E869D93866F3630CY4PR09MB1464namp_-- From nobody Mon Sep 18 07:36:14 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E04E71331E4 for ; Mon, 18 Sep 2017 07:36:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 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, 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 XbDD_DYjEVEG for ; Mon, 18 Sep 2017 07:36:11 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF11D1321C9 for ; Mon, 18 Sep 2017 07:36:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10584; q=dns/txt; s=iport; t=1505745370; x=1506954970; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=asxM82OtiNVVnKWU8BMdPdqk/zZoNZyICGwFqr4s+4M=; b=JHHubFIBePIhkP7ZniQyTpNJ/JHAbQUZa5Sm3LS2GN/ovT5sz99tsPsg TH9jRpe4qVBux14NCRSHFf25Cq6LYR3oEdPYqcUNg0O/veE284NF3kQt2 hsV8ZPAzhYuHukmg8fTYcueQxdCPG+XFrClSGgz1AA0orgK8dz1kHj8bv 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CyAADC2L9Z/5NdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm9AK2RuJweODo92gXSQZ4U/DoIEChgBCoUYAoRHPxgBAgEBAQE?= =?us-ascii?q?BAQFrKIUYAQEBAQMBAStBGwIBCBEEAQEoBycLFAkIAgQBEgiIWW5kEKxAiyoBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEYBYMrggKBUIFjgyiERQESAVWFPQWYQIhIApR?= =?us-ascii?q?KkwGVCAIRGQGBOAEfOIECC3cVSYccdoVhgSOBDwEBAQ?= X-IronPort-AV: E=Sophos;i="5.42,413,1500940800"; d="scan'208,217";a="296821666" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Sep 2017 14:36:09 +0000 Received: from XCH-RCD-008.cisco.com (xch-rcd-008.cisco.com [173.37.102.18]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v8IEa9fj020199 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 18 Sep 2017 14:36:09 GMT Received: from xch-aln-010.cisco.com (173.36.7.20) by XCH-RCD-008.cisco.com (173.37.102.18) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 18 Sep 2017 09:36:09 -0500 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.1263.000; Mon, 18 Sep 2017 09:36:08 -0500 From: "Panos Kampanakis (pkampana)" To: "Dang, Quynh (Fed)" , Russ Housley , "spasm@ietf.org" Thread-Topic: [lamps] Starting work to CAA and SHAKE Thread-Index: AQHTLlrfXIZ8m4v8P0uw3FozVLbwJKK60vAA///VVBA= Date: Mon, 18 Sep 2017 14:36:08 +0000 Message-ID: <8b3e335ad93d426eb359a8dd053793d2@XCH-ALN-010.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.108.5] Content-Type: multipart/alternative; boundary="_000_8b3e335ad93d426eb359a8dd053793d2XCHALN010ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [lamps] Starting work to CAA and SHAKE 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, 18 Sep 2017 14:36:13 -0000 --_000_8b3e335ad93d426eb359a8dd053793d2XCHALN010ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 Happy to work with Quynh on the X.509 SHAKE draft as well. Panos From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Dang, Quynh (Fed) Sent: Monday, September 18, 2017 7:05 AM To: Russ Housley ; spasm@ietf.org Subject: Re: [lamps] Starting work to CAA and SHAKE Hi Russ and all, Yes, I am willing to work on the item 2. Regards, Quynh. ________________________________ From: Spasm > on beha= lf of Russ Housley > Sent: Friday, September 15, 2017 3:43:01 PM To: spasm@ietf.org Subject: [lamps] Starting work to CAA and SHAKE I have been discussing the recharter with EKR, and he agrees that we should= get started on this work even though the LAMPS re-charter is blocked on a = bit of process. Having completed the S/MIME 4.0 specifications and updates to support i18n = email addresses in PKIX certificates, the LAMPS WG is now ready to work on = two additional topics: 1. Specify a discovery mechanism for CAA records to replace the one describ= ed in RFC 6844. 2. Specify the use of SHAKE128/256 and SHAKE256/512 for PKIX and S/MIME. Other topics can be considered when these two are progressing. CAA RFC 6844 describes the mechanism by which CAA records relating to a domain = are discovered. Implementation experience has demonstrated an ambiguity in= the current processing of CNAME and DNAME records during discovery. Subse= quent discussion has suggested that a different discovery approach would re= solve limitations inherent in the current approach. We have seen at least = two individual drafts on this topic. I would like to have the WG adopt a r= fc6844bis as a starting point. SHAKE Unlike the previous hashing standards, the SHA-3 functions are the outcome = of an open competition. They have a clear design rationale and have receiv= ed a lot of public analysis, resulting in great confidence that the SHA-3 f= amily of functions are very secure. Also, since the design of the SHA-3 fu= nctions use a very different construction from the SHA-2 functions, they of= fer an excellent alternative to the SHA-2 family of functions. In particular, SHAKE128/256 and SHAKE256/512 offer security = and performance benefits. We have not seen any individual drafts on this y= et. It seems to me that one draft is needed for PKIX and another draft is = needed for CMS and S/MIME. Is anyone willing to work on them? Russ _______________________________________________ Spasm mailing list Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm --_000_8b3e335ad93d426eb359a8dd053793d2XCHALN010ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1

Happy to work with Quynh on the X.509= SHAKE draft as well.

Panos

 

From: Spasm [mailto:spasm-bounces@ie= tf.org] On Behalf Of Dang, Quynh (Fed)
Sent: Monday, September 18, 2017 7:05 AM
To: Russ Housley <housley@vigilsec.com>; spasm@ietf.org
Subject: Re: [lamps] Starting work to CAA and SHAKE

 

H= i Russ and all,

<= o:p> 

Y= es, I am willing to work on the item 2.

<= o:p> 

R= egards,

Q= uynh. 

From: Spasm = <spasm-bounces@ietf.org>= ; on behalf of Russ Housley <hous= ley@vigilsec.com>
Sent: Friday, September 15, 2017 3:43:01 PM
To: spasm@ietf.org
Subject: [lamps] Starting work to CAA and SHAKE

 

I have been discuss= ing the recharter with EKR, and he agrees that we should get started on thi= s work even though the LAMPS re-charter is blocked on a bit of process.

Having completed the S/MIME 4.0 specifications and updates to support i18n = email addresses in PKIX certificates, the LAMPS WG is now ready to work on = two additional topics:

1. Specify a discovery mechanism for CAA records to replace the one describ= ed in RFC 6844.

2. Specify the use of SHAKE128/256 and SHAKE256/512 for PKIX and S/MIME.
Other topics can be considered when these two are progressing.


CAA

RFC 6844 describes the mechanism by which CAA records relating to a domain = are discovered.  Implementation experience has demonstrated an ambigui= ty in the current processing of CNAME and DNAME records during discovery.&n= bsp; Subsequent discussion has suggested that a different discovery approach would resolve limitations inherent in the c= urrent approach.  We have seen at least two individual drafts on this = topic.  I would like to have the WG adopt a rfc6844bis as a starting p= oint.


SHAKE

Unlike the previous hashing standards, the SHA-3 functions are the outcome = of an open competition.  They have a clear design rationale and have r= eceived a lot of public analysis, resulting in great confidence that the SH= A-3 family of functions are very secure.  Also, since the design of the SHA-3 functions use a very different constru= ction from the SHA-2 functions, they offer an excellent alternative to the = SHA-2 family
of functions.  In particular, SHAKE128/256 and SHAKE256/512 offer secu= rity and performance benefits.  We have not seen any individual drafts= on this yet.  It seems to me that one draft is needed for PKIX and an= other draft is needed for CMS and S/MIME.  Is anyone willing to work on them?

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

--_000_8b3e335ad93d426eb359a8dd053793d2XCHALN010ciscocom_-- From nobody Tue Sep 19 03:20:33 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 059D9126B7E for ; Tue, 19 Sep 2017 03:20:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 84FVmiJTscks for ; Tue, 19 Sep 2017 03:20:29 -0700 (PDT) Received: from off-send01.osa.jprs.co.jp (off-send01.osa.jprs.co.jp [IPv6:2001:218:3001:17::10]) (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 699EE132D8A for ; Tue, 19 Sep 2017 03:20:16 -0700 (PDT) Received: from off-sendsmg01.osa.jprs.co.jp (off-sendsmg01.osa.jprs.co.jp [172.23.8.61]) by off-send01.osa.jprs.co.jp (8.14.4/8.14.4) with ESMTP id v8JAKAdu003804; Tue, 19 Sep 2017 19:20:10 +0900 Received: from off-sendsmg01.osa.jprs.co.jp (localhost [127.0.0.1]) by postfix.imss71 (Postfix) with ESMTP id 30607180064; Tue, 19 Sep 2017 19:20:09 +0900 (JST) Received: from localhost (off-cpu05.osa.jprs.co.jp [172.23.4.15]) by off-sendsmg01.osa.jprs.co.jp (Postfix) with ESMTP id 1A390180062; Tue, 19 Sep 2017 19:20:09 +0900 (JST) Date: Tue, 19 Sep 2017 19:20:08 +0900 (JST) Message-Id: <20170919.192008.787143344501911357.fujiwara@jprs.co.jp> To: jsha@eff.org Cc: spasm@ietf.org From: fujiwara@jprs.co.jp In-Reply-To: <02d4e149-b777-5b5c-1cd0-a2c2aae49311@eff.org> References: <02d4e149-b777-5b5c-1cd0-a2c2aae49311@eff.org> X-Mailer: Mew version 6.5 on Emacs 24.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1690-8.1.0.1062-23338.004 X-TM-AS-Result: No--0.693-5.0-31-10 X-imss-scan-details: No--0.693-5.0-31-10 X-TMASE-MatchedRID: jOF9SGbtYWxCXIGdsOwlUu5i6weAmSDKYawhvkuLgj7adW4iYSMjUds1 CHzkaGoiSEpwrDCjtgwHwP5zLNLkyfdlvs2UcJ0YrQcmzcV8ovwPo0vi0aZfNbv408/GP5HqWio bvLavUWKxMJ5xZ0J5p4/c5Me1/B6VtcCPfkIwcq4c9jA4mLo8uReN8ZMPETMtvH0oAj/wZg+jxY yRBa/qJX3mXSdV7KK4P+fP7xq5aHOy9Q92ZKlY2s4XLBsYBeuCKrauXd3MZDU0XYPbWCCVhYHLK Csoj7WVHv11FZcBnjoqBYIeCc+udyV//CVLUCMm0j8DLTpYMUtuzL3l31iDD756D1/9xR+Q2/Cz k69Kxn+K1E7EcEHndXWzxraQrrH3fWtDOV9+jn3/UOLrc6wdEOiH9KrflGju Archived-At: Subject: Re: [lamps] CAA Simplification draft 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, 19 Sep 2017 10:20:32 -0000 I did not know about RFC 6844 and was surprised about "tree climing" and "CNAME". > From: Jacob Hoffman-Andrews > https://www.ietf.org/id/draft-hoffman-andrews-caa-simplification-00.txt I checked differences between RFC 6844 and the draft. https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/rfc/rfc6844.txt&url2=https://www.ietf.org/id/draft-hoffman-andrews-caa-simplification-01.txt I have some comments. - Current draft has some formatting mistakes. current text: $ORIGIN example.com . CAA 0 issue "ca.example.net" should be (from RFC 6844) rfc6844: $ORIGIN example.com rfc6844: . CAA 0 issue "ca.example.net" However, I would like to suggest to remove "$ORIGIN" and add tailing dot in domain names. proposed: example.com. CAA 0 issue "ca.example.net" - Current document still contain "tree climing" and checks CAA RR in TLDs. The tree climing should stop at administrative domain boundaries. "example.com." domain name owner does not want to be checked "com. CAA". See (concluded) dbound WG and Public Suffix list discussions. https://tools.ietf.org/wg/dbound/ https://publicsuffix.org/ - I like prefixed record solution proposed at IETF 99 lamps WG. https://datatracker.ietf.org/meeting/99/materials/slides-99-lamps-caabis/ However, it is not compatible with RFC 6844. Regards, -- Kazunori Fujiwara, JPRS From nobody Tue Sep 19 05:05:01 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B796B132939 for ; Tue, 19 Sep 2017 05:04:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c2YWPcjXufJJ for ; Tue, 19 Sep 2017 05:04:57 -0700 (PDT) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E1E4134212 for ; Tue, 19 Sep 2017 05:04:55 -0700 (PDT) Received: by mail-io0-x236.google.com with SMTP id l15so9377861iol.8 for ; Tue, 19 Sep 2017 05:04:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=jSW74RluwQo6yHtufXxoGkclifzu2PiIAl3aNC3Xjm0=; b=IyP7uKDJzDUH2onXuCE4J2vmr5APkiA3tPVM/9VFLMH4Y82yFqWX2QedETU+KTtiBd FPwWE2cJHqECFH5JwjUOhtCxyAbhmekKXp5P6ZC56lCrcEE1HN9KToWDTNtD6KjRjIgF fxs9FYpJNNjpzW2mxeIvX8fGuFE/pFVwmuMWnrTrFndAMYJRj7fztPEy3kfzZTUfypWr DxoaGg4HS+BWAXX3kK4v7nEpGXX09hwZRwf0Gxmll1o904+qY1ZewIgCk9RAcJkMiE5V C8I4yYQwR+01mMyUH9++3WQj1JCrRchQ2r2R4cmNr6I24M5nwYPYS5RheGMrFcvnd7Kg b3aA== 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=jSW74RluwQo6yHtufXxoGkclifzu2PiIAl3aNC3Xjm0=; b=XMVfX4ID2H/8cM9PW7Z2Ep1NdL8RhDKfrd3kAvI1PYM8rKlDHWVOBWMZ0ReVvex8kz L58rJu1EhO06q5MYU5fDp1gbydgFsXiZejWuCij5NH/AiBLkHcshh7SqUgjedHc5+71x 66JMi/hcCponfZ6+03RC4WSFFTt642MYfZV/qHcSVDxzZ3ab4QnHgbYI4pASYnisLQAg 6zDjsFN1WyZH+J5X+vPT026UONzoxR8xmjk/qXXZ/nIldz7YQhExkp3EMpC8dX8YIXs8 HOU53Vw0mjT3k0YrF7ORK6UtoFJDNBEBmOHv0tuHLF868V6AAyUCRRTjdm5iKECfdJJB gKcQ== X-Gm-Message-State: AHPjjUicL4As15Pzz0xYUX6PBr4NTVYsSIkLwQS81sPQ3qy5V5t4J4O3 IET566eitI/7Fo2GVi3yXK00g6i6S1ugCEvLXzA= X-Google-Smtp-Source: AOwi7QD6uOJ55pQQ+tETzXLW7VpAoX2p+xN7PfVmT5WUO6Joj/SpBm5rE9+G4mAHlTwGSwHNGN2LWUKiyleBk2xvxoo= X-Received: by 10.202.44.80 with SMTP id s77mr1176363ois.262.1505822694336; Tue, 19 Sep 2017 05:04:54 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.157.46.177 with HTTP; Tue, 19 Sep 2017 05:04:53 -0700 (PDT) In-Reply-To: <20170919.192008.787143344501911357.fujiwara@jprs.co.jp> References: <02d4e149-b777-5b5c-1cd0-a2c2aae49311@eff.org> <20170919.192008.787143344501911357.fujiwara@jprs.co.jp> From: Phillip Hallam-Baker Date: Tue, 19 Sep 2017 08:04:53 -0400 X-Google-Sender-Auth: BLKKqLd0gyYIwNzGVVPyVa3goJ8 Message-ID: To: fujiwara@jprs.co.jp Cc: Jacob Hoffman-Andrews , SPASM Content-Type: multipart/alternative; boundary="001a1137d83eca6e0e055989aaed" Archived-At: Subject: Re: [lamps] CAA Simplification draft 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, 19 Sep 2017 12:04:59 -0000 --001a1137d83eca6e0e055989aaed Content-Type: text/plain; charset="UTF-8" Administrative boundaries are not visible in the DNS. Attempting to attach semantics to the zone cut creates more problems than it solves. Given the length of the document and the need to cite it in other documents, I don't think an update is appropriate. Obsoleting the old text and replacing is the way to go. The reason the tree climbing is necessary is that MANY DNS host and service names are not visible on the public DNS. So most of the time, a CA has no way to validate the records for secrethost.example.com, the CAA record has to be at example.com. The reason aliases are necessary is two fold. One is to support delegation of the domain to a different administration as is typical in a CDN, the other is to simplify management of large portfolios of domains. The DNS only provides one alias record (DNAME is not an alias, see below) so it is not clear what the purpose of the alias is. When RFC6844 was written, CDNs were the exception, now they are much more common. Further, the DNS spec is broken in that it requires that a CNAME be the only entry at a node if present. On the DNAME issue, it is not really an alias as a DNAME is a wildcard record that would have never appeared on the wire until DNSSEC made it necessary. An application does not process a DNAME directly, it uses the DNAME record to either validate a CNAME or infer that one should have been presented but was not. On Tue, Sep 19, 2017 at 6:20 AM, wrote: > I did not know about RFC 6844 and was surprised about "tree climing" > and "CNAME". > > > From: Jacob Hoffman-Andrews > > https://www.ietf.org/id/draft-hoffman-andrews-caa-simplification-00.txt > > I checked differences between RFC 6844 and the draft. > https://tools.ietf.org/rfcdiff?url1=https://tools. > ietf.org/rfc/rfc6844.txt&url2=https://www.ietf.org/id/draft- > hoffman-andrews-caa-simplification-01.txt > > I have some comments. > > - Current draft has some formatting mistakes. > > current text: $ORIGIN example.com . CAA 0 issue "ca.example.net" > > should be (from RFC 6844) > > rfc6844: $ORIGIN example.com > rfc6844: . CAA 0 issue "ca.example.net" > > However, I would like to suggest to remove "$ORIGIN" and add tailing > dot in domain names. > > proposed: example.com. CAA 0 issue "ca.example.net" > > - Current document still contain "tree climing" and checks CAA RR in TLDs. > > The tree climing should stop at administrative domain boundaries. > > "example.com." domain name owner does not want to be checked "com. CAA". > > See (concluded) dbound WG and Public Suffix list discussions. > https://tools.ietf.org/wg/dbound/ > https://publicsuffix.org/ > > - I like prefixed record solution proposed at IETF 99 lamps WG. > https://datatracker.ietf.org/meeting/99/materials/slides- > 99-lamps-caabis/ > > However, it is not compatible with RFC 6844. > > Regards, > > -- > Kazunori Fujiwara, JPRS > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm > --001a1137d83eca6e0e055989aaed Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Adm= inistrative boundaries are not visible in the DNS. Attempting to attach sem= antics to the zone cut creates more problems than it solves.

Given the length of the document and th= e need to cite it in other documents, I don't think an update is approp= riate. Obsoleting the old text and replacing is the way to go.


The reason the tree climbing is necessary is th= at MANY DNS host and service names are not visible on the public DNS. So mo= st of the time, a CA has no way to validate the records for secrethost.example.com, the CAA record has t= o be at example.com.

The reason aliases are necessary is two fold= . One is to support delegation of the domain to a different administration = as is typical in a CDN, the other is to simplify management of large portfo= lios of domains. The DNS only provides one alias record (DNAME is not an al= ias, see below) so it is not clear what the purpose of the alias is. When R= FC6844 was written, CDNs were the exception, now they are much more common.=

Further, the DNS spec is= broken in that it requires that a CNAME be the only entry at a node if pre= sent.=C2=A0

On the DNAME issue, it = is not really an alias as a DNAME is a wildcard record that would have neve= r appeared on the wire until DNSSEC made it necessary. An application does = not process a DNAME directly, it uses the DNAME record to either validate a= CNAME or infer that one should have been presented but was not.=C2=A0





On Tue, Sep 19, 2017 at 6:20 AM, <= fujiwara@jprs.co.j= p> wrote:
I did not know ab= out RFC 6844 and was surprised about "tree climing"
and "CNAME".

> From: Jacob Hoffman-Andrews <jsha@e= ff.org>
> https://www.ietf.org/id/= draft-hoffman-andrews-caa-simplification-00.txt

I checked differences between RFC 6844 and the draft.
https://tools.ie= tf.org/rfcdiff?url1=3Dhttps://tools.ietf.org/rfc/rfc6844.txt&= url2=3Dhttps://www.ietf.org/id/draft-hoffman-andrews-caa-sim= plification-01.txt

I have some comments.

- Current draft has some formatting mistakes.

=C2=A0 current text: $ORIGIN example.com .=C2=A0 CAA 0 issue "ca.example.net<= /a>"

=C2=A0 should be=C2=A0 =C2=A0(from RFC 6844)

=C2=A0 rfc6844:=C2=A0 $ORIGIN example.com
=C2=A0 rfc6844:=C2=A0 .=C2=A0 CAA 0 issue "ca.example.net"

=C2=A0 However, I would like to suggest to remove "$ORIGIN" and a= dd tailing
=C2=A0 dot in domain names.

=C2=A0 proposed:=C2=A0 example.com. CAA 0 issue "ca.example.net"

- Current document still contain "tree climing" and checks CAA RR= in TLDs.

=C2=A0 The tree climing should stop at administrative domain boundaries.
=C2=A0 "example.com." domain name owner does not want to be checked = "com. CAA".

=C2=A0 See (concluded) dbound WG and Public Suffix list discussions.
=C2=A0 =C2=A0 https://tools.ietf.org/wg/dbound/
=C2=A0 =C2=A0 https://publicsuffix.org/

- I like prefixed record solution proposed at IETF 99 lamps WG.
=C2=A0 https://datatracker.= ietf.org/meeting/99/materials/slides-99-lamps-caabis/

=C2=A0 However, it is not compatible with RFC 6844.

Regards,

--
Kazunori Fujiwara, JPRS <fujiwara= @jprs.co.jp>

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

--001a1137d83eca6e0e055989aaed-- From nobody Wed Sep 20 06:22:23 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BC76133205; Wed, 20 Sep 2017 06:22:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iCtZtxPKn-RN; Wed, 20 Sep 2017 06:21:58 -0700 (PDT) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 685EC134212; Wed, 20 Sep 2017 06:21:58 -0700 (PDT) Received: by mail-wm0-x235.google.com with SMTP id r68so7151958wmg.3; Wed, 20 Sep 2017 06:21:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/ntSqCCIbi5IkG8kBgc+o6EXHSWRyN429laHemOqxSM=; b=ogf2l0hNQ6+ZSAgnET/FT8vO/ho9jE4+WC58zPIeyD3qmEuNPs6loLXAXeTq+bMzzT 3MWs5kwuzdSrILEyhXCqq1nnlZUiZW61ZHPHEQSWUGlWoUvxva0K0mRnZ5S6cdb1d16V abZs4i1oreUR0g429UvDjsXbOK58oj8SWymSMhRmJ5zIO4jjURz78fPBGYbHaoB7e2l/ cYxpjH6NZZE6f/pl9CwS1+BZ6AIV1do3x5ntPxvTlkEdflowCbc8Gv/UNlVVXm2X31rA QA7xLQ6n+lBuk6BksfdkAx0oEz/Ef2nPQKpA83BgQabdpIOOSl86glZD64Tg46qlImRH 1KIw== 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=/ntSqCCIbi5IkG8kBgc+o6EXHSWRyN429laHemOqxSM=; b=Jbex6MMKE9i32dl5am6KAulA/iCUx2RvzeqL0FtuS7d2u4eabRpHvt3ngq2UG1FlCC ZPPvEjBoJSRmdrQgwc0jgHGzxOJm1FFQdlnNQn8MR3gtQSDgjP1vrtG16xeUQxXIocgQ dMbFbepF2P/93Au9aCwX0jimG71hurajBwalHPRUe9D2rdljb+qL3Ik0lbz3BdGcL2Xd vtO+jyBc70CEUZCxPWD7pVzFTf66wMvv8GhaGRhmqINj5aeVpzIJeetLpUHTiTLfwp8Q Ma817piy7ojkdLPp4vhOSV/lWsS6icw/4U7vtX4evSHUnMO+S5SSEC55qGItlYzwDx2i 7Mcw== X-Gm-Message-State: AHPjjUiWGXJ/Sx0WIMHUk+XphIopqfL2kQZKNLftjz9CEiXOkB6JF+H3 eVMSkVVxcFUScLQNOlZbL8FUclGMNyE4FqC5uY8= X-Google-Smtp-Source: AOwi7QBotSqgFsU8jOJorTakDVqL7xoy0IBn3No/0KfsXfe8XFIHZI99co7uKUZbX7onAmAoSSuzx7GFAyF7oLQ2ZOo= X-Received: by 10.80.165.82 with SMTP id z18mr4463837edb.172.1505913716867; Wed, 20 Sep 2017 06:21:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.220.202 with HTTP; Wed, 20 Sep 2017 06:21:56 -0700 (PDT) In-Reply-To: References: <150522092693.4724.2532571098567577114.idtracker@ietfa.amsl.com> From: Dmitry Belyavsky Date: Wed, 20 Sep 2017 16:21:56 +0300 Message-ID: To: Nikos Mavrogiannopoulos Cc: "saag@ietf.org" , LAMPS , dev-security-policy@lists.mozilla.org, pkix@ietf.org Content-Type: multipart/alternative; boundary="94eb2c0de67c28062305599edcf9" 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: Wed, 20 Sep 2017 13:22:02 -0000 --94eb2c0de67c28062305599edcf9 Content-Type: text/plain; charset="UTF-8" Dear Nikos On Wed, Sep 13, 2017 at 9:39 AM, Nikos Mavrogiannopoulos wrote: > > 4. How do you handle extensions to this format? > > Overall, why not use X.509 extensions to store such additional > constraints? We already (in the p11-kit trust store in Fedora/RHEL > systems) use the notion of stapled extensions to limit certificates > [0, 1] and seems quite a flexible approach. Have you considered that > path? > > regards, > Nikos > > [0]. https://p11-glue.freedesktop.org/doc/storing-trust-policy/ > storing-trust-model.html > [1]. http://nmav.gnutls.org/2016/06/restricting-scope-of-ca- > certificates.html > I've looked through the specification. It's OK for me, but I do not get whether the attached extensions are crypto-protected. I'm ready to cooperate with you if there is any interest. -- SY, Dmitry Belyavsky --94eb2c0de67c28062305599edcf9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Nikos

On Wed, Sep 13, 2017 at 9:39 AM, Nikos Mavrogiannopoulos <nmav@gnu= tls.org> wrote:

4. How do you handle extensions to this format?

Overall, why not use X.509 extensions to store such additional
constraints? We already (in the p11-kit trust store in Fedora/RHEL
systems) use the notion of stapled extensions to limit certificates
[0, 1] and seems quite a flexible approach. Have you considered that
path?

regards,
Nikos

[0]. https://p11-g= lue.freedesktop.org/doc/storing-trust-policy/storing-trust-model.= html
[1]. http://nmav.gnutls.org/= 2016/06/restricting-scope-of-ca-certificates.html

I've looked through the specification. It's = OK for me, but I do not get whether the attached extensions are crypto-prot= ected.
I'm ready to cooperate with you = if there is any interest.

--
SY, Dmitry Belyavsk= y
--94eb2c0de67c28062305599edcf9-- From nobody Wed Sep 20 09:10:50 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1B8D133158 for ; Wed, 20 Sep 2017 09:10:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eff.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y3FRk03S9QyF for ; Wed, 20 Sep 2017 09:10:48 -0700 (PDT) Received: from mail2.eff.org (mail2.eff.org [173.239.79.204]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFFAC132D18 for ; Wed, 20 Sep 2017 09:10:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject; bh=C15VB3HhCy1Bsq2fpllBzr2rWZhBOHnmwyYUt/uA8j8=; b=m3eW4pPkhjUOKhTOknqeZsnb8U+AWP+FaHPra4As81UBFsOAT+cPrREzWIHGcZLDPHjRUbHkTD5SPdxzu4gsFzFe6mM5zThAj3URo4ZpG9cE+o1SFe5gNh3jEEcrzIfCaY85CmSa76WKYThkqR9gh8L6ivMw8QgbJEM2Fq9zRJY=; Received: ; Wed, 20 Sep 2017 09:10:45 -0700 To: spasm@ietf.org References: <02d4e149-b777-5b5c-1cd0-a2c2aae49311@eff.org> <20170919.192008.787143344501911357.fujiwara@jprs.co.jp> From: Jacob Hoffman-Andrews Message-ID: <44fd171d-4487-99f4-5cb4-4279c069a203@eff.org> Date: Wed, 20 Sep 2017 09:10:47 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <20170919.192008.787143344501911357.fujiwara@jprs.co.jp> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Received-SPF: skipped for local relay Archived-At: Subject: Re: [lamps] CAA Simplification draft 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, 20 Sep 2017 16:10:49 -0000 On 09/19/2017 03:20 AM, fujiwara@jprs.co.jp wrote: > - Current document still contain "tree climing" and checks CAA RR in TLDs. Yes, the goal is to remove tree climbing on the targets of aliases, which causes known problems (discussed earlier on this list), but keep tree climbing on the actual hostname being checked, which provides useful properties as Phillip mentioned. Thanks for pointing out the formatting mistakes, I'll fix those. From nobody Fri Sep 22 01:07:23 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E9C11342CC; Fri, 22 Sep 2017 01:07:14 -0700 (PDT) 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 Q-n-ZH7TxNHJ; Fri, 22 Sep 2017 01:07:12 -0700 (PDT) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAE0D1326ED; Fri, 22 Sep 2017 01:07:12 -0700 (PDT) Received: by mail-qt0-x22e.google.com with SMTP id l25so304929qtf.13; Fri, 22 Sep 2017 01:07:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=vBJE8mrBdTSyBWtBoTFZsowcFqF8InTDMATdgzA1yJ4=; b=HsWc5Y+Vvfu+6mNOxADaWNEFc0s/ZbkN9N7Scb/srqRFOd467GXidiYJbQ+YfVYasF BzIPeD3MHjomDqMA9KNLYFnv+2dE9+majeN7qloOLGswlrEF27IjzOOVYMR6NuZnsCT/ DElsD5ajILwjgrgVsYZl0vxJlcPy46gu0gguaL/yv5nSleQWgSJMTnaquFVSSsEpgqId 4fmbfq2GTLaONAtTDpcoRb+7J1wr9aw686YeCvyC7eftPZphd6bk3XERx2GDeP2vGQNJ X+79EGiai0TsUQbinNHIz29TPX0k7ml6ULm45Xm+tI1UtEBCZ/qejhJQT+xo3cL3WCf3 EPxw== 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=vBJE8mrBdTSyBWtBoTFZsowcFqF8InTDMATdgzA1yJ4=; b=FqTQvhtFkluruTYJU+tq2+gPafdwxmRyXRmQ+7Z9XBSHnhbxDo0JdX/zCLo8EYkbaO JJ9E6wp41jCyH2QG7WviUf97mTzNqx5Vsm6SCPJ5l+VX917YXZ5Nn0vEuUSA33njurvF VRV5FnqpaQ8E4W8wu6i25xwRVEVE8emTrNeFYHBSSrcOvs/MNMkjYSmaJF8Zg/qkemQ8 jP2wXXuUddAoh20exaz0eQ1Oxq6WjoGlV9wWQy+S03nof+KlLWbiZVg4S5eJq1zjxAsn bNmZSVyoDtub75jRpwPm771/1OZRxvp8LEOt18dAhEHSjkCrLkgD8xxqi57Fn39lBI9o 62mA== X-Gm-Message-State: AHPjjUitKmWE5FwblPVLKuIVtj5jG0AANLuF2AavM1rve9FbMusP/EyA M8aOfKApyLzFZYholQNozBkRndTi/WHlOEzQBpBlB197 X-Google-Smtp-Source: AOwi7QDDOO2NS5wxjNzH3OX/LY9A3hbgBfwO1y1ijziCfn7cGbynxVFrc4HGMEU8oz2GLD9fw47GsLtQxjYYqPClqPI= X-Received: by 10.200.52.60 with SMTP id u57mr7361042qtb.107.1506067631778; Fri, 22 Sep 2017 01:07:11 -0700 (PDT) MIME-Version: 1.0 Sender: n.mavrogiannopoulos@gmail.com Received: by 10.12.175.136 with HTTP; Fri, 22 Sep 2017 01:06:31 -0700 (PDT) In-Reply-To: References: <150522092693.4724.2532571098567577114.idtracker@ietfa.amsl.com> From: Nikos Mavrogiannopoulos Date: Fri, 22 Sep 2017 10:06:31 +0200 X-Google-Sender-Auth: Zg2LgTczXlHytCnGWbVTaghDHQU Message-ID: To: Dmitry Belyavsky Cc: "saag@ietf.org" , LAMPS , dev-security-policy@lists.mozilla.org, pkix@ietf.org Content-Type: text/plain; charset="UTF-8" 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: Fri, 22 Sep 2017 08:07:14 -0000 On Wed, Sep 20, 2017 at 3:21 PM, Dmitry Belyavsky wrote: > Dear Nikos > > On Wed, Sep 13, 2017 at 9:39 AM, Nikos Mavrogiannopoulos > wrote: >> >> >> 4. How do you handle extensions to this format? >> >> Overall, why not use X.509 extensions to store such additional >> constraints? We already (in the p11-kit trust store in Fedora/RHEL >> systems) use the notion of stapled extensions to limit certificates >> [0, 1] and seems quite a flexible approach. Have you considered that >> path? >> >> regards, >> Nikos >> >> [0]. >> https://p11-glue.freedesktop.org/doc/storing-trust-policy/storing-trust-model.html >> [1]. >> http://nmav.gnutls.org/2016/06/restricting-scope-of-ca-certificates.html > I've looked through the specification. It's OK for me, but I do not get > whether the attached extensions are crypto-protected. No, as these values are inserted by the administrator of the system, or us (the distributor of the software), we didn't feel we needed the introduction of additional PKI. How do you see the infrastructure on the draft-belyavskiy-certificate-limitation-policy? Who do you envision signing these structures? (I assume that distribution of data will be done by software distributors?) >> 4. How do you handle extensions to this format? >> > Simillary to CRL. Do you have ideas of the extensions? 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. 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 } Another difference between this profile and the p11-kit one, is that the extensions/revocation here is done on the certificate, while in p11-kit is done on the public key. Both approaches have pros and cons. Another question. I also noticed the fingerprint field above. Is that to distinguish between same CAs with different keys? In that case using the SubjectPublicKeyIdentifier may be sufficient, and more natural as this is how certificates with matching DNs/serials are distinguished. regards, Nikos From nobody Mon Sep 25 09:25:02 2017 Return-Path: X-Original-To: spasm@ietf.org Delivered-To: spasm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B94E1344C3; Mon, 25 Sep 2017 09:25:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.62.1 Auto-Submitted: auto-generated Precedence: bulk CC: lamps-chairs@ietf.org, ekr@rtfm.com, Russ Housley , housley@vigilsec.com, draft-ietf-lamps-eai-addresses@ietf.org, spasm@ietf.org Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <150635670119.27403.15548557096112745114.idtracker@ietfa.amsl.com> Date: Mon, 25 Sep 2017 09:25:01 -0700 Archived-At: Subject: [lamps] Last Call: (Internationalized Email Addresses in X.509 certificates) to Proposed Standard X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 16:25:01 -0000 The IESG has received a request from the Limited Additional Mechanisms for PKIX and SMIME WG (lamps) to consider the following document: - 'Internationalized Email Addresses in X.509 certificates' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2017-10-09. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines a new name form for inclusion in the otherName field of an X.509 Subject Alternative Name and Issuer Alternative Name extension that allows a certificate subject to be associated with an Internationalized Email Address. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-lamps-eai-addresses/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-lamps-eai-addresses/ballot/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: draft-housley-rfc5280-i18n-update: Internationalization Updates to RFC 5280 (None - ) From nobody Wed Sep 27 11:40:53 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 5147B1330AD for ; Wed, 27 Sep 2017 11:40:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 Npn778co1JN3 for ; Wed, 27 Sep 2017 11:40:50 -0700 (PDT) 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 120DB132D4B for ; Wed, 27 Sep 2017 11:40:49 -0700 (PDT) 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=1506537599; h=from:subject:to:date:message-id; bh=Ws3Q9EXkCRX6b3LNLQ36tlgZy08Y9smDkQ5hU2Fu7V4=; b=fCR3ebB5mFBPP00aqVesT+2eStOSoxogtnMlVegPArF6YN8xe2194V2HngQHs76W3958OQme+7M Z3/pKP+cxdMTiKLMaCe2fegrm/r1N3r7pyZ1FwCcHS77NmTvvF5ikuEkGjCTNGTSleasrJwOSe86F bhuWPtiFhEYKoLsZhigXGXLvF/r4eUz16vHorztBpOD3eUue8F7luMbijMXXis/QFEqgJ6wp04yTS YIx1ggoWdM8ioPzfmsjnNBOFnaybq2KAUdNaSSXadiBMNlcgiKIiw9uGbbQvSD3FY12mKBPk01mk4 yE/fQKHkElqMv/1JVeX9TMdwiYum2MnkWE3A== 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; Wed, 27 Sep 2017 11:39:58 -0700 Received: from Hebrews (192.168.1.162) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 27 Sep 2017 11:39:58 -0700 From: Jim Schaad To: 'SPASM' Date: Wed, 27 Sep 2017 11:40:41 -0700 Message-ID: <024101d337c0$2069f5e0$613de1a0$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdM3v5PJQwfXXcFdSySyL1RUVqVVFg== X-Originating-IP: [192.168.1.162] Archived-At: Subject: [lamps] Review comment from the AD 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, 27 Sep 2017 18:40:51 -0000 I have one review comment from EKR on rfc5750bis that I am not sure what to do with. The following paragraph from Section 6 - Security Considerations When determining the time for a certificate validity check, agents have to be careful to use a reliable time. Unless it is from a trusted agent, this time MUST NOT be the SigningTime attribute found in an S/MIME message. For most sending agents, the SigningTime attribute could be deliberately set to direct the receiving agent to check a CRL that could have out-of-date revocation status for a certificate, or cause an improper result when checking the Validity field of a certificate. The problem is two-fold: 1. Should the definition of trusted agent be expanded to be more clear, and 2. Should that sentence just be deleted because, even if it is a trusted agent, a compromised key is going to be able to lie about the time anyway. My memory was that this text was supposed to deal with things like time-stamp agents where the time was significant, but it could be wrong. Jim From nobody Wed Sep 27 11:56:10 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 7ED761320CF for ; Wed, 27 Sep 2017 11:56:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5oX0JbPCABUo for ; Wed, 27 Sep 2017 11:56:05 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2E55132D4B for ; Wed, 27 Sep 2017 11:56:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 0DD6D30058D for ; Wed, 27 Sep 2017 14:56:05 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 0m-tvSZyYLVF for ; Wed, 27 Sep 2017 14:56:03 -0400 (EDT) Received: from [172.20.1.237] (h60.74.129.40.static.ip.windstream.net [40.129.74.60]) by mail.smeinc.net (Postfix) with ESMTPSA id B831A30009D; Wed, 27 Sep 2017 14:56:03 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Russ Housley In-Reply-To: <024101d337c0$2069f5e0$613de1a0$@augustcellars.com> Date: Wed, 27 Sep 2017 14:56:03 -0400 Cc: SPASM Content-Transfer-Encoding: quoted-printable Message-Id: <6EC17286-BCA3-4C56-80A6-EEA8279ED5D6@vigilsec.com> References: <024101d337c0$2069f5e0$613de1a0$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [lamps] Review comment from the AD 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, 27 Sep 2017 18:56:07 -0000 I think this text was supposed to say that SigningTime is the clock = value of the signer, which might be very wrong. One might rely on a = time-stamp authority [RFC3161], if there is a valid attribute from one = in the message. Otherwise, the time that the message arrived in your = mailbox is the best guess that you have. Russ > On Sep 27, 2017, at 2:40 PM, Jim Schaad = wrote: >=20 > I have one review comment from EKR on rfc5750bis that I am not sure = what to > do with. >=20 > The following paragraph from Section 6 - Security Considerations >=20 > When determining the time for a certificate validity check, agents > have to be careful to use a reliable time. Unless it is from a > trusted agent, this time MUST NOT be the SigningTime attribute found > in an S/MIME message. For most sending agents, the SigningTime > attribute could be deliberately set to direct the receiving agent to > check a CRL that could have out-of-date revocation status for a > certificate, or cause an improper result when checking the Validity > field of a certificate. >=20 > The problem is two-fold: > 1. Should the definition of trusted agent be expanded to be more = clear, and > 2. Should that sentence just be deleted because, even if it is a = trusted > agent, a compromised key is going to be able to lie about the time = anyway. >=20 > My memory was that this text was supposed to deal with things like > time-stamp agents where the time was significant, but it could be = wrong. >=20 > Jim >=20 >=20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm From nobody Wed Sep 27 15:04: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 C0996135145 for ; Wed, 27 Sep 2017 15:04:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 8TNEjv3WZgUU for ; Wed, 27 Sep 2017 15:04:27 -0700 (PDT) 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 E912113513B for ; Wed, 27 Sep 2017 15:04:26 -0700 (PDT) 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=1506549816; h=from:subject:to:date:message-id; bh=Le8Lqc6knQS8xSucrdaTTDUVqWlgvffjkd+OW+OG8Sk=; b=Hy8qTJkr7CVnvJpoPdoZZo0CXo1vt9I7pWwQuKZlna2TfaTcpHoCucC1H9RxFUxabj7YlT4nY0x MLfSimA3MFts300Hg3BsHFjEHjnouhnA9vT0X7RMoSX8XOY7Z2nFWo5yeOsCYflOYSAw8RRVaCNmn k8oQykck1SMN06sRTMypQwKEVEoTp3TzxhezT3MSpKc6XtcfhBNp81Cj4FB6Z0c/CjmVJmDQOA0lU vPhRuC9wdbESVhKrvnrRRR6Xpnd8jlhsShmQ+I/vBsZULKr59zx2iNVkVXPb9T61MkcZh3NlGI3qV dxSupj4aBCNykAnBUxg7AHfQE6Ed2YsepIZw== 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; Wed, 27 Sep 2017 15:03:35 -0700 Received: from Hebrews (192.168.1.162) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 27 Sep 2017 15:03:33 -0700 From: Jim Schaad To: 'Russ Housley' CC: 'SPASM' References: <024101d337c0$2069f5e0$613de1a0$@augustcellars.com> <6EC17286-BCA3-4C56-80A6-EEA8279ED5D6@vigilsec.com> In-Reply-To: <6EC17286-BCA3-4C56-80A6-EEA8279ED5D6@vigilsec.com> Date: Wed, 27 Sep 2017 15:04:16 -0700 Message-ID: <025901d337dc$917e6970$b47b3c50$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQFqoV8vTefs2ccFBFEHtScvSvY/6QIgZvajo4ly8GA= X-Originating-IP: [192.168.1.162] Archived-At: Subject: Re: [lamps] Review comment from the AD 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, 27 Sep 2017 22:04:29 -0000 Yes, but if the time-stamp authority has been compromised, then it is no longer a good authority. So perhaps some extra guidance is needed about doing two checks or something. Jim > -----Original Message----- > From: Russ Housley [mailto:housley@vigilsec.com] > Sent: Wednesday, September 27, 2017 11:56 AM > To: Jim Schaad > Cc: SPASM > Subject: Re: [lamps] Review comment from the AD > > I think this text was supposed to say that SigningTime is the clock value of the > signer, which might be very wrong. One might rely on a time-stamp > authority [RFC3161], if there is a valid attribute from one in the message. > Otherwise, the time that the message arrived in your mailbox is the best > guess that you have. > > Russ > > > > On Sep 27, 2017, at 2:40 PM, Jim Schaad wrote: > > > > I have one review comment from EKR on rfc5750bis that I am not sure > > what to do with. > > > > The following paragraph from Section 6 - Security Considerations > > > > When determining the time for a certificate validity check, agents > > have to be careful to use a reliable time. Unless it is from a > > trusted agent, this time MUST NOT be the SigningTime attribute found > > in an S/MIME message. For most sending agents, the SigningTime > > attribute could be deliberately set to direct the receiving agent to > > check a CRL that could have out-of-date revocation status for a > > certificate, or cause an improper result when checking the Validity > > field of a certificate. > > > > The problem is two-fold: > > 1. Should the definition of trusted agent be expanded to be more > > clear, and 2. Should that sentence just be deleted because, even if it > > is a trusted agent, a compromised key is going to be able to lie about the > time anyway. > > > > My memory was that this text was supposed to deal with things like > > time-stamp agents where the time was significant, but it could be wrong. > > > > Jim > > > > > > _______________________________________________ > > Spasm mailing list > > Spasm@ietf.org > > https://www.ietf.org/mailman/listinfo/spasm From nobody Wed Sep 27 15:38:53 2017 Return-Path: X-Original-To: spasm@ietf.org Delivered-To: spasm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F7D513305E; Wed, 13 Sep 2017 08:25:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Liaison Statement Management Tool To: "David Waltermire" , "Tero Kivinen" , "Russ Housley" Cc: David Waltermire , IP Security Maintenance and Extensions Discussion List , Limited Additional Mechanisms for PKIX and SMIME Discussion List , Russ Housley , Scott Mansfield , Kathleen Moriarty , Tero Kivinen , itu-t-liaison@iab.org, Eric Rescorla , jean-paul.lemaire@univ-paris-diderot.fr X-Test-IDTracker: no X-IETF-IDTracker: 6.61.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150531630127.30557.5933470261200873062.idtracker@ietfa.amsl.com> Date: Wed, 13 Sep 2017 08:25:01 -0700 Archived-At: X-Mailman-Approved-At: Wed, 27 Sep 2017 15:38:52 -0700 Subject: [lamps] New Liaison Statement, "LS on ITU-T SG17 work on quantum-safe PKI" X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Sep 2017 15:25:01 -0000 Title: LS on ITU-T SG17 work on quantum-safe PKI Submission Date: 2017-09-13 URL of the IETF Web page: https://datatracker.ietf.org/liaison/1541/ From: Jean-Paul Lemaire To: David Waltermire ,Tero Kivinen ,Russ Housley Cc: David Waltermire ,IP Security Maintenance and Extensions Discussion List ,itu-t-liaison@iab.org,Limited Additional Mechanisms for PKIX and SMIME Discussion List ,Russ Housley ,Scott Mansfield ,Kathleen Moriarty ,Tero Kivinen ,Eric Rescorla Response Contacts: jean-paul.lemaire@univ-paris-diderot.fr Technical Contacts: Purpose: For information Body: ITU-T Study Group 17 is pleased to inform you that in our August/September 2017 meeting we agreed to start work on the inclusion of a proposal to include optional support for multiple public-key algorithms in Recommendation ITU-T X509 | ISO/IEC 9594-8. The industry is preparing ICT systems to be resistant to attacks by large-scale quantum computers in addition to more sophisticated attacks by conventional computing resources. Proposed was an optional feature to the X.509 certificate that provides a seamless migration capability to existing PKI systems, and is completely backwardly compatible with existing systems. While public-key key establishment algorithms are typically negotiated between peers and are generally fairly simple to update, the authentication systems typically rely on a single digital signature algorithm which are more difficult to update. This is because of the circular dependency between PKI-based identity systems and the dependent communication protocols. In order to update a PKI system, one would typically need to create a duplicate PKI system that utilizes a new digital signature algorithm and then migrate all the dependent systems one by one. This proposal eliminates the need to create such duplicate PKI systems by adding optional extensions to contain alternate public key and alternate signature, and a method for the CA to sign certificates using a layered approach to ensure that every attribute is authenticated by both signatures. The resulting certificate, while containing new quantum safe public key and signature, can still be used by existing systems relying on the classic public key and signature. Attachments: sp16-sg17-oLS-00068 https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2017-09-13-itu-t-sg-17-ipsecme-lamps-ls-on-itu-t-sg17-work-on-quantum-safe-pki-attachment-1.pdf From nobody Thu Sep 28 07:31:56 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11EEB1331E7 for ; Thu, 28 Sep 2017 07:31:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DSwfiMqj8PwW for ; Thu, 28 Sep 2017 07:31:47 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A0131331E4 for ; Thu, 28 Sep 2017 07:31:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id EDFAF3002C7 for ; Thu, 28 Sep 2017 10:31:46 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id U3xz3RfE3v40 for ; Thu, 28 Sep 2017 10:31:41 -0400 (EDT) Received: from [172.20.1.237] (h60.74.129.40.static.ip.windstream.net [40.129.74.60]) by mail.smeinc.net (Postfix) with ESMTPSA id 8F9FA300265; Thu, 28 Sep 2017 10:31:41 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Russ Housley In-Reply-To: <025901d337dc$917e6970$b47b3c50$@augustcellars.com> Date: Thu, 28 Sep 2017 10:31:40 -0400 Cc: SPASM Content-Transfer-Encoding: quoted-printable Message-Id: <7D7852CB-EF22-425C-8256-591437400325@vigilsec.com> References: <024101d337c0$2069f5e0$613de1a0$@augustcellars.com> <6EC17286-BCA3-4C56-80A6-EEA8279ED5D6@vigilsec.com> <025901d337dc$917e6970$b47b3c50$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [lamps] Review comment from the AD 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, 28 Sep 2017 14:31:54 -0000 Jim: The CA that issued the certificate to the TSA should revoke that = certificate if the TSA is compromised. So, I think that the revocation = checking on the TSA certification path is enough. Russ > On Sep 27, 2017, at 6:04 PM, Jim Schaad = wrote: >=20 > Yes, but if the time-stamp authority has been compromised, then it is = no > longer a good authority. So perhaps some extra guidance is needed = about > doing two checks or something. >=20 > Jim >=20 >=20 >=20 >> -----Original Message----- >> From: Russ Housley [mailto:housley@vigilsec.com] >> Sent: Wednesday, September 27, 2017 11:56 AM >> To: Jim Schaad >> Cc: SPASM >> Subject: Re: [lamps] Review comment from the AD >>=20 >> I think this text was supposed to say that SigningTime is the clock = value > of the >> signer, which might be very wrong. One might rely on a time-stamp >> authority [RFC3161], if there is a valid attribute from one in the > message. >> Otherwise, the time that the message arrived in your mailbox is the = best >> guess that you have. >>=20 >> Russ >>=20 >>=20 >>> On Sep 27, 2017, at 2:40 PM, Jim Schaad = wrote: >>>=20 >>> I have one review comment from EKR on rfc5750bis that I am not sure >>> what to do with. >>>=20 >>> The following paragraph from Section 6 - Security Considerations >>>=20 >>> When determining the time for a certificate validity check, agents >>> have to be careful to use a reliable time. Unless it is from a >>> trusted agent, this time MUST NOT be the SigningTime attribute = found >>> in an S/MIME message. For most sending agents, the SigningTime >>> attribute could be deliberately set to direct the receiving agent = to >>> check a CRL that could have out-of-date revocation status for a >>> certificate, or cause an improper result when checking the Validity >>> field of a certificate. >>>=20 >>> The problem is two-fold: >>> 1. Should the definition of trusted agent be expanded to be more >>> clear, and 2. Should that sentence just be deleted because, even if = it >>> is a trusted agent, a compromised key is going to be able to lie = about > the >> time anyway. >>>=20 >>> My memory was that this text was supposed to deal with things like >>> time-stamp agents where the time was significant, but it could be = wrong. >>>=20 >>> Jim >>>=20 >>>=20 >>> _______________________________________________ >>> Spasm mailing list >>> Spasm@ietf.org >>> https://www.ietf.org/mailman/listinfo/spasm >=20 >=20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm From nobody Thu Sep 28 07:58: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 A1D7513474D for ; Thu, 28 Sep 2017 07:58:58 -0700 (PDT) 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 DgJquc-bONRK for ; Thu, 28 Sep 2017 07:58:54 -0700 (PDT) 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 121C6134744 for ; Thu, 28 Sep 2017 07:58:54 -0700 (PDT) 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=1506610687; h=from:subject:to:date:message-id; bh=d/k1bjHjHTppO/RMZwktvEhSn1+SeWc++8AUTZyKUoE=; b=N8x3pIPjMpfhNwArHwYx0S5MyR3d9efseG61xfFa5esPgKinqMWqwh4TlYUU0+blzJdP73JPTdG D69cUs4dA3G2YxRW0j3AjZ9Py0iZ1m0d+uPEumETnLwbA5Zd8CF1UNnGRSHV08LOby9HYnX+Ei5Kh 4qupzYHPBE7x8lMNtmMxWORFBvsDAGMPW5I5h71kW8PA4wpNZsXTFzRsYbOeVUDVPVRLxmo6TrCUr KddXAjw+KBQj/4Y0VYJoVimVas9g+DArHn/r+WlUkJKEfJr1uflld9F780c6f7+nWHS2uak4HpXU4 6fvET97nQQUWlFK8l79kIETvg+kSJZO3SxqA== 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; Thu, 28 Sep 2017 07:58:06 -0700 Received: from Hebrews (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 28 Sep 2017 07:58:02 -0700 From: Jim Schaad To: 'Russ Housley' CC: 'SPASM' References: <024101d337c0$2069f5e0$613de1a0$@augustcellars.com> <6EC17286-BCA3-4C56-80A6-EEA8279ED5D6@vigilsec.com> <025901d337dc$917e6970$b47b3c50$@augustcellars.com> <7D7852CB-EF22-425C-8256-591437400325@vigilsec.com> In-Reply-To: <7D7852CB-EF22-425C-8256-591437400325@vigilsec.com> Date: Thu, 28 Sep 2017 07:58:45 -0700 Message-ID: <02a201d3386a$49f61830$dde24890$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQFqoV8vTefs2ccFBFEHtScvSvY/6QIgZvajAgAg/7MCNfQeC6No3c1A X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [lamps] Review comment from the AD 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, 28 Sep 2017 14:58:58 -0000 That would only be true if you checked the most recent CA rather than the one issued at the time in the message. Jim > -----Original Message----- > From: Russ Housley [mailto:housley@vigilsec.com] > Sent: Thursday, September 28, 2017 7:32 AM > To: Jim Schaad > Cc: SPASM > Subject: Re: [lamps] Review comment from the AD > > Jim: > > The CA that issued the certificate to the TSA should revoke that certificate if > the TSA is compromised. So, I think that the revocation checking on the TSA > certification path is enough. > > Russ > > > > On Sep 27, 2017, at 6:04 PM, Jim Schaad wrote: > > > > Yes, but if the time-stamp authority has been compromised, then it is > > no longer a good authority. So perhaps some extra guidance is needed > > about doing two checks or something. > > > > Jim > > > > > > > >> -----Original Message----- > >> From: Russ Housley [mailto:housley@vigilsec.com] > >> Sent: Wednesday, September 27, 2017 11:56 AM > >> To: Jim Schaad > >> Cc: SPASM > >> Subject: Re: [lamps] Review comment from the AD > >> > >> I think this text was supposed to say that SigningTime is the clock > >> value > > of the > >> signer, which might be very wrong. One might rely on a time-stamp > >> authority [RFC3161], if there is a valid attribute from one in the > > message. > >> Otherwise, the time that the message arrived in your mailbox is the > >> best guess that you have. > >> > >> Russ > >> > >> > >>> On Sep 27, 2017, at 2:40 PM, Jim Schaad > wrote: > >>> > >>> I have one review comment from EKR on rfc5750bis that I am not sure > >>> what to do with. > >>> > >>> The following paragraph from Section 6 - Security Considerations > >>> > >>> When determining the time for a certificate validity check, agents > >>> have to be careful to use a reliable time. Unless it is from a > >>> trusted agent, this time MUST NOT be the SigningTime attribute found > >>> in an S/MIME message. For most sending agents, the SigningTime > >>> attribute could be deliberately set to direct the receiving agent to > >>> check a CRL that could have out-of-date revocation status for a > >>> certificate, or cause an improper result when checking the Validity > >>> field of a certificate. > >>> > >>> The problem is two-fold: > >>> 1. Should the definition of trusted agent be expanded to be more > >>> clear, and 2. Should that sentence just be deleted because, even if > >>> it is a trusted agent, a compromised key is going to be able to lie > >>> about > > the > >> time anyway. > >>> > >>> My memory was that this text was supposed to deal with things like > >>> time-stamp agents where the time was significant, but it could be > wrong. > >>> > >>> Jim > >>> > >>> > >>> _______________________________________________ > >>> Spasm mailing list > >>> Spasm@ietf.org > >>> https://www.ietf.org/mailman/listinfo/spasm > > > > > > _______________________________________________ > > Spasm mailing list > > Spasm@ietf.org > > https://www.ietf.org/mailman/listinfo/spasm From nobody Thu Sep 28 13:25:24 2017 Return-Path: X-Original-To: spasm@ietf.org Delivered-To: spasm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8264212426E; Thu, 28 Sep 2017 13:25:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Joel Halpern To: Cc: draft-ietf-lamps-rfc5280-i18n-update.all@ietf.org, spasm@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150663032250.27722.15835601633819810120@ietfa.amsl.com> Date: Thu, 28 Sep 2017 13:25:22 -0700 Archived-At: Subject: [lamps] Genart telechat review of draft-ietf-lamps-rfc5280-i18n-update-03 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2017 20:25:22 -0000 Reviewer: Joel Halpern Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at . Document: draft-ietf-lamps-rfc5280-i18n-update-03 Reviewer: Joel Halpern Review Date: 2017-09-28 IETF LC End Date: 2017-07-25 IESG Telechat date: 2017-10-12 Summary: This document is still ready for publication as a Proposed Standard Major issues: N/A Minor issues: N/A Nits/editorial comments: N/A From nobody Sat Sep 30 06:41:55 2017 Return-Path: X-Original-To: spasm@ietf.org Delivered-To: spasm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CF40132D54; Sat, 30 Sep 2017 06:41:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Adam Montville To: Cc: spasm@ietf.org, ietf@ietf.org, draft-ietf-lamps-eai-addresses.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150677890834.3451.1848734083648672272@ietfa.amsl.com> Date: Sat, 30 Sep 2017 06:41:48 -0700 Archived-At: Subject: [lamps] Secdir last call review of draft-ietf-lamps-eai-addresses-15 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Sep 2017 13:41:48 -0000 Reviewer: Adam Montville Review result: Ready I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document is ready. Previously raised nits have been addressed - thank you! A fresh review offers nothing new from my perspective. Kind regards, Adam